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