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

Tomi Valkeinen tomi.valkeinen at ti.com
Thu Mar 21 13:12:03 UTC 2019


On 21/03/2019 00:58, Andrey Smirnov wrote:

> Regardless of how it's going to be implemented in the end, there'd
> have to be a way to specify which HPD input is being used. Which means

True.

> a either a new DT binding or re-using already existing to be agreed on
> by DT folks. It just seems to me that there exists a much stronger
> case to solve this using existing "language" of GPIO references as
> opposed to introducing some vendor specific binding serving just this
> single purpose. If DT is supposed to be used to describe the HW, then,
> IMHO, it might be the other way around, TC358767 is also a GPIO
> expander and has to be modeled/implemented as such, whether anyone
> would ever use it in such capacity fully isn't that significant.

Yep. But few points:

- TC358767 node will expose gpios and then it uses them itself. It does
look slightly silly in the DT data =). It's not often when you create a
reference from a node to itself.

- This also needs irqchip implemention to support HPD irq. I have never
written one, but I presume it's not too complex, but not trivial either.

- All this adds quite a big amount of code, compared to only few lines
of code if this is done internally.

>> Then we have two cases 1) HPD connected to TC358767, 2) HPD goes
>> directly to the SoC, or worded differently, HPD is handled by something
>> else than TC358767.
>>
>> 1) was implemented in this current patch, and there's no real benefit
>> with the gpiochip. It's somewhat confusing that the driver provides a
>> gpiochip which the same driver then uses, for its internal functionality.
>>
>> 2) should actually not involve TC358767 driver at all as it's totally
>> outside TC358767.
>>
> 
> There's already precedent for such usage in ti-tfp410.c, analogix/ and
> andanalogix-anx78xx.c, so it's not unheard of.

Yes, but I believe the direction has been to move away from that.

>> If the HPD goes from the DP connector to the SoC, we should have the DP
>> connector driver handle it. Currently that connector is in the TC358767
>> driver, but it should really be separated.
>>
> 
> Sure, there's definitely more than one way to solve this.
> 
>> So... Obviously what's missing from the current patch is that we need to
>> be able to say which of the two GPIOs are used for the HPD (if any). But
>> I'm debating with myself whether gpiochip here is a sane choice or not.
> 
> Yeah, maybe it'd be best to submit a patch to DT mailing list and see
> what they have to say?

Yep. I'll write the irchip support too, out of interest, and see what it
looks like. But this has the feel of over-engineering.

 Tomi

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


More information about the dri-devel mailing list