On Fri, Mar 12, 2010 at 5:18 PM, Kevin Hilman <khil...@deeprootsystems.com>wrote:
> "Nori, Sekhar" <nsek...@ti.com> writes: > > > 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. > > Correct. Drivers should not do muxing. This should be done by SoC or > board init code. If your bootloader is doing it, that suggests that it is > init-time only, and should be done in init code. > > Would it be possible to architect the pin-mux logic to accept boot arguments to configure the SoC devices wanted? We are struggling with porting a kernel to a davinci based System-on-Module type board that would allow end users to select what interfaces (e.g., UARTS vs. SPI ports) to use on these devices. Having a pile of custom machines (kernel configurations) for every permutation seems painful if all they are doing is enabling different devices. I sort of thought the point of modular kernel drivers was to provide pluggable support for dynamic device control. I appreciate that someone needs to keep track of the resources, but couldn't there be some sort of allocation mechanism to allow drivers to "test" and see if they can have a set of resources before using them, much like the gpiolib? -Mike
_______________________________________________ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
