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

Jonathan Richardson jonathan.richardson at broadcom.com
Wed Mar 29 12:28:59 PDT 2017

On 17-03-28 09:36 PM, Jassi Brar wrote:
> On Tue, Mar 28, 2017 at 11:00 PM, Jonathan Richardson
> <jonathan.richardson at broadcom.com> wrote:
>> On 17-03-15 10:30 AM, Jassi Brar wrote:
>>> 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.
>> 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.

>> 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.


More information about the linux-arm-kernel mailing list