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

[Michael Zoran]

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>
> 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
> functionality.
> 
> [1] http://lists.infradead.org/pipermail/linux-rpi-kernel/2016-Septem
> ber/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.
> 
>   Dave

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
wrong etc?