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

382 lines
12 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.
*
*/
#include "intel_display_types.h"
#include "intel_dp_aux_backlight.h"
static void set_aux_backlight_enable(struct intel_dp *intel_dp, bool enable)
{
struct drm_i915_private *i915 = dp_to_i915(intel_dp);
u8 reg_val = 0;
/* Early return when display use other mechanism to enable backlight. */
if (!(intel_dp->edp_dpcd[1] & DP_EDP_BACKLIGHT_AUX_ENABLE_CAP))
return;
if (drm_dp_dpcd_readb(&intel_dp->aux, DP_EDP_DISPLAY_CONTROL_REGISTER,
&reg_val) < 0) {
drm_dbg_kms(&i915->drm, "Failed to read DPCD register 0x%x\n",
DP_EDP_DISPLAY_CONTROL_REGISTER);
return;
}
if (enable)
reg_val |= DP_EDP_BACKLIGHT_ENABLE;
else
reg_val &= ~(DP_EDP_BACKLIGHT_ENABLE);
if (drm_dp_dpcd_writeb(&intel_dp->aux, DP_EDP_DISPLAY_CONTROL_REGISTER,
reg_val) != 1) {
drm_dbg_kms(&i915->drm, "Failed to %s aux backlight\n",
enable ? "enable" : "disable");
}
}
/*
* Read the current backlight value from DPCD register(s) based
* on if 8-bit(MSB) or 16-bit(MSB and LSB) values are supported
*/
static u32 intel_dp_aux_get_backlight(struct intel_connector *connector)
{
struct intel_dp *intel_dp = intel_attached_dp(connector);
struct drm_i915_private *i915 = dp_to_i915(intel_dp);
u8 read_val[2] = { 0x0 };
drm/i915: Assume 100% brightness when not in DPCD control mode Currently we always determine the initial panel brightness level by simply reading the value from DP_EDP_BACKLIGHT_BRIGHTNESS_MSB/LSB. This seems wrong though, because if the panel is not currently in DPCD control mode there's not really any reason why there would be any brightness value programmed in the first place. This appears to be the case on the Lenovo ThinkPad X1 Extreme 2nd Generation, where the default value in these registers is always 0 on boot despite the fact the panel runs at max brightness by default. Getting the initial brightness value correct here is important as well, since the panel on this laptop doesn't behave well if it's ever put into DPCD control mode while the brightness level is programmed to 0. So, let's fix this by checking what the current backlight control mode is before reading the brightness level. If it's in DPCD control mode, we return the programmed brightness level. Otherwise we assume 100% brightness and return the highest possible brightness level. This also prevents us from accidentally programming a brightness level of 0. This is one of the many fixes that gets backlight controls working on the ThinkPad X1 Extreme 2nd Generation with optional 4K AMOLED screen. Changes since v1: * s/DP_EDP_DISPLAY_CONTROL_REGISTER/DP_EDP_BACKLIGHT_MODE_SET_REGISTER/ - Jani 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-3-lyude@redhat.com
2020-01-16 21:16:09 +00:00
u8 mode_reg;
u16 level = 0;
drm/i915: Assume 100% brightness when not in DPCD control mode Currently we always determine the initial panel brightness level by simply reading the value from DP_EDP_BACKLIGHT_BRIGHTNESS_MSB/LSB. This seems wrong though, because if the panel is not currently in DPCD control mode there's not really any reason why there would be any brightness value programmed in the first place. This appears to be the case on the Lenovo ThinkPad X1 Extreme 2nd Generation, where the default value in these registers is always 0 on boot despite the fact the panel runs at max brightness by default. Getting the initial brightness value correct here is important as well, since the panel on this laptop doesn't behave well if it's ever put into DPCD control mode while the brightness level is programmed to 0. So, let's fix this by checking what the current backlight control mode is before reading the brightness level. If it's in DPCD control mode, we return the programmed brightness level. Otherwise we assume 100% brightness and return the highest possible brightness level. This also prevents us from accidentally programming a brightness level of 0. This is one of the many fixes that gets backlight controls working on the ThinkPad X1 Extreme 2nd Generation with optional 4K AMOLED screen. Changes since v1: * s/DP_EDP_DISPLAY_CONTROL_REGISTER/DP_EDP_BACKLIGHT_MODE_SET_REGISTER/ - Jani 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-3-lyude@redhat.com
2020-01-16 21:16:09 +00:00
if (drm_dp_dpcd_readb(&intel_dp->aux,
DP_EDP_BACKLIGHT_MODE_SET_REGISTER,
&mode_reg) != 1) {
drm_dbg_kms(&i915->drm,
"Failed to read the DPCD register 0x%x\n",
DP_EDP_BACKLIGHT_MODE_SET_REGISTER);
drm/i915: Assume 100% brightness when not in DPCD control mode Currently we always determine the initial panel brightness level by simply reading the value from DP_EDP_BACKLIGHT_BRIGHTNESS_MSB/LSB. This seems wrong though, because if the panel is not currently in DPCD control mode there's not really any reason why there would be any brightness value programmed in the first place. This appears to be the case on the Lenovo ThinkPad X1 Extreme 2nd Generation, where the default value in these registers is always 0 on boot despite the fact the panel runs at max brightness by default. Getting the initial brightness value correct here is important as well, since the panel on this laptop doesn't behave well if it's ever put into DPCD control mode while the brightness level is programmed to 0. So, let's fix this by checking what the current backlight control mode is before reading the brightness level. If it's in DPCD control mode, we return the programmed brightness level. Otherwise we assume 100% brightness and return the highest possible brightness level. This also prevents us from accidentally programming a brightness level of 0. This is one of the many fixes that gets backlight controls working on the ThinkPad X1 Extreme 2nd Generation with optional 4K AMOLED screen. Changes since v1: * s/DP_EDP_DISPLAY_CONTROL_REGISTER/DP_EDP_BACKLIGHT_MODE_SET_REGISTER/ - Jani 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-3-lyude@redhat.com
2020-01-16 21:16:09 +00:00
return 0;
}
/*
* If we're not in DPCD control mode yet, the programmed brightness
* value is meaningless and we should assume max brightness
*/
if ((mode_reg & DP_EDP_BACKLIGHT_CONTROL_MODE_MASK) !=
DP_EDP_BACKLIGHT_CONTROL_MODE_DPCD)
return connector->panel.backlight.max;
if (drm_dp_dpcd_read(&intel_dp->aux, DP_EDP_BACKLIGHT_BRIGHTNESS_MSB,
&read_val, sizeof(read_val)) < 0) {
drm_dbg_kms(&i915->drm, "Failed to read DPCD register 0x%x\n",
DP_EDP_BACKLIGHT_BRIGHTNESS_MSB);
return 0;
}
level = read_val[0];
if (intel_dp->edp_dpcd[2] & DP_EDP_BACKLIGHT_BRIGHTNESS_BYTE_COUNT)
level = (read_val[0] << 8 | read_val[1]);
return level;
}
/*
* Sends the current backlight level over the aux channel, checking if its using
* 8-bit or 16 bit value (MSB and LSB)
*/
static void
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
intel_dp_aux_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);
struct intel_dp *intel_dp = intel_attached_dp(connector);
struct drm_i915_private *i915 = dp_to_i915(intel_dp);
u8 vals[2] = { 0x0 };
vals[0] = level;
/* Write the MSB and/or LSB */
if (intel_dp->edp_dpcd[2] & DP_EDP_BACKLIGHT_BRIGHTNESS_BYTE_COUNT) {
vals[0] = (level & 0xFF00) >> 8;
vals[1] = (level & 0xFF);
}
if (drm_dp_dpcd_write(&intel_dp->aux, DP_EDP_BACKLIGHT_BRIGHTNESS_MSB,
vals, sizeof(vals)) < 0) {
drm_dbg_kms(&i915->drm,
"Failed to write aux backlight level\n");
return;
}
}
/*
* Set PWM Frequency divider to match desired frequency in vbt.
* The PWM Frequency is calculated as 27Mhz / (F x P).
* - Where F = PWM Frequency Pre-Divider value programmed by field 7:0 of the
* EDP_BACKLIGHT_FREQ_SET register (DPCD Address 00728h)
* - Where P = 2^Pn, where Pn is the value programmed by field 4:0 of the
* EDP_PWMGEN_BIT_COUNT register (DPCD Address 00724h)
*/
static bool intel_dp_aux_set_pwm_freq(struct intel_connector *connector)
{
struct drm_i915_private *dev_priv = to_i915(connector->base.dev);
struct intel_dp *intel_dp = intel_attached_dp(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
const u8 pn = connector->panel.backlight.pwmgen_bit_count;
int freq, fxp, f, fxp_actual, fxp_min, fxp_max;
freq = dev_priv->vbt.backlight.pwm_freq_hz;
if (!freq) {
drm_dbg_kms(&dev_priv->drm,
"Use panel default backlight frequency\n");
return false;
}
fxp = DIV_ROUND_CLOSEST(KHz(DP_EDP_BACKLIGHT_FREQ_BASE_KHZ), freq);
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
f = clamp(DIV_ROUND_CLOSEST(fxp, 1 << pn), 1, 255);
fxp_actual = f << pn;
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
/* Ensure frequency is within 25% of desired value */
fxp_min = DIV_ROUND_CLOSEST(fxp * 3, 4);
fxp_max = DIV_ROUND_CLOSEST(fxp * 5, 4);
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
if (fxp_min > fxp_actual || fxp_actual > fxp_max) {
drm_dbg_kms(&dev_priv->drm, "Actual frequency out of range\n");
return false;
}
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
if (drm_dp_dpcd_writeb(&intel_dp->aux,
DP_EDP_BACKLIGHT_FREQ_SET, (u8) f) < 0) {
drm_dbg_kms(&dev_priv->drm,
"Failed to write aux backlight freq\n");
return false;
}
return true;
}
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
static void intel_dp_aux_enable_backlight(const struct intel_crtc_state *crtc_state,
const struct drm_connector_state *conn_state)
{
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);
struct intel_dp *intel_dp = intel_attached_dp(connector);
struct drm_i915_private *i915 = dp_to_i915(intel_dp);
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;
u8 dpcd_buf, new_dpcd_buf, edp_backlight_mode;
if (drm_dp_dpcd_readb(&intel_dp->aux,
DP_EDP_BACKLIGHT_MODE_SET_REGISTER, &dpcd_buf) != 1) {
drm_dbg_kms(&i915->drm, "Failed to read DPCD register 0x%x\n",
DP_EDP_BACKLIGHT_MODE_SET_REGISTER);
return;
}
new_dpcd_buf = dpcd_buf;
edp_backlight_mode = dpcd_buf & DP_EDP_BACKLIGHT_CONTROL_MODE_MASK;
switch (edp_backlight_mode) {
case DP_EDP_BACKLIGHT_CONTROL_MODE_PWM:
case DP_EDP_BACKLIGHT_CONTROL_MODE_PRESET:
case DP_EDP_BACKLIGHT_CONTROL_MODE_PRODUCT:
new_dpcd_buf &= ~DP_EDP_BACKLIGHT_CONTROL_MODE_MASK;
new_dpcd_buf |= DP_EDP_BACKLIGHT_CONTROL_MODE_DPCD;
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
if (drm_dp_dpcd_writeb(&intel_dp->aux,
DP_EDP_PWMGEN_BIT_COUNT,
panel->backlight.pwmgen_bit_count) < 0)
drm_dbg_kms(&i915->drm,
"Failed to write aux pwmgen bit count\n");
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
break;
/* Do nothing when it is already DPCD mode */
case DP_EDP_BACKLIGHT_CONTROL_MODE_DPCD:
default:
break;
}
if (intel_dp->edp_dpcd[2] & DP_EDP_BACKLIGHT_FREQ_AUX_SET_CAP)
if (intel_dp_aux_set_pwm_freq(connector))
new_dpcd_buf |= DP_EDP_BACKLIGHT_FREQ_AUX_SET_ENABLE;
if (new_dpcd_buf != dpcd_buf) {
if (drm_dp_dpcd_writeb(&intel_dp->aux,
DP_EDP_BACKLIGHT_MODE_SET_REGISTER, new_dpcd_buf) < 0) {
drm_dbg_kms(&i915->drm,
"Failed to write aux backlight mode\n");
}
}
drm/i915: Fix DPCD register order in intel_dp_aux_enable_backlight() For eDP panels, it appears it's expected that so long as the panel is in DPCD control mode that the brightness value is never set to 0. Instead, if the desired effect is to set the panel's backlight to 0 we're expected to simply turn off the backlight through the DP_EDP_DISPLAY_CONTROL_REGISTER. We already do the latter correctly in intel_dp_aux_disable_backlight(). But, we make the mistake of writing the DPCD registers in the wrong order when enabling the backlight in intel_dp_aux_enable_backlight() since we currently enable the backlight through DP_EDP_DISPLAY_CONTROL_REGISTER before writing the brightness level. On the X1 Extreme 2nd Generation, this appears to have the potential of confusing the panel in such a way that further attempts to set the brightness don't actually change the backlight as expected and leave it off. Presumably, this happens because the incorrect register writing order briefly leaves the panel with DPCD mode enabled and a 0 brightness level set. So, reverse the order we write the DPCD registers when enabling the panel backlight so that we write the brightness value first, and enable the backlight second. This fix appears to be the final bit needed to get the backlight on the ThinkPad X1 Extreme 2nd Generation's AMOLED screen working. 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-4-lyude@redhat.com
2020-01-16 21:16:10 +00:00
intel_dp_aux_set_backlight(conn_state,
connector->panel.backlight.level);
set_aux_backlight_enable(intel_dp, true);
}
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
static void intel_dp_aux_disable_backlight(const struct drm_connector_state *old_conn_state)
{
set_aux_backlight_enable(enc_to_intel_dp(to_intel_encoder(old_conn_state->best_encoder)),
false);
}
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
static u32 intel_dp_aux_calc_max_backlight(struct intel_connector *connector)
{
struct drm_i915_private *i915 = to_i915(connector->base.dev);
struct intel_dp *intel_dp = intel_attached_dp(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;
u32 max_backlight = 0;
int freq, fxp, fxp_min, fxp_max, fxp_actual, f = 1;
u8 pn, pn_min, pn_max;
if (drm_dp_dpcd_readb(&intel_dp->aux, DP_EDP_PWMGEN_BIT_COUNT, &pn) == 1) {
pn &= DP_EDP_PWMGEN_BIT_COUNT_MASK;
max_backlight = (1 << pn) - 1;
}
/* Find desired value of (F x P)
* Note that, if F x P is out of supported range, the maximum value or
* minimum value will applied automatically. So no need to check that.
*/
freq = i915->vbt.backlight.pwm_freq_hz;
drm_dbg_kms(&i915->drm, "VBT defined backlight frequency %u Hz\n",
freq);
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
if (!freq) {
drm_dbg_kms(&i915->drm,
"Use panel default backlight frequency\n");
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
return max_backlight;
}
fxp = DIV_ROUND_CLOSEST(KHz(DP_EDP_BACKLIGHT_FREQ_BASE_KHZ), freq);
/* Use highest possible value of Pn for more granularity of brightness
* adjustment while satifying the conditions below.
* - Pn is in the range of Pn_min and Pn_max
* - F is in the range of 1 and 255
* - FxP is within 25% of desired value.
* Note: 25% is arbitrary value and may need some tweak.
*/
if (drm_dp_dpcd_readb(&intel_dp->aux,
DP_EDP_PWMGEN_BIT_COUNT_CAP_MIN, &pn_min) != 1) {
drm_dbg_kms(&i915->drm,
"Failed to read pwmgen bit count cap min\n");
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
return max_backlight;
}
if (drm_dp_dpcd_readb(&intel_dp->aux,
DP_EDP_PWMGEN_BIT_COUNT_CAP_MAX, &pn_max) != 1) {
drm_dbg_kms(&i915->drm,
"Failed to read pwmgen bit count cap max\n");
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
return max_backlight;
}
pn_min &= DP_EDP_PWMGEN_BIT_COUNT_MASK;
pn_max &= DP_EDP_PWMGEN_BIT_COUNT_MASK;
fxp_min = DIV_ROUND_CLOSEST(fxp * 3, 4);
fxp_max = DIV_ROUND_CLOSEST(fxp * 5, 4);
if (fxp_min < (1 << pn_min) || (255 << pn_max) < fxp_max) {
drm_dbg_kms(&i915->drm,
"VBT defined backlight frequency out of range\n");
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
return max_backlight;
}
for (pn = pn_max; pn >= pn_min; pn--) {
f = clamp(DIV_ROUND_CLOSEST(fxp, 1 << pn), 1, 255);
fxp_actual = f << pn;
if (fxp_min <= fxp_actual && fxp_actual <= fxp_max)
break;
}
drm_dbg_kms(&i915->drm, "Using eDP pwmgen bit count of %d\n", pn);
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
if (drm_dp_dpcd_writeb(&intel_dp->aux,
DP_EDP_PWMGEN_BIT_COUNT, pn) < 0) {
drm_dbg_kms(&i915->drm,
"Failed to write aux pwmgen bit count\n");
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
return max_backlight;
}
panel->backlight.pwmgen_bit_count = pn;
max_backlight = (1 << pn) - 1;
return max_backlight;
}
static int intel_dp_aux_setup_backlight(struct intel_connector *connector,
enum pipe pipe)
{
struct intel_panel *panel = &connector->panel;
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
panel->backlight.max = intel_dp_aux_calc_max_backlight(connector);
if (!panel->backlight.max)
return -ENODEV;
panel->backlight.min = 0;
panel->backlight.level = intel_dp_aux_get_backlight(connector);
panel->backlight.enabled = panel->backlight.level != 0;
return 0;
}
static bool
intel_dp_aux_display_control_capable(struct intel_connector *connector)
{
struct intel_dp *intel_dp = intel_attached_dp(connector);
struct drm_i915_private *i915 = dp_to_i915(intel_dp);
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
/* Check the eDP Display control capabilities registers to determine if
* the panel can support backlight control over the aux channel
*/
if (intel_dp->edp_dpcd[1] & DP_EDP_TCON_BACKLIGHT_ADJUSTMENT_CAP &&
(intel_dp->edp_dpcd[2] & DP_EDP_BACKLIGHT_BRIGHTNESS_AUX_SET_CAP) &&
!(intel_dp->edp_dpcd[2] & DP_EDP_BACKLIGHT_BRIGHTNESS_PWM_PIN_CAP)) {
drm_dbg_kms(&i915->drm, "AUX Backlight Control Supported!\n");
return true;
}
return false;
}
int intel_dp_aux_init_backlight_funcs(struct intel_connector *intel_connector)
{
struct intel_panel *panel = &intel_connector->panel;
struct intel_dp *intel_dp = enc_to_intel_dp(intel_connector->encoder);
struct drm_i915_private *i915 = dp_to_i915(intel_dp);
if (i915_modparams.enable_dpcd_backlight == 0 ||
!intel_dp_aux_display_control_capable(intel_connector))
return -ENODEV;
/*
* There are a lot of machines that don't advertise the backlight
* control interface to use properly in their VBIOS, :\
*/
if (i915->vbt.backlight.type !=
INTEL_BACKLIGHT_VESA_EDP_AUX_INTERFACE &&
i915_modparams.enable_dpcd_backlight != 1 &&
!drm_dp_has_quirk(&intel_dp->desc, intel_dp->edid_quirks,
DP_QUIRK_FORCE_DPCD_BACKLIGHT)) {
drm_info(&i915->drm,
"Panel advertises DPCD backlight support, but "
"VBT disagrees. If your backlight controls "
"don't work try booting with "
"i915.enable_dpcd_backlight=1. If your machine "
"needs this, please file a _new_ bug report on "
"drm/i915, see " FDO_BUG_URL " for details.\n");
return -ENODEV;
}
panel->backlight.setup = intel_dp_aux_setup_backlight;
panel->backlight.enable = intel_dp_aux_enable_backlight;
panel->backlight.disable = intel_dp_aux_disable_backlight;
panel->backlight.set = intel_dp_aux_set_backlight;
panel->backlight.get = intel_dp_aux_get_backlight;
return 0;
}