[PATCH 1/6] bcm2835-gpio-exp: Driver for GPIO expander via mailbox service
mzoran at crowfest.net
Mon Mar 20 11:54:22 PDT 2017
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
> adding for testing is the VC4 driver fully driving the display. Is
> still in the .config that you used? Is this a standard version of
> 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.
More information about the linux-rpi-kernel