[PATCH v3 0/5] Add Type-C DP support for RK3399 EVB IND board

[Chaoyi Chen]

On 8/5/2025 6:44 PM, Dmitry Baryshkov wrote:

> On Tue, Aug 05, 2025 at 02:32:17PM +0800, Chaoyi Chen wrote:
>> Hi Dmitry,
>>
>> On 8/5/2025 12:26 PM, Dmitry Baryshkov wrote:
>>> On 05/08/2025 09:13, Chaoyi Chen wrote:
>>>> Hi Dmitry,
>>>>
>>>> On 8/2/2025 5:55 PM, Dmitry Baryshkov wrote:
>>>>
>>>> [...]
>>>>
>>>>
>>>>>>>> BTW, one of the important things to do is to implement extcon-like
>>>>>>>> notifications. I found include/drm/bridge/aux-bridge.h , but if the
>>>>>>>> aux-bridge is used, the bridge chain would look like this:
>>>>>>>>
>>>>>>>> PHY0 aux-bridge ---+
>>>>>>>>                       | ----> CDN-DP bridge
>>>>>>>> PHY1 aux-bridge ---+
>>>>>>>>
>>>>>>>> Oh, CDN-DP bridge has two previous aux-bridge!
>>>>>>>>
>>>>>>>> Now, I try to use drm_connector_oob_hotplug_event() to notify HPD
>>>>>>>> state between PHY and CDN-DP controller.
>>>>>>> Does it actually work? The OOB HPD event will be repoted
>>>>>>> for the usb-c
>>>>>>> connector's fwnode, but the DP controller isn't
>>>>>>> connected to that node
>>>>>>> anyhow. If I'm not mistaken, the HPD signal will not
>>>>>>> reach DP driver in
>>>>>>> this case.
>>>>>> Yes.  What you mentioned is the case in
>>>>>> drivers/usb/typec/altmodes/displayport.c . I have also added
>>>>>> a new OOB event
>>>>>> notify in the PHY driver in Patch 3, where the expected
>>>>>> fwnode is used in
>>>>>> the PHY. So now we have two OOB HPD events, one from
>>>>>> altmodes/ displayport.c
>>>>>> and the other from PHY. Only the HPD from PHY is eventually
>>>>>> passed to the DP
>>>>>> driver.
>>>>> This way you will loose IRQ_HPD pulse events from the DP. They are used
>>>>> by DPRX (aka DP Sink) to signal to DPTX (DP Source) that there was a
>>>>> change on the DPRX side and the DPTX should reread link params
>>>>> and maybe
>>>>> retrain the link.
>>>> Sorry, I still don't quite understand your point. I think the entire
>>>> notification path is as follows:
>>>>
>>>> Type-C mux callback -> RK3399 USBDP PHY -> PHY calls
>>>> drm_connector_oob_hotplug_event() -> DP driver
>>>>
>>>> Are you concerned that the IRQ_HPD event is not being handled
>>>> somewhere along the path? Is it that the Type-C mux callback didn't
>>>> notify the PHY, or that after the PHY passed the event to the DP
>>>> driver via the OOB event, the DP driver didn't handle it?
>>> The IRQ_HPD is an event coming from DPRX, it is delivered as a part of
>>> the attention VDM, see DP_STATUS_IRQ_HPD. It's being handled by the
>>> altmode displayport.c driver and is then delivered as an OOB hotplug
>>> call. However, it's not a mux event, so it is not (and it should not)
>>> being broadcasted over the typec_mux devices.
>>>
>>> The way we were handling that is by having a chain of drm_aux_bridges
>>> for all interim devices, ending up with a drm_dp_hpd_bridge registered
>>> by the TCPM. This way when the DPRX triggers the IRQ_HPD event, it is
>>> being handled by the displayport.c and then delivered through that
>>> bridge to the DP driver.
>> I think the issue goes back to the beginning. The key is to reuse the logic
>> in displayport.c, and the previous approach of directly setting the fwnode
>> has already been rejected. Is it a good idea to register the aux hpd bridge
>> in displayport.c? In this way, we don't need to register it with a bunch of
>> PD drivers (such as fusb302), which seems like a more generic solution.
> displayport.c comes into play only when you actually attach a DP dongle,
> which is too late for bringing up the display pipeline. But your point
> is valid, it might be worth moving drm_dp_hpd registration to
> typec_port_register_altmode().

Very insightful, thank you! I will try to do this in v4 :)