Michael Zoran writes: > On Mon, 2017-03-20 at 10:22 -0700, Eric Anholt wrote: >> Michael Zoran 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. > > Just a FYI, Eric Anholt has offically announced support for VC4 for > HDMI on mainline Linus build without any support from the expander on > the RPI 3. > > Sounds like this particular driver isn't needed then, correct? That's the HDMI audio that just landed. HDMI has been working on the pi3 since 9d44abbbb8d530e8cc97d71ffcbc0ff3b5553c62. In the absence of a GPIO line for hotplug detect, we use DDC, which is slower and throws an error in dmesg when the probe happens but HDMI is disconnected. As such, having a GPIO driver would improve things for people.