HP DreamColor panel needs to be controlled via AUX interface. However, it has both DP_EDP_BACKLIGHT_BRIGHTNESS_AUX_SET_CAP and DP_EDP_BACKLIGHT_BRIGHTNESS_PWM_PIN_CAP set, so it fails to pass intel_dp_aux_display_control_capable() test.
Skip the test if the panel has force DPCD quirk.
Signed-off-by: Kai-Heng Feng kai.heng.feng@canonical.com --- drivers/gpu/drm/i915/display/intel_dp_aux_backlight.c | 10 ++++++---- 1 file changed, 6 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_dp_aux_backlight.c b/drivers/gpu/drm/i915/display/intel_dp_aux_backlight.c index acbd7eb66cbe..acf2e1c65290 100644 --- a/drivers/gpu/drm/i915/display/intel_dp_aux_backlight.c +++ b/drivers/gpu/drm/i915/display/intel_dp_aux_backlight.c @@ -347,9 +347,13 @@ 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); + bool force_dpcd; + + force_dpcd = drm_dp_has_quirk(&intel_dp->desc, intel_dp->edid_quirks, + DP_QUIRK_FORCE_DPCD_BACKLIGHT);
if (i915->params.enable_dpcd_backlight == 0 || - !intel_dp_aux_display_control_capable(intel_connector)) + (!force_dpcd && !intel_dp_aux_display_control_capable(intel_connector))) return -ENODEV;
/* @@ -358,9 +362,7 @@ int intel_dp_aux_init_backlight_funcs(struct intel_connector *intel_connector) */ if (i915->vbt.backlight.type != INTEL_BACKLIGHT_VESA_EDP_AUX_INTERFACE && - i915->params.enable_dpcd_backlight != 1 && - !drm_dp_has_quirk(&intel_dp->desc, intel_dp->edid_quirks, - DP_QUIRK_FORCE_DPCD_BACKLIGHT)) { + i915->params.enable_dpcd_backlight != 1 && !force_dpcd) { drm_info(&i915->drm, "Panel advertises DPCD backlight support, but " "VBT disagrees. If your backlight controls "
HP DreamColor panel, which is used by new HP ZBook Studio, needs to use DPCD to control brightness.
Signed-off-by: Kai-Heng Feng kai.heng.feng@canonical.com --- drivers/gpu/drm/drm_dp_helper.c | 1 + 1 file changed, 1 insertion(+)
diff --git a/drivers/gpu/drm/drm_dp_helper.c b/drivers/gpu/drm/drm_dp_helper.c index 092c8c985911..b3d0ea1b082b 100644 --- a/drivers/gpu/drm/drm_dp_helper.c +++ b/drivers/gpu/drm/drm_dp_helper.c @@ -1321,6 +1321,7 @@ static const struct edid_quirk edid_quirk_list[] = { */ { MFG(0x06, 0xaf), PROD_ID(0x9b, 0x32), BIT(DP_QUIRK_FORCE_DPCD_BACKLIGHT) }, { MFG(0x06, 0xaf), PROD_ID(0xeb, 0x41), BIT(DP_QUIRK_FORCE_DPCD_BACKLIGHT) }, + { MFG(0x30, 0xe4), PROD_ID(0x61, 0x06), BIT(DP_QUIRK_FORCE_DPCD_BACKLIGHT) }, { MFG(0x4d, 0x10), PROD_ID(0xc7, 0x14), BIT(DP_QUIRK_FORCE_DPCD_BACKLIGHT) }, { MFG(0x4d, 0x10), PROD_ID(0xe6, 0x14), BIT(DP_QUIRK_FORCE_DPCD_BACKLIGHT) }, { MFG(0x4c, 0x83), PROD_ID(0x47, 0x41), BIT(DP_QUIRK_FORCE_DPCD_BACKLIGHT) },
Hi! I thought this patch rang a bell, we actually already had some discussion about this since there's a couple of other systems this was causing issues for. Unfortunately it never seems like that patch got sent out. Satadru?
(if I don't hear back from them soon, I'll just send out a patch for this myself)
JFYI - the proper fix here is to just drop the DP_EDP_BACKLIGHT_BRIGHTNESS_PWM_PIN_CAP check from the code entirely. As long as the backlight supports AUX_SET_CAP, that should be enough for us to control it.
On Wed, 2020-10-07 at 14:58 +0800, Kai-Heng Feng wrote:
HP DreamColor panel needs to be controlled via AUX interface. However, it has both DP_EDP_BACKLIGHT_BRIGHTNESS_AUX_SET_CAP and DP_EDP_BACKLIGHT_BRIGHTNESS_PWM_PIN_CAP set, so it fails to pass intel_dp_aux_display_control_capable() test.
Skip the test if the panel has force DPCD quirk.
Signed-off-by: Kai-Heng Feng kai.heng.feng@canonical.com
drivers/gpu/drm/i915/display/intel_dp_aux_backlight.c | 10 ++++++---- 1 file changed, 6 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_dp_aux_backlight.c b/drivers/gpu/drm/i915/display/intel_dp_aux_backlight.c index acbd7eb66cbe..acf2e1c65290 100644 --- a/drivers/gpu/drm/i915/display/intel_dp_aux_backlight.c +++ b/drivers/gpu/drm/i915/display/intel_dp_aux_backlight.c @@ -347,9 +347,13 @@ 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);
bool force_dpcd;
force_dpcd = drm_dp_has_quirk(&intel_dp->desc, intel_dp->edid_quirks,
DP_QUIRK_FORCE_DPCD_BACKLIGHT);if (i915->params.enable_dpcd_backlight == 0 ||
!intel_dp_aux_display_control_capable(intel_connector))
(!force_dpcd &&!intel_dp_aux_display_control_capable(intel_connector))) return -ENODEV;
/* @@ -358,9 +362,7 @@ int intel_dp_aux_init_backlight_funcs(struct intel_connector *intel_connector) */ if (i915->vbt.backlight.type != INTEL_BACKLIGHT_VESA_EDP_AUX_INTERFACE &&
i915->params.enable_dpcd_backlight != 1 &&!drm_dp_has_quirk(&intel_dp->desc, intel_dp->edid_quirks,DP_QUIRK_FORCE_DPCD_BACKLIGHT)) {
i915->params.enable_dpcd_backlight != 1 && !force_dpcd) {
Hi Lyude,
On Oct 8, 2020, at 05:53, Lyude Paul lyude@redhat.com wrote:
Hi! I thought this patch rang a bell, we actually already had some discussion about this since there's a couple of other systems this was causing issues for. Unfortunately it never seems like that patch got sent out. Satadru?
(if I don't hear back from them soon, I'll just send out a patch for this myself)
JFYI - the proper fix here is to just drop the DP_EDP_BACKLIGHT_BRIGHTNESS_PWM_PIN_CAP check from the code entirely. As long as the backlight supports AUX_SET_CAP, that should be enough for us to control it.
Does the proper fix include dropping DP_QUIRK_FORCE_DPCD_BACKLIGHT entirely?
Kai-Heng
On Wed, 2020-10-07 at 14:58 +0800, Kai-Heng Feng wrote:
HP DreamColor panel needs to be controlled via AUX interface. However, it has both DP_EDP_BACKLIGHT_BRIGHTNESS_AUX_SET_CAP and DP_EDP_BACKLIGHT_BRIGHTNESS_PWM_PIN_CAP set, so it fails to pass intel_dp_aux_display_control_capable() test.
Skip the test if the panel has force DPCD quirk.
Signed-off-by: Kai-Heng Feng kai.heng.feng@canonical.com
drivers/gpu/drm/i915/display/intel_dp_aux_backlight.c | 10 ++++++---- 1 file changed, 6 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_dp_aux_backlight.c b/drivers/gpu/drm/i915/display/intel_dp_aux_backlight.c index acbd7eb66cbe..acf2e1c65290 100644 --- a/drivers/gpu/drm/i915/display/intel_dp_aux_backlight.c +++ b/drivers/gpu/drm/i915/display/intel_dp_aux_backlight.c @@ -347,9 +347,13 @@ 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);
bool force_dpcd;
force_dpcd = drm_dp_has_quirk(&intel_dp->desc, intel_dp->edid_quirks,
DP_QUIRK_FORCE_DPCD_BACKLIGHT);if (i915->params.enable_dpcd_backlight == 0 ||
!intel_dp_aux_display_control_capable(intel_connector))
(!force_dpcd &&!intel_dp_aux_display_control_capable(intel_connector))) return -ENODEV;
/* @@ -358,9 +362,7 @@ int intel_dp_aux_init_backlight_funcs(struct intel_connector *intel_connector) */ if (i915->vbt.backlight.type != INTEL_BACKLIGHT_VESA_EDP_AUX_INTERFACE &&
i915->params.enable_dpcd_backlight != 1 &&!drm_dp_has_quirk(&intel_dp->desc, intel_dp->edid_quirks,DP_QUIRK_FORCE_DPCD_BACKLIGHT)) {
i915->params.enable_dpcd_backlight != 1 && !force_dpcd) {-- Sincerely, Lyude Paul (she/her) Software Engineer at Red Hat
On Thu, 2020-10-08 at 10:32 +0800, Kai-Heng Feng wrote:
Hi Lyude,
On Oct 8, 2020, at 05:53, Lyude Paul lyude@redhat.com wrote:
Hi! I thought this patch rang a bell, we actually already had some discussion about this since there's a couple of other systems this was causing issues for. Unfortunately it never seems like that patch got sent out. Satadru?
(if I don't hear back from them soon, I'll just send out a patch for this myself)
JFYI - the proper fix here is to just drop the DP_EDP_BACKLIGHT_BRIGHTNESS_PWM_PIN_CAP check from the code entirely. As long as the backlight supports AUX_SET_CAP, that should be enough for us to control it.
Does the proper fix include dropping DP_QUIRK_FORCE_DPCD_BACKLIGHT entirely?\
Not yet - we need someone to help with reviewing my Intel HDR backlight interface patches before we can drop that. I was just talking about dropping the check where we don't enable the DPCD backlight if it claims to support DP_EDP_BACKLIGHT_BRIGHTNESS_PWM_PIN_CAP
Kai-Heng
On Wed, 2020-10-07 at 14:58 +0800, Kai-Heng Feng wrote:
HP DreamColor panel needs to be controlled via AUX interface. However, it has both DP_EDP_BACKLIGHT_BRIGHTNESS_AUX_SET_CAP and DP_EDP_BACKLIGHT_BRIGHTNESS_PWM_PIN_CAP set, so it fails to pass intel_dp_aux_display_control_capable() test.
Skip the test if the panel has force DPCD quirk.
Signed-off-by: Kai-Heng Feng kai.heng.feng@canonical.com
drivers/gpu/drm/i915/display/intel_dp_aux_backlight.c | 10 ++++++---- 1 file changed, 6 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_dp_aux_backlight.c b/drivers/gpu/drm/i915/display/intel_dp_aux_backlight.c index acbd7eb66cbe..acf2e1c65290 100644 --- a/drivers/gpu/drm/i915/display/intel_dp_aux_backlight.c +++ b/drivers/gpu/drm/i915/display/intel_dp_aux_backlight.c @@ -347,9 +347,13 @@ 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);
bool force_dpcd;
force_dpcd = drm_dp_has_quirk(&intel_dp->desc, intel_dp->edid_quirks,
DP_QUIRK_FORCE_DPCD_BACKLIGHT);if (i915->params.enable_dpcd_backlight == 0 ||
!intel_dp_aux_display_control_capable(intel_connector))
(!force_dpcd &&!intel_dp_aux_display_control_capable(intel_connector))) return -ENODEV;
/* @@ -358,9 +362,7 @@ int intel_dp_aux_init_backlight_funcs(struct intel_connector *intel_connector) */ if (i915->vbt.backlight.type != INTEL_BACKLIGHT_VESA_EDP_AUX_INTERFACE &&
i915->params.enable_dpcd_backlight != 1 &&!drm_dp_has_quirk(&intel_dp->desc, intel_dp->edid_quirks,DP_QUIRK_FORCE_DPCD_BACKLIGHT)) {
i915->params.enable_dpcd_backlight != 1 && !force_dpcd) {-- Sincerely, Lyude Paul (she/her) Software Engineer at Red Hat
oh hold on, I misspoke. Here's the patch I was thinking of:
https://patchwork.freedesktop.org/series/82041/
On Thu, 2020-10-08 at 10:32 +0800, Kai-Heng Feng wrote:
Hi Lyude,
On Oct 8, 2020, at 05:53, Lyude Paul lyude@redhat.com wrote:
Hi! I thought this patch rang a bell, we actually already had some discussion about this since there's a couple of other systems this was causing issues for. Unfortunately it never seems like that patch got sent out. Satadru?
(if I don't hear back from them soon, I'll just send out a patch for this myself)
JFYI - the proper fix here is to just drop the DP_EDP_BACKLIGHT_BRIGHTNESS_PWM_PIN_CAP check from the code entirely. As long as the backlight supports AUX_SET_CAP, that should be enough for us to control it.
Does the proper fix include dropping DP_QUIRK_FORCE_DPCD_BACKLIGHT entirely?
Kai-Heng
On Wed, 2020-10-07 at 14:58 +0800, Kai-Heng Feng wrote:
HP DreamColor panel needs to be controlled via AUX interface. However, it has both DP_EDP_BACKLIGHT_BRIGHTNESS_AUX_SET_CAP and DP_EDP_BACKLIGHT_BRIGHTNESS_PWM_PIN_CAP set, so it fails to pass intel_dp_aux_display_control_capable() test.
Skip the test if the panel has force DPCD quirk.
Signed-off-by: Kai-Heng Feng kai.heng.feng@canonical.com
drivers/gpu/drm/i915/display/intel_dp_aux_backlight.c | 10 ++++++---- 1 file changed, 6 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_dp_aux_backlight.c b/drivers/gpu/drm/i915/display/intel_dp_aux_backlight.c index acbd7eb66cbe..acf2e1c65290 100644 --- a/drivers/gpu/drm/i915/display/intel_dp_aux_backlight.c +++ b/drivers/gpu/drm/i915/display/intel_dp_aux_backlight.c @@ -347,9 +347,13 @@ 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);
bool force_dpcd;
force_dpcd = drm_dp_has_quirk(&intel_dp->desc, intel_dp->edid_quirks,
DP_QUIRK_FORCE_DPCD_BACKLIGHT);if (i915->params.enable_dpcd_backlight == 0 ||
!intel_dp_aux_display_control_capable(intel_connector))
(!force_dpcd &&!intel_dp_aux_display_control_capable(intel_connector))) return -ENODEV;
/* @@ -358,9 +362,7 @@ int intel_dp_aux_init_backlight_funcs(struct intel_connector *intel_connector) */ if (i915->vbt.backlight.type != INTEL_BACKLIGHT_VESA_EDP_AUX_INTERFACE &&
i915->params.enable_dpcd_backlight != 1 &&!drm_dp_has_quirk(&intel_dp->desc, intel_dp->edid_quirks,DP_QUIRK_FORCE_DPCD_BACKLIGHT)) {
i915->params.enable_dpcd_backlight != 1 && !force_dpcd) {-- Sincerely, Lyude Paul (she/her) Software Engineer at Red Hat
Kevin Chowski said he would be geting to working on upstreaming a version of that which was in the ChromeOS tree here:
https://chromium-review.googlesource.com/c/chromiumos/third_party/kernel/+/2... when I last spoke to hi
(This was two weeks ago.)
Kevin - do you have any input on this?
Satadru
On Thu, Oct 8, 2020 at 1:07 PM Lyude Paul lyude@redhat.com wrote:
oh hold on, I misspoke. Here's the patch I was thinking of:
https://patchwork.freedesktop.org/series/82041/
On Thu, 2020-10-08 at 10:32 +0800, Kai-Heng Feng wrote:
Hi Lyude,
On Oct 8, 2020, at 05:53, Lyude Paul lyude@redhat.com wrote:
Hi! I thought this patch rang a bell, we actually already had some discussion about this since there's a couple of other systems this was causing
issues
for. Unfortunately it never seems like that patch got sent out. Satadru?
(if I don't hear back from them soon, I'll just send out a patch for
this
myself)
JFYI - the proper fix here is to just drop the DP_EDP_BACKLIGHT_BRIGHTNESS_PWM_PIN_CAP check from the code entirely.
As
long as the backlight supports AUX_SET_CAP, that should be enough for us to
control
it.
Does the proper fix include dropping DP_QUIRK_FORCE_DPCD_BACKLIGHT
entirely?
Kai-Heng
On Wed, 2020-10-07 at 14:58 +0800, Kai-Heng Feng wrote:
HP DreamColor panel needs to be controlled via AUX interface.
However,
it has both DP_EDP_BACKLIGHT_BRIGHTNESS_AUX_SET_CAP and DP_EDP_BACKLIGHT_BRIGHTNESS_PWM_PIN_CAP set, so it fails to pass intel_dp_aux_display_control_capable() test.
Skip the test if the panel has force DPCD quirk.
Signed-off-by: Kai-Heng Feng kai.heng.feng@canonical.com
drivers/gpu/drm/i915/display/intel_dp_aux_backlight.c | 10 ++++++---- 1 file changed, 6 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_dp_aux_backlight.c b/drivers/gpu/drm/i915/display/intel_dp_aux_backlight.c index acbd7eb66cbe..acf2e1c65290 100644 --- a/drivers/gpu/drm/i915/display/intel_dp_aux_backlight.c +++ b/drivers/gpu/drm/i915/display/intel_dp_aux_backlight.c @@ -347,9 +347,13 @@ 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);
- bool force_dpcd;
- force_dpcd = drm_dp_has_quirk(&intel_dp->desc,
intel_dp->edid_quirks,
DP_QUIRK_FORCE_DPCD_BACKLIGHT);if (i915->params.enable_dpcd_backlight == 0 ||
!intel_dp_aux_display_control_capable(intel_connector))
(!force_dpcd &&!intel_dp_aux_display_control_capable(intel_connector))) return -ENODEV;
/* @@ -358,9 +362,7 @@ int intel_dp_aux_init_backlight_funcs(struct intel_connector *intel_connector) */ if (i915->vbt.backlight.type != INTEL_BACKLIGHT_VESA_EDP_AUX_INTERFACE &&
i915->params.enable_dpcd_backlight != 1 &&!drm_dp_has_quirk(&intel_dp->desc, intel_dp->edid_quirks,DP_QUIRK_FORCE_DPCD_BACKLIGHT)) {
i915->params.enable_dpcd_backlight != 1 && !force_dpcd) { drm_info(&i915->drm, "Panel advertises DPCD backlight support, but " "VBT disagrees. If your backlight controls "-- Sincerely, Lyude Paul (she/her) Software Engineer at Red Hat
-- Sincerely, Lyude Paul (she/her) Software Engineer at Red Hat
dri-devel@lists.freedesktop.org
-
Kai-Heng Feng -
Lyude Paul -
Satadru Pramanik