Thread (1 message) 1 message, 1 author, 2017-03-29

[PATCH v4 2/3] mailbox: Add iProc mailbox controller driver

From: Jonathan Richardson <hidden>
Date: 2017-03-29 19:28:59
Also in: linux-devicetree


On 17-03-28 09:36 PM, Jassi Brar wrote:
On Tue, Mar 28, 2017 at 11:00 PM, Jonathan Richardson
[off-list ref] wrote:
quoted
On 17-03-15 10:30 AM, Jassi Brar wrote:
quoted
The right way to do is have a 'server/owner' client that accepts
requests from various clients and serially queue them to mailbox. That
way you can keep the controller driver free from quirks (like max wait
time of 30us) of your present platform.
Do you mean 1 mailbox client with one mailbox channel that all the mbox client drivers share?
I thought this would work when I suggested it previously but the client callbacks are necessary
in all txdone modes. Client drivers that send the messages need the callbacks
That's a legit requirement.
quoted
and this is only possible with multiple mbox clients.
That is incorrect.
It is trivial to support callbacks to end clients from your common
code... just ask for callback along with the message to be submitted
to mailbox api.
Ok, if we can provide our own callbacks in the message instead of the client then that's perfectly fine.
quoted
And a channel can only have 1 mbox client. Clients in multiple drivers need the callbacks to either know when to start polling, or be notified when the transaction is complete. It would be nice if multiple clients could use the same channel.
We had to choose from shared vs exclusive access to channels... latter
was chosen because there are ways to still support former.
This makes more sense now. Thanks for clarifying.

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