[PATCH v4 4/6] drm/i915/alpm: Add compute config for lobf

[Animesh Manna]

Link Off Between Active Frames, is a new feature for eDP
that allows the panel to go to lower power state after
transmission of data. This is a feature on top of ALPM, AS SDP.
Add compute config during atomic-check phase.

v1: RFC version.
v2: Add separate flag for auxless-alpm. [Jani]
v3:
- intel_dp->lobf_supported replaced with crtc_state->has_lobf. [Jouni]
- Add DISPLAY_VER() check. [Jouni]
- Modify function name of get_aux_less_status. [Jani]
v4: Add enum alpm_mode to hold the aux-wake/less capability.

Signed-off-by: Animesh Manna 
---
 drivers/gpu/drm/i915/display/intel_alpm.c | 58 +++
 drivers/gpu/drm/i915/display/intel_alpm.h |  5 ++
 .../drm/i915/display/intel_display_types.h| 11 
 drivers/gpu/drm/i915/display/intel_dp.c   |  4 ++
 4 files changed, 78 insertions(+)

diff --git a/drivers/gpu/drm/i915/display/intel_alpm.c 
b/drivers/gpu/drm/i915/display/intel_alpm.c
index ee6c2a959f09..5979eab1f2e0 100644
--- a/drivers/gpu/drm/i915/display/intel_alpm.c
+++ b/drivers/gpu/drm/i915/display/intel_alpm.c
@@ -11,6 +11,23 @@
 #include "intel_dp_aux.h"
 #include "intel_psr_regs.h"
 
+enum alpm_mode intel_alpm_get_capability(struct intel_dp *intel_dp)
+{
+   u8 alpm_caps = 0;
+
+   if (drm_dp_dpcd_readb(_dp->aux, DP_RECEIVER_ALPM_CAP,
+ _caps) != 1)
+   return ALPM_INVALID;
+
+   if (alpm_caps & DP_ALPM_CAP)
+   return ALPM_AUX_WAKE;
+
+   if (alpm_caps & DP_ALPM_AUX_LESS_CAP)
+   return ALPM_AUX_LESS;
+
+   return ALPM_NOT_SUPPORTED;
+}
+
 /*
  * See Bspec: 71632 for the table
  *
@@ -242,6 +259,47 @@ bool intel_alpm_compute_params(struct intel_dp *intel_dp,
return true;
 }
 
+void intel_alpm_compute_lobf_config(struct intel_dp *intel_dp,
+   struct intel_crtc_state *crtc_state,
+   struct drm_connector_state *conn_state)
+{
+   struct drm_i915_private *i915 = dp_to_i915(intel_dp);
+   struct drm_display_mode *adjusted_mode = _state->hw.adjusted_mode;
+   int waketime_in_lines, first_sdp_position;
+   int context_latency, guardband;
+
+   if (!intel_dp_is_edp(intel_dp))
+   return;
+
+   if (DISPLAY_VER(i915) < 20)
+   return;
+
+   if (!intel_dp_as_sdp_supported(intel_dp))
+   return;
+
+   if (crtc_state->has_psr)
+   return;
+
+   if (intel_dp->alpm_parameters.mode == ALPM_INVALID ||
+   intel_dp->alpm_parameters.mode == ALPM_NOT_SUPPORTED)
+   return;
+
+   if (!intel_alpm_compute_params(intel_dp, crtc_state))
+   return;
+
+   context_latency = adjusted_mode->crtc_vblank_start - 
adjusted_mode->crtc_vdisplay;
+   guardband = adjusted_mode->crtc_vtotal -
+   adjusted_mode->crtc_vdisplay - context_latency;
+   first_sdp_position = adjusted_mode->crtc_vtotal - 
adjusted_mode->crtc_vsync_start;
+   if (intel_dp->alpm_parameters.mode == ALPM_AUX_LESS)
+   waketime_in_lines = intel_dp->alpm_parameters.io_wake_lines;
+   else
+   waketime_in_lines = intel_dp->alpm_parameters.fast_wake_lines;
+
+   crtc_state->has_lobf = (context_latency + guardband) >
+   (first_sdp_position + waketime_in_lines);
+}
+
 static void lnl_alpm_configure(struct intel_dp *intel_dp)
 {
struct drm_i915_private *dev_priv = dp_to_i915(intel_dp);
diff --git a/drivers/gpu/drm/i915/display/intel_alpm.h 
b/drivers/gpu/drm/i915/display/intel_alpm.h
index c45d078e5a6b..80c8a66b34af 100644
--- a/drivers/gpu/drm/i915/display/intel_alpm.h
+++ b/drivers/gpu/drm/i915/display/intel_alpm.h
@@ -10,9 +10,14 @@
 
 struct intel_dp;
 struct intel_crtc_state;
+struct drm_connector_state;
 
+enum alpm_mode intel_alpm_get_capability(struct intel_dp *intel_dp);
 bool intel_alpm_compute_params(struct intel_dp *intel_dp,
   struct intel_crtc_state *crtc_state);
+void intel_alpm_compute_lobf_config(struct intel_dp *intel_dp,
+   struct intel_crtc_state *crtc_state,
+   struct drm_connector_state *conn_state);
 void intel_alpm_configure(struct intel_dp *intel_dp);
 
 #endif
diff --git a/drivers/gpu/drm/i915/display/intel_display_types.h 
b/drivers/gpu/drm/i915/display/intel_display_types.h
index e81fd71ce57b..79e9e543020b 100644
--- a/drivers/gpu/drm/i915/display/intel_display_types.h
+++ b/drivers/gpu/drm/i915/display/intel_display_types.h
@@ -1405,6 +1405,9 @@ struct intel_crtc_state {
 
/* for loading single buffered registers during vblank */
struct drm_vblank_work vblank_work;
+
+   /* LOBF flag */
+   bool has_lobf;
 };
 
 enum intel_pipe_crc_source {
@@ -1715,6 +1718,13 @@ struct intel_psr {
u8 entry_setup_frames;
 };
 
+enum alpm_mode {
+   ALPM_INVALID,
+   ALPM_AUX_WAKE,
+   ALPM_AUX_LESS,
+   ALPM_NOT_SUPPORTED
+};
+
 

[PATCH v4 6/6] drm/i915/alpm: Add debugfs for LOBF

[Animesh Manna]

For validation purpose add debugfs for LOBF.

v1: Initial version.
v2: Add aux-wake/less info along with lobf status. [Jouni]

Signed-off-by: Animesh Manna 
---
 drivers/gpu/drm/i915/display/intel_alpm.c | 49 +++
 drivers/gpu/drm/i915/display/intel_alpm.h |  2 +
 .../drm/i915/display/intel_display_debugfs.c  |  2 +
 3 files changed, 53 insertions(+)

diff --git a/drivers/gpu/drm/i915/display/intel_alpm.c 
b/drivers/gpu/drm/i915/display/intel_alpm.c
index c8eddc910cc5..b5b4c212de88 100644
--- a/drivers/gpu/drm/i915/display/intel_alpm.c
+++ b/drivers/gpu/drm/i915/display/intel_alpm.c
@@ -354,3 +354,52 @@ void intel_alpm_configure(struct intel_dp *intel_dp,
 {
lnl_alpm_configure(intel_dp, crtc_state);
 }
+
+static int i915_edp_lobf_info_show(struct seq_file *m, void *data)
+{
+   struct intel_connector *connector = m->private;
+   struct drm_i915_private *dev_priv = to_i915(connector->base.dev);
+   struct drm_crtc *crtc;
+   struct intel_crtc_state *crtc_state;
+   enum transcoder cpu_transcoder;
+   u32 alpm_ctl;
+   int ret;
+
+   ret = 
drm_modeset_lock_single_interruptible(_priv->drm.mode_config.connection_mutex);
+   if (ret)
+   return ret;
+
+   crtc = connector->base.state->crtc;
+   if (connector->base.status != connector_status_connected || !crtc) {
+   ret = -ENODEV;
+   goto out;
+   }
+
+   crtc_state = to_intel_crtc_state(crtc->state);
+   cpu_transcoder = crtc_state->cpu_transcoder;
+   alpm_ctl = intel_de_read(dev_priv, ALPM_CTL(dev_priv, cpu_transcoder));
+   seq_printf(m, "LOBF status: %s\n", str_enabled_disabled(alpm_ctl & 
ALPM_CTL_LOBF_ENABLE));
+   seq_printf(m, "Aux-wake alpm status: %s\n",
+  str_enabled_disabled(!(alpm_ctl & 
ALPM_CTL_ALPM_AUX_LESS_ENABLE)));
+   seq_printf(m, "Aux-less alpm status: %s\n",
+  str_enabled_disabled(alpm_ctl & 
ALPM_CTL_ALPM_AUX_LESS_ENABLE));
+out:
+   drm_modeset_unlock(_priv->drm.mode_config.connection_mutex);
+
+   return ret;
+}
+
+DEFINE_SHOW_ATTRIBUTE(i915_edp_lobf_info);
+
+void intel_alpm_lobf_debugfs_add(struct intel_connector *connector)
+{
+   struct drm_i915_private *i915 = to_i915(connector->base.dev);
+   struct dentry *root = connector->base.debugfs_entry;
+
+   if (DISPLAY_VER(i915) < 20 ||
+   connector->base.connector_type != DRM_MODE_CONNECTOR_eDP)
+   return;
+
+   debugfs_create_file("i915_edp_lobf_info", 0444, root,
+   connector, _edp_lobf_info_fops);
+}
diff --git a/drivers/gpu/drm/i915/display/intel_alpm.h 
b/drivers/gpu/drm/i915/display/intel_alpm.h
index c0c085c1e5b0..8e1e0bbd44a3 100644
--- a/drivers/gpu/drm/i915/display/intel_alpm.h
+++ b/drivers/gpu/drm/i915/display/intel_alpm.h
@@ -11,6 +11,7 @@
 struct intel_dp;
 struct intel_crtc_state;
 struct drm_connector_state;
+struct intel_connector;
 
 enum alpm_mode intel_alpm_get_capability(struct intel_dp *intel_dp);
 bool intel_alpm_compute_params(struct intel_dp *intel_dp,
@@ -20,4 +21,5 @@ void intel_alpm_compute_lobf_config(struct intel_dp *intel_dp,
struct drm_connector_state *conn_state);
 void intel_alpm_configure(struct intel_dp *intel_dp,
  const struct intel_crtc_state *crtc_state);
+void intel_alpm_lobf_debugfs_add(struct intel_connector *connector);
 #endif
diff --git a/drivers/gpu/drm/i915/display/intel_display_debugfs.c 
b/drivers/gpu/drm/i915/display/intel_display_debugfs.c
index 35f9f86ef70f..86d9900c40af 100644
--- a/drivers/gpu/drm/i915/display/intel_display_debugfs.c
+++ b/drivers/gpu/drm/i915/display/intel_display_debugfs.c
@@ -13,6 +13,7 @@
 #include "i915_debugfs.h"
 #include "i915_irq.h"
 #include "i915_reg.h"
+#include "intel_alpm.h"
 #include "intel_crtc.h"
 #include "intel_de.h"
 #include "intel_crtc_state_dump.h"
@@ -1515,6 +1516,7 @@ void intel_connector_debugfs_add(struct intel_connector 
*connector)
intel_drrs_connector_debugfs_add(connector);
intel_pps_connector_debugfs_add(connector);
intel_psr_connector_debugfs_add(connector);
+   intel_alpm_lobf_debugfs_add(connector);
 
if (connector_type == DRM_MODE_CONNECTOR_DisplayPort ||
connector_type == DRM_MODE_CONNECTOR_HDMIA ||
-- 
2.29.0

[PATCH v4 5/6] drm/i915/alpm: Enable lobf from source in ALPM_CTL

[Animesh Manna]

Set the Link Off Between Frames Enable bit in ALPM_CTL register.

Note: Lobf need to be enabled adaptive sync fixed refresh mode
where vmin = vmax = flipline, which will arise after cmmr feature
enablement. Will add enabling sequence in a separate patch.

v1: Initial version.
v2: Condition check modified in alpm_configure(). [Jouni]

Signed-off-by: Animesh Manna 
---
 drivers/gpu/drm/i915/display/intel_alpm.c | 16 +++-
 drivers/gpu/drm/i915/display/intel_alpm.h |  4 ++--
 drivers/gpu/drm/i915/display/intel_psr.c  |  2 +-
 3 files changed, 14 insertions(+), 8 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/intel_alpm.c 
b/drivers/gpu/drm/i915/display/intel_alpm.c
index 5979eab1f2e0..c8eddc910cc5 100644
--- a/drivers/gpu/drm/i915/display/intel_alpm.c
+++ b/drivers/gpu/drm/i915/display/intel_alpm.c
@@ -300,10 +300,11 @@ void intel_alpm_compute_lobf_config(struct intel_dp 
*intel_dp,
(first_sdp_position + waketime_in_lines);
 }
 
-static void lnl_alpm_configure(struct intel_dp *intel_dp)
+static void lnl_alpm_configure(struct intel_dp *intel_dp,
+  const struct intel_crtc_state *crtc_state)
 {
struct drm_i915_private *dev_priv = dp_to_i915(intel_dp);
-   enum transcoder cpu_transcoder = intel_dp->psr.transcoder;
+   enum transcoder cpu_transcoder = crtc_state->cpu_transcoder;
u32 alpm_ctl;
 
if (DISPLAY_VER(dev_priv) < 20 || (!intel_dp->psr.psr2_enabled &&
@@ -314,7 +315,8 @@ static void lnl_alpm_configure(struct intel_dp *intel_dp)
 * Panel Replay on eDP is always using ALPM aux less. I.e. no need to
 * check panel support at this point.
 */
-   if (intel_dp->psr.panel_replay_enabled && intel_dp_is_edp(intel_dp)) {
+   if ((intel_dp->psr.panel_replay_enabled && intel_dp_is_edp(intel_dp)) ||
+   (crtc_state->has_lobf && intel_dp->alpm_parameters.mode == 
ALPM_AUX_LESS)) {
alpm_ctl = ALPM_CTL_ALPM_ENABLE |
ALPM_CTL_ALPM_AUX_LESS_ENABLE |
ALPM_CTL_AUX_LESS_SLEEP_HOLD_TIME_50_SYMBOLS;
@@ -339,12 +341,16 @@ static void lnl_alpm_configure(struct intel_dp *intel_dp)
   
ALPM_CTL_EXTENDED_FAST_WAKE_TIME(intel_dp->alpm_parameters.fast_wake_lines);
}
 
+   if (crtc_state->has_lobf)
+   alpm_ctl |= ALPM_CTL_LOBF_ENABLE;
+
alpm_ctl |= 
ALPM_CTL_ALPM_ENTRY_CHECK(intel_dp->alpm_parameters.check_entry_lines);
 
intel_de_write(dev_priv, ALPM_CTL(dev_priv, cpu_transcoder), alpm_ctl);
 }
 
-void intel_alpm_configure(struct intel_dp *intel_dp)
+void intel_alpm_configure(struct intel_dp *intel_dp,
+ const struct intel_crtc_state *crtc_state)
 {
-   lnl_alpm_configure(intel_dp);
+   lnl_alpm_configure(intel_dp, crtc_state);
 }
diff --git a/drivers/gpu/drm/i915/display/intel_alpm.h 
b/drivers/gpu/drm/i915/display/intel_alpm.h
index 80c8a66b34af..c0c085c1e5b0 100644
--- a/drivers/gpu/drm/i915/display/intel_alpm.h
+++ b/drivers/gpu/drm/i915/display/intel_alpm.h
@@ -18,6 +18,6 @@ bool intel_alpm_compute_params(struct intel_dp *intel_dp,
 void intel_alpm_compute_lobf_config(struct intel_dp *intel_dp,
struct intel_crtc_state *crtc_state,
struct drm_connector_state *conn_state);
-void intel_alpm_configure(struct intel_dp *intel_dp);
-
+void intel_alpm_configure(struct intel_dp *intel_dp,
+ const struct intel_crtc_state *crtc_state);
 #endif
diff --git a/drivers/gpu/drm/i915/display/intel_psr.c 
b/drivers/gpu/drm/i915/display/intel_psr.c
index 9e89844e6418..cd1afc82aefc 100644
--- a/drivers/gpu/drm/i915/display/intel_psr.c
+++ b/drivers/gpu/drm/i915/display/intel_psr.c
@@ -1620,7 +1620,7 @@ static void intel_psr_enable_source(struct intel_dp 
*intel_dp,
 IGNORE_PSR2_HW_TRACKING : 0);
 
if (intel_dp_is_edp(intel_dp))
-   intel_alpm_configure(intel_dp);
+   intel_alpm_configure(intel_dp, crtc_state);
 
/*
 * Wa_16013835468
-- 
2.29.0

[PATCH v4 3/6] drm/display: Add missing aux less alpm wake related bits

[Animesh Manna]

From: Jouni Högander 

eDP1.5 adds some more bits into DP_RECEIVER_ALPM_CAP and
DP_RECEIVER_ALPM_CONFIG registers. Add definitions for these.

Signed-off-by: Jouni Högander 
---
 include/drm/display/drm_dp.h | 5 -
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/include/drm/display/drm_dp.h b/include/drm/display/drm_dp.h
index 0b032faa8cf2..ad0cb0a1de87 100644
--- a/include/drm/display/drm_dp.h
+++ b/include/drm/display/drm_dp.h
@@ -232,6 +232,8 @@
 
 #define DP_RECEIVER_ALPM_CAP   0x02e   /* eDP 1.4 */
 # define DP_ALPM_CAP   (1 << 0)
+# define DP_ALPM_PM_STATE_2A_SUPPORT   (1 << 1) /* eDP 1.5 */
+# define DP_ALPM_AUX_LESS_CAP  (1 << 2) /* eDP 1.5 */
 
 #define DP_SINK_DEVICE_AUX_FRAME_SYNC_CAP   0x02f   /* eDP 1.4 */
 # define DP_AUX_FRAME_SYNC_CAP (1 << 0)
@@ -677,7 +679,8 @@
 
 #define DP_RECEIVER_ALPM_CONFIG0x116   /* eDP 1.4 */
 # define DP_ALPM_ENABLE(1 << 0)
-# define DP_ALPM_LOCK_ERROR_IRQ_HPD_ENABLE  (1 << 1)
+# define DP_ALPM_LOCK_ERROR_IRQ_HPD_ENABLE  (1 << 1) /* eDP 1.5 */
+# define DP_ALPM_MODE_AUX_LESS (1 << 2) /* eDP 1.5 */
 
 #define DP_SINK_DEVICE_AUX_FRAME_SYNC_CONF  0x117   /* eDP 1.4 */
 # define DP_AUX_FRAME_SYNC_ENABLE  (1 << 0)
-- 
2.29.0

[PATCH v4 2/6] drm/i915/alpm: Move alpm related code to a new file

[Animesh Manna]

Move ALPM feature related code as it will be used for
non-psr panel also thorugh LOBF feature.

v1: Initial version.
v2: Correct ordering in makefile. [Jani]

Signed-off-by: Animesh Manna 
---
 drivers/gpu/drm/i915/Makefile |   1 +
 drivers/gpu/drm/i915/display/intel_alpm.c | 292 ++
 drivers/gpu/drm/i915/display/intel_alpm.h |  18 ++
 drivers/gpu/drm/i915/display/intel_psr.c  | 282 +
 drivers/gpu/drm/xe/Makefile   |   1 +
 5 files changed, 315 insertions(+), 279 deletions(-)
 create mode 100644 drivers/gpu/drm/i915/display/intel_alpm.c
 create mode 100644 drivers/gpu/drm/i915/display/intel_alpm.h

diff --git a/drivers/gpu/drm/i915/Makefile b/drivers/gpu/drm/i915/Makefile
index 7cad944b825c..9a3f910ce4fd 100644
--- a/drivers/gpu/drm/i915/Makefile
+++ b/drivers/gpu/drm/i915/Makefile
@@ -243,6 +243,7 @@ i915-y += \
display/hsw_ips.o \
display/i9xx_plane.o \
display/i9xx_wm.o \
+   display/intel_alpm.o \
display/intel_atomic.o \
display/intel_atomic_plane.o \
display/intel_audio.o \
diff --git a/drivers/gpu/drm/i915/display/intel_alpm.c 
b/drivers/gpu/drm/i915/display/intel_alpm.c
new file mode 100644
index ..ee6c2a959f09
--- /dev/null
+++ b/drivers/gpu/drm/i915/display/intel_alpm.c
@@ -0,0 +1,292 @@
+// SPDX-License-Identifier: MIT
+/*
+ * Copyright 2024, Intel Corporation.
+ */
+
+#include "intel_alpm.h"
+#include "intel_crtc.h"
+#include "intel_de.h"
+#include "intel_display_types.h"
+#include "intel_dp.h"
+#include "intel_dp_aux.h"
+#include "intel_psr_regs.h"
+
+/*
+ * See Bspec: 71632 for the table
+ *
+ * Silence_period = tSilence,Min + ((tSilence,Max - tSilence,Min) / 2)
+ *
+ * Half cycle duration:
+ *
+ * Link rates 1.62 - 4.32 and tLFPS_Cycle = 70 ns
+ * FLOOR( (Link Rate * tLFPS_Cycle) / (2 * 10) )
+ *
+ * Link rates 5.4 - 8.1
+ * PORT_ALPM_LFPS_CTL[ LFPS Cycle Count ] = 10
+ * LFPS Period chosen is the mid-point of the min:max values from the table
+ * FLOOR( LFPS Period in Symbol clocks /
+ * (2 * PORT_ALPM_LFPS_CTL[ LFPS Cycle Count ]) )
+ */
+static bool _lnl_get_silence_period_and_lfps_half_cycle(int link_rate,
+   int *silence_period,
+   int *lfps_half_cycle)
+{
+   switch (link_rate) {
+   case 162000:
+   *silence_period = 20;
+   *lfps_half_cycle = 5;
+   break;
+   case 216000:
+   *silence_period = 27;
+   *lfps_half_cycle = 7;
+   break;
+   case 243000:
+   *silence_period = 31;
+   *lfps_half_cycle = 8;
+   break;
+   case 27:
+   *silence_period = 34;
+   *lfps_half_cycle = 9;
+   break;
+   case 324000:
+   *silence_period = 41;
+   *lfps_half_cycle = 11;
+   break;
+   case 432000:
+   *silence_period = 56;
+   *lfps_half_cycle = 15;
+   break;
+   case 54:
+   *silence_period = 69;
+   *lfps_half_cycle = 12;
+   break;
+   case 648000:
+   *silence_period = 84;
+   *lfps_half_cycle = 15;
+   break;
+   case 675000:
+   *silence_period = 87;
+   *lfps_half_cycle = 15;
+   break;
+   case 81:
+   *silence_period = 104;
+   *lfps_half_cycle = 19;
+   break;
+   default:
+   *silence_period = *lfps_half_cycle = -1;
+   return false;
+   }
+   return true;
+}
+
+/*
+ * AUX-Less Wake Time = CEILING( ((PHY P2 to P0) + tLFPS_Period, Max+
+ * tSilence, Max+ tPHY Establishment + tCDS) / tline)
+ * For the "PHY P2 to P0" latency see the PHY Power Control page
+ * (PHY P2 to P0) : https://gfxspecs.intel.com/Predator/Home/Index/68965
+ * : 12 us
+ * The tLFPS_Period, Max term is 800ns
+ * The tSilence, Max term is 180ns
+ * The tPHY Establishment (a.k.a. t1) term is 50us
+ * The tCDS term is 1 or 2 times t2
+ * t2 = Number ML_PHY_LOCK * tML_PHY_LOCK
+ * Number ML_PHY_LOCK = ( 7 + CEILING( 6.5us / tML_PHY_LOCK ) + 1)
+ * Rounding up the 6.5us padding to the next ML_PHY_LOCK boundary and
+ * adding the "+ 1" term ensures all ML_PHY_LOCK sequences that start
+ * within the CDS period complete within the CDS period regardless of
+ * entry into the period
+ * tML_PHY_LOCK = TPS4 Length * ( 10 / (Link Rate in MHz) )
+ * TPS4 Length = 252 Symbols
+ */
+static int _lnl_compute_aux_less_wake_time(int port_clock)
+{
+   int tphy2_p2_to_p0 = 12 * 1000;
+   int tlfps_period_max = 800;
+   int tsilence_max = 180;
+   int t1 = 50 * 1000;
+   int tps4 = 252;
+   int tml_phy_lock = 1000 * 1000 * tps4 * 10 / port_clock;
+   int num_ml_phy_lock = 7 + DIV_ROUND_UP(6500, tml_phy_lock) + 1;
+   int t2 = 

[PATCH v4 1/6] drm/i915/alpm: Move alpm parameters from intel_psr

[Animesh Manna]

ALPM can be enabled for non psr panel and currenly aplm-params are
encapsulated under intel_psr struct, so moving out to intel_dp struct.

Signed-off-by: Animesh Manna 
---
 .../drm/i915/display/intel_display_types.h| 21 +
 drivers/gpu/drm/i915/display/intel_psr.c  | 43 +--
 2 files changed, 31 insertions(+), 33 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/intel_display_types.h 
b/drivers/gpu/drm/i915/display/intel_display_types.h
index 00eba3fbcdc6..e81fd71ce57b 100644
--- a/drivers/gpu/drm/i915/display/intel_display_types.h
+++ b/drivers/gpu/drm/i915/display/intel_display_types.h
@@ -1700,17 +1700,6 @@ struct intel_psr {
bool psr2_sel_fetch_cff_enabled;
bool req_psr2_sdp_prior_scanline;
u8 sink_sync_latency;
-
-   struct {
-   u8 io_wake_lines;
-   u8 fast_wake_lines;
-
-   /* LNL and beyond */
-   u8 check_entry_lines;
-   u8 silence_period_sym_clocks;
-   u8 lfps_half_cycle_num_of_syms;
-   } alpm_parameters;
-
ktime_t last_entry_attempt;
ktime_t last_exit;
bool sink_not_reliable;
@@ -1840,6 +1829,16 @@ struct intel_dp {
unsigned long last_oui_write;
 
bool colorimetry_support;
+
+   struct {
+   u8 io_wake_lines;
+   u8 fast_wake_lines;
+
+   /* LNL and beyond */
+   u8 check_entry_lines;
+   u8 silence_period_sym_clocks;
+   u8 lfps_half_cycle_num_of_syms;
+   } alpm_parameters;
 };
 
 enum lspcon_vendor {
diff --git a/drivers/gpu/drm/i915/display/intel_psr.c 
b/drivers/gpu/drm/i915/display/intel_psr.c
index 595eb1b3b6c6..13c0f44f48b9 100644
--- a/drivers/gpu/drm/i915/display/intel_psr.c
+++ b/drivers/gpu/drm/i915/display/intel_psr.c
@@ -816,8 +816,8 @@ static u32 intel_psr2_get_tp_time(struct intel_dp *intel_dp)
 
 static int psr2_block_count_lines(struct intel_dp *intel_dp)
 {
-   return intel_dp->psr.alpm_parameters.io_wake_lines < 9 &&
-   intel_dp->psr.alpm_parameters.fast_wake_lines < 9 ? 8 : 12;
+   return intel_dp->alpm_parameters.io_wake_lines < 9 &&
+   intel_dp->alpm_parameters.fast_wake_lines < 9 ? 8 : 12;
 }
 
 static int psr2_block_count(struct intel_dp *intel_dp)
@@ -855,7 +855,6 @@ static void dg2_activate_panel_replay(struct intel_dp 
*intel_dp)
 static void hsw_activate_psr2(struct intel_dp *intel_dp)
 {
struct drm_i915_private *dev_priv = dp_to_i915(intel_dp);
-   struct intel_psr *psr = _dp->psr;
enum transcoder cpu_transcoder = intel_dp->psr.transcoder;
u32 val = EDP_PSR2_ENABLE;
u32 psr_val = 0;
@@ -897,18 +896,19 @@ static void hsw_activate_psr2(struct intel_dp *intel_dp)
 */
int tmp;
 
-   tmp = map[psr->alpm_parameters.io_wake_lines -
+   tmp = map[intel_dp->alpm_parameters.io_wake_lines -
  TGL_EDP_PSR2_IO_BUFFER_WAKE_MIN_LINES];
val |= TGL_EDP_PSR2_IO_BUFFER_WAKE(tmp + 
TGL_EDP_PSR2_IO_BUFFER_WAKE_MIN_LINES);
 
-   tmp = map[psr->alpm_parameters.fast_wake_lines - 
TGL_EDP_PSR2_FAST_WAKE_MIN_LINES];
+   tmp = map[intel_dp->alpm_parameters.fast_wake_lines -
+ TGL_EDP_PSR2_FAST_WAKE_MIN_LINES];
val |= TGL_EDP_PSR2_FAST_WAKE(tmp + 
TGL_EDP_PSR2_FAST_WAKE_MIN_LINES);
} else if (DISPLAY_VER(dev_priv) >= 12) {
-   val |= 
TGL_EDP_PSR2_IO_BUFFER_WAKE(psr->alpm_parameters.io_wake_lines);
-   val |= 
TGL_EDP_PSR2_FAST_WAKE(psr->alpm_parameters.fast_wake_lines);
+   val |= 
TGL_EDP_PSR2_IO_BUFFER_WAKE(intel_dp->alpm_parameters.io_wake_lines);
+   val |= 
TGL_EDP_PSR2_FAST_WAKE(intel_dp->alpm_parameters.fast_wake_lines);
} else if (DISPLAY_VER(dev_priv) >= 9) {
-   val |= 
EDP_PSR2_IO_BUFFER_WAKE(psr->alpm_parameters.io_wake_lines);
-   val |= EDP_PSR2_FAST_WAKE(psr->alpm_parameters.fast_wake_lines);
+   val |= 
EDP_PSR2_IO_BUFFER_WAKE(intel_dp->alpm_parameters.io_wake_lines);
+   val |= 
EDP_PSR2_FAST_WAKE(intel_dp->alpm_parameters.fast_wake_lines);
}
 
if (intel_dp->psr.req_psr2_sdp_prior_scanline)
@@ -1294,9 +1294,9 @@ static int _lnl_compute_aux_less_alpm_params(struct 
intel_dp *intel_dp,
if (i915->display.params.psr_safest_params)
aux_less_wake_lines = ALPM_CTL_AUX_LESS_WAKE_TIME_MASK;
 
-   intel_dp->psr.alpm_parameters.fast_wake_lines = aux_less_wake_lines;
-   intel_dp->psr.alpm_parameters.silence_period_sym_clocks = 
silence_period;
-   intel_dp->psr.alpm_parameters.lfps_half_cycle_num_of_syms = 
lfps_half_cycle;
+   intel_dp->alpm_parameters.fast_wake_lines = aux_less_wake_lines;
+   intel_dp->alpm_parameters.silence_period_sym_clocks = silence_period;
+   intel_dp->alpm_parameters.lfps_half_cycle_num_of_syms = 

[PATCH v4 0/6] Link off between frames for edp

[Animesh Manna]

Link Off Between Active Frames (LOBF) allows an eDP link to be turned Off and On
durning long VBLANK durations without enabling any of the PSR/PSR2/PR modes of 
operation.

Bspec: 71477

Note: Lobf need to be enabled adaptive sync fixed refresh mode
where vmin = vmax = flipline, which will arise after cmmr feature
enablement. Currently existing code refactored and make compute-config()
and enabling function ready. Will add enabling sequence in a separate patch.

Signed-off-by: Animesh Manna 

Animesh Manna (5):
  drm/i915/alpm: Move alpm parameters from intel_psr
  drm/i915/alpm: Move alpm related code to a new file
  drm/i915/alpm: Add compute config for lobf
  drm/i915/alpm: Enable lobf from source in ALPM_CTL
  drm/i915/alpm: Add debugfs for LOBF

Jouni Högander (1):
  drm/display: Add missing aux less alpm wake related bits

 drivers/gpu/drm/i915/Makefile |   1 +
 drivers/gpu/drm/i915/display/intel_alpm.c | 405 ++
 drivers/gpu/drm/i915/display/intel_alpm.h |  25 ++
 .../drm/i915/display/intel_display_debugfs.c  |   2 +
 .../drm/i915/display/intel_display_types.h|  32 +-
 drivers/gpu/drm/i915/display/intel_dp.c   |   4 +
 drivers/gpu/drm/i915/display/intel_psr.c  | 301 +
 drivers/gpu/drm/xe/Makefile   |   1 +
 include/drm/display/drm_dp.h  |   5 +-
 9 files changed, 475 insertions(+), 301 deletions(-)
 create mode 100644 drivers/gpu/drm/i915/display/intel_alpm.c
 create mode 100644 drivers/gpu/drm/i915/display/intel_alpm.h

-- 
2.29.0

Re: [PATCH v2 2/3] dt-bindings: arm: mediatek: mmsys: Add OF graph support for board path

[胡俊光]

Re: [PATCH] drm/xe: Fix UBSAN shift-out-of-bounds failure

[Lucas De Marchi]

On Tue, May 07, 2024 at 01:04:11PM GMT, Shuicheng Lin wrote:

Here is the failure stack:
[   12.988209] [ cut here ]
[   12.988216] UBSAN: shift-out-of-bounds in ./include/linux/log2.h:57:13
[   12.988232] shift exponent 64 is too large for 64-bit type 'long unsigned 
int'
[   12.988235] CPU: 4 PID: 1310 Comm: gnome-shell Tainted: G U 
6.9.0-rc6+prerelease1158+ #19
[   12.988237] Hardware name: Intel Corporation Raptor Lake Client 
Platform/RPL-S ADP-S DDR5 UDIMM CRB, BIOS RPLSFWI1.R00.3301.A02.2208050712 
08/05/2022
[   12.988239] Call Trace:
[   12.988240]  
[   12.988242]  dump_stack_lvl+0xd7/0xf0
[   12.988248]  dump_stack+0x10/0x20
[   12.988250]  ubsan_epilogue+0x9/0x40
[   12.988253]  __ubsan_handle_shift_out_of_bounds+0x10e/0x170
[   12.988260]  dma_resv_reserve_fences.cold+0x2b/0x48
[   12.988262]  ? ww_mutex_lock_interruptible+0x3c/0x110
[   12.988267]  drm_exec_prepare_obj+0x45/0x60 [drm_exec]
[   12.988271]  ? vm_bind_ioctl_ops_execute+0x5b/0x740 [xe]
[   12.988345]  vm_bind_ioctl_ops_execute+0x78/0x740 [xe]

It is caused by the value 0 of parameter num_fences in function 
drm_exec_prepare_obj.
And lead to in function __rounddown_pow_of_two, "0 - 1" causes the 
shift-out-of-bounds.


ok


For num_fences == 0 case, drm_exec_prepare_obj is the same as drm_exec_lock_obj 
in
function, so call drm_exec_lock_obj instead to solve it.


this is not true and per discussion in this thread it's not going to
change. drm_exec_prepare_obj() should not be called with num_fences ==
0. So I'd reworded with something like below so we have all breadcrumbs
for anyone trying to understand the changes later:

By design drm_exec_prepare_obj() should be called only when there are
fences to be reserved. If num_fences is 0, calling drm_exec_lock_obj()
is sufficient as was done in commit 9377de4cb3e8 ("drm/xe/vm: Avoid
reserving zero fences")



Cc: Nirmoy Das 
Cc: Matthew Brost 
Signed-off-by: Shuicheng Lin 


with the reword,

Reviewed-by: Lucas De Marchi 

And also add:
Link: https://lore.kernel.org/all/24d4a9a9-c622-4f56-8672-21f4c6785...@amd.com

Could you also submit a patch to add the warning like mentioned by
Christian?

thanks
Lucas De Marchi


---
drivers/gpu/drm/xe/xe_vm.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/xe/xe_vm.c b/drivers/gpu/drm/xe/xe_vm.c
index d17192c8b7de..c5b1694b292f 100644
--- a/drivers/gpu/drm/xe/xe_vm.c
+++ b/drivers/gpu/drm/xe/xe_vm.c
@@ -2692,7 +2692,7 @@ static int vma_lock_and_validate(struct drm_exec *exec, 
struct xe_vma *vma,

if (bo) {
if (!bo->vm)
-   err = drm_exec_prepare_obj(exec, >ttm.base, 0);
+   err = drm_exec_lock_obj(exec, >ttm.base);
if (!err && validate)
err = xe_bo_validate(bo, xe_vma_vm(vma), true);
}
@@ -2777,7 +2777,7 @@ static int vm_bind_ioctl_ops_lock_and_prep(struct 
drm_exec *exec,
struct xe_vma_op *op;
int err;

-   err = drm_exec_prepare_obj(exec, xe_vm_obj(vm), 0);
+   err = drm_exec_lock_obj(exec, xe_vm_obj(vm));
if (err)
return err;

--
2.25.1

Re: [PATCH] drm/msm: remove python 3.9 dependency for compiling msm

[Masahiro Yamada]

On Thu, May 9, 2024 at 9:28 AM Doug Anderson  wrote:
>
> Hi,
>
> On Tue, May 7, 2024 at 4:05 PM Abhinav Kumar  wrote:
> >
> > Since commit 5acf49119630 ("drm/msm: import gen_header.py script from 
> > Mesa"),
> > compilation is broken on machines having python versions older than 3.9
> > due to dependency on argparse.BooleanOptionalAction.
> >
> > Switch to use simple bool for the validate flag to remove the dependency.
> >
> > Fixes: 5acf49119630 ("drm/msm: import gen_header.py script from Mesa")
> > Signed-off-by: Abhinav Kumar 
> > ---
> >  drivers/gpu/drm/msm/registers/gen_header.py | 5 +++--
> >  1 file changed, 3 insertions(+), 2 deletions(-)
>
> No idea if we're supposed to allow python as a build dependency. That
> being said, I can confirm that this fixes the problem for me since I
> ran into it too [1].
>
> Tested-by: Douglas Anderson 
>
> [1] 
> https://lore.kernel.org/r/CAD=FV=XnpS-=cookkxzfm8og9wcsemxfesmftyh811438qg...@mail.gmail.com
>


I do not like Perl.

IMHO, Python should be OK if Perl is OK.
I agree that the required version should be
documented changes.rst, at least.






-- 
Best Regards
Masahiro Yamada

[PATCH v5 7/7] drm/panel: himax-hx83102: Support for IVO t109nw41 MIPI-DSI panel

[Cong Yang]

The IVO t109nw41 is a 11.0" WUXGA TFT LCD panel, use hx83102 controller
which fits in nicely with the existing panel-himax-hx83102 driver. Hence,
we add a new compatible with panel specific config.

Signed-off-by: Cong Yang 
---
Chage since V5:

- Adjust inital cmds indentation and check accum_err before calling mdelay in 
init().
- Adjust somes inital cmds to Optimize gamma.

V4: 
https://lore.kernel.org/all/20240507135234.1356855-8-yangco...@huaqin.corp-partner.google.com

Chage since V4:

- inital cmds use lowercasehex.

V3: 
https://lore.kernel.org/all/20240424023010.2099949-8-yangco...@huaqin.corp-partner.google.com

Chage since V3:

- Depend Dous'series [1].
[1]: https://lore.kernel.org/all/20240501154251.3302887-1-diand...@chromium.org

V2: 
https://lore.kernel.org/all/20240422090310.3311429-8-yangco...@huaqin.corp-partner.google.com

---
 drivers/gpu/drm/panel/panel-himax-hx83102.c | 131 
 1 file changed, 131 insertions(+)

diff --git a/drivers/gpu/drm/panel/panel-himax-hx83102.c 
b/drivers/gpu/drm/panel/panel-himax-hx83102.c
index f1273e1c92d2..03a82e48da11 100644
--- a/drivers/gpu/drm/panel/panel-himax-hx83102.c
+++ b/drivers/gpu/drm/panel/panel-himax-hx83102.c
@@ -293,6 +293,112 @@ static int boe_nv110wum_init(struct hx83102 *ctx)
return 0;
 };
 
+static int ivo_t109nw41_init(struct hx83102 *ctx)
+{
+   struct mipi_dsi_multi_context dsi_ctx = { .dsi = ctx->dsi };
+
+   msleep(60);
+
+   hx83102_enable_extended_cmds(_ctx, true);
+   mipi_dsi_dcs_write_seq_multi(_ctx, HX83102_SETPOWER, 0x2c, 0xed, 
0xed, 0x0f, 0xcf, 0x42,
+0xf5, 0x39, 0x36, 0x36, 0x36, 0x36, 0x32, 
0x8b, 0x11, 0x65, 0x00, 0x88,
+0xfa, 0xff, 0xff, 0x8f, 0xff, 0x08, 0xd6, 
0x33);
+   mipi_dsi_dcs_write_seq_multi(_ctx, HX83102_SETDISP, 0x00, 0x47, 
0xb0, 0x80, 0x00, 0x12,
+0x71, 0x3c, 0xa3, 0x22, 0x20, 0x00, 0x00, 
0x88, 0x01);
+   mipi_dsi_dcs_write_seq_multi(_ctx, HX83102_SETCYC, 0x35, 0x35, 
0x43, 0x43, 0x35, 0x35,
+0x30, 0x7a, 0x30, 0x7a, 0x01, 0x9d);
+   mipi_dsi_dcs_write_seq_multi(_ctx, HX83102_SETSPCCMD, 0xcd);
+   mipi_dsi_dcs_write_seq_multi(_ctx, HX83102_SETMIPI, 0x84);
+   mipi_dsi_dcs_write_seq_multi(_ctx, HX83102_SETSPCCMD, 0x3f);
+   mipi_dsi_dcs_write_seq_multi(_ctx, HX83102_SETVDC, 0x1b, 0x04);
+   mipi_dsi_dcs_write_seq_multi(_ctx, HX83102_UNKNOWN_BE, 0x20);
+   mipi_dsi_dcs_write_seq_multi(_ctx, HX83102_SETPTBA, 0xfc, 0xc4);
+   mipi_dsi_dcs_write_seq_multi(_ctx, HX83102_SETSTBA, 0x34, 0x34, 
0x22, 0x11, 0x22, 0xa0,
+0x31, 0x08, 0xf5, 0x03);
+   mipi_dsi_dcs_write_seq_multi(_ctx, HX83102_SETSPCCMD, 0xcc);
+   mipi_dsi_dcs_write_seq_multi(_ctx, HX83102_SETTCON, 0x80);
+   mipi_dsi_dcs_write_seq_multi(_ctx, HX83102_SETSPCCMD, 0x3f);
+   mipi_dsi_dcs_write_seq_multi(_ctx, HX83102_SETSPCCMD, 0xd3);
+   mipi_dsi_dcs_write_seq_multi(_ctx, HX83102_SETTCON, 0x22);
+   mipi_dsi_dcs_write_seq_multi(_ctx, HX83102_SETSPCCMD, 0x3f);
+   mipi_dsi_dcs_write_seq_multi(_ctx, HX83102_SETSPCCMD, 0xc6);
+   mipi_dsi_dcs_write_seq_multi(_ctx, HX83102_SETRAMDMY, 0x97);
+   mipi_dsi_dcs_write_seq_multi(_ctx, HX83102_SETSPCCMD, 0x3f);
+   mipi_dsi_dcs_write_seq_multi(_ctx, HX83102_SETPWM, 0x00, 0x1e, 
0x13, 0x88, 0x01);
+   mipi_dsi_dcs_write_seq_multi(_ctx, HX83102_SETCLOCK, 0x08, 0x13, 
0x07, 0x00, 0x0f, 0x34);
+   mipi_dsi_dcs_write_seq_multi(_ctx, HX83102_SETPANEL, 0x02, 0x03, 
0x44);
+   mipi_dsi_dcs_write_seq_multi(_ctx, HX83102_SETSPCCMD, 0xc4);
+   mipi_dsi_dcs_write_seq_multi(_ctx, HX83102_SETCASCADE, 0x03);
+   mipi_dsi_dcs_write_seq_multi(_ctx, HX83102_SETSPCCMD, 0x3f);
+   mipi_dsi_dcs_write_seq_multi(_ctx, HX83102_SETPCTRL, 0x07, 0x06, 
0x00, 0x02, 0x04, 0x2c,
+0xff);
+   mipi_dsi_dcs_write_seq_multi(_ctx, HX83102_SETGIP0, 0x06, 0x00, 
0x00, 0x00, 0x00, 0x08,
+0x08, 0x08, 0x08, 0x37, 0x07, 0x64, 0x7c, 
0x11, 0x11, 0x03, 0x03, 0x32,
+0x10, 0x0e, 0x00, 0x0e, 0x32, 0x17, 0x97, 
0x07, 0x97, 0x32, 0x00, 0x02,
+0x00, 0x02, 0x00, 0x00);
+   mipi_dsi_dcs_write_seq_multi(_ctx, HX83102_SETGIP1, 0x25, 0x24, 
0x25, 0x24, 0x18, 0x18,
+0x18, 0x18, 0x07, 0x06, 0x07, 0x06, 0x05, 
0x04, 0x05, 0x04, 0x03, 0x02,
+0x03, 0x02, 0x01, 0x00, 0x01, 0x00, 0x1e, 
0x1e, 0x1e, 0x1e, 0x1f, 0x1f,
+0x1f, 0x1f, 0x21, 0x20, 0x21, 0x20, 0x18, 
0x18, 0x18, 0x18, 0x18, 0x18,
+0x18, 0x18);
+   mipi_dsi_dcs_write_seq_multi(_ctx, HX83102_SETGIP3, 0xaa, 0xaa, 
0xaa, 0xaa, 0xaa, 0xa0,
+0xaa, 0xaa, 0xaa, 0xaa, 0xaa, 

[PATCH v5 6/7] dt-bindings: display: panel: Add compatible for IVO t109nw41

[Cong Yang]

The IVO t109nw41 is a 11.0" WUXGA TFT LCD panel with himax-hx83102
controller. Hence, we add a new compatible with panel specific config.

Signed-off-by: Cong Yang 
Acked-by: Conor Dooley 
---
Chage since V5:

- No change.

V4: 
https://lore.kernel.org/all/20240507135234.1356855-7-yangco...@huaqin.corp-partner.google.com

Chage since V4:

- No change.

V3: 
https://lore.kernel.org/all/20240424023010.2099949-7-yangco...@huaqin.corp-partner.google.com

Chage since V3:

- Update commit message.

V2: 
https://lore.kernel.org/all/20240422090310.3311429-7-yangco...@huaqin.corp-partner.google.com/

---
 .../devicetree/bindings/display/panel/himax,hx83102.yaml| 2 ++
 1 file changed, 2 insertions(+)

diff --git a/Documentation/devicetree/bindings/display/panel/himax,hx83102.yaml 
b/Documentation/devicetree/bindings/display/panel/himax,hx83102.yaml
index baf8b053e375..c649fb085833 100644
--- a/Documentation/devicetree/bindings/display/panel/himax,hx83102.yaml
+++ b/Documentation/devicetree/bindings/display/panel/himax,hx83102.yaml
@@ -18,6 +18,8 @@ properties:
   - enum:
   # Boe nv110wum-l60 11.0" WUXGA TFT LCD panel
   - boe,nv110wum-l60
+  # IVO t109nw41 11.0" WUXGA TFT LCD panel
+  - ivo,t109nw41
   # STARRY himax83102-j02 10.51" WUXGA TFT LCD panel
   - starry,himax83102-j02
   - const: himax,hx83102
-- 
2.25.1

[PATCH v5 5/7] drm/panel: himax-hx83102: Support for BOE nv110wum-l60 MIPI-DSI panel

[Cong Yang]

The BOE nv110wum-l60 is a 11.0" WUXGA TFT LCD panel, use hx83102 controller
which fits in nicely with the existing panel-himax-hx83102 driver. Hence,
we add a new compatible with panel specific config.

Signed-off-by: Cong Yang 
---
Chage since V5:

- Adjust inital cmds indentation and check accum_err before calling mdelay in 
init()..

V4: 
https://lore.kernel.org/all/20240507135234.1356855-6-yangco...@huaqin.corp-partner.google.com

Chage since V4:

- Depend Dous'series [1].
[1]: https://lore.kernel.org/all/20240501154251.3302887-1-diand...@chromium.org

V3: 
https://lore.kernel.org/all/20240424023010.2099949-6-yangco...@huaqin.corp-partner.google.com

Chage since V3:

- inital cmds use lowercasehex.

V2: 
https://lore.kernel.org/all/20240422090310.3311429-6-yangco...@huaqin.corp-partner.google.com

---
 drivers/gpu/drm/panel/panel-himax-hx83102.c | 133 
 1 file changed, 133 insertions(+)

diff --git a/drivers/gpu/drm/panel/panel-himax-hx83102.c 
b/drivers/gpu/drm/panel/panel-himax-hx83102.c
index 76558b1091a8..f1273e1c92d2 100644
--- a/drivers/gpu/drm/panel/panel-himax-hx83102.c
+++ b/drivers/gpu/drm/panel/panel-himax-hx83102.c
@@ -44,6 +44,7 @@
 #define HX83102_SETGIP20xd6
 #define HX83102_SETGIP30xd8
 #define HX83102_SETGMA 0xe0
+#define HX83102_UNKNOWN_E1 0xe1
 #define HX83102_SETTP1 0xe7
 #define HX83102_SETSPCCMD  0xe9
 
@@ -185,6 +186,113 @@ static int starry_himax83102_j02_init(struct hx83102 *ctx)
return dsi_ctx.accum_err;
 };
 
+static int boe_nv110wum_init(struct hx83102 *ctx)
+{
+   struct mipi_dsi_multi_context dsi_ctx = { .dsi = ctx->dsi };
+
+   msleep(60);
+
+   hx83102_enable_extended_cmds(_ctx, true);
+   mipi_dsi_dcs_write_seq_multi(_ctx, HX83102_SETPOWER, 0x2c, 0xaf, 
0xaf, 0x2b, 0xeb, 0x42,
+0xe1, 0x4d, 0x36, 0x36, 0x36, 0x36, 0x1a, 
0x8b, 0x11, 0x65, 0x00,
+0x88, 0xfa, 0xff, 0xff, 0x8f, 0xff, 0x08, 
0x9a, 0x33);
+   mipi_dsi_dcs_write_seq_multi(_ctx, HX83102_SETDISP, 0x00, 0x47, 
0xb0, 0x80, 0x00, 0x12,
+0x71, 0x3c, 0xa3, 0x11, 0x00, 0x00, 0x00, 
0x88, 0xf5, 0x22, 0x8f);
+   mipi_dsi_dcs_write_seq_multi(_ctx, HX83102_SETCYC, 0x49, 0x49, 
0x32, 0x32, 0x14, 0x32,
+0x84, 0x6e, 0x84, 0x6e, 0x01, 0x9c);
+   mipi_dsi_dcs_write_seq_multi(_ctx, HX83102_SETSPCCMD, 0xcd);
+   mipi_dsi_dcs_write_seq_multi(_ctx, HX83102_SETMIPI, 0x84);
+   mipi_dsi_dcs_write_seq_multi(_ctx, HX83102_SETSPCCMD, 0x3f);
+   mipi_dsi_dcs_write_seq_multi(_ctx, HX83102_SETVDC, 0x1b, 0x04);
+   mipi_dsi_dcs_write_seq_multi(_ctx, HX83102_UNKNOWN_BE, 0x20);
+   mipi_dsi_dcs_write_seq_multi(_ctx, HX83102_SETPTBA, 0xfc, 0x84);
+   mipi_dsi_dcs_write_seq_multi(_ctx, HX83102_SETSTBA, 0x36, 0x36, 
0x22, 0x00, 0x00, 0xa0,
+0x61, 0x08, 0xf5, 0x03);
+   mipi_dsi_dcs_write_seq_multi(_ctx, HX83102_SETSPCCMD, 0xcc);
+   mipi_dsi_dcs_write_seq_multi(_ctx, HX83102_SETTCON, 0x80);
+   mipi_dsi_dcs_write_seq_multi(_ctx, HX83102_SETSPCCMD, 0x3f);
+   mipi_dsi_dcs_write_seq_multi(_ctx, HX83102_SETSPCCMD, 0xc6);
+   mipi_dsi_dcs_write_seq_multi(_ctx, HX83102_SETRAMDMY, 0x97);
+   mipi_dsi_dcs_write_seq_multi(_ctx, HX83102_SETSPCCMD, 0x3f);
+   mipi_dsi_dcs_write_seq_multi(_ctx, HX83102_SETPWM, 0x00, 0x1e, 
0x30, 0xd4, 0x01);
+   mipi_dsi_dcs_write_seq_multi(_ctx, HX83102_SETCLOCK, 0x08, 0x13, 
0x07, 0x00, 0x0f, 0x34);
+   mipi_dsi_dcs_write_seq_multi(_ctx, HX83102_SETPANEL, 0x02, 0x03, 
0x44);
+   mipi_dsi_dcs_write_seq_multi(_ctx, HX83102_SETSPCCMD, 0xc4);
+   mipi_dsi_dcs_write_seq_multi(_ctx, HX83102_SETCASCADE, 0x03);
+   mipi_dsi_dcs_write_seq_multi(_ctx, HX83102_SETSPCCMD, 0x3f);
+   mipi_dsi_dcs_write_seq_multi(_ctx, HX83102_SETPCTRL, 0x37, 0x06, 
0x00, 0x02, 0x04, 0x0c, 0xff);
+   mipi_dsi_dcs_write_seq_multi(_ctx, HX83102_UNKNOWN_D2, 0x1f, 0x11, 
0x1f, 0x11);
+   mipi_dsi_dcs_write_seq_multi(_ctx, HX83102_SETGIP0, 0x06, 0x00, 
0x00, 0x00, 0x00, 0x04,
+0x08, 0x04, 0x08, 0x37, 0x37, 0x64, 0x4b, 
0x11, 0x11, 0x03, 0x03, 0x32,
+0x10, 0x0e, 0x00, 0x0e, 0x32, 0x10, 0x0a, 
0x00, 0x0a, 0x32, 0x17, 0x98,
+0x07, 0x98, 0x00, 0x00);
+   mipi_dsi_dcs_write_seq_multi(_ctx, HX83102_SETGIP1, 0x18, 0x18, 
0x18, 0x18, 0x1e, 0x1e,
+0x1e, 0x1e, 0x1f, 0x1f, 0x1f, 0x1f, 0x24, 
0x24, 0x24, 0x24, 0x07, 0x06,
+0x07, 0x06, 0x05, 0x04, 0x05, 0x04, 0x03, 
0x02, 0x03, 0x02, 0x01, 0x00,
+0x01, 0x00, 0x21, 0x20, 0x21, 0x20, 0x18, 
0x18, 0x18, 0x18, 0x18, 0x18,
+0x18, 0x18);
+   mipi_dsi_dcs_write_seq_multi(_ctx, HX83102_SETGIP3, 0xaf, 

[PATCH v5 4/7] dt-bindings: display: panel: Add compatible for BOE nv110wum-l60

[Cong Yang]

The BOE nv110wum-l60 is a 11.0" WUXGA TFT LCD panel with himax-hx83102
controller. Hence, we add a new compatible with panel specific config.

Signed-off-by: Cong Yang 
Acked-by: Conor Dooley 
---
Chage since V5:

- No change.

V4: 
https://lore.kernel.org/all/20240507135234.1356855-5-yangco...@huaqin.corp-partner.google.com

Chage since V4:

- No change.

V3: 
https://lore.kernel.org/all/20240424023010.2099949-5-yangco...@huaqin.corp-partner.google.com

Chage since V3:

- Update commit message.

V2: 
https://lore.kernel.org/all/20240422090310.3311429-5-yangco...@huaqin.corp-partner.google.com

---
 .../devicetree/bindings/display/panel/himax,hx83102.yaml| 2 ++
 1 file changed, 2 insertions(+)

diff --git a/Documentation/devicetree/bindings/display/panel/himax,hx83102.yaml 
b/Documentation/devicetree/bindings/display/panel/himax,hx83102.yaml
index fc584b5088ff..baf8b053e375 100644
--- a/Documentation/devicetree/bindings/display/panel/himax,hx83102.yaml
+++ b/Documentation/devicetree/bindings/display/panel/himax,hx83102.yaml
@@ -16,6 +16,8 @@ properties:
   compatible:
 items:
   - enum:
+  # Boe nv110wum-l60 11.0" WUXGA TFT LCD panel
+  - boe,nv110wum-l60
   # STARRY himax83102-j02 10.51" WUXGA TFT LCD panel
   - starry,himax83102-j02
   - const: himax,hx83102
-- 
2.25.1

[PATCH v5 3/7] arm64: defconfig: Enable HIMAX_HX83102 panel

[Cong Yang]

DRM_PANEL_HIMAX_HX83102 is being split out from DRM_PANEL_BOE_TV101WUM_NL6.
Since the arm64 defconfig had the BOE panel driver enabled, let's also
enable the himax driver.

Signed-off-by: Cong Yang 
Reviewed-by: Douglas Anderson 
---
 arch/arm64/configs/defconfig | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/arm64/configs/defconfig b/arch/arm64/configs/defconfig
index 2c30d617e180..687c86ddaece 100644
--- a/arch/arm64/configs/defconfig
+++ b/arch/arm64/configs/defconfig
@@ -864,6 +864,7 @@ CONFIG_DRM_PANEL_BOE_TV101WUM_NL6=m
 CONFIG_DRM_PANEL_LVDS=m
 CONFIG_DRM_PANEL_SIMPLE=m
 CONFIG_DRM_PANEL_EDP=m
+CONFIG_DRM_PANEL_HIMAX_HX83102=m
 CONFIG_DRM_PANEL_ILITEK_ILI9882T=m
 CONFIG_DRM_PANEL_MANTIX_MLAF057WE51=m
 CONFIG_DRM_PANEL_RAYDIUM_RM67191=m
-- 
2.25.1

[PATCH v5 2/7] drm/panel: himax-hx83102: Break out as separate driver

[Cong Yang]

The Starry HX83102 based mipi panel should never have been part of the boe
tv101wum-n16 driver. Discussion with Doug and Linus in V1 [1], we need a
separate driver to enable the hx83102 controller.

In hx83102 driver, add DSI commands as macros. So it can add some panels
with same control model in the future.

In the old boe-tv101wum-nl6 driver inital cmds was invoked at the end of
prepare() function , and call 0x11 and 0x29 at end of inital. For
himax-hx83102 driver, we move 0x11 and 0x29 cmds invoked at enable()
function. For panel timing, I think there is no much difference.

Note:0x11 is mipi_dsi_dcs_exit_sleep_mode
 0x29 is mipi_dsi_dcs_set_display_on

[1]: 
https://lore.kernel.org/all/CACRpkdbzYZAS0=zbqjuc4cb2wj4s1h6n6asazqvdmv95r3z...@mail.gmail.com

Signed-off-by: Cong Yang 
---
Chage since V5:

-  Modify hx83102_enable_extended_cmds function and adjust inital cmds 
indentation.update commit message.
-  Move the ->init() call to be made at the end of prepare() instead of the 
beginning of enable().

V4: 
https://lore.kernel.org/all/20240507135234.1356855-3-yangco...@huaqin.corp-partner.google.com

Chage since V4:

-  Add hx83102_enable_extended_cmds function, rename UNKNOWN CMDS and depend 
Dous'series [1].
[1]: https://lore.kernel.org/all/20240501154251.3302887-1-diand...@chromium.org

V3: 
https://lore.kernel.org/all/20240424023010.2099949-3-yangco...@huaqin.corp-partner.google.com

Chage since V3:

-  Drop excess flags and function, inital cmds use lowercasehex.

V2: 
https://lore.kernel.org/all/20240422090310.3311429-3-yangco...@huaqin.corp-partner.google.com

---
 drivers/gpu/drm/panel/Kconfig |   9 +
 drivers/gpu/drm/panel/Makefile|   1 +
 .../gpu/drm/panel/panel-boe-tv101wum-nl6.c| 133 -
 drivers/gpu/drm/panel/panel-himax-hx83102.c   | 477 ++
 4 files changed, 487 insertions(+), 133 deletions(-)
 create mode 100644 drivers/gpu/drm/panel/panel-himax-hx83102.c

diff --git a/drivers/gpu/drm/panel/Kconfig b/drivers/gpu/drm/panel/Kconfig
index d037b3b8b999..acd3d09b5a05 100644
--- a/drivers/gpu/drm/panel/Kconfig
+++ b/drivers/gpu/drm/panel/Kconfig
@@ -145,6 +145,15 @@ config DRM_PANEL_LVDS
  handling of power supplies or control signals. It implements automatic
  backlight handling if the panel is attached to a backlight controller.
 
+config DRM_PANEL_HIMAX_HX83102
+   tristate "Himax HX83102-based panels"
+   depends on OF
+   depends on DRM_MIPI_DSI
+   depends on BACKLIGHT_CLASS_DEVICE
+   help
+ Say Y if you want to enable support for panels based on the
+ Himax HX83102 controller.
+
 config DRM_PANEL_HIMAX_HX83112A
tristate "Himax HX83112A-based DSI panel"
depends on OF
diff --git a/drivers/gpu/drm/panel/Makefile b/drivers/gpu/drm/panel/Makefile
index f156d7fa0bcc..8fa9e38382f6 100644
--- a/drivers/gpu/drm/panel/Makefile
+++ b/drivers/gpu/drm/panel/Makefile
@@ -15,6 +15,7 @@ obj-$(CONFIG_DRM_PANEL_EBBG_FT8719) += panel-ebbg-ft8719.o
 obj-$(CONFIG_DRM_PANEL_ELIDA_KD35T133) += panel-elida-kd35t133.o
 obj-$(CONFIG_DRM_PANEL_FEIXIN_K101_IM2BA02) += panel-feixin-k101-im2ba02.o
 obj-$(CONFIG_DRM_PANEL_FEIYANG_FY07024DI26A30D) += 
panel-feiyang-fy07024di26a30d.o
+obj-$(CONFIG_DRM_PANEL_HIMAX_HX83102) += panel-himax-hx83102.o
 obj-$(CONFIG_DRM_PANEL_HIMAX_HX83112A) += panel-himax-hx83112a.o
 obj-$(CONFIG_DRM_PANEL_HIMAX_HX8394) += panel-himax-hx8394.o
 obj-$(CONFIG_DRM_PANEL_ILITEK_IL9322) += panel-ilitek-ili9322.o
diff --git a/drivers/gpu/drm/panel/panel-boe-tv101wum-nl6.c 
b/drivers/gpu/drm/panel/panel-boe-tv101wum-nl6.c
index aab60cec0603..4b4b125a6c6b 100644
--- a/drivers/gpu/drm/panel/panel-boe-tv101wum-nl6.c
+++ b/drivers/gpu/drm/panel/panel-boe-tv101wum-nl6.c
@@ -1399,108 +1399,6 @@ static int starry_qfh032011_53g_init(struct boe_panel 
*boe)
return 0;
 };
 
-static int starry_himax83102_j02_init(struct boe_panel *boe)
-{
-   struct mipi_dsi_multi_context ctx = { .dsi = boe->dsi };
-
-   mipi_dsi_dcs_write_seq_multi(, 0xb9, 0x83, 0x10, 0x21, 0x55, 0x00);
-   mipi_dsi_dcs_write_seq_multi(, 0xb1, 0x2c, 0xb5, 0xb5, 0x31, 0xf1, 
0x31, 0xd7, 0x2f,
-0x36, 0x36, 0x36, 0x36, 0x1a, 0x8b, 0x11, 
0x65, 0x00, 0x88,
-0xfa, 0xff, 0xff, 0x8f, 0xff, 0x08, 0x74, 
0x33);
-   mipi_dsi_dcs_write_seq_multi(, 0xb2, 0x00, 0x47, 0xb0, 0x80, 0x00, 
0x12, 0x72, 0x3c,
-0xa3, 0x03, 0x03, 0x00, 0x00, 0x88, 0xf5);
-   mipi_dsi_dcs_write_seq_multi(, 0xb4, 0x76, 0x76, 0x76, 0x76, 0x76, 
0x76, 0x63, 0x5c,
-0x63, 0x5c, 0x01, 0x9e);
-   mipi_dsi_dcs_write_seq_multi(, 0xe9, 0xcd);
-   mipi_dsi_dcs_write_seq_multi(, 0xba, 0x84);
-   mipi_dsi_dcs_write_seq_multi(, 0xe9, 0x3f);
-   mipi_dsi_dcs_write_seq_multi(, 0xbc, 0x1b, 0x04);
-   mipi_dsi_dcs_write_seq_multi(, 0xbe, 0x20);
-   

[PATCH v5 1/7] dt-bindings: display: panel: Add himax hx83102 panel bindings

[Cong Yang]

In V1, discussed with Doug and Linus [1], we need break out as separate
driver for the himax83102-j02 controller. Beacuse "starry,himax83102-j02"
and in this series "BOE nv110wum-l60" "IVO t109nw41" panels use same
controller, they have some common CMDS. So add new documentation for
this panels.

For himax83102-j02 controller, no need 3v3 supply, so remove it.

[1]: 
https://lore.kernel.org/all/CACRpkdbzYZAS0=zbqjuc4cb2wj4s1h6n6asazqvdmv95r3z...@mail.gmail.com

Signed-off-by: Cong Yang 
---
Chage since V5:

- Modify compatible format.

V4: 
https://lore.kernel.org/all/20240507135234.1356855-2-yangco...@huaqin.corp-partner.google.com

Chage since V4:

- Update commit message and add fallback compatible.

V3: 
https://lore.kernel.org/all/20240424023010.2099949-2-yangco...@huaqin.corp-partner.google.com

Chage since V3:

- Update commit message.

V2: 
https://lore.kernel.org/all/20240422090310.3311429-2-yangco...@huaqin.corp-partner.google.com

---
 .../display/panel/boe,tv101wum-nl6.yaml   |  2 -
 .../bindings/display/panel/himax,hx83102.yaml | 73 +++
 2 files changed, 73 insertions(+), 2 deletions(-)
 create mode 100644 
Documentation/devicetree/bindings/display/panel/himax,hx83102.yaml

diff --git 
a/Documentation/devicetree/bindings/display/panel/boe,tv101wum-nl6.yaml 
b/Documentation/devicetree/bindings/display/panel/boe,tv101wum-nl6.yaml
index 906ef62709b8..53fb35f5c9de 100644
--- a/Documentation/devicetree/bindings/display/panel/boe,tv101wum-nl6.yaml
+++ b/Documentation/devicetree/bindings/display/panel/boe,tv101wum-nl6.yaml
@@ -32,8 +32,6 @@ properties:
   - innolux,hj110iz-01a
 # STARRY 2081101QFH032011-53G 10.1" WUXGA TFT LCD panel
   - starry,2081101qfh032011-53g
-# STARRY himax83102-j02 10.51" WUXGA TFT LCD panel
-  - starry,himax83102-j02
 # STARRY ili9882t 10.51" WUXGA TFT LCD panel
   - starry,ili9882t
 
diff --git a/Documentation/devicetree/bindings/display/panel/himax,hx83102.yaml 
b/Documentation/devicetree/bindings/display/panel/himax,hx83102.yaml
new file mode 100644
index ..fc584b5088ff
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/panel/himax,hx83102.yaml
@@ -0,0 +1,73 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/display/panel/himax,hx83102.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Himax HX83102 MIPI-DSI LCD panel controller
+
+maintainers:
+  - Cong Yang 
+
+allOf:
+  - $ref: panel-common.yaml#
+
+properties:
+  compatible:
+items:
+  - enum:
+  # STARRY himax83102-j02 10.51" WUXGA TFT LCD panel
+  - starry,himax83102-j02
+  - const: himax,hx83102
+
+  reg:
+description: the virtual channel number of a DSI peripheral
+
+  enable-gpios:
+description: a GPIO spec for the enable pin
+
+  pp1800-supply:
+description: core voltage supply
+
+  avdd-supply:
+description: phandle of the regulator that provides positive voltage
+
+  avee-supply:
+description: phandle of the regulator that provides negative voltage
+
+  backlight: true
+  port: true
+  rotation: true
+
+required:
+  - compatible
+  - reg
+  - enable-gpios
+  - pp1800-supply
+  - avdd-supply
+  - avee-supply
+
+additionalProperties: false
+
+examples:
+  - |
+dsi {
+#address-cells = <1>;
+#size-cells = <0>;
+panel@0 {
+compatible = "starry,himax83102-j02", "himax,hx83102";
+reg = <0>;
+enable-gpios = < 45 0>;
+avdd-supply = <_lcd>;
+avee-supply = <_lcd>;
+pp1800-supply = <_lcd>;
+backlight = <_lcd0>;
+port {
+panel_in: endpoint {
+remote-endpoint = <_out>;
+};
+};
+};
+};
+
+...
-- 
2.25.1

[PATCH v5 0/7] Break out as separate driver and add BOE nv110wum-l60 IVO t109nw41 MIPI-DSI panel

[Cong Yang]

Discussion with Doug and Linus in V1, we need a
separate driver to enable the hx83102 controller.

So this series this series mainly Break out as separate driver
for Starry-himax83102-j02 panels from boe tv101wum driver.

Then add BOE nv110wum-l60 and IVO t109nw41 in himax-hx83102 driver.

Add compatible for BOE nv110wum-l60 and IVO t109nw41
in dt-bindings

Note:this series depend Dous'series [1]
[1]: https://lore.kernel.org/all/20240501154251.3302887-1-diand...@chromium.org/

Changes in v5:
- PATCH 1/7: Modify compatible format.
- PATCH 2/7: Modify hx83102_enable_extended_cmds function and adjust inital 
cmds indentation.update commit message.
- PATCH 3/7: No change.
- PATCH 4/7: No change.
- PATCH 5/7: Adjust inital cmds indentation and check accum_err before calling 
mdelay in init().
- PATCH 6/7: No change.
- PATCH 7/7: Adjust inital cmds indentation and check accum_err before calling 
mdelay in init().
- Link to 
v4:https://lore.kernel.org/all/20240507135234.1356855-1-yangco...@huaqin.corp-partner.google.com

Changes in v4:
- PATCH 1/7: Update commit message and add fallback compatible.
- PATCH 2/7: Add hx83102_enable_extended_cmds function, rename UNKNOWN CMDS and 
depend Dous'series [1].
- PATCH 3/7: No change.
- PATCH 4/7: No change.
- PATCH 5/7: Depend Dous'series [1].
- PATCH 6/7: No change.
- PATCH 7/7: Depend Dous'series [1].
- Link to 
v3:https://lore.kernel.org/all/20240424023010.2099949-1-yangco...@huaqin.corp-partner.google.com/

Changes in v3:
- PATCH 1/7: Update commit message.
- PATCH 2/7: Drop excess flags and function, inital cmds use lowercasehex.
- PATCH 4/7: Update commit message.
- PATCH 5/7: inital cmds use lowercasehex.
- PATCH 6/7: Update commit message.
- PATCH 7/7: inital cmds use lowercasehex..
- Link to v2: 
https://lore.kernel.org/all/20240422090310.3311429-1-yangco...@huaqin.corp-partner.google.com/

Changes in v2:
- PATCH 1/7: Delete Starry-himax83102-j02 from boe,tv101wum-nl6.yaml, add a new 
bindings file.
- PATCH 2/7: Break out as separate driver with Starry-himax83102-j02 panels.
- PATCH 3/7: Enable HIMAX_HX83102 panel.
- PATCH 4/7: Add compatible for BOE nv110wum-l60 in dt-bindings.
- PATCH 5/7: Support for BOE nv110wum-l60 MIPI-DSI panel.
- PATCH 6/7: Add compatible for IVO t109nw41 in dt-bindings..
- PATCH 7/7: Support for IVO t109nw41 MIPI-DSI panel.
- Link to v1: 
https://lore.kernel.org/all/20240410071439.2152588-1-yangco...@huaqin.corp-partner.google.com/

Cong Yang (7):
  dt-bindings: display: panel: Add himax hx83102 panel bindings
  drm/panel: himax-hx83102: Break out as separate driver
  arm64: defconfig: Enable HIMAX_HX83102 panel
  dt-bindings: display: panel: Add compatible for BOE nv110wum-l60
  drm/panel: himax-hx83102: Support for BOE nv110wum-l60 MIPI-DSI panel
  dt-bindings: display: panel: Add compatible for IVO t109nw41
  drm/panel: himax-hx83102: Support for IVO t109nw41 MIPI-DSI panel

 .../display/panel/boe,tv101wum-nl6.yaml   |   2 -
 .../bindings/display/panel/himax,hx83102.yaml |  77 ++
 arch/arm64/configs/defconfig  |   1 +
 drivers/gpu/drm/panel/Kconfig |   9 +
 drivers/gpu/drm/panel/Makefile|   1 +
 .../gpu/drm/panel/panel-boe-tv101wum-nl6.c| 133 
 drivers/gpu/drm/panel/panel-himax-hx83102.c   | 741 ++
 7 files changed, 829 insertions(+), 135 deletions(-)
 create mode 100644 
Documentation/devicetree/bindings/display/panel/himax,hx83102.yaml
 create mode 100644 drivers/gpu/drm/panel/panel-himax-hx83102.c

-- 
2.25.1

[PATCH] [PATCH RESEND] drm/virtio: fix memory leak of vbuf

[Weishi Li]

Both virtio_gpu_queue_ctrl_buffer and virtio_gpu_queue_cursor use
virtqueue_add_sgs to upload the structure virtio_gpu_vbuffer * vbuf
to virtqueue. However, when the vbuf fails to upload and virtqueue_add_sgs
returns -EIO or -ENOMEM, the vbuf will not be able to be free by
virtio_gpu_dequeue_*_func, resulting in a continuous increase
in memory allocated to vgdev ->vbufs.

Therefore, make virtio_gpu_queue_ctrl_sgs and virtio_gpu_queue_cursor
free vbuf directly after virtqueue_add_sgs returns -EIO or -ENOMEM.

Signed-off-by: Weishi Li 
---
 drivers/gpu/drm/virtio/virtgpu_vq.c | 15 ++-
 1 file changed, 10 insertions(+), 5 deletions(-)

diff --git a/drivers/gpu/drm/virtio/virtgpu_vq.c 
b/drivers/gpu/drm/virtio/virtgpu_vq.c
index b1a00c0c25a7..6701ce9d0ee8 100644
--- a/drivers/gpu/drm/virtio/virtgpu_vq.c
+++ b/drivers/gpu/drm/virtio/virtgpu_vq.c
@@ -356,12 +356,14 @@ static int virtio_gpu_queue_ctrl_sgs(struct 
virtio_gpu_device *vgdev,
 
ret = virtqueue_add_sgs(vq, sgs, outcnt, incnt, vbuf, GFP_ATOMIC);
WARN_ON(ret);
+   if (ret < 0 && ret != -ENOSPC) {
+   free_vbuf(vgdev, vbuf);
+   } else {
+   vbuf->seqno = ++vgdev->ctrlq.seqno;
+   trace_virtio_gpu_cmd_queue(vq, virtio_gpu_vbuf_ctrl_hdr(vbuf), 
vbuf->seqno);
 
-   vbuf->seqno = ++vgdev->ctrlq.seqno;
-   trace_virtio_gpu_cmd_queue(vq, virtio_gpu_vbuf_ctrl_hdr(vbuf), 
vbuf->seqno);
-
-   atomic_inc(>pending_commands);
-
+   atomic_inc(>pending_commands);
+   }
spin_unlock(>ctrlq.qlock);
 
drm_dev_exit(idx);
@@ -469,6 +471,9 @@ static void virtio_gpu_queue_cursor(struct 
virtio_gpu_device *vgdev,
wait_event(vgdev->cursorq.ack_queue, vq->num_free >= outcnt);
spin_lock(>cursorq.qlock);
goto retry;
+   } else if (ret < 0) {
+   free_vbuf(vgdev, vbuf);
+   notify = false;
} else {
vbuf->seqno = ++vgdev->cursorq.seqno;
trace_virtio_gpu_cmd_queue(vq,
-- 
2.25.1

Re: [PATCH] drm/msm: remove python 3.9 dependency for compiling msm

[Doug Anderson]

Hi,

On Tue, May 7, 2024 at 4:05 PM Abhinav Kumar  wrote:
>
> Since commit 5acf49119630 ("drm/msm: import gen_header.py script from Mesa"),
> compilation is broken on machines having python versions older than 3.9
> due to dependency on argparse.BooleanOptionalAction.
>
> Switch to use simple bool for the validate flag to remove the dependency.
>
> Fixes: 5acf49119630 ("drm/msm: import gen_header.py script from Mesa")
> Signed-off-by: Abhinav Kumar 
> ---
>  drivers/gpu/drm/msm/registers/gen_header.py | 5 +++--
>  1 file changed, 3 insertions(+), 2 deletions(-)

No idea if we're supposed to allow python as a build dependency. That
being said, I can confirm that this fixes the problem for me since I
ran into it too [1].

Tested-by: Douglas Anderson 

[1] 
https://lore.kernel.org/r/CAD=FV=XnpS-=cookkxzfm8og9wcsemxfesmftyh811438qg...@mail.gmail.com

Re: [PATCH] [PATCH RESEND] drm/virtio: fix memory leak of vbuf

[kernel test robot]

Hi Weishi,

kernel test robot noticed the following build warnings:

[auto build test WARNING on drm-misc/drm-misc-next]
[also build test WARNING on drm/drm-next linus/master v6.9-rc7 next-20240508]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use '--base' as documented in
https://git-scm.com/docs/git-format-patch#_base_tree_information]

url:
https://github.com/intel-lab-lkp/linux/commits/Weishi-Li/drm-virtio-fix-memory-leak-of-vbuf/20240507-114452
base:   git://anongit.freedesktop.org/drm/drm-misc drm-misc-next
patch link:
https://lore.kernel.org/r/20240507033814.57906-1-liweishi%40kylinos.cn
patch subject: [PATCH] [PATCH RESEND] drm/virtio: fix memory leak of vbuf
config: i386-buildonly-randconfig-001-20240508 
(https://download.01.org/0day-ci/archive/20240509/202405090747.y8ofue7r-...@intel.com/config)
compiler: clang version 18.1.4 (https://github.com/llvm/llvm-project 
e6c3289804a67ea0bb6a86fadbe454dd93b8d855)
reproduce (this is a W=1 build): 
(https://download.01.org/0day-ci/archive/20240509/202405090747.y8ofue7r-...@intel.com/reproduce)

If you fix the issue in a separate patch/commit (i.e. not just a new version of
the same patch/commit), kindly add following tags
| Reported-by: kernel test robot 
| Closes: 
https://lore.kernel.org/oe-kbuild-all/202405090747.y8ofue7r-...@intel.com/

All warnings (new ones prefixed by >>):

>> drivers/gpu/drm/virtio/virtgpu_vq.c:474:13: warning: variable 'notify' is 
>> used uninitialized whenever 'if' condition is true 
>> [-Wsometimes-uninitialized]
 474 | } else if (ret < 0) {
 |^~~
   drivers/gpu/drm/virtio/virtgpu_vq.c:487:6: note: uninitialized use occurs 
here
 487 | if (notify)
 | ^~
   drivers/gpu/drm/virtio/virtgpu_vq.c:474:9: note: remove the 'if' if its 
condition is always false
 474 | } else if (ret < 0) {
 |^~
 475 | free_vbuf(vgdev, vbuf);
 | ~~~
 476 | } else {
 | ~~
   drivers/gpu/drm/virtio/virtgpu_vq.c:455:13: note: initialize the variable 
'notify' to silence this warning
 455 | bool notify;
 |^
 | = 0
   1 warning generated.


vim +474 drivers/gpu/drm/virtio/virtgpu_vq.c

   448  
   449  static void virtio_gpu_queue_cursor(struct virtio_gpu_device *vgdev,
   450  struct virtio_gpu_vbuffer *vbuf)
   451  {
   452  struct virtqueue *vq = vgdev->cursorq.vq;
   453  struct scatterlist *sgs[1], ccmd;
   454  int idx, ret, outcnt;
   455  bool notify;
   456  
   457  if (!drm_dev_enter(vgdev->ddev, )) {
   458  free_vbuf(vgdev, vbuf);
   459  return;
   460  }
   461  
   462  sg_init_one(, vbuf->buf, vbuf->size);
   463  sgs[0] = 
   464  outcnt = 1;
   465  
   466  spin_lock(>cursorq.qlock);
   467  retry:
   468  ret = virtqueue_add_sgs(vq, sgs, outcnt, 0, vbuf, GFP_ATOMIC);
   469  if (ret == -ENOSPC) {
   470  spin_unlock(>cursorq.qlock);
   471  wait_event(vgdev->cursorq.ack_queue, vq->num_free >= 
outcnt);
   472  spin_lock(>cursorq.qlock);
   473  goto retry;
 > 474  } else if (ret < 0) {
   475  free_vbuf(vgdev, vbuf);
   476  } else {
   477  vbuf->seqno = ++vgdev->cursorq.seqno;
   478  trace_virtio_gpu_cmd_queue(vq,
   479  virtio_gpu_vbuf_ctrl_hdr(vbuf),
   480  vbuf->seqno);
   481  
   482  notify = virtqueue_kick_prepare(vq);
   483  }
   484  
   485  spin_unlock(>cursorq.qlock);
   486  
   487  if (notify)
   488  virtqueue_notify(vq);
   489  
   490  drm_dev_exit(idx);
   491  }
   492  

-- 
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests/wiki

[PATCH v3 6/6] fbdev/viafb: Make I2C terminology more inclusive

[Easwar Hariharan]

I2C v7, SMBus 3.2, and I3C 1.1.1 specifications have replaced "master/slave"
with more appropriate terms. Inspired by Wolfram's series to fix drivers/i2c/,
fix the terminology for users of I2C_ALGOBIT bitbanging interface, now that
the approved verbiage exists in the specification.

Compile tested, no functionality changes intended

Acked-by: Thomas Zimmermann 
Signed-off-by: Easwar Hariharan 
---
 drivers/video/fbdev/via/chip.h|  8 
 drivers/video/fbdev/via/dvi.c | 24 
 drivers/video/fbdev/via/lcd.c |  6 +++---
 drivers/video/fbdev/via/via_aux.h |  2 +-
 drivers/video/fbdev/via/via_i2c.c | 12 ++--
 drivers/video/fbdev/via/vt1636.c  |  6 +++---
 6 files changed, 29 insertions(+), 29 deletions(-)

diff --git a/drivers/video/fbdev/via/chip.h b/drivers/video/fbdev/via/chip.h
index f0a19cbcb9e5d..f81af13630e28 100644
--- a/drivers/video/fbdev/via/chip.h
+++ b/drivers/video/fbdev/via/chip.h
@@ -69,7 +69,7 @@
 #define VT1632_TMDS 0x01
 #define INTEGRATED_TMDS 0x42
 
-/* Definition TMDS Trasmitter I2C Slave Address */
+/* Definition TMDS Trasmitter I2C Target Address */
 #define VT1632_TMDS_I2C_ADDR0x10
 
 /**/
@@ -88,21 +88,21 @@
 #define TX_DATA_DDR_MODE0x04
 #define TX_DATA_SDR_MODE0x08
 
-/* Definition LVDS Trasmitter I2C Slave Address */
+/* Definition LVDS Trasmitter I2C Target Address */
 #define VT1631_LVDS_I2C_ADDR0x70
 #define VT3271_LVDS_I2C_ADDR0x80
 #define VT1636_LVDS_I2C_ADDR0x80
 
 struct tmds_chip_information {
int tmds_chip_name;
-   int tmds_chip_slave_addr;
+   int tmds_chip_target_addr;
int output_interface;
int i2c_port;
 };
 
 struct lvds_chip_information {
int lvds_chip_name;
-   int lvds_chip_slave_addr;
+   int lvds_chip_target_addr;
int output_interface;
int i2c_port;
 };
diff --git a/drivers/video/fbdev/via/dvi.c b/drivers/video/fbdev/via/dvi.c
index 13147e3066ebf..27990a73bfa39 100644
--- a/drivers/video/fbdev/via/dvi.c
+++ b/drivers/video/fbdev/via/dvi.c
@@ -70,7 +70,7 @@ bool viafb_tmds_trasmitter_identify(void)
/* Check for VT1632: */
viaparinfo->chip_info->tmds_chip_info.tmds_chip_name = VT1632_TMDS;
viaparinfo->chip_info->
-   tmds_chip_info.tmds_chip_slave_addr = VT1632_TMDS_I2C_ADDR;
+   tmds_chip_info.tmds_chip_target_addr = VT1632_TMDS_I2C_ADDR;
viaparinfo->chip_info->tmds_chip_info.i2c_port = VIA_PORT_31;
if (check_tmds_chip(VT1632_DEVICE_ID_REG, VT1632_DEVICE_ID)) {
/*
@@ -128,14 +128,14 @@ bool viafb_tmds_trasmitter_identify(void)
viaparinfo->chip_info->
tmds_chip_info.tmds_chip_name = NON_TMDS_TRANSMITTER;
viaparinfo->chip_info->tmds_chip_info.
-   tmds_chip_slave_addr = VT1632_TMDS_I2C_ADDR;
+   tmds_chip_target_addr = VT1632_TMDS_I2C_ADDR;
return false;
 }
 
 static void tmds_register_write(int index, u8 data)
 {
viafb_i2c_writebyte(viaparinfo->chip_info->tmds_chip_info.i2c_port,
-   
viaparinfo->chip_info->tmds_chip_info.tmds_chip_slave_addr,
+   
viaparinfo->chip_info->tmds_chip_info.tmds_chip_target_addr,
index, data);
 }
 
@@ -144,7 +144,7 @@ static int tmds_register_read(int index)
u8 data;
 
viafb_i2c_readbyte(viaparinfo->chip_info->tmds_chip_info.i2c_port,
-  (u8) 
viaparinfo->chip_info->tmds_chip_info.tmds_chip_slave_addr,
+  (u8) 
viaparinfo->chip_info->tmds_chip_info.tmds_chip_target_addr,
   (u8) index, );
return data;
 }
@@ -152,7 +152,7 @@ static int tmds_register_read(int index)
 static int tmds_register_read_bytes(int index, u8 *buff, int buff_len)
 {
viafb_i2c_readbytes(viaparinfo->chip_info->tmds_chip_info.i2c_port,
-   (u8) 
viaparinfo->chip_info->tmds_chip_info.tmds_chip_slave_addr,
+   (u8) 
viaparinfo->chip_info->tmds_chip_info.tmds_chip_target_addr,
(u8) index, buff, buff_len);
return 0;
 }
@@ -256,14 +256,14 @@ static int viafb_dvi_query_EDID(void)
 
DEBUG_MSG(KERN_INFO "viafb_dvi_query_EDID!!\n");
 
-   restore = viaparinfo->chip_info->tmds_chip_info.tmds_chip_slave_addr;
-   viaparinfo->chip_info->tmds_chip_info.tmds_chip_slave_addr = 0xA0;
+   restore = viaparinfo->chip_info->tmds_chip_info.tmds_chip_target_addr;
+   viaparinfo->chip_info->tmds_chip_info.tmds_chip_target_addr = 0xA0;
 
data0 = (u8) tmds_register_read(0x00);
data1 = (u8) tmds_register_read(0x01);
if ((data0 == 0) && (data1 == 0xFF)) {
viaparinfo->chip_info->
-   tmds_chip_info.tmds_chip_slave_addr = restore;
+   

[PATCH v3 4/6] sfc: falcon: Make I2C terminology more inclusive

[Easwar Hariharan]

I2C v7, SMBus 3.2, and I3C 1.1.1 specifications have replaced "master/slave"
with more appropriate terms. Inspired by Wolfram's series to fix drivers/i2c/,
fix the terminology for users of I2C_ALGOBIT bitbanging interface, now that
the approved verbiage exists in the specification.

Compile tested, no functionality changes intended

Reviewed-by: Martin Habets 
Reviewed-by: Simon Horman 
Signed-off-by: Easwar Hariharan 
---
 drivers/net/ethernet/sfc/falcon/falcon.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/net/ethernet/sfc/falcon/falcon.c 
b/drivers/net/ethernet/sfc/falcon/falcon.c
index 7a1c9337081b5..36114ce88034c 100644
--- a/drivers/net/ethernet/sfc/falcon/falcon.c
+++ b/drivers/net/ethernet/sfc/falcon/falcon.c
@@ -367,7 +367,7 @@ static const struct i2c_algo_bit_data 
falcon_i2c_bit_operations = {
.getsda = falcon_getsda,
.getscl = falcon_getscl,
.udelay = 5,
-   /* Wait up to 50 ms for slave to let us pull SCL high */
+   /* Wait up to 50 ms for target to let us pull SCL high */
.timeout= DIV_ROUND_UP(HZ, 20),
 };
 
-- 
2.34.1

[PATCH v3 5/6] fbdev/smscufx: Make I2C terminology more inclusive

[Easwar Hariharan]

I2C v7, SMBus 3.2, and I3C 1.1.1 specifications have replaced "master/slave"
with more appropriate terms. Inspired by Wolfram's series to fix drivers/i2c/,
fix the terminology for users of I2C_ALGOBIT bitbanging interface, now that
the approved verbiage exists in the specification.

Compile tested, no functionality changes intended

Acked-by: Thomas Zimmermann 
Signed-off-by: Easwar Hariharan 
---
 drivers/video/fbdev/smscufx.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/video/fbdev/smscufx.c b/drivers/video/fbdev/smscufx.c
index 35d682b110c42..5f0dd01fd8349 100644
--- a/drivers/video/fbdev/smscufx.c
+++ b/drivers/video/fbdev/smscufx.c
@@ -1292,7 +1292,7 @@ static int ufx_realloc_framebuffer(struct ufx_data *dev, 
struct fb_info *info)
return 0;
 }
 
-/* sets up I2C Controller for 100 Kbps, std. speed, 7-bit addr, master,
+/* sets up DDC channel for 100 Kbps, std. speed, 7-bit addr, controller mode,
  * restart enabled, but no start byte, enable controller */
 static int ufx_i2c_init(struct ufx_data *dev)
 {
@@ -1321,7 +1321,7 @@ static int ufx_i2c_init(struct ufx_data *dev)
/* 7-bit (not 10-bit) addressing */
tmp &= ~(0x10);
 
-   /* enable restart conditions and master mode */
+   /* enable restart conditions and controller mode */
tmp |= 0x21;
 
status = ufx_reg_write(dev, 0x1000, tmp);
-- 
2.34.1

[PATCH v3 3/6] drm/i915: Make I2C terminology more inclusive

[Easwar Hariharan]

I2C v7, SMBus 3.2, and I3C 1.1.1 specifications have replaced "master/slave"
with more appropriate terms. Inspired by Wolfram's series to fix drivers/i2c/,
fix the terminology for users of I2C_ALGOBIT bitbanging interface, now that
the approved verbiage exists in the specification.

Compile tested, no functionality changes intended

Reviewed-by: Rodrigo Vivi 
Acked-by: Rodrigo Vivi 
Acked-by: Zhi Wang 
Signed-off-by: Easwar Hariharan 
---
 drivers/gpu/drm/i915/display/dvo_ch7017.c | 14 -
 drivers/gpu/drm/i915/display/dvo_ch7xxx.c | 18 +--
 drivers/gpu/drm/i915/display/dvo_ivch.c   | 16 +-
 drivers/gpu/drm/i915/display/dvo_ns2501.c | 18 +--
 drivers/gpu/drm/i915/display/dvo_sil164.c | 18 +--
 drivers/gpu/drm/i915/display/dvo_tfp410.c | 18 +--
 drivers/gpu/drm/i915/display/intel_bios.c | 22 +++---
 .../gpu/drm/i915/display/intel_display_core.h |  2 +-
 drivers/gpu/drm/i915/display/intel_dsi.h  |  2 +-
 drivers/gpu/drm/i915/display/intel_dsi_vbt.c  | 20 ++---
 drivers/gpu/drm/i915/display/intel_dvo.c  | 14 -
 drivers/gpu/drm/i915/display/intel_dvo_dev.h  |  2 +-
 drivers/gpu/drm/i915/display/intel_gmbus.c|  4 +--
 drivers/gpu/drm/i915/display/intel_sdvo.c | 30 +--
 drivers/gpu/drm/i915/display/intel_vbt_defs.h |  4 +--
 drivers/gpu/drm/i915/gvt/edid.c   | 28 -
 drivers/gpu/drm/i915/gvt/edid.h   |  4 +--
 drivers/gpu/drm/i915/gvt/opregion.c   |  2 +-
 18 files changed, 118 insertions(+), 118 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/dvo_ch7017.c 
b/drivers/gpu/drm/i915/display/dvo_ch7017.c
index d0c3880d7f80f..493e730c685b8 100644
--- a/drivers/gpu/drm/i915/display/dvo_ch7017.c
+++ b/drivers/gpu/drm/i915/display/dvo_ch7017.c
@@ -170,13 +170,13 @@ static bool ch7017_read(struct intel_dvo_device *dvo, u8 
addr, u8 *val)
 {
struct i2c_msg msgs[] = {
{
-   .addr = dvo->slave_addr,
+   .addr = dvo->target_addr,
.flags = 0,
.len = 1,
.buf = ,
},
{
-   .addr = dvo->slave_addr,
+   .addr = dvo->target_addr,
.flags = I2C_M_RD,
.len = 1,
.buf = val,
@@ -189,7 +189,7 @@ static bool ch7017_write(struct intel_dvo_device *dvo, u8 
addr, u8 val)
 {
u8 buf[2] = { addr, val };
struct i2c_msg msg = {
-   .addr = dvo->slave_addr,
+   .addr = dvo->target_addr,
.flags = 0,
.len = 2,
.buf = buf,
@@ -197,7 +197,7 @@ static bool ch7017_write(struct intel_dvo_device *dvo, u8 
addr, u8 val)
return i2c_transfer(dvo->i2c_bus, , 1) == 1;
 }
 
-/** Probes for a CH7017 on the given bus and slave address. */
+/** Probes for a CH7017 on the given bus and target address. */
 static bool ch7017_init(struct intel_dvo_device *dvo,
struct i2c_adapter *adapter)
 {
@@ -227,13 +227,13 @@ static bool ch7017_init(struct intel_dvo_device *dvo,
break;
default:
DRM_DEBUG_KMS("ch701x not detected, got %d: from %s "
- "slave %d.\n",
- val, adapter->name, dvo->slave_addr);
+ "target %d.\n",
+ val, adapter->name, dvo->target_addr);
goto fail;
}
 
DRM_DEBUG_KMS("%s detected on %s, addr %d\n",
- str, adapter->name, dvo->slave_addr);
+ str, adapter->name, dvo->target_addr);
return true;
 
 fail:
diff --git a/drivers/gpu/drm/i915/display/dvo_ch7xxx.c 
b/drivers/gpu/drm/i915/display/dvo_ch7xxx.c
index 2e8e85da5a409..534b8544e0a41 100644
--- a/drivers/gpu/drm/i915/display/dvo_ch7xxx.c
+++ b/drivers/gpu/drm/i915/display/dvo_ch7xxx.c
@@ -153,13 +153,13 @@ static bool ch7xxx_readb(struct intel_dvo_device *dvo, 
int addr, u8 *ch)
 
struct i2c_msg msgs[] = {
{
-   .addr = dvo->slave_addr,
+   .addr = dvo->target_addr,
.flags = 0,
.len = 1,
.buf = out_buf,
},
{
-   .addr = dvo->slave_addr,
+   .addr = dvo->target_addr,
.flags = I2C_M_RD,
.len = 1,
.buf = in_buf,
@@ -176,7 +176,7 @@ static bool ch7xxx_readb(struct intel_dvo_device *dvo, int 
addr, u8 *ch)
 
if (!ch7xxx->quiet) {
DRM_DEBUG_KMS("Unable to read register 0x%02x from %s:%02x.\n",
- addr, adapter->name, dvo->slave_addr);
+ addr, adapter->name, 

[PATCH v3 2/6] drm/gma500: Make I2C terminology more inclusive

[Easwar Hariharan]

I2C v7, SMBus 3.2, and I3C 1.1.1 specifications have replaced "master/slave"
with more appropriate terms. Inspired by Wolfram's series to fix drivers/i2c/,
fix the terminology for users of I2C_ALGOBIT bitbanging interface, now that
the approved verbiage exists in the specification.

Compile tested, no functionality changes intended

Acked-by: Thomas Zimmermann 
Signed-off-by: Easwar Hariharan 
---
 drivers/gpu/drm/gma500/cdv_intel_lvds.c |  2 +-
 drivers/gpu/drm/gma500/intel_bios.c | 22 ++---
 drivers/gpu/drm/gma500/intel_bios.h |  4 ++--
 drivers/gpu/drm/gma500/intel_gmbus.c|  2 +-
 drivers/gpu/drm/gma500/psb_drv.h|  2 +-
 drivers/gpu/drm/gma500/psb_intel_drv.h  |  2 +-
 drivers/gpu/drm/gma500/psb_intel_lvds.c |  4 ++--
 drivers/gpu/drm/gma500/psb_intel_sdvo.c | 26 -
 8 files changed, 32 insertions(+), 32 deletions(-)

diff --git a/drivers/gpu/drm/gma500/cdv_intel_lvds.c 
b/drivers/gpu/drm/gma500/cdv_intel_lvds.c
index f08a6803dc184..c7652a02b42ec 100644
--- a/drivers/gpu/drm/gma500/cdv_intel_lvds.c
+++ b/drivers/gpu/drm/gma500/cdv_intel_lvds.c
@@ -565,7 +565,7 @@ void cdv_intel_lvds_init(struct drm_device *dev,
dev->dev, "I2C bus registration failed.\n");
goto err_encoder_cleanup;
}
-   gma_encoder->i2c_bus->slave_addr = 0x2C;
+   gma_encoder->i2c_bus->target_addr = 0x2C;
dev_priv->lvds_i2c_bus = gma_encoder->i2c_bus;
 
/*
diff --git a/drivers/gpu/drm/gma500/intel_bios.c 
b/drivers/gpu/drm/gma500/intel_bios.c
index 8245b5603d2c0..d5924ca3ed050 100644
--- a/drivers/gpu/drm/gma500/intel_bios.c
+++ b/drivers/gpu/drm/gma500/intel_bios.c
@@ -14,8 +14,8 @@
 #include "psb_intel_drv.h"
 #include "psb_intel_reg.h"
 
-#defineSLAVE_ADDR1 0x70
-#defineSLAVE_ADDR2 0x72
+#defineTARGET_ADDR10x70
+#defineTARGET_ADDR20x72
 
 static void *find_section(struct bdb_header *bdb, int section_id)
 {
@@ -357,10 +357,10 @@ parse_sdvo_device_mapping(struct drm_psb_private 
*dev_priv,
/* skip the device block if device type is invalid */
continue;
}
-   if (p_child->slave_addr != SLAVE_ADDR1 &&
-   p_child->slave_addr != SLAVE_ADDR2) {
+   if (p_child->target_addr != TARGET_ADDR1 &&
+   p_child->target_addr != TARGET_ADDR2) {
/*
-* If the slave address is neither 0x70 nor 0x72,
+* If the target address is neither 0x70 nor 0x72,
 * it is not a SDVO device. Skip it.
 */
continue;
@@ -371,22 +371,22 @@ parse_sdvo_device_mapping(struct drm_psb_private 
*dev_priv,
DRM_DEBUG_KMS("Incorrect SDVO port. Skip it\n");
continue;
}
-   DRM_DEBUG_KMS("the SDVO device with slave addr %2x is found on"
+   DRM_DEBUG_KMS("the SDVO device with target addr %2x is found on"
" %s port\n",
-   p_child->slave_addr,
+   p_child->target_addr,
(p_child->dvo_port == DEVICE_PORT_DVOB) ?
"SDVOB" : "SDVOC");
p_mapping = &(dev_priv->sdvo_mappings[p_child->dvo_port - 1]);
if (!p_mapping->initialized) {
p_mapping->dvo_port = p_child->dvo_port;
-   p_mapping->slave_addr = p_child->slave_addr;
+   p_mapping->target_addr = p_child->target_addr;
p_mapping->dvo_wiring = p_child->dvo_wiring;
p_mapping->ddc_pin = p_child->ddc_pin;
p_mapping->i2c_pin = p_child->i2c_pin;
p_mapping->initialized = 1;
DRM_DEBUG_KMS("SDVO device: dvo=%x, addr=%x, wiring=%d, 
ddc_pin=%d, i2c_pin=%d\n",
  p_mapping->dvo_port,
- p_mapping->slave_addr,
+ p_mapping->target_addr,
  p_mapping->dvo_wiring,
  p_mapping->ddc_pin,
  p_mapping->i2c_pin);
@@ -394,10 +394,10 @@ parse_sdvo_device_mapping(struct drm_psb_private 
*dev_priv,
DRM_DEBUG_KMS("Maybe one SDVO port is shared by "
 "two SDVO device.\n");
}
-   if (p_child->slave2_addr) {
+   if (p_child->target2_addr) {
/* Maybe this is a SDVO device with multiple inputs */
/* And the mapping info is not added */
-   DRM_DEBUG_KMS("there exists the slave2_addr. Maybe this"

[PATCH v3 1/6] drm/amdgpu, drm/radeon: Make I2C terminology more inclusive

[Easwar Hariharan]

I2C v7, SMBus 3.2, and I3C 1.1.1 specifications have replaced "master/slave"
with more appropriate terms. Inspired by Wolfram's series to fix drivers/i2c/,
fix the terminology for users of I2C_ALGOBIT bitbanging interface, now that
the approved verbiage exists in the specification.

Compile tested, no functionality changes intended

Acked-by: Alex Deucher 
Signed-off-by: Easwar Hariharan 
---
 .../gpu/drm/amd/amdgpu/amdgpu_atomfirmware.c  |  8 +++---
 drivers/gpu/drm/amd/amdgpu/amdgpu_i2c.c   | 10 +++
 drivers/gpu/drm/amd/amdgpu/atombios_i2c.c |  8 +++---
 drivers/gpu/drm/amd/amdgpu/atombios_i2c.h |  2 +-
 drivers/gpu/drm/amd/amdgpu/smu_v11_0_i2c.c| 20 ++---
 .../gpu/drm/amd/display/dc/bios/bios_parser.c |  2 +-
 .../drm/amd/display/dc/bios/bios_parser2.c|  2 +-
 .../drm/amd/display/dc/core/dc_link_exports.c |  4 +--
 drivers/gpu/drm/amd/display/dc/dc.h   |  2 +-
 drivers/gpu/drm/amd/display/dc/dce/dce_i2c.c  |  4 +--
 .../display/include/grph_object_ctrl_defs.h   |  2 +-
 drivers/gpu/drm/amd/include/atombios.h|  2 +-
 drivers/gpu/drm/amd/include/atomfirmware.h| 26 -
 .../powerplay/hwmgr/vega20_processpptables.c  |  4 +--
 .../amd/pm/powerplay/inc/smu11_driver_if.h|  2 +-
 .../inc/pmfw_if/smu11_driver_if_arcturus.h|  2 +-
 .../inc/pmfw_if/smu11_driver_if_navi10.h  |  2 +-
 .../pmfw_if/smu11_driver_if_sienna_cichlid.h  |  2 +-
 .../inc/pmfw_if/smu13_driver_if_aldebaran.h   |  2 +-
 .../inc/pmfw_if/smu13_driver_if_v13_0_0.h |  2 +-
 .../inc/pmfw_if/smu13_driver_if_v13_0_7.h |  2 +-
 .../gpu/drm/amd/pm/swsmu/smu11/arcturus_ppt.c |  4 +--
 .../amd/pm/swsmu/smu11/sienna_cichlid_ppt.c   |  8 +++---
 drivers/gpu/drm/radeon/atombios.h | 16 +--
 drivers/gpu/drm/radeon/atombios_i2c.c |  4 +--
 drivers/gpu/drm/radeon/radeon_combios.c   | 28 +--
 drivers/gpu/drm/radeon/radeon_i2c.c   | 10 +++
 drivers/gpu/drm/radeon/radeon_mode.h  |  6 ++--
 28 files changed, 93 insertions(+), 93 deletions(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_atomfirmware.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_atomfirmware.c
index 6857c586ded71..37f50fc5d4961 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_atomfirmware.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_atomfirmware.c
@@ -614,7 +614,7 @@ bool amdgpu_atomfirmware_ras_rom_addr(struct amdgpu_device 
*adev,
if ((frev == 3 && crev >= 4) || (frev > 3)) {
firmware_info = (union firmware_info *)
(mode_info->atom_context->bios + data_offset);
-   /* The ras_rom_i2c_slave_addr should ideally
+   /* The ras_rom_i2c_target_addr should ideally
 * be a 19-bit EEPROM address, which would be
 * used as is by the driver; see top of
 * amdgpu_eeprom.c.
@@ -625,13 +625,13 @@ bool amdgpu_atomfirmware_ras_rom_addr(struct 
amdgpu_device *adev,
 * leave the check for the pointer.
 *
 * The reason this works right now is because
-* ras_rom_i2c_slave_addr contains the EEPROM
+* ras_rom_i2c_target_addr contains the EEPROM
 * device type qualifier 1010b in the top 4
 * bits.
 */
-   if (firmware_info->v34.ras_rom_i2c_slave_addr) {
+   if (firmware_info->v34.ras_rom_i2c_target_addr) {
if (i2c_address)
-   *i2c_address = 
firmware_info->v34.ras_rom_i2c_slave_addr;
+   *i2c_address = 
firmware_info->v34.ras_rom_i2c_target_addr;
return true;
}
}
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_i2c.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_i2c.c
index d79cb13e1aa83..070049c92e2b4 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_i2c.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_i2c.c
@@ -280,7 +280,7 @@ amdgpu_i2c_lookup(struct amdgpu_device *adev,
 }
 
 static void amdgpu_i2c_get_byte(struct amdgpu_i2c_chan *i2c_bus,
-u8 slave_addr,
+u8 target_addr,
 u8 addr,
 u8 *val)
 {
@@ -288,13 +288,13 @@ static void amdgpu_i2c_get_byte(struct amdgpu_i2c_chan 
*i2c_bus,
u8 in_buf[2];
struct i2c_msg msgs[] = {
{
-   .addr = slave_addr,
+   .addr = target_addr,
.flags = 0,
.len = 1,
.buf = out_buf,
},
{
-   .addr = slave_addr,
+   .addr = target_addr,
   

[PATCH v3 0/6] Make I2C terminology more inclusive for I2C Algobit and consumers

[Easwar Hariharan]

I2C v7, SMBus 3.2, and I3C 1.1.1 specifications have replaced "master/slave"
with more appropriate terms. Inspired by and following on to Wolfram's
series to fix drivers/i2c/[1], fix the terminology for users of the
I2C_ALGOBIT bitbanging interface, now that the approved verbiage exists
in the specification.

Compile tested, no functionality changes intended

Please chime in with your opinions and suggestions.

This series is based on v6.9-rc7

[1]: 
https://lore.kernel.org/all/20240322132619.6389-1-wsa+rene...@sang-engineering.com/


changelog:
v2->v3:
- v2 link: 
https://lore.kernel.org/all/20240503181333.2336999-1-eahar...@linux.microsoft.com/
- Drop drivers/media patches [Mauro]
- Pick up Acked-by Alex (modulo typo correction, hope you don't mind) [amdgpu, 
radeon]
- Pick up Acked-by Thomas [smscufx, viafb]
- Revert eDP change in drm/i915 [Jani, Rodrigo, Andi]

v1->v2:
- v1 link: 
https://lore.kernel.org/all/20240430173812.1423757-1-eahar...@linux.microsoft.com/
 
- Switch to specification verbiage master->controller, slave->target,
  drop usage of host/client [Thomas]
- Pick up Reviewed-bys and Acked-bys from Rodrigo, Zhi, and Thomas [gma500, 
i915]
- Fix up some straggler master/slave terms in amdgpu, cx25821, ivtv,
  cx23885

v0->v1:
- v0 link: 
https://lore.kernel.org/all/20240329170038.3863998-1-eahar...@linux.microsoft.com/
- Drop drivers/infiniband patches [Leon, Dennis]
- Switch to specification verbiage master->controller, slave->target,
  drop usage of client [Andi, Ville, Jani, Christian]
- Add I3C specification version in commit messages [Andi]
- Pick up Reviewed-bys from Martin and Simon [sfc]
- Drop i2c/treewide patch to make this series independent from Wolfram's
  ([1]) [Wolfram]
- Split away drm/nouveau patch to allow expansion into non-I2C
  non-inclusive terms


Easwar Hariharan (6):
  drm/amdgpu, drm/radeon: Make I2C terminology more inclusive
  drm/gma500: Make I2C terminology more inclusive
  drm/i915: Make I2C terminology more inclusive
  sfc: falcon: Make I2C terminology more inclusive
  fbdev/smscufx: Make I2C terminology more inclusive
  fbdev/viafb: Make I2C terminology more inclusive

 .../gpu/drm/amd/amdgpu/amdgpu_atomfirmware.c  |  8 ++---
 drivers/gpu/drm/amd/amdgpu/amdgpu_i2c.c   | 10 +++
 drivers/gpu/drm/amd/amdgpu/atombios_i2c.c |  8 ++---
 drivers/gpu/drm/amd/amdgpu/atombios_i2c.h |  2 +-
 drivers/gpu/drm/amd/amdgpu/smu_v11_0_i2c.c| 20 ++---
 .../gpu/drm/amd/display/dc/bios/bios_parser.c |  2 +-
 .../drm/amd/display/dc/bios/bios_parser2.c|  2 +-
 .../drm/amd/display/dc/core/dc_link_exports.c |  4 +--
 drivers/gpu/drm/amd/display/dc/dc.h   |  2 +-
 drivers/gpu/drm/amd/display/dc/dce/dce_i2c.c  |  4 +--
 .../display/include/grph_object_ctrl_defs.h   |  2 +-
 drivers/gpu/drm/amd/include/atombios.h|  2 +-
 drivers/gpu/drm/amd/include/atomfirmware.h| 26 
 .../powerplay/hwmgr/vega20_processpptables.c  |  4 +--
 .../amd/pm/powerplay/inc/smu11_driver_if.h|  2 +-
 .../inc/pmfw_if/smu11_driver_if_arcturus.h|  2 +-
 .../inc/pmfw_if/smu11_driver_if_navi10.h  |  2 +-
 .../pmfw_if/smu11_driver_if_sienna_cichlid.h  |  2 +-
 .../inc/pmfw_if/smu13_driver_if_aldebaran.h   |  2 +-
 .../inc/pmfw_if/smu13_driver_if_v13_0_0.h |  2 +-
 .../inc/pmfw_if/smu13_driver_if_v13_0_7.h |  2 +-
 .../gpu/drm/amd/pm/swsmu/smu11/arcturus_ppt.c |  4 +--
 .../amd/pm/swsmu/smu11/sienna_cichlid_ppt.c   |  8 ++---
 drivers/gpu/drm/gma500/cdv_intel_lvds.c   |  2 +-
 drivers/gpu/drm/gma500/intel_bios.c   | 22 +++---
 drivers/gpu/drm/gma500/intel_bios.h   |  4 +--
 drivers/gpu/drm/gma500/intel_gmbus.c  |  2 +-
 drivers/gpu/drm/gma500/psb_drv.h  |  2 +-
 drivers/gpu/drm/gma500/psb_intel_drv.h|  2 +-
 drivers/gpu/drm/gma500/psb_intel_lvds.c   |  4 +--
 drivers/gpu/drm/gma500/psb_intel_sdvo.c   | 26 
 drivers/gpu/drm/i915/display/dvo_ch7017.c | 14 -
 drivers/gpu/drm/i915/display/dvo_ch7xxx.c | 18 +--
 drivers/gpu/drm/i915/display/dvo_ivch.c   | 16 +-
 drivers/gpu/drm/i915/display/dvo_ns2501.c | 18 +--
 drivers/gpu/drm/i915/display/dvo_sil164.c | 18 +--
 drivers/gpu/drm/i915/display/dvo_tfp410.c | 18 +--
 drivers/gpu/drm/i915/display/intel_bios.c | 22 +++---
 .../gpu/drm/i915/display/intel_display_core.h |  2 +-
 drivers/gpu/drm/i915/display/intel_dsi.h  |  2 +-
 drivers/gpu/drm/i915/display/intel_dsi_vbt.c  | 20 ++---
 drivers/gpu/drm/i915/display/intel_dvo.c  | 14 -
 drivers/gpu/drm/i915/display/intel_dvo_dev.h  |  2 +-
 drivers/gpu/drm/i915/display/intel_gmbus.c|  4 +--
 drivers/gpu/drm/i915/display/intel_sdvo.c | 30 +--
 drivers/gpu/drm/i915/display/intel_vbt_defs.h |  4 +--
 drivers/gpu/drm/i915/gvt/edid.c   | 28 -
 drivers/gpu/drm/i915/gvt/edid.h   |  4 +--
 

Re: [PATCH v2 1/2] drm/msm/gen_header: allow skipping the validation

[Abhinav Kumar]

On 5/8/2024 3:41 PM, Doug Anderson wrote:

Hi,

On Fri, May 3, 2024 at 11:15 AM Dmitry Baryshkov
 wrote:


@@ -941,6 +948,7 @@ def main():
 parser = argparse.ArgumentParser()
 parser.add_argument('--rnn', type=str, required=True)
 parser.add_argument('--xml', type=str, required=True)
+   parser.add_argument('--validate', action=argparse.BooleanOptionalAction)


FWIW, the above (argparse.BooleanOptionalAction) appears to be a
python 3.9 thing. My own build environment happens to have python3
default to python 3.8 and thus I get a build error related to this. I
have no idea what the kernel usually assumes for a baseline, but
others might get build errors too. I don't even see python listed in:

https://docs.kernel.org/process/changes.html

...in any case, if it's easy to change this to not require python3.9
that would at least help for my build environment. :-P



Yes, I had posted this y'day as I also ran into this

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



-Doug

Re: [PATCH v3] drm/nouveau: use tile_mode and pte_kind for VM_BIND bo allocations

[Faith Ekstrand]

On Wed, May 8, 2024 at 6:06 PM Mohamed Ahmed <
mohamedahmedegypt2...@gmail.com> wrote:

> Allows PTE kind and tile mode on BO create with VM_BIND,
> and adds a GETPARAM to indicate this change. This is needed to support
> modifiers in NVK and ensure correctness when dealing with the nouveau
> GL driver.
>
> The userspace modifiers implementation this is for can be found here:
> https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/28843
>
> Fixes: b88baab82871 ("drm/nouveau: implement new VM_BIND uAPI")
> Signed-off-by: Mohamed Ahmed 
> ---
>  drivers/gpu/drm/nouveau/nouveau_abi16.c |  3 ++
>  drivers/gpu/drm/nouveau/nouveau_bo.c| 45 +++--
>  include/uapi/drm/nouveau_drm.h  |  7 
>  3 files changed, 30 insertions(+), 25 deletions(-)
>
> diff --git a/drivers/gpu/drm/nouveau/nouveau_abi16.c
> b/drivers/gpu/drm/nouveau/nouveau_abi16.c
> index 80f74ee0f..47e53e17b 100644
> --- a/drivers/gpu/drm/nouveau/nouveau_abi16.c
> +++ b/drivers/gpu/drm/nouveau/nouveau_abi16.c
> @@ -272,6 +272,9 @@ nouveau_abi16_ioctl_getparam(ABI16_IOCTL_ARGS)
> getparam->value =
> (u64)ttm_resource_manager_usage(vram_mgr);
> break;
> }
> +   case NOUVEAU_GETPARAM_HAS_VMA_TILEMODE:
> +   getparam->value = 1;
> +   break;
> default:
> NV_PRINTK(dbg, cli, "unknown parameter %lld\n",
> getparam->param);
> return -EINVAL;
> diff --git a/drivers/gpu/drm/nouveau/nouveau_bo.c
> b/drivers/gpu/drm/nouveau/nouveau_bo.c
> index db8cbf615..583c962ef 100644
> --- a/drivers/gpu/drm/nouveau/nouveau_bo.c
> +++ b/drivers/gpu/drm/nouveau/nouveau_bo.c
> @@ -241,28 +241,29 @@ nouveau_bo_alloc(struct nouveau_cli *cli, u64 *size,
> int *align, u32 domain,
> }
>
> nvbo->contig = !(tile_flags & NOUVEAU_GEM_TILE_NONCONTIG);
> -   if (!nouveau_cli_uvmm(cli) || internal) {
> -   /* for BO noVM allocs, don't assign kinds */
> -   if (cli->device.info.family >= NV_DEVICE_INFO_V0_FERMI) {
> -   nvbo->kind = (tile_flags & 0xff00) >> 8;
> -   if (!nvif_mmu_kind_valid(mmu, nvbo->kind)) {
> -   kfree(nvbo);
> -   return ERR_PTR(-EINVAL);
> -   }
>
> -   nvbo->comp = mmu->kind[nvbo->kind] != nvbo->kind;
> -   } else if (cli->device.info.family >=
> NV_DEVICE_INFO_V0_TESLA) {
> -   nvbo->kind = (tile_flags & 0x7f00) >> 8;
> -   nvbo->comp = (tile_flags & 0x0003) >> 16;
> -   if (!nvif_mmu_kind_valid(mmu, nvbo->kind)) {
> -   kfree(nvbo);
> -   return ERR_PTR(-EINVAL);
> -   }
> -   } else {
> -   nvbo->zeta = (tile_flags & 0x0007);
> +   /* for BO allocs, don't assign kinds */
>

I think this comment is stale. We're now assigning them in both cases.


> +   if (cli->device.info.family >= NV_DEVICE_INFO_V0_FERMI) {
> +   nvbo->kind = (tile_flags & 0xff00) >> 8;
> +   if (!nvif_mmu_kind_valid(mmu, nvbo->kind)) {
> +   kfree(nvbo);
> +   return ERR_PTR(-EINVAL);
> +   }
> +
> +   nvbo->comp = mmu->kind[nvbo->kind] != nvbo->kind;
> +   } else if (cli->device.info.family >= NV_DEVICE_INFO_V0_TESLA) {
> +   nvbo->kind = (tile_flags & 0x7f00) >> 8;
> +   nvbo->comp = (tile_flags & 0x0003) >> 16;
> +   if (!nvif_mmu_kind_valid(mmu, nvbo->kind)) {
> +   kfree(nvbo);
> +   return ERR_PTR(-EINVAL);
> }
> -   nvbo->mode = tile_mode;
> +   } else {
> +   nvbo->zeta = (tile_flags & 0x0007);
> +   }
> +   nvbo->mode = tile_mode;
>
> +   if (!nouveau_cli_uvmm(cli) || internal) {
> /* Determine the desirable target GPU page size for the
> buffer. */
> for (i = 0; i < vmm->page_nr; i++) {
> /* Because we cannot currently allow VMM maps to
> fail
> @@ -304,12 +305,6 @@ nouveau_bo_alloc(struct nouveau_cli *cli, u64 *size,
> int *align, u32 domain,
> }
> nvbo->page = vmm->page[pi].shift;
> } else {
> -   /* reject other tile flags when in VM mode. */
> -   if (tile_mode)
> -   return ERR_PTR(-EINVAL);
> -   if (tile_flags & ~NOUVEAU_GEM_TILE_NONCONTIG)
> -   return ERR_PTR(-EINVAL);
> -
> /* Determine the desirable target GPU page size for the
> buffer. */
> for (i = 0; i < vmm->page_nr; i++) {
> /* Because we cannot currently allow VMM maps to
> fail
> diff --git a/include/uapi/drm/nouveau_drm.h
> 

[PATCH v3] drm/nouveau: use tile_mode and pte_kind for VM_BIND bo allocations

[Mohamed Ahmed]

Allows PTE kind and tile mode on BO create with VM_BIND,
and adds a GETPARAM to indicate this change. This is needed to support
modifiers in NVK and ensure correctness when dealing with the nouveau
GL driver.

The userspace modifiers implementation this is for can be found here:
https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/28843

Fixes: b88baab82871 ("drm/nouveau: implement new VM_BIND uAPI")
Signed-off-by: Mohamed Ahmed 
---
 drivers/gpu/drm/nouveau/nouveau_abi16.c |  3 ++
 drivers/gpu/drm/nouveau/nouveau_bo.c| 45 +++--
 include/uapi/drm/nouveau_drm.h  |  7 
 3 files changed, 30 insertions(+), 25 deletions(-)

diff --git a/drivers/gpu/drm/nouveau/nouveau_abi16.c 
b/drivers/gpu/drm/nouveau/nouveau_abi16.c
index 80f74ee0f..47e53e17b 100644
--- a/drivers/gpu/drm/nouveau/nouveau_abi16.c
+++ b/drivers/gpu/drm/nouveau/nouveau_abi16.c
@@ -272,6 +272,9 @@ nouveau_abi16_ioctl_getparam(ABI16_IOCTL_ARGS)
getparam->value = (u64)ttm_resource_manager_usage(vram_mgr);
break;
}
+   case NOUVEAU_GETPARAM_HAS_VMA_TILEMODE:
+   getparam->value = 1;
+   break;
default:
NV_PRINTK(dbg, cli, "unknown parameter %lld\n", 
getparam->param);
return -EINVAL;
diff --git a/drivers/gpu/drm/nouveau/nouveau_bo.c 
b/drivers/gpu/drm/nouveau/nouveau_bo.c
index db8cbf615..583c962ef 100644
--- a/drivers/gpu/drm/nouveau/nouveau_bo.c
+++ b/drivers/gpu/drm/nouveau/nouveau_bo.c
@@ -241,28 +241,29 @@ nouveau_bo_alloc(struct nouveau_cli *cli, u64 *size, int 
*align, u32 domain,
}
 
nvbo->contig = !(tile_flags & NOUVEAU_GEM_TILE_NONCONTIG);
-   if (!nouveau_cli_uvmm(cli) || internal) {
-   /* for BO noVM allocs, don't assign kinds */
-   if (cli->device.info.family >= NV_DEVICE_INFO_V0_FERMI) {
-   nvbo->kind = (tile_flags & 0xff00) >> 8;
-   if (!nvif_mmu_kind_valid(mmu, nvbo->kind)) {
-   kfree(nvbo);
-   return ERR_PTR(-EINVAL);
-   }
 
-   nvbo->comp = mmu->kind[nvbo->kind] != nvbo->kind;
-   } else if (cli->device.info.family >= NV_DEVICE_INFO_V0_TESLA) {
-   nvbo->kind = (tile_flags & 0x7f00) >> 8;
-   nvbo->comp = (tile_flags & 0x0003) >> 16;
-   if (!nvif_mmu_kind_valid(mmu, nvbo->kind)) {
-   kfree(nvbo);
-   return ERR_PTR(-EINVAL);
-   }
-   } else {
-   nvbo->zeta = (tile_flags & 0x0007);
+   /* for BO allocs, don't assign kinds */
+   if (cli->device.info.family >= NV_DEVICE_INFO_V0_FERMI) {
+   nvbo->kind = (tile_flags & 0xff00) >> 8;
+   if (!nvif_mmu_kind_valid(mmu, nvbo->kind)) {
+   kfree(nvbo);
+   return ERR_PTR(-EINVAL);
+   }
+
+   nvbo->comp = mmu->kind[nvbo->kind] != nvbo->kind;
+   } else if (cli->device.info.family >= NV_DEVICE_INFO_V0_TESLA) {
+   nvbo->kind = (tile_flags & 0x7f00) >> 8;
+   nvbo->comp = (tile_flags & 0x0003) >> 16;
+   if (!nvif_mmu_kind_valid(mmu, nvbo->kind)) {
+   kfree(nvbo);
+   return ERR_PTR(-EINVAL);
}
-   nvbo->mode = tile_mode;
+   } else {
+   nvbo->zeta = (tile_flags & 0x0007);
+   }
+   nvbo->mode = tile_mode;
 
+   if (!nouveau_cli_uvmm(cli) || internal) {
/* Determine the desirable target GPU page size for the buffer. 
*/
for (i = 0; i < vmm->page_nr; i++) {
/* Because we cannot currently allow VMM maps to fail
@@ -304,12 +305,6 @@ nouveau_bo_alloc(struct nouveau_cli *cli, u64 *size, int 
*align, u32 domain,
}
nvbo->page = vmm->page[pi].shift;
} else {
-   /* reject other tile flags when in VM mode. */
-   if (tile_mode)
-   return ERR_PTR(-EINVAL);
-   if (tile_flags & ~NOUVEAU_GEM_TILE_NONCONTIG)
-   return ERR_PTR(-EINVAL);
-
/* Determine the desirable target GPU page size for the buffer. 
*/
for (i = 0; i < vmm->page_nr; i++) {
/* Because we cannot currently allow VMM maps to fail
diff --git a/include/uapi/drm/nouveau_drm.h b/include/uapi/drm/nouveau_drm.h
index cd84227f1..5402f77ee 100644
--- a/include/uapi/drm/nouveau_drm.h
+++ b/include/uapi/drm/nouveau_drm.h
@@ -68,6 +68,13 @@ extern "C" {
  */
 #define NOUVEAU_GETPARAM_VRAM_USED 19
 
+/*
+ * NOUVEAU_GETPARAM_HAS_VMA_TILEMODE
+ *
+ * Query whether tile mode and PTE kind are accepted with VM allocs or not.
+ */
+#define 

[pull] amdgpu, amdkfd drm-fixes-6.9

[Alex Deucher]

Hi Dave, Sima,

Fixes for 6.9.

The following changes since commit dd5a440a31fae6e459c0d627162825505361:

  Linux 6.9-rc7 (2024-05-05 14:06:01 -0700)

are available in the Git repository at:

  https://gitlab.freedesktop.org/agd5f/linux.git 
tags/amd-drm-fixes-6.9-2024-05-08

for you to fetch changes up to 3d09248a06d285397e7b873415505d299202e1c6:

  drm/amdgpu: Fix comparison in amdgpu_res_cpu_visible (2024-05-08 18:47:52 
-0400)


amd-drm-fixes-6.9-2024-05-08:

amdgpu:
- DCN 3.5 fix
- MST DSC fixes
- S0i3 fix
- S4 fix
- Warning fix
- HDP MMIO mapping fix
- Fix a regression in visible vram handling

amdkfd:
- Spatial partition fix


Agustin Gutierrez (2):
  drm/amd/display: Fix DSC-re-computing
  drm/amd/display: MST DSC check for older devices

Alex Deucher (1):
  drm/amdkfd: don't allow mapping the MMIO HDP page with large pages

Lijo Lazar (2):
  Revert "drm/amdkfd: Add partition id field to location_id"
  drm/amd/amdxcp: Fix warnings

Mario Limonciello (1):
  dm/amd/pm: Fix problems with reboot/shutdown for some SMU 13.0.4/13.0.11 
users

Michel Dänzer (1):
  drm/amdgpu: Fix comparison in amdgpu_res_cpu_visible

Nicholas Kazlauskas (1):
  drm/amd/display: Fix idle optimization checks for multi-display and dual 
eDP

Nicholas Susanto (1):
  drm/amd/display: Enable urgent latency adjustments for DCN35

 drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c|  2 +-
 drivers/gpu/drm/amd/amdkfd/kfd_chardev.c   |  7 +++--
 drivers/gpu/drm/amd/amdkfd/kfd_topology.c  |  5 ++--
 drivers/gpu/drm/amd/amdxcp/amdgpu_xcp_drv.c|  2 +-
 .../amd/display/amdgpu_dm/amdgpu_dm_mst_types.c| 16 +--
 .../gpu/drm/amd/display/dc/dml/dcn35/dcn35_fpu.c   |  4 +--
 .../drm/amd/display/dc/hwss/dcn35/dcn35_hwseq.c| 33 ++
 .../gpu/drm/amd/pm/swsmu/smu13/smu_v13_0_4_ppt.c   |  2 +-
 8 files changed, 52 insertions(+), 19 deletions(-)

Re: [PATCH v2 1/2] drm/msm/gen_header: allow skipping the validation

[Doug Anderson]

Hi,

On Fri, May 3, 2024 at 11:15 AM Dmitry Baryshkov
 wrote:
>
> @@ -941,6 +948,7 @@ def main():
> parser = argparse.ArgumentParser()
> parser.add_argument('--rnn', type=str, required=True)
> parser.add_argument('--xml', type=str, required=True)
> +   parser.add_argument('--validate', 
> action=argparse.BooleanOptionalAction)

FWIW, the above (argparse.BooleanOptionalAction) appears to be a
python 3.9 thing. My own build environment happens to have python3
default to python 3.8 and thus I get a build error related to this. I
have no idea what the kernel usually assumes for a baseline, but
others might get build errors too. I don't even see python listed in:

https://docs.kernel.org/process/changes.html

...in any case, if it's easy to change this to not require python3.9
that would at least help for my build environment. :-P

-Doug

Re: [PATCH] drm/msm: remove python 3.9 dependency for compiling msm

[Stephen Boyd]

Quoting Jani Nikula (2024-05-08 01:43:56)
> On Tue, 07 May 2024, Abhinav Kumar  wrote:
> > Since commit 5acf49119630 ("drm/msm: import gen_header.py script from 
> > Mesa"),
> > compilation is broken on machines having python versions older than 3.9
> > due to dependency on argparse.BooleanOptionalAction.
>
> Is it now okay to require Python for the build? Not listed in
> Documentation/process/changes.rst.
>

I doubt it is ok. Perl scripts have been replaced with shell scripts in
the past to speed up the build process. See commit e0e2fa4b515c
("headers_install.pl: convert to headers_install.sh") as an example.

Don't forget, freedesktop.org offers free CoC training for inquiring projects

[Lyude Paul]

Hey everyone! This is just a general reminder that if you're interested
in receiving professional Code of Conduct enforcement training for your
project - freedesktop.org is happy to cover the costs for doing such
training through the wonderful services of https://otter.technology/ .
All that's needed is to send an email to the board, and we can handle
setting up scheduling :).

And of course as always, the Code of Conduct team is always looking for
new volunteers.
-- 
Cheers,
 Lyude Paul (she/her)
 Software Engineer at Red Hat

Re: Safety of opening up /dev/dma_heap/* to physically present users (udev uaccess tag) ?

[Laurent Pinchart]

On Wed, May 08, 2024 at 10:39:58AM +0200, Daniel Vetter wrote:
> On Tue, May 07, 2024 at 10:59:42PM +0300, Dmitry Baryshkov wrote:
> > On Tue, 7 May 2024 at 21:40, Laurent Pinchart wrote:
> > > On Tue, May 07, 2024 at 06:19:18PM +0300, Dmitry Baryshkov wrote:
> > > > On Tue, 7 May 2024 at 18:15, Bryan O'Donoghue wrote:
> > > > > On 07/05/2024 16:09, Dmitry Baryshkov wrote:
> > > > > > Ah, I see. Then why do you require the DMA-ble buffer at all? If 
> > > > > > you are
> > > > > > providing data to VPU or DRM, then you should be able to get the 
> > > > > > buffer
> > > > > > from the data-consuming device.
> > > > >
> > > > > Because we don't necessarily know what the consuming device is, if 
> > > > > any.
> > > > >
> > > > > Could be VPU, could be Zoom/Hangouts via pipewire, could for argument
> > > > > sake be GPU or DSP.
> > > > >
> > > > > Also if we introduce a dependency on another device to allocate the
> > > > > output buffers - say always taking the output buffer from the GPU, 
> > > > > then
> > > > > we've added another dependency which is more difficult to guarantee
> > > > > across different arches.
> > > >
> > > > Yes. And it should be expected. It's a consumer who knows the
> > > > restrictions on the buffer. As I wrote, Zoom/Hangouts should not
> > > > require a DMA buffer at all.
> > >
> > > Why not ? If you want to capture to a buffer that you then compose on
> > > the screen without copying data, dma-buf is the way to go. That's the
> > > Linux solution for buffer sharing.
> > 
> > Yes. But it should be allocated by the DRM driver. As Sima wrote,
> > there is no guarantee that the buffer allocated from dma-heaps is
> > accessible to the GPU.
> > 
> > >
> > > > Applications should be able to allocate
> > > > the buffer out of the generic memory.
> > >
> > > If applications really want to copy data and degrade performance, they
> > > are free to shoot themselves in the foot of course. Applications (or
> > > compositors) need to support copying as a fallback in the worst case,
> > > but all components should at least aim for the zero-copy case.
> > 
> > I'd say that they should aim for the optimal case. It might include
> > both zero-copying access from another DMA master or simple software
> > processing of some kind.
> > 
> > > > GPUs might also have different
> > > > requirements. Consider GPUs with VRAM. It might be beneficial to
> > > > allocate a buffer out of VRAM rather than generic DMA mem.
> > >
> > > Absolutely. For that we need a centralized device memory allocator in
> > > userspace. An effort was started by James Jones in 2016, see [1]. It has
> > > unfortunately stalled. If I didn't have a camera framework to develop, I
> > > would try to tackle that issue :-)
> > 
> > I'll review the talk. However the fact that the effort has stalled
> > most likely means that 'one fits them all' approach didn't really fly
> > well. We have too many usecases.
> 
> I think there's two reasons:
> 
> - It's a really hard problem with many aspects. Where you need to allocate
>   the buffer is just one of the myriad of issues a common allocator needs
>   to solve.

The other large problem is picking up an optimal pixel format. I wonder
if that could be decoupled from the allocation. That could help moving
forward.

> - Every linux-based os has their own solution for these, and the one that
>   suffers most has an entirely different one from everyone else: Android
>   uses binder services to allow apps to make these allocations, keep track
>   of them and make sure there's no abuse. And if there is, it can just
>   nuke the app.

-- 
Regards,

Laurent Pinchart

Re: Safety of opening up /dev/dma_heap/* to physically present users (udev uaccess tag) ?

[Laurent Pinchart]

On Thu, May 09, 2024 at 12:51:08AM +0300, Laurent Pinchart wrote:
> On Wed, May 08, 2024 at 10:36:08AM +0200, Daniel Vetter wrote:
> > On Tue, May 07, 2024 at 04:07:39PM -0400, Nicolas Dufresne wrote:
> > > Le mardi 07 mai 2024 à 21:36 +0300, Laurent Pinchart a écrit :
> > > > Shorter term, we have a problem to solve, and the best option we have
> > > > found so far is to rely on dma-buf heaps as a backend for the frame
> > > > buffer allocatro helper in libcamera for the use case described above.
> > > > This won't work in 100% of the cases, clearly. It's a stop-gap measure
> > > > until we can do better.
> > > 
> > > Considering the security concerned raised on this thread with dmabuf heap
> > > allocation not be restricted by quotas, you'd get what you want quickly 
> > > with
> > > memfd + udmabuf instead (which is accounted already).
> > > 
> > > It was raised that distro don't enable udmabuf, but as stated there by 
> > > Hans, in
> > > any cases distro needs to take action to make the softISP works. This
> > > alternative is easy and does not interfere in anyway with your future 
> > > plan or
> > > the libcamera API. You could even have both dmabuf heap (for Raspbian) 
> > > and the
> > > safer memfd+udmabuf for the distro with security concerns.
> > > 
> > > And for the long term plan, we can certainly get closer by fixing that 
> > > issue
> > > with accounting. This issue also applied to v4l2 io-ops, so it would be 
> > > nice to
> > > find common set of helpers to fix these exporters.
> > 
> > Yeah if this is just for softisp, then memfd + udmabuf is also what I was
> > about to suggest. Not just as a stopgap, but as the real official thing.
> 
> Long term I still want a centralized memory allocator, at which point
> libcamera should stop allocating buffers at all.

And to be clear, udmabuf could be fine for the time being. At least as
long as we don't find any shortcoming while testing it :-)

> > udmabuf does kinda allow you to pin memory, but we can easily fix that by
> > adding the right accounting and then either let mlock rlimits or cgroups
> > kernel memory limits enforce good behavior.

-- 
Regards,

Laurent Pinchart

Re: Safety of opening up /dev/dma_heap/* to physically present users (udev uaccess tag) ?

[Laurent Pinchart]

On Wed, May 08, 2024 at 10:36:08AM +0200, Daniel Vetter wrote:
> On Tue, May 07, 2024 at 04:07:39PM -0400, Nicolas Dufresne wrote:
> > Le mardi 07 mai 2024 à 21:36 +0300, Laurent Pinchart a écrit :
> > > Shorter term, we have a problem to solve, and the best option we have
> > > found so far is to rely on dma-buf heaps as a backend for the frame
> > > buffer allocatro helper in libcamera for the use case described above.
> > > This won't work in 100% of the cases, clearly. It's a stop-gap measure
> > > until we can do better.
> > 
> > Considering the security concerned raised on this thread with dmabuf heap
> > allocation not be restricted by quotas, you'd get what you want quickly with
> > memfd + udmabuf instead (which is accounted already).
> > 
> > It was raised that distro don't enable udmabuf, but as stated there by 
> > Hans, in
> > any cases distro needs to take action to make the softISP works. This
> > alternative is easy and does not interfere in anyway with your future plan 
> > or
> > the libcamera API. You could even have both dmabuf heap (for Raspbian) and 
> > the
> > safer memfd+udmabuf for the distro with security concerns.
> > 
> > And for the long term plan, we can certainly get closer by fixing that issue
> > with accounting. This issue also applied to v4l2 io-ops, so it would be 
> > nice to
> > find common set of helpers to fix these exporters.
> 
> Yeah if this is just for softisp, then memfd + udmabuf is also what I was
> about to suggest. Not just as a stopgap, but as the real official thing.

Long term I still want a centralized memory allocator, at which point
libcamera should stop allocating buffers at all.

> udmabuf does kinda allow you to pin memory, but we can easily fix that by
> adding the right accounting and then either let mlock rlimits or cgroups
> kernel memory limits enforce good behavior.

-- 
Regards,

Laurent Pinchart

[PATCH v2] drm/amd/display: Enable colorspace property for MST connectors

[Mario Limonciello]

MST colorspace property support was disabled due to a series of warnings
that came up when the device was plugged in since the properties weren't
made at device creation. Create the properties in advance instead.

Suggested-by: Ville Syrjälä 
Fixes: 69a959610229 ("drm/amd/display: Temporary Disable MST DP Colorspace 
Property").
Reported-and-tested-by: Tyler Schneider 
Closes: https://gitlab.freedesktop.org/drm/amd/-/issues/3353
Signed-off-by: Mario Limonciello 
---
 drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_mst_types.c | 3 +++
 1 file changed, 3 insertions(+)

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 941e96f100f4..12b036d511d0 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
@@ -613,6 +613,9 @@ dm_dp_add_mst_connector(struct drm_dp_mst_topology_mgr *mgr,
>base,
dev->mode_config.tile_property,
0);
+   connector->colorspace_property = master->base.colorspace_property;
+   if (connector->colorspace_property)
+   drm_connector_attach_colorspace_property(connector);
 
drm_connector_set_path_property(connector, pathprop);
 
-- 
2.43.0

Re: [RFT PATCH v2 00/48] drm/panel: Remove most store/double-check of prepared/enabled state

[Doug Anderson]

Hi,

On Sun, May 5, 2024 at 11:52 PM Linus Walleij  wrote:
>
> On Fri, May 3, 2024 at 11:36 PM Douglas Anderson  
> wrote:
>
> > As talked about in commit d2aacaf07395 ("drm/panel: Check for already
> > prepared/enabled in drm_panel"), we want to remove needless code from
> > panel drivers that was storing and double-checking the
> > prepared/enabled state. Even if someone was relying on the
> > double-check before, that double-check is now in the core and not
> > needed in individual drivers.
> >
> > This series attempts to do just that. While the original grep, AKA:
> >   git grep 'if.*>prepared' -- drivers/gpu/drm/panel
> >   git grep 'if.*>enabled' -- drivers/gpu/drm/panel
> > ...still produces a few hits after my series, they are _mostly_ all
> > gone. The ones that are left are less trivial to fix.
> >
> > One of the main reasons that many panels probably needed to store and
> > double-check their prepared/enabled appears to have been to handle
> > shutdown and/or remove. Panels drivers often wanted to force the power
> > off for panels in these cases and this was a good reason for the
> > double-check.
> >
> > In response to my V1 series [1] we had much discussion of what to
> > do. The conclusion was that as long as DRM modeset drivers properly
> > called drm_atomic_helper_shutdown() that we should be able to remove
> > the explicit shutdown/remove handling in the panel drivers. Most of
> > the patches to improve DRM modeset drivers [2] [3] [4] have now
> > landed.
> >
> > In contrast to my V1 series, I broke the V2 series up a lot
> > more. Since a few of the panel drivers in V1 already landed, we had
> > fewer total drivers and so we could devote a patch to each panel.
> > Also, since we were now relying on DRM modeset drivers I felt like we
> > should split the patches for each panel into two: one that's
> > definitely safe and one that could be reverted if we found a
> > problematic DRM modeset driver that we couldn't fix.
> >
> > Sorry for the large number of patches. I've set things to mostly just
> > CC people on the cover letter and the patches that are relevant to
> > them. I've tried to CC people on the whole series that have shown
> > interest in this TODO item.
> >
> > As patches in this series are reviewed and/or tested they could be
> > landed. There's really no ordering requirement for the series unless
> > patches touch the same driver.
> >
> > NOTE: this touches _a lot_ of drivers, is repetitive, and is not
> > really possible to generate automatically. That means it's entirely
> > possible that my eyes glazed over and I did something wrong. Please
> > double-check me and don't assume that I got everything perfect, though
> > I did my best. I have at least confirmed that "allmodconfig" for arm64
> > doesn't fall on its face with this series. I haven't done a ton of
> > other testing.
> >
> > [1] 
> > https://lore.kernel.org/r/20230804140605.RFC.4.I930069a32baab6faf46d6b234f89613b5cec0f14@changeid
> > [2] https://lore.kernel.org/r/20230901234015.566018-1-diand...@chromium.org
> > [3] https://lore.kernel.org/r/20230901234202.566951-1-diand...@chromium.org
> > [4] https://lore.kernel.org/r/20230921192749.1542462-1-diand...@chromium.org
>
> This is the right thing to do, thanks for looking into this!
>
> As for the behaviour of .remove() I doubt whether in many cases
> the original driver authors have even tested this themselves.

Yeah, I'd tend to agree.


> I would say we should just apply the series as soon as it's non-RFC

It's not actually RFC now, but "RFT" (request for testing). I don't
_think_ there's any need to send a version without the RFT tag before
landing unless someone really feels strongly about it.


> after the next merge window

With drm-misc there's not really any specific reason to wait for the
merge window to open/close as we can land in drm-misc-next at any time
regardless of the merge window. drm-misc-next will simply stop feeding
linuxnext for a while.

That all being said, I'm happy to delay landing this until after the
next -rc1 comes out if people would prefer that. If I don't hear
anything, I guess I'll just wait until -rc1 before landing any of
these.


> and see what happens. I doubt it
> will cause much trouble.

I can land the whole series if that's what everyone agrees on. As I
mentioned above, I'm at least slightly worried that I did something
stupid _somewhere_ in this series since no automation was possible and
with repetitive tasks like this it's super easy to flub something up.
It's _probably_ fine, but I guess I still have the worry in the back
of my mind.

If folks think I should just apply the whole series then I'm happy to
do that. If folks think I should just land parts of the series as they
are reviewed/tested I can do that as well. Let me know. If I don't
hear anything I'd tend to just land patches that are reviewed/tested.
Then after a month or so (hopefully) I'd send out a v2 with anything
left.


> The series:
> Acked-by: Linus Walleij 

Re: [PATCH v2 01/12] drm/amdgpu, drm/radeon: Make I2C terminology more inclusive

[Alex Deucher]

On Wed, May 8, 2024 at 4:12 PM Easwar Hariharan
 wrote:
>
> On 5/8/2024 7:53 AM, Alex Deucher wrote:
> > On Tue, May 7, 2024 at 2:32 PM Easwar Hariharan
> >  wrote:
> >>
> >> On 5/3/2024 11:13 AM, Easwar Hariharan wrote:
> >>> I2C v7, SMBus 3.2, and I3C 1.1.1 specifications have replaced 
> >>> "master/slave"
> >>> with more appropriate terms. Inspired by and following on to Wolfram's
> >>> series to fix drivers/i2c/[1], fix the terminology for users of
> >>> I2C_ALGOBIT bitbanging interface, now that the approved verbiage exists
> >>> in the specification.
> >>>
> >>> Compile tested, no functionality changes intended
> >>>
> >>> [1]: 
> >>> https://lore.kernel.org/all/20240322132619.6389-1-wsa+rene...@sang-engineering.com/
> >>>
> >>> Signed-off-by: Easwar Hariharan 
> >>> ---
> >>>  .../gpu/drm/amd/amdgpu/amdgpu_atomfirmware.c  |  8 +++---
> >>>  drivers/gpu/drm/amd/amdgpu/amdgpu_i2c.c   | 10 +++
> >>>  drivers/gpu/drm/amd/amdgpu/atombios_i2c.c |  8 +++---
> >>>  drivers/gpu/drm/amd/amdgpu/atombios_i2c.h |  2 +-
> >>>  drivers/gpu/drm/amd/amdgpu/smu_v11_0_i2c.c| 20 ++---
> >>>  .../gpu/drm/amd/display/dc/bios/bios_parser.c |  2 +-
> >>>  .../drm/amd/display/dc/bios/bios_parser2.c|  2 +-
> >>>  .../drm/amd/display/dc/core/dc_link_exports.c |  4 +--
> >>>  drivers/gpu/drm/amd/display/dc/dc.h   |  2 +-
> >>>  drivers/gpu/drm/amd/display/dc/dce/dce_i2c.c  |  4 +--
> >>>  .../display/include/grph_object_ctrl_defs.h   |  2 +-
> >>>  drivers/gpu/drm/amd/include/atombios.h|  2 +-
> >>>  drivers/gpu/drm/amd/include/atomfirmware.h| 26 -
> >>>  .../powerplay/hwmgr/vega20_processpptables.c  |  4 +--
> >>>  .../amd/pm/powerplay/inc/smu11_driver_if.h|  2 +-
> >>>  .../inc/pmfw_if/smu11_driver_if_arcturus.h|  2 +-
> >>>  .../inc/pmfw_if/smu11_driver_if_navi10.h  |  2 +-
> >>>  .../pmfw_if/smu11_driver_if_sienna_cichlid.h  |  2 +-
> >>>  .../inc/pmfw_if/smu13_driver_if_aldebaran.h   |  2 +-
> >>>  .../inc/pmfw_if/smu13_driver_if_v13_0_0.h |  2 +-
> >>>  .../inc/pmfw_if/smu13_driver_if_v13_0_7.h |  2 +-
> >>>  .../gpu/drm/amd/pm/swsmu/smu11/arcturus_ppt.c |  4 +--
> >>>  .../amd/pm/swsmu/smu11/sienna_cichlid_ppt.c   |  8 +++---
> >>>  drivers/gpu/drm/radeon/atombios.h | 16 +--
> >>>  drivers/gpu/drm/radeon/atombios_i2c.c |  4 +--
> >>>  drivers/gpu/drm/radeon/radeon_combios.c   | 28 +--
> >>>  drivers/gpu/drm/radeon/radeon_i2c.c   | 10 +++
> >>>  drivers/gpu/drm/radeon/radeon_mode.h  |  6 ++--
> >>>  28 files changed, 93 insertions(+), 93 deletions(-)
> >>>
> >>
> >> 
> >>
> >> Hello Christian, Daniel, David, others,
> >>
> >> Could you re-review v2 since the feedback provided in v0 [1] has now been 
> >> addressed? I can send v3 with
> >> all other feedback and signoffs from the other maintainers incorporated 
> >> when I have something for amdgpu
> >> and radeon.
> >
> > This seems like a lot of churn.  Additionally, a bunch of these
> > headers are shared with other OSes, so it's possible some of the
> > changes may end up getting reverted accidently when we sync up or we
> > may add new headers in new code with the old nomenclature and then
> > we'd need to make sure to adjust it to make sure everything was
> > aligned again.  I would just as soon leave things as is, but I'm open
> > to acking them if there is a strong desire to update things.
> >
> > Alex
>
> The way I see it, this is a small downpayment on the debt we have built up so 
> far. Internship
> programs like LF Outreachy to get more underrepresented groups involved in 
> open source are trying to
> change the open source community culture to be more inclusive, but 
> simultaneously rely on the culture
> being welcoming enough as well.
>
> I do see the challenge involved in preserving the changes and ensuring no new 
> code is added with
> outdated nomenclature (but see [1]), but culture changes one person at a 
> time, and I'd encourage the community
> to do the work needed so we can move past our (mostly) inadvertent role in 
> perpetuating it.
>
> That's my 2c (or your sub-unit currency of choice).

Fair enough.
Acked-by: Aex Deucher 

>
> Easwar
>
> [1] 
> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=49decddd39e5f6132ccd7d9fdc3d7c470b0061bb

Re: [PATCH] fbdev: Have CONFIG_FB_NOTIFY be tristate

[Arnd Bergmann]

On Wed, May 8, 2024, at 22:36, Sam Ravnborg wrote:
>> 
>> I think if you want to do a new version, that is likely to run
>> into new problems, given that this part of fbdev is particularly
>> fragile and partly wrong. On the other hand, it would be nice to
>> have a patch to limit the use of the notifiers to the smallest
>> set of kernel configs that actually need it, and leave it turned
>> off for everything else.
>> 
>> These are the ones I could find:
>> 
>> - CONFIG_GUMSTIX_AM200EPD (FB_EVENT_FB_REGISTERED)
>
> I was surprised to see this driver is still around as many other old
> drivers was nuked as part of the pxa cleanup.
> It is the only user of FB_EVENT_FB_REGISTERED - so a potential cleanup
> if the driver is no longer relevant.

We kept gumstix at the time to give a chance to do a DT conversion
using the qemu model, but so far nobody has worked on this. My
feeling is that we'll end up removing it at some point in the
future along with the other legacy PXA board files. 

Even if someone wants to keep working on gumstix DT support for
qemu, I agree that we can probably remove AM200EPD, AM300EPD
and metronomefb, since those are not even modeled by qemu.

 Arnd

Re: [PATCH v2 6/6] drm/xe/client: Print runtime to fdinfo

[Lucas De Marchi]

On Wed, May 08, 2024 at 09:23:17AM GMT, Tvrtko Ursulin wrote:


On 07/05/2024 22:35, Lucas De Marchi wrote:

On Fri, Apr 26, 2024 at 11:47:37AM GMT, Tvrtko Ursulin wrote:


On 24/04/2024 00:56, Lucas De Marchi wrote:

Print the accumulated runtime for client when printing fdinfo.
Each time a query is done it first does 2 things:

1) loop through all the exec queues for the current client and
   accumulate the runtime, per engine class. CTX_TIMESTAMP is used for
   that, being read from the context image.

2) Read a "GPU timestamp" that can be used for considering "how much GPU
   time has passed" and that has the same unit/refclock as the one
   recording the runtime. RING_TIMESTAMP is used for that via MMIO.

Since for all current platforms RING_TIMESTAMP follows the same
refclock, just read it once, using any first engine.

This is exported to userspace as 2 numbers in fdinfo:

drm-cycles-: 
drm-total-cycles-: 

Userspace is expected to collect at least 2 samples, which allows to
know the client engine busyness as per:

    RUNTIME1 - RUNTIME0
busyness = -
  T1 - T0

Another thing to point out is that it's expected that userspace will
read any 2 samples every few seconds.  Given the update frequency of the
counters involved and that CTX_TIMESTAMP is 32-bits, the counter for
each exec_queue can wrap around (assuming 100% utilization) after ~200s.
The wraparound is not perceived by userspace since it's just accumulated
for all the exec_queues in a 64-bit counter), but the measurement will
not be accurate if the samples are too far apart.

This could be mitigated by adding a workqueue to accumulate the counters
every so often, but it's additional complexity for something that is
done already by userspace every few seconds in tools like gputop (from
igt), htop, nvtop, etc with none of them really defaulting to 1 sample
per minute or more.

Signed-off-by: Lucas De Marchi 
---
 Documentation/gpu/drm-usage-stats.rst   |  16 ++-
 Documentation/gpu/xe/index.rst  |   1 +
 Documentation/gpu/xe/xe-drm-usage-stats.rst |  10 ++
 drivers/gpu/drm/xe/xe_drm_client.c  | 138 +++-
 4 files changed, 162 insertions(+), 3 deletions(-)
 create mode 100644 Documentation/gpu/xe/xe-drm-usage-stats.rst

diff --git a/Documentation/gpu/drm-usage-stats.rst 
b/Documentation/gpu/drm-usage-stats.rst

index 6dc299343b48..421766289b78 100644
--- a/Documentation/gpu/drm-usage-stats.rst
+++ b/Documentation/gpu/drm-usage-stats.rst
@@ -112,6 +112,17 @@ larger value within a reasonable period. 
Upon observing a value lower than what
 was previously read, userspace is expected to stay with that 
larger previous

 value until a monotonic update is seen.
+- drm-total-cycles-: 
+
+Engine identifier string must be the same as the one specified in the
+drm-cycles- tag and shall contain the total number 
cycles for the given

+engine.
+
+This is a timestamp in GPU unspecified unit that matches the 
update rate
+of drm-cycles-. For drivers that implement this 
interface, the engine

+utilization can be calculated entirely on the GPU clock domain, without
+considering the CPU sleep time between 2 samples.


Two opens.

1)
Do we need to explicity document that drm-total-cycles and 
drm-maxfreq are mutually exclusive?


so userspace has a fallback mechanism to calculate utilization depending
on what keys are available?


No, to document all three at once do not make sense. Or at least are 
not expected. Or you envisage someone might legitimately emit all 
three? I don't see what would be the semantics. When we have 
cycles+maxfreq the latter is in Hz. And when we have cycles+total then 
it is unitless. All three?


I don't follow what you mean here. *cycles* is actually a unit.

The engine spent 10 cycles running this context (drm-cycles). In the
same period there were 100 cycles available (drm-total-cycles). Current
frequency is X MHz. Max frequency is Y MHz. For me all of them make
sense if one wants to mix them together. For xe it doesn't make sense
because the counter backing drm-cycles and drm-total-cycles is unrelated
to the engine frequency.

I can add something in the doc that we do not expected to see all of them
together until we see a usecase. Each driver may implement a subset.




2)
Should drm-total-cycles for now be documents as driver specific?


you mean to call it xe-total-cycles?


Yes but it is not an ask, just an open.


Ok, my opinion is that we shouldn't. Just like we have drm-cycles today
implemented by some drivers, but not all. I'd consider the drm-curfreq,
not documented in the drm layer as something to be fixed or migrated to
a driver-only interface (probably not possible anymore as it'd break the
uapi).  Problem I see with turning it into xe-total-cycles, is that the
moment another driver decide to implement they will either have to use
xe- prefix or xe will need to start publishing both keys.
As said above, I can document that it's 

[PATCH v4 8/9] drm/panel: ili9882t: Don't use a table for initting panels

[Douglas Anderson]

Consensus on the mailing lists is that panels shouldn't use a table of
init commands but should instead use init functions. With the recently
introduced mipi_dsi_dcs_write_seq_multi() this is not only clean/easy
but also saves space. Measuring before/after this change:

$ scripts/bloat-o-meter \
  .../before/panel-ilitek-ili9882t.ko \
  .../after/panel-ilitek-ili9882t.ko
add/remove: 3/2 grow/shrink: 0/2 up/down: 6834/-8177 (-1343)
Function old new   delta
starry_ili9882t_init   -6152   +6152
starry_ili9882t_init.d - 678+678
ili9882t_disable.d -   4  +4
ili9882t_disable 260 228 -32
ili9882t_prepare 540 396-144
.compoundliteral 681   --681
starry_ili9882t_init_cmd7320   -   -7320
Total: Before=11928, After=10585, chg -11.26%

Let's do the conversion.

Since we're touching all the tables, let's also convert hex numbers to
lower case as per kernel conventions.

Reviewed-by: Linus Walleij 
Signed-off-by: Douglas Anderson 
---

(no changes since v3)

Changes in v3:
- New

 drivers/gpu/drm/panel/panel-ilitek-ili9882t.c | 794 --
 1 file changed, 368 insertions(+), 426 deletions(-)

diff --git a/drivers/gpu/drm/panel/panel-ilitek-ili9882t.c 
b/drivers/gpu/drm/panel/panel-ilitek-ili9882t.c
index 267a5307041c..58fc1d799371 100644
--- a/drivers/gpu/drm/panel/panel-ilitek-ili9882t.c
+++ b/drivers/gpu/drm/panel/panel-ilitek-ili9882t.c
@@ -15,6 +15,8 @@
 
 #include 
 
+struct ili9882t;
+
 /*
  * Use this descriptor struct to describe different panels using the
  * Ilitek ILI9882T display controller.
@@ -34,7 +36,7 @@ struct panel_desc {
 
unsigned long mode_flags;
enum mipi_dsi_pixel_format format;
-   const struct panel_init_cmd *init_cmds;
+   int (*init)(struct ili9882t *boe);
unsigned int lanes;
 };
 
@@ -52,433 +54,372 @@ struct ili9882t {
struct gpio_desc *enable_gpio;
 };
 
-enum dsi_cmd_type {
-   INIT_DCS_CMD,
-   DELAY_CMD,
-};
-
-struct panel_init_cmd {
-   enum dsi_cmd_type type;
-   size_t len;
-   const char *data;
-};
-
-#define _INIT_DCS_CMD(...) { \
-   .type = INIT_DCS_CMD, \
-   .len = sizeof((char[]){__VA_ARGS__}), \
-   .data = (char[]){__VA_ARGS__} }
-
-#define _INIT_DELAY_CMD(...) { \
-   .type = DELAY_CMD,\
-   .len = sizeof((char[]){__VA_ARGS__}), \
-   .data = (char[]){__VA_ARGS__} }
-
 /* ILI9882-specific commands, add new commands as you decode them */
 #define ILI9882T_DCS_SWITCH_PAGE   0xFF
 
-#define _INIT_SWITCH_PAGE_CMD(page) \
-   _INIT_DCS_CMD(ILI9882T_DCS_SWITCH_PAGE, 0x98, 0x82, (page))
-
-static const struct panel_init_cmd starry_ili9882t_init_cmd[] = {
-   _INIT_DELAY_CMD(5),
-   _INIT_SWITCH_PAGE_CMD(0x01),
-   _INIT_DCS_CMD(0x00, 0x42),
-   _INIT_DCS_CMD(0x01, 0x11),
-   _INIT_DCS_CMD(0x02, 0x00),
-   _INIT_DCS_CMD(0x03, 0x00),
-
-   _INIT_DCS_CMD(0x04, 0x01),
-   _INIT_DCS_CMD(0x05, 0x11),
-   _INIT_DCS_CMD(0x06, 0x00),
-   _INIT_DCS_CMD(0x07, 0x00),
-
-   _INIT_DCS_CMD(0x08, 0x80),
-   _INIT_DCS_CMD(0x09, 0x81),
-   _INIT_DCS_CMD(0x0A, 0x71),
-   _INIT_DCS_CMD(0x0B, 0x00),
-
-   _INIT_DCS_CMD(0x0C, 0x00),
-   _INIT_DCS_CMD(0x0E, 0x1A),
-
-   _INIT_DCS_CMD(0x24, 0x00),
-   _INIT_DCS_CMD(0x25, 0x00),
-   _INIT_DCS_CMD(0x26, 0x00),
-   _INIT_DCS_CMD(0x27, 0x00),
-
-   _INIT_DCS_CMD(0x2C, 0xD4),
-   _INIT_DCS_CMD(0xB9, 0x40),
-
-   _INIT_DCS_CMD(0xB0, 0x11),
-
-   _INIT_DCS_CMD(0xE6, 0x32),
-   _INIT_DCS_CMD(0xD1, 0x30),
-
-   _INIT_DCS_CMD(0xD6, 0x55),
-
-   _INIT_DCS_CMD(0xD0, 0x01),
-   _INIT_DCS_CMD(0xE3, 0x93),
-   _INIT_DCS_CMD(0xE4, 0x00),
-   _INIT_DCS_CMD(0xE5, 0x80),
-
-   _INIT_DCS_CMD(0x31, 0x07),
-   _INIT_DCS_CMD(0x32, 0x07),
-   _INIT_DCS_CMD(0x33, 0x07),
-   _INIT_DCS_CMD(0x34, 0x07),
-   _INIT_DCS_CMD(0x35, 0x07),
-   _INIT_DCS_CMD(0x36, 0x01),
-   _INIT_DCS_CMD(0x37, 0x00),
-   _INIT_DCS_CMD(0x38, 0x28),
-   _INIT_DCS_CMD(0x39, 0x29),
-   _INIT_DCS_CMD(0x3A, 0x11),
-   _INIT_DCS_CMD(0x3B, 0x13),
-   _INIT_DCS_CMD(0x3C, 0x15),
-   _INIT_DCS_CMD(0x3D, 0x17),
-   _INIT_DCS_CMD(0x3E, 0x09),
-   _INIT_DCS_CMD(0x3F, 0x0D),
-   _INIT_DCS_CMD(0x40, 0x02),
-   _INIT_DCS_CMD(0x41, 0x02),
-   _INIT_DCS_CMD(0x42, 0x02),
-   _INIT_DCS_CMD(0x43, 0x02),
-   _INIT_DCS_CMD(0x44, 0x02),
-   _INIT_DCS_CMD(0x45, 0x02),
-   _INIT_DCS_CMD(0x46, 0x02),
-
-   _INIT_DCS_CMD(0x47, 0x07),
-   _INIT_DCS_CMD(0x48, 0x07),
-   _INIT_DCS_CMD(0x49, 0x07),
-   _INIT_DCS_CMD(0x4A, 0x07),
-   _INIT_DCS_CMD(0x4B, 0x07),
-   _INIT_DCS_CMD(0x4C, 0x01),
-   _INIT_DCS_CMD(0x4D, 0x00),
-   

[PATCH v4 9/9] drm/panel: innolux-p079zca: Don't use a table for initting panels

[Douglas Anderson]

Consensus on the mailing lists is that panels shouldn't use a table of
init commands but should instead use init functions. We'll use the
same concepts as the recently introduced
mipi_dsi_generic_write_seq_multi() to make this clean/easy and also
not bloat the driver too much. Measuring before/after this change:

$ scripts/bloat-o-meter \
  .../before/panel-innolux-p079zca.ko \
  .../after/panel-innolux-p079zca.ko
add/remove: 3/2 grow/shrink: 0/1 up/down: 2356/-1944 (412)
Function old new   delta
innolux_p097pfg_init   -1772   +1772
innolux_p097pfg_init.d - 480+480
innolux_panel_write_multi  - 104+104
innolux_panel_prepare412 308-104
.compoundliteral 480   --480
innolux_p097pfg_init_cmds   1360   -   -1360
Total: Before=5802, After=6214, chg +7.10%

Note that, unlike some other drivers, we actually make this panel
driver _bigger_ by using the new functions. This is because the
innolux-p079zca panel driver didn't have as complex of a table and
thus the old table was more efficient than the code. The bloat is
still not giant (only 412 bytes).

Also note that we can't direclty use
mipi_dsi_generic_write_seq_multi() here because we need to deal with
the crazy "nop" that this driver sends after all commands. This means
that we have to write code that is "inspired" by the new macros.

Since we're touching all the tables, let's also convert hex numbers to
lower case as per kernel conventions.

Reviewed-by: Linus Walleij 
Signed-off-by: Douglas Anderson 
---

Changes in v4:
- Test to see if init is non-NULL before using it.

Changes in v3:
- New

 drivers/gpu/drm/panel/panel-innolux-p079zca.c | 284 +-
 1 file changed, 140 insertions(+), 144 deletions(-)

diff --git a/drivers/gpu/drm/panel/panel-innolux-p079zca.c 
b/drivers/gpu/drm/panel/panel-innolux-p079zca.c
index 485178a99910..ade8bf7491ee 100644
--- a/drivers/gpu/drm/panel/panel-innolux-p079zca.c
+++ b/drivers/gpu/drm/panel/panel-innolux-p079zca.c
@@ -17,14 +17,7 @@
 #include 
 #include 
 
-struct panel_init_cmd {
-   size_t len;
-   const char *data;
-};
-
-#define _INIT_CMD(...) { \
-   .len = sizeof((char[]){__VA_ARGS__}), \
-   .data = (char[]){__VA_ARGS__} }
+struct innolux_panel;
 
 struct panel_desc {
const struct drm_display_mode *mode;
@@ -36,7 +29,7 @@ struct panel_desc {
 
unsigned long flags;
enum mipi_dsi_pixel_format format;
-   const struct panel_init_cmd *init_cmds;
+   int (*init)(struct innolux_panel *innolux);
unsigned int lanes;
const char * const *supply_names;
unsigned int num_supplies;
@@ -132,32 +125,10 @@ static int innolux_panel_prepare(struct drm_panel *panel)
/* p079zca: t4, p097pfg: t5 */
usleep_range(2, 21000);
 
-   if (innolux->desc->init_cmds) {
-   const struct panel_init_cmd *cmds =
-   innolux->desc->init_cmds;
-   unsigned int i;
-
-   for (i = 0; cmds[i].len != 0; i++) {
-   const struct panel_init_cmd *cmd = [i];
-
-   err = mipi_dsi_generic_write(innolux->link, cmd->data,
-cmd->len);
-   if (err < 0) {
-   dev_err(panel->dev, "failed to write command 
%u\n", i);
-   goto poweroff;
-   }
-
-   /*
-* Included by random guessing, because without this
-* (or at least, some delay), the panel sometimes
-* didn't appear to pick up the command sequence.
-*/
-   err = mipi_dsi_dcs_nop(innolux->link);
-   if (err < 0) {
-   dev_err(panel->dev, "failed to send DCS nop: 
%d\n", err);
-   goto poweroff;
-   }
-   }
+   if (innolux->desc->init) {
+   err = innolux->desc->init(innolux);
+   if (err < 0)
+   goto poweroff;
}
 
err = mipi_dsi_dcs_exit_sleep_mode(innolux->link);
@@ -250,119 +221,144 @@ static const struct drm_display_mode 
innolux_p097pfg_mode = {
.vtotal = 2048 + 100 + 2 + 18,
 };
 
+static void innolux_panel_write_multi(struct mipi_dsi_multi_context *ctx,
+ const void *payload, size_t size)
+{
+   struct mipi_dsi_device *dsi = ctx->dsi;
+   struct device *dev = >dev;
+
+   mipi_dsi_generic_write_multi(ctx, payload, size);
+   if (ctx->accum_err)
+   return;
+
+   /*
+* Included by random guessing, because without this
+* (or at least, some delay), 

[PATCH v4 7/9] drm/panel: boe-tv101wum-nl6: Don't use a table for initting panels

[Douglas Anderson]

Consensus on the mailing lists is that panels shouldn't use a table of
init commands but should instead use init functions. With the recently
introduced mipi_dsi_dcs_write_seq_multi() this is not only clean/easy
but also saves space. Measuring before/after this change:

$ scripts/bloat-o-meter \
  .../before/panel-boe-tv101wum-nl6.ko \
  .../after/panel-boe-tv101wum-nl6.ko
add/remove: 14/8 grow/shrink: 0/1 up/down: 27062/-31433 (-4371)
Function old new   delta
inx_hj110iz_init   -7040   +7040
boe_tv110c9m_init  -6440   +6440
boe_init   -5916   +5916
starry_qfh032011_53g_init  -1944   +1944
starry_himax83102_j02_init -1228   +1228
inx_hj110iz_init.d -1040   +1040
boe_tv110c9m_init.d- 982+982
auo_b101uan08_3_init   - 944+944
boe_init.d - 580+580
starry_himax83102_j02_init.d   - 512+512
starry_qfh032011_53g_init.d- 180+180
auo_kd101n80_45na_init - 172+172
auo_b101uan08_3_init.d -  82 +82
auo_kd101n80_45na_init.d   -   2  +2
auo_kd101n80_45na_init_cmd   144   --144
boe_panel_prepare592 440-152
auo_b101uan08_3_init_cmd1056   -   -1056
starry_himax83102_j02_init_cmd  1392   -   -1392
starry_qfh032011_53g_init_cmd   2256   -   -2256
.compoundliteral3393   -   -3393
boe_init_cmd7008   -   -7008
boe_tv110c9m_init_cmd   7656   -   -7656
inx_hj110iz_init_cmd8376   -   -8376
Total: Before=37297, After=32926, chg -11.72%

Let's do the conversion.

Since we're touching all the tables, let's also convert hex numbers to
lower case as per kernel conventions.

Reviewed-by: Linus Walleij 
Signed-off-by: Douglas Anderson 
---

(no changes since v3)

Changes in v3:
- Fix spacing of init function.
- Remove an unneeded error print.
- Squash boe-tv101wum-nl6 lowercase patch into main patch

Changes in v2:
- New

 .../gpu/drm/panel/panel-boe-tv101wum-nl6.c| 2792 +
 1 file changed, 1442 insertions(+), 1350 deletions(-)

diff --git a/drivers/gpu/drm/panel/panel-boe-tv101wum-nl6.c 
b/drivers/gpu/drm/panel/panel-boe-tv101wum-nl6.c
index 0ffe8f8c01de..aab60cec0603 100644
--- a/drivers/gpu/drm/panel/panel-boe-tv101wum-nl6.c
+++ b/drivers/gpu/drm/panel/panel-boe-tv101wum-nl6.c
@@ -17,6 +17,8 @@
 
 #include 
 
+struct boe_panel;
+
 struct panel_desc {
const struct drm_display_mode *modes;
unsigned int bpc;
@@ -32,7 +34,7 @@ struct panel_desc {
 
unsigned long mode_flags;
enum mipi_dsi_pixel_format format;
-   const struct panel_init_cmd *init_cmds;
+   int (*init)(struct boe_panel *boe);
unsigned int lanes;
bool discharge_on_disable;
bool lp11_before_reset;
@@ -54,1318 +56,1449 @@ struct boe_panel {
bool prepared;
 };
 
-enum dsi_cmd_type {
-   INIT_DCS_CMD,
-   DELAY_CMD,
-};
+static int boe_tv110c9m_init(struct boe_panel *boe)
+{
+   struct mipi_dsi_multi_context ctx = { .dsi = boe->dsi };
+
+   mipi_dsi_dcs_write_seq_multi(, 0xff, 0x20);
+   mipi_dsi_dcs_write_seq_multi(, 0xfb, 0x01);
+   mipi_dsi_dcs_write_seq_multi(, 0x05, 0xd9);
+   mipi_dsi_dcs_write_seq_multi(, 0x07, 0x78);
+   mipi_dsi_dcs_write_seq_multi(, 0x08, 0x5a);
+   mipi_dsi_dcs_write_seq_multi(, 0x0d, 0x63);
+   mipi_dsi_dcs_write_seq_multi(, 0x0e, 0x91);
+   mipi_dsi_dcs_write_seq_multi(, 0x0f, 0x73);
+   mipi_dsi_dcs_write_seq_multi(, 0x95, 0xe6);
+   mipi_dsi_dcs_write_seq_multi(, 0x96, 0xf0);
+   mipi_dsi_dcs_write_seq_multi(, 0x30, 0x00);
+   mipi_dsi_dcs_write_seq_multi(, 0x6d, 0x66);
+   mipi_dsi_dcs_write_seq_multi(, 0x75, 0xa2);
+   mipi_dsi_dcs_write_seq_multi(, 0x77, 0x3b);
+
+   mipi_dsi_dcs_write_seq_multi(, 0xb0, 0x00, 0x08, 0x00, 0x23, 0x00, 
0x4d, 0x00, 0x6d,
+0x00, 0x89, 0x00, 0xa1, 0x00, 0xb6, 0x00, 
0xc9);
+   mipi_dsi_dcs_write_seq_multi(, 0xb1, 0x00, 0xda, 0x01, 0x13, 0x01, 
0x3c, 0x01, 0x7e,
+0x01, 0xab, 0x01, 0xf7, 0x02, 0x2f, 0x02, 
0x31);
+   mipi_dsi_dcs_write_seq_multi(, 0xb2, 0x02, 0x67, 0x02, 0xa6, 0x02, 
0xd1, 0x03, 0x08,
+0x03, 0x2e, 0x03, 0x5b, 0x03, 0x6b, 0x03, 
0x7b);
+   mipi_dsi_dcs_write_seq_multi(, 0xb3, 0x03, 0x8e, 0x03, 0xa2, 0x03, 
0xb7, 0x03, 0xe7,
+0x03, 0xfd, 0x03, 0xff);
+
+   

[PATCH v4 6/9] drm/panel: novatek-nt36672e: Switch to mipi_dsi_dcs_write_seq_multi()

[Douglas Anderson]

This is a mechanical conversion of the novatek-nt36672e driver to use
the new mipi_dsi_dcs_write_seq_multi(). The new function is easier for
clients to understand and using it also causes smaller code to be
generated. Specifically:

$ scripts/bloat-o-meter \
  ...after/panel-novatek-nt36672e.ko \
  ...ctx/panel-novatek-nt36672e.ko
add/remove: 0/0 grow/shrink: 0/1 up/down: 0/-988 (-988)
Function old new   delta
nt36672e_1080x2408_60hz_init62365248-988
Total: Before=10651, After=9663, chg -9.28%

Cc: Ritesh Kumar 
Signed-off-by: Douglas Anderson 
---
This change is only compile tested. I don't use this panel myself but
arbitrarily picked it as an example to look at when working on the
MIPI DSI macros.

NOTE: as of the posting of v4 this change still has no tags. Without
any tags (Reviewed-by/Tested-by/Acked-by) I won't actually land this
change even if the rest of the series lands.

(no changes since v3)

Changes in v3:
- Fix spacing of init function.

Changes in v2:
- New

 .../gpu/drm/panel/panel-novatek-nt36672e.c| 576 +-
 1 file changed, 289 insertions(+), 287 deletions(-)

diff --git a/drivers/gpu/drm/panel/panel-novatek-nt36672e.c 
b/drivers/gpu/drm/panel/panel-novatek-nt36672e.c
index 20b7bfe4aa12..9ce8df455232 100644
--- a/drivers/gpu/drm/panel/panel-novatek-nt36672e.c
+++ b/drivers/gpu/drm/panel/panel-novatek-nt36672e.c
@@ -51,293 +51,295 @@ static inline struct nt36672e_panel 
*to_nt36672e_panel(struct drm_panel *panel)
 
 static int nt36672e_1080x2408_60hz_init(struct mipi_dsi_device *dsi)
 {
-   mipi_dsi_dcs_write_seq(dsi, 0xff, 0x10);
-   mipi_dsi_dcs_write_seq(dsi, 0xfb, 0x01);
-   mipi_dsi_dcs_write_seq(dsi, 0xb0, 0x00);
-   mipi_dsi_dcs_write_seq(dsi, 0xc0, 0x00);
-   mipi_dsi_dcs_write_seq(dsi, 0xc1, 0x89, 0x28, 0x00, 0x08, 0x00, 0xaa, 
0x02,
-   0x0e, 0x00, 0x2b, 0x00, 0x07, 0x0d, 0xb7, 0x0c, 
0xb7);
-
-   mipi_dsi_dcs_write_seq(dsi, 0xc2, 0x1b, 0xa0);
-   mipi_dsi_dcs_write_seq(dsi, 0xff, 0x20);
-   mipi_dsi_dcs_write_seq(dsi, 0xfb, 0x01);
-   mipi_dsi_dcs_write_seq(dsi, 0x01, 0x66);
-   mipi_dsi_dcs_write_seq(dsi, 0x06, 0x40);
-   mipi_dsi_dcs_write_seq(dsi, 0x07, 0x38);
-   mipi_dsi_dcs_write_seq(dsi, 0x2f, 0x83);
-   mipi_dsi_dcs_write_seq(dsi, 0x69, 0x91);
-   mipi_dsi_dcs_write_seq(dsi, 0x95, 0xd1);
-   mipi_dsi_dcs_write_seq(dsi, 0x96, 0xd1);
-   mipi_dsi_dcs_write_seq(dsi, 0xf2, 0x64);
-   mipi_dsi_dcs_write_seq(dsi, 0xf3, 0x54);
-   mipi_dsi_dcs_write_seq(dsi, 0xf4, 0x64);
-   mipi_dsi_dcs_write_seq(dsi, 0xf5, 0x54);
-   mipi_dsi_dcs_write_seq(dsi, 0xf6, 0x64);
-   mipi_dsi_dcs_write_seq(dsi, 0xf7, 0x54);
-   mipi_dsi_dcs_write_seq(dsi, 0xf8, 0x64);
-   mipi_dsi_dcs_write_seq(dsi, 0xf9, 0x54);
-   mipi_dsi_dcs_write_seq(dsi, 0xff, 0x24);
-   mipi_dsi_dcs_write_seq(dsi, 0xfb, 0x01);
-   mipi_dsi_dcs_write_seq(dsi, 0x01, 0x0f);
-   mipi_dsi_dcs_write_seq(dsi, 0x03, 0x0c);
-   mipi_dsi_dcs_write_seq(dsi, 0x05, 0x1d);
-   mipi_dsi_dcs_write_seq(dsi, 0x08, 0x2f);
-   mipi_dsi_dcs_write_seq(dsi, 0x09, 0x2e);
-   mipi_dsi_dcs_write_seq(dsi, 0x0a, 0x2d);
-   mipi_dsi_dcs_write_seq(dsi, 0x0b, 0x2c);
-   mipi_dsi_dcs_write_seq(dsi, 0x11, 0x17);
-   mipi_dsi_dcs_write_seq(dsi, 0x12, 0x13);
-   mipi_dsi_dcs_write_seq(dsi, 0x13, 0x15);
-   mipi_dsi_dcs_write_seq(dsi, 0x15, 0x14);
-   mipi_dsi_dcs_write_seq(dsi, 0x16, 0x16);
-   mipi_dsi_dcs_write_seq(dsi, 0x17, 0x18);
-   mipi_dsi_dcs_write_seq(dsi, 0x1b, 0x01);
-   mipi_dsi_dcs_write_seq(dsi, 0x1d, 0x1d);
-   mipi_dsi_dcs_write_seq(dsi, 0x20, 0x2f);
-   mipi_dsi_dcs_write_seq(dsi, 0x21, 0x2e);
-   mipi_dsi_dcs_write_seq(dsi, 0x22, 0x2d);
-   mipi_dsi_dcs_write_seq(dsi, 0x23, 0x2c);
-   mipi_dsi_dcs_write_seq(dsi, 0x29, 0x17);
-   mipi_dsi_dcs_write_seq(dsi, 0x2a, 0x13);
-   mipi_dsi_dcs_write_seq(dsi, 0x2b, 0x15);
-   mipi_dsi_dcs_write_seq(dsi, 0x2f, 0x14);
-   mipi_dsi_dcs_write_seq(dsi, 0x30, 0x16);
-   mipi_dsi_dcs_write_seq(dsi, 0x31, 0x18);
-   mipi_dsi_dcs_write_seq(dsi, 0x32, 0x04);
-   mipi_dsi_dcs_write_seq(dsi, 0x34, 0x10);
-   mipi_dsi_dcs_write_seq(dsi, 0x35, 0x1f);
-   mipi_dsi_dcs_write_seq(dsi, 0x36, 0x1f);
-   mipi_dsi_dcs_write_seq(dsi, 0x4d, 0x14);
-   mipi_dsi_dcs_write_seq(dsi, 0x4e, 0x36);
-   mipi_dsi_dcs_write_seq(dsi, 0x4f, 0x36);
-   mipi_dsi_dcs_write_seq(dsi, 0x53, 0x36);
-   mipi_dsi_dcs_write_seq(dsi, 0x71, 0x30);
-   mipi_dsi_dcs_write_seq(dsi, 0x79, 0x11);
-   mipi_dsi_dcs_write_seq(dsi, 0x7a, 0x82);
-   mipi_dsi_dcs_write_seq(dsi, 0x7b, 0x8f);
-   mipi_dsi_dcs_write_seq(dsi, 0x7d, 0x04);
-   mipi_dsi_dcs_write_seq(dsi, 0x80, 0x04);
-   mipi_dsi_dcs_write_seq(dsi, 0x81, 0x04);
-   mipi_dsi_dcs_write_seq(dsi, 0x82, 0x13);
-   

[PATCH v4 5/9] drm/mipi-dsi: Introduce mipi_dsi_*_write_seq_multi()

[Douglas Anderson]

The current mipi_dsi_*_write_seq() macros are non-intutitive because
they contain a hidden "return" statement that will return out of the
_caller_ of the macro. Let's mark them as deprecated and instead
introduce some new macros that are more intuitive.

These new macros are less optimal when an error occurs but should
behave more optimally when there is no error. Specifically these new
macros cause smaller code to get generated and the code size savings
(less to fetch from RAM, less cache space used, less RAM used) are
important. Since the error case isn't something we need to optimize
for and these new macros are easier to understand and more flexible,
they should be used.

After converting to use these new functions, one example shows some
nice savings while also being easier to understand.

$ scripts/bloat-o-meter \
  ...after/panel-novatek-nt36672e.ko \
  ...ctx/panel-novatek-nt36672e.ko
add/remove: 0/0 grow/shrink: 0/1 up/down: 0/-988 (-988)
Function old new   delta
nt36672e_1080x2408_60hz_init62365248-988
Total: Before=10651, After=9663, chg -9.28%

Reviewed-by: Neil Armstrong 
Reviewed-by: Linus Walleij 
Signed-off-by: Douglas Anderson 
---
Right now this patch introduces two new functions in drm_mipi_dsi.c.
Alternatively we could have changed the prototype of the "chatty"
functions and made the deprecated macros adapt to the new prototype.
While this sounds nice, it bloated callers of the deprecated functioin
a bit because it caused the compiler to emit less optimal code. It
doesn't seem terrible to add two more functions, so I went that
way. There may be cases where callers who aren't writing many
sequences prefer to use the "chatty" versions anyway.

(no changes since v3)

Changes in v3:
- Add a TODO item for cleaning up the deprecated macros/functions.
- Inline kerneldoc comments for struct mipi_dsi_multi_context.

Changes in v2:
- New

 Documentation/gpu/todo.rst | 18 ++
 drivers/gpu/drm/drm_mipi_dsi.c | 56 ++
 include/drm/drm_mipi_dsi.h | 62 ++
 3 files changed, 136 insertions(+)

diff --git a/Documentation/gpu/todo.rst b/Documentation/gpu/todo.rst
index e2a0585915b3..2734b8a34541 100644
--- a/Documentation/gpu/todo.rst
+++ b/Documentation/gpu/todo.rst
@@ -494,6 +494,24 @@ Contact: Douglas Anderson 
 
 Level: Starter/Intermediate
 
+Transition away from using mipi_dsi_*_write_seq()
+-
+
+The macros mipi_dsi_generic_write_seq() and mipi_dsi_dcs_write_seq() are
+non-intuitive because, if there are errors, they return out of the *caller's*
+function. We should move all callers to use mipi_dsi_generic_write_seq_multi()
+and mipi_dsi_dcs_write_seq_multi() macros instead.
+
+Once all callers are transitioned, the macros and the functions that they call,
+mipi_dsi_generic_write_chatty() and mipi_dsi_dcs_write_buffer_chatty(), can
+probably be removed. Alternatively, if people feel like the _multi() variants
+are overkill for some use cases, we could keep the mipi_dsi_*_write_seq()
+variants but change them not to return out of the caller.
+
+Contact: Douglas Anderson 
+
+Level: Starter
+
 
 Core refactorings
 =
diff --git a/drivers/gpu/drm/drm_mipi_dsi.c b/drivers/gpu/drm/drm_mipi_dsi.c
index 8593d9ed5891..d2957cb692d3 100644
--- a/drivers/gpu/drm/drm_mipi_dsi.c
+++ b/drivers/gpu/drm/drm_mipi_dsi.c
@@ -792,6 +792,34 @@ int mipi_dsi_generic_write_chatty(struct mipi_dsi_device 
*dsi,
 }
 EXPORT_SYMBOL(mipi_dsi_generic_write_chatty);
 
+/**
+ * mipi_dsi_generic_write_multi() - mipi_dsi_generic_write_chatty() w/ 
accum_err
+ * @ctx: Context for multiple DSI transactions
+ * @payload: buffer containing the payload
+ * @size: size of payload buffer
+ *
+ * Like mipi_dsi_generic_write_chatty() but deals with errors in a way that
+ * makes it convenient to make several calls in a row.
+ */
+void mipi_dsi_generic_write_multi(struct mipi_dsi_multi_context *ctx,
+ const void *payload, size_t size)
+{
+   struct mipi_dsi_device *dsi = ctx->dsi;
+   struct device *dev = >dev;
+   ssize_t ret;
+
+   if (ctx->accum_err)
+   return;
+
+   ret = mipi_dsi_generic_write(dsi, payload, size);
+   if (ret < 0) {
+   ctx->accum_err = ret;
+   dev_err(dev, "sending generic data %*ph failed: %d\n",
+   (int)size, payload, ctx->accum_err);
+   }
+}
+EXPORT_SYMBOL(mipi_dsi_generic_write_multi);
+
 /**
  * mipi_dsi_generic_read() - receive data using a generic read packet
  * @dsi: DSI peripheral device
@@ -908,6 +936,34 @@ int mipi_dsi_dcs_write_buffer_chatty(struct 
mipi_dsi_device *dsi,
 }
 EXPORT_SYMBOL(mipi_dsi_dcs_write_buffer_chatty);
 
+/**
+ * mipi_dsi_dcs_write_buffer_multi - mipi_dsi_dcs_write_buffer_chatty() w/ 
accum_err
+ * @ctx: Context for multiple DSI transactions
+ * @data: buffer containing 

[PATCH v4 4/9] drm/mipi-dsi: Reduce driver bloat of mipi_dsi_*_write_seq()

[Douglas Anderson]

Through a cooperative effort between Hsin-Yi Wang and Dmitry
Baryshkov, we have realized the dev_err() in the
mipi_dsi_*_write_seq() macros was causing quite a bit of bloat to the
kernel. Let's hoist this call into drm_mipi_dsi.c by adding a "chatty"
version of the functions that includes the print. While doing this,
add a bit more comments to these macros making it clear that they
print errors and also that they return out of _the caller's_ function.

Without any changes to clients this gives a nice savings. Specifically
the macro was inlined and thus the error report call was inlined into
every call to mipi_dsi_dcs_write_seq() and
mipi_dsi_generic_write_seq(). By using a call to a "chatty" function,
the usage is reduced to one call in the chatty function and a function
call at the invoking site.

Building with my build system shows one example:

$ scripts/bloat-o-meter \
  .../before/panel-novatek-nt36672e.ko \
  .../after/panel-novatek-nt36672e.ko
add/remove: 0/0 grow/shrink: 0/1 up/down: 0/-4404 (-4404)
Function old new   delta
nt36672e_1080x2408_60hz_init   106406236   -4404
Total: Before=15055, After=10651, chg -29.25%

Note that given the change in location of the print it's harder to
include the "cmd" in the printout for mipi_dsi_dcs_write_seq() since,
theoretically, someone could call the new chatty function with a
zero-size array and it would be illegal to dereference data[0].
There's a printk format to print the whole buffer and this is probably
more useful for debugging anyway. Given that we're doing this for
mipi_dsi_dcs_write_seq(), let's also print the buffer for
mipi_dsi_generic_write_seq() in the error case.

It should be noted that the current consensus of DRM folks is that the
mipi_dsi_*_write_seq() should be deprecated due to the non-intuitive
return behavior. A future patch will formally mark them as deprecated
and provide an alternative.

Reviewed-by: Dmitry Baryshkov 
Reviewed-by: Neil Armstrong 
Reviewed-by: Linus Walleij 
Signed-off-by: Douglas Anderson 
---

Changes in v4:
- Update wording as per Linus W.

Changes in v3:
- Rebased upon patch to remove ratelimit of prints.

Changes in v2:
- Add some comments to the macros about printing and returning.
- Change the way err value is handled in prep for next patch.
- Modify commit message now that this is part of a series.
- Rebased upon patches to avoid theoretical int overflow.

 drivers/gpu/drm/drm_mipi_dsi.c | 56 ++
 include/drm/drm_mipi_dsi.h | 47 +++-
 2 files changed, 82 insertions(+), 21 deletions(-)

diff --git a/drivers/gpu/drm/drm_mipi_dsi.c b/drivers/gpu/drm/drm_mipi_dsi.c
index 795001bb7ff1..8593d9ed5891 100644
--- a/drivers/gpu/drm/drm_mipi_dsi.c
+++ b/drivers/gpu/drm/drm_mipi_dsi.c
@@ -764,6 +764,34 @@ ssize_t mipi_dsi_generic_write(struct mipi_dsi_device 
*dsi, const void *payload,
 }
 EXPORT_SYMBOL(mipi_dsi_generic_write);
 
+/**
+ * mipi_dsi_generic_write_chatty() - mipi_dsi_generic_write() w/ an error log
+ * @dsi: DSI peripheral device
+ * @payload: buffer containing the payload
+ * @size: size of payload buffer
+ *
+ * Like mipi_dsi_generic_write() but includes a dev_err_ratelimited()
+ * call for you and returns 0 upon success, not the number of bytes sent.
+ *
+ * Return: 0 on success or a negative error code on failure.
+ */
+int mipi_dsi_generic_write_chatty(struct mipi_dsi_device *dsi,
+ const void *payload, size_t size)
+{
+   struct device *dev = >dev;
+   ssize_t ret;
+
+   ret = mipi_dsi_generic_write(dsi, payload, size);
+   if (ret < 0) {
+   dev_err(dev, "sending generic data %*ph failed: %zd\n",
+   (int)size, payload, ret);
+   return ret;
+   }
+
+   return 0;
+}
+EXPORT_SYMBOL(mipi_dsi_generic_write_chatty);
+
 /**
  * mipi_dsi_generic_read() - receive data using a generic read packet
  * @dsi: DSI peripheral device
@@ -852,6 +880,34 @@ ssize_t mipi_dsi_dcs_write_buffer(struct mipi_dsi_device 
*dsi,
 }
 EXPORT_SYMBOL(mipi_dsi_dcs_write_buffer);
 
+/**
+ * mipi_dsi_dcs_write_buffer_chatty - mipi_dsi_dcs_write_buffer() w/ an error 
log
+ * @dsi: DSI peripheral device
+ * @data: buffer containing data to be transmitted
+ * @len: size of transmission buffer
+ *
+ * Like mipi_dsi_dcs_write_buffer() but includes a dev_err_ratelimited()
+ * call for you and returns 0 upon success, not the number of bytes sent.
+ *
+ * Return: 0 on success or a negative error code on failure.
+ */
+int mipi_dsi_dcs_write_buffer_chatty(struct mipi_dsi_device *dsi,
+const void *data, size_t len)
+{
+   struct device *dev = >dev;
+   ssize_t ret;
+
+   ret = mipi_dsi_dcs_write_buffer(dsi, data, len);
+   if (ret < 0) {
+   dev_err(dev, "sending dcs data %*ph failed: %zd\n",
+   (int)len, data, ret);
+   return ret;
+   

[PATCH v4 3/9] drm/mipi-dsi: mipi_dsi_*_write functions don't need to ratelimit prints

[Douglas Anderson]

We really don't expect these errors to be printed over and over
again. When a driver hits the error it should bail out. Just use a
normal error print.

This gives a nice space savings for users of these functions:

$ scripts/bloat-o-meter \
  .../before/panel-novatek-nt36672e.ko \
  .../after/panel-novatek-nt36672e.ko
add/remove: 0/1 grow/shrink: 0/1 up/down: 0/-16760 (-16760)
Function old new   delta
nt36672e_1080x2408_60hz_init   17080   10640   -6440
nt36672e_1080x2408_60hz_init._rs   10320   -  -10320
Total: Before=31815, After=15055, chg -52.68%

Reviewed-by: Neil Armstrong 
Reviewed-by: Linus Walleij 
Signed-off-by: Douglas Anderson 
---

(no changes since v3)

Changes in v3:
- ("mipi_dsi_*_write functions don't need to ratelimit...") moved earlier.

Changes in v2:
- New

 include/drm/drm_mipi_dsi.h | 24 +++-
 1 file changed, 11 insertions(+), 13 deletions(-)

diff --git a/include/drm/drm_mipi_dsi.h b/include/drm/drm_mipi_dsi.h
index e0f56564bf97..67967be48dbd 100644
--- a/include/drm/drm_mipi_dsi.h
+++ b/include/drm/drm_mipi_dsi.h
@@ -314,17 +314,16 @@ int mipi_dsi_dcs_get_display_brightness_large(struct 
mipi_dsi_device *dsi,
  * @dsi: DSI peripheral device
  * @seq: buffer containing the payload
  */
-#define mipi_dsi_generic_write_seq(dsi, seq...)
 \
-   do {
\
-   static const u8 d[] = { seq };  
\
-   struct device *dev = >dev; 
\
-   ssize_t ret;
\
-   ret = mipi_dsi_generic_write(dsi, d, ARRAY_SIZE(d));
\
-   if (ret < 0) {  
\
-   dev_err_ratelimited(dev, "transmit data failed: %zd\n", 
\
-   ret);   
\
-   return ret; 
\
-   }   
\
+#define mipi_dsi_generic_write_seq(dsi, seq...)   \
+   do {  \
+   static const u8 d[] = { seq };\
+   struct device *dev = >dev;   \
+   ssize_t ret;  \
+   ret = mipi_dsi_generic_write(dsi, d, ARRAY_SIZE(d));  \
+   if (ret < 0) {\
+   dev_err(dev, "transmit data failed: %zd\n", ret); \
+   return ret;   \
+   } \
} while (0)
 
 /**
@@ -340,8 +339,7 @@ int mipi_dsi_dcs_get_display_brightness_large(struct 
mipi_dsi_device *dsi,
ssize_t ret;\
ret = mipi_dsi_dcs_write_buffer(dsi, d, ARRAY_SIZE(d)); \
if (ret < 0) {  \
-   dev_err_ratelimited(\
-   dev, "sending command %#02x failed: %zd\n", \
+   dev_err(dev, "sending command %#02x failed: %zd\n", \
cmd, ret);  \
return ret; \
}   \
-- 
2.45.0.rc1.225.g2a3ae87e7f-goog

[PATCH v4 2/9] drm/mipi-dsi: Fix theoretical int overflow in mipi_dsi_generic_write_seq()

[Douglas Anderson]

The mipi_dsi_generic_write_seq() macro makes a call to
mipi_dsi_generic_write() which returns a type ssize_t. The macro then
stores it in an int and checks to see if it's negative. This could
theoretically be a problem if "ssize_t" is larger than "int".

To see the issue, imagine that "ssize_t" is 32-bits and "int" is
16-bits, you could see a problem if there was some code out there that
looked like:

  mipi_dsi_generic_write_seq(dsi, <32768 bytes as arguments>);

...since we'd get back that 32768 bytes were transferred and 32768
stored in a 16-bit int would look negative.

Though there are no callsites where we'd actually hit this (even if
"int" was only 16-bit), it's cleaner to make the types match so let's
fix it.

Fixes: a9015ce59320 ("drm/mipi-dsi: Add a mipi_dsi_dcs_write_seq() macro")
Reviewed-by: Neil Armstrong 
Reviewed-by: Linus Walleij 
Signed-off-by: Douglas Anderson 
---

(no changes since v3)

Changes in v3:
- Use %zd in print instead of casting errors to int.

Changes in v2:
- New

 include/drm/drm_mipi_dsi.h | 22 +++---
 1 file changed, 11 insertions(+), 11 deletions(-)

diff --git a/include/drm/drm_mipi_dsi.h b/include/drm/drm_mipi_dsi.h
index 70ce0b8cbc68..e0f56564bf97 100644
--- a/include/drm/drm_mipi_dsi.h
+++ b/include/drm/drm_mipi_dsi.h
@@ -314,17 +314,17 @@ int mipi_dsi_dcs_get_display_brightness_large(struct 
mipi_dsi_device *dsi,
  * @dsi: DSI peripheral device
  * @seq: buffer containing the payload
  */
-#define mipi_dsi_generic_write_seq(dsi, seq...)
\
-   do {   \
-   static const u8 d[] = { seq }; \
-   struct device *dev = >dev;\
-   int ret;   \
-   ret = mipi_dsi_generic_write(dsi, d, ARRAY_SIZE(d));   \
-   if (ret < 0) { \
-   dev_err_ratelimited(dev, "transmit data failed: %d\n", \
-   ret);  \
-   return ret;\
-   }  \
+#define mipi_dsi_generic_write_seq(dsi, seq...)
 \
+   do {
\
+   static const u8 d[] = { seq };  
\
+   struct device *dev = >dev; 
\
+   ssize_t ret;
\
+   ret = mipi_dsi_generic_write(dsi, d, ARRAY_SIZE(d));
\
+   if (ret < 0) {  
\
+   dev_err_ratelimited(dev, "transmit data failed: %zd\n", 
\
+   ret);   
\
+   return ret; 
\
+   }   
\
} while (0)
 
 /**
-- 
2.45.0.rc1.225.g2a3ae87e7f-goog

[PATCH v4 1/9] drm/mipi-dsi: Fix theoretical int overflow in mipi_dsi_dcs_write_seq()

[Douglas Anderson]

The mipi_dsi_dcs_write_seq() macro makes a call to
mipi_dsi_dcs_write_buffer() which returns a type ssize_t. The macro
then stores it in an int and checks to see if it's negative. This
could theoretically be a problem if "ssize_t" is larger than "int".

To see the issue, imagine that "ssize_t" is 32-bits and "int" is
16-bits, you could see a problem if there was some code out there that
looked like:

  mipi_dsi_dcs_write_seq(dsi, cmd, <32767 bytes as arguments>);

...since we'd get back that 32768 bytes were transferred and 32768
stored in a 16-bit int would look negative.

Though there are no callsites where we'd actually hit this (even if
"int" was only 16-bit), it's cleaner to make the types match so let's
fix it.

Fixes: 2a9e9daf7523 ("drm/mipi-dsi: Introduce mipi_dsi_dcs_write_seq macro")
Reviewed-by: Neil Armstrong 
Reviewed-by: Linus Walleij 
Signed-off-by: Douglas Anderson 
---

(no changes since v3)

Changes in v3:
- Use %zd in print instead of casting errors to int.

Changes in v2:
- New

 include/drm/drm_mipi_dsi.h | 24 
 1 file changed, 12 insertions(+), 12 deletions(-)

diff --git a/include/drm/drm_mipi_dsi.h b/include/drm/drm_mipi_dsi.h
index 82b1cc434ea3..70ce0b8cbc68 100644
--- a/include/drm/drm_mipi_dsi.h
+++ b/include/drm/drm_mipi_dsi.h
@@ -333,18 +333,18 @@ int mipi_dsi_dcs_get_display_brightness_large(struct 
mipi_dsi_device *dsi,
  * @cmd: Command
  * @seq: buffer containing data to be transmitted
  */
-#define mipi_dsi_dcs_write_seq(dsi, cmd, seq...)   \
-   do {   \
-   static const u8 d[] = { cmd, seq };\
-   struct device *dev = >dev;\
-   int ret;   \
-   ret = mipi_dsi_dcs_write_buffer(dsi, d, ARRAY_SIZE(d));\
-   if (ret < 0) { \
-   dev_err_ratelimited(   \
-   dev, "sending command %#02x failed: %d\n", \
-   cmd, ret); \
-   return ret;\
-   }  \
+#define mipi_dsi_dcs_write_seq(dsi, cmd, seq...)\
+   do {\
+   static const u8 d[] = { cmd, seq }; \
+   struct device *dev = >dev; \
+   ssize_t ret;\
+   ret = mipi_dsi_dcs_write_buffer(dsi, d, ARRAY_SIZE(d)); \
+   if (ret < 0) {  \
+   dev_err_ratelimited(\
+   dev, "sending command %#02x failed: %zd\n", \
+   cmd, ret);  \
+   return ret; \
+   }   \
} while (0)
 
 /**
-- 
2.45.0.rc1.225.g2a3ae87e7f-goog

[PATCH v4 0/9] drm/mipi-dsi: Reduce bloat and add funcs for cleaner init seqs

[Douglas Anderson]

The consensus of many DRM folks is that we want to move away from DSI
drivers defining tables of init commands. Instead, we want to move to
init functions that can use common DRM functions. The issue thus far
has been that using the macros mipi_dsi_generic_write_seq() and
mipi_dsi_dcs_write_seq() bloats the driver using them.

While trying to solve bloat, we realized that the majority of the it
was easy to solve. This series solves the bloat for existing drivers
by moving the printout outside of the macro.

During discussion of my v1 patch to fix the bloat [1], we also decided
that we really want to change the way that drivers deal with init
sequences to make it clearer. In addition to being cleaner, a side
effect of moving drivers to the new style reduces bloat _even more_.

This series also contains a few minor fixes / cleanups that I found
along the way.

This series converts four drivers over to the new
mipi_dsi_dcs_write_seq_multi() function. Not all conversions have been
tested, but hopefully they are straightforward enough. I'd appreciate
testing.

NOTE: In v3 I tried to incorporate the feedback from v2. I also
converted the other two panels I could find that used table-based
initialization.

v4 just has a tiny bugfix and collects tags. Assuming no other
problems are found the plan is to land this series sometime roughly
around May 16 [2]. Note that unless I get a review/Ack for the patch
("drm/panel: novatek-nt36672e: Switch to
mipi_dsi_dcs_write_seq_multi()") then I'll land the series without
that patch.

[1] 
https://lore.kernel.org/r/20240424172017.1.Id15fae80582bc74a0d4f1338987fa375738f45b9@changeid
[2] https://lore.kernel.org/r/35b899d2-fb47-403a-83d2-204c0800d...@linaro.org

Changes in v4:
- Test to see if init is non-NULL before using it.
- Update wording as per Linus W.

Changes in v3:
- ("mipi_dsi_*_write functions don't need to ratelimit...") moved earlier.
- Add a TODO item for cleaning up the deprecated macros/functions.
- Fix spacing of init function.
- Inline kerneldoc comments for struct mipi_dsi_multi_context.
- Rebased upon patch to remove ratelimit of prints.
- Remove an unneeded error print.
- Squash boe-tv101wum-nl6 lowercase patch into main patch
- Use %zd in print instead of casting errors to int.
- drm/panel: ili9882t: Don't use a table for initting panels
- drm/panel: innolux-p079zca: Don't use a table for initting panels

Changes in v2:
- Add some comments to the macros about printing and returning.
- Change the way err value is handled in prep for next patch.
- Modify commit message now that this is part of a series.
- Rebased upon patches to avoid theoretical int overflow.
- drm/mipi-dsi: Fix theoretical int overflow in mipi_dsi_dcs_write_seq()
- drm/mipi-dsi: Fix theoretical int overflow in mipi_dsi_generic_write_seq()
- drm/mipi-dsi: Introduce mipi_dsi_*_write_seq_multi()
- drm/mipi-dsi: mipi_dsi_*_write functions don't need to ratelimit prints
- drm/panel: boe-tv101wum-nl6: Convert hex to lowercase
- drm/panel: boe-tv101wum-nl6: Don't use a table for initting commands
- drm/panel: novatek-nt36672e: Switch to mipi_dsi_dcs_write_seq_multi()

Douglas Anderson (9):
  drm/mipi-dsi: Fix theoretical int overflow in mipi_dsi_dcs_write_seq()
  drm/mipi-dsi: Fix theoretical int overflow in
mipi_dsi_generic_write_seq()
  drm/mipi-dsi: mipi_dsi_*_write functions don't need to ratelimit
prints
  drm/mipi-dsi: Reduce driver bloat of mipi_dsi_*_write_seq()
  drm/mipi-dsi: Introduce mipi_dsi_*_write_seq_multi()
  drm/panel: novatek-nt36672e: Switch to mipi_dsi_dcs_write_seq_multi()
  drm/panel: boe-tv101wum-nl6: Don't use a table for initting panels
  drm/panel: ili9882t: Don't use a table for initting panels
  drm/panel: innolux-p079zca: Don't use a table for initting panels

 Documentation/gpu/todo.rst|   18 +
 drivers/gpu/drm/drm_mipi_dsi.c|  112 +
 .../gpu/drm/panel/panel-boe-tv101wum-nl6.c| 2792 +
 drivers/gpu/drm/panel/panel-ilitek-ili9882t.c |  794 +++--
 drivers/gpu/drm/panel/panel-innolux-p079zca.c |  284 +-
 .../gpu/drm/panel/panel-novatek-nt36672e.c|  576 ++--
 include/drm/drm_mipi_dsi.h|  101 +-
 7 files changed, 2452 insertions(+), 2225 deletions(-)

-- 
2.45.0.rc1.225.g2a3ae87e7f-goog

Re: [PATCH] drm/msm: Fix gen_header.py for python earlier than v3.9

[Jon Hunter]

On 08/05/2024 17:46, Abhinav Kumar wrote:



On 5/8/2024 2:17 AM, Jon Hunter wrote:
Building the kernel with python3 versions earlier than v3.9 fails with 
...


  Traceback (most recent call last):
    File "drivers/gpu/drm/msm/registers/gen_header.py", line 970, in 


  main()
    File "drivers/gpu/drm/msm/registers/gen_header.py", line 951, in main
  parser.add_argument('--validate', 
action=argparse.BooleanOptionalAction)
  AttributeError: module 'argparse' has no attribute 
'BooleanOptionalAction'


The argparse attribute 'BooleanOptionalAction' is only supported for
python v3.9 and later. Fix support for earlier python3 versions by
explicitly defining '--validate' and '--no-validate' arguments.

Signed-off-by: Jon Hunter 
---
  drivers/gpu/drm/msm/registers/gen_header.py | 3 ++-
  1 file changed, 2 insertions(+), 1 deletion(-)



Thanks for your patch, I had sent something similar y'day.

If you are alright with https://patchwork.freedesktop.org/patch/593057/, 
we can use that one.



Yes that's fine with me.

Thanks
Jon

--
nvpublic

Re: [PATCH] fbdev: Have CONFIG_FB_NOTIFY be tristate

[Sam Ravnborg]

Hi Arnd,

> 
> I think if you want to do a new version, that is likely to run
> into new problems, given that this part of fbdev is particularly
> fragile and partly wrong. On the other hand, it would be nice to
> have a patch to limit the use of the notifiers to the smallest
> set of kernel configs that actually need it, and leave it turned
> off for everything else.
> 
> These are the ones I could find:
> 
> - CONFIG_GUMSTIX_AM200EPD (FB_EVENT_FB_REGISTERED)

I was surprised to see this driver is still around as many other old
drivers was nuked as part of the pxa cleanup.
It is the only user of FB_EVENT_FB_REGISTERED - so a potential cleanup
if the driver is no longer relevant.

Just a drive-by comment, this should not stop a v2 of the patchset.

Sam

Re: [PATCH v2] mailbox: mtk-cmdq: Fix sleeping function called from invalid context

[Krzysztof Kozlowski]

On 08/05/2024 11:51, Jason-JH.Lin wrote:
> When we run kernel with lockdebug option, we will get the BUG below:
> [  106.692124] BUG: sleeping function called from invalid context at 
> drivers/base/power/runtime.c:1164
> [  106.692190] in_atomic(): 1, irqs_disabled(): 128, non_block: 0, pid: 3616, 
> name: kworker/u17:3

Trim logs from irrelevant context. timestamps are useless his. Registers
as well. Addresses of stacktrace as well and better just decode it.


> [  106.692226] preempt_count: 1, expected: 0
> [  106.692254] RCU nest depth: 0, expected: 0
> [  106.692282] INFO: lockdep is turned off.
> [  106.692306] irq event stamp: 0
> [  106.692331] hardirqs last  enabled at (0): [<>] 0x0
> [  106.692376] hardirqs last disabled at (0): [] 
> copy_process+0xc90/0x2ac0
> [  106.692429] softirqs last  enabled at (0): [] 
> copy_process+0xcb4/0x2ac0
> [  106.692473] softirqs last disabled at (0): [<>] 0x0
> [  106.692513] CPU: 1 PID: 3616 Comm: kworker/u17:3 Not tainted 
> 6.1.87-lockdep-14133-g26e933aca785 #1 6839942e1cf34914b0a366137843dd2366f52aa9
> [  106.692556] Hardware name: Google Ciri sku0/unprovisioned board (DT)
> [  106.692586] Workqueue: imgsys_runner imgsys_runner_func
> [  106.692638] Call trace:
> [  106.692662]  dump_backtrace+0x100/0x120
> [  106.692702]  show_stack+0x20/0x2c
> [  106.692737]  dump_stack_lvl+0x84/0xb4
> [  106.692775]  dump_stack+0x18/0x48
> [  106.692809]  __might_resched+0x354/0x4c0
> [  106.692847]  __might_sleep+0x98/0xe4
> [  106.692883]  __pm_runtime_resume+0x70/0x124
> [  106.692921]  cmdq_mbox_send_data+0xe4/0xb1c
> [  106.692964]  msg_submit+0x194/0x2dc
> [  106.693003]  mbox_send_message+0x190/0x330
> [  106.693043]  imgsys_cmdq_sendtask+0x1618/0x2224
> [  106.693082]  imgsys_runner_func+0xac/0x11c
> [  106.693118]  process_one_work+0x638/0xf84
> [  106.693158]  worker_thread+0x808/0xcd0
> [  106.693196]  kthread+0x24c/0x324
> [  106.693231]  ret_from_fork+0x10/0x20
> 
> We found that there is a spin_lock_irqsave protection in msg_submit()
> of mailbox.c and it is in the atomic context.
> So when cmdq driver calls pm_runtime_get_sync() in cmdq_mbox_send_data(),
> it will get this BUG report.
> 
> 1. Change pm_runtime_get_sync() to pm_runtime_get() to avoid using sleep
>in atomic context.
> 2. Move clk_bulk_enable() outside cmdq_runtime_resume() to ensure GCE
>clocks are enabled before configuring GCE register.
> 3. Add used_count to avoid cmdq_runtime_suspend() being called before
>calling cmdq_runtime_resume().
> 
> Fixes: 8afe816b0c99 ("mailbox: mtk-cmdq-mailbox: Implement Runtime PM with 
> autosuspend")
> Signed-off-by: Jason-JH.Lin 
> ---
>  drivers/mailbox/mtk-cmdq-mailbox.c | 24 +++-
>  1 file changed, 15 insertions(+), 9 deletions(-)
> 
> diff --git a/drivers/mailbox/mtk-cmdq-mailbox.c 
> b/drivers/mailbox/mtk-cmdq-mailbox.c
> index 033aff11f87c..b50f42e69aab 100644
> --- a/drivers/mailbox/mtk-cmdq-mailbox.c
> +++ b/drivers/mailbox/mtk-cmdq-mailbox.c
> @@ -82,6 +82,7 @@ struct cmdq {
>   const struct gce_plat   *pdata;
>   struct cmdq_thread  *thread;
>   struct clk_bulk_dataclocks[CMDQ_GCE_NUM_MAX];
> + atomic_tused_count;
>   boolsuspended;
>  };
>  
> @@ -317,14 +318,21 @@ static int cmdq_runtime_resume(struct device *dev)
>  {
>   struct cmdq *cmdq = dev_get_drvdata(dev);
>  
> - return clk_bulk_enable(cmdq->pdata->gce_num, cmdq->clocks);
> + atomic_inc(>used_count);

Do not implement own runtime PM counter...

> + return 0;
>  }
>  
>  static int cmdq_runtime_suspend(struct device *dev)
>  {
>   struct cmdq *cmdq = dev_get_drvdata(dev);
>  
> + if (atomic_read(>used_count) == 0) {
> + dev_warn(dev, "%s when used_count is 0!", __func__);
> + return -EINVAL;
> + }
> +
>   clk_bulk_disable(cmdq->pdata->gce_num, cmdq->clocks);
> + atomic_dec(>used_count);
>   return 0;
>  }
>  
> @@ -392,9 +400,8 @@ static int cmdq_mbox_send_data(struct mbox_chan *chan, 
> void *data)
>   /* Client should not flush new tasks if suspended. */
>   WARN_ON(cmdq->suspended);
>  
> - ret = pm_runtime_get_sync(cmdq->mbox.dev);
> - if (ret < 0)
> - return ret;
> + WARN_ON(pm_runtime_get(cmdq->mbox.dev) < 0);
> + WARN_ON(clk_bulk_enable(cmdq->pdata->gce_num, cmdq->clocks));

That's a no... First, you remove error handling. Second, you add WARN
and code should not have WARNs for error handling.

All this looks like terrible hacky workaround just to make warning go
away, without actually addressing real problem.

Best regards,
Krzysztof

Re: [PATCH v2 01/12] drm/amdgpu, drm/radeon: Make I2C terminology more inclusive

[Easwar Hariharan]

On 5/8/2024 7:53 AM, Alex Deucher wrote:
> On Tue, May 7, 2024 at 2:32 PM Easwar Hariharan
>  wrote:
>>
>> On 5/3/2024 11:13 AM, Easwar Hariharan wrote:
>>> I2C v7, SMBus 3.2, and I3C 1.1.1 specifications have replaced "master/slave"
>>> with more appropriate terms. Inspired by and following on to Wolfram's
>>> series to fix drivers/i2c/[1], fix the terminology for users of
>>> I2C_ALGOBIT bitbanging interface, now that the approved verbiage exists
>>> in the specification.
>>>
>>> Compile tested, no functionality changes intended
>>>
>>> [1]: 
>>> https://lore.kernel.org/all/20240322132619.6389-1-wsa+rene...@sang-engineering.com/
>>>
>>> Signed-off-by: Easwar Hariharan 
>>> ---
>>>  .../gpu/drm/amd/amdgpu/amdgpu_atomfirmware.c  |  8 +++---
>>>  drivers/gpu/drm/amd/amdgpu/amdgpu_i2c.c   | 10 +++
>>>  drivers/gpu/drm/amd/amdgpu/atombios_i2c.c |  8 +++---
>>>  drivers/gpu/drm/amd/amdgpu/atombios_i2c.h |  2 +-
>>>  drivers/gpu/drm/amd/amdgpu/smu_v11_0_i2c.c| 20 ++---
>>>  .../gpu/drm/amd/display/dc/bios/bios_parser.c |  2 +-
>>>  .../drm/amd/display/dc/bios/bios_parser2.c|  2 +-
>>>  .../drm/amd/display/dc/core/dc_link_exports.c |  4 +--
>>>  drivers/gpu/drm/amd/display/dc/dc.h   |  2 +-
>>>  drivers/gpu/drm/amd/display/dc/dce/dce_i2c.c  |  4 +--
>>>  .../display/include/grph_object_ctrl_defs.h   |  2 +-
>>>  drivers/gpu/drm/amd/include/atombios.h|  2 +-
>>>  drivers/gpu/drm/amd/include/atomfirmware.h| 26 -
>>>  .../powerplay/hwmgr/vega20_processpptables.c  |  4 +--
>>>  .../amd/pm/powerplay/inc/smu11_driver_if.h|  2 +-
>>>  .../inc/pmfw_if/smu11_driver_if_arcturus.h|  2 +-
>>>  .../inc/pmfw_if/smu11_driver_if_navi10.h  |  2 +-
>>>  .../pmfw_if/smu11_driver_if_sienna_cichlid.h  |  2 +-
>>>  .../inc/pmfw_if/smu13_driver_if_aldebaran.h   |  2 +-
>>>  .../inc/pmfw_if/smu13_driver_if_v13_0_0.h |  2 +-
>>>  .../inc/pmfw_if/smu13_driver_if_v13_0_7.h |  2 +-
>>>  .../gpu/drm/amd/pm/swsmu/smu11/arcturus_ppt.c |  4 +--
>>>  .../amd/pm/swsmu/smu11/sienna_cichlid_ppt.c   |  8 +++---
>>>  drivers/gpu/drm/radeon/atombios.h | 16 +--
>>>  drivers/gpu/drm/radeon/atombios_i2c.c |  4 +--
>>>  drivers/gpu/drm/radeon/radeon_combios.c   | 28 +--
>>>  drivers/gpu/drm/radeon/radeon_i2c.c   | 10 +++
>>>  drivers/gpu/drm/radeon/radeon_mode.h  |  6 ++--
>>>  28 files changed, 93 insertions(+), 93 deletions(-)
>>>
>>
>> 
>>
>> Hello Christian, Daniel, David, others,
>>
>> Could you re-review v2 since the feedback provided in v0 [1] has now been 
>> addressed? I can send v3 with
>> all other feedback and signoffs from the other maintainers incorporated when 
>> I have something for amdgpu
>> and radeon.
> 
> This seems like a lot of churn.  Additionally, a bunch of these
> headers are shared with other OSes, so it's possible some of the
> changes may end up getting reverted accidently when we sync up or we
> may add new headers in new code with the old nomenclature and then
> we'd need to make sure to adjust it to make sure everything was
> aligned again.  I would just as soon leave things as is, but I'm open
> to acking them if there is a strong desire to update things.
> 
> Alex

The way I see it, this is a small downpayment on the debt we have built up so 
far. Internship
programs like LF Outreachy to get more underrepresented groups involved in open 
source are trying to 
change the open source community culture to be more inclusive, but 
simultaneously rely on the culture
being welcoming enough as well.

I do see the challenge involved in preserving the changes and ensuring no new 
code is added with
outdated nomenclature (but see [1]), but culture changes one person at a time, 
and I'd encourage the community
to do the work needed so we can move past our (mostly) inadvertent role in 
perpetuating it.

That's my 2c (or your sub-unit currency of choice).

Easwar

[1] 
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=49decddd39e5f6132ccd7d9fdc3d7c470b0061bb

Re: [PATCH 1/2] drm: Allow mode object properties to be added after a device is registered

[Ville Syrjälä]

On Wed, May 08, 2024 at 02:43:07PM -0500, Mario Limonciello wrote:
> When the colorspace property is registered on MST devices there is
> no `obj_free_cb` callback for it in drm_mode_object_add().
> 
> Don't show a warning trace for __drm_mode_object_add() calls for
> DRM_MODE_OBJECT_PROPERTY.

You need to create the property ahead of time. See eg.
commit 1b9bd09630d4 ("drm/i915: Do not create a new max_bpc prop for MST
connectors")

> 
> Reported-and-tested-by: Tyler Schneider 
> Closes: https://gitlab.freedesktop.org/drm/amd/-/issues/3353
> Signed-off-by: Mario Limonciello 
> ---
>  drivers/gpu/drm/drm_mode_object.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/drm_mode_object.c 
> b/drivers/gpu/drm/drm_mode_object.c
> index 0e8355063eee..b077547a2db4 100644
> --- a/drivers/gpu/drm/drm_mode_object.c
> +++ b/drivers/gpu/drm/drm_mode_object.c
> @@ -42,7 +42,7 @@ int __drm_mode_object_add(struct drm_device *dev, struct 
> drm_mode_object *obj,
>  {
>   int ret;
>  
> - WARN_ON(!dev->driver->load && dev->registered && !obj_free_cb);
> + WARN_ON(!dev->driver->load && dev->registered && !obj_free_cb && 
> obj_type != DRM_MODE_OBJECT_PROPERTY);
>  
>   mutex_lock(>mode_config.idr_mutex);
>   ret = idr_alloc(>mode_config.object_idr, register_obj ? obj : NULL,
> -- 
> 2.43.0

-- 
Ville Syrjälä
Intel

[PATCH 2/2] Revert "drm/amd/display: Temporary Disable MST DP Colorspace Property"

[Mario Limonciello]

MST colorspace property support was disabled due to a series of warnings
that came up when the device was plugged in.  As those warnings are fixed,
revert commit 69a959610229 ("drm/amd/display: Temporary Disable MST DP
Colorspace Property").

Reported-and-tested-by: Tyler Schneider 
Closes: https://gitlab.freedesktop.org/drm/amd/-/issues/3353
Signed-off-by: Mario Limonciello 
---
 drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 2 +-
 1 file changed, 1 insertion(+), 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 3054bf79fc99..93e2030f4c17 100644
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
@@ -7695,7 +7695,7 @@ void amdgpu_dm_connector_init_helper(struct 
amdgpu_display_manager *dm,
if (connector_type == DRM_MODE_CONNECTOR_HDMIA) {
if 
(!drm_mode_create_hdmi_colorspace_property(>base, 
supported_colorspaces))

drm_connector_attach_colorspace_property(>base);
-   } else if ((connector_type == DRM_MODE_CONNECTOR_DisplayPort && 
!aconnector->mst_root) ||
+   } else if (connector_type == DRM_MODE_CONNECTOR_DisplayPort ||
   connector_type == DRM_MODE_CONNECTOR_eDP) {
if (!drm_mode_create_dp_colorspace_property(>base, 
supported_colorspaces))

drm_connector_attach_colorspace_property(>base);
-- 
2.43.0

[PATCH 1/2] drm: Allow mode object properties to be added after a device is registered

[Mario Limonciello]

When the colorspace property is registered on MST devices there is
no `obj_free_cb` callback for it in drm_mode_object_add().

Don't show a warning trace for __drm_mode_object_add() calls for
DRM_MODE_OBJECT_PROPERTY.

Reported-and-tested-by: Tyler Schneider 
Closes: https://gitlab.freedesktop.org/drm/amd/-/issues/3353
Signed-off-by: Mario Limonciello 
---
 drivers/gpu/drm/drm_mode_object.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/drm_mode_object.c 
b/drivers/gpu/drm/drm_mode_object.c
index 0e8355063eee..b077547a2db4 100644
--- a/drivers/gpu/drm/drm_mode_object.c
+++ b/drivers/gpu/drm/drm_mode_object.c
@@ -42,7 +42,7 @@ int __drm_mode_object_add(struct drm_device *dev, struct 
drm_mode_object *obj,
 {
int ret;
 
-   WARN_ON(!dev->driver->load && dev->registered && !obj_free_cb);
+   WARN_ON(!dev->driver->load && dev->registered && !obj_free_cb && 
obj_type != DRM_MODE_OBJECT_PROPERTY);
 
mutex_lock(>mode_config.idr_mutex);
ret = idr_alloc(>mode_config.object_idr, register_obj ? obj : NULL,
-- 
2.43.0

Re: [PATCH 00/21] drm: Increase COMPILE_TEST=y coverage

[Ville Syrjälä]

On Mon, Apr 08, 2024 at 08:04:05PM +0300, Ville Syrjala wrote:
> From: Ville Syrjälä 
> 
> I got fed up having to build multiple architectures when
> doing subsystem wide refactoring. So I decided to attack
> the low hanging COMPILE_TEST=y fruit. Here are the
> results. All of these drivers now build with COMPILE_TEST=y
> on x86/x86_64
> 
> Ville Syrjälä (21):
>   drm/hisilicon/kirin: Include linux/io.h for readl()/writel()
>   drm/hisilicon/kirin: Fix 64bit divisions
>   drm/hisilicon/kirin: Fix MASK(32) on 32bit architectures
>   drm/hisilicon/kirin: Allow build with COMPILE_TEST=y
>   drm/omap: Open code phys_to_page()
>   drm/omap: Allow build with COMPILE_TEST=y
>   drm/atmel-hlcdc: Allow build with COMPILE_TEST=y
>   drm/rcar-du: Allow build with COMPILE_TEST=y
>   drm/stm: Allow build with COMPILE_TEST=y

^ pushed to drm-misc-next. Thanks for the reviews.

>   drm/armada: Fix printk arguments
>   drm/armada: Fix armada_debugfs_crtc_reg_write() return type
>   drm/armada: Allow build with COMPILE_TEST=y
>   drm/imx/dcss: Fix 64bit divisions
>   drm/imx/dcss: Allow build with COMPILE_TEST=y
>   drm/sti: Include linux/io.h for devm_ioremap()
>   drm/sti: Allow build with COMPILE_TEST=y
>   drm/fsl-dcu: Allow build with COMPILE_TEST=y
>   drm/mediatek: Allow build with COMPILE_TEST=y
>   drm/meson: Allow build with COMPILE_TEST=y

^ are all still without comments.

>   drm/tilcdc: Allow build without __iowmb()
>   drm/tilcdc: Allow build with COMPILE_TEST=y

^ I need to respin.

-- 
Ville Syrjälä
Intel

2024 X.Org Developers Conference - October 9-11, Montréal, Canada

[Mark Filion]

Hello!

We're delighted to announce that the 2024 X.Org Developers Conference
(XDC) will be taking place on October 9 to 11 in Montréal, Canada, co-
located with the GStreamer Conference & Hackfest 2024 which will be
running from October 7 to 10. Join us for a freedesktop week in
Montréal!

XDC is the event for developers working on all things Open graphics
(Linux kernel, Mesa, DRM, Wayland, X11, etc.).

New this year: XDC 2024 will feature two full days of talks followed by
a day dedicated to workshops, meetings & hacking.

XDC 2024 website: https://indico.freedesktop.org/event/6/

The in-person venue is the Concordia University Conference Centre,
located within the John Molson School of Business.

Concordia University Conference Centre
1450 Guy St., Montreal, Quebec, Canada, H3H 0A1
https://goo.gl/maps/9nDyTvKtf7X1JuJc9

As usual, XDC will be free of charge and open to the general public.

Registration & Call for Proposals will be opening soon, stay tuned!

Best regards,

Mark Filion, on behalf of X.org

Re: /sys/kernel/debug/vgaswitcheroo directory missing

[Chris Clayton]

On 08/05/2024 16:54, Daniel Vetter wrote:
> On Wed, May 08, 2024 at 09:02:02AM +0100, Chris Clayton wrote:
>> Hi,
>>
>> I'm running the latest development kernel - 6.9.0-rc7+ (HEAD is 
>> dccb07f2914cdab2ac3a5b6c98406f765acab803.)
>>
>> As I say in $SUBJECT, the directory /sys/kernel/debug/vgaswitcheroo is 
>> missing in this release. Perhaps more importantly
>> unless it is configured to simply blank the screen, when xscreensaver kicks 
>> in an error message flashes rapidly on and
>> off complaining that no GL graphics are available. Moreover, if I start 
>> scribus from qterminal, I see the message
>> "Inconsistent value (1) for DRI_PRIME. Should be < 1 (GPU devices count). 
>> Using: 0".
>>
>> This same userspace works fine with kernels 6.6.30 and 6.8.9
>>
>> lsmod shows that the nouveau module is loaded and lsof shows that 
>> libdrm_nouveau is loaded for Xorg and a few desktop
>> applications. However, inspecting the nouveau-related output from dmesg 
>> reveals:
>>
>> [Wed May  8 08:20:07 2024] nouveau: detected PR support, will not use DSM
>> [Wed May  8 08:20:07 2024] nouveau :01:00.0: enabling device (0006 -> 
>> 0007)
>> [Wed May  8 08:20:07 2024] nouveau :01:00.0: NVIDIA TU117 (167000a1)
>> [Wed May  8 08:20:07 2024] nouveau :01:00.0: bios: version 90.17.42.00.36
>> [Wed May  8 08:20:07 2024] nouveau :01:00.0: pmu: firmware unavailable
>> [Wed May  8 08:20:07 2024] nouveau :01:00.0: fb: 4096 MiB GDDR6
>> [Wed May  8 08:20:07 2024] nouveau :01:00.0: sec2(acr): mbox 0007 
>> 
>> [Wed May  8 08:20:07 2024] nouveau :01:00.0: sec2(acr):AHESASC: boot 
>> failed: -5
>> [Wed May  8 08:20:07 2024] nouveau :01:00.0: acr: init failed, -5
>> [Wed May  8 08:20:07 2024] nouveau :01:00.0: init failed with -5
>> [Wed May  8 08:20:07 2024] nouveau: DRM-master::0080: init 
>> failed with -5
>> [Wed May  8 08:20:07 2024] nouveau :01:00.0: DRM-master: Device 
>> allocation failed: -5
>> [Wed May  8 08:20:07 2024] nouveau :01:00.0: probe with driver nouveau 
>> failed with error -5
>>
>> With kernel 6.8.9 the equivalent output is :
>>
>> Wed May  8 08:51:07 2024] nouveau: detected PR support, will not use DSM
>> [Wed May  8 08:51:07 2024] nouveau :01:00.0: enabling device (0006 -> 
>> 0007)
>> [Wed May  8 08:51:07 2024] nouveau :01:00.0: NVIDIA TU117 (167000a1)
>> [Wed May  8 08:51:07 2024] nouveau :01:00.0: bios: version 90.17.42.00.36
>> [Wed May  8 08:51:07 2024] nouveau :01:00.0: pmu: firmware unavailable
>> [Wed May  8 08:51:07 2024] nouveau :01:00.0: fb: 4096 MiB GDDR6
>> [Wed May  8 08:51:07 2024] nouveau :01:00.0: DRM: VRAM: 4096 MiB
>> [Wed May  8 08:51:07 2024] nouveau :01:00.0: DRM: GART: 536870912 MiB
>> [Wed May  8 08:51:07 2024] nouveau :01:00.0: DRM: BIT table 'A' not found
>> [Wed May  8 08:51:07 2024] nouveau :01:00.0: DRM: BIT table 'L' not found
>> [Wed May  8 08:51:07 2024] nouveau :01:00.0: DRM: TMDS table version 2.0
>> [Wed May  8 08:51:07 2024] nouveau :01:00.0: DRM: MM: using COPY for 
>> buffer copies
>> [Wed May  8 08:51:07 2024] [drm] Initialized nouveau 1.4.0 20120801 for 
>> :01:00.0 on minor 1
>> [Wed May  8 08:51:07 2024] nouveau :01:00.0: [drm] No compatible format 
>> found
>> [Wed May  8 08:51:07 2024] nouveau :01:00.0: [drm] Cannot find any crtc 
>> or sizes
>> [Wed May  8 08:51:07 2024] nouveau :01:00.0: DRM: Disabling PCI power 
>> management to avoid bug
>>
>> I've attached the complete dmesg output from 6.9.8-rc7+.
> 
> I'm assuming that the working kernel's dmesg shows that the proprietary
> nvidia driver is loaded, which provides all the services and gl. And now
> that somehow the nouveau driver loads (but doesn't work correctly for some
> reason, maybe because the userspace is missing) stuff is on fire.
> 
> If this assumption is correct you need to reinstall your nvidia driver
> stack and bother nvidia with any issues, not upstream.
> -Sima
> 

Oh, I'm terribly sorry to have bothered you! What and attitude to take to 
someone who is reporting  a problem in an
effort to help.

Your assumption is wrong. I've been using linux long enough to know not to 
report a problem if you've got a proprietary
driver installed. But never mind, I've blacklisted the nouveau driver. I'll try 
it again somwetime when I can be
bothered because clearly I'm just a nuisance to you.


>>
>> Please cc me on any reply as I'm not subscribed.
>>
>> Chris
>>
> 
>> [Wed May  8 08:20:04 2024] Linux version 6.9.0-rc7+ (chris@laptop) (gcc14 
>> (GCC) 14.0.1 20240503 (prerelease), GNU ld (GNU Binutils) 2.42) #283 SMP 
>> PREEMPT_DYNAMIC Tue May  7 06:58:55 BST 2024
>> [Wed May  8 08:20:04 2024] Command line: BOOT_IMAGE=/boot/vmlinuz-6.9.0-rc7+ 
>> ro root=PARTUUID=f927883a-e95c-4cdd-b64e-a0a778216b9f 
>> resume=PARTUUID=70ccedc5-d788-42bc-9f13-81e2beb61338 rootfstype=ext4 
>> net.ifnames=0 video=1920x1080@60
>> [Wed May  8 08:20:04 2024] BIOS-provided physical RAM map:
>> [Wed 

Re: [PATCH] fbdev: Have CONFIG_FB_NOTIFY be tristate

[Arnd Bergmann]

On Wed, May 8, 2024, at 20:37, Florian Fainelli wrote:
> On 5/7/24 04:44, Arnd Bergmann wrote:
>> On Tue, May 7, 2024, at 13:10, Daniel Vetter wrote:
>>> On Mon, May 06, 2024 at 04:53:47PM +0200, Arnd Bergmann wrote:

>> Right, let's wait for Florian to reply. From what he said earlier
>> though, the only reason that the notifiers are getting in the
>> way is the link error you get from trying to load a separately
>> built fb.ko module on a kernel that was built with FB=n / FB_CORE=n,
>> so I don't think he even cares about notifiers, only about
>> allowing the recovery application to mmap() the framebuffer.
>
> Right, we do not really care about notifiers AFAICT. Based upon this 
> discussion there has been an action on our side to stop making use of 
> the FB subsystem for recovery and use the full blow DRM driver instead.

Ok, sounds good.

> While we get there, though I still see some value into this patch (or a 
> v2, that is). I have a v2 ready if you think there is some value in 
> pursuing that route, if not, we can stop there.

I think if you want to do a new version, that is likely to run
into new problems, given that this part of fbdev is particularly
fragile and partly wrong. On the other hand, it would be nice to
have a patch to limit the use of the notifiers to the smallest
set of kernel configs that actually need it, and leave it turned
off for everything else.

These are the ones I could find:

- CONFIG_GUMSTIX_AM200EPD (FB_EVENT_FB_REGISTERED)
- CONFIG_LCD_CORGI, CONFIG_LCD_TDO24M (FB_EVENT_MODE_CHANGE)
- CONFIG_LEDS_TRIGGER_BACKLIGHT (FB_EVENT_BLANK)
- CONFIG_FB_OLPC_DCON (FB_EVENT_BLANK/BL_CORE_FBBLANK)
- CONFIG_FB_SH_MOBILE_LCDC, CONFIG_BACKLIGHT_PCF50633,
  CONFIG_BACKLIGHT_PANDORA, CONFIG_BACKLIGHT_LP855X (BL_CORE_FBBLANK)
- CONFIG_FB_CLPS711X, CONFIG_FB_IMX, CONFIG_MACH_AMS_DELTA
  (lcd BL_CORE_FBBLANK)
- CONFIG_LCD_AMS369FG06, CONFIG_LCD_CORGI, CONFIG_LCD_HX8357,
  CONFIG_LCD_ILI922X, CONFIG_LCD_ILI9320, CONFIG_LCD_HP700,
  CONFIG_LCD_L4F00242T03, CONFIG_LCD_LMS283GF05, CONFIG_LCD_LMS501KF03
  CONFIG_LCD_LTV350QV, CONFIG_LCD_OTM3225A, CONFIG_LCD_PLATFORM,
  CONFIG_LCD_TDO24M (lcd BL_CORE_FBBLANK)

Almost all of these are exclusive to ancient ARMv5 boards or
similar, so if we make the notifiers depend on the whole list,
this would leave it disabled even for most configurations
that enable CONFIG_FB=y.

This could be done with a 'select', but I'd prefer the
'default y; depends on LCD_FOO || LCD_BAR || ...'
variant because that makes it easier to spot if someone
tries to add another one.

  Arnd

Re: [PATCH v8 00/35] fix CONFIG_DRM_USE_DYNAMIC_DEBUG=y regression

[jim . cromie]

On Mon, Apr 29, 2024 at 1:32 PM Jim Cromie  wrote:
>
> hi Greg, Jason, DRM-folk,
>
> This patchset fixes the CONFIG_DRM_USE_DYNAMIC_DEBUG=y regression,
> Fixes: bb2ff6c27bc9 ("drm: Disable dynamic debug as broken")
>
> this is v8.
> Its also here:
> https://github.com/jimc/linux/tree/dd-classmap-fix-8a
>

This patchset didnt get picked up by drm patchwork
maybe its tired my stochastic renaming, sorry about that

https://patchwork.freedesktop.org/project/intel-gfx/series/?ordering=-last_updated

125063fix DRM_USE_DYNAMIC_DEBUG=y
regressionwarningNew23jim.cromie@gmail.comNone2023-11-01
123572fix DRM_USE_DYNAMIC_DEBUG
regressionfailureNew22jim.cromie@gmail.comNone2023-09-11
113363fix DRM_USE_DYNAMIC_DEBUG regressionwarningIn progress
22jim.cromie@gmail.comNone2023-08-01
111651DRM_USE_DYNAMIC_DEBUG
regressionfailureNew20jim.cromie@gmail.comNone2023-01-13
111631DRM - avoid regression in -rc, fix comment

is there something missing for a DRM patchwork run ?
does it kick out because theres non-drm subsystem stuff in there ?

thanks



> v7 had at least 2 problems:
>
>  https://lore.kernel.org/lkml/20231101002609.3533731-1-jim.cro...@gmail.com/
>  https://patchwork.freedesktop.org/series/125066/
>
> 1. missing __align(8) in METATDATA macro, giving too much placement
> freedom to linker, caused weird segvs following non-ptr vals, but for
> builtin modules only. found by lkp-test.
>
> 2. the main patch changed both the dyndbg API, and the drm/drivers.
> This was a flag-day annoyance, and not practical.  Fix by preserving
> old API macro until "later", and splitting the patch and set into 2
> sequential subsets.  removal can wait.
>
> What was broken ?
>
> Booting a modular kernel with drm.debug=0x1ff, this enabled pr_debugs
> only in drm itself, not the yet-to-be loaded driver + helpers.  I had
> tested with scripts doing lots of modprobes with dyndbg=<> options
> permuting.  I didn't notice that I didn't really test without them.
>
> The deeper cause was my design error, a violation of the K rule:
> "define once, refer many times".
>
> DECLARE_DYNDBG_CLASSMAP defined the classmap, and was used everywhere,
> re-declaring the same static classmap repeatedly. Jani Nikula actually
> picked up on this at the time, but didn't scream loudly enough for
> anyone to notice, I know I didn't get it then.  One patchset across 2
> trees didn't help either.
>
> The revised classmap API "splits" it to def & ref.
>
> DYNDBG_CLASSMAP_DEFINE fixes & updates the busted macro, EXPORTing the
> classmap instead.  It gets invoked once per subsystem, by the
> parent/builtin, drm.ko for DRM.
>
> DYNDBG_CLASSMAP_USE in drivers and helpers refer to the classmap by
> name, which links the 2 modules (like __drm_debug already does).
>
> These 2 tell dyndbg to map "class FOO" to the defined FOO_ID, which
> allows it to make those changes via >control.
>
> DYNDBG_CLASSMAP_PARAM*, defines the controlling kparam, and binds it
> to both the _var, and the _DEFINEd classmap.  So drm uses this to bind
> the classmap to __drm_debug.
>
> It provides the common control-point for the sub-system; it is applied
> to the classmaps during modprobe of both _DEFINEr and USErs.  It also
> enforces the relative nature of LEVEL classmaps, ie V3>V2.
>
> DECLARE_DYNDBG_CLASSMAP is preserved to decouple the DRM patches.
>
> A new struct and elf section contain the _USEs; on modprobe, these are
> scanned similarly to the _DEFINEs, but follow the references to their
> defining modules, find the kparam wired to the classmap, and apply its
> classmap settings to the USEr.  This action is what V1 missed, which
> is why drivers failed to enable debug during modprobe.
>
> In order to recapitulate the regression scenario without involving
> DRM, the patchset (v6 I think) adds test_dynamic_debug_submod, which
> is a duplicate of its parent; _submod.c #defines _SUBMOD, and then
> includes parent.
>
> This puts _DEFINE and _USE close together in the same file, for
> obviousness.  It also guarantees that the submod always has the same
> complement of debug()s, giving consistent output from both when
> classmaps are working properly, as tested when changing callsites via
> both param and >control.
>
> To provide a turn-key selftest, the patchset also adds
> ./tools/testing/selftests/dynamic_debug/dyndbg_selftest.sh, pilfered
> from a debug-to-trace patchset I and Lukasz Bartozik have been working
> out.  It starts with basic_tests, then to test 2 new parsing
> delimiters, which simplify testing of the classmap functionality.
>
> It works nicely from virtme-ng:
>
> [jimc@frodo vx]$ vrun_ -- 
> ./tools/testing/selftests/dynamic_debug/dyndbg_selftest.sh
> doing: vng --verbose --name v6.9-rc5-34-g2f1ace6e1c68 \
>--user root --cwd ../.. \
>-a dynamic_debug.verbose=2 -p 4 \
>-- ./tools/testing/selftests/dynamic_debug/dyndbg_selftest.sh
> virtme: waiting for virtiofsd to start
> ...
> [3.546739] ip (260) used greatest stack depth: 12368 bytes left
> [

[PULL] drm-intel-fixes

[Rodrigo Vivi]

Hi Dave and Sima,

Here goes our last fixes for v6.9.

drm-intel-fixes-2024-05-08:
- Automate CCS Mode setting during engine resets (Andi)
- Fix audio time stamp programming for DP (Chaitanya)
- Fix parsing backlight BDB data (Karthikeyan)
The following changes since commit dd5a440a31fae6e459c0d627162825505361:

  Linux 6.9-rc7 (2024-05-05 14:06:01 -0700)

are available in the Git repository at:

  https://anongit.freedesktop.org/git/drm/drm-intel 
tags/drm-intel-fixes-2024-05-08

for you to fetch changes up to 43b26bdd2ee5cfca80939be910d5b23a50cd7f9d:

  drm/i915/bios: Fix parsing backlight BDB data (2024-05-07 09:42:27 -0400)


- Automate CCS Mode setting during engine resets (Andi)
- Fix audio time stamp programming for DP (Chaitanya)
- Fix parsing backlight BDB data (Karthikeyan)


Andi Shyti (1):
  drm/i915/gt: Automate CCS Mode setting during engine resets

Chaitanya Kumar Borah (1):
  drm/i915/audio: Fix audio time stamp programming for DP

Karthikeyan Ramasubramanian (1):
  drm/i915/bios: Fix parsing backlight BDB data

 drivers/gpu/drm/i915/display/intel_audio.c| 113 ++
 drivers/gpu/drm/i915/display/intel_bios.c |  19 +
 drivers/gpu/drm/i915/display/intel_vbt_defs.h |   5 --
 drivers/gpu/drm/i915/gt/intel_gt_ccs_mode.c   |   6 +-
 drivers/gpu/drm/i915/gt/intel_gt_ccs_mode.h   |   2 +-
 drivers/gpu/drm/i915/gt/intel_workarounds.c   |   4 +-
 6 files changed, 19 insertions(+), 130 deletions(-)

Re: [RFC 1/5] drm/amdgpu: Fix migration rate limiting accounting

[Friedrich Vock]

On 08.05.24 20:09, Tvrtko Ursulin wrote:

From: Tvrtko Ursulin 

The logic assumed any migration attempt worked and therefore would over-
account the amount of data migrated during buffer re-validation. As a
consequence client can be unfairly penalised by incorrectly considering
its migration budget spent.


If the migration failed but data was still moved (which I think could be
the case when we try evicting everything but it still doesn't work?),
shouldn't the eviction movements count towards the ratelimit too?



Fix it by looking at the before and after buffer object backing store and
only account if there was a change.

FIXME:
I think this needs a better solution to account for migrations between
VRAM visible and non-visible portions.


FWIW, I have some WIP patches (not posted on any MLs yet though) that
attempt to solve this issue (+actually enforcing ratelimits) by moving
the ratelimit accounting/enforcement to TTM entirely.

By moving the accounting to TTM we can count moved bytes when we move
them, and don't have to rely on comparing resources to determine whether
moving actually happened. This should address your FIXME as well.

Regards,
Friedrich


Signed-off-by: Tvrtko Ursulin 
Cc: Christian König 
Cc: Friedrich Vock 
---
  drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c | 26 +-
  1 file changed, 21 insertions(+), 5 deletions(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c
index ec888fc6ead8..22708954ae68 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c
@@ -784,12 +784,15 @@ static int amdgpu_cs_bo_validate(void *param, struct 
amdgpu_bo *bo)
.no_wait_gpu = false,
.resv = bo->tbo.base.resv
};
+   struct ttm_resource *old_res;
uint32_t domain;
int r;

if (bo->tbo.pin_count)
return 0;

+   old_res = bo->tbo.resource;
+
/* Don't move this buffer if we have depleted our allowance
 * to move it. Don't move anything if the threshold is zero.
 */
@@ -817,16 +820,29 @@ static int amdgpu_cs_bo_validate(void *param, struct 
amdgpu_bo *bo)
amdgpu_bo_placement_from_domain(bo, domain);
r = ttm_bo_validate(>tbo, >placement, );

-   p->bytes_moved += ctx.bytes_moved;
-   if (!amdgpu_gmc_vram_full_visible(>gmc) &&
-   amdgpu_res_cpu_visible(adev, bo->tbo.resource))
-   p->bytes_moved_vis += ctx.bytes_moved;
-
if (unlikely(r == -ENOMEM) && domain != bo->allowed_domains) {
domain = bo->allowed_domains;
goto retry;
}

+   if (!r) {
+   struct ttm_resource *new_res = bo->tbo.resource;
+   bool moved = true;
+
+   if (old_res == new_res)
+   moved = false;
+   else if (old_res && new_res &&
+old_res->mem_type == new_res->mem_type)
+   moved = false;
+
+   if (moved) {
+   p->bytes_moved += ctx.bytes_moved;
+   if (!amdgpu_gmc_vram_full_visible(>gmc) &&
+   amdgpu_res_cpu_visible(adev, bo->tbo.resource))
+   p->bytes_moved_vis += ctx.bytes_moved;
+   }
+   }
+
return r;
  }

Re: drm scheduler and wq flavours

[Matthew Brost]

On Tue, May 07, 2024 at 10:09:18AM +0100, Tvrtko Ursulin wrote:
> 
> On 07/05/2024 00:23, Matthew Brost wrote:
> > On Thu, May 02, 2024 at 03:33:50PM +0100, Tvrtko Ursulin wrote:
> > > 
> > > Hi all,
> > > 
> > > Continuing after the brief IRC discussion yesterday regarding work queues
> > > being prone to deadlocks or not, I had a browse around the code base and
> > > ended up a bit confused.
> > > 
> > > When drm_sched_init documents and allocates an *ordered* wq, if no custom
> > > one was provided, could someone remind me was the ordered property
> > > fundamental for something to work correctly? Like run_job vs free_job
> > > ordering?
> > > 
> > 
> > Before the work queue (kthread design), run_job & free_job were ordered.
> > It was decided to not break this existing behavior.
> 
> Simply for extra paranoia or you remember if there was a reason identified?
> 

Not to break existing behavior. Can dig the entire thread if for
reference if needed.

> > > I ask because it appears different drivers to different things and at the
> > > moment it looks we have all possible combos or ordered/unordered, bound 
> > > and
> > > unbound, shared or not shared with the timeout wq, or even unbound for the
> > > timeout wq.
> > > 
> > > The drivers worth looking at in this respect are probably nouveau, 
> > > panthor,
> > > pvr and xe.
> > > 
> > > Nouveau also talks about a depency betwen run_job and free_job and goes to
> > > create two unordered wqs.
> > > 
> > > Then xe looks a bit funky with the workaround/hack for lockep where it
> > > creates 512 work queues and hands them over to user queues in round-robin
> > > fashion. (Instead of default 1:1.) Which I suspect is a problem which 
> > > should
> > > be applicable for any 1:1 driver given a thorough enough test suite.
> > > 
> > 
> > I think lockdep ran out of chains or something when executing some wild
> > IGT with 1:1. Yes, any driver with a wild enough test would likely hit
> > this lockdep splat too. Using a pool probably is not bad idea either.
> 
> I wonder what is different between that and having a single shared unbound
> queue and let kernel manage the concurrency? Both this..
> 

Each action (run_job, free_job, and Xe specific process msg) has its own
work item on the DRM scheduler work queue. In Xe, these options must be
ordered, or strictly speaking, not executed in parallel within the DRM
sched entity/scheduler. With a single shared unbound queue, this breaks.

> > > So anyway.. ordered vs unordered - drm sched dictated or at driver's 
> > > choice?
> > > 
> > 
> > Default ordered, driver can override with unordered.
> 
> .. and this, go back to my original question - whether the default queue
> must be ordered or not, or under which circustmances can drivers choose
> unordered. I think in drm_sched_init, where kerneldoc says it will create an
> ordered queue, it would be good to document the rules.
>

Sure. Let me write something up.

Matt

> Regards,
> 
> Tvrtko

Re: [PATCH 3/5] drm/i915: Use drm_crtc_vblank_crtc()

[Ville Syrjälä]

On Wed, May 08, 2024 at 12:12:32PM +0300, Jani Nikula wrote:
> On Mon, 08 Apr 2024, Ville Syrjala  wrote:
> > From: Ville Syrjälä 
> >
> > Replace the open coded drm_crtc_vblank_crtc() with the real
> > thing.
> >
> > Cc: intel-...@lists.freedesktop.org
> > Signed-off-by: Ville Syrjälä 
> 
> Reviewed-by: Jani Nikula 

Ta. Pushed this one to to drm-intel-next since
drm_crtc_vblank_crtc() made it there in the meantime.

-- 
Ville Syrjälä
Intel

Re: [PATCH 2/5] drm/amdgpu: Use drm_crtc_vblank_crtc()

[Ville Syrjälä]

On Wed, May 08, 2024 at 09:47:50AM -0400, Alex Deucher wrote:
> On Mon, Apr 8, 2024 at 3:06 PM Ville Syrjala
>  wrote:
> >
> > From: Ville Syrjälä 
> >
> > Replace the open coded drm_crtc_vblank_crtc() with the real
> > thing.
> >
> > Cc: Alex Deucher 
> > Cc: "Christian König" 
> > Cc: "Pan, Xinhui" 
> > Cc: amd-...@lists.freedesktop.org
> > Signed-off-by: Ville Syrjälä 
> 
> Reviewed-by: Alex Deucher 

Thanks. Pushed to drm-misc-next.

-- 
Ville Syrjälä
Intel

Re: [PATCH] fbdev: Have CONFIG_FB_NOTIFY be tristate

[Florian Fainelli]

On 5/7/24 04:44, Arnd Bergmann wrote:

On Tue, May 7, 2024, at 13:10, Daniel Vetter wrote:

On Mon, May 06, 2024 at 04:53:47PM +0200, Arnd Bergmann wrote:

On Mon, May 6, 2024, at 15:14, Daniel Vetter wrote:

On Fri, May 03, 2024 at 01:22:10PM -0700, Florian Fainelli wrote:

On 5/3/24 12:45, Arnd Bergmann wrote:


This is the current Android GKI config:
https://android.googlesource.com/kernel/common.git/+/refs/heads/android-mainline/arch/arm64/configs/gki_defconfig
where I can see that CONFIG_DRM is built-in, but DRM_FBDEV_EMULATION
CONFIG_VT, CONFIG_FRAMEBUFFER_CONSOLE, CONFIG_FB_DEVICE and
CONFIG_FB_CORE are all disabled.

So the console won't work at all,I think this means that there
is no way to get the console working, but building a fb.ko module
allows using /dev/fb with simplefb.ko (or any other one) happens
to almost work, but only by dumb luck rather than by design.


So using /dev/fb chardev without fbcon is very much a real idea. This way
you should be able to run old userspace that uses fbdev directly for
drawing, but your console needs are served by a userspace console running
on top of drm.

vt switching gets a bit more entertaining, but I thought logind has all
the glue already to make that happen. Worst case you need a tiny launcher
tool to get your userspace console out of the way while you launch a fbdev
using application, but I think correctly implement the vt ioctls to switch
to graphics mode /should/ work automatically.

I do agree that this is only really a good idea with drm drivers, since
those do not rely on any of the fbdev infrastructure like the notifier
under discussion.


I'm pretty sure what Florian is looking for has no dependency
on VT, fbcon or logind, but I'm only guessing based on the
information I see in the public Android source trees.

My understanding is that the Android recovery application is a
graphical tool that accesses the framebuffer directly and
is controlled using the volume and power buttons on a phone.


I suppose making CONFIG_FB_NOTIFIER optional for FB (on by
default if any of the consumers of the notification are turned
on) would not be a bad direction to go in general and also
address Florian's link error, but that doesn't solve the
more general concern about a third-party fb.ko module on a
kernel that was explicitly built with FB disabled.

The GKI defconfig was initially done at a time where one could
not have CONFIG_FBDEV_EMULATION and CONFIG_FB_DEVICE without
pulling in the entire fbdev module, but now that is possible.
Maybe that is something that Android could now include?

Alternatively, I wonder if that recovery image could be changed
to access the screen through the /dev/dri/ interfaces? I have
no experience in using those without Xorg or Wayland, is that
a sensible thing to do?


Uh ... I think I'm confused about the requirements. Does android's
recovery image need fbdev (meaning /dev/fb chardevs), or does it need
fbcon?

Note that fbcon runs (or well, should run) totally fine on top of drm
drivers without the fb notifier. This wasn't the case a few years ago
(because fbcon also used that notifier), but nowadays fb notifiers are
only needed for legacy fbdev drivers. So could it be that this "need fb
notifier" requirement is a leftover from rather old kernel versions and
not actually needed anymore?

I think we should nail the actual requirements here first before jumping
to solutions ...


Right, let's wait for Florian to reply. From what he said earlier
though, the only reason that the notifiers are getting in the
way is the link error you get from trying to load a separately
built fb.ko module on a kernel that was built with FB=n / FB_CORE=n,
so I don't think he even cares about notifiers, only about
allowing the recovery application to mmap() the framebuffer.


Right, we do not really care about notifiers AFAICT. Based upon this 
discussion there has been an action on our side to stop making use of 
the FB subsystem for recovery and use the full blow DRM driver instead.


While we get there, though I still see some value into this patch (or a 
v2, that is). I have a v2 ready if you think there is some value in 
pursuing that route, if not, we can stop there.

--
Florian



smime.p7s
Description: S/MIME Cryptographic Signature

Re: [PATCH v6 0/7] Adds support for ConfigFS to VKMS!

[José Expósito]

Hi everyone,

I wasn't aware of these patches, but I'm really glad they are getting
some attention, thanks a lot for your review Sima.

Given that it's been a while since the patches were emailed, I'm not
sure if the original authors of the patches could implement your
comments. If not, I can work on it. Please let me know.

I'm working on a Mutter feature that'd greatly benefit from this uapi
and I'm sure other compositors would find it useful.

I'll start working on a new version in a few days if nobody else is
already working on it.

Best wishes,
José Expósito

[RFC 1/5] drm/amdgpu: Fix migration rate limiting accounting

[Tvrtko Ursulin]

From: Tvrtko Ursulin 

The logic assumed any migration attempt worked and therefore would over-
account the amount of data migrated during buffer re-validation. As a
consequence client can be unfairly penalised by incorrectly considering
its migration budget spent.

Fix it by looking at the before and after buffer object backing store and
only account if there was a change.

FIXME:
I think this needs a better solution to account for migrations between
VRAM visible and non-visible portions.

Signed-off-by: Tvrtko Ursulin 
Cc: Christian König 
Cc: Friedrich Vock 
---
 drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c | 26 +-
 1 file changed, 21 insertions(+), 5 deletions(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c
index ec888fc6ead8..22708954ae68 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c
@@ -784,12 +784,15 @@ static int amdgpu_cs_bo_validate(void *param, struct 
amdgpu_bo *bo)
.no_wait_gpu = false,
.resv = bo->tbo.base.resv
};
+   struct ttm_resource *old_res;
uint32_t domain;
int r;
 
if (bo->tbo.pin_count)
return 0;
 
+   old_res = bo->tbo.resource;
+
/* Don't move this buffer if we have depleted our allowance
 * to move it. Don't move anything if the threshold is zero.
 */
@@ -817,16 +820,29 @@ static int amdgpu_cs_bo_validate(void *param, struct 
amdgpu_bo *bo)
amdgpu_bo_placement_from_domain(bo, domain);
r = ttm_bo_validate(>tbo, >placement, );
 
-   p->bytes_moved += ctx.bytes_moved;
-   if (!amdgpu_gmc_vram_full_visible(>gmc) &&
-   amdgpu_res_cpu_visible(adev, bo->tbo.resource))
-   p->bytes_moved_vis += ctx.bytes_moved;
-
if (unlikely(r == -ENOMEM) && domain != bo->allowed_domains) {
domain = bo->allowed_domains;
goto retry;
}
 
+   if (!r) {
+   struct ttm_resource *new_res = bo->tbo.resource;
+   bool moved = true;
+
+   if (old_res == new_res)
+   moved = false;
+   else if (old_res && new_res &&
+old_res->mem_type == new_res->mem_type)
+   moved = false;
+
+   if (moved) {
+   p->bytes_moved += ctx.bytes_moved;
+   if (!amdgpu_gmc_vram_full_visible(>gmc) &&
+   amdgpu_res_cpu_visible(adev, bo->tbo.resource))
+   p->bytes_moved_vis += ctx.bytes_moved;
+   }
+   }
+
return r;
 }
 
-- 
2.44.0

[RFC 2/5] drm/amdgpu: Actually respect buffer migration budget

[Tvrtko Ursulin]

From: Tvrtko Ursulin 

Current code appears to live in a misconception that playing with buffer
allowed and preferred placements can control the decision on whether
backing store migration will be attempted or not.

Both from code inspection and from empirical experiments I see that not
being true, and that both allowed and preferred placement are typically
set to the same bitmask.

As such, when the code decides to throttle the migration for a client, it
is in fact not achieving anything. Buffers can still be either migrated or
not migrated based on the external (to this function and facility) logic.

Fix it by not changing the buffer object placements if the migration
budget has been spent.

FIXME:
Is it still required to call validate is the question..

Signed-off-by: Tvrtko Ursulin 
Cc: Christian König 
Cc: Friedrich Vock 
---
 drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c | 12 +---
 1 file changed, 9 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c
index 22708954ae68..d07a1dd7c880 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c
@@ -784,6 +784,7 @@ static int amdgpu_cs_bo_validate(void *param, struct 
amdgpu_bo *bo)
.no_wait_gpu = false,
.resv = bo->tbo.base.resv
};
+   bool migration_allowed = true;
struct ttm_resource *old_res;
uint32_t domain;
int r;
@@ -805,19 +806,24 @@ static int amdgpu_cs_bo_validate(void *param, struct 
amdgpu_bo *bo)
 * visible VRAM if we've depleted our allowance to do
 * that.
 */
-   if (p->bytes_moved_vis < p->bytes_moved_vis_threshold)
+   if (p->bytes_moved_vis < p->bytes_moved_vis_threshold) {
domain = bo->preferred_domains;
-   else
+   } else {
domain = bo->allowed_domains;
+   migration_allowed = false;
+   }
} else {
domain = bo->preferred_domains;
}
} else {
domain = bo->allowed_domains;
+   migration_allowed = false;
}
 
 retry:
-   amdgpu_bo_placement_from_domain(bo, domain);
+   if (migration_allowed)
+   amdgpu_bo_placement_from_domain(bo, domain);
+
r = ttm_bo_validate(>tbo, >placement, );
 
if (unlikely(r == -ENOMEM) && domain != bo->allowed_domains) {
-- 
2.44.0

[RFC 0/5] Discussion around eviction improvements

[Tvrtko Ursulin]

From: Tvrtko Ursulin 

Last few days I was looking at the situation with VRAM over subscription, what
happens versus what perhaps should happen. Browsing through the driver and
running some simple experiments.

I ended up with this patch series which, as a disclaimer, may be completely
wrong but as I found some suspicious things, to me at least, I thought it was a
good point to stop and request some comments.

To perhaps summarise what are the main issues I think I found:

 * Migration rate limiting does not bother knowing if actual migration happened
   and so can over-account and unfairly penalise.

 * Migration rate limiting does not even work, at least not for the common case
   where userspace configures VRAM+GTT. It thinks it can stop migration attempts
   by playing with bo->allowed_domains vs bo->preferred domains but, both from
   the code, and from empirical experiments, I see that not working at all. Both
   masks are identical so fiddling with them achieves nothing.

 * Idea of the fallback placement only works when VRAM has free space. As soon
   as it does not, ttm_resource_compatible is happy to leave the buffers in the
   secondary placement forever.

 * Driver thinks it will be re-validating evicted buffers on the next submission
   but it does not for the very common case of VRAM+GTT because it only checks
   if current placement is *none* of the preferred placements.

All those problems are addressed in individual patches.

End result of this series appears to be driver which will try harder to move
buffers back into VRAM, but will be (more) correctly throttled in doing so by
the existing rate limiting logic.

I have run a quick benchmark of Cyberpunk 2077 and cannot say that I saw a
change but that could be a good thing too. At least I did not break anything,
perhaps.. On one occassion I did see the rate limiting logic get confused while
for a period of few minutes it went to a mode where it was constantly giving a
high migration budget. But that recovered itself when I switched clients and did
not come back so I don't know. If there is something wrong there I don't think
it would be caused by any patches in this series.

Series is probably rough but should be good enough for dicsussion. I am curious
to hear if I identified at least something correctly as a real problem.

It would also be good to hear what are the suggested games to check and see
whether there is any improvement.

Cc: Christian König 
Cc: Friedrich Vock 

Tvrtko Ursulin (5):
  drm/amdgpu: Fix migration rate limiting accounting
  drm/amdgpu: Actually respect buffer migration budget
  drm/ttm: Add preferred placement flag
  drm/amdgpu: Use preferred placement for VRAM+GTT
  drm/amdgpu: Re-validate evicted buffers

 drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c | 38 +-
 drivers/gpu/drm/amd/amdgpu/amdgpu_object.c |  8 +++--
 drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c | 21 ++--
 drivers/gpu/drm/ttm/ttm_resource.c | 13 +---
 include/drm/ttm/ttm_placement.h|  3 ++
 5 files changed, 65 insertions(+), 18 deletions(-)

-- 
2.44.0

[RFC 5/5] drm/amdgpu: Re-validate evicted buffers

[Tvrtko Ursulin]

From: Tvrtko Ursulin 

Currently the driver appears to be thinking that it will be attempting to
re-validate the evicted buffers on the next submission if they are not in
their preferred placement.

That however appears not to be true for the very common case of buffers
with allowed placements of VRAM+GTT. Simply because the check can only
detect if the current placement is *none* of the preferred ones, happily
leaving VRAM+GTT buffers in the GTT placement "forever".

Fix it by extending the VRAM+GTT special case to the re-validation logic.

Signed-off-by: Tvrtko Ursulin 
Cc: Christian König 
Cc: Friedrich Vock 
---
 drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c | 21 ++---
 1 file changed, 18 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c
index 6bddd43604bc..e53ff914b62e 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c
@@ -1248,10 +1248,25 @@ int amdgpu_vm_bo_update(struct amdgpu_device *adev, 
struct amdgpu_bo_va *bo_va,
 * next command submission.
 */
if (amdgpu_vm_is_bo_always_valid(vm, bo)) {
-   uint32_t mem_type = bo->tbo.resource->mem_type;
+   unsigned current_domain =
+   amdgpu_mem_type_to_domain(bo->tbo.resource->mem_type);
+   bool move_to_evict = false;
 
-   if (!(bo->preferred_domains &
- amdgpu_mem_type_to_domain(mem_type)))
+   if (!(bo->preferred_domains & current_domain)) {
+   move_to_evict = true;
+   } else if ((bo->preferred_domains & AMDGPU_GEM_DOMAIN_MASK) ==
+  (AMDGPU_GEM_DOMAIN_VRAM | AMDGPU_GEM_DOMAIN_GTT) &&
+  current_domain != AMDGPU_GEM_DOMAIN_VRAM) {
+   /*
+* If userspace has provided a list of possible
+* placements equal to VRAM+GTT, we assume VRAM is *the*
+* preferred placement and so try to move it back there
+* on the next submission.
+*/
+   move_to_evict = true;
+   }
+
+   if (move_to_evict)
amdgpu_vm_bo_evicted(_va->base);
else
amdgpu_vm_bo_idle(_va->base);
-- 
2.44.0

[RFC 3/5] drm/ttm: Add preferred placement flag

[Tvrtko Ursulin]

From: Tvrtko Ursulin 

Currently the fallback placement flag can achieve a hint that buffer
should be migrated back to the non-fallback placement, however that only
works while there is no memory pressure. As soon as we reach full VRAM
utilisation, or worse overcommit, the logic is happy to leave buffers in
the fallback placement. Consequence of this is that once buffers are
evicted they never get considered to be migrated back until the memory
pressure subsides, leaving a potentially active client not able to bring
its buffers back in.

Add a "preferred" placement flag which drivers can set when they want some
extra effort to be attempted for bringing a buffer back in.

QQQ:
Is the current "desired" flag unfortunately named perhaps? I ended up
understanding it as more like "would be nice if possible but absolutely
don't bother under memory pressure".

Signed-off-by: Tvrtko Ursulin 
Cc: Christian König 
Cc: Friedrich Vock 
---
 drivers/gpu/drm/ttm/ttm_resource.c | 13 +
 include/drm/ttm/ttm_placement.h|  3 +++
 2 files changed, 12 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/ttm/ttm_resource.c 
b/drivers/gpu/drm/ttm/ttm_resource.c
index 4a66b851b67d..59f3d1bcc11f 100644
--- a/drivers/gpu/drm/ttm/ttm_resource.c
+++ b/drivers/gpu/drm/ttm/ttm_resource.c
@@ -305,6 +305,8 @@ bool ttm_resource_compatible(struct ttm_resource *res,
 struct ttm_placement *placement,
 bool evicting)
 {
+   const u32 incompatible_flag = evicting ? TTM_PL_FLAG_DESIRED :
+TTM_PL_FLAG_FALLBACK;
struct ttm_buffer_object *bo = res->bo;
struct ttm_device *bdev = bo->bdev;
unsigned i;
@@ -316,11 +318,14 @@ bool ttm_resource_compatible(struct ttm_resource *res,
const struct ttm_place *place = >placement[i];
struct ttm_resource_manager *man;
 
-   if (res->mem_type != place->mem_type)
-   continue;
+   if (res->mem_type != place->mem_type) {
+   if (place->flags & TTM_PL_FLAG_PREFERRED)
+   return false;
+   else
+   continue;
+   }
 
-   if (place->flags & (evicting ? TTM_PL_FLAG_DESIRED :
-   TTM_PL_FLAG_FALLBACK))
+   if (place->flags & incompatible_flag)
continue;
 
if (place->flags & TTM_PL_FLAG_CONTIGUOUS &&
diff --git a/include/drm/ttm/ttm_placement.h b/include/drm/ttm/ttm_placement.h
index b510a4812609..8ea0865e9cc8 100644
--- a/include/drm/ttm/ttm_placement.h
+++ b/include/drm/ttm/ttm_placement.h
@@ -70,6 +70,9 @@
 /* Placement is only used during eviction */
 #define TTM_PL_FLAG_FALLBACK   (1 << 4)
 
+/* Placement is only used during eviction */
+#define TTM_PL_FLAG_PREFERRED  (1 << 5)
+
 /**
  * struct ttm_place
  *
-- 
2.44.0

[RFC 4/5] drm/amdgpu: Use preferred placement for VRAM+GTT

[Tvrtko Ursulin]

From: Tvrtko Ursulin 

Now that TTM has the preferred placement flag, extend the current
workaround which assumes the GTT placement as fallback in the presence of
the additional VRAM placement.

By marking the VRAM placement as preferred we will make the buffer re-
validation phase actually attempt to migrate them back to VRAM.

Without it, TTM core logic is happy to leave them in GTT placement
"forever".

Signed-off-by: Tvrtko Ursulin 
Cc: Christian König 
Cc: Friedrich Vock 
---
 drivers/gpu/drm/amd/amdgpu/amdgpu_object.c | 8 +---
 1 file changed, 5 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c
index 50b7e7c0ce50..9be767357e86 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c
@@ -128,8 +128,8 @@ void amdgpu_bo_placement_from_domain(struct amdgpu_bo *abo, 
u32 domain)
struct amdgpu_device *adev = amdgpu_ttm_adev(abo->tbo.bdev);
struct ttm_placement *placement = >placement;
struct ttm_place *places = abo->placements;
+   int c = 0, vram_index = -1;
u64 flags = abo->flags;
-   u32 c = 0;
 
if (domain & AMDGPU_GEM_DOMAIN_VRAM) {
unsigned int visible_pfn = adev->gmc.visible_vram_size >> 
PAGE_SHIFT;
@@ -158,7 +158,7 @@ void amdgpu_bo_placement_from_domain(struct amdgpu_bo *abo, 
u32 domain)
flags & AMDGPU_GEM_CREATE_VRAM_CONTIGUOUS)
places[c].flags |= TTM_PL_FLAG_CONTIGUOUS;
 
-   c++;
+   vram_index = c++;
}
 
if (domain & AMDGPU_GEM_DOMAIN_DOORBELL) {
@@ -180,8 +180,10 @@ void amdgpu_bo_placement_from_domain(struct amdgpu_bo 
*abo, u32 domain)
 * When GTT is just an alternative to VRAM make sure that we
 * only use it as fallback and still try to fill up VRAM first.
 */
-   if (domain & abo->preferred_domains & AMDGPU_GEM_DOMAIN_VRAM)
+   if (vram_index >= 0) {
places[c].flags |= TTM_PL_FLAG_FALLBACK;
+   places[vram_index].flags |= TTM_PL_FLAG_PREFERRED;
+   }
c++;
}
 
-- 
2.44.0

[PATCH] drm/msm/adreno: De-spaghettify the use of memory barriers

[Konrad Dybcio]

Memory barriers help ensure instruction ordering, NOT time and order
of actual write arrival at other observers (e.g. memory-mapped IP).
On architectures employing weak memory ordering, the latter can be a
giant pain point, and it has been as part of this driver.

Moreover, the gpu_/gmu_ accessors already use non-relaxed versions of
readl/writel, which include r/w (respectively) barriers.

Replace the barriers with a readback that ensures the previous writes
have exited the write buffer (as the CPU must flush the write to the
register it's trying to read back) and subsequently remove the hack
introduced in commit b77532803d11 ("drm/msm/a6xx: Poll for GBIF unhalt
status in hw_init").

Fixes: b77532803d11 ("drm/msm/a6xx: Poll for GBIF unhalt status in hw_init")
Signed-off-by: Konrad Dybcio 
---
 drivers/gpu/drm/msm/adreno/a6xx_gmu.c |  5 ++---
 drivers/gpu/drm/msm/adreno/a6xx_gpu.c | 14 --
 2 files changed, 6 insertions(+), 13 deletions(-)

diff --git a/drivers/gpu/drm/msm/adreno/a6xx_gmu.c 
b/drivers/gpu/drm/msm/adreno/a6xx_gmu.c
index 0e3dfd4c2bc8..4135a53b55a7 100644
--- a/drivers/gpu/drm/msm/adreno/a6xx_gmu.c
+++ b/drivers/gpu/drm/msm/adreno/a6xx_gmu.c
@@ -466,9 +466,8 @@ static int a6xx_rpmh_start(struct a6xx_gmu *gmu)
int ret;
u32 val;
 
-   gmu_write(gmu, REG_A6XX_GMU_RSCC_CONTROL_REQ, 1 << 1);
-   /* Wait for the register to finish posting */
-   wmb();
+   gmu_write(gmu, REG_A6XX_GMU_RSCC_CONTROL_REQ, BIT(1));
+   gmu_read(gmu, REG_A6XX_GMU_RSCC_CONTROL_REQ);
 
ret = gmu_poll_timeout(gmu, REG_A6XX_GMU_RSCC_CONTROL_ACK, val,
val & (1 << 1), 100, 1);
diff --git a/drivers/gpu/drm/msm/adreno/a6xx_gpu.c 
b/drivers/gpu/drm/msm/adreno/a6xx_gpu.c
index 973872ad0474..0acbc38b8e70 100644
--- a/drivers/gpu/drm/msm/adreno/a6xx_gpu.c
+++ b/drivers/gpu/drm/msm/adreno/a6xx_gpu.c
@@ -1713,22 +1713,16 @@ static int hw_init(struct msm_gpu *gpu)
}
 
/* Clear GBIF halt in case GX domain was not collapsed */
+   gpu_write(gpu, REG_A6XX_GBIF_HALT, 0);
+   gpu_read(gpu, REG_A6XX_GBIF_HALT);
if (adreno_is_a619_holi(adreno_gpu)) {
-   gpu_write(gpu, REG_A6XX_GBIF_HALT, 0);
gpu_write(gpu, REG_A6XX_RBBM_GPR0_CNTL, 0);
-   /* Let's make extra sure that the GPU can access the memory.. */
-   mb();
+   gpu_read(gpu, REG_A6XX_RBBM_GPR0_CNTL);
} else if (a6xx_has_gbif(adreno_gpu)) {
-   gpu_write(gpu, REG_A6XX_GBIF_HALT, 0);
gpu_write(gpu, REG_A6XX_RBBM_GBIF_HALT, 0);
-   /* Let's make extra sure that the GPU can access the memory.. */
-   mb();
+   gpu_read(gpu, REG_A6XX_RBBM_GBIF_HALT);
}
 
-   /* Some GPUs are stubborn and take their sweet time to unhalt GBIF! */
-   if (adreno_is_a7xx(adreno_gpu) && a6xx_has_gbif(adreno_gpu))
-   spin_until(!gpu_read(gpu, REG_A6XX_GBIF_HALT_ACK));
-
gpu_write(gpu, REG_A6XX_RBBM_SECVID_TSB_CNTL, 0);
 
if (adreno_is_a619_holi(adreno_gpu))

---
base-commit: 93a39e4766083050ca0ecd6a3548093a3b9eb60c
change-id: 20240508-topic-adreno-a2d199cd4152

Best regards,
-- 
Konrad Dybcio 

Re: [PATCH v4 2/7] drm/panel: himax-hx83102: Break out as separate driver

[Doug Anderson]

Hi,

On Wed, May 8, 2024 at 4:52 AM cong yang
 wrote:
>
> > > +static int starry_himax83102_j02_init(struct hx83102 *ctx)
> > > +{
> > > +   struct mipi_dsi_multi_context dsi_ctx = { .dsi = ctx->dsi };
> > > +
> > > +   hx83102_enable_extended_cmds(ctx, true);
> > > +   mipi_dsi_dcs_write_seq_multi(_ctx, HX83102_SETPOWER, 0x2c, 
> > > 0xb5, 0xb5, 0x31, 0xf1,
> > > +0x31, 0xd7, 0x2f, 0x36, 0x36, 
> > > 0x36, 0x36, 0x1a, 0x8b, 0x11,
> > > +0x65, 0x00, 0x88, 0xfa, 0xff, 
> > > 0xff, 0x8f, 0xff, 0x08, 0x74,
> > > +0x33);
> >
> > The indentation is still off here. You have 5 tabs followed by a
> > space. To make things line up with the opening brace I think it should
> > be 4 tabs followed by 5 spaces.
>
> Sorry, my  editor 'Visual Studio Code' It seems that the correct indentation
> is not recognized. I have checked it through the 'vim' editor in the V4 
> version.
> Thanks.

FWIW, I use VS Code and it looks fine to me. Maybe check your VS Code
settings? Tab size should be 8.


> > > +static int hx83102_enable(struct drm_panel *panel)
> > > +{
> > > +   struct hx83102 *ctx = panel_to_hx83102(panel);
> > > +   struct mipi_dsi_device *dsi = ctx->dsi;
> > > +   struct device *dev = >dev;
> > > +   int ret;
> > > +
> > > +   ret = ctx->desc->init(ctx);
> > > +   if (ret)
> > > +   return ret;
> >
> > You're still changing behavior here. In the old boe-tv101wum-nl6
> > driver the init() function was invoked at the end of prepare(). Now
> > you've got it at the beginning of enable(). If this change is
> > important it should be in a separate commit and explained.
> >
> >
> > > +   ret = mipi_dsi_dcs_exit_sleep_mode(dsi);
> > > +   if (ret) {
> > > +   dev_err(dev, "Failed to exit sleep mode: %d\n", ret);
> > > +   return ret;
> > > +   }
> > > +
> > > +   msleep(120);
> > > +
> > > +   ret = mipi_dsi_dcs_set_display_on(dsi);
> > > +   if (ret) {
> > > +   dev_err(dev, "Failed to turn on the display: %d\n", ret);
> > > +   }
> >
> > The old boe-tv101wum-nl6 driver didn't call
> > mipi_dsi_dcs_exit_sleep_mode() nor mipi_dsi_dcs_set_display_on() in
> > its enable routine, did it? If this change is important please put it
> > in a separate change and justify it.
>
> In the old boe-tv101wum-nl6 driver inital cmds was invoked at the end of
> prepare() function , and call 0x11 and 0x29 at end of inital. For
> himax-hx83102 driver, we move inital cmds invoked at enable() function.
> For panel timing, I think there is no much difference. They are
> all initial cmds executed after meeting the power-on sequence.
> I will update these in the v4 commit message.

Ah, I see! So the mipi_dsi_dcs_exit_sleep_mode() was the 0x11 in the
old code and the mipi_dsi_dcs_set_display_on() was the 0x29 in the old
code. OK, I agree that it's better like you've done it where those
functions are moved out of the "->init()" function and into the
caller, so please keep that as you have it.

The only thing I would request is to keep the ->init() call to be made
at the end of prepare() instead of the beginning of enable(). It may
not matter too much, but in that case I'd rather keep it how it was or
make it an explicit change and not an implicit part of the refactor.

-Doug

Re: [Linaro-mm-sig] Re: [PATCH] epoll: try to be a _bit_ better about file lifetimes

[Linus Torvalds]

On Wed, 8 May 2024 at 09:19, Linus Torvalds
 wrote:
>
> So since we already have two versions of F_DUPFD (the other being
> F_DUPFD_CLOEXEC) I decided that the best thing to do is to just extend
> on that existing naming pattern, and called it F_DUPFD_QUERY instead.
>
> I'm not married to the name, so if somebody hates it, feel free to
> argue otherwise.

Side note: with this patch, doing

   ret = fcntl(fd1, F_DUPFD_QUERY, fd2);

will result in:

 -1 (EBADF): 'fd1' is not a valid file descriptor
 -1 (EINVAL): old kernel that doesn't support F_DUPFD_QUERY
 0: fd2 does not refer to the same file as fd1
 1: fd2 is the same 'struct file' as fd1

and it might be worth noting a couple of things here:

 (a) fd2 being an invalid file descriptor does not cause EBADF, it
just causes "does not match".

 (b) we *could* use more bits for more equality

IOW, it would possibly make sense to extend the 0/1 result to be

- bit #0: same file pointer
- bit #1: same path
- bit #2: same dentry
- bit #3: same inode

which are all different levels of "sameness".

Does anybody care? Do we want to extend on this "sameness"? I'm not
convinced, but it might be a good idea to document this as a possibly
future extension, ie *if* what you care about is "same file pointer",
maybe you should make sure to only look at bit #0.

   Linus

Re: [RFC PATCH net-next v8 02/14] net: page_pool: create hooks for custom page providers

[Pavel Begunkov]

On 5/8/24 16:51, Christoph Hellwig wrote:

On Wed, May 08, 2024 at 12:35:52PM +0100, Pavel Begunkov wrote:

all these, because e.g. ttm internally does have a page pool because
depending upon allocator, that's indeed beneficial. Other drm drivers have
more buffer-based concepts for opportunistically memory around, usually
by marking buffers that are just kept as cache as purgeable (which is a
concept that goes all the way to opengl/vulkan).


Because in this case it solves nothing and helps with nothing, quite
the opposite. Just as well we can ask why NVMe doesn't wrap user pages
into a dmabuf while doing IO.


You seem to confused totally unrelated things.

For short-term pins, that is pin_user_pages without FOLL_LONGTERM there
would never be any point in using a dmabuf as the pin is transient.  For
long-term pin dmabufs in the block layer absolutely make sense, and I


Well, the example fell flat, but you don't use dmabuf when there are
no upsides from using it. For instance, when you already have pinned
pages, you're going to use pages, and there are no other refcounting
concerns. Unless there is an advantage of dmabufs over FOLL_LONGTERM
that I don't know about when used with normal user pages.


wish io_uring would have just implemented them from the start instead of
the current fixed buffers that are not quite as useful by not
pre-mapping DMA and not supporting P2P.


fdget(dmabuf) would be horrible, I assume that's not the suggestion.
But then it's really about kernel internals, and theoretically can
be patched to wrap user pages into a dmabuf and pass it in. The tricky
part is how that "pass it in" should looks like. Keith tried to cover
both pre-mapping and p2p by registering dmabuf and passing the mapped
addresses in an iter IIRC.

Anyway, this discussion should better move from to block/fs lists,
if there is any interest.

--
Pavel Begunkov

Re: [PATCH] drm/msm: remove python 3.9 dependency for compiling msm

[Abhinav Kumar]

On 5/8/2024 1:43 AM, Jani Nikula wrote:

On Tue, 07 May 2024, Abhinav Kumar  wrote:

Since commit 5acf49119630 ("drm/msm: import gen_header.py script from Mesa"),
compilation is broken on machines having python versions older than 3.9
due to dependency on argparse.BooleanOptionalAction.


Is it now okay to require Python for the build? Not listed in
Documentation/process/changes.rst.

BR,
Jani.



The change to move gen_header.py to kernel is already part of the v6.10 
pull request.


This change only fixes the version dependency.

But, I agree we should update the changes.rst (better late than never).

Dmitry, can you pls suggest which version we want to list there?

I am hoping that after this change there are no further dependencies on 
python versions, so anything > EOL should be fine.


I am leaning towards v3.8






Switch to use simple bool for the validate flag to remove the dependency.

Fixes: 5acf49119630 ("drm/msm: import gen_header.py script from Mesa")
Signed-off-by: Abhinav Kumar 
---
  drivers/gpu/drm/msm/registers/gen_header.py | 5 +++--
  1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/msm/registers/gen_header.py 
b/drivers/gpu/drm/msm/registers/gen_header.py
index fc3bfdc991d2..3926485bb197 100644
--- a/drivers/gpu/drm/msm/registers/gen_header.py
+++ b/drivers/gpu/drm/msm/registers/gen_header.py
@@ -538,7 +538,7 @@ class Parser(object):
self.variants.add(reg.domain)
  
  	def do_validate(self, schemafile):

-   if self.validate == False:
+   if not self.validate:
return
  
  		try:

@@ -948,7 +948,8 @@ def main():
parser = argparse.ArgumentParser()
parser.add_argument('--rnn', type=str, required=True)
parser.add_argument('--xml', type=str, required=True)
-   parser.add_argument('--validate', action=argparse.BooleanOptionalAction)
+   parser.add_argument('--validate', default=False, action='store_true')
+   parser.add_argument('--no-validate', dest='validate', 
action='store_false')
  
  	subparsers = parser.add_subparsers()

subparsers.required = True

Re: [PATCH] drm/msm: Fix gen_header.py for python earlier than v3.9

[Abhinav Kumar]

On 5/8/2024 2:17 AM, Jon Hunter wrote:

Building the kernel with python3 versions earlier than v3.9 fails with ...

  Traceback (most recent call last):
File "drivers/gpu/drm/msm/registers/gen_header.py", line 970, in 
  main()
File "drivers/gpu/drm/msm/registers/gen_header.py", line 951, in main
  parser.add_argument('--validate', action=argparse.BooleanOptionalAction)
  AttributeError: module 'argparse' has no attribute 'BooleanOptionalAction'

The argparse attribute 'BooleanOptionalAction' is only supported for
python v3.9 and later. Fix support for earlier python3 versions by
explicitly defining '--validate' and '--no-validate' arguments.

Signed-off-by: Jon Hunter 
---
  drivers/gpu/drm/msm/registers/gen_header.py | 3 ++-
  1 file changed, 2 insertions(+), 1 deletion(-)



Thanks for your patch, I had sent something similar y'day.

If you are alright with https://patchwork.freedesktop.org/patch/593057/, 
we can use that one.



diff --git a/drivers/gpu/drm/msm/registers/gen_header.py 
b/drivers/gpu/drm/msm/registers/gen_header.py
index fc3bfdc991d2..64f67d2e3f1c 100644
--- a/drivers/gpu/drm/msm/registers/gen_header.py
+++ b/drivers/gpu/drm/msm/registers/gen_header.py
@@ -948,7 +948,8 @@ def main():
parser = argparse.ArgumentParser()
parser.add_argument('--rnn', type=str, required=True)
parser.add_argument('--xml', type=str, required=True)
-   parser.add_argument('--validate', action=argparse.BooleanOptionalAction)
+   parser.add_argument('--validate', dest='validate', action='store_true')
+   parser.add_argument('--no-validate', dest='validate', 
action='store_false')
  
  	subparsers = parser.add_subparsers()

subparsers.required = True

Re: [Linaro-mm-sig] Re: [PATCH] epoll: try to be a _bit_ better about file lifetimes

[Linus Torvalds]

On Tue, 7 May 2024 at 12:07, Linus Torvalds
 wrote:
>
> That example thing shows that we shouldn't make it a FISAME ioctl - we
> should make it a fcntl() instead, and it would just be a companion to
> F_DUPFD.
>
> Doesn't that strike everybody as a *much* cleaner interface? I think
> F_ISDUP would work very naturally indeed with F_DUPFD.

So since we already have two versions of F_DUPFD (the other being
F_DUPFD_CLOEXEC) I decided that the best thing to do is to just extend
on that existing naming pattern, and called it F_DUPFD_QUERY instead.

I'm not married to the name, so if somebody hates it, feel free to
argue otherwise.

But with that, the suggested patch would end up looking something like
the attached (I also re-ordered the existing "F_LINUX_SPECIFIC_BASE"
users, since one of them was out of numerical order).

This really feels like a very natural thing, and yes, the 'same_fd()'
function in systemd that Christian also pointed at could use this very
naturally.

Also note that I obviously haven't tested this. Because obviously this
is trivially correct and cannot possibly have any bugs. Right? RIGHT?

And yes, I did check - despite the odd jump in numbers, we've never
had anything between F_NOTIFY (+2) and F_CANCELLK (+5).

We added F_SETLEASE (+0) , F_GETLEASE (+1) and F_NOTIFY (+2) in
2.4.0-test9 (roughly October 2000, I didn't dig deeper).

And then back in 2007 we suddenly jumped to F_CANCELLK (+5) in commit
9b9d2ab4154a ("locks: add lock cancel command"). I don't know why 3/4
were shunned.

After that we had 22d2b35b200f ("F_DUPFD_CLOEXEC implementation") add
F_DUPFD_CLOEXEC (+6).

I'd have loved to put F_DUPFD_QUERY next to it, but +5 and +7 are both used.

Linus
 fs/fcntl.c | 23 +++
 include/uapi/linux/fcntl.h | 14 --
 2 files changed, 31 insertions(+), 6 deletions(-)

diff --git a/fs/fcntl.c b/fs/fcntl.c
index 54cc85d3338e..1ddb63f70445 100644
--- a/fs/fcntl.c
+++ b/fs/fcntl.c
@@ -327,6 +327,25 @@ static long fcntl_set_rw_hint(struct file *file, unsigned int cmd,
 	return 0;
 }
 
+/*
+ * Is the file descriptor a dup of the file?
+ */
+static long f_dupfd_query(int fd, struct file *filp)
+{
+	struct fd f = fdget_raw(fd);
+
+	/*
+	 * We can do the 'fdput()' immediately, as the only thing that
+	 * matters is the pointer value which isn't changed by the fdput.
+	 *
+	 * Technically we didn't need a ref at all, and 'fdget()' was
+	 * overkill, but given our lockless file pointer lookup, the
+	 * alternatives are complicated.
+	 */
+	fdput(f);
+	return f.file == filp;
+}
+
 static long do_fcntl(int fd, unsigned int cmd, unsigned long arg,
 		struct file *filp)
 {
@@ -342,6 +361,9 @@ static long do_fcntl(int fd, unsigned int cmd, unsigned long arg,
 	case F_DUPFD_CLOEXEC:
 		err = f_dupfd(argi, filp, O_CLOEXEC);
 		break;
+	case F_DUPFD_QUERY:
+		err = f_dupfd_query(argi, filp);
+		break;
 	case F_GETFD:
 		err = get_close_on_exec(fd) ? FD_CLOEXEC : 0;
 		break;
@@ -446,6 +468,7 @@ static int check_fcntl_cmd(unsigned cmd)
 	switch (cmd) {
 	case F_DUPFD:
 	case F_DUPFD_CLOEXEC:
+	case F_DUPFD_QUERY:
 	case F_GETFD:
 	case F_SETFD:
 	case F_GETFL:
diff --git a/include/uapi/linux/fcntl.h b/include/uapi/linux/fcntl.h
index 282e90aeb163..c0bcc185fa48 100644
--- a/include/uapi/linux/fcntl.h
+++ b/include/uapi/linux/fcntl.h
@@ -8,6 +8,14 @@
 #define F_SETLEASE	(F_LINUX_SPECIFIC_BASE + 0)
 #define F_GETLEASE	(F_LINUX_SPECIFIC_BASE + 1)
 
+/*
+ * Request nofications on a directory.
+ * See below for events that may be notified.
+ */
+#define F_NOTIFY	(F_LINUX_SPECIFIC_BASE + 2)
+
+#define F_DUPFD_QUERY	(F_LINUX_SPECIFIC_BASE + 3)
+
 /*
  * Cancel a blocking posix lock; internal use only until we expose an
  * asynchronous lock api to userspace:
@@ -17,12 +25,6 @@
 /* Create a file descriptor with FD_CLOEXEC set. */
 #define F_DUPFD_CLOEXEC	(F_LINUX_SPECIFIC_BASE + 6)
 
-/*
- * Request nofications on a directory.
- * See below for events that may be notified.
- */
-#define F_NOTIFY	(F_LINUX_SPECIFIC_BASE+2)
-
 /*
  * Set and get of pipe page size array
  */

Re: [RFC PATCH net-next v8 02/14] net: page_pool: create hooks for custom page providers

[Pavel Begunkov]

On 5/8/24 16:58, Jason Gunthorpe wrote:

On Wed, May 08, 2024 at 04:44:32PM +0100, Pavel Begunkov wrote:


like a weird and indirect way to get there. Why can't io_uring just be
the entity that does the final free and not mess with the logic
allocator?


Then the user has to do a syscall (e.g. via io_uring) to return pages,
and there we'd need to care how to put the pages efficiently, i.e.
hitting the page pool's fast path, e.g. by hoping napi is scheduled and
scheduled for the CPU we're running on, or maybe transferring the pages
to the right CPU first.

Compare it with userspace putting pages into a ring, and the allocator
taking from there when needed without any extra synchronisation and
hassle just because it's a sole consumer.


Wow, that sounds a bit terrifying for security, but I guess I can see
your point.


Mind elaborating about security? "No synchronisation" is for grabbing
from the ring, it's napi exclusive, but it does refcounting to make sure
there are no previous net users left and the userspace doesn't try
anything funny like returning a page twice. And it's not even a page
but rather a separately refcounted buffer represented by an offset
from the userspace POV. It doesn't even have to be page sized, hw
benefits from smaller chunks.


You are replacing the whole allocator logic if you are effectively
putting the free list in userspace memory.

Jason


--
Pavel Begunkov

Re: [RFC PATCH net-next v8 02/14] net: page_pool: create hooks for custom page providers

[Jason Gunthorpe]

On Wed, May 08, 2024 at 04:44:32PM +0100, Pavel Begunkov wrote:

> > like a weird and indirect way to get there. Why can't io_uring just be
> > the entity that does the final free and not mess with the logic
> > allocator?
> 
> Then the user has to do a syscall (e.g. via io_uring) to return pages,
> and there we'd need to care how to put the pages efficiently, i.e.
> hitting the page pool's fast path, e.g. by hoping napi is scheduled and
> scheduled for the CPU we're running on, or maybe transferring the pages
> to the right CPU first.
> 
> Compare it with userspace putting pages into a ring, and the allocator
> taking from there when needed without any extra synchronisation and
> hassle just because it's a sole consumer.

Wow, that sounds a bit terrifying for security, but I guess I can see
your point.

You are replacing the whole allocator logic if you are effectively
putting the free list in userspace memory.

Jason

Re: /sys/kernel/debug/vgaswitcheroo directory missing

[Daniel Vetter]

On Wed, May 08, 2024 at 09:02:02AM +0100, Chris Clayton wrote:
> Hi,
> 
> I'm running the latest development kernel - 6.9.0-rc7+ (HEAD is 
> dccb07f2914cdab2ac3a5b6c98406f765acab803.)
> 
> As I say in $SUBJECT, the directory /sys/kernel/debug/vgaswitcheroo is 
> missing in this release. Perhaps more importantly
> unless it is configured to simply blank the screen, when xscreensaver kicks 
> in an error message flashes rapidly on and
> off complaining that no GL graphics are available. Moreover, if I start 
> scribus from qterminal, I see the message
> "Inconsistent value (1) for DRI_PRIME. Should be < 1 (GPU devices count). 
> Using: 0".
> 
> This same userspace works fine with kernels 6.6.30 and 6.8.9
> 
> lsmod shows that the nouveau module is loaded and lsof shows that 
> libdrm_nouveau is loaded for Xorg and a few desktop
> applications. However, inspecting the nouveau-related output from dmesg 
> reveals:
> 
> [Wed May  8 08:20:07 2024] nouveau: detected PR support, will not use DSM
> [Wed May  8 08:20:07 2024] nouveau :01:00.0: enabling device (0006 -> 
> 0007)
> [Wed May  8 08:20:07 2024] nouveau :01:00.0: NVIDIA TU117 (167000a1)
> [Wed May  8 08:20:07 2024] nouveau :01:00.0: bios: version 90.17.42.00.36
> [Wed May  8 08:20:07 2024] nouveau :01:00.0: pmu: firmware unavailable
> [Wed May  8 08:20:07 2024] nouveau :01:00.0: fb: 4096 MiB GDDR6
> [Wed May  8 08:20:07 2024] nouveau :01:00.0: sec2(acr): mbox 0007 
> 
> [Wed May  8 08:20:07 2024] nouveau :01:00.0: sec2(acr):AHESASC: boot 
> failed: -5
> [Wed May  8 08:20:07 2024] nouveau :01:00.0: acr: init failed, -5
> [Wed May  8 08:20:07 2024] nouveau :01:00.0: init failed with -5
> [Wed May  8 08:20:07 2024] nouveau: DRM-master::0080: init failed 
> with -5
> [Wed May  8 08:20:07 2024] nouveau :01:00.0: DRM-master: Device 
> allocation failed: -5
> [Wed May  8 08:20:07 2024] nouveau :01:00.0: probe with driver nouveau 
> failed with error -5
> 
> With kernel 6.8.9 the equivalent output is :
> 
> Wed May  8 08:51:07 2024] nouveau: detected PR support, will not use DSM
> [Wed May  8 08:51:07 2024] nouveau :01:00.0: enabling device (0006 -> 
> 0007)
> [Wed May  8 08:51:07 2024] nouveau :01:00.0: NVIDIA TU117 (167000a1)
> [Wed May  8 08:51:07 2024] nouveau :01:00.0: bios: version 90.17.42.00.36
> [Wed May  8 08:51:07 2024] nouveau :01:00.0: pmu: firmware unavailable
> [Wed May  8 08:51:07 2024] nouveau :01:00.0: fb: 4096 MiB GDDR6
> [Wed May  8 08:51:07 2024] nouveau :01:00.0: DRM: VRAM: 4096 MiB
> [Wed May  8 08:51:07 2024] nouveau :01:00.0: DRM: GART: 536870912 MiB
> [Wed May  8 08:51:07 2024] nouveau :01:00.0: DRM: BIT table 'A' not found
> [Wed May  8 08:51:07 2024] nouveau :01:00.0: DRM: BIT table 'L' not found
> [Wed May  8 08:51:07 2024] nouveau :01:00.0: DRM: TMDS table version 2.0
> [Wed May  8 08:51:07 2024] nouveau :01:00.0: DRM: MM: using COPY for 
> buffer copies
> [Wed May  8 08:51:07 2024] [drm] Initialized nouveau 1.4.0 20120801 for 
> :01:00.0 on minor 1
> [Wed May  8 08:51:07 2024] nouveau :01:00.0: [drm] No compatible format 
> found
> [Wed May  8 08:51:07 2024] nouveau :01:00.0: [drm] Cannot find any crtc 
> or sizes
> [Wed May  8 08:51:07 2024] nouveau :01:00.0: DRM: Disabling PCI power 
> management to avoid bug
> 
> I've attached the complete dmesg output from 6.9.8-rc7+.

I'm assuming that the working kernel's dmesg shows that the proprietary
nvidia driver is loaded, which provides all the services and gl. And now
that somehow the nouveau driver loads (but doesn't work correctly for some
reason, maybe because the userspace is missing) stuff is on fire.

If this assumption is correct you need to reinstall your nvidia driver
stack and bother nvidia with any issues, not upstream.
-Sima

> 
> Please cc me on any reply as I'm not subscribed.
> 
> Chris
> 

> [Wed May  8 08:20:04 2024] Linux version 6.9.0-rc7+ (chris@laptop) (gcc14 
> (GCC) 14.0.1 20240503 (prerelease), GNU ld (GNU Binutils) 2.42) #283 SMP 
> PREEMPT_DYNAMIC Tue May  7 06:58:55 BST 2024
> [Wed May  8 08:20:04 2024] Command line: BOOT_IMAGE=/boot/vmlinuz-6.9.0-rc7+ 
> ro root=PARTUUID=f927883a-e95c-4cdd-b64e-a0a778216b9f 
> resume=PARTUUID=70ccedc5-d788-42bc-9f13-81e2beb61338 rootfstype=ext4 
> net.ifnames=0 video=1920x1080@60
> [Wed May  8 08:20:04 2024] BIOS-provided physical RAM map:
> [Wed May  8 08:20:04 2024] BIOS-e820: [mem 
> 0x-0x0009efff] usable
> [Wed May  8 08:20:04 2024] BIOS-e820: [mem 
> 0x0009f000-0x000f] reserved
> [Wed May  8 08:20:04 2024] BIOS-e820: [mem 
> 0x0010-0x7e1d8fff] usable
> [Wed May  8 08:20:04 2024] BIOS-e820: [mem 
> 0x7e1d9000-0x7ead8fff] reserved
> [Wed May  8 08:20:04 2024] BIOS-e820: [mem 
> 0x7ead9000-0x8cceefff] usable
> [Wed May  8 08:20:04 2024] BIOS-e820: [mem 
> 0x8ccef000-0x8eedefff] reserved

Re: Safety of opening up /dev/dma_heap/* to physically present users (udev uaccess tag) ?

[Daniel Vetter]

On Wed, May 08, 2024 at 09:38:33AM +0100, Daniel Stone wrote:
> On Wed, 8 May 2024 at 09:33, Daniel Vetter  wrote:
> > On Wed, May 08, 2024 at 06:46:53AM +0100, Daniel Stone wrote:
> > > That would have the unfortunate side effect of making sandboxed apps
> > > less efficient on some platforms, since they wouldn't be able to do
> > > direct scanout anymore ...
> >
> > I was assuming that everyone goes through pipewire, and ideally that is
> > the only one that can even get at these special chardev.
> >
> > If pipewire is only for sandboxed apps then yeah this aint great :-/
> 
> No, PipeWire is fine, I mean graphical apps.
> 
> Right now, if your platform requires CMA for display, then the app
> needs access to the GPU render node and the display node too, in order
> to allocate buffers which the compositor can scan out directly. If it
> only has access to the render nodes and not the display node, it won't
> be able to allocate correctly, so its content will need a composition
> pass, i.e. performance penalty for sandboxing. But if it can allocate
> correctly, then hey, it can exhaust CMA just like heaps can.
> 
> Personally I think we'd be better off just allowing access and
> figuring out cgroups later. It's not like the OOM story is great
> generally, and hey, you can get there with just render nodes ...

Imo the right fix is to ask the compositor to allocate the buffers in this
case, and then maybe have some kind of revoke/purge behaviour on these
buffers. Compositor has an actual idea of who's a candidate for direct
scanout after all, not the app. Or well at least force migrate the memory
from cma to shmem.

If you only whack cgroups on this issue you're still stuck in the world
where either all apps together can ddos the display or no one can
realistically direct scanout.

So yeah on the display side the problem isn't solved either, but we knew
that already.
-Sima
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch

Re: [Linaro-mm-sig] Re: [PATCH] epoll: try to be a _bit_ better about file lifetimes

[Daniel Vetter]

On Wed, May 08, 2024 at 12:08:57PM +0200, Christian Brauner wrote:
> On Mon, May 06, 2024 at 04:29:44PM +0200, Christian König wrote:
> > Am 04.05.24 um 20:20 schrieb Linus Torvalds:
> > > On Sat, 4 May 2024 at 08:32, Linus Torvalds
> > >  wrote:
> > > > Lookie here, the fundamental issue is that epoll can call '->poll()'
> > > > on a file descriptor that is being closed concurrently.
> > > Thinking some more about this, and replying to myself...
> > > 
> > > Actually, I wonder if we could *really* fix this by simply moving the
> > > eventpoll_release() to where it really belongs.
> > > 
> > > If we did it in file_close_fd_locked(),  it would actually make a
> > > *lot* more sense. Particularly since eventpoll actually uses this:
> > > 
> > >  struct epoll_filefd {
> > >  struct file *file;
> > >  int fd;
> > >  } __packed;
> > > 
> > > ie it doesn't just use the 'struct file *', it uses the 'fd' itself
> > > (for ep_find()).
> > > 
> > > (Strictly speaking, it should also have a pointer to the 'struct
> > > files_struct' to make the 'int fd' be meaningful).
> > 
> > While I completely agree on this I unfortunately have to ruin the idea.
> > 
> > Before we had KCMP some people relied on the strange behavior of eventpoll
> > to compare struct files when the fd is the same.
> > 
> > I just recently suggested that solution to somebody at AMD as a workaround
> > when KCMP is disabled because of security hardening and I'm pretty sure I've
> > seen it somewhere else as well.
> > 
> > So when we change that it would break (undocumented?) UAPI behavior.
> 
> I've worked on that a bit yesterday and I learned new things about epoll
> and ran into some limitations.
> 
> Like, what happens if process P1 has a file descriptor registered in an
> epoll instance and now P1 forks and creates P2. So every file that P1
> maintains gets copied into a new file descriptor table for P2. And the
> same file descriptors refer to the same files for both P1 and P2.

So this is pretty similar to any other struct file that has resources
hanging off the struct file instead of the underlying inode. Like drm
chardev files, where all the buffers, gpu contexts and everything else
hangs off the file and there's no other way to get at them (except when
exporting to some explicitly meant-for-sharing file like dma-buf).

If you fork() that it's utter hilarity, which is why absolutely everyone
should set O_CLOEXEC on these. Or EPOLL_CLOEXEC for epoll_create.

For the uapi issue you describe below my take would be that we should just
try, and hope that everyone's been dutifully using O_CLOEXEC. But maybe
I'm biased from the gpu world, where we've been hammering it in that
"O_CLOEXEC or bust" mantra since well over a decade. Really the only valid
use-case is something like systemd handing open files to a service, where
it drops priviledges even well before the exec() call. But we can't switch
around the defaults for any of these special open files with anything more
than just a current seek position as state, since that breaks uapi.
-Sima

> 
> So there's two interesting cases here:
> 
> (1) P2 explicitly removes the file descriptor from the epoll instance
> via epoll_ctl(EPOLL_CTL_DEL). That removal affects both P1 and P2
> since the  pair is only registered once and it isn't
> marked whether it belongs to P1 and P2 fdtable.
> 
> So effectively fork()ing with epoll creates a weird shared state
> where removal of file descriptors that were registered before the
> fork() affects both child and parent.
> 
> I found that surprising even though I've worked with epoll quite
> extensively in low-level userspace.
> 
> (2) P2 doesn't close it's file descriptors. It just exits. Since removal
> of the file descriptor from the epoll instance isn't done during
> close() but during last fput() P1's epoll state remains unaffected
> by P2's sloppy exit because P1 still holds references to all files
> in its fdtable.
> 
> (Sidenote, if one ends up adding every more duped-fds into epoll
> instance that one doesn't explicitly close and all of them refer to
> the same file wouldn't one just be allocating new epitems that
> are kept around for a really long time?)
> 
> So if the removal of the fd would now be done during close() or during
> exit_files() when we call close_files() and since there's currently no
> way of differentiating whether P1 or P2 own that fd it would mean that
> (2) collapses into (1) and we'd always alter (1)'s epoll state. That
> would be a UAPI break.
> 
> So say we record the fdtable to get ownership of that file descriptor so
> P2 doesn't close anything in (2) that really belongs to P1 to fix that
> problem.
> 
> But afaict, that would break another possible use-case. Namely, where P1
> creates an epoll instance and registeres fds and then fork()s to create
> P2. Now P1 can exit and P2 takes over the epoll loop of P1. This
> wouldn't work anymore 

Re: [RFC PATCH net-next v8 02/14] net: page_pool: create hooks for custom page providers

[Pavel Begunkov]

On 5/8/24 15:25, Jason Gunthorpe wrote:

On Wed, May 08, 2024 at 12:30:07PM +0100, Pavel Begunkov wrote:


I'm not going to pretend to know about page pool details, but dmabuf
is the way to get the bulk of pages into a pool within the net stack's
allocator and keep that bulk properly refcounted while.> An object like
dmabuf is needed for the general case because there are
not going to be per-page references or otherwise available.


They are already pinned, memory is owned by the provider, io_uring
in this case, and it should not be freed circumventing io_uring,
and at this stage calling release_pages() is not such a hassle,
especially comparing to introducing an additional object.


Something needs to co-ordinate when the net stack's allocator is done
with the bulk of pages and when io_uring and do the final
put_user_page() to free it. DMABUF is not an unreasonable choice for
this.


When a page pool dies notifies io_uring via the ->destroy callback.
Vise versa, when io_uring wants to terminate zerocopy, it releases
the interface queue, which kills the page pool, ending in
->destroy again.
 

topic to me, and honestly hacking into the allocator free function
seems a bit weird..


Do you also think that DMA_BUF_IOCTL_SYNC is a weird hack, because
it "delays free" by pinning the dmabuf object and letting the user
read memory instead of copying it? I can find many examples


It seems to me the flow you want is for the driver to allocate a page,
put it on a rx ring, process it through the netstack, and deliver it
to io_uring. io_uring would then sit on the allocation until userspace
it done and return it back to the netstack allocator.


That's right, with a note that "driver allocating a page" is
not a alloc_page() but grabbing a user page/frag  the user
registered beforehand.


Hooking the free of the netstack allocator and then defering it seems


FWIW, it's not about page pool's ->release_page, it's a slow
path and in an ideal world wouldn't be called outside of tear
down.


like a weird and indirect way to get there. Why can't io_uring just be
the entity that does the final free and not mess with the logic
allocator?


Then the user has to do a syscall (e.g. via io_uring) to return pages,
and there we'd need to care how to put the pages efficiently, i.e.
hitting the page pool's fast path, e.g. by hoping napi is scheduled and
scheduled for the CPU we're running on, or maybe transferring the pages
to the right CPU first.

Compare it with userspace putting pages into a ring, and the allocator
taking from there when needed without any extra synchronisation and
hassle just because it's a sole consumer.

--
Pavel Begunkov

Re: [RFC PATCH net-next v8 02/14] net: page_pool: create hooks for custom page providers

[Daniel Vetter]

On Wed, May 08, 2024 at 12:35:52PM +0100, Pavel Begunkov wrote:
> On 5/8/24 08:16, Daniel Vetter wrote:
> > On Tue, May 07, 2024 at 08:32:47PM -0300, Jason Gunthorpe wrote:
> > > On Tue, May 07, 2024 at 08:35:37PM +0100, Pavel Begunkov wrote:
> > > > On 5/7/24 18:56, Jason Gunthorpe wrote:
> > > > > On Tue, May 07, 2024 at 06:25:52PM +0100, Pavel Begunkov wrote:
> > > > > > On 5/7/24 17:48, Jason Gunthorpe wrote:
> > > > > > > On Tue, May 07, 2024 at 09:42:05AM -0700, Mina Almasry wrote:
> > > > > > > 
> > > > > > > > 1. Align with devmem TCP to use udmabuf for your io_uring 
> > > > > > > > memory. I
> > > > > > > > think in the past you said it's a uapi you don't link but in 
> > > > > > > > the face
> > > > > > > > of this pushback you may want to reconsider.
> > > > > > > 
> > > > > > > dmabuf does not force a uapi, you can acquire your pages however 
> > > > > > > you
> > > > > > > want and wrap them up in a dmabuf. No uapi at all.
> > > > > > > 
> > > > > > > The point is that dmabuf already provides ops that do basically 
> > > > > > > what
> > > > > > > is needed here. We don't need ops calling ops just because 
> > > > > > > dmabuf's
> > > > > > > ops are not understsood or not perfect. Fixup dmabuf.
> > > > > > 
> > > > > > Those ops, for example, are used to efficiently return used buffers
> > > > > > back to the kernel, which is uapi, I don't see how dmabuf can be
> > > > > > fixed up to cover it.
> > > > > 
> > > > > Sure, but that doesn't mean you can't use dma buf for the other parts
> > > > > of the flow. The per-page lifetime is a different topic than the
> > > > > refcounting and access of the entire bulk of memory.
> > > > 
> > > > Ok, so if we're leaving uapi (and ops) and keep per page/sub-buffer as
> > > > is, the rest is resolving uptr -> pages, and passing it to page pool in
> > > > a convenient to page pool format (net_iov).
> > > 
> > > I'm not going to pretend to know about page pool details, but dmabuf
> > > is the way to get the bulk of pages into a pool within the net stack's
> > > allocator and keep that bulk properly refcounted while.
> > > 
> > > An object like dmabuf is needed for the general case because there are
> > > not going to be per-page references or otherwise available.
> > > 
> > > What you seem to want is to alter how the actual allocation flow works
> > > from that bulk of memory and delay the free. It seems like a different
> > > topic to me, and honestly hacking into the allocator free function
> > > seems a bit weird..
> > 
> > Also I don't see how it's an argument against dma-buf as the interface for
> 
> It's not, neither I said it is, but it is an argument against removing
> the network's page pool ops.
> 
> > all these, because e.g. ttm internally does have a page pool because
> > depending upon allocator, that's indeed beneficial. Other drm drivers have
> > more buffer-based concepts for opportunistically memory around, usually
> > by marking buffers that are just kept as cache as purgeable (which is a
> > concept that goes all the way to opengl/vulkan).
> 
> Because in this case it solves nothing and helps with nothing, quite
> the opposite. Just as well we can ask why NVMe doesn't wrap user pages
> into a dmabuf while doing IO.

Because the rules around memory reclaim, gfp nesting and guaranteed
forward progress don't match up for block i/o. I looked quite a bit into
gluing direct i/o into dma-buf because there's vulkan extensions for that,
and it's an absolute mess.
-Sima

> 
> > But these are all internals of the dma-buf exporter, the dma-buf api users
> > don't ever need to care.
> > -Sima
> 
> -- 
> Pavel Begunkov

-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch

Re: [PATCH v2 01/12] drm/amdgpu, drm/radeon: Make I2C terminology more inclusive

[Alex Deucher]

On Tue, May 7, 2024 at 2:32 PM Easwar Hariharan
 wrote:
>
> On 5/3/2024 11:13 AM, Easwar Hariharan wrote:
> > I2C v7, SMBus 3.2, and I3C 1.1.1 specifications have replaced "master/slave"
> > with more appropriate terms. Inspired by and following on to Wolfram's
> > series to fix drivers/i2c/[1], fix the terminology for users of
> > I2C_ALGOBIT bitbanging interface, now that the approved verbiage exists
> > in the specification.
> >
> > Compile tested, no functionality changes intended
> >
> > [1]: 
> > https://lore.kernel.org/all/20240322132619.6389-1-wsa+rene...@sang-engineering.com/
> >
> > Signed-off-by: Easwar Hariharan 
> > ---
> >  .../gpu/drm/amd/amdgpu/amdgpu_atomfirmware.c  |  8 +++---
> >  drivers/gpu/drm/amd/amdgpu/amdgpu_i2c.c   | 10 +++
> >  drivers/gpu/drm/amd/amdgpu/atombios_i2c.c |  8 +++---
> >  drivers/gpu/drm/amd/amdgpu/atombios_i2c.h |  2 +-
> >  drivers/gpu/drm/amd/amdgpu/smu_v11_0_i2c.c| 20 ++---
> >  .../gpu/drm/amd/display/dc/bios/bios_parser.c |  2 +-
> >  .../drm/amd/display/dc/bios/bios_parser2.c|  2 +-
> >  .../drm/amd/display/dc/core/dc_link_exports.c |  4 +--
> >  drivers/gpu/drm/amd/display/dc/dc.h   |  2 +-
> >  drivers/gpu/drm/amd/display/dc/dce/dce_i2c.c  |  4 +--
> >  .../display/include/grph_object_ctrl_defs.h   |  2 +-
> >  drivers/gpu/drm/amd/include/atombios.h|  2 +-
> >  drivers/gpu/drm/amd/include/atomfirmware.h| 26 -
> >  .../powerplay/hwmgr/vega20_processpptables.c  |  4 +--
> >  .../amd/pm/powerplay/inc/smu11_driver_if.h|  2 +-
> >  .../inc/pmfw_if/smu11_driver_if_arcturus.h|  2 +-
> >  .../inc/pmfw_if/smu11_driver_if_navi10.h  |  2 +-
> >  .../pmfw_if/smu11_driver_if_sienna_cichlid.h  |  2 +-
> >  .../inc/pmfw_if/smu13_driver_if_aldebaran.h   |  2 +-
> >  .../inc/pmfw_if/smu13_driver_if_v13_0_0.h |  2 +-
> >  .../inc/pmfw_if/smu13_driver_if_v13_0_7.h |  2 +-
> >  .../gpu/drm/amd/pm/swsmu/smu11/arcturus_ppt.c |  4 +--
> >  .../amd/pm/swsmu/smu11/sienna_cichlid_ppt.c   |  8 +++---
> >  drivers/gpu/drm/radeon/atombios.h | 16 +--
> >  drivers/gpu/drm/radeon/atombios_i2c.c |  4 +--
> >  drivers/gpu/drm/radeon/radeon_combios.c   | 28 +--
> >  drivers/gpu/drm/radeon/radeon_i2c.c   | 10 +++
> >  drivers/gpu/drm/radeon/radeon_mode.h  |  6 ++--
> >  28 files changed, 93 insertions(+), 93 deletions(-)
> >
>
> 
>
> Hello Christian, Daniel, David, others,
>
> Could you re-review v2 since the feedback provided in v0 [1] has now been 
> addressed? I can send v3 with
> all other feedback and signoffs from the other maintainers incorporated when 
> I have something for amdgpu
> and radeon.

This seems like a lot of churn.  Additionally, a bunch of these
headers are shared with other OSes, so it's possible some of the
changes may end up getting reverted accidently when we sync up or we
may add new headers in new code with the old nomenclature and then
we'd need to make sure to adjust it to make sure everything was
aligned again.  I would just as soon leave things as is, but I'm open
to acking them if there is a strong desire to update things.

Alex

[PATCH 0/6] drm/v3d: Improve Performance Counters handling

[Maíra Canal]

This series has the intention to address two issues with Performance Counters
on V3D:

1. Update the number of Performance Counters for V3D 7.1 

V3D 7.1 has 93 performance counters, while V3D 4.2 has only 87. Although the
series [1] enabled support for V3D 7.1, it didn’t replace the maximum number of
performance counters. This led to errors in user space as the Vulkan driver
updated the maximum number of performance counters, but the kernel didn’t. 

Currently, the user space can request values for performance counters that
are greater than 87 and the kernel will return an error instead of the values.
That’s why `dEQP-VK.query_pool.performance_query.*` currently fails on Mesa
CI [2]. This series intends to fix the `dEQP-VK.query_pool.performance_query.*`
fail.

2. Make the kernel able to provide the Performance Counter descriptions

Although all the management of the Performance Monitors is done through IOCTLs,
which means that the code is in the kernel, the performance counter descriptions
are in Mesa. This means two things: (#1) only Mesa has access to the 
descriptions
and (#2) we can have inconsistencies between the information provided by Mesa
and the kernel, as seen in the first issue addressed by this series.

To minimize the risk of inconsistencies, this series proposes to use the kernel
as a “single source of truth”. Therefore, if there are any changes to the
performance monitors, all the changes must be done only in the kernel. This
means that all information about the maximum number of performance counters and
all the descriptions will now be retrieved from the kernel. 

This series is coupled with a Mesa series [3] that enabled the use of the new
IOCTL. I appreciate any feedback from both the kernel and Mesa implementations.

[1] https://lore.kernel.org/dri-devel/20231031073859.25298-1-ito...@igalia.com/
[2] 
https://gitlab.freedesktop.org/mesa/mesa/-/commit/ea1f09a5f21839f4f3b93610b58507c4bd9b9b81
[3] https://gitlab.freedesktop.org/mairacanal/mesa/-/tree/v3dv/fix-perfcnt

Best Regards,
- Maíra Canal

Maíra Canal (6):
  drm/v3d: Add Performance Counters descriptions for V3D 4.2 and 7.1
  drm/v3d: Different V3D versions can have different number of perfcnt
  drm/v3d: Create a new V3D parameter for the maximum number of perfcnt
  drm/v3d: Create new IOCTL to expose performance counters information
  drm/v3d: Use V3D_MAX_COUNTERS instead of V3D_PERFCNT_NUM
  drm/v3d: Deprecate the use of the Performance Counters enum

 drivers/gpu/drm/v3d/v3d_drv.c |  11 +
 drivers/gpu/drm/v3d/v3d_drv.h |  14 +-
 drivers/gpu/drm/v3d/v3d_perfmon.c |  36 ++-
 .../gpu/drm/v3d/v3d_performance_counters.h| 208 ++
 drivers/gpu/drm/v3d/v3d_sched.c   |   2 +-
 include/uapi/drm/v3d_drm.h|  44 
 6 files changed, 312 insertions(+), 3 deletions(-)
 create mode 100644 drivers/gpu/drm/v3d/v3d_performance_counters.h

-- 
2.44.0

[PATCH 6/6] drm/v3d: Deprecate the use of the Performance Counters enum

[Maíra Canal]

The Performance Counters enum used to identify the index of each
performance counter and provide the total number of performance
counters (V3D_PERFCNT_NUM). But, this enum is only valid for V3D 4.2,
not for V3D 7.1.

As we implemented a new flexible structure to retrieve performance
counters information, we can deprecate this enum.

Signed-off-by: Maíra Canal 
---
 include/uapi/drm/v3d_drm.h | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/include/uapi/drm/v3d_drm.h b/include/uapi/drm/v3d_drm.h
index 0860ddb3d0b6..706b4dea1c45 100644
--- a/include/uapi/drm/v3d_drm.h
+++ b/include/uapi/drm/v3d_drm.h
@@ -603,6 +603,12 @@ struct drm_v3d_submit_cpu {
__u64 extensions;
 };
 
+/* The performance counters index represented by this enum are deprecated and
+ * must no longer be used. These counters are only valid for V3D 4.2.
+ *
+ * In order to check for performance counter information,
+ * use DRM_IOCTL_V3D_PERFMON_GET_COUNTER.
+ */
 enum {
V3D_PERFCNT_FEP_VALID_PRIMTS_NO_PIXELS,
V3D_PERFCNT_FEP_VALID_PRIMS,
-- 
2.44.0

[PATCH 2/6] drm/v3d: Different V3D versions can have different number of perfcnt

[Maíra Canal]

Currently, even though V3D 7.1 has 93 performance counters, it is not
possible to create counters bigger than 87, as
`v3d_perfmon_create_ioctl()` understands that counters bigger than 87
are invalid.

Therefore, create a device variable to expose the maximum
number of counters for a given V3D version and make
`v3d_perfmon_create_ioctl()` check this variable.

This commit fixes CTS failures in the performance queries tests
(dEQP-VK.query_pool.performance_query.*) [1]

Link: 
https://gitlab.freedesktop.org/mesa/mesa/-/commit/ea1f09a5f21839f4f3b93610b58507c4bd9b9b81
 [1]
Fixes: 6fd9487147c4 ("drm/v3d: add brcm,2712-v3d as a compatible V3D device")
Signed-off-by: Maíra Canal 
---
 drivers/gpu/drm/v3d/v3d_drv.c | 7 +++
 drivers/gpu/drm/v3d/v3d_drv.h | 5 +
 drivers/gpu/drm/v3d/v3d_perfmon.c | 3 ++-
 3 files changed, 14 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/v3d/v3d_drv.c b/drivers/gpu/drm/v3d/v3d_drv.c
index 28b7ddce7747..6b9dd26df9fe 100644
--- a/drivers/gpu/drm/v3d/v3d_drv.c
+++ b/drivers/gpu/drm/v3d/v3d_drv.c
@@ -294,6 +294,13 @@ static int v3d_platform_drm_probe(struct platform_device 
*pdev)
v3d->cores = V3D_GET_FIELD(ident1, V3D_HUB_IDENT1_NCORES);
WARN_ON(v3d->cores > 1); /* multicore not yet implemented */
 
+   if (v3d->ver >= 71)
+   v3d->max_counters = ARRAY_SIZE(v3d_v71_performance_counters);
+   else if (v3d->ver >= 42)
+   v3d->max_counters = ARRAY_SIZE(v3d_v42_performance_counters);
+   else
+   v3d->max_counters = 0;
+
v3d->reset = devm_reset_control_get_exclusive(dev, NULL);
if (IS_ERR(v3d->reset)) {
ret = PTR_ERR(v3d->reset);
diff --git a/drivers/gpu/drm/v3d/v3d_drv.h b/drivers/gpu/drm/v3d/v3d_drv.h
index 671375a3bb66..bd1e38f7d10a 100644
--- a/drivers/gpu/drm/v3d/v3d_drv.h
+++ b/drivers/gpu/drm/v3d/v3d_drv.h
@@ -104,6 +104,11 @@ struct v3d_dev {
int ver;
bool single_irq_line;
 
+   /* Different revisions of V3D have different total number of performance
+* counters
+*/
+   unsigned int max_counters;
+
void __iomem *hub_regs;
void __iomem *core_regs[3];
void __iomem *bridge_regs;
diff --git a/drivers/gpu/drm/v3d/v3d_perfmon.c 
b/drivers/gpu/drm/v3d/v3d_perfmon.c
index e1be7368b87d..f268d9466c0f 100644
--- a/drivers/gpu/drm/v3d/v3d_perfmon.c
+++ b/drivers/gpu/drm/v3d/v3d_perfmon.c
@@ -123,6 +123,7 @@ int v3d_perfmon_create_ioctl(struct drm_device *dev, void 
*data,
 {
struct v3d_file_priv *v3d_priv = file_priv->driver_priv;
struct drm_v3d_perfmon_create *req = data;
+   struct v3d_dev *v3d = v3d_priv->v3d;
struct v3d_perfmon *perfmon;
unsigned int i;
int ret;
@@ -134,7 +135,7 @@ int v3d_perfmon_create_ioctl(struct drm_device *dev, void 
*data,
 
/* Make sure all counters are valid. */
for (i = 0; i < req->ncounters; i++) {
-   if (req->counters[i] >= V3D_PERFCNT_NUM)
+   if (req->counters[i] >= v3d->max_counters)
return -EINVAL;
}
 
-- 
2.44.0

[PATCH 3/6] drm/v3d: Create a new V3D parameter for the maximum number of perfcnt

[Maíra Canal]

The maximum number of performance counters can change from version to
version and it's important for userspace to know this value, as it needs
to use the counters for performance queries. Therefore, expose the
maximum number of performance counters to userspace as a parameter.

Signed-off-by: Maíra Canal 
---
 drivers/gpu/drm/v3d/v3d_drv.c | 3 +++
 include/uapi/drm/v3d_drm.h| 1 +
 2 files changed, 4 insertions(+)

diff --git a/drivers/gpu/drm/v3d/v3d_drv.c b/drivers/gpu/drm/v3d/v3d_drv.c
index 6b9dd26df9fe..d2c1d5053132 100644
--- a/drivers/gpu/drm/v3d/v3d_drv.c
+++ b/drivers/gpu/drm/v3d/v3d_drv.c
@@ -94,6 +94,9 @@ static int v3d_get_param_ioctl(struct drm_device *dev, void 
*data,
case DRM_V3D_PARAM_SUPPORTS_CPU_QUEUE:
args->value = 1;
return 0;
+   case DRM_V3D_PARAM_MAX_PERF_COUNTERS:
+   args->value = v3d->max_counters;
+   return 0;
default:
DRM_DEBUG("Unknown parameter %d\n", args->param);
return -EINVAL;
diff --git a/include/uapi/drm/v3d_drm.h b/include/uapi/drm/v3d_drm.h
index dce1835eced4..215b01bb69c3 100644
--- a/include/uapi/drm/v3d_drm.h
+++ b/include/uapi/drm/v3d_drm.h
@@ -286,6 +286,7 @@ enum drm_v3d_param {
DRM_V3D_PARAM_SUPPORTS_PERFMON,
DRM_V3D_PARAM_SUPPORTS_MULTISYNC_EXT,
DRM_V3D_PARAM_SUPPORTS_CPU_QUEUE,
+   DRM_V3D_PARAM_MAX_PERF_COUNTERS,
 };
 
 struct drm_v3d_get_param {
-- 
2.44.0

[PATCH 5/6] drm/v3d: Use V3D_MAX_COUNTERS instead of V3D_PERFCNT_NUM

[Maíra Canal]

V3D_PERFCNT_NUM represents the maximum number of performance counters
for V3D 4.2, but not for V3D 7.1. This means that, if we use
V3D_PERFCNT_NUM, we might go out-of-bounds on V3D 7.1.

Therefore, use the number of performance counters on V3D 7.1 as the
maximum number of counters. This will allow us to create arrays on the
stack with reasonable size. Note that userspace must use the value
provided by DRM_V3D_PARAM_V3D_MAX_PERF_COUNTERS.

Signed-off-by: Maíra Canal 
---
 drivers/gpu/drm/v3d/v3d_drv.h   | 5 -
 drivers/gpu/drm/v3d/v3d_sched.c | 2 +-
 2 files changed, 5 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/v3d/v3d_drv.h b/drivers/gpu/drm/v3d/v3d_drv.h
index 44cfddedebde..556cbb400ba0 100644
--- a/drivers/gpu/drm/v3d/v3d_drv.h
+++ b/drivers/gpu/drm/v3d/v3d_drv.h
@@ -351,8 +351,11 @@ struct v3d_timestamp_query {
struct drm_syncobj *syncobj;
 };
 
+/* Maximum number of performance counters supported by any version of V3D */
+#define V3D_MAX_COUNTERS ARRAY_SIZE(v3d_v71_performance_counters)
+
 /* Number of perfmons required to handle all supported performance counters */
-#define V3D_MAX_PERFMONS DIV_ROUND_UP(V3D_PERFCNT_NUM, \
+#define V3D_MAX_PERFMONS DIV_ROUND_UP(V3D_MAX_COUNTERS, \
  DRM_V3D_MAX_PERF_COUNTERS)
 
 struct v3d_performance_query {
diff --git a/drivers/gpu/drm/v3d/v3d_sched.c b/drivers/gpu/drm/v3d/v3d_sched.c
index 7cd8c335cd9b..03df37a3acf5 100644
--- a/drivers/gpu/drm/v3d/v3d_sched.c
+++ b/drivers/gpu/drm/v3d/v3d_sched.c
@@ -490,7 +490,7 @@ v3d_write_performance_query_result(struct v3d_cpu_job *job, 
void *data, u32 quer
struct v3d_file_priv *v3d_priv = job->base.file->driver_priv;
struct v3d_dev *v3d = job->base.v3d;
struct v3d_perfmon *perfmon;
-   u64 counter_values[V3D_PERFCNT_NUM];
+   u64 counter_values[V3D_MAX_COUNTERS];
 
for (int i = 0; i < performance_query->nperfmons; i++) {
perfmon = v3d_perfmon_find(v3d_priv,
-- 
2.44.0

[PATCH 4/6] drm/v3d: Create new IOCTL to expose performance counters information

[Maíra Canal]

Userspace usually needs some information about the performance counters
available. Although we could replicate this information in the kernel
and user-space, let's use the kernel as the "single source of truth" to
avoid issues in the future (e.g. list of performance counters is updated
in user-space, but not in the kernel, generating invalid requests).

Therefore, create a new IOCTL to expose the performance counters
information, that is name, category, and description.

Signed-off-by: Maíra Canal 
---
 drivers/gpu/drm/v3d/v3d_drv.c |  1 +
 drivers/gpu/drm/v3d/v3d_drv.h |  2 ++
 drivers/gpu/drm/v3d/v3d_perfmon.c | 33 +++
 include/uapi/drm/v3d_drm.h| 37 +++
 4 files changed, 73 insertions(+)

diff --git a/drivers/gpu/drm/v3d/v3d_drv.c b/drivers/gpu/drm/v3d/v3d_drv.c
index d2c1d5053132..f7477488b1cc 100644
--- a/drivers/gpu/drm/v3d/v3d_drv.c
+++ b/drivers/gpu/drm/v3d/v3d_drv.c
@@ -211,6 +211,7 @@ static const struct drm_ioctl_desc v3d_drm_ioctls[] = {
DRM_IOCTL_DEF_DRV(V3D_PERFMON_DESTROY, v3d_perfmon_destroy_ioctl, 
DRM_RENDER_ALLOW),
DRM_IOCTL_DEF_DRV(V3D_PERFMON_GET_VALUES, v3d_perfmon_get_values_ioctl, 
DRM_RENDER_ALLOW),
DRM_IOCTL_DEF_DRV(V3D_SUBMIT_CPU, v3d_submit_cpu_ioctl, 
DRM_RENDER_ALLOW | DRM_AUTH),
+   DRM_IOCTL_DEF_DRV(V3D_PERFMON_GET_COUNTER, 
v3d_perfmon_get_counter_ioctl, DRM_RENDER_ALLOW),
 };
 
 static const struct drm_driver v3d_drm_driver = {
diff --git a/drivers/gpu/drm/v3d/v3d_drv.h b/drivers/gpu/drm/v3d/v3d_drv.h
index bd1e38f7d10a..44cfddedebde 100644
--- a/drivers/gpu/drm/v3d/v3d_drv.h
+++ b/drivers/gpu/drm/v3d/v3d_drv.h
@@ -582,6 +582,8 @@ int v3d_perfmon_destroy_ioctl(struct drm_device *dev, void 
*data,
  struct drm_file *file_priv);
 int v3d_perfmon_get_values_ioctl(struct drm_device *dev, void *data,
 struct drm_file *file_priv);
+int v3d_perfmon_get_counter_ioctl(struct drm_device *dev, void *data,
+ struct drm_file *file_priv);
 
 /* v3d_sysfs.c */
 int v3d_sysfs_init(struct device *dev);
diff --git a/drivers/gpu/drm/v3d/v3d_perfmon.c 
b/drivers/gpu/drm/v3d/v3d_perfmon.c
index f268d9466c0f..73e2bb8bdb7f 100644
--- a/drivers/gpu/drm/v3d/v3d_perfmon.c
+++ b/drivers/gpu/drm/v3d/v3d_perfmon.c
@@ -217,3 +217,36 @@ int v3d_perfmon_get_values_ioctl(struct drm_device *dev, 
void *data,
 
return ret;
 }
+
+int v3d_perfmon_get_counter_ioctl(struct drm_device *dev, void *data,
+ struct drm_file *file_priv)
+{
+   struct drm_v3d_perfmon_get_counter *req = data;
+   struct v3d_dev *v3d = to_v3d_dev(dev);
+   const struct v3d_perf_counter_desc *counter;
+
+   for (int i = 0; i < ARRAY_SIZE(req->reserved); i++) {
+   if (req->reserved[i] != 0)
+   return -EINVAL;
+   }
+
+   /* Make sure that the counter ID is valid */
+   if (req->counter >= v3d->max_counters)
+   return -EINVAL;
+
+   if (v3d->ver >= 71) {
+   WARN_ON(v3d->max_counters != 
ARRAY_SIZE(v3d_v71_performance_counters));
+   counter = _v71_performance_counters[req->counter];
+   } else if (v3d->ver >= 42) {
+   WARN_ON(v3d->max_counters != 
ARRAY_SIZE(v3d_v42_performance_counters));
+   counter = _v42_performance_counters[req->counter];
+   } else {
+   return -EOPNOTSUPP;
+   }
+
+   strscpy(req->name, counter->name, sizeof(req->name));
+   strscpy(req->category, counter->category, sizeof(req->category));
+   strscpy(req->description, counter->description, 
sizeof(req->description));
+
+   return 0;
+}
diff --git a/include/uapi/drm/v3d_drm.h b/include/uapi/drm/v3d_drm.h
index 215b01bb69c3..0860ddb3d0b6 100644
--- a/include/uapi/drm/v3d_drm.h
+++ b/include/uapi/drm/v3d_drm.h
@@ -42,6 +42,7 @@ extern "C" {
 #define DRM_V3D_PERFMON_DESTROY   0x09
 #define DRM_V3D_PERFMON_GET_VALUES0x0a
 #define DRM_V3D_SUBMIT_CPU0x0b
+#define DRM_V3D_PERFMON_GET_COUNTER   0x0c
 
 #define DRM_IOCTL_V3D_SUBMIT_CL   DRM_IOWR(DRM_COMMAND_BASE + 
DRM_V3D_SUBMIT_CL, struct drm_v3d_submit_cl)
 #define DRM_IOCTL_V3D_WAIT_BO DRM_IOWR(DRM_COMMAND_BASE + 
DRM_V3D_WAIT_BO, struct drm_v3d_wait_bo)
@@ -58,6 +59,8 @@ extern "C" {
 #define DRM_IOCTL_V3D_PERFMON_GET_VALUES  DRM_IOWR(DRM_COMMAND_BASE + 
DRM_V3D_PERFMON_GET_VALUES, \
   struct 
drm_v3d_perfmon_get_values)
 #define DRM_IOCTL_V3D_SUBMIT_CPU  DRM_IOW(DRM_COMMAND_BASE + 
DRM_V3D_SUBMIT_CPU, struct drm_v3d_submit_cpu)
+#define DRM_IOCTL_V3D_PERFMON_GET_COUNTER DRM_IOWR(DRM_COMMAND_BASE + 
DRM_V3D_PERFMON_GET_COUNTER, \
+  struct 
drm_v3d_perfmon_get_counter)
 
 #define DRM_V3D_SUBMIT_CL_FLUSH_CACHE 0x01
 #define 

[PATCH 1/6] drm/v3d: Add Performance Counters descriptions for V3D 4.2 and 7.1

[Maíra Canal]

Add name, category and description for each one of the 93 performance
counters available on V3D.

Note that V3D 4.2 has 87 performance counters, while V3D 7.1 has 93.
Therefore, there are two performance counters arrays. The index of the
performance counter for each V3D version is represented by its position
on the array.

Signed-off-by: Maíra Canal 
---
 drivers/gpu/drm/v3d/v3d_drv.h |   2 +
 .../gpu/drm/v3d/v3d_performance_counters.h| 208 ++
 2 files changed, 210 insertions(+)
 create mode 100644 drivers/gpu/drm/v3d/v3d_performance_counters.h

diff --git a/drivers/gpu/drm/v3d/v3d_drv.h b/drivers/gpu/drm/v3d/v3d_drv.h
index a2c516fe6d79..671375a3bb66 100644
--- a/drivers/gpu/drm/v3d/v3d_drv.h
+++ b/drivers/gpu/drm/v3d/v3d_drv.h
@@ -11,6 +11,8 @@
 #include 
 #include 
 
+#include "v3d_performance_counters.h"
+
 #include "uapi/drm/v3d_drm.h"
 
 struct clk;
diff --git a/drivers/gpu/drm/v3d/v3d_performance_counters.h 
b/drivers/gpu/drm/v3d/v3d_performance_counters.h
new file mode 100644
index ..72822205ebdc
--- /dev/null
+++ b/drivers/gpu/drm/v3d/v3d_performance_counters.h
@@ -0,0 +1,208 @@
+/* SPDX-License-Identifier: GPL-2.0+ */
+/*
+ * Copyright (C) 2024 Raspberry Pi
+ */
+#ifndef V3D_PERFORMANCE_COUNTERS_H
+#define V3D_PERFORMANCE_COUNTERS_H
+
+/* Holds a description of a given performance counter. The index of performance
+ * counter is given by the array on v3d_performance_counter.h
+ */
+struct v3d_perf_counter_desc {
+   /* Category of the counter */
+   char category[32];
+
+   /* Name of the counter */
+   char name[64];
+
+   /* Description of the counter */
+   char description[256];
+};
+
+static const struct v3d_perf_counter_desc v3d_v71_performance_counters[] = {
+   {"CORE", "cycle-count", "[CORE] Cycle counter"},
+   {"CORE", "core-active", "[CORE] Bin/Render/Compute active cycles"},
+   {"CLE", "CLE-bin-thread-active-cycles", "[CLE] Bin thread active 
cycles"},
+   {"CLE", "CLE-render-thread-active-cycles", "[CLE] Render thread active 
cycles"},
+   {"CORE", "compute-active-cycles", "[CORE] Compute active cycles"},
+   {"FEP", "FEP-valid-primitives-no-rendered-pixels", "[FEP] Valid 
primitives that result in no rendered pixels, for all rendered tiles"},
+   {"FEP", "FEP-valid-primitives-rendered-pixels", "[FEP] Valid primitives 
for all rendered tiles (primitives may be counted in more than one tile)"},
+   {"FEP", "FEP-clipped-quads", "[FEP] Early-Z/Near/Far clipped quads"},
+   {"FEP", "FEP-valid-quads", "[FEP] Valid quads"},
+   {"TLB", "TLB-quads-not-passing-stencil-test", "[TLB] Quads with no 
pixels passing the stencil test"},
+   {"TLB", "TLB-quads-not-passing-z-and-stencil-test", "[TLB] Quads with 
no pixels passing the Z and stencil tests"},
+   {"TLB", "TLB-quads-passing-z-and-stencil-test", "[TLB] Quads with any 
pixels passing the Z and stencil tests"},
+   {"TLB", "TLB-quads-written-to-color-buffer", "[TLB] Quads with valid 
pixels written to colour buffer"},
+   {"TLB", "TLB-partial-quads-written-to-color-buffer", "[TLB] Partial 
quads written to the colour buffer"},
+   {"PTB", "PTB-primitives-need-clipping", "[PTB] Primitives that need 
clipping"},
+   {"PTB", "PTB-primitives-discarded-outside-viewport", "[PTB] Primitives 
discarded by being outside the viewport"},
+   {"PTB", "PTB-primitives-binned", "[PTB] Total primitives binned"},
+   {"PTB", "PTB-primitives-discarded-reversed", "[PTB] Primitives that are 
discarded because they are reversed"},
+   {"QPU", "QPU-total-instr-cache-hit", "[QPU] Total instruction cache 
hits for all slices"},
+   {"QPU", "QPU-total-instr-cache-miss", "[QPU] Total instruction cache 
misses for all slices"},
+   {"QPU", "QPU-total-uniform-cache-hit", "[QPU] Total uniforms cache hits 
for all slices"},
+   {"QPU", "QPU-total-uniform-cache-miss", "[QPU] Total uniforms cache 
misses for all slices"},
+   {"TMU", "TMU-active-cycles", "[TMU] Active cycles"},
+   {"TMU", "TMU-stalled-cycles", "[TMU] Stalled cycles"},
+   {"TMU", "TMU-total-text-quads-access", "[TMU] Total texture cache 
accesses"},
+   {"TMU", "TMU-cache-x4-active-cycles", "[TMU] Cache active cycles for x4 
access"},
+   {"TMU", "TMU-cache-x4-stalled-cycles", "[TMU] Cache stalled cycles for 
x4 access"},
+   {"TMU", "TMU-total-text-quads-x4-access", "[TMU] Total texture cache x4 
access"},
+   {"L2T", "L2T-total-cache-hit", "[L2T] Total Level 2 cache hits"},
+   {"L2T", "L2T-total-cache-miss", "[L2T] Total Level 2 cache misses"},
+   {"L2T", "L2T-local", "[L2T] Local mode access"},
+   {"L2T", "L2T-writeback", "[L2T] Writeback"},
+   {"L2T", "L2T-zero", "[L2T] Zero"},
+   {"L2T", "L2T-merge", "[L2T] Merge"},
+   {"L2T", "L2T-fill", "[L2T] Fill"},
+   {"L2T", "L2T-stalls-no-wid", "[L2T] Stalls because no WID available"},
+   {"L2T", "L2T-stalls-no-rid", "[L2T] Stalls