On Fri, May 31, 2019 at 05:53:26PM +0100, Sudeep Holla wrote:

On Fri, May 31, 2019 at 11:21:08AM -0500, Jassi Brar wrote:

quoted

On Fri, May 31, 2019 at 9:33 AM Sudeep Holla [off-list ref] wrote:

quoted

quoted

This is my another attempt to extend mailbox framework to support
doorbell mode mailbox hardware. It also adds doorbell support to ARM
MHU driver.

quoted

Nothing has really changed since the last time we discussed many months ago.
MHU remains same, and so are my points.

Yes, I understand your concern.

But as mentioned in the cover letter I did try the suggestions and have
detailed reasoning why that's still an issue. In short I ended up
re-inventing mailbox framework with all the queuing and similar APIs
for this. Worse, we can't even add an extra node for that in DT to
describe that. It can't be simple shim as we need to allow multiple
users to access one physical channel at a time. We have use case
where we can this for CPU DVFS fast switching in scheduler context.

Forgive me if I'm missing something here (this is partly based on
conversations from months ago so I may be misremembering things) but is
the issue here specifically the doorbell mode or is it the need to have
partly software defined mailboxes implemented using this hardware?  My
understanding is that the hardware is more a component that's intended
to allow potentially multiple more complex mailboxes to be tied to a
single hardware block than a complete mailbox in and of itself.  It
feels like the issues with sharing access to the hardware and with the
API for talking to doorbell hardware are getting tied together and
confusing things.  But like I say I might be missing something here.