From: Doug Anderson <dianders@chromium.org>
To: Linus Walleij <linus.walleij@linaro.org>
Cc: dri-devel@lists.freedesktop.org,
"Maxime Ripard" <mripard@kernel.org>,
"Chris Morgan" <macromorgan@hotmail.com>,
"Yuran Pereira" <yuran.pereira@hotmail.com>,
"Neil Armstrong" <neil.armstrong@linaro.org>,
"AngeloGioacchino Del Regno"
<angelogioacchino.delregno@collabora.com>,
"Daniel Vetter" <daniel@ffwll.ch>,
"David Airlie" <airlied@gmail.com>,
"Guido Günther" <agx@sigxcpu.org>,
"Jerry Han" <hanxu5@huaqin.corp-partner.google.com>,
"Jessica Zhang" <quic_jesszhan@quicinc.com>,
"Jonathan Corbet" <corbet@lwn.net>,
"Maarten Lankhorst" <maarten.lankhorst@linux.intel.com>,
"Matthias Brugger" <matthias.bgg@gmail.com>,
"Ondrej Jirman" <megi@xff.cz>,
"Purism Kernel Team" <kernel@puri.sm>,
"Robert Chiras" <robert.chiras@nxp.com>,
"Sam Ravnborg" <sam@ravnborg.org>,
"Stefan Mavrodiev" <stefan@olimex.com>,
"Sumit Semwal" <sumit.semwal@linaro.org>,
"Thomas Zimmermann" <tzimmermann@suse.de>,
linux-arm-kernel@lists.infradead.org, linux-doc@vger.kernel.org,
linux-kernel@vger.kernel.org, linux-mediatek@lists.infradead.org
Subject: Re: [RFT PATCH v2 00/48] drm/panel: Remove most store/double-check of prepared/enabled state
Date: Wed, 8 May 2024 14:14:22 -0700 [thread overview]
Message-ID: <CAD=FV=WoYm43SzrdrSZ1Np58iQ4nMwF0u6uamOAnZc4pqmBpsg@mail.gmail.com> (raw)
In-Reply-To: <CACRpkdYbtfE9RLsDewV2UwnJknCp_sFEgc+cq=OF+Qd3tkTcwA@mail.gmail.com>
Hi,
On Sun, May 5, 2024 at 11:52 PM Linus Walleij <linus.walleij@linaro.org> wrote:
>
> On Fri, May 3, 2024 at 11:36 PM Douglas Anderson <dianders@chromium.org> wrote:
>
> > As talked about in commit d2aacaf07395 ("drm/panel: Check for already
> > prepared/enabled in drm_panel"), we want to remove needless code from
> > panel drivers that was storing and double-checking the
> > prepared/enabled state. Even if someone was relying on the
> > double-check before, that double-check is now in the core and not
> > needed in individual drivers.
> >
> > This series attempts to do just that. While the original grep, AKA:
> > git grep 'if.*>prepared' -- drivers/gpu/drm/panel
> > git grep 'if.*>enabled' -- drivers/gpu/drm/panel
> > ...still produces a few hits after my series, they are _mostly_ all
> > gone. The ones that are left are less trivial to fix.
> >
> > One of the main reasons that many panels probably needed to store and
> > double-check their prepared/enabled appears to have been to handle
> > shutdown and/or remove. Panels drivers often wanted to force the power
> > off for panels in these cases and this was a good reason for the
> > double-check.
> >
> > In response to my V1 series [1] we had much discussion of what to
> > do. The conclusion was that as long as DRM modeset drivers properly
> > called drm_atomic_helper_shutdown() that we should be able to remove
> > the explicit shutdown/remove handling in the panel drivers. Most of
> > the patches to improve DRM modeset drivers [2] [3] [4] have now
> > landed.
> >
> > In contrast to my V1 series, I broke the V2 series up a lot
> > more. Since a few of the panel drivers in V1 already landed, we had
> > fewer total drivers and so we could devote a patch to each panel.
> > Also, since we were now relying on DRM modeset drivers I felt like we
> > should split the patches for each panel into two: one that's
> > definitely safe and one that could be reverted if we found a
> > problematic DRM modeset driver that we couldn't fix.
> >
> > Sorry for the large number of patches. I've set things to mostly just
> > CC people on the cover letter and the patches that are relevant to
> > them. I've tried to CC people on the whole series that have shown
> > interest in this TODO item.
> >
> > As patches in this series are reviewed and/or tested they could be
> > landed. There's really no ordering requirement for the series unless
> > patches touch the same driver.
> >
> > NOTE: this touches _a lot_ of drivers, is repetitive, and is not
> > really possible to generate automatically. That means it's entirely
> > possible that my eyes glazed over and I did something wrong. Please
> > double-check me and don't assume that I got everything perfect, though
> > I did my best. I have at least confirmed that "allmodconfig" for arm64
> > doesn't fall on its face with this series. I haven't done a ton of
> > other testing.
> >
> > [1] https://lore.kernel.org/r/20230804140605.RFC.4.I930069a32baab6faf46d6b234f89613b5cec0f14@changeid
> > [2] https://lore.kernel.org/r/20230901234015.566018-1-dianders@chromium.org
> > [3] https://lore.kernel.org/r/20230901234202.566951-1-dianders@chromium.org
> > [4] https://lore.kernel.org/r/20230921192749.1542462-1-dianders@chromium.org
>
> This is the right thing to do, thanks for looking into this!
>
> As for the behaviour of .remove() I doubt whether in many cases
> the original driver authors have even tested this themselves.
Yeah, I'd tend to agree.
> I would say we should just apply the series as soon as it's non-RFC
It's not actually RFC now, but "RFT" (request for testing). I don't
_think_ there's any need to send a version without the RFT tag before
landing unless someone really feels strongly about it.
> after the next merge window
With drm-misc there's not really any specific reason to wait for the
merge window to open/close as we can land in drm-misc-next at any time
regardless of the merge window. drm-misc-next will simply stop feeding
linuxnext for a while.
That all being said, I'm happy to delay landing this until after the
next -rc1 comes out if people would prefer that. If I don't hear
anything, I guess I'll just wait until -rc1 before landing any of
these.
> and see what happens. I doubt it
> will cause much trouble.
I can land the whole series if that's what everyone agrees on. As I
mentioned above, I'm at least slightly worried that I did something
stupid _somewhere_ in this series since no automation was possible and
with repetitive tasks like this it's super easy to flub something up.
It's _probably_ fine, but I guess I still have the worry in the back
of my mind.
If folks think I should just apply the whole series then I'm happy to
do that. If folks think I should just land parts of the series as they
are reviewed/tested I can do that as well. Let me know. If I don't
hear anything I'd tend to just land patches that are reviewed/tested.
Then after a month or so (hopefully) I'd send out a v2 with anything
left.
> The series:
> Acked-by: Linus Walleij <linus.walleij@linaro.org>
Thanks!
-Doug
next prev parent reply other threads:[~2024-05-08 21:14 UTC|newest]
Thread overview: 74+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-05-03 21:32 [RFT PATCH v2 00/48] drm/panel: Remove most store/double-check of prepared/enabled state Douglas Anderson
2024-05-03 21:32 ` [RFT PATCH v2 01/48] drm/panel: raydium-rm692e5: Stop tracking prepared Douglas Anderson
2024-05-10 6:39 ` Luca Weiss
2024-05-03 21:32 ` [RFT PATCH v2 02/48] drm/panel: boe-himax8279d: Stop tracking prepared/enabled Douglas Anderson
2024-05-03 21:32 ` [RFT PATCH v2 03/48] drm/panel: boe-himax8279d: Don't call unprepare+disable at shutdown/remove Douglas Anderson
2024-05-03 21:32 ` [RFT PATCH v2 04/48] drm/panel: boe-tv101wum-nl6: Stop tracking prepared Douglas Anderson
2024-05-03 21:32 ` [RFT PATCH v2 05/48] drm/panel: boe-tv101wum-nl6: Don't call unprepare+disable at shutdown/remove Douglas Anderson
2024-05-03 21:32 ` [RFT PATCH v2 06/48] drm/panel: edp: Stop tracking prepared/enabled Douglas Anderson
2024-05-03 21:32 ` [RFT PATCH v2 07/48] drm/panel: edp: Add a comment about unprepare+disable at shutdown/remove Douglas Anderson
2024-05-03 21:32 ` [RFT PATCH v2 08/48] drm/panel: innolux-p079zca: Stop tracking prepared/enabled Douglas Anderson
2024-05-06 16:28 ` Heiko Stübner
2024-05-03 21:32 ` [RFT PATCH v2 09/48] drm/panel: innolux-p079zca: Don't call unprepare+disable at shutdown/remove Douglas Anderson
2024-05-06 16:29 ` Heiko Stübner
2024-05-03 21:32 ` [RFT PATCH v2 10/48] drm/panel: khadas-ts050: Stop tracking prepared/enabled Douglas Anderson
2024-05-03 21:32 ` [RFT PATCH v2 11/48] drm/panel: khadas-ts050: Don't call unprepare+disable at shutdown/remove Douglas Anderson
2024-05-03 21:32 ` [RFT PATCH v2 12/48] drm/panel: kingdisplay-kd097d04: Stop tracking prepared/enabled Douglas Anderson
2024-05-06 16:29 ` Heiko Stübner
2024-05-03 21:32 ` [RFT PATCH v2 13/48] drm/panel: kingdisplay-kd097d04: Don't call unprepare+disable at shutdown/remove Douglas Anderson
2024-05-06 16:29 ` Heiko Stübner
2024-05-03 21:32 ` [RFT PATCH v2 14/48] drm/panel: ltk050h3146w: Stop tracking prepared Douglas Anderson
2024-05-06 11:17 ` Quentin Schulz
2024-05-06 16:26 ` Heiko Stübner
2024-05-03 21:32 ` [RFT PATCH v2 15/48] drm/panel: ltk050h3146w: Don't call unprepare+disable at shutdown/remove Douglas Anderson
2024-05-06 14:04 ` Quentin Schulz
2024-05-06 15:17 ` Doug Anderson
2024-05-06 16:21 ` Heiko Stübner
2024-05-03 21:32 ` [RFT PATCH v2 16/48] drm/panel: ltk500hd1829: Stop tracking prepared Douglas Anderson
2024-05-06 16:30 ` Heiko Stübner
2024-05-03 21:32 ` [RFT PATCH v2 17/48] drm/panel: ltk500hd1829: Don't call unprepare+disable at shutdown/remove Douglas Anderson
2024-05-06 16:30 ` Heiko Stübner
2024-05-03 21:32 ` [RFT PATCH v2 18/48] drm/panel: novatek-nt36672a: Stop tracking prepared Douglas Anderson
2024-05-04 23:58 ` Joel Selvaraj
2024-05-03 21:33 ` [RFT PATCH v2 19/48] drm/panel: novatek-nt36672a: Don't call unprepare+disable at shutdown/remove Douglas Anderson
2024-05-04 23:58 ` Joel Selvaraj
2024-05-05 0:10 ` Joel Selvaraj
2024-05-03 21:33 ` [RFT PATCH v2 20/48] drm/panel: olimex-lcd-olinuxino: Stop tracking prepared/enabled Douglas Anderson
2024-05-03 21:33 ` [RFT PATCH v2 21/48] drm/panel: olimex-lcd-olinuxino: Don't call unprepare+disable at remove Douglas Anderson
2024-05-03 21:33 ` [RFT PATCH v2 22/48] drm/panel: osd-osd101t2587-53ts: Stop tracking prepared/enabled Douglas Anderson
2024-05-03 21:33 ` [RFT PATCH v2 23/48] drm/panel: osd-osd101t2587-53ts: Don't call unprepare+disable at shutdown/remove Douglas Anderson
2024-05-03 21:33 ` [RFT PATCH v2 24/48] drm/panel: samsung-atna33xc20: Stop tracking prepared/enabled Douglas Anderson
2024-05-03 21:33 ` [RFT PATCH v2 25/48] drm/panel: samsung-atna33xc20: Don't call unprepare+disable at shutdown/remove Douglas Anderson
2024-05-03 21:33 ` [RFT PATCH v2 26/48] drm/panel: simple: Stop tracking prepared/enabled Douglas Anderson
2024-05-18 13:20 ` [RFT,v2,26/48] " Sui Jingfeng
2024-05-03 21:33 ` [RFT PATCH v2 27/48] drm/panel: simple: Add a comment about unprepare+disable at shutdown/remove Douglas Anderson
2024-05-03 21:33 ` [RFT PATCH v2 28/48] drm/panel: tdo-tl070wsh30: Stop tracking prepared Douglas Anderson
2024-05-03 21:33 ` [RFT PATCH v2 29/48] drm/panel: tdo-tl070wsh30: Don't call unprepare+disable at shutdown/remove Douglas Anderson
2024-05-03 21:33 ` [RFT PATCH v2 30/48] drm/panel: xinpeng-xpp055c272: Stop tracking prepared Douglas Anderson
2024-05-06 16:30 ` Heiko Stübner
2024-05-03 21:33 ` [RFT PATCH v2 31/48] drm/panel: xinpeng-xpp055c272: Don't call unprepare+disable at shutdown/remove Douglas Anderson
2024-05-06 16:31 ` Heiko Stübner
2024-05-03 21:33 ` [RFT PATCH v2 32/48] drm/panel: jdi-lt070me05000: Stop tracking prepared/enabled Douglas Anderson
2024-05-03 21:33 ` [RFT PATCH v2 33/48] drm/panel: jdi-lt070me05000: Don't call disable at shutdown/remove Douglas Anderson
2024-05-03 21:33 ` [RFT PATCH v2 34/48] drm/panel: panasonic-vvx10f034n00: Stop tracking prepared/enabled Douglas Anderson
2024-05-03 21:33 ` [RFT PATCH v2 35/48] drm/panel: panasonic-vvx10f034n00: Don't call disable at shutdown/remove Douglas Anderson
2024-05-03 21:33 ` [RFT PATCH v2 36/48] drm/panel: seiko-43wvf1g: Stop tracking prepared/enabled Douglas Anderson
2024-05-03 21:33 ` [RFT PATCH v2 37/48] drm/panel: seiko-43wvf1g: Don't call disable at shutdown/remove Douglas Anderson
2024-05-03 21:33 ` [RFT PATCH v2 38/48] drm/panel: sharp-lq101r1sx01: Stop tracking prepared/enabled Douglas Anderson
2024-05-03 21:33 ` [RFT PATCH v2 39/48] drm/panel: sharp-lq101r1sx01: Don't call disable at shutdown/remove Douglas Anderson
2024-05-03 21:33 ` [RFT PATCH v2 40/48] drm/panel: sharp-ls043t1le01: Stop tracking prepared Douglas Anderson
2024-05-03 21:33 ` [RFT PATCH v2 41/48] drm/panel: sharp-ls043t1le01: Don't call disable at shutdown/remove Douglas Anderson
2024-05-03 21:33 ` [RFT PATCH v2 42/48] drm/panel: sitronix-st7703: Stop tracking prepared Douglas Anderson
2024-05-03 21:33 ` [RFT PATCH v2 43/48] drm/panel: sitronix-st7703: Don't call disable at shutdown/remove Douglas Anderson
2024-05-03 21:33 ` [RFT PATCH v2 44/48] drm/panel: raydium-rm67191: Stop tracking enabled Douglas Anderson
2024-05-03 21:33 ` [RFT PATCH v2 45/48] drm/panel: raydium-rm67191: Don't call unprepare+disable at shutdown Douglas Anderson
2024-05-03 21:33 ` [RFT PATCH v2 46/48] drm/panel: sony-acx565akm: Don't double-check enabled state in disable Douglas Anderson
2024-05-06 6:49 ` Linus Walleij
2024-05-03 21:33 ` [RFT PATCH v2 47/48] drm/panel: sony-acx565akm: Don't call disable at remove Douglas Anderson
2024-05-06 6:49 ` Linus Walleij
2024-05-06 6:49 ` Linus Walleij
2024-05-03 21:33 ` [RFT PATCH v2 48/48] drm/panel: Update TODO list item for cleaning up prepared/enabled tracking Douglas Anderson
2024-05-06 6:52 ` [RFT PATCH v2 00/48] drm/panel: Remove most store/double-check of prepared/enabled state Linus Walleij
2024-05-06 7:17 ` Ondřej Jirman
2024-05-08 21:14 ` Doug Anderson [this message]
2024-05-06 7:27 ` Maxime Ripard
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='CAD=FV=WoYm43SzrdrSZ1Np58iQ4nMwF0u6uamOAnZc4pqmBpsg@mail.gmail.com' \
--to=dianders@chromium.org \
--cc=agx@sigxcpu.org \
--cc=airlied@gmail.com \
--cc=angelogioacchino.delregno@collabora.com \
--cc=corbet@lwn.net \
--cc=daniel@ffwll.ch \
--cc=dri-devel@lists.freedesktop.org \
--cc=hanxu5@huaqin.corp-partner.google.com \
--cc=kernel@puri.sm \
--cc=linus.walleij@linaro.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-doc@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mediatek@lists.infradead.org \
--cc=maarten.lankhorst@linux.intel.com \
--cc=macromorgan@hotmail.com \
--cc=matthias.bgg@gmail.com \
--cc=megi@xff.cz \
--cc=mripard@kernel.org \
--cc=neil.armstrong@linaro.org \
--cc=quic_jesszhan@quicinc.com \
--cc=robert.chiras@nxp.com \
--cc=sam@ravnborg.org \
--cc=stefan@olimex.com \
--cc=sumit.semwal@linaro.org \
--cc=tzimmermann@suse.de \
--cc=yuran.pereira@hotmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).