[PATCH] RFC: name the Raspberry Pi GPIO lines

Eric Anholt eric at anholt.net
Wed Oct 19 09:07:35 PDT 2016


Linus Walleij <linus.walleij at linaro.org> writes:

> On Tue, Oct 18, 2016 at 5:52 PM, Eric Anholt <eric at anholt.net> wrote:
>>> On Thu, Oct 6, 2016 at 8:26 PM, Eric Anholt <eric at anholt.net> wrote:
>
>>>> The thing I want most when trying to debug gpio/pinctrl issues is
>>>> something that shows me what the current pinmux is and what the state of
>>>> the line is.  /debug/pinctrl/3f200000.gpio/pins is promising, but it
>>>> doesn't get the new names:
>>>>
>>>> ...
>>>> pin 44 (gpio44) function alt0 in lo; irq 138 (none)
>>>> pin 45 (gpio45) function alt0 in lo; irq 139 (none)
>>>> pin 46 (gpio46) function gpio_in in lo; irq 140 (none)
>>>> pin 47 (gpio47) function gpio_out in lo; irq 141 (none)
>>>> pin 48 (gpio48) function alt3 in hi; irq 142 (none)
>>>
>>> Don't you have
>>> /debug/pinctrl/3f200000.gpio/pinmux-pins
>>> ?
>>
>> Sorry, never saw your mail due to a bug in my mail client.  Looking at
>> that file, that's got:
>>
>> pin 46 (gpio46): (MUX UNCLAIMED) (GPIO UNCLAIMED)
>>
>> No name, no mux, and no current state of the line, either.
>
> That is an indication that maybe the right muxing is not even set up
> for this pin: instead the driver simply relies on the power-on defaults
> that happen to be correct.
>
> The pinmux framework does not query the register to figure out what
> muxing is set up (if someone wants to work on this, welcome) so
> the sysfs simply reflects the muxing done by the kernel since boot.
>
> I would make sure the right muxing is set up in the device tree
> and connected to the "default" state of that device at least.

Yeah, we could work on that.  But for debugging GPIO I want the debug to
be fetching the actual state back out of the hardware, not relying on
whatever we programmed last.  For example, the key to figuring out why
my original FXL6408 GPIO expander driver didn't work was was seeing that
the pinmux was changing a bunch, because the firmware was manipulating
it.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 800 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-rpi-kernel/attachments/20161019/7d79cfeb/attachment.sig>


More information about the linux-rpi-kernel mailing list