On Tuesday 30 December 2008, Sergei Shtylyov wrote: > > Move DM355 MMC/SD pinmux to the device setup code; it shouldn't > > be coupled to clock activation. This is a small cleanup which > > doesn't yet support options like not muxing all MMCSD1 pins when > > they're not needed (e.g. hard-wired to an SDIO WLAN adapter). > > Such options should be dealt with at the board-*.c level
Right: pass such info to the code which sets up the MMC/SD/SDIO platform device, which passes the info to the MMC driver. (It'd need to stop advertising 4-bit support, and might need to adjust its eventual SDIO support.) > -- as well as any > board level PinMux specifics (say, you need unused pins of some device to be > used by other device and you do need both devices to work). I think I agree, but it's hard to tell without specifics. Those can be dealt with as they show up. > WBR, Sergei > > PS: We now have the code to detect PinMux conflicts at runtime but it will > only work on DM35x. That must be code that hasn't been published yet. The current muxing code doesn't even have a representation of pins, so it can't detect whether a davinci_cfg_reg() call introduces any kind of conflict. > DM64xx PinMux registers are module-, not pin-centric > (i.e., it might be possible to detect conflicts there but that would need > careful work of grouping some separate bitfields together in 'struct > pin_config' to create mutually exclusive configs -- not sure if it's at all > posiible ATM). Hopefully, we'll be able to submit that... It's currently "struct mux_config". :) I'm not sure I see a need for software to detect such conflicts. Other platforms don't seem to be suffering the lack of it... - Dave _______________________________________________ Davinci-linux-open-source mailing list [email protected] http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
