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