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

[Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>]

On 05/08/2025 09:13, Chaoyi Chen wrote:
> Hi Dmitry,
> 
> On 8/2/2025 5:55 PM, Dmitry Baryshkov wrote:
> 
> [...]
> 
> 
>>> Currently, the software simply selects the first available port. So 
>>> if user
>>> plugs in DP dongles in both USB-C ports, the DP driver will select 
>>> the first
>>> port. This process is implemented in cdn_dp_connected_port() .
>>>
>> I think Stephen Boyd has been looking on similar issues for Chromebooks,
>> which were sharing DP controller between several USB-C ports. I don't
>> remember what was his last status. I think there it was easier since the
>> bifurcation point was the EC.
> 
> I think the latest progress should be here: [0]. It seems that it hasn't 
> been updated for a while.

Might be :-(

> 
> [0]: https://lore.kernel.org/all/20240901040658.157425-1- 
> swboyd@chromium.org/
> 
> 
>>
>> I think, CDN-DP needs to register up to two encoders and up to two
>> connectors, having a separate drm_bridge chain for each of the DP
>> signals paths (in the end, you can not guarantee that both branches will
>> have the same simple CDN-DP -> PHY -> USB-C configuration: there can be
>> different retimers, etc).
>>
>> Both encoders should list the same CRTC in possible_crtcs, etc. Of
>> course, it should not be possible to enable both of them.
>>
>> This way if the user plugs in two DP dongles, it would be possible to
>> select, which output actually gets a signal.
> 
> That makes sense, but this might make the DP driver quite complex. I 
> will see if I can make it happen.

I think it's trading one burden for another, because CDN-DP currently 
has a complication of calling cdn_dp_get_port_lanes() / 
cdn_dp_enable_phy() in a loop rather than just enabling one instance.

> 
> 
>>
>>>
>>>>> 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.

-- 
With best wishes
Dmitry

-- 
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy