On 28 June 2012 20:57, Tomi Valkeinen <tomi.valkeinen@xxxxxx> wrote: > On Thu, 2012-06-28 at 20:44 +0530, Jassi Brar wrote: >> 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). > OK, somehow I was under impression you didn't wanna spare even the 5V+ floating. Though there could also be some option in settings to enable 5/HPD only when the user is about the connect a display... so that the activate window is even narrowed down. Anyway... I am glad we are in sync. >> > 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. > I meant before stale-edid, we face potential problem of omapdss behaving badly to the displays switched during suspend ? -- To unsubscribe from this list: send the line "unsubscribe linux-fbdev" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
