OMAP4 Panda DVI problem

OMAP4 Panda DVI problem

[Tomi Valkeinen]

[-- Attachment #1: Type: text/plain, Size: 2002 bytes --]

Hi Tony, Roger,

I recently raised the i2c issue with reading EDID from a DVI monitor on
Panda, when booting with DT. I just couldn't get reading EDID work at
all reliably.

I now see problems with non-DT also. Booting with 3.10-rc5, with DSS
compiled into the kernel, reading EDID fails during the boot. I can
later read the EDID fine from userspace.

With help from Roger, we found the issue.

DVI cable has a +5V line, that the source (i.e. Panda) has to provide.
This +5V is required to read EDID, but according to the documentation I
think it's actually required to show video also (although I guess this
could depend on the monitor).

I think for OMAP3 boards the +5V is always-on (I haven't looked at OMAP3
boards yet, though). For Panda, the +5V comes from DC_HST_5V, controlled
with a GPIO, which is used for USB and currently managed by USB in
arch/arm/mach-omap2/usb-host.c, which creates a fixed voltage hsusbX_vcc
regulator.

So, basically, if USB is disabled, DVI doesn't work. This is why I see
problems with DT (no USB), and non-DT (USB enabled after DVI is enabled).

To fix this properly I need to add regulator handling to the DVI driver,
and we need to share the same supply with USB and DVI.

However, while the above shouldn't be particularly difficult, it's still
not simple. And additional complications come with DT boot, as DSS
doesn't support DT yet. We have the hack that enables DSS for Panda and
SDP board when booting with DT, but I don't think it's possible to
manage the shared regulator easily in that setup (ie. USB and the
regulator being described in DT, DSS and DVI added the old way in
dss-common.c).

So I think the simplest solution is to make DC_HST_5V always-on. This
should be fixed for 3.10 also.

Any idea if DC_HST_5V is a big power sink if it's always enabled? If
it's a big one, I could look at how to hack the DVI driver so that it
would find the regulator. I'm quite sure I won't be neat, though.

 Tomi


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 901 bytes --]

Re: OMAP4 Panda DVI problem

[Roger Quadros]

Hi Tomi,

On 06/14/2013 04:52 PM, Tomi Valkeinen wrote:
> Hi Tony, Roger,
> 
> I recently raised the i2c issue with reading EDID from a DVI monitor on
> Panda, when booting with DT. I just couldn't get reading EDID work at
> all reliably.
> 
> I now see problems with non-DT also. Booting with 3.10-rc5, with DSS
> compiled into the kernel, reading EDID fails during the boot. I can
> later read the EDID fine from userspace.
> 
> With help from Roger, we found the issue.
> 
> DVI cable has a +5V line, that the source (i.e. Panda) has to provide.
> This +5V is required to read EDID, but according to the documentation I
> think it's actually required to show video also (although I guess this
> could depend on the monitor).
> 
> I think for OMAP3 boards the +5V is always-on (I haven't looked at OMAP3
> boards yet, though). For Panda, the +5V comes from DC_HST_5V, controlled
> with a GPIO, which is used for USB and currently managed by USB in
> arch/arm/mach-omap2/usb-host.c, which creates a fixed voltage hsusbX_vcc
> regulator.
> 
> So, basically, if USB is disabled, DVI doesn't work. This is why I see
> problems with DT (no USB), and non-DT (USB enabled after DVI is enabled).
> 
> To fix this properly I need to add regulator handling to the DVI driver,
> and we need to share the same supply with USB and DVI.
> 
> However, while the above shouldn't be particularly difficult, it's still
> not simple. And additional complications come with DT boot, as DSS
> doesn't support DT yet. We have the hack that enables DSS for Panda and
> SDP board when booting with DT, but I don't think it's possible to
> manage the shared regulator easily in that setup (ie. USB and the
> regulator being described in DT, DSS and DVI added the old way in
> dss-common.c).
> 
> So I think the simplest solution is to make DC_HST_5V always-on. This
> should be fixed for 3.10 also.

I am fine with this.

> 
> Any idea if DC_HST_5V is a big power sink if it's always enabled? If
> it's a big one, I could look at how to hack the DVI driver so that it
> would find the regulator. I'm quite sure I won't be neat, though.
> 

DC_HST_5V is going to be active if USB is active. So I wouldn't be much
worried if this supply is left always ON for people needing USB host &
ethernet. (NOTE, ethernet is part of the same USB hub chip)

cheers,
-roger

Re: OMAP4 Panda DVI problem

[Tony Lindgren]

* Roger Quadros <rogerq@ti.com> [130617 01:18]:
> Hi Tomi,
> 
> On 06/14/2013 04:52 PM, Tomi Valkeinen wrote:
> > Hi Tony, Roger,
> > 
> > I recently raised the i2c issue with reading EDID from a DVI monitor on
> > Panda, when booting with DT. I just couldn't get reading EDID work at
> > all reliably.
> > 
> > I now see problems with non-DT also. Booting with 3.10-rc5, with DSS
> > compiled into the kernel, reading EDID fails during the boot. I can
> > later read the EDID fine from userspace.
> > 
> > With help from Roger, we found the issue.
> > 
> > DVI cable has a +5V line, that the source (i.e. Panda) has to provide.
> > This +5V is required to read EDID, but according to the documentation I
> > think it's actually required to show video also (although I guess this
> > could depend on the monitor).
> > 
> > I think for OMAP3 boards the +5V is always-on (I haven't looked at OMAP3
> > boards yet, though). For Panda, the +5V comes from DC_HST_5V, controlled
> > with a GPIO, which is used for USB and currently managed by USB in
> > arch/arm/mach-omap2/usb-host.c, which creates a fixed voltage hsusbX_vcc
> > regulator.
> > 
> > So, basically, if USB is disabled, DVI doesn't work. This is why I see
> > problems with DT (no USB), and non-DT (USB enabled after DVI is enabled).
> > 
> > To fix this properly I need to add regulator handling to the DVI driver,
> > and we need to share the same supply with USB and DVI.
> > 
> > However, while the above shouldn't be particularly difficult, it's still
> > not simple. And additional complications come with DT boot, as DSS
> > doesn't support DT yet. We have the hack that enables DSS for Panda and
> > SDP board when booting with DT, but I don't think it's possible to
> > manage the shared regulator easily in that setup (ie. USB and the
> > regulator being described in DT, DSS and DVI added the old way in
> > dss-common.c).

