Thread (28 messages) 28 messages, 5 authors, 2017-05-16

Re: [PATCH v4 3/5] soc: qcom: Introduce APCS IPC driver

From: Jassi Brar <jassisinghbrar@gmail.com>
Date: 2017-05-06 04:48:14
Also in: linux-arm-msm, linux-remoteproc, lkml

On Sat, May 6, 2017 at 6:49 AM, Bjorn Andersson
[off-list ref] wrote:
On Fri 05 May 13:22 PDT 2017, Jassi Brar wrote:
quoted
How is it supposed to work if a client queues more than one request?
One such example is found in patch 5 in this series. There are two FIFOs
in shared memory, one in each direction. Each fifo has a index-pair
associated; a write-index is used by the writer to inform the reader
where the valid data in the ring buffer ends and a read-index indicates
to the writer how far behind the read is.

The writer will just push data into the FIFO, each time firing off an
APCS IPC interrupt and when the remote interrupt handler runs it will
consume all the messages from the read-index to the write-index. All
without the need for the reader to signal the writer that it has
received the interrupts.

In the event that the write-index catches up with the read-index a
dedicated flag is set which will cause the reader to signal that the
read-index is updated - allowing the writer to sleep waiting for room in
the FIFO.
Interesting.Just for my enlightenment...

  Where does the writer sleep in the driver? I see it simply sets the
bit and leave.
Such a flag (or head and tail pointers matching) should be checked in
last_tx_done()

If you think RPM will _always_ be ready to accept new messages (though
we have seen that doesn't hold in some situations), then you don't
need last_tx_done. The client should call mbox_client_txdone() after
mbox_send_message().

thnx
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help