On Tue, Mar 18, 2025 at 05:49:54PM +0200, Tomi Valkeinen wrote: > Hi, > > On 12/03/2025 14:52, Dmitry Baryshkov wrote: > > On Wed, Mar 12, 2025 at 11:56:41AM +0530, Harikrishna Shenoy wrote: > > > > > > > > > On 05/02/25 19:03, Dmitry Baryshkov wrote: > > > > On Wed, Feb 05, 2025 at 12:52:52PM +0100, Krzysztof Kozlowski wrote: > > > > > On 05/02/2025 12:50, Harikrishna Shenoy wrote: > > > > > > From: Rahul T R <r-ravikumar@xxxxxx> > > > > > > > > > > > > The mhdp bridge can work without its HPD pin hooked up to the connector, > > > > > > but the current bridge driver throws an error when hpd line is not > > > > > > connected to the connector. For such cases, we need an indication for > > > > > > no-hpd, using which we can bypass the hpd detection and instead use the > > > > > > auxiliary channels connected to the DP connector to confirm the > > > > > > connection. > > > > > > So add no-hpd property to the bindings, to disable hpd when not > > > > > > connected or unusable due to DP0-HPD not connected to correct HPD > > > > > > pin on SOC like in case of J721S2. > > > > > > > > > > > > Signed-off-by: Rahul T R <r-ravikumar@xxxxxx> > > > > > > > > > > Why are you sending over and over the same? You already got feedback. > > > > > Then you send v2. You got the same feedback. > > > > > > > > > > Now you send v3? > > > > > > > > > > So the same feedback, but this time: NAK > > > > > > > > Krzysztof's email forced me to take a look at the actual boards that you > > > > are trying to enable. I couldn't stop by notice that the HPD signal > > > > _is_ connected to a GPIO pin. Please stop hacking the bridge driver and > > > > use the tools that are already provided to you: add the HPD pin to the > > > > dp-controller device node. And then fix any possible issues coming from > > > > the bridge driver not being able to handle HPD signals being delivered > > > > by the DRM framework via the .hpd_notify() callback. > > > > > > > > TL;DR: also a NAK from my side, add HPD gpio to dp-controller. > > > > > > > We tried implementing a interrupt based HPD functionality as HPD signal is > > > connected to GPIO0_18 pin, we were able to get interrupt based HPD working > > > however to route this signal to SoC we are loosing audio capability due to > > > MUX conflict. Due to board level limitations to > > > route the signal to SoC, we will not be able to support interrupt > > > based HPD and polling seems a possible way without loosing on audio > > > capability. > > > > Still NAK for the no-hpd property. HPD pin is a requirement for > > DisplayPort to work, as it is used e.g. for the 'attention' IRQs being > > sent by the DP sink. I'm not sure what kind of idea you HW engineers had > > in mind. > > It's true that for normal DP functionality the HPD is required, but afaik DP > works "fine" without HPD too. This is not the first board that has DP > connector, but doesn't have HPD, that I have seen or worked on. Polling can > be used for the IRQs too. Just out of curiosity, is there a DP host / bridge that provide polling for short HPD pulses (aka attention)? > For eDP HPD is optional, and some of the cases I've worked with involved a > chip intended for eDP, but used with a full DP connector, and no HPD. > However, in this particular case the DP chip supports full DP, so it's just > a board design error. In such a case, if I'm not mistaken, the no-hpd is a part of the panel interface rather than the eDP source. I see that SN65DSI86 has the no-hpd property, but if I understood Doug correctly it is used to change bridge's configuration rather than just skip the HPD processing. > My question is, is J721s2 EVM something that's used widely? Or is it a rare > board? If it's a rare one, maybe there's no point in solving this in > upstream? But if it's widely used, I don't see why we wouldn't support it in > upstream. The HW is broken, but we need to live with it. > > Another question is, if eDP support is added to the cdns-mhdp driver, and > used with a panel that doesn't have an HPD, how would that code look like? > If that would be solved with a "no-hpd" property, identical to the one > proposed in this series, then... There's even less reason to not support > this. > > Disclaimer: I didn't study the schematics, and I haven't thought or looked > at how eDP is implemented in other drm drivers. I hope that Doug can comment on eDP side. On the schematics side, there a multi-pin mux, which switches several GPIO pins. One of the positions of the mux is useful for audio connection. Unfortunately, DP HPD pin gets connected in a different mux positition. -- With best wishes Dmitry