You should be able to get the regulator based on the name just fine
from the drivers even if one driver is using DT and one is not. That is
as long as the regulator is defined. Then the regulator fwk will track
the usecount properly.

> > So I think the simplest solution is to make DC_HST_5V always-on. This
> > should be fixed for 3.10 also.
> 
> I am fine with this.

For a short term fix I'm fine with that, but please investigate using
the regulator, it might be simpler than you think.

> > Any idea if DC_HST_5V is a big power sink if it's always enabled? If
> > it's a big one, I could look at how to hack the DVI driver so that it
> > would find the regulator. I'm quite sure I won't be neat, though.
> > 
> 
> DC_HST_5V is going to be active if USB is active. So I wouldn't be much
> worried if this supply is left always ON for people needing USB host &
> ethernet. (NOTE, ethernet is part of the same USB hub chip)

Of course power management will suffer, but it's currently not working
with EHCI anyways AFAIK.

Regards,

Tony

Re: OMAP4 Panda DVI problem

[Tomi Valkeinen]

[-- Attachment #1: Type: text/plain, Size: 1347 bytes --]

On 17/06/13 14:18, Tony Lindgren wrote:

> You should be able to get the regulator based on the name just fine
> from the drivers even if one driver is using DT and one is not. That is
> as long as the regulator is defined. Then the regulator fwk will track
> the usecount properly.

Doesn't the regulator need to be "bound" to a device for the driver to
use the proper name for the regulator? I mean, in this case the dvi
driver wants to get a regulator named "vdd_5v" (or something like that,
I'm not sure what's the proper name). The USB host driver uses a name
"vcc", while the real name of the regulator is "hsusbX_vcc".

If DVI driver wanted to use the regulator, it'd need to get
"hsusbX_vcc". Which, I presume, would work, but is board specific and
hacky, and it makes handling EPROBE_DEFER a bit more difficult.

Then again, maybe that's still simpler than making the regulator
always-on, as there are complications with that approach also, which we
are currently studying.

>>> So I think the simplest solution is to make DC_HST_5V always-on. This
>>> should be fixed for 3.10 also.
>>
>> I am fine with this.
> 
> For a short term fix I'm fine with that, but please investigate using
> the regulator, it might be simpler than you think.

I'll have a look, maybe there's something I'm missing.

 Tomi



[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 901 bytes --]

Re: OMAP4 Panda DVI problem

[Tony Lindgren]

* Tomi Valkeinen <tomi.valkeinen@ti.com> [130617 04:34]:
> On 17/06/13 14:18, Tony Lindgren wrote:
> 
> > You should be able to get the regulator based on the name just fine
> > from the drivers even if one driver is using DT and one is not. That is
> > as long as the regulator is defined. Then the regulator fwk will track
> > the usecount properly.
> 
> Doesn't the regulator need to be "bound" to a device for the driver to
> use the proper name for the regulator? I mean, in this case the dvi
> driver wants to get a regulator named "vdd_5v" (or something like that,
> I'm not sure what's the proper name). The USB host driver uses a name
> "vcc", while the real name of the regulator is "hsusbX_vcc".

I think that's for looking up regulators based on the dev entry, and also
name based lookup should work. But maybe I'm confusing it with the clock
framework. If you need to bind it to a device, you can do that too
dynamically I'd assume.

> If DVI driver wanted to use the regulator, it'd need to get
> "hsusbX_vcc". Which, I presume, would work, but is board specific and
> hacky, and it makes handling EPROBE_DEFER a bit more difficult.
> 
> Then again, maybe that's still simpler than making the regulator
> always-on, as there are complications with that approach also, which we
> are currently studying.
> 
> >>> So I think the simplest solution is to make DC_HST_5V always-on. This
> >>> should be fixed for 3.10 also.
> >>
> >> I am fine with this.
> > 
> > For a short term fix I'm fine with that, but please investigate using
> > the regulator, it might be simpler than you think.
> 
> I'll have a look, maybe there's something I'm missing.

Yes might be worth checking.

Regards,

Tony

Re: OMAP4 Panda DVI problem

[Roger Quadros]

On 06/17/2013 02:27 PM, Tomi Valkeinen wrote:
> On 17/06/13 14:18, Tony Lindgren wrote:
> 
>> You should be able to get the regulator based on the name just fine
>> from the drivers even if one driver is using DT and one is not. That is
>> as long as the regulator is defined. Then the regulator fwk will track
>> the usecount properly.
> 
> Doesn't the regulator need to be "bound" to a device for the driver to
> use the proper name for the regulator? I mean, in this case the dvi
> driver wants to get a regulator named "vdd_5v" (or something like that,
> I'm not sure what's the proper name). The USB host driver uses a name
> "vcc", while the real name of the regulator is "hsusbX_vcc".

Right. I think if the regulator is not bound to any device then you can
get it just by supply name.

http://lxr.free-electrons.com/source/drivers/regulator/core.c#L1175

But the USB PHY driver will always try to get the regulator for it's device
that has supply name "vcc".

cheers,
-roger