Hi On 29 April 2013 21:30, Suman Anna <s-a...@ti.com> wrote: > Hi Jassi, > > On 04/26/2013 11:51 PM, Jassi Brar wrote:
>>> OK, I didn't think of a no RTR interrupt-based controller. I would thing >>> that such a controller is very rudimentary. I wonder if there are any >>> controllers like this out there. >>> >> One of my controllers is like that :) > > I hope it does have a status register atleast, and not the "neither > report nor sense RTR" type. > Actually the status is not set by the h/w, but the remote's firmware implementation makes sure it sets a marker in the status register after accepting data. So with some other firmware, we might not even have the status read facility and the client will have to solely run the TX ticker. >> If the controller h/w absolutely can not tell the remote(sender) of a >> received packet (as seems to be your case), its driver shouldn't even >> try to demux the received messages. The client driver must know which >> remotes could send it a message and how to discern them on the >> platform. Some 'server' RX client is needed here. > > No demuxing, deliver the message to the different clients. It is a > protocol agreement between the clients on what the message means. Think > of this scenario akin to shared interrupts. > Please re-read. That's what I said - No demuxing by the controller driver :) > > The notify mechanism was the top-half on the interrupt handling. The > faith part is coming from the fact that you expect all the clients to do > the equivalent of the bottom-half (which would mean some duplication in > the different clients), the OMAP scenario is such that all the different > link interrupts (both rx & tx) are mapped onto a single physical > interrupt. I think this may not be applicable to your usecase, wherein > you probably expect a response back before proceeding. > Simply put - the RX by notifier method will fail should a client is speed critical. The api might provide it optionally, but direct handover should be the default option. Btw, I did put up an almost tested version of an API implementing most of the features we agree upon http://www.spinics.net/lists/kernel/msg1523873.html http://www.spinics.net/lists/kernel/msg1523874.html cheers. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
