[PATCH 1/6] bcm2835-gpio-exp: Driver for GPIO expander via mailbox service

Dave Stevenson dave.stevenson at raspberrypi.org
Thu Mar 23 15:07:10 PDT 2017

Hi Stefan.

On 23 March 2017 at 19:45, Stefan Wahren <stefan.wahren at i2se.com> wrote:
> Hi Dave,
>> Dave Stevenson <dave.stevenson at raspberrypi.org> hat am 23. März 2017 um 18:08 geschrieben:
>> Linus' review comments preferred hard coding "ngpios" and
>> "firmware-gpio-offset" in the driver. Eric and Michael both pushed
>> them into DT. Stephan made a comment of setting rpi->gc.base
>> explicitly in the driver. I know I was focussed on the task of getting
>> it working, hence the hardcoded gc.base=128 and then using gc.base as
>> the firmware offset.
>> I can see cases for numerous options:
>> 1) Any expanders controlled through the firmware will start with an
>> offset of 128. Within the firmware GPIOs 0-127 map onto the standard
>> GPIO block, but why would you bother to use this driver when you can
>> go direct and avoid an IPC overhead? Hard coding that offset to 128
>> seems reasonable.
> i think there is a big misunderstanding. There is no standard GPIO block. The base in mainline pinctrl-bcm2835 is -1, which means Linux is free to choose the base.

My apologies if I'm misrepresenting you (and certainly for mispelling
your name).
I was referencing your comment archived at [1] in relation to Eric's
patch implementing a driver for the expander.
"i think it's better to assign rpi->gc.base explicit."
Is that no longer your view?

My comment is that the VPU firmware code is using GPIO numbers 0-127
for the peripheral that is generally termed the gpio block, even if
Linux drives it through a pinctrl driver and is free to set the base
to any value of its chosing.
The mailbox service can be told to control the GPIOs the firmware
considers to be 0-127 just as well as those on the expander starting
at 128, however in my view there is no point in making use of that

[1] http://lists.infradead.org/pipermail/linux-rpi-kernel/2016-September/004420.html

> Btw userspace shouldn't rely on those GPIO numbers.

Reality is that the typical userspace application is using pigpio,
WiringPi, or GpioZero, totally ignoring the kernel and going direct to
the hardware registers. So in that regard I guess they aren't relying
on those GPIO numbers, but also it's totally uncontrolled :-(
For the expander GPIOs they are forced to come through a kernel driver
(unless they use the mailbox directly), so some manner of determining
where Linux has decided to place the GPIOs is going to be necessary.
I'm open to suggestions.


More information about the linux-rpi-kernel mailing list