On Thu, Mar 11, 2010 at 11:45:47, Jon Povey wrote: > Steve Chen wrote: > > On Wed, Mar 10, 2010 at 12:49 AM, Jon Povey > > <jon.po...@racelogic.co.uk> wrote: > > >> We have 3 different boards using DM355, with different gpio / pinmux > >> setups. So far, our device drivers are modules which fiddle the > >> pinmux registers directly. > > >> At the moment I am thinking that I might want to split up > >> davinci_cfg_reg into two functions so it's not hardwired to > >> soc_info->pinmux_pins, and I could pass my own mux_config structs > >> in. If this is of interest I can have a go at doing this and > >> submitting the patch here. > > > > For board specific pinmux, you can put them in board-dm355-*.c. > > There are some board specific pinmux setup in board-da830-evm.c. > > Look for da8xx_pinmux_setup. > > Thanks, I see this. I have also been looking at the gpiolib support and > something like that would be useful. > > At minimum it would be helpful to split out the davinci_cfg_reg stuff as > described above so that driver modules can use the same functions.
Methods of handing pinmux were debated at length on this list. I think this thread captures most of it: http://www.mail-archive.com/davinci-linux-open-source@linux.davincidsp.com/msg11281.html It's a long thread, but very useful read. I don't think having drivers handle pinmux directly is acceptable at all. I still think splitting davinci_cfg_reg() they way you describe may have some merit in terms of code organization, but I fail to see where it will be useful (at least in the current kernel). > I may extend the mux.c interface to support debugfs for reporting, and > perhaps an owner name string. The mux.c interface could maintain a > bitmap of claimed mux bits and warn/deny on conflicts like the gpiolib > does. Something like this was implemented (I think by Steve Chen) for MV kernel. It has not been submitted for upstream acceptance, but I do not seem to recall any major opposition to the idea (you should check the thread above). > > I recently found the gpiolib tracking of owners and debugfs support very > useful, which inspired me to look at muxing in that way. > > Again comments are welcome, especially "you're an idiot, do it like this > instead" or "all fixed in arago", otherwise I will quietly hack away on > my own and maybe submit a patch later. > > Cc'd KH as he seems to have been most active in mux.c recently. You didn't actually do it (I did now), but there should be no need to do that since he tracks this list pretty closely. Thanks, Sekhar _______________________________________________ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
