On Thu, 2012-06-28 at 20:03 +0800, Andy Green wrote: > On 06/28/12 19:10, the mail apparently from Tomi Valkeinen included: > > For this to work like you want we need a bigger restructuring of HDMI > > and partly omapdss also. Currently we have just one big "enabled" or > > "disabled" state. We need multiple states. Probably something like: > > > > - disabled, everything totally off > > - low power, hotplug detection enabled > > - powered on, but no video > > - video enabled > > > > Been long in my mind, but I'm not very familiar with HDMI so I could get > > my simple prototypes to work when I tried something like this once. > > That doesn't sound too hard since the difference between the first three > states at the HDMI chip is just whether the two gpio controlling it are > 00, 10 or 11. I don't think it's that simple. We should be able to do EDID read on one of the states, perhaps second or third. For that we need parts of the HDMI IP to be enabled. Also, the third state should be something where the IP is fully functional. For DSI this would mean that you can communicate over DSI bus etc. So I guess EDID read should be possible at this level. > If Jassi's alright with it we might have a go at implementing this, but > can you define a bit more about how we logically tell DSS that we want > to, eg, disable HDMI totally? Disabling HDMI is easy, it's already done by the disable call. And the same for the video enabled mode. The middle ones are the ones that need implementation. And for HDMI, there's currently no way to enable it partially. This is what I tried with my quick hack, but I couldn't figure out what parts need to be enabled (but I didn't spend much time on it). This is something that should be implemented for all outputs, obviously, but we could approach it bit by bit. For example, implement it first for HDMI, and all other outputs just consider anything else than "disabled" as full enable. Tomi
Attachment:
signature.asc
Description: This is a digitally signed message part
