On Wed, 14 Feb 2024, Doug Anderson <dianders@xxxxxxxxxxxx> wrote: > Hi, > > On Tue, Feb 13, 2024 at 10:25 PM Hsin-Yi Wang <hsinyi@xxxxxxxxxxxx> wrote: >> >> On Wed, Feb 14, 2024 at 2:23 PM Douglas Anderson <dianders@xxxxxxxxxxxx> wrote: >> > >> > If an eDP panel is not powered on then any attempts to talk to it over >> > the DP AUX channel will timeout. Unfortunately these attempts may be >> > quite slow. Userspace can initiate these attempts either via a >> > /dev/drm_dp_auxN device or via the created i2c device. >> > >> > Making the DP AUX drivers timeout faster is a difficult proposition. >> > In theory we could just poll the panel's HPD line in the AUX transfer >> > function and immediately return an error there. However, this is >> > easier said than done. For one thing, there's no hard requirement to >> > hook the HPD line up for eDP panels and it's OK to just delay a fixed >> > amount. For another thing, the HPD line may not be fast to probe. On >> > parade-ps8640 we need to wait for the bridge chip's firmware to boot >> > before we can get the HPD line and this is a slow process. >> > >> > The fact that the transfers are taking so long to timeout is causing >> > real problems. The open source fwupd daemon sometimes scans DP busses >> > looking for devices whose firmware need updating. If it happens to >> > scan while a panel is turned off this scan can take a long time. The >> > fwupd daemon could try to be smarter and only scan when eDP panels are >> > turned on, but we can also improve the behavior in the kernel. >> > >> > Let's let eDP panels drivers specify that a panel is turned off and >> > then modify the common AUX transfer code not to attempt a transfer in >> > this case. >> > >> > Signed-off-by: Douglas Anderson <dianders@xxxxxxxxxxxx> >> > --- >> >> Reviewed-by: Hsin-Yi Wang <hsinyi@xxxxxxxxxxxx> > > Thanks for the review! > > Given that this touches core DRM code and that I never got > confirmation that Jani's concerns were addressed with my previous > response, I'm still going to wait a little while before applying. I'm > on vacation for most of next week, but if there are no further replies > between now and then I'll plan to apply this to "drm-misc-next" the > week of Feb 26th. If someone else wants to apply this before I do then > I certainly won't object. Jani: if you feel this needs more discussion > or otherwise object to this patch landing then please yell. Likewise > if anyone else in the community wants to throw in their opinion, feel > free. Sorry for dropping the ball after my initial response. I simply have not had the time to look into this. It would be great to get, say, drm-misc maintainer ack on this before merging. It's not fair for me to stall this any longer, I'll trust their judgement. Reasonable? BR, Jani. -- Jani Nikula, Intel
