lkml.org 
[lkml]   [2023]   [Sep]   [5]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    From
    Date
    SubjectRe: [RFC PATCH 00/10] drm/panel: Remove most store/double-check of prepared/enabled state
    Hi,

    On Thu, Aug 10, 2023 at 1:23 AM Linus Walleij <linus.walleij@linaro.org> wrote:
    >
    > On Fri, Aug 4, 2023 at 11:07 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. As part of this series a new helper is added that uses
    > > the state tracking that the drm_panel core is doing so each individual
    > > panel driver doesn't need to do it.
    > >
    > > This series changes a lot of drivers and obviously the author can't
    > > test on all of them. The changes here are also not completely trivial
    > > in all cases. Please double-check your drivers carefully to make sure
    > > something wasn't missed. After looking at over 40 drivers I'll admit
    > > that my eyes glazed over a little.
    > >
    > > I've attempted to organize these patches like to group together panels
    > > that needed similar handling. Panels that had code that didn't seem to
    > > match anyone else got their own patch. I made judgement calls on what
    > > I considered "similar".
    > >
    > > As noted in individual patches, there are some cases here where I
    > > expect behavior to change a little bit. I'm hoping these changes are
    > > for the better and don't cause any problems. Fingers crossed.
    > >
    > > 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.
    >
    > The series:
    > Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
    >
    > Please send out a non-RFC version, this is clearly the right thing to
    > do.

    As per the long discussion in response to patch #4, I think there are
    still open questions about the later patches in this series. However,
    I could land patches #1 - #3 if there are no concerns. Would anyone
    object if I just landed them straight from this series with Linus's
    review, or would I need to repost just patches #1 - #3 without the
    "RFC" tag?

    Thanks!

    -Doug

    \
     
     \ /
      Last update: 2023-09-05 21:17    [W:2.691 / U:0.036 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site