From: Doug Anderson <dianders@chromium.org> To: Maxime Ripard <mripard@kernel.org> Cc: Thomas Zimmermann <tzimmermann@suse.de>, linux-kernel@vger.kernel.org, dri-devel@lists.freedesktop.org Subject: Re: [RFC PATCH 04/10] drm/panel_helper: Introduce drm_panel_helper Date: Mon, 28 Aug 2023 09:06:29 -0700 [thread overview] Message-ID: <CAD=FV=XUhzguFCC=aKzHFMV0bBnZzkHXP_tx+P=PNkVr=8SnTA@mail.gmail.com> (raw) In-Reply-To: <lhd6ai7d6swlxhisjhikytguor7pptrymo3bmfwej4k7zqrnv4@hp2gvhw7mh3m> Hi, On Mon, Aug 28, 2023 at 12:45 AM Maxime Ripard <mripard@kernel.org> wrote: > > > For removal I'd be fine with just dropping the call and saying it's > > the responsibility of the driver to call drm_atomic_helper_shutdown(), > > as you suggest. I'd tend to believe that removal of DRM drivers is not > > used anywhere in "production" code (or at least not common) and I > > think it's super hard to get it right, to unregister and unbind all > > the DRM components in the right order. > > It depends on the kind of devices. USB devices are very likely to be > removed, platform devices very unlikely, and PCIe cards somewhere in the > middle :) Good point. Obviously those cases need to work. I guess I've just spent lots of time on the SoC case where all the pieces coming together are very intertwined with each other... > > Shutdown is called any time you reboot a device. That means that if a > > DRM driver is _not_ calling drm_atomic_helper_shutdown() on the > > panel's behalf at shutdown time then the panel won't be powered off > > properly. This feels to me like something that might actually matter. > > It does matter. What I disagree on is that you suggest working around > that brokenness in the core framework. What I'm saying is driver is > broken, we should keep the core framework sane and fix it in the driver. > > It should be fairly easy with a coccinelle script to figure out which > panels are affected, and to add that call in remove. I think I'm confused here. I've already figured out which panels are affected in my patch series, right? It's the set of panels that today try to power the panel off in their shutdown call, right? ...but I think we can't add the call you're suggesting, drm_atomic_helper_shutdown(), to the _panel_'s shutdown callback, can we? We need to add it to the shutdown callback of the top-level DRM driver, right? > > Panels tend to be one of those things that really care about their > > power sequencing and can even get damaged (or not turn on properly > > next time) if sequencing is not done properly, so just removing this > > code and putting the blame on the DRM driver seems scary to me. > > Sure, it's bad. But there's no difference compared to the approach you > suggest in that patch: you created a helper, yes, but every driver will > still have to call that helper and if they don't, the panel will still > be called and it's a bug. And we would have to convert everything to > that new helper. > > It's fundamentally the same discussion than what you were opposed to > above. I think the key difference here is that, if I understand correctly, drm_atomic_helper_shutdown() needs to be added to the top-level DRM driver, not to the panel itself. I guess I'm worried that I'll either miss a case or that simply adding a call to drm_atomic_helper_shutdown() in the top-level DRM driver will break something. Well, I suppose I can try it and see what happens... I'll try to cook up a v2 and we'll see what people say. I might keep the RFC tag for v2 just because I expect it to still be touching a lot of stuff. -Doug
WARNING: multiple messages have this Message-ID (diff)
From: Doug Anderson <dianders@chromium.org> To: Maxime Ripard <mripard@kernel.org> Cc: dri-devel@lists.freedesktop.org, Linus Walleij <linus.walleij@linaro.org>, Daniel Vetter <daniel@ffwll.ch>, David Airlie <airlied@gmail.com>, Maarten Lankhorst <maarten.lankhorst@linux.intel.com>, Thomas Zimmermann <tzimmermann@suse.de>, linux-kernel@vger.kernel.org Subject: Re: [RFC PATCH 04/10] drm/panel_helper: Introduce drm_panel_helper Date: Mon, 28 Aug 2023 09:06:29 -0700 [thread overview] Message-ID: <CAD=FV=XUhzguFCC=aKzHFMV0bBnZzkHXP_tx+P=PNkVr=8SnTA@mail.gmail.com> (raw) In-Reply-To: <lhd6ai7d6swlxhisjhikytguor7pptrymo3bmfwej4k7zqrnv4@hp2gvhw7mh3m> Hi, On Mon, Aug 28, 2023 at 12:45 AM Maxime Ripard <mripard@kernel.org> wrote: > > > For removal I'd be fine with just dropping the call and saying it's > > the responsibility of the driver to call drm_atomic_helper_shutdown(), > > as you suggest. I'd tend to believe that removal of DRM drivers is not > > used anywhere in "production" code (or at least not common) and I > > think it's super hard to get it right, to unregister and unbind all > > the DRM components in the right order. > > It depends on the kind of devices. USB devices are very likely to be > removed, platform devices very unlikely, and PCIe cards somewhere in the > middle :) Good point. Obviously those cases need to work. I guess I've just spent lots of time on the SoC case where all the pieces coming together are very intertwined with each other... > > Shutdown is called any time you reboot a device. That means that if a > > DRM driver is _not_ calling drm_atomic_helper_shutdown() on the > > panel's behalf at shutdown time then the panel won't be powered off > > properly. This feels to me like something that might actually matter. > > It does matter. What I disagree on is that you suggest working around > that brokenness in the core framework. What I'm saying is driver is > broken, we should keep the core framework sane and fix it in the driver. > > It should be fairly easy with a coccinelle script to figure out which > panels are affected, and to add that call in remove. I think I'm confused here. I've already figured out which panels are affected in my patch series, right? It's the set of panels that today try to power the panel off in their shutdown call, right? ...but I think we can't add the call you're suggesting, drm_atomic_helper_shutdown(), to the _panel_'s shutdown callback, can we? We need to add it to the shutdown callback of the top-level DRM driver, right? > > Panels tend to be one of those things that really care about their > > power sequencing and can even get damaged (or not turn on properly > > next time) if sequencing is not done properly, so just removing this > > code and putting the blame on the DRM driver seems scary to me. > > Sure, it's bad. But there's no difference compared to the approach you > suggest in that patch: you created a helper, yes, but every driver will > still have to call that helper and if they don't, the panel will still > be called and it's a bug. And we would have to convert everything to > that new helper. > > It's fundamentally the same discussion than what you were opposed to > above. I think the key difference here is that, if I understand correctly, drm_atomic_helper_shutdown() needs to be added to the top-level DRM driver, not to the panel itself. I guess I'm worried that I'll either miss a case or that simply adding a call to drm_atomic_helper_shutdown() in the top-level DRM driver will break something. Well, I suppose I can try it and see what happens... I'll try to cook up a v2 and we'll see what people say. I might keep the RFC tag for v2 just because I expect it to still be touching a lot of stuff. -Doug
next prev parent reply other threads:[~2023-08-28 16:06 UTC|newest] Thread overview: 68+ messages / expand[flat|nested] mbox.gz Atom feed top 2023-08-04 21:06 [RFC PATCH 00/10] drm/panel: Remove most store/double-check of prepared/enabled state Douglas Anderson 2023-08-04 21:06 ` Douglas Anderson 2023-08-04 21:06 ` [RFC PATCH 01/10] drm/panel: Don't store+check prepared/enabled for simple cases Douglas Anderson 2023-08-04 21:06 ` Douglas Anderson 2023-09-13 18:20 ` Doug Anderson 2023-09-13 18:20 ` Doug Anderson 2023-08-04 21:06 ` [RFC PATCH 02/10] drm/panel: s6e63m0: Don't store+check prepared/enabled Douglas Anderson 2023-08-04 21:06 ` Douglas Anderson 2023-09-13 18:20 ` Doug Anderson 2023-09-13 18:20 ` Doug Anderson 2023-08-04 21:06 ` [RFC PATCH 03/10] drm/panel: otm8009a: Don't double check prepared/enabled Douglas Anderson 2023-08-04 21:06 ` Douglas Anderson 2023-09-13 18:20 ` Doug Anderson 2023-09-13 18:20 ` Doug Anderson 2023-08-04 21:06 ` [RFC PATCH 04/10] drm/panel_helper: Introduce drm_panel_helper Douglas Anderson 2023-08-04 21:06 ` Douglas Anderson 2023-08-07 6:41 ` Maxime Ripard 2023-08-07 6:41 ` Maxime Ripard 2023-08-25 21:58 ` Doug Anderson 2023-08-25 21:58 ` Doug Anderson 2023-08-28 7:45 ` Maxime Ripard 2023-08-28 7:45 ` Maxime Ripard 2023-08-28 16:06 ` Doug Anderson [this message] 2023-08-28 16:06 ` Doug Anderson 2023-08-29 8:38 ` Maxime Ripard 2023-08-29 8:38 ` Maxime Ripard 2023-08-30 23:10 ` Doug Anderson 2023-08-30 23:10 ` Doug Anderson 2023-08-31 7:38 ` Maxime Ripard 2023-08-31 7:38 ` Maxime Ripard 2023-08-31 18:18 ` Doug Anderson 2023-08-31 18:18 ` Doug Anderson 2023-09-01 8:15 ` Maxime Ripard 2023-09-01 8:15 ` Maxime Ripard 2023-09-01 13:42 ` Doug Anderson 2023-09-01 13:42 ` Doug Anderson 2023-09-01 23:44 ` Doug Anderson 2023-09-01 23:44 ` Doug Anderson 2023-09-04 15:33 ` Maxime Ripard 2023-09-04 15:33 ` Maxime Ripard 2023-09-05 16:45 ` Doug Anderson 2023-09-05 16:45 ` Doug Anderson 2023-09-05 19:12 ` Doug Anderson 2023-09-05 19:12 ` Doug Anderson 2023-09-07 14:16 ` Maxime Ripard 2023-09-07 14:16 ` Maxime Ripard 2023-09-07 14:14 ` Maxime Ripard 2023-09-07 14:14 ` Maxime Ripard 2023-09-13 18:28 ` Doug Anderson 2023-09-13 18:28 ` Doug Anderson 2023-08-04 21:06 ` [RFC PATCH 05/10] drm/panel: Don't store+check prepared/enabled for panels needing shutdown Douglas Anderson 2023-08-04 21:06 ` Douglas Anderson 2023-08-04 21:06 ` [RFC PATCH 06/10] drm/panel: Don't store+check prepared/enabled for panels disabled at shutdown Douglas Anderson 2023-08-04 21:06 ` Douglas Anderson 2023-08-04 21:06 ` [RFC PATCH 07/10] drm/panel: st7703: Don't store+check prepared Douglas Anderson 2023-08-04 21:06 ` Douglas Anderson 2023-08-04 21:06 ` [RFC PATCH 08/10] drm/panel: rm67191: Don't store+check enabled Douglas Anderson 2023-08-04 21:06 ` Douglas Anderson 2023-08-04 21:06 ` [RFC PATCH 09/10] drm/panel: sony-acx565akm: Don't double-check enabled state in disable Douglas Anderson 2023-08-04 21:06 ` Douglas Anderson 2023-08-04 21:06 ` [RFC PATCH 10/10] drm/panel: Update TODO list item for cleaning up prepared/enabled tracking Douglas Anderson 2023-08-04 21:06 ` Douglas Anderson 2023-08-07 6:41 ` Maxime Ripard 2023-08-07 6:41 ` Maxime Ripard 2023-08-10 8:23 ` [RFC PATCH 00/10] drm/panel: Remove most store/double-check of prepared/enabled state Linus Walleij 2023-08-10 8:23 ` Linus Walleij 2023-09-05 19:15 ` Doug Anderson 2023-09-05 19:15 ` Doug Anderson
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=XUhzguFCC=aKzHFMV0bBnZzkHXP_tx+P=PNkVr=8SnTA@mail.gmail.com' \ --to=dianders@chromium.org \ --cc=dri-devel@lists.freedesktop.org \ --cc=linux-kernel@vger.kernel.org \ --cc=mripard@kernel.org \ --cc=tzimmermann@suse.de \ /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: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.