On Sat, Feb 15, 2014 at 09:02:07AM +0530, Jassi Brar wrote: > Hi, > > On 8 February 2014 06:20, Courtney Cavin <courtney.cavin@xxxxxxxxxxxxxx> wrote: > > There is currently no common framework for mailbox drivers, so this is my > > attempt to come up with something suitable. There seems to be a need for > > making this generic, so I have attempted to do just that. Most of this is > > modeled pretty strongly after the pwm core, with some influences from the clock > > core. > > > > Looking at the existing use-cases, and some new ones, it would appear that the > > requirements here are rather simple. We need essentially two things for > > consumers: > > - put_message > > - callback for receiving messages > > > > The code currently uses atomic notifiers for callbacks. The common omap core > > deals with fifos and work-queues in order to escape atomic contexts, but from > > what I can see, this is unneeded. I am also of the opinion that the contexts > > can be much better managed in the drivers which are working with these > > contexts, rather than generically. > > > > Hopefully this will be suitable for the plethora of other drivers around the > > kernel which implement mailboxes, as well. In any case, I'm rather interested > > to see what the rest of the world thinks. > > > > Keep in mind that while the pl320 & omap code should compile, I don't currently > > have a platform on which I can perform proper testing. I also removed the > > context save/restore code from omap2 mailbox support, because I think it should > > be able to be done via driver suspend/resume, but haven't done a full > > investigation just yet. > > > > I'm also aware that breaking omap, just to fix it again probably isn't the best > > course of action, and I'm open to suggestions. > > > Did you try to look up the history of mailbox api development? Google > search: 'mailbox common api' > > I (Linaro/Fujitsu), Suman Anna (TI), LeyFoon Tan (Intel), Craig > McGeachie(Broadcom) and Loic Pallardy(ST) already worked a generic > Mailbox framework and infact have controller drivers working over > them. > For some confidentiality and some lazy and some confusion or whatever > reasons the final version of drivers and API wasn't submitted upstream > yet. Then, in all reality, it doesn't exist at all, and so, we will evaluate this submission instead. Just because you all can't send something for merging, doesn't mean you get to block someone else who has got their act together, that's not fair. sorry, greg k-h -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
