Re: Eric Anholt offically announces support of VC4 without access to expander on the RPI 3

[Eric Anholt <eric@anholt.net>]

[-- Attachment #1: Type: text/plain, Size: 2896 bytes --]

Michael Zoran <mzoran@crowfest.net> writes:

> On Mon, 2017-03-20 at 10:22 -0700, Eric Anholt wrote:
>> Michael Zoran <mzoran@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.
>
> 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.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 832 bytes --]