On Mon, 2017-03-20 at 11:54 -0700, Michael Zoran wrote: > 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. Since Stefan always has such interesting comments on patches and I've submitting changes to a driver that doesn't even offically load, perhaps someone can help me get one of the TODO items removed and make real progress getting this driver out of staging by sending me a real e-mail address of who I should send an actual working DT for the RPI 3 to that will actually be seriously considered. I'll leave it at that. Thanks. _______________________________________________ devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxx http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
