linux-kernel - 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-next>] [day] [month] [year] [list]

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

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?