[patch 1/2] imx51: fix gpiolib support
Arnaud Patard (Rtp)
arnaud.patard at rtp-net.org
Wed Dec 1 05:03:05 EST 2010
Lothar Waßmann <LW at KARO-electronics.de> writes:
> Hi,
Hi,
>
>> The gpiolib code is always returning 0 when reading pad values if the pads
>> are configured as output. Using DR registers instead of PSR is fixing that.
>>
>> Signed-off-by: Arnaud Patard <arnaud.patard at rtp-net.org>
>> Index: linux-2.6-submit/arch/arm/plat-mxc/gpio.c
>> ===================================================================
>> --- linux-2.6-submit.orig/arch/arm/plat-mxc/gpio.c 2010-11-24 18:00:47.000000000 +0100
>> +++ linux-2.6-submit/arch/arm/plat-mxc/gpio.c 2010-11-24 18:06:54.000000000 +0100
>> @@ -276,6 +276,10 @@
>> {
>> struct mxc_gpio_port *port =
>> container_of(chip, struct mxc_gpio_port, chip);
>> + u32 l = __raw_readl(port->base + GPIO_GDIR);
>> +
>> + if (cpu_is_mx51() && (l & (1 << offset)))
>> + return (__raw_readl(port->base + GPIO_DR) >> offset) & 1;
>>
>> return (__raw_readl(port->base + GPIO_PSR) >> offset) & 1;
>> }
>>
> Now you are not reading the actual pin state as with GPIO_PSR, but the
> value that has been programmed into the output register (thus you
> would not be able to determine whether an Open Drain output that is
> programmed to HIGH is driven LOW by an external device).
yeah, I know. I didn't say it was the right fix. I noticed a problem and
proposed a solution.
>
> Note that for being able to read back the actual pin state of an
> output, the SION bit in the MUX_CTL register of the corresponding pad
> has to be asserted.
Is it working no matter of the MUX_MODE setting ? I thought that it was
working only if the MUX_MODE setting was 0 and not for every possible
MUX_MODE setting.
Arnaud
More information about the linux-arm-kernel
mailing list