Instead of checking the state of various backlight_properties fields
against the memorised state in atmel_lcdfb_info.bl_power,
atmel_bl_update_status() should retrieve the desired state using
backlight_get_brightness (which takes into account the power state,
blanking etc.). This means the explicit checks using props.fb_blank
and props.power can be dropped.
Then brightness can only be negative if the backlight is on but
props.brightness is negative, so the test before reading the
brightness value from the hardware can be simplified to
(brightness < 0).
As a result, bl_power in struct atmel_lcdfb_info is no longer
necessary, so remove that while we're at it. Since we only ever care
about reading the current state in backlight_properties, drop the
updates at the end of the function.
Signed-off-by: Stephen Kitt <[email protected]>
Cc: Nicolas Ferre <[email protected]>
Cc: Helge Deller <[email protected]>
Cc: Alexandre Belloni <[email protected]>
Cc: Claudiu Beznea <[email protected]>
Cc: [email protected]
Cc: [email protected]
Cc: [email protected]
---
drivers/video/fbdev/atmel_lcdfb.c | 21 ++-------------------
1 file changed, 2 insertions(+), 19 deletions(-)
diff --git a/drivers/video/fbdev/atmel_lcdfb.c b/drivers/video/fbdev/atmel_lcdfb.c
index 1fc8de4ecbeb..06159a4da293 100644
--- a/drivers/video/fbdev/atmel_lcdfb.c
+++ b/drivers/video/fbdev/atmel_lcdfb.c
@@ -49,7 +49,6 @@ struct atmel_lcdfb_info {
struct clk *lcdc_clk;
struct backlight_device *backlight;
- u8 bl_power;
u8 saved_lcdcon;
u32 pseudo_palette[16];
@@ -109,22 +108,10 @@ static u32 contrast_ctr = ATMEL_LCDC_PS_DIV8
static int atmel_bl_update_status(struct backlight_device *bl)
{
struct atmel_lcdfb_info *sinfo = bl_get_data(bl);
- int power = sinfo->bl_power;
- int brightness = bl->props.brightness;
+ int brightness = backlight_get_brightness(bl);
- /* REVISIT there may be a meaningful difference between
- * fb_blank and power ... there seem to be some cases
- * this doesn't handle correctly.
- */
- if (bl->props.fb_blank != sinfo->bl_power)
- power = bl->props.fb_blank;
- else if (bl->props.power != sinfo->bl_power)
- power = bl->props.power;
-
- if (brightness < 0 && power == FB_BLANK_UNBLANK)
+ if (brightness < 0)
brightness = lcdc_readl(sinfo, ATMEL_LCDC_CONTRAST_VAL);
- else if (power != FB_BLANK_UNBLANK)
- brightness = 0;
lcdc_writel(sinfo, ATMEL_LCDC_CONTRAST_VAL, brightness);
if (contrast_ctr & ATMEL_LCDC_POL_POSITIVE)
@@ -133,8 +120,6 @@ static int atmel_bl_update_status(struct backlight_device *bl)
else
lcdc_writel(sinfo, ATMEL_LCDC_CONTRAST_CTR, contrast_ctr);
- bl->props.fb_blank = bl->props.power = sinfo->bl_power = power;
-
return 0;
}
@@ -155,8 +140,6 @@ static void init_backlight(struct atmel_lcdfb_info *sinfo)
struct backlight_properties props;
struct backlight_device *bl;
- sinfo->bl_power = FB_BLANK_UNBLANK;
-
if (sinfo->backlight)
return;
base-commit: f2906aa863381afb0015a9eb7fefad885d4e5a56
--
2.30.2
On Wed, Jun 08, 2022 at 10:56:23PM +0200, Stephen Kitt wrote:
> Instead of checking the state of various backlight_properties fields
> against the memorised state in atmel_lcdfb_info.bl_power,
> atmel_bl_update_status() should retrieve the desired state using
> backlight_get_brightness (which takes into account the power state,
> blanking etc.). This means the explicit checks using props.fb_blank
> and props.power can be dropped.
>
> Then brightness can only be negative if the backlight is on but
> props.brightness is negative, so the test before reading the
> brightness value from the hardware can be simplified to
> (brightness < 0).
props.brightness should always be in the interval 0..max_brightness.
This is enforced by the main backlight code (and APIs to set the
brightness use unsigned values). Thus props.brightness could only be
negative is the driver explicitly sets a negative value as some kind of
placeholder (which this driver does not do).
I don't think there is any need to keep this logic.
Daniel.
> diff --git a/drivers/video/fbdev/atmel_lcdfb.c b/drivers/video/fbdev/atmel_lcdfb.c
> index 1fc8de4ecbeb..06159a4da293 100644
> --- a/drivers/video/fbdev/atmel_lcdfb.c
> +++ b/drivers/video/fbdev/atmel_lcdfb.c
> @@ -109,22 +108,10 @@ static u32 contrast_ctr = ATMEL_LCDC_PS_DIV8
> static int atmel_bl_update_status(struct backlight_device *bl)
> {
> struct atmel_lcdfb_info *sinfo = bl_get_data(bl);
> - int power = sinfo->bl_power;
> - int brightness = bl->props.brightness;
> + int brightness = backlight_get_brightness(bl);
>
> - /* REVISIT there may be a meaningful difference between
> - * fb_blank and power ... there seem to be some cases
> - * this doesn't handle correctly.
> - */
> - if (bl->props.fb_blank != sinfo->bl_power)
> - power = bl->props.fb_blank;
> - else if (bl->props.power != sinfo->bl_power)
> - power = bl->props.power;
> -
> - if (brightness < 0 && power == FB_BLANK_UNBLANK)
> + if (brightness < 0)
> brightness = lcdc_readl(sinfo, ATMEL_LCDC_CONTRAST_VAL);
> - else if (power != FB_BLANK_UNBLANK)
> - brightness = 0;
>
> lcdc_writel(sinfo, ATMEL_LCDC_CONTRAST_VAL, brightness);
> if (contrast_ctr & ATMEL_LCDC_POL_POSITIVE)
Hi Stephen,
thanks for taking care of all these backlight simplifications - this
really helps to make the code simpler and more readable.
On Thu, Jun 09, 2022 at 10:54:12AM +0100, Daniel Thompson wrote:
> On Wed, Jun 08, 2022 at 10:56:23PM +0200, Stephen Kitt wrote:
> > Instead of checking the state of various backlight_properties fields
> > against the memorised state in atmel_lcdfb_info.bl_power,
> > atmel_bl_update_status() should retrieve the desired state using
> > backlight_get_brightness (which takes into account the power state,
> > blanking etc.). This means the explicit checks using props.fb_blank
> > and props.power can be dropped.
> >
> > Then brightness can only be negative if the backlight is on but
> > props.brightness is negative, so the test before reading the
> > brightness value from the hardware can be simplified to
> > (brightness < 0).
>
> props.brightness should always be in the interval 0..max_brightness.
>
> This is enforced by the main backlight code (and APIs to set the
> brightness use unsigned values). Thus props.brightness could only be
> negative is the driver explicitly sets a negative value as some kind of
> placeholder (which this driver does not do).
>
> I don't think there is any need to keep this logic.
Daniel is right - please drop the "if (brightness < 0)" logic.
I have looked a bit on the datasheet in my attempt to do a drm version
of this driver - something that I am yet to succeed and the backlight
core avoid any negative values.
Sam
Hi Sam, Daniel,
On Thu, 9 Jun 2022 19:30:57 +0200, Sam Ravnborg <[email protected]> wrote:
> thanks for taking care of all these backlight simplifications - this
> really helps to make the code simpler and more readable.
You’re welcome! I noticed fb_blank was deprecated and near enough unused, and
started digging...
> On Thu, Jun 09, 2022 at 10:54:12AM +0100, Daniel Thompson wrote:
> > On Wed, Jun 08, 2022 at 10:56:23PM +0200, Stephen Kitt wrote:
> > > Instead of checking the state of various backlight_properties fields
> > > against the memorised state in atmel_lcdfb_info.bl_power,
> > > atmel_bl_update_status() should retrieve the desired state using
> > > backlight_get_brightness (which takes into account the power state,
> > > blanking etc.). This means the explicit checks using props.fb_blank
> > > and props.power can be dropped.
> > >
> > > Then brightness can only be negative if the backlight is on but
> > > props.brightness is negative, so the test before reading the
> > > brightness value from the hardware can be simplified to
> > > (brightness < 0).
> >
> > props.brightness should always be in the interval 0..max_brightness.
> >
> > This is enforced by the main backlight code (and APIs to set the
> > brightness use unsigned values). Thus props.brightness could only be
> > negative is the driver explicitly sets a negative value as some kind of
> > placeholder (which this driver does not do).
> >
> > I don't think there is any need to keep this logic.
>
> Daniel is right - please drop the "if (brightness < 0)" logic.
> I have looked a bit on the datasheet in my attempt to do a drm version
> of this driver - something that I am yet to succeed and the backlight
> core avoid any negative values.
Thanks for the reviews!
I’ve prepared a v2 without the (brightness < 0) logic, I’m about to submit
it.
Regards,
Stephen
On Thu, Jun 09, 2022 at 07:45:11PM +0200, Stephen Kitt wrote:
> Hi Sam, Daniel,
>
> On Thu, 9 Jun 2022 19:30:57 +0200, Sam Ravnborg <[email protected]> wrote:
> > thanks for taking care of all these backlight simplifications - this
> > really helps to make the code simpler and more readable.
>
> You’re welcome! I noticed fb_blank was deprecated and near enough unused, and
> started digging...
I saw Sam's comment and kinda wished I'd thought to say that... definitely
good to see these things being tidied up.
Daniel.
On Fri, 10 Jun 2022 10:49:55 +0100, Daniel Thompson
<[email protected]> wrote:
> On Thu, Jun 09, 2022 at 07:45:11PM +0200, Stephen Kitt wrote:
> > Hi Sam, Daniel,
> >
> > On Thu, 9 Jun 2022 19:30:57 +0200, Sam Ravnborg <[email protected]> wrote:
> >
> > > thanks for taking care of all these backlight simplifications - this
> > > really helps to make the code simpler and more readable.
> >
> > You’re welcome! I noticed fb_blank was deprecated and near enough unused,
> > and started digging...
>
> I saw Sam's comment and kinda wished I'd thought to say that... definitely
> good to see these things being tidied up.
Thanks! I saw the nice wrapper functions in backlight.h and couldn’t resist.
Regards,
Stephen