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

[Stefan Wahren]

Hi Dave,

> Dave Stevenson <dave.stevenson at raspberrypi.org> hat am 23. März 2017 um 18:08 geschrieben:
> 
> 
> On 21 March 2017 at 20:58, Michael Zoran <mzoran at crowfest.net> wrote:
> > On Tue, 2017-03-21 at 23:30 +0300, Dan Carpenter wrote:
> >> I've read Stefan's review comments and intervened where I didn't
> >> understand them.  The recent ones are very specific and reasonable...
> >>
> >> Just send a v2.  I don't get what the deal is...
> >
> > Partly because Eric and Stefan have publically annouced all over the
> > who knows where that they don't want this in staging.  They say it
> > needs to go to the general tree.  So I'm not 100% sure a V2 makes sense
> > when people aren't even agreeing if this is the correct place for this
> > to be.
> >
> > I did not write the driver myself, I've simply been burdened myself
> > that VC4 doesn't really work that good on the RPI 3 so I was hoping it
> > would unblock people after finding it on the web.
> >
> > If people want a V2, then they are going to have to be very specific
> > about what needs to change and exactly how it to change. Not just say
> > they don't like it.
> >
> > If it's suddenly so important, why can't someone else add in their
> > corrections after my Signed-off-by: and add their own Signed-off-by:.
> > Or better yet submit the original driver themselves.
> 
> Michael: I know the original request to upstream this came from Phil /
> myself, and thank you for your efforts. However if you want to offload
> this then I will find some time to go through a couple of revisions.
> It would be Tuesday or Wednesday next week all being well.
> This is a pretty trivial driver so there's only limited scope for me
> messing it up (hopefully), and the lack of HDMI HPD is a stumbling
> block for Pi3/CM3.
> 
> Can I get a couple of answers from others as to preferences first?
> 
> Sorry Eric, I wasn't aware you had previously sent a patch
> implementing any of this otherwise I would have taken it as a base.
> I'd seen a comment that you were thinking about it but that was all.
> So which patch is preferred as the base? Eric's or mine?
> 
> Eric's patch had the driver in the main tree vs Michael putting it in
> staging. Where do we really want this going?
> Linus Walleij as one of the GPIO maintainers had reviewed Eric's patch
> and not totally dismissed it, so are we better off picking up on the
> comments from both review threads and aiming to merge directly to
> drivers/gpio?
> 
> 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.

Btw userspace shouldn't rely on those GPIO numbers.

Stefan