Eric Anholt offically announces support of VC4 without access to expander on the RPI 3
Eric Anholt
eric at anholt.net
Tue Mar 21 10:34:08 PDT 2017
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.
-------------- 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/eabf551a/attachment.sig>
More information about the linux-rpi-kernel
mailing list