RE: [PATCH 0/5] imx-lcdif modeset changes
Hi Lucas, Thank you for the patch series. On Wednesday, September 20, 2023 6:31 PM Lucas Stach wrote: > This changes the modeset flow in the imx-lcdif driver to work > better with runtime PM and get rid of duplicate hardware setup. I'm assuming the duplicate hardware setup is calling lcdif_plane_primary_atomic_update() in lcdif_crtc_atomic_enable() as I mentioned in [1]. If that's the case, it looks like the call is inevitable due to CRTC/bridge enablement sequence. See detail comments for patch 2/5. Regards, Liu Ying > > This series is a result of looking a bit more into the issue and > feedback received on some earlier patches [1]. > > Regards, > Lucas > > [1] > https://lore.k/ > ernel.org%2Fall%2FCAOcKUNWMU6tjWwtnU%2BCOggrr--G19EvZaHrxAp0- > 0i5dK394jg%40mail.gmail.com%2F&data=05%7C01%7Cvictor.liu%40nxp.com > %7C3dedd482af2a4a3d9d3f08dbb9c4bfe8%7C686ea1d3bc2b4c6fa92cd99c5c > 301635%7C0%7C0%7C638308026921385573%7CUnknown%7CTWFpbGZsb3d > 8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3 > D%7C3000%7C%7C%7C&sdata=%2BxMk6cO%2Fxpoip2xChoFcHtkhLWNmi%2 > FngtNm%2BBu2kr6M%3D&reserved=0 > > Lucas Stach (5): > drm: lcdif: improve burst size configuration comment > drm: lcdif: move controller enable into atomic_flush > drm: lcdif: remove superfluous setup of framebuffer DMA address > drm: lcdif: move pitch setup to plane atomic update > drm: lcdif: force modeset when FB format changes > > drivers/gpu/drm/mxsfb/lcdif_drv.c | 18 +++- > drivers/gpu/drm/mxsfb/lcdif_kms.c | 68 +-- > 2 files changed, 55 insertions(+), 31 deletions(-) > > -- > 2.39.2
Re: [PATCH drm-misc-next v4 1/8] drm/gpuvm: rename struct drm_gpuva_manager to struct drm_gpuvm
Am 20.09.23 um 16:42 schrieb Danilo Krummrich:
Rename struct drm_gpuva_manager to struct drm_gpuvm including
corresponding functions. This way the GPUVA manager's structures align
very well with the documentation of VM_BIND [1] and VM_BIND locking [2].
It also provides a better foundation for the naming of data structures
and functions introduced for implementing a common dma-resv per GPU-VM
including tracking of external and evicted objects in subsequent
patches.
[1] Documentation/gpu/drm-vm-bind-async.rst
[2] Documentation/gpu/drm-vm-bind-locking.rst
Cc: Thomas Hellström
Cc: Matthew Brost
Signed-off-by: Danilo Krummrich
Not sure if that name is better or worse, but from the handling I
suggest to have this patch separately pushed to drm-misc-next.
Feel free to add my Acked-by for pushing this.
Regards,
Christian.
---
drivers/gpu/drm/Makefile | 2 +-
drivers/gpu/drm/drm_debugfs.c | 16 +-
.../gpu/drm/{drm_gpuva_mgr.c => drm_gpuvm.c} | 400 +-
drivers/gpu/drm/nouveau/nouveau_exec.c| 2 +-
drivers/gpu/drm/nouveau/nouveau_uvmm.c| 24 +-
drivers/gpu/drm/nouveau/nouveau_uvmm.h| 6 +-
include/drm/drm_debugfs.h | 6 +-
include/drm/{drm_gpuva_mgr.h => drm_gpuvm.h} | 153 ---
8 files changed, 304 insertions(+), 305 deletions(-)
rename drivers/gpu/drm/{drm_gpuva_mgr.c => drm_gpuvm.c} (78%)
rename include/drm/{drm_gpuva_mgr.h => drm_gpuvm.h} (78%)
diff --git a/drivers/gpu/drm/Makefile b/drivers/gpu/drm/Makefile
index 215e78e79125..7a84b3cddeab 100644
--- a/drivers/gpu/drm/Makefile
+++ b/drivers/gpu/drm/Makefile
@@ -45,7 +45,7 @@ drm-y := \
drm_vblank.o \
drm_vblank_work.o \
drm_vma_manager.o \
- drm_gpuva_mgr.o \
+ drm_gpuvm.o \
drm_writeback.o
drm-$(CONFIG_DRM_LEGACY) += \
drm_agpsupport.o \
diff --git a/drivers/gpu/drm/drm_debugfs.c b/drivers/gpu/drm/drm_debugfs.c
index 44ecd7d0daac..f291fb4b359f 100644
--- a/drivers/gpu/drm/drm_debugfs.c
+++ b/drivers/gpu/drm/drm_debugfs.c
@@ -40,7 +40,7 @@
#include
#include
#include
-#include
+#include
#include "drm_crtc_internal.h"
#include "drm_internal.h"
@@ -189,31 +189,31 @@ static const struct file_operations drm_debugfs_fops = {
/**
* drm_debugfs_gpuva_info - dump the given DRM GPU VA space
* @m: pointer to the &seq_file to write
- * @mgr: the &drm_gpuva_manager representing the GPU VA space
+ * @gpuvm: the &drm_gpuvm representing the GPU VA space
*
* Dumps the GPU VA mappings of a given DRM GPU VA manager.
*
* For each DRM GPU VA space drivers should call this function from their
* &drm_info_list's show callback.
*
- * Returns: 0 on success, -ENODEV if the &mgr is not initialized
+ * Returns: 0 on success, -ENODEV if the &gpuvm is not initialized
*/
int drm_debugfs_gpuva_info(struct seq_file *m,
- struct drm_gpuva_manager *mgr)
+ struct drm_gpuvm *gpuvm)
{
- struct drm_gpuva *va, *kva = &mgr->kernel_alloc_node;
+ struct drm_gpuva *va, *kva = &gpuvm->kernel_alloc_node;
- if (!mgr->name)
+ if (!gpuvm->name)
return -ENODEV;
seq_printf(m, "DRM GPU VA space (%s) [0x%016llx;0x%016llx]\n",
- mgr->name, mgr->mm_start, mgr->mm_start + mgr->mm_range);
+ gpuvm->name, gpuvm->mm_start, gpuvm->mm_start +
gpuvm->mm_range);
seq_printf(m, "Kernel reserved node [0x%016llx;0x%016llx]\n",
kva->va.addr, kva->va.addr + kva->va.range);
seq_puts(m, "\n");
seq_puts(m, " VAs | start | range | end
| object | object offset\n");
seq_puts(m,
"-\n");
- drm_gpuva_for_each_va(va, mgr) {
+ drm_gpuvm_for_each_va(va, gpuvm) {
if (unlikely(va == kva))
continue;
diff --git a/drivers/gpu/drm/drm_gpuva_mgr.c b/drivers/gpu/drm/drm_gpuvm.c
similarity index 78%
rename from drivers/gpu/drm/drm_gpuva_mgr.c
rename to drivers/gpu/drm/drm_gpuvm.c
index f86bfad74ff8..7074bcad5b28 100644
--- a/drivers/gpu/drm/drm_gpuva_mgr.c
+++ b/drivers/gpu/drm/drm_gpuvm.c
@@ -25,7 +25,7 @@
*
*/
-#include
+#include
#include
#include
@@ -33,8 +33,8 @@
/**
* DOC: Overview
*
- * The DRM GPU VA Manager, represented by struct drm_gpuva_manager keeps track
- * of a GPU's virtual address (VA) space and manages the corresponding virtual
+ * The DRM GPU VA Manager, represented by struct drm_gpuvm keeps track of a
+ * GPU's virtual address (VA) space and manages the corresponding virtual
* mappings represented by &drm_gpuva objects. It also keeps track of the
* mapping's backing &drm_gem_object buffers.
*
@@ -47,28 +47,28 @@
* The GPU VA manager internally uses a rb-
[PATCH v6 6/6] drm/i915/panelreplay: Debugfs support for panel replay
Add debugfs support which will print source and sink status
per connector basis.
Cc: Jouni Högander
Signed-off-by: Animesh Manna
---
drivers/gpu/drm/i915/display/intel_psr.c | 132 +--
1 file changed, 97 insertions(+), 35 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_psr.c
b/drivers/gpu/drm/i915/display/intel_psr.c
index 67337b4a421b..65f22e4ff3b2 100644
--- a/drivers/gpu/drm/i915/display/intel_psr.c
+++ b/drivers/gpu/drm/i915/display/intel_psr.c
@@ -2834,6 +2834,25 @@ static int psr_get_status_and_error_status(struct
intel_dp *intel_dp,
return 0;
}
+static int panel_replay_get_status_and_error_status(struct intel_dp *intel_dp,
+ u8 *status, u8
*error_status)
+{
+ struct drm_dp_aux *aux = &intel_dp->aux;
+ int ret;
+
+ ret = drm_dp_dpcd_readb(aux, DP_SINK_DEVICE_PR_AND_FRAME_LOCK_STATUS,
status);
+ if (ret != 1)
+ return ret;
+
+ ret = drm_dp_dpcd_readb(aux, DP_PANEL_REPLAY_ERROR_STATUS,
error_status);
+ if (ret != 1)
+ return ret;
+
+ *status = *status & DP_PSR_SINK_STATE_MASK;
+
+ return 0;
+}
+
static void psr_alpm_check(struct intel_dp *intel_dp)
{
struct drm_i915_private *dev_priv = dp_to_i915(intel_dp);
@@ -3046,7 +3065,7 @@ psr_source_status(struct intel_dp *intel_dp, struct
seq_file *m)
status = live_status[status_val];
}
- seq_printf(m, "Source PSR status: %s [0x%08x]\n", status, val);
+ seq_printf(m, "Source PSR/PanelReplay status: %s [0x%08x]\n", status,
val);
}
static int intel_psr_status(struct seq_file *m, struct intel_dp *intel_dp)
@@ -3059,18 +3078,23 @@ static int intel_psr_status(struct seq_file *m, struct
intel_dp *intel_dp)
bool enabled;
u32 val;
- seq_printf(m, "Sink support: %s", str_yes_no(psr->sink_support));
- if (psr->sink_support)
+ seq_printf(m, "Sink support: PSR = %s, Panel Replay = %s",
+ str_yes_no(psr->sink_support),
+ str_yes_no(psr->sink_panel_replay_support));
+
+ if (psr->sink_support || psr->sink_panel_replay_support)
seq_printf(m, " [0x%02x]", intel_dp->psr_dpcd[0]);
seq_puts(m, "\n");
- if (!psr->sink_support)
+ if (!(psr->sink_support || psr->sink_panel_replay_support))
return 0;
wakeref = intel_runtime_pm_get(&dev_priv->runtime_pm);
mutex_lock(&psr->lock);
- if (psr->enabled)
+ if (psr->panel_replay_enabled)
+ status = "Panel Replay Enabled";
+ else if (psr->enabled)
status = psr->psr2_enabled ? "PSR2 enabled" : "PSR1 enabled";
else
status = "disabled";
@@ -3083,14 +3107,17 @@ static int intel_psr_status(struct seq_file *m, struct
intel_dp *intel_dp)
goto unlock;
}
- if (psr->psr2_enabled) {
+ if (psr->panel_replay_enabled) {
+ val = intel_de_read(dev_priv, TRANS_DP2_CTL(cpu_transcoder));
+ enabled = val & TRANS_DP2_PANEL_REPLAY_ENABLE;
+ } else if (psr->psr2_enabled) {
val = intel_de_read(dev_priv, EDP_PSR2_CTL(cpu_transcoder));
enabled = val & EDP_PSR2_ENABLE;
} else {
val = intel_de_read(dev_priv, psr_ctl_reg(dev_priv,
cpu_transcoder));
enabled = val & EDP_PSR_ENABLE;
}
- seq_printf(m, "Source PSR ctl: %s [0x%08x]\n",
+ seq_printf(m, "Source PSR/PanelReplay ctl: %s [0x%08x]\n",
str_enabled_disabled(enabled), val);
psr_source_status(intel_dp, m);
seq_printf(m, "Busy frontbuffer bits: 0x%08x\n",
@@ -3232,6 +3259,7 @@ static int i915_psr_sink_status_show(struct seq_file *m,
void *data)
{
struct intel_connector *connector = m->private;
struct intel_dp *intel_dp = intel_attached_dp(connector);
+ struct intel_psr *psr = &intel_dp->psr;
static const char * const sink_status[] = {
"inactive",
"transition to active, capture and display",
@@ -3242,45 +3270,82 @@ static int i915_psr_sink_status_show(struct seq_file
*m, void *data)
"reserved",
"sink internal error",
};
+ static const char * const panel_replay_status[] = {
+ "Sink device frame is locked to the Source device",
+ "Sink device is coasting, using the VTotal target",
+ "Sink device is governing the frame rate (frame rate unlock is
granted)",
+ "Sink device in the process of re-locking with the Source
device",
+ };
const char *str;
int ret;
u8 status, error_status;
- if (!CAN_PSR(intel_dp)) {
- seq_puts(m, "PSR Unsupported\n");
+ if (!(CAN_PSR(intel_dp) || CAN_PANEL_REPLAY(intel_dp))) {
+ seq_puts(m, "PSR/Panel-Replay Unsu
[PATCH v6 5/6] drm/i915/panelreplay: enable/disable panel replay
TRANS_DP2_CTL register is programmed to enable panel replay from source
and sink is enabled through panel replay dpcd configuration address.
Bspec: 1407940617
v1: Initial version.
v2:
- Use pr_* flags instead psr_* flags. [Jouni]
- Remove intel_dp_is_edp check as edp1.5 also has panel replay. [Jouni]
v3: Cover letter updated and selective fetch condition check is added
before updating its bit in PSR2_MAN_TRK_CTL register. [Jouni]
v4: Selective fetch related PSR2_MAN_TRK_CTL programmming dropped. [Jouni]
v5: Added PSR2_MAN_TRK_CTL programming as needed for Continuous Full
Frame (CFF) update.
Note: Initial plan is to enable panel replay in full-screen live active
frame update mode. In a incremental approach panel replay will be enabled
in selctive update mode if there is any gap in curent implementation.
Cc: Jouni Högander
Signed-off-by: Animesh Manna
---
drivers/gpu/drm/i915/display/intel_ddi.c | 7 +-
.../drm/i915/display/intel_display_types.h| 1 +
drivers/gpu/drm/i915/display/intel_psr.c | 65 ++-
3 files changed, 56 insertions(+), 17 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_ddi.c
b/drivers/gpu/drm/i915/display/intel_ddi.c
index 4668de45d6fe..203c56c5e208 100644
--- a/drivers/gpu/drm/i915/display/intel_ddi.c
+++ b/drivers/gpu/drm/i915/display/intel_ddi.c
@@ -2717,10 +2717,15 @@ static void intel_ddi_pre_enable_dp(struct
intel_atomic_state *state,
const struct drm_connector_state
*conn_state)
{
struct drm_i915_private *dev_priv = to_i915(encoder->base.dev);
+ struct intel_dp *intel_dp = enc_to_intel_dp(encoder);
- if (HAS_DP20(dev_priv))
+ if (HAS_DP20(dev_priv)) {
intel_dp_128b132b_sdp_crc16(enc_to_intel_dp(encoder),
crtc_state);
+ if (crtc_state->has_panel_replay)
+ drm_dp_dpcd_writeb(&intel_dp->aux, PANEL_REPLAY_CONFIG,
+ DP_PANEL_REPLAY_ENABLE);
+ }
if (DISPLAY_VER(dev_priv) >= 14)
mtl_ddi_pre_enable_dp(state, encoder, crtc_state, conn_state);
diff --git a/drivers/gpu/drm/i915/display/intel_display_types.h
b/drivers/gpu/drm/i915/display/intel_display_types.h
index 3eadd8e12f63..1cf302e9deed 100644
--- a/drivers/gpu/drm/i915/display/intel_display_types.h
+++ b/drivers/gpu/drm/i915/display/intel_display_types.h
@@ -1698,6 +1698,7 @@ struct intel_psr {
u16 su_y_granularity;
bool source_panel_replay_support;
bool sink_panel_replay_support;
+ bool panel_replay_enabled;
u32 dc3co_exitline;
u32 dc3co_exit_delay;
struct delayed_work dc3co_work;
diff --git a/drivers/gpu/drm/i915/display/intel_psr.c
b/drivers/gpu/drm/i915/display/intel_psr.c
index a59f13c29c3d..67337b4a421b 100644
--- a/drivers/gpu/drm/i915/display/intel_psr.c
+++ b/drivers/gpu/drm/i915/display/intel_psr.c
@@ -607,8 +607,11 @@ static void intel_psr_enable_sink(struct intel_dp
*intel_dp)
struct drm_i915_private *dev_priv = dp_to_i915(intel_dp);
u8 dpcd_val = DP_PSR_ENABLE;
- /* Enable ALPM at sink for psr2 */
+ if (intel_dp->psr.panel_replay_enabled)
+ return;
+
if (intel_dp->psr.psr2_enabled) {
+ /* Enable ALPM at sink for psr2 */
drm_dp_dpcd_writeb(&intel_dp->aux, DP_RECEIVER_ALPM_CONFIG,
DP_ALPM_ENABLE |
DP_ALPM_LOCK_ERROR_IRQ_HPD_ENABLE);
@@ -758,6 +761,17 @@ static int psr2_block_count(struct intel_dp *intel_dp)
return psr2_block_count_lines(intel_dp) / 4;
}
+static void dg2_activate_panel_replay(struct intel_dp *intel_dp)
+{
+ struct drm_i915_private *dev_priv = dp_to_i915(intel_dp);
+
+ intel_de_rmw(dev_priv, PSR2_MAN_TRK_CTL(intel_dp->psr.transcoder),
+0, ADLP_PSR2_MAN_TRK_CTL_SF_CONTINUOS_FULL_FRAME);
+
+ intel_de_rmw(dev_priv, TRANS_DP2_CTL(intel_dp->psr.transcoder), 0,
+TRANS_DP2_PANEL_REPLAY_ENABLE);
+}
+
static void hsw_activate_psr2(struct intel_dp *intel_dp)
{
struct drm_i915_private *dev_priv = dp_to_i915(intel_dp);
@@ -1322,18 +1336,23 @@ void intel_psr_get_config(struct intel_encoder *encoder,
return;
intel_dp = &dig_port->dp;
- if (!CAN_PSR(intel_dp))
+ if (!(CAN_PSR(intel_dp) || CAN_PANEL_REPLAY(intel_dp)))
return;
mutex_lock(&intel_dp->psr.lock);
if (!intel_dp->psr.enabled)
goto unlock;
- /*
-* Not possible to read EDP_PSR/PSR2_CTL registers as it is
-* enabled/disabled because of frontbuffer tracking and others.
-*/
- pipe_config->has_psr = true;
+ if (intel_dp->psr.panel_replay_enabled) {
+ pipe_config->has_panel_replay = true;
+ } else {
+ /*
+* Not possible to read
[PATCH v6 3/6] drm/i915/panelreplay: Initializaton and compute config for panel replay
Modify existing PSR implementation to enable panel replay feature of DP 2.0
which is similar to PSR feature of EDP panel. There is different DPCD
address to check panel capability compare to PSR and vsc sdp header
is different.
v1: Initial version.
v2:
- Set source_panel_replay_support flag under HAS_PANEL_REPLAY()
condition check. [Jouni]
- Code restructured around intel_panel_replay_init
and renamed to intel_panel_replay_init_dpcd. [Jouni]
- Remove the initial code modification around has_psr2 flag. [Jouni]
- Add CAN_PANEL_REPLAY() in intel_encoder_can_psr which is used to
enable in intel_psr_post_plane_update. [Jouni]
v3:
- Initialize both psr and panel-replay. [Jouni]
- Initialize both panel replay and psr if detected. [Jouni]
- Refactoring psr function by introducing _psr_compute_config(). [Jouni]
- Add check for !is_edp while deriving source_panel_replay_support. [Jouni]
- Enable panel replay dpcd initialization in a separate patch. [Jouni]
v4:
- HAS_PANEL_REPLAY() check not needed during sink capability check. [Jouni]
- Set either panel replay source support or psr. [Jouni]
v5:
- HAS_PANEL_REPLAY() removed and use HAS_DP20() instead. [Jouni]
- Move psr related code to intel_psr.c. [Jani]
- Reset sink_panel_replay_support flag during disconnection. [Jani]
v6: return statement restored which is removed by misatke. [Jouni]
Cc: Jouni Högander
Signed-off-by: Animesh Manna
---
.../drm/i915/display/intel_display_types.h| 14 +--
drivers/gpu/drm/i915/display/intel_dp.c | 50 --
drivers/gpu/drm/i915/display/intel_dp_mst.c | 3 +
drivers/gpu/drm/i915/display/intel_psr.c | 95 ++-
drivers/gpu/drm/i915/display/intel_psr.h | 7 ++
5 files changed, 123 insertions(+), 46 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_display_types.h
b/drivers/gpu/drm/i915/display/intel_display_types.h
index 2213ad6c00da..3eadd8e12f63 100644
--- a/drivers/gpu/drm/i915/display/intel_display_types.h
+++ b/drivers/gpu/drm/i915/display/intel_display_types.h
@@ -1203,6 +1203,7 @@ struct intel_crtc_state {
bool has_psr2;
bool enable_psr2_sel_fetch;
bool req_psr2_sdp_prior_scanline;
+ bool has_panel_replay;
bool wm_level_disabled;
u32 dc3co_exitline;
u16 su_y_granularity;
@@ -1695,6 +1696,8 @@ struct intel_psr {
bool irq_aux_error;
u16 su_w_granularity;
u16 su_y_granularity;
+ bool source_panel_replay_support;
+ bool sink_panel_replay_support;
u32 dc3co_exitline;
u32 dc3co_exit_delay;
struct delayed_work dc3co_work;
@@ -1982,17 +1985,6 @@ dp_to_lspcon(struct intel_dp *intel_dp)
#define dp_to_i915(__intel_dp)
to_i915(dp_to_dig_port(__intel_dp)->base.base.dev)
-#define CAN_PSR(intel_dp) ((intel_dp)->psr.sink_support && \
- (intel_dp)->psr.source_support)
-
-static inline bool intel_encoder_can_psr(struct intel_encoder *encoder)
-{
- if (!intel_encoder_is_dp(encoder))
- return false;
-
- return CAN_PSR(enc_to_intel_dp(encoder));
-}
-
static inline struct intel_digital_port *
hdmi_to_dig_port(struct intel_hdmi *intel_hdmi)
{
diff --git a/drivers/gpu/drm/i915/display/intel_dp.c
b/drivers/gpu/drm/i915/display/intel_dp.c
index f16d9fa88fe1..1c7d9b14fd1c 100644
--- a/drivers/gpu/drm/i915/display/intel_dp.c
+++ b/drivers/gpu/drm/i915/display/intel_dp.c
@@ -2338,12 +2338,22 @@ static void intel_dp_compute_vsc_colorimetry(const
struct intel_crtc_state *crtc
struct intel_crtc *crtc = to_intel_crtc(crtc_state->uapi.crtc);
struct drm_i915_private *dev_priv = to_i915(crtc->base.dev);
- /*
-* Prepare VSC Header for SU as per DP 1.4 spec, Table 2-118
-* VSC SDP supporting 3D stereo, PSR2, and Pixel Encoding/
-* Colorimetry Format indication.
-*/
- vsc->revision = 0x5;
+ if (crtc_state->has_panel_replay) {
+ /*
+* Prepare VSC Header for SU as per DP 2.0 spec, Table 2-223
+* VSC SDP supporting 3D stereo, Panel Replay, and Pixel
+* Encoding/Colorimetry Format indication.
+*/
+ vsc->revision = 0x7;
+ } else {
+ /*
+* Prepare VSC Header for SU as per DP 1.4 spec, Table 2-118
+* VSC SDP supporting 3D stereo, PSR2, and Pixel Encoding/
+* Colorimetry Format indication.
+*/
+ vsc->revision = 0x5;
+ }
+
vsc->length = 0x13;
/* DP 1.4a spec, Table 2-120 */
@@ -2452,6 +2462,21 @@ void intel_dp_compute_psr_vsc_sdp(struct intel_dp
*intel_dp,
vsc->revision = 0x4;
vsc->length = 0xe;
}
+ } else if (crtc_state->has_panel_replay) {
+ if (intel_dp->psr.colorimetry_support &&
+ intel_dp_needs_vsc_sdp(crtc_state, conn_state)) {
+ /* [P
[PATCH v6 2/6] drm/i915/psr: Move psr specific dpcd init into own function
From: Jouni Högander
This patch is preparing adding panel replay specific dpcd init.
Signed-off-by: Jouni Högander
---
drivers/gpu/drm/i915/display/intel_psr.c | 41 +---
1 file changed, 23 insertions(+), 18 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_psr.c
b/drivers/gpu/drm/i915/display/intel_psr.c
index 850b11f20285..71fe2e4aca85 100644
--- a/drivers/gpu/drm/i915/display/intel_psr.c
+++ b/drivers/gpu/drm/i915/display/intel_psr.c
@@ -474,27 +474,22 @@ static void intel_dp_get_su_granularity(struct intel_dp
*intel_dp)
intel_dp->psr.su_y_granularity = y;
}
-void intel_psr_init_dpcd(struct intel_dp *intel_dp)
+static void _psr_init_dpcd(struct intel_dp *intel_dp)
{
- struct drm_i915_private *dev_priv =
+ struct drm_i915_private *i915 =
to_i915(dp_to_dig_port(intel_dp)->base.base.dev);
- drm_dp_dpcd_read(&intel_dp->aux, DP_PSR_SUPPORT, intel_dp->psr_dpcd,
-sizeof(intel_dp->psr_dpcd));
-
- if (!intel_dp->psr_dpcd[0])
- return;
- drm_dbg_kms(&dev_priv->drm, "eDP panel supports PSR version %x\n",
+ drm_dbg_kms(&i915->drm, "eDP panel supports PSR version %x\n",
intel_dp->psr_dpcd[0]);
if (drm_dp_has_quirk(&intel_dp->desc, DP_DPCD_QUIRK_NO_PSR)) {
- drm_dbg_kms(&dev_priv->drm,
+ drm_dbg_kms(&i915->drm,
"PSR support not currently available for this
panel\n");
return;
}
if (!(intel_dp->edp_dpcd[1] & DP_EDP_SET_POWER_CAP)) {
- drm_dbg_kms(&dev_priv->drm,
+ drm_dbg_kms(&i915->drm,
"Panel lacks power state control, PSR cannot be
enabled\n");
return;
}
@@ -503,8 +498,8 @@ void intel_psr_init_dpcd(struct intel_dp *intel_dp)
intel_dp->psr.sink_sync_latency =
intel_dp_get_sink_sync_latency(intel_dp);
- if (DISPLAY_VER(dev_priv) >= 9 &&
- (intel_dp->psr_dpcd[0] == DP_PSR2_WITH_Y_COORD_IS_SUPPORTED)) {
+ if (DISPLAY_VER(i915) >= 9 &&
+ intel_dp->psr_dpcd[0] == DP_PSR2_WITH_Y_COORD_IS_SUPPORTED) {
bool y_req = intel_dp->psr_dpcd[1] &
DP_PSR2_SU_Y_COORDINATE_REQUIRED;
bool alpm = intel_dp_get_alpm_status(intel_dp);
@@ -521,14 +516,24 @@ void intel_psr_init_dpcd(struct intel_dp *intel_dp)
* GTC first.
*/
intel_dp->psr.sink_psr2_support = y_req && alpm;
- drm_dbg_kms(&dev_priv->drm, "PSR2 %ssupported\n",
+ drm_dbg_kms(&i915->drm, "PSR2 %ssupported\n",
intel_dp->psr.sink_psr2_support ? "" : "not ");
+ }
+}
- if (intel_dp->psr.sink_psr2_support) {
- intel_dp->psr.colorimetry_support =
- intel_dp_get_colorimetry_status(intel_dp);
- intel_dp_get_su_granularity(intel_dp);
- }
+void intel_psr_init_dpcd(struct intel_dp *intel_dp)
+{
+ drm_dp_dpcd_read(&intel_dp->aux, DP_PSR_SUPPORT, intel_dp->psr_dpcd,
+sizeof(intel_dp->psr_dpcd));
+
+ if (intel_dp->psr_dpcd[0])
+ _psr_init_dpcd(intel_dp);
+ /* TODO: Add PR case here */
+
+ if (intel_dp->psr.sink_psr2_support) {
+ intel_dp->psr.colorimetry_support =
+ intel_dp_get_colorimetry_status(intel_dp);
+ intel_dp_get_su_granularity(intel_dp);
}
}
--
2.29.0
[PATCH v6 4/6] drm/i915/panelreplay: Enable panel replay dpcd initialization for DP
Due to similarity panel replay dpcd initialization got added in psr function which is specific for edp panel. This patch enables panel replay initialization for dp connector. Signed-off-by: Animesh Manna --- drivers/gpu/drm/i915/display/intel_psr.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/drivers/gpu/drm/i915/display/intel_psr.c b/drivers/gpu/drm/i915/display/intel_psr.c index 2427bd5cb7ca..a59f13c29c3d 100644 --- a/drivers/gpu/drm/i915/display/intel_psr.c +++ b/drivers/gpu/drm/i915/display/intel_psr.c @@ -2749,6 +2749,9 @@ void intel_psr_init(struct intel_dp *intel_dp) if (!(HAS_PSR(dev_priv) || HAS_DP20(dev_priv))) return; + if (!intel_dp_is_edp(intel_dp)) + intel_psr_init_dpcd(intel_dp); + /* * HSW spec explicitly says PSR is tied to port A. * BDW+ platforms have a instance of PSR registers per transcoder but -- 2.29.0
[PATCH v6 1/6] drm/panelreplay: dpcd register definition for panelreplay
Add DPCD register definition for discovering, enabling and checking status of panel replay of the sink. Cc: Jouni Högander Signed-off-by: Animesh Manna --- include/drm/display/drm_dp.h | 23 +++ 1 file changed, 23 insertions(+) diff --git a/include/drm/display/drm_dp.h b/include/drm/display/drm_dp.h index e69cece404b3..fc42b622ef32 100644 --- a/include/drm/display/drm_dp.h +++ b/include/drm/display/drm_dp.h @@ -543,6 +543,10 @@ /* DFP Capability Extension */ #define DP_DFP_CAPABILITY_EXTENSION_SUPPORT0x0a3 /* 2.0 */ +#define DP_PANEL_REPLAY_CAP 0x0b0 /* DP 2.0 */ +# define DP_PANEL_REPLAY_SUPPORT(1 << 0) +# define DP_PANEL_REPLAY_SU_SUPPORT (1 << 1) + /* Link Configuration */ #defineDP_LINK_BW_SET 0x100 # define DP_LINK_RATE_TABLE0x00/* eDP 1.4 */ @@ -716,6 +720,13 @@ #define DP_BRANCH_DEVICE_CTRL 0x1a1 # define DP_BRANCH_DEVICE_IRQ_HPD (1 << 0) +#define PANEL_REPLAY_CONFIG 0x1b0 /* DP 2.0 */ +# define DP_PANEL_REPLAY_ENABLE (1 << 0) +# define DP_PANEL_REPLAY_UNRECOVERABLE_ERROR_EN (1 << 3) +# define DP_PANEL_REPLAY_RFB_STORAGE_ERROR_EN (1 << 4) +# define DP_PANEL_REPLAY_ACTIVE_FRAME_CRC_ERROR_EN (1 << 5) +# define DP_PANEL_REPLAY_SU_ENABLE (1 << 6) + #define DP_PAYLOAD_ALLOCATE_SET0x1c0 #define DP_PAYLOAD_ALLOCATE_START_TIME_SLOT 0x1c1 #define DP_PAYLOAD_ALLOCATE_TIME_SLOT_COUNT 0x1c2 @@ -1105,6 +1116,18 @@ #define DP_LANE_ALIGN_STATUS_UPDATED_ESI 0x200e /* status same as 0x204 */ #define DP_SINK_STATUS_ESI 0x200f /* status same as 0x205 */ +#define DP_PANEL_REPLAY_ERROR_STATUS 0x2020 /* DP 2.1*/ +# define DP_PANEL_REPLAY_LINK_CRC_ERROR(1 << 0) +# define DP_PANEL_REPLAY_RFB_STORAGE_ERROR (1 << 1) +# define DP_PANEL_REPLAY_VSC_SDP_UNCORRECTABLE_ERROR (1 << 2) + +#define DP_SINK_DEVICE_PR_AND_FRAME_LOCK_STATUS0x2022 /* DP 2.1 */ +# define DP_SINK_DEVICE_PANEL_REPLAY_STATUS_MASK (7 << 0) +# define DP_SINK_FRAME_LOCKED_SHIFT3 +# define DP_SINK_FRAME_LOCKED_MASK (3 << 3) +# define DP_SINK_FRAME_LOCKED_STATUS_VALID_SHIFT 5 +# define DP_SINK_FRAME_LOCKED_STATUS_VALID_MASK(1 << 5) + /* Extended Receiver Capability: See DP_DPCD_REV for definitions */ #define DP_DP13_DPCD_REV0x2200 -- 2.29.0
[PATCH v6 0/6] Panel replay phase1 implementation
Panel Replay is a power saving feature for DP 2.0 monitor and similar to PSR on EDP. These patches are basic enablement patches added on top of existing psr framework to enable full-screen live active frame update mode of panel replay. Panel replay also can be enabled in selective update mode which will be enabled in a incremental approach. As per current design panel replay priority is higher than psr. intel_dp->psr.panel_replay_enabled flag indicate panel replay is enabled. intel_dp->psr.panel_replay_enabled + intel_dp->psr.psr2_enabled indicates panel replay is enabled in selective update mode. intel_dp->psr.panel_replay_enabled + intel_dp->psr.psr2_enabled + intel_psr.selective_fetch enabled indicates panel replay is enabled in selective update mode with selective fetch. PSR replated flags remain same like before. Note: The patches are under testing by using panel replay emulator and panel is not avalible. Cc: Jouni Högander Signed-off-by: Animesh Manna Animesh Manna (5): drm/panelreplay: dpcd register definition for panelreplay drm/i915/panelreplay: Initializaton and compute config for panel replay drm/i915/panelreplay: Enable panel replay dpcd initialization for DP drm/i915/panelreplay: enable/disable panel replay drm/i915/panelreplay: Debugfs support for panel replay Jouni Högander (1): drm/i915/psr: Move psr specific dpcd init into own function drivers/gpu/drm/i915/display/intel_ddi.c | 7 +- .../drm/i915/display/intel_display_types.h| 15 +- drivers/gpu/drm/i915/display/intel_dp.c | 50 ++- drivers/gpu/drm/i915/display/intel_dp_mst.c | 3 + drivers/gpu/drm/i915/display/intel_psr.c | 332 +- drivers/gpu/drm/i915/display/intel_psr.h | 7 + include/drm/display/drm_dp.h | 23 ++ 7 files changed, 323 insertions(+), 114 deletions(-) -- 2.29.0
[PATCH] fbdev: sh7760fb: require FB=y to build cleanly
Fix build errors when CONFIG_FB=m and CONFIG_FB_SH7760=y:
sh2-linux-ld: drivers/video/fbdev/sh7760fb.o: in function `sh7760fb_probe':
sh7760fb.c:(.text+0x374): undefined reference to `framebuffer_alloc'
sh2-linux-ld: sh7760fb.c:(.text+0x394): undefined reference to
`fb_videomode_to_var'
sh2-linux-ld: sh7760fb.c:(.text+0x3a0): undefined reference to `fb_alloc_cmap'
sh2-linux-ld: sh7760fb.c:(.text+0x3a4): undefined reference to
`register_framebuffer'
sh2-linux-ld: sh7760fb.c:(.text+0x3ac): undefined reference to `fb_dealloc_cmap'
sh2-linux-ld: sh7760fb.c:(.text+0x434): undefined reference to
`framebuffer_release'
sh2-linux-ld: drivers/video/fbdev/sh7760fb.o: in function `sh7760fb_remove':
sh7760fb.c:(.text+0x800): undefined reference to `unregister_framebuffer'
sh2-linux-ld: sh7760fb.c:(.text+0x804): undefined reference to `fb_dealloc_cmap'
sh2-linux-ld: sh7760fb.c:(.text+0x814): undefined reference to
`framebuffer_release'
sh2-linux-ld: drivers/video/fbdev/sh7760fb.o:(.rodata+0xc): undefined reference
to `fb_io_read'
sh2-linux-ld: drivers/video/fbdev/sh7760fb.o:(.rodata+0x10): undefined
reference to `fb_io_write'
sh2-linux-ld: drivers/video/fbdev/sh7760fb.o:(.rodata+0x2c): undefined
reference to `cfb_fillrect'
sh2-linux-ld: drivers/video/fbdev/sh7760fb.o:(.rodata+0x30): undefined
reference to `cfb_copyarea'
sh2-linux-ld: drivers/video/fbdev/sh7760fb.o:(.rodata+0x34): undefined
reference to `cfb_imageblit'
Fixes: 4a25e41831ee ("video: sh7760fb: SH7760/SH7763 LCDC framebuffer driver")
Signed-off-by: Randy Dunlap
Cc: Daniel Vetter
Cc: Helge Deller
Cc: linux-fb...@vger.kernel.org
Cc: dri-devel@lists.freedesktop.org
Cc: John Paul Adrian Glaubitz
Cc: linux...@vger.kernel.org
---
drivers/video/fbdev/Kconfig |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff -- a/drivers/video/fbdev/Kconfig b/drivers/video/fbdev/Kconfig
--- a/drivers/video/fbdev/Kconfig
+++ b/drivers/video/fbdev/Kconfig
@@ -1762,7 +1762,7 @@ config FB_COBALT
config FB_SH7760
bool "SH7760/SH7763/SH7720/SH7721 LCDC support"
- depends on FB && (CPU_SUBTYPE_SH7760 || CPU_SUBTYPE_SH7763 \
+ depends on FB=y && (CPU_SUBTYPE_SH7760 || CPU_SUBTYPE_SH7763 \
|| CPU_SUBTYPE_SH7720 || CPU_SUBTYPE_SH7721)
select FB_IOMEM_HELPERS
help
Re: Decrypting tt maps in ttm
On Wed, 2023-09-20 at 21:22 +0200, Thomas Hellström wrote: > !! External Email > > On 9/20/23 20:24, Zack Rusin wrote: > > On Wed, 2023-09-20 at 19:17 +0200, Thomas Hellström wrote: > > > !! External Email > > > > > > Hi, Zack > > > > > > On 9/20/23 18:39, Zack Rusin wrote: > > > > On Wed, 2023-09-20 at 12:48 +0200, Christian König wrote: > > > > > !! External Email > > > > > > > > > > Am 20.09.23 um 09:36 schrieb Thomas Hellström: > > > > > > Hi, Zack, > > > > > > > > > > > > On 9/20/23 05:43, Zack Rusin wrote: > > > > > > > On Tue, 2023-09-19 at 09:47 +0200, Christian König wrote: > > > > > > > > !! External Email > > > > > > > > > > > > > > > > Am 19.09.23 um 08:56 schrieb Thomas Hellström: > > > > > > > > > On 9/19/23 07:39, Christian König wrote: > > > > > > > > > > Am 19.09.23 um 03:26 schrieb Zack Rusin: > > > > > > > > > > > On Mon, 2023-09-18 at 16:21 -0400, Alex Deucher wrote: > > > > > > > > > > > > !! External Email > > > > > > > > > > > > > > > > > > > > > > > > On Mon, Sep 18, 2023 at 3:06 PM Thomas Hellström > > > > > > > > > > > > wrote: > > > > > > > > > > > > > On 9/18/23 17:52, Zack Rusin wrote: > > > > > > > > > > > > > > On Mon, 2023-09-18 at 17:13 +0200, Thomas Hellström > > > > > > > > > > > > > > wrote: > > > > > > > > > > > > > > > Hi, > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > On 9/18/23 16:56, Thomas Hellström wrote: > > > > > > > > > > > > > > > > Hi Zack, Christian > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > On 9/18/23 13:36, Christian König wrote: > > > > > > > > > > > > > > > > > Hi Zack, > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > adding Thomas and Daniel. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > I briefly remember that I talked with Thomas > > > > > > > > > > > > > > > > > and > > > > > > > > > > > > > > > > > some > > > > > > > > > > > > > > > > > other > > > > > > > > > > > > > > > > > people > > > > > > > > > > > > > > > > > about that quite a while ago as well, but I > > > > > > > > > > > > > > > > > don't > > > > > > > > > > > > > > > > > fully > > > > > > > > > > > > > > > > > remember the > > > > > > > > > > > > > > > > > outcome. > > > > > > > > > > > > > > > > Found one old thread, but didn't read it: > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > https://lists.freedesktop.org/archives/dri-devel/2019-September/234100.html > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > /Thomas > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Ugh. Now starting to read that thread I have a > > > > > > > > > > > > > > > vague > > > > > > > > > > > > > > > recollection it all > > > > > > > > > > > > > > > ended with not supporting mapping any device pages > > > > > > > > > > > > > > > whatsoever > > > > > > > > > > > > > > > when SEV > > > > > > > > > > > > > > > was enabled, but rather resorting to llvmpipe and > > > > > > > > > > > > > > > VM- > > > > > > > > > > > > > > > local > > > > > > > > > > > > > > > bos. > > > > > > > > > > > > > > Hi, Thomas. > > > > > > > > > > > > > > > > > > > > > > > > > > > > Thanks for finding this! I'd (of course) like to > > > > > > > > > > > > > > solve > > > > > > > > > > > > > > it > > > > > > > > > > > > > > properly and get > > > > > > > > > > > > > > vmwgfx > > > > > > > > > > > > > > running with 3d support with SEV-ES active instead > > > > > > > > > > > > > > of > > > > > > > > > > > > > > essentially > > > > > > > > > > > > > > disabling > > > > > > > > > > > > > > the > > > > > > > > > > > > > > driver when SEV-ES is active. > > > > > > > > > > > > > > > > > > > > > > > > > > > > I think there are two separate discussions there, > > > > > > > > > > > > > > the > > > > > > > > > > > > > > non-controversial one > > > > > > > > > > > > > > and the > > > > > > > > > > > > > > controversial one: > > > > > > > > > > > > > > 1) The non-controversial: is there a case where > > > > > > > > > > > > > > drivers > > > > > > > > > > > > > > would > > > > > > > > > > > > > > want encrypted > > > > > > > > > > > > > > memory > > > > > > > > > > > > > > for TT pages but not for io mem mappings? Because > > > > > > > > > > > > > > if not > > > > > > > > > > > > > > then as > > > > > > > > > > > > > > Christian > > > > > > > > > > > > > > pointed > > > > > > > > > > > > > > out we could just add pgprot_decrypted to > > > > > > > > > > > > > > ttm_io_prot > > > > > > > > > > > > > > and be > > > > > > > > > > > > > > essentially done. > > > > > > > > > > > > > > The > > > > > > > > > > > > > > current method of decrypting io mem but leaving sys > > > > > > > > > > > > > > mem > > > > > > > > > > > > > > mappings > > > > > > > > > > > > > > encrypted is > > > > > > > > > > > > > > a bit > > > > > > > > > > > > > > weird anyway. > > > > > > > > > > > > > > > > > > > > > > > > > > > > If the
Re: [PATCH v6 7/7] drm/vkms Add hotplug support via configfs to VKMS.
Sorry, these tests are actually running in the chromeOS infrastructure
environment! A similar test can be written in IGT (and I think is in
the other chain that Marius published)
On Thu, Sep 21, 2023 at 3:03 AM Helen Koike wrote:
>
> Hello!
>
> Thanks for the patch.
>
> On 29/08/2023 02:30, Brandon Pollack wrote:
> > This change adds the ability to read or write a "1" or a "0" to the
> > newly added "connected" attribute of a connector in the vkms entry in
> > configfs.
> >
> > A write will trigger a call to drm_kms_helper_hotplug_event, causing a
> > hotplug uevent.
> >
> > With this we can write virtualized multidisplay tests that involve
> > hotplugging displays (eg recompositing windows when a monitor is turned
> > off).
>
> Are these tests going to be added in igt?
>
> I was just wondering if it requires any special thing for drm ci:
>
> https://lists.freedesktop.org/archives/dri-devel/2023-September/423719.html
>
> (btw, it would be awesome of you could test your changes with drm ci :)
>
> Regards,
> Helen
>
> >
> > Signed-off-by: Brandon Pollack
> > ---
> > Documentation/gpu/vkms.rst | 2 +-
> > drivers/gpu/drm/vkms/vkms_configfs.c | 68 ++--
> > drivers/gpu/drm/vkms/vkms_drv.h | 11 +
> > drivers/gpu/drm/vkms/vkms_output.c | 47 ++-
> > 4 files changed, 123 insertions(+), 5 deletions(-)
> >
> > diff --git a/Documentation/gpu/vkms.rst b/Documentation/gpu/vkms.rst
> > index c3875bf66dba..7f715097539c 100644
> > --- a/Documentation/gpu/vkms.rst
> > +++ b/Documentation/gpu/vkms.rst
> > @@ -145,7 +145,7 @@ We want to be able to manipulate vkms instances without
> > having to reload the
> > module. Such configuration can be added as extensions to vkms's ConfigFS
> > support. Use-cases:
> >
> > -- Hotplug/hotremove connectors on the fly (to be able to test DP MST
> > handling
> > +- Hotremove connectors on the fly (to be able to test DP MST handling
> > of compositors).
> >
> > - Change output configuration: Plug/unplug screens, change EDID, allow
> > changing
> > diff --git a/drivers/gpu/drm/vkms/vkms_configfs.c
> > b/drivers/gpu/drm/vkms/vkms_configfs.c
> > index bc35dcc47585..d231e28101ae 100644
> > --- a/drivers/gpu/drm/vkms/vkms_configfs.c
> > +++ b/drivers/gpu/drm/vkms/vkms_configfs.c
> > @@ -1,5 +1,6 @@
> > // SPDX-License-Identifier: GPL-2.0+
> >
> > +#include "drm/drm_probe_helper.h"
> > #include
> > #include
> > #include
> > @@ -40,6 +41,7 @@
> >* `-- vkms
> >* `-- test
> >* |-- connectors
> > + *`-- connected
> >* |-- crtcs
> >* |-- encoders
> >* |-- planes
> > @@ -89,6 +91,14 @@
> >*
> >* echo 1 > /config/vkms/test/enabled
> >*
> > + * By default no display is "connected" so to connect a connector you'll
> > also
> > + * have to write 1 to a connectors "connected" attribute::
> > + *
> > + * echo 1 > /config/vkms/test/connectors/connector/connected
> > + *
> > + * One can verify that this is worked using the `modetest` utility or the
> > + * equivalent for your platform.
> > + *
> >* When you're done with the virtual device, you can clean up the device
> > like
> >* so::
> >*
> > @@ -236,7 +246,58 @@ static void add_possible_encoders(struct config_group
> > *parent,
> >
> > /* Connector item, e.g. /config/vkms/device/connectors/ID */
> >
> > +static ssize_t connector_connected_show(struct config_item *item, char
> > *buf)
> > +{
> > + struct vkms_config_connector *connector =
> > + item_to_config_connector(item);
> > + struct vkms_configfs *configfs = connector_item_to_configfs(item);
> > + bool connected = false;
> > +
> > + mutex_lock(&configfs->lock);
> > + connected = connector->connected;
> > + mutex_unlock(&configfs->lock);
> > +
> > + return sprintf(buf, "%d\n", connected);
> > +}
> > +
> > +static ssize_t connector_connected_store(struct config_item *item,
> > + const char *buf, size_t len)
> > +{
> > + struct vkms_config_connector *connector =
> > + item_to_config_connector(item);
> > + struct vkms_configfs *configfs = connector_item_to_configfs(item);
> > + int val, ret;
> > +
> > + ret = kstrtouint(buf, 10, &val);
> > + if (ret)
> > + return ret;
> > +
> > + if (val != 1 && val != 0)
> > + return -EINVAL;
> > +
> > + mutex_lock(&configfs->lock);
> > + connector->connected = val;
> > + if (!connector->connector) {
> > + pr_info("VKMS Device %s is not yet enabled, connector will be
> > enabled on start",
> > + configfs->device_group.cg_item.ci_name);
> > + }
> > + mutex_unlock(&configfs->lock);
> > +
> > + if (connector->connector)
> > + drm_kms_helper_hotplug_event(connector->connector->dev);
> > +
> > + return len;
> > +}
> > +
> > +CONFIGFS_ATTR(connector_, co
Re: [PATCH v4 01/10] drm/sched: Add drm_sched_submit_* helpers
On 2023-09-19 01:58, Christian König wrote:
> Am 19.09.23 um 07:01 schrieb Matthew Brost:
>> Add scheduler submit ready, stop, and start helpers to hide the
>> implementation details of the scheduler from the drivers.
>>
>> Signed-off-by: Matthew Brost
>
> Reviewed-by: Christian König for this one.
>
> No idea when I have time to look into the rest :( But Luben should take
> a look.
Hi Christian,
Yes, I'll finish up with v3 and v4 tomorrow morning and afternoon.
Regards,
Luben
>
> Regards,
> Christian
>
>> ---
>> .../drm/amd/amdgpu/amdgpu_amdkfd_arcturus.c | 2 +-
>> drivers/gpu/drm/amd/amdgpu/amdgpu_debugfs.c | 15 +++
>> drivers/gpu/drm/amd/amdgpu/amdgpu_device.c| 12 +++---
>> drivers/gpu/drm/msm/adreno/adreno_device.c| 6 ++-
>> drivers/gpu/drm/scheduler/sched_main.c| 40 ++-
>> include/drm/gpu_scheduler.h | 3 ++
>> 6 files changed, 60 insertions(+), 18 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_arcturus.c
>> b/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_arcturus.c
>> index 625db444df1c..36a1accbc846 100644
>> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_arcturus.c
>> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_arcturus.c
>> @@ -290,7 +290,7 @@ static int suspend_resume_compute_scheduler(struct
>> amdgpu_device *adev, bool sus
>> for (i = 0; i < adev->gfx.num_compute_rings; i++) {
>> struct amdgpu_ring *ring = &adev->gfx.compute_ring[i];
>>
>> -if (!(ring && ring->sched.thread))
>> +if (!(ring && drm_sched_submit_ready(&ring->sched)))
>> continue;
>>
>> /* stop secheduler and drain ring. */
>> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_debugfs.c
>> b/drivers/gpu/drm/amd/amdgpu/amdgpu_debugfs.c
>> index a4faea4fa0b5..fb5dad687168 100644
>> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_debugfs.c
>> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_debugfs.c
>> @@ -1659,9 +1659,9 @@ static int amdgpu_debugfs_test_ib_show(struct seq_file
>> *m, void *unused)
>> for (i = 0; i < AMDGPU_MAX_RINGS; i++) {
>> struct amdgpu_ring *ring = adev->rings[i];
>>
>> -if (!ring || !ring->sched.thread)
>> +if (!ring || !drm_sched_submit_ready(&ring->sched))
>> continue;
>> -kthread_park(ring->sched.thread);
>> +drm_sched_submit_stop(&ring->sched);
>> }
>>
>> seq_puts(m, "run ib test:\n");
>> @@ -1675,9 +1675,9 @@ static int amdgpu_debugfs_test_ib_show(struct seq_file
>> *m, void *unused)
>> for (i = 0; i < AMDGPU_MAX_RINGS; i++) {
>> struct amdgpu_ring *ring = adev->rings[i];
>>
>> -if (!ring || !ring->sched.thread)
>> +if (!ring || !drm_sched_submit_ready(&ring->sched))
>> continue;
>> -kthread_unpark(ring->sched.thread);
>> +drm_sched_submit_start(&ring->sched);
>> }
>>
>> up_write(&adev->reset_domain->sem);
>> @@ -1897,7 +1897,8 @@ static int amdgpu_debugfs_ib_preempt(void *data, u64
>> val)
>>
>> ring = adev->rings[val];
>>
>> -if (!ring || !ring->funcs->preempt_ib || !ring->sched.thread)
>> +if (!ring || !ring->funcs->preempt_ib ||
>> +!drm_sched_submit_ready(&ring->sched))
>> return -EINVAL;
>>
>> /* the last preemption failed */
>> @@ -1915,7 +1916,7 @@ static int amdgpu_debugfs_ib_preempt(void *data, u64
>> val)
>> goto pro_end;
>>
>> /* stop the scheduler */
>> -kthread_park(ring->sched.thread);
>> +drm_sched_submit_stop(&ring->sched);
>>
>> /* preempt the IB */
>> r = amdgpu_ring_preempt_ib(ring);
>> @@ -1949,7 +1950,7 @@ static int amdgpu_debugfs_ib_preempt(void *data, u64
>> val)
>>
>> failure:
>> /* restart the scheduler */
>> -kthread_unpark(ring->sched.thread);
>> +drm_sched_submit_start(&ring->sched);
>>
>> up_read(&adev->reset_domain->sem);
>>
>> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
>> b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
>> index 30c4f5cca02c..e366f61c3aed 100644
>> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
>> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
>> @@ -4588,7 +4588,7 @@ bool amdgpu_device_has_job_running(struct
>> amdgpu_device *adev)
>> for (i = 0; i < AMDGPU_MAX_RINGS; ++i) {
>> struct amdgpu_ring *ring = adev->rings[i];
>>
>> -if (!ring || !ring->sched.thread)
>> +if (!ring || !drm_sched_submit_ready(&ring->sched))
>> continue;
>>
>> spin_lock(&ring->sched.job_list_lock);
>> @@ -4727,7 +4727,7 @@ int amdgpu_device_pre_asic_reset(struct amdgpu_device
>> *adev,
>> for (i = 0; i < AMDGPU_MAX_RINGS; ++i) {
>> struct amdgpu_ring *ring = adev->rings[i];
>>
>> -if (!ring || !ring->sched.thread)
>> +if (!ring || !drm_sched_submit
Re: [PATCH v3 09/13] drm/sched: Submit job before starting TDR
On 2023-09-14 13:48, Matthew Brost wrote:
> On Wed, Sep 13, 2023 at 10:56:10PM -0400, Luben Tuikov wrote:
>> On 2023-09-11 22:16, Matthew Brost wrote:
>>> If the TDR is set to a value, it can fire before a job is submitted in
>>> drm_sched_main. The job should be always be submitted before the TDR
>>> fires, fix this ordering.
>>>
>>> v2:
>>> - Add to pending list before run_job, start TDR after (Luben, Boris)
>>>
>>> Signed-off-by: Matthew Brost
>>> ---
>>> drivers/gpu/drm/scheduler/sched_main.c | 2 +-
>>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>>
>>> diff --git a/drivers/gpu/drm/scheduler/sched_main.c
>>> b/drivers/gpu/drm/scheduler/sched_main.c
>>> index c627d3e6494a..9dbfab7be2c6 100644
>>> --- a/drivers/gpu/drm/scheduler/sched_main.c
>>> +++ b/drivers/gpu/drm/scheduler/sched_main.c
>>> @@ -498,7 +498,6 @@ static void drm_sched_job_begin(struct drm_sched_job
>>> *s_job)
>>>
>>> spin_lock(&sched->job_list_lock);
>>> list_add_tail(&s_job->list, &sched->pending_list);
>>> - drm_sched_start_timeout(sched);
>>> spin_unlock(&sched->job_list_lock);
>>> }
>>>
>>> @@ -1234,6 +1233,7 @@ static void drm_sched_run_job_work(struct work_struct
>>> *w)
>>> fence = sched->ops->run_job(sched_job);
>>> complete_all(&entity->entity_idle);
>>> drm_sched_fence_scheduled(s_fence, fence);
>>> + drm_sched_start_timeout_unlocked(sched);
>>>
>>> if (!IS_ERR_OR_NULL(fence)) {
>>> /* Drop for original kref_init of the fence */
>>
>> So, sched->ops->run_job(), is a "job inflection point" from the point of
>> view of
>> the DRM scheduler. After that call, DRM has relinquished control of the job
>> to the
>> firmware/hardware.
>>
>> Putting the job in the pending list, before submitting it to down to the
>> firmware/hardware,
>> goes along with starting a timeout timer for the job. The timeout always
>> includes
>> time for the firmware/hardware to get it prepped, as well as time for the
>> actual
>> execution of the job (task). Thus, we want to do this:
>> 1. Put the job in pending list. "Pending list" means "pends in
>> hardware".
>> 2. Start a timeout timer for the job.
>> 3. Start executing the job/task. This usually involves giving it to
>> firmware/hardware,
>> i.e. ownership of the job/task changes to another domain. In our
>> case this is accomplished
>> by calling sched->ops->run_job().
>> Perhaps move drm_sched_start_timeout() closer to sched->ops->run_job() from
>> above and/or increase
>> the timeout value?
>
> I disagree. It is clear race if the timeout starts before run_job() that
> the TDR can fire before run_job() is called. The entire point of this
Then that would mean that 1) the timeout time is too short, and/or 2) the
firmware/hardware
took a really long time to complete the job (from the point of view of the
scheduler TDR).
> patch is to seal this race by starting the TDR after run_job() is
> called.
Once you call run_job() you're no longer in control of the job and things can
happen, like this job being returned/cancelled due to reasons out of the
scheduler's
control. If you started the timeout _after_ submitting the job to the hardware,
you may be racing with what the hardware might want to do to the job as
described
in the previous sentence.
The timeout timer should start before we give away the job to the hardware.
This is not that dissimilar to sending a network packet out the interface.
If you need a longer timeout time, then we can do that, but starting the timeout
after giving away the job to the hardware is a no-go.
--
Regards,
Luben
Re: [PATCH 00/10] Add mediate-drm secure flow for SVP
Re: [PATCH 3/3] drm/msm/dpu: Fix SC7280 DSC block length
On 9/20/2023 3:46 PM, Konrad Dybcio wrote:
Commit e550ad0e5c3d ("drm/msm/dpu: fix DSC 1.2 block lengths") changed
the block length from a wrong value to another wrong value.
Use the correct one this time.
No that change is correct as well.
After we moved to sub-blk parsing, we have enc and ctl blocks length
used from the dsc_sblk_* instead:
static const struct dpu_dsc_sub_blks dsc_sblk_0 = {
.enc = {.name = "enc", .base = 0x100, .len = 0x9c},
.ctl = {.name = "ctl", .base = 0xF00, .len = 0x10},
};
static const struct dpu_dsc_sub_blks dsc_sblk_1 = {
.enc = {.name = "enc", .base = 0x200, .len = 0x9c},
.ctl = {.name = "ctl", .base = 0xF80, .len = 0x10},
};
The main block has only one register now which is the DSC_CMN register.
Hence len = 0x4 is correct for that.
Sorry, but this is right too :)
Fixes: e550ad0e5c3d ("drm/msm/dpu: fix DSC 1.2 block lengths")
Signed-off-by: Konrad Dybcio
---
drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_7_2_sc7280.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_7_2_sc7280.h
b/drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_7_2_sc7280.h
index b6a59d7b94c4..de5e1a57a142 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_7_2_sc7280.h
+++ b/drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_7_2_sc7280.h
@@ -163,7 +163,7 @@ static const struct dpu_pingpong_cfg sc7280_pp[] = {
static const struct dpu_dsc_cfg sc7280_dsc[] = {
{
.name = "dce_0_0", .id = DSC_0,
- .base = 0x8, .len = 0x4,
+ .base = 0x8, .len = 0x10,
.features = BIT(DPU_DSC_HW_REV_1_2) |
BIT(DPU_DSC_NATIVE_42x_EN) | BIT(DPU_DSC_OUTPUT_CTRL),
.sblk = &dsc_sblk_0,
},
Re: [PATCH 2/3] drm/msm/dpu: Add missing DPU_DSC_OUTPUT_CTRL to SC7280
On 9/20/2023 3:46 PM, Konrad Dybcio wrote:
DPU_DSC_OUTPUT_CTRL should be enabled for all platforms with a CTL
CFG 1.0.0. SC7280 is one of them. Add it.
sc7280 and all other chipsets using DSC 1.2 use dpu_hw_dsc_init_1_2 and
not dpu_hw_dsc_init.
dpu_hw_dsc_init_1_2 assigns the dsc_bind_pingpong_blk op by default.
So this change is not needed.
Fixes: 0d1b10c63346 ("drm/msm/dpu: add DSC 1.2 hw blocks for relevant chipsets")
Signed-off-by: Konrad Dybcio
---
drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_7_2_sc7280.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_7_2_sc7280.h
b/drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_7_2_sc7280.h
index dc3198335164..b6a59d7b94c4 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_7_2_sc7280.h
+++ b/drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_7_2_sc7280.h
@@ -164,7 +164,7 @@ static const struct dpu_dsc_cfg sc7280_dsc[] = {
{
.name = "dce_0_0", .id = DSC_0,
.base = 0x8, .len = 0x4,
- .features = BIT(DPU_DSC_HW_REV_1_2) |
BIT(DPU_DSC_NATIVE_42x_EN),
+ .features = BIT(DPU_DSC_HW_REV_1_2) |
BIT(DPU_DSC_NATIVE_42x_EN) | BIT(DPU_DSC_OUTPUT_CTRL),
.sblk = &dsc_sblk_0,
},
};
Re: [PATCH 1/3] drm/msm/dpu: Fix SC7280 PP length
On 9/20/2023 3:46 PM, Konrad Dybcio wrote:
Commit 194347df5844 ("drm/msm/dpu: inline DSC_BLK and DSC_BLK_1_2
macros") unrolled a macro incorrectly. Fix that.
No, its correct from what i can tell.
Before inlining it was using PP_BLK_DITHER macro and not PP_BLK.
PP_BLK_DITHER has a len of 0 and not 0xd4.
Hence I cannot see whats wrong here.
Fixes: 194347df5844 ("drm/msm/dpu: inline DSC_BLK and DSC_BLK_1_2 macros")
Signed-off-by: Konrad Dybcio
---
drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_7_2_sc7280.h | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_7_2_sc7280.h
b/drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_7_2_sc7280.h
index 3b5061c4402a..dc3198335164 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_7_2_sc7280.h
+++ b/drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_7_2_sc7280.h
@@ -126,7 +126,7 @@ static const struct dpu_dspp_cfg sc7280_dspp[] = {
static const struct dpu_pingpong_cfg sc7280_pp[] = {
{
.name = "pingpong_0", .id = PINGPONG_0,
- .base = 0x69000, .len = 0,
+ .base = 0x69000, .len = 0xd4,
.features = BIT(DPU_PINGPONG_DITHER),
.sblk = &sc7280_pp_sblk,
.merge_3d = 0,
@@ -134,7 +134,7 @@ static const struct dpu_pingpong_cfg sc7280_pp[] = {
.intr_rdptr = -1,
}, {
.name = "pingpong_1", .id = PINGPONG_1,
- .base = 0x6a000, .len = 0,
+ .base = 0x6a000, .len = 0xd4,
.features = BIT(DPU_PINGPONG_DITHER),
.sblk = &sc7280_pp_sblk,
.merge_3d = 0,
@@ -142,7 +142,7 @@ static const struct dpu_pingpong_cfg sc7280_pp[] = {
.intr_rdptr = -1,
}, {
.name = "pingpong_2", .id = PINGPONG_2,
- .base = 0x6b000, .len = 0,
+ .base = 0x6b000, .len = 0xd4,
.features = BIT(DPU_PINGPONG_DITHER),
.sblk = &sc7280_pp_sblk,
.merge_3d = 0,
@@ -150,7 +150,7 @@ static const struct dpu_pingpong_cfg sc7280_pp[] = {
.intr_rdptr = -1,
}, {
.name = "pingpong_3", .id = PINGPONG_3,
- .base = 0x6c000, .len = 0,
+ .base = 0x6c000, .len = 0xd4,
.features = BIT(DPU_PINGPONG_DITHER),
.sblk = &sc7280_pp_sblk,
.merge_3d = 0,
Re: [PATCH] drm/ci: Uprev IGT to pull in fixes
On 20/09/2023 16:44, Rob Clark wrote: On Wed, Sep 20, 2023 at 11:53 AM Helen Koike wrote: Hi Rob, Thanks for the patch. On 20/09/2023 15:10, Rob Clark wrote: On Wed, Sep 20, 2023 at 11:06 AM Rob Clark wrote: From: Rob Clark There have been a few igt test fixes compared to the commit that we were currently using. Pull in a newer igt and update expectations. Signed-off-by: Rob Clark --- Could you send here the url of a pipeline run with this change? https://gitlab.freedesktop.org/drm/msm/-/pipelines/989913 Thanks, lgtm. Acked-by: Helen Koike That was before I wrote a proper commit msg so you can ignore the checkpatch job.. and there is an unrelated issue with the sdm845 runners not booting w/ v6.6-rc2, which still needs to be tracked down. BR, -R drivers/gpu/drm/ci/gitlab-ci.yml | 2 +- .../gpu/drm/ci/xfails/amdgpu-stoney-fails.txt | 4 ++-- drivers/gpu/drm/ci/xfails/i915-apl-fails.txt | 11 --- drivers/gpu/drm/ci/xfails/i915-cml-fails.txt | 2 +- drivers/gpu/drm/ci/xfails/i915-tgl-fails.txt | 1 - drivers/gpu/drm/ci/xfails/msm-sc7180-skips.txt | 18 +- .../drm/ci/xfails/rockchip-rk3288-fails.txt| 2 ++ 7 files changed, 7 insertions(+), 33 deletions(-) diff --git a/drivers/gpu/drm/ci/gitlab-ci.yml b/drivers/gpu/drm/ci/gitlab-ci.yml index 2c4df53f5dfe..3ecb5879e80f 100644 --- a/drivers/gpu/drm/ci/gitlab-ci.yml +++ b/drivers/gpu/drm/ci/gitlab-ci.yml @@ -5,7 +5,7 @@ variables: UPSTREAM_REPO: git://anongit.freedesktop.org/drm/drm TARGET_BRANCH: drm-next - IGT_VERSION: 471bfababd070e1dac0ebb87470ac4f2ae85e663 + IGT_VERSION: 2517e42d612e0c1ca096acf8b5f6177f7ef4bce7 DEQP_RUNNER_GIT_URL: https://gitlab.freedesktop.org/anholt/deqp-runner.git DEQP_RUNNER_GIT_TAG: v0.15.0 diff --git a/drivers/gpu/drm/ci/xfails/amdgpu-stoney-fails.txt b/drivers/gpu/drm/ci/xfails/amdgpu-stoney-fails.txt index bd9392536e7c..bab21930a0d4 100644 --- a/drivers/gpu/drm/ci/xfails/amdgpu-stoney-fails.txt +++ b/drivers/gpu/drm/ci/xfails/amdgpu-stoney-fails.txt @@ -1,7 +1,6 @@ kms_addfb_basic@bad-pitch-65536,Fail kms_addfb_basic@bo-too-small,Fail kms_async_flips@invalid-async-flip,Fail -kms_atomic@plane-immutable-zpos,Fail kms_atomic_transition@plane-toggle-modeset-transition,Fail kms_bw@linear-tiling-1-displays-2560x1440p,Fail kms_bw@linear-tiling-1-displays-3840x2160p,Fail @@ -11,9 +10,10 @@ kms_color@degamma,Fail kms_cursor_crc@cursor-size-change,Fail kms_cursor_crc@pipe-A-cursor-size-change,Fail kms_cursor_crc@pipe-B-cursor-size-change,Fail -kms_cursor_legacy@forked-move,Fail kms_hdr@bpc-switch,Fail kms_hdr@bpc-switch-dpms,Fail kms_plane_multiple@atomic-pipe-A-tiling-none,Fail kms_rmfb@close-fd,Fail kms_rotation_crc@primary-rotation-180,Fail +kms_flip@flip-vs-modeset-vs-hang,Fail +kms_flip@flip-vs-panning-vs-hang,Fail diff --git a/drivers/gpu/drm/ci/xfails/i915-apl-fails.txt b/drivers/gpu/drm/ci/xfails/i915-apl-fails.txt index 46397ce38d5a..2e3b7c5dac3c 100644 --- a/drivers/gpu/drm/ci/xfails/i915-apl-fails.txt +++ b/drivers/gpu/drm/ci/xfails/i915-apl-fails.txt @@ -8,13 +8,6 @@ kms_bw@linear-tiling-3-displays-3840x2160p,Fail kms_bw@linear-tiling-4-displays-1920x1080p,Fail kms_bw@linear-tiling-4-displays-2560x1440p,Fail kms_bw@linear-tiling-4-displays-3840x2160p,Fail -kms_color@ctm-0-25,Fail -kms_color@ctm-0-50,Fail -kms_color@ctm-0-75,Fail -kms_color@ctm-max,Fail -kms_color@ctm-negative,Fail -kms_color@ctm-red-to-blue,Fail -kms_color@ctm-signed,Fail kms_flip_scaled_crc@flip-32bpp-linear-to-64bpp-linear-downscaling,Fail kms_flip_scaled_crc@flip-32bpp-linear-to-64bpp-linear-upscaling,Fail kms_flip_scaled_crc@flip-32bpp-xtile-to-64bpp-xtile-downscaling,Fail @@ -38,8 +31,6 @@ kms_flip_scaled_crc@flip-64bpp-ytile-to-32bpp-ytile-upscaling,Fail kms_flip_scaled_crc@flip-64bpp-ytile-to-32bpp-ytilegen12rcccs-upscaling,Fail kms_flip_scaled_crc@flip-64bpp-ytile-to-32bpp-ytilercccs-downscaling,Fail kms_flip_scaled_crc@flip-64bpp-ytile-to-32bpp-ytilercccs-upscaling,Fail -kms_hdmi_inject@inject-4k,Timeout -kms_plane@plane-position-hole,Timeout kms_plane_alpha_blend@alpha-basic,Fail kms_plane_alpha_blend@alpha-opaque-fb,Fail kms_plane_alpha_blend@alpha-transparent-fb,Fail @@ -53,6 +44,4 @@ kms_plane_alpha_blend@pipe-B-constant-alpha-max,Fail kms_plane_alpha_blend@pipe-C-alpha-opaque-fb,Fail kms_plane_alpha_blend@pipe-C-alpha-transparent-fb,Fail kms_plane_alpha_blend@pipe-C-constant-alpha-max,Fail -kms_plane_multiple@tiling-y,Timeout -kms_pwrite_crc,Timeout kms_sysfs_edid_timing,Fail diff --git a/drivers/gpu/drm/ci/xfails/i915-cml-fails.txt b/drivers/gpu/drm/ci/xfails/i915-cml-fails.txt index 6139b410e767..13c0a25fc627 100644 --- a/drivers/gpu/drm/ci/xfails/i915-cml-fails.txt +++ b/drivers/gpu/drm/ci/xfails/i915-cml-fails.txt @@ -1,4 +1,3 @@ -kms_color@ctm-0-25,Fail kms_flip_scaled_crc@flip-32bpp-linear-to-64bpp-linear-downscaling,Fail
Re: [PATCH v3 4/7] drm/msm/dp: incorporate pm_runtime framework into DP driver
On 9/15/2023 6:07 PM, Dmitry Baryshkov wrote:
On Sat, 16 Sept 2023 at 00:38, Kuogee Hsieh wrote:
Currently DP driver is executed independent of PM runtime framework.
This lead DP driver incompatible with others. Incorporating pm runtime
Why is it incompatible? Which others are mentioned here?
framework into DP driver so that both power and clocks to enable/disable
host controller fits with PM runtime mechanism. Once pm runtime framework
is incorporated into DP driver, wake up device from power up path is not
necessary. Hence remove it. Both EV_POWER_PM_GET and EV_POWER_PM_PUT events
are introduced to perform pm runtime control for the HPD GPIO routing to a
display-connector case.
Changes in v3:
-- incorporate removing pm_runtime_xx() from dp_pwer.c to this patch
-- use pm_runtime_resume_and_get() instead of pm_runtime_get()
-- error checking pm_runtime_resume_and_get() return value
-- add EV_POWER_PM_GET and PM_EV_POWER_PUT to handle HPD_GPIO case
Previous changelog?
Signed-off-by: Kuogee Hsieh
---
drivers/gpu/drm/msm/dp/dp_aux.c | 5 ++
drivers/gpu/drm/msm/dp/dp_display.c | 114 +++-
drivers/gpu/drm/msm/dp/dp_power.c | 9 ---
3 files changed, 90 insertions(+), 38 deletions(-)
diff --git a/drivers/gpu/drm/msm/dp/dp_aux.c b/drivers/gpu/drm/msm/dp/dp_aux.c
index 8e3b677..8fa93c5 100644
--- a/drivers/gpu/drm/msm/dp/dp_aux.c
+++ b/drivers/gpu/drm/msm/dp/dp_aux.c
@@ -291,6 +291,9 @@ static ssize_t dp_aux_transfer(struct drm_dp_aux *dp_aux,
return -EINVAL;
}
+ if (pm_runtime_resume_and_get(dp_aux->dev))
+ return -EINVAL;
Please propagate error values instead of reinventing them.
+
mutex_lock(&aux->mutex);
if (!aux->initted) {
ret = -EIO;
@@ -364,6 +367,8 @@ static ssize_t dp_aux_transfer(struct drm_dp_aux *dp_aux,
exit:
mutex_unlock(&aux->mutex);
+ pm_runtime_mark_last_busy(dp_aux->dev);
+ pm_runtime_put_autosuspend(dp_aux->dev);
What is the reason for using autosuspend? Such design decisions should
be described in the commit message.
return ret;
}
diff --git a/drivers/gpu/drm/msm/dp/dp_display.c
b/drivers/gpu/drm/msm/dp/dp_display.c
index 59f9d85..e7af7f7 100644
--- a/drivers/gpu/drm/msm/dp/dp_display.c
+++ b/drivers/gpu/drm/msm/dp/dp_display.c
@@ -60,6 +60,8 @@ enum {
EV_IRQ_HPD_INT,
EV_HPD_UNPLUG_INT,
EV_USER_NOTIFICATION,
+ EV_POWER_PM_GET,
+ EV_POWER_PM_PUT,
};
#define EVENT_TIMEOUT (HZ/10) /* 100ms */
@@ -276,13 +278,6 @@ static int dp_display_bind(struct device *dev, struct
device *master,
dp->dp_display.drm_dev = drm;
priv->dp[dp->id] = &dp->dp_display;
- rc = dp->parser->parse(dp->parser);
- if (rc) {
- DRM_ERROR("device tree parsing failed\n");
- goto end;
- }
-
-
dp->drm_dev = drm;
dp->aux->drm_dev = drm;
rc = dp_aux_register(dp->aux);
@@ -291,12 +286,6 @@ static int dp_display_bind(struct device *dev, struct
device *master,
goto end;
}
- rc = dp_power_client_init(dp->power);
- if (rc) {
- DRM_ERROR("Power client create failed\n");
- goto end;
- }
-
rc = dp_register_audio_driver(dev, dp->audio);
if (rc) {
DRM_ERROR("Audio registration Dp failed\n");
@@ -320,10 +309,6 @@ static void dp_display_unbind(struct device *dev, struct
device *master,
struct dp_display_private *dp = dev_get_dp_display_private(dev);
struct msm_drm_private *priv = dev_get_drvdata(master);
- /* disable all HPD interrupts */
- if (dp->core_initialized)
- dp_catalog_hpd_config_intr(dp->catalog, DP_DP_HPD_INT_MASK,
false);
-
kthread_stop(dp->ev_tsk);
of_dp_aux_depopulate_bus(dp->aux);
@@ -467,6 +452,18 @@ static void dp_display_host_deinit(struct
dp_display_private *dp)
dp->core_initialized = false;
}
+static void dp_display_pm_get(struct dp_display_private *dp)
+{
+ if (pm_runtime_resume_and_get(&dp->pdev->dev))
+ DRM_ERROR("failed to start power\n");
+}
Huge NAK here. This means that the error is completely ignored (other
than being dumped to the log). This is a short path to Sync error and
other kinds of reboot.
+
+static void dp_display_pm_put(struct dp_display_private *dp)
+{
+ pm_runtime_mark_last_busy(&dp->pdev->dev);
+ pm_runtime_put_autosuspend(&dp->pdev->dev);
+}
+
static int dp_display_usbpd_configure_cb(struct device *dev)
{
struct dp_display_private *dp = dev_get_dp_display_private(dev);
@@ -1096,7 +1093,6 @@ static int hpd_event_thread(void *data)
switch (todo->event_id) {
case EV_HPD_INIT_SETUP:
- dp_display_host_init(dp_priv);
break;
case EV_HPD_PLUG_INT:
[PATCH 2/3] drm/msm/dpu: Add missing DPU_DSC_OUTPUT_CTRL to SC7280
DPU_DSC_OUTPUT_CTRL should be enabled for all platforms with a CTL
CFG 1.0.0. SC7280 is one of them. Add it.
Fixes: 0d1b10c63346 ("drm/msm/dpu: add DSC 1.2 hw blocks for relevant chipsets")
Signed-off-by: Konrad Dybcio
---
drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_7_2_sc7280.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_7_2_sc7280.h
b/drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_7_2_sc7280.h
index dc3198335164..b6a59d7b94c4 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_7_2_sc7280.h
+++ b/drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_7_2_sc7280.h
@@ -164,7 +164,7 @@ static const struct dpu_dsc_cfg sc7280_dsc[] = {
{
.name = "dce_0_0", .id = DSC_0,
.base = 0x8, .len = 0x4,
- .features = BIT(DPU_DSC_HW_REV_1_2) |
BIT(DPU_DSC_NATIVE_42x_EN),
+ .features = BIT(DPU_DSC_HW_REV_1_2) |
BIT(DPU_DSC_NATIVE_42x_EN) | BIT(DPU_DSC_OUTPUT_CTRL),
.sblk = &dsc_sblk_0,
},
};
--
2.39.2
[PATCH 3/3] drm/msm/dpu: Fix SC7280 DSC block length
Commit e550ad0e5c3d ("drm/msm/dpu: fix DSC 1.2 block lengths") changed
the block length from a wrong value to another wrong value.
Use the correct one this time.
Fixes: e550ad0e5c3d ("drm/msm/dpu: fix DSC 1.2 block lengths")
Signed-off-by: Konrad Dybcio
---
drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_7_2_sc7280.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_7_2_sc7280.h
b/drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_7_2_sc7280.h
index b6a59d7b94c4..de5e1a57a142 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_7_2_sc7280.h
+++ b/drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_7_2_sc7280.h
@@ -163,7 +163,7 @@ static const struct dpu_pingpong_cfg sc7280_pp[] = {
static const struct dpu_dsc_cfg sc7280_dsc[] = {
{
.name = "dce_0_0", .id = DSC_0,
- .base = 0x8, .len = 0x4,
+ .base = 0x8, .len = 0x10,
.features = BIT(DPU_DSC_HW_REV_1_2) |
BIT(DPU_DSC_NATIVE_42x_EN) | BIT(DPU_DSC_OUTPUT_CTRL),
.sblk = &dsc_sblk_0,
},
--
2.39.2
[PATCH 1/3] drm/msm/dpu: Fix SC7280 PP length
Commit 194347df5844 ("drm/msm/dpu: inline DSC_BLK and DSC_BLK_1_2
macros") unrolled a macro incorrectly. Fix that.
Fixes: 194347df5844 ("drm/msm/dpu: inline DSC_BLK and DSC_BLK_1_2 macros")
Signed-off-by: Konrad Dybcio
---
drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_7_2_sc7280.h | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_7_2_sc7280.h
b/drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_7_2_sc7280.h
index 3b5061c4402a..dc3198335164 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_7_2_sc7280.h
+++ b/drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_7_2_sc7280.h
@@ -126,7 +126,7 @@ static const struct dpu_dspp_cfg sc7280_dspp[] = {
static const struct dpu_pingpong_cfg sc7280_pp[] = {
{
.name = "pingpong_0", .id = PINGPONG_0,
- .base = 0x69000, .len = 0,
+ .base = 0x69000, .len = 0xd4,
.features = BIT(DPU_PINGPONG_DITHER),
.sblk = &sc7280_pp_sblk,
.merge_3d = 0,
@@ -134,7 +134,7 @@ static const struct dpu_pingpong_cfg sc7280_pp[] = {
.intr_rdptr = -1,
}, {
.name = "pingpong_1", .id = PINGPONG_1,
- .base = 0x6a000, .len = 0,
+ .base = 0x6a000, .len = 0xd4,
.features = BIT(DPU_PINGPONG_DITHER),
.sblk = &sc7280_pp_sblk,
.merge_3d = 0,
@@ -142,7 +142,7 @@ static const struct dpu_pingpong_cfg sc7280_pp[] = {
.intr_rdptr = -1,
}, {
.name = "pingpong_2", .id = PINGPONG_2,
- .base = 0x6b000, .len = 0,
+ .base = 0x6b000, .len = 0xd4,
.features = BIT(DPU_PINGPONG_DITHER),
.sblk = &sc7280_pp_sblk,
.merge_3d = 0,
@@ -150,7 +150,7 @@ static const struct dpu_pingpong_cfg sc7280_pp[] = {
.intr_rdptr = -1,
}, {
.name = "pingpong_3", .id = PINGPONG_3,
- .base = 0x6c000, .len = 0,
+ .base = 0x6c000, .len = 0xd4,
.features = BIT(DPU_PINGPONG_DITHER),
.sblk = &sc7280_pp_sblk,
.merge_3d = 0,
--
2.39.2
[PATCH 0/3] SC7280 DPU fixups
Found a couple mistakes, this series attempts to fix it. Signed-off-by: Konrad Dybcio --- Konrad Dybcio (3): drm/msm/dpu: Fix SC7280 PP length drm/msm/dpu: Add missing DPU_DSC_OUTPUT_CTRL to SC7280 drm/msm/dpu: Fix SC7280 DSC block length drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_7_2_sc7280.h | 12 ++-- 1 file changed, 6 insertions(+), 6 deletions(-) --- base-commit: 926f75c8a5ab70567eb4c2d82fbc96963313e564 change-id: 20230920-topic-7280_dpu-59a29cedca6e Best regards, -- Konrad Dybcio
Re: [PATCH v3 1/2] dt-bindings: display: imx: add binding for i.MX8MP HDMI PVI
On Wed, 20 Sep 2023 19:10:08 +0200, Lucas Stach wrote: > Add binding for the i.MX8MP HDMI parallel video interface block. > > Signed-off-by: Lucas Stach > --- > .../display/imx/fsl,imx8mp-hdmi-pvi.yaml | 80 +++ > 1 file changed, 80 insertions(+) > create mode 100644 > Documentation/devicetree/bindings/display/imx/fsl,imx8mp-hdmi-pvi.yaml > My bot found errors running 'make DT_CHECKER_FLAGS=-m dt_binding_check' on your patch (DT_CHECKER_FLAGS is new in v5.13): yamllint warnings/errors: dtschema/dtc warnings/errors: /builds/robherring/dt-review-ci/linux/Documentation/devicetree/bindings/display/imx/fsl,imx8mp-hdmi-pvi.example.dtb: display-bridge@32fc4000: 'interrupts' does not match any of the regexes: 'pinctrl-[0-9]+' from schema $id: http://devicetree.org/schemas/display/imx/fsl,imx8mp-hdmi-pvi.yaml# doc reference errors (make refcheckdocs): See https://patchwork.ozlabs.org/project/devicetree-bindings/patch/20230920171009.3193296-1-l.st...@pengutronix.de The base for the series is generally the latest rc1. A different dependency should be noted in *this* patch. If you already ran 'make dt_binding_check' and didn't see the above error(s), then make sure 'yamllint' is installed and dt-schema is up to date: pip3 install dtschema --upgrade Please check and re-submit after running the above command yourself. Note that DT_SCHEMA_FILES can be set to your schema file to speed up checking your schema. However, it must be unset to test all examples with your schema.
[pull] amdgpu, amdkfd drm-fixes-6.6
Hi Dave, Daniel, Fixes for 6.6. The following changes since commit ce9ecca0238b140b88f43859b211c9fdfd8e5b70: Linux 6.6-rc2 (2023-09-17 14:40:24 -0700) are available in the Git repository at: https://gitlab.freedesktop.org/agd5f/linux.git tags/amd-drm-fixes-6.6-2023-09-20 for you to fetch changes up to cc39f9ccb82426e576734b493e1777ea01b144a8: drm/amdkfd: Use gpu_offset for user queue's wptr (2023-09-20 17:30:42 -0400) amd-drm-fixes-6.6-2023-09-20: amdgpu: - MST fix - Vbios part number reporting fix - Fix a possible memory leak in an error case in the RAS code - Fix low resolution modes on eDP amdkfd: - Fix GPU address for user queue wptr when GART is not at 0 Cong Liu (1): drm/amdgpu: fix a memory leak in amdgpu_ras_feature_enable Hamza Mahfooz (1): drm/amd/display: fix the ability to use lower resolution modes on eDP Lijo Lazar (1): Revert "drm/amdgpu: Report vbios version instead of PN" Muhammad Ahmed (1): drm/amd/display: Fix MST recognizes connected displays as one YuBiao Wang (1): drm/amdkfd: Use gpu_offset for user queue's wptr drivers/gpu/drm/amd/amdgpu/amdgpu_atombios.c | 2 +- drivers/gpu/drm/amd/amdgpu/amdgpu_ras.c| 1 + .../gpu/drm/amd/amdkfd/kfd_device_queue_manager.c | 2 +- drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 4 +-- .../amd/display/dc/dce110/dce110_hw_sequencer.c| 30 -- drivers/gpu/drm/amd/display/dc/dcn20/dcn20_hwseq.c | 8 ++ drivers/gpu/drm/amd/display/dc/dcn32/dcn32_mpc.c | 2 +- 7 files changed, 25 insertions(+), 24 deletions(-)
Re: [PATCH 1/6] drm/msm/mdss: fix highest-bank-bit for msm8998
On 9/5/2023 10:43 AM, Dmitry Baryshkov wrote:
According to the vendor DT files, msm8998 has highest-bank-bit equal to
2. Update the data accordingly.
Fixes: 6f410b246209 ("drm/msm/mdss: populate missing data")
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/msm/msm_mdss.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
Reviewed-by: Abhinav Kumar
[PATCH] drm/i915/gem: Allow users to disable waitboost
Provide a bit to disable waitboost while waiting on a gem object.
Waitboost results in increased power consumption by requesting RP0
while waiting for the request to complete. Add a bit in the gem_wait()
IOCTL where this can be disabled.
This is related to the libva API change here -
Link:
https://github.com/XinfengZhang/libva/commit/3d90d18c67609a73121bb71b20ee4776b54b61a7
Cc: Rodrigo Vivi
Signed-off-by: Vinay Belgaumkar
---
drivers/gpu/drm/i915/gem/i915_gem_wait.c | 9 ++---
drivers/gpu/drm/i915/i915_request.c | 3 ++-
drivers/gpu/drm/i915/i915_request.h | 1 +
include/uapi/drm/i915_drm.h | 1 +
4 files changed, 10 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_wait.c
b/drivers/gpu/drm/i915/gem/i915_gem_wait.c
index d4b918fb11ce..955885ec859d 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_wait.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_wait.c
@@ -72,7 +72,8 @@ i915_gem_object_wait_reservation(struct dma_resv *resv,
struct dma_fence *fence;
long ret = timeout ?: 1;
- i915_gem_object_boost(resv, flags);
+ if (!(flags & I915_WAITBOOST_DISABLE))
+ i915_gem_object_boost(resv, flags);
dma_resv_iter_begin(&cursor, resv,
dma_resv_usage_rw(flags & I915_WAIT_ALL));
@@ -236,7 +237,7 @@ i915_gem_wait_ioctl(struct drm_device *dev, void *data,
struct drm_file *file)
ktime_t start;
long ret;
- if (args->flags != 0)
+ if (args->flags != 0 || args->flags != I915_GEM_WAITBOOST_DISABLE)
return -EINVAL;
obj = i915_gem_object_lookup(file, args->bo_handle);
@@ -248,7 +249,9 @@ i915_gem_wait_ioctl(struct drm_device *dev, void *data,
struct drm_file *file)
ret = i915_gem_object_wait(obj,
I915_WAIT_INTERRUPTIBLE |
I915_WAIT_PRIORITY |
- I915_WAIT_ALL,
+ I915_WAIT_ALL |
+ (args->flags & I915_GEM_WAITBOOST_DISABLE ?
+ I915_WAITBOOST_DISABLE : 0),
to_wait_timeout(args->timeout_ns));
if (args->timeout_ns > 0) {
diff --git a/drivers/gpu/drm/i915/i915_request.c
b/drivers/gpu/drm/i915/i915_request.c
index f59081066a19..2957409b4b2a 100644
--- a/drivers/gpu/drm/i915/i915_request.c
+++ b/drivers/gpu/drm/i915/i915_request.c
@@ -2044,7 +2044,8 @@ long i915_request_wait_timeout(struct i915_request *rq,
* but at a cost of spending more power processing the workload
* (bad for battery).
*/
- if (flags & I915_WAIT_PRIORITY && !i915_request_started(rq))
+ if (!(flags & I915_WAITBOOST_DISABLE) && (flags & I915_WAIT_PRIORITY) &&
+ !i915_request_started(rq))
intel_rps_boost(rq);
wait.tsk = current;
diff --git a/drivers/gpu/drm/i915/i915_request.h
b/drivers/gpu/drm/i915/i915_request.h
index 0ac55b2e4223..3cc00e8254dc 100644
--- a/drivers/gpu/drm/i915/i915_request.h
+++ b/drivers/gpu/drm/i915/i915_request.h
@@ -445,6 +445,7 @@ long i915_request_wait(struct i915_request *rq,
#define I915_WAIT_INTERRUPTIBLEBIT(0)
#define I915_WAIT_PRIORITY BIT(1) /* small priority bump for the request */
#define I915_WAIT_ALL BIT(2) /* used by i915_gem_object_wait() */
+#define I915_WAITBOOST_DISABLE BIT(3) /* used by i915_gem_object_wait() */
void i915_request_show(struct drm_printer *m,
const struct i915_request *rq,
diff --git a/include/uapi/drm/i915_drm.h b/include/uapi/drm/i915_drm.h
index 7000e5910a1d..4adee70e39cf 100644
--- a/include/uapi/drm/i915_drm.h
+++ b/include/uapi/drm/i915_drm.h
@@ -1928,6 +1928,7 @@ struct drm_i915_gem_wait {
/** Handle of BO we shall wait on */
__u32 bo_handle;
__u32 flags;
+#define I915_GEM_WAITBOOST_DISABLE (1u<<0)
/** Number of nanoseconds to wait, Returns time remaining. */
__s64 timeout_ns;
};
--
2.38.1
[PATCH v2 2/2] drm/i915/bios: Fixup h/vsync_end instead of h/vtotal
From: Ville Syrjälä
We have the same h/vsync_end vs. h/vtotal quirk in the VBT parser
that was also present in EDID parser. Adjust the VBT parser the
same way as was done for hte EDID parser to fixup h/vsync_end
instead of h/vtotal. While I'm not currently aware of any machines
that need this for the VBT it seems prudent to keep both parsers
in sync.
And while at it let's add some debugs here as well. A bit
lackluster but didn't feel like plumbing the connector all
the way down at this time.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/display/intel_bios.c | 23 +++
1 file changed, 15 insertions(+), 8 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_bios.c
b/drivers/gpu/drm/i915/display/intel_bios.c
index f735b035436c..863ff54fffd1 100644
--- a/drivers/gpu/drm/i915/display/intel_bios.c
+++ b/drivers/gpu/drm/i915/display/intel_bios.c
@@ -521,7 +521,8 @@ static void init_bdb_blocks(struct drm_i915_private *i915,
}
static void
-fill_detail_timing_data(struct drm_display_mode *panel_fixed_mode,
+fill_detail_timing_data(struct drm_i915_private *i915,
+ struct drm_display_mode *panel_fixed_mode,
const struct lvds_dvo_timing *dvo_timing)
{
panel_fixed_mode->hdisplay = (dvo_timing->hactive_hi << 8) |
@@ -561,11 +562,17 @@ fill_detail_timing_data(struct drm_display_mode
*panel_fixed_mode,
panel_fixed_mode->height_mm = (dvo_timing->vimage_hi << 8) |
dvo_timing->vimage_lo;
- /* Some VBTs have bogus h/vtotal values */
- if (panel_fixed_mode->hsync_end > panel_fixed_mode->htotal)
- panel_fixed_mode->htotal = panel_fixed_mode->hsync_end + 1;
- if (panel_fixed_mode->vsync_end > panel_fixed_mode->vtotal)
- panel_fixed_mode->vtotal = panel_fixed_mode->vsync_end + 1;
+ /* Some VBTs have bogus h/vsync_end values */
+ if (panel_fixed_mode->hsync_end > panel_fixed_mode->htotal) {
+ drm_dbg_kms(&i915->drm, "reducing hsync_end %d->%d\n",
+ panel_fixed_mode->hsync_end,
panel_fixed_mode->htotal);
+ panel_fixed_mode->hsync_end = panel_fixed_mode->htotal;
+ }
+ if (panel_fixed_mode->vsync_end > panel_fixed_mode->vtotal) {
+ drm_dbg_kms(&i915->drm, "reducing vsync_end %d->%d\n",
+ panel_fixed_mode->vsync_end,
panel_fixed_mode->vtotal);
+ panel_fixed_mode->vsync_end = panel_fixed_mode->vtotal;
+ }
drm_mode_set_name(panel_fixed_mode);
}
@@ -849,7 +856,7 @@ parse_lfp_panel_dtd(struct drm_i915_private *i915,
if (!panel_fixed_mode)
return;
- fill_detail_timing_data(panel_fixed_mode, panel_dvo_timing);
+ fill_detail_timing_data(i915, panel_fixed_mode, panel_dvo_timing);
panel->vbt.lfp_lvds_vbt_mode = panel_fixed_mode;
@@ -1134,7 +1141,7 @@ parse_sdvo_panel_data(struct drm_i915_private *i915,
if (!panel_fixed_mode)
return;
- fill_detail_timing_data(panel_fixed_mode, &dtds->dtds[index]);
+ fill_detail_timing_data(i915, panel_fixed_mode, &dtds->dtds[index]);
panel->vbt.sdvo_lvds_vbt_mode = panel_fixed_mode;
--
2.41.0
[PATCH v2 1/2] drm/edid: Fixup h/vsync_end instead of h/vtotal
From: Ville Syrjälä
There are some weird EDIDs floating around that have the sync
pulse extending beyond the end of the blanking period.
On the currently problemtic machine (HP Omni 120) EDID reports
the following mode:
"1600x900": 60 108000 1600 1780 1860 1800 900 910 913 1000 0x40 0x5
which is then "corrected" to have htotal=1861 by the current drm_edid.c
code.
The fixup code was originally added in commit 7064fef56369 ("drm: work
around EDIDs with bad htotal/vtotal values"). Googling around we end up in
https://bugs.launchpad.net/ubuntu/hardy/+source/xserver-xorg-video-intel/+bug/297245
where we find an EDID for a Dell Studio 15, which reports:
(II) VESA(0): clock: 65.0 MHz Image Size: 331 x 207 mm
(II) VESA(0): h_active: 1280 h_sync: 1328 h_sync_end 1360 h_blank_end 1337
h_border: 0
(II) VESA(0): v_active: 800 v_sync: 803 v_sync_end 809 v_blanking: 810
v_border: 0
Note that if we use the hblank size (as opposed of the hsync_end)
from the DTD to determine htotal we get exactly 60Hz refresh rate in
both cases, whereas using hsync_end to determine htotal we get a
slightly lower refresh rates. This makes me believe the using the
hblank size is what was intended even in those cases.
Also note that in case of the HP Onmi 120 the VBIOS boots with these:
crtc timings: 108000 1600 1780 1860 1800 900 910 913 1000, type: 0x40 flags:
0x5
ie. it just blindly stuffs the bogus hsync_end and htotal from the DTD
into the transcoder timing registers, and the display works. I believe
the (at least more modern) hardware will automagically terminate the hsync
pulse when the timing generator reaches htotal, which again points that we
should use the hblank size to determine htotal. Unfortunatley the old bug
reports for the Dell machines are extremely lacking in useful details so
we have no idea what kind of timings the VBIOS programmed into the
hardware :(
Let's just flip this quirk around and reduce the length of the sync
pulse instead of extending the blanking period. This at least seems
to be the correct thing to do on more modern hardware. And if any
issues crop up on older hardware we need to debug them properly.
v2: Add debug message breadcrumbs (Jani)
Reviewed-by: Jani Nikula #v1
Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/8895
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/drm_edid.c | 18 +-
1 file changed, 13 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
index 39dd3f694544..ec1cb4890acb 100644
--- a/drivers/gpu/drm/drm_edid.c
+++ b/drivers/gpu/drm/drm_edid.c
@@ -3497,11 +3497,19 @@ static struct drm_display_mode
*drm_mode_detailed(struct drm_connector *connecto
mode->vsync_end = mode->vsync_start + vsync_pulse_width;
mode->vtotal = mode->vdisplay + vblank;
- /* Some EDIDs have bogus h/vtotal values */
- if (mode->hsync_end > mode->htotal)
- mode->htotal = mode->hsync_end + 1;
- if (mode->vsync_end > mode->vtotal)
- mode->vtotal = mode->vsync_end + 1;
+ /* Some EDIDs have bogus h/vsync_end values */
+ if (mode->hsync_end > mode->htotal) {
+ drm_dbg_kms(dev, "[CONNECTOR:%d:%s] reducing hsync_end
%d->%d\n",
+ connector->base.id, connector->name,
+ mode->hsync_end, mode->htotal);
+ mode->hsync_end = mode->htotal;
+ }
+ if (mode->vsync_end > mode->vtotal) {
+ drm_dbg_kms(dev, "[CONNECTOR:%d:%s] reducing vsync_end
%d->%d\n",
+ connector->base.id, connector->name,
+ mode->vsync_end, mode->vtotal);
+ mode->vsync_end = mode->vtotal;
+ }
drm_mode_do_interlace_quirk(mode, pt);
--
2.41.0
Re: [PATCH] drm/virtio: add definition for venus capset
On 9/15/23 13:59, Huang Rui wrote:
> This definition is used fro qemu, and qemu imports this marco in the
> headers to enable venus for virtio gpu. So it should add it even kernel
> doesn't use this.
>
> Signed-off-by: Huang Rui
> ---
>
> Hi all,
>
> We would like to add a new definition for venus capset, it will be used for
> qemu. Please see details on below discussion:
>
> https://lore.kernel.org/qemu-devel/b82982aa-5b9e-481e-9491-b9313877b...@daynix.com/
>
> Thanks,
> Ray
>
> include/uapi/linux/virtio_gpu.h | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/include/uapi/linux/virtio_gpu.h b/include/uapi/linux/virtio_gpu.h
> index f556fde07b76..0e21f3998108 100644
> --- a/include/uapi/linux/virtio_gpu.h
> +++ b/include/uapi/linux/virtio_gpu.h
> @@ -309,6 +309,8 @@ struct virtio_gpu_cmd_submit {
>
> #define VIRTIO_GPU_CAPSET_VIRGL 1
> #define VIRTIO_GPU_CAPSET_VIRGL2 2
> +/* 3 is reserved for gfxstream */
> +#define VIRTIO_GPU_CAPSET_VENUS 4
Could you please add all other capsets, so we won't needed to do it
again in the future
--
Best regards,
Dmitry
Re: [PATCH] drm/virtio: clean out_fence on complete_submit
On 9/12/23 09:08, José Pekkarinen wrote: > The removed line prevents the following cleanup function > to execute a dma_fence_put on the out_fence to free its > memory, producing the following output in kmemleak: > > unreferenced object 0x888126d8ee00 (size 128): > comm "kwin_wayland", pid 981, jiffies 4295380296 (age 390.060s) > hex dump (first 32 bytes): > c8 a1 c2 27 81 88 ff ff e0 14 a9 c0 ff ff ff ff ...' > 30 1a e1 2e a6 00 00 00 28 fc 5b 17 81 88 ff ff 0...(.[. > backtrace: > [<11655661>] kmalloc_trace+0x26/0xa0 > [<55f15b82>] virtio_gpu_fence_alloc+0x47/0xc0 [virtio_gpu] > [] virtio_gpu_execbuffer_ioctl+0x1a8/0x800 [virtio_gpu] > [ ] drm_ioctl_kernel+0x169/0x240 [drm] > [<5ad33e27>] drm_ioctl+0x399/0x6b0 [drm] > [ ] __x64_sys_ioctl+0xc5/0x100 > [<11fa801e>] do_syscall_64+0x5b/0xc0 > [<65c76d8a>] entry_SYSCALL_64_after_hwframe+0x6e/0xd8 > unreferenced object 0x888121930500 (size 128): > comm "kwin_wayland", pid 981, jiffies 4295380313 (age 390.096s) > hex dump (first 32 bytes): > c8 a1 c2 27 81 88 ff ff e0 14 a9 c0 ff ff ff ff ...' > f9 ec d7 2f a6 00 00 00 28 fc 5b 17 81 88 ff ff .../(.[. > backtrace: > [<11655661>] kmalloc_trace+0x26/0xa0 > [<55f15b82>] virtio_gpu_fence_alloc+0x47/0xc0 [virtio_gpu] > [ ] virtio_gpu_execbuffer_ioctl+0x1a8/0x800 [virtio_gpu] > [ ] drm_ioctl_kernel+0x169/0x240 [drm] > [<5ad33e27>] drm_ioctl+0x399/0x6b0 [drm] > [ ] __x64_sys_ioctl+0xc5/0x100 > [<11fa801e>] do_syscall_64+0x5b/0xc0 > [<65c76d8a>] entry_SYSCALL_64_after_hwframe+0x6e/0xd8 > [...] > > This memleak will grow quickly, being possible to see the > following line in dmesg after few minutes of life in the > virtual machine: > > [ 706.217388] kmemleak: 10731 new suspected memory leaks (see > /sys/kernel/debug/kmemleak) > > The patch will remove the line to allow the cleanup > function do its job. > > Signed-off-by: José Pekkarinen > --- > drivers/gpu/drm/virtio/virtgpu_submit.c | 1 - > 1 file changed, 1 deletion(-) Added fixes tag and pushed to misc-fixes -- Best regards, Dmitry
Re: [PATCH v2] drm/i915: refactor deprecated strncpy
On Tue, Sep 19, 2023 at 04:45:31AM +, Justin Stitt wrote:
> `strncpy` is deprecated for use on NUL-terminated destination strings [1].
>
> We should prefer more robust and less ambiguous string interfaces.
>
> A suitable replacement is `strscpy` [2] due to the fact that it
> guarantees NUL-termination on the destination buffer without
> unnecessarily NUL-padding. `ctx` is zero allocated and as such strncpy's
> NUL-padding behavior was strictly a performance hit which is now
> resolved.
>
> Link:
> https://www.kernel.org/doc/html/latest/process/deprecated.html#strncpy-on-nul-terminated-strings
> [1]
> Link: https://manpages.debian.org/testing/linux-manual-4.8/strscpy.9.en.html
> [2]
> Link: https://github.com/KSPP/linux/issues/90
> Cc: linux-harden...@vger.kernel.org
> Signed-off-by: Justin Stitt
> ---
> Changes in v2:
> - drop the `... - 1` (thanks Kees)
> - Link to v1:
> https://lore.kernel.org/r/20230914-strncpy-drivers-gpu-drm-i915-gem-selftests-mock_context-c-v1-1-c3f92df94...@google.com
> ---
Reviewed-by: Rodrigo Vivi
and pushing it right now to drm-intel-gt-next
> drivers/gpu/drm/i915/gem/selftests/mock_context.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/i915/gem/selftests/mock_context.c
> b/drivers/gpu/drm/i915/gem/selftests/mock_context.c
> index 8ac6726ec16b..e199d7dbb876 100644
> --- a/drivers/gpu/drm/i915/gem/selftests/mock_context.c
> +++ b/drivers/gpu/drm/i915/gem/selftests/mock_context.c
> @@ -36,7 +36,7 @@ mock_context(struct drm_i915_private *i915,
> if (name) {
> struct i915_ppgtt *ppgtt;
>
> - strncpy(ctx->name, name, sizeof(ctx->name) - 1);
> + strscpy(ctx->name, name, sizeof(ctx->name));
>
> ppgtt = mock_ppgtt(i915, name);
> if (!ppgtt)
>
> ---
> base-commit: 3669558bdf354cd352be955ef2764cde6a9bf5ec
> change-id:
> 20230914-strncpy-drivers-gpu-drm-i915-gem-selftests-mock_context-c-980c8ecc9142
>
> Best regards,
> --
> Justin Stitt
>
Re: [PATCH v3 2/2] drm/bridge: imx: add driver for HDMI TX Parallel Video Interface
Hi Lucas,
Thank you for the patch.
On Wed, Sep 20, 2023 at 07:10:09PM +0200, Lucas Stach wrote:
> This IP block is found in the HDMI subsystem of the i.MX8MP SoC. It has a
> full timing generator and can switch between different video sources. On
> the i.MX8MP however the only supported source is the LCDIF. The block
> just needs to be powered up and told about the polarity of the video
> sync signals to act in bypass mode.
>
> Signed-off-by: Lucas Stach
> Reviewed-by: Luca Ceresoli (v2)
> Tested-by: Marek Vasut (v1)
> Tested-by: Luca Ceresoli (v2)
> Tested-by: Richard Leitner (v2)
> Tested-by: Frieder Schrempf (v2)
> ---
> drivers/gpu/drm/bridge/imx/Kconfig | 7 +
> drivers/gpu/drm/bridge/imx/Makefile | 1 +
> drivers/gpu/drm/bridge/imx/imx8mp-hdmi-pvi.c | 206 +++
> 3 files changed, 214 insertions(+)
> create mode 100644 drivers/gpu/drm/bridge/imx/imx8mp-hdmi-pvi.c
>
> diff --git a/drivers/gpu/drm/bridge/imx/Kconfig
> b/drivers/gpu/drm/bridge/imx/Kconfig
> index 9fae28db6aa7..3a4e663d922a 100644
> --- a/drivers/gpu/drm/bridge/imx/Kconfig
> +++ b/drivers/gpu/drm/bridge/imx/Kconfig
> @@ -3,6 +3,13 @@ if ARCH_MXC || COMPILE_TEST
> config DRM_IMX_LDB_HELPER
> tristate
>
> +config DRM_IMX8MP_HDMI_PVI
> + tristate "Freescale i.MX8MP HDMI PVI bridge support"
> + depends on OF
> + help
> + Choose this to enable support for the internal HDMI TX Parallel
> + Video Interface found on the Freescale i.MX8MP SoC.
> +
> config DRM_IMX8QM_LDB
> tristate "Freescale i.MX8QM LVDS display bridge"
> depends on OF
> diff --git a/drivers/gpu/drm/bridge/imx/Makefile
> b/drivers/gpu/drm/bridge/imx/Makefile
> index 8e2ebf3399a1..be9b4f9adb50 100644
> --- a/drivers/gpu/drm/bridge/imx/Makefile
> +++ b/drivers/gpu/drm/bridge/imx/Makefile
> @@ -1,4 +1,5 @@
> obj-$(CONFIG_DRM_IMX_LDB_HELPER) += imx-ldb-helper.o
> +obj-$(CONFIG_DRM_IMX8MP_HDMI_PVI) += imx8mp-hdmi-pvi.o
> obj-$(CONFIG_DRM_IMX8QM_LDB) += imx8qm-ldb.o
> obj-$(CONFIG_DRM_IMX8QXP_LDB) += imx8qxp-ldb.o
> obj-$(CONFIG_DRM_IMX8QXP_PIXEL_COMBINER) += imx8qxp-pixel-combiner.o
> diff --git a/drivers/gpu/drm/bridge/imx/imx8mp-hdmi-pvi.c
> b/drivers/gpu/drm/bridge/imx/imx8mp-hdmi-pvi.c
> new file mode 100644
> index ..5ccd70c98187
> --- /dev/null
> +++ b/drivers/gpu/drm/bridge/imx/imx8mp-hdmi-pvi.c
> @@ -0,0 +1,206 @@
> +// SPDX-License-Identifier: GPL-2.0+
> +
> +/*
> + * Copyright (C) 2022 Pengutronix, Lucas Stach
> + */
> +
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +
> +#define HTX_PVI_CTRL 0x0
> +#define PVI_CTRL_OP_VSYNC_POL BIT(18)
> +#define PVI_CTRL_OP_HSYNC_POL BIT(17)
> +#define PVI_CTRL_OP_DE_POL BIT(16)
> +#define PVI_CTRL_INP_VSYNC_POL BIT(14)
> +#define PVI_CTRL_INP_HSYNC_POL BIT(13)
> +#define PVI_CTRL_INP_DE_POL BIT(12)
> +#define PVI_CTRL_MODE_MASK GENMASK(2, 1)
> +#define PVI_CTRL_MODE_LCDIF 2
> +#define PVI_CTRL_EN BIT(0)
> +
> +struct imx8mp_hdmi_pvi {
> + struct drm_bridge bridge;
> + struct device *dev;
> + struct drm_bridge *next_bridge;
> + void __iomem*regs;
> +};
> +
> +static inline struct imx8mp_hdmi_pvi *
> +to_imx8mp_hdmi_pvi(struct drm_bridge *bridge)
> +{
> + return container_of(bridge, struct imx8mp_hdmi_pvi, bridge);
> +}
> +
> +static int imx8mp_hdmi_pvi_bridge_attach(struct drm_bridge *bridge,
> + enum drm_bridge_attach_flags flags)
> +{
> + struct imx8mp_hdmi_pvi *pvi = to_imx8mp_hdmi_pvi(bridge);
> +
> + return drm_bridge_attach(bridge->encoder, pvi->next_bridge,
> + bridge, flags);
> +}
> +
> +static void imx8mp_hdmi_pvi_bridge_enable(struct drm_bridge *bridge,
> + struct drm_bridge_state *bridge_state)
> +{
> + struct drm_atomic_state *state = bridge_state->base.state;
> + struct imx8mp_hdmi_pvi *pvi = to_imx8mp_hdmi_pvi(bridge);
> + struct drm_connector_state *conn_state;
> + const struct drm_display_mode *mode;
> + struct drm_crtc_state *crtc_state;
> + struct drm_connector *connector;
> + u32 bus_flags, val;
> +
> + connector = drm_atomic_get_new_connector_for_encoder(state,
> bridge->encoder);
> + conn_state = drm_atomic_get_new_connector_state(state, connector);
> + crtc_state = drm_atomic_get_new_crtc_state(state, conn_state->crtc);
> +
> + if (WARN_ON(pm_runtime_resume_and_get(pvi->dev)))
> + return;
> +
> + mode = &crtc_state->adjusted_mode;
> +
> + val = FIELD_PREP(PVI_CTRL_MODE_MASK, PVI_CTRL_MODE_LCDIF) | PVI_CTRL_EN;
> +
> + if (mode->flags & DRM_MODE_FLAG_PVSYNC)
> + val |= PVI_CTRL_OP_VSYNC_POL | PVI_CTRL_INP_VSYNC_POL;
> +
> + if (mode->flags & DRM_MODE_FLAG_PHSYNC
[PATCH] drm: improve the documentation of connector hpd ops
While making the changes in [1], it was noted that the documentation
of the enable_hpd() and disable_hpd() does not make it clear that
these ops should not try to do hpd state maintenance and should only
attempt to enable/disable hpd related hardware for the connector.
The state management of these calls to make sure these calls are
balanced is handled by the DRM core and we should keep it that way
to minimize the overhead in the drivers which implement these ops.
[1]: https://patchwork.freedesktop.org/patch/558387/
Signed-off-by: Abhinav Kumar
---
include/drm/drm_modeset_helper_vtables.h | 10 ++
1 file changed, 10 insertions(+)
diff --git a/include/drm/drm_modeset_helper_vtables.h
b/include/drm/drm_modeset_helper_vtables.h
index e3c3ac615909..a33cf7488737 100644
--- a/include/drm/drm_modeset_helper_vtables.h
+++ b/include/drm/drm_modeset_helper_vtables.h
@@ -1154,6 +1154,11 @@ struct drm_connector_helper_funcs {
* This operation is optional.
*
* This callback is used by the drm_kms_helper_poll_enable() helpers.
+*
+* This operation does not need to perform any hpd state tracking as
+* the DRM core handles that maintenance and ensures the calls to enable
+* and disable hpd are balanced.
+*
*/
void (*enable_hpd)(struct drm_connector *connector);
@@ -1165,6 +1170,11 @@ struct drm_connector_helper_funcs {
* This operation is optional.
*
* This callback is used by the drm_kms_helper_poll_disable() helpers.
+*
+* This operation does not need to perform any hpd state tracking as
+* the DRM core handles that maintenance and ensures the calls to enable
+* and disable hpd are balanced.
+*
*/
void (*disable_hpd)(struct drm_connector *connector);
};
--
2.40.1
[PATCH 4/4] drm/i915/dsi: Add some debug logging to mipi_exec_i2c (v2)
Add some debug logging to mipi_exec_i2c, to make debugging various
issues seen with it easier.
Changes in v2:
- Drop unnecessary __func__ drm_dbg_kms() argument
Signed-off-by: Hans de Goede
---
drivers/gpu/drm/i915/display/intel_dsi_vbt.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/gpu/drm/i915/display/intel_dsi_vbt.c
b/drivers/gpu/drm/i915/display/intel_dsi_vbt.c
index e56ec3f2d84a..24b2cbcfc1ef 100644
--- a/drivers/gpu/drm/i915/display/intel_dsi_vbt.c
+++ b/drivers/gpu/drm/i915/display/intel_dsi_vbt.c
@@ -565,6 +565,9 @@ static const u8 *mipi_exec_i2c(struct intel_dsi *intel_dsi,
const u8 *data)
u8 payload_size = *(data + 6);
u8 *payload_data;
+ drm_dbg_kms(&i915->drm, "bus %d client-addr 0x%02x reg 0x%02x data
%*ph\n",
+ vbt_i2c_bus_num, slave_addr, reg_offset, payload_size, data
+ 7);
+
if (intel_dsi->i2c_bus_num < 0) {
intel_dsi->i2c_bus_num = vbt_i2c_bus_num;
i2c_acpi_find_adapter(intel_dsi, slave_addr);
--
2.41.0
[PATCH 2/4] drm/i915/vlv_dsi: Add DMI quirk for wrong I2C bus and panel size on Lenovo Yoga Tablet 2 series (v3)
On the Lenovo Yoga Tablet 2 830 / 1050 there are 2 problems:
1. The I2C MIPI sequence elements reference bus 3. ACPI has I2C1 - I2C7
which under Linux become bus 0 - 6. And the MIPI sequence reference
to bus 3 is indented for I2C3 which is bus 2 under Linux.
This leads to errors like these:
[ 178.244049] i2c_designware 80860F41:03: controller timed out
[ 178.245703] i915 :00:02.0: [drm] *ERROR* Failed to xfer payload of
size (1) to reg (169)
There are 3 timeouts when the panel is on, delaying
waking up the screen on a key press by 3 seconds.
Note mipi_exec_i2c() cannot just subtract 1 from the bus
given in the I2C MIPI sequence element. Since on other
devices the I2C bus-numbers used in the MIPI sequences do
actually start at 0.
2. width_/height_mm contain a bogus 192mm x 120mm size. This is
especially a problem on the 8" 830 version which uses a 10:16
portrait screen where as the bogus size is 16:10.
Add a DMI quirk to override the I2C bus and the panel size with
the correct values.
Note both the 10" 1050 models as well as the 8" 830 models use the same
mainboard and thus the same DMI strings. The 10" 1050 uses a 1920x1200
landscape screen, where as the 8" 830 uses a 1200x1920 portrait screen,
so the quirk handling uses the display resolution to detect the model.
v2:
- Also override i2c_bus_num to fix mipi_exec_i2c() timeouts
v3:
- Add Closes tag to gitlab issue with drm.debug=0xe, VBT info
Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/9379
Reviewed-by: Javier Martinez Canillas
Signed-off-by: Hans de Goede
---
drivers/gpu/drm/i915/display/vlv_dsi.c | 52 ++
1 file changed, 52 insertions(+)
diff --git a/drivers/gpu/drm/i915/display/vlv_dsi.c
b/drivers/gpu/drm/i915/display/vlv_dsi.c
index 0d3aabf6a1dd..f69cafe8a17d 100644
--- a/drivers/gpu/drm/i915/display/vlv_dsi.c
+++ b/drivers/gpu/drm/i915/display/vlv_dsi.c
@@ -1767,6 +1767,44 @@ static void vlv_dsi_asus_tf103c_mode_fixup(struct
intel_dsi *intel_dsi)
fixed_mode->vtotal -= 4;
}
+/*
+ * On the Lenovo Yoga Tablet 2 830 / 1050 there are 2 problems:
+ * 1. The I2C MIPI sequence elements reference bus 3. ACPI has I2C1 - I2C7
+ *which under Linux become bus 0 - 6. And the MIPI sequence reference
+ *to bus 3 is indented for I2C3 which is bus 2 under Linux.
+ *
+ *Note mipi_exec_i2c() cannot just subtract 1 from the bus
+ *given in the I2C MIPI sequence element. Since on other
+ *devices the I2C bus-numbers used in the MIPI sequences do
+ *actually start at 0.
+ *
+ * 2. width_/height_mm contain a bogus 192mm x 120mm size. This is
+ *especially a problem on the 8" 830 version which uses a 10:16
+ *portrait screen where as the bogus size is 16:10.
+ *
+ * https://gitlab.freedesktop.org/drm/intel/-/issues/9379
+ */
+static void vlv_dsi_lenovo_yoga_tab2_size_fixup(struct intel_dsi *intel_dsi)
+{
+ const struct drm_display_mode *fixed_mode =
+ intel_panel_preferred_fixed_mode(intel_dsi->attached_connector);
+ struct drm_display_info *info =
&intel_dsi->attached_connector->base.display_info;
+
+ intel_dsi->i2c_bus_num = 2;
+
+ /*
+* The 10" 1050 uses a 1920x1200 landscape screen, where as the 8" 830
+* uses a 1200x1920 portrait screen.
+*/
+ if (fixed_mode->hdisplay == 1920) {
+ info->width_mm = 216;
+ info->height_mm = 135;
+ } else {
+ info->width_mm = 107;
+ info->height_mm = 171;
+ }
+}
+
static const struct dmi_system_id vlv_dsi_dmi_quirk_table[] = {
{
/* Asus Transformer Pad TF103C */
@@ -1776,6 +1814,20 @@ static const struct dmi_system_id
vlv_dsi_dmi_quirk_table[] = {
},
.driver_data = (void *)vlv_dsi_asus_tf103c_mode_fixup,
},
+ {
+ /*
+* Lenovo Yoga Tablet 2 830F/L or 1050F/L (The 8" and 10"
+* Lenovo Yoga Tablet 2 use the same mainboard)
+*/
+ .matches = {
+ DMI_MATCH(DMI_SYS_VENDOR, "Intel Corp."),
+ DMI_MATCH(DMI_PRODUCT_NAME, "VALLEYVIEW C0 PLATFORM"),
+ DMI_MATCH(DMI_BOARD_NAME, "BYT-T FFD8"),
+ /* Partial match on beginning of BIOS version */
+ DMI_MATCH(DMI_BIOS_VERSION, "BLADE_21"),
+ },
+ .driver_data = (void *)vlv_dsi_lenovo_yoga_tab2_size_fixup,
+ },
{ }
};
--
2.41.0
[PATCH 3/4] drm/i915/vlv_dsi: Add DMI quirk for backlight control issues on Lenovo Yoga Tab 3 (v2)
On the Lenovo Yoga Tab 3 Pro YT3-X90F there are 2 issues with the backlight
on/off MIPI sequences:
1. The backlight on sequence has an I2C MIPI sequence element which uses
bus 0, but there is a bogus I2cSerialBus resource under the GPU in
the DSDT which causes i2c_acpi_find_adapter() to pick the wrong bus.
2. There is no backlight off sequence, causing the backlight to stay on.
Add a DMI quirk fixing both issues.
v2:
- Add Closes tag to gitlab issue with drm.debug=0xe, VBT info
Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/9380
Signed-off-by: Hans de Goede
---
drivers/gpu/drm/i915/display/vlv_dsi.c | 34 ++
1 file changed, 34 insertions(+)
diff --git a/drivers/gpu/drm/i915/display/vlv_dsi.c
b/drivers/gpu/drm/i915/display/vlv_dsi.c
index f69cafe8a17d..55da627a8b8d 100644
--- a/drivers/gpu/drm/i915/display/vlv_dsi.c
+++ b/drivers/gpu/drm/i915/display/vlv_dsi.c
@@ -1805,6 +1805,31 @@ static void vlv_dsi_lenovo_yoga_tab2_size_fixup(struct
intel_dsi *intel_dsi)
}
}
+/*
+ * On the Lenovo Yoga Tab 3 Pro YT3-X90F there are 2 problems:
+ * 1. i2c_acpi_find_adapter() picks the wrong adapter causing mipi_exec_i2c()
+ *to not work. Fix this by setting i2c_bus_num.
+ * 2. There is no backlight off MIPI sequence, causing the backlight to stay
on.
+ *Add a backlight off sequence mirroring the existing backlight on
sequence.
+ *
+ * https://gitlab.freedesktop.org/drm/intel/-/issues/9380
+ */
+static void vlv_dsi_lenovo_yoga_tab3_backlight_fixup(struct intel_dsi
*intel_dsi)
+{
+ static const u8 backlight_off_sequence[16] = {
+ /* Header Seq-id 7, length after header 11 bytes */
+ 0x07, 0x0b, 0x00, 0x00, 0x00,
+ /* MIPI_SEQ_ELEM_I2C bus 0 addr 0x2c reg 0x00 data-len 1 data
0x00 */
+ 0x04, 0x08, 0x00, 0x00, 0x00, 0x2c, 0x00, 0x00, 0x01, 0x00,
+ /* MIPI_SEQ_ELEM_END */
+ 0x00
+ };
+ struct intel_connector *connector = intel_dsi->attached_connector;
+
+ intel_dsi->i2c_bus_num = 0;
+ connector->panel.vbt.dsi.sequence[MIPI_SEQ_BACKLIGHT_OFF] =
backlight_off_sequence;
+}
+
static const struct dmi_system_id vlv_dsi_dmi_quirk_table[] = {
{
/* Asus Transformer Pad TF103C */
@@ -1828,6 +1853,15 @@ static const struct dmi_system_id
vlv_dsi_dmi_quirk_table[] = {
},
.driver_data = (void *)vlv_dsi_lenovo_yoga_tab2_size_fixup,
},
+ {
+ /* Lenovo Yoga Tab 3 Pro YT3-X90F */
+ .matches = {
+ DMI_MATCH(DMI_SYS_VENDOR, "Intel Corporation"),
+ DMI_MATCH(DMI_PRODUCT_NAME, "CHERRYVIEW D1 PLATFORM"),
+ DMI_MATCH(DMI_PRODUCT_VERSION, "Blade3-10A-001"),
+ },
+ .driver_data = (void *)vlv_dsi_lenovo_yoga_tab3_backlight_fixup,
+ },
{ }
};
--
2.41.0
[PATCH 1/4] drm/i915/vlv_dsi: Add DMI quirk for wrong panel modeline in BIOS on Asus TF103C (v3)
Vtotal is wrong in the BIOS supplied modeline for the DSI panel on
the Asus TF103C leading to the last line of the display being shown
as the first line.
Original: "1280x800": 60 67700 1280 1312 1328 1376 800 808 812 820 0x8 0xa
Fixed:"1280x800": 60 67700 1280 1312 1328 1376 800 808 812 816 0x8 0xa
The factory installed Android has a hardcoded modeline in its kernel,
causing it to not suffer from this BIOS bug;
and the Android boot-splash which uses the EFI FB which does have this bug
has the last line all black causing the bug to not be visible.
This commit introduces a generic DMI based quirk mechanism to vlv_dsi for
doing various fixups, and uses this to correct the modeline.
v2:
- s/mode_fixup/dmi_quirk/ to make the new DMI quirk mechanism more generic
- Add a comment with the old and new modelines to the patch and commit msg
v3:
- Add Closes tag to gitlab issue with drm.debug=0xe, VBT info
Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/9381
Reviewed-by: Javier Martinez Canillas
Signed-off-by: Hans de Goede
---
drivers/gpu/drm/i915/display/vlv_dsi.c | 44 ++
1 file changed, 44 insertions(+)
diff --git a/drivers/gpu/drm/i915/display/vlv_dsi.c
b/drivers/gpu/drm/i915/display/vlv_dsi.c
index a96e7d028c5c..0d3aabf6a1dd 100644
--- a/drivers/gpu/drm/i915/display/vlv_dsi.c
+++ b/drivers/gpu/drm/i915/display/vlv_dsi.c
@@ -23,6 +23,7 @@
* Author: Jani Nikula
*/
+#include
#include
#include
@@ -1744,6 +1745,40 @@ static void vlv_dphy_param_init(struct intel_dsi
*intel_dsi)
intel_dsi_log_params(intel_dsi);
}
+typedef void (*vlv_dsi_dmi_quirk_func)(struct intel_dsi *intel_dsi);
+
+/*
+ * Vtotal is wrong on the Asus TF103C leading to the last line of the display
+ * being shown as the first line. The factory installed Android has a hardcoded
+ * modeline, causing it to not suffer from this BIOS bug.
+ *
+ * Original mode: "1280x800": 60 67700 1280 1312 1328 1376 800 808 812 820 0x8
0xa
+ * Fixedmode: "1280x800": 60 67700 1280 1312 1328 1376 800 808 812 816 0x8
0xa
+ *
+ * https://gitlab.freedesktop.org/drm/intel/-/issues/9381
+ */
+static void vlv_dsi_asus_tf103c_mode_fixup(struct intel_dsi *intel_dsi)
+{
+ /* Cast away the const as we want to fixup the mode */
+ struct drm_display_mode *fixed_mode = (struct drm_display_mode *)
+ intel_panel_preferred_fixed_mode(intel_dsi->attached_connector);
+
+ if (fixed_mode->vtotal == 820)
+ fixed_mode->vtotal -= 4;
+}
+
+static const struct dmi_system_id vlv_dsi_dmi_quirk_table[] = {
+ {
+ /* Asus Transformer Pad TF103C */
+ .matches = {
+ DMI_MATCH(DMI_SYS_VENDOR, "ASUSTeK COMPUTER INC."),
+ DMI_MATCH(DMI_PRODUCT_NAME, "TF103C"),
+ },
+ .driver_data = (void *)vlv_dsi_asus_tf103c_mode_fixup,
+ },
+ { }
+};
+
void vlv_dsi_init(struct drm_i915_private *dev_priv)
{
struct intel_dsi *intel_dsi;
@@ -1752,6 +1787,7 @@ void vlv_dsi_init(struct drm_i915_private *dev_priv)
struct intel_connector *intel_connector;
struct drm_connector *connector;
struct drm_display_mode *current_mode;
+ const struct dmi_system_id *dmi_id;
enum port port;
enum pipe pipe;
@@ -1883,6 +1919,14 @@ void vlv_dsi_init(struct drm_i915_private *dev_priv)
goto err_cleanup_connector;
}
+ dmi_id = dmi_first_match(vlv_dsi_dmi_quirk_table);
+ if (dmi_id) {
+ vlv_dsi_dmi_quirk_func quirk_func =
+ (vlv_dsi_dmi_quirk_func)dmi_id->driver_data;
+
+ quirk_func(intel_dsi);
+ }
+
intel_panel_init(intel_connector, NULL);
intel_backlight_setup(intel_connector, INVALID_PIPE);
--
2.41.0
[PATCH 0/4] drm/i915/vlv_dsi: Add quirks for x86 android tablets (v3)
Hi All, Some vlv/chv tablets ship with Android as factory OS. The factory OS BSP style kernel on these tablets does not use the normal x86 hw autodetection instead it hardcodes a whole bunch of things including using panel drivers instead of relying on VBT MIPI sequences to turn the panel/backlight on/off. The normal i915 driver (which does not use panel drivers) mostly works since the VBT still needs to contain valid info for the GOP, but because of the Android kernel relying on panel drivers with various things hardcoded some DMI quirks are necessary to fix some issues on these devices. Some of these issues also are related to which I2C bus to use for MIPI sequence elements which do I2C transfers. This series also includes a patch adding some extra debugging to mipi_exec_i2c() to help with debugging similar issues in the future. These patches have been posted before but back then I did not get around to follow up on the series: https://lore.kernel.org/intel-gfx/20220225214934.383168-1-hdego...@redhat.com/ v2: - Drop the changes how the I2C bus number is found, instead just have the quirks set the right number directly where necessary. This should avoid any chances of causing regressions on devices where the quirks do not apply. - New quirk for backlight control issues on Lenovo Yoga Tab 3 - Address Jani Nikula's remark about __func__ being redundant when using drm_dbg_kms() v3: - File 3 gitlab issues with drm.debug=0xe dmesg output, VBT dump for all 3 affected models. Add Closes: tags with links to gitlab issues Regards, Hans Hans de Goede (4): drm/i915/vlv_dsi: Add DMI quirk for wrong panel modeline in BIOS on Asus TF103C (v3) drm/i915/vlv_dsi: Add DMI quirk for wrong I2C bus and panel size on Lenovo Yoga Tablet 2 series (v3) drm/i915/vlv_dsi: Add DMI quirk for backlight control issues on Lenovo Yoga Tab 3 (v2) drm/i915/dsi: Add some debug logging to mipi_exec_i2c (v2) drivers/gpu/drm/i915/display/intel_dsi_vbt.c | 3 + drivers/gpu/drm/i915/display/vlv_dsi.c | 124 +++ 2 files changed, 127 insertions(+) -- 2.41.0
Re: [PATCH 0/4] drm/i915/vlv_dsi: Add quirks for x86 android tablets (v2)
Hi Ville, On 9/18/23 10:00, Ville Syrjälä wrote: > On Sat, Sep 16, 2023 at 02:54:51PM +0200, Hans de Goede wrote: >> Hi All, >> >> Some vlv/chv tablets ship with Android as factory OS. The factory OS >> BSP style kernel on these tablets does not use the normal x86 hw >> autodetection instead it hardcodes a whole bunch of things including >> using panel drivers instead of relying on VBT MIPI sequences to >> turn the panel/backlight on/off. >> >> The normal i915 driver (which does not use panel drivers) mostly works >> since the VBT still needs to contain valid info for the GOP, but because >> of the Android kernel relying on panel drivers with various things >> hardcoded some DMI quirks are necessary to fix some issues on these >> devices. >> >> Some of these issues also are related to which I2C bus to use for >> MIPI sequence elements which do I2C transfers. This series also >> includes a patch adding some extra debugging to mipi_exec_i2c() to >> help with debugging similar issues in the future. >> >> These patches have been posted before but back then I did not get around >> to follow up on the series: >> https://lore.kernel.org/intel-gfx/20220225214934.383168-1-hdego...@redhat.com/ >> >> Changes compared to this old version: >> - Drop the changes how the I2C bus number is found, instead just have >> the quirks set the right number directly where necessary. This should >> avoid any chances of causing regressions on devices where the quirks >> do not apply. >> >> - New quirk for backlight control issues on Lenovo Yoga Tab 3 >> >> - Address Jani Nikula's remark about __func__ being redundant when using >> drm_dbg_kms() >> >> >> Regards, >> >> Hans >> >> >> >> Hans de Goede (4): >> drm/i915/vlv_dsi: Add DMI quirk for wrong panel modeline in BIOS on >> Asus TF103C (v2) >> drm/i915/vlv_dsi: Add DMI quirk for wrong I2C bus and panel size on >> Lenovo Yoga Tablet 2 series (v2) >> drm/i915/vlv_dsi: Add DMI quirk for backlight control issues on Lenovo >> Yoga Tab 3 > > Please file a bug for each of these and attach the usual drm.debug=0xe > dmesg + VBT + any other relevant information there. Otherwise a few > years from now I'll be cursing at these commits as well for not leaving > a decent papertrail... Ok. I've just completed filing 3 issues (1 per affected model) and I've added Closes: tags to the patches pointing to the issues. I'll send out a v3 of this series with the Closes tags. Regards, Hans > >> drm/i915/dsi: Add some debug logging to mipi_exec_i2c (v2) >> >> drivers/gpu/drm/i915/display/intel_dsi_vbt.c | 3 + >> drivers/gpu/drm/i915/display/vlv_dsi.c | 124 +++ >> 2 files changed, 127 insertions(+) >> >> -- >> 2.41.0 >
Re: [PATCH v3 6/7] drm/msm/dp: add pm_runtime_force_suspend()/resume()
On 9/19/2023 2:50 AM, Dmitry Baryshkov wrote:
On Mon, 18 Sept 2023 at 20:48, Kuogee Hsieh wrote:
On 9/15/2023 6:21 PM, Dmitry Baryshkov wrote:
On Sat, 16 Sept 2023 at 00:38, Kuogee Hsieh wrote:
Add pm_runtime_force_suspend()/resume() to complete incorporating pm
runtime framework into DP driver. Both dp_pm_prepare() and dp_pm_complete()
are added to set hpd_state to correct state. After resume, DP driver will
re training its main link after .hpd_enable() callback enabled HPD
interrupts and bring up display accordingly.
How will it re-train the main link? What is the code path for that?
1) for edp, dp_bridge_atomic_enable(), called from framework, to start
link training and bring up display.
And this path doesn't use .hpd_enable() which you have mentioned in
the commit message. Please don't try to shorten the commit message.
You see, I have had questions to several of them, which means that
they were not verbose enough.
ok, my bad,
I will add more explain to commit text.
2) for external DP, HPD_PLUG_INT will be generated to start link
training and bring up display.
This should be hpd_notify, who starts link training, not some event.
I think this is a misuse for prepare/complete callbacks, at least
judging from their documentation.
1) dp_pm_prepare() is called to make sure eDP/DP related power/clocks
are off and set hpd_state to ST_SUSPENDED and nothing else.
2) dp_pm_completed() is called to set hpd_state to ST_ST_DISCONNECTED
(default state) and nothing else.
I think both are doing proper action.
Have you read the prepare() / complete() documentation? Does your
usage follow the documented use case?
I think I can just remove both dp_pm_prepare and dp_pm_complete fro
this patch.
Changes in v3:
-- replace dp_pm_suspend() with pm_runtime_force_suspend()
-- replace dp_pm_resume() with pm_runtime_force_resume()
Signed-off-by: Kuogee Hsieh
---
drivers/gpu/drm/msm/dp/dp_display.c | 87
+
1 file changed, 10 insertions(+), 77 deletions(-)
diff --git a/drivers/gpu/drm/msm/dp/dp_display.c
b/drivers/gpu/drm/msm/dp/dp_display.c
index b6992202..b58cb02 100644
--- a/drivers/gpu/drm/msm/dp/dp_display.c
+++ b/drivers/gpu/drm/msm/dp/dp_display.c
@@ -1333,101 +1333,35 @@ static int dp_pm_runtime_resume(struct device *dev)
return 0;
}
-static int dp_pm_resume(struct device *dev)
+static void dp_pm_complete(struct device *dev)
{
- struct platform_device *pdev = to_platform_device(dev);
- struct msm_dp *dp_display = platform_get_drvdata(pdev);
- struct dp_display_private *dp;
- int sink_count = 0;
-
- dp = container_of(dp_display, struct dp_display_private, dp_display);
+ struct dp_display_private *dp = dev_get_dp_display_private(dev);
mutex_lock(&dp->event_mutex);
drm_dbg_dp(dp->drm_dev,
- "Before, type=%d core_inited=%d phy_inited=%d power_on=%d\n",
+ "type=%d core_inited=%d phy_inited=%d power_on=%d\n",
dp->dp_display.connector_type, dp->core_initialized,
- dp->phy_initialized, dp_display->power_on);
+ dp->phy_initialized, dp->dp_display.power_on);
/* start from disconnected state */
dp->hpd_state = ST_DISCONNECTED;
- /* turn on dp ctrl/phy */
- dp_display_host_init(dp);
-
- if (dp_display->is_edp)
- dp_catalog_ctrl_hpd_enable(dp->catalog);
-
- if (dp_catalog_link_is_connected(dp->catalog)) {
- /*
-* set sink to normal operation mode -- D0
-* before dpcd read
-*/
- dp_display_host_phy_init(dp);
- dp_link_psm_config(dp->link, &dp->panel->link_info, false);
- sink_count = drm_dp_read_sink_count(dp->aux);
- if (sink_count < 0)
- sink_count = 0;
-
- dp_display_host_phy_exit(dp);
- }
-
- dp->link->sink_count = sink_count;
- /*
-* can not declared display is connected unless
-* HDMI cable is plugged in and sink_count of
-* dongle become 1
-* also only signal audio when disconnected
-*/
- if (dp->link->sink_count) {
- dp->dp_display.link_ready = true;
- } else {
- dp->dp_display.link_ready = false;
- dp_display_handle_plugged_change(dp_display, false);
- }
-
- drm_dbg_dp(dp->drm_dev,
- "After, type=%d sink=%d conn=%d core_init=%d phy_init=%d
power=%d\n",
- dp->dp_display.connector_type, dp->link->sink_count,
- dp->dp_display.link_ready, dp->core_initialized,
- dp->phy_initialized, dp_display->power_on);
-
mutex_unlock(&dp->event_mutex);
-
- return 0;
}
-static int dp_pm_suspend(struct device *dev)
+static int dp_pm_prepare(struct device *dev)
{
- struct platform_device *pdev = to_platform_devi
Re: [PATCH] drm/ci: Uprev IGT to pull in fixes
On Wed, Sep 20, 2023 at 11:53 AM Helen Koike wrote: > > Hi Rob, > > Thanks for the patch. > > On 20/09/2023 15:10, Rob Clark wrote: > > On Wed, Sep 20, 2023 at 11:06 AM Rob Clark wrote: > >> > >> From: Rob Clark > >> > >> There have been a few igt test fixes compared to the commit that we were > >> currently using. Pull in a newer igt and update expectations. > >> > >> Signed-off-by: Rob Clark > >> --- > > Could you send here the url of a pipeline run with this change? https://gitlab.freedesktop.org/drm/msm/-/pipelines/989913 That was before I wrote a proper commit msg so you can ignore the checkpatch job.. and there is an unrelated issue with the sdm845 runners not booting w/ v6.6-rc2, which still needs to be tracked down. BR, -R > >> drivers/gpu/drm/ci/gitlab-ci.yml | 2 +- > >> .../gpu/drm/ci/xfails/amdgpu-stoney-fails.txt | 4 ++-- > >> drivers/gpu/drm/ci/xfails/i915-apl-fails.txt | 11 --- > >> drivers/gpu/drm/ci/xfails/i915-cml-fails.txt | 2 +- > >> drivers/gpu/drm/ci/xfails/i915-tgl-fails.txt | 1 - > >> drivers/gpu/drm/ci/xfails/msm-sc7180-skips.txt | 18 +- > >> .../drm/ci/xfails/rockchip-rk3288-fails.txt| 2 ++ > >> 7 files changed, 7 insertions(+), 33 deletions(-) > >> > >> diff --git a/drivers/gpu/drm/ci/gitlab-ci.yml > >> b/drivers/gpu/drm/ci/gitlab-ci.yml > >> index 2c4df53f5dfe..3ecb5879e80f 100644 > >> --- a/drivers/gpu/drm/ci/gitlab-ci.yml > >> +++ b/drivers/gpu/drm/ci/gitlab-ci.yml > >> @@ -5,7 +5,7 @@ variables: > >> UPSTREAM_REPO: git://anongit.freedesktop.org/drm/drm > >> TARGET_BRANCH: drm-next > >> > >> - IGT_VERSION: 471bfababd070e1dac0ebb87470ac4f2ae85e663 > >> + IGT_VERSION: 2517e42d612e0c1ca096acf8b5f6177f7ef4bce7 > >> > >> DEQP_RUNNER_GIT_URL: > >> https://gitlab.freedesktop.org/anholt/deqp-runner.git > >> DEQP_RUNNER_GIT_TAG: v0.15.0 > >> diff --git a/drivers/gpu/drm/ci/xfails/amdgpu-stoney-fails.txt > >> b/drivers/gpu/drm/ci/xfails/amdgpu-stoney-fails.txt > >> index bd9392536e7c..bab21930a0d4 100644 > >> --- a/drivers/gpu/drm/ci/xfails/amdgpu-stoney-fails.txt > >> +++ b/drivers/gpu/drm/ci/xfails/amdgpu-stoney-fails.txt > >> @@ -1,7 +1,6 @@ > >> kms_addfb_basic@bad-pitch-65536,Fail > >> kms_addfb_basic@bo-too-small,Fail > >> kms_async_flips@invalid-async-flip,Fail > >> -kms_atomic@plane-immutable-zpos,Fail > >> kms_atomic_transition@plane-toggle-modeset-transition,Fail > >> kms_bw@linear-tiling-1-displays-2560x1440p,Fail > >> kms_bw@linear-tiling-1-displays-3840x2160p,Fail > >> @@ -11,9 +10,10 @@ kms_color@degamma,Fail > >> kms_cursor_crc@cursor-size-change,Fail > >> kms_cursor_crc@pipe-A-cursor-size-change,Fail > >> kms_cursor_crc@pipe-B-cursor-size-change,Fail > >> -kms_cursor_legacy@forked-move,Fail > >> kms_hdr@bpc-switch,Fail > >> kms_hdr@bpc-switch-dpms,Fail > >> kms_plane_multiple@atomic-pipe-A-tiling-none,Fail > >> kms_rmfb@close-fd,Fail > >> kms_rotation_crc@primary-rotation-180,Fail > >> +kms_flip@flip-vs-modeset-vs-hang,Fail > >> +kms_flip@flip-vs-panning-vs-hang,Fail > >> diff --git a/drivers/gpu/drm/ci/xfails/i915-apl-fails.txt > >> b/drivers/gpu/drm/ci/xfails/i915-apl-fails.txt > >> index 46397ce38d5a..2e3b7c5dac3c 100644 > >> --- a/drivers/gpu/drm/ci/xfails/i915-apl-fails.txt > >> +++ b/drivers/gpu/drm/ci/xfails/i915-apl-fails.txt > >> @@ -8,13 +8,6 @@ kms_bw@linear-tiling-3-displays-3840x2160p,Fail > >> kms_bw@linear-tiling-4-displays-1920x1080p,Fail > >> kms_bw@linear-tiling-4-displays-2560x1440p,Fail > >> kms_bw@linear-tiling-4-displays-3840x2160p,Fail > >> -kms_color@ctm-0-25,Fail > >> -kms_color@ctm-0-50,Fail > >> -kms_color@ctm-0-75,Fail > >> -kms_color@ctm-max,Fail > >> -kms_color@ctm-negative,Fail > >> -kms_color@ctm-red-to-blue,Fail > >> -kms_color@ctm-signed,Fail > >> kms_flip_scaled_crc@flip-32bpp-linear-to-64bpp-linear-downscaling,Fail > >> kms_flip_scaled_crc@flip-32bpp-linear-to-64bpp-linear-upscaling,Fail > >> kms_flip_scaled_crc@flip-32bpp-xtile-to-64bpp-xtile-downscaling,Fail > >> @@ -38,8 +31,6 @@ > >> kms_flip_scaled_crc@flip-64bpp-ytile-to-32bpp-ytile-upscaling,Fail > >> > >> kms_flip_scaled_crc@flip-64bpp-ytile-to-32bpp-ytilegen12rcccs-upscaling,Fail > >> kms_flip_scaled_crc@flip-64bpp-ytile-to-32bpp-ytilercccs-downscaling,Fail > >> kms_flip_scaled_crc@flip-64bpp-ytile-to-32bpp-ytilercccs-upscaling,Fail > >> -kms_hdmi_inject@inject-4k,Timeout > >> -kms_plane@plane-position-hole,Timeout > >> kms_plane_alpha_blend@alpha-basic,Fail > >> kms_plane_alpha_blend@alpha-opaque-fb,Fail > >> kms_plane_alpha_blend@alpha-transparent-fb,Fail > >> @@ -53,6 +44,4 @@ kms_plane_alpha_blend@pipe-B-constant-alpha-max,Fail > >> kms_plane_alpha_blend@pipe-C-alpha-opaque-fb,Fail > >> kms_plane_alpha_blend@pipe-C-alpha-transparent-fb,Fail > >> kms_plane_alpha_blend@pipe-C-constant-alpha-max,Fail > >> -kms_plane_multiple@tiling-y,Timeout > >> -kms_pwrite_crc,Timeout > >> kms_sysfs_edid_timing,Fail > >> diff --git
Re: [PATCH] omap: dsi: do not WARN on detach if dsidev was never attached
Hi,
On Tue, Sep 19, 2023 at 03:37:28PM +0200, H. Nikolaus Schaller wrote:
> dsi_init_output() called by dsi_probe() may fail. In that
> case mipi_dsi_host_unregister() is called which may call
> omap_dsi_host_detach() with uninitialized dsi->dsidev
> because omap_dsi_host_attach() was never called before.
>
> This happens if the panel driver asks for an EPROBE_DEFER.
>
> So let's suppress the WARN() in this special case.
...
> Signed-off-by: H. Nikolaus Schaller
> ---
Reviewed-by: Sebastian Reichel
-- Sebastian
> drivers/gpu/drm/omapdrm/dss/dsi.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/omapdrm/dss/dsi.c
> b/drivers/gpu/drm/omapdrm/dss/dsi.c
> index ea63c64d3a1ab..c37eb6b1b9a39 100644
> --- a/drivers/gpu/drm/omapdrm/dss/dsi.c
> +++ b/drivers/gpu/drm/omapdrm/dss/dsi.c
> @@ -4411,7 +4411,7 @@ static int omap_dsi_host_detach(struct mipi_dsi_host
> *host,
> {
> struct dsi_data *dsi = host_to_omap(host);
>
> - if (WARN_ON(dsi->dsidev != client))
> + if (!dsi->dsidev || WARN_ON(dsi->dsidev != client))
> return -EINVAL;
>
> cancel_delayed_work_sync(&dsi->dsi_disable_work);
> --
> 2.42.0
>
signature.asc
Description: PGP signature
Re: [Intel-gfx] [PATCH] drm/edid: Fixup h/vsync_end instead of h/vtotal
On Wed, Sep 20, 2023 at 08:40:00PM +0300, Jani Nikula wrote:
> On Thu, 14 Sep 2023, Ville Syrjala wrote:
> > From: Ville Syrjälä
> >
> > There are some weird EDIDs floating around that have the sync
> > pulse extending beyond the end of the blanking period.
> >
> > On the currently problemtic machine (HP Omni 120) EDID reports
> > the following mode:
> > "1600x900": 60 108000 1600 1780 1860 1800 900 910 913 1000 0x40 0x5
> > which is then "corrected" to have htotal=1861 by the current drm_edid.c
> > code.
> >
> > The fixup code was originally added in commit 7064fef56369 ("drm: work
> > around EDIDs with bad htotal/vtotal values"). Googling around we end up in
> > https://bugs.launchpad.net/ubuntu/hardy/+source/xserver-xorg-video-intel/+bug/297245
> > where we find an EDID for a Dell Studio 15, which reports:
> > (II) VESA(0): clock: 65.0 MHz Image Size: 331 x 207 mm
> > (II) VESA(0): h_active: 1280 h_sync: 1328 h_sync_end 1360 h_blank_end
> > 1337 h_border: 0
> > (II) VESA(0): v_active: 800 v_sync: 803 v_sync_end 809 v_blanking: 810
> > v_border: 0
> >
> > Note that if we use the hblank size (as opposed of the hsync_end)
> > from the DTD to determine htotal we get exactly 60Hz refresh rate in
> > both cases, whereas using hsync_end to determine htotal we get a
> > slightly lower refresh rates. This makes me believe the using the
> > hblank size is what was intended even in those cases.
> >
> > Also note that in case of the HP Onmi 120 the VBIOS boots with these:
> > crtc timings: 108000 1600 1780 1860 1800 900 910 913 1000, type: 0x40
> > flags: 0x5
> > ie. it just blindly stuffs the bogus hsync_end and htotal from the DTD
> > into the transcoder timing registers, and the display works. I believe
> > the (at least more modern) hardware will automagically terminate the hsync
> > pulse when the timing generator reaches htotal, which again points that we
> > should use the hblank size to determine htotal. Unfortunatley the old bug
> > reports for the Dell machines are extremely lacking in useful details so
> > we have no idea what kind of timings the VBIOS programmed into the
> > hardware :(
> >
> > Let's just flip this quirk around and reduce the length of the sync
> > pulse instead of extending the blanking period. This at least seems
> > to be the correct thing to do on more modern hardware. And if any
> > issues crop up on older hardware we need to debug them properly.
> >
> > Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/8895
> > Signed-off-by: Ville Syrjälä
> > ---
> > drivers/gpu/drm/drm_edid.c | 6 +++---
> > 1 file changed, 3 insertions(+), 3 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
> > index 39dd3f694544..0c5563b4d21e 100644
> > --- a/drivers/gpu/drm/drm_edid.c
> > +++ b/drivers/gpu/drm/drm_edid.c
> > @@ -3497,11 +3497,11 @@ static struct drm_display_mode
> > *drm_mode_detailed(struct drm_connector *connecto
> > mode->vsync_end = mode->vsync_start + vsync_pulse_width;
> > mode->vtotal = mode->vdisplay + vblank;
> >
> > - /* Some EDIDs have bogus h/vtotal values */
> > + /* Some EDIDs have bogus h/vsync_end values */
> > if (mode->hsync_end > mode->htotal)
> > - mode->htotal = mode->hsync_end + 1;
> > + mode->hsync_end = mode->htotal;
> > if (mode->vsync_end > mode->vtotal)
> > - mode->vtotal = mode->vsync_end + 1;
> > + mode->vsync_end = mode->vtotal;
>
> I wonder if we shouldn't debug log these to help our future selves?
Yeah, might be a good idea. I can respin with that. I noticed
that our VBT parser has the exact same code in it as well so
I'll be wanting to cook up a patch that as well.
>
> Anyway,
>
> Reviewed-by: Jani Nikula
Ta.
>
>
> >
> > drm_mode_do_interlace_quirk(mode, pt);
>
> --
> Jani Nikula, Intel
--
Ville Syrjälä
Intel
Re: Decrypting tt maps in ttm
On 9/20/23 20:24, Zack Rusin wrote: On Wed, 2023-09-20 at 19:17 +0200, Thomas Hellström wrote: !! External Email Hi, Zack On 9/20/23 18:39, Zack Rusin wrote: On Wed, 2023-09-20 at 12:48 +0200, Christian König wrote: !! External Email Am 20.09.23 um 09:36 schrieb Thomas Hellström: Hi, Zack, On 9/20/23 05:43, Zack Rusin wrote: On Tue, 2023-09-19 at 09:47 +0200, Christian König wrote: !! External Email Am 19.09.23 um 08:56 schrieb Thomas Hellström: On 9/19/23 07:39, Christian König wrote: Am 19.09.23 um 03:26 schrieb Zack Rusin: On Mon, 2023-09-18 at 16:21 -0400, Alex Deucher wrote: !! External Email On Mon, Sep 18, 2023 at 3:06 PM Thomas Hellström wrote: On 9/18/23 17:52, Zack Rusin wrote: On Mon, 2023-09-18 at 17:13 +0200, Thomas Hellström wrote: Hi, On 9/18/23 16:56, Thomas Hellström wrote: Hi Zack, Christian On 9/18/23 13:36, Christian König wrote: Hi Zack, adding Thomas and Daniel. I briefly remember that I talked with Thomas and some other people about that quite a while ago as well, but I don't fully remember the outcome. Found one old thread, but didn't read it: https://lists.freedesktop.org/archives/dri-devel/2019-September/234100.html /Thomas Ugh. Now starting to read that thread I have a vague recollection it all ended with not supporting mapping any device pages whatsoever when SEV was enabled, but rather resorting to llvmpipe and VM-local bos. Hi, Thomas. Thanks for finding this! I'd (of course) like to solve it properly and get vmwgfx running with 3d support with SEV-ES active instead of essentially disabling the driver when SEV-ES is active. I think there are two separate discussions there, the non-controversial one and the controversial one: 1) The non-controversial: is there a case where drivers would want encrypted memory for TT pages but not for io mem mappings? Because if not then as Christian pointed out we could just add pgprot_decrypted to ttm_io_prot and be essentially done. The current method of decrypting io mem but leaving sys mem mappings encrypted is a bit weird anyway. If the answer to that question is "yes, some driver does want the TT mappings to be encrypted" then your "[PATCH v2 3/4] drm/ttm, drm/vmwgfx: Correctly support support AMD memory encryption" solves that. I think getting one of those two in makes sense regardless of everything else, agreed? Well, there is more to it I think. IIRC, the AMD SME encryption mode has a way for a device to have the memory controller (?) encrypt / decrypt device traffic by using an address range alias, so in theory it supports encrypted TT pages, and the dma-layer may indeed hand encrypted DMA pages to TTM on such systems depending on the device's DMA mask. That's why I think that force_dma_unencrypted() export was needed, and If the amdgpu driver accesses TT memory in SME mode *without* pgprot_decrypted() and it still works, then I think that mode is actually used. How could it otherwise work? For SME, as long as the encrypted bit is set in the physical address used for DMA, the memory controller will handle the encrypt/decrypt for the device. For devices with a limited dma mask, you need to use the IOMMU so that the encrypted bit is retained when the address hits the memory controller. How does that work on systems with swiotlb, e.g. swiotlb=force, or i.e. what would decrypt the ttm tt mappings when copying between system and vram when iommu is disabled/absent? SME makes it mandatory that all devices can handle the physical address used for DMA, either native or with the help of IOMMU. Hacks like SWIOTLB are not directly supported as far as I know. Maybe somehow SWIOTLB manually decrypts the data while copying it or something like this, but I'm not 100% sure if that is actually implemented. Regards, Christian. A bold guess after looking at various code and patches: 1) Devices under SME that don't support the encryption bit and SEV: a) Coherent memory is unencrypted. b) Streaming DMA under IOMMU: The IOMMU sets the encrypted bit. c) Streaming DMA with SWIOTLB: The bounce buffer is unencrypted. Copying to/from bounce-buffer decrypts/encrypts. 2) Devices under SME that do support the encryption bit (which I believe is most graphics devices in general on SME systems, not just amdgpu; it "just works") *) Coherent memory is encrypted. The DMA layer sets dma addresses and pgprot accordingly. *) Streaming DMA is encrypted. So the bug in TTM would then be it's not handling 1a) and 1b) correctly. Remedy: 1b) Shouldn't be used with encryption. 1a) This is what we should try to fix. Exporting dma_force_unencrypted() didn't seem to be a way forward. Properly fixing this would, I guess, mean implement the missing functionality in the dma layer: For vmap / kmap we could simply reuse the virtual addresses we get back from dma_alloc_coherent(), but for faulting one would want something like dma_coherent_insert_pfn() (if it doesn't exist already) after a proper disussion with Christoph Hellwig. Chri
Re: [PATCH v3 1/2] dt-bindings: display: imx: add binding for i.MX8MP HDMI PVI
Hi Lucas,
Thank you for the patch.
On Wed, Sep 20, 2023 at 07:10:08PM +0200, Lucas Stach wrote:
> Add binding for the i.MX8MP HDMI parallel video interface block.
>
> Signed-off-by: Lucas Stach
> ---
> .../display/imx/fsl,imx8mp-hdmi-pvi.yaml | 80 +++
> 1 file changed, 80 insertions(+)
> create mode 100644
> Documentation/devicetree/bindings/display/imx/fsl,imx8mp-hdmi-pvi.yaml
>
> diff --git
> a/Documentation/devicetree/bindings/display/imx/fsl,imx8mp-hdmi-pvi.yaml
> b/Documentation/devicetree/bindings/display/imx/fsl,imx8mp-hdmi-pvi.yaml
> new file mode 100644
> index ..12855bb3ed4c
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/display/imx/fsl,imx8mp-hdmi-pvi.yaml
> @@ -0,0 +1,80 @@
> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/display/imx/fsl,imx8mp-hdmi-pvi.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: Freescale i.MX8MP HDMI Parallel Video Interface
> +
> +maintainers:
> + - Lucas Stach
> +
> +description: |
> + The HDMI parallel video interface is a timing and sync generator block in
> the
> + i.MX8MP SoC, that sits between the video source and the HDMI TX controller.
> +
> +properties:
> + compatible:
> +const: fsl,imx8mp-hdmi-pvi
> +
> + reg:
> +maxItems: 1
> +
> + power-domains:
> +maxItems: 1
> +
> + ports:
> +$ref: /schemas/graph.yaml#/properties/ports
> +
> +properties:
> + port@0:
> +$ref: /schemas/graph.yaml#/properties/port
> +description: Input from the LCDIF controller.
> +
> + port@1:
> +$ref: /schemas/graph.yaml#/properties/port
> +description: Output to the HDMI TX controller.
> +
> +required:
> + - port@0
> + - port@1
> +
> +required:
> + - compatible
> + - reg
> + - interrupts
The interrupts property is missing above. With this fixed,
Reviewed-by: Laurent Pinchart
> + - power-domains
> + - ports
> +
> +additionalProperties: false
> +
> +examples:
> + - |
> +#include
> +#include
> +
> +display-bridge@32fc4000 {
> +compatible = "fsl,imx8mp-hdmi-pvi";
> +reg = <0x32fc4000 0x40>;
> +interrupts = <12 IRQ_TYPE_LEVEL_HIGH>;
> +power-domains = <&hdmi_blk_ctrl IMX8MP_HDMIBLK_PD_PVI>;
> +
> +ports {
> +#address-cells = <1>;
> +#size-cells = <0>;
> +
> +port@0 {
> +reg = <0>;
> +pvi_from_lcdif3: endpoint {
> +remote-endpoint = <&lcdif3_to_pvi>;
> +};
> +};
> +
> +port@1 {
> +reg = <1>;
> +pvi_to_hdmi_tx: endpoint {
> +remote-endpoint = <&hdmi_tx_from_pvi>;
> +};
> +};
> +};
> +};
--
Regards,
Laurent Pinchart
Re: [RFT PATCH 01/15] drm/armada: Call drm_atomic_helper_shutdown() at shutdown time
On Wed, Sep 20, 2023 at 11:03:32AM -0700, Doug Anderson wrote: > Maxime, > > On Wed, Sep 13, 2023 at 8:34 AM Doug Anderson wrote: > > > > Hi, > > > > On Tue, Sep 5, 2023 at 7:23 AM Doug Anderson wrote: > > > > > > Hi, > > > > > > On Sun, Sep 3, 2023 at 8:53 AM Russell King (Oracle) > > > wrote: > > > > > > > > On Fri, Sep 01, 2023 at 04:41:12PM -0700, Douglas Anderson wrote: > > > > > Based on grepping through the source code this driver appears to be > > > > > missing a call to drm_atomic_helper_shutdown() at system shutdown > > > > > time. Among other things, this means that if a panel is in use that it > > > > > won't be cleanly powered off at system shutdown time. > > > > > > > > > > The fact that we should call drm_atomic_helper_shutdown() in the case > > > > > of OS shutdown/restart comes straight out of the kernel doc "driver > > > > > instance overview" in drm_drv.c. > > > > > > > > > > This driver was fairly easy to update. The drm_device is stored in the > > > > > drvdata so we just have to make sure the drvdata is NULL whenever the > > > > > device is not bound. > > > > > > > > ... and there I think you have a misunderstanding of the driver model. > > > > Please have a look at device_unbind_cleanup() which will be called if > > > > probe fails, or when the device is removed (in other words, when it is > > > > not bound to a driver.) > > > > > > ...and there I think you didn't read this patch closely enough and > > > perhaps that you have a misunderstanding of the component model. > > > Please have a look at the difference between armada_drm_unbind() and > > > armada_drm_remove() and also check which of those two functions is > > > being modified by my patch. Were this patch adding a call to > > > "dev_set_drvdata(dev, NULL)" in armada_drm_remove() then your NAK > > > would be justified. However, I am not aware of anything in the > > > component unbind path nor in the failure case of component bind that > > > would NULL the drvdata. > > > > > > Kindly look at the patch a second time with this in mind. > > > > Since I didn't see any further response, I'll assume that my > > explanation here has addressed your concerns. If not, I can re-post it > > without NULLing the "drvdata". While I still believe this is unsafe in > > some corner cases because of the component model used by this driver, > > at least it would get the shutdown call in. > > > > In any case, what's the process for landing patches to this driver? > > Running `./scripts/get_maintainer.pl --scm -f > > drivers/gpu/drm/armada/armada_drv.c` seems to indicate that this > > should go through the git tree: > > > > git git://git.armlinux.org.uk/~rmk/linux-arm.git drm-armada-devel > > > > ...but it doesn't appear that recent changes to this driver have gone > > that way. Should this land through drm-misc? > > Do you have any advice here? Should I land this through drm-misc-next, > put it on ice for a while, or resend without the calls to NULL our the > drvdata? Sorry, I haven't had a chance to look at it, but I think you're probably right, so I withdraw my objection. Please take it through drm-misc for the time being. Thanks. -- RMK's Patch system: https://www.armlinux.org.uk/developer/patches/ FTTP is here! 80Mbps down 10Mbps up. Decent connectivity at last!
Re: [PATCH] drm/ci: Uprev IGT to pull in fixes
Hi Rob, Thanks for the patch. On 20/09/2023 15:10, Rob Clark wrote: On Wed, Sep 20, 2023 at 11:06 AM Rob Clark wrote: From: Rob Clark There have been a few igt test fixes compared to the commit that we were currently using. Pull in a newer igt and update expectations. Signed-off-by: Rob Clark --- Could you send here the url of a pipeline run with this change? drivers/gpu/drm/ci/gitlab-ci.yml | 2 +- .../gpu/drm/ci/xfails/amdgpu-stoney-fails.txt | 4 ++-- drivers/gpu/drm/ci/xfails/i915-apl-fails.txt | 11 --- drivers/gpu/drm/ci/xfails/i915-cml-fails.txt | 2 +- drivers/gpu/drm/ci/xfails/i915-tgl-fails.txt | 1 - drivers/gpu/drm/ci/xfails/msm-sc7180-skips.txt | 18 +- .../drm/ci/xfails/rockchip-rk3288-fails.txt| 2 ++ 7 files changed, 7 insertions(+), 33 deletions(-) diff --git a/drivers/gpu/drm/ci/gitlab-ci.yml b/drivers/gpu/drm/ci/gitlab-ci.yml index 2c4df53f5dfe..3ecb5879e80f 100644 --- a/drivers/gpu/drm/ci/gitlab-ci.yml +++ b/drivers/gpu/drm/ci/gitlab-ci.yml @@ -5,7 +5,7 @@ variables: UPSTREAM_REPO: git://anongit.freedesktop.org/drm/drm TARGET_BRANCH: drm-next - IGT_VERSION: 471bfababd070e1dac0ebb87470ac4f2ae85e663 + IGT_VERSION: 2517e42d612e0c1ca096acf8b5f6177f7ef4bce7 DEQP_RUNNER_GIT_URL: https://gitlab.freedesktop.org/anholt/deqp-runner.git DEQP_RUNNER_GIT_TAG: v0.15.0 diff --git a/drivers/gpu/drm/ci/xfails/amdgpu-stoney-fails.txt b/drivers/gpu/drm/ci/xfails/amdgpu-stoney-fails.txt index bd9392536e7c..bab21930a0d4 100644 --- a/drivers/gpu/drm/ci/xfails/amdgpu-stoney-fails.txt +++ b/drivers/gpu/drm/ci/xfails/amdgpu-stoney-fails.txt @@ -1,7 +1,6 @@ kms_addfb_basic@bad-pitch-65536,Fail kms_addfb_basic@bo-too-small,Fail kms_async_flips@invalid-async-flip,Fail -kms_atomic@plane-immutable-zpos,Fail kms_atomic_transition@plane-toggle-modeset-transition,Fail kms_bw@linear-tiling-1-displays-2560x1440p,Fail kms_bw@linear-tiling-1-displays-3840x2160p,Fail @@ -11,9 +10,10 @@ kms_color@degamma,Fail kms_cursor_crc@cursor-size-change,Fail kms_cursor_crc@pipe-A-cursor-size-change,Fail kms_cursor_crc@pipe-B-cursor-size-change,Fail -kms_cursor_legacy@forked-move,Fail kms_hdr@bpc-switch,Fail kms_hdr@bpc-switch-dpms,Fail kms_plane_multiple@atomic-pipe-A-tiling-none,Fail kms_rmfb@close-fd,Fail kms_rotation_crc@primary-rotation-180,Fail +kms_flip@flip-vs-modeset-vs-hang,Fail +kms_flip@flip-vs-panning-vs-hang,Fail diff --git a/drivers/gpu/drm/ci/xfails/i915-apl-fails.txt b/drivers/gpu/drm/ci/xfails/i915-apl-fails.txt index 46397ce38d5a..2e3b7c5dac3c 100644 --- a/drivers/gpu/drm/ci/xfails/i915-apl-fails.txt +++ b/drivers/gpu/drm/ci/xfails/i915-apl-fails.txt @@ -8,13 +8,6 @@ kms_bw@linear-tiling-3-displays-3840x2160p,Fail kms_bw@linear-tiling-4-displays-1920x1080p,Fail kms_bw@linear-tiling-4-displays-2560x1440p,Fail kms_bw@linear-tiling-4-displays-3840x2160p,Fail -kms_color@ctm-0-25,Fail -kms_color@ctm-0-50,Fail -kms_color@ctm-0-75,Fail -kms_color@ctm-max,Fail -kms_color@ctm-negative,Fail -kms_color@ctm-red-to-blue,Fail -kms_color@ctm-signed,Fail kms_flip_scaled_crc@flip-32bpp-linear-to-64bpp-linear-downscaling,Fail kms_flip_scaled_crc@flip-32bpp-linear-to-64bpp-linear-upscaling,Fail kms_flip_scaled_crc@flip-32bpp-xtile-to-64bpp-xtile-downscaling,Fail @@ -38,8 +31,6 @@ kms_flip_scaled_crc@flip-64bpp-ytile-to-32bpp-ytile-upscaling,Fail kms_flip_scaled_crc@flip-64bpp-ytile-to-32bpp-ytilegen12rcccs-upscaling,Fail kms_flip_scaled_crc@flip-64bpp-ytile-to-32bpp-ytilercccs-downscaling,Fail kms_flip_scaled_crc@flip-64bpp-ytile-to-32bpp-ytilercccs-upscaling,Fail -kms_hdmi_inject@inject-4k,Timeout -kms_plane@plane-position-hole,Timeout kms_plane_alpha_blend@alpha-basic,Fail kms_plane_alpha_blend@alpha-opaque-fb,Fail kms_plane_alpha_blend@alpha-transparent-fb,Fail @@ -53,6 +44,4 @@ kms_plane_alpha_blend@pipe-B-constant-alpha-max,Fail kms_plane_alpha_blend@pipe-C-alpha-opaque-fb,Fail kms_plane_alpha_blend@pipe-C-alpha-transparent-fb,Fail kms_plane_alpha_blend@pipe-C-constant-alpha-max,Fail -kms_plane_multiple@tiling-y,Timeout -kms_pwrite_crc,Timeout kms_sysfs_edid_timing,Fail diff --git a/drivers/gpu/drm/ci/xfails/i915-cml-fails.txt b/drivers/gpu/drm/ci/xfails/i915-cml-fails.txt index 6139b410e767..13c0a25fc627 100644 --- a/drivers/gpu/drm/ci/xfails/i915-cml-fails.txt +++ b/drivers/gpu/drm/ci/xfails/i915-cml-fails.txt @@ -1,4 +1,3 @@ -kms_color@ctm-0-25,Fail kms_flip_scaled_crc@flip-32bpp-linear-to-64bpp-linear-downscaling,Fail kms_flip_scaled_crc@flip-32bpp-linear-to-64bpp-linear-upscaling,Fail kms_flip_scaled_crc@flip-32bpp-xtile-to-64bpp-xtile-downscaling,Fail @@ -16,3 +15,4 @@ kms_plane_alpha_blend@alpha-basic,Fail kms_plane_alpha_blend@alpha-opaque-fb,Fail kms_plane_alpha_blend@alpha-transparent-fb,Fail kms_plane_alpha_blend@constant-alpha-max,Fail +kms_async_flips@crc,Fail diff --git a/drivers/gpu/drm/ci/xfails/i915-tgl-fails.txt b/drivers/gpu/drm/ci/xfails/
Re: [PATCH 00/10] Add mediate-drm secure flow for SVP
On Tue, Sep 19, 2023 at 10:26 PM CK Hu (胡俊光) wrote: > > Hi, Jason: > > On Tue, 2023-09-19 at 11:03 +0800, Jason-JH.Lin wrote: > > The patch series provides drm driver support for enabling secure > > video > > path (SVP) playback on MediaiTek hardware in the Linux kernel. > > > > Memory Definitions: > > secure memory - Memory allocated in the TEE (Trusted Execution > > Environment) which is inaccessible in the REE (Rich Execution > > Environment, i.e. linux kernel/userspace). > > secure handle - Integer value which acts as reference to 'secure > > memory'. Used in communication between TEE and REE to reference > > 'secure memory'. > > secure buffer - 'secure memory' that is used to store decrypted, > > compressed video or for other general purposes in the TEE. > > secure surface - 'secure memory' that is used to store graphic > > buffers. > > > > Memory Usage in SVP: > > The overall flow of SVP starts with encrypted video coming in from an > > outside source into the REE. The REE will then allocate a 'secure > > buffer' and send the corresponding 'secure handle' along with the > > encrypted, compressed video data to the TEE. The TEE will then > > decrypt > > the video and store the result in the 'secure buffer'. The REE will > > then allocate a 'secure surface'. The REE will pass the 'secure > > handles' for both the 'secure buffer' and 'secure surface' into the > > TEE for video decoding. The video decoder HW will then decode the > > contents of the 'secure buffer' and place the result in the 'secure > > surface'. The REE will then attach the 'secure surface' to the > > overlay > > plane for rendering of the video. > > > > Everything relating to ensuring security of the actual contents of > > the > > 'secure buffer' and 'secure surface' is out of scope for the REE and > > is the responsibility of the TEE. > > > > DRM driver handles allocation of gem objects that are backed by a > > 'secure > > surface' and for displaying a 'secure surface' on the overlay plane. > > This introduces a new flag for object creation called > > DRM_MTK_GEM_CREATE_ENCRYPTED which indicates it should be a 'secure > > surface'. All changes here are in MediaTek specific code. > > How do you define SVP? Is there standard requirement we could refer to? > If the secure video buffer is read by display hardware and output to > HDMI without any protection and user could capture HDMI signal, is this > secure? SVP (Secure Video Path) is essentially the video being completed isolated from the kernel/userspace. The specific requirements for it vary between implementations. Regarding HDMI/HDCP output; it's the responsibility of the TEE to enforce that. Nothing on the kernel/userspace side needs to be concerned about enforcing HDCP. The only thing userspace is involved in there is actually turning on HDCP via the kernel drivers; and then the TEE ensures that it is active if the policy for the encrypted content requires it. > > Regards, > CK > > > > > --- > > Based on 2 series: > > [1] Add CMDQ secure driver for SVP > > - > > https://urldefense.com/v3/__https://patchwork.kernel.org/project/linux-mediatek/list/?series=785332__;!!CTRNKA9wMg0ARbw!mPocbQwZ4-25DmidvAgd9K5eXjNEhSyIKpvvYHPpdrq2PgS-hkYyHohzDvoJydD45UZp5JvY9DuDVFj1ltVnhGY$ > > > > > > [2] dma-buf: heaps: Add MediaTek secure heap > > - > > https://urldefense.com/v3/__https://patchwork.kernel.org/project/linux-mediatek/list/?series=782776__;!!CTRNKA9wMg0ARbw!mPocbQwZ4-25DmidvAgd9K5eXjNEhSyIKpvvYHPpdrq2PgS-hkYyHohzDvoJydD45UZp5JvY9DuDVFj10sD4kHE$ > > > > --- > > > > CK Hu (1): > > drm/mediatek: Add interface to allocate MediaTek GEM buffer. > > > > Jason-JH.Lin (9): > > drm/mediatek/uapi: Add DRM_MTK_GEM_CREATED_ENCRYPTTED flag > > drm/mediatek: Add secure buffer control flow to mtk_drm_gem > > drm/mediatek: Add secure identify flag and funcution to > > mtk_drm_plane > > drm/mediatek: Add mtk_ddp_sec_write to config secure buffer info > > drm/mediatek: Add get_sec_port interface to mtk_ddp_comp > > drm/mediatek: Add secure layer config support for ovl > > drm/mediatek: Add secure layer config support for ovl_adaptor > > drm/mediatek: Add secure flow support to mediatek-drm > > arm64: dts: mt8195-cherry: Add secure mbox settings for vdosys > > > > .../boot/dts/mediatek/mt8195-cherry.dtsi | 10 + > > drivers/gpu/drm/mediatek/mtk_disp_drv.h | 3 + > > drivers/gpu/drm/mediatek/mtk_disp_ovl.c | 31 +- > > .../gpu/drm/mediatek/mtk_disp_ovl_adaptor.c | 15 + > > drivers/gpu/drm/mediatek/mtk_drm_crtc.c | 271 > > +- > > drivers/gpu/drm/mediatek/mtk_drm_crtc.h | 1 + > > drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c | 14 + > > drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.h | 13 + > > drivers/gpu/drm/mediatek/mtk_drm_drv.c| 16 +- > > drivers/gpu/drm/mediatek/mtk_drm_gem.c| 121 > > drivers/gpu/drm/mediatek/mtk_drm_gem.h| 16 ++ > > drivers/gpu/drm/mediatek/mtk_drm_plane.c | 7 +
Re: Decrypting tt maps in ttm
On Wed, 2023-09-20 at 19:17 +0200, Thomas Hellström wrote: > !! External Email > > Hi, Zack > > On 9/20/23 18:39, Zack Rusin wrote: > > On Wed, 2023-09-20 at 12:48 +0200, Christian König wrote: > > > !! External Email > > > > > > Am 20.09.23 um 09:36 schrieb Thomas Hellström: > > > > Hi, Zack, > > > > > > > > On 9/20/23 05:43, Zack Rusin wrote: > > > > > On Tue, 2023-09-19 at 09:47 +0200, Christian König wrote: > > > > > > !! External Email > > > > > > > > > > > > Am 19.09.23 um 08:56 schrieb Thomas Hellström: > > > > > > > On 9/19/23 07:39, Christian König wrote: > > > > > > > > Am 19.09.23 um 03:26 schrieb Zack Rusin: > > > > > > > > > On Mon, 2023-09-18 at 16:21 -0400, Alex Deucher wrote: > > > > > > > > > > !! External Email > > > > > > > > > > > > > > > > > > > > On Mon, Sep 18, 2023 at 3:06 PM Thomas Hellström > > > > > > > > > > wrote: > > > > > > > > > > > On 9/18/23 17:52, Zack Rusin wrote: > > > > > > > > > > > > On Mon, 2023-09-18 at 17:13 +0200, Thomas Hellström > > > > > > > > > > > > wrote: > > > > > > > > > > > > > Hi, > > > > > > > > > > > > > > > > > > > > > > > > > > On 9/18/23 16:56, Thomas Hellström wrote: > > > > > > > > > > > > > > Hi Zack, Christian > > > > > > > > > > > > > > > > > > > > > > > > > > > > On 9/18/23 13:36, Christian König wrote: > > > > > > > > > > > > > > > Hi Zack, > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > adding Thomas and Daniel. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > I briefly remember that I talked with Thomas and > > > > > > > > > > > > > > > some > > > > > > > > > > > > > > > other > > > > > > > > > > > > > > > people > > > > > > > > > > > > > > > about that quite a while ago as well, but I don't > > > > > > > > > > > > > > > fully > > > > > > > > > > > > > > > remember the > > > > > > > > > > > > > > > outcome. > > > > > > > > > > > > > > Found one old thread, but didn't read it: > > > > > > > > > > > > > > > > > > > > > > > > > > > > https://lists.freedesktop.org/archives/dri-devel/2019-September/234100.html > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > /Thomas > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Ugh. Now starting to read that thread I have a vague > > > > > > > > > > > > > recollection it all > > > > > > > > > > > > > ended with not supporting mapping any device pages > > > > > > > > > > > > > whatsoever > > > > > > > > > > > > > when SEV > > > > > > > > > > > > > was enabled, but rather resorting to llvmpipe and > > > > > > > > > > > > > VM-local > > > > > > > > > > > > > bos. > > > > > > > > > > > > Hi, Thomas. > > > > > > > > > > > > > > > > > > > > > > > > Thanks for finding this! I'd (of course) like to solve > > > > > > > > > > > > it > > > > > > > > > > > > properly and get > > > > > > > > > > > > vmwgfx > > > > > > > > > > > > running with 3d support with SEV-ES active instead of > > > > > > > > > > > > essentially > > > > > > > > > > > > disabling > > > > > > > > > > > > the > > > > > > > > > > > > driver when SEV-ES is active. > > > > > > > > > > > > > > > > > > > > > > > > I think there are two separate discussions there, the > > > > > > > > > > > > non-controversial one > > > > > > > > > > > > and the > > > > > > > > > > > > controversial one: > > > > > > > > > > > > 1) The non-controversial: is there a case where drivers > > > > > > > > > > > > would > > > > > > > > > > > > want encrypted > > > > > > > > > > > > memory > > > > > > > > > > > > for TT pages but not for io mem mappings? Because if not > > > > > > > > > > > > then as > > > > > > > > > > > > Christian > > > > > > > > > > > > pointed > > > > > > > > > > > > out we could just add pgprot_decrypted to ttm_io_prot > > > > > > > > > > > > and be > > > > > > > > > > > > essentially done. > > > > > > > > > > > > The > > > > > > > > > > > > current method of decrypting io mem but leaving sys mem > > > > > > > > > > > > mappings > > > > > > > > > > > > encrypted is > > > > > > > > > > > > a bit > > > > > > > > > > > > weird anyway. > > > > > > > > > > > > > > > > > > > > > > > > If the answer to that question is "yes, some driver does > > > > > > > > > > > > want > > > > > > > > > > > > the > > > > > > > > > > > > TT mappings > > > > > > > > > > > > to be > > > > > > > > > > > > encrypted" then your "[PATCH v2 3/4] drm/ttm, > > > > > > > > > > > > drm/vmwgfx: > > > > > > > > > > > > Correctly support > > > > > > > > > > > > support > > > > > > > > > > > > AMD memory encryption" solves that. I think getting one > > > > > > > > > > > > of > > > > > > > > > > > > those > > > > > > > > > > > > two in makes > > > > > > > > > > > > sense > > > > > > > > > > > > regardless of everything else, agreed? > > > > > > > > > > > Well, there is more to it I think. > > > > > > > > > > > > > > > > > > > > > > IIRC, the AMD SME encryption mode has a way for a device > > > > > > > > > > > to > > > > > > > > > > > have the > >
Re: [PATCH] drm/ci: Uprev IGT to pull in fixes
On Wed, Sep 20, 2023 at 11:06 AM Rob Clark wrote: > > From: Rob Clark > > There have been a few igt test fixes compared to the commit that we were > currently using. Pull in a newer igt and update expectations. > > Signed-off-by: Rob Clark > --- > drivers/gpu/drm/ci/gitlab-ci.yml | 2 +- > .../gpu/drm/ci/xfails/amdgpu-stoney-fails.txt | 4 ++-- > drivers/gpu/drm/ci/xfails/i915-apl-fails.txt | 11 --- > drivers/gpu/drm/ci/xfails/i915-cml-fails.txt | 2 +- > drivers/gpu/drm/ci/xfails/i915-tgl-fails.txt | 1 - > drivers/gpu/drm/ci/xfails/msm-sc7180-skips.txt | 18 +- > .../drm/ci/xfails/rockchip-rk3288-fails.txt| 2 ++ > 7 files changed, 7 insertions(+), 33 deletions(-) > > diff --git a/drivers/gpu/drm/ci/gitlab-ci.yml > b/drivers/gpu/drm/ci/gitlab-ci.yml > index 2c4df53f5dfe..3ecb5879e80f 100644 > --- a/drivers/gpu/drm/ci/gitlab-ci.yml > +++ b/drivers/gpu/drm/ci/gitlab-ci.yml > @@ -5,7 +5,7 @@ variables: >UPSTREAM_REPO: git://anongit.freedesktop.org/drm/drm >TARGET_BRANCH: drm-next > > - IGT_VERSION: 471bfababd070e1dac0ebb87470ac4f2ae85e663 > + IGT_VERSION: 2517e42d612e0c1ca096acf8b5f6177f7ef4bce7 > >DEQP_RUNNER_GIT_URL: https://gitlab.freedesktop.org/anholt/deqp-runner.git >DEQP_RUNNER_GIT_TAG: v0.15.0 > diff --git a/drivers/gpu/drm/ci/xfails/amdgpu-stoney-fails.txt > b/drivers/gpu/drm/ci/xfails/amdgpu-stoney-fails.txt > index bd9392536e7c..bab21930a0d4 100644 > --- a/drivers/gpu/drm/ci/xfails/amdgpu-stoney-fails.txt > +++ b/drivers/gpu/drm/ci/xfails/amdgpu-stoney-fails.txt > @@ -1,7 +1,6 @@ > kms_addfb_basic@bad-pitch-65536,Fail > kms_addfb_basic@bo-too-small,Fail > kms_async_flips@invalid-async-flip,Fail > -kms_atomic@plane-immutable-zpos,Fail > kms_atomic_transition@plane-toggle-modeset-transition,Fail > kms_bw@linear-tiling-1-displays-2560x1440p,Fail > kms_bw@linear-tiling-1-displays-3840x2160p,Fail > @@ -11,9 +10,10 @@ kms_color@degamma,Fail > kms_cursor_crc@cursor-size-change,Fail > kms_cursor_crc@pipe-A-cursor-size-change,Fail > kms_cursor_crc@pipe-B-cursor-size-change,Fail > -kms_cursor_legacy@forked-move,Fail > kms_hdr@bpc-switch,Fail > kms_hdr@bpc-switch-dpms,Fail > kms_plane_multiple@atomic-pipe-A-tiling-none,Fail > kms_rmfb@close-fd,Fail > kms_rotation_crc@primary-rotation-180,Fail > +kms_flip@flip-vs-modeset-vs-hang,Fail > +kms_flip@flip-vs-panning-vs-hang,Fail > diff --git a/drivers/gpu/drm/ci/xfails/i915-apl-fails.txt > b/drivers/gpu/drm/ci/xfails/i915-apl-fails.txt > index 46397ce38d5a..2e3b7c5dac3c 100644 > --- a/drivers/gpu/drm/ci/xfails/i915-apl-fails.txt > +++ b/drivers/gpu/drm/ci/xfails/i915-apl-fails.txt > @@ -8,13 +8,6 @@ kms_bw@linear-tiling-3-displays-3840x2160p,Fail > kms_bw@linear-tiling-4-displays-1920x1080p,Fail > kms_bw@linear-tiling-4-displays-2560x1440p,Fail > kms_bw@linear-tiling-4-displays-3840x2160p,Fail > -kms_color@ctm-0-25,Fail > -kms_color@ctm-0-50,Fail > -kms_color@ctm-0-75,Fail > -kms_color@ctm-max,Fail > -kms_color@ctm-negative,Fail > -kms_color@ctm-red-to-blue,Fail > -kms_color@ctm-signed,Fail > kms_flip_scaled_crc@flip-32bpp-linear-to-64bpp-linear-downscaling,Fail > kms_flip_scaled_crc@flip-32bpp-linear-to-64bpp-linear-upscaling,Fail > kms_flip_scaled_crc@flip-32bpp-xtile-to-64bpp-xtile-downscaling,Fail > @@ -38,8 +31,6 @@ > kms_flip_scaled_crc@flip-64bpp-ytile-to-32bpp-ytile-upscaling,Fail > kms_flip_scaled_crc@flip-64bpp-ytile-to-32bpp-ytilegen12rcccs-upscaling,Fail > kms_flip_scaled_crc@flip-64bpp-ytile-to-32bpp-ytilercccs-downscaling,Fail > kms_flip_scaled_crc@flip-64bpp-ytile-to-32bpp-ytilercccs-upscaling,Fail > -kms_hdmi_inject@inject-4k,Timeout > -kms_plane@plane-position-hole,Timeout > kms_plane_alpha_blend@alpha-basic,Fail > kms_plane_alpha_blend@alpha-opaque-fb,Fail > kms_plane_alpha_blend@alpha-transparent-fb,Fail > @@ -53,6 +44,4 @@ kms_plane_alpha_blend@pipe-B-constant-alpha-max,Fail > kms_plane_alpha_blend@pipe-C-alpha-opaque-fb,Fail > kms_plane_alpha_blend@pipe-C-alpha-transparent-fb,Fail > kms_plane_alpha_blend@pipe-C-constant-alpha-max,Fail > -kms_plane_multiple@tiling-y,Timeout > -kms_pwrite_crc,Timeout > kms_sysfs_edid_timing,Fail > diff --git a/drivers/gpu/drm/ci/xfails/i915-cml-fails.txt > b/drivers/gpu/drm/ci/xfails/i915-cml-fails.txt > index 6139b410e767..13c0a25fc627 100644 > --- a/drivers/gpu/drm/ci/xfails/i915-cml-fails.txt > +++ b/drivers/gpu/drm/ci/xfails/i915-cml-fails.txt > @@ -1,4 +1,3 @@ > -kms_color@ctm-0-25,Fail > kms_flip_scaled_crc@flip-32bpp-linear-to-64bpp-linear-downscaling,Fail > kms_flip_scaled_crc@flip-32bpp-linear-to-64bpp-linear-upscaling,Fail > kms_flip_scaled_crc@flip-32bpp-xtile-to-64bpp-xtile-downscaling,Fail > @@ -16,3 +15,4 @@ kms_plane_alpha_blend@alpha-basic,Fail > kms_plane_alpha_blend@alpha-opaque-fb,Fail > kms_plane_alpha_blend@alpha-transparent-fb,Fail > kms_plane_alpha_blend@constant-alpha-max,Fail > +kms_async_flips@crc,Fail > diff --git a/drivers/gpu/drm/ci/xfails/i915-tgl-fails.txt > b/dr
[PATCH] drm/ci: Uprev IGT to pull in fixes
From: Rob Clark There have been a few igt test fixes compared to the commit that we were currently using. Pull in a newer igt and update expectations. Signed-off-by: Rob Clark --- drivers/gpu/drm/ci/gitlab-ci.yml | 2 +- .../gpu/drm/ci/xfails/amdgpu-stoney-fails.txt | 4 ++-- drivers/gpu/drm/ci/xfails/i915-apl-fails.txt | 11 --- drivers/gpu/drm/ci/xfails/i915-cml-fails.txt | 2 +- drivers/gpu/drm/ci/xfails/i915-tgl-fails.txt | 1 - drivers/gpu/drm/ci/xfails/msm-sc7180-skips.txt | 18 +- .../drm/ci/xfails/rockchip-rk3288-fails.txt| 2 ++ 7 files changed, 7 insertions(+), 33 deletions(-) diff --git a/drivers/gpu/drm/ci/gitlab-ci.yml b/drivers/gpu/drm/ci/gitlab-ci.yml index 2c4df53f5dfe..3ecb5879e80f 100644 --- a/drivers/gpu/drm/ci/gitlab-ci.yml +++ b/drivers/gpu/drm/ci/gitlab-ci.yml @@ -5,7 +5,7 @@ variables: UPSTREAM_REPO: git://anongit.freedesktop.org/drm/drm TARGET_BRANCH: drm-next - IGT_VERSION: 471bfababd070e1dac0ebb87470ac4f2ae85e663 + IGT_VERSION: 2517e42d612e0c1ca096acf8b5f6177f7ef4bce7 DEQP_RUNNER_GIT_URL: https://gitlab.freedesktop.org/anholt/deqp-runner.git DEQP_RUNNER_GIT_TAG: v0.15.0 diff --git a/drivers/gpu/drm/ci/xfails/amdgpu-stoney-fails.txt b/drivers/gpu/drm/ci/xfails/amdgpu-stoney-fails.txt index bd9392536e7c..bab21930a0d4 100644 --- a/drivers/gpu/drm/ci/xfails/amdgpu-stoney-fails.txt +++ b/drivers/gpu/drm/ci/xfails/amdgpu-stoney-fails.txt @@ -1,7 +1,6 @@ kms_addfb_basic@bad-pitch-65536,Fail kms_addfb_basic@bo-too-small,Fail kms_async_flips@invalid-async-flip,Fail -kms_atomic@plane-immutable-zpos,Fail kms_atomic_transition@plane-toggle-modeset-transition,Fail kms_bw@linear-tiling-1-displays-2560x1440p,Fail kms_bw@linear-tiling-1-displays-3840x2160p,Fail @@ -11,9 +10,10 @@ kms_color@degamma,Fail kms_cursor_crc@cursor-size-change,Fail kms_cursor_crc@pipe-A-cursor-size-change,Fail kms_cursor_crc@pipe-B-cursor-size-change,Fail -kms_cursor_legacy@forked-move,Fail kms_hdr@bpc-switch,Fail kms_hdr@bpc-switch-dpms,Fail kms_plane_multiple@atomic-pipe-A-tiling-none,Fail kms_rmfb@close-fd,Fail kms_rotation_crc@primary-rotation-180,Fail +kms_flip@flip-vs-modeset-vs-hang,Fail +kms_flip@flip-vs-panning-vs-hang,Fail diff --git a/drivers/gpu/drm/ci/xfails/i915-apl-fails.txt b/drivers/gpu/drm/ci/xfails/i915-apl-fails.txt index 46397ce38d5a..2e3b7c5dac3c 100644 --- a/drivers/gpu/drm/ci/xfails/i915-apl-fails.txt +++ b/drivers/gpu/drm/ci/xfails/i915-apl-fails.txt @@ -8,13 +8,6 @@ kms_bw@linear-tiling-3-displays-3840x2160p,Fail kms_bw@linear-tiling-4-displays-1920x1080p,Fail kms_bw@linear-tiling-4-displays-2560x1440p,Fail kms_bw@linear-tiling-4-displays-3840x2160p,Fail -kms_color@ctm-0-25,Fail -kms_color@ctm-0-50,Fail -kms_color@ctm-0-75,Fail -kms_color@ctm-max,Fail -kms_color@ctm-negative,Fail -kms_color@ctm-red-to-blue,Fail -kms_color@ctm-signed,Fail kms_flip_scaled_crc@flip-32bpp-linear-to-64bpp-linear-downscaling,Fail kms_flip_scaled_crc@flip-32bpp-linear-to-64bpp-linear-upscaling,Fail kms_flip_scaled_crc@flip-32bpp-xtile-to-64bpp-xtile-downscaling,Fail @@ -38,8 +31,6 @@ kms_flip_scaled_crc@flip-64bpp-ytile-to-32bpp-ytile-upscaling,Fail kms_flip_scaled_crc@flip-64bpp-ytile-to-32bpp-ytilegen12rcccs-upscaling,Fail kms_flip_scaled_crc@flip-64bpp-ytile-to-32bpp-ytilercccs-downscaling,Fail kms_flip_scaled_crc@flip-64bpp-ytile-to-32bpp-ytilercccs-upscaling,Fail -kms_hdmi_inject@inject-4k,Timeout -kms_plane@plane-position-hole,Timeout kms_plane_alpha_blend@alpha-basic,Fail kms_plane_alpha_blend@alpha-opaque-fb,Fail kms_plane_alpha_blend@alpha-transparent-fb,Fail @@ -53,6 +44,4 @@ kms_plane_alpha_blend@pipe-B-constant-alpha-max,Fail kms_plane_alpha_blend@pipe-C-alpha-opaque-fb,Fail kms_plane_alpha_blend@pipe-C-alpha-transparent-fb,Fail kms_plane_alpha_blend@pipe-C-constant-alpha-max,Fail -kms_plane_multiple@tiling-y,Timeout -kms_pwrite_crc,Timeout kms_sysfs_edid_timing,Fail diff --git a/drivers/gpu/drm/ci/xfails/i915-cml-fails.txt b/drivers/gpu/drm/ci/xfails/i915-cml-fails.txt index 6139b410e767..13c0a25fc627 100644 --- a/drivers/gpu/drm/ci/xfails/i915-cml-fails.txt +++ b/drivers/gpu/drm/ci/xfails/i915-cml-fails.txt @@ -1,4 +1,3 @@ -kms_color@ctm-0-25,Fail kms_flip_scaled_crc@flip-32bpp-linear-to-64bpp-linear-downscaling,Fail kms_flip_scaled_crc@flip-32bpp-linear-to-64bpp-linear-upscaling,Fail kms_flip_scaled_crc@flip-32bpp-xtile-to-64bpp-xtile-downscaling,Fail @@ -16,3 +15,4 @@ kms_plane_alpha_blend@alpha-basic,Fail kms_plane_alpha_blend@alpha-opaque-fb,Fail kms_plane_alpha_blend@alpha-transparent-fb,Fail kms_plane_alpha_blend@constant-alpha-max,Fail +kms_async_flips@crc,Fail diff --git a/drivers/gpu/drm/ci/xfails/i915-tgl-fails.txt b/drivers/gpu/drm/ci/xfails/i915-tgl-fails.txt index a6da5544e198..27bfca1c6f2c 100644 --- a/drivers/gpu/drm/ci/xfails/i915-tgl-fails.txt +++ b/drivers/gpu/drm/ci/xfails/i915-tgl-fails.txt @@ -8,7 +8,6 @@ kms_bw@linear-tiling-4-displays-3840x2160p,Fail kms_bw@linear
Re: [RFT PATCH 01/15] drm/armada: Call drm_atomic_helper_shutdown() at shutdown time
Maxime, On Wed, Sep 13, 2023 at 8:34 AM Doug Anderson wrote: > > Hi, > > On Tue, Sep 5, 2023 at 7:23 AM Doug Anderson wrote: > > > > Hi, > > > > On Sun, Sep 3, 2023 at 8:53 AM Russell King (Oracle) > > wrote: > > > > > > On Fri, Sep 01, 2023 at 04:41:12PM -0700, Douglas Anderson wrote: > > > > Based on grepping through the source code this driver appears to be > > > > missing a call to drm_atomic_helper_shutdown() at system shutdown > > > > time. Among other things, this means that if a panel is in use that it > > > > won't be cleanly powered off at system shutdown time. > > > > > > > > The fact that we should call drm_atomic_helper_shutdown() in the case > > > > of OS shutdown/restart comes straight out of the kernel doc "driver > > > > instance overview" in drm_drv.c. > > > > > > > > This driver was fairly easy to update. The drm_device is stored in the > > > > drvdata so we just have to make sure the drvdata is NULL whenever the > > > > device is not bound. > > > > > > ... and there I think you have a misunderstanding of the driver model. > > > Please have a look at device_unbind_cleanup() which will be called if > > > probe fails, or when the device is removed (in other words, when it is > > > not bound to a driver.) > > > > ...and there I think you didn't read this patch closely enough and > > perhaps that you have a misunderstanding of the component model. > > Please have a look at the difference between armada_drm_unbind() and > > armada_drm_remove() and also check which of those two functions is > > being modified by my patch. Were this patch adding a call to > > "dev_set_drvdata(dev, NULL)" in armada_drm_remove() then your NAK > > would be justified. However, I am not aware of anything in the > > component unbind path nor in the failure case of component bind that > > would NULL the drvdata. > > > > Kindly look at the patch a second time with this in mind. > > Since I didn't see any further response, I'll assume that my > explanation here has addressed your concerns. If not, I can re-post it > without NULLing the "drvdata". While I still believe this is unsafe in > some corner cases because of the component model used by this driver, > at least it would get the shutdown call in. > > In any case, what's the process for landing patches to this driver? > Running `./scripts/get_maintainer.pl --scm -f > drivers/gpu/drm/armada/armada_drv.c` seems to indicate that this > should go through the git tree: > > git git://git.armlinux.org.uk/~rmk/linux-arm.git drm-armada-devel > > ...but it doesn't appear that recent changes to this driver have gone > that way. Should this land through drm-misc? Do you have any advice here? Should I land this through drm-misc-next, put it on ice for a while, or resend without the calls to NULL our the drvdata? Thanks! -Doug
Re: [PATCH v6 7/7] drm/vkms Add hotplug support via configfs to VKMS.
Hello!
Thanks for the patch.
On 29/08/2023 02:30, Brandon Pollack wrote:
This change adds the ability to read or write a "1" or a "0" to the
newly added "connected" attribute of a connector in the vkms entry in
configfs.
A write will trigger a call to drm_kms_helper_hotplug_event, causing a
hotplug uevent.
With this we can write virtualized multidisplay tests that involve
hotplugging displays (eg recompositing windows when a monitor is turned
off).
Are these tests going to be added in igt?
I was just wondering if it requires any special thing for drm ci:
https://lists.freedesktop.org/archives/dri-devel/2023-September/423719.html
(btw, it would be awesome of you could test your changes with drm ci :)
Regards,
Helen
Signed-off-by: Brandon Pollack
---
Documentation/gpu/vkms.rst | 2 +-
drivers/gpu/drm/vkms/vkms_configfs.c | 68 ++--
drivers/gpu/drm/vkms/vkms_drv.h | 11 +
drivers/gpu/drm/vkms/vkms_output.c | 47 ++-
4 files changed, 123 insertions(+), 5 deletions(-)
diff --git a/Documentation/gpu/vkms.rst b/Documentation/gpu/vkms.rst
index c3875bf66dba..7f715097539c 100644
--- a/Documentation/gpu/vkms.rst
+++ b/Documentation/gpu/vkms.rst
@@ -145,7 +145,7 @@ We want to be able to manipulate vkms instances without
having to reload the
module. Such configuration can be added as extensions to vkms's ConfigFS
support. Use-cases:
-- Hotplug/hotremove connectors on the fly (to be able to test DP MST handling
+- Hotremove connectors on the fly (to be able to test DP MST handling
of compositors).
- Change output configuration: Plug/unplug screens, change EDID, allow changing
diff --git a/drivers/gpu/drm/vkms/vkms_configfs.c
b/drivers/gpu/drm/vkms/vkms_configfs.c
index bc35dcc47585..d231e28101ae 100644
--- a/drivers/gpu/drm/vkms/vkms_configfs.c
+++ b/drivers/gpu/drm/vkms/vkms_configfs.c
@@ -1,5 +1,6 @@
// SPDX-License-Identifier: GPL-2.0+
+#include "drm/drm_probe_helper.h"
#include
#include
#include
@@ -40,6 +41,7 @@
* `-- vkms
* `-- test
* |-- connectors
+ *`-- connected
* |-- crtcs
* |-- encoders
* |-- planes
@@ -89,6 +91,14 @@
*
* echo 1 > /config/vkms/test/enabled
*
+ * By default no display is "connected" so to connect a connector you'll also
+ * have to write 1 to a connectors "connected" attribute::
+ *
+ * echo 1 > /config/vkms/test/connectors/connector/connected
+ *
+ * One can verify that this is worked using the `modetest` utility or the
+ * equivalent for your platform.
+ *
* When you're done with the virtual device, you can clean up the device like
* so::
*
@@ -236,7 +246,58 @@ static void add_possible_encoders(struct config_group
*parent,
/* Connector item, e.g. /config/vkms/device/connectors/ID */
+static ssize_t connector_connected_show(struct config_item *item, char *buf)
+{
+ struct vkms_config_connector *connector =
+ item_to_config_connector(item);
+ struct vkms_configfs *configfs = connector_item_to_configfs(item);
+ bool connected = false;
+
+ mutex_lock(&configfs->lock);
+ connected = connector->connected;
+ mutex_unlock(&configfs->lock);
+
+ return sprintf(buf, "%d\n", connected);
+}
+
+static ssize_t connector_connected_store(struct config_item *item,
+const char *buf, size_t len)
+{
+ struct vkms_config_connector *connector =
+ item_to_config_connector(item);
+ struct vkms_configfs *configfs = connector_item_to_configfs(item);
+ int val, ret;
+
+ ret = kstrtouint(buf, 10, &val);
+ if (ret)
+ return ret;
+
+ if (val != 1 && val != 0)
+ return -EINVAL;
+
+ mutex_lock(&configfs->lock);
+ connector->connected = val;
+ if (!connector->connector) {
+ pr_info("VKMS Device %s is not yet enabled, connector will be
enabled on start",
+ configfs->device_group.cg_item.ci_name);
+ }
+ mutex_unlock(&configfs->lock);
+
+ if (connector->connector)
+ drm_kms_helper_hotplug_event(connector->connector->dev);
+
+ return len;
+}
+
+CONFIGFS_ATTR(connector_, connected);
+
+static struct configfs_attribute *connector_attrs[] = {
+ &connector_attr_connected,
+ NULL,
+};
+
static struct config_item_type connector_type = {
+ .ct_attrs = connector_attrs,
.ct_owner = THIS_MODULE,
};
@@ -264,7 +325,7 @@ static ssize_t plane_type_show(struct config_item *item, char *buf)
plane_type = plane->type;
mutex_unlock(&configfs->lock);
- return sprintf(buf, "%u", plane_type);
+ return sprintf(buf, "%u\n", plane_type);
}
static ssize_t plane_type_store(struct config_item *item, const char *buf,
@@ -319,6 +380,7 @@ static struct config_group *connectors_group_make(struct
co
Re: [PATCH 5/5] drm: lcdif: force modeset when FB format changes
On 9/20/23 12:31, Lucas Stach wrote:
Force a modeset if the new FB has a different format than the
currently active one. While it might be possible to change between
compatible formats without a full modeset as the format control is
also supposed to be double buffered, the colorspace conversion is
not, so when the CSC changes we need a modeset.
For now just always force a modeset when the FB format changes to
properly reconfigure all parts of the device for the new format.
Signed-off-by: Lucas Stach
---
drivers/gpu/drm/mxsfb/lcdif_drv.c | 18 +-
drivers/gpu/drm/mxsfb/lcdif_kms.c | 26 --
2 files changed, 37 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/mxsfb/lcdif_drv.c
b/drivers/gpu/drm/mxsfb/lcdif_drv.c
index 18de2f17e249..b74f0cf1e240 100644
--- a/drivers/gpu/drm/mxsfb/lcdif_drv.c
+++ b/drivers/gpu/drm/mxsfb/lcdif_drv.c
@@ -30,9 +30,25 @@
#include "lcdif_drv.h"
#include "lcdif_regs.h"
+static int lcdif_atomic_check(struct drm_device *dev,
+ struct drm_atomic_state *state)
+{
+ int ret;
+
+ ret = drm_atomic_helper_check(dev, state);
+ if (ret)
+ return ret;
+
+ /*
+* Check modeset again in case crtc_state->mode_changed is
+* updated in plane's ->atomic_check callback.
+*/
+ return drm_atomic_helper_check_modeset(dev, state);
+}
+
static const struct drm_mode_config_funcs lcdif_mode_config_funcs = {
.fb_create = drm_gem_fb_create,
- .atomic_check = drm_atomic_helper_check,
+ .atomic_check = lcdif_atomic_check,
.atomic_commit = drm_atomic_helper_commit,
};
diff --git a/drivers/gpu/drm/mxsfb/lcdif_kms.c b/drivers/gpu/drm/mxsfb/lcdif_kms.c
index 3ebf55d06027..8167604bd3f8 100644
--- a/drivers/gpu/drm/mxsfb/lcdif_kms.c
+++ b/drivers/gpu/drm/mxsfb/lcdif_kms.c
@@ -647,18 +647,32 @@ static const struct drm_crtc_funcs lcdif_crtc_funcs = {
static int lcdif_plane_atomic_check(struct drm_plane *plane,
struct drm_atomic_state *state)
{
- struct drm_plane_state *plane_state =
drm_atomic_get_new_plane_state(state,
-
plane);
+ struct drm_plane_state *new_state =
drm_atomic_get_new_plane_state(state,
+
plane);
+ struct drm_plane_state *old_state =
drm_atomic_get_old_plane_state(state,
+
plane);
struct lcdif_drm_private *lcdif = to_lcdif_drm_private(plane->dev);
struct drm_crtc_state *crtc_state;
+ int ret;
+
+ /* always okay to disable the plane */
+ if (!new_state->fb)
+ return 0;
crtc_state = drm_atomic_get_new_crtc_state(state,
&lcdif->crtc);
- return drm_atomic_helper_check_plane_state(plane_state, crtc_state,
- DRM_PLANE_NO_SCALING,
- DRM_PLANE_NO_SCALING,
- false, true);
+ ret = drm_atomic_helper_check_plane_state(new_state, crtc_state,
+ DRM_PLANE_NO_SCALING,
+ DRM_PLANE_NO_SCALING,
+ false, true);
+ if (ret)
+ return ret;
+
+ if (old_state->fb && new_state->fb->format != old_state->fb->format)
+ crtc_state->mode_changed = true;
+
+ return 0;
}
static void lcdif_plane_primary_atomic_update(struct drm_plane *plane,
Reviewed-by: Marek Vasut
Re: [PATCH 3/5] drm: lcdif: remove superfluous setup of framebuffer DMA address
On 9/20/23 12:31, Lucas Stach wrote:
Now that the plane state is fully programmed into the hardware before
the scanout is started there is no need to program the plane framebuffer
DMA address from the CRTC atomic_enable anymore.
Signed-off-by: Lucas Stach
---
drivers/gpu/drm/mxsfb/lcdif_kms.c | 10 --
1 file changed, 10 deletions(-)
diff --git a/drivers/gpu/drm/mxsfb/lcdif_kms.c
b/drivers/gpu/drm/mxsfb/lcdif_kms.c
index 4acf6914a8d1..33a082366b25 100644
--- a/drivers/gpu/drm/mxsfb/lcdif_kms.c
+++ b/drivers/gpu/drm/mxsfb/lcdif_kms.c
@@ -541,7 +541,6 @@ static void lcdif_crtc_atomic_enable(struct drm_crtc *crtc,
crtc->primary);
struct drm_display_mode *m = &lcdif->crtc.state->adjusted_mode;
struct drm_device *drm = lcdif->drm;
- dma_addr_t paddr;
clk_set_rate(lcdif->clk, m->crtc_clock * 1000);
@@ -549,15 +548,6 @@ static void lcdif_crtc_atomic_enable(struct drm_crtc *crtc,
lcdif_crtc_mode_set_nofb(new_cstate, new_pstate);
- /* Write cur_buf as well to avoid an initial corrupt frame */
- paddr = drm_fb_dma_get_gem_addr(new_pstate->fb, new_pstate, 0);
- if (paddr) {
- writel(lower_32_bits(paddr),
- lcdif->base + LCDC_V8_CTRLDESCL_LOW0_4);
- writel(CTRLDESCL_HIGH0_4_ADDR_HIGH(upper_32_bits(paddr)),
- lcdif->base + LCDC_V8_CTRLDESCL_HIGH0_4);
- }
-
drm_crtc_vblank_on(crtc);
}
Reviewed-by: Marek Vasut
Re: [PATCH 4/5] drm: lcdif: move pitch setup to plane atomic update
On 9/20/23 12:31, Lucas Stach wrote: The buffer pitch may change when switching the buffer on a atomic update. As the register is double buffered it can be safely changed while the display is active. Signed-off-by: Lucas Stach --- drivers/gpu/drm/mxsfb/lcdif_kms.c | 26 +- 1 file changed, 13 insertions(+), 13 deletions(-) diff --git a/drivers/gpu/drm/mxsfb/lcdif_kms.c b/drivers/gpu/drm/mxsfb/lcdif_kms.c index 33a082366b25..3ebf55d06027 100644 --- a/drivers/gpu/drm/mxsfb/lcdif_kms.c +++ b/drivers/gpu/drm/mxsfb/lcdif_kms.c @@ -327,19 +327,6 @@ static void lcdif_set_mode(struct lcdif_drm_private *lcdif, u32 bus_flags) writel(CTRLDESCL0_1_HEIGHT(m->vdisplay) | CTRLDESCL0_1_WIDTH(m->hdisplay), lcdif->base + LCDC_V8_CTRLDESCL0_1); - - /* -* Undocumented P_SIZE and T_SIZE bitfields written in the downstream -* driver. Those bitfields control the AXI burst size. As of now there -* are two known values: -* 1 - 128Byte -* 2 - 256Byte -* Downstream sets this to 256B burst size to improve the memory access -* efficiency so set it here too. -*/ - ctrl = CTRLDESCL0_3_P_SIZE(2) | CTRLDESCL0_3_T_SIZE(2) | - CTRLDESCL0_3_PITCH(lcdif->crtc.primary->state->fb->pitches[0]); - writel(ctrl, lcdif->base + LCDC_V8_CTRLDESCL0_3); } static void lcdif_enable_controller(struct lcdif_drm_private *lcdif) @@ -689,6 +676,19 @@ static void lcdif_plane_primary_atomic_update(struct drm_plane *plane, writel(CTRLDESCL_HIGH0_4_ADDR_HIGH(upper_32_bits(paddr)), lcdif->base + LCDC_V8_CTRLDESCL_HIGH0_4); } + + /* +* Undocumented P_SIZE and T_SIZE bitfields written in the downstream +* driver. Those bitfields control the AXI burst size. As of now there +* are two known values: +* 1 - 128Byte +* 2 - 256Byte +* Downstream sets this to 256B burst size to improve the memory access +* efficiency so set it here too. +*/ + writel(CTRLDESCL0_3_P_SIZE(2) | CTRLDESCL0_3_T_SIZE(2) | + CTRLDESCL0_3_PITCH(new_pstate->fb->pitches[0]), + lcdif->base + LCDC_V8_CTRLDESCL0_3); } static bool lcdif_format_mod_supported(struct drm_plane *plane, Reviewed-by: Marek Vasut
Re: [PATCH 2/5] drm: lcdif: move controller enable into atomic_flush
On 9/20/23 12:31, Lucas Stach wrote:
Allow drm_atomic_helper_commit_tail_rpm to setup all the plane
state before the scanout is started.
Signed-off-by: Lucas Stach
---
drivers/gpu/drm/mxsfb/lcdif_kms.c | 6 +-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/mxsfb/lcdif_kms.c
b/drivers/gpu/drm/mxsfb/lcdif_kms.c
index f5bfe8b52920..4acf6914a8d1 100644
--- a/drivers/gpu/drm/mxsfb/lcdif_kms.c
+++ b/drivers/gpu/drm/mxsfb/lcdif_kms.c
@@ -505,6 +505,8 @@ static int lcdif_crtc_atomic_check(struct drm_crtc *crtc,
static void lcdif_crtc_atomic_flush(struct drm_crtc *crtc,
struct drm_atomic_state *state)
{
+ struct drm_crtc_state *crtc_state = drm_atomic_get_new_crtc_state(state,
+ crtc);
struct lcdif_drm_private *lcdif = to_lcdif_drm_private(crtc->dev);
struct drm_pending_vblank_event *event;
u32 reg;
@@ -513,6 +515,9 @@ static void lcdif_crtc_atomic_flush(struct drm_crtc *crtc,
reg |= CTRLDESCL0_5_SHADOW_LOAD_EN;
writel(reg, lcdif->base + LCDC_V8_CTRLDESCL0_5);
+ if (drm_atomic_crtc_needs_modeset(crtc_state))
+ lcdif_enable_controller(lcdif);
+
event = crtc->state->event;
crtc->state->event = NULL;
@@ -552,7 +557,6 @@ static void lcdif_crtc_atomic_enable(struct drm_crtc *crtc,
writel(CTRLDESCL_HIGH0_4_ADDR_HIGH(upper_32_bits(paddr)),
lcdif->base + LCDC_V8_CTRLDESCL_HIGH0_4);
}
- lcdif_enable_controller(lcdif);
drm_crtc_vblank_on(crtc);
}
Reviewed-by: Marek Vasut
Re: [PATCH 1/5] drm: lcdif: improve burst size configuration comment
On 9/20/23 12:31, Lucas Stach wrote: The comment regarding AXI bust size configuration is a bit hard to read. Improve the wording somewhat. Signed-off-by: Lucas Stach --- drivers/gpu/drm/mxsfb/lcdif_kms.c | 8 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/drivers/gpu/drm/mxsfb/lcdif_kms.c b/drivers/gpu/drm/mxsfb/lcdif_kms.c index 2541d2de4e45..f5bfe8b52920 100644 --- a/drivers/gpu/drm/mxsfb/lcdif_kms.c +++ b/drivers/gpu/drm/mxsfb/lcdif_kms.c @@ -329,12 +329,12 @@ static void lcdif_set_mode(struct lcdif_drm_private *lcdif, u32 bus_flags) lcdif->base + LCDC_V8_CTRLDESCL0_1); /* -* Undocumented P_SIZE and T_SIZE register but those written in the -* downstream kernel those registers control the AXI burst size. As of -* now there are two known values: +* Undocumented P_SIZE and T_SIZE bitfields written in the downstream s@written@documented only@ or so, since yeah, those fields are only used in the downstream driver and miss in the TRM . +* driver. Those bitfields control the AXI burst size. As of now there +* are two known values: * 1 - 128Byte * 2 - 256Byte -* Downstream set it to 256B burst size to improve the memory +* Downstream sets this to 256B burst size to improve the memory access * efficiency so set it here too. With that fixed: Reviewed-by: Marek Vasut
[RFC PATCH 2/2] drm: ci: add tests on vkms
Add job that runs igt on top of vkms.
Signed-off-by: Helen Koike
---
See pipeline:
https://gitlab.freedesktop.org/helen.fornazier/linux/-/pipelines/990494
---
MAINTAINERS | 1 +
drivers/gpu/drm/ci/build.sh | 1 -
drivers/gpu/drm/ci/gitlab-ci.yml | 1 +
drivers/gpu/drm/ci/igt_runner.sh | 6 ++--
drivers/gpu/drm/ci/image-tags.yml | 2 +-
drivers/gpu/drm/ci/test.yml | 24 ++-
drivers/gpu/drm/ci/x86_64.config | 1 +
.../drm/ci/xfails/virtio_gpu-none-flakes.txt | 0
drivers/gpu/drm/ci/xfails/vkms-none-fails.txt | 29 +++
drivers/gpu/drm/ci/xfails/vkms-none-skips.txt | 10 +++
10 files changed, 69 insertions(+), 6 deletions(-)
delete mode 100644 drivers/gpu/drm/ci/xfails/virtio_gpu-none-flakes.txt
create mode 100644 drivers/gpu/drm/ci/xfails/vkms-none-fails.txt
create mode 100644 drivers/gpu/drm/ci/xfails/vkms-none-skips.txt
diff --git a/MAINTAINERS b/MAINTAINERS
index 740a2ce2689c..e47dbe31d221 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -6813,6 +6813,7 @@ L:dri-devel@lists.freedesktop.org
S: Maintained
T: git git://anongit.freedesktop.org/drm/drm-misc
F: Documentation/gpu/vkms.rst
+F: drivers/gpu/drm/ci/xfails/vkms*
F: drivers/gpu/drm/vkms/
DRM DRIVER FOR VIRTUALBOX VIRTUAL GPU
diff --git a/drivers/gpu/drm/ci/build.sh b/drivers/gpu/drm/ci/build.sh
index 7b014287a041..9e510e77098b 100644
--- a/drivers/gpu/drm/ci/build.sh
+++ b/drivers/gpu/drm/ci/build.sh
@@ -146,7 +146,6 @@ fi
mkdir -p artifacts/install/lib
mv install/* artifacts/install/.
-rm -rf artifacts/install/modules
ln -s common artifacts/install/ci-common
for image in ${KERNEL_IMAGE_NAME}; do
diff --git a/drivers/gpu/drm/ci/gitlab-ci.yml b/drivers/gpu/drm/ci/gitlab-ci.yml
index 73725070702b..4705b9ecbc72 100644
--- a/drivers/gpu/drm/ci/gitlab-ci.yml
+++ b/drivers/gpu/drm/ci/gitlab-ci.yml
@@ -122,6 +122,7 @@ stages:
- rockchip
- virtio-gpu
- lint
+ - software-driver
# YAML anchors for rule conditions
#
diff --git a/drivers/gpu/drm/ci/igt_runner.sh b/drivers/gpu/drm/ci/igt_runner.sh
index 2bb759165063..c7f83d1b72e9 100755
--- a/drivers/gpu/drm/ci/igt_runner.sh
+++ b/drivers/gpu/drm/ci/igt_runner.sh
@@ -21,9 +21,9 @@ cat /sys/kernel/debug/dri/*/state
set -e
# Cannot use HWCI_KERNEL_MODULES as at that point we don't have the module in
/lib
-if [ "$IGT_FORCE_DRIVER" = "amdgpu" ]; then
-mv /install/modules/lib/modules/* /lib/modules/.
-modprobe amdgpu
+if [ "$IGT_FORCE_DRIVER" = "amdgpu" || "$IGT_FORCE_DRIVER" = "vkms" ]; then
+mv /install/modules/lib/modules/* /lib/modules/. || true
+modprobe --first-time "$IGT_FORCE_DRIVER"
fi
if [ -e "/install/xfails/$DRIVER_NAME-$GPU_VERSION-skips.txt" ]; then
diff --git a/drivers/gpu/drm/ci/image-tags.yml
b/drivers/gpu/drm/ci/image-tags.yml
index f051b6c547c5..e05077ee29d2 100644
--- a/drivers/gpu/drm/ci/image-tags.yml
+++ b/drivers/gpu/drm/ci/image-tags.yml
@@ -4,7 +4,7 @@ variables:
DEBIAN_BASE_TAG: "${CONTAINER_TAG}"
DEBIAN_X86_64_BUILD_IMAGE_PATH: "debian/x86_64_build"
- DEBIAN_BUILD_TAG: "${CONTAINER_TAG}"
+ DEBIAN_BUILD_TAG: "2023-09-20-vkms-module-2"
KERNEL_ROOTFS_TAG: "${CONTAINER_TAG}"
diff --git a/drivers/gpu/drm/ci/test.yml b/drivers/gpu/drm/ci/test.yml
index 6473cddaa7a9..e6ed8707423c 100644
--- a/drivers/gpu/drm/ci/test.yml
+++ b/drivers/gpu/drm/ci/test.yml
@@ -332,4 +332,26 @@ virtio_gpu:none:
- igt:x86_64
rules:
# TODO: current issue: malloc(): corrupted top size. Fix and remove this
rule.
-- when: never
\ No newline at end of file
+- when: never
+
+vkms:none:
+ stage: software-driver
+ variables:
+DRIVER_NAME: vkms
+GPU_VERSION: none
+ extends:
+- .test-gl
+ tags:
+- kvm
+ script:
+- ln -sf $CI_PROJECT_DIR/install /install
+- mv install/bzImage /lava-files/bzImage
+- mkdir -p /lib/modules
+- mv install/modules/lib/modules/* /lib/modules/.
+- mkdir -p $CI_PROJECT_DIR/results
+- ln -sf $CI_PROJECT_DIR/results /results
+- ./install/crosvm-runner.sh ./install/igt_runner.sh
+ needs:
+- debian/x86_64_test-gl
+- testing:x86_64
+- igt:x86_64
\ No newline at end of file
diff --git a/drivers/gpu/drm/ci/x86_64.config b/drivers/gpu/drm/ci/x86_64.config
index 1cbd49a5b23a..8eaba388b141 100644
--- a/drivers/gpu/drm/ci/x86_64.config
+++ b/drivers/gpu/drm/ci/x86_64.config
@@ -24,6 +24,7 @@ CONFIG_DRM=y
CONFIG_DRM_PANEL_SIMPLE=y
CONFIG_PWM_CROS_EC=y
CONFIG_BACKLIGHT_PWM=y
+CONFIG_DRM_VKMS=m
# Strip out some stuff we don't need for graphics testing, to reduce
# the build.
diff --git a/drivers/gpu/drm/ci/xfails/virtio_gpu-none-flakes.txt
b/drivers/gpu/drm/ci/xfails/virtio_gpu-none-flakes.txt
deleted file mode 100644
index e69de29bb2d1..
diff --git a/drivers/gpu/drm/ci/xfails/vkms-none-fails.txt
b/drivers/gpu/drm/ci/
[RFC PATCH 1/2] drm/ci: uprev mesa version - fix container build
When building containers, some rust packages were installed without
locking the dependencies version, which got updated and started giving
errors like:
error: failed to compile `bindgen-cli v0.62.0`, intermediate artifacts can be
found at `/tmp/cargo-installkNKRwf`
Caused by:
package `rustix v0.38.13` cannot be built because it requires rustc 1.63 or
newer, while the currently active rustc version is 1.60.0
A patch to Mesa was recently added fixing this error, so update it.
Signed-off-by: Helen Koike
---
I'm submitting this to make it available for other to run and test. I'd
like to solve the TODO below (blocked on Mesa) before this is picked up.
---
drivers/gpu/drm/ci/gitlab-ci.yml | 19 +--
drivers/gpu/drm/ci/lava-submit.sh | 2 +-
2 files changed, 18 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/ci/gitlab-ci.yml b/drivers/gpu/drm/ci/gitlab-ci.yml
index 2c4df53f5dfe..73725070702b 100644
--- a/drivers/gpu/drm/ci/gitlab-ci.yml
+++ b/drivers/gpu/drm/ci/gitlab-ci.yml
@@ -1,6 +1,8 @@
variables:
- DRM_CI_PROJECT_PATH: &drm-ci-project-path mesa/mesa
- DRM_CI_COMMIT_SHA: &drm-ci-commit-sha
0dc961645c4f0241f8512cb0ec3ad59635842072
+ # TODO: point back to mesa/mesa once the following issue is fixed:
+ # https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/25238
+ DRM_CI_PROJECT_PATH: &drm-ci-project-path helen.fornazier/mesa
+ DRM_CI_COMMIT_SHA: &drm-ci-commit-sha inc-files
UPSTREAM_REPO: git://anongit.freedesktop.org/drm/drm
TARGET_BRANCH: drm-next
@@ -24,6 +26,8 @@ variables:
PIPELINE_ARTIFACTS_BASE:
${S3_HOST}/artifacts/${CI_PROJECT_PATH}/${CI_PIPELINE_ID}
# per-job artifact storage on MinIO
JOB_ARTIFACTS_BASE: ${PIPELINE_ARTIFACTS_BASE}/${CI_JOB_ID}
+ # default kernel for rootfs before injecting the current kernel tree
+ KERNEL_IMAGE_BASE:
https://${S3_HOST}/mesa-lava/gfx-ci/linux/v6.4.12-for-mesa-ci-f6b4ad45f48d
LAVA_JOB_PRIORITY: 30
@@ -86,6 +90,17 @@ include:
- '/.gitlab-ci/container/gitlab-ci.yml'
- '/.gitlab-ci/test/gitlab-ci.yml'
- '/.gitlab-ci/lava/lava-gitlab-ci.yml'
+ - '/src/microsoft/ci/gitlab-ci-inc.yml'
+ - '/src/gallium/drivers/zink/ci/gitlab-ci-inc.yml'
+ - '/src/gallium/drivers/crocus/ci/gitlab-ci-inc.yml'
+ - '/src/gallium/drivers/softpipe/ci/gitlab-ci-inc.yml'
+ - '/src/gallium/drivers/llvmpipe/ci/gitlab-ci-inc.yml'
+ - '/src/gallium/drivers/virgl/ci/gitlab-ci-inc.yml'
+ - '/src/gallium/drivers/nouveau/ci/gitlab-ci-inc.yml'
+ - '/src/gallium/frontends/lavapipe/ci/gitlab-ci-inc.yml'
+ - '/src/intel/ci/gitlab-ci-inc.yml'
+ - '/src/freedreno/ci/gitlab-ci-inc.yml'
+ - '/src/amd/ci/gitlab-ci-inc.yml'
- drivers/gpu/drm/ci/image-tags.yml
- drivers/gpu/drm/ci/container.yml
- drivers/gpu/drm/ci/static-checks.yml
diff --git a/drivers/gpu/drm/ci/lava-submit.sh
b/drivers/gpu/drm/ci/lava-submit.sh
index 0c4456b21b0f..379f26ea87cc 100755
--- a/drivers/gpu/drm/ci/lava-submit.sh
+++ b/drivers/gpu/drm/ci/lava-submit.sh
@@ -22,7 +22,7 @@ cp "$SCRIPTS_DIR"/setup-test-env.sh
results/job-rootfs-overlay/
# Prepare env vars for upload.
section_start variables "Variables passed through:"
-KERNEL_IMAGE_BASE_URL="https://${BASE_SYSTEM_HOST_PATH}"; \
+KERNEL_IMAGE_BASE="https://${BASE_SYSTEM_HOST_PATH}"; \
artifacts/ci-common/generate-env.sh | tee
results/job-rootfs-overlay/set-job-env-vars.sh
section_end variables
--
2.34.1
[RFC PATCH 0/2] drm/ci: Update Mesa and Introduce VKMS Support
This patchset offers two enhancements to drm/ci: 1. Mesa Version Update. drm/ci re-uses components from Mesa project. A recent bug in MesaCI was fixed. The first patch updates drm/ci Mesa's version, re-allowing containers rebuilds when uncached, essencial for new runs. At this moment, this change depends on the following MR: https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/25238 For now, I'm just pointing to a branch in my personal repo (this is why it is an RFC) so people can already review and test it. 2. VKMS Driver Testing, together with the -skips.txt and -fails.txt list that were found during the tests. Helen Koike (2): drm/ci: uprev mesa version - fix container build drm: ci: add tests on vkms MAINTAINERS | 1 + drivers/gpu/drm/ci/build.sh | 1 - drivers/gpu/drm/ci/gitlab-ci.yml | 20 +++-- drivers/gpu/drm/ci/igt_runner.sh | 6 ++-- drivers/gpu/drm/ci/image-tags.yml | 2 +- drivers/gpu/drm/ci/lava-submit.sh | 2 +- drivers/gpu/drm/ci/test.yml | 24 ++- drivers/gpu/drm/ci/x86_64.config | 1 + .../drm/ci/xfails/virtio_gpu-none-flakes.txt | 0 drivers/gpu/drm/ci/xfails/vkms-none-fails.txt | 29 +++ drivers/gpu/drm/ci/xfails/vkms-none-skips.txt | 10 +++ 11 files changed, 87 insertions(+), 9 deletions(-) delete mode 100644 drivers/gpu/drm/ci/xfails/virtio_gpu-none-flakes.txt create mode 100644 drivers/gpu/drm/ci/xfails/vkms-none-fails.txt create mode 100644 drivers/gpu/drm/ci/xfails/vkms-none-skips.txt -- 2.34.1
Re: [Intel-gfx] [PATCH] drm/edid: Fixup h/vsync_end instead of h/vtotal
On Thu, 14 Sep 2023, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> There are some weird EDIDs floating around that have the sync
> pulse extending beyond the end of the blanking period.
>
> On the currently problemtic machine (HP Omni 120) EDID reports
> the following mode:
> "1600x900": 60 108000 1600 1780 1860 1800 900 910 913 1000 0x40 0x5
> which is then "corrected" to have htotal=1861 by the current drm_edid.c
> code.
>
> The fixup code was originally added in commit 7064fef56369 ("drm: work
> around EDIDs with bad htotal/vtotal values"). Googling around we end up in
> https://bugs.launchpad.net/ubuntu/hardy/+source/xserver-xorg-video-intel/+bug/297245
> where we find an EDID for a Dell Studio 15, which reports:
> (II) VESA(0): clock: 65.0 MHz Image Size: 331 x 207 mm
> (II) VESA(0): h_active: 1280 h_sync: 1328 h_sync_end 1360 h_blank_end 1337
> h_border: 0
> (II) VESA(0): v_active: 800 v_sync: 803 v_sync_end 809 v_blanking: 810
> v_border: 0
>
> Note that if we use the hblank size (as opposed of the hsync_end)
> from the DTD to determine htotal we get exactly 60Hz refresh rate in
> both cases, whereas using hsync_end to determine htotal we get a
> slightly lower refresh rates. This makes me believe the using the
> hblank size is what was intended even in those cases.
>
> Also note that in case of the HP Onmi 120 the VBIOS boots with these:
> crtc timings: 108000 1600 1780 1860 1800 900 910 913 1000, type: 0x40
> flags: 0x5
> ie. it just blindly stuffs the bogus hsync_end and htotal from the DTD
> into the transcoder timing registers, and the display works. I believe
> the (at least more modern) hardware will automagically terminate the hsync
> pulse when the timing generator reaches htotal, which again points that we
> should use the hblank size to determine htotal. Unfortunatley the old bug
> reports for the Dell machines are extremely lacking in useful details so
> we have no idea what kind of timings the VBIOS programmed into the
> hardware :(
>
> Let's just flip this quirk around and reduce the length of the sync
> pulse instead of extending the blanking period. This at least seems
> to be the correct thing to do on more modern hardware. And if any
> issues crop up on older hardware we need to debug them properly.
>
> Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/8895
> Signed-off-by: Ville Syrjälä
> ---
> drivers/gpu/drm/drm_edid.c | 6 +++---
> 1 file changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
> index 39dd3f694544..0c5563b4d21e 100644
> --- a/drivers/gpu/drm/drm_edid.c
> +++ b/drivers/gpu/drm/drm_edid.c
> @@ -3497,11 +3497,11 @@ static struct drm_display_mode
> *drm_mode_detailed(struct drm_connector *connecto
> mode->vsync_end = mode->vsync_start + vsync_pulse_width;
> mode->vtotal = mode->vdisplay + vblank;
>
> - /* Some EDIDs have bogus h/vtotal values */
> + /* Some EDIDs have bogus h/vsync_end values */
> if (mode->hsync_end > mode->htotal)
> - mode->htotal = mode->hsync_end + 1;
> + mode->hsync_end = mode->htotal;
> if (mode->vsync_end > mode->vtotal)
> - mode->vtotal = mode->vsync_end + 1;
> + mode->vsync_end = mode->vtotal;
I wonder if we shouldn't debug log these to help our future selves?
Anyway,
Reviewed-by: Jani Nikula
>
> drm_mode_do_interlace_quirk(mode, pt);
--
Jani Nikula, Intel
Re: [PATCH] drm/i915: Remove unnecessary memory quiescing for aux inval
On Wed, Sep 20, 2023 at 01:11:31PM +0200, Nirmoy Das wrote:
> i915 already does memory quiesce before signaling
> breadcrumb so remove extra memory quiescing for aux
> invalidation which can cause unnecessary side effects.
This explanation seems confusing to me. If we've already performed the
necessary flushing and quiesced all cache<->memory traffic, then
performing another flush should just be a noop, right? If we're seeing
side effects, then doesn't that imply that there was still something in
the cache that hadn't made its way to memory yet?
Is the breadcrumb code flushing all the necessary bits? What about
PIPE_CONTROL_CCS_FLUSH?
Matt
>
> Fixes: 78a6ccd65fa3 ("drm/i915/gt: Ensure memory quiesced before
> invalidation")
> Cc: Jonathan Cavitt
> Cc: Andi Shyti
> Cc: # v5.8+
> Cc: Andrzej Hajda
> Cc: Tvrtko Ursulin
> Cc: Matt Roper
> Cc: Tejas Upadhyay
> Cc: Lucas De Marchi
> Cc: Prathap Kumar Valsan
> Cc: Tapani Pälli
> Cc: Mark Janes
> Cc: Rodrigo Vivi
> Signed-off-by: Nirmoy Das
> ---
> drivers/gpu/drm/i915/gt/gen8_engine_cs.c | 50
> 1 file changed, 26 insertions(+), 24 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/gt/gen8_engine_cs.c
> b/drivers/gpu/drm/i915/gt/gen8_engine_cs.c
> index 0143445dba83..5001670046a0 100644
> --- a/drivers/gpu/drm/i915/gt/gen8_engine_cs.c
> +++ b/drivers/gpu/drm/i915/gt/gen8_engine_cs.c
> @@ -248,11 +248,7 @@ int gen12_emit_flush_rcs(struct i915_request *rq, u32
> mode)
> {
> struct intel_engine_cs *engine = rq->engine;
>
> - /*
> - * On Aux CCS platforms the invalidation of the Aux
> - * table requires quiescing memory traffic beforehand
> - */
> - if (mode & EMIT_FLUSH || gen12_needs_ccs_aux_inv(engine)) {
> + if (mode & EMIT_FLUSH) {
> u32 bit_group_0 = 0;
> u32 bit_group_1 = 0;
> int err;
> @@ -264,13 +260,6 @@ int gen12_emit_flush_rcs(struct i915_request *rq, u32
> mode)
>
> bit_group_0 |= PIPE_CONTROL0_HDC_PIPELINE_FLUSH;
>
> - /*
> - * When required, in MTL and beyond platforms we
> - * need to set the CCS_FLUSH bit in the pipe control
> - */
> - if (GRAPHICS_VER_FULL(rq->i915) >= IP_VER(12, 70))
> - bit_group_0 |= PIPE_CONTROL_CCS_FLUSH;
> -
> bit_group_1 |= PIPE_CONTROL_TILE_CACHE_FLUSH;
> bit_group_1 |= PIPE_CONTROL_FLUSH_L3;
> bit_group_1 |= PIPE_CONTROL_RENDER_TARGET_CACHE_FLUSH;
> @@ -800,14 +789,15 @@ u32 *gen12_emit_fini_breadcrumb_rcs(struct i915_request
> *rq, u32 *cs)
> {
> struct drm_i915_private *i915 = rq->i915;
> struct intel_gt *gt = rq->engine->gt;
> - u32 flags = (PIPE_CONTROL_CS_STALL |
> - PIPE_CONTROL_TLB_INVALIDATE |
> - PIPE_CONTROL_TILE_CACHE_FLUSH |
> - PIPE_CONTROL_FLUSH_L3 |
> - PIPE_CONTROL_RENDER_TARGET_CACHE_FLUSH |
> - PIPE_CONTROL_DEPTH_CACHE_FLUSH |
> - PIPE_CONTROL_DC_FLUSH_ENABLE |
> - PIPE_CONTROL_FLUSH_ENABLE);
> + u32 bit_group_0 = PIPE_CONTROL0_HDC_PIPELINE_FLUSH;
> + u32 bit_group_1 = (PIPE_CONTROL_CS_STALL |
> +PIPE_CONTROL_TLB_INVALIDATE |
> +PIPE_CONTROL_TILE_CACHE_FLUSH |
> +PIPE_CONTROL_FLUSH_L3 |
> +PIPE_CONTROL_RENDER_TARGET_CACHE_FLUSH |
> +PIPE_CONTROL_DEPTH_CACHE_FLUSH |
> +PIPE_CONTROL_DC_FLUSH_ENABLE |
> +PIPE_CONTROL_FLUSH_ENABLE);
>
> /* Wa_14016712196 */
> if (IS_GFX_GT_IP_RANGE(gt, IP_VER(12, 70), IP_VER(12, 71)) ||
> IS_DG2(i915))
> @@ -817,14 +807,26 @@ u32 *gen12_emit_fini_breadcrumb_rcs(struct i915_request
> *rq, u32 *cs)
>
> if (GRAPHICS_VER(i915) == 12 && GRAPHICS_VER_FULL(i915) < IP_VER(12,
> 50))
> /* Wa_1409600907 */
> - flags |= PIPE_CONTROL_DEPTH_STALL;
> + bit_group_1 |= PIPE_CONTROL_DEPTH_STALL;
>
> if (!HAS_3D_PIPELINE(rq->i915))
> - flags &= ~PIPE_CONTROL_3D_ARCH_FLAGS;
> + bit_group_1 &= ~PIPE_CONTROL_3D_ARCH_FLAGS;
> else if (rq->engine->class == COMPUTE_CLASS)
> - flags &= ~PIPE_CONTROL_3D_ENGINE_FLAGS;
> + bit_group_1 &= ~PIPE_CONTROL_3D_ENGINE_FLAGS;
> +
> + /*
> + * On Aux CCS platforms the invalidation of the Aux
> + * table requires quiescing memory traffic beforehand.
> + * gen12_emit_fini_breadcrumb_rcs() does this for us as
> + * all memory traffic has to be completed before we signal
> + * the breadcrumb. In MTL and beyond platforms, we need to also
> + * add CCS_FLUSH bit in the pipe control for that purpose.
> + */
> +
> + if (GRAPHICS_VER_FULL(rq->i915) >= IP_VER(12, 70))
> + bit_group_0 |= PIPE_CONTROL_CCS_FLUSH;
>
> -
Re: Decrypting tt maps in ttm
Hi, Zack On 9/20/23 18:39, Zack Rusin wrote: On Wed, 2023-09-20 at 12:48 +0200, Christian König wrote: !! External Email Am 20.09.23 um 09:36 schrieb Thomas Hellström: Hi, Zack, On 9/20/23 05:43, Zack Rusin wrote: On Tue, 2023-09-19 at 09:47 +0200, Christian König wrote: !! External Email Am 19.09.23 um 08:56 schrieb Thomas Hellström: On 9/19/23 07:39, Christian König wrote: Am 19.09.23 um 03:26 schrieb Zack Rusin: On Mon, 2023-09-18 at 16:21 -0400, Alex Deucher wrote: !! External Email On Mon, Sep 18, 2023 at 3:06 PM Thomas Hellström wrote: On 9/18/23 17:52, Zack Rusin wrote: On Mon, 2023-09-18 at 17:13 +0200, Thomas Hellström wrote: Hi, On 9/18/23 16:56, Thomas Hellström wrote: Hi Zack, Christian On 9/18/23 13:36, Christian König wrote: Hi Zack, adding Thomas and Daniel. I briefly remember that I talked with Thomas and some other people about that quite a while ago as well, but I don't fully remember the outcome. Found one old thread, but didn't read it: https://lists.freedesktop.org/archives/dri-devel/2019-September/234100.html /Thomas Ugh. Now starting to read that thread I have a vague recollection it all ended with not supporting mapping any device pages whatsoever when SEV was enabled, but rather resorting to llvmpipe and VM-local bos. Hi, Thomas. Thanks for finding this! I'd (of course) like to solve it properly and get vmwgfx running with 3d support with SEV-ES active instead of essentially disabling the driver when SEV-ES is active. I think there are two separate discussions there, the non-controversial one and the controversial one: 1) The non-controversial: is there a case where drivers would want encrypted memory for TT pages but not for io mem mappings? Because if not then as Christian pointed out we could just add pgprot_decrypted to ttm_io_prot and be essentially done. The current method of decrypting io mem but leaving sys mem mappings encrypted is a bit weird anyway. If the answer to that question is "yes, some driver does want the TT mappings to be encrypted" then your "[PATCH v2 3/4] drm/ttm, drm/vmwgfx: Correctly support support AMD memory encryption" solves that. I think getting one of those two in makes sense regardless of everything else, agreed? Well, there is more to it I think. IIRC, the AMD SME encryption mode has a way for a device to have the memory controller (?) encrypt / decrypt device traffic by using an address range alias, so in theory it supports encrypted TT pages, and the dma-layer may indeed hand encrypted DMA pages to TTM on such systems depending on the device's DMA mask. That's why I think that force_dma_unencrypted() export was needed, and If the amdgpu driver accesses TT memory in SME mode *without* pgprot_decrypted() and it still works, then I think that mode is actually used. How could it otherwise work? For SME, as long as the encrypted bit is set in the physical address used for DMA, the memory controller will handle the encrypt/decrypt for the device. For devices with a limited dma mask, you need to use the IOMMU so that the encrypted bit is retained when the address hits the memory controller. How does that work on systems with swiotlb, e.g. swiotlb=force, or i.e. what would decrypt the ttm tt mappings when copying between system and vram when iommu is disabled/absent? SME makes it mandatory that all devices can handle the physical address used for DMA, either native or with the help of IOMMU. Hacks like SWIOTLB are not directly supported as far as I know. Maybe somehow SWIOTLB manually decrypts the data while copying it or something like this, but I'm not 100% sure if that is actually implemented. Regards, Christian. A bold guess after looking at various code and patches: 1) Devices under SME that don't support the encryption bit and SEV: a) Coherent memory is unencrypted. b) Streaming DMA under IOMMU: The IOMMU sets the encrypted bit. c) Streaming DMA with SWIOTLB: The bounce buffer is unencrypted. Copying to/from bounce-buffer decrypts/encrypts. 2) Devices under SME that do support the encryption bit (which I believe is most graphics devices in general on SME systems, not just amdgpu; it "just works") *) Coherent memory is encrypted. The DMA layer sets dma addresses and pgprot accordingly. *) Streaming DMA is encrypted. So the bug in TTM would then be it's not handling 1a) and 1b) correctly. Remedy: 1b) Shouldn't be used with encryption. 1a) This is what we should try to fix. Exporting dma_force_unencrypted() didn't seem to be a way forward. Properly fixing this would, I guess, mean implement the missing functionality in the dma layer: For vmap / kmap we could simply reuse the virtual addresses we get back from dma_alloc_coherent(), but for faulting one would want something like dma_coherent_insert_pfn() (if it doesn't exist already) after a proper disussion with Christoph Hellwig. Christoph once pointed me to dma_mmap_attrs() for this, but I never found the time to fully look into it. Hmm, yea, that
Re: [PATCH RFC v2 07/37] drm/connector: hdmi: Add HDMI compute clock helper
Hi Maxime!
Dne sreda, 20. september 2023 ob 16:35:22 CEST je Maxime Ripard napisal(a):
> A lot of HDMI drivers have some variation of the formula to calculate
> the TMDS character rate from a mode, but few of them actually take all
> parameters into account.
>
> Let's create a helper to provide that rate taking all parameters into
> account.
>
> Signed-off-by: Maxime Ripard
> ---
> drivers/gpu/drm/drm_connector.c | 31 +++
> include/drm/drm_connector.h | 5 +
> 2 files changed, 36 insertions(+)
>
> diff --git a/drivers/gpu/drm/drm_connector.c b/drivers/gpu/drm/drm_connector.c
> index b01cb4783ea6..4c1af97971bb 100644
> --- a/drivers/gpu/drm/drm_connector.c
> +++ b/drivers/gpu/drm/drm_connector.c
> @@ -2944,6 +2944,37 @@ void drm_connector_update_privacy_screen(const struct
> drm_connector_state *conne
> }
> EXPORT_SYMBOL(drm_connector_update_privacy_screen);
>
> +/**
> + * drm_connector_hdmi_compute_mode_clock() - Computes the TMDS Character Rate
> + * @mode: Display mode to compute the clock for
> + * @bpc: Bits per character
> + * @fmt: Output Pixel Format used
> + *
> + * Returns the TMDS Character Rate for a given mode, bpc count and output
> format.
> + *
> + * RETURNS:
> + * The TMDS Character Rate, in Hertz
> + */
> +unsigned long long
> +drm_connector_hdmi_compute_mode_clock(const struct drm_display_mode *mode,
> + unsigned int bpc,
> + enum hdmi_colorspace fmt)
> +{
> + unsigned long long clock = mode->clock * 1000ULL;
> +
> + if (mode->flags & DRM_MODE_FLAG_DBLCLK)
> + clock = clock * 2;
> +
> + if (fmt == HDMI_COLORSPACE_YUV422)
> + bpc = 8;
I think you're missing YUV420 handling, which needs half of clock speed. But
this is a thing of HDMI2.
Best regards,
Jernej
> +
> + clock = clock * bpc;
> + do_div(clock, 8);
> +
> + return clock;
> +}
> +EXPORT_SYMBOL(drm_connector_hdmi_compute_mode_clock);
> +
> int drm_connector_set_obj_prop(struct drm_mode_object *obj,
> struct drm_property *property,
> uint64_t value)
> diff --git a/include/drm/drm_connector.h b/include/drm/drm_connector.h
> index a66cb4e35d7b..d74e9c64ee88 100644
> --- a/include/drm/drm_connector.h
> +++ b/include/drm/drm_connector.h
> @@ -38,6 +38,7 @@ struct drm_connector_helper_funcs;
> struct drm_modeset_acquire_ctx;
> struct drm_device;
> struct drm_crtc;
> +struct drm_display_mode;
> struct drm_encoder;
> struct drm_panel;
> struct drm_property;
> @@ -2115,6 +2116,10 @@ void
> drm_connector_attach_privacy_screen_properties(struct drm_connector *conn);
> void drm_connector_attach_privacy_screen_provider(
> struct drm_connector *connector, struct drm_privacy_screen *priv);
> void drm_connector_update_privacy_screen(const struct drm_connector_state
> *connector_state);
> +unsigned long long
> +drm_connector_hdmi_compute_mode_clock(const struct drm_display_mode *mode,
> + unsigned int bpc,
> + enum hdmi_colorspace fmt);
>
> /**
> * struct drm_tile_group - Tile group metadata
>
>
Re: [PATCH RFC v2 11/37] drm/connector: hdmi: Add Infoframes generation
Dne sreda, 20. september 2023 ob 16:35:26 CEST je Maxime Ripard napisal(a):
> Infoframes in KMS is usually handled by a bunch of low-level helpers
> that require quite some boilerplate for drivers. This leads to
> discrepancies with how drivers generate them, and which are actually
> sent.
>
> Now that we have everything needed to generate them in the HDMI
> connector state, we can generate them in our common logic so that
> drivers can simply reuse what we precomputed.
>
> Signed-off-by: Maxime Ripard
> ---
> drivers/gpu/drm/Kconfig | 1 +
> drivers/gpu/drm/drm_atomic_state_helper.c | 327
> ++
> drivers/gpu/drm/drm_connector.c | 9 +
> include/drm/drm_atomic_state_helper.h | 6 +
> include/drm/drm_connector.h | 131
> 5 files changed, 474 insertions(+)
>
> diff --git a/drivers/gpu/drm/Kconfig b/drivers/gpu/drm/Kconfig
> index ab9ef1c20349..10caf2dcce93 100644
> --- a/drivers/gpu/drm/Kconfig
> +++ b/drivers/gpu/drm/Kconfig
> @@ -99,6 +99,7 @@ config DRM_KUNIT_TEST
> config DRM_KMS_HELPER
> tristate
> depends on DRM
> + select DRM_DISPLAY_HDMI_HELPER
> help
> CRTC helpers for KMS drivers.
>
> diff --git a/drivers/gpu/drm/drm_atomic_state_helper.c
> b/drivers/gpu/drm/drm_atomic_state_helper.c
> index 2f85422cccd4..5bbdd2f7d306 100644
> --- a/drivers/gpu/drm/drm_atomic_state_helper.c
> +++ b/drivers/gpu/drm/drm_atomic_state_helper.c
> @@ -38,6 +38,8 @@
> #include
> #include
>
> +#include
> +
> #include
> #include
>
> @@ -839,6 +841,142 @@ hdmi_compute_config(const struct drm_connector
> *connector,
> return -EINVAL;
> }
>
> +static int hdmi_generate_avi_infoframe(const struct drm_connector *connector,
> +struct drm_connector_state *state)
> +{
> + const struct drm_display_mode *mode =
> + connector_state_get_adjusted_mode(state);
> + struct drm_connector_hdmi_infoframe *infoframe =
> + &state->hdmi.infoframes.avi;
> + struct hdmi_avi_infoframe *frame =
> + &infoframe->data.avi;
> + bool is_lim_range =
> + drm_atomic_helper_connector_hdmi_is_full_range(connector,
> +state);
> + enum hdmi_quantization_range rgb_quant_range =
> + is_lim_range ? HDMI_QUANTIZATION_RANGE_FULL :
> HDMI_QUANTIZATION_RANGE_LIMITED;
While usage of is_lim_range is correct, its name is off. Replace lim with full.
Best regards,
Jernej
> + int ret;
> +
> + ret = drm_hdmi_avi_infoframe_from_display_mode(frame, connector, mode);
> + if (ret)
> + return ret;
> +
> + frame->colorspace = state->hdmi.output_format;
> +
> + drm_hdmi_avi_infoframe_quant_range(frame, connector, mode,
> rgb_quant_range);
> + drm_hdmi_avi_infoframe_colorimetry(frame, state);
> + drm_hdmi_avi_infoframe_bars(frame, state);
> +
> + infoframe->set = true;
> +
> + return 0;
> +}
> +
> +static int hdmi_generate_spd_infoframe(const struct drm_connector *connector,
> +struct drm_connector_state *state)
> +{
> + struct drm_connector_hdmi_infoframe *infoframe =
> + &state->hdmi.infoframes.spd;
> + struct hdmi_spd_infoframe *frame =
> + &infoframe->data.spd;
> + int ret;
> +
> + ret = hdmi_spd_infoframe_init(frame,
> + connector->hdmi.vendor,
> + connector->hdmi.product);
> + if (ret)
> + return ret;
> +
> + frame->sdi = HDMI_SPD_SDI_PC;
> +
> + infoframe->set = true;
> +
> + return 0;
> +}
> +
> +static int hdmi_generate_hdr_infoframe(const struct drm_connector *connector,
> +struct drm_connector_state *state)
> +{
> + struct drm_connector_hdmi_infoframe *infoframe =
> + &state->hdmi.infoframes.drm;
> + struct hdmi_drm_infoframe *frame =
> + &infoframe->data.drm;
> + int ret;
> +
> + if (connector->max_bpc < 10)
> + return 0;
> +
> + if (!state->hdr_output_metadata)
> + return 0;
> +
> + ret = drm_hdmi_infoframe_set_hdr_metadata(frame, state);
> + if (ret)
> + return ret;
> +
> + infoframe->set = true;
> +
> + return 0;
> +}
> +
> +static int hdmi_generate_vendor_infoframe(const struct drm_connector
> *connector,
> + struct drm_connector_state *state)
> +{
> + const struct drm_display_mode *mode =
> + connector_state_get_adjusted_mode(state);
> + struct drm_connector_hdmi_infoframe *infoframe =
> + &state->hdmi.infoframes.vendor;
> + struct hdmi_vendor_infoframe *frame =
> + &infoframe->data.vendor.hdmi;
> + int ret;
> +
> + ret = drm_hdmi_vendor_infoframe_from_display_mode(frame, connector,
> mode);
> +
[PATCH v3 2/2] drm/bridge: imx: add driver for HDMI TX Parallel Video Interface
This IP block is found in the HDMI subsystem of the i.MX8MP SoC. It has a
full timing generator and can switch between different video sources. On
the i.MX8MP however the only supported source is the LCDIF. The block
just needs to be powered up and told about the polarity of the video
sync signals to act in bypass mode.
Signed-off-by: Lucas Stach
Reviewed-by: Luca Ceresoli (v2)
Tested-by: Marek Vasut (v1)
Tested-by: Luca Ceresoli (v2)
Tested-by: Richard Leitner (v2)
Tested-by: Frieder Schrempf (v2)
---
drivers/gpu/drm/bridge/imx/Kconfig | 7 +
drivers/gpu/drm/bridge/imx/Makefile | 1 +
drivers/gpu/drm/bridge/imx/imx8mp-hdmi-pvi.c | 206 +++
3 files changed, 214 insertions(+)
create mode 100644 drivers/gpu/drm/bridge/imx/imx8mp-hdmi-pvi.c
diff --git a/drivers/gpu/drm/bridge/imx/Kconfig
b/drivers/gpu/drm/bridge/imx/Kconfig
index 9fae28db6aa7..3a4e663d922a 100644
--- a/drivers/gpu/drm/bridge/imx/Kconfig
+++ b/drivers/gpu/drm/bridge/imx/Kconfig
@@ -3,6 +3,13 @@ if ARCH_MXC || COMPILE_TEST
config DRM_IMX_LDB_HELPER
tristate
+config DRM_IMX8MP_HDMI_PVI
+ tristate "Freescale i.MX8MP HDMI PVI bridge support"
+ depends on OF
+ help
+ Choose this to enable support for the internal HDMI TX Parallel
+ Video Interface found on the Freescale i.MX8MP SoC.
+
config DRM_IMX8QM_LDB
tristate "Freescale i.MX8QM LVDS display bridge"
depends on OF
diff --git a/drivers/gpu/drm/bridge/imx/Makefile
b/drivers/gpu/drm/bridge/imx/Makefile
index 8e2ebf3399a1..be9b4f9adb50 100644
--- a/drivers/gpu/drm/bridge/imx/Makefile
+++ b/drivers/gpu/drm/bridge/imx/Makefile
@@ -1,4 +1,5 @@
obj-$(CONFIG_DRM_IMX_LDB_HELPER) += imx-ldb-helper.o
+obj-$(CONFIG_DRM_IMX8MP_HDMI_PVI) += imx8mp-hdmi-pvi.o
obj-$(CONFIG_DRM_IMX8QM_LDB) += imx8qm-ldb.o
obj-$(CONFIG_DRM_IMX8QXP_LDB) += imx8qxp-ldb.o
obj-$(CONFIG_DRM_IMX8QXP_PIXEL_COMBINER) += imx8qxp-pixel-combiner.o
diff --git a/drivers/gpu/drm/bridge/imx/imx8mp-hdmi-pvi.c
b/drivers/gpu/drm/bridge/imx/imx8mp-hdmi-pvi.c
new file mode 100644
index ..5ccd70c98187
--- /dev/null
+++ b/drivers/gpu/drm/bridge/imx/imx8mp-hdmi-pvi.c
@@ -0,0 +1,206 @@
+// SPDX-License-Identifier: GPL-2.0+
+
+/*
+ * Copyright (C) 2022 Pengutronix, Lucas Stach
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#define HTX_PVI_CTRL 0x0
+#define PVI_CTRL_OP_VSYNC_POL BIT(18)
+#define PVI_CTRL_OP_HSYNC_POL BIT(17)
+#define PVI_CTRL_OP_DE_POLBIT(16)
+#define PVI_CTRL_INP_VSYNC_POLBIT(14)
+#define PVI_CTRL_INP_HSYNC_POLBIT(13)
+#define PVI_CTRL_INP_DE_POL BIT(12)
+#define PVI_CTRL_MODE_MASKGENMASK(2, 1)
+#define PVI_CTRL_MODE_LCDIF 2
+#define PVI_CTRL_EN BIT(0)
+
+struct imx8mp_hdmi_pvi {
+ struct drm_bridge bridge;
+ struct device *dev;
+ struct drm_bridge *next_bridge;
+ void __iomem*regs;
+};
+
+static inline struct imx8mp_hdmi_pvi *
+to_imx8mp_hdmi_pvi(struct drm_bridge *bridge)
+{
+ return container_of(bridge, struct imx8mp_hdmi_pvi, bridge);
+}
+
+static int imx8mp_hdmi_pvi_bridge_attach(struct drm_bridge *bridge,
+enum drm_bridge_attach_flags flags)
+{
+ struct imx8mp_hdmi_pvi *pvi = to_imx8mp_hdmi_pvi(bridge);
+
+ return drm_bridge_attach(bridge->encoder, pvi->next_bridge,
+bridge, flags);
+}
+
+static void imx8mp_hdmi_pvi_bridge_enable(struct drm_bridge *bridge,
+ struct drm_bridge_state *bridge_state)
+{
+ struct drm_atomic_state *state = bridge_state->base.state;
+ struct imx8mp_hdmi_pvi *pvi = to_imx8mp_hdmi_pvi(bridge);
+ struct drm_connector_state *conn_state;
+ const struct drm_display_mode *mode;
+ struct drm_crtc_state *crtc_state;
+ struct drm_connector *connector;
+ u32 bus_flags, val;
+
+ connector = drm_atomic_get_new_connector_for_encoder(state,
bridge->encoder);
+ conn_state = drm_atomic_get_new_connector_state(state, connector);
+ crtc_state = drm_atomic_get_new_crtc_state(state, conn_state->crtc);
+
+ if (WARN_ON(pm_runtime_resume_and_get(pvi->dev)))
+ return;
+
+ mode = &crtc_state->adjusted_mode;
+
+ val = FIELD_PREP(PVI_CTRL_MODE_MASK, PVI_CTRL_MODE_LCDIF) | PVI_CTRL_EN;
+
+ if (mode->flags & DRM_MODE_FLAG_PVSYNC)
+ val |= PVI_CTRL_OP_VSYNC_POL | PVI_CTRL_INP_VSYNC_POL;
+
+ if (mode->flags & DRM_MODE_FLAG_PHSYNC)
+ val |= PVI_CTRL_OP_HSYNC_POL | PVI_CTRL_INP_HSYNC_POL;
+
+ if (pvi->next_bridge->timings)
+ bus_flags = pvi->next_bridge->timings->input_bus_flags;
+ else if (bridge_state)
+ bus_flags = bridge_state->input_bus_cfg.flags;
+
+
[PATCH v3 1/2] dt-bindings: display: imx: add binding for i.MX8MP HDMI PVI
Add binding for the i.MX8MP HDMI parallel video interface block.
Signed-off-by: Lucas Stach
---
.../display/imx/fsl,imx8mp-hdmi-pvi.yaml | 80 +++
1 file changed, 80 insertions(+)
create mode 100644
Documentation/devicetree/bindings/display/imx/fsl,imx8mp-hdmi-pvi.yaml
diff --git
a/Documentation/devicetree/bindings/display/imx/fsl,imx8mp-hdmi-pvi.yaml
b/Documentation/devicetree/bindings/display/imx/fsl,imx8mp-hdmi-pvi.yaml
new file mode 100644
index ..12855bb3ed4c
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/imx/fsl,imx8mp-hdmi-pvi.yaml
@@ -0,0 +1,80 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/display/imx/fsl,imx8mp-hdmi-pvi.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Freescale i.MX8MP HDMI Parallel Video Interface
+
+maintainers:
+ - Lucas Stach
+
+description: |
+ The HDMI parallel video interface is a timing and sync generator block in the
+ i.MX8MP SoC, that sits between the video source and the HDMI TX controller.
+
+properties:
+ compatible:
+const: fsl,imx8mp-hdmi-pvi
+
+ reg:
+maxItems: 1
+
+ power-domains:
+maxItems: 1
+
+ ports:
+$ref: /schemas/graph.yaml#/properties/ports
+
+properties:
+ port@0:
+$ref: /schemas/graph.yaml#/properties/port
+description: Input from the LCDIF controller.
+
+ port@1:
+$ref: /schemas/graph.yaml#/properties/port
+description: Output to the HDMI TX controller.
+
+required:
+ - port@0
+ - port@1
+
+required:
+ - compatible
+ - reg
+ - interrupts
+ - power-domains
+ - ports
+
+additionalProperties: false
+
+examples:
+ - |
+#include
+#include
+
+display-bridge@32fc4000 {
+compatible = "fsl,imx8mp-hdmi-pvi";
+reg = <0x32fc4000 0x40>;
+interrupts = <12 IRQ_TYPE_LEVEL_HIGH>;
+power-domains = <&hdmi_blk_ctrl IMX8MP_HDMIBLK_PD_PVI>;
+
+ports {
+#address-cells = <1>;
+#size-cells = <0>;
+
+port@0 {
+reg = <0>;
+pvi_from_lcdif3: endpoint {
+remote-endpoint = <&lcdif3_to_pvi>;
+};
+};
+
+port@1 {
+reg = <1>;
+pvi_to_hdmi_tx: endpoint {
+remote-endpoint = <&hdmi_tx_from_pvi>;
+};
+};
+};
+};
--
2.39.2
Re: [PATCH v2] drm/bridge: panel: Fix device link for DRM_BRIDGE_ATTACH_NO_CONNECTOR
Hi, On Wed, 20 Sep 2023 10:27:27 +0200, AngeloGioacchino Del Regno wrote: > When external bridges are attached with DRM_BRIDGE_ATTACH_NO_CONNECTOR, > the panel bridge may also get the same flag, but in the .attach() > callback for the panel bridge a device link is added only when this > flag is not present; To make things worse, the .detach() callback > tries to delete the device link unconditionally and without checking > if it was created in the first place, crashing the kernel with a NULL > pointer kernel panic upon calling panel_bridge_detach(). > > [...] Thanks, Applied to https://anongit.freedesktop.org/git/drm/drm-misc.git (drm-misc-next) [1/1] drm/bridge: panel: Fix device link for DRM_BRIDGE_ATTACH_NO_CONNECTOR https://cgit.freedesktop.org/drm/drm-misc/commit/?id=887878014534186cc50dbd16a62e744ad217b4b1 -- Neil
Re: [PATCH v2 2/2] backlight: mp3309c: Add support for MPS MP3309C
On Fri, Sep 15, 2023 at 04:05:16PM +0200, Flavio Suligoi wrote:
> The Monolithic Power (MPS) MP3309C is a WLED step-up converter, featuring a
> programmable switching frequency to optimize efficiency.
> The brightness can be controlled either by I2C commands (called "analog"
> mode) or by a PWM input signal (PWM mode).
> This driver supports both modes.
>
> For DT configuration details, please refer to:
> - Documentation/devicetree/bindings/leds/backlight/mps,mp3309c.yaml
>
> The datasheet is available at:
> - https://www.monolithicpower.com/en/mp3309c.html
>
> Signed-off-by: Flavio Suligoi
> ---
>
> v2:
> - fix dependecies in Kconfig
> - fix Kconfig MP3309C entry order
> - remove switch-on-delay-ms property
> - remove optional gpio property to reset external devices
> - remove dimming-mode property (the analog-i2c dimming mode is the default;
> the
>presence of the pwms property, in DT, selects automatically the pwm dimming
>mode)
> - substitute three boolean properties, used for the overvoltage-protection
>values, with a single enum property
> - drop simple tracing messages
> - use dev_err_probe() in probe function
> - change device name from mp3309c_bl to the simple mp3309c
> - remove shutdown function
> v1:
> - first version
>
> MAINTAINERS | 6 +
> drivers/video/backlight/Kconfig | 11 +
> drivers/video/backlight/Makefile | 1 +
> drivers/video/backlight/mp3309c.c | 395 ++
> 4 files changed, 413 insertions(+)
> create mode 100644 drivers/video/backlight/mp3309c.c
>
> diff --git a/MAINTAINERS b/MAINTAINERS
> index 3be1bdfe8ecc..f779df433af1 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -14333,6 +14333,12 @@ S: Maintained
> F: Documentation/driver-api/tty/moxa-smartio.rst
> F: drivers/tty/mxser.*
>
> +MP3309C BACKLIGHT DRIVER
> +M: Flavio Suligoi
> +S: Maintained
> +F: Documentation/devicetree/bindings/leds/backlight/mps,mp3309c.yaml
> +F: drivers/video/backlight/mp3309c.c
> +
> MR800 AVERMEDIA USB FM RADIO DRIVER
> M: Alexey Klimov
> L: linux-me...@vger.kernel.org
> diff --git a/drivers/video/backlight/Kconfig b/drivers/video/backlight/Kconfig
> index 51387b1ef012..1144a54a35c0 100644
> --- a/drivers/video/backlight/Kconfig
> +++ b/drivers/video/backlight/Kconfig
> @@ -402,6 +402,17 @@ config BACKLIGHT_LP8788
> help
> This supports TI LP8788 backlight driver.
>
> +config BACKLIGHT_MP3309C
> + tristate "Backlight Driver for MPS MP3309C"
> + depends on I2C && PWM
> + select REGMAP_I2C
> + help
> + This supports MPS MP3309C backlight WLED driver in both PWM and
> + analog/I2C dimming modes.
> +
> + To compile this driver as a module, choose M here: the module will
> + be called mp3309c.
> +
> config BACKLIGHT_PANDORA
> tristate "Backlight driver for Pandora console"
> depends on TWL4030_CORE
> diff --git a/drivers/video/backlight/Makefile
> b/drivers/video/backlight/Makefile
> index f72e1c3c59e9..1af583de665b 100644
> --- a/drivers/video/backlight/Makefile
> +++ b/drivers/video/backlight/Makefile
> @@ -44,6 +44,7 @@ obj-$(CONFIG_BACKLIGHT_LP855X) += lp855x_bl.o
> obj-$(CONFIG_BACKLIGHT_LP8788) += lp8788_bl.o
> obj-$(CONFIG_BACKLIGHT_LV5207LP) += lv5207lp.o
> obj-$(CONFIG_BACKLIGHT_MAX8925) += max8925_bl.o
> +obj-$(CONFIG_BACKLIGHT_MP3309C) += mp3309c.o
> obj-$(CONFIG_BACKLIGHT_MT6370) += mt6370-backlight.o
> obj-$(CONFIG_BACKLIGHT_OMAP1)+= omap1_bl.o
> obj-$(CONFIG_BACKLIGHT_PANDORA) += pandora_bl.o
> diff --git a/drivers/video/backlight/mp3309c.c
> b/drivers/video/backlight/mp3309c.c
> new file mode 100644
> index ..470c960d7438
> --- /dev/null
> +++ b/drivers/video/backlight/mp3309c.c
> @@ -0,0 +1,395 @@
> +// SPDX-License-Identifier: GPL-2.0+
This is an obsolete spelling. Should be:
https://spdx.org/licenses/GPL-2.0-or-later.html
> +static int mp3309c_bl_update_status(struct backlight_device *bl)
> +{
> + struct mp3309c_chip *chip = bl_get_data(bl);
> + int brightness = backlight_get_brightness(bl);
> + struct pwm_state pwmstate;
> + unsigned int analog_val, bits_val;
> + int i, ret;
> +
> + if (chip->pdata->dimming_mode == DIMMING_PWM) {
> + /*
> + * PWM dimming mode
> + */
> + pwm_get_state(chip->pwmd, &pwmstate);
> + pwm_set_relative_duty_cycle(&pwmstate, brightness,
> + chip->pdata->max_brightness);
> + pwmstate.enabled = true;
> + ret = pwm_apply_state(chip->pwmd, &pwmstate);
> + if (ret)
> + return ret;
> +
> + switch (chip->pdata->status) {
> + case FIRST_POWER_ON:
> + case BACKLIGHT_OFF:
> + /*
> + * After 20ms of pwm off, we must enable t
Re: [PATCH drm-misc-next v4 6/8] drm/gpuvm: add drm_gpuvm_flags to drm_gpuvm
Hi Danilo,
kernel test robot noticed the following build warnings:
[auto build test WARNING on 1c7a387ffef894b1ab3942f0482dac7a6e0a909c]
url:
https://github.com/intel-lab-lkp/linux/commits/Danilo-Krummrich/drm-gpuvm-rename-struct-drm_gpuva_manager-to-struct-drm_gpuvm/20230920-224605
base: 1c7a387ffef894b1ab3942f0482dac7a6e0a909c
patch link:
https://lore.kernel.org/r/20230920144343.64830-7-dakr%40redhat.com
patch subject: [PATCH drm-misc-next v4 6/8] drm/gpuvm: add drm_gpuvm_flags to
drm_gpuvm
config: alpha-allyesconfig
(https://download.01.org/0day-ci/archive/20230921/202309210041.ypce0guk-...@intel.com/config)
compiler: alpha-linux-gcc (GCC) 13.2.0
reproduce (this is a W=1 build):
(https://download.01.org/0day-ci/archive/20230921/202309210041.ypce0guk-...@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/202309210041.ypce0guk-...@intel.com/
All warnings (new ones prefixed by >>):
>> drivers/gpu/drm/drm_gpuvm.c:712: warning: Function parameter or member
>> 'flags' not described in 'drm_gpuvm_init'
vim +712 drivers/gpu/drm/drm_gpuvm.c
e6303f323b1ad9 drivers/gpu/drm/drm_gpuva_mgr.c Danilo Krummrich 2023-07-20 689
e6303f323b1ad9 drivers/gpu/drm/drm_gpuva_mgr.c Danilo Krummrich 2023-07-20 690
/**
06f9274d201d5d drivers/gpu/drm/drm_gpuvm.c Danilo Krummrich 2023-09-20 691
* drm_gpuvm_init() - initialize a &drm_gpuvm
06f9274d201d5d drivers/gpu/drm/drm_gpuvm.c Danilo Krummrich 2023-09-20 692
* @gpuvm: pointer to the &drm_gpuvm to initialize
52ef25512ca721 drivers/gpu/drm/drm_gpuvm.c Danilo Krummrich 2023-09-20 693
* @drm: the drivers &drm_device
e6303f323b1ad9 drivers/gpu/drm/drm_gpuva_mgr.c Danilo Krummrich 2023-07-20 694
* @name: the name of the GPU VA space
e6303f323b1ad9 drivers/gpu/drm/drm_gpuva_mgr.c Danilo Krummrich 2023-07-20 695
* @start_offset: the start offset of the GPU VA space
e6303f323b1ad9 drivers/gpu/drm/drm_gpuva_mgr.c Danilo Krummrich 2023-07-20 696
* @range: the size of the GPU VA space
e6303f323b1ad9 drivers/gpu/drm/drm_gpuva_mgr.c Danilo Krummrich 2023-07-20 697
* @reserve_offset: the start of the kernel reserved GPU VA area
e6303f323b1ad9 drivers/gpu/drm/drm_gpuva_mgr.c Danilo Krummrich 2023-07-20 698
* @reserve_range: the size of the kernel reserved GPU VA area
06f9274d201d5d drivers/gpu/drm/drm_gpuvm.c Danilo Krummrich 2023-09-20 699
* @ops: &drm_gpuvm_ops called on &drm_gpuvm_sm_map / &drm_gpuvm_sm_unmap
e6303f323b1ad9 drivers/gpu/drm/drm_gpuva_mgr.c Danilo Krummrich 2023-07-20 700
*
06f9274d201d5d drivers/gpu/drm/drm_gpuvm.c Danilo Krummrich 2023-09-20 701
* The &drm_gpuvm must be initialized with this function before use.
e6303f323b1ad9 drivers/gpu/drm/drm_gpuva_mgr.c Danilo Krummrich 2023-07-20 702
*
06f9274d201d5d drivers/gpu/drm/drm_gpuvm.c Danilo Krummrich 2023-09-20 703
* Note that @gpuvm must be cleared to 0 before calling this function. The
given
e6303f323b1ad9 drivers/gpu/drm/drm_gpuva_mgr.c Danilo Krummrich 2023-07-20 704
* &name is expected to be managed by the surrounding driver structures.
e6303f323b1ad9 drivers/gpu/drm/drm_gpuva_mgr.c Danilo Krummrich 2023-07-20 705
*/
e6303f323b1ad9 drivers/gpu/drm/drm_gpuva_mgr.c Danilo Krummrich 2023-07-20 706
void
52ef25512ca721 drivers/gpu/drm/drm_gpuvm.c Danilo Krummrich 2023-09-20 707
drm_gpuvm_init(struct drm_gpuvm *gpuvm, struct drm_device *drm,
790facc6dac6ef drivers/gpu/drm/drm_gpuvm.c Danilo Krummrich 2023-09-20 708
const char *name, enum drm_gpuva_flags flags,
e6303f323b1ad9 drivers/gpu/drm/drm_gpuva_mgr.c Danilo Krummrich 2023-07-20 709
u64 start_offset, u64 range,
e6303f323b1ad9 drivers/gpu/drm/drm_gpuva_mgr.c Danilo Krummrich 2023-07-20 710
u64 reserve_offset, u64 reserve_range,
06f9274d201d5d drivers/gpu/drm/drm_gpuvm.c Danilo Krummrich 2023-09-20 711
const struct drm_gpuvm_ops *ops)
e6303f323b1ad9 drivers/gpu/drm/drm_gpuva_mgr.c Danilo Krummrich 2023-07-20 @712
{
06f9274d201d5d drivers/gpu/drm/drm_gpuvm.c Danilo Krummrich 2023-09-20 713
gpuvm->rb.tree = RB_ROOT_CACHED;
06f9274d201d5d drivers/gpu/drm/drm_gpuvm.c Danilo Krummrich 2023-09-20 714
INIT_LIST_HEAD(&gpuvm->rb.list);
e6303f323b1ad9 drivers/gpu/drm/drm_gpuva_mgr.c Danilo Krummrich 2023-07-20 715
06f9274d201d5d drivers/gpu/drm/drm_gpuvm.c Danilo Krummrich 2023-09-20 716
drm_gpuvm_check_overflow(start_offset, range);
06f9274d201d5d drivers/gpu/drm/drm_gpuvm.c Danilo Krummrich 2023-09-20 717
gpuvm->mm_start = start_offset;
06f9274d201d5d drivers/gpu/drm/drm_gpuvm.c Danilo Krummrich 2023-09-20 718
gpuvm->mm_range =
Re: Decrypting tt maps in ttm
On Wed, 2023-09-20 at 12:48 +0200, Christian König wrote: > !! External Email > > Am 20.09.23 um 09:36 schrieb Thomas Hellström: > > Hi, Zack, > > > > On 9/20/23 05:43, Zack Rusin wrote: > > > On Tue, 2023-09-19 at 09:47 +0200, Christian König wrote: > > > > !! External Email > > > > > > > > Am 19.09.23 um 08:56 schrieb Thomas Hellström: > > > > > On 9/19/23 07:39, Christian König wrote: > > > > > > Am 19.09.23 um 03:26 schrieb Zack Rusin: > > > > > > > On Mon, 2023-09-18 at 16:21 -0400, Alex Deucher wrote: > > > > > > > > !! External Email > > > > > > > > > > > > > > > > On Mon, Sep 18, 2023 at 3:06 PM Thomas Hellström > > > > > > > > wrote: > > > > > > > > > On 9/18/23 17:52, Zack Rusin wrote: > > > > > > > > > > On Mon, 2023-09-18 at 17:13 +0200, Thomas Hellström wrote: > > > > > > > > > > > Hi, > > > > > > > > > > > > > > > > > > > > > > On 9/18/23 16:56, Thomas Hellström wrote: > > > > > > > > > > > > Hi Zack, Christian > > > > > > > > > > > > > > > > > > > > > > > > On 9/18/23 13:36, Christian König wrote: > > > > > > > > > > > > > Hi Zack, > > > > > > > > > > > > > > > > > > > > > > > > > > adding Thomas and Daniel. > > > > > > > > > > > > > > > > > > > > > > > > > > I briefly remember that I talked with Thomas and some > > > > > > > > > > > > > other > > > > > > > > > > > > > people > > > > > > > > > > > > > about that quite a while ago as well, but I don't > > > > > > > > > > > > > fully > > > > > > > > > > > > > remember the > > > > > > > > > > > > > outcome. > > > > > > > > > > > > Found one old thread, but didn't read it: > > > > > > > > > > > > > > > > > > > > > > > > https://lists.freedesktop.org/archives/dri-devel/2019-September/234100.html > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > /Thomas > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Ugh. Now starting to read that thread I have a vague > > > > > > > > > > > recollection it all > > > > > > > > > > > ended with not supporting mapping any device pages > > > > > > > > > > > whatsoever > > > > > > > > > > > when SEV > > > > > > > > > > > was enabled, but rather resorting to llvmpipe and VM-local > > > > > > > > > > > bos. > > > > > > > > > > Hi, Thomas. > > > > > > > > > > > > > > > > > > > > Thanks for finding this! I'd (of course) like to solve it > > > > > > > > > > properly and get > > > > > > > > > > vmwgfx > > > > > > > > > > running with 3d support with SEV-ES active instead of > > > > > > > > > > essentially > > > > > > > > > > disabling > > > > > > > > > > the > > > > > > > > > > driver when SEV-ES is active. > > > > > > > > > > > > > > > > > > > > I think there are two separate discussions there, the > > > > > > > > > > non-controversial one > > > > > > > > > > and the > > > > > > > > > > controversial one: > > > > > > > > > > 1) The non-controversial: is there a case where drivers > > > > > > > > > > would > > > > > > > > > > want encrypted > > > > > > > > > > memory > > > > > > > > > > for TT pages but not for io mem mappings? Because if not > > > > > > > > > > then as > > > > > > > > > > Christian > > > > > > > > > > pointed > > > > > > > > > > out we could just add pgprot_decrypted to ttm_io_prot and be > > > > > > > > > > essentially done. > > > > > > > > > > The > > > > > > > > > > current method of decrypting io mem but leaving sys mem > > > > > > > > > > mappings > > > > > > > > > > encrypted is > > > > > > > > > > a bit > > > > > > > > > > weird anyway. > > > > > > > > > > > > > > > > > > > > If the answer to that question is "yes, some driver does > > > > > > > > > > want > > > > > > > > > > the > > > > > > > > > > TT mappings > > > > > > > > > > to be > > > > > > > > > > encrypted" then your "[PATCH v2 3/4] drm/ttm, drm/vmwgfx: > > > > > > > > > > Correctly support > > > > > > > > > > support > > > > > > > > > > AMD memory encryption" solves that. I think getting one of > > > > > > > > > > those > > > > > > > > > > two in makes > > > > > > > > > > sense > > > > > > > > > > regardless of everything else, agreed? > > > > > > > > > Well, there is more to it I think. > > > > > > > > > > > > > > > > > > IIRC, the AMD SME encryption mode has a way for a device to > > > > > > > > > have the > > > > > > > > > memory controller (?) encrypt / decrypt device traffic by > > > > > > > > > using an > > > > > > > > > address range alias, so in theory it supports encrypted TT > > > > > > > > > pages, and > > > > > > > > > the dma-layer may indeed hand encrypted DMA pages to TTM on > > > > > > > > > such > > > > > > > > > systems > > > > > > > > > depending on the device's DMA mask. That's why I think that > > > > > > > > > force_dma_unencrypted() export was needed, and If the amdgpu > > > > > > > > > driver > > > > > > > > > accesses TT memory in SME mode *without* pgprot_decrypted() > > > > > > > > > and it > > > > > > > > > still > > > > > > > > > works, then I think that mode is actually used. How could it > > > > > > > > > ot
Re: [PATCH] drm/meson: fix memory leak on ->hpd_notify callback
On Wed, 20 Sep 2023, Neil Armstrong wrote: > Hi, > > On Thu, 14 Sep 2023 16:10:15 +0300, Jani Nikula wrote: >> The EDID returned by drm_bridge_get_edid() needs to be freed. >> >> > > Thanks, Applied to https://anongit.freedesktop.org/git/drm/drm-misc.git > (drm-misc-fixes) > > [1/1] drm/meson: fix memory leak on ->hpd_notify callback > > https://cgit.freedesktop.org/drm/drm-misc/commit/?id=099f0af9d98231bb74956ce92508e87cbcb896be Thanks, Jani. -- Jani Nikula, Intel
Re: [PATCH v6 4/6] drm/drm_file: Add DRM obj's RSS reporting function for fdinfo
On 20/09/2023 00:34, Adrián Larumbe wrote:
Some BO's might be mapped onto physical memory chunkwise and on demand,
like Panfrost's tiler heap. In this case, even though the
drm_gem_shmem_object page array might already be allocated, only a very
small fraction of the BO is currently backed by system memory, but
drm_show_memory_stats will then proceed to add its entire virtual size to
the file's total resident size regardless.
This led to very unrealistic RSS sizes being reckoned for Panfrost, where
said tiler heap buffer is initially allocated with a virtual size of 128
MiB, but only a small part of it will eventually be backed by system memory
after successive GPU page faults.
Provide a new DRM object generic function that would allow drivers to
return a more accurate RSS size for their BOs.
Signed-off-by: Adrián Larumbe
Reviewed-by: Boris Brezillon
Reviewed-by: Steven Price
---
drivers/gpu/drm/drm_file.c | 5 -
include/drm/drm_gem.h | 9 +
2 files changed, 13 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/drm_file.c b/drivers/gpu/drm/drm_file.c
index 883d83bc0e3d..762965e3d503 100644
--- a/drivers/gpu/drm/drm_file.c
+++ b/drivers/gpu/drm/drm_file.c
@@ -944,7 +944,10 @@ void drm_show_memory_stats(struct drm_printer *p, struct
drm_file *file)
}
if (s & DRM_GEM_OBJECT_RESIDENT) {
- status.resident += obj->size;
+ if (obj->funcs && obj->funcs->rss)
+ status.resident += obj->funcs->rss(obj);
+ else
+ status.resident += obj->size;
Presumably you'd want the same smaller size in both active and
purgeable? Or you can end up with more in those two than in rss which
would look odd.
Also, alternative to adding a new callback could be adding multiple
output parameters to the existing obj->func->status() which maybe ends
up simpler due fewer callbacks?
Like:
s = obj->funcs->status(obj, &supported_status, &rss)
And adjust the code flow to pick up the rss if driver signaled it
supports reporting it.
Regards,
Tvrtko
} else {
/* If already purged or not yet backed by pages, don't
* count it as purgeable:
diff --git a/include/drm/drm_gem.h b/include/drm/drm_gem.h
index bc9f6aa2f3fe..16364487fde9 100644
--- a/include/drm/drm_gem.h
+++ b/include/drm/drm_gem.h
@@ -208,6 +208,15 @@ struct drm_gem_object_funcs {
*/
enum drm_gem_object_status (*status)(struct drm_gem_object *obj);
+ /**
+* @rss:
+*
+* Return resident size of the object in physical memory.
+*
+* Called by drm_show_memory_stats().
+*/
+ size_t (*rss)(struct drm_gem_object *obj);
+
/**
* @vm_ops:
*
Re: [PATCH v6 2/6] drm/panfrost: Add fdinfo support GPU load metrics
On 20/09/2023 00:34, Adrián Larumbe wrote:
The drm-stats fdinfo tags made available to user space are drm-engine,
drm-cycles, drm-max-freq and drm-curfreq, one per job slot.
This deviates from standard practice in other DRM drivers, where a single
set of key:value pairs is provided for the whole render engine. However,
Panfrost has separate queues for fragment and vertex/tiler jobs, so a
decision was made to calculate bus cycles and workload times separately.
Maximum operating frequency is calculated at devfreq initialisation time.
Current frequency is made available to user space because nvtop uses it
when performing engine usage calculations.
It is important to bear in mind that both GPU cycle and kernel time numbers
provided are at best rough estimations, and always reported in excess from
the actual figure because of two reasons:
- Excess time because of the delay between the end of a job processing,
the subsequent job IRQ and the actual time of the sample.
- Time spent in the engine queue waiting for the GPU to pick up the next
job.
To avoid race conditions during enablement/disabling, a reference counting
mechanism was introduced, and a job flag that tells us whether a given job
increased the refcount. This is necessary, because user space can toggle
cycle counting through a debugfs file, and a given job might have been in
flight by the time cycle counting was disabled.
The main goal of the debugfs cycle counter knob is letting tools like nvtop
or IGT's gputop switch it at any time, to avoid power waste in case no
engine usage measuring is necessary.
Signed-off-by: Adrián Larumbe
Reviewed-by: Boris Brezillon
Reviewed-by: Steven Price
---
drivers/gpu/drm/panfrost/Makefile | 2 +
drivers/gpu/drm/panfrost/panfrost_debugfs.c | 20
drivers/gpu/drm/panfrost/panfrost_debugfs.h | 13 +
drivers/gpu/drm/panfrost/panfrost_devfreq.c | 8 +++
drivers/gpu/drm/panfrost/panfrost_devfreq.h | 3 ++
drivers/gpu/drm/panfrost/panfrost_device.c | 2 +
drivers/gpu/drm/panfrost/panfrost_device.h | 13 +
drivers/gpu/drm/panfrost/panfrost_drv.c | 57 -
drivers/gpu/drm/panfrost/panfrost_gpu.c | 41 +++
drivers/gpu/drm/panfrost/panfrost_gpu.h | 4 ++
drivers/gpu/drm/panfrost/panfrost_job.c | 24 +
drivers/gpu/drm/panfrost/panfrost_job.h | 5 ++
12 files changed, 191 insertions(+), 1 deletion(-)
create mode 100644 drivers/gpu/drm/panfrost/panfrost_debugfs.c
create mode 100644 drivers/gpu/drm/panfrost/panfrost_debugfs.h
diff --git a/drivers/gpu/drm/panfrost/Makefile
b/drivers/gpu/drm/panfrost/Makefile
index 7da2b3f02ed9..2c01c1e7523e 100644
--- a/drivers/gpu/drm/panfrost/Makefile
+++ b/drivers/gpu/drm/panfrost/Makefile
@@ -12,4 +12,6 @@ panfrost-y := \
panfrost_perfcnt.o \
panfrost_dump.o
+panfrost-$(CONFIG_DEBUG_FS) += panfrost_debugfs.o
+
obj-$(CONFIG_DRM_PANFROST) += panfrost.o
diff --git a/drivers/gpu/drm/panfrost/panfrost_debugfs.c
b/drivers/gpu/drm/panfrost/panfrost_debugfs.c
new file mode 100644
index ..cc14eccba206
--- /dev/null
+++ b/drivers/gpu/drm/panfrost/panfrost_debugfs.c
@@ -0,0 +1,20 @@
+// SPDX-License-Identifier: GPL-2.0
+/* Copyright 2023 Collabora ltd. */
+
+#include
+#include
+#include
+#include
+#include
+
+#include "panfrost_device.h"
+#include "panfrost_gpu.h"
+#include "panfrost_debugfs.h"
+
+void panfrost_debugfs_init(struct drm_minor *minor)
+{
+ struct drm_device *dev = minor->dev;
+ struct panfrost_device *pfdev =
platform_get_drvdata(to_platform_device(dev->dev));
+
+ debugfs_create_atomic_t("profile", 0600, minor->debugfs_root,
&pfdev->profile_mode);
+}
diff --git a/drivers/gpu/drm/panfrost/panfrost_debugfs.h
b/drivers/gpu/drm/panfrost/panfrost_debugfs.h
new file mode 100644
index ..db1c158bcf2f
--- /dev/null
+++ b/drivers/gpu/drm/panfrost/panfrost_debugfs.h
@@ -0,0 +1,13 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+/*
+ * Copyright 2023 Collabora ltd.
+ */
+
+#ifndef PANFROST_DEBUGFS_H
+#define PANFROST_DEBUGFS_H
+
+#ifdef CONFIG_DEBUG_FS
+void panfrost_debugfs_init(struct drm_minor *minor);
+#endif
+
+#endif /* PANFROST_DEBUGFS_H */
diff --git a/drivers/gpu/drm/panfrost/panfrost_devfreq.c
b/drivers/gpu/drm/panfrost/panfrost_devfreq.c
index 58dfb15a8757..28caffc689e2 100644
--- a/drivers/gpu/drm/panfrost/panfrost_devfreq.c
+++ b/drivers/gpu/drm/panfrost/panfrost_devfreq.c
@@ -58,6 +58,7 @@ static int panfrost_devfreq_get_dev_status(struct device *dev,
spin_lock_irqsave(&pfdevfreq->lock, irqflags);
panfrost_devfreq_update_utilization(pfdevfreq);
+ pfdevfreq->current_frequency = status->current_frequency;
status->total_time = ktime_to_ns(ktime_add(pfdevfreq->busy_time,
pfdevfreq->idle_time));
@@ -117,6 +118,7 @@ int panfrost_devfreq_init(struct panfrost_device *pfdev)
struct devfreq *devfreq;
stru
Re: [PATCH v6 6/6] drm/drm-file: Show finer-grained BO sizes in drm_show_memory_stats
On 20/09/2023 00:34, Adrián Larumbe wrote:
The current implementation will try to pick the highest available size
display unit as soon as the BO size exceeds that of the previous
multiplier. That can lead to loss of precision in contexts of low memory
usage.
The new selection criteria try to preserve precision, whilst also
increasing the display unit selection threshold to render more accurate
values.
Signed-off-by: Adrián Larumbe
Reviewed-by: Boris Brezillon
Reviewed-by: Steven Price
---
drivers/gpu/drm/drm_file.c | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/drm_file.c b/drivers/gpu/drm/drm_file.c
index 762965e3d503..34cfa128ffe5 100644
--- a/drivers/gpu/drm/drm_file.c
+++ b/drivers/gpu/drm/drm_file.c
@@ -872,6 +872,8 @@ void drm_send_event(struct drm_device *dev, struct
drm_pending_event *e)
}
EXPORT_SYMBOL(drm_send_event);
+#define UPPER_UNIT_THRESHOLD 100
+
static void print_size(struct drm_printer *p, const char *stat,
const char *region, u64 sz)
{
@@ -879,7 +881,8 @@ static void print_size(struct drm_printer *p, const char
*stat,
unsigned u;
for (u = 0; u < ARRAY_SIZE(units) - 1; u++) {
- if (sz < SZ_1K)
+ if ((sz & (SZ_1K - 1)) &&
IS_ALIGNED worth it at all?
+ sz < UPPER_UNIT_THRESHOLD * SZ_1K)
break;
Excuse me for a late comment (I was away). I did not get what what is
special about a ~10% threshold? Sounds to me just going with the lower
unit, when size is not aligned to the higher one, would be better than
sometimes precision-sometimes-not.
Regards,
Tvrtko
sz = div_u64(sz, SZ_1K);
}
Re: [PATCH v2 14/15] dt-bindings: gpu: mali-valhall-csf: Add initial bindings for panthor driver
On 20/09/2023 16:25, Liviu Dudau wrote:
> On Wed, Sep 20, 2023 at 03:51:36PM +0200, Krzysztof Kozlowski wrote:
>> On 20/09/2023 15:41, Liviu Dudau wrote:
> +properties:
> + $nodename:
> +pattern: '^gpu@[a-f0-9]+$'
> +
> + compatible:
> +oneOf:
Drop oneOf.
>>>
>>> The idea was to allow for future compatible strings to be added later, but
>>> I guess we can re-introduce the oneOf entry later. Will remove it.
>>
>> If you already predict that new list will be added (so new fallback
>> compatible!), then it's fine.
>>
>>>
> + - items:
> + - enum:
> + - rockchip,rk3588-mali
> + - const: arm,mali-valhall-csf # Mali Valhall GPU
> model/revision is fully discoverable
> +
> + reg:
> +maxItems: 1
> +
> + interrupts:
> +items:
> + - description: Job interrupt
> + - description: MMU interrupt
> + - description: GPU interrupt
> +
> + interrupt-names:
> +items:
> + - const: job
> + - const: mmu
> + - const: gpu
> +
> + clocks:
> +minItems: 1
> +maxItems: 3
> +
> + clock-names:
> +minItems: 1
> +items:
> + - const: core
> + - const: coregroup
> + - const: stacks
> +
> + mali-supply: true
> +
> + sram-supply: true
> +
> + operating-points-v2: true
Missing opp-table.
>>>
>>> This is the main topic I want to clarify. See further down for the main
>>> comment,
>>> but I would like to understand what you are asking here. To copy the schema
>>> from bindings/opp/opp-v2.yaml and bindings/opp/opp-v2-base.yaml?
>>
>> No, "opp-table" property.
>> git grep "opp-table:"
>
> You mean adding
>
> opp-table:
>type: object
>
> as property? What's the difference between opp-table: true (like in
> 'display/msm/dp-controller.yaml') and 'opp-table: type: object' like in other
There is no opp-table: true. Nowhere.
...
>>>
> +};
> +
> +gpu_opp_table: opp-table {
Opp table should be inside the device node.
>>>
>>> I cannot find any device tree that supports your suggested usage. Most
>>> (all?) of
>>
>> Really? All Qcom have it embedded.
>
> The arm,mali-* ones seem to have them outside the gpu node. See
> "arm,mali-midgard.yaml"
You said you cannot find any, so I pointed out that's not true.
Best regards,
Krzysztof
Re: [PATCH v4 0/5] ppc, fbdev: Clean up fbdev mmap helper
On Tue, Sep 12, 2023, at 09:48, Thomas Zimmermann wrote: > Clean up and rename fb_pgprotect() to work without struct file. Then > refactor the implementation for PowerPC. This change has been discussed > at [1] in the context of refactoring fbdev's mmap code. > > The first two patches update fbdev and replace fbdev's fb_pgprotect() > with pgprot_framebuffer() on all architectures. The new helper's stream- > lined interface enables more refactoring within fbdev's mmap > implementation. > > Patches 3 to 5 adapt PowerPC's internal interfaces to provide > phys_mem_access_prot() that works without struct file. Neither the > architecture code or fbdev helpers need the parameter. > > v4: > * fix commit message (Christophe) > v3: > * rename fb_pgrotect() to pgprot_framebuffer() (Arnd) I had another look today, and everything look good to me now. Whole series Reviewed-by: Arnd Bergmann
[PATCH drm-misc-next v4 7/8] drm/gpuvm: generalize dma_resv/extobj handling and GEM validation
So far the DRM GPUVA manager offers common infrastructure to track GPU VA allocations and mappings, generically connect GPU VA mappings to their backing buffers and perform more complex mapping operations on the GPU VA space. However, there are more design patterns commonly used by drivers, which can potentially be generalized in order to make the DRM GPUVA manager represent a basic GPU-VM implementation. In this context, this patch aims at generalizing the following elements. 1) Provide a common dma-resv for GEM objects not being used outside of this GPU-VM. 2) Provide tracking of external GEM objects (GEM objects which are shared with other GPU-VMs). 3) Provide functions to efficiently lock all GEM objects dma-resv the GPU-VM contains mappings of. 4) Provide tracking of evicted GEM objects the GPU-VM contains mappings of, such that validation of evicted GEM objects is accelerated. 5) Provide some convinience functions for common patterns. Rather than being designed as a "framework", the target is to make all features appear as a collection of optional helper functions, such that drivers are free to make use of the DRM GPUVA managers basic functionality and opt-in for other features without setting any feature flags, just by making use of the corresponding functions. Big thanks to Boris Brezillon for his help to figure out locking for drivers updating the GPU VA space within the fence signalling path. Suggested-by: Matthew Brost Signed-off-by: Danilo Krummrich --- drivers/gpu/drm/drm_gpuvm.c | 627 include/drm/drm_gpuvm.h | 268 ++- 2 files changed, 894 insertions(+), 1 deletion(-) diff --git a/drivers/gpu/drm/drm_gpuvm.c b/drivers/gpu/drm/drm_gpuvm.c index 6e9d2d478bb8..6cac90023efc 100644 --- a/drivers/gpu/drm/drm_gpuvm.c +++ b/drivers/gpu/drm/drm_gpuvm.c @@ -73,6 +73,21 @@ * &drm_gem_object list of &drm_gpuvm_bos for an existing instance of this * particular combination. If not existent a new instance is created and linked * to the &drm_gem_object. + * + * &drm_gpuvm_bo structures, since unique for a given &drm_gpuvm, are also used + * as entry for the &drm_gpuvm's lists of external and evicted objects. Those + * list are maintained in order to accelerate locking of dma-resv locks and + * validation of evicted objects bound in a &drm_gpuvm. For instance the all + * &drm_gem_object's &dma_resv of a given &drm_gpuvm can be locked by calling + * drm_gpuvm_exec_lock(). Once locked drivers can call drm_gpuvm_validate() in + * order to validate all evicted &drm_gem_objects. It is also possible to lock + * additional &drm_gem_objects by providing the corresponding parameters to + * drm_gpuvm_exec_lock() as well as open code the &drm_exec loop while making + * use of helper functions such as drm_gpuvm_prepare_range() or + * drm_gpuvm_prepare_objects(). + * + * Every bound &drm_gem_object is treated as external object when its &dma_resv + * structure is different than the &drm_gpuvm's common &dma_resv structure. */ /** @@ -420,6 +435,21 @@ * Subsequent calls to drm_gpuvm_bo_obtain() for the same &drm_gpuvm and * &drm_gem_object must be able to observe previous creations and destructions * of &drm_gpuvm_bos in order to keep instances unique. + * + * The &drm_gpuvm's lists for keeping track of external and evicted objects are + * protected against concurrent insertion / removal and iteration internally. + * + * However, drivers still need ensure to protect concurrent calls to functions + * iterating those lists, such as drm_gpuvm_validate() and + * drm_gpuvm_prepare_objects(). Every such function contains a particular + * comment and lockdep checks if possible. + * + * Alternatively, drivers can set the &DRM_GPUVM_RESV_PROTECTED flag indicate + * that the corresponding &dma_resv locks are held in order to protect the + * lists. If &DRM_GPUVM_RESV_PROTECTED is set, internal locking is disabled and + * the corresponding lockdep checks are enabled. This is an optimization for + * drivers which are capable of taking the corresponding &dma_resv locks and + * hence do not require internal locking. */ /** @@ -632,6 +662,195 @@ * } */ +/** + * get_next_vm_bo_from_list() - get the next vm_bo element + * @__gpuvm: The GPU VM + * @__list_name: The name of the list we're iterating on + * @__local_list: A pointer to the local list used to store already iterated items + * @__prev_vm_bo: The previous element we got from drm_gpuvm_get_next_cached_vm_bo() + * + * This helper is here to provide lockless list iteration. Lockless as in, the + * iterator releases the lock immediately after picking the first element from + * the list, so list insertion deletion can happen concurrently. + * + * Elements popped from the original list are kept in a local list, so removal + * and is_empty checks can still happen while we're iterating the list. + */ +#define get_next_vm_bo_from_list(__gpuvm, __list_name, __local_list, __prev_vm_
[PATCH drm-misc-next v4 8/8] drm/nouveau: GPUVM dma-resv/extobj handling, GEM validation
Make use of the DRM GPUVA managers GPU-VM common dma-resv, external GEM
object tracking, dma-resv locking, evicted GEM object tracking and
validation features.
Signed-off-by: Danilo Krummrich
---
drivers/gpu/drm/nouveau/nouveau_bo.c| 4 +-
drivers/gpu/drm/nouveau/nouveau_exec.c | 52 +++--
drivers/gpu/drm/nouveau/nouveau_exec.h | 4 -
drivers/gpu/drm/nouveau/nouveau_gem.c | 5 +-
drivers/gpu/drm/nouveau/nouveau_sched.h | 4 +-
drivers/gpu/drm/nouveau/nouveau_uvmm.c | 99 -
6 files changed, 83 insertions(+), 85 deletions(-)
diff --git a/drivers/gpu/drm/nouveau/nouveau_bo.c
b/drivers/gpu/drm/nouveau/nouveau_bo.c
index 19cab37ac69c..52d3f7eba011 100644
--- a/drivers/gpu/drm/nouveau/nouveau_bo.c
+++ b/drivers/gpu/drm/nouveau/nouveau_bo.c
@@ -1060,17 +1060,18 @@ nouveau_bo_move(struct ttm_buffer_object *bo, bool
evict,
{
struct nouveau_drm *drm = nouveau_bdev(bo->bdev);
struct nouveau_bo *nvbo = nouveau_bo(bo);
+ struct drm_gem_object *obj = &bo->base;
struct ttm_resource *old_reg = bo->resource;
struct nouveau_drm_tile *new_tile = NULL;
int ret = 0;
-
if (new_reg->mem_type == TTM_PL_TT) {
ret = nouveau_ttm_tt_bind(bo->bdev, bo->ttm, new_reg);
if (ret)
return ret;
}
+ drm_gpuvm_bo_gem_evict(obj, evict);
nouveau_bo_move_ntfy(bo, new_reg);
ret = ttm_bo_wait_ctx(bo, ctx);
if (ret)
@@ -1135,6 +1136,7 @@ nouveau_bo_move(struct ttm_buffer_object *bo, bool evict,
out_ntfy:
if (ret) {
nouveau_bo_move_ntfy(bo, bo->resource);
+ drm_gpuvm_bo_gem_evict(obj, !evict);
}
return ret;
}
diff --git a/drivers/gpu/drm/nouveau/nouveau_exec.c
b/drivers/gpu/drm/nouveau/nouveau_exec.c
index b4239af29e5a..ba6913a3efb6 100644
--- a/drivers/gpu/drm/nouveau/nouveau_exec.c
+++ b/drivers/gpu/drm/nouveau/nouveau_exec.c
@@ -1,7 +1,5 @@
// SPDX-License-Identifier: MIT
-#include
-
#include "nouveau_drv.h"
#include "nouveau_gem.h"
#include "nouveau_mem.h"
@@ -91,9 +89,6 @@ nouveau_exec_job_submit(struct nouveau_job *job)
struct nouveau_exec_job *exec_job = to_nouveau_exec_job(job);
struct nouveau_cli *cli = job->cli;
struct nouveau_uvmm *uvmm = nouveau_cli_uvmm(cli);
- struct drm_exec *exec = &job->exec;
- struct drm_gem_object *obj;
- unsigned long index;
int ret;
ret = nouveau_fence_new(&exec_job->fence);
@@ -101,52 +96,29 @@ nouveau_exec_job_submit(struct nouveau_job *job)
return ret;
nouveau_uvmm_lock(uvmm);
- drm_exec_init(exec, DRM_EXEC_INTERRUPTIBLE_WAIT |
- DRM_EXEC_IGNORE_DUPLICATES);
- drm_exec_until_all_locked(exec) {
- struct drm_gpuva *va;
-
- drm_gpuvm_for_each_va(va, &uvmm->base) {
- if (unlikely(va == &uvmm->base.kernel_alloc_node))
- continue;
-
- ret = drm_exec_prepare_obj(exec, va->gem.obj, 1);
- drm_exec_retry_on_contention(exec);
- if (ret)
- goto err_uvmm_unlock;
- }
+ job->vm_exec.vm = &uvmm->base;
+ ret = drm_gpuvm_exec_lock(&job->vm_exec, 1, false);
+ if (ret) {
+ nouveau_uvmm_unlock(uvmm);
+ return ret;
}
nouveau_uvmm_unlock(uvmm);
- drm_exec_for_each_locked_object(exec, index, obj) {
- struct nouveau_bo *nvbo = nouveau_gem_object(obj);
-
- ret = nouveau_bo_validate(nvbo, true, false);
- if (ret)
- goto err_exec_fini;
+ ret = drm_gpuvm_exec_validate(&job->vm_exec);
+ if (ret) {
+ drm_gpuvm_exec_unlock(&job->vm_exec);
+ return ret;
}
return 0;
-
-err_uvmm_unlock:
- nouveau_uvmm_unlock(uvmm);
-err_exec_fini:
- drm_exec_fini(exec);
- return ret;
-
}
static void
nouveau_exec_job_armed_submit(struct nouveau_job *job)
{
- struct drm_exec *exec = &job->exec;
- struct drm_gem_object *obj;
- unsigned long index;
-
- drm_exec_for_each_locked_object(exec, index, obj)
- dma_resv_add_fence(obj->resv, job->done_fence, job->resv_usage);
-
- drm_exec_fini(exec);
+ drm_gpuvm_exec_resv_add_fence(&job->vm_exec, job->done_fence,
+ job->resv_usage, job->resv_usage);
+ drm_gpuvm_exec_unlock(&job->vm_exec);
}
static struct dma_fence *
diff --git a/drivers/gpu/drm/nouveau/nouveau_exec.h
b/drivers/gpu/drm/nouveau/nouveau_exec.h
index 778cacd90f65..b815de2428f3 100644
--- a/drivers/gpu/drm/nouveau/nouveau_exec.h
+++ b/drivers/gpu/drm/nouveau/nouveau_exec.h
@@ -3,16 +3,12 @@
#ifndef __NOUVEAU_EXEC_H__
#define __NOUVEAU_EXEC_H__
-#include
-
#include "nouveau_drv.h
[PATCH drm-misc-next v4 6/8] drm/gpuvm: add drm_gpuvm_flags to drm_gpuvm
Introduce flags for struct drm_gpuvm, this required by subsequent
commits.
Signed-off-by: Danilo Krummrich
---
drivers/gpu/drm/drm_gpuvm.c| 3 ++-
drivers/gpu/drm/nouveau/nouveau_uvmm.c | 2 +-
include/drm/drm_gpuvm.h| 17 -
3 files changed, 19 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/drm_gpuvm.c b/drivers/gpu/drm/drm_gpuvm.c
index 6ee224e1121e..6e9d2d478bb8 100644
--- a/drivers/gpu/drm/drm_gpuvm.c
+++ b/drivers/gpu/drm/drm_gpuvm.c
@@ -705,7 +705,7 @@ drm_gpuva_range_valid(struct drm_gpuvm *gpuvm,
*/
void
drm_gpuvm_init(struct drm_gpuvm *gpuvm, struct drm_device *drm,
- const char *name,
+ const char *name, enum drm_gpuva_flags flags,
u64 start_offset, u64 range,
u64 reserve_offset, u64 reserve_range,
const struct drm_gpuvm_ops *ops)
@@ -718,6 +718,7 @@ drm_gpuvm_init(struct drm_gpuvm *gpuvm, struct drm_device
*drm,
gpuvm->mm_range = range;
gpuvm->name = name ? name : "unknown";
+ gpuvm->flags = flags;
gpuvm->ops = ops;
memset(&gpuvm->kernel_alloc_node, 0, sizeof(struct drm_gpuva));
diff --git a/drivers/gpu/drm/nouveau/nouveau_uvmm.c
b/drivers/gpu/drm/nouveau/nouveau_uvmm.c
index cf709afd2ac7..3de8533841db 100644
--- a/drivers/gpu/drm/nouveau/nouveau_uvmm.c
+++ b/drivers/gpu/drm/nouveau/nouveau_uvmm.c
@@ -1864,7 +1864,7 @@ nouveau_uvmm_init(struct nouveau_uvmm *uvmm, struct
nouveau_cli *cli,
uvmm->kernel_managed_addr = kernel_managed_addr;
uvmm->kernel_managed_size = kernel_managed_size;
- drm_gpuvm_init(&uvmm->base, cli->drm->dev, cli->name,
+ drm_gpuvm_init(&uvmm->base, cli->drm->dev, cli->name, 0,
NOUVEAU_VA_SPACE_START,
NOUVEAU_VA_SPACE_END,
kernel_managed_addr, kernel_managed_size,
diff --git a/include/drm/drm_gpuvm.h b/include/drm/drm_gpuvm.h
index 2c9ad6eb9401..f57ad1f0f0d0 100644
--- a/include/drm/drm_gpuvm.h
+++ b/include/drm/drm_gpuvm.h
@@ -192,6 +192,16 @@ static inline bool drm_gpuva_invalidated(struct drm_gpuva
*va)
return va->flags & DRM_GPUVA_INVALIDATED;
}
+/**
+ * enum drm_gpuvm_flags - flags for struct drm_gpuvm
+ */
+enum drm_gpuvm_flags {
+ /**
+* @DRM_GPUVM_USERBITS: user defined bits
+*/
+ DRM_GPUVM_USERBITS = (1 << 0),
+};
+
/**
* struct drm_gpuvm - DRM GPU VA Manager
*
@@ -210,6 +220,11 @@ struct drm_gpuvm {
*/
const char *name;
+ /**
+* @flags: the &drm_gpuvm_flags of this GPUVM
+*/
+ enum drm_gpuva_flags flags;
+
/**
* @mm_start: start of the VA space
*/
@@ -256,7 +271,7 @@ struct drm_gpuvm {
};
void drm_gpuvm_init(struct drm_gpuvm *gpuvm, struct drm_device *drm,
- const char *name,
+ const char *name, enum drm_gpuva_flags flags,
u64 start_offset, u64 range,
u64 reserve_offset, u64 reserve_range,
const struct drm_gpuvm_ops *ops);
--
2.41.0
[PATCH drm-misc-next v4 5/8] drm/gpuvm: add an abstraction for a VM / BO combination
This patch adds an abstraction layer between the drm_gpuva mappings of
a particular drm_gem_object and this GEM object itself. The abstraction
represents a combination of a drm_gem_object and drm_gpuvm. The
drm_gem_object holds a list of drm_gpuvm_bo structures (the structure
representing this abstraction), while each drm_gpuvm_bo contains list of
mappings of this GEM object.
This has multiple advantages:
1) We can use the drm_gpuvm_bo structure to attach it to various lists
of the drm_gpuvm. This is useful for tracking external and evicted
objects per VM, which is introduced in subsequent patches.
2) Finding mappings of a certain drm_gem_object mapped in a certain
drm_gpuvm becomes much cheaper.
3) Drivers can derive and extend the structure to easily represent
driver specific states of a BO for a certain GPUVM.
The idea of this abstraction was taken from amdgpu, hence the credit for
this idea goes to the developers of amdgpu.
Cc: Christian König
Signed-off-by: Danilo Krummrich
---
drivers/gpu/drm/drm_gpuvm.c| 309 ++---
drivers/gpu/drm/nouveau/nouveau_uvmm.c | 68 --
include/drm/drm_gem.h | 32 +--
include/drm/drm_gpuvm.h| 149 +++-
4 files changed, 483 insertions(+), 75 deletions(-)
diff --git a/drivers/gpu/drm/drm_gpuvm.c b/drivers/gpu/drm/drm_gpuvm.c
index cbf4b738a16c..6ee224e1121e 100644
--- a/drivers/gpu/drm/drm_gpuvm.c
+++ b/drivers/gpu/drm/drm_gpuvm.c
@@ -61,6 +61,18 @@
* contained within struct drm_gpuva already. Hence, for inserting &drm_gpuva
* entries from within dma-fence signalling critical sections it is enough to
* pre-allocate the &drm_gpuva structures.
+ *
+ * In order to connect a struct drm_gpuva its backing &drm_gem_object each
+ * &drm_gem_object maintains a list of &drm_gpuvm_bo structures, and each
+ * &drm_gpuvm_bo contains a list of &&drm_gpuva structures.
+ *
+ * A &drm_gpuvm_bo is an abstraction that represents a combination of a
+ * &drm_gpuvm and a &drm_gem_object. Every such combination should be unique.
+ * This is ensured by the API through drm_gpuvm_bo_obtain() and
+ * drm_gpuvm_bo_obtain_prealloc() which first look into the corresponding
+ * &drm_gem_object list of &drm_gpuvm_bos for an existing instance of this
+ * particular combination. If not existent a new instance is created and linked
+ * to the &drm_gem_object.
*/
/**
@@ -393,14 +405,21 @@
* split / merge or prefetch.
*
* The GPU VA manager also does not take care of the locking of the backing
- * &drm_gem_object buffers GPU VA lists by itself; drivers are responsible to
- * enforce mutual exclusion using either the GEMs dma_resv lock or
alternatively
- * a driver specific external lock. For the latter see also
- * drm_gem_gpuva_set_lock().
+ * &drm_gem_object buffers GPU VA lists and &drm_gpuvm_bo abstractions by
+ * itself; drivers are responsible to enforce mutual exclusion using either the
+ * GEMs dma_resv lock or alternatively a driver specific external lock. For the
+ * latter see also drm_gem_gpuva_set_lock().
*
* However, the GPU VA manager contains lockdep checks to ensure callers of its
* API hold the corresponding lock whenever the &drm_gem_objects GPU VA list is
- * accessed by functions such as drm_gpuva_link() or drm_gpuva_unlink().
+ * accessed by functions such as drm_gpuva_link() or drm_gpuva_unlink(), but
+ * also drm_gpuvm_bo_obtain() and drm_gpuvm_bo_put().
+ *
+ * The latter is required since on creation and destruction of a &drm_gpuvm_bo
+ * the &drm_gpuvm_bo is attached / removed from the &drm_gem_objects gpuva
list.
+ * Subsequent calls to drm_gpuvm_bo_obtain() for the same &drm_gpuvm and
+ * &drm_gem_object must be able to observe previous creations and destructions
+ * of &drm_gpuvm_bos in order to keep instances unique.
*/
/**
@@ -430,6 +449,7 @@
* {
* struct drm_gpuva_ops *ops;
* struct drm_gpuva_op *op
+ * struct drm_gpuvm_bo *vm_bo;
*
* driver_lock_va_space();
* ops = drm_gpuvm_sm_map_ops_create(gpuvm, addr, range,
@@ -437,6 +457,10 @@
* if (IS_ERR(ops))
* return PTR_ERR(ops);
*
+ * vm_bo = drm_gpuvm_bo_obtain(gpuvm, obj);
+ * if (IS_ERR(vm_bo))
+ * return PTR_ERR(vm_bo);
+ *
* drm_gpuva_for_each_op(op, ops) {
* struct drm_gpuva *va;
*
@@ -449,7 +473,7 @@
*
* driver_vm_map();
* drm_gpuva_map(gpuvm, va, &op->map);
- * drm_gpuva_link(va);
+ * drm_gpuva_link(va, vm_bo);
*
* break;
* case DRM_GPUVA_OP_REMAP: {
@@ -476,11 +500,11 @@
* driver_vm_remap();
* drm_gpuva_remap(prev, next, &op->remap);
*
- * drm_gpu
[PATCH drm-misc-next v4 3/8] drm/nouveau: uvmm: rename 'umgr' to 'base'
Rename struct drm_gpuvm within struct nouveau_uvmm from 'umgr' to base.
Signed-off-by: Danilo Krummrich
---
drivers/gpu/drm/nouveau/nouveau_debugfs.c | 2 +-
drivers/gpu/drm/nouveau/nouveau_exec.c| 4 +--
drivers/gpu/drm/nouveau/nouveau_uvmm.c| 32 +++
drivers/gpu/drm/nouveau/nouveau_uvmm.h| 6 ++---
4 files changed, 22 insertions(+), 22 deletions(-)
diff --git a/drivers/gpu/drm/nouveau/nouveau_debugfs.c
b/drivers/gpu/drm/nouveau/nouveau_debugfs.c
index 053f703f2f68..e83db051e851 100644
--- a/drivers/gpu/drm/nouveau/nouveau_debugfs.c
+++ b/drivers/gpu/drm/nouveau/nouveau_debugfs.c
@@ -231,7 +231,7 @@ nouveau_debugfs_gpuva(struct seq_file *m, void *data)
continue;
nouveau_uvmm_lock(uvmm);
- drm_debugfs_gpuva_info(m, &uvmm->umgr);
+ drm_debugfs_gpuva_info(m, &uvmm->base);
seq_puts(m, "\n");
nouveau_debugfs_gpuva_regions(m, uvmm);
nouveau_uvmm_unlock(uvmm);
diff --git a/drivers/gpu/drm/nouveau/nouveau_exec.c
b/drivers/gpu/drm/nouveau/nouveau_exec.c
index c001952cd678..b4239af29e5a 100644
--- a/drivers/gpu/drm/nouveau/nouveau_exec.c
+++ b/drivers/gpu/drm/nouveau/nouveau_exec.c
@@ -106,8 +106,8 @@ nouveau_exec_job_submit(struct nouveau_job *job)
drm_exec_until_all_locked(exec) {
struct drm_gpuva *va;
- drm_gpuvm_for_each_va(va, &uvmm->umgr) {
- if (unlikely(va == &uvmm->umgr.kernel_alloc_node))
+ drm_gpuvm_for_each_va(va, &uvmm->base) {
+ if (unlikely(va == &uvmm->base.kernel_alloc_node))
continue;
ret = drm_exec_prepare_obj(exec, va->gem.obj, 1);
diff --git a/drivers/gpu/drm/nouveau/nouveau_uvmm.c
b/drivers/gpu/drm/nouveau/nouveau_uvmm.c
index c750072cb268..6c86b64273c3 100644
--- a/drivers/gpu/drm/nouveau/nouveau_uvmm.c
+++ b/drivers/gpu/drm/nouveau/nouveau_uvmm.c
@@ -329,7 +329,7 @@ nouveau_uvma_region_create(struct nouveau_uvmm *uvmm,
struct nouveau_uvma_region *reg;
int ret;
- if (!drm_gpuva_interval_empty(&uvmm->umgr, addr, range))
+ if (!drm_gpuva_interval_empty(&uvmm->base, addr, range))
return -ENOSPC;
ret = nouveau_uvma_region_alloc(®);
@@ -384,7 +384,7 @@ nouveau_uvma_region_empty(struct nouveau_uvma_region *reg)
{
struct nouveau_uvmm *uvmm = reg->uvmm;
- return drm_gpuva_interval_empty(&uvmm->umgr,
+ return drm_gpuva_interval_empty(&uvmm->base,
reg->va.addr,
reg->va.range);
}
@@ -589,7 +589,7 @@ op_map_prepare(struct nouveau_uvmm *uvmm,
uvma->region = args->region;
uvma->kind = args->kind;
- drm_gpuva_map(&uvmm->umgr, &uvma->va, op);
+ drm_gpuva_map(&uvmm->base, &uvma->va, op);
/* Keep a reference until this uvma is destroyed. */
nouveau_uvma_gem_get(uvma);
@@ -1194,7 +1194,7 @@ nouveau_uvmm_bind_job_submit(struct nouveau_job *job)
goto unwind_continue;
}
- op->ops = drm_gpuvm_sm_unmap_ops_create(&uvmm->umgr,
+ op->ops = drm_gpuvm_sm_unmap_ops_create(&uvmm->base,
op->va.addr,
op->va.range);
if (IS_ERR(op->ops)) {
@@ -1205,7 +1205,7 @@ nouveau_uvmm_bind_job_submit(struct nouveau_job *job)
ret = nouveau_uvmm_sm_unmap_prepare(uvmm, &op->new,
op->ops);
if (ret) {
- drm_gpuva_ops_free(&uvmm->umgr, op->ops);
+ drm_gpuva_ops_free(&uvmm->base, op->ops);
op->ops = NULL;
op->reg = NULL;
goto unwind_continue;
@@ -1240,7 +1240,7 @@ nouveau_uvmm_bind_job_submit(struct nouveau_job *job)
}
}
- op->ops = drm_gpuvm_sm_map_ops_create(&uvmm->umgr,
+ op->ops = drm_gpuvm_sm_map_ops_create(&uvmm->base,
op->va.addr,
op->va.range,
op->gem.obj,
@@ -1256,7 +1256,7 @@ nouveau_uvmm_bind_job_submit(struct nouveau_job *job)
op->va.range,
op->flags & 0xff);
if (ret) {
- drm_gpuva_ops_free(&uvmm->umgr, op->ops);
+ drm_gpuva_ops_fr
[PATCH drm-misc-next v4 4/8] drm/gpuvm: add common dma-resv per struct drm_gpuvm
Provide a common dma-resv for GEM objects not being used outside of this
GPU-VM. This is used in a subsequent patch to generalize dma-resv,
external and evicted object handling and GEM validation.
Signed-off-by: Danilo Krummrich
---
drivers/gpu/drm/drm_gpuvm.c| 9 +++--
drivers/gpu/drm/nouveau/nouveau_uvmm.c | 2 +-
include/drm/drm_gpuvm.h| 17 -
3 files changed, 24 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/drm_gpuvm.c b/drivers/gpu/drm/drm_gpuvm.c
index bfea4a8a19ec..cbf4b738a16c 100644
--- a/drivers/gpu/drm/drm_gpuvm.c
+++ b/drivers/gpu/drm/drm_gpuvm.c
@@ -655,6 +655,7 @@ drm_gpuva_range_valid(struct drm_gpuvm *gpuvm,
/**
* drm_gpuvm_init() - initialize a &drm_gpuvm
* @gpuvm: pointer to the &drm_gpuvm to initialize
+ * @drm: the drivers &drm_device
* @name: the name of the GPU VA space
* @start_offset: the start offset of the GPU VA space
* @range: the size of the GPU VA space
@@ -668,7 +669,7 @@ drm_gpuva_range_valid(struct drm_gpuvm *gpuvm,
* &name is expected to be managed by the surrounding driver structures.
*/
void
-drm_gpuvm_init(struct drm_gpuvm *gpuvm,
+drm_gpuvm_init(struct drm_gpuvm *gpuvm, struct drm_device *drm,
const char *name,
u64 start_offset, u64 range,
u64 reserve_offset, u64 reserve_range,
@@ -694,6 +695,8 @@ drm_gpuvm_init(struct drm_gpuvm *gpuvm,
reserve_range)))
__drm_gpuva_insert(gpuvm, &gpuvm->kernel_alloc_node);
}
+
+ drm_gem_private_object_init(drm, &gpuvm->d_obj, 0);
}
EXPORT_SYMBOL_GPL(drm_gpuvm_init);
@@ -713,7 +716,9 @@ drm_gpuvm_destroy(struct drm_gpuvm *gpuvm)
__drm_gpuva_remove(&gpuvm->kernel_alloc_node);
WARN(!RB_EMPTY_ROOT(&gpuvm->rb.tree.rb_root),
-"GPUVA tree is not empty, potentially leaking memory.");
+"GPUVA tree is not empty, potentially leaking memory.\n");
+
+ drm_gem_private_object_fini(&gpuvm->d_obj);
}
EXPORT_SYMBOL_GPL(drm_gpuvm_destroy);
diff --git a/drivers/gpu/drm/nouveau/nouveau_uvmm.c
b/drivers/gpu/drm/nouveau/nouveau_uvmm.c
index 6c86b64273c3..a80ac8767843 100644
--- a/drivers/gpu/drm/nouveau/nouveau_uvmm.c
+++ b/drivers/gpu/drm/nouveau/nouveau_uvmm.c
@@ -1836,7 +1836,7 @@ nouveau_uvmm_init(struct nouveau_uvmm *uvmm, struct
nouveau_cli *cli,
uvmm->kernel_managed_addr = kernel_managed_addr;
uvmm->kernel_managed_size = kernel_managed_size;
- drm_gpuvm_init(&uvmm->base, cli->name,
+ drm_gpuvm_init(&uvmm->base, cli->drm->dev, cli->name,
NOUVEAU_VA_SPACE_START,
NOUVEAU_VA_SPACE_END,
kernel_managed_addr, kernel_managed_size,
diff --git a/include/drm/drm_gpuvm.h b/include/drm/drm_gpuvm.h
index 0e802676e0a9..c07d7c3e 100644
--- a/include/drm/drm_gpuvm.h
+++ b/include/drm/drm_gpuvm.h
@@ -240,14 +240,29 @@ struct drm_gpuvm {
* @ops: &drm_gpuvm_ops providing the split/merge steps to drivers
*/
const struct drm_gpuvm_ops *ops;
+
+ /**
+* @d_obj: Dummy GEM object; used internally to pass the GPU VMs
+* dma-resv to &drm_exec. Provides the GPUVM's &dma-resv.
+*/
+ struct drm_gem_object d_obj;
};
-void drm_gpuvm_init(struct drm_gpuvm *gpuvm, const char *name,
+void drm_gpuvm_init(struct drm_gpuvm *gpuvm, struct drm_device *drm,
+ const char *name,
u64 start_offset, u64 range,
u64 reserve_offset, u64 reserve_range,
const struct drm_gpuvm_ops *ops);
void drm_gpuvm_destroy(struct drm_gpuvm *gpuvm);
+/**
+ * drm_gpuvm_resv() - returns the &drm_gpuvm's &dma_resv
+ * @gpuvm__: the &drm_gpuvm
+ *
+ * Returns: a pointer to the &drm_gpuvm's &dma_resv
+ */
+#define drm_gpuvm_resv(gpuvm__) (&(gpuvm__)->d_obj._resv)
+
static inline struct drm_gpuva *
__drm_gpuva_next(struct drm_gpuva *va)
{
--
2.41.0
[PATCH drm-misc-next v4 2/8] drm/gpuvm: allow building as module
Currently, the DRM GPUVM does not have any core dependencies preventing
a module build.
Also, new features from subsequent patches require helpers (namely
drm_exec) which can be built as module.
Reviewed-by: Christian König
Signed-off-by: Danilo Krummrich
---
drivers/gpu/drm/Kconfig | 7 +++
drivers/gpu/drm/Makefile| 2 +-
drivers/gpu/drm/drm_gpuvm.c | 3 +++
drivers/gpu/drm/nouveau/Kconfig | 1 +
4 files changed, 12 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/Kconfig b/drivers/gpu/drm/Kconfig
index ab9ef1c20349..0f78a03e4e84 100644
--- a/drivers/gpu/drm/Kconfig
+++ b/drivers/gpu/drm/Kconfig
@@ -216,6 +216,13 @@ config DRM_EXEC
help
Execution context for command submissions
+config DRM_GPUVM
+ tristate
+ depends on DRM && DRM_EXEC
+ help
+ GPU-VM representation providing helpers to manage a GPUs virtual
+ address space
+
config DRM_BUDDY
tristate
depends on DRM
diff --git a/drivers/gpu/drm/Makefile b/drivers/gpu/drm/Makefile
index 7a84b3cddeab..8e1bde059170 100644
--- a/drivers/gpu/drm/Makefile
+++ b/drivers/gpu/drm/Makefile
@@ -45,7 +45,6 @@ drm-y := \
drm_vblank.o \
drm_vblank_work.o \
drm_vma_manager.o \
- drm_gpuvm.o \
drm_writeback.o
drm-$(CONFIG_DRM_LEGACY) += \
drm_agpsupport.o \
@@ -81,6 +80,7 @@ obj-$(CONFIG_DRM_PANEL_ORIENTATION_QUIRKS) +=
drm_panel_orientation_quirks.o
#
#
obj-$(CONFIG_DRM_EXEC) += drm_exec.o
+obj-$(CONFIG_DRM_GPUVM) += drm_gpuvm.o
obj-$(CONFIG_DRM_BUDDY) += drm_buddy.o
diff --git a/drivers/gpu/drm/drm_gpuvm.c b/drivers/gpu/drm/drm_gpuvm.c
index 7074bcad5b28..bfea4a8a19ec 100644
--- a/drivers/gpu/drm/drm_gpuvm.c
+++ b/drivers/gpu/drm/drm_gpuvm.c
@@ -1723,3 +1723,6 @@ drm_gpuva_ops_free(struct drm_gpuvm *gpuvm,
kfree(ops);
}
EXPORT_SYMBOL_GPL(drm_gpuva_ops_free);
+
+MODULE_DESCRIPTION("DRM GPUVM");
+MODULE_LICENSE("GPL");
diff --git a/drivers/gpu/drm/nouveau/Kconfig b/drivers/gpu/drm/nouveau/Kconfig
index c52e8096cca4..1e6aaf95ff7c 100644
--- a/drivers/gpu/drm/nouveau/Kconfig
+++ b/drivers/gpu/drm/nouveau/Kconfig
@@ -11,6 +11,7 @@ config DRM_NOUVEAU
select DRM_TTM
select DRM_TTM_HELPER
select DRM_EXEC
+ select DRM_GPUVM
select DRM_SCHED
select I2C
select I2C_ALGOBIT
--
2.41.0
[PATCH drm-misc-next v4 1/8] drm/gpuvm: rename struct drm_gpuva_manager to struct drm_gpuvm
Rename struct drm_gpuva_manager to struct drm_gpuvm including
corresponding functions. This way the GPUVA manager's structures align
very well with the documentation of VM_BIND [1] and VM_BIND locking [2].
It also provides a better foundation for the naming of data structures
and functions introduced for implementing a common dma-resv per GPU-VM
including tracking of external and evicted objects in subsequent
patches.
[1] Documentation/gpu/drm-vm-bind-async.rst
[2] Documentation/gpu/drm-vm-bind-locking.rst
Cc: Thomas Hellström
Cc: Matthew Brost
Signed-off-by: Danilo Krummrich
---
drivers/gpu/drm/Makefile | 2 +-
drivers/gpu/drm/drm_debugfs.c | 16 +-
.../gpu/drm/{drm_gpuva_mgr.c => drm_gpuvm.c} | 400 +-
drivers/gpu/drm/nouveau/nouveau_exec.c| 2 +-
drivers/gpu/drm/nouveau/nouveau_uvmm.c| 24 +-
drivers/gpu/drm/nouveau/nouveau_uvmm.h| 6 +-
include/drm/drm_debugfs.h | 6 +-
include/drm/{drm_gpuva_mgr.h => drm_gpuvm.h} | 153 ---
8 files changed, 304 insertions(+), 305 deletions(-)
rename drivers/gpu/drm/{drm_gpuva_mgr.c => drm_gpuvm.c} (78%)
rename include/drm/{drm_gpuva_mgr.h => drm_gpuvm.h} (78%)
diff --git a/drivers/gpu/drm/Makefile b/drivers/gpu/drm/Makefile
index 215e78e79125..7a84b3cddeab 100644
--- a/drivers/gpu/drm/Makefile
+++ b/drivers/gpu/drm/Makefile
@@ -45,7 +45,7 @@ drm-y := \
drm_vblank.o \
drm_vblank_work.o \
drm_vma_manager.o \
- drm_gpuva_mgr.o \
+ drm_gpuvm.o \
drm_writeback.o
drm-$(CONFIG_DRM_LEGACY) += \
drm_agpsupport.o \
diff --git a/drivers/gpu/drm/drm_debugfs.c b/drivers/gpu/drm/drm_debugfs.c
index 44ecd7d0daac..f291fb4b359f 100644
--- a/drivers/gpu/drm/drm_debugfs.c
+++ b/drivers/gpu/drm/drm_debugfs.c
@@ -40,7 +40,7 @@
#include
#include
#include
-#include
+#include
#include "drm_crtc_internal.h"
#include "drm_internal.h"
@@ -189,31 +189,31 @@ static const struct file_operations drm_debugfs_fops = {
/**
* drm_debugfs_gpuva_info - dump the given DRM GPU VA space
* @m: pointer to the &seq_file to write
- * @mgr: the &drm_gpuva_manager representing the GPU VA space
+ * @gpuvm: the &drm_gpuvm representing the GPU VA space
*
* Dumps the GPU VA mappings of a given DRM GPU VA manager.
*
* For each DRM GPU VA space drivers should call this function from their
* &drm_info_list's show callback.
*
- * Returns: 0 on success, -ENODEV if the &mgr is not initialized
+ * Returns: 0 on success, -ENODEV if the &gpuvm is not initialized
*/
int drm_debugfs_gpuva_info(struct seq_file *m,
- struct drm_gpuva_manager *mgr)
+ struct drm_gpuvm *gpuvm)
{
- struct drm_gpuva *va, *kva = &mgr->kernel_alloc_node;
+ struct drm_gpuva *va, *kva = &gpuvm->kernel_alloc_node;
- if (!mgr->name)
+ if (!gpuvm->name)
return -ENODEV;
seq_printf(m, "DRM GPU VA space (%s) [0x%016llx;0x%016llx]\n",
- mgr->name, mgr->mm_start, mgr->mm_start + mgr->mm_range);
+ gpuvm->name, gpuvm->mm_start, gpuvm->mm_start +
gpuvm->mm_range);
seq_printf(m, "Kernel reserved node [0x%016llx;0x%016llx]\n",
kva->va.addr, kva->va.addr + kva->va.range);
seq_puts(m, "\n");
seq_puts(m, " VAs | start | range | end
| object | object offset\n");
seq_puts(m,
"-\n");
- drm_gpuva_for_each_va(va, mgr) {
+ drm_gpuvm_for_each_va(va, gpuvm) {
if (unlikely(va == kva))
continue;
diff --git a/drivers/gpu/drm/drm_gpuva_mgr.c b/drivers/gpu/drm/drm_gpuvm.c
similarity index 78%
rename from drivers/gpu/drm/drm_gpuva_mgr.c
rename to drivers/gpu/drm/drm_gpuvm.c
index f86bfad74ff8..7074bcad5b28 100644
--- a/drivers/gpu/drm/drm_gpuva_mgr.c
+++ b/drivers/gpu/drm/drm_gpuvm.c
@@ -25,7 +25,7 @@
*
*/
-#include
+#include
#include
#include
@@ -33,8 +33,8 @@
/**
* DOC: Overview
*
- * The DRM GPU VA Manager, represented by struct drm_gpuva_manager keeps track
- * of a GPU's virtual address (VA) space and manages the corresponding virtual
+ * The DRM GPU VA Manager, represented by struct drm_gpuvm keeps track of a
+ * GPU's virtual address (VA) space and manages the corresponding virtual
* mappings represented by &drm_gpuva objects. It also keeps track of the
* mapping's backing &drm_gem_object buffers.
*
@@ -47,28 +47,28 @@
* The GPU VA manager internally uses a rb-tree to manage the
* &drm_gpuva mappings within a GPU's virtual address space.
*
- * The &drm_gpuva_manager contains a special &drm_gpuva representing the
+ * The &drm_gpuvm structure contains a special &drm_gpuva representing the
* portion of VA space reserved by the kernel. This node i
[PATCH drm-misc-next v4 0/8] [RFC] DRM GPUVA Manager GPU-VM features
So far the DRM GPUVA manager offers common infrastructure to track GPU VA allocations and mappings, generically connect GPU VA mappings to their backing buffers and perform more complex mapping operations on the GPU VA space. However, there are more design patterns commonly used by drivers, which can potentially be generalized in order to make the DRM GPUVA manager represent a basic GPU-VM implementation. In this context, this patch series aims at generalizing the following elements. 1) Provide a common dma-resv for GEM objects not being used outside of this GPU-VM. 2) Provide tracking of external GEM objects (GEM objects which are shared with other GPU-VMs). 3) Provide functions to efficiently lock all GEM objects dma-resv the GPU-VM contains mappings of. 4) Provide tracking of evicted GEM objects the GPU-VM contains mappings of, such that validation of evicted GEM objects is accelerated. 5) Provide some convinience functions for common patterns. The implementation introduces struct drm_gpuvm_bo, which serves as abstraction combining a struct drm_gpuvm and struct drm_gem_object, similar to what amdgpu does with struct amdgpu_bo_vm. While this adds a bit of complexity it improves the efficiency of tracking external and evicted GEM objects. This patch series also renames struct drm_gpuva_manager to struct drm_gpuvm including corresponding functions. This way the GPUVA manager's structures align better with the documentation of VM_BIND [1] and VM_BIND locking [2]. It also provides a better foundation for the naming of data structures and functions introduced for implementing the features of this patch series. This patch series is also available at [3]. [1] Documentation/gpu/drm-vm-bind-async.rst [2] Documentation/gpu/drm-vm-bind-locking.rst [3] https://gitlab.freedesktop.org/nouvelles/kernel/-/commits/gpuvm-next Changes in V2: == - rename 'drm_gpuva_manager' -> 'drm_gpuvm' which generally leads to more consistent naming - properly separate commits (introduce common dma-resv, drm_gpuvm_bo abstraction, etc.) - remove maple tree for tracking external objects, use a list drm_gpuvm_bos per drm_gpuvm instead - rework dma-resv locking helpers (Thomas) - add a locking helper for a given range of the VA space (Christian) - make the GPUVA manager buildable as module, rather than drm_exec builtin (Christian) Changes in V3: == - rename missing function and files (Boris) - warn if vm_obj->obj != obj in drm_gpuva_link() (Boris) - don't expose drm_gpuvm_bo_destroy() (Boris) - unlink VM_BO from GEM in drm_gpuvm_bo_destroy() rather than drm_gpuva_unlink() and link within drm_gpuvm_bo_obtain() to keep drm_gpuvm_bo instances unique - add internal locking to external and evicted object lists to support drivers updating the VA space from within the fence signalling critical path (Boris) - unlink external objects and evicted objects from the GPUVM's list in drm_gpuvm_bo_destroy() - add more documentation and fix some kernel doc issues Changes in V4: == - add a drm_gpuvm_resv() helper (Boris) - add a drm_gpuvmlocal_list field (Boris) - remove drm_gpuvm_bo_get_unless_zero() helper (Boris) - fix missing NULL assignment in get_next_vm_bo_from_list() (Boris) - keep a drm_gem_object reference on potential vm_bo destroy (alternatively we could free the vm_bo and drop the vm_bo's drm_gem_object reference through async work) - introduce DRM_GPUVM_RESV_PROTECTED flag to indicate external locking through the corresponding dma-resv locks to optimize for drivers already holding them when needed; add the corresponding lock_assert_held() calls (Thomas) - make drm_gpuvm_bo_evict() per vm_bo and add a drm_gpuvm_bo_gem_evict() helper (Thomas) - pass a drm_gpuvm_bo in drm_gpuvm_ops::vm_bo_validate() (Thomas) - documentation fixes Danilo Krummrich (8): drm/gpuvm: rename struct drm_gpuva_manager to struct drm_gpuvm drm/gpuvm: allow building as module drm/nouveau: uvmm: rename 'umgr' to 'base' drm/gpuvm: add common dma-resv per struct drm_gpuvm drm/gpuvm: add an abstraction for a VM / BO combination drm/gpuvm: add drm_gpuvm_flags to drm_gpuvm drm/gpuvm: generalize dma_resv/extobj handling and GEM validation drm/nouveau: GPUVM dma-resv/extobj handling, GEM validation drivers/gpu/drm/Kconfig |7 + drivers/gpu/drm/Makefile |2 +- drivers/gpu/drm/drm_debugfs.c | 16 +- drivers/gpu/drm/drm_gpuva_mgr.c | 1725 -- drivers/gpu/drm/drm_gpuvm.c | 2600 + drivers/gpu/drm/nouveau/Kconfig |1 + drivers/gpu/drm/nouveau/nouveau_bo.c |4 +- drivers/gpu/drm/nouveau/nouveau_debugfs.c |2 +- drivers/gpu/drm/nouveau/nouveau_exec.c| 52 +- drivers/gpu/drm/nouveau/nouveau_exec.h|4 - drivers/gpu/drm/nouveau/nouveau_gem.c |5 +- drivers/g
Re: [Intel-gfx] [PATCH 5/5] drm/i915: Implement fdinfo memory stats printing
On Wed, Sep 20, 2023 at 7:35 AM Tvrtko Ursulin
wrote:
>
>
> On 24/08/2023 12:35, Upadhyay, Tejas wrote:
> >> -Original Message-
> >> From: Intel-gfx On Behalf Of
> >> Tvrtko
> >> Ursulin
> >> Sent: Friday, July 7, 2023 6:32 PM
> >> To: intel-...@lists.freedesktop.org; dri-devel@lists.freedesktop.org
> >> Subject: [Intel-gfx] [PATCH 5/5] drm/i915: Implement fdinfo memory stats
> >> printing
> >>
> >> From: Tvrtko Ursulin
> >>
> >> Use the newly added drm_print_memory_stats helper to show memory
> >> utilisation of our objects in drm/driver specific fdinfo output.
> >>
> >> To collect the stats we walk the per memory regions object lists and
> >> accumulate object size into the respective drm_memory_stats categories.
> >>
> >> Objects with multiple possible placements are reported in multiple regions
> >> for
> >> total and shared sizes, while other categories are counted only for the
> >> currently active region.
> >>
> >> Signed-off-by: Tvrtko Ursulin
> >> Cc: Aravind Iddamsetty
> >> Cc: Rob Clark
> >> ---
> >> drivers/gpu/drm/i915/i915_drm_client.c | 85 ++
> >> 1 file changed, 85 insertions(+)
> >>
> >> diff --git a/drivers/gpu/drm/i915/i915_drm_client.c
> >> b/drivers/gpu/drm/i915/i915_drm_client.c
> >> index ffccb6239789..5c77d6987d90 100644
> >> --- a/drivers/gpu/drm/i915/i915_drm_client.c
> >> +++ b/drivers/gpu/drm/i915/i915_drm_client.c
> >> @@ -45,6 +45,89 @@ void __i915_drm_client_free(struct kref *kref) }
> >>
> >> #ifdef CONFIG_PROC_FS
> >> +static void
> >> +obj_meminfo(struct drm_i915_gem_object *obj,
> >> +struct drm_memory_stats stats[INTEL_REGION_UNKNOWN]) {
> >> +struct intel_memory_region *mr;
> >> +u64 sz = obj->base.size;
> >> +enum intel_region_id id;
> >> +unsigned int i;
> >> +
> >> +/* Attribute size and shared to all possible memory regions. */
> >> +for (i = 0; i < obj->mm.n_placements; i++) {
> >> +mr = obj->mm.placements[i];
> >> +id = mr->id;
> >> +
> >> +if (obj->base.handle_count > 1)
> >> +stats[id].shared += sz;
> >> +else
> >> +stats[id].private += sz;
> >> +}
> >> +
> >> +/* Attribute other categories to only the current region. */
> >> +mr = obj->mm.region;
> >> +if (mr)
> >> +id = mr->id;
> >> +else
> >> +id = INTEL_REGION_SMEM;
> >> +
> >> +if (!obj->mm.n_placements) {
> >> +if (obj->base.handle_count > 1)
> >> +stats[id].shared += sz;
> >> +else
> >> +stats[id].private += sz;
> >> +}
> >> +
> >> +if (i915_gem_object_has_pages(obj)) {
> >> +stats[id].resident += sz;
> >> +
> >> +if (!dma_resv_test_signaled(obj->base.resv,
> >> +dma_resv_usage_rw(true)))
> >
> > Should not DMA_RESV_USAGE_BOOKKEEP also considered active (why only "rw")?
> > Some app is syncing with syncjobs and has added dma_fence with
> > DMA_RESV_USAGE_BOOKKEEP during execbuf while that BO is busy on waiting on
> > work!
>
> Hmm do we have a path which adds DMA_RESV_USAGE_BOOKKEEP usage in execbuf?
>
> Rob, any comments here? Given how I basically lifted the logic from
> 686b21b5f6ca ("drm: Add fdinfo memory stats"), does it sound plausible
> to upgrade the test against all fences?
Yes, I think so.. I don't have any use for BOOKKEEP so I hadn't considered it
BR,
-R
>
> Regards,
>
> Tvrtko
>
> >> +stats[id].active += sz;
> >> +else if (i915_gem_object_is_shrinkable(obj) &&
> >> + obj->mm.madv == I915_MADV_DONTNEED)
> >> +stats[id].purgeable += sz;
> >> +}
> >> +}
> >> +
> >> +static void show_meminfo(struct drm_printer *p, struct drm_file *file)
> >> +{
> >> +struct drm_memory_stats stats[INTEL_REGION_UNKNOWN] = {};
> >> +struct drm_i915_file_private *fpriv = file->driver_priv;
> >> +struct i915_drm_client *client = fpriv->client;
> >> +struct drm_i915_private *i915 = fpriv->i915;
> >> +struct drm_i915_gem_object *obj;
> >> +struct intel_memory_region *mr;
> >> +struct list_head *pos;
> >> +unsigned int id;
> >> +
> >> +/* Public objects. */
> >> +spin_lock(&file->table_lock);
> >> +idr_for_each_entry (&file->object_idr, obj, id)
> >> +obj_meminfo(obj, stats);
> >> +spin_unlock(&file->table_lock);
> >> +
> >> +/* Internal objects. */
> >> +rcu_read_lock();
> >> +list_for_each_rcu(pos, &client->objects_list) {
> >> +obj = i915_gem_object_get_rcu(list_entry(pos, typeof(*obj),
> >> + client_link));
> >> +if (!obj)
> >> +continue;
> >> +obj_meminfo(obj, stats);
> >> +i915_gem_object_put(obj);
> >> +}
> >> +rcu_read_unlock();
> >> +
> >> +for_each_memory_region(mr, i915, id)
> >> +
[PATCH RFC v2 37/37] drm/sun4i: hdmi: Switch to HDMI connector
The new HDMI connector infrastructure allows to remove some boilerplate,
especially to generate infoframes. Let's switch to it.
Signed-off-by: Maxime Ripard
---
drivers/gpu/drm/sun4i/sun4i_hdmi_enc.c | 80 ++
1 file changed, 51 insertions(+), 29 deletions(-)
diff --git a/drivers/gpu/drm/sun4i/sun4i_hdmi_enc.c
b/drivers/gpu/drm/sun4i/sun4i_hdmi_enc.c
index b7cf369b1906..8a9106a39f23 100644
--- a/drivers/gpu/drm/sun4i/sun4i_hdmi_enc.c
+++ b/drivers/gpu/drm/sun4i/sun4i_hdmi_enc.c
@@ -36,30 +36,24 @@
#define drm_connector_to_sun4i_hdmi(c) \
container_of_const(c, struct sun4i_hdmi, connector)
-static int sun4i_hdmi_setup_avi_infoframes(struct sun4i_hdmi *hdmi,
- struct drm_display_mode *mode)
+static int sun4i_hdmi_write_infoframe(struct drm_connector *connector,
+ enum hdmi_infoframe_type type,
+ const u8 *buffer, size_t len)
{
- struct hdmi_avi_infoframe frame;
- u8 buffer[17];
- int i, ret;
+ struct sun4i_hdmi *hdmi = drm_connector_to_sun4i_hdmi(connector);
+ int i;
- ret = drm_hdmi_avi_infoframe_from_display_mode(&frame,
- &hdmi->connector, mode);
- if (ret < 0) {
- DRM_ERROR("Failed to get infoframes from mode\n");
- return ret;
+ if (type != HDMI_INFOFRAME_TYPE_AVI) {
+ drm_err(connector->dev,
+ "Unsupported infoframe type: %u\n", type);
+ return 0;
}
- ret = hdmi_avi_infoframe_pack(&frame, buffer, sizeof(buffer));
- if (ret < 0) {
- DRM_ERROR("Failed to pack infoframes\n");
- return ret;
- }
-
- for (i = 0; i < sizeof(buffer); i++)
+ for (i = 0; i < len; i++)
writeb(buffer[i], hdmi->base + SUN4I_HDMI_AVI_INFOFRAME_REG(i));
return 0;
+
}
static void sun4i_hdmi_disable(struct drm_encoder *encoder,
@@ -82,14 +76,18 @@ static void sun4i_hdmi_enable(struct drm_encoder *encoder,
{
struct drm_display_mode *mode = &encoder->crtc->state->adjusted_mode;
struct sun4i_hdmi *hdmi = drm_encoder_to_sun4i_hdmi(encoder);
- struct drm_display_info *display = &hdmi->connector.display_info;
+ struct drm_connector *connector = &hdmi->connector;
+ struct drm_display_info *display = &connector->display_info;
+ struct drm_connector_state *conn_state =
+ drm_atomic_get_new_connector_state(state, connector);
+ unsigned long long tmds_rate = conn_state->hdmi.tmds_char_rate;
unsigned int x, y;
u32 val = 0;
DRM_DEBUG_DRIVER("Enabling the HDMI Output\n");
- clk_set_rate(hdmi->mod_clk, mode->crtc_clock * 1000);
- clk_set_rate(hdmi->tmds_clk, mode->crtc_clock * 1000);
+ clk_set_rate(hdmi->mod_clk, tmds_rate);
+ clk_set_rate(hdmi->tmds_clk, tmds_rate);
/* Set input sync enable */
writel(SUN4I_HDMI_UNKNOWN_INPUT_SYNC,
@@ -142,7 +140,8 @@ static void sun4i_hdmi_enable(struct drm_encoder *encoder,
clk_prepare_enable(hdmi->tmds_clk);
- sun4i_hdmi_setup_avi_infoframes(hdmi, mode);
+ drm_atomic_helper_connector_hdmi_update_infoframes(connector, state);
+
val |= SUN4I_HDMI_PKT_CTRL_TYPE(0, SUN4I_HDMI_PKT_AVI);
val |= SUN4I_HDMI_PKT_CTRL_TYPE(1, SUN4I_HDMI_PKT_END);
writel(val, hdmi->base + SUN4I_HDMI_PKT_CTRL_REG(0));
@@ -195,7 +194,7 @@ static int sun4i_hdmi_connector_atomic_check(struct
drm_connector *connector,
enum drm_mode_status status;
status = sun4i_hdmi_connector_clock_valid(connector, mode,
- mode->clock * 1000);
+
conn_state->hdmi.tmds_char_rate);
if (status != MODE_OK)
return -EINVAL;
@@ -206,8 +205,11 @@ static enum drm_mode_status
sun4i_hdmi_connector_mode_valid(struct drm_connector *connector,
struct drm_display_mode *mode)
{
- return sun4i_hdmi_connector_clock_valid(connector, mode,
- mode->clock * 1000);
+ unsigned long long rate =
+ drm_connector_hdmi_compute_mode_clock(mode, 8,
+ HDMI_COLORSPACE_RGB);
+
+ return sun4i_hdmi_connector_clock_valid(connector, mode, rate);
}
static int sun4i_hdmi_get_modes(struct drm_connector *connector)
@@ -253,6 +255,11 @@ static struct i2c_adapter *sun4i_hdmi_get_ddc(struct
device *dev)
return ddc;
}
+static const struct drm_connector_hdmi_funcs sun4i_hdmi_hdmi_connector_funcs =
{
+ .tmds_char_rate_valid = sun4i_hdmi_connector_clock_valid,
+ .write_infoframe= sun4i_hdmi_write_infoframe,
+};
+
static const struct drm_connector_helper_func
[PATCH RFC v2 35/37] drm/sun4i: hdmi: Switch to container_of_const
container_of_const() allows to preserve the pointer constness and is
thus more flexible than inline functions.
Let's switch all our instances of container_of() to container_of_const().
Signed-off-by: Maxime Ripard
---
drivers/gpu/drm/sun4i/sun4i_hdmi_enc.c | 16
1 file changed, 4 insertions(+), 12 deletions(-)
diff --git a/drivers/gpu/drm/sun4i/sun4i_hdmi_enc.c
b/drivers/gpu/drm/sun4i/sun4i_hdmi_enc.c
index bae69d696765..c276d984da6b 100644
--- a/drivers/gpu/drm/sun4i/sun4i_hdmi_enc.c
+++ b/drivers/gpu/drm/sun4i/sun4i_hdmi_enc.c
@@ -30,19 +30,11 @@
#include "sun4i_drv.h"
#include "sun4i_hdmi.h"
-static inline struct sun4i_hdmi *
-drm_encoder_to_sun4i_hdmi(struct drm_encoder *encoder)
-{
- return container_of(encoder, struct sun4i_hdmi,
- encoder);
-}
+#define drm_encoder_to_sun4i_hdmi(e) \
+ container_of_const(e, struct sun4i_hdmi, encoder)
-static inline struct sun4i_hdmi *
-drm_connector_to_sun4i_hdmi(struct drm_connector *connector)
-{
- return container_of(connector, struct sun4i_hdmi,
- connector);
-}
+#define drm_connector_to_sun4i_hdmi(c) \
+ container_of_const(c, struct sun4i_hdmi, connector)
static int sun4i_hdmi_setup_avi_infoframes(struct sun4i_hdmi *hdmi,
struct drm_display_mode *mode)
--
2.41.0
[PATCH RFC v2 36/37] drm/sun4i: hdmi: Consolidate atomic_check and mode_valid
atomic_check and mode_valid do not check for the same things which can
lead to surprising result if the userspace commits a mode that didn't go
through mode_valid. Let's merge the two implementations into a function
called by both.
Signed-off-by: Maxime Ripard
---
drivers/gpu/drm/sun4i/sun4i_hdmi_enc.c | 74 +-
1 file changed, 47 insertions(+), 27 deletions(-)
diff --git a/drivers/gpu/drm/sun4i/sun4i_hdmi_enc.c
b/drivers/gpu/drm/sun4i/sun4i_hdmi_enc.c
index c276d984da6b..b7cf369b1906 100644
--- a/drivers/gpu/drm/sun4i/sun4i_hdmi_enc.c
+++ b/drivers/gpu/drm/sun4i/sun4i_hdmi_enc.c
@@ -62,18 +62,6 @@ static int sun4i_hdmi_setup_avi_infoframes(struct sun4i_hdmi
*hdmi,
return 0;
}
-static int sun4i_hdmi_atomic_check(struct drm_encoder *encoder,
- struct drm_crtc_state *crtc_state,
- struct drm_connector_state *conn_state)
-{
- struct drm_display_mode *mode = &crtc_state->mode;
-
- if (mode->flags & DRM_MODE_FLAG_DBLCLK)
- return -EINVAL;
-
- return 0;
-}
-
static void sun4i_hdmi_disable(struct drm_encoder *encoder,
struct drm_atomic_state *state)
{
@@ -166,31 +154,61 @@ static void sun4i_hdmi_enable(struct drm_encoder *encoder,
writel(val, hdmi->base + SUN4I_HDMI_VID_CTRL_REG);
}
-static enum drm_mode_status sun4i_hdmi_mode_valid(struct drm_encoder *encoder,
- const struct drm_display_mode *mode)
+static const struct drm_encoder_helper_funcs sun4i_hdmi_helper_funcs = {
+ .atomic_disable = sun4i_hdmi_disable,
+ .atomic_enable = sun4i_hdmi_enable,
+};
+
+static enum drm_mode_status
+sun4i_hdmi_connector_clock_valid(const struct drm_connector *connector,
+const struct drm_display_mode *mode,
+unsigned long long clock)
{
- struct sun4i_hdmi *hdmi = drm_encoder_to_sun4i_hdmi(encoder);
- unsigned long rate = mode->clock * 1000;
- unsigned long diff = rate / 200; /* +-0.5% allowed by HDMI spec */
+ const struct sun4i_hdmi *hdmi = drm_connector_to_sun4i_hdmi(connector);
+ unsigned long diff = clock / 200; /* +-0.5% allowed by HDMI spec */
long rounded_rate;
+ if (mode->flags & DRM_MODE_FLAG_DBLCLK)
+ return MODE_BAD;
+
/* 165 MHz is the typical max pixelclock frequency for HDMI <= 1.2 */
- if (rate > 16500)
+ if (clock > 16500)
return MODE_CLOCK_HIGH;
- rounded_rate = clk_round_rate(hdmi->tmds_clk, rate);
+
+ rounded_rate = clk_round_rate(hdmi->tmds_clk, clock);
if (rounded_rate > 0 &&
- max_t(unsigned long, rounded_rate, rate) -
- min_t(unsigned long, rounded_rate, rate) < diff)
+ max_t(unsigned long, rounded_rate, clock) -
+ min_t(unsigned long, rounded_rate, clock) < diff)
return MODE_OK;
+
return MODE_NOCLOCK;
}
-static const struct drm_encoder_helper_funcs sun4i_hdmi_helper_funcs = {
- .atomic_check = sun4i_hdmi_atomic_check,
- .atomic_disable = sun4i_hdmi_disable,
- .atomic_enable = sun4i_hdmi_enable,
- .mode_valid = sun4i_hdmi_mode_valid,
-};
+static int sun4i_hdmi_connector_atomic_check(struct drm_connector *connector,
+struct drm_atomic_state *state)
+{
+ struct drm_connector_state *conn_state =
+ drm_atomic_get_new_connector_state(state, connector);
+ struct drm_crtc *crtc = conn_state->crtc;
+ struct drm_crtc_state *crtc_state = crtc->state;
+ struct drm_display_mode *mode = &crtc_state->adjusted_mode;
+ enum drm_mode_status status;
+
+ status = sun4i_hdmi_connector_clock_valid(connector, mode,
+ mode->clock * 1000);
+ if (status != MODE_OK)
+ return -EINVAL;
+
+ return 0;
+}
+
+static enum drm_mode_status
+sun4i_hdmi_connector_mode_valid(struct drm_connector *connector,
+ struct drm_display_mode *mode)
+{
+ return sun4i_hdmi_connector_clock_valid(connector, mode,
+ mode->clock * 1000);
+}
static int sun4i_hdmi_get_modes(struct drm_connector *connector)
{
@@ -236,6 +254,8 @@ static struct i2c_adapter *sun4i_hdmi_get_ddc(struct device
*dev)
}
static const struct drm_connector_helper_funcs
sun4i_hdmi_connector_helper_funcs = {
+ .atomic_check = sun4i_hdmi_connector_atomic_check,
+ .mode_valid = sun4i_hdmi_connector_mode_valid,
.get_modes = sun4i_hdmi_get_modes,
};
--
2.41.0
[PATCH RFC v2 29/37] drm/rockchip: inno_hdmi: Create mask retrieval functions
The register mask and bits to enable or disable a given infoframe
depends on its type.
This is currently passed as an argument to the function that writes an
infoframe, but let's create a helper function to retrieve them based on
the type to make further reworks easier.
Signed-off-by: Maxime Ripard
---
drivers/gpu/drm/rockchip/inno_hdmi.c | 75 ++--
1 file changed, 63 insertions(+), 12 deletions(-)
diff --git a/drivers/gpu/drm/rockchip/inno_hdmi.c
b/drivers/gpu/drm/rockchip/inno_hdmi.c
index e3a421d98dd4..bc7fb1278cb2 100644
--- a/drivers/gpu/drm/rockchip/inno_hdmi.c
+++ b/drivers/gpu/drm/rockchip/inno_hdmi.c
@@ -156,10 +156,62 @@ static void inno_hdmi_reset(struct inno_hdmi *hdmi)
inno_hdmi_set_pwr_mode(hdmi, NORMAL);
}
-static void inno_hdmi_disable_frame(struct inno_hdmi *hdmi,
- u32 frame_index,
- u32 mask, u32 disable)
+static u32 inno_hdmi_get_frame_mask(struct inno_hdmi *hdmi,
+ u32 frame_index)
{
+ struct drm_device *drm = hdmi->connector.dev;
+
+ switch (frame_index) {
+ case INFOFRAME_VSI:
+ return m_PACKET_VSI_EN;
+ case INFOFRAME_AVI:
+ return 0;
+ default:
+ drm_err(drm, "Unknown infoframe type: %u\n", frame_index);
+ }
+
+ return 0;
+}
+
+static u32 inno_hdmi_get_frame_disable(struct inno_hdmi *hdmi,
+ u32 frame_index)
+{
+ struct drm_device *drm = hdmi->connector.dev;
+
+ switch (frame_index) {
+ case INFOFRAME_VSI:
+ return v_PACKET_VSI_EN(0);
+ case INFOFRAME_AVI:
+ return 0;
+ default:
+ drm_err(drm, "Unknown infoframe type: %u\n", frame_index);
+ }
+
+ return 0;
+}
+
+static u32 inno_hdmi_get_frame_enable(struct inno_hdmi *hdmi,
+ u32 frame_index)
+{
+ struct drm_device *drm = hdmi->connector.dev;
+
+ switch (frame_index) {
+ case INFOFRAME_VSI:
+ return v_PACKET_VSI_EN(1);
+ case INFOFRAME_AVI:
+ return 0;
+ default:
+ drm_err(drm, "Unknown infoframe type: %u\n", frame_index);
+ }
+
+ return 0;
+}
+
+static void inno_hdmi_disable_frame(struct inno_hdmi *hdmi, u32 frame_index)
+{
+ u32 disable = inno_hdmi_get_frame_disable(hdmi, frame_index);
+ u32 mask = inno_hdmi_get_frame_mask(hdmi, frame_index);
+
if (mask)
hdmi_modb(hdmi, HDMI_PACKET_SEND_AUTO, mask, disable);
@@ -167,13 +219,14 @@ static void inno_hdmi_disable_frame(struct inno_hdmi
*hdmi,
}
static int inno_hdmi_upload_frame(struct inno_hdmi *hdmi,
- union hdmi_infoframe *frame, u32 frame_index,
- u32 mask, u32 disable, u32 enable)
+ union hdmi_infoframe *frame, u32 frame_index)
{
+ u32 enable = inno_hdmi_get_frame_enable(hdmi, frame_index);
+ u32 mask = inno_hdmi_get_frame_mask(hdmi, frame_index);
u8 packed_frame[HDMI_MAXIMUM_INFO_FRAME_SIZE];
ssize_t rc, i;
- inno_hdmi_disable_frame(hdmi, frame_index, mask, disable);
+ inno_hdmi_disable_frame(hdmi, frame_index);
rc = hdmi_infoframe_pack(frame, packed_frame,
sizeof(packed_frame));
@@ -200,13 +253,11 @@ static int inno_hdmi_config_video_vsi(struct inno_hdmi
*hdmi,
&hdmi->connector,
mode);
if (rc) {
- inno_hdmi_disable_frame(hdmi, INFOFRAME_VSI,
- m_PACKET_VSI_EN, v_PACKET_VSI_EN(0));
+ inno_hdmi_disable_frame(hdmi, INFOFRAME_VSI);
return rc;
}
- return inno_hdmi_upload_frame(hdmi, &frame, INFOFRAME_VSI,
- m_PACKET_VSI_EN, v_PACKET_VSI_EN(0), v_PACKET_VSI_EN(1));
+ return inno_hdmi_upload_frame(hdmi, &frame, INFOFRAME_VSI);
}
static int inno_hdmi_config_video_avi(struct inno_hdmi *hdmi,
@@ -219,13 +270,13 @@ static int inno_hdmi_config_video_avi(struct inno_hdmi
*hdmi,
&hdmi->connector,
mode);
if (rc) {
- inno_hdmi_disable_frame(hdmi, INFOFRAME_AVI, 0, 0);
+ inno_hdmi_disable_frame(hdmi, INFOFRAME_AVI);
return rc;
}
frame.avi.colorspace = HDMI_COLORSPACE_RGB;
- return inno_hdmi_upload_frame(hdmi, &frame, INFOFRAME_AVI, 0, 0, 0);
+ return inno_hdmi_upload_frame(hdmi, &frame, INFOFRAME_AVI);
}
static int inno_hdmi_config_video_csc(struct inno_hdmi *hdmi)
--
2.41.0
[PATCH RFC v2 34/37] drm/sun4i: hdmi: Move mode_set into enable
We're not doing anything special in atomic_mode_set so we can simply
merge it into atomic_enable.
Signed-off-by: Maxime Ripard
---
drivers/gpu/drm/sun4i/sun4i_hdmi_enc.c | 38 +-
1 file changed, 14 insertions(+), 24 deletions(-)
diff --git a/drivers/gpu/drm/sun4i/sun4i_hdmi_enc.c
b/drivers/gpu/drm/sun4i/sun4i_hdmi_enc.c
index 799a26215cc2..bae69d696765 100644
--- a/drivers/gpu/drm/sun4i/sun4i_hdmi_enc.c
+++ b/drivers/gpu/drm/sun4i/sun4i_hdmi_enc.c
@@ -103,33 +103,11 @@ static void sun4i_hdmi_enable(struct drm_encoder *encoder,
struct drm_display_mode *mode = &encoder->crtc->state->adjusted_mode;
struct sun4i_hdmi *hdmi = drm_encoder_to_sun4i_hdmi(encoder);
struct drm_display_info *display = &hdmi->connector.display_info;
+ unsigned int x, y;
u32 val = 0;
DRM_DEBUG_DRIVER("Enabling the HDMI Output\n");
- clk_prepare_enable(hdmi->tmds_clk);
-
- sun4i_hdmi_setup_avi_infoframes(hdmi, mode);
- val |= SUN4I_HDMI_PKT_CTRL_TYPE(0, SUN4I_HDMI_PKT_AVI);
- val |= SUN4I_HDMI_PKT_CTRL_TYPE(1, SUN4I_HDMI_PKT_END);
- writel(val, hdmi->base + SUN4I_HDMI_PKT_CTRL_REG(0));
-
- val = SUN4I_HDMI_VID_CTRL_ENABLE;
- if (display->is_hdmi)
- val |= SUN4I_HDMI_VID_CTRL_HDMI_MODE;
-
- writel(val, hdmi->base + SUN4I_HDMI_VID_CTRL_REG);
-}
-
-static void sun4i_hdmi_mode_set(struct drm_encoder *encoder,
- struct drm_crtc_state *crtc_state,
- struct drm_connector_state *conn_state)
-{
- const struct drm_display_mode *mode = &crtc_state->mode;
- struct sun4i_hdmi *hdmi = drm_encoder_to_sun4i_hdmi(encoder);
- unsigned int x, y;
- u32 val;
-
clk_set_rate(hdmi->mod_clk, mode->crtc_clock * 1000);
clk_set_rate(hdmi->tmds_clk, mode->crtc_clock * 1000);
@@ -181,6 +159,19 @@ static void sun4i_hdmi_mode_set(struct drm_encoder
*encoder,
val |= SUN4I_HDMI_VID_TIMING_POL_VSYNC;
writel(val, hdmi->base + SUN4I_HDMI_VID_TIMING_POL_REG);
+
+ clk_prepare_enable(hdmi->tmds_clk);
+
+ sun4i_hdmi_setup_avi_infoframes(hdmi, mode);
+ val |= SUN4I_HDMI_PKT_CTRL_TYPE(0, SUN4I_HDMI_PKT_AVI);
+ val |= SUN4I_HDMI_PKT_CTRL_TYPE(1, SUN4I_HDMI_PKT_END);
+ writel(val, hdmi->base + SUN4I_HDMI_PKT_CTRL_REG(0));
+
+ val = SUN4I_HDMI_VID_CTRL_ENABLE;
+ if (display->is_hdmi)
+ val |= SUN4I_HDMI_VID_CTRL_HDMI_MODE;
+
+ writel(val, hdmi->base + SUN4I_HDMI_VID_CTRL_REG);
}
static enum drm_mode_status sun4i_hdmi_mode_valid(struct drm_encoder *encoder,
@@ -206,7 +197,6 @@ static const struct drm_encoder_helper_funcs
sun4i_hdmi_helper_funcs = {
.atomic_check = sun4i_hdmi_atomic_check,
.atomic_disable = sun4i_hdmi_disable,
.atomic_enable = sun4i_hdmi_enable,
- .atomic_mode_set= sun4i_hdmi_mode_set,
.mode_valid = sun4i_hdmi_mode_valid,
};
--
2.41.0
[PATCH RFC v2 26/37] drm/rockchip: inno_hdmi: Remove useless coeff_csc matrix
The coeff_csc matrix isn't used anymore, let's remove it.
Signed-off-by: Maxime Ripard
---
drivers/gpu/drm/rockchip/inno_hdmi.c | 70
1 file changed, 70 deletions(-)
diff --git a/drivers/gpu/drm/rockchip/inno_hdmi.c
b/drivers/gpu/drm/rockchip/inno_hdmi.c
index 35f44e556fcf..e4fe02b79a98 100644
--- a/drivers/gpu/drm/rockchip/inno_hdmi.c
+++ b/drivers/gpu/drm/rockchip/inno_hdmi.c
@@ -64,76 +64,6 @@ static struct inno_hdmi *connector_to_inno_hdmi(struct
drm_connector *connector)
return container_of(connector, struct inno_hdmi, connector);
}
-static const char coeff_csc[][24] = {
- /*
-* YUV2RGB:601 SD mode(Y[16:235], UV[16:240], RGB[0:255]):
-* R = 1.164*Y + 1.596*V - 204
-* G = 1.164*Y - 0.391*U - 0.813*V + 154
-* B = 1.164*Y + 2.018*U - 258
-*/
- {
- 0x04, 0xa7, 0x00, 0x00, 0x06, 0x62, 0x02, 0xcc,
- 0x04, 0xa7, 0x11, 0x90, 0x13, 0x40, 0x00, 0x9a,
- 0x04, 0xa7, 0x08, 0x12, 0x00, 0x00, 0x03, 0x02
- },
- /*
-* YUV2RGB:601 SD mode(YUV[0:255],RGB[0:255]):
-* R = Y + 1.402*V - 248
-* G = Y - 0.344*U - 0.714*V + 135
-* B = Y + 1.772*U - 227
-*/
- {
- 0x04, 0x00, 0x00, 0x00, 0x05, 0x9b, 0x02, 0xf8,
- 0x04, 0x00, 0x11, 0x60, 0x12, 0xdb, 0x00, 0x87,
- 0x04, 0x00, 0x07, 0x16, 0x00, 0x00, 0x02, 0xe3
- },
- /*
-* YUV2RGB:709 HD mode(Y[16:235],UV[16:240],RGB[0:255]):
-* R = 1.164*Y + 1.793*V - 248
-* G = 1.164*Y - 0.213*U - 0.534*V + 77
-* B = 1.164*Y + 2.115*U - 289
-*/
- {
- 0x04, 0xa7, 0x00, 0x00, 0x07, 0x2c, 0x02, 0xf8,
- 0x04, 0xa7, 0x10, 0xda, 0x12, 0x22, 0x00, 0x4d,
- 0x04, 0xa7, 0x08, 0x74, 0x00, 0x00, 0x03, 0x21
- },
-
- /*
-* RGB2YUV:601 SD mode:
-* Cb = -0.291G - 0.148R + 0.439B + 128
-* Y = 0.504G + 0.257R + 0.098B + 16
-* Cr = -0.368G + 0.439R - 0.071B + 128
-*/
- {
- 0x11, 0x5f, 0x01, 0x82, 0x10, 0x23, 0x00, 0x80,
- 0x02, 0x1c, 0x00, 0xa1, 0x00, 0x36, 0x00, 0x1e,
- 0x11, 0x29, 0x10, 0x59, 0x01, 0x82, 0x00, 0x80
- },
- /*
-* RGB2YUV:709 HD mode:
-* Cb = - 0.338G - 0.101R + 0.439B + 128
-* Y = 0.614G + 0.183R + 0.062B + 16
-* Cr = - 0.399G + 0.439R - 0.040B + 128
-*/
- {
- 0x11, 0x98, 0x01, 0xc1, 0x10, 0x28, 0x00, 0x80,
- 0x02, 0x74, 0x00, 0xbb, 0x00, 0x3f, 0x00, 0x10,
- 0x11, 0x5a, 0x10, 0x67, 0x01, 0xc1, 0x00, 0x80
- },
- /*
-* RGB[0:255]2RGB[16:235]:
-* R' = R x (235-16)/255 + 16;
-* G' = G x (235-16)/255 + 16;
-* B' = B x (235-16)/255 + 16;
-*/
- {
- 0x00, 0x00, 0x03, 0x6F, 0x00, 0x00, 0x00, 0x10,
- 0x03, 0x6F, 0x00, 0x00, 0x00, 0x00, 0x00, 0x10,
- 0x00, 0x00, 0x00, 0x00, 0x03, 0x6F, 0x00, 0x10
- },
-};
-
static inline u8 hdmi_readb(struct inno_hdmi *hdmi, u16 offset)
{
return readl_relaxed(hdmi->regs + (offset) * 0x04);
--
2.41.0
[PATCH RFC v2 33/37] drm/sun4i: hdmi: Convert encoder to atomic
The sun4i_hdmi driver still uses the non-atomic variants of the encoder
hooks, so let's convert to their atomic equivalents.
Signed-off-by: Maxime Ripard
---
drivers/gpu/drm/sun4i/sun4i_hdmi_enc.c | 17 ++---
1 file changed, 10 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/sun4i/sun4i_hdmi_enc.c
b/drivers/gpu/drm/sun4i/sun4i_hdmi_enc.c
index 152375f3de2e..799a26215cc2 100644
--- a/drivers/gpu/drm/sun4i/sun4i_hdmi_enc.c
+++ b/drivers/gpu/drm/sun4i/sun4i_hdmi_enc.c
@@ -82,7 +82,8 @@ static int sun4i_hdmi_atomic_check(struct drm_encoder
*encoder,
return 0;
}
-static void sun4i_hdmi_disable(struct drm_encoder *encoder)
+static void sun4i_hdmi_disable(struct drm_encoder *encoder,
+ struct drm_atomic_state *state)
{
struct sun4i_hdmi *hdmi = drm_encoder_to_sun4i_hdmi(encoder);
u32 val;
@@ -96,7 +97,8 @@ static void sun4i_hdmi_disable(struct drm_encoder *encoder)
clk_disable_unprepare(hdmi->tmds_clk);
}
-static void sun4i_hdmi_enable(struct drm_encoder *encoder)
+static void sun4i_hdmi_enable(struct drm_encoder *encoder,
+ struct drm_atomic_state *state)
{
struct drm_display_mode *mode = &encoder->crtc->state->adjusted_mode;
struct sun4i_hdmi *hdmi = drm_encoder_to_sun4i_hdmi(encoder);
@@ -120,9 +122,10 @@ static void sun4i_hdmi_enable(struct drm_encoder *encoder)
}
static void sun4i_hdmi_mode_set(struct drm_encoder *encoder,
- struct drm_display_mode *mode,
- struct drm_display_mode *adjusted_mode)
+ struct drm_crtc_state *crtc_state,
+ struct drm_connector_state *conn_state)
{
+ const struct drm_display_mode *mode = &crtc_state->mode;
struct sun4i_hdmi *hdmi = drm_encoder_to_sun4i_hdmi(encoder);
unsigned int x, y;
u32 val;
@@ -201,9 +204,9 @@ static enum drm_mode_status sun4i_hdmi_mode_valid(struct
drm_encoder *encoder,
static const struct drm_encoder_helper_funcs sun4i_hdmi_helper_funcs = {
.atomic_check = sun4i_hdmi_atomic_check,
- .disable= sun4i_hdmi_disable,
- .enable = sun4i_hdmi_enable,
- .mode_set = sun4i_hdmi_mode_set,
+ .atomic_disable = sun4i_hdmi_disable,
+ .atomic_enable = sun4i_hdmi_enable,
+ .atomic_mode_set= sun4i_hdmi_mode_set,
.mode_valid = sun4i_hdmi_mode_valid,
};
--
2.41.0
[PATCH RFC v2 22/37] drm/rockchip: inno_hdmi: Remove useless output format
Similarly to the input format, the driver has a lot of code to deal with
various output format, but the driver hardcodes it to RGB always.
Let's get rid of the dead code.
Signed-off-by: Maxime Ripard
---
drivers/gpu/drm/rockchip/inno_hdmi.c | 57
1 file changed, 6 insertions(+), 51 deletions(-)
diff --git a/drivers/gpu/drm/rockchip/inno_hdmi.c
b/drivers/gpu/drm/rockchip/inno_hdmi.c
index e0696ab16da3..0c6c550e0ce7 100644
--- a/drivers/gpu/drm/rockchip/inno_hdmi.c
+++ b/drivers/gpu/drm/rockchip/inno_hdmi.c
@@ -28,7 +28,6 @@
#include "inno_hdmi.h"
struct hdmi_data_info {
- unsigned int enc_out_format;
unsigned int colorimetry;
};
@@ -296,26 +295,14 @@ static int inno_hdmi_config_video_avi(struct inno_hdmi
*hdmi,
rc = drm_hdmi_avi_infoframe_from_display_mode(&frame.avi,
&hdmi->connector,
mode);
-
- if (hdmi->hdmi_data.enc_out_format == HDMI_COLORSPACE_YUV444)
- frame.avi.colorspace = HDMI_COLORSPACE_YUV444;
- else if (hdmi->hdmi_data.enc_out_format == HDMI_COLORSPACE_YUV422)
- frame.avi.colorspace = HDMI_COLORSPACE_YUV422;
- else
- frame.avi.colorspace = HDMI_COLORSPACE_RGB;
+ frame.avi.colorspace = HDMI_COLORSPACE_RGB;
return inno_hdmi_upload_frame(hdmi, rc, &frame, INFOFRAME_AVI, 0, 0, 0);
}
static int inno_hdmi_config_video_csc(struct inno_hdmi *hdmi)
{
- struct hdmi_data_info *data = &hdmi->hdmi_data;
- int c0_c2_change = 0;
- int csc_enable = 0;
- int csc_mode = 0;
- int auto_csc = 0;
int value;
- int i;
/* Input video mode is SDR RGB24bit, data enable signal from external */
hdmi_writeb(hdmi, HDMI_VIDEO_CONTRL1, v_DE_EXTERNAL |
@@ -327,43 +314,13 @@ static int inno_hdmi_config_video_csc(struct inno_hdmi
*hdmi)
v_VIDEO_INPUT_CSP(0);
hdmi_writeb(hdmi, HDMI_VIDEO_CONTRL2, value);
- if (HDMI_COLORSPACE_RGB == data->enc_out_format) {
- value = v_SOF_DISABLE | v_COLOR_DEPTH_NOT_INDICATED(1);
- hdmi_writeb(hdmi, HDMI_VIDEO_CONTRL3, value);
-
- hdmi_modb(hdmi, HDMI_VIDEO_CONTRL,
- m_VIDEO_AUTO_CSC | m_VIDEO_C0_C2_SWAP,
- v_VIDEO_AUTO_CSC(AUTO_CSC_DISABLE) |
- v_VIDEO_C0_C2_SWAP(C0_C2_CHANGE_DISABLE));
- return 0;
- }
-
- if (data->colorimetry == HDMI_COLORIMETRY_ITU_601) {
- if (data->enc_out_format == HDMI_COLORSPACE_YUV444) {
- csc_mode = CSC_RGB_0_255_TO_ITU601_16_235_8BIT;
- auto_csc = AUTO_CSC_DISABLE;
- c0_c2_change = C0_C2_CHANGE_DISABLE;
- csc_enable = v_CSC_ENABLE;
- }
- } else {
- if (data->enc_out_format == HDMI_COLORSPACE_YUV444) {
- csc_mode = CSC_RGB_0_255_TO_ITU709_16_235_8BIT;
- auto_csc = AUTO_CSC_DISABLE;
- c0_c2_change = C0_C2_CHANGE_DISABLE;
- csc_enable = v_CSC_ENABLE;
- }
- }
-
- for (i = 0; i < 24; i++)
- hdmi_writeb(hdmi, HDMI_VIDEO_CSC_COEF + i,
- coeff_csc[csc_mode][i]);
-
- value = v_SOF_DISABLE | csc_enable | v_COLOR_DEPTH_NOT_INDICATED(1);
+ value = v_SOF_DISABLE | v_COLOR_DEPTH_NOT_INDICATED(1);
hdmi_writeb(hdmi, HDMI_VIDEO_CONTRL3, value);
- hdmi_modb(hdmi, HDMI_VIDEO_CONTRL, m_VIDEO_AUTO_CSC |
- m_VIDEO_C0_C2_SWAP, v_VIDEO_AUTO_CSC(auto_csc) |
- v_VIDEO_C0_C2_SWAP(c0_c2_change));
+ hdmi_modb(hdmi, HDMI_VIDEO_CONTRL,
+ m_VIDEO_AUTO_CSC | m_VIDEO_C0_C2_SWAP,
+ v_VIDEO_AUTO_CSC(AUTO_CSC_DISABLE) |
+ v_VIDEO_C0_C2_SWAP(C0_C2_CHANGE_DISABLE));
return 0;
}
@@ -425,8 +382,6 @@ static int inno_hdmi_setup(struct inno_hdmi *hdmi,
struct drm_display_info *display = &hdmi->connector.display_info;
u8 vic = drm_match_cea_mode(mode);
- hdmi->hdmi_data.enc_out_format = HDMI_COLORSPACE_RGB;
-
if ((vic == 6) || (vic == 7) ||
(vic == 21) || (vic == 22) ||
(vic == 2) || (vic == 3) ||
--
2.41.0
[PATCH RFC v2 27/37] drm/rockchip: inno_hdmi: Remove useless mode_valid
The inno_hdmi mode_valid implementation always return MODE_OK which is
what the core assumes when we don't have an implementation.
Let's get rid of it.
Signed-off-by: Maxime Ripard
---
drivers/gpu/drm/rockchip/inno_hdmi.c | 8
1 file changed, 8 deletions(-)
diff --git a/drivers/gpu/drm/rockchip/inno_hdmi.c
b/drivers/gpu/drm/rockchip/inno_hdmi.c
index e4fe02b79a98..59b2b676b7b8 100644
--- a/drivers/gpu/drm/rockchip/inno_hdmi.c
+++ b/drivers/gpu/drm/rockchip/inno_hdmi.c
@@ -400,13 +400,6 @@ static int inno_hdmi_connector_get_modes(struct
drm_connector *connector)
return ret;
}
-static enum drm_mode_status
-inno_hdmi_connector_mode_valid(struct drm_connector *connector,
- struct drm_display_mode *mode)
-{
- return MODE_OK;
-}
-
static int
inno_hdmi_probe_single_connector_modes(struct drm_connector *connector,
uint32_t maxX, uint32_t maxY)
@@ -431,7 +424,6 @@ static const struct drm_connector_funcs
inno_hdmi_connector_funcs = {
static struct drm_connector_helper_funcs inno_hdmi_connector_helper_funcs = {
.get_modes = inno_hdmi_connector_get_modes,
- .mode_valid = inno_hdmi_connector_mode_valid,
};
static int inno_hdmi_register(struct drm_device *drm, struct inno_hdmi *hdmi)
--
2.41.0
[PATCH RFC v2 32/37] drm/rockchip: inno_hdmi: Switch to HDMI connector
The new HDMI connector infrastructure allows to remove some boilerplate,
especially to generate infoframes. Let's switch to it.
Signed-off-by: Maxime Ripard
---
drivers/gpu/drm/rockchip/inno_hdmi.c | 101 ++-
1 file changed, 41 insertions(+), 60 deletions(-)
diff --git a/drivers/gpu/drm/rockchip/inno_hdmi.c
b/drivers/gpu/drm/rockchip/inno_hdmi.c
index d0b463d166fb..d5661ef5e00b 100644
--- a/drivers/gpu/drm/rockchip/inno_hdmi.c
+++ b/drivers/gpu/drm/rockchip/inno_hdmi.c
@@ -223,9 +223,10 @@ static u32 inno_hdmi_get_frame_enable(struct inno_hdmi
*hdmi,
return 0;
}
-static void inno_hdmi_disable_frame(struct inno_hdmi *hdmi,
- enum hdmi_infoframe_type type)
+static int inno_hdmi_disable_frame(struct drm_connector *connector,
+ enum hdmi_infoframe_type type)
{
+ struct inno_hdmi *hdmi = connector_to_inno_hdmi(connector);
u32 frame_index = inno_hdmi_get_frame_index(hdmi, type);
u32 disable = inno_hdmi_get_frame_disable(hdmi, type);
u32 mask = inno_hdmi_get_frame_mask(hdmi, type);
@@ -234,24 +235,23 @@ static void inno_hdmi_disable_frame(struct inno_hdmi
*hdmi,
hdmi_modb(hdmi, HDMI_PACKET_SEND_AUTO, mask, disable);
hdmi_writeb(hdmi, HDMI_CONTROL_PACKET_BUF_INDEX, frame_index);
+
+ return 0;
}
-static int inno_hdmi_upload_frame(struct inno_hdmi *hdmi,
- union hdmi_infoframe *frame, enum
hdmi_infoframe_type type)
+static int inno_hdmi_upload_frame(struct drm_connector *connector,
+ enum hdmi_infoframe_type type,
+ const u8 *buffer, size_t len)
{
+ struct inno_hdmi *hdmi = connector_to_inno_hdmi(connector);
u32 enable = inno_hdmi_get_frame_enable(hdmi, type);
u32 mask = inno_hdmi_get_frame_mask(hdmi, type);
u8 packed_frame[HDMI_MAXIMUM_INFO_FRAME_SIZE];
- ssize_t rc, i;
+ ssize_t i;
- inno_hdmi_disable_frame(hdmi, type);
+ inno_hdmi_disable_frame(connector, type);
- rc = hdmi_infoframe_pack(frame, packed_frame,
-sizeof(packed_frame));
- if (rc < 0)
- return rc;
-
- for (i = 0; i < rc; i++)
+ for (i = 0; i < len; i++)
hdmi_writeb(hdmi, HDMI_CONTROL_PACKET_ADDR + i,
packed_frame[i]);
@@ -261,41 +261,10 @@ static int inno_hdmi_upload_frame(struct inno_hdmi *hdmi,
return 0;
}
-static int inno_hdmi_config_video_vsi(struct inno_hdmi *hdmi,
- struct drm_display_mode *mode)
-{
- union hdmi_infoframe frame;
- int rc;
-
- rc = drm_hdmi_vendor_infoframe_from_display_mode(&frame.vendor.hdmi,
-&hdmi->connector,
-mode);
- if (rc) {
- inno_hdmi_disable_frame(hdmi, HDMI_INFOFRAME_TYPE_VENDOR);
- return rc;
- }
-
- return inno_hdmi_upload_frame(hdmi, &frame, HDMI_INFOFRAME_TYPE_VENDOR);
-}
-
-static int inno_hdmi_config_video_avi(struct inno_hdmi *hdmi,
- struct drm_display_mode *mode)
-{
- union hdmi_infoframe frame;
- int rc;
-
- rc = drm_hdmi_avi_infoframe_from_display_mode(&frame.avi,
- &hdmi->connector,
- mode);
- if (rc) {
- inno_hdmi_disable_frame(hdmi, HDMI_INFOFRAME_TYPE_AVI);
- return rc;
- }
-
- frame.avi.colorspace = HDMI_COLORSPACE_RGB;
-
- return inno_hdmi_upload_frame(hdmi, &frame, HDMI_INFOFRAME_TYPE_AVI);
-}
+static const struct drm_connector_hdmi_funcs inno_hdmi_hdmi_connector_funcs = {
+ .clear_infoframe= inno_hdmi_disable_frame,
+ .write_infoframe= inno_hdmi_upload_frame,
+};
static int inno_hdmi_config_video_csc(struct inno_hdmi *hdmi)
{
@@ -374,9 +343,12 @@ static int inno_hdmi_config_video_timing(struct inno_hdmi
*hdmi,
}
static int inno_hdmi_setup(struct inno_hdmi *hdmi,
- struct drm_display_mode *mode)
+ struct drm_crtc_state *new_crtc_state,
+ struct drm_connector_state *new_conn_state)
{
- struct drm_display_info *display = &hdmi->connector.display_info;
+ struct drm_connector *connector = &hdmi->connector;
+ struct drm_display_info *display = &connector->display_info;
+ struct drm_display_mode *mode = &new_crtc_state->adjusted_mode;
/* Mute video and audio output */
hdmi_modb(hdmi, HDMI_AV_MUTE, m_AUDIO_MUTE | m_VIDEO_BLACK,
@@ -390,10 +362,8 @@ static int inno_hdmi_setup(struct inno_hdmi *hdmi,
inno_hdmi_config_video_csc(hdmi);
- if (display->is_hdmi) {
-
