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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Tue, 21 Mar 2017 10:34:08 -0700
From:   Eric Anholt <eric@...olt.net>
To:     Michael Zoran <mzoran@...wfest.net>, linux-kernel@...r.kernel.org
Cc:     gregkh@...uxfoundation.org, devel@...verdev.osuosl.org,
        linux-rpi-kernel@...ts.infradead.org,
        Stefan Wahren <stefan.wahren@...e.com>
Subject: Re: Eric Anholt offically announces support of VC4 without access to expander on the RPI 3

Michael Zoran <mzoran@...wfest.net> writes:

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

Download attachment "signature.asc" of type "application/pgp-signature" (833 bytes)