[PATCH] RFC: name the Raspberry Pi GPIO lines

[Linus Walleij]

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.

>> If you want to monitor the value of the line and it is possible to
>> use the lines as GPIO *at the same time* as it is used by the
>> HDMI (with or without hacks) this is achieveable. There are platforms
>> that do this, but I don't know about the BCM2835 pin control and
>> GPIO hardware.
>
> I just want to monitor the value I'd get from gpio_get_value_cansleep().
> It's an input line.

Since the pin controller is not strict (allow to use the line as GPIO
and other function at the same time) and only seems to have
callbacks for fiddling with the direction of the line (which should
anyway be input I assume) you should be able to use it as GPIO
at the same time, so this should be fine, i.e. it can be claimed
for a certain mux setting pertaining to HDMI and be requested
as GPIO and monitored at the same time.

You probably should not set up GPIO line interrupts on it though.

Yours,
Linus Walleij