OMAP4 Panda DVI problem

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.

Hi Tomi,

Quoted 36 lines · Tomi Valkeinen

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).

Quoted 2 lines

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.

Quoted 4 lines

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)

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.

Quoted 4 lines

Quoted 2 lines

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.

Quoted 4 lines · Tony Lindgren

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.

Quoted 3 lines

Quoted 3 lines

Quoted 2 lines

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

Quoted 4 lines

Quoted 1 line

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.

Quoted 4 lines · Tony Lindgren

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".