David Brownell 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.)
Not only that: PinMux setup code will also be board specific. It would
seem good however to have non-specific PinMux setups for all devices in the
generic files (like devices.c) with the way of overriding them on the board
level. (In fact, we have implemented this in the conflict detection patch.)
-- 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
I didn't say it has.
muxing code doesn't even have a representation of pins, so it
Actually, I should have said signals, not pins. It represents them via
struct mux_config, though sometimes it's a signal group (e.g. MMC/SD0 case)
and sometimes it's individual pins (e.g. MMC/SD1 case).
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". :)
Yeah, seeing it now. Our internal code base is significantly different.
I'm not sure I see a need for software to detect such conflicts.
If I remember correctly, you were all for such code -- or was it Kevin.
Anyway, it's the *only sane way* to determine pin-incompatible kernel
configurations.
Other platforms don't seem to be suffering the lack of it...
I'm not familiar with the (usual) OMAP PinMux but it might be just
impossible (hard) to detect the conflicts, like on DM64xx. There's OMAP-1x
however (which is actually not an OMAP in anything and in reality it most
resembles DaVinci :-) which has 20 PinMux registers to control multiplexing of
400+ signals *individually*.
- Dave
WBR, Sergei
_______________________________________________
Davinci-linux-open-source mailing list
Davinci-linux-open-source@linux.davincidsp.com
http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
