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(). -- With best wishes Dmitry
