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 steve@sk2.org Cc: Nicolas Ferre nicolas.ferre@microchip.com Cc: Helge Deller deller@gmx.de Cc: Alexandre Belloni alexandre.belloni@bootlin.com Cc: Claudiu Beznea claudiu.beznea@microchip.com Cc: linux-fbdev@vger.kernel.org Cc: dri-devel@lists.freedesktop.org Cc: linux-arm-kernel@lists.infradead.org --- 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
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 sam@ravnborg.org 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 sam@ravnborg.org 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 daniel.thompson@linaro.org 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 sam@ravnborg.org 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
dri-devel@lists.freedesktop.org
-
Daniel Thompson -
Sam Ravnborg -
Stephen Kitt