linux/drivers/gpu/drm/i915/display/intel_dp_aux_backlight.c

440 lines
16 KiB
C
Raw Normal View History

/*
* Copyright © 2015 Intel Corporation
*
* Permission is hereby granted, free of charge, to any person obtaining a
* copy of this software and associated documentation files (the "Software"),
* to deal in the Software without restriction, including without limitation
* the rights to use, copy, modify, merge, publish, distribute, sublicense,
* and/or sell copies of the Software, and to permit persons to whom the
* Software is furnished to do so, subject to the following conditions:
*
* The above copyright notice and this permission notice (including the next
* paragraph) shall be included in all copies or substantial portions of the
* Software.
*
* THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
* IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
* FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL
* THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
* LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
* FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS
* IN THE SOFTWARE.
*
*/
drm/i915/dp: Enable Intel's HDR backlight interface (only SDR for now) So-recently a bunch of laptops on the market have started using DPCD backlight controls instead of the traditional DDI backlight controls. Originally we thought we had this handled by adding VESA backlight control support to i915, but the story ended up being a lot more complicated then that. Simply put-there's two main backlight interfaces Intel can see in the wild. Intel's proprietary HDR backlight interface, and the standard VESA backlight interface. Note that many panels have been observed to report support for both backlight interfaces, but testing has shown far more panels work with the Intel HDR backlight interface at the moment. Additionally, the VBT appears to be capable of reporting support for the VESA backlight interface but not the Intel HDR interface which needs to be probed by setting the right magic OUI. On top of that however, there's also actually two different variants of the Intel HDR backlight interface. The first uses the AUX channel for controlling the brightness of the screen in both SDR and HDR mode, and the second only uses the AUX channel for setting the brightness level in HDR mode - relying on PWM for setting the brightness level in SDR mode. For the time being we've been using EDIDs to maintain a list of quirks for panels that safely do support the VESA backlight interface. Adding support for Intel's HDR backlight interface in addition however, should finally allow us to auto-detect eDP backlight controls properly so long as we probe like so: * If the panel's VBT reports VESA backlight support, assume it really does support it * If the panel's VBT reports DDI backlight controls: * First probe for Intel's HDR backlight interface * If that fails, probe for VESA's backlight interface * If that fails, assume no DPCD backlight control * If the panel's VBT reports any other backlight type: just assume it doesn't have DPCD backlight controls Changes since v4: * Fix checkpatch issues Changes since v3: * Stop using drm_device and use drm_i915_private instead * Don't forget to return from intel_dp_aux_hdr_get_backlight() if we fail to read the current backlight mode from the DPCD * s/uint8_t/u8/ * Remove unneeded parenthesis in intel_dp_aux_hdr_enable_backlight() * Use drm_dbg_kms() in intel_dp_aux_init_backlight_funcs() 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-4-lyude@redhat.com
2020-06-29 19:01:49 +00:00
/*
* Laptops with Intel GPUs which have panels that support controlling the
* backlight through DP AUX can actually use two different interfaces: Intel's
* proprietary DP AUX backlight interface, and the standard VESA backlight
* interface. Unfortunately, at the time of writing this a lot of laptops will
* advertise support for the standard VESA backlight interface when they
* don't properly support it. However, on these systems the Intel backlight
* interface generally does work properly. Additionally, these systems will
* usually just indicate that they use PWM backlight controls in their VBIOS
* for some reason.
*/
#include "intel_display_types.h"
#include "intel_dp_aux_backlight.h"
drm/i915/dp: Enable Intel's HDR backlight interface (only SDR for now) So-recently a bunch of laptops on the market have started using DPCD backlight controls instead of the traditional DDI backlight controls. Originally we thought we had this handled by adding VESA backlight control support to i915, but the story ended up being a lot more complicated then that. Simply put-there's two main backlight interfaces Intel can see in the wild. Intel's proprietary HDR backlight interface, and the standard VESA backlight interface. Note that many panels have been observed to report support for both backlight interfaces, but testing has shown far more panels work with the Intel HDR backlight interface at the moment. Additionally, the VBT appears to be capable of reporting support for the VESA backlight interface but not the Intel HDR interface which needs to be probed by setting the right magic OUI. On top of that however, there's also actually two different variants of the Intel HDR backlight interface. The first uses the AUX channel for controlling the brightness of the screen in both SDR and HDR mode, and the second only uses the AUX channel for setting the brightness level in HDR mode - relying on PWM for setting the brightness level in SDR mode. For the time being we've been using EDIDs to maintain a list of quirks for panels that safely do support the VESA backlight interface. Adding support for Intel's HDR backlight interface in addition however, should finally allow us to auto-detect eDP backlight controls properly so long as we probe like so: * If the panel's VBT reports VESA backlight support, assume it really does support it * If the panel's VBT reports DDI backlight controls: * First probe for Intel's HDR backlight interface * If that fails, probe for VESA's backlight interface * If that fails, assume no DPCD backlight control * If the panel's VBT reports any other backlight type: just assume it doesn't have DPCD backlight controls Changes since v4: * Fix checkpatch issues Changes since v3: * Stop using drm_device and use drm_i915_private instead * Don't forget to return from intel_dp_aux_hdr_get_backlight() if we fail to read the current backlight mode from the DPCD * s/uint8_t/u8/ * Remove unneeded parenthesis in intel_dp_aux_hdr_enable_backlight() * Use drm_dbg_kms() in intel_dp_aux_init_backlight_funcs() 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-4-lyude@redhat.com
2020-06-29 19:01:49 +00:00
#include "intel_panel.h"
/* TODO:
* Implement HDR, right now we just implement the bare minimum to bring us back into SDR mode so we
* can make people's backlights work in the mean time
*/
/*
* DP AUX registers for Intel's proprietary HDR backlight interface. We define
* them here since we'll likely be the only driver to ever use these.
*/
#define INTEL_EDP_HDR_TCON_CAP0 0x340
#define INTEL_EDP_HDR_TCON_CAP1 0x341
# define INTEL_EDP_HDR_TCON_2084_DECODE_CAP BIT(0)
# define INTEL_EDP_HDR_TCON_2020_GAMUT_CAP BIT(1)
# define INTEL_EDP_HDR_TCON_TONE_MAPPING_CAP BIT(2)
# define INTEL_EDP_HDR_TCON_SEGMENTED_BACKLIGHT_CAP BIT(3)
# define INTEL_EDP_HDR_TCON_BRIGHTNESS_NITS_CAP BIT(4)
# define INTEL_EDP_HDR_TCON_OPTIMIZATION_CAP BIT(5)
# define INTEL_EDP_HDR_TCON_SDP_COLORIMETRY_CAP BIT(6)
# define INTEL_EDP_HDR_TCON_SRGB_TO_PANEL_GAMUT_CONVERSION_CAP BIT(7)
#define INTEL_EDP_HDR_TCON_CAP2 0x342
# define INTEL_EDP_SDR_TCON_BRIGHTNESS_AUX_CAP BIT(0)
#define INTEL_EDP_HDR_TCON_CAP3 0x343
#define INTEL_EDP_HDR_GETSET_CTRL_PARAMS 0x344
# define INTEL_EDP_HDR_TCON_2084_DECODE_ENABLE BIT(0)
# define INTEL_EDP_HDR_TCON_2020_GAMUT_ENABLE BIT(1)
# define INTEL_EDP_HDR_TCON_TONE_MAPPING_ENABLE BIT(2) /* Pre-TGL+ */
# define INTEL_EDP_HDR_TCON_SEGMENTED_BACKLIGHT_ENABLE BIT(3)
# define INTEL_EDP_HDR_TCON_BRIGHTNESS_AUX_ENABLE BIT(4)
# define INTEL_EDP_HDR_TCON_SRGB_TO_PANEL_GAMUT_ENABLE BIT(5)
/* Bit 6 is reserved */
# define INTEL_EDP_HDR_TCON_SDP_COLORIMETRY_ENABLE BIT(7)
#define INTEL_EDP_HDR_CONTENT_LUMINANCE 0x346 /* Pre-TGL+ */
#define INTEL_EDP_HDR_PANEL_LUMINANCE_OVERRIDE 0x34A
#define INTEL_EDP_SDR_LUMINANCE_LEVEL 0x352
#define INTEL_EDP_BRIGHTNESS_NITS_LSB 0x354
#define INTEL_EDP_BRIGHTNESS_NITS_MSB 0x355
#define INTEL_EDP_BRIGHTNESS_DELAY_FRAMES 0x356
#define INTEL_EDP_BRIGHTNESS_PER_FRAME_STEPS 0x357
#define INTEL_EDP_BRIGHTNESS_OPTIMIZATION_0 0x358
# define INTEL_EDP_TCON_USAGE_MASK GENMASK(0, 3)
# define INTEL_EDP_TCON_USAGE_UNKNOWN 0x0
# define INTEL_EDP_TCON_USAGE_DESKTOP 0x1
# define INTEL_EDP_TCON_USAGE_FULL_SCREEN_MEDIA 0x2
# define INTEL_EDP_TCON_USAGE_FULL_SCREEN_GAMING 0x3
# define INTEL_EDP_TCON_POWER_MASK BIT(4)
# define INTEL_EDP_TCON_POWER_DC (0 << 4)
# define INTEL_EDP_TCON_POWER_AC (1 << 4)
# define INTEL_EDP_TCON_OPTIMIZATION_STRENGTH_MASK GENMASK(5, 7)
#define INTEL_EDP_BRIGHTNESS_OPTIMIZATION_1 0x359
drm/i915/dp: Enable Intel's HDR backlight interface (only SDR for now) So-recently a bunch of laptops on the market have started using DPCD backlight controls instead of the traditional DDI backlight controls. Originally we thought we had this handled by adding VESA backlight control support to i915, but the story ended up being a lot more complicated then that. Simply put-there's two main backlight interfaces Intel can see in the wild. Intel's proprietary HDR backlight interface, and the standard VESA backlight interface. Note that many panels have been observed to report support for both backlight interfaces, but testing has shown far more panels work with the Intel HDR backlight interface at the moment. Additionally, the VBT appears to be capable of reporting support for the VESA backlight interface but not the Intel HDR interface which needs to be probed by setting the right magic OUI. On top of that however, there's also actually two different variants of the Intel HDR backlight interface. The first uses the AUX channel for controlling the brightness of the screen in both SDR and HDR mode, and the second only uses the AUX channel for setting the brightness level in HDR mode - relying on PWM for setting the brightness level in SDR mode. For the time being we've been using EDIDs to maintain a list of quirks for panels that safely do support the VESA backlight interface. Adding support for Intel's HDR backlight interface in addition however, should finally allow us to auto-detect eDP backlight controls properly so long as we probe like so: * If the panel's VBT reports VESA backlight support, assume it really does support it * If the panel's VBT reports DDI backlight controls: * First probe for Intel's HDR backlight interface * If that fails, probe for VESA's backlight interface * If that fails, assume no DPCD backlight control * If the panel's VBT reports any other backlight type: just assume it doesn't have DPCD backlight controls Changes since v4: * Fix checkpatch issues Changes since v3: * Stop using drm_device and use drm_i915_private instead * Don't forget to return from intel_dp_aux_hdr_get_backlight() if we fail to read the current backlight mode from the DPCD * s/uint8_t/u8/ * Remove unneeded parenthesis in intel_dp_aux_hdr_enable_backlight() * Use drm_dbg_kms() in intel_dp_aux_init_backlight_funcs() 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-4-lyude@redhat.com
2020-06-29 19:01:49 +00:00
/* Intel EDP backlight callbacks */
static bool
intel_dp_aux_supports_hdr_backlight(struct intel_connector *connector)
{
struct drm_i915_private *i915 = to_i915(connector->base.dev);
struct intel_dp *intel_dp = enc_to_intel_dp(connector->encoder);
struct drm_dp_aux *aux = &intel_dp->aux;
struct intel_panel *panel = &connector->panel;
int ret;
u8 tcon_cap[4];
ret = drm_dp_dpcd_read(aux, INTEL_EDP_HDR_TCON_CAP0, tcon_cap, sizeof(tcon_cap));
if (ret != sizeof(tcon_cap))
drm/i915/dp: Enable Intel's HDR backlight interface (only SDR for now) So-recently a bunch of laptops on the market have started using DPCD backlight controls instead of the traditional DDI backlight controls. Originally we thought we had this handled by adding VESA backlight control support to i915, but the story ended up being a lot more complicated then that. Simply put-there's two main backlight interfaces Intel can see in the wild. Intel's proprietary HDR backlight interface, and the standard VESA backlight interface. Note that many panels have been observed to report support for both backlight interfaces, but testing has shown far more panels work with the Intel HDR backlight interface at the moment. Additionally, the VBT appears to be capable of reporting support for the VESA backlight interface but not the Intel HDR interface which needs to be probed by setting the right magic OUI. On top of that however, there's also actually two different variants of the Intel HDR backlight interface. The first uses the AUX channel for controlling the brightness of the screen in both SDR and HDR mode, and the second only uses the AUX channel for setting the brightness level in HDR mode - relying on PWM for setting the brightness level in SDR mode. For the time being we've been using EDIDs to maintain a list of quirks for panels that safely do support the VESA backlight interface. Adding support for Intel's HDR backlight interface in addition however, should finally allow us to auto-detect eDP backlight controls properly so long as we probe like so: * If the panel's VBT reports VESA backlight support, assume it really does support it * If the panel's VBT reports DDI backlight controls: * First probe for Intel's HDR backlight interface * If that fails, probe for VESA's backlight interface * If that fails, assume no DPCD backlight control * If the panel's VBT reports any other backlight type: just assume it doesn't have DPCD backlight controls Changes since v4: * Fix checkpatch issues Changes since v3: * Stop using drm_device and use drm_i915_private instead * Don't forget to return from intel_dp_aux_hdr_get_backlight() if we fail to read the current backlight mode from the DPCD * s/uint8_t/u8/ * Remove unneeded parenthesis in intel_dp_aux_hdr_enable_backlight() * Use drm_dbg_kms() in intel_dp_aux_init_backlight_funcs() 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-4-lyude@redhat.com
2020-06-29 19:01:49 +00:00
return false;
if (!(tcon_cap[1] & INTEL_EDP_HDR_TCON_BRIGHTNESS_NITS_CAP))
return false;
if (tcon_cap[0] >= 1) {
drm_dbg_kms(&i915->drm, "Detected Intel HDR backlight interface version %d\n",
tcon_cap[0]);
} else {
drm_dbg_kms(&i915->drm, "Detected unsupported HDR backlight interface version %d\n",
tcon_cap[0]);
return false;
}
panel->backlight.edp.intel.sdr_uses_aux =
tcon_cap[2] & INTEL_EDP_SDR_TCON_BRIGHTNESS_AUX_CAP;
return true;
}
static u32
intel_dp_aux_hdr_get_backlight(struct intel_connector *connector, enum pipe pipe)
{
struct drm_i915_private *i915 = to_i915(connector->base.dev);
struct intel_panel *panel = &connector->panel;
struct intel_dp *intel_dp = enc_to_intel_dp(connector->encoder);
u8 tmp;
u8 buf[2] = { 0 };
if (drm_dp_dpcd_readb(&intel_dp->aux, INTEL_EDP_HDR_GETSET_CTRL_PARAMS, &tmp) != 1) {
drm/i915/dp: Enable Intel's HDR backlight interface (only SDR for now) So-recently a bunch of laptops on the market have started using DPCD backlight controls instead of the traditional DDI backlight controls. Originally we thought we had this handled by adding VESA backlight control support to i915, but the story ended up being a lot more complicated then that. Simply put-there's two main backlight interfaces Intel can see in the wild. Intel's proprietary HDR backlight interface, and the standard VESA backlight interface. Note that many panels have been observed to report support for both backlight interfaces, but testing has shown far more panels work with the Intel HDR backlight interface at the moment. Additionally, the VBT appears to be capable of reporting support for the VESA backlight interface but not the Intel HDR interface which needs to be probed by setting the right magic OUI. On top of that however, there's also actually two different variants of the Intel HDR backlight interface. The first uses the AUX channel for controlling the brightness of the screen in both SDR and HDR mode, and the second only uses the AUX channel for setting the brightness level in HDR mode - relying on PWM for setting the brightness level in SDR mode. For the time being we've been using EDIDs to maintain a list of quirks for panels that safely do support the VESA backlight interface. Adding support for Intel's HDR backlight interface in addition however, should finally allow us to auto-detect eDP backlight controls properly so long as we probe like so: * If the panel's VBT reports VESA backlight support, assume it really does support it * If the panel's VBT reports DDI backlight controls: * First probe for Intel's HDR backlight interface * If that fails, probe for VESA's backlight interface * If that fails, assume no DPCD backlight control * If the panel's VBT reports any other backlight type: just assume it doesn't have DPCD backlight controls Changes since v4: * Fix checkpatch issues Changes since v3: * Stop using drm_device and use drm_i915_private instead * Don't forget to return from intel_dp_aux_hdr_get_backlight() if we fail to read the current backlight mode from the DPCD * s/uint8_t/u8/ * Remove unneeded parenthesis in intel_dp_aux_hdr_enable_backlight() * Use drm_dbg_kms() in intel_dp_aux_init_backlight_funcs() 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-4-lyude@redhat.com
2020-06-29 19:01:49 +00:00
drm_err(&i915->drm, "Failed to read current backlight mode from DPCD\n");
return 0;
}
if (!(tmp & INTEL_EDP_HDR_TCON_BRIGHTNESS_AUX_ENABLE)) {
if (!panel->backlight.edp.intel.sdr_uses_aux) {
u32 pwm_level = panel->backlight.pwm_funcs->get(connector, pipe);
return intel_panel_backlight_level_from_pwm(connector, pwm_level);
}
/* Assume 100% brightness if backlight controls aren't enabled yet */
return panel->backlight.max;
}
if (drm_dp_dpcd_read(&intel_dp->aux, INTEL_EDP_BRIGHTNESS_NITS_LSB, buf,
sizeof(buf)) != sizeof(buf)) {
drm/i915/dp: Enable Intel's HDR backlight interface (only SDR for now) So-recently a bunch of laptops on the market have started using DPCD backlight controls instead of the traditional DDI backlight controls. Originally we thought we had this handled by adding VESA backlight control support to i915, but the story ended up being a lot more complicated then that. Simply put-there's two main backlight interfaces Intel can see in the wild. Intel's proprietary HDR backlight interface, and the standard VESA backlight interface. Note that many panels have been observed to report support for both backlight interfaces, but testing has shown far more panels work with the Intel HDR backlight interface at the moment. Additionally, the VBT appears to be capable of reporting support for the VESA backlight interface but not the Intel HDR interface which needs to be probed by setting the right magic OUI. On top of that however, there's also actually two different variants of the Intel HDR backlight interface. The first uses the AUX channel for controlling the brightness of the screen in both SDR and HDR mode, and the second only uses the AUX channel for setting the brightness level in HDR mode - relying on PWM for setting the brightness level in SDR mode. For the time being we've been using EDIDs to maintain a list of quirks for panels that safely do support the VESA backlight interface. Adding support for Intel's HDR backlight interface in addition however, should finally allow us to auto-detect eDP backlight controls properly so long as we probe like so: * If the panel's VBT reports VESA backlight support, assume it really does support it * If the panel's VBT reports DDI backlight controls: * First probe for Intel's HDR backlight interface * If that fails, probe for VESA's backlight interface * If that fails, assume no DPCD backlight control * If the panel's VBT reports any other backlight type: just assume it doesn't have DPCD backlight controls Changes since v4: * Fix checkpatch issues Changes since v3: * Stop using drm_device and use drm_i915_private instead * Don't forget to return from intel_dp_aux_hdr_get_backlight() if we fail to read the current backlight mode from the DPCD * s/uint8_t/u8/ * Remove unneeded parenthesis in intel_dp_aux_hdr_enable_backlight() * Use drm_dbg_kms() in intel_dp_aux_init_backlight_funcs() 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-4-lyude@redhat.com
2020-06-29 19:01:49 +00:00
drm_err(&i915->drm, "Failed to read brightness from DPCD\n");
return 0;
}
return (buf[1] << 8 | buf[0]);
}
static void
intel_dp_aux_hdr_set_aux_backlight(const struct drm_connector_state *conn_state, u32 level)
{
struct intel_connector *connector = to_intel_connector(conn_state->connector);
struct drm_device *dev = connector->base.dev;
struct intel_dp *intel_dp = enc_to_intel_dp(connector->encoder);
u8 buf[4] = { 0 };
buf[0] = level & 0xFF;
buf[1] = (level & 0xFF00) >> 8;
if (drm_dp_dpcd_write(&intel_dp->aux, INTEL_EDP_BRIGHTNESS_NITS_LSB, buf,
sizeof(buf)) != sizeof(buf))
drm/i915/dp: Enable Intel's HDR backlight interface (only SDR for now) So-recently a bunch of laptops on the market have started using DPCD backlight controls instead of the traditional DDI backlight controls. Originally we thought we had this handled by adding VESA backlight control support to i915, but the story ended up being a lot more complicated then that. Simply put-there's two main backlight interfaces Intel can see in the wild. Intel's proprietary HDR backlight interface, and the standard VESA backlight interface. Note that many panels have been observed to report support for both backlight interfaces, but testing has shown far more panels work with the Intel HDR backlight interface at the moment. Additionally, the VBT appears to be capable of reporting support for the VESA backlight interface but not the Intel HDR interface which needs to be probed by setting the right magic OUI. On top of that however, there's also actually two different variants of the Intel HDR backlight interface. The first uses the AUX channel for controlling the brightness of the screen in both SDR and HDR mode, and the second only uses the AUX channel for setting the brightness level in HDR mode - relying on PWM for setting the brightness level in SDR mode. For the time being we've been using EDIDs to maintain a list of quirks for panels that safely do support the VESA backlight interface. Adding support for Intel's HDR backlight interface in addition however, should finally allow us to auto-detect eDP backlight controls properly so long as we probe like so: * If the panel's VBT reports VESA backlight support, assume it really does support it * If the panel's VBT reports DDI backlight controls: * First probe for Intel's HDR backlight interface * If that fails, probe for VESA's backlight interface * If that fails, assume no DPCD backlight control * If the panel's VBT reports any other backlight type: just assume it doesn't have DPCD backlight controls Changes since v4: * Fix checkpatch issues Changes since v3: * Stop using drm_device and use drm_i915_private instead * Don't forget to return from intel_dp_aux_hdr_get_backlight() if we fail to read the current backlight mode from the DPCD * s/uint8_t/u8/ * Remove unneeded parenthesis in intel_dp_aux_hdr_enable_backlight() * Use drm_dbg_kms() in intel_dp_aux_init_backlight_funcs() 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-4-lyude@redhat.com
2020-06-29 19:01:49 +00:00
drm_err(dev, "Failed to write brightness level to DPCD\n");
}
static void
intel_dp_aux_hdr_set_backlight(const struct drm_connector_state *conn_state, u32 level)
{
struct intel_connector *connector = to_intel_connector(conn_state->connector);
struct intel_panel *panel = &connector->panel;
if (panel->backlight.edp.intel.sdr_uses_aux) {
intel_dp_aux_hdr_set_aux_backlight(conn_state, level);
} else {
const u32 pwm_level = intel_panel_backlight_level_to_pwm(connector, level);
intel_panel_set_pwm_level(conn_state, pwm_level);
}
}
static void
intel_dp_aux_hdr_enable_backlight(const struct intel_crtc_state *crtc_state,
const struct drm_connector_state *conn_state, u32 level)
{
struct intel_connector *connector = to_intel_connector(conn_state->connector);
struct intel_panel *panel = &connector->panel;
struct drm_i915_private *i915 = to_i915(connector->base.dev);
struct intel_dp *intel_dp = enc_to_intel_dp(connector->encoder);
int ret;
u8 old_ctrl, ctrl;
ret = drm_dp_dpcd_readb(&intel_dp->aux, INTEL_EDP_HDR_GETSET_CTRL_PARAMS, &old_ctrl);
if (ret != 1) {
drm/i915/dp: Enable Intel's HDR backlight interface (only SDR for now) So-recently a bunch of laptops on the market have started using DPCD backlight controls instead of the traditional DDI backlight controls. Originally we thought we had this handled by adding VESA backlight control support to i915, but the story ended up being a lot more complicated then that. Simply put-there's two main backlight interfaces Intel can see in the wild. Intel's proprietary HDR backlight interface, and the standard VESA backlight interface. Note that many panels have been observed to report support for both backlight interfaces, but testing has shown far more panels work with the Intel HDR backlight interface at the moment. Additionally, the VBT appears to be capable of reporting support for the VESA backlight interface but not the Intel HDR interface which needs to be probed by setting the right magic OUI. On top of that however, there's also actually two different variants of the Intel HDR backlight interface. The first uses the AUX channel for controlling the brightness of the screen in both SDR and HDR mode, and the second only uses the AUX channel for setting the brightness level in HDR mode - relying on PWM for setting the brightness level in SDR mode. For the time being we've been using EDIDs to maintain a list of quirks for panels that safely do support the VESA backlight interface. Adding support for Intel's HDR backlight interface in addition however, should finally allow us to auto-detect eDP backlight controls properly so long as we probe like so: * If the panel's VBT reports VESA backlight support, assume it really does support it * If the panel's VBT reports DDI backlight controls: * First probe for Intel's HDR backlight interface * If that fails, probe for VESA's backlight interface * If that fails, assume no DPCD backlight control * If the panel's VBT reports any other backlight type: just assume it doesn't have DPCD backlight controls Changes since v4: * Fix checkpatch issues Changes since v3: * Stop using drm_device and use drm_i915_private instead * Don't forget to return from intel_dp_aux_hdr_get_backlight() if we fail to read the current backlight mode from the DPCD * s/uint8_t/u8/ * Remove unneeded parenthesis in intel_dp_aux_hdr_enable_backlight() * Use drm_dbg_kms() in intel_dp_aux_init_backlight_funcs() 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-4-lyude@redhat.com
2020-06-29 19:01:49 +00:00
drm_err(&i915->drm, "Failed to read current backlight control mode: %d\n", ret);
return;
}
ctrl = old_ctrl;
if (panel->backlight.edp.intel.sdr_uses_aux) {
ctrl |= INTEL_EDP_HDR_TCON_BRIGHTNESS_AUX_ENABLE;
intel_dp_aux_hdr_set_aux_backlight(conn_state, level);
} else {
u32 pwm_level = intel_panel_backlight_level_to_pwm(connector, level);
panel->backlight.pwm_funcs->enable(crtc_state, conn_state, pwm_level);
ctrl &= ~INTEL_EDP_HDR_TCON_BRIGHTNESS_AUX_ENABLE;
}
if (ctrl != old_ctrl)
if (drm_dp_dpcd_writeb(&intel_dp->aux, INTEL_EDP_HDR_GETSET_CTRL_PARAMS, ctrl) != 1)
drm/i915/dp: Enable Intel's HDR backlight interface (only SDR for now) So-recently a bunch of laptops on the market have started using DPCD backlight controls instead of the traditional DDI backlight controls. Originally we thought we had this handled by adding VESA backlight control support to i915, but the story ended up being a lot more complicated then that. Simply put-there's two main backlight interfaces Intel can see in the wild. Intel's proprietary HDR backlight interface, and the standard VESA backlight interface. Note that many panels have been observed to report support for both backlight interfaces, but testing has shown far more panels work with the Intel HDR backlight interface at the moment. Additionally, the VBT appears to be capable of reporting support for the VESA backlight interface but not the Intel HDR interface which needs to be probed by setting the right magic OUI. On top of that however, there's also actually two different variants of the Intel HDR backlight interface. The first uses the AUX channel for controlling the brightness of the screen in both SDR and HDR mode, and the second only uses the AUX channel for setting the brightness level in HDR mode - relying on PWM for setting the brightness level in SDR mode. For the time being we've been using EDIDs to maintain a list of quirks for panels that safely do support the VESA backlight interface. Adding support for Intel's HDR backlight interface in addition however, should finally allow us to auto-detect eDP backlight controls properly so long as we probe like so: * If the panel's VBT reports VESA backlight support, assume it really does support it * If the panel's VBT reports DDI backlight controls: * First probe for Intel's HDR backlight interface * If that fails, probe for VESA's backlight interface * If that fails, assume no DPCD backlight control * If the panel's VBT reports any other backlight type: just assume it doesn't have DPCD backlight controls Changes since v4: * Fix checkpatch issues Changes since v3: * Stop using drm_device and use drm_i915_private instead * Don't forget to return from intel_dp_aux_hdr_get_backlight() if we fail to read the current backlight mode from the DPCD * s/uint8_t/u8/ * Remove unneeded parenthesis in intel_dp_aux_hdr_enable_backlight() * Use drm_dbg_kms() in intel_dp_aux_init_backlight_funcs() 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-4-lyude@redhat.com
2020-06-29 19:01:49 +00:00
drm_err(&i915->drm, "Failed to configure DPCD brightness controls\n");
}
static void
intel_dp_aux_hdr_disable_backlight(const struct drm_connector_state *conn_state, u32 level)
{
struct intel_connector *connector = to_intel_connector(conn_state->connector);
struct intel_panel *panel = &connector->panel;
/* Nothing to do for AUX based backlight controls */
if (panel->backlight.edp.intel.sdr_uses_aux)
return;
/* Note we want the actual pwm_level to be 0, regardless of pwm_min */
panel->backlight.pwm_funcs->disable(conn_state, intel_panel_invert_pwm_level(connector, 0));
}
static int
intel_dp_aux_hdr_setup_backlight(struct intel_connector *connector, enum pipe pipe)
{
struct drm_i915_private *i915 = to_i915(connector->base.dev);
struct intel_panel *panel = &connector->panel;
int ret;
if (panel->backlight.edp.intel.sdr_uses_aux) {
drm_dbg_kms(&i915->drm, "SDR backlight is controlled through DPCD\n");
} else {
drm_dbg_kms(&i915->drm, "SDR backlight is controlled through PWM\n");
ret = panel->backlight.pwm_funcs->setup(connector, pipe);
if (ret < 0) {
drm_err(&i915->drm,
"Failed to setup SDR backlight controls through PWM: %d\n", ret);
return ret;
}
}
panel->backlight.max = 512;
panel->backlight.min = 0;
panel->backlight.level = intel_dp_aux_hdr_get_backlight(connector, pipe);
panel->backlight.enabled = panel->backlight.level != 0;
return 0;
}
/* VESA backlight callbacks */
static u32 intel_dp_aux_vesa_get_backlight(struct intel_connector *connector, enum pipe unused)
{
drm/dp: Extract i915's eDP backlight code into DRM helpers Since we're about to implement eDP backlight support in nouveau using the standard protocol from VESA, we might as well just take the code that's already written for this and move it into a set of shared DRM helpers. Note that these helpers are intended to handle DPCD related backlight control bits such as setting the brightness level over AUX, probing the backlight's TCON, enabling/disabling the backlight over AUX if supported, etc. Any PWM-related portions of backlight control are explicitly left up to the driver, as these will vary from platform to platform. The only exception to this is the calculation of the PWM frequency pre-divider value. This is because the only platform-specific information required for this is the PWM frequency of the panel, which the driver is expected to provide if available. The actual algorithm for calculating this value is standard and is defined in the eDP specification from VESA. Note that these helpers do not yet implement the full range of features the VESA backlight interface provides, and only provide the following functionality (all of which was already present in i915's DPCD backlight support): * Basic control of brightness levels * Basic probing of backlight capabilities * Helpers for enabling and disabling the backlight v3: * Split out changes to i915's backlight code to separate patches to make it easier to review v4: * Style/spelling changes from Thomas Zimmermann v5: * Start using new drm_dbg_*() functions Signed-off-by: Lyude Paul <lyude@redhat.com> Cc: Jani Nikula <jani.nikula@intel.com> Cc: Dave Airlie <airlied@gmail.com> Cc: greg.depoire@gmail.com Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210514181504.565252-9-lyude@redhat.com
2021-05-14 18:15:02 +00:00
return connector->panel.backlight.level;
}
static void
drm/dp: Extract i915's eDP backlight code into DRM helpers Since we're about to implement eDP backlight support in nouveau using the standard protocol from VESA, we might as well just take the code that's already written for this and move it into a set of shared DRM helpers. Note that these helpers are intended to handle DPCD related backlight control bits such as setting the brightness level over AUX, probing the backlight's TCON, enabling/disabling the backlight over AUX if supported, etc. Any PWM-related portions of backlight control are explicitly left up to the driver, as these will vary from platform to platform. The only exception to this is the calculation of the PWM frequency pre-divider value. This is because the only platform-specific information required for this is the PWM frequency of the panel, which the driver is expected to provide if available. The actual algorithm for calculating this value is standard and is defined in the eDP specification from VESA. Note that these helpers do not yet implement the full range of features the VESA backlight interface provides, and only provide the following functionality (all of which was already present in i915's DPCD backlight support): * Basic control of brightness levels * Basic probing of backlight capabilities * Helpers for enabling and disabling the backlight v3: * Split out changes to i915's backlight code to separate patches to make it easier to review v4: * Style/spelling changes from Thomas Zimmermann v5: * Start using new drm_dbg_*() functions Signed-off-by: Lyude Paul <lyude@redhat.com> Cc: Jani Nikula <jani.nikula@intel.com> Cc: Dave Airlie <airlied@gmail.com> Cc: greg.depoire@gmail.com Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210514181504.565252-9-lyude@redhat.com
2021-05-14 18:15:02 +00:00
intel_dp_aux_vesa_set_backlight(const struct drm_connector_state *conn_state, u32 level)
{
drm/i915: Pass atomic state to backlight enable/disable/set callbacks. Pass crtc_state to the enable callback, and connector_state to all callbacks. This will eliminate the need to guess for the correct pipe in these callbacks. The crtc state is required for pch_enable_backlight to obtain the correct cpu_transcoder. intel_dp_aux_backlight's setup function is called before hw readout, so crtc_state and connector_state->best_encoder are NULL in the enable() and set() callbacks. This fixes the following series of warns from intel_get_pipe_from_connector: [ 219.968428] ------------[ cut here ]------------ [ 219.968481] WARNING: CPU: 3 PID: 2457 at drivers/gpu/drm/i915/intel_display.c:13881 intel_get_pipe_from_connector+0x62/0x90 [i915] [ 219.968483] WARN_ON(!drm_modeset_is_locked(&dev->mode_config.connection_mutex)) [ 219.968485] Modules linked in: nls_iso8859_1 snd_hda_codec_hdmi snd_hda_codec_realtek snd_hda_codec_generic snd_hda_intel snd_hda_codec snd_hda_core snd_hwdep snd_pcm intel_rapl x86_pkg_temp_thermal coretemp kvm_intel snd_seq_midi snd_seq_midi_event kvm snd_rawmidi irqbypass crct10dif_pclmul crc32_pclmul ghash_clmulni_intel pcbc snd_seq snd_seq_device serio_raw snd_timer aesni_intel aes_x86_64 crypto_simd glue_helper cryptd lpc_ich snd mei_me shpchp soundcore mei rfkill_gpio mac_hid intel_pmc_ipc parport_pc ppdev lp parport ip_tables x_tables autofs4 hid_generic usbhid igb ahci i915 xhci_pci dca xhci_hcd ptp sdhci_pci sdhci libahci pps_core i2c_hid hid video [ 219.968573] CPU: 3 PID: 2457 Comm: kworker/u8:3 Tainted: G W 4.10.0-tip-201703010159+ #2 [ 219.968575] Hardware name: Intel Corp. Broxton P/NOTEBOOK, BIOS APLKRVPA.X64.0144.B10.1606270006 06/27/2016 [ 219.968627] Workqueue: events_unbound intel_atomic_commit_work [i915] [ 219.968629] Call Trace: [ 219.968640] dump_stack+0x63/0x87 [ 219.968646] __warn+0xd1/0xf0 [ 219.968651] warn_slowpath_fmt+0x4f/0x60 [ 219.968657] ? drm_printk+0x97/0xa0 [ 219.968708] intel_get_pipe_from_connector+0x62/0x90 [i915] [ 219.968756] intel_panel_enable_backlight+0x19/0xf0 [i915] [ 219.968804] intel_edp_backlight_on.part.22+0x33/0x40 [i915] [ 219.968852] intel_edp_backlight_on+0x18/0x20 [i915] [ 219.968900] intel_enable_ddi+0x94/0xc0 [i915] [ 219.968950] intel_encoders_enable.isra.93+0x77/0x90 [i915] [ 219.969000] haswell_crtc_enable+0x310/0x7f0 [i915] [ 219.969051] intel_update_crtc+0x58/0x100 [i915] [ 219.969101] skl_update_crtcs+0x218/0x240 [i915] [ 219.969153] intel_atomic_commit_tail+0x350/0x1000 [i915] [ 219.969159] ? vtime_account_idle+0xe/0x50 [ 219.969164] ? finish_task_switch+0x107/0x250 [ 219.969214] intel_atomic_commit_work+0x12/0x20 [i915] [ 219.969219] process_one_work+0x153/0x3f0 [ 219.969223] worker_thread+0x12b/0x4b0 [ 219.969227] kthread+0x101/0x140 [ 219.969230] ? rescuer_thread+0x340/0x340 [ 219.969233] ? kthread_park+0x90/0x90 [ 219.969237] ? do_syscall_64+0x6e/0x180 [ 219.969243] ret_from_fork+0x2c/0x40 [ 219.969246] ---[ end trace 0a8fa19387b9ad6d ]--- Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=100022 Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/20170612102115.23665-4-maarten.lankhorst@linux.intel.com Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
2017-06-12 10:21:15 +00:00
struct intel_connector *connector = to_intel_connector(conn_state->connector);
drm/dp: Extract i915's eDP backlight code into DRM helpers Since we're about to implement eDP backlight support in nouveau using the standard protocol from VESA, we might as well just take the code that's already written for this and move it into a set of shared DRM helpers. Note that these helpers are intended to handle DPCD related backlight control bits such as setting the brightness level over AUX, probing the backlight's TCON, enabling/disabling the backlight over AUX if supported, etc. Any PWM-related portions of backlight control are explicitly left up to the driver, as these will vary from platform to platform. The only exception to this is the calculation of the PWM frequency pre-divider value. This is because the only platform-specific information required for this is the PWM frequency of the panel, which the driver is expected to provide if available. The actual algorithm for calculating this value is standard and is defined in the eDP specification from VESA. Note that these helpers do not yet implement the full range of features the VESA backlight interface provides, and only provide the following functionality (all of which was already present in i915's DPCD backlight support): * Basic control of brightness levels * Basic probing of backlight capabilities * Helpers for enabling and disabling the backlight v3: * Split out changes to i915's backlight code to separate patches to make it easier to review v4: * Style/spelling changes from Thomas Zimmermann v5: * Start using new drm_dbg_*() functions Signed-off-by: Lyude Paul <lyude@redhat.com> Cc: Jani Nikula <jani.nikula@intel.com> Cc: Dave Airlie <airlied@gmail.com> Cc: greg.depoire@gmail.com Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210514181504.565252-9-lyude@redhat.com
2021-05-14 18:15:02 +00:00
struct intel_panel *panel = &connector->panel;
struct intel_dp *intel_dp = enc_to_intel_dp(connector->encoder);
drm/dp: Extract i915's eDP backlight code into DRM helpers Since we're about to implement eDP backlight support in nouveau using the standard protocol from VESA, we might as well just take the code that's already written for this and move it into a set of shared DRM helpers. Note that these helpers are intended to handle DPCD related backlight control bits such as setting the brightness level over AUX, probing the backlight's TCON, enabling/disabling the backlight over AUX if supported, etc. Any PWM-related portions of backlight control are explicitly left up to the driver, as these will vary from platform to platform. The only exception to this is the calculation of the PWM frequency pre-divider value. This is because the only platform-specific information required for this is the PWM frequency of the panel, which the driver is expected to provide if available. The actual algorithm for calculating this value is standard and is defined in the eDP specification from VESA. Note that these helpers do not yet implement the full range of features the VESA backlight interface provides, and only provide the following functionality (all of which was already present in i915's DPCD backlight support): * Basic control of brightness levels * Basic probing of backlight capabilities * Helpers for enabling and disabling the backlight v3: * Split out changes to i915's backlight code to separate patches to make it easier to review v4: * Style/spelling changes from Thomas Zimmermann v5: * Start using new drm_dbg_*() functions Signed-off-by: Lyude Paul <lyude@redhat.com> Cc: Jani Nikula <jani.nikula@intel.com> Cc: Dave Airlie <airlied@gmail.com> Cc: greg.depoire@gmail.com Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210514181504.565252-9-lyude@redhat.com
2021-05-14 18:15:02 +00:00
drm_edp_backlight_set_level(&intel_dp->aux, &panel->backlight.edp.vesa.info, level);
}
static void
intel_dp_aux_vesa_enable_backlight(const struct intel_crtc_state *crtc_state,
const struct drm_connector_state *conn_state, u32 level)
{
drm/i915: Pass atomic state to backlight enable/disable/set callbacks. Pass crtc_state to the enable callback, and connector_state to all callbacks. This will eliminate the need to guess for the correct pipe in these callbacks. The crtc state is required for pch_enable_backlight to obtain the correct cpu_transcoder. intel_dp_aux_backlight's setup function is called before hw readout, so crtc_state and connector_state->best_encoder are NULL in the enable() and set() callbacks. This fixes the following series of warns from intel_get_pipe_from_connector: [ 219.968428] ------------[ cut here ]------------ [ 219.968481] WARNING: CPU: 3 PID: 2457 at drivers/gpu/drm/i915/intel_display.c:13881 intel_get_pipe_from_connector+0x62/0x90 [i915] [ 219.968483] WARN_ON(!drm_modeset_is_locked(&dev->mode_config.connection_mutex)) [ 219.968485] Modules linked in: nls_iso8859_1 snd_hda_codec_hdmi snd_hda_codec_realtek snd_hda_codec_generic snd_hda_intel snd_hda_codec snd_hda_core snd_hwdep snd_pcm intel_rapl x86_pkg_temp_thermal coretemp kvm_intel snd_seq_midi snd_seq_midi_event kvm snd_rawmidi irqbypass crct10dif_pclmul crc32_pclmul ghash_clmulni_intel pcbc snd_seq snd_seq_device serio_raw snd_timer aesni_intel aes_x86_64 crypto_simd glue_helper cryptd lpc_ich snd mei_me shpchp soundcore mei rfkill_gpio mac_hid intel_pmc_ipc parport_pc ppdev lp parport ip_tables x_tables autofs4 hid_generic usbhid igb ahci i915 xhci_pci dca xhci_hcd ptp sdhci_pci sdhci libahci pps_core i2c_hid hid video [ 219.968573] CPU: 3 PID: 2457 Comm: kworker/u8:3 Tainted: G W 4.10.0-tip-201703010159+ #2 [ 219.968575] Hardware name: Intel Corp. Broxton P/NOTEBOOK, BIOS APLKRVPA.X64.0144.B10.1606270006 06/27/2016 [ 219.968627] Workqueue: events_unbound intel_atomic_commit_work [i915] [ 219.968629] Call Trace: [ 219.968640] dump_stack+0x63/0x87 [ 219.968646] __warn+0xd1/0xf0 [ 219.968651] warn_slowpath_fmt+0x4f/0x60 [ 219.968657] ? drm_printk+0x97/0xa0 [ 219.968708] intel_get_pipe_from_connector+0x62/0x90 [i915] [ 219.968756] intel_panel_enable_backlight+0x19/0xf0 [i915] [ 219.968804] intel_edp_backlight_on.part.22+0x33/0x40 [i915] [ 219.968852] intel_edp_backlight_on+0x18/0x20 [i915] [ 219.968900] intel_enable_ddi+0x94/0xc0 [i915] [ 219.968950] intel_encoders_enable.isra.93+0x77/0x90 [i915] [ 219.969000] haswell_crtc_enable+0x310/0x7f0 [i915] [ 219.969051] intel_update_crtc+0x58/0x100 [i915] [ 219.969101] skl_update_crtcs+0x218/0x240 [i915] [ 219.969153] intel_atomic_commit_tail+0x350/0x1000 [i915] [ 219.969159] ? vtime_account_idle+0xe/0x50 [ 219.969164] ? finish_task_switch+0x107/0x250 [ 219.969214] intel_atomic_commit_work+0x12/0x20 [i915] [ 219.969219] process_one_work+0x153/0x3f0 [ 219.969223] worker_thread+0x12b/0x4b0 [ 219.969227] kthread+0x101/0x140 [ 219.969230] ? rescuer_thread+0x340/0x340 [ 219.969233] ? kthread_park+0x90/0x90 [ 219.969237] ? do_syscall_64+0x6e/0x180 [ 219.969243] ret_from_fork+0x2c/0x40 [ 219.969246] ---[ end trace 0a8fa19387b9ad6d ]--- Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=100022 Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/20170612102115.23665-4-maarten.lankhorst@linux.intel.com Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
2017-06-12 10:21:15 +00:00
struct intel_connector *connector = to_intel_connector(conn_state->connector);
drm/i915: Fix eDP DPCD aux max backlight calculations Max backlight value for the panel was being calculated using byte count i.e. 0xffff if 2 bytes are supported for backlight brightness and 0xff if 1 byte is supported. However, EDP_PWMGEN_BIT_COUNT determines the number of active control bits used for the brightness setting. Thus, even if the panel uses 2 byte setting, it might not use all the control bits. Thus, max backlight should be set based on the value of EDP_PWMGEN_BIT_COUNT instead of assuming 65535 or 255. Additionally, EDP_PWMGEN_BIT_COUNT was being updated based on the VBT frequency which results in a different max backlight value. Thus, setting of EDP_PWMGEN_BIT_COUNT is moved to setup phase instead of enable so that max backlight can be calculated correctly. Only the frequency divider is set during the enable phase using the value of EDP_PWMGEN_BIT_COUNT. This is based off the original patch series from Furquan Shaikh <furquan@google.com>: https://patchwork.freedesktop.org/patch/317255/?series=62326&rev=3 Changes since original patch: * Remove unused intel_dp variable in intel_dp_aux_setup_backlight() * Fix checkpatch issues * Make sure that we rewrite the pwmgen bit count whenever we bring the panel out of D3 mode v2 by Jani: * rebase * fix readb return value check Cc: Furquan Shaikh <furquan@google.com> Tested-by: AceLan Kao <acelan.kao@canonical.com> Tested-by: Perry Yuan <pyuan@redhat.com> Signed-off-by: Lyude Paul <lyude@redhat.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200116211623.53799-2-lyude@redhat.com
2020-01-16 21:16:08 +00:00
struct intel_panel *panel = &connector->panel;
drm/dp: Extract i915's eDP backlight code into DRM helpers Since we're about to implement eDP backlight support in nouveau using the standard protocol from VESA, we might as well just take the code that's already written for this and move it into a set of shared DRM helpers. Note that these helpers are intended to handle DPCD related backlight control bits such as setting the brightness level over AUX, probing the backlight's TCON, enabling/disabling the backlight over AUX if supported, etc. Any PWM-related portions of backlight control are explicitly left up to the driver, as these will vary from platform to platform. The only exception to this is the calculation of the PWM frequency pre-divider value. This is because the only platform-specific information required for this is the PWM frequency of the panel, which the driver is expected to provide if available. The actual algorithm for calculating this value is standard and is defined in the eDP specification from VESA. Note that these helpers do not yet implement the full range of features the VESA backlight interface provides, and only provide the following functionality (all of which was already present in i915's DPCD backlight support): * Basic control of brightness levels * Basic probing of backlight capabilities * Helpers for enabling and disabling the backlight v3: * Split out changes to i915's backlight code to separate patches to make it easier to review v4: * Style/spelling changes from Thomas Zimmermann v5: * Start using new drm_dbg_*() functions Signed-off-by: Lyude Paul <lyude@redhat.com> Cc: Jani Nikula <jani.nikula@intel.com> Cc: Dave Airlie <airlied@gmail.com> Cc: greg.depoire@gmail.com Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210514181504.565252-9-lyude@redhat.com
2021-05-14 18:15:02 +00:00
struct intel_dp *intel_dp = enc_to_intel_dp(connector->encoder);
drm/dp: Extract i915's eDP backlight code into DRM helpers Since we're about to implement eDP backlight support in nouveau using the standard protocol from VESA, we might as well just take the code that's already written for this and move it into a set of shared DRM helpers. Note that these helpers are intended to handle DPCD related backlight control bits such as setting the brightness level over AUX, probing the backlight's TCON, enabling/disabling the backlight over AUX if supported, etc. Any PWM-related portions of backlight control are explicitly left up to the driver, as these will vary from platform to platform. The only exception to this is the calculation of the PWM frequency pre-divider value. This is because the only platform-specific information required for this is the PWM frequency of the panel, which the driver is expected to provide if available. The actual algorithm for calculating this value is standard and is defined in the eDP specification from VESA. Note that these helpers do not yet implement the full range of features the VESA backlight interface provides, and only provide the following functionality (all of which was already present in i915's DPCD backlight support): * Basic control of brightness levels * Basic probing of backlight capabilities * Helpers for enabling and disabling the backlight v3: * Split out changes to i915's backlight code to separate patches to make it easier to review v4: * Style/spelling changes from Thomas Zimmermann v5: * Start using new drm_dbg_*() functions Signed-off-by: Lyude Paul <lyude@redhat.com> Cc: Jani Nikula <jani.nikula@intel.com> Cc: Dave Airlie <airlied@gmail.com> Cc: greg.depoire@gmail.com Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210514181504.565252-9-lyude@redhat.com
2021-05-14 18:15:02 +00:00
drm_edp_backlight_enable(&intel_dp->aux, &panel->backlight.edp.vesa.info, level);
}
static void intel_dp_aux_vesa_disable_backlight(const struct drm_connector_state *old_conn_state,
u32 level)
{
drm/dp: Extract i915's eDP backlight code into DRM helpers Since we're about to implement eDP backlight support in nouveau using the standard protocol from VESA, we might as well just take the code that's already written for this and move it into a set of shared DRM helpers. Note that these helpers are intended to handle DPCD related backlight control bits such as setting the brightness level over AUX, probing the backlight's TCON, enabling/disabling the backlight over AUX if supported, etc. Any PWM-related portions of backlight control are explicitly left up to the driver, as these will vary from platform to platform. The only exception to this is the calculation of the PWM frequency pre-divider value. This is because the only platform-specific information required for this is the PWM frequency of the panel, which the driver is expected to provide if available. The actual algorithm for calculating this value is standard and is defined in the eDP specification from VESA. Note that these helpers do not yet implement the full range of features the VESA backlight interface provides, and only provide the following functionality (all of which was already present in i915's DPCD backlight support): * Basic control of brightness levels * Basic probing of backlight capabilities * Helpers for enabling and disabling the backlight v3: * Split out changes to i915's backlight code to separate patches to make it easier to review v4: * Style/spelling changes from Thomas Zimmermann v5: * Start using new drm_dbg_*() functions Signed-off-by: Lyude Paul <lyude@redhat.com> Cc: Jani Nikula <jani.nikula@intel.com> Cc: Dave Airlie <airlied@gmail.com> Cc: greg.depoire@gmail.com Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210514181504.565252-9-lyude@redhat.com
2021-05-14 18:15:02 +00:00
struct intel_connector *connector = to_intel_connector(old_conn_state->connector);
drm/i915: Fix eDP DPCD aux max backlight calculations Max backlight value for the panel was being calculated using byte count i.e. 0xffff if 2 bytes are supported for backlight brightness and 0xff if 1 byte is supported. However, EDP_PWMGEN_BIT_COUNT determines the number of active control bits used for the brightness setting. Thus, even if the panel uses 2 byte setting, it might not use all the control bits. Thus, max backlight should be set based on the value of EDP_PWMGEN_BIT_COUNT instead of assuming 65535 or 255. Additionally, EDP_PWMGEN_BIT_COUNT was being updated based on the VBT frequency which results in a different max backlight value. Thus, setting of EDP_PWMGEN_BIT_COUNT is moved to setup phase instead of enable so that max backlight can be calculated correctly. Only the frequency divider is set during the enable phase using the value of EDP_PWMGEN_BIT_COUNT. This is based off the original patch series from Furquan Shaikh <furquan@google.com>: https://patchwork.freedesktop.org/patch/317255/?series=62326&rev=3 Changes since original patch: * Remove unused intel_dp variable in intel_dp_aux_setup_backlight() * Fix checkpatch issues * Make sure that we rewrite the pwmgen bit count whenever we bring the panel out of D3 mode v2 by Jani: * rebase * fix readb return value check Cc: Furquan Shaikh <furquan@google.com> Tested-by: AceLan Kao <acelan.kao@canonical.com> Tested-by: Perry Yuan <pyuan@redhat.com> Signed-off-by: Lyude Paul <lyude@redhat.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200116211623.53799-2-lyude@redhat.com
2020-01-16 21:16:08 +00:00
struct intel_panel *panel = &connector->panel;
drm/dp: Extract i915's eDP backlight code into DRM helpers Since we're about to implement eDP backlight support in nouveau using the standard protocol from VESA, we might as well just take the code that's already written for this and move it into a set of shared DRM helpers. Note that these helpers are intended to handle DPCD related backlight control bits such as setting the brightness level over AUX, probing the backlight's TCON, enabling/disabling the backlight over AUX if supported, etc. Any PWM-related portions of backlight control are explicitly left up to the driver, as these will vary from platform to platform. The only exception to this is the calculation of the PWM frequency pre-divider value. This is because the only platform-specific information required for this is the PWM frequency of the panel, which the driver is expected to provide if available. The actual algorithm for calculating this value is standard and is defined in the eDP specification from VESA. Note that these helpers do not yet implement the full range of features the VESA backlight interface provides, and only provide the following functionality (all of which was already present in i915's DPCD backlight support): * Basic control of brightness levels * Basic probing of backlight capabilities * Helpers for enabling and disabling the backlight v3: * Split out changes to i915's backlight code to separate patches to make it easier to review v4: * Style/spelling changes from Thomas Zimmermann v5: * Start using new drm_dbg_*() functions Signed-off-by: Lyude Paul <lyude@redhat.com> Cc: Jani Nikula <jani.nikula@intel.com> Cc: Dave Airlie <airlied@gmail.com> Cc: greg.depoire@gmail.com Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210514181504.565252-9-lyude@redhat.com
2021-05-14 18:15:02 +00:00
struct intel_dp *intel_dp = enc_to_intel_dp(connector->encoder);
drm/i915: Fix eDP DPCD aux max backlight calculations Max backlight value for the panel was being calculated using byte count i.e. 0xffff if 2 bytes are supported for backlight brightness and 0xff if 1 byte is supported. However, EDP_PWMGEN_BIT_COUNT determines the number of active control bits used for the brightness setting. Thus, even if the panel uses 2 byte setting, it might not use all the control bits. Thus, max backlight should be set based on the value of EDP_PWMGEN_BIT_COUNT instead of assuming 65535 or 255. Additionally, EDP_PWMGEN_BIT_COUNT was being updated based on the VBT frequency which results in a different max backlight value. Thus, setting of EDP_PWMGEN_BIT_COUNT is moved to setup phase instead of enable so that max backlight can be calculated correctly. Only the frequency divider is set during the enable phase using the value of EDP_PWMGEN_BIT_COUNT. This is based off the original patch series from Furquan Shaikh <furquan@google.com>: https://patchwork.freedesktop.org/patch/317255/?series=62326&rev=3 Changes since original patch: * Remove unused intel_dp variable in intel_dp_aux_setup_backlight() * Fix checkpatch issues * Make sure that we rewrite the pwmgen bit count whenever we bring the panel out of D3 mode v2 by Jani: * rebase * fix readb return value check Cc: Furquan Shaikh <furquan@google.com> Tested-by: AceLan Kao <acelan.kao@canonical.com> Tested-by: Perry Yuan <pyuan@redhat.com> Signed-off-by: Lyude Paul <lyude@redhat.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200116211623.53799-2-lyude@redhat.com
2020-01-16 21:16:08 +00:00
drm/dp: Extract i915's eDP backlight code into DRM helpers Since we're about to implement eDP backlight support in nouveau using the standard protocol from VESA, we might as well just take the code that's already written for this and move it into a set of shared DRM helpers. Note that these helpers are intended to handle DPCD related backlight control bits such as setting the brightness level over AUX, probing the backlight's TCON, enabling/disabling the backlight over AUX if supported, etc. Any PWM-related portions of backlight control are explicitly left up to the driver, as these will vary from platform to platform. The only exception to this is the calculation of the PWM frequency pre-divider value. This is because the only platform-specific information required for this is the PWM frequency of the panel, which the driver is expected to provide if available. The actual algorithm for calculating this value is standard and is defined in the eDP specification from VESA. Note that these helpers do not yet implement the full range of features the VESA backlight interface provides, and only provide the following functionality (all of which was already present in i915's DPCD backlight support): * Basic control of brightness levels * Basic probing of backlight capabilities * Helpers for enabling and disabling the backlight v3: * Split out changes to i915's backlight code to separate patches to make it easier to review v4: * Style/spelling changes from Thomas Zimmermann v5: * Start using new drm_dbg_*() functions Signed-off-by: Lyude Paul <lyude@redhat.com> Cc: Jani Nikula <jani.nikula@intel.com> Cc: Dave Airlie <airlied@gmail.com> Cc: greg.depoire@gmail.com Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210514181504.565252-9-lyude@redhat.com
2021-05-14 18:15:02 +00:00
drm_edp_backlight_disable(&intel_dp->aux, &panel->backlight.edp.vesa.info);
drm/i915: Fix eDP DPCD aux max backlight calculations Max backlight value for the panel was being calculated using byte count i.e. 0xffff if 2 bytes are supported for backlight brightness and 0xff if 1 byte is supported. However, EDP_PWMGEN_BIT_COUNT determines the number of active control bits used for the brightness setting. Thus, even if the panel uses 2 byte setting, it might not use all the control bits. Thus, max backlight should be set based on the value of EDP_PWMGEN_BIT_COUNT instead of assuming 65535 or 255. Additionally, EDP_PWMGEN_BIT_COUNT was being updated based on the VBT frequency which results in a different max backlight value. Thus, setting of EDP_PWMGEN_BIT_COUNT is moved to setup phase instead of enable so that max backlight can be calculated correctly. Only the frequency divider is set during the enable phase using the value of EDP_PWMGEN_BIT_COUNT. This is based off the original patch series from Furquan Shaikh <furquan@google.com>: https://patchwork.freedesktop.org/patch/317255/?series=62326&rev=3 Changes since original patch: * Remove unused intel_dp variable in intel_dp_aux_setup_backlight() * Fix checkpatch issues * Make sure that we rewrite the pwmgen bit count whenever we bring the panel out of D3 mode v2 by Jani: * rebase * fix readb return value check Cc: Furquan Shaikh <furquan@google.com> Tested-by: AceLan Kao <acelan.kao@canonical.com> Tested-by: Perry Yuan <pyuan@redhat.com> Signed-off-by: Lyude Paul <lyude@redhat.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200116211623.53799-2-lyude@redhat.com
2020-01-16 21:16:08 +00:00
}
drm/dp: Extract i915's eDP backlight code into DRM helpers Since we're about to implement eDP backlight support in nouveau using the standard protocol from VESA, we might as well just take the code that's already written for this and move it into a set of shared DRM helpers. Note that these helpers are intended to handle DPCD related backlight control bits such as setting the brightness level over AUX, probing the backlight's TCON, enabling/disabling the backlight over AUX if supported, etc. Any PWM-related portions of backlight control are explicitly left up to the driver, as these will vary from platform to platform. The only exception to this is the calculation of the PWM frequency pre-divider value. This is because the only platform-specific information required for this is the PWM frequency of the panel, which the driver is expected to provide if available. The actual algorithm for calculating this value is standard and is defined in the eDP specification from VESA. Note that these helpers do not yet implement the full range of features the VESA backlight interface provides, and only provide the following functionality (all of which was already present in i915's DPCD backlight support): * Basic control of brightness levels * Basic probing of backlight capabilities * Helpers for enabling and disabling the backlight v3: * Split out changes to i915's backlight code to separate patches to make it easier to review v4: * Style/spelling changes from Thomas Zimmermann v5: * Start using new drm_dbg_*() functions Signed-off-by: Lyude Paul <lyude@redhat.com> Cc: Jani Nikula <jani.nikula@intel.com> Cc: Dave Airlie <airlied@gmail.com> Cc: greg.depoire@gmail.com Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210514181504.565252-9-lyude@redhat.com
2021-05-14 18:15:02 +00:00
static int intel_dp_aux_vesa_setup_backlight(struct intel_connector *connector, enum pipe pipe)
{
struct intel_dp *intel_dp = intel_attached_dp(connector);
struct intel_panel *panel = &connector->panel;
drm/dp: Extract i915's eDP backlight code into DRM helpers Since we're about to implement eDP backlight support in nouveau using the standard protocol from VESA, we might as well just take the code that's already written for this and move it into a set of shared DRM helpers. Note that these helpers are intended to handle DPCD related backlight control bits such as setting the brightness level over AUX, probing the backlight's TCON, enabling/disabling the backlight over AUX if supported, etc. Any PWM-related portions of backlight control are explicitly left up to the driver, as these will vary from platform to platform. The only exception to this is the calculation of the PWM frequency pre-divider value. This is because the only platform-specific information required for this is the PWM frequency of the panel, which the driver is expected to provide if available. The actual algorithm for calculating this value is standard and is defined in the eDP specification from VESA. Note that these helpers do not yet implement the full range of features the VESA backlight interface provides, and only provide the following functionality (all of which was already present in i915's DPCD backlight support): * Basic control of brightness levels * Basic probing of backlight capabilities * Helpers for enabling and disabling the backlight v3: * Split out changes to i915's backlight code to separate patches to make it easier to review v4: * Style/spelling changes from Thomas Zimmermann v5: * Start using new drm_dbg_*() functions Signed-off-by: Lyude Paul <lyude@redhat.com> Cc: Jani Nikula <jani.nikula@intel.com> Cc: Dave Airlie <airlied@gmail.com> Cc: greg.depoire@gmail.com Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210514181504.565252-9-lyude@redhat.com
2021-05-14 18:15:02 +00:00
struct drm_i915_private *i915 = dp_to_i915(intel_dp);
u16 current_level;
u8 current_mode;
int ret;
drm/dp: Extract i915's eDP backlight code into DRM helpers Since we're about to implement eDP backlight support in nouveau using the standard protocol from VESA, we might as well just take the code that's already written for this and move it into a set of shared DRM helpers. Note that these helpers are intended to handle DPCD related backlight control bits such as setting the brightness level over AUX, probing the backlight's TCON, enabling/disabling the backlight over AUX if supported, etc. Any PWM-related portions of backlight control are explicitly left up to the driver, as these will vary from platform to platform. The only exception to this is the calculation of the PWM frequency pre-divider value. This is because the only platform-specific information required for this is the PWM frequency of the panel, which the driver is expected to provide if available. The actual algorithm for calculating this value is standard and is defined in the eDP specification from VESA. Note that these helpers do not yet implement the full range of features the VESA backlight interface provides, and only provide the following functionality (all of which was already present in i915's DPCD backlight support): * Basic control of brightness levels * Basic probing of backlight capabilities * Helpers for enabling and disabling the backlight v3: * Split out changes to i915's backlight code to separate patches to make it easier to review v4: * Style/spelling changes from Thomas Zimmermann v5: * Start using new drm_dbg_*() functions Signed-off-by: Lyude Paul <lyude@redhat.com> Cc: Jani Nikula <jani.nikula@intel.com> Cc: Dave Airlie <airlied@gmail.com> Cc: greg.depoire@gmail.com Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210514181504.565252-9-lyude@redhat.com
2021-05-14 18:15:02 +00:00
ret = drm_edp_backlight_init(&intel_dp->aux, &panel->backlight.edp.vesa.info,
i915->vbt.backlight.pwm_freq_hz, intel_dp->edp_dpcd,
&current_level, &current_mode);
if (ret < 0)
return ret;
drm/dp: Extract i915's eDP backlight code into DRM helpers Since we're about to implement eDP backlight support in nouveau using the standard protocol from VESA, we might as well just take the code that's already written for this and move it into a set of shared DRM helpers. Note that these helpers are intended to handle DPCD related backlight control bits such as setting the brightness level over AUX, probing the backlight's TCON, enabling/disabling the backlight over AUX if supported, etc. Any PWM-related portions of backlight control are explicitly left up to the driver, as these will vary from platform to platform. The only exception to this is the calculation of the PWM frequency pre-divider value. This is because the only platform-specific information required for this is the PWM frequency of the panel, which the driver is expected to provide if available. The actual algorithm for calculating this value is standard and is defined in the eDP specification from VESA. Note that these helpers do not yet implement the full range of features the VESA backlight interface provides, and only provide the following functionality (all of which was already present in i915's DPCD backlight support): * Basic control of brightness levels * Basic probing of backlight capabilities * Helpers for enabling and disabling the backlight v3: * Split out changes to i915's backlight code to separate patches to make it easier to review v4: * Style/spelling changes from Thomas Zimmermann v5: * Start using new drm_dbg_*() functions Signed-off-by: Lyude Paul <lyude@redhat.com> Cc: Jani Nikula <jani.nikula@intel.com> Cc: Dave Airlie <airlied@gmail.com> Cc: greg.depoire@gmail.com Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210514181504.565252-9-lyude@redhat.com
2021-05-14 18:15:02 +00:00
panel->backlight.max = panel->backlight.edp.vesa.info.max;
panel->backlight.min = 0;
drm/dp: Extract i915's eDP backlight code into DRM helpers Since we're about to implement eDP backlight support in nouveau using the standard protocol from VESA, we might as well just take the code that's already written for this and move it into a set of shared DRM helpers. Note that these helpers are intended to handle DPCD related backlight control bits such as setting the brightness level over AUX, probing the backlight's TCON, enabling/disabling the backlight over AUX if supported, etc. Any PWM-related portions of backlight control are explicitly left up to the driver, as these will vary from platform to platform. The only exception to this is the calculation of the PWM frequency pre-divider value. This is because the only platform-specific information required for this is the PWM frequency of the panel, which the driver is expected to provide if available. The actual algorithm for calculating this value is standard and is defined in the eDP specification from VESA. Note that these helpers do not yet implement the full range of features the VESA backlight interface provides, and only provide the following functionality (all of which was already present in i915's DPCD backlight support): * Basic control of brightness levels * Basic probing of backlight capabilities * Helpers for enabling and disabling the backlight v3: * Split out changes to i915's backlight code to separate patches to make it easier to review v4: * Style/spelling changes from Thomas Zimmermann v5: * Start using new drm_dbg_*() functions Signed-off-by: Lyude Paul <lyude@redhat.com> Cc: Jani Nikula <jani.nikula@intel.com> Cc: Dave Airlie <airlied@gmail.com> Cc: greg.depoire@gmail.com Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210514181504.565252-9-lyude@redhat.com
2021-05-14 18:15:02 +00:00
if (current_mode == DP_EDP_BACKLIGHT_CONTROL_MODE_DPCD) {
panel->backlight.level = current_level;
panel->backlight.enabled = panel->backlight.level != 0;
} else {
panel->backlight.level = panel->backlight.max;
panel->backlight.enabled = false;
}
return 0;
}
static bool
intel_dp_aux_supports_vesa_backlight(struct intel_connector *connector)
{
struct intel_dp *intel_dp = intel_attached_dp(connector);
struct drm_i915_private *i915 = dp_to_i915(intel_dp);
drm/dp: Extract i915's eDP backlight code into DRM helpers Since we're about to implement eDP backlight support in nouveau using the standard protocol from VESA, we might as well just take the code that's already written for this and move it into a set of shared DRM helpers. Note that these helpers are intended to handle DPCD related backlight control bits such as setting the brightness level over AUX, probing the backlight's TCON, enabling/disabling the backlight over AUX if supported, etc. Any PWM-related portions of backlight control are explicitly left up to the driver, as these will vary from platform to platform. The only exception to this is the calculation of the PWM frequency pre-divider value. This is because the only platform-specific information required for this is the PWM frequency of the panel, which the driver is expected to provide if available. The actual algorithm for calculating this value is standard and is defined in the eDP specification from VESA. Note that these helpers do not yet implement the full range of features the VESA backlight interface provides, and only provide the following functionality (all of which was already present in i915's DPCD backlight support): * Basic control of brightness levels * Basic probing of backlight capabilities * Helpers for enabling and disabling the backlight v3: * Split out changes to i915's backlight code to separate patches to make it easier to review v4: * Style/spelling changes from Thomas Zimmermann v5: * Start using new drm_dbg_*() functions Signed-off-by: Lyude Paul <lyude@redhat.com> Cc: Jani Nikula <jani.nikula@intel.com> Cc: Dave Airlie <airlied@gmail.com> Cc: greg.depoire@gmail.com Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210514181504.565252-9-lyude@redhat.com
2021-05-14 18:15:02 +00:00
/* TODO: We currently only support AUX only backlight configurations, not backlights which
* require a mix of PWM and AUX controls to work. In the mean time, these machines typically
* work just fine using normal PWM controls anyway.
*/
drm/dp: Extract i915's eDP backlight code into DRM helpers Since we're about to implement eDP backlight support in nouveau using the standard protocol from VESA, we might as well just take the code that's already written for this and move it into a set of shared DRM helpers. Note that these helpers are intended to handle DPCD related backlight control bits such as setting the brightness level over AUX, probing the backlight's TCON, enabling/disabling the backlight over AUX if supported, etc. Any PWM-related portions of backlight control are explicitly left up to the driver, as these will vary from platform to platform. The only exception to this is the calculation of the PWM frequency pre-divider value. This is because the only platform-specific information required for this is the PWM frequency of the panel, which the driver is expected to provide if available. The actual algorithm for calculating this value is standard and is defined in the eDP specification from VESA. Note that these helpers do not yet implement the full range of features the VESA backlight interface provides, and only provide the following functionality (all of which was already present in i915's DPCD backlight support): * Basic control of brightness levels * Basic probing of backlight capabilities * Helpers for enabling and disabling the backlight v3: * Split out changes to i915's backlight code to separate patches to make it easier to review v4: * Style/spelling changes from Thomas Zimmermann v5: * Start using new drm_dbg_*() functions Signed-off-by: Lyude Paul <lyude@redhat.com> Cc: Jani Nikula <jani.nikula@intel.com> Cc: Dave Airlie <airlied@gmail.com> Cc: greg.depoire@gmail.com Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210514181504.565252-9-lyude@redhat.com
2021-05-14 18:15:02 +00:00
if ((intel_dp->edp_dpcd[1] & DP_EDP_BACKLIGHT_AUX_ENABLE_CAP) &&
drm_edp_backlight_supported(intel_dp->edp_dpcd)) {
drm_dbg_kms(&i915->drm, "AUX Backlight Control Supported!\n");
return true;
}
return false;
}
drm/i915/dp: Enable Intel's HDR backlight interface (only SDR for now) So-recently a bunch of laptops on the market have started using DPCD backlight controls instead of the traditional DDI backlight controls. Originally we thought we had this handled by adding VESA backlight control support to i915, but the story ended up being a lot more complicated then that. Simply put-there's two main backlight interfaces Intel can see in the wild. Intel's proprietary HDR backlight interface, and the standard VESA backlight interface. Note that many panels have been observed to report support for both backlight interfaces, but testing has shown far more panels work with the Intel HDR backlight interface at the moment. Additionally, the VBT appears to be capable of reporting support for the VESA backlight interface but not the Intel HDR interface which needs to be probed by setting the right magic OUI. On top of that however, there's also actually two different variants of the Intel HDR backlight interface. The first uses the AUX channel for controlling the brightness of the screen in both SDR and HDR mode, and the second only uses the AUX channel for setting the brightness level in HDR mode - relying on PWM for setting the brightness level in SDR mode. For the time being we've been using EDIDs to maintain a list of quirks for panels that safely do support the VESA backlight interface. Adding support for Intel's HDR backlight interface in addition however, should finally allow us to auto-detect eDP backlight controls properly so long as we probe like so: * If the panel's VBT reports VESA backlight support, assume it really does support it * If the panel's VBT reports DDI backlight controls: * First probe for Intel's HDR backlight interface * If that fails, probe for VESA's backlight interface * If that fails, assume no DPCD backlight control * If the panel's VBT reports any other backlight type: just assume it doesn't have DPCD backlight controls Changes since v4: * Fix checkpatch issues Changes since v3: * Stop using drm_device and use drm_i915_private instead * Don't forget to return from intel_dp_aux_hdr_get_backlight() if we fail to read the current backlight mode from the DPCD * s/uint8_t/u8/ * Remove unneeded parenthesis in intel_dp_aux_hdr_enable_backlight() * Use drm_dbg_kms() in intel_dp_aux_init_backlight_funcs() 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-4-lyude@redhat.com
2020-06-29 19:01:49 +00:00
static const struct intel_panel_bl_funcs intel_dp_hdr_bl_funcs = {
.setup = intel_dp_aux_hdr_setup_backlight,
.enable = intel_dp_aux_hdr_enable_backlight,
.disable = intel_dp_aux_hdr_disable_backlight,
.set = intel_dp_aux_hdr_set_backlight,
.get = intel_dp_aux_hdr_get_backlight,
};
static const struct intel_panel_bl_funcs intel_dp_vesa_bl_funcs = {
.setup = intel_dp_aux_vesa_setup_backlight,
.enable = intel_dp_aux_vesa_enable_backlight,
.disable = intel_dp_aux_vesa_disable_backlight,
.set = intel_dp_aux_vesa_set_backlight,
.get = intel_dp_aux_vesa_get_backlight,
};
enum intel_dp_aux_backlight_modparam {
INTEL_DP_AUX_BACKLIGHT_AUTO = -1,
INTEL_DP_AUX_BACKLIGHT_OFF = 0,
INTEL_DP_AUX_BACKLIGHT_ON = 1,
INTEL_DP_AUX_BACKLIGHT_FORCE_VESA = 2,
INTEL_DP_AUX_BACKLIGHT_FORCE_INTEL = 3,
};
drm/i915/dp: Enable Intel's HDR backlight interface (only SDR for now) So-recently a bunch of laptops on the market have started using DPCD backlight controls instead of the traditional DDI backlight controls. Originally we thought we had this handled by adding VESA backlight control support to i915, but the story ended up being a lot more complicated then that. Simply put-there's two main backlight interfaces Intel can see in the wild. Intel's proprietary HDR backlight interface, and the standard VESA backlight interface. Note that many panels have been observed to report support for both backlight interfaces, but testing has shown far more panels work with the Intel HDR backlight interface at the moment. Additionally, the VBT appears to be capable of reporting support for the VESA backlight interface but not the Intel HDR interface which needs to be probed by setting the right magic OUI. On top of that however, there's also actually two different variants of the Intel HDR backlight interface. The first uses the AUX channel for controlling the brightness of the screen in both SDR and HDR mode, and the second only uses the AUX channel for setting the brightness level in HDR mode - relying on PWM for setting the brightness level in SDR mode. For the time being we've been using EDIDs to maintain a list of quirks for panels that safely do support the VESA backlight interface. Adding support for Intel's HDR backlight interface in addition however, should finally allow us to auto-detect eDP backlight controls properly so long as we probe like so: * If the panel's VBT reports VESA backlight support, assume it really does support it * If the panel's VBT reports DDI backlight controls: * First probe for Intel's HDR backlight interface * If that fails, probe for VESA's backlight interface * If that fails, assume no DPCD backlight control * If the panel's VBT reports any other backlight type: just assume it doesn't have DPCD backlight controls Changes since v4: * Fix checkpatch issues Changes since v3: * Stop using drm_device and use drm_i915_private instead * Don't forget to return from intel_dp_aux_hdr_get_backlight() if we fail to read the current backlight mode from the DPCD * s/uint8_t/u8/ * Remove unneeded parenthesis in intel_dp_aux_hdr_enable_backlight() * Use drm_dbg_kms() in intel_dp_aux_init_backlight_funcs() 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-4-lyude@redhat.com
2020-06-29 19:01:49 +00:00
int intel_dp_aux_init_backlight_funcs(struct intel_connector *connector)
{
drm/i915/dp: Enable Intel's HDR backlight interface (only SDR for now) So-recently a bunch of laptops on the market have started using DPCD backlight controls instead of the traditional DDI backlight controls. Originally we thought we had this handled by adding VESA backlight control support to i915, but the story ended up being a lot more complicated then that. Simply put-there's two main backlight interfaces Intel can see in the wild. Intel's proprietary HDR backlight interface, and the standard VESA backlight interface. Note that many panels have been observed to report support for both backlight interfaces, but testing has shown far more panels work with the Intel HDR backlight interface at the moment. Additionally, the VBT appears to be capable of reporting support for the VESA backlight interface but not the Intel HDR interface which needs to be probed by setting the right magic OUI. On top of that however, there's also actually two different variants of the Intel HDR backlight interface. The first uses the AUX channel for controlling the brightness of the screen in both SDR and HDR mode, and the second only uses the AUX channel for setting the brightness level in HDR mode - relying on PWM for setting the brightness level in SDR mode. For the time being we've been using EDIDs to maintain a list of quirks for panels that safely do support the VESA backlight interface. Adding support for Intel's HDR backlight interface in addition however, should finally allow us to auto-detect eDP backlight controls properly so long as we probe like so: * If the panel's VBT reports VESA backlight support, assume it really does support it * If the panel's VBT reports DDI backlight controls: * First probe for Intel's HDR backlight interface * If that fails, probe for VESA's backlight interface * If that fails, assume no DPCD backlight control * If the panel's VBT reports any other backlight type: just assume it doesn't have DPCD backlight controls Changes since v4: * Fix checkpatch issues Changes since v3: * Stop using drm_device and use drm_i915_private instead * Don't forget to return from intel_dp_aux_hdr_get_backlight() if we fail to read the current backlight mode from the DPCD * s/uint8_t/u8/ * Remove unneeded parenthesis in intel_dp_aux_hdr_enable_backlight() * Use drm_dbg_kms() in intel_dp_aux_init_backlight_funcs() 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-4-lyude@redhat.com
2020-06-29 19:01:49 +00:00
struct drm_device *dev = connector->base.dev;
struct intel_panel *panel = &connector->panel;
struct intel_dp *intel_dp = enc_to_intel_dp(connector->encoder);
struct drm_i915_private *i915 = dp_to_i915(intel_dp);
bool try_intel_interface = false, try_vesa_interface = false;
/* Check the VBT and user's module parameters to figure out which
* interfaces to probe
*/
switch (i915->params.enable_dpcd_backlight) {
case INTEL_DP_AUX_BACKLIGHT_OFF:
return -ENODEV;
case INTEL_DP_AUX_BACKLIGHT_AUTO:
switch (i915->vbt.backlight.type) {
case INTEL_BACKLIGHT_VESA_EDP_AUX_INTERFACE:
try_vesa_interface = true;
break;
case INTEL_BACKLIGHT_DISPLAY_DDI:
try_intel_interface = true;
break;
default:
return -ENODEV;
}
break;
case INTEL_DP_AUX_BACKLIGHT_ON:
if (i915->vbt.backlight.type != INTEL_BACKLIGHT_VESA_EDP_AUX_INTERFACE)
try_intel_interface = true;
try_vesa_interface = true;
break;
case INTEL_DP_AUX_BACKLIGHT_FORCE_VESA:
try_vesa_interface = true;
break;
case INTEL_DP_AUX_BACKLIGHT_FORCE_INTEL:
try_intel_interface = true;
break;
}
/*
drm/i915/dp: Enable Intel's HDR backlight interface (only SDR for now) So-recently a bunch of laptops on the market have started using DPCD backlight controls instead of the traditional DDI backlight controls. Originally we thought we had this handled by adding VESA backlight control support to i915, but the story ended up being a lot more complicated then that. Simply put-there's two main backlight interfaces Intel can see in the wild. Intel's proprietary HDR backlight interface, and the standard VESA backlight interface. Note that many panels have been observed to report support for both backlight interfaces, but testing has shown far more panels work with the Intel HDR backlight interface at the moment. Additionally, the VBT appears to be capable of reporting support for the VESA backlight interface but not the Intel HDR interface which needs to be probed by setting the right magic OUI. On top of that however, there's also actually two different variants of the Intel HDR backlight interface. The first uses the AUX channel for controlling the brightness of the screen in both SDR and HDR mode, and the second only uses the AUX channel for setting the brightness level in HDR mode - relying on PWM for setting the brightness level in SDR mode. For the time being we've been using EDIDs to maintain a list of quirks for panels that safely do support the VESA backlight interface. Adding support for Intel's HDR backlight interface in addition however, should finally allow us to auto-detect eDP backlight controls properly so long as we probe like so: * If the panel's VBT reports VESA backlight support, assume it really does support it * If the panel's VBT reports DDI backlight controls: * First probe for Intel's HDR backlight interface * If that fails, probe for VESA's backlight interface * If that fails, assume no DPCD backlight control * If the panel's VBT reports any other backlight type: just assume it doesn't have DPCD backlight controls Changes since v4: * Fix checkpatch issues Changes since v3: * Stop using drm_device and use drm_i915_private instead * Don't forget to return from intel_dp_aux_hdr_get_backlight() if we fail to read the current backlight mode from the DPCD * s/uint8_t/u8/ * Remove unneeded parenthesis in intel_dp_aux_hdr_enable_backlight() * Use drm_dbg_kms() in intel_dp_aux_init_backlight_funcs() 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-4-lyude@redhat.com
2020-06-29 19:01:49 +00:00
* A lot of eDP panels in the wild will report supporting both the
* Intel proprietary backlight control interface, and the VESA
* backlight control interface. Many of these panels are liars though,
* and will only work with the Intel interface. So, always probe for
* that first.
*/
if (try_intel_interface && intel_dp_aux_supports_hdr_backlight(connector)) {
drm/i915/dp: Enable Intel's HDR backlight interface (only SDR for now) So-recently a bunch of laptops on the market have started using DPCD backlight controls instead of the traditional DDI backlight controls. Originally we thought we had this handled by adding VESA backlight control support to i915, but the story ended up being a lot more complicated then that. Simply put-there's two main backlight interfaces Intel can see in the wild. Intel's proprietary HDR backlight interface, and the standard VESA backlight interface. Note that many panels have been observed to report support for both backlight interfaces, but testing has shown far more panels work with the Intel HDR backlight interface at the moment. Additionally, the VBT appears to be capable of reporting support for the VESA backlight interface but not the Intel HDR interface which needs to be probed by setting the right magic OUI. On top of that however, there's also actually two different variants of the Intel HDR backlight interface. The first uses the AUX channel for controlling the brightness of the screen in both SDR and HDR mode, and the second only uses the AUX channel for setting the brightness level in HDR mode - relying on PWM for setting the brightness level in SDR mode. For the time being we've been using EDIDs to maintain a list of quirks for panels that safely do support the VESA backlight interface. Adding support for Intel's HDR backlight interface in addition however, should finally allow us to auto-detect eDP backlight controls properly so long as we probe like so: * If the panel's VBT reports VESA backlight support, assume it really does support it * If the panel's VBT reports DDI backlight controls: * First probe for Intel's HDR backlight interface * If that fails, probe for VESA's backlight interface * If that fails, assume no DPCD backlight control * If the panel's VBT reports any other backlight type: just assume it doesn't have DPCD backlight controls Changes since v4: * Fix checkpatch issues Changes since v3: * Stop using drm_device and use drm_i915_private instead * Don't forget to return from intel_dp_aux_hdr_get_backlight() if we fail to read the current backlight mode from the DPCD * s/uint8_t/u8/ * Remove unneeded parenthesis in intel_dp_aux_hdr_enable_backlight() * Use drm_dbg_kms() in intel_dp_aux_init_backlight_funcs() 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-4-lyude@redhat.com
2020-06-29 19:01:49 +00:00
drm_dbg_kms(dev, "Using Intel proprietary eDP backlight controls\n");
panel->backlight.funcs = &intel_dp_hdr_bl_funcs;
return 0;
}
if (try_vesa_interface && intel_dp_aux_supports_vesa_backlight(connector)) {
drm/i915/dp: Enable Intel's HDR backlight interface (only SDR for now) So-recently a bunch of laptops on the market have started using DPCD backlight controls instead of the traditional DDI backlight controls. Originally we thought we had this handled by adding VESA backlight control support to i915, but the story ended up being a lot more complicated then that. Simply put-there's two main backlight interfaces Intel can see in the wild. Intel's proprietary HDR backlight interface, and the standard VESA backlight interface. Note that many panels have been observed to report support for both backlight interfaces, but testing has shown far more panels work with the Intel HDR backlight interface at the moment. Additionally, the VBT appears to be capable of reporting support for the VESA backlight interface but not the Intel HDR interface which needs to be probed by setting the right magic OUI. On top of that however, there's also actually two different variants of the Intel HDR backlight interface. The first uses the AUX channel for controlling the brightness of the screen in both SDR and HDR mode, and the second only uses the AUX channel for setting the brightness level in HDR mode - relying on PWM for setting the brightness level in SDR mode. For the time being we've been using EDIDs to maintain a list of quirks for panels that safely do support the VESA backlight interface. Adding support for Intel's HDR backlight interface in addition however, should finally allow us to auto-detect eDP backlight controls properly so long as we probe like so: * If the panel's VBT reports VESA backlight support, assume it really does support it * If the panel's VBT reports DDI backlight controls: * First probe for Intel's HDR backlight interface * If that fails, probe for VESA's backlight interface * If that fails, assume no DPCD backlight control * If the panel's VBT reports any other backlight type: just assume it doesn't have DPCD backlight controls Changes since v4: * Fix checkpatch issues Changes since v3: * Stop using drm_device and use drm_i915_private instead * Don't forget to return from intel_dp_aux_hdr_get_backlight() if we fail to read the current backlight mode from the DPCD * s/uint8_t/u8/ * Remove unneeded parenthesis in intel_dp_aux_hdr_enable_backlight() * Use drm_dbg_kms() in intel_dp_aux_init_backlight_funcs() 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-4-lyude@redhat.com
2020-06-29 19:01:49 +00:00
drm_dbg_kms(dev, "Using VESA eDP backlight controls\n");
panel->backlight.funcs = &intel_dp_vesa_bl_funcs;
return 0;
}
drm/i915/dp: Enable Intel's HDR backlight interface (only SDR for now) So-recently a bunch of laptops on the market have started using DPCD backlight controls instead of the traditional DDI backlight controls. Originally we thought we had this handled by adding VESA backlight control support to i915, but the story ended up being a lot more complicated then that. Simply put-there's two main backlight interfaces Intel can see in the wild. Intel's proprietary HDR backlight interface, and the standard VESA backlight interface. Note that many panels have been observed to report support for both backlight interfaces, but testing has shown far more panels work with the Intel HDR backlight interface at the moment. Additionally, the VBT appears to be capable of reporting support for the VESA backlight interface but not the Intel HDR interface which needs to be probed by setting the right magic OUI. On top of that however, there's also actually two different variants of the Intel HDR backlight interface. The first uses the AUX channel for controlling the brightness of the screen in both SDR and HDR mode, and the second only uses the AUX channel for setting the brightness level in HDR mode - relying on PWM for setting the brightness level in SDR mode. For the time being we've been using EDIDs to maintain a list of quirks for panels that safely do support the VESA backlight interface. Adding support for Intel's HDR backlight interface in addition however, should finally allow us to auto-detect eDP backlight controls properly so long as we probe like so: * If the panel's VBT reports VESA backlight support, assume it really does support it * If the panel's VBT reports DDI backlight controls: * First probe for Intel's HDR backlight interface * If that fails, probe for VESA's backlight interface * If that fails, assume no DPCD backlight control * If the panel's VBT reports any other backlight type: just assume it doesn't have DPCD backlight controls Changes since v4: * Fix checkpatch issues Changes since v3: * Stop using drm_device and use drm_i915_private instead * Don't forget to return from intel_dp_aux_hdr_get_backlight() if we fail to read the current backlight mode from the DPCD * s/uint8_t/u8/ * Remove unneeded parenthesis in intel_dp_aux_hdr_enable_backlight() * Use drm_dbg_kms() in intel_dp_aux_init_backlight_funcs() 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-4-lyude@redhat.com
2020-06-29 19:01:49 +00:00
return -ENODEV;
}