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 :)
