[PATCH] i915: Introduce quirk for shifting eDP brightness.

[PATCH] i915: Introduce quirk for shifting eDP brightness.

[Kevin Chowski]

We have observed that Google Pixelbook's backlight hardware is
interpretting these backlight bits from the most-significant side of the
16 bit word (if DP_EDP_PWMGEN_BIT_COUNT < 16), whereas the driver code
assumes the peripheral cares about the least-significant bits.

Testing was done from within Chrome OS's build environment when the
patch is backported to 5.4 (the version we are newly targeting for the
Pixelbook); for the record:
   $ emerge-eve-kernelnext sys-kernel/chromeos-kernel-5_4 && \
      ./update_kernel.sh --remote=$IP

I used `/sys/kernel/debug/dri/0/eDP-1/i915_dpcd` on my laptop to verify
that the registers were being set according to what the actual hardware
expects; I also observe that the backlight is noticeably brighter with
this patch.

Signed-off-by: Kevin Chowski <chowski@chromium.org>
---

 .../drm/i915/display/intel_dp_aux_backlight.c | 34 +++++++++++++++++++
 drivers/gpu/drm/i915/display/intel_quirks.c   | 13 +++++++
 drivers/gpu/drm/i915/i915_drv.h               |  1 +
 3 files changed, 48 insertions(+)

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 acbd7eb66cbe3..99c98f217356d 100644
--- a/drivers/gpu/drm/i915/display/intel_dp_aux_backlight.c
+++ b/drivers/gpu/drm/i915/display/intel_dp_aux_backlight.c
@@ -91,6 +91,23 @@ static u32 intel_dp_aux_get_backlight(struct intel_connector *connector)
 	if (intel_dp->edp_dpcd[2] & DP_EDP_BACKLIGHT_BRIGHTNESS_BYTE_COUNT)
 		level = (read_val[0] << 8 | read_val[1]);
 
+	if (i915->quirks & QUIRK_SHIFT_EDP_BACKLIGHT_BRIGHTNESS) {
+		if (!drm_dp_dpcd_readb(&intel_dp->aux, DP_EDP_PWMGEN_BIT_COUNT,
+						&read_val[0])) {
+			DRM_DEBUG_KMS("Failed to read DPCD register 0x%x\n",
+					DP_EDP_PWMGEN_BIT_COUNT);
+			return 0;
+		}
+		// Only bits 4:0 are used, 7:5 are reserved.
+		read_val[0] = read_val[0] & 0x1F;
+		if (read_val[0] > 16) {
+			DRM_DEBUG_KMS("Invalid DP_EDP_PWNGEN_BIT_COUNT 0x%X, expected at most 16\n",
+						read_val[0]);
+			return 0;
+		}
+		level >>= 16 - read_val[0];
+	}
+
 	return level;
 }
 
@@ -106,6 +123,23 @@ intel_dp_aux_set_backlight(const struct drm_connector_state *conn_state, u32 lev
 	struct drm_i915_private *i915 = dp_to_i915(intel_dp);
 	u8 vals[2] = { 0x0 };
 
+	if (i915->quirks & QUIRK_SHIFT_EDP_BACKLIGHT_BRIGHTNESS) {
+		if (!drm_dp_dpcd_readb(&intel_dp->aux, DP_EDP_PWMGEN_BIT_COUNT,
+						&vals[0])) {
+			DRM_DEBUG_KMS("Failed to write aux backlight level: Failed to read DPCD register 0x%x\n",
+					  DP_EDP_PWMGEN_BIT_COUNT);
+			return;
+		}
+		// Only bits 4:0 are used, 7:5 are reserved.
+		vals[0] = vals[0] & 0x1F;
+		if (vals[0] > 16) {
+			DRM_DEBUG_KMS("Failed to write aux backlight level: Invalid DP_EDP_PWNGEN_BIT_COUNT 0x%X, expected at most 16\n",
+						vals[0]);
+			return;
+		}
+		level <<= (16 - vals[0]) & 0xFFFF;
+	}
+
 	vals[0] = level;
 
 	/* Write the MSB and/or LSB */
diff --git a/drivers/gpu/drm/i915/display/intel_quirks.c b/drivers/gpu/drm/i915/display/intel_quirks.c
index 46beb155d835f..63b27d49b2864 100644
--- a/drivers/gpu/drm/i915/display/intel_quirks.c
+++ b/drivers/gpu/drm/i915/display/intel_quirks.c
@@ -53,6 +53,16 @@ static void quirk_increase_ddi_disabled_time(struct drm_i915_private *i915)
 	drm_info(&i915->drm, "Applying Increase DDI Disabled quirk\n");
 }
 
+/*
+ * Some eDP backlight hardware uses the most-significant bits of the brightness
+ * register, so brightness values must be shifted first.
+ */
+static void quirk_shift_edp_backlight_brightness(struct drm_i915_private *i915)
+{
+	i915->quirks |= QUIRK_SHIFT_EDP_BACKLIGHT_BRIGHTNESS;
+	DRM_INFO("Applying shift eDP backlight brightness quirk\n");
+}
+
 struct intel_quirk {
 	int device;
 	int subsystem_vendor;
@@ -156,6 +166,9 @@ static struct intel_quirk intel_quirks[] = {
 	/* ASRock ITX*/
 	{ 0x3185, 0x1849, 0x2212, quirk_increase_ddi_disabled_time },
 	{ 0x3184, 0x1849, 0x2212, quirk_increase_ddi_disabled_time },
+
+	/* Google Pixelbook */
+	{ 0x591E, 0x8086, 0x2212, quirk_shift_edp_backlight_brightness },
 };
 
 void intel_init_quirks(struct drm_i915_private *i915)
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index e4f7f6518945b..cc93bede4fab8 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -525,6 +525,7 @@ struct i915_psr {
 #define QUIRK_PIN_SWIZZLED_PAGES (1<<5)
 #define QUIRK_INCREASE_T12_DELAY (1<<6)
 #define QUIRK_INCREASE_DDI_DISABLED_TIME (1<<7)
+#define QUIRK_SHIFT_EDP_BACKLIGHT_BRIGHTNESS (1<<8)
 
 struct intel_fbdev;
 struct intel_fbc_work;
-- 
2.28.0.618.gf4bc123cb7-goog

Re: [PATCH] i915: Introduce quirk for shifting eDP brightness.

[Lyude Paul]

Just an FYI, my plan for some of this eDP backlight code is to move as much of
it into helpers as possible since we need to implement the same interface in
nouveau. We probably can figure out some other solution for handling this quirk
if this isn't possible, but could we maybe use the panel's OUI here and add a
quirk to drm_dp_helper.c instead?

On Thu, 2020-09-17 at 11:09 -0600, Kevin Chowski wrote:
> We have observed that Google Pixelbook's backlight hardware is
> interpretting these backlight bits from the most-significant side of the
> 16 bit word (if DP_EDP_PWMGEN_BIT_COUNT < 16), whereas the driver code
> assumes the peripheral cares about the least-significant bits.
> 
> Testing was done from within Chrome OS's build environment when the
> patch is backported to 5.4 (the version we are newly targeting for the
> Pixelbook); for the record:
>    $ emerge-eve-kernelnext sys-kernel/chromeos-kernel-5_4 && \
>       ./update_kernel.sh --remote=$IP
> 
> I used `/sys/kernel/debug/dri/0/eDP-1/i915_dpcd` on my laptop to verify
> that the registers were being set according to what the actual hardware
> expects; I also observe that the backlight is noticeably brighter with
> this patch.
> 
> Signed-off-by: Kevin Chowski <chowski@chromium.org>
> ---
> 
>  .../drm/i915/display/intel_dp_aux_backlight.c | 34 +++++++++++++++++++
>  drivers/gpu/drm/i915/display/intel_quirks.c   | 13 +++++++
>  drivers/gpu/drm/i915/i915_drv.h               |  1 +
>  3 files changed, 48 insertions(+)
> 
> 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 acbd7eb66cbe3..99c98f217356d 100644
> --- a/drivers/gpu/drm/i915/display/intel_dp_aux_backlight.c
> +++ b/drivers/gpu/drm/i915/display/intel_dp_aux_backlight.c
> @@ -91,6 +91,23 @@ static u32 intel_dp_aux_get_backlight(struct
> intel_connector *connector)
>  	if (intel_dp->edp_dpcd[2] & DP_EDP_BACKLIGHT_BRIGHTNESS_BYTE_COUNT)
>  		level = (read_val[0] << 8 | read_val[1]);
>  
> +	if (i915->quirks & QUIRK_SHIFT_EDP_BACKLIGHT_BRIGHTNESS) {
> +		if (!drm_dp_dpcd_readb(&intel_dp->aux, DP_EDP_PWMGEN_BIT_COUNT,
> +						&read_val[0])) {
> +			DRM_DEBUG_KMS("Failed to read DPCD register 0x%x\n",
> +					DP_EDP_PWMGEN_BIT_COUNT);
> +			return 0;
> +		}
> +		// Only bits 4:0 are used, 7:5 are reserved.
> +		read_val[0] = read_val[0] & 0x1F;
> +		if (read_val[0] > 16) {
> +			DRM_DEBUG_KMS("Invalid DP_EDP_PWNGEN_BIT_COUNT 0x%X,
> expected at most 16\n",
> +						read_val[0]);
> +			return 0;
> +		}
> +		level >>= 16 - read_val[0];
> +	}
> +
>  	return level;
>  }
>  
> @@ -106,6 +123,23 @@ intel_dp_aux_set_backlight(const struct
> drm_connector_state *conn_state, u32 lev
>  	struct drm_i915_private *i915 = dp_to_i915(intel_dp);
>  	u8 vals[2] = { 0x0 };
>  
> +	if (i915->quirks & QUIRK_SHIFT_EDP_BACKLIGHT_BRIGHTNESS) {
> +		if (!drm_dp_dpcd_readb(&intel_dp->aux, DP_EDP_PWMGEN_BIT_COUNT,
> +						&vals[0])) {
> +			DRM_DEBUG_KMS("Failed to write aux backlight level:
> Failed to read DPCD register 0x%x\n",
> +					  DP_EDP_PWMGEN_BIT_COUNT);
> +			return;
> +		}
> +		// Only bits 4:0 are used, 7:5 are reserved.
> +		vals[0] = vals[0] & 0x1F;
> +		if (vals[0] > 16) {
> +			DRM_DEBUG_KMS("Failed to write aux backlight level:
> Invalid DP_EDP_PWNGEN_BIT_COUNT 0x%X, expected at most 16\n",
> +						vals[0]);
> +			return;
> +		}
> +		level <<= (16 - vals[0]) & 0xFFFF;
> +	}
> +
>  	vals[0] = level;
>  
>  	/* Write the MSB and/or LSB */
> diff --git a/drivers/gpu/drm/i915/display/intel_quirks.c
> b/drivers/gpu/drm/i915/display/intel_quirks.c
> index 46beb155d835f..63b27d49b2864 100644
> --- a/drivers/gpu/drm/i915/display/intel_quirks.c
> +++ b/drivers/gpu/drm/i915/display/intel_quirks.c
> @@ -53,6 +53,16 @@ static void quirk_increase_ddi_disabled_time(struct
> drm_i915_private *i915)
>  	drm_info(&i915->drm, "Applying Increase DDI Disabled quirk\n");
>  }
>  
> +/*
> + * Some eDP backlight hardware uses the most-significant bits of the
> brightness
> + * register, so brightness values must be shifted first.
> + */
> +static void quirk_shift_edp_backlight_brightness(struct drm_i915_private
> *i915)
> +{
> +	i915->quirks |= QUIRK_SHIFT_EDP_BACKLIGHT_BRIGHTNESS;
> +	DRM_INFO("Applying shift eDP backlight brightness quirk\n");
> +}
> +
>  struct intel_quirk {
>  	int device;
>  	int subsystem_vendor;
> @@ -156,6 +166,9 @@ static struct intel_quirk intel_quirks[] = {
>  	/* ASRock ITX*/
>  	{ 0x3185, 0x1849, 0x2212, quirk_increase_ddi_disabled_time },
>  	{ 0x3184, 0x1849, 0x2212, quirk_increase_ddi_disabled_time },
> +
> +	/* Google Pixelbook */
> +	{ 0x591E, 0x8086, 0x2212, quirk_shift_edp_backlight_brightness },
>  };
>  
>  void intel_init_quirks(struct drm_i915_private *i915)
> diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
> index e4f7f6518945b..cc93bede4fab8 100644
> --- a/drivers/gpu/drm/i915/i915_drv.h
> +++ b/drivers/gpu/drm/i915/i915_drv.h
> @@ -525,6 +525,7 @@ struct i915_psr {
>  #define QUIRK_PIN_SWIZZLED_PAGES (1<<5)
>  #define QUIRK_INCREASE_T12_DELAY (1<<6)
>  #define QUIRK_INCREASE_DDI_DISABLED_TIME (1<<7)
> +#define QUIRK_SHIFT_EDP_BACKLIGHT_BRIGHTNESS (1<<8)
>  
>  struct intel_fbdev;
>  struct intel_fbc_work;
-- 
Sincerely,
      Lyude Paul (she/her)
      Software Engineer at Red Hat

Re: [PATCH] i915: Introduce quirk for shifting eDP brightness.

[Ville Syrjälä]

On Thu, Sep 17, 2020 at 11:09:06AM -0600, Kevin Chowski wrote:
> We have observed that Google Pixelbook's backlight hardware is
> interpretting these backlight bits from the most-significant side of the
> 16 bit word (if DP_EDP_PWMGEN_BIT_COUNT < 16), whereas the driver code
> assumes the peripheral cares about the least-significant bits.

The spec seems to agree with the msb interpretation. So looks like
the current code is just broken?

> 
> Testing was done from within Chrome OS's build environment when the
> patch is backported to 5.4 (the version we are newly targeting for the
> Pixelbook); for the record:
>    $ emerge-eve-kernelnext sys-kernel/chromeos-kernel-5_4 && \
>       ./update_kernel.sh --remote=$IP
> 
> I used `/sys/kernel/debug/dri/0/eDP-1/i915_dpcd` on my laptop to verify
> that the registers were being set according to what the actual hardware
> expects; I also observe that the backlight is noticeably brighter with
> this patch.
> 
> Signed-off-by: Kevin Chowski <chowski@chromium.org>
> ---
> 
>  .../drm/i915/display/intel_dp_aux_backlight.c | 34 +++++++++++++++++++
>  drivers/gpu/drm/i915/display/intel_quirks.c   | 13 +++++++
>  drivers/gpu/drm/i915/i915_drv.h               |  1 +
>  3 files changed, 48 insertions(+)
> 
> 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 acbd7eb66cbe3..99c98f217356d 100644
> --- a/drivers/gpu/drm/i915/display/intel_dp_aux_backlight.c
> +++ b/drivers/gpu/drm/i915/display/intel_dp_aux_backlight.c
> @@ -91,6 +91,23 @@ static u32 intel_dp_aux_get_backlight(struct intel_connector *connector)
>  	if (intel_dp->edp_dpcd[2] & DP_EDP_BACKLIGHT_BRIGHTNESS_BYTE_COUNT)
>  		level = (read_val[0] << 8 | read_val[1]);
>  
> +	if (i915->quirks & QUIRK_SHIFT_EDP_BACKLIGHT_BRIGHTNESS) {
> +		if (!drm_dp_dpcd_readb(&intel_dp->aux, DP_EDP_PWMGEN_BIT_COUNT,
> +						&read_val[0])) {
> +			DRM_DEBUG_KMS("Failed to read DPCD register 0x%x\n",
> +					DP_EDP_PWMGEN_BIT_COUNT);
> +			return 0;
> +		}
> +		// Only bits 4:0 are used, 7:5 are reserved.
> +		read_val[0] = read_val[0] & 0x1F;
> +		if (read_val[0] > 16) {
> +			DRM_DEBUG_KMS("Invalid DP_EDP_PWNGEN_BIT_COUNT 0x%X, expected at most 16\n",
> +						read_val[0]);
> +			return 0;
> +		}
> +		level >>= 16 - read_val[0];
> +	}
> +
>  	return level;
>  }
>  
> @@ -106,6 +123,23 @@ intel_dp_aux_set_backlight(const struct drm_connector_state *conn_state, u32 lev
>  	struct drm_i915_private *i915 = dp_to_i915(intel_dp);
>  	u8 vals[2] = { 0x0 };
>  
> +	if (i915->quirks & QUIRK_SHIFT_EDP_BACKLIGHT_BRIGHTNESS) {
> +		if (!drm_dp_dpcd_readb(&intel_dp->aux, DP_EDP_PWMGEN_BIT_COUNT,
> +						&vals[0])) {
> +			DRM_DEBUG_KMS("Failed to write aux backlight level: Failed to read DPCD register 0x%x\n",
> +					  DP_EDP_PWMGEN_BIT_COUNT);
> +			return;
> +		}
> +		// Only bits 4:0 are used, 7:5 are reserved.
> +		vals[0] = vals[0] & 0x1F;
> +		if (vals[0] > 16) {
> +			DRM_DEBUG_KMS("Failed to write aux backlight level: Invalid DP_EDP_PWNGEN_BIT_COUNT 0x%X, expected at most 16\n",
> +						vals[0]);
> +			return;
> +		}
> +		level <<= (16 - vals[0]) & 0xFFFF;
> +	}
> +
>  	vals[0] = level;
>  
>  	/* Write the MSB and/or LSB */
> diff --git a/drivers/gpu/drm/i915/display/intel_quirks.c b/drivers/gpu/drm/i915/display/intel_quirks.c
> index 46beb155d835f..63b27d49b2864 100644
> --- a/drivers/gpu/drm/i915/display/intel_quirks.c
> +++ b/drivers/gpu/drm/i915/display/intel_quirks.c
> @@ -53,6 +53,16 @@ static void quirk_increase_ddi_disabled_time(struct drm_i915_private *i915)
>  	drm_info(&i915->drm, "Applying Increase DDI Disabled quirk\n");
>  }
>  
> +/*
> + * Some eDP backlight hardware uses the most-significant bits of the brightness
> + * register, so brightness values must be shifted first.
> + */
> +static void quirk_shift_edp_backlight_brightness(struct drm_i915_private *i915)
> +{
> +	i915->quirks |= QUIRK_SHIFT_EDP_BACKLIGHT_BRIGHTNESS;
> +	DRM_INFO("Applying shift eDP backlight brightness quirk\n");
> +}
> +
>  struct intel_quirk {
>  	int device;
>  	int subsystem_vendor;
> @@ -156,6 +166,9 @@ static struct intel_quirk intel_quirks[] = {
>  	/* ASRock ITX*/
>  	{ 0x3185, 0x1849, 0x2212, quirk_increase_ddi_disabled_time },
>  	{ 0x3184, 0x1849, 0x2212, quirk_increase_ddi_disabled_time },
> +
> +	/* Google Pixelbook */
> +	{ 0x591E, 0x8086, 0x2212, quirk_shift_edp_backlight_brightness },
>  };
>  
>  void intel_init_quirks(struct drm_i915_private *i915)
> diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
> index e4f7f6518945b..cc93bede4fab8 100644
> --- a/drivers/gpu/drm/i915/i915_drv.h
> +++ b/drivers/gpu/drm/i915/i915_drv.h
> @@ -525,6 +525,7 @@ struct i915_psr {
>  #define QUIRK_PIN_SWIZZLED_PAGES (1<<5)
>  #define QUIRK_INCREASE_T12_DELAY (1<<6)
>  #define QUIRK_INCREASE_DDI_DISABLED_TIME (1<<7)
> +#define QUIRK_SHIFT_EDP_BACKLIGHT_BRIGHTNESS (1<<8)
>  
>  struct intel_fbdev;
>  struct intel_fbc_work;
> -- 
> 2.28.0.618.gf4bc123cb7-goog

-- 
Ville Syrjälä
Intel

Re: [PATCH] i915: Introduce quirk for shifting eDP brightness.

[Kevin Chowski]

(resending as plain-text, my last mail was rejected by lots of
addresses for some reason)

Thanks very much for the quick reply, Lyude!

I'm happy to make the requested changes, but I wanted to clarify
before falling down the wrong hole: are you suggesting that I move the
intel_dp_aux_set_backlight/intel_dp_aux_get_backlight routines to the
drm_dp_helper.c file?

On Thu, Sep 17, 2020 at 11:13 AM Lyude Paul <lyude@redhat.com> wrote:
>
> Just an FYI, my plan for some of this eDP backlight code is to move as much of
> it into helpers as possible since we need to implement the same interface in
> nouveau. We probably can figure out some other solution for handling this quirk
> if this isn't possible, but could we maybe use the panel's OUI here and add a
> quirk to drm_dp_helper.c instead?
>
> On Thu, 2020-09-17 at 11:09 -0600, Kevin Chowski wrote:
> > We have observed that Google Pixelbook's backlight hardware is
> > interpretting these backlight bits from the most-significant side of the
> > 16 bit word (if DP_EDP_PWMGEN_BIT_COUNT < 16), whereas the driver code
> > assumes the peripheral cares about the least-significant bits.
> >
> > Testing was done from within Chrome OS's build environment when the
> > patch is backported to 5.4 (the version we are newly targeting for the
> > Pixelbook); for the record:
> >    $ emerge-eve-kernelnext sys-kernel/chromeos-kernel-5_4 && \
> >       ./update_kernel.sh --remote=$IP
> >
> > I used `/sys/kernel/debug/dri/0/eDP-1/i915_dpcd` on my laptop to verify
> > that the registers were being set according to what the actual hardware
> > expects; I also observe that the backlight is noticeably brighter with
> > this patch.
> >
> > Signed-off-by: Kevin Chowski <chowski@chromium.org>
> > ---
> >
> >  .../drm/i915/display/intel_dp_aux_backlight.c | 34 +++++++++++++++++++
> >  drivers/gpu/drm/i915/display/intel_quirks.c   | 13 +++++++
> >  drivers/gpu/drm/i915/i915_drv.h               |  1 +
> >  3 files changed, 48 insertions(+)
> >
> > 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 acbd7eb66cbe3..99c98f217356d 100644
> > --- a/drivers/gpu/drm/i915/display/intel_dp_aux_backlight.c
> > +++ b/drivers/gpu/drm/i915/display/intel_dp_aux_backlight.c
> > @@ -91,6 +91,23 @@ static u32 intel_dp_aux_get_backlight(struct
> > intel_connector *connector)
> >       if (intel_dp->edp_dpcd[2] & DP_EDP_BACKLIGHT_BRIGHTNESS_BYTE_COUNT)
> >               level = (read_val[0] << 8 | read_val[1]);
> >
> > +     if (i915->quirks & QUIRK_SHIFT_EDP_BACKLIGHT_BRIGHTNESS) {
> > +             if (!drm_dp_dpcd_readb(&intel_dp->aux, DP_EDP_PWMGEN_BIT_COUNT,
> > +                                             &read_val[0])) {
> > +                     DRM_DEBUG_KMS("Failed to read DPCD register 0x%x\n",
> > +                                     DP_EDP_PWMGEN_BIT_COUNT);
> > +                     return 0;
> > +             }
> > +             // Only bits 4:0 are used, 7:5 are reserved.
> > +             read_val[0] = read_val[0] & 0x1F;
> > +             if (read_val[0] > 16) {
> > +                     DRM_DEBUG_KMS("Invalid DP_EDP_PWNGEN_BIT_COUNT 0x%X,
> > expected at most 16\n",
> > +                                             read_val[0]);
> > +                     return 0;
> > +             }
> > +             level >>= 16 - read_val[0];
> > +     }
> > +
> >       return level;
> >  }
> >
> > @@ -106,6 +123,23 @@ intel_dp_aux_set_backlight(const struct
> > drm_connector_state *conn_state, u32 lev
> >       struct drm_i915_private *i915 = dp_to_i915(intel_dp);
> >       u8 vals[2] = { 0x0 };
> >
> > +     if (i915->quirks & QUIRK_SHIFT_EDP_BACKLIGHT_BRIGHTNESS) {
> > +             if (!drm_dp_dpcd_readb(&intel_dp->aux, DP_EDP_PWMGEN_BIT_COUNT,
> > +                                             &vals[0])) {
> > +                     DRM_DEBUG_KMS("Failed to write aux backlight level:
> > Failed to read DPCD register 0x%x\n",
> > +                                       DP_EDP_PWMGEN_BIT_COUNT);
> > +                     return;
> > +             }
> > +             // Only bits 4:0 are used, 7:5 are reserved.
> > +             vals[0] = vals[0] & 0x1F;
> > +             if (vals[0] > 16) {
> > +                     DRM_DEBUG_KMS("Failed to write aux backlight level:
> > Invalid DP_EDP_PWNGEN_BIT_COUNT 0x%X, expected at most 16\n",
> > +                                             vals[0]);
> > +                     return;
> > +             }
> > +             level <<= (16 - vals[0]) & 0xFFFF;
> > +     }
> > +
> >       vals[0] = level;
> >
> >       /* Write the MSB and/or LSB */
> > diff --git a/drivers/gpu/drm/i915/display/intel_quirks.c
> > b/drivers/gpu/drm/i915/display/intel_quirks.c
> > index 46beb155d835f..63b27d49b2864 100644
> > --- a/drivers/gpu/drm/i915/display/intel_quirks.c
> > +++ b/drivers/gpu/drm/i915/display/intel_quirks.c
> > @@ -53,6 +53,16 @@ static void quirk_increase_ddi_disabled_time(struct
> > drm_i915_private *i915)
> >       drm_info(&i915->drm, "Applying Increase DDI Disabled quirk\n");
> >  }
> >
> > +/*
> > + * Some eDP backlight hardware uses the most-significant bits of the
> > brightness
> > + * register, so brightness values must be shifted first.
> > + */
> > +static void quirk_shift_edp_backlight_brightness(struct drm_i915_private
> > *i915)
> > +{
> > +     i915->quirks |= QUIRK_SHIFT_EDP_BACKLIGHT_BRIGHTNESS;
> > +     DRM_INFO("Applying shift eDP backlight brightness quirk\n");
> > +}
> > +
> >  struct intel_quirk {
> >       int device;
> >       int subsystem_vendor;
> > @@ -156,6 +166,9 @@ static struct intel_quirk intel_quirks[] = {
> >       /* ASRock ITX*/
> >       { 0x3185, 0x1849, 0x2212, quirk_increase_ddi_disabled_time },
> >       { 0x3184, 0x1849, 0x2212, quirk_increase_ddi_disabled_time },
> > +
> > +     /* Google Pixelbook */
> > +     { 0x591E, 0x8086, 0x2212, quirk_shift_edp_backlight_brightness },
> >  };
> >
> >  void intel_init_quirks(struct drm_i915_private *i915)
> > diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
> > index e4f7f6518945b..cc93bede4fab8 100644
> > --- a/drivers/gpu/drm/i915/i915_drv.h
> > +++ b/drivers/gpu/drm/i915/i915_drv.h
> > @@ -525,6 +525,7 @@ struct i915_psr {
> >  #define QUIRK_PIN_SWIZZLED_PAGES (1<<5)
> >  #define QUIRK_INCREASE_T12_DELAY (1<<6)
> >  #define QUIRK_INCREASE_DDI_DISABLED_TIME (1<<7)
> > +#define QUIRK_SHIFT_EDP_BACKLIGHT_BRIGHTNESS (1<<8)
> >
> >  struct intel_fbdev;
> >  struct intel_fbc_work;
> --
> Sincerely,
>       Lyude Paul (she/her)
>       Software Engineer at Red Hat
>

Re: [PATCH] i915: Introduce quirk for shifting eDP brightness.

[Kevin Chowski]

Apologies for being too vague. To be as precise I can be, here is the
specific code delta I tested: https://crrev.com/c/2406616 . To answer
your other question, the code I tested against is indeed including the
fde7266fb2f6 (despite ostensibly being called 5.4 in my commit
message): our current top-of-tree for our 5.4 branch includes the
intel_dp_aux_calc_max_backlight logic. Further, I'll note that change
is exactly the change which breaks my Pixelbook model: prior to the
change, the max_brightness was hard-coded to 0xFFFF and the math
worked out that it didn't matter that the hardware cared about the MSB
despite the driver code caring about the LSB.

To answer Ville's question: the fde7266fb2f6 change which fixes one
laptop (I believe Thinkpad X1 extreme Gen 2, from some bug reports I
dug up) and breaks another (Pixelbook); so unfortunately I believe we
need a quirk at least for some laptop. Reading through the copy of the
datasheet I have, it wasn't clear to me which was the correct
interpretation. I'm cc'ing puthik@, who was leaning toward the current
kernel code (caring about LSB) being the correct interpretation. I
believe we have other chromebooks which do rely on LSB functionality,
so unless we can find more examples of laptops wanting MSB it
currently looks like Pixelbook is the outlier.

On Thu, Sep 17, 2020 at 11:28 AM Jani Nikula
<jani.nikula@linux.intel.com> wrote:
>
> On Thu, 17 Sep 2020, Kevin Chowski <chowski@chromium.org> wrote:
> > We have observed that Google Pixelbook's backlight hardware is
> > interpretting these backlight bits from the most-significant side of the
> > 16 bit word (if DP_EDP_PWMGEN_BIT_COUNT < 16), whereas the driver code
> > assumes the peripheral cares about the least-significant bits.
> >
> > Testing was done from within Chrome OS's build environment when the
> > patch is backported to 5.4 (the version we are newly targeting for the
> > Pixelbook); for the record:
> >    $ emerge-eve-kernelnext sys-kernel/chromeos-kernel-5_4 && \
> >       ./update_kernel.sh --remote=$IP
> >
> > I used `/sys/kernel/debug/dri/0/eDP-1/i915_dpcd` on my laptop to verify
> > that the registers were being set according to what the actual hardware
> > expects; I also observe that the backlight is noticeably brighter with
> > this patch.
>
> It's unclear to me what kernel version this is against, and what you've
> actually tested.
>
> Have you tried v5.7 kernel with Lyude's fde7266fb2f6 ("drm/i915: Fix eDP
> DPCD aux max backlight calculations")?
>
> I just want to make sure you've tested with all the relevant fixes
> before adding quirks.
>
> BR,
> Jani.
>
> >
> > Signed-off-by: Kevin Chowski <chowski@chromium.org>
> > ---
> >
> >  .../drm/i915/display/intel_dp_aux_backlight.c | 34 +++++++++++++++++++
> >  drivers/gpu/drm/i915/display/intel_quirks.c   | 13 +++++++
> >  drivers/gpu/drm/i915/i915_drv.h               |  1 +
> >  3 files changed, 48 insertions(+)
> >
> > 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 acbd7eb66cbe3..99c98f217356d 100644
> > --- a/drivers/gpu/drm/i915/display/intel_dp_aux_backlight.c
> > +++ b/drivers/gpu/drm/i915/display/intel_dp_aux_backlight.c
> > @@ -91,6 +91,23 @@ static u32 intel_dp_aux_get_backlight(struct intel_connector *connector)
> >       if (intel_dp->edp_dpcd[2] & DP_EDP_BACKLIGHT_BRIGHTNESS_BYTE_COUNT)
> >               level = (read_val[0] << 8 | read_val[1]);
> >
> > +     if (i915->quirks & QUIRK_SHIFT_EDP_BACKLIGHT_BRIGHTNESS) {
> > +             if (!drm_dp_dpcd_readb(&intel_dp->aux, DP_EDP_PWMGEN_BIT_COUNT,
> > +                                             &read_val[0])) {
> > +                     DRM_DEBUG_KMS("Failed to read DPCD register 0x%x\n",
> > +                                     DP_EDP_PWMGEN_BIT_COUNT);
> > +                     return 0;
> > +             }
> > +             // Only bits 4:0 are used, 7:5 are reserved.
> > +             read_val[0] = read_val[0] & 0x1F;
> > +             if (read_val[0] > 16) {
> > +                     DRM_DEBUG_KMS("Invalid DP_EDP_PWNGEN_BIT_COUNT 0x%X, expected at most 16\n",
> > +                                             read_val[0]);
> > +                     return 0;
> > +             }
> > +             level >>= 16 - read_val[0];
> > +     }
> > +
> >       return level;
> >  }
> >
> > @@ -106,6 +123,23 @@ intel_dp_aux_set_backlight(const struct drm_connector_state *conn_state, u32 lev
> >       struct drm_i915_private *i915 = dp_to_i915(intel_dp);
> >       u8 vals[2] = { 0x0 };
> >
> > +     if (i915->quirks & QUIRK_SHIFT_EDP_BACKLIGHT_BRIGHTNESS) {
> > +             if (!drm_dp_dpcd_readb(&intel_dp->aux, DP_EDP_PWMGEN_BIT_COUNT,
> > +                                             &vals[0])) {
> > +                     DRM_DEBUG_KMS("Failed to write aux backlight level: Failed to read DPCD register 0x%x\n",
> > +                                       DP_EDP_PWMGEN_BIT_COUNT);
> > +                     return;
> > +             }
> > +             // Only bits 4:0 are used, 7:5 are reserved.
> > +             vals[0] = vals[0] & 0x1F;
> > +             if (vals[0] > 16) {
> > +                     DRM_DEBUG_KMS("Failed to write aux backlight level: Invalid DP_EDP_PWNGEN_BIT_COUNT 0x%X, expected at most 16\n",
> > +                                             vals[0]);
> > +                     return;
> > +             }
> > +             level <<= (16 - vals[0]) & 0xFFFF;
> > +     }
> > +
> >       vals[0] = level;
> >
> >       /* Write the MSB and/or LSB */
> > diff --git a/drivers/gpu/drm/i915/display/intel_quirks.c b/drivers/gpu/drm/i915/display/intel_quirks.c
> > index 46beb155d835f..63b27d49b2864 100644
> > --- a/drivers/gpu/drm/i915/display/intel_quirks.c
> > +++ b/drivers/gpu/drm/i915/display/intel_quirks.c
> > @@ -53,6 +53,16 @@ static void quirk_increase_ddi_disabled_time(struct drm_i915_private *i915)
> >       drm_info(&i915->drm, "Applying Increase DDI Disabled quirk\n");
> >  }
> >
> > +/*
> > + * Some eDP backlight hardware uses the most-significant bits of the brightness
> > + * register, so brightness values must be shifted first.
> > + */
> > +static void quirk_shift_edp_backlight_brightness(struct drm_i915_private *i915)
> > +{
> > +     i915->quirks |= QUIRK_SHIFT_EDP_BACKLIGHT_BRIGHTNESS;
> > +     DRM_INFO("Applying shift eDP backlight brightness quirk\n");
> > +}
> > +
> >  struct intel_quirk {
> >       int device;
> >       int subsystem_vendor;
> > @@ -156,6 +166,9 @@ static struct intel_quirk intel_quirks[] = {
> >       /* ASRock ITX*/
> >       { 0x3185, 0x1849, 0x2212, quirk_increase_ddi_disabled_time },
> >       { 0x3184, 0x1849, 0x2212, quirk_increase_ddi_disabled_time },
> > +
> > +     /* Google Pixelbook */
> > +     { 0x591E, 0x8086, 0x2212, quirk_shift_edp_backlight_brightness },
> >  };
> >
> >  void intel_init_quirks(struct drm_i915_private *i915)
> > diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
> > index e4f7f6518945b..cc93bede4fab8 100644
> > --- a/drivers/gpu/drm/i915/i915_drv.h
> > +++ b/drivers/gpu/drm/i915/i915_drv.h
> > @@ -525,6 +525,7 @@ struct i915_psr {
> >  #define QUIRK_PIN_SWIZZLED_PAGES (1<<5)
> >  #define QUIRK_INCREASE_T12_DELAY (1<<6)
> >  #define QUIRK_INCREASE_DDI_DISABLED_TIME (1<<7)
> > +#define QUIRK_SHIFT_EDP_BACKLIGHT_BRIGHTNESS (1<<8)
> >
> >  struct intel_fbdev;
> >  struct intel_fbc_work;
>
> --
> Jani Nikula, Intel Open Source Graphics Center

Re: [PATCH] i915: Introduce quirk for shifting eDP brightness.

[Puthikorn Voravootivat]

The Lyude fde7266fb2f6 change is actually based on Chromium change
(https://crrev.com/c/1650325) that fixes the brightness for Samsung
Galaxy Chromebook. So currently we have 2 examples that use LSB
interpretation and 1 that use MSB.


On Thu, Sep 17, 2020 at 10:55 AM Kevin Chowski <chowski@chromium.org> wrote:
>
> Apologies for being too vague. To be as precise I can be, here is the
> specific code delta I tested: https://crrev.com/c/2406616 . To answer
> your other question, the code I tested against is indeed including the
> fde7266fb2f6 (despite ostensibly being called 5.4 in my commit
> message): our current top-of-tree for our 5.4 branch includes the
> intel_dp_aux_calc_max_backlight logic. Further, I'll note that change
> is exactly the change which breaks my Pixelbook model: prior to the
> change, the max_brightness was hard-coded to 0xFFFF and the math
> worked out that it didn't matter that the hardware cared about the MSB
> despite the driver code caring about the LSB.
>
> To answer Ville's question: the fde7266fb2f6 change which fixes one
> laptop (I believe Thinkpad X1 extreme Gen 2, from some bug reports I
> dug up) and breaks another (Pixelbook); so unfortunately I believe we
> need a quirk at least for some laptop. Reading through the copy of the
> datasheet I have, it wasn't clear to me which was the correct
> interpretation. I'm cc'ing puthik@, who was leaning toward the current
> kernel code (caring about LSB) being the correct interpretation. I
> believe we have other chromebooks which do rely on LSB functionality,
> so unless we can find more examples of laptops wanting MSB it
> currently looks like Pixelbook is the outlier.
>
> On Thu, Sep 17, 2020 at 11:28 AM Jani Nikula
> <jani.nikula@linux.intel.com> wrote:
> >
> > On Thu, 17 Sep 2020, Kevin Chowski <chowski@chromium.org> wrote:
> > > We have observed that Google Pixelbook's backlight hardware is
> > > interpretting these backlight bits from the most-significant side of the
> > > 16 bit word (if DP_EDP_PWMGEN_BIT_COUNT < 16), whereas the driver code
> > > assumes the peripheral cares about the least-significant bits.
> > >
> > > Testing was done from within Chrome OS's build environment when the
> > > patch is backported to 5.4 (the version we are newly targeting for the
> > > Pixelbook); for the record:
> > >    $ emerge-eve-kernelnext sys-kernel/chromeos-kernel-5_4 && \
> > >       ./update_kernel.sh --remote=$IP
> > >
> > > I used `/sys/kernel/debug/dri/0/eDP-1/i915_dpcd` on my laptop to verify
> > > that the registers were being set according to what the actual hardware
> > > expects; I also observe that the backlight is noticeably brighter with
> > > this patch.
> >
> > It's unclear to me what kernel version this is against, and what you've
> > actually tested.
> >
> > Have you tried v5.7 kernel with Lyude's fde7266fb2f6 ("drm/i915: Fix eDP
> > DPCD aux max backlight calculations")?
> >
> > I just want to make sure you've tested with all the relevant fixes
> > before adding quirks.
> >
> > BR,
> > Jani.
> >
> > >
> > > Signed-off-by: Kevin Chowski <chowski@chromium.org>
> > > ---
> > >
> > >  .../drm/i915/display/intel_dp_aux_backlight.c | 34 +++++++++++++++++++
> > >  drivers/gpu/drm/i915/display/intel_quirks.c   | 13 +++++++
> > >  drivers/gpu/drm/i915/i915_drv.h               |  1 +
> > >  3 files changed, 48 insertions(+)
> > >
> > > 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 acbd7eb66cbe3..99c98f217356d 100644
> > > --- a/drivers/gpu/drm/i915/display/intel_dp_aux_backlight.c
> > > +++ b/drivers/gpu/drm/i915/display/intel_dp_aux_backlight.c
> > > @@ -91,6 +91,23 @@ static u32 intel_dp_aux_get_backlight(struct intel_connector *connector)
> > >       if (intel_dp->edp_dpcd[2] & DP_EDP_BACKLIGHT_BRIGHTNESS_BYTE_COUNT)
> > >               level = (read_val[0] << 8 | read_val[1]);
> > >
> > > +     if (i915->quirks & QUIRK_SHIFT_EDP_BACKLIGHT_BRIGHTNESS) {
> > > +             if (!drm_dp_dpcd_readb(&intel_dp->aux, DP_EDP_PWMGEN_BIT_COUNT,
> > > +                                             &read_val[0])) {
> > > +                     DRM_DEBUG_KMS("Failed to read DPCD register 0x%x\n",
> > > +                                     DP_EDP_PWMGEN_BIT_COUNT);
> > > +                     return 0;
> > > +             }
> > > +             // Only bits 4:0 are used, 7:5 are reserved.
> > > +             read_val[0] = read_val[0] & 0x1F;
> > > +             if (read_val[0] > 16) {
> > > +                     DRM_DEBUG_KMS("Invalid DP_EDP_PWNGEN_BIT_COUNT 0x%X, expected at most 16\n",
> > > +                                             read_val[0]);
> > > +                     return 0;
> > > +             }
> > > +             level >>= 16 - read_val[0];
> > > +     }
> > > +
> > >       return level;
> > >  }
> > >
> > > @@ -106,6 +123,23 @@ intel_dp_aux_set_backlight(const struct drm_connector_state *conn_state, u32 lev
> > >       struct drm_i915_private *i915 = dp_to_i915(intel_dp);
> > >       u8 vals[2] = { 0x0 };
> > >
> > > +     if (i915->quirks & QUIRK_SHIFT_EDP_BACKLIGHT_BRIGHTNESS) {
> > > +             if (!drm_dp_dpcd_readb(&intel_dp->aux, DP_EDP_PWMGEN_BIT_COUNT,
> > > +                                             &vals[0])) {
> > > +                     DRM_DEBUG_KMS("Failed to write aux backlight level: Failed to read DPCD register 0x%x\n",
> > > +                                       DP_EDP_PWMGEN_BIT_COUNT);
> > > +                     return;
> > > +             }
> > > +             // Only bits 4:0 are used, 7:5 are reserved.
> > > +             vals[0] = vals[0] & 0x1F;
> > > +             if (vals[0] > 16) {
> > > +                     DRM_DEBUG_KMS("Failed to write aux backlight level: Invalid DP_EDP_PWNGEN_BIT_COUNT 0x%X, expected at most 16\n",
> > > +                                             vals[0]);
> > > +                     return;
> > > +             }
> > > +             level <<= (16 - vals[0]) & 0xFFFF;
> > > +     }
> > > +
> > >       vals[0] = level;
> > >
> > >       /* Write the MSB and/or LSB */
> > > diff --git a/drivers/gpu/drm/i915/display/intel_quirks.c b/drivers/gpu/drm/i915/display/intel_quirks.c
> > > index 46beb155d835f..63b27d49b2864 100644
> > > --- a/drivers/gpu/drm/i915/display/intel_quirks.c
> > > +++ b/drivers/gpu/drm/i915/display/intel_quirks.c
> > > @@ -53,6 +53,16 @@ static void quirk_increase_ddi_disabled_time(struct drm_i915_private *i915)
> > >       drm_info(&i915->drm, "Applying Increase DDI Disabled quirk\n");
> > >  }
> > >
> > > +/*
> > > + * Some eDP backlight hardware uses the most-significant bits of the brightness
> > > + * register, so brightness values must be shifted first.
> > > + */
> > > +static void quirk_shift_edp_backlight_brightness(struct drm_i915_private *i915)
> > > +{
> > > +     i915->quirks |= QUIRK_SHIFT_EDP_BACKLIGHT_BRIGHTNESS;
> > > +     DRM_INFO("Applying shift eDP backlight brightness quirk\n");
> > > +}
> > > +
> > >  struct intel_quirk {
> > >       int device;
> > >       int subsystem_vendor;
> > > @@ -156,6 +166,9 @@ static struct intel_quirk intel_quirks[] = {
> > >       /* ASRock ITX*/
> > >       { 0x3185, 0x1849, 0x2212, quirk_increase_ddi_disabled_time },
> > >       { 0x3184, 0x1849, 0x2212, quirk_increase_ddi_disabled_time },
> > > +
> > > +     /* Google Pixelbook */
> > > +     { 0x591E, 0x8086, 0x2212, quirk_shift_edp_backlight_brightness },
> > >  };
> > >
> > >  void intel_init_quirks(struct drm_i915_private *i915)
> > > diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
> > > index e4f7f6518945b..cc93bede4fab8 100644
> > > --- a/drivers/gpu/drm/i915/i915_drv.h
> > > +++ b/drivers/gpu/drm/i915/i915_drv.h
> > > @@ -525,6 +525,7 @@ struct i915_psr {
> > >  #define QUIRK_PIN_SWIZZLED_PAGES (1<<5)
> > >  #define QUIRK_INCREASE_T12_DELAY (1<<6)
> > >  #define QUIRK_INCREASE_DDI_DISABLED_TIME (1<<7)
> > > +#define QUIRK_SHIFT_EDP_BACKLIGHT_BRIGHTNESS (1<<8)
> > >
> > >  struct intel_fbdev;
> > >  struct intel_fbc_work;
> >
> > --
> > Jani Nikula, Intel Open Source Graphics Center

Re: [PATCH] i915: Introduce quirk for shifting eDP brightness.

[Lyude Paul]

On Thu, 2020-09-17 at 21:25 +0300, Ville Syrjälä wrote:
> On Thu, Sep 17, 2020 at 11:14:43AM -0700, Puthikorn Voravootivat wrote:
> > The Lyude fde7266fb2f6 change is actually based on Chromium change
> > (https://crrev.com/c/1650325) that fixes the brightness for Samsung
> > Galaxy Chromebook. So currently we have 2 examples that use LSB
> > interpretation and 1 that use MSB.
> 
> "If field 4:0 of the EDP_PWMGEN_BIT_COUNT register represents a value
> of greater than 8 and the BACKLIGHT_BRIGHTNESS_BYTE_COUNT bit
> is cleared to 0, only the 8 MSB of the brightness control value can be
> controlled.
> (See Note below.)
> Assigned bits are allocated to the MSB of the enabled register
> combination."
> 
> I think that's pretty clear the assigned bits are supposed to be
> msb aligned.

Are we sure that isn't just referring to the DP_EDP_BACKLIGHT_BRIGHTNESS_MSB
register, as opposed to alignment of the whole value in that register? My
understanding of this was just that if there wasn't a pwmgen bit count
specified, that the backlight level would just be written to
DP_EDP_BACKLIGHT_BRIGHTNESS_MSB and DP_EDP_BACKLIGHT_BRIGHTNESS_LSB would be
ignored. 

Hopefully I'm not misunderstanding Ville, but I don't think so since the current
code we have already follows the understanding I just gave:

	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);
	}

(vals[0] == MSB)
> 
> > 
> > On Thu, Sep 17, 2020 at 10:55 AM Kevin Chowski <chowski@chromium.org> wrote:
> > > Apologies for being too vague. To be as precise I can be, here is the
> > > specific code delta I tested: https://crrev.com/c/2406616 . To answer
> > > your other question, the code I tested against is indeed including the
> > > fde7266fb2f6 (despite ostensibly being called 5.4 in my commit
> > > message): our current top-of-tree for our 5.4 branch includes the
> > > intel_dp_aux_calc_max_backlight logic. Further, I'll note that change
> > > is exactly the change which breaks my Pixelbook model: prior to the
> > > change, the max_brightness was hard-coded to 0xFFFF and the math
> > > worked out that it didn't matter that the hardware cared about the MSB
> > > despite the driver code caring about the LSB.
> > > 
> > > To answer Ville's question: the fde7266fb2f6 change which fixes one
> > > laptop (I believe Thinkpad X1 extreme Gen 2, from some bug reports I
> > > dug up) and breaks another (Pixelbook); so unfortunately I believe we
> > > need a quirk at least for some laptop. Reading through the copy of the
> > > datasheet I have, it wasn't clear to me which was the correct
> > > interpretation. I'm cc'ing puthik@, who was leaning toward the current
> > > kernel code (caring about LSB) being the correct interpretation. I
> > > believe we have other chromebooks which do rely on LSB functionality,
> > > so unless we can find more examples of laptops wanting MSB it
> > > currently looks like Pixelbook is the outlier.
> > > 
> > > On Thu, Sep 17, 2020 at 11:28 AM Jani Nikula
> > > <jani.nikula@linux.intel.com> wrote:
> > > > On Thu, 17 Sep 2020, Kevin Chowski <chowski@chromium.org> wrote:
> > > > > We have observed that Google Pixelbook's backlight hardware is
> > > > > interpretting these backlight bits from the most-significant side of
> > > > > the
> > > > > 16 bit word (if DP_EDP_PWMGEN_BIT_COUNT < 16), whereas the driver code
> > > > > assumes the peripheral cares about the least-significant bits.
> > > > > 
> > > > > Testing was done from within Chrome OS's build environment when the
> > > > > patch is backported to 5.4 (the version we are newly targeting for the
> > > > > Pixelbook); for the record:
> > > > >    $ emerge-eve-kernelnext sys-kernel/chromeos-kernel-5_4 && \
> > > > >       ./update_kernel.sh --remote=$IP
> > > > > 
> > > > > I used `/sys/kernel/debug/dri/0/eDP-1/i915_dpcd` on my laptop to
> > > > > verify
> > > > > that the registers were being set according to what the actual
> > > > > hardware
> > > > > expects; I also observe that the backlight is noticeably brighter with
> > > > > this patch.
> > > > 
> > > > It's unclear to me what kernel version this is against, and what you've
> > > > actually tested.
> > > > 
> > > > Have you tried v5.7 kernel with Lyude's fde7266fb2f6 ("drm/i915: Fix eDP
> > > > DPCD aux max backlight calculations")?
> > > > 
> > > > I just want to make sure you've tested with all the relevant fixes
> > > > before adding quirks.
> > > > 
> > > > BR,
> > > > Jani.
> > > > 
> > > > > Signed-off-by: Kevin Chowski <chowski@chromium.org>
> > > > > ---
> > > > > 
> > > > >  .../drm/i915/display/intel_dp_aux_backlight.c | 34
> > > > > +++++++++++++++++++
> > > > >  drivers/gpu/drm/i915/display/intel_quirks.c   | 13 +++++++
> > > > >  drivers/gpu/drm/i915/i915_drv.h               |  1 +
> > > > >  3 files changed, 48 insertions(+)
> > > > > 
> > > > > 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 acbd7eb66cbe3..99c98f217356d 100644
> > > > > --- a/drivers/gpu/drm/i915/display/intel_dp_aux_backlight.c
> > > > > +++ b/drivers/gpu/drm/i915/display/intel_dp_aux_backlight.c
> > > > > @@ -91,6 +91,23 @@ static u32 intel_dp_aux_get_backlight(struct
> > > > > intel_connector *connector)
> > > > >       if (intel_dp->edp_dpcd[2] &
> > > > > DP_EDP_BACKLIGHT_BRIGHTNESS_BYTE_COUNT)
> > > > >               level = (read_val[0] << 8 | read_val[1]);
> > > > > 
> > > > > +     if (i915->quirks & QUIRK_SHIFT_EDP_BACKLIGHT_BRIGHTNESS) {
> > > > > +             if (!drm_dp_dpcd_readb(&intel_dp->aux,
> > > > > DP_EDP_PWMGEN_BIT_COUNT,
> > > > > +                                             &read_val[0])) {
> > > > > +                     DRM_DEBUG_KMS("Failed to read DPCD register
> > > > > 0x%x\n",
> > > > > +                                     DP_EDP_PWMGEN_BIT_COUNT);
> > > > > +                     return 0;
> > > > > +             }
> > > > > +             // Only bits 4:0 are used, 7:5 are reserved.
> > > > > +             read_val[0] = read_val[0] & 0x1F;
> > > > > +             if (read_val[0] > 16) {
> > > > > +                     DRM_DEBUG_KMS("Invalid DP_EDP_PWNGEN_BIT_COUNT
> > > > > 0x%X, expected at most 16\n",
> > > > > +                                             read_val[0]);
> > > > > +                     return 0;
> > > > > +             }
> > > > > +             level >>= 16 - read_val[0];
> > > > > +     }
> > > > > +
> > > > >       return level;
> > > > >  }
> > > > > 
> > > > > @@ -106,6 +123,23 @@ intel_dp_aux_set_backlight(const struct
> > > > > drm_connector_state *conn_state, u32 lev
> > > > >       struct drm_i915_private *i915 = dp_to_i915(intel_dp);
> > > > >       u8 vals[2] = { 0x0 };
> > > > > 
> > > > > +     if (i915->quirks & QUIRK_SHIFT_EDP_BACKLIGHT_BRIGHTNESS) {
> > > > > +             if (!drm_dp_dpcd_readb(&intel_dp->aux,
> > > > > DP_EDP_PWMGEN_BIT_COUNT,
> > > > > +                                             &vals[0])) {
> > > > > +                     DRM_DEBUG_KMS("Failed to write aux backlight
> > > > > level: Failed to read DPCD register 0x%x\n",
> > > > > +                                       DP_EDP_PWMGEN_BIT_COUNT);
> > > > > +                     return;
> > > > > +             }
> > > > > +             // Only bits 4:0 are used, 7:5 are reserved.
> > > > > +             vals[0] = vals[0] & 0x1F;
> > > > > +             if (vals[0] > 16) {
> > > > > +                     DRM_DEBUG_KMS("Failed to write aux backlight
> > > > > level: Invalid DP_EDP_PWNGEN_BIT_COUNT 0x%X, expected at most 16\n",
> > > > > +                                             vals[0]);
> > > > > +                     return;
> > > > > +             }
> > > > > +             level <<= (16 - vals[0]) & 0xFFFF;
> > > > > +     }
> > > > > +
> > > > >       vals[0] = level;
> > > > > 
> > > > >       /* Write the MSB and/or LSB */
> > > > > diff --git a/drivers/gpu/drm/i915/display/intel_quirks.c
> > > > > b/drivers/gpu/drm/i915/display/intel_quirks.c
> > > > > index 46beb155d835f..63b27d49b2864 100644
> > > > > --- a/drivers/gpu/drm/i915/display/intel_quirks.c
> > > > > +++ b/drivers/gpu/drm/i915/display/intel_quirks.c
> > > > > @@ -53,6 +53,16 @@ static void quirk_increase_ddi_disabled_time(struct
> > > > > drm_i915_private *i915)
> > > > >       drm_info(&i915->drm, "Applying Increase DDI Disabled quirk\n");
> > > > >  }
> > > > > 
> > > > > +/*
> > > > > + * Some eDP backlight hardware uses the most-significant bits of the
> > > > > brightness
> > > > > + * register, so brightness values must be shifted first.
> > > > > + */
> > > > > +static void quirk_shift_edp_backlight_brightness(struct
> > > > > drm_i915_private *i915)
> > > > > +{
> > > > > +     i915->quirks |= QUIRK_SHIFT_EDP_BACKLIGHT_BRIGHTNESS;
> > > > > +     DRM_INFO("Applying shift eDP backlight brightness quirk\n");
> > > > > +}
> > > > > +
> > > > >  struct intel_quirk {
> > > > >       int device;
> > > > >       int subsystem_vendor;
> > > > > @@ -156,6 +166,9 @@ static struct intel_quirk intel_quirks[] = {
> > > > >       /* ASRock ITX*/
> > > > >       { 0x3185, 0x1849, 0x2212, quirk_increase_ddi_disabled_time },
> > > > >       { 0x3184, 0x1849, 0x2212, quirk_increase_ddi_disabled_time },
> > > > > +
> > > > > +     /* Google Pixelbook */
> > > > > +     { 0x591E, 0x8086, 0x2212, quirk_shift_edp_backlight_brightness
> > > > > },
> > > > >  };
> > > > > 
> > > > >  void intel_init_quirks(struct drm_i915_private *i915)
> > > > > diff --git a/drivers/gpu/drm/i915/i915_drv.h
> > > > > b/drivers/gpu/drm/i915/i915_drv.h
> > > > > index e4f7f6518945b..cc93bede4fab8 100644
> > > > > --- a/drivers/gpu/drm/i915/i915_drv.h
> > > > > +++ b/drivers/gpu/drm/i915/i915_drv.h
> > > > > @@ -525,6 +525,7 @@ struct i915_psr {
> > > > >  #define QUIRK_PIN_SWIZZLED_PAGES (1<<5)
> > > > >  #define QUIRK_INCREASE_T12_DELAY (1<<6)
> > > > >  #define QUIRK_INCREASE_DDI_DISABLED_TIME (1<<7)
> > > > > +#define QUIRK_SHIFT_EDP_BACKLIGHT_BRIGHTNESS (1<<8)
> > > > > 
> > > > >  struct intel_fbdev;
> > > > >  struct intel_fbc_work;
> > > > 
> > > > --
> > > > Jani Nikula, Intel Open Source Graphics Center
-- 
Sincerely,
      Lyude Paul (she/her)
      Software Engineer at Red Hat

Re: [Intel-gfx] [PATCH] i915: Introduce quirk for shifting eDP brightness.

[Ville Syrjälä]

On Thu, Sep 17, 2020 at 09:25:35PM +0300, Ville Syrjälä wrote:
> On Thu, Sep 17, 2020 at 11:14:43AM -0700, Puthikorn Voravootivat wrote:
> > The Lyude fde7266fb2f6 change is actually based on Chromium change
> > (https://crrev.com/c/1650325) that fixes the brightness for Samsung
> > Galaxy Chromebook. So currently we have 2 examples that use LSB
> > interpretation and 1 that use MSB.
> 
> "If field 4:0 of the EDP_PWMGEN_BIT_COUNT register represents a value
> of greater than 8 and the BACKLIGHT_BRIGHTNESS_BYTE_COUNT bit
> is cleared to 0, only the 8 MSB of the brightness control value can be
> controlled.
> (See Note below.)
> Assigned bits are allocated to the MSB of the enabled register
> combination."
> 
> I think that's pretty clear the assigned bits are supposed to be
> msb aligned.

I guess there's some email issues happening, but just to clarify:

When the spec says MSB in caps here it clearly means
"most significant-bit(s)" since otherwise "8 MSB" would not make
any sense in the context of a 2 byte value.

Granted the spec is crap here since "Table 1-1: Acronyms and
Initialism" does claim "MSB" should be byte(s) and "msb" bit(s).

Also I can't imagine anyone would allocate the bits starting
from the lsb when the whole thing is clearly supposed to be a
16bit big endian integer. So with >8 assigned bits you'd end
up with crazy stuff like this:

[ 7 ... 0 ][7   ...   0]
[ 8 MSB   ][XXXX][N LSB]

so you couldn't even treat the value as a regular big endian
thing. Instead, if you squint a bit, it now looks like a funky
little endian value. So we're deep into some mixed endian land
where nothing makes sense anymore.

Anyways I think the code should simply do this to match the spec:
u16 value = brightness << (16 - num_assigned_bits);
val[0] = value >> 8;
val[1] = value & 0xff;


> 
> > 
> > 
> > On Thu, Sep 17, 2020 at 10:55 AM Kevin Chowski <chowski@chromium.org> wrote:
> > >
> > > Apologies for being too vague. To be as precise I can be, here is the
> > > specific code delta I tested: https://crrev.com/c/2406616 . To answer
> > > your other question, the code I tested against is indeed including the
> > > fde7266fb2f6 (despite ostensibly being called 5.4 in my commit
> > > message): our current top-of-tree for our 5.4 branch includes the
> > > intel_dp_aux_calc_max_backlight logic. Further, I'll note that change
> > > is exactly the change which breaks my Pixelbook model: prior to the
> > > change, the max_brightness was hard-coded to 0xFFFF and the math
> > > worked out that it didn't matter that the hardware cared about the MSB
> > > despite the driver code caring about the LSB.
> > >
> > > To answer Ville's question: the fde7266fb2f6 change which fixes one
> > > laptop (I believe Thinkpad X1 extreme Gen 2, from some bug reports I
> > > dug up) and breaks another (Pixelbook); so unfortunately I believe we
> > > need a quirk at least for some laptop. Reading through the copy of the
> > > datasheet I have, it wasn't clear to me which was the correct
> > > interpretation. I'm cc'ing puthik@, who was leaning toward the current
> > > kernel code (caring about LSB) being the correct interpretation. I
> > > believe we have other chromebooks which do rely on LSB functionality,
> > > so unless we can find more examples of laptops wanting MSB it
> > > currently looks like Pixelbook is the outlier.
> > >
> > > On Thu, Sep 17, 2020 at 11:28 AM Jani Nikula
> > > <jani.nikula@linux.intel.com> wrote:
> > > >
> > > > On Thu, 17 Sep 2020, Kevin Chowski <chowski@chromium.org> wrote:
> > > > > We have observed that Google Pixelbook's backlight hardware is
> > > > > interpretting these backlight bits from the most-significant side of the
> > > > > 16 bit word (if DP_EDP_PWMGEN_BIT_COUNT < 16), whereas the driver code
> > > > > assumes the peripheral cares about the least-significant bits.
> > > > >
> > > > > Testing was done from within Chrome OS's build environment when the
> > > > > patch is backported to 5.4 (the version we are newly targeting for the
> > > > > Pixelbook); for the record:
> > > > >    $ emerge-eve-kernelnext sys-kernel/chromeos-kernel-5_4 && \
> > > > >       ./update_kernel.sh --remote=$IP
> > > > >
> > > > > I used `/sys/kernel/debug/dri/0/eDP-1/i915_dpcd` on my laptop to verify
> > > > > that the registers were being set according to what the actual hardware
> > > > > expects; I also observe that the backlight is noticeably brighter with
> > > > > this patch.
> > > >
> > > > It's unclear to me what kernel version this is against, and what you've
> > > > actually tested.
> > > >
> > > > Have you tried v5.7 kernel with Lyude's fde7266fb2f6 ("drm/i915: Fix eDP
> > > > DPCD aux max backlight calculations")?
> > > >
> > > > I just want to make sure you've tested with all the relevant fixes
> > > > before adding quirks.
> > > >
> > > > BR,
> > > > Jani.
> > > >
> > > > >
> > > > > Signed-off-by: Kevin Chowski <chowski@chromium.org>
> > > > > ---
> > > > >
> > > > >  .../drm/i915/display/intel_dp_aux_backlight.c | 34 +++++++++++++++++++
> > > > >  drivers/gpu/drm/i915/display/intel_quirks.c   | 13 +++++++
> > > > >  drivers/gpu/drm/i915/i915_drv.h               |  1 +
> > > > >  3 files changed, 48 insertions(+)
> > > > >
> > > > > 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 acbd7eb66cbe3..99c98f217356d 100644
> > > > > --- a/drivers/gpu/drm/i915/display/intel_dp_aux_backlight.c
> > > > > +++ b/drivers/gpu/drm/i915/display/intel_dp_aux_backlight.c
> > > > > @@ -91,6 +91,23 @@ static u32 intel_dp_aux_get_backlight(struct intel_connector *connector)
> > > > >       if (intel_dp->edp_dpcd[2] & DP_EDP_BACKLIGHT_BRIGHTNESS_BYTE_COUNT)
> > > > >               level = (read_val[0] << 8 | read_val[1]);
> > > > >
> > > > > +     if (i915->quirks & QUIRK_SHIFT_EDP_BACKLIGHT_BRIGHTNESS) {
> > > > > +             if (!drm_dp_dpcd_readb(&intel_dp->aux, DP_EDP_PWMGEN_BIT_COUNT,
> > > > > +                                             &read_val[0])) {
> > > > > +                     DRM_DEBUG_KMS("Failed to read DPCD register 0x%x\n",
> > > > > +                                     DP_EDP_PWMGEN_BIT_COUNT);
> > > > > +                     return 0;
> > > > > +             }
> > > > > +             // Only bits 4:0 are used, 7:5 are reserved.
> > > > > +             read_val[0] = read_val[0] & 0x1F;
> > > > > +             if (read_val[0] > 16) {
> > > > > +                     DRM_DEBUG_KMS("Invalid DP_EDP_PWNGEN_BIT_COUNT 0x%X, expected at most 16\n",
> > > > > +                                             read_val[0]);
> > > > > +                     return 0;
> > > > > +             }
> > > > > +             level >>= 16 - read_val[0];
> > > > > +     }
> > > > > +
> > > > >       return level;
> > > > >  }
> > > > >
> > > > > @@ -106,6 +123,23 @@ intel_dp_aux_set_backlight(const struct drm_connector_state *conn_state, u32 lev
> > > > >       struct drm_i915_private *i915 = dp_to_i915(intel_dp);
> > > > >       u8 vals[2] = { 0x0 };
> > > > >
> > > > > +     if (i915->quirks & QUIRK_SHIFT_EDP_BACKLIGHT_BRIGHTNESS) {
> > > > > +             if (!drm_dp_dpcd_readb(&intel_dp->aux, DP_EDP_PWMGEN_BIT_COUNT,
> > > > > +                                             &vals[0])) {
> > > > > +                     DRM_DEBUG_KMS("Failed to write aux backlight level: Failed to read DPCD register 0x%x\n",
> > > > > +                                       DP_EDP_PWMGEN_BIT_COUNT);
> > > > > +                     return;
> > > > > +             }
> > > > > +             // Only bits 4:0 are used, 7:5 are reserved.
> > > > > +             vals[0] = vals[0] & 0x1F;
> > > > > +             if (vals[0] > 16) {
> > > > > +                     DRM_DEBUG_KMS("Failed to write aux backlight level: Invalid DP_EDP_PWNGEN_BIT_COUNT 0x%X, expected at most 16\n",
> > > > > +                                             vals[0]);
> > > > > +                     return;
> > > > > +             }
> > > > > +             level <<= (16 - vals[0]) & 0xFFFF;
> > > > > +     }
> > > > > +
> > > > >       vals[0] = level;
> > > > >
> > > > >       /* Write the MSB and/or LSB */
> > > > > diff --git a/drivers/gpu/drm/i915/display/intel_quirks.c b/drivers/gpu/drm/i915/display/intel_quirks.c
> > > > > index 46beb155d835f..63b27d49b2864 100644
> > > > > --- a/drivers/gpu/drm/i915/display/intel_quirks.c
> > > > > +++ b/drivers/gpu/drm/i915/display/intel_quirks.c
> > > > > @@ -53,6 +53,16 @@ static void quirk_increase_ddi_disabled_time(struct drm_i915_private *i915)
> > > > >       drm_info(&i915->drm, "Applying Increase DDI Disabled quirk\n");
> > > > >  }
> > > > >
> > > > > +/*
> > > > > + * Some eDP backlight hardware uses the most-significant bits of the brightness
> > > > > + * register, so brightness values must be shifted first.
> > > > > + */
> > > > > +static void quirk_shift_edp_backlight_brightness(struct drm_i915_private *i915)
> > > > > +{
> > > > > +     i915->quirks |= QUIRK_SHIFT_EDP_BACKLIGHT_BRIGHTNESS;
> > > > > +     DRM_INFO("Applying shift eDP backlight brightness quirk\n");
> > > > > +}
> > > > > +
> > > > >  struct intel_quirk {
> > > > >       int device;
> > > > >       int subsystem_vendor;
> > > > > @@ -156,6 +166,9 @@ static struct intel_quirk intel_quirks[] = {
> > > > >       /* ASRock ITX*/
> > > > >       { 0x3185, 0x1849, 0x2212, quirk_increase_ddi_disabled_time },
> > > > >       { 0x3184, 0x1849, 0x2212, quirk_increase_ddi_disabled_time },
> > > > > +
> > > > > +     /* Google Pixelbook */
> > > > > +     { 0x591E, 0x8086, 0x2212, quirk_shift_edp_backlight_brightness },
> > > > >  };
> > > > >
> > > > >  void intel_init_quirks(struct drm_i915_private *i915)
> > > > > diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
> > > > > index e4f7f6518945b..cc93bede4fab8 100644
> > > > > --- a/drivers/gpu/drm/i915/i915_drv.h
> > > > > +++ b/drivers/gpu/drm/i915/i915_drv.h
> > > > > @@ -525,6 +525,7 @@ struct i915_psr {
> > > > >  #define QUIRK_PIN_SWIZZLED_PAGES (1<<5)
> > > > >  #define QUIRK_INCREASE_T12_DELAY (1<<6)
> > > > >  #define QUIRK_INCREASE_DDI_DISABLED_TIME (1<<7)
> > > > > +#define QUIRK_SHIFT_EDP_BACKLIGHT_BRIGHTNESS (1<<8)
> > > > >
> > > > >  struct intel_fbdev;
> > > > >  struct intel_fbc_work;
> > > >
> > > > --
> > > > Jani Nikula, Intel Open Source Graphics Center
> 
> -- 
> Ville Syrjälä
> Intel
> _______________________________________________
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx

-- 
Ville Syrjälä
Intel

Re: [Intel-gfx] [PATCH] i915: Introduce quirk for shifting eDP brightness.

[Kevin Chowski]

Apologies once again, some of my emails were bouncing for some
addresses yesterday. Hopefully it was a temporary condition; I'll
continue trying to dig into it on my end if it happens again for this
email.

Since there's evidence that some models want lsb and some (well, at
least one) want msb, my understanding is that we'll need a quirk one
way or the other (please correct if I'm mistaken). I unfortunately
don't have the ability to test anything other than the Pixelbook, so
if we decide the msb is the "right" way, then I will have to rely on
others to test (and find the OUI of) other models which require lsb.

I am happy to make any changes requested, but I do not at all have
enough background here to make the decision on whether the msb
functionality deserves the quirk or if the lsb one does. How can I
help you all come to an agreement here?

* It seems like Ville feels strongly about the msb being the correct
interpretation of the spec.
* It's unclear to me on which side of the fence Lyude falls, I
couldn't pick up a strong opinion in her clarifying question.
* Puthikorn seems to be on the side of lsb being correct, but maybe
was swayed by Ville's argument.

If no one feels that Ville's argument is not strong in some way, and
we go with that, I will get to work on the requested changes. I am
concerned, though, about changing the default functionality without
testing it widely to find the set of laptops which require the lsb
quirk. I'd appreciate any advice people might have about making this
change safely.

Thank you for your time,
Kevin

On Thu, Sep 17, 2020 at 2:11 PM Ville Syrjälä
<ville.syrjala@linux.intel.com> wrote:
>
> On Thu, Sep 17, 2020 at 09:25:35PM +0300, Ville Syrjälä wrote:
> > On Thu, Sep 17, 2020 at 11:14:43AM -0700, Puthikorn Voravootivat wrote:
> > > The Lyude fde7266fb2f6 change is actually based on Chromium change
> > > (https://crrev.com/c/1650325) that fixes the brightness for Samsung
> > > Galaxy Chromebook. So currently we have 2 examples that use LSB
> > > interpretation and 1 that use MSB.
> >
> > "If field 4:0 of the EDP_PWMGEN_BIT_COUNT register represents a value
> > of greater than 8 and the BACKLIGHT_BRIGHTNESS_BYTE_COUNT bit
> > is cleared to 0, only the 8 MSB of the brightness control value can be
> > controlled.
> > (See Note below.)
> > Assigned bits are allocated to the MSB of the enabled register
> > combination."
> >
> > I think that's pretty clear the assigned bits are supposed to be
> > msb aligned.
>
> I guess there's some email issues happening, but just to clarify:
>
> When the spec says MSB in caps here it clearly means
> "most significant-bit(s)" since otherwise "8 MSB" would not make
> any sense in the context of a 2 byte value.
>
> Granted the spec is crap here since "Table 1-1: Acronyms and
> Initialism" does claim "MSB" should be byte(s) and "msb" bit(s).
>
> Also I can't imagine anyone would allocate the bits starting
> from the lsb when the whole thing is clearly supposed to be a
> 16bit big endian integer. So with >8 assigned bits you'd end
> up with crazy stuff like this:
>
> [ 7 ... 0 ][7   ...   0]
> [ 8 MSB   ][XXXX][N LSB]
>
> so you couldn't even treat the value as a regular big endian
> thing. Instead, if you squint a bit, it now looks like a funky
> little endian value. So we're deep into some mixed endian land
> where nothing makes sense anymore.
>
> Anyways I think the code should simply do this to match the spec:
> u16 value = brightness << (16 - num_assigned_bits);
> val[0] = value >> 8;
> val[1] = value & 0xff;
>
>
> >
> > >
> > >
> > > On Thu, Sep 17, 2020 at 10:55 AM Kevin Chowski <chowski@chromium.org> wrote:
> > > >
> > > > Apologies for being too vague. To be as precise I can be, here is the
> > > > specific code delta I tested: https://crrev.com/c/2406616 . To answer
> > > > your other question, the code I tested against is indeed including the
> > > > fde7266fb2f6 (despite ostensibly being called 5.4 in my commit
> > > > message): our current top-of-tree for our 5.4 branch includes the
> > > > intel_dp_aux_calc_max_backlight logic. Further, I'll note that change
> > > > is exactly the change which breaks my Pixelbook model: prior to the
> > > > change, the max_brightness was hard-coded to 0xFFFF and the math
> > > > worked out that it didn't matter that the hardware cared about the MSB
> > > > despite the driver code caring about the LSB.
> > > >
> > > > To answer Ville's question: the fde7266fb2f6 change which fixes one
> > > > laptop (I believe Thinkpad X1 extreme Gen 2, from some bug reports I
> > > > dug up) and breaks another (Pixelbook); so unfortunately I believe we
> > > > need a quirk at least for some laptop. Reading through the copy of the
> > > > datasheet I have, it wasn't clear to me which was the correct
> > > > interpretation. I'm cc'ing puthik@, who was leaning toward the current
> > > > kernel code (caring about LSB) being the correct interpretation. I
> > > > believe we have other chromebooks which do rely on LSB functionality,
> > > > so unless we can find more examples of laptops wanting MSB it
> > > > currently looks like Pixelbook is the outlier.
> > > >
> > > > On Thu, Sep 17, 2020 at 11:28 AM Jani Nikula
> > > > <jani.nikula@linux.intel.com> wrote:
> > > > >
> > > > > On Thu, 17 Sep 2020, Kevin Chowski <chowski@chromium.org> wrote:
> > > > > > We have observed that Google Pixelbook's backlight hardware is
> > > > > > interpretting these backlight bits from the most-significant side of the
> > > > > > 16 bit word (if DP_EDP_PWMGEN_BIT_COUNT < 16), whereas the driver code
> > > > > > assumes the peripheral cares about the least-significant bits.
> > > > > >
> > > > > > Testing was done from within Chrome OS's build environment when the
> > > > > > patch is backported to 5.4 (the version we are newly targeting for the
> > > > > > Pixelbook); for the record:
> > > > > >    $ emerge-eve-kernelnext sys-kernel/chromeos-kernel-5_4 && \
> > > > > >       ./update_kernel.sh --remote=$IP
> > > > > >
> > > > > > I used `/sys/kernel/debug/dri/0/eDP-1/i915_dpcd` on my laptop to verify
> > > > > > that the registers were being set according to what the actual hardware
> > > > > > expects; I also observe that the backlight is noticeably brighter with
> > > > > > this patch.
> > > > >
> > > > > It's unclear to me what kernel version this is against, and what you've
> > > > > actually tested.
> > > > >
> > > > > Have you tried v5.7 kernel with Lyude's fde7266fb2f6 ("drm/i915: Fix eDP
> > > > > DPCD aux max backlight calculations")?
> > > > >
> > > > > I just want to make sure you've tested with all the relevant fixes
> > > > > before adding quirks.
> > > > >
> > > > > BR,
> > > > > Jani.
> > > > >
> > > > > >
> > > > > > Signed-off-by: Kevin Chowski <chowski@chromium.org>
> > > > > > ---
> > > > > >
> > > > > >  .../drm/i915/display/intel_dp_aux_backlight.c | 34 +++++++++++++++++++
> > > > > >  drivers/gpu/drm/i915/display/intel_quirks.c   | 13 +++++++
> > > > > >  drivers/gpu/drm/i915/i915_drv.h               |  1 +
> > > > > >  3 files changed, 48 insertions(+)
> > > > > >
> > > > > > 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 acbd7eb66cbe3..99c98f217356d 100644
> > > > > > --- a/drivers/gpu/drm/i915/display/intel_dp_aux_backlight.c
> > > > > > +++ b/drivers/gpu/drm/i915/display/intel_dp_aux_backlight.c
> > > > > > @@ -91,6 +91,23 @@ static u32 intel_dp_aux_get_backlight(struct intel_connector *connector)
> > > > > >       if (intel_dp->edp_dpcd[2] & DP_EDP_BACKLIGHT_BRIGHTNESS_BYTE_COUNT)
> > > > > >               level = (read_val[0] << 8 | read_val[1]);
> > > > > >
> > > > > > +     if (i915->quirks & QUIRK_SHIFT_EDP_BACKLIGHT_BRIGHTNESS) {
> > > > > > +             if (!drm_dp_dpcd_readb(&intel_dp->aux, DP_EDP_PWMGEN_BIT_COUNT,
> > > > > > +                                             &read_val[0])) {
> > > > > > +                     DRM_DEBUG_KMS("Failed to read DPCD register 0x%x\n",
> > > > > > +                                     DP_EDP_PWMGEN_BIT_COUNT);
> > > > > > +                     return 0;
> > > > > > +             }
> > > > > > +             // Only bits 4:0 are used, 7:5 are reserved.
> > > > > > +             read_val[0] = read_val[0] & 0x1F;
> > > > > > +             if (read_val[0] > 16) {
> > > > > > +                     DRM_DEBUG_KMS("Invalid DP_EDP_PWNGEN_BIT_COUNT 0x%X, expected at most 16\n",
> > > > > > +                                             read_val[0]);
> > > > > > +                     return 0;
> > > > > > +             }
> > > > > > +             level >>= 16 - read_val[0];
> > > > > > +     }
> > > > > > +
> > > > > >       return level;
> > > > > >  }
> > > > > >
> > > > > > @@ -106,6 +123,23 @@ intel_dp_aux_set_backlight(const struct drm_connector_state *conn_state, u32 lev
> > > > > >       struct drm_i915_private *i915 = dp_to_i915(intel_dp);
> > > > > >       u8 vals[2] = { 0x0 };
> > > > > >
> > > > > > +     if (i915->quirks & QUIRK_SHIFT_EDP_BACKLIGHT_BRIGHTNESS) {
> > > > > > +             if (!drm_dp_dpcd_readb(&intel_dp->aux, DP_EDP_PWMGEN_BIT_COUNT,
> > > > > > +                                             &vals[0])) {
> > > > > > +                     DRM_DEBUG_KMS("Failed to write aux backlight level: Failed to read DPCD register 0x%x\n",
> > > > > > +                                       DP_EDP_PWMGEN_BIT_COUNT);
> > > > > > +                     return;
> > > > > > +             }
> > > > > > +             // Only bits 4:0 are used, 7:5 are reserved.
> > > > > > +             vals[0] = vals[0] & 0x1F;
> > > > > > +             if (vals[0] > 16) {
> > > > > > +                     DRM_DEBUG_KMS("Failed to write aux backlight level: Invalid DP_EDP_PWNGEN_BIT_COUNT 0x%X, expected at most 16\n",
> > > > > > +                                             vals[0]);
> > > > > > +                     return;
> > > > > > +             }
> > > > > > +             level <<= (16 - vals[0]) & 0xFFFF;
> > > > > > +     }
> > > > > > +
> > > > > >       vals[0] = level;
> > > > > >
> > > > > >       /* Write the MSB and/or LSB */
> > > > > > diff --git a/drivers/gpu/drm/i915/display/intel_quirks.c b/drivers/gpu/drm/i915/display/intel_quirks.c
> > > > > > index 46beb155d835f..63b27d49b2864 100644
> > > > > > --- a/drivers/gpu/drm/i915/display/intel_quirks.c
> > > > > > +++ b/drivers/gpu/drm/i915/display/intel_quirks.c
> > > > > > @@ -53,6 +53,16 @@ static void quirk_increase_ddi_disabled_time(struct drm_i915_private *i915)
> > > > > >       drm_info(&i915->drm, "Applying Increase DDI Disabled quirk\n");
> > > > > >  }
> > > > > >
> > > > > > +/*
> > > > > > + * Some eDP backlight hardware uses the most-significant bits of the brightness
> > > > > > + * register, so brightness values must be shifted first.
> > > > > > + */
> > > > > > +static void quirk_shift_edp_backlight_brightness(struct drm_i915_private *i915)
> > > > > > +{
> > > > > > +     i915->quirks |= QUIRK_SHIFT_EDP_BACKLIGHT_BRIGHTNESS;
> > > > > > +     DRM_INFO("Applying shift eDP backlight brightness quirk\n");
> > > > > > +}
> > > > > > +
> > > > > >  struct intel_quirk {
> > > > > >       int device;
> > > > > >       int subsystem_vendor;
> > > > > > @@ -156,6 +166,9 @@ static struct intel_quirk intel_quirks[] = {
> > > > > >       /* ASRock ITX*/
> > > > > >       { 0x3185, 0x1849, 0x2212, quirk_increase_ddi_disabled_time },
> > > > > >       { 0x3184, 0x1849, 0x2212, quirk_increase_ddi_disabled_time },
> > > > > > +
> > > > > > +     /* Google Pixelbook */
> > > > > > +     { 0x591E, 0x8086, 0x2212, quirk_shift_edp_backlight_brightness },
> > > > > >  };
> > > > > >
> > > > > >  void intel_init_quirks(struct drm_i915_private *i915)
> > > > > > diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
> > > > > > index e4f7f6518945b..cc93bede4fab8 100644
> > > > > > --- a/drivers/gpu/drm/i915/i915_drv.h
> > > > > > +++ b/drivers/gpu/drm/i915/i915_drv.h
> > > > > > @@ -525,6 +525,7 @@ struct i915_psr {
> > > > > >  #define QUIRK_PIN_SWIZZLED_PAGES (1<<5)
> > > > > >  #define QUIRK_INCREASE_T12_DELAY (1<<6)
> > > > > >  #define QUIRK_INCREASE_DDI_DISABLED_TIME (1<<7)
> > > > > > +#define QUIRK_SHIFT_EDP_BACKLIGHT_BRIGHTNESS (1<<8)
> > > > > >
> > > > > >  struct intel_fbdev;
> > > > > >  struct intel_fbc_work;
> > > > >
> > > > > --
> > > > > Jani Nikula, Intel Open Source Graphics Center
> >
> > --
> > Ville Syrjälä
> > Intel
> > _______________________________________________
> > Intel-gfx mailing list
> > Intel-gfx@lists.freedesktop.org
> > https://lists.freedesktop.org/mailman/listinfo/intel-gfx
>
> --
> Ville Syrjälä
> Intel

Re: [Intel-gfx] [PATCH] i915: Introduce quirk for shifting eDP brightness.

[Puthikorn Voravootivat]

I'll defer to Ville & Lyude.

I dug up more on the bug report and found that both Thinkpad and
Galaxy Chromebook use the same Samsung OLED.
So my 2 vs 1 argument is actually not valid.

On Fri, Sep 18, 2020 at 10:59 AM Kevin Chowski <chowski@chromium.org> wrote:
>
> Apologies once again, some of my emails were bouncing for some
> addresses yesterday. Hopefully it was a temporary condition; I'll
> continue trying to dig into it on my end if it happens again for this
> email.
>
> Since there's evidence that some models want lsb and some (well, at
> least one) want msb, my understanding is that we'll need a quirk one
> way or the other (please correct if I'm mistaken). I unfortunately
> don't have the ability to test anything other than the Pixelbook, so
> if we decide the msb is the "right" way, then I will have to rely on
> others to test (and find the OUI of) other models which require lsb.
>
> I am happy to make any changes requested, but I do not at all have
> enough background here to make the decision on whether the msb
> functionality deserves the quirk or if the lsb one does. How can I
> help you all come to an agreement here?
>
> * It seems like Ville feels strongly about the msb being the correct
> interpretation of the spec.
> * It's unclear to me on which side of the fence Lyude falls, I
> couldn't pick up a strong opinion in her clarifying question.
> * Puthikorn seems to be on the side of lsb being correct, but maybe
> was swayed by Ville's argument.
>
> If no one feels that Ville's argument is not strong in some way, and
> we go with that, I will get to work on the requested changes. I am
> concerned, though, about changing the default functionality without
> testing it widely to find the set of laptops which require the lsb
> quirk. I'd appreciate any advice people might have about making this
> change safely.
>
> Thank you for your time,
> Kevin
>
> On Thu, Sep 17, 2020 at 2:11 PM Ville Syrjälä
> <ville.syrjala@linux.intel.com> wrote:
> >
> > On Thu, Sep 17, 2020 at 09:25:35PM +0300, Ville Syrjälä wrote:
> > > On Thu, Sep 17, 2020 at 11:14:43AM -0700, Puthikorn Voravootivat wrote:
> > > > The Lyude fde7266fb2f6 change is actually based on Chromium change
> > > > (https://crrev.com/c/1650325) that fixes the brightness for Samsung
> > > > Galaxy Chromebook. So currently we have 2 examples that use LSB
> > > > interpretation and 1 that use MSB.
> > >
> > > "If field 4:0 of the EDP_PWMGEN_BIT_COUNT register represents a value
> > > of greater than 8 and the BACKLIGHT_BRIGHTNESS_BYTE_COUNT bit
> > > is cleared to 0, only the 8 MSB of the brightness control value can be
> > > controlled.
> > > (See Note below.)
> > > Assigned bits are allocated to the MSB of the enabled register
> > > combination."
> > >
> > > I think that's pretty clear the assigned bits are supposed to be
> > > msb aligned.
> >
> > I guess there's some email issues happening, but just to clarify:
> >
> > When the spec says MSB in caps here it clearly means
> > "most significant-bit(s)" since otherwise "8 MSB" would not make
> > any sense in the context of a 2 byte value.
> >
> > Granted the spec is crap here since "Table 1-1: Acronyms and
> > Initialism" does claim "MSB" should be byte(s) and "msb" bit(s).
> >
> > Also I can't imagine anyone would allocate the bits starting
> > from the lsb when the whole thing is clearly supposed to be a
> > 16bit big endian integer. So with >8 assigned bits you'd end
> > up with crazy stuff like this:
> >
> > [ 7 ... 0 ][7   ...   0]
> > [ 8 MSB   ][XXXX][N LSB]
> >
> > so you couldn't even treat the value as a regular big endian
> > thing. Instead, if you squint a bit, it now looks like a funky
> > little endian value. So we're deep into some mixed endian land
> > where nothing makes sense anymore.
> >
> > Anyways I think the code should simply do this to match the spec:
> > u16 value = brightness << (16 - num_assigned_bits);
> > val[0] = value >> 8;
> > val[1] = value & 0xff;
> >
> >
> > >
> > > >
> > > >
> > > > On Thu, Sep 17, 2020 at 10:55 AM Kevin Chowski <chowski@chromium.org> wrote:
> > > > >
> > > > > Apologies for being too vague. To be as precise I can be, here is the
> > > > > specific code delta I tested: https://crrev.com/c/2406616 . To answer
> > > > > your other question, the code I tested against is indeed including the
> > > > > fde7266fb2f6 (despite ostensibly being called 5.4 in my commit
> > > > > message): our current top-of-tree for our 5.4 branch includes the
> > > > > intel_dp_aux_calc_max_backlight logic. Further, I'll note that change
> > > > > is exactly the change which breaks my Pixelbook model: prior to the
> > > > > change, the max_brightness was hard-coded to 0xFFFF and the math
> > > > > worked out that it didn't matter that the hardware cared about the MSB
> > > > > despite the driver code caring about the LSB.
> > > > >
> > > > > To answer Ville's question: the fde7266fb2f6 change which fixes one
> > > > > laptop (I believe Thinkpad X1 extreme Gen 2, from some bug reports I
> > > > > dug up) and breaks another (Pixelbook); so unfortunately I believe we
> > > > > need a quirk at least for some laptop. Reading through the copy of the
> > > > > datasheet I have, it wasn't clear to me which was the correct
> > > > > interpretation. I'm cc'ing puthik@, who was leaning toward the current
> > > > > kernel code (caring about LSB) being the correct interpretation. I
> > > > > believe we have other chromebooks which do rely on LSB functionality,
> > > > > so unless we can find more examples of laptops wanting MSB it
> > > > > currently looks like Pixelbook is the outlier.
> > > > >
> > > > > On Thu, Sep 17, 2020 at 11:28 AM Jani Nikula
> > > > > <jani.nikula@linux.intel.com> wrote:
> > > > > >
> > > > > > On Thu, 17 Sep 2020, Kevin Chowski <chowski@chromium.org> wrote:
> > > > > > > We have observed that Google Pixelbook's backlight hardware is
> > > > > > > interpretting these backlight bits from the most-significant side of the
> > > > > > > 16 bit word (if DP_EDP_PWMGEN_BIT_COUNT < 16), whereas the driver code
> > > > > > > assumes the peripheral cares about the least-significant bits.
> > > > > > >
> > > > > > > Testing was done from within Chrome OS's build environment when the
> > > > > > > patch is backported to 5.4 (the version we are newly targeting for the
> > > > > > > Pixelbook); for the record:
> > > > > > >    $ emerge-eve-kernelnext sys-kernel/chromeos-kernel-5_4 && \
> > > > > > >       ./update_kernel.sh --remote=$IP
> > > > > > >
> > > > > > > I used `/sys/kernel/debug/dri/0/eDP-1/i915_dpcd` on my laptop to verify
> > > > > > > that the registers were being set according to what the actual hardware
> > > > > > > expects; I also observe that the backlight is noticeably brighter with
> > > > > > > this patch.
> > > > > >
> > > > > > It's unclear to me what kernel version this is against, and what you've
> > > > > > actually tested.
> > > > > >
> > > > > > Have you tried v5.7 kernel with Lyude's fde7266fb2f6 ("drm/i915: Fix eDP
> > > > > > DPCD aux max backlight calculations")?
> > > > > >
> > > > > > I just want to make sure you've tested with all the relevant fixes
> > > > > > before adding quirks.
> > > > > >
> > > > > > BR,
> > > > > > Jani.
> > > > > >
> > > > > > >
> > > > > > > Signed-off-by: Kevin Chowski <chowski@chromium.org>
> > > > > > > ---
> > > > > > >
> > > > > > >  .../drm/i915/display/intel_dp_aux_backlight.c | 34 +++++++++++++++++++
> > > > > > >  drivers/gpu/drm/i915/display/intel_quirks.c   | 13 +++++++
> > > > > > >  drivers/gpu/drm/i915/i915_drv.h               |  1 +
> > > > > > >  3 files changed, 48 insertions(+)
> > > > > > >
> > > > > > > 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 acbd7eb66cbe3..99c98f217356d 100644
> > > > > > > --- a/drivers/gpu/drm/i915/display/intel_dp_aux_backlight.c
> > > > > > > +++ b/drivers/gpu/drm/i915/display/intel_dp_aux_backlight.c
> > > > > > > @@ -91,6 +91,23 @@ static u32 intel_dp_aux_get_backlight(struct intel_connector *connector)
> > > > > > >       if (intel_dp->edp_dpcd[2] & DP_EDP_BACKLIGHT_BRIGHTNESS_BYTE_COUNT)
> > > > > > >               level = (read_val[0] << 8 | read_val[1]);
> > > > > > >
> > > > > > > +     if (i915->quirks & QUIRK_SHIFT_EDP_BACKLIGHT_BRIGHTNESS) {
> > > > > > > +             if (!drm_dp_dpcd_readb(&intel_dp->aux, DP_EDP_PWMGEN_BIT_COUNT,
> > > > > > > +                                             &read_val[0])) {
> > > > > > > +                     DRM_DEBUG_KMS("Failed to read DPCD register 0x%x\n",
> > > > > > > +                                     DP_EDP_PWMGEN_BIT_COUNT);
> > > > > > > +                     return 0;
> > > > > > > +             }
> > > > > > > +             // Only bits 4:0 are used, 7:5 are reserved.
> > > > > > > +             read_val[0] = read_val[0] & 0x1F;
> > > > > > > +             if (read_val[0] > 16) {
> > > > > > > +                     DRM_DEBUG_KMS("Invalid DP_EDP_PWNGEN_BIT_COUNT 0x%X, expected at most 16\n",
> > > > > > > +                                             read_val[0]);
> > > > > > > +                     return 0;
> > > > > > > +             }
> > > > > > > +             level >>= 16 - read_val[0];
> > > > > > > +     }
> > > > > > > +
> > > > > > >       return level;
> > > > > > >  }
> > > > > > >
> > > > > > > @@ -106,6 +123,23 @@ intel_dp_aux_set_backlight(const struct drm_connector_state *conn_state, u32 lev
> > > > > > >       struct drm_i915_private *i915 = dp_to_i915(intel_dp);
> > > > > > >       u8 vals[2] = { 0x0 };
> > > > > > >
> > > > > > > +     if (i915->quirks & QUIRK_SHIFT_EDP_BACKLIGHT_BRIGHTNESS) {
> > > > > > > +             if (!drm_dp_dpcd_readb(&intel_dp->aux, DP_EDP_PWMGEN_BIT_COUNT,
> > > > > > > +                                             &vals[0])) {
> > > > > > > +                     DRM_DEBUG_KMS("Failed to write aux backlight level: Failed to read DPCD register 0x%x\n",
> > > > > > > +                                       DP_EDP_PWMGEN_BIT_COUNT);
> > > > > > > +                     return;
> > > > > > > +             }
> > > > > > > +             // Only bits 4:0 are used, 7:5 are reserved.
> > > > > > > +             vals[0] = vals[0] & 0x1F;
> > > > > > > +             if (vals[0] > 16) {
> > > > > > > +                     DRM_DEBUG_KMS("Failed to write aux backlight level: Invalid DP_EDP_PWNGEN_BIT_COUNT 0x%X, expected at most 16\n",
> > > > > > > +                                             vals[0]);
> > > > > > > +                     return;
> > > > > > > +             }
> > > > > > > +             level <<= (16 - vals[0]) & 0xFFFF;
> > > > > > > +     }
> > > > > > > +
> > > > > > >       vals[0] = level;
> > > > > > >
> > > > > > >       /* Write the MSB and/or LSB */
> > > > > > > diff --git a/drivers/gpu/drm/i915/display/intel_quirks.c b/drivers/gpu/drm/i915/display/intel_quirks.c
> > > > > > > index 46beb155d835f..63b27d49b2864 100644
> > > > > > > --- a/drivers/gpu/drm/i915/display/intel_quirks.c
> > > > > > > +++ b/drivers/gpu/drm/i915/display/intel_quirks.c
> > > > > > > @@ -53,6 +53,16 @@ static void quirk_increase_ddi_disabled_time(struct drm_i915_private *i915)
> > > > > > >       drm_info(&i915->drm, "Applying Increase DDI Disabled quirk\n");
> > > > > > >  }
> > > > > > >
> > > > > > > +/*
> > > > > > > + * Some eDP backlight hardware uses the most-significant bits of the brightness
> > > > > > > + * register, so brightness values must be shifted first.
> > > > > > > + */
> > > > > > > +static void quirk_shift_edp_backlight_brightness(struct drm_i915_private *i915)
> > > > > > > +{
> > > > > > > +     i915->quirks |= QUIRK_SHIFT_EDP_BACKLIGHT_BRIGHTNESS;
> > > > > > > +     DRM_INFO("Applying shift eDP backlight brightness quirk\n");
> > > > > > > +}
> > > > > > > +
> > > > > > >  struct intel_quirk {
> > > > > > >       int device;
> > > > > > >       int subsystem_vendor;
> > > > > > > @@ -156,6 +166,9 @@ static struct intel_quirk intel_quirks[] = {
> > > > > > >       /* ASRock ITX*/
> > > > > > >       { 0x3185, 0x1849, 0x2212, quirk_increase_ddi_disabled_time },
> > > > > > >       { 0x3184, 0x1849, 0x2212, quirk_increase_ddi_disabled_time },
> > > > > > > +
> > > > > > > +     /* Google Pixelbook */
> > > > > > > +     { 0x591E, 0x8086, 0x2212, quirk_shift_edp_backlight_brightness },
> > > > > > >  };
> > > > > > >
> > > > > > >  void intel_init_quirks(struct drm_i915_private *i915)
> > > > > > > diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
> > > > > > > index e4f7f6518945b..cc93bede4fab8 100644
> > > > > > > --- a/drivers/gpu/drm/i915/i915_drv.h
> > > > > > > +++ b/drivers/gpu/drm/i915/i915_drv.h
> > > > > > > @@ -525,6 +525,7 @@ struct i915_psr {
> > > > > > >  #define QUIRK_PIN_SWIZZLED_PAGES (1<<5)
> > > > > > >  #define QUIRK_INCREASE_T12_DELAY (1<<6)
> > > > > > >  #define QUIRK_INCREASE_DDI_DISABLED_TIME (1<<7)
> > > > > > > +#define QUIRK_SHIFT_EDP_BACKLIGHT_BRIGHTNESS (1<<8)
> > > > > > >
> > > > > > >  struct intel_fbdev;
> > > > > > >  struct intel_fbc_work;
> > > > > >
> > > > > > --
> > > > > > Jani Nikula, Intel Open Source Graphics Center
> > >
> > > --
> > > Ville Syrjälä
> > > Intel
> > > _______________________________________________
> > > Intel-gfx mailing list
> > > Intel-gfx@lists.freedesktop.org
> > > https://lists.freedesktop.org/mailman/listinfo/intel-gfx
> >
> > --
> > Ville Syrjälä
> > Intel

Re: [Intel-gfx] [PATCH] i915: Introduce quirk for shifting eDP brightness.

[Kevin Chowski]

Alrighty, I'll take everyone else's silence as tacit approval of
Ville's opinions. (I didn't receive any email bounces this time, so I
think my issue was transient.) I will start on inverting the quirk and
making the most-significant-alignment matter for these registers by
default.

Who can help me gather a list of OUIs that we need to add to the
quirk? I can follow up with Puthikorn about the relevant Chromebooks,
but I don't know what other types of laptops are using this driver.

Thanks for your time,
Kevin Chowski


On Fri, Sep 18, 2020 at 12:16 PM Puthikorn Voravootivat
<puthik@chromium.org> wrote:
>
> I'll defer to Ville & Lyude.
>
> I dug up more on the bug report and found that both Thinkpad and
> Galaxy Chromebook use the same Samsung OLED.
> So my 2 vs 1 argument is actually not valid.
>
> On Fri, Sep 18, 2020 at 10:59 AM Kevin Chowski <chowski@chromium.org> wrote:
> >
> > Apologies once again, some of my emails were bouncing for some
> > addresses yesterday. Hopefully it was a temporary condition; I'll
> > continue trying to dig into it on my end if it happens again for this
> > email.
> >
> > Since there's evidence that some models want lsb and some (well, at
> > least one) want msb, my understanding is that we'll need a quirk one
> > way or the other (please correct if I'm mistaken). I unfortunately
> > don't have the ability to test anything other than the Pixelbook, so
> > if we decide the msb is the "right" way, then I will have to rely on
> > others to test (and find the OUI of) other models which require lsb.
> >
> > I am happy to make any changes requested, but I do not at all have
> > enough background here to make the decision on whether the msb
> > functionality deserves the quirk or if the lsb one does. How can I
> > help you all come to an agreement here?
> >
> > * It seems like Ville feels strongly about the msb being the correct
> > interpretation of the spec.
> > * It's unclear to me on which side of the fence Lyude falls, I
> > couldn't pick up a strong opinion in her clarifying question.
> > * Puthikorn seems to be on the side of lsb being correct, but maybe
> > was swayed by Ville's argument.
> >
> > If no one feels that Ville's argument is not strong in some way, and
> > we go with that, I will get to work on the requested changes. I am
> > concerned, though, about changing the default functionality without
> > testing it widely to find the set of laptops which require the lsb
> > quirk. I'd appreciate any advice people might have about making this
> > change safely.
> >
> > Thank you for your time,
> > Kevin
> >
> > On Thu, Sep 17, 2020 at 2:11 PM Ville Syrjälä
> > <ville.syrjala@linux.intel.com> wrote:
> > >
> > > On Thu, Sep 17, 2020 at 09:25:35PM +0300, Ville Syrjälä wrote:
> > > > On Thu, Sep 17, 2020 at 11:14:43AM -0700, Puthikorn Voravootivat wrote:
> > > > > The Lyude fde7266fb2f6 change is actually based on Chromium change
> > > > > (https://crrev.com/c/1650325) that fixes the brightness for Samsung
> > > > > Galaxy Chromebook. So currently we have 2 examples that use LSB
> > > > > interpretation and 1 that use MSB.
> > > >
> > > > "If field 4:0 of the EDP_PWMGEN_BIT_COUNT register represents a value
> > > > of greater than 8 and the BACKLIGHT_BRIGHTNESS_BYTE_COUNT bit
> > > > is cleared to 0, only the 8 MSB of the brightness control value can be
> > > > controlled.
> > > > (See Note below.)
> > > > Assigned bits are allocated to the MSB of the enabled register
> > > > combination."
> > > >
> > > > I think that's pretty clear the assigned bits are supposed to be
> > > > msb aligned.
> > >
> > > I guess there's some email issues happening, but just to clarify:
> > >
> > > When the spec says MSB in caps here it clearly means
> > > "most significant-bit(s)" since otherwise "8 MSB" would not make
> > > any sense in the context of a 2 byte value.
> > >
> > > Granted the spec is crap here since "Table 1-1: Acronyms and
> > > Initialism" does claim "MSB" should be byte(s) and "msb" bit(s).
> > >
> > > Also I can't imagine anyone would allocate the bits starting
> > > from the lsb when the whole thing is clearly supposed to be a
> > > 16bit big endian integer. So with >8 assigned bits you'd end
> > > up with crazy stuff like this:
> > >
> > > [ 7 ... 0 ][7   ...   0]
> > > [ 8 MSB   ][XXXX][N LSB]
> > >
> > > so you couldn't even treat the value as a regular big endian
> > > thing. Instead, if you squint a bit, it now looks like a funky
> > > little endian value. So we're deep into some mixed endian land
> > > where nothing makes sense anymore.
> > >
> > > Anyways I think the code should simply do this to match the spec:
> > > u16 value = brightness << (16 - num_assigned_bits);
> > > val[0] = value >> 8;
> > > val[1] = value & 0xff;
> > >
> > >
> > > >
> > > > >
> > > > >
> > > > > On Thu, Sep 17, 2020 at 10:55 AM Kevin Chowski <chowski@chromium.org> wrote:
> > > > > >
> > > > > > Apologies for being too vague. To be as precise I can be, here is the
> > > > > > specific code delta I tested: https://crrev.com/c/2406616 . To answer
> > > > > > your other question, the code I tested against is indeed including the
> > > > > > fde7266fb2f6 (despite ostensibly being called 5.4 in my commit
> > > > > > message): our current top-of-tree for our 5.4 branch includes the
> > > > > > intel_dp_aux_calc_max_backlight logic. Further, I'll note that change
> > > > > > is exactly the change which breaks my Pixelbook model: prior to the
> > > > > > change, the max_brightness was hard-coded to 0xFFFF and the math
> > > > > > worked out that it didn't matter that the hardware cared about the MSB
> > > > > > despite the driver code caring about the LSB.
> > > > > >
> > > > > > To answer Ville's question: the fde7266fb2f6 change which fixes one
> > > > > > laptop (I believe Thinkpad X1 extreme Gen 2, from some bug reports I
> > > > > > dug up) and breaks another (Pixelbook); so unfortunately I believe we
> > > > > > need a quirk at least for some laptop. Reading through the copy of the
> > > > > > datasheet I have, it wasn't clear to me which was the correct
> > > > > > interpretation. I'm cc'ing puthik@, who was leaning toward the current
> > > > > > kernel code (caring about LSB) being the correct interpretation. I
> > > > > > believe we have other chromebooks which do rely on LSB functionality,
> > > > > > so unless we can find more examples of laptops wanting MSB it
> > > > > > currently looks like Pixelbook is the outlier.
> > > > > >
> > > > > > On Thu, Sep 17, 2020 at 11:28 AM Jani Nikula
> > > > > > <jani.nikula@linux.intel.com> wrote:
> > > > > > >
> > > > > > > On Thu, 17 Sep 2020, Kevin Chowski <chowski@chromium.org> wrote:
> > > > > > > > We have observed that Google Pixelbook's backlight hardware is
> > > > > > > > interpretting these backlight bits from the most-significant side of the
> > > > > > > > 16 bit word (if DP_EDP_PWMGEN_BIT_COUNT < 16), whereas the driver code
> > > > > > > > assumes the peripheral cares about the least-significant bits.
> > > > > > > >
> > > > > > > > Testing was done from within Chrome OS's build environment when the
> > > > > > > > patch is backported to 5.4 (the version we are newly targeting for the
> > > > > > > > Pixelbook); for the record:
> > > > > > > >    $ emerge-eve-kernelnext sys-kernel/chromeos-kernel-5_4 && \
> > > > > > > >       ./update_kernel.sh --remote=$IP
> > > > > > > >
> > > > > > > > I used `/sys/kernel/debug/dri/0/eDP-1/i915_dpcd` on my laptop to verify
> > > > > > > > that the registers were being set according to what the actual hardware
> > > > > > > > expects; I also observe that the backlight is noticeably brighter with
> > > > > > > > this patch.
> > > > > > >
> > > > > > > It's unclear to me what kernel version this is against, and what you've
> > > > > > > actually tested.
> > > > > > >
> > > > > > > Have you tried v5.7 kernel with Lyude's fde7266fb2f6 ("drm/i915: Fix eDP
> > > > > > > DPCD aux max backlight calculations")?
> > > > > > >
> > > > > > > I just want to make sure you've tested with all the relevant fixes
> > > > > > > before adding quirks.
> > > > > > >
> > > > > > > BR,
> > > > > > > Jani.
> > > > > > >
> > > > > > > >
> > > > > > > > Signed-off-by: Kevin Chowski <chowski@chromium.org>
> > > > > > > > ---
> > > > > > > >
> > > > > > > >  .../drm/i915/display/intel_dp_aux_backlight.c | 34 +++++++++++++++++++
> > > > > > > >  drivers/gpu/drm/i915/display/intel_quirks.c   | 13 +++++++
> > > > > > > >  drivers/gpu/drm/i915/i915_drv.h               |  1 +
> > > > > > > >  3 files changed, 48 insertions(+)
> > > > > > > >
> > > > > > > > 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 acbd7eb66cbe3..99c98f217356d 100644
> > > > > > > > --- a/drivers/gpu/drm/i915/display/intel_dp_aux_backlight.c
> > > > > > > > +++ b/drivers/gpu/drm/i915/display/intel_dp_aux_backlight.c
> > > > > > > > @@ -91,6 +91,23 @@ static u32 intel_dp_aux_get_backlight(struct intel_connector *connector)
> > > > > > > >       if (intel_dp->edp_dpcd[2] & DP_EDP_BACKLIGHT_BRIGHTNESS_BYTE_COUNT)
> > > > > > > >               level = (read_val[0] << 8 | read_val[1]);
> > > > > > > >
> > > > > > > > +     if (i915->quirks & QUIRK_SHIFT_EDP_BACKLIGHT_BRIGHTNESS) {
> > > > > > > > +             if (!drm_dp_dpcd_readb(&intel_dp->aux, DP_EDP_PWMGEN_BIT_COUNT,
> > > > > > > > +                                             &read_val[0])) {
> > > > > > > > +                     DRM_DEBUG_KMS("Failed to read DPCD register 0x%x\n",
> > > > > > > > +                                     DP_EDP_PWMGEN_BIT_COUNT);
> > > > > > > > +                     return 0;
> > > > > > > > +             }
> > > > > > > > +             // Only bits 4:0 are used, 7:5 are reserved.
> > > > > > > > +             read_val[0] = read_val[0] & 0x1F;
> > > > > > > > +             if (read_val[0] > 16) {
> > > > > > > > +                     DRM_DEBUG_KMS("Invalid DP_EDP_PWNGEN_BIT_COUNT 0x%X, expected at most 16\n",
> > > > > > > > +                                             read_val[0]);
> > > > > > > > +                     return 0;
> > > > > > > > +             }
> > > > > > > > +             level >>= 16 - read_val[0];
> > > > > > > > +     }
> > > > > > > > +
> > > > > > > >       return level;
> > > > > > > >  }
> > > > > > > >
> > > > > > > > @@ -106,6 +123,23 @@ intel_dp_aux_set_backlight(const struct drm_connector_state *conn_state, u32 lev
> > > > > > > >       struct drm_i915_private *i915 = dp_to_i915(intel_dp);
> > > > > > > >       u8 vals[2] = { 0x0 };
> > > > > > > >
> > > > > > > > +     if (i915->quirks & QUIRK_SHIFT_EDP_BACKLIGHT_BRIGHTNESS) {
> > > > > > > > +             if (!drm_dp_dpcd_readb(&intel_dp->aux, DP_EDP_PWMGEN_BIT_COUNT,
> > > > > > > > +                                             &vals[0])) {
> > > > > > > > +                     DRM_DEBUG_KMS("Failed to write aux backlight level: Failed to read DPCD register 0x%x\n",
> > > > > > > > +                                       DP_EDP_PWMGEN_BIT_COUNT);
> > > > > > > > +                     return;
> > > > > > > > +             }
> > > > > > > > +             // Only bits 4:0 are used, 7:5 are reserved.
> > > > > > > > +             vals[0] = vals[0] & 0x1F;
> > > > > > > > +             if (vals[0] > 16) {
> > > > > > > > +                     DRM_DEBUG_KMS("Failed to write aux backlight level: Invalid DP_EDP_PWNGEN_BIT_COUNT 0x%X, expected at most 16\n",
> > > > > > > > +                                             vals[0]);
> > > > > > > > +                     return;
> > > > > > > > +             }
> > > > > > > > +             level <<= (16 - vals[0]) & 0xFFFF;
> > > > > > > > +     }
> > > > > > > > +
> > > > > > > >       vals[0] = level;
> > > > > > > >
> > > > > > > >       /* Write the MSB and/or LSB */
> > > > > > > > diff --git a/drivers/gpu/drm/i915/display/intel_quirks.c b/drivers/gpu/drm/i915/display/intel_quirks.c
> > > > > > > > index 46beb155d835f..63b27d49b2864 100644
> > > > > > > > --- a/drivers/gpu/drm/i915/display/intel_quirks.c
> > > > > > > > +++ b/drivers/gpu/drm/i915/display/intel_quirks.c
> > > > > > > > @@ -53,6 +53,16 @@ static void quirk_increase_ddi_disabled_time(struct drm_i915_private *i915)
> > > > > > > >       drm_info(&i915->drm, "Applying Increase DDI Disabled quirk\n");
> > > > > > > >  }
> > > > > > > >
> > > > > > > > +/*
> > > > > > > > + * Some eDP backlight hardware uses the most-significant bits of the brightness
> > > > > > > > + * register, so brightness values must be shifted first.
> > > > > > > > + */
> > > > > > > > +static void quirk_shift_edp_backlight_brightness(struct drm_i915_private *i915)
> > > > > > > > +{
> > > > > > > > +     i915->quirks |= QUIRK_SHIFT_EDP_BACKLIGHT_BRIGHTNESS;
> > > > > > > > +     DRM_INFO("Applying shift eDP backlight brightness quirk\n");
> > > > > > > > +}
> > > > > > > > +
> > > > > > > >  struct intel_quirk {
> > > > > > > >       int device;
> > > > > > > >       int subsystem_vendor;
> > > > > > > > @@ -156,6 +166,9 @@ static struct intel_quirk intel_quirks[] = {
> > > > > > > >       /* ASRock ITX*/
> > > > > > > >       { 0x3185, 0x1849, 0x2212, quirk_increase_ddi_disabled_time },
> > > > > > > >       { 0x3184, 0x1849, 0x2212, quirk_increase_ddi_disabled_time },
> > > > > > > > +
> > > > > > > > +     /* Google Pixelbook */
> > > > > > > > +     { 0x591E, 0x8086, 0x2212, quirk_shift_edp_backlight_brightness },
> > > > > > > >  };
> > > > > > > >
> > > > > > > >  void intel_init_quirks(struct drm_i915_private *i915)
> > > > > > > > diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
> > > > > > > > index e4f7f6518945b..cc93bede4fab8 100644
> > > > > > > > --- a/drivers/gpu/drm/i915/i915_drv.h
> > > > > > > > +++ b/drivers/gpu/drm/i915/i915_drv.h
> > > > > > > > @@ -525,6 +525,7 @@ struct i915_psr {
> > > > > > > >  #define QUIRK_PIN_SWIZZLED_PAGES (1<<5)
> > > > > > > >  #define QUIRK_INCREASE_T12_DELAY (1<<6)
> > > > > > > >  #define QUIRK_INCREASE_DDI_DISABLED_TIME (1<<7)
> > > > > > > > +#define QUIRK_SHIFT_EDP_BACKLIGHT_BRIGHTNESS (1<<8)
> > > > > > > >
> > > > > > > >  struct intel_fbdev;
> > > > > > > >  struct intel_fbc_work;
> > > > > > >
> > > > > > > --
> > > > > > > Jani Nikula, Intel Open Source Graphics Center
> > > >
> > > > --
> > > > Ville Syrjälä
> > > > Intel
> > > > _______________________________________________
> > > > Intel-gfx mailing list
> > > > Intel-gfx@lists.freedesktop.org
> > > > https://lists.freedesktop.org/mailman/listinfo/intel-gfx
> > >
> > > --
> > > Ville Syrjälä
> > > Intel

Re: [Intel-gfx] [PATCH] i915: Introduce quirk for shifting eDP brightness.

[Puthikorn Voravootivat]

+Lyude
I notice that Lyude email was somehow dropped from the thread.
Lyude was the person who submitted the patch for Thinkpad and should
know the OUI of the panel.

On Tue, Sep 22, 2020 at 11:47 AM Kevin Chowski <chowski@chromium.org> wrote:
>
> Alrighty, I'll take everyone else's silence as tacit approval of
> Ville's opinions. (I didn't receive any email bounces this time, so I
> think my issue was transient.) I will start on inverting the quirk and
> making the most-significant-alignment matter for these registers by
> default.
>
> Who can help me gather a list of OUIs that we need to add to the
> quirk? I can follow up with Puthikorn about the relevant Chromebooks,
> but I don't know what other types of laptops are using this driver.
>
> Thanks for your time,
> Kevin Chowski
>
>
> On Fri, Sep 18, 2020 at 12:16 PM Puthikorn Voravootivat
> <puthik@chromium.org> wrote:
> >
> > I'll defer to Ville & Lyude.
> >
> > I dug up more on the bug report and found that both Thinkpad and
> > Galaxy Chromebook use the same Samsung OLED.
> > So my 2 vs 1 argument is actually not valid.
> >
> > On Fri, Sep 18, 2020 at 10:59 AM Kevin Chowski <chowski@chromium.org> wrote:
> > >
> > > Apologies once again, some of my emails were bouncing for some
> > > addresses yesterday. Hopefully it was a temporary condition; I'll
> > > continue trying to dig into it on my end if it happens again for this
> > > email.
> > >
> > > Since there's evidence that some models want lsb and some (well, at
> > > least one) want msb, my understanding is that we'll need a quirk one
> > > way or the other (please correct if I'm mistaken). I unfortunately
> > > don't have the ability to test anything other than the Pixelbook, so
> > > if we decide the msb is the "right" way, then I will have to rely on
> > > others to test (and find the OUI of) other models which require lsb.
> > >
> > > I am happy to make any changes requested, but I do not at all have
> > > enough background here to make the decision on whether the msb
> > > functionality deserves the quirk or if the lsb one does. How can I
> > > help you all come to an agreement here?
> > >
> > > * It seems like Ville feels strongly about the msb being the correct
> > > interpretation of the spec.
> > > * It's unclear to me on which side of the fence Lyude falls, I
> > > couldn't pick up a strong opinion in her clarifying question.
> > > * Puthikorn seems to be on the side of lsb being correct, but maybe
> > > was swayed by Ville's argument.
> > >
> > > If no one feels that Ville's argument is not strong in some way, and
> > > we go with that, I will get to work on the requested changes. I am
> > > concerned, though, about changing the default functionality without
> > > testing it widely to find the set of laptops which require the lsb
> > > quirk. I'd appreciate any advice people might have about making this
> > > change safely.
> > >
> > > Thank you for your time,
> > > Kevin
> > >
> > > On Thu, Sep 17, 2020 at 2:11 PM Ville Syrjälä
> > > <ville.syrjala@linux.intel.com> wrote:
> > > >
> > > > On Thu, Sep 17, 2020 at 09:25:35PM +0300, Ville Syrjälä wrote:
> > > > > On Thu, Sep 17, 2020 at 11:14:43AM -0700, Puthikorn Voravootivat wrote:
> > > > > > The Lyude fde7266fb2f6 change is actually based on Chromium change
> > > > > > (https://crrev.com/c/1650325) that fixes the brightness for Samsung
> > > > > > Galaxy Chromebook. So currently we have 2 examples that use LSB
> > > > > > interpretation and 1 that use MSB.
> > > > >
> > > > > "If field 4:0 of the EDP_PWMGEN_BIT_COUNT register represents a value
> > > > > of greater than 8 and the BACKLIGHT_BRIGHTNESS_BYTE_COUNT bit
> > > > > is cleared to 0, only the 8 MSB of the brightness control value can be
> > > > > controlled.
> > > > > (See Note below.)
> > > > > Assigned bits are allocated to the MSB of the enabled register
> > > > > combination."
> > > > >
> > > > > I think that's pretty clear the assigned bits are supposed to be
> > > > > msb aligned.
> > > >
> > > > I guess there's some email issues happening, but just to clarify:
> > > >
> > > > When the spec says MSB in caps here it clearly means
> > > > "most significant-bit(s)" since otherwise "8 MSB" would not make
> > > > any sense in the context of a 2 byte value.
> > > >
> > > > Granted the spec is crap here since "Table 1-1: Acronyms and
> > > > Initialism" does claim "MSB" should be byte(s) and "msb" bit(s).
> > > >
> > > > Also I can't imagine anyone would allocate the bits starting
> > > > from the lsb when the whole thing is clearly supposed to be a
> > > > 16bit big endian integer. So with >8 assigned bits you'd end
> > > > up with crazy stuff like this:
> > > >
> > > > [ 7 ... 0 ][7   ...   0]
> > > > [ 8 MSB   ][XXXX][N LSB]
> > > >
> > > > so you couldn't even treat the value as a regular big endian
> > > > thing. Instead, if you squint a bit, it now looks like a funky
> > > > little endian value. So we're deep into some mixed endian land
> > > > where nothing makes sense anymore.
> > > >
> > > > Anyways I think the code should simply do this to match the spec:
> > > > u16 value = brightness << (16 - num_assigned_bits);
> > > > val[0] = value >> 8;
> > > > val[1] = value & 0xff;
> > > >
> > > >
> > > > >
> > > > > >
> > > > > >
> > > > > > On Thu, Sep 17, 2020 at 10:55 AM Kevin Chowski <chowski@chromium.org> wrote:
> > > > > > >
> > > > > > > Apologies for being too vague. To be as precise I can be, here is the
> > > > > > > specific code delta I tested: https://crrev.com/c/2406616 . To answer
> > > > > > > your other question, the code I tested against is indeed including the
> > > > > > > fde7266fb2f6 (despite ostensibly being called 5.4 in my commit
> > > > > > > message): our current top-of-tree for our 5.4 branch includes the
> > > > > > > intel_dp_aux_calc_max_backlight logic. Further, I'll note that change
> > > > > > > is exactly the change which breaks my Pixelbook model: prior to the
> > > > > > > change, the max_brightness was hard-coded to 0xFFFF and the math
> > > > > > > worked out that it didn't matter that the hardware cared about the MSB
> > > > > > > despite the driver code caring about the LSB.
> > > > > > >
> > > > > > > To answer Ville's question: the fde7266fb2f6 change which fixes one
> > > > > > > laptop (I believe Thinkpad X1 extreme Gen 2, from some bug reports I
> > > > > > > dug up) and breaks another (Pixelbook); so unfortunately I believe we
> > > > > > > need a quirk at least for some laptop. Reading through the copy of the
> > > > > > > datasheet I have, it wasn't clear to me which was the correct
> > > > > > > interpretation. I'm cc'ing puthik@, who was leaning toward the current
> > > > > > > kernel code (caring about LSB) being the correct interpretation. I
> > > > > > > believe we have other chromebooks which do rely on LSB functionality,
> > > > > > > so unless we can find more examples of laptops wanting MSB it
> > > > > > > currently looks like Pixelbook is the outlier.
> > > > > > >
> > > > > > > On Thu, Sep 17, 2020 at 11:28 AM Jani Nikula
> > > > > > > <jani.nikula@linux.intel.com> wrote:
> > > > > > > >
> > > > > > > > On Thu, 17 Sep 2020, Kevin Chowski <chowski@chromium.org> wrote:
> > > > > > > > > We have observed that Google Pixelbook's backlight hardware is
> > > > > > > > > interpretting these backlight bits from the most-significant side of the
> > > > > > > > > 16 bit word (if DP_EDP_PWMGEN_BIT_COUNT < 16), whereas the driver code
> > > > > > > > > assumes the peripheral cares about the least-significant bits.
> > > > > > > > >
> > > > > > > > > Testing was done from within Chrome OS's build environment when the
> > > > > > > > > patch is backported to 5.4 (the version we are newly targeting for the
> > > > > > > > > Pixelbook); for the record:
> > > > > > > > >    $ emerge-eve-kernelnext sys-kernel/chromeos-kernel-5_4 && \
> > > > > > > > >       ./update_kernel.sh --remote=$IP
> > > > > > > > >
> > > > > > > > > I used `/sys/kernel/debug/dri/0/eDP-1/i915_dpcd` on my laptop to verify
> > > > > > > > > that the registers were being set according to what the actual hardware
> > > > > > > > > expects; I also observe that the backlight is noticeably brighter with
> > > > > > > > > this patch.
> > > > > > > >
> > > > > > > > It's unclear to me what kernel version this is against, and what you've
> > > > > > > > actually tested.
> > > > > > > >
> > > > > > > > Have you tried v5.7 kernel with Lyude's fde7266fb2f6 ("drm/i915: Fix eDP
> > > > > > > > DPCD aux max backlight calculations")?
> > > > > > > >
> > > > > > > > I just want to make sure you've tested with all the relevant fixes
> > > > > > > > before adding quirks.
> > > > > > > >
> > > > > > > > BR,
> > > > > > > > Jani.
> > > > > > > >
> > > > > > > > >
> > > > > > > > > Signed-off-by: Kevin Chowski <chowski@chromium.org>
> > > > > > > > > ---
> > > > > > > > >
> > > > > > > > >  .../drm/i915/display/intel_dp_aux_backlight.c | 34 +++++++++++++++++++
> > > > > > > > >  drivers/gpu/drm/i915/display/intel_quirks.c   | 13 +++++++
> > > > > > > > >  drivers/gpu/drm/i915/i915_drv.h               |  1 +
> > > > > > > > >  3 files changed, 48 insertions(+)
> > > > > > > > >
> > > > > > > > > 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 acbd7eb66cbe3..99c98f217356d 100644
> > > > > > > > > --- a/drivers/gpu/drm/i915/display/intel_dp_aux_backlight.c
> > > > > > > > > +++ b/drivers/gpu/drm/i915/display/intel_dp_aux_backlight.c
> > > > > > > > > @@ -91,6 +91,23 @@ static u32 intel_dp_aux_get_backlight(struct intel_connector *connector)
> > > > > > > > >       if (intel_dp->edp_dpcd[2] & DP_EDP_BACKLIGHT_BRIGHTNESS_BYTE_COUNT)
> > > > > > > > >               level = (read_val[0] << 8 | read_val[1]);
> > > > > > > > >
> > > > > > > > > +     if (i915->quirks & QUIRK_SHIFT_EDP_BACKLIGHT_BRIGHTNESS) {
> > > > > > > > > +             if (!drm_dp_dpcd_readb(&intel_dp->aux, DP_EDP_PWMGEN_BIT_COUNT,
> > > > > > > > > +                                             &read_val[0])) {
> > > > > > > > > +                     DRM_DEBUG_KMS("Failed to read DPCD register 0x%x\n",
> > > > > > > > > +                                     DP_EDP_PWMGEN_BIT_COUNT);
> > > > > > > > > +                     return 0;
> > > > > > > > > +             }
> > > > > > > > > +             // Only bits 4:0 are used, 7:5 are reserved.
> > > > > > > > > +             read_val[0] = read_val[0] & 0x1F;
> > > > > > > > > +             if (read_val[0] > 16) {
> > > > > > > > > +                     DRM_DEBUG_KMS("Invalid DP_EDP_PWNGEN_BIT_COUNT 0x%X, expected at most 16\n",
> > > > > > > > > +                                             read_val[0]);
> > > > > > > > > +                     return 0;
> > > > > > > > > +             }
> > > > > > > > > +             level >>= 16 - read_val[0];
> > > > > > > > > +     }
> > > > > > > > > +
> > > > > > > > >       return level;
> > > > > > > > >  }
> > > > > > > > >
> > > > > > > > > @@ -106,6 +123,23 @@ intel_dp_aux_set_backlight(const struct drm_connector_state *conn_state, u32 lev
> > > > > > > > >       struct drm_i915_private *i915 = dp_to_i915(intel_dp);
> > > > > > > > >       u8 vals[2] = { 0x0 };
> > > > > > > > >
> > > > > > > > > +     if (i915->quirks & QUIRK_SHIFT_EDP_BACKLIGHT_BRIGHTNESS) {
> > > > > > > > > +             if (!drm_dp_dpcd_readb(&intel_dp->aux, DP_EDP_PWMGEN_BIT_COUNT,
> > > > > > > > > +                                             &vals[0])) {
> > > > > > > > > +                     DRM_DEBUG_KMS("Failed to write aux backlight level: Failed to read DPCD register 0x%x\n",
> > > > > > > > > +                                       DP_EDP_PWMGEN_BIT_COUNT);
> > > > > > > > > +                     return;
> > > > > > > > > +             }
> > > > > > > > > +             // Only bits 4:0 are used, 7:5 are reserved.
> > > > > > > > > +             vals[0] = vals[0] & 0x1F;
> > > > > > > > > +             if (vals[0] > 16) {
> > > > > > > > > +                     DRM_DEBUG_KMS("Failed to write aux backlight level: Invalid DP_EDP_PWNGEN_BIT_COUNT 0x%X, expected at most 16\n",
> > > > > > > > > +                                             vals[0]);
> > > > > > > > > +                     return;
> > > > > > > > > +             }
> > > > > > > > > +             level <<= (16 - vals[0]) & 0xFFFF;
> > > > > > > > > +     }
> > > > > > > > > +
> > > > > > > > >       vals[0] = level;
> > > > > > > > >
> > > > > > > > >       /* Write the MSB and/or LSB */
> > > > > > > > > diff --git a/drivers/gpu/drm/i915/display/intel_quirks.c b/drivers/gpu/drm/i915/display/intel_quirks.c
> > > > > > > > > index 46beb155d835f..63b27d49b2864 100644
> > > > > > > > > --- a/drivers/gpu/drm/i915/display/intel_quirks.c
> > > > > > > > > +++ b/drivers/gpu/drm/i915/display/intel_quirks.c
> > > > > > > > > @@ -53,6 +53,16 @@ static void quirk_increase_ddi_disabled_time(struct drm_i915_private *i915)
> > > > > > > > >       drm_info(&i915->drm, "Applying Increase DDI Disabled quirk\n");
> > > > > > > > >  }
> > > > > > > > >
> > > > > > > > > +/*
> > > > > > > > > + * Some eDP backlight hardware uses the most-significant bits of the brightness
> > > > > > > > > + * register, so brightness values must be shifted first.
> > > > > > > > > + */
> > > > > > > > > +static void quirk_shift_edp_backlight_brightness(struct drm_i915_private *i915)
> > > > > > > > > +{
> > > > > > > > > +     i915->quirks |= QUIRK_SHIFT_EDP_BACKLIGHT_BRIGHTNESS;
> > > > > > > > > +     DRM_INFO("Applying shift eDP backlight brightness quirk\n");
> > > > > > > > > +}
> > > > > > > > > +
> > > > > > > > >  struct intel_quirk {
> > > > > > > > >       int device;
> > > > > > > > >       int subsystem_vendor;
> > > > > > > > > @@ -156,6 +166,9 @@ static struct intel_quirk intel_quirks[] = {
> > > > > > > > >       /* ASRock ITX*/
> > > > > > > > >       { 0x3185, 0x1849, 0x2212, quirk_increase_ddi_disabled_time },
> > > > > > > > >       { 0x3184, 0x1849, 0x2212, quirk_increase_ddi_disabled_time },
> > > > > > > > > +
> > > > > > > > > +     /* Google Pixelbook */
> > > > > > > > > +     { 0x591E, 0x8086, 0x2212, quirk_shift_edp_backlight_brightness },
> > > > > > > > >  };
> > > > > > > > >
> > > > > > > > >  void intel_init_quirks(struct drm_i915_private *i915)
> > > > > > > > > diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
> > > > > > > > > index e4f7f6518945b..cc93bede4fab8 100644
> > > > > > > > > --- a/drivers/gpu/drm/i915/i915_drv.h
> > > > > > > > > +++ b/drivers/gpu/drm/i915/i915_drv.h
> > > > > > > > > @@ -525,6 +525,7 @@ struct i915_psr {
> > > > > > > > >  #define QUIRK_PIN_SWIZZLED_PAGES (1<<5)
> > > > > > > > >  #define QUIRK_INCREASE_T12_DELAY (1<<6)
> > > > > > > > >  #define QUIRK_INCREASE_DDI_DISABLED_TIME (1<<7)
> > > > > > > > > +#define QUIRK_SHIFT_EDP_BACKLIGHT_BRIGHTNESS (1<<8)
> > > > > > > > >
> > > > > > > > >  struct intel_fbdev;
> > > > > > > > >  struct intel_fbc_work;
> > > > > > > >
> > > > > > > > --
> > > > > > > > Jani Nikula, Intel Open Source Graphics Center
> > > > >
> > > > > --
> > > > > Ville Syrjälä
> > > > > Intel
> > > > > _______________________________________________
> > > > > Intel-gfx mailing list
> > > > > Intel-gfx@lists.freedesktop.org
> > > > > https://lists.freedesktop.org/mailman/listinfo/intel-gfx
> > > >
> > > > --
> > > > Ville Syrjälä
> > > > Intel

Re: [Intel-gfx] [PATCH] i915: Introduce quirk for shifting eDP brightness.

[Lyude Paul]

Hi! Since I got dropped from the thread, many responses inline

On Tue, 2020-09-22 at 12:58 -0700, Puthikorn Voravootivat wrote:
> +Lyude
> I notice that Lyude email was somehow dropped from the thread.
> Lyude was the person who submitted the patch for Thinkpad and should
> know the OUI of the panel.

no need - currently because of some confusion that got caused by the Intel HDR
backlight interface being the only backlight interface that works properly on
a lot of panels (many panels will advertise both interfaces, but might only
work with the Intel one), we actually rely on a small allowlist of "approved"
panels for enabling DPCD backlight control.

…however, many of these panels are annoying and don't actually provide a
reliable enough OUID to use for quirk detection, which is why we had to add
EDID quirk detection as a temporary workaround for this. The current list of
panels lives in drm_dp_helper.c:

/*
 * Some devices have unreliable OUIDs where they don't set the device ID
 * correctly, and as a result we need to use the EDID for finding additional
 * DP quirks in such cases.
 */
static const struct edid_quirk edid_quirk_list[] = {
	/* Optional 4K AMOLED panel in the ThinkPad X1 Extreme 2nd Generation
	 * only supports DPCD backlight controls
	 */
	{ MFG(0x4c, 0x83), PROD_ID(0x41, 0x41), BIT(DP_QUIRK_FORCE_DPCD_BACKLIGHT) },
	/*
	 * Some Dell CML 2020 systems have panels support both AUX and PWM
	 * backlight control, and some only support AUX backlight control. All
	 * said panels start up in AUX mode by default, and we don't have any
	 * support for disabling HDR mode on these panels which would be
	 * required to switch to PWM backlight control mode (plus, I'm not
	 * even sure we want PWM backlight controls over DPCD backlight
	 * controls anyway...). Until we have a better way of detecting these,
	 * force DPCD backlight mode on all of them.
	 */
	{ 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(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) },
};

Also note that I think just about every panel on that list supports the Intel
HDR backlight interface, so it's -possible- that the VESA interface could be
broken on these panels. But, that would be a lot of different panels from
different vendors to all be broken in the same way.

> 
> On Tue, Sep 22, 2020 at 11:47 AM Kevin Chowski <chowski@chromium.org> wrote:
> > Alrighty, I'll take everyone else's silence as tacit approval of
> > Ville's opinions. (I didn't receive any email bounces this time, so I
> > think my issue was transient.) I will start on inverting the quirk and
> > making the most-significant-alignment matter for these registers by
> > default.
> > 
> > Who can help me gather a list of OUIs that we need to add to the
> > quirk? I can follow up with Puthikorn about the relevant Chromebooks,
> > but I don't know what other types of laptops are using this driver.
> > 
> > Thanks for your time,
> > Kevin Chowski
> > 
> > 
> > On Fri, Sep 18, 2020 at 12:16 PM Puthikorn Voravootivat
> > <puthik@chromium.org> wrote:
> > > I'll defer to Ville & Lyude.
> > > 
> > > I dug up more on the bug report and found that both Thinkpad and
> > > Galaxy Chromebook use the same Samsung OLED.
> > > So my 2 vs 1 argument is actually not valid.
> > > 
> > > On Fri, Sep 18, 2020 at 10:59 AM Kevin Chowski <chowski@chromium.org>
> > > wrote:
> > > > Apologies once again, some of my emails were bouncing for some
> > > > addresses yesterday. Hopefully it was a temporary condition; I'll
> > > > continue trying to dig into it on my end if it happens again for this
> > > > email.
> > > > 
> > > > Since there's evidence that some models want lsb and some (well, at
> > > > least one) want msb, my understanding is that we'll need a quirk one
> > > > way or the other (please correct if I'm mistaken). I unfortunately
> > > > don't have the ability to test anything other than the Pixelbook, so
> > > > if we decide the msb is the "right" way, then I will have to rely on
> > > > others to test (and find the OUI of) other models which require lsb.
> > > > 
> > > > I am happy to make any changes requested, but I do not at all have
> > > > enough background here to make the decision on whether the msb
> > > > functionality deserves the quirk or if the lsb one does. How can I
> > > > help you all come to an agreement here?
> > > > 
> > > > * It seems like Ville feels strongly about the msb being the correct
> > > > interpretation of the spec.
> > > > * It's unclear to me on which side of the fence Lyude falls, I
> > > > couldn't pick up a strong opinion in her clarifying question.
> > > > * Puthikorn seems to be on the side of lsb being correct, but maybe
> > > > was swayed by Ville's argument.

Honestly I'm not hard to convince :P, if it looks like we got the bit shift
wrong for the majority of devices and everyone else agrees then I'm fine with
assuming that's the case. I'm just quite surprised, seeing as we've tested
many different panels from a few vendors and haven't run into any issues with
this before.

Honestly - if there's this much uncertainty about it, maybe we should just ask
VESA directly what the correct interpretation of this is? Note I'm not on the
VESA board (I get access to DP/eDP specs through X.org) so unless the contacts
I've got from VESA would work (Bill Lempesis bill at vesa dot org) for that it
might be a better idea for someone from Google or Intel to ask.

> > > > 
> > > > If no one feels that Ville's argument is not strong in some way, and
> > > > we go with that, I will get to work on the requested changes. I am
> > > > concerned, though, about changing the default functionality without
> > > > testing it widely to find the set of laptops which require the lsb
> > > > quirk. I'd appreciate any advice people might have about making this
> > > > change safely.

Usually, I just try to stick with what the majority of machines need to do. I
still think it'd be a good idea for us to verify this with VESA if there's
that much confusion though

> > > > 
> > > > Thank you for your time,
> > > > Kevin
> > > > 
> > > > On Thu, Sep 17, 2020 at 2:11 PM Ville Syrjälä
> > > > <ville.syrjala@linux.intel.com> wrote:
> > > > > On Thu, Sep 17, 2020 at 09:25:35PM +0300, Ville Syrjälä wrote:
> > > > > > On Thu, Sep 17, 2020 at 11:14:43AM -0700, Puthikorn Voravootivat
> > > > > > wrote:
> > > > > > > The Lyude fde7266fb2f6 change is actually based on Chromium
> > > > > > > change
> > > > > > > (https://crrev.com/c/1650325) that fixes the brightness for
> > > > > > > Samsung
> > > > > > > Galaxy Chromebook. So currently we have 2 examples that use LSB
> > > > > > > interpretation and 1 that use MSB.
> > > > > > 
> > > > > > "If field 4:0 of the EDP_PWMGEN_BIT_COUNT register represents a
> > > > > > value
> > > > > > of greater than 8 and the BACKLIGHT_BRIGHTNESS_BYTE_COUNT bit
> > > > > > is cleared to 0, only the 8 MSB of the brightness control value
> > > > > > can be
> > > > > > controlled.
> > > > > > (See Note below.)
> > > > > > Assigned bits are allocated to the MSB of the enabled register
> > > > > > combination."
> > > > > > 
> > > > > > I think that's pretty clear the assigned bits are supposed to be
> > > > > > msb aligned.
> > > > > 
> > > > > I guess there's some email issues happening, but just to clarify:
> > > > > 
> > > > > When the spec says MSB in caps here it clearly means
> > > > > "most significant-bit(s)" since otherwise "8 MSB" would not make
> > > > > any sense in the context of a 2 byte value.
> > > > > 
> > > > > Granted the spec is crap here since "Table 1-1: Acronyms and
> > > > > Initialism" does claim "MSB" should be byte(s) and "msb" bit(s).
> > > > > 
> > > > > Also I can't imagine anyone would allocate the bits starting
> > > > > from the lsb when the whole thing is clearly supposed to be a
> > > > > 16bit big endian integer. So with >8 assigned bits you'd end
> > > > > up with crazy stuff like this:
> > > > > 
> > > > > [ 7 ... 0 ][7   ...   0]
> > > > > [ 8 MSB   ][XXXX][N LSB]
> > > > > 
> > > > > so you couldn't even treat the value as a regular big endian
> > > > > thing. Instead, if you squint a bit, it now looks like a funky
> > > > > little endian value. So we're deep into some mixed endian land
> > > > > where nothing makes sense anymore.
> > > > > 
> > > > > Anyways I think the code should simply do this to match the spec:
> > > > > u16 value = brightness << (16 - num_assigned_bits);
> > > > > val[0] = value >> 8;
> > > > > val[1] = value & 0xff;
> > > > > 
> > > > > 
> > > > > > > 
> > > > > > > On Thu, Sep 17, 2020 at 10:55 AM Kevin Chowski <
> > > > > > > chowski@chromium.org> wrote:
> > > > > > > > Apologies for being too vague. To be as precise I can be, here
> > > > > > > > is the
> > > > > > > > specific code delta I tested: https://crrev.com/c/2406616 . To
> > > > > > > > answer
> > > > > > > > your other question, the code I tested against is indeed
> > > > > > > > including the
> > > > > > > > fde7266fb2f6 (despite ostensibly being called 5.4 in my commit
> > > > > > > > message): our current top-of-tree for our 5.4 branch includes
> > > > > > > > the
> > > > > > > > intel_dp_aux_calc_max_backlight logic. Further, I'll note that
> > > > > > > > change
> > > > > > > > is exactly the change which breaks my Pixelbook model: prior
> > > > > > > > to the
> > > > > > > > change, the max_brightness was hard-coded to 0xFFFF and the
> > > > > > > > math
> > > > > > > > worked out that it didn't matter that the hardware cared about
> > > > > > > > the MSB
> > > > > > > > despite the driver code caring about the LSB.
> > > > > > > > 
> > > > > > > > To answer Ville's question: the fde7266fb2f6 change which
> > > > > > > > fixes one
> > > > > > > > laptop (I believe Thinkpad X1 extreme Gen 2, from some bug
> > > > > > > > reports I
> > > > > > > > dug up) and breaks another (Pixelbook); so unfortunately I
> > > > > > > > believe we
> > > > > > > > need a quirk at least for some laptop. Reading through the
> > > > > > > > copy of the
> > > > > > > > datasheet I have, it wasn't clear to me which was the correct
> > > > > > > > interpretation. I'm cc'ing puthik@, who was leaning toward the
> > > > > > > > current
> > > > > > > > kernel code (caring about LSB) being the correct
> > > > > > > > interpretation. I
> > > > > > > > believe we have other chromebooks which do rely on LSB
> > > > > > > > functionality,
> > > > > > > > so unless we can find more examples of laptops wanting MSB it
> > > > > > > > currently looks like Pixelbook is the outlier.
> > > > > > > > 
> > > > > > > > On Thu, Sep 17, 2020 at 11:28 AM Jani Nikula
> > > > > > > > <jani.nikula@linux.intel.com> wrote:
> > > > > > > > > On Thu, 17 Sep 2020, Kevin Chowski <chowski@chromium.org>
> > > > > > > > > wrote:
> > > > > > > > > > We have observed that Google Pixelbook's backlight
> > > > > > > > > > hardware is
> > > > > > > > > > interpretting these backlight bits from the most-
> > > > > > > > > > significant side of the
> > > > > > > > > > 16 bit word (if DP_EDP_PWMGEN_BIT_COUNT < 16), whereas the
> > > > > > > > > > driver code
> > > > > > > > > > assumes the peripheral cares about the least-significant
> > > > > > > > > > bits.
> > > > > > > > > > 
> > > > > > > > > > Testing was done from within Chrome OS's build environment
> > > > > > > > > > when the
> > > > > > > > > > patch is backported to 5.4 (the version we are newly
> > > > > > > > > > targeting for the
> > > > > > > > > > Pixelbook); for the record:
> > > > > > > > > >    $ emerge-eve-kernelnext sys-kernel/chromeos-kernel-5_4
> > > > > > > > > > && \
> > > > > > > > > >       ./update_kernel.sh --remote=$IP
> > > > > > > > > > 
> > > > > > > > > > I used `/sys/kernel/debug/dri/0/eDP-1/i915_dpcd` on my
> > > > > > > > > > laptop to verify
> > > > > > > > > > that the registers were being set according to what the
> > > > > > > > > > actual hardware
> > > > > > > > > > expects; I also observe that the backlight is noticeably
> > > > > > > > > > brighter with
> > > > > > > > > > this patch.
> > > > > > > > > 
> > > > > > > > > It's unclear to me what kernel version this is against, and
> > > > > > > > > what you've
> > > > > > > > > actually tested.
> > > > > > > > > 
> > > > > > > > > Have you tried v5.7 kernel with Lyude's fde7266fb2f6
> > > > > > > > > ("drm/i915: Fix eDP
> > > > > > > > > DPCD aux max backlight calculations")?
> > > > > > > > > 
> > > > > > > > > I just want to make sure you've tested with all the relevant
> > > > > > > > > fixes
> > > > > > > > > before adding quirks.
> > > > > > > > > 
> > > > > > > > > BR,
> > > > > > > > > Jani.
> > > > > > > > > 
> > > > > > > > > > Signed-off-by: Kevin Chowski <chowski@chromium.org>
> > > > > > > > > > ---
> > > > > > > > > > 
> > > > > > > > > >  .../drm/i915/display/intel_dp_aux_backlight.c | 34
> > > > > > > > > > +++++++++++++++++++
> > > > > > > > > >  drivers/gpu/drm/i915/display/intel_quirks.c   | 13
> > > > > > > > > > +++++++
> > > > > > > > > >  drivers/gpu/drm/i915/i915_drv.h               |  1 +
> > > > > > > > > >  3 files changed, 48 insertions(+)
> > > > > > > > > > 
> > > > > > > > > > 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 acbd7eb66cbe3..99c98f217356d 100644
> > > > > > > > > > ---
> > > > > > > > > > a/drivers/gpu/drm/i915/display/intel_dp_aux_backlight.c
> > > > > > > > > > +++
> > > > > > > > > > b/drivers/gpu/drm/i915/display/intel_dp_aux_backlight.c
> > > > > > > > > > @@ -91,6 +91,23 @@ static u32
> > > > > > > > > > intel_dp_aux_get_backlight(struct intel_connector
> > > > > > > > > > *connector)
> > > > > > > > > >       if (intel_dp->edp_dpcd[2] &
> > > > > > > > > > DP_EDP_BACKLIGHT_BRIGHTNESS_BYTE_COUNT)
> > > > > > > > > >               level = (read_val[0] << 8 | read_val[1]);
> > > > > > > > > > 
> > > > > > > > > > +     if (i915->quirks &
> > > > > > > > > > QUIRK_SHIFT_EDP_BACKLIGHT_BRIGHTNESS) {
> > > > > > > > > > +             if (!drm_dp_dpcd_readb(&intel_dp->aux,
> > > > > > > > > > DP_EDP_PWMGEN_BIT_COUNT,
> > > > > > > > > > +                                             &read_val[0]
> > > > > > > > > > )) {
> > > > > > > > > > +                     DRM_DEBUG_KMS("Failed to read DPCD
> > > > > > > > > > register 0x%x\n",
> > > > > > > > > > +                                     DP_EDP_PWMGEN_BIT_CO
> > > > > > > > > > UNT);
> > > > > > > > > > +                     return 0;
> > > > > > > > > > +             }
> > > > > > > > > > +             // Only bits 4:0 are used, 7:5 are reserved.
> > > > > > > > > > +             read_val[0] = read_val[0] & 0x1F;
> > > > > > > > > > +             if (read_val[0] > 16) {
> > > > > > > > > > +                     DRM_DEBUG_KMS("Invalid
> > > > > > > > > > DP_EDP_PWNGEN_BIT_COUNT 0x%X, expected at most 16\n",
> > > > > > > > > > +                                             read_val[0])
> > > > > > > > > > ;
> > > > > > > > > > +                     return 0;
> > > > > > > > > > +             }
> > > > > > > > > > +             level >>= 16 - read_val[0];
> > > > > > > > > > +     }
> > > > > > > > > > +
> > > > > > > > > >       return level;
> > > > > > > > > >  }
> > > > > > > > > > 
> > > > > > > > > > @@ -106,6 +123,23 @@ intel_dp_aux_set_backlight(const
> > > > > > > > > > struct drm_connector_state *conn_state, u32 lev
> > > > > > > > > >       struct drm_i915_private *i915 =
> > > > > > > > > > dp_to_i915(intel_dp);
> > > > > > > > > >       u8 vals[2] = { 0x0 };
> > > > > > > > > > 
> > > > > > > > > > +     if (i915->quirks &
> > > > > > > > > > QUIRK_SHIFT_EDP_BACKLIGHT_BRIGHTNESS) {
> > > > > > > > > > +             if (!drm_dp_dpcd_readb(&intel_dp->aux,
> > > > > > > > > > DP_EDP_PWMGEN_BIT_COUNT,
> > > > > > > > > > +                                             &vals[0])) {
> > > > > > > > > > +                     DRM_DEBUG_KMS("Failed to write aux
> > > > > > > > > > backlight level: Failed to read DPCD register 0x%x\n",
> > > > > > > > > > +                                       DP_EDP_PWMGEN_BIT_
> > > > > > > > > > COUNT);
> > > > > > > > > > +                     return;
> > > > > > > > > > +             }
> > > > > > > > > > +             // Only bits 4:0 are used, 7:5 are reserved.
> > > > > > > > > > +             vals[0] = vals[0] & 0x1F;
> > > > > > > > > > +             if (vals[0] > 16) {
> > > > > > > > > > +                     DRM_DEBUG_KMS("Failed to write aux
> > > > > > > > > > backlight level: Invalid DP_EDP_PWNGEN_BIT_COUNT 0x%X,
> > > > > > > > > > expected at most 16\n",
> > > > > > > > > > +                                             vals[0]);
> > > > > > > > > > +                     return;
> > > > > > > > > > +             }
> > > > > > > > > > +             level <<= (16 - vals[0]) & 0xFFFF;
> > > > > > > > > > +     }
> > > > > > > > > > +
> > > > > > > > > >       vals[0] = level;
> > > > > > > > > > 
> > > > > > > > > >       /* Write the MSB and/or LSB */
> > > > > > > > > > diff --git a/drivers/gpu/drm/i915/display/intel_quirks.c
> > > > > > > > > > b/drivers/gpu/drm/i915/display/intel_quirks.c
> > > > > > > > > > index 46beb155d835f..63b27d49b2864 100644
> > > > > > > > > > --- a/drivers/gpu/drm/i915/display/intel_quirks.c
> > > > > > > > > > +++ b/drivers/gpu/drm/i915/display/intel_quirks.c
> > > > > > > > > > @@ -53,6 +53,16 @@ static void
> > > > > > > > > > quirk_increase_ddi_disabled_time(struct drm_i915_private
> > > > > > > > > > *i915)
> > > > > > > > > >       drm_info(&i915->drm, "Applying Increase DDI Disabled
> > > > > > > > > > quirk\n");
> > > > > > > > > >  }
> > > > > > > > > > 
> > > > > > > > > > +/*
> > > > > > > > > > + * Some eDP backlight hardware uses the most-significant
> > > > > > > > > > bits of the brightness
> > > > > > > > > > + * register, so brightness values must be shifted first.
> > > > > > > > > > + */
> > > > > > > > > > +static void quirk_shift_edp_backlight_brightness(struct
> > > > > > > > > > drm_i915_private *i915)
> > > > > > > > > > +{
> > > > > > > > > > +     i915->quirks |=
> > > > > > > > > > QUIRK_SHIFT_EDP_BACKLIGHT_BRIGHTNESS;
> > > > > > > > > > +     DRM_INFO("Applying shift eDP backlight brightness
> > > > > > > > > > quirk\n");
> > > > > > > > > > +}
> > > > > > > > > > +
> > > > > > > > > >  struct intel_quirk {
> > > > > > > > > >       int device;
> > > > > > > > > >       int subsystem_vendor;
> > > > > > > > > > @@ -156,6 +166,9 @@ static struct intel_quirk
> > > > > > > > > > intel_quirks[] = {
> > > > > > > > > >       /* ASRock ITX*/
> > > > > > > > > >       { 0x3185, 0x1849, 0x2212,
> > > > > > > > > > quirk_increase_ddi_disabled_time },
> > > > > > > > > >       { 0x3184, 0x1849, 0x2212,
> > > > > > > > > > quirk_increase_ddi_disabled_time },
> > > > > > > > > > +
> > > > > > > > > > +     /* Google Pixelbook */
> > > > > > > > > > +     { 0x591E, 0x8086, 0x2212,
> > > > > > > > > > quirk_shift_edp_backlight_brightness },
> > > > > > > > > >  };
> > > > > > > > > > 
> > > > > > > > > >  void intel_init_quirks(struct drm_i915_private *i915)
> > > > > > > > > > diff --git a/drivers/gpu/drm/i915/i915_drv.h
> > > > > > > > > > b/drivers/gpu/drm/i915/i915_drv.h
> > > > > > > > > > index e4f7f6518945b..cc93bede4fab8 100644
> > > > > > > > > > --- a/drivers/gpu/drm/i915/i915_drv.h
> > > > > > > > > > +++ b/drivers/gpu/drm/i915/i915_drv.h
> > > > > > > > > > @@ -525,6 +525,7 @@ struct i915_psr {
> > > > > > > > > >  #define QUIRK_PIN_SWIZZLED_PAGES (1<<5)
> > > > > > > > > >  #define QUIRK_INCREASE_T12_DELAY (1<<6)
> > > > > > > > > >  #define QUIRK_INCREASE_DDI_DISABLED_TIME (1<<7)
> > > > > > > > > > +#define QUIRK_SHIFT_EDP_BACKLIGHT_BRIGHTNESS (1<<8)
> > > > > > > > > > 
> > > > > > > > > >  struct intel_fbdev;
> > > > > > > > > >  struct intel_fbc_work;
> > > > > > > > > 
> > > > > > > > > --
> > > > > > > > > Jani Nikula, Intel Open Source Graphics Center
> > > > > > 
> > > > > > --
> > > > > > Ville Syrjälä
> > > > > > Intel
> > > > > > _______________________________________________
> > > > > > Intel-gfx mailing list
> > > > > > Intel-gfx@lists.freedesktop.org
> > > > > > https://lists.freedesktop.org/mailman/listinfo/intel-gfx
> > > > > 
> > > > > --
> > > > > Ville Syrjälä
> > > > > Intel
-- 
Cheers,
	Lyude Paul (she/her)
	Software Engineer at Red Hat

Re: [Intel-gfx] [PATCH] i915: Introduce quirk for shifting eDP brightness.

[Kevin Chowski]

cc back a few others who were unintentionally dropped from the thread earlier.

Someone (at Google) helped me dig into this a little more and they
found a document titled "eDP Backlight Brightness bit alignment" sent
out for review in January 2017. I registered for a new account (google
is a member) and have access to the document; here is the URL for
those who also have access:
https://groups.vesa.org/wg/AllMem/document/7786. For what it's worth,
it seems like Lyude's contact Bill Lempesis uploaded this
change-request document, so I think we can reach out to him if we have
further questions. It's actually unclear to me what the status of this
change request is, and whether it's been officially accepted. But I
think it can be seen as some official advice on how we can move
forward here.

Basically, this is a change request to the spec which acknowledges
that, despite the original spec implying that the
most-significant-bits were relevant here, many implementations used
the least-significant-bits. In defense of most-significant it laid out
some similar arguments to what Ville was saying. But it ends up
saying:

> Unfortunately, the most common interpretation that we have
> encountered is case 1 in the example above. TCON vendors
> tend to align the valid bits to the LSBs, not the MSBs.

Instead of changing the default defined functionality (as some earlier
version of this doc apparently suggested), this doc prefers to
allocate two extra bits in EDP_GENERAL_CAPABILITY_2 so that future
backlight devices can specify to the Source how to program them:

00: the current functionality, i,e. no defined interpretation
01: aligned to most-significant bits
10: aligned to least-significant bits
11: reserved

It also says "[Sources] should only need panel-specific workarounds
for the currently available panels."

So I believe this document is an acknowledgement of many
implementations having their alignment to the least-significant bits,
and (to my eyes) clearly validates that the spec "should" be the
opposite. If we believe the doc's claim that "the most common
interpretation" is least-significant, it seems to me that it would
require more quirks if we made most-significant the default
implementation.

Ville mentioned at some point earlier that we should try to match the
spec, whereas Lyude mentioned we should prefer to do what the majority
of machines do. What do you both think of this new development?

I will also look into whether my specific device supports this
extension, and in that case I'll volunteer to implement this new
functionality in the driver.

Thanks for your time,
Kevin

On Tue, Sep 22, 2020 at 3:30 PM Lyude Paul <lyude@redhat.com> wrote:
>
> Hi! Since I got dropped from the thread, many responses inline
>
> On Tue, 2020-09-22 at 12:58 -0700, Puthikorn Voravootivat wrote:
> > +Lyude
> > I notice that Lyude email was somehow dropped from the thread.
> > Lyude was the person who submitted the patch for Thinkpad and should
> > know the OUI of the panel.
>
> no need - currently because of some confusion that got caused by the Intel HDR
> backlight interface being the only backlight interface that works properly on
> a lot of panels (many panels will advertise both interfaces, but might only
> work with the Intel one), we actually rely on a small allowlist of "approved"
> panels for enabling DPCD backlight control.
>
> …however, many of these panels are annoying and don't actually provide a
> reliable enough OUID to use for quirk detection, which is why we had to add
> EDID quirk detection as a temporary workaround for this. The current list of
> panels lives in drm_dp_helper.c:
>
> /*
>  * Some devices have unreliable OUIDs where they don't set the device ID
>  * correctly, and as a result we need to use the EDID for finding additional
>  * DP quirks in such cases.
>  */
> static const struct edid_quirk edid_quirk_list[] = {
>         /* Optional 4K AMOLED panel in the ThinkPad X1 Extreme 2nd Generation
>          * only supports DPCD backlight controls
>          */
>         { MFG(0x4c, 0x83), PROD_ID(0x41, 0x41), BIT(DP_QUIRK_FORCE_DPCD_BACKLIGHT) },
>         /*
>          * Some Dell CML 2020 systems have panels support both AUX and PWM
>          * backlight control, and some only support AUX backlight control. All
>          * said panels start up in AUX mode by default, and we don't have any
>          * support for disabling HDR mode on these panels which would be
>          * required to switch to PWM backlight control mode (plus, I'm not
>          * even sure we want PWM backlight controls over DPCD backlight
>          * controls anyway...). Until we have a better way of detecting these,
>          * force DPCD backlight mode on all of them.
>          */
>         { 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(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) },
> };
>
> Also note that I think just about every panel on that list supports the Intel
> HDR backlight interface, so it's -possible- that the VESA interface could be
> broken on these panels. But, that would be a lot of different panels from
> different vendors to all be broken in the same way.
>
> >
> > On Tue, Sep 22, 2020 at 11:47 AM Kevin Chowski <chowski@chromium.org> wrote:
> > > Alrighty, I'll take everyone else's silence as tacit approval of
> > > Ville's opinions. (I didn't receive any email bounces this time, so I
> > > think my issue was transient.) I will start on inverting the quirk and
> > > making the most-significant-alignment matter for these registers by
> > > default.
> > >
> > > Who can help me gather a list of OUIs that we need to add to the
> > > quirk? I can follow up with Puthikorn about the relevant Chromebooks,
> > > but I don't know what other types of laptops are using this driver.
> > >
> > > Thanks for your time,
> > > Kevin Chowski
> > >
> > >
> > > On Fri, Sep 18, 2020 at 12:16 PM Puthikorn Voravootivat
> > > <puthik@chromium.org> wrote:
> > > > I'll defer to Ville & Lyude.
> > > >
> > > > I dug up more on the bug report and found that both Thinkpad and
> > > > Galaxy Chromebook use the same Samsung OLED.
> > > > So my 2 vs 1 argument is actually not valid.
> > > >
> > > > On Fri, Sep 18, 2020 at 10:59 AM Kevin Chowski <chowski@chromium.org>
> > > > wrote:
> > > > > Apologies once again, some of my emails were bouncing for some
> > > > > addresses yesterday. Hopefully it was a temporary condition; I'll
> > > > > continue trying to dig into it on my end if it happens again for this
> > > > > email.
> > > > >
> > > > > Since there's evidence that some models want lsb and some (well, at
> > > > > least one) want msb, my understanding is that we'll need a quirk one
> > > > > way or the other (please correct if I'm mistaken). I unfortunately
> > > > > don't have the ability to test anything other than the Pixelbook, so
> > > > > if we decide the msb is the "right" way, then I will have to rely on
> > > > > others to test (and find the OUI of) other models which require lsb.
> > > > >
> > > > > I am happy to make any changes requested, but I do not at all have
> > > > > enough background here to make the decision on whether the msb
> > > > > functionality deserves the quirk or if the lsb one does. How can I
> > > > > help you all come to an agreement here?
> > > > >
> > > > > * It seems like Ville feels strongly about the msb being the correct
> > > > > interpretation of the spec.
> > > > > * It's unclear to me on which side of the fence Lyude falls, I
> > > > > couldn't pick up a strong opinion in her clarifying question.
> > > > > * Puthikorn seems to be on the side of lsb being correct, but maybe
> > > > > was swayed by Ville's argument.
>
> Honestly I'm not hard to convince :P, if it looks like we got the bit shift
> wrong for the majority of devices and everyone else agrees then I'm fine with
> assuming that's the case. I'm just quite surprised, seeing as we've tested
> many different panels from a few vendors and haven't run into any issues with
> this before.
>
> Honestly - if there's this much uncertainty about it, maybe we should just ask
> VESA directly what the correct interpretation of this is? Note I'm not on the
> VESA board (I get access to DP/eDP specs through X.org) so unless the contacts
> I've got from VESA would work (Bill Lempesis bill at vesa dot org) for that it
> might be a better idea for someone from Google or Intel to ask.
>
> > > > >
> > > > > If no one feels that Ville's argument is not strong in some way, and
> > > > > we go with that, I will get to work on the requested changes. I am
> > > > > concerned, though, about changing the default functionality without
> > > > > testing it widely to find the set of laptops which require the lsb
> > > > > quirk. I'd appreciate any advice people might have about making this
> > > > > change safely.
>
> Usually, I just try to stick with what the majority of machines need to do. I
> still think it'd be a good idea for us to verify this with VESA if there's
> that much confusion though
>
> > > > >
> > > > > Thank you for your time,
> > > > > Kevin
> > > > >
> > > > > On Thu, Sep 17, 2020 at 2:11 PM Ville Syrjälä
> > > > > <ville.syrjala@linux.intel.com> wrote:
> > > > > > On Thu, Sep 17, 2020 at 09:25:35PM +0300, Ville Syrjälä wrote:
> > > > > > > On Thu, Sep 17, 2020 at 11:14:43AM -0700, Puthikorn Voravootivat
> > > > > > > wrote:
> > > > > > > > The Lyude fde7266fb2f6 change is actually based on Chromium
> > > > > > > > change
> > > > > > > > (https://crrev.com/c/1650325) that fixes the brightness for
> > > > > > > > Samsung
> > > > > > > > Galaxy Chromebook. So currently we have 2 examples that use LSB
> > > > > > > > interpretation and 1 that use MSB.
> > > > > > >
> > > > > > > "If field 4:0 of the EDP_PWMGEN_BIT_COUNT register represents a
> > > > > > > value
> > > > > > > of greater than 8 and the BACKLIGHT_BRIGHTNESS_BYTE_COUNT bit
> > > > > > > is cleared to 0, only the 8 MSB of the brightness control value
> > > > > > > can be
> > > > > > > controlled.
> > > > > > > (See Note below.)
> > > > > > > Assigned bits are allocated to the MSB of the enabled register
> > > > > > > combination."
> > > > > > >
> > > > > > > I think that's pretty clear the assigned bits are supposed to be
> > > > > > > msb aligned.
> > > > > >
> > > > > > I guess there's some email issues happening, but just to clarify:
> > > > > >
> > > > > > When the spec says MSB in caps here it clearly means
> > > > > > "most significant-bit(s)" since otherwise "8 MSB" would not make
> > > > > > any sense in the context of a 2 byte value.
> > > > > >
> > > > > > Granted the spec is crap here since "Table 1-1: Acronyms and
> > > > > > Initialism" does claim "MSB" should be byte(s) and "msb" bit(s).
> > > > > >
> > > > > > Also I can't imagine anyone would allocate the bits starting
> > > > > > from the lsb when the whole thing is clearly supposed to be a
> > > > > > 16bit big endian integer. So with >8 assigned bits you'd end
> > > > > > up with crazy stuff like this:
> > > > > >
> > > > > > [ 7 ... 0 ][7   ...   0]
> > > > > > [ 8 MSB   ][XXXX][N LSB]
> > > > > >
> > > > > > so you couldn't even treat the value as a regular big endian
> > > > > > thing. Instead, if you squint a bit, it now looks like a funky
> > > > > > little endian value. So we're deep into some mixed endian land
> > > > > > where nothing makes sense anymore.
> > > > > >
> > > > > > Anyways I think the code should simply do this to match the spec:
> > > > > > u16 value = brightness << (16 - num_assigned_bits);
> > > > > > val[0] = value >> 8;
> > > > > > val[1] = value & 0xff;
> > > > > >
> > > > > >
> > > > > > > >
> > > > > > > > On Thu, Sep 17, 2020 at 10:55 AM Kevin Chowski <
> > > > > > > > chowski@chromium.org> wrote:
> > > > > > > > > Apologies for being too vague. To be as precise I can be, here
> > > > > > > > > is the
> > > > > > > > > specific code delta I tested: https://crrev.com/c/2406616 . To
> > > > > > > > > answer
> > > > > > > > > your other question, the code I tested against is indeed
> > > > > > > > > including the
> > > > > > > > > fde7266fb2f6 (despite ostensibly being called 5.4 in my commit
> > > > > > > > > message): our current top-of-tree for our 5.4 branch includes
> > > > > > > > > the
> > > > > > > > > intel_dp_aux_calc_max_backlight logic. Further, I'll note that
> > > > > > > > > change
> > > > > > > > > is exactly the change which breaks my Pixelbook model: prior
> > > > > > > > > to the
> > > > > > > > > change, the max_brightness was hard-coded to 0xFFFF and the
> > > > > > > > > math
> > > > > > > > > worked out that it didn't matter that the hardware cared about
> > > > > > > > > the MSB
> > > > > > > > > despite the driver code caring about the LSB.
> > > > > > > > >
> > > > > > > > > To answer Ville's question: the fde7266fb2f6 change which
> > > > > > > > > fixes one
> > > > > > > > > laptop (I believe Thinkpad X1 extreme Gen 2, from some bug
> > > > > > > > > reports I
> > > > > > > > > dug up) and breaks another (Pixelbook); so unfortunately I
> > > > > > > > > believe we
> > > > > > > > > need a quirk at least for some laptop. Reading through the
> > > > > > > > > copy of the
> > > > > > > > > datasheet I have, it wasn't clear to me which was the correct
> > > > > > > > > interpretation. I'm cc'ing puthik@, who was leaning toward the
> > > > > > > > > current
> > > > > > > > > kernel code (caring about LSB) being the correct
> > > > > > > > > interpretation. I
> > > > > > > > > believe we have other chromebooks which do rely on LSB
> > > > > > > > > functionality,
> > > > > > > > > so unless we can find more examples of laptops wanting MSB it
> > > > > > > > > currently looks like Pixelbook is the outlier.
> > > > > > > > >
> > > > > > > > > On Thu, Sep 17, 2020 at 11:28 AM Jani Nikula
> > > > > > > > > <jani.nikula@linux.intel.com> wrote:
> > > > > > > > > > On Thu, 17 Sep 2020, Kevin Chowski <chowski@chromium.org>
> > > > > > > > > > wrote:
> > > > > > > > > > > We have observed that Google Pixelbook's backlight
> > > > > > > > > > > hardware is
> > > > > > > > > > > interpretting these backlight bits from the most-
> > > > > > > > > > > significant side of the
> > > > > > > > > > > 16 bit word (if DP_EDP_PWMGEN_BIT_COUNT < 16), whereas the
> > > > > > > > > > > driver code
> > > > > > > > > > > assumes the peripheral cares about the least-significant
> > > > > > > > > > > bits.
> > > > > > > > > > >
> > > > > > > > > > > Testing was done from within Chrome OS's build environment
> > > > > > > > > > > when the
> > > > > > > > > > > patch is backported to 5.4 (the version we are newly
> > > > > > > > > > > targeting for the
> > > > > > > > > > > Pixelbook); for the record:
> > > > > > > > > > >    $ emerge-eve-kernelnext sys-kernel/chromeos-kernel-5_4
> > > > > > > > > > > && \
> > > > > > > > > > >       ./update_kernel.sh --remote=$IP
> > > > > > > > > > >
> > > > > > > > > > > I used `/sys/kernel/debug/dri/0/eDP-1/i915_dpcd` on my
> > > > > > > > > > > laptop to verify
> > > > > > > > > > > that the registers were being set according to what the
> > > > > > > > > > > actual hardware
> > > > > > > > > > > expects; I also observe that the backlight is noticeably
> > > > > > > > > > > brighter with
> > > > > > > > > > > this patch.
> > > > > > > > > >
> > > > > > > > > > It's unclear to me what kernel version this is against, and
> > > > > > > > > > what you've
> > > > > > > > > > actually tested.
> > > > > > > > > >
> > > > > > > > > > Have you tried v5.7 kernel with Lyude's fde7266fb2f6
> > > > > > > > > > ("drm/i915: Fix eDP
> > > > > > > > > > DPCD aux max backlight calculations")?
> > > > > > > > > >
> > > > > > > > > > I just want to make sure you've tested with all the relevant
> > > > > > > > > > fixes
> > > > > > > > > > before adding quirks.
> > > > > > > > > >
> > > > > > > > > > BR,
> > > > > > > > > > Jani.
> > > > > > > > > >
> > > > > > > > > > > Signed-off-by: Kevin Chowski <chowski@chromium.org>
> > > > > > > > > > > ---
> > > > > > > > > > >
> > > > > > > > > > >  .../drm/i915/display/intel_dp_aux_backlight.c | 34
> > > > > > > > > > > +++++++++++++++++++
> > > > > > > > > > >  drivers/gpu/drm/i915/display/intel_quirks.c   | 13
> > > > > > > > > > > +++++++
> > > > > > > > > > >  drivers/gpu/drm/i915/i915_drv.h               |  1 +
> > > > > > > > > > >  3 files changed, 48 insertions(+)
> > > > > > > > > > >
> > > > > > > > > > > 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 acbd7eb66cbe3..99c98f217356d 100644
> > > > > > > > > > > ---
> > > > > > > > > > > a/drivers/gpu/drm/i915/display/intel_dp_aux_backlight.c
> > > > > > > > > > > +++
> > > > > > > > > > > b/drivers/gpu/drm/i915/display/intel_dp_aux_backlight.c
> > > > > > > > > > > @@ -91,6 +91,23 @@ static u32
> > > > > > > > > > > intel_dp_aux_get_backlight(struct intel_connector
> > > > > > > > > > > *connector)
> > > > > > > > > > >       if (intel_dp->edp_dpcd[2] &
> > > > > > > > > > > DP_EDP_BACKLIGHT_BRIGHTNESS_BYTE_COUNT)
> > > > > > > > > > >               level = (read_val[0] << 8 | read_val[1]);
> > > > > > > > > > >
> > > > > > > > > > > +     if (i915->quirks &
> > > > > > > > > > > QUIRK_SHIFT_EDP_BACKLIGHT_BRIGHTNESS) {
> > > > > > > > > > > +             if (!drm_dp_dpcd_readb(&intel_dp->aux,
> > > > > > > > > > > DP_EDP_PWMGEN_BIT_COUNT,
> > > > > > > > > > > +                                             &read_val[0]
> > > > > > > > > > > )) {
> > > > > > > > > > > +                     DRM_DEBUG_KMS("Failed to read DPCD
> > > > > > > > > > > register 0x%x\n",
> > > > > > > > > > > +                                     DP_EDP_PWMGEN_BIT_CO
> > > > > > > > > > > UNT);
> > > > > > > > > > > +                     return 0;
> > > > > > > > > > > +             }
> > > > > > > > > > > +             // Only bits 4:0 are used, 7:5 are reserved.
> > > > > > > > > > > +             read_val[0] = read_val[0] & 0x1F;
> > > > > > > > > > > +             if (read_val[0] > 16) {
> > > > > > > > > > > +                     DRM_DEBUG_KMS("Invalid
> > > > > > > > > > > DP_EDP_PWNGEN_BIT_COUNT 0x%X, expected at most 16\n",
> > > > > > > > > > > +                                             read_val[0])
> > > > > > > > > > > ;
> > > > > > > > > > > +                     return 0;
> > > > > > > > > > > +             }
> > > > > > > > > > > +             level >>= 16 - read_val[0];
> > > > > > > > > > > +     }
> > > > > > > > > > > +
> > > > > > > > > > >       return level;
> > > > > > > > > > >  }
> > > > > > > > > > >
> > > > > > > > > > > @@ -106,6 +123,23 @@ intel_dp_aux_set_backlight(const
> > > > > > > > > > > struct drm_connector_state *conn_state, u32 lev
> > > > > > > > > > >       struct drm_i915_private *i915 =
> > > > > > > > > > > dp_to_i915(intel_dp);
> > > > > > > > > > >       u8 vals[2] = { 0x0 };
> > > > > > > > > > >
> > > > > > > > > > > +     if (i915->quirks &
> > > > > > > > > > > QUIRK_SHIFT_EDP_BACKLIGHT_BRIGHTNESS) {
> > > > > > > > > > > +             if (!drm_dp_dpcd_readb(&intel_dp->aux,
> > > > > > > > > > > DP_EDP_PWMGEN_BIT_COUNT,
> > > > > > > > > > > +                                             &vals[0])) {
> > > > > > > > > > > +                     DRM_DEBUG_KMS("Failed to write aux
> > > > > > > > > > > backlight level: Failed to read DPCD register 0x%x\n",
> > > > > > > > > > > +                                       DP_EDP_PWMGEN_BIT_
> > > > > > > > > > > COUNT);
> > > > > > > > > > > +                     return;
> > > > > > > > > > > +             }
> > > > > > > > > > > +             // Only bits 4:0 are used, 7:5 are reserved.
> > > > > > > > > > > +             vals[0] = vals[0] & 0x1F;
> > > > > > > > > > > +             if (vals[0] > 16) {
> > > > > > > > > > > +                     DRM_DEBUG_KMS("Failed to write aux
> > > > > > > > > > > backlight level: Invalid DP_EDP_PWNGEN_BIT_COUNT 0x%X,
> > > > > > > > > > > expected at most 16\n",
> > > > > > > > > > > +                                             vals[0]);
> > > > > > > > > > > +                     return;
> > > > > > > > > > > +             }
> > > > > > > > > > > +             level <<= (16 - vals[0]) & 0xFFFF;
> > > > > > > > > > > +     }
> > > > > > > > > > > +
> > > > > > > > > > >       vals[0] = level;
> > > > > > > > > > >
> > > > > > > > > > >       /* Write the MSB and/or LSB */
> > > > > > > > > > > diff --git a/drivers/gpu/drm/i915/display/intel_quirks.c
> > > > > > > > > > > b/drivers/gpu/drm/i915/display/intel_quirks.c
> > > > > > > > > > > index 46beb155d835f..63b27d49b2864 100644
> > > > > > > > > > > --- a/drivers/gpu/drm/i915/display/intel_quirks.c
> > > > > > > > > > > +++ b/drivers/gpu/drm/i915/display/intel_quirks.c
> > > > > > > > > > > @@ -53,6 +53,16 @@ static void
> > > > > > > > > > > quirk_increase_ddi_disabled_time(struct drm_i915_private
> > > > > > > > > > > *i915)
> > > > > > > > > > >       drm_info(&i915->drm, "Applying Increase DDI Disabled
> > > > > > > > > > > quirk\n");
> > > > > > > > > > >  }
> > > > > > > > > > >
> > > > > > > > > > > +/*
> > > > > > > > > > > + * Some eDP backlight hardware uses the most-significant
> > > > > > > > > > > bits of the brightness
> > > > > > > > > > > + * register, so brightness values must be shifted first.
> > > > > > > > > > > + */
> > > > > > > > > > > +static void quirk_shift_edp_backlight_brightness(struct
> > > > > > > > > > > drm_i915_private *i915)
> > > > > > > > > > > +{
> > > > > > > > > > > +     i915->quirks |=
> > > > > > > > > > > QUIRK_SHIFT_EDP_BACKLIGHT_BRIGHTNESS;
> > > > > > > > > > > +     DRM_INFO("Applying shift eDP backlight brightness
> > > > > > > > > > > quirk\n");
> > > > > > > > > > > +}
> > > > > > > > > > > +
> > > > > > > > > > >  struct intel_quirk {
> > > > > > > > > > >       int device;
> > > > > > > > > > >       int subsystem_vendor;
> > > > > > > > > > > @@ -156,6 +166,9 @@ static struct intel_quirk
> > > > > > > > > > > intel_quirks[] = {
> > > > > > > > > > >       /* ASRock ITX*/
> > > > > > > > > > >       { 0x3185, 0x1849, 0x2212,
> > > > > > > > > > > quirk_increase_ddi_disabled_time },
> > > > > > > > > > >       { 0x3184, 0x1849, 0x2212,
> > > > > > > > > > > quirk_increase_ddi_disabled_time },
> > > > > > > > > > > +
> > > > > > > > > > > +     /* Google Pixelbook */
> > > > > > > > > > > +     { 0x591E, 0x8086, 0x2212,
> > > > > > > > > > > quirk_shift_edp_backlight_brightness },
> > > > > > > > > > >  };
> > > > > > > > > > >
> > > > > > > > > > >  void intel_init_quirks(struct drm_i915_private *i915)
> > > > > > > > > > > diff --git a/drivers/gpu/drm/i915/i915_drv.h
> > > > > > > > > > > b/drivers/gpu/drm/i915/i915_drv.h
> > > > > > > > > > > index e4f7f6518945b..cc93bede4fab8 100644
> > > > > > > > > > > --- a/drivers/gpu/drm/i915/i915_drv.h
> > > > > > > > > > > +++ b/drivers/gpu/drm/i915/i915_drv.h
> > > > > > > > > > > @@ -525,6 +525,7 @@ struct i915_psr {
> > > > > > > > > > >  #define QUIRK_PIN_SWIZZLED_PAGES (1<<5)
> > > > > > > > > > >  #define QUIRK_INCREASE_T12_DELAY (1<<6)
> > > > > > > > > > >  #define QUIRK_INCREASE_DDI_DISABLED_TIME (1<<7)
> > > > > > > > > > > +#define QUIRK_SHIFT_EDP_BACKLIGHT_BRIGHTNESS (1<<8)
> > > > > > > > > > >
> > > > > > > > > > >  struct intel_fbdev;
> > > > > > > > > > >  struct intel_fbc_work;
> > > > > > > > > >
> > > > > > > > > > --
> > > > > > > > > > Jani Nikula, Intel Open Source Graphics Center
> > > > > > >
> > > > > > > --
> > > > > > > Ville Syrjälä
> > > > > > > Intel
> > > > > > > _______________________________________________
> > > > > > > Intel-gfx mailing list
> > > > > > > Intel-gfx@lists.freedesktop.org
> > > > > > > https://lists.freedesktop.org/mailman/listinfo/intel-gfx
> > > > > >
> > > > > > --
> > > > > > Ville Syrjälä
> > > > > > Intel
> --
> Cheers,
>         Lyude Paul (she/her)
>         Software Engineer at Red Hat
>

Re: [Intel-gfx] [PATCH] i915: Introduce quirk for shifting eDP brightness.

[Lyude Paul]

On Thu, 2020-09-24 at 17:46 -0600, Kevin Chowski wrote:
> cc back a few others who were unintentionally dropped from the thread
> earlier.
> 
> Someone (at Google) helped me dig into this a little more and they
> found a document titled "eDP Backlight Brightness bit alignment" sent
> out for review in January 2017. I registered for a new account (google
> is a member) and have access to the document; here is the URL for
> those who also have access:
> https://groups.vesa.org/wg/AllMem/document/7786. For what it's worth,
> it seems like Lyude's contact Bill Lempesis uploaded this
> change-request document, so I think we can reach out to him if we have
> further questions. It's actually unclear to me what the status of this
> change request is, and whether it's been officially accepted. But I
> think it can be seen as some official advice on how we can move
> forward here.
> 
> Basically, this is a change request to the spec which acknowledges
> that, despite the original spec implying that the
> most-significant-bits were relevant here, many implementations used
> the least-significant-bits. In defense of most-significant it laid out
> some similar arguments to what Ville was saying. But it ends up
> saying:
> 
> > Unfortunately, the most common interpretation that we have
> > encountered is case 1 in the example above. TCON vendors
> > tend to align the valid bits to the LSBs, not the MSBs.
> 
> Instead of changing the default defined functionality (as some earlier
> version of this doc apparently suggested), this doc prefers to
> allocate two extra bits in EDP_GENERAL_CAPABILITY_2 so that future
> backlight devices can specify to the Source how to program them:
> 
> 00: the current functionality, i,e. no defined interpretation
> 01: aligned to most-significant bits
> 10: aligned to least-significant bits
> 11: reserved
> 
> It also says "[Sources] should only need panel-specific workarounds
> for the currently available panels."
> 
> So I believe this document is an acknowledgement of many
> implementations having their alignment to the least-significant bits,
> and (to my eyes) clearly validates that the spec "should" be the
> opposite. If we believe the doc's claim that "the most common
> interpretation" is least-significant, it seems to me that it would
> require more quirks if we made most-significant the default
> implementation.
> 
> Ville mentioned at some point earlier that we should try to match the
> spec, whereas Lyude mentioned we should prefer to do what the majority
> of machines do. What do you both think of this new development?

That's how displayport happens to be sometimes :). Definitely isn't the first
time something in the spec like this got implemented incorrectly so many times
by different vendors that they had to update the spec in response (same thing
happened with MST and interleaved sideband messages as of DP 2.0), so I'm
really glad we went and actually investigated this.

So yes - I think a quirk for this would definitely be a good idea, and IMO we
should always lean on the side that more panels implement even if it's not
according to spec - so defaulting to the behavior we currently have in the
kernel, and adding quirks for panels that were smart enough not to fall for
this would probably be the best way to go. That just leaves the challenge of
"how do we figure out which panels actually need this and which ones don't?"

This might end up being a bit of a challenge, but I've got some ideas on how
we might be able to tackle it to the best of our ability based off my
discussions with laptop vendors. It seems like some of the homegrown backlight
interfaces might help us out here. Note I'm mentioning other laptop vendors
here because at least for nouveau, our plan for DPCD backlight support is to
move a lot of the code for handling it that currently lives in i915 into
shared DRM helpers (which now we'll definitely need to do as a result of these
quirks).

So, on the x86 front, there's already a few different interfaces in use for
laptop panels:
 * AMD usually uses their own backlight interface, so for AMD-only laptops we
   can probably safely ignore this
 * Intel uses their own DPCD backlight interface on most of the _non-ChromeOS_ 
   machines on the market right now afaik based off my discussion with some
   laptop vendors. For panels that only come up in Intel-only machines, that
   means we only really need to care about the ChromeOS case here. So-if
   Google's able to actually survey the devices they're shipping with ChromeOS
   right now to figure out which ones are using DPCD backlight controls, and
   which ones need to be MSB aligned - then I'd think we could probably build
   an accurate quirk list of those panels easily.
 * This just leaves the nvidia case. Nvidia seems to be one of the only GPU
   vendors that didn't come up with their own backlight interface over DPCD,
   and they actually require that the panel support the VESA backlight control
   interface. Incidentally, a lot of the laptops that I've force-enabled VESA
   backlight controls on have nvidia GPUs in them, and so far every single one
   has worked with the code we currently use in the kernel. My hope with this
   would be that since nvidia's driver support is somewhat consistent, they
   either might have a list of problematic panels or can just verify with us
   that all of the panels that their driver interacts with follow the LSB
   preference.

For the ChromeOS guys in the thread, does this sound like it could be
workable? For the time being, I'll also send my nvidia contacts a poke to see
what info they can give us. As well, we should probably poke Bill just in case
he might know of some resource that documents some of the problematic panels
out there (probably not, but it's at least worth a shot). I'll try to get
around this today, but we might have to poke him once or twice since there
originally was a problem with any of the emails from Red Hat getting through
to him…

> 
> I will also look into whether my specific device supports this
> extension, and in that case I'll volunteer to implement this new
> functionality in the driver.
> 
> Thanks for your time,
> Kevin
> 
> On Tue, Sep 22, 2020 at 3:30 PM Lyude Paul <lyude@redhat.com> wrote:
> > Hi! Since I got dropped from the thread, many responses inline
> > 
> > On Tue, 2020-09-22 at 12:58 -0700, Puthikorn Voravootivat wrote:
> > > +Lyude
> > > I notice that Lyude email was somehow dropped from the thread.
> > > Lyude was the person who submitted the patch for Thinkpad and should
> > > know the OUI of the panel.
> > 
> > no need - currently because of some confusion that got caused by the Intel
> > HDR
> > backlight interface being the only backlight interface that works properly
> > on
> > a lot of panels (many panels will advertise both interfaces, but might
> > only
> > work with the Intel one), we actually rely on a small allowlist of
> > "approved"
> > panels for enabling DPCD backlight control.
> > 
> > …however, many of these panels are annoying and don't actually provide a
> > reliable enough OUID to use for quirk detection, which is why we had to
> > add
> > EDID quirk detection as a temporary workaround for this. The current list
> > of
> > panels lives in drm_dp_helper.c:
> > 
> > /*
> >  * Some devices have unreliable OUIDs where they don't set the device ID
> >  * correctly, and as a result we need to use the EDID for finding
> > additional
> >  * DP quirks in such cases.
> >  */
> > static const struct edid_quirk edid_quirk_list[] = {
> >         /* Optional 4K AMOLED panel in the ThinkPad X1 Extreme 2nd
> > Generation
> >          * only supports DPCD backlight controls
> >          */
> >         { MFG(0x4c, 0x83), PROD_ID(0x41, 0x41),
> > BIT(DP_QUIRK_FORCE_DPCD_BACKLIGHT) },
> >         /*
> >          * Some Dell CML 2020 systems have panels support both AUX and PWM
> >          * backlight control, and some only support AUX backlight control.
> > All
> >          * said panels start up in AUX mode by default, and we don't have
> > any
> >          * support for disabling HDR mode on these panels which would be
> >          * required to switch to PWM backlight control mode (plus, I'm not
> >          * even sure we want PWM backlight controls over DPCD backlight
> >          * controls anyway...). Until we have a better way of detecting
> > these,
> >          * force DPCD backlight mode on all of them.
> >          */
> >         { 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(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) },
> > };
> > 
> > Also note that I think just about every panel on that list supports the
> > Intel
> > HDR backlight interface, so it's -possible- that the VESA interface could
> > be
> > broken on these panels. But, that would be a lot of different panels from
> > different vendors to all be broken in the same way.
> > 
> > > On Tue, Sep 22, 2020 at 11:47 AM Kevin Chowski <chowski@chromium.org>
> > > wrote:
> > > > Alrighty, I'll take everyone else's silence as tacit approval of
> > > > Ville's opinions. (I didn't receive any email bounces this time, so I
> > > > think my issue was transient.) I will start on inverting the quirk and
> > > > making the most-significant-alignment matter for these registers by
> > > > default.
> > > > 
> > > > Who can help me gather a list of OUIs that we need to add to the
> > > > quirk? I can follow up with Puthikorn about the relevant Chromebooks,
> > > > but I don't know what other types of laptops are using this driver.
> > > > 
> > > > Thanks for your time,
> > > > Kevin Chowski
> > > > 
> > > > 
> > > > On Fri, Sep 18, 2020 at 12:16 PM Puthikorn Voravootivat
> > > > <puthik@chromium.org> wrote:
> > > > > I'll defer to Ville & Lyude.
> > > > > 
> > > > > I dug up more on the bug report and found that both Thinkpad and
> > > > > Galaxy Chromebook use the same Samsung OLED.
> > > > > So my 2 vs 1 argument is actually not valid.
> > > > > 
> > > > > On Fri, Sep 18, 2020 at 10:59 AM Kevin Chowski <chowski@chromium.org
> > > > > >
> > > > > wrote:
> > > > > > Apologies once again, some of my emails were bouncing for some
> > > > > > addresses yesterday. Hopefully it was a temporary condition; I'll
> > > > > > continue trying to dig into it on my end if it happens again for
> > > > > > this
> > > > > > email.
> > > > > > 
> > > > > > Since there's evidence that some models want lsb and some (well,
> > > > > > at
> > > > > > least one) want msb, my understanding is that we'll need a quirk
> > > > > > one
> > > > > > way or the other (please correct if I'm mistaken). I unfortunately
> > > > > > don't have the ability to test anything other than the Pixelbook,
> > > > > > so
> > > > > > if we decide the msb is the "right" way, then I will have to rely
> > > > > > on
> > > > > > others to test (and find the OUI of) other models which require
> > > > > > lsb.
> > > > > > 
> > > > > > I am happy to make any changes requested, but I do not at all have
> > > > > > enough background here to make the decision on whether the msb
> > > > > > functionality deserves the quirk or if the lsb one does. How can I
> > > > > > help you all come to an agreement here?
> > > > > > 
> > > > > > * It seems like Ville feels strongly about the msb being the
> > > > > > correct
> > > > > > interpretation of the spec.
> > > > > > * It's unclear to me on which side of the fence Lyude falls, I
> > > > > > couldn't pick up a strong opinion in her clarifying question.
> > > > > > * Puthikorn seems to be on the side of lsb being correct, but
> > > > > > maybe
> > > > > > was swayed by Ville's argument.
> > 
> > Honestly I'm not hard to convince :P, if it looks like we got the bit
> > shift
> > wrong for the majority of devices and everyone else agrees then I'm fine
> > with
> > assuming that's the case. I'm just quite surprised, seeing as we've tested
> > many different panels from a few vendors and haven't run into any issues
> > with
> > this before.
> > 
> > Honestly - if there's this much uncertainty about it, maybe we should just
> > ask
> > VESA directly what the correct interpretation of this is? Note I'm not on
> > the
> > VESA board (I get access to DP/eDP specs through X.org) so unless the
> > contacts
> > I've got from VESA would work (Bill Lempesis bill at vesa dot org) for
> > that it
> > might be a better idea for someone from Google or Intel to ask.
> > 
> > > > > > If no one feels that Ville's argument is not strong in some way,
> > > > > > and
> > > > > > we go with that, I will get to work on the requested changes. I am
> > > > > > concerned, though, about changing the default functionality
> > > > > > without
> > > > > > testing it widely to find the set of laptops which require the lsb
> > > > > > quirk. I'd appreciate any advice people might have about making
> > > > > > this
> > > > > > change safely.
> > 
> > Usually, I just try to stick with what the majority of machines need to
> > do. I
> > still think it'd be a good idea for us to verify this with VESA if there's
> > that much confusion though
> > 
> > > > > > Thank you for your time,
> > > > > > Kevin
> > > > > > 
> > > > > > On Thu, Sep 17, 2020 at 2:11 PM Ville Syrjälä
> > > > > > <ville.syrjala@linux.intel.com> wrote:
> > > > > > > On Thu, Sep 17, 2020 at 09:25:35PM +0300, Ville Syrjälä wrote:
> > > > > > > > On Thu, Sep 17, 2020 at 11:14:43AM -0700, Puthikorn
> > > > > > > > Voravootivat
> > > > > > > > wrote:
> > > > > > > > > The Lyude fde7266fb2f6 change is actually based on Chromium
> > > > > > > > > change
> > > > > > > > > (https://crrev.com/c/1650325) that fixes the brightness for
> > > > > > > > > Samsung
> > > > > > > > > Galaxy Chromebook. So currently we have 2 examples that use
> > > > > > > > > LSB
> > > > > > > > > interpretation and 1 that use MSB.
> > > > > > > > 
> > > > > > > > "If field 4:0 of the EDP_PWMGEN_BIT_COUNT register represents
> > > > > > > > a
> > > > > > > > value
> > > > > > > > of greater than 8 and the BACKLIGHT_BRIGHTNESS_BYTE_COUNT bit
> > > > > > > > is cleared to 0, only the 8 MSB of the brightness control
> > > > > > > > value
> > > > > > > > can be
> > > > > > > > controlled.
> > > > > > > > (See Note below.)
> > > > > > > > Assigned bits are allocated to the MSB of the enabled register
> > > > > > > > combination."
> > > > > > > > 
> > > > > > > > I think that's pretty clear the assigned bits are supposed to
> > > > > > > > be
> > > > > > > > msb aligned.
> > > > > > > 
> > > > > > > I guess there's some email issues happening, but just to
> > > > > > > clarify:
> > > > > > > 
> > > > > > > When the spec says MSB in caps here it clearly means
> > > > > > > "most significant-bit(s)" since otherwise "8 MSB" would not make
> > > > > > > any sense in the context of a 2 byte value.
> > > > > > > 
> > > > > > > Granted the spec is crap here since "Table 1-1: Acronyms and
> > > > > > > Initialism" does claim "MSB" should be byte(s) and "msb" bit(s).
> > > > > > > 
> > > > > > > Also I can't imagine anyone would allocate the bits starting
> > > > > > > from the lsb when the whole thing is clearly supposed to be a
> > > > > > > 16bit big endian integer. So with >8 assigned bits you'd end
> > > > > > > up with crazy stuff like this:
> > > > > > > 
> > > > > > > [ 7 ... 0 ][7   ...   0]
> > > > > > > [ 8 MSB   ][XXXX][N LSB]
> > > > > > > 
> > > > > > > so you couldn't even treat the value as a regular big endian
> > > > > > > thing. Instead, if you squint a bit, it now looks like a funky
> > > > > > > little endian value. So we're deep into some mixed endian land
> > > > > > > where nothing makes sense anymore.
> > > > > > > 
> > > > > > > Anyways I think the code should simply do this to match the
> > > > > > > spec:
> > > > > > > u16 value = brightness << (16 - num_assigned_bits);
> > > > > > > val[0] = value >> 8;
> > > > > > > val[1] = value & 0xff;
> > > > > > > 
> > > > > > > 
> > > > > > > > > On Thu, Sep 17, 2020 at 10:55 AM Kevin Chowski <
> > > > > > > > > chowski@chromium.org> wrote:
> > > > > > > > > > Apologies for being too vague. To be as precise I can be,
> > > > > > > > > > here
> > > > > > > > > > is the
> > > > > > > > > > specific code delta I tested: https://crrev.com/c/2406616
> > > > > > > > > > . To
> > > > > > > > > > answer
> > > > > > > > > > your other question, the code I tested against is indeed
> > > > > > > > > > including the
> > > > > > > > > > fde7266fb2f6 (despite ostensibly being called 5.4 in my
> > > > > > > > > > commit
> > > > > > > > > > message): our current top-of-tree for our 5.4 branch
> > > > > > > > > > includes
> > > > > > > > > > the
> > > > > > > > > > intel_dp_aux_calc_max_backlight logic. Further, I'll note
> > > > > > > > > > that
> > > > > > > > > > change
> > > > > > > > > > is exactly the change which breaks my Pixelbook model:
> > > > > > > > > > prior
> > > > > > > > > > to the
> > > > > > > > > > change, the max_brightness was hard-coded to 0xFFFF and
> > > > > > > > > > the
> > > > > > > > > > math
> > > > > > > > > > worked out that it didn't matter that the hardware cared
> > > > > > > > > > about
> > > > > > > > > > the MSB
> > > > > > > > > > despite the driver code caring about the LSB.
> > > > > > > > > > 
> > > > > > > > > > To answer Ville's question: the fde7266fb2f6 change which
> > > > > > > > > > fixes one
> > > > > > > > > > laptop (I believe Thinkpad X1 extreme Gen 2, from some bug
> > > > > > > > > > reports I
> > > > > > > > > > dug up) and breaks another (Pixelbook); so unfortunately I
> > > > > > > > > > believe we
> > > > > > > > > > need a quirk at least for some laptop. Reading through the
> > > > > > > > > > copy of the
> > > > > > > > > > datasheet I have, it wasn't clear to me which was the
> > > > > > > > > > correct
> > > > > > > > > > interpretation. I'm cc'ing puthik@, who was leaning toward
> > > > > > > > > > the
> > > > > > > > > > current
> > > > > > > > > > kernel code (caring about LSB) being the correct
> > > > > > > > > > interpretation. I
> > > > > > > > > > believe we have other chromebooks which do rely on LSB
> > > > > > > > > > functionality,
> > > > > > > > > > so unless we can find more examples of laptops wanting MSB
> > > > > > > > > > it
> > > > > > > > > > currently looks like Pixelbook is the outlier.
> > > > > > > > > > 
> > > > > > > > > > On Thu, Sep 17, 2020 at 11:28 AM Jani Nikula
> > > > > > > > > > <jani.nikula@linux.intel.com> wrote:
> > > > > > > > > > > On Thu, 17 Sep 2020, Kevin Chowski <chowski@chromium.org
> > > > > > > > > > > >
> > > > > > > > > > > wrote:
> > > > > > > > > > > > We have observed that Google Pixelbook's backlight
> > > > > > > > > > > > hardware is
> > > > > > > > > > > > interpretting these backlight bits from the most-
> > > > > > > > > > > > significant side of the
> > > > > > > > > > > > 16 bit word (if DP_EDP_PWMGEN_BIT_COUNT < 16), whereas
> > > > > > > > > > > > the
> > > > > > > > > > > > driver code
> > > > > > > > > > > > assumes the peripheral cares about the least-
> > > > > > > > > > > > significant
> > > > > > > > > > > > bits.
> > > > > > > > > > > > 
> > > > > > > > > > > > Testing was done from within Chrome OS's build
> > > > > > > > > > > > environment
> > > > > > > > > > > > when the
> > > > > > > > > > > > patch is backported to 5.4 (the version we are newly
> > > > > > > > > > > > targeting for the
> > > > > > > > > > > > Pixelbook); for the record:
> > > > > > > > > > > >    $ emerge-eve-kernelnext sys-kernel/chromeos-kernel-
> > > > > > > > > > > > 5_4
> > > > > > > > > > > > && \
> > > > > > > > > > > >       ./update_kernel.sh --remote=$IP
> > > > > > > > > > > > 
> > > > > > > > > > > > I used `/sys/kernel/debug/dri/0/eDP-1/i915_dpcd` on my
> > > > > > > > > > > > laptop to verify
> > > > > > > > > > > > that the registers were being set according to what
> > > > > > > > > > > > the
> > > > > > > > > > > > actual hardware
> > > > > > > > > > > > expects; I also observe that the backlight is
> > > > > > > > > > > > noticeably
> > > > > > > > > > > > brighter with
> > > > > > > > > > > > this patch.
> > > > > > > > > > > 
> > > > > > > > > > > It's unclear to me what kernel version this is against,
> > > > > > > > > > > and
> > > > > > > > > > > what you've
> > > > > > > > > > > actually tested.
> > > > > > > > > > > 
> > > > > > > > > > > Have you tried v5.7 kernel with Lyude's fde7266fb2f6
> > > > > > > > > > > ("drm/i915: Fix eDP
> > > > > > > > > > > DPCD aux max backlight calculations")?
> > > > > > > > > > > 
> > > > > > > > > > > I just want to make sure you've tested with all the
> > > > > > > > > > > relevant
> > > > > > > > > > > fixes
> > > > > > > > > > > before adding quirks.
> > > > > > > > > > > 
> > > > > > > > > > > BR,
> > > > > > > > > > > Jani.
> > > > > > > > > > > 
> > > > > > > > > > > > Signed-off-by: Kevin Chowski <chowski@chromium.org>
> > > > > > > > > > > > ---
> > > > > > > > > > > > 
> > > > > > > > > > > >  .../drm/i915/display/intel_dp_aux_backlight.c | 34
> > > > > > > > > > > > +++++++++++++++++++
> > > > > > > > > > > >  drivers/gpu/drm/i915/display/intel_quirks.c   | 13
> > > > > > > > > > > > +++++++
> > > > > > > > > > > >  drivers/gpu/drm/i915/i915_drv.h               |  1 +
> > > > > > > > > > > >  3 files changed, 48 insertions(+)
> > > > > > > > > > > > 
> > > > > > > > > > > > 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 acbd7eb66cbe3..99c98f217356d 100644
> > > > > > > > > > > > ---
> > > > > > > > > > > > a/drivers/gpu/drm/i915/display/intel_dp_aux_backlight.
> > > > > > > > > > > > c
> > > > > > > > > > > > +++
> > > > > > > > > > > > b/drivers/gpu/drm/i915/display/intel_dp_aux_backlight.
> > > > > > > > > > > > c
> > > > > > > > > > > > @@ -91,6 +91,23 @@ static u32
> > > > > > > > > > > > intel_dp_aux_get_backlight(struct intel_connector
> > > > > > > > > > > > *connector)
> > > > > > > > > > > >       if (intel_dp->edp_dpcd[2] &
> > > > > > > > > > > > DP_EDP_BACKLIGHT_BRIGHTNESS_BYTE_COUNT)
> > > > > > > > > > > >               level = (read_val[0] << 8 |
> > > > > > > > > > > > read_val[1]);
> > > > > > > > > > > > 
> > > > > > > > > > > > +     if (i915->quirks &
> > > > > > > > > > > > QUIRK_SHIFT_EDP_BACKLIGHT_BRIGHTNESS) {
> > > > > > > > > > > > +             if (!drm_dp_dpcd_readb(&intel_dp->aux,
> > > > > > > > > > > > DP_EDP_PWMGEN_BIT_COUNT,
> > > > > > > > > > > > +                                             &read_va
> > > > > > > > > > > > l[0]
> > > > > > > > > > > > )) {
> > > > > > > > > > > > +                     DRM_DEBUG_KMS("Failed to read
> > > > > > > > > > > > DPCD
> > > > > > > > > > > > register 0x%x\n",
> > > > > > > > > > > > +                                     DP_EDP_PWMGEN_BI
> > > > > > > > > > > > T_CO
> > > > > > > > > > > > UNT);
> > > > > > > > > > > > +                     return 0;
> > > > > > > > > > > > +             }
> > > > > > > > > > > > +             // Only bits 4:0 are used, 7:5 are
> > > > > > > > > > > > reserved.
> > > > > > > > > > > > +             read_val[0] = read_val[0] & 0x1F;
> > > > > > > > > > > > +             if (read_val[0] > 16) {
> > > > > > > > > > > > +                     DRM_DEBUG_KMS("Invalid
> > > > > > > > > > > > DP_EDP_PWNGEN_BIT_COUNT 0x%X, expected at most 16\n",
> > > > > > > > > > > > +                                             read_val
> > > > > > > > > > > > [0])
> > > > > > > > > > > > ;
> > > > > > > > > > > > +                     return 0;
> > > > > > > > > > > > +             }
> > > > > > > > > > > > +             level >>= 16 - read_val[0];
> > > > > > > > > > > > +     }
> > > > > > > > > > > > +
> > > > > > > > > > > >       return level;
> > > > > > > > > > > >  }
> > > > > > > > > > > > 
> > > > > > > > > > > > @@ -106,6 +123,23 @@ intel_dp_aux_set_backlight(const
> > > > > > > > > > > > struct drm_connector_state *conn_state, u32 lev
> > > > > > > > > > > >       struct drm_i915_private *i915 =
> > > > > > > > > > > > dp_to_i915(intel_dp);
> > > > > > > > > > > >       u8 vals[2] = { 0x0 };
> > > > > > > > > > > > 
> > > > > > > > > > > > +     if (i915->quirks &
> > > > > > > > > > > > QUIRK_SHIFT_EDP_BACKLIGHT_BRIGHTNESS) {
> > > > > > > > > > > > +             if (!drm_dp_dpcd_readb(&intel_dp->aux,
> > > > > > > > > > > > DP_EDP_PWMGEN_BIT_COUNT,
> > > > > > > > > > > > +                                             &vals[0]
> > > > > > > > > > > > )) {
> > > > > > > > > > > > +                     DRM_DEBUG_KMS("Failed to write
> > > > > > > > > > > > aux
> > > > > > > > > > > > backlight level: Failed to read DPCD register 0x%x\n",
> > > > > > > > > > > > +                                       DP_EDP_PWMGEN_
> > > > > > > > > > > > BIT_
> > > > > > > > > > > > COUNT);
> > > > > > > > > > > > +                     return;
> > > > > > > > > > > > +             }
> > > > > > > > > > > > +             // Only bits 4:0 are used, 7:5 are
> > > > > > > > > > > > reserved.
> > > > > > > > > > > > +             vals[0] = vals[0] & 0x1F;
> > > > > > > > > > > > +             if (vals[0] > 16) {
> > > > > > > > > > > > +                     DRM_DEBUG_KMS("Failed to write
> > > > > > > > > > > > aux
> > > > > > > > > > > > backlight level: Invalid DP_EDP_PWNGEN_BIT_COUNT 0x%X,
> > > > > > > > > > > > expected at most 16\n",
> > > > > > > > > > > > +                                             vals[0])
> > > > > > > > > > > > ;
> > > > > > > > > > > > +                     return;
> > > > > > > > > > > > +             }
> > > > > > > > > > > > +             level <<= (16 - vals[0]) & 0xFFFF;
> > > > > > > > > > > > +     }
> > > > > > > > > > > > +
> > > > > > > > > > > >       vals[0] = level;
> > > > > > > > > > > > 
> > > > > > > > > > > >       /* Write the MSB and/or LSB */
> > > > > > > > > > > > diff --git
> > > > > > > > > > > > a/drivers/gpu/drm/i915/display/intel_quirks.c
> > > > > > > > > > > > b/drivers/gpu/drm/i915/display/intel_quirks.c
> > > > > > > > > > > > index 46beb155d835f..63b27d49b2864 100644
> > > > > > > > > > > > --- a/drivers/gpu/drm/i915/display/intel_quirks.c
> > > > > > > > > > > > +++ b/drivers/gpu/drm/i915/display/intel_quirks.c
> > > > > > > > > > > > @@ -53,6 +53,16 @@ static void
> > > > > > > > > > > > quirk_increase_ddi_disabled_time(struct
> > > > > > > > > > > > drm_i915_private
> > > > > > > > > > > > *i915)
> > > > > > > > > > > >       drm_info(&i915->drm, "Applying Increase DDI
> > > > > > > > > > > > Disabled
> > > > > > > > > > > > quirk\n");
> > > > > > > > > > > >  }
> > > > > > > > > > > > 
> > > > > > > > > > > > +/*
> > > > > > > > > > > > + * Some eDP backlight hardware uses the most-
> > > > > > > > > > > > significant
> > > > > > > > > > > > bits of the brightness
> > > > > > > > > > > > + * register, so brightness values must be shifted
> > > > > > > > > > > > first.
> > > > > > > > > > > > + */
> > > > > > > > > > > > +static void
> > > > > > > > > > > > quirk_shift_edp_backlight_brightness(struct
> > > > > > > > > > > > drm_i915_private *i915)
> > > > > > > > > > > > +{
> > > > > > > > > > > > +     i915->quirks |=
> > > > > > > > > > > > QUIRK_SHIFT_EDP_BACKLIGHT_BRIGHTNESS;
> > > > > > > > > > > > +     DRM_INFO("Applying shift eDP backlight
> > > > > > > > > > > > brightness
> > > > > > > > > > > > quirk\n");
> > > > > > > > > > > > +}
> > > > > > > > > > > > +
> > > > > > > > > > > >  struct intel_quirk {
> > > > > > > > > > > >       int device;
> > > > > > > > > > > >       int subsystem_vendor;
> > > > > > > > > > > > @@ -156,6 +166,9 @@ static struct intel_quirk
> > > > > > > > > > > > intel_quirks[] = {
> > > > > > > > > > > >       /* ASRock ITX*/
> > > > > > > > > > > >       { 0x3185, 0x1849, 0x2212,
> > > > > > > > > > > > quirk_increase_ddi_disabled_time },
> > > > > > > > > > > >       { 0x3184, 0x1849, 0x2212,
> > > > > > > > > > > > quirk_increase_ddi_disabled_time },
> > > > > > > > > > > > +
> > > > > > > > > > > > +     /* Google Pixelbook */
> > > > > > > > > > > > +     { 0x591E, 0x8086, 0x2212,
> > > > > > > > > > > > quirk_shift_edp_backlight_brightness },
> > > > > > > > > > > >  };
> > > > > > > > > > > > 
> > > > > > > > > > > >  void intel_init_quirks(struct drm_i915_private *i915)
> > > > > > > > > > > > diff --git a/drivers/gpu/drm/i915/i915_drv.h
> > > > > > > > > > > > b/drivers/gpu/drm/i915/i915_drv.h
> > > > > > > > > > > > index e4f7f6518945b..cc93bede4fab8 100644
> > > > > > > > > > > > --- a/drivers/gpu/drm/i915/i915_drv.h
> > > > > > > > > > > > +++ b/drivers/gpu/drm/i915/i915_drv.h
> > > > > > > > > > > > @@ -525,6 +525,7 @@ struct i915_psr {
> > > > > > > > > > > >  #define QUIRK_PIN_SWIZZLED_PAGES (1<<5)
> > > > > > > > > > > >  #define QUIRK_INCREASE_T12_DELAY (1<<6)
> > > > > > > > > > > >  #define QUIRK_INCREASE_DDI_DISABLED_TIME (1<<7)
> > > > > > > > > > > > +#define QUIRK_SHIFT_EDP_BACKLIGHT_BRIGHTNESS (1<<8)
> > > > > > > > > > > > 
> > > > > > > > > > > >  struct intel_fbdev;
> > > > > > > > > > > >  struct intel_fbc_work;
> > > > > > > > > > > 
> > > > > > > > > > > --
> > > > > > > > > > > Jani Nikula, Intel Open Source Graphics Center
> > > > > > > > 
> > > > > > > > --
> > > > > > > > Ville Syrjälä
> > > > > > > > Intel
> > > > > > > > _______________________________________________
> > > > > > > > Intel-gfx mailing list
> > > > > > > > Intel-gfx@lists.freedesktop.org
> > > > > > > > https://lists.freedesktop.org/mailman/listinfo/intel-gfx
> > > > > > > 
> > > > > > > --
> > > > > > > Ville Syrjälä
> > > > > > > Intel
> > --
> > Cheers,
> >         Lyude Paul (she/her)
> >         Software Engineer at Red Hat
> > 
-- 
Cheers,
	Lyude Paul (she/her)
	Software Engineer at Red Hat

Re: [Intel-gfx] [PATCH] i915: Introduce quirk for shifting eDP brightness.

[Kevin Chowski]

Thank you for the reply. And in regards to digging into it further,
thanks for requesting that I do some more due diligence here :)

Also if you did get around to it, thanks for double-checking with
Bill! Let me know if you'd like me to reach out instead, or if
anything else needs to be done in this regard.

So to clarify the plan: if we do actually move forwards with leaving
the current functionality as the default, do we need to have the
complete list of devices which need the quirk applied when the patch
first goes in? From my perspective, we definitely have one device
which needs the quirk (and preferably, it'd be good to do it sooner
than later so that we can get this bugfix out to our users) and an
unknowable number of others. Would it be OK to introduce the quirk for
just Pixelbook and to follow up to add others once we have that list?
It may take a good amount of time for me to herd the cats inside
Google, especially given there's a chance that there are affected
laptops and that no one has noticed (e.g., I almost didn't notice with
the Pixelbook). Given Lyude's analysis it seems like Chrome OS devices
may be the largest affected group here, so I am incentivized to not
drop the ball after fixing my immediate Pixelbook problem :)

On Fri, Sep 25, 2020 at 10:53 AM Lyude Paul <lyude@redhat.com> wrote:
>
> On Thu, 2020-09-24 at 17:46 -0600, Kevin Chowski wrote:
> > cc back a few others who were unintentionally dropped from the thread
> > earlier.
> >
> > Someone (at Google) helped me dig into this a little more and they
> > found a document titled "eDP Backlight Brightness bit alignment" sent
> > out for review in January 2017. I registered for a new account (google
> > is a member) and have access to the document; here is the URL for
> > those who also have access:
> > https://groups.vesa.org/wg/AllMem/document/7786. For what it's worth,
> > it seems like Lyude's contact Bill Lempesis uploaded this
> > change-request document, so I think we can reach out to him if we have
> > further questions. It's actually unclear to me what the status of this
> > change request is, and whether it's been officially accepted. But I
> > think it can be seen as some official advice on how we can move
> > forward here.
> >
> > Basically, this is a change request to the spec which acknowledges
> > that, despite the original spec implying that the
> > most-significant-bits were relevant here, many implementations used
> > the least-significant-bits. In defense of most-significant it laid out
> > some similar arguments to what Ville was saying. But it ends up
> > saying:
> >
> > > Unfortunately, the most common interpretation that we have
> > > encountered is case 1 in the example above. TCON vendors
> > > tend to align the valid bits to the LSBs, not the MSBs.
> >
> > Instead of changing the default defined functionality (as some earlier
> > version of this doc apparently suggested), this doc prefers to
> > allocate two extra bits in EDP_GENERAL_CAPABILITY_2 so that future
> > backlight devices can specify to the Source how to program them:
> >
> > 00: the current functionality, i,e. no defined interpretation
> > 01: aligned to most-significant bits
> > 10: aligned to least-significant bits
> > 11: reserved
> >
> > It also says "[Sources] should only need panel-specific workarounds
> > for the currently available panels."
> >
> > So I believe this document is an acknowledgement of many
> > implementations having their alignment to the least-significant bits,
> > and (to my eyes) clearly validates that the spec "should" be the
> > opposite. If we believe the doc's claim that "the most common
> > interpretation" is least-significant, it seems to me that it would
> > require more quirks if we made most-significant the default
> > implementation.
> >
> > Ville mentioned at some point earlier that we should try to match the
> > spec, whereas Lyude mentioned we should prefer to do what the majority
> > of machines do. What do you both think of this new development?
>
> That's how displayport happens to be sometimes :). Definitely isn't the first
> time something in the spec like this got implemented incorrectly so many times
> by different vendors that they had to update the spec in response (same thing
> happened with MST and interleaved sideband messages as of DP 2.0), so I'm
> really glad we went and actually investigated this.
>
> So yes - I think a quirk for this would definitely be a good idea, and IMO we
> should always lean on the side that more panels implement even if it's not
> according to spec - so defaulting to the behavior we currently have in the
> kernel, and adding quirks for panels that were smart enough not to fall for
> this would probably be the best way to go. That just leaves the challenge of
> "how do we figure out which panels actually need this and which ones don't?"
>
> This might end up being a bit of a challenge, but I've got some ideas on how
> we might be able to tackle it to the best of our ability based off my
> discussions with laptop vendors. It seems like some of the homegrown backlight
> interfaces might help us out here. Note I'm mentioning other laptop vendors
> here because at least for nouveau, our plan for DPCD backlight support is to
> move a lot of the code for handling it that currently lives in i915 into
> shared DRM helpers (which now we'll definitely need to do as a result of these
> quirks).
>
> So, on the x86 front, there's already a few different interfaces in use for
> laptop panels:
>  * AMD usually uses their own backlight interface, so for AMD-only laptops we
>    can probably safely ignore this
>  * Intel uses their own DPCD backlight interface on most of the _non-ChromeOS_
>    machines on the market right now afaik based off my discussion with some
>    laptop vendors. For panels that only come up in Intel-only machines, that
>    means we only really need to care about the ChromeOS case here. So-if
>    Google's able to actually survey the devices they're shipping with ChromeOS
>    right now to figure out which ones are using DPCD backlight controls, and
>    which ones need to be MSB aligned - then I'd think we could probably build
>    an accurate quirk list of those panels easily.
>  * This just leaves the nvidia case. Nvidia seems to be one of the only GPU
>    vendors that didn't come up with their own backlight interface over DPCD,
>    and they actually require that the panel support the VESA backlight control
>    interface. Incidentally, a lot of the laptops that I've force-enabled VESA
>    backlight controls on have nvidia GPUs in them, and so far every single one
>    has worked with the code we currently use in the kernel. My hope with this
>    would be that since nvidia's driver support is somewhat consistent, they
>    either might have a list of problematic panels or can just verify with us
>    that all of the panels that their driver interacts with follow the LSB
>    preference.
>
> For the ChromeOS guys in the thread, does this sound like it could be
> workable? For the time being, I'll also send my nvidia contacts a poke to see
> what info they can give us. As well, we should probably poke Bill just in case
> he might know of some resource that documents some of the problematic panels
> out there (probably not, but it's at least worth a shot). I'll try to get
> around this today, but we might have to poke him once or twice since there
> originally was a problem with any of the emails from Red Hat getting through
> to him…
>
> >
> > I will also look into whether my specific device supports this
> > extension, and in that case I'll volunteer to implement this new
> > functionality in the driver.
> >
> > Thanks for your time,
> > Kevin
> >
> > On Tue, Sep 22, 2020 at 3:30 PM Lyude Paul <lyude@redhat.com> wrote:
> > > Hi! Since I got dropped from the thread, many responses inline
> > >
> > > On Tue, 2020-09-22 at 12:58 -0700, Puthikorn Voravootivat wrote:
> > > > +Lyude
> > > > I notice that Lyude email was somehow dropped from the thread.
> > > > Lyude was the person who submitted the patch for Thinkpad and should
> > > > know the OUI of the panel.
> > >
> > > no need - currently because of some confusion that got caused by the Intel
> > > HDR
> > > backlight interface being the only backlight interface that works properly
> > > on
> > > a lot of panels (many panels will advertise both interfaces, but might
> > > only
> > > work with the Intel one), we actually rely on a small allowlist of
> > > "approved"
> > > panels for enabling DPCD backlight control.
> > >
> > > …however, many of these panels are annoying and don't actually provide a
> > > reliable enough OUID to use for quirk detection, which is why we had to
> > > add
> > > EDID quirk detection as a temporary workaround for this. The current list
> > > of
> > > panels lives in drm_dp_helper.c:
> > >
> > > /*
> > >  * Some devices have unreliable OUIDs where they don't set the device ID
> > >  * correctly, and as a result we need to use the EDID for finding
> > > additional
> > >  * DP quirks in such cases.
> > >  */
> > > static const struct edid_quirk edid_quirk_list[] = {
> > >         /* Optional 4K AMOLED panel in the ThinkPad X1 Extreme 2nd
> > > Generation
> > >          * only supports DPCD backlight controls
> > >          */
> > >         { MFG(0x4c, 0x83), PROD_ID(0x41, 0x41),
> > > BIT(DP_QUIRK_FORCE_DPCD_BACKLIGHT) },
> > >         /*
> > >          * Some Dell CML 2020 systems have panels support both AUX and PWM
> > >          * backlight control, and some only support AUX backlight control.
> > > All
> > >          * said panels start up in AUX mode by default, and we don't have
> > > any
> > >          * support for disabling HDR mode on these panels which would be
> > >          * required to switch to PWM backlight control mode (plus, I'm not
> > >          * even sure we want PWM backlight controls over DPCD backlight
> > >          * controls anyway...). Until we have a better way of detecting
> > > these,
> > >          * force DPCD backlight mode on all of them.
> > >          */
> > >         { 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(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) },
> > > };
> > >
> > > Also note that I think just about every panel on that list supports the
> > > Intel
> > > HDR backlight interface, so it's -possible- that the VESA interface could
> > > be
> > > broken on these panels. But, that would be a lot of different panels from
> > > different vendors to all be broken in the same way.
> > >
> > > > On Tue, Sep 22, 2020 at 11:47 AM Kevin Chowski <chowski@chromium.org>
> > > > wrote:
> > > > > Alrighty, I'll take everyone else's silence as tacit approval of
> > > > > Ville's opinions. (I didn't receive any email bounces this time, so I
> > > > > think my issue was transient.) I will start on inverting the quirk and
> > > > > making the most-significant-alignment matter for these registers by
> > > > > default.
> > > > >
> > > > > Who can help me gather a list of OUIs that we need to add to the
> > > > > quirk? I can follow up with Puthikorn about the relevant Chromebooks,
> > > > > but I don't know what other types of laptops are using this driver.
> > > > >
> > > > > Thanks for your time,
> > > > > Kevin Chowski
> > > > >
> > > > >
> > > > > On Fri, Sep 18, 2020 at 12:16 PM Puthikorn Voravootivat
> > > > > <puthik@chromium.org> wrote:
> > > > > > I'll defer to Ville & Lyude.
> > > > > >
> > > > > > I dug up more on the bug report and found that both Thinkpad and
> > > > > > Galaxy Chromebook use the same Samsung OLED.
> > > > > > So my 2 vs 1 argument is actually not valid.
> > > > > >
> > > > > > On Fri, Sep 18, 2020 at 10:59 AM Kevin Chowski <chowski@chromium.org
> > > > > > >
> > > > > > wrote:
> > > > > > > Apologies once again, some of my emails were bouncing for some
> > > > > > > addresses yesterday. Hopefully it was a temporary condition; I'll
> > > > > > > continue trying to dig into it on my end if it happens again for
> > > > > > > this
> > > > > > > email.
> > > > > > >
> > > > > > > Since there's evidence that some models want lsb and some (well,
> > > > > > > at
> > > > > > > least one) want msb, my understanding is that we'll need a quirk
> > > > > > > one
> > > > > > > way or the other (please correct if I'm mistaken). I unfortunately
> > > > > > > don't have the ability to test anything other than the Pixelbook,
> > > > > > > so
> > > > > > > if we decide the msb is the "right" way, then I will have to rely
> > > > > > > on
> > > > > > > others to test (and find the OUI of) other models which require
> > > > > > > lsb.
> > > > > > >
> > > > > > > I am happy to make any changes requested, but I do not at all have
> > > > > > > enough background here to make the decision on whether the msb
> > > > > > > functionality deserves the quirk or if the lsb one does. How can I
> > > > > > > help you all come to an agreement here?
> > > > > > >
> > > > > > > * It seems like Ville feels strongly about the msb being the
> > > > > > > correct
> > > > > > > interpretation of the spec.
> > > > > > > * It's unclear to me on which side of the fence Lyude falls, I
> > > > > > > couldn't pick up a strong opinion in her clarifying question.
> > > > > > > * Puthikorn seems to be on the side of lsb being correct, but
> > > > > > > maybe
> > > > > > > was swayed by Ville's argument.
> > >
> > > Honestly I'm not hard to convince :P, if it looks like we got the bit
> > > shift
> > > wrong for the majority of devices and everyone else agrees then I'm fine
> > > with
> > > assuming that's the case. I'm just quite surprised, seeing as we've tested
> > > many different panels from a few vendors and haven't run into any issues
> > > with
> > > this before.
> > >
> > > Honestly - if there's this much uncertainty about it, maybe we should just
> > > ask
> > > VESA directly what the correct interpretation of this is? Note I'm not on
> > > the
> > > VESA board (I get access to DP/eDP specs through X.org) so unless the
> > > contacts
> > > I've got from VESA would work (Bill Lempesis bill at vesa dot org) for
> > > that it
> > > might be a better idea for someone from Google or Intel to ask.
> > >
> > > > > > > If no one feels that Ville's argument is not strong in some way,
> > > > > > > and
> > > > > > > we go with that, I will get to work on the requested changes. I am
> > > > > > > concerned, though, about changing the default functionality
> > > > > > > without
> > > > > > > testing it widely to find the set of laptops which require the lsb
> > > > > > > quirk. I'd appreciate any advice people might have about making
> > > > > > > this
> > > > > > > change safely.
> > >
> > > Usually, I just try to stick with what the majority of machines need to
> > > do. I
> > > still think it'd be a good idea for us to verify this with VESA if there's
> > > that much confusion though
> > >
> > > > > > > Thank you for your time,
> > > > > > > Kevin
> > > > > > >
> > > > > > > On Thu, Sep 17, 2020 at 2:11 PM Ville Syrjälä
> > > > > > > <ville.syrjala@linux.intel.com> wrote:
> > > > > > > > On Thu, Sep 17, 2020 at 09:25:35PM +0300, Ville Syrjälä wrote:
> > > > > > > > > On Thu, Sep 17, 2020 at 11:14:43AM -0700, Puthikorn
> > > > > > > > > Voravootivat
> > > > > > > > > wrote:
> > > > > > > > > > The Lyude fde7266fb2f6 change is actually based on Chromium
> > > > > > > > > > change
> > > > > > > > > > (https://crrev.com/c/1650325) that fixes the brightness for
> > > > > > > > > > Samsung
> > > > > > > > > > Galaxy Chromebook. So currently we have 2 examples that use
> > > > > > > > > > LSB
> > > > > > > > > > interpretation and 1 that use MSB.
> > > > > > > > >
> > > > > > > > > "If field 4:0 of the EDP_PWMGEN_BIT_COUNT register represents
> > > > > > > > > a
> > > > > > > > > value
> > > > > > > > > of greater than 8 and the BACKLIGHT_BRIGHTNESS_BYTE_COUNT bit
> > > > > > > > > is cleared to 0, only the 8 MSB of the brightness control
> > > > > > > > > value
> > > > > > > > > can be
> > > > > > > > > controlled.
> > > > > > > > > (See Note below.)
> > > > > > > > > Assigned bits are allocated to the MSB of the enabled register
> > > > > > > > > combination."
> > > > > > > > >
> > > > > > > > > I think that's pretty clear the assigned bits are supposed to
> > > > > > > > > be
> > > > > > > > > msb aligned.
> > > > > > > >
> > > > > > > > I guess there's some email issues happening, but just to
> > > > > > > > clarify:
> > > > > > > >
> > > > > > > > When the spec says MSB in caps here it clearly means
> > > > > > > > "most significant-bit(s)" since otherwise "8 MSB" would not make
> > > > > > > > any sense in the context of a 2 byte value.
> > > > > > > >
> > > > > > > > Granted the spec is crap here since "Table 1-1: Acronyms and
> > > > > > > > Initialism" does claim "MSB" should be byte(s) and "msb" bit(s).
> > > > > > > >
> > > > > > > > Also I can't imagine anyone would allocate the bits starting
> > > > > > > > from the lsb when the whole thing is clearly supposed to be a
> > > > > > > > 16bit big endian integer. So with >8 assigned bits you'd end
> > > > > > > > up with crazy stuff like this:
> > > > > > > >
> > > > > > > > [ 7 ... 0 ][7   ...   0]
> > > > > > > > [ 8 MSB   ][XXXX][N LSB]
> > > > > > > >
> > > > > > > > so you couldn't even treat the value as a regular big endian
> > > > > > > > thing. Instead, if you squint a bit, it now looks like a funky
> > > > > > > > little endian value. So we're deep into some mixed endian land
> > > > > > > > where nothing makes sense anymore.
> > > > > > > >
> > > > > > > > Anyways I think the code should simply do this to match the
> > > > > > > > spec:
> > > > > > > > u16 value = brightness << (16 - num_assigned_bits);
> > > > > > > > val[0] = value >> 8;
> > > > > > > > val[1] = value & 0xff;
> > > > > > > >
> > > > > > > >
> > > > > > > > > > On Thu, Sep 17, 2020 at 10:55 AM Kevin Chowski <
> > > > > > > > > > chowski@chromium.org> wrote:
> > > > > > > > > > > Apologies for being too vague. To be as precise I can be,
> > > > > > > > > > > here
> > > > > > > > > > > is the
> > > > > > > > > > > specific code delta I tested: https://crrev.com/c/2406616
> > > > > > > > > > > . To
> > > > > > > > > > > answer
> > > > > > > > > > > your other question, the code I tested against is indeed
> > > > > > > > > > > including the
> > > > > > > > > > > fde7266fb2f6 (despite ostensibly being called 5.4 in my
> > > > > > > > > > > commit
> > > > > > > > > > > message): our current top-of-tree for our 5.4 branch
> > > > > > > > > > > includes
> > > > > > > > > > > the
> > > > > > > > > > > intel_dp_aux_calc_max_backlight logic. Further, I'll note
> > > > > > > > > > > that
> > > > > > > > > > > change
> > > > > > > > > > > is exactly the change which breaks my Pixelbook model:
> > > > > > > > > > > prior
> > > > > > > > > > > to the
> > > > > > > > > > > change, the max_brightness was hard-coded to 0xFFFF and
> > > > > > > > > > > the
> > > > > > > > > > > math
> > > > > > > > > > > worked out that it didn't matter that the hardware cared
> > > > > > > > > > > about
> > > > > > > > > > > the MSB
> > > > > > > > > > > despite the driver code caring about the LSB.
> > > > > > > > > > >
> > > > > > > > > > > To answer Ville's question: the fde7266fb2f6 change which
> > > > > > > > > > > fixes one
> > > > > > > > > > > laptop (I believe Thinkpad X1 extreme Gen 2, from some bug
> > > > > > > > > > > reports I
> > > > > > > > > > > dug up) and breaks another (Pixelbook); so unfortunately I
> > > > > > > > > > > believe we
> > > > > > > > > > > need a quirk at least for some laptop. Reading through the
> > > > > > > > > > > copy of the
> > > > > > > > > > > datasheet I have, it wasn't clear to me which was the
> > > > > > > > > > > correct
> > > > > > > > > > > interpretation. I'm cc'ing puthik@, who was leaning toward
> > > > > > > > > > > the
> > > > > > > > > > > current
> > > > > > > > > > > kernel code (caring about LSB) being the correct
> > > > > > > > > > > interpretation. I
> > > > > > > > > > > believe we have other chromebooks which do rely on LSB
> > > > > > > > > > > functionality,
> > > > > > > > > > > so unless we can find more examples of laptops wanting MSB
> > > > > > > > > > > it
> > > > > > > > > > > currently looks like Pixelbook is the outlier.
> > > > > > > > > > >
> > > > > > > > > > > On Thu, Sep 17, 2020 at 11:28 AM Jani Nikula
> > > > > > > > > > > <jani.nikula@linux.intel.com> wrote:
> > > > > > > > > > > > On Thu, 17 Sep 2020, Kevin Chowski <chowski@chromium.org
> > > > > > > > > > > > >
> > > > > > > > > > > > wrote:
> > > > > > > > > > > > > We have observed that Google Pixelbook's backlight
> > > > > > > > > > > > > hardware is
> > > > > > > > > > > > > interpretting these backlight bits from the most-
> > > > > > > > > > > > > significant side of the
> > > > > > > > > > > > > 16 bit word (if DP_EDP_PWMGEN_BIT_COUNT < 16), whereas
> > > > > > > > > > > > > the
> > > > > > > > > > > > > driver code
> > > > > > > > > > > > > assumes the peripheral cares about the least-
> > > > > > > > > > > > > significant
> > > > > > > > > > > > > bits.
> > > > > > > > > > > > >
> > > > > > > > > > > > > Testing was done from within Chrome OS's build
> > > > > > > > > > > > > environment
> > > > > > > > > > > > > when the
> > > > > > > > > > > > > patch is backported to 5.4 (the version we are newly
> > > > > > > > > > > > > targeting for the
> > > > > > > > > > > > > Pixelbook); for the record:
> > > > > > > > > > > > >    $ emerge-eve-kernelnext sys-kernel/chromeos-kernel-
> > > > > > > > > > > > > 5_4
> > > > > > > > > > > > > && \
> > > > > > > > > > > > >       ./update_kernel.sh --remote=$IP
> > > > > > > > > > > > >
> > > > > > > > > > > > > I used `/sys/kernel/debug/dri/0/eDP-1/i915_dpcd` on my
> > > > > > > > > > > > > laptop to verify
> > > > > > > > > > > > > that the registers were being set according to what
> > > > > > > > > > > > > the
> > > > > > > > > > > > > actual hardware
> > > > > > > > > > > > > expects; I also observe that the backlight is
> > > > > > > > > > > > > noticeably
> > > > > > > > > > > > > brighter with
> > > > > > > > > > > > > this patch.
> > > > > > > > > > > >
> > > > > > > > > > > > It's unclear to me what kernel version this is against,
> > > > > > > > > > > > and
> > > > > > > > > > > > what you've
> > > > > > > > > > > > actually tested.
> > > > > > > > > > > >
> > > > > > > > > > > > Have you tried v5.7 kernel with Lyude's fde7266fb2f6
> > > > > > > > > > > > ("drm/i915: Fix eDP
> > > > > > > > > > > > DPCD aux max backlight calculations")?
> > > > > > > > > > > >
> > > > > > > > > > > > I just want to make sure you've tested with all the
> > > > > > > > > > > > relevant
> > > > > > > > > > > > fixes
> > > > > > > > > > > > before adding quirks.
> > > > > > > > > > > >
> > > > > > > > > > > > BR,
> > > > > > > > > > > > Jani.
> > > > > > > > > > > >
> > > > > > > > > > > > > Signed-off-by: Kevin Chowski <chowski@chromium.org>
> > > > > > > > > > > > > ---
> > > > > > > > > > > > >
> > > > > > > > > > > > >  .../drm/i915/display/intel_dp_aux_backlight.c | 34
> > > > > > > > > > > > > +++++++++++++++++++
> > > > > > > > > > > > >  drivers/gpu/drm/i915/display/intel_quirks.c   | 13
> > > > > > > > > > > > > +++++++
> > > > > > > > > > > > >  drivers/gpu/drm/i915/i915_drv.h               |  1 +
> > > > > > > > > > > > >  3 files changed, 48 insertions(+)
> > > > > > > > > > > > >
> > > > > > > > > > > > > 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 acbd7eb66cbe3..99c98f217356d 100644
> > > > > > > > > > > > > ---
> > > > > > > > > > > > > a/drivers/gpu/drm/i915/display/intel_dp_aux_backlight.
> > > > > > > > > > > > > c
> > > > > > > > > > > > > +++
> > > > > > > > > > > > > b/drivers/gpu/drm/i915/display/intel_dp_aux_backlight.
> > > > > > > > > > > > > c
> > > > > > > > > > > > > @@ -91,6 +91,23 @@ static u32
> > > > > > > > > > > > > intel_dp_aux_get_backlight(struct intel_connector
> > > > > > > > > > > > > *connector)
> > > > > > > > > > > > >       if (intel_dp->edp_dpcd[2] &
> > > > > > > > > > > > > DP_EDP_BACKLIGHT_BRIGHTNESS_BYTE_COUNT)
> > > > > > > > > > > > >               level = (read_val[0] << 8 |
> > > > > > > > > > > > > read_val[1]);
> > > > > > > > > > > > >
> > > > > > > > > > > > > +     if (i915->quirks &
> > > > > > > > > > > > > QUIRK_SHIFT_EDP_BACKLIGHT_BRIGHTNESS) {
> > > > > > > > > > > > > +             if (!drm_dp_dpcd_readb(&intel_dp->aux,
> > > > > > > > > > > > > DP_EDP_PWMGEN_BIT_COUNT,
> > > > > > > > > > > > > +                                             &read_va
> > > > > > > > > > > > > l[0]
> > > > > > > > > > > > > )) {
> > > > > > > > > > > > > +                     DRM_DEBUG_KMS("Failed to read
> > > > > > > > > > > > > DPCD
> > > > > > > > > > > > > register 0x%x\n",
> > > > > > > > > > > > > +                                     DP_EDP_PWMGEN_BI
> > > > > > > > > > > > > T_CO
> > > > > > > > > > > > > UNT);
> > > > > > > > > > > > > +                     return 0;
> > > > > > > > > > > > > +             }
> > > > > > > > > > > > > +             // Only bits 4:0 are used, 7:5 are
> > > > > > > > > > > > > reserved.
> > > > > > > > > > > > > +             read_val[0] = read_val[0] & 0x1F;
> > > > > > > > > > > > > +             if (read_val[0] > 16) {
> > > > > > > > > > > > > +                     DRM_DEBUG_KMS("Invalid
> > > > > > > > > > > > > DP_EDP_PWNGEN_BIT_COUNT 0x%X, expected at most 16\n",
> > > > > > > > > > > > > +                                             read_val
> > > > > > > > > > > > > [0])
> > > > > > > > > > > > > ;
> > > > > > > > > > > > > +                     return 0;
> > > > > > > > > > > > > +             }
> > > > > > > > > > > > > +             level >>= 16 - read_val[0];
> > > > > > > > > > > > > +     }
> > > > > > > > > > > > > +
> > > > > > > > > > > > >       return level;
> > > > > > > > > > > > >  }
> > > > > > > > > > > > >
> > > > > > > > > > > > > @@ -106,6 +123,23 @@ intel_dp_aux_set_backlight(const
> > > > > > > > > > > > > struct drm_connector_state *conn_state, u32 lev
> > > > > > > > > > > > >       struct drm_i915_private *i915 =
> > > > > > > > > > > > > dp_to_i915(intel_dp);
> > > > > > > > > > > > >       u8 vals[2] = { 0x0 };
> > > > > > > > > > > > >
> > > > > > > > > > > > > +     if (i915->quirks &
> > > > > > > > > > > > > QUIRK_SHIFT_EDP_BACKLIGHT_BRIGHTNESS) {
> > > > > > > > > > > > > +             if (!drm_dp_dpcd_readb(&intel_dp->aux,
> > > > > > > > > > > > > DP_EDP_PWMGEN_BIT_COUNT,
> > > > > > > > > > > > > +                                             &vals[0]
> > > > > > > > > > > > > )) {
> > > > > > > > > > > > > +                     DRM_DEBUG_KMS("Failed to write
> > > > > > > > > > > > > aux
> > > > > > > > > > > > > backlight level: Failed to read DPCD register 0x%x\n",
> > > > > > > > > > > > > +                                       DP_EDP_PWMGEN_
> > > > > > > > > > > > > BIT_
> > > > > > > > > > > > > COUNT);
> > > > > > > > > > > > > +                     return;
> > > > > > > > > > > > > +             }
> > > > > > > > > > > > > +             // Only bits 4:0 are used, 7:5 are
> > > > > > > > > > > > > reserved.
> > > > > > > > > > > > > +             vals[0] = vals[0] & 0x1F;
> > > > > > > > > > > > > +             if (vals[0] > 16) {
> > > > > > > > > > > > > +                     DRM_DEBUG_KMS("Failed to write
> > > > > > > > > > > > > aux
> > > > > > > > > > > > > backlight level: Invalid DP_EDP_PWNGEN_BIT_COUNT 0x%X,
> > > > > > > > > > > > > expected at most 16\n",
> > > > > > > > > > > > > +                                             vals[0])
> > > > > > > > > > > > > ;
> > > > > > > > > > > > > +                     return;
> > > > > > > > > > > > > +             }
> > > > > > > > > > > > > +             level <<= (16 - vals[0]) & 0xFFFF;
> > > > > > > > > > > > > +     }
> > > > > > > > > > > > > +
> > > > > > > > > > > > >       vals[0] = level;
> > > > > > > > > > > > >
> > > > > > > > > > > > >       /* Write the MSB and/or LSB */
> > > > > > > > > > > > > diff --git
> > > > > > > > > > > > > a/drivers/gpu/drm/i915/display/intel_quirks.c
> > > > > > > > > > > > > b/drivers/gpu/drm/i915/display/intel_quirks.c
> > > > > > > > > > > > > index 46beb155d835f..63b27d49b2864 100644
> > > > > > > > > > > > > --- a/drivers/gpu/drm/i915/display/intel_quirks.c
> > > > > > > > > > > > > +++ b/drivers/gpu/drm/i915/display/intel_quirks.c
> > > > > > > > > > > > > @@ -53,6 +53,16 @@ static void
> > > > > > > > > > > > > quirk_increase_ddi_disabled_time(struct
> > > > > > > > > > > > > drm_i915_private
> > > > > > > > > > > > > *i915)
> > > > > > > > > > > > >       drm_info(&i915->drm, "Applying Increase DDI
> > > > > > > > > > > > > Disabled
> > > > > > > > > > > > > quirk\n");
> > > > > > > > > > > > >  }
> > > > > > > > > > > > >
> > > > > > > > > > > > > +/*
> > > > > > > > > > > > > + * Some eDP backlight hardware uses the most-
> > > > > > > > > > > > > significant
> > > > > > > > > > > > > bits of the brightness
> > > > > > > > > > > > > + * register, so brightness values must be shifted
> > > > > > > > > > > > > first.
> > > > > > > > > > > > > + */
> > > > > > > > > > > > > +static void
> > > > > > > > > > > > > quirk_shift_edp_backlight_brightness(struct
> > > > > > > > > > > > > drm_i915_private *i915)
> > > > > > > > > > > > > +{
> > > > > > > > > > > > > +     i915->quirks |=
> > > > > > > > > > > > > QUIRK_SHIFT_EDP_BACKLIGHT_BRIGHTNESS;
> > > > > > > > > > > > > +     DRM_INFO("Applying shift eDP backlight
> > > > > > > > > > > > > brightness
> > > > > > > > > > > > > quirk\n");
> > > > > > > > > > > > > +}
> > > > > > > > > > > > > +
> > > > > > > > > > > > >  struct intel_quirk {
> > > > > > > > > > > > >       int device;
> > > > > > > > > > > > >       int subsystem_vendor;
> > > > > > > > > > > > > @@ -156,6 +166,9 @@ static struct intel_quirk
> > > > > > > > > > > > > intel_quirks[] = {
> > > > > > > > > > > > >       /* ASRock ITX*/
> > > > > > > > > > > > >       { 0x3185, 0x1849, 0x2212,
> > > > > > > > > > > > > quirk_increase_ddi_disabled_time },
> > > > > > > > > > > > >       { 0x3184, 0x1849, 0x2212,
> > > > > > > > > > > > > quirk_increase_ddi_disabled_time },
> > > > > > > > > > > > > +
> > > > > > > > > > > > > +     /* Google Pixelbook */
> > > > > > > > > > > > > +     { 0x591E, 0x8086, 0x2212,
> > > > > > > > > > > > > quirk_shift_edp_backlight_brightness },
> > > > > > > > > > > > >  };
> > > > > > > > > > > > >
> > > > > > > > > > > > >  void intel_init_quirks(struct drm_i915_private *i915)
> > > > > > > > > > > > > diff --git a/drivers/gpu/drm/i915/i915_drv.h
> > > > > > > > > > > > > b/drivers/gpu/drm/i915/i915_drv.h
> > > > > > > > > > > > > index e4f7f6518945b..cc93bede4fab8 100644
> > > > > > > > > > > > > --- a/drivers/gpu/drm/i915/i915_drv.h
> > > > > > > > > > > > > +++ b/drivers/gpu/drm/i915/i915_drv.h
> > > > > > > > > > > > > @@ -525,6 +525,7 @@ struct i915_psr {
> > > > > > > > > > > > >  #define QUIRK_PIN_SWIZZLED_PAGES (1<<5)
> > > > > > > > > > > > >  #define QUIRK_INCREASE_T12_DELAY (1<<6)
> > > > > > > > > > > > >  #define QUIRK_INCREASE_DDI_DISABLED_TIME (1<<7)
> > > > > > > > > > > > > +#define QUIRK_SHIFT_EDP_BACKLIGHT_BRIGHTNESS (1<<8)
> > > > > > > > > > > > >
> > > > > > > > > > > > >  struct intel_fbdev;
> > > > > > > > > > > > >  struct intel_fbc_work;
> > > > > > > > > > > >
> > > > > > > > > > > > --
> > > > > > > > > > > > Jani Nikula, Intel Open Source Graphics Center
> > > > > > > > >
> > > > > > > > > --
> > > > > > > > > Ville Syrjälä
> > > > > > > > > Intel
> > > > > > > > > _______________________________________________
> > > > > > > > > Intel-gfx mailing list
> > > > > > > > > Intel-gfx@lists.freedesktop.org
> > > > > > > > > https://lists.freedesktop.org/mailman/listinfo/intel-gfx
> > > > > > > >
> > > > > > > > --
> > > > > > > > Ville Syrjälä
> > > > > > > > Intel
> > > --
> > > Cheers,
> > >         Lyude Paul (she/her)
> > >         Software Engineer at Red Hat
> > >
> --
> Cheers,
>         Lyude Paul (she/her)
>         Software Engineer at Red Hat
>

Re: [Intel-gfx] [PATCH] i915: Introduce quirk for shifting eDP brightness.

[Lyude Paul]

On Tue, 2020-09-29 at 13:32 -0600, Kevin Chowski wrote:
> Thank you for the reply. And in regards to digging into it further,
> thanks for requesting that I do some more due diligence here :)
> 
> Also if you did get around to it, thanks for double-checking with
> Bill! Let me know if you'd like me to reach out instead, or if
> anything else needs to be done in this regard.
> 
> So to clarify the plan: if we do actually move forwards with leaving
> the current functionality as the default, do we need to have the
> complete list of devices which need the quirk applied when the patch
> first goes in? From my perspective, we definitely have one device
> which needs the quirk (and preferably, it'd be good to do it sooner
> than later so that we can get this bugfix out to our users) and an
> unknowable number of others. Would it be OK to introduce the quirk for
> just Pixelbook and to follow up to add others once we have that list?

Totally-I've got no problem with this.

> It may take a good amount of time for me to herd the cats inside
> Google, especially given there's a chance that there are affected
> laptops and that no one has noticed (e.g., I almost didn't notice with
> the Pixelbook). Given Lyude's analysis it seems like Chrome OS devices
> may be the largest affected group here, so I am incentivized to not
> drop the ball after fixing my immediate Pixelbook problem :)
> 
> On Fri, Sep 25, 2020 at 10:53 AM Lyude Paul <lyude@redhat.com> wrote:
> > On Thu, 2020-09-24 at 17:46 -0600, Kevin Chowski wrote:
> > > cc back a few others who were unintentionally dropped from the thread
> > > earlier.
> > > 
> > > Someone (at Google) helped me dig into this a little more and they
> > > found a document titled "eDP Backlight Brightness bit alignment" sent
> > > out for review in January 2017. I registered for a new account (google
> > > is a member) and have access to the document; here is the URL for
> > > those who also have access:
> > > https://groups.vesa.org/wg/AllMem/document/7786. For what it's worth,
> > > it seems like Lyude's contact Bill Lempesis uploaded this
> > > change-request document, so I think we can reach out to him if we have
> > > further questions. It's actually unclear to me what the status of this
> > > change request is, and whether it's been officially accepted. But I
> > > think it can be seen as some official advice on how we can move
> > > forward here.
> > > 
> > > Basically, this is a change request to the spec which acknowledges
> > > that, despite the original spec implying that the
> > > most-significant-bits were relevant here, many implementations used
> > > the least-significant-bits. In defense of most-significant it laid out
> > > some similar arguments to what Ville was saying. But it ends up
> > > saying:
> > > 
> > > > Unfortunately, the most common interpretation that we have
> > > > encountered is case 1 in the example above. TCON vendors
> > > > tend to align the valid bits to the LSBs, not the MSBs.
> > > 
> > > Instead of changing the default defined functionality (as some earlier
> > > version of this doc apparently suggested), this doc prefers to
> > > allocate two extra bits in EDP_GENERAL_CAPABILITY_2 so that future
> > > backlight devices can specify to the Source how to program them:
> > > 
> > > 00: the current functionality, i,e. no defined interpretation
> > > 01: aligned to most-significant bits
> > > 10: aligned to least-significant bits
> > > 11: reserved
> > > 
> > > It also says "[Sources] should only need panel-specific workarounds
> > > for the currently available panels."
> > > 
> > > So I believe this document is an acknowledgement of many
> > > implementations having their alignment to the least-significant bits,
> > > and (to my eyes) clearly validates that the spec "should" be the
> > > opposite. If we believe the doc's claim that "the most common
> > > interpretation" is least-significant, it seems to me that it would
> > > require more quirks if we made most-significant the default
> > > implementation.
> > > 
> > > Ville mentioned at some point earlier that we should try to match the
> > > spec, whereas Lyude mentioned we should prefer to do what the majority
> > > of machines do. What do you both think of this new development?
> > 
> > That's how displayport happens to be sometimes :). Definitely isn't the
> > first
> > time something in the spec like this got implemented incorrectly so many
> > times
> > by different vendors that they had to update the spec in response (same
> > thing
> > happened with MST and interleaved sideband messages as of DP 2.0), so I'm
> > really glad we went and actually investigated this.
> > 
> > So yes - I think a quirk for this would definitely be a good idea, and IMO
> > we
> > should always lean on the side that more panels implement even if it's not
> > according to spec - so defaulting to the behavior we currently have in the
> > kernel, and adding quirks for panels that were smart enough not to fall for
> > this would probably be the best way to go. That just leaves the challenge of
> > "how do we figure out which panels actually need this and which ones don't?"
> > 
> > This might end up being a bit of a challenge, but I've got some ideas on how
> > we might be able to tackle it to the best of our ability based off my
> > discussions with laptop vendors. It seems like some of the homegrown
> > backlight
> > interfaces might help us out here. Note I'm mentioning other laptop vendors
> > here because at least for nouveau, our plan for DPCD backlight support is to
> > move a lot of the code for handling it that currently lives in i915 into
> > shared DRM helpers (which now we'll definitely need to do as a result of
> > these
> > quirks).
> > 
> > So, on the x86 front, there's already a few different interfaces in use for
> > laptop panels:
> >  * AMD usually uses their own backlight interface, so for AMD-only laptops
> > we
> >    can probably safely ignore this
> >  * Intel uses their own DPCD backlight interface on most of the _non-
> > ChromeOS_
> >    machines on the market right now afaik based off my discussion with some
> >    laptop vendors. For panels that only come up in Intel-only machines, that
> >    means we only really need to care about the ChromeOS case here. So-if
> >    Google's able to actually survey the devices they're shipping with
> > ChromeOS
> >    right now to figure out which ones are using DPCD backlight controls, and
> >    which ones need to be MSB aligned - then I'd think we could probably
> > build
> >    an accurate quirk list of those panels easily.
> >  * This just leaves the nvidia case. Nvidia seems to be one of the only GPU
> >    vendors that didn't come up with their own backlight interface over DPCD,
> >    and they actually require that the panel support the VESA backlight
> > control
> >    interface. Incidentally, a lot of the laptops that I've force-enabled
> > VESA
> >    backlight controls on have nvidia GPUs in them, and so far every single
> > one
> >    has worked with the code we currently use in the kernel. My hope with
> > this
> >    would be that since nvidia's driver support is somewhat consistent, they
> >    either might have a list of problematic panels or can just verify with us
> >    that all of the panels that their driver interacts with follow the LSB
> >    preference.
> > 
> > For the ChromeOS guys in the thread, does this sound like it could be
> > workable? For the time being, I'll also send my nvidia contacts a poke to
> > see
> > what info they can give us. As well, we should probably poke Bill just in
> > case
> > he might know of some resource that documents some of the problematic panels
> > out there (probably not, but it's at least worth a shot). I'll try to get
> > around this today, but we might have to poke him once or twice since there
> > originally was a problem with any of the emails from Red Hat getting through
> > to him…
> > 
> > > I will also look into whether my specific device supports this
> > > extension, and in that case I'll volunteer to implement this new
> > > functionality in the driver.
> > > 
> > > Thanks for your time,
> > > Kevin
> > > 
> > > On Tue, Sep 22, 2020 at 3:30 PM Lyude Paul <lyude@redhat.com> wrote:
> > > > Hi! Since I got dropped from the thread, many responses inline
> > > > 
> > > > On Tue, 2020-09-22 at 12:58 -0700, Puthikorn Voravootivat wrote:
> > > > > +Lyude
> > > > > I notice that Lyude email was somehow dropped from the thread.
> > > > > Lyude was the person who submitted the patch for Thinkpad and should
> > > > > know the OUI of the panel.
> > > > 
> > > > no need - currently because of some confusion that got caused by the
> > > > Intel
> > > > HDR
> > > > backlight interface being the only backlight interface that works
> > > > properly
> > > > on
> > > > a lot of panels (many panels will advertise both interfaces, but might
> > > > only
> > > > work with the Intel one), we actually rely on a small allowlist of
> > > > "approved"
> > > > panels for enabling DPCD backlight control.
> > > > 
> > > > …however, many of these panels are annoying and don't actually provide a
> > > > reliable enough OUID to use for quirk detection, which is why we had to
> > > > add
> > > > EDID quirk detection as a temporary workaround for this. The current
> > > > list
> > > > of
> > > > panels lives in drm_dp_helper.c:
> > > > 
> > > > /*
> > > >  * Some devices have unreliable OUIDs where they don't set the device ID
> > > >  * correctly, and as a result we need to use the EDID for finding
> > > > additional
> > > >  * DP quirks in such cases.
> > > >  */
> > > > static const struct edid_quirk edid_quirk_list[] = {
> > > >         /* Optional 4K AMOLED panel in the ThinkPad X1 Extreme 2nd
> > > > Generation
> > > >          * only supports DPCD backlight controls
> > > >          */
> > > >         { MFG(0x4c, 0x83), PROD_ID(0x41, 0x41),
> > > > BIT(DP_QUIRK_FORCE_DPCD_BACKLIGHT) },
> > > >         /*
> > > >          * Some Dell CML 2020 systems have panels support both AUX and
> > > > PWM
> > > >          * backlight control, and some only support AUX backlight
> > > > control.
> > > > All
> > > >          * said panels start up in AUX mode by default, and we don't
> > > > have
> > > > any
> > > >          * support for disabling HDR mode on these panels which would be
> > > >          * required to switch to PWM backlight control mode (plus, I'm
> > > > not
> > > >          * even sure we want PWM backlight controls over DPCD backlight
> > > >          * controls anyway...). Until we have a better way of detecting
> > > > these,
> > > >          * force DPCD backlight mode on all of them.
> > > >          */
> > > >         { 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(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) },
> > > > };
> > > > 
> > > > Also note that I think just about every panel on that list supports the
> > > > Intel
> > > > HDR backlight interface, so it's -possible- that the VESA interface
> > > > could
> > > > be
> > > > broken on these panels. But, that would be a lot of different panels
> > > > from
> > > > different vendors to all be broken in the same way.
> > > > 
> > > > > On Tue, Sep 22, 2020 at 11:47 AM Kevin Chowski <chowski@chromium.org>
> > > > > wrote:
> > > > > > Alrighty, I'll take everyone else's silence as tacit approval of
> > > > > > Ville's opinions. (I didn't receive any email bounces this time, so
> > > > > > I
> > > > > > think my issue was transient.) I will start on inverting the quirk
> > > > > > and
> > > > > > making the most-significant-alignment matter for these registers by
> > > > > > default.
> > > > > > 
> > > > > > Who can help me gather a list of OUIs that we need to add to the
> > > > > > quirk? I can follow up with Puthikorn about the relevant
> > > > > > Chromebooks,
> > > > > > but I don't know what other types of laptops are using this driver.
> > > > > > 
> > > > > > Thanks for your time,
> > > > > > Kevin Chowski
> > > > > > 
> > > > > > 
> > > > > > On Fri, Sep 18, 2020 at 12:16 PM Puthikorn Voravootivat
> > > > > > <puthik@chromium.org> wrote:
> > > > > > > I'll defer to Ville & Lyude.
> > > > > > > 
> > > > > > > I dug up more on the bug report and found that both Thinkpad and
> > > > > > > Galaxy Chromebook use the same Samsung OLED.
> > > > > > > So my 2 vs 1 argument is actually not valid.
> > > > > > > 
> > > > > > > On Fri, Sep 18, 2020 at 10:59 AM Kevin Chowski <
> > > > > > > chowski@chromium.org
> > > > > > > wrote:
> > > > > > > > Apologies once again, some of my emails were bouncing for some
> > > > > > > > addresses yesterday. Hopefully it was a temporary condition;
> > > > > > > > I'll
> > > > > > > > continue trying to dig into it on my end if it happens again for
> > > > > > > > this
> > > > > > > > email.
> > > > > > > > 
> > > > > > > > Since there's evidence that some models want lsb and some (well,
> > > > > > > > at
> > > > > > > > least one) want msb, my understanding is that we'll need a quirk
> > > > > > > > one
> > > > > > > > way or the other (please correct if I'm mistaken). I
> > > > > > > > unfortunately
> > > > > > > > don't have the ability to test anything other than the
> > > > > > > > Pixelbook,
> > > > > > > > so
> > > > > > > > if we decide the msb is the "right" way, then I will have to
> > > > > > > > rely
> > > > > > > > on
> > > > > > > > others to test (and find the OUI of) other models which require
> > > > > > > > lsb.
> > > > > > > > 
> > > > > > > > I am happy to make any changes requested, but I do not at all
> > > > > > > > have
> > > > > > > > enough background here to make the decision on whether the msb
> > > > > > > > functionality deserves the quirk or if the lsb one does. How can
> > > > > > > > I
> > > > > > > > help you all come to an agreement here?
> > > > > > > > 
> > > > > > > > * It seems like Ville feels strongly about the msb being the
> > > > > > > > correct
> > > > > > > > interpretation of the spec.
> > > > > > > > * It's unclear to me on which side of the fence Lyude falls, I
> > > > > > > > couldn't pick up a strong opinion in her clarifying question.
> > > > > > > > * Puthikorn seems to be on the side of lsb being correct, but
> > > > > > > > maybe
> > > > > > > > was swayed by Ville's argument.
> > > > 
> > > > Honestly I'm not hard to convince :P, if it looks like we got the bit
> > > > shift
> > > > wrong for the majority of devices and everyone else agrees then I'm fine
> > > > with
> > > > assuming that's the case. I'm just quite surprised, seeing as we've
> > > > tested
> > > > many different panels from a few vendors and haven't run into any issues
> > > > with
> > > > this before.
> > > > 
> > > > Honestly - if there's this much uncertainty about it, maybe we should
> > > > just
> > > > ask
> > > > VESA directly what the correct interpretation of this is? Note I'm not
> > > > on
> > > > the
> > > > VESA board (I get access to DP/eDP specs through X.org) so unless the
> > > > contacts
> > > > I've got from VESA would work (Bill Lempesis bill at vesa dot org) for
> > > > that it
> > > > might be a better idea for someone from Google or Intel to ask.
> > > > 
> > > > > > > > If no one feels that Ville's argument is not strong in some way,
> > > > > > > > and
> > > > > > > > we go with that, I will get to work on the requested changes. I
> > > > > > > > am
> > > > > > > > concerned, though, about changing the default functionality
> > > > > > > > without
> > > > > > > > testing it widely to find the set of laptops which require the
> > > > > > > > lsb
> > > > > > > > quirk. I'd appreciate any advice people might have about making
> > > > > > > > this
> > > > > > > > change safely.
> > > > 
> > > > Usually, I just try to stick with what the majority of machines need to
> > > > do. I
> > > > still think it'd be a good idea for us to verify this with VESA if
> > > > there's
> > > > that much confusion though
> > > > 
> > > > > > > > Thank you for your time,
> > > > > > > > Kevin
> > > > > > > > 
> > > > > > > > On Thu, Sep 17, 2020 at 2:11 PM Ville Syrjälä
> > > > > > > > <ville.syrjala@linux.intel.com> wrote:
> > > > > > > > > On Thu, Sep 17, 2020 at 09:25:35PM +0300, Ville Syrjälä wrote:
> > > > > > > > > > On Thu, Sep 17, 2020 at 11:14:43AM -0700, Puthikorn
> > > > > > > > > > Voravootivat
> > > > > > > > > > wrote:
> > > > > > > > > > > The Lyude fde7266fb2f6 change is actually based on
> > > > > > > > > > > Chromium
> > > > > > > > > > > change
> > > > > > > > > > > (https://crrev.com/c/1650325) that fixes the brightness
> > > > > > > > > > > for
> > > > > > > > > > > Samsung
> > > > > > > > > > > Galaxy Chromebook. So currently we have 2 examples that
> > > > > > > > > > > use
> > > > > > > > > > > LSB
> > > > > > > > > > > interpretation and 1 that use MSB.
> > > > > > > > > > 
> > > > > > > > > > "If field 4:0 of the EDP_PWMGEN_BIT_COUNT register
> > > > > > > > > > represents
> > > > > > > > > > a
> > > > > > > > > > value
> > > > > > > > > > of greater than 8 and the BACKLIGHT_BRIGHTNESS_BYTE_COUNT
> > > > > > > > > > bit
> > > > > > > > > > is cleared to 0, only the 8 MSB of the brightness control
> > > > > > > > > > value
> > > > > > > > > > can be
> > > > > > > > > > controlled.
> > > > > > > > > > (See Note below.)
> > > > > > > > > > Assigned bits are allocated to the MSB of the enabled
> > > > > > > > > > register
> > > > > > > > > > combination."
> > > > > > > > > > 
> > > > > > > > > > I think that's pretty clear the assigned bits are supposed
> > > > > > > > > > to
> > > > > > > > > > be
> > > > > > > > > > msb aligned.
> > > > > > > > > 
> > > > > > > > > I guess there's some email issues happening, but just to
> > > > > > > > > clarify:
> > > > > > > > > 
> > > > > > > > > When the spec says MSB in caps here it clearly means
> > > > > > > > > "most significant-bit(s)" since otherwise "8 MSB" would not
> > > > > > > > > make
> > > > > > > > > any sense in the context of a 2 byte value.
> > > > > > > > > 
> > > > > > > > > Granted the spec is crap here since "Table 1-1: Acronyms and
> > > > > > > > > Initialism" does claim "MSB" should be byte(s) and "msb"
> > > > > > > > > bit(s).
> > > > > > > > > 
> > > > > > > > > Also I can't imagine anyone would allocate the bits starting
> > > > > > > > > from the lsb when the whole thing is clearly supposed to be a
> > > > > > > > > 16bit big endian integer. So with >8 assigned bits you'd end
> > > > > > > > > up with crazy stuff like this:
> > > > > > > > > 
> > > > > > > > > [ 7 ... 0 ][7   ...   0]
> > > > > > > > > [ 8 MSB   ][XXXX][N LSB]
> > > > > > > > > 
> > > > > > > > > so you couldn't even treat the value as a regular big endian
> > > > > > > > > thing. Instead, if you squint a bit, it now looks like a funky
> > > > > > > > > little endian value. So we're deep into some mixed endian land
> > > > > > > > > where nothing makes sense anymore.
> > > > > > > > > 
> > > > > > > > > Anyways I think the code should simply do this to match the
> > > > > > > > > spec:
> > > > > > > > > u16 value = brightness << (16 - num_assigned_bits);
> > > > > > > > > val[0] = value >> 8;
> > > > > > > > > val[1] = value & 0xff;
> > > > > > > > > 
> > > > > > > > > 
> > > > > > > > > > > On Thu, Sep 17, 2020 at 10:55 AM Kevin Chowski <
> > > > > > > > > > > chowski@chromium.org> wrote:
> > > > > > > > > > > > Apologies for being too vague. To be as precise I can
> > > > > > > > > > > > be,
> > > > > > > > > > > > here
> > > > > > > > > > > > is the
> > > > > > > > > > > > specific code delta I tested: 
> > > > > > > > > > > > https://crrev.com/c/2406616
> > > > > > > > > > > > . To
> > > > > > > > > > > > answer
> > > > > > > > > > > > your other question, the code I tested against is indeed
> > > > > > > > > > > > including the
> > > > > > > > > > > > fde7266fb2f6 (despite ostensibly being called 5.4 in my
> > > > > > > > > > > > commit
> > > > > > > > > > > > message): our current top-of-tree for our 5.4 branch
> > > > > > > > > > > > includes
> > > > > > > > > > > > the
> > > > > > > > > > > > intel_dp_aux_calc_max_backlight logic. Further, I'll
> > > > > > > > > > > > note
> > > > > > > > > > > > that
> > > > > > > > > > > > change
> > > > > > > > > > > > is exactly the change which breaks my Pixelbook model:
> > > > > > > > > > > > prior
> > > > > > > > > > > > to the
> > > > > > > > > > > > change, the max_brightness was hard-coded to 0xFFFF and
> > > > > > > > > > > > the
> > > > > > > > > > > > math
> > > > > > > > > > > > worked out that it didn't matter that the hardware cared
> > > > > > > > > > > > about
> > > > > > > > > > > > the MSB
> > > > > > > > > > > > despite the driver code caring about the LSB.
> > > > > > > > > > > > 
> > > > > > > > > > > > To answer Ville's question: the fde7266fb2f6 change
> > > > > > > > > > > > which
> > > > > > > > > > > > fixes one
> > > > > > > > > > > > laptop (I believe Thinkpad X1 extreme Gen 2, from some
> > > > > > > > > > > > bug
> > > > > > > > > > > > reports I
> > > > > > > > > > > > dug up) and breaks another (Pixelbook); so unfortunately
> > > > > > > > > > > > I
> > > > > > > > > > > > believe we
> > > > > > > > > > > > need a quirk at least for some laptop. Reading through
> > > > > > > > > > > > the
> > > > > > > > > > > > copy of the
> > > > > > > > > > > > datasheet I have, it wasn't clear to me which was the
> > > > > > > > > > > > correct
> > > > > > > > > > > > interpretation. I'm cc'ing puthik@, who was leaning
> > > > > > > > > > > > toward
> > > > > > > > > > > > the
> > > > > > > > > > > > current
> > > > > > > > > > > > kernel code (caring about LSB) being the correct
> > > > > > > > > > > > interpretation. I
> > > > > > > > > > > > believe we have other chromebooks which do rely on LSB
> > > > > > > > > > > > functionality,
> > > > > > > > > > > > so unless we can find more examples of laptops wanting
> > > > > > > > > > > > MSB
> > > > > > > > > > > > it
> > > > > > > > > > > > currently looks like Pixelbook is the outlier.
> > > > > > > > > > > > 
> > > > > > > > > > > > On Thu, Sep 17, 2020 at 11:28 AM Jani Nikula
> > > > > > > > > > > > <jani.nikula@linux.intel.com> wrote:
> > > > > > > > > > > > > On Thu, 17 Sep 2020, Kevin Chowski <
> > > > > > > > > > > > > chowski@chromium.org
> > > > > > > > > > > > > wrote:
> > > > > > > > > > > > > > We have observed that Google Pixelbook's backlight
> > > > > > > > > > > > > > hardware is
> > > > > > > > > > > > > > interpretting these backlight bits from the most-
> > > > > > > > > > > > > > significant side of the
> > > > > > > > > > > > > > 16 bit word (if DP_EDP_PWMGEN_BIT_COUNT < 16),
> > > > > > > > > > > > > > whereas
> > > > > > > > > > > > > > the
> > > > > > > > > > > > > > driver code
> > > > > > > > > > > > > > assumes the peripheral cares about the least-
> > > > > > > > > > > > > > significant
> > > > > > > > > > > > > > bits.
> > > > > > > > > > > > > > 
> > > > > > > > > > > > > > Testing was done from within Chrome OS's build
> > > > > > > > > > > > > > environment
> > > > > > > > > > > > > > when the
> > > > > > > > > > > > > > patch is backported to 5.4 (the version we are newly
> > > > > > > > > > > > > > targeting for the
> > > > > > > > > > > > > > Pixelbook); for the record:
> > > > > > > > > > > > > >    $ emerge-eve-kernelnext sys-kernel/chromeos-
> > > > > > > > > > > > > > kernel-
> > > > > > > > > > > > > > 5_4
> > > > > > > > > > > > > > && \
> > > > > > > > > > > > > >       ./update_kernel.sh --remote=$IP
> > > > > > > > > > > > > > 
> > > > > > > > > > > > > > I used `/sys/kernel/debug/dri/0/eDP-1/i915_dpcd` on
> > > > > > > > > > > > > > my
> > > > > > > > > > > > > > laptop to verify
> > > > > > > > > > > > > > that the registers were being set according to what
> > > > > > > > > > > > > > the
> > > > > > > > > > > > > > actual hardware
> > > > > > > > > > > > > > expects; I also observe that the backlight is
> > > > > > > > > > > > > > noticeably
> > > > > > > > > > > > > > brighter with
> > > > > > > > > > > > > > this patch.
> > > > > > > > > > > > > 
> > > > > > > > > > > > > It's unclear to me what kernel version this is
> > > > > > > > > > > > > against,
> > > > > > > > > > > > > and
> > > > > > > > > > > > > what you've
> > > > > > > > > > > > > actually tested.
> > > > > > > > > > > > > 
> > > > > > > > > > > > > Have you tried v5.7 kernel with Lyude's fde7266fb2f6
> > > > > > > > > > > > > ("drm/i915: Fix eDP
> > > > > > > > > > > > > DPCD aux max backlight calculations")?
> > > > > > > > > > > > > 
> > > > > > > > > > > > > I just want to make sure you've tested with all the
> > > > > > > > > > > > > relevant
> > > > > > > > > > > > > fixes
> > > > > > > > > > > > > before adding quirks.
> > > > > > > > > > > > > 
> > > > > > > > > > > > > BR,
> > > > > > > > > > > > > Jani.
> > > > > > > > > > > > > 
> > > > > > > > > > > > > > Signed-off-by: Kevin Chowski <chowski@chromium.org>
> > > > > > > > > > > > > > ---
> > > > > > > > > > > > > > 
> > > > > > > > > > > > > >  .../drm/i915/display/intel_dp_aux_backlight.c | 34
> > > > > > > > > > > > > > +++++++++++++++++++
> > > > > > > > > > > > > >  drivers/gpu/drm/i915/display/intel_quirks.c   | 13
> > > > > > > > > > > > > > +++++++
> > > > > > > > > > > > > >  drivers/gpu/drm/i915/i915_drv.h               |  1
> > > > > > > > > > > > > > +
> > > > > > > > > > > > > >  3 files changed, 48 insertions(+)
> > > > > > > > > > > > > > 
> > > > > > > > > > > > > > diff --git
> > > > > > > > > > > > > > a/drivers/gpu/drm/i915/display/intel_dp_aux_backligh
> > > > > > > > > > > > > > t.
> > > > > > > > > > > > > > c
> > > > > > > > > > > > > > b/drivers/gpu/drm/i915/display/intel_dp_aux_backligh
> > > > > > > > > > > > > > t.
> > > > > > > > > > > > > > c
> > > > > > > > > > > > > > index acbd7eb66cbe3..99c98f217356d 100644
> > > > > > > > > > > > > > ---
> > > > > > > > > > > > > > a/drivers/gpu/drm/i915/display/intel_dp_aux_backligh
> > > > > > > > > > > > > > t.
> > > > > > > > > > > > > > c
> > > > > > > > > > > > > > +++
> > > > > > > > > > > > > > b/drivers/gpu/drm/i915/display/intel_dp_aux_backligh
> > > > > > > > > > > > > > t.
> > > > > > > > > > > > > > c
> > > > > > > > > > > > > > @@ -91,6 +91,23 @@ static u32
> > > > > > > > > > > > > > intel_dp_aux_get_backlight(struct intel_connector
> > > > > > > > > > > > > > *connector)
> > > > > > > > > > > > > >       if (intel_dp->edp_dpcd[2] &
> > > > > > > > > > > > > > DP_EDP_BACKLIGHT_BRIGHTNESS_BYTE_COUNT)
> > > > > > > > > > > > > >               level = (read_val[0] << 8 |
> > > > > > > > > > > > > > read_val[1]);
> > > > > > > > > > > > > > 
> > > > > > > > > > > > > > +     if (i915->quirks &
> > > > > > > > > > > > > > QUIRK_SHIFT_EDP_BACKLIGHT_BRIGHTNESS) {
> > > > > > > > > > > > > > +             if (!drm_dp_dpcd_readb(&intel_dp->aux,
> > > > > > > > > > > > > > DP_EDP_PWMGEN_BIT_COUNT,
> > > > > > > > > > > > > > +                                             &read_
> > > > > > > > > > > > > > va
> > > > > > > > > > > > > > l[0]
> > > > > > > > > > > > > > )) {
> > > > > > > > > > > > > > +                     DRM_DEBUG_KMS("Failed to read
> > > > > > > > > > > > > > DPCD
> > > > > > > > > > > > > > register 0x%x\n",
> > > > > > > > > > > > > > +                                     DP_EDP_PWMGEN_
> > > > > > > > > > > > > > BI
> > > > > > > > > > > > > > T_CO
> > > > > > > > > > > > > > UNT);
> > > > > > > > > > > > > > +                     return 0;
> > > > > > > > > > > > > > +             }
> > > > > > > > > > > > > > +             // Only bits 4:0 are used, 7:5 are
> > > > > > > > > > > > > > reserved.
> > > > > > > > > > > > > > +             read_val[0] = read_val[0] & 0x1F;
> > > > > > > > > > > > > > +             if (read_val[0] > 16) {
> > > > > > > > > > > > > > +                     DRM_DEBUG_KMS("Invalid
> > > > > > > > > > > > > > DP_EDP_PWNGEN_BIT_COUNT 0x%X, expected at most
> > > > > > > > > > > > > > 16\n",
> > > > > > > > > > > > > > +                                             read_v
> > > > > > > > > > > > > > al
> > > > > > > > > > > > > > [0])
> > > > > > > > > > > > > > ;
> > > > > > > > > > > > > > +                     return 0;
> > > > > > > > > > > > > > +             }
> > > > > > > > > > > > > > +             level >>= 16 - read_val[0];
> > > > > > > > > > > > > > +     }
> > > > > > > > > > > > > > +
> > > > > > > > > > > > > >       return level;
> > > > > > > > > > > > > >  }
> > > > > > > > > > > > > > 
> > > > > > > > > > > > > > @@ -106,6 +123,23 @@
> > > > > > > > > > > > > > intel_dp_aux_set_backlight(const
> > > > > > > > > > > > > > struct drm_connector_state *conn_state, u32 lev
> > > > > > > > > > > > > >       struct drm_i915_private *i915 =
> > > > > > > > > > > > > > dp_to_i915(intel_dp);
> > > > > > > > > > > > > >       u8 vals[2] = { 0x0 };
> > > > > > > > > > > > > > 
> > > > > > > > > > > > > > +     if (i915->quirks &
> > > > > > > > > > > > > > QUIRK_SHIFT_EDP_BACKLIGHT_BRIGHTNESS) {
> > > > > > > > > > > > > > +             if (!drm_dp_dpcd_readb(&intel_dp->aux,
> > > > > > > > > > > > > > DP_EDP_PWMGEN_BIT_COUNT,
> > > > > > > > > > > > > > +                                             &vals[
> > > > > > > > > > > > > > 0]
> > > > > > > > > > > > > > )) {
> > > > > > > > > > > > > > +                     DRM_DEBUG_KMS("Failed to write
> > > > > > > > > > > > > > aux
> > > > > > > > > > > > > > backlight level: Failed to read DPCD register
> > > > > > > > > > > > > > 0x%x\n",
> > > > > > > > > > > > > > +                                       DP_EDP_PWMGE
> > > > > > > > > > > > > > N_
> > > > > > > > > > > > > > BIT_
> > > > > > > > > > > > > > COUNT);
> > > > > > > > > > > > > > +                     return;
> > > > > > > > > > > > > > +             }
> > > > > > > > > > > > > > +             // Only bits 4:0 are used, 7:5 are
> > > > > > > > > > > > > > reserved.
> > > > > > > > > > > > > > +             vals[0] = vals[0] & 0x1F;
> > > > > > > > > > > > > > +             if (vals[0] > 16) {
> > > > > > > > > > > > > > +                     DRM_DEBUG_KMS("Failed to write
> > > > > > > > > > > > > > aux
> > > > > > > > > > > > > > backlight level: Invalid DP_EDP_PWNGEN_BIT_COUNT
> > > > > > > > > > > > > > 0x%X,
> > > > > > > > > > > > > > expected at most 16\n",
> > > > > > > > > > > > > > +                                             vals[0
> > > > > > > > > > > > > > ])
> > > > > > > > > > > > > > ;
> > > > > > > > > > > > > > +                     return;
> > > > > > > > > > > > > > +             }
> > > > > > > > > > > > > > +             level <<= (16 - vals[0]) & 0xFFFF;
> > > > > > > > > > > > > > +     }
> > > > > > > > > > > > > > +
> > > > > > > > > > > > > >       vals[0] = level;
> > > > > > > > > > > > > > 
> > > > > > > > > > > > > >       /* Write the MSB and/or LSB */
> > > > > > > > > > > > > > diff --git
> > > > > > > > > > > > > > a/drivers/gpu/drm/i915/display/intel_quirks.c
> > > > > > > > > > > > > > b/drivers/gpu/drm/i915/display/intel_quirks.c
> > > > > > > > > > > > > > index 46beb155d835f..63b27d49b2864 100644
> > > > > > > > > > > > > > --- a/drivers/gpu/drm/i915/display/intel_quirks.c
> > > > > > > > > > > > > > +++ b/drivers/gpu/drm/i915/display/intel_quirks.c
> > > > > > > > > > > > > > @@ -53,6 +53,16 @@ static void
> > > > > > > > > > > > > > quirk_increase_ddi_disabled_time(struct
> > > > > > > > > > > > > > drm_i915_private
> > > > > > > > > > > > > > *i915)
> > > > > > > > > > > > > >       drm_info(&i915->drm, "Applying Increase DDI
> > > > > > > > > > > > > > Disabled
> > > > > > > > > > > > > > quirk\n");
> > > > > > > > > > > > > >  }
> > > > > > > > > > > > > > 
> > > > > > > > > > > > > > +/*
> > > > > > > > > > > > > > + * Some eDP backlight hardware uses the most-
> > > > > > > > > > > > > > significant
> > > > > > > > > > > > > > bits of the brightness
> > > > > > > > > > > > > > + * register, so brightness values must be shifted
> > > > > > > > > > > > > > first.
> > > > > > > > > > > > > > + */
> > > > > > > > > > > > > > +static void
> > > > > > > > > > > > > > quirk_shift_edp_backlight_brightness(struct
> > > > > > > > > > > > > > drm_i915_private *i915)
> > > > > > > > > > > > > > +{
> > > > > > > > > > > > > > +     i915->quirks |=
> > > > > > > > > > > > > > QUIRK_SHIFT_EDP_BACKLIGHT_BRIGHTNESS;
> > > > > > > > > > > > > > +     DRM_INFO("Applying shift eDP backlight
> > > > > > > > > > > > > > brightness
> > > > > > > > > > > > > > quirk\n");
> > > > > > > > > > > > > > +}
> > > > > > > > > > > > > > +
> > > > > > > > > > > > > >  struct intel_quirk {
> > > > > > > > > > > > > >       int device;
> > > > > > > > > > > > > >       int subsystem_vendor;
> > > > > > > > > > > > > > @@ -156,6 +166,9 @@ static struct intel_quirk
> > > > > > > > > > > > > > intel_quirks[] = {
> > > > > > > > > > > > > >       /* ASRock ITX*/
> > > > > > > > > > > > > >       { 0x3185, 0x1849, 0x2212,
> > > > > > > > > > > > > > quirk_increase_ddi_disabled_time },
> > > > > > > > > > > > > >       { 0x3184, 0x1849, 0x2212,
> > > > > > > > > > > > > > quirk_increase_ddi_disabled_time },
> > > > > > > > > > > > > > +
> > > > > > > > > > > > > > +     /* Google Pixelbook */
> > > > > > > > > > > > > > +     { 0x591E, 0x8086, 0x2212,
> > > > > > > > > > > > > > quirk_shift_edp_backlight_brightness },
> > > > > > > > > > > > > >  };
> > > > > > > > > > > > > > 
> > > > > > > > > > > > > >  void intel_init_quirks(struct drm_i915_private
> > > > > > > > > > > > > > *i915)
> > > > > > > > > > > > > > diff --git a/drivers/gpu/drm/i915/i915_drv.h
> > > > > > > > > > > > > > b/drivers/gpu/drm/i915/i915_drv.h
> > > > > > > > > > > > > > index e4f7f6518945b..cc93bede4fab8 100644
> > > > > > > > > > > > > > --- a/drivers/gpu/drm/i915/i915_drv.h
> > > > > > > > > > > > > > +++ b/drivers/gpu/drm/i915/i915_drv.h
> > > > > > > > > > > > > > @@ -525,6 +525,7 @@ struct i915_psr {
> > > > > > > > > > > > > >  #define QUIRK_PIN_SWIZZLED_PAGES (1<<5)
> > > > > > > > > > > > > >  #define QUIRK_INCREASE_T12_DELAY (1<<6)
> > > > > > > > > > > > > >  #define QUIRK_INCREASE_DDI_DISABLED_TIME (1<<7)
> > > > > > > > > > > > > > +#define QUIRK_SHIFT_EDP_BACKLIGHT_BRIGHTNESS (1<<8)
> > > > > > > > > > > > > > 
> > > > > > > > > > > > > >  struct intel_fbdev;
> > > > > > > > > > > > > >  struct intel_fbc_work;
> > > > > > > > > > > > > 
> > > > > > > > > > > > > --
> > > > > > > > > > > > > Jani Nikula, Intel Open Source Graphics Center
> > > > > > > > > > 
> > > > > > > > > > --
> > > > > > > > > > Ville Syrjälä
> > > > > > > > > > Intel
> > > > > > > > > > _______________________________________________
> > > > > > > > > > Intel-gfx mailing list
> > > > > > > > > > Intel-gfx@lists.freedesktop.org
> > > > > > > > > > https://lists.freedesktop.org/mailman/listinfo/intel-gfx
> > > > > > > > > 
> > > > > > > > > --
> > > > > > > > > Ville Syrjälä
> > > > > > > > > Intel
> > > > --
> > > > Cheers,
> > > >         Lyude Paul (she/her)
> > > >         Software Engineer at Red Hat
> > > > 
> > --
> > Cheers,
> >         Lyude Paul (she/her)
> >         Software Engineer at Red Hat
> > 
-- 
Sincerely,
      Lyude Paul (she/her)
      Software Engineer at Red Hat

Re: [Intel-gfx] [PATCH] i915: Introduce quirk for shifting eDP brightness.

[Lyude Paul]

On Wed, 2020-09-30 at 16:25 -0400, Lyude Paul wrote:
> On Tue, 2020-09-29 at 13:32 -0600, Kevin Chowski wrote:
> > Thank you for the reply. And in regards to digging into it further,
> > thanks for requesting that I do some more due diligence here :)
> > 
> > Also if you did get around to it, thanks for double-checking with
> > Bill! Let me know if you'd like me to reach out instead, or if
> > anything else needs to be done in this regard.
> > 
> > So to clarify the plan: if we do actually move forwards with leaving
> > the current functionality as the default, do we need to have the
> > complete list of devices which need the quirk applied when the patch
> > first goes in? From my perspective, we definitely have one device
> > which needs the quirk (and preferably, it'd be good to do it sooner
> > than later so that we can get this bugfix out to our users) and an
> > unknowable number of others. Would it be OK to introduce the quirk for
> > just Pixelbook and to follow up to add others once we have that list?
> 
> Totally-I've got no problem with this.

oh-regarding Bill, yeah it might help a bit if you guys messaged them since I'm
not in the vesa WG, I just have access to some specs from there
> 
> > It may take a good amount of time for me to herd the cats inside
> > Google, especially given there's a chance that there are affected
> > laptops and that no one has noticed (e.g., I almost didn't notice with
> > the Pixelbook). Given Lyude's analysis it seems like Chrome OS devices
> > may be the largest affected group here, so I am incentivized to not
> > drop the ball after fixing my immediate Pixelbook problem :)
> > 
> > On Fri, Sep 25, 2020 at 10:53 AM Lyude Paul <lyude@redhat.com> wrote:
> > > On Thu, 2020-09-24 at 17:46 -0600, Kevin Chowski wrote:
> > > > cc back a few others who were unintentionally dropped from the thread
> > > > earlier.
> > > > 
> > > > Someone (at Google) helped me dig into this a little more and they
> > > > found a document titled "eDP Backlight Brightness bit alignment" sent
> > > > out for review in January 2017. I registered for a new account (google
> > > > is a member) and have access to the document; here is the URL for
> > > > those who also have access:
> > > > https://groups.vesa.org/wg/AllMem/document/7786. For what it's worth,
> > > > it seems like Lyude's contact Bill Lempesis uploaded this
> > > > change-request document, so I think we can reach out to him if we have
> > > > further questions. It's actually unclear to me what the status of this
> > > > change request is, and whether it's been officially accepted. But I
> > > > think it can be seen as some official advice on how we can move
> > > > forward here.
> > > > 
> > > > Basically, this is a change request to the spec which acknowledges
> > > > that, despite the original spec implying that the
> > > > most-significant-bits were relevant here, many implementations used
> > > > the least-significant-bits. In defense of most-significant it laid out
> > > > some similar arguments to what Ville was saying. But it ends up
> > > > saying:
> > > > 
> > > > > Unfortunately, the most common interpretation that we have
> > > > > encountered is case 1 in the example above. TCON vendors
> > > > > tend to align the valid bits to the LSBs, not the MSBs.
> > > > 
> > > > Instead of changing the default defined functionality (as some earlier
> > > > version of this doc apparently suggested), this doc prefers to
> > > > allocate two extra bits in EDP_GENERAL_CAPABILITY_2 so that future
> > > > backlight devices can specify to the Source how to program them:
> > > > 
> > > > 00: the current functionality, i,e. no defined interpretation
> > > > 01: aligned to most-significant bits
> > > > 10: aligned to least-significant bits
> > > > 11: reserved
> > > > 
> > > > It also says "[Sources] should only need panel-specific workarounds
> > > > for the currently available panels."
> > > > 
> > > > So I believe this document is an acknowledgement of many
> > > > implementations having their alignment to the least-significant bits,
> > > > and (to my eyes) clearly validates that the spec "should" be the
> > > > opposite. If we believe the doc's claim that "the most common
> > > > interpretation" is least-significant, it seems to me that it would
> > > > require more quirks if we made most-significant the default
> > > > implementation.
> > > > 
> > > > Ville mentioned at some point earlier that we should try to match the
> > > > spec, whereas Lyude mentioned we should prefer to do what the majority
> > > > of machines do. What do you both think of this new development?
> > > 
> > > That's how displayport happens to be sometimes :). Definitely isn't the
> > > first
> > > time something in the spec like this got implemented incorrectly so many
> > > times
> > > by different vendors that they had to update the spec in response (same
> > > thing
> > > happened with MST and interleaved sideband messages as of DP 2.0), so I'm
> > > really glad we went and actually investigated this.
> > > 
> > > So yes - I think a quirk for this would definitely be a good idea, and IMO
> > > we
> > > should always lean on the side that more panels implement even if it's not
> > > according to spec - so defaulting to the behavior we currently have in the
> > > kernel, and adding quirks for panels that were smart enough not to fall
> > > for
> > > this would probably be the best way to go. That just leaves the challenge
> > > of
> > > "how do we figure out which panels actually need this and which ones
> > > don't?"
> > > 
> > > This might end up being a bit of a challenge, but I've got some ideas on
> > > how
> > > we might be able to tackle it to the best of our ability based off my
> > > discussions with laptop vendors. It seems like some of the homegrown
> > > backlight
> > > interfaces might help us out here. Note I'm mentioning other laptop
> > > vendors
> > > here because at least for nouveau, our plan for DPCD backlight support is
> > > to
> > > move a lot of the code for handling it that currently lives in i915 into
> > > shared DRM helpers (which now we'll definitely need to do as a result of
> > > these
> > > quirks).
> > > 
> > > So, on the x86 front, there's already a few different interfaces in use
> > > for
> > > laptop panels:
> > >  * AMD usually uses their own backlight interface, so for AMD-only laptops
> > > we
> > >    can probably safely ignore this
> > >  * Intel uses their own DPCD backlight interface on most of the _non-
> > > ChromeOS_
> > >    machines on the market right now afaik based off my discussion with
> > > some
> > >    laptop vendors. For panels that only come up in Intel-only machines,
> > > that
> > >    means we only really need to care about the ChromeOS case here. So-if
> > >    Google's able to actually survey the devices they're shipping with
> > > ChromeOS
> > >    right now to figure out which ones are using DPCD backlight controls,
> > > and
> > >    which ones need to be MSB aligned - then I'd think we could probably
> > > build
> > >    an accurate quirk list of those panels easily.
> > >  * This just leaves the nvidia case. Nvidia seems to be one of the only
> > > GPU
> > >    vendors that didn't come up with their own backlight interface over
> > > DPCD,
> > >    and they actually require that the panel support the VESA backlight
> > > control
> > >    interface. Incidentally, a lot of the laptops that I've force-enabled
> > > VESA
> > >    backlight controls on have nvidia GPUs in them, and so far every single
> > > one
> > >    has worked with the code we currently use in the kernel. My hope with
> > > this
> > >    would be that since nvidia's driver support is somewhat consistent,
> > > they
> > >    either might have a list of problematic panels or can just verify with
> > > us
> > >    that all of the panels that their driver interacts with follow the LSB
> > >    preference.
> > > 
> > > For the ChromeOS guys in the thread, does this sound like it could be
> > > workable? For the time being, I'll also send my nvidia contacts a poke to
> > > see
> > > what info they can give us. As well, we should probably poke Bill just in
> > > case
> > > he might know of some resource that documents some of the problematic
> > > panels
> > > out there (probably not, but it's at least worth a shot). I'll try to get
> > > around this today, but we might have to poke him once or twice since there
> > > originally was a problem with any of the emails from Red Hat getting
> > > through
> > > to him…
> > > 
> > > > I will also look into whether my specific device supports this
> > > > extension, and in that case I'll volunteer to implement this new
> > > > functionality in the driver.
> > > > 
> > > > Thanks for your time,
> > > > Kevin
> > > > 
> > > > On Tue, Sep 22, 2020 at 3:30 PM Lyude Paul <lyude@redhat.com> wrote:
> > > > > Hi! Since I got dropped from the thread, many responses inline
> > > > > 
> > > > > On Tue, 2020-09-22 at 12:58 -0700, Puthikorn Voravootivat wrote:
> > > > > > +Lyude
> > > > > > I notice that Lyude email was somehow dropped from the thread.
> > > > > > Lyude was the person who submitted the patch for Thinkpad and should
> > > > > > know the OUI of the panel.
> > > > > 
> > > > > no need - currently because of some confusion that got caused by the
> > > > > Intel
> > > > > HDR
> > > > > backlight interface being the only backlight interface that works
> > > > > properly
> > > > > on
> > > > > a lot of panels (many panels will advertise both interfaces, but might
> > > > > only
> > > > > work with the Intel one), we actually rely on a small allowlist of
> > > > > "approved"
> > > > > panels for enabling DPCD backlight control.
> > > > > 
> > > > > …however, many of these panels are annoying and don't actually provide
> > > > > a
> > > > > reliable enough OUID to use for quirk detection, which is why we had
> > > > > to
> > > > > add
> > > > > EDID quirk detection as a temporary workaround for this. The current
> > > > > list
> > > > > of
> > > > > panels lives in drm_dp_helper.c:
> > > > > 
> > > > > /*
> > > > >  * Some devices have unreliable OUIDs where they don't set the device
> > > > > ID
> > > > >  * correctly, and as a result we need to use the EDID for finding
> > > > > additional
> > > > >  * DP quirks in such cases.
> > > > >  */
> > > > > static const struct edid_quirk edid_quirk_list[] = {
> > > > >         /* Optional 4K AMOLED panel in the ThinkPad X1 Extreme 2nd
> > > > > Generation
> > > > >          * only supports DPCD backlight controls
> > > > >          */
> > > > >         { MFG(0x4c, 0x83), PROD_ID(0x41, 0x41),
> > > > > BIT(DP_QUIRK_FORCE_DPCD_BACKLIGHT) },
> > > > >         /*
> > > > >          * Some Dell CML 2020 systems have panels support both AUX and
> > > > > PWM
> > > > >          * backlight control, and some only support AUX backlight
> > > > > control.
> > > > > All
> > > > >          * said panels start up in AUX mode by default, and we don't
> > > > > have
> > > > > any
> > > > >          * support for disabling HDR mode on these panels which would
> > > > > be
> > > > >          * required to switch to PWM backlight control mode (plus, I'm
> > > > > not
> > > > >          * even sure we want PWM backlight controls over DPCD
> > > > > backlight
> > > > >          * controls anyway...). Until we have a better way of
> > > > > detecting
> > > > > these,
> > > > >          * force DPCD backlight mode on all of them.
> > > > >          */
> > > > >         { 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(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) },
> > > > > };
> > > > > 
> > > > > Also note that I think just about every panel on that list supports
> > > > > the
> > > > > Intel
> > > > > HDR backlight interface, so it's -possible- that the VESA interface
> > > > > could
> > > > > be
> > > > > broken on these panels. But, that would be a lot of different panels
> > > > > from
> > > > > different vendors to all be broken in the same way.
> > > > > 
> > > > > > On Tue, Sep 22, 2020 at 11:47 AM Kevin Chowski <chowski@chromium.org
> > > > > > >
> > > > > > wrote:
> > > > > > > Alrighty, I'll take everyone else's silence as tacit approval of
> > > > > > > Ville's opinions. (I didn't receive any email bounces this time,
> > > > > > > so
> > > > > > > I
> > > > > > > think my issue was transient.) I will start on inverting the quirk
> > > > > > > and
> > > > > > > making the most-significant-alignment matter for these registers
> > > > > > > by
> > > > > > > default.
> > > > > > > 
> > > > > > > Who can help me gather a list of OUIs that we need to add to the
> > > > > > > quirk? I can follow up with Puthikorn about the relevant
> > > > > > > Chromebooks,
> > > > > > > but I don't know what other types of laptops are using this
> > > > > > > driver.
> > > > > > > 
> > > > > > > Thanks for your time,
> > > > > > > Kevin Chowski
> > > > > > > 
> > > > > > > 
> > > > > > > On Fri, Sep 18, 2020 at 12:16 PM Puthikorn Voravootivat
> > > > > > > <puthik@chromium.org> wrote:
> > > > > > > > I'll defer to Ville & Lyude.
> > > > > > > > 
> > > > > > > > I dug up more on the bug report and found that both Thinkpad and
> > > > > > > > Galaxy Chromebook use the same Samsung OLED.
> > > > > > > > So my 2 vs 1 argument is actually not valid.
> > > > > > > > 
> > > > > > > > On Fri, Sep 18, 2020 at 10:59 AM Kevin Chowski <
> > > > > > > > chowski@chromium.org
> > > > > > > > wrote:
> > > > > > > > > Apologies once again, some of my emails were bouncing for some
> > > > > > > > > addresses yesterday. Hopefully it was a temporary condition;
> > > > > > > > > I'll
> > > > > > > > > continue trying to dig into it on my end if it happens again
> > > > > > > > > for
> > > > > > > > > this
> > > > > > > > > email.
> > > > > > > > > 
> > > > > > > > > Since there's evidence that some models want lsb and some
> > > > > > > > > (well,
> > > > > > > > > at
> > > > > > > > > least one) want msb, my understanding is that we'll need a
> > > > > > > > > quirk
> > > > > > > > > one
> > > > > > > > > way or the other (please correct if I'm mistaken). I
> > > > > > > > > unfortunately
> > > > > > > > > don't have the ability to test anything other than the
> > > > > > > > > Pixelbook,
> > > > > > > > > so
> > > > > > > > > if we decide the msb is the "right" way, then I will have to
> > > > > > > > > rely
> > > > > > > > > on
> > > > > > > > > others to test (and find the OUI of) other models which
> > > > > > > > > require
> > > > > > > > > lsb.
> > > > > > > > > 
> > > > > > > > > I am happy to make any changes requested, but I do not at all
> > > > > > > > > have
> > > > > > > > > enough background here to make the decision on whether the msb
> > > > > > > > > functionality deserves the quirk or if the lsb one does. How
> > > > > > > > > can
> > > > > > > > > I
> > > > > > > > > help you all come to an agreement here?
> > > > > > > > > 
> > > > > > > > > * It seems like Ville feels strongly about the msb being the
> > > > > > > > > correct
> > > > > > > > > interpretation of the spec.
> > > > > > > > > * It's unclear to me on which side of the fence Lyude falls, I
> > > > > > > > > couldn't pick up a strong opinion in her clarifying question.
> > > > > > > > > * Puthikorn seems to be on the side of lsb being correct, but
> > > > > > > > > maybe
> > > > > > > > > was swayed by Ville's argument.
> > > > > 
> > > > > Honestly I'm not hard to convince :P, if it looks like we got the bit
> > > > > shift
> > > > > wrong for the majority of devices and everyone else agrees then I'm
> > > > > fine
> > > > > with
> > > > > assuming that's the case. I'm just quite surprised, seeing as we've
> > > > > tested
> > > > > many different panels from a few vendors and haven't run into any
> > > > > issues
> > > > > with
> > > > > this before.
> > > > > 
> > > > > Honestly - if there's this much uncertainty about it, maybe we should
> > > > > just
> > > > > ask
> > > > > VESA directly what the correct interpretation of this is? Note I'm not
> > > > > on
> > > > > the
> > > > > VESA board (I get access to DP/eDP specs through X.org) so unless the
> > > > > contacts
> > > > > I've got from VESA would work (Bill Lempesis bill at vesa dot org) for
> > > > > that it
> > > > > might be a better idea for someone from Google or Intel to ask.
> > > > > 
> > > > > > > > > If no one feels that Ville's argument is not strong in some
> > > > > > > > > way,
> > > > > > > > > and
> > > > > > > > > we go with that, I will get to work on the requested changes.
> > > > > > > > > I
> > > > > > > > > am
> > > > > > > > > concerned, though, about changing the default functionality
> > > > > > > > > without
> > > > > > > > > testing it widely to find the set of laptops which require the
> > > > > > > > > lsb
> > > > > > > > > quirk. I'd appreciate any advice people might have about
> > > > > > > > > making
> > > > > > > > > this
> > > > > > > > > change safely.
> > > > > 
> > > > > Usually, I just try to stick with what the majority of machines need
> > > > > to
> > > > > do. I
> > > > > still think it'd be a good idea for us to verify this with VESA if
> > > > > there's
> > > > > that much confusion though
> > > > > 
> > > > > > > > > Thank you for your time,
> > > > > > > > > Kevin
> > > > > > > > > 
> > > > > > > > > On Thu, Sep 17, 2020 at 2:11 PM Ville Syrjälä
> > > > > > > > > <ville.syrjala@linux.intel.com> wrote:
> > > > > > > > > > On Thu, Sep 17, 2020 at 09:25:35PM +0300, Ville Syrjälä
> > > > > > > > > > wrote:
> > > > > > > > > > > On Thu, Sep 17, 2020 at 11:14:43AM -0700, Puthikorn
> > > > > > > > > > > Voravootivat
> > > > > > > > > > > wrote:
> > > > > > > > > > > > The Lyude fde7266fb2f6 change is actually based on
> > > > > > > > > > > > Chromium
> > > > > > > > > > > > change
> > > > > > > > > > > > (https://crrev.com/c/1650325) that fixes the brightness
> > > > > > > > > > > > for
> > > > > > > > > > > > Samsung
> > > > > > > > > > > > Galaxy Chromebook. So currently we have 2 examples that
> > > > > > > > > > > > use
> > > > > > > > > > > > LSB
> > > > > > > > > > > > interpretation and 1 that use MSB.
> > > > > > > > > > > 
> > > > > > > > > > > "If field 4:0 of the EDP_PWMGEN_BIT_COUNT register
> > > > > > > > > > > represents
> > > > > > > > > > > a
> > > > > > > > > > > value
> > > > > > > > > > > of greater than 8 and the BACKLIGHT_BRIGHTNESS_BYTE_COUNT
> > > > > > > > > > > bit
> > > > > > > > > > > is cleared to 0, only the 8 MSB of the brightness control
> > > > > > > > > > > value
> > > > > > > > > > > can be
> > > > > > > > > > > controlled.
> > > > > > > > > > > (See Note below.)
> > > > > > > > > > > Assigned bits are allocated to the MSB of the enabled
> > > > > > > > > > > register
> > > > > > > > > > > combination."
> > > > > > > > > > > 
> > > > > > > > > > > I think that's pretty clear the assigned bits are supposed
> > > > > > > > > > > to
> > > > > > > > > > > be
> > > > > > > > > > > msb aligned.
> > > > > > > > > > 
> > > > > > > > > > I guess there's some email issues happening, but just to
> > > > > > > > > > clarify:
> > > > > > > > > > 
> > > > > > > > > > When the spec says MSB in caps here it clearly means
> > > > > > > > > > "most significant-bit(s)" since otherwise "8 MSB" would not
> > > > > > > > > > make
> > > > > > > > > > any sense in the context of a 2 byte value.
> > > > > > > > > > 
> > > > > > > > > > Granted the spec is crap here since "Table 1-1: Acronyms and
> > > > > > > > > > Initialism" does claim "MSB" should be byte(s) and "msb"
> > > > > > > > > > bit(s).
> > > > > > > > > > 
> > > > > > > > > > Also I can't imagine anyone would allocate the bits starting
> > > > > > > > > > from the lsb when the whole thing is clearly supposed to be
> > > > > > > > > > a
> > > > > > > > > > 16bit big endian integer. So with >8 assigned bits you'd end
> > > > > > > > > > up with crazy stuff like this:
> > > > > > > > > > 
> > > > > > > > > > [ 7 ... 0 ][7   ...   0]
> > > > > > > > > > [ 8 MSB   ][XXXX][N LSB]
> > > > > > > > > > 
> > > > > > > > > > so you couldn't even treat the value as a regular big endian
> > > > > > > > > > thing. Instead, if you squint a bit, it now looks like a
> > > > > > > > > > funky
> > > > > > > > > > little endian value. So we're deep into some mixed endian
> > > > > > > > > > land
> > > > > > > > > > where nothing makes sense anymore.
> > > > > > > > > > 
> > > > > > > > > > Anyways I think the code should simply do this to match the
> > > > > > > > > > spec:
> > > > > > > > > > u16 value = brightness << (16 - num_assigned_bits);
> > > > > > > > > > val[0] = value >> 8;
> > > > > > > > > > val[1] = value & 0xff;
> > > > > > > > > > 
> > > > > > > > > > 
> > > > > > > > > > > > On Thu, Sep 17, 2020 at 10:55 AM Kevin Chowski <
> > > > > > > > > > > > chowski@chromium.org> wrote:
> > > > > > > > > > > > > Apologies for being too vague. To be as precise I can
> > > > > > > > > > > > > be,
> > > > > > > > > > > > > here
> > > > > > > > > > > > > is the
> > > > > > > > > > > > > specific code delta I tested: 
> > > > > > > > > > > > > https://crrev.com/c/2406616
> > > > > > > > > > > > > . To
> > > > > > > > > > > > > answer
> > > > > > > > > > > > > your other question, the code I tested against is
> > > > > > > > > > > > > indeed
> > > > > > > > > > > > > including the
> > > > > > > > > > > > > fde7266fb2f6 (despite ostensibly being called 5.4 in
> > > > > > > > > > > > > my
> > > > > > > > > > > > > commit
> > > > > > > > > > > > > message): our current top-of-tree for our 5.4 branch
> > > > > > > > > > > > > includes
> > > > > > > > > > > > > the
> > > > > > > > > > > > > intel_dp_aux_calc_max_backlight logic. Further, I'll
> > > > > > > > > > > > > note
> > > > > > > > > > > > > that
> > > > > > > > > > > > > change
> > > > > > > > > > > > > is exactly the change which breaks my Pixelbook model:
> > > > > > > > > > > > > prior
> > > > > > > > > > > > > to the
> > > > > > > > > > > > > change, the max_brightness was hard-coded to 0xFFFF
> > > > > > > > > > > > > and
> > > > > > > > > > > > > the
> > > > > > > > > > > > > math
> > > > > > > > > > > > > worked out that it didn't matter that the hardware
> > > > > > > > > > > > > cared
> > > > > > > > > > > > > about
> > > > > > > > > > > > > the MSB
> > > > > > > > > > > > > despite the driver code caring about the LSB.
> > > > > > > > > > > > > 
> > > > > > > > > > > > > To answer Ville's question: the fde7266fb2f6 change
> > > > > > > > > > > > > which
> > > > > > > > > > > > > fixes one
> > > > > > > > > > > > > laptop (I believe Thinkpad X1 extreme Gen 2, from some
> > > > > > > > > > > > > bug
> > > > > > > > > > > > > reports I
> > > > > > > > > > > > > dug up) and breaks another (Pixelbook); so
> > > > > > > > > > > > > unfortunately
> > > > > > > > > > > > > I
> > > > > > > > > > > > > believe we
> > > > > > > > > > > > > need a quirk at least for some laptop. Reading through
> > > > > > > > > > > > > the
> > > > > > > > > > > > > copy of the
> > > > > > > > > > > > > datasheet I have, it wasn't clear to me which was the
> > > > > > > > > > > > > correct
> > > > > > > > > > > > > interpretation. I'm cc'ing puthik@, who was leaning
> > > > > > > > > > > > > toward
> > > > > > > > > > > > > the
> > > > > > > > > > > > > current
> > > > > > > > > > > > > kernel code (caring about LSB) being the correct
> > > > > > > > > > > > > interpretation. I
> > > > > > > > > > > > > believe we have other chromebooks which do rely on LSB
> > > > > > > > > > > > > functionality,
> > > > > > > > > > > > > so unless we can find more examples of laptops wanting
> > > > > > > > > > > > > MSB
> > > > > > > > > > > > > it
> > > > > > > > > > > > > currently looks like Pixelbook is the outlier.
> > > > > > > > > > > > > 
> > > > > > > > > > > > > On Thu, Sep 17, 2020 at 11:28 AM Jani Nikula
> > > > > > > > > > > > > <jani.nikula@linux.intel.com> wrote:
> > > > > > > > > > > > > > On Thu, 17 Sep 2020, Kevin Chowski <
> > > > > > > > > > > > > > chowski@chromium.org
> > > > > > > > > > > > > > wrote:
> > > > > > > > > > > > > > > We have observed that Google Pixelbook's backlight
> > > > > > > > > > > > > > > hardware is
> > > > > > > > > > > > > > > interpretting these backlight bits from the most-
> > > > > > > > > > > > > > > significant side of the
> > > > > > > > > > > > > > > 16 bit word (if DP_EDP_PWMGEN_BIT_COUNT < 16),
> > > > > > > > > > > > > > > whereas
> > > > > > > > > > > > > > > the
> > > > > > > > > > > > > > > driver code
> > > > > > > > > > > > > > > assumes the peripheral cares about the least-
> > > > > > > > > > > > > > > significant
> > > > > > > > > > > > > > > bits.
> > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > Testing was done from within Chrome OS's build
> > > > > > > > > > > > > > > environment
> > > > > > > > > > > > > > > when the
> > > > > > > > > > > > > > > patch is backported to 5.4 (the version we are
> > > > > > > > > > > > > > > newly
> > > > > > > > > > > > > > > targeting for the
> > > > > > > > > > > > > > > Pixelbook); for the record:
> > > > > > > > > > > > > > >    $ emerge-eve-kernelnext sys-kernel/chromeos-
> > > > > > > > > > > > > > > kernel-
> > > > > > > > > > > > > > > 5_4
> > > > > > > > > > > > > > > && \
> > > > > > > > > > > > > > >       ./update_kernel.sh --remote=$IP
> > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > I used `/sys/kernel/debug/dri/0/eDP-1/i915_dpcd`
> > > > > > > > > > > > > > > on
> > > > > > > > > > > > > > > my
> > > > > > > > > > > > > > > laptop to verify
> > > > > > > > > > > > > > > that the registers were being set according to
> > > > > > > > > > > > > > > what
> > > > > > > > > > > > > > > the
> > > > > > > > > > > > > > > actual hardware
> > > > > > > > > > > > > > > expects; I also observe that the backlight is
> > > > > > > > > > > > > > > noticeably
> > > > > > > > > > > > > > > brighter with
> > > > > > > > > > > > > > > this patch.
> > > > > > > > > > > > > > 
> > > > > > > > > > > > > > It's unclear to me what kernel version this is
> > > > > > > > > > > > > > against,
> > > > > > > > > > > > > > and
> > > > > > > > > > > > > > what you've
> > > > > > > > > > > > > > actually tested.
> > > > > > > > > > > > > > 
> > > > > > > > > > > > > > Have you tried v5.7 kernel with Lyude's fde7266fb2f6
> > > > > > > > > > > > > > ("drm/i915: Fix eDP
> > > > > > > > > > > > > > DPCD aux max backlight calculations")?
> > > > > > > > > > > > > > 
> > > > > > > > > > > > > > I just want to make sure you've tested with all the
> > > > > > > > > > > > > > relevant
> > > > > > > > > > > > > > fixes
> > > > > > > > > > > > > > before adding quirks.
> > > > > > > > > > > > > > 
> > > > > > > > > > > > > > BR,
> > > > > > > > > > > > > > Jani.
> > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > Signed-off-by: Kevin Chowski <chowski@chromium.org
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > ---
> > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > >  .../drm/i915/display/intel_dp_aux_backlight.c |
> > > > > > > > > > > > > > > 34
> > > > > > > > > > > > > > > +++++++++++++++++++
> > > > > > > > > > > > > > >  drivers/gpu/drm/i915/display/intel_quirks.c   |
> > > > > > > > > > > > > > > 13
> > > > > > > > > > > > > > > +++++++
> > > > > > > > > > > > > > >  drivers/gpu/drm/i915/i915_drv.h               |  
> > > > > > > > > > > > > > > 1
> > > > > > > > > > > > > > > +
> > > > > > > > > > > > > > >  3 files changed, 48 insertions(+)
> > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > diff --git
> > > > > > > > > > > > > > > a/drivers/gpu/drm/i915/display/intel_dp_aux_backli
> > > > > > > > > > > > > > > gh
> > > > > > > > > > > > > > > t.
> > > > > > > > > > > > > > > c
> > > > > > > > > > > > > > > b/drivers/gpu/drm/i915/display/intel_dp_aux_backli
> > > > > > > > > > > > > > > gh
> > > > > > > > > > > > > > > t.
> > > > > > > > > > > > > > > c
> > > > > > > > > > > > > > > index acbd7eb66cbe3..99c98f217356d 100644
> > > > > > > > > > > > > > > ---
> > > > > > > > > > > > > > > a/drivers/gpu/drm/i915/display/intel_dp_aux_backli
> > > > > > > > > > > > > > > gh
> > > > > > > > > > > > > > > t.
> > > > > > > > > > > > > > > c
> > > > > > > > > > > > > > > +++
> > > > > > > > > > > > > > > b/drivers/gpu/drm/i915/display/intel_dp_aux_backli
> > > > > > > > > > > > > > > gh
> > > > > > > > > > > > > > > t.
> > > > > > > > > > > > > > > c
> > > > > > > > > > > > > > > @@ -91,6 +91,23 @@ static u32
> > > > > > > > > > > > > > > intel_dp_aux_get_backlight(struct intel_connector
> > > > > > > > > > > > > > > *connector)
> > > > > > > > > > > > > > >       if (intel_dp->edp_dpcd[2] &
> > > > > > > > > > > > > > > DP_EDP_BACKLIGHT_BRIGHTNESS_BYTE_COUNT)
> > > > > > > > > > > > > > >               level = (read_val[0] << 8 |
> > > > > > > > > > > > > > > read_val[1]);
> > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > +     if (i915->quirks &
> > > > > > > > > > > > > > > QUIRK_SHIFT_EDP_BACKLIGHT_BRIGHTNESS) {
> > > > > > > > > > > > > > > +             if (!drm_dp_dpcd_readb(&intel_dp-
> > > > > > > > > > > > > > > >aux,
> > > > > > > > > > > > > > > DP_EDP_PWMGEN_BIT_COUNT,
> > > > > > > > > > > > > > > +                                             &rea
> > > > > > > > > > > > > > > d_
> > > > > > > > > > > > > > > va
> > > > > > > > > > > > > > > l[0]
> > > > > > > > > > > > > > > )) {
> > > > > > > > > > > > > > > +                     DRM_DEBUG_KMS("Failed to
> > > > > > > > > > > > > > > read
> > > > > > > > > > > > > > > DPCD
> > > > > > > > > > > > > > > register 0x%x\n",
> > > > > > > > > > > > > > > +                                     DP_EDP_PWMGE
> > > > > > > > > > > > > > > N_
> > > > > > > > > > > > > > > BI
> > > > > > > > > > > > > > > T_CO
> > > > > > > > > > > > > > > UNT);
> > > > > > > > > > > > > > > +                     return 0;
> > > > > > > > > > > > > > > +             }
> > > > > > > > > > > > > > > +             // Only bits 4:0 are used, 7:5 are
> > > > > > > > > > > > > > > reserved.
> > > > > > > > > > > > > > > +             read_val[0] = read_val[0] & 0x1F;
> > > > > > > > > > > > > > > +             if (read_val[0] > 16) {
> > > > > > > > > > > > > > > +                     DRM_DEBUG_KMS("Invalid
> > > > > > > > > > > > > > > DP_EDP_PWNGEN_BIT_COUNT 0x%X, expected at most
> > > > > > > > > > > > > > > 16\n",
> > > > > > > > > > > > > > > +                                             read
> > > > > > > > > > > > > > > _v
> > > > > > > > > > > > > > > al
> > > > > > > > > > > > > > > [0])
> > > > > > > > > > > > > > > ;
> > > > > > > > > > > > > > > +                     return 0;
> > > > > > > > > > > > > > > +             }
> > > > > > > > > > > > > > > +             level >>= 16 - read_val[0];
> > > > > > > > > > > > > > > +     }
> > > > > > > > > > > > > > > +
> > > > > > > > > > > > > > >       return level;
> > > > > > > > > > > > > > >  }
> > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > @@ -106,6 +123,23 @@
> > > > > > > > > > > > > > > intel_dp_aux_set_backlight(const
> > > > > > > > > > > > > > > struct drm_connector_state *conn_state, u32 lev
> > > > > > > > > > > > > > >       struct drm_i915_private *i915 =
> > > > > > > > > > > > > > > dp_to_i915(intel_dp);
> > > > > > > > > > > > > > >       u8 vals[2] = { 0x0 };
> > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > +     if (i915->quirks &
> > > > > > > > > > > > > > > QUIRK_SHIFT_EDP_BACKLIGHT_BRIGHTNESS) {
> > > > > > > > > > > > > > > +             if (!drm_dp_dpcd_readb(&intel_dp-
> > > > > > > > > > > > > > > >aux,
> > > > > > > > > > > > > > > DP_EDP_PWMGEN_BIT_COUNT,
> > > > > > > > > > > > > > > +                                             &val
> > > > > > > > > > > > > > > s[
> > > > > > > > > > > > > > > 0]
> > > > > > > > > > > > > > > )) {
> > > > > > > > > > > > > > > +                     DRM_DEBUG_KMS("Failed to
> > > > > > > > > > > > > > > write
> > > > > > > > > > > > > > > aux
> > > > > > > > > > > > > > > backlight level: Failed to read DPCD register
> > > > > > > > > > > > > > > 0x%x\n",
> > > > > > > > > > > > > > > +                                       DP_EDP_PWM
> > > > > > > > > > > > > > > GE
> > > > > > > > > > > > > > > N_
> > > > > > > > > > > > > > > BIT_
> > > > > > > > > > > > > > > COUNT);
> > > > > > > > > > > > > > > +                     return;
> > > > > > > > > > > > > > > +             }
> > > > > > > > > > > > > > > +             // Only bits 4:0 are used, 7:5 are
> > > > > > > > > > > > > > > reserved.
> > > > > > > > > > > > > > > +             vals[0] = vals[0] & 0x1F;
> > > > > > > > > > > > > > > +             if (vals[0] > 16) {
> > > > > > > > > > > > > > > +                     DRM_DEBUG_KMS("Failed to
> > > > > > > > > > > > > > > write
> > > > > > > > > > > > > > > aux
> > > > > > > > > > > > > > > backlight level: Invalid DP_EDP_PWNGEN_BIT_COUNT
> > > > > > > > > > > > > > > 0x%X,
> > > > > > > > > > > > > > > expected at most 16\n",
> > > > > > > > > > > > > > > +                                             vals
> > > > > > > > > > > > > > > [0
> > > > > > > > > > > > > > > ])
> > > > > > > > > > > > > > > ;
> > > > > > > > > > > > > > > +                     return;
> > > > > > > > > > > > > > > +             }
> > > > > > > > > > > > > > > +             level <<= (16 - vals[0]) & 0xFFFF;
> > > > > > > > > > > > > > > +     }
> > > > > > > > > > > > > > > +
> > > > > > > > > > > > > > >       vals[0] = level;
> > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > >       /* Write the MSB and/or LSB */
> > > > > > > > > > > > > > > diff --git
> > > > > > > > > > > > > > > a/drivers/gpu/drm/i915/display/intel_quirks.c
> > > > > > > > > > > > > > > b/drivers/gpu/drm/i915/display/intel_quirks.c
> > > > > > > > > > > > > > > index 46beb155d835f..63b27d49b2864 100644
> > > > > > > > > > > > > > > --- a/drivers/gpu/drm/i915/display/intel_quirks.c
> > > > > > > > > > > > > > > +++ b/drivers/gpu/drm/i915/display/intel_quirks.c
> > > > > > > > > > > > > > > @@ -53,6 +53,16 @@ static void
> > > > > > > > > > > > > > > quirk_increase_ddi_disabled_time(struct
> > > > > > > > > > > > > > > drm_i915_private
> > > > > > > > > > > > > > > *i915)
> > > > > > > > > > > > > > >       drm_info(&i915->drm, "Applying Increase DDI
> > > > > > > > > > > > > > > Disabled
> > > > > > > > > > > > > > > quirk\n");
> > > > > > > > > > > > > > >  }
> > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > +/*
> > > > > > > > > > > > > > > + * Some eDP backlight hardware uses the most-
> > > > > > > > > > > > > > > significant
> > > > > > > > > > > > > > > bits of the brightness
> > > > > > > > > > > > > > > + * register, so brightness values must be shifted
> > > > > > > > > > > > > > > first.
> > > > > > > > > > > > > > > + */
> > > > > > > > > > > > > > > +static void
> > > > > > > > > > > > > > > quirk_shift_edp_backlight_brightness(struct
> > > > > > > > > > > > > > > drm_i915_private *i915)
> > > > > > > > > > > > > > > +{
> > > > > > > > > > > > > > > +     i915->quirks |=
> > > > > > > > > > > > > > > QUIRK_SHIFT_EDP_BACKLIGHT_BRIGHTNESS;
> > > > > > > > > > > > > > > +     DRM_INFO("Applying shift eDP backlight
> > > > > > > > > > > > > > > brightness
> > > > > > > > > > > > > > > quirk\n");
> > > > > > > > > > > > > > > +}
> > > > > > > > > > > > > > > +
> > > > > > > > > > > > > > >  struct intel_quirk {
> > > > > > > > > > > > > > >       int device;
> > > > > > > > > > > > > > >       int subsystem_vendor;
> > > > > > > > > > > > > > > @@ -156,6 +166,9 @@ static struct intel_quirk
> > > > > > > > > > > > > > > intel_quirks[] = {
> > > > > > > > > > > > > > >       /* ASRock ITX*/
> > > > > > > > > > > > > > >       { 0x3185, 0x1849, 0x2212,
> > > > > > > > > > > > > > > quirk_increase_ddi_disabled_time },
> > > > > > > > > > > > > > >       { 0x3184, 0x1849, 0x2212,
> > > > > > > > > > > > > > > quirk_increase_ddi_disabled_time },
> > > > > > > > > > > > > > > +
> > > > > > > > > > > > > > > +     /* Google Pixelbook */
> > > > > > > > > > > > > > > +     { 0x591E, 0x8086, 0x2212,
> > > > > > > > > > > > > > > quirk_shift_edp_backlight_brightness },
> > > > > > > > > > > > > > >  };
> > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > >  void intel_init_quirks(struct drm_i915_private
> > > > > > > > > > > > > > > *i915)
> > > > > > > > > > > > > > > diff --git a/drivers/gpu/drm/i915/i915_drv.h
> > > > > > > > > > > > > > > b/drivers/gpu/drm/i915/i915_drv.h
> > > > > > > > > > > > > > > index e4f7f6518945b..cc93bede4fab8 100644
> > > > > > > > > > > > > > > --- a/drivers/gpu/drm/i915/i915_drv.h
> > > > > > > > > > > > > > > +++ b/drivers/gpu/drm/i915/i915_drv.h
> > > > > > > > > > > > > > > @@ -525,6 +525,7 @@ struct i915_psr {
> > > > > > > > > > > > > > >  #define QUIRK_PIN_SWIZZLED_PAGES (1<<5)
> > > > > > > > > > > > > > >  #define QUIRK_INCREASE_T12_DELAY (1<<6)
> > > > > > > > > > > > > > >  #define QUIRK_INCREASE_DDI_DISABLED_TIME (1<<7)
> > > > > > > > > > > > > > > +#define QUIRK_SHIFT_EDP_BACKLIGHT_BRIGHTNESS
> > > > > > > > > > > > > > > (1<<8)
> > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > >  struct intel_fbdev;
> > > > > > > > > > > > > > >  struct intel_fbc_work;
> > > > > > > > > > > > > > 
> > > > > > > > > > > > > > --
> > > > > > > > > > > > > > Jani Nikula, Intel Open Source Graphics Center
> > > > > > > > > > > 
> > > > > > > > > > > --
> > > > > > > > > > > Ville Syrjälä
> > > > > > > > > > > Intel
> > > > > > > > > > > _______________________________________________
> > > > > > > > > > > Intel-gfx mailing list
> > > > > > > > > > > Intel-gfx@lists.freedesktop.org
> > > > > > > > > > > https://lists.freedesktop.org/mailman/listinfo/intel-gfx
> > > > > > > > > > 
> > > > > > > > > > --
> > > > > > > > > > Ville Syrjälä
> > > > > > > > > > Intel
> > > > > --
> > > > > Cheers,
> > > > >         Lyude Paul (she/her)
> > > > >         Software Engineer at Red Hat
> > > > > 
> > > --
> > > Cheers,
> > >         Lyude Paul (she/her)
> > >         Software Engineer at Red Hat
> > > 
-- 
Sincerely,
      Lyude Paul (she/her)
      Software Engineer at Red Hat