Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.38 as permitted sender) client-ip=23.128.96.38;
MIME-Version: 1.0
References: <20231207081801.4049075-1-treapking@chromium.org>
 <20231207081801.4049075-5-treapking@chromium.org> <CAD=FV=U6M5rpQXmjC+iGf0BGtiyjRAAcMfo4Fr3pDyYVp3m4aQ@mail.gmail.com>
 <fctpvshu5ychxketsf35jfg2qzi6i3nfup5hy7r7hzmmbpd2j4@xmsik3cycjlj>
 <CAD=FV=V=K9L=bJiNvFJ+K_DHUTPxA4WtukXA+E_VW6uihE8kdQ@mail.gmail.com>
 <cplpgkl5b3nrtdhxauleep6zo2rwic7h7fiwr4wnvrwk6uzxgw@dcgknug2gsaa> <CAD=FV=UiF9d5C=da64dj_JnGWuO_vGUg1hgzXSQd0x+pFpe23w@mail.gmail.com>
In-Reply-To: <CAD=FV=UiF9d5C=da64dj_JnGWuO_vGUg1hgzXSQd0x+pFpe23w@mail.gmail.com>
From:   Pin-yen Lin <treapking@chromium.org>
Date:   Thu, 14 Dec 2023 16:17:01 +0800
Message-ID: <CAEXTbpdjTVteNYMPN_wOwoc9TGuRT-+mugM4pj6tzih_wOU+hg@mail.gmail.com>
Subject: Re: [PATCH v2 4/4] drm/panel-edp: Add some panels with conservative timings
To:     Doug Anderson <dianders@chromium.org>
Cc:     Maxime Ripard <mripard@kernel.org>,
        Neil Armstrong <neil.armstrong@linaro.org>,
        Jessica Zhang <quic_jesszhan@quicinc.com>,
        Sam Ravnborg <sam@ravnborg.org>,
        Maarten Lankhorst <maarten.lankhorst@linux.intel.com>,
        Thomas Zimmermann <tzimmermann@suse.de>,
        David Airlie <airlied@gmail.com>,
        Daniel Vetter <daniel@ffwll.ch>, linux-kernel@vger.kernel.org,
        Guenter Roeck <groeck@chromium.org>,
        dri-devel@lists.freedesktop.org
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Precedence: bulk

On Thu, Dec 14, 2023 at 12:23=E2=80=AFAM Doug Anderson <dianders@chromium.o=
rg> wrote:
>
> Hi,
>
> On Wed, Dec 13, 2023 at 7:34=E2=80=AFAM Maxime Ripard <mripard@kernel.org=
> wrote:
> >
> > > > > 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 befo=
re
> > > > > 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 pa=
nels
> > > > > essentially booted without _any_ delays back on the old downstrea=
m
> > > > > v4.19 kernel. Presumably the panels just had fairly robust timing
> > > > > controllers and so worked OK, but it's better to get the timing m=
ore
> > > > > correct.
> > > >
> > > > ... especially since you have to rely on the recollection of engine=
ers
> > > > involved at the time and you have no real way to test and make thin=
gs
> > > > 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.
> > >
> > > It's probably not clear enough from the commit message, but this isn'=
t
> > > just a dump from downstream 4.19. What happened was:
> > >
> > > 1. Downstream chromeos-4.19 used the "little white lie" approach. The=
y
> > > all claimed a specific panel's compatible string even though there
> > > were a whole pile of panels out there actually being used. Personally=
,
> > > this was not something I was ever a fan of (and I wasn't personally
> > > involved in this project), but it was the "state of the art" before
> > > the generic panel-edp. Getting out of the "little white lie" situatio=
n
> > > was why I spent so much time on the generic edp-panel solution
> > > upstream.
> > >
> > > 2. These devices have now been uprevved to a newer kernel and I
> > > believe that there were issues seen that necessitated a move to the
> > > proper generic panel-edp code.
> > >
> > > 3. We are now getting field reports from our warning collector about =
a
> > > whole pile of panels that are falling back to the "conservative"
> > > timings, which means that they turn on/off much more slowly than they
> > > should.
> > >
> > > Pin-yen made an attempt to search for panels data sheets that matched
> > > up with the IDs that came in from the field reports but there were
> > > some panels that he just couldn't find.
> > >
> > > So basically we're stuck. Options:
> > >
> > > 1. Leave customers who have these panels stuck with the hardware
> > > behaving worse than it used to. This is not acceptable to me.
> > >
> > > 2. Land Pin-yen's patch as a downstream-only patch in ChromeOS. This
> > > would solve the problem, but it would make me sad. If anyone ever
> > > wants to take these old laptops and run some other Linux distribution
> > > on them (and there are several that target old Chromebooks) then
> > > they'd be again stuck with old timings.
> > >
> > > 3. Land a patch like this one that at least gets us into not such a b=
ad shape.
> > >
> > > While I don't love this patch (and that's why I made it clear that it
> > > needs to spend time on the list), it seems better than the
> > > alternatives. Do you have a proposal for something else? If not, can
> > > you confirm you're OK with #3 given this explanation? ...and perhaps
> > > more details in the commit message?
> >
> > I don't have a specific comment, it was more of a comment about the
> > process itself, if you write down what's above in the commit message ..=
.
>
> Pin-yen: can you take a whack at summarizing some of the above in the
> commit message and sending out a v3?

Sure I'll do that in v3. Sorry for not including enough details in the
original commit message.

Pin-yen