On 18 July 2014 00:21, Sudeep Holla <sudeep.holla@xxxxxxx> wrote: > On 17/07/14 18:07, Jassi Brar wrote: > >>> 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. >>> >>> 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. > >> 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@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
