RE: [PATCH 1/2] gpio: add pin biasing and drive mode to gpiolib
From: H Hartley Sweeten
Date: Wed Apr 27 2011 - 18:17:03 EST
On Wednesday, April 27, 2011 2:55 PM, Russell King wrote:
> On Wed, Apr 20, 2011 at 04:32:38PM +0100, Alan Cox wrote:
>>> Even if some people are only muxing pins that can also be used as GPIO,
>>> this is not always the case. We can shunt out the same pins to be used as
>>> I2C or SPI for example, that means this cannot be handled in a GPIO
>>> driver since it has nothing to do with GPIO pins at all.
>>
>> It sounds very much to me like it belongs in the GPIO driver. That is the
>> one piece of code which knows what it is doing for all this configuration.
>
> I don't think so. See PXA devices, where MFP (multifunction pin)
> configuration is entirely separate from GPIO - and there's some MFPs
> which don't even have GPIOs associated with them.
>
> If I'm reading the PXA930 MFP header file right, it also appears that
> GPIOs can be configured on to multiple different pins (eg, GPIO46 can
> be on GPIO46 or DF_nWE. So refering to GPIO46 does not give you
> sufficient information for exactly what pin is to be configured here.
>
> To complicate matters, MFP configuration on PXA deals with stuff like
> low power mode configuration, drive strength, etc which is completely
> independent of the GPIO layer.
I agree with Russell. The muxing goes way beyond GPIO use.
On the i.MX for example, the iomux is used to configured what the pads on the
chip are used for. The pad configuration might be gpio related or it could be
setting the pad for use by one of the internal peripherals.
For instance, on the i.MX35 the uart3 rxd signal can appear on the pads: RTS2,
SD2_DATA0, ATA_DATA10, or FEC_TX_CLK. All of these pads can also be configured
as a gpio or for use by some other on-board peripheral.
Also, like Russell mentions for the PXA930, some of the gpios can be routed to
multiple pins. And some of the pads have no gpio use but multiple other uses.
Regards,
Hartley--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/