drm/i915: Keep track of pwm-related backlight hooks separately
Currently, every different type of backlight hook that i915 supports is pretty straight forward - you have a backlight, probably through PWM (but maybe DPCD), with a single set of platform-specific hooks that are used for controlling it. HDR backlights, in particular VESA and Intel's HDR backlight implementations, can end up being more complicated. With Intel's proprietary interface, HDR backlight controls always run through the DPCD. When the backlight is in SDR backlight mode however, the driver may need to bypass the TCON and control the backlight directly through PWM. So, in order to support this we'll need to split our backlight callbacks into two groups: a set of high-level backlight control callbacks in intel_panel, and an additional set of pwm-specific backlight control callbacks. This also implies a functional changes for how these callbacks are used: * We now keep track of two separate backlight level ranges, one for the high-level backlight, and one for the pwm backlight range * We also keep track of backlight enablement and PWM backlight enablement separately * Since the currently set backlight level might not be the same as the currently programmed PWM backlight level, we stop setting panel->backlight.level with the currently programmed PWM backlight level in panel->backlight.pwm_funcs->setup(). Instead, we rely on the higher level backlight control functions to retrieve the current PWM backlight level (in this case, intel_pwm_get_backlight()). Note that there are still a few PWM backlight setup callbacks that do actually need to retrieve the current PWM backlight level, although we no longer save this value in panel->backlight.level like before. Additionally, we drop the call to lpt_get_backlight() in lpt_setup_backlight(), and avoid unconditionally writing the PWM value that we get from it and only write it back if we're in CPU mode, and switching to PCH mode. The reason for this is because in the original codepath for this, it was expected that the intel_panel_bl_funcs->setup() hook would be responsible for fetching the initial backlight level. On lpt systems, the only time we could ever be in PCH backlight mode is during the initial driver load - meaning that outside of the setup() hook, lpt_get_backlight() will always be the callback used for retrieving the current backlight level. After this patch we still need to fetch and write-back the PCH backlight value if we're switching from CPU mode to PCH, but because intel_pwm_setup_backlight() will retrieve the backlight level after setup() using the get() hook, which always ends up being lpt_get_backlight(). Thus - an additional call to lpt_get_backlight() in lpt_setup_backlight() is made redundant. v9: * Drop the intel_panel_invert_pwm_level() call in lpt_setup_backlight() * Remove leftover detritus from lpt_setup_backlight() v8: * Go back to getting initial brightness level with intel_pwm_get_backlight(), the other fix we had was definitely wrong. v7: * Use panel->backlight.pwm_funcs->get() to get the backlight level in intel_pwm_setup_backlight(), lest we upset lockdep * Rebase * Rename intel_panel_sanitize_pwm_level() to intel_panel_invert_pwm_level() v6: * Make sure to grab connection_mutex before calling intel_pwm_get_backlight() in intel_pwm_setup_backlight() v5: * Fix indenting warnings from checkpatch v4: * Fix commit message * Remove outdated comment in intel_panel.c * Rename pwm_(min|max) to pwm_level_(min|max) * Use intel_pwm_get_backlight() in intel_pwm_setup_backlight() instead of indirection * Don't move intel_dp_aux_init_bcklight_funcs() call to bottom of intel_panel_init_backlight_funcs() quite yet v3: * Reuse intel_panel_bl_funcs() for pwm_funcs * Explain why we drop lpt_get_backlight() Signed-off-by: Lyude Paul <lyude@redhat.com> Reviewed-by: Jani Nikula <jani.nikula@intel.com> Cc: thaytan@noraisin.net Cc: Vasily Khoruzhick <anarsoul@gmail.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210114221709.2261452-3-lyude@redhat.com
Showing
This diff is collapsed.
Please register or sign in to comment