[Intel-gfx] [RESEND RFC 18/18] drm/display/dp_mst: Move all payload info into the atomic state

[Lyude Paul]

Now that we've finally gotten rid of the non-atomic MST users leftover in
the kernel, we can finally get rid of all of the legacy payload code we
have and move as much as possible into the MST atomic state structs. The
main purpose of this is to make the MST code a lot less confusing to work
on, as there's a lot of duplicated logic that doesn't really need to be
here. As well, this should make introducing features like fallback link
retraining and DSC support far easier.

Since the old payload code was pretty gnarly and there's a Lot of changes
here, I expect this might be a bit difficult to review. So to make things
as easy as possible for reviewers, I'll sum up how both the old and new
code worked here (it took me a while to figure this out too!).

The old MST code basically worked by maintaining two different payload
tables - proposed_vcpis, and payloads. proposed_vcpis would hold the
modified payload we wanted to push to the topology, while payloads held the
payload table that was currently programmed in hardware. Modifications to
proposed_vcpis would be handled through drm_dp_allocate_vcpi(),
drm_dp_mst_deallocate_vcpi(), and drm_dp_mst_reset_vcpi_slots(). Then, they
would be pushed via drm_dp_mst_update_payload_step1() and
drm_dp_mst_update_payload_step2().

Furthermore, it's important to note how adding and removing VC payloads
actually worked with drm_dp_mst_update_payload_step1(). When a VC payload
is removed from the VC table, all VC payloads which come after the removed
VC payload's slots must have their time slots shifted towards the start of
the table. The old code handles this by looping through the entire payload
table and recomputing the start slot for every payload in the topology from
scratch. While very much overkill, this ends up doing the right thing
because we always order the VCPIs for payloads from first to last starting
timeslot.

It's important to also note that drm_dp_mst_update_payload_step2() isn't
actually limited to updating a single payload - the driver can use it to
queue up multiple payload changes so that as many of them can be sent as
possible before waiting for the ACT.

drm_dp_mst_update_payload_step2() is pretty self explanatory and basically
the same between the old and new code, save for the fact we don't have a
second step for deleting payloads anymore -and thus rename it to
drm_dp_mst_add_payload_step2().

The new payload code stores all of the current payload info within the MST
atomic state and computes as much of the state as possible ahead of time.
This has the one exception of the starting timeslots for payloads, which
can't be determined at atomic check time since the starting time slots will
vary depending on what order CRTCs are enabled in the atomic state - which
varies from driver to driver. These are still stored in the atomic MST
state, but are only copied from the old MST state during atomic commit
time. Likewise, this is when new start slots are determined.

Adding/removing payloads now works much more closely to how things are
described in the spec. When we delete a payload, we loop through the
current list of payloads and update the start slots for any payloads whose
time slots came after the payload we just deleted. Determining the starting
time slots for new payloads being added is done by simply keeping track of
where the end of the VC table is in
drm_dp_mst_topology_mgr->next_start_slot. Additionally, it's worth noting
that we no longer have a single update_payload() function. Instead, we now
have drm_dp_mst_add_payload_step1|2() and drm_dp_mst_remove_payload(). As
such, it's now left it up to the driver to figure out when to add or remove
payloads. The driver already knows when it's disabling/enabling CRTCs, so
it also already knows when payloads should be added or removed. And, this
doesn't interfere with the ability to queue up multiple payload changes
before waiting for the ACT.

Signed-off-by: Lyude Paul 
Cc: Wayne Lin 
Cc: Ville Syrjälä 
Cc: Fangzhi Zuo 
Cc: Jani Nikula 
Cc: Imre Deak 
Cc: Daniel Vetter 
Cc: Sean Paul 
---
 .../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c |  56 +-
 .../amd/display/amdgpu_dm/amdgpu_dm_helpers.c | 107 +--
 .../display/amdgpu_dm/amdgpu_dm_mst_types.c   |  85 +--
 .../amd/display/include/link_service_types.h  |   7 +
 drivers/gpu/drm/display/drm_dp_mst_topology.c | 699 ++
 drivers/gpu/drm/i915/display/intel_dp_mst.c   |  64 +-
 drivers/gpu/drm/i915/display/intel_hdcp.c |  24 +-
 drivers/gpu/drm/nouveau/dispnv50/disp.c   | 163 ++--
 include/drm/display/drm_dp_mst_helper.h   | 178 ++---
 9 files changed, 536 insertions(+), 847 deletions(-)

diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c 
b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
index ac8648e3c1c9..93d572ea3c48 100644
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
@@ -7378,6 +7378,7 @@ static int dm_encoder_helper_atomic_check(struct 
drm_enco

[Intel-gfx] [RESEND RFC 13/18] drm/display/dp_mst: Add helpers for serializing SST <-> MST transitions

[Lyude Paul]

There's another kind of situation where we could potentially race with
nonblocking modesets and MST, especially if we were to only use the locking
provided by atomic modesetting:

* Display 1 begins as enabled on DP-1 in SST mode
* Display 1 switches to MST mode, exposes one sink in MST mode
* Userspace does non-blocking modeset to disable the SST display
* Userspace does non-blocking modeset to enable the MST display with a
  different CRTC, but the SST display hasn't been fully taken down yet
* Execution order between the last two commits isn't guaranteed since they
  share no drm resources

We can fix this however, by ensuring that we always pull in the atomic
topology state whenever a connector capable of driving an MST display
performs its atomic check - and then tracking CRTC commits happening on the
SST connector in the MST topology state. So, let's add some simple helpers
for doing that and hook them up in various drivers.

Signed-off-by: Lyude Paul 
Cc: Wayne Lin 
Cc: Ville Syrjälä 
Cc: Fangzhi Zuo 
Cc: Jani Nikula 
Cc: Imre Deak 
Cc: Daniel Vetter 
Cc: Sean Paul 
---
 .../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c |  7 +++
 drivers/gpu/drm/display/drm_dp_mst_topology.c | 59 +++
 drivers/gpu/drm/i915/display/intel_dp.c   |  9 +++
 drivers/gpu/drm/nouveau/dispnv50/disp.c   |  2 +-
 drivers/gpu/drm/nouveau/dispnv50/disp.h   |  2 +
 drivers/gpu/drm/nouveau/nouveau_connector.c   | 14 +
 include/drm/display/drm_dp_mst_helper.h   |  2 +
 7 files changed, 94 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c 
b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
index d9c7393ef151..ac8648e3c1c9 100644
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
@@ -7177,10 +7177,17 @@ amdgpu_dm_connector_atomic_check(struct drm_connector 
*conn,
drm_atomic_get_old_connector_state(state, conn);
struct drm_crtc *crtc = new_con_state->crtc;
struct drm_crtc_state *new_crtc_state;
+   struct amdgpu_dm_connector *aconn = to_amdgpu_dm_connector(conn);
int ret;
 
trace_amdgpu_dm_connector_atomic_check(new_con_state);
 
+   if (conn->connector_type == DRM_MODE_CONNECTOR_DisplayPort) {
+   ret = drm_dp_mst_root_conn_atomic_check(new_con_state, 
>mst_mgr);
+   if (ret < 0)
+   return ret;
+   }
+
if (!crtc)
return 0;
 
diff --git a/drivers/gpu/drm/display/drm_dp_mst_topology.c 
b/drivers/gpu/drm/display/drm_dp_mst_topology.c
index c5edcf2a26c8..a775f9437868 100644
--- a/drivers/gpu/drm/display/drm_dp_mst_topology.c
+++ b/drivers/gpu/drm/display/drm_dp_mst_topology.c
@@ -4608,6 +4608,65 @@ void drm_dp_mst_atomic_wait_for_dependencies(struct 
drm_atomic_state *state)
 }
 EXPORT_SYMBOL(drm_dp_mst_atomic_wait_for_dependencies);
 
+/**
+ * drm_dp_mst_root_conn_atomic_check() - Serialize CRTC commits on MST-capable 
connectors operating
+ * in SST mode
+ * @new_conn_state: The new connector state of the _connector
+ * @mgr: The MST topology manager for the _connector
+ *
+ * Since MST uses fake _encoder structs, the generic atomic modesetting 
code isn't able to
+ * serialize non-blocking commits happening on the real DP connector of an MST 
topology switching
+ * into/away from MST mode - as the CRTC on the real DP connector and the 
CRTCs on the connector's
+ * MST topology will never share the same _encoder.
+ *
+ * This function takes care of this serialization issue, by checking a root 
MST connector's atomic
+ * state to determine if it is about to have a modeset - and then pulling in 
the MST topology state
+ * if so, along with adding any relevant CRTCs to 
_dp_mst_topology_state.pending_crtc_mask.
+ *
+ * Drivers implementing MST must call this function from the
+ * _connector_helper_funcs.atomic_check hook of any physical DP 
_connector capable of
+ * driving MST sinks.
+ *
+ * Returns:
+ * 0 on success, negative error code otherwise
+ */
+int drm_dp_mst_root_conn_atomic_check(struct drm_connector_state 
*new_conn_state,
+ struct drm_dp_mst_topology_mgr *mgr)
+{
+   struct drm_atomic_state *state = new_conn_state->state;
+   struct drm_connector_state *old_conn_state =
+   drm_atomic_get_old_connector_state(state, 
new_conn_state->connector);
+   struct drm_crtc_state *crtc_state;
+   struct drm_dp_mst_topology_state *mst_state = NULL;
+
+   if (new_conn_state->crtc) {
+   crtc_state = drm_atomic_get_new_crtc_state(state, 
new_conn_state->crtc);
+   if (crtc_state && drm_atomic_crtc_needs_modeset(crtc_state)) {
+   mst_state = drm_atomic_get_mst_topology_state(state, 
mgr);
+   if (IS_ERR(mst_state))
+   return PTR_ERR(mst_state);
+
+   mst_state->

[Intel-gfx] [RESEND RFC 09/18] drm/display/dp_mst: Don't open code modeset checks for releasing time slots

[Lyude Paul]

I'm not sure why, but at the time I originally wrote the find/release time
slot helpers I thought we should avoid keeping modeset tracking out of the
MST helpers. In retrospect though there's no actual good reason to do
this, and the logic has ended up being identical across all the drivers
using the helpers. Also, it needs to be fixed anyway so we don't break
things when going atomic-only with MST.

So, let's just move this code into drm_dp_atomic_release_time_slots() and
stop open coding it.

Signed-off-by: Lyude Paul 
Cc: Wayne Lin 
Cc: Ville Syrjälä 
Cc: Fangzhi Zuo 
Cc: Jani Nikula 
Cc: Imre Deak 
Cc: Daniel Vetter 
Cc: Sean Paul 
---
 .../display/amdgpu_dm/amdgpu_dm_mst_types.c   | 29 +++
 drivers/gpu/drm/display/drm_dp_mst_topology.c | 21 --
 drivers/gpu/drm/i915/display/intel_dp_mst.c   | 24 +--
 drivers/gpu/drm/nouveau/dispnv50/disp.c   | 21 --
 4 files changed, 23 insertions(+), 72 deletions(-)

diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_mst_types.c 
b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_mst_types.c
index e40ff51e7be0..b447c453b58d 100644
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_mst_types.c
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_mst_types.c
@@ -353,34 +353,13 @@ dm_dp_mst_detect(struct drm_connector *connector,
 }
 
 static int dm_dp_mst_atomic_check(struct drm_connector *connector,
-   struct drm_atomic_state *state)
+ struct drm_atomic_state *state)
 {
-   struct drm_connector_state *new_conn_state =
-   drm_atomic_get_new_connector_state(state, connector);
-   struct drm_connector_state *old_conn_state =
-   drm_atomic_get_old_connector_state(state, connector);
struct amdgpu_dm_connector *aconnector = 
to_amdgpu_dm_connector(connector);
-   struct drm_crtc_state *new_crtc_state;
-   struct drm_dp_mst_topology_mgr *mst_mgr;
-   struct drm_dp_mst_port *mst_port;
+   struct drm_dp_mst_topology_mgr *mst_mgr = 
>mst_port->mst_mgr;
+   struct drm_dp_mst_port *mst_port = aconnector->port;
 
-   mst_port = aconnector->port;
-   mst_mgr = >mst_port->mst_mgr;
-
-   if (!old_conn_state->crtc)
-   return 0;
-
-   if (new_conn_state->crtc) {
-   new_crtc_state = drm_atomic_get_new_crtc_state(state, 
new_conn_state->crtc);
-   if (!new_crtc_state ||
-   !drm_atomic_crtc_needs_modeset(new_crtc_state) ||
-   new_crtc_state->enable)
-   return 0;
-   }
-
-   return drm_dp_atomic_release_time_slots(state,
-   mst_mgr,
-   mst_port);
+   return drm_dp_atomic_release_time_slots(state, mst_mgr, mst_port);
 }
 
 static const struct drm_connector_helper_funcs 
dm_dp_mst_connector_helper_funcs = {
diff --git a/drivers/gpu/drm/display/drm_dp_mst_topology.c 
b/drivers/gpu/drm/display/drm_dp_mst_topology.c
index a0ed29f83556..e73b34c0cc9e 100644
--- a/drivers/gpu/drm/display/drm_dp_mst_topology.c
+++ b/drivers/gpu/drm/display/drm_dp_mst_topology.c
@@ -4484,14 +4484,29 @@ int drm_dp_atomic_release_time_slots(struct 
drm_atomic_state *state,
 {
struct drm_dp_mst_topology_state *topology_state;
struct drm_dp_mst_atomic_payload *payload;
-   struct drm_connector_state *conn_state;
+   struct drm_connector_state *old_conn_state, *new_conn_state;
+
+   old_conn_state = drm_atomic_get_old_connector_state(state, 
port->connector);
+   if (!old_conn_state->crtc)
+   return 0;
+
+   /* If the CRTC isn't disabled by this state, don't release it's payload 
*/
+   new_conn_state = drm_atomic_get_new_connector_state(state, 
port->connector);
+   if (new_conn_state->crtc) {
+   struct drm_crtc_state *crtc_state =
+   drm_atomic_get_new_crtc_state(state, 
new_conn_state->crtc);
+
+   if (!crtc_state ||
+   !drm_atomic_crtc_needs_modeset(crtc_state) ||
+   crtc_state->enable)
+   return 0;
+   }
 
topology_state = drm_atomic_get_mst_topology_state(state, mgr);
if (IS_ERR(topology_state))
return PTR_ERR(topology_state);
 
-   conn_state = drm_atomic_get_old_connector_state(state, port->connector);
-   topology_state->pending_crtc_mask |= drm_crtc_mask(conn_state->crtc);
+   topology_state->pending_crtc_mask |= 
drm_crtc_mask(old_conn_state->crtc);
 
payload = drm_atomic_get_mst_payload_state(topology_state, port);
if (WARN_ON(!payload)) {
diff --git a/drivers/gpu/drm/i915/display/intel_dp_mst.c 
b/drivers/gpu/drm/i915/display/intel_dp_mst.c
index 0c922667398a..4b0af3c26176 100644
--- a/drivers/gpu/drm

[Intel-gfx] [RESEND RFC 08/18] drm/display/dp_mst: Add nonblocking helpers for DP MST

[Lyude Paul]

As Daniel Vetter pointed out, if we only use the atomic modesetting locks
with MST it's technically possible for a driver with non-blocking modesets
to race when it comes to MST displays - as we make the mistake of not doing
our own CRTC commit tracking in the topology_state object.

This could potentially cause problems if something like this happens:

* User starts non-blocking commit to disable CRTC-1 on MST topology 1
* User starts non-blocking commit to enable CRTC-2 on MST topology 1

There's no guarantee here that the commit for disabling CRTC-2 will only
occur after CRTC-1 has finished, since neither commit shares a CRTC - only
the private modesetting object for MST. Keep in mind this likely isn't a
problem for blocking modesets, only non-blocking.

So, begin fixing this by keeping track of which CRTCs on a topology have
changed by keeping track of which CRTCs we release or allocate timeslots
on. As well, add some helpers for:

* Setting up the drm_crtc_commit structs in the ->commit_setup hook
* Waiting for any CRTC dependencies from the previous topology state

Signed-off-by: Lyude Paul 
Cc: Wayne Lin 
Cc: Ville Syrjälä 
Cc: Fangzhi Zuo 
Cc: Jani Nikula 
Cc: Imre Deak 
Cc: Daniel Vetter 
Cc: Sean Paul 
---
 .../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c |  9 +-
 drivers/gpu/drm/display/drm_dp_mst_topology.c | 93 +++
 drivers/gpu/drm/i915/display/intel_display.c  | 11 +++
 drivers/gpu/drm/nouveau/dispnv50/disp.c   | 12 +++
 include/drm/display/drm_dp_mst_helper.h   | 15 +++
 5 files changed, 139 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c 
b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
index f84a4ad736d8..d9c7393ef151 100644
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
@@ -211,6 +211,7 @@ static int amdgpu_dm_encoder_init(struct drm_device *dev,
 static int amdgpu_dm_connector_get_modes(struct drm_connector *connector);
 
 static void amdgpu_dm_atomic_commit_tail(struct drm_atomic_state *state);
+static int amdgpu_dm_atomic_setup_commit(struct drm_atomic_state *state);
 
 static int amdgpu_dm_atomic_check(struct drm_device *dev,
  struct drm_atomic_state *state);
@@ -2808,7 +2809,8 @@ static const struct drm_mode_config_funcs 
amdgpu_dm_mode_funcs = {
 };
 
 static struct drm_mode_config_helper_funcs amdgpu_dm_mode_config_helperfuncs = 
{
-   .atomic_commit_tail = amdgpu_dm_atomic_commit_tail
+   .atomic_commit_tail = amdgpu_dm_atomic_commit_tail,
+   .atomic_commit_setup = amdgpu_dm_atomic_setup_commit,
 };
 
 static void update_connector_ext_caps(struct amdgpu_dm_connector *aconnector)
@@ -9558,6 +9560,7 @@ static void amdgpu_dm_atomic_commit_tail(struct 
drm_atomic_state *state)
DRM_ERROR("Waiting for fences timed out!");
 
drm_atomic_helper_update_legacy_modeset_state(dev, state);
+   drm_dp_mst_atomic_wait_for_dependencies(state);
 
dm_state = dm_atomic_get_new_state(state);
if (dm_state && dm_state->context) {
@@ -9958,6 +9961,10 @@ static void amdgpu_dm_atomic_commit_tail(struct 
drm_atomic_state *state)
dc_release_state(dc_state_temp);
 }
 
+static int amdgpu_dm_atomic_setup_commit(struct drm_atomic_state *state)
+{
+   return drm_dp_mst_atomic_setup_commit(state);
+}
 
 static int dm_force_atomic_commit(struct drm_connector *connector)
 {
diff --git a/drivers/gpu/drm/display/drm_dp_mst_topology.c 
b/drivers/gpu/drm/display/drm_dp_mst_topology.c
index 0bc2c7a90c37..a0ed29f83556 100644
--- a/drivers/gpu/drm/display/drm_dp_mst_topology.c
+++ b/drivers/gpu/drm/display/drm_dp_mst_topology.c
@@ -4395,12 +4395,16 @@ int drm_dp_atomic_find_time_slots(struct 
drm_atomic_state *state,
 {
struct drm_dp_mst_topology_state *topology_state;
struct drm_dp_mst_atomic_payload *payload = NULL;
+   struct drm_connector_state *conn_state;
int prev_slots = 0, prev_bw = 0, req_slots;
 
topology_state = drm_atomic_get_mst_topology_state(state, mgr);
if (IS_ERR(topology_state))
return PTR_ERR(topology_state);
 
+   conn_state = drm_atomic_get_new_connector_state(state, port->connector);
+   topology_state->pending_crtc_mask |= drm_crtc_mask(conn_state->crtc);
+
/* Find the current allocation for this port, if any */
payload = drm_atomic_get_mst_payload_state(topology_state, port);
if (payload) {
@@ -4480,11 +4484,15 @@ int drm_dp_atomic_release_time_slots(struct 
drm_atomic_state *state,
 {
struct drm_dp_mst_topology_state *topology_state;
struct drm_dp_mst_atomic_payload *payload;
+   struct drm_connector_state *conn_state;
 
topology_state = drm_atomic_get_mst_topology_state(state, mgr);
if (IS_ERR(topology_state))
return PTR_ERR(topology_state);
 
+   conn_state = drm_atomic_ge

[Intel-gfx] [RESEND RFC 04/18] drm/display/dp_mst: Call them time slots, not VCPI slots

[Lyude Paul]

VCPI is only sort of the correct term here, originally the majority of this
code simply referred to timeslots vaguely as "slots" - and since I started
working on it and adding atomic functionality, the name "VCPI slots" has
been used to represent time slots.

Now that we actually have consistent access to the DisplayPort spec thanks
to VESA, I now know this isn't actually the proper term - as the
specification refers to these as time slots.

Since we're trying to make this code as easy to figure out as possible,
let's take this opportunity to correct this nomenclature and call them by
their proper name - timeslots. Likewise, we rename various functions
appropriately, along with replacing references in the kernel documentation
and various debugging messages.

It's important to note that this patch series leaves the legacy MST code
untouched for the most part, which is fine since we'll be removing it soon
anyhow. There should be no functional changes in this series.

Signed-off-by: Lyude Paul 
Cc: Wayne Lin 
Cc: Ville Syrjälä 
Cc: Fangzhi Zuo 
Cc: Jani Nikula 
Cc: Imre Deak 
Cc: Daniel Vetter 
Cc: Sean Paul 
---
 .../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c |   2 +-
 .../display/amdgpu_dm/amdgpu_dm_mst_types.c   |  28 ++---
 drivers/gpu/drm/display/drm_dp_mst_topology.c | 106 +-
 drivers/gpu/drm/i915/display/intel_dp_mst.c   |   5 +-
 drivers/gpu/drm/nouveau/dispnv50/disp.c   |   4 +-
 include/drm/display/drm_dp_mst_helper.h   |   6 +-
 6 files changed, 75 insertions(+), 76 deletions(-)

diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c 
b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
index ad4571190a90..f84a4ad736d8 100644
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
@@ -7393,7 +7393,7 @@ static int dm_encoder_helper_atomic_check(struct 
drm_encoder *encoder,
clock = adjusted_mode->clock;
dm_new_connector_state->pbn = drm_dp_calc_pbn_mode(clock, bpp, 
false);
}
-   dm_new_connector_state->vcpi_slots = 
drm_dp_atomic_find_vcpi_slots(state,
+   dm_new_connector_state->vcpi_slots = 
drm_dp_atomic_find_time_slots(state,
   
mst_mgr,
   
mst_port,
   
dm_new_connector_state->pbn,
diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_mst_types.c 
b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_mst_types.c
index 9221b6690a4a..e40ff51e7be0 100644
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_mst_types.c
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_mst_types.c
@@ -378,7 +378,7 @@ static int dm_dp_mst_atomic_check(struct drm_connector 
*connector,
return 0;
}
 
-   return drm_dp_atomic_release_vcpi_slots(state,
+   return drm_dp_atomic_release_time_slots(state,
mst_mgr,
mst_port);
 }
@@ -689,7 +689,7 @@ static void increase_dsc_bpp(struct drm_atomic_state *state,
 
if (initial_slack[next_index] > fair_pbn_alloc) {
vars[next_index].pbn += fair_pbn_alloc;
-   if (drm_dp_atomic_find_vcpi_slots(state,
+   if (drm_dp_atomic_find_time_slots(state,
  
params[next_index].port->mgr,
  
params[next_index].port,
  vars[next_index].pbn,
@@ -699,7 +699,7 @@ static void increase_dsc_bpp(struct drm_atomic_state *state,
vars[next_index].bpp_x16 = 
bpp_x16_from_pbn(params[next_index], vars[next_index].pbn);
} else {
vars[next_index].pbn -= fair_pbn_alloc;
-   if (drm_dp_atomic_find_vcpi_slots(state,
+   if (drm_dp_atomic_find_time_slots(state,
  
params[next_index].port->mgr,
  
params[next_index].port,
  
vars[next_index].pbn,
@@ -708,7 +708,7 @@ static void increase_dsc_bpp(struct drm_atomic_state *state,
}
} else {
vars[next_index].pbn += initial_slack[next_index];
-   if (drm_dp_atomic_find_vcpi_slots(state,
+   if (drm_dp_atomic_find_time_slots(state,
  
params[next_index].port->mgr,
   

[Intel-gfx] [RFC 04/18] drm/display/dp_mst: Call them time slots, not VCPI slots

[Lyude Paul]

VCPI is only sort of the correct term here, originally the majority of this
code simply referred to timeslots vaguely as "slots" - and since I started
working on it and adding atomic functionality, the name "VCPI slots" has
been used to represent time slots.

Now that we actually have consistent access to the DisplayPort spec thanks
to VESA, I now know this isn't actually the proper term - as the
specification refers to these as time slots.

Since we're trying to make this code as easy to figure out as possible,
let's take this opportunity to correct this nomenclature and call them by
their proper name - timeslots. Likewise, we rename various functions
appropriately, along with replacing references in the kernel documentation
and various debugging messages.

It's important to note that this patch series leaves the legacy MST code
untouched for the most part, which is fine since we'll be removing it soon
anyhow. There should be no functional changes in this series.

Signed-off-by: Lyude Paul 
Cc: Wayne Lin 
Cc: Ville Syrjälä 
Cc: Fangzhi Zuo 
Cc: Jani Nikula 
Cc: Imre Deak 
Cc: Daniel Vetter 
Cc: Sean Paul 
---
 .../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c |   2 +-
 .../display/amdgpu_dm/amdgpu_dm_mst_types.c   |  28 ++---
 drivers/gpu/drm/display/drm_dp_mst_topology.c | 106 +-
 drivers/gpu/drm/i915/display/intel_dp_mst.c   |   5 +-
 drivers/gpu/drm/nouveau/dispnv50/disp.c   |   4 +-
 include/drm/display/drm_dp_mst_helper.h   |   6 +-
 6 files changed, 75 insertions(+), 76 deletions(-)

diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c 
b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
index ad4571190a90..f84a4ad736d8 100644
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
@@ -7393,7 +7393,7 @@ static int dm_encoder_helper_atomic_check(struct 
drm_encoder *encoder,
clock = adjusted_mode->clock;
dm_new_connector_state->pbn = drm_dp_calc_pbn_mode(clock, bpp, 
false);
}
-   dm_new_connector_state->vcpi_slots = 
drm_dp_atomic_find_vcpi_slots(state,
+   dm_new_connector_state->vcpi_slots = 
drm_dp_atomic_find_time_slots(state,
   
mst_mgr,
   
mst_port,
   
dm_new_connector_state->pbn,
diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_mst_types.c 
b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_mst_types.c
index 9221b6690a4a..e40ff51e7be0 100644
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_mst_types.c
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_mst_types.c
@@ -378,7 +378,7 @@ static int dm_dp_mst_atomic_check(struct drm_connector 
*connector,
return 0;
}
 
-   return drm_dp_atomic_release_vcpi_slots(state,
+   return drm_dp_atomic_release_time_slots(state,
mst_mgr,
mst_port);
 }
@@ -689,7 +689,7 @@ static void increase_dsc_bpp(struct drm_atomic_state *state,
 
if (initial_slack[next_index] > fair_pbn_alloc) {
vars[next_index].pbn += fair_pbn_alloc;
-   if (drm_dp_atomic_find_vcpi_slots(state,
+   if (drm_dp_atomic_find_time_slots(state,
  
params[next_index].port->mgr,
  
params[next_index].port,
  vars[next_index].pbn,
@@ -699,7 +699,7 @@ static void increase_dsc_bpp(struct drm_atomic_state *state,
vars[next_index].bpp_x16 = 
bpp_x16_from_pbn(params[next_index], vars[next_index].pbn);
} else {
vars[next_index].pbn -= fair_pbn_alloc;
-   if (drm_dp_atomic_find_vcpi_slots(state,
+   if (drm_dp_atomic_find_time_slots(state,
  
params[next_index].port->mgr,
  
params[next_index].port,
  
vars[next_index].pbn,
@@ -708,7 +708,7 @@ static void increase_dsc_bpp(struct drm_atomic_state *state,
}
} else {
vars[next_index].pbn += initial_slack[next_index];
-   if (drm_dp_atomic_find_vcpi_slots(state,
+   if (drm_dp_atomic_find_time_slots(state,
  
params[next_index].port->mgr,
   

[Intel-gfx] XDC 2022: Registration & Call for Presentations still open!

[Lyude Paul]

Hello! This is just a reminder that the CFP for XDC in 2022 is still open!

The 2022 X.Org Developers Conference is being held in conjunction with
the 2022 Wine Developers Conference.  This is a meeting to bring
together developers working on all things open graphics (Linux kernel,
Mesa, DRM, Wayland, X11, etc.) as well as developers for the Wine
Project, a key consumer of open graphics.

Registration & Call for Proposals are now open for both XDC 2022 and
WineConf 2022, which will take place on October 4-6, 2022 in
Minneapolis, Minnesota, USA. 

https://xdc2022.x.org
 
As usual, the conference is free of charge and open to the general
public. If you plan on attending, please make sure to register as early
as possible!
 
In order to register as attendee, you will therefore need to do it via
the XDC website:
 
https://indico.freedesktop.org/event/2/registrations/2/
 
In addition to registration, the CfP is now open for talks, workshops
and demos at XDC 2022. While any serious proposal will be gratefully
considered, topics of interest to X.Org and freedesktop.org developers
are encouraged. The program focus is on new development, ongoing
challenges and anything else that will spark discussions among
attendees in the hallway track.
 
We are open to talks across all layers of the graphics stack, from the
kernel to desktop environments / graphical applications and about how
to make things better for the developers who build them. Head to the
CfP page to learn more: 
 
https://indico.freedesktop.org/event/2/abstracts/
 
The deadline for submissions is Monday July 4th, 2022.
 
Check out our Reimbursement Policy to accept speaker
expenses for X.Org events like XDC 2022:
 
https://www.x.org/wiki/XorgFoundation/Policies/Reimbursement/

If you have any questions, please send me an email to
x...@codeweavers.com, adding on CC the X.org board (board
at foundation.x.org).
 
And don't forget, you can follow us on Twitter for all the latest
updates and to stay connected:
 
https://twitter.com/XOrgDevConf

Best regards,
Lyude Paul, on behalf of X.org

Re: [Intel-gfx] [PATCH 5/6] drm/i915/bios: Define more BDB contents

[Lyude Paul]

> 
> Reviewed-by: Jani Nikula 
> 
> 
> > +   u8 reserved1:1;
> > +   u8 power_conservation_pref:3;
> > +   u8 reserved2:1;
> > +   u8 lace_enabled_status:1;
> > +   u8 lace_support:1;
> > +   u8 als_enable:1;
> > +} __packed;
> >  
> >  struct als_data_entry {
> > u16 backlight_adjust;
> > @@ -861,10 +886,16 @@ struct aggressiveness_profile_entry {
> > u8 lace_aggressiveness : 4;
> >  } __packed;
> >  
> > +struct aggressiveness_profile2_entry {
> > +   u8 opst_aggressiveness : 4;
> > +   u8 elp_aggressiveness : 4;
> > +} __packed;
> > +
> >  struct bdb_lfp_power {
> > -   u8 lfp_feature_bits;
> > +   struct lfp_features features;
> > struct als_data_entry als[5];
> > -   u8 lace_aggressiveness_profile;
> > +   u8 lace_aggressiveness_profile:3;
> > +   u8 reserved1:5;
> > u16 dpst;
> > u16 psr;
> > u16 drrs;
> > @@ -876,6 +907,9 @@ struct bdb_lfp_power {
> > struct aggressiveness_profile_entry aggressiveness[16];
> > u16 hobl; /* 232+ */
> >     u16 vrr_feature_enabled; /* 233+ */
> > +   u16 elp; /* 247+ */
> > +   u16 opst; /* 247+ */
> > +   struct aggressiveness_profile2_entry aggressiveness2[16]; /* 247+
> > */
> >  } __packed;
> >  
> >  /*
> > @@ -885,8 +919,10 @@ struct bdb_lfp_power {
> >  #define MAX_MIPI_CONFIGURATIONS6
> >  
> >  struct bdb_mipi_config {
> > -   struct mipi_config config[MAX_MIPI_CONFIGURATIONS];
> > -   struct mipi_pps_data pps[MAX_MIPI_CONFIGURATIONS];
> > +   struct mipi_config config[MAX_MIPI_CONFIGURATIONS]; /* 175 */
> > +   struct mipi_pps_data pps[MAX_MIPI_CONFIGURATIONS]; /* 177 */
> > +   struct edp_pwm_delays pwm_delays[MAX_MIPI_CONFIGURATIONS]; /* 186
> > */
> > +   u8 pmic_i2c_bus_number[MAX_MIPI_CONFIGURATIONS]; /* 190 */
> >  } __packed;
> >  
> >  /*
> 

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

Re: [Intel-gfx] [PATCH 12/14] drm/nouveau: Register ACPI video backlight when nv_backlight registration fails

[Lyude Paul]

On Tue, 2022-05-17 at 17:23 +0200, Hans de Goede wrote:
> Typically the acpi_video driver will initialize before nouveau, which
> used to cause /sys/class/backlight/acpi_video0 to get registered and then
> nouveau would register its own nv_backlight device later. After which
> the drivers/acpi/video_detect.c code unregistered the acpi_video0 device
> to avoid there being 2 backlight devices.
> 
> This means that userspace used to briefly see 2 devices and the
> disappearing of acpi_video0 after a brief time confuses the systemd
> backlight level save/restore code, see e.g.:
> https://bbs.archlinux.org/viewtopic.php?id=269920
> 
> To fix this the ACPI video code has been modified to make backlight class
> device registration a separate step, relying on the drm/kms driver to
> ask for the acpi_video backlight registration after it is done setting up
> its native backlight device.
> 
> Add a call to the new acpi_video_register_backlight() when native backlight
> device registration has failed / was skipped to ensure that there is a
> backlight device available before the drm_device gets registered with
> userspace.
> 
> Signed-off-by: Hans de Goede 
> ---
>  drivers/gpu/drm/nouveau/nouveau_backlight.c | 7 +++
>  1 file changed, 7 insertions(+)
> 
> diff --git a/drivers/gpu/drm/nouveau/nouveau_backlight.c
> b/drivers/gpu/drm/nouveau/nouveau_backlight.c
> index f56ff797c78c..0ae8793357a4 100644
> --- a/drivers/gpu/drm/nouveau/nouveau_backlight.c
> +++ b/drivers/gpu/drm/nouveau/nouveau_backlight.c
> @@ -436,6 +436,13 @@ nouveau_backlight_init(struct drm_connector *connector)
>  
>  fail_alloc:
> kfree(bl);
> +   /*
> +    * If we get here we have an internal panel, but no nv_backlight,
> +    * try registering an ACPI video backlight device instead.
> +    */
> +   if (ret == 0)
> +   acpi_video_register_backlight();

Assuming we don't need to return the value of acpi_video_register_backlight()
here:

Reviewed-by: Lyude Paul 

> +
> return ret;
>  }
>  

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

Re: [Intel-gfx] [PATCH 05/14] drm/nouveau: Don't register backlight when another backlight should be used

[Lyude Paul]

Reviewed-by: Lyude Paul 

Also, ack on this being pushed to drm-misc, along with any other patches I r-b

On Tue, 2022-05-17 at 17:23 +0200, Hans de Goede wrote:
> Before this commit when we want userspace to use the acpi_video backlight
> device we register both the GPU's native backlight device and acpi_video's
> firmware acpi_video# backlight device. This relies on userspace preferring
> firmware type backlight devices over native ones.
> 
> Registering 2 backlight devices for a single display really is
> undesirable, don't register the GPU's native backlight device when
> another backlight device should be used.
> 
> Signed-off-by: Hans de Goede 
> ---
>  drivers/gpu/drm/nouveau/nouveau_backlight.c | 7 +++
>  1 file changed, 7 insertions(+)
> 
> diff --git a/drivers/gpu/drm/nouveau/nouveau_backlight.c
> b/drivers/gpu/drm/nouveau/nouveau_backlight.c
> index daf9f87477ba..f56ff797c78c 100644
> --- a/drivers/gpu/drm/nouveau/nouveau_backlight.c
> +++ b/drivers/gpu/drm/nouveau/nouveau_backlight.c
> @@ -34,6 +34,8 @@
>  #include 
>  #include 
>  
> +#include 
> +
>  #include "nouveau_drv.h"
>  #include "nouveau_reg.h"
>  #include "nouveau_encoder.h"
> @@ -404,6 +406,11 @@ nouveau_backlight_init(struct drm_connector *connector)
> goto fail_alloc;
> }
>  
> +   if (acpi_video_get_backlight_type(true) != acpi_backlight_native) {
> +   NV_INFO(drm, "Skipping nv_backlight registration\n");
> +   goto fail_alloc;
> +   }
> +
> if (!nouveau_get_backlight_name(backlight_name, bl)) {
>     NV_ERROR(drm, "Failed to retrieve a unique name for the
> backlight interface\n");
> goto fail_alloc;

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

[Intel-gfx] Requests For Proposals for hosting XDC 2023 are now open

[Lyude Paul]

Hello everyone!

The X.org board is soliciting proposals to host XDC in 2023. Since
XDC 2022 is being held in North America this year, XDC 2023 is expected
to be in Europe. However, the board is open to other locations,
especially if there's an interesting co-location with another
conference.

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 *September 1st, 2022*. 

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.

Best regards,
Lyude Paul
On behalf of X.org

[Intel-gfx] XDC 2022: Registration & Call for Proposals now open!

[Lyude Paul]

Hello!

The 2022 X.Org Developers Conference is being held in conjunction with
the 2022 Wine Developers Conference.  This is a meeting to bring
together developers working on all things open graphics (Linux kernel,
Mesa, DRM, Wayland, X11, etc.) as well as developers for the Wine
Project, a key consumer of open graphics.

Registration & Call for Proposals are now open for both XDC 2022 and
WineConf 2022, which will take place on October 4-6, 2022 in
Minneapolis, Minnesota, USA. 

https://xdc2022.x.org
 
As usual, the conference is free of charge and open to the general
public. If you plan on attending, please make sure to register as early
as possible!
 
In order to register as attendee, you will therefore need to do it via
the XDC website:
 
https://indico.freedesktop.org/event/2/registrations/2/
 
In addition to registration, the CfP is now open for talks, workshops
and demos at XDC 2022. While any serious proposal will be gratefully
considered, topics of interest to X.Org and freedesktop.org developers
are encouraged. The program focus is on new development, ongoing
challenges and anything else that will spark discussions among
attendees in the hallway track.
 
We are open to talks across all layers of the graphics stack, from the
kernel to desktop environments / graphical applications and about how
to make things better for the developers who build them. Head to the
CfP page to learn more: 
 
https://indico.freedesktop.org/event/2/abstracts/
 
The deadline for submissions is Monday July 4th, 2022.
 
Check out our Reimbursement Policy to accept speaker
expenses for X.Org events like XDC 2022:
 
https://www.x.org/wiki/XorgFoundation/Policies/Reimbursement/

If you have any questions, please send me an email to
x...@codeweavers.com, adding on CC the X.org board (board
at foundation.x.org).
 
And don't forget, you can follow us on Twitter for all the latest
updates and to stay connected:
 
https://twitter.com/XOrgDevConf

Best regards,
Lyude Paul, on behalf of X.org

[Intel-gfx] 2022 X.Org Foundation Election vote results

[Lyude Paul]

The Board of Directors election and the vote on the By-laws concluded at
23:59 UTC on 18 April 2022. There are 80 current Members of the X.Org
Foundation, and 52 Members cast votes. This is a 65.0% turn out.

In the election of the Directors to the Board of the X.Org Foundation,
the results were that Emma Anholt, Alyssa Rosenzweig, Mark Filion and
Ricardo Garcia were elected for two year terms.

The old full board is: Emma Anholt, Samuel Iglesias Gonsálvez, Mark
Filion, Manasi D Navare, Keith Packard, Lyude Paul, Daniel Vetter, Harry
Wentland

The new full board is: Emma Anholt, Samuel Iglesias Gonsálvez, Mark
Filion, Manasi D Navare, Alyssa Rosenzweig, Lyude Paul, Daniel Vetter,
and Ricardo Garcia

The full election results were as follows:

   Option | Rank 1 | Rank 2 | Rank 3 | Rank 4 | Rank 5 | Rank 6 | Final 
Score
  Emma Anholt | 21 | 16 |  4 |  1 |  5 |  5 |   
  240
Alyssa Rosenzweig |  4 | 10 | 17 |  7 | 11 |  3 |   
  188
  Mark Filion |  8 | 12 |  7 | 10 |  5 | 10 |   
  186
   Ricardo Garcia |  9 |  4 |  5 | 17 | 10 |  7 |   
  172
  Lucas Stach |  4 |  5 | 14 |  9 | 11 |  9 |   
  163
  Shashank Sharma |  6 |  5 |  5 |  8 | 10 | 18 |   
  143

Lyude Paul, on behalf of the X.Org elections committee

Re: [Intel-gfx] [PATCH v2] drm/i915: Check EDID for HDR static metadata when choosing blc

[Lyude Paul]

Reviewed-by: Lyude Paul 

On Wed, 2022-04-13 at 11:28 +0300, Jouni Högander wrote:
> We have now seen panel (XMG Core 15 e21 laptop) advertizing support
> for Intel proprietary eDP backlight control via DPCD registers, but
> actually working only with legacy pwm control.
> 
> This patch adds panel EDID check for possible HDR static metadata and
> Intel proprietary eDP backlight control is used only if that exists.
> Missing HDR static metadata is ignored if user specifically asks for
> Intel proprietary eDP backlight control via enable_dpcd_backlight
> parameter.
> 
> v2 :
> - Ignore missing HDR static metadata if Intel proprietary eDP
>   backlight control is forced via i915.enable_dpcd_backlight
> - Printout info message if panel is missing HDR static metadata and
>   support for Intel proprietary eDP backlight control is detected
> 
> Fixes: 4a8d79901d5b ("drm/i915/dp: Enable Intel's HDR backlight interface
> (only SDR for now)")
> Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/5284
> Cc: Lyude Paul 
> Cc: Mika Kahola 
> Cc: Jani Nikula 
> Cc: Filippo Falezza 
> Cc: sta...@vger.kernel.org
> Signed-off-by: Jouni Högander 
> ---
>  .../drm/i915/display/intel_dp_aux_backlight.c | 34 ++-
>  1 file changed, 26 insertions(+), 8 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 97cf3cac0105..fb6cf30ee628 100644
> --- a/drivers/gpu/drm/i915/display/intel_dp_aux_backlight.c
> +++ b/drivers/gpu/drm/i915/display/intel_dp_aux_backlight.c
> @@ -97,6 +97,14 @@
>  
>  #define INTEL_EDP_BRIGHTNESS_OPTIMIZATION_1   
> 0x359
>  
> +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,
> +};
> +
>  /* Intel EDP backlight callbacks */
>  static bool
>  intel_dp_aux_supports_hdr_backlight(struct intel_connector *connector)
> @@ -126,6 +134,24 @@ intel_dp_aux_supports_hdr_backlight(struct
> intel_connector *connector)
> return false;
> }
>  
> +   /*
> +    * If we don't have HDR static metadata there is no way to
> +    * runtime detect used range for nits based control. For now
> +    * do not use Intel proprietary eDP backlight control if we
> +    * don't have this data in panel EDID. In case we find panel
> +    * which supports only nits based control, but doesn't provide
> +    * HDR static metadata we need to start maintaining table of
> +    * ranges for such panels.
> +    */
> +   if (i915->params.enable_dpcd_backlight !=
> INTEL_DP_AUX_BACKLIGHT_FORCE_INTEL &&
> +   !(connector->base.hdr_sink_metadata.hdmi_type1.metadata_type &
> + BIT(HDMI_STATIC_METADATA_TYPE1))) {
> +   drm_info(>drm,
> +    "Panel is missing HDR static metadata. Possible
> support for Intel HDR backlight interface is not used. If your backlight
> controls don't work try booting with i915.enable_dpcd_backlight=%d. needs
> this, please file a _new_ bug report on drm/i915, see " FDO_BUG_URL " for
> details.\n",
> +    INTEL_DP_AUX_BACKLIGHT_FORCE_INTEL);
> +   return false;
> +   }
> +
> panel->backlight.edp.intel.sdr_uses_aux =
> tcon_cap[2] & INTEL_EDP_SDR_TCON_BRIGHTNESS_AUX_CAP;
>  
> @@ -413,14 +439,6 @@ 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;

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

Re: [Intel-gfx] [PATCH] drm/i915: Check EDID before dpcd for possible HDR aux bl support

[Lyude Paul]

On Wed, 2022-04-13 at 08:31 +, Hogander, Jouni wrote:
> Hello Lyude,
> 
> See my respose below.
> 
> On Tue, 2022-04-12 at 13:50 -0400, Lyude Paul wrote:
> > On Tue, 2022-04-12 at 08:25 +0300, Jouni Högander wrote:
> > > We have now seen panel (XMG Core 15 e21 laptop) avertizing support
> > > for Intel proprietary eDP backlight control via DPCD registers, but
> > > actually working only with legacy pwm control.
> > > 
> > > This patch adds panel EDID check for possible HDR static metadata
> > > and
> > > does detection from DPCD registers only if this data block exists.
> > > 
> > > Fixes: 4a8d79901d5b ("drm/i915/dp: Enable Intel's HDR backlight
> > > interface
> > > (only SDR for now)")
> > > Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/5284
> > > Cc: Lyude Paul 
> > > Cc: Mika Kahola 
> > > Cc: Jani Nikula 
> > > Tested-by: Filippo Falezza 
> > > Signed-off-by: Jouni Högander 
> > > ---
> > >  .../gpu/drm/i915/display/intel_dp_aux_backlight.c   | 13
> > > +
> > >  1 file changed, 13 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 97cf3cac0105..f69e185b58c1 100644
> > > --- a/drivers/gpu/drm/i915/display/intel_dp_aux_backlight.c
> > > +++ b/drivers/gpu/drm/i915/display/intel_dp_aux_backlight.c
> > > @@ -108,6 +108,19 @@ intel_dp_aux_supports_hdr_backlight(struct
> > > intel_connector *connector)
> > >     int ret;
> > >     u8 tcon_cap[4];
> > >  
> > > +   /*
> > > +    * If we don't have HDR static metadata there is no way to
> > > +    * runtime detect used range for nits based control. For
> > > now
> > > +    * do not use Intel proprietary eDP backlight control if we
> > > +    * don't have this data in panel EDID. In case we find
> > > panel
> > > +    * which supports only nits based control, but doesn't
> > > provide
> > > +    * HDR static metadata we need to start maintaining table
> > > of
> > > +    * ranges for such panels.
> > > +    */
> > > +   if (!(connector-
> > > > base.hdr_sink_metadata.hdmi_type1.metadata_type &
> > > + BIT(HDMI_STATIC_METADATA_TYPE1)))
> > > +   return false;
> > 
> > The block used for this is actually for HDMI?? How bizarre…
> > 
> > Anyway yeah - patch looks good to me, but I think we should print a
> > debugging
> > message of some sort when we determine that there's no HDR backlight
> > because
> > of the EDID - along with printing instructions for how the user can
> > override
> > it if we've made the wrong choice along with reporting a bug. Also -
> > we should
> > have the
> 
> hmm, currently there is no override possibility
> in intel_dp_aux_supports_hdr_backlight. Do you think I should add one?

Yes, probably - I think just making it so that i915.enable_dpcd_backlight=3
enables the HDR backlight regardless of the results of the EDID check would
probably be a good idea.

> 
> I sent version 2. Didn't add your rb there as I wasn't sure if I
> understood your comment correctly. Please check new version.
> 
> > Cc: sta...@vger.kernel.org
> 
> tag from dim added here using `dim fixes $commit`.
> 
> With that fixed:
> 
> Reviewed-by: Lyude Paul 
> 
> +
>     intel_dp_wait_source_oui(intel_dp);
>  
>     ret = drm_dp_dpcd_read(aux, INTEL_EDP_HDR_TCON_CAP0,
> tcon_cap,
> sizeof(tcon_cap));
> 
> BR,
> 
> Jouni Högander
> 

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

Re: [Intel-gfx] [PATCH] drm/i915: Check EDID before dpcd for possible HDR aux bl support

[Lyude Paul]

On Tue, 2022-04-12 at 08:25 +0300, Jouni Högander wrote:
> We have now seen panel (XMG Core 15 e21 laptop) avertizing support
> for Intel proprietary eDP backlight control via DPCD registers, but
> actually working only with legacy pwm control.
> 
> This patch adds panel EDID check for possible HDR static metadata and
> does detection from DPCD registers only if this data block exists.
> 
> Fixes: 4a8d79901d5b ("drm/i915/dp: Enable Intel's HDR backlight interface
> (only SDR for now)")
> Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/5284
> Cc: Lyude Paul 
> Cc: Mika Kahola 
> Cc: Jani Nikula 
> Tested-by: Filippo Falezza 
> Signed-off-by: Jouni Högander 
> ---
>  .../gpu/drm/i915/display/intel_dp_aux_backlight.c   | 13 +
>  1 file changed, 13 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 97cf3cac0105..f69e185b58c1 100644
> --- a/drivers/gpu/drm/i915/display/intel_dp_aux_backlight.c
> +++ b/drivers/gpu/drm/i915/display/intel_dp_aux_backlight.c
> @@ -108,6 +108,19 @@ intel_dp_aux_supports_hdr_backlight(struct
> intel_connector *connector)
> int ret;
> u8 tcon_cap[4];
>  
> +   /*
> +    * If we don't have HDR static metadata there is no way to
> +    * runtime detect used range for nits based control. For now
> +    * do not use Intel proprietary eDP backlight control if we
> +    * don't have this data in panel EDID. In case we find panel
> +    * which supports only nits based control, but doesn't provide
> +    * HDR static metadata we need to start maintaining table of
> +    * ranges for such panels.
> +    */
> +   if (!(connector->base.hdr_sink_metadata.hdmi_type1.metadata_type &
> + BIT(HDMI_STATIC_METADATA_TYPE1)))
> +   return false;

The block used for this is actually for HDMI?? How bizarre…

Anyway yeah - patch looks good to me, but I think we should print a debugging
message of some sort when we determine that there's no HDR backlight because
of the EDID - along with printing instructions for how the user can override
it if we've made the wrong choice along with reporting a bug. Also - we should
have the

Cc: sta...@vger.kernel.org

tag from dim added here using `dim fixes $commit`.

With that fixed:

Reviewed-by: Lyude Paul 

> +
> intel_dp_wait_source_oui(intel_dp);
>  
> ret = drm_dp_dpcd_read(aux, INTEL_EDP_HDR_TCON_CAP0, tcon_cap,
> sizeof(tcon_cap));

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

[Intel-gfx] 2022 X.org Foundation Election Candidates

[Lyude Paul]

To all X.Org Foundation Members:

The election for the X.Org Foundation Board of Directors will begin on 04 April
2022. We have 6 candidates who are running for 4 seats. They are:

Emma Anholt
Shashank Sharma
Ricardo Garcia
Mark Filion
Lucas Stach
Alyssa Rosenzweig

To be found in the link below below are the Personal Statements each candidate
submitted for your consideration along with their Statements of Contribution
that they submitted with the membership application. Please review each of the
candidates' statements to help you decide whom to vote for during the upcoming
election.

https://www.x.org/wiki/BoardOfDirectors/Elections/2022/

If you have questions of the candidates, you should feel free to ask them here
on the mailing list.

The election committee will provide detailed instructions on how the voting
system will work when the voting period begins.

Lyude Paul, on behalf of the X.Org elections committee

[Intel-gfx] 2022 X.Org Foundation Membership deadline for voting in the election

[Lyude Paul]

The 2022 X.Org Foundation elections are rapidly approaching. We will be
forwarding the election schedule and nominating process to the
membership shortly.

Please note that only current members can vote in the upcoming election,
and that the deadline for new memberships or renewals to vote in the
upcoming election is 31 March 2022 at 23:59 UTC.

If you are interested in joining the X.Org Foundation or in renewing
your membership, please visit the membership system site at:
https://members.x.org/

Lyude Paul, on behalf of the X.Org elections committee

[Intel-gfx] 2022 X.Org Board of Directors Elections Nomination period is NOW

[Lyude Paul]

The Board consists of directors elected from the membership.  Each year, an
election is held to bring the total number of directors to eight. The four
members receiving the highest vote totals will serve as directors for two year
terms.

The directors who received two year terms starting in 2021 were Lyude Paul,
Samuel Iglesias Gonsálvez, Manasi D Navare and Daniel Vetter. They will
continue to serve until their term ends in 2023. Current directors whose term
expires in 2022 are Emma Anholt, Keith Packard, Harry Wentland and Mark
Filion.

A director is expected to participate in the fortnightly IRC meeting to
discuss current business and to attend the annual meeting of the X.Org
Foundation, which will be held at a location determined in advance by the
Board of Directors.

A member may nominate themselves or any other member they feel is qualified.
Nominations should be sent to the Election Committee at elections at x.org.

Nominees shall be required to be current members of the X.Org Foundation, and
submit a personal statement of up to 200 words that will be provided to
prospective voters.  The collected statements, along with the statement of
contribution to the X.Org Foundation in the member's account page on
http://members.x.org, will be made available to all voters to help them make
their voting decisions.

Nominations, membership applications or renewals and completed personal
statements must be received no later than 23:59 UTC on 20th March 2022.

The slate of candidates will be published 28th March 2022 and candidate Q
will begin then. The deadline for Xorg membership applications and renewals is
31st March 2022.

Cheers,
   Lyude Paul, on behalf of the X.Org BoD

Re: [Intel-gfx] [PATCH] drm/i915/mst: re-enable link training failure fallback for DP MST

[Lyude Paul]

On Mon, 2022-03-07 at 22:48 +0200, Ville Syrjälä wrote:
> On Mon, Mar 07, 2022 at 09:36:57PM +0200, Jani Nikula wrote:
> > Commit 80a8cecf62a5 ("drm/i915/dp_mst: Disable link training fallback on
> > MST links") disabled link training failure fallback for DP MST due to
> > the MST manager using the DPCD directly, and generally being ignorant
> > about the possibility of downgrading link parameters. See the commit for
> > further details.
> > 
> > Since then, the max_lane_count and max_link_rate members have been added
> > to struct drm_dp_mst_topology_mgr in commit 98025a62cb00 ("drm/dp_mst:
> > Use Extended Base Receiver Capability DPCD space") and refined in
> > follow-up work.
> > 
> > The members perhaps aren't intended for changing the parameters during
> > the lifetime of the manager, as they're supposed to be passed to
> > drm_dp_mst_topology_mgr_init(). However, the members are only ever used
> > in drm_dp_mst_topology_mgr_set_mst(), and there seems to be nothing to
> > prevent us from adjusting them *before* enabling MST. The wouldn't have
> > an effect if modified while MST is enabled. This is not necessarily
> > pretty, though.
> > 
> > Cc: Nikola Cornij 
> > Cc: Lyude Paul 
> > Cc: Imre Deak 
> > Cc: Ville Syrjälä 
> > Cc: Uma Shankar 
> > Signed-off-by: Jani Nikula 
> > 
> > ---
> > 
> > This is *untested*. I don't see why it wouldn't work, though...
> 
> I don't think we have the required stuff to force a modeset on all
> the streams when the link params change. And the bad link status
> property + uevent stuff is only hooked up to the SST connector
> AFAICS.
> 
> The other major thing missing is a way to reduce the bpp/etc. of
> all the streams to make more room on the link if we have
> insufficient bandwidth. And the more we start to reduce the bw
> the more we're going to hit that and fail the modesets. We already
> ran into regressions due to this when I tried to enable deep color
> for MST.

Yeah, this is why I have been trying to move stuff into the atomic state
because it will make stuff like this a LOT easier. And to be honest, I think
pretty much all of the bandwidth related info in the MST mgr that isn't in
atomic is a hack at this point (I'm definitely not accepting adding any more
props into mgr now). We'll probably also want to consider maybe having a more
complicated link_status API for MST (I was originally going to use the
link_status prop we already have, but I've been realizing that might cause a
lot of problems when initially introducing it since fixing MST link status
errors will likely require disabling all sinks on the link - which userspace
won't understand).

Unfortunately now that I'm back to working on that, I'm stuck on trying to
wrap my head around adjusting amdgpu for these changes <<. I have a WIP branch
with other drivers adjusted if anyone is interested in looking:

https://gitlab.freedesktop.org/lyudess/linux/-/commits/wip/mst-atomic-only-v1

Haven't actually tried it yet on any hardware though

> 
> > this
> > should allow us to downgrade the link to from 128b/132b to 8b/10b if the
> > former fails.
> > 
> > Thoughts? In particular, any objections for messing with the topology
> > manager members directly? Any chance it'll make refactoring the MST code
> > more difficult?
> > ---
> >  drivers/gpu/drm/i915/display/intel_dp.c | 42 ++---
> >  drivers/gpu/drm/i915/display/intel_dp_mst.c |  5 ++-
> >  2 files changed, 23 insertions(+), 24 deletions(-)
> > 
> > diff --git a/drivers/gpu/drm/i915/display/intel_dp.c
> > b/drivers/gpu/drm/i915/display/intel_dp.c
> > index 619546441eae..2fad3104b40e 100644
> > --- a/drivers/gpu/drm/i915/display/intel_dp.c
> > +++ b/drivers/gpu/drm/i915/display/intel_dp.c
> > @@ -600,15 +600,6 @@ int intel_dp_get_link_train_fallback_values(struct
> > intel_dp *intel_dp,
> > struct drm_i915_private *i915 = dp_to_i915(intel_dp);
> > int index;
> >  
> > -   /*
> > -    * TODO: Enable fallback on MST links once MST link compute can
> > handle
> > -    * the fallback params.
> > -    */
> > -   if (intel_dp->is_mst) {
> > -   drm_err(>drm, "Link Training Unsuccessful\n");
> > -   return -1;
> > -   }
> > -
> > if (intel_dp_is_edp(intel_dp) && !intel_dp->use_max_params) {
> > drm_dbg_kms(>drm,
> >     "Retrying Link training for eDP with max
> > parameters\n");
> > @@ -2785,6 +2776,8 @@ intel_dp_configu

[Intel-gfx] 2022 X.Org Board of Directors Elections timeline extended, Request for nominations

[Lyude Paul]

We are seeking nominations for candidates for election to the X.org Foundation
Board of Directors. However, as we presently do not have enough nominations to
start the election - the decision has been made to extend the timeline by 2
weeks. Note this is a fairly regular part of the elections process.

The new deadline for nominations to the X.org Board of Directors is 23:59 UTC
on 20th March 2022.

The Board consists of directors elected from the membership.  Each year, an
election is held to bring the total number of directors to eight. The four
members receiving the highest vote totals will serve as directors for two year
terms.

The directors who received two year terms starting in 2021 were Lyude Paul,
Samuel Iglesias Gonsálvez, Manasi D Navare and Daniel Vetter. They will
continue to serve until their term ends in 2023. Current directors whose term
expires in 2022 are Emma Anholt, Keith Packard, Harry Wentland and Mark
Filion.

A director is expected to participate in the fortnightly IRC meeting to
discuss current business and to attend the annual meeting of the X.Org
Foundation, which will be held at a location determined in advance by the
Board of Directors.

A member may nominate themselves or any other member they feel is qualified.
Nominations should be sent to the Election Committee at elections at x.org.

Nominees shall be required to be current members of the X.Org Foundation, and
submit a personal statement of up to 200 words that will be provided to
prospective voters.  The collected statements, along with the statement of
contribution to the X.Org Foundation in the member's account page on
http://members.x.org, will be made available to all voters to help them make
their voting decisions.

Nominations, membership applications or renewals and completed personal
statements must be received no later than 23:59 UTC on 20th March 2022.

The slate of candidates will be published 28th March 2022 and candidate Q
will begin then. The deadline for Xorg membership applications and renewals is
31st March 2022.

Cheers,
   Lyude Paul, on behalf of the X.Org BoD

Re: [Intel-gfx] [PATCH v2] drm/i915/psr: Set "SF Partial Frame Enable" also on full update

[Lyude Paul]

JFYI I've been running the patch on my laptop for about a day now, flickering
is totally gone and also I'm a bit astonished at the power savings!

Tested-by: Lyude Paul 

On Thu, 2022-02-24 at 15:02 -0500, Lyude Paul wrote:
> Also - I realized this is missing an appropriate Fixes: tag for the commit
> that enabled PSR2 selective fetch on tigerlake in the first place
> 
> On Wed, 2022-02-23 at 17:32 +, Souza, Jose wrote:
> > On Wed, 2022-02-23 at 14:48 +0200, Jouni Högander wrote:
> > > Currently we are observing occasional screen flickering when
> > > PSR2 selective fetch is enabled. More specifically glitch seems
> > > to happen on full frame update when cursor moves to coords
> > > x = -1 or y = -1.
> > > 
> > > According to Bspec SF Single full frame should not be set if
> > > SF Partial Frame Enable is not set. This happened to be true for
> > > ADLP as PSR2_MAN_TRK_CTL_ENABLE is always set and for ADLP it's
> > > actually "SF Partial Frame Enable" (Bit 31).
> > > 
> > > Setting "SF Partial Frame Enable" bit also on full update seems to
> > > fix screen flickering.
> > > 
> > > Also make code more clear by setting PSR2_MAN_TRK_CTL_ENABLE
> > > only if not on ADLP as this bit doesn't exist in ADLP.
> > 
> > Bit exist but has another name.
> > 
> > > 
> > > Bspec: 49274
> > > 
> > > v2: Fix Mihai Harpau email address
> > > 
> > > Reported-by: Lyude Paul 
> > > Cc: Mihai Harpau 
> > > Cc: José Roberto de Souza 
> > > Cc: Ville Syrjälä 
> > > Bugzilla: https://gitlab.freedesktop.org/drm/intel/-/issues/5077
> > > Signed-off-by: Jouni Högander 
> > > ---
> > >  drivers/gpu/drm/i915/display/intel_psr.c | 20 ++--
> > >  drivers/gpu/drm/i915/i915_reg.h  |  1 +
> > >  2 files changed, 19 insertions(+), 2 deletions(-)
> > > 
> > > diff --git a/drivers/gpu/drm/i915/display/intel_psr.c
> > > b/drivers/gpu/drm/i915/display/intel_psr.c
> > > index 2e0b092f4b6b..90aca75e05e0 100644
> > > --- a/drivers/gpu/drm/i915/display/intel_psr.c
> > > +++ b/drivers/gpu/drm/i915/display/intel_psr.c
> > > @@ -1439,6 +1439,13 @@ static inline u32
> > > man_trk_ctl_single_full_frame_bit_get(struct drm_i915_private
> > >    PSR2_MAN_TRK_CTL_SF_SINGLE_FULL_FRAME;
> > >  }
> > >  
> > > +static inline u32 man_trk_ctl_partial_frame_bit_get(struct
> > > drm_i915_private *dev_priv)
> > > +{
> > > +   return IS_ALDERLAKE_P(dev_priv) ?
> > > +  ADLP_PSR2_MAN_TRK_CTL_SF_PARTIAL_FRAME_UPDATE :
> > > +  PSR2_MAN_TRK_CTL_SF_PARTIAL_FRAME_UPDATE;
> > > +}
> > > +
> > >  static void psr_force_hw_tracking_exit(struct intel_dp *intel_dp)
> > >  {
> > > struct drm_i915_private *dev_priv = dp_to_i915(intel_dp);
> > > @@ -1543,7 +1550,17 @@ static void psr2_man_trk_ctl_calc(struct
> > > intel_crtc_state *crtc_state,
> > >  {
> > > struct intel_crtc *crtc = to_intel_crtc(crtc_state->uapi.crtc);
> > > struct drm_i915_private *dev_priv = to_i915(crtc->base.dev);
> > > -   u32 val = PSR2_MAN_TRK_CTL_ENABLE;
> > > +   u32 val = 0;
> > > +
> > > +   /*
> > > +    * ADL_P doesn't have HW tracking nor manual tracking enable
> > > +    * bit
> > > +    */
> > 
> > Nit: Unnecessary comment.
> > 
> > Reviewed-by: José Roberto de Souza 
> > 
> > > +   if (!IS_ALDERLAKE_P(dev_priv))
> > > +   val = PSR2_MAN_TRK_CTL_ENABLE;
> > > +
> > > +   /* SF partial frame enable has to be set even on full update */
> > > +   val |= man_trk_ctl_partial_frame_bit_get(dev_priv);
> > >  
> > > if (full_update) {
> > > /*
> > > @@ -1563,7 +1580,6 @@ static void psr2_man_trk_ctl_calc(struct
> > > intel_crtc_state *crtc_state,
> > > } else {
> > > drm_WARN_ON(crtc_state->uapi.crtc->dev, clip->y1 % 4 ||
> > > clip->y2 % 4);
> > >  
> > > -   val |= PSR2_MAN_TRK_CTL_SF_PARTIAL_FRAME_UPDATE;
> > > val |= PSR2_MAN_TRK_CTL_SU_REGION_START_ADDR(clip->y1 /
> > > 4
> > > + 1);
> > > val |= PSR2_MAN_TRK_CTL_SU_REGION_END_ADDR(clip->y2 / 4
> > > +
> > > 1);
> > > }
> > > diff --g

Re: [Intel-gfx] [PATCH v2] drm/i915/psr: Set "SF Partial Frame Enable" also on full update

[Lyude Paul]

Also - I realized this is missing an appropriate Fixes: tag for the commit
that enabled PSR2 selective fetch on tigerlake in the first place

On Wed, 2022-02-23 at 17:32 +, Souza, Jose wrote:
> On Wed, 2022-02-23 at 14:48 +0200, Jouni Högander wrote:
> > Currently we are observing occasional screen flickering when
> > PSR2 selective fetch is enabled. More specifically glitch seems
> > to happen on full frame update when cursor moves to coords
> > x = -1 or y = -1.
> > 
> > According to Bspec SF Single full frame should not be set if
> > SF Partial Frame Enable is not set. This happened to be true for
> > ADLP as PSR2_MAN_TRK_CTL_ENABLE is always set and for ADLP it's
> > actually "SF Partial Frame Enable" (Bit 31).
> > 
> > Setting "SF Partial Frame Enable" bit also on full update seems to
> > fix screen flickering.
> > 
> > Also make code more clear by setting PSR2_MAN_TRK_CTL_ENABLE
> > only if not on ADLP as this bit doesn't exist in ADLP.
> 
> Bit exist but has another name.
> 
> > 
> > Bspec: 49274
> > 
> > v2: Fix Mihai Harpau email address
> > 
> > Reported-by: Lyude Paul 
> > Cc: Mihai Harpau 
> > Cc: José Roberto de Souza 
> > Cc: Ville Syrjälä 
> > Bugzilla: https://gitlab.freedesktop.org/drm/intel/-/issues/5077
> > Signed-off-by: Jouni Högander 
> > ---
> >  drivers/gpu/drm/i915/display/intel_psr.c | 20 ++--
> >  drivers/gpu/drm/i915/i915_reg.h  |  1 +
> >  2 files changed, 19 insertions(+), 2 deletions(-)
> > 
> > diff --git a/drivers/gpu/drm/i915/display/intel_psr.c
> > b/drivers/gpu/drm/i915/display/intel_psr.c
> > index 2e0b092f4b6b..90aca75e05e0 100644
> > --- a/drivers/gpu/drm/i915/display/intel_psr.c
> > +++ b/drivers/gpu/drm/i915/display/intel_psr.c
> > @@ -1439,6 +1439,13 @@ static inline u32
> > man_trk_ctl_single_full_frame_bit_get(struct drm_i915_private
> >    PSR2_MAN_TRK_CTL_SF_SINGLE_FULL_FRAME;
> >  }
> >  
> > +static inline u32 man_trk_ctl_partial_frame_bit_get(struct
> > drm_i915_private *dev_priv)
> > +{
> > +   return IS_ALDERLAKE_P(dev_priv) ?
> > +  ADLP_PSR2_MAN_TRK_CTL_SF_PARTIAL_FRAME_UPDATE :
> > +  PSR2_MAN_TRK_CTL_SF_PARTIAL_FRAME_UPDATE;
> > +}
> > +
> >  static void psr_force_hw_tracking_exit(struct intel_dp *intel_dp)
> >  {
> > struct drm_i915_private *dev_priv = dp_to_i915(intel_dp);
> > @@ -1543,7 +1550,17 @@ static void psr2_man_trk_ctl_calc(struct
> > intel_crtc_state *crtc_state,
> >  {
> > struct intel_crtc *crtc = to_intel_crtc(crtc_state->uapi.crtc);
> > struct drm_i915_private *dev_priv = to_i915(crtc->base.dev);
> > -   u32 val = PSR2_MAN_TRK_CTL_ENABLE;
> > +   u32 val = 0;
> > +
> > +   /*
> > +    * ADL_P doesn't have HW tracking nor manual tracking enable
> > +    * bit
> > +    */
> 
> Nit: Unnecessary comment.
> 
> Reviewed-by: José Roberto de Souza 
> 
> > +   if (!IS_ALDERLAKE_P(dev_priv))
> > +   val = PSR2_MAN_TRK_CTL_ENABLE;
> > +
> > +   /* SF partial frame enable has to be set even on full update */
> > +   val |= man_trk_ctl_partial_frame_bit_get(dev_priv);
> >  
> > if (full_update) {
> > /*
> > @@ -1563,7 +1580,6 @@ static void psr2_man_trk_ctl_calc(struct
> > intel_crtc_state *crtc_state,
> > } else {
> > drm_WARN_ON(crtc_state->uapi.crtc->dev, clip->y1 % 4 ||
> > clip->y2 % 4);
> >  
> > -   val |= PSR2_MAN_TRK_CTL_SF_PARTIAL_FRAME_UPDATE;
> > val |= PSR2_MAN_TRK_CTL_SU_REGION_START_ADDR(clip->y1 / 4
> > + 1);
> > val |= PSR2_MAN_TRK_CTL_SU_REGION_END_ADDR(clip->y2 / 4 +
> > 1);
> > }
> > diff --git a/drivers/gpu/drm/i915/i915_reg.h
> > b/drivers/gpu/drm/i915/i915_reg.h
> > index 2b8a3086ed35..89bbb64e520d 100644
> > --- a/drivers/gpu/drm/i915/i915_reg.h
> > +++ b/drivers/gpu/drm/i915/i915_reg.h
> > @@ -2316,6 +2316,7 @@
> >  #define 
> > ADLP_PSR2_MAN_TRK_CTL_SU_REGION_START_ADDR(val)   REG_FIELD_PREP(ADLP_
> > PSR2_MAN_TRK_CTL_SU_REGION_START_ADDR_MASK, val)
> >  #define 
> > ADLP_PSR2_MAN_TRK_CTL_SU_REGION_END_ADDR_MASK REG_GENMASK(12, 0)
> >  #define 
> > ADLP_PSR2_MAN_TRK_CTL_SU_REGION_END_ADDR(val) REG_FIELD_PREP(ADLP_
> > PSR2_MAN_TRK_CTL_SU_REGION_END_ADDR_MASK, val)
> > +#define 
> > ADLP_PSR2_MAN_TRK_CTL_SF_PARTIAL_FRAME_UPDATE REG_BIT(31)
> >  #define 
> > ADLP_PSR2_MAN_TRK_CTL_SF_SINGLE_FULL_FRAMEREG_BIT(14)
> >  #define 
> > ADLP_PSR2_MAN_TRK_CTL_SF_CONTINUOS_FULL_FRAME REG_BIT(13)
> >  
> 

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

Re: [Intel-gfx] [PATCH v2] drm/i915/psr: Set "SF Partial Frame Enable" also on full update

[Lyude Paul]

I'm back so I will try this patch on my machine and see if it helps, thank
you!

On Wed, 2022-02-23 at 14:48 +0200, Jouni Högander wrote:
> Currently we are observing occasional screen flickering when
> PSR2 selective fetch is enabled. More specifically glitch seems
> to happen on full frame update when cursor moves to coords
> x = -1 or y = -1.
> 
> According to Bspec SF Single full frame should not be set if
> SF Partial Frame Enable is not set. This happened to be true for
> ADLP as PSR2_MAN_TRK_CTL_ENABLE is always set and for ADLP it's
> actually "SF Partial Frame Enable" (Bit 31).
> 
> Setting "SF Partial Frame Enable" bit also on full update seems to
> fix screen flickering.
> 
> Also make code more clear by setting PSR2_MAN_TRK_CTL_ENABLE
> only if not on ADLP as this bit doesn't exist in ADLP.
> 
> Bspec: 49274
> 
> v2: Fix Mihai Harpau email address
> 
> Reported-by: Lyude Paul 
> Cc: Mihai Harpau 
> Cc: José Roberto de Souza 
> Cc: Ville Syrjälä 
> Bugzilla: https://gitlab.freedesktop.org/drm/intel/-/issues/5077
> Signed-off-by: Jouni Högander 
> ---
>  drivers/gpu/drm/i915/display/intel_psr.c | 20 ++--
>  drivers/gpu/drm/i915/i915_reg.h  |  1 +
>  2 files changed, 19 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/display/intel_psr.c
> b/drivers/gpu/drm/i915/display/intel_psr.c
> index 2e0b092f4b6b..90aca75e05e0 100644
> --- a/drivers/gpu/drm/i915/display/intel_psr.c
> +++ b/drivers/gpu/drm/i915/display/intel_psr.c
> @@ -1439,6 +1439,13 @@ static inline u32
> man_trk_ctl_single_full_frame_bit_get(struct drm_i915_private
>    PSR2_MAN_TRK_CTL_SF_SINGLE_FULL_FRAME;
>  }
>  
> +static inline u32 man_trk_ctl_partial_frame_bit_get(struct drm_i915_private
> *dev_priv)
> +{
> +   return IS_ALDERLAKE_P(dev_priv) ?
> +  ADLP_PSR2_MAN_TRK_CTL_SF_PARTIAL_FRAME_UPDATE :
> +  PSR2_MAN_TRK_CTL_SF_PARTIAL_FRAME_UPDATE;
> +}
> +
>  static void psr_force_hw_tracking_exit(struct intel_dp *intel_dp)
>  {
> struct drm_i915_private *dev_priv = dp_to_i915(intel_dp);
> @@ -1543,7 +1550,17 @@ static void psr2_man_trk_ctl_calc(struct
> intel_crtc_state *crtc_state,
>  {
> struct intel_crtc *crtc = to_intel_crtc(crtc_state->uapi.crtc);
> struct drm_i915_private *dev_priv = to_i915(crtc->base.dev);
> -   u32 val = PSR2_MAN_TRK_CTL_ENABLE;
> +   u32 val = 0;
> +
> +   /*
> +    * ADL_P doesn't have HW tracking nor manual tracking enable
> +    * bit
> +    */
> +   if (!IS_ALDERLAKE_P(dev_priv))
> +   val = PSR2_MAN_TRK_CTL_ENABLE;
> +
> +   /* SF partial frame enable has to be set even on full update */
> +   val |= man_trk_ctl_partial_frame_bit_get(dev_priv);
>  
> if (full_update) {
> /*
> @@ -1563,7 +1580,6 @@ static void psr2_man_trk_ctl_calc(struct
> intel_crtc_state *crtc_state,
> } else {
> drm_WARN_ON(crtc_state->uapi.crtc->dev, clip->y1 % 4 ||
> clip->y2 % 4);
>  
> -   val |= PSR2_MAN_TRK_CTL_SF_PARTIAL_FRAME_UPDATE;
> val |= PSR2_MAN_TRK_CTL_SU_REGION_START_ADDR(clip->y1 / 4 +
> 1);
> val |= PSR2_MAN_TRK_CTL_SU_REGION_END_ADDR(clip->y2 / 4 +
> 1);
> }
> diff --git a/drivers/gpu/drm/i915/i915_reg.h
> b/drivers/gpu/drm/i915/i915_reg.h
> index 2b8a3086ed35..89bbb64e520d 100644
> --- a/drivers/gpu/drm/i915/i915_reg.h
> +++ b/drivers/gpu/drm/i915/i915_reg.h
> @@ -2316,6 +2316,7 @@
>  #define 
> ADLP_PSR2_MAN_TRK_CTL_SU_REGION_START_ADDR(val)   REG_FIELD_PREP(ADLP_PS
> R2_MAN_TRK_CTL_SU_REGION_START_ADDR_MASK, val)
>  #define 
> ADLP_PSR2_MAN_TRK_CTL_SU_REGION_END_ADDR_MASK REG_GENMASK(12, 0)
>  #define 
> ADLP_PSR2_MAN_TRK_CTL_SU_REGION_END_ADDR(val)     REG_FIELD_PREP(ADLP_PS
> R2_MAN_TRK_CTL_SU_REGION_END_ADDR_MASK, val)
> +#define  ADLP_PSR2_MAN_TRK_CTL_SF_PARTIAL_FRAME_UPDATE REG_BIT(31)
>  #define  ADLP_PSR2_MAN_TRK_CTL_SF_SINGLE_FULL_FRAMEREG_BIT(14)
>  #define  ADLP_PSR2_MAN_TRK_CTL_SF_CONTINUOS_FULL_FRAME REG_BIT(13)
>  

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

[Intel-gfx] 2022 X.Org Board of Directors Elections Nomination period is NOW

[Lyude Paul]

We are seeking nominations for candidates for election to the X.Org Foundation
Board of Directors. All X.Org Foundation members are eligible for election to
the board.

Nominations for the 2022 election are now open and will remain open until
23:59 UTC on 06 March 2022.

The Board consists of directors elected from the membership. Each year, an
election is held to bring the total number of directors to eight. The four
members receiving the highest vote totals will serve as directors for two year
terms.

The directors who received two year terms starting in 2021 were Lyude Paul,
Samuel Iglesias Gonsálvez, Manasi D Navare and Daniel Vetter. They will
continue to serve until their term ends in 2023. Current directors whose term
expires in 2022 are Emma Anholt, Keith Packard, Harry Wentland and Mark
Filion.

A director is expected to participate in the fortnightly IRC meeting to
discuss current business and to attend the annual meeting of the X.Org
Foundation, which will be held at a location determined in advance by the
Board of Directors.

A member may nominate themselves or any other member they feel is qualified.
Nominations should be sent to the Election Committee at elections at x.org.

Nominees shall be required to be current members of the X.Org Foundation, and
submit a personal statement of up to 200 words that will be provided to
prospective voters. The collected statements, along with the statement of
contribution to the X.Org Foundation in the member's account page on
http://members.x.org, will be made available to all voters to help them make
their voting decisions.

Nominations, membership applications or renewals and completed personal
statements must be received no later than 23:59 UTC on 6th March 2022.

The slate of candidates will be published 14 March 2022 and candidate Q will
begin then. The deadline for Xorg membership applications and renewals is 17
March 2022.

Cheers, Lyude Paul, on behalf of the X.Org BoD

[Intel-gfx] [Important!] 2022 X.Org Foundation Membership deadline for voting in the election

[Lyude Paul]

The 2022 X.Org Foundation elections are rapidly approaching. We will be
forwarding instructions on the nomination process to membership in the
near future.

Please note that only current members can vote in the upcoming election,
and that the deadline for new memberships or renewals to vote in the
upcoming election is March 17th 2022 at 23:59 UTC.

If you are interested in joining the X.Org Foundation or in renewing
your membership, please visit the membership system site at:

https://members.x.org/

You can find the current election schedule here:

https://www.x.org/wiki/BoardOfDirectors/Elections/2022/

Lyude Paul,
On behalf of the X.Org elections committee

Re: [Intel-gfx] [PATCH] drm/i915/psr: Disable PSR2 selective fetch for all TGL steps

[Lyude Paul]

Opened the issue at https://gitlab.freedesktop.org/drm/intel/-/issues/5077 ,
included dmesg + video. Feel free to let me know if you need any more info, or
need me to try any patches

On Tue, 2022-02-08 at 13:06 +, Souza, Jose wrote:
> On Mon, 2022-02-07 at 16:38 -0500, Lyude Paul wrote:
> > As we've unfortunately started to come to expect from PSR on Intel
> > platforms, PSR2 selective fetch is not at all ready to be enabled on
> > Tigerlake as it results in severe flickering issues - at least on this
> > ThinkPad X1 Carbon 9th generation. The easiest way I've found of
> > reproducing these issues is to just move the cursor around the left border
> > of the screen (suspicious…).
> 
> Where is the bug for that? Where is the logs?
> We can't go from enabled to disabled without any debug and because of a
> single device.
> In the mean time you have the option to set the i915 parameter to disable
> it.
> 
> > 
> > So, fix people's displays again and turn PSR2 selective fetch off for all
> > steppings of Tigerlake. This can be re-enabled again if someone from Intel
> > finds the time to fix this functionality on OEM machines.
> > 
> > Signed-off-by: Lyude Paul 
> > Fixes: 7f6002e58025 ("drm/i915/display: Enable PSR2 selective fetch by
> > default")
> > Cc: Gwan-gyeong Mun 
> > Cc: Ville Syrjälä 
> > Cc: José Roberto de Souza 
> > Cc: Jani Nikula 
> > Cc: Rodrigo Vivi 
> > Cc: intel-gfx@lists.freedesktop.org
> > Cc:  # v5.16+
> > ---
> >  drivers/gpu/drm/i915/display/intel_psr.c | 10 +++---
> >  1 file changed, 7 insertions(+), 3 deletions(-)
> > 
> > diff --git a/drivers/gpu/drm/i915/display/intel_psr.c
> > b/drivers/gpu/drm/i915/display/intel_psr.c
> > index a1a663f362e7..25c16abcd9cd 100644
> > --- a/drivers/gpu/drm/i915/display/intel_psr.c
> > +++ b/drivers/gpu/drm/i915/display/intel_psr.c
> > @@ -737,10 +737,14 @@ static bool intel_psr2_sel_fetch_config_valid(struct
> > intel_dp *intel_dp,
> > return false;
> > }
> >  
> > -   /* Wa_14010254185 Wa_14010103792 */
> > -   if (IS_TGL_DISPLAY_STEP(dev_priv, STEP_A0, STEP_C0)) {
> > +   /*
> > +    * There's two things stopping this from being enabled on TGL:
> > +    * For steps A0-C0: workarounds Wa_14010254185 Wa_14010103792 are
> > missing
> > +    * For all steps: PSR2 selective fetch causes screen flickering
> > +    */
> > +   if (IS_TIGERLAKE(dev_priv)) {
> >     drm_dbg_kms(_priv->drm,
> > -   "PSR2 sel fetch not enabled, missing the
> > implementation of WAs\n");
> > +   "PSR2 sel fetch not enabled, currently broken
> > on TGL\n");
> > return false;
> > }
> >  
> 

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

Re: [Intel-gfx] [PATCH] drm/i915/psr: Disable PSR2 selective fetch for all TGL steps

[Lyude Paul]

On Tue, 2022-02-08 at 13:06 +, Souza, Jose wrote:
> On Mon, 2022-02-07 at 16:38 -0500, Lyude Paul wrote:
> > As we've unfortunately started to come to expect from PSR on Intel
> > platforms, PSR2 selective fetch is not at all ready to be enabled on
> > Tigerlake as it results in severe flickering issues - at least on this
> > ThinkPad X1 Carbon 9th generation. The easiest way I've found of
> > reproducing these issues is to just move the cursor around the left border
> > of the screen (suspicious…).
> 
> Where is the bug for that? Where is the logs?

I'm happy to open up a bug and include some logs, will do it in just a moment

> We can't go from enabled to disabled without any debug and because of a
> single device.
> In the mean time you have the option to set the i915 parameter to disable
> it.

I mean - I totally understand the hesistance with the lack of debug info, I'll
go open up an issue with said info in a bit. FWIW is a machine currently being
sold with Linux pre-installs which is expected to work out of the box, so it's
not exactly an uncommon laptop to be running Linux. Also I don't have any
problem with us trying to fix the issue before flat out disabling things - I
sent the revert hoping that would happen, and also because I needed to write
the revert anyway since I had to disable this in Fedora's kernel.

> 
> > 
> > So, fix people's displays again and turn PSR2 selective fetch off for all
> > steppings of Tigerlake. This can be re-enabled again if someone from Intel
> > finds the time to fix this functionality on OEM machines.
> > 
> > Signed-off-by: Lyude Paul 
> > Fixes: 7f6002e58025 ("drm/i915/display: Enable PSR2 selective fetch by
> > default")
> > Cc: Gwan-gyeong Mun 
> > Cc: Ville Syrjälä 
> > Cc: José Roberto de Souza 
> > Cc: Jani Nikula 
> > Cc: Rodrigo Vivi 
> > Cc: intel-gfx@lists.freedesktop.org
> > Cc:  # v5.16+
> > ---
> >  drivers/gpu/drm/i915/display/intel_psr.c | 10 +++---
> >  1 file changed, 7 insertions(+), 3 deletions(-)
> > 
> > diff --git a/drivers/gpu/drm/i915/display/intel_psr.c
> > b/drivers/gpu/drm/i915/display/intel_psr.c
> > index a1a663f362e7..25c16abcd9cd 100644
> > --- a/drivers/gpu/drm/i915/display/intel_psr.c
> > +++ b/drivers/gpu/drm/i915/display/intel_psr.c
> > @@ -737,10 +737,14 @@ static bool intel_psr2_sel_fetch_config_valid(struct
> > intel_dp *intel_dp,
> > return false;
> > }
> >  
> > -   /* Wa_14010254185 Wa_14010103792 */
> > -   if (IS_TGL_DISPLAY_STEP(dev_priv, STEP_A0, STEP_C0)) {
> > +   /*
> > +    * There's two things stopping this from being enabled on TGL:
> > +    * For steps A0-C0: workarounds Wa_14010254185 Wa_14010103792 are
> > missing
> > +    * For all steps: PSR2 selective fetch causes screen flickering
> > +    */
> > +   if (IS_TIGERLAKE(dev_priv)) {
> >     drm_dbg_kms(_priv->drm,
> > -   "PSR2 sel fetch not enabled, missing the
> > implementation of WAs\n");
> > +   "PSR2 sel fetch not enabled, currently broken
> > on TGL\n");
> > return false;
> > }
> >  
> 

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

[Intel-gfx] [PATCH] drm/i915/psr: Disable PSR2 selective fetch for all TGL steps

[Lyude Paul]

As we've unfortunately started to come to expect from PSR on Intel
platforms, PSR2 selective fetch is not at all ready to be enabled on
Tigerlake as it results in severe flickering issues - at least on this
ThinkPad X1 Carbon 9th generation. The easiest way I've found of
reproducing these issues is to just move the cursor around the left border
of the screen (suspicious…).

So, fix people's displays again and turn PSR2 selective fetch off for all
steppings of Tigerlake. This can be re-enabled again if someone from Intel
finds the time to fix this functionality on OEM machines.

Signed-off-by: Lyude Paul 
Fixes: 7f6002e58025 ("drm/i915/display: Enable PSR2 selective fetch by default")
Cc: Gwan-gyeong Mun 
Cc: Ville Syrjälä 
Cc: José Roberto de Souza 
Cc: Jani Nikula 
Cc: Rodrigo Vivi 
Cc: intel-gfx@lists.freedesktop.org
Cc:  # v5.16+
---
 drivers/gpu/drm/i915/display/intel_psr.c | 10 +++---
 1 file changed, 7 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/intel_psr.c 
b/drivers/gpu/drm/i915/display/intel_psr.c
index a1a663f362e7..25c16abcd9cd 100644
--- a/drivers/gpu/drm/i915/display/intel_psr.c
+++ b/drivers/gpu/drm/i915/display/intel_psr.c
@@ -737,10 +737,14 @@ static bool intel_psr2_sel_fetch_config_valid(struct 
intel_dp *intel_dp,
return false;
}
 
-   /* Wa_14010254185 Wa_14010103792 */
-   if (IS_TGL_DISPLAY_STEP(dev_priv, STEP_A0, STEP_C0)) {
+   /*
+* There's two things stopping this from being enabled on TGL:
+* For steps A0-C0: workarounds Wa_14010254185 Wa_14010103792 are 
missing
+* For all steps: PSR2 selective fetch causes screen flickering
+*/
+   if (IS_TIGERLAKE(dev_priv)) {
drm_dbg_kms(_priv->drm,
-   "PSR2 sel fetch not enabled, missing the 
implementation of WAs\n");
+   "PSR2 sel fetch not enabled, currently broken on 
TGL\n");
return false;
}
 
-- 
2.34.1

[Intel-gfx] [Important!] 2022 X.Org Foundation Membership deadline for voting in the election

[Lyude Paul]

The 2022 X.Org Foundation elections are rapidly approaching. We will be
forwarding instructions on the nomination process to membership in the
near future.

Please note that only current members can vote in the upcoming election,
and that the deadline for new memberships or renewals to vote in the
upcoming election is March 17th 2022 at 23:59 UTC.

If you are interested in joining the X.Org Foundation or in renewing
your membership, please visit the membership system site at:

https://members.x.org/

You can find the current election schedule here:

https://www.x.org/wiki/BoardOfDirectors/Elections/2022/

    Lyude Paul,
    On behalf of the X.Org elections committee

Re: [Intel-gfx] [PATCH 8/8] drm/i915/mst: update slot information for 128b/132b

[Lyude Paul]

Acked-by: Lyude Paul 

BTW - I made a ton of progress last week on getting all of this stuff moved
into the atomic state :), mainly just trying to get amd hooked up with this
now (and need to rebase):

https://gitlab.freedesktop.org/lyudess/linux/-/commits/wip/mst-atomic-only-v1

So we soon won't need this slots hack

On Tue, 2022-01-25 at 19:03 +0200, Jani Nikula wrote:
> 128b/132b supports using 64 slots starting from 0, while 8b/10b reserves
> slot 0 for metadata.
> 
> Commit d6c6a76f80a1 ("drm: Update MST First Link Slot Information Based
> on Encoding Format") added support for updating the topology state
> accordingly, and commit 41724ea273cd ("drm/amd/display: Add DP 2.0 MST
> DM Support") started using it in the amd driver.
> 
> This feels more than a little cumbersome, especially updating the
> information in atomic check. For i915, add the update to MST connector
> .compute_config hook rather than iterating over all MST managers and
> connectors in global mode config .atomic_check. Fingers crossed.
> 
> v2:
> - Update in .compute_config() not .atomic_check (Ville)
> 
> Cc: Bhawanpreet Lakha 
> Cc: Lyude Paul 
> Cc: Uma Shankar 
> Cc: Ville Syrjälä 
> Signed-off-by: Jani Nikula 
> ---
>  drivers/gpu/drm/i915/display/intel_dp_mst.c | 29 +++--
>  1 file changed, 27 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/display/intel_dp_mst.c
> b/drivers/gpu/drm/i915/display/intel_dp_mst.c
> index b8bc7d397c81..ff75e22bde5c 100644
> --- a/drivers/gpu/drm/i915/display/intel_dp_mst.c
> +++ b/drivers/gpu/drm/i915/display/intel_dp_mst.c
> @@ -99,6 +99,27 @@ static int intel_dp_mst_compute_link_config(struct
> intel_encoder *encoder,
> return 0;
>  }
>  
> +static void intel_dp_mst_update_slots(struct intel_encoder *encoder,
> + struct intel_crtc_state *crtc_state,
> + struct drm_connector_state
> *conn_state)
> +{
> +   struct drm_i915_private *i915 = to_i915(encoder->base.dev);
> +   struct intel_dp_mst_encoder *intel_mst = enc_to_mst(encoder);
> +   struct intel_dp *intel_dp = _mst->primary->dp;
> +   struct drm_dp_mst_topology_mgr *mgr = _dp->mst_mgr;
> +   struct drm_dp_mst_topology_state *topology_state;
> +   u8 link_coding_cap = intel_dp_is_uhbr(crtc_state) ?
> +   DP_CAP_ANSI_128B132B : DP_CAP_ANSI_8B10B;
> +
> +   topology_state = drm_atomic_get_mst_topology_state(conn_state-
> >state, mgr);
> +   if (IS_ERR(topology_state)) {
> +   drm_dbg_kms(>drm, "slot update failed\n");
> +   return;
> +   }
> +
> +   drm_dp_mst_update_slots(topology_state, link_coding_cap);
> +}
> +
>  static int intel_dp_mst_compute_config(struct intel_encoder *encoder,
>    struct intel_crtc_state *pipe_config,
>    struct drm_connector_state
> *conn_state)
> @@ -155,6 +176,8 @@ static int intel_dp_mst_compute_config(struct
> intel_encoder *encoder,
> if (ret)
> return ret;
>  
> +   intel_dp_mst_update_slots(encoder, pipe_config, conn_state);
> +
> pipe_config->limited_color_range =
> intel_dp_limited_color_range(pipe_config, conn_state);
>  
> @@ -357,6 +380,7 @@ static void intel_mst_disable_dp(struct
> intel_atomic_state *state,
> struct intel_connector *connector =
> to_intel_connector(old_conn_state->connector);
> struct drm_i915_private *i915 = to_i915(connector->base.dev);
> +   int start_slot = intel_dp_is_uhbr(old_crtc_state) ? 0 : 1;
> int ret;
>  
> drm_dbg_kms(>drm, "active links %d\n",
> @@ -366,7 +390,7 @@ static void intel_mst_disable_dp(struct
> intel_atomic_state *state,
>  
> drm_dp_mst_reset_vcpi_slots(_dp->mst_mgr, connector->port);
>  
> -   ret = drm_dp_update_payload_part1(_dp->mst_mgr, 1);
> +   ret = drm_dp_update_payload_part1(_dp->mst_mgr, start_slot);
> if (ret) {
> drm_dbg_kms(>drm, "failed to update payload %d\n",
> ret);
> }
> @@ -475,6 +499,7 @@ static void intel_mst_pre_enable_dp(struct
> intel_atomic_state *state,
> struct drm_i915_private *dev_priv = to_i915(encoder->base.dev);
> struct intel_connector *connector =
> to_intel_connector(conn_state->connector);
> +   int start_slot = intel_dp_is_uhbr(pipe_config) ? 0 : 1;
> int ret;
>     bool first_mst_stream;
>  
> @@ -509,7 +534,7 @@ static void intel_mst_pre_enable_dp(struct
> intel_atomic_state *state,
>  
> intel_dp->active_mst_links++;
>  
> -   ret = drm_dp_update_payload_part1(_dp->mst_mgr, 1);
> +   ret = drm_dp_update_payload_part1(_dp->mst_mgr, start_slot);
>  
> /*
>  * Before Gen 12 this is not done as part of

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

Re: [Intel-gfx] [Nouveau] [PATCH v2 3/5] drm/dp: Move DisplayPort helpers into separate helper module

[Lyude Paul]

Acked-by: Lyude Paul 

On Wed, 2021-12-15 at 11:43 +0100, Thomas Zimmermann wrote:
> Move DisplayPort functions into a separate module to reduce the size
> of the KMS helpers. Select DRM_DP_HELPER for all users of the code. To
> avoid naming conflicts, rename drm_dp_helper.c to drm_dp.c
> 
> This change can help to reduce the size of the kernel binary. Some
> numbers from a x86-64 test build:
> 
> Before:
> drm_kms_helper.ko:  447480 bytes
> 
> After:
> drm_dp_helper.ko:   216632 bytes
> drm_kms_helper.ko:  239424 bytes
> 
> For early-boot graphics, generic DRM drivers, such as simpledrm,
> require DRM KMS helpers to be built into the kernel. Generic helper
> functions for DisplayPort take up a significant portion of DRM KMS
> helper library. These functions are not used by generic drivers and
> can be loaded as a module.
> 
> v2:
> * move DP helper code into dp/ (Jani)
> 
> Signed-off-by: Thomas Zimmermann 
> ---
>  drivers/gpu/drm/Kconfig   |  8 +++
>  drivers/gpu/drm/Makefile  | 10 -
>  drivers/gpu/drm/bridge/Kconfig    |  4 
>  drivers/gpu/drm/bridge/analogix/Kconfig   |  2 ++
>  drivers/gpu/drm/bridge/cadence/Kconfig    |  1 +
>  drivers/gpu/drm/dp/Makefile   |  7 ++
>  .../gpu/drm/{drm_dp_helper.c => dp/drm_dp.c}  |  0
>  drivers/gpu/drm/{ => dp}/drm_dp_aux_dev.c |  0
>  drivers/gpu/drm/{ => dp}/drm_dp_cec.c |  0
>  .../drm/{ => dp}/drm_dp_dual_mode_helper.c    |  0
>  .../gpu/drm/{ => dp}/drm_dp_helper_internal.h |  0
>  drivers/gpu/drm/dp/drm_dp_helper_mod.c    | 22 +++
>  .../gpu/drm/{ => dp}/drm_dp_mst_topology.c    |  0
>  .../{ => dp}/drm_dp_mst_topology_internal.h   |  0
>  drivers/gpu/drm/drm_kms_helper_common.c   | 15 -
>  drivers/gpu/drm/i915/Kconfig  |  1 +
>  drivers/gpu/drm/msm/Kconfig   |  1 +
>  drivers/gpu/drm/nouveau/Kconfig   |  1 +
>  drivers/gpu/drm/rockchip/Kconfig  |  1 +
>  drivers/gpu/drm/tegra/Kconfig |  1 +
>  drivers/gpu/drm/xlnx/Kconfig  |  1 +
>  21 files changed, 54 insertions(+), 21 deletions(-)
>  create mode 100644 drivers/gpu/drm/dp/Makefile
>  rename drivers/gpu/drm/{drm_dp_helper.c => dp/drm_dp.c} (100%)
>  rename drivers/gpu/drm/{ => dp}/drm_dp_aux_dev.c (100%)
>  rename drivers/gpu/drm/{ => dp}/drm_dp_cec.c (100%)
>  rename drivers/gpu/drm/{ => dp}/drm_dp_dual_mode_helper.c (100%)
>  rename drivers/gpu/drm/{ => dp}/drm_dp_helper_internal.h (100%)
>  create mode 100644 drivers/gpu/drm/dp/drm_dp_helper_mod.c
>  rename drivers/gpu/drm/{ => dp}/drm_dp_mst_topology.c (100%)
>  rename drivers/gpu/drm/{ => dp}/drm_dp_mst_topology_internal.h (100%)
> 
> diff --git a/drivers/gpu/drm/Kconfig b/drivers/gpu/drm/Kconfig
> index b1f22e457fd0..91f54aeb0b7c 100644
> --- a/drivers/gpu/drm/Kconfig
> +++ b/drivers/gpu/drm/Kconfig
> @@ -80,6 +80,12 @@ config DRM_DEBUG_SELFTEST
>  
>   If in doubt, say "N".
>  
> +config DRM_DP_HELPER
> +   tristate
> +   depends on DRM
> +   help
> + DRM helpers for DisplayPort.
> +
>  config DRM_KMS_HELPER
> tristate
> depends on DRM
> @@ -236,6 +242,7 @@ config DRM_RADEON
> depends on DRM && PCI && MMU
> depends on AGP || !AGP
> select FW_LOADER
> +   select DRM_DP_HELPER
>  select DRM_KMS_HELPER
>  select DRM_TTM
> select DRM_TTM_HELPER
> @@ -256,6 +263,7 @@ config DRM_AMDGPU
> tristate "AMD GPU"
> depends on DRM && PCI && MMU
> select FW_LOADER
> +   select DRM_DP_HELPER
> select DRM_KMS_HELPER
> select DRM_SCHED
> select DRM_TTM
> diff --git a/drivers/gpu/drm/Makefile b/drivers/gpu/drm/Makefile
> index 301a44dc18e3..69be80ef1d31 100644
> --- a/drivers/gpu/drm/Makefile
> +++ b/drivers/gpu/drm/Makefile
> @@ -48,21 +48,18 @@ obj-$(CONFIG_DRM_VRAM_HELPER) += drm_vram_helper.o
>  drm_ttm_helper-y := drm_gem_ttm_helper.o
>  obj-$(CONFIG_DRM_TTM_HELPER) += drm_ttm_helper.o
>  
> -drm_kms_helper-y := drm_bridge_connector.o drm_crtc_helper.o
> drm_dp_helper.o \
> +drm_kms_helper-y := drm_bridge_connector.o drm_crtc_helper.o \
> drm_dsc.o drm_encoder_slave.o drm_flip_work.o drm_hdcp.o \
> drm_probe_helper.o \
> -   drm_plane_helper.o drm_dp_mst_topology.o drm_atomic_helper.o
> \
> -   drm_kms_helper_common.o drm_dp_dual_mode_helper.o \
> +   drm_plan

[Intel-gfx] [PATCH v3] drm/i915/dp: Perform 30ms delay after source OUI write

[Lyude Paul]

While working on supporting the Intel HDR backlight interface, I noticed
that there's a couple of laptops that will very rarely manage to boot up
without detecting Intel HDR backlight support - even though it's supported
on the system. One example of such a laptop is the Lenovo P17 1st
generation.

Following some investigation Ville Syrjälä did through the docs they have
available to them, they discovered that there's actually supposed to be a
30ms wait after writing the source OUI before we begin setting up the rest
of the backlight interface.

This seems to be correct, as adding this 30ms delay seems to have
completely fixed the probing issues I was previously seeing. So - let's
start performing a 30ms wait after writing the OUI, which we do in a manner
similar to how we keep track of PPS delays (e.g. record the timestamp of
the OUI write, and then wait for however many ms are left since that
timestamp right before we interact with the backlight) in order to avoid
waiting any longer then we need to. As well, this also avoids us performing
this delay on systems where we don't end up using the HDR backlight
interface.

V3:
* Move last_oui_write into intel_dp
V2:
* Move panel delays into intel_pps

Signed-off-by: Lyude Paul 
Reviewed-by: Jani Nikula 
Fixes: 4a8d79901d5b ("drm/i915/dp: Enable Intel's HDR backlight interface (only 
SDR for now)")
Cc: Ville Syrjälä 
Cc:  # v5.12+
---
 drivers/gpu/drm/i915/display/intel_display_types.h|  3 +++
 drivers/gpu/drm/i915/display/intel_dp.c   | 11 +++
 drivers/gpu/drm/i915/display/intel_dp.h   |  2 ++
 drivers/gpu/drm/i915/display/intel_dp_aux_backlight.c |  5 +
 4 files changed, 21 insertions(+)

diff --git a/drivers/gpu/drm/i915/display/intel_display_types.h 
b/drivers/gpu/drm/i915/display/intel_display_types.h
index ea1e8a6e10b0..b9c967837872 100644
--- a/drivers/gpu/drm/i915/display/intel_display_types.h
+++ b/drivers/gpu/drm/i915/display/intel_display_types.h
@@ -1653,6 +1653,9 @@ struct intel_dp {
struct intel_dp_pcon_frl frl;
 
struct intel_psr psr;
+
+   /* When we last wrote the OUI for eDP */
+   unsigned long last_oui_write;
 };
 
 enum lspcon_vendor {
diff --git a/drivers/gpu/drm/i915/display/intel_dp.c 
b/drivers/gpu/drm/i915/display/intel_dp.c
index 0a424bf69396..5a8206298691 100644
--- a/drivers/gpu/drm/i915/display/intel_dp.c
+++ b/drivers/gpu/drm/i915/display/intel_dp.c
@@ -29,6 +29,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 
 #include 
@@ -2010,6 +2011,16 @@ intel_edp_init_source_oui(struct intel_dp *intel_dp, 
bool careful)
 
if (drm_dp_dpcd_write(_dp->aux, DP_SOURCE_OUI, oui, sizeof(oui)) 
< 0)
drm_err(>drm, "Failed to write source OUI\n");
+
+   intel_dp->last_oui_write = jiffies;
+}
+
+void intel_dp_wait_source_oui(struct intel_dp *intel_dp)
+{
+   struct drm_i915_private *i915 = dp_to_i915(intel_dp);
+
+   drm_dbg_kms(>drm, "Performing OUI wait\n");
+   wait_remaining_ms_from_jiffies(intel_dp->last_oui_write, 30);
 }
 
 /* If the device supports it, try to set the power state appropriately */
diff --git a/drivers/gpu/drm/i915/display/intel_dp.h 
b/drivers/gpu/drm/i915/display/intel_dp.h
index ce229026dc91..b64145a3869a 100644
--- a/drivers/gpu/drm/i915/display/intel_dp.h
+++ b/drivers/gpu/drm/i915/display/intel_dp.h
@@ -119,4 +119,6 @@ void intel_dp_pcon_dsc_configure(struct intel_dp *intel_dp,
 const struct intel_crtc_state *crtc_state);
 void intel_dp_phy_test(struct intel_encoder *encoder);
 
+void intel_dp_wait_source_oui(struct intel_dp *intel_dp);
+
 #endif /* __INTEL_DP_H__ */
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 8b9c925c4c16..62c112daacf2 100644
--- a/drivers/gpu/drm/i915/display/intel_dp_aux_backlight.c
+++ b/drivers/gpu/drm/i915/display/intel_dp_aux_backlight.c
@@ -36,6 +36,7 @@
 
 #include "intel_backlight.h"
 #include "intel_display_types.h"
+#include "intel_dp.h"
 #include "intel_dp_aux_backlight.h"
 
 /* TODO:
@@ -106,6 +107,8 @@ intel_dp_aux_supports_hdr_backlight(struct intel_connector 
*connector)
int ret;
u8 tcon_cap[4];
 
+   intel_dp_wait_source_oui(intel_dp);
+
ret = drm_dp_dpcd_read(aux, INTEL_EDP_HDR_TCON_CAP0, tcon_cap, 
sizeof(tcon_cap));
if (ret != sizeof(tcon_cap))
return false;
@@ -204,6 +207,8 @@ intel_dp_aux_hdr_enable_backlight(const struct 
intel_crtc_state *crtc_state,
int ret;
u8 old_ctrl, ctrl;
 
+   intel_dp_wait_source_oui(intel_dp);
+
ret = drm_dp_dpcd_readb(_dp->aux, 
INTEL_EDP_HDR_GETSET_CTRL_PARAMS, _ctrl);
if (ret != 1) {
drm_err(>drm, "Failed to read current backlight control 
mode: %d\n", ret);
-- 
2.33.1

Re: [Intel-gfx] [PATCH v2] drm/i915/dp: Perform 30ms delay after source OUI write

[Lyude Paul]

On Tue, 2021-11-30 at 12:36 +0200, Jani Nikula wrote:
> On Mon, 29 Nov 2021, Lyude Paul  wrote:
> > While working on supporting the Intel HDR backlight interface, I noticed
> > that there's a couple of laptops that will very rarely manage to boot up
> > without detecting Intel HDR backlight support - even though it's supported
> > on the system. One example of such a laptop is the Lenovo P17 1st
> > generation.
> > 
> > Following some investigation Ville Syrjälä did through the docs they have
> > available to them, they discovered that there's actually supposed to be a
> > 30ms wait after writing the source OUI before we begin setting up the rest
> > of the backlight interface.
> > 
> > This seems to be correct, as adding this 30ms delay seems to have
> > completely fixed the probing issues I was previously seeing. So - let's
> > start performing a 30ms wait after writing the OUI, which we do in a
> > manner
> > similar to how we keep track of PPS delays (e.g. record the timestamp of
> > the OUI write, and then wait for however many ms are left since that
> > timestamp right before we interact with the backlight) in order to avoid
> > waiting any longer then we need to. As well, this also avoids us
> > performing
> > this delay on systems where we don't end up using the HDR backlight
> > interface.
> > 
> > V2:
> > * Move panel delays into intel_pps
> > 
> > Signed-off-by: Lyude Paul 
> > Fixes: 4a8d79901d5b ("drm/i915/dp: Enable Intel's HDR backlight interface
> > (only SDR for now)")
> > Cc: Ville Syrjälä 
> > Cc:  # v5.12+
> > ---
> >  drivers/gpu/drm/i915/display/intel_display_types.h    |  4 
> >  drivers/gpu/drm/i915/display/intel_dp.c   | 11 +++
> >  drivers/gpu/drm/i915/display/intel_dp.h   |  2 ++
> >  drivers/gpu/drm/i915/display/intel_dp_aux_backlight.c |  5 +
> >  4 files changed, 22 insertions(+)
> > 
> > diff --git a/drivers/gpu/drm/i915/display/intel_display_types.h
> > b/drivers/gpu/drm/i915/display/intel_display_types.h
> > index ea1e8a6e10b0..ad64f9caa7ff 100644
> > --- a/drivers/gpu/drm/i915/display/intel_display_types.h
> > +++ b/drivers/gpu/drm/i915/display/intel_display_types.h
> > @@ -1485,6 +1485,7 @@ struct intel_pps {
> > bool want_panel_vdd;
> > unsigned long last_power_on;
> > unsigned long last_backlight_off;
> > +   unsigned long last_oui_write;
> > ktime_t panel_power_off_time;
> > intel_wakeref_t vdd_wakeref;
> >  
> > @@ -1653,6 +1654,9 @@ struct intel_dp {
> > struct intel_dp_pcon_frl frl;
> >  
> > struct intel_psr psr;
> > +
> > +   /* When we last wrote the OUI for eDP */
> > +   unsigned long last_oui_write;
> 
> Now you're adding last_oui_write to both intel_pps and intel_dp, forgot
> to git add? ;)

Yep :P, will send out a different version in a bit
> 
> I guess I'd add this to intel_dp only, because it's not strictly about
> PPS. I just wanted the mechanism to be similar to that.
> 
> >  };
> >  
> >  enum lspcon_vendor {
> > diff --git a/drivers/gpu/drm/i915/display/intel_dp.c
> > b/drivers/gpu/drm/i915/display/intel_dp.c
> > index 0a424bf69396..45318891ba07 100644
> > --- a/drivers/gpu/drm/i915/display/intel_dp.c
> > +++ b/drivers/gpu/drm/i915/display/intel_dp.c
> > @@ -29,6 +29,7 @@
> >  #include 
> >  #include 
> >  #include 
> > +#include 
> >  #include 
> >  
> >  #include 
> > @@ -2010,6 +2011,16 @@ intel_edp_init_source_oui(struct intel_dp
> > *intel_dp, bool careful)
> >  
> > if (drm_dp_dpcd_write(_dp->aux, DP_SOURCE_OUI, oui,
> > sizeof(oui)) < 0)
> > drm_err(>drm, "Failed to write source OUI\n");
> > +
> > +   intel_dp->pps.last_oui_write = jiffies;
> 
> Set to intel_dp->last_oui_write.
> 
> With those fixes,
> 
> Reviewed-by: Jani Nikula 
> 
> 
> > +}
> > +
> > +void intel_dp_wait_source_oui(struct intel_dp *intel_dp)
> > +{
> > +   struct drm_i915_private *i915 = dp_to_i915(intel_dp);
> > +
> > +   drm_dbg_kms(>drm, "Performing OUI wait\n");
> > +   wait_remaining_ms_from_jiffies(intel_dp->last_oui_write, 30);
> >  }
> >  
> >  /* If the device supports it, try to set the power state appropriately */
> > diff --git a/drivers/gpu/drm/i915/display/intel_dp.h
> > b/drivers/gpu/drm/i915/display/intel_dp.h
> > index ce229026dc91.

[Intel-gfx] [PATCH v2] drm/i915/dp: Perform 30ms delay after source OUI write

[Lyude Paul]

While working on supporting the Intel HDR backlight interface, I noticed
that there's a couple of laptops that will very rarely manage to boot up
without detecting Intel HDR backlight support - even though it's supported
on the system. One example of such a laptop is the Lenovo P17 1st
generation.

Following some investigation Ville Syrjälä did through the docs they have
available to them, they discovered that there's actually supposed to be a
30ms wait after writing the source OUI before we begin setting up the rest
of the backlight interface.

This seems to be correct, as adding this 30ms delay seems to have
completely fixed the probing issues I was previously seeing. So - let's
start performing a 30ms wait after writing the OUI, which we do in a manner
similar to how we keep track of PPS delays (e.g. record the timestamp of
the OUI write, and then wait for however many ms are left since that
timestamp right before we interact with the backlight) in order to avoid
waiting any longer then we need to. As well, this also avoids us performing
this delay on systems where we don't end up using the HDR backlight
interface.

V2:
* Move panel delays into intel_pps

Signed-off-by: Lyude Paul 
Fixes: 4a8d79901d5b ("drm/i915/dp: Enable Intel's HDR backlight interface (only 
SDR for now)")
Cc: Ville Syrjälä 
Cc:  # v5.12+
---
 drivers/gpu/drm/i915/display/intel_display_types.h|  4 
 drivers/gpu/drm/i915/display/intel_dp.c   | 11 +++
 drivers/gpu/drm/i915/display/intel_dp.h   |  2 ++
 drivers/gpu/drm/i915/display/intel_dp_aux_backlight.c |  5 +
 4 files changed, 22 insertions(+)

diff --git a/drivers/gpu/drm/i915/display/intel_display_types.h 
b/drivers/gpu/drm/i915/display/intel_display_types.h
index ea1e8a6e10b0..ad64f9caa7ff 100644
--- a/drivers/gpu/drm/i915/display/intel_display_types.h
+++ b/drivers/gpu/drm/i915/display/intel_display_types.h
@@ -1485,6 +1485,7 @@ struct intel_pps {
bool want_panel_vdd;
unsigned long last_power_on;
unsigned long last_backlight_off;
+   unsigned long last_oui_write;
ktime_t panel_power_off_time;
intel_wakeref_t vdd_wakeref;
 
@@ -1653,6 +1654,9 @@ struct intel_dp {
struct intel_dp_pcon_frl frl;
 
struct intel_psr psr;
+
+   /* When we last wrote the OUI for eDP */
+   unsigned long last_oui_write;
 };
 
 enum lspcon_vendor {
diff --git a/drivers/gpu/drm/i915/display/intel_dp.c 
b/drivers/gpu/drm/i915/display/intel_dp.c
index 0a424bf69396..45318891ba07 100644
--- a/drivers/gpu/drm/i915/display/intel_dp.c
+++ b/drivers/gpu/drm/i915/display/intel_dp.c
@@ -29,6 +29,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 
 #include 
@@ -2010,6 +2011,16 @@ intel_edp_init_source_oui(struct intel_dp *intel_dp, 
bool careful)
 
if (drm_dp_dpcd_write(_dp->aux, DP_SOURCE_OUI, oui, sizeof(oui)) 
< 0)
drm_err(>drm, "Failed to write source OUI\n");
+
+   intel_dp->pps.last_oui_write = jiffies;
+}
+
+void intel_dp_wait_source_oui(struct intel_dp *intel_dp)
+{
+   struct drm_i915_private *i915 = dp_to_i915(intel_dp);
+
+   drm_dbg_kms(>drm, "Performing OUI wait\n");
+   wait_remaining_ms_from_jiffies(intel_dp->last_oui_write, 30);
 }
 
 /* If the device supports it, try to set the power state appropriately */
diff --git a/drivers/gpu/drm/i915/display/intel_dp.h 
b/drivers/gpu/drm/i915/display/intel_dp.h
index ce229026dc91..b64145a3869a 100644
--- a/drivers/gpu/drm/i915/display/intel_dp.h
+++ b/drivers/gpu/drm/i915/display/intel_dp.h
@@ -119,4 +119,6 @@ void intel_dp_pcon_dsc_configure(struct intel_dp *intel_dp,
 const struct intel_crtc_state *crtc_state);
 void intel_dp_phy_test(struct intel_encoder *encoder);
 
+void intel_dp_wait_source_oui(struct intel_dp *intel_dp);
+
 #endif /* __INTEL_DP_H__ */
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 8b9c925c4c16..62c112daacf2 100644
--- a/drivers/gpu/drm/i915/display/intel_dp_aux_backlight.c
+++ b/drivers/gpu/drm/i915/display/intel_dp_aux_backlight.c
@@ -36,6 +36,7 @@
 
 #include "intel_backlight.h"
 #include "intel_display_types.h"
+#include "intel_dp.h"
 #include "intel_dp_aux_backlight.h"
 
 /* TODO:
@@ -106,6 +107,8 @@ intel_dp_aux_supports_hdr_backlight(struct intel_connector 
*connector)
int ret;
u8 tcon_cap[4];
 
+   intel_dp_wait_source_oui(intel_dp);
+
ret = drm_dp_dpcd_read(aux, INTEL_EDP_HDR_TCON_CAP0, tcon_cap, 
sizeof(tcon_cap));
if (ret != sizeof(tcon_cap))
return false;
@@ -204,6 +207,8 @@ intel_dp_aux_hdr_enable_backlight(const struct 
intel_crtc_state *crtc_state,
int ret;
u8 old_ctrl, ctrl;
 
+   intel_dp_wait_source_oui(intel_dp);
+
ret = drm_dp_dpcd_readb(_dp->aux, 
INTEL_EDP_HDR_GETSET_CTRL_PA

Re: [Intel-gfx] [PATCH 2/2] drm/i915/backlight: Make ext_pwm_disable_backlight() call intel_backlight_set_pwm_level()

[Lyude Paul]

Reviewed-by: Lyude Paul 

On Sun, 2021-11-21 at 12:00 +0100, Hans de Goede wrote:
> At least the Bay Trail LPSS PWM controller used with DSI panels on many
> Bay Trail tablets seems to leave the PWM pin in whatever state it was
> (high or low) ATM that the PWM gets disabled. Combined with some panels
> not having a separate backlight-enable pin this leads to the backlight
> sometimes staying on while it should not (when the pin was high during
> PWM-disabling).
> 
> First calling intel_backlight_set_pwm_level() will ensure that the pin
> is always low (or high for inverted brightness panels) since the passed
> in duty-cycle is 0% (or 100%) when the PWM gets disabled fixing the
> backlight sometimes staying on.
> 
> With the exception of ext_pwm_disable_backlight() all other
> foo_disable_backlight() functions call intel_backlight_set_pwm_level()
> already before disabling the backlight, so this change also aligns
> ext_pwm_disable_backlight() with all the other disable() functions.
> 
> Signed-off-by: Hans de Goede 
> ---
>  drivers/gpu/drm/i915/display/intel_backlight.c | 2 ++
>  1 file changed, 2 insertions(+)
> 
> diff --git a/drivers/gpu/drm/i915/display/intel_backlight.c
> b/drivers/gpu/drm/i915/display/intel_backlight.c
> index 03cd730c926a..2758a2f6c093 100644
> --- a/drivers/gpu/drm/i915/display/intel_backlight.c
> +++ b/drivers/gpu/drm/i915/display/intel_backlight.c
> @@ -421,6 +421,8 @@ static void ext_pwm_disable_backlight(const struct
> drm_connector_state *old_conn
> struct intel_connector *connector =
> to_intel_connector(old_conn_state->connector);
> struct intel_panel *panel = >panel;
>  
> +   intel_backlight_set_pwm_level(old_conn_state, level);
> +
> panel->backlight.pwm_state.enabled = false;
> pwm_apply_state(panel->backlight.pwm, >backlight.pwm_state);
>  }

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

Re: [Intel-gfx] [PATCH] drm/i915/dp: Perform 30ms delay after source OUI write

[Lyude Paul]

On Mon, 2021-11-15 at 12:53 +0200, Jani Nikula wrote:
> On Fri, 12 Nov 2021, Lyude Paul  wrote:
> > While working on supporting the Intel HDR backlight interface, I noticed
> > that there's a couple of laptops that will very rarely manage to boot up
> > without detecting Intel HDR backlight support - even though it's supported
> > on the system. One example of such a laptop is the Lenovo P17 1st
> > generation.
> > 
> > Following some investigation Ville Syrjälä did through the docs they have
> > available to them, they discovered that there's actually supposed to be a
> > 30ms wait after writing the source OUI before we begin setting up the rest
> > of the backlight interface.
> > 
> > This seems to be correct, as adding this 30ms delay seems to have
> > completely fixed the probing issues I was previously seeing. So - let's
> > start performing a 30ms wait after writing the OUI, which we do in a
> > manner
> > similar to how we keep track of PPS delays (e.g. record the timestamp of
> > the OUI write, and then wait for however many ms are left since that
> > timestamp right before we interact with the backlight) in order to avoid
> > waiting any longer then we need to. As well, this also avoids us
> > performing
> > this delay on systems where we don't end up using the HDR backlight
> > interface.
> 
> Ugh. Thanks for digging into this.

haha, np! You should thank Ville for finding the hidden docs that told us
about this :).

> 
> The only thing that I dislike with the implementation is splitting the
> implementation to two places. See how well we've managed to shove all of
> the PPS waits inside intel_pps.c. Almost all of intel_dp->pps is managed
> within intel_pps.c.

gotcha, I think I meant to do this after I got things working but forgot
before I sent this out, will respin ASAP

> 
> I think I'd actually add a intel_dp_wait_source_oui() or something in
> intel_dp.c, so all of the details about source OUI and
> intel_dp->last_oui_write access would be localized.
> 
> 
> BR,
> Jani.
> 
> 
> > 
> > Signed-off-by: Lyude Paul 
> > Fixes: 4a8d79901d5b ("drm/i915/dp: Enable Intel's HDR backlight interface
> > (only SDR for now)")
> > Cc: Ville Syrjälä 
> > Cc:  # v5.12+
> > ---
> >  drivers/gpu/drm/i915/display/intel_display_types.h    |  3 +++
> >  drivers/gpu/drm/i915/display/intel_dp.c   |  3 +++
> >  drivers/gpu/drm/i915/display/intel_dp_aux_backlight.c | 11 +++
> >  3 files changed, 17 insertions(+)
> > 
> > diff --git a/drivers/gpu/drm/i915/display/intel_display_types.h
> > b/drivers/gpu/drm/i915/display/intel_display_types.h
> > index ea1e8a6e10b0..b9c967837872 100644
> > --- a/drivers/gpu/drm/i915/display/intel_display_types.h
> > +++ b/drivers/gpu/drm/i915/display/intel_display_types.h
> > @@ -1653,6 +1653,9 @@ struct intel_dp {
> > struct intel_dp_pcon_frl frl;
> >  
> > struct intel_psr psr;
> > +
> > +   /* When we last wrote the OUI for eDP */
> > +   unsigned long last_oui_write;
> >  };
> >  
> >  enum lspcon_vendor {
> > diff --git a/drivers/gpu/drm/i915/display/intel_dp.c
> > b/drivers/gpu/drm/i915/display/intel_dp.c
> > index 0a424bf69396..77d9a9390c1e 100644
> > --- a/drivers/gpu/drm/i915/display/intel_dp.c
> > +++ b/drivers/gpu/drm/i915/display/intel_dp.c
> > @@ -29,6 +29,7 @@
> >  #include 
> >  #include 
> >  #include 
> > +#include 
> >  #include 
> >  
> >  #include 
> > @@ -2010,6 +2011,8 @@ intel_edp_init_source_oui(struct intel_dp *intel_dp,
> > bool careful)
> >  
> > if (drm_dp_dpcd_write(_dp->aux, DP_SOURCE_OUI, oui,
> > sizeof(oui)) < 0)
> > drm_err(>drm, "Failed to write source OUI\n");
> > +
> > +   intel_dp->last_oui_write = jiffies;
> >  }
> >  
> >  /* If the device supports it, try to set the power state appropriately */
> > 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 569d17b4d00f..2c35b999ec2c 100644
> > --- a/drivers/gpu/drm/i915/display/intel_dp_aux_backlight.c
> > +++ b/drivers/gpu/drm/i915/display/intel_dp_aux_backlight.c
> > @@ -96,6 +96,13 @@
> >  #define INTEL_EDP_BRIGHTNESS_OPTIMIZATION_1   
> > 0x359
> >  
> >  /* Intel EDP backlight callbacks */
> > +static void
> > +wait_for_oui(struct drm_i915_private *i915, struct intel_dp *intel_dp)
> > +{
> > +   drm_dbg_kms(

[Intel-gfx] [PATCH] drm/i915/dp: Perform 30ms delay after source OUI write

[Lyude Paul]

While working on supporting the Intel HDR backlight interface, I noticed
that there's a couple of laptops that will very rarely manage to boot up
without detecting Intel HDR backlight support - even though it's supported
on the system. One example of such a laptop is the Lenovo P17 1st
generation.

Following some investigation Ville Syrjälä did through the docs they have
available to them, they discovered that there's actually supposed to be a
30ms wait after writing the source OUI before we begin setting up the rest
of the backlight interface.

This seems to be correct, as adding this 30ms delay seems to have
completely fixed the probing issues I was previously seeing. So - let's
start performing a 30ms wait after writing the OUI, which we do in a manner
similar to how we keep track of PPS delays (e.g. record the timestamp of
the OUI write, and then wait for however many ms are left since that
timestamp right before we interact with the backlight) in order to avoid
waiting any longer then we need to. As well, this also avoids us performing
this delay on systems where we don't end up using the HDR backlight
interface.

Signed-off-by: Lyude Paul 
Fixes: 4a8d79901d5b ("drm/i915/dp: Enable Intel's HDR backlight interface (only 
SDR for now)")
Cc: Ville Syrjälä 
Cc:  # v5.12+
---
 drivers/gpu/drm/i915/display/intel_display_types.h|  3 +++
 drivers/gpu/drm/i915/display/intel_dp.c   |  3 +++
 drivers/gpu/drm/i915/display/intel_dp_aux_backlight.c | 11 +++
 3 files changed, 17 insertions(+)

diff --git a/drivers/gpu/drm/i915/display/intel_display_types.h 
b/drivers/gpu/drm/i915/display/intel_display_types.h
index ea1e8a6e10b0..b9c967837872 100644
--- a/drivers/gpu/drm/i915/display/intel_display_types.h
+++ b/drivers/gpu/drm/i915/display/intel_display_types.h
@@ -1653,6 +1653,9 @@ struct intel_dp {
struct intel_dp_pcon_frl frl;
 
struct intel_psr psr;
+
+   /* When we last wrote the OUI for eDP */
+   unsigned long last_oui_write;
 };
 
 enum lspcon_vendor {
diff --git a/drivers/gpu/drm/i915/display/intel_dp.c 
b/drivers/gpu/drm/i915/display/intel_dp.c
index 0a424bf69396..77d9a9390c1e 100644
--- a/drivers/gpu/drm/i915/display/intel_dp.c
+++ b/drivers/gpu/drm/i915/display/intel_dp.c
@@ -29,6 +29,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 
 #include 
@@ -2010,6 +2011,8 @@ intel_edp_init_source_oui(struct intel_dp *intel_dp, bool 
careful)
 
if (drm_dp_dpcd_write(_dp->aux, DP_SOURCE_OUI, oui, sizeof(oui)) 
< 0)
drm_err(>drm, "Failed to write source OUI\n");
+
+   intel_dp->last_oui_write = jiffies;
 }
 
 /* If the device supports it, try to set the power state appropriately */
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 569d17b4d00f..2c35b999ec2c 100644
--- a/drivers/gpu/drm/i915/display/intel_dp_aux_backlight.c
+++ b/drivers/gpu/drm/i915/display/intel_dp_aux_backlight.c
@@ -96,6 +96,13 @@
 #define INTEL_EDP_BRIGHTNESS_OPTIMIZATION_10x359
 
 /* Intel EDP backlight callbacks */
+static void
+wait_for_oui(struct drm_i915_private *i915, struct intel_dp *intel_dp)
+{
+   drm_dbg_kms(>drm, "Performing OUI wait\n");
+   wait_remaining_ms_from_jiffies(intel_dp->last_oui_write, 30);
+}
+
 static bool
 intel_dp_aux_supports_hdr_backlight(struct intel_connector *connector)
 {
@@ -106,6 +113,8 @@ intel_dp_aux_supports_hdr_backlight(struct intel_connector 
*connector)
int ret;
u8 tcon_cap[4];
 
+   wait_for_oui(i915, intel_dp);
+
ret = drm_dp_dpcd_read(aux, INTEL_EDP_HDR_TCON_CAP0, tcon_cap, 
sizeof(tcon_cap));
if (ret != sizeof(tcon_cap))
return false;
@@ -204,6 +213,8 @@ intel_dp_aux_hdr_enable_backlight(const struct 
intel_crtc_state *crtc_state,
int ret;
u8 old_ctrl, ctrl;
 
+   wait_for_oui(i915, intel_dp);
+
ret = drm_dp_dpcd_readb(_dp->aux, 
INTEL_EDP_HDR_GETSET_CTRL_PARAMS, _ctrl);
if (ret != 1) {
drm_err(>drm, "Failed to read current backlight control 
mode: %d\n", ret);
-- 
2.31.1

[Intel-gfx] [PATCH v5 5/5] drm/i915: Clarify probing order in intel_dp_aux_init_backlight_funcs()

[Lyude Paul]

Hooray! We've managed to hit enough bugs upstream that I've been able to
come up with a pretty solid explanation for how backlight controls are
actually supposed to be detected and used these days. As well, having the
rest of the PWM bits in VESA's backlight interface implemented seems to
have fixed all of the problematic brightness controls laptop panels that
we've hit so far.

So, let's actually document this instead of just calling the laptop panels
liars. As well, I would like to formally apologize to all of the laptop
panels I called liars. I'm sorry laptop panels, hopefully you can all
forgive me and we can move past this~

Signed-off-by: Lyude Paul 
Acked-by: Ville Syrjälä 
---
 .../drm/i915/display/intel_dp_aux_backlight.c| 16 +++-
 1 file changed, 11 insertions(+), 5 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 96fe3eaba44a..8b9c925c4c16 100644
--- a/drivers/gpu/drm/i915/display/intel_dp_aux_backlight.c
+++ b/drivers/gpu/drm/i915/display/intel_dp_aux_backlight.c
@@ -456,11 +456,17 @@ int intel_dp_aux_init_backlight_funcs(struct 
intel_connector *connector)
}
 
/*
-* A lot of eDP panels in the wild will report supporting both the
-* Intel proprietary backlight control interface, and the VESA
-* backlight control interface. Many of these panels are liars though,
-* and will only work with the Intel interface. So, always probe for
-* that first.
+* Since Intel has their own backlight control interface, the majority 
of machines out there
+* using DPCD backlight controls with Intel GPUs will be using this 
interface as opposed to
+* the VESA interface. However, other GPUs (such as Nvidia's) will 
always use the VESA
+* interface. This means that there's quite a number of panels out 
there that will advertise
+* support for both interfaces, primarily systems with Intel/Nvidia 
hybrid GPU setups.
+*
+* There's a catch to this though: on many panels that advertise 
support for both
+* interfaces, the VESA backlight interface will stop working once 
we've programmed the
+* panel with Intel's OUI - which is also required for us to be able to 
detect Intel's
+* backlight interface at all. This means that the only sensible way 
for us to detect both
+* interfaces is to probe for Intel's first, and VESA's second.
 */
if (try_intel_interface && 
intel_dp_aux_supports_hdr_backlight(connector)) {
drm_dbg_kms(dev, "Using Intel proprietary eDP backlight 
controls\n");
-- 
2.31.1

[Intel-gfx] [PATCH v5 4/5] drm/dp, drm/i915: Add support for VESA backlights using PWM for brightness control

[Lyude Paul]

Now that we've added support to i915 for controlling panel backlights that
need PWM to be enabled/disabled, let's finalize this and add support for
controlling brightness levels via PWM as well. This should hopefully put us
towards the path of supporting _ALL_ backlights via VESA's DPCD interface
which would allow us to finally start trusting the DPCD again.

Note however that we still don't enable using this by default on i915 when
it's not needed, primarily because I haven't yet had a chance to confirm if
it's safe to do this on the one machine in Intel's CI that had an issue
with this: samus-fi-bdw. I have done basic testing of this on other
machines though, by manually patching i915 to force it into PWM-only mode
on some of my laptops.

v2:
* Correct documentation (thanks Doug!)
* Get rid of backlight caps

Signed-off-by: Lyude Paul 
Reviewed-by: Doug Anderson 
Cc: Rajeev Nandan 
Cc: Satadru Pramanik 
---
 drivers/gpu/drm/drm_dp_helper.c   | 72 +--
 .../drm/i915/display/intel_dp_aux_backlight.c | 44 +---
 include/drm/drm_dp_helper.h   |  7 +-
 3 files changed, 89 insertions(+), 34 deletions(-)

diff --git a/drivers/gpu/drm/drm_dp_helper.c b/drivers/gpu/drm/drm_dp_helper.c
index af2aad2f4725..23f9073bc473 100644
--- a/drivers/gpu/drm/drm_dp_helper.c
+++ b/drivers/gpu/drm/drm_dp_helper.c
@@ -3290,6 +3290,10 @@ int drm_edp_backlight_set_level(struct drm_dp_aux *aux, 
const struct drm_edp_bac
int ret;
u8 buf[2] = { 0 };
 
+   /* The panel uses the PWM for controlling brightness levels */
+   if (!bl->aux_set)
+   return 0;
+
if (bl->lsb_reg_used) {
buf[0] = (level & 0xff00) >> 8;
buf[1] = (level & 0x00ff);
@@ -3316,7 +3320,7 @@ drm_edp_backlight_set_enable(struct drm_dp_aux *aux, 
const struct drm_edp_backli
int ret;
u8 buf;
 
-   /* The panel uses something other then DPCD for enabling its backlight 
*/
+   /* This panel uses the EDP_BL_PWR GPIO for enablement */
if (!bl->aux_enable)
return 0;
 
@@ -3351,11 +3355,11 @@ drm_edp_backlight_set_enable(struct drm_dp_aux *aux, 
const struct drm_edp_backli
  * 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. On such panels
- * _edp_backlight_info.aux_enable will be set to %false, this function 
will skip the step of
- * programming the %DP_EDP_DISPLAY_CONTROL_REGISTER, and the driver must 
perform the required
- * implementation specific step for enabling the backlight after calling this 
function.
+ * Note that certain panels do not support being enabled or disabled via DPCD, 
but instead require
+ * that the driver handle enabling/disabling the panel through 
implementation-specific means using
+ * the EDP_BL_PWR GPIO. For such panels, _edp_backlight_info.aux_enable 
will be set to %false,
+ * this function becomes a no-op, and the driver is expected to handle 
powering the panel on using
+ * the EDP_BL_PWR GPIO.
  *
  * Returns: %0 on success, negative error code on failure.
  */
@@ -3363,7 +3367,12 @@ int drm_edp_backlight_enable(struct drm_dp_aux *aux, 
const struct drm_edp_backli
 const u16 level)
 {
int ret;
-   u8 dpcd_buf = DP_EDP_BACKLIGHT_CONTROL_MODE_DPCD;
+   u8 dpcd_buf;
+
+   if (bl->aux_set)
+   dpcd_buf = DP_EDP_BACKLIGHT_CONTROL_MODE_DPCD;
+   else
+   dpcd_buf = DP_EDP_BACKLIGHT_CONTROL_MODE_PWM;
 
if (bl->pwmgen_bit_count) {
ret = drm_dp_dpcd_writeb(aux, DP_EDP_PWMGEN_BIT_COUNT, 
bl->pwmgen_bit_count);
@@ -3405,12 +3414,13 @@ EXPORT_SYMBOL(drm_edp_backlight_enable);
  * @aux: The DP AUX channel to use
  * @bl: Backlight capability info from drm_edp_backlight_init()
  *
- * This function handles disabling DPCD backlight controls on a panel over 
AUX. Note that some
- * panels have backlights that are enabled/disabled by other means, despite 
having their brightness
- * values controlled through DPCD. On such panels 
_edp_backlight_info.aux_enable will be set to
- * %false, this function will become a no-op (and we will skip updating
- * %DP_EDP_DISPLAY_CONTROL_REGISTER), and the driver must take care to perform 
it's own
- * implementation specific step for disabling the backlight.
+ * This function handles disabling DPCD backlight controls on a panel over AUX.
+ *
+ * Note that certain panels do not support being enabled or disabled via DPCD, 
but instead require
+ * that the driver handle enabling/disabling the panel through 
implementation-specific means using
+ * the EDP_BL_PWR GPIO. For such panels, _edp_backlight_info.aux_enable 
will be set to %false,
+

[Intel-gfx] [PATCH v5 3/5] drm/dp: Don't read back backlight mode in drm_edp_backlight_enable()

[Lyude Paul]

As it turns out, apparently some machines will actually leave additional
backlight functionality like dynamic backlight control on before the OS
loads. Currently we don't take care to disable unsupported features when
writing back the backlight mode, which can lead to some rather strange
looking behavior when adjusting the backlight.

So, let's fix this by just not reading back the current backlight mode on
initial enable. I don't think there should really be any downsides to this,
and this will ensure we don't leave any unsupported functionality enabled.

This should fix at least one (but not all) of the issues seen with DPCD
backlight support on fi-bdw-samus

v5:
* Just avoid reading back DPCD register - Doug Anderson

Signed-off-by: Lyude Paul 
Fixes: 867cf9cd73c3 ("drm/dp: Extract i915's eDP backlight code into DRM 
helpers")
---
 drivers/gpu/drm/drm_dp_helper.c | 40 ++---
 1 file changed, 12 insertions(+), 28 deletions(-)

diff --git a/drivers/gpu/drm/drm_dp_helper.c b/drivers/gpu/drm/drm_dp_helper.c
index ada0a1ff262d..af2aad2f4725 100644
--- a/drivers/gpu/drm/drm_dp_helper.c
+++ b/drivers/gpu/drm/drm_dp_helper.c
@@ -3363,27 +3363,13 @@ int drm_edp_backlight_enable(struct drm_dp_aux *aux, 
const struct drm_edp_backli
 const u16 level)
 {
int ret;
-   u8 dpcd_buf, new_dpcd_buf;
+   u8 dpcd_buf = DP_EDP_BACKLIGHT_CONTROL_MODE_DPCD;
 
-   ret = drm_dp_dpcd_readb(aux, DP_EDP_BACKLIGHT_MODE_SET_REGISTER, 
_buf);
-   if (ret != 1) {
-   drm_dbg_kms(aux->drm_dev,
-   "%s: Failed to read backlight mode: %d\n", 
aux->name, ret);
-   return ret < 0 ? ret : -EIO;
-   }
-
-   new_dpcd_buf = dpcd_buf;
-
-   if ((dpcd_buf & DP_EDP_BACKLIGHT_CONTROL_MODE_MASK) != 
DP_EDP_BACKLIGHT_CONTROL_MODE_DPCD) {
-   new_dpcd_buf &= ~DP_EDP_BACKLIGHT_CONTROL_MODE_MASK;
-   new_dpcd_buf |= DP_EDP_BACKLIGHT_CONTROL_MODE_DPCD;
-
-   if (bl->pwmgen_bit_count) {
-   ret = drm_dp_dpcd_writeb(aux, DP_EDP_PWMGEN_BIT_COUNT, 
bl->pwmgen_bit_count);
-   if (ret != 1)
-   drm_dbg_kms(aux->drm_dev, "%s: Failed to write 
aux pwmgen bit count: %d\n",
-   aux->name, ret);
-   }
+   if (bl->pwmgen_bit_count) {
+   ret = drm_dp_dpcd_writeb(aux, DP_EDP_PWMGEN_BIT_COUNT, 
bl->pwmgen_bit_count);
+   if (ret != 1)
+   drm_dbg_kms(aux->drm_dev, "%s: Failed to write aux 
pwmgen bit count: %d\n",
+   aux->name, ret);
}
 
if (bl->pwm_freq_pre_divider) {
@@ -3393,16 +3379,14 @@ int drm_edp_backlight_enable(struct drm_dp_aux *aux, 
const struct drm_edp_backli
"%s: Failed to write aux backlight 
frequency: %d\n",
aux->name, ret);
else
-   new_dpcd_buf |= DP_EDP_BACKLIGHT_FREQ_AUX_SET_ENABLE;
+   dpcd_buf |= DP_EDP_BACKLIGHT_FREQ_AUX_SET_ENABLE;
}
 
-   if (new_dpcd_buf != dpcd_buf) {
-   ret = drm_dp_dpcd_writeb(aux, 
DP_EDP_BACKLIGHT_MODE_SET_REGISTER, new_dpcd_buf);
-   if (ret != 1) {
-   drm_dbg_kms(aux->drm_dev, "%s: Failed to write aux 
backlight mode: %d\n",
-   aux->name, ret);
-   return ret < 0 ? ret : -EIO;
-   }
+   ret = drm_dp_dpcd_writeb(aux, DP_EDP_BACKLIGHT_MODE_SET_REGISTER, 
dpcd_buf);
+   if (ret != 1) {
+   drm_dbg_kms(aux->drm_dev, "%s: Failed to write aux backlight 
mode: %d\n",
+   aux->name, ret);
+   return ret < 0 ? ret : -EIO;
}
 
ret = drm_edp_backlight_set_level(aux, bl, level);
-- 
2.31.1

[Intel-gfx] [PATCH v5 2/5] drm/nouveau/kms/nv50-: Explicitly check DPCD backlights for aux enable/brightness

[Lyude Paul]

Since we don't support hybrid AUX/PWM backlights in nouveau right now,
let's add some explicit checks so that we don't break nouveau once we
enable support for these backlights in other drivers.

Reviewed-by: Karol Herbst 
Signed-off-by: Lyude Paul 
---
 drivers/gpu/drm/nouveau/nouveau_backlight.c | 5 -
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/nouveau/nouveau_backlight.c 
b/drivers/gpu/drm/nouveau/nouveau_backlight.c
index 1cbd71abc80a..ae2f2abc8f5a 100644
--- a/drivers/gpu/drm/nouveau/nouveau_backlight.c
+++ b/drivers/gpu/drm/nouveau/nouveau_backlight.c
@@ -308,7 +308,10 @@ nv50_backlight_init(struct nouveau_backlight *bl,
if (ret < 0)
return ret;
 
-   if (drm_edp_backlight_supported(edp_dpcd)) {
+   /* TODO: Add support for hybrid PWM/DPCD panels */
+   if (drm_edp_backlight_supported(edp_dpcd) &&
+   (edp_dpcd[1] & DP_EDP_BACKLIGHT_AUX_ENABLE_CAP) &&
+   (edp_dpcd[2] & DP_EDP_BACKLIGHT_BRIGHTNESS_AUX_SET_CAP)) {
NV_DEBUG(drm, "DPCD backlight controls supported on 
%s\n",
 nv_conn->base.name);
 
-- 
2.31.1

[Intel-gfx] [PATCH v5 1/5] drm/i915: Add support for panels with VESA backlights with PWM enable/disable

[Lyude Paul]

This simply adds proper support for panel backlights that can be controlled
via VESA's backlight control protocol, but which also require that we
enable and disable the backlight via PWM instead of via the DPCD interface.
We also enable this by default, in order to fix some people's backlights
that were broken by not having this enabled.

For reference, backlights that require this and use VESA's backlight
interface tend to be laptops with hybrid GPUs, but this very well may
change in the future.

v4:
* Make sure that we call intel_backlight_level_to_pwm() in
  intel_dp_aux_vesa_enable_backlight() - vsyrjala

Signed-off-by: Lyude Paul 
Link: https://gitlab.freedesktop.org/drm/intel/-/issues/3680
Fixes: fe7d52bccab6 ("drm/i915/dp: Don't use DPCD backlights that need PWM 
enable/disable")
Reviewed-by: Ville Syrjälä 
Cc:  # v5.12+
---
 .../drm/i915/display/intel_dp_aux_backlight.c | 27 ++-
 1 file changed, 21 insertions(+), 6 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 569d17b4d00f..f05b71c01b8e 100644
--- a/drivers/gpu/drm/i915/display/intel_dp_aux_backlight.c
+++ b/drivers/gpu/drm/i915/display/intel_dp_aux_backlight.c
@@ -293,6 +293,13 @@ intel_dp_aux_vesa_enable_backlight(const struct 
intel_crtc_state *crtc_state,
struct intel_panel *panel = >panel;
struct intel_dp *intel_dp = enc_to_intel_dp(connector->encoder);
 
+   if (!panel->backlight.edp.vesa.info.aux_enable) {
+   u32 pwm_level = intel_backlight_invert_pwm_level(connector,
+
panel->backlight.pwm_level_max);
+
+   panel->backlight.pwm_funcs->enable(crtc_state, conn_state, 
pwm_level);
+   }
+
drm_edp_backlight_enable(_dp->aux, 
>backlight.edp.vesa.info, level);
 }
 
@@ -304,6 +311,10 @@ static void intel_dp_aux_vesa_disable_backlight(const 
struct drm_connector_state
struct intel_dp *intel_dp = enc_to_intel_dp(connector->encoder);
 
drm_edp_backlight_disable(_dp->aux, 
>backlight.edp.vesa.info);
+
+   if (!panel->backlight.edp.vesa.info.aux_enable)
+   panel->backlight.pwm_funcs->disable(old_conn_state,
+   
intel_backlight_invert_pwm_level(connector, 0));
 }
 
 static int intel_dp_aux_vesa_setup_backlight(struct intel_connector 
*connector, enum pipe pipe)
@@ -321,6 +332,15 @@ static int intel_dp_aux_vesa_setup_backlight(struct 
intel_connector *connector,
if (ret < 0)
return ret;
 
+   if (!panel->backlight.edp.vesa.info.aux_enable) {
+   ret = panel->backlight.pwm_funcs->setup(connector, pipe);
+   if (ret < 0) {
+   drm_err(>drm,
+   "Failed to setup PWM backlight controls for eDP 
backlight: %d\n",
+   ret);
+   return ret;
+   }
+   }
panel->backlight.max = panel->backlight.edp.vesa.info.max;
panel->backlight.min = 0;
if (current_mode == DP_EDP_BACKLIGHT_CONTROL_MODE_DPCD) {
@@ -340,12 +360,7 @@ intel_dp_aux_supports_vesa_backlight(struct 
intel_connector *connector)
struct intel_dp *intel_dp = intel_attached_dp(connector);
struct drm_i915_private *i915 = dp_to_i915(intel_dp);
 
-   /* TODO: We currently only support AUX only backlight configurations, 
not backlights which
-* require a mix of PWM and AUX controls to work. In the mean time, 
these machines typically
-* work just fine using normal PWM controls anyway.
-*/
-   if ((intel_dp->edp_dpcd[1] & DP_EDP_BACKLIGHT_AUX_ENABLE_CAP) &&
-   drm_edp_backlight_supported(intel_dp->edp_dpcd)) {
+   if (drm_edp_backlight_supported(intel_dp->edp_dpcd)) {
drm_dbg_kms(>drm, "AUX Backlight Control Supported!\n");
return true;
}
-- 
2.31.1

[Intel-gfx] [PATCH v5 0/5] drm/dp, drm/i915: Finish basic PWM support for VESA backlight helpers

[Lyude Paul]

When I originally moved all of the VESA backlight code in i915 into DRM
helpers, one of the things I didn't have the hardware or time for
testing was machines that used a combination of PWM and DPCD in order to
control their backlights. This has since then caused some breakages and
resulted in us disabling DPCD backlight support on such machines. This
works fine, unless you have a machine that actually needs this
functionality for backlight controls to work at all. Additionally, we
will need to support PWM for when we start adding support for VESA's
product (as in the product of multiplication) control mode for better
brightness ranges.

So - let's finally finish up implementing basic support for these types
of backlights to solve these problems in our DP helpers, along with
implementing support for this in i915. And since digging into this issue
solved the last questions we really had about probing backlights in i915
for the most part, let's update some of the comments around that as
well!

Lyude Paul (5):
  drm/i915: Add support for panels with VESA backlights with PWM
enable/disable
  drm/nouveau/kms/nv50-: Explicitly check DPCD backlights for aux
enable/brightness
  drm/dp: Don't read back backlight mode in drm_edp_backlight_enable()
  drm/dp, drm/i915: Add support for VESA backlights using PWM for
brightness control
  drm/i915: Clarify probing order in intel_dp_aux_init_backlight_funcs()

 drivers/gpu/drm/drm_dp_helper.c   | 108 ++
 .../drm/i915/display/intel_dp_aux_backlight.c |  81 ++---
 drivers/gpu/drm/nouveau/nouveau_backlight.c   |   5 +-
 include/drm/drm_dp_helper.h   |   7 +-
 4 files changed, 132 insertions(+), 69 deletions(-)

-- 
2.31.1

Re: [Intel-gfx] [PULL] topic/amdgpu-dp2.0-mst

[Lyude Paul]

JFYI - the wrapping was because of evolution, sorry about that. Going to make
sure that gets fixed the next time I have to send out a topic branch

On Fri, 2021-10-29 at 13:35 +0300, Jani Nikula wrote:
> On Fri, 29 Oct 2021, Jani Nikula  wrote:
> > On Wed, 27 Oct 2021, Lyude Paul  wrote:
> > > topic/amdgpu-dp2.0-mst-2021-10-27:
> > > UAPI Changes:
> > > Nope!
> > > 
> > > Cross-subsystem Changes:
> > > drm_dp_update_payload_part1() takes a new argument for specifying what
> > > the
> > > VCPI slot start is
> > > 
> > > Core Changes:
> > > Make the DP MST helpers aware of the current starting VCPI slot/VCPI
> > > total
> > > slot count...
> > > 
> > > Driver Changes:
> > > ...and then add support for taking advantage of this for 128b/132b links
> > > on DP
> > > 2.0 for amdgpu
> > > The following changes since commit
> > > 6f2f7c83303d2227f47551423e507d77d9ea01c7:
> > > 
> > >   Merge tag 'drm-intel-gt-next-2021-10-21' of
> > > git://anongit.freedesktop.org/drm/drm-intel into drm-next (2021-10-22
> > > 06:30:34
> > > +1000)
> > > 
> > > are available in the Git repository at:
> > > 
> > >   git://anongit.freedesktop.org/drm/drm-misc tags/topic/amdgpu-dp2.0-
> > > mst-2021-
> > > 10-27
> > 
> > I'm curious, how did you generate and send this pull request? The lines
> > are wrapped with newlines, and you have non-breaking spaces instead of
> > regular spaces there.
> > 
> > So for me this fails with:
> > 
> > Pulling   git://anongit.freedesktop.org/drm/drm-misc tags/topic/amdgpu-
> > dp2.0-mst-2021- 10-27 ...
> > fatal: invalid refspec 'git://anongit.freedesktop.org/drm/drm-misc'
> 
> Fixed manually, but I can't pull this into drm-intel-next directly after
> all, because the baseline is not in drm-intel-next history. The diffstat
> for drm-intel-next is:
> 
> 65 files changed, 3656 insertions(+), 780 deletions(-)
> 
> I asked for this to be a topic branch so I could pull it into
> drm-intel-next. I guess I'll just have to do a drm-next backmerge
> instead.
> 
> BR,
> Jani.
> 
> 
> > 
> > BR,
> > Jani.
> > 
> > 
> > > 
> > > for you to fetch changes up to 00f965e700ef5aa2d889e7e65c7458531d2a4bcf:
> > > 
> > >   drm/amdgpu/display: fix build when CONFIG_DRM_AMD_DC_DCN is not set
> > > (2021-
> > > 10-27 19:50:26 -0400)
> > > 
> > > 
> > > UAPI Changes:
> > > Nope!
> > > 
> > > Cross-subsystem Changes:
> > > drm_dp_update_payload_part1() takes a new argument for specifying what
> > > the
> > > VCPI slot start is
> > > 
> > > Core Changes:
> > > Make the DP MST helpers aware of the current starting VCPI slot/VCPI
> > > total
> > > slot count...
> > > 
> > > Driver Changes:
> > > ...and then add support for taking advantage of this for 128b/132b links
> > > on DP
> > > 2.0 for amdgpu
> > > 
> > > 
> > > Alex Deucher (1):
> > >   drm/amdgpu/display: fix build when CONFIG_DRM_AMD_DC_DCN is not
> > > set
> > > 
> > > Bhawanpreet Lakha (3):
> > >   drm: Remove slot checks in dp mst topology during commit
> > >   drm: Update MST First Link Slot Information Based on Encoding
> > > Format
> > >   drm/amd/display: Add DP 2.0 MST DM Support
> > > 
> > > Fangzhi Zuo (1):
> > >   drm/amd/display: Add DP 2.0 MST DC Support
> > > 
> > >  drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c  |  29 ++
> > >  .../drm/amd/display/amdgpu_dm/amdgpu_dm_debugfs.c  |   3 +
> > >  .../drm/amd/display/amdgpu_dm/amdgpu_dm_helpers.c  |   7 +-
> > >  drivers/gpu/drm/amd/display/dc/core/dc.c   |  14 +
> > >  drivers/gpu/drm/amd/display/dc/core/dc_link.c  | 292
> > > +
> > >  drivers/gpu/drm/amd/display/dc/core/dc_link_dp.c   |  19 ++
> > >  drivers/gpu/drm/amd/display/dc/dc_link.h   |   7 +
> > >  drivers/gpu/drm/amd/display/dc/dc_stream.h |  13 +
> > >  drivers/gpu/drm/drm_dp_mst_topology.c  |  42 ++-
> > >  drivers/gpu/drm/i915/display/intel_dp_mst.c    |   4 +-
> > >  drivers/gpu/drm/nouveau/dispnv50/disp.c    |   2 +-
> > >  drivers/gpu/drm/radeon/radeon_dp_mst.c |   4 +-
> > >  include/drm/drm_dp_mst_helper.h    |   5 +-
> > >  13 files changed, 425 insertions(+), 16 deletions(-)
> 

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

Re: [Intel-gfx] [PATCH v4 3/5] drm/dp: Disable unsupported features in DP_EDP_BACKLIGHT_MODE_SET_REGISTER

[Lyude Paul]

On Thu, 2021-10-28 at 11:27 -0700, Doug Anderson wrote:
> Hi,
> 
> On Tue, Oct 26, 2021 at 3:09 PM Lyude Paul  wrote:
> > 
> > As it turns out, apparently some machines will actually leave additional
> > backlight functionality like dynamic backlight control on before the OS
> > loads. Currently we don't take care to disable unsupported features when
> > writing back the backlight mode, which can lead to some rather strange
> > looking behavior when adjusting the backlight.
> > 
> > So, let's fix this by ensuring we only keep supported features enabled for
> > panel backlights - which should fix some of the issues we were seeing from
> > this on fi-bdw-samus.
> > 
> > Signed-off-by: Lyude Paul 
> > Fixes: 867cf9cd73c3 ("drm/dp: Extract i915's eDP backlight code into DRM
> > helpers")
> > ---
> >  drivers/gpu/drm/drm_dp_helper.c | 6 +-
> >  1 file changed, 5 insertions(+), 1 deletion(-)
> > 
> > diff --git a/drivers/gpu/drm/drm_dp_helper.c
> > b/drivers/gpu/drm/drm_dp_helper.c
> > index ada0a1ff262d..8f2032a955cf 100644
> > --- a/drivers/gpu/drm/drm_dp_helper.c
> > +++ b/drivers/gpu/drm/drm_dp_helper.c
> > @@ -3372,7 +3372,9 @@ int drm_edp_backlight_enable(struct drm_dp_aux *aux,
> > const struct drm_edp_backli
> >     return ret < 0 ? ret : -EIO;
> >     }
> > 
> > -   new_dpcd_buf = dpcd_buf;
> > +   /* Disable any backlight functionality we don't support that might
> > be on */
> > +   new_dpcd_buf = dpcd_buf & (DP_EDP_BACKLIGHT_CONTROL_MODE_MASK |
> > +  DP_EDP_BACKLIGHT_FREQ_AUX_SET_ENABLE);
> 
> My first thought when reading the above was: if we're masking so much
> stuff out, why do we bother reading the old value back out at all?
> 
> I guess the two places you use the old value for are:
> 
> 1. You avoid setting the "DP_EDP_PWMGEN_BIT_COUNT" if the backlight
> was already configured for DPCD mode.
> 
> 2. You avoid writing the register if you didn't change it.
> 
> I would actually argue that use #1 is probably a bug. If you're
> worried about the firmware leaving the backlight configured in a
> strange way, it could very well have left the backlight configured in
> DPCD mode but set a different "bit count" than you want, right? Maybe
> you should just always set the bit count?
> 
> Use #2 is fine, but does it buy you anything? Are writes to the DCPD
> bus somehow more expensive than reads? ...or maybe you're expecting
> that a display will glitch / act badly if you write the same value
> that's already there?
> 
> 
> So I guess my instinct here is that you should avoid reading all
> together and just program the value you want.

Good point, will respin this in a little bit

> 
> -Doug
> 

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

[Intel-gfx] [PULL] topic/amdgpu-dp2.0-mst

[Lyude Paul]

topic/amdgpu-dp2.0-mst-2021-10-27:
UAPI Changes:
Nope!

Cross-subsystem Changes:
drm_dp_update_payload_part1() takes a new argument for specifying what the
VCPI slot start is

Core Changes:
Make the DP MST helpers aware of the current starting VCPI slot/VCPI total
slot count...

Driver Changes:
...and then add support for taking advantage of this for 128b/132b links on DP
2.0 for amdgpu
The following changes since commit 6f2f7c83303d2227f47551423e507d77d9ea01c7:

  Merge tag 'drm-intel-gt-next-2021-10-21' of
git://anongit.freedesktop.org/drm/drm-intel into drm-next (2021-10-22 06:30:34
+1000)

are available in the Git repository at:

  git://anongit.freedesktop.org/drm/drm-misc tags/topic/amdgpu-dp2.0-mst-2021-
10-27

for you to fetch changes up to 00f965e700ef5aa2d889e7e65c7458531d2a4bcf:

  drm/amdgpu/display: fix build when CONFIG_DRM_AMD_DC_DCN is not set (2021-
10-27 19:50:26 -0400)


UAPI Changes:
Nope!

Cross-subsystem Changes:
drm_dp_update_payload_part1() takes a new argument for specifying what the
VCPI slot start is

Core Changes:
Make the DP MST helpers aware of the current starting VCPI slot/VCPI total
slot count...

Driver Changes:
...and then add support for taking advantage of this for 128b/132b links on DP
2.0 for amdgpu


Alex Deucher (1):
  drm/amdgpu/display: fix build when CONFIG_DRM_AMD_DC_DCN is not set

Bhawanpreet Lakha (3):
  drm: Remove slot checks in dp mst topology during commit
  drm: Update MST First Link Slot Information Based on Encoding Format
  drm/amd/display: Add DP 2.0 MST DM Support

Fangzhi Zuo (1):
  drm/amd/display: Add DP 2.0 MST DC Support

 drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c  |  29 ++
 .../drm/amd/display/amdgpu_dm/amdgpu_dm_debugfs.c  |   3 +
 .../drm/amd/display/amdgpu_dm/amdgpu_dm_helpers.c  |   7 +-
 drivers/gpu/drm/amd/display/dc/core/dc.c   |  14 +
 drivers/gpu/drm/amd/display/dc/core/dc_link.c  | 292
+
 drivers/gpu/drm/amd/display/dc/core/dc_link_dp.c   |  19 ++
 drivers/gpu/drm/amd/display/dc/dc_link.h   |   7 +
 drivers/gpu/drm/amd/display/dc/dc_stream.h |  13 +
 drivers/gpu/drm/drm_dp_mst_topology.c  |  42 ++-
 drivers/gpu/drm/i915/display/intel_dp_mst.c    |   4 +-
 drivers/gpu/drm/nouveau/dispnv50/disp.c    |   2 +-
 drivers/gpu/drm/radeon/radeon_dp_mst.c |   4 +-
 include/drm/drm_dp_mst_helper.h    |   5 +-
 13 files changed, 425 insertions(+), 16 deletions(-)

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

Re: [Intel-gfx] [PULL] topic/amdgpu-dp2.0-mst

[Lyude Paul]

This was for airlied to pull into drm-next

On Wed, 2021-10-27 at 09:18 +0200, Maxime Ripard wrote:
> Hi Lyude,
> 
> On Mon, Oct 25, 2021 at 09:30:14PM -0400, Lyude Paul wrote:
> > topic/amdgpu-dp2.0-mst-2021-10-25:
> > UAPI Changes:
> > Nope!
> > 
> > Cross-subsystem Changes:
> > drm_dp_update_payload_part1() takes a new argument for specifying what the
> > VCPI slot start is
> > 
> > Core Changes:
> > Make the DP MST helpers aware of the current starting VCPI slot/VCPI total
> > slot count...
> > 
> > Driver Changes:
> > ...and then add support for taking advantage of this for 128b/132b links
> > on DP
> > 2.0 for amdgpu
> 
> It's not really clear to me what branch it should be pulled in? is it
> for drm-misc-next?
> 
> Thanks!
> Maxime

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

[Intel-gfx] [PATCH v4 5/5] drm/i915: Clarify probing order in intel_dp_aux_init_backlight_funcs()

[Lyude Paul]

Hooray! We've managed to hit enough bugs upstream that I've been able to
come up with a pretty solid explanation for how backlight controls are
actually supposed to be detected and used these days. As well, having the
rest of the PWM bits in VESA's backlight interface implemented seems to
have fixed all of the problematic brightness controls laptop panels that
we've hit so far.

So, let's actually document this instead of just calling the laptop panels
liars. As well, I would like to formally apologize to all of the laptop
panels I called liars. I'm sorry laptop panels, hopefully you can all
forgive me and we can move past this~

Signed-off-by: Lyude Paul 
Acked-by: Ville Syrjälä 
---
 .../drm/i915/display/intel_dp_aux_backlight.c| 16 +++-
 1 file changed, 11 insertions(+), 5 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 96fe3eaba44a..8b9c925c4c16 100644
--- a/drivers/gpu/drm/i915/display/intel_dp_aux_backlight.c
+++ b/drivers/gpu/drm/i915/display/intel_dp_aux_backlight.c
@@ -456,11 +456,17 @@ int intel_dp_aux_init_backlight_funcs(struct 
intel_connector *connector)
}
 
/*
-* A lot of eDP panels in the wild will report supporting both the
-* Intel proprietary backlight control interface, and the VESA
-* backlight control interface. Many of these panels are liars though,
-* and will only work with the Intel interface. So, always probe for
-* that first.
+* Since Intel has their own backlight control interface, the majority 
of machines out there
+* using DPCD backlight controls with Intel GPUs will be using this 
interface as opposed to
+* the VESA interface. However, other GPUs (such as Nvidia's) will 
always use the VESA
+* interface. This means that there's quite a number of panels out 
there that will advertise
+* support for both interfaces, primarily systems with Intel/Nvidia 
hybrid GPU setups.
+*
+* There's a catch to this though: on many panels that advertise 
support for both
+* interfaces, the VESA backlight interface will stop working once 
we've programmed the
+* panel with Intel's OUI - which is also required for us to be able to 
detect Intel's
+* backlight interface at all. This means that the only sensible way 
for us to detect both
+* interfaces is to probe for Intel's first, and VESA's second.
 */
if (try_intel_interface && 
intel_dp_aux_supports_hdr_backlight(connector)) {
drm_dbg_kms(dev, "Using Intel proprietary eDP backlight 
controls\n");
-- 
2.31.1

[Intel-gfx] [PATCH v4 4/5] drm/dp, drm/i915: Add support for VESA backlights using PWM for brightness control

[Lyude Paul]

Now that we've added support to i915 for controlling panel backlights that
need PWM to be enabled/disabled, let's finalize this and add support for
controlling brightness levels via PWM as well. This should hopefully put us
towards the path of supporting _ALL_ backlights via VESA's DPCD interface
which would allow us to finally start trusting the DPCD again.

Note however that we still don't enable using this by default on i915 when
it's not needed, primarily because I haven't yet had a chance to confirm if
it's safe to do this on the one machine in Intel's CI that had an issue
with this: samus-fi-bdw. I have done basic testing of this on other
machines though, by manually patching i915 to force it into PWM-only mode
on some of my laptops.

v2:
* Correct documentation (thanks Doug!)
* Get rid of backlight caps

Signed-off-by: Lyude Paul 
Reviewed-by: Doug Anderson 
Cc: Rajeev Nandan 
Cc: Satadru Pramanik 
---
 drivers/gpu/drm/drm_dp_helper.c   | 76 +--
 .../drm/i915/display/intel_dp_aux_backlight.c | 44 ---
 include/drm/drm_dp_helper.h   |  7 +-
 3 files changed, 91 insertions(+), 36 deletions(-)

diff --git a/drivers/gpu/drm/drm_dp_helper.c b/drivers/gpu/drm/drm_dp_helper.c
index 8f2032a955cf..b91b092e10f0 100644
--- a/drivers/gpu/drm/drm_dp_helper.c
+++ b/drivers/gpu/drm/drm_dp_helper.c
@@ -3290,6 +3290,10 @@ int drm_edp_backlight_set_level(struct drm_dp_aux *aux, 
const struct drm_edp_bac
int ret;
u8 buf[2] = { 0 };
 
+   /* The panel uses the PWM for controlling brightness levels */
+   if (!bl->aux_set)
+   return 0;
+
if (bl->lsb_reg_used) {
buf[0] = (level & 0xff00) >> 8;
buf[1] = (level & 0x00ff);
@@ -3316,7 +3320,7 @@ drm_edp_backlight_set_enable(struct drm_dp_aux *aux, 
const struct drm_edp_backli
int ret;
u8 buf;
 
-   /* The panel uses something other then DPCD for enabling its backlight 
*/
+   /* This panel uses the EDP_BL_PWR GPIO for enablement */
if (!bl->aux_enable)
return 0;
 
@@ -3351,11 +3355,11 @@ drm_edp_backlight_set_enable(struct drm_dp_aux *aux, 
const struct drm_edp_backli
  * 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. On such panels
- * _edp_backlight_info.aux_enable will be set to %false, this function 
will skip the step of
- * programming the %DP_EDP_DISPLAY_CONTROL_REGISTER, and the driver must 
perform the required
- * implementation specific step for enabling the backlight after calling this 
function.
+ * Note that certain panels do not support being enabled or disabled via DPCD, 
but instead require
+ * that the driver handle enabling/disabling the panel through 
implementation-specific means using
+ * the EDP_BL_PWR GPIO. For such panels, _edp_backlight_info.aux_enable 
will be set to %false,
+ * this function becomes a no-op, and the driver is expected to handle 
powering the panel on using
+ * the EDP_BL_PWR GPIO.
  *
  * Returns: %0 on success, negative error code on failure.
  */
@@ -3363,7 +3367,7 @@ int drm_edp_backlight_enable(struct drm_dp_aux *aux, 
const struct drm_edp_backli
 const u16 level)
 {
int ret;
-   u8 dpcd_buf, new_dpcd_buf;
+   u8 dpcd_buf, new_dpcd_buf, new_mode;
 
ret = drm_dp_dpcd_readb(aux, DP_EDP_BACKLIGHT_MODE_SET_REGISTER, 
_buf);
if (ret != 1) {
@@ -3376,9 +3380,14 @@ int drm_edp_backlight_enable(struct drm_dp_aux *aux, 
const struct drm_edp_backli
new_dpcd_buf = dpcd_buf & (DP_EDP_BACKLIGHT_CONTROL_MODE_MASK |
   DP_EDP_BACKLIGHT_FREQ_AUX_SET_ENABLE);
 
-   if ((dpcd_buf & DP_EDP_BACKLIGHT_CONTROL_MODE_MASK) != 
DP_EDP_BACKLIGHT_CONTROL_MODE_DPCD) {
+   if (bl->aux_set)
+   new_mode = DP_EDP_BACKLIGHT_CONTROL_MODE_DPCD;
+   else
+   new_mode = DP_EDP_BACKLIGHT_CONTROL_MODE_PWM;
+
+   if ((dpcd_buf & DP_EDP_BACKLIGHT_CONTROL_MODE_MASK) != new_mode) {
new_dpcd_buf &= ~DP_EDP_BACKLIGHT_CONTROL_MODE_MASK;
-   new_dpcd_buf |= DP_EDP_BACKLIGHT_CONTROL_MODE_DPCD;
+   new_dpcd_buf |= new_mode;
 
if (bl->pwmgen_bit_count) {
ret = drm_dp_dpcd_writeb(aux, DP_EDP_PWMGEN_BIT_COUNT, 
bl->pwmgen_bit_count);
@@ -3425,12 +3434,13 @@ EXPORT_SYMBOL(drm_edp_backlight_enable);
  * @aux: The DP AUX channel to use
  * @bl: Backlight capability info from drm_edp_backlight_init()
  *
- * This function handles disabling DPCD backlight controls on a panel over 
AUX. Note that some
- * panels have backlights that are enabled/disabled by other me

[Intel-gfx] [PATCH v4 2/5] drm/nouveau/kms/nv50-: Explicitly check DPCD backlights for aux enable/brightness

[Lyude Paul]

Since we don't support hybrid AUX/PWM backlights in nouveau right now,
let's add some explicit checks so that we don't break nouveau once we
enable support for these backlights in other drivers.

Signed-off-by: Lyude Paul 
---
 drivers/gpu/drm/nouveau/nouveau_backlight.c | 5 -
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/nouveau/nouveau_backlight.c 
b/drivers/gpu/drm/nouveau/nouveau_backlight.c
index 1cbd71abc80a..ae2f2abc8f5a 100644
--- a/drivers/gpu/drm/nouveau/nouveau_backlight.c
+++ b/drivers/gpu/drm/nouveau/nouveau_backlight.c
@@ -308,7 +308,10 @@ nv50_backlight_init(struct nouveau_backlight *bl,
if (ret < 0)
return ret;
 
-   if (drm_edp_backlight_supported(edp_dpcd)) {
+   /* TODO: Add support for hybrid PWM/DPCD panels */
+   if (drm_edp_backlight_supported(edp_dpcd) &&
+   (edp_dpcd[1] & DP_EDP_BACKLIGHT_AUX_ENABLE_CAP) &&
+   (edp_dpcd[2] & DP_EDP_BACKLIGHT_BRIGHTNESS_AUX_SET_CAP)) {
NV_DEBUG(drm, "DPCD backlight controls supported on 
%s\n",
 nv_conn->base.name);
 
-- 
2.31.1

[Intel-gfx] [PATCH v4 3/5] drm/dp: Disable unsupported features in DP_EDP_BACKLIGHT_MODE_SET_REGISTER

[Lyude Paul]

As it turns out, apparently some machines will actually leave additional
backlight functionality like dynamic backlight control on before the OS
loads. Currently we don't take care to disable unsupported features when
writing back the backlight mode, which can lead to some rather strange
looking behavior when adjusting the backlight.

So, let's fix this by ensuring we only keep supported features enabled for
panel backlights - which should fix some of the issues we were seeing from
this on fi-bdw-samus.

Signed-off-by: Lyude Paul 
Fixes: 867cf9cd73c3 ("drm/dp: Extract i915's eDP backlight code into DRM 
helpers")
---
 drivers/gpu/drm/drm_dp_helper.c | 6 +-
 1 file changed, 5 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/drm_dp_helper.c b/drivers/gpu/drm/drm_dp_helper.c
index ada0a1ff262d..8f2032a955cf 100644
--- a/drivers/gpu/drm/drm_dp_helper.c
+++ b/drivers/gpu/drm/drm_dp_helper.c
@@ -3372,7 +3372,9 @@ int drm_edp_backlight_enable(struct drm_dp_aux *aux, 
const struct drm_edp_backli
return ret < 0 ? ret : -EIO;
}
 
-   new_dpcd_buf = dpcd_buf;
+   /* Disable any backlight functionality we don't support that might be 
on */
+   new_dpcd_buf = dpcd_buf & (DP_EDP_BACKLIGHT_CONTROL_MODE_MASK |
+  DP_EDP_BACKLIGHT_FREQ_AUX_SET_ENABLE);
 
if ((dpcd_buf & DP_EDP_BACKLIGHT_CONTROL_MODE_MASK) != 
DP_EDP_BACKLIGHT_CONTROL_MODE_DPCD) {
new_dpcd_buf &= ~DP_EDP_BACKLIGHT_CONTROL_MODE_MASK;
@@ -3394,6 +3396,8 @@ int drm_edp_backlight_enable(struct drm_dp_aux *aux, 
const struct drm_edp_backli
aux->name, ret);
else
new_dpcd_buf |= DP_EDP_BACKLIGHT_FREQ_AUX_SET_ENABLE;
+   } else {
+   new_dpcd_buf &= ~DP_EDP_BACKLIGHT_FREQ_AUX_SET_ENABLE;
}
 
if (new_dpcd_buf != dpcd_buf) {
-- 
2.31.1

[Intel-gfx] [PATCH v4 1/5] drm/i915: Add support for panels with VESA backlights with PWM enable/disable

[Lyude Paul]

This simply adds proper support for panel backlights that can be controlled
via VESA's backlight control protocol, but which also require that we
enable and disable the backlight via PWM instead of via the DPCD interface.
We also enable this by default, in order to fix some people's backlights
that were broken by not having this enabled.

For reference, backlights that require this and use VESA's backlight
interface tend to be laptops with hybrid GPUs, but this very well may
change in the future.

v4:
* Make sure that we call intel_backlight_level_to_pwm() in
  intel_dp_aux_vesa_enable_backlight() - vsyrjala

Signed-off-by: Lyude Paul 
Link: https://gitlab.freedesktop.org/drm/intel/-/issues/3680
Fixes: fe7d52bccab6 ("drm/i915/dp: Don't use DPCD backlights that need PWM 
enable/disable")
Cc:  # v5.12+
---
 .../drm/i915/display/intel_dp_aux_backlight.c | 27 ++-
 1 file changed, 21 insertions(+), 6 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 569d17b4d00f..f05b71c01b8e 100644
--- a/drivers/gpu/drm/i915/display/intel_dp_aux_backlight.c
+++ b/drivers/gpu/drm/i915/display/intel_dp_aux_backlight.c
@@ -293,6 +293,13 @@ intel_dp_aux_vesa_enable_backlight(const struct 
intel_crtc_state *crtc_state,
struct intel_panel *panel = >panel;
struct intel_dp *intel_dp = enc_to_intel_dp(connector->encoder);
 
+   if (!panel->backlight.edp.vesa.info.aux_enable) {
+   u32 pwm_level = intel_backlight_invert_pwm_level(connector,
+
panel->backlight.pwm_level_max);
+
+   panel->backlight.pwm_funcs->enable(crtc_state, conn_state, 
pwm_level);
+   }
+
drm_edp_backlight_enable(_dp->aux, 
>backlight.edp.vesa.info, level);
 }
 
@@ -304,6 +311,10 @@ static void intel_dp_aux_vesa_disable_backlight(const 
struct drm_connector_state
struct intel_dp *intel_dp = enc_to_intel_dp(connector->encoder);
 
drm_edp_backlight_disable(_dp->aux, 
>backlight.edp.vesa.info);
+
+   if (!panel->backlight.edp.vesa.info.aux_enable)
+   panel->backlight.pwm_funcs->disable(old_conn_state,
+   
intel_backlight_invert_pwm_level(connector, 0));
 }
 
 static int intel_dp_aux_vesa_setup_backlight(struct intel_connector 
*connector, enum pipe pipe)
@@ -321,6 +332,15 @@ static int intel_dp_aux_vesa_setup_backlight(struct 
intel_connector *connector,
if (ret < 0)
return ret;
 
+   if (!panel->backlight.edp.vesa.info.aux_enable) {
+   ret = panel->backlight.pwm_funcs->setup(connector, pipe);
+   if (ret < 0) {
+   drm_err(>drm,
+   "Failed to setup PWM backlight controls for eDP 
backlight: %d\n",
+   ret);
+   return ret;
+   }
+   }
panel->backlight.max = panel->backlight.edp.vesa.info.max;
panel->backlight.min = 0;
if (current_mode == DP_EDP_BACKLIGHT_CONTROL_MODE_DPCD) {
@@ -340,12 +360,7 @@ intel_dp_aux_supports_vesa_backlight(struct 
intel_connector *connector)
struct intel_dp *intel_dp = intel_attached_dp(connector);
struct drm_i915_private *i915 = dp_to_i915(intel_dp);
 
-   /* TODO: We currently only support AUX only backlight configurations, 
not backlights which
-* require a mix of PWM and AUX controls to work. In the mean time, 
these machines typically
-* work just fine using normal PWM controls anyway.
-*/
-   if ((intel_dp->edp_dpcd[1] & DP_EDP_BACKLIGHT_AUX_ENABLE_CAP) &&
-   drm_edp_backlight_supported(intel_dp->edp_dpcd)) {
+   if (drm_edp_backlight_supported(intel_dp->edp_dpcd)) {
drm_dbg_kms(>drm, "AUX Backlight Control Supported!\n");
return true;
}
-- 
2.31.1

[Intel-gfx] [PATCH v4 0/5] drm/dp, drm/i915: Finish basic PWM support for VESA backlight helpers

[Lyude Paul]

When I originally moved all of the VESA backlight code in i915 into DRM
helpers, one of the things I didn't have the hardware or time for
testing was machines that used a combination of PWM and DPCD in order to
control their backlights. This has since then caused some breakages and
resulted in us disabling DPCD backlight support on such machines. This
works fine, unless you have a machine that actually needs this
functionality for backlight controls to work at all. Additionally, we
will need to support PWM for when we start adding support for VESA's
product (as in the product of multiplication) control mode for better
brightness ranges.

So - let's finally finish up implementing basic support for these types
of backlights to solve these problems in our DP helpers, along with
implementing support for this in i915. And since digging into this issue
solved the last questions we really had about probing backlights in i915
for the most part, let's update some of the comments around that as
well!

Changes (v3):
* Add likely fix for weird backlight scaling issues on samus-fi-bdw in intel's
  CI, which pointed out we've been leaving some (currently) unsupported
  backlight features on by mistake which certainly have the potential to cause
  problems.
  UPDATE: this didn't fix the problem, but this changed the symptoms was
  definitely still a bug either way.
Changes (v2):
* Fixup docs
* Add patch to stop us from breaking nouveau

Lyude Paul (5):
  drm/i915: Add support for panels with VESA backlights with PWM
enable/disable
  drm/nouveau/kms/nv50-: Explicitly check DPCD backlights for aux
enable/brightness
  drm/dp: Disable unsupported features in
DP_EDP_BACKLIGHT_MODE_SET_REGISTER
  drm/dp, drm/i915: Add support for VESA backlights using PWM for
brightness control
  drm/i915: Clarify probing order in intel_dp_aux_init_backlight_funcs()

 drivers/gpu/drm/drm_dp_helper.c   | 82 +--
 .../drm/i915/display/intel_dp_aux_backlight.c | 81 ++
 drivers/gpu/drm/nouveau/nouveau_backlight.c   |  5 +-
 include/drm/drm_dp_helper.h   |  7 +-
 4 files changed, 129 insertions(+), 46 deletions(-)

-- 
2.31.1

Re: [Intel-gfx] [PATCH 0/4] drm/i915: (near)atomic gamma LUT updates via vblank workers

[Lyude Paul]

Hey! I'll try to review this tomorrow or the day after if you're still
interested in me doing so :)

On Thu, 2021-10-21 at 01:33 +0300, Ville Syrjala wrote:
> From: Ville Syrjälä 
> 
> Finally got around to refreshing my vblank worker gamma LUT series.
> Since I started this (ahem, some years ago) Lyude took over the
> actual vblank worker implementation, mostly rewrote it I think,
> and landed it for use in nouveau. So now I'm just left with the
> easy task of using it for i915 gamma LUT updates. And so here
> we are.
> 
> CC: Lyude Paul 
> 
> Ville Syrjälä (4):
>   drm/i915: Move function prototypes to the correct header
>   drm/i915: Do vrr push before sampling the freame counter
>   drm/i915: Use vblank workers for gamma updates
>   drm/i915: Use unlocked register accesses for LUT loads
> 
>  drivers/gpu/drm/i915/display/intel_color.c    | 128 +-
>  drivers/gpu/drm/i915/display/intel_crtc.c |  82 ++-
>  drivers/gpu/drm/i915/display/intel_crtc.h |   7 +
>  drivers/gpu/drm/i915/display/intel_display.c  |   9 +-
>  .../drm/i915/display/intel_display_types.h    |   8 ++
>  drivers/gpu/drm/i915/display/intel_dsb.c  |   4 +-
>  drivers/gpu/drm/i915/display/intel_psr.c  |   2 +-
>  drivers/gpu/drm/i915/display/intel_sprite.h   |   4 -
>  drivers/gpu/drm/i915/i915_trace.h |  42 ++
>  9 files changed, 203 insertions(+), 83 deletions(-)
> 

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

[Intel-gfx] [PULL] topic/amdgpu-dp2.0-mst

[Lyude Paul]

topic/amdgpu-dp2.0-mst-2021-10-25:
UAPI Changes:
Nope!

Cross-subsystem Changes:
drm_dp_update_payload_part1() takes a new argument for specifying what the
VCPI slot start is

Core Changes:
Make the DP MST helpers aware of the current starting VCPI slot/VCPI total
slot count...

Driver Changes:
...and then add support for taking advantage of this for 128b/132b links on DP
2.0 for amdgpu
The following changes since commit 6f2f7c83303d2227f47551423e507d77d9ea01c7:

  Merge tag 'drm-intel-gt-next-2021-10-21' of
git://anongit.freedesktop.org/drm/drm-intel into drm-next (2021-10-22 06:30:34
+1000)

are available in the Git repository at:

  git://anongit.freedesktop.org/drm/drm-misc tags/topic/amdgpu-dp2.0-mst-2021-
10-25

for you to fetch changes up to 41724ea273cdda5261db4fabd6bfb1375fbc96b2:

  drm/amd/display: Add DP 2.0 MST DM Support (2021-10-25 21:21:09 -0400)


UAPI Changes:
Nope!

Cross-subsystem Changes:
drm_dp_update_payload_part1() takes a new argument for specifying what the
VCPI slot start is

Core Changes:
Make the DP MST helpers aware of the current starting VCPI slot/VCPI total
slot count...

Driver Changes:
...and then add support for taking advantage of this for 128b/132b links on DP
2.0 for amdgpu


Bhawanpreet Lakha (3):
  drm: Remove slot checks in dp mst topology during commit
  drm: Update MST First Link Slot Information Based on Encoding Format
  drm/amd/display: Add DP 2.0 MST DM Support

Fangzhi Zuo (1):
  drm/amd/display: Add DP 2.0 MST DC Support

 drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c  |  29 ++
 .../drm/amd/display/amdgpu_dm/amdgpu_dm_debugfs.c  |   3 +
 .../drm/amd/display/amdgpu_dm/amdgpu_dm_helpers.c  |   5 +-
 drivers/gpu/drm/amd/display/dc/core/dc.c   |  14 +
 drivers/gpu/drm/amd/display/dc/core/dc_link.c  | 292
+
 drivers/gpu/drm/amd/display/dc/core/dc_link_dp.c   |  19 ++
 drivers/gpu/drm/amd/display/dc/dc_link.h   |   7 +
 drivers/gpu/drm/amd/display/dc/dc_stream.h |  13 +
 drivers/gpu/drm/drm_dp_mst_topology.c  |  42 ++-
 drivers/gpu/drm/i915/display/intel_dp_mst.c    |   4 +-
 drivers/gpu/drm/nouveau/dispnv50/disp.c    |   2 +-
 drivers/gpu/drm/radeon/radeon_dp_mst.c |   4 +-
 include/drm/drm_dp_mst_helper.h    |   5 +-
 13 files changed, 423 insertions(+), 16 deletions(-)

[Intel-gfx] [PATCH RESEND v5 2/4] drm: Update MST First Link Slot Information Based on Encoding Format

[Lyude Paul]

From: Bhawanpreet Lakha 

8b/10b encoding format requires to reserve the first slot for
recording metadata. Real data transmission starts from the second slot,
with a total of available 63 slots available.

In 128b/132b encoding format, metadata is transmitted separately
in LLCP packet before MTP. Real data transmission starts from
the first slot, with a total of 64 slots available.

v2:
* Move total/start slots to mst_state, and copy it to mst_mgr in
atomic_check

v3:
* Only keep the slot info on the mst_state
* add a start_slot parameter to the payload function, to facilitate non
  atomic drivers (this is a temporary workaround and should be removed when
  we are moving out the non atomic driver helpers)

v4:
*fixed typo and formatting

v5: (no functional changes)
* Fixed formatting in drm_dp_mst_update_slots()
* Reference mst_state instead of mst_state->mgr for debugging info

Signed-off-by: Bhawanpreet Lakha 
Signed-off-by: Fangzhi Zuo 
[v5 nitpicks]
Reviewed-by: Lyude Paul 
Signed-off-by: Lyude Paul 
---
 .../amd/display/amdgpu_dm/amdgpu_dm_helpers.c |  2 +-
 drivers/gpu/drm/drm_dp_mst_topology.c | 36 ---
 drivers/gpu/drm/i915/display/intel_dp_mst.c   |  4 +--
 drivers/gpu/drm/nouveau/dispnv50/disp.c   |  2 +-
 drivers/gpu/drm/radeon/radeon_dp_mst.c|  4 +--
 include/drm/drm_dp_mst_helper.h   |  5 ++-
 6 files changed, 42 insertions(+), 11 deletions(-)

diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_helpers.c 
b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_helpers.c
index ff0f91c93ba4..6169488e2011 100644
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_helpers.c
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_helpers.c
@@ -251,7 +251,7 @@ bool dm_helpers_dp_mst_write_payload_allocation_table(
}
 
/* It's OK for this to fail */
-   drm_dp_update_payload_part1(mst_mgr);
+   drm_dp_update_payload_part1(mst_mgr, 1);
 
/* mst_mgr->->payloads are VC payload notify MST branch using DPCD or
 * AUX message. The sequence is slot 1-63 allocated sequence for each
diff --git a/drivers/gpu/drm/drm_dp_mst_topology.c 
b/drivers/gpu/drm/drm_dp_mst_topology.c
index 04ed34a7f71c..571da0c2f39f 100644
--- a/drivers/gpu/drm/drm_dp_mst_topology.c
+++ b/drivers/gpu/drm/drm_dp_mst_topology.c
@@ -3355,6 +3355,10 @@ static int drm_dp_destroy_payload_step2(struct 
drm_dp_mst_topology_mgr *mgr,
 /**
  * drm_dp_update_payload_part1() - Execute payload update part 1
  * @mgr: manager to use.
+ * @start_slot: this is the cur slot
+ *
+ * NOTE: start_slot is a temporary workaround for non-atomic drivers,
+ * this will be removed when non-atomic mst helpers are moved out of the helper
  *
  * This iterates over all proposed virtual channels, and tries to
  * allocate space in the link for them. For 0->slots transitions,
@@ -3365,12 +3369,12 @@ static int drm_dp_destroy_payload_step2(struct 
drm_dp_mst_topology_mgr *mgr,
  * after calling this the driver should generate ACT and payload
  * packets.
  */
-int drm_dp_update_payload_part1(struct drm_dp_mst_topology_mgr *mgr)
+int drm_dp_update_payload_part1(struct drm_dp_mst_topology_mgr *mgr, int 
start_slot)
 {
struct drm_dp_payload req_payload;
struct drm_dp_mst_port *port;
int i, j;
-   int cur_slots = 1;
+   int cur_slots = start_slot;
bool skip;
 
mutex_lock(>payload_lock);
@@ -4505,6 +4509,27 @@ int drm_dp_atomic_release_vcpi_slots(struct 
drm_atomic_state *state,
 }
 EXPORT_SYMBOL(drm_dp_atomic_release_vcpi_slots);
 
+/**
+ * drm_dp_mst_update_slots() - updates the slot info depending on the DP 
ecoding format
+ * @mst_state: mst_state to update
+ * @link_encoding_cap: the ecoding format on the link
+ */
+void drm_dp_mst_update_slots(struct drm_dp_mst_topology_state *mst_state, 
uint8_t link_encoding_cap)
+{
+   if (link_encoding_cap == DP_CAP_ANSI_128B132B) {
+   mst_state->total_avail_slots = 64;
+   mst_state->start_slot = 0;
+   } else {
+   mst_state->total_avail_slots = 63;
+   mst_state->start_slot = 1;
+   }
+
+   DRM_DEBUG_KMS("%s encoding format on mst_state 0x%p\n",
+ (link_encoding_cap == DP_CAP_ANSI_128B132B) ? 
"128b/132b":"8b/10b",
+ mst_state);
+}
+EXPORT_SYMBOL(drm_dp_mst_update_slots);
+
 /**
  * drm_dp_mst_allocate_vcpi() - Allocate a virtual channel
  * @mgr: manager for this port
@@ -5224,7 +5249,7 @@ drm_dp_mst_atomic_check_vcpi_alloc_limit(struct 
drm_dp_mst_topology_mgr *mgr,
 struct drm_dp_mst_topology_state 
*mst_state)
 {
struct drm_dp_vcpi_allocation *vcpi;
-   int avail_slots = 63, payload_count = 0;
+   int avail_slots = mst_state->total_avail_slots, payload_count = 0;
 
list_for_each_entry(vcpi, _state->vcpis, next) {
/* Releasing V

[Intel-gfx] [PATCH v5 2/4] drm: Update MST First Link Slot Information Based on Encoding Format

[Lyude Paul]

From: Bhawanpreet Lakha 

8b/10b encoding format requires to reserve the first slot for
recording metadata. Real data transmission starts from the second slot,
with a total of available 63 slots available.

In 128b/132b encoding format, metadata is transmitted separately
in LLCP packet before MTP. Real data transmission starts from
the first slot, with a total of 64 slots available.

v2:
* Move total/start slots to mst_state, and copy it to mst_mgr in
atomic_check

v3:
* Only keep the slot info on the mst_state
* add a start_slot parameter to the payload function, to facilitate non
  atomic drivers (this is a temporary workaround and should be removed when
  we are moving out the non atomic driver helpers)

v4:
*fixed typo and formatting

v5: (no functional changes)
* Fixed formatting in drm_dp_mst_update_slots()
* Reference mst_state instead of mst_state->mgr for debugging info

Signed-off-by: Bhawanpreet Lakha 
Signed-off-by: Fangzhi Zuo 
[v5 nitpicks]
Reviewed-by: Lyude Paul 
Signed-off-by: Lyude Paul 
---
 .../amd/display/amdgpu_dm/amdgpu_dm_helpers.c |  2 +-
 drivers/gpu/drm/drm_dp_mst_topology.c | 36 ---
 drivers/gpu/drm/i915/display/intel_dp_mst.c   |  4 +--
 drivers/gpu/drm/nouveau/dispnv50/disp.c   |  2 +-
 drivers/gpu/drm/radeon/radeon_dp_mst.c|  4 +--
 include/drm/drm_dp_mst_helper.h   |  5 ++-
 6 files changed, 42 insertions(+), 11 deletions(-)

diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_helpers.c 
b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_helpers.c
index ff0f91c93ba4..6169488e2011 100644
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_helpers.c
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_helpers.c
@@ -251,7 +251,7 @@ bool dm_helpers_dp_mst_write_payload_allocation_table(
}
 
/* It's OK for this to fail */
-   drm_dp_update_payload_part1(mst_mgr);
+   drm_dp_update_payload_part1(mst_mgr, 1);
 
/* mst_mgr->->payloads are VC payload notify MST branch using DPCD or
 * AUX message. The sequence is slot 1-63 allocated sequence for each
diff --git a/drivers/gpu/drm/drm_dp_mst_topology.c 
b/drivers/gpu/drm/drm_dp_mst_topology.c
index 04ed34a7f71c..571da0c2f39f 100644
--- a/drivers/gpu/drm/drm_dp_mst_topology.c
+++ b/drivers/gpu/drm/drm_dp_mst_topology.c
@@ -3355,6 +3355,10 @@ static int drm_dp_destroy_payload_step2(struct 
drm_dp_mst_topology_mgr *mgr,
 /**
  * drm_dp_update_payload_part1() - Execute payload update part 1
  * @mgr: manager to use.
+ * @start_slot: this is the cur slot
+ *
+ * NOTE: start_slot is a temporary workaround for non-atomic drivers,
+ * this will be removed when non-atomic mst helpers are moved out of the helper
  *
  * This iterates over all proposed virtual channels, and tries to
  * allocate space in the link for them. For 0->slots transitions,
@@ -3365,12 +3369,12 @@ static int drm_dp_destroy_payload_step2(struct 
drm_dp_mst_topology_mgr *mgr,
  * after calling this the driver should generate ACT and payload
  * packets.
  */
-int drm_dp_update_payload_part1(struct drm_dp_mst_topology_mgr *mgr)
+int drm_dp_update_payload_part1(struct drm_dp_mst_topology_mgr *mgr, int 
start_slot)
 {
struct drm_dp_payload req_payload;
struct drm_dp_mst_port *port;
int i, j;
-   int cur_slots = 1;
+   int cur_slots = start_slot;
bool skip;
 
mutex_lock(>payload_lock);
@@ -4505,6 +4509,27 @@ int drm_dp_atomic_release_vcpi_slots(struct 
drm_atomic_state *state,
 }
 EXPORT_SYMBOL(drm_dp_atomic_release_vcpi_slots);
 
+/**
+ * drm_dp_mst_update_slots() - updates the slot info depending on the DP 
ecoding format
+ * @mst_state: mst_state to update
+ * @link_encoding_cap: the ecoding format on the link
+ */
+void drm_dp_mst_update_slots(struct drm_dp_mst_topology_state *mst_state, 
uint8_t link_encoding_cap)
+{
+   if (link_encoding_cap == DP_CAP_ANSI_128B132B) {
+   mst_state->total_avail_slots = 64;
+   mst_state->start_slot = 0;
+   } else {
+   mst_state->total_avail_slots = 63;
+   mst_state->start_slot = 1;
+   }
+
+   DRM_DEBUG_KMS("%s encoding format on mst_state 0x%p\n",
+ (link_encoding_cap == DP_CAP_ANSI_128B132B) ? 
"128b/132b":"8b/10b",
+ mst_state);
+}
+EXPORT_SYMBOL(drm_dp_mst_update_slots);
+
 /**
  * drm_dp_mst_allocate_vcpi() - Allocate a virtual channel
  * @mgr: manager for this port
@@ -5224,7 +5249,7 @@ drm_dp_mst_atomic_check_vcpi_alloc_limit(struct 
drm_dp_mst_topology_mgr *mgr,
 struct drm_dp_mst_topology_state 
*mst_state)
 {
struct drm_dp_vcpi_allocation *vcpi;
-   int avail_slots = 63, payload_count = 0;
+   int avail_slots = mst_state->total_avail_slots, payload_count = 0;
 
list_for_each_entry(vcpi, _state->vcpis, next) {
/* Releasing V

Re: [Intel-gfx] [PATCH v3 1/5] drm/i915: Add support for panels with VESA backlights with PWM enable/disable

[Lyude Paul]

On Tue, 2021-10-19 at 21:09 +0300, Ville Syrjälä wrote:
> On Tue, Oct 05, 2021 at 10:40:14PM -0400, Lyude Paul wrote:
> > This simply adds proper support for panel backlights that can be
> > controlled
> > via VESA's backlight control protocol, but which also require that we
> > enable and disable the backlight via PWM instead of via the DPCD
> > interface.
> > We also enable this by default, in order to fix some people's backlights
> > that were broken by not having this enabled.
> > 
> > For reference, backlights that require this and use VESA's backlight
> > interface tend to be laptops with hybrid GPUs, but this very well may
> > change in the future.
> > 
> > Signed-off-by: Lyude Paul 
> > Link: https://gitlab.freedesktop.org/drm/intel/-/issues/3680
> > Fixes: fe7d52bccab6 ("drm/i915/dp: Don't use DPCD backlights that need PWM
> > enable/disable")
> > Cc:  # v5.12+
> > ---
> >  .../drm/i915/display/intel_dp_aux_backlight.c | 24 ++-
> >  1 file changed, 18 insertions(+), 6 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 569d17b4d00f..594fdc7453ca 100644
> > --- a/drivers/gpu/drm/i915/display/intel_dp_aux_backlight.c
> > +++ b/drivers/gpu/drm/i915/display/intel_dp_aux_backlight.c
> > @@ -293,6 +293,10 @@ intel_dp_aux_vesa_enable_backlight(const struct
> > intel_crtc_state *crtc_state,
> > struct intel_panel *panel = >panel;
> > struct intel_dp *intel_dp = enc_to_intel_dp(connector->encoder);
> >  
> > +   if (!panel->backlight.edp.vesa.info.aux_enable)
> > +   panel->backlight.pwm_funcs->enable(crtc_state, conn_state,
> > +  panel-
> > >backlight.pwm_level_max);
> 
> What't the story here with the non-inverted max vs. pontetially inverted
> 0 in the counterpart?

OH! Nice catch,  I wonder if this explains some of the weirdness with samus-
fi-bdw…

Anyway-unfortunately I don't know the precise answer to if we're supposed to
be inverting the panel backlight level or not, so I'd say we should probably
just go with whatever the Intel HDR AUX interface is currently doing - which
is inverting the panel PWM level when needed. Will fix this in a respin
shortly

> 
> > +
> > drm_edp_backlight_enable(_dp->aux, 
> > >backlight.edp.vesa.info, level);
> >  }
> >  
> > @@ -304,6 +308,10 @@ static void intel_dp_aux_vesa_disable_backlight(const
> > struct drm_connector_state
> > struct intel_dp *intel_dp = enc_to_intel_dp(connector->encoder);
> >  
> > drm_edp_backlight_disable(_dp->aux, 
> > >backlight.edp.vesa.info);
> > +
> > +   if (!panel->backlight.edp.vesa.info.aux_enable)
> > +   panel->backlight.pwm_funcs->disable(old_conn_state,
> > +  
> > intel_backlight_invert_pwm_level(connector, 0));
> >  }
> >  
> >  static int intel_dp_aux_vesa_setup_backlight(struct intel_connector
> > *connector, enum pipe pipe)
> > @@ -321,6 +329,15 @@ static int intel_dp_aux_vesa_setup_backlight(struct
> > intel_connector *connector,
> > if (ret < 0)
> > return ret;
> >  
> > +   if (!panel->backlight.edp.vesa.info.aux_enable) {
> > +   ret = panel->backlight.pwm_funcs->setup(connector, pipe);
> > +   if (ret < 0) {
> > +   drm_err(>drm,
> > +   "Failed to setup PWM backlight controls
> > for eDP backlight: %d\n",
> > +   ret);
> > +   return ret;
> > +   }
> > +   }
> > panel->backlight.max = panel->backlight.edp.vesa.info.max;
> > panel->backlight.min = 0;
> > if (current_mode == DP_EDP_BACKLIGHT_CONTROL_MODE_DPCD) {
> > @@ -340,12 +357,7 @@ intel_dp_aux_supports_vesa_backlight(struct
> > intel_connector *connector)
> > struct intel_dp *intel_dp = intel_attached_dp(connector);
> > struct drm_i915_private *i915 = dp_to_i915(intel_dp);
> >  
> > -   /* TODO: We currently only support AUX only backlight
> > configurations, not backlights which
> > -    * require a mix of PWM and AUX controls to work. In the mean
> > time, these machines typically
> > -    * work just fine using normal PWM controls anyway.
> > -    */
> > -   if ((intel_dp->edp_dpcd[1] & DP_EDP_BACKLIGHT_AUX_ENABLE_CAP) &&
> > -   drm_edp_backlight_supported(intel_dp->edp_dpcd)) {
> > +   if (drm_edp_backlight_supported(intel_dp->edp_dpcd)) {
> > drm_dbg_kms(>drm, "AUX Backlight Control
> > Supported!\n");
> > return true;
> > }
> > -- 
> > 2.31.1
> 

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

Re: [Intel-gfx] [PATCH 2/4] drm: Update MST First Link Slot Information Based on Encoding Format

[Lyude Paul]

Awesome! So this all looks fine to me, just some formatting changes:

On Wed, 2021-10-20 at 10:16 -0400, Bhawanpreet Lakha wrote:
> 8b/10b encoding format requires to reserve the first slot for
> recording metadata. Real data transmission starts from the second slot,
> with a total of available 63 slots available.
> 
> In 128b/132b encoding format, metadata is transmitted separately
> in LLCP packet before MTP. Real data transmission starts from
> the first slot, with a total of 64 slots available.
> 
> v2:
> * Move total/start slots to mst_state, and copy it to mst_mgr in
> atomic_check
> 
> v3:
> * Only keep the slot info on the mst_state
> * add a start_slot parameter to the payload function, to facilitate non
>   atomic drivers (this is a temporary workaround and should be removed when
>   we are moving out the non atomic driver helpers)
> 
> Signed-off-by: Bhawanpreet Lakha 
> Signed-off-by: Fangzhi Zuo 
> ---
>  .../amd/display/amdgpu_dm/amdgpu_dm_helpers.c |  2 +-
>  drivers/gpu/drm/drm_dp_mst_topology.c | 34 ---
>  drivers/gpu/drm/i915/display/intel_dp_mst.c   |  4 +--
>  drivers/gpu/drm/nouveau/dispnv50/disp.c   |  2 +-
>  drivers/gpu/drm/radeon/radeon_dp_mst.c    |  4 +--
>  include/drm/drm_dp_mst_helper.h   |  5 ++-
>  6 files changed, 40 insertions(+), 11 deletions(-)
> 
> diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_helpers.c
> b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_helpers.c
> index ff0f91c93ba4..6169488e2011 100644
> --- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_helpers.c
> +++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_helpers.c
> @@ -251,7 +251,7 @@ bool dm_helpers_dp_mst_write_payload_allocation_table(
> }
>  
> /* It's OK for this to fail */
> -   drm_dp_update_payload_part1(mst_mgr);
> +   drm_dp_update_payload_part1(mst_mgr, 1);
>  
> /* mst_mgr->->payloads are VC payload notify MST branch using DPCD
> or
>  * AUX message. The sequence is slot 1-63 allocated sequence for
> each
> diff --git a/drivers/gpu/drm/drm_dp_mst_topology.c
> b/drivers/gpu/drm/drm_dp_mst_topology.c
> index 5ab3b3a46e89..d188a5269070 100644
> --- a/drivers/gpu/drm/drm_dp_mst_topology.c
> +++ b/drivers/gpu/drm/drm_dp_mst_topology.c
> @@ -3353,6 +3353,9 @@ static int drm_dp_destroy_payload_step2(struct
> drm_dp_mst_topology_mgr *mgr,
>  /**
>   * drm_dp_update_payload_part1() - Execute payload update part 1
>   * @mgr: manager to use.
> + * @start_slot: this is the cur slot
> + *  NOTE: start_slot is a temporary workaround for non-atomic drivers,
> + *  this will be removed when non-atomic mst helpers are moved out of the
> helper

We should probably add a space right before NOTE, and reformat these comments
since there's a bit of an indent at the start (unfortunately, I don't think
kdoc is smart enough to retain the indent in the documentation it generates).

>   *
>   * This iterates over all proposed virtual channels, and tries to
>   * allocate space in the link for them. For 0->slots transitions,
> @@ -3363,12 +3366,12 @@ static int drm_dp_destroy_payload_step2(struct
> drm_dp_mst_topology_mgr *mgr,
>   * after calling this the driver should generate ACT and payload
>   * packets.
>   */
> -int drm_dp_update_payload_part1(struct drm_dp_mst_topology_mgr *mgr)
> +int drm_dp_update_payload_part1(struct drm_dp_mst_topology_mgr *mgr, int
> start_slot)
>  {
> struct drm_dp_payload req_payload;
> struct drm_dp_mst_port *port;
> int i, j;
> -   int cur_slots = 1;
> +   int cur_slots = start_slot;
> bool skip;
>  
> mutex_lock(>payload_lock);
> @@ -4503,6 +4506,26 @@ int drm_dp_atomic_release_vcpi_slots(struct
> drm_atomic_state *state,
>  }
>  EXPORT_SYMBOL(drm_dp_atomic_release_vcpi_slots);
>  
> +/**
> + * drm_dp_mst_update_slots() - updates the slot info depending on the DP
> ecoding format
> + * @mst_state: mst_state to update
> + * @link_ecoding_cap: the ecoding format on the link
> + */
> +void drm_dp_mst_update_slots(struct drm_dp_mst_topology_state *mst_state,
> uint8_t link_ecoding_cap)
> +{
> +   if (link_ecoding_cap == DP_CAP_ANSI_128B132B) {
> +   mst_state->total_avail_slots = 64;
> +   mst_state->start_slot = 0;
> +   } else {
> +   mst_state->total_avail_slots = 63;
> +   mst_state->start_slot = 1;
> +   }
> +
> +   DRM_DEBUG_KMS("%s ecoding format on mst_state 0x%p\n",
> +   (link_ecoding_cap == DP_CAP_ANSI_128B132B) ?
> "128b/132b":"8b/10b", mst_state->mgr);
> +}
> +EXPORT_SYMBOL

Re: [Intel-gfx] [PATCH 1/4] drm: Remove slot checks in dp mst topology during commit

[Lyude Paul]

Reviewed-by: Lyude Paul 

On Wed, 2021-10-20 at 10:16 -0400, Bhawanpreet Lakha wrote:
> This code path is used during commit, and we dont expect things to fail
> during the commit stage, so remove this.
> 
> Signed-off-by: Bhawanpreet Lakha 
> ---
>  drivers/gpu/drm/drm_dp_mst_topology.c | 6 +-
>  1 file changed, 1 insertion(+), 5 deletions(-)
> 
> diff --git a/drivers/gpu/drm/drm_dp_mst_topology.c
> b/drivers/gpu/drm/drm_dp_mst_topology.c
> index ad0795afc21c..5ab3b3a46e89 100644
> --- a/drivers/gpu/drm/drm_dp_mst_topology.c
> +++ b/drivers/gpu/drm/drm_dp_mst_topology.c
> @@ -4332,10 +4332,6 @@ static int drm_dp_init_vcpi(struct
> drm_dp_mst_topology_mgr *mgr,
>  {
> int ret;
>  
> -   /* max. time slots - one slot for MTP header */
> -   if (slots > 63)
> -   return -ENOSPC;
> -
> vcpi->pbn = pbn;
> vcpi->aligned_pbn = slots * mgr->pbn_div;
> vcpi->num_slots = slots;
> @@ -4538,7 +4534,7 @@ bool drm_dp_mst_allocate_vcpi(struct
> drm_dp_mst_topology_mgr *mgr,
>  
> ret = drm_dp_init_vcpi(mgr, >vcpi, pbn, slots);
> if (ret) {
> -   drm_dbg_kms(mgr->dev, "failed to init vcpi slots=%d max=63
> ret=%d\n",
> +   drm_dbg_kms(mgr->dev, "failed to init vcpi slots=%d
> ret=%d\n",
>         DIV_ROUND_UP(pbn, mgr->pbn_div), ret);
> drm_dp_mst_topology_put_port(port);
> goto out;

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

Re: [Intel-gfx] ✗ Fi.CI.IGT: failure for drm/dp, drm/i915: Finish basic PWM support for VESA backlight helpers (rev8)

[Lyude Paul]

d-iclb: FAIL ([i915#454]) -> PASS
>  * igt@i915_pm_rpm@system-suspend:shard-skl: INCOMPLETE ([i915#151]) -> PASS
>  * igt@kms_async_flips@alternate-sync-async-flip:shard-skl: FAIL ([i915#2521])
>-> PASS
>  * igt@kms_big_fb@yf-tiled-16bpp-rotate-0:shard-glk: DMESG-WARN ([i915#118]) -
>> PASS
>  * igt@kms_flip@flip-vs-expired-vblank@b-edp1:shard-skl: FAIL ([i915#79]) ->
>PASS
>  * igt@kms_flip@plain-flip-fb-recreate@a-edp1:shard-skl: FAIL ([i915#2122]) ->
>PASS
>  * igt@kms_plane@plane-panning-bottom-right-suspend@pipe-b-planes:shard-kbl:
>DMESG-WARN ([i915#180]) -> PASS +5 similar issues
>  * igt@perf@polling-parameterized:shard-glk: FAIL ([i915#1542]) -> PASSshard-
>skl: FAIL ([i915#1542]) -> PASS
> Warnings * igt@i915_pm_rc6_residency@rc6-idle:shard-iclb: WARN ([i915#2684]) 
> -> WARN
>([i915#1804] / [i915#2684])
>  * igt@kms_psr2_sf@overlay-plane-update-sf-dmg-area-1:shard-iclb: SKIP
>([i915#2920]) -> SKIP ([i915#658]) +3 similar issues
>  * igt@kms_psr2_sf@overlay-primary-update-sf-dmg-area-2:shard-iclb: SKIP
>([i915#658]) -> SKIP ([i915#2920]) +1 similar issue
>  * igt@runner@aborted:shard-kbl: (FAIL, FAIL, FAIL, FAIL, FAIL, FAIL, FAIL)
>([i915#1436] / [i915#180] / [i915#1814] / [i915#3002] / [i915#3363]) ->
>(FAIL, FAIL, FAIL, FAIL, FAIL, FAIL, FAIL, FAIL, FAIL) ([i915#180] /
>[i915#1814] / [i915#3002] / [i915#3363] / [i915#92])shard-apl: (FAIL, FAIL,
>FAIL) ([fdo#109271] / [i915#1814] / [i915#3002] / [i915#3363]) -> (FAIL,
>FAIL, FAIL) ([i915#180] / [i915#1814] / [i915#3002] / [i915#3363])shard-
>skl: ([FAIL][147], [FAIL][148], [FAIL][149], [FAIL][150]) ([i915#1436] /
>[i915#2029] / [i915#3002] / [i915#3363]) -> ([FAIL][151], [FAIL][152]) ([i

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

Re: [Intel-gfx] [Nouveau] [PATCH v3 2/5] drm/nouveau/kms/nv50-: Explicitly check DPCD backlights for aux enable/brightness

[Lyude Paul]

On Wed, 2021-10-06 at 18:30 +0200, Karol Herbst wrote:
> On Wed, Oct 6, 2021 at 4:41 AM Lyude Paul  wrote:
> > 
> > Since we don't support hybrid AUX/PWM backlights in nouveau right now,
> > let's add some explicit checks so that we don't break nouveau once we
> > enable support for these backlights in other drivers.
> > 
> > Signed-off-by: Lyude Paul 
> > ---
> >  drivers/gpu/drm/nouveau/nouveau_backlight.c | 5 -
> >  1 file changed, 4 insertions(+), 1 deletion(-)
> > 
> > diff --git a/drivers/gpu/drm/nouveau/nouveau_backlight.c
> > b/drivers/gpu/drm/nouveau/nouveau_backlight.c
> > index 1cbd71abc80a..ae2f2abc8f5a 100644
> > --- a/drivers/gpu/drm/nouveau/nouveau_backlight.c
> > +++ b/drivers/gpu/drm/nouveau/nouveau_backlight.c
> > @@ -308,7 +308,10 @@ nv50_backlight_init(struct nouveau_backlight *bl,
> >     if (ret < 0)
> >     return ret;
> > 
> > -   if (drm_edp_backlight_supported(edp_dpcd)) {
> > +   /* TODO: Add support for hybrid PWM/DPCD panels */
> > +   if (drm_edp_backlight_supported(edp_dpcd) &&
> > +   (edp_dpcd[1] & DP_EDP_BACKLIGHT_AUX_ENABLE_CAP) &&
> 
> where does the DP_EDP_BACKLIGHT_AUX_ENABLE_CAP come from? afaik
> drm_edp_backlight_supported checks for
> DP_EDP_BACKLIGHT_BRIGHTNESS_AUX_SET_CAP and
> DP_EDP_TCON_BACKLIGHT_ADJUSTMENT_CAP so wondering if this was
> intentional or a typo

This is intentional - drm_edp_backlight_supported() does check for these, but
in the patch after this we remove the BRIGHTNESS_AUX_SET_CAP from
drm_edp_backlight_supported() in order to implement support for panels lacking
BRIGHTNESS_AUX_SET_CAP in i915. Since we don't have support for this in
nouveau yet but such backlights are likely to mostly work without the use of
DPCD if we avoid trying to set it up, this patch is just here to make sure
that the changes to drm_edp_backlight_supported() don't result in nouveau
suddenly trying (and failing) to enable DPCD backlight controls on those
backlights.

> 
> > +   (edp_dpcd[2] &
> > DP_EDP_BACKLIGHT_BRIGHTNESS_AUX_SET_CAP)) {
> >     NV_DEBUG(drm, "DPCD backlight controls supported
> > on %s\n",
> >  nv_conn->base.name);
> > 
> > --
> > 2.31.1
> > 
> 

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

[Intel-gfx] [PATCH v3 5/5] drm/i915: Clarify probing order in intel_dp_aux_init_backlight_funcs()

[Lyude Paul]

Hooray! We've managed to hit enough bugs upstream that I've been able to
come up with a pretty solid explanation for how backlight controls are
actually supposed to be detected and used these days. As well, having the
rest of the PWM bits in VESA's backlight interface implemented seems to
have fixed all of the problematic brightness controls laptop panels that
we've hit so far.

So, let's actually document this instead of just calling the laptop panels
liars. As well, I would like to formally apologize to all of the laptop
panels I called liars. I'm sorry laptop panels, hopefully you can all
forgive me and we can move past this~

Signed-off-by: Lyude Paul 
---
 .../drm/i915/display/intel_dp_aux_backlight.c| 16 +++-
 1 file changed, 11 insertions(+), 5 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 91daf9ab50e8..04a52d6a74ed 100644
--- a/drivers/gpu/drm/i915/display/intel_dp_aux_backlight.c
+++ b/drivers/gpu/drm/i915/display/intel_dp_aux_backlight.c
@@ -455,11 +455,17 @@ int intel_dp_aux_init_backlight_funcs(struct 
intel_connector *connector)
}
 
/*
-* A lot of eDP panels in the wild will report supporting both the
-* Intel proprietary backlight control interface, and the VESA
-* backlight control interface. Many of these panels are liars though,
-* and will only work with the Intel interface. So, always probe for
-* that first.
+* Since Intel has their own backlight control interface, the majority 
of machines out there
+* using DPCD backlight controls with Intel GPUs will be using this 
interface as opposed to
+* the VESA interface. However, other GPUs (such as Nvidia's) will 
always use the VESA
+* interface. This means that there's quite a number of panels out 
there that will advertise
+* support for both interfaces, primarily systems with Intel/Nvidia 
hybrid GPU setups.
+*
+* There's a catch to this though: on many panels that advertise 
support for both
+* interfaces, the VESA backlight interface will stop working once 
we've programmed the
+* panel with Intel's OUI - which is also required for us to be able to 
detect Intel's
+* backlight interface at all. This means that the only sensible way 
for us to detect both
+* interfaces is to probe for Intel's first, and VESA's second.
 */
if (try_intel_interface && 
intel_dp_aux_supports_hdr_backlight(connector)) {
drm_dbg_kms(dev, "Using Intel proprietary eDP backlight 
controls\n");
-- 
2.31.1

[Intel-gfx] [PATCH v3 4/5] drm/dp, drm/i915: Add support for VESA backlights using PWM for brightness control

[Lyude Paul]

Now that we've added support to i915 for controlling panel backlights that
need PWM to be enabled/disabled, let's finalize this and add support for
controlling brightness levels via PWM as well. This should hopefully put us
towards the path of supporting _ALL_ backlights via VESA's DPCD interface
which would allow us to finally start trusting the DPCD again.

Note however that we still don't enable using this by default on i915 when
it's not needed, primarily because I haven't yet had a chance to confirm if
it's safe to do this on the one machine in Intel's CI that had an issue
with this: samus-fi-bdw. I have done basic testing of this on other
machines though, by manually patching i915 to force it into PWM-only mode
on some of my laptops.

v2:
* Correct documentation (thanks Doug!)
* Get rid of backlight caps

Signed-off-by: Lyude Paul 
Cc: Rajeev Nandan 
Cc: Doug Anderson 
Cc: Satadru Pramanik 
---
 drivers/gpu/drm/drm_dp_helper.c   | 76 +--
 .../drm/i915/display/intel_dp_aux_backlight.c | 48 +---
 include/drm/drm_dp_helper.h   |  7 +-
 3 files changed, 94 insertions(+), 37 deletions(-)

diff --git a/drivers/gpu/drm/drm_dp_helper.c b/drivers/gpu/drm/drm_dp_helper.c
index d9a7f07f42fd..9bef21613370 100644
--- a/drivers/gpu/drm/drm_dp_helper.c
+++ b/drivers/gpu/drm/drm_dp_helper.c
@@ -3173,6 +3173,10 @@ int drm_edp_backlight_set_level(struct drm_dp_aux *aux, 
const struct drm_edp_bac
int ret;
u8 buf[2] = { 0 };
 
+   /* The panel uses the PWM for controlling brightness levels */
+   if (!bl->aux_set)
+   return 0;
+
if (bl->lsb_reg_used) {
buf[0] = (level & 0xff00) >> 8;
buf[1] = (level & 0x00ff);
@@ -3199,7 +3203,7 @@ drm_edp_backlight_set_enable(struct drm_dp_aux *aux, 
const struct drm_edp_backli
int ret;
u8 buf;
 
-   /* The panel uses something other then DPCD for enabling its backlight 
*/
+   /* This panel uses the EDP_BL_PWR GPIO for enablement */
if (!bl->aux_enable)
return 0;
 
@@ -3234,11 +3238,11 @@ drm_edp_backlight_set_enable(struct drm_dp_aux *aux, 
const struct drm_edp_backli
  * 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. On such panels
- * _edp_backlight_info.aux_enable will be set to %false, this function 
will skip the step of
- * programming the %DP_EDP_DISPLAY_CONTROL_REGISTER, and the driver must 
perform the required
- * implementation specific step for enabling the backlight after calling this 
function.
+ * Note that certain panels do not support being enabled or disabled via DPCD, 
but instead require
+ * that the driver handle enabling/disabling the panel through 
implementation-specific means using
+ * the EDP_BL_PWR GPIO. For such panels, _edp_backlight_info.aux_enable 
will be set to %false,
+ * this function becomes a no-op, and the driver is expected to handle 
powering the panel on using
+ * the EDP_BL_PWR GPIO.
  *
  * Returns: %0 on success, negative error code on failure.
  */
@@ -3246,7 +3250,7 @@ int drm_edp_backlight_enable(struct drm_dp_aux *aux, 
const struct drm_edp_backli
 const u16 level)
 {
int ret;
-   u8 dpcd_buf, new_dpcd_buf;
+   u8 dpcd_buf, new_dpcd_buf, new_mode;
 
ret = drm_dp_dpcd_readb(aux, DP_EDP_BACKLIGHT_MODE_SET_REGISTER, 
_buf);
if (ret != 1) {
@@ -3259,9 +3263,14 @@ int drm_edp_backlight_enable(struct drm_dp_aux *aux, 
const struct drm_edp_backli
new_dpcd_buf = dpcd_buf & (DP_EDP_BACKLIGHT_CONTROL_MODE_MASK |
   DP_EDP_BACKLIGHT_FREQ_AUX_SET_ENABLE);
 
-   if ((dpcd_buf & DP_EDP_BACKLIGHT_CONTROL_MODE_MASK) != 
DP_EDP_BACKLIGHT_CONTROL_MODE_DPCD) {
+   if (bl->aux_set)
+   new_mode = DP_EDP_BACKLIGHT_CONTROL_MODE_DPCD;
+   else
+   new_mode = DP_EDP_BACKLIGHT_CONTROL_MODE_PWM;
+
+   if ((dpcd_buf & DP_EDP_BACKLIGHT_CONTROL_MODE_MASK) != new_mode) {
new_dpcd_buf &= ~DP_EDP_BACKLIGHT_CONTROL_MODE_MASK;
-   new_dpcd_buf |= DP_EDP_BACKLIGHT_CONTROL_MODE_DPCD;
+   new_dpcd_buf |= new_mode;
 
if (bl->pwmgen_bit_count) {
ret = drm_dp_dpcd_writeb(aux, DP_EDP_PWMGEN_BIT_COUNT, 
bl->pwmgen_bit_count);
@@ -3308,12 +3317,13 @@ EXPORT_SYMBOL(drm_edp_backlight_enable);
  * @aux: The DP AUX channel to use
  * @bl: Backlight capability info from drm_edp_backlight_init()
  *
- * This function handles disabling DPCD backlight controls on a panel over 
AUX. Note that some
- * panels have backlights that are enabled/disabled by other means, despit

[Intel-gfx] [PATCH v3 3/5] drm/dp: Disable unsupported features in DP_EDP_BACKLIGHT_MODE_SET_REGISTER

[Lyude Paul]

As it turns out, apparently some machines will actually leave additional
backlight functionality like dynamic backlight control on before the OS
loads. Currently we don't take care to disable unsupported features when
writing back the backlight mode, which can lead to some rather strange
looking behavior when adjusting the backlight.

So, let's fix this by ensuring we only keep supported features enabled for
panel backlights - which should fix some of the issues we were seeing from
this on fi-bdw-samus.

Signed-off-by: Lyude Paul 
Fixes: 867cf9cd73c3 ("drm/dp: Extract i915's eDP backlight code into DRM 
helpers")
---
 drivers/gpu/drm/drm_dp_helper.c | 6 +-
 1 file changed, 5 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/drm_dp_helper.c b/drivers/gpu/drm/drm_dp_helper.c
index 4d0d1e8e51fa..d9a7f07f42fd 100644
--- a/drivers/gpu/drm/drm_dp_helper.c
+++ b/drivers/gpu/drm/drm_dp_helper.c
@@ -3255,7 +3255,9 @@ int drm_edp_backlight_enable(struct drm_dp_aux *aux, 
const struct drm_edp_backli
return ret < 0 ? ret : -EIO;
}
 
-   new_dpcd_buf = dpcd_buf;
+   /* Disable any backlight functionality we don't support that might be 
on */
+   new_dpcd_buf = dpcd_buf & (DP_EDP_BACKLIGHT_CONTROL_MODE_MASK |
+  DP_EDP_BACKLIGHT_FREQ_AUX_SET_ENABLE);
 
if ((dpcd_buf & DP_EDP_BACKLIGHT_CONTROL_MODE_MASK) != 
DP_EDP_BACKLIGHT_CONTROL_MODE_DPCD) {
new_dpcd_buf &= ~DP_EDP_BACKLIGHT_CONTROL_MODE_MASK;
@@ -3277,6 +3279,8 @@ int drm_edp_backlight_enable(struct drm_dp_aux *aux, 
const struct drm_edp_backli
aux->name, ret);
else
new_dpcd_buf |= DP_EDP_BACKLIGHT_FREQ_AUX_SET_ENABLE;
+   } else {
+   new_dpcd_buf &= ~DP_EDP_BACKLIGHT_FREQ_AUX_SET_ENABLE;
}
 
if (new_dpcd_buf != dpcd_buf) {
-- 
2.31.1

[Intel-gfx] [PATCH v3 2/5] drm/nouveau/kms/nv50-: Explicitly check DPCD backlights for aux enable/brightness

[Lyude Paul]

Since we don't support hybrid AUX/PWM backlights in nouveau right now,
let's add some explicit checks so that we don't break nouveau once we
enable support for these backlights in other drivers.

Signed-off-by: Lyude Paul 
---
 drivers/gpu/drm/nouveau/nouveau_backlight.c | 5 -
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/nouveau/nouveau_backlight.c 
b/drivers/gpu/drm/nouveau/nouveau_backlight.c
index 1cbd71abc80a..ae2f2abc8f5a 100644
--- a/drivers/gpu/drm/nouveau/nouveau_backlight.c
+++ b/drivers/gpu/drm/nouveau/nouveau_backlight.c
@@ -308,7 +308,10 @@ nv50_backlight_init(struct nouveau_backlight *bl,
if (ret < 0)
return ret;
 
-   if (drm_edp_backlight_supported(edp_dpcd)) {
+   /* TODO: Add support for hybrid PWM/DPCD panels */
+   if (drm_edp_backlight_supported(edp_dpcd) &&
+   (edp_dpcd[1] & DP_EDP_BACKLIGHT_AUX_ENABLE_CAP) &&
+   (edp_dpcd[2] & DP_EDP_BACKLIGHT_BRIGHTNESS_AUX_SET_CAP)) {
NV_DEBUG(drm, "DPCD backlight controls supported on 
%s\n",
 nv_conn->base.name);
 
-- 
2.31.1

[Intel-gfx] [PATCH v3 1/5] drm/i915: Add support for panels with VESA backlights with PWM enable/disable

[Lyude Paul]

This simply adds proper support for panel backlights that can be controlled
via VESA's backlight control protocol, but which also require that we
enable and disable the backlight via PWM instead of via the DPCD interface.
We also enable this by default, in order to fix some people's backlights
that were broken by not having this enabled.

For reference, backlights that require this and use VESA's backlight
interface tend to be laptops with hybrid GPUs, but this very well may
change in the future.

Signed-off-by: Lyude Paul 
Link: https://gitlab.freedesktop.org/drm/intel/-/issues/3680
Fixes: fe7d52bccab6 ("drm/i915/dp: Don't use DPCD backlights that need PWM 
enable/disable")
Cc:  # v5.12+
---
 .../drm/i915/display/intel_dp_aux_backlight.c | 24 ++-
 1 file changed, 18 insertions(+), 6 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 569d17b4d00f..594fdc7453ca 100644
--- a/drivers/gpu/drm/i915/display/intel_dp_aux_backlight.c
+++ b/drivers/gpu/drm/i915/display/intel_dp_aux_backlight.c
@@ -293,6 +293,10 @@ intel_dp_aux_vesa_enable_backlight(const struct 
intel_crtc_state *crtc_state,
struct intel_panel *panel = >panel;
struct intel_dp *intel_dp = enc_to_intel_dp(connector->encoder);
 
+   if (!panel->backlight.edp.vesa.info.aux_enable)
+   panel->backlight.pwm_funcs->enable(crtc_state, conn_state,
+  
panel->backlight.pwm_level_max);
+
drm_edp_backlight_enable(_dp->aux, 
>backlight.edp.vesa.info, level);
 }
 
@@ -304,6 +308,10 @@ static void intel_dp_aux_vesa_disable_backlight(const 
struct drm_connector_state
struct intel_dp *intel_dp = enc_to_intel_dp(connector->encoder);
 
drm_edp_backlight_disable(_dp->aux, 
>backlight.edp.vesa.info);
+
+   if (!panel->backlight.edp.vesa.info.aux_enable)
+   panel->backlight.pwm_funcs->disable(old_conn_state,
+   
intel_backlight_invert_pwm_level(connector, 0));
 }
 
 static int intel_dp_aux_vesa_setup_backlight(struct intel_connector 
*connector, enum pipe pipe)
@@ -321,6 +329,15 @@ static int intel_dp_aux_vesa_setup_backlight(struct 
intel_connector *connector,
if (ret < 0)
return ret;
 
+   if (!panel->backlight.edp.vesa.info.aux_enable) {
+   ret = panel->backlight.pwm_funcs->setup(connector, pipe);
+   if (ret < 0) {
+   drm_err(>drm,
+   "Failed to setup PWM backlight controls for eDP 
backlight: %d\n",
+   ret);
+   return ret;
+   }
+   }
panel->backlight.max = panel->backlight.edp.vesa.info.max;
panel->backlight.min = 0;
if (current_mode == DP_EDP_BACKLIGHT_CONTROL_MODE_DPCD) {
@@ -340,12 +357,7 @@ intel_dp_aux_supports_vesa_backlight(struct 
intel_connector *connector)
struct intel_dp *intel_dp = intel_attached_dp(connector);
struct drm_i915_private *i915 = dp_to_i915(intel_dp);
 
-   /* TODO: We currently only support AUX only backlight configurations, 
not backlights which
-* require a mix of PWM and AUX controls to work. In the mean time, 
these machines typically
-* work just fine using normal PWM controls anyway.
-*/
-   if ((intel_dp->edp_dpcd[1] & DP_EDP_BACKLIGHT_AUX_ENABLE_CAP) &&
-   drm_edp_backlight_supported(intel_dp->edp_dpcd)) {
+   if (drm_edp_backlight_supported(intel_dp->edp_dpcd)) {
drm_dbg_kms(>drm, "AUX Backlight Control Supported!\n");
return true;
}
-- 
2.31.1

[Intel-gfx] [PATCH v3 0/5] drm/dp, drm/i915: Finish basic PWM support for VESA backlight helpers

[Lyude Paul]

When I originally moved all of the VESA backlight code in i915 into DRM
helpers, one of the things I didn't have the hardware or time for
testing was machines that used a combination of PWM and DPCD in order to
control their backlights. This has since then caused some breakages and
resulted in us disabling DPCD backlight support on such machines. This
works fine, unless you have a machine that actually needs this
functionality for backlight controls to work at all. Additionally, we
will need to support PWM for when we start adding support for VESA's
product (as in the product of multiplication) control mode for better
brightness ranges.

So - let's finally finish up implementing basic support for these types
of backlights to solve these problems in our DP helpers, along with
implementing support for this in i915. And since digging into this issue
solved the last questions we really had about probing backlights in i915
for the most part, let's update some of the comments around that as
well!

Changes (v3):
* Add likely fix for weird backlight scaling issues on samus-fi-bdw in intel's
  CI, which pointed out we've been leaving some (currently) unsupported
  backlight features on by mistake which certainly have the potential to cause
  problems.
Changes (v2):
* Fixup docs
* Add patch to stop us from breaking nouveau

Lyude Paul (5):
  drm/i915: Add support for panels with VESA backlights with PWM
enable/disable
  drm/nouveau/kms/nv50-: Explicitly check DPCD backlights for aux
enable/brightness
  drm/dp: Disable unsupported features in
DP_EDP_BACKLIGHT_MODE_SET_REGISTER
  drm/dp, drm/i915: Add support for VESA backlights using PWM for
brightness control
  drm/i915: Clarify probing order in intel_dp_aux_init_backlight_funcs()

 drivers/gpu/drm/drm_dp_helper.c   | 82 +--
 .../drm/i915/display/intel_dp_aux_backlight.c | 80 ++
 drivers/gpu/drm/nouveau/nouveau_backlight.c   |  5 +-
 include/drm/drm_dp_helper.h   |  7 +-
 4 files changed, 128 insertions(+), 46 deletions(-)

-- 
2.31.1

Re: [Intel-gfx] [PATCH v2 0/4] drm/dp, drm/i915: Finish basic PWM support for VESA backlight helpers

[Lyude Paul]

On Sat, 2021-10-02 at 11:14 +0200, Hans de Goede wrote:
> Hi Lyude,
> 
> On 10/2/21 12:53 AM, Lyude Paul wrote:
> > When I originally moved all of the VESA backlight code in i915 into DRM
> > helpers, one of the things I didn't have the hardware or time for
> > testing was machines that used a combination of PWM and DPCD in order to
> > control their backlights. This has since then caused some breakages and
> > resulted in us disabling DPCD backlight support on such machines. This
> > works fine, unless you have a machine that actually needs this
> > functionality for backlight controls to work at all. Additionally, we
> > will need to support PWM for when we start adding support for VESA's
> > product (as in the product of multiplication) control mode for better
> > brightness ranges.
> > 
> > So - let's finally finish up implementing basic support for these types
> > of backlights to solve these problems in our DP helpers, along with
> > implementing support for this in i915. And since digging into this issue
> > solved the last questions we really had about probing backlights in i915
> > for the most part, let's update some of the comments around that as
> > well!
> 
> Backlight control is a topic which I'm reasonably familiar with,
> do you want me to review this series for you ?

Possibly, although I definitely want to make sure that someone from Intel gets
a chance to review this as well. I'm more curious if you might happen to have
any systems that would be able to test this.

> 
> Regards,
> 
> Hans
> 
> 
> 
> > 
> > Changes:
> > * Fixup docs
> > * Add patch to stop us from breaking nouveau
> > 
> > Lyude Paul (4):
> >   drm/i915: Add support for panels with VESA backlights with PWM
> >     enable/disable
> >   drm/nouveau/kms/nv50-: Explicitly check DPCD backlights for aux
> >     enable/brightness
> >   drm/dp, drm/i915: Add support for VESA backlights using PWM for
> >     brightness control
> >   drm/i915: Clarify probing order in intel_dp_aux_init_backlight_funcs()
> > 
> >  drivers/gpu/drm/drm_dp_helper.c   | 75 +++--
> >  .../drm/i915/display/intel_dp_aux_backlight.c | 80 ++-
> >  drivers/gpu/drm/nouveau/nouveau_backlight.c   |  5 +-
> >  include/drm/drm_dp_helper.h   |  7 +-
> >  4 files changed, 122 insertions(+), 45 deletions(-)
> > 
> 

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

[Intel-gfx] [PATCH v2 3/4] drm/dp, drm/i915: Add support for VESA backlights using PWM for brightness control

[Lyude Paul]

Now that we've added support to i915 for controlling panel backlights that
need PWM to be enabled/disabled, let's finalize this and add support for
controlling brightness levels via PWM as well. This should hopefully put us
towards the path of supporting _ALL_ backlights via VESA's DPCD interface
which would allow us to finally start trusting the DPCD again.

Note however that we still don't enable using this by default on i915 when
it's not needed, primarily because I haven't yet had a chance to confirm if
it's safe to do this on the one machine in Intel's CI that had an issue
with this: samus-fi-bdw. I have done basic testing of this on other
machines though, by manually patching i915 to force it into PWM-only mode
on some of my laptops.

v2:
* Correct documentation (thanks Doug!)
* Get rid of backlight caps

Signed-off-by: Lyude Paul 
Cc: Rajeev Nandan 
Cc: Doug Anderson 
Cc: Satadru Pramanik 
---
 drivers/gpu/drm/drm_dp_helper.c   | 75 +--
 .../drm/i915/display/intel_dp_aux_backlight.c | 48 +---
 include/drm/drm_dp_helper.h   |  7 +-
 3 files changed, 93 insertions(+), 37 deletions(-)

diff --git a/drivers/gpu/drm/drm_dp_helper.c b/drivers/gpu/drm/drm_dp_helper.c
index 4d0d1e8e51fa..f350e17a80e7 100644
--- a/drivers/gpu/drm/drm_dp_helper.c
+++ b/drivers/gpu/drm/drm_dp_helper.c
@@ -3173,6 +3173,10 @@ int drm_edp_backlight_set_level(struct drm_dp_aux *aux, 
const struct drm_edp_bac
int ret;
u8 buf[2] = { 0 };
 
+   /* The panel uses the PWM for controlling brightness levels */
+   if (!bl->aux_set)
+   return 0;
+
if (bl->lsb_reg_used) {
buf[0] = (level & 0xff00) >> 8;
buf[1] = (level & 0x00ff);
@@ -3199,7 +3203,7 @@ drm_edp_backlight_set_enable(struct drm_dp_aux *aux, 
const struct drm_edp_backli
int ret;
u8 buf;
 
-   /* The panel uses something other then DPCD for enabling its backlight 
*/
+   /* This panel uses the EDP_BL_PWR GPIO for enablement */
if (!bl->aux_enable)
return 0;
 
@@ -3234,11 +3238,11 @@ drm_edp_backlight_set_enable(struct drm_dp_aux *aux, 
const struct drm_edp_backli
  * 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. On such panels
- * _edp_backlight_info.aux_enable will be set to %false, this function 
will skip the step of
- * programming the %DP_EDP_DISPLAY_CONTROL_REGISTER, and the driver must 
perform the required
- * implementation specific step for enabling the backlight after calling this 
function.
+ * Note that certain panels do not support being enabled or disabled via DPCD, 
but instead require
+ * that the driver handle enabling/disabling the panel through 
implementation-specific means using
+ * the EDP_BL_PWR GPIO. For such panels, _edp_backlight_info.aux_enable 
will be set to %false,
+ * this function becomes a no-op, and the driver is expected to handle 
powering the panel on using
+ * the EDP_BL_PWR GPIO.
  *
  * Returns: %0 on success, negative error code on failure.
  */
@@ -3246,7 +3250,7 @@ int drm_edp_backlight_enable(struct drm_dp_aux *aux, 
const struct drm_edp_backli
 const u16 level)
 {
int ret;
-   u8 dpcd_buf, new_dpcd_buf;
+   u8 dpcd_buf, new_dpcd_buf, new_mode;
 
ret = drm_dp_dpcd_readb(aux, DP_EDP_BACKLIGHT_MODE_SET_REGISTER, 
_buf);
if (ret != 1) {
@@ -3256,10 +3260,14 @@ int drm_edp_backlight_enable(struct drm_dp_aux *aux, 
const struct drm_edp_backli
}
 
new_dpcd_buf = dpcd_buf;
+   if (bl->aux_set)
+   new_mode = DP_EDP_BACKLIGHT_CONTROL_MODE_DPCD;
+   else
+   new_mode = DP_EDP_BACKLIGHT_CONTROL_MODE_PWM;
 
-   if ((dpcd_buf & DP_EDP_BACKLIGHT_CONTROL_MODE_MASK) != 
DP_EDP_BACKLIGHT_CONTROL_MODE_DPCD) {
+   if ((dpcd_buf & DP_EDP_BACKLIGHT_CONTROL_MODE_MASK) != new_mode) {
new_dpcd_buf &= ~DP_EDP_BACKLIGHT_CONTROL_MODE_MASK;
-   new_dpcd_buf |= DP_EDP_BACKLIGHT_CONTROL_MODE_DPCD;
+   new_dpcd_buf |= new_mode;
 
if (bl->pwmgen_bit_count) {
ret = drm_dp_dpcd_writeb(aux, DP_EDP_PWMGEN_BIT_COUNT, 
bl->pwmgen_bit_count);
@@ -3304,12 +3312,13 @@ EXPORT_SYMBOL(drm_edp_backlight_enable);
  * @aux: The DP AUX channel to use
  * @bl: Backlight capability info from drm_edp_backlight_init()
  *
- * This function handles disabling DPCD backlight controls on a panel over 
AUX. Note that some
- * panels have backlights that are enabled/disabled by other means, despite 
having their brightness
- * values controlled through DPCD. On such panels 
_edp_backlight_info.aux_ena

[Intel-gfx] [PATCH v2 4/4] drm/i915: Clarify probing order in intel_dp_aux_init_backlight_funcs()

[Lyude Paul]

Hooray! We've managed to hit enough bugs upstream that I've been able to
come up with a pretty solid explanation for how backlight controls are
actually supposed to be detected and used these days. As well, having the
rest of the PWM bits in VESA's backlight interface implemented seems to
have fixed all of the problematic brightness controls laptop panels that
we've hit so far.

So, let's actually document this instead of just calling the laptop panels
liars. As well, I would like to formally apologize to all of the laptop
panels I called liars. I'm sorry laptop panels, hopefully you can all
forgive me and we can move past this~

Signed-off-by: Lyude Paul 
---
 .../drm/i915/display/intel_dp_aux_backlight.c| 16 +++-
 1 file changed, 11 insertions(+), 5 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 91daf9ab50e8..04a52d6a74ed 100644
--- a/drivers/gpu/drm/i915/display/intel_dp_aux_backlight.c
+++ b/drivers/gpu/drm/i915/display/intel_dp_aux_backlight.c
@@ -455,11 +455,17 @@ int intel_dp_aux_init_backlight_funcs(struct 
intel_connector *connector)
}
 
/*
-* A lot of eDP panels in the wild will report supporting both the
-* Intel proprietary backlight control interface, and the VESA
-* backlight control interface. Many of these panels are liars though,
-* and will only work with the Intel interface. So, always probe for
-* that first.
+* Since Intel has their own backlight control interface, the majority 
of machines out there
+* using DPCD backlight controls with Intel GPUs will be using this 
interface as opposed to
+* the VESA interface. However, other GPUs (such as Nvidia's) will 
always use the VESA
+* interface. This means that there's quite a number of panels out 
there that will advertise
+* support for both interfaces, primarily systems with Intel/Nvidia 
hybrid GPU setups.
+*
+* There's a catch to this though: on many panels that advertise 
support for both
+* interfaces, the VESA backlight interface will stop working once 
we've programmed the
+* panel with Intel's OUI - which is also required for us to be able to 
detect Intel's
+* backlight interface at all. This means that the only sensible way 
for us to detect both
+* interfaces is to probe for Intel's first, and VESA's second.
 */
if (try_intel_interface && 
intel_dp_aux_supports_hdr_backlight(connector)) {
drm_dbg_kms(dev, "Using Intel proprietary eDP backlight 
controls\n");
-- 
2.31.1

[Intel-gfx] [PATCH v2 1/4] drm/i915: Add support for panels with VESA backlights with PWM enable/disable

[Lyude Paul]

This simply adds proper support for panel backlights that can be controlled
via VESA's backlight control protocol, but which also require that we
enable and disable the backlight via PWM instead of via the DPCD interface.
We also enable this by default, in order to fix some people's backlights
that were broken by not having this enabled.

For reference, backlights that require this and use VESA's backlight
interface tend to be laptops with hybrid GPUs, but this very well may
change in the future.

Signed-off-by: Lyude Paul 
Link: https://gitlab.freedesktop.org/drm/intel/-/issues/3680
Fixes: fe7d52bccab6 ("drm/i915/dp: Don't use DPCD backlights that need PWM 
enable/disable")
Cc:  # v5.12+
---
 .../drm/i915/display/intel_dp_aux_backlight.c | 24 ++-
 1 file changed, 18 insertions(+), 6 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 569d17b4d00f..594fdc7453ca 100644
--- a/drivers/gpu/drm/i915/display/intel_dp_aux_backlight.c
+++ b/drivers/gpu/drm/i915/display/intel_dp_aux_backlight.c
@@ -293,6 +293,10 @@ intel_dp_aux_vesa_enable_backlight(const struct 
intel_crtc_state *crtc_state,
struct intel_panel *panel = >panel;
struct intel_dp *intel_dp = enc_to_intel_dp(connector->encoder);
 
+   if (!panel->backlight.edp.vesa.info.aux_enable)
+   panel->backlight.pwm_funcs->enable(crtc_state, conn_state,
+  
panel->backlight.pwm_level_max);
+
drm_edp_backlight_enable(_dp->aux, 
>backlight.edp.vesa.info, level);
 }
 
@@ -304,6 +308,10 @@ static void intel_dp_aux_vesa_disable_backlight(const 
struct drm_connector_state
struct intel_dp *intel_dp = enc_to_intel_dp(connector->encoder);
 
drm_edp_backlight_disable(_dp->aux, 
>backlight.edp.vesa.info);
+
+   if (!panel->backlight.edp.vesa.info.aux_enable)
+   panel->backlight.pwm_funcs->disable(old_conn_state,
+   
intel_backlight_invert_pwm_level(connector, 0));
 }
 
 static int intel_dp_aux_vesa_setup_backlight(struct intel_connector 
*connector, enum pipe pipe)
@@ -321,6 +329,15 @@ static int intel_dp_aux_vesa_setup_backlight(struct 
intel_connector *connector,
if (ret < 0)
return ret;
 
+   if (!panel->backlight.edp.vesa.info.aux_enable) {
+   ret = panel->backlight.pwm_funcs->setup(connector, pipe);
+   if (ret < 0) {
+   drm_err(>drm,
+   "Failed to setup PWM backlight controls for eDP 
backlight: %d\n",
+   ret);
+   return ret;
+   }
+   }
panel->backlight.max = panel->backlight.edp.vesa.info.max;
panel->backlight.min = 0;
if (current_mode == DP_EDP_BACKLIGHT_CONTROL_MODE_DPCD) {
@@ -340,12 +357,7 @@ intel_dp_aux_supports_vesa_backlight(struct 
intel_connector *connector)
struct intel_dp *intel_dp = intel_attached_dp(connector);
struct drm_i915_private *i915 = dp_to_i915(intel_dp);
 
-   /* TODO: We currently only support AUX only backlight configurations, 
not backlights which
-* require a mix of PWM and AUX controls to work. In the mean time, 
these machines typically
-* work just fine using normal PWM controls anyway.
-*/
-   if ((intel_dp->edp_dpcd[1] & DP_EDP_BACKLIGHT_AUX_ENABLE_CAP) &&
-   drm_edp_backlight_supported(intel_dp->edp_dpcd)) {
+   if (drm_edp_backlight_supported(intel_dp->edp_dpcd)) {
drm_dbg_kms(>drm, "AUX Backlight Control Supported!\n");
return true;
}
-- 
2.31.1

[Intel-gfx] [PATCH v2 2/4] drm/nouveau/kms/nv50-: Explicitly check DPCD backlights for aux enable/brightness

[Lyude Paul]

Since we don't support hybrid AUX/PWM backlights in nouveau right now,
let's add some explicit checks so that we don't break nouveau once we
enable support for these backlights in other drivers.

Signed-off-by: Lyude Paul 
---
 drivers/gpu/drm/nouveau/nouveau_backlight.c | 5 -
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/nouveau/nouveau_backlight.c 
b/drivers/gpu/drm/nouveau/nouveau_backlight.c
index 1cbd71abc80a..ae2f2abc8f5a 100644
--- a/drivers/gpu/drm/nouveau/nouveau_backlight.c
+++ b/drivers/gpu/drm/nouveau/nouveau_backlight.c
@@ -308,7 +308,10 @@ nv50_backlight_init(struct nouveau_backlight *bl,
if (ret < 0)
return ret;
 
-   if (drm_edp_backlight_supported(edp_dpcd)) {
+   /* TODO: Add support for hybrid PWM/DPCD panels */
+   if (drm_edp_backlight_supported(edp_dpcd) &&
+   (edp_dpcd[1] & DP_EDP_BACKLIGHT_AUX_ENABLE_CAP) &&
+   (edp_dpcd[2] & DP_EDP_BACKLIGHT_BRIGHTNESS_AUX_SET_CAP)) {
NV_DEBUG(drm, "DPCD backlight controls supported on 
%s\n",
 nv_conn->base.name);
 
-- 
2.31.1

[Intel-gfx] [PATCH v2 0/4] drm/dp, drm/i915: Finish basic PWM support for VESA backlight helpers

[Lyude Paul]

When I originally moved all of the VESA backlight code in i915 into DRM
helpers, one of the things I didn't have the hardware or time for
testing was machines that used a combination of PWM and DPCD in order to
control their backlights. This has since then caused some breakages and
resulted in us disabling DPCD backlight support on such machines. This
works fine, unless you have a machine that actually needs this
functionality for backlight controls to work at all. Additionally, we
will need to support PWM for when we start adding support for VESA's
product (as in the product of multiplication) control mode for better
brightness ranges.

So - let's finally finish up implementing basic support for these types
of backlights to solve these problems in our DP helpers, along with
implementing support for this in i915. And since digging into this issue
solved the last questions we really had about probing backlights in i915
for the most part, let's update some of the comments around that as
well!

Changes:
* Fixup docs
* Add patch to stop us from breaking nouveau

Lyude Paul (4):
  drm/i915: Add support for panels with VESA backlights with PWM
enable/disable
  drm/nouveau/kms/nv50-: Explicitly check DPCD backlights for aux
enable/brightness
  drm/dp, drm/i915: Add support for VESA backlights using PWM for
brightness control
  drm/i915: Clarify probing order in intel_dp_aux_init_backlight_funcs()

 drivers/gpu/drm/drm_dp_helper.c   | 75 +++--
 .../drm/i915/display/intel_dp_aux_backlight.c | 80 ++-
 drivers/gpu/drm/nouveau/nouveau_backlight.c   |  5 +-
 include/drm/drm_dp_helper.h   |  7 +-
 4 files changed, 122 insertions(+), 45 deletions(-)

-- 
2.31.1

Re: [Intel-gfx] [PATCH 2/3] drm/dp, drm/i915: Add support for VESA backlights using PWM for brightness control

[Lyude Paul]

On Tue, 2021-09-28 at 13:00 -0700, Doug Anderson wrote:
> Hi,
> 
> 
> I'm not sure I understand the comment above. You say "enabled/disabled
> via PWM" and that doesn't make sense w/ my mental model. Normally I
> think of a PWM allowing you to adjust the brightness and there being a
> separate GPIO that's in charge of enable/disable. To some extent you

Oops - you're completely right, it is a GPIO pin and I got myself
confused since in i915 I'm the chipset-specific callbacks for turning
the panel on are intertwined with the PWM callbacks.

> could think of a PWM as being "disabled" when its duty cycle is 0%,
> but usually there's separate "enable" logic that really has nothing to
> do with the PWM itself.
> 
> In general, it seems like the options are:
> 
> 1. DPCD controls PWM and the "enable" logic.
> 
> 2. DPCD controls PWM but requires an external "enable" GPIO.
> 
> 3. We require an external PWM but DPCD controls the "enable" logic.
> 
> Maybe you need a second "capability" to describe whether the client of
> your code knows how to control an enable GPIO? ...or perhaps better
> you don't need a capability and you can just assume that if the client
> needs to set an "enable" GPIO that it will do so. That would match how
> things work today. AKA:
> 
> a) Client calls the AUX backlight code to "enable"
> 
> b) AUX backlight code will set the "enable" bit if supported.
> 
> c) Client will set the "enable" GPIO if it knows about one.
> 
> Presumably only one of b) or c) will actually do something. If neither
> does something then this panel simply isn't compatible with this
> board.

I will definitely take note from this explanation and rewrite some of
the helper docs I'm updating to reflect this, thank you!

Being that I think panel drivers are basically the only other user of
this driver, if you think this is the way to go I'm OK with this. My
original reasoning for having a cap for this was worrying about the ARM
drivers handling this, along with potentially changing backlight
behavior in nouveau. I'm realizing now though that those are probably
problems for nouveau and not the helper, and I could probably avoid
hitting any issues by just adding some additional DPCD checks for GPIO
enabling/PWM passthrough in nouveau itself.

So I'll drop the cap in the next respin of this
> 
> 
> > +/**
> > + * drm_edp_backlight_supported() - Check an eDP DPCD for VESA backlight
> > support
> > + * @aux: The AUX channel, only used for debug logging
> > + * @edp_dpcd: The DPCD to check
> > + * @caps: The backlight capabilities this driver supports
> > + *
> > + * Returns: %True if @edp_dpcd indicates that VESA backlight controls are
> > supported, %false
> > + * otherwise
> > + */
> > +bool drm_edp_backlight_supported(struct drm_dp_aux *aux,
> > +    const u8
> > edp_dpcd[EDP_DISPLAY_CTL_CAP_SIZE],
> > +    enum drm_edp_backlight_driver_caps caps)
> > +{
> > +   if (!(edp_dpcd[1] & DP_EDP_TCON_BACKLIGHT_ADJUSTMENT_CAP))
> > +   return false;
> > +
> > +   if (!(caps & DRM_EDP_BACKLIGHT_DRIVER_CAP_PWM) &&
> > +   (!(edp_dpcd[2] & DP_EDP_BACKLIGHT_BRIGHTNESS_AUX_SET_CAP) ||
> > +    !(edp_dpcd[2] & DP_EDP_BACKLIGHT_AUX_ENABLE_CAP))) {
> 
> Elsewhere you match DP_EDP_BACKLIGHT_AUX_ENABLE_CAP against
> edp_dpcd[1]. Here you match against [2]. Are you sure that's correct?

absolutely not! thank you for catching this

> 
> 
> >  /*
> >   * DisplayPort AUX channel
> >   */
> > @@ -2200,7 +2182,11 @@ drm_dp_has_quirk(const struct drm_dp_desc *desc,
> > enum drm_dp_quirk quirk)
> >   * @pwm_freq_pre_divider: The PWM frequency pre-divider value being used
> > for this backlight, if any
> >   * @max: The maximum backlight level that may be set
> >   * @lsb_reg_used: Do we also write values to the
> > DP_EDP_BACKLIGHT_BRIGHTNESS_LSB register?
> > - * @aux_enable: Does the panel support the AUX enable cap?
> > + * @aux_enable: Does the panel support the AUX enable cap? Always %false
> > when the driver doesn't
> > + * support %DRM_EDP_BACKLIGHT_DRIVER_CAP_PWM
> 
> Why is aux_enable always false if it doesn't support
> DRM_EDP_BACKLIGHT_DRIVER_CAP_PWM? It doesn't seem like the code
> enforces this and I'm not sure why it would. Am I confused?

This was mainly just to keep the behavior identical for drivers that
didn't support controlling backlights like this, but re: the response I
wrote up above I think we can just totally drop the caps.

> 

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

[Intel-gfx] [PATCH 3/3] drm/i915: Clarify probing order in intel_dp_aux_init_backlight_funcs()

[Lyude Paul]

Hooray! We've managed to hit enough bugs upstream that I've been able to
come up with a pretty solid explanation for how backlight controls are
actually supposed to be detected and used these days. As well, having the
rest of the PWM bits in VESA's backlight interface implemented seems to
have fixed all of the problematic brightness controls laptop panels that
we've hit so far.

So, let's actually document this instead of just calling the laptop panels
liars. As well, I would like to formally apologize to all of the laptop
panels I called liars. I'm sorry laptop panels, hopefully you can all
forgive me and we can move past this~

Signed-off-by: Lyude Paul 
---
 .../drm/i915/display/intel_dp_aux_backlight.c| 16 +++-
 1 file changed, 11 insertions(+), 5 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 9b1ac02b0263..1e20c607408c 100644
--- a/drivers/gpu/drm/i915/display/intel_dp_aux_backlight.c
+++ b/drivers/gpu/drm/i915/display/intel_dp_aux_backlight.c
@@ -456,11 +456,17 @@ int intel_dp_aux_init_backlight_funcs(struct 
intel_connector *connector)
}
 
/*
-* A lot of eDP panels in the wild will report supporting both the
-* Intel proprietary backlight control interface, and the VESA
-* backlight control interface. Many of these panels are liars though,
-* and will only work with the Intel interface. So, always probe for
-* that first.
+* Since Intel has their own backlight control interface, the majority 
of machines out there
+* using DPCD backlight controls with Intel GPUs will be using this 
interface as opposed to
+* the VESA interface. However, other GPUs (such as Nvidia's) will 
always use the VESA
+* interface. This means that there's quite a number of panels out 
there that will advertise
+* support for both interfaces, primarily systems with Intel/Nvidia 
hybrid GPU setups.
+*
+* There's a catch to this though: on many panels that advertise 
support for both
+* interfaces, the VESA backlight interface will stop working once 
we've programmed the
+* panel with Intel's OUI - which is also required for us to be able to 
detect Intel's
+* backlight interface at all. This means that the only sensible way 
for us to detect both
+* interfaces is to probe for Intel's first, and VESA's second.
 */
if (try_intel_interface && 
intel_dp_aux_supports_hdr_backlight(connector)) {
drm_dbg_kms(dev, "Using Intel proprietary eDP backlight 
controls\n");
-- 
2.31.1

[Intel-gfx] [PATCH 2/3] drm/dp, drm/i915: Add support for VESA backlights using PWM for brightness control

[Lyude Paul]

Now that we've added support to i915 for controlling panel backlights that
need PWM to be enabled/disabled, let's finalize this and add support for
controlling brightness levels via PWM as well. This should hopefully put us
towards the path of supporting _ALL_ backlights via VESA's DPCD interface
which would allow us to finally start trusting the DPCD again.

Note that for the DRM helpers for this, we change some behavior by starting
to hide all backlights that require PWM controls by default, and require
that the driver pass our new DRM_EDP_BACKLIGHT_DRIVER_CAP_PWM flag to
drm_edp_backlight_supported(). The primary reason for doing this is that
panels requiring PWM in addition to DPCD controls will require additional
implementation on the driver's side, as there's no way for us to handle
PWM controls from the helpers in a driver-independent way.

Note however that we still don't enable using this by default when it's not
needed, primarily because I haven't yet had a chance to confirm if it's
safe to do this on the one machine in Intel's CI that had an issue with
this: samus-fi-bdw. I have done basic testing of this on other machines
though, by manually patching i915 to force it into PWM-only mode on some of
my laptops.

Signed-off-by: Lyude Paul 
Cc: Rajeev Nandan 
Cc: Doug Anderson 
Cc: Satadru Pramanik 
---
 drivers/gpu/drm/drm_dp_helper.c   | 102 ++
 .../drm/i915/display/intel_dp_aux_backlight.c |  51 ++---
 drivers/gpu/drm/nouveau/nouveau_backlight.c   |   2 +-
 include/drm/drm_dp_helper.h   |  46 
 4 files changed, 146 insertions(+), 55 deletions(-)

diff --git a/drivers/gpu/drm/drm_dp_helper.c b/drivers/gpu/drm/drm_dp_helper.c
index 4d0d1e8e51fa..a1cf849fc6ed 100644
--- a/drivers/gpu/drm/drm_dp_helper.c
+++ b/drivers/gpu/drm/drm_dp_helper.c
@@ -3163,7 +3163,10 @@ EXPORT_SYMBOL(drm_dp_pcon_convert_rgb_to_ycbcr);
  * @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().
+ * already have been enabled by the driver by calling 
drm_edp_backlight_enable(). Note that if the
+ * panel in question requires the PWM pin be used to control brightness levels 
(e.g.
+ * _edp_backlight_info.aux_set is %false), then this function becomes a 
no-op and it is up to
+ * the driver to handle adjusting the brightness levels.
  *
  * Returns: %0 on success, negative error code on failure
  */
@@ -3173,6 +3176,10 @@ int drm_edp_backlight_set_level(struct drm_dp_aux *aux, 
const struct drm_edp_bac
int ret;
u8 buf[2] = { 0 };
 
+   /* The panel uses PWM for controlling brightness levels */
+   if (!bl->aux_set)
+   return 0;
+
if (bl->lsb_reg_used) {
buf[0] = (level & 0xff00) >> 8;
buf[1] = (level & 0x00ff);
@@ -3234,11 +3241,8 @@ drm_edp_backlight_set_enable(struct drm_dp_aux *aux, 
const struct drm_edp_backli
  * 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. On such panels
- * _edp_backlight_info.aux_enable will be set to %false, this function 
will skip the step of
- * programming the %DP_EDP_DISPLAY_CONTROL_REGISTER, and the driver must 
perform the required
- * implementation specific step for enabling the backlight after calling this 
function.
+ * Drivers supporting %DRM_EDP_BACKLIGHT_DRIVER_CAP_PWM are expected to enable 
the panel backlight
+ * and/or program the panel's brightness level after calling this function.
  *
  * Returns: %0 on success, negative error code on failure.
  */
@@ -3246,7 +3250,7 @@ int drm_edp_backlight_enable(struct drm_dp_aux *aux, 
const struct drm_edp_backli
 const u16 level)
 {
int ret;
-   u8 dpcd_buf, new_dpcd_buf;
+   u8 dpcd_buf, new_dpcd_buf, new_mode;
 
ret = drm_dp_dpcd_readb(aux, DP_EDP_BACKLIGHT_MODE_SET_REGISTER, 
_buf);
if (ret != 1) {
@@ -3256,10 +3260,14 @@ int drm_edp_backlight_enable(struct drm_dp_aux *aux, 
const struct drm_edp_backli
}
 
new_dpcd_buf = dpcd_buf;
+   if (bl->aux_set)
+   new_mode = DP_EDP_BACKLIGHT_CONTROL_MODE_DPCD;
+   else
+   new_mode = DP_EDP_BACKLIGHT_CONTROL_MODE_PWM;
 
-   if ((dpcd_buf & DP_EDP_BACKLIGHT_CONTROL_MODE_MASK) != 
DP_EDP_BACKLIGHT_CONTROL_MODE_DPCD) {
+   if ((dpcd_buf & DP_EDP_BACKLIGHT_CONTROL_MODE_MASK) != new_mode) {
new_dpcd_buf &= ~DP_EDP_BACKLIGHT_CONTROL_MODE_MASK;
-   new_dpcd_buf |= DP_EDP_BACKLIGHT_CONTROL_MODE_DPCD;
+   new_dpcd_buf |= new_mode;
 
 

[Intel-gfx] [PATCH 1/3] drm/i915: Add support for panels with VESA backlights with PWM enable/disable

[Lyude Paul]

This simply adds proper support for panel backlights that can be controlled
via VESA's backlight control protocol, but which also require that we
enable and disable the backlight via PWM instead of via the DPCD interface.
We also enable this by default, in order to fix some people's backlights
that were broken by not having this enabled.

For reference, backlights that require this and use VESA's backlight
interface tend to be laptops with hybrid GPUs, but this very well may
change in the future.

Signed-off-by: Lyude Paul 
Link: https://gitlab.freedesktop.org/drm/intel/-/issues/3680
Fixes: fe7d52bccab6 ("drm/i915/dp: Don't use DPCD backlights that need PWM 
enable/disable")
Cc:  # v5.12+
---
 .../drm/i915/display/intel_dp_aux_backlight.c | 24 ++-
 1 file changed, 18 insertions(+), 6 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 569d17b4d00f..594fdc7453ca 100644
--- a/drivers/gpu/drm/i915/display/intel_dp_aux_backlight.c
+++ b/drivers/gpu/drm/i915/display/intel_dp_aux_backlight.c
@@ -293,6 +293,10 @@ intel_dp_aux_vesa_enable_backlight(const struct 
intel_crtc_state *crtc_state,
struct intel_panel *panel = >panel;
struct intel_dp *intel_dp = enc_to_intel_dp(connector->encoder);
 
+   if (!panel->backlight.edp.vesa.info.aux_enable)
+   panel->backlight.pwm_funcs->enable(crtc_state, conn_state,
+  
panel->backlight.pwm_level_max);
+
drm_edp_backlight_enable(_dp->aux, 
>backlight.edp.vesa.info, level);
 }
 
@@ -304,6 +308,10 @@ static void intel_dp_aux_vesa_disable_backlight(const 
struct drm_connector_state
struct intel_dp *intel_dp = enc_to_intel_dp(connector->encoder);
 
drm_edp_backlight_disable(_dp->aux, 
>backlight.edp.vesa.info);
+
+   if (!panel->backlight.edp.vesa.info.aux_enable)
+   panel->backlight.pwm_funcs->disable(old_conn_state,
+   
intel_backlight_invert_pwm_level(connector, 0));
 }
 
 static int intel_dp_aux_vesa_setup_backlight(struct intel_connector 
*connector, enum pipe pipe)
@@ -321,6 +329,15 @@ static int intel_dp_aux_vesa_setup_backlight(struct 
intel_connector *connector,
if (ret < 0)
return ret;
 
+   if (!panel->backlight.edp.vesa.info.aux_enable) {
+   ret = panel->backlight.pwm_funcs->setup(connector, pipe);
+   if (ret < 0) {
+   drm_err(>drm,
+   "Failed to setup PWM backlight controls for eDP 
backlight: %d\n",
+   ret);
+   return ret;
+   }
+   }
panel->backlight.max = panel->backlight.edp.vesa.info.max;
panel->backlight.min = 0;
if (current_mode == DP_EDP_BACKLIGHT_CONTROL_MODE_DPCD) {
@@ -340,12 +357,7 @@ intel_dp_aux_supports_vesa_backlight(struct 
intel_connector *connector)
struct intel_dp *intel_dp = intel_attached_dp(connector);
struct drm_i915_private *i915 = dp_to_i915(intel_dp);
 
-   /* TODO: We currently only support AUX only backlight configurations, 
not backlights which
-* require a mix of PWM and AUX controls to work. In the mean time, 
these machines typically
-* work just fine using normal PWM controls anyway.
-*/
-   if ((intel_dp->edp_dpcd[1] & DP_EDP_BACKLIGHT_AUX_ENABLE_CAP) &&
-   drm_edp_backlight_supported(intel_dp->edp_dpcd)) {
+   if (drm_edp_backlight_supported(intel_dp->edp_dpcd)) {
drm_dbg_kms(>drm, "AUX Backlight Control Supported!\n");
return true;
}
-- 
2.31.1

[Intel-gfx] [PATCH 0/3] drm/dp, drm/i915: Finish basic PWM support for VESA backlight helpers

[Lyude Paul]

When I originally moved all of the VESA backlight code in i915 into DRM
helpers, one of the things I didn't have the hardware or time for
testing was machines that used a combination of PWM and DPCD in order to
control their backlights. This has since then caused some breakages and
resulted in us disabling DPCD backlight support on such machines. This
works fine, unless you have a machine that actually needs this
functionality for backlight controls to work at all. Additionally, we
will need to support PWM for when we start adding support for VESA's
product (as in the product of multiplication) control mode for better
brightness ranges.

So - let's finally finish up implementing basic support for these types
of backlights to solve these problems in our DP helpers, along with
implementing support for this in i915. And since digging into this issue
solved the last questions we really had about probing backlights in i915
for the most part, let's update some of the comments around that as
well!

Lyude Paul (3):
  drm/i915: Add support for panels with VESA backlights with PWM
enable/disable
  drm/dp, drm/i915: Add support for VESA backlights using PWM for
brightness control
  drm/i915: Clarify probing order in intel_dp_aux_init_backlight_funcs()

 drivers/gpu/drm/drm_dp_helper.c   | 102 ++
 .../drm/i915/display/intel_dp_aux_backlight.c |  81 ++
 drivers/gpu/drm/nouveau/nouveau_backlight.c   |   2 +-
 include/drm/drm_dp_helper.h   |  46 
 4 files changed, 170 insertions(+), 61 deletions(-)

-- 
2.31.1

Re: [Intel-gfx] [PATCH 9/9] drm/i915: Add privacy-screen support

[Lyude Paul]

On Thu, 2021-09-16 at 12:32 +0200, Hans de Goede wrote:
> 
> I'm fine with refactoring this a bit and adding
> an intel_modeset_probe_defer() helper for this, I assume I should also
> move the vga_switcheroo_client_probe_defer(pdev) check there?
> 
> As you suggested yourself in your reply to the coverletter I will
> push out the rest of the series to drm-misc-next while we figure this
> out. Assuming Lyude is happy with the answers which I gave to her
> remarks about some of the other patches.

I am, btw!

> 
> Regards,
> 
> Hans
> 

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

Re: [Intel-gfx] [PATCH 4/9] drm/privacy-screen: Add notifier support

[Lyude Paul]

On Thu, 2021-09-16 at 11:06 +0200, Hans de Goede wrote:
> Hi,
> 
> On 9/15/21 10:26 PM, Lyude Paul wrote:
> > On Mon, 2021-09-06 at 09:35 +0200, Hans de Goede wrote:
> > > Add support for privacy-screen consumers to register a notifier to
> > > be notified of external (e.g. done by the hw itself on a hotkey press)
> > > state changes.
> > > 
> > > Reviewed-by: Emil Velikov 
> > > Signed-off-by: Hans de Goede 
> > > ---
> > >  drivers/gpu/drm/drm_privacy_screen.c  | 67 +++
> > >  include/drm/drm_privacy_screen_consumer.h | 15 +
> > >  include/drm/drm_privacy_screen_driver.h   |  4 ++
> > >  3 files changed, 86 insertions(+)
> > > 
> > > diff --git a/drivers/gpu/drm/drm_privacy_screen.c
> > > b/drivers/gpu/drm/drm_privacy_screen.c
> > > index 294a09194bfb..7a5f878c3171 100644
> > > --- a/drivers/gpu/drm/drm_privacy_screen.c
> > > +++ b/drivers/gpu/drm/drm_privacy_screen.c
> > > @@ -255,6 +255,49 @@ void drm_privacy_screen_get_state(struct
> > > drm_privacy_screen *priv,
> > >  }
> > >  EXPORT_SYMBOL(drm_privacy_screen_get_state);
> > >  
> > > +/**
> > > + * drm_privacy_screen_register_notifier - register a notifier
> > > + * @priv: Privacy screen to register the notifier with
> > > + * @nb: Notifier-block for the notifier to register
> > > + *
> > > + * Register a notifier with the privacy-screen to be notified of
> > > changes
> > > made
> > > + * to the privacy-screen state from outside of the privacy-screen
> > > class.
> > > + * E.g. the state may be changed by the hardware itself in response to
> > > a
> > > + * hotkey press.
> > > + *
> > > + * The notifier is called with no locks held. The new hw_state and
> > > sw_state
> > > + * can be retrieved using the drm_privacy_screen_get_state() function.
> > > + * A pointer to the drm_privacy_screen's struct is passed as the void
> > > *data
> > > + * argument of the notifier_block's notifier_call.
> > > + *
> > > + * The notifier will NOT be called when changes are made through
> > > + * drm_privacy_screen_set_sw_state(). It is only called for external
> > > changes.
> > > + *
> > > + * Return: 0 on success, negative error code on failure.
> > > + */
> > > +int drm_privacy_screen_register_notifier(struct drm_privacy_screen
> > > *priv,
> > > +    struct notifier_block *nb)
> > > +{
> > > +   return blocking_notifier_chain_register(>notifier_head,
> > > nb);
> > > +}
> > > +EXPORT_SYMBOL(drm_privacy_screen_register_notifier);
> > > +
> > > +/**
> > > + * drm_privacy_screen_unregister_notifier - unregister a notifier
> > > + * @priv: Privacy screen to register the notifier with
> > > + * @nb: Notifier-block for the notifier to register
> > > + *
> > > + * Unregister a notifier registered with
> > > drm_privacy_screen_register_notifier().
> > > + *
> > > + * Return: 0 on success, negative error code on failure.
> > > + */
> > > +int drm_privacy_screen_unregister_notifier(struct drm_privacy_screen
> > > *priv,
> > > +  struct notifier_block *nb)
> > > +{
> > > +   return blocking_notifier_chain_unregister(>notifier_head,
> > > nb);
> > > +}
> > > +EXPORT_SYMBOL(drm_privacy_screen_unregister_notifier);
> > > +
> > >  /*** drm_privacy_screen_driver.h functions ***/
> > >  
> > >  static ssize_t sw_state_show(struct device *dev,
> > > @@ -352,6 +395,7 @@ struct drm_privacy_screen
> > > *drm_privacy_screen_register(
> > > return ERR_PTR(-ENOMEM);
> > >  
> > > mutex_init(>lock);
> > > +   BLOCKING_INIT_NOTIFIER_HEAD(>notifier_head);
> > >  
> > > priv->dev.class = drm_class;
> > > priv->dev.type = _privacy_screen_type;
> > > @@ -399,3 +443,26 @@ void drm_privacy_screen_unregister(struct
> > > drm_privacy_screen *priv)
> > > device_unregister(>dev);
> > >  }
> > >  EXPORT_SYMBOL(drm_privacy_screen_unregister);
> > > +
> > > +/**
> > > + * drm_privacy_screen_call_notifier_chain - notify consumers of state
> > > change
> > > + * @priv: Privacy screen to register the notifier with
> > 

Re: [Intel-gfx] [PATCH 0/9] drm: Add privacy-screen class and connector properties

[Lyude Paul]

OK! Looked over all of these patches. Patches 2 and 4 have some comments that
should be addressed, but otherwise this series is:

Reviewed-by: Lyude Paul 

Let me know when/if you need help pushing this upstream

On Mon, 2021-09-06 at 09:35 +0200, Hans de Goede wrote:
> Hi all,
> 
> Here is the privacy-screen related code which I last posted in April 2021
> To the best of my knowledge there is consensus about / everyone is in
> agreement with the new userspace API (2 connector properties) this
> patch-set add (patch 1 of the series).
> 
> This is unchanged (except for a rebase on drm-tip), what has changed is
> that the first userspace consumer of the new properties is now fully ready
> for merging (it is just waiting for the kernel bits to land first):
> 
>  -
> https://gitlab.gnome.org/GNOME/gsettings-desktop-schemas/-/merge_requests/49
>  - https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1952
>  - https://gitlab.gnome.org/GNOME/gnome-control-center/-/merge_requests/1032
> 
> Having a userspace-consumer of the API fully ready for merging, clears the
> last blocker for this series. It has already has been reviewed before
> by Emil Velikov, but it could really do with another review.
> 
> The new API works as designed and add the following features to GNOME:
> 
> 1. Showing an OSD notification when the privacy-screen is toggled on/off
>    through hotkeys handled by the embedded-controller
> 2. Allowing control of the privacy-screen from the GNOME control-panel,
>    including the on/off slider shown there updating to match the hw-setting
>    when the setting is changed with the control-panel open.
> 3. Restoring the last user-setting at login
> 
> This series consists of a number of different parts:
> 
> 1. A new version of Rajat's privacy-screen connector properties patch,
> this adds new userspace API in the form of new properties
> 
> 2. Since on most devices the privacy screen is actually controlled by
> some vendor specific ACPI/WMI interface which has a driver under
> drivers/platform/x86, we need some "glue" code to make this functionality
> available to KMS drivers. Patches 2-4 add a new privacy-screen class for
> this, which allows non KMS drivers (and possibly KMS drivers too) to
> register a privacy-screen device and also adds an interface for KMS drivers
> to get access to the privacy-screen associated with a specific connector.
> This is modelled similar to how we deal with e.g. PWMs and GPIOs in the
> kernel, including separate includes for consumers and providers(drivers).
> 
> 3. Some drm_connector helper functions to keep the actual changes needed
> for this in individual KMS drivers as small as possible (patch 5).
> 
> 4. Make the thinkpad_acpi code register a privacy-screen device on
> ThinkPads with a privacy-screen (patches 6-8)
> 
> 5. Make the i915 driver export the privacy-screen functionality through
> the connector properties on the eDP connector.
> 
> I believe that it would be best to merge the entire series, including
> the thinkpad_acpi changes through drm-misc in one go. As the pdx86
> subsys maintainer I hereby give my ack for merging the thinkpad_acpi
> changes through drm-misc.
> 
> There is one small caveat with this series, which it is good to be
> aware of. The i915 driver will now return -EPROBE_DEFER on Thinkpads
> with an eprivacy screen, until the thinkpad_acpi driver is loaded.
> This means that initrd generation tools will need to be updated to
> include thinkpad_acpi when the i915 driver is added to the initrd.
> Without this the loading of the i915 driver will be delayed to after
> the switch to real rootfs.
> 
> Regards,
> 
> Hans
> 
> 
> Hans de Goede (8):
>   drm: Add privacy-screen class (v3)
>   drm/privacy-screen: Add X86 specific arch init code
>   drm/privacy-screen: Add notifier support
>   drm/connector: Add a drm_connector privacy-screen helper functions
>   platform/x86: thinkpad_acpi: Add hotkey_notify_extended_hotkey()
>     helper
>   platform/x86: thinkpad_acpi: Get privacy-screen / lcdshadow ACPI
>     handles only once
>   platform/x86: thinkpad_acpi: Register a privacy-screen device
>   drm/i915: Add privacy-screen support
> 
> Rajat Jain (1):
>   drm/connector: Add support for privacy-screen properties (v4)
> 
>  Documentation/gpu/drm-kms-helpers.rst    |  15 +
>  Documentation/gpu/drm-kms.rst    |   2 +
>  MAINTAINERS  |   8 +
>  drivers/gpu/drm/Kconfig  |   4 +
>  drivers/gpu/drm/Makefile |   1 +
>  drivers/gpu/drm/drm_atomic_uapi.c    |   4 +
>  drivers/gpu/drm/drm_connector.c  | 214 +
>  drivers/gpu/drm/drm_drv.c   

Re: [Intel-gfx] [PATCH 9/9] drm/i915: Add privacy-screen support

[Lyude Paul]

(connector,
> +   
> privacy_screen);
> +   } else if (PTR_ERR(privacy_screen) != -ENODEV) {
> +   drm_warn(_priv->drm, "Error getting privacy-screen\n");
> +   }
> +
> return true;
>  
>  out_vdd_off:
> diff --git a/drivers/gpu/drm/i915/i915_pci.c
> b/drivers/gpu/drm/i915/i915_pci.c
> index 146f7e39182a..d6913f567a1c 100644
> --- a/drivers/gpu/drm/i915/i915_pci.c
> +++ b/drivers/gpu/drm/i915/i915_pci.c
> @@ -25,6 +25,7 @@
>  #include 
>  
>  #include 
> +#include 
>  #include 
>  
>  #include "i915_drv.h"
> @@ -1167,6 +1168,7 @@ static int i915_pci_probe(struct pci_dev *pdev, const
> struct pci_device_id *ent)
>  {
> struct intel_device_info *intel_info =
> (struct intel_device_info *) ent->driver_data;
> +   struct drm_privacy_screen *privacy_screen;
> int err;
>  
> if (intel_info->require_force_probe &&
> @@ -1195,7 +1197,17 @@ static int i915_pci_probe(struct pci_dev *pdev, const
> struct pci_device_id *ent)
> if (vga_switcheroo_client_probe_defer(pdev))
> return -EPROBE_DEFER;
>  
> +   /*
> +    * We do not handle -EPROBE_DEFER further into the probe process, so
> +    * check if we have a laptop-panel privacy-screen for which the
> driver
> +    * has not loaded yet here.
> +    */
> +   privacy_screen = drm_privacy_screen_get(>dev, NULL);
> +   if (IS_ERR(privacy_screen) && PTR_ERR(privacy_screen) == -
> EPROBE_DEFER)
> +   return -EPROBE_DEFER;
> +
> err = i915_driver_probe(pdev, ent);
> +   drm_privacy_screen_put(privacy_screen);
> if (err)
> return err;
>  

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

Re: [Intel-gfx] [PATCH 8/9] platform/x86: thinkpad_acpi: Register a privacy-screen device

[Lyude Paul]

tate,
> +   .get_hw_state = lcdshadow_get_hw_state,
> +};
> +
>  static int tpacpi_lcdshadow_init(struct ibm_init_struct *iibm)
>  {
> acpi_status status1, status2;
> @@ -9850,36 +9868,44 @@ static int tpacpi_lcdshadow_init(struct
> ibm_init_struct *iibm)
>  
> status1 = acpi_get_handle(hkey_handle, "GSSS",
> _get_handle);
> status2 = acpi_get_handle(hkey_handle, "",
> _set_handle);
> -   if (ACPI_FAILURE(status1) || ACPI_FAILURE(status2)) {
> -   lcdshadow_state = -ENODEV;
> +   if (ACPI_FAILURE(status1) || ACPI_FAILURE(status2))
> return 0;
> -   }
>  
> -   if (!acpi_evalf(lcdshadow_get_handle, , NULL, "dd", 0)) {
> -   lcdshadow_state = -EIO;
> +   if (!acpi_evalf(lcdshadow_get_handle, , NULL, "dd", 0))
> return -EIO;
> -   }
> -   if (!(output & 0x1)) {
> -   lcdshadow_state = -ENODEV;
> +
> +   if (!(output & 0x1))
> return 0;
> -   }
> -   lcdshadow_state = output & 0x1;
> +
> +   lcdshadow_dev = drm_privacy_screen_register(_pdev->dev,
> +   _ops);
> +   if (IS_ERR(lcdshadow_dev))
> +   return PTR_ERR(lcdshadow_dev);
>  
> return 0;
>  }
>  
> +static void lcdshadow_exit(void)
> +{
> +   drm_privacy_screen_unregister(lcdshadow_dev);
> +}
> +
>  static void lcdshadow_resume(void)
>  {
> -   if (lcdshadow_state >= 0)
> -   lcdshadow_on_off(lcdshadow_state);
> +   if (!lcdshadow_dev)
> +   return;
> +
> +   mutex_lock(_dev->lock);
> +   lcdshadow_set_sw_state(lcdshadow_dev, lcdshadow_dev->sw_state);
> +   mutex_unlock(_dev->lock);
>  }
>  

For privacy screens provided by x86 platform drivers this is -probably-
correct, but only so long as we're confident that the privacy screen is always
going to be controllable regardless of the power state of the actual LCD
panel.

I'd think we would need to handle suspend/resume in the atomic commit though
if we ever have to support systems where the two are dependent on one another,
but, that's a simple enough change to do later if it arises that I think we
can ignore it for now.

>  static int lcdshadow_read(struct seq_file *m)
>  {
> -   if (lcdshadow_state < 0) {
> +   if (!lcdshadow_dev) {
> seq_puts(m, "status:\t\tnot supported\n");
> } else {
> -   seq_printf(m, "status:\t\t%d\n", lcdshadow_state);
> +   seq_printf(m, "status:\t\t%d\n", lcdshadow_dev->hw_state);
> seq_puts(m, "commands:\t0, 1\n");
> }
>  
> @@ -9891,7 +9917,7 @@ static int lcdshadow_write(char *buf)
> char *cmd;
> int res, state = -EINVAL;
>  
> -   if (lcdshadow_state < 0)
> +   if (!lcdshadow_dev)
> return -ENODEV;
>  
> while ((cmd = strsep(, ","))) {
> @@ -9903,11 +9929,18 @@ static int lcdshadow_write(char *buf)
> if (state >= 2 || state < 0)
> return -EINVAL;
>  
> -   return lcdshadow_set(state);
> +   mutex_lock(_dev->lock);
> +   res = lcdshadow_set_sw_state(lcdshadow_dev, state);
> +   mutex_unlock(_dev->lock);
> +
> +   drm_privacy_screen_call_notifier_chain(lcdshadow_dev);
> +
> +   return res;
>  }
>  
>  static struct ibm_struct lcdshadow_driver_data = {
> .name = "lcdshadow",
> +   .exit = lcdshadow_exit,
> .resume = lcdshadow_resume,
> .read = lcdshadow_read,
> .write = lcdshadow_write,
> @@ -10717,6 +10750,14 @@ static void tpacpi_driver_event(const unsigned int
> hkey_event)
> if (!atomic_add_unless(_ignore_event, -1, 0))
> dytc_profile_refresh();
> }
> +
> +   if (lcdshadow_dev && hkey_event == TP_HKEY_EV_PRIVACYGUARD_TOGGLE) {
> +   mutex_lock(_dev->lock);
> +   lcdshadow_get_hw_state(lcdshadow_dev);
> +   mutex_unlock(_dev->lock);
> +
> +   drm_privacy_screen_call_notifier_chain(lcdshadow_dev);
> +   }
>  }
>  
>  static void hotkey_driver_event(const unsigned int scancode)

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

Re: [Intel-gfx] [PATCH 4/9] drm/privacy-screen: Add notifier support

[Lyude Paul]

ifier_head, 0, priv);
> +}
> +EXPORT_SYMBOL(drm_privacy_screen_call_notifier_chain);
> diff --git a/include/drm/drm_privacy_screen_consumer.h
> b/include/drm/drm_privacy_screen_consumer.h
> index 0cbd23b0453d..7f66a90d15b7 100644
> --- a/include/drm/drm_privacy_screen_consumer.h
> +++ b/include/drm/drm_privacy_screen_consumer.h
> @@ -24,6 +24,11 @@ int drm_privacy_screen_set_sw_state(struct
> drm_privacy_screen *priv,
>  void drm_privacy_screen_get_state(struct drm_privacy_screen *priv,
>   enum drm_privacy_screen_status
> *sw_state_ret,
>   enum drm_privacy_screen_status
> *hw_state_ret);
> +
> +int drm_privacy_screen_register_notifier(struct drm_privacy_screen *priv,
> +    struct notifier_block *nb);
> +int drm_privacy_screen_unregister_notifier(struct drm_privacy_screen *priv,
> +  struct notifier_block *nb);
>  #else
>  static inline struct drm_privacy_screen *drm_privacy_screen_get(struct
> device *dev,
> const char
> *con_id)
> @@ -45,6 +50,16 @@ static inline void drm_privacy_screen_get_state(struct
> drm_privacy_screen *priv,
> *sw_state_ret = PRIVACY_SCREEN_DISABLED;
> *hw_state_ret = PRIVACY_SCREEN_DISABLED;
>  }
> +static inline int drm_privacy_screen_register_notifier(struct
> drm_privacy_screen *priv,
> +  struct notifier_block
> *nb)
> +{
> +   return -ENODEV;
> +}
> +static inline int drm_privacy_screen_unregister_notifier(struct
> drm_privacy_screen *priv,
> +    struct
> notifier_block *nb)
> +{
> +   return -ENODEV;
> +}
>  #endif
>  
>  #endif
> diff --git a/include/drm/drm_privacy_screen_driver.h
> b/include/drm/drm_privacy_screen_driver.h
> index 5187ae52eb03..24591b607675 100644
> --- a/include/drm/drm_privacy_screen_driver.h
> +++ b/include/drm/drm_privacy_screen_driver.h
> @@ -54,6 +54,8 @@ struct drm_privacy_screen {
> struct mutex lock;
> /** @list: privacy-screen devices list list-entry. */
> struct list_head list;
> +   /** @notifier_head: privacy-screen notifier head. */
> +   struct blocking_notifier_head notifier_head;
> /**
>  * @ops:  drm_privacy_screen_ops for this privacy-screen.
>  * This is NULL if the driver has unregistered the privacy-screen.
> @@ -77,4 +79,6 @@ struct drm_privacy_screen *drm_privacy_screen_register(
> struct device *parent, const struct drm_privacy_screen_ops *ops);
>  void drm_privacy_screen_unregister(struct drm_privacy_screen *priv);
>  
> +void drm_privacy_screen_call_notifier_chain(struct drm_privacy_screen
> *priv);
> +
>  #endif

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

Re: [Intel-gfx] [PATCH 2/9] drm: Add privacy-screen class (v3)

[Lyude Paul]

state.
> +    * This is always called with the drm_privacy_screen's lock held.
> +    */
> +   int (*set_sw_state)(struct drm_privacy_screen *priv,
> +   enum drm_privacy_screen_status sw_state);
> +   /**
> +    * @get_hw_state: Called to request that the driver gets the current
> +    * privacy-screen state from the hardware and then updates sw_state
> and
> +    * hw_state accordingly. This will be called by the core just before
> +    * the privacy-screen is registered in sysfs.
> +    */
> +   void (*get_hw_state)(struct drm_privacy_screen *priv);
> +};
> +
> +/**
> + * struct drm_privacy_screen - central privacy-screen structure
> + *
> + * Central privacy-screen structure, this contains the struct device used
> + * to register the screen in sysfs, the screen's state, ops, etc.
> + */
> +struct drm_privacy_screen {
> +   /** @dev: device used to register the privacy-screen in sysfs. */
> +   struct device dev;
> +   /** @lock: mutex protection all fields in this struct. */
> +   struct mutex lock;
> +   /** @list: privacy-screen devices list list-entry. */
> +   struct list_head list;
> +   /**
> +    * @ops:  drm_privacy_screen_ops for this privacy-screen.
> +    * This is NULL if the driver has unregistered the privacy-screen.
> +    */
> +   const struct drm_privacy_screen_ops *ops;
> +   /**
> +    * @sw_state: The privacy-screen's software state, see
> +    * :ref:`Standard Connector
> Properties`
> +    * for more info.
> +    */
> +   enum drm_privacy_screen_status sw_state;
> +   /**
> +    * @hw_state: The privacy-screen's hardware state, see
> +    * :ref:`Standard Connector
> Properties`
> +    * for more info.
> +    */
> +   enum drm_privacy_screen_status hw_state;
> +};
> +
> +struct drm_privacy_screen *drm_privacy_screen_register(
> +   struct device *parent, const struct drm_privacy_screen_ops *ops);
> +void drm_privacy_screen_unregister(struct drm_privacy_screen *priv);
> +
> +#endif
> diff --git a/include/drm/drm_privacy_screen_machine.h
> b/include/drm/drm_privacy_screen_machine.h
> new file mode 100644
> index ..aaa0d38cce92
> --- /dev/null
> +++ b/include/drm/drm_privacy_screen_machine.h
> @@ -0,0 +1,41 @@
> +/* SPDX-License-Identifier: MIT */
> +/*
> + * Copyright (C) 2020 Red Hat, Inc.
> + *
> + * Authors:
> + * Hans de Goede 
> + */
> +
> +#ifndef __DRM_PRIVACY_SCREEN_MACHINE_H__
> +#define __DRM_PRIVACY_SCREEN_MACHINE_H__
> +
> +#include 
> +
> +/**
> + * struct drm_privacy_screen_lookup -  static privacy-screen lookup list
> entry
> + *
> + * Used for the static lookup-list for mapping privacy-screen consumer
> + * dev-connector pairs to a privacy-screen provider.
> + */
> +struct drm_privacy_screen_lookup {
> +   /** @list: Lookup list list-entry. */
> +   struct list_head list;
> +   /** @dev_id: Consumer device name or NULL to match all devices. */
> +   const char *dev_id;
> +   /** @con_id: Consumer connector name or NULL to match all
> connectors. */

I think this patch mostly looks good, the one part that I'm a little confused
on here is the con_id. Perhaps I missed this when looking over this patch, but
what "connector name" are we referring to here - the DRM connector name (e.g.
eDP-1), or something else? The reason I ask is because I wonder if connector
names are really the way that we want to be looking DRM connectors up, since I
believe it's possible for two different GPUs to have DRM connectors with the
same name.

> +   const char *con_id;
> +   /** @provider: dev_name() of the privacy_screen provider. */
> +   const char *provider;
> +};
> +
> +void drm_privacy_screen_lookup_add(struct drm_privacy_screen_lookup
> *lookup);
> +void drm_privacy_screen_lookup_remove(struct drm_privacy_screen_lookup
> *lookup);
> +
> +static inline void drm_privacy_screen_lookup_init(void)
> +{
> +}
> +static inline void drm_privacy_screen_lookup_exit(void)
> +{
> +}
> +
> +#endif

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

Re: [Intel-gfx] [PATCH 1/9] drm/connector: Add support for privacy-screen properties (v4)

[Lyude Paul]

ate_property)
> +   return;
> +
> +   drm_object_attach_property(>base,
> +  connector-
> >privacy_screen_sw_state_property,
> +  PRIVACY_SCREEN_DISABLED);
> +
> +   drm_object_attach_property(>base,
> +  connector-
> >privacy_screen_hw_state_property,
> +  PRIVACY_SCREEN_DISABLED);
> +}
> +EXPORT_SYMBOL(drm_connector_attach_privacy_screen_properties);
> +
>  int drm_connector_set_obj_prop(struct drm_mode_object *obj,
>     struct drm_property *property,
>     uint64_t value)
> diff --git a/include/drm/drm_connector.h b/include/drm/drm_connector.h
> index 79fa34e5ccdb..1acbcf0626ce 100644
> --- a/include/drm/drm_connector.h
> +++ b/include/drm/drm_connector.h
> @@ -320,6 +320,30 @@ struct drm_monitor_range_info {
> u8 max_vfreq;
>  };
>  
> +/**
> + * enum drm_privacy_screen_status - privacy screen status
> + *
> + * This enum is used to track and control the state of the integrated
> privacy
> + * screen present on some display panels, via the "privacy-screen sw-state"
> + * and "privacy-screen hw-state" properties. Note the _LOCKED enum values
> + * are only valid for the "privacy-screen hw-state" property.
> + *
> + * @PRIVACY_SCREEN_DISABLED:
> + *  The privacy-screen on the panel is disabled
> + * @PRIVACY_SCREEN_ENABLED:
> + *  The privacy-screen on the panel is enabled
> + * @PRIVACY_SCREEN_DISABLED_LOCKED:
> + *  The privacy-screen on the panel is disabled and locked (cannot be
> changed)
> + * @PRIVACY_SCREEN_ENABLED_LOCKED:
> + *  The privacy-screen on the panel is enabled and locked (cannot be
> changed)
> + */
> +enum drm_privacy_screen_status {
> +   PRIVACY_SCREEN_DISABLED = 0,
> +   PRIVACY_SCREEN_ENABLED,
> +   PRIVACY_SCREEN_DISABLED_LOCKED,
> +   PRIVACY_SCREEN_ENABLED_LOCKED,
> +};
> +
>  /*
>   * This is a consolidated colorimetry list supported by HDMI and
>   * DP protocol standard. The respective connectors will register
> @@ -781,6 +805,12 @@ struct drm_connector_state {
>  */
> u8 max_bpc;
>  
> +   /**
> +    * @privacy_screen_sw_state: See :ref:`Standard Connector
> +    * Properties`
> +    */

So THAT'S how you reference other sections. I've always wondered!

> +   enum drm_privacy_screen_status privacy_screen_sw_state;
> +
> /**
>  * @hdr_output_metadata:
>  * DRM blob property for HDR output metadata
> @@ -1409,6 +1439,18 @@ struct drm_connector {
>      */
> struct drm_property *max_bpc_property;
>  
> +   /**
> +    * @privacy_screen_sw_state_property: Optional atomic property for
> the
> +    * connector to control the integrated privacy screen.
> +    */
> +   struct drm_property *privacy_screen_sw_state_property;
> +
> +   /**
> +    * @privacy_screen_hw_state_property: Optional atomic property for
> the
> +    * connector to report the actual integrated privacy screen state.
> +    */
> +   struct drm_property *privacy_screen_hw_state_property;
> +
>  #define DRM_CONNECTOR_POLL_HPD (1 << 0)
>  #define DRM_CONNECTOR_POLL_CONNECT (1 << 1)
>  #define DRM_CONNECTOR_POLL_DISCONNECT (1 << 2)
> @@ -1732,6 +1774,8 @@ int drm_connector_set_panel_orientation_with_quirk(
> int width, int height);
>  int drm_connector_attach_max_bpc_property(struct drm_connector *connector,
>   int min, int max);
> +void drm_connector_create_privacy_screen_properties(struct drm_connector
> *conn);
> +void drm_connector_attach_privacy_screen_properties(struct drm_connector
> *conn);
>  
>  /**
>   * struct drm_tile_group - Tile group metadata

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

Re: [Intel-gfx] [PATCH] drm/i915/dp: add a delay before setting panel brightness after power on

[Lyude Paul]

On Tue, 2021-09-14 at 12:09 +0300, Jani Nikula wrote:
> On Mon, 13 Sep 2021, Vasily Khoruzhick  wrote:
> > Panel in my Dell XPS 7590, that uses Intel's HDR backlight interface to
> > control brightness, apparently needs a delay before setting brightness
> > after power on. Without this delay the panel does accept the setting
> > and may come up with some arbitrary brightness (sometimes it's too dark,
> > sometimes it's too bright, I wasn't able to find a system).
> > 
> > I don't have access to the spec, so I'm not sure if it's expected
> > behavior or a quirk for particular device.
> > 
> > Delay was chosen by experiment: it works with 100ms, but fails with
> > anything lower than 75ms.
> 
> Looks like we don't respect the panel delays for DPCD backlight. The
> values are used for setting up the panel power sequencer, and thus PWM
> based backlight, but we should probably use the delays in DPCD backlight
> code too.

This makes sense to me, you're referring to the panel delays in the VBT
correct?

> 
> BR,
> Jani.
> 
> 
> > 
> > Signed-off-by: Vasily Khoruzhick 
> > ---
> >  drivers/gpu/drm/i915/display/intel_dp_aux_backlight.c | 4 
> >  1 file changed, 4 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 4f8337c7fd2e..c4f35e1b5870 100644
> > --- a/drivers/gpu/drm/i915/display/intel_dp_aux_backlight.c
> > +++ b/drivers/gpu/drm/i915/display/intel_dp_aux_backlight.c
> > @@ -210,6 +210,10 @@ intel_dp_aux_hdr_enable_backlight(const struct
> > intel_crtc_state *crtc_state,
> >  
> > ctrl = old_ctrl;
> > if (panel->backlight.edp.intel.sdr_uses_aux) {
> > +   /* Wait 100ms to ensure that panel is ready otherwise it
> > may not
> > +    * set chosen backlight level
> > +    */
> > +   msleep(100);
> > ctrl |= INTEL_EDP_HDR_TCON_BRIGHTNESS_AUX_ENABLE;
> > intel_dp_aux_hdr_set_aux_backlight(conn_state, level);
> > } else {
> 

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

Re: [Intel-gfx] [PATCH v3 02/13] drm/dp: use more of the extended receiver cap

[Lyude Paul]

…whoops, that was supposed to be:

Reviewed-by: Lyude Paul 

On Thu, 2021-09-09 at 12:18 -0400, Lyude Paul wrote:
> I thought I remembered an issue with this but looked up the previous emails,
> and it looks like that this change actually should be safe!
> 
> Signed-off-by: Lyude Paul 
> 
> On Thu, 2021-09-09 at 15:51 +0300, Jani Nikula wrote:
> > Extend the use of extended receiver cap at 0x2200 to cover
> > MAIN_LINK_CHANNEL_CODING_CAP in 0x2206, in case an implementation hides
> > the DP 2.0 128b/132b channel encoding cap.
> > 
> > v2: Extend to DP_RECEIVER_CAP_SIZE (Ville)
> > 
> > Cc: Lyude Paul 
> > Cc: dri-de...@lists.freedesktop.org
> > Cc: Manasi Navare 
> > Cc: Ville Syrjälä 
> > Signed-off-by: Jani Nikula 
> > ---
> >  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 9b2a2961fca8..2e74b02ed96b 100644
> > --- a/drivers/gpu/drm/drm_dp_helper.c
> > +++ b/drivers/gpu/drm/drm_dp_helper.c
> > @@ -608,7 +608,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];
> > int ret;
> >  
> > /*
> 

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

Re: [Intel-gfx] [PATCH v3 02/13] drm/dp: use more of the extended receiver cap

[Lyude Paul]

I thought I remembered an issue with this but looked up the previous emails,
and it looks like that this change actually should be safe!

Signed-off-by: Lyude Paul 

On Thu, 2021-09-09 at 15:51 +0300, Jani Nikula wrote:
> Extend the use of extended receiver cap at 0x2200 to cover
> MAIN_LINK_CHANNEL_CODING_CAP in 0x2206, in case an implementation hides
> the DP 2.0 128b/132b channel encoding cap.
> 
> v2: Extend to DP_RECEIVER_CAP_SIZE (Ville)
> 
> Cc: Lyude Paul 
> Cc: dri-de...@lists.freedesktop.org
> Cc: Manasi Navare 
> Cc: Ville Syrjälä 
> Signed-off-by: Jani Nikula 
> ---
>  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 9b2a2961fca8..2e74b02ed96b 100644
> --- a/drivers/gpu/drm/drm_dp_helper.c
> +++ b/drivers/gpu/drm/drm_dp_helper.c
> @@ -608,7 +608,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];
> int ret;
>  
> /*

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

Re: [Intel-gfx] [PATCH 2/4] drm/dp: use more of the extended receiver cap

[Lyude Paul]

On Thu, 2021-08-26 at 14:11 +0300, Jani Nikula wrote:
> On Wed, 25 Aug 2021, Jani Nikula  wrote:
> > On Thu, 19 Aug 2021, Ville Syrjälä  wrote:
> > > On Fri, Aug 13, 2021 at 01:43:20PM +0300, Jani Nikula wrote:
> > > > Extend the use of extended receiver cap at 0x2200 to cover
> > > > MAIN_LINK_CHANNEL_CODING_CAP in 0x2206, in case an implementation
> > > > hides
> > > > the DP 2.0 128b/132b channel encoding cap.
> > > > 
> > > > Cc: Manasi Navare 
> > > > Signed-off-by: Jani Nikula 
> > > > ---
> > > >  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 9b2a2961fca8..9389f92cb944 100644
> > > > --- a/drivers/gpu/drm/drm_dp_helper.c
> > > > +++ b/drivers/gpu/drm/drm_dp_helper.c
> > > > @@ -608,7 +608,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_MAIN_LINK_CHANNEL_CODING + 1];
> > > 
> > > Why are we even reading less of this than the normal receiver caps?
> > 
> > Good question. I forget my reasoning to only extend to what might affect
> > this use case. Should we extend to the size of the usual receiver caps?
> 
> Ah, there was a previous discussion [1] with Lyude (Cc'd).

Yeah - basically the problem is that we just need to make sure we take care to
avoid clearing info from the non-extended DPCD by accident. Extending this to
7 bits should be fine.

JFYI reading back at your comments it sounds like we might actually be safe to
read the entire DPCD, but we need to make sure we take care to avoid
accidentally replacing the main DPCD with a zeroed-out DPCD which could happen
on systems that have no support for extended DPCDs.

(Also - super bonus points if you can write a unit test to confirm we're not
overwriting the original DPCD! I don't know how much effort this would be
though so don't worry about it too much)

> 
> BR,
> Jani.
> 
> 
> [1]
> https://patchwork.freedesktop.org/patch/msgid/20200901123226.4177-1-jani.nik...@intel.com
> 
> 
> > 
> > BR,
> > Jani.
> > 
> > 
> > > 
> > > > int ret;
> > > >  
> > > > /*
> > > > -- 
> > > > 2.20.1
> 

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

Re: [Intel-gfx] [PATCH 0/3] drm/i915: better backlight & panel abstractions

[Lyude Paul]

Reviewed-by: Lyude Paul  (assuming this still applies)

As I mentioned on IRC pretty much all of the DPCD backlight helpers already
made it upstream. There are some changes I'm working on right now for VESA
backlights that use PWM for controlling the brightness level (so we can
hopefully fix https://gitlab.freedesktop.org/drm/intel/-/issues/3680 ,
otherwise I've gotta do some more poking with the backlight folks from Intel I
got in touch with), but I have no problem with rebasing this when the time
comes.

On Wed, 2021-08-25 at 14:06 +0300, Jani Nikula wrote:
> Extract the backlight code out of intel_panel.c, and rename the panel
> and backlight functions according to usual conventions.
> 
> Lyude, I haven't seen follow-ups on the DPCD backlight stuff you've
> worked on. Is it okay to merge this (and inevitably cause you conflicts)
> or shall I wait more?
> 
> BR,
> Jani.
> 
> 
> Cc: Lyude Paul 
> 
> Jani Nikula (3):
>   drm/i915/backlight: extract backlight code to a separate file
>   drm/i915/backlight: mass rename functions to have intel_backlight_
>     prefix
>   drm/i915/panel: mass rename functions to have intel_panel_ prefix
> 
>  drivers/gpu/drm/i915/Makefile |    1 +
>  drivers/gpu/drm/i915/display/g4x_dp.c |    4 +-
>  drivers/gpu/drm/i915/display/icl_dsi.c    |   13 +-
>  .../gpu/drm/i915/display/intel_backlight.c    | 1776 
>  .../gpu/drm/i915/display/intel_backlight.h    |   52 +
>  .../gpu/drm/i915/display/intel_connector.c    |    4 +-
>  drivers/gpu/drm/i915/display/intel_ddi.c  |    4 +-
>  drivers/gpu/drm/i915/display/intel_dp.c   |   16 +-
>  .../drm/i915/display/intel_dp_aux_backlight.c |   12 +-
>  drivers/gpu/drm/i915/display/intel_dvo.c  |    2 +-
>  drivers/gpu/drm/i915/display/intel_hdmi.c |    2 +-
>  drivers/gpu/drm/i915/display/intel_lvds.c |   18 +-
>  drivers/gpu/drm/i915/display/intel_opregion.c |    5 +-
>  drivers/gpu/drm/i915/display/intel_panel.c    | 1786 +
>  drivers/gpu/drm/i915/display/intel_panel.h    |   42 +-
>  drivers/gpu/drm/i915/display/vlv_dsi.c    |   16 +-
>  16 files changed, 1895 insertions(+), 1858 deletions(-)
>  create mode 100644 drivers/gpu/drm/i915/display/intel_backlight.c
>  create mode 100644 drivers/gpu/drm/i915/display/intel_backlight.h
> 

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

Re: [Intel-gfx] [PATCH 0/8] drm + usb-type-c: Add support for out-of-band hotplug notification (v4 resend)

[Lyude Paul]

This looks great to me! Wasn't much to comment on here as most of this looks
fine to me. For the whole series:

Reviewed-by: Lyude Paul 

This will be quite interesting to try getting working for nouveau

On Tue, 2021-08-17 at 23:51 +0200, Hans de Goede wrote:
> Hi all,
> 
> Here is a rebased-resend of v4 of my patchset making DP over Type-C work on
> devices where the Type-C controller does not drive the HPD pin on the GPU,
> but instead we need to forward HPD events from the Type-C controller to
> the DRM driver.
> 
> Changes in v4 resend:
> - Rebase on top of latest drm-tip
> 
> Changes in v4:
> - Rebase on top of latest drm-tip
> - Add forward declaration for struct fwnode_handle to drm_crtc_internal.h
>   (fixes warning reported by kernel test robot )
> - Add Heikki's Reviewed-by to patch 7 & 8
> - Add Heikki's Tested-by to the series
> 
> Changes in v3:
> - Base on top of latest drm-tip, which should fix the CI being unable to
>   apply (and thus to test) the patches
> - Make intel_acpi_assign_connector_fwnodes() take a ref on the fwnode
>   it stores in connector->fwnode and have drm_connector_cleanup() put
>   this reference
> - Drop data argument from drm_connector_oob_hotplug_event()
> - Make the Type-C DP altmode code only call
> drm_connector_oob_hotplug_event()
>   when the HPD bit in the status vdo changes
> - Drop the platform/x86/intel_cht_int33fe: Correct "displayport" fwnode
>   reference patch, this will be merged independently through the pdx86 tree
> 
> Changes in v2:
> - Replace the bogus "drm/connector: Make the drm_sysfs connector->kdev
>   device hold a reference to the connector" patch with:
>   "drm/connector: Give connector sysfs devices there own device_type"
>   the new patch is a dep for patch 2/9 see the patches
> 
> - Stop using a class-dev-iter, instead at a global connector list
>   to drm_connector.c and use that to find the connector by the fwnode,
>   similar to how we already do this in drm_panel.c and drm_bridge.c
> 
> - Make drm_connector_oob_hotplug_event() take a fwnode pointer as
>   argument, rather then a drm_connector pointer and let it do the
>   lookup itself. This allows making drm_connector_find_by_fwnode() a
>   drm-internal function and avoids code outside the drm subsystem
>   potentially holding on the a drm_connector reference for a longer
>   period.
> 
> This series not only touches drm subsys files but it also touches
> drivers/usb/typec/altmodes/typec_displayport.c, that file usually
> does not see a whole lot of changes. So I believe it would be best
> to just merge the entire series through drm-misc, Assuming we can
> get an ack from Greg for merging the typec_displayport.c changes
> this way.
> 
> Regards,
> 
> Hans
> 
> Hans de Goede (7):
>   drm/connector: Give connector sysfs devices there own device_type
>   drm/connector: Add a fwnode pointer to drm_connector and register with
>     ACPI (v2)
>   drm/connector: Add drm_connector_find_by_fwnode() function (v3)
>   drm/connector: Add support for out-of-band hotplug notification (v3)
>   drm/i915/dp: Add support for out-of-bound hotplug events
>   usb: typec: altmodes/displayport: Make dp_altmode_notify() more
>     generic
>   usb: typec: altmodes/displayport: Notify drm subsys of hotplug events
> 
> Heikki Krogerus (1):
>   drm/i915: Associate ACPI connector nodes with connector entries (v2)
> 
>  drivers/gpu/drm/drm_connector.c  | 79 ++
>  drivers/gpu/drm/drm_crtc_internal.h  |  2 +
>  drivers/gpu/drm/drm_sysfs.c  | 87 +---
>  drivers/gpu/drm/i915/display/intel_acpi.c    | 46 +++
>  drivers/gpu/drm/i915/display/intel_acpi.h    |  3 +
>  drivers/gpu/drm/i915/display/intel_display.c |  1 +
>  drivers/gpu/drm/i915/display/intel_dp.c      | 12 +++
>  drivers/usb/typec/altmodes/Kconfig   |  1 +
>  drivers/usb/typec/altmodes/displayport.c | 58 -
>  include/drm/drm_connector.h  | 25 ++
>  10 files changed, 279 insertions(+), 35 deletions(-)
> 

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

Re: [Intel-gfx] [PATCH 1/8] drm/connector: Give connector sysfs devices there own device_type

[Lyude Paul]

On Tue, 2021-08-17 at 23:51 +0200, Hans de Goede wrote:
> Give connector sysfs devices there own device_type, this allows us to
> check if a device passed to functions dealing with generic devices is
> a drm_connector or not.
> 
> A check like this is necessary in the drm_connector_acpi_bus_match()
> function added in the next patch in this series.
> 
> Tested-by: Heikki Krogerus 
> Signed-off-by: Hans de Goede 
> ---
>  drivers/gpu/drm/drm_sysfs.c | 50 +++--
>  1 file changed, 37 insertions(+), 13 deletions(-)
> 
> diff --git a/drivers/gpu/drm/drm_sysfs.c b/drivers/gpu/drm/drm_sysfs.c
> index 968a9560b4aa..f9d92bbb1f98 100644
> --- a/drivers/gpu/drm/drm_sysfs.c
> +++ b/drivers/gpu/drm/drm_sysfs.c
> @@ -50,6 +50,10 @@ static struct device_type drm_sysfs_device_minor = {
> .name = "drm_minor"
>  };
>  
> +static struct device_type drm_sysfs_device_connector = {
> +   .name = "drm_connector",
> +};
> +
>  struct class *drm_class;
>  
>  static char *drm_devnode(struct device *dev, umode_t *mode)
> @@ -102,6 +106,11 @@ void drm_sysfs_destroy(void)
> drm_class = NULL;
>  }
>  
> +static void drm_sysfs_release(struct device *dev)
> +{
> +   kfree(dev);
> +}
> +
>  /*
>   * Connector properties
>   */
> @@ -273,27 +282,47 @@ static const struct attribute_group
> *connector_dev_groups[] = {
>  int drm_sysfs_connector_add(struct drm_connector *connector)
>  {
> struct drm_device *dev = connector->dev;
> +   struct device *kdev;
> +   int r;
>  
> if (connector->kdev)
> return 0;
>  
> -   connector->kdev =
> -   device_create_with_groups(drm_class, dev->primary->kdev, 0,
> - connector, connector_dev_groups,
> - "card%d-%s", dev->primary->index,
> - connector->name);
> +   kdev = kzalloc(sizeof(*kdev), GFP_KERNEL);
> +   if (!kdev)
> +   return -ENOMEM;
> +
> +   device_initialize(kdev);
> +   kdev->class = drm_class;
> +   kdev->type = _sysfs_device_connector;
> +   kdev->parent = dev->primary->kdev;
> +   kdev->groups = connector_dev_groups;
> +   kdev->release = drm_sysfs_release;
> +   dev_set_drvdata(kdev, connector);
> +
> +   r = dev_set_name(kdev, "card%d-%s", dev->primary->index, connector-
> >name);
> +   if (r)
> +   goto err_free;
> +
> DRM_DEBUG("adding \"%s\" to sysfs\n",
>   connector->name);
>  
> -   if (IS_ERR(connector->kdev)) {
> -   DRM_ERROR("failed to register connector device: %ld\n",
> PTR_ERR(connector->kdev));
> -   return PTR_ERR(connector->kdev);
> +   r = device_add(kdev);
> +   if (r) {
> +   DRM_ERROR("failed to register connector device: %d\n", r);
> +   goto err_free;

Should probably be using drm_err() here since we have access to struct
drm_device *

> }
>  
> +   connector->kdev = kdev;
> +
> if (connector->ddc)
> return sysfs_create_link(>kdev->kobj,
>  >ddc->dev.kobj, "ddc");
> return 0;
> +
> +err_free:
> +   put_device(kdev);
> +   return r;
>  }
>  
>  void drm_sysfs_connector_remove(struct drm_connector *connector)
> @@ -374,11 +403,6 @@ void drm_sysfs_connector_status_event(struct
> drm_connector *connector,
>  }
>  EXPORT_SYMBOL(drm_sysfs_connector_status_event);
>  
> -static void drm_sysfs_release(struct device *dev)
> -{
> -   kfree(dev);
> -}
> -
>  struct device *drm_sysfs_minor_alloc(struct drm_minor *minor)
>  {
> const char *minor_str;

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

Re: [Intel-gfx] [PATCH] drm/dp_mst: Add missing drm parameters to recently added call to drm_dbg_kms()

[Lyude Paul]

It's no problem! We all make mistakes sometimes :), I should have been more
diligent on compile-checking this myself as well

On Thu, 2021-06-17 at 08:20 +, Lin, Wayne wrote:
> [Public]
> 
> Really sorry for the mistake that I made and any inconvenience it brought.
> Thanks José and Lyude.
> 
> Regards,
> Wayne
> 
> ____
> > From: Lyude Paul 
> > Sent: Thursday, June 17, 2021 03:47
> > To: José Roberto de Souza; intel-gfx@lists.freedesktop.org
> > Cc: dri-de...@lists.freedesktop.org; Lin, Wayne
> > Subject: Re: [PATCH] drm/dp_mst: Add missing drm parameters to recently
> > added call to drm_dbg_kms()
> > 
> > Reviewed-by: Lyude Paul 
> > 
> > Will go ahead and push this to drm-misc-next-fixes, thanks
> > 
> > On Wed, 2021-06-16 at 12:44 -0700, José Roberto de Souza wrote:
> > > Commit 3769e4c0af5b ("drm/dp_mst: Avoid to mess up payload table by
> > > ports in stale topology") added to calls to drm_dbg_kms() but it
> > > missed the first parameter, the drm device breaking the build.
> > > 
> > > Fixes: 3769e4c0af5b ("drm/dp_mst: Avoid to mess up payload table by
> > > ports in
> > > stale topology")
> > > Cc: Wayne Lin 
> > > Cc: Lyude Paul 
> > > Cc: dri-de...@lists.freedesktop.org
> > > Signed-off-by: José Roberto de Souza 
> > > ---
> > >  drivers/gpu/drm/drm_dp_mst_topology.c | 7 +--
> > >  1 file changed, 5 insertions(+), 2 deletions(-)
> > > 
> > > diff --git a/drivers/gpu/drm/drm_dp_mst_topology.c
> > > b/drivers/gpu/drm/drm_dp_mst_topology.c
> > > index 9ac148efd9e43..ad0795afc21cf 100644
> > > --- a/drivers/gpu/drm/drm_dp_mst_topology.c
> > > +++ b/drivers/gpu/drm/drm_dp_mst_topology.c
> > > @@ -3389,7 +3389,9 @@ int drm_dp_update_payload_part1(struct
> > > drm_dp_mst_topology_mgr *mgr)
> > >     mutex_unlock(>lock);
> > > 
> > >     if (skip) {
> > > -   drm_dbg_kms("Virtual channel %d is not
> > > in
> > > current topology\n", i);
> > > +   drm_dbg_kms(mgr->dev,
> > > +   "Virtual channel %d is not
> > > in
> > > current topology\n",
> > > +   i);
> > >     continue;
> > >     }
> > >     /* Validated ports don't matter if we're
> > > releasing
> > > @@ -3404,7 +3406,8 @@ int drm_dp_update_payload_part1(struct
> > > drm_dp_mst_topology_mgr *mgr)
> > >     payload->start_slot =
> > > req_payload.start_slot;
> > >     continue;
> > >     } else {
> > > -   drm_dbg_kms("Fail:set
> > > payload to invalid sink");
> > > +   drm_dbg_kms(mgr->dev,
> > > +   "Fail:set
> > > payload to invalid sink");
> > >     mutex_unlock(
> > > > payload_lock);
> > >     return -EINVAL;
> > >     }
> > 
> > --
> > Cheers,
> >  Lyude Paul (she/her)
> >  Software Engineer at Red Hat
> 

-- 
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] [PULL] drm-misc-next-fixes

[Lyude Paul]

-
> > Short summary of fixes pull:
> > 
> >  * hyperv: advertise the correct formatmodifiers for its primary plane
> >  * dp_mst: VCPI fixes to make it work with StarTech hub
> > 
> > 
> > Pu Lehui (1):
> >   drm/hyperv: Fix unused const variable 'hyperv_modifiers'
> > 
> > Wayne Lin (2):
> >   drm/dp_mst: Do not set proposed vcpi directly
> >   drm/dp_mst: Avoid to mess up payload table by ports in stale topology
> > 
> >  drivers/gpu/drm/drm_dp_mst_topology.c   | 65 +-
> > ---
> >  drivers/gpu/drm/hyperv/hyperv_drm_modeset.c |  2 +-
> >  2 files changed, 40 insertions(+), 27 deletions(-)
> > 
> > --
> > Thomas Zimmermann
> > Graphics Driver Developer
> > SUSE Software Solutions Germany GmbH
> > Maxfeldstr. 5, 90409 Nürnberg, Germany
> > (HRB 36809, AG Nürnberg)
> > Geschäftsführer: Felix Imendörffer
> 

-- 
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_mst: Add missing drm parameters to recently added call to drm_dbg_kms()

[Lyude Paul]

Reviewed-by: Lyude Paul 

Will go ahead and push this to drm-misc-next-fixes, thanks

On Wed, 2021-06-16 at 12:44 -0700, José Roberto de Souza wrote:
> Commit 3769e4c0af5b ("drm/dp_mst: Avoid to mess up payload table by
> ports in stale topology") added to calls to drm_dbg_kms() but it
> missed the first parameter, the drm device breaking the build.
> 
> Fixes: 3769e4c0af5b ("drm/dp_mst: Avoid to mess up payload table by ports in
> stale topology")
> Cc: Wayne Lin 
> Cc: Lyude Paul 
> Cc: dri-de...@lists.freedesktop.org
> Signed-off-by: José Roberto de Souza 
> ---
>  drivers/gpu/drm/drm_dp_mst_topology.c | 7 +--
>  1 file changed, 5 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/gpu/drm/drm_dp_mst_topology.c
> b/drivers/gpu/drm/drm_dp_mst_topology.c
> index 9ac148efd9e43..ad0795afc21cf 100644
> --- a/drivers/gpu/drm/drm_dp_mst_topology.c
> +++ b/drivers/gpu/drm/drm_dp_mst_topology.c
> @@ -3389,7 +3389,9 @@ int drm_dp_update_payload_part1(struct
> drm_dp_mst_topology_mgr *mgr)
> mutex_unlock(>lock);
>  
> if (skip) {
> -   drm_dbg_kms("Virtual channel %d is not in
> current topology\n", i);
> +   drm_dbg_kms(mgr->dev,
> +   "Virtual channel %d is not in
> current topology\n",
> +   i);
> continue;
> }
> /* Validated ports don't matter if we're releasing
> @@ -3404,7 +3406,8 @@ int drm_dp_update_payload_part1(struct
> drm_dp_mst_topology_mgr *mgr)
> payload->start_slot =
> req_payload.start_slot;
> continue;
> } else {
> -   drm_dbg_kms("Fail:set
> payload to invalid sink");
> +   drm_dbg_kms(mgr->dev,
> +   "Fail:set
> payload to invalid sink");
>     mutex_unlock(
> >payload_lock);
> return -EINVAL;
> }

-- 
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 v6 6/9] drm/i915/dpcd_bl: Return early in vesa_calc_max_backlight if we can't read PWMGEN_BIT_COUNT

[Lyude Paul]

If we can't read DP_EDP_PWMGEN_BIT_COUNT in
intel_dp_aux_vesa_calc_max_backlight() but do have a valid PWM frequency
defined in the VBT, we'll keep going in the function until we inevitably
fail on reading DP_EDP_PWMGEN_BIT_COUNT_CAP_MIN. There's not much point in
doing this, so just return early.

Signed-off-by: Lyude Paul 
Reviewed-by: Rodrigo Vivi 
---
 drivers/gpu/drm/i915/display/intel_dp_aux_backlight.c | 9 ++---
 1 file changed, 6 insertions(+), 3 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 781c7cd98d75..bf8e4ed56847 100644
--- a/drivers/gpu/drm/i915/display/intel_dp_aux_backlight.c
+++ b/drivers/gpu/drm/i915/display/intel_dp_aux_backlight.c
@@ -449,11 +449,14 @@ static u32 intel_dp_aux_vesa_calc_max_backlight(struct 
intel_connector *connecto
int freq, fxp, fxp_min, fxp_max, fxp_actual, f = 1;
u8 pn, pn_min, pn_max;
 
-   if (drm_dp_dpcd_readb(_dp->aux, DP_EDP_PWMGEN_BIT_COUNT, ) == 
1) {
-   pn &= DP_EDP_PWMGEN_BIT_COUNT_MASK;
-   max_backlight = (1 << pn) - 1;
+   if (drm_dp_dpcd_readb(_dp->aux, DP_EDP_PWMGEN_BIT_COUNT, ) != 
1) {
+   drm_dbg_kms(>drm, "Failed to read pwmgen bit count 
cap\n");
+   return 0;
}
 
+   pn &= DP_EDP_PWMGEN_BIT_COUNT_MASK;
+   max_backlight = (1 << pn) - 1;
+
/* Find desired value of (F x P)
 * Note that, if F x P is out of supported range, the maximum value or
 * minimum value will applied automatically. So no need to check that.
-- 
2.31.1

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

[Intel-gfx] [PATCH v6 4/9] drm/i915/dpcd_bl: Cache some backlight capabilities in intel_panel.backlight

[Lyude Paul]

Since we're about to be moving this code into shared DRM helpers, we might
as well start to cache certain backlight capabilities that can be
determined from the EDP DPCD, and are likely to be relevant to the majority
of drivers using said helpers. The main purpose of this is just to prevent
every driver from having to check everything against the eDP DPCD using DP
macros, which makes the code slightly easier to read (especially since the
names of some of the eDP capabilities don't exactly match up with what we
actually need to use them for, like DP_EDP_BACKLIGHT_BRIGHTNESS_BYTE_COUNT
for instance).

Signed-off-by: Lyude Paul 
Reviewed-by: Rodrigo Vivi 
---
 .../drm/i915/display/intel_display_types.h|  2 ++
 .../drm/i915/display/intel_dp_aux_backlight.c | 29 ---
 2 files changed, 21 insertions(+), 10 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/intel_display_types.h 
b/drivers/gpu/drm/i915/display/intel_display_types.h
index 7054a37363fb..d4a57bce71b1 100644
--- a/drivers/gpu/drm/i915/display/intel_display_types.h
+++ b/drivers/gpu/drm/i915/display/intel_display_types.h
@@ -312,6 +312,8 @@ struct intel_panel {
struct {
u8 pwmgen_bit_count;
u8 pwm_freq_pre_divider;
+   bool lsb_reg_used;
+   bool aux_enable;
} vesa;
struct {
bool sdr_uses_aux;
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 1ab82933afb5..1d31c33f4867 100644
--- a/drivers/gpu/drm/i915/display/intel_dp_aux_backlight.c
+++ b/drivers/gpu/drm/i915/display/intel_dp_aux_backlight.c
@@ -270,13 +270,14 @@ intel_dp_aux_hdr_setup_backlight(struct intel_connector 
*connector, enum pipe pi
 }
 
 /* VESA backlight callbacks */
-static void set_vesa_backlight_enable(struct intel_dp *intel_dp, bool enable)
+static void set_vesa_backlight_enable(struct intel_connector *connector, bool 
enable)
 {
+   struct intel_dp *intel_dp = intel_attached_dp(connector);
struct drm_i915_private *i915 = dp_to_i915(intel_dp);
u8 reg_val = 0;
 
/* Early return when display use other mechanism to enable backlight. */
-   if (!(intel_dp->edp_dpcd[1] & DP_EDP_BACKLIGHT_AUX_ENABLE_CAP))
+   if (!connector->panel.backlight.edp.vesa.aux_enable)
return;
 
if (drm_dp_dpcd_readb(_dp->aux, DP_EDP_DISPLAY_CONTROL_REGISTER, 
_val) != 1) {
@@ -339,9 +340,11 @@ static u32 intel_dp_aux_vesa_get_backlight(struct 
intel_connector *connector, en
DP_EDP_BACKLIGHT_BRIGHTNESS_MSB);
return 0;
}
-   level = read_val[0];
-   if (intel_dp->edp_dpcd[2] & DP_EDP_BACKLIGHT_BRIGHTNESS_BYTE_COUNT)
+
+   if (connector->panel.backlight.edp.vesa.lsb_reg_used)
level = (read_val[0] << 8 | read_val[1]);
+   else
+   level = read_val[0];
 
return level;
 }
@@ -359,13 +362,14 @@ intel_dp_aux_vesa_set_backlight(const struct 
drm_connector_state *conn_state,
struct drm_i915_private *i915 = dp_to_i915(intel_dp);
u8 vals[2] = { 0x0 };
 
-   vals[0] = level;
-
/* Write the MSB and/or LSB */
-   if (intel_dp->edp_dpcd[2] & DP_EDP_BACKLIGHT_BRIGHTNESS_BYTE_COUNT) {
+   if (connector->panel.backlight.edp.vesa.lsb_reg_used) {
vals[0] = (level & 0xFF00) >> 8;
vals[1] = (level & 0xFF);
+   } else {
+   vals[0] = level;
}
+
if (drm_dp_dpcd_write(_dp->aux, DP_EDP_BACKLIGHT_BRIGHTNESS_MSB, 
vals,
  sizeof(vals)) != sizeof(vals)) {
drm_dbg_kms(>drm,
@@ -419,14 +423,13 @@ intel_dp_aux_vesa_enable_backlight(const struct 
intel_crtc_state *crtc_state,
}
 
intel_dp_aux_vesa_set_backlight(conn_state, level);
-   set_vesa_backlight_enable(intel_dp, true);
+   set_vesa_backlight_enable(connector, true);
 }
 
 static void intel_dp_aux_vesa_disable_backlight(const struct 
drm_connector_state *old_conn_state,
u32 level)
 {
-   
set_vesa_backlight_enable(enc_to_intel_dp(to_intel_encoder(old_conn_state->best_encoder)),
- false);
+   
set_vesa_backlight_enable(to_intel_connector(old_conn_state->connector), false);
 }
 
 /*
@@ -524,8 +527,14 @@ static u32 intel_dp_aux_vesa_calc_max_backlight(struct 
intel_connector *connecto
 static int intel_dp_aux_vesa_setup_backlight(struct intel_connector *connector,
 enum pipe pipe)
 {
+   struct intel_dp *intel_dp = intel_attached_dp(connector);
struct intel_panel *panel = >panel;
 
+   if (intel_dp->edp_dpcd[1] & DP_EDP_BAC