from:"Lyude Paul"

[Intel-gfx] [PATCH v7 2/5] drm/i915: Keep track of pwm-related backlight hooks separately

2021-01-14 Thread Lyude Paul

Currently, every different type of backlight hook that i915 supports is
pretty straight forward - you have a backlight, probably through PWM
(but maybe DPCD), with a single set of platform-specific hooks that are
used for controlling it.

HDR backlights, in particular VESA and Intel's HDR backlight
implementations, can end up being more complicated. With Intel's
proprietary interface, HDR backlight controls always run through the
DPCD. When the backlight is in SDR backlight mode however, the driver
may need to bypass the TCON and control the backlight directly through
PWM.

So, in order to support this we'll need to split our backlight callbacks
into two groups: a set of high-level backlight control callbacks in
intel_panel, and an additional set of pwm-specific backlight control
callbacks. This also implies a functional changes for how these
callbacks are used:

* We now keep track of two separate backlight level ranges, one for the
  high-level backlight, and one for the pwm backlight range
* We also keep track of backlight enablement and PWM backlight
  enablement separately
* Since the currently set backlight level might not be the same as the
  currently programmed PWM backlight level, we stop setting
  panel->backlight.level with the currently programmed PWM backlight
  level in panel->backlight.pwm_funcs->setup(). Instead, we rely
  on the higher level backlight control functions to retrieve the
  current PWM backlight level (in this case, intel_pwm_get_backlight()).
  Note that there are still a few PWM backlight setup callbacks that
  do actually need to retrieve the current PWM backlight level, although
  we no longer save this value in panel->backlight.level like before.

Additionally, we drop the call to lpt_get_backlight() in
lpt_setup_backlight(), and avoid unconditionally writing the PWM value that
we get from it and only write it back if we're in CPU mode, and switching
to PCH mode. The reason for this is because in the original codepath for
this, it was expected that the intel_panel_bl_funcs->setup() hook would be
responsible for fetching the initial backlight level. On lpt systems, the
only time we could ever be in PCH backlight mode is during the initial
driver load - meaning that outside of the setup() hook, lpt_get_backlight()
will always be the callback used for retrieving the current backlight
level. After this patch we still need to fetch and write-back the PCH
backlight value if we're switching from CPU mode to PCH, but because
intel_pwm_setup_backlight() will retrieve the backlight level after setup()
using the get() hook, which always ends up being lpt_get_backlight(). Thus
- an additional call to lpt_get_backlight() in lpt_setup_backlight() is
made redundant.

v8:
* Go back to getting initial brightness level with
  intel_pwm_get_backlight(), the other fix we had was definitely wrong.
v7:
* Use panel->backlight.pwm_funcs->get() to get the backlight level in
  intel_pwm_setup_backlight(), lest we upset lockdep
* Rebase
* Rename intel_panel_sanitize_pwm_level() to intel_panel_invert_pwm_level()
v6:
* Make sure to grab connection_mutex before calling
  intel_pwm_get_backlight() in intel_pwm_setup_backlight()
v5:
* Fix indenting warnings from checkpatch
v4:
* Fix commit message
* Remove outdated comment in intel_panel.c
* Rename pwm_(min|max) to pwm_level_(min|max)
* Use intel_pwm_get_backlight() in intel_pwm_setup_backlight() instead of
  indirection
* Don't move intel_dp_aux_init_bcklight_funcs() call to bottom of
  intel_panel_init_backlight_funcs() quite yet
v3:
* Reuse intel_panel_bl_funcs() for pwm_funcs
* Explain why we drop lpt_get_backlight()

Signed-off-by: Lyude Paul 
Reviewed-by: Jani Nikula 
Cc: thay...@noraisin.net
Cc: Vasily Khoruzhick 

squash! drm/i915: Keep track of pwm-related backlight hooks separately

Signed-off-by: Lyude Paul 
---
 .../drm/i915/display/intel_display_types.h|   4 +
 drivers/gpu/drm/i915/display/intel_panel.c| 331 ++
 2 files changed, 188 insertions(+), 147 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/intel_display_types.h 
b/drivers/gpu/drm/i915/display/intel_display_types.h
index b1f4ec144207..ee23cc1518df 100644
--- a/drivers/gpu/drm/i915/display/intel_display_types.h
+++ b/drivers/gpu/drm/i915/display/intel_display_types.h
@@ -252,6 +252,9 @@ struct intel_panel {
bool alternate_pwm_increment;   /* lpt+ */
 
/* PWM chip */
+   u32 pwm_level_min;
+   u32 pwm_level_max;
+   bool pwm_enabled;
bool util_pin_active_low;   /* bxt+ */
u8 controller;  /* bxt+ only */
struct pwm_device *pwm;
@@ -263,6 +266,7 @@ struct intel_panel {
struct backlight_device *device;
 
const struct intel_panel_bl_funcs *funcs;
+   const struct intel_panel_bl_funcs *pwm_funcs;
void (*power)(struct intel_connector *, bool enable)

[Intel-gfx] [PATCH v7 1/5] drm/i915: Pass port to intel_panel_bl_funcs.get()

2021-01-14 Thread Lyude Paul

In the next commit where we split PWM related backlight functions from
higher-level backlight functions, we'll want to be able to retrieve the
backlight level for the current display panel from the
intel_panel_bl_funcs->setup() function using pwm_funcs->get(). Since
intel_panel_bl_funcs->setup() is called before we've fully read in the
current hardware state into our atomic state, we can't grab atomic
modesetting locks safely anyway in intel_panel_bl_funcs->setup(), and some
PWM backlight functions (vlv_get_backlight() in particular) require knowing
the currently used pipe we need to be able to discern the current display
pipe through other means. Luckily, we're already passing the current
display pipe to intel_panel_bl_funcs->setup() so all we have to do in order
to achieve this is pass down that parameter to intel_panel_bl_funcs->get().

So, fix this by accepting an additional pipe parameter in
intel_panel_bl_funcs->get(), and leave figuring out the current display
pipe up to the caller.

Signed-off-by: Lyude Paul 
---
 .../drm/i915/display/intel_display_types.h|  2 +-
 .../drm/i915/display/intel_dp_aux_backlight.c |  4 +-
 .../i915/display/intel_dsi_dcs_backlight.c|  2 +-
 drivers/gpu/drm/i915/display/intel_panel.c| 40 ---
 4 files changed, 21 insertions(+), 27 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/intel_display_types.h 
b/drivers/gpu/drm/i915/display/intel_display_types.h
index 585bb1edea04..b1f4ec144207 100644
--- a/drivers/gpu/drm/i915/display/intel_display_types.h
+++ b/drivers/gpu/drm/i915/display/intel_display_types.h
@@ -228,7 +228,7 @@ struct intel_encoder {
 struct intel_panel_bl_funcs {
/* Connector and platform specific backlight functions */
int (*setup)(struct intel_connector *connector, enum pipe pipe);
-   u32 (*get)(struct intel_connector *connector);
+   u32 (*get)(struct intel_connector *connector, enum pipe pipe);
void (*set)(const struct drm_connector_state *conn_state, u32 level);
void (*disable)(const struct drm_connector_state *conn_state, u32 
level);
void (*enable)(const struct intel_crtc_state *crtc_state,
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 9775f33d1aac..de764dae1e66 100644
--- a/drivers/gpu/drm/i915/display/intel_dp_aux_backlight.c
+++ b/drivers/gpu/drm/i915/display/intel_dp_aux_backlight.c
@@ -128,7 +128,7 @@ static bool intel_dp_aux_vesa_backlight_dpcd_mode(struct 
intel_connector *connec
  * Read the current backlight value from DPCD register(s) based
  * on if 8-bit(MSB) or 16-bit(MSB and LSB) values are supported
  */
-static u32 intel_dp_aux_vesa_get_backlight(struct intel_connector *connector)
+static u32 intel_dp_aux_vesa_get_backlight(struct intel_connector *connector, 
enum pipe unused)
 {
struct intel_dp *intel_dp = intel_attached_dp(connector);
struct drm_i915_private *i915 = dp_to_i915(intel_dp);
@@ -381,7 +381,7 @@ static int intel_dp_aux_vesa_setup_backlight(struct 
intel_connector *connector,
return -ENODEV;
 
panel->backlight.min = 0;
-   panel->backlight.level = intel_dp_aux_vesa_get_backlight(connector);
+   panel->backlight.level = intel_dp_aux_vesa_get_backlight(connector, 
pipe);
panel->backlight.enabled = 
intel_dp_aux_vesa_backlight_dpcd_mode(connector) &&
   panel->backlight.level != 0;
 
diff --git a/drivers/gpu/drm/i915/display/intel_dsi_dcs_backlight.c 
b/drivers/gpu/drm/i915/display/intel_dsi_dcs_backlight.c
index 88628764956d..584c14c4cbd0 100644
--- a/drivers/gpu/drm/i915/display/intel_dsi_dcs_backlight.c
+++ b/drivers/gpu/drm/i915/display/intel_dsi_dcs_backlight.c
@@ -43,7 +43,7 @@
 
 #define PANEL_PWM_MAX_VALUE0xFF
 
-static u32 dcs_get_backlight(struct intel_connector *connector)
+static u32 dcs_get_backlight(struct intel_connector *connector, enum pipe 
unused)
 {
struct intel_encoder *encoder = intel_attached_encoder(connector);
struct intel_dsi *intel_dsi = enc_to_intel_dsi(encoder);
diff --git a/drivers/gpu/drm/i915/display/intel_panel.c 
b/drivers/gpu/drm/i915/display/intel_panel.c
index 7a4239d1c241..7587aaefc7a0 100644
--- a/drivers/gpu/drm/i915/display/intel_panel.c
+++ b/drivers/gpu/drm/i915/display/intel_panel.c
@@ -530,21 +530,21 @@ static u32 intel_panel_compute_brightness(struct 
intel_connector *connector,
return val;
 }
 
-static u32 lpt_get_backlight(struct intel_connector *connector)
+static u32 lpt_get_backlight(struct intel_connector *connector, enum pipe 
unused)
 {
struct drm_i915_private *dev_priv = to_i915(connector->base.dev);
 
return intel_de_read(dev_priv, BLC_PWM_PCH_CTL2) & 
BACKLIGHT_DUTY_CYCLE_MASK;
 }
 
-static u32 pch_get_backlight(struct intel_connector *connector)
+static u32 pch_get_backlight(struct intel_connector *connector, en

[Intel-gfx] [PATCH v7 0/5] drm/i915: Add support for Intel's eDP backlight controls

2021-01-14 Thread Lyude Paul

A while ago we ran into issues while trying to enable the eDP backlight
control interface as defined by VESA, in order to make the DPCD
backlight controls on newer laptop panels work. The issue ended up being
much more complicated however, as we also apparently needed to add
support for an Intel-specific DPCD backlight control interface as the
VESA interface is broken on many laptop panels. For lack of a better
name, we just call this the Intel HDR backlight interface.

While this only adds support for the SDR backlight mode (I think), this
will fix a lot of user's laptop panels that we weren't able to properly
automatically detect DPCD backlight controls on previously.

Series-wide changes in v7:
* Add another patch that allows passing the current display pipe to
  intel_panel_bl_funcs.get(), which should fix the lockdep issues we
  were seeing with Intel's CI

Lyude Paul (5):
  drm/i915: Pass port to intel_panel_bl_funcs.get()
  drm/i915: Keep track of pwm-related backlight hooks separately
  drm/i915/dp: Enable Intel's HDR backlight interface (only SDR for now)
  drm/i915/dp: Allow forcing specific interfaces through
enable_dpcd_backlight
  drm/dp: Revert "drm/dp: Introduce EDID-based quirks"

 drivers/gpu/drm/drm_dp_helper.c   |  83 +---
 drivers/gpu/drm/drm_dp_mst_topology.c |   3 +-
 .../drm/i915/display/intel_display_types.h|  16 +-
 drivers/gpu/drm/i915/display/intel_dp.c   |   9 +-
 .../drm/i915/display/intel_dp_aux_backlight.c | 290 +++--
 drivers/gpu/drm/i915/display/intel_dp_mst.c   |   3 +-
 .../i915/display/intel_dsi_dcs_backlight.c|   2 +-
 drivers/gpu/drm/i915/display/intel_panel.c| 395 ++
 drivers/gpu/drm/i915/display/intel_panel.h|   4 +
 drivers/gpu/drm/i915/display/intel_psr.c  |   2 +-
 drivers/gpu/drm/i915/i915_params.c|   2 +-
 include/drm/drm_dp_helper.h   |  21 +-
 12 files changed, 519 insertions(+), 311 deletions(-)

-- 
2.29.2

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH v6 1/4] drm/i915: Keep track of pwm-related backlight hooks separately

2021-01-14 Thread Lyude Paul

On Thu, 2021-01-14 at 09:12 +0200, Jani Nikula wrote:
> On Wed, 13 Jan 2021, Lyude Paul  wrote:
> > Currently, every different type of backlight hook that i915 supports is
> > pretty straight forward - you have a backlight, probably through PWM
> > (but maybe DPCD), with a single set of platform-specific hooks that are
> > used for controlling it.
> > 
> > HDR backlights, in particular VESA and Intel's HDR backlight
> > implementations, can end up being more complicated. With Intel's
> > proprietary interface, HDR backlight controls always run through the
> > DPCD. When the backlight is in SDR backlight mode however, the driver
> > may need to bypass the TCON and control the backlight directly through
> > PWM.
> > 
> > So, in order to support this we'll need to split our backlight callbacks
> > into two groups: a set of high-level backlight control callbacks in
> > intel_panel, and an additional set of pwm-specific backlight control
> > callbacks. This also implies a functional changes for how these
> > callbacks are used:
> > 
> > * We now keep track of two separate backlight level ranges, one for the
> >   high-level backlight, and one for the pwm backlight range
> > * We also keep track of backlight enablement and PWM backlight
> >   enablement separately
> > * Since the currently set backlight level might not be the same as the
> >   currently programmed PWM backlight level, we stop setting
> >   panel->backlight.level with the currently programmed PWM backlight
> >   level in panel->backlight.pwm_funcs->setup(). Instead, we rely
> >   on the higher level backlight control functions to retrieve the
> >   current PWM backlight level (in this case, intel_pwm_get_backlight()).
> >   Note that there are still a few PWM backlight setup callbacks that
> >   do actually need to retrieve the current PWM backlight level, although
> >   we no longer save this value in panel->backlight.level like before.
> > 
> > Additionally, we drop the call to lpt_get_backlight() in
> > lpt_setup_backlight(), and avoid unconditionally writing the PWM value that
> > we get from it and only write it back if we're in CPU mode, and switching
> > to PCH mode. The reason for this is because in the original codepath for
> > this, it was expected that the intel_panel_bl_funcs->setup() hook would be
> > responsible for fetching the initial backlight level. On lpt systems, the
> > only time we could ever be in PCH backlight mode is during the initial
> > driver load - meaning that outside of the setup() hook, lpt_get_backlight()
> > will always be the callback used for retrieving the current backlight
> > level. After this patch we still need to fetch and write-back the PCH
> > backlight value if we're switching from CPU mode to PCH, but because
> > intel_pwm_setup_backlight() will retrieve the backlight level after setup()
> > using the get() hook, which always ends up being lpt_get_backlight(). Thus
> > - an additional call to lpt_get_backlight() in lpt_setup_backlight() is
> > made redundant.
> > 
> > v7:
> > * Use panel->backlight.pwm_funcs->get() to get the backlight level in
> >   intel_pwm_setup_backlight(), lest we upset lockdep
> 
> I think this change is wrong, as it now bypasses
> intel_panel_invert_pwm_level(). Please explain. I don't see anything in
> there that could trigger a lockdep warning.

yeah-this was definitely me misunderstanding what the issue we were hitting here
was.

> 
> Perhaps it's the below you're referring to, but I think the root cause
> is different?
> 
> > @@ -1788,22 +1780,17 @@ static int vlv_setup_backlight(struct
> > intel_connector *connector, enum pipe pipe
> > panel->backlight.active_low_pwm = ctl2 & BLM_POLARITY_I965;
> >  
> > ctl = intel_de_read(dev_priv, VLV_BLC_PWM_CTL(pipe));
> > -   panel->backlight.max = ctl >> 16;
> > +   panel->backlight.pwm_level_max = ctl >> 16;
> >  
> > -   if (!panel->backlight.max)
> > -   panel->backlight.max = get_backlight_max_vbt(connector);
> > +   if (!panel->backlight.pwm_level_max)
> > +   panel->backlight.pwm_level_max =
> > get_backlight_max_vbt(connector);
> >  
> > -   if (!panel->backlight.max)
> > +   if (!panel->backlight.pwm_level_max)
> > return -ENODEV;
> >  
> > -   panel->backlight.min = get_backlight_min_vbt(connector);
> > +   panel->backlight.pwm_level_min = get_backlight_min_vbt(connector);
> >  
> > -   val = _v

[Intel-gfx] [PATCH v6 4/4] drm/dp: Revert "drm/dp: Introduce EDID-based quirks"

2021-01-13 Thread Lyude Paul

This reverts commit 0883ce8146ed6074c76399f4e70dbed788582e12. Originally
these quirks were added because of the issues with using the eDP
backlight interfaces on certain laptop panels, which made it impossible
to properly probe for DPCD backlight support without having a whitelist
for panels that we know have working VESA backlight control interfaces
over DPCD. As well, it should be noted it was impossible to use the
normal sink OUI for recognizing these panels as none of them actually
filled out their OUIs, hence needing to resort to checking EDIDs.

At the time we weren't really sure why certain panels had issues with
DPCD backlight controls, but we eventually figured out that there was a
second interface that these problematic laptop panels actually did work
with and advertise properly: Intel's proprietary backlight interface for
HDR panels. So far the testing we've done hasn't brought any panels to
light that advertise this interface and don't support it properly, which
means we finally have a real solution to this problem.

As a result, we now have no need for the force DPCD backlight quirk, and
furthermore this also removes the need for any kind of EDID quirk
checking in DRM. So, let's just revert it for now since we were the only
driver using this.

v3:
* Rebase
v2:
* Fix indenting error picked up by checkpatch in
  intel_edp_init_connector()

Signed-off-by: Lyude Paul 
Acked-by: Jani Nikula 
Cc: thay...@noraisin.net
Cc: Vasily Khoruzhick 
---
 drivers/gpu/drm/drm_dp_helper.c   | 83 +--
 drivers/gpu/drm/drm_dp_mst_topology.c |  3 +-
 .../drm/i915/display/intel_display_types.h|  1 -
 drivers/gpu/drm/i915/display/intel_dp.c   |  9 +-
 drivers/gpu/drm/i915/display/intel_dp_mst.c   |  3 +-
 drivers/gpu/drm/i915/display/intel_psr.c  |  2 +-
 include/drm/drm_dp_helper.h   | 21 +
 7 files changed, 9 insertions(+), 113 deletions(-)

diff --git a/drivers/gpu/drm/drm_dp_helper.c b/drivers/gpu/drm/drm_dp_helper.c
index 3ecde451f523..19dbdeb581cb 100644
--- a/drivers/gpu/drm/drm_dp_helper.c
+++ b/drivers/gpu/drm/drm_dp_helper.c
@@ -1236,7 +1236,7 @@ bool drm_dp_read_sink_count_cap(struct drm_connector 
*connector,
return connector->connector_type != DRM_MODE_CONNECTOR_eDP &&
dpcd[DP_DPCD_REV] >= DP_DPCD_REV_11 &&
dpcd[DP_DOWNSTREAMPORT_PRESENT] & DP_DWN_STRM_PORT_PRESENT &&
-   !drm_dp_has_quirk(desc, 0, DP_DPCD_QUIRK_NO_SINK_COUNT);
+   !drm_dp_has_quirk(desc, DP_DPCD_QUIRK_NO_SINK_COUNT);
 }
 EXPORT_SYMBOL(drm_dp_read_sink_count_cap);
 
@@ -1957,87 +1957,6 @@ drm_dp_get_quirks(const struct drm_dp_dpcd_ident *ident, 
bool is_branch)
 #undef DEVICE_ID_ANY
 #undef DEVICE_ID
 
-struct edid_quirk {
-   u8 mfg_id[2];
-   u8 prod_id[2];
-   u32 quirks;
-};
-
-#define MFG(first, second) { (first), (second) }
-#define PROD_ID(first, second) { (first), (second) }
-
-/*
- * 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) },
-   { MFG(0x09, 0xe5), PROD_ID(0xde, 0x08), 
BIT(DP_QUIRK_FORCE_DPCD_BACKLIGHT) },
-};
-
-#undef MFG
-#undef PROD_ID
-
-/**
- * drm_dp_get_edid_quirks() - Check the EDID of a DP device to find additional
- * DP-specific quirks
- * @edid: The EDID to check
- *
- * While OUIDs are meant to be used to recognize a DisplayPort device, a lot
- * of manufacturers don't seem to like following standards and neglect to fill
- * the dev-ID in, making it impossible to only use OUIDs for determining
- * quirk

[Intel-gfx] [PATCH v6 3/4] drm/i915/dp: Allow forcing specific interfaces through enable_dpcd_backlight

2021-01-13 Thread Lyude Paul

Since we now support controlling panel backlights through DPCD using
both the standard VESA interface, and Intel's proprietary HDR backlight
interface, we should allow the user to be able to explicitly choose
between one or the other in the event that we're wrong about panels
reliably reporting support for the Intel HDR interface.

So, this commit adds support for this by introducing two new
enable_dpcd_backlight options: 2 which forces i915 to only probe for the
VESA interface, and 3 which forces i915 to only probe for the Intel
backlight interface (might be useful if we find panels in the wild that
report the VESA interface in their VBT, but actually only support the
Intel backlight interface).

v3:
* Rebase

Signed-off-by: Lyude Paul 
Reviewed-by: Jani Nikula 
Cc: thay...@noraisin.net
Cc: Vasily Khoruzhick 
---
 .../drm/i915/display/intel_dp_aux_backlight.c | 45 +--
 drivers/gpu/drm/i915/i915_params.c|  2 +-
 2 files changed, 43 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/intel_dp_aux_backlight.c 
b/drivers/gpu/drm/i915/display/intel_dp_aux_backlight.c
index abfe950259d9..7ccd56977d9c 100644
--- a/drivers/gpu/drm/i915/display/intel_dp_aux_backlight.c
+++ b/drivers/gpu/drm/i915/display/intel_dp_aux_backlight.c
@@ -612,15 +612,54 @@ static const struct intel_panel_bl_funcs 
intel_dp_vesa_bl_funcs = {
.get = intel_dp_aux_vesa_get_backlight,
 };
 
+enum intel_dp_aux_backlight_modparam {
+   INTEL_DP_AUX_BACKLIGHT_AUTO = -1,
+   INTEL_DP_AUX_BACKLIGHT_OFF = 0,
+   INTEL_DP_AUX_BACKLIGHT_ON = 1,
+   INTEL_DP_AUX_BACKLIGHT_FORCE_VESA = 2,
+   INTEL_DP_AUX_BACKLIGHT_FORCE_INTEL = 3,
+};
+
 int intel_dp_aux_init_backlight_funcs(struct intel_connector *connector)
 {
struct drm_device *dev = connector->base.dev;
struct intel_panel *panel = >panel;
struct intel_dp *intel_dp = enc_to_intel_dp(connector->encoder);
struct drm_i915_private *i915 = dp_to_i915(intel_dp);
+   bool try_intel_interface = false, try_vesa_interface = false;
 
-   if (i915->params.enable_dpcd_backlight == 0)
+   /* Check the VBT and user's module parameters to figure out which
+* interfaces to probe
+*/
+   switch (i915->params.enable_dpcd_backlight) {
+   case INTEL_DP_AUX_BACKLIGHT_OFF:
return -ENODEV;
+   case INTEL_DP_AUX_BACKLIGHT_AUTO:
+   switch (i915->vbt.backlight.type) {
+   case INTEL_BACKLIGHT_VESA_EDP_AUX_INTERFACE:
+   try_vesa_interface = true;
+   break;
+   case INTEL_BACKLIGHT_DISPLAY_DDI:
+   try_intel_interface = true;
+   try_vesa_interface = true;
+   break;
+   default:
+   return -ENODEV;
+   }
+   break;
+   case INTEL_DP_AUX_BACKLIGHT_ON:
+   if (i915->vbt.backlight.type != 
INTEL_BACKLIGHT_VESA_EDP_AUX_INTERFACE)
+   try_intel_interface = true;
+
+   try_vesa_interface = true;
+   break;
+   case INTEL_DP_AUX_BACKLIGHT_FORCE_VESA:
+   try_vesa_interface = true;
+   break;
+   case INTEL_DP_AUX_BACKLIGHT_FORCE_INTEL:
+   try_intel_interface = true;
+   break;
+   }
 
/*
 * A lot of eDP panels in the wild will report supporting both the
@@ -629,13 +668,13 @@ int intel_dp_aux_init_backlight_funcs(struct 
intel_connector *connector)
 * and will only work with the Intel interface. So, always probe for
 * that first.
 */
-   if (intel_dp_aux_supports_hdr_backlight(connector)) {
+   if (try_intel_interface && 
intel_dp_aux_supports_hdr_backlight(connector)) {
drm_dbg_kms(dev, "Using Intel proprietary eDP backlight 
controls\n");
panel->backlight.funcs = _dp_hdr_bl_funcs;
return 0;
}
 
-   if (intel_dp_aux_supports_vesa_backlight(connector)) {
+   if (try_vesa_interface && 
intel_dp_aux_supports_vesa_backlight(connector)) {
drm_dbg_kms(dev, "Using VESA eDP backlight controls\n");
panel->backlight.funcs = _dp_vesa_bl_funcs;
return 0;
diff --git a/drivers/gpu/drm/i915/i915_params.c 
b/drivers/gpu/drm/i915/i915_params.c
index 7f139ea4a90b..6939634e56ed 100644
--- a/drivers/gpu/drm/i915/i915_params.c
+++ b/drivers/gpu/drm/i915/i915_params.c
@@ -185,7 +185,7 @@ i915_param_named_unsafe(inject_probe_failure, uint, 0400,
 
 i915_param_named(enable_dpcd_backlight, int, 0400,
"Enable support for DPCD backlight control"
-   "(-1=use per-VBT LFP backlight type setting [default], 0=disabled, 
1=enabled)");
+   "(-1=use per-VBT LFP backlight type setting [default], 0=disabled, 
1=enable, 2

[Intel-gfx] [PATCH v6 2/4] drm/i915/dp: Enable Intel's HDR backlight interface (only SDR for now)

2021-01-13 Thread Lyude Paul

So-recently a bunch of laptops on the market have started using DPCD
backlight controls instead of the traditional DDI backlight controls.
Originally we thought we had this handled by adding VESA backlight
control support to i915, but the story ended up being a lot more
complicated then that.

Simply put-there's two main backlight interfaces Intel can see in the
wild. Intel's proprietary HDR backlight interface, and the standard VESA
backlight interface. Note that many panels have been observed to report
support for both backlight interfaces, but testing has shown far more
panels work with the Intel HDR backlight interface at the moment.
Additionally, the VBT appears to be capable of reporting support for the
VESA backlight interface but not the Intel HDR interface which needs to
be probed by setting the right magic OUI.

On top of that however, there's also actually two different variants of
the Intel HDR backlight interface. The first uses the AUX channel for
controlling the brightness of the screen in both SDR and HDR mode, and
the second only uses the AUX channel for setting the brightness level in
HDR mode - relying on PWM for setting the brightness level in SDR mode.

For the time being we've been using EDIDs to maintain a list of quirks
for panels that safely do support the VESA backlight interface. Adding
support for Intel's HDR backlight interface in addition however, should
finally allow us to auto-detect eDP backlight controls properly so long
as we probe like so:

* If the panel's VBT reports VESA backlight support, assume it really
  does support it
* If the panel's VBT reports DDI backlight controls:
  * First probe for Intel's HDR backlight interface
  * If that fails, probe for VESA's backlight interface
  * If that fails, assume no DPCD backlight control
* If the panel's VBT reports any other backlight type: just assume it
  doesn't have DPCD backlight controls

Changes since v4:
* Fix checkpatch issues
Changes since v3:
* Stop using drm_device and use drm_i915_private instead
* Don't forget to return from intel_dp_aux_hdr_get_backlight() if we fail
  to read the current backlight mode from the DPCD
* s/uint8_t/u8/
* Remove unneeded parenthesis in intel_dp_aux_hdr_enable_backlight()
* Use drm_dbg_kms() in intel_dp_aux_init_backlight_funcs()

Signed-off-by: Lyude Paul 
Reviewed-by: Jani Nikula 
Cc: thay...@noraisin.net
Cc: Vasily Khoruzhick 
---
 .../drm/i915/display/intel_display_types.h|   9 +-
 .../drm/i915/display/intel_dp_aux_backlight.c | 247 --
 drivers/gpu/drm/i915/display/intel_panel.c|  42 ++-
 drivers/gpu/drm/i915/display/intel_panel.h|   4 +
 4 files changed, 270 insertions(+), 32 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/intel_display_types.h 
b/drivers/gpu/drm/i915/display/intel_display_types.h
index db5e318a5c1b..7d156ea5cd7f 100644
--- a/drivers/gpu/drm/i915/display/intel_display_types.h
+++ b/drivers/gpu/drm/i915/display/intel_display_types.h
@@ -261,7 +261,14 @@ struct intel_panel {
struct pwm_state pwm_state;
 
/* DPCD backlight */
-   u8 pwmgen_bit_count;
+   union {
+   struct {
+   u8 pwmgen_bit_count;
+   } vesa;
+   struct {
+   bool sdr_uses_aux;
+   } intel;
+   } edp;
 
struct backlight_device *device;
 
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 9775f33d1aac..abfe950259d9 100644
--- a/drivers/gpu/drm/i915/display/intel_dp_aux_backlight.c
+++ b/drivers/gpu/drm/i915/display/intel_dp_aux_backlight.c
@@ -22,8 +22,26 @@
  *
  */
 
+/*
+ * Laptops with Intel GPUs which have panels that support controlling the
+ * backlight through DP AUX can actually use two different interfaces: Intel's
+ * proprietary DP AUX backlight interface, and the standard VESA backlight
+ * interface. Unfortunately, at the time of writing this a lot of laptops will
+ * advertise support for the standard VESA backlight interface when they
+ * don't properly support it. However, on these systems the Intel backlight
+ * interface generally does work properly. Additionally, these systems will
+ * usually just indicate that they use PWM backlight controls in their VBIOS
+ * for some reason.
+ */
+
 #include "intel_display_types.h"
 #include "intel_dp_aux_backlight.h"
+#include "intel_panel.h"
+
+/* TODO:
+ * Implement HDR, right now we just implement the bare minimum to bring us 
back into SDR mode so we
+ * can make people's backlights work in the mean time
+ */
 
 /*
  * DP AUX registers for Intel's proprietary HDR backlight interface. We define
@@ -77,6 +95,178 @@
 
 #define INTEL_EDP_BRIGHTNESS_OPTIMIZATION_10x359
 
+/* Intel EDP backlight callbacks */
+static bool
+intel_dp_aux_supports_hdr_ba

[Intel-gfx] [PATCH v6 1/4] drm/i915: Keep track of pwm-related backlight hooks separately

2021-01-13 Thread Lyude Paul

Currently, every different type of backlight hook that i915 supports is
pretty straight forward - you have a backlight, probably through PWM
(but maybe DPCD), with a single set of platform-specific hooks that are
used for controlling it.

HDR backlights, in particular VESA and Intel's HDR backlight
implementations, can end up being more complicated. With Intel's
proprietary interface, HDR backlight controls always run through the
DPCD. When the backlight is in SDR backlight mode however, the driver
may need to bypass the TCON and control the backlight directly through
PWM.

So, in order to support this we'll need to split our backlight callbacks
into two groups: a set of high-level backlight control callbacks in
intel_panel, and an additional set of pwm-specific backlight control
callbacks. This also implies a functional changes for how these
callbacks are used:

* We now keep track of two separate backlight level ranges, one for the
  high-level backlight, and one for the pwm backlight range
* We also keep track of backlight enablement and PWM backlight
  enablement separately
* Since the currently set backlight level might not be the same as the
  currently programmed PWM backlight level, we stop setting
  panel->backlight.level with the currently programmed PWM backlight
  level in panel->backlight.pwm_funcs->setup(). Instead, we rely
  on the higher level backlight control functions to retrieve the
  current PWM backlight level (in this case, intel_pwm_get_backlight()).
  Note that there are still a few PWM backlight setup callbacks that
  do actually need to retrieve the current PWM backlight level, although
  we no longer save this value in panel->backlight.level like before.

Additionally, we drop the call to lpt_get_backlight() in
lpt_setup_backlight(), and avoid unconditionally writing the PWM value that
we get from it and only write it back if we're in CPU mode, and switching
to PCH mode. The reason for this is because in the original codepath for
this, it was expected that the intel_panel_bl_funcs->setup() hook would be
responsible for fetching the initial backlight level. On lpt systems, the
only time we could ever be in PCH backlight mode is during the initial
driver load - meaning that outside of the setup() hook, lpt_get_backlight()
will always be the callback used for retrieving the current backlight
level. After this patch we still need to fetch and write-back the PCH
backlight value if we're switching from CPU mode to PCH, but because
intel_pwm_setup_backlight() will retrieve the backlight level after setup()
using the get() hook, which always ends up being lpt_get_backlight(). Thus
- an additional call to lpt_get_backlight() in lpt_setup_backlight() is
made redundant.

v7:
* Use panel->backlight.pwm_funcs->get() to get the backlight level in
  intel_pwm_setup_backlight(), lest we upset lockdep
* Rebase
* Rename intel_panel_sanitize_pwm_level() to intel_panel_invert_pwm_level()
v6:
* Make sure to grab connection_mutex before calling
  intel_pwm_get_backlight() in intel_pwm_setup_backlight()
v5:
* Fix indenting warnings from checkpatch
v4:
* Fix commit message
* Remove outdated comment in intel_panel.c
* Rename pwm_(min|max) to pwm_level_(min|max)
* Use intel_pwm_get_backlight() in intel_pwm_setup_backlight() instead of
  indirection
* Don't move intel_dp_aux_init_bcklight_funcs() call to bottom of
  intel_panel_init_backlight_funcs() quite yet
v3:
* Reuse intel_panel_bl_funcs() for pwm_funcs
* Explain why we drop lpt_get_backlight()

Signed-off-by: Lyude Paul 
Reviewed-by: Jani Nikula 
Cc: thay...@noraisin.net
Cc: Vasily Khoruzhick 
---
 .../drm/i915/display/intel_display_types.h|   4 +
 drivers/gpu/drm/i915/display/intel_panel.c| 330 ++
 2 files changed, 187 insertions(+), 147 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/intel_display_types.h 
b/drivers/gpu/drm/i915/display/intel_display_types.h
index 24792102bcf6..db5e318a5c1b 100644
--- a/drivers/gpu/drm/i915/display/intel_display_types.h
+++ b/drivers/gpu/drm/i915/display/intel_display_types.h
@@ -252,6 +252,9 @@ struct intel_panel {
bool alternate_pwm_increment;   /* lpt+ */
 
/* PWM chip */
+   u32 pwm_level_min;
+   u32 pwm_level_max;
+   bool pwm_enabled;
bool util_pin_active_low;   /* bxt+ */
u8 controller;  /* bxt+ only */
struct pwm_device *pwm;
@@ -263,6 +266,7 @@ struct intel_panel {
struct backlight_device *device;
 
const struct intel_panel_bl_funcs *funcs;
+   const struct intel_panel_bl_funcs *pwm_funcs;
void (*power)(struct intel_connector *, bool enable);
} backlight;
 };
diff --git a/drivers/gpu/drm/i915/display/intel_panel.c 
b/drivers/gpu/drm/i915/display/intel_panel.c
index 7a4239d1c241..1e7d2dce7fc3 100644
--- a/drivers/gpu/drm/i915/display/intel_panel.c
+++ b

[Intel-gfx] [PATCH v6 0/4] drm/i915: Add support for Intel's eDP backlight controls

2021-01-13 Thread Lyude Paul

A while ago we ran into issues while trying to enable the eDP backlight
control interface as defined by VESA, in order to make the DPCD
backlight controls on newer laptop panels work. The issue ended up being
much more complicated however, as we also apparently needed to add
support for an Intel-specific DPCD backlight control interface as the
VESA interface is broken on many laptop panels. For lack of a better
name, we just call this the Intel HDR backlight interface.

While this only adds support for the SDR backlight mode (I think), this
will fix a lot of user's laptop panels that we weren't able to properly
automatically detect DPCD backlight controls on previously.

Series-wide changes in v3:
* Pass down brightness values to enable/disable backlight callbacks in a
  separate patch
* Rebase

Lyude Paul (4):
  drm/i915: Keep track of pwm-related backlight hooks separately
  drm/i915/dp: Enable Intel's HDR backlight interface (only SDR for now)
  drm/i915/dp: Allow forcing specific interfaces through
enable_dpcd_backlight
  drm/dp: Revert "drm/dp: Introduce EDID-based quirks"

 drivers/gpu/drm/drm_dp_helper.c   |  83 +---
 drivers/gpu/drm/drm_dp_mst_topology.c |   3 +-
 .../drm/i915/display/intel_display_types.h|  14 +-
 drivers/gpu/drm/i915/display/intel_dp.c   |   9 +-
 .../drm/i915/display/intel_dp_aux_backlight.c | 286 --
 drivers/gpu/drm/i915/display/intel_dp_mst.c   |   3 +-
 drivers/gpu/drm/i915/display/intel_panel.c| 368 +++---
 drivers/gpu/drm/i915/display/intel_panel.h|   4 +
 drivers/gpu/drm/i915/display/intel_psr.c  |   2 +-
 drivers/gpu/drm/i915/i915_params.c|   2 +-
 include/drm/drm_dp_helper.h   |  21 +-
 11 files changed, 504 insertions(+), 291 deletions(-)

-- 
2.29.2

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH] drm/i915/backlight: fix CPU mode backlight takeover on LPT

2021-01-08 Thread Lyude Paul

Reviewed-by: Lyude Paul 

Let me know when you've pushed this upstream and I'll go ahead and send out a
rebased version of my backlight series.

On Fri, 2021-01-08 at 17:28 +0200, Jani Nikula wrote:
> The pch_get_backlight(), lpt_get_backlight(), and lpt_set_backlight()
> functions operate directly on the hardware registers. If inverting the
> value is needed, using intel_panel_compute_brightness(), it should only
> be done in the interface between hardware registers and
> panel->backlight.level.
> 
> The CPU mode takeover code added in commit 5b1ec9ac7ab5
> ("drm/i915/backlight: Fix backlight takeover on LPT, v3.") reads the
> hardware register and converts to panel->backlight.level correctly,
> however the value written back should remain in the hardware register
> "domain".
> 
> This hasn't been an issue, because GM45 machines are the only known
> users of i915.invert_brightness and the brightness invert quirk, and
> without one of them no conversion is made. It's likely nobody's ever hit
> the problem.
> 
> Fixes: 5b1ec9ac7ab5 ("drm/i915/backlight: Fix backlight takeover on LPT, v3.")
> Cc: Maarten Lankhorst 
> Cc: Ville Syrjälä 
> Cc: Lyude Paul 
> Cc:  # v5.1+
> Signed-off-by: Jani Nikula 
> ---
>  drivers/gpu/drm/i915/display/intel_panel.c | 9 +
>  1 file changed, 5 insertions(+), 4 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/display/intel_panel.c
> b/drivers/gpu/drm/i915/display/intel_panel.c
> index 67f81ae995c4..7a4239d1c241 100644
> --- a/drivers/gpu/drm/i915/display/intel_panel.c
> +++ b/drivers/gpu/drm/i915/display/intel_panel.c
> @@ -1649,16 +1649,13 @@ static int lpt_setup_backlight(struct intel_connector
> *connector, enum pipe unus
> val = pch_get_backlight(connector);
> else
> val = lpt_get_backlight(connector);
> -   val = intel_panel_compute_brightness(connector, val);
> -   panel->backlight.level = clamp(val, panel->backlight.min,
> -  panel->backlight.max);
>  
> if (cpu_mode) {
> drm_dbg_kms(_priv->drm,
>     "CPU backlight register was enabled, switching to
> PCH override\n");
>  
> /* Write converted CPU PWM value to PCH override register */
> -   lpt_set_backlight(connector->base.state, panel-
> >backlight.level);
> +   lpt_set_backlight(connector->base.state, val);
> intel_de_write(dev_priv, BLC_PWM_PCH_CTL1,
>    pch_ctl1 | BLM_PCH_OVERRIDE_ENABLE);
>  
> @@ -1666,6 +1663,10 @@ static int lpt_setup_backlight(struct intel_connector
> *connector, enum pipe unus
>    cpu_ctl2 & ~BLM_PWM_ENABLE);
> }
>  
> +   val = intel_panel_compute_brightness(connector, val);
> +   panel->backlight.level = clamp(val, panel->backlight.min,
> +  panel->backlight.max);
> +
> return 0;
>  }
>  

-- 
Sincerely,
   Lyude Paul (she/her)
   Software Engineer at Red Hat
   
Note: I deal with a lot of emails and have a lot of bugs on my plate. If you've
asked me a question, are waiting for a review/merge on a patch, etc. and I
haven't responded in a while, please feel free to send me another email to check
on my status. I don't bite!

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH v5 4/4] drm/dp: Revert "drm/dp: Introduce EDID-based quirks"

2021-01-07 Thread Lyude Paul

This reverts commit 0883ce8146ed6074c76399f4e70dbed788582e12. Originally
these quirks were added because of the issues with using the eDP
backlight interfaces on certain laptop panels, which made it impossible
to properly probe for DPCD backlight support without having a whitelist
for panels that we know have working VESA backlight control interfaces
over DPCD. As well, it should be noted it was impossible to use the
normal sink OUI for recognizing these panels as none of them actually
filled out their OUIs, hence needing to resort to checking EDIDs.

At the time we weren't really sure why certain panels had issues with
DPCD backlight controls, but we eventually figured out that there was a
second interface that these problematic laptop panels actually did work
with and advertise properly: Intel's proprietary backlight interface for
HDR panels. So far the testing we've done hasn't brought any panels to
light that advertise this interface and don't support it properly, which
means we finally have a real solution to this problem.

As a result, we now have no need for the force DPCD backlight quirk, and
furthermore this also removes the need for any kind of EDID quirk
checking in DRM. So, let's just revert it for now since we were the only
driver using this.

v3:
* Rebase
v2:
* Fix indenting error picked up by checkpatch in
  intel_edp_init_connector()

Signed-off-by: Lyude Paul 
Acked-by: Jani Nikula 
Cc: thay...@noraisin.net
Cc: Vasily Khoruzhick 
---
 drivers/gpu/drm/drm_dp_helper.c   | 83 +--
 drivers/gpu/drm/drm_dp_mst_topology.c |  3 +-
 .../drm/i915/display/intel_display_types.h|  1 -
 drivers/gpu/drm/i915/display/intel_dp.c   |  9 +-
 drivers/gpu/drm/i915/display/intel_dp_mst.c   |  3 +-
 drivers/gpu/drm/i915/display/intel_psr.c  |  2 +-
 include/drm/drm_dp_helper.h   | 21 +
 7 files changed, 9 insertions(+), 113 deletions(-)

diff --git a/drivers/gpu/drm/drm_dp_helper.c b/drivers/gpu/drm/drm_dp_helper.c
index 3ecde451f523..19dbdeb581cb 100644
--- a/drivers/gpu/drm/drm_dp_helper.c
+++ b/drivers/gpu/drm/drm_dp_helper.c
@@ -1236,7 +1236,7 @@ bool drm_dp_read_sink_count_cap(struct drm_connector 
*connector,
return connector->connector_type != DRM_MODE_CONNECTOR_eDP &&
dpcd[DP_DPCD_REV] >= DP_DPCD_REV_11 &&
dpcd[DP_DOWNSTREAMPORT_PRESENT] & DP_DWN_STRM_PORT_PRESENT &&
-   !drm_dp_has_quirk(desc, 0, DP_DPCD_QUIRK_NO_SINK_COUNT);
+   !drm_dp_has_quirk(desc, DP_DPCD_QUIRK_NO_SINK_COUNT);
 }
 EXPORT_SYMBOL(drm_dp_read_sink_count_cap);
 
@@ -1957,87 +1957,6 @@ drm_dp_get_quirks(const struct drm_dp_dpcd_ident *ident, 
bool is_branch)
 #undef DEVICE_ID_ANY
 #undef DEVICE_ID
 
-struct edid_quirk {
-   u8 mfg_id[2];
-   u8 prod_id[2];
-   u32 quirks;
-};
-
-#define MFG(first, second) { (first), (second) }
-#define PROD_ID(first, second) { (first), (second) }
-
-/*
- * 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) },
-   { MFG(0x09, 0xe5), PROD_ID(0xde, 0x08), 
BIT(DP_QUIRK_FORCE_DPCD_BACKLIGHT) },
-};
-
-#undef MFG
-#undef PROD_ID
-
-/**
- * drm_dp_get_edid_quirks() - Check the EDID of a DP device to find additional
- * DP-specific quirks
- * @edid: The EDID to check
- *
- * While OUIDs are meant to be used to recognize a DisplayPort device, a lot
- * of manufacturers don't seem to like following standards and neglect to fill
- * the dev-ID in, making it impossible to only use OUIDs for determining
- * quirk

[Intel-gfx] [PATCH v5 2/4] drm/i915/dp: Enable Intel's HDR backlight interface (only SDR for now)

2021-01-07 Thread Lyude Paul

So-recently a bunch of laptops on the market have started using DPCD
backlight controls instead of the traditional DDI backlight controls.
Originally we thought we had this handled by adding VESA backlight
control support to i915, but the story ended up being a lot more
complicated then that.

Simply put-there's two main backlight interfaces Intel can see in the
wild. Intel's proprietary HDR backlight interface, and the standard VESA
backlight interface. Note that many panels have been observed to report
support for both backlight interfaces, but testing has shown far more
panels work with the Intel HDR backlight interface at the moment.
Additionally, the VBT appears to be capable of reporting support for the
VESA backlight interface but not the Intel HDR interface which needs to
be probed by setting the right magic OUI.

On top of that however, there's also actually two different variants of
the Intel HDR backlight interface. The first uses the AUX channel for
controlling the brightness of the screen in both SDR and HDR mode, and
the second only uses the AUX channel for setting the brightness level in
HDR mode - relying on PWM for setting the brightness level in SDR mode.

For the time being we've been using EDIDs to maintain a list of quirks
for panels that safely do support the VESA backlight interface. Adding
support for Intel's HDR backlight interface in addition however, should
finally allow us to auto-detect eDP backlight controls properly so long
as we probe like so:

* If the panel's VBT reports VESA backlight support, assume it really
  does support it
* If the panel's VBT reports DDI backlight controls:
  * First probe for Intel's HDR backlight interface
  * If that fails, probe for VESA's backlight interface
  * If that fails, assume no DPCD backlight control
* If the panel's VBT reports any other backlight type: just assume it
  doesn't have DPCD backlight controls

Changes since v4:
* Fix checkpatch issues
Changes since v3:
* Stop using drm_device and use drm_i915_private instead
* Don't forget to return from intel_dp_aux_hdr_get_backlight() if we fail
  to read the current backlight mode from the DPCD
* s/uint8_t/u8/
* Remove unneeded parenthesis in intel_dp_aux_hdr_enable_backlight()
* Use drm_dbg_kms() in intel_dp_aux_init_backlight_funcs()

Signed-off-by: Lyude Paul 
Acked-by: Jani Nikula 
Cc: thay...@noraisin.net
Cc: Vasily Khoruzhick 
---
 .../drm/i915/display/intel_display_types.h|   9 +-
 .../drm/i915/display/intel_dp_aux_backlight.c | 248 --
 drivers/gpu/drm/i915/display/intel_panel.c|  42 ++-
 drivers/gpu/drm/i915/display/intel_panel.h|   4 +
 4 files changed, 271 insertions(+), 32 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/intel_display_types.h 
b/drivers/gpu/drm/i915/display/intel_display_types.h
index ee5c2d50b81a..b24d80ffd18b 100644
--- a/drivers/gpu/drm/i915/display/intel_display_types.h
+++ b/drivers/gpu/drm/i915/display/intel_display_types.h
@@ -261,7 +261,14 @@ struct intel_panel {
struct pwm_state pwm_state;
 
/* DPCD backlight */
-   u8 pwmgen_bit_count;
+   union {
+   struct {
+   u8 pwmgen_bit_count;
+   } vesa;
+   struct {
+   bool sdr_uses_aux;
+   } intel;
+   } edp;
 
struct backlight_device *device;
 
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 9775f33d1aac..5e761fb49a14 100644
--- a/drivers/gpu/drm/i915/display/intel_dp_aux_backlight.c
+++ b/drivers/gpu/drm/i915/display/intel_dp_aux_backlight.c
@@ -22,8 +22,26 @@
  *
  */
 
+/*
+ * Laptops with Intel GPUs which have panels that support controlling the
+ * backlight through DP AUX can actually use two different interfaces: Intel's
+ * proprietary DP AUX backlight interface, and the standard VESA backlight
+ * interface. Unfortunately, at the time of writing this a lot of laptops will
+ * advertise support for the standard VESA backlight interface when they
+ * don't properly support it. However, on these systems the Intel backlight
+ * interface generally does work properly. Additionally, these systems will
+ * usually just indicate that they use PWM backlight controls in their VBIOS
+ * for some reason.
+ */
+
 #include "intel_display_types.h"
 #include "intel_dp_aux_backlight.h"
+#include "intel_panel.h"
+
+/* TODO:
+ * Implement HDR, right now we just implement the bare minimum to bring us 
back into SDR mode so we
+ * can make people's backlights work in the mean time
+ */
 
 /*
  * DP AUX registers for Intel's proprietary HDR backlight interface. We define
@@ -77,6 +95,179 @@
 
 #define INTEL_EDP_BRIGHTNESS_OPTIMIZATION_10x359
 
+/* Intel EDP backlight callbacks */
+static bool
+intel_dp_aux_supports_hdr_ba

[Intel-gfx] [PATCH v5 3/4] drm/i915/dp: Allow forcing specific interfaces through enable_dpcd_backlight

2021-01-07 Thread Lyude Paul

Since we now support controlling panel backlights through DPCD using
both the standard VESA interface, and Intel's proprietary HDR backlight
interface, we should allow the user to be able to explicitly choose
between one or the other in the event that we're wrong about panels
reliably reporting support for the Intel HDR interface.

So, this commit adds support for this by introducing two new
enable_dpcd_backlight options: 2 which forces i915 to only probe for the
VESA interface, and 3 which forces i915 to only probe for the Intel
backlight interface (might be useful if we find panels in the wild that
report the VESA interface in their VBT, but actually only support the
Intel backlight interface).

v3:
* Rebase

Signed-off-by: Lyude Paul 
Reviewed-by: Jani Nikula 
Cc: thay...@noraisin.net
Cc: Vasily Khoruzhick 
---
 .../drm/i915/display/intel_dp_aux_backlight.c | 45 +--
 drivers/gpu/drm/i915/i915_params.c|  2 +-
 2 files changed, 43 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/intel_dp_aux_backlight.c 
b/drivers/gpu/drm/i915/display/intel_dp_aux_backlight.c
index 5e761fb49a14..4b2cb20b1f94 100644
--- a/drivers/gpu/drm/i915/display/intel_dp_aux_backlight.c
+++ b/drivers/gpu/drm/i915/display/intel_dp_aux_backlight.c
@@ -613,15 +613,54 @@ static const struct intel_panel_bl_funcs 
intel_dp_vesa_bl_funcs = {
.get = intel_dp_aux_vesa_get_backlight,
 };
 
+enum intel_dp_aux_backlight_modparam {
+   INTEL_DP_AUX_BACKLIGHT_AUTO = -1,
+   INTEL_DP_AUX_BACKLIGHT_OFF = 0,
+   INTEL_DP_AUX_BACKLIGHT_ON = 1,
+   INTEL_DP_AUX_BACKLIGHT_FORCE_VESA = 2,
+   INTEL_DP_AUX_BACKLIGHT_FORCE_INTEL = 3,
+};
+
 int intel_dp_aux_init_backlight_funcs(struct intel_connector *connector)
 {
struct drm_device *dev = connector->base.dev;
struct intel_panel *panel = >panel;
struct intel_dp *intel_dp = enc_to_intel_dp(connector->encoder);
struct drm_i915_private *i915 = dp_to_i915(intel_dp);
+   bool try_intel_interface = false, try_vesa_interface = false;
 
-   if (i915->params.enable_dpcd_backlight == 0)
+   /* Check the VBT and user's module parameters to figure out which
+* interfaces to probe
+*/
+   switch (i915->params.enable_dpcd_backlight) {
+   case INTEL_DP_AUX_BACKLIGHT_OFF:
return -ENODEV;
+   case INTEL_DP_AUX_BACKLIGHT_AUTO:
+   switch (i915->vbt.backlight.type) {
+   case INTEL_BACKLIGHT_VESA_EDP_AUX_INTERFACE:
+   try_vesa_interface = true;
+   break;
+   case INTEL_BACKLIGHT_DISPLAY_DDI:
+   try_intel_interface = true;
+   try_vesa_interface = true;
+   break;
+   default:
+   return -ENODEV;
+   }
+   break;
+   case INTEL_DP_AUX_BACKLIGHT_ON:
+   if (i915->vbt.backlight.type != 
INTEL_BACKLIGHT_VESA_EDP_AUX_INTERFACE)
+   try_intel_interface = true;
+
+   try_vesa_interface = true;
+   break;
+   case INTEL_DP_AUX_BACKLIGHT_FORCE_VESA:
+   try_vesa_interface = true;
+   break;
+   case INTEL_DP_AUX_BACKLIGHT_FORCE_INTEL:
+   try_intel_interface = true;
+   break;
+   }
 
/*
 * A lot of eDP panels in the wild will report supporting both the
@@ -630,13 +669,13 @@ int intel_dp_aux_init_backlight_funcs(struct 
intel_connector *connector)
 * and will only work with the Intel interface. So, always probe for
 * that first.
 */
-   if (intel_dp_aux_supports_hdr_backlight(connector)) {
+   if (try_intel_interface && 
intel_dp_aux_supports_hdr_backlight(connector)) {
drm_dbg_kms(dev, "Using Intel proprietary eDP backlight 
controls\n");
panel->backlight.funcs = _dp_hdr_bl_funcs;
return 0;
}
 
-   if (intel_dp_aux_supports_vesa_backlight(connector)) {
+   if (try_vesa_interface && 
intel_dp_aux_supports_vesa_backlight(connector)) {
drm_dbg_kms(dev, "Using VESA eDP backlight controls\n");
panel->backlight.funcs = _dp_vesa_bl_funcs;
return 0;
diff --git a/drivers/gpu/drm/i915/i915_params.c 
b/drivers/gpu/drm/i915/i915_params.c
index 7f139ea4a90b..6939634e56ed 100644
--- a/drivers/gpu/drm/i915/i915_params.c
+++ b/drivers/gpu/drm/i915/i915_params.c
@@ -185,7 +185,7 @@ i915_param_named_unsafe(inject_probe_failure, uint, 0400,
 
 i915_param_named(enable_dpcd_backlight, int, 0400,
"Enable support for DPCD backlight control"
-   "(-1=use per-VBT LFP backlight type setting [default], 0=disabled, 
1=enabled)");
+   "(-1=use per-VBT LFP backlight type setting [default], 0=disabled, 
1=enable, 2

[Intel-gfx] [PATCH v5 1/4] drm/i915: Keep track of pwm-related backlight hooks separately

2021-01-07 Thread Lyude Paul

Currently, every different type of backlight hook that i915 supports is
pretty straight forward - you have a backlight, probably through PWM
(but maybe DPCD), with a single set of platform-specific hooks that are
used for controlling it.

HDR backlights, in particular VESA and Intel's HDR backlight
implementations, can end up being more complicated. With Intel's
proprietary interface, HDR backlight controls always run through the
DPCD. When the backlight is in SDR backlight mode however, the driver
may need to bypass the TCON and control the backlight directly through
PWM.

So, in order to support this we'll need to split our backlight callbacks
into two groups: a set of high-level backlight control callbacks in
intel_panel, and an additional set of pwm-specific backlight control
callbacks. This also implies a functional changes for how these
callbacks are used:

* We now keep track of two separate backlight level ranges, one for the
  high-level backlight, and one for the pwm backlight range
* We also keep track of backlight enablement and PWM backlight
  enablement separately
* Since the currently set backlight level might not be the same as the
  currently programmed PWM backlight level, we stop setting
  panel->backlight.level with the currently programmed PWM backlight
  level in panel->backlight.pwm_funcs->setup(). Instead, we rely
  on the higher level backlight control functions to retrieve the
  current PWM backlight level (in this case, intel_pwm_get_backlight()).
  Note that there are still a few PWM backlight setup callbacks that
  do actually need to retrieve the current PWM backlight level, although
  we no longer save this value in panel->backlight.level like before.

Additionally, we drop the call to lpt_get_backlight() in
lpt_setup_backlight(), and avoid unconditionally writing the PWM value that
we get from it and only write it back if we're in CPU mode, and switching
to PCH mode. The reason for this is because in the original codepath for
this, it was expected that the intel_panel_bl_funcs->setup() hook would be
responsible for fetching the initial backlight level. On lpt systems, the
only time we could ever be in PCH backlight mode is during the initial
driver load - meaning that outside of the setup() hook, lpt_get_backlight()
will always be the callback used for retrieving the current backlight
level. After this patch we still need to fetch and write-back the PCH
backlight value if we're switching from CPU mode to PCH, but because
intel_pwm_setup_backlight() will retrieve the backlight level after setup()
using the get() hook, which always ends up being lpt_get_backlight(). Thus
- an additional call to lpt_get_backlight() in lpt_setup_backlight() is
made redundant.

v5:
* Fix indenting warnings from checkpatch
v4:
* Fix commit message
* Remove outdated comment in intel_panel.c
* Rename pwm_(min|max) to pwm_level_(min|max)
* Use intel_pwm_get_backlight() in intel_pwm_setup_backlight() instead of
  indirection
* Don't move intel_dp_aux_init_bcklight_funcs() call to bottom of
  intel_panel_init_backlight_funcs() quite yet
v3:
* Reuse intel_panel_bl_funcs() for pwm_funcs
* Explain why we drop lpt_get_backlight()

Signed-off-by: Lyude Paul 
Cc: thay...@noraisin.net
Cc: Vasily Khoruzhick 
---
 .../drm/i915/display/intel_display_types.h|   4 +
 drivers/gpu/drm/i915/display/intel_panel.c| 333 ++
 2 files changed, 187 insertions(+), 150 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/intel_display_types.h 
b/drivers/gpu/drm/i915/display/intel_display_types.h
index 1067bd073c95..ee5c2d50b81a 100644
--- a/drivers/gpu/drm/i915/display/intel_display_types.h
+++ b/drivers/gpu/drm/i915/display/intel_display_types.h
@@ -252,6 +252,9 @@ struct intel_panel {
bool alternate_pwm_increment;   /* lpt+ */
 
/* PWM chip */
+   u32 pwm_level_min;
+   u32 pwm_level_max;
+   bool pwm_enabled;
bool util_pin_active_low;   /* bxt+ */
u8 controller;  /* bxt+ only */
struct pwm_device *pwm;
@@ -263,6 +266,7 @@ struct intel_panel {
struct backlight_device *device;
 
const struct intel_panel_bl_funcs *funcs;
+   const struct intel_panel_bl_funcs *pwm_funcs;
void (*power)(struct intel_connector *, bool enable);
} backlight;
 };
diff --git a/drivers/gpu/drm/i915/display/intel_panel.c 
b/drivers/gpu/drm/i915/display/intel_panel.c
index 67f81ae995c4..8c99bf404a32 100644
--- a/drivers/gpu/drm/i915/display/intel_panel.c
+++ b/drivers/gpu/drm/i915/display/intel_panel.c
@@ -511,25 +511,34 @@ static u32 scale_hw_to_user(struct intel_connector 
*connector,
 0, user_max);
 }
 
-static u32 intel_panel_compute_brightness(struct intel_connector *connector,
- u32 val)
+static u32 intel_panel_sanitize_pwm_level(struct intel_connector *

[Intel-gfx] [PATCH v5 0/4] drm/i915: Add support for Intel's eDP backlight controls

2021-01-07 Thread Lyude Paul

A while ago we ran into issues while trying to enable the eDP backlight
control interface as defined by VESA, in order to make the DPCD
backlight controls on newer laptop panels work. The issue ended up being
much more complicated however, as we also apparently needed to add
support for an Intel-specific DPCD backlight control interface as the
VESA interface is broken on many laptop panels. For lack of a better
name, we just call this the Intel HDR backlight interface.

While this only adds support for the SDR backlight mode (I think), this
will fix a lot of user's laptop panels that we weren't able to properly
automatically detect DPCD backlight controls on previously.

Series-wide changes in v3:
* Pass down brightness values to enable/disable backlight callbacks in a
  separate patch
* Rebase

Lyude Paul (4):
  drm/i915: Keep track of pwm-related backlight hooks separately
  drm/i915/dp: Enable Intel's HDR backlight interface (only SDR for now)
  drm/i915/dp: Allow forcing specific interfaces through
enable_dpcd_backlight
  drm/dp: Revert "drm/dp: Introduce EDID-based quirks"

 drivers/gpu/drm/drm_dp_helper.c   |  83 +---
 drivers/gpu/drm/drm_dp_mst_topology.c |   3 +-
 .../drm/i915/display/intel_display_types.h|  14 +-
 drivers/gpu/drm/i915/display/intel_dp.c   |   9 +-
 .../drm/i915/display/intel_dp_aux_backlight.c | 287 --
 drivers/gpu/drm/i915/display/intel_dp_mst.c   |   3 +-
 drivers/gpu/drm/i915/display/intel_panel.c| 371 ++
 drivers/gpu/drm/i915/display/intel_panel.h|   4 +
 drivers/gpu/drm/i915/display/intel_psr.c  |   2 +-
 drivers/gpu/drm/i915/i915_params.c|   2 +-
 include/drm/drm_dp_helper.h   |  21 +-
 11 files changed, 505 insertions(+), 294 deletions(-)

-- 
2.29.2

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH V2] drm/i915/cml : Add TGP PCH support

2021-01-06 Thread Lyude Paul

= tgl_hpd_pin(dev_priv, port); diff --git
> > > > > a/drivers/gpu/drm/i915/display/intel_display.c
> > > > > b/drivers/gpu/drm/i915/display/intel_display.c
> > > > > index f2c48e5cdb43..47014471658f 100644
> > > > > --- a/drivers/gpu/drm/i915/display/intel_display.c
> > > > > +++ b/drivers/gpu/drm/i915/display/intel_display.c
> > > > > @@ -16163,6 +16163,11 @@ static void intel_setup_outputs(struct
> > > > drm_i915_private *dev_priv)
> > > > >  intel_ddi_init(dev_priv, PORT_F);
> > > > > 
> > > > >  icl_dsi_init(dev_priv);
> > > > > +} else if (IS_COMETLAKE(dev_priv) && HAS_PCH_TGP(dev_priv)) {
> > > > > +intel_ddi_init(dev_priv, PORT_A); intel_ddi_init(dev_priv,
> > > > > +PORT_B); intel_ddi_init(dev_priv, PORT_C);
> > > > > +intel_ddi_init(dev_priv, PORT_D);
> > > > 
> > > > As noted before, this relates to gen9bc in general, not just CML.
> > > > 
> > > Tejas : I will add GEN9BC check here with TGP specific handle.
> > > 
> > > > Is the only reason for this block because TGP's instance of
> > > > SFUSE_STRAP doesn't have output presence bits anymore?  If you want,
> > > > you could keep using the existing gen9bc block for consistency, but
> > > > make the SFUSE_STRAP checks themselves conditional on a platform
> > > > that has the presence bits.  E.g.,
> > > > 
> > > Tejas : I am not much familiar with STRAP, can I go ahead with above
> > approach GEN9BC && TGP PCH check?
> > 
> > The output initialization is already a bit of a mess (and we plan to
> > overhaul
> > the design soon), so adding special case conditions like this just makes
> > it
> > more complicated and harder to follow.  I'm asking what led you to create
> > a
> > new block rather than just letting the existing block continue to be
> > used.  I
> > can see where TGP's lack of strap bits could be a problem (since reading
> > those bits as 0 would incorrectly lead you to believe that the output
> > didn't
> > exist), but if that's the only thing you were trying to avoid, then it's
> > probably
> > simpler to just update the place we read the fuse value.  Were there other
> > reasons you also decided to create a new block?
> 
> Tejas : As I told I am not much clear with STRAP logic, but the observation
> was that only port A output was getting initialized by default. Okay I will
> avoid fuse checks for GEN9 BC && TGP PCH case and use existing blocks.
> > 
> > 
> > > 
> > > >     /* ICP+ no longer has port presence bits */
> > > >     found = INTEL_PCH_TYPE(dev_priv) >= PCH_ICP ?
> > > >     ~0 : intel_de_read(dev_priv, SFUSE_STRAP);
> > > > 
> > > > >  } else if (IS_GEN9_LP(dev_priv)) {
> > > > >  /*
> > > > >   * FIXME: Broxton doesn't support port detection via the diff -
> > > > -git
> > > > > a/drivers/gpu/drm/i915/display/intel_hdmi.c
> > > > > b/drivers/gpu/drm/i915/display/intel_hdmi.c
> > > > > index c5959590562b..540c9d54b595 100644
> > > > > --- a/drivers/gpu/drm/i915/display/intel_hdmi.c
> > > > > +++ b/drivers/gpu/drm/i915/display/intel_hdmi.c
> > > > > @@ -3174,7 +3174,8 @@ static u8 intel_hdmi_ddc_pin(struct
> > > > > intel_encoder *encoder)
> > > > > 
> > > > >  if (INTEL_PCH_TYPE(dev_priv) >= PCH_DG1)  ddc_pin =
> > > > > dg1_port_to_ddc_pin(dev_priv, port); -else if
> > > > > (IS_ROCKETLAKE(dev_priv))
> > > > > +else if (IS_ROCKETLAKE(dev_priv) || (IS_COMETLAKE(dev_priv) &&
> > > > > + HAS_PCH_TGP(dev_priv)))
> > > > >  ddc_pin = rkl_port_to_ddc_pin(dev_priv, port);
> > > > 
> > > > As above, none of the changes in this patch have any relation to
> > > > RKL, so it doesn't make sense to update the RKL condition.  Instead
> > > > just add the gen9bc port mapping logic to icl_port_to_ddc_pin().
> > > > 
> > > Tejas : Ok.
> > > > Plus, it looks like what you have here right now will make the same
> > > > mapping mistake for C and D that the HPD logic did.
> > > > 
> > > Tejas : It is doing proper pin mapping. Its tested by us on RVP and by
> > > DELL.
> > 
> > Are you sure this was fully tested and you didn't forget any of the
> > outputs?
> > The first thing the function does is
> > 
> >     WARN_ON(port == PORT_C);
> > 
> > which means that you should have immediately started seeing warnings on
> > any CML platforms with an HDMI output on DDI-C (which is a valid setup).
> > What we should be warning on is PORT_A since gen9 platforms like CML
> > can't handle HDMI on port A.
> Tejas : Warns are coming, but they will not affect result. However I am
> planning to remove/update warns in the next patch versions. Also yes we have
> tested with 4 (A,B,C,D) outputs. I know the fact that CML has E output as
> well but I have not added it, should I add that also?. So far RKL (UDIMM)
> RVP + TGP (with all ports), RKL (SODIMM) RVP + TGP (with all ports), CML
> (UDIMM) RVP + TGP (with A,B,C,D ports), CML (SODIMM) RVP + TGP (with A,B,C,D
> ports), AIO(Canonical/Wostron, CML CPU(RKL RVP) + TGP PCH), Caribou(Dell
> board, CML CPU(RKL RVP) + TGP PCH), Seal(Dell board, CML CPU(RKL RVP) + TGP
> PCH), Proghron(Canonical/Wostron, CML CPU(RKL RVP) + TGP PCH) boards are
> tested and successfully able to enumerate all the ports (including HDMI on
> every board).
> > 
> > 
> > Matt
> > 
> > > > 
> > > > Matt
> > > > 
> > > > >  else if (HAS_PCH_MCC(dev_priv))
> > > > >  ddc_pin = mcc_port_to_ddc_pin(dev_priv, port);
> > > > > --
> > > > > 2.28.0
> > > > > 
> > > > > ___
> > > > > Intel-gfx mailing list
> > > > > Intel-gfx@lists.freedesktop.org
> > > > > https://lists.freedesktop.org/mailman/listinfo/intel-gfx
> > > > 
> > > > --
> > > > Matt Roper
> > > > Graphics Software Engineer
> > > > VTT-OSGC Platform Enablement
> > > > Intel Corporation
> > > > (916) 356-2795
> > 
> > --
> > Matt Roper
> > Graphics Software Engineer
> > VTT-OSGC Platform Enablement
> > Intel Corporation
> > (916) 356-2795
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
> 

-- 
Cheers,
 Lyude Paul (she/her)
 Software Engineer at Red Hat

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH v4 4/4] drm/dp: Revert "drm/dp: Introduce EDID-based quirks"

2021-01-05 Thread Lyude Paul

This reverts commit 0883ce8146ed6074c76399f4e70dbed788582e12. Originally
these quirks were added because of the issues with using the eDP
backlight interfaces on certain laptop panels, which made it impossible
to properly probe for DPCD backlight support without having a whitelist
for panels that we know have working VESA backlight control interfaces
over DPCD. As well, it should be noted it was impossible to use the
normal sink OUI for recognizing these panels as none of them actually
filled out their OUIs, hence needing to resort to checking EDIDs.

At the time we weren't really sure why certain panels had issues with
DPCD backlight controls, but we eventually figured out that there was a
second interface that these problematic laptop panels actually did work
with and advertise properly: Intel's proprietary backlight interface for
HDR panels. So far the testing we've done hasn't brought any panels to
light that advertise this interface and don't support it properly, which
means we finally have a real solution to this problem.

As a result, we now have no need for the force DPCD backlight quirk, and
furthermore this also removes the need for any kind of EDID quirk
checking in DRM. So, let's just revert it for now since we were the only
driver using this.

v3:
* Rebase
v2:
* Fix indenting error picked up by checkpatch in
  intel_edp_init_connector()

Signed-off-by: Lyude Paul 
Acked-by: Jani Nikula 
Cc: thay...@noraisin.net
Cc: Vasily Khoruzhick 
---
 drivers/gpu/drm/drm_dp_helper.c   | 83 +--
 drivers/gpu/drm/drm_dp_mst_topology.c |  3 +-
 .../drm/i915/display/intel_display_types.h|  1 -
 drivers/gpu/drm/i915/display/intel_dp.c   |  9 +-
 drivers/gpu/drm/i915/display/intel_dp_mst.c   |  3 +-
 drivers/gpu/drm/i915/display/intel_psr.c  |  2 +-
 include/drm/drm_dp_helper.h   | 21 +
 7 files changed, 9 insertions(+), 113 deletions(-)

diff --git a/drivers/gpu/drm/drm_dp_helper.c b/drivers/gpu/drm/drm_dp_helper.c
index 3ecde451f523..19dbdeb581cb 100644
--- a/drivers/gpu/drm/drm_dp_helper.c
+++ b/drivers/gpu/drm/drm_dp_helper.c
@@ -1236,7 +1236,7 @@ bool drm_dp_read_sink_count_cap(struct drm_connector 
*connector,
return connector->connector_type != DRM_MODE_CONNECTOR_eDP &&
dpcd[DP_DPCD_REV] >= DP_DPCD_REV_11 &&
dpcd[DP_DOWNSTREAMPORT_PRESENT] & DP_DWN_STRM_PORT_PRESENT &&
-   !drm_dp_has_quirk(desc, 0, DP_DPCD_QUIRK_NO_SINK_COUNT);
+   !drm_dp_has_quirk(desc, DP_DPCD_QUIRK_NO_SINK_COUNT);
 }
 EXPORT_SYMBOL(drm_dp_read_sink_count_cap);
 
@@ -1957,87 +1957,6 @@ drm_dp_get_quirks(const struct drm_dp_dpcd_ident *ident, 
bool is_branch)
 #undef DEVICE_ID_ANY
 #undef DEVICE_ID
 
-struct edid_quirk {
-   u8 mfg_id[2];
-   u8 prod_id[2];
-   u32 quirks;
-};
-
-#define MFG(first, second) { (first), (second) }
-#define PROD_ID(first, second) { (first), (second) }
-
-/*
- * 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) },
-   { MFG(0x09, 0xe5), PROD_ID(0xde, 0x08), 
BIT(DP_QUIRK_FORCE_DPCD_BACKLIGHT) },
-};
-
-#undef MFG
-#undef PROD_ID
-
-/**
- * drm_dp_get_edid_quirks() - Check the EDID of a DP device to find additional
- * DP-specific quirks
- * @edid: The EDID to check
- *
- * While OUIDs are meant to be used to recognize a DisplayPort device, a lot
- * of manufacturers don't seem to like following standards and neglect to fill
- * the dev-ID in, making it impossible to only use OUIDs for determining
- * quirk

[Intel-gfx] [PATCH v4 3/4] drm/i915/dp: Allow forcing specific interfaces through enable_dpcd_backlight

2021-01-05 Thread Lyude Paul

Since we now support controlling panel backlights through DPCD using
both the standard VESA interface, and Intel's proprietary HDR backlight
interface, we should allow the user to be able to explicitly choose
between one or the other in the event that we're wrong about panels
reliably reporting support for the Intel HDR interface.

So, this commit adds support for this by introducing two new
enable_dpcd_backlight options: 2 which forces i915 to only probe for the
VESA interface, and 3 which forces i915 to only probe for the Intel
backlight interface (might be useful if we find panels in the wild that
report the VESA interface in their VBT, but actually only support the
Intel backlight interface).

v3:
* Rebase

Signed-off-by: Lyude Paul 
Reviewed-by: Jani Nikula 
Cc: thay...@noraisin.net
Cc: Vasily Khoruzhick 
---
 .../drm/i915/display/intel_dp_aux_backlight.c | 45 +--
 drivers/gpu/drm/i915/i915_params.c|  2 +-
 2 files changed, 43 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/intel_dp_aux_backlight.c 
b/drivers/gpu/drm/i915/display/intel_dp_aux_backlight.c
index 5eb472eb304f..94a9e3b1f24c 100644
--- a/drivers/gpu/drm/i915/display/intel_dp_aux_backlight.c
+++ b/drivers/gpu/drm/i915/display/intel_dp_aux_backlight.c
@@ -611,15 +611,54 @@ static const struct intel_panel_bl_funcs 
intel_dp_vesa_bl_funcs = {
.get = intel_dp_aux_vesa_get_backlight,
 };
 
+enum intel_dp_aux_backlight_modparam {
+   INTEL_DP_AUX_BACKLIGHT_AUTO = -1,
+   INTEL_DP_AUX_BACKLIGHT_OFF = 0,
+   INTEL_DP_AUX_BACKLIGHT_ON = 1,
+   INTEL_DP_AUX_BACKLIGHT_FORCE_VESA = 2,
+   INTEL_DP_AUX_BACKLIGHT_FORCE_INTEL = 3,
+};
+
 int intel_dp_aux_init_backlight_funcs(struct intel_connector *connector)
 {
struct drm_device *dev = connector->base.dev;
struct intel_panel *panel = >panel;
struct intel_dp *intel_dp = enc_to_intel_dp(connector->encoder);
struct drm_i915_private *i915 = dp_to_i915(intel_dp);
+   bool try_intel_interface = false, try_vesa_interface = false;
 
-   if (i915->params.enable_dpcd_backlight == 0)
+   /* Check the VBT and user's module parameters to figure out which
+* interfaces to probe
+*/
+   switch (i915->params.enable_dpcd_backlight) {
+   case INTEL_DP_AUX_BACKLIGHT_OFF:
return -ENODEV;
+   case INTEL_DP_AUX_BACKLIGHT_AUTO:
+   switch (i915->vbt.backlight.type) {
+   case INTEL_BACKLIGHT_VESA_EDP_AUX_INTERFACE:
+   try_vesa_interface = true;
+   break;
+   case INTEL_BACKLIGHT_DISPLAY_DDI:
+   try_intel_interface = true;
+   try_vesa_interface = true;
+   break;
+   default:
+   return -ENODEV;
+   }
+   break;
+   case INTEL_DP_AUX_BACKLIGHT_ON:
+   if (i915->vbt.backlight.type != 
INTEL_BACKLIGHT_VESA_EDP_AUX_INTERFACE)
+   try_intel_interface = true;
+
+   try_vesa_interface = true;
+   break;
+   case INTEL_DP_AUX_BACKLIGHT_FORCE_VESA:
+   try_vesa_interface = true;
+   break;
+   case INTEL_DP_AUX_BACKLIGHT_FORCE_INTEL:
+   try_intel_interface = true;
+   break;
+   }
 
/*
 * A lot of eDP panels in the wild will report supporting both the
@@ -628,13 +667,13 @@ int intel_dp_aux_init_backlight_funcs(struct 
intel_connector *connector)
 * and will only work with the Intel interface. So, always probe for
 * that first.
 */
-   if (intel_dp_aux_supports_hdr_backlight(connector)) {
+   if (try_intel_interface && 
intel_dp_aux_supports_hdr_backlight(connector)) {
drm_dbg_kms(dev, "Using Intel proprietary eDP backlight 
controls\n");
panel->backlight.funcs = _dp_hdr_bl_funcs;
return 0;
}
 
-   if (intel_dp_aux_supports_vesa_backlight(connector)) {
+   if (try_vesa_interface && 
intel_dp_aux_supports_vesa_backlight(connector)) {
drm_dbg_kms(dev, "Using VESA eDP backlight controls\n");
panel->backlight.funcs = _dp_vesa_bl_funcs;
return 0;
diff --git a/drivers/gpu/drm/i915/i915_params.c 
b/drivers/gpu/drm/i915/i915_params.c
index 7f139ea4a90b..6939634e56ed 100644
--- a/drivers/gpu/drm/i915/i915_params.c
+++ b/drivers/gpu/drm/i915/i915_params.c
@@ -185,7 +185,7 @@ i915_param_named_unsafe(inject_probe_failure, uint, 0400,
 
 i915_param_named(enable_dpcd_backlight, int, 0400,
"Enable support for DPCD backlight control"
-   "(-1=use per-VBT LFP backlight type setting [default], 0=disabled, 
1=enabled)");
+   "(-1=use per-VBT LFP backlight type setting [default], 0=disabled, 
1=enable, 2

[Intel-gfx] [PATCH v4 2/4] drm/i915/dp: Enable Intel's HDR backlight interface (only SDR for now)

2021-01-05 Thread Lyude Paul

So-recently a bunch of laptops on the market have started using DPCD
backlight controls instead of the traditional DDI backlight controls.
Originally we thought we had this handled by adding VESA backlight
control support to i915, but the story ended up being a lot more
complicated then that.

Simply put-there's two main backlight interfaces Intel can see in the
wild. Intel's proprietary HDR backlight interface, and the standard VESA
backlight interface. Note that many panels have been observed to report
support for both backlight interfaces, but testing has shown far more
panels work with the Intel HDR backlight interface at the moment.
Additionally, the VBT appears to be capable of reporting support for the
VESA backlight interface but not the Intel HDR interface which needs to
be probed by setting the right magic OUI.

On top of that however, there's also actually two different variants of
the Intel HDR backlight interface. The first uses the AUX channel for
controlling the brightness of the screen in both SDR and HDR mode, and
the second only uses the AUX channel for setting the brightness level in
HDR mode - relying on PWM for setting the brightness level in SDR mode.

For the time being we've been using EDIDs to maintain a list of quirks
for panels that safely do support the VESA backlight interface. Adding
support for Intel's HDR backlight interface in addition however, should
finally allow us to auto-detect eDP backlight controls properly so long
as we probe like so:

* If the panel's VBT reports VESA backlight support, assume it really
  does support it
* If the panel's VBT reports DDI backlight controls:
  * First probe for Intel's HDR backlight interface
  * If that fails, probe for VESA's backlight interface
  * If that fails, assume no DPCD backlight control
* If the panel's VBT reports any other backlight type: just assume it
  doesn't have DPCD backlight controls

Changes since v3:
* Stop using drm_device and use drm_i915_private instead
* Don't forget to return from intel_dp_aux_hdr_get_backlight() if we fail
  to read the current backlight mode from the DPCD
* s/uint8_t/u8/
* Remove unneeded parenthesis in intel_dp_aux_hdr_enable_backlight()
* Use drm_dbg_kms() in intel_dp_aux_init_backlight_funcs()

Signed-off-by: Lyude Paul 
Acked-by: Jani Nikula 
Cc: thay...@noraisin.net
Cc: Vasily Khoruzhick 
---
 .../drm/i915/display/intel_display_types.h|   9 +-
 .../drm/i915/display/intel_dp_aux_backlight.c | 246 --
 drivers/gpu/drm/i915/display/intel_panel.c|  42 ++-
 drivers/gpu/drm/i915/display/intel_panel.h|   4 +
 4 files changed, 269 insertions(+), 32 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/intel_display_types.h 
b/drivers/gpu/drm/i915/display/intel_display_types.h
index ee5c2d50b81a..b24d80ffd18b 100644
--- a/drivers/gpu/drm/i915/display/intel_display_types.h
+++ b/drivers/gpu/drm/i915/display/intel_display_types.h
@@ -261,7 +261,14 @@ struct intel_panel {
struct pwm_state pwm_state;
 
/* DPCD backlight */
-   u8 pwmgen_bit_count;
+   union {
+   struct {
+   u8 pwmgen_bit_count;
+   } vesa;
+   struct {
+   bool sdr_uses_aux;
+   } intel;
+   } edp;
 
struct backlight_device *device;
 
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 9775f33d1aac..5eb472eb304f 100644
--- a/drivers/gpu/drm/i915/display/intel_dp_aux_backlight.c
+++ b/drivers/gpu/drm/i915/display/intel_dp_aux_backlight.c
@@ -22,8 +22,26 @@
  *
  */
 
+/*
+ * Laptops with Intel GPUs which have panels that support controlling the
+ * backlight through DP AUX can actually use two different interfaces: Intel's
+ * proprietary DP AUX backlight interface, and the standard VESA backlight
+ * interface. Unfortunately, at the time of writing this a lot of laptops will
+ * advertise support for the standard VESA backlight interface when they
+ * don't properly support it. However, on these systems the Intel backlight
+ * interface generally does work properly. Additionally, these systems will
+ * usually just indicate that they use PWM backlight controls in their VBIOS
+ * for some reason.
+ */
+
 #include "intel_display_types.h"
 #include "intel_dp_aux_backlight.h"
+#include "intel_panel.h"
+
+/* TODO:
+ * Implement HDR, right now we just implement the bare minimum to bring us 
back into SDR mode so we
+ * can make people's backlights work in the mean time
+ */
 
 /*
  * DP AUX registers for Intel's proprietary HDR backlight interface. We define
@@ -77,6 +95,177 @@
 
 #define INTEL_EDP_BRIGHTNESS_OPTIMIZATION_10x359
 
+/* Intel EDP backlight callbacks */
+static bool
+intel_dp_aux_supports_hdr_backlight(struct intel_connector

[Intel-gfx] [PATCH v4 1/4] drm/i915: Keep track of pwm-related backlight hooks separately

2021-01-05 Thread Lyude Paul

Currently, every different type of backlight hook that i915 supports is
pretty straight forward - you have a backlight, probably through PWM
(but maybe DPCD), with a single set of platform-specific hooks that are
used for controlling it.

HDR backlights, in particular VESA and Intel's HDR backlight
implementations, can end up being more complicated. With Intel's
proprietary interface, HDR backlight controls always run through the
DPCD. When the backlight is in SDR backlight mode however, the driver
may need to bypass the TCON and control the backlight directly through
PWM.

So, in order to support this we'll need to split our backlight callbacks
into two groups: a set of high-level backlight control callbacks in
intel_panel, and an additional set of pwm-specific backlight control
callbacks. This also implies a functional changes for how these
callbacks are used:

* We now keep track of two separate backlight level ranges, one for the
  high-level backlight, and one for the pwm backlight range
* We also keep track of backlight enablement and PWM backlight
  enablement separately
* Since the currently set backlight level might not be the same as the
  currently programmed PWM backlight level, we stop setting
  panel->backlight.level with the currently programmed PWM backlight
  level in panel->backlight.pwm_funcs->setup(). Instead, we rely
  on the higher level backlight control functions to retrieve the
  current PWM backlight level (in this case, intel_pwm_get_backlight()).
  Note that there are still a few PWM backlight setup callbacks that
  do actually need to retrieve the current PWM backlight level, although
  we no longer save this value in panel->backlight.level like before.

Additionally, we drop the call to lpt_get_backlight() in
lpt_setup_backlight(), and avoid unconditionally writing the PWM value that
we get from it and only write it back if we're in CPU mode, and switching
to PCH mode. The reason for this is because in the original codepath for
this, it was expected that the intel_panel_bl_funcs->setup() hook would be
responsible for fetching the initial backlight level. On lpt systems, the
only time we could ever be in PCH backlight mode is during the initial
driver load - meaning that outside of the setup() hook, lpt_get_backlight()
will always be the callback used for retrieving the current backlight
level. After this patch we still need to fetch and write-back the PCH
backlight value if we're switching from CPU mode to PCH, but because
intel_pwm_setup_backlight() will retrieve the backlight level after setup()
using the get() hook, which always ends up being lpt_get_backlight(). Thus
- an additional call to lpt_get_backlight() in lpt_setup_backlight() is
made redundant.

v4:
* Fix commit message
* Remove outdated comment in intel_panel.c
* Rename pwm_(min|max) to pwm_level_(min|max)
* Use intel_pwm_get_backlight() in intel_pwm_setup_backlight() instead of
  indirection
* Don't move intel_dp_aux_init_bcklight_funcs() call to bottom of
  intel_panel_init_backlight_funcs() quite yet
v3:
* Reuse intel_panel_bl_funcs() for pwm_funcs
* Explain why we drop lpt_get_backlight()

Signed-off-by: Lyude Paul 
Cc: thay...@noraisin.net
Cc: Vasily Khoruzhick 
---
 .../drm/i915/display/intel_display_types.h|   4 +
 drivers/gpu/drm/i915/display/intel_panel.c| 333 ++
 2 files changed, 187 insertions(+), 150 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/intel_display_types.h 
b/drivers/gpu/drm/i915/display/intel_display_types.h
index 1067bd073c95..ee5c2d50b81a 100644
--- a/drivers/gpu/drm/i915/display/intel_display_types.h
+++ b/drivers/gpu/drm/i915/display/intel_display_types.h
@@ -252,6 +252,9 @@ struct intel_panel {
bool alternate_pwm_increment;   /* lpt+ */
 
/* PWM chip */
+   u32 pwm_level_min;
+   u32 pwm_level_max;
+   bool pwm_enabled;
bool util_pin_active_low;   /* bxt+ */
u8 controller;  /* bxt+ only */
struct pwm_device *pwm;
@@ -263,6 +266,7 @@ struct intel_panel {
struct backlight_device *device;
 
const struct intel_panel_bl_funcs *funcs;
+   const struct intel_panel_bl_funcs *pwm_funcs;
void (*power)(struct intel_connector *, bool enable);
} backlight;
 };
diff --git a/drivers/gpu/drm/i915/display/intel_panel.c 
b/drivers/gpu/drm/i915/display/intel_panel.c
index 67f81ae995c4..4469ce6760e9 100644
--- a/drivers/gpu/drm/i915/display/intel_panel.c
+++ b/drivers/gpu/drm/i915/display/intel_panel.c
@@ -511,25 +511,34 @@ static u32 scale_hw_to_user(struct intel_connector 
*connector,
 0, user_max);
 }
 
-static u32 intel_panel_compute_brightness(struct intel_connector *connector,
- u32 val)
+static u32 intel_panel_sanitize_pwm_level(struct intel_connector *connector, 
u32 val)
 {
struct d

[Intel-gfx] [PATCH v4 0/4] drm/i915: Add support for Intel's eDP backlight controls

2021-01-05 Thread Lyude Paul

A while ago we ran into issues while trying to enable the eDP backlight
control interface as defined by VESA, in order to make the DPCD
backlight controls on newer laptop panels work. The issue ended up being
much more complicated however, as we also apparently needed to add
support for an Intel-specific DPCD backlight control interface as the
VESA interface is broken on many laptop panels. For lack of a better
name, we just call this the Intel HDR backlight interface.

While this only adds support for the SDR backlight mode (I think), this
will fix a lot of user's laptop panels that we weren't able to properly
automatically detect DPCD backlight controls on previously.

Series-wide changes in v3:
* Pass down brightness values to enable/disable backlight callbacks in a
  separate patch
* Rebase

Lyude Paul (4):
  drm/i915: Keep track of pwm-related backlight hooks separately
  drm/i915/dp: Enable Intel's HDR backlight interface (only SDR for now)
  drm/i915/dp: Allow forcing specific interfaces through
enable_dpcd_backlight
  drm/dp: Revert "drm/dp: Introduce EDID-based quirks"

 drivers/gpu/drm/drm_dp_helper.c   |  83 +---
 drivers/gpu/drm/drm_dp_mst_topology.c |   3 +-
 .../drm/i915/display/intel_display_types.h|  14 +-
 drivers/gpu/drm/i915/display/intel_dp.c   |   9 +-
 .../drm/i915/display/intel_dp_aux_backlight.c | 285 --
 drivers/gpu/drm/i915/display/intel_dp_mst.c   |   3 +-
 drivers/gpu/drm/i915/display/intel_panel.c| 371 ++
 drivers/gpu/drm/i915/display/intel_panel.h|   4 +
 drivers/gpu/drm/i915/display/intel_psr.c  |   2 +-
 drivers/gpu/drm/i915/i915_params.c|   2 +-
 include/drm/drm_dp_helper.h   |  21 +-
 11 files changed, 503 insertions(+), 294 deletions(-)

-- 
2.29.2

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH v3 4/9] drm/i915: Keep track of pwm-related backlight hooks separately

2021-01-05 Thread Lyude Paul

On Wed, 2020-12-23 at 18:37 +0200, Jani Nikula wrote:
> On Fri, 04 Dec 2020, Lyude Paul  wrote:
> > Currently, every different type of backlight hook that i915 supports is
> > pretty straight forward - you have a backlight, probably through PWM
> > (but maybe DPCD), with a single set of platform-specific hooks that are
> > used for controlling it.
> > 
> > HDR backlights, in particular VESA and Intel's HDR backlight
> > implementations, can end up being more complicated. With Intel's
> > proprietary interface, HDR backlight controls always run through the
> > DPCD. When the backlight is in SDR backlight mode however, the driver
> > may need to bypass the TCON and control the backlight directly through
> > PWM.
> > 
> > So, in order to support this we'll need to split our backlight callbacks
> > into two groups: a set of high-level backlight control callbacks in
> > intel_panel, and an additional set of pwm-specific backlight control
> > callbacks. This also implies a functional changes for how these
> > callbacks are used:
> > 
> > * We now keep track of two separate backlight level ranges, one for the
> >   high-level backlight, and one for the pwm backlight range
> > * We also keep track of backlight enablement and PWM backlight
> >   enablement separately
> > * Since the currently set backlight level might not be the same as the
> >   currently programmed PWM backlight level, we stop setting
> >   panel->backlight.level with the currently programmed PWM backlight
> >   level in panel->backlight.pwm_funcs->setup(). Instead, we rely
> >   on the higher level backlight control functions to retrieve the
> >   current PWM backlight level (in this case, intel_pwm_get_backlight()).
> >   Note that there are still a few PWM backlight setup callbacks that
> >   do actually need to retrieve the current PWM backlight level, although
> >   we no longer save this value in panel->backlight.level like before.
> > 
> > Additionally, we drop the call to lpt_get_backlight() in
> > lpt_setup_backlight(), and avoid unconditionally writing the PWM value
> > that
> > we get from it and only write it back if we're in PCH mode. The reason for
> 
> Should be something like, "...only write it back if we're in CPU mode,
> and switching to PCH mode."
> 
> > this is because in the original codepath for this, it was expected that
> > the
> > intel_panel_bl_funcs->setup() hook would be responsible for fetching the
> > initial backlight level. On lpt systems, the only time we could ever be in
> > PCH backlight mode is during the initial driver load - meaning that
> > outside
> > of the setup() hook, lpt_get_backlight() will always be the callback used
> > for retrieving the current backlight level. After this patch we still need
> > to fetch and write-back the PCH backlight value if we're in PCH mode, but
> 
> Ditto here. We may probe at CPU mode, set up by BIOS/GOP, but we always
> switch to PCH override mode. (The pch_ prefixed function naming is
> misleading...)
> 
> Historically there was a CPU register for pwm control. Then the
> functionality was moved to PCH but the register remained. Then there was
> a transition to PCH register, but the CPU register remained and used
> some low level internal messaging from CPU to PCH, unless PCH override
> was set. Finally the messaging was removed. Anyway, on the CPU+PCH
> combos where we can choose, we prefer using the PCH register directly
> ("PCH mode") and not use the CPU register with messaging. Simple made
> complex(tm).
> 
> > because intel_pwm_setup_backlight() will retrieve the backlight level
> > after
> > setup() using the get() hook, which always ends up being
> > lpt_get_backlight(). Thus - an additional call to lpt_get_backlight() in
> > lpt_setup_backlight() is made redundant.
> > 
> > v3:
> > * Reuse intel_panel_bl_funcs() for pwm_funcs
> > * Explain why we drop lpt_get_backlight()
> > 
> > Signed-off-by: Lyude Paul 
> > Cc: thay...@noraisin.net
> > Cc: Vasily Khoruzhick 
> > ---
> >  .../drm/i915/display/intel_display_types.h    |   4 +
> >  drivers/gpu/drm/i915/display/intel_panel.c    | 344 ++
> >  2 files changed, 194 insertions(+), 154 deletions(-)
> > 
> > diff --git a/drivers/gpu/drm/i915/display/intel_display_types.h
> > b/drivers/gpu/drm/i915/display/intel_display_types.h
> > index a70d1bf29aa5..47ee565c49a2 100644
> > --- a/drivers/gpu/drm/i915/display/intel_display_types.h
> > +++ b/drivers/gpu/drm/i915/display/intel_display_types.h
> > @@ -25

Re: [Intel-gfx] [PATCH v3 0/9] drm/i915: Add support for Intel's eDP backlight controls

2020-12-17 Thread Lyude Paul

Poke, can we please get some reviews on this? It's been over a week.

On Fri, 2020-12-04 at 17:35 -0500, Lyude Paul wrote:
> A while ago we ran into issues while trying to enable the eDP backlight
> control interface as defined by VESA, in order to make the DPCD
> backlight controls on newer laptop panels work. The issue ended up being
> much more complicated however, as we also apparently needed to add
> support for an Intel-specific DPCD backlight control interface as the
> VESA interface is broken on many laptop panels. For lack of a better
> name, we just call this the Intel HDR backlight interface.
> 
> While this only adds support for the SDR backlight mode (I think), this
> will fix a lot of user's laptop panels that we weren't able to properly
> automatically detect DPCD backlight controls on previously.
> 
> Series-wide changes in v3:
> * Pass down brightness values to enable/disable backlight callbacks in a
>   separate patch
> * Rebase
> 
> Lyude Paul (9):
>   drm/i915/dp: Program source OUI on eDP panels
>   drm/i915: Rename pwm_* backlight callbacks to ext_pwm_*
>   drm/i915: Pass down brightness values to enable/disable backlight
>     callbacks
>   drm/i915: Keep track of pwm-related backlight hooks separately
>   drm/i915/dp: Rename eDP VESA backlight interface functions
>   drm/i915/dp: Add register definitions for Intel HDR backlight
>     interface
>   drm/i915/dp: Enable Intel's HDR backlight interface (only SDR for now)
>   drm/i915/dp: Allow forcing specific interfaces through
>     enable_dpcd_backlight
>   drm/dp: Revert "drm/dp: Introduce EDID-based quirks"
> 
>  drivers/gpu/drm/drm_dp_helper.c   |  83 +---
>  drivers/gpu/drm/drm_dp_mst_topology.c |   3 +-
>  .../drm/i915/display/intel_display_types.h    |  18 +-
>  drivers/gpu/drm/i915/display/intel_dp.c   |  42 +-
>  .../drm/i915/display/intel_dp_aux_backlight.c | 394 +---
>  drivers/gpu/drm/i915/display/intel_dp_mst.c   |   3 +-
>  .../i915/display/intel_dsi_dcs_backlight.c    |   7 +-
>  drivers/gpu/drm/i915/display/intel_panel.c    | 435 ++
>  drivers/gpu/drm/i915/display/intel_panel.h    |   4 +
>  drivers/gpu/drm/i915/display/intel_psr.c  |   2 +-
>  drivers/gpu/drm/i915/i915_params.c    |   2 +-
>  include/drm/drm_dp_helper.h   |  21 +-
>  12 files changed, 655 insertions(+), 359 deletions(-)
> 

-- 
Sincerely,
   Lyude Paul (she/her)
   Software Engineer at Red Hat
   
Note: I deal with a lot of emails and have a lot of bugs on my plate. If you've
asked me a question, are waiting for a review/merge on a patch, etc. and I
haven't responded in a while, please feel free to send me another email to check
on my status. I don't bite!

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [RFC 5/5] drm/nouveau/kms/nv50-: Add basic DPCD backlight support for nouveau

2020-12-09 Thread Lyude Paul

This adds support for controlling panel backlights over eDP using VESA's
standard backlight control interface. Luckily, Nvidia was cool enough to
never come up with their own proprietary backlight control interface (at
least, not any that I or the laptop manufacturers I've talked to are aware
of), so this should work for any laptop panels which support the VESA
backlight control interface.

Note that we don't yet provide the panel backlight frequency to the DRM DP
backlight helpers. This should be fine for the time being, since it's not
required to get basic backlight controls working.

For reference: there's some mentions of PWM backlight values in
nouveau_reg.h, but I'm not sure these are the values we would want to use.
If we figure out how to get this information in the future, we'll have the
benefit of more granular backlight control.

Signed-off-by: Lyude Paul 
Cc: Jani Nikula 
Cc: Dave Airlie 
Cc: greg.depo...@gmail.com
---
 drivers/gpu/drm/nouveau/dispnv50/disp.c |  30 +++-
 drivers/gpu/drm/nouveau/nouveau_backlight.c | 166 ++--
 drivers/gpu/drm/nouveau/nouveau_connector.h |   9 +-
 drivers/gpu/drm/nouveau/nouveau_encoder.h   |   1 +
 4 files changed, 187 insertions(+), 19 deletions(-)

diff --git a/drivers/gpu/drm/nouveau/dispnv50/disp.c 
b/drivers/gpu/drm/nouveau/dispnv50/disp.c
index 33fff388dd83..fbc1665afc68 100644
--- a/drivers/gpu/drm/nouveau/dispnv50/disp.c
+++ b/drivers/gpu/drm/nouveau/dispnv50/disp.c
@@ -31,6 +31,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include 
 #include 
@@ -1615,23 +1616,38 @@ nv50_sor_update(struct nouveau_encoder *nv_encoder, u8 
head,
core->func->sor->ctrl(core, nv_encoder->or, nv_encoder->ctrl, asyh);
 }
 
+/* TODO: Should we extend this to PWM-only backlights?
+ * As well, should we add a DRM helper for waiting for the backlight to 
acknowledge
+ * the panel backlight has been shut off? Intel doesn't seem to do this, and 
uses a
+ * fixed time delay from the vbios…
+ */
 static void
 nv50_sor_disable(struct drm_encoder *encoder,
 struct drm_atomic_state *state)
 {
struct nouveau_encoder *nv_encoder = nouveau_encoder(encoder);
+   struct nouveau_drm *drm = nouveau_drm(nv_encoder->base.base.dev);
struct nouveau_crtc *nv_crtc = nouveau_crtc(nv_encoder->crtc);
struct nouveau_connector *nv_connector =
nv50_outp_get_old_connector(nv_encoder, state);
+   int ret;
 
nv_encoder->crtc = NULL;
 
if (nv_crtc) {
struct drm_dp_aux *aux = _connector->aux;
+   struct nouveau_backlight *backlight = nv_connector->backlight;
u8 pwr;
 
+   if (backlight && backlight->uses_dpcd) {
+   ret = drm_edp_backlight_disable(aux, 
>edp_info);
+   if (ret < 0)
+   NV_ERROR(drm, "Failed to disable backlight on 
[CONNECTOR:%d:%s]: %d\n",
+nv_connector->base.base.id, 
nv_connector->base.name, ret);
+   }
+
if (nv_encoder->dcb->type == DCB_OUTPUT_DP) {
-   int ret = drm_dp_dpcd_readb(aux, DP_SET_POWER, );
+   ret = drm_dp_dpcd_readb(aux, DP_SET_POWER, );
 
if (ret == 0) {
pwr &= ~DP_SET_POWER_MASK;
@@ -1667,6 +1683,9 @@ nv50_sor_enable(struct drm_encoder *encoder, struct 
drm_atomic_state *state)
struct drm_device *dev = encoder->dev;
struct nouveau_drm *drm = nouveau_drm(dev);
struct nouveau_connector *nv_connector;
+#ifdef CONFIG_DRM_NOUVEAU_BACKLIGHT
+   struct nouveau_backlight *backlight;
+#endif
struct nvbios *bios = >vbios;
bool hda = false;
u8 proto = NV507D_SOR_SET_CONTROL_PROTOCOL_CUSTOM;
@@ -1741,6 +1760,14 @@ nv50_sor_enable(struct drm_encoder *encoder, struct 
drm_atomic_state *state)
proto = NV887D_SOR_SET_CONTROL_PROTOCOL_DP_B;
 
nv50_audio_enable(encoder, state, mode);
+
+#ifdef CONFIG_DRM_NOUVEAU_BACKLIGHT
+   backlight = nv_connector->backlight;
+   if (backlight && backlight->uses_dpcd)
+   drm_edp_backlight_enable(_connector->aux, 
>edp_info,
+
(u16)backlight->dev->props.brightness);
+#endif
+
break;
default:
BUG();
@@ -2263,6 +2290,7 @@ nv50_disp_atomic_commit_tail(struct drm_atomic_state 
*state)
nv50_crc_atomic_start_reporting(state);
if (!flushed)
nv50_crc_atomic_release_notifier_contexts(state);
+
drm_atomic_helper_commit_hw_done(state);
drm_atomic_helper_cleanup_planes(dev, state);
drm_atomic_helper_commit_cleanup_done(state);
diff --git a/drivers/gpu/drm/nouveau/nouveau_backlight.c 
b/drivers/

[Intel-gfx] [RFC 4/5] drm/dp: Extract i915's eDP backlight code into DRM helpers

2020-12-09 Thread Lyude Paul

Since we're about to implement eDP backlight support in nouveau using the
standard protocol from VESA, we might as well just take the code that's
already written for this and move it into a set of shared DRM helpers.

Note that these helpers are intended to handle DPCD related backlight
control bits such as setting the brightness level over AUX, probing the
backlight's TCON, enabling/disabling the backlight over AUX if supported,
etc. Any PWM-related portions of backlight control are explicitly left up
to the driver, as these will vary from platform to platform.

The only exception to this is the calculation of the PWM frequency
pre-divider value. This is because the only platform-specific information
required for this is the PWM frequency of the panel, which the driver is
expected to provide if available. The actual algorithm for calculating this
value is standard and is defined in the eDP specification from VESA.

Note that these helpers do not yet implement the full range of features
the VESA backlight interface provides, and only provide the following
functionality (all of which was already present in i915's DPCD backlight
support):

* Basic control of brightness levels
* Basic probing of backlight capabilities
* Helpers for enabling and disabling the backlight

Signed-off-by: Lyude Paul 
Cc: Jani Nikula 
Cc: Dave Airlie 
Cc: greg.depo...@gmail.com
---
 drivers/gpu/drm/drm_dp_helper.c   | 332 ++
 .../drm/i915/display/intel_display_types.h|   5 +-
 .../drm/i915/display/intel_dp_aux_backlight.c | 304 ++--
 include/drm/drm_dp_helper.h   |  48 +++
 4 files changed, 419 insertions(+), 270 deletions(-)

diff --git a/drivers/gpu/drm/drm_dp_helper.c b/drivers/gpu/drm/drm_dp_helper.c
index 5bd0934004e3..06fdddf44e54 100644
--- a/drivers/gpu/drm/drm_dp_helper.c
+++ b/drivers/gpu/drm/drm_dp_helper.c
@@ -2596,3 +2596,335 @@ void drm_dp_vsc_sdp_log(const char *level, struct 
device *dev,
 #undef DP_SDP_LOG
 }
 EXPORT_SYMBOL(drm_dp_vsc_sdp_log);
+
+/**
+ * drm_edp_backlight_set_level() - Set the backlight level of an eDP panel via 
AUX
+ * @aux: The DP AUX channel to use
+ * @bl: Backlight capability info from drm_edp_backlight_init()
+ * @level: The brightness level to set
+ *
+ * Sets the brightness level of an eDP panel's backlight. Note that the 
panel's backlight must
+ * already have been enabled by the driver by calling 
drm_edp_backlight_enable().
+ *
+ * Returns: %0 on success, negative error code on failure
+ */
+int drm_edp_backlight_set_level(struct drm_dp_aux *aux, const struct 
drm_edp_backlight_info *bl,
+   u16 level)
+{
+   int ret;
+   u8 buf[2] = { 0 };
+
+   if (bl->lsb_reg_used) {
+   buf[0] = (level & 0xFF00) >> 8;
+   buf[1] = (level & 0x00FF);
+   } else {
+   buf[0] = level;
+   }
+
+   ret = drm_dp_dpcd_write(aux, DP_EDP_BACKLIGHT_BRIGHTNESS_MSB, buf, 
sizeof(buf));
+   if (ret != sizeof(buf)) {
+   DRM_ERROR("%s: Failed to write aux backlight level: %d\n", 
aux->name, ret);
+   return ret < 0 ? ret : -EIO;
+   }
+
+   return 0;
+}
+EXPORT_SYMBOL(drm_edp_backlight_set_level);
+
+static int
+drm_edp_backlight_set_enable(struct drm_dp_aux *aux, const struct 
drm_edp_backlight_info *bl,
+bool enable)
+{
+   int ret;
+   u8 buf;
+
+   /* The panel uses something other then DPCD for enabling it's backlight 
*/
+   if (!bl->aux_enable)
+   return 0;
+
+   ret = drm_dp_dpcd_readb(aux, DP_EDP_DISPLAY_CONTROL_REGISTER, );
+   if (ret != 1) {
+   DRM_ERROR("%s: Failed to read eDP display control register: 
%d\n", aux->name, ret);
+   return ret < 0 ? ret : -EIO;
+   }
+   if (enable)
+   buf |= DP_EDP_BACKLIGHT_ENABLE;
+   else
+   buf &= ~DP_EDP_BACKLIGHT_ENABLE;
+
+   ret = drm_dp_dpcd_writeb(aux, DP_EDP_DISPLAY_CONTROL_REGISTER, buf);
+   if (ret != 1) {
+   DRM_ERROR("%s: Failed to write eDP display control register: 
%d\n", aux->name, ret);
+   return ret < 0 ? ret : -EIO;
+   }
+
+   return 0;
+}
+
+/**
+ * drm_edp_backlight_enable() - Enable an eDP panel's backlight using DPCD
+ * @aux: The DP AUX channel to use
+ * @bl: Backlight capability info from drm_edp_backlight_init()
+ * @level: The initial backlight level to set via AUX, if there is one
+ *
+ * This function handles enabling DPCD backlight controls on a panel over 
DPCD, while additionally
+ * restoring any important backlight state such as the given backlight level, 
the brightness byte
+ * count, backlight frequency, etc.
+ *
+ * Note that certain panels, while supporting brightness level controls over 
DPCD, may not support
+ * having their backlights enabled via the standard 
%DP_EDP_DISPLAY_CONTROL_REGISTER.

[Intel-gfx] [RFC 3/5] drm/i915/dp: Remove redundant AUX backlight frequency calculations

2020-12-09 Thread Lyude Paul

Noticed this while moving all of the VESA backlight code in i915 over to
DRM helpers: it would appear that we calculate the frequency value we want
to write to DP_EDP_BACKLIGHT_FREQ_SET twice even though this value never
actually changes during runtime. So, let's simplify things by just caching
this value in intel_panel.backlight, and re-writing it as-needed.

Signed-off-by: Lyude Paul 
Cc: Jani Nikula 
Cc: Dave Airlie 
Cc: greg.depo...@gmail.com
---
 .../drm/i915/display/intel_display_types.h|  1 +
 .../drm/i915/display/intel_dp_aux_backlight.c | 64 ++-
 2 files changed, 19 insertions(+), 46 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/intel_display_types.h 
b/drivers/gpu/drm/i915/display/intel_display_types.h
index 5bc5bfbc4551..133c9cb742a7 100644
--- a/drivers/gpu/drm/i915/display/intel_display_types.h
+++ b/drivers/gpu/drm/i915/display/intel_display_types.h
@@ -259,6 +259,7 @@ struct intel_panel {
 
/* DPCD backlight */
u8 pwmgen_bit_count;
+   u8 pwm_freq_pre_divider;
 
struct backlight_device *device;
 
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 4fd536801b14..94ce5ca1affa 100644
--- a/drivers/gpu/drm/i915/display/intel_dp_aux_backlight.c
+++ b/drivers/gpu/drm/i915/display/intel_dp_aux_backlight.c
@@ -129,50 +129,6 @@ intel_dp_aux_set_backlight(const struct 
drm_connector_state *conn_state, u32 lev
}
 }
 
-/*
- * Set PWM Frequency divider to match desired frequency in vbt.
- * The PWM Frequency is calculated as 27Mhz / (F x P).
- * - Where F = PWM Frequency Pre-Divider value programmed by field 7:0 of the
- * EDP_BACKLIGHT_FREQ_SET register (DPCD Address 00728h)
- * - Where P = 2^Pn, where Pn is the value programmed by field 4:0 of the
- * EDP_PWMGEN_BIT_COUNT register (DPCD Address 00724h)
- */
-static bool intel_dp_aux_set_pwm_freq(struct intel_connector *connector)
-{
-   struct drm_i915_private *dev_priv = to_i915(connector->base.dev);
-   struct intel_dp *intel_dp = intel_attached_dp(connector);
-   const u8 pn = connector->panel.backlight.pwmgen_bit_count;
-   int freq, fxp, f, fxp_actual, fxp_min, fxp_max;
-
-   freq = dev_priv->vbt.backlight.pwm_freq_hz;
-   if (!freq) {
-   drm_dbg_kms(_priv->drm,
-   "Use panel default backlight frequency\n");
-   return false;
-   }
-
-   fxp = DIV_ROUND_CLOSEST(KHz(DP_EDP_BACKLIGHT_FREQ_BASE_KHZ), freq);
-   f = clamp(DIV_ROUND_CLOSEST(fxp, 1 << pn), 1, 255);
-   fxp_actual = f << pn;
-
-   /* Ensure frequency is within 25% of desired value */
-   fxp_min = DIV_ROUND_CLOSEST(fxp * 3, 4);
-   fxp_max = DIV_ROUND_CLOSEST(fxp * 5, 4);
-
-   if (fxp_min > fxp_actual || fxp_actual > fxp_max) {
-   drm_dbg_kms(_priv->drm, "Actual frequency out of range\n");
-   return false;
-   }
-
-   if (drm_dp_dpcd_writeb(_dp->aux,
-  DP_EDP_BACKLIGHT_FREQ_SET, (u8) f) < 0) {
-   drm_dbg_kms(_priv->drm,
-   "Failed to write aux backlight freq\n");
-   return false;
-   }
-   return true;
-}
-
 static void intel_dp_aux_enable_backlight(const struct intel_crtc_state 
*crtc_state,
  const struct drm_connector_state 
*conn_state)
 {
@@ -213,9 +169,13 @@ static void intel_dp_aux_enable_backlight(const struct 
intel_crtc_state *crtc_st
break;
}
 
-   if (intel_dp->edp_dpcd[2] & DP_EDP_BACKLIGHT_FREQ_AUX_SET_CAP)
-   if (intel_dp_aux_set_pwm_freq(connector))
+   if (panel->backlight.pwm_freq_pre_divider) {
+   if (drm_dp_dpcd_writeb(_dp->aux, 
DP_EDP_BACKLIGHT_FREQ_SET,
+  panel->backlight.pwm_freq_pre_divider) 
== 1)
new_dpcd_buf |= DP_EDP_BACKLIGHT_FREQ_AUX_SET_ENABLE;
+   else
+   drm_dbg_kms(>drm, "Failed to write aux backlight 
frequency\n");
+   }
 
if (new_dpcd_buf != dpcd_buf) {
if (drm_dp_dpcd_writeb(_dp->aux,
@@ -236,6 +196,14 @@ static void intel_dp_aux_disable_backlight(const struct 
drm_connector_state *old
 false);
 }
 
+/*
+ * Compute PWM frequency divider value based off the frequency provided to us 
by the vbt.
+ * The PWM Frequency is calculated as 27Mhz / (F x P).
+ * - Where F = PWM Frequency Pre-Divider value programmed by field 7:0 of the
+ * EDP_BACKLIGHT_FREQ_SET register (DPCD Address 00728h)
+ * - Where P = 2^Pn, where Pn is the value programmed by field 4:0 of the
+ * EDP_PWMGEN_BIT_COUNT register (DPCD Address 00724h)
+ */
 static u32 intel_dp_aux_calc_max_b

[Intel-gfx] [RFC 2/5] drm/nouveau/kms: Don't probe eDP connectors more then once

2020-12-09 Thread Lyude Paul

eDP doesn't do hotplugging, so there's no reason for us to reprobe it (unless a
connection status change is being forced, of course).

Signed-off-by: Lyude Paul 
Cc: Jani Nikula 
Cc: Dave Airlie 
Cc: greg.depo...@gmail.com
---
 drivers/gpu/drm/nouveau/nouveau_connector.c | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/drivers/gpu/drm/nouveau/nouveau_connector.c 
b/drivers/gpu/drm/nouveau/nouveau_connector.c
index 8b4b3688c7ae..398fee9b7ae9 100644
--- a/drivers/gpu/drm/nouveau/nouveau_connector.c
+++ b/drivers/gpu/drm/nouveau/nouveau_connector.c
@@ -554,6 +554,12 @@ nouveau_connector_detect(struct drm_connector *connector, 
bool force)
int ret;
enum drm_connector_status conn_status = connector_status_disconnected;
 
+   /* eDP doesn't do hotplugging, never probe more then once */
+   if (nv_connector->type == DCB_CONNECTOR_eDP &&
+   connector->force == DRM_FORCE_UNSPECIFIED &&
+   connector->status != connector_status_unknown)
+   return connector->status;
+
/* Outputs are only polled while runtime active, so resuming the
 * device here is unnecessary (and would deadlock upon runtime suspend
 * because it waits for polling to finish). We do however, want to
-- 
2.28.0

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [RFC 1/5] drm/nouveau/kms/nv40-/backlight: Assign prop type once

2020-12-09 Thread Lyude Paul

Signed-off-by: Lyude Paul 
Cc: Jani Nikula 
Cc: Dave Airlie 
Cc: greg.depo...@gmail.com
---
 drivers/gpu/drm/nouveau/nouveau_backlight.c | 4 +---
 1 file changed, 1 insertion(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/nouveau/nouveau_backlight.c 
b/drivers/gpu/drm/nouveau/nouveau_backlight.c
index c7a94c94dbf3..4acc5be5e9aa 100644
--- a/drivers/gpu/drm/nouveau/nouveau_backlight.c
+++ b/drivers/gpu/drm/nouveau/nouveau_backlight.c
@@ -106,7 +106,6 @@ nv40_backlight_init(struct nouveau_encoder *encoder,
if (!(nvif_rd32(device, NV40_PMC_BACKLIGHT) & NV40_PMC_BACKLIGHT_MASK))
return -ENODEV;
 
-   props->type = BACKLIGHT_RAW;
props->max_brightness = 31;
*ops = _bl_ops;
return 0;
@@ -212,7 +211,6 @@ nv50_backlight_init(struct nouveau_encoder *nv_encoder,
else
*ops = _bl_ops;
 
-   props->type = BACKLIGHT_RAW;
props->max_brightness = 100;
 
return 0;
@@ -226,7 +224,7 @@ nouveau_backlight_init(struct drm_connector *connector)
struct nouveau_encoder *nv_encoder = NULL;
struct nvif_device *device = >client.device;
char backlight_name[BL_NAME_SIZE];
-   struct backlight_properties props = {0};
+   struct backlight_properties props = { .type = BACKLIGHT_RAW, 0 };
const struct backlight_ops *ops;
int ret;
 
-- 
2.28.0

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [RFC 0/5] drm: Extract DPCD backlight helpers from i915, add support in nouveau

2020-12-09 Thread Lyude Paul

This series:
* Cleans up i915's DPCD backlight code a little bit
* Extracts i915's DPCD backlight code into a set of shared DRM helpers
* Starts using those helpers in nouveau to add support to nouveau for
  DPCD backlight control

Cc: Jani Nikula 
Cc: Dave Airlie 
Cc: greg.depo...@gmail.com

Lyude Paul (5):
  drm/nouveau/kms/nv40-/backlight: Assign prop type once
  drm/nouveau/kms: Don't probe eDP connectors more then once
  drm/i915/dp: Remove redundant AUX backlight frequency calculations
  drm/dp: Extract i915's eDP backlight code into DRM helpers
  drm/nouveau/kms/nv50-: Add basic DPCD backlight support for nouveau

 drivers/gpu/drm/drm_dp_helper.c   | 332 ++
 .../drm/i915/display/intel_display_types.h|   4 +-
 .../drm/i915/display/intel_dp_aux_backlight.c | 332 ++
 drivers/gpu/drm/nouveau/dispnv50/disp.c   |  30 +-
 drivers/gpu/drm/nouveau/nouveau_backlight.c   | 170 +++--
 drivers/gpu/drm/nouveau/nouveau_connector.c   |   6 +
 drivers/gpu/drm/nouveau/nouveau_connector.h   |   9 +-
 drivers/gpu/drm/nouveau/nouveau_encoder.h |   1 +
 include/drm/drm_dp_helper.h   |  48 +++
 9 files changed, 613 insertions(+), 319 deletions(-)

-- 
2.28.0

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH v3 9/9] drm/dp: Revert "drm/dp: Introduce EDID-based quirks"

2020-12-04 Thread Lyude Paul

This reverts commit 0883ce8146ed6074c76399f4e70dbed788582e12. Originally
these quirks were added because of the issues with using the eDP
backlight interfaces on certain laptop panels, which made it impossible
to properly probe for DPCD backlight support without having a whitelist
for panels that we know have working VESA backlight control interfaces
over DPCD. As well, it should be noted it was impossible to use the
normal sink OUI for recognizing these panels as none of them actually
filled out their OUIs, hence needing to resort to checking EDIDs.

At the time we weren't really sure why certain panels had issues with
DPCD backlight controls, but we eventually figured out that there was a
second interface that these problematic laptop panels actually did work
with and advertise properly: Intel's proprietary backlight interface for
HDR panels. So far the testing we've done hasn't brought any panels to
light that advertise this interface and don't support it properly, which
means we finally have a real solution to this problem.

As a result, we now have no need for the force DPCD backlight quirk, and
furthermore this also removes the need for any kind of EDID quirk
checking in DRM. So, let's just revert it for now since we were the only
driver using this.

v3:
* Rebase
v2:
* Fix indenting error picked up by checkpatch in
  intel_edp_init_connector()

Signed-off-by: Lyude Paul 
Acked-by: Jani Nikula 
Cc: thay...@noraisin.net
Cc: Vasily Khoruzhick 
---
 drivers/gpu/drm/drm_dp_helper.c   | 83 +--
 drivers/gpu/drm/drm_dp_mst_topology.c |  3 +-
 .../drm/i915/display/intel_display_types.h|  1 -
 drivers/gpu/drm/i915/display/intel_dp.c   |  9 +-
 drivers/gpu/drm/i915/display/intel_dp_mst.c   |  3 +-
 drivers/gpu/drm/i915/display/intel_psr.c  |  2 +-
 include/drm/drm_dp_helper.h   | 21 +
 7 files changed, 9 insertions(+), 113 deletions(-)

diff --git a/drivers/gpu/drm/drm_dp_helper.c b/drivers/gpu/drm/drm_dp_helper.c
index 5bd0934004e3..62f696fe511e 100644
--- a/drivers/gpu/drm/drm_dp_helper.c
+++ b/drivers/gpu/drm/drm_dp_helper.c
@@ -1204,7 +1204,7 @@ bool drm_dp_read_sink_count_cap(struct drm_connector 
*connector,
return connector->connector_type != DRM_MODE_CONNECTOR_eDP &&
dpcd[DP_DPCD_REV] >= DP_DPCD_REV_11 &&
dpcd[DP_DOWNSTREAMPORT_PRESENT] & DP_DWN_STRM_PORT_PRESENT &&
-   !drm_dp_has_quirk(desc, 0, DP_DPCD_QUIRK_NO_SINK_COUNT);
+   !drm_dp_has_quirk(desc, DP_DPCD_QUIRK_NO_SINK_COUNT);
 }
 EXPORT_SYMBOL(drm_dp_read_sink_count_cap);
 
@@ -1925,87 +1925,6 @@ drm_dp_get_quirks(const struct drm_dp_dpcd_ident *ident, 
bool is_branch)
 #undef DEVICE_ID_ANY
 #undef DEVICE_ID
 
-struct edid_quirk {
-   u8 mfg_id[2];
-   u8 prod_id[2];
-   u32 quirks;
-};
-
-#define MFG(first, second) { (first), (second) }
-#define PROD_ID(first, second) { (first), (second) }
-
-/*
- * 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) },
-   { MFG(0x09, 0xe5), PROD_ID(0xde, 0x08), 
BIT(DP_QUIRK_FORCE_DPCD_BACKLIGHT) },
-};
-
-#undef MFG
-#undef PROD_ID
-
-/**
- * drm_dp_get_edid_quirks() - Check the EDID of a DP device to find additional
- * DP-specific quirks
- * @edid: The EDID to check
- *
- * While OUIDs are meant to be used to recognize a DisplayPort device, a lot
- * of manufacturers don't seem to like following standards and neglect to fill
- * the dev-ID in, making it impossible to only use OUIDs for determining
- * quirk

[Intel-gfx] [PATCH v3 8/9] drm/i915/dp: Allow forcing specific interfaces through enable_dpcd_backlight

2020-12-04 Thread Lyude Paul

Since we now support controlling panel backlights through DPCD using
both the standard VESA interface, and Intel's proprietary HDR backlight
interface, we should allow the user to be able to explicitly choose
between one or the other in the event that we're wrong about panels
reliably reporting support for the Intel HDR interface.

So, this commit adds support for this by introducing two new
enable_dpcd_backlight options: 2 which forces i915 to only probe for the
VESA interface, and 3 which forces i915 to only probe for the Intel
backlight interface (might be useful if we find panels in the wild that
report the VESA interface in their VBT, but actually only support the
Intel backlight interface).

v3:
* Rebase

Signed-off-by: Lyude Paul 
Cc: thay...@noraisin.net
Cc: Vasily Khoruzhick 
---
 .../drm/i915/display/intel_dp_aux_backlight.c | 45 +--
 drivers/gpu/drm/i915/i915_params.c|  2 +-
 2 files changed, 43 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/intel_dp_aux_backlight.c 
b/drivers/gpu/drm/i915/display/intel_dp_aux_backlight.c
index 9a3ff3ffc158..eef14ab6bddc 100644
--- a/drivers/gpu/drm/i915/display/intel_dp_aux_backlight.c
+++ b/drivers/gpu/drm/i915/display/intel_dp_aux_backlight.c
@@ -609,15 +609,54 @@ static const struct intel_panel_bl_funcs 
intel_dp_vesa_bl_funcs = {
.get = intel_dp_aux_vesa_get_backlight,
 };
 
+enum intel_dp_aux_backlight_modparam {
+   INTEL_DP_AUX_BACKLIGHT_AUTO = -1,
+   INTEL_DP_AUX_BACKLIGHT_OFF = 0,
+   INTEL_DP_AUX_BACKLIGHT_ON = 1,
+   INTEL_DP_AUX_BACKLIGHT_FORCE_VESA = 2,
+   INTEL_DP_AUX_BACKLIGHT_FORCE_INTEL = 3,
+};
+
 int intel_dp_aux_init_backlight_funcs(struct intel_connector *connector)
 {
struct drm_device *dev = connector->base.dev;
struct intel_panel *panel = >panel;
struct intel_dp *intel_dp = enc_to_intel_dp(connector->encoder);
struct drm_i915_private *i915 = dp_to_i915(intel_dp);
+   bool try_intel_interface = false, try_vesa_interface = false;
 
-   if (i915->params.enable_dpcd_backlight == 0)
+   /* Check the VBT and user's module parameters to figure out which
+* interfaces to probe
+*/
+   switch (i915->params.enable_dpcd_backlight) {
+   case INTEL_DP_AUX_BACKLIGHT_OFF:
return -ENODEV;
+   case INTEL_DP_AUX_BACKLIGHT_AUTO:
+   switch (i915->vbt.backlight.type) {
+   case INTEL_BACKLIGHT_VESA_EDP_AUX_INTERFACE:
+   try_vesa_interface = true;
+   break;
+   case INTEL_BACKLIGHT_DISPLAY_DDI:
+   try_intel_interface = true;
+   try_vesa_interface = true;
+   break;
+   default:
+   return -ENODEV;
+   }
+   break;
+   case INTEL_DP_AUX_BACKLIGHT_ON:
+   if (i915->vbt.backlight.type != 
INTEL_BACKLIGHT_VESA_EDP_AUX_INTERFACE)
+   try_intel_interface = true;
+
+   try_vesa_interface = true;
+   break;
+   case INTEL_DP_AUX_BACKLIGHT_FORCE_VESA:
+   try_vesa_interface = true;
+   break;
+   case INTEL_DP_AUX_BACKLIGHT_FORCE_INTEL:
+   try_intel_interface = true;
+   break;
+   }
 
/*
 * A lot of eDP panels in the wild will report supporting both the
@@ -626,13 +665,13 @@ int intel_dp_aux_init_backlight_funcs(struct 
intel_connector *connector)
 * and will only work with the Intel interface. So, always probe for
 * that first.
 */
-   if (intel_dp_aux_supports_hdr_backlight(connector)) {
+   if (try_intel_interface && 
intel_dp_aux_supports_hdr_backlight(connector)) {
drm_dbg(dev, "Using Intel proprietary eDP backlight 
controls\n");
panel->backlight.funcs = _dp_hdr_bl_funcs;
return 0;
}
 
-   if (intel_dp_aux_supports_vesa_backlight(connector)) {
+   if (try_vesa_interface && 
intel_dp_aux_supports_vesa_backlight(connector)) {
drm_dbg(dev, "Using VESA eDP backlight controls\n");
panel->backlight.funcs = _dp_vesa_bl_funcs;
return 0;
diff --git a/drivers/gpu/drm/i915/i915_params.c 
b/drivers/gpu/drm/i915/i915_params.c
index 7f139ea4a90b..6939634e56ed 100644
--- a/drivers/gpu/drm/i915/i915_params.c
+++ b/drivers/gpu/drm/i915/i915_params.c
@@ -185,7 +185,7 @@ i915_param_named_unsafe(inject_probe_failure, uint, 0400,
 
 i915_param_named(enable_dpcd_backlight, int, 0400,
"Enable support for DPCD backlight control"
-   "(-1=use per-VBT LFP backlight type setting [default], 0=disabled, 
1=enabled)");
+   "(-1=use per-VBT LFP backlight type setting [default], 0=disabled, 
1=enable, 2=force VESA interface, 3=force Intel inter

[Intel-gfx] [PATCH v3 7/9] drm/i915/dp: Enable Intel's HDR backlight interface (only SDR for now)

2020-12-04 Thread Lyude Paul

So-recently a bunch of laptops on the market have started using DPCD
backlight controls instead of the traditional DDI backlight controls.
Originally we thought we had this handled by adding VESA backlight
control support to i915, but the story ended up being a lot more
complicated then that.

Simply put-there's two main backlight interfaces Intel can see in the
wild. Intel's proprietary HDR backlight interface, and the standard VESA
backlight interface. Note that many panels have been observed to report
support for both backlight interfaces, but testing has shown far more
panels work with the Intel HDR backlight interface at the moment.
Additionally, the VBT appears to be capable of reporting support for the
VESA backlight interface but not the Intel HDR interface which needs to
be probed by setting the right magic OUI.

On top of that however, there's also actually two different variants of
the Intel HDR backlight interface. The first uses the AUX channel for
controlling the brightness of the screen in both SDR and HDR mode, and
the second only uses the AUX channel for setting the brightness level in
HDR mode - relying on PWM for setting the brightness level in SDR mode.

For the time being we've been using EDIDs to maintain a list of quirks
for panels that safely do support the VESA backlight interface. Adding
support for Intel's HDR backlight interface in addition however, should
finally allow us to auto-detect eDP backlight controls properly so long
as we probe like so:

* If the panel's VBT reports VESA backlight support, assume it really
  does support it
* If the panel's VBT reports DDI backlight controls:
  * First probe for Intel's HDR backlight interface
  * If that fails, probe for VESA's backlight interface
  * If that fails, assume no DPCD backlight control
* If the panel's VBT reports any other backlight type: just assume it
  doesn't have DPCD backlight controls

Signed-off-by: Lyude Paul 
Cc: thay...@noraisin.net
Cc: Vasily Khoruzhick 
---
 .../drm/i915/display/intel_display_types.h|   9 +-
 .../drm/i915/display/intel_dp_aux_backlight.c | 244 --
 drivers/gpu/drm/i915/display/intel_panel.c|  34 ++-
 drivers/gpu/drm/i915/display/intel_panel.h|   4 +
 4 files changed, 263 insertions(+), 28 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/intel_display_types.h 
b/drivers/gpu/drm/i915/display/intel_display_types.h
index 47ee565c49a2..889b6f9c1aa9 100644
--- a/drivers/gpu/drm/i915/display/intel_display_types.h
+++ b/drivers/gpu/drm/i915/display/intel_display_types.h
@@ -261,7 +261,14 @@ struct intel_panel {
struct pwm_state pwm_state;
 
/* DPCD backlight */
-   u8 pwmgen_bit_count;
+   union {
+   struct {
+   u8 pwmgen_bit_count;
+   } vesa;
+   struct {
+   bool sdr_uses_aux;
+   } intel;
+   } edp;
 
struct backlight_device *device;
 
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 9775f33d1aac..9a3ff3ffc158 100644
--- a/drivers/gpu/drm/i915/display/intel_dp_aux_backlight.c
+++ b/drivers/gpu/drm/i915/display/intel_dp_aux_backlight.c
@@ -22,8 +22,26 @@
  *
  */
 
+/*
+ * Laptops with Intel GPUs which have panels that support controlling the
+ * backlight through DP AUX can actually use two different interfaces: Intel's
+ * proprietary DP AUX backlight interface, and the standard VESA backlight
+ * interface. Unfortunately, at the time of writing this a lot of laptops will
+ * advertise support for the standard VESA backlight interface when they
+ * don't properly support it. However, on these systems the Intel backlight
+ * interface generally does work properly. Additionally, these systems will
+ * usually just indicate that they use PWM backlight controls in their VBIOS
+ * for some reason.
+ */
+
 #include "intel_display_types.h"
 #include "intel_dp_aux_backlight.h"
+#include "intel_panel.h"
+
+/* TODO:
+ * Implement HDR, right now we just implement the bare minimum to bring us 
back into SDR mode so we
+ * can make people's backlights work in the mean time
+ */
 
 /*
  * DP AUX registers for Intel's proprietary HDR backlight interface. We define
@@ -77,6 +95,175 @@
 
 #define INTEL_EDP_BRIGHTNESS_OPTIMIZATION_10x359
 
+/* Intel EDP backlight callbacks */
+static bool
+intel_dp_aux_supports_hdr_backlight(struct intel_connector *connector)
+{
+   struct drm_device *dev = connector->base.dev;
+   struct intel_dp *intel_dp = enc_to_intel_dp(connector->encoder);
+   struct drm_dp_aux *aux = _dp->aux;
+   struct intel_panel *panel = >panel;
+   int ret;
+   u8 tcon_cap[4];
+
+   ret = drm_dp_dpcd_read(aux, INTEL_EDP_HDR_TCON_CAP0, tcon_cap, 
sizeof(tcon_cap));
+

[Intel-gfx] [PATCH v3 4/9] drm/i915: Keep track of pwm-related backlight hooks separately

2020-12-04 Thread Lyude Paul

Currently, every different type of backlight hook that i915 supports is
pretty straight forward - you have a backlight, probably through PWM
(but maybe DPCD), with a single set of platform-specific hooks that are
used for controlling it.

HDR backlights, in particular VESA and Intel's HDR backlight
implementations, can end up being more complicated. With Intel's
proprietary interface, HDR backlight controls always run through the
DPCD. When the backlight is in SDR backlight mode however, the driver
may need to bypass the TCON and control the backlight directly through
PWM.

So, in order to support this we'll need to split our backlight callbacks
into two groups: a set of high-level backlight control callbacks in
intel_panel, and an additional set of pwm-specific backlight control
callbacks. This also implies a functional changes for how these
callbacks are used:

* We now keep track of two separate backlight level ranges, one for the
  high-level backlight, and one for the pwm backlight range
* We also keep track of backlight enablement and PWM backlight
  enablement separately
* Since the currently set backlight level might not be the same as the
  currently programmed PWM backlight level, we stop setting
  panel->backlight.level with the currently programmed PWM backlight
  level in panel->backlight.pwm_funcs->setup(). Instead, we rely
  on the higher level backlight control functions to retrieve the
  current PWM backlight level (in this case, intel_pwm_get_backlight()).
  Note that there are still a few PWM backlight setup callbacks that
  do actually need to retrieve the current PWM backlight level, although
  we no longer save this value in panel->backlight.level like before.

Additionally, we drop the call to lpt_get_backlight() in
lpt_setup_backlight(), and avoid unconditionally writing the PWM value that
we get from it and only write it back if we're in PCH mode. The reason for
this is because in the original codepath for this, it was expected that the
intel_panel_bl_funcs->setup() hook would be responsible for fetching the
initial backlight level. On lpt systems, the only time we could ever be in
PCH backlight mode is during the initial driver load - meaning that outside
of the setup() hook, lpt_get_backlight() will always be the callback used
for retrieving the current backlight level. After this patch we still need
to fetch and write-back the PCH backlight value if we're in PCH mode, but
because intel_pwm_setup_backlight() will retrieve the backlight level after
setup() using the get() hook, which always ends up being
lpt_get_backlight(). Thus - an additional call to lpt_get_backlight() in
lpt_setup_backlight() is made redundant.

v3:
* Reuse intel_panel_bl_funcs() for pwm_funcs
* Explain why we drop lpt_get_backlight()

Signed-off-by: Lyude Paul 
Cc: thay...@noraisin.net
Cc: Vasily Khoruzhick 
---
 .../drm/i915/display/intel_display_types.h|   4 +
 drivers/gpu/drm/i915/display/intel_panel.c| 344 ++
 2 files changed, 194 insertions(+), 154 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/intel_display_types.h 
b/drivers/gpu/drm/i915/display/intel_display_types.h
index a70d1bf29aa5..47ee565c49a2 100644
--- a/drivers/gpu/drm/i915/display/intel_display_types.h
+++ b/drivers/gpu/drm/i915/display/intel_display_types.h
@@ -252,6 +252,9 @@ struct intel_panel {
bool alternate_pwm_increment;   /* lpt+ */
 
/* PWM chip */
+   u32 pwm_min;
+   u32 pwm_max;
+   bool pwm_enabled;
bool util_pin_active_low;   /* bxt+ */
u8 controller;  /* bxt+ only */
struct pwm_device *pwm;
@@ -263,6 +266,7 @@ struct intel_panel {
struct backlight_device *device;
 
const struct intel_panel_bl_funcs *funcs;
+   const struct intel_panel_bl_funcs *pwm_funcs;
void (*power)(struct intel_connector *, bool enable);
} backlight;
 };
diff --git a/drivers/gpu/drm/i915/display/intel_panel.c 
b/drivers/gpu/drm/i915/display/intel_panel.c
index 67f81ae995c4..41f0d2b2c627 100644
--- a/drivers/gpu/drm/i915/display/intel_panel.c
+++ b/drivers/gpu/drm/i915/display/intel_panel.c
@@ -511,25 +511,34 @@ static u32 scale_hw_to_user(struct intel_connector 
*connector,
 0, user_max);
 }
 
-static u32 intel_panel_compute_brightness(struct intel_connector *connector,
- u32 val)
+static u32 intel_panel_sanitize_pwm_level(struct intel_connector *connector, 
u32 val)
 {
struct drm_i915_private *dev_priv = to_i915(connector->base.dev);
struct intel_panel *panel = >panel;
 
-   drm_WARN_ON(_priv->drm, panel->backlight.max == 0);
+   drm_WARN_ON(_priv->drm, panel->backlight.pwm_max == 0);
 
if (dev_priv->params.invert_brightness < 0)
return val;
 
if (dev_priv->params.inv

[Intel-gfx] [PATCH v3 3/9] drm/i915: Pass down brightness values to enable/disable backlight callbacks

2020-12-04 Thread Lyude Paul

Instead of using intel_panel->backlight.level, have the caller provide us
with the current panel backlight value. We'll need this for when we
separate PWM-related backlight callbacks from other means of backlight
control (like DPCD backlight controls), as the caller of each PWM callback
will be responsible for converting the current brightness value to it's
respective PWM level.

Signed-off-by: Lyude Paul 
---
 .../drm/i915/display/intel_display_types.h|  4 +-
 .../drm/i915/display/intel_dp_aux_backlight.c |  8 +--
 .../i915/display/intel_dsi_dcs_backlight.c|  7 +-
 drivers/gpu/drm/i915/display/intel_panel.c| 67 +--
 4 files changed, 42 insertions(+), 44 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/intel_display_types.h 
b/drivers/gpu/drm/i915/display/intel_display_types.h
index 1fa0246b3a82..a70d1bf29aa5 100644
--- a/drivers/gpu/drm/i915/display/intel_display_types.h
+++ b/drivers/gpu/drm/i915/display/intel_display_types.h
@@ -230,9 +230,9 @@ struct intel_panel_bl_funcs {
int (*setup)(struct intel_connector *connector, enum pipe pipe);
u32 (*get)(struct intel_connector *connector);
void (*set)(const struct drm_connector_state *conn_state, u32 level);
-   void (*disable)(const struct drm_connector_state *conn_state);
+   void (*disable)(const struct drm_connector_state *conn_state, u32 
level);
void (*enable)(const struct intel_crtc_state *crtc_state,
-  const struct drm_connector_state *conn_state);
+  const struct drm_connector_state *conn_state, u32 level);
u32 (*hz_to_pwm)(struct intel_connector *connector, u32 hz);
 };
 
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 4fd536801b14..c76287e9e91e 100644
--- a/drivers/gpu/drm/i915/display/intel_dp_aux_backlight.c
+++ b/drivers/gpu/drm/i915/display/intel_dp_aux_backlight.c
@@ -174,7 +174,7 @@ static bool intel_dp_aux_set_pwm_freq(struct 
intel_connector *connector)
 }
 
 static void intel_dp_aux_enable_backlight(const struct intel_crtc_state 
*crtc_state,
- const struct drm_connector_state 
*conn_state)
+ const struct drm_connector_state 
*conn_state, u32 level)
 {
struct intel_connector *connector = 
to_intel_connector(conn_state->connector);
struct intel_dp *intel_dp = intel_attached_dp(connector);
@@ -225,12 +225,12 @@ static void intel_dp_aux_enable_backlight(const struct 
intel_crtc_state *crtc_st
}
}
 
-   intel_dp_aux_set_backlight(conn_state,
-  connector->panel.backlight.level);
+   intel_dp_aux_set_backlight(conn_state, level);
set_aux_backlight_enable(intel_dp, true);
 }
 
-static void intel_dp_aux_disable_backlight(const struct drm_connector_state 
*old_conn_state)
+static void intel_dp_aux_disable_backlight(const struct drm_connector_state 
*old_conn_state,
+  u32 level)
 {

set_aux_backlight_enable(enc_to_intel_dp(to_intel_encoder(old_conn_state->best_encoder)),
 false);
diff --git a/drivers/gpu/drm/i915/display/intel_dsi_dcs_backlight.c 
b/drivers/gpu/drm/i915/display/intel_dsi_dcs_backlight.c
index 5c508d51f526..88628764956d 100644
--- a/drivers/gpu/drm/i915/display/intel_dsi_dcs_backlight.c
+++ b/drivers/gpu/drm/i915/display/intel_dsi_dcs_backlight.c
@@ -77,7 +77,7 @@ static void dcs_set_backlight(const struct 
drm_connector_state *conn_state, u32
}
 }
 
-static void dcs_disable_backlight(const struct drm_connector_state *conn_state)
+static void dcs_disable_backlight(const struct drm_connector_state 
*conn_state, u32 level)
 {
struct intel_dsi *intel_dsi = 
enc_to_intel_dsi(to_intel_encoder(conn_state->best_encoder));
struct mipi_dsi_device *dsi_device;
@@ -111,10 +111,9 @@ static void dcs_disable_backlight(const struct 
drm_connector_state *conn_state)
 }
 
 static void dcs_enable_backlight(const struct intel_crtc_state *crtc_state,
-const struct drm_connector_state *conn_state)
+const struct drm_connector_state *conn_state, 
u32 level)
 {
struct intel_dsi *intel_dsi = 
enc_to_intel_dsi(to_intel_encoder(conn_state->best_encoder));
-   struct intel_panel *panel = 
_intel_connector(conn_state->connector)->panel;
struct mipi_dsi_device *dsi_device;
enum port port;
 
@@ -142,7 +141,7 @@ static void dcs_enable_backlight(const struct 
intel_crtc_state *crtc_state,
   , sizeof(cabc));
}
 
-   dcs_set_backlight(conn_state, panel->backlight.level);
+   dcs_set_backlight(conn_state, level);
 }
 
 static int dcs_setup_backlight(struct intel_connector *connector,
diff --git a/drivers/gpu/drm/i915/display/intel

[Intel-gfx] [PATCH v3 5/9] drm/i915/dp: Rename eDP VESA backlight interface functions

2020-12-04 Thread Lyude Paul

Since we're about to add support for a second type of backlight control
interface over DP AUX (specifically, Intel's proprietary HDR backlight
controls) let's rename all of the current backlight hooks we have for
vesa to make it clear that they're specific to the VESA interface and
not Intel's.

v3:
* Rebase

Signed-off-by: Lyude Paul 
Reviewed-by: Rodrigo Vivi 
Cc: thay...@noraisin.net
Cc: Vasily Khoruzhick 
---
 .../drm/i915/display/intel_dp_aux_backlight.c | 62 ++-
 1 file changed, 32 insertions(+), 30 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/intel_dp_aux_backlight.c 
b/drivers/gpu/drm/i915/display/intel_dp_aux_backlight.c
index c76287e9e91e..b102692a659d 100644
--- a/drivers/gpu/drm/i915/display/intel_dp_aux_backlight.c
+++ b/drivers/gpu/drm/i915/display/intel_dp_aux_backlight.c
@@ -25,7 +25,7 @@
 #include "intel_display_types.h"
 #include "intel_dp_aux_backlight.h"
 
-static void set_aux_backlight_enable(struct intel_dp *intel_dp, bool enable)
+static void set_vesa_backlight_enable(struct intel_dp *intel_dp, bool enable)
 {
struct drm_i915_private *i915 = dp_to_i915(intel_dp);
u8 reg_val = 0;
@@ -52,7 +52,7 @@ static void set_aux_backlight_enable(struct intel_dp 
*intel_dp, bool enable)
}
 }
 
-static bool intel_dp_aux_backlight_dpcd_mode(struct intel_connector *connector)
+static bool intel_dp_aux_vesa_backlight_dpcd_mode(struct intel_connector 
*connector)
 {
struct intel_dp *intel_dp = intel_attached_dp(connector);
struct drm_i915_private *i915 = dp_to_i915(intel_dp);
@@ -75,7 +75,7 @@ static bool intel_dp_aux_backlight_dpcd_mode(struct 
intel_connector *connector)
  * Read the current backlight value from DPCD register(s) based
  * on if 8-bit(MSB) or 16-bit(MSB and LSB) values are supported
  */
-static u32 intel_dp_aux_get_backlight(struct intel_connector *connector)
+static u32 intel_dp_aux_vesa_get_backlight(struct intel_connector *connector)
 {
struct intel_dp *intel_dp = intel_attached_dp(connector);
struct drm_i915_private *i915 = dp_to_i915(intel_dp);
@@ -86,7 +86,7 @@ static u32 intel_dp_aux_get_backlight(struct intel_connector 
*connector)
 * If we're not in DPCD control mode yet, the programmed brightness
 * value is meaningless and we should assume max brightness
 */
-   if (!intel_dp_aux_backlight_dpcd_mode(connector))
+   if (!intel_dp_aux_vesa_backlight_dpcd_mode(connector))
return connector->panel.backlight.max;
 
if (drm_dp_dpcd_read(_dp->aux, DP_EDP_BACKLIGHT_BRIGHTNESS_MSB,
@@ -107,7 +107,8 @@ static u32 intel_dp_aux_get_backlight(struct 
intel_connector *connector)
  * 8-bit or 16 bit value (MSB and LSB)
  */
 static void
-intel_dp_aux_set_backlight(const struct drm_connector_state *conn_state, u32 
level)
+intel_dp_aux_vesa_set_backlight(const struct drm_connector_state *conn_state,
+   u32 level)
 {
struct intel_connector *connector = 
to_intel_connector(conn_state->connector);
struct intel_dp *intel_dp = intel_attached_dp(connector);
@@ -137,7 +138,7 @@ intel_dp_aux_set_backlight(const struct drm_connector_state 
*conn_state, u32 lev
  * - Where P = 2^Pn, where Pn is the value programmed by field 4:0 of the
  * EDP_PWMGEN_BIT_COUNT register (DPCD Address 00724h)
  */
-static bool intel_dp_aux_set_pwm_freq(struct intel_connector *connector)
+static bool intel_dp_aux_vesa_set_pwm_freq(struct intel_connector *connector)
 {
struct drm_i915_private *dev_priv = to_i915(connector->base.dev);
struct intel_dp *intel_dp = intel_attached_dp(connector);
@@ -173,8 +174,9 @@ static bool intel_dp_aux_set_pwm_freq(struct 
intel_connector *connector)
return true;
 }
 
-static void intel_dp_aux_enable_backlight(const struct intel_crtc_state 
*crtc_state,
- const struct drm_connector_state 
*conn_state, u32 level)
+static void
+intel_dp_aux_vesa_enable_backlight(const struct intel_crtc_state *crtc_state,
+  const struct drm_connector_state 
*conn_state, u32 level)
 {
struct intel_connector *connector = 
to_intel_connector(conn_state->connector);
struct intel_dp *intel_dp = intel_attached_dp(connector);
@@ -214,7 +216,7 @@ static void intel_dp_aux_enable_backlight(const struct 
intel_crtc_state *crtc_st
}
 
if (intel_dp->edp_dpcd[2] & DP_EDP_BACKLIGHT_FREQ_AUX_SET_CAP)
-   if (intel_dp_aux_set_pwm_freq(connector))
+   if (intel_dp_aux_vesa_set_pwm_freq(connector))
new_dpcd_buf |= DP_EDP_BACKLIGHT_FREQ_AUX_SET_ENABLE;
 
if (new_dpcd_buf != dpcd_buf) {
@@ -225,18 +227,18 @@ static void intel_dp_aux_enable_backlight(const struct 
intel_crtc_state *crtc_st
}
}
 
-   intel_dp_aux_set_backlight(conn_state, level);
-

[Intel-gfx] [PATCH v3 6/9] drm/i915/dp: Add register definitions for Intel HDR backlight interface

2020-12-04 Thread Lyude Paul

No functional changes yet, this just adds definitions for all of the
known DPCD registers used by Intel's HDR backlight interface. Since
we'll only ever use this in i915, we just define them in
intel_dp_aux_backlight.c

Reviewed-by: Rodrigo Vivi 
Signed-off-by: Lyude Paul 
Cc: thay...@noraisin.net
Cc: Vasily Khoruzhick 
---
 .../drm/i915/display/intel_dp_aux_backlight.c | 53 +++
 1 file changed, 53 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 b102692a659d..9775f33d1aac 100644
--- a/drivers/gpu/drm/i915/display/intel_dp_aux_backlight.c
+++ b/drivers/gpu/drm/i915/display/intel_dp_aux_backlight.c
@@ -25,6 +25,59 @@
 #include "intel_display_types.h"
 #include "intel_dp_aux_backlight.h"
 
+/*
+ * DP AUX registers for Intel's proprietary HDR backlight interface. We define
+ * them here since we'll likely be the only driver to ever use these.
+ */
+#define INTEL_EDP_HDR_TCON_CAP00x340
+
+#define INTEL_EDP_HDR_TCON_CAP10x341
+# define INTEL_EDP_HDR_TCON_2084_DECODE_CAP   BIT(0)
+# define INTEL_EDP_HDR_TCON_2020_GAMUT_CAPBIT(1)
+# define INTEL_EDP_HDR_TCON_TONE_MAPPING_CAP  BIT(2)
+# define INTEL_EDP_HDR_TCON_SEGMENTED_BACKLIGHT_CAP   BIT(3)
+# define INTEL_EDP_HDR_TCON_BRIGHTNESS_NITS_CAP   BIT(4)
+# define INTEL_EDP_HDR_TCON_OPTIMIZATION_CAP  BIT(5)
+# define INTEL_EDP_HDR_TCON_SDP_COLORIMETRY_CAP   BIT(6)
+# define INTEL_EDP_HDR_TCON_SRGB_TO_PANEL_GAMUT_CONVERSION_CAPBIT(7)
+
+#define INTEL_EDP_HDR_TCON_CAP20x342
+# define INTEL_EDP_SDR_TCON_BRIGHTNESS_AUX_CAPBIT(0)
+
+#define INTEL_EDP_HDR_TCON_CAP30x343
+
+#define INTEL_EDP_HDR_GETSET_CTRL_PARAMS   0x344
+# define INTEL_EDP_HDR_TCON_2084_DECODE_ENABLEBIT(0)
+# define INTEL_EDP_HDR_TCON_2020_GAMUT_ENABLE BIT(1)
+# define INTEL_EDP_HDR_TCON_TONE_MAPPING_ENABLE   BIT(2) 
/* Pre-TGL+ */
+# define INTEL_EDP_HDR_TCON_SEGMENTED_BACKLIGHT_ENABLEBIT(3)
+# define INTEL_EDP_HDR_TCON_BRIGHTNESS_AUX_ENABLE BIT(4)
+# define INTEL_EDP_HDR_TCON_SRGB_TO_PANEL_GAMUT_ENABLEBIT(5)
+/* Bit 6 is reserved */
+# define INTEL_EDP_HDR_TCON_SDP_COLORIMETRY_ENABLEBIT(7)
+
+#define INTEL_EDP_HDR_CONTENT_LUMINANCE0x346 
/* Pre-TGL+ */
+#define INTEL_EDP_HDR_PANEL_LUMINANCE_OVERRIDE 0x34A
+#define INTEL_EDP_SDR_LUMINANCE_LEVEL  0x352
+#define INTEL_EDP_BRIGHTNESS_NITS_LSB  0x354
+#define INTEL_EDP_BRIGHTNESS_NITS_MSB  0x355
+#define INTEL_EDP_BRIGHTNESS_DELAY_FRAMES  0x356
+#define INTEL_EDP_BRIGHTNESS_PER_FRAME_STEPS   0x357
+
+#define INTEL_EDP_BRIGHTNESS_OPTIMIZATION_00x358
+# define INTEL_EDP_TCON_USAGE_MASK GENMASK(0, 3)
+# define INTEL_EDP_TCON_USAGE_UNKNOWN0x0
+# define INTEL_EDP_TCON_USAGE_DESKTOP0x1
+# define INTEL_EDP_TCON_USAGE_FULL_SCREEN_MEDIA  0x2
+# define INTEL_EDP_TCON_USAGE_FULL_SCREEN_GAMING 0x3
+# define INTEL_EDP_TCON_POWER_MASKBIT(4)
+# define INTEL_EDP_TCON_POWER_DC(0 << 4)
+# define INTEL_EDP_TCON_POWER_AC(1 << 4)
+# define INTEL_EDP_TCON_OPTIMIZATION_STRENGTH_MASK GENMASK(5, 7)
+
+#define INTEL_EDP_BRIGHTNESS_OPTIMIZATION_10x359
+
+/* VESA backlight callbacks */
 static void set_vesa_backlight_enable(struct intel_dp *intel_dp, bool enable)
 {
struct drm_i915_private *i915 = dp_to_i915(intel_dp);
-- 
2.28.0

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH v3 2/9] drm/i915: Rename pwm_* backlight callbacks to ext_pwm_*

2020-12-04 Thread Lyude Paul

Since we're going to need to add a set of lower-level PWM backlight
control hooks to be shared by normal backlight controls and HDR
backlight controls in SDR mode, let's add a prefix to the external PWM
backlight functions so that the difference between them and the high
level PWM-only backlight functions is a bit more obvious.

This introduces no functional changes.

Signed-off-by: Lyude Paul 
Reviewed-by: Rodrigo Vivi 
Reviewed-by: Jani Nikula 
Cc: thay...@noraisin.net
Cc: Vasily Khoruzhick 
---
 drivers/gpu/drm/i915/display/intel_panel.c | 28 +++---
 1 file changed, 14 insertions(+), 14 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/intel_panel.c 
b/drivers/gpu/drm/i915/display/intel_panel.c
index 36b7693453ae..da8f7c12ae22 100644
--- a/drivers/gpu/drm/i915/display/intel_panel.c
+++ b/drivers/gpu/drm/i915/display/intel_panel.c
@@ -589,7 +589,7 @@ static u32 bxt_get_backlight(struct intel_connector 
*connector)
 BXT_BLC_PWM_DUTY(panel->backlight.controller));
 }
 
-static u32 pwm_get_backlight(struct intel_connector *connector)
+static u32 ext_pwm_get_backlight(struct intel_connector *connector)
 {
struct intel_panel *panel = >panel;
struct pwm_state state;
@@ -666,7 +666,7 @@ static void bxt_set_backlight(const struct 
drm_connector_state *conn_state, u32
   BXT_BLC_PWM_DUTY(panel->backlight.controller), level);
 }
 
-static void pwm_set_backlight(const struct drm_connector_state *conn_state, 
u32 level)
+static void ext_pwm_set_backlight(const struct drm_connector_state 
*conn_state, u32 level)
 {
struct intel_panel *panel = 
_intel_connector(conn_state->connector)->panel;
 
@@ -835,7 +835,7 @@ static void cnp_disable_backlight(const struct 
drm_connector_state *old_conn_sta
   tmp & ~BXT_BLC_PWM_ENABLE);
 }
 
-static void pwm_disable_backlight(const struct drm_connector_state 
*old_conn_state)
+static void ext_pwm_disable_backlight(const struct drm_connector_state 
*old_conn_state)
 {
struct intel_connector *connector = 
to_intel_connector(old_conn_state->connector);
struct intel_panel *panel = >panel;
@@ -1168,8 +1168,8 @@ static void cnp_enable_backlight(const struct 
intel_crtc_state *crtc_state,
   pwm_ctl | BXT_BLC_PWM_ENABLE);
 }
 
-static void pwm_enable_backlight(const struct intel_crtc_state *crtc_state,
-const struct drm_connector_state *conn_state)
+static void ext_pwm_enable_backlight(const struct intel_crtc_state *crtc_state,
+const struct drm_connector_state 
*conn_state)
 {
struct intel_connector *connector = 
to_intel_connector(conn_state->connector);
struct intel_panel *panel = >panel;
@@ -1890,8 +1890,8 @@ cnp_setup_backlight(struct intel_connector *connector, 
enum pipe unused)
return 0;
 }
 
-static int pwm_setup_backlight(struct intel_connector *connector,
-  enum pipe pipe)
+static int ext_pwm_setup_backlight(struct intel_connector *connector,
+  enum pipe pipe)
 {
struct drm_device *dev = connector->base.dev;
struct drm_i915_private *dev_priv = to_i915(dev);
@@ -2061,12 +2061,12 @@ static const struct intel_panel_bl_funcs pch_funcs = {
.hz_to_pwm = pch_hz_to_pwm,
 };
 
-static const struct intel_panel_bl_funcs pwm_funcs = {
-   .setup = pwm_setup_backlight,
-   .enable = pwm_enable_backlight,
-   .disable = pwm_disable_backlight,
-   .set = pwm_set_backlight,
-   .get = pwm_get_backlight,
+static const struct intel_panel_bl_funcs ext_pwm_funcs = {
+   .setup = ext_pwm_setup_backlight,
+   .enable = ext_pwm_enable_backlight,
+   .disable = ext_pwm_disable_backlight,
+   .set = ext_pwm_set_backlight,
+   .get = ext_pwm_get_backlight,
 };
 
 static const struct intel_panel_bl_funcs vlv_funcs = {
@@ -2125,7 +2125,7 @@ intel_panel_init_backlight_funcs(struct intel_panel 
*panel)
panel->backlight.funcs = _funcs;
} else if (IS_VALLEYVIEW(dev_priv) || IS_CHERRYVIEW(dev_priv)) {
if (connector->base.connector_type == DRM_MODE_CONNECTOR_DSI) {
-   panel->backlight.funcs = _funcs;
+   panel->backlight.funcs = _pwm_funcs;
} else {
panel->backlight.funcs = _funcs;
}
-- 
2.28.0

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH v3 1/9] drm/i915/dp: Program source OUI on eDP panels

2020-12-04 Thread Lyude Paul

Since we're about to start adding support for Intel's magic HDR
backlight interface over DPCD, we need to ensure we're properly
programming this field so that Intel specific sink services are exposed.
Otherwise, 0x300-0x3ff will just read zeroes.

We also take care not to reprogram the source OUI if it already matches
what we expect. This is just to be careful so that we don't accidentally
take the panel out of any backlight control modes we found it in.

v2:
* Add careful parameter to intel_edp_init_source_oui() to avoid
  re-writing the source OUI if it's already been set during driver
  initialization

Signed-off-by: Lyude Paul 
Reviewed-by: Rodrigo Vivi 
Cc: thay...@noraisin.net
Cc: Vasily Khoruzhick 
---
 drivers/gpu/drm/i915/display/intel_dp.c | 33 +
 1 file changed, 33 insertions(+)

diff --git a/drivers/gpu/drm/i915/display/intel_dp.c 
b/drivers/gpu/drm/i915/display/intel_dp.c
index 2d4d5e95af84..4cb2bfee9c40 100644
--- a/drivers/gpu/drm/i915/display/intel_dp.c
+++ b/drivers/gpu/drm/i915/display/intel_dp.c
@@ -3583,6 +3583,29 @@ void intel_dp_sink_set_decompression_state(struct 
intel_dp *intel_dp,
enable ? "enable" : "disable");
 }
 
+static void
+intel_edp_init_source_oui(struct intel_dp *intel_dp, bool careful)
+{
+   struct drm_i915_private *i915 = dp_to_i915(intel_dp);
+   u8 oui[] = { 0x00, 0xaa, 0x01 };
+   u8 buf[3] = { 0 };
+
+   /*
+* During driver init, we want to be careful and avoid changing the 
source OUI if it's
+* already set to what we want, so as to avoid clearing any state by 
accident
+*/
+   if (careful) {
+   if (drm_dp_dpcd_read(_dp->aux, DP_SOURCE_OUI, buf, 
sizeof(buf)) < 0)
+   drm_err(>drm, "Failed to read source OUI\n");
+
+   if (memcmp(oui, buf, sizeof(oui)) == 0)
+   return;
+   }
+
+   if (drm_dp_dpcd_write(_dp->aux, DP_SOURCE_OUI, oui, sizeof(oui)) 
< 0)
+   drm_err(>drm, "Failed to write source OUI\n");
+}
+
 /* If the device supports it, try to set the power state appropriately */
 void intel_dp_set_power(struct intel_dp *intel_dp, u8 mode)
 {
@@ -3604,6 +3627,10 @@ void intel_dp_set_power(struct intel_dp *intel_dp, u8 
mode)
 
lspcon_resume(dp_to_dig_port(intel_dp));
 
+   /* Write the source OUI as early as possible */
+   if (intel_dp_is_edp(intel_dp))
+   intel_edp_init_source_oui(intel_dp, false);
+
/*
 * When turning on, we need to retry for 1ms to give the sink
 * time to wake up.
@@ -4869,6 +4896,12 @@ intel_edp_init_dpcd(struct intel_dp *intel_dp)
if (INTEL_GEN(dev_priv) >= 10 || IS_GEMINILAKE(dev_priv))
intel_dp_get_dsc_sink_cap(intel_dp);
 
+   /*
+* If needed, program our source OUI so we can make various 
Intel-specific AUX services
+* available (such as HDR backlight controls)
+*/
+   intel_edp_init_source_oui(intel_dp, true);
+
return true;
 }
 
-- 
2.28.0

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH v3 0/9] drm/i915: Add support for Intel's eDP backlight controls

2020-12-04 Thread Lyude Paul

A while ago we ran into issues while trying to enable the eDP backlight
control interface as defined by VESA, in order to make the DPCD
backlight controls on newer laptop panels work. The issue ended up being
much more complicated however, as we also apparently needed to add
support for an Intel-specific DPCD backlight control interface as the
VESA interface is broken on many laptop panels. For lack of a better
name, we just call this the Intel HDR backlight interface.

While this only adds support for the SDR backlight mode (I think), this
will fix a lot of user's laptop panels that we weren't able to properly
automatically detect DPCD backlight controls on previously.

Series-wide changes in v3:
* Pass down brightness values to enable/disable backlight callbacks in a
  separate patch
* Rebase

Lyude Paul (9):
  drm/i915/dp: Program source OUI on eDP panels
  drm/i915: Rename pwm_* backlight callbacks to ext_pwm_*
  drm/i915: Pass down brightness values to enable/disable backlight
callbacks
  drm/i915: Keep track of pwm-related backlight hooks separately
  drm/i915/dp: Rename eDP VESA backlight interface functions
  drm/i915/dp: Add register definitions for Intel HDR backlight
interface
  drm/i915/dp: Enable Intel's HDR backlight interface (only SDR for now)
  drm/i915/dp: Allow forcing specific interfaces through
enable_dpcd_backlight
  drm/dp: Revert "drm/dp: Introduce EDID-based quirks"

 drivers/gpu/drm/drm_dp_helper.c   |  83 +---
 drivers/gpu/drm/drm_dp_mst_topology.c |   3 +-
 .../drm/i915/display/intel_display_types.h|  18 +-
 drivers/gpu/drm/i915/display/intel_dp.c   |  42 +-
 .../drm/i915/display/intel_dp_aux_backlight.c | 394 +---
 drivers/gpu/drm/i915/display/intel_dp_mst.c   |   3 +-
 .../i915/display/intel_dsi_dcs_backlight.c|   7 +-
 drivers/gpu/drm/i915/display/intel_panel.c| 435 ++
 drivers/gpu/drm/i915/display/intel_panel.h|   4 +
 drivers/gpu/drm/i915/display/intel_psr.c  |   2 +-
 drivers/gpu/drm/i915/i915_params.c|   2 +-
 include/drm/drm_dp_helper.h   |  21 +-
 12 files changed, 655 insertions(+), 359 deletions(-)

-- 
2.28.0

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [RFC v2 3/8] drm/i915: Keep track of pwm-related backlight hooks separately

2020-11-30 Thread Lyude Paul

On Thu, 2020-11-26 at 13:57 +0200, Jani Nikula wrote:
> On Thu, 26 Nov 2020, Dave Airlie  wrote:
> > On Thu, 17 Sept 2020 at 03:19, Lyude Paul  wrote:
> > > 
> > > Currently, every different type of backlight hook that i915 supports is
> > > pretty straight forward - you have a backlight, probably through PWM
> > > (but maybe DPCD), with a single set of platform-specific hooks that are
> > > used for controlling it.
> > > 
> > > HDR backlights, in particular VESA and Intel's HDR backlight
> > > implementations, can end up being more complicated. With Intel's
> > > proprietary interface, HDR backlight controls always run through the
> > > DPCD. When the backlight is in SDR backlight mode however, the driver
> > > may need to bypass the TCON and control the backlight directly through
> > > PWM.
> > > 
> > > So, in order to support this we'll need to split our backlight callbacks
> > > into two groups: a set of high-level backlight control callbacks in
> > > intel_panel, and an additional set of pwm-specific backlight control
> > > callbacks. This also implies a functional changes for how these
> > > callbacks are used:
> > > 
> > > * We now keep track of two separate backlight level ranges, one for the
> > >   high-level backlight, and one for the pwm backlight range
> > > * We also keep track of backlight enablement and PWM backlight
> > >   enablement separately
> > > * Since the currently set backlight level might not be the same as the
> > >   currently programmed PWM backlight level, we stop setting
> > >   panel->backlight.level with the currently programmed PWM backlight
> > >   level in panel->backlight.pwm_funcs.setup(). Instead, we rely
> > >   on the higher level backlight control functions to retrieve the
> > >   current PWM backlight level (in this case, intel_pwm_get_backlight()).
> > >   Note that there are still a few PWM backlight setup callbacks that
> > >   do actually need to retrieve the current PWM backlight level, although
> > >   we no longer save this value in panel->backlight.level like before.
> > > * panel->backlight.pwm_funcs.enable()/disable() both accept a PWM
> > >   brightness level, unlike their siblings
> > >   panel->backlight.enable()/disable(). This is so we can calculate the
> > >   actual PWM brightness level we want to set on disable/enable in the
> > >   higher level backlight enable()/disable() functions, since this value
> > >   might be scaled from a brightness level that doesn't come from PWM.
> > 
> > Oh this patch is a handful, I can see why people stall out here.
> > 
> > I'm going to be annoying maintainer and see if you can clean this up a
> > bit in advance of this patch.
> 
> Agreed. And not looking into and requesting this earlier is on me.
> 
> The thing that still keeps bugging me about the DPCD brightness control
> in general is that it's a historical mistake to put all of this under
> i915. (Again, mea culpa.) The standard DPCD brightness control should
> really be under drm core, in one form or another.

JFYI - I already actually have a WIP series to move all of the VESA standard
brightness stuff into the DRM core (especially since I am adding support for
the VESA interface to nouveau). It is pretty important to do so especially
considering some of the ways panel manufacturers seem to have consistently
gotten some portions of the spec wrong (there's currently a bug on almost
every panel I've run into, minus some panels in laptops that run ChromeOS,
where they interpret the brightness value as LSB aligned and not MSB aligned
(which is what the eDP spec actually says), because almost everyone misread
it. So, definitely the kind of stuff we'd want to keep in the drm core to make
maintaining quirks like this easier.

> 
> I'm not asking to fix that here. But I *am* wondering if the series
> makes that harder. What would it look like if we did have that unicorn
> of a brightness connector property? How would that tie into the hooks we
> have?

Re: making it harder, not really. But either way I'm planning on doing the
work for this anyway :)

> 
> Maybe the answer is that the DPCD backlight functions should just be
> library code in drm core that the drivers could call. In the long run,
> i915 really can't be the only one needing this stuff.
> 
> We haven't implemented the mixed modes of DPCD and eDP PWM pin
> brightness control. But the point is, the library code can't call into
> i915 specific eDP PWM pin control code. The proprietary HDR brightness
> code will still be i915 specific, but does it

Re: [Intel-gfx] [RFC v2 3/8] drm/i915: Keep track of pwm-related backlight hooks separately

2020-11-30 Thread Lyude Paul

On Thu, 2020-11-26 at 11:03 +1000, Dave Airlie wrote:
> On Thu, 17 Sept 2020 at 03:19, Lyude Paul  wrote:
> > 
> > Currently, every different type of backlight hook that i915 supports is
> > pretty straight forward - you have a backlight, probably through PWM
> > (but maybe DPCD), with a single set of platform-specific hooks that are
> > used for controlling it.
> > 
> > HDR backlights, in particular VESA and Intel's HDR backlight
> > implementations, can end up being more complicated. With Intel's
> > proprietary interface, HDR backlight controls always run through the
> > DPCD. When the backlight is in SDR backlight mode however, the driver
> > may need to bypass the TCON and control the backlight directly through
> > PWM.
> > 
> > So, in order to support this we'll need to split our backlight callbacks
> > into two groups: a set of high-level backlight control callbacks in
> > intel_panel, and an additional set of pwm-specific backlight control
> > callbacks. This also implies a functional changes for how these
> > callbacks are used:
> > 
> > * We now keep track of two separate backlight level ranges, one for the
> >   high-level backlight, and one for the pwm backlight range
> > * We also keep track of backlight enablement and PWM backlight
> >   enablement separately
> > * Since the currently set backlight level might not be the same as the
> >   currently programmed PWM backlight level, we stop setting
> >   panel->backlight.level with the currently programmed PWM backlight
> >   level in panel->backlight.pwm_funcs.setup(). Instead, we rely
> >   on the higher level backlight control functions to retrieve the
> >   current PWM backlight level (in this case, intel_pwm_get_backlight()).
> >   Note that there are still a few PWM backlight setup callbacks that
> >   do actually need to retrieve the current PWM backlight level, although
> >   we no longer save this value in panel->backlight.level like before.
> > * panel->backlight.pwm_funcs.enable()/disable() both accept a PWM
> >   brightness level, unlike their siblings
> >   panel->backlight.enable()/disable(). This is so we can calculate the
> >   actual PWM brightness level we want to set on disable/enable in the
> >   higher level backlight enable()/disable() functions, since this value
> >   might be scaled from a brightness level that doesn't come from PWM.
> 
> Oh this patch is a handful, I can see why people stall out here.
> 
> I'm going to be annoying maintainer and see if you can clean this up a
> bit in advance
> of this patch.
> 

Not annoying at all :), I was hoping there'd be a good bit of criticism on
this patch series since it's been hard to figure out if I'm even implementing
things in the right way or not (especially because I really don't know what
the HDR side of this is going to look like, although I assume it's probably
going to be pretty hands-off in the kernel).

JFYI too for folks on the list, any suggestions about the HDR side of this are
super appreciated. I'm barely familiar with such things.

> 1) move the callbacks out of struct intel_panel.backlight into a separate
> struct
> and use const static object tables, having fn ptrs and data co-located
> in a struct
> isn't great.
> 
> strcut intel_panel_backlight_funcs {
> 
> };
> struct intel_panel {
>     struct {
>     struct intel_panel_backlight_funcs *funcs;
>     };
> };
> 
> type of thing.
> 
> I think you could reuse the backlight funcs struct for the pwm stuff
> as well. (maybe with an assert on hz_to_pwm for the old hooks).
> 
> 2) change the apis to pass 0 down in a separate patch, this modifies a
> bunch of apis to pass in an extra level parameter, do that
> first in a separate patch that doesn't change anything but hands 0
> down the chain. Then switch over in another patch.
> 
> 3) One comment in passing below.
> > 
> > 
> > -   if (cpu_mode)
> > -   val = pch_get_backlight(connector);
> > -   else
> > -   val = lpt_get_backlight(connector);
> > -   val = intel_panel_compute_brightness(connector, val);
> > -   panel->backlight.level = clamp(val, panel->backlight.min,
> > -  panel->backlight.max);
> > 
> >     if (cpu_mode) {
> > +   val = intel_panel_sanitize_pwm_level(connector,
> > pch_get_backlight(connector));
> > +
> >     drm_dbg_kms(_priv->drm,
> >     "CPU backlight register was enabled, switching
> > to PCH override\n");
> > 
> >

Re: [Intel-gfx] [RFC v2 1/8] drm/i915/dp: Program source OUI on eDP panels

2020-11-30 Thread Lyude Paul

On Thu, 2020-11-26 at 12:51 +0200, Jani Nikula wrote:
> On Wed, 16 Sep 2020, Lyude Paul  wrote:
> > Since we're about to start adding support for Intel's magic HDR
> > backlight interface over DPCD, we need to ensure we're properly
> > programming this field so that Intel specific sink services are exposed.
> > Otherwise, 0x300-0x3ff will just read zeroes.
> > 
> > We also take care not to reprogram the source OUI if it already matches
> > what we expect. This is just to be careful so that we don't accidentally
> > take the panel out of any backlight control modes we found it in.
> > 
> > v2:
> > * Add careful parameter to intel_edp_init_source_oui() to avoid
> >   re-writing the source OUI if it's already been set during driver
> >   initialization
> > 
> > Signed-off-by: Lyude Paul 
> > Cc: thay...@noraisin.net
> > Cc: Vasily Khoruzhick 
> > ---
> >  drivers/gpu/drm/i915/display/intel_dp.c | 33 +
> >  1 file changed, 33 insertions(+)
> > 
> > diff --git a/drivers/gpu/drm/i915/display/intel_dp.c
> > b/drivers/gpu/drm/i915/display/intel_dp.c
> > index 4bd10456ad188..7db2b6a3cd52e 100644
> > --- a/drivers/gpu/drm/i915/display/intel_dp.c
> > +++ b/drivers/gpu/drm/i915/display/intel_dp.c
> > @@ -3424,6 +3424,29 @@ void intel_dp_sink_set_decompression_state(struct
> > intel_dp *intel_dp,
> >     enable ? "enable" : "disable");
> >  }
> >  
> > +static void
> > +intel_edp_init_source_oui(struct intel_dp *intel_dp, bool careful)
> > +{
> > +   struct drm_i915_private *i915 = dp_to_i915(intel_dp);
> > +   u8 oui[] = { 0x00, 0xaa, 0x01 };
> 
> Nitpick, could be static const.
> 
> > +   u8 buf[3] = { 0 };
> > +
> > +   /*
> > +    * During driver init, we want to be careful and avoid changing
> > the source OUI if it's
> > +    * already set to what we want, so as to avoid clearing any state
> > by accident
> > +    */
> 
> Did you actually observe any ill behaviour with unconditionally writing
> the source OUI?
> 
> I mean it's easy to add the "careful" mode afterwards if there are
> concrete issues, but it'll be hard to remove because it'll be a
> functional change potentially causing regressions.

I haven't yet, although I'll give a test on some of the other machines I've
got lying around.

FWIW, relevant spec info:

   A Sink device that does not support the Source-device specified behavior
   specified by the owner of the IEEE OUI written to in DPCD Addresses 00300h
   through 00302h as being associated with the Source Identification shall
   AUX_ACK all writes, but take no other action, and shall respond to reads
   with an AUX_ACK and the value 00h.

> 
> > +   if (careful) {
> > +   if (drm_dp_dpcd_read(_dp->aux, DP_SOURCE_OUI, buf,
> > sizeof(buf)) < 0)
> > +   drm_err(>drm, "Failed to read source
> > OUI\n");
> > +
> > +   if (memcmp(oui, buf, sizeof(oui)) == 0)
> > +   return;
> > +   }
> > +
> > +   if (drm_dp_dpcd_write(_dp->aux, DP_SOURCE_OUI, oui,
> > sizeof(oui)) < 0)
> > +   drm_err(>drm, "Failed to write source OUI\n");
> > +}
> > +
> >  /* If the sink supports it, try to set the power state appropriately */
> >  void intel_dp_sink_dpms(struct intel_dp *intel_dp, int mode)
> >  {
> > @@ -3443,6 +3466,10 @@ void intel_dp_sink_dpms(struct intel_dp *intel_dp,
> > int mode)
> > } else {
> > struct intel_lspcon *lspcon = dp_to_lspcon(intel_dp);
> >  
> > +   /* Write the source OUI as early as possible */
> > +   if (intel_dp_is_edp(intel_dp))
> > +   intel_edp_init_source_oui(intel_dp, false);
> > +
> 
> This hunk conflicts, will need a rebase.
> 
> BR,
> Jani.
> 
> 
> > /*
> >  * When turning on, we need to retry for 1ms to give the
> > sink
> >  * time to wake up.
> > @@ -4607,6 +4634,12 @@ intel_edp_init_dpcd(struct intel_dp *intel_dp)
> > if (INTEL_GEN(dev_priv) >= 10 || IS_GEMINILAKE(dev_priv))
> > intel_dp_get_dsc_sink_cap(intel_dp);
> >  
> > +   /*
> > +    * If needed, program our source OUI so we can make various Intel-
> > specific AUX services
> > +    * available (such as HDR backlight controls)
> > +    */
> > +   intel_edp_init_source_oui(intel_dp, true);
> > +
> > return true;
> >  }
> 

-- 
Cheers,
 Lyude Paul (she/her)
 Software Engineer at Red Hat

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH] drm/i915/tgl: Set drm_crtc_state.active=false for all added disconnected CRTCs sharing MST stream.

2020-10-21 Thread Lyude Paul

On Wed, 2020-10-21 at 16:26 +0300, Ville Syrjälä wrote:
> On Tue, Oct 20, 2020 at 11:25:53PM +, Souza, Jose wrote:
> > On Tue, 2020-10-20 at 15:41 +0300, Ville SyrjÃƒÂ¤lÃƒÂ¤ wrote:
> > > On Tue, Oct 20, 2020 at 12:45:55AM -0700, Khaled Almahallawy wrote:
> > > > This patch avoids failing atomic commits sent by user space by making
> > > > sure CRTC/Connector added to drm_atomic_state by the driver are in valid
> > > > state.
> > > > 
> > > > When disconnecting MST hub with two or more connected displays. The user
> > > > space sends IOCTL for each MST pipe to disable.
> > > > drm_atomic_state object sent from user space contains only the state of
> > > > the crtc/pipe intended to disable.
> > > > In TGL, intel_dp_mst_atomic_master_trans_check will add all other CRTC
> > > > and connectors that share the MST stream to drm_atomic_state:
> > > > 
> > > > drm_atomic_commit
> > > > Ã‚Â Ã‚Â Ã‚Â drm_atomic_helper_check_modeset
> > > > Ã‚Â Ã‚Â Ã‚Â Ã‚Â Ã‚Â Ã‚Â Ã‚Â update_connector_routing
> > > > Ã‚Â Ã‚Â Ã‚Â Ã‚Â Ã‚Â Ã‚Â Ã‚Â intel_dp_mst_atomic_check = funcs-
> > > > >atomic_check(connector, state);
> > > > Ã‚Â Ã‚Â Ã‚Â Ã‚Â Ã‚Â Ã‚Â Ã‚Âintel_dp_mst_atomic_master_trans_chec
> > > > k
> > > > intel_atomic_get_digital_connector_state
> > > > drm_atomic_get_connector_state   <-- Add all
> > > > Connectors
> > > > drm_atomic_get_crtc_state <-- Add all CRTCs
> > > > Ã‚Â Ã‚Â Ã‚Â Ã‚Â Ã‚Â Ã‚Â Ã‚Â update_connector_routing <-- Check added
> > > > Connector/CRTCs - Will fail
> > > > 
> > > > However the added crtc/connector pair will be in invalid state (enabled
> > > > state for a removed connector)
> > > > triggering this condition in
> > > > drm_atomic_helper.c/update_connector_routing:
> > > > 
> > > > if (!state->duplicated &&
> > > > drm_connector_is_unregistered(connector) &&
> > > > crtc_state->active) {
> > > > DRM_DEBUG_ATOMIC("[CONNECTOR:%d:%s] is not
> > > > registered\n",
> > > >  connector->base.id, connector->name);
> > > > return -EINVAL;
> > > > }
> > > 
> > > Yeah, I think that "reject modeset on unregistered connectors" idea is
> > > a bit broken given how the uapi has worked in the past. Cc:ing danvet
> > > and lyude who IIRC were involved with that.
> > > 
> > > Hmm. Maybe we could add the other stuff to the state only after the
> > > connector .atomic_check() stuff has been done? I don't quite remember
> > > why we decided to do it here. JosÃƒÂ© do you recall the details?
> > 
> > Because the connector check function runs twice in
> > drm_atomic_helper_check_modeset(), in the first iteration it will add all
> > connectors that share the
> > same MST stream to state, the second one will make sure all other checks
> > passed in all connectors of the MST stream.
> > 
> > To me looks like the Chrome userspace is not doing the right thing, it is
> > sending asynchronous atomic commits with conflicting state between each
> > commit.
> > If it had a pool that dispatch one atomic state at time waiting for
> > completion before dispatch the next one it would not be a issue.
> 
> Yeah, with atomic userspace could avoid this potentially. Though it
> may be racy depending on whether it has noticed all the MST connectors
> disappearing yet or not. Either way it's still an issue for legacy
> uapi.

Sigh-I had hoped that we would have hooked this up such that we'd avoid this (as
I've already had to fix some issues this caused with legacy modesetting) but I
guess not. Have you guys considered trying to use the connector epochs whenever
you receive a hotplug event to differentiate between removed ('stale')
connectors and other connectors? tbh, if you can't find a connector with the
same mst path and epoch you last had as your stale connector then it's safe to
just assume it's gone.

Also - I'm totally open to better ideas for handling this or making it more
obvious when a connector has been removed, most of the reason for adding these
checks was to try our best (as this is impossible to fully guarantee) to avoid
situations where a host tried to enable an MST display that no longer existed
and put the hardware into a weird state. At least if I remember correctly, it's
been a while.

> 
-- 
Sincerely,
  Lyude Paul (she/her)
  Software Engineer at Red Hat

Note: I deal with a lot of emails and have a lot of bugs on my plate. If you've
asked me a question, are waiting for a review/merge on a patch, etc. and I
haven't responded in a while, please feel free to send me another email to check
on my status. I don't bite!

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH v3 1/3] drm/i915: Reorder hpd init vs. display resume

2020-10-19 Thread Lyude Paul

Reviewed-by: Lyude Paul 

On Tue, 2020-10-13 at 21:11 +0300, Ville Syrjala wrote:
> From: Ville Syrjälä 
> 
> Currently we call .hpd_irq_setup() directly just before display
> resume, and follow it with another call via intel_hpd_init()
> just afterwards. Assuming the hpd pins are marked as enabled
> during the open-coded call these two things do exactly the
> same thing (ie. enable HPD interrupts). Which even makes sense
> since we definitely need working HPD interrupts for MST sideband
> during the display resume.
> 
> So let's nuke the open-coded call and move the intel_hpd_init()
> call earlier. However we need to leave the poll_init_work stuff
> behind after the display resume as that will trigger display
> detection while we're resuming. We don't want that trampling over
> the display resume process. To make this a bit more symmetric
> we turn this into a intel_hpd_poll_{enable,disable}() pair.
> So we end up with the following transformation:
> intel_hpd_poll_init() -> intel_hpd_poll_enable()
> lone intel_hpd_init() -> intel_hpd_init()+intel_hpd_poll_disable()
> .hpd_irq_setup()+resume+intel_hpd_init() ->
> intel_hpd_init()+resume+intel_hpd_poll_disable()
> 
> If we really would like to prevent all *long* HPD processing during
> display resume we'd need some kind of software mechanism to simply
> ignore all long HPDs. Currently we appear to have that just for
> fbdev via ifbdev->hpd_suspended. Since we aren't exploding left and
> right all the time I guess that's mostly sufficient.
> 
> For a bit of history on this, we first got a mechanism to block
> hotplug processing during suspend in commit 15239099d7a7 ("drm/i915:
> enable irqs earlier when resuming") on account of moving the irq enable
> earlier. This then got removed in commit 50c3dc970a09 ("drm/fb-helper:
> Fix hpd vs. initial config races") because the fdev initial config
> got pushed to a later point. The second ad-hoc hpd_irq_setup() for
> resume was added in commit 0e32b39ceed6 ("drm/i915: add DP 1.2 MST
> support (v0.7)") to be able to do MST sideband during the resume.
> And finally we got a partial resurrection of the hpd blocking
> mechanism in commit e8a8fedd57fd ("drm/i915: Block fbdev HPD
> processing during suspend"), but this time it only prevent fbdev
> from handling hpd while resuming.
> 
> v2: Leave the poll_init_work behind
> v3: Remove the extra intel_hpd_poll_disable() from display reset (Lyude)
> Add the missing intel_hpd_poll_disable() to display init (Imre)
> 
> Cc: Lyude Paul 
> Cc: Imre Deak 
> Signed-off-by: Ville Syrjälä 
> ---
>  drivers/gpu/drm/i915/display/intel_display.c  |  9 ++--
>  .../drm/i915/display/intel_display_power.c|  3 +-
>  drivers/gpu/drm/i915/display/intel_hotplug.c  | 42 ++-
>  drivers/gpu/drm/i915/display/intel_hotplug.h  |  3 +-
>  drivers/gpu/drm/i915/i915_drv.c   | 23 --
>  5 files changed, 46 insertions(+), 34 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/display/intel_display.c
> b/drivers/gpu/drm/i915/display/intel_display.c
> index 907e1d155443..3be0d531f96c 100644
> --- a/drivers/gpu/drm/i915/display/intel_display.c
> +++ b/drivers/gpu/drm/i915/display/intel_display.c
> @@ -5036,18 +5036,14 @@ void intel_finish_reset(struct drm_i915_private
> *dev_priv)
>   intel_pps_unlock_regs_wa(dev_priv);
>   intel_modeset_init_hw(dev_priv);
>   intel_init_clock_gating(dev_priv);
> -
> - spin_lock_irq(_priv->irq_lock);
> - if (dev_priv->display.hpd_irq_setup)
> - dev_priv->display.hpd_irq_setup(dev_priv);
> - spin_unlock_irq(_priv->irq_lock);
> + intel_hpd_init(dev_priv);
>  
>   ret = __intel_display_resume(dev, state, ctx);
>   if (ret)
>   drm_err(_priv->drm,
>   "Restoring old state failed with %i\n", ret);
>  
> - intel_hpd_init(dev_priv);
> + intel_hpd_poll_disable(dev_priv);
>   }
>  
>   drm_atomic_state_put(state);
> @@ -18257,6 +18253,7 @@ int intel_modeset_init(struct drm_i915_private
> *i915)
>  
>   /* Only enable hotplug handling once the fbdev is fully set up. */
>   intel_hpd_init(i915);
> + intel_hpd_poll_disable(i915);
>  
>   intel_init_ipc(i915);
>  
> diff --git a/drivers/gpu/drm/i915/display/intel_display_power.c
> b/drivers/gpu/drm/i915/display/intel_display_power.c
> index 7277e58b01f1..20ddc54298cb 100644
> --- a/drivers/gpu/drm/i915/display/intel_display_power.c
> +++ b/drivers/gpu/drm/i915/display/intel_display_power.c
> @@ -1424,6

Re: [Intel-gfx] [PATCH 1/2] drm/i915/dpcd_bl: uncheck PWM_PIN_CAP when detect eDP backlight capabilities

2020-10-12 Thread Lyude Paul

Completely zoned out on Ccing these patches to stable before submitting them,
but once they hit the mainline kernel you should be able to ask Greg to backport
them if you need. Anyway, pushed to drm-intel-next-queued. Thanks for the
patches!

On Fri, 2020-10-09 at 16:57 +0800, Aaron Ma wrote:
> BOE panel with ID 2270 claims both PWM_PIN_CAP and AUX_SET_CAP backlight
> control bits, but default chip backlight failed to control brightness.
> 
> Check AUX_SET_CAP and proceed to check quirks or VBT backlight type.
> DPCD can control the brightness of this pannel.
> 
> Signed-off-by: Aaron Ma 
> ---
>  drivers/gpu/drm/i915/display/intel_dp_aux_backlight.c | 3 +--
>  1 file changed, 1 insertion(+), 2 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/display/intel_dp_aux_backlight.c
> b/drivers/gpu/drm/i915/display/intel_dp_aux_backlight.c
> index acbd7eb66cbe..308b14159b7c 100644
> --- a/drivers/gpu/drm/i915/display/intel_dp_aux_backlight.c
> +++ b/drivers/gpu/drm/i915/display/intel_dp_aux_backlight.c
> @@ -334,8 +334,7 @@ intel_dp_aux_display_control_capable(struct
> intel_connector *connector)
>* the panel can support backlight control over the aux channel
>*/
>   if (intel_dp->edp_dpcd[1] & DP_EDP_TCON_BACKLIGHT_ADJUSTMENT_CAP &&
> - (intel_dp->edp_dpcd[2] & DP_EDP_BACKLIGHT_BRIGHTNESS_AUX_SET_CAP) &&
> - !(intel_dp->edp_dpcd[2] & DP_EDP_BACKLIGHT_BRIGHTNESS_PWM_PIN_CAP))
> {
> + (intel_dp->edp_dpcd[2] & DP_EDP_BACKLIGHT_BRIGHTNESS_AUX_SET_CAP)) {
>   drm_dbg_kms(>drm, "AUX Backlight Control Supported!\n");
>   return true;
>   }
-- 
Sincerely,
  Lyude Paul (she/her)
  Software Engineer at Red Hat

Note: I deal with a lot of emails and have a lot of bugs on my plate. If you've
asked me a question, are waiting for a review/merge on a patch, etc. and I
haven't responded in a while, please feel free to send me another email to check
on my status. I don't bite!

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH] drm/i915/dp: Tweak initial dpcd backlight.enabled value

2020-10-12 Thread Lyude Paul

On Mon, 2020-10-12 at 22:02 +, Vivi, Rodrigo wrote:
> > On Oct 12, 2020, at 2:47 PM, Lyude Paul  wrote:
> > 
> > Just pushed this, but it's not in drm-tip because it would seem that
> > rebuilding
> > drm-tip has failed, and the conflict doesn't appear to be from any of the
> > patches I pushed so I'm getting the feeling from the DRM maintainer docs I
> > should probably let one of the drm-misc-folks handle the conflict.
> 
> conflicts solved. feel free to push now.

Thank you!
> 
> For the drm-misc I simply went with the drm-misc-next solution and for the
> drm-intel
> I went with the drm-intel-next-queued one.
> 
> > On Mon, 2020-10-12 at 13:50 -0400, Sean Paul wrote:
> > > On Tue, Sep 22, 2020 at 11:36 AM Lyude Paul  wrote:
> > > > On Tue, 2020-09-22 at 09:39 -0400, Sean Paul wrote:
> > > > > On Mon, Sep 21, 2020 at 6:35 PM Lyude Paul  wrote:
> > > > > > So if I understand this correctly, it sounds like that some
> > > > > > Pixelbooks
> > > > > > boot up
> > > > > > with DP_EDP_BACKLIGHT_BRIGHTNESS_MSB set to a non-zero value,
> > > > > > without
> > > > > > the
> > > > > > panel actually having DPCD backlight controls enabled?
> > > > > 
> > > > > It boots with DP_EDP_BACKLIGHT_BRIGHTNESS_MSB == 0, which used to set
> > > > > backlight.enabled = false. By changing backlight.level = max,
> > > > > backlight.enabled is now set to true. This results in losing backlight
> > > > > control on boot (since the enable routine is no longer invoked).
> > > > > 
> > > > Ahhh ok, I'm fine with that - review still stands :)
> > > 
> > > Pinging intel maintainers, could someone please apply this?
> > > 
> > > 
> > > Sean
> > > 
> > > > > Sean
> > > > > 
> > > > > > If I'm understanding that correctly, then this patch looks good to
> > > > > > me:
> > > > > > 
> > > > > > Reviewed-by: Lyude Paul 
> > > > > > 
> > > > > > On Thu, 2020-09-17 at 20:28 -0400, Sean Paul wrote:
> > > > > > > From: Sean Paul 
> > > > > > > 
> > > > > > > In commit 79946723092b ("drm/i915: Assume 100% brightness when not
> > > > > > > in
> > > > > > > DPCD control mode"), we fixed the brightness level when DPCD
> > > > > > > control
> > > > > > > was
> > > > > > > not active to max brightness. This is as good as we can guess
> > > > > > > since
> > > > > > > most
> > > > > > > backlights go on full when uncontrolled.
> > > > > > > 
> > > > > > > However in doing so we changed the semantics of the initial
> > > > > > > 'backlight.enabled' value. At least on Pixelbooks, they  were
> > > > > > > relying
> > > > > > > on the brightness level in DP_EDP_BACKLIGHT_BRIGHTNESS_MSB to be 0
> > > > > > > on
> > > > > > > boot such that enabled would be false. This causes the device to
> > > > > > > be
> > > > > > > enabled when the brightness is set. Without this, brightness
> > > > > > > control
> > > > > > > doesn't work. So by changing brightness to max, we also flipped
> > > > > > > enabled
> > > > > > > to be true on boot.
> > > > > > > 
> > > > > > > To fix this, make enabled a function of brightness and backlight
> > > > > > > control
> > > > > > > mechanism.
> > > > > > > 
> > > > > > > Fixes: 79946723092b ("drm/i915: Assume 100% brightness when not in
> > > > > > > DPCD
> > > > > > > control mode")
> > > > > > > Cc: Lyude Paul 
> > > > > > > Cc: Jani Nikula 
> > > > > > > Cc: Juha-Pekka Heikkila 
> > > > > > > Cc: "Ville Syrjälä" 
> > > > > > > Cc: Rodrigo Vivi 
> > > > > > > Cc: Kevin Chowski >
> > > > > > > Signed-off-by: Sean Paul 
> > > > > > > ---
> > > > > > > .../drm/i915/display/intel_dp_aux_backlight.c | 31 ---
&

Re: [Intel-gfx] [PATCH] drm/i915/dp: Tweak initial dpcd backlight.enabled value

2020-10-12 Thread Lyude Paul

Just pushed this, but it's not in drm-tip because it would seem that rebuilding
drm-tip has failed, and the conflict doesn't appear to be from any of the
patches I pushed so I'm getting the feeling from the DRM maintainer docs I
should probably let one of the drm-misc-folks handle the conflict.

On Mon, 2020-10-12 at 13:50 -0400, Sean Paul wrote:
> On Tue, Sep 22, 2020 at 11:36 AM Lyude Paul  wrote:
> > On Tue, 2020-09-22 at 09:39 -0400, Sean Paul wrote:
> > > On Mon, Sep 21, 2020 at 6:35 PM Lyude Paul  wrote:
> > > > So if I understand this correctly, it sounds like that some Pixelbooks
> > > > boot up
> > > > with DP_EDP_BACKLIGHT_BRIGHTNESS_MSB set to a non-zero value, without
> > > > the
> > > > panel actually having DPCD backlight controls enabled?
> > > 
> > > It boots with DP_EDP_BACKLIGHT_BRIGHTNESS_MSB == 0, which used to set
> > > backlight.enabled = false. By changing backlight.level = max,
> > > backlight.enabled is now set to true. This results in losing backlight
> > > control on boot (since the enable routine is no longer invoked).
> > > 
> > Ahhh ok, I'm fine with that - review still stands :)
> 
> Pinging intel maintainers, could someone please apply this?
> 
> 
> Sean
> 
> > > Sean
> > > 
> > > > If I'm understanding that correctly, then this patch looks good to me:
> > > > 
> > > > Reviewed-by: Lyude Paul 
> > > > 
> > > > On Thu, 2020-09-17 at 20:28 -0400, Sean Paul wrote:
> > > > > From: Sean Paul 
> > > > > 
> > > > > In commit 79946723092b ("drm/i915: Assume 100% brightness when not in
> > > > > DPCD control mode"), we fixed the brightness level when DPCD control
> > > > > was
> > > > > not active to max brightness. This is as good as we can guess since
> > > > > most
> > > > > backlights go on full when uncontrolled.
> > > > > 
> > > > > However in doing so we changed the semantics of the initial
> > > > > 'backlight.enabled' value. At least on Pixelbooks, they  were relying
> > > > > on the brightness level in DP_EDP_BACKLIGHT_BRIGHTNESS_MSB to be 0 on
> > > > > boot such that enabled would be false. This causes the device to be
> > > > > enabled when the brightness is set. Without this, brightness control
> > > > > doesn't work. So by changing brightness to max, we also flipped
> > > > > enabled
> > > > > to be true on boot.
> > > > > 
> > > > > To fix this, make enabled a function of brightness and backlight
> > > > > control
> > > > > mechanism.
> > > > > 
> > > > > Fixes: 79946723092b ("drm/i915: Assume 100% brightness when not in
> > > > > DPCD
> > > > > control mode")
> > > > > Cc: Lyude Paul 
> > > > > Cc: Jani Nikula 
> > > > > Cc: Juha-Pekka Heikkila 
> > > > > Cc: "Ville Syrjälä" 
> > > > > Cc: Rodrigo Vivi 
> > > > > Cc: Kevin Chowski >
> > > > > Signed-off-by: Sean Paul 
> > > > > ---
> > > > >  .../drm/i915/display/intel_dp_aux_backlight.c | 31 
> > > > > ---
> > > > >  1 file changed, 20 insertions(+), 11 deletions(-)
> > > > > 
> > > > > diff --git a/drivers/gpu/drm/i915/display/intel_dp_aux_backlight.c
> > > > > b/drivers/gpu/drm/i915/display/intel_dp_aux_backlight.c
> > > > > index acbd7eb66cbe..036f504ac7db 100644
> > > > > --- a/drivers/gpu/drm/i915/display/intel_dp_aux_backlight.c
> > > > > +++ b/drivers/gpu/drm/i915/display/intel_dp_aux_backlight.c
> > > > > @@ -52,17 +52,11 @@ static void set_aux_backlight_enable(struct
> > > > > intel_dp
> > > > > *intel_dp, bool enable)
> > > > >   }
> > > > >  }
> > > > > 
> > > > > -/*
> > > > > - * Read the current backlight value from DPCD register(s) based
> > > > > - * on if 8-bit(MSB) or 16-bit(MSB and LSB) values are supported
> > > > > - */
> > > > > -static u32 intel_dp_aux_get_backlight(struct intel_connector
> > > > > *connector)
> > > > > +static bool intel_dp_aux_backlight_dpcd_mode(struct intel_connector
> > > > > *connector)
> > > > >  {
> > > > >   struct intel_dp *in

Re: [Intel-gfx] [PATCH] drm/i915/dp: Tweak initial dpcd backlight.enabled value

2020-10-12 Thread Lyude Paul

On Mon, 2020-10-12 at 13:50 -0400, Sean Paul wrote:
> On Tue, Sep 22, 2020 at 11:36 AM Lyude Paul  wrote:
> > On Tue, 2020-09-22 at 09:39 -0400, Sean Paul wrote:
> > > On Mon, Sep 21, 2020 at 6:35 PM Lyude Paul  wrote:
> > > > So if I understand this correctly, it sounds like that some Pixelbooks
> > > > boot up
> > > > with DP_EDP_BACKLIGHT_BRIGHTNESS_MSB set to a non-zero value, without
> > > > the
> > > > panel actually having DPCD backlight controls enabled?
> > > 
> > > It boots with DP_EDP_BACKLIGHT_BRIGHTNESS_MSB == 0, which used to set
> > > backlight.enabled = false. By changing backlight.level = max,
> > > backlight.enabled is now set to true. This results in losing backlight
> > > control on boot (since the enable routine is no longer invoked).
> > > 
> > Ahhh ok, I'm fine with that - review still stands :)
> 
> Pinging intel maintainers, could someone please apply this?

oops, sorry about that. I can go ahead and push this
> 
> 
> Sean
> 
> > > Sean
> > > 
> > > > If I'm understanding that correctly, then this patch looks good to me:
> > > > 
> > > > Reviewed-by: Lyude Paul 
> > > > 
> > > > On Thu, 2020-09-17 at 20:28 -0400, Sean Paul wrote:
> > > > > From: Sean Paul 
> > > > > 
> > > > > In commit 79946723092b ("drm/i915: Assume 100% brightness when not in
> > > > > DPCD control mode"), we fixed the brightness level when DPCD control
> > > > > was
> > > > > not active to max brightness. This is as good as we can guess since
> > > > > most
> > > > > backlights go on full when uncontrolled.
> > > > > 
> > > > > However in doing so we changed the semantics of the initial
> > > > > 'backlight.enabled' value. At least on Pixelbooks, they  were relying
> > > > > on the brightness level in DP_EDP_BACKLIGHT_BRIGHTNESS_MSB to be 0 on
> > > > > boot such that enabled would be false. This causes the device to be
> > > > > enabled when the brightness is set. Without this, brightness control
> > > > > doesn't work. So by changing brightness to max, we also flipped
> > > > > enabled
> > > > > to be true on boot.
> > > > > 
> > > > > To fix this, make enabled a function of brightness and backlight
> > > > > control
> > > > > mechanism.
> > > > > 
> > > > > Fixes: 79946723092b ("drm/i915: Assume 100% brightness when not in
> > > > > DPCD
> > > > > control mode")
> > > > > Cc: Lyude Paul 
> > > > > Cc: Jani Nikula 
> > > > > Cc: Juha-Pekka Heikkila 
> > > > > Cc: "Ville Syrjälä" 
> > > > > Cc: Rodrigo Vivi 
> > > > > Cc: Kevin Chowski >
> > > > > Signed-off-by: Sean Paul 
> > > > > ---
> > > > >  .../drm/i915/display/intel_dp_aux_backlight.c | 31 
> > > > > ---
> > > > >  1 file changed, 20 insertions(+), 11 deletions(-)
> > > > > 
> > > > > diff --git a/drivers/gpu/drm/i915/display/intel_dp_aux_backlight.c
> > > > > b/drivers/gpu/drm/i915/display/intel_dp_aux_backlight.c
> > > > > index acbd7eb66cbe..036f504ac7db 100644
> > > > > --- a/drivers/gpu/drm/i915/display/intel_dp_aux_backlight.c
> > > > > +++ b/drivers/gpu/drm/i915/display/intel_dp_aux_backlight.c
> > > > > @@ -52,17 +52,11 @@ static void set_aux_backlight_enable(struct
> > > > > intel_dp
> > > > > *intel_dp, bool enable)
> > > > >   }
> > > > >  }
> > > > > 
> > > > > -/*
> > > > > - * Read the current backlight value from DPCD register(s) based
> > > > > - * on if 8-bit(MSB) or 16-bit(MSB and LSB) values are supported
> > > > > - */
> > > > > -static u32 intel_dp_aux_get_backlight(struct intel_connector
> > > > > *connector)
> > > > > +static bool intel_dp_aux_backlight_dpcd_mode(struct intel_connector
> > > > > *connector)
> > > > >  {
> > > > >   struct intel_dp *intel_dp = intel_attached_dp(connector);
> > > > >   struct drm_i915_private *i915 = dp_to_i915(intel_dp);
> > > > > - u8 read_val[2] = { 0x0 };
> > > > >   u8 mode_reg;
> > > &

[Intel-gfx] (Cc: drm-misc/intel maintainers) Re: [PATCH 1/2] drm/i915/dpcd_bl: uncheck PWM_PIN_CAP when detect eDP backlight capabilities

2020-10-09 Thread Lyude Paul

For the whole series:

For the whole series:

Reviewed-by: Lyude Paul 

I'm going to add a Cc for stable so that it can be backported, and I'll push it
to drm-intel-next-queued once I get the OK from drm-misc/i915 folks

On Fri, 2020-10-09 at 16:57 +0800, Aaron Ma wrote:
> BOE panel with ID 2270 claims both PWM_PIN_CAP and AUX_SET_CAP backlight
> control bits, but default chip backlight failed to control brightness.
> 
> Check AUX_SET_CAP and proceed to check quirks or VBT backlight type.
> DPCD can control the brightness of this pannel.
> 
> Signed-off-by: Aaron Ma 
> ---
>  drivers/gpu/drm/i915/display/intel_dp_aux_backlight.c | 3 +--
>  1 file changed, 1 insertion(+), 2 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/display/intel_dp_aux_backlight.c
> b/drivers/gpu/drm/i915/display/intel_dp_aux_backlight.c
> index acbd7eb66cbe..308b14159b7c 100644
> --- a/drivers/gpu/drm/i915/display/intel_dp_aux_backlight.c
> +++ b/drivers/gpu/drm/i915/display/intel_dp_aux_backlight.c
> @@ -334,8 +334,7 @@ intel_dp_aux_display_control_capable(struct
> intel_connector *connector)
>* the panel can support backlight control over the aux channel
>*/
>   if (intel_dp->edp_dpcd[1] & DP_EDP_TCON_BACKLIGHT_ADJUSTMENT_CAP &&
> - (intel_dp->edp_dpcd[2] & DP_EDP_BACKLIGHT_BRIGHTNESS_AUX_SET_CAP) &&
> - !(intel_dp->edp_dpcd[2] & DP_EDP_BACKLIGHT_BRIGHTNESS_PWM_PIN_CAP))
> {
> + (intel_dp->edp_dpcd[2] & DP_EDP_BACKLIGHT_BRIGHTNESS_AUX_SET_CAP)) {
>   drm_dbg_kms(>drm, "AUX Backlight Control Supported!\n");
>   return true;
>   }
-- 
Sincerely,
  Lyude Paul (she/her)
  Software Engineer at Red Hat

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 1/2] drm/i915/dpcd_bl: Skip testing control capability with force DPCD quirk

2020-10-08 Thread Lyude Paul

oh hold on, I misspoke. Here's the patch I was thinking of:

https://patchwork.freedesktop.org/series/82041/

On Thu, 2020-10-08 at 10:32 +0800, Kai-Heng Feng wrote:
> Hi Lyude,
> 
> > On Oct 8, 2020, at 05:53, Lyude Paul  wrote:
> > 
> > Hi! I thought this patch rang a bell, we actually already had some
> > discussion
> > about this since there's a couple of other systems this was causing issues
> > for.
> > Unfortunately it never seems like that patch got sent out. Satadru?
> > 
> > (if I don't hear back from them soon, I'll just send out a patch for this
> > myself)
> > 
> > JFYI - the proper fix here is to just drop the
> > DP_EDP_BACKLIGHT_BRIGHTNESS_PWM_PIN_CAP check from the code entirely. As
> > long as
> > the backlight supports AUX_SET_CAP, that should be enough for us to control
> > it.
> 
> Does the proper fix include dropping DP_QUIRK_FORCE_DPCD_BACKLIGHT entirely?
> 
> Kai-Heng
> 
> > 
> > On Wed, 2020-10-07 at 14:58 +0800, Kai-Heng Feng wrote:
> > > HP DreamColor panel needs to be controlled via AUX interface. However,
> > > it has both DP_EDP_BACKLIGHT_BRIGHTNESS_AUX_SET_CAP and
> > > DP_EDP_BACKLIGHT_BRIGHTNESS_PWM_PIN_CAP set, so it fails to pass
> > > intel_dp_aux_display_control_capable() test.
> > > 
> > > Skip the test if the panel has force DPCD quirk.
> > > 
> > > Signed-off-by: Kai-Heng Feng 
> > > ---
> > > drivers/gpu/drm/i915/display/intel_dp_aux_backlight.c | 10 ++
> > > 1 file changed, 6 insertions(+), 4 deletions(-)
> > > 
> > > diff --git a/drivers/gpu/drm/i915/display/intel_dp_aux_backlight.c
> > > b/drivers/gpu/drm/i915/display/intel_dp_aux_backlight.c
> > > index acbd7eb66cbe..acf2e1c65290 100644
> > > --- a/drivers/gpu/drm/i915/display/intel_dp_aux_backlight.c
> > > +++ b/drivers/gpu/drm/i915/display/intel_dp_aux_backlight.c
> > > @@ -347,9 +347,13 @@ int intel_dp_aux_init_backlight_funcs(struct
> > > intel_connector *intel_connector)
> > >   struct intel_panel *panel = _connector->panel;
> > >   struct intel_dp *intel_dp = enc_to_intel_dp(intel_connector->encoder);
> > >   struct drm_i915_private *i915 = dp_to_i915(intel_dp);
> > > + bool force_dpcd;
> > > +
> > > + force_dpcd = drm_dp_has_quirk(_dp->desc, intel_dp->edid_quirks,
> > > +   DP_QUIRK_FORCE_DPCD_BACKLIGHT);
> > > 
> > >   if (i915->params.enable_dpcd_backlight == 0 ||
> > > - !intel_dp_aux_display_control_capable(intel_connector))
> > > + (!force_dpcd &&
> > > !intel_dp_aux_display_control_capable(intel_connector)))
> > >   return -ENODEV;
> > > 
> > >   /*
> > > @@ -358,9 +362,7 @@ int intel_dp_aux_init_backlight_funcs(struct
> > > intel_connector *intel_connector)
> > >*/
> > >   if (i915->vbt.backlight.type !=
> > >   INTEL_BACKLIGHT_VESA_EDP_AUX_INTERFACE &&
> > > - i915->params.enable_dpcd_backlight != 1 &&
> > > - !drm_dp_has_quirk(_dp->desc, intel_dp->edid_quirks,
> > > -   DP_QUIRK_FORCE_DPCD_BACKLIGHT)) {
> > > + i915->params.enable_dpcd_backlight != 1 && !force_dpcd) {
> > >   drm_info(>drm,
> > >"Panel advertises DPCD backlight support, but "
> > >"VBT disagrees. If your backlight controls "
> > -- 
> > Sincerely,
> >  Lyude Paul (she/her)
> >  Software Engineer at Red Hat
-- 
Sincerely,
  Lyude Paul (she/her)
  Software Engineer at Red Hat

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH v3 4/6] drm/dp: Add LTTPR helpers

2020-10-08 Thread Lyude Paul

Acked-by: Lyude Paul 


On Thu, 2020-10-08 at 19:46 +0300, Imre Deak wrote:
> Hi Dave et all,
> 
> On Wed, Oct 07, 2020 at 08:09:15PM +0300, Imre Deak wrote:
> > Add the helpers and register definitions needed to read out the common
> > and per-PHY LTTPR capabilities and perform link training in the LTTPR
> > non-transparent mode.
> > 
> > v2:
> > - Add drm_dp_dpcd_read_phy_link_status() and DP_PHY_LTTPR() here instead
> >   of adding these to i915. (Ville)
> > v3:
> > - Use memmove() to convert LTTPR to DPRX link status format. (Ville)
> > 
> > Cc: dri-de...@lists.freedesktop.org
> > Cc: Ville SyrjÃƒÂ¤lÃƒÂ¤ 
> > Reviewed-by: Ville SyrjÃƒÂ¤lÃƒÂ¤ 
> > Signed-off-by: Imre Deak 
> 
> Is it ok to merge this patch via drm-intel-next-queued? If so could
> someone Ack it?
> 
> Thanks,
> Imre
> 
> > ---
> >  drivers/gpu/drm/drm_dp_helper.c | 232 +++-
> >  include/drm/drm_dp_helper.h |  62 +
> >  2 files changed, 290 insertions(+), 4 deletions(-)
> > 
> > diff --git a/drivers/gpu/drm/drm_dp_helper.c
> > b/drivers/gpu/drm/drm_dp_helper.c
> > index 478dd51f738d..79732402336d 100644
> > --- a/drivers/gpu/drm/drm_dp_helper.c
> > +++ b/drivers/gpu/drm/drm_dp_helper.c
> > @@ -150,11 +150,8 @@ void drm_dp_link_train_clock_recovery_delay(const u8
> > dpcd[DP_RECEIVER_CAP_SIZE])
> >  }
> >  EXPORT_SYMBOL(drm_dp_link_train_clock_recovery_delay);
> >  
> > -void drm_dp_link_train_channel_eq_delay(const u8
> > dpcd[DP_RECEIVER_CAP_SIZE])
> > +static void __drm_dp_link_train_channel_eq_delay(unsigned long rd_interval)
> >  {
> > -   unsigned long rd_interval = dpcd[DP_TRAINING_AUX_RD_INTERVAL] &
> > -DP_TRAINING_AUX_RD_MASK;
> > -
> > if (rd_interval > 4)
> > DRM_DEBUG_KMS("AUX interval %lu, out of range (max 4)\n",
> >   rd_interval);
> > @@ -166,8 +163,35 @@ void drm_dp_link_train_channel_eq_delay(const u8
> > dpcd[DP_RECEIVER_CAP_SIZE])
> >  
> > usleep_range(rd_interval, rd_interval * 2);
> >  }
> > +
> > +void drm_dp_link_train_channel_eq_delay(const u8
> > dpcd[DP_RECEIVER_CAP_SIZE])
> > +{
> > +   __drm_dp_link_train_channel_eq_delay(dpcd[DP_TRAINING_AUX_RD_INTERVAL] &
> > +DP_TRAINING_AUX_RD_MASK);
> > +}
> >  EXPORT_SYMBOL(drm_dp_link_train_channel_eq_delay);
> >  
> > +void drm_dp_lttpr_link_train_clock_recovery_delay(void)
> > +{
> > +   usleep_range(100, 200);
> > +}
> > +EXPORT_SYMBOL(drm_dp_lttpr_link_train_clock_recovery_delay);
> > +
> > +static u8 dp_lttpr_phy_cap(const u8 phy_cap[DP_LTTPR_PHY_CAP_SIZE], int r)
> > +{
> > +   return phy_cap[r - DP_TRAINING_AUX_RD_INTERVAL_PHY_REPEATER1];
> > +}
> > +
> > +void drm_dp_lttpr_link_train_channel_eq_delay(const u8
> > phy_cap[DP_LTTPR_PHY_CAP_SIZE])
> > +{
> > +   u8 interval = dp_lttpr_phy_cap(phy_cap,
> > +  DP_TRAINING_AUX_RD_INTERVAL_PHY_REPEATER1
> > ) &
> > + DP_TRAINING_AUX_RD_MASK;
> > +
> > +   __drm_dp_link_train_channel_eq_delay(interval);
> > +}
> > +EXPORT_SYMBOL(drm_dp_lttpr_link_train_channel_eq_delay);
> > +
> >  u8 drm_dp_link_rate_to_bw_code(int link_rate)
> >  {
> > /* Spec says link_bw = link_rate / 0.27Gbps */
> > @@ -363,6 +387,59 @@ int drm_dp_dpcd_read_link_status(struct drm_dp_aux
> > *aux,
> >  }
> >  EXPORT_SYMBOL(drm_dp_dpcd_read_link_status);
> >  
> > +/**
> > + * drm_dp_dpcd_read_phy_link_status - get the link status information for a
> > DP PHY
> > + * @aux: DisplayPort AUX channel
> > + * @dp_phy: the DP PHY to get the link status for
> > + * @link_status: buffer to return the status in
> > + *
> > + * Fetch the AUX DPCD registers for the DPRX or an LTTPR PHY link status.
> > The
> > + * layout of the returned @link_status matches the DPCD register layout of
> > the
> > + * DPRX PHY link status.
> > + *
> > + * Returns 0 if the information was read successfully or a negative error
> > code
> > + * on failure.
> > + */
> > +int drm_dp_dpcd_read_phy_link_status(struct drm_dp_aux *aux,
> > +enum drm_dp_phy dp_phy,
> > +u8 link_status[DP_LINK_STATUS_SIZE])
> > +{
> > +   int ret;
> > +
> > +   if (dp_phy == DP_PHY_DPRX) {
> > +   ret = drm_dp_dpcd_read(aux,
>

Re: [Intel-gfx] [PATCH 1/2] drm/i915/dpcd_bl: Skip testing control capability with force DPCD quirk

2020-10-08 Thread Lyude Paul

On Thu, 2020-10-08 at 10:32 +0800, Kai-Heng Feng wrote:
> Hi Lyude,
> 
> > On Oct 8, 2020, at 05:53, Lyude Paul  wrote:
> > 
> > Hi! I thought this patch rang a bell, we actually already had some
> > discussion
> > about this since there's a couple of other systems this was causing issues
> > for.
> > Unfortunately it never seems like that patch got sent out. Satadru?
> > 
> > (if I don't hear back from them soon, I'll just send out a patch for this
> > myself)
> > 
> > JFYI - the proper fix here is to just drop the
> > DP_EDP_BACKLIGHT_BRIGHTNESS_PWM_PIN_CAP check from the code entirely. As
> > long as
> > the backlight supports AUX_SET_CAP, that should be enough for us to control
> > it.
> 
> Does the proper fix include dropping DP_QUIRK_FORCE_DPCD_BACKLIGHT entirely?\

Not yet - we need someone to help with reviewing my Intel HDR backlight
interface patches before we can drop that. I was just talking about dropping the
check where we don't enable the DPCD backlight if it claims to support
DP_EDP_BACKLIGHT_BRIGHTNESS_PWM_PIN_CAP

> 
> Kai-Heng
> 
> > 
> > On Wed, 2020-10-07 at 14:58 +0800, Kai-Heng Feng wrote:
> > > HP DreamColor panel needs to be controlled via AUX interface. However,
> > > it has both DP_EDP_BACKLIGHT_BRIGHTNESS_AUX_SET_CAP and
> > > DP_EDP_BACKLIGHT_BRIGHTNESS_PWM_PIN_CAP set, so it fails to pass
> > > intel_dp_aux_display_control_capable() test.
> > > 
> > > Skip the test if the panel has force DPCD quirk.
> > > 
> > > Signed-off-by: Kai-Heng Feng 
> > > ---
> > > drivers/gpu/drm/i915/display/intel_dp_aux_backlight.c | 10 ++
> > > 1 file changed, 6 insertions(+), 4 deletions(-)
> > > 
> > > diff --git a/drivers/gpu/drm/i915/display/intel_dp_aux_backlight.c
> > > b/drivers/gpu/drm/i915/display/intel_dp_aux_backlight.c
> > > index acbd7eb66cbe..acf2e1c65290 100644
> > > --- a/drivers/gpu/drm/i915/display/intel_dp_aux_backlight.c
> > > +++ b/drivers/gpu/drm/i915/display/intel_dp_aux_backlight.c
> > > @@ -347,9 +347,13 @@ int intel_dp_aux_init_backlight_funcs(struct
> > > intel_connector *intel_connector)
> > >   struct intel_panel *panel = _connector->panel;
> > >   struct intel_dp *intel_dp = enc_to_intel_dp(intel_connector->encoder);
> > >   struct drm_i915_private *i915 = dp_to_i915(intel_dp);
> > > + bool force_dpcd;
> > > +
> > > + force_dpcd = drm_dp_has_quirk(_dp->desc, intel_dp->edid_quirks,
> > > +   DP_QUIRK_FORCE_DPCD_BACKLIGHT);
> > > 
> > >   if (i915->params.enable_dpcd_backlight == 0 ||
> > > - !intel_dp_aux_display_control_capable(intel_connector))
> > > + (!force_dpcd &&
> > > !intel_dp_aux_display_control_capable(intel_connector)))
> > >   return -ENODEV;
> > > 
> > >   /*
> > > @@ -358,9 +362,7 @@ int intel_dp_aux_init_backlight_funcs(struct
> > > intel_connector *intel_connector)
> > >*/
> > >   if (i915->vbt.backlight.type !=
> > >   INTEL_BACKLIGHT_VESA_EDP_AUX_INTERFACE &&
> > > - i915->params.enable_dpcd_backlight != 1 &&
> > > - !drm_dp_has_quirk(_dp->desc, intel_dp->edid_quirks,
> > > -   DP_QUIRK_FORCE_DPCD_BACKLIGHT)) {
> > > + i915->params.enable_dpcd_backlight != 1 && !force_dpcd) {
> > >   drm_info(>drm,
> > >"Panel advertises DPCD backlight support, but "
> > >"VBT disagrees. If your backlight controls "
> > -- 
> > Sincerely,
> >  Lyude Paul (she/her)
> >  Software Engineer at Red Hat
-- 
Sincerely,
  Lyude Paul (she/her)
  Software Engineer at Red Hat

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH v2 1/3] drm/i915: Reorder hpd init vs. display resume

2020-10-07 Thread Lyude Paul

On Wed, 2020-10-07 at 22:22 +0300, Ville Syrjala wrote:
> From: Ville Syrjälä 
> 
> Currently we call .hpd_irq_setup() directly just before display
> resume, and follow it with another call via intel_hpd_init()
> just afterwards. Assuming the hpd pins are marked as enabled
> during the open-coded call these two things do exactly the
> same thing (ie. enable HPD interrupts). Which even makes sense
> since we definitely need working HPD interrupts for MST sideband
> during the display resume.
> 
> So let's nuke the open-coded call and move the intel_hpd_init()
> call earlier. However we need to leave the poll_init_work stuff
> behind after the display resume as that will trigger display
> detection while we're resuming. We don't want that trampling over
> the display resume process. To make this a bit more symmetric
> we turn this into a intel_hpd_poll_{enable,disable}() pair.
> So we end up with the following transformation:
> intel_hpd_poll_init() -> intel_hpd_poll_enable()
> lone intel_hpd_init() -> intel_hpd_init()+intel_hpd_poll_disable()
> .hpd_irq_setup()+resume+intel_hpd_init() ->
> intel_hpd_init()+resume+intel_hpd_poll_disable()
> 
> If we really would like to prevent all *long* HPD processing during
> display resume we'd need some kind of software mechanism to simply
> ignore all long HPDs. Currently we appear to have that just for
> fbdev via ifbdev->hpd_suspended. Since we aren't exploding left and
> right all the time I guess that's mostly sufficient.
> 
> For a bit of history on this, we first got a mechanism to block
> hotplug processing during suspend in commit 15239099d7a7 ("drm/i915:
> enable irqs earlier when resuming") on account of moving the irq enable
> earlier. This then got removed in commit 50c3dc970a09 ("drm/fb-helper:
> Fix hpd vs. initial config races") because the fdev initial config
> got pushed to a later point. The second ad-hoc hpd_irq_setup() for
> resume was added in commit 0e32b39ceed6 ("drm/i915: add DP 1.2 MST
> support (v0.7)") to be able to do MST sideband during the resume.
> And finally we got a partial resurrection of the hpd blocking
> mechanism in commit e8a8fedd57fd ("drm/i915: Block fbdev HPD
> processing during suspend"), but this time it only prevent fbdev
> from handling hpd while resuming.
> 
> v2: Leave the poll_init_work behind
> 
> Cc: Lyude Paul 
> Signed-off-by: Ville Syrjälä 
> ---
>  drivers/gpu/drm/i915/display/intel_display.c  |  9 ++--
>  .../drm/i915/display/intel_display_power.c|  3 +-
>  drivers/gpu/drm/i915/display/intel_hotplug.c  | 42 ++-
>  drivers/gpu/drm/i915/display/intel_hotplug.h  |  3 +-
>  drivers/gpu/drm/i915/i915_drv.c   | 23 --
>  5 files changed, 46 insertions(+), 34 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/display/intel_display.c
> b/drivers/gpu/drm/i915/display/intel_display.c
> index 907e1d155443..0d5607ae97c4 100644
> --- a/drivers/gpu/drm/i915/display/intel_display.c
> +++ b/drivers/gpu/drm/i915/display/intel_display.c
> @@ -5036,18 +5036,15 @@ void intel_finish_reset(struct drm_i915_private
> *dev_priv)
>   intel_pps_unlock_regs_wa(dev_priv);
>   intel_modeset_init_hw(dev_priv);
>   intel_init_clock_gating(dev_priv);
> -
> - spin_lock_irq(_priv->irq_lock);
> - if (dev_priv->display.hpd_irq_setup)
> - dev_priv->display.hpd_irq_setup(dev_priv);
> - spin_unlock_irq(_priv->irq_lock);
> + intel_hpd_init(dev_priv);
> + intel_hpd_poll_disable(dev_priv);
>  
>   ret = __intel_display_resume(dev, state, ctx);
>   if (ret)
>   drm_err(_priv->drm,
>   "Restoring old state failed with %i\n", ret);
>  
> - intel_hpd_init(dev_priv);
> + intel_hpd_poll_disable(dev_priv);

Looks like you're calling intel_hpd_poll_disable() twice here, is this
intentional?

>   }
>  
>   drm_atomic_state_put(state);
> diff --git a/drivers/gpu/drm/i915/display/intel_display_power.c
> b/drivers/gpu/drm/i915/display/intel_display_power.c
> index 7277e58b01f1..20ddc54298cb 100644
> --- a/drivers/gpu/drm/i915/display/intel_display_power.c
> +++ b/drivers/gpu/drm/i915/display/intel_display_power.c
> @@ -1424,6 +1424,7 @@ static void vlv_display_power_well_init(struct
> drm_i915_private *dev_priv)
>   return;
>  
>   intel_hpd_init(dev_priv);
> + intel_hpd_poll_disable(dev_priv);
>  
>   /* Re-enable the ADPA, if we have one */
>   for_each_intel_encoder(_priv->drm, encoder) {
> @@ -1449,7 +1450,7 @@ s

Re: [Intel-gfx] [PATCH 1/2] drm/i915/dpcd_bl: Skip testing control capability with force DPCD quirk

2020-10-07 Thread Lyude Paul

Hi! I thought this patch rang a bell, we actually already had some discussion
about this since there's a couple of other systems this was causing issues for.
Unfortunately it never seems like that patch got sent out. Satadru?

(if I don't hear back from them soon, I'll just send out a patch for this
myself)

JFYI - the proper fix here is to just drop the
DP_EDP_BACKLIGHT_BRIGHTNESS_PWM_PIN_CAP check from the code entirely. As long as
the backlight supports AUX_SET_CAP, that should be enough for us to control it.


On Wed, 2020-10-07 at 14:58 +0800, Kai-Heng Feng wrote:
> HP DreamColor panel needs to be controlled via AUX interface. However,
> it has both DP_EDP_BACKLIGHT_BRIGHTNESS_AUX_SET_CAP and
> DP_EDP_BACKLIGHT_BRIGHTNESS_PWM_PIN_CAP set, so it fails to pass
> intel_dp_aux_display_control_capable() test.
> 
> Skip the test if the panel has force DPCD quirk.
> 
> Signed-off-by: Kai-Heng Feng 
> ---
>  drivers/gpu/drm/i915/display/intel_dp_aux_backlight.c | 10 ++
>  1 file changed, 6 insertions(+), 4 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/display/intel_dp_aux_backlight.c
> b/drivers/gpu/drm/i915/display/intel_dp_aux_backlight.c
> index acbd7eb66cbe..acf2e1c65290 100644
> --- a/drivers/gpu/drm/i915/display/intel_dp_aux_backlight.c
> +++ b/drivers/gpu/drm/i915/display/intel_dp_aux_backlight.c
> @@ -347,9 +347,13 @@ int intel_dp_aux_init_backlight_funcs(struct
> intel_connector *intel_connector)
>   struct intel_panel *panel = _connector->panel;
>   struct intel_dp *intel_dp = enc_to_intel_dp(intel_connector->encoder);
>   struct drm_i915_private *i915 = dp_to_i915(intel_dp);
> + bool force_dpcd;
> +
> + force_dpcd = drm_dp_has_quirk(_dp->desc, intel_dp->edid_quirks,
> +   DP_QUIRK_FORCE_DPCD_BACKLIGHT);
>  
>   if (i915->params.enable_dpcd_backlight == 0 ||
> - !intel_dp_aux_display_control_capable(intel_connector))
> + (!force_dpcd &&
> !intel_dp_aux_display_control_capable(intel_connector)))
>   return -ENODEV;
>  
>   /*
> @@ -358,9 +362,7 @@ int intel_dp_aux_init_backlight_funcs(struct
> intel_connector *intel_connector)
>*/
>   if (i915->vbt.backlight.type !=
>   INTEL_BACKLIGHT_VESA_EDP_AUX_INTERFACE &&
> - i915->params.enable_dpcd_backlight != 1 &&
> - !drm_dp_has_quirk(_dp->desc, intel_dp->edid_quirks,
> -   DP_QUIRK_FORCE_DPCD_BACKLIGHT)) {
> + i915->params.enable_dpcd_backlight != 1 && !force_dpcd) {
>   drm_info(>drm,
>"Panel advertises DPCD backlight support, but "
>"VBT disagrees. If your backlight controls "
-- 
Sincerely,
  Lyude Paul (she/her)
  Software Engineer at Red Hat

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

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

2020-09-30 Thread 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  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-signifi

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

2020-09-30 Thread 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  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 go

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

2020-09-25 Thread Lyude Paul

ase. 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  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 
> > &

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

2020-09-22 Thread Lyude Paul

 & 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(_dp->aux,
> > > > > > > > > > DP_EDP_PWMGEN_BIT_COUNT,
> > > > > > > > > > + [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]) & 0x;
> > > > > > > > > > + }
> > > > > > > > > > +
> > > > > > > > > >   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(>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

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [RESEND PATCH 1/2] drm/dp: fix kernel-doc warnings at drm_dp_helper.c

2020-09-22 Thread Lyude Paul

From: Mauro Carvalho Chehab 

As warned by kernel-doc:

./drivers/gpu/drm/drm_dp_helper.c:385: warning: Function parameter or 
member 'type' not described in 'drm_dp_downstream_is_type'
./drivers/gpu/drm/drm_dp_helper.c:886: warning: Function parameter or 
member 'dev' not described in 'drm_dp_downstream_mode'

Some function parameters weren't documented.

Fixes: 38784f6f8805 ("drm/dp: Add helpers to identify downstream facing port 
types")
Signed-off-by: Mauro Carvalho Chehab 
Reviewed-by: Lyude Paul 
---
 drivers/gpu/drm/drm_dp_helper.c | 5 +
 1 file changed, 5 insertions(+)

diff --git a/drivers/gpu/drm/drm_dp_helper.c b/drivers/gpu/drm/drm_dp_helper.c
index 90807a6b415c..478dd51f738d 100644
--- a/drivers/gpu/drm/drm_dp_helper.c
+++ b/drivers/gpu/drm/drm_dp_helper.c
@@ -374,6 +374,10 @@ static bool is_edid_digital_input_dp(const struct edid 
*edid)
  * drm_dp_downstream_is_type() - is the downstream facing port of certain type?
  * @dpcd: DisplayPort configuration data
  * @port_cap: port capabilities
+ * @type: port type to be checked. Can be:
+ *   %DP_DS_PORT_TYPE_DP, %DP_DS_PORT_TYPE_VGA, %DP_DS_PORT_TYPE_DVI,
+ *   %DP_DS_PORT_TYPE_HDMI, %DP_DS_PORT_TYPE_NON_EDID,
+ *   %DP_DS_PORT_TYPE_DP_DUALMODE or %DP_DS_PORT_TYPE_WIRELESS.
  *
  * Caveat: Only works with DPCD 1.1+ port caps.
  *
@@ -870,6 +874,7 @@ EXPORT_SYMBOL(drm_dp_downstream_444_to_420_conversion);
 
 /**
  * drm_dp_downstream_mode() - return a mode for downstream facing port
+ * @dev: DRM device
  * @dpcd: DisplayPort configuration data
  * @port_cap: port capabilities
  *
-- 
2.26.2

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [RESEND PATCH 0/2] drm/i915: kernel-doc fixes for new DP helpers

2020-09-22 Thread Lyude Paul

Note that none of the code that this touches is in i915, however at the
time I posted this patch all of the DP helpers that concern these
patches were added through drm-intel-next-queued, not drm-misc-next, so
it makes more sense to merge it through drm-intel-next-queued. As such,
I'm just sending this onto intel-gfx so that it gets a patch ID.

This should introduce no functional changes, and is already reviewed by
me.

Mauro Carvalho Chehab (2):
  drm/dp: fix kernel-doc warnings at drm_dp_helper.c
  drm/dp: fix a kernel-doc issue at drm_edid.c

 drivers/gpu/drm/drm_dp_helper.c | 5 +
 drivers/gpu/drm/drm_edid.c  | 2 +-
 2 files changed, 6 insertions(+), 1 deletion(-)

-- 
2.26.2

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [RESEND PATCH 2/2] drm/dp: fix a kernel-doc issue at drm_edid.c

2020-09-22 Thread Lyude Paul

From: Mauro Carvalho Chehab 

The name of the argument is different, causing those warnings:

./drivers/gpu/drm/drm_edid.c:3754: warning: Function parameter or 
member 'video_code' not described in 'drm_display_mode_from_cea_vic'
./drivers/gpu/drm/drm_edid.c:3754: warning: Excess function parameter 
'vic' description in 'drm_display_mode_from_cea_vic'

Fixes: 7af655bce275 ("drm/dp: Add drm_dp_downstream_mode()")
Signed-off-by: Mauro Carvalho Chehab 
Reviewed-by: Lyude Paul 
---
 drivers/gpu/drm/drm_edid.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
index a82f37d44258..631125b46e04 100644
--- a/drivers/gpu/drm/drm_edid.c
+++ b/drivers/gpu/drm/drm_edid.c
@@ -3741,7 +3741,7 @@ drm_add_cmdb_modes(struct drm_connector *connector, u8 
svd)
 /**
  * drm_display_mode_from_cea_vic() - return a mode for CEA VIC
  * @dev: DRM device
- * @vic: CEA VIC of the mode
+ * @video_code: CEA VIC of the mode
  *
  * Creates a new mode matching the specified CEA VIC.
  *
-- 
2.26.2

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH] drm/i915/dp: Tweak initial dpcd backlight.enabled value

2020-09-22 Thread Lyude Paul

On Tue, 2020-09-22 at 09:39 -0400, Sean Paul wrote:
> On Mon, Sep 21, 2020 at 6:35 PM Lyude Paul  wrote:
> > So if I understand this correctly, it sounds like that some Pixelbooks
> > boot up
> > with DP_EDP_BACKLIGHT_BRIGHTNESS_MSB set to a non-zero value, without the
> > panel actually having DPCD backlight controls enabled?
> 
> It boots with DP_EDP_BACKLIGHT_BRIGHTNESS_MSB == 0, which used to set
> backlight.enabled = false. By changing backlight.level = max,
> backlight.enabled is now set to true. This results in losing backlight
> control on boot (since the enable routine is no longer invoked).
> 
Ahhh ok, I'm fine with that - review still stands :)

> Sean
> 
> > If I'm understanding that correctly, then this patch looks good to me:
> > 
> > Reviewed-by: Lyude Paul 
> > 
> > On Thu, 2020-09-17 at 20:28 -0400, Sean Paul wrote:
> > > From: Sean Paul 
> > > 
> > > In commit 79946723092b ("drm/i915: Assume 100% brightness when not in
> > > DPCD control mode"), we fixed the brightness level when DPCD control was
> > > not active to max brightness. This is as good as we can guess since most
> > > backlights go on full when uncontrolled.
> > > 
> > > However in doing so we changed the semantics of the initial
> > > 'backlight.enabled' value. At least on Pixelbooks, they  were relying
> > > on the brightness level in DP_EDP_BACKLIGHT_BRIGHTNESS_MSB to be 0 on
> > > boot such that enabled would be false. This causes the device to be
> > > enabled when the brightness is set. Without this, brightness control
> > > doesn't work. So by changing brightness to max, we also flipped enabled
> > > to be true on boot.
> > > 
> > > To fix this, make enabled a function of brightness and backlight control
> > > mechanism.
> > > 
> > > Fixes: 79946723092b ("drm/i915: Assume 100% brightness when not in DPCD
> > > control mode")
> > > Cc: Lyude Paul 
> > > Cc: Jani Nikula 
> > > Cc: Juha-Pekka Heikkila 
> > > Cc: "Ville Syrjälä" 
> > > Cc: Rodrigo Vivi 
> > > Cc: Kevin Chowski >
> > > Signed-off-by: Sean Paul 
> > > ---
> > >  .../drm/i915/display/intel_dp_aux_backlight.c | 31 ---
> > >  1 file changed, 20 insertions(+), 11 deletions(-)
> > > 
> > > diff --git a/drivers/gpu/drm/i915/display/intel_dp_aux_backlight.c
> > > b/drivers/gpu/drm/i915/display/intel_dp_aux_backlight.c
> > > index acbd7eb66cbe..036f504ac7db 100644
> > > --- a/drivers/gpu/drm/i915/display/intel_dp_aux_backlight.c
> > > +++ b/drivers/gpu/drm/i915/display/intel_dp_aux_backlight.c
> > > @@ -52,17 +52,11 @@ static void set_aux_backlight_enable(struct intel_dp
> > > *intel_dp, bool enable)
> > >   }
> > >  }
> > > 
> > > -/*
> > > - * Read the current backlight value from DPCD register(s) based
> > > - * on if 8-bit(MSB) or 16-bit(MSB and LSB) values are supported
> > > - */
> > > -static u32 intel_dp_aux_get_backlight(struct intel_connector
> > > *connector)
> > > +static bool intel_dp_aux_backlight_dpcd_mode(struct intel_connector
> > > *connector)
> > >  {
> > >   struct intel_dp *intel_dp = intel_attached_dp(connector);
> > >   struct drm_i915_private *i915 = dp_to_i915(intel_dp);
> > > - u8 read_val[2] = { 0x0 };
> > >   u8 mode_reg;
> > > - u16 level = 0;
> > > 
> > >   if (drm_dp_dpcd_readb(_dp->aux,
> > > DP_EDP_BACKLIGHT_MODE_SET_REGISTER,
> > > @@ -70,15 +64,29 @@ static u32 intel_dp_aux_get_backlight(struct
> > > intel_connector *connector)
> > >   drm_dbg_kms(>drm,
> > >   "Failed to read the DPCD register 0x%x\n",
> > >   DP_EDP_BACKLIGHT_MODE_SET_REGISTER);
> > > - return 0;
> > > + return false;
> > >   }
> > > 
> > > + return (mode_reg & DP_EDP_BACKLIGHT_CONTROL_MODE_MASK) ==
> > > +DP_EDP_BACKLIGHT_CONTROL_MODE_DPCD;
> > > +}
> > > +
> > > +/*
> > > + * Read the current backlight value from DPCD register(s) based
> > > + * on if 8-bit(MSB) or 16-bit(MSB and LSB) values are supported
> > > + */
> > > +static u32 intel_dp_aux_get_backlight(struct intel_connector
> > > *connector)
> > > +{
> > > + struct intel_dp *intel_dp = intel_attac

Re: [Intel-gfx] [PATCH] drm/i915/dp: Tweak initial dpcd backlight.enabled value

2020-09-21 Thread Lyude Paul

So if I understand this correctly, it sounds like that some Pixelbooks boot up
with DP_EDP_BACKLIGHT_BRIGHTNESS_MSB set to a non-zero value, without the
panel actually having DPCD backlight controls enabled?

If I'm understanding that correctly, then this patch looks good to me:

Reviewed-by: Lyude Paul 

On Thu, 2020-09-17 at 20:28 -0400, Sean Paul wrote:
> From: Sean Paul 
> 
> In commit 79946723092b ("drm/i915: Assume 100% brightness when not in
> DPCD control mode"), we fixed the brightness level when DPCD control was
> not active to max brightness. This is as good as we can guess since most
> backlights go on full when uncontrolled.
> 
> However in doing so we changed the semantics of the initial
> 'backlight.enabled' value. At least on Pixelbooks, they  were relying
> on the brightness level in DP_EDP_BACKLIGHT_BRIGHTNESS_MSB to be 0 on
> boot such that enabled would be false. This causes the device to be
> enabled when the brightness is set. Without this, brightness control
> doesn't work. So by changing brightness to max, we also flipped enabled
> to be true on boot.
> 
> To fix this, make enabled a function of brightness and backlight control
> mechanism.
> 
> Fixes: 79946723092b ("drm/i915: Assume 100% brightness when not in DPCD
> control mode")
> Cc: Lyude Paul 
> Cc: Jani Nikula 
> Cc: Juha-Pekka Heikkila 
> Cc: "Ville Syrjälä" 
> Cc: Rodrigo Vivi 
> Cc: Kevin Chowski >
> Signed-off-by: Sean Paul 
> ---
>  .../drm/i915/display/intel_dp_aux_backlight.c | 31 ---
>  1 file changed, 20 insertions(+), 11 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/display/intel_dp_aux_backlight.c
> b/drivers/gpu/drm/i915/display/intel_dp_aux_backlight.c
> index acbd7eb66cbe..036f504ac7db 100644
> --- a/drivers/gpu/drm/i915/display/intel_dp_aux_backlight.c
> +++ b/drivers/gpu/drm/i915/display/intel_dp_aux_backlight.c
> @@ -52,17 +52,11 @@ static void set_aux_backlight_enable(struct intel_dp
> *intel_dp, bool enable)
>   }
>  }
>  
> -/*
> - * Read the current backlight value from DPCD register(s) based
> - * on if 8-bit(MSB) or 16-bit(MSB and LSB) values are supported
> - */
> -static u32 intel_dp_aux_get_backlight(struct intel_connector *connector)
> +static bool intel_dp_aux_backlight_dpcd_mode(struct intel_connector
> *connector)
>  {
>   struct intel_dp *intel_dp = intel_attached_dp(connector);
>   struct drm_i915_private *i915 = dp_to_i915(intel_dp);
> - u8 read_val[2] = { 0x0 };
>   u8 mode_reg;
> - u16 level = 0;
>  
>   if (drm_dp_dpcd_readb(_dp->aux,
> DP_EDP_BACKLIGHT_MODE_SET_REGISTER,
> @@ -70,15 +64,29 @@ static u32 intel_dp_aux_get_backlight(struct
> intel_connector *connector)
>   drm_dbg_kms(>drm,
>   "Failed to read the DPCD register 0x%x\n",
>   DP_EDP_BACKLIGHT_MODE_SET_REGISTER);
> - return 0;
> + return false;
>   }
>  
> + return (mode_reg & DP_EDP_BACKLIGHT_CONTROL_MODE_MASK) ==
> +DP_EDP_BACKLIGHT_CONTROL_MODE_DPCD;
> +}
> +
> +/*
> + * Read the current backlight value from DPCD register(s) based
> + * on if 8-bit(MSB) or 16-bit(MSB and LSB) values are supported
> + */
> +static u32 intel_dp_aux_get_backlight(struct intel_connector *connector)
> +{
> + struct intel_dp *intel_dp = intel_attached_dp(connector);
> + struct drm_i915_private *i915 = dp_to_i915(intel_dp);
> + u8 read_val[2] = { 0x0 };
> + u16 level = 0;
> +
>   /*
>* If we're not in DPCD control mode yet, the programmed brightness
>* value is meaningless and we should assume max brightness
>*/
> - if ((mode_reg & DP_EDP_BACKLIGHT_CONTROL_MODE_MASK) !=
> - DP_EDP_BACKLIGHT_CONTROL_MODE_DPCD)
> + if (!intel_dp_aux_backlight_dpcd_mode(connector))
>   return connector->panel.backlight.max;
>  
>   if (drm_dp_dpcd_read(_dp->aux, DP_EDP_BACKLIGHT_BRIGHTNESS_MSB,
> @@ -319,7 +327,8 @@ static int intel_dp_aux_setup_backlight(struct
> intel_connector *connector,
>  
>   panel->backlight.min = 0;
>   panel->backlight.level = intel_dp_aux_get_backlight(connector);
> - panel->backlight.enabled = panel->backlight.level != 0;
> + panel->backlight.enabled = intel_dp_aux_backlight_dpcd_mode(connector)
> &&
> +panel->backlight.level != 0;
>  
>   return 0;
>  }
-- 
Cheers,
Lyude Paul (she/her)
Software Engineer at Red Hat

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH] drm/dp: start using more of the extended receiver caps

2020-09-21 Thread Lyude Paul

On Tue, 2020-09-01 at 21:01 +0300, Jani Nikula wrote:
> On Tue, 01 Sep 2020, Lyude Paul  wrote:
> > On Tue, 2020-09-01 at 15:32 +0300, Jani Nikula wrote:
> > > In the future, we'll be needing more of the extended receiver capability
> > > field starting at DPCD address 0x2200. (Specifically, we'll need main
> > > link channel coding cap for DP 2.0.) Start using it now to not miss out
> > > later on.
> > > 
> > > Cc: Lyude Paul 
> > > Signed-off-by: Jani Nikula 
> > > 
> > > ---
> > > 
> > > I guess this can be merged after the topic branch to drm-misc-next or
> > > so, but I'd prefer to have this fairly early on to catch any potential
> > > issues.
> > > ---
> > >  drivers/gpu/drm/drm_dp_helper.c | 2 +-
> > >  1 file changed, 1 insertion(+), 1 deletion(-)
> > > 
> > > diff --git a/drivers/gpu/drm/drm_dp_helper.c
> > > b/drivers/gpu/drm/drm_dp_helper.c
> > > index 1e7c638873c8..3a3c238452df 100644
> > > --- a/drivers/gpu/drm/drm_dp_helper.c
> > > +++ b/drivers/gpu/drm/drm_dp_helper.c
> > > @@ -436,7 +436,7 @@ static u8 drm_dp_downstream_port_count(const u8
> > > dpcd[DP_RECEIVER_CAP_SIZE])
> > >  static int drm_dp_read_extended_dpcd_caps(struct drm_dp_aux *aux,
> > > u8 dpcd[DP_RECEIVER_CAP_SIZE])
> > >  {
> > > - u8 dpcd_ext[6];
> > > + u8 dpcd_ext[DP_RECEIVER_CAP_SIZE];
> > 
> > Not 100% sure this is right? It's not clear at first glance of the 2.0
> > spec, but
> > my assumption would be that on < DP2.0 devices that everything but those
> > first 6
> > bytes are zeroed out in the extended DPRX field. Since we memcpy()
> > dpcd_ext
> > using sizeof(dpcd_ext), we'd potentially end up zeroing out all of the
> > DPCD caps
> > that comes after those 6 bytes.
> 
> Re-reading stuff... AFAICT everything in 0x2200..0x220F should be
> valid. They should match what's in 0x..0x000F except for 0x,
> 0x0001, and 0x0005, for backwards compatibility.
> 
> Apparently there are no such backwards compatibility concerns with the
> other receiver cap fields then.
> 
> But it gives me an uneasy feeling that many places in the spec refer to
> 0x2200+ even though they should per spec be the same in 0x+.
> 
> I guess we can try without the change, and fix later if we hit issues.

I'm fine with the change if it doesn't break things btw - just as long as
we're making sure that we don't zero things out by accident
> 
> 
> BR,
> Jani.
> 
-- 
Cheers,
Lyude Paul (she/her)
Software Engineer at Red Hat

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

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

2020-09-17 Thread Lyude Paul

On Thu, 2020-09-17 at 11:31 -0600, Kevin Chowski wrote:
> 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?

You don't have to do that yet (although I wouldn't object either way), I was
just mostly implying using drm_dp_has_quirk()
> On Thu, Sep 17, 2020 at 11:13 AM Lyude Paul  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 
> > 
> > > ---
> > 
> > > 
> > 
> > >  .../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(_dp->aux,
> > DP_EDP_PWMGEN_BIT_COUNT,
> > 
> > > + _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;
> > 
> > >  }
> > 
> > >  
> > 
> > > @@ -10

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

2020-09-17 Thread Lyude Paul

 > > > 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(>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

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

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

2020-09-17 Thread Lyude Paul

 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

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [RFC v2 4/8] drm/i915/dp: Rename eDP VESA backlight interface functions

2020-09-16 Thread Lyude Paul

Since we're about to add support for a second type of backlight control
interface over DP AUX (specifically, Intel's proprietary HDR backlight
controls) let's rename all of the current backlight hooks we have for
vesa to make it clear that they're specific to the VESA interface and
not Intel's.

Signed-off-by: Lyude Paul 
Cc: thay...@noraisin.net
Cc: Vasily Khoruzhick 
---
 .../drm/i915/display/intel_dp_aux_backlight.c | 51 ++-
 1 file changed, 26 insertions(+), 25 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/intel_dp_aux_backlight.c 
b/drivers/gpu/drm/i915/display/intel_dp_aux_backlight.c
index acbd7eb66cbe3..f601bcbe8ee46 100644
--- a/drivers/gpu/drm/i915/display/intel_dp_aux_backlight.c
+++ b/drivers/gpu/drm/i915/display/intel_dp_aux_backlight.c
@@ -25,7 +25,7 @@
 #include "intel_display_types.h"
 #include "intel_dp_aux_backlight.h"
 
-static void set_aux_backlight_enable(struct intel_dp *intel_dp, bool enable)
+static void set_vesa_backlight_enable(struct intel_dp *intel_dp, bool enable)
 {
struct drm_i915_private *i915 = dp_to_i915(intel_dp);
u8 reg_val = 0;
@@ -56,7 +56,7 @@ static void set_aux_backlight_enable(struct intel_dp 
*intel_dp, bool enable)
  * Read the current backlight value from DPCD register(s) based
  * on if 8-bit(MSB) or 16-bit(MSB and LSB) values are supported
  */
-static u32 intel_dp_aux_get_backlight(struct intel_connector *connector)
+static u32 intel_dp_aux_vesa_get_backlight(struct intel_connector *connector)
 {
struct intel_dp *intel_dp = intel_attached_dp(connector);
struct drm_i915_private *i915 = dp_to_i915(intel_dp);
@@ -99,7 +99,8 @@ static u32 intel_dp_aux_get_backlight(struct intel_connector 
*connector)
  * 8-bit or 16 bit value (MSB and LSB)
  */
 static void
-intel_dp_aux_set_backlight(const struct drm_connector_state *conn_state, u32 
level)
+intel_dp_aux_vesa_set_backlight(const struct drm_connector_state *conn_state,
+   u32 level)
 {
struct intel_connector *connector = 
to_intel_connector(conn_state->connector);
struct intel_dp *intel_dp = intel_attached_dp(connector);
@@ -129,7 +130,7 @@ intel_dp_aux_set_backlight(const struct drm_connector_state 
*conn_state, u32 lev
  * - Where P = 2^Pn, where Pn is the value programmed by field 4:0 of the
  * EDP_PWMGEN_BIT_COUNT register (DPCD Address 00724h)
  */
-static bool intel_dp_aux_set_pwm_freq(struct intel_connector *connector)
+static bool intel_dp_aux_vesa_set_pwm_freq(struct intel_connector *connector)
 {
struct drm_i915_private *dev_priv = to_i915(connector->base.dev);
struct intel_dp *intel_dp = intel_attached_dp(connector);
@@ -165,8 +166,8 @@ static bool intel_dp_aux_set_pwm_freq(struct 
intel_connector *connector)
return true;
 }
 
-static void intel_dp_aux_enable_backlight(const struct intel_crtc_state 
*crtc_state,
- const struct drm_connector_state 
*conn_state)
+static void intel_dp_aux_vesa_enable_backlight(const struct intel_crtc_state 
*crtc_state,
+  const struct drm_connector_state 
*conn_state)
 {
struct intel_connector *connector = 
to_intel_connector(conn_state->connector);
struct intel_dp *intel_dp = intel_attached_dp(connector);
@@ -206,7 +207,7 @@ static void intel_dp_aux_enable_backlight(const struct 
intel_crtc_state *crtc_st
}
 
if (intel_dp->edp_dpcd[2] & DP_EDP_BACKLIGHT_FREQ_AUX_SET_CAP)
-   if (intel_dp_aux_set_pwm_freq(connector))
+   if (intel_dp_aux_vesa_set_pwm_freq(connector))
new_dpcd_buf |= DP_EDP_BACKLIGHT_FREQ_AUX_SET_ENABLE;
 
if (new_dpcd_buf != dpcd_buf) {
@@ -217,18 +218,18 @@ static void intel_dp_aux_enable_backlight(const struct 
intel_crtc_state *crtc_st
}
}
 
-   intel_dp_aux_set_backlight(conn_state,
-  connector->panel.backlight.level);
-   set_aux_backlight_enable(intel_dp, true);
+   intel_dp_aux_vesa_set_backlight(conn_state,
+   connector->panel.backlight.level);
+   set_vesa_backlight_enable(intel_dp, true);
 }
 
-static void intel_dp_aux_disable_backlight(const struct drm_connector_state 
*old_conn_state)
+static void intel_dp_aux_vesa_disable_backlight(const struct 
drm_connector_state *old_conn_state)
 {
-   
set_aux_backlight_enable(enc_to_intel_dp(to_intel_encoder(old_conn_state->best_encoder)),
-false);
+   
set_vesa_backlight_enable(enc_to_intel_dp(to_intel_encoder(old_conn_state->best_encoder)),
+ false);
 }
 
-static u32 intel_dp_aux_calc_max_backlight(struct intel_connector *connector)
+static u32 intel_dp_aux_vesa_calc_max_backlight(struct intel_connector 
*connector)
 {
struct drm_i915_private *i915 = to_i9

[Intel-gfx] [RFC v2 0/8] drm/i915: Add support for Intel's eDP backlight controls

2020-09-16 Thread Lyude Paul

A while ago we ran into issues while trying to enable the eDP backlight
control interface as defined by VESA, in order to make the DPCD
backlight controls on newer laptop panels work. The issue ended up being
much more complicated however, as we also apparently needed to add
support for an Intel-specific DPCD backlight control interface as the
VESA interface is broken on many laptop panels. For lack of a better
name, we just call this the Intel HDR backlight interface.

While this only adds support for the SDR backlight mode (I think), this
will fix a lot of user's laptop panels that we weren't able to properly
automatically detect DPCD backlight controls on previously.

Lyude Paul (8):
  drm/i915/dp: Program source OUI on eDP panels
  drm/i915: Rename pwm_* backlight callbacks to ext_pwm_*
  drm/i915: Keep track of pwm-related backlight hooks separately
  drm/i915/dp: Rename eDP VESA backlight interface functions
  drm/i915/dp: Add register definitions for Intel HDR backlight
interface
  drm/i915/dp: Enable Intel's HDR backlight interface (only SDR for now)
  drm/i915/dp: Allow forcing specific interfaces through
enable_dpcd_backlight
  drm/dp: Revert "drm/dp: Introduce EDID-based quirks"

 drivers/gpu/drm/drm_dp_helper.c   |  82 +--
 drivers/gpu/drm/drm_dp_mst_topology.c |   3 +-
 .../drm/i915/display/intel_display_types.h|  24 +-
 drivers/gpu/drm/i915/display/intel_dp.c   |  42 +-
 .../drm/i915/display/intel_dp_aux_backlight.c | 384 --
 drivers/gpu/drm/i915/display/intel_dp_mst.c   |   3 +-
 drivers/gpu/drm/i915/display/intel_panel.c| 476 ++
 drivers/gpu/drm/i915/display/intel_panel.h|   4 +
 drivers/gpu/drm/i915/display/intel_psr.c  |   2 +-
 drivers/gpu/drm/i915/i915_params.c|   2 +-
 include/drm/drm_dp_helper.h   |  21 +-
 11 files changed, 672 insertions(+), 371 deletions(-)

-- 
2.26.2

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [RFC v2 2/8] drm/i915: Rename pwm_* backlight callbacks to ext_pwm_*

2020-09-16 Thread Lyude Paul

Since we're going to need to add a set of lower-level PWM backlight
control hooks to be shared by normal backlight controls and HDR
backlight controls in SDR mode, let's add a prefix to the external PWM
backlight functions so that the difference between them and the high
level PWM-only backlight functions is a bit more obvious.

This introduces no functional changes.

Signed-off-by: Lyude Paul 
Reviewed-by: Rodrigo Vivi 
Cc: thay...@noraisin.net
Cc: Vasily Khoruzhick 
---
 drivers/gpu/drm/i915/display/intel_panel.c | 24 +++---
 1 file changed, 12 insertions(+), 12 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/intel_panel.c 
b/drivers/gpu/drm/i915/display/intel_panel.c
index 9f23bac0d7924..c0e36244bb07d 100644
--- a/drivers/gpu/drm/i915/display/intel_panel.c
+++ b/drivers/gpu/drm/i915/display/intel_panel.c
@@ -589,7 +589,7 @@ static u32 bxt_get_backlight(struct intel_connector 
*connector)
 BXT_BLC_PWM_DUTY(panel->backlight.controller));
 }
 
-static u32 pwm_get_backlight(struct intel_connector *connector)
+static u32 ext_pwm_get_backlight(struct intel_connector *connector)
 {
struct intel_panel *panel = >panel;
struct pwm_state state;
@@ -666,7 +666,7 @@ static void bxt_set_backlight(const struct 
drm_connector_state *conn_state, u32
   BXT_BLC_PWM_DUTY(panel->backlight.controller), level);
 }
 
-static void pwm_set_backlight(const struct drm_connector_state *conn_state, 
u32 level)
+static void ext_pwm_set_backlight(const struct drm_connector_state 
*conn_state, u32 level)
 {
struct intel_panel *panel = 
_intel_connector(conn_state->connector)->panel;
 
@@ -835,7 +835,7 @@ static void cnp_disable_backlight(const struct 
drm_connector_state *old_conn_sta
   tmp & ~BXT_BLC_PWM_ENABLE);
 }
 
-static void pwm_disable_backlight(const struct drm_connector_state 
*old_conn_state)
+static void ext_pwm_disable_backlight(const struct drm_connector_state 
*old_conn_state)
 {
struct intel_connector *connector = 
to_intel_connector(old_conn_state->connector);
struct intel_panel *panel = >panel;
@@ -1168,8 +1168,8 @@ static void cnp_enable_backlight(const struct 
intel_crtc_state *crtc_state,
   pwm_ctl | BXT_BLC_PWM_ENABLE);
 }
 
-static void pwm_enable_backlight(const struct intel_crtc_state *crtc_state,
-const struct drm_connector_state *conn_state)
+static void ext_pwm_enable_backlight(const struct intel_crtc_state *crtc_state,
+const struct drm_connector_state 
*conn_state)
 {
struct intel_connector *connector = 
to_intel_connector(conn_state->connector);
struct intel_panel *panel = >panel;
@@ -1890,8 +1890,8 @@ cnp_setup_backlight(struct intel_connector *connector, 
enum pipe unused)
return 0;
 }
 
-static int pwm_setup_backlight(struct intel_connector *connector,
-  enum pipe pipe)
+static int ext_pwm_setup_backlight(struct intel_connector *connector,
+  enum pipe pipe)
 {
struct drm_device *dev = connector->base.dev;
struct drm_i915_private *dev_priv = to_i915(dev);
@@ -2065,11 +2065,11 @@ intel_panel_init_backlight_funcs(struct intel_panel 
*panel)
panel->backlight.hz_to_pwm = pch_hz_to_pwm;
} else if (IS_VALLEYVIEW(dev_priv) || IS_CHERRYVIEW(dev_priv)) {
if (connector->base.connector_type == DRM_MODE_CONNECTOR_DSI) {
-   panel->backlight.setup = pwm_setup_backlight;
-   panel->backlight.enable = pwm_enable_backlight;
-   panel->backlight.disable = pwm_disable_backlight;
-   panel->backlight.set = pwm_set_backlight;
-   panel->backlight.get = pwm_get_backlight;
+   panel->backlight.setup = ext_pwm_setup_backlight;
+   panel->backlight.enable = ext_pwm_enable_backlight;
+   panel->backlight.disable = ext_pwm_disable_backlight;
+   panel->backlight.set = ext_pwm_set_backlight;
+   panel->backlight.get = ext_pwm_get_backlight;
} else {
panel->backlight.setup = vlv_setup_backlight;
panel->backlight.enable = vlv_enable_backlight;
-- 
2.26.2

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [RFC v2 3/8] drm/i915: Keep track of pwm-related backlight hooks separately

2020-09-16 Thread Lyude Paul

Currently, every different type of backlight hook that i915 supports is
pretty straight forward - you have a backlight, probably through PWM
(but maybe DPCD), with a single set of platform-specific hooks that are
used for controlling it.

HDR backlights, in particular VESA and Intel's HDR backlight
implementations, can end up being more complicated. With Intel's
proprietary interface, HDR backlight controls always run through the
DPCD. When the backlight is in SDR backlight mode however, the driver
may need to bypass the TCON and control the backlight directly through
PWM.

So, in order to support this we'll need to split our backlight callbacks
into two groups: a set of high-level backlight control callbacks in
intel_panel, and an additional set of pwm-specific backlight control
callbacks. This also implies a functional changes for how these
callbacks are used:

* We now keep track of two separate backlight level ranges, one for the
  high-level backlight, and one for the pwm backlight range
* We also keep track of backlight enablement and PWM backlight
  enablement separately
* Since the currently set backlight level might not be the same as the
  currently programmed PWM backlight level, we stop setting
  panel->backlight.level with the currently programmed PWM backlight
  level in panel->backlight.pwm_funcs.setup(). Instead, we rely
  on the higher level backlight control functions to retrieve the
  current PWM backlight level (in this case, intel_pwm_get_backlight()).
  Note that there are still a few PWM backlight setup callbacks that
  do actually need to retrieve the current PWM backlight level, although
  we no longer save this value in panel->backlight.level like before.
* panel->backlight.pwm_funcs.enable()/disable() both accept a PWM
  brightness level, unlike their siblings
  panel->backlight.enable()/disable(). This is so we can calculate the
  actual PWM brightness level we want to set on disable/enable in the
  higher level backlight enable()/disable() functions, since this value
  might be scaled from a brightness level that doesn't come from PWM.

Signed-off-by: Lyude Paul 
Cc: thay...@noraisin.net
Cc: Vasily Khoruzhick 
---
 .../drm/i915/display/intel_display_types.h|  14 +-
 drivers/gpu/drm/i915/display/intel_panel.c| 436 ++
 2 files changed, 246 insertions(+), 204 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/intel_display_types.h 
b/drivers/gpu/drm/i915/display/intel_display_types.h
index b2d0edacc58c9..52a6543df842a 100644
--- a/drivers/gpu/drm/i915/display/intel_display_types.h
+++ b/drivers/gpu/drm/i915/display/intel_display_types.h
@@ -221,6 +221,9 @@ struct intel_panel {
bool alternate_pwm_increment;   /* lpt+ */
 
/* PWM chip */
+   u32 pwm_min;
+   u32 pwm_max;
+   bool pwm_enabled;
bool util_pin_active_low;   /* bxt+ */
u8 controller;  /* bxt+ only */
struct pwm_device *pwm;
@@ -229,6 +232,16 @@ struct intel_panel {
/* DPCD backlight */
u8 pwmgen_bit_count;
 
+   struct {
+   int (*setup)(struct intel_connector *connector, enum 
pipe pipe);
+   u32 (*get)(struct intel_connector *connector);
+   void (*set)(const struct drm_connector_state 
*conn_state, u32 level);
+   void (*disable)(const struct drm_connector_state 
*conn_state, u32 level);
+   void (*enable)(const struct intel_crtc_state 
*crtc_state,
+  const struct drm_connector_state 
*conn_state, u32 level);
+   u32 (*hz_to_pwm)(struct intel_connector *connector, u32 
hz);
+   } pwm_funcs;
+
struct backlight_device *device;
 
/* Connector and platform specific backlight functions */
@@ -238,7 +251,6 @@ struct intel_panel {
void (*disable)(const struct drm_connector_state *conn_state);
void (*enable)(const struct intel_crtc_state *crtc_state,
   const struct drm_connector_state *conn_state);
-   u32 (*hz_to_pwm)(struct intel_connector *connector, u32 hz);
void (*power)(struct intel_connector *, bool enable);
} backlight;
 };
diff --git a/drivers/gpu/drm/i915/display/intel_panel.c 
b/drivers/gpu/drm/i915/display/intel_panel.c
index c0e36244bb07d..6d3e9d51d069c 100644
--- a/drivers/gpu/drm/i915/display/intel_panel.c
+++ b/drivers/gpu/drm/i915/display/intel_panel.c
@@ -511,25 +511,34 @@ static u32 scale_hw_to_user(struct intel_connector 
*connector,
 0, user_max);
 }
 
-static u32 intel_panel_compute_brightness(struct intel_connector *connector,
- u32 val)
+static u32 intel_panel_sanitize_pwm_level(struct intel_connector *connector, 
u32 val)
 {

[Intel-gfx] [RFC v2 8/8] drm/dp: Revert "drm/dp: Introduce EDID-based quirks"

2020-09-16 Thread Lyude Paul

This reverts commit 0883ce8146ed6074c76399f4e70dbed788582e12. Originally
these quirks were added because of the issues with using the eDP
backlight interfaces on certain laptop panels, which made it impossible
to properly probe for DPCD backlight support without having a whitelist
for panels that we know have working VESA backlight control interfaces
over DPCD. As well, it should be noted it was impossible to use the
normal sink OUI for recognizing these panels as none of them actually
filled out their OUIs, hence needing to resort to checking EDIDs.

At the time we weren't really sure why certain panels had issues with
DPCD backlight controls, but we eventually figured out that there was a
second interface that these problematic laptop panels actually did work
with and advertise properly: Intel's proprietary backlight interface for
HDR panels. So far the testing we've done hasn't brought any panels to
light that advertise this interface and don't support it properly, which
means we finally have a real solution to this problem.

As a result, we now have no need for the force DPCD backlight quirk, and
furthermore this also removes the need for any kind of EDID quirk
checking in DRM. So, let's just revert it for now since we were the only
driver using this.

v2:
* Fix indenting error picked up by checkpatch in
  intel_edp_init_connector()

Signed-off-by: Lyude Paul 
Acked-by: Jani Nikula 
Cc: thay...@noraisin.net
Cc: Vasily Khoruzhick 
---
 drivers/gpu/drm/drm_dp_helper.c   | 82 +--
 drivers/gpu/drm/drm_dp_mst_topology.c |  3 +-
 .../drm/i915/display/intel_display_types.h|  1 -
 drivers/gpu/drm/i915/display/intel_dp.c   |  9 +-
 drivers/gpu/drm/i915/display/intel_dp_mst.c   |  3 +-
 drivers/gpu/drm/i915/display/intel_psr.c  |  2 +-
 include/drm/drm_dp_helper.h   | 21 +
 7 files changed, 9 insertions(+), 112 deletions(-)

diff --git a/drivers/gpu/drm/drm_dp_helper.c b/drivers/gpu/drm/drm_dp_helper.c
index 1e7c638873c82..7138655bfc9d0 100644
--- a/drivers/gpu/drm/drm_dp_helper.c
+++ b/drivers/gpu/drm/drm_dp_helper.c
@@ -823,7 +823,7 @@ bool drm_dp_read_sink_count_cap(struct drm_connector 
*connector,
return connector->connector_type != DRM_MODE_CONNECTOR_eDP &&
dpcd[DP_DPCD_REV] >= DP_DPCD_REV_11 &&
dpcd[DP_DOWNSTREAMPORT_PRESENT] & DP_DWN_STRM_PORT_PRESENT &&
-   !drm_dp_has_quirk(desc, 0, DP_DPCD_QUIRK_NO_SINK_COUNT);
+   !drm_dp_has_quirk(desc, DP_DPCD_QUIRK_NO_SINK_COUNT);
 }
 EXPORT_SYMBOL(drm_dp_read_sink_count_cap);
 
@@ -1544,86 +1544,6 @@ drm_dp_get_quirks(const struct drm_dp_dpcd_ident *ident, 
bool is_branch)
 #undef DEVICE_ID_ANY
 #undef DEVICE_ID
 
-struct edid_quirk {
-   u8 mfg_id[2];
-   u8 prod_id[2];
-   u32 quirks;
-};
-
-#define MFG(first, second) { (first), (second) }
-#define PROD_ID(first, second) { (first), (second) }
-
-/*
- * 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) },
-};
-
-#undef MFG
-#undef PROD_ID
-
-/**
- * drm_dp_get_edid_quirks() - Check the EDID of a DP device to find additional
- * DP-specific quirks
- * @edid: The EDID to check
- *
- * While OUIDs are meant to be used to recognize a DisplayPort device, a lot
- * of manufacturers don't seem to like following standards and neglect to fill
- * the dev-ID in, making it impossible to only use OUIDs for determining
- * quirks in some cases. This function can be used to check the EDID and look
- * up any addit

[Intel-gfx] [RFC v2 6/8] drm/i915/dp: Enable Intel's HDR backlight interface (only SDR for now)

2020-09-16 Thread Lyude Paul

So-recently a bunch of laptops on the market have started using DPCD
backlight controls instead of the traditional DDI backlight controls.
Originally we thought we had this handled by adding VESA backlight
control support to i915, but the story ended up being a lot more
complicated then that.

Simply put-there's two main backlight interfaces Intel can see in the
wild. Intel's proprietary HDR backlight interface, and the standard VESA
backlight interface. Note that many panels have been observed to report
support for both backlight interfaces, but testing has shown far more
panels work with the Intel HDR backlight interface at the moment.
Additionally, the VBT appears to be capable of reporting support for the
VESA backlight interface but not the Intel HDR interface which needs to
be probed by setting the right magic OUI.

On top of that however, there's also actually two different variants of
the Intel HDR backlight interface. The first uses the AUX channel for
controlling the brightness of the screen in both SDR and HDR mode, and
the second only uses the AUX channel for setting the brightness level in
HDR mode - relying on PWM for setting the brightness level in SDR mode.

For the time being we've been using EDIDs to maintain a list of quirks
for panels that safely do support the VESA backlight interface. Adding
support for Intel's HDR backlight interface in addition however, should
finally allow us to auto-detect eDP backlight controls properly so long
as we probe like so:

* If the panel's VBT reports VESA backlight support, assume it really
  does support it
* If the panel's VBT reports DDI backlight controls:
  * First probe for Intel's HDR backlight interface
  * If that fails, probe for VESA's backlight interface
  * If that fails, assume no DPCD backlight control
* If the panel's VBT reports any other backlight type: just assume it
  doesn't have DPCD backlight controls

Signed-off-by: Lyude Paul 
Cc: thay...@noraisin.net
Cc: Vasily Khoruzhick 
---
 .../drm/i915/display/intel_display_types.h|   9 +-
 .../drm/i915/display/intel_dp_aux_backlight.c | 253 --
 drivers/gpu/drm/i915/display/intel_panel.c|  34 ++-
 drivers/gpu/drm/i915/display/intel_panel.h|   4 +
 4 files changed, 268 insertions(+), 32 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/intel_display_types.h 
b/drivers/gpu/drm/i915/display/intel_display_types.h
index 52a6543df842a..9d540368bac89 100644
--- a/drivers/gpu/drm/i915/display/intel_display_types.h
+++ b/drivers/gpu/drm/i915/display/intel_display_types.h
@@ -230,7 +230,14 @@ struct intel_panel {
struct pwm_state pwm_state;
 
/* DPCD backlight */
-   u8 pwmgen_bit_count;
+   union {
+   struct {
+   u8 pwmgen_bit_count;
+   } vesa;
+   struct {
+   bool sdr_uses_aux;
+   } intel;
+   } edp;
 
struct {
int (*setup)(struct intel_connector *connector, enum 
pipe pipe);
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 c1e8e8b166267..376419ea3ae52 100644
--- a/drivers/gpu/drm/i915/display/intel_dp_aux_backlight.c
+++ b/drivers/gpu/drm/i915/display/intel_dp_aux_backlight.c
@@ -22,8 +22,26 @@
  *
  */
 
+/*
+ * Laptops with Intel GPUs which have panels that support controlling the
+ * backlight through DP AUX can actually use two different interfaces: Intel's
+ * proprietary DP AUX backlight interface, and the standard VESA backlight
+ * interface. Unfortunately, at the time of writing this a lot of laptops will
+ * advertise support for the standard VESA backlight interface when they
+ * don't properly support it. However, on these systems the Intel backlight
+ * interface generally does work properly. Additionally, these systems will
+ * usually just indicate that they use PWM backlight controls in their VBIOS
+ * for some reason.
+ */
+
 #include "intel_display_types.h"
 #include "intel_dp_aux_backlight.h"
+#include "intel_panel.h"
+
+/* TODO:
+ * Implement HDR, right now we just implement the bare minimum to bring us 
back into SDR mode so we
+ * can make people's backlights work in the mean time
+ */
 
 /*
  * DP AUX registers for Intel's proprietary HDR backlight interface. We define
@@ -77,6 +95,176 @@
 
 #define INTEL_EDP_BRIGHTNESS_OPTIMIZATION_10x359
 
+/* Intel EDP backlight callbacks */
+static bool
+intel_dp_aux_supports_hdr_backlight(struct intel_connector *connector)
+{
+   struct drm_device *dev = connector->base.dev;
+   struct intel_dp *intel_dp = enc_to_intel_dp(connector->encoder);
+   struct drm_dp_aux *aux = _dp->aux;
+   struct intel_panel *panel = >panel;
+   int ret;
+   u8 tcon_cap[4];
+
+   ret = drm_dp_dpcd_r

[Intel-gfx] [RFC v2 1/8] drm/i915/dp: Program source OUI on eDP panels

2020-09-16 Thread Lyude Paul

Since we're about to start adding support for Intel's magic HDR
backlight interface over DPCD, we need to ensure we're properly
programming this field so that Intel specific sink services are exposed.
Otherwise, 0x300-0x3ff will just read zeroes.

We also take care not to reprogram the source OUI if it already matches
what we expect. This is just to be careful so that we don't accidentally
take the panel out of any backlight control modes we found it in.

v2:
* Add careful parameter to intel_edp_init_source_oui() to avoid
  re-writing the source OUI if it's already been set during driver
  initialization

Signed-off-by: Lyude Paul 
Cc: thay...@noraisin.net
Cc: Vasily Khoruzhick 
---
 drivers/gpu/drm/i915/display/intel_dp.c | 33 +
 1 file changed, 33 insertions(+)

diff --git a/drivers/gpu/drm/i915/display/intel_dp.c 
b/drivers/gpu/drm/i915/display/intel_dp.c
index 4bd10456ad188..7db2b6a3cd52e 100644
--- a/drivers/gpu/drm/i915/display/intel_dp.c
+++ b/drivers/gpu/drm/i915/display/intel_dp.c
@@ -3424,6 +3424,29 @@ void intel_dp_sink_set_decompression_state(struct 
intel_dp *intel_dp,
enable ? "enable" : "disable");
 }
 
+static void
+intel_edp_init_source_oui(struct intel_dp *intel_dp, bool careful)
+{
+   struct drm_i915_private *i915 = dp_to_i915(intel_dp);
+   u8 oui[] = { 0x00, 0xaa, 0x01 };
+   u8 buf[3] = { 0 };
+
+   /*
+* During driver init, we want to be careful and avoid changing the 
source OUI if it's
+* already set to what we want, so as to avoid clearing any state by 
accident
+*/
+   if (careful) {
+   if (drm_dp_dpcd_read(_dp->aux, DP_SOURCE_OUI, buf, 
sizeof(buf)) < 0)
+   drm_err(>drm, "Failed to read source OUI\n");
+
+   if (memcmp(oui, buf, sizeof(oui)) == 0)
+   return;
+   }
+
+   if (drm_dp_dpcd_write(_dp->aux, DP_SOURCE_OUI, oui, sizeof(oui)) 
< 0)
+   drm_err(>drm, "Failed to write source OUI\n");
+}
+
 /* If the sink supports it, try to set the power state appropriately */
 void intel_dp_sink_dpms(struct intel_dp *intel_dp, int mode)
 {
@@ -3443,6 +3466,10 @@ void intel_dp_sink_dpms(struct intel_dp *intel_dp, int 
mode)
} else {
struct intel_lspcon *lspcon = dp_to_lspcon(intel_dp);
 
+   /* Write the source OUI as early as possible */
+   if (intel_dp_is_edp(intel_dp))
+   intel_edp_init_source_oui(intel_dp, false);
+
/*
 * When turning on, we need to retry for 1ms to give the sink
 * time to wake up.
@@ -4607,6 +4634,12 @@ intel_edp_init_dpcd(struct intel_dp *intel_dp)
if (INTEL_GEN(dev_priv) >= 10 || IS_GEMINILAKE(dev_priv))
intel_dp_get_dsc_sink_cap(intel_dp);
 
+   /*
+* If needed, program our source OUI so we can make various 
Intel-specific AUX services
+* available (such as HDR backlight controls)
+*/
+   intel_edp_init_source_oui(intel_dp, true);
+
return true;
 }
 
-- 
2.26.2

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [RFC v2 5/8] drm/i915/dp: Add register definitions for Intel HDR backlight interface

2020-09-16 Thread Lyude Paul

No functional changes yet, this just adds definitions for all of the
known DPCD registers used by Intel's HDR backlight interface. Since
we'll only ever use this in i915, we just define them in
intel_dp_aux_backlight.c

Reviewed-by: Rodrigo Vivi 
Signed-off-by: Lyude Paul 
Cc: thay...@noraisin.net
Cc: Vasily Khoruzhick 
---
 .../drm/i915/display/intel_dp_aux_backlight.c | 53 +++
 1 file changed, 53 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 f601bcbe8ee46..c1e8e8b166267 100644
--- a/drivers/gpu/drm/i915/display/intel_dp_aux_backlight.c
+++ b/drivers/gpu/drm/i915/display/intel_dp_aux_backlight.c
@@ -25,6 +25,59 @@
 #include "intel_display_types.h"
 #include "intel_dp_aux_backlight.h"
 
+/*
+ * DP AUX registers for Intel's proprietary HDR backlight interface. We define
+ * them here since we'll likely be the only driver to ever use these.
+ */
+#define INTEL_EDP_HDR_TCON_CAP00x340
+
+#define INTEL_EDP_HDR_TCON_CAP10x341
+# define INTEL_EDP_HDR_TCON_2084_DECODE_CAP   BIT(0)
+# define INTEL_EDP_HDR_TCON_2020_GAMUT_CAPBIT(1)
+# define INTEL_EDP_HDR_TCON_TONE_MAPPING_CAP  BIT(2)
+# define INTEL_EDP_HDR_TCON_SEGMENTED_BACKLIGHT_CAP   BIT(3)
+# define INTEL_EDP_HDR_TCON_BRIGHTNESS_NITS_CAP   BIT(4)
+# define INTEL_EDP_HDR_TCON_OPTIMIZATION_CAP  BIT(5)
+# define INTEL_EDP_HDR_TCON_SDP_COLORIMETRY_CAP   BIT(6)
+# define INTEL_EDP_HDR_TCON_SRGB_TO_PANEL_GAMUT_CONVERSION_CAPBIT(7)
+
+#define INTEL_EDP_HDR_TCON_CAP20x342
+# define INTEL_EDP_SDR_TCON_BRIGHTNESS_AUX_CAPBIT(0)
+
+#define INTEL_EDP_HDR_TCON_CAP30x343
+
+#define INTEL_EDP_HDR_GETSET_CTRL_PARAMS   0x344
+# define INTEL_EDP_HDR_TCON_2084_DECODE_ENABLEBIT(0)
+# define INTEL_EDP_HDR_TCON_2020_GAMUT_ENABLE BIT(1)
+# define INTEL_EDP_HDR_TCON_TONE_MAPPING_ENABLE   BIT(2) 
/* Pre-TGL+ */
+# define INTEL_EDP_HDR_TCON_SEGMENTED_BACKLIGHT_ENABLEBIT(3)
+# define INTEL_EDP_HDR_TCON_BRIGHTNESS_AUX_ENABLE BIT(4)
+# define INTEL_EDP_HDR_TCON_SRGB_TO_PANEL_GAMUT_ENABLEBIT(5)
+/* Bit 6 is reserved */
+# define INTEL_EDP_HDR_TCON_SDP_COLORIMETRY_ENABLEBIT(7)
+
+#define INTEL_EDP_HDR_CONTENT_LUMINANCE0x346 
/* Pre-TGL+ */
+#define INTEL_EDP_HDR_PANEL_LUMINANCE_OVERRIDE 0x34A
+#define INTEL_EDP_SDR_LUMINANCE_LEVEL  0x352
+#define INTEL_EDP_BRIGHTNESS_NITS_LSB  0x354
+#define INTEL_EDP_BRIGHTNESS_NITS_MSB  0x355
+#define INTEL_EDP_BRIGHTNESS_DELAY_FRAMES  0x356
+#define INTEL_EDP_BRIGHTNESS_PER_FRAME_STEPS   0x357
+
+#define INTEL_EDP_BRIGHTNESS_OPTIMIZATION_00x358
+# define INTEL_EDP_TCON_USAGE_MASK GENMASK(0, 3)
+# define INTEL_EDP_TCON_USAGE_UNKNOWN0x0
+# define INTEL_EDP_TCON_USAGE_DESKTOP0x1
+# define INTEL_EDP_TCON_USAGE_FULL_SCREEN_MEDIA  0x2
+# define INTEL_EDP_TCON_USAGE_FULL_SCREEN_GAMING 0x3
+# define INTEL_EDP_TCON_POWER_MASKBIT(4)
+# define INTEL_EDP_TCON_POWER_DC(0 << 4)
+# define INTEL_EDP_TCON_POWER_AC(1 << 4)
+# define INTEL_EDP_TCON_OPTIMIZATION_STRENGTH_MASK GENMASK(5, 7)
+
+#define INTEL_EDP_BRIGHTNESS_OPTIMIZATION_10x359
+
+/* VESA backlight callbacks */
 static void set_vesa_backlight_enable(struct intel_dp *intel_dp, bool enable)
 {
struct drm_i915_private *i915 = dp_to_i915(intel_dp);
-- 
2.26.2

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [RFC v2 7/8] drm/i915/dp: Allow forcing specific interfaces through enable_dpcd_backlight

2020-09-16 Thread Lyude Paul

Since we now support controlling panel backlights through DPCD using
both the standard VESA interface, and Intel's proprietary HDR backlight
interface, we should allow the user to be able to explicitly choose
between one or the other in the event that we're wrong about panels
reliably reporting support for the Intel HDR interface.

So, this commit adds support for this by introducing two new
enable_dpcd_backlight options: 2 which forces i915 to only probe for the
VESA interface, and 3 which forces i915 to only probe for the Intel
backlight interface (might be useful if we find panels in the wild that
report the VESA interface in their VBT, but actually only support the
Intel backlight interface).

Signed-off-by: Lyude Paul 
Cc: thay...@noraisin.net
Cc: Vasily Khoruzhick 
---
 .../drm/i915/display/intel_dp_aux_backlight.c | 45 +--
 drivers/gpu/drm/i915/i915_params.c|  2 +-
 2 files changed, 43 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/intel_dp_aux_backlight.c 
b/drivers/gpu/drm/i915/display/intel_dp_aux_backlight.c
index 376419ea3ae52..aa1429302db70 100644
--- a/drivers/gpu/drm/i915/display/intel_dp_aux_backlight.c
+++ b/drivers/gpu/drm/i915/display/intel_dp_aux_backlight.c
@@ -585,15 +585,54 @@ intel_dp_aux_supports_vesa_backlight(struct 
intel_connector *connector)
return false;
 }
 
+enum intel_dp_aux_backlight_modparam {
+   INTEL_DP_AUX_BACKLIGHT_AUTO = -1,
+   INTEL_DP_AUX_BACKLIGHT_OFF = 0,
+   INTEL_DP_AUX_BACKLIGHT_ON = 1,
+   INTEL_DP_AUX_BACKLIGHT_FORCE_VESA = 2,
+   INTEL_DP_AUX_BACKLIGHT_FORCE_INTEL = 3,
+};
+
 int intel_dp_aux_init_backlight_funcs(struct intel_connector *connector)
 {
struct drm_device *dev = connector->base.dev;
struct intel_panel *panel = >panel;
struct intel_dp *intel_dp = enc_to_intel_dp(connector->encoder);
struct drm_i915_private *i915 = dp_to_i915(intel_dp);
+   bool try_intel_interface = false, try_vesa_interface = false;
 
-   if (i915->params.enable_dpcd_backlight == 0)
+   /* Check the VBT and user's module parameters to figure out which
+* interfaces to probe
+*/
+   switch (i915->params.enable_dpcd_backlight) {
+   case INTEL_DP_AUX_BACKLIGHT_OFF:
return -ENODEV;
+   case INTEL_DP_AUX_BACKLIGHT_AUTO:
+   switch (i915->vbt.backlight.type) {
+   case INTEL_BACKLIGHT_VESA_EDP_AUX_INTERFACE:
+   try_vesa_interface = true;
+   break;
+   case INTEL_BACKLIGHT_DISPLAY_DDI:
+   try_intel_interface = true;
+   try_vesa_interface = true;
+   break;
+   default:
+   return -ENODEV;
+   }
+   break;
+   case INTEL_DP_AUX_BACKLIGHT_ON:
+   if (i915->vbt.backlight.type != 
INTEL_BACKLIGHT_VESA_EDP_AUX_INTERFACE)
+   try_intel_interface = true;
+
+   try_vesa_interface = true;
+   break;
+   case INTEL_DP_AUX_BACKLIGHT_FORCE_VESA:
+   try_vesa_interface = true;
+   break;
+   case INTEL_DP_AUX_BACKLIGHT_FORCE_INTEL:
+   try_intel_interface = true;
+   break;
+   }
 
/*
 * A lot of eDP panels in the wild will report supporting both the
@@ -602,7 +641,7 @@ int intel_dp_aux_init_backlight_funcs(struct 
intel_connector *connector)
 * and will only work with the Intel interface. So, always probe for
 * that first.
 */
-   if (intel_dp_aux_supports_hdr_backlight(connector)) {
+   if (try_intel_interface && 
intel_dp_aux_supports_hdr_backlight(connector)) {
drm_dbg(dev, "Using Intel proprietary eDP backlight 
controls\n");
 
panel->backlight.setup = intel_dp_aux_hdr_setup_backlight;
@@ -614,7 +653,7 @@ int intel_dp_aux_init_backlight_funcs(struct 
intel_connector *connector)
return 0;
}
 
-   if (intel_dp_aux_supports_vesa_backlight(connector)) {
+   if (try_vesa_interface && 
intel_dp_aux_supports_vesa_backlight(connector)) {
drm_dbg(dev, "Using VESA eDP backlight controls\n");
 
panel->backlight.setup = intel_dp_aux_vesa_setup_backlight;
diff --git a/drivers/gpu/drm/i915/i915_params.c 
b/drivers/gpu/drm/i915/i915_params.c
index 7f139ea4a90b2..6939634e56ed6 100644
--- a/drivers/gpu/drm/i915/i915_params.c
+++ b/drivers/gpu/drm/i915/i915_params.c
@@ -185,7 +185,7 @@ i915_param_named_unsafe(inject_probe_failure, uint, 0400,
 
 i915_param_named(enable_dpcd_backlight, int, 0400,
"Enable support for DPCD backlight control"
-   "(-1=use per-VBT LFP backlight type setting [default], 0=disabled, 
1=enabled)");
+   "(-1=use per-VBT LFP backlight type s

Re: [Intel-gfx] [RFC 1/5] drm/i915/dp: Program source OUI on eDP panels

2020-09-16 Thread Lyude Paul

On Wed, 2020-09-16 at 10:43 +0300, Jani Nikula wrote:
> On Tue, 15 Sep 2020, Rodrigo Vivi  wrote:
> > On Tue, Sep 15, 2020 at 01:29:35PM -0400, Lyude Paul wrote:
> > > Since we're about to start adding support for Intel's magic HDR
> > > backlight interface over DPCD, we need to ensure we're properly
> > > programming this field so that Intel specific sink services are exposed.
> > > Otherwise, 0x300-0x3ff will just read zeroes.
> > > 
> > > We also take care not to reprogram the source OUI if it already matches
> > > what we expect. This is just to be careful so that we don't accidentally
> > > take the panel out of any backlight control modes we found it in.
> 
> (For whatever reason I didn't receive the original message.)
> 
> > > Signed-off-by: Lyude Paul 
> > > Cc: thay...@noraisin.net
> > > Cc: Vasily Khoruzhick 
> > > ---
> > >  drivers/gpu/drm/i915/display/intel_dp.c | 32 +
> > >  1 file changed, 32 insertions(+)
> > > 
> > > diff --git a/drivers/gpu/drm/i915/display/intel_dp.c
> > > b/drivers/gpu/drm/i915/display/intel_dp.c
> > > index 4bd10456ad188..b591672ec4eab 100644
> > > --- a/drivers/gpu/drm/i915/display/intel_dp.c
> > > +++ b/drivers/gpu/drm/i915/display/intel_dp.c
> > > @@ -3428,6 +3428,7 @@ void intel_dp_sink_set_decompression_state(struct
> > > intel_dp *intel_dp,
> > >  void intel_dp_sink_dpms(struct intel_dp *intel_dp, int mode)
> > >  {
> > >   struct drm_i915_private *i915 = dp_to_i915(intel_dp);
> > > + u8 edp_oui[] = { 0x00, 0xaa, 0x01 };
> > 
> > what are these values?
> 
> An OUI lookup confirms these are Intel OUI.

Thanks for the confirmation!

> 
> > >   int ret, i;
> > >  
> > >   /* Should have a valid DPCD by this point */
> > > @@ -3443,6 +3444,14 @@ void intel_dp_sink_dpms(struct intel_dp *intel_dp,
> > > int mode)
> > >   } else {
> > >   struct intel_lspcon *lspcon = dp_to_lspcon(intel_dp);
> > >  
> > > + /* Write the source OUI as early as possible */
> > > + if (intel_dp_is_edp(intel_dp)) {
> > > + ret = drm_dp_dpcd_write(_dp->aux, DP_SOURCE_OUI,
> > > edp_oui,
> > > + sizeof(edp_oui));
> > > + if (ret < 0)
> > > + drm_err(>drm, "Failed to write eDP source
> > > OUI\n");
> > > + }
> > > +
> > >   /*
> > >* When turning on, we need to retry for 1ms to give the sink
> > >* time to wake up.
> > > @@ -4530,6 +4539,23 @@ static void intel_dp_get_dsc_sink_cap(struct
> > > intel_dp *intel_dp)
> > >   }
> > >  }
> > >  
> > > +static void
> > > +intel_edp_init_source_oui(struct intel_dp *intel_dp)
> > > +{
> > > + struct drm_i915_private *i915 = dp_to_i915(intel_dp);
> > > + u8 oui[] = { 0x00, 0xaa, 0x01 };
> > > + u8 buf[3] = { 0 };
> > > +
> > > + if (drm_dp_dpcd_read(_dp->aux, DP_SOURCE_OUI, buf, sizeof(buf)) <
> > > 0)
> > > + drm_err(>drm, "Failed to read source OUI\n");
> > > +
> > > + if (memcmp(oui, buf, sizeof(oui)) == 0)
> > > + return;
> > > +
> > > + if (drm_dp_dpcd_write(_dp->aux, DP_SOURCE_OUI, oui, sizeof(oui)) <
> > > 0)
> > > + drm_err(>drm, "Failed to write source OUI\n");
> > > +}
> 
> Maybe add this function with a parameter to force write or write only if
> necessary, and call from both places that set source OUI?
> 
> > > +
> > >  static bool
> > >  intel_edp_init_dpcd(struct intel_dp *intel_dp)
> > >  {
> > > @@ -4607,6 +4633,12 @@ intel_edp_init_dpcd(struct intel_dp *intel_dp)
> > >   if (INTEL_GEN(dev_priv) >= 10 || IS_GEMINILAKE(dev_priv))
> > >   intel_dp_get_dsc_sink_cap(intel_dp);
> > >  
> > > + /*
> > > +  * Program our source OUI so we can make various Intel-specific AUX
> > > +  * services available (such as HDR backlight controls)
> > > +  */
> > > + intel_edp_init_source_oui(intel_dp);
> > 
> > I believe we should restrict this to the supported platforms: cfl, whl, cml,
> > icl, tgl
> > no?
> 
> Mmh, this just exposes sink behaviour that I think can be supported by
> any platform. I don't understand the notion of "supported platforms"
>

Re: [Intel-gfx] [RFC 1/5] drm/i915/dp: Program source OUI on eDP panels

2020-09-15 Thread Lyude Paul

On Tue, 2020-09-15 at 15:38 -0700, Navare, Manasi wrote:
> On Tue, Sep 15, 2020 at 03:47:01PM -0400, Lyude Paul wrote:
> > On Tue, 2020-09-15 at 15:06 -0400, Rodrigo Vivi wrote:
> > > On Tue, Sep 15, 2020 at 01:29:35PM -0400, Lyude Paul wrote:
> > > > Since we're about to start adding support for Intel's magic HDR
> > > > backlight interface over DPCD, we need to ensure we're properly
> > > > programming this field so that Intel specific sink services are
> > > > exposed.
> > > > Otherwise, 0x300-0x3ff will just read zeroes.
> > > > 
> > > > We also take care not to reprogram the source OUI if it already
> > > > matches
> > > > what we expect. This is just to be careful so that we don't
> > > > accidentally
> > > > take the panel out of any backlight control modes we found it in.
> > > > 
> > > > Signed-off-by: Lyude Paul 
> > > > Cc: thay...@noraisin.net
> > > > Cc: Vasily Khoruzhick 
> > > > ---
> > > >  drivers/gpu/drm/i915/display/intel_dp.c | 32
> > > > +
> > > >  1 file changed, 32 insertions(+)
> > > > 
> > > > diff --git a/drivers/gpu/drm/i915/display/intel_dp.c
> > > > b/drivers/gpu/drm/i915/display/intel_dp.c
> > > > index 4bd10456ad188..b591672ec4eab 100644
> > > > --- a/drivers/gpu/drm/i915/display/intel_dp.c
> > > > +++ b/drivers/gpu/drm/i915/display/intel_dp.c
> > > > @@ -3428,6 +3428,7 @@ void
> > > > intel_dp_sink_set_decompression_state(struct
> > > > intel_dp *intel_dp,
> > > >  void intel_dp_sink_dpms(struct intel_dp *intel_dp, int mode)
> > > >  {
> > > > struct drm_i915_private *i915 = dp_to_i915(intel_dp);
> > > > +   u8 edp_oui[] = { 0x00, 0xaa, 0x01 };
> > > 
> > > what are these values?
> 
> We in i915 typically use the OUI number for adding any eDP specific
> quirks. I have seen these getting spit out in the dmesg log at thebeginning.
> AFAIK It is some kind of OEM identification number for a display panel.

Are you sure you're not confusing this with the sink OUI btw? We're setting
the source OUI (so, identifying ourselves to the display panel instead of the
other way around) here to tell the panel to expose the Intel specific
backlight controls. My assumption is the { 0x00, 0xaa, 0x01 } is some Intel
driver OUI, it's just I'm not really sure where it comes from other then the
patch I linked to down below

> 
> Manasi
> > I wish I knew, my assumption is this is the OUI that Intel's GPU driver
> > uses on
> > other platforms, but I don't have any documentation mentioning this (in
> > fact,
> > the few documents I do have on this backlight interface don't seem to make
> > any
> > mention of it). I only managed to find this when looking through the last
> > attempt someone did at adding support for this backlight interface:
> > 
> > https://patchwork.freedesktop.org/patch/334989/
> > 
> > I think it should be fairly safe to write, as I know nouveau always
> > programs a
> > source OUI (we don't do it from our driver, but nvidia hardware seems to
> > do it
> > automatically) and I don't believe I've seen it ever change any behavior
> > besides
> > making things appear in the 0x300-0x3ff register range.
> > 
> > AFAICT though, the backlight interface won't advertise itself without this
> > being
> > set early on. If you could find anyone from Intel who knows more about it
> > though
> > I'd definitely appreciate it (and just in general for the rest of the
> > patch
> > series as well)
> > 
> > > > int ret, i;
> > > >  
> > > > /* Should have a valid DPCD by this point */
> > > > @@ -3443,6 +3444,14 @@ void intel_dp_sink_dpms(struct intel_dp
> > > > *intel_dp,
> > > > int mode)
> > > > } else {
> > > > struct intel_lspcon *lspcon = dp_to_lspcon(intel_dp);
> > > >  
> > > > +   /* Write the source OUI as early as possible */
> > > > +   if (intel_dp_is_edp(intel_dp)) {
> > > > +   ret = drm_dp_dpcd_write(_dp->aux,
> > > > DP_SOURCE_OUI,
> > > > edp_oui,
> > > > +   sizeof(edp_oui));
> > > > +   if (ret < 0)
> > > > +   drm_err(>drm, "Failed to w

Re: [Intel-gfx] [RFC 1/5] drm/i915/dp: Program source OUI on eDP panels

2020-09-15 Thread Lyude Paul

On Tue, 2020-09-15 at 15:06 -0400, Rodrigo Vivi wrote:
> On Tue, Sep 15, 2020 at 01:29:35PM -0400, Lyude Paul wrote:
> > Since we're about to start adding support for Intel's magic HDR
> > backlight interface over DPCD, we need to ensure we're properly
> > programming this field so that Intel specific sink services are exposed.
> > Otherwise, 0x300-0x3ff will just read zeroes.
> > 
> > We also take care not to reprogram the source OUI if it already matches
> > what we expect. This is just to be careful so that we don't accidentally
> > take the panel out of any backlight control modes we found it in.
> > 
> > Signed-off-by: Lyude Paul 
> > Cc: thay...@noraisin.net
> > Cc: Vasily Khoruzhick 
> > ---
> >  drivers/gpu/drm/i915/display/intel_dp.c | 32 +
> >  1 file changed, 32 insertions(+)
> > 
> > diff --git a/drivers/gpu/drm/i915/display/intel_dp.c
> > b/drivers/gpu/drm/i915/display/intel_dp.c
> > index 4bd10456ad188..b591672ec4eab 100644
> > --- a/drivers/gpu/drm/i915/display/intel_dp.c
> > +++ b/drivers/gpu/drm/i915/display/intel_dp.c
> > @@ -3428,6 +3428,7 @@ void intel_dp_sink_set_decompression_state(struct
> > intel_dp *intel_dp,
> >  void intel_dp_sink_dpms(struct intel_dp *intel_dp, int mode)
> >  {
> > struct drm_i915_private *i915 = dp_to_i915(intel_dp);
> > +   u8 edp_oui[] = { 0x00, 0xaa, 0x01 };
> 
> what are these values?

I wish I knew, my assumption is this is the OUI that Intel's GPU driver uses on
other platforms, but I don't have any documentation mentioning this (in fact,
the few documents I do have on this backlight interface don't seem to make any
mention of it). I only managed to find this when looking through the last
attempt someone did at adding support for this backlight interface:

https://patchwork.freedesktop.org/patch/334989/

I think it should be fairly safe to write, as I know nouveau always programs a
source OUI (we don't do it from our driver, but nvidia hardware seems to do it
automatically) and I don't believe I've seen it ever change any behavior besides
making things appear in the 0x300-0x3ff register range.

AFAICT though, the backlight interface won't advertise itself without this being
set early on. If you could find anyone from Intel who knows more about it though
I'd definitely appreciate it (and just in general for the rest of the patch
series as well)

> 
> > int ret, i;
> >  
> > /* Should have a valid DPCD by this point */
> > @@ -3443,6 +3444,14 @@ void intel_dp_sink_dpms(struct intel_dp *intel_dp,
> > int mode)
> > } else {
> > struct intel_lspcon *lspcon = dp_to_lspcon(intel_dp);
> >  
> > +   /* Write the source OUI as early as possible */
> > +   if (intel_dp_is_edp(intel_dp)) {
> > +   ret = drm_dp_dpcd_write(_dp->aux, DP_SOURCE_OUI,
> > edp_oui,
> > +   sizeof(edp_oui));
> > +   if (ret < 0)
> > +   drm_err(>drm, "Failed to write eDP source
> > OUI\n");
> > +   }
> > +
> > /*
> >  * When turning on, we need to retry for 1ms to give the sink
> >  * time to wake up.
> > @@ -4530,6 +4539,23 @@ static void intel_dp_get_dsc_sink_cap(struct intel_dp
> > *intel_dp)
> > }
> >  }
> >  
> > +static void
> > +intel_edp_init_source_oui(struct intel_dp *intel_dp)
> > +{
> > +   struct drm_i915_private *i915 = dp_to_i915(intel_dp);
> > +   u8 oui[] = { 0x00, 0xaa, 0x01 };
> > +   u8 buf[3] = { 0 };
> > +
> > +   if (drm_dp_dpcd_read(_dp->aux, DP_SOURCE_OUI, buf, sizeof(buf)) <
> > 0)
> > +   drm_err(>drm, "Failed to read source OUI\n");
> > +
> > +   if (memcmp(oui, buf, sizeof(oui)) == 0)
> > +   return;
> > +
> > +   if (drm_dp_dpcd_write(_dp->aux, DP_SOURCE_OUI, oui, sizeof(oui)) <
> > 0)
> > +   drm_err(>drm, "Failed to write source OUI\n");
> > +}
> > +
> >  static bool
> >  intel_edp_init_dpcd(struct intel_dp *intel_dp)
> >  {
> > @@ -4607,6 +4633,12 @@ intel_edp_init_dpcd(struct intel_dp *intel_dp)
> > if (INTEL_GEN(dev_priv) >= 10 || IS_GEMINILAKE(dev_priv))
> > intel_dp_get_dsc_sink_cap(intel_dp);
> >  
> > +   /*
> > +    * Program our source OUI so we can make various Intel-specific AUX
> > +* services available (such as HDR backlight controls)
> > +*/
> > +   intel_edp_init_source_oui(intel_dp);
> 
> I believe we should restrict this to the supported platforms: cfl, whl, cml,
> icl, tgl
> no?
> 
> > +
> > return true;
> >  }
> >  
> > -- 
> > 2.26.2
> > 
> > ___
> > dri-devel mailing list
> > dri-de...@lists.freedesktop.org
> > https://lists.freedesktop.org/mailman/listinfo/dri-devel
-- 
Sincerely,
  Lyude Paul (she/her)
  Software Engineer at Red Hat

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [RFC 2/5] drm/i915: Rename pwm_* backlight callbacks to ext_pwm_*

2020-09-15 Thread Lyude Paul

Since we're going to need to add a set of lower-level PWM backlight
control hooks to be shared by normal backlight controls and HDR
backlight controls in SDR mode, let's add a prefix to the external PWM
backlight functions so that the difference between them and the high
level PWM-only backlight functions is a bit more obvious.

This introduces no functional changes.

Signed-off-by: Lyude Paul 
Cc: thay...@noraisin.net
Cc: Vasily Khoruzhick 
---
 drivers/gpu/drm/i915/display/intel_panel.c | 24 +++---
 1 file changed, 12 insertions(+), 12 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/intel_panel.c 
b/drivers/gpu/drm/i915/display/intel_panel.c
index 9f23bac0d7924..c0e36244bb07d 100644
--- a/drivers/gpu/drm/i915/display/intel_panel.c
+++ b/drivers/gpu/drm/i915/display/intel_panel.c
@@ -589,7 +589,7 @@ static u32 bxt_get_backlight(struct intel_connector 
*connector)
 BXT_BLC_PWM_DUTY(panel->backlight.controller));
 }
 
-static u32 pwm_get_backlight(struct intel_connector *connector)
+static u32 ext_pwm_get_backlight(struct intel_connector *connector)
 {
struct intel_panel *panel = >panel;
struct pwm_state state;
@@ -666,7 +666,7 @@ static void bxt_set_backlight(const struct 
drm_connector_state *conn_state, u32
   BXT_BLC_PWM_DUTY(panel->backlight.controller), level);
 }
 
-static void pwm_set_backlight(const struct drm_connector_state *conn_state, 
u32 level)
+static void ext_pwm_set_backlight(const struct drm_connector_state 
*conn_state, u32 level)
 {
struct intel_panel *panel = 
_intel_connector(conn_state->connector)->panel;
 
@@ -835,7 +835,7 @@ static void cnp_disable_backlight(const struct 
drm_connector_state *old_conn_sta
   tmp & ~BXT_BLC_PWM_ENABLE);
 }
 
-static void pwm_disable_backlight(const struct drm_connector_state 
*old_conn_state)
+static void ext_pwm_disable_backlight(const struct drm_connector_state 
*old_conn_state)
 {
struct intel_connector *connector = 
to_intel_connector(old_conn_state->connector);
struct intel_panel *panel = >panel;
@@ -1168,8 +1168,8 @@ static void cnp_enable_backlight(const struct 
intel_crtc_state *crtc_state,
   pwm_ctl | BXT_BLC_PWM_ENABLE);
 }
 
-static void pwm_enable_backlight(const struct intel_crtc_state *crtc_state,
-const struct drm_connector_state *conn_state)
+static void ext_pwm_enable_backlight(const struct intel_crtc_state *crtc_state,
+const struct drm_connector_state 
*conn_state)
 {
struct intel_connector *connector = 
to_intel_connector(conn_state->connector);
struct intel_panel *panel = >panel;
@@ -1890,8 +1890,8 @@ cnp_setup_backlight(struct intel_connector *connector, 
enum pipe unused)
return 0;
 }
 
-static int pwm_setup_backlight(struct intel_connector *connector,
-  enum pipe pipe)
+static int ext_pwm_setup_backlight(struct intel_connector *connector,
+  enum pipe pipe)
 {
struct drm_device *dev = connector->base.dev;
struct drm_i915_private *dev_priv = to_i915(dev);
@@ -2065,11 +2065,11 @@ intel_panel_init_backlight_funcs(struct intel_panel 
*panel)
panel->backlight.hz_to_pwm = pch_hz_to_pwm;
} else if (IS_VALLEYVIEW(dev_priv) || IS_CHERRYVIEW(dev_priv)) {
if (connector->base.connector_type == DRM_MODE_CONNECTOR_DSI) {
-   panel->backlight.setup = pwm_setup_backlight;
-   panel->backlight.enable = pwm_enable_backlight;
-   panel->backlight.disable = pwm_disable_backlight;
-   panel->backlight.set = pwm_set_backlight;
-   panel->backlight.get = pwm_get_backlight;
+   panel->backlight.setup = ext_pwm_setup_backlight;
+   panel->backlight.enable = ext_pwm_enable_backlight;
+   panel->backlight.disable = ext_pwm_disable_backlight;
+   panel->backlight.set = ext_pwm_set_backlight;
+   panel->backlight.get = ext_pwm_get_backlight;
} else {
panel->backlight.setup = vlv_setup_backlight;
panel->backlight.enable = vlv_enable_backlight;
-- 
2.26.2

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [RFC 5/5] drm/dp: Revert "drm/dp: Introduce EDID-based quirks"

2020-09-15 Thread Lyude Paul

This reverts commit 0883ce8146ed6074c76399f4e70dbed788582e12. Originally
these quirks were added because of the issues with using the eDP
backlight interfaces on certain laptop panels, which made it impossible
to properly probe for DPCD backlight support without having a whitelist
for panels that we know have working VESA backlight control interfaces
over DPCD. As well, it should be noted it was impossible to use the
normal sink OUI for recognizing these panels as none of them actually
filled out their OUIs, hence needing to resort to checking EDIDs.

At the time we weren't really sure why certain panels had issues with
DPCD backlight controls, but we eventually figured out that there was a
second interface that these problematic laptop panels actually did work
with and advertise properly: Intel's proprietary backlight interface for
HDR panels. So far the testing we've done hasn't brought any panels to
light that advertise this interface and don't support it properly, which
means we finally have a real solution to this problem.

As a result, we now have no need for the force DPCD backlight quirk, and
furthermore this also removes the need for any kind of EDID quirk
checking in DRM. So, let's just revert it for now since we were the only
driver using this.

Signed-off-by: Lyude Paul 
Cc: thay...@noraisin.net
Cc: Vasily Khoruzhick 
---
 drivers/gpu/drm/drm_dp_helper.c   | 82 +--
 drivers/gpu/drm/drm_dp_mst_topology.c |  3 +-
 .../drm/i915/display/intel_display_types.h|  1 -
 drivers/gpu/drm/i915/display/intel_dp.c   | 12 +--
 drivers/gpu/drm/i915/display/intel_dp_mst.c   |  3 +-
 drivers/gpu/drm/i915/display/intel_psr.c  |  2 +-
 include/drm/drm_dp_helper.h   | 21 +
 7 files changed, 11 insertions(+), 113 deletions(-)

diff --git a/drivers/gpu/drm/drm_dp_helper.c b/drivers/gpu/drm/drm_dp_helper.c
index 1e7c638873c82..7138655bfc9d0 100644
--- a/drivers/gpu/drm/drm_dp_helper.c
+++ b/drivers/gpu/drm/drm_dp_helper.c
@@ -823,7 +823,7 @@ bool drm_dp_read_sink_count_cap(struct drm_connector 
*connector,
return connector->connector_type != DRM_MODE_CONNECTOR_eDP &&
dpcd[DP_DPCD_REV] >= DP_DPCD_REV_11 &&
dpcd[DP_DOWNSTREAMPORT_PRESENT] & DP_DWN_STRM_PORT_PRESENT &&
-   !drm_dp_has_quirk(desc, 0, DP_DPCD_QUIRK_NO_SINK_COUNT);
+   !drm_dp_has_quirk(desc, DP_DPCD_QUIRK_NO_SINK_COUNT);
 }
 EXPORT_SYMBOL(drm_dp_read_sink_count_cap);
 
@@ -1544,86 +1544,6 @@ drm_dp_get_quirks(const struct drm_dp_dpcd_ident *ident, 
bool is_branch)
 #undef DEVICE_ID_ANY
 #undef DEVICE_ID
 
-struct edid_quirk {
-   u8 mfg_id[2];
-   u8 prod_id[2];
-   u32 quirks;
-};
-
-#define MFG(first, second) { (first), (second) }
-#define PROD_ID(first, second) { (first), (second) }
-
-/*
- * 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) },
-};
-
-#undef MFG
-#undef PROD_ID
-
-/**
- * drm_dp_get_edid_quirks() - Check the EDID of a DP device to find additional
- * DP-specific quirks
- * @edid: The EDID to check
- *
- * While OUIDs are meant to be used to recognize a DisplayPort device, a lot
- * of manufacturers don't seem to like following standards and neglect to fill
- * the dev-ID in, making it impossible to only use OUIDs for determining
- * quirks in some cases. This function can be used to check the EDID and look
- * up any additional DP quirks. The bits returned by this function correspond
- * to the quirk bits in _dp_quirk.
- *
- * Re

[Intel-gfx] [RFC 1/5] drm/i915/dp: Program source OUI on eDP panels

2020-09-15 Thread Lyude Paul

Since we're about to start adding support for Intel's magic HDR
backlight interface over DPCD, we need to ensure we're properly
programming this field so that Intel specific sink services are exposed.
Otherwise, 0x300-0x3ff will just read zeroes.

We also take care not to reprogram the source OUI if it already matches
what we expect. This is just to be careful so that we don't accidentally
take the panel out of any backlight control modes we found it in.

Signed-off-by: Lyude Paul 
Cc: thay...@noraisin.net
Cc: Vasily Khoruzhick 
---
 drivers/gpu/drm/i915/display/intel_dp.c | 32 +
 1 file changed, 32 insertions(+)

diff --git a/drivers/gpu/drm/i915/display/intel_dp.c 
b/drivers/gpu/drm/i915/display/intel_dp.c
index 4bd10456ad188..b591672ec4eab 100644
--- a/drivers/gpu/drm/i915/display/intel_dp.c
+++ b/drivers/gpu/drm/i915/display/intel_dp.c
@@ -3428,6 +3428,7 @@ void intel_dp_sink_set_decompression_state(struct 
intel_dp *intel_dp,
 void intel_dp_sink_dpms(struct intel_dp *intel_dp, int mode)
 {
struct drm_i915_private *i915 = dp_to_i915(intel_dp);
+   u8 edp_oui[] = { 0x00, 0xaa, 0x01 };
int ret, i;
 
/* Should have a valid DPCD by this point */
@@ -3443,6 +3444,14 @@ void intel_dp_sink_dpms(struct intel_dp *intel_dp, int 
mode)
} else {
struct intel_lspcon *lspcon = dp_to_lspcon(intel_dp);
 
+   /* Write the source OUI as early as possible */
+   if (intel_dp_is_edp(intel_dp)) {
+   ret = drm_dp_dpcd_write(_dp->aux, DP_SOURCE_OUI, 
edp_oui,
+   sizeof(edp_oui));
+   if (ret < 0)
+   drm_err(>drm, "Failed to write eDP source 
OUI\n");
+   }
+
/*
 * When turning on, we need to retry for 1ms to give the sink
 * time to wake up.
@@ -4530,6 +4539,23 @@ static void intel_dp_get_dsc_sink_cap(struct intel_dp 
*intel_dp)
}
 }
 
+static void
+intel_edp_init_source_oui(struct intel_dp *intel_dp)
+{
+   struct drm_i915_private *i915 = dp_to_i915(intel_dp);
+   u8 oui[] = { 0x00, 0xaa, 0x01 };
+   u8 buf[3] = { 0 };
+
+   if (drm_dp_dpcd_read(_dp->aux, DP_SOURCE_OUI, buf, sizeof(buf)) < 
0)
+   drm_err(>drm, "Failed to read source OUI\n");
+
+   if (memcmp(oui, buf, sizeof(oui)) == 0)
+   return;
+
+   if (drm_dp_dpcd_write(_dp->aux, DP_SOURCE_OUI, oui, sizeof(oui)) 
< 0)
+   drm_err(>drm, "Failed to write source OUI\n");
+}
+
 static bool
 intel_edp_init_dpcd(struct intel_dp *intel_dp)
 {
@@ -4607,6 +4633,12 @@ intel_edp_init_dpcd(struct intel_dp *intel_dp)
if (INTEL_GEN(dev_priv) >= 10 || IS_GEMINILAKE(dev_priv))
intel_dp_get_dsc_sink_cap(intel_dp);
 
+   /*
+* Program our source OUI so we can make various Intel-specific AUX
+* services available (such as HDR backlight controls)
+*/
+   intel_edp_init_source_oui(intel_dp);
+
return true;
 }
 
-- 
2.26.2

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [RFC 3/5] drm/i915: Keep track of pwm-related backlight hooks separately

2020-09-15 Thread Lyude Paul

Currently, every different type of backlight hook that i915 supports is
pretty straight forward - you have a backlight, probably through PWM
(but maybe DPCD), with a single set of platform-specific hooks that are
used for controlling it.

HDR backlights, in particular VESA and Intel's HDR backlight
implementations, can end up being more complicated. With Intel's
proprietary interface, HDR backlight controls always run through the
DPCD. When the backlight is in SDR backlight mode however, the driver
may need to bypass the TCON and control the backlight directly through
PWM.

So, in order to support this we'll need to split our backlight callbacks
into two groups: a set of high-level backlight control callbacks in
intel_panel, and an additional set of pwm-specific backlight control
callbacks. This also implies a functional changes for how these
callbacks are used:

* We now keep track of two separate backlight level ranges, one for the
  high-level backlight, and one for the pwm backlight range
* We also keep track of backlight enablement and PWM backlight
  enablement separately
* Since the currently set backlight level might not be the same as the
  currently programmed PWM backlight level, we stop setting
  panel->backlight.level with the currently programmed PWM backlight
  level in panel->backlight.pwm_funcs.setup(). Instead, we rely
  on the higher level backlight control functions to retrieve the
  current PWM backlight level (in this case, intel_pwm_get_backlight()).
  Note that there are still a few PWM backlight setup callbacks that
  do actually need to retrieve the current PWM backlight level, although
  we no longer save this value in panel->backlight.level like before.
* panel->backlight.pwm_funcs.enable()/disable() both accept a PWM
  brightness level, unlike their siblings
  panel->backlight.enable()/disable(). This is so we can calculate the
  actual PWM brightness level we want to set on disable/enable in the
  higher level backlight enable()/disable() functions, since this value
  might be scaled from a brightness level that doesn't come from PWM.

Signed-off-by: Lyude Paul 
Cc: thay...@noraisin.net
Cc: Vasily Khoruzhick 
---
 .../drm/i915/display/intel_display_types.h|  14 +-
 drivers/gpu/drm/i915/display/intel_panel.c| 436 ++
 2 files changed, 246 insertions(+), 204 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/intel_display_types.h 
b/drivers/gpu/drm/i915/display/intel_display_types.h
index b2d0edacc58c9..52a6543df842a 100644
--- a/drivers/gpu/drm/i915/display/intel_display_types.h
+++ b/drivers/gpu/drm/i915/display/intel_display_types.h
@@ -221,6 +221,9 @@ struct intel_panel {
bool alternate_pwm_increment;   /* lpt+ */
 
/* PWM chip */
+   u32 pwm_min;
+   u32 pwm_max;
+   bool pwm_enabled;
bool util_pin_active_low;   /* bxt+ */
u8 controller;  /* bxt+ only */
struct pwm_device *pwm;
@@ -229,6 +232,16 @@ struct intel_panel {
/* DPCD backlight */
u8 pwmgen_bit_count;
 
+   struct {
+   int (*setup)(struct intel_connector *connector, enum 
pipe pipe);
+   u32 (*get)(struct intel_connector *connector);
+   void (*set)(const struct drm_connector_state 
*conn_state, u32 level);
+   void (*disable)(const struct drm_connector_state 
*conn_state, u32 level);
+   void (*enable)(const struct intel_crtc_state 
*crtc_state,
+  const struct drm_connector_state 
*conn_state, u32 level);
+   u32 (*hz_to_pwm)(struct intel_connector *connector, u32 
hz);
+   } pwm_funcs;
+
struct backlight_device *device;
 
/* Connector and platform specific backlight functions */
@@ -238,7 +251,6 @@ struct intel_panel {
void (*disable)(const struct drm_connector_state *conn_state);
void (*enable)(const struct intel_crtc_state *crtc_state,
   const struct drm_connector_state *conn_state);
-   u32 (*hz_to_pwm)(struct intel_connector *connector, u32 hz);
void (*power)(struct intel_connector *, bool enable);
} backlight;
 };
diff --git a/drivers/gpu/drm/i915/display/intel_panel.c 
b/drivers/gpu/drm/i915/display/intel_panel.c
index c0e36244bb07d..6d3e9d51d069c 100644
--- a/drivers/gpu/drm/i915/display/intel_panel.c
+++ b/drivers/gpu/drm/i915/display/intel_panel.c
@@ -511,25 +511,34 @@ static u32 scale_hw_to_user(struct intel_connector 
*connector,
 0, user_max);
 }
 
-static u32 intel_panel_compute_brightness(struct intel_connector *connector,
- u32 val)
+static u32 intel_panel_sanitize_pwm_level(struct intel_connector *connector, 
u32 val)
 {

[Intel-gfx] [RFC 4/5] drm/i915: Enable Intel's HDR backlight interface (only SDR for now)

2020-09-15 Thread Lyude Paul

So-recently a bunch of laptops on the market have started using DPCD
backlight controls instead of the traditional DDI backlight controls.
Originally we thought we had this handled by adding VESA backlight
control support to i915, but the story ended up being a lot more
complicated then that.

Simply put-there's two main backlight interfaces Intel can see in the
wild. Intel's proprietary HDR backlight interface, and the standard VESA
backlight interface. Note that many panels have been observed to report
support for both backlight interfaces, but testing has shown far more
panels work with the Intel HDR backlight interface at the moment.
Additionally, the VBT appears to be capable of reporting support for the
VESA backlight interface but not the Intel HDR interface which needs to
be probed by setting the right magic OUI.

On top of that however, there's also actually two different variants of
the Intel HDR backlight interface. The first uses the AUX channel for
controlling the brightness of the screen in both SDR and HDR mode, and
the second only uses the AUX channel for setting the brightness level in
HDR mode - relying on PWM for setting the brightness level in SDR mode.

For the time being we've been using EDIDs to maintain a list of quirks
for panels that safely do support the VESA backlight interface. Adding
support for Intel's HDR backlight interface in addition however, should
finally allow us to auto-detect eDP backlight controls properly so long
as we probe like so:

* If the panel's VBT reports VESA backlight support, assume it really
  does support it
* If the panel's VBT reports DDI backlight controls:
  * First probe for Intel's HDR backlight interface
  * If that fails, probe for VESA's backlight interface
  * If that fails, assume no DPCD backlight control
* If the panel's VBT reports any other backlight type: just assume it
  doesn't have DPCD backlight controls

Note as well that in order for us to make Intel's HDR backlight
interface appear, we need to start programming the appropriate source
OUI on the eDP panel as early as possible in the probing process. Note
that this technically could be done at any time before setting up
backlight controls, but this way allows us to avoid re-writing it
multiple times in case we need to use other source-OUI enabled features
in the future.

Finally, we also make sure to document the registers for this backlight
interface since eventually, we want to actually implement the full
interface instead of keeping it in SDR mode.

Signed-off-by: Lyude Paul 
Cc: thay...@noraisin.net
Cc: Vasily Khoruzhick 
---
 .../drm/i915/display/intel_display_types.h|   9 +-
 .../drm/i915/display/intel_dp_aux_backlight.c | 384 +++---
 drivers/gpu/drm/i915/display/intel_panel.c|  34 +-
 drivers/gpu/drm/i915/display/intel_panel.h|   4 +
 drivers/gpu/drm/i915/i915_params.c|   2 +-
 5 files changed, 381 insertions(+), 52 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/intel_display_types.h 
b/drivers/gpu/drm/i915/display/intel_display_types.h
index 52a6543df842a..9d540368bac89 100644
--- a/drivers/gpu/drm/i915/display/intel_display_types.h
+++ b/drivers/gpu/drm/i915/display/intel_display_types.h
@@ -230,7 +230,14 @@ struct intel_panel {
struct pwm_state pwm_state;
 
/* DPCD backlight */
-   u8 pwmgen_bit_count;
+   union {
+   struct {
+   u8 pwmgen_bit_count;
+   } vesa;
+   struct {
+   bool sdr_uses_aux;
+   } intel;
+   } edp;
 
struct {
int (*setup)(struct intel_connector *connector, enum 
pipe pipe);
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..aa1429302db70 100644
--- a/drivers/gpu/drm/i915/display/intel_dp_aux_backlight.c
+++ b/drivers/gpu/drm/i915/display/intel_dp_aux_backlight.c
@@ -22,10 +22,251 @@
  *
  */
 
+/*
+ * Laptops with Intel GPUs which have panels that support controlling the
+ * backlight through DP AUX can actually use two different interfaces: Intel's
+ * proprietary DP AUX backlight interface, and the standard VESA backlight
+ * interface. Unfortunately, at the time of writing this a lot of laptops will
+ * advertise support for the standard VESA backlight interface when they
+ * don't properly support it. However, on these systems the Intel backlight
+ * interface generally does work properly. Additionally, these systems will
+ * usually just indicate that they use PWM backlight controls in their VBIOS
+ * for some reason.
+ */
+
 #include "intel_display_types.h"
 #include "intel_dp_aux_backlight.h"
+#include "intel_panel.h"
+
+/* TODO:
+ * Implement HDR, right now we just implement the bare minimum to bring us 
back into SDR mode so we
+

[Intel-gfx] [RFC 0/5] drm/i915: Add support for Intel's eDP backlight controls

2020-09-15 Thread Lyude Paul

A while ago we ran into issues while trying to enable the eDP backlight
control interface as defined by VESA, in order to make the DPCD
backlight controls on newer laptop panels work. The issue ended up being
much more complicated however, as we also apparently needed to add
support for an Intel-specific DPCD backlight control interface as the
VESA interface is broken on many laptop panels. For lack of a better
name, we just call this the Intel HDR backlight interface.

While this only adds support for the SDR backlight mode (I think), this
will fix a lot of user's laptop panels that we weren't able to properly
automatically detect DPCD backlight controls on previously.

Lyude Paul (5):
  drm/i915/dp: Program source OUI on eDP panels
  drm/i915: Rename pwm_* backlight callbacks to ext_pwm_*
  drm/i915: Keep track of pwm-related backlight hooks separately
  drm/i915: Enable Intel's HDR backlight interface (only SDR for now)
  drm/dp: Revert "drm/dp: Introduce EDID-based quirks"

 drivers/gpu/drm/drm_dp_helper.c   |  82 +--
 drivers/gpu/drm/drm_dp_mst_topology.c |   3 +-
 .../drm/i915/display/intel_display_types.h|  24 +-
 drivers/gpu/drm/i915/display/intel_dp.c   |  44 +-
 .../drm/i915/display/intel_dp_aux_backlight.c | 384 --
 drivers/gpu/drm/i915/display/intel_dp_mst.c   |   3 +-
 drivers/gpu/drm/i915/display/intel_panel.c| 476 ++
 drivers/gpu/drm/i915/display/intel_panel.h|   4 +
 drivers/gpu/drm/i915/display/intel_psr.c  |   2 +-
 drivers/gpu/drm/i915/i915_params.c|   2 +-
 include/drm/drm_dp_helper.h   |  21 +-
 11 files changed, 673 insertions(+), 372 deletions(-)

-- 
2.26.2

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH v2 10/18] drm/dp: Add drm_dp_downstream_{min, max}_tmds_clock()

2020-09-10 Thread Lyude Paul

On Thu, 2020-09-10 at 16:55 +0300, Ville Syrjälä wrote:
> On Tue, Sep 08, 2020 at 02:08:17PM -0400, Lyude Paul wrote:
> > On Fri, 2020-09-04 at 14:53 +0300, Ville Syrjala wrote:
> > > From: Ville SyrjÃƒÂ¤lÃƒÂ¤ 
> > > 
> > > Add helpers to get the TMDS clock limits for HDMI/DVI downstream
> > > facing ports.
> > > 
> > > Signed-off-by: Ville SyrjÃƒÂ¤lÃƒÂ¤ 
> > > ---
> > >  drivers/gpu/drm/drm_dp_helper.c | 116 
> > >  include/drm/drm_dp_helper.h |   6 ++
> > >  2 files changed, 122 insertions(+)
> > > 
> > > diff --git a/drivers/gpu/drm/drm_dp_helper.c
> > > b/drivers/gpu/drm/drm_dp_helper.c
> > > index 822a30e609ef..f567428f2aef 100644
> > > --- a/drivers/gpu/drm/drm_dp_helper.c
> > > +++ b/drivers/gpu/drm/drm_dp_helper.c
> > > @@ -643,6 +643,114 @@ int drm_dp_downstream_max_dotclock(const u8
> > > dpcd[DP_RECEIVER_CAP_SIZE],
> > >  }
> > >  EXPORT_SYMBOL(drm_dp_downstream_max_dotclock);
> > >  
> > > +/**
> > > + * drm_dp_downstream_max_tmds_clock() - extract downstream facing port
> > > max
> > > TMDS clock
> > > + * @dpcd: DisplayPort configuration data
> > > + * @port_cap: port capabilities
> > > + * @edid: EDID
> > > + *
> > > + * Returns HDMI/DVI downstream facing port max TMDS clock in kHz on
> > > success,
> > > + * or 0 if max TMDS clock not defined
> > > + */
> > > +int drm_dp_downstream_max_tmds_clock(const u8 dpcd[DP_RECEIVER_CAP_SIZE],
> > > +  const u8 port_cap[4],
> > > +  const struct edid *edid)
> > > +{
> > > + if (!drm_dp_is_branch(dpcd))
> > > + return 0;
> > > +
> > > + if (dpcd[DP_DPCD_REV] < 0x11) {
> > > + switch (dpcd[DP_DOWNSTREAMPORT_PRESENT] &
> > > DP_DWN_STRM_PORT_TYPE_MASK) {
> > > + case DP_DWN_STRM_PORT_TYPE_TMDS:
> > > + return 165000;
> > > + default:
> > > + return 0;
> > > + }
> > > + }
> > > +
> > > + switch (port_cap[0] & DP_DS_PORT_TYPE_MASK) {
> > > + case DP_DS_PORT_TYPE_DP_DUALMODE:
> > > + if (is_edid_digital_input_dp(edid))
> > > + return 0;
> > > + /*
> > > +  * It's left up to the driver to check the
> > > +  * DP dual mode adapter's max TMDS clock.
> > > +  *
> > > +  * Unfortunatley it looks like branch devices
> > > +  * may not fordward that the DP dual mode i2c
> > > +  * access so we just usually get i2c nak :(
> > > +  */
> > > + fallthrough;
> > > + case DP_DS_PORT_TYPE_HDMI:
> > > +  /*
> > > +   * We should perhaps assume 165 MHz when detailed cap
> > > +   * info is not available. But looks like many typical
> > > +   * branch devices fall into that category and so we'd
> > > +   * probably end up with users complaining that they can't
> > > +   * get high resolution modes with their favorite dongle.
> > > +   *
> > > +   * So let's limit to 300 MHz instead since DPCD 1.4
> > > +       * HDMI 2.0 DFPs are required to have the detailed cap
> > > +   * info. So it's more likely we're dealing with a HDMI 1.4
> > > +   * compatible* device here.
> > 
> > Forgot to mention - not directly related to this series, there's some hidden
> > i2c bits that I think can also be probed for this sort of information on
> > passive adapters, I know amdgpu actually supports this. I wonder how many of
> > them also apply to older active adapters...
> 
> Something other than the normal DP dual mode stuff?
Actually that -may- have been what I was thinking of but I'm not sure, I'd
probably need to look through DAL to find out
> 
-- 
Sincerely,
  Lyude Paul (she/her)
  Software Engineer at Red Hat

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH v2 07/18] drm/dp: Pimp drm_dp_downstream_max_bpc()

2020-09-10 Thread Lyude Paul

On Thu, 2020-09-10 at 17:46 +0300, Ville Syrjälä wrote:
> On Tue, Sep 08, 2020 at 01:51:56PM -0400, Lyude Paul wrote:
> > On Fri, 2020-09-04 at 14:53 +0300, Ville Syrjala wrote:
> > > From: Ville SyrjÃƒÂ¤lÃƒÂ¤ 
> > > 
> > > Deal with more cases in drm_dp_downstream_max_bpc():
> > > - DPCD 1.0 -> assume 8bpc for non-DP
> > > - DPCD 1.1+ DP (or DP++ with DP sink) -> allow anything
> > > - DPCD 1.1+ TMDS -> check the caps, assume 8bpc if the value is crap
> > > - anything else -> assume 8bpc
> > > 
> > > Signed-off-by: Ville SyrjÃƒÂ¤lÃƒÂ¤ 
> > > ---
> > >  drivers/gpu/drm/drm_dp_helper.c   | 69 +++
> > >  .../drm/i915/display/intel_display_debugfs.c  |  3 +-
> > >  drivers/gpu/drm/i915/display/intel_dp.c   |  2 +-
> > >  include/drm/drm_dp_helper.h   | 10 ++-
> > >  4 files changed, 51 insertions(+), 33 deletions(-)
> > > 
> > > diff --git a/drivers/gpu/drm/drm_dp_helper.c
> > > b/drivers/gpu/drm/drm_dp_helper.c
> > > index 0fcb94f7dbe5..ab87209c25d8 100644
> > > --- a/drivers/gpu/drm/drm_dp_helper.c
> > > +++ b/drivers/gpu/drm/drm_dp_helper.c
> > > @@ -653,36 +653,44 @@ int drm_dp_downstream_max_clock(const u8
> > > dpcd[DP_RECEIVER_CAP_SIZE],
> > >  EXPORT_SYMBOL(drm_dp_downstream_max_clock);
> > >  
> > >  /**
> > > - * drm_dp_downstream_max_bpc() - extract branch device max
> > > - *   bits per component
> > > - * @dpcd: DisplayPort configuration data
> > > - * @port_cap: port capabilities
> > > - *
> > > - * See also:
> > > - * drm_dp_read_downstream_info()
> > > - * drm_dp_downstream_max_clock()
> > > - *
> > > - * Returns: Max bpc on success or 0 if max bpc not defined
> > > - */
> > > +  * drm_dp_downstream_max_bpc() - extract downstream facing port max
> > > +  *   bits per component
> > > +  * @dpcd: DisplayPort configuration data
> > > +  * @port_cap: downstream facing port capabilities
> > > +  * @edid: EDID
> > > +  *
> > > +  * Returns max bpc on success or 0 if max bpc not defined
> > > +  */
> > >  int drm_dp_downstream_max_bpc(const u8 dpcd[DP_RECEIVER_CAP_SIZE],
> > > -   const u8 port_cap[4])
> > > +   const u8 port_cap[4],
> > > +   const struct edid *edid)
> > >  {
> > > - int type = port_cap[0] & DP_DS_PORT_TYPE_MASK;
> > > - bool detailed_cap_info = dpcd[DP_DOWNSTREAMPORT_PRESENT] &
> > > - DP_DETAILED_CAP_INFO_AVAILABLE;
> > > - int bpc;
> > > -
> > > - if (!detailed_cap_info)
> > 
> > I don't think we can drop this check. There's a somewhat surprising blurb
> > about downstream port caps in the DP 2.0 spec (section 5.3.3.1):
> > 
> >In addition, the adapter shall set the Detailed Capabilities Info
> > registers
> >(DPCD Addresses 00080h through 0008Fh) to show all the downstream types,
> >including DFP 0. Either one or four bytes are used, per DFP type
> >indication. Therefore, up to 16 (with 1-byte descriptor) or four (with 4-
> >byte descriptor) DFP capabilities can be stored.
> > 
> > I've never once actually seen a sink do this, but this does mean it's
> > technically possible tthat if we don't check the detailed caps bit then we
> > might end up reading another port's DFP type instead of max_bpc info. Note
> > though that we can make the assumption the four byte version of the field is
> > used for DP 1.4+
> 
> The check is now ...
> 
> 
> > > + if (!drm_dp_is_branch(dpcd))
> > >   return 0;
> > >  
> > > - switch (type) {
> > > - case DP_DS_PORT_TYPE_VGA:
> > > - case DP_DS_PORT_TYPE_DVI:
> > > - case DP_DS_PORT_TYPE_HDMI:
> > > + if (dpcd[DP_DPCD_REV] < 0x11) {
> > > + switch (dpcd[DP_DOWNSTREAMPORT_PRESENT] &
> > > DP_DWN_STRM_PORT_TYPE_MASK) {
> > > + case DP_DWN_STRM_PORT_TYPE_DP:
> > > + return 0;
> > > + default:
> > > + return 8;
> > > + }
> > > + }
> > > +
> > > + switch (port_cap[0] & DP_DS_PORT_TYPE_MASK) {
> > > + case DP_DS_PORT_TYPE_DP:
> > > + return 0;
> > >   case DP_DS_PORT_TYPE_DP_DUALMODE:
> > > - bpc = port_cap[2] & DP

Re: [Intel-gfx] [PATCH v2 00/18] drm/i915: Pimp DP DFP handling

2020-09-08 Thread Lyude Paul

With the nitpicks addressed (note there were a couple of other spots where we
wanted to use Return: in the kdocs, but I didn't bother pointing all of them
out), all but patch 07 is:

Reviewed-by: Lyude Paul 

On Fri, 2020-09-04 at 14:53 +0300, Ville Syrjala wrote:
> From: Ville Syrjälä 
> 
> Attempt to deal with DP downstream facing ports (DFP) more
> thoroughly. This involves reading more of the port caps
> and dealing with various clock/bpc limitations.
> 
> And we try to enable YCbCr 444->420 conversion for HDMI DFPs
> which could allow some 4k displays to actually use 4k on
> pre-icl hardware (which doesn't have native 420 output),
> assuming we don't run into some other hardware limits.
> 
> I dropped my earlier patches to also hook in the DP dual mode
> adapter probing since sadly I've not actually seen a DP->DP++
> dongle that passes through the i2c traffic for those.
> 
> Only pimped the SST side of things. Not sure what would
> be required to get it all working for MST.
> 
> Ville Syrjälä (18):
>   drm/dp: Dump downstream facing port caps
>   drm/i915/lspcon: Do not send infoframes to non-HDMI sinks
>   drm/dp: Define protocol converter DPCD registers
>   drm/dp: Define more downstream facing port caps
>   drm/i915: Reworkd DFP max bpc handling
>   drm/dp: Add helpers to identify downstream facing port types
>   drm/dp: Pimp drm_dp_downstream_max_bpc()
>   drm/dp: Redo drm_dp_downstream_max_clock() as
> drm_dp_downstream_max_dotclock()
>   drm/i915: Reworkd DP DFP clock handling
>   drm/dp: Add drm_dp_downstream_{min,max}_tmds_clock()
>   drm/i915: Deal with TMDS DFP clock limits
>   drm/i915: Configure DP 1.3+ protocol converted HDMI mode
>   drm/dp: Add drm_dp_downstream_mode()
>   drm/i915: Handle downstream facing ports w/o EDID
>   drm/i915: Extract intel_hdmi_has_audio()
>   drm/i915: DP->HDMI TMDS clock limits vs. deep color
>   drm/dp: Add helpers for DFP YCbCr 4:2:0 handling
>   drm/i915: Do YCbCr 444->420 conversion via DP protocol converters
> 
>  drivers/gpu/drm/drm_dp_helper.c   | 382 +++---
>  drivers/gpu/drm/drm_edid.c|  19 +
>  drivers/gpu/drm/i915/display/intel_ddi.c  |  11 +-
>  .../drm/i915/display/intel_display_debugfs.c  |   3 +-
>  .../drm/i915/display/intel_display_types.h|   9 +
>  drivers/gpu/drm/i915/display/intel_dp.c   | 304 +++---
>  drivers/gpu/drm/i915/display/intel_dp.h   |   1 +
>  drivers/gpu/drm/i915/display/intel_hdmi.c |  82 ++--
>  drivers/gpu/drm/i915/display/intel_hdmi.h |   2 +
>  include/drm/drm_dp_helper.h       |  63 ++-
>  include/drm/drm_edid.h|   4 +
>  11 files changed, 738 insertions(+), 142 deletions(-)
> 
-- 
Cheers,
Lyude Paul (she/her)
Software Engineer at Red Hat

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH v2 17/18] drm/dp: Add helpers for DFP YCbCr 4:2:0 handling

2020-09-08 Thread Lyude Paul

On Fri, 2020-09-04 at 14:53 +0300, Ville Syrjala wrote:
> From: Ville Syrjälä 
> 
> Add helpers to determine whether the DFP supports
> YCbCr 4:2:0 passthrough or YCbCr 4:4:4->4:2:0 conversion.
> 
> Signed-off-by: Ville Syrjälä 
> ---
>  drivers/gpu/drm/drm_dp_helper.c | 44 +
>  include/drm/drm_dp_helper.h |  8 ++
>  2 files changed, 52 insertions(+)
> 
> diff --git a/drivers/gpu/drm/drm_dp_helper.c
> b/drivers/gpu/drm/drm_dp_helper.c
> index 0d5e9bcf11d0..dc68e10aa1fd 100644
> --- a/drivers/gpu/drm/drm_dp_helper.c
> +++ b/drivers/gpu/drm/drm_dp_helper.c
> @@ -808,6 +808,50 @@ int drm_dp_downstream_max_bpc(const u8
> dpcd[DP_RECEIVER_CAP_SIZE],
>  }
>  EXPORT_SYMBOL(drm_dp_downstream_max_bpc);
>  
> +bool drm_dp_downstream_420_passthrough(const u8 dpcd[DP_RECEIVER_CAP_SIZE],
> +const u8 port_cap[4])
> +{
> + if (!drm_dp_is_branch(dpcd))
> + return false;
> +
> + if (dpcd[DP_DPCD_REV] < 0x13)
> + return false;
> +
> + switch (port_cap[0] & DP_DS_PORT_TYPE_MASK) {
> + case DP_DS_PORT_TYPE_DP:
> + return true;
> + case DP_DS_PORT_TYPE_HDMI:
> + if ((dpcd[DP_DOWNSTREAMPORT_PRESENT] &
> DP_DETAILED_CAP_INFO_AVAILABLE) == 0)
> + return false;
> +
> + return port_cap[3] & DP_DS_HDMI_YCBCR420_PASS_THROUGH;
> + default:
> + return false;
> + }
> +}
> +EXPORT_SYMBOL(drm_dp_downstream_420_passthrough);

Forgot the kdocs again

> +
> +bool drm_dp_downstream_444_to_420_conversion(const u8
> dpcd[DP_RECEIVER_CAP_SIZE],
> +  const u8 port_cap[4])
> +{
> + if (!drm_dp_is_branch(dpcd))
> + return false;
> +
> + if (dpcd[DP_DPCD_REV] < 0x13)
> + return false;
> +
> + switch (port_cap[0] & DP_DS_PORT_TYPE_MASK) {
> + case DP_DS_PORT_TYPE_HDMI:
> + if ((dpcd[DP_DOWNSTREAMPORT_PRESENT] &
> DP_DETAILED_CAP_INFO_AVAILABLE) == 0)
> + return false;
> +
> + return port_cap[3] & DP_DS_HDMI_YCBCR444_TO_420_CONV;
> + default:
> + return false;
> + }
> +}
> +EXPORT_SYMBOL(drm_dp_downstream_444_to_420_conversion);
> +
>  /**
>   * drm_dp_downstream_mode() - return a mode for downstream facing port
>   * @dpcd: DisplayPort configuration data
> diff --git a/include/drm/drm_dp_helper.h b/include/drm/drm_dp_helper.h
> index fbba4a0f7366..c9f2851904d0 100644
> --- a/include/drm/drm_dp_helper.h
> +++ b/include/drm/drm_dp_helper.h
> @@ -407,6 +407,10 @@ struct drm_device;
>  # define DP_DS_DVI_HIGH_COLOR_DEPTH  (1 << 2)
>  /* offset 3 for HDMI */
>  # define DP_DS_HDMI_FRAME_SEQ_TO_FRAME_PACK (1 << 0)
> +# define DP_DS_HDMI_YCBCR422_PASS_THROUGH   (1 << 1)
> +# define DP_DS_HDMI_YCBCR420_PASS_THROUGH   (1 << 2)
> +# define DP_DS_HDMI_YCBCR444_TO_422_CONV(1 << 3)
> +# define DP_DS_HDMI_YCBCR444_TO_420_CONV(1 << 4)
>  
>  #define DP_MAX_DOWNSTREAM_PORTS  0x10
>  
> @@ -1663,6 +1667,10 @@ int drm_dp_downstream_min_tmds_clock(const u8
> dpcd[DP_RECEIVER_CAP_SIZE],
>  int drm_dp_downstream_max_bpc(const u8 dpcd[DP_RECEIVER_CAP_SIZE],
> const u8 port_cap[4],
> const struct edid *edid);
> +bool drm_dp_downstream_420_passthrough(const u8 dpcd[DP_RECEIVER_CAP_SIZE],
> +const u8 port_cap[4]);
> +bool drm_dp_downstream_444_to_420_conversion(const u8
> dpcd[DP_RECEIVER_CAP_SIZE],
> +  const u8 port_cap[4]);
>  struct drm_display_mode *drm_dp_downstream_mode(struct drm_device *dev,
>   const u8
> dpcd[DP_RECEIVER_CAP_SIZE],
>   const u8 port_cap[4]);
-- 
Cheers,
Lyude Paul (she/her)
Software Engineer at Red Hat

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH v2 13/18] drm/dp: Add drm_dp_downstream_mode()

2020-09-08 Thread Lyude Paul

20x1080i_60(3 << 4)
> +# define DP_DS_NON_EDID_1920x1080i_50(4 << 4)
> +# define DP_DS_NON_EDID_1280x720_60  (5 << 4)
> +# define DP_DS_NON_EDID_1280x720_50  (7 << 4)
>  /* offset 1 for VGA is maximum megapixels per second / 8 */
>  /* offset 1 for DVI/HDMI is maximum TMDS clock in Mbps / 2.5 */
>  /* offset 2 for VGA/DVI/HDMI */
> @@ -1654,6 +1663,9 @@ int drm_dp_downstream_min_tmds_clock(const u8
> dpcd[DP_RECEIVER_CAP_SIZE],
>  int drm_dp_downstream_max_bpc(const u8 dpcd[DP_RECEIVER_CAP_SIZE],
> const u8 port_cap[4],
> const struct edid *edid);
> +struct drm_display_mode *drm_dp_downstream_mode(struct drm_device *dev,
> + const u8
> dpcd[DP_RECEIVER_CAP_SIZE],
> + const u8 port_cap[4]);
>  int drm_dp_downstream_id(struct drm_dp_aux *aux, char id[6]);
>  void drm_dp_downstream_debug(struct seq_file *m,
>const u8 dpcd[DP_RECEIVER_CAP_SIZE],
> diff --git a/include/drm/drm_edid.h b/include/drm/drm_edid.h
> index cfa4f5af49af..b27a0e2169c8 100644
> --- a/include/drm/drm_edid.h
> +++ b/include/drm/drm_edid.h
> @@ -517,4 +517,8 @@ void drm_edid_get_monitor_name(struct edid *edid, char
> *name,
>  struct drm_display_mode *drm_mode_find_dmt(struct drm_device *dev,
>  int hsize, int vsize, int fresh,
>  bool rb);
> +struct drm_display_mode *
> +drm_display_mode_from_cea_vic(struct drm_device *dev,
> +   u8 video_code);
> +
>  #endif /* __DRM_EDID_H__ */
-- 
Cheers,
Lyude Paul (she/her)
Software Engineer at Red Hat

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH v2 12/18] drm/i915: Configure DP 1.3+ protocol converted HDMI mode

2020-09-08 Thread Lyude Paul

On Fri, 2020-09-04 at 14:53 +0300, Ville Syrjala wrote:
> From: Ville Syrjälä 
> 
> DP 1.3 adds some extra control knobs for DP->HDMI protocol conversion.
> Let's use that to configure the "HDMI mode" (ie. infoframes vs. not)
> based on the capabilities of the sink.
> 
> Signed-off-by: Ville Syrjälä 
> ---
>  drivers/gpu/drm/i915/display/intel_ddi.c |  1 +
>  drivers/gpu/drm/i915/display/intel_dp.c  | 23 +++
>  drivers/gpu/drm/i915/display/intel_dp.h  |  1 +
>  3 files changed, 25 insertions(+)
> 
> diff --git a/drivers/gpu/drm/i915/display/intel_ddi.c
> b/drivers/gpu/drm/i915/display/intel_ddi.c
> index 28ff85493f25..9adba0d0b4aa 100644
> --- a/drivers/gpu/drm/i915/display/intel_ddi.c
> +++ b/drivers/gpu/drm/i915/display/intel_ddi.c
> @@ -3470,6 +3470,7 @@ static void hsw_ddi_pre_enable_dp(struct
> intel_atomic_state *state,
>   intel_ddi_init_dp_buf_reg(encoder);
>   if (!is_mst)
>   intel_dp_sink_dpms(intel_dp, DRM_MODE_DPMS_ON);
> + intel_dp_configure_protocol_converter(intel_dp);
>   intel_dp_sink_set_decompression_state(intel_dp, crtc_state,
> true);
>   intel_dp_sink_set_fec_ready(intel_dp, crtc_state);
> diff --git a/drivers/gpu/drm/i915/display/intel_dp.c
> b/drivers/gpu/drm/i915/display/intel_dp.c
> index a703e4659e47..047449253a54 100644
> --- a/drivers/gpu/drm/i915/display/intel_dp.c
> +++ b/drivers/gpu/drm/i915/display/intel_dp.c
> @@ -3792,6 +3792,28 @@ static void intel_dp_enable_port(struct intel_dp
> *intel_dp,
>   intel_de_posting_read(dev_priv, intel_dp->output_reg);
>  }
>  
> +void intel_dp_configure_protocol_converter(struct intel_dp *intel_dp)
> +{
> + struct drm_i915_private *i915 = dp_to_i915(intel_dp);
> + u8 tmp;
> +
> + if (intel_dp->dpcd[DP_DPCD_REV] < 0x13)
> + return;
> +
> + if (!drm_dp_is_branch(intel_dp->dpcd))
> + return;
> +
> + tmp = intel_dp->has_hdmi_sink ?
> + DP_HDMI_DVI_OUTPUT_CONFIG : 0;
> +
> + if (drm_dp_dpcd_writeb(_dp->aux,
> +DP_PROTOCOL_CONVERTER_CONTROL_0, tmp) <= 0)
> + drm_dbg_kms(>drm, "Failed to set protocol converter HDMI
> mode to %s\n",
> + enableddisabled(intel_dp->has_hdmi_sink));
> +
> + /* TODO: configure YCbCr 4:2:2/4:2:0 conversion */
> +}

Maybe add a DP helper for this while we're at it? Up to you

> +
>  static void intel_enable_dp(struct intel_atomic_state *state,
>   struct intel_encoder *encoder,
>   const struct intel_crtc_state *pipe_config,
> @@ -3829,6 +3851,7 @@ static void intel_enable_dp(struct intel_atomic_state
> *state,
>   }
>  
>   intel_dp_sink_dpms(intel_dp, DRM_MODE_DPMS_ON);
> + intel_dp_configure_protocol_converter(intel_dp);
>   intel_dp_start_link_train(intel_dp);
>   intel_dp_stop_link_train(intel_dp);
>  
> diff --git a/drivers/gpu/drm/i915/display/intel_dp.h
> b/drivers/gpu/drm/i915/display/intel_dp.h
> index ec5688a21f66..08a1c0aa8b94 100644
> --- a/drivers/gpu/drm/i915/display/intel_dp.h
> +++ b/drivers/gpu/drm/i915/display/intel_dp.h
> @@ -51,6 +51,7 @@ int intel_dp_get_link_train_fallback_values(struct
> intel_dp *intel_dp,
>  int intel_dp_retrain_link(struct intel_encoder *encoder,
> struct drm_modeset_acquire_ctx *ctx);
>  void intel_dp_sink_dpms(struct intel_dp *intel_dp, int mode);
> +void intel_dp_configure_protocol_converter(struct intel_dp *intel_dp);
>  void intel_dp_sink_set_decompression_state(struct intel_dp *intel_dp,
>  const struct intel_crtc_state
> *crtc_state,
>  bool enable);
-- 
Cheers,
Lyude Paul (she/her)
Software Engineer at Red Hat

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH v2 10/18] drm/dp: Add drm_dp_downstream_{min, max}_tmds_clock()

2020-09-08 Thread Lyude Paul

   return 0;
> + }
> + }
> +
> + switch (port_cap[0] & DP_DS_PORT_TYPE_MASK) {
> + case DP_DS_PORT_TYPE_DP_DUALMODE:
> + if (is_edid_digital_input_dp(edid))
> + return 0;
> + fallthrough;
> + case DP_DS_PORT_TYPE_DVI:
> + case DP_DS_PORT_TYPE_HDMI:
> + /*
> +  * Unclear whether the protocol converter could
> +  * utilize pixel replication. Assume it won't.
> +  */
> + return 25000;
> + default:
> + return 0;
> + }
> +}
> +EXPORT_SYMBOL(drm_dp_downstream_min_tmds_clock);
> +
>  /**
>* drm_dp_downstream_max_bpc() - extract downstream facing port max
>*   bits per component
> @@ -788,6 +896,14 @@ void drm_dp_downstream_debug(struct seq_file *m,
>   if (clk > 0)
>   seq_printf(m, "\t\tMax dot clock: %d kHz\n", clk);
>  
> + clk = drm_dp_downstream_max_tmds_clock(dpcd, port_cap, edid);
> + if (clk > 0)
> + seq_printf(m, "\t\tMax TMDS clock: %d kHz\n", clk);
> +
> + clk = drm_dp_downstream_min_tmds_clock(dpcd, port_cap, edid);
> + if (clk > 0)
> + seq_printf(m, "\t\tMin TMDS clock: %d kHz\n", clk);
> +
>   bpc = drm_dp_downstream_max_bpc(dpcd, port_cap, edid);
>  
>   if (bpc > 0)
> diff --git a/include/drm/drm_dp_helper.h b/include/drm/drm_dp_helper.h
> index 19bc04207788..6812a3e0de8d 100644
> --- a/include/drm/drm_dp_helper.h
> +++ b/include/drm/drm_dp_helper.h
> @@ -1645,6 +1645,12 @@ bool drm_dp_downstream_is_tmds(const u8
> dpcd[DP_RECEIVER_CAP_SIZE],
>  const struct edid *edid);
>  int drm_dp_downstream_max_dotclock(const u8 dpcd[DP_RECEIVER_CAP_SIZE],
>  const u8 port_cap[4]);
> +int drm_dp_downstream_max_tmds_clock(const u8 dpcd[DP_RECEIVER_CAP_SIZE],
> +  const u8 port_cap[4],
> +  const struct edid *edid);
> +int drm_dp_downstream_min_tmds_clock(const u8 dpcd[DP_RECEIVER_CAP_SIZE],
> +  const u8 port_cap[4],
> +  const struct edid *edid);
>  int drm_dp_downstream_max_bpc(const u8 dpcd[DP_RECEIVER_CAP_SIZE],
> const u8 port_cap[4],
> const struct edid *edid);
-- 
Cheers,
Lyude Paul (she/her)
Software Engineer at Red Hat

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH v2 10/18] drm/dp: Add drm_dp_downstream_{min, max}_tmds_clock()

2020-09-08 Thread Lyude Paul

gt; + default:
> + return 0;
> + }
> + }
> +
> + switch (port_cap[0] & DP_DS_PORT_TYPE_MASK) {
> + case DP_DS_PORT_TYPE_DP_DUALMODE:
> + if (is_edid_digital_input_dp(edid))
> + return 0;
> + fallthrough;
> + case DP_DS_PORT_TYPE_DVI:
> + case DP_DS_PORT_TYPE_HDMI:
> + /*
> +  * Unclear whether the protocol converter could
> +  * utilize pixel replication. Assume it won't.
> +  */
> + return 25000;
> + default:
> + return 0;
> + }
> +}
> +EXPORT_SYMBOL(drm_dp_downstream_min_tmds_clock);
> +
>  /**
>* drm_dp_downstream_max_bpc() - extract downstream facing port max
>*   bits per component
> @@ -788,6 +896,14 @@ void drm_dp_downstream_debug(struct seq_file *m,
>   if (clk > 0)
>   seq_printf(m, "\t\tMax dot clock: %d kHz\n", clk);
>  
> + clk = drm_dp_downstream_max_tmds_clock(dpcd, port_cap, edid);
> + if (clk > 0)
> + seq_printf(m, "\t\tMax TMDS clock: %d kHz\n", clk);
> +
> + clk = drm_dp_downstream_min_tmds_clock(dpcd, port_cap, edid);
> + if (clk > 0)
> + seq_printf(m, "\t\tMin TMDS clock: %d kHz\n", clk);
> +
>   bpc = drm_dp_downstream_max_bpc(dpcd, port_cap, edid);
>  
>   if (bpc > 0)
> diff --git a/include/drm/drm_dp_helper.h b/include/drm/drm_dp_helper.h
> index 19bc04207788..6812a3e0de8d 100644
> --- a/include/drm/drm_dp_helper.h
> +++ b/include/drm/drm_dp_helper.h
> @@ -1645,6 +1645,12 @@ bool drm_dp_downstream_is_tmds(const u8
> dpcd[DP_RECEIVER_CAP_SIZE],
>  const struct edid *edid);
>  int drm_dp_downstream_max_dotclock(const u8 dpcd[DP_RECEIVER_CAP_SIZE],
>  const u8 port_cap[4]);
> +int drm_dp_downstream_max_tmds_clock(const u8 dpcd[DP_RECEIVER_CAP_SIZE],
> +  const u8 port_cap[4],
> +  const struct edid *edid);
> +int drm_dp_downstream_min_tmds_clock(const u8 dpcd[DP_RECEIVER_CAP_SIZE],
> +  const u8 port_cap[4],
> +  const struct edid *edid);
>  int drm_dp_downstream_max_bpc(const u8 dpcd[DP_RECEIVER_CAP_SIZE],
> const u8 port_cap[4],
> const struct edid *edid);
-- 
Cheers,
Lyude Paul (she/her)
Software Engineer at Red Hat

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH v2 08/18] drm/dp: Redo drm_dp_downstream_max_clock() as drm_dp_downstream_max_dotclock()

2020-09-08 Thread Lyude Paul

in(max_dotclk, ds_max_dotclk);
> diff --git a/include/drm/drm_dp_helper.h b/include/drm/drm_dp_helper.h
> index 6218de1294c1..19bc04207788 100644
> --- a/include/drm/drm_dp_helper.h
> +++ b/include/drm/drm_dp_helper.h
> @@ -1643,8 +1643,8 @@ bool drm_dp_downstream_is_type(const u8
> dpcd[DP_RECEIVER_CAP_SIZE],
>  bool drm_dp_downstream_is_tmds(const u8 dpcd[DP_RECEIVER_CAP_SIZE],
>  const u8 port_cap[4],
>  const struct edid *edid);
> -int drm_dp_downstream_max_clock(const u8 dpcd[DP_RECEIVER_CAP_SIZE],
> - const u8 port_cap[4]);
> +int drm_dp_downstream_max_dotclock(const u8 dpcd[DP_RECEIVER_CAP_SIZE],
> +const u8 port_cap[4]);
>  int drm_dp_downstream_max_bpc(const u8 dpcd[DP_RECEIVER_CAP_SIZE],
> const u8 port_cap[4],
> const struct edid *edid);
-- 
Cheers,
Lyude Paul (she/her)
Software Engineer at Red Hat

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH v2 07/18] drm/dp: Pimp drm_dp_downstream_max_bpc()

2020-09-08 Thread Lyude Paul

eturn 8;
>   }
>  }
>  EXPORT_SYMBOL(drm_dp_downstream_max_bpc);
> @@ -717,12 +727,15 @@ EXPORT_SYMBOL(drm_dp_downstream_id);
>   * @m: pointer for debugfs file
>   * @dpcd: DisplayPort configuration data
>   * @port_cap: port capabilities
> + * @edid: EDID
>   * @aux: DisplayPort AUX channel
>   *
>   */
>  void drm_dp_downstream_debug(struct seq_file *m,
>const u8 dpcd[DP_RECEIVER_CAP_SIZE],
> -  const u8 port_cap[4], struct drm_dp_aux *aux)
> +  const u8 port_cap[4],
> +  const struct edid *edid,
> +  struct drm_dp_aux *aux)
>  {
>   bool detailed_cap_info = dpcd[DP_DOWNSTREAMPORT_PRESENT] &
>DP_DETAILED_CAP_INFO_AVAILABLE;
> @@ -789,7 +802,7 @@ void drm_dp_downstream_debug(struct seq_file *m,
>   seq_printf(m, "\t\tMax TMDS clock: %d kHz\n",
> clk);
>   }
>  
> - bpc = drm_dp_downstream_max_bpc(dpcd, port_cap);
> + bpc = drm_dp_downstream_max_bpc(dpcd, port_cap, edid);
>  
>   if (bpc > 0)
>   seq_printf(m, "\t\tMax bpc: %d\n", bpc);
> diff --git a/drivers/gpu/drm/i915/display/intel_display_debugfs.c
> b/drivers/gpu/drm/i915/display/intel_display_debugfs.c
> index 53a0a3d9a22d..0bf31f9a8af5 100644
> --- a/drivers/gpu/drm/i915/display/intel_display_debugfs.c
> +++ b/drivers/gpu/drm/i915/display/intel_display_debugfs.c
> @@ -626,6 +626,7 @@ static void intel_dp_info(struct seq_file *m,
>  {
>   struct intel_encoder *intel_encoder =
> intel_attached_encoder(intel_connector);
>   struct intel_dp *intel_dp = enc_to_intel_dp(intel_encoder);
> + const struct drm_property_blob *edid = intel_connector-
> >base.edid_blob_ptr;
>  
>   seq_printf(m, "\tDPCD rev: %x\n", intel_dp->dpcd[DP_DPCD_REV]);
>   seq_printf(m, "\taudio support: %s\n", yesno(intel_dp->has_audio));
> @@ -633,7 +634,7 @@ static void intel_dp_info(struct seq_file *m,
>   intel_panel_info(m, _connector->panel);
>  
>   drm_dp_downstream_debug(m, intel_dp->dpcd, intel_dp->downstream_ports,
> - _dp->aux);
> + edid ? edid->data : NULL, _dp->aux);
>  }
>  
>  static void intel_dp_mst_info(struct seq_file *m,
> diff --git a/drivers/gpu/drm/i915/display/intel_dp.c
> b/drivers/gpu/drm/i915/display/intel_dp.c
> index 2c8e82d97a34..c73b3efd84e0 100644
> --- a/drivers/gpu/drm/i915/display/intel_dp.c
> +++ b/drivers/gpu/drm/i915/display/intel_dp.c
> @@ -6071,7 +6071,7 @@ intel_dp_set_edid(struct intel_dp *intel_dp)
>  
>   intel_dp->dfp.max_bpc =
>   drm_dp_downstream_max_bpc(intel_dp->dpcd,
> -   intel_dp->downstream_ports);
> +   intel_dp->downstream_ports, edid);
>  
>   drm_dbg_kms(>drm, "[CONNECTOR:%d:%s] DFP max bpc %d\n",
>   connector->base.base.id, connector->base.name,
> diff --git a/include/drm/drm_dp_helper.h b/include/drm/drm_dp_helper.h
> index 4f946826dfce..6218de1294c1 100644
> --- a/include/drm/drm_dp_helper.h
> +++ b/include/drm/drm_dp_helper.h
> @@ -1646,10 +1646,14 @@ bool drm_dp_downstream_is_tmds(const u8
> dpcd[DP_RECEIVER_CAP_SIZE],
>  int drm_dp_downstream_max_clock(const u8 dpcd[DP_RECEIVER_CAP_SIZE],
>   const u8 port_cap[4]);
>  int drm_dp_downstream_max_bpc(const u8 dpcd[DP_RECEIVER_CAP_SIZE],
> -   const u8 port_cap[4]);
> +   const u8 port_cap[4],
> +       const struct edid *edid);
>  int drm_dp_downstream_id(struct drm_dp_aux *aux, char id[6]);
> -void drm_dp_downstream_debug(struct seq_file *m, const u8
> dpcd[DP_RECEIVER_CAP_SIZE],
> -  const u8 port_cap[4], struct drm_dp_aux *aux);
> +void drm_dp_downstream_debug(struct seq_file *m,
> +  const u8 dpcd[DP_RECEIVER_CAP_SIZE],
> +  const u8 port_cap[4],
> +  const struct edid *edid,
> +  struct drm_dp_aux *aux);
>  enum drm_mode_subconnector
>  drm_dp_subconnector_type(const u8 dpcd[DP_RECEIVER_CAP_SIZE],
>const u8 port_cap[4]);
-- 
Cheers,
Lyude Paul (she/her)
Software Engineer at Red Hat

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH v2 07/18] drm/dp: Pimp drm_dp_downstream_max_bpc()

2020-09-08 Thread Lyude Paul

ENT] &
>DP_DETAILED_CAP_INFO_AVAILABLE;
> @@ -789,7 +802,7 @@ void drm_dp_downstream_debug(struct seq_file *m,
>   seq_printf(m, "\t\tMax TMDS clock: %d kHz\n",
> clk);
>   }
>  
> - bpc = drm_dp_downstream_max_bpc(dpcd, port_cap);
> + bpc = drm_dp_downstream_max_bpc(dpcd, port_cap, edid);
>  
>   if (bpc > 0)
>   seq_printf(m, "\t\tMax bpc: %d\n", bpc);
> diff --git a/drivers/gpu/drm/i915/display/intel_display_debugfs.c
> b/drivers/gpu/drm/i915/display/intel_display_debugfs.c
> index 53a0a3d9a22d..0bf31f9a8af5 100644
> --- a/drivers/gpu/drm/i915/display/intel_display_debugfs.c
> +++ b/drivers/gpu/drm/i915/display/intel_display_debugfs.c
> @@ -626,6 +626,7 @@ static void intel_dp_info(struct seq_file *m,
>  {
>   struct intel_encoder *intel_encoder =
> intel_attached_encoder(intel_connector);
>   struct intel_dp *intel_dp = enc_to_intel_dp(intel_encoder);
> + const struct drm_property_blob *edid = intel_connector-
> >base.edid_blob_ptr;
>  
>   seq_printf(m, "\tDPCD rev: %x\n", intel_dp->dpcd[DP_DPCD_REV]);
>   seq_printf(m, "\taudio support: %s\n", yesno(intel_dp->has_audio));
> @@ -633,7 +634,7 @@ static void intel_dp_info(struct seq_file *m,
>   intel_panel_info(m, _connector->panel);
>  
>   drm_dp_downstream_debug(m, intel_dp->dpcd, intel_dp->downstream_ports,
> - _dp->aux);
> + edid ? edid->data : NULL, _dp->aux);
>  }
>  
>  static void intel_dp_mst_info(struct seq_file *m,
> diff --git a/drivers/gpu/drm/i915/display/intel_dp.c
> b/drivers/gpu/drm/i915/display/intel_dp.c
> index 2c8e82d97a34..c73b3efd84e0 100644
> --- a/drivers/gpu/drm/i915/display/intel_dp.c
> +++ b/drivers/gpu/drm/i915/display/intel_dp.c
> @@ -6071,7 +6071,7 @@ intel_dp_set_edid(struct intel_dp *intel_dp)
>  
>   intel_dp->dfp.max_bpc =
>   drm_dp_downstream_max_bpc(intel_dp->dpcd,
> -   intel_dp->downstream_ports);
> +   intel_dp->downstream_ports, edid);
>  
>   drm_dbg_kms(>drm, "[CONNECTOR:%d:%s] DFP max bpc %d\n",
>   connector->base.base.id, connector->base.name,
> diff --git a/include/drm/drm_dp_helper.h b/include/drm/drm_dp_helper.h
> index 4f946826dfce..6218de1294c1 100644
> --- a/include/drm/drm_dp_helper.h
> +++ b/include/drm/drm_dp_helper.h
> @@ -1646,10 +1646,14 @@ bool drm_dp_downstream_is_tmds(const u8
> dpcd[DP_RECEIVER_CAP_SIZE],
>  int drm_dp_downstream_max_clock(const u8 dpcd[DP_RECEIVER_CAP_SIZE],
>   const u8 port_cap[4]);
>  int drm_dp_downstream_max_bpc(const u8 dpcd[DP_RECEIVER_CAP_SIZE],
> -   const u8 port_cap[4]);
> +   const u8 port_cap[4],
> +       const struct edid *edid);
>  int drm_dp_downstream_id(struct drm_dp_aux *aux, char id[6]);
> -void drm_dp_downstream_debug(struct seq_file *m, const u8
> dpcd[DP_RECEIVER_CAP_SIZE],
> -  const u8 port_cap[4], struct drm_dp_aux *aux);
> +void drm_dp_downstream_debug(struct seq_file *m,
> +  const u8 dpcd[DP_RECEIVER_CAP_SIZE],
> +  const u8 port_cap[4],
> +  const struct edid *edid,
> +  struct drm_dp_aux *aux);
>  enum drm_mode_subconnector
>  drm_dp_subconnector_type(const u8 dpcd[DP_RECEIVER_CAP_SIZE],
>const u8 port_cap[4]);
-- 
Cheers,
Lyude Paul (she/her)
Software Engineer at Red Hat

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH v2 06/18] drm/dp: Add helpers to identify downstream facing port types

2020-09-08 Thread Lyude Paul

On Fri, 2020-09-04 at 14:53 +0300, Ville Syrjala wrote:
> From: Ville Syrjälä 
> 
> Add a few helpers to let us better identify which kind of DFP
> we're dealing with.
> 
> Signed-off-by: Ville Syrjälä 
> ---
>  drivers/gpu/drm/drm_dp_helper.c | 60 +
>  include/drm/drm_dp_helper.h |  5 +++
>  2 files changed, 65 insertions(+)
> 
> diff --git a/drivers/gpu/drm/drm_dp_helper.c
> b/drivers/gpu/drm/drm_dp_helper.c
> index c21bbfc3d714..0fcb94f7dbe5 100644
> --- a/drivers/gpu/drm/drm_dp_helper.c
> +++ b/drivers/gpu/drm/drm_dp_helper.c
> @@ -363,6 +363,66 @@ int drm_dp_dpcd_read_link_status(struct drm_dp_aux
> *aux,
>  }
>  EXPORT_SYMBOL(drm_dp_dpcd_read_link_status);
>  
> +static bool is_edid_digital_input_dp(const struct edid *edid)
> +{
> + return edid && edid->revision >= 4 &&
> + edid->input & DRM_EDID_INPUT_DIGITAL &&
> + (edid->input & DRM_EDID_DIGITAL_TYPE_MASK) ==
> DRM_EDID_DIGITAL_TYPE_DP;
> +}
> +
> +/**
> + * drm_dp_downstream_is_type() - is the downstream facing port of certain
> type?
> + * @dpcd: DisplayPort configuration data
> + * @port_cap: port capabilities
> + *
> + * Caveat: Only works with DPCD 1.1+ port caps.
> + *
> + * Returns whether the downstream facing port matches the type.

Nitpick: s/Returns/Returns:/ for kdoc purposes

> + */
> +bool drm_dp_downstream_is_type(const u8 dpcd[DP_RECEIVER_CAP_SIZE],
> +const u8 port_cap[4], u8 type)
> +{
> + return drm_dp_is_branch(dpcd) &&
> + dpcd[DP_DPCD_REV] >= 0x11 &&
> + (port_cap[0] & DP_DS_PORT_TYPE_MASK) == type;
> +}
> +EXPORT_SYMBOL(drm_dp_downstream_is_type);
> +
> +/**
> + * drm_dp_downstream_is_tmds() - is the downstream facing port TMDS?
> + * @dpcd: DisplayPort configuration data
> + * @port_cap: port capabilities
> + * @edid: EDID
> + *
> + * Returns whether the downstream facing port is TMDS (HDMI/DVI).

Same nitpick here

> + */
> +bool drm_dp_downstream_is_tmds(const u8 dpcd[DP_RECEIVER_CAP_SIZE],
> +const u8 port_cap[4],
> +const struct edid *edid)
> +{
> + if (dpcd[DP_DPCD_REV] < 0x11) {
> + switch (dpcd[DP_DOWNSTREAMPORT_PRESENT] &
> DP_DWN_STRM_PORT_TYPE_MASK) {
> + case DP_DWN_STRM_PORT_TYPE_TMDS:
> + return true;
> + default:
> + return false;
> + }
> + }
> +
> + switch (port_cap[0] & DP_DS_PORT_TYPE_MASK) {
> + case DP_DS_PORT_TYPE_DP_DUALMODE:
> + if (is_edid_digital_input_dp(edid))
> + return false;
> + fallthrough;
> + case DP_DS_PORT_TYPE_DVI:
> + case DP_DS_PORT_TYPE_HDMI:
> + return true;
> + default:
> + return false;
> + }
> +}
> +EXPORT_SYMBOL(drm_dp_downstream_is_tmds);
> +
>  /**
>   * drm_dp_send_real_edid_checksum() - send back real edid checksum value
>   * @aux: DisplayPort AUX channel
> diff --git a/include/drm/drm_dp_helper.h b/include/drm/drm_dp_helper.h
> index 86461a40066b..4f946826dfce 100644
> --- a/include/drm/drm_dp_helper.h
> +++ b/include/drm/drm_dp_helper.h
> @@ -1638,6 +1638,11 @@ bool drm_dp_send_real_edid_checksum(struct drm_dp_aux
> *aux,
>  int drm_dp_read_downstream_info(struct drm_dp_aux *aux,
>   const u8 dpcd[DP_RECEIVER_CAP_SIZE],
>   u8 downstream_ports[DP_MAX_DOWNSTREAM_PORTS]);
> +bool drm_dp_downstream_is_type(const u8 dpcd[DP_RECEIVER_CAP_SIZE],
> +const u8 port_cap[4], u8 type);
> +bool drm_dp_downstream_is_tmds(const u8 dpcd[DP_RECEIVER_CAP_SIZE],
> +const u8 port_cap[4],
> +const struct edid *edid);
>  int drm_dp_downstream_max_clock(const u8 dpcd[DP_RECEIVER_CAP_SIZE],
>   const u8 port_cap[4]);
>  int drm_dp_downstream_max_bpc(const u8 dpcd[DP_RECEIVER_CAP_SIZE],
-- 
Cheers,
Lyude Paul (she/her)
Software Engineer at Red Hat

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH v2 00/18] drm/i915: Pimp DP DFP handling

2020-09-04 Thread Lyude Paul

Will try to look at this today, if I don't have the time though I'll definitely
have the time on Tuesday

On Fri, 2020-09-04 at 14:53 +0300, Ville Syrjala wrote:
> From: Ville Syrjälä 
> 
> Attempt to deal with DP downstream facing ports (DFP) more
> thoroughly. This involves reading more of the port caps
> and dealing with various clock/bpc limitations.
> 
> And we try to enable YCbCr 444->420 conversion for HDMI DFPs
> which could allow some 4k displays to actually use 4k on
> pre-icl hardware (which doesn't have native 420 output),
> assuming we don't run into some other hardware limits.
> 
> I dropped my earlier patches to also hook in the DP dual mode
> adapter probing since sadly I've not actually seen a DP->DP++
> dongle that passes through the i2c traffic for those.
> 
> Only pimped the SST side of things. Not sure what would
> be required to get it all working for MST.
> 
> Ville Syrjälä (18):
>   drm/dp: Dump downstream facing port caps
>   drm/i915/lspcon: Do not send infoframes to non-HDMI sinks
>   drm/dp: Define protocol converter DPCD registers
>   drm/dp: Define more downstream facing port caps
>   drm/i915: Reworkd DFP max bpc handling
>   drm/dp: Add helpers to identify downstream facing port types
>   drm/dp: Pimp drm_dp_downstream_max_bpc()
>   drm/dp: Redo drm_dp_downstream_max_clock() as
> drm_dp_downstream_max_dotclock()
>   drm/i915: Reworkd DP DFP clock handling
>   drm/dp: Add drm_dp_downstream_{min,max}_tmds_clock()
>   drm/i915: Deal with TMDS DFP clock limits
>   drm/i915: Configure DP 1.3+ protocol converted HDMI mode
>   drm/dp: Add drm_dp_downstream_mode()
>   drm/i915: Handle downstream facing ports w/o EDID
>   drm/i915: Extract intel_hdmi_has_audio()
>   drm/i915: DP->HDMI TMDS clock limits vs. deep color
>   drm/dp: Add helpers for DFP YCbCr 4:2:0 handling
>   drm/i915: Do YCbCr 444->420 conversion via DP protocol converters
> 
>  drivers/gpu/drm/drm_dp_helper.c   | 382 +++---
>  drivers/gpu/drm/drm_edid.c|  19 +
>  drivers/gpu/drm/i915/display/intel_ddi.c  |  11 +-
>  .../drm/i915/display/intel_display_debugfs.c  |   3 +-
>  .../drm/i915/display/intel_display_types.h|   9 +
>  drivers/gpu/drm/i915/display/intel_dp.c   | 304 +++---
>  drivers/gpu/drm/i915/display/intel_dp.h   |   1 +
>  drivers/gpu/drm/i915/display/intel_hdmi.c |  82 ++--
>  drivers/gpu/drm/i915/display/intel_hdmi.h |   2 +
>  include/drm/drm_dp_helper.h   |  63 ++-
>  include/drm/drm_edid.h|   4 +
>  11 files changed, 738 insertions(+), 142 deletions(-)
> 
-- 
Sincerely,
  Lyude Paul (she/her)
  Software Engineer at Red Hat

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PULL] topic/nouveau-i915-dp-helpers-and-cleanup

2020-09-04 Thread Lyude Paul

On Fri, 2020-09-04 at 09:24 -0400, Rodrigo Vivi wrote:
> On Mon, Aug 31, 2020 at 07:38:57PM -0400, Lyude Paul wrote:
> > topic/nouveau-i915-dp-helpers-and-cleanup-2020-08-31-1:
> > UAPI Changes:
> > 
> > None
> > 
> > Cross-subsystem Changes:
> > 
> > * Moves a bunch of miscellaneous DP code from the i915 driver into a set
> >   of shared DRM DP helpers
> > 
> > Core Changes:
> > 
> > * New DRM DP helpers (see above)
> > 
> > Driver Changes:
> > 
> > * Implements usage of the aforementioned DP helpers in the nouveau
> >   driver, along with some other various HPD related cleanup for nouveau
> 
> was this picked-up on the nouveau side already?
> whenever that happens, please ping me so I can pull this to dinq.

Everything that's needed is in this topic branch
> 
> But a reminder that it has my ack to go to drm-misc or only to nouveau
> directly.
> 
> > The following changes since commit bfacb84993eb173c0ab53ca4dd6180f76f4dc176:
> > 
> >   drm: virtio: fix kconfig dependency warning (2020-08-31 08:55:02 +0200)
> > 
> > are available in the Git repository at:
> > 
> >   git://anongit.freedesktop.org/drm/drm-misc tags/topic/nouveau-i915-dp-
> > helpers-and-cleanup-2020-08-31-1
> > 
> > for you to fetch changes up to 79416e97dda0118b137302575a70a14259a27d7d:
> > 
> >   drm/nouveau/kms: Start using drm_dp_read_dpcd_caps() (2020-08-31 19:10:09
> > -0400)
> > 
> > 
> > UAPI Changes:
> > 
> > None
> > 
> > Cross-subsystem Changes:
> > 
> > * Moves a bunch of miscellaneous DP code from the i915 driver into a set
> >   of shared DRM DP helpers
> > 
> > Core Changes:
> > 
> > * New DRM DP helpers (see above)
> > 
> > Driver Changes:
> > 
> > * Implements usage of the aforementioned DP helpers in the nouveau
> >   driver, along with some other various HPD related cleanup for nouveau
> > 
> > 
> > Lyude Paul (20):
> >   drm/nouveau/kms: Fix some indenting in nouveau_dp_detect()
> >   drm/nouveau/kms/nv50-: Remove open-coded drm_dp_read_desc()
> >   drm/nouveau/kms/nv50-: Just use drm_dp_dpcd_read() in nouveau_dp.c
> >   drm/nouveau/kms/nv50-: Use macros for DP registers in nouveau_dp.c
> >   drm/nouveau/kms: Don't clear DP_MST_CTRL DPCD in nv50_mstm_new()
> >   drm/nouveau/kms: Search for encoders' connectors properly
> >   drm/nouveau/kms/nv50-: Use drm_dp_dpcd_(readb|writeb)() in
> > nv50_sor_disable()
> >   drm/nouveau/kms/nv50-: Refactor and cleanup DP HPD handling
> >   drm/i915/dp: Extract drm_dp_read_mst_cap()
> >   drm/nouveau/kms: Use new drm_dp_read_mst_cap() helper for checking MST
> > caps
> >   drm/nouveau/kms: Move drm_dp_cec_unset_edid() into
> > nouveau_connector_detect()
> >   drm/nouveau/kms: Only use hpd_work for reprobing in HPD paths
> >   drm/i915/dp: Extract drm_dp_read_downstream_info()
> >   drm/nouveau/kms/nv50-: Use downstream DP clock limits for mode
> > validation
> >   drm/i915/dp: Extract drm_dp_read_sink_count_cap()
> >   drm/i915/dp: Extract drm_dp_read_sink_count()
> >   drm/nouveau/kms/nv50-: Add support for DP_SINK_COUNT
> >   drm/nouveau/kms: Don't change EDID when it hasn't actually changed
> >   drm/i915/dp: Extract drm_dp_read_dpcd_caps()
> >   drm/nouveau/kms: Start using drm_dp_read_dpcd_caps()
> > 
> >  drivers/gpu/drm/drm_dp_helper.c | 187 -
> >  drivers/gpu/drm/drm_dp_mst_topology.c   |  22 ++
> >  drivers/gpu/drm/i915/display/intel_dp.c | 124 +++
> >  drivers/gpu/drm/i915/display/intel_dp.h |   1 -
> >  drivers/gpu/drm/i915/display/intel_lspcon.c |   2 +-
> >  drivers/gpu/drm/nouveau/dispnv04/dac.c  |   2 +-
> >  drivers/gpu/drm/nouveau/dispnv04/dfp.c  |   7 +-
> >  drivers/gpu/drm/nouveau/dispnv04/disp.c |  24 ++-
> >  drivers/gpu/drm/nouveau/dispnv04/disp.h |   4 +
> >  drivers/gpu/drm/nouveau/dispnv04/tvnv04.c   |   2 +-
> >  drivers/gpu/drm/nouveau/dispnv04/tvnv17.c   |   2 +-
> >  drivers/gpu/drm/nouveau/dispnv50/disp.c | 305 -
> > ---
> >  drivers/gpu/drm/nouveau/nouveau_connector.c | 132 +---
> >  drivers/gpu/drm/nouveau/nouveau_connector.h |   1 +
> >  drivers/gpu/drm/nouveau/nouveau_display.c   |  72 ++-
> >  drivers/gpu/drm/nouveau/nouveau_display.h   |   3 +-
> >  d

[Intel-gfx] [RESEND] Requests For Proposals for hosting XDC2021 are now open

2020-09-03 Thread Lyude Paul

(Including a bunch more emails in the To: that got missed the first time)

Hello everyone!

The X.org board is soliciting proposals to host XDC in 2021. Since
XDC2020 is being held virtually this year, we've decided to host in
either North America or Europe. However, the board is open to other
locations, especially if there's an interesting co-location with another
conference.

Of course though, due to the ongoing COVID-19 pandemic it's not yet
clear whether or not it will be possible to host XDC2021 in person.
Because of this, we would like to make it clear that sponsors should
prepare for both the possibility of an in person conference, and the
possibility of a virtual conference. We will work with organizers on
coming up with a deadline for deciding whether or not we'll be going
virtual, likely sometime around July.

If you're considering hosting XDC, we've assembled a wiki page with
what's generally expected and needed:

https://www.x.org/wiki/Events/RFP/

When submitting your proposal, please make sure to include at least the
key information about the potential location in question, possible dates
along with estimated costs. Proposals can be submitted to board at
foundation.x.org until the deadline of November 1st. Additionally, an
quirk early heads-up to the board if you're considering hosting would be
appreciated, in case we need to adjust the schedule a bit. Also, earlier
is better since there generally will be a bit of Q with organizers.

And if you just have some questions about what organizing XDC entails,
please feel free to chat with previous organizers, or someone from the
board.
-- 
Sincerely,
  Lyude Paul (she/her)
  Software Engineer at Red Hat

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

< 1 2 3 4 5 6 7 8 9 10 >

401 - 500 of 1283 matches

Mail list logo