[PATCH v2 04/17] drm: cleanup: drm_modeset_lock_all() --> DRM_MODESET_LOCK_ALL_BEGIN()
As requested in Documentation/gpu/todo.rst, replace driver calls to
drm_modeset_lock_all() with DRM_MODESET_LOCK_ALL_BEGIN() and
DRM_MODESET_LOCK_ALL_END()
Signed-off-by: Fernando Ramos
Reviewed-by: Sean Paul
---
drivers/gpu/drm/drm_client_modeset.c | 5 +++--
drivers/gpu/drm/drm_crtc_helper.c| 18 --
drivers/gpu/drm/drm_fb_helper.c | 10 ++
drivers/gpu/drm/drm_framebuffer.c| 6 --
4 files changed, 25 insertions(+), 14 deletions(-)
diff --git a/drivers/gpu/drm/drm_client_modeset.c
b/drivers/gpu/drm/drm_client_modeset.c
index 5f5184f071ed..43f772543d2a 100644
--- a/drivers/gpu/drm/drm_client_modeset.c
+++ b/drivers/gpu/drm/drm_client_modeset.c
@@ -1062,9 +1062,10 @@ static int drm_client_modeset_commit_legacy(struct
drm_client_dev *client)
struct drm_device *dev = client->dev;
struct drm_mode_set *mode_set;
struct drm_plane *plane;
+ struct drm_modeset_acquire_ctx ctx;
int ret = 0;
- drm_modeset_lock_all(dev);
+ DRM_MODESET_LOCK_ALL_BEGIN(dev, ctx, 0, ret);
drm_for_each_plane(plane, dev) {
if (plane->type != DRM_PLANE_TYPE_PRIMARY)
drm_plane_force_disable(plane);
@@ -1093,7 +1094,7 @@ static int drm_client_modeset_commit_legacy(struct
drm_client_dev *client)
goto out;
}
out:
- drm_modeset_unlock_all(dev);
+ DRM_MODESET_LOCK_ALL_END(dev, ctx, ret);
return ret;
}
diff --git a/drivers/gpu/drm/drm_crtc_helper.c
b/drivers/gpu/drm/drm_crtc_helper.c
index bff917531f33..f3ce073dff79 100644
--- a/drivers/gpu/drm/drm_crtc_helper.c
+++ b/drivers/gpu/drm/drm_crtc_helper.c
@@ -218,11 +218,14 @@ static void __drm_helper_disable_unused_functions(struct
drm_device *dev)
*/
void drm_helper_disable_unused_functions(struct drm_device *dev)
{
+ struct drm_modeset_acquire_ctx ctx;
+ int ret;
+
WARN_ON(drm_drv_uses_atomic_modeset(dev));
- drm_modeset_lock_all(dev);
+ DRM_MODESET_LOCK_ALL_BEGIN(dev, ctx, 0, ret);
__drm_helper_disable_unused_functions(dev);
- drm_modeset_unlock_all(dev);
+ DRM_MODESET_LOCK_ALL_END(dev, ctx, ret);
}
EXPORT_SYMBOL(drm_helper_disable_unused_functions);
@@ -942,12 +945,14 @@ void drm_helper_resume_force_mode(struct drm_device *dev)
struct drm_crtc *crtc;
struct drm_encoder *encoder;
const struct drm_crtc_helper_funcs *crtc_funcs;
+ struct drm_modeset_acquire_ctx ctx;
int encoder_dpms;
bool ret;
+ int err;
WARN_ON(drm_drv_uses_atomic_modeset(dev));
- drm_modeset_lock_all(dev);
+ DRM_MODESET_LOCK_ALL_BEGIN(dev, ctx, 0, err);
drm_for_each_crtc(crtc, dev) {
if (!crtc->enabled)
@@ -982,7 +987,7 @@ void drm_helper_resume_force_mode(struct drm_device *dev)
/* disable the unused connectors while restoring the modesetting */
__drm_helper_disable_unused_functions(dev);
- drm_modeset_unlock_all(dev);
+ DRM_MODESET_LOCK_ALL_END(dev, ctx, err);
}
EXPORT_SYMBOL(drm_helper_resume_force_mode);
@@ -1002,9 +1007,10 @@ EXPORT_SYMBOL(drm_helper_resume_force_mode);
int drm_helper_force_disable_all(struct drm_device *dev)
{
struct drm_crtc *crtc;
+ struct drm_modeset_acquire_ctx ctx;
int ret = 0;
- drm_modeset_lock_all(dev);
+ DRM_MODESET_LOCK_ALL_BEGIN(dev, ctx, 0, ret);
drm_for_each_crtc(crtc, dev)
if (crtc->enabled) {
struct drm_mode_set set = {
@@ -1016,7 +1022,7 @@ int drm_helper_force_disable_all(struct drm_device *dev)
goto out;
}
out:
- drm_modeset_unlock_all(dev);
+ DRM_MODESET_LOCK_ALL_END(dev, ctx, ret);
return ret;
}
EXPORT_SYMBOL(drm_helper_force_disable_all);
diff --git a/drivers/gpu/drm/drm_fb_helper.c b/drivers/gpu/drm/drm_fb_helper.c
index 3ab078321045..6860223f0068 100644
--- a/drivers/gpu/drm/drm_fb_helper.c
+++ b/drivers/gpu/drm/drm_fb_helper.c
@@ -940,10 +940,11 @@ static int setcmap_legacy(struct fb_cmap *cmap, struct
fb_info *info)
struct drm_fb_helper *fb_helper = info->par;
struct drm_mode_set *modeset;
struct drm_crtc *crtc;
+ struct drm_modeset_acquire_ctx ctx;
u16 *r, *g, *b;
int ret = 0;
- drm_modeset_lock_all(fb_helper->dev);
+ DRM_MODESET_LOCK_ALL_BEGIN(fb_helper->dev, ctx, 0, ret);
drm_client_for_each_modeset(modeset, &fb_helper->client) {
crtc = modeset->crtc;
if (!crtc->funcs->gamma_set || !crtc->gamma_size) {
@@ -970,7 +971,7 @@ static int setcmap_legacy(struct fb_cmap *cmap, struct
fb_info *info)
goto out;
}
out:
- drm_modeset_unlock_all(fb_helper->dev);
+ DRM_MODESET_LOCK_ALL_END(fb_helper->dev, ctx, ret);
return ret;
}
@@ -1441,10 +1442,11 @@ static int pan_display_legacy(struc
[PATCH v2 03/17] drm/msm: cleanup: drm_modeset_lock_all_ctx() --> DRM_MODESET_LOCK_ALL_BEGIN()
As requested in Documentation/gpu/todo.rst, replace the boilerplate code
surrounding drm_modeset_lock_all_ctx() with DRM_MODESET_LOCK_ALL_BEGIN()
and DRM_MODESET_LOCK_ALL_END()
Signed-off-by: Fernando Ramos
Reviewed-by: Sean Paul
Reported-by: kernel test robot
---
drivers/gpu/drm/msm/disp/msm_disp_snapshot_util.c | 12 ++--
1 file changed, 6 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/msm/disp/msm_disp_snapshot_util.c
b/drivers/gpu/drm/msm/disp/msm_disp_snapshot_util.c
index cabe15190ec1..abda52f09b09 100644
--- a/drivers/gpu/drm/msm/disp/msm_disp_snapshot_util.c
+++ b/drivers/gpu/drm/msm/disp/msm_disp_snapshot_util.c
@@ -5,6 +5,8 @@
#define pr_fmt(fmt)"[drm:%s:%d] " fmt, __func__, __LINE__
+#include
+
#include "msm_disp_snapshot.h"
static void msm_disp_state_dump_regs(u32 **reg, u32 aligned_len, void __iomem
*base_addr)
@@ -99,20 +101,18 @@ static void msm_disp_capture_atomic_state(struct
msm_disp_state *disp_state)
{
struct drm_device *ddev;
struct drm_modeset_acquire_ctx ctx;
+ int ret;
disp_state->timestamp = ktime_get();
ddev = disp_state->drm_dev;
- drm_modeset_acquire_init(&ctx, 0);
-
- while (drm_modeset_lock_all_ctx(ddev, &ctx) != 0)
- drm_modeset_backoff(&ctx);
+ DRM_MODESET_LOCK_ALL_BEGIN(ddev, ctx, 0, ret);
disp_state->atomic_state = drm_atomic_helper_duplicate_state(ddev,
&ctx);
- drm_modeset_drop_locks(&ctx);
- drm_modeset_acquire_fini(&ctx);
+
+ DRM_MODESET_LOCK_ALL_END(ddev, ctx, ret);
}
void msm_disp_snapshot_capture_state(struct msm_disp_state *disp_state)
--
2.33.0
[PATCH v2 06/17] drm/tegra: cleanup: drm_modeset_lock_all() --> DRM_MODESET_LOCK_ALL_BEGIN()
As requested in Documentation/gpu/todo.rst, replace driver calls to
drm_modeset_lock_all() with DRM_MODESET_LOCK_ALL_BEGIN() and
DRM_MODESET_LOCK_ALL_END()
Signed-off-by: Fernando Ramos
Reviewed-by: Sean Paul
Reported-by: kernel test robot
---
drivers/gpu/drm/tegra/dsi.c | 6 --
drivers/gpu/drm/tegra/hdmi.c | 6 --
drivers/gpu/drm/tegra/sor.c | 11 +++
3 files changed, 15 insertions(+), 8 deletions(-)
diff --git a/drivers/gpu/drm/tegra/dsi.c b/drivers/gpu/drm/tegra/dsi.c
index f46d377f0c30..28050c188c1c 100644
--- a/drivers/gpu/drm/tegra/dsi.c
+++ b/drivers/gpu/drm/tegra/dsi.c
@@ -23,6 +23,7 @@
#include
#include
#include
+#include
#include "dc.h"
#include "drm.h"
@@ -202,10 +203,11 @@ static int tegra_dsi_show_regs(struct seq_file *s, void
*data)
struct tegra_dsi *dsi = node->info_ent->data;
struct drm_crtc *crtc = dsi->output.encoder.crtc;
struct drm_device *drm = node->minor->dev;
+ struct drm_modeset_acquire_ctx ctx;
unsigned int i;
int err = 0;
- drm_modeset_lock_all(drm);
+ DRM_MODESET_LOCK_ALL_BEGIN(drm, ctx, 0, err);
if (!crtc || !crtc->state->active) {
err = -EBUSY;
@@ -220,7 +222,7 @@ static int tegra_dsi_show_regs(struct seq_file *s, void
*data)
}
unlock:
- drm_modeset_unlock_all(drm);
+ DRM_MODESET_LOCK_ALL_END(drm, ctx, err);
return err;
}
diff --git a/drivers/gpu/drm/tegra/hdmi.c b/drivers/gpu/drm/tegra/hdmi.c
index e5d2a4026028..a62de7f92414 100644
--- a/drivers/gpu/drm/tegra/hdmi.c
+++ b/drivers/gpu/drm/tegra/hdmi.c
@@ -22,6 +22,7 @@
#include
#include
#include
+#include
#include "hda.h"
#include "hdmi.h"
@@ -1031,10 +1032,11 @@ static int tegra_hdmi_show_regs(struct seq_file *s,
void *data)
struct tegra_hdmi *hdmi = node->info_ent->data;
struct drm_crtc *crtc = hdmi->output.encoder.crtc;
struct drm_device *drm = node->minor->dev;
+ struct drm_modeset_acquire_ctx ctx;
unsigned int i;
int err = 0;
- drm_modeset_lock_all(drm);
+ DRM_MODESET_LOCK_ALL_BEGIN(drm, ctx, 0, err);
if (!crtc || !crtc->state->active) {
err = -EBUSY;
@@ -1049,7 +1051,7 @@ static int tegra_hdmi_show_regs(struct seq_file *s, void
*data)
}
unlock:
- drm_modeset_unlock_all(drm);
+ DRM_MODESET_LOCK_ALL_END(drm, ctx, err);
return err;
}
diff --git a/drivers/gpu/drm/tegra/sor.c b/drivers/gpu/drm/tegra/sor.c
index 0ea320c1092b..3d1c8b3d1358 100644
--- a/drivers/gpu/drm/tegra/sor.c
+++ b/drivers/gpu/drm/tegra/sor.c
@@ -23,6 +23,7 @@
#include
#include
#include
+#include
#include "dc.h"
#include "dp.h"
@@ -1490,10 +1491,11 @@ static int tegra_sor_show_crc(struct seq_file *s, void
*data)
struct tegra_sor *sor = node->info_ent->data;
struct drm_crtc *crtc = sor->output.encoder.crtc;
struct drm_device *drm = node->minor->dev;
+ struct drm_modeset_acquire_ctx ctx;
int err = 0;
u32 value;
- drm_modeset_lock_all(drm);
+ DRM_MODESET_LOCK_ALL_BEGIN(drm, ctx, 0, err);
if (!crtc || !crtc->state->active) {
err = -EBUSY;
@@ -1522,7 +1524,7 @@ static int tegra_sor_show_crc(struct seq_file *s, void
*data)
seq_printf(s, "%08x\n", value);
unlock:
- drm_modeset_unlock_all(drm);
+ DRM_MODESET_LOCK_ALL_END(drm, ctx, err);
return err;
}
@@ -1652,10 +1654,11 @@ static int tegra_sor_show_regs(struct seq_file *s, void
*data)
struct tegra_sor *sor = node->info_ent->data;
struct drm_crtc *crtc = sor->output.encoder.crtc;
struct drm_device *drm = node->minor->dev;
+ struct drm_modeset_acquire_ctx ctx;
unsigned int i;
int err = 0;
- drm_modeset_lock_all(drm);
+ DRM_MODESET_LOCK_ALL_BEGIN(drm, ctx, 0, err);
if (!crtc || !crtc->state->active) {
err = -EBUSY;
@@ -1670,7 +1673,7 @@ static int tegra_sor_show_regs(struct seq_file *s, void
*data)
}
unlock:
- drm_modeset_unlock_all(drm);
+ DRM_MODESET_LOCK_ALL_END(drm, ctx, err);
return err;
}
--
2.33.0
[PATCH v2 12/17] drm/i915: cleanup: drm_modeset_lock_all() --> DRM_MODESET_LOCK_ALL_BEGIN()
As requested in Documentation/gpu/todo.rst, replace driver calls to
drm_modeset_lock_all() with DRM_MODESET_LOCK_ALL_BEGIN() and
DRM_MODESET_LOCK_ALL_END()
Signed-off-by: Fernando Ramos
---
drivers/gpu/drm/i915/display/intel_audio.c| 16 ---
drivers/gpu/drm/i915/display/intel_display.c | 5 +-
.../drm/i915/display/intel_display_debugfs.c | 46 ---
drivers/gpu/drm/i915/display/intel_overlay.c | 6 ++-
drivers/gpu/drm/i915/display/intel_pipe_crc.c | 7 ++-
drivers/gpu/drm/i915/i915_drv.c | 13 --
6 files changed, 61 insertions(+), 32 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_audio.c
b/drivers/gpu/drm/i915/display/intel_audio.c
index 532237588511..c64f738cc062 100644
--- a/drivers/gpu/drm/i915/display/intel_audio.c
+++ b/drivers/gpu/drm/i915/display/intel_audio.c
@@ -26,6 +26,7 @@
#include
#include
+#include
#include "i915_drv.h"
#include "intel_atomic.h"
@@ -1214,7 +1215,8 @@ static int i915_audio_component_bind(struct device
*i915_kdev,
{
struct i915_audio_component *acomp = data;
struct drm_i915_private *dev_priv = kdev_to_i915(i915_kdev);
- int i;
+ struct drm_modeset_acquire_ctx ctx;
+ int i, ret;
if (drm_WARN_ON(&dev_priv->drm, acomp->base.ops || acomp->base.dev))
return -EEXIST;
@@ -1224,16 +1226,16 @@ static int i915_audio_component_bind(struct device
*i915_kdev,
DL_FLAG_STATELESS)))
return -ENOMEM;
- drm_modeset_lock_all(&dev_priv->drm);
+ DRM_MODESET_LOCK_ALL_BEGIN((&dev_priv->drm), ctx, 0, ret);
acomp->base.ops = &i915_audio_component_ops;
acomp->base.dev = i915_kdev;
BUILD_BUG_ON(MAX_PORTS != I915_MAX_PORTS);
for (i = 0; i < ARRAY_SIZE(acomp->aud_sample_rate); i++)
acomp->aud_sample_rate[i] = 0;
dev_priv->audio_component = acomp;
- drm_modeset_unlock_all(&dev_priv->drm);
+ DRM_MODESET_LOCK_ALL_END((&dev_priv->drm), ctx, ret);
- return 0;
+ return ret;
}
static void i915_audio_component_unbind(struct device *i915_kdev,
@@ -1241,12 +1243,14 @@ static void i915_audio_component_unbind(struct device
*i915_kdev,
{
struct i915_audio_component *acomp = data;
struct drm_i915_private *dev_priv = kdev_to_i915(i915_kdev);
+ struct drm_modeset_acquire_ctx ctx;
+ int ret;
- drm_modeset_lock_all(&dev_priv->drm);
+ DRM_MODESET_LOCK_ALL_BEGIN((&dev_priv->drm), ctx, 0, ret);
acomp->base.ops = NULL;
acomp->base.dev = NULL;
dev_priv->audio_component = NULL;
- drm_modeset_unlock_all(&dev_priv->drm);
+ DRM_MODESET_LOCK_ALL_END((&dev_priv->drm), ctx, ret);
device_link_remove(hda_kdev, i915_kdev);
diff --git a/drivers/gpu/drm/i915/display/intel_display.c
b/drivers/gpu/drm/i915/display/intel_display.c
index 2bf01416d656..297359411c5f 100644
--- a/drivers/gpu/drm/i915/display/intel_display.c
+++ b/drivers/gpu/drm/i915/display/intel_display.c
@@ -12512,6 +12512,7 @@ int intel_modeset_init_noirq(struct drm_i915_private
*i915)
int intel_modeset_init_nogem(struct drm_i915_private *i915)
{
struct drm_device *dev = &i915->drm;
+ struct drm_modeset_acquire_ctx ctx;
enum pipe pipe;
struct intel_crtc *crtc;
int ret;
@@ -12563,9 +12564,9 @@ int intel_modeset_init_nogem(struct drm_i915_private
*i915)
intel_vga_disable(i915);
intel_setup_outputs(i915);
- drm_modeset_lock_all(dev);
+ DRM_MODESET_LOCK_ALL_BEGIN(dev, ctx, 0, ret);
intel_modeset_setup_hw_state(dev, dev->mode_config.acquire_ctx);
- drm_modeset_unlock_all(dev);
+ DRM_MODESET_LOCK_ALL_END(dev, ctx, ret);
for_each_intel_crtc(dev, crtc) {
struct intel_initial_plane_config plane_config = {};
diff --git a/drivers/gpu/drm/i915/display/intel_display_debugfs.c
b/drivers/gpu/drm/i915/display/intel_display_debugfs.c
index 8fdacb252bb1..e0a6837996e7 100644
--- a/drivers/gpu/drm/i915/display/intel_display_debugfs.c
+++ b/drivers/gpu/drm/i915/display/intel_display_debugfs.c
@@ -5,6 +5,7 @@
#include
#include
+#include
#include "i915_debugfs.h"
#include "intel_display_debugfs.h"
@@ -1057,11 +1058,13 @@ static int i915_display_info(struct seq_file *m, void
*unused)
struct intel_crtc *crtc;
struct drm_connector *connector;
struct drm_connector_list_iter conn_iter;
+ struct drm_modeset_acquire_ctx ctx;
intel_wakeref_t wakeref;
+ int ret;
wakeref = intel_runtime_pm_get(&dev_priv->runtime_pm);
- drm_modeset_lock_all(dev);
+ DRM_MODESET_LOCK_ALL_BEGIN(dev, ctx, 0, ret);
seq_printf(m, "CRTC info\n");
seq_printf(m, "-\n");
@@ -1076,20 +1079,21 @@ static int i915_display_info(struct seq_file *m, void
*unused)
intel_connector_info(m, connector);
drm_connector_list_
[PATCH v2 00/17] drm: cleanup: Use DRM_MODESET_LOCK_ALL_* helpers where possible
Hi all,
One of the things in the DRM TODO list ("Documentation/gpu/todo.rst") was to
"use DRM_MODESET_LOCAL_ALL_* helpers instead of boilerplate". That's what this
patch series is about.
You will find two types of changes here:
- Replacing "drm_modeset_lock_all_ctx()" (and surrounding boilerplate) with
"DRM_MODESET_LOCK_ALL_BEGIN()/END()" in the remaining places (as it has
already been done in previous commits such as b7ea04d2)
- Replacing "drm_modeset_lock_all()" with "DRM_MODESET_LOCK_ALL_BEGIN()/END()"
in the remaining places (as it has already been done in previous commits
such as 57037094)
Most of the changes are straight forward, except for a few cases in the "amd"
and "i915" drivers where some extra dancing was needed to overcome the
limitation that the DRM_MODESET_LOCK_ALL_BEGIN()/END() macros can only be used
once inside the same function (the reason being that the macro expansion
includes *labels*, and you can not have two labels named the same inside one
function)
Notice that, even after this patch series, some places remain where
"drm_modeset_lock_all()" and "drm_modeset_lock_all_ctx()" are still present,
all inside drm core (which makes sense), except for two (in "amd" and "i915")
which cannot be replaced due to the way they are being used.
Changes in v2:
- Fix commit message typo
- Use the value returned by DRM_MODESET_LOCK_ALL_END when possible
- Split drm/i915 patch into two simpler ones
- Remove drm_modeset_(un)lock_all()
- Fix build problems in non-x86 platforms
Fernando Ramos (17):
drm: cleanup: drm_modeset_lock_all_ctx() --> DRM_MODESET_LOCK_ALL_BEGIN()
drm/i915: cleanup: drm_modeset_lock_all_ctx() --> DRM_MODESET_LOCK_ALL_BEGIN()
drm/msm: cleanup: drm_modeset_lock_all_ctx() --> DRM_MODESET_LOCK_ALL_BEGIN()
drm: cleanup: drm_modeset_lock_all() --> DRM_MODESET_LOCK_ALL_BEGIN()
drm/vmwgfx: cleanup: drm_modeset_lock_all() --> DRM_MODESET_LOCK_ALL_BEGIN()
drm/tegra: cleanup: drm_modeset_lock_all() --> DRM_MODESET_LOCK_ALL_BEGIN()
drm/shmobile: cleanup: drm_modeset_lock_all() --> DRM_MODESET_LOCK_ALL_BEGIN()
drm/radeon: cleanup: drm_modeset_lock_all() --> DRM_MODESET_LOCK_ALL_BEGIN()
drm/omapdrm: cleanup: drm_modeset_lock_all() --> DRM_MODESET_LOCK_ALL_BEGIN()
drm/nouveau: cleanup: drm_modeset_lock_all() --> DRM_MODESET_LOCK_ALL_BEGIN()
drm/msm: cleanup: drm_modeset_lock_all() --> DRM_MODESET_LOCK_ALL_BEGIN()
drm/i915: cleanup: drm_modeset_lock_all() --> DRM_MODESET_LOCK_ALL_BEGIN()
drm/i915: cleanup: drm_modeset_lock_all() --> DRM_MODESET_LOCK_ALL_BEGIN()
part 2
drm/gma500: cleanup: drm_modeset_lock_all() --> DRM_MODESET_LOCK_ALL_BEGIN()
drm/amd: cleanup: drm_modeset_lock_all() --> DRM_MODESET_LOCK_ALL_BEGIN()
drm: cleanup: remove drm_modeset_(un)lock_all()
doc: drm: remove TODO entry regarding DRM_MODSET_LOCK_ALL cleanup
Documentation/gpu/todo.rst| 17
Documentation/locking/ww-mutex-design.rst | 2 +-
drivers/gpu/drm/amd/amdgpu/amdgpu_display.c | 21 +++--
.../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 50 +-
.../amd/display/amdgpu_dm/amdgpu_dm_debugfs.c | 25 ++---
drivers/gpu/drm/drm_client_modeset.c | 14 ++-
drivers/gpu/drm/drm_crtc_helper.c | 18 ++--
drivers/gpu/drm/drm_fb_helper.c | 10 +-
drivers/gpu/drm/drm_framebuffer.c | 6 +-
drivers/gpu/drm/drm_modeset_lock.c| 94 +--
drivers/gpu/drm/gma500/psb_device.c | 18 ++--
drivers/gpu/drm/i915/display/intel_audio.c| 16 ++--
drivers/gpu/drm/i915/display/intel_display.c | 23 ++---
.../drm/i915/display/intel_display_debugfs.c | 46 +
drivers/gpu/drm/i915/display/intel_overlay.c | 46 -
drivers/gpu/drm/i915/display/intel_pipe_crc.c | 7 +-
drivers/gpu/drm/i915/i915_drv.c | 13 ++-
drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c | 10 +-
.../gpu/drm/msm/disp/msm_disp_snapshot_util.c | 12 +--
drivers/gpu/drm/nouveau/dispnv50/disp.c | 15 ++-
drivers/gpu/drm/omapdrm/omap_fb.c | 9 +-
drivers/gpu/drm/radeon/radeon_device.c| 21 +++--
drivers/gpu/drm/radeon/radeon_dp_mst.c| 10 +-
drivers/gpu/drm/shmobile/shmob_drm_drv.c | 6 +-
drivers/gpu/drm/tegra/dsi.c | 6 +-
drivers/gpu/drm/tegra/hdmi.c | 6 +-
drivers/gpu/drm/tegra/sor.c | 11 ++-
drivers/gpu/drm/vmwgfx/vmwgfx_ioctl.c | 11 ++-
drivers/gpu/drm/vmwgfx/vmwgfx_kms.c | 12 ++-
include/drm/drm_modeset_lock.h| 2 -
30 files changed, 265 insertions(+), 292 deletions(-)
base-commit: 6880fa6c56601bb8ed59df6c30fd390cc5f6dd8f
--
2.33.0
[PATCH v2 13/17] drm/i915: cleanup: drm_modeset_lock_all() --> DRM_MODESET_LOCK_ALL_BEGIN() part 2
As requested in Documentation/gpu/todo.rst, replace driver calls to
drm_modeset_lock_all() with DRM_MODESET_LOCK_ALL_BEGIN() and
DRM_MODESET_LOCK_ALL_END()
While the previous commit was a simple "search and replace", this time I
had to do a bit of refactoring as only one call to
DRM_MODESET_LOCK_ALL_BEGIN() is allowed inside one same function.
Signed-off-by: Fernando Ramos
---
drivers/gpu/drm/i915/display/intel_overlay.c | 40 ++--
1 file changed, 19 insertions(+), 21 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_overlay.c
b/drivers/gpu/drm/i915/display/intel_overlay.c
index c0ee135e5499..c623738c59c8 100644
--- a/drivers/gpu/drm/i915/display/intel_overlay.c
+++ b/drivers/gpu/drm/i915/display/intel_overlay.c
@@ -1105,6 +1105,7 @@ int intel_overlay_put_image_ioctl(struct drm_device *dev,
void *data,
struct drm_crtc *drmmode_crtc;
struct intel_crtc *crtc;
struct drm_i915_gem_object *new_bo;
+ struct drm_modeset_acquire_ctx ctx;
int ret;
overlay = dev_priv->overlay;
@@ -1113,24 +1114,24 @@ int intel_overlay_put_image_ioctl(struct drm_device
*dev, void *data,
return -ENODEV;
}
- if (!(params->flags & I915_OVERLAY_ENABLE)) {
- drm_modeset_lock_all(dev);
- ret = intel_overlay_switch_off(overlay);
- drm_modeset_unlock_all(dev);
+ if (params->flags & I915_OVERLAY_ENABLE) {
- return ret;
- }
+ drmmode_crtc = drm_crtc_find(dev, file_priv, params->crtc_id);
+ if (!drmmode_crtc)
+ return -ENOENT;
+ crtc = to_intel_crtc(drmmode_crtc);
- drmmode_crtc = drm_crtc_find(dev, file_priv, params->crtc_id);
- if (!drmmode_crtc)
- return -ENOENT;
- crtc = to_intel_crtc(drmmode_crtc);
+ new_bo = i915_gem_object_lookup(file_priv, params->bo_handle);
+ if (!new_bo)
+ return -ENOENT;
+ }
- new_bo = i915_gem_object_lookup(file_priv, params->bo_handle);
- if (!new_bo)
- return -ENOENT;
+ DRM_MODESET_LOCK_ALL_BEGIN(dev, ctx, 0, ret);
- drm_modeset_lock_all(dev);
+ if (!(params->flags & I915_OVERLAY_ENABLE)) {
+ ret = intel_overlay_switch_off(overlay);
+ goto out_unlock;
+ }
if (i915_gem_object_is_tiled(new_bo)) {
drm_dbg_kms(&dev_priv->drm,
@@ -1195,14 +1196,11 @@ int intel_overlay_put_image_ioctl(struct drm_device
*dev, void *data,
if (ret != 0)
goto out_unlock;
- drm_modeset_unlock_all(dev);
- i915_gem_object_put(new_bo);
-
- return 0;
-
out_unlock:
- drm_modeset_unlock_all(dev);
- i915_gem_object_put(new_bo);
+ DRM_MODESET_LOCK_ALL_END(dev, ctx, ret);
+
+ if (params->flags & I915_OVERLAY_ENABLE)
+ i915_gem_object_put(new_bo);
return ret;
}
--
2.33.0
[PATCH v2 07/17] drm/shmobile: cleanup: drm_modeset_lock_all() --> DRM_MODESET_LOCK_ALL_BEGIN()
As requested in Documentation/gpu/todo.rst, replace driver calls to
drm_modeset_lock_all() with DRM_MODESET_LOCK_ALL_BEGIN() and
DRM_MODESET_LOCK_ALL_END()
Signed-off-by: Fernando Ramos
Reviewed-by: Sean Paul
---
drivers/gpu/drm/shmobile/shmob_drm_drv.c | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/shmobile/shmob_drm_drv.c
b/drivers/gpu/drm/shmobile/shmob_drm_drv.c
index 7db01904d18d..8ee215ab614e 100644
--- a/drivers/gpu/drm/shmobile/shmob_drm_drv.c
+++ b/drivers/gpu/drm/shmobile/shmob_drm_drv.c
@@ -156,10 +156,12 @@ static int shmob_drm_pm_suspend(struct device *dev)
static int shmob_drm_pm_resume(struct device *dev)
{
struct shmob_drm_device *sdev = dev_get_drvdata(dev);
+ struct drm_modeset_acquire_ctx ctx;
+ int ret;
- drm_modeset_lock_all(sdev->ddev);
+ DRM_MODESET_LOCK_ALL_BEGIN(sdev->ddev, ctx, 0, ret);
shmob_drm_crtc_resume(&sdev->crtc);
- drm_modeset_unlock_all(sdev->ddev);
+ DRM_MODESET_LOCK_ALL_END(sdev->ddev, ctx, ret);
drm_kms_helper_poll_enable(sdev->ddev);
return 0;
--
2.33.0
[PATCH v2 08/17] drm/radeon: cleanup: drm_modeset_lock_all() --> DRM_MODESET_LOCK_ALL_BEGIN()
As requested in Documentation/gpu/todo.rst, replace driver calls to
drm_modeset_lock_all() with DRM_MODESET_LOCK_ALL_BEGIN() and
DRM_MODESET_LOCK_ALL_END()
Signed-off-by: Fernando Ramos
---
drivers/gpu/drm/radeon/radeon_device.c | 21 +++--
drivers/gpu/drm/radeon/radeon_dp_mst.c | 10 ++
2 files changed, 21 insertions(+), 10 deletions(-)
diff --git a/drivers/gpu/drm/radeon/radeon_device.c
b/drivers/gpu/drm/radeon/radeon_device.c
index 4f0fbf667431..7e31e5ce7f61 100644
--- a/drivers/gpu/drm/radeon/radeon_device.c
+++ b/drivers/gpu/drm/radeon/radeon_device.c
@@ -37,6 +37,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -1559,7 +1560,8 @@ int radeon_suspend_kms(struct drm_device *dev, bool
suspend,
struct pci_dev *pdev;
struct drm_crtc *crtc;
struct drm_connector *connector;
- int i, r;
+ struct drm_modeset_acquire_ctx ctx;
+ int i, r, ret;
if (dev == NULL || dev->dev_private == NULL) {
return -ENODEV;
@@ -1573,12 +1575,15 @@ int radeon_suspend_kms(struct drm_device *dev, bool
suspend,
drm_kms_helper_poll_disable(dev);
- drm_modeset_lock_all(dev);
+ DRM_MODESET_LOCK_ALL_BEGIN(dev, ctx, 0, ret);
/* turn off display hw */
list_for_each_entry(connector, &dev->mode_config.connector_list, head) {
drm_helper_connector_dpms(connector, DRM_MODE_DPMS_OFF);
}
- drm_modeset_unlock_all(dev);
+ DRM_MODESET_LOCK_ALL_END(dev, ctx, ret);
+
+ if (ret)
+ return ret;
/* unpin the front buffers and cursors */
list_for_each_entry(crtc, &dev->mode_config.crtc_list, head) {
@@ -1663,7 +1668,8 @@ int radeon_resume_kms(struct drm_device *dev, bool
resume, bool fbcon)
struct radeon_device *rdev = dev->dev_private;
struct pci_dev *pdev = to_pci_dev(dev->dev);
struct drm_crtc *crtc;
- int r;
+ struct drm_modeset_acquire_ctx ctx;
+ int r, ret;
if (dev->switch_power_state == DRM_SWITCH_POWER_OFF)
return 0;
@@ -1741,11 +1747,14 @@ int radeon_resume_kms(struct drm_device *dev, bool
resume, bool fbcon)
if (fbcon) {
drm_helper_resume_force_mode(dev);
/* turn on display hw */
- drm_modeset_lock_all(dev);
+ DRM_MODESET_LOCK_ALL_BEGIN(dev, ctx, 0, ret);
list_for_each_entry(connector,
&dev->mode_config.connector_list, head) {
drm_helper_connector_dpms(connector, DRM_MODE_DPMS_ON);
}
- drm_modeset_unlock_all(dev);
+ DRM_MODESET_LOCK_ALL_END(dev, ctx, ret);
+
+ if (ret)
+ return ret;
}
drm_kms_helper_poll_enable(dev);
diff --git a/drivers/gpu/drm/radeon/radeon_dp_mst.c
b/drivers/gpu/drm/radeon/radeon_dp_mst.c
index ec867fa880a4..3f83ee75b100 100644
--- a/drivers/gpu/drm/radeon/radeon_dp_mst.c
+++ b/drivers/gpu/drm/radeon/radeon_dp_mst.c
@@ -4,6 +4,7 @@
#include
#include
#include
+#include
#include "atom.h"
#include "ni_reg.h"
@@ -737,11 +738,12 @@ static int radeon_debugfs_mst_info_show(struct seq_file
*m, void *unused)
struct radeon_device *rdev = (struct radeon_device *)m->private;
struct drm_device *dev = rdev->ddev;
struct drm_connector *connector;
+ struct drm_modeset_acquire_ctx ctx;
struct radeon_connector *radeon_connector;
struct radeon_connector_atom_dig *dig_connector;
- int i;
+ int i, ret;
- drm_modeset_lock_all(dev);
+ DRM_MODESET_LOCK_ALL_BEGIN(dev, ctx, 0, ret);
list_for_each_entry(connector, &dev->mode_config.connector_list, head) {
if (connector->connector_type != DRM_MODE_CONNECTOR_DisplayPort)
continue;
@@ -759,8 +761,8 @@ static int radeon_debugfs_mst_info_show(struct seq_file *m,
void *unused)
radeon_connector->cur_stream_attribs[i].fe,
radeon_connector->cur_stream_attribs[i].slots);
}
- drm_modeset_unlock_all(dev);
- return 0;
+ DRM_MODESET_LOCK_ALL_END(dev, ctx, ret);
+ return ret;
}
DEFINE_SHOW_ATTRIBUTE(radeon_debugfs_mst_info);
--
2.33.0
[PATCH v2 05/17] drm/vmwgfx: cleanup: drm_modeset_lock_all() --> DRM_MODESET_LOCK_ALL_BEGIN()
As requested in Documentation/gpu/todo.rst, replace driver calls to
drm_modeset_lock_all() with DRM_MODESET_LOCK_ALL_BEGIN() and
DRM_MODESET_LOCK_ALL_END()
Signed-off-by: Fernando Ramos
Reviewed-by: Sean Paul
---
drivers/gpu/drm/vmwgfx/vmwgfx_ioctl.c | 11 +++
drivers/gpu/drm/vmwgfx/vmwgfx_kms.c | 12
2 files changed, 15 insertions(+), 8 deletions(-)
diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_ioctl.c
b/drivers/gpu/drm/vmwgfx/vmwgfx_ioctl.c
index 28af34ab6ed6..7df35c6f1458 100644
--- a/drivers/gpu/drm/vmwgfx/vmwgfx_ioctl.c
+++ b/drivers/gpu/drm/vmwgfx/vmwgfx_ioctl.c
@@ -28,6 +28,7 @@
#include "vmwgfx_drv.h"
#include "vmwgfx_devcaps.h"
#include
+#include
#include "vmwgfx_kms.h"
int vmw_getparam_ioctl(struct drm_device *dev, void *data,
@@ -172,6 +173,7 @@ int vmw_present_ioctl(struct drm_device *dev, void *data,
struct drm_vmw_rect __user *clips_ptr;
struct drm_vmw_rect *clips = NULL;
struct drm_framebuffer *fb;
+ struct drm_modeset_acquire_ctx ctx;
struct vmw_framebuffer *vfb;
struct vmw_resource *res;
uint32_t num_clips;
@@ -203,7 +205,7 @@ int vmw_present_ioctl(struct drm_device *dev, void *data,
goto out_no_copy;
}
- drm_modeset_lock_all(dev);
+ DRM_MODESET_LOCK_ALL_BEGIN(dev, ctx, 0, ret);
fb = drm_framebuffer_lookup(dev, file_priv, arg->fb_id);
if (!fb) {
@@ -231,7 +233,7 @@ int vmw_present_ioctl(struct drm_device *dev, void *data,
out_no_surface:
drm_framebuffer_put(fb);
out_no_fb:
- drm_modeset_unlock_all(dev);
+ DRM_MODESET_LOCK_ALL_END(dev, ctx, ret);
out_no_copy:
kfree(clips);
out_clips:
@@ -250,6 +252,7 @@ int vmw_present_readback_ioctl(struct drm_device *dev, void
*data,
struct drm_vmw_rect __user *clips_ptr;
struct drm_vmw_rect *clips = NULL;
struct drm_framebuffer *fb;
+ struct drm_modeset_acquire_ctx ctx;
struct vmw_framebuffer *vfb;
uint32_t num_clips;
int ret;
@@ -280,7 +283,7 @@ int vmw_present_readback_ioctl(struct drm_device *dev, void
*data,
goto out_no_copy;
}
- drm_modeset_lock_all(dev);
+ DRM_MODESET_LOCK_ALL_BEGIN(dev, ctx, 0, ret);
fb = drm_framebuffer_lookup(dev, file_priv, arg->fb_id);
if (!fb) {
@@ -303,7 +306,7 @@ int vmw_present_readback_ioctl(struct drm_device *dev, void
*data,
out_no_ttm_lock:
drm_framebuffer_put(fb);
out_no_fb:
- drm_modeset_unlock_all(dev);
+ DRM_MODESET_LOCK_ALL_END(dev, ctx, ret);
out_no_copy:
kfree(clips);
out_clips:
diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_kms.c
b/drivers/gpu/drm/vmwgfx/vmwgfx_kms.c
index 74fa41909213..268095cb8c84 100644
--- a/drivers/gpu/drm/vmwgfx/vmwgfx_kms.c
+++ b/drivers/gpu/drm/vmwgfx/vmwgfx_kms.c
@@ -33,6 +33,7 @@
#include
#include
#include
+#include
#include "vmwgfx_kms.h"
@@ -243,15 +244,17 @@ void vmw_kms_legacy_hotspot_clear(struct vmw_private
*dev_priv)
struct drm_device *dev = &dev_priv->drm;
struct vmw_display_unit *du;
struct drm_crtc *crtc;
+ struct drm_modeset_acquire_ctx ctx;
+ int ret;
- drm_modeset_lock_all(dev);
+ DRM_MODESET_LOCK_ALL_BEGIN(dev, ctx, 0, ret);
drm_for_each_crtc(crtc, dev) {
du = vmw_crtc_to_du(crtc);
du->hotspot_x = 0;
du->hotspot_y = 0;
}
- drm_modeset_unlock_all(dev);
+ DRM_MODESET_LOCK_ALL_END(dev, ctx, ret);
}
void vmw_kms_cursor_post_execbuf(struct vmw_private *dev_priv)
@@ -1012,9 +1015,10 @@ static int vmw_framebuffer_bo_dirty(struct
drm_framebuffer *framebuffer,
struct vmw_framebuffer_bo *vfbd =
vmw_framebuffer_to_vfbd(framebuffer);
struct drm_clip_rect norect;
+ struct drm_modeset_acquire_ctx ctx;
int ret, increment = 1;
- drm_modeset_lock_all(&dev_priv->drm);
+ DRM_MODESET_LOCK_ALL_BEGIN((&dev_priv->drm), ctx, 0, ret);
if (!num_clips) {
num_clips = 1;
@@ -1040,7 +1044,7 @@ static int vmw_framebuffer_bo_dirty(struct
drm_framebuffer *framebuffer,
vmw_cmd_flush(dev_priv, false);
- drm_modeset_unlock_all(&dev_priv->drm);
+ DRM_MODESET_LOCK_ALL_END((&dev_priv->drm), ctx, ret);
return ret;
}
--
2.33.0
[PATCH v2 09/17] drm/omapdrm: cleanup: drm_modeset_lock_all() --> DRM_MODESET_LOCK_ALL_BEGIN()
As requested in Documentation/gpu/todo.rst, replace driver calls to
drm_modeset_lock_all() with DRM_MODESET_LOCK_ALL_BEGIN() and
DRM_MODESET_LOCK_ALL_END()
Signed-off-by: Fernando Ramos
Reviewed-by: Sean Paul
---
drivers/gpu/drm/omapdrm/omap_fb.c | 9 ++---
1 file changed, 6 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/omapdrm/omap_fb.c
b/drivers/gpu/drm/omapdrm/omap_fb.c
index 190afc564914..fa7636c13c19 100644
--- a/drivers/gpu/drm/omapdrm/omap_fb.c
+++ b/drivers/gpu/drm/omapdrm/omap_fb.c
@@ -9,6 +9,7 @@
#include
#include
#include
+#include
#include "omap_dmm_tiler.h"
#include "omap_drv.h"
@@ -62,15 +63,17 @@ static int omap_framebuffer_dirty(struct drm_framebuffer
*fb,
unsigned num_clips)
{
struct drm_crtc *crtc;
+ struct drm_modeset_acquire_ctx ctx;
+ int ret;
- drm_modeset_lock_all(fb->dev);
+ DRM_MODESET_LOCK_ALL_BEGIN(fb->dev, ctx, 0, ret);
drm_for_each_crtc(crtc, fb->dev)
omap_crtc_flush(crtc);
- drm_modeset_unlock_all(fb->dev);
+ DRM_MODESET_LOCK_ALL_END(fb->dev, ctx, ret);
- return 0;
+ return ret;
}
static const struct drm_framebuffer_funcs omap_framebuffer_funcs = {
--
2.33.0
[PATCH v2 01/17] drm: cleanup: drm_modeset_lock_all_ctx() --> DRM_MODESET_LOCK_ALL_BEGIN()
As requested in Documentation/gpu/todo.rst, replace the boilerplate code surrounding drm_modeset_lock_all_ctx() with DRM_MODESET_LOCK_ALL_BEGIN() and DRM_MODESET_LOCK_ALL_END() Signed-off-by: Fernando Ramos --- drivers/gpu/drm/drm_client_modeset.c | 9 +++-- 1 file changed, 3 insertions(+), 6 deletions(-) diff --git a/drivers/gpu/drm/drm_client_modeset.c b/drivers/gpu/drm/drm_client_modeset.c index ced09c7c06f9..5f5184f071ed 100644 --- a/drivers/gpu/drm/drm_client_modeset.c +++ b/drivers/gpu/drm/drm_client_modeset.c @@ -574,6 +574,7 @@ static bool drm_client_firmware_config(struct drm_client_dev *client, int num_connectors_detected = 0; int num_tiled_conns = 0; struct drm_modeset_acquire_ctx ctx; + int err; if (!drm_drv_uses_atomic_modeset(dev)) return false; @@ -585,10 +586,7 @@ static bool drm_client_firmware_config(struct drm_client_dev *client, if (!save_enabled) return false; - drm_modeset_acquire_init(&ctx, 0); - - while (drm_modeset_lock_all_ctx(dev, &ctx) != 0) - drm_modeset_backoff(&ctx); + DRM_MODESET_LOCK_ALL_BEGIN(dev, ctx, 0, err); memcpy(save_enabled, enabled, count); mask = GENMASK(count - 1, 0); @@ -743,8 +741,7 @@ static bool drm_client_firmware_config(struct drm_client_dev *client, ret = false; } - drm_modeset_drop_locks(&ctx); - drm_modeset_acquire_fini(&ctx); + DRM_MODESET_LOCK_ALL_END(dev, ctx, err); kfree(save_enabled); return ret; -- 2.33.0
[PATCH v2 02/17] drm/i915: cleanup: drm_modeset_lock_all_ctx() --> DRM_MODESET_LOCK_ALL_BEGIN()
As requested in Documentation/gpu/todo.rst, replace the boilerplate code
surrounding drm_modeset_lock_all_ctx() with DRM_MODESET_LOCK_ALL_BEGIN()
and DRM_MODESET_LOCK_ALL_END()
Signed-off-by: Fernando Ramos
Reviewed-by: Sean Paul
---
drivers/gpu/drm/i915/display/intel_display.c | 18 +-
1 file changed, 5 insertions(+), 13 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_display.c
b/drivers/gpu/drm/i915/display/intel_display.c
index 134a6acbd8fb..2bf01416d656 100644
--- a/drivers/gpu/drm/i915/display/intel_display.c
+++ b/drivers/gpu/drm/i915/display/intel_display.c
@@ -43,6 +43,7 @@
#include
#include
#include
+#include
#include "display/intel_audio.h"
#include "display/intel_crt.h"
@@ -13476,22 +13477,13 @@ void intel_display_resume(struct drm_device *dev)
if (state)
state->acquire_ctx = &ctx;
- drm_modeset_acquire_init(&ctx, 0);
-
- while (1) {
- ret = drm_modeset_lock_all_ctx(dev, &ctx);
- if (ret != -EDEADLK)
- break;
-
- drm_modeset_backoff(&ctx);
- }
+ DRM_MODESET_LOCK_ALL_BEGIN(dev, ctx, 0, ret);
- if (!ret)
- ret = __intel_display_resume(dev, state, &ctx);
+ ret = __intel_display_resume(dev, state, &ctx);
intel_enable_ipc(dev_priv);
- drm_modeset_drop_locks(&ctx);
- drm_modeset_acquire_fini(&ctx);
+
+ DRM_MODESET_LOCK_ALL_END(dev, ctx, ret);
if (ret)
drm_err(&dev_priv->drm,
--
2.33.0
[PATCH v2 15/17] drm/amd: cleanup: drm_modeset_lock_all() --> DRM_MODESET_LOCK_ALL_BEGIN()
As requested in Documentation/gpu/todo.rst, replace driver calls to
drm_modeset_lock_all() with DRM_MODESET_LOCK_ALL_BEGIN() and
DRM_MODESET_LOCK_ALL_END()
Signed-off-by: Fernando Ramos
---
drivers/gpu/drm/amd/amdgpu/amdgpu_display.c | 21 +---
.../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 50 +--
.../amd/display/amdgpu_dm/amdgpu_dm_debugfs.c | 25 ++
3 files changed, 53 insertions(+), 43 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_display.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_display.c
index 7a7316731911..b07e845a2600 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_display.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_display.c
@@ -40,6 +40,7 @@
#include
#include
#include
+#include
static void amdgpu_display_flip_callback(struct dma_fence *f,
struct dma_fence_cb *cb)
@@ -1543,16 +1544,21 @@ int amdgpu_display_suspend_helper(struct amdgpu_device
*adev)
struct drm_crtc *crtc;
struct drm_connector *connector;
struct drm_connector_list_iter iter;
- int r;
+ struct drm_modeset_acquire_ctx ctx;
+ int r, ret;
/* turn off display hw */
- drm_modeset_lock_all(dev);
+ DRM_MODESET_LOCK_ALL_BEGIN(dev, ctx, 0, ret);
drm_connector_list_iter_begin(dev, &iter);
drm_for_each_connector_iter(connector, &iter)
drm_helper_connector_dpms(connector,
DRM_MODE_DPMS_OFF);
drm_connector_list_iter_end(&iter);
- drm_modeset_unlock_all(dev);
+ DRM_MODESET_LOCK_ALL_END(dev, ctx, ret);
+
+ if (ret)
+ return ret;
+
/* unpin the front buffers and cursors */
list_for_each_entry(crtc, &dev->mode_config.crtc_list, head) {
struct amdgpu_crtc *amdgpu_crtc = to_amdgpu_crtc(crtc);
@@ -1590,7 +1596,8 @@ int amdgpu_display_resume_helper(struct amdgpu_device
*adev)
struct drm_connector *connector;
struct drm_connector_list_iter iter;
struct drm_crtc *crtc;
- int r;
+ struct drm_modeset_acquire_ctx ctx;
+ int r, ret;
/* pin cursors */
list_for_each_entry(crtc, &dev->mode_config.crtc_list, head) {
@@ -1612,7 +1619,7 @@ int amdgpu_display_resume_helper(struct amdgpu_device
*adev)
drm_helper_resume_force_mode(dev);
/* turn on display hw */
- drm_modeset_lock_all(dev);
+ DRM_MODESET_LOCK_ALL_BEGIN(dev, ctx, 0, ret);
drm_connector_list_iter_begin(dev, &iter);
drm_for_each_connector_iter(connector, &iter)
@@ -1620,8 +1627,8 @@ int amdgpu_display_resume_helper(struct amdgpu_device
*adev)
DRM_MODE_DPMS_ON);
drm_connector_list_iter_end(&iter);
- drm_modeset_unlock_all(dev);
+ DRM_MODESET_LOCK_ALL_END(dev, ctx, ret);
- return 0;
+ return ret;
}
diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
index 9b1fc54555ee..5196c1d26f87 100644
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
@@ -80,6 +80,7 @@
#include
#include
#include
+#include
#if defined(CONFIG_DRM_AMD_DC_DCN)
#include "ivsrcid/dcn/irqsrcs_dcn_1_0.h"
@@ -2621,6 +2622,9 @@ static void handle_hpd_irq(void *param)
#ifdef CONFIG_DRM_AMD_DC_HDCP
struct dm_connector_state *dm_con_state =
to_dm_connector_state(connector->state);
#endif
+ struct drm_modeset_acquire_ctx ctx;
+ int ret;
+
if (adev->dm.disable_hpd_irq)
return;
@@ -2646,14 +2650,6 @@ static void handle_hpd_irq(void *param)
if (aconnector->base.force && new_connection_type ==
dc_connection_none) {
emulated_link_detect(aconnector->dc_link);
-
- drm_modeset_lock_all(dev);
- dm_restore_drm_connector_state(dev, connector);
- drm_modeset_unlock_all(dev);
-
- if (aconnector->base.force == DRM_FORCE_UNSPECIFIED)
- drm_kms_helper_hotplug_event(dev);
-
} else if (dc_link_detect(aconnector->dc_link, DETECT_REASON_HPD)) {
if (new_connection_type == dc_connection_none &&
aconnector->dc_link->type == dc_connection_none)
@@ -2661,13 +2657,18 @@ static void handle_hpd_irq(void *param)
amdgpu_dm_update_connector_after_detect(aconnector);
- drm_modeset_lock_all(dev);
- dm_restore_drm_connector_state(dev, connector);
- drm_modeset_unlock_all(dev);
-
- if (aconnector->base.force == DRM_FORCE_UNSPECIFIED)
- drm_kms_helper_hotplug_event(dev);
+ } else {
+ goto out;
}
+
+ DRM_MODESET_LOCK_ALL_BEGIN(dev, ctx, 0, ret);
+ dm_restore_drm_connector_state(dev, connector);
+ DRM_MODESET_LOCK_ALL_END(dev, ctx,
[PATCH v2 11/17] drm/msm: cleanup: drm_modeset_lock_all() --> DRM_MODESET_LOCK_ALL_BEGIN()
As requested in Documentation/gpu/todo.rst, replace driver calls to drm_modeset_lock_all() with DRM_MODESET_LOCK_ALL_BEGIN() and DRM_MODESET_LOCK_ALL_END() Signed-off-by: Fernando Ramos --- drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c | 10 ++ 1 file changed, 6 insertions(+), 4 deletions(-) diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c b/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c index 768012243b44..b89687074890 100644 --- a/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c +++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c @@ -18,6 +18,7 @@ #include #include #include +#include #include "dpu_kms.h" #include "dpu_hw_lm.h" @@ -1172,14 +1173,15 @@ static int _dpu_debugfs_status_show(struct seq_file *s, void *data) struct drm_display_mode *mode; struct drm_framebuffer *fb; struct drm_plane_state *state; + struct drm_modeset_acquire_ctx ctx; struct dpu_crtc_state *cstate; - int i, out_width; + int i, out_width, ret; dpu_crtc = s->private; crtc = &dpu_crtc->base; - drm_modeset_lock_all(crtc->dev); + DRM_MODESET_LOCK_ALL_BEGIN(crtc->dev, ctx, 0, ret); cstate = to_dpu_crtc_state(crtc->state); mode = &crtc->state->adjusted_mode; @@ -1263,9 +1265,9 @@ static int _dpu_debugfs_status_show(struct seq_file *s, void *data) dpu_crtc->vblank_cb_time = ktime_set(0, 0); } - drm_modeset_unlock_all(crtc->dev); + DRM_MODESET_LOCK_ALL_END(crtc->dev, ctx, ret); - return 0; + return ret; } DEFINE_SHOW_ATTRIBUTE(_dpu_debugfs_status); -- 2.33.0
[PATCH v2 17/17] doc: drm: remove TODO entry regarding DRM_MODSET_LOCK_ALL cleanup
The previous commits do exactly what this entry in the TODO file asks for, thus we can remove it now as it is no longer applicable. Signed-off-by: Fernando Ramos Reviewed-by: Sean Paul --- Documentation/gpu/todo.rst| 17 - Documentation/locking/ww-mutex-design.rst | 2 +- 2 files changed, 1 insertion(+), 18 deletions(-) diff --git a/Documentation/gpu/todo.rst b/Documentation/gpu/todo.rst index 12e61869939e..6613543955e9 100644 --- a/Documentation/gpu/todo.rst +++ b/Documentation/gpu/todo.rst @@ -353,23 +353,6 @@ converted, except for struct drm_driver.gem_prime_mmap. Level: Intermediate -Use DRM_MODESET_LOCK_ALL_* helpers instead of boilerplate -- - -For cases where drivers are attempting to grab the modeset locks with a local -acquire context. Replace the boilerplate code surrounding -drm_modeset_lock_all_ctx() with DRM_MODESET_LOCK_ALL_BEGIN() and -DRM_MODESET_LOCK_ALL_END() instead. - -This should also be done for all places where drm_modeset_lock_all() is still -used. - -As a reference, take a look at the conversions already completed in drm core. - -Contact: Sean Paul, respective driver maintainers - -Level: Starter - Rename CMA helpers to DMA helpers - diff --git a/Documentation/locking/ww-mutex-design.rst b/Documentation/locking/ww-mutex-design.rst index 6a4d7319f8f0..6a8f8beb9ec4 100644 --- a/Documentation/locking/ww-mutex-design.rst +++ b/Documentation/locking/ww-mutex-design.rst @@ -60,7 +60,7 @@ Concepts Compared to normal mutexes two additional concepts/objects show up in the lock interface for w/w mutexes: -Acquire context: To ensure eventual forward progress it is important the a task +Acquire context: To ensure eventual forward progress it is important that a task trying to acquire locks doesn't grab a new reservation id, but keeps the one it acquired when starting the lock acquisition. This ticket is stored in the acquire context. Furthermore the acquire context keeps track of debugging state -- 2.33.0
[PATCH v2 16/17] drm: cleanup: remove drm_modeset_(un)lock_all()
Functions drm_modeset_lock_all() and drm_modeset_unlock_all() are no
longer used anywhere and can be removed.
Signed-off-by: Fernando Ramos
---
drivers/gpu/drm/drm_modeset_lock.c | 94 +-
include/drm/drm_modeset_lock.h | 2 -
2 files changed, 3 insertions(+), 93 deletions(-)
diff --git a/drivers/gpu/drm/drm_modeset_lock.c
b/drivers/gpu/drm/drm_modeset_lock.c
index fcfe1a03c4a1..afd1351749a5 100644
--- a/drivers/gpu/drm/drm_modeset_lock.c
+++ b/drivers/gpu/drm/drm_modeset_lock.c
@@ -77,93 +77,6 @@
static DEFINE_WW_CLASS(crtc_ww_class);
-/**
- * drm_modeset_lock_all - take all modeset locks
- * @dev: DRM device
- *
- * This function takes all modeset locks, suitable where a more fine-grained
- * scheme isn't (yet) implemented. Locks must be dropped by calling the
- * drm_modeset_unlock_all() function.
- *
- * This function is deprecated. It allocates a lock acquisition context and
- * stores it in &drm_device.mode_config. This facilitate conversion of
- * existing code because it removes the need to manually deal with the
- * acquisition context, but it is also brittle because the context is global
- * and care must be taken not to nest calls. New code should use the
- * drm_modeset_lock_all_ctx() function and pass in the context explicitly.
- */
-void drm_modeset_lock_all(struct drm_device *dev)
-{
- struct drm_mode_config *config = &dev->mode_config;
- struct drm_modeset_acquire_ctx *ctx;
- int ret;
-
- ctx = kzalloc(sizeof(*ctx), GFP_KERNEL | __GFP_NOFAIL);
- if (WARN_ON(!ctx))
- return;
-
- mutex_lock(&config->mutex);
-
- drm_modeset_acquire_init(ctx, 0);
-
-retry:
- ret = drm_modeset_lock_all_ctx(dev, ctx);
- if (ret < 0) {
- if (ret == -EDEADLK) {
- drm_modeset_backoff(ctx);
- goto retry;
- }
-
- drm_modeset_acquire_fini(ctx);
- kfree(ctx);
- return;
- }
- ww_acquire_done(&ctx->ww_ctx);
-
- WARN_ON(config->acquire_ctx);
-
- /*
-* We hold the locks now, so it is safe to stash the acquisition
-* context for drm_modeset_unlock_all().
-*/
- config->acquire_ctx = ctx;
-
- drm_warn_on_modeset_not_all_locked(dev);
-}
-EXPORT_SYMBOL(drm_modeset_lock_all);
-
-/**
- * drm_modeset_unlock_all - drop all modeset locks
- * @dev: DRM device
- *
- * This function drops all modeset locks taken by a previous call to the
- * drm_modeset_lock_all() function.
- *
- * This function is deprecated. It uses the lock acquisition context stored
- * in &drm_device.mode_config. This facilitates conversion of existing
- * code because it removes the need to manually deal with the acquisition
- * context, but it is also brittle because the context is global and care must
- * be taken not to nest calls. New code should pass the acquisition context
- * directly to the drm_modeset_drop_locks() function.
- */
-void drm_modeset_unlock_all(struct drm_device *dev)
-{
- struct drm_mode_config *config = &dev->mode_config;
- struct drm_modeset_acquire_ctx *ctx = config->acquire_ctx;
-
- if (WARN_ON(!ctx))
- return;
-
- config->acquire_ctx = NULL;
- drm_modeset_drop_locks(ctx);
- drm_modeset_acquire_fini(ctx);
-
- kfree(ctx);
-
- mutex_unlock(&dev->mode_config.mutex);
-}
-EXPORT_SYMBOL(drm_modeset_unlock_all);
-
/**
* drm_warn_on_modeset_not_all_locked - check that all modeset locks are locked
* @dev: device
@@ -380,10 +293,9 @@ EXPORT_SYMBOL(drm_modeset_unlock);
* This function takes all modeset locks, suitable where a more fine-grained
* scheme isn't (yet) implemented.
*
- * Unlike drm_modeset_lock_all(), it doesn't take the &drm_mode_config.mutex
- * since that lock isn't required for modeset state changes. Callers which
- * need to grab that lock too need to do so outside of the acquire context
- * @ctx.
+ * It doesn't take the &drm_mode_config.mutex since that lock isn't required
for
+ * modeset state changes. Callers which need to grab that lock too need to do
so
+ * outside of the acquire context @ctx.
*
* Locks acquired with this function should be released by calling the
* drm_modeset_drop_locks() function on @ctx.
diff --git a/include/drm/drm_modeset_lock.h b/include/drm/drm_modeset_lock.h
index aafd07388eb7..865e64bcc4cb 100644
--- a/include/drm/drm_modeset_lock.h
+++ b/include/drm/drm_modeset_lock.h
@@ -132,8 +132,6 @@ struct drm_device;
struct drm_crtc;
struct drm_plane;
-void drm_modeset_lock_all(struct drm_device *dev);
-void drm_modeset_unlock_all(struct drm_device *dev);
void drm_warn_on_modeset_not_all_locked(struct drm_device *dev);
int drm_modeset_lock_all_ctx(struct drm_device *dev,
--
2.33.0
[PATCH v2 10/17] drm/nouveau: cleanup: drm_modeset_lock_all() --> DRM_MODESET_LOCK_ALL_BEGIN()
As requested in Documentation/gpu/todo.rst, replace driver calls to
drm_modeset_lock_all() with DRM_MODESET_LOCK_ALL_BEGIN() and
DRM_MODESET_LOCK_ALL_END()
Signed-off-by: Fernando Ramos
Reviewed-by: Sean Paul
---
drivers/gpu/drm/nouveau/dispnv50/disp.c | 15 ++-
1 file changed, 10 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/nouveau/dispnv50/disp.c
b/drivers/gpu/drm/nouveau/dispnv50/disp.c
index d7b9f7f8c9e3..86e18a844953 100644
--- a/drivers/gpu/drm/nouveau/dispnv50/disp.c
+++ b/drivers/gpu/drm/nouveau/dispnv50/disp.c
@@ -42,6 +42,7 @@
#include
#include
#include
+#include
#include
@@ -667,16 +668,18 @@ nv50_audio_component_bind(struct device *kdev, struct
device *hda_kdev,
struct drm_device *drm_dev = dev_get_drvdata(kdev);
struct nouveau_drm *drm = nouveau_drm(drm_dev);
struct drm_audio_component *acomp = data;
+ struct drm_modeset_acquire_ctx ctx;
+ int ret;
if (WARN_ON(!device_link_add(hda_kdev, kdev, DL_FLAG_STATELESS)))
return -ENOMEM;
- drm_modeset_lock_all(drm_dev);
+ DRM_MODESET_LOCK_ALL_BEGIN(drm_dev, ctx, 0, ret);
acomp->ops = &nv50_audio_component_ops;
acomp->dev = kdev;
drm->audio.component = acomp;
- drm_modeset_unlock_all(drm_dev);
- return 0;
+ DRM_MODESET_LOCK_ALL_END(drm_dev, ctx, ret);
+ return ret;
}
static void
@@ -686,12 +689,14 @@ nv50_audio_component_unbind(struct device *kdev, struct
device *hda_kdev,
struct drm_device *drm_dev = dev_get_drvdata(kdev);
struct nouveau_drm *drm = nouveau_drm(drm_dev);
struct drm_audio_component *acomp = data;
+ struct drm_modeset_acquire_ctx ctx;
+ int ret;
- drm_modeset_lock_all(drm_dev);
+ DRM_MODESET_LOCK_ALL_BEGIN(drm_dev, ctx, 0, ret);
drm->audio.component = NULL;
acomp->ops = NULL;
acomp->dev = NULL;
- drm_modeset_unlock_all(drm_dev);
+ DRM_MODESET_LOCK_ALL_END(drm_dev, ctx, ret);
}
static const struct component_ops nv50_audio_component_bind_ops = {
--
2.33.0
[PATCH v2 14/17] drm/gma500: cleanup: drm_modeset_lock_all() --> DRM_MODESET_LOCK_ALL_BEGIN()
As requested in Documentation/gpu/todo.rst, replace driver calls to
drm_modeset_lock_all() with DRM_MODESET_LOCK_ALL_BEGIN() and
DRM_MODESET_LOCK_ALL_END()
Signed-off-by: Fernando Ramos
---
drivers/gpu/drm/gma500/psb_device.c | 18 --
1 file changed, 12 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/gma500/psb_device.c
b/drivers/gpu/drm/gma500/psb_device.c
index 951725a0f7a3..98d06736dbaa 100644
--- a/drivers/gpu/drm/gma500/psb_device.c
+++ b/drivers/gpu/drm/gma500/psb_device.c
@@ -8,6 +8,7 @@
#include
#include
+#include
#include "gma_device.h"
#include "intel_bios.h"
@@ -169,8 +170,10 @@ static int psb_save_display_registers(struct drm_device
*dev)
{
struct drm_psb_private *dev_priv = dev->dev_private;
struct drm_crtc *crtc;
+ struct drm_modeset_acquire_ctx ctx;
struct gma_connector *connector;
struct psb_state *regs = &dev_priv->regs.psb;
+ int ret;
/* Display arbitration control + watermarks */
regs->saveDSPARB = PSB_RVDC32(DSPARB);
@@ -183,7 +186,7 @@ static int psb_save_display_registers(struct drm_device
*dev)
regs->saveCHICKENBIT = PSB_RVDC32(DSPCHICKENBIT);
/* Save crtc and output state */
- drm_modeset_lock_all(dev);
+ DRM_MODESET_LOCK_ALL_BEGIN(dev, ctx, 0, ret);
list_for_each_entry(crtc, &dev->mode_config.crtc_list, head) {
if (drm_helper_crtc_in_use(crtc))
dev_priv->ops->save_crtc(crtc);
@@ -193,8 +196,9 @@ static int psb_save_display_registers(struct drm_device
*dev)
if (connector->save)
connector->save(&connector->base);
- drm_modeset_unlock_all(dev);
- return 0;
+ DRM_MODESET_LOCK_ALL_END(dev, ctx, ret);
+
+ return ret;
}
/**
@@ -207,8 +211,10 @@ static int psb_restore_display_registers(struct drm_device
*dev)
{
struct drm_psb_private *dev_priv = dev->dev_private;
struct drm_crtc *crtc;
+ struct drm_modeset_acquire_ctx ctx;
struct gma_connector *connector;
struct psb_state *regs = &dev_priv->regs.psb;
+ int ret;
/* Display arbitration + watermarks */
PSB_WVDC32(regs->saveDSPARB, DSPARB);
@@ -223,7 +229,7 @@ static int psb_restore_display_registers(struct drm_device
*dev)
/*make sure VGA plane is off. it initializes to on after reset!*/
PSB_WVDC32(0x8000, VGACNTRL);
- drm_modeset_lock_all(dev);
+ DRM_MODESET_LOCK_ALL_BEGIN(dev, ctx, 0, ret);
list_for_each_entry(crtc, &dev->mode_config.crtc_list, head)
if (drm_helper_crtc_in_use(crtc))
dev_priv->ops->restore_crtc(crtc);
@@ -232,8 +238,8 @@ static int psb_restore_display_registers(struct drm_device
*dev)
if (connector->restore)
connector->restore(&connector->base);
- drm_modeset_unlock_all(dev);
- return 0;
+ DRM_MODESET_LOCK_ALL_END(dev, ctx, ret);
+ return ret;
}
static int psb_power_down(struct drm_device *dev)
--
2.33.0
Re: [PATCH v5 13/16] drm/mediatek: add ETHDR support for MT8195
Hi Chun-Kuang,
Thanks for the review.
On Wed, 2021-09-22 at 08:09 +0800, Chun-Kuang Hu wrote:
> Hi, Nancy:
>
> Nancy.Lin 於 2021年9月6日 週一 下午3:15寫道：
> >
> > ETHDR is a part of ovl_adaptor.
> > ETHDR is designed for HDR video and graphics conversion in the
> > external
> > display path. It handles multiple HDR input types and performs tone
> > mapping, color space/color format conversion, and then combine
> > different layers, output the required HDR or SDR signal to the
> > subsequent display path.
> >
> > Signed-off-by: Nancy.Lin
> > ---
> > drivers/gpu/drm/mediatek/Makefile| 1 +
> > drivers/gpu/drm/mediatek/mtk_ethdr.c | 424
> > +++
> > drivers/gpu/drm/mediatek/mtk_ethdr.h | 25 ++
> > 3 files changed, 450 insertions(+)
> > create mode 100644 drivers/gpu/drm/mediatek/mtk_ethdr.c
> > create mode 100644 drivers/gpu/drm/mediatek/mtk_ethdr.h
>
> [snip]
>
> > +
> > +void mtk_ethdr_disable_vblank(struct device *dev)
> > +{
> > + struct mtk_ethdr *priv = dev_get_drvdata(dev);
> > + unsigned long flags;
> > +
> > + spin_lock_irqsave(&priv->lock, flags);
> > + priv->vblank_cb = NULL;
> > + priv->vblank_cb_data = NULL;
> > + spin_unlock_irqrestore(&priv->lock, flags);
> > +
> > + writel(0x0, priv->ethdr_comp[ETHDR_MIXER].regs +
> > MIX_INTEN);
> > +}
> > +
> > +static irqreturn_t mtk_ethdr_irq_handler(int irq, void *dev_id)
> > +{
> > + struct mtk_ethdr *priv = dev_id;
> > + unsigned long flags;
> > +
> > + writel(0x0, priv->ethdr_comp[ETHDR_MIXER].regs +
> > MIX_INTSTA);
> > +
> > + spin_lock_irqsave(&priv->lock, flags);
> > + if (!priv->vblank_cb) {
> > + spin_unlock_irqrestore(&priv->lock, flags);
> > + return IRQ_NONE;
> > + }
> > +
> > + priv->vblank_cb(priv->vblank_cb_data);
> > + spin_unlock_irqrestore(&priv->lock, flags);
> > +
> > + return IRQ_HANDLED;
> > +}
> > +
> > +void mtk_ethdr_layer_config(struct device *dev, unsigned int idx,
> > + struct mtk_plane_state *state,
> > + struct cmdq_pkt *cmdq_pkt)
> > +{
> > + struct mtk_ethdr *priv = dev_get_drvdata(dev);
> > + struct mtk_ethdr_comp *mixer = &priv-
> > >ethdr_comp[ETHDR_MIXER];
> > + struct mtk_plane_pending_state *pending = &state->pending;
> > + unsigned int offset = (pending->y << 16) | pending->x;
>
> unsigned int offset = (pending->x & 1) << 31 | pending->y << 16 |
> pending->x;
>
> So you don't need x_offset_odd.
>
OK, I will modify it.
> > +
> >unsigned int mixer_pad_mode = MIXER_INx_MODE_BYPASS;
> > + unsigned int alpha_con = 0;
> > + unsigned int fmt = 0;
> > + bool x_offset_odd = false;
> > +
> > + dev_dbg(dev, "%s+ idx:%d", __func__, idx);
> > +
> > + if (idx >= 4)
> > + return;
> > +
> > + if (!pending->enable) {
> > + mtk_ddp_write(cmdq_pkt, 0, &mixer->cmdq_base,
> > mixer->regs, MIX_L_SRC_SIZE(idx));
> > + mtk_mmsys_ddp_config(priv->mmsys_dev,
> > MMSYS_CONFIG_MIXER_IN_MODE,
> > +idx + 1,
> > MIXER_INx_MODE_BYPASS, cmdq_pkt);
> > + mtk_mmsys_ddp_config(priv->mmsys_dev,
> > MMSYS_CONFIG_MIXER_IN_BIWIDTH,
> > +idx + 1, 0, cmdq_pkt);
> > + return;
> > + }
> > +
> > + if (pending->x % 2) {
> > + x_offset_odd = true;
> > + mixer_pad_mode = MIXER_INx_MODE_EVEN_EXTEND;
> > + }
> > + mtk_mmsys_ddp_config(priv->mmsys_dev,
> > MMSYS_CONFIG_MIXER_IN_MODE,
> > +idx + 1, mixer_pad_mode, cmdq_pkt);
> > + mtk_mmsys_ddp_config(priv->mmsys_dev,
> > MMSYS_CONFIG_MIXER_IN_BIWIDTH,
> > +idx + 1, pending->width / 2 - 1,
> > cmdq_pkt);
> > +
> > + if (state->base.fb && state->base.fb->format->has_alpha) {
> > + alpha_con = MIXER_ALPHA_AEN | MIXER_ALPHA;
> > + mtk_mmsys_ddp_config(priv->mmsys_dev,
> > MMSYS_CONFIG_HDR_ALPHA_SEL,
> > +idx + 1, 0, cmdq_pkt);
> > + } else {
> > + mtk_mmsys_ddp_config(priv->mmsys_dev,
> > MMSYS_CONFIG_HDR_ALPHA_SEL,
> > +idx + 1, 1, cmdq_pkt);
> > + }
> > + mtk_mmsys_ddp_config(priv->mmsys_dev,
> > MMSYS_CONFIG_MIXER_IN_ALPHA_ODD, idx + 1,
> > +DEFAULT_9BIT_ALPHA, cmdq_pkt);
> > + mtk_mmsys_ddp_config(priv->mmsys_dev,
> > MMSYS_CONFIG_MIXER_IN_ALPHA_EVEN, idx + 1,
> > +DEFAULT_9BIT_ALPHA, cmdq_pkt);
> > +
> > + mtk_ddp_write(cmdq_pkt, (pending->height << 16) | pending-
> > >width, &mixer->cmdq_base,
>
> mtk_ddp_write(cmdq_pkt, pending->height << 16 | pending->width,
> &mixer->cmdq_base,
>
OK.
> > + mixer->regs, MIX_L_SRC_SIZE(idx));
> > + mtk_ddp_write(cmdq_pkt,
[git pull] drm fixes for 5.15-rc3
Hey Linus, quiet week this week, just some i915 and amd fixes, just getting ready for my all nighter maintainer summit! Dave. drm-fixes-2021-09-24: drm fixes for 5.15-rc3 i915: - Fix ADL-P memory bandwidth parameters - Fix memory corruption due to a double free - Fix memory leak in DMC firmware handling amdgpu: - Update MAINTAINERS entry for powerplay - Fix empty macros - SI DPM fix amdkfd: - SVM fixes - DMA mapping fix The following changes since commit e4e737bb5c170df6135a127739a9e6148ee3da82: Linux 5.15-rc2 (2021-09-19 17:28:22 -0700) are available in the Git repository at: git://anongit.freedesktop.org/drm/drm tags/drm-fixes-2021-09-24 for you to fetch changes up to ef88d7a8a5c94d063311a5581d9a8f0c0e3a99cb: Merge tag 'drm-intel-fixes-2021-09-23' of git://anongit.freedesktop.org/drm/drm-intel into drm-fixes (2021-09-24 09:39:17 +1000) drm fixes for 5.15-rc3 i915: - Fix ADL-P memory bandwidth parameters - Fix memory corruption due to a double free - Fix memory leak in DMC firmware handling amdgpu: - Update MAINTAINERS entry for powerplay - Fix empty macros - SI DPM fix amdkfd: - SVM fixes - DMA mapping fix Alex Deucher (1): MAINTAINERS: fix up entry for AMD Powerplay Arnd Bergmann (1): drm/amd/display: fix empty debug macros Chris Wilson (1): drm/i915: Free all DMC payloads Dave Airlie (2): Merge tag 'amd-drm-fixes-5.15-2021-09-23' of https://gitlab.freedesktop.org/agd5f/linux into drm-fixes Merge tag 'drm-intel-fixes-2021-09-23' of git://anongit.freedesktop.org/drm/drm-intel into drm-fixes Lijo Lazar (1): drm/amd/pm: Update intermediate power state for SI Maarten Lankhorst (1): drm/i915: Move __i915_gem_free_object to ttm_bo_destroy Philip Yang (4): drm/amdkfd: SVM map to gpus check vma boundary drm/amdkfd: fix dma mapping leaking warning drm/amdkfd: handle svm migrate init error drm/amdkfd: fix svm_migrate_fini warning Radhakrishna Sripada (1): drm/i915: Update memory bandwidth parameters MAINTAINERS | 4 ++-- drivers/gpu/drm/amd/amdkfd/kfd_device.c | 1 - drivers/gpu/drm/amd/amdkfd/kfd_migrate.c | 16 +++- drivers/gpu/drm/amd/amdkfd/kfd_migrate.h | 5 - drivers/gpu/drm/amd/amdkfd/kfd_svm.c | 24 +++- drivers/gpu/drm/amd/display/dc/dce/dce_aux.c | 4 ++-- drivers/gpu/drm/amd/pm/powerplay/si_dpm.c| 2 ++ drivers/gpu/drm/i915/display/intel_bw.c | 19 --- drivers/gpu/drm/i915/display/intel_dmc.c | 5 - drivers/gpu/drm/i915/gem/i915_gem_ttm.c | 9 + 10 files changed, 57 insertions(+), 32 deletions(-)
Re: [PATCH v2 1/9] vfio/ccw: Use functions for alloc/free of the vfio_ccw_private
On Thu, 2021-09-09 at 16:38 -0300, Jason Gunthorpe wrote: > Makes the code easier to understand what is memory lifecycle and what > is > other stuff. > > Signed-off-by: Jason Gunthorpe > --- > drivers/s390/cio/vfio_ccw_drv.c | 137 ++-- > > 1 file changed, 78 insertions(+), 59 deletions(-) Reviewed-by: Eric Farman
Re: [PATCH v2 2/9] vfio/ccw: Pass vfio_ccw_private not mdev_device to various functions
On Thu, 2021-09-09 at 16:38 -0300, Jason Gunthorpe wrote: > mdev_device should only be used in functions assigned to ops > callbacks, > interior functions should use the struct vfio_ccw_private instead of > repeatedly trying to get it from the mdev. > > Signed-off-by: Jason Gunthorpe > --- > drivers/s390/cio/vfio_ccw_ops.c | 37 + > > 1 file changed, 15 insertions(+), 22 deletions(-) Reviewed-by: Eric Farman
Re: [PATCH v2 6/9] vfio/mdev: Add mdev available instance checking to the core
On Tue, 2021-09-21 at 10:19 -0300, Jason Gunthorpe wrote: > On Mon, Sep 20, 2021 at 08:02:29PM +0200, Cornelia Huck wrote: > > On Thu, Sep 09 2021, Jason Gunthorpe wrote: > > > > > Many of the mdev drivers use a simple counter for keeping track > > > of the > > > available instances. Move this code to the core code and store > > > the counter > > > in the mdev_type. Implement it using correct locking, fixing > > > mdpy. > > > > > > Drivers provide a get_available() callback to set the number of > > > available > > > instances for their mtypes which is fixed at registration time. > > > The core > > > provides a standard sysfs attribute to return the > > > available_instances. > > > > So, according to the documentation, available_instances is > > mandatory. This means that drivers either need to provide > > get_available > > or implement their own version of the attribute. I think we want to > > update vfio-mediated-device.rst as well? > > I added this, and something similar for the device_api patch too, > thanks > > diff --git a/Documentation/driver-api/vfio-mediated-device.rst > b/Documentation/driver-api/vfio-mediated-device.rst > index 9f26079cacae35..0a130d76b33a48 100644 > --- a/Documentation/driver-api/vfio-mediated-device.rst > +++ b/Documentation/driver-api/vfio-mediated-device.rst > @@ -106,6 +106,7 @@ structure to represent a mediated device's > driver:: >int (*probe) (struct mdev_device *dev); >void (*remove) (struct mdev_device *dev); >struct device_driverdriver; > + unsigned int (*get_available)(struct mdev_type *mtype); > }; > > A mediated bus driver for mdev should use this structure in the > function calls > @@ -230,7 +231,8 @@ Directories and files under the sysfs for Each > Physical Device > * available_instances > >This attribute should show the number of devices of type > that can be > - created. > + created. Drivers can supply a get_availble() function pointer to s/availble/available/ > have the core > + code create and maintain this sysfs automatically. > > * [device] >
Re: [PATCH v2 3/3] drm/bridge: ti-sn65dsi86: Add NO_CONNECTOR support
Hi Rob,
On Thu, Sep 23, 2021 at 10:31:52AM -0700, Rob Clark wrote:
> On Wed, Sep 22, 2021 at 5:44 PM Laurent Pinchart wrote:
> > On Mon, Sep 20, 2021 at 03:58:00PM -0700, Rob Clark wrote:
> > > From: Rob Clark
> > >
> > > Slightly awkward to fish out the display_info when we aren't creating
> > > own connector. But I don't see an obvious better way.
> > >
> > > v2: Remove error return with NO_CONNECTOR flag
> > >
> > > Signed-off-by: Rob Clark
> > > ---
> > > drivers/gpu/drm/bridge/ti-sn65dsi86.c | 39 ---
> > > 1 file changed, 29 insertions(+), 10 deletions(-)
> > >
> > > diff --git a/drivers/gpu/drm/bridge/ti-sn65dsi86.c
> > > b/drivers/gpu/drm/bridge/ti-sn65dsi86.c
> > > index 6154bed0af5b..94c94cc8a4d8 100644
> > > --- a/drivers/gpu/drm/bridge/ti-sn65dsi86.c
> > > +++ b/drivers/gpu/drm/bridge/ti-sn65dsi86.c
> > > @@ -667,11 +667,6 @@ static int ti_sn_bridge_attach(struct drm_bridge
> > > *bridge,
> > > .node = NULL,
> > >};
> > >
> > > - if (flags & DRM_BRIDGE_ATTACH_NO_CONNECTOR) {
> > > - DRM_ERROR("Fix bridge driver to make connector optional!");
> > > - return -EINVAL;
> > > - }
> > > -
> > > pdata->aux.drm_dev = bridge->dev;
> > > ret = drm_dp_aux_register(&pdata->aux);
> > > if (ret < 0) {
> > > @@ -679,9 +674,11 @@ static int ti_sn_bridge_attach(struct drm_bridge
> > > *bridge,
> > > return ret;
> > > }
> > >
> > > - ret = ti_sn_bridge_connector_init(pdata);
> > > - if (ret < 0)
> > > - goto err_conn_init;
> > > + if (!(flags & DRM_BRIDGE_ATTACH_NO_CONNECTOR)) {
> > > + ret = ti_sn_bridge_connector_init(pdata);
> > > + if (ret < 0)
> > > + goto err_conn_init;
> > > + }
> > >
> > > /*
> > >* TODO: ideally finding host resource and dsi dev registration
> > > needs
> > > @@ -743,7 +740,8 @@ static int ti_sn_bridge_attach(struct drm_bridge
> > > *bridge,
> > > err_dsi_attach:
> > > mipi_dsi_device_unregister(dsi);
> > > err_dsi_host:
> > > - drm_connector_cleanup(&pdata->connector);
> > > + if (!(flags & DRM_BRIDGE_ATTACH_NO_CONNECTOR))
> > > + drm_connector_cleanup(&pdata->connector);
> >
> > I wonder if we actually need this. The connector gets attached to the
> > encoder, won't it be destroyed by the DRM core in the error path ?
>
> This does not appear to be the case, we leak the connector if I remove
> this (and add a hack to trigger the error path)
OK.
> > > err_conn_init:
> > > drm_dp_aux_unregister(&pdata->aux);
> > > return ret;
> > > @@ -792,9 +790,30 @@ static void ti_sn_bridge_set_dsi_rate(struct
> > > ti_sn65dsi86 *pdata)
> > > regmap_write(pdata->regmap, SN_DSIA_CLK_FREQ_REG, val);
> > > }
> > >
> > > +/*
> > > + * Find the connector and fish out the bpc from display_info. It would
> > > + * be nice if we could get this instead from drm_bridge_state, but that
> > > + * doesn't yet appear to be the case.
> >
> > You already have a bus format in the bridge state, from which you can
> > derive the bpp. Could you give it a try ?
>
> Possibly the bridge should be converted to ->atomic_enable(), etc..
> I'll leave that for another time
It should be fairly straightforward, and would avoid the hack below.
> > > + */
> > > static unsigned int ti_sn_bridge_get_bpp(struct ti_sn65dsi86 *pdata)
> > > {
> > > - if (pdata->connector.display_info.bpc <= 6)
> > > + struct drm_bridge *bridge = &pdata->bridge;
> > > + struct drm_connector_list_iter conn_iter;
> > > + struct drm_connector *connector;
> > > + unsigned bpc = 0;
> > > +
> > > + drm_connector_list_iter_begin(bridge->dev, &conn_iter);
> > > + drm_for_each_connector_iter(connector, &conn_iter) {
> > > + if (drm_connector_has_possible_encoder(connector,
> > > bridge->encoder)) {
> > > + bpc = connector->display_info.bpc;
> > > + break;
> > > + }
> > > + }
> > > + drm_connector_list_iter_end(&conn_iter);
> > > +
> > > + WARN_ON(bpc == 0);
> > > +
> > > + if (bpc <= 6)
> > > return 18;
> > > else
> > > return 24;
--
Regards,
Laurent Pinchart
[PATCH v5 2/2] drm/bridge: ti-sn65dsi86: Implement the pwm_chip
The SN65DSI86 provides the ability to supply a PWM signal on GPIO 4,
with the primary purpose of controlling the backlight of the attached
panel. Add an implementation that exposes this using the standard PWM
framework, to allow e.g. pwm-backlight to expose this to the user.
Signed-off-by: Bjorn Andersson
---
Changes since v4:
- Rebased the patch
- Turned ti_sn65dsi86_write_u16 into using regmap bulk write
- Moved pwm_refclk_freq out of the #if CONFIG_PWM, to allow removing the guard
from ti_sn_bridge_set_refclk_freq()
- Updates "Limitations" text
- pm_runtime_put_sync() on pm_runtime_get_sync() failure
- Added parenthesis around (scale + 1) in the PWM_FREQ formula and thereby
redid all the math
- Rewrote the comments related to the math
- Rewrote the math for calculating the backlight (duty cycle) register value
- Dropped some !! on already boolean state->enabled
- Dropped a spurious newline
- Rewrote comment in ti_sn65dsi86_probe() talking about future PWM work
drivers/gpu/drm/bridge/ti-sn65dsi86.c | 369 +-
1 file changed, 361 insertions(+), 8 deletions(-)
diff --git a/drivers/gpu/drm/bridge/ti-sn65dsi86.c
b/drivers/gpu/drm/bridge/ti-sn65dsi86.c
index 41d48a393e7f..857a53dc6c75 100644
--- a/drivers/gpu/drm/bridge/ti-sn65dsi86.c
+++ b/drivers/gpu/drm/bridge/ti-sn65dsi86.c
@@ -4,7 +4,9 @@
* datasheet: https://www.ti.com/lit/ds/symlink/sn65dsi86.pdf
*/
+#include
#include
+#include
#include
#include
#include
@@ -15,6 +17,7 @@
#include
#include
#include
+#include
#include
#include
@@ -91,6 +94,13 @@
#define SN_ML_TX_MODE_REG 0x96
#define ML_TX_MAIN_LINK_OFF 0
#define ML_TX_NORMAL_MODE BIT(0)
+#define SN_PWM_PRE_DIV_REG 0xA0
+#define SN_BACKLIGHT_SCALE_REG 0xA1
+#define BACKLIGHT_SCALE_MAX 0x
+#define SN_BACKLIGHT_REG 0xA3
+#define SN_PWM_EN_INV_REG 0xA5
+#define SN_PWM_INV_MASK BIT(0)
+#define SN_PWM_EN_MASKBIT(1)
#define SN_AUX_CMD_STATUS_REG 0xF4
#define AUX_IRQ_STATUS_AUX_RPLY_TOUT BIT(3)
#define AUX_IRQ_STATUS_AUX_SHORT BIT(5)
@@ -113,11 +123,14 @@
#define SN_LINK_TRAINING_TRIES 10
+#define SN_PWM_GPIO_IDX3 /* 4th GPIO */
+
/**
* struct ti_sn65dsi86 - Platform data for ti-sn65dsi86 driver.
* @bridge_aux: AUX-bus sub device for MIPI-to-eDP bridge functionality.
* @gpio_aux: AUX-bus sub device for GPIO controller functionality.
* @aux_aux: AUX-bus sub device for eDP AUX channel functionality.
+ * @pwm_aux: AUX-bus sub device for PWM controller functionality.
*
* @dev: Pointer to the top level (i2c) device.
* @regmap: Regmap for accessing i2c.
@@ -145,11 +158,17 @@
*bitmap so we can do atomic ops on it without an extra
*lock so concurrent users of our 4 GPIOs don't stomp on
*each other's read-modify-write.
+ *
+ * @pchip:pwm_chip if the PWM is exposed.
+ * @pwm_enabled: Used to track if the PWM signal is currently enabled.
+ * @pwm_pin_busy: Track if GPIO4 is currently requested for GPIO or PWM.
+ * @pwm_refclk_freq: Cache for the reference clock input to the PWM.
*/
struct ti_sn65dsi86 {
struct auxiliary_device bridge_aux;
struct auxiliary_device gpio_aux;
struct auxiliary_device aux_aux;
+ struct auxiliary_device pwm_aux;
struct device *dev;
struct regmap *regmap;
@@ -172,6 +191,12 @@ struct ti_sn65dsi86 {
struct gpio_chipgchip;
DECLARE_BITMAP(gchip_output, SN_NUM_GPIOS);
#endif
+#if defined(CONFIG_PWM)
+ struct pwm_chip pchip;
+ boolpwm_enabled;
+ atomic_tpwm_pin_busy;
+#endif
+ unsigned intpwm_refclk_freq;
};
static const struct regmap_range ti_sn65dsi86_volatile_ranges[] = {
@@ -190,11 +215,31 @@ static const struct regmap_config
ti_sn65dsi86_regmap_config = {
.cache_type = REGCACHE_NONE,
};
+static int ti_sn65dsi86_read_u16(struct ti_sn65dsi86 *pdata,
+unsigned int reg, u16 *val)
+{
+ unsigned int tmp;
+ int ret;
+
+ ret = regmap_read(pdata->regmap, reg, &tmp);
+ if (ret)
+ return ret;
+ *val = tmp;
+
+ ret = regmap_read(pdata->regmap, reg + 1, &tmp);
+ if (ret)
+ return ret;
+ *val |= tmp << 8;
+
+ return 0;
+}
+
static void ti_sn65dsi86_write_u16(struct ti_sn65dsi86 *pdata,
unsigned int reg, u16 val)
{
- regmap_write(pdata->regmap, reg, val & 0xFF);
- regmap_write(pdata->regmap, reg + 1, val >> 8);
[PATCH v5 1/2] pwm: Introduce single-PWM of_xlate function
The existing pxa driver and the upcoming addition of PWM support in the
TI sn565dsi86 DSI/eDP bridge driver both has a single PWM channel and
thereby a need for a of_xlate function with the period as its single
argument.
Introduce a common helper function in the core that can be used as
of_xlate by such drivers and migrate the pxa driver to use this.
Signed-off-by: Bjorn Andersson
---
Changes since v4:
- None
drivers/pwm/core.c| 26 ++
drivers/pwm/pwm-pxa.c | 16 +---
include/linux/pwm.h | 2 ++
3 files changed, 29 insertions(+), 15 deletions(-)
diff --git a/drivers/pwm/core.c b/drivers/pwm/core.c
index 4527f09a5c50..2c6b155002a2 100644
--- a/drivers/pwm/core.c
+++ b/drivers/pwm/core.c
@@ -152,6 +152,32 @@ of_pwm_xlate_with_flags(struct pwm_chip *pc, const struct
of_phandle_args *args)
}
EXPORT_SYMBOL_GPL(of_pwm_xlate_with_flags);
+struct pwm_device *
+of_pwm_single_xlate(struct pwm_chip *pc, const struct of_phandle_args *args)
+{
+ struct pwm_device *pwm;
+
+ if (pc->of_pwm_n_cells < 1)
+ return ERR_PTR(-EINVAL);
+
+ /* validate that one cell is specified, optionally with flags */
+ if (args->args_count != 1 && args->args_count != 2)
+ return ERR_PTR(-EINVAL);
+
+ pwm = pwm_request_from_chip(pc, 0, NULL);
+ if (IS_ERR(pwm))
+ return pwm;
+
+ pwm->args.period = args->args[0];
+ pwm->args.polarity = PWM_POLARITY_NORMAL;
+
+ if (args->args_count == 2 && args->args[2] & PWM_POLARITY_INVERTED)
+ pwm->args.polarity = PWM_POLARITY_INVERSED;
+
+ return pwm;
+}
+EXPORT_SYMBOL_GPL(of_pwm_single_xlate);
+
static void of_pwmchip_add(struct pwm_chip *chip)
{
if (!chip->dev || !chip->dev->of_node)
diff --git a/drivers/pwm/pwm-pxa.c b/drivers/pwm/pwm-pxa.c
index a9efdcf839ae..238ec88c130b 100644
--- a/drivers/pwm/pwm-pxa.c
+++ b/drivers/pwm/pwm-pxa.c
@@ -148,20 +148,6 @@ static const struct platform_device_id
*pxa_pwm_get_id_dt(struct device *dev)
return id ? id->data : NULL;
}
-static struct pwm_device *
-pxa_pwm_of_xlate(struct pwm_chip *pc, const struct of_phandle_args *args)
-{
- struct pwm_device *pwm;
-
- pwm = pwm_request_from_chip(pc, 0, NULL);
- if (IS_ERR(pwm))
- return pwm;
-
- pwm->args.period = args->args[0];
-
- return pwm;
-}
-
static int pwm_probe(struct platform_device *pdev)
{
const struct platform_device_id *id = platform_get_device_id(pdev);
@@ -187,7 +173,7 @@ static int pwm_probe(struct platform_device *pdev)
pc->chip.npwm = (id->driver_data & HAS_SECONDARY_PWM) ? 2 : 1;
if (IS_ENABLED(CONFIG_OF)) {
- pc->chip.of_xlate = pxa_pwm_of_xlate;
+ pc->chip.of_xlate = of_pwm_single_xlate;
pc->chip.of_pwm_n_cells = 1;
}
diff --git a/include/linux/pwm.h b/include/linux/pwm.h
index 725c9b784e60..dd51d4931fdc 100644
--- a/include/linux/pwm.h
+++ b/include/linux/pwm.h
@@ -414,6 +414,8 @@ struct pwm_device *pwm_request_from_chip(struct pwm_chip
*chip,
struct pwm_device *of_pwm_xlate_with_flags(struct pwm_chip *pc,
const struct of_phandle_args *args);
+struct pwm_device *of_pwm_single_xlate(struct pwm_chip *pc,
+ const struct of_phandle_args *args);
struct pwm_device *pwm_get(struct device *dev, const char *con_id);
struct pwm_device *of_pwm_get(struct device *dev, struct device_node *np,
--
2.32.0
[PATCH v2] drm/amd/display: Fix randomly flicking on overlay with enabled ABM
From: "Yipeng Chen (Jasber)" [Why] Enabled ABM (level != 0) would raise short pulse irq DC_IRQ_SOURCE_HPD1RX randomly with PSR error LINK_CRC_ERROR. Actually there is no hot plugging on EDP panel. After correcting CRC error, there is no need to send drm hotplug event. [How] Returning false would skip doing hot-plug when handle_hpd_irq_psr_sink() handled irq. Hot-plug process causes visible flicking on overlay. Signed-off-by: Yipeng Chen (Jasber) Reviewed-by: Roman Li Reviewed-by: Anthony Koo --- drivers/gpu/drm/amd/display/dc/core/dc_link_dp.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/amd/display/dc/core/dc_link_dp.c b/drivers/gpu/drm/amd/display/dc/core/dc_link_dp.c index 1e4794e2825c..9b9fbe5e9bd4 100644 --- a/drivers/gpu/drm/amd/display/dc/core/dc_link_dp.c +++ b/drivers/gpu/drm/amd/display/dc/core/dc_link_dp.c @@ -3007,7 +3007,7 @@ bool dc_link_handle_hpd_rx_irq(struct dc_link *link, union hpd_irq_data *out_hpd if (handle_hpd_irq_psr_sink(link)) /* PSR-related error was detected and handled */ - return true; + return false; /* If PSR-related error handled, Main link may be off, * so do not handle as a normal sink status change interrupt. -- 2.25.1
[PATCH 3/3] drm/panel: Delete panel on mipi_dsi_attach() failure
Many DSI panel drivers fail to clean up their panel references on
mipi_dsi_attach() failure, so we're leaving a dangling drm_panel
reference to freed memory. Clean that up on failure.
Noticed by inspection, after seeing similar problems on other drivers.
Therefore, I'm not marking Fixes/stable.
Signed-off-by: Brian Norris
---
drivers/gpu/drm/panel/panel-feiyang-fy07024di26a30d.c| 8 +++-
drivers/gpu/drm/panel/panel-jdi-lt070me05000.c | 8 +++-
drivers/gpu/drm/panel/panel-novatek-nt36672a.c | 8 +++-
drivers/gpu/drm/panel/panel-panasonic-vvx10f034n00.c | 8 +++-
drivers/gpu/drm/panel/panel-ronbo-rb070d30.c | 8 +++-
drivers/gpu/drm/panel/panel-samsung-s6e88a0-ams452ef01.c | 1 +
drivers/gpu/drm/panel/panel-samsung-sofef00.c| 1 +
drivers/gpu/drm/panel/panel-sharp-ls043t1le01.c | 8 +++-
8 files changed, 44 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/panel/panel-feiyang-fy07024di26a30d.c
b/drivers/gpu/drm/panel/panel-feiyang-fy07024di26a30d.c
index 581661b506f8..f9c1f7bc8218 100644
--- a/drivers/gpu/drm/panel/panel-feiyang-fy07024di26a30d.c
+++ b/drivers/gpu/drm/panel/panel-feiyang-fy07024di26a30d.c
@@ -227,7 +227,13 @@ static int feiyang_dsi_probe(struct mipi_dsi_device *dsi)
dsi->format = MIPI_DSI_FMT_RGB888;
dsi->lanes = 4;
- return mipi_dsi_attach(dsi);
+ ret = mipi_dsi_attach(dsi);
+ if (ret < 0) {
+ drm_panel_remove(&ctx->panel);
+ return ret;
+ }
+
+ return 0;
}
static int feiyang_dsi_remove(struct mipi_dsi_device *dsi)
diff --git a/drivers/gpu/drm/panel/panel-jdi-lt070me05000.c
b/drivers/gpu/drm/panel/panel-jdi-lt070me05000.c
index 733010b5e4f5..3c86ad262d5e 100644
--- a/drivers/gpu/drm/panel/panel-jdi-lt070me05000.c
+++ b/drivers/gpu/drm/panel/panel-jdi-lt070me05000.c
@@ -473,7 +473,13 @@ static int jdi_panel_probe(struct mipi_dsi_device *dsi)
if (ret < 0)
return ret;
- return mipi_dsi_attach(dsi);
+ ret = mipi_dsi_attach(dsi);
+ if (ret < 0) {
+ jdi_panel_del(jdi);
+ return ret;
+ }
+
+ return 0;
}
static int jdi_panel_remove(struct mipi_dsi_device *dsi)
diff --git a/drivers/gpu/drm/panel/panel-novatek-nt36672a.c
b/drivers/gpu/drm/panel/panel-novatek-nt36672a.c
index 533cd3934b8b..839b263fb3c0 100644
--- a/drivers/gpu/drm/panel/panel-novatek-nt36672a.c
+++ b/drivers/gpu/drm/panel/panel-novatek-nt36672a.c
@@ -656,7 +656,13 @@ static int nt36672a_panel_probe(struct mipi_dsi_device
*dsi)
if (err < 0)
return err;
- return mipi_dsi_attach(dsi);
+ err = mipi_dsi_attach(dsi);
+ if (err < 0) {
+ drm_panel_remove(&pinfo->base);
+ return err;
+ }
+
+ return 0;
}
static int nt36672a_panel_remove(struct mipi_dsi_device *dsi)
diff --git a/drivers/gpu/drm/panel/panel-panasonic-vvx10f034n00.c
b/drivers/gpu/drm/panel/panel-panasonic-vvx10f034n00.c
index 3c20beeb1781..3991f5d950af 100644
--- a/drivers/gpu/drm/panel/panel-panasonic-vvx10f034n00.c
+++ b/drivers/gpu/drm/panel/panel-panasonic-vvx10f034n00.c
@@ -241,7 +241,13 @@ static int wuxga_nt_panel_probe(struct mipi_dsi_device
*dsi)
if (ret < 0)
return ret;
- return mipi_dsi_attach(dsi);
+ ret = mipi_dsi_attach(dsi);
+ if (ret < 0) {
+ wuxga_nt_panel_del(wuxga_nt);
+ return ret;
+ }
+
+ return 0;
}
static int wuxga_nt_panel_remove(struct mipi_dsi_device *dsi)
diff --git a/drivers/gpu/drm/panel/panel-ronbo-rb070d30.c
b/drivers/gpu/drm/panel/panel-ronbo-rb070d30.c
index a3782830ae3c..1fb579a574d9 100644
--- a/drivers/gpu/drm/panel/panel-ronbo-rb070d30.c
+++ b/drivers/gpu/drm/panel/panel-ronbo-rb070d30.c
@@ -199,7 +199,13 @@ static int rb070d30_panel_dsi_probe(struct mipi_dsi_device
*dsi)
dsi->format = MIPI_DSI_FMT_RGB888;
dsi->lanes = 4;
- return mipi_dsi_attach(dsi);
+ ret = mipi_dsi_attach(dsi);
+ if (ret < 0) {
+ drm_panel_remove(&ctx->panel);
+ return ret;
+ }
+
+ return 0;
}
static int rb070d30_panel_dsi_remove(struct mipi_dsi_device *dsi)
diff --git a/drivers/gpu/drm/panel/panel-samsung-s6e88a0-ams452ef01.c
b/drivers/gpu/drm/panel/panel-samsung-s6e88a0-ams452ef01.c
index ea63799ff2a1..29fde3823212 100644
--- a/drivers/gpu/drm/panel/panel-samsung-s6e88a0-ams452ef01.c
+++ b/drivers/gpu/drm/panel/panel-samsung-s6e88a0-ams452ef01.c
@@ -247,6 +247,7 @@ static int s6e88a0_ams452ef01_probe(struct mipi_dsi_device
*dsi)
ret = mipi_dsi_attach(dsi);
if (ret < 0) {
dev_err(dev, "Failed to attach to DSI host: %d\n", ret);
+ drm_panel_remove(&ctx->panel);
return ret;
}
diff --git a/drivers/gpu/drm/panel/panel-samsung-sofef00.c
b/drivers/gpu/drm/panel/panel-samsung-sofef00.
[PATCH 1/3] drm/panel: kingdisplay-kd097d04: Delete panel on attach() failure
If we fail to attach (e.g., because 1 of 2 dual-DSI controllers aren't
ready), we leave a dangling drm_panel reference to freed memory. Clean
that up on failure.
Fixes: 2a994cbed6b2 ("drm/panel: Add Kingdisplay KD097D04 panel driver")
Signed-off-by: Brian Norris
---
drivers/gpu/drm/panel/panel-kingdisplay-kd097d04.c | 8 +++-
1 file changed, 7 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/panel/panel-kingdisplay-kd097d04.c
b/drivers/gpu/drm/panel/panel-kingdisplay-kd097d04.c
index 86e4213e8bb1..daccb1fd5fda 100644
--- a/drivers/gpu/drm/panel/panel-kingdisplay-kd097d04.c
+++ b/drivers/gpu/drm/panel/panel-kingdisplay-kd097d04.c
@@ -406,7 +406,13 @@ static int kingdisplay_panel_probe(struct mipi_dsi_device
*dsi)
if (err < 0)
return err;
- return mipi_dsi_attach(dsi);
+ err = mipi_dsi_attach(dsi);
+ if (err < 0) {
+ kingdisplay_panel_del(kingdisplay);
+ return err;
+ }
+
+ return 0;
}
static int kingdisplay_panel_remove(struct mipi_dsi_device *dsi)
--
2.33.0.685.g46640cef36-goog
[PATCH 2/3] drm/panel: innolux-p079zca: Delete panel on attach() failure
If we fail to attach (e.g., because 1 of 2 dual-DSI controllers aren't
ready), we leave a dangling drm_panel reference to freed memory. Clean
that up on failure.
This problem exists since the driver's introduction, but is especially
relevant after refactored for dual-DSI variants.
Fixes: 14c8f2e9f8ea ("drm/panel: add Innolux P079ZCA panel driver")
Fixes: 7ad4e4636c54 ("drm/panel: p079zca: Refactor panel driver to support
multiple panels")
Signed-off-by: Brian Norris
---
drivers/gpu/drm/panel/panel-innolux-p079zca.c | 10 +-
1 file changed, 9 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/panel/panel-innolux-p079zca.c
b/drivers/gpu/drm/panel/panel-innolux-p079zca.c
index aea316225391..f194b62e290c 100644
--- a/drivers/gpu/drm/panel/panel-innolux-p079zca.c
+++ b/drivers/gpu/drm/panel/panel-innolux-p079zca.c
@@ -484,6 +484,7 @@ static void innolux_panel_del(struct innolux_panel *innolux)
static int innolux_panel_probe(struct mipi_dsi_device *dsi)
{
const struct panel_desc *desc;
+ struct innolux_panel *innolux;
int err;
desc = of_device_get_match_data(&dsi->dev);
@@ -495,7 +496,14 @@ static int innolux_panel_probe(struct mipi_dsi_device *dsi)
if (err < 0)
return err;
- return mipi_dsi_attach(dsi);
+ err = mipi_dsi_attach(dsi);
+ if (err < 0) {
+ innolux = mipi_dsi_get_drvdata(dsi);
+ innolux_panel_del(innolux);
+ return err;
+ }
+
+ return 0;
}
static int innolux_panel_remove(struct mipi_dsi_device *dsi)
--
2.33.0.685.g46640cef36-goog
[PATCH 0/3] drm/panel: Proper cleanup after mipi_dsi_attach()
I've tested a few dual-DSI panel drivers which choke if they PROBE_DEFER at the wrong time, so I patched those up in patch 1 and 2. Patch 3 fixes the other drivers that I couldn't test, but seem to have all the same problem. Brian Norris (3): drm/panel: kingdisplay-kd097d04: Delete panel on attach() failure drm/panel: innolux-p079zca: Delete panel on attach() failure drm/panel: Delete panel on mipi_dsi_attach() failure drivers/gpu/drm/panel/panel-feiyang-fy07024di26a30d.c | 8 +++- drivers/gpu/drm/panel/panel-innolux-p079zca.c | 10 +- drivers/gpu/drm/panel/panel-jdi-lt070me05000.c | 8 +++- drivers/gpu/drm/panel/panel-kingdisplay-kd097d04.c | 8 +++- drivers/gpu/drm/panel/panel-novatek-nt36672a.c | 8 +++- drivers/gpu/drm/panel/panel-panasonic-vvx10f034n00.c | 8 +++- drivers/gpu/drm/panel/panel-ronbo-rb070d30.c | 8 +++- .../gpu/drm/panel/panel-samsung-s6e88a0-ams452ef01.c | 1 + drivers/gpu/drm/panel/panel-samsung-sofef00.c | 1 + drivers/gpu/drm/panel/panel-sharp-ls043t1le01.c| 8 +++- 10 files changed, 60 insertions(+), 8 deletions(-) -- 2.33.0.685.g46640cef36-goog
Re: [PATCH v2 0/4] CMDQ refinement of Mediatek DRM driver
Hi, Enric: Enric Balletbo Serra 於 2021年9月24日 週五 上午12:36寫道： > > Hi Chun-Kuang, > > Missatge de Chun-Kuang Hu del dia dt., 21 de > set. 2021 a les 15:15: > > > > Hi, Enric: > > > > Enric Balletbo Serra 於 2021年9月21日 週二 下午4:36寫道： > > > > > > Hi Chun-Kuang, > > > > > > (again without html format, sorry for the noise) > > > > > > Missatge de Chun-Kuang Hu del dia dj., 12 > > > d’ag. 2021 a les 2:13: > > > > > > > > Chun-Kuang Hu 於 2021年8月9日 週一 上午7:47寫道： > > > > > > > > > > These refinements include using standard mailbox callback interface, > > > > > timeout detection, and a fixed cmdq_handle. > > > > > > > > For this series, applied to mediatek-drm-next [1]. > > > > > > > > [1] > > > > https://git.kernel.org/pub/scm/linux/kernel/git/chunkuang.hu/linux.git/log/?h=mediatek-drm-next > > > > > > > > > > These patches seem to break the display on the Acer Chromebook R 13 > > > (MT8173) in the current mainline. After running a bisection it pointed > > > me to the following commit > > > > > > commit f4be17cd5b14dd73545b0e014a63ebe9ab5ef837 > > > Author: Chun-Kuang Hu > > > Date: Sun Jul 4 15:36:48 2021 +0800 > > > > > > drm/mediatek: Remove struct cmdq_client > > > > > > Reverting this patch alone is not trivial, so I ended up reverting the > > > full series, and I can confirm that reverting the full series makes > > > the display work again. > > > > I think you could not just revert "drm/mediatek: Remove struct > > cmdq_client", you should also revert the patches after it, such as > > > > "drm/mediatek: Clear pending flag when cmdq packet is done" > > "drm/mediatek: Add cmdq_handle in mtk_crtc" > > "drm/mediatek: Detect CMDQ execution timeout" > > > > Yes, in fact I reverted: > > 9efb16c2fdd6 drm/mediatek: Clear pending flag when cmdq packet is done > bc9241be73d9 drm/mediatek: Add cmdq_handle in mtk_crtc > 8cdcb3653424 drm/mediatek: Detect CMDQ execution timeout > f4be17cd5b14 drm/mediatek: Remove struct cmdq_client > c1ec54b7b5af drm/mediatek: Use mailbox rx_callback instead of cmdq_task_cb > > Without these patches 5.15-rc2 works again on my platform. > > The commit 'c1ec54b7b5af drm/mediatek: Use mailbox rx_callback instead > of cmdq_task_cb' alone introduces lots of warnings in the kernel > > WARNING: CPU: 0 PID: 0 at drivers/mailbox/mtk-cmdq-mailbox.c:198 > cmdq_task_exec_done+0xb8/0xe0 I think the WARN_ON in cmdq driver should be remove because that warning show that cmdq_task_cb is not used but I that is what I want. > > I think is just a leftover or the mentioned warning, but that confused > me a bit doing the bisection. Then, after commit 'f4be17cd5b14 > drm/mediatek: Remove struct cmdq_client' my system simply gets stuck. > For now I don't see any obvious mistake but will dig further. > > Can I ask you in which platform did you test? And if you can double > check if your platform is broken too in current mainline? I've no environment to test code now. I apply this series because I assume Yongqiang has test his patch "Clear pending flag when cmdq packet is done". Before I setup the environment (this may take a long time), I would find others to fix this problem. According to your information, "c1ec54b7b5af drm/mediatek: Use mailbox rx_callback instead of cmdq_task_cb" would cause many warning but display still work, right? If so, I think we should focus on "f4be17cd5b14 drm/mediatek: Remove struct cmdq_client". Regards, Chun-Kuang. > > Thanks, > Enric > > > If "drm/mediatek: Remove struct cmdq_client" is the patch cause > > display abnormal, I think you could compare code w/ and w/o this > > patch. Focus on the value accuracy, such as cmdq_cl and cmdq_chan. And > > focus on the flow accuracy, such as mtk_drm_crtc_update_config() and > > ddp_cmdq_cb(). If this could not find the problem, I think the latest > > way is to break this patch into small patches, changes little in each > > small patches and we could finally find out the problem. > > > > Regards, > > Chun-Kuang. > > > > > > > > Unfortunately, after the merge window, different things broke for this > > > device, and I didn't finish isolating them, and it is not clear to me > > > yet whether the logs I'm getting are useful for this specific issue or > > > not. Basically with this series merged the kernel seems to be stuck, > > > and the display is not working. Latest message is > > > > > > [ 12.329173] mtk-iommu 10205000.iommu: Partial TLB flush timed out, > > > falling back to full flush > > > > > > Without the series, the kernel goes far and display works, however > > > there are other issues affecting the cros-ec, but I think that's > > > another issue. > > > > > > I'll try to dig a bit more, but, meanwhile, if you have any idea > > > please let me know. > > > > > > Thanks, > > > Enric > > > > > > > > > > Regards, > > > > Chun-Kuang. > > > > > > > > > > > > > > Changes in v2: > > > > > 1. Define mtk_drm_cmdq_pkt_create() and mtk_drm_cmdq_pkt_destroy() > > > > >when CONFIG_MTK_CMDQ is reachable. > > > > > > > > > > Chun-
Re: BoF at LPC: Documenting the Heterogeneous Memory Model Architecture
Hi, On Thu, 23 Sept 2021 at 21:40, Matthew Wilcox wrote: > On Thu, Sep 23, 2021 at 04:25:08PM -0400, Felix Kuehling wrote: > > Change of plan: Instead of a BoF, this is now a session in the "GPU/media/AI > > buffer management and interop MC" micro conference. Thank you Daniel Stone > > for making that happen. > > https://linuxplumbersconf.org/event/11/contributions/1112/ > > > > It is scheduled for tomorrow (Friday) 08:40-10:00 Pacific, 11:40-13:00 > > Eastern, 15:40-17:00 UTC. > > That's up against: > > Direct map management > Vlastimil Babka, Mike Rapoport, Rick Edgecombe 11:30-12:15. > > Seems like a lot of the same people would want to be in both sessions. > Maybe one could be moved? Good point, and thanks, but it's hard to keep the longer slot whilst moving it later; I wonder if we could move direct map management to the final slot? Cheers, Daniel
Re: [PATCH v3 6/6] drm/ingenic: Attach bridge chain to encoders
On Thursday, 23 September 2021 22:23:28 CEST H. Nikolaus Schaller wrote:
>
> > Am 23.09.2021 um 21:39 schrieb Paul Cercueil :
> >
> > Start by wiring things properly, like in my previously linked DTS, and
> > *test*. If it fails, tell us where it fails.
>
> Well, I tell where drm_bridge_attach fails with
> DRM_BRIDGE_ATTACH_NO_CONNECTOR...
I tried to piece together this entire discussion from the mailing list
archives, but there appear to be two approaches that "work", in that they
activate the LCD controller with the HDMI peripheral:
1. Nikolaus's approach, which involves getting the Synopsys driver to create a
connector and then avoiding the call to drm_bridge_connector_init in the
Ingenic DRM driver.
2. My approach, which just involves changing the Synopsys driver to set the
bridge type in dw_hdmi_probe like this:
hdmi->bridge.type = DRM_MODE_CONNECTOR_HDMIA;
Otherwise, I don't see how the bridge's (struct drm_bridge) type will be set.
And this causes drm_bridge_connector_init to fail because it tests the bridge
type.
Now, I just reintroduced the HDMI connector to the device tree as follows:
hdmi_connector {
compatible = "hdmi-connector";
label = "hdmi";
type = "a";
port {
hdmi_connector_in: endpoint {
remote-endpoint = <&dw_hdmi_out>;
};
};
};
And then I added a second port to the HDMI peripheral node as follows:
port@1 {
reg = <1>;
dw_hdmi_out: endpoint {
remote-endpoint = <&hdmi_connector_in>;
};
};
And I removed any of the above hacks. What I observe, apart from an inactive
LCD controller (and ingenic-drm driver), is the following in /sys/devices/
platform/1018.hdmi/:
consumer:platform:1305.lcdc0
consumer:platform:hdmi_connector
Maybe I don't understand the significance of "consumer" here, but the LCD
controller and the HDMI connector obviously have rather different roles. Then
again, the device tree is defining bidirectional relationships, so maybe this
is how they manifest themselves.
> > Because your "it doesn't work" arguments have zero weight otherwise.
>
> I hope I still can find it. So I can't promise anything.
> We have had it complete in DTS and added code to parse it.
> It may have been wiped out by cleaning up patch series during rebase.
I suppose the question is whether this is actually handled already. I would
have thought that either the DRM framework would be able to identify such
relationships in a generic way or that the Synopsys driver would need to do
so. This might actually be happening, given that the sysfs entries are there,
but I might also imagine that something extra would be required to set the
bridge type.
I did start writing some code to look up a remote endpoint for the second
port, find the connector type, and then set it, but it was probably after
midnight on that occasion as well. Short-circuiting this little dance and
setting the bridge type indicated that this might ultimately be the right
approach, but it would probably also mean introducing a point of
specialisation to the Synopsys driver so that device-specific drivers can
define a function to set the connector type.
Otherwise, I can't see the Synopsys driver working for devices like the
JZ4780, but then again, it seems that all the other devices seem to
incorporate the Synopsys functionality in a different way and do not need to
deal with connectors at all.
> > If I can find some time this weekend I will test it myself.
>
> You may be faster than me.
So, when I wrote about approaches that "work", I can seemingly get the LCD
controller and HDMI peripheral registers set up to match a non-Linux
environment where I can demonstrate a functioning display, and yet I don't get
a valid signal in the Linux environment.
Nikolaus can actually get HDMI output, but there may be other factors
introduced by the Linux environment that frustrate success for me, whereas my
non-Linux environment is much simpler and can reliably reproduce a successful
result.
For me, running modetest yields plenty of information about encoders,
connectors (and the supported modes via the EDID, thanks to my HDMI-A hack),
CRTCs, and planes. But no framebuffers are reported.
Paul
Re: [PATCH] DRM/Panel : abt-y030xx067a yellow tint fix
Hi,
Le jeu., sept. 23 2021 at 22:17:51 +0200, Sam Ravnborg
a écrit :
Hi Christophe, Paul,
On Tue, Sep 14, 2021 at 11:27:16AM +0200, Christophe Branchereau
wrote:
The previous parameters caused an unbalanced yellow tint.
Signed-off-by: Christophe Branchereau
with the subject fixed the patch is:
Acked-by: Sam Ravnborg
Paul - I assume you will apply this as you wrote on irc.
I added:
Fixes: 7467389bdafb ("drm/panel: Add ABT Y030XX067A 3.0" 320x480 panel")
I also fixed the subject (case and punctuation), and pushed to
drm-misc-fixes.
Thanks!
Cheers,
-Paul
Sam
---
drivers/gpu/drm/panel/panel-abt-y030xx067a.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/panel/panel-abt-y030xx067a.c
b/drivers/gpu/drm/panel/panel-abt-y030xx067a.c
index 2d8794d495d0..3d8a9ab47cae 100644
--- a/drivers/gpu/drm/panel/panel-abt-y030xx067a.c
+++ b/drivers/gpu/drm/panel/panel-abt-y030xx067a.c
@@ -146,8 +146,8 @@ static const struct reg_sequence
y030xx067a_init_sequence[] = {
{ 0x09, REG09_SUB_BRIGHT_R(0x20) },
{ 0x0a, REG0A_SUB_BRIGHT_B(0x20) },
{ 0x0b, REG0B_HD_FREERUN | REG0B_VD_FREERUN },
- { 0x0c, REG0C_CONTRAST_R(0x10) },
- { 0x0d, REG0D_CONTRAST_G(0x10) },
+ { 0x0c, REG0C_CONTRAST_R(0x00) },
+ { 0x0d, REG0D_CONTRAST_G(0x00) },
{ 0x0e, REG0E_CONTRAST_B(0x10) },
{ 0x0f, 0 },
{ 0x10, REG10_BRIGHT(0x7f) },
--
2.33.0
RE: BoF at LPC: Documenting the Heterogeneous Memory Model Architecture
[AMD Official Use Only] Hi Matt, I originally picked the 10 am pdt time slot to avoid those conflicts. But I see the overlap is only partial. I also see Peterz is giving a talk that also overlaps partially. But I think this is survivable. I suggest we just try to make this work as best we can. It's not a presentation, it's primarily intended as a meet and greet and discussion. Whatever starts there will continue on lkml and etc. Regards, Daniel -Original Message- From: Matthew Wilcox Sent: Thursday, September 23, 2021 1:39 PM To: Kuehling, Felix Cc: Linux MM ; linux-e...@vger.kernel.org; linux-...@vger.kernel.org; Maling list - DRI developers ; linux-ker...@vger.kernel.org; Christoph Hellwig ; Jason Gunthorpe ; Jerome Glisse ; Ralph Campbell ; Theodore Ts'o ; Andrew Morton ; Mel Gorman ; Peter Zijlstra ; Phillips, Daniel ; Sierra Guiza, Alejandro (Alex) ; Daniel Stone Subject: Re: BoF at LPC: Documenting the Heterogeneous Memory Model Architecture [CAUTION: External Email] On Thu, Sep 23, 2021 at 04:25:08PM -0400, Felix Kuehling wrote: > Change of plan: Instead of a BoF, this is now a session in the > "GPU/media/AI buffer management and interop MC" micro conference. > Thank you Daniel Stone for making that happen. > https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Flinu > xplumbersconf.org%2Fevent%2F11%2Fcontributions%2F1112%2F&data=04%7 > C01%7CDaniel.Phillips%40amd.com%7Cb5064a1c5649431a90be08d97ed2517b%7C3 > dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637680264672385094%7CUnknown > %7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJ > XVCI6Mn0%3D%7C2000&sdata=e%2Bpn4vXZI9yhLAbB8rtqik6OiZsEwOCBMdqk4JZ > n%2FC8%3D&reserved=0 > > It is scheduled for tomorrow (Friday) 08:40-10:00 Pacific, 11:40-13:00 > Eastern, 15:40-17:00 UTC. That's up against: Direct map management Vlastimil Babka, Mike Rapoport, Rick Edgecombe 11:30-12:15. Seems like a lot of the same people would want to be in both sessions. Maybe one could be moved?
[pull] amdgpu, amdkfd drm-fixes-5.15
Hi Dave, Daniel, Fixes for 5.15. The following changes since commit e4e737bb5c170df6135a127739a9e6148ee3da82: Linux 5.15-rc2 (2021-09-19 17:28:22 -0700) are available in the Git repository at: https://gitlab.freedesktop.org/agd5f/linux.git tags/amd-drm-fixes-5.15-2021-09-23 for you to fetch changes up to 197ae17722e989942b36e33e044787877f158574: drm/amdkfd: fix svm_migrate_fini warning (2021-09-23 17:06:11 -0400) amd-drm-fixes-5.15-2021-09-23: amdgpu: - Update MAINTAINERS entry for powerplay - Fix empty macros - SI DPM fix amdkfd: - SVM fixes - DMA mapping fix Alex Deucher (1): MAINTAINERS: fix up entry for AMD Powerplay Arnd Bergmann (1): drm/amd/display: fix empty debug macros Lijo Lazar (1): drm/amd/pm: Update intermediate power state for SI Philip Yang (4): drm/amdkfd: SVM map to gpus check vma boundary drm/amdkfd: fix dma mapping leaking warning drm/amdkfd: handle svm migrate init error drm/amdkfd: fix svm_migrate_fini warning MAINTAINERS | 4 ++-- drivers/gpu/drm/amd/amdkfd/kfd_device.c | 1 - drivers/gpu/drm/amd/amdkfd/kfd_migrate.c | 16 +++- drivers/gpu/drm/amd/amdkfd/kfd_migrate.h | 5 - drivers/gpu/drm/amd/amdkfd/kfd_svm.c | 24 +++- drivers/gpu/drm/amd/display/dc/dce/dce_aux.c | 4 ++-- drivers/gpu/drm/amd/pm/powerplay/si_dpm.c| 2 ++ 7 files changed, 32 insertions(+), 24 deletions(-)
Re: [PATCH v12 05/35] dt-bindings: clock: tegra-car: Document new clock sub-nodes
On Mon, 20 Sep 2021 21:11:15 +0300, Dmitry Osipenko wrote: > Document sub-nodes which describe Tegra SoC clocks that require a higher > voltage of the core power domain in order to operate properly on a higher > clock rates. Each node contains a phandle to OPP table and power domain. > > The root PLLs and system clocks don't have any specific device dedicated > to them, clock controller is in charge of managing power for them. > > Signed-off-by: Dmitry Osipenko > --- > .../bindings/clock/nvidia,tegra20-car.yaml| 37 +++ > 1 file changed, 37 insertions(+) > Reviewed-by: Rob Herring
Re: [PATCH v6 1/2] drm/bridge: parade-ps8640: Use regmap APIs
Hi, On Tue, Sep 21, 2021 at 11:06 AM Philip Chen wrote: > > Replace the direct i2c access (i2c_smbus_* functions) with regmap APIs, > which will simplify the future update on ps8640 driver. > > Reviewed-by: Douglas Anderson > Acked-by: Sam Ravnborg > Signed-off-by: Philip Chen > --- > > (no changes since v4) > > Changes in v4: > - Remove excessive error logging from the probe function > > Changes in v3: > - Fix the nits from v2 review > > Changes in v2: > - Add separate reg map config per page > > drivers/gpu/drm/bridge/parade-ps8640.c | 94 ++ > 1 file changed, 64 insertions(+), 30 deletions(-) Pushed both patches to drm-misc-next: 13afcdd7277e drm/bridge: parade-ps8640: Add support for AUX channel 692d8db0a5ca drm/bridge: parade-ps8640: Use regmap APIs I made a few whitespace fixes reported by `dim apply-branch` (DRM committer tool) and also re-arranged your Signed-off-by to be above the Reviews/Acks. -Doug
Re: BoF at LPC: Documenting the Heterogeneous Memory Model Architecture
On Thu, Sep 23, 2021 at 04:25:08PM -0400, Felix Kuehling wrote: > Change of plan: Instead of a BoF, this is now a session in the "GPU/media/AI > buffer management and interop MC" micro conference. Thank you Daniel Stone > for making that happen. > https://linuxplumbersconf.org/event/11/contributions/1112/ > > It is scheduled for tomorrow (Friday) 08:40-10:00 Pacific, 11:40-13:00 > Eastern, 15:40-17:00 UTC. That's up against: Direct map management Vlastimil Babka, Mike Rapoport, Rick Edgecombe 11:30-12:15. Seems like a lot of the same people would want to be in both sessions. Maybe one could be moved?
Re: BoF at LPC: Documenting the Heterogeneous Memory Model Architecture
Change of plan: Instead of a BoF, this is now a session in the "GPU/media/AI buffer management and interop MC" micro conference. Thank you Daniel Stone for making that happen. https://linuxplumbersconf.org/event/11/contributions/1112/ It is scheduled for tomorrow (Friday) 08:40-10:00 Pacific, 11:40-13:00 Eastern, 15:40-17:00 UTC. I hope to see you all tomorrow, Felix On 2021-09-21 3:19 p.m., Felix Kuehling wrote: As the programming models for GPU-based high-performance computing applications are evolving, HMM is helping us integrate the GPU memory management more closely with the kernel's virtual memory management. As a result we can provide a shared virtual address space with demand-paging and page-based migrations of anonymous pages to/from device memory. A patch series by AMD [1, 2] to add support for cache-coherent, CPU-accessible device memory has brought up some fairly fundamental questions about HMM and its interaction with virtual memory management, page cache and file systems. We'd like to use the chance of getting together for a BoF [3] at LPC to raise awareness for HMM outside the GPU driver code, identify gaps in the architectural documentation and clarify our priorities for future development. Thank you, Daniel, for suggesting the BoF and getting it scheduled. It's set for Friday, 10am Pacific, 1pm Eastern, 5pm UTC. I am registered at LPC. Daniel got a speaker's pass. We're still trying to work something out for Alex. I hope to see many of you on Friday. Best regards, Felix [1] https://patchwork.freedesktop.org/series/94611/ [2] https://patchwork.freedesktop.org/series/90706/ [3] https://linuxplumbersconf.org/event/11/contributions/1123/
Re: [PATCH v3 6/6] drm/ingenic: Attach bridge chain to encoders
Hi Paul, > Am 23.09.2021 um 21:39 schrieb Paul Cercueil : > > > > Le jeu., sept. 23 2021 at 20:52:23 +0200, H. Nikolaus Schaller > a écrit : >> Hi Paul, >>> Am 23.09.2021 um 15:30 schrieb Paul Cercueil : >>> Hi Nikolaus, >>> Le jeu., sept. 23 2021 at 13:41:28 +0200, H. Nikolaus Schaller >>> a écrit : Hi Laurent, Ah, ok. But then we still have issues. Firstly I would assume that get_edid only works properly if it is initialized through dw_hdmi_connector_create(). Next, in the current code, passing DRM_BRIDGE_ATTACH_NO_CONNECTOR to dw_hdmi_bridge_attach() indeed does not call dw_hdmi_connector_create() but returns 0. This patch 6/6 makes drm/ingenic unconditionally require a connector to be attached which is defined somewhere else (device tree e.g. "connector-hdmi") unrelated to dw-hdmi. Current upstream code for drm/ingenic does not init/attach such a connector on its own so it did work before. I.e. I think we can't just use parts of dw-hdmi. >>> The fact that Laurent is using dw-hdmi with DRM_BRIDGE_ATTACH_NO_CONNECTOR >>> on Renesas makes me think that it's possible here as well. There's no >>> reason why it shouldn't work with ingenic-drm. >> That is interesting and Laurent can probably comment on differences between >> his setup (I wasn't able to deduce what device you are referring to) and >> dw-hdmi. >> For jz4780 we tried that first. I do not remember the exact reasons but we >> wasted >> weeks trying to but failed to get it working. While the dw-hdmi connector >> simply works >> on top of upstream and fails only if we apply your patch. >> Another issue is how you want to tell connector-hdmi to use the extra i2c >> bus driver >> for ddc which is not available directly as a standard i2c controller of the >> jz4780. >> hdmi-connector.yaml defines: >> ddc-i2c-bus: >> description: phandle link to the I2C controller used for DDC EDID >> probing >> $ref: /schemas/types.yaml#/definitions/phandle >> So we would need some ddc-i2c-bus = <&i2c-controller-inside-the dw-hdmi>. >> But that i2c-controller-inside-the dw-hdmi does not exist in device tree >> and can not be added unless someone significantly rewrites dw-hdmi to >> register and expose it as i2c controller. > > No, you don't need to do that at all. Just don't set the "ddc-i2c-bus" > property. And then ddc from dw-hdmi works? > >>> The ingenic-drm driver does not need to create any connector. The >>> "connector-hdmi" is connected to dw-hdmi as the "next bridge" in the list. >> Sure. It does not *create* a connector. It expects that it can safely call >> drm_bridge_connector_init() to get a pointer to a newly created connector. >> But if we use the dw-hdmi connector, there is no such connector and "next >> bridge". > > We don't want to use the dw-hdmi connector. Your "next bridge" is the > "hdmi-connector" that should be wired in DTS. > >> Or can you tell me how to make the dw-hdmi connector created by >> dw_hdmi_connector_create() become the "next bridge" in the list for your >> driver? >> But without significantly rewriting dw-hdmi.c (and testing). > > Wire it to the LCD node in DTS... > > See how we do it for the IT66121 driver: > https://github.com/OpenDingux/linux/blob/jz-5.15/arch/mips/boot/dts/ingenic/rg350m.dts#L114-L134 That is how we already tried. > If drm_bridge_attach() would return some errno if DRM_BRIDGE_ATTACH_NO_CONNECTOR is set, initialization in ingenic_drm_bind() would fail likewise with "Unable to attach bridge". So in any case dw-hdmi is broken by this drm/ingenic patch unless someone reworks it to make it compatible. >>> Where would the errno be returned? Why would drm_bridge_attach() return an >>> error code? >> Currently dw_hdmi_bridge_attach() returns 0 if it is asked to support >> DRM_BRIDGE_ATTACH_NO_CONNECTOR. >> This is not treated as an error by drm_bridge_attach(). >> Here it could return an error (-ENOTSUPP?) instead, to allow for error >> handling >> by its caller. > > And why would you do that? If you don't want to attach a connector, then > drm_bridge_attach() doesn't need to do much. So it's normal that it returns > zero. > >> But that raises an error message like "failed to attach bridge to encoder" >> and >> the bridge is reset and detached. Another issue is that dw_hdmi_connector_create() does not only do dcd/edid but appears to detects hot plug and does some special initialization. So we probably loose hotplug detect if we just use drm_bridge_funcs.get_edid(). >>> There's drm_bridge_funcs.detect(). >> You mean in dw-hdmi? Yes, it calls dw_hdmi_bridge_detect() which calls >> dw_hdmi_detect(). >> This does some read_hpd. >> Anyways, this does not solve the problem that with your drm/ingenic proposal >> the >> dw-hdmi subsystem (hdmi + ddc) can no longer be initialized properly unless >> someone >> fixes either. >> So IMHO this sh
Re: [PATCH] DRM/Panel : abt-y030xx067a yellow tint fix
Hi Christophe, Paul,
On Tue, Sep 14, 2021 at 11:27:16AM +0200, Christophe Branchereau wrote:
> The previous parameters caused an unbalanced yellow tint.
>
> Signed-off-by: Christophe Branchereau
with the subject fixed the patch is:
Acked-by: Sam Ravnborg
Paul - I assume you will apply this as you wrote on irc.
Sam
> ---
> drivers/gpu/drm/panel/panel-abt-y030xx067a.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/panel/panel-abt-y030xx067a.c
> b/drivers/gpu/drm/panel/panel-abt-y030xx067a.c
> index 2d8794d495d0..3d8a9ab47cae 100644
> --- a/drivers/gpu/drm/panel/panel-abt-y030xx067a.c
> +++ b/drivers/gpu/drm/panel/panel-abt-y030xx067a.c
> @@ -146,8 +146,8 @@ static const struct reg_sequence
> y030xx067a_init_sequence[] = {
> { 0x09, REG09_SUB_BRIGHT_R(0x20) },
> { 0x0a, REG0A_SUB_BRIGHT_B(0x20) },
> { 0x0b, REG0B_HD_FREERUN | REG0B_VD_FREERUN },
> - { 0x0c, REG0C_CONTRAST_R(0x10) },
> - { 0x0d, REG0D_CONTRAST_G(0x10) },
> + { 0x0c, REG0C_CONTRAST_R(0x00) },
> + { 0x0d, REG0D_CONTRAST_G(0x00) },
> { 0x0e, REG0E_CONTRAST_B(0x10) },
> { 0x0f, 0 },
> { 0x10, REG10_BRIGHT(0x7f) },
> --
> 2.33.0
Re: [PATCH v3 6/6] drm/ingenic: Attach bridge chain to encoders
Le jeu., sept. 23 2021 at 20:52:23 +0200, H. Nikolaus Schaller a écrit : Hi Paul, Am 23.09.2021 um 15:30 schrieb Paul Cercueil : Hi Nikolaus, Le jeu., sept. 23 2021 at 13:41:28 +0200, H. Nikolaus Schaller a écrit : Hi Laurent, Ah, ok. But then we still have issues. Firstly I would assume that get_edid only works properly if it is initialized through dw_hdmi_connector_create(). Next, in the current code, passing DRM_BRIDGE_ATTACH_NO_CONNECTOR to dw_hdmi_bridge_attach() indeed does not call dw_hdmi_connector_create() but returns 0. This patch 6/6 makes drm/ingenic unconditionally require a connector to be attached which is defined somewhere else (device tree e.g. "connector-hdmi") unrelated to dw-hdmi. Current upstream code for drm/ingenic does not init/attach such a connector on its own so it did work before. I.e. I think we can't just use parts of dw-hdmi. The fact that Laurent is using dw-hdmi with DRM_BRIDGE_ATTACH_NO_CONNECTOR on Renesas makes me think that it's possible here as well. There's no reason why it shouldn't work with ingenic-drm. That is interesting and Laurent can probably comment on differences between his setup (I wasn't able to deduce what device you are referring to) and dw-hdmi. For jz4780 we tried that first. I do not remember the exact reasons but we wasted weeks trying to but failed to get it working. While the dw-hdmi connector simply works on top of upstream and fails only if we apply your patch. Another issue is how you want to tell connector-hdmi to use the extra i2c bus driver for ddc which is not available directly as a standard i2c controller of the jz4780. hdmi-connector.yaml defines: ddc-i2c-bus: description: phandle link to the I2C controller used for DDC EDID probing $ref: /schemas/types.yaml#/definitions/phandle So we would need some ddc-i2c-bus = <&i2c-controller-inside-the dw-hdmi>. But that i2c-controller-inside-the dw-hdmi does not exist in device tree and can not be added unless someone significantly rewrites dw-hdmi to register and expose it as i2c controller. No, you don't need to do that at all. Just don't set the "ddc-i2c-bus" property. The ingenic-drm driver does not need to create any connector. The "connector-hdmi" is connected to dw-hdmi as the "next bridge" in the list. Sure. It does not *create* a connector. It expects that it can safely call drm_bridge_connector_init() to get a pointer to a newly created connector. But if we use the dw-hdmi connector, there is no such connector and "next bridge". We don't want to use the dw-hdmi connector. Your "next bridge" is the "hdmi-connector" that should be wired in DTS. Or can you tell me how to make the dw-hdmi connector created by dw_hdmi_connector_create() become the "next bridge" in the list for your driver? But without significantly rewriting dw-hdmi.c (and testing). Wire it to the LCD node in DTS... See how we do it for the IT66121 driver: https://github.com/OpenDingux/linux/blob/jz-5.15/arch/mips/boot/dts/ingenic/rg350m.dts#L114-L134 If drm_bridge_attach() would return some errno if DRM_BRIDGE_ATTACH_NO_CONNECTOR is set, initialization in ingenic_drm_bind() would fail likewise with "Unable to attach bridge". So in any case dw-hdmi is broken by this drm/ingenic patch unless someone reworks it to make it compatible. Where would the errno be returned? Why would drm_bridge_attach() return an error code? Currently dw_hdmi_bridge_attach() returns 0 if it is asked to support DRM_BRIDGE_ATTACH_NO_CONNECTOR. This is not treated as an error by drm_bridge_attach(). Here it could return an error (-ENOTSUPP?) instead, to allow for error handling by its caller. And why would you do that? If you don't want to attach a connector, then drm_bridge_attach() doesn't need to do much. So it's normal that it returns zero. But that raises an error message like "failed to attach bridge to encoder" and the bridge is reset and detached. Another issue is that dw_hdmi_connector_create() does not only do dcd/edid but appears to detects hot plug and does some special initialization. So we probably loose hotplug detect if we just use drm_bridge_funcs.get_edid(). There's drm_bridge_funcs.detect(). You mean in dw-hdmi? Yes, it calls dw_hdmi_bridge_detect() which calls dw_hdmi_detect(). This does some read_hpd. Anyways, this does not solve the problem that with your drm/ingenic proposal the dw-hdmi subsystem (hdmi + ddc) can no longer be initialized properly unless someone fixes either. So IMHO this should be treated as a significant blocking point for your patch because it breaks something that is working upstream and there seems to be no rationale to change it. Your commit message just says: "All the bridges are now attached with DRM_BRIDGE_ATTACH_NO_CONNECTOR." but gives no reason why. I fully understand that you want to change it and Laurent said that it will become standard i
Re: [PATCH v3 6/6] drm/ingenic: Attach bridge chain to encoders
Hi Paul, > Am 23.09.2021 um 15:30 schrieb Paul Cercueil : > > Hi Nikolaus, > > Le jeu., sept. 23 2021 at 13:41:28 +0200, H. Nikolaus Schaller > a écrit : >> Hi Laurent, >> Ah, ok. >> But then we still have issues. >> Firstly I would assume that get_edid only works properly if it is initialized >> through dw_hdmi_connector_create(). >> Next, in the current code, passing DRM_BRIDGE_ATTACH_NO_CONNECTOR to >> dw_hdmi_bridge_attach() indeed does not call dw_hdmi_connector_create() >> but returns 0. >> This patch 6/6 makes drm/ingenic unconditionally require a connector >> to be attached which is defined somewhere else (device tree e.g. >> "connector-hdmi") >> unrelated to dw-hdmi. Current upstream code for drm/ingenic does not >> init/attach >> such a connector on its own so it did work before. >> I.e. I think we can't just use parts of dw-hdmi. > > The fact that Laurent is using dw-hdmi with DRM_BRIDGE_ATTACH_NO_CONNECTOR on > Renesas makes me think that it's possible here as well. There's no reason why > it shouldn't work with ingenic-drm. That is interesting and Laurent can probably comment on differences between his setup (I wasn't able to deduce what device you are referring to) and dw-hdmi. For jz4780 we tried that first. I do not remember the exact reasons but we wasted weeks trying to but failed to get it working. While the dw-hdmi connector simply works on top of upstream and fails only if we apply your patch. Another issue is how you want to tell connector-hdmi to use the extra i2c bus driver for ddc which is not available directly as a standard i2c controller of the jz4780. hdmi-connector.yaml defines: ddc-i2c-bus: description: phandle link to the I2C controller used for DDC EDID probing $ref: /schemas/types.yaml#/definitions/phandle So we would need some ddc-i2c-bus = <&i2c-controller-inside-the dw-hdmi>. But that i2c-controller-inside-the dw-hdmi does not exist in device tree and can not be added unless someone significantly rewrites dw-hdmi to register and expose it as i2c controller. > > The ingenic-drm driver does not need to create any connector. The > "connector-hdmi" is connected to dw-hdmi as the "next bridge" in the list. Sure. It does not *create* a connector. It expects that it can safely call drm_bridge_connector_init() to get a pointer to a newly created connector. But if we use the dw-hdmi connector, there is no such connector and "next bridge". Or can you tell me how to make the dw-hdmi connector created by dw_hdmi_connector_create() become the "next bridge" in the list for your driver? But without significantly rewriting dw-hdmi.c (and testing). > >> If drm_bridge_attach() would return some errno if >> DRM_BRIDGE_ATTACH_NO_CONNECTOR >> is set, initialization in ingenic_drm_bind() would fail likewise with >> "Unable to attach bridge". >> So in any case dw-hdmi is broken by this drm/ingenic patch unless someone >> reworks it to make it compatible. > > Where would the errno be returned? Why would drm_bridge_attach() return an > error code? Currently dw_hdmi_bridge_attach() returns 0 if it is asked to support DRM_BRIDGE_ATTACH_NO_CONNECTOR. This is not treated as an error by drm_bridge_attach(). Here it could return an error (-ENOTSUPP?) instead, to allow for error handling by its caller. But that raises an error message like "failed to attach bridge to encoder" and the bridge is reset and detached. > >> Another issue is that dw_hdmi_connector_create() does not only do dcd/edid >> but appears to detects hot plug and does some special initialization. >> So we probably loose hotplug detect if we just use >> drm_bridge_funcs.get_edid(). > > There's drm_bridge_funcs.detect(). You mean in dw-hdmi? Yes, it calls dw_hdmi_bridge_detect() which calls dw_hdmi_detect(). This does some read_hpd. Anyways, this does not solve the problem that with your drm/ingenic proposal the dw-hdmi subsystem (hdmi + ddc) can no longer be initialized properly unless someone fixes either. So IMHO this should be treated as a significant blocking point for your patch because it breaks something that is working upstream and there seems to be no rationale to change it. Your commit message just says: "All the bridges are now attached with DRM_BRIDGE_ATTACH_NO_CONNECTOR." but gives no reason why. I fully understand that you want to change it and Laurent said that it will become standard in the far future. Therefore I suggest to find a way that you can find out if a connector has already been created by drm_bridge_attach() to stay compatible with current upstream code. I even want to help here but I don't know how to detect the inverse of drm_connector_attach_encoder(), i.e. is_drm_encoder_attached_to_any_connector(). BR and thanks, Nikolaus
[PATCH] drm/vc4: crtc: Make sure the HDMI controller is powered when disabling
Since commit 875a4d536842 ("drm/vc4: drv: Disable the CRTC at boot
time"), during the initial setup of the driver we call into the VC4 HDMI
controller hooks to make sure the controller is properly disabled.
However, we were never making sure that the device was properly powered
while doing so. This never resulted in any (reported) issue in practice,
but since the introduction of commit 4209f03fcb8e ("drm/vc4: hdmi: Warn
if we access the controller while disabled") we get a loud complaint
when we do that kind of access.
Let's make sure we have the HDMI controller properly powered while
disabling it.
Fixes: 875a4d536842 ("drm/vc4: drv: Disable the CRTC at boot time")
Signed-off-by: Maxime Ripard
---
drivers/gpu/drm/vc4/vc4_crtc.c | 19 ++-
1 file changed, 18 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/vc4/vc4_crtc.c b/drivers/gpu/drm/vc4/vc4_crtc.c
index 18f5009ce90e..c0df11e5fcf2 100644
--- a/drivers/gpu/drm/vc4/vc4_crtc.c
+++ b/drivers/gpu/drm/vc4/vc4_crtc.c
@@ -32,6 +32,7 @@
#include
#include
#include
+#include
#include
#include
@@ -42,6 +43,7 @@
#include
#include "vc4_drv.h"
+#include "vc4_hdmi.h"
#include "vc4_regs.h"
#define HVS_FIFO_LATENCY_PIX 6
@@ -496,8 +498,10 @@ int vc4_crtc_disable_at_boot(struct drm_crtc *crtc)
enum vc4_encoder_type encoder_type;
const struct vc4_pv_data *pv_data;
struct drm_encoder *encoder;
+ struct vc4_hdmi *vc4_hdmi;
unsigned encoder_sel;
int channel;
+ int ret;
if (!(of_device_is_compatible(vc4_crtc->pdev->dev.of_node,
"brcm,bcm2711-pixelvalve2") ||
@@ -525,7 +529,20 @@ int vc4_crtc_disable_at_boot(struct drm_crtc *crtc)
if (WARN_ON(!encoder))
return 0;
- return vc4_crtc_disable(crtc, encoder, NULL, channel);
+ vc4_hdmi = encoder_to_vc4_hdmi(encoder);
+ ret = pm_runtime_resume_and_get(&vc4_hdmi->pdev->dev);
+ if (ret)
+ return ret;
+
+ ret = vc4_crtc_disable(crtc, encoder, NULL, channel);
+ if (ret)
+ return ret;
+
+ ret = pm_runtime_put(&vc4_hdmi->pdev->dev);
+ if (ret)
+ return ret;
+
+ return 0;
}
static void vc4_crtc_atomic_disable(struct drm_crtc *crtc,
--
2.31.1
Re: [PATCH 1/1] drm: This patch fixes colour banding caused by wrong information passed by the Lenovo Thinkpad L540 panel.
On Thu, Sep 23, 2021 at 2:15 PM Francesco Paolo Lovergine
wrote:
>
> Hi,
The patch title is a little long. How about something like:
drm: fix colour banding on Lenovo Thinkpad L540 panel
>
> there is an issue with Lenovo Thinkpad L540 very similar to those described
> here:
> https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1749420 or here:
> https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1788308
> that is a bad looking color banding with dark colors mainly.
> It happens with any kernel starting from 4.8 up to the current.
Bugs should be referenced like:
Bug: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1749420
Bug: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1788308
Otherwise looks good to me.
Alex
>
> Signed-off-by: Francesco Paolo Lovergine
> ---
> drivers/gpu/drm/drm_edid.c | 3 +++
> 1 file changed, 3 insertions(+)
>
> diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
> index 6325877c5fd6..48e06cc33e4d 100644
> --- a/drivers/gpu/drm/drm_edid.c
> +++ b/drivers/gpu/drm/drm_edid.c
> @@ -141,6 +141,9 @@ static const struct edid_quirk {
> /* LGD panel of HP zBook 17 G2, eDP 10 bpc, but reports unknown bpc */
> { "LGD", 764, EDID_QUIRK_FORCE_10BPC },
>
> + /* LGD panel of Lenovo L540 reports 8 bpc, but is a 6 bpc panel */
> + { "LGD", 0x038e, EDID_QUIRK_FORCE_6BPC },
> +
> /* LG Philips LCD LP154W01-A5 */
> { "LPL", 0, EDID_QUIRK_DETAILED_USE_MAXIMUM_SIZE },
> { "LPL", 0x2a00, EDID_QUIRK_DETAILED_USE_MAXIMUM_SIZE },
> --
> 2.30.2
>
>
> --
> Francesco P. Lovergine
Re: [PATCH v3 5/8] x86/sme: Replace occurrences of sme_active() with cc_platform_has()
On Thu, Sep 23, 2021 at 12:05:58AM +0300, Kirill A. Shutemov wrote:
> Unless we find other way to guarantee RIP-relative access, we must use
> fixup_pointer() to access any global variables.
Yah, I've asked compiler folks about any guarantees we have wrt
rip-relative addresses but it doesn't look good. Worst case, we'd have
to do the fixup_pointer() thing.
In the meantime, Tom and I did some more poking at this and here's a
diff ontop.
The direction being that we'll stick both the AMD and Intel
*cc_platform_has() call into cc_platform.c for which instrumentation
will be disabled so no issues with that.
And that will keep all that querying all together in a single file.
---
diff --git a/arch/x86/include/asm/mem_encrypt.h
b/arch/x86/include/asm/mem_encrypt.h
index a73712b6ee0e..2d4f5c17d79c 100644
--- a/arch/x86/include/asm/mem_encrypt.h
+++ b/arch/x86/include/asm/mem_encrypt.h
@@ -51,7 +51,6 @@ void __init mem_encrypt_free_decrypted_mem(void);
void __init mem_encrypt_init(void);
void __init sev_es_init_vc_handling(void);
-bool amd_cc_platform_has(enum cc_attr attr);
#define __bss_decrypted __section(".bss..decrypted")
@@ -74,7 +73,6 @@ static inline void __init sme_encrypt_kernel(struct
boot_params *bp) { }
static inline void __init sme_enable(struct boot_params *bp) { }
static inline void sev_es_init_vc_handling(void) { }
-static inline bool amd_cc_platform_has(enum cc_attr attr) { return false; }
static inline int __init
early_set_memory_decrypted(unsigned long vaddr, unsigned long size) { return
0; }
@@ -103,12 +101,6 @@ static inline u64 sme_get_me_mask(void)
return sme_me_mask;
}
-#if defined(CONFIG_CPU_SUP_INTEL) && defined(CONFIG_ARCH_HAS_CC_PLATFORM)
-bool intel_cc_platform_has(enum cc_attr attr);
-#else
-static inline bool intel_cc_platform_has(enum cc_attr attr) { return false; }
-#endif
-
#endif /* __ASSEMBLY__ */
#endif /* __X86_MEM_ENCRYPT_H__ */
diff --git a/arch/x86/kernel/cc_platform.c b/arch/x86/kernel/cc_platform.c
index da54a1805211..97ede7052f77 100644
--- a/arch/x86/kernel/cc_platform.c
+++ b/arch/x86/kernel/cc_platform.c
@@ -13,6 +13,52 @@
#include
+static bool intel_cc_platform_has(enum cc_attr attr)
+{
+#ifdef CONFIG_INTEL_TDX_GUEST
+ return false;
+#else
+ return false;
+#endif
+}
+
+/*
+ * SME and SEV are very similar but they are not the same, so there are
+ * times that the kernel will need to distinguish between SME and SEV. The
+ * cc_platform_has() function is used for this. When a distinction isn't
+ * needed, the CC_ATTR_MEM_ENCRYPT attribute can be used.
+ *
+ * The trampoline code is a good example for this requirement. Before
+ * paging is activated, SME will access all memory as decrypted, but SEV
+ * will access all memory as encrypted. So, when APs are being brought
+ * up under SME the trampoline area cannot be encrypted, whereas under SEV
+ * the trampoline area must be encrypted.
+ */
+static bool amd_cc_platform_has(enum cc_attr attr)
+{
+#ifdef CONFIG_AMD_MEM_ENCRYPT
+ switch (attr) {
+ case CC_ATTR_MEM_ENCRYPT:
+ return sme_me_mask;
+
+ case CC_ATTR_HOST_MEM_ENCRYPT:
+ return sme_me_mask && !(sev_status & MSR_AMD64_SEV_ENABLED);
+
+ case CC_ATTR_GUEST_MEM_ENCRYPT:
+ return sev_status & MSR_AMD64_SEV_ENABLED;
+
+ case CC_ATTR_GUEST_STATE_ENCRYPT:
+ return sev_status & MSR_AMD64_SEV_ES_ENABLED;
+
+ default:
+ return false;
+ }
+#else
+ return false;
+#endif
+}
+
+
bool cc_platform_has(enum cc_attr attr)
{
if (sme_me_mask)
diff --git a/arch/x86/kernel/cpu/intel.c b/arch/x86/kernel/cpu/intel.c
index 53756ff12295..8321c43554a1 100644
--- a/arch/x86/kernel/cpu/intel.c
+++ b/arch/x86/kernel/cpu/intel.c
@@ -60,13 +60,6 @@ static u64 msr_test_ctrl_cache __ro_after_init;
*/
static bool cpu_model_supports_sld __ro_after_init;
-#ifdef CONFIG_ARCH_HAS_CC_PLATFORM
-bool intel_cc_platform_has(enum cc_attr attr)
-{
- return false;
-}
-#endif
-
/*
* Processors which have self-snooping capability can handle conflicting
* memory type across CPUs by snooping its own cache. However, there exists
diff --git a/arch/x86/mm/mem_encrypt.c b/arch/x86/mm/mem_encrypt.c
index 9417d404ea92..23d54b810f08 100644
--- a/arch/x86/mm/mem_encrypt.c
+++ b/arch/x86/mm/mem_encrypt.c
@@ -361,38 +361,6 @@ int __init early_set_memory_encrypted(unsigned long vaddr,
unsigned long size)
return early_set_memory_enc_dec(vaddr, size, true);
}
-/*
- * SME and SEV are very similar but they are not the same, so there are
- * times that the kernel will need to distinguish between SME and SEV. The
- * cc_platform_has() function is used for this. When a distinction isn't
- * needed, the CC_ATTR_MEM_ENCRYPT attribute can be used.
- *
- * The trampoline code is a good example for this requirement. Before
- * paging is activated, SME will access all memory as decrypted, but SEV
- * will access all memory a
[PATCH 1/1] drm: This patch fixes colour banding caused by wrong information passed by the Lenovo Thinkpad L540 panel.
Hi,
there is an issue with Lenovo Thinkpad L540 very similar to those described
here:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1749420 or here:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1788308
that is a bad looking color banding with dark colors mainly.
It happens with any kernel starting from 4.8 up to the current.
Signed-off-by: Francesco Paolo Lovergine
---
drivers/gpu/drm/drm_edid.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
index 6325877c5fd6..48e06cc33e4d 100644
--- a/drivers/gpu/drm/drm_edid.c
+++ b/drivers/gpu/drm/drm_edid.c
@@ -141,6 +141,9 @@ static const struct edid_quirk {
/* LGD panel of HP zBook 17 G2, eDP 10 bpc, but reports unknown bpc */
{ "LGD", 764, EDID_QUIRK_FORCE_10BPC },
+ /* LGD panel of Lenovo L540 reports 8 bpc, but is a 6 bpc panel */
+ { "LGD", 0x038e, EDID_QUIRK_FORCE_6BPC },
+
/* LG Philips LCD LP154W01-A5 */
{ "LPL", 0, EDID_QUIRK_DETAILED_USE_MAXIMUM_SIZE },
{ "LPL", 0x2a00, EDID_QUIRK_DETAILED_USE_MAXIMUM_SIZE },
--
2.30.2
--
Francesco P. Lovergine
Re: Multiple DRI card detection in compositor systemd units
Hi Pekka, Those are fair answers. In my case, it does happen that the configuration available on the virtual cards includes a way to set distinct names reported by drmGetVersion()->name. It looks like the consensus is that UDev rules probably shouldn't be consulting the name as a distinguishing/durable identifier of cards, and that the physical path is the standard thing used to disambiguate. Thanks. -Matt On 9/23/21, 8:39 AM, "Pekka Paalanen" wrote: On Wed, 22 Sep 2021 16:16:48 + "Hoosier, Matt" wrote: > > The /dev/dri/by-path idea works, I suppose, if you have different > physical graphics cards. In my case, that's not true. These are > virtualized cards that the silicon vendor's DRM drivers use to expose > different subsets of DRM resources as different cards. So there's > only one /dev/dri/by-path card here. Think: DRM leases, but with the > lessees popping out as card nodes rather than arranged dynamically > using the drm ioctl()'s to manufature leases. That's the standard solution though, I believe: use devpath for matching the device, because the device doesn't randomly jump from a physical connector (e.g. PCIe slot) to another. But since you have virtual cards, that obviously doesn't work. I'm afraid you need to solve this with your virtual card provider. Maybe there could be some sort of virtual bus with persistent addresses which would make devpath reliable? I wouldn't expect drmGetVersion()->name to differ between the (virtual) devices since they are all using the same driver, right? Sorry, pq > The use-case here is to allow separate DRM domains for each of > several containers. It's not really desirable to try to funnel > everybody's graphics through a common compositor that runs all the > connectors. > CONFIDENTIALITY NOTICE: This email and any attachments are for the sole use of the intended recipient(s) and contain information that may be Garmin confidential and/or Garmin legally privileged. If you have received this email in error, please notify the sender by reply email and delete the message. Any disclosure, copying, distribution or use of this communication (including attachments) by someone other than the intended recipient is prohibited. Thank you.
Re: [PATCH v2 3/3] drm/bridge: ti-sn65dsi86: Add NO_CONNECTOR support
On Wed, Sep 22, 2021 at 5:44 PM Laurent Pinchart
wrote:
>
> Hi Rob,
>
> Thank you for the patch.
>
> On Mon, Sep 20, 2021 at 03:58:00PM -0700, Rob Clark wrote:
> > From: Rob Clark
> >
> > Slightly awkward to fish out the display_info when we aren't creating
> > own connector. But I don't see an obvious better way.
> >
> > v2: Remove error return with NO_CONNECTOR flag
> >
> > Signed-off-by: Rob Clark
> > ---
> > drivers/gpu/drm/bridge/ti-sn65dsi86.c | 39 ---
> > 1 file changed, 29 insertions(+), 10 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/bridge/ti-sn65dsi86.c
> > b/drivers/gpu/drm/bridge/ti-sn65dsi86.c
> > index 6154bed0af5b..94c94cc8a4d8 100644
> > --- a/drivers/gpu/drm/bridge/ti-sn65dsi86.c
> > +++ b/drivers/gpu/drm/bridge/ti-sn65dsi86.c
> > @@ -667,11 +667,6 @@ static int ti_sn_bridge_attach(struct drm_bridge
> > *bridge,
> > .node = NULL,
> >};
> >
> > - if (flags & DRM_BRIDGE_ATTACH_NO_CONNECTOR) {
> > - DRM_ERROR("Fix bridge driver to make connector optional!");
> > - return -EINVAL;
> > - }
> > -
> > pdata->aux.drm_dev = bridge->dev;
> > ret = drm_dp_aux_register(&pdata->aux);
> > if (ret < 0) {
> > @@ -679,9 +674,11 @@ static int ti_sn_bridge_attach(struct drm_bridge
> > *bridge,
> > return ret;
> > }
> >
> > - ret = ti_sn_bridge_connector_init(pdata);
> > - if (ret < 0)
> > - goto err_conn_init;
> > + if (!(flags & DRM_BRIDGE_ATTACH_NO_CONNECTOR)) {
> > + ret = ti_sn_bridge_connector_init(pdata);
> > + if (ret < 0)
> > + goto err_conn_init;
> > + }
> >
> > /*
> >* TODO: ideally finding host resource and dsi dev registration needs
> > @@ -743,7 +740,8 @@ static int ti_sn_bridge_attach(struct drm_bridge
> > *bridge,
> > err_dsi_attach:
> > mipi_dsi_device_unregister(dsi);
> > err_dsi_host:
> > - drm_connector_cleanup(&pdata->connector);
> > + if (!(flags & DRM_BRIDGE_ATTACH_NO_CONNECTOR))
> > + drm_connector_cleanup(&pdata->connector);
>
> I wonder if we actually need this. The connector gets attached to the
> encoder, won't it be destroyed by the DRM core in the error path ?
This does not appear to be the case, we leak the connector if I remove
this (and add a hack to trigger the error path)
> > err_conn_init:
> > drm_dp_aux_unregister(&pdata->aux);
> > return ret;
> > @@ -792,9 +790,30 @@ static void ti_sn_bridge_set_dsi_rate(struct
> > ti_sn65dsi86 *pdata)
> > regmap_write(pdata->regmap, SN_DSIA_CLK_FREQ_REG, val);
> > }
> >
> > +/*
> > + * Find the connector and fish out the bpc from display_info. It would
> > + * be nice if we could get this instead from drm_bridge_state, but that
> > + * doesn't yet appear to be the case.
>
> You already have a bus format in the bridge state, from which you can
> derive the bpp. Could you give it a try ?
Possibly the bridge should be converted to ->atomic_enable(), etc..
I'll leave that for another time
BR,
-R
> > + */
> > static unsigned int ti_sn_bridge_get_bpp(struct ti_sn65dsi86 *pdata)
> > {
> > - if (pdata->connector.display_info.bpc <= 6)
> > + struct drm_bridge *bridge = &pdata->bridge;
> > + struct drm_connector_list_iter conn_iter;
> > + struct drm_connector *connector;
> > + unsigned bpc = 0;
> > +
> > + drm_connector_list_iter_begin(bridge->dev, &conn_iter);
> > + drm_for_each_connector_iter(connector, &conn_iter) {
> > + if (drm_connector_has_possible_encoder(connector,
> > bridge->encoder)) {
> > + bpc = connector->display_info.bpc;
> > + break;
> > + }
> > + }
> > + drm_connector_list_iter_end(&conn_iter);
> > +
> > + WARN_ON(bpc == 0);
> > +
> > + if (bpc <= 6)
> > return 18;
> > else
> > return 24;
>
> --
> Regards,
>
> Laurent Pinchart
[PATCH v2] drm/i915/bdb: Fix version check
With patch "drm/i915/vbt: Fix backlight parsing for VBT 234+"
the size of bdb_lfp_backlight_data structure has been increased,
causing if-statement in the parse_lfp_backlight function
that comapres this structure size to the one retrieved from BDB,
always to fail for older revisions.
This patch calculates expected size of the structure for a given
BDB version and compares it with the value gathered from BDB.
Tested on Chromebook Pixelbook (Nocturne) (reports bdb->version = 221)
Tested-by: Lukasz Majczak
Signed-off-by: Lukasz Majczak
---
drivers/gpu/drm/i915/display/intel_bios.c | 11 +--
drivers/gpu/drm/i915/display/intel_vbt_defs.h | 5 +
2 files changed, 14 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_bios.c
b/drivers/gpu/drm/i915/display/intel_bios.c
index 3c25926092de..90eae6da12e0 100644
--- a/drivers/gpu/drm/i915/display/intel_bios.c
+++ b/drivers/gpu/drm/i915/display/intel_bios.c
@@ -428,6 +428,7 @@ parse_lfp_backlight(struct drm_i915_private *i915,
const struct lfp_backlight_data_entry *entry;
int panel_type = i915->vbt.panel_type;
u16 level;
+ size_t exp_size;
backlight_data = find_section(bdb, BDB_LVDS_BACKLIGHT);
if (!backlight_data)
@@ -450,9 +451,15 @@ parse_lfp_backlight(struct drm_i915_private *i915,
return;
}
+ if (bdb->version <= 234)
+ exp_size = EXP_BDB_LFP_BL_DATA_SIZE_REV_234;
+ else if (bdb->version > 234 && bdb->version <= 236)
+ exp_size = EXP_BDB_LFP_BL_DATA_SIZE_REV_236;
+ else
+ exp_size = sizeof(struct bdb_lfp_backlight_data);
+
i915->vbt.backlight.type = INTEL_BACKLIGHT_DISPLAY_DDI;
- if (bdb->version >= 191 &&
- get_blocksize(backlight_data) >= sizeof(*backlight_data)) {
+ if (bdb->version >= 191 && get_blocksize(backlight_data) >= exp_size) {
const struct lfp_backlight_control_method *method;
method = &backlight_data->backlight_control[panel_type];
diff --git a/drivers/gpu/drm/i915/display/intel_vbt_defs.h
b/drivers/gpu/drm/i915/display/intel_vbt_defs.h
index 330077c2e588..ba9990e5983c 100644
--- a/drivers/gpu/drm/i915/display/intel_vbt_defs.h
+++ b/drivers/gpu/drm/i915/display/intel_vbt_defs.h
@@ -814,6 +814,11 @@ struct lfp_brightness_level {
u16 reserved;
} __packed;
+#define EXP_BDB_LFP_BL_DATA_SIZE_REV_234 \
+ offsetof(struct bdb_lfp_backlight_data, brightness_level)
+#define EXP_BDB_LFP_BL_DATA_SIZE_REV_236 \
+ offsetof(struct bdb_lfp_backlight_data, brightness_precision_bits)
+
struct bdb_lfp_backlight_data {
u8 entry_size;
struct lfp_backlight_data_entry data[16];
--
2.33.0.464.g1972c5931b-goog
Re: [PATCH v2 0/4] CMDQ refinement of Mediatek DRM driver
Hi Chun-Kuang, Missatge de Chun-Kuang Hu del dia dt., 21 de set. 2021 a les 15:15: > > Hi, Enric: > > Enric Balletbo Serra 於 2021年9月21日 週二 下午4:36寫道： > > > > Hi Chun-Kuang, > > > > (again without html format, sorry for the noise) > > > > Missatge de Chun-Kuang Hu del dia dj., 12 > > d’ag. 2021 a les 2:13: > > > > > > Chun-Kuang Hu 於 2021年8月9日 週一 上午7:47寫道： > > > > > > > > These refinements include using standard mailbox callback interface, > > > > timeout detection, and a fixed cmdq_handle. > > > > > > For this series, applied to mediatek-drm-next [1]. > > > > > > [1] > > > https://git.kernel.org/pub/scm/linux/kernel/git/chunkuang.hu/linux.git/log/?h=mediatek-drm-next > > > > > > > These patches seem to break the display on the Acer Chromebook R 13 > > (MT8173) in the current mainline. After running a bisection it pointed > > me to the following commit > > > > commit f4be17cd5b14dd73545b0e014a63ebe9ab5ef837 > > Author: Chun-Kuang Hu > > Date: Sun Jul 4 15:36:48 2021 +0800 > > > > drm/mediatek: Remove struct cmdq_client > > > > Reverting this patch alone is not trivial, so I ended up reverting the > > full series, and I can confirm that reverting the full series makes > > the display work again. > > I think you could not just revert "drm/mediatek: Remove struct > cmdq_client", you should also revert the patches after it, such as > > "drm/mediatek: Clear pending flag when cmdq packet is done" > "drm/mediatek: Add cmdq_handle in mtk_crtc" > "drm/mediatek: Detect CMDQ execution timeout" > Yes, in fact I reverted: 9efb16c2fdd6 drm/mediatek: Clear pending flag when cmdq packet is done bc9241be73d9 drm/mediatek: Add cmdq_handle in mtk_crtc 8cdcb3653424 drm/mediatek: Detect CMDQ execution timeout f4be17cd5b14 drm/mediatek: Remove struct cmdq_client c1ec54b7b5af drm/mediatek: Use mailbox rx_callback instead of cmdq_task_cb Without these patches 5.15-rc2 works again on my platform. The commit 'c1ec54b7b5af drm/mediatek: Use mailbox rx_callback instead of cmdq_task_cb' alone introduces lots of warnings in the kernel WARNING: CPU: 0 PID: 0 at drivers/mailbox/mtk-cmdq-mailbox.c:198 cmdq_task_exec_done+0xb8/0xe0 I think is just a leftover or the mentioned warning, but that confused me a bit doing the bisection. Then, after commit 'f4be17cd5b14 drm/mediatek: Remove struct cmdq_client' my system simply gets stuck. For now I don't see any obvious mistake but will dig further. Can I ask you in which platform did you test? And if you can double check if your platform is broken too in current mainline? Thanks, Enric > If "drm/mediatek: Remove struct cmdq_client" is the patch cause > display abnormal, I think you could compare code w/ and w/o this > patch. Focus on the value accuracy, such as cmdq_cl and cmdq_chan. And > focus on the flow accuracy, such as mtk_drm_crtc_update_config() and > ddp_cmdq_cb(). If this could not find the problem, I think the latest > way is to break this patch into small patches, changes little in each > small patches and we could finally find out the problem. > > Regards, > Chun-Kuang. > > > > > Unfortunately, after the merge window, different things broke for this > > device, and I didn't finish isolating them, and it is not clear to me > > yet whether the logs I'm getting are useful for this specific issue or > > not. Basically with this series merged the kernel seems to be stuck, > > and the display is not working. Latest message is > > > > [ 12.329173] mtk-iommu 10205000.iommu: Partial TLB flush timed out, > > falling back to full flush > > > > Without the series, the kernel goes far and display works, however > > there are other issues affecting the cros-ec, but I think that's > > another issue. > > > > I'll try to dig a bit more, but, meanwhile, if you have any idea > > please let me know. > > > > Thanks, > > Enric > > > > > > > Regards, > > > Chun-Kuang. > > > > > > > > > > > Changes in v2: > > > > 1. Define mtk_drm_cmdq_pkt_create() and mtk_drm_cmdq_pkt_destroy() > > > >when CONFIG_MTK_CMDQ is reachable. > > > > > > > > Chun-Kuang Hu (4): > > > > drm/mediatek: Use mailbox rx_callback instead of cmdq_task_cb > > > > drm/mediatek: Remove struct cmdq_client > > > > drm/mediatek: Detect CMDQ execution timeout > > > > drm/mediatek: Add cmdq_handle in mtk_crtc > > > > > > > > drivers/gpu/drm/mediatek/mtk_drm_crtc.c | 110 > > > > 1 file changed, 91 insertions(+), 19 deletions(-) > > > > > > > > -- > > > > 2.25.1 > > > >
[patch 00/11] hrtimers: Cleanup hrtimer_forward() [ab]use
A recent syzbot report unearthed abuse of hrtimer_forward() which can cause runaway timers hogging the CPU in timer expiry context by rearming the timer in the past over and over. This happens when the caller uses timer->expiry for the 'now' argument of hrtimer_forward(). That works as long as the timer expiry is on time, but can cause a long period of rearm/fire loops which hog the CPU. Expiring late can have various causes, but obviously virtualization is prone to that due to VCPU scheduling. The correct usage of hrtimer_forward() is to hand the current time to the 'now' argument which ensures that the next event on the periodic time line is past now. This is what hrtimer_forward_now() provides. The following series addresses this: 1) Add a debug mechanism to the hrtimer expiry loop 2) Convert all hrtimer_forward() usage outside of kernel/time/ to use hrtimer_forward_now(). 3) Confine hrtimer_forward() to kernel/time/ core code. The mac80211_hwsim patch has already been picked up by the wireless maintainer and all other patches which affect usage outside the core code can be picked up by the relevant subsystems. If a maintainer wants me to pick a particular patch up, please let me know. The last patch which confines hrtimer_forward() will be postponed until all other patches have been merged into Linus tree. The series is also available from git: git://git.kernel.org/pub/scm/linux/kernel/git/tglx/devel.git hrtimer Thanks, tglx --- drivers/gpu/drm/i915/i915_pmu.c|2 - drivers/net/wireless/mac80211_hwsim.c |4 +- drivers/net/wwan/iosm/iosm_ipc_imem.c |4 +- drivers/power/reset/ltc2952-poweroff.c |4 -- include/linux/hrtimer.h| 26 - include/linux/posix-timers.h |3 ++ kernel/signal.c| 14 + kernel/time/hrtimer.c | 48 - kernel/time/itimer.c | 13 kernel/time/posix-timers.c | 42 +++- kernel/time/tick-internal.h|1 net/can/bcm.c |2 - sound/drivers/pcsp/pcsp_lib.c |2 - 13 files changed, 92 insertions(+), 73 deletions(-)
[patch 07/11] drm/i915/pmu: Use hrtimer_forward_now()
hrtimer_forward() is about to be removed from the public interfaces. Replace it with hrtimer_forward_now() which provides the same functionality. Signed-off-by: Thomas Gleixner Cc: David Airlie Cc: intel-...@lists.freedesktop.org Cc: Joonas Lahtinen Cc: Jani Nikula Cc: dri-devel@lists.freedesktop.org Cc: Daniel Vetter Cc: Rodrigo Vivi --- drivers/gpu/drm/i915/i915_pmu.c |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) --- a/drivers/gpu/drm/i915/i915_pmu.c +++ b/drivers/gpu/drm/i915/i915_pmu.c @@ -439,7 +439,7 @@ static enum hrtimer_restart i915_sample( engines_sample(gt, period_ns); frequency_sample(gt, period_ns); - hrtimer_forward(hrtimer, now, ns_to_ktime(PERIOD)); + hrtimer_forward_now(hrtimer, ns_to_ktime(PERIOD)); return HRTIMER_RESTART; }
Re: [PATCH v3 1/6] drm/vc4: select PM (openrisc)
On Thu, Sep 23, 2021 at 07:55:32AM -0700, Nathan Chancellor wrote:
> On Thu, Sep 23, 2021 at 04:52:08PM +0200, Maxime Ripard wrote:
> > Hi Nathan,
> >
> > On Wed, Sep 22, 2021 at 08:49:50AM -0700, Nathan Chancellor wrote:
> > > On Wed, Sep 22, 2021 at 10:41:56AM +0200, Maxime Ripard wrote:
> > > > Hi Randy,
> > > >
> > > > On Sun, Sep 19, 2021 at 09:40:44AM -0700, Randy Dunlap wrote:
> > > > > On 8/19/21 6:59 AM, Maxime Ripard wrote:
> > > > > > We already depend on runtime PM to get the power domains and clocks
> > > > > > for
> > > > > > most of the devices supported by the vc4 driver, so let's just
> > > > > > select it
> > > > > > to make sure it's there, and remove the ifdef.
> > > > > >
> > > > > > Signed-off-by: Maxime Ripard
> > > > > > ---
> > > > > > drivers/gpu/drm/vc4/Kconfig| 1 +
> > > > > > drivers/gpu/drm/vc4/vc4_hdmi.c | 2 --
> > > > > > 2 files changed, 1 insertion(+), 2 deletions(-)
> > > > > >
> > > > > > diff --git a/drivers/gpu/drm/vc4/Kconfig
> > > > > > b/drivers/gpu/drm/vc4/Kconfig
> > > > > > index 118e8a426b1a..f774ab340863 100644
> > > > > > --- a/drivers/gpu/drm/vc4/Kconfig
> > > > > > +++ b/drivers/gpu/drm/vc4/Kconfig
> > > > > > @@ -9,6 +9,7 @@ config DRM_VC4
> > > > > > select DRM_KMS_CMA_HELPER
> > > > > > select DRM_GEM_CMA_HELPER
> > > > > > select DRM_PANEL_BRIDGE
> > > > > > + select PM
> > > > > > select SND_PCM
> > > > > > select SND_PCM_ELD
> > > > > > select SND_SOC_GENERIC_DMAENGINE_PCM
> > > > > > diff --git a/drivers/gpu/drm/vc4/vc4_hdmi.c
> > > > > > b/drivers/gpu/drm/vc4/vc4_hdmi.c
> > > > > > index c2876731ee2d..602203b2d8e1 100644
> > > > > > --- a/drivers/gpu/drm/vc4/vc4_hdmi.c
> > > > > > +++ b/drivers/gpu/drm/vc4/vc4_hdmi.c
> > > > > > @@ -2107,7 +2107,6 @@ static int vc5_hdmi_init_resources(struct
> > > > > > vc4_hdmi *vc4_hdmi)
> > > > > > return 0;
> > > > > > }
> > > > > > -#ifdef CONFIG_PM
> > > > > > static int vc4_hdmi_runtime_suspend(struct device *dev)
> > > > > > {
> > > > > > struct vc4_hdmi *vc4_hdmi = dev_get_drvdata(dev);
> > > > > > @@ -2128,7 +2127,6 @@ static int vc4_hdmi_runtime_resume(struct
> > > > > > device *dev)
> > > > > > return 0;
> > > > > > }
> > > > > > -#endif
> > > > > > static int vc4_hdmi_bind(struct device *dev, struct device
> > > > > > *master, void *data)
> > > > > > {
> > > > > >
> > > > >
> > > > > Hi,
> > > > >
> > > > > FYI.
> > > > >
> > > > > This still causes a build error on arch/openrisc/ since it does not
> > > > > support
> > > > > CONFIG_PM (it does not source "kernel/power/Kconfig" like some other
> > > > > arches do):
> > > > >
> > > > > ./arch/riscv/Kconfig:source "kernel/power/Kconfig"
> > > > > ./arch/x86/Kconfig:source "kernel/power/Kconfig"
> > > > > ./arch/nds32/Kconfig:source "kernel/power/Kconfig"
> > > > > ./arch/sh/Kconfig:source "kernel/power/Kconfig"
> > > > > ./arch/arc/Kconfig:source "kernel/power/Kconfig"
> > > > > ./arch/arm64/Kconfig:source "kernel/power/Kconfig"
> > > > > ./arch/xtensa/Kconfig:source "kernel/power/Kconfig"
> > > > > ./arch/sparc/Kconfig:source "kernel/power/Kconfig"
> > > > > ./arch/arm/Kconfig:source "kernel/power/Kconfig"
> > > > > ./arch/mips/Kconfig:source "kernel/power/Kconfig"
> > > > > ./arch/powerpc/Kconfig:source "kernel/power/Kconfig"
> > > > > ./arch/um/Kconfig:source "kernel/power/Kconfig"
> > > > > ./arch/ia64/Kconfig:source "kernel/power/Kconfig"
> > > > >
> > > > > so with
> > > > > CONFIG_DRM_VC4=y
> > > > > # CONFIG_DRM_VC4_HDMI_CEC is not set
> > > > >
> > > > > I still see
> > > > > ../drivers/gpu/drm/vc4/vc4_hdmi.c:2139:12: warning:
> > > > > 'vc4_hdmi_runtime_suspend' defined but not used [-Wunused-function]
> > > > > 2139 | static int vc4_hdmi_runtime_suspend(struct device *dev)
> > > > > |^~~~
> > > >
> > > > With what version did you get that build error? -rc2 shouldn't have it
> > > > anymore since the runtime_pm hooks introduction got reverted.
> > >
> > > -next still contains these patches as Stephen effectively reverted the
> > > changes in Linus' tree when merging in the drm-misc-fixes tree:
> > >
> > > https://lore.kernel.org/r/20210920090729.19458...@canb.auug.org.au/
> >
> > Ah, indeed, thanks.
> >
> > What's the typical fix for these errors?
> >
> > I guess adding a depends on ARM || ARM64 || COMPILE_TEST would work?
>
> I think the typical fix from most people is marking these functions as
> __maybe_unused so that they are always defined but the compiler does not
> warn. An alternative would be changing the "select PM" to be
> "depends on PM" I believe but that is less frequent.
Thanks for the suggestion. Since those functions are always going to be
used anyway (but on COMPILE_TEST), I've chosen the opposite approach of
dropping SET_RUNTIME_PM_OPS instead. You're in CC of that patch so feel
free to comment there if you think this is wrong.
Maxime
signature.asc
Description: PGP signature
Re: [PATCH v2 09/12] lib: test_hmm add module param for zone device type
On 9/21/2021 12:14 AM, Alistair Popple wrote:
On Tuesday, 21 September 2021 6:05:30 AM AEST Sierra Guiza, Alejandro (Alex)
wrote:
On 9/20/2021 3:53 AM, Alistair Popple wrote:
On Tuesday, 14 September 2021 2:16:01 AM AEST Alex Sierra wrote:
In order to configure device public in test_hmm, two module parameters
should be passed, which correspond to the SP start address of each
device (2) spm_addr_dev0 & spm_addr_dev1. If no parameters are passed,
private device type is configured.
It's a pity that testing this seems to require some amount of special setup to
test. Is there a way this could be made to work on a more standard setup
similar to how DEVICE_PRIVATE is tested?
Hi Alistair
We tried to do it as simpler as possible. Unfortunately, there are two main
requirements to register dev memory as DEVICE_PUBLIC type. This memory must
NOT be accessed by any memory allocator (SLAB, SLOB, SLUB) plus, it has
to be
CPU coherently accessed. We also want to avoid aliasing the same PFNs for
different page types (regular system memory and DEVICE_PUBLIC). So we don't
want the reserved memory to be part of the kernel's memory map before we
call
memremap_pages. A transparent way of doing it, without any special HW, was
setting a portion of system memory as SPM (Special purpose memory). And use
this as our “device fake” memory.
Ok, I think it's great that we can test this without special HW but the boot
time configuration is still a bit annoying. Would it be possible to allocate
memory fitting the above requirements by hot unplugging it with something like
offline_and_remove_memory()?
I also don't see why the DEVICE_PRIVATE and DEVICE_PUBLIC testing should be
mutually exclusive - why can't we test both without reloading the module?
You could do both DEVICE_PRIVATE and DEVICE_PUBLIC tests by running the
test_hmm_sh
script twice, just passing the proper parameters. Even when you booted
with fake EFI SP
regions. If spm_address_dev0/1 parameters are passed, the module gets
configured with
DEVICE_PUBLIC type. Otherwise DEVICE_PRIVATE type is set. Technically
the only
complication in testing DEVICE_PUBLIC is the fake SPM boot parameter.
Alex Sierra
- Alistair
Regards,
Alex Sierra
Signed-off-by: Alex Sierra
---
v5:
Remove devmem->pagemap.type = MEMORY_DEVICE_PRIVATE at
dmirror_allocate_chunk that was forcing to configure pagemap.type
to MEMORY_DEVICE_PRIVATE
v6:
Check for null pointers for resource and memremap references
at dmirror_allocate_chunk
v7:
Due to patch dropped from these patch series "kernel: resource:
lookup_resource as exported symbol", lookup_resource was not longer a
callable function. This was used in public device configuration, to
get start and end addresses, to create pgmap->range struct. This
information is now taken directly from the spm_addr_devX parameters and
the fixed size DEVMEM_CHUNK_SIZE.
---
lib/test_hmm.c | 66 +++--
lib/test_hmm_uapi.h | 1 +
2 files changed, 47 insertions(+), 20 deletions(-)
diff --git a/lib/test_hmm.c b/lib/test_hmm.c
index 3cd91ca31dd7..ef27e355738a 100644
--- a/lib/test_hmm.c
+++ b/lib/test_hmm.c
@@ -33,6 +33,16 @@
#define DEVMEM_CHUNK_SIZE(256 * 1024 * 1024U)
#define DEVMEM_CHUNKS_RESERVE16
+static unsigned long spm_addr_dev0;
+module_param(spm_addr_dev0, long, 0644);
+MODULE_PARM_DESC(spm_addr_dev0,
+ "Specify start address for SPM (special purpose memory) used for
device 0. By setting this Generic device type will be used. Make sure spm_addr_dev1 is
set too");
+
+static unsigned long spm_addr_dev1;
+module_param(spm_addr_dev1, long, 0644);
+MODULE_PARM_DESC(spm_addr_dev1,
+ "Specify start address for SPM (special purpose memory) used for
device 1. By setting this Generic device type will be used. Make sure spm_addr_dev0 is
set too");
+
static const struct dev_pagemap_ops dmirror_devmem_ops;
static const struct mmu_interval_notifier_ops dmirror_min_ops;
static dev_t dmirror_dev;
@@ -450,11 +460,11 @@ static int dmirror_write(struct dmirror *dmirror, struct
hmm_dmirror_cmd *cmd)
return ret;
}
-static bool dmirror_allocate_chunk(struct dmirror_device *mdevice,
+static int dmirror_allocate_chunk(struct dmirror_device *mdevice,
struct page **ppage)
{
struct dmirror_chunk *devmem;
- struct resource *res;
+ struct resource *res = NULL;
unsigned long pfn;
unsigned long pfn_first;
unsigned long pfn_last;
@@ -462,17 +472,29 @@ static bool dmirror_allocate_chunk(struct dmirror_device
*mdevice,
devmem = kzalloc(sizeof(*devmem), GFP_KERNEL);
if (!devmem)
- return false;
+ return -ENOMEM;
- res = request_free_mem_region(&iomem_resource, DEVMEM_CHUNK_SIZE,
- "hmm_dmirror");
- if (IS_ERR(res))
- goto err_devmem;
+ if (!spm
Re: [RFC PATCH v3 1/6] drm/doc: Color Management and HDR10 RFC
On 2021-09-23 9:40 a.m., Harry Wentland wrote: On 2021-09-23 04:01, Pekka Paalanen wrote: On Wed, 22 Sep 2021 11:06:53 -0400 Harry Wentland wrote: On 2021-09-20 20:14, Harry Wentland wrote: On 2021-09-15 10:01, Pekka Paalanen wrote:> On Fri, 30 Jul 2021 16:41:29 -0400 Harry Wentland wrote: +If a display's maximum HDR white level is correctly reported it is trivial +to convert between all of the above representations of SDR white level. If +it is not, defining SDR luminance as a nits value, or a ratio vs a fixed +nits value is preferred, assuming we are blending in linear space. + +It is our experience that many HDR displays do not report maximum white +level correctly Which value do you refer to as "maximum white", and how did you measure it? Good question. I haven't played with those displays myself but I'll try to find out a bit more background behind this statement. Some TVs report the EOTF but not the luminance values. For an example edid-code capture of my eDP HDR panel: HDR Static Metadata Data Block: Electro optical transfer functions: Traditional gamma - SDR luminance range SMPTE ST2084 Supported static metadata descriptors: Static metadata type 1 Desired content max luminance: 115 (603.666 cd/m^2) Desired content max frame-average luminance: 109 (530.095 cd/m^2) Desired content min luminance: 7 (0.005 cd/m^2) I forget where I heard (you, Vitaly, someone?) that integrated panels may not have the magic gamut and tone mapping hardware, which means that software (or display engine) must do the full correct thing. That's another reason to not rely on magic display functionality, which suits my plans perfectly. I've mentioned it before but there aren't really a lot of integrated HDR panels yet. I think we've only seen one or two without tone-mapping ability. Either way we probably need at least the ability to tone-map the output on the transmitter side (SW, GPU, or display HW). It is really interesting to see the quality of panel TM algorithm by specifying different metadata and validate how severe loss of details which could mean no TM at all or 1DLUT is used to soften the clipping or 3DLUT( which has wider possibilities for TM) To facilitate this development we may use LCMS proofing capabilities to allow simulate the image view on high end(wide gamut display) how it may looks on low end (narrow gamut displays or integrated panels) I suspect on those TVs it looks like this: HDR Static Metadata Data Block: Electro optical transfer functions: Traditional gamma - SDR luminance range SMPTE ST2084 Supported static metadata descriptors: Static metadata type 1 Windows has some defaults in this case and our Windows driver also has some defaults. Oh, missing information. Yay. Using defaults in the 1000-2000 nits range would yield much better tone-mapping results than assuming the monitor can support a full 10k nits. Obviously. As an aside, recently we've come across displays where the max average luminance is higher than the max peak luminance. This is not a mistake but due to how the display's dimming zones work. IOW, the actual max peak luminance in absolute units depends on the current image average luminance. Wonderful, but what am I (the content producer, the display server) supposed to do with that information... Not sure what impact this might have on tone-mapping, other than to keep in mind that we can assume that max_avg < max_peak. *cannot Right Seems like it would lead to a very different tone mapping algorithm which needs to compute the image average luminance before it can account for max peak luminance (which I wouldn't know how to infer). So either a two-pass algorithm, or taking the average from the previous frame. I imagine that is going to be fun considering one needs to composite different types of input images together, and the final tone mapping might need to differ for each. Strictly thinking that might lead to an iterative optimisation algorithm which would be quite intractable in practise to complete for a single frame at a time. Maybe a good approach for this would be to just consider MaxAvg = MaxPeak in this case. At least until one would want to consider dynamic tone-mapping, i.e. tone-mapping that is changing frame-by-frame based on content. Dynamic tone-mapping might be challenging to do in SW but could be a possibility with specialized HW. Though I'm not sure exactly how that HW would look like. Maybe something like a histogram engine like Laurent mentions in https://lists.freedesktop.org/archives/dri-devel/2021-June/311689.html. Harry Thanks, pq
Re: [Intel-gfx] [PATCH v6 3/9] drm/i915/gt: Increase suspend timeout
On 9/23/21 4:33 PM, Tvrtko Ursulin wrote: On 23/09/2021 14:19, Thomas Hellström wrote: On 9/23/21 2:59 PM, Tvrtko Ursulin wrote: On 23/09/2021 12:47, Thomas Hellström wrote: Hi, Tvrtko, On 9/23/21 12:13 PM, Tvrtko Ursulin wrote: On 22/09/2021 07:25, Thomas Hellström wrote: With GuC submission on DG1, the execution of the requests times out for the gem_exec_suspend igt test case after executing around 800-900 of 1000 submitted requests. Given the time we allow elsewhere for fences to signal (in the order of seconds), increase the timeout before we mark the gt wedged and proceed. I suspect it is not about requests not retiring in time but about the intel_guc_wait_for_idle part of intel_gt_wait_for_idle. Although I don't know which G2H message is the code waiting for at suspend time so perhaps something to run past the GuC experts. So what's happening here is that the tests submits 1000 requests, each writing a value to an object, and then that object content is checked after resume. With GuC it turns out that only 800-900 or so values are actually written before we time out, and the test (basic-S3) fails, but not on every run. Yes and that did not make sense to me. It is a single context even so I did not come up with an explanation why would GuC be slower. Unless it somehow manages to not even update the ring tail in time and requests are still only stuck in the software queue? Perhaps you can see that from context tail and head when it happens. This is a bit interesting in itself, because I never saw the hang-S3 test fail, which from what I can tell basically is an identical test but with a spinner submitted after the 1000th request. Could be that the suspend backup code ends up waiting for something before we end up in intel_gt_wait_for_idle, giving more requests time to execute. No idea, I don't know the suspend paths that well. For instance before looking at the code I thought we would preempt what's executing and not wait for everything that has been submitted to finish. :) Anyway, if that turns out to be correct then perhaps it would be better to split the two timeouts (like if required GuC timeout is perhaps fundamentally independent) so it's clear who needs how much time. Adding Matt and John to comment. You mean we have separate timeouts depending on whether we're using GuC or execlists submission? No, I don't know yet. First I think we need to figure out what exactly is happening. Well then TBH I will need to file a separate Jira about that. There might be various things going on here like swiching between the migrate context for eviction of unrelated LMEM buffers and the context used by gem_exec_suspend. The gem_exec_suspend failures are blocking DG1 BAT so it's pretty urgent to get this series merged. If you insist I can leave this patch out for now, but rather I'd commit it as is and File a Jira instead. I see now how you have i915_gem_suspend() in between two lmem_suspend() calls in this series. So first call has the potential of creating a lot of requests and that you think interferes? Sounds plausible but implies GuC timeslicing is less efficient if I follow? Yes, I guess so. Not sure exactly what is not performing so well with the GuC but some tests really take a big performance hit, like gem_lmem_swapping and gem_exec_whisper, but those may trigger entirely different situations than what we have here. IMO it is okay to leave for follow up work but strictly speaking, unless I am missing something, the approach of bumping the timeout does not sound valid if the copying is done async. Not async ATM. In any case It will probably make sense to sync before we start the GT timeout, so that remaining work can be done undisturbed by the copying. That way copying will always succeed, but depending on how much and what type of work user-space has queued up, it might be terminated. Because the timeout is then mandated not only as function of GPU activity (lets say user controlled), but also the amount of unpinned/idle buffers which happen to be laying around (which is more i915 controlled, or mixed at least). So question is, with enough data to copy, any timeout could be too low and then how long do we want to wait before failing suspend? Is this an argument to have a separate timeout specifically addressing the suspend path or not I am not sure. Perhaps there is no choice and simply wait until buffers are swapped out otherwise nothing will work. Regards, Tvrtko Thanks, Thomas.
Re: [PATCH] drm/i915/guc, docs: Fix pdfdocs build error by removing nested grid
On Mon, 20 Sep 2021, Akira Yokosawa wrote:
> Nested grids in grid-table cells are not specified as proper ReST
> constructs.
> Commit 572f2a5cd974 ("drm/i915/guc: Update firmware to v62.0.0")
> added a couple of kerneldoc tables of the form:
>
> +---+---+--+
> | 1 | 31:0 | ++ |
> +---+---+ || |
> |...| | | Embedded `HXG Message`_ | |
> +---+---+ || |
> | n | 31:0 | ++ |
> +---+---+--+
>
> For "make htmldocs", they happen to work as one might expect,
> but they are incompatible with "make latexdocs" and "make pdfdocs",
> and cause the generated gpu.tex file to become incomplete and
> unbuildable by xelatex.
>
> Restore the compatibility by removing those nested grids in the tables.
>
> Size comparison of generated gpu.tex:
>
> Sphinx 2.4.4 Sphinx 4.2.0
> v5.14: 3238686 3841631
> v5.15-rc1:376270432729
> with this fix: 3377846 3998095
>
> Fixes: 572f2a5cd974 ("drm/i915/guc: Update firmware to v62.0.0")
> Cc: John Harrison
> Cc: Michal Wajdeczko
> Cc: Matthew Brost
> Cc: Daniele Ceraolo Spurio
> Cc: Matt Roper
> Cc: Jonathan Corbet
> Signed-off-by: Akira Yokosawa
Pushed to drm-intel-gt-next, thanks for the patch.
This makes the HTML output arguably worse, but there were no comments
from anyone and the pdf build needs to work.
BR,
Jani.
> ---
> Hi all,
>
> I know there is little interest in building pdfdocs (or LaTeX) version
> of kernel-doc, and this issue does not matter most of you.
>
> But "make pdfdocs" is supposed to work, give or take those tables
> with squeezed columns, and at least it is expected to complete
> without fatal errors.
>
> I have no idea who is responsible to those grid-tables, so added
> a lot of people in the To: and Cc: lists.
>
> Does removing those nested grids look reasonable to you?
>
> Any feedback is welcome!
>
> Note: This patch is against the docs-next branch of Jon's -doc tree
> (git://git.lwn.net/linux.git). It can be applied against v5.15-rc1
> and v5.15-rc2 as well.
>
> Thanks, Akira
> --
> .../gpu/drm/i915/gt/uc/abi/guc_communication_ctb_abi.h | 10 +-
> .../drm/i915/gt/uc/abi/guc_communication_mmio_abi.h| 10 +-
> 2 files changed, 10 insertions(+), 10 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/gt/uc/abi/guc_communication_ctb_abi.h
> b/drivers/gpu/drm/i915/gt/uc/abi/guc_communication_ctb_abi.h
> index 99e1fad5ca20..c9086a600bce 100644
> --- a/drivers/gpu/drm/i915/gt/uc/abi/guc_communication_ctb_abi.h
> +++ b/drivers/gpu/drm/i915/gt/uc/abi/guc_communication_ctb_abi.h
> @@ -102,11 +102,11 @@ static_assert(sizeof(struct guc_ct_buffer_desc) == 64);
> * |
> +---+--+
> * | | 7:0 | NUM_DWORDS = length (in dwords) of the embedded HXG
> message |
> *
> +---+---+--+
> - * | 1 | 31:0 |
> ++ |
> - * +---+---+ |
> | |
> - * |...| | | Embedded `HXG Message`_
> | |
> - * +---+---+ |
> | |
> - * | n | 31:0 |
> ++ |
> + * | 1 | 31:0 |
> |
> + * +---+---+
> |
> + * |...| | [Embedded `HXG Message`_]
> |
> + * +---+---+
> |
> + * | n | 31:0 |
> |
> *
> +---+---+--+
> */
>
> diff --git a/drivers/gpu/drm/i915/gt/uc/abi/guc_communication_mmio_abi.h
> b/drivers/gpu/drm/i915/gt/uc/abi/guc_communication_mmio_abi.h
> index bbf1ddb77434..9baa3cb07d13 100644
> --- a/drivers/gpu/drm/i915/gt/uc/abi/guc_communication_mmio_abi.h
> +++ b/drivers/gpu/drm/i915/gt/uc/abi/guc_communication_mmio_abi.h
> @@ -38,11 +38,11 @@
> *
> +---+---+--+
> * | | Bits | Description
> |
> *
> +===+===+==+
> - * | 0 | 31:0 |
> ++ |
> - * +---+---+ |
Re: [PATCH v3 1/6] drm/vc4: select PM (openrisc)
On Thu, Sep 23, 2021 at 04:52:08PM +0200, Maxime Ripard wrote:
> Hi Nathan,
>
> On Wed, Sep 22, 2021 at 08:49:50AM -0700, Nathan Chancellor wrote:
> > On Wed, Sep 22, 2021 at 10:41:56AM +0200, Maxime Ripard wrote:
> > > Hi Randy,
> > >
> > > On Sun, Sep 19, 2021 at 09:40:44AM -0700, Randy Dunlap wrote:
> > > > On 8/19/21 6:59 AM, Maxime Ripard wrote:
> > > > > We already depend on runtime PM to get the power domains and clocks
> > > > > for
> > > > > most of the devices supported by the vc4 driver, so let's just select
> > > > > it
> > > > > to make sure it's there, and remove the ifdef.
> > > > >
> > > > > Signed-off-by: Maxime Ripard
> > > > > ---
> > > > > drivers/gpu/drm/vc4/Kconfig| 1 +
> > > > > drivers/gpu/drm/vc4/vc4_hdmi.c | 2 --
> > > > > 2 files changed, 1 insertion(+), 2 deletions(-)
> > > > >
> > > > > diff --git a/drivers/gpu/drm/vc4/Kconfig b/drivers/gpu/drm/vc4/Kconfig
> > > > > index 118e8a426b1a..f774ab340863 100644
> > > > > --- a/drivers/gpu/drm/vc4/Kconfig
> > > > > +++ b/drivers/gpu/drm/vc4/Kconfig
> > > > > @@ -9,6 +9,7 @@ config DRM_VC4
> > > > > select DRM_KMS_CMA_HELPER
> > > > > select DRM_GEM_CMA_HELPER
> > > > > select DRM_PANEL_BRIDGE
> > > > > + select PM
> > > > > select SND_PCM
> > > > > select SND_PCM_ELD
> > > > > select SND_SOC_GENERIC_DMAENGINE_PCM
> > > > > diff --git a/drivers/gpu/drm/vc4/vc4_hdmi.c
> > > > > b/drivers/gpu/drm/vc4/vc4_hdmi.c
> > > > > index c2876731ee2d..602203b2d8e1 100644
> > > > > --- a/drivers/gpu/drm/vc4/vc4_hdmi.c
> > > > > +++ b/drivers/gpu/drm/vc4/vc4_hdmi.c
> > > > > @@ -2107,7 +2107,6 @@ static int vc5_hdmi_init_resources(struct
> > > > > vc4_hdmi *vc4_hdmi)
> > > > > return 0;
> > > > > }
> > > > > -#ifdef CONFIG_PM
> > > > > static int vc4_hdmi_runtime_suspend(struct device *dev)
> > > > > {
> > > > > struct vc4_hdmi *vc4_hdmi = dev_get_drvdata(dev);
> > > > > @@ -2128,7 +2127,6 @@ static int vc4_hdmi_runtime_resume(struct
> > > > > device *dev)
> > > > > return 0;
> > > > > }
> > > > > -#endif
> > > > > static int vc4_hdmi_bind(struct device *dev, struct device *master,
> > > > > void *data)
> > > > > {
> > > > >
> > > >
> > > > Hi,
> > > >
> > > > FYI.
> > > >
> > > > This still causes a build error on arch/openrisc/ since it does not
> > > > support
> > > > CONFIG_PM (it does not source "kernel/power/Kconfig" like some other
> > > > arches do):
> > > >
> > > > ./arch/riscv/Kconfig:source "kernel/power/Kconfig"
> > > > ./arch/x86/Kconfig:source "kernel/power/Kconfig"
> > > > ./arch/nds32/Kconfig:source "kernel/power/Kconfig"
> > > > ./arch/sh/Kconfig:source "kernel/power/Kconfig"
> > > > ./arch/arc/Kconfig:source "kernel/power/Kconfig"
> > > > ./arch/arm64/Kconfig:source "kernel/power/Kconfig"
> > > > ./arch/xtensa/Kconfig:source "kernel/power/Kconfig"
> > > > ./arch/sparc/Kconfig:source "kernel/power/Kconfig"
> > > > ./arch/arm/Kconfig:source "kernel/power/Kconfig"
> > > > ./arch/mips/Kconfig:source "kernel/power/Kconfig"
> > > > ./arch/powerpc/Kconfig:source "kernel/power/Kconfig"
> > > > ./arch/um/Kconfig:source "kernel/power/Kconfig"
> > > > ./arch/ia64/Kconfig:source "kernel/power/Kconfig"
> > > >
> > > > so with
> > > > CONFIG_DRM_VC4=y
> > > > # CONFIG_DRM_VC4_HDMI_CEC is not set
> > > >
> > > > I still see
> > > > ../drivers/gpu/drm/vc4/vc4_hdmi.c:2139:12: warning:
> > > > 'vc4_hdmi_runtime_suspend' defined but not used [-Wunused-function]
> > > > 2139 | static int vc4_hdmi_runtime_suspend(struct device *dev)
> > > > |^~~~
> > >
> > > With what version did you get that build error? -rc2 shouldn't have it
> > > anymore since the runtime_pm hooks introduction got reverted.
> >
> > -next still contains these patches as Stephen effectively reverted the
> > changes in Linus' tree when merging in the drm-misc-fixes tree:
> >
> > https://lore.kernel.org/r/20210920090729.19458...@canb.auug.org.au/
>
> Ah, indeed, thanks.
>
> What's the typical fix for these errors?
>
> I guess adding a depends on ARM || ARM64 || COMPILE_TEST would work?
I think the typical fix from most people is marking these functions as
__maybe_unused so that they are always defined but the compiler does not
warn. An alternative would be changing the "select PM" to be
"depends on PM" I believe but that is less frequent.
Cheers,
Nathan
Re: [PATCH v3 1/6] drm/vc4: select PM (openrisc)
Hi Nathan,
On Wed, Sep 22, 2021 at 08:49:50AM -0700, Nathan Chancellor wrote:
> On Wed, Sep 22, 2021 at 10:41:56AM +0200, Maxime Ripard wrote:
> > Hi Randy,
> >
> > On Sun, Sep 19, 2021 at 09:40:44AM -0700, Randy Dunlap wrote:
> > > On 8/19/21 6:59 AM, Maxime Ripard wrote:
> > > > We already depend on runtime PM to get the power domains and clocks for
> > > > most of the devices supported by the vc4 driver, so let's just select it
> > > > to make sure it's there, and remove the ifdef.
> > > >
> > > > Signed-off-by: Maxime Ripard
> > > > ---
> > > > drivers/gpu/drm/vc4/Kconfig| 1 +
> > > > drivers/gpu/drm/vc4/vc4_hdmi.c | 2 --
> > > > 2 files changed, 1 insertion(+), 2 deletions(-)
> > > >
> > > > diff --git a/drivers/gpu/drm/vc4/Kconfig b/drivers/gpu/drm/vc4/Kconfig
> > > > index 118e8a426b1a..f774ab340863 100644
> > > > --- a/drivers/gpu/drm/vc4/Kconfig
> > > > +++ b/drivers/gpu/drm/vc4/Kconfig
> > > > @@ -9,6 +9,7 @@ config DRM_VC4
> > > > select DRM_KMS_CMA_HELPER
> > > > select DRM_GEM_CMA_HELPER
> > > > select DRM_PANEL_BRIDGE
> > > > + select PM
> > > > select SND_PCM
> > > > select SND_PCM_ELD
> > > > select SND_SOC_GENERIC_DMAENGINE_PCM
> > > > diff --git a/drivers/gpu/drm/vc4/vc4_hdmi.c
> > > > b/drivers/gpu/drm/vc4/vc4_hdmi.c
> > > > index c2876731ee2d..602203b2d8e1 100644
> > > > --- a/drivers/gpu/drm/vc4/vc4_hdmi.c
> > > > +++ b/drivers/gpu/drm/vc4/vc4_hdmi.c
> > > > @@ -2107,7 +2107,6 @@ static int vc5_hdmi_init_resources(struct
> > > > vc4_hdmi *vc4_hdmi)
> > > > return 0;
> > > > }
> > > > -#ifdef CONFIG_PM
> > > > static int vc4_hdmi_runtime_suspend(struct device *dev)
> > > > {
> > > > struct vc4_hdmi *vc4_hdmi = dev_get_drvdata(dev);
> > > > @@ -2128,7 +2127,6 @@ static int vc4_hdmi_runtime_resume(struct device
> > > > *dev)
> > > > return 0;
> > > > }
> > > > -#endif
> > > > static int vc4_hdmi_bind(struct device *dev, struct device *master,
> > > > void *data)
> > > > {
> > > >
> > >
> > > Hi,
> > >
> > > FYI.
> > >
> > > This still causes a build error on arch/openrisc/ since it does not
> > > support
> > > CONFIG_PM (it does not source "kernel/power/Kconfig" like some other
> > > arches do):
> > >
> > > ./arch/riscv/Kconfig:source "kernel/power/Kconfig"
> > > ./arch/x86/Kconfig:source "kernel/power/Kconfig"
> > > ./arch/nds32/Kconfig:source "kernel/power/Kconfig"
> > > ./arch/sh/Kconfig:source "kernel/power/Kconfig"
> > > ./arch/arc/Kconfig:source "kernel/power/Kconfig"
> > > ./arch/arm64/Kconfig:source "kernel/power/Kconfig"
> > > ./arch/xtensa/Kconfig:source "kernel/power/Kconfig"
> > > ./arch/sparc/Kconfig:source "kernel/power/Kconfig"
> > > ./arch/arm/Kconfig:source "kernel/power/Kconfig"
> > > ./arch/mips/Kconfig:source "kernel/power/Kconfig"
> > > ./arch/powerpc/Kconfig:source "kernel/power/Kconfig"
> > > ./arch/um/Kconfig:source "kernel/power/Kconfig"
> > > ./arch/ia64/Kconfig:source "kernel/power/Kconfig"
> > >
> > > so with
> > > CONFIG_DRM_VC4=y
> > > # CONFIG_DRM_VC4_HDMI_CEC is not set
> > >
> > > I still see
> > > ../drivers/gpu/drm/vc4/vc4_hdmi.c:2139:12: warning:
> > > 'vc4_hdmi_runtime_suspend' defined but not used [-Wunused-function]
> > > 2139 | static int vc4_hdmi_runtime_suspend(struct device *dev)
> > > |^~~~
> >
> > With what version did you get that build error? -rc2 shouldn't have it
> > anymore since the runtime_pm hooks introduction got reverted.
>
> -next still contains these patches as Stephen effectively reverted the
> changes in Linus' tree when merging in the drm-misc-fixes tree:
>
> https://lore.kernel.org/r/20210920090729.19458...@canb.auug.org.au/
Ah, indeed, thanks.
What's the typical fix for these errors?
I guess adding a depends on ARM || ARM64 || COMPILE_TEST would work?
Maxime
signature.asc
Description: PGP signature
Re: [PATCH] drm/ttm: Don't delete the system manager before the delayed delete
Am 23.09.21 um 15:53 schrieb Zack Rusin: On 9/20/21 10:59 AM, Zack Rusin wrote: On Sep 20, 2021, at 02:30, Christian König wrote: Am 17.09.21 um 19:53 schrieb Zack Rusin: On some hardware, in particular in virtualized environments, the system memory can be shared with the "hardware". In those cases the BO's allocated through the ttm system manager might be busy during ttm_bo_put which results in them being scheduled for a delayed deletion. While the patch itself is probably fine the reasoning here is a clear NAK. Buffers in the system domain are not GPU accessible by definition, even in a shared environment and so *must* be idle. I’m assuming that means they are not allowed to be ever fenced then, yes? Any thoughts on this? I'd love a confirmation because it would mean I need to go and rewrite the vmwgfx_mob.c bits where we use TTM_PL_SYSTEM memory (through vmw_bo_create_and_populate) for a page table which is read by the host, and those bo's need to be fenced to prevent destruction of the page tables while the memory they point to is still used. So if those were never allowed to be fenced in the first place we probably need to add a new memory type to hold those page tables. Yeah, as far as I can see that is pretty much illegal from a design point of view. We could probably change that rule on the TTM side, but I think that keeping the design as it is and adding a placement in vmwgfx sounds like the cleaner approach. Christian. z
Re: [Intel-gfx] [PATCH v6 3/9] drm/i915/gt: Increase suspend timeout
On 23/09/2021 14:19, Thomas Hellström wrote: On 9/23/21 2:59 PM, Tvrtko Ursulin wrote: On 23/09/2021 12:47, Thomas Hellström wrote: Hi, Tvrtko, On 9/23/21 12:13 PM, Tvrtko Ursulin wrote: On 22/09/2021 07:25, Thomas Hellström wrote: With GuC submission on DG1, the execution of the requests times out for the gem_exec_suspend igt test case after executing around 800-900 of 1000 submitted requests. Given the time we allow elsewhere for fences to signal (in the order of seconds), increase the timeout before we mark the gt wedged and proceed. I suspect it is not about requests not retiring in time but about the intel_guc_wait_for_idle part of intel_gt_wait_for_idle. Although I don't know which G2H message is the code waiting for at suspend time so perhaps something to run past the GuC experts. So what's happening here is that the tests submits 1000 requests, each writing a value to an object, and then that object content is checked after resume. With GuC it turns out that only 800-900 or so values are actually written before we time out, and the test (basic-S3) fails, but not on every run. Yes and that did not make sense to me. It is a single context even so I did not come up with an explanation why would GuC be slower. Unless it somehow manages to not even update the ring tail in time and requests are still only stuck in the software queue? Perhaps you can see that from context tail and head when it happens. This is a bit interesting in itself, because I never saw the hang-S3 test fail, which from what I can tell basically is an identical test but with a spinner submitted after the 1000th request. Could be that the suspend backup code ends up waiting for something before we end up in intel_gt_wait_for_idle, giving more requests time to execute. No idea, I don't know the suspend paths that well. For instance before looking at the code I thought we would preempt what's executing and not wait for everything that has been submitted to finish. :) Anyway, if that turns out to be correct then perhaps it would be better to split the two timeouts (like if required GuC timeout is perhaps fundamentally independent) so it's clear who needs how much time. Adding Matt and John to comment. You mean we have separate timeouts depending on whether we're using GuC or execlists submission? No, I don't know yet. First I think we need to figure out what exactly is happening. Well then TBH I will need to file a separate Jira about that. There might be various things going on here like swiching between the migrate context for eviction of unrelated LMEM buffers and the context used by gem_exec_suspend. The gem_exec_suspend failures are blocking DG1 BAT so it's pretty urgent to get this series merged. If you insist I can leave this patch out for now, but rather I'd commit it as is and File a Jira instead. I see now how you have i915_gem_suspend() in between two lmem_suspend() calls in this series. So first call has the potential of creating a lot of requests and that you think interferes? Sounds plausible but implies GuC timeslicing is less efficient if I follow? IMO it is okay to leave for follow up work but strictly speaking, unless I am missing something, the approach of bumping the timeout does not sound valid if the copying is done async. Because the timeout is then mandated not only as function of GPU activity (lets say user controlled), but also the amount of unpinned/idle buffers which happen to be laying around (which is more i915 controlled, or mixed at least). So question is, with enough data to copy, any timeout could be too low and then how long do we want to wait before failing suspend? Is this an argument to have a separate timeout specifically addressing the suspend path or not I am not sure. Perhaps there is no choice and simply wait until buffers are swapped out otherwise nothing will work. Regards, Tvrtko
Re: [PATCH] drm/ttm: Don't delete the system manager before the delayed delete
On 9/20/21 10:59 AM, Zack Rusin wrote: On Sep 20, 2021, at 02:30, Christian König wrote: Am 17.09.21 um 19:53 schrieb Zack Rusin: On some hardware, in particular in virtualized environments, the system memory can be shared with the "hardware". In those cases the BO's allocated through the ttm system manager might be busy during ttm_bo_put which results in them being scheduled for a delayed deletion. While the patch itself is probably fine the reasoning here is a clear NAK. Buffers in the system domain are not GPU accessible by definition, even in a shared environment and so *must* be idle. I’m assuming that means they are not allowed to be ever fenced then, yes? Any thoughts on this? I'd love a confirmation because it would mean I need to go and rewrite the vmwgfx_mob.c bits where we use TTM_PL_SYSTEM memory (through vmw_bo_create_and_populate) for a page table which is read by the host, and those bo's need to be fenced to prevent destruction of the page tables while the memory they point to is still used. So if those were never allowed to be fenced in the first place we probably need to add a new memory type to hold those page tables. z
Re: [PATCH RESEND] drm/i915: Flush buffer pools on driver remove
On Thu, Sep 23, 2021 at 03:07:06PM +0200, Janusz Krzysztofik wrote: > Hi Matt, > > Thanks for review. > > On czwartek, 23 września 2021 00:24:29 CEST Matt Roper wrote: > > On Fri, Sep 03, 2021 at 04:23:20PM +0200, Janusz Krzysztofik wrote: > > > In preparation for clean driver release, attempts to drain work queues > > > and release freed objects are taken at driver remove time. However, GT > > > buffer pools are now not flushed before the driver release phase. > > > Since unused objects may stay there for up to one second, some may > > > survive until driver release is attempted. That can potentially > > > explain sporadic then hardly reproducible issues observed at driver > > > release time, like non-zero shrink counter or outstanding address space > > > > So just to make sure I'm understanding the description here: > > - We currently do an explicit flush of the buffer pools within the call > >path of drm_driver.release(); this removes all buffers, regardless of > >their age. > > And also triggers release of the buffers' underlying resources (objects, > address space areas). > > > - However there may be other code that runs *earlier* within the > >drm_driver.release() call chain > > Yes, within the drm_driver.release() call chain, but not necessarily earlier > -- that's irrelevant, I believe, ... > > >that expects buffer pools have > >already been flushed and are already empty. > > ... since that other code expects not just buffer pools but resource > categories they consume (objects, address space areas) to be flushed already, > while some may still be busy with old buffers not auto-flushed yet. > > > - Since buffer pools auto-flush old buffers once per second in a worker > >thread, there's a small window where if we remove the driver while > >there are still buffers with an age of less than one second, the > >assumptions of the other release code may be violated. > > Correct. > > > So by moving the flush to driver remove (which executes earlier via the > > pci_driver.remove() flow) you're ensuring that all buffers are flushed > > before _any_ code in drm_driver.release() executes. > > And also flushed before some other code in pci_driver.remove() flushes those > other resource categories released on buffer pools flush, then completeness > of > all those flushes is checked in drm_driver.release(). > > May I copy-paste some of you wording while rephrasing my commit description? Sure go ahead. Thanks. Matt > > Thanks, > Janusz > > > > > I found the wording of the commit message here somewhat confusing since > > it's talking about flushes we do in driver release, but mentions > > problems that arise during driver release due to lack of flushing. You > > might want to reword the commit message somewhat to help clarify. > > Otherwise, the code change itself looks reasonable to me. > > > > BTW, I do notice that drm_driver.release() in general is technically > > deprecated at this point (with a suggestion in the drm_drv.h comments to > > switch to using drmm_add_action(), drmm_kmalloc(), etc. to manage the > > cleanup of resources). At some point in the future me may want to > > rework the i915 cleanup in general according to that guidance. > > > > > > Matt > > > > > areas. > > > > > > Flush buffer pools on GT remove as a fix. On driver release, don't > > > flush the pools again, just assert that the flush was called and > > > nothing added more in between. > > > > > > Signed-off-by: Janusz Krzysztofik > > > Cc: Chris Wilson > > > --- > > > Resending with Cc: dri-devel@lists.freedesktop.org as requested, and a > > > typo in commit description fixed. > > > > > > Thanks, > > > Janusz > > > > > > drivers/gpu/drm/i915/gt/intel_gt.c | 2 ++ > > > drivers/gpu/drm/i915/gt/intel_gt_buffer_pool.c | 2 -- > > > 2 files changed, 2 insertions(+), 2 deletions(-) > > > > > > diff --git a/drivers/gpu/drm/i915/gt/intel_gt.c > > > b/drivers/gpu/drm/i915/gt/intel_gt.c > > > index 62d40c986642..8f322a4ecd87 100644 > > > --- a/drivers/gpu/drm/i915/gt/intel_gt.c > > > +++ b/drivers/gpu/drm/i915/gt/intel_gt.c > > > @@ -737,6 +737,8 @@ void intel_gt_driver_remove(struct intel_gt *gt) > > > intel_uc_driver_remove(>->uc); > > > > > > intel_engines_release(gt); > > > + > > > + intel_gt_flush_buffer_pool(gt); > > > } > > > > > > void intel_gt_driver_unregister(struct intel_gt *gt) > > > diff --git a/drivers/gpu/drm/i915/gt/intel_gt_buffer_pool.c > > > b/drivers/gpu/drm/i915/gt/intel_gt_buffer_pool.c > > > index aa0a59c5b614..acc49c56a9f3 100644 > > > --- a/drivers/gpu/drm/i915/gt/intel_gt_buffer_pool.c > > > +++ b/drivers/gpu/drm/i915/gt/intel_gt_buffer_pool.c > > > @@ -245,8 +245,6 @@ void intel_gt_fini_buffer_pool(struct intel_gt *gt) > > > struct intel_gt_buffer_pool *pool = >->buffer_pool; > > > int n; > > > > > > - intel_gt_flush_buffer_pool(gt); > > > - > > > for (n = 0; n < ARRAY_SIZE(pool->cache_list); n++) > > >
Re: [PATCH v2] backlight: propagate errors from get_brightness()
On Thu, 23 Sep 2021, Thomas Weißschuh wrote: > On 2021-09-23T10:48+0100, Lee Jones wrote: > > On Tue, 07 Sep 2021, Thomas Weißschuh wrote: > > > > > backlight.h documents "struct backlight_ops->get_brightness()" to return > > > a negative errno on failure. > > > So far these errors have not been handled in the backlight core. > > > This leads to negative values being exposed through sysfs although only > > > positive values are documented to be reported. > > > > > > Signed-off-by: Thomas Weißschuh > > > --- > > > > > > v1: > > > https://lore.kernel.org/dri-devel/20210906215525.15418-1-li...@weissschuh.net/ > > > > > > v1 -> v2: > > > * use dev_err() instead of dev_warn() (Daniel Thompson) > > > * Finish logging format string with newline (Daniel Thompson) > > > * Log errno via dedicated error pointer format (Daniel Thompson) > > > > > > drivers/video/backlight/backlight.c | 22 +- > > > 1 file changed, 17 insertions(+), 5 deletions(-) > > > > Applied, thanks. > > Hi Lee, > > thanks! > > Also I'm sorry about my nagging before. No worries. > I was not aware you were on vacation and saw you respond to other mails. They were in the queue before this one. I had hundreds of emails to get through on my return! -- Lee Jones [李琼斯] Senior Technical Lead - Developer Services Linaro.org │ Open source software for Arm SoCs Follow Linaro: Facebook | Twitter | Blog
Re: [RFC PATCH v3 1/6] drm/doc: Color Management and HDR10 RFC
On 2021-09-23 04:01, Pekka Paalanen wrote: > On Wed, 22 Sep 2021 11:06:53 -0400 > Harry Wentland wrote: > >> On 2021-09-20 20:14, Harry Wentland wrote: >>> On 2021-09-15 10:01, Pekka Paalanen wrote:> On Fri, 30 Jul 2021 16:41:29 >>> -0400 Harry Wentland wrote: >> >> >> > +If a display's maximum HDR white level is correctly reported it is > trivial > +to convert between all of the above representations of SDR white level. > If > +it is not, defining SDR luminance as a nits value, or a ratio vs a fixed > +nits value is preferred, assuming we are blending in linear space. > + > +It is our experience that many HDR displays do not report maximum white > +level correctly Which value do you refer to as "maximum white", and how did you measure it? >>> Good question. I haven't played with those displays myself but I'll try to >>> find out a bit more background behind this statement. >>> >> >> >> Some TVs report the EOTF but not the luminance values. >> For an example edid-code capture of my eDP HDR panel: >> >> HDR Static Metadata Data Block: >> Electro optical transfer functions: >> Traditional gamma - SDR luminance range >> SMPTE ST2084 >> Supported static metadata descriptors: >> Static metadata type 1 >> Desired content max luminance: 115 (603.666 cd/m^2) >> Desired content max frame-average luminance: 109 (530.095 cd/m^2) >> Desired content min luminance: 7 (0.005 cd/m^2) >> > > I forget where I heard (you, Vitaly, someone?) that integrated panels > may not have the magic gamut and tone mapping hardware, which means > that software (or display engine) must do the full correct thing. > > That's another reason to not rely on magic display functionality, which > suits my plans perfectly. > I've mentioned it before but there aren't really a lot of integrated HDR panels yet. I think we've only seen one or two without tone-mapping ability. Either way we probably need at least the ability to tone-map the output on the transmitter side (SW, GPU, or display HW). >> I suspect on those TVs it looks like this: >> >> HDR Static Metadata Data Block: >> Electro optical transfer functions: >> Traditional gamma - SDR luminance range >> SMPTE ST2084 >> Supported static metadata descriptors: >> Static metadata type 1 >> >> Windows has some defaults in this case and our Windows driver also has >> some defaults. > > Oh, missing information. Yay. > >> Using defaults in the 1000-2000 nits range would yield much better >> tone-mapping results than assuming the monitor can support a full >> 10k nits. > > Obviously. > >> As an aside, recently we've come across displays where the max >> average luminance is higher than the max peak luminance. This is >> not a mistake but due to how the display's dimming zones work. > > IOW, the actual max peak luminance in absolute units depends on the > current image average luminance. Wonderful, but what am I (the content > producer, the display server) supposed to do with that information... > >> Not sure what impact this might have on tone-mapping, other than >> to keep in mind that we can assume that max_avg < max_peak. > > *cannot > Right > Seems like it would lead to a very different tone mapping algorithm > which needs to compute the image average luminance before it can > account for max peak luminance (which I wouldn't know how to infer). So > either a two-pass algorithm, or taking the average from the previous > frame. > > I imagine that is going to be fun considering one needs to composite > different types of input images together, and the final tone mapping > might need to differ for each. Strictly thinking that might lead to an > iterative optimisation algorithm which would be quite intractable in > practise to complete for a single frame at a time. > Maybe a good approach for this would be to just consider MaxAvg = MaxPeak in this case. At least until one would want to consider dynamic tone-mapping, i.e. tone-mapping that is changing frame-by-frame based on content. Dynamic tone-mapping might be challenging to do in SW but could be a possibility with specialized HW. Though I'm not sure exactly how that HW would look like. Maybe something like a histogram engine like Laurent mentions in https://lists.freedesktop.org/archives/dri-devel/2021-June/311689.html. Harry > > Thanks, > pq >
Re: Multiple DRI card detection in compositor systemd units
On Wed, 22 Sep 2021 16:16:48 + "Hoosier, Matt" wrote: > > The /dev/dri/by-path idea works, I suppose, if you have different > physical graphics cards. In my case, that's not true. These are > virtualized cards that the silicon vendor's DRM drivers use to expose > different subsets of DRM resources as different cards. So there's > only one /dev/dri/by-path card here. Think: DRM leases, but with the > lessees popping out as card nodes rather than arranged dynamically > using the drm ioctl()'s to manufature leases. That's the standard solution though, I believe: use devpath for matching the device, because the device doesn't randomly jump from a physical connector (e.g. PCIe slot) to another. But since you have virtual cards, that obviously doesn't work. I'm afraid you need to solve this with your virtual card provider. Maybe there could be some sort of virtual bus with persistent addresses which would make devpath reliable? I wouldn't expect drmGetVersion()->name to differ between the (virtual) devices since they are all using the same driver, right? Sorry, pq > The use-case here is to allow separate DRM domains for each of > several containers. It's not really desirable to try to funnel > everybody's graphics through a common compositor that runs all the > connectors. > pgpx6a2vXcO8_.pgp Description: OpenPGP digital signature
Re: [PATCH v3 6/6] drm/ingenic: Attach bridge chain to encoders
Hi Nikolaus, Le jeu., sept. 23 2021 at 13:41:28 +0200, H. Nikolaus Schaller a écrit : Hi Laurent, Am 23.09.2021 um 12:03 schrieb Laurent Pinchart : Hi Nikolaus, On Thu, Sep 23, 2021 at 11:55:56AM +0200, H. Nikolaus Schaller wrote: Am 23.09.2021 um 11:27 schrieb Laurent Pinchart: On Thu, Sep 23, 2021 at 11:19:23AM +0200, H. Nikolaus Schaller wrote: + ret = drm_bridge_attach(encoder, &ib->bridge, NULL, + DRM_BRIDGE_ATTACH_NO_CONNECTOR); DRM_BRIDGE_ATTACH_NO_CONNECTOR makes it fundamentally incompatible with synopsys/dw_hdmi.c That driver checks for DRM_BRIDGE_ATTACH_NO_CONNECTOR being NOT present, since it wants to register its own connector through dw_hdmi_connector_create(). It does it for a reason: the dw-hdmi is a multi-function driver which does HDMI and DDC/EDID stuff in a single driver (because I/O registers and power management seem to be shared). The IT66121 driver does all of that too, and does not need DRM_BRIDGE_ATTACH_NO_CONNECTOR. The drm_bridge_funcs struct has callbacks to handle cable detection and DDC stuff. Since I do not see who could split this into a separate bridge and a connector driver and test it on multiple SoC platforms (there are at least 3 or 4), I think modifying the fundamentals of the dw-hdmi architecture just to get CI20 HDMI working is not our turf. You could have a field in the dw-hdmi pdata structure, that would instruct the driver whether or not it should use the new API. Ugly, I know, and would probably duplicate a lot of code, but that would allow other drivers to be updated at a later date. Yes, would be very ugly. But generally who has the knowledge (and time) to do this work? And has a working platform to test (jz4780 isn't a good development environment)? The driver seems to have a turbulent history starting 2013 in staging/imx and apparently it was generalized since then... Is Laurent currently dw-hdmi maintainer? "Maintainer" would be an overstatement. I've worked on that driver in the past, and I still use it, but don't have time to really maintain it. I've also been told that Synopsys required all patches for that driver developed using documentation under NDA to be submitted internally to them first before being published, so I decided to stop contributing instead of agreeing with this insane process. There's public documentation about the IP in some NXP reference manuals though, so it should be possible to still move forward without abiding by this rule. Therefore the code here should be able to detect if drm_bridge_attach() already creates and attaches a connector and then skip the code below. Not that easy, unfortunately. On one side we have dw-hdmi which checks that DRM_BRIDGE_ATTACH_NO_CONNECTOR is not set, and on the other side we have other drivers like the IT66121 which will fail if this flag is not set. Ok, I see. You have to handle contradicting cases here. Would it be possible to run it with DRM_BRIDGE_ATTACH_NO_CONNECTOR first and retry if it fails without? But IMHO the return value (in error case) is not well defined. So there must be a test if a connector has been created (I do not know how this would work). Another suggestion: can you check if there is a downstream connector defined in device tree (dw-hdmi does not need such a definition)? If not we call it with 0 and if there is one we call it with DRM_BRIDGE_ATTACH_NO_CONNECTOR and create one? I haven't followed the ful conversation, what the reason why DRM_BRIDGE_ATTACH_NO_CONNECTOR can't always be use here ? The synopsys driver creates its own connector through dw_hdmi_connector_create() because the IP handles DDC/EDID directly. That doesn't require creating a connector though. The driver implements drm_bridge_funcs.get_edid(), which is used to get the EDID without the need to create a connector in the dw-hdmi driver. Ah, ok. But then we still have issues. Firstly I would assume that get_edid only works properly if it is initialized through dw_hdmi_connector_create(). Next, in the current code, passing DRM_BRIDGE_ATTACH_NO_CONNECTOR to dw_hdmi_bridge_attach() indeed does not call dw_hdmi_connector_create() but returns 0. This patch 6/6 makes drm/ingenic unconditionally require a connector to be attached which is defined somewhere else (device tree e.g. "connector-hdmi") unrelated to dw-hdmi. Current upstream code for drm/ingenic does not init/attach such a connector on its own so it did work before. I.e. I think we can't just use parts of dw-hdmi. The fact that Laurent is using dw-hdmi with DRM_BRIDGE_ATTACH_NO_CONNECTOR on Renesas makes me think that it's possible here as well. There's no reason why it shouldn't work with ingenic-drm. The ingenic-drm driver does not need to create any connector. The "connector-hdmi" is connected to dw-hdmi as the "next bridge" in the list.
Re: [Intel-gfx] [PATCH v6 3/9] drm/i915/gt: Increase suspend timeout
On 9/23/21 2:59 PM, Tvrtko Ursulin wrote: On 23/09/2021 12:47, Thomas Hellström wrote: Hi, Tvrtko, On 9/23/21 12:13 PM, Tvrtko Ursulin wrote: On 22/09/2021 07:25, Thomas Hellström wrote: With GuC submission on DG1, the execution of the requests times out for the gem_exec_suspend igt test case after executing around 800-900 of 1000 submitted requests. Given the time we allow elsewhere for fences to signal (in the order of seconds), increase the timeout before we mark the gt wedged and proceed. I suspect it is not about requests not retiring in time but about the intel_guc_wait_for_idle part of intel_gt_wait_for_idle. Although I don't know which G2H message is the code waiting for at suspend time so perhaps something to run past the GuC experts. So what's happening here is that the tests submits 1000 requests, each writing a value to an object, and then that object content is checked after resume. With GuC it turns out that only 800-900 or so values are actually written before we time out, and the test (basic-S3) fails, but not on every run. Yes and that did not make sense to me. It is a single context even so I did not come up with an explanation why would GuC be slower. Unless it somehow manages to not even update the ring tail in time and requests are still only stuck in the software queue? Perhaps you can see that from context tail and head when it happens. This is a bit interesting in itself, because I never saw the hang-S3 test fail, which from what I can tell basically is an identical test but with a spinner submitted after the 1000th request. Could be that the suspend backup code ends up waiting for something before we end up in intel_gt_wait_for_idle, giving more requests time to execute. No idea, I don't know the suspend paths that well. For instance before looking at the code I thought we would preempt what's executing and not wait for everything that has been submitted to finish. :) Anyway, if that turns out to be correct then perhaps it would be better to split the two timeouts (like if required GuC timeout is perhaps fundamentally independent) so it's clear who needs how much time. Adding Matt and John to comment. You mean we have separate timeouts depending on whether we're using GuC or execlists submission? No, I don't know yet. First I think we need to figure out what exactly is happening. Well then TBH I will need to file a separate Jira about that. There might be various things going on here like swiching between the migrate context for eviction of unrelated LMEM buffers and the context used by gem_exec_suspend. The gem_exec_suspend failures are blocking DG1 BAT so it's pretty urgent to get this series merged. If you insist I can leave this patch out for now, but rather I'd commit it as is and File a Jira instead. /Thomas
Re: [PATCH RESEND] drm/i915: Flush buffer pools on driver remove
Hi Matt, Thanks for review. On czwartek, 23 września 2021 00:24:29 CEST Matt Roper wrote: > On Fri, Sep 03, 2021 at 04:23:20PM +0200, Janusz Krzysztofik wrote: > > In preparation for clean driver release, attempts to drain work queues > > and release freed objects are taken at driver remove time. However, GT > > buffer pools are now not flushed before the driver release phase. > > Since unused objects may stay there for up to one second, some may > > survive until driver release is attempted. That can potentially > > explain sporadic then hardly reproducible issues observed at driver > > release time, like non-zero shrink counter or outstanding address space > > So just to make sure I'm understanding the description here: > - We currently do an explicit flush of the buffer pools within the call >path of drm_driver.release(); this removes all buffers, regardless of >their age. And also triggers release of the buffers' underlying resources (objects, address space areas). > - However there may be other code that runs *earlier* within the >drm_driver.release() call chain Yes, within the drm_driver.release() call chain, but not necessarily earlier -- that's irrelevant, I believe, ... >that expects buffer pools have >already been flushed and are already empty. ... since that other code expects not just buffer pools but resource categories they consume (objects, address space areas) to be flushed already, while some may still be busy with old buffers not auto-flushed yet. > - Since buffer pools auto-flush old buffers once per second in a worker >thread, there's a small window where if we remove the driver while >there are still buffers with an age of less than one second, the >assumptions of the other release code may be violated. Correct. > So by moving the flush to driver remove (which executes earlier via the > pci_driver.remove() flow) you're ensuring that all buffers are flushed > before _any_ code in drm_driver.release() executes. And also flushed before some other code in pci_driver.remove() flushes those other resource categories released on buffer pools flush, then completeness of all those flushes is checked in drm_driver.release(). May I copy-paste some of you wording while rephrasing my commit description? Thanks, Janusz > > I found the wording of the commit message here somewhat confusing since > it's talking about flushes we do in driver release, but mentions > problems that arise during driver release due to lack of flushing. You > might want to reword the commit message somewhat to help clarify. > Otherwise, the code change itself looks reasonable to me. > > BTW, I do notice that drm_driver.release() in general is technically > deprecated at this point (with a suggestion in the drm_drv.h comments to > switch to using drmm_add_action(), drmm_kmalloc(), etc. to manage the > cleanup of resources). At some point in the future me may want to > rework the i915 cleanup in general according to that guidance. > > > Matt > > > areas. > > > > Flush buffer pools on GT remove as a fix. On driver release, don't > > flush the pools again, just assert that the flush was called and > > nothing added more in between. > > > > Signed-off-by: Janusz Krzysztofik > > Cc: Chris Wilson > > --- > > Resending with Cc: dri-devel@lists.freedesktop.org as requested, and a > > typo in commit description fixed. > > > > Thanks, > > Janusz > > > > drivers/gpu/drm/i915/gt/intel_gt.c | 2 ++ > > drivers/gpu/drm/i915/gt/intel_gt_buffer_pool.c | 2 -- > > 2 files changed, 2 insertions(+), 2 deletions(-) > > > > diff --git a/drivers/gpu/drm/i915/gt/intel_gt.c > > b/drivers/gpu/drm/i915/gt/intel_gt.c > > index 62d40c986642..8f322a4ecd87 100644 > > --- a/drivers/gpu/drm/i915/gt/intel_gt.c > > +++ b/drivers/gpu/drm/i915/gt/intel_gt.c > > @@ -737,6 +737,8 @@ void intel_gt_driver_remove(struct intel_gt *gt) > > intel_uc_driver_remove(>->uc); > > > > intel_engines_release(gt); > > + > > + intel_gt_flush_buffer_pool(gt); > > } > > > > void intel_gt_driver_unregister(struct intel_gt *gt) > > diff --git a/drivers/gpu/drm/i915/gt/intel_gt_buffer_pool.c > > b/drivers/gpu/drm/i915/gt/intel_gt_buffer_pool.c > > index aa0a59c5b614..acc49c56a9f3 100644 > > --- a/drivers/gpu/drm/i915/gt/intel_gt_buffer_pool.c > > +++ b/drivers/gpu/drm/i915/gt/intel_gt_buffer_pool.c > > @@ -245,8 +245,6 @@ void intel_gt_fini_buffer_pool(struct intel_gt *gt) > > struct intel_gt_buffer_pool *pool = >->buffer_pool; > > int n; > > > > - intel_gt_flush_buffer_pool(gt); > > - > > for (n = 0; n < ARRAY_SIZE(pool->cache_list); n++) > > GEM_BUG_ON(!list_empty(&pool->cache_list[n])); > > } > >
[PATCH v3.1] dt-bindings: display: renesas, du: Provide bindings for r8a779a0
From: Kieran Bingham Extend the Renesas DU display bindings to support the r8a779a0 V3U. Reviewed-by: Laurent Pinchart Reviewed-by: Geert Uytterhoeven Signed-off-by: Kieran Bingham --- v2: - Collected Laurent's tag - Remove clock-names requirement - Specify only a single clock v3: - Use clocknames: 'du.0' instead of 'du' to remain consistent v3.1: - Require clock-names - Collect Geert's tag .../bindings/display/renesas,du.yaml | 51 +++ 1 file changed, 51 insertions(+) diff --git a/Documentation/devicetree/bindings/display/renesas,du.yaml b/Documentation/devicetree/bindings/display/renesas,du.yaml index e3ca5389c17d..13efea574584 100644 --- a/Documentation/devicetree/bindings/display/renesas,du.yaml +++ b/Documentation/devicetree/bindings/display/renesas,du.yaml @@ -39,6 +39,7 @@ properties: - renesas,du-r8a77980 # for R-Car V3H compatible DU - renesas,du-r8a77990 # for R-Car E3 compatible DU - renesas,du-r8a77995 # for R-Car D3 compatible DU + - renesas,du-r8a779a0 # for R-Car V3U compatible DU reg: maxItems: 1 @@ -773,6 +774,56 @@ allOf: - reset-names - renesas,vsps + - if: + properties: +compatible: + contains: +enum: + - renesas,du-r8a779a0 +then: + properties: +clocks: + items: +- description: Functional clock + +clock-names: + maxItems: 1 + items: +- const: du.0 + +interrupts: + maxItems: 2 + +resets: + maxItems: 1 + +reset-names: + items: +- const: du.0 + +ports: + properties: +port@0: + description: DSI 0 +port@1: + description: DSI 1 +port@2: false +port@3: false + + required: +- port@0 +- port@1 + +renesas,vsps: + minItems: 2 + + required: +- clock-names +- interrupts +- resets +- reset-names +- renesas,vsps + additionalProperties: false examples: -- 2.30.2
Re: [Intel-gfx] [PATCH v6 3/9] drm/i915/gt: Increase suspend timeout
On 23/09/2021 12:47, Thomas Hellström wrote:
Hi, Tvrtko,
On 9/23/21 12:13 PM, Tvrtko Ursulin wrote:
On 22/09/2021 07:25, Thomas Hellström wrote:
With GuC submission on DG1, the execution of the requests times out
for the gem_exec_suspend igt test case after executing around 800-900
of 1000 submitted requests.
Given the time we allow elsewhere for fences to signal (in the order of
seconds), increase the timeout before we mark the gt wedged and proceed.
I suspect it is not about requests not retiring in time but about the
intel_guc_wait_for_idle part of intel_gt_wait_for_idle. Although I
don't know which G2H message is the code waiting for at suspend time
so perhaps something to run past the GuC experts.
So what's happening here is that the tests submits 1000 requests, each
writing a value to an object, and then that object content is checked
after resume. With GuC it turns out that only 800-900 or so values are
actually written before we time out, and the test (basic-S3) fails, but
not on every run.
Yes and that did not make sense to me. It is a single context even so I
did not come up with an explanation why would GuC be slower.
Unless it somehow manages to not even update the ring tail in time and
requests are still only stuck in the software queue? Perhaps you can see
that from context tail and head when it happens.
This is a bit interesting in itself, because I never saw the hang-S3
test fail, which from what I can tell basically is an identical test but
with a spinner submitted after the 1000th request. Could be that the
suspend backup code ends up waiting for something before we end up in
intel_gt_wait_for_idle, giving more requests time to execute.
No idea, I don't know the suspend paths that well. For instance before
looking at the code I thought we would preempt what's executing and not
wait for everything that has been submitted to finish. :)
Anyway, if that turns out to be correct then perhaps it would be
better to split the two timeouts (like if required GuC timeout is
perhaps fundamentally independent) so it's clear who needs how much
time. Adding Matt and John to comment.
You mean we have separate timeouts depending on whether we're using GuC
or execlists submission?
No, I don't know yet. First I think we need to figure out what exactly
is happening.
To be clear, as timeout is AFAIK an arbitrary value, I don't have
fundamental objections here. Just think it would be good to have
accurate story in the commit message.
Ok. yes. I wonder whether we actually should increase this timeout even
more since now the watchdog times out after 10+ seconds? I guess those
long-running requests could be executing also at suspend time.
We probably should not just increase it hugely. Because watchdog is a
separate story since it applies to unsubmited and unready requests and
suspend can happen fine with those around I think.
Regards,
Tvrtko
/Thomas
Regards,
Tvrtko
Signed-off-by: Thomas Hellström
---
drivers/gpu/drm/i915/gt/intel_gt_pm.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/gt/intel_gt_pm.c
b/drivers/gpu/drm/i915/gt/intel_gt_pm.c
index dea8e2479897..f84f2bfe2de0 100644
--- a/drivers/gpu/drm/i915/gt/intel_gt_pm.c
+++ b/drivers/gpu/drm/i915/gt/intel_gt_pm.c
@@ -19,6 +19,8 @@
#include "intel_rps.h"
#include "intel_wakeref.h"
+#define I915_GT_SUSPEND_IDLE_TIMEOUT (HZ / 2)
+
static void user_forcewake(struct intel_gt *gt, bool suspend)
{
int count = atomic_read(>->user_wakeref);
@@ -279,7 +281,7 @@ static void wait_for_suspend(struct intel_gt *gt)
if (!intel_gt_pm_is_awake(gt))
return;
- if (intel_gt_wait_for_idle(gt, I915_GEM_IDLE_TIMEOUT) ==
-ETIME) {
+ if (intel_gt_wait_for_idle(gt, I915_GT_SUSPEND_IDLE_TIMEOUT) ==
-ETIME) {
/*
* Forcibly cancel outstanding work and leave
* the gpu quiet.
Re: [PATCH] drm/amd/display: Fix randomly flicking on overlay with enabled ABM
On Thu, Sep 23, 2021 at 5:03 AM wrote: > > From: "Yipeng Chen (Jasber)" > > [Why] > Enabled ABM (level != 0) would raise short pluse irq DC_IRQ_SOURCE_HPD1RX > randomly with PSR error LINK_CRC_ERROR. Actually there is no hot plugging > on EDP panel. After correcting CRC error, there is no need to send drm > hotplug event. > > [How] > Returning false would skip doing hot-plug when handle_hpd_irq_psr_sink() > handled irq. Hot-plug process causes visible flicking on overlay. > > Signed-off-by: Yipeng Chen (Jasber) > Reviewed-by: Roman Li > Anthony Koo Each reviewer should be called out on a separate line E.g., Reviewed-by: Roman Li Reviewed-by: Anthony Koo > --- > drivers/gpu/drm/amd/display/dc/core/dc_link_dp.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/drivers/gpu/drm/amd/display/dc/core/dc_link_dp.c > b/drivers/gpu/drm/amd/display/dc/core/dc_link_dp.c > index 1e4794e2825c..9b9fbe5e9bd4 100644 > --- a/drivers/gpu/drm/amd/display/dc/core/dc_link_dp.c > +++ b/drivers/gpu/drm/amd/display/dc/core/dc_link_dp.c > @@ -3007,7 +3007,7 @@ bool dc_link_handle_hpd_rx_irq(struct dc_link *link, > union hpd_irq_data *out_hpd > > if (handle_hpd_irq_psr_sink(link)) > /* PSR-related error was detected and handled */ > - return true; > + return false; > > /* If PSR-related error handled, Main link may be off, > * so do not handle as a normal sink status change interrupt. > -- > 2.25.1 >
Re: [PATCH v3 6/6] drm/ingenic: Attach bridge chain to encoders
Hi Laurent,
> IMHO it is leaving (mature) dw-hdmi untouched and make attachment of a
> connector
> in ingenic_drm_bind() depend on some condition.
Since I don't know details of the DRM bridge/encoder/connector APIs),
let me reformulate the quersion for a condition specifically.
How can one find out in this code fragment from Paul's patch
if drm_brige_attach() did create a connector or not?
I.e. did call drm_connector_attach_encoder(connector, hdmi->bridge.encoder);
on its own?
@@ -1154,20 +1186,36 @@ static int ingenic_drm_bind(struct device *dev, bool
has_components)
bridge = devm_drm_panel_bridge_add_typed(dev, panel,
DRM_MODE_CONNECTOR_DPI);
drm_encoder_helper_add(encoder,
&ingenic_drm_encoder_helper_funcs);
- ret = drm_bridge_attach(encoder, bridge, NULL, 0);
- if (ret)
+ ib->bridge.funcs = &ingenic_drm_bridge_funcs;
+ ib->next_bridge = bridge;
+
+ ret = drm_bridge_attach(encoder, &ib->bridge, NULL,
+ DRM_BRIDGE_ATTACH_NO_CONNECTOR);
+ if (ret) {
+ dev_err(dev, "Unable to attach bridge\n");
return ret;
+ }
+
+ connector = drm_bridge_connector_init(drm, encoder);
+ if (IS_ERR(connector)) {
+ dev_err(dev, "Unable to init connector\n");
+ return PTR_ERR(connector);
+ }
+
+ drm_connector_attach_encoder(connector, encoder);
}
A problem may be that "connector" is unknown before drm_bridge_connector_init()
is called.
Then I think I can propose a fallback solution to drm_bridge_attach(, 0) if
drm_bridge_attach(, DRM_BRIDGE_ATTACH_NO_CONNECTOR) fails.
BR and thanks,
Nikolaus
Re: [Intel-gfx] [PATCH v6 3/9] drm/i915/gt: Increase suspend timeout
Hi, Tvrtko,
On 9/23/21 12:13 PM, Tvrtko Ursulin wrote:
On 22/09/2021 07:25, Thomas Hellström wrote:
With GuC submission on DG1, the execution of the requests times out
for the gem_exec_suspend igt test case after executing around 800-900
of 1000 submitted requests.
Given the time we allow elsewhere for fences to signal (in the order of
seconds), increase the timeout before we mark the gt wedged and proceed.
I suspect it is not about requests not retiring in time but about the
intel_guc_wait_for_idle part of intel_gt_wait_for_idle. Although I
don't know which G2H message is the code waiting for at suspend time
so perhaps something to run past the GuC experts.
So what's happening here is that the tests submits 1000 requests, each
writing a value to an object, and then that object content is checked
after resume. With GuC it turns out that only 800-900 or so values are
actually written before we time out, and the test (basic-S3) fails, but
not on every run.
This is a bit interesting in itself, because I never saw the hang-S3
test fail, which from what I can tell basically is an identical test but
with a spinner submitted after the 1000th request. Could be that the
suspend backup code ends up waiting for something before we end up in
intel_gt_wait_for_idle, giving more requests time to execute.
Anyway, if that turns out to be correct then perhaps it would be
better to split the two timeouts (like if required GuC timeout is
perhaps fundamentally independent) so it's clear who needs how much
time. Adding Matt and John to comment.
You mean we have separate timeouts depending on whether we're using GuC
or execlists submission?
To be clear, as timeout is AFAIK an arbitrary value, I don't have
fundamental objections here. Just think it would be good to have
accurate story in the commit message.
Ok. yes. I wonder whether we actually should increase this timeout even
more since now the watchdog times out after 10+ seconds? I guess those
long-running requests could be executing also at suspend time.
/Thomas
Regards,
Tvrtko
Signed-off-by: Thomas Hellström
---
drivers/gpu/drm/i915/gt/intel_gt_pm.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/gt/intel_gt_pm.c
b/drivers/gpu/drm/i915/gt/intel_gt_pm.c
index dea8e2479897..f84f2bfe2de0 100644
--- a/drivers/gpu/drm/i915/gt/intel_gt_pm.c
+++ b/drivers/gpu/drm/i915/gt/intel_gt_pm.c
@@ -19,6 +19,8 @@
#include "intel_rps.h"
#include "intel_wakeref.h"
+#define I915_GT_SUSPEND_IDLE_TIMEOUT (HZ / 2)
+
static void user_forcewake(struct intel_gt *gt, bool suspend)
{
int count = atomic_read(>->user_wakeref);
@@ -279,7 +281,7 @@ static void wait_for_suspend(struct intel_gt *gt)
if (!intel_gt_pm_is_awake(gt))
return;
- if (intel_gt_wait_for_idle(gt, I915_GEM_IDLE_TIMEOUT) ==
-ETIME) {
+ if (intel_gt_wait_for_idle(gt, I915_GT_SUSPEND_IDLE_TIMEOUT) ==
-ETIME) {
/*
* Forcibly cancel outstanding work and leave
* the gpu quiet.
Re: [PATCH v3 6/6] drm/ingenic: Attach bridge chain to encoders
Hi Laurent, > Am 23.09.2021 um 12:03 schrieb Laurent Pinchart > : > > Hi Nikolaus, > > On Thu, Sep 23, 2021 at 11:55:56AM +0200, H. Nikolaus Schaller wrote: >>> Am 23.09.2021 um 11:27 schrieb Laurent Pinchart: >>> On Thu, Sep 23, 2021 at 11:19:23AM +0200, H. Nikolaus Schaller wrote: >>> + ret = drm_bridge_attach(encoder, &ib->bridge, NULL, >>> + DRM_BRIDGE_ATTACH_NO_CONNECTOR); >> >> DRM_BRIDGE_ATTACH_NO_CONNECTOR makes it fundamentally incompatible >> with synopsys/dw_hdmi.c >> That driver checks for DRM_BRIDGE_ATTACH_NO_CONNECTOR being NOT present, >> since it wants to register its own connector through >> dw_hdmi_connector_create(). >> It does it for a reason: the dw-hdmi is a multi-function driver which >> does >> HDMI and DDC/EDID stuff in a single driver (because I/O registers and >> power >> management seem to be shared). > > The IT66121 driver does all of that too, and does not need > DRM_BRIDGE_ATTACH_NO_CONNECTOR. The drm_bridge_funcs struct has > callbacks to handle cable detection and DDC stuff. > >> Since I do not see who could split this into a separate bridge and a >> connector driver >> and test it on multiple SoC platforms (there are at least 3 or 4), I >> think modifying >> the fundamentals of the dw-hdmi architecture just to get CI20 HDMI >> working is not >> our turf. > > You could have a field in the dw-hdmi pdata structure, that would > instruct the driver whether or not it should use the new API. Ugly, > I know, and would probably duplicate a lot of code, but that would > allow other drivers to be updated at a later date. Yes, would be very ugly. But generally who has the knowledge (and time) to do this work? And has a working platform to test (jz4780 isn't a good development environment)? The driver seems to have a turbulent history starting 2013 in staging/imx and apparently it was generalized since then... Is Laurent currently dw-hdmi maintainer? >>> >>> "Maintainer" would be an overstatement. I've worked on that driver in >>> the past, and I still use it, but don't have time to really maintain it. >>> I've also been told that Synopsys required all patches for that driver >>> developed using documentation under NDA to be submitted internally to >>> them first before being published, so I decided to stop contributing >>> instead of agreeing with this insane process. There's public >>> documentation about the IP in some NXP reference manuals though, so it >>> should be possible to still move forward without abiding by this rule. >>> >> Therefore the code here should be able to detect if drm_bridge_attach() >> already >> creates and attaches a connector and then skip the code below. > > Not that easy, unfortunately. On one side we have dw-hdmi which > checks that DRM_BRIDGE_ATTACH_NO_CONNECTOR is not set, and on the > other side we have other drivers like the IT66121 which will fail if > this flag is not set. Ok, I see. You have to handle contradicting cases here. Would it be possible to run it with DRM_BRIDGE_ATTACH_NO_CONNECTOR first and retry if it fails without? But IMHO the return value (in error case) is not well defined. So there must be a test if a connector has been created (I do not know how this would work). Another suggestion: can you check if there is a downstream connector defined in device tree (dw-hdmi does not need such a definition)? If not we call it with 0 and if there is one we call it with DRM_BRIDGE_ATTACH_NO_CONNECTOR and create one? >>> >>> I haven't followed the ful conversation, what the reason why >>> DRM_BRIDGE_ATTACH_NO_CONNECTOR can't always be use here ? >> >> The synopsys driver creates its own connector through >> dw_hdmi_connector_create() >> because the IP handles DDC/EDID directly. > > That doesn't require creating a connector though. The driver implements > drm_bridge_funcs.get_edid(), which is used to get the EDID without the > need to create a connector in the dw-hdmi driver. Ah, ok. But then we still have issues. Firstly I would assume that get_edid only works properly if it is initialized through dw_hdmi_connector_create(). Next, in the current code, passing DRM_BRIDGE_ATTACH_NO_CONNECTOR to dw_hdmi_bridge_attach() indeed does not call dw_hdmi_connector_create() but returns 0. This patch 6/6 makes drm/ingenic unconditionally require a connector to be attached which is defined somewhere else (device tree e.g. "connector-hdmi") unrelated to dw-hdmi. Current upstream code for drm/ingenic does not init/attach such a connector on its own so it did work before. I.e. I think we can't just use parts of dw-hdmi. If drm_bridge_attach() would return some errno if DRM_BRIDGE_ATTA
[PULL] drm-intel-fixes
Hi Dave & Daniel - drm-intel-fixes-2021-09-23: drm/i915 fixes for v5.15-rc3: - Fix ADL-P memory bandwidth parameters - Fix memory corruption due to a double free - Fix memory leak in DMC firmware handling BR, Jani. The following changes since commit e4e737bb5c170df6135a127739a9e6148ee3da82: Linux 5.15-rc2 (2021-09-19 17:28:22 -0700) are available in the Git repository at: git://anongit.freedesktop.org/drm/drm-intel tags/drm-intel-fixes-2021-09-23 for you to fetch changes up to b875fb313a10bf816b5d49d8d7642d1cc9905f2f: drm/i915: Free all DMC payloads (2021-09-21 13:36:34 +0300) drm/i915 fixes for v5.15-rc3: - Fix ADL-P memory bandwidth parameters - Fix memory corruption due to a double free - Fix memory leak in DMC firmware handling Chris Wilson (1): drm/i915: Free all DMC payloads Maarten Lankhorst (1): drm/i915: Move __i915_gem_free_object to ttm_bo_destroy Radhakrishna Sripada (1): drm/i915: Update memory bandwidth parameters drivers/gpu/drm/i915/display/intel_bw.c | 19 --- drivers/gpu/drm/i915/display/intel_dmc.c | 5 - drivers/gpu/drm/i915/gem/i915_gem_ttm.c | 9 + 3 files changed, 25 insertions(+), 8 deletions(-) -- Jani Nikula, Intel Open Source Graphics Center
Re: [PATCH v2] backlight: propagate errors from get_brightness()
On 2021-09-23T10:48+0100, Lee Jones wrote: > On Tue, 07 Sep 2021, Thomas Weißschuh wrote: > > > backlight.h documents "struct backlight_ops->get_brightness()" to return > > a negative errno on failure. > > So far these errors have not been handled in the backlight core. > > This leads to negative values being exposed through sysfs although only > > positive values are documented to be reported. > > > > Signed-off-by: Thomas Weißschuh > > --- > > > > v1: > > https://lore.kernel.org/dri-devel/20210906215525.15418-1-li...@weissschuh.net/ > > > > v1 -> v2: > > * use dev_err() instead of dev_warn() (Daniel Thompson) > > * Finish logging format string with newline (Daniel Thompson) > > * Log errno via dedicated error pointer format (Daniel Thompson) > > > > drivers/video/backlight/backlight.c | 22 +- > > 1 file changed, 17 insertions(+), 5 deletions(-) > > Applied, thanks. Hi Lee, thanks! Also I'm sorry about my nagging before. I was not aware you were on vacation and saw you respond to other mails. Thomas
Re: [Intel-gfx] [PATCH v6 3/9] drm/i915/gt: Increase suspend timeout
On 22/09/2021 07:25, Thomas Hellström wrote:
With GuC submission on DG1, the execution of the requests times out
for the gem_exec_suspend igt test case after executing around 800-900
of 1000 submitted requests.
Given the time we allow elsewhere for fences to signal (in the order of
seconds), increase the timeout before we mark the gt wedged and proceed.
I suspect it is not about requests not retiring in time but about the
intel_guc_wait_for_idle part of intel_gt_wait_for_idle. Although I don't
know which G2H message is the code waiting for at suspend time so
perhaps something to run past the GuC experts.
Anyway, if that turns out to be correct then perhaps it would be better
to split the two timeouts (like if required GuC timeout is perhaps
fundamentally independent) so it's clear who needs how much time. Adding
Matt and John to comment.
To be clear, as timeout is AFAIK an arbitrary value, I don't have
fundamental objections here. Just think it would be good to have
accurate story in the commit message.
Regards,
Tvrtko
Signed-off-by: Thomas Hellström
---
drivers/gpu/drm/i915/gt/intel_gt_pm.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/gt/intel_gt_pm.c
b/drivers/gpu/drm/i915/gt/intel_gt_pm.c
index dea8e2479897..f84f2bfe2de0 100644
--- a/drivers/gpu/drm/i915/gt/intel_gt_pm.c
+++ b/drivers/gpu/drm/i915/gt/intel_gt_pm.c
@@ -19,6 +19,8 @@
#include "intel_rps.h"
#include "intel_wakeref.h"
+#define I915_GT_SUSPEND_IDLE_TIMEOUT (HZ / 2)
+
static void user_forcewake(struct intel_gt *gt, bool suspend)
{
int count = atomic_read(>->user_wakeref);
@@ -279,7 +281,7 @@ static void wait_for_suspend(struct intel_gt *gt)
if (!intel_gt_pm_is_awake(gt))
return;
- if (intel_gt_wait_for_idle(gt, I915_GEM_IDLE_TIMEOUT) == -ETIME) {
+ if (intel_gt_wait_for_idle(gt, I915_GT_SUSPEND_IDLE_TIMEOUT) == -ETIME)
{
/*
* Forcibly cancel outstanding work and leave
* the gpu quiet.
Re: [PATCH v3 6/6] drm/ingenic: Attach bridge chain to encoders
Hi Nikolaus, On Thu, Sep 23, 2021 at 11:55:56AM +0200, H. Nikolaus Schaller wrote: > > Am 23.09.2021 um 11:27 schrieb Laurent Pinchart: > > On Thu, Sep 23, 2021 at 11:19:23AM +0200, H. Nikolaus Schaller wrote: > >> > > + ret = drm_bridge_attach(encoder, &ib->bridge, NULL, > > + DRM_BRIDGE_ATTACH_NO_CONNECTOR); > > DRM_BRIDGE_ATTACH_NO_CONNECTOR makes it fundamentally incompatible > with synopsys/dw_hdmi.c > That driver checks for DRM_BRIDGE_ATTACH_NO_CONNECTOR being NOT present, > since it wants to register its own connector through > dw_hdmi_connector_create(). > It does it for a reason: the dw-hdmi is a multi-function driver which > does > HDMI and DDC/EDID stuff in a single driver (because I/O registers and > power > management seem to be shared). > >>> > >>> The IT66121 driver does all of that too, and does not need > >>> DRM_BRIDGE_ATTACH_NO_CONNECTOR. The drm_bridge_funcs struct has > >>> callbacks to handle cable detection and DDC stuff. > >>> > Since I do not see who could split this into a separate bridge and a > connector driver > and test it on multiple SoC platforms (there are at least 3 or 4), I > think modifying > the fundamentals of the dw-hdmi architecture just to get CI20 HDMI > working is not > our turf. > >>> > >>> You could have a field in the dw-hdmi pdata structure, that would > >>> instruct the driver whether or not it should use the new API. Ugly, > >>> I know, and would probably duplicate a lot of code, but that would > >>> allow other drivers to be updated at a later date. > >> > >> Yes, would be very ugly. > >> > >> But generally who has the knowledge (and time) to do this work? > >> And has a working platform to test (jz4780 isn't a good development > >> environment)? > >> > >> The driver seems to have a turbulent history starting 2013 in staging/imx > >> and > >> apparently it was generalized since then... Is Laurent currently dw-hdmi > >> maintainer? > > > > "Maintainer" would be an overstatement. I've worked on that driver in > > the past, and I still use it, but don't have time to really maintain it. > > I've also been told that Synopsys required all patches for that driver > > developed using documentation under NDA to be submitted internally to > > them first before being published, so I decided to stop contributing > > instead of agreeing with this insane process. There's public > > documentation about the IP in some NXP reference manuals though, so it > > should be possible to still move forward without abiding by this rule. > > > Therefore the code here should be able to detect if drm_bridge_attach() > already > creates and attaches a connector and then skip the code below. > >>> > >>> Not that easy, unfortunately. On one side we have dw-hdmi which > >>> checks that DRM_BRIDGE_ATTACH_NO_CONNECTOR is not set, and on the > >>> other side we have other drivers like the IT66121 which will fail if > >>> this flag is not set. > >> > >> Ok, I see. You have to handle contradicting cases here. > >> > >> Would it be possible to run it with DRM_BRIDGE_ATTACH_NO_CONNECTOR first > >> and retry if it fails without? > >> > >> But IMHO the return value (in error case) is not well defined. So there > >> must be a test if a connector has been created (I do not know how this > >> would work). > >> > >> Another suggestion: can you check if there is a downstream connector > >> defined in > >> device tree (dw-hdmi does not need such a definition)? > >> If not we call it with 0 and if there is one we call it with > >> DRM_BRIDGE_ATTACH_NO_CONNECTOR and create one? > > > > I haven't followed the ful conversation, what the reason why > > DRM_BRIDGE_ATTACH_NO_CONNECTOR can't always be use here ? > > The synopsys driver creates its own connector through > dw_hdmi_connector_create() > because the IP handles DDC/EDID directly. That doesn't require creating a connector though. The driver implements drm_bridge_funcs.get_edid(), which is used to get the EDID without the need to create a connector in the dw-hdmi driver. > Hence it checks for ! DRM_BRIDGE_ATTACH_NO_CONNECTOR which seems to be the > right thing to do on current platforms that use it. > > For CI20/jz4780 we just add a specialisation of the generic dw-hdmi to > make HDMI work. > > Now this patch for drm/ingenic wants the opposite definition and create its > own > connector. This fails even if we remove the check (then we have two > interfering > connectors). > > > We're moving > > towards requiring DRM_BRIDGE_ATTACH_NO_CONNECTOR for all new code, so it > > will have to be done eventually. > > So from my view drm/ingenic wants to already enforce this rule and breaks > dw-hdmi. > > IMHO it should either handle this situation gracefully or include a fix for > dw-hdmi.c to keep it compatible. -- Regards, Laurent Pinchart
Re: [PATCH v6 7/9] drm/i915: Reduce the number of objects subject to memcpy recover
On 9/23/21 11:44 AM, Matthew Auld wrote:
On 22/09/2021 07:25, Thomas Hellström wrote:
We really only need memcpy restore for objects that affect the
operability of the migrate context. That is, primarily the page-table
objects of the migrate VM.
Add an object flag, I915_BO_ALLOC_PM_EARLY for objects that need early
restores using memcpy and a way to assign LMEM page-table object flags
to be used by the vms.
Restore objects without this flag with the gpu blitter and only objects
carrying the flag using TTM memcpy.
Initially mark the migrate, gt, gtt and vgpu vms to use this flag, and
defer for a later audit which vms actually need it. Most importantly,
user-
allocated vms with pinned page-table objects can be restored using the
blitter.
Performance-wise memcpy restore is probably as fast as gpu restore if
not
faster, but using gpu restore will help tackling future restrictions in
mappable LMEM size.
v4:
- Don't mark the aliasing ppgtt page table flags for early resume, but
rather the ggtt page table flags as intended. (Matthew Auld)
- The check for user buffer objects during early resume is pointless,
since
they are never marked I915_BO_ALLOC_PM_EARLY. (Matthew Auld)
v5:
- Mark GuC LMEM objects with I915_BO_ALLOC_PM_EARLY to have them
restored
before we fire up the migrate context.
Cc: Matthew Brost
Signed-off-by: Thomas Hellström
Reviewed-by: Matthew Auld
---
drivers/gpu/drm/i915/gem/i915_gem_context.c | 4 ++--
drivers/gpu/drm/i915/gem/i915_gem_object_types.h | 9 ++---
drivers/gpu/drm/i915/gem/i915_gem_pm.c | 6 +-
drivers/gpu/drm/i915/gem/i915_gem_ttm_pm.c | 5 +++--
drivers/gpu/drm/i915/gem/selftests/huge_pages.c | 2 +-
drivers/gpu/drm/i915/gt/gen6_ppgtt.c | 2 +-
drivers/gpu/drm/i915/gt/gen8_ppgtt.c | 5 +++--
drivers/gpu/drm/i915/gt/gen8_ppgtt.h | 4 +++-
drivers/gpu/drm/i915/gt/intel_ggtt.c | 3 ++-
drivers/gpu/drm/i915/gt/intel_gt.c | 2 +-
drivers/gpu/drm/i915/gt/intel_gtt.c | 3 ++-
drivers/gpu/drm/i915/gt/intel_gtt.h | 9 +++--
drivers/gpu/drm/i915/gt/intel_migrate.c | 2 +-
drivers/gpu/drm/i915/gt/intel_ppgtt.c | 13 -
drivers/gpu/drm/i915/gt/selftest_hangcheck.c | 2 +-
drivers/gpu/drm/i915/gt/uc/intel_guc.c | 3 ++-
drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c | 7 +--
drivers/gpu/drm/i915/gvt/scheduler.c | 2 +-
drivers/gpu/drm/i915/selftests/i915_gem_gtt.c | 4 ++--
19 files changed, 56 insertions(+), 31 deletions(-)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_context.c
b/drivers/gpu/drm/i915/gem/i915_gem_context.c
index c2ab0e22db0a..8208fd5b72c3 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_context.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_context.c
@@ -1287,7 +1287,7 @@ i915_gem_create_context(struct drm_i915_private
*i915,
} else if (HAS_FULL_PPGTT(i915)) {
struct i915_ppgtt *ppgtt;
- ppgtt = i915_ppgtt_create(&i915->gt);
+ ppgtt = i915_ppgtt_create(&i915->gt, 0);
if (IS_ERR(ppgtt)) {
drm_dbg(&i915->drm, "PPGTT setup failed (%ld)\n",
PTR_ERR(ppgtt));
@@ -1465,7 +1465,7 @@ int i915_gem_vm_create_ioctl(struct drm_device
*dev, void *data,
if (args->flags)
return -EINVAL;
- ppgtt = i915_ppgtt_create(&i915->gt);
+ ppgtt = i915_ppgtt_create(&i915->gt, 0);
if (IS_ERR(ppgtt))
return PTR_ERR(ppgtt);
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_object_types.h
b/drivers/gpu/drm/i915/gem/i915_gem_object_types.h
index 118691ce81d7..fa2ba9e2a4d0 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_object_types.h
+++ b/drivers/gpu/drm/i915/gem/i915_gem_object_types.h
@@ -294,13 +294,16 @@ struct drm_i915_gem_object {
#define I915_BO_ALLOC_USER BIT(3)
/* Object is allowed to lose its contents on suspend / resume, even
if pinned */
#define I915_BO_ALLOC_PM_VOLATILE BIT(4)
+/* Object needs to be restored early using memcpy during resume */
+#define I915_BO_ALLOC_PM_EARLY BIT(5)
#define I915_BO_ALLOC_FLAGS (I915_BO_ALLOC_CONTIGUOUS | \
I915_BO_ALLOC_VOLATILE | \
I915_BO_ALLOC_CPU_CLEAR | \
I915_BO_ALLOC_USER | \
- I915_BO_ALLOC_PM_VOLATILE)
-#define I915_BO_READONLY BIT(5)
-#define I915_TILING_QUIRK_BIT 6 /* unknown swizzling; do not
release! */
+ I915_BO_ALLOC_PM_VOLATILE | \
+ I915_BO_ALLOC_PM_EARLY)
+#define I915_BO_READONLY BIT(6)
+#define I915_TILING_QUIRK_BIT 7 /* unknown swizzling; do not
release! */
/**
* @mem_flags - Mutable placement-related flags
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_pm.c
b/drivers/gpu/drm/i915/gem/i915_gem_pm.c
index 12b37b4c1192..726b40e1fbb0 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_pm.c
+++ b/drivers/gpu/drm/i91
Re: [PATCH v3 6/6] drm/ingenic: Attach bridge chain to encoders
Hi Laurent, > Am 23.09.2021 um 11:27 schrieb Laurent Pinchart > : > > Hi Nikolaus, > > On Thu, Sep 23, 2021 at 11:19:23AM +0200, H. Nikolaus Schaller wrote: >> > + ret = drm_bridge_attach(encoder, &ib->bridge, NULL, > + DRM_BRIDGE_ATTACH_NO_CONNECTOR); DRM_BRIDGE_ATTACH_NO_CONNECTOR makes it fundamentally incompatible with synopsys/dw_hdmi.c That driver checks for DRM_BRIDGE_ATTACH_NO_CONNECTOR being NOT present, since it wants to register its own connector through dw_hdmi_connector_create(). It does it for a reason: the dw-hdmi is a multi-function driver which does HDMI and DDC/EDID stuff in a single driver (because I/O registers and power management seem to be shared). >>> >>> The IT66121 driver does all of that too, and does not need >>> DRM_BRIDGE_ATTACH_NO_CONNECTOR. The drm_bridge_funcs struct has >>> callbacks to handle cable detection and DDC stuff. >>> Since I do not see who could split this into a separate bridge and a connector driver and test it on multiple SoC platforms (there are at least 3 or 4), I think modifying the fundamentals of the dw-hdmi architecture just to get CI20 HDMI working is not our turf. >>> >>> You could have a field in the dw-hdmi pdata structure, that would >>> instruct the driver whether or not it should use the new API. Ugly, >>> I know, and would probably duplicate a lot of code, but that would >>> allow other drivers to be updated at a later date. >> >> Yes, would be very ugly. >> >> But generally who has the knowledge (and time) to do this work? >> And has a working platform to test (jz4780 isn't a good development >> environment)? >> >> The driver seems to have a turbulent history starting 2013 in staging/imx and >> apparently it was generalized since then... Is Laurent currently dw-hdmi >> maintainer? > > "Maintainer" would be an overstatement. I've worked on that driver in > the past, and I still use it, but don't have time to really maintain it. > I've also been told that Synopsys required all patches for that driver > developed using documentation under NDA to be submitted internally to > them first before being published, so I decided to stop contributing > instead of agreeing with this insane process. There's public > documentation about the IP in some NXP reference manuals though, so it > should be possible to still move forward without abiding by this rule. > Therefore the code here should be able to detect if drm_bridge_attach() already creates and attaches a connector and then skip the code below. >>> >>> Not that easy, unfortunately. On one side we have dw-hdmi which >>> checks that DRM_BRIDGE_ATTACH_NO_CONNECTOR is not set, and on the >>> other side we have other drivers like the IT66121 which will fail if >>> this flag is not set. >> >> Ok, I see. You have to handle contradicting cases here. >> >> Would it be possible to run it with DRM_BRIDGE_ATTACH_NO_CONNECTOR first >> and retry if it fails without? >> >> But IMHO the return value (in error case) is not well defined. So there >> must be a test if a connector has been created (I do not know how this >> would work). >> >> Another suggestion: can you check if there is a downstream connector defined >> in >> device tree (dw-hdmi does not need such a definition)? >> If not we call it with 0 and if there is one we call it with >> DRM_BRIDGE_ATTACH_NO_CONNECTOR and create one? > > I haven't followed the ful conversation, what the reason why > DRM_BRIDGE_ATTACH_NO_CONNECTOR can't always be use here ? The synopsys driver creates its own connector through dw_hdmi_connector_create() because the IP handles DDC/EDID directly. Hence it checks for ! DRM_BRIDGE_ATTACH_NO_CONNECTOR which seems to be the right thing to do on current platforms that use it. For CI20/jz4780 we just add a specialisation of the generic dw-hdmi to make HDMI work. Now this patch for drm/ingenic wants the opposite definition and create its own connector. This fails even if we remove the check (then we have two interfering connectors). > We're moving > towards requiring DRM_BRIDGE_ATTACH_NO_CONNECTOR for all new code, so it > will have to be done eventually. So from my view drm/ingenic wants to already enforce this rule and breaks dw-hdmi. IMHO it should either handle this situation gracefully or include a fix for dw-hdmi.c to keep it compatible. BR and thanks, Nikolaus
Re: [PATCH v2] backlight: propagate errors from get_brightness()
On Tue, 07 Sep 2021, Thomas Weißschuh wrote: > backlight.h documents "struct backlight_ops->get_brightness()" to return > a negative errno on failure. > So far these errors have not been handled in the backlight core. > This leads to negative values being exposed through sysfs although only > positive values are documented to be reported. > > Signed-off-by: Thomas Weißschuh > --- > > v1: > https://lore.kernel.org/dri-devel/20210906215525.15418-1-li...@weissschuh.net/ > > v1 -> v2: > * use dev_err() instead of dev_warn() (Daniel Thompson) > * Finish logging format string with newline (Daniel Thompson) > * Log errno via dedicated error pointer format (Daniel Thompson) > > drivers/video/backlight/backlight.c | 22 +- > 1 file changed, 17 insertions(+), 5 deletions(-) Applied, thanks. -- Lee Jones [李琼斯] Senior Technical Lead - Developer Services Linaro.org │ Open source software for Arm SoCs Follow Linaro: Facebook | Twitter | Blog
Re: [PATCH v6 7/9] drm/i915: Reduce the number of objects subject to memcpy recover
On 22/09/2021 07:25, Thomas Hellström wrote:
We really only need memcpy restore for objects that affect the
operability of the migrate context. That is, primarily the page-table
objects of the migrate VM.
Add an object flag, I915_BO_ALLOC_PM_EARLY for objects that need early
restores using memcpy and a way to assign LMEM page-table object flags
to be used by the vms.
Restore objects without this flag with the gpu blitter and only objects
carrying the flag using TTM memcpy.
Initially mark the migrate, gt, gtt and vgpu vms to use this flag, and
defer for a later audit which vms actually need it. Most importantly, user-
allocated vms with pinned page-table objects can be restored using the
blitter.
Performance-wise memcpy restore is probably as fast as gpu restore if not
faster, but using gpu restore will help tackling future restrictions in
mappable LMEM size.
v4:
- Don't mark the aliasing ppgtt page table flags for early resume, but
rather the ggtt page table flags as intended. (Matthew Auld)
- The check for user buffer objects during early resume is pointless, since
they are never marked I915_BO_ALLOC_PM_EARLY. (Matthew Auld)
v5:
- Mark GuC LMEM objects with I915_BO_ALLOC_PM_EARLY to have them restored
before we fire up the migrate context.
Cc: Matthew Brost
Signed-off-by: Thomas Hellström
Reviewed-by: Matthew Auld
---
drivers/gpu/drm/i915/gem/i915_gem_context.c | 4 ++--
drivers/gpu/drm/i915/gem/i915_gem_object_types.h | 9 ++---
drivers/gpu/drm/i915/gem/i915_gem_pm.c | 6 +-
drivers/gpu/drm/i915/gem/i915_gem_ttm_pm.c | 5 +++--
drivers/gpu/drm/i915/gem/selftests/huge_pages.c | 2 +-
drivers/gpu/drm/i915/gt/gen6_ppgtt.c | 2 +-
drivers/gpu/drm/i915/gt/gen8_ppgtt.c | 5 +++--
drivers/gpu/drm/i915/gt/gen8_ppgtt.h | 4 +++-
drivers/gpu/drm/i915/gt/intel_ggtt.c | 3 ++-
drivers/gpu/drm/i915/gt/intel_gt.c | 2 +-
drivers/gpu/drm/i915/gt/intel_gtt.c | 3 ++-
drivers/gpu/drm/i915/gt/intel_gtt.h | 9 +++--
drivers/gpu/drm/i915/gt/intel_migrate.c | 2 +-
drivers/gpu/drm/i915/gt/intel_ppgtt.c| 13 -
drivers/gpu/drm/i915/gt/selftest_hangcheck.c | 2 +-
drivers/gpu/drm/i915/gt/uc/intel_guc.c | 3 ++-
drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c | 7 +--
drivers/gpu/drm/i915/gvt/scheduler.c | 2 +-
drivers/gpu/drm/i915/selftests/i915_gem_gtt.c| 4 ++--
19 files changed, 56 insertions(+), 31 deletions(-)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_context.c
b/drivers/gpu/drm/i915/gem/i915_gem_context.c
index c2ab0e22db0a..8208fd5b72c3 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_context.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_context.c
@@ -1287,7 +1287,7 @@ i915_gem_create_context(struct drm_i915_private *i915,
} else if (HAS_FULL_PPGTT(i915)) {
struct i915_ppgtt *ppgtt;
- ppgtt = i915_ppgtt_create(&i915->gt);
+ ppgtt = i915_ppgtt_create(&i915->gt, 0);
if (IS_ERR(ppgtt)) {
drm_dbg(&i915->drm, "PPGTT setup failed (%ld)\n",
PTR_ERR(ppgtt));
@@ -1465,7 +1465,7 @@ int i915_gem_vm_create_ioctl(struct drm_device *dev, void
*data,
if (args->flags)
return -EINVAL;
- ppgtt = i915_ppgtt_create(&i915->gt);
+ ppgtt = i915_ppgtt_create(&i915->gt, 0);
if (IS_ERR(ppgtt))
return PTR_ERR(ppgtt);
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_object_types.h b/drivers/gpu/drm/i915/gem/i915_gem_object_types.h
index 118691ce81d7..fa2ba9e2a4d0 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_object_types.h
+++ b/drivers/gpu/drm/i915/gem/i915_gem_object_types.h
@@ -294,13 +294,16 @@ struct drm_i915_gem_object {
#define I915_BO_ALLOC_USERBIT(3)
/* Object is allowed to lose its contents on suspend / resume, even if pinned
*/
#define I915_BO_ALLOC_PM_VOLATILE BIT(4)
+/* Object needs to be restored early using memcpy during resume */
+#define I915_BO_ALLOC_PM_EARLYBIT(5)
#define I915_BO_ALLOC_FLAGS (I915_BO_ALLOC_CONTIGUOUS | \
I915_BO_ALLOC_VOLATILE | \
I915_BO_ALLOC_CPU_CLEAR | \
I915_BO_ALLOC_USER | \
-I915_BO_ALLOC_PM_VOLATILE)
-#define I915_BO_READONLY BIT(5)
-#define I915_TILING_QUIRK_BIT 6 /* unknown swizzling; do not release! */
+I915_BO_ALLOC_PM_VOLATILE | \
+I915_BO_ALLOC_PM_EARLY)
+#define I915_BO_READONLY BIT(6)
+#define I915_TILING_QUIRK_BIT 7 /* unknown swizzling; do not release! */
/**
* @mem_flags - Mutable placement-related flags
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_pm.c
b/drivers/gpu/drm/i915/gem/i915_gem_pm.c
index 12b37b4c1192..726b40e1fbb0 100644
--- a/dri
Re: [PATCH v3 6/6] drm/ingenic: Attach bridge chain to encoders
Hi Nikolaus, On Thu, Sep 23, 2021 at 11:19:23AM +0200, H. Nikolaus Schaller wrote: > > Am 23.09.2021 um 10:49 schrieb Paul Cercueil: > > Le jeu., sept. 23 2021 at 07:52:08 +0200, H. Nikolaus Schaller a écrit : > >> Hi Paul, > >> thanks for another update. > >> We have been delayed to rework the CI20 HDMI code on top of your series > >> but it basically works in some situations. There is for example a problem > >> if the EDID reports DRM_COLOR_FORMAT_YCRCB422 but it appears to be outside > >> of your series. > > > > I think the SoC can output YCbCr as well, but I never tried to use it. > > Maybe there is code missing or something else. We have not yet deeply > researched. > Except that when ignoring DRM_COLOR_FORMAT_YCRCB422 capability it uses RGB > and works. > > >>> + ret = drm_bridge_attach(encoder, &ib->bridge, NULL, > >>> + DRM_BRIDGE_ATTACH_NO_CONNECTOR); > >> > >> DRM_BRIDGE_ATTACH_NO_CONNECTOR makes it fundamentally incompatible > >> with synopsys/dw_hdmi.c > >> That driver checks for DRM_BRIDGE_ATTACH_NO_CONNECTOR being NOT present, > >> since it wants to register its own connector through > >> dw_hdmi_connector_create(). > >> It does it for a reason: the dw-hdmi is a multi-function driver which does > >> HDMI and DDC/EDID stuff in a single driver (because I/O registers and power > >> management seem to be shared). > > > > The IT66121 driver does all of that too, and does not need > > DRM_BRIDGE_ATTACH_NO_CONNECTOR. The drm_bridge_funcs struct has > > callbacks to handle cable detection and DDC stuff. > > > >> Since I do not see who could split this into a separate bridge and a > >> connector driver > >> and test it on multiple SoC platforms (there are at least 3 or 4), I think > >> modifying > >> the fundamentals of the dw-hdmi architecture just to get CI20 HDMI working > >> is not > >> our turf. > > > > You could have a field in the dw-hdmi pdata structure, that would > > instruct the driver whether or not it should use the new API. Ugly, > > I know, and would probably duplicate a lot of code, but that would > > allow other drivers to be updated at a later date. > > Yes, would be very ugly. > > But generally who has the knowledge (and time) to do this work? > And has a working platform to test (jz4780 isn't a good development > environment)? > > The driver seems to have a turbulent history starting 2013 in staging/imx and > apparently it was generalized since then... Is Laurent currently dw-hdmi > maintainer? "Maintainer" would be an overstatement. I've worked on that driver in the past, and I still use it, but don't have time to really maintain it. I've also been told that Synopsys required all patches for that driver developed using documentation under NDA to be submitted internally to them first before being published, so I decided to stop contributing instead of agreeing with this insane process. There's public documentation about the IP in some NXP reference manuals though, so it should be possible to still move forward without abiding by this rule. > >> Therefore the code here should be able to detect if drm_bridge_attach() > >> already > >> creates and attaches a connector and then skip the code below. > > > > Not that easy, unfortunately. On one side we have dw-hdmi which > > checks that DRM_BRIDGE_ATTACH_NO_CONNECTOR is not set, and on the > > other side we have other drivers like the IT66121 which will fail if > > this flag is not set. > > Ok, I see. You have to handle contradicting cases here. > > Would it be possible to run it with DRM_BRIDGE_ATTACH_NO_CONNECTOR first > and retry if it fails without? > > But IMHO the return value (in error case) is not well defined. So there > must be a test if a connector has been created (I do not know how this > would work). > > Another suggestion: can you check if there is a downstream connector defined > in > device tree (dw-hdmi does not need such a definition)? > If not we call it with 0 and if there is one we call it with > DRM_BRIDGE_ATTACH_NO_CONNECTOR and create one? I haven't followed the ful conversation, what the reason why DRM_BRIDGE_ATTACH_NO_CONNECTOR can't always be use here ? We're moving towards requiring DRM_BRIDGE_ATTACH_NO_CONNECTOR for all new code, so it will have to be done eventually. > Just some ideas how to solve without touching hdmi drivers. > > BR and thanks, > Nikolaus -- Regards, Laurent Pinchart
Re: [PATCH v6 0/2] Add p2p via dmabuf to habanalabs
On Sat, Sep 18, 2021 at 11:38 AM Oded Gabbay wrote: > > On Fri, Sep 17, 2021 at 3:30 PM Daniel Vetter wrote: > > > > On Thu, Sep 16, 2021 at 10:10:14AM -0300, Jason Gunthorpe wrote: > > > On Thu, Sep 16, 2021 at 02:31:34PM +0200, Daniel Vetter wrote: > > > > On Wed, Sep 15, 2021 at 10:45:36AM +0300, Oded Gabbay wrote: > > > > > On Tue, Sep 14, 2021 at 7:12 PM Jason Gunthorpe wrote: > > > > > > > > > > > > On Tue, Sep 14, 2021 at 04:18:31PM +0200, Daniel Vetter wrote: > > > > > > > On Sun, Sep 12, 2021 at 07:53:07PM +0300, Oded Gabbay wrote: > > > > > > > > Hi, > > > > > > > > Re-sending this patch-set following the release of our > > > > > > > > user-space TPC > > > > > > > > compiler and runtime library. > > > > > > > > > > > > > > > > I would appreciate a review on this. > > > > > > > > > > > > > > I think the big open we have is the entire revoke discussions. > > > > > > > Having the > > > > > > > option to let dma-buf hang around which map to random local > > > > > > > memory ranges, > > > > > > > without clear ownership link and a way to kill it sounds bad to > > > > > > > me. > > > > > > > > > > > > > > I think there's a few options: > > > > > > > - We require revoke support. But I've heard rdma really doesn't > > > > > > > like that, > > > > > > > I guess because taking out an MR while holding the > > > > > > > dma_resv_lock would > > > > > > > be an inversion, so can't be done. Jason, can you recap what > > > > > > > exactly the > > > > > > > hold-up was again that makes this a no-go? > > > > > > > > > > > > RDMA HW can't do revoke. > > > > > > > > Like why? I'm assuming when the final open handle or whatever for that > > > > MR > > > > is closed, you do clean up everything? Or does that MR still stick > > > > around > > > > forever too? > > > > > > It is a combination of uAPI and HW specification. > > > > > > revoke here means you take a MR object and tell it to stop doing DMA > > > without causing the MR object to be destructed. > > > > > > All the drivers can of course destruct the MR, but doing such a > > > destruction without explicit synchronization with user space opens > > > things up to a serious use-after potential that could be a security > > > issue. > > > > > > When the open handle closes the userspace is synchronized with the > > > kernel and we can destruct the HW objects safely. > > > > > > So, the special HW feature required is 'stop doing DMA but keep the > > > object in an error state' which isn't really implemented, and doesn't > > > extend very well to other object types beyond simple MRs. > > > > Yeah revoke without destroying the MR doesn't work, and it sounds like > > revoke by destroying the MR just moves the can of worms around to another > > place. > > > > > > 1. User A opens gaudi device, sets up dma-buf export > > > > > > > > 2. User A registers that with RDMA, or anything else that doesn't > > > > support > > > > revoke. > > > > > > > > 3. User A closes gaudi device > > > > > > > > 4. User B opens gaudi device, assumes that it has full control over the > > > > device and uploads some secrets, which happen to end up in the dma-buf > > > > region user A set up > > > > > > I would expect this is blocked so long as the DMABUF exists - eg the > > > DMABUF will hold a fget on the FD of #1 until the DMABUF is closed, so > > > that #3 can't actually happen. > > > > > > > It's not mlocked memory, it's mlocked memory and I can exfiltrate > > > > it. > > > > > > That's just bug, don't make buggy drivers :) > > > > Well yeah, but given that habanalabs hand rolled this I can't just check > > for the usual things we have to enforce this in drm. And generally you can > > just open chardevs arbitrarily, and multiple users fighting over each > > another. The troubles only start when you have private state or memory > > allocations of some kind attached to the struct file (instead of the > > underlying device), or something else that requires device exclusivity. > > There's no standard way to do that. > > > > Plus in many cases you really want revoke on top (can't get that here > > unfortunately it seems), and the attempts to get towards a generic > > revoke() just never went anywhere. So again it's all hand-rolled > > per-subsystem. *insert lament about us not having done this through a > > proper subsystem* > > > > Anyway it sounds like the code takes care of that. > > -Daniel > > Daniel, Jason, > Thanks for reviewing this code. > > Can I get an R-B / A-B from you for this patch-set ? > > Thanks, > Oded A kind reminder. Thanks, Oded
Re: [PATCH v3 6/6] drm/ingenic: Attach bridge chain to encoders
Hello,
On Thu, Sep 23, 2021 at 09:49:03AM +0100, Paul Cercueil wrote:
> Le jeu., sept. 23 2021 at 07:52:08 +0200, H. Nikolaus Schaller a écrit :
> > Hi Paul,
> > thanks for another update.
> >
> > We have been delayed to rework the CI20 HDMI code on top of your series
> > but it basically works in some situations. There is for example a problem
> > if the EDID reports DRM_COLOR_FORMAT_YCRCB422 but it appears to be outside
> > of your series.
>
> I think the SoC can output YCbCr as well, but I never tried to use it.
>
> > The only issue we have is described below.
> >
> >> Am 22.09.2021 um 22:55 schrieb Paul Cercueil :
> >>
> >> Attach a top-level bridge to each encoder, which will be used for
> >> negociating the bus format and flags.
> >>
> >> All the bridges are now attached with DRM_BRIDGE_ATTACH_NO_CONNECTOR.
> >>
> >> Signed-off-by: Paul Cercueil
> >> ---
> >> drivers/gpu/drm/ingenic/ingenic-drm-drv.c | 92 +--
> >> 1 file changed, 70 insertions(+), 22 deletions(-)
> >>
> >> diff --git a/drivers/gpu/drm/ingenic/ingenic-drm-drv.c
> >> b/drivers/gpu/drm/ingenic/ingenic-drm-drv.c
> >> index a5e2880e07a1..a05a9fa6e115 100644
> >> --- a/drivers/gpu/drm/ingenic/ingenic-drm-drv.c
> >> +++ b/drivers/gpu/drm/ingenic/ingenic-drm-drv.c
> >> @@ -21,6 +21,7 @@
> >> #include
> >> #include
> >> #include
> >> +#include
> >> #include
> >> #include
> >> #include
> >> @@ -108,6 +109,19 @@ struct ingenic_drm {
> >>struct drm_private_obj private_obj;
> >> };
> >>
> >> +struct ingenic_drm_bridge {
> >> + struct drm_encoder encoder;
> >> + struct drm_bridge bridge, *next_bridge;
> >> +
> >> + struct drm_bus_cfg bus_cfg;
> >> +};
> >> +
> >> +static inline struct ingenic_drm_bridge *
> >> +to_ingenic_drm_bridge(struct drm_encoder *encoder)
> >> +{
> >> + return container_of(encoder, struct ingenic_drm_bridge, encoder);
> >> +}
> >> +
> >> static inline struct ingenic_drm_private_state *
> >> to_ingenic_drm_priv_state(struct drm_private_state *state)
> >> {
> >> @@ -668,11 +682,10 @@ static void
> >> ingenic_drm_encoder_atomic_mode_set(struct drm_encoder *encoder,
> >> {
> >>struct ingenic_drm *priv = drm_device_get_priv(encoder->dev);
> >>struct drm_display_mode *mode = &crtc_state->adjusted_mode;
> >> - struct drm_connector *conn = conn_state->connector;
> >> - struct drm_display_info *info = &conn->display_info;
> >> + struct ingenic_drm_bridge *bridge = to_ingenic_drm_bridge(encoder);
> >>unsigned int cfg, rgbcfg = 0;
> >>
> >> - priv->panel_is_sharp = info->bus_flags & DRM_BUS_FLAG_SHARP_SIGNALS;
> >> + priv->panel_is_sharp = bridge->bus_cfg.flags &
> >> DRM_BUS_FLAG_SHARP_SIGNALS;
> >>
> >>if (priv->panel_is_sharp) {
> >>cfg = JZ_LCD_CFG_MODE_SPECIAL_TFT_1 | JZ_LCD_CFG_REV_POLARITY;
> >> @@ -685,19 +698,19 @@ static void
> >> ingenic_drm_encoder_atomic_mode_set(struct drm_encoder *encoder,
> >>cfg |= JZ_LCD_CFG_HSYNC_ACTIVE_LOW;
> >>if (mode->flags & DRM_MODE_FLAG_NVSYNC)
> >>cfg |= JZ_LCD_CFG_VSYNC_ACTIVE_LOW;
> >> - if (info->bus_flags & DRM_BUS_FLAG_DE_LOW)
> >> + if (bridge->bus_cfg.flags & DRM_BUS_FLAG_DE_LOW)
> >>cfg |= JZ_LCD_CFG_DE_ACTIVE_LOW;
> >> - if (info->bus_flags & DRM_BUS_FLAG_PIXDATA_DRIVE_NEGEDGE)
> >> + if (bridge->bus_cfg.flags & DRM_BUS_FLAG_PIXDATA_DRIVE_NEGEDGE)
> >>cfg |= JZ_LCD_CFG_PCLK_FALLING_EDGE;
> >>
> >>if (!priv->panel_is_sharp) {
> >> - if (conn->connector_type == DRM_MODE_CONNECTOR_TV) {
> >> + if (conn_state->connector->connector_type ==
> >> DRM_MODE_CONNECTOR_TV) {
> >>if (mode->flags & DRM_MODE_FLAG_INTERLACE)
> >>cfg |= JZ_LCD_CFG_MODE_TV_OUT_I;
> >>else
> >>cfg |= JZ_LCD_CFG_MODE_TV_OUT_P;
> >>} else {
> >> - switch (*info->bus_formats) {
> >> + switch (bridge->bus_cfg.format) {
> >>case MEDIA_BUS_FMT_RGB565_1X16:
> >>cfg |= JZ_LCD_CFG_MODE_GENERIC_16BIT;
> >>break;
> >> @@ -723,20 +736,29 @@ static void
> >> ingenic_drm_encoder_atomic_mode_set(struct drm_encoder *encoder,
> >>regmap_write(priv->map, JZ_REG_LCD_RGBC, rgbcfg);
> >> }
> >>
> >> -static int ingenic_drm_encoder_atomic_check(struct drm_encoder *encoder,
> >> - struct drm_crtc_state *crtc_state,
> >> - struct drm_connector_state
> >> *conn_state)
> >> +static int ingenic_drm_bridge_attach(struct drm_bridge *bridge,
> >> + enum drm_bridge_attach_flags flags)
> >> +{
> >> + struct ingenic_drm_bridge *ib = to_ingenic_drm_bridge(bridge->encoder);
> >> +
> >> + return drm_bridge_attach(bridge->encoder, ib->next_bridge,
> >> + &ib->bridge, flags);
> >> +}
> >> +
> >> +s
Re: [PATCH v3 6/6] drm/ingenic: Attach bridge chain to encoders
Hi Paul, > Am 23.09.2021 um 10:49 schrieb Paul Cercueil : > > Hi Nikolaus, > > Le jeu., sept. 23 2021 at 07:52:08 +0200, H. Nikolaus Schaller > a écrit : >> Hi Paul, >> thanks for another update. >> We have been delayed to rework the CI20 HDMI code on top of your series >> but it basically works in some situations. There is for example a problem >> if the EDID reports DRM_COLOR_FORMAT_YCRCB422 but it appears to be outside >> of your series. > > I think the SoC can output YCbCr as well, but I never tried to use it. Maybe there is code missing or something else. We have not yet deeply researched. Except that when ignoring DRM_COLOR_FORMAT_YCRCB422 capability it uses RGB and works. > >>> + ret = drm_bridge_attach(encoder, &ib->bridge, NULL, >>> + DRM_BRIDGE_ATTACH_NO_CONNECTOR); >> DRM_BRIDGE_ATTACH_NO_CONNECTOR makes it fundamentally incompatible >> with synopsys/dw_hdmi.c >> That driver checks for DRM_BRIDGE_ATTACH_NO_CONNECTOR being NOT present, >> since it wants to register its own connector through >> dw_hdmi_connector_create(). >> It does it for a reason: the dw-hdmi is a multi-function driver which does >> HDMI and DDC/EDID stuff in a single driver (because I/O registers and power >> management seem to be shared). > > The IT66121 driver does all of that too, and does not need > DRM_BRIDGE_ATTACH_NO_CONNECTOR. The drm_bridge_funcs struct has callbacks to > handle cable detection and DDC stuff. > >> Since I do not see who could split this into a separate bridge and a >> connector driver >> and test it on multiple SoC platforms (there are at least 3 or 4), I think >> modifying >> the fundamentals of the dw-hdmi architecture just to get CI20 HDMI working >> is not >> our turf. > > You could have a field in the dw-hdmi pdata structure, that would instruct > the driver whether or not it should use the new API. Ugly, I know, and would > probably duplicate a lot of code, but that would allow other drivers to be > updated at a later date. Yes, would be very ugly. But generally who has the knowledge (and time) to do this work? And has a working platform to test (jz4780 isn't a good development environment)? The driver seems to have a turbulent history starting 2013 in staging/imx and apparently it was generalized since then... Is Laurent currently dw-hdmi maintainer? > >> Therefore the code here should be able to detect if drm_bridge_attach() >> already >> creates and attaches a connector and then skip the code below. > > Not that easy, unfortunately. On one side we have dw-hdmi which checks that > DRM_BRIDGE_ATTACH_NO_CONNECTOR is not set, and on the other side we have > other drivers like the IT66121 which will fail if this flag is not set. Ok, I see. You have to handle contradicting cases here. Would it be possible to run it with DRM_BRIDGE_ATTACH_NO_CONNECTOR first and retry if it fails without? But IMHO the return value (in error case) is not well defined. So there must be a test if a connector has been created (I do not know how this would work). Another suggestion: can you check if there is a downstream connector defined in device tree (dw-hdmi does not need such a definition)? If not we call it with 0 and if there is one we call it with DRM_BRIDGE_ATTACH_NO_CONNECTOR and create one? Just some ideas how to solve without touching hdmi drivers. BR and thanks, Nikolaus
Re: [PATCH v6 3/9] drm/i915/gt: Increase suspend timeout
On 22/09/2021 07:25, Thomas Hellström wrote:
With GuC submission on DG1, the execution of the requests times out
for the gem_exec_suspend igt test case after executing around 800-900
of 1000 submitted requests.
Given the time we allow elsewhere for fences to signal (in the order of
seconds), increase the timeout before we mark the gt wedged and proceed.
Signed-off-by: Thomas Hellström
Acked-by: Matthew Auld
---
drivers/gpu/drm/i915/gt/intel_gt_pm.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/gt/intel_gt_pm.c
b/drivers/gpu/drm/i915/gt/intel_gt_pm.c
index dea8e2479897..f84f2bfe2de0 100644
--- a/drivers/gpu/drm/i915/gt/intel_gt_pm.c
+++ b/drivers/gpu/drm/i915/gt/intel_gt_pm.c
@@ -19,6 +19,8 @@
#include "intel_rps.h"
#include "intel_wakeref.h"
+#define I915_GT_SUSPEND_IDLE_TIMEOUT (HZ / 2)
+
static void user_forcewake(struct intel_gt *gt, bool suspend)
{
int count = atomic_read(>->user_wakeref);
@@ -279,7 +281,7 @@ static void wait_for_suspend(struct intel_gt *gt)
if (!intel_gt_pm_is_awake(gt))
return;
- if (intel_gt_wait_for_idle(gt, I915_GEM_IDLE_TIMEOUT) == -ETIME) {
+ if (intel_gt_wait_for_idle(gt, I915_GT_SUSPEND_IDLE_TIMEOUT) == -ETIME)
{
/*
* Forcibly cancel outstanding work and leave
* the gpu quiet.
[PATCH] drm/amd/display: Fix randomly flicking on overlay with enabled ABM
From: "Yipeng Chen (Jasber)" [Why] Enabled ABM (level != 0) would raise short pluse irq DC_IRQ_SOURCE_HPD1RX randomly with PSR error LINK_CRC_ERROR. Actually there is no hot plugging on EDP panel. After correcting CRC error, there is no need to send drm hotplug event. [How] Returning false would skip doing hot-plug when handle_hpd_irq_psr_sink() handled irq. Hot-plug process causes visible flicking on overlay. Signed-off-by: Yipeng Chen (Jasber) Reviewed-by: Roman Li Anthony Koo --- drivers/gpu/drm/amd/display/dc/core/dc_link_dp.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/amd/display/dc/core/dc_link_dp.c b/drivers/gpu/drm/amd/display/dc/core/dc_link_dp.c index 1e4794e2825c..9b9fbe5e9bd4 100644 --- a/drivers/gpu/drm/amd/display/dc/core/dc_link_dp.c +++ b/drivers/gpu/drm/amd/display/dc/core/dc_link_dp.c @@ -3007,7 +3007,7 @@ bool dc_link_handle_hpd_rx_irq(struct dc_link *link, union hpd_irq_data *out_hpd if (handle_hpd_irq_psr_sink(link)) /* PSR-related error was detected and handled */ - return true; + return false; /* If PSR-related error handled, Main link may be off, * so do not handle as a normal sink status change interrupt. -- 2.25.1
Re: Handling DRM master transitions cooperatively
Hi, On 9/23/21 10:23 AM, Pekka Paalanen wrote: > On Wed, 22 Sep 2021 11:21:16 +0200 > Hans de Goede wrote: > >> Hi, >> >> On 9/22/21 10:56 AM, Pekka Paalanen wrote: >>> On Tue, 14 Sep 2021 15:45:21 +0200 >>> Daniel Vetter wrote: >>> On Thu, Sep 09, 2021 at 10:37:03AM +0300, Pekka Paalanen wrote: > On Wed, 8 Sep 2021 18:27:09 +0200 > Daniel Vetter wrote: > >> On Wed, Sep 8, 2021 at 9:36 AM Pekka Paalanen >> wrote: >>> >>> On Tue, 7 Sep 2021 14:42:56 +0200 >>> Hans de Goede wrote: >>> Hi, On 9/7/21 12:07 PM, Pekka Paalanen wrote: > On Fri, 3 Sep 2021 21:08:21 +0200 > Dennis Filder wrote: > >> Hans de Goede asked me to take a topic from a private discussion >> here. >> I must also preface that I'm not a graphics person and my knowledge >> of >> DRI/DRM is cursory at best. >> >> I initiated the conversation with de Goede after learning that the X >> server now supports being started with an open DRM file descriptor >> (this was added for Keith Packard's xlease project). I wondered if >> that could be used to smoothen the Plymouth->X transition somehow and >> asked de Goede if there were any such plans. He denied, but >> mentioned >> that a new ioctl is in the works to prevent the kernel from wiping >> the >> contents of a frame buffer after a device is closed, and that this >> would help to keep transitions smooth. > > Hi, > > I believe the kernel is not wiping anything on device close. If > something in the KMS state is wiped, it originates in userspace: > > - Plymouth doing something (e.g. RmFB on an in-use FB will turn the > output off, you need to be careful to "leak" your FB if you want a > smooth hand-over) The "kernel is not wiping anything on device close" is not true, when closing /dev/dri/card# any remaining FBs from the app closing it will be dealt with as if they were RmFB-ed, causing the screen to show what I call "the fallback fb", at least with the i915 driver. >>> >>> No, that's not what should happen AFAIK. >>> >>> True, all FBs that are not referenced by active CRTCs or planes will >>> get freed, since their refcount drops to zero, but those CRTCs and >>> planes that are active will remain active and therefore keep their >>> reference to the respective FBs and so the FBs remain until replaced or >>> turned off explicitly (by e.g. fbcon if you switch to that rather than >>> another userspace KMS client). I believe that is the whole reason why >>> e.g. DRM_IOCTL_MODE_GETFB2 can be useful, otherwise the next KMS client >>> would not have anything to scrape. >>> >>> danvet, what is the DRM core intention? >> >> Historical accidents mostly. There's two things that foil easy >> handover to the next compositor: >> - RMFB instead of CLOSEFB semantics, especially when closing the >> drmfd. This is uapi, so anything we change needs to be opt-in > > What does this mean and refer to? > > Are you trying to say, that closing the DRM device fd (freeing the file > description) causes an implicit RmFB on all the FBs tied to that DRM > device file description? > > I never realised that before. Yes, final close does iterate over fb and do an RMFB. Which is why we've had this discussion whether closefb semantics should be an ADDFB2 flag at creation time instead. >>> >>> Hi Daniel, >>> >>> such flag would make sense to me. >> >> Hmm, I was thinking having a separate call to mark a FB to switch to >> closefb semantics. But both plymouth (because of end of animation) >> and GNOME (because a mostly empty gnome-shell needs to be rendered >> to avoid leaking privacy sensitive info) will need to prepare a >> special FB on exit anyways, so then an ADDFB2 flag would work fine. >> >> I would be happy to work on the plymouth side of this, so that we >> have at least one consumer of such a flag lined up for merging. > > Right, but I'm thinking this from the other side: why would anyone > deliberately *want* RmFB semantics on device close? Device-close also happens on application crashes. So basically any time where the app (typically a display-server) may display privacy sensitive contents which we don't want to leak to other apps, we want RmFB semantics on close. ATM e.g. GNOME just leaves everything on the screen in place at logout / shutdown. So "apps" are definitely going to need to have some work done to them to make sure that from a privacy pov it is safe to leave the FB in place after they exit. > I can't think of any, and hence I would be inclined to assume that >
Re: [PATCH v3 6/6] drm/ingenic: Attach bridge chain to encoders
Hi Nikolaus,
Le jeu., sept. 23 2021 at 07:52:08 +0200, H. Nikolaus Schaller
a écrit :
Hi Paul,
thanks for another update.
We have been delayed to rework the CI20 HDMI code on top of your
series
but it basically works in some situations. There is for example a
problem
if the EDID reports DRM_COLOR_FORMAT_YCRCB422 but it appears to be
outside
of your series.
I think the SoC can output YCbCr as well, but I never tried to use it.
The only issue we have is described below.
Am 22.09.2021 um 22:55 schrieb Paul Cercueil :
Attach a top-level bridge to each encoder, which will be used for
negociating the bus format and flags.
All the bridges are now attached with
DRM_BRIDGE_ATTACH_NO_CONNECTOR.
Signed-off-by: Paul Cercueil
---
drivers/gpu/drm/ingenic/ingenic-drm-drv.c | 92
+--
1 file changed, 70 insertions(+), 22 deletions(-)
diff --git a/drivers/gpu/drm/ingenic/ingenic-drm-drv.c
b/drivers/gpu/drm/ingenic/ingenic-drm-drv.c
index a5e2880e07a1..a05a9fa6e115 100644
--- a/drivers/gpu/drm/ingenic/ingenic-drm-drv.c
+++ b/drivers/gpu/drm/ingenic/ingenic-drm-drv.c
@@ -21,6 +21,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -108,6 +109,19 @@ struct ingenic_drm {
struct drm_private_obj private_obj;
};
+struct ingenic_drm_bridge {
+ struct drm_encoder encoder;
+ struct drm_bridge bridge, *next_bridge;
+
+ struct drm_bus_cfg bus_cfg;
+};
+
+static inline struct ingenic_drm_bridge *
+to_ingenic_drm_bridge(struct drm_encoder *encoder)
+{
+ return container_of(encoder, struct ingenic_drm_bridge, encoder);
+}
+
static inline struct ingenic_drm_private_state *
to_ingenic_drm_priv_state(struct drm_private_state *state)
{
@@ -668,11 +682,10 @@ static void
ingenic_drm_encoder_atomic_mode_set(struct drm_encoder *encoder,
{
struct ingenic_drm *priv = drm_device_get_priv(encoder->dev);
struct drm_display_mode *mode = &crtc_state->adjusted_mode;
- struct drm_connector *conn = conn_state->connector;
- struct drm_display_info *info = &conn->display_info;
+ struct ingenic_drm_bridge *bridge =
to_ingenic_drm_bridge(encoder);
unsigned int cfg, rgbcfg = 0;
- priv->panel_is_sharp = info->bus_flags &
DRM_BUS_FLAG_SHARP_SIGNALS;
+ priv->panel_is_sharp = bridge->bus_cfg.flags &
DRM_BUS_FLAG_SHARP_SIGNALS;
if (priv->panel_is_sharp) {
cfg = JZ_LCD_CFG_MODE_SPECIAL_TFT_1 | JZ_LCD_CFG_REV_POLARITY;
@@ -685,19 +698,19 @@ static void
ingenic_drm_encoder_atomic_mode_set(struct drm_encoder *encoder,
cfg |= JZ_LCD_CFG_HSYNC_ACTIVE_LOW;
if (mode->flags & DRM_MODE_FLAG_NVSYNC)
cfg |= JZ_LCD_CFG_VSYNC_ACTIVE_LOW;
- if (info->bus_flags & DRM_BUS_FLAG_DE_LOW)
+ if (bridge->bus_cfg.flags & DRM_BUS_FLAG_DE_LOW)
cfg |= JZ_LCD_CFG_DE_ACTIVE_LOW;
- if (info->bus_flags & DRM_BUS_FLAG_PIXDATA_DRIVE_NEGEDGE)
+ if (bridge->bus_cfg.flags & DRM_BUS_FLAG_PIXDATA_DRIVE_NEGEDGE)
cfg |= JZ_LCD_CFG_PCLK_FALLING_EDGE;
if (!priv->panel_is_sharp) {
- if (conn->connector_type == DRM_MODE_CONNECTOR_TV) {
+ if (conn_state->connector->connector_type ==
DRM_MODE_CONNECTOR_TV) {
if (mode->flags & DRM_MODE_FLAG_INTERLACE)
cfg |= JZ_LCD_CFG_MODE_TV_OUT_I;
else
cfg |= JZ_LCD_CFG_MODE_TV_OUT_P;
} else {
- switch (*info->bus_formats) {
+ switch (bridge->bus_cfg.format) {
case MEDIA_BUS_FMT_RGB565_1X16:
cfg |= JZ_LCD_CFG_MODE_GENERIC_16BIT;
break;
@@ -723,20 +736,29 @@ static void
ingenic_drm_encoder_atomic_mode_set(struct drm_encoder *encoder,
regmap_write(priv->map, JZ_REG_LCD_RGBC, rgbcfg);
}
-static int ingenic_drm_encoder_atomic_check(struct drm_encoder
*encoder,
- struct drm_crtc_state *crtc_state,
- struct drm_connector_state
*conn_state)
+static int ingenic_drm_bridge_attach(struct drm_bridge *bridge,
+ enum drm_bridge_attach_flags flags)
+{
+ struct ingenic_drm_bridge *ib =
to_ingenic_drm_bridge(bridge->encoder);
+
+ return drm_bridge_attach(bridge->encoder, ib->next_bridge,
+ &ib->bridge, flags);
+}
+
+static int ingenic_drm_bridge_atomic_check(struct drm_bridge
*bridge,
+ struct drm_bridge_state
*bridge_state,
+ struct drm_crtc_state *crtc_state,
+ struct drm_connector_state
*conn_state)
{
- struct drm_display_info *info =
&conn_state->connector->display_info;
struct drm_di
Re: [PATCH v2 3/3] drm/bridge: ti-sn65dsi86: Add NO_CONNECTOR support
Hi, On Tue, Sep 21, 2021 at 03:42:05PM -0700, Rob Clark wrote: > On Tue, Sep 21, 2021 at 3:20 PM Doug Anderson wrote: > > > > Hi, > > > > On Mon, Sep 20, 2021 at 3:53 PM Rob Clark wrote: > > > > > > From: Rob Clark > > > > > > Slightly awkward to fish out the display_info when we aren't creating > > > own connector. But I don't see an obvious better way. > > > > > > v2: Remove error return with NO_CONNECTOR flag > > > > > > Signed-off-by: Rob Clark > > > --- > > > drivers/gpu/drm/bridge/ti-sn65dsi86.c | 39 --- > > > 1 file changed, 29 insertions(+), 10 deletions(-) > > > > This seems fine to me: > > > > Reviewed-by: Douglas Anderson > > > > ...if you would like me to apply patch #2 / #3 to drm-misc-next then > > please yell. > > Thanks.. I think we can give it a few days for Laurent to have a look. > > This will conflict some with Maxime's bridge vs dsi-host ordering > series.. not sure how close that one is to the finish line, but I can > rebase either patch on top of the other depending on which order they > are applied It's probably going to take a bit of time to get merged, so don't worry about this series and just go ahead, I'll rebase it on top of yours if needed. Maxime signature.asc Description: PGP signature
Re: Handling DRM master transitions cooperatively
On Wed, 22 Sep 2021 11:21:16 +0200 Hans de Goede wrote: > Hi, > > On 9/22/21 10:56 AM, Pekka Paalanen wrote: > > On Tue, 14 Sep 2021 15:45:21 +0200 > > Daniel Vetter wrote: > > > >> On Thu, Sep 09, 2021 at 10:37:03AM +0300, Pekka Paalanen wrote: > >>> On Wed, 8 Sep 2021 18:27:09 +0200 > >>> Daniel Vetter wrote: > >>> > On Wed, Sep 8, 2021 at 9:36 AM Pekka Paalanen > wrote: > > > > On Tue, 7 Sep 2021 14:42:56 +0200 > > Hans de Goede wrote: > > > >> Hi, > >> > >> On 9/7/21 12:07 PM, Pekka Paalanen wrote: > >>> On Fri, 3 Sep 2021 21:08:21 +0200 > >>> Dennis Filder wrote: > >>> > Hans de Goede asked me to take a topic from a private discussion > here. > I must also preface that I'm not a graphics person and my knowledge > of > DRI/DRM is cursory at best. > > I initiated the conversation with de Goede after learning that the X > server now supports being started with an open DRM file descriptor > (this was added for Keith Packard's xlease project). I wondered if > that could be used to smoothen the Plymouth->X transition somehow and > asked de Goede if there were any such plans. He denied, but > mentioned > that a new ioctl is in the works to prevent the kernel from wiping > the > contents of a frame buffer after a device is closed, and that this > would help to keep transitions smooth. > >>> > >>> Hi, > >>> > >>> I believe the kernel is not wiping anything on device close. If > >>> something in the KMS state is wiped, it originates in userspace: > >>> > >>> - Plymouth doing something (e.g. RmFB on an in-use FB will turn the > >>> output off, you need to be careful to "leak" your FB if you want a > >>> smooth hand-over) > >> > >> The "kernel is not wiping anything on device close" is not true, > >> when closing /dev/dri/card# any remaining FBs from the app closing > >> it will be dealt with as if they were RmFB-ed, causing the screen > >> to show what I call "the fallback fb", at least with the i915 driver. > >> > > > > No, that's not what should happen AFAIK. > > > > True, all FBs that are not referenced by active CRTCs or planes will > > get freed, since their refcount drops to zero, but those CRTCs and > > planes that are active will remain active and therefore keep their > > reference to the respective FBs and so the FBs remain until replaced or > > turned off explicitly (by e.g. fbcon if you switch to that rather than > > another userspace KMS client). I believe that is the whole reason why > > e.g. DRM_IOCTL_MODE_GETFB2 can be useful, otherwise the next KMS client > > would not have anything to scrape. > > > > danvet, what is the DRM core intention? > > Historical accidents mostly. There's two things that foil easy > handover to the next compositor: > - RMFB instead of CLOSEFB semantics, especially when closing the > drmfd. This is uapi, so anything we change needs to be opt-in > >>> > >>> What does this mean and refer to? > >>> > >>> Are you trying to say, that closing the DRM device fd (freeing the file > >>> description) causes an implicit RmFB on all the FBs tied to that DRM > >>> device file description? > >>> > >>> I never realised that before. > >> > >> Yes, final close does iterate over fb and do an RMFB. Which is why we've > >> had this discussion whether closefb semantics should be an ADDFB2 flag at > >> creation time instead. > > > > Hi Daniel, > > > > such flag would make sense to me. > > Hmm, I was thinking having a separate call to mark a FB to switch to > closefb semantics. But both plymouth (because of end of animation) > and GNOME (because a mostly empty gnome-shell needs to be rendered > to avoid leaking privacy sensitive info) will need to prepare a > special FB on exit anyways, so then an ADDFB2 flag would work fine. > > I would be happy to work on the plymouth side of this, so that we > have at least one consumer of such a flag lined up for merging. Right, but I'm thinking this from the other side: why would anyone deliberately *want* RmFB semantics on device close? I can't think of any, and hence I would be inclined to assume that userspace would just switch to using closefb semantics for everything all the time. Legacy userspace is one thing, but userspace that is updated to set closefb semantics will also be aware of what closefb means: it leaves the FBs up and CRTCs and planes enabled, if you leave them like that. So if they don't want that, they know they should not do that. Asking in another way: why would the same program sometimes use RmFB semantics and sometimes closefb semantics? Even more so, why would one switch an FB from one to the other? Hmm... to pr
Re: [PATCH v4 24/24] drm/exynos: dsi: Adjust probe order
Hi Maxime, On 22.09.2021 10:53, Maxime Ripard wrote: > On Fri, Sep 17, 2021 at 02:35:05PM +0200, Marek Szyprowski wrote: >> On 13.09.2021 12:30, Andrzej Hajda wrote: >>> W dniu 10.09.2021 o 12:12, Maxime Ripard pisze: Without proper care and an agreement between how DSI hosts and devices drivers register their MIPI-DSI entities and potential components, we can end up in a situation where the drivers can never probe. Most drivers were taking evasive maneuvers to try to workaround this, but not all of them were following the same conventions, resulting in various incompatibilities between DSI hosts and devices. Now that we have a sequence agreed upon and documented, let's convert exynos to it. Signed-off-by: Maxime Ripard >>> This patch should be dropped, as it will probably break the driver. >>> >>> Exynos is already compatible with the pattern >>> register-bus-then-get-sink, but it adds/removes panel/bridge >>> dynamically, so it creates drm_device without waiting for downstream sink. >> Right, this patch breaks Exynos DSI driver operation. Without it, the >> whole series works fine on all Exynos based test boards. > Thanks for testing. Did you have any board using one of those bridges in > your test sample? Nope, the only bridges I've tested are tc358764 and exynos-mic. However, both are used in a bit special way. The rest of my test boards just have a dsi panel. Best regards -- Marek Szyprowski, PhD Samsung R&D Institute Poland
Re: [RFC PATCH v3 1/6] drm/doc: Color Management and HDR10 RFC
On Wed, 22 Sep 2021 11:06:53 -0400 Harry Wentland wrote: > On 2021-09-20 20:14, Harry Wentland wrote: > > On 2021-09-15 10:01, Pekka Paalanen wrote:> On Fri, 30 Jul 2021 16:41:29 > > -0400 > >> Harry Wentland wrote: > >> > > > > >>> +If a display's maximum HDR white level is correctly reported it is > >>> trivial > >>> +to convert between all of the above representations of SDR white level. > >>> If > >>> +it is not, defining SDR luminance as a nits value, or a ratio vs a fixed > >>> +nits value is preferred, assuming we are blending in linear space. > >>> + > >>> +It is our experience that many HDR displays do not report maximum white > >>> +level correctly > >> > >> Which value do you refer to as "maximum white", and how did you measure > >> it? > >> > > Good question. I haven't played with those displays myself but I'll try to > > find out a bit more background behind this statement. > > > > > Some TVs report the EOTF but not the luminance values. > For an example edid-code capture of my eDP HDR panel: > > HDR Static Metadata Data Block: > Electro optical transfer functions: > Traditional gamma - SDR luminance range > SMPTE ST2084 > Supported static metadata descriptors: > Static metadata type 1 > Desired content max luminance: 115 (603.666 cd/m^2) > Desired content max frame-average luminance: 109 (530.095 cd/m^2) > Desired content min luminance: 7 (0.005 cd/m^2) > I forget where I heard (you, Vitaly, someone?) that integrated panels may not have the magic gamut and tone mapping hardware, which means that software (or display engine) must do the full correct thing. That's another reason to not rely on magic display functionality, which suits my plans perfectly. > I suspect on those TVs it looks like this: > > HDR Static Metadata Data Block: > Electro optical transfer functions: > Traditional gamma - SDR luminance range > SMPTE ST2084 > Supported static metadata descriptors: > Static metadata type 1 > > Windows has some defaults in this case and our Windows driver also has > some defaults. Oh, missing information. Yay. > Using defaults in the 1000-2000 nits range would yield much better > tone-mapping results than assuming the monitor can support a full > 10k nits. Obviously. > As an aside, recently we've come across displays where the max > average luminance is higher than the max peak luminance. This is > not a mistake but due to how the display's dimming zones work. IOW, the actual max peak luminance in absolute units depends on the current image average luminance. Wonderful, but what am I (the content producer, the display server) supposed to do with that information... > Not sure what impact this might have on tone-mapping, other than > to keep in mind that we can assume that max_avg < max_peak. *cannot Seems like it would lead to a very different tone mapping algorithm which needs to compute the image average luminance before it can account for max peak luminance (which I wouldn't know how to infer). So either a two-pass algorithm, or taking the average from the previous frame. I imagine that is going to be fun considering one needs to composite different types of input images together, and the final tone mapping might need to differ for each. Strictly thinking that might lead to an iterative optimisation algorithm which would be quite intractable in practise to complete for a single frame at a time. Thanks, pq pgpFlUwkDGCZp.pgp Description: OpenPGP digital signature
Re: [PATCH v8 10/16] i915/gvt: remove spaces in pr_debug "gvt: core:" etc prefixes
On 2021.09.15 10:39:51 -0600, Jim Cromie wrote:
> Taking embedded spaces out of existing prefixes makes them better
> class-prefixes; simplifying the extra quoting needed otherwise:
>
> $> echo format "^gvt: core:" +p >control
>
> Dropping the internal spaces means any trailing space in a query will
> more clearly terminate the prefix being searched for.
>
> Consider a generic drm-debug example:
>
> # turn off ATOMIC reports
> echo format "^drm:atomic: " -p > control
>
> # turn off all ATOMIC:* reports, including any sub-categories
> echo format "^drm:atomic:" -p > control
>
> # turn on ATOMIC:FAIL: reports
> echo format "^drm:atomic:fail: " +p > control
>
> Removing embedded spaces in the class-prefixes simplifies the
> corresponding match-prefix. This means that "quoted" match-prefixes
> are only needed when the trailing space is desired, in order to
> exclude explicitly sub-categorized pr-debugs; in this example,
> "drm:atomic:fail:".
>
> RFC: maybe the prefix catenation should paste in the " " class-prefix
> terminator explicitly. A pr_debug_() flavor could exclude the " ",
> allowing ad-hoc sub-categorization by appending for example, "fail:"
> to "drm:atomic:" without the default " " insertion.
>
> Signed-off-by: Jim Cromie
> ---
> v8:
> . fix patchwork CI warning
> ---
> drivers/gpu/drm/i915/gvt/debug.h | 18 +-
> 1 file changed, 9 insertions(+), 9 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/gvt/debug.h
> b/drivers/gpu/drm/i915/gvt/debug.h
> index c6027125c1ec..bbecc279e077 100644
> --- a/drivers/gpu/drm/i915/gvt/debug.h
> +++ b/drivers/gpu/drm/i915/gvt/debug.h
> @@ -36,30 +36,30 @@ do {
> \
> } while (0)
>
> #define gvt_dbg_core(fmt, args...) \
> - pr_debug("gvt: core: "fmt, ##args)
> + pr_debug("gvt:core: " fmt, ##args)
>
> #define gvt_dbg_irq(fmt, args...) \
> - pr_debug("gvt: irq: "fmt, ##args)
> + pr_debug("gvt:irq: " fmt, ##args)
>
> #define gvt_dbg_mm(fmt, args...) \
> - pr_debug("gvt: mm: "fmt, ##args)
> + pr_debug("gvt:mm: " fmt, ##args)
>
> #define gvt_dbg_mmio(fmt, args...) \
> - pr_debug("gvt: mmio: "fmt, ##args)
> + pr_debug("gvt:mmio: " fmt, ##args)
>
> #define gvt_dbg_dpy(fmt, args...) \
> - pr_debug("gvt: dpy: "fmt, ##args)
> + pr_debug("gvt:dpy: " fmt, ##args)
>
> #define gvt_dbg_el(fmt, args...) \
> - pr_debug("gvt: el: "fmt, ##args)
> + pr_debug("gvt:el: " fmt, ##args)
>
> #define gvt_dbg_sched(fmt, args...) \
> - pr_debug("gvt: sched: "fmt, ##args)
> + pr_debug("gvt:sched: " fmt, ##args)
>
> #define gvt_dbg_render(fmt, args...) \
> - pr_debug("gvt: render: "fmt, ##args)
> + pr_debug("gvt:render: " fmt, ##args)
>
> #define gvt_dbg_cmd(fmt, args...) \
> - pr_debug("gvt: cmd: "fmt, ##args)
> + pr_debug("gvt:cmd: " fmt, ##args)
>
> #endif
> --
Looks good to me. Thanks!
Reviewed-by: Zhenyu Wang
signature.asc
Description: PGP signature
[PULL] drm-misc-next
Hi Dave, Daniel,
Here's this week PR for drm-misc-next
Maxime
drm-misc-next-2021-09-23:
drm-misc-next for 5.15:
UAPI Changes:
Cross-subsystem Changes:
Core Changes:
Driver Changes:
- Conversions to dev_err_probe() helper
- rockchip: Various build improvements, Use
DRM_BRIDGE_ATTACH_NO_CONNECTOR for LVDS and RGB
- panel: New panel-edp driver
The following changes since commit e4f868191138975f2fdf2f37c11318b47db4acc9:
drm/v3d: fix wait for TMU write combiner flush (2021-09-15 18:43:37 +0100)
are available in the Git repository at:
git://anongit.freedesktop.org/drm/drm-misc tags/drm-misc-next-2021-09-23
for you to fetch changes up to 9c2fce137852e6434ca0c6fe3d75e00feb168c07:
drm: Fix scaling_mode docs (2021-09-22 22:11:53 +0300)
drm-misc-next for 5.15:
UAPI Changes:
Cross-subsystem Changes:
Core Changes:
Driver Changes:
- Conversions to dev_err_probe() helper
- rockchip: Various build improvements, Use
DRM_BRIDGE_ATTACH_NO_CONNECTOR for LVDS and RGB
- panel: New panel-edp driver
Alex Bee (3):
drm: bridge: it66121: Fix return value it66121_probe
drm/rockchip: handle non-platform devices in
rockchip_drm_endpoint_is_subdriver
drm/rockchip: add DRM_BRIDGE_ATTACH_NO_CONNECTOR flag to drm_bridge_attach
Alex Deucher (1):
MAINTAINERS: add Andrey as the DRM GPU scheduler maintainer
Andy Yan (1):
drm/rockchip: Check iommu itself instead of it's parent for
device_is_available
Brian Norris (1):
drm/rockchip: remove unused psr_list{,_lock}
Cai Huoqing (4):
drm/sun4i: dsi: Make use of the helper function dev_err_probe()
drm/sun4i: dw-hdmi: Make use of the helper function dev_err_probe()
drm/v3d: Make use of the helper function
devm_platform_ioremap_resource_byname()
drm/rockchip: Make use of the helper function
devm_platform_ioremap_resource()
Douglas Anderson (15):
dt-bindings: drm/panel-simple-edp: Introduce generic eDP panels
drm/edid: Break out reading block 0 of the EDID
drm/edid: Allow querying/working with the panel ID from the EDID
drm/edid: Use new encoded panel id style for quirks matching
ARM: configs: Everyone who had PANEL_SIMPLE now gets PANEL_EDP
arm64: defconfig: Everyone who had PANEL_SIMPLE now gets PANEL_EDP
drm/panel-edp: Split eDP panels out of panel-simple
drm/panel-edp: Move some wayward panels to the eDP driver
drm/panel-simple: Non-eDP panels don't need "HPD" handling
drm/panel-edp: Split the delay structure out
drm/panel-edp: Better describe eDP panel delays
drm/panel-edp: hpd_reliable shouldn't be subtraced from hpd_absent
drm/panel-edp: Fix "prepare_to_enable" if panel doesn't handle HPD
drm/panel-edp: Don't re-read the EDID every time we power off the panel
drm/panel-edp: Implement generic "edp-panel"s probed by EDID
Jiapeng Chong (3):
panfrost: make mediatek_mt8183_supplies and mediatek_mt8183_pm_domains
static
drm/rockchip: dsi: Fix duplicate included linux/phy/phy.h
drm/rockchip: dsi: make hstt_table static
Lukas Bulwahn (1):
MAINTAINERS: fix typo in DRM DRIVER FOR SAMSUNG S6D27A1 PANELS
Maxime Ripard (1):
drm/bridge: Move devm_drm_of_get_bridge to bridge/panel.c
Melissa Wen (1):
drm/v3d: fix sched job resources cleanup when a job is aborted
Souptick Joarder (2):
drm/rockchip: remove of_match_ptr() from vop_driver_dt_match
drm/rockchip: remove of_match_ptr() from analogix dp driver
Steven Price (1):
drm/panfrost: Calculate lock region size correctly
Ville Syrjälä (1):
drm: Fix scaling_mode docs
Wolfram Sang (1):
drm/panfrost: simplify getting .driver_data
liuyuntao (1):
virtio-gpu: fix possible memory allocation failure
.../bindings/display/panel/panel-edp.yaml | 188 ++
MAINTAINERS| 10 +-
arch/arm/configs/at91_dt_defconfig |1 +
arch/arm/configs/exynos_defconfig |1 +
arch/arm/configs/imx_v6_v7_defconfig |1 +
arch/arm/configs/lpc32xx_defconfig |1 +
arch/arm/configs/multi_v5_defconfig|1 +
arch/arm/configs/multi_v7_defconfig|1 +
arch/arm/configs/omap2plus_defconfig |1 +
arch/arm/configs/qcom_defconfig|1 +
arch/arm/configs/realview_defconfig|1 +
arch/arm/configs/sama5_defconfig |1 +
arch/arm/configs/shmobile_defconfig|1 +
arch/arm/configs/sunxi_defconfig |1 +
arch/arm/configs/tegra_defconfig |1 +
arch/arm/configs/versatile_defconfig |1 +
arch/arm/configs/vexpress_defconfig|1 +
arch/arm64/configs/defconfig
