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

[Michael Zoran]

On Mon, 2017-03-20 at 10:28 -0700, Michael Zoran wrote:
> On Mon, 2017-03-20 at 10:22 -0700, Eric Anholt wrote:
> > Michael Zoran <mzoran at crowfest.net> writes:
> > 
> > > > > Since the API is completely documented, I see no reason we or
> > > > > anybody
> > > > > couldn't essentially rewrite the driver while it's in
> > > > > staging.  I
> > > > > just
> > > > > think it would be best for everyone if the new version was a
> > > > > drop
> > > > > in
> > > > > replacement for the original version.  Essential an
> > > > > enhancement
> > > > > rather
> > > > > then a competitor.
> > > > 
> > > > I think my comments weren't fundamental changes, but you surely
> > > > mean
> > > > the devicetree ABI? I like to see this driver ASAP out of
> > > > staging
> > > > and
> > > > i'm not interested to maintain 2 functional identical driver
> > > > only
> > > > to
> > > > keep compability with the Foundation tree. Currently i'm afraid
> > > > that
> > > > we build up many drivers in staging, which need a complete
> > > > rewrite
> > > > later if they should come out of staging. It would be nice if
> > > > we
> > > > could avoid the situation we have with the thermal driver.
> > > > 
> > > > Stefan
> > > 
> > > The API I'm talking about here is the mailbox API that is used to
> > > talk
> > > to the firmware.  The numbers and structures to pass are
> > > documented. 
> > > Nothing prevents anybody from rewriting this driver and
> > > submitting
> > > it
> > > to the appropriate subsystems.  It's certainly small enough.
> > > 
> > > If you really want working thermal or cpu speed drivers today,
> > > nothing
> > > stops anybody from submitting the downstream drivers after doing
> > > some
> > > minor touchups and submitting them to staging.  That would at
> > > least
> > > get
> > > things working while people argue about what the correct DT nodes
> > > should be.
> > > 
> > > I would also like to point out that the RPI 3 has been out for
> > > over
> > > a
> > > year and nobody has been able to get working video out of it
> > > through
> > > VC4 on a mainline tree.  At least until now.  So I'm not sure the
> > > best
> > > way to go is for the expander driver to go under the GPIO
> > > subtree.
> > 
> > Excuse me?  Display works fine on my Pi3.  VC4 uses DDC to probe
> > for
> > connection when the GPIO line isn't present in the DT.
> 
> Is this arm32 or arm64 modes? And is this through the simplefb that
> was
> adding for testing is the VC4 driver fully driving the display.  Is
> VC4
> still in the .config that you used? Is this a standard version of
> VC4,
> or does it include modifications for testing purposes?
> 
> If it works so well as is, why do you need or want the expander?  You
> tried to submit a very similar version a year ago?

Since Stephan seems to have taken this sudden intense interest in
vc04_services all of a sudden, perhaps now would be a excellent time to
actually acomplish one of the TODOs and get the DT bindings in for this
driver.  Since it is working an all.