> > 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. >
Kevin, This reminds me of the discussions between you, Mark G, and Dave Brownell about dynamic pinmux setup and conflict detection. I seem to remember a comment regarding a change in clock setup (or was it some driver init) that would make a variant of dynamic pinmux setup in MVL Pro5 acceptable to the community. Just wondering if you remember any details. Steve _______________________________________________ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
