On Mon, 2017-03-20 at 10:22 -0700, Eric Anholt wrote:
> Michael Zoran <[email protected]> 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?
Michael Zoran <[email protected]> writes:
> On Mon, 2017-03-20 at 10:22 -0700, Eric Anholt wrote:
>> Michael Zoran <[email protected]> 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.
On Tue, 2017-03-21 at 10:34 -0700, Eric Anholt wrote:
> Michael Zoran <[email protected]> writes:
>
> > On Mon, 2017-03-20 at 10:22 -0700, Eric Anholt wrote:
> > > Michael Zoran <[email protected]> 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?
On Tue, 2017-03-21 at 12:09 -0700, Michael Zoran wrote:
> On Tue, 2017-03-21 at 10:34 -0700, Eric Anholt wrote:
> > Michael Zoran <[email protected]> writes:
> >
> > > On Mon, 2017-03-20 at 10:22 -0700, Eric Anholt wrote:
> > > > Michael Zoran <[email protected]> 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?
Just to clarify, this would be a soft dependency. We would have the
function in place on all RPI but it would only actually do something if
both vc04_services is in the .config AND vc04_services gets put into
the DT on the platforms that it would benefit the most at this time(The
RPI3).
The idea is that you would only use the function in the cases that you
don't have a better way to get the information such as directly polling
a GPIO pin.
I know vcgencmd supports of bunch of stuff, but the documentation is
fuzzy on the web so I would only be confortable supporting what is
absolutely needed and we know works well(In this case the HDMI hot
plug).
Michael Zoran <[email protected]> writes:
> On Tue, 2017-03-21 at 10:34 -0700, Eric Anholt wrote:
>> Michael Zoran <[email protected]> writes:
>>
>> > On Mon, 2017-03-20 at 10:22 -0700, Eric Anholt wrote:
>> > > Michael Zoran <[email protected]> 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.