Re: [PATCH 7/8] mailbox: f_mhu: add driver for Fujitsu MHU controller

On 18 July 2014 00:21, Sudeep Holla [off-list ref] wrote:

On 17/07/14 18:07, Jassi Brar wrote:

quoted

quoted

I believe that's what we need here if we want this driver to work
on both Juno and your platform. Agree ?

Does this driver not work for Juno?

I have not yet tried yet. For sure secure access will explode.

OK, I will remove setting up SCFG.

quoted

quoted

No what I meant is unless there is a real need to use hard irq, we
should prefer threaded one otherwise.

And how does controller discern a "real need" from a "soft need" to
use hard irq?
Even if the controller driver pushes data up from a threaded function,
the client can't know the context and can't sleep because the
intermediate API says the rx_callback should be assumed to be atomic.

Yes I am not arguing on that, it should assume atomic and not sleep.
I am saying we can avoid rx_callback in interrupt context if possible.
I will try to look at the protocol implementation tomorrow.

There is only one way for controller to push data to client... which
is rx_callback() and it specified to be atomic.

quoted

Again, it maybe more efficient if I see your implementation of the
driver and understand your concerns about mine.

As I said its almost same as this, except I call mbox_chan_received_data
in irq thread context. I prefer enabling other interrupts while copying
payload data.

You call mbox_chan_received_data (which does rx_callback) from
threaded handler. If your client only does atomic stuff in
rx_callback(), then you pay for nothing. If your client does sleepable
stuff then, as you agree, that's wrong.

cheers
-jassi
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html