Hi,
On Fri, Apr 16, 2021 at 3:41 PM Douglas Anderson <dianders@xxxxxxxxxxxx> wrote:
>
> Historically simple-panel had code to make sure that if prepare() was
> called on an already-prepared panel that it was a no-op. Similarly if
> unprepare() was called on an already-unprepared panel it was also a
> no-op. Essentially it means that these functions always "forced" the
> value to be whatever the caller wanted it to be. You can see that the
> forcing behavior dates back at least as far as 2014 by looking at
> commit 613a633e7a56 ("drm/panel: simple: Add proper definition for
> prepare and unprepare").
>
> Apparently the code supporting the historical behavior may not be
> needed [1] and prepare() / unprepare() are supposed to be
> balanced. Let's try removing it and see if anyone breaks! If they do
> then we can have a debate about whether we should change that code or
> revert this patch. :-) If nobody breaks then we've nicely saved a few
> lines of code and some complexity.
>
> [1] https://lore.kernel.org/r/YHePsQgqOau1V5lD@xxxxxxxxxxxxxxxxxxxxxxxxxx
>
> Suggested-by: Laurent Pinchart <laurent.pinchart@xxxxxxxxxxxxxxxx>
> Signed-off-by: Douglas Anderson <dianders@xxxxxxxxxxxx>
> ---
>
> (no changes since v1)
>
> drivers/gpu/drm/panel/panel-simple.c | 14 --------------
> 1 file changed, 14 deletions(-)
So it turns out that when looking at panel_simple_remove() I already
found a case that's not necessarily refcounting. There I see
drm_panel_unprepare() just simply hardcoded, but (as I understand it)
there's no reason to believe that the panel has been prepared at
remove() time. Yes, I could fix panel_simple_remove() but instead, for
now, I think I'm going to drop this patch from the series. If someone
wants to pick it up then I certainly won't object, but for now keeping
the way things are seems the best way to keep from getting shouted at.
-Doug
