Nori, Sekhar wrote: > On Mon, Mar 15, 2010 at 07:47:44, Jon Povey wrote:
>> - Board init would setup pinmuxing resource structures that could be >> passed to drivers, something like gpio, but supporting the different >> DaVinci devices (insert handwaving here) >> - Device driver can callback to request / release its mux resources >> - mux layer can print/warn/bug for debug if claimed resources >> conflict >> >> Aplogies if this is all very wrongheaded. I am still getting to grips >> with the provided APIs, attempting to specify a new one is a stretch. > > As far as possible, the interfaces to device drivers should not be > SoC specific ones, but should be portable across platforms and > architectures. > > So, what you are proposing needs to be an interface defined > in include/linux/* and cannot be DaVinci specific. > > The problem is there is no cross-platform framework for handling > pin as a resource defined yet. Currently, every platform that runs > into this solves it in its own way. > > Have a look at this post from the thread I posted earlier.. > > http://www.mail-archive.com/davinci-linux-open-sou...@linux.davincidsp.c om/msg11301.html > > .. and the response from Dave Brownell to that. > > http://www.mail-archive.com/davinci-linux-open-sou...@linux.davincidsp.c om/msg11303.html Thanks for those useful archive links. How about a generic interface which included claim/free resource methods, like for gpio, but taking a pointer to a mux resource struct instead of a gpio number. The mux resource struct would include function pointers to mach- or soc- specific functions to do the work of checking, setting and freeing the mux resources. The mux resource struct would also contain a list of mach- or soc- specific resource data required by that device (pointers into an array of mux resource structs or whatever?) The mux resources would be setup and passed by the board init to the driver. The driver could claim and release them using the platform-independent functions. The platform-independent functions could just be wrappers calling the mach-specific functions, or do more elaborate generic things (sysfs stuff, printing/handling conflicts) I appreciate this is fairly simpleminded and doesn't handle, for example, large peripherals that you may not want to mux all of the pins for (I'm thinking DM355 VPFE, we reuse the sync pins for example). Obviously I am handwaving all implementation details. Just trying to get a grip on the theory and appreciate all experienced criticism. -- Jon Povey jon.po...@racelogic.co.uk Racelogic is a limited company registered in England. Registered number 2743719 . Registered Office Unit 10, Swan Business Centre, Osier Way, Buckingham, Bucks, MK18 1TB . The information contained in this electronic mail transmission is intended by Racelogic Ltd for the use of the named individual or entity to which it is directed and may contain information that is confidential or privileged. If you have received this electronic mail transmission in error, please delete it from your system without copying or forwarding it, and notify the sender of the error by reply email so that the sender's address records can be corrected. The views expressed by the sender of this communication do not necessarily represent those of Racelogic Ltd. Please note that Racelogic reserves the right to monitor e-mail communications passing through its network _______________________________________________ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
