Re: [PATCH 3/3] OMAPDSS: HDMI: Cache EDID

On Thu, 2012-06-28 at 20:44 +0530, Jassi Brar wrote:

I won't press further with my Utopian ideas, but I think we need to
segregate 5V/HPD enabling from PHY enabling somehow. Because that is
already failing slow but otherwise perfectly legit displays (like
Andy's "HPD taking 700ms" TV)

Yes, I agree. That's what the four power states I suggested in the other
mail were about. The second power state would have HPD enabled, and the
third would enable the PHY. Or at least enough to do i2c transfers, I'm
not sure if the PHY is needed for that.

quoted

And also, as I said earlier, if you keep it enabled all the time, it'll
eat power even if the user is never going to use HDMI.

On a desktop I guess the power consumption wouldn't be an issue, but I
do feel a bit uneasy about it on an embedded device.

As I said, it should be platform dependent. If a device doesn't have
HDMI port, the board file would not even have platform_enable. And if

Not that it's relevant here, but I have a patch series where I remove
the platform_enable stuff for HDMI, and move the work to the hdmi
driver. That needs to be done for device tree stuff, when we don't have
board files.

it has, some user action should enable it while 'making the device
ready for new display'.
IOW, how do you envision an OMAP4 based tablet with HDMI port react to
display connections ?

I guess this was covered in my mail about the phone's HDMI. If the
tablet is unlocked, and I plug in a HDMI cable, I expect the device to
do something. Either clone the display, or perhaps ask me what I want to
do.

So yes, HPD would be always enabled, when the tablet is active
(unlocked).

quoted

quoted

HDMI enable/disable via /sysfs/ and HPD (de)assertion, switch only
HDMI_PHY on/off.
The user selecting "Autodetect and Configure" option would then equate
to "(un)loading" of the HDMI driver.

HDMI cannot be currently compiled as a separate module. Although I think
you can detach a device and a driver, achieving the same. Is that what
you meant with unloading?

Yeah, I meant something to the effect of bringing HDMI driver to life.

quoted

By the way, when the device is in system suspend, we surely won't detect
the HPD even if we kept the HPD always enabled. So there we'll miss the
HPD interrupt anyway, and the EDID cache would be invalid.

If omapdss already handles the possibility of display changed during
suspend, I think we should be good :)

Hmm I'm not sure I understand what you mean. I was referring to your
patch, which invalidated the EDID cache only on HPD interrupt when the
cable is unplugged. And we'd miss that interrupt when the board is in
system suspend, even if we otherwise kept the HPD interrupt always
enabled.

 Tomi