• State TI Thinks Resolved
  • Locked Locked
  • Replies 4 replies
  • Answers 3 answers
  • Subscribers 98 subscribers
  • Views 1525 views
  • Users 0 members are here
Support feedback
Options
Options
Related

This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

Linux/AM5728: IPC MessageQ and rpmsg details

Janardan M
Expert 1115 points

Part Number: AM5728

Tool/software: Linux

Hi Everyone,

I am using MessageQ between ARM A15 and DSP , currently when I am not freeing all msgQ at a15 side after round trip from A15->DSP->A15,
MessageQ are allocated without heap memory.
I have following errors,
rpmsg_proto virtio0.rpmsg-proto.-1.61: timeout waiting for a tx buffer
rpmsg_sock_sendmsg: rpmsg_send failed: -512
TransportRpmsg_put: send failed: 512 (Unknown error 512)
From rpmsg driver, come to know that  MAX_RPMSG_NUM_BUFS   (512),
so If I want to push more msgQ than this MAX_RPMSG_NUM_BUFS can I increase this buffers ? will it affect other functionality of rpmsg other than MsgQ?

Regards,

Janardan M

  • 0
    TI__Guru 50170 points
    Hi, Janardan,

    By looking at the rpmsg source code, rpmsg allocate the total buffer space using buffer number * buffer_size. You can give it a try and see if it makes difference.

    total_buf_space = vrp->num_bufs * vrp->buf_size;
    bufs_va = dma_alloc_coherent(vdev->dev.parent->parent,
    total_buf_space, &vrp->bufs_dma,
    GFP_KERNEL);

    Rex
  • 0 in reply to Rex Chang
    TI__Guru 50170 points
    Hi, Janardan,

    FYI. The buffer size cannot be changed without modifying driver. The buffer number can be changed, but it is dictated by the resource table. Depending on the size you want, you may have to change your linker cmd file as well depending on the total size being allocated.

    Rex
  • 0 in reply to Rex Chang
    Expert 1115 points
    Hi Rex,

    I tried increasing messageQ size to 1024 as of your instructions and tested the change, even in this case the issue is same, I am able to see the same error message popping up. please suggest me for workaround .

    Thanks,
    Janardan
  • 0 in reply to Janardan M
    TI__Guru 50170 points
    Hi, Janardan,

    Adding the queue depth wasn't suggested in the beginning because you are trying to mask out the issue. The result is expected not to work. As I mentioned earlier, you should redesign the DSP code in terms of the RTOS thread scheduling and priority. FWIW, the messages themselves should be handled as soon as they are received and in a Swi.

    This is design issue and TI won't be able to solve. I'll close this thread.

    Rex