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@xxxxxxxxxxxx> 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. _______________________________________________ devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxx http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
