[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <fctpvshu5ychxketsf35jfg2qzi6i3nfup5hy7r7hzmmbpd2j4@xmsik3cycjlj>
Date: Thu, 7 Dec 2023 19:58:24 +0100
From: Maxime Ripard <mripard@...nel.org>
To: Doug Anderson <dianders@...omium.org>
Cc: Pin-yen Lin <treapking@...omium.org>,
Neil Armstrong <neil.armstrong@...aro.org>,
Jessica Zhang <quic_jesszhan@...cinc.com>,
Sam Ravnborg <sam@...nborg.org>,
Maarten Lankhorst <maarten.lankhorst@...ux.intel.com>,
Thomas Zimmermann <tzimmermann@...e.de>,
David Airlie <airlied@...il.com>,
Daniel Vetter <daniel@...ll.ch>, linux-kernel@...r.kernel.org,
Guenter Roeck <groeck@...omium.org>,
dri-devel@...ts.freedesktop.org
Subject: Re: [PATCH v2 4/4] drm/panel-edp: Add some panels with conservative
timings
On Thu, Dec 07, 2023 at 10:23:53AM -0800, Doug Anderson wrote:
> Hi,
>
> On Thu, Dec 7, 2023 at 12:18 AM Pin-yen Lin <treapking@...omium.org> wrote:
> >
> > These panels are used by Mediatek MT8173 Chromebooks but we can't find
> > the corresponding data sheets, and these panels used to work on v4.19
> > kernel without any specified delays.
> >
> > Therefore, instead of having them use the default conservative timings,
> > update them with less-conservative timings from other panels of the same
> > vendor. The panels should still work under those timings, and we can
> > save some delays and suppress the warnings.
> >
> > Signed-off-by: Pin-yen Lin <treapking@...omium.org>
> >
> > ---
> >
> > (no changes since v1)
> >
> > drivers/gpu/drm/panel/panel-edp.c | 31 +++++++++++++++++++++++++++++++
> > 1 file changed, 31 insertions(+)
>
> Reviewed-by: Douglas Anderson <dianders@...omium.org>
>
> Repeating my comments from v1 here too, since I expect this patch to
> sit on the lists for a little while:
>
>
> This is OK w/ me, but it will need time on the mailing lists before
> landing in case anyone else has opinions.
Generally speaking, I'm not really a fan of big patches that dump
whatever ChromeOS is doing ...
> Specifical thoughts:
>
> * I at least feel fairly confident that this is OK since these panels
> essentially booted without _any_ delays back on the old downstream
> v4.19 kernel. Presumably the panels just had fairly robust timing
> controllers and so worked OK, but it's better to get the timing more
> correct.
... especially since you have to rely on the recollection of engineers
involved at the time and you have no real way to test and make things
clearer anymore, and we have to take patches in that are handwavy "trust
us, it's doing the right thing".
I'd really prefer to have these patches sent as they are found out.
Also, the fact that the 4.19 kernel mentionned in the commit log is
actually a downstream tree needs to be made much clearer.
Maxime
Download attachment "signature.asc" of type "application/pgp-signature" (229 bytes)
Powered by blists - more mailing lists