Messages in this thread | | | Date | Tue, 24 Feb 2009 23:09:00 +0100 (CET) | From | Guennadi Liakhovetski <> | Subject | Re: [RFC PATCH 2/3] mxc: move serial driver init()/exit() to platform_device |
| |
On Tue, 24 Feb 2009, Russell King - ARM Linux wrote:
> I really don't like this approach to controlling multiplex pins, which > is to setup the SoC pin configuration when the driver is being bound and > to remove it when the driver is unbound.
What do you think about the reasoning given by Sascha here: http://marc.info/?l=linux-arm-kernel&m=123453175927569&w=2 which is power saving?
> > Let's take the issue of a serial driver. > > The outputs of a serial port have defined inactive levels - for TXD, RTS > and DTR, that's logic one. If a driver is not loaded and you have a > peripheral connected to this port, you probably don't want them to see > a break level on TXD, or active RTS or DTR signal. > > However, by hooking the SoC pin configuration into the binding and > unbinding of the driver, the state of the pins are indeterminent until > the driver is initialised. > > I can think of other cases in hardware I've dealt with which required > careful handling of SSP signals to ensure that a flip-flop in a FPGA is > correctly set to ensure that left/right channels aren't swapped. > > Basically, my point is that for 99.9% of the time, SoC pin configuration > is determined by the platform board layout, and the right place to set > this configuration up is in the board support file, just like we do on > PXA platforms. > > For the 0.1% of cases where a board needs to manipulate the SoC pin > configuration depending on which drivers are loaded, doing so at driver > probe time _may_ make sense, but it feels all together cumbersome, > especially as unloading drivers has historically had question marks > over it. > > Surely, for this 0.1% of cases, the right solution would be to have an > interface which allows a platform device to be unregistered, the SoC pin > mux settings changed by platform code, and the new device registered? > > Finally, note that the approach of putting init/exit into struct > platform_device doesn't cater for all cases - we're still going to need > to have init/exit pointers in platform data for some platform devices, > such as MMC drivers, which have to pass parameters to those hooks.
Thanks Guennadi --- Guennadi Liakhovetski
| |