linux-kernel - Re: [PATCH 3/3] drm/omap: displays: encoder-tpd12s015: Support for hot plug detection

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <e89a3405-5fe0-d9c5-2365-abe14766c1a4@ti.com>
Date:   Tue, 23 May 2017 14:23:37 +0300
From:   Tomi Valkeinen <tomi.valkeinen@...com>
To:     Laurent Pinchart <laurent.pinchart@...asonboard.com>
CC:     Peter Ujfalusi <peter.ujfalusi@...com>, <airlied@...ux.ie>,
        <jsarha@...com>, <dri-devel@...ts.freedesktop.org>,
        <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH 3/3] drm/omap: displays: encoder-tpd12s015: Support for
 hot plug detection

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

Download attachment "signature.asc" of type "application/pgp-signature" (820 bytes)