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

[Eric Anholt]

Michael Zoran <mzoran at crowfest.net> writes:

> On Tue, 2017-03-21 at 10:34 -0700, Eric Anholt wrote:
>> Michael Zoran <mzoran at crowfest.net> writes:
>> 
>> > On Mon, 2017-03-20 at 10:22 -0700, Eric Anholt wrote:
>> > > Michael Zoran <mzoran at 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.
>
>
> Would a non DT based solution be outside the realm of possibilities?  I
> wrote a very simple library that emulates vcgencmd from the kernel. 
> One of the commands for vcgencmd is to query the HDMI hotplug status. 
> It's sort of semi documentated on the web.  The vcgencmd library works,
> but I haven't tested if the virtualized hotplug info from the command
> output is correct in all cases.
>
> What I'm thinking is I could package this in a single file library that
> would get put in upstream, but it would only support 1 command only. To
> query the virtual hotplug status.
>
> The only thing is you would need to take a dependency from VC4 to
> vchiq/vc04_services.  It would get VC4 working better on upstream, but
> it would mean taking a dependency from VC4 to vc04_services and the
> stagging tree(with all that imples).
>
> I think this may be a better solution then arguing with the DT folks on
> this expander driver that isn't being directly controlled.
>
> What do you think?

Not interested.  We should expose the full GPIO expander using the
firmware's GPIO expander interfaces, which is a more generally useful
solution.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 832 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-rpi-kernel/attachments/20170321/3c17f4c1/attachment.sig>