From mboxrd@z Thu Jan 1 00:00:00 1970 From: arnaud.patard@rtp-net.org (Arnaud Patard (Rtp)) Date: Fri, 17 Jan 2014 21:33:56 +0100 Subject: More GPIO madness on iMX6 - and the crappy ARM port of Linux In-Reply-To: <52D98E94.6000609@boundarydevices.com> (Eric Nelson's message of "Fri, 17 Jan 2014 13:12:04 -0700") References: <20140117184731.GE15937@n2100.arm.linux.org.uk> <87ioti2xfu.fsf@lebrac.rtp-net.org> <52D98E94.6000609@boundarydevices.com> Message-ID: <87eh462vrf.fsf@lebrac.rtp-net.org> To: linux-arm-kernel@lists.infradead.org List-Id: linux-arm-kernel.lists.infradead.org Eric Nelson writes: > On 01/17/2014 12:57 PM, Arnaud Patard (Rtp) wrote: >> Russell King - ARM Linux writes: >> >>> So, we have this wonderful GPIO layer which abstracts GPIO stuff and >>> hides stuff. It's really wonderful, because you don't have to care >>> about how the GPIOs are actually accessed in drivers anymore. >>> >>> However, what about the behaviour of GPIOs? >>> >>> What about... for example... this sequence: >>> >>> gpio_direction_output(gpio, 1); >>> val = gpio_get_value(gpio); >>> >>> What value is "val"? More importantly, what value is reflected in >>> /sys/kernel/debug/gpio ? Would it indicate that it's high or low? >>> >>> Now, while you can make reasonable assumptions, such as "it'll return >>> that the output is being driven to the requested state" or "it'll >>> return the actual state of the pin", what about this instead, which >>> happens on iMX hardware - "it'll _always_ return zero". >>> >> >> this is "expected". gpio layer docs are saying that in output case, the >> value may be wrong. Not intuitive but documented. >> >>> Yes, iMX6 at least has this behaviour. For any output, val as above >>> will always be zero, and /proc/sys/kernel/debug/gpio will always >>> report that an output is zero... unless the SION bit has been set for >>> that GPIO signal. >> >> afaik at least imx51/53 have some behaviour. >> >>> >>> The reason is that on hardware such as iMX6, reading the GPIO is done >>> by reading the pad state register, and this register is _only_ supplied >>> the state of the pad when the input path is enabled. The input path >>> is only enabled when the output is disabled, or the SION bit is set >>> to force the GPIO input path. >> >> I sent mails about this same issue for imx51 in Dec 2010 and answer were >> that the SION bit should not be set for all gpios: >> http://permalink.gmane.org/gmane.linux.ports.arm.kernel/100875 >> > > Thanks Arnaud, > > This bit from the 2010 chain really needs some explanation: > >>> Arnaud Patard (Rtp) writes: >>> >>> >>> >>> I had done the same, but had some trouble with this. >>> E.g. on our board GPIO1_7 is used as a generic GPIO to enable an >>> external clock oscillator for the USBH1 ULPI PHY. When the SION bit >>> for this pad was set, I got strange errors on the USBH1 port >>> (disconnecting low speed devices behind a hub would stall the >>> bus). When I removed the SION bit for that pin everything worked >>> well. >>> > > Did you ever chase down the symptom here? Was the GPIO output not > holding a constant value such that the oscillator wasn't functioning? > It was not me who got this issue. The issue I had was not being able to read GPIO value if set as output. This link may be clearer: http://archive.arm.linux.org.uk/lurker/message/20101215.151016.ea731aa7.en.html Arnaud