On 23/05/17 13:42, Laurent Pinchart wrote: > Hi Tomi, > > On Tuesday 23 May 2017 13:25:34 Tomi Valkeinen wrote: >> On 23/05/17 12:48, Laurent Pinchart wrote: >>> As the connector code can handle GPIO HPD thanks to patch 2/3, why does it >>> have to be duplicated here ? I agree that encoders should support >>> reporting of hotplug events when the HPD signal is connected to an >>> encoder, but if it's connected to a GPIO, it seems to me that it should >>> be the sole responsibility of the connector code to handle it. >> >> The HPD line goes from the connector to TPD12S015. From TPD12S015 >> another line goes to the SoCs GPIO. > > Isn't it the same signal, just with glitches filtered ? The TPD12S015 is an > ESD clamp, level shifter and DC-DC converter, if it wasn't for the two control > inputs CT_CP_HPD and LS_OE, we could probably do without a driver. I wouldn't > add HPD support to this driver, as the chip really can't detect HPD. Yes, it is the same signal, level shifted and filtered, if I'm not mistaken. The HPD gpio is defined in TPD's DT data. And can we know what is the state of the HPD signal when TPD hasn't configured CT_CP_HPD and LS_OE. Will there be a glitch when CT_CP_HPD is enabled? What if connector-hdmi is already listening to HPD signal at that point? My guess is that having gpio handling just in the connector would work, especially as we set the CT_CP_HPD very early when TPD is being set up. With this series we could probably do a bit more optimized management for CT_CP_HPD, but probably we could still make sure the sequence is such that the CT_CP_HPD is enabled before connector-hdmi registers the irq. But that doesn't sound quite correct to me... I do think it's TPD driver's responsibility, and it removes all the "make sure that"'s. Tomi
Attachment:
signature.asc
Description: OpenPGP digital signature
_______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/dri-devel
