[PATCH v1 1/1] backlight: drop EARLY_EVENT_BLANK support
Sam Ravnborg
sam at ravnborg.org
Fri Jul 26 16:09:53 UTC 2019
Hi Lee.
On Thu, Jul 25, 2019 at 04:06:29PM +0100, Lee Jones wrote:
> On Thu, 25 Jul 2019, Daniel Vetter wrote:
>
> > On Thu, Jul 25, 2019 at 04:32:24PM +0200, Sam Ravnborg wrote:
> > > There was no users left - so drop the code to support EARLY_FB_BLANK.
> > > This patch removes the support in backlight,
> > > and drop the notifier in fbmem.
> > >
> > > That EARLY_FB_BLANK is not used can be verified that no driver set any of:
> > >
> > > lcd_ops.early_set_power()
> > > lcd_ops.r_early_set_power()
> > >
> > > Noticed while browsing backlight code for other reasons.
> >
> > Ah I didn't grep hard enough, I didn't realize that no one sets the
> > lcd_ops->(r_)early_set_power hooks. Nice find!
> >
> > Reviewed-by: Daniel Vetter <daniel.vetter at ffwll.ch>
> >
> > > Signed-off-by: Sam Ravnborg <sam at ravnborg.org>
> > > Cc: Lee Jones <lee.jones at linaro.org>
> > > Cc: Daniel Thompson <daniel.thompson at linaro.org>
> > > Cc: Jingoo Han <jingoohan1 at gmail.com>
> > > Cc: Bartlomiej Zolnierkiewicz <b.zolnierkie at samsung.com>
> > > Cc: Daniel Vetter <daniel.vetter at ffwll.ch>
> > > Cc: Sam Ravnborg <sam at ravnborg.org>
> > > Cc: Maarten Lankhorst <maarten.lankhorst at linux.intel.com>
> > > Cc: "Michał Mirosław" <mirq-linux at rere.qmqm.pl>
> > > Cc: Peter Rosin <peda at axentia.se>
> > > Cc: Gerd Hoffmann <kraxel at redhat.com>
> > > Cc: dri-devel at lists.freedesktop.org
> > > Cc: linux-fbdev at vger.kernel.org
> > > ---
> > >
> > > Build tested with various architectures, configs.
> > >
> > > Lee, Daniel - OK to commit to drm-misc-next where fbdev stuff is
> > > maintained today?
> >
> > backlight is separate from fbdev in Lee's own tree, not in drm-misc. I
> > think at least.
>
> That's correct. We'll sort that once we have all the Acks.
We have acks all around now.
OK that I commit this to drm-misc-next?
This is where we maintain fbdev these days. Or you could apply it to
your backlight tree.
Both solutins would be fine as the risk of introducing merge conflicts
in these code paths are minimal.
Sam
More information about the dri-devel
mailing list