[21/21] drm/bridge: tc358767: implement naive HPD handling

[Tomi Valkeinen]

On 19/03/2019 20:18, Andrey Smirnov wrote:

> TC358767 has two GPIO pins that can be used for HPD signal. I think
> instead of hardcoding GPIO0 here it would be more flexible to expose
> boths gpios as a gpiochip and use gpiolib API to query the value of
> HPD as well as use "hpd-gpios" binidng in DT to select which input to
> use.
> 
> Another argument in favour of this solution is that Toshiba's FAEs (at
> least some) recommend thier customers to connect HPD signal to SoC's
> GPIOs and bypass TC358767 entirely. Their reasoning being that
> TC358767 implements a generic GPIO contoller and there's no advantage
> in going through TC358767 if you could use your "normal" GPIOs.
> 
> Using gpiolib API would allow us to handle both usecase with the same
> code.
> 
> Lastly, by treating "hpd-gpios" as an optional property, we can
> preserve old driver behaviour regardless if it is connected to DP or
> eDP panel. Not saying that this is really worth doing, just pointing
> out that this option would be on the table as well.

I think that's a good point.

There's one thing that TC358767 offers, which may not be available on
most generic GPIO controllers, though: it can detect short (programmable
length) pulses, thus it's possible to easily implement the DisplayPort
IRQ mechanism. I'm not sure if it's possible to implement reliable DP
IRQ detection without HW support.

Still, I think using standard gpios makes sense.

 Tomi

-- 
Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki.
Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki