On 04/12/2017 03:03 PM, Hans Verkuil wrote: > Hi Tomi, > > On 04/10/2017 01:59 PM, Tomi Valkeinen wrote: >> On 08/04/17 13:11, Hans Verkuil wrote: >> >>> So, this is a bit of a blast from the past since the omap4 CEC development >>> has been on hold for almost a year. But I am about to resume my work on this >>> now that the CEC framework was merged. >>> >>> The latest code is here, if you are interested: >>> >>> https://git.linuxtv.org/hverkuil/media_tree.git/log/?h=panda-cec >>> >>> It's pretty much unchanged from the version I posted a year ago, just rebased. >>> >>> But before I continue with this I have one question for you. First some >>> background: >>> >>> There is a special corner case (and I wasn't aware of that a year ago!) where >>> it is allowed to send a CEC message when there is *no HPD*. >>> >>> The reason is that some displays turn off the hotplug detect pin when they go >>> into standby or when another input is active. The only way to communicate with >>> such displays is via CEC. >>> >>> The problem is that without a HPD there is no EDID and basically no way for an >>> HDMI transmitter to detect that something is connected at all, unless you are >>> using CEC. >>> >>> What this means is that if we want to implement this on the omap4 the CEC support >>> has to be on all the time. >>> >>> We have seen modern displays that behave like this, so this is a real issue. And >>> this corner case is specifically allowed by the CEC specification: the Poll, >>> Image/Text View On and the Active Source messages can be sent to a TV even when >>> there is no HPD in order to turn on the display if it was in standby and to make >>> us the active input. >>> >>> The CEC framework in the kernel supports this starting with 4.12 (this code is >>> in the panda-cec branch above). >>> >>> If this *can't* be supported by the omap4, then I will likely have to add a CEC >>> capability to signal to the application that this specific corner case is not >>> supported. >>> >>> I just did some tests with omap4 and I my impression is that this can't be >>> supported: when the HPD goes away it seems like most/all of the HDMI blocks are >>> all powered off and any attempt to even access the CEC registers will fail. >>> >>> Changing this looks to be non-trivial if not impossible. >>> >>> Can you confirm that that isn't possible? If you think this can be done, then >>> I'd appreciate if you can give me a few pointers. >> >> HPD doesn't control the HW, it's all in the SW. So while I don't know >> much at all about CEC and haven't looked at this particular use case, I >> believe it's doable. HPD going off will make the DRM connector to be in >> "disconnected" state, which on omapdrm will cause everything about HDMI >> to be turned off. >> >> Does it work on some other DRM driver? I'm wondering if there's >> something in the DRM framework side that also has to be changed, in >> addition to omapdrm changes. >> >> It could require larger SW redesigns, though... Which makes me think >> that the work shouldn't be done until we have changed the omapdrm's >> driver model to DRM's common bridge driver model, and then all this >> could possibly be done in a more generic manner. >> >> Well, then again, I think the hdmi driver's internal power state >> handling could be improved even before that. Currently it's not very >> versatile. We should have ways to partially enable the IP for just the >> required parts. > > I noticed while experimenting with this that tpd_disconnect() in > drivers/gpu/drm/omapdrm/displays/encoder-tpd12s015.c isn't called when > I disconnect the HDMI cable. Is that a bug somewhere? > > I would expect that tpd_connect and tpd_disconnect are balanced. The tpd_enable > and tpd_disable calls are properly balanced and I see the tpd_disable when I > disconnect the HDMI cable. > > The key to keeping CEC up and running, even when there is no HPD is to keep > the hdmi.vdda_reg regulator enabled. Also the HDMI_IRQ_CORE should always be > on, otherwise I won't get any CEC interrupts. > > So if the omap4 CEC support is enabled in the kernel config, then always enable > this regulator and irq, and otherwise keep the current code. And of course the ls_oe_gpio in tpd12s015.c should always be high as well, otherwise the CEC signal would never get through. This too can depend on the kernel config. Hans > > Does that look sensible to you? > > Regards, > > Hans >
