Message-ID: <87frxskef7.fsf@minerva.mail-host-address-is-not-set>
Date: Fri, 16 Feb 2024 09:21:16 +0100
From: Javier Martinez Canillas <javierm@...hat.com>
To: Doug Anderson <dianders@...omium.org>, neil.armstrong@...aro.org
Cc: Jani Nikula <jani.nikula@...el.com>, Maxime Ripard <mripard@...nel.org>,
 Thomas Zimmermann <tzimmermann@...e.de>, Maarten Lankhorst
 <maarten.lankhorst@...ux.intel.com>, Hsin-Yi Wang <hsinyi@...omium.org>,
 dri-devel@...ts.freedesktop.org, eizan@...omium.org, Ankit Nautiyal
 <ankit.k.nautiyal@...el.com>, Daniel Vetter <daniel@...ll.ch>, David
 Airlie <airlied@...il.com>, Heiner Kallweit <hkallweit1@...il.com>, Imre
 Deak <imre.deak@...el.com>, Jessica Zhang <quic_jesszhan@...cinc.com>, Sam
 Ravnborg <sam@...nborg.org>, Stanislav Lisovskiy
 <stanislav.lisovskiy@...el.com>, linux-kernel@...r.kernel.org
Subject: Re: [PATCH] drm/dp: Don't attempt AUX transfers when eDP panels are
 not powered

Doug Anderson <dianders@...omium.org> writes:

Hello Doug,

> Hi,
>
> On Thu, Feb 15, 2024 at 8:53 AM Neil Armstrong
> <neil.armstrong@...aro.org> 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@...elcom> wrote:
>> >>
>> >> On Wed, 14 Feb 2024, Doug Anderson <dianders@...omium.org> wrote:
>> >>> Hi,
>> >>>
>> >>> On Tue, Feb 13, 2024 at 10:25 PM Hsin-Yi Wang <hsinyi@...omium.org> wrote:
>> >>>>
>> >>>> On Wed, Feb 14, 2024 at 2:23 PM Douglas Anderson <dianders@...omium.org> 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 kernel tree we landed on was the v5.15 tree, which is currently
> serving all Qualcomm sc7180-based Chromebooks, all Mediatek 8173
> Chromebooks and all Mediatek 8186 Chromebooks. There are also a pile
> of x86 Chromebooks running our v5.15 kernel. This code shouldn't
> affect them because (unless I'm mistaken) they don't use the two
> affected panel drivers. In any case, I haven't heard any screams from
> them either. Given my landing plans of "the week of the 26th", this
> still gives another 1.5 weeks for any screams to reach my ears.
>
> ...or are you looking for non-ChromeOS test reports? I'm not sure how
> to encourage those. I suppose sometimes folks at Red Hat end up
> stumbling over similar panel problems to those of us in ChromeOS.
> Maybe +Javier would be interested in providing a Tested-by?
>

I do have a SC7180 based HP X2 Chromebook and could test your patch (not
today but I could do it early next week), although I haven't followed so
if you could please let me know what exactly do you want me to verify.

AFAIU the problem is that the fwupd daemon tries to scan DP busses even if
the panel is turned off and that's what takes a lot of time (due retries),
and your patch makes the driver to bail out immediately ? If that's the
case, I guess that just starting fwupd daemon with an without your patch
while the panel is turned off could be a good test ?

> [1] https://crrev.com/c/5277322
> [2] https://crrev.com/c/5277736
>

-- 
Best regards,

Javier Martinez Canillas
Core Platforms
Red Hat

Powered by blists - more mailing lists