[PATCH 1/6] bcm2835-gpio-exp: Driver for GPIO expander via mailbox service
mzoran at crowfest.net
Thu Mar 23 16:07:25 PDT 2017
On Thu, 2017-03-23 at 22:07 +0000, Dave Stevenson wrote:
> Hi Stefan.
> On 23 March 2017 at 19:45, Stefan Wahren <stefan.wahren at i2se.com>
> > 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  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
>  http://lists.infradead.org/pipermail/linux-rpi-kernel/2016-Septem
> > 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
> 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
> (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.
Is their actually an expander on the RPI 3?
Do people want my help at this point, or was this all just to prove me
More information about the linux-rpi-kernel