Hi, On Wed, Feb 28, 2024 at 8:52 AM <neil.armstrong@xxxxxxxxxx> wrote: > > On 28/02/2024 17:40, Doug Anderson wrote: > > Neil, > > > > On Thu, Feb 15, 2024 at 8:53 AM Neil Armstrong > > <neil.armstrong@xxxxxxxxxx> wrote: > >> > >> Hi Doug, > >> > >> On 15/02/2024 16:08, Doug Anderson wrote: > >>> Hi, > >>> > >>> On Thu, Feb 15, 2024 at 2:24 AM Jani Nikula <jani.nikula@xxxxxxxxx> wrote: > >>>> > >>>> 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? > >>> > >>> I'd be more than happy for one of the drm-misc maintainers to Ack. > >>> I'll move Maxime, Thomas, and Maarten to the "To:" line to see if that > >>> helps get through their filters. > >> > >> I'll like some test reports to be sure it doesn't break anything, > >> then I'll be happy to give my ack ! > > > > Are you looking for any more test reports at this point? Eizan did > > some testing and provided a tag, though this was also on ChromeOS. > > Steev also tested on two non-ChromeOS environments and provided his > > tag. It's also been another two weeks of this being rolled out to some > > Chromebook users and I haven't heard any reports of problems. If > > somehow something was missed, I'm happy to follow-up and provide > > additional fixes if some report comes in later. > > Sure, thx I think you can apply it now > > Acked-by: Neil Armstrong <neil.armstrong@xxxxxxxxxx> Pushed to drm-misc-next. 8df1ddb5bf11 drm/dp: Don't attempt AUX transfers when eDP panels are not powered
