More GPIO madness on iMX6 - and the crappy ARM port of Linux
Eric Nelson
eric.nelson at boundarydevices.com
Fri Jan 17 14:33:43 EST 2014
Hi Russell,
On 01/17/2014 12:13 PM, Eric Nelson wrote:
> Hi Russell,
>
> On 01/17/2014 11:47 AM, Russell King - ARM Linux wrote:
>>
>> <snip>
>>
>> So, this brings up three obvious questions:
>>
>> 1. What should gpio_get_value() return for an output?
>
> It seems that this is pretty well specified.
>
> To quote Documentation/gpio/gpio-legacy.txt:
> >> When reading the value of an output pin, the value
> >> returned should be what's seen on the pin ... that
> >> won't always match the specified output value, because
> >> of issues including open-drain signaling and output
> >> latencies.
>
> Documentation/gpio/gpio.txt is a little less clear, but implies
> the same:
> >> If you are "driving" the signal high but
> >> gpiod_get_value(gpio) reports a low value (after
> >> the appropriate rise time passes), you know some other
> >> component is driving the shared signal low
>
>> 2. What should be reported in /sys/kernel/debug/gpio for an output?
>> 3. Should iMX6 (and similar) GPIOs always have the SION bit set in
>> their DT descriptions?
>>
>> Discuss.
>>
>
> Each signal accessed using the GPIO subsystem **must** have
> the SION bit set and the values returned should be the value
> from the PSR registers.
>
Because the MUX registers are very consistent, it appears
that a fix for this that sets the SION bit is simple (almost
mechanical) in the imx*pinfunc.h files.
It seems that each of the declarations matching
#define MX*GPIO_something
should have bit four set in the mux_mode column.
I'd be happy to work up a patch if there's agreement here
(and I can't think of any rationale for not setting these).
Regards,
Eric
More information about the linux-arm-kernel
mailing list