[PATCH] RFC: name the Raspberry Pi GPIO lines

Eric Anholt eric at anholt.net
Tue Oct 18 08:52:21 PDT 2016


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

> On Thu, Oct 6, 2016 at 8:26 PM, Eric Anholt <eric at anholt.net> wrote:
>> Linus Walleij <linus.walleij at linaro.org> writes:
>
>> Nice.  I really like this idea.  I'll spend some time reviewing these
>> against the schematics I have and send some updates.
>
> Please just squash in your changes and apply as one patch in the
> end. I don't care about credits for the patch, the important part is that
> it happens.
>
>>         line 45: "[PWM1_OUT]" unused
>>         line 46: "HDMI_HPD_P" unused
>>         line 47: "SD_CARD_DET" "?" [kernel output]
>>         line 48: "[SD_CLK_R]" unused
>>         line 49: "[SD_CMD_R]" unused
>>         line 50: "[SD_DATA0_R]" unused
>>         line 51: "[SD_DATA1_R]" unused
>>         line 52: "[SD_DATA2_R]" unused
>>         line 53: "[SD_DATA3_R]" unused
>>
>> So we've got nice names now, but everything is showing up as unused.
>
> Not this one:
>
>>         line 47: "SD_CARD_DET" "?" [kernel output]
>
> It is used as a GPIO by the kernel driver for SD card detection.
>
>> I know the HDMI HPD has been grabbed by the DRM, and my SD lines are
>> obviously in use by my SD card.  What does "unused" mean here?  Are we
>> doing something wrong in our platform?
>
> From a GPIO point of view the lines used by other peripherals are
> "unused" as they are not used for GPIO. I don't have a mechanism
> for letting the pin control subsystem tell the GPIO subsystem that it
> can't use a certain pin, but I guess it is possible. However it would
> require the pin controller to set the .strict flag in struct pinmux_ops
> and the BCM2835 currently does not, i.e. it says it is OK to use
> pins for GPIO and other devices at the same time.
>
>> 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.

>> What I'm looking for is something where I can ask a user "please plug
>> and unplug your HDMI monitor while 'watch grep HDMI
>> /debug/gpio/whatever' is running" and see what happens.
>
> Hm... Not familiar with the use case.
>
> 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.
-------------- 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/20161018/de1d0a6f/attachment.sig>


More information about the linux-rpi-kernel mailing list