Re: [PATCH] drm/debugfs: Fix drm_debugfs_remove_files() stub
Am 14.09.23 um 01:30 schrieb Nathan Chancellor:
When building without CONFIG_DEBUG_FS:
drivers/gpu/drm/tegra/dc.c:1757:59: error: too many arguments to function
call, expected 3, have 4
1757 | drm_debugfs_remove_files(dc->debugfs_files, count, root,
minor);
|
^
include/drm/drm_debugfs.h:162:19: note: 'drm_debugfs_remove_files' declared
here
162 | static inline int drm_debugfs_remove_files(const struct
drm_info_list *files,
| ^
~~
163 |int count, struct
drm_minor *minor)
|
~~
1 error generated.
Update the stub to include the root parameter.
Fixes: 8e455145d8f1 ("drm/debugfs: rework drm_debugfs_create_files implementation
v2")
Signed-off-by: Nathan Chancellor
Reviewed and pushed to drm-misc-next.
Sorry for the noise, I didn't tested the latest version of the patch
without CONFIG_DEBUG_FS.
Regards,
Christian.
---
include/drm/drm_debugfs.h | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/include/drm/drm_debugfs.h b/include/drm/drm_debugfs.h
index 7213ce15e4ff..3bba169f9bae 100644
--- a/include/drm/drm_debugfs.h
+++ b/include/drm/drm_debugfs.h
@@ -160,7 +160,8 @@ static inline void drm_debugfs_create_files(const struct
drm_info_list *files,
{}
static inline int drm_debugfs_remove_files(const struct drm_info_list *files,
- int count, struct drm_minor *minor)
+ int count, struct dentry *root,
+ struct drm_minor *minor)
{
return 0;
}
---
base-commit: fc71f615fd08a530d24c7af0a1efa72ec6ea8e34
change-id: 20230913-fix-drm_debugfs_remove_files-stub-bd864127c162
Best regards,
[PATCH v3 10/12] drm/msm/dpu: create additional virtual planes
Since we have enabled sharing of SSPP blocks between two planes, it is
now possible to use twice as much planes as there are hardware SSPP
blocks. Create additional overlay planes.
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c | 12
1 file changed, 12 insertions(+)
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c
b/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c
index 5106abe366a3..a6cd1346b298 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c
@@ -792,6 +792,18 @@ static int _dpu_kms_drm_obj_init(struct dpu_kms *dpu_kms)
primary_planes[primary_planes_idx++] = plane;
}
+ if (dpu_use_virtual_planes) {
+ for (i = 0; i < catalog->sspp_count; i++) {
+ plane = dpu_plane_init_virtual(dev,
DRM_PLANE_TYPE_OVERLAY,
+ (1UL << max_crtc_count)
- 1);
+ if (IS_ERR(plane)) {
+ DPU_ERROR("dpu_plane_init failed\n");
+ ret = PTR_ERR(plane);
+ return ret;
+ }
+ }
+ }
+
max_crtc_count = min(max_crtc_count, primary_planes_idx);
/* Create one CRTC per encoder */
--
2.39.2
[PATCH v3 00/12] drm/msm/dpu: support virtual wide planes
As promised in the basic wide planes support ([1]) here comes a series supporting 2*max_linewidth for all the planes. Note: Unlike v1 and v2 this series finally includes support for additional planes - having more planes than the number of SSPP blocks. Note: this iteration features handling of rotation and reflection of the wide plane. However rot90 is still not tested: it is enabled on sc7280 and it only supports UBWC (tiled) framebuffers, it was quite low on my priority list. [1] https://patchwork.freedesktop.org/series/99909/ Changes since v2: - Dropped the encoder-related parts, leave all resource allocation as is (Abhinav) - Significantly reworked the SSPP allocation code - Added debugging code to dump RM state in dri/N/state Changes since v1: - Fixed build error due to me missing one of fixups, it was left uncommitted. - Implementated proper handling of wide plane rotation & reflection. Dmitry Baryshkov (12): drm/atomic-helper: split not-scaling part of drm_atomic_helper_check_plane_state drm/msm/dpu: add current resource allocation to dumped state drm/msm/dpu: take plane rotation into account for wide planes drm/msm/dpu: move pstate->pipe initialization to dpu_plane_atomic_check drm/msm/dpu: split dpu_plane_atomic_check() drm/msm/dpu: move rot90 checking to dpu_plane_atomic_check_pipe() drm/msm/dpu: add support for virtual planes drm/msm/dpu: allow using two SSPP blocks for a single plane drm/msm/dpu: allow sharing SSPP between planes drm/msm/dpu: create additional virtual planes drm/msm/dpu: allow sharing of blending stages drm/msm/dpu: include SSPP allocation state into the dumped state drivers/gpu/drm/drm_atomic_helper.c | 110 +++- drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c| 59 +- drivers/gpu/drm/msm/disp/dpu1/dpu_hw_sspp.h | 2 + drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c | 26 +- drivers/gpu/drm/msm/disp/dpu1/dpu_kms.h | 6 + drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c | 671 drivers/gpu/drm/msm/disp/dpu1/dpu_plane.h | 29 +- drivers/gpu/drm/msm/disp/dpu1/dpu_rm.c | 130 drivers/gpu/drm/msm/disp/dpu1/dpu_rm.h | 36 ++ include/drm/drm_atomic_helper.h | 7 + 10 files changed, 924 insertions(+), 152 deletions(-) -- 2.39.2
[PATCH v3 12/12] drm/msm/dpu: include SSPP allocation state into the dumped state
Make dpu_rm_print_state() also output the SSPP allocation state. Signed-off-by: Dmitry Baryshkov --- drivers/gpu/drm/msm/disp/dpu1/dpu_rm.c | 8 1 file changed, 8 insertions(+) diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_rm.c b/drivers/gpu/drm/msm/disp/dpu1/dpu_rm.c index 1b0166bc9bee..e7c142bebab1 100644 --- a/drivers/gpu/drm/msm/disp/dpu1/dpu_rm.c +++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_rm.c @@ -773,4 +773,12 @@ void dpu_rm_print_state(struct drm_printer *p, else drm_puts(p, " -,"); drm_puts(p, "\n"); + + drm_puts(p, "sspp:"); + for (i = 0; i < ARRAY_SIZE(global_state->sspp_to_crtc_id); i++) + if (rm->hw_sspp[i]) + drm_printf(p, " %d,", global_state->sspp_to_crtc_id[i]); + else + drm_puts(p, " -,"); + drm_puts(p, "\n"); } -- 2.39.2
[PATCH v3 11/12] drm/msm/dpu: allow sharing of blending stages
It is possible to slightly bend the limitations of the HW blender. If
two rectangles are contiguous (like two rectangles of a single plane)
they can be blended using a single LM blending stage, allowing one to
blend more planes via a single LM.
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c | 9 --
drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c | 37 ++-
2 files changed, 37 insertions(+), 9 deletions(-)
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c
b/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c
index df4c2e503fa5..4b5b2b7ed494 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c
@@ -456,6 +456,7 @@ static void _dpu_crtc_blend_setup_mixer(struct drm_crtc
*crtc,
uint32_t lm_idx;
bool bg_alpha_enable = false;
+ unsigned int stage_indices[DPU_STAGE_MAX] = {};
DECLARE_BITMAP(fetch_active, SSPP_MAX);
memset(fetch_active, 0, sizeof(fetch_active));
@@ -480,7 +481,9 @@ static void _dpu_crtc_blend_setup_mixer(struct drm_crtc
*crtc,
mixer, cstate->num_mixers,
pstate->stage,
format, fb ? fb->modifier : 0,
- >pipe, 0, stage_cfg);
+ >pipe,
+ stage_indices[pstate->stage]++,
+ stage_cfg);
if (pstate->r_pipe.sspp) {
set_bit(pstate->r_pipe.sspp->idx, fetch_active);
@@ -488,7 +491,9 @@ static void _dpu_crtc_blend_setup_mixer(struct drm_crtc
*crtc,
mixer, cstate->num_mixers,
pstate->stage,
format, fb ? fb->modifier :
0,
- >r_pipe, 1,
stage_cfg);
+ >r_pipe,
+
stage_indices[pstate->stage]++,
+ stage_cfg);
}
/* blend config update */
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c
b/drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c
index 61afd1cf033d..e7a157feab22 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c
@@ -809,13 +809,6 @@ static int dpu_plane_atomic_check_nopipe(struct drm_plane
*plane,
if (!new_plane_state->visible)
return 0;
- pstate->stage = DPU_STAGE_0 + pstate->base.normalized_zpos;
- if (pstate->stage >= pdpu->catalog->caps->max_mixer_blendstages) {
- DPU_ERROR("> %d plane stages assigned\n",
- pdpu->catalog->caps->max_mixer_blendstages -
DPU_STAGE_0);
- return -EINVAL;
- }
-
fb_rect.x2 = new_plane_state->fb->width;
fb_rect.y2 = new_plane_state->fb->height;
@@ -952,6 +945,18 @@ static int dpu_plane_try_multirect(struct dpu_plane_state
*pstate,
prev_pipe->multirect_index = DPU_SSPP_RECT_0;
prev_pipe->multirect_mode = DPU_SSPP_MULTIRECT_PARALLEL;
+ if (pipe_cfg->dst_rect.y1 == prev_pipe_cfg->dst_rect.y1 &&
+ pipe_cfg->dst_rect.y2 == prev_pipe_cfg->dst_rect.y2 &&
+ pipe_cfg->dst_rect.x1 == prev_pipe_cfg->dst_rect.x2) {
+ pstate->stage = prev_pstate->stage;
+ } else if (pipe_cfg->dst_rect.y1 == prev_pipe_cfg->dst_rect.y1
&&
+ pipe_cfg->dst_rect.y2 == prev_pipe_cfg->dst_rect.y2
&&
+ pipe_cfg->dst_rect.x2 == prev_pipe_cfg->dst_rect.x1)
{
+ pstate->stage = prev_pstate->stage;
+ pipe->multirect_index = DPU_SSPP_RECT_0;
+ prev_pipe->multirect_index = DPU_SSPP_RECT_1;
+ }
+
return true;
}
@@ -1054,6 +1059,13 @@ static int dpu_plane_atomic_check(struct drm_plane
*plane,
if (!new_plane_state->visible)
return 0;
+ pstate->stage = DPU_STAGE_0 + pstate->base.normalized_zpos;
+ if (pstate->stage >= pdpu->catalog->caps->max_mixer_blendstages) {
+ DPU_ERROR("> %d plane stages assigned\n",
+ pdpu->catalog->caps->max_mixer_blendstages -
DPU_STAGE_0);
+ return -EINVAL;
+ }
+
pipe->multirect_index = DPU_SSPP_RECT_SOLO;
pipe->multirect_mode = DPU_SSPP_MULTIRECT_NONE;
r_pipe->multirect_index = DPU_SSPP_RECT_SOLO;
@@ -1189,6 +1201,11 @@ static int dpu_plane_virtual_assign_resources(struct
drm_crtc *crtc,
max_linewidth = dpu_kms->catalog->caps->max_linewidth;
+ if (prev_pstate)
+
[PATCH v3 09/12] drm/msm/dpu: allow sharing SSPP between planes
Since SmartDMA planes provide two rectangles, it is possible to use them
to drive two different DRM planes, first plane getting the rect_0,
another one using rect_1 of the same SSPP. The sharing algorithm is
pretty simple, it requires that each of the planes can be driven by the
single rectangle and only consequetive planes are considered.
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c | 128 +++---
1 file changed, 112 insertions(+), 16 deletions(-)
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c
b/drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c
index 9ffbcd91661a..61afd1cf033d 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c
@@ -867,10 +867,9 @@ static int dpu_plane_atomic_check_nopipe(struct drm_plane
*plane,
return 0;
}
-static int dpu_plane_is_multirect_parallel_capable(struct dpu_sw_pipe *pipe,
- struct dpu_sw_pipe_cfg
*pipe_cfg,
- const struct dpu_format *fmt,
- uint32_t max_linewidth)
+static int dpu_plane_is_multirect_capable(struct dpu_sw_pipe *pipe,
+ struct dpu_sw_pipe_cfg *pipe_cfg,
+ const struct dpu_format *fmt)
{
if (drm_rect_width(_cfg->src_rect) !=
drm_rect_width(_cfg->dst_rect) ||
drm_rect_height(_cfg->src_rect) !=
drm_rect_height(_cfg->dst_rect))
@@ -882,6 +881,13 @@ static int dpu_plane_is_multirect_parallel_capable(struct
dpu_sw_pipe *pipe,
if (DPU_FORMAT_IS_YUV(fmt))
return false;
+ return true;
+}
+
+static int dpu_plane_is_parallel_capable(struct dpu_sw_pipe_cfg *pipe_cfg,
+const struct dpu_format *fmt,
+uint32_t max_linewidth)
+{
if (DPU_FORMAT_IS_UBWC(fmt) &&
drm_rect_width(_cfg->src_rect) > max_linewidth / 2)
return false;
@@ -889,6 +895,82 @@ static int dpu_plane_is_multirect_parallel_capable(struct
dpu_sw_pipe *pipe,
return true;
}
+static int dpu_plane_is_multirect_parallel_capable(struct dpu_sw_pipe *pipe,
+ struct dpu_sw_pipe_cfg
*pipe_cfg,
+ const struct dpu_format *fmt,
+ uint32_t max_linewidth)
+{
+ return dpu_plane_is_multirect_capable(pipe, pipe_cfg, fmt) &&
+ dpu_plane_is_parallel_capable(pipe_cfg, fmt, max_linewidth);
+}
+
+
+static int dpu_plane_try_multirect(struct dpu_plane_state *pstate,
+ struct dpu_plane_state *prev_pstate,
+ const struct dpu_format *fmt,
+ uint32_t max_linewidth)
+{
+ struct dpu_sw_pipe *pipe = >pipe;
+ struct dpu_sw_pipe *r_pipe = >r_pipe;
+ struct dpu_sw_pipe_cfg *pipe_cfg = >pipe_cfg;
+ struct dpu_sw_pipe *prev_pipe = _pstate->pipe;
+ struct dpu_sw_pipe_cfg *prev_pipe_cfg = _pstate->pipe_cfg;
+ const struct dpu_format *prev_fmt =
+ to_dpu_format(msm_framebuffer_format(prev_pstate->base.fb));
+ u16 max_tile_height = 1;
+
+ if (prev_pstate->r_pipe.sspp != NULL ||
+ prev_pipe->multirect_mode != DPU_SSPP_MULTIRECT_NONE)
+ return false;
+
+ if (!dpu_plane_is_multirect_capable(pipe, pipe_cfg, fmt) ||
+ !dpu_plane_is_multirect_capable(prev_pipe, prev_pipe_cfg, prev_fmt)
||
+ !(test_bit(DPU_SSPP_SMART_DMA_V1, _pipe->sspp->cap->features)
||
+ test_bit(DPU_SSPP_SMART_DMA_V2, _pipe->sspp->cap->features)))
+ return false;
+
+ if (DPU_FORMAT_IS_UBWC(fmt))
+ max_tile_height = max(max_tile_height, fmt->tile_height);
+
+ if (DPU_FORMAT_IS_UBWC(prev_fmt))
+ max_tile_height = max(max_tile_height, prev_fmt->tile_height);
+
+ r_pipe->multirect_index = DPU_SSPP_RECT_SOLO;
+ r_pipe->multirect_mode = DPU_SSPP_MULTIRECT_NONE;
+
+ r_pipe->sspp = NULL;
+
+ if (dpu_plane_is_parallel_capable(pipe_cfg, fmt, max_linewidth) &&
+ dpu_plane_is_parallel_capable(prev_pipe_cfg, prev_fmt,
max_linewidth) &&
+ (pipe_cfg->dst_rect.x1 >= prev_pipe_cfg->dst_rect.x2 ||
+prev_pipe_cfg->dst_rect.x1 >= pipe_cfg->dst_rect.x2)) {
+ pipe->sspp = prev_pipe->sspp;
+
+ pipe->multirect_index = DPU_SSPP_RECT_1;
+ pipe->multirect_mode = DPU_SSPP_MULTIRECT_PARALLEL;
+
+ prev_pipe->multirect_index = DPU_SSPP_RECT_0;
+ prev_pipe->multirect_mode = DPU_SSPP_MULTIRECT_PARALLEL;
+
+ return true;
+ }
+
+ if (pipe_cfg->dst_rect.y1 >= prev_pipe_cfg->dst_rect.y2 + 2 *
max_tile_height ||
+
[PATCH v3 06/12] drm/msm/dpu: move rot90 checking to dpu_plane_atomic_check_pipe()
Move a call to dpu_plane_check_inline_rotation() to the
dpu_plane_atomic_check_pipe() function, so that the rot90 constraints
are checked for both pipes. Also move rotation field from struct
dpu_plane_state to struct dpu_sw_pipe_cfg.
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/msm/disp/dpu1/dpu_hw_sspp.h | 2 +
drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c | 55 +++--
drivers/gpu/drm/msm/disp/dpu1/dpu_plane.h | 2 -
3 files changed, 31 insertions(+), 28 deletions(-)
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_sspp.h
b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_sspp.h
index cbf4f95ff0fd..21b0c5a13ba8 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_sspp.h
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_sspp.h
@@ -157,10 +157,12 @@ struct dpu_hw_pixel_ext {
* @src_rect: src ROI, caller takes into account the different operations
* such as decimation, flip etc to program this field
* @dest_rect: destination ROI.
+ * @rotation: simplified drm rotation hint
*/
struct dpu_sw_pipe_cfg {
struct drm_rect src_rect;
struct drm_rect dst_rect;
+ unsigned int rotation;
};
/**
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c
b/drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c
index 4b1fbe9dbb3f..4cf69f93b44f 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c
@@ -527,8 +527,7 @@ static const struct dpu_csc_cfg *_dpu_plane_get_csc(struct
dpu_sw_pipe *pipe,
static void _dpu_plane_setup_scaler(struct dpu_sw_pipe *pipe,
const struct dpu_format *fmt, bool color_fill,
- struct dpu_sw_pipe_cfg *pipe_cfg,
- unsigned int rotation)
+ struct dpu_sw_pipe_cfg *pipe_cfg)
{
struct dpu_hw_sspp *pipe_hw = pipe->sspp;
const struct drm_format_info *info =
drm_format_info(fmt->base.pixel_format);
@@ -551,7 +550,7 @@ static void _dpu_plane_setup_scaler(struct dpu_sw_pipe
*pipe,
dst_height,
_cfg, fmt,
info->hsub, info->vsub,
- rotation);
+ pipe_cfg->rotation);
/* configure pixel extension based on scalar config */
_dpu_plane_setup_pixel_ext(_cfg, _ext,
@@ -603,7 +602,7 @@ static void _dpu_plane_color_fill_pipe(struct
dpu_plane_state *pstate,
if (pipe->sspp->ops.setup_rects)
pipe->sspp->ops.setup_rects(pipe, _cfg);
- _dpu_plane_setup_scaler(pipe, fmt, true, _cfg, pstate->rotation);
+ _dpu_plane_setup_scaler(pipe, fmt, true, _cfg);
}
/**
@@ -703,12 +702,17 @@ static void dpu_plane_cleanup_fb(struct drm_plane *plane,
}
static int dpu_plane_check_inline_rotation(struct dpu_plane *pdpu,
- const struct dpu_sspp_sub_blks
*sblk,
- struct drm_rect src, const
struct dpu_format *fmt)
+ struct dpu_sw_pipe *pipe,
+ struct drm_rect src,
+ const struct dpu_format *fmt)
{
+ const struct dpu_sspp_sub_blks *sblk = pipe->sspp->cap->sblk;
size_t num_formats;
const u32 *supported_formats;
+ if (!test_bit(DPU_SSPP_INLINE_ROTATION, >sspp->cap->features))
+ return -EINVAL;
+
if (!sblk->rotation_cfg) {
DPU_ERROR("invalid rotation cfg\n");
return -EINVAL;
@@ -736,6 +740,7 @@ static int dpu_plane_atomic_check_pipe(struct dpu_plane
*pdpu,
const struct dpu_format *fmt)
{
uint32_t min_src_size;
+ int ret;
min_src_size = DPU_FORMAT_IS_YUV(fmt) ? 2 : 1;
@@ -774,6 +779,12 @@ static int dpu_plane_atomic_check_pipe(struct dpu_plane
*pdpu,
return -EINVAL;
}
+ if (pipe_cfg->rotation & DRM_MODE_ROTATE_90) {
+ ret = dpu_plane_check_inline_rotation(pdpu, pipe,
pipe_cfg->src_rect, fmt);
+ if (ret)
+ return ret;
+ }
+
return 0;
}
@@ -870,7 +881,6 @@ static int dpu_plane_atomic_check_pipes(struct drm_plane
*plane,
struct dpu_sw_pipe_cfg *pipe_cfg = >pipe_cfg;
struct dpu_sw_pipe_cfg *r_pipe_cfg = >r_pipe_cfg;
uint32_t max_linewidth;
- unsigned int rotation;
uint32_t supported_rotations;
const struct dpu_sspp_cfg *pipe_hw_caps;
const struct dpu_sspp_sub_blks *sblk;
@@ -894,6 +904,15 @@ static int dpu_plane_atomic_check_pipes(struct drm_plane
*plane,
max_linewidth = pdpu->catalog->caps->max_linewidth;
+ supported_rotations = DRM_MODE_REFLECT_MASK | DRM_MODE_ROTATE_0;
+
+ if (pipe_hw_caps->features & BIT(DPU_SSPP_INLINE_ROTATION))
+ supported_rotations |= DRM_MODE_ROTATE_90;
+
+ pipe_cfg->rotation = drm_rotation_simplify(new_plane_state->rotation,
+
[PATCH v3 07/12] drm/msm/dpu: add support for virtual planes
Only several SSPP blocks support such features as YUV output or scaling,
thus different DRM planes have different features. Properly utilizing
all planes requires the attention of the compositor, who should
prefer simpler planes to YUV-supporting ones. Otherwise it is very easy
to end up in a situation when all featureful planes are already
allocated for simple windows, leaving no spare plane for YUV playback.
To solve this problem make all planes virtual. Each plane is registered
as if it supports all possible features, but then at the runtime during
the atomic_check phase the driver selects backing SSPP block for each
plane.
Note, this does not provide support for using two different SSPP blocks
for a single plane or using two rectangles of an SSPP to drive two
planes. Each plane still gets its own SSPP and can utilize either a solo
rectangle or both multirect rectangles depending on the resolution.
Note #2: By default support for virtual planes is turned off and the
driver still uses old code path with preallocated SSPP block for each
plane. To enable virtual planes, pass 'msm.dpu_use_virtual_planes=1'
kernel parameter.
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c | 50 +
drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c | 10 +-
drivers/gpu/drm/msm/disp/dpu1/dpu_kms.h | 4 +
drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c | 228 +++---
drivers/gpu/drm/msm/disp/dpu1/dpu_plane.h | 19 ++
drivers/gpu/drm/msm/disp/dpu1/dpu_rm.c| 74 +++
drivers/gpu/drm/msm/disp/dpu1/dpu_rm.h| 28 +++
7 files changed, 384 insertions(+), 29 deletions(-)
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c
b/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c
index 8ce7586e2ddf..df4c2e503fa5 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c
@@ -1179,6 +1179,49 @@ static bool dpu_crtc_needs_dirtyfb(struct drm_crtc_state
*cstate)
return false;
}
+static int dpu_crtc_reassign_planes(struct drm_crtc *crtc, struct
drm_crtc_state *crtc_state)
+{
+ int total_planes = crtc->dev->mode_config.num_total_plane;
+ struct drm_atomic_state *state = crtc_state->state;
+ struct dpu_global_state *global_state;
+ struct drm_plane_state **states;
+ struct drm_plane *plane;
+ int ret;
+
+ global_state = dpu_kms_get_global_state(crtc_state->state);
+ if (IS_ERR(global_state))
+ return PTR_ERR(global_state);
+
+ dpu_rm_release_all_sspp(global_state, crtc);
+
+ if (!crtc_state->enable)
+ return 0;
+
+ states = kcalloc(total_planes, sizeof(*states), GFP_KERNEL);
+ if (!states)
+ return -ENOMEM;
+
+ drm_atomic_crtc_state_for_each_plane(plane, crtc_state) {
+ struct drm_plane_state *plane_state =
+ drm_atomic_get_plane_state(state, plane);
+
+ if (IS_ERR(plane_state)) {
+ ret = PTR_ERR(plane_state);
+ goto done;
+ }
+
+ states[plane_state->normalized_zpos] = plane_state;
+ }
+
+ ret = dpu_assign_plane_resources(global_state, state, crtc, states,
total_planes);
+
+done:
+ kfree(states);
+ return ret;
+
+ return 0;
+}
+
static int dpu_crtc_atomic_check(struct drm_crtc *crtc,
struct drm_atomic_state *state)
{
@@ -1194,6 +1237,13 @@ static int dpu_crtc_atomic_check(struct drm_crtc *crtc,
bool needs_dirtyfb = dpu_crtc_needs_dirtyfb(crtc_state);
+ if (dpu_use_virtual_planes &&
+ (crtc_state->planes_changed || crtc_state->zpos_changed)) {
+ rc = dpu_crtc_reassign_planes(crtc, crtc_state);
+ if (rc < 0)
+ return rc;
+ }
+
if (!crtc_state->enable ||
!drm_atomic_crtc_effectively_active(crtc_state)) {
DRM_DEBUG_ATOMIC("crtc%d -> enable %d, active %d, skip
atomic_check\n",
crtc->base.id, crtc_state->enable,
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c
b/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c
index 172b64dc60e6..5106abe366a3 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c
@@ -51,6 +51,9 @@
#define DPU_DEBUGFS_DIR "msm_dpu"
#define DPU_DEBUGFS_HWMASKNAME "hw_log_mask"
+bool dpu_use_virtual_planes = false;
+module_param(dpu_use_virtual_planes, bool, 0);
+
static int dpu_kms_hw_init(struct msm_kms *kms);
static void _dpu_kms_mmu_destroy(struct dpu_kms *dpu_kms);
@@ -772,8 +775,11 @@ static int _dpu_kms_drm_obj_init(struct dpu_kms *dpu_kms)
type, catalog->sspp[i].features,
catalog->sspp[i].features & BIT(DPU_SSPP_CURSOR));
- plane = dpu_plane_init(dev, catalog->sspp[i].id, type,
- (1UL << max_crtc_count) - 1);
+ if
[PATCH v3 05/12] drm/msm/dpu: split dpu_plane_atomic_check()
Split dpu_plane_atomic_check() function into two pieces:
dpu_plane_atomic_check_nopipe() performing generic checks on the pstate,
without touching the associated pipe,
and
dpu_plane_atomic_check_pipes(), which takes into account used pipes.
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c | 178 ++
1 file changed, 112 insertions(+), 66 deletions(-)
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c
b/drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c
index 3a75c474c4cd..4b1fbe9dbb3f 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c
@@ -777,46 +777,20 @@ static int dpu_plane_atomic_check_pipe(struct dpu_plane
*pdpu,
return 0;
}
-static int dpu_plane_atomic_check(struct drm_plane *plane,
- struct drm_atomic_state *state)
+static int dpu_plane_atomic_check_nopipe(struct drm_plane *plane,
+struct drm_plane_state
*new_plane_state,
+const struct drm_crtc_state
*crtc_state)
{
- struct drm_plane_state *new_plane_state =
drm_atomic_get_new_plane_state(state,
-
plane);
- int ret = 0, min_scale;
struct dpu_plane *pdpu = to_dpu_plane(plane);
struct dpu_plane_state *pstate = to_dpu_plane_state(new_plane_state);
- struct dpu_kms *dpu_kms = _dpu_plane_get_kms(plane);
- struct dpu_sw_pipe *pipe = >pipe;
- struct dpu_sw_pipe *r_pipe = >r_pipe;
- const struct drm_crtc_state *crtc_state = NULL;
- const struct dpu_format *fmt;
struct dpu_sw_pipe_cfg *pipe_cfg = >pipe_cfg;
struct dpu_sw_pipe_cfg *r_pipe_cfg = >r_pipe_cfg;
struct drm_rect fb_rect = { 0 };
uint32_t max_linewidth;
- unsigned int rotation;
- uint32_t supported_rotations;
- const struct dpu_sspp_cfg *pipe_hw_caps;
- const struct dpu_sspp_sub_blks *sblk;
+ int ret = 0;
- if (new_plane_state->crtc)
- crtc_state = drm_atomic_get_new_crtc_state(state,
-
new_plane_state->crtc);
-
- pipe->sspp = dpu_rm_get_sspp(_kms->rm, pdpu->pipe);
- r_pipe->sspp = NULL;
-
- if (!pipe->sspp)
- return -EINVAL;
-
- pipe_hw_caps = pipe->sspp->cap;
- sblk = pipe->sspp->cap->sblk;
-
- min_scale = FRAC_16_16(1, sblk->maxupscale);
- ret = drm_atomic_helper_check_plane_state(new_plane_state, crtc_state,
- min_scale,
- sblk->maxdwnscale << 16,
- true, true);
+ ret = drm_atomic_helper_check_plane_noscale(new_plane_state, crtc_state,
+ true, true);
if (ret) {
DPU_DEBUG_PLANE(pdpu, "Check plane state failed (%d)\n", ret);
return ret;
@@ -824,11 +798,6 @@ static int dpu_plane_atomic_check(struct drm_plane *plane,
if (!new_plane_state->visible)
return 0;
- pipe->multirect_index = DPU_SSPP_RECT_SOLO;
- pipe->multirect_mode = DPU_SSPP_MULTIRECT_NONE;
- r_pipe->multirect_index = DPU_SSPP_RECT_SOLO;
- r_pipe->multirect_mode = DPU_SSPP_MULTIRECT_NONE;
-
pstate->stage = DPU_STAGE_0 + pstate->base.normalized_zpos;
if (pstate->stage >= pdpu->catalog->caps->max_mixer_blendstages) {
DPU_ERROR("> %d plane stages assigned\n",
@@ -847,8 +816,6 @@ static int dpu_plane_atomic_check(struct drm_plane *plane,
return -E2BIG;
}
- fmt = to_dpu_format(msm_framebuffer_format(new_plane_state->fb));
-
max_linewidth = pdpu->catalog->caps->max_linewidth;
/* state->src is 16.16, src_rect is not */
@@ -861,6 +828,77 @@ static int dpu_plane_atomic_check(struct drm_plane *plane,
new_plane_state->rotation);
if (drm_rect_width(_cfg->src_rect) > max_linewidth) {
+ if (drm_rect_width(_cfg->src_rect) > 2 * max_linewidth) {
+ DPU_DEBUG_PLANE(pdpu, "invalid src " DRM_RECT_FMT "
line:%u\n",
+ DRM_RECT_ARG(_cfg->src_rect),
max_linewidth);
+ return -E2BIG;
+ }
+
+ *r_pipe_cfg = *pipe_cfg;
+ pipe_cfg->src_rect.x2 = (pipe_cfg->src_rect.x1 +
pipe_cfg->src_rect.x2) >> 1;
+ pipe_cfg->dst_rect.x2 = (pipe_cfg->dst_rect.x1 +
pipe_cfg->dst_rect.x2) >> 1;
+ r_pipe_cfg->src_rect.x1 = pipe_cfg->src_rect.x2;
+ r_pipe_cfg->dst_rect.x1 = pipe_cfg->dst_rect.x2;
+ } else {
+ memset(r_pipe_cfg, 0, sizeof(*r_pipe_cfg));
+ }
+
+ drm_rect_rotate_inv(_cfg->src_rect,
+
[PATCH v3 04/12] drm/msm/dpu: move pstate->pipe initialization to dpu_plane_atomic_check
In preparation for virtualized planes support, move pstate->pipe
initialization from dpu_plane_reset() to dpu_plane_atomic_check(). In
case of virtual planes the plane's pipe will not be known up to the
point of atomic_check() callback.
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c | 26 +++
1 file changed, 12 insertions(+), 14 deletions(-)
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c
b/drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c
index 67f9c2a62a17..3a75c474c4cd 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c
@@ -785,6 +785,7 @@ static int dpu_plane_atomic_check(struct drm_plane *plane,
int ret = 0, min_scale;
struct dpu_plane *pdpu = to_dpu_plane(plane);
struct dpu_plane_state *pstate = to_dpu_plane_state(new_plane_state);
+ struct dpu_kms *dpu_kms = _dpu_plane_get_kms(plane);
struct dpu_sw_pipe *pipe = >pipe;
struct dpu_sw_pipe *r_pipe = >r_pipe;
const struct drm_crtc_state *crtc_state = NULL;
@@ -795,13 +796,22 @@ static int dpu_plane_atomic_check(struct drm_plane *plane,
uint32_t max_linewidth;
unsigned int rotation;
uint32_t supported_rotations;
- const struct dpu_sspp_cfg *pipe_hw_caps = pstate->pipe.sspp->cap;
- const struct dpu_sspp_sub_blks *sblk = pstate->pipe.sspp->cap->sblk;
+ const struct dpu_sspp_cfg *pipe_hw_caps;
+ const struct dpu_sspp_sub_blks *sblk;
if (new_plane_state->crtc)
crtc_state = drm_atomic_get_new_crtc_state(state,
new_plane_state->crtc);
+ pipe->sspp = dpu_rm_get_sspp(_kms->rm, pdpu->pipe);
+ r_pipe->sspp = NULL;
+
+ if (!pipe->sspp)
+ return -EINVAL;
+
+ pipe_hw_caps = pipe->sspp->cap;
+ sblk = pipe->sspp->cap->sblk;
+
min_scale = FRAC_16_16(1, sblk->maxupscale);
ret = drm_atomic_helper_check_plane_state(new_plane_state, crtc_state,
min_scale,
@@ -818,7 +828,6 @@ static int dpu_plane_atomic_check(struct drm_plane *plane,
pipe->multirect_mode = DPU_SSPP_MULTIRECT_NONE;
r_pipe->multirect_index = DPU_SSPP_RECT_SOLO;
r_pipe->multirect_mode = DPU_SSPP_MULTIRECT_NONE;
- r_pipe->sspp = NULL;
pstate->stage = DPU_STAGE_0 + pstate->base.normalized_zpos;
if (pstate->stage >= pdpu->catalog->caps->max_mixer_blendstages) {
@@ -1302,7 +1311,6 @@ static void dpu_plane_reset(struct drm_plane *plane)
{
struct dpu_plane *pdpu;
struct dpu_plane_state *pstate;
- struct dpu_kms *dpu_kms = _dpu_plane_get_kms(plane);
if (!plane) {
DPU_ERROR("invalid plane\n");
@@ -1324,16 +1332,6 @@ static void dpu_plane_reset(struct drm_plane *plane)
return;
}
- /*
-* Set the SSPP here until we have proper virtualized DPU planes.
-* This is the place where the state is allocated, so fill it fully.
-*/
- pstate->pipe.sspp = dpu_rm_get_sspp(_kms->rm, pdpu->pipe);
- pstate->pipe.multirect_index = DPU_SSPP_RECT_SOLO;
- pstate->pipe.multirect_mode = DPU_SSPP_MULTIRECT_NONE;
-
- pstate->r_pipe.sspp = NULL;
-
__drm_atomic_helper_plane_reset(plane, >base);
}
--
2.39.2
[PATCH v3 08/12] drm/msm/dpu: allow using two SSPP blocks for a single plane
Virtual wide planes give high amount of flexibility, but it is not
always enough:
In parallel multirect case only the half of the usual width is supported
for tiled formats. Thus the whole width of two tiled multirect
rectangles can not be greater than max_linewidth, which is not enough
for some platforms/compositors.
Another example is as simple as wide YUV plane. YUV planes can not use
multirect, so currently they are limited to max_linewidth too.
Now that the planes are fully virtualized, add support for allocating
two SSPP blocks to drive a single DRM plane. This fixes both mentioned
cases and allows all planes to go up to 2*max_linewidth (at the cost of
making some of the planes unavailable to the user).
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c | 170 --
drivers/gpu/drm/msm/disp/dpu1/dpu_plane.h | 8 +
2 files changed, 130 insertions(+), 48 deletions(-)
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c
b/drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c
index 2ac6e1074c62..9ffbcd91661a 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c
@@ -867,6 +867,28 @@ static int dpu_plane_atomic_check_nopipe(struct drm_plane
*plane,
return 0;
}
+static int dpu_plane_is_multirect_parallel_capable(struct dpu_sw_pipe *pipe,
+ struct dpu_sw_pipe_cfg
*pipe_cfg,
+ const struct dpu_format *fmt,
+ uint32_t max_linewidth)
+{
+ if (drm_rect_width(_cfg->src_rect) !=
drm_rect_width(_cfg->dst_rect) ||
+ drm_rect_height(_cfg->src_rect) !=
drm_rect_height(_cfg->dst_rect))
+ return false;
+
+ if (pipe_cfg->rotation & DRM_MODE_ROTATE_90)
+ return false;
+
+ if (DPU_FORMAT_IS_YUV(fmt))
+ return false;
+
+ if (DPU_FORMAT_IS_UBWC(fmt) &&
+ drm_rect_width(_cfg->src_rect) > max_linewidth / 2)
+ return false;
+
+ return true;
+}
+
static int dpu_plane_atomic_check_pipes(struct drm_plane *plane,
struct drm_atomic_state *state)
{
@@ -880,7 +902,6 @@ static int dpu_plane_atomic_check_pipes(struct drm_plane
*plane,
const struct dpu_format *fmt;
struct dpu_sw_pipe_cfg *pipe_cfg = >pipe_cfg;
struct dpu_sw_pipe_cfg *r_pipe_cfg = >r_pipe_cfg;
- uint32_t max_linewidth;
uint32_t supported_rotations;
const struct dpu_sspp_cfg *pipe_hw_caps;
const struct dpu_sspp_sub_blks *sblk;
@@ -895,15 +916,8 @@ static int dpu_plane_atomic_check_pipes(struct drm_plane
*plane,
if (ret)
return ret;
- pipe->multirect_index = DPU_SSPP_RECT_SOLO;
- pipe->multirect_mode = DPU_SSPP_MULTIRECT_NONE;
- r_pipe->multirect_index = DPU_SSPP_RECT_SOLO;
- r_pipe->multirect_mode = DPU_SSPP_MULTIRECT_NONE;
-
fmt = to_dpu_format(msm_framebuffer_format(new_plane_state->fb));
- max_linewidth = pdpu->catalog->caps->max_linewidth;
-
supported_rotations = DRM_MODE_REFLECT_MASK | DRM_MODE_ROTATE_0;
if (pipe_hw_caps->features & BIT(DPU_SSPP_INLINE_ROTATION))
@@ -918,40 +932,6 @@ static int dpu_plane_atomic_check_pipes(struct drm_plane
*plane,
return ret;
if (drm_rect_width(_pipe_cfg->src_rect) != 0) {
- /*
-* In parallel multirect case only the half of the usual width
-* is supported for tiled formats. If we are here, we know that
-* full width is more than max_linewidth, thus each rect is
-* wider than allowed.
-*/
- if (DPU_FORMAT_IS_UBWC(fmt)) {
- DPU_DEBUG_PLANE(pdpu, "invalid src " DRM_RECT_FMT "
line:%u, tiled format\n",
- DRM_RECT_ARG(_cfg->src_rect),
max_linewidth);
- return -E2BIG;
- }
-
- if (drm_rect_width(_cfg->src_rect) !=
drm_rect_width(_cfg->dst_rect) ||
- drm_rect_height(_cfg->src_rect) !=
drm_rect_height(_cfg->dst_rect) ||
- (!test_bit(DPU_SSPP_SMART_DMA_V1,
>sspp->cap->features) &&
-!test_bit(DPU_SSPP_SMART_DMA_V2,
>sspp->cap->features)) ||
- pipe_cfg->rotation & DRM_MODE_ROTATE_90 ||
- DPU_FORMAT_IS_YUV(fmt)) {
- DPU_DEBUG_PLANE(pdpu, "invalid src " DRM_RECT_FMT "
line:%u, can't use split source\n",
- DRM_RECT_ARG(_cfg->src_rect),
max_linewidth);
- return -E2BIG;
- }
-
- /*
-* Use multirect for wide plane. We do not support dynamic
-* assignment of SSPPs, so we know the configuration.
-*/
-
[PATCH v3 03/12] drm/msm/dpu: take plane rotation into account for wide planes
Take into account the plane rotation and flipping when calculating src
positions for the wide plane parts.
This is not an issue yet, because rotation is only supported for the
UBWC planes and wide UBWC planes are rejected anyway because in parallel
multirect case only the half of the usual width is supported for tiled
formats. However it's better to fix this now rather than stumbling upon
it later.
Fixes: 80e8ae3b38ab ("drm/msm/dpu: add support for wide planes")
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c | 27 ++-
1 file changed, 17 insertions(+), 10 deletions(-)
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c
b/drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c
index c2aaaded07ed..67f9c2a62a17 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c
@@ -827,16 +827,6 @@ static int dpu_plane_atomic_check(struct drm_plane *plane,
return -EINVAL;
}
- pipe_cfg->src_rect = new_plane_state->src;
-
- /* state->src is 16.16, src_rect is not */
- pipe_cfg->src_rect.x1 >>= 16;
- pipe_cfg->src_rect.x2 >>= 16;
- pipe_cfg->src_rect.y1 >>= 16;
- pipe_cfg->src_rect.y2 >>= 16;
-
- pipe_cfg->dst_rect = new_plane_state->dst;
-
fb_rect.x2 = new_plane_state->fb->width;
fb_rect.y2 = new_plane_state->fb->height;
@@ -852,6 +842,15 @@ static int dpu_plane_atomic_check(struct drm_plane *plane,
max_linewidth = pdpu->catalog->caps->max_linewidth;
+ /* state->src is 16.16, src_rect is not */
+ drm_rect_fp_to_int(_cfg->src_rect, _plane_state->src);
+
+ pipe_cfg->dst_rect = new_plane_state->dst;
+
+ drm_rect_rotate(_cfg->src_rect,
+ new_plane_state->fb->width, new_plane_state->fb->height,
+ new_plane_state->rotation);
+
if (drm_rect_width(_cfg->src_rect) > max_linewidth) {
/*
* In parallel multirect case only the half of the usual width
@@ -899,6 +898,14 @@ static int dpu_plane_atomic_check(struct drm_plane *plane,
r_pipe_cfg->dst_rect.x1 = pipe_cfg->dst_rect.x2;
}
+ drm_rect_rotate_inv(_cfg->src_rect,
+ new_plane_state->fb->width,
new_plane_state->fb->height,
+ new_plane_state->rotation);
+ if (r_pipe->sspp)
+ drm_rect_rotate_inv(_pipe_cfg->src_rect,
+ new_plane_state->fb->width,
new_plane_state->fb->height,
+ new_plane_state->rotation);
+
ret = dpu_plane_atomic_check_pipe(pdpu, pipe, pipe_cfg, fmt);
if (ret)
return ret;
--
2.39.2
[PATCH v3 02/12] drm/msm/dpu: add current resource allocation to dumped state
Provide atomic_print_state callback to the DPU's private object. This
way the debugfs/dri/0/state will also include RM's internal state.
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c | 4 +++
drivers/gpu/drm/msm/disp/dpu1/dpu_kms.h | 2 ++
drivers/gpu/drm/msm/disp/dpu1/dpu_rm.c | 48 +
drivers/gpu/drm/msm/disp/dpu1/dpu_rm.h | 8 +
4 files changed, 62 insertions(+)
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c
b/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c
index ee84160592ce..172b64dc60e6 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c
@@ -362,6 +362,7 @@ static void dpu_kms_global_destroy_state(struct
drm_private_obj *obj,
static const struct drm_private_state_funcs dpu_kms_global_state_funcs = {
.atomic_duplicate_state = dpu_kms_global_duplicate_state,
.atomic_destroy_state = dpu_kms_global_destroy_state,
+ .atomic_print_state = dpu_rm_print_state,
};
static int dpu_kms_global_obj_init(struct dpu_kms *dpu_kms)
@@ -375,6 +376,9 @@ static int dpu_kms_global_obj_init(struct dpu_kms *dpu_kms)
drm_atomic_private_obj_init(dpu_kms->dev, _kms->global_state,
>base,
_kms_global_state_funcs);
+
+ state->rm = _kms->rm;
+
return 0;
}
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.h
b/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.h
index ed549f0f7c65..dd2be279b366 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.h
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.h
@@ -130,6 +130,8 @@ struct vsync_info {
struct dpu_global_state {
struct drm_private_state base;
+ struct dpu_rm *rm;
+
uint32_t pingpong_to_enc_id[PINGPONG_MAX - PINGPONG_0];
uint32_t mixer_to_enc_id[LM_MAX - LM_0];
uint32_t ctl_to_enc_id[CTL_MAX - CTL_0];
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_rm.c
b/drivers/gpu/drm/msm/disp/dpu1/dpu_rm.c
index f9215643c71a..5e3442fb8678 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_rm.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_rm.c
@@ -652,3 +652,51 @@ int dpu_rm_get_assigned_resources(struct dpu_rm *rm,
return num_blks;
}
+
+void dpu_rm_print_state(struct drm_printer *p,
+ const struct drm_private_state *state)
+{
+ const struct dpu_global_state *global_state =
to_dpu_global_state(state);
+ const struct dpu_rm *rm = global_state->rm;
+ int i;
+
+ drm_puts(p, "pingpong:");
+ for (i = 0; i < ARRAY_SIZE(global_state->pingpong_to_enc_id); i++)
+ if (rm->pingpong_blks[i])
+ drm_printf(p, " %d,",
global_state->pingpong_to_enc_id[i]);
+ else
+ drm_puts(p, " -,");
+ drm_puts(p, "\n");
+
+ drm_puts(p, "mixer:");
+ for (i = 0; i < ARRAY_SIZE(global_state->mixer_to_enc_id); i++)
+ if (rm->mixer_blks[i])
+ drm_printf(p, " %d,", global_state->mixer_to_enc_id[i]);
+ else
+ drm_puts(p, " -,");
+ drm_puts(p, "\n");
+
+ drm_puts(p, "ctl:");
+ for (i = 0; i < ARRAY_SIZE(global_state->ctl_to_enc_id); i++)
+ if (rm->ctl_blks[i])
+ drm_printf(p, " %d,", global_state->ctl_to_enc_id[i]);
+ else
+ drm_puts(p, " -,");
+ drm_puts(p, "\n");
+
+ drm_puts(p, "dspp:");
+ for (i = 0; i < ARRAY_SIZE(global_state->dspp_to_enc_id); i++)
+ if (rm->dspp_blks[i])
+ drm_printf(p, " %d,", global_state->dspp_to_enc_id[i]);
+ else
+ drm_puts(p, " -,");
+ drm_puts(p, "\n");
+
+ drm_puts(p, "dsc:");
+ for (i = 0; i < ARRAY_SIZE(global_state->dsc_to_enc_id); i++)
+ if (rm->dsc_blks[i])
+ drm_printf(p, " %d,", global_state->dsc_to_enc_id[i]);
+ else
+ drm_puts(p, " -,");
+ drm_puts(p, "\n");
+}
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_rm.h
b/drivers/gpu/drm/msm/disp/dpu1/dpu_rm.h
index 2b551566cbf4..913baca81a42 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_rm.h
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_rm.h
@@ -92,6 +92,14 @@ int dpu_rm_get_assigned_resources(struct dpu_rm *rm,
struct dpu_global_state *global_state, uint32_t enc_id,
enum dpu_hw_blk_type type, struct dpu_hw_blk **blks, int blks_size);
+/**
+ * dpu_rm_print_state - output the RM private state
+ * @p: DRM printer
+ * @state: private object state
+ */
+void dpu_rm_print_state(struct drm_printer *p,
+ const struct drm_private_state *state);
+
/**
* dpu_rm_get_intf - Return a struct dpu_hw_intf instance given it's index.
* @rm: DPU Resource Manager handle
--
2.39.2
[PATCH v3 01/12] drm/atomic-helper: split not-scaling part of drm_atomic_helper_check_plane_state
The helper drm_atomic_helper_check_plane_state() runs several checks on
plane src and dst rectangles, including the check whether required
scaling fits into the required margins. The msm driver would benefit
from having a function that does all these checks except the scaling
one. Split them into a new helper called
drm_atomic_helper_check_plane_noscale().
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/drm_atomic_helper.c | 110 ++--
include/drm/drm_atomic_helper.h | 7 ++
2 files changed, 96 insertions(+), 21 deletions(-)
diff --git a/drivers/gpu/drm/drm_atomic_helper.c
b/drivers/gpu/drm/drm_atomic_helper.c
index 292e38eb6218..2d7dd66181c9 100644
--- a/drivers/gpu/drm/drm_atomic_helper.c
+++ b/drivers/gpu/drm/drm_atomic_helper.c
@@ -825,11 +825,9 @@ drm_atomic_helper_check_wb_encoder_state(struct
drm_encoder *encoder,
EXPORT_SYMBOL(drm_atomic_helper_check_wb_encoder_state);
/**
- * drm_atomic_helper_check_plane_state() - Check plane state for validity
+ * drm_atomic_helper_check_plane_noscale() - Check plane state for validity
* @plane_state: plane state to check
* @crtc_state: CRTC state to check
- * @min_scale: minimum @src:@dest scaling factor in 16.16 fixed point
- * @max_scale: maximum @src:@dest scaling factor in 16.16 fixed point
* @can_position: is it legal to position the plane such that it
*doesn't cover the entire CRTC? This will generally
*only be false for primary planes.
@@ -845,19 +843,16 @@ EXPORT_SYMBOL(drm_atomic_helper_check_wb_encoder_state);
* RETURNS:
* Zero if update appears valid, error code on failure
*/
-int drm_atomic_helper_check_plane_state(struct drm_plane_state *plane_state,
- const struct drm_crtc_state *crtc_state,
- int min_scale,
- int max_scale,
- bool can_position,
- bool can_update_disabled)
+int drm_atomic_helper_check_plane_noscale(struct drm_plane_state *plane_state,
+ const struct drm_crtc_state
*crtc_state,
+ bool can_position,
+ bool can_update_disabled)
{
struct drm_framebuffer *fb = plane_state->fb;
struct drm_rect *src = _state->src;
struct drm_rect *dst = _state->dst;
unsigned int rotation = plane_state->rotation;
struct drm_rect clip = {};
- int hscale, vscale;
WARN_ON(plane_state->crtc && plane_state->crtc != crtc_state->crtc);
@@ -883,17 +878,6 @@ int drm_atomic_helper_check_plane_state(struct
drm_plane_state *plane_state,
drm_rect_rotate(src, fb->width << 16, fb->height << 16, rotation);
- /* Check scaling */
- hscale = drm_rect_calc_hscale(src, dst, min_scale, max_scale);
- vscale = drm_rect_calc_vscale(src, dst, min_scale, max_scale);
- if (hscale < 0 || vscale < 0) {
- drm_dbg_kms(plane_state->plane->dev,
- "Invalid scaling of plane\n");
- drm_rect_debug_print("src: ", _state->src, true);
- drm_rect_debug_print("dst: ", _state->dst, false);
- return -ERANGE;
- }
-
if (crtc_state->enable)
drm_mode_get_hv_timing(_state->mode, , );
@@ -921,6 +905,90 @@ int drm_atomic_helper_check_plane_state(struct
drm_plane_state *plane_state,
return 0;
}
+EXPORT_SYMBOL(drm_atomic_helper_check_plane_noscale);
+
+/**
+ * drm_atomic_helper_check_plane_scale() - Check whether plane can be scaled
+ * @plane_state: plane state to check
+ * @min_scale: minimum @src:@dest scaling factor in 16.16 fixed point
+ * @max_scale: maximum @src:@dest scaling factor in 16.16 fixed point
+ *
+ * Checks that a desired plane scale fits into the min_scale..max_scale
+ * boundaries.
+ * Drivers that provide their own plane handling rather than helper-provided
+ * implementations may still wish to call this function to avoid duplication of
+ * error checking code.
+ *
+ * RETURNS:
+ * Zero if update appears valid, error code on failure
+ */
+int drm_atomic_helper_check_plane_scale(struct drm_plane_state *plane_state,
+ int min_scale,
+ int max_scale)
+{
+ struct drm_framebuffer *fb = plane_state->fb;
+ struct drm_rect src;
+ struct drm_rect dst;
+ int hscale, vscale;
+
+ if (!plane_state->visible)
+ return 0;
+
+ src = drm_plane_state_src(plane_state);
+ dst = drm_plane_state_dest(plane_state);
+
+ drm_rect_rotate(, fb->width << 16, fb->height << 16,
plane_state->rotation);
+
+ hscale = drm_rect_calc_hscale(, , min_scale, max_scale);
+ vscale = drm_rect_calc_vscale(, , min_scale, max_scale);
+ if (hscale < 0 || vscale < 0)
Re: [PATCH v3 03/13] drm/sched: Move schedule policy to scheduler / entity
On 2023-09-14 00:18, Luben Tuikov wrote:
> On 2023-09-11 22:16, Matthew Brost wrote:
>> Rather than a global modparam for scheduling policy, move the scheduling
>> policy to scheduler / entity so user can control each scheduler / entity
>> policy.
>>
>> v2:
>> - s/DRM_SCHED_POLICY_MAX/DRM_SCHED_POLICY_COUNT (Luben)
>> - Only include policy in scheduler (Luben)
>>
>> Signed-off-by: Matthew Brost
>> ---
>> drivers/gpu/drm/amd/amdgpu/amdgpu_device.c | 1 +
>> drivers/gpu/drm/etnaviv/etnaviv_sched.c| 3 ++-
>> drivers/gpu/drm/lima/lima_sched.c | 3 ++-
>> drivers/gpu/drm/msm/msm_ringbuffer.c | 3 ++-
>> drivers/gpu/drm/nouveau/nouveau_sched.c| 3 ++-
>> drivers/gpu/drm/panfrost/panfrost_job.c| 3 ++-
>> drivers/gpu/drm/scheduler/sched_entity.c | 24 ++
>> drivers/gpu/drm/scheduler/sched_main.c | 23 +++--
>> drivers/gpu/drm/v3d/v3d_sched.c| 15 +-
>> include/drm/gpu_scheduler.h| 20 --
>> 10 files changed, 72 insertions(+), 26 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
>> b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
>> index c83a76bccc1d..ecb00991dd51 100644
>> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
>> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
>> @@ -2309,6 +2309,7 @@ static int amdgpu_device_init_schedulers(struct
>> amdgpu_device *adev)
>> ring->num_hw_submission, 0,
>> timeout, adev->reset_domain->wq,
>> ring->sched_score, ring->name,
>> + DRM_SCHED_POLICY_DEFAULT,
>> adev->dev);
>> if (r) {
>> DRM_ERROR("Failed to create scheduler on ring %s.\n",
>> diff --git a/drivers/gpu/drm/etnaviv/etnaviv_sched.c
>> b/drivers/gpu/drm/etnaviv/etnaviv_sched.c
>> index 618a804ddc34..3646f995ca94 100644
>> --- a/drivers/gpu/drm/etnaviv/etnaviv_sched.c
>> +++ b/drivers/gpu/drm/etnaviv/etnaviv_sched.c
>> @@ -137,7 +137,8 @@ int etnaviv_sched_init(struct etnaviv_gpu *gpu)
>> ret = drm_sched_init(>sched, _sched_ops, NULL,
>> etnaviv_hw_jobs_limit, etnaviv_job_hang_limit,
>> msecs_to_jiffies(500), NULL, NULL,
>> - dev_name(gpu->dev), gpu->dev);
>> + dev_name(gpu->dev), DRM_SCHED_POLICY_DEFAULT,
>> + gpu->dev);
>> if (ret)
>> return ret;
>>
>> diff --git a/drivers/gpu/drm/lima/lima_sched.c
>> b/drivers/gpu/drm/lima/lima_sched.c
>> index 8d858aed0e56..465d4bf3882b 100644
>> --- a/drivers/gpu/drm/lima/lima_sched.c
>> +++ b/drivers/gpu/drm/lima/lima_sched.c
>> @@ -491,7 +491,8 @@ int lima_sched_pipe_init(struct lima_sched_pipe *pipe,
>> const char *name)
>> return drm_sched_init(>base, _sched_ops, NULL, 1,
>>lima_job_hang_limit,
>>msecs_to_jiffies(timeout), NULL,
>> - NULL, name, pipe->ldev->dev);
>> + NULL, name, DRM_SCHED_POLICY_DEFAULT,
>> + pipe->ldev->dev);
>> }
>>
>> void lima_sched_pipe_fini(struct lima_sched_pipe *pipe)
>> diff --git a/drivers/gpu/drm/msm/msm_ringbuffer.c
>> b/drivers/gpu/drm/msm/msm_ringbuffer.c
>> index b8865e61b40f..f45e674a0aaf 100644
>> --- a/drivers/gpu/drm/msm/msm_ringbuffer.c
>> +++ b/drivers/gpu/drm/msm/msm_ringbuffer.c
>> @@ -96,7 +96,8 @@ struct msm_ringbuffer *msm_ringbuffer_new(struct msm_gpu
>> *gpu, int id,
>>
>> ret = drm_sched_init(>sched, _sched_ops, NULL,
>> num_hw_submissions, 0, sched_timeout,
>> -NULL, NULL, to_msm_bo(ring->bo)->name, gpu->dev->dev);
>> +NULL, NULL, to_msm_bo(ring->bo)->name,
>> +DRM_SCHED_POLICY_DEFAULT, gpu->dev->dev);
>> if (ret) {
>> goto fail;
>> }
>> diff --git a/drivers/gpu/drm/nouveau/nouveau_sched.c
>> b/drivers/gpu/drm/nouveau/nouveau_sched.c
>> index d458c2227d4f..70e497e40c70 100644
>> --- a/drivers/gpu/drm/nouveau/nouveau_sched.c
>> +++ b/drivers/gpu/drm/nouveau/nouveau_sched.c
>> @@ -431,7 +431,8 @@ int nouveau_sched_init(struct nouveau_drm *drm)
>>
>> return drm_sched_init(sched, _sched_ops, NULL,
>>NOUVEAU_SCHED_HW_SUBMISSIONS, 0, job_hang_limit,
>> - NULL, NULL, "nouveau_sched", drm->dev->dev);
>> + NULL, NULL, "nouveau_sched",
>> + DRM_SCHED_POLICY_DEFAULT, drm->dev->dev);
>> }
>>
>> void nouveau_sched_fini(struct nouveau_drm *drm)
>> diff --git a/drivers/gpu/drm/panfrost/panfrost_job.c
>> b/drivers/gpu/drm/panfrost/panfrost_job.c
>> index 326ca1ddf1d7..ad36bf3a4699 100644
>> --- a/drivers/gpu/drm/panfrost/panfrost_job.c
>> +++
Re: [PATCH v3 03/13] drm/sched: Move schedule policy to scheduler / entity
On 2023-09-11 22:16, Matthew Brost wrote:
> Rather than a global modparam for scheduling policy, move the scheduling
> policy to scheduler / entity so user can control each scheduler / entity
> policy.
>
> v2:
> - s/DRM_SCHED_POLICY_MAX/DRM_SCHED_POLICY_COUNT (Luben)
> - Only include policy in scheduler (Luben)
>
> Signed-off-by: Matthew Brost
> ---
> drivers/gpu/drm/amd/amdgpu/amdgpu_device.c | 1 +
> drivers/gpu/drm/etnaviv/etnaviv_sched.c| 3 ++-
> drivers/gpu/drm/lima/lima_sched.c | 3 ++-
> drivers/gpu/drm/msm/msm_ringbuffer.c | 3 ++-
> drivers/gpu/drm/nouveau/nouveau_sched.c| 3 ++-
> drivers/gpu/drm/panfrost/panfrost_job.c| 3 ++-
> drivers/gpu/drm/scheduler/sched_entity.c | 24 ++
> drivers/gpu/drm/scheduler/sched_main.c | 23 +++--
> drivers/gpu/drm/v3d/v3d_sched.c| 15 +-
> include/drm/gpu_scheduler.h| 20 --
> 10 files changed, 72 insertions(+), 26 deletions(-)
>
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
> b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
> index c83a76bccc1d..ecb00991dd51 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
> @@ -2309,6 +2309,7 @@ static int amdgpu_device_init_schedulers(struct
> amdgpu_device *adev)
> ring->num_hw_submission, 0,
> timeout, adev->reset_domain->wq,
> ring->sched_score, ring->name,
> +DRM_SCHED_POLICY_DEFAULT,
> adev->dev);
> if (r) {
> DRM_ERROR("Failed to create scheduler on ring %s.\n",
> diff --git a/drivers/gpu/drm/etnaviv/etnaviv_sched.c
> b/drivers/gpu/drm/etnaviv/etnaviv_sched.c
> index 618a804ddc34..3646f995ca94 100644
> --- a/drivers/gpu/drm/etnaviv/etnaviv_sched.c
> +++ b/drivers/gpu/drm/etnaviv/etnaviv_sched.c
> @@ -137,7 +137,8 @@ int etnaviv_sched_init(struct etnaviv_gpu *gpu)
> ret = drm_sched_init(>sched, _sched_ops, NULL,
>etnaviv_hw_jobs_limit, etnaviv_job_hang_limit,
>msecs_to_jiffies(500), NULL, NULL,
> - dev_name(gpu->dev), gpu->dev);
> + dev_name(gpu->dev), DRM_SCHED_POLICY_DEFAULT,
> + gpu->dev);
> if (ret)
> return ret;
>
> diff --git a/drivers/gpu/drm/lima/lima_sched.c
> b/drivers/gpu/drm/lima/lima_sched.c
> index 8d858aed0e56..465d4bf3882b 100644
> --- a/drivers/gpu/drm/lima/lima_sched.c
> +++ b/drivers/gpu/drm/lima/lima_sched.c
> @@ -491,7 +491,8 @@ int lima_sched_pipe_init(struct lima_sched_pipe *pipe,
> const char *name)
> return drm_sched_init(>base, _sched_ops, NULL, 1,
> lima_job_hang_limit,
> msecs_to_jiffies(timeout), NULL,
> - NULL, name, pipe->ldev->dev);
> + NULL, name, DRM_SCHED_POLICY_DEFAULT,
> + pipe->ldev->dev);
> }
>
> void lima_sched_pipe_fini(struct lima_sched_pipe *pipe)
> diff --git a/drivers/gpu/drm/msm/msm_ringbuffer.c
> b/drivers/gpu/drm/msm/msm_ringbuffer.c
> index b8865e61b40f..f45e674a0aaf 100644
> --- a/drivers/gpu/drm/msm/msm_ringbuffer.c
> +++ b/drivers/gpu/drm/msm/msm_ringbuffer.c
> @@ -96,7 +96,8 @@ struct msm_ringbuffer *msm_ringbuffer_new(struct msm_gpu
> *gpu, int id,
>
> ret = drm_sched_init(>sched, _sched_ops, NULL,
> num_hw_submissions, 0, sched_timeout,
> - NULL, NULL, to_msm_bo(ring->bo)->name, gpu->dev->dev);
> + NULL, NULL, to_msm_bo(ring->bo)->name,
> + DRM_SCHED_POLICY_DEFAULT, gpu->dev->dev);
> if (ret) {
> goto fail;
> }
> diff --git a/drivers/gpu/drm/nouveau/nouveau_sched.c
> b/drivers/gpu/drm/nouveau/nouveau_sched.c
> index d458c2227d4f..70e497e40c70 100644
> --- a/drivers/gpu/drm/nouveau/nouveau_sched.c
> +++ b/drivers/gpu/drm/nouveau/nouveau_sched.c
> @@ -431,7 +431,8 @@ int nouveau_sched_init(struct nouveau_drm *drm)
>
> return drm_sched_init(sched, _sched_ops, NULL,
> NOUVEAU_SCHED_HW_SUBMISSIONS, 0, job_hang_limit,
> - NULL, NULL, "nouveau_sched", drm->dev->dev);
> + NULL, NULL, "nouveau_sched",
> + DRM_SCHED_POLICY_DEFAULT, drm->dev->dev);
> }
>
> void nouveau_sched_fini(struct nouveau_drm *drm)
> diff --git a/drivers/gpu/drm/panfrost/panfrost_job.c
> b/drivers/gpu/drm/panfrost/panfrost_job.c
> index 326ca1ddf1d7..ad36bf3a4699 100644
> --- a/drivers/gpu/drm/panfrost/panfrost_job.c
> +++ b/drivers/gpu/drm/panfrost/panfrost_job.c
> @@ -835,7 +835,8 @@ int panfrost_job_init(struct panfrost_device *pfdev)
>
Re: [PATCH v16 15/20] drm/shmem-helper: Add memory shrinker
On 9/13/23 10:48, Boris Brezillon wrote:
> On Wed, 13 Sep 2023 03:56:14 +0300
> Dmitry Osipenko wrote:
>
>> On 9/5/23 11:03, Boris Brezillon wrote:
* But
+ * acquiring the obj lock in
drm_gem_shmem_release_pages_locked() can
+ * cause a locking order inversion between
reservation_ww_class_mutex
+ * and fs_reclaim.
+ *
+ * This deadlock is not actually possible, because no one should
+ * be already holding the lock when drm_gem_shmem_free() is
called.
+ * Unfortunately lockdep is not aware of this detail. So when
the
+ * refcount drops to zero, don't touch the reservation lock.
+ */
+ if (shmem->got_pages_sgt &&
+ refcount_dec_and_test(>pages_use_count)) {
+ drm_gem_shmem_do_release_pages_locked(shmem);
+ shmem->got_pages_sgt = false;
}
>>> Leaking memory is the right thing to do if pages_use_count > 1 (it's
>>> better to leak than having someone access memory it no longer owns), but
>>> I think it's worth mentioning in the above comment.
>>
>> It's unlikely that it will be only a leak without a following up
>> use-after-free. Neither is acceptable.
>
> Not necessarily, if you have a page leak, it could be that the GPU has
> access to those pages, but doesn't need the GEM object anymore
> (pages are mapped by the iommu, which doesn't need shmem->sgt or
> shmem->pages after the mapping is created). Without a WARN_ON(), this
> can go unnoticed and lead to memory corruptions/information leaks.
>
>>
>> The drm_gem_shmem_free() could be changed such that kernel won't blow up
>> on a refcnt bug, but that's not worthwhile doing because drivers
>> shouldn't have silly bugs.
>
> We definitely don't want to fix that, but we want to complain loudly
> (WARN_ON()), and make sure the risk is limited (preventing memory from
> being re-assigned to someone else by not freeing it).
That's what the code did and continues to do here. Not exactly sure what
you're trying to say. I'm going to relocate the comment in v17 to
put_pages(), we can continue discussing it there if I'm missing yours point.
--
Best regards,
Dmitry
Re: [PATCH v3 02/13] drm/sched: Convert drm scheduler to use a work queue rather than kthread
On 2023-09-12 11:02, Matthew Brost wrote:
> On Tue, Sep 12, 2023 at 09:29:53AM +0200, Boris Brezillon wrote:
>> On Mon, 11 Sep 2023 19:16:04 -0700
>> Matthew Brost wrote:
>>
>>> @@ -1071,6 +1063,7 @@ static int drm_sched_main(void *param)
>>> *
>>> * @sched: scheduler instance
>>> * @ops: backend operations for this scheduler
>>> + * @submit_wq: workqueue to use for submission. If NULL, the system_wq is
>>> used
>>> * @hw_submission: number of hw submissions that can be in flight
>>> * @hang_limit: number of times to allow a job to hang before dropping it
>>> * @timeout: timeout value in jiffies for the scheduler
>>> @@ -1084,14 +1077,16 @@ static int drm_sched_main(void *param)
>>> */
>>> int drm_sched_init(struct drm_gpu_scheduler *sched,
>>>const struct drm_sched_backend_ops *ops,
>>> + struct workqueue_struct *submit_wq,
>>>unsigned hw_submission, unsigned hang_limit,
>>>long timeout, struct workqueue_struct *timeout_wq,
>>>atomic_t *score, const char *name, struct device *dev)
>>> {
>>> - int i, ret;
>>> + int i;
>>> sched->ops = ops;
>>> sched->hw_submission_limit = hw_submission;
>>> sched->name = name;
>>> + sched->submit_wq = submit_wq ? : system_wq;
>>
>> My understanding is that the new design is based on the idea of
>> splitting the drm_sched_main function into work items that can be
>> scheduled independently so users/drivers can insert their own
>> steps/works without requiring changes to drm_sched. This approach is
>> relying on the properties of ordered workqueues (1 work executed at a
>> time, FIFO behavior) to guarantee that these steps are still executed
>> in order, and one at a time.
>>
>> Given what you're trying to achieve I think we should create an ordered
>> workqueue instead of using the system_wq when submit_wq is NULL,
>> otherwise you lose this ordering/serialization guarantee which both
>> the dedicated kthread and ordered wq provide. It will probably work for
>> most drivers, but might lead to subtle/hard to spot ordering issues.
>>
>
> I debated chosing between a system_wq or creating an ordered-wq by
> default myself. Indeed using the system_wq by default subtlety changes
> the behavior as run_job & free_job workers can run in parallel. To be
> safe, agree the default use be an ordered-wq. If drivers are fine with
> run_job() and free_job() running in parallel, they are free to set
> submit_wq == system_wq. Will change in next rev.
>
> Matt
So, yes, this is very good--do make that change. However, in case
of parallelism between run_job() and free_job(), perhaps we should
have a function parameter, to control this, and then internally,
we decide whether to use system_wq (perhaps not) or our own
workqueue which is just not ordered. This will give us some flexibility
should we need to have better control/reporting/etc., of our workqueue.
--
Regards,
Luben
>
>>> sched->timeout = timeout;
>>> sched->timeout_wq = timeout_wq ? : system_wq;
>>> sched->hang_limit = hang_limit;
>>> @@ -1100,23 +1095,15 @@ int drm_sched_init(struct drm_gpu_scheduler *sched,
>>> for (i = DRM_SCHED_PRIORITY_MIN; i < DRM_SCHED_PRIORITY_COUNT; i++)
>>> drm_sched_rq_init(sched, >sched_rq[i]);
>>>
>>> - init_waitqueue_head(>wake_up_worker);
>>> init_waitqueue_head(>job_scheduled);
>>> INIT_LIST_HEAD(>pending_list);
>>> spin_lock_init(>job_list_lock);
>>> atomic_set(>hw_rq_count, 0);
>>> INIT_DELAYED_WORK(>work_tdr, drm_sched_job_timedout);
>>> + INIT_WORK(>work_submit, drm_sched_main);
>>> atomic_set(>_score, 0);
>>> atomic64_set(>job_id_count, 0);
>>> -
>>> - /* Each scheduler will run on a seperate kernel thread */
>>> - sched->thread = kthread_run(drm_sched_main, sched, sched->name);
>>> - if (IS_ERR(sched->thread)) {
>>> - ret = PTR_ERR(sched->thread);
>>> - sched->thread = NULL;
>>> - DRM_DEV_ERROR(sched->dev, "Failed to create scheduler for
>>> %s.\n", name);
>>> - return ret;
>>> - }
>>> + sched->pause_submit = false;
>>>
>>> sched->ready = true;
>>> return 0;
Re: [PATCH v3 02/13] drm/sched: Convert drm scheduler to use a work queue rather than kthread
On 2023-09-11 22:16, Matthew Brost wrote:
> In XE, the new Intel GPU driver, a choice has made to have a 1 to 1
has --> was
> mapping between a drm_gpu_scheduler and drm_sched_entity. At first this
> seems a bit odd but let us explain the reasoning below.
It's totally fine! :-)
>
> 1. In XE the submission order from multiple drm_sched_entity is not
> guaranteed to be the same completion even if targeting the same hardware
> engine. This is because in XE we have a firmware scheduler, the GuC,
> which allowed to reorder, timeslice, and preempt submissions. If a using
> shared drm_gpu_scheduler across multiple drm_sched_entity, the TDR falls
> apart as the TDR expects submission order == completion order. Using a
> dedicated drm_gpu_scheduler per drm_sched_entity solve this problem.
>
> 2. In XE submissions are done via programming a ring buffer (circular
> buffer), a drm_gpu_scheduler provides a limit on number of jobs, if the
> limit of number jobs is set to RING_SIZE / MAX_SIZE_PER_JOB we get flow
> control on the ring for free.
>
> A problem with this design is currently a drm_gpu_scheduler uses a
> kthread for submission / job cleanup. This doesn't scale if a large
> number of drm_gpu_scheduler are used. To work around the scaling issue,
> use a worker rather than kthread for submission / job cleanup.
>
> v2:
> - (Rob Clark) Fix msm build
> - Pass in run work queue
> v3:
> - (Boris) don't have loop in worker
> v4:
> - (Tvrtko) break out submit ready, stop, start helpers into own patch
>
> Signed-off-by: Matthew Brost
> ---
> drivers/gpu/drm/amd/amdgpu/amdgpu_device.c | 2 +-
> drivers/gpu/drm/etnaviv/etnaviv_sched.c| 2 +-
> drivers/gpu/drm/lima/lima_sched.c | 2 +-
> drivers/gpu/drm/msm/msm_ringbuffer.c | 2 +-
> drivers/gpu/drm/nouveau/nouveau_sched.c| 2 +-
> drivers/gpu/drm/panfrost/panfrost_job.c| 2 +-
> drivers/gpu/drm/scheduler/sched_main.c | 106 +
> drivers/gpu/drm/v3d/v3d_sched.c| 10 +-
> include/drm/gpu_scheduler.h| 12 ++-
> 9 files changed, 65 insertions(+), 75 deletions(-)
>
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
> b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
> index 1f8a794704d0..c83a76bccc1d 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
> @@ -2305,7 +2305,7 @@ static int amdgpu_device_init_schedulers(struct
> amdgpu_device *adev)
> break;
> }
>
> - r = drm_sched_init(>sched, _sched_ops,
> + r = drm_sched_init(>sched, _sched_ops, NULL,
> ring->num_hw_submission, 0,
> timeout, adev->reset_domain->wq,
> ring->sched_score, ring->name,
> diff --git a/drivers/gpu/drm/etnaviv/etnaviv_sched.c
> b/drivers/gpu/drm/etnaviv/etnaviv_sched.c
> index 345fec6cb1a4..618a804ddc34 100644
> --- a/drivers/gpu/drm/etnaviv/etnaviv_sched.c
> +++ b/drivers/gpu/drm/etnaviv/etnaviv_sched.c
> @@ -134,7 +134,7 @@ int etnaviv_sched_init(struct etnaviv_gpu *gpu)
> {
> int ret;
>
> - ret = drm_sched_init(>sched, _sched_ops,
> + ret = drm_sched_init(>sched, _sched_ops, NULL,
>etnaviv_hw_jobs_limit, etnaviv_job_hang_limit,
>msecs_to_jiffies(500), NULL, NULL,
>dev_name(gpu->dev), gpu->dev);
> diff --git a/drivers/gpu/drm/lima/lima_sched.c
> b/drivers/gpu/drm/lima/lima_sched.c
> index ffd91a5ee299..8d858aed0e56 100644
> --- a/drivers/gpu/drm/lima/lima_sched.c
> +++ b/drivers/gpu/drm/lima/lima_sched.c
> @@ -488,7 +488,7 @@ int lima_sched_pipe_init(struct lima_sched_pipe *pipe,
> const char *name)
>
> INIT_WORK(>recover_work, lima_sched_recover_work);
>
> - return drm_sched_init(>base, _sched_ops, 1,
> + return drm_sched_init(>base, _sched_ops, NULL, 1,
> lima_job_hang_limit,
> msecs_to_jiffies(timeout), NULL,
> NULL, name, pipe->ldev->dev);
> diff --git a/drivers/gpu/drm/msm/msm_ringbuffer.c
> b/drivers/gpu/drm/msm/msm_ringbuffer.c
> index 40c0bc35a44c..b8865e61b40f 100644
> --- a/drivers/gpu/drm/msm/msm_ringbuffer.c
> +++ b/drivers/gpu/drm/msm/msm_ringbuffer.c
> @@ -94,7 +94,7 @@ struct msm_ringbuffer *msm_ringbuffer_new(struct msm_gpu
> *gpu, int id,
>/* currently managing hangcheck ourselves: */
> sched_timeout = MAX_SCHEDULE_TIMEOUT;
>
> - ret = drm_sched_init(>sched, _sched_ops,
> + ret = drm_sched_init(>sched, _sched_ops, NULL,
> num_hw_submissions, 0, sched_timeout,
> NULL, NULL, to_msm_bo(ring->bo)->name, gpu->dev->dev);
> if (ret) {
> diff --git a/drivers/gpu/drm/nouveau/nouveau_sched.c
> b/drivers/gpu/drm/nouveau/nouveau_sched.c
> index 88217185e0f3..d458c2227d4f 100644
> ---
RE: [PATCH 3/3] drm/mst: adjust the function drm_dp_remove_payload_part2()
[Public]
> -Original Message-
> From: Imre Deak
> Sent: Tuesday, September 12, 2023 7:19 PM
> To: Lin, Wayne
> Cc: dri-devel@lists.freedesktop.org; amd-...@lists.freedesktop.org;
> ly...@redhat.com; jani.nik...@intel.com; ville.syrj...@linux.intel.com;
> Wentland, Harry ; Zuo, Jerry
>
> Subject: Re: [PATCH 3/3] drm/mst: adjust the function
> drm_dp_remove_payload_part2()
>
> On Tue, Sep 12, 2023 at 07:26:29AM +, Lin, Wayne wrote:
> > [Public]
> > [...]
> > >
> > > I'd like to be sure that the payload is removed with the size it was
> > > added with in the previous commit and as I wrote above not depend
> > > for this on the new payload state with a mixture of old/current/new
> > > states.
> > > Based on that I'd be ok for instance with a new
> > >
> > > int drm_dp_remove_port_payload(mgr, mst_state, port)
> > >
> > > function which looks up / removes the payload with the time_slots
> > > calculated based on the payload table as in your patch and returns
> > > the calculated time_slots.
> > >
> > > The AMD driver could call the above function and the current
> > > drm_dp_remove_payload(mgr, mst_state, old_payload) function would be
> > >
> > > time_slots = drm_dp_remove_port_payload(mgr, mst_state,
> > > old_payload->port);
> > > WARN_ON(time_slots != old_payload->time_slots);
> > >
> > > --Imre
> >
> > Sorry but I might not fully understand what you suggested here. Would
> > like to know if you agree on referring to the time slot number of the
> > payload table at the moment is better then referring
> > old_payload->time_slots for drm_dp_remove_payload()? If you agree on
> > that, my patch actually is just replacing old_payload->time_slots with
> > the more appropriate one. Not adding mixture of old/current but replacing
> the old with the current one.
>
> The new_payload state contains a mixture of old/current/new state at the
> moment and this patch adds more dependency on that, recalculating the old
> payload size from that state. For i915 this recalculation isn't needed, the
> size is
> already available in the old payload state.
>
I see. Thanks, Imre. So it's about the idea to have another patch to extract
things
like vc_start_slot out of mst state.
> > And like what I explained in previous example, when calling
> > drm_dp_remove_payload(), the time slot number to be removed shouldn't
> > be constrained to the one in previous commit. The number in the
> > payload table when we're about to remove the payload might be a better
> > choice. Could you elaborate more what's the mixture that this patch is
> adding on, please?
> >
> > As for the changing suggestion, are you suggesting to create a new
> > function
> > drm_dp_remove_port_payload() to wrap up the calculation in my patch?
> > If so, I think that's the consensus to use current time slot number to
> > replace
> the one in old_payload.
> > Therefore, it doesn't have to pass old_payload to
> > drm_dp_remove_port_payload(), and "WARN_ON(time_slots !=
> > old_payload->time_slots);" is not appropriate as for the example that I gave
> previously.
>
> I meant something like the following:
The change looks good to me. I'll update the patch. Thanks for the help.
>
> diff --git
> a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_helpers.c
> b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_helpers.c
> index cbef4ff28cd8a..0555433d8050b 100644
> --- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_helpers.c
> +++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_helpers.c
> @@ -343,7 +343,7 @@ bool dm_helpers_dp_mst_send_payload_allocation(
> struct amdgpu_dm_connector *aconnector;
> struct drm_dp_mst_topology_state *mst_state;
> struct drm_dp_mst_topology_mgr *mst_mgr;
> - struct drm_dp_mst_atomic_payload *new_payload, *old_payload;
> + struct drm_dp_mst_atomic_payload *new_payload;
> enum mst_progress_status set_flag =
> MST_ALLOCATE_NEW_PAYLOAD;
> enum mst_progress_status clr_flag =
> MST_CLEAR_ALLOCATED_PAYLOAD;
> int ret = 0;
> @@ -366,9 +366,8 @@ bool dm_helpers_dp_mst_send_payload_allocation(
> if (enable) {
> ret = drm_dp_add_payload_part2(mst_mgr, mst_state-
> >base.state, new_payload);
> } else {
> - dm_helpers_construct_old_payload(stream->link, mst_state-
> >pbn_div,
> - new_payload, old_payload);
> - drm_dp_remove_payload_part2(mst_mgr, mst_state,
> old_payload, new_payload);
> + drm_dp_remove_current_payload_part2(mst_mgr,
> mst_state->base.state,
> + aconnector-
> >mst_output_port);
> }
>
> if (ret) {
> diff --git a/drivers/gpu/drm/display/drm_dp_mst_topology.c
> b/drivers/gpu/drm/display/drm_dp_mst_topology.c
> index e04f87ff755ac..4d25dba789e91 100644
> --- a/drivers/gpu/drm/display/drm_dp_mst_topology.c
> +++ b/drivers/gpu/drm/display/drm_dp_mst_topology.c
> @@ -3382,37 +3382,70 @@
>
Re: [PATCH v3 09/13] drm/sched: Submit job before starting TDR
On 2023-09-11 22:16, Matthew Brost wrote:
> If the TDR is set to a value, it can fire before a job is submitted in
> drm_sched_main. The job should be always be submitted before the TDR
> fires, fix this ordering.
>
> v2:
> - Add to pending list before run_job, start TDR after (Luben, Boris)
>
> Signed-off-by: Matthew Brost
> ---
> drivers/gpu/drm/scheduler/sched_main.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/scheduler/sched_main.c
> b/drivers/gpu/drm/scheduler/sched_main.c
> index c627d3e6494a..9dbfab7be2c6 100644
> --- a/drivers/gpu/drm/scheduler/sched_main.c
> +++ b/drivers/gpu/drm/scheduler/sched_main.c
> @@ -498,7 +498,6 @@ static void drm_sched_job_begin(struct drm_sched_job
> *s_job)
>
> spin_lock(>job_list_lock);
> list_add_tail(_job->list, >pending_list);
> - drm_sched_start_timeout(sched);
> spin_unlock(>job_list_lock);
> }
>
> @@ -1234,6 +1233,7 @@ static void drm_sched_run_job_work(struct work_struct
> *w)
> fence = sched->ops->run_job(sched_job);
> complete_all(>entity_idle);
> drm_sched_fence_scheduled(s_fence, fence);
> + drm_sched_start_timeout_unlocked(sched);
>
> if (!IS_ERR_OR_NULL(fence)) {
> /* Drop for original kref_init of the fence */
So, sched->ops->run_job(), is a "job inflection point" from the point of view of
the DRM scheduler. After that call, DRM has relinquished control of the job to
the
firmware/hardware.
Putting the job in the pending list, before submitting it to down to the
firmware/hardware,
goes along with starting a timeout timer for the job. The timeout always
includes
time for the firmware/hardware to get it prepped, as well as time for the actual
execution of the job (task). Thus, we want to do this:
1. Put the job in pending list. "Pending list" means "pends in
hardware".
2. Start a timeout timer for the job.
3. Start executing the job/task. This usually involves giving it to
firmware/hardware,
i.e. ownership of the job/task changes to another domain. In our
case this is accomplished
by calling sched->ops->run_job().
Perhaps move drm_sched_start_timeout() closer to sched->ops->run_job() from
above and/or increase
the timeout value?
--
Regards,
Luben
Re: [PATCH v3 10/13] drm/sched: Add helper to set TDR timeout
On 2023-09-11 22:16, Matthew Brost wrote:
> Add helper to set TDR timeout and restart the TDR with new timeout
> value. This will be used in XE, new Intel GPU driver, to trigger the TDR
> to cleanup drm_sched_entity that encounter errors.
Do you just want to trigger the cleanup or do you really want to
modify the timeout and requeue TDR delayed work (to be triggered
later at a different time)?
If the former, then might as well just add a function to queue that
right away. If the latter, then this would do, albeit with a few
notes as mentioned below.
>
> Signed-off-by: Matthew Brost
> ---
> drivers/gpu/drm/scheduler/sched_main.c | 18 ++
> include/drm/gpu_scheduler.h| 1 +
> 2 files changed, 19 insertions(+)
>
> diff --git a/drivers/gpu/drm/scheduler/sched_main.c
> b/drivers/gpu/drm/scheduler/sched_main.c
> index 9dbfab7be2c6..689fb6686e01 100644
> --- a/drivers/gpu/drm/scheduler/sched_main.c
> +++ b/drivers/gpu/drm/scheduler/sched_main.c
> @@ -426,6 +426,24 @@ static void drm_sched_start_timeout_unlocked(struct
> drm_gpu_scheduler *sched)
> spin_unlock(>job_list_lock);
> }
>
> +/**
> + * drm_sched_set_timeout - set timeout for reset worker
> + *
> + * @sched: scheduler instance to set and (re)-start the worker for
> + * @timeout: timeout period
> + *
> + * Set and (re)-start the timeout for the given scheduler.
> + */
> +void drm_sched_set_timeout(struct drm_gpu_scheduler *sched, long timeout)
> +{
Well, I'd perhaps call this "drm_sched_set_tdr_timeout()", or something
to that effect, as "drm_sched_set_timeout()" isn't clear that it is indeed
a cleanup timeout. However, it's totally up to you. :-)
It appears that "long timeout" is the new job timeout, so it is possible
that a stuck job might be given old timeout + new timeout recovery time,
after this function is called.
> + spin_lock(>job_list_lock);
> + sched->timeout = timeout;
> + cancel_delayed_work(>work_tdr);
> + drm_sched_start_timeout(sched);
> + spin_unlock(>job_list_lock);
> +}
> +EXPORT_SYMBOL(drm_sched_set_timeout);
Well, drm_sched_start_timeout() (which also has a name lacking description,
perhaps
it should be "drm_sched_start_tdr_timeout()" or "...start_cleanup_timeout()"),
anyway,
so that function compares to MAX_SCHEDULE_TIMEOUT and pending list not being
empty
before it requeues delayed TDR work item. So, while a remote possibility, this
new
function may have the unintended consequence of canceling TDR, and never
restarting it.
I see it grabs the lock, however. Maybe wrap it in "if (sched->timeout !=
MAX_SCHEDULE_TIMEOUT)"?
How about using mod_delayed_work()?
--
Regards,
Luben
> +
> /**
> * drm_sched_fault - immediately start timeout handler
> *
> diff --git a/include/drm/gpu_scheduler.h b/include/drm/gpu_scheduler.h
> index 5d753ecb5d71..b7b818cd81b6 100644
> --- a/include/drm/gpu_scheduler.h
> +++ b/include/drm/gpu_scheduler.h
> @@ -596,6 +596,7 @@ void drm_sched_entity_modify_sched(struct
> drm_sched_entity *entity,
> struct drm_gpu_scheduler **sched_list,
> unsigned int num_sched_list);
>
> +void drm_sched_set_timeout(struct drm_gpu_scheduler *sched, long timeout);
> void drm_sched_job_cleanup(struct drm_sched_job *job);
> void drm_sched_wakeup_if_can_queue(struct drm_gpu_scheduler *sched);
> void drm_sched_add_msg(struct drm_gpu_scheduler *sched,
Re: [PATCH v3 12/13] drm/sched/doc: Add Entity teardown documentaion
On 2023-09-11 22:16, Matthew Brost wrote: > Provide documentation to guide in ways to teardown an entity. > > Signed-off-by: Matthew Brost > --- > Documentation/gpu/drm-mm.rst | 6 ++ > drivers/gpu/drm/scheduler/sched_entity.c | 19 +++ > 2 files changed, 25 insertions(+) > > diff --git a/Documentation/gpu/drm-mm.rst b/Documentation/gpu/drm-mm.rst > index c19b34b1c0ed..cb4d6097897e 100644 > --- a/Documentation/gpu/drm-mm.rst > +++ b/Documentation/gpu/drm-mm.rst > @@ -552,6 +552,12 @@ Overview > .. kernel-doc:: drivers/gpu/drm/scheduler/sched_main.c > :doc: Overview > > +Entity teardown > +--- > + > +.. kernel-doc:: drivers/gpu/drm/scheduler/sched_entity.c > + :doc: Entity teardown > + > Scheduler Function References > - > > diff --git a/drivers/gpu/drm/scheduler/sched_entity.c > b/drivers/gpu/drm/scheduler/sched_entity.c > index 37557fbb96d0..76f3e10218bb 100644 > --- a/drivers/gpu/drm/scheduler/sched_entity.c > +++ b/drivers/gpu/drm/scheduler/sched_entity.c > @@ -21,6 +21,25 @@ > * > */ > > +/** > + * DOC: Entity teardown > + * > + * Drivers can teardown down an entity for several reasons. Reasons typically > + * are a user closes the entity via an IOCTL, the FD associated with the > entity > + * is closed, or the entity encounters an error. So in this third case, "entity encounters an error", we need to make sure that no new jobs are being pushed to the entity, or at least say that here. IOW, in all three cases, the common denominator (requirement?) is that no new jobs are being pushed to the entity, i.e. that there are no incoming jobs. > The GPU scheduler provides the > + * basic infrastructure to do this in a few different ways. Well, I'd say "in two different ways." or "in the following two ways." I'd rather have "two" in there to make sure that it is these two, and not any more/less/etc. > + * > + * 1. Let the entity run dry (both the pending list and job queue) and then > call > + * drm_sched_entity_fini. The backend can accelerate the process of running > dry. > + * For example set a flag so run_job is a NOP and set the TDR to a low value > to > + * signal all jobs in a timely manner (this example works for > + * DRM_SCHED_POLICY_SINGLE_ENTITY). > + * > + * 2. Kill the entity directly via drm_sched_entity_flush / > + * drm_sched_entity_fini ensuring all pending and queued jobs are off the > + * hardware and signaled. > + */ > + > #include > #include > #include -- Regards, Luben
Re: [PATCH v3 00/13] DRM scheduler changes for Xe
On 2023-09-11 22:16, Matthew Brost wrote: > As a prerequisite to merging the new Intel Xe DRM driver [1] [2], we > have been asked to merge our common DRM scheduler patches first. > > This a continuation of a RFC [3] with all comments addressed, ready for > a full review, and hopefully in state which can merged in the near > future. More details of this series can found in the cover letter of the > RFC [3]. > > These changes have been tested with the Xe driver. > > v2: > - Break run job, free job, and process message in own work items > - This might break other drivers as run job and free job now can run in >parallel, can fix up if needed Hi Matthew, Do you mean "run job B and free job A" ... "in parallel"? I don't see why this cannot be done. One can have a work-item/thread push jobs to hardware, while another post-processes them on a wakeup from a driver interrupt, and frees them, and both of those run in parallel, albeit any dependencies. Regards, Luben > > v3: > - Include missing patch 'drm/sched: Add drm_sched_submit_* helpers' > - Fix issue with setting timestamp to early > - Don't dequeue jobs for single entity after calling entity fini > - Flush pending jobs on entity fini > - Add documentation for entity teardown > - Add Matthew Brost to maintainers of DRM scheduler > > Matt > > [1] https://gitlab.freedesktop.org/drm/xe/kernel > [2] https://patchwork.freedesktop.org/series/112188/ > [3] https://patchwork.freedesktop.org/series/116055/ > > Matthew Brost (13): > drm/sched: Add drm_sched_submit_* helpers > drm/sched: Convert drm scheduler to use a work queue rather than > kthread > drm/sched: Move schedule policy to scheduler / entity > drm/sched: Add DRM_SCHED_POLICY_SINGLE_ENTITY scheduling policy > drm/sched: Split free_job into own work item > drm/sched: Add generic scheduler message interface > drm/sched: Add drm_sched_start_timeout_unlocked helper > drm/sched: Start run wq before TDR in drm_sched_start > drm/sched: Submit job before starting TDR > drm/sched: Add helper to set TDR timeout > drm/sched: Waiting for pending jobs to complete in scheduler kill > drm/sched/doc: Add Entity teardown documentaion > drm/sched: Update maintainers of GPU scheduler > > Documentation/gpu/drm-mm.rst | 6 + > MAINTAINERS | 1 + > .../drm/amd/amdgpu/amdgpu_amdkfd_arcturus.c | 2 +- > drivers/gpu/drm/amd/amdgpu/amdgpu_debugfs.c | 17 +- > drivers/gpu/drm/amd/amdgpu/amdgpu_device.c| 15 +- > drivers/gpu/drm/etnaviv/etnaviv_sched.c | 5 +- > drivers/gpu/drm/lima/lima_sched.c | 5 +- > drivers/gpu/drm/msm/adreno/adreno_device.c| 6 +- > drivers/gpu/drm/msm/msm_ringbuffer.c | 5 +- > drivers/gpu/drm/nouveau/nouveau_sched.c | 5 +- > drivers/gpu/drm/panfrost/panfrost_job.c | 5 +- > drivers/gpu/drm/scheduler/sched_entity.c | 111 +++- > drivers/gpu/drm/scheduler/sched_fence.c | 2 +- > drivers/gpu/drm/scheduler/sched_main.c| 497 ++ > drivers/gpu/drm/v3d/v3d_sched.c | 25 +- > include/drm/gpu_scheduler.h | 96 +++- > 16 files changed, 644 insertions(+), 159 deletions(-) > -- Regards, Luben
[PATCH] drm/debugfs: Fix drm_debugfs_remove_files() stub
When building without CONFIG_DEBUG_FS:
drivers/gpu/drm/tegra/dc.c:1757:59: error: too many arguments to function
call, expected 3, have 4
1757 | drm_debugfs_remove_files(dc->debugfs_files, count, root,
minor);
| ^
include/drm/drm_debugfs.h:162:19: note: 'drm_debugfs_remove_files' declared
here
162 | static inline int drm_debugfs_remove_files(const struct drm_info_list
*files,
| ^
~~
163 |int count, struct
drm_minor *minor)
|
~~
1 error generated.
Update the stub to include the root parameter.
Fixes: 8e455145d8f1 ("drm/debugfs: rework drm_debugfs_create_files
implementation v2")
Signed-off-by: Nathan Chancellor
---
include/drm/drm_debugfs.h | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/include/drm/drm_debugfs.h b/include/drm/drm_debugfs.h
index 7213ce15e4ff..3bba169f9bae 100644
--- a/include/drm/drm_debugfs.h
+++ b/include/drm/drm_debugfs.h
@@ -160,7 +160,8 @@ static inline void drm_debugfs_create_files(const struct
drm_info_list *files,
{}
static inline int drm_debugfs_remove_files(const struct drm_info_list *files,
- int count, struct drm_minor *minor)
+ int count, struct dentry *root,
+ struct drm_minor *minor)
{
return 0;
}
---
base-commit: fc71f615fd08a530d24c7af0a1efa72ec6ea8e34
change-id: 20230913-fix-drm_debugfs_remove_files-stub-bd864127c162
Best regards,
--
Nathan Chancellor
Re: [RFC PATCH v2 0/5] drm/amd/display: improve DTN color state log
On 9/13/23 10:43, Melissa Wen wrote: Hi, This is an update of previous RFC [0] improving the data collection of Gamma Correction and Blend Gamma color blocks. As I mentioned in the last version, I'm updating the color state part of DTN log to match DCN3.0 HW better. Currently, the DTN log considers the DCN10 color pipeline, which is useless for DCN3.0 because of all the differences in color caps between DCN versions. In addition to new color blocks and caps, some semantic differences made the DCN10 output not fit DCN30. In this RFC, the first patch adds new color state elements to DPP and implements the reading of registers according to HW blocks. Similarly to MPC, the second patch also creates a DCN3-specific function to read the MPC state and add the MPC color state logging to it. With DPP and MPC color-register reading, I detach DCN10 color state logging from the HW log and create a `.log_color_state` hook for logging color state according to HW color blocks with DCN30 as the first use case. Finally, the last patch adds DPP and MPC color caps output to facilitate understanding of the color state log. This version works well with the driver-specific color properties[1] and steamdeck/gamescope[2] together, where we can see color state changing from default values. Here is a before vs. after example: Without this series: === DPP:IGAM format IGAM modeDGAM modeRGAM mode GAMUT mode C11 C12 C13 C14 C21 C22 C23 C24 C31 C32 C33 C34 [ 0]:0h BypassFixed Bypass Bypass0h h h h h h [ 3]:0h BypassFixed Bypass Bypass0h h h h h h MPCC: OPP DPP MPCCBOT MODE ALPHA_MODE PREMULT OVERLAP_ONLY IDLE [ 0]: 0h 0h 3h 3 20 0 0 [ 3]: 0h 3h fh 2 20 0 0 With this series (Steamdeck/Gamescope): == DPP: DGAM ROM DGAM ROM type DGAM LUT SHAPER mode 3DLUT mode 3DLUT bit depth 3DLUT size RGAM mode GAMUT mode C11 C12 C13 C14 C21 C22 C23 C24 C31 C32 C33 C34 [ 0]:1 sRGBBypassRAM A RAM B 12-bit17x17x17 RAM A 0 h h h h h h [ 1]:1 sRGBBypassRAM B RAM A 12-bit17x17x17 RAM A 0 h h h h h h [ 2]:1 sRGBBypassRAM B RAM A 12-bit17x17x17 RAM A 0 h h h h h h [ 3]:1 sRGBBypassRAM A RAM B 12-bit17x17x17 RAM A 0 h h h h h h DPP Color Caps: input_lut_shared:0 icsc:1 dgam_ram:0 dgam_rom: srgb:1,bt2020:1,gamma2_2:1,pq:1,hlg:1 post_csc:1 gamcor:1 dgam_rom_for_yuv:0 3d_lut:1 blnd_lut:1 oscs:0 MPCC: OPP DPP MPCCBOT MODE ALPHA_MODE PREMULT OVERLAP_ONLY IDLE SHAPER mode 3DLUT_mode 3DLUT bit-depth 3DLUT size OGAM mode OGAM LUT GAMUT mode C11 C12 C33 C34 [ 0]: 0h 0h 2h 3 01 0 0 Bypass Bypass 12-bit17x17x17RAM A 0 h h [ 1]: 0h 1h fh 2 20 0 0 Bypass Bypass 12-bit17x17x17 Bypass A 0 h h [ 2]: 0h 2h 3h 3 01 0 0 Bypass Bypass 12-bit17x17x17 Bypass A 0 h h [ 3]: 0h 3h 1h 3 20 0 0 Bypass Bypass 12-bit17x17x17 Bypass A 0 h h MPC Color Caps: gamut_remap:1, 3dlut:2, ogam_ram:1, ocsc:1 I liked this new visualization. At some point, we need to document this information as a kernel-doc to make it easy to understand this DTN LOG. With this series (Steamdeck/KDE): DPP: DGAM ROM DGAM ROM type DGAM LUT SHAPER mode 3DLUT mode 3DLUT bit depth 3DLUT size RGAM mode GAMUT mode C11 C12 C13 C14 C21 C22 C23 C24 C31 C32 C33 C34 [ 0]:0 sRGBBypass Bypass Bypass 12-bit 9x9x9 Bypass 0 h h h h h h [ 3]:0 sRGBBypass Bypass Bypass 12-bit 9x9x9 Bypass 0 h h h h h h DPP Color Caps: input_lut_shared:0 icsc:1 dgam_ram:0 dgam_rom: srgb:1,bt2020:1,gamma2_2:1,pq:1,hlg:1 post_csc:1 gamcor:1
[PATCH v2 1/1] drm/i915/pxp: Add drm_dbgs for critical PXP events.
Debugging PXP issues can't even begin without understanding precedding
sequence of events. Add drm_dbg into the most important PXP events.
v2 : - remove __func__ since drm_dbg covers that (Jani).
- add timeout of the restart from front-end (Alan).
Signed-off-by: Alan Previn
---
drivers/gpu/drm/i915/gt/uc/intel_gsc_proxy.c | 2 ++
drivers/gpu/drm/i915/pxp/intel_pxp.c | 15 ---
drivers/gpu/drm/i915/pxp/intel_pxp_irq.c | 4 ++--
drivers/gpu/drm/i915/pxp/intel_pxp_session.c | 6 +-
drivers/gpu/drm/i915/pxp/intel_pxp_types.h | 1 +
5 files changed, 22 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_gsc_proxy.c
b/drivers/gpu/drm/i915/gt/uc/intel_gsc_proxy.c
index 5f138de3c14f..61216c4abaec 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_gsc_proxy.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_gsc_proxy.c
@@ -321,6 +321,7 @@ static int i915_gsc_proxy_component_bind(struct device
*i915_kdev,
mutex_lock(>proxy.mutex);
gsc->proxy.component = data;
gsc->proxy.component->mei_dev = mei_kdev;
+ gt_dbg(gt, "GSC proxy mei component bound\n");
mutex_unlock(>proxy.mutex);
return 0;
@@ -342,6 +343,7 @@ static void i915_gsc_proxy_component_unbind(struct device
*i915_kdev,
with_intel_runtime_pm(>runtime_pm, wakeref)
intel_uncore_rmw(gt->uncore, HECI_H_CSR(MTL_GSC_HECI2_BASE),
HECI_H_CSR_IE | HECI_H_CSR_RST, 0);
+ gt_dbg(gt, "GSC proxy mei component unbound\n");
}
static const struct component_ops i915_gsc_proxy_component_ops = {
diff --git a/drivers/gpu/drm/i915/pxp/intel_pxp.c
b/drivers/gpu/drm/i915/pxp/intel_pxp.c
index dc327cf40b5a..e11f562b1876 100644
--- a/drivers/gpu/drm/i915/pxp/intel_pxp.c
+++ b/drivers/gpu/drm/i915/pxp/intel_pxp.c
@@ -303,6 +303,8 @@ static int __pxp_global_teardown_final(struct intel_pxp
*pxp)
if (!pxp->arb_is_valid)
return 0;
+
+ drm_dbg(>ctrl_gt->i915->drm, "PXP: teardown for suspend/fini");
/*
* To ensure synchronous and coherent session teardown completion
* in response to suspend or shutdown triggers, don't use a worker.
@@ -324,6 +326,8 @@ static int __pxp_global_teardown_restart(struct intel_pxp
*pxp)
if (pxp->arb_is_valid)
return 0;
+
+ drm_dbg(>ctrl_gt->i915->drm, "PXP: teardown for restart");
/*
* The arb-session is currently inactive and we are doing a reset and
restart
* due to a runtime event. Use the worker that was designed for this.
@@ -332,8 +336,11 @@ static int __pxp_global_teardown_restart(struct intel_pxp
*pxp)
timeout = intel_pxp_get_backend_timeout_ms(pxp);
- if (!wait_for_completion_timeout(>termination,
msecs_to_jiffies(timeout)))
+ if (!wait_for_completion_timeout(>termination,
msecs_to_jiffies(timeout))) {
+ drm_dbg(>ctrl_gt->i915->drm, "PXP: restart backend timed
out (%d ms)",
+ timeout);
return -ETIMEDOUT;
+ }
return 0;
}
@@ -414,10 +421,12 @@ int intel_pxp_start(struct intel_pxp *pxp)
int ret = 0;
ret = intel_pxp_get_readiness_status(pxp, PXP_READINESS_TIMEOUT);
- if (ret < 0)
+ if (ret < 0) {
+ drm_dbg(>ctrl_gt->i915->drm, "PXP: tried but not-avail
(%d)", ret);
return ret;
- else if (ret > 1)
+ } else if (ret > 1) {
return -EIO; /* per UAPI spec, user may retry later */
+ }
mutex_lock(>arb_mutex);
diff --git a/drivers/gpu/drm/i915/pxp/intel_pxp_irq.c
b/drivers/gpu/drm/i915/pxp/intel_pxp_irq.c
index 91e9622c07d0..0637b1d36356 100644
--- a/drivers/gpu/drm/i915/pxp/intel_pxp_irq.c
+++ b/drivers/gpu/drm/i915/pxp/intel_pxp_irq.c
@@ -40,11 +40,11 @@ void intel_pxp_irq_handler(struct intel_pxp *pxp, u16 iir)
GEN12_DISPLAY_APP_TERMINATED_PER_FW_REQ_INTERRUPT)) {
/* immediately mark PXP as inactive on termination */
intel_pxp_mark_termination_in_progress(pxp);
- pxp->session_events |= PXP_TERMINATION_REQUEST |
PXP_INVAL_REQUIRED;
+ pxp->session_events |= PXP_TERMINATION_REQUEST |
PXP_INVAL_REQUIRED | PXP_EVENT_TYPE_IRQ;
}
if (iir & GEN12_DISPLAY_STATE_RESET_COMPLETE_INTERRUPT)
- pxp->session_events |= PXP_TERMINATION_COMPLETE;
+ pxp->session_events |= PXP_TERMINATION_COMPLETE |
PXP_EVENT_TYPE_IRQ;
if (pxp->session_events)
queue_work(system_unbound_wq, >session_work);
diff --git a/drivers/gpu/drm/i915/pxp/intel_pxp_session.c
b/drivers/gpu/drm/i915/pxp/intel_pxp_session.c
index 0a3e66b0265e..091c86e03d1a 100644
--- a/drivers/gpu/drm/i915/pxp/intel_pxp_session.c
+++ b/drivers/gpu/drm/i915/pxp/intel_pxp_session.c
@@ -137,8 +137,10 @@ void intel_pxp_terminate(struct intel_pxp *pxp, bool
post_invalidation_needs_res
static void
Re: [RFC PATCH v2 2/5] drm/amd/display: fill up DCN3 DPP color state
On 9/13/23 10:43, Melissa Wen wrote:
DCN3 DPP color state was uncollected and some state elements from DCN1
doesn't fit DCN3. Create new elements according to DCN3 color caps and
fill them up for DTN log output.
rfc-v2:
- fix reading of gamcor and blnd gamma states
Signed-off-by: Melissa Wen
---
.../gpu/drm/amd/display/dc/dcn30/dcn30_dpp.c | 45 +--
drivers/gpu/drm/amd/display/dc/inc/hw/dpp.h | 8
2 files changed, 50 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/amd/display/dc/dcn30/dcn30_dpp.c
b/drivers/gpu/drm/amd/display/dc/dcn30/dcn30_dpp.c
index 50dc83404644..a26b33c84ae0 100644
--- a/drivers/gpu/drm/amd/display/dc/dcn30/dcn30_dpp.c
+++ b/drivers/gpu/drm/amd/display/dc/dcn30/dcn30_dpp.c
@@ -44,11 +44,50 @@
void dpp30_read_state(struct dpp *dpp_base, struct dcn_dpp_state *s)
{
struct dcn3_dpp *dpp = TO_DCN30_DPP(dpp_base);
+ uint32_t gamcor_lut_mode, rgam_lut_mode;
REG_GET(DPP_CONTROL,
- DPP_CLOCK_ENABLE, >is_enabled);
-
- // TODO: Implement for DCN3
+ DPP_CLOCK_ENABLE, >is_enabled);
+ // Pre-degamma (ROM)
+ REG_GET_2(PRE_DEGAM,
+ PRE_DEGAM_MODE, >pre_dgam_mode,
+ PRE_DEGAM_SELECT, >pre_dgam_select);
nitpick:
Add a new line before each comment in this function.
+ // Gamma Correction (RAM)
+ REG_GET(CM_GAMCOR_CONTROL,
+ CM_GAMCOR_MODE_CURRENT, >gamcor_mode);
+ if (s->gamcor_mode) {
+ REG_GET(CM_GAMCOR_CONTROL, CM_GAMCOR_SELECT_CURRENT,
_lut_mode);
+ if (!gamcor_lut_mode)
+ s->gamcor_mode = LUT_RAM_A; // Otherwise, LUT_RAM_B
+ }
+ // Shaper LUT (RAM), 3D LUT (mode, bit-depth, size)
+ REG_GET(CM_SHAPER_CONTROL,
+ CM_SHAPER_LUT_MODE, >shaper_lut_mode);
+ REG_GET(CM_3DLUT_MODE,
+ CM_3DLUT_MODE_CURRENT, >lut3d_mode);
+ REG_GET(CM_3DLUT_READ_WRITE_CONTROL,
+ CM_3DLUT_30BIT_EN, >lut3d_bit_depth);
+ REG_GET(CM_3DLUT_MODE,
+ CM_3DLUT_SIZE, >lut3d_size);
+ // Gamut Remap Matrix (3x4)
+ REG_GET(CM_GAMUT_REMAP_CONTROL,
+ CM_GAMUT_REMAP_MODE, >gamut_remap_mode);
+ if (s->gamut_remap_mode) {
+ s->gamut_remap_c11_c12 = REG_READ(CM_GAMUT_REMAP_C11_C12);
+ s->gamut_remap_c13_c14 = REG_READ(CM_GAMUT_REMAP_C13_C14);
+ s->gamut_remap_c21_c22 = REG_READ(CM_GAMUT_REMAP_C21_C22);
+ s->gamut_remap_c23_c24 = REG_READ(CM_GAMUT_REMAP_C23_C24);
+ s->gamut_remap_c31_c32 = REG_READ(CM_GAMUT_REMAP_C31_C32);
+ s->gamut_remap_c33_c34 = REG_READ(CM_GAMUT_REMAP_C33_C34);
+ }
+ // Blend/Out Gamma (RAM)
+ REG_GET(CM_BLNDGAM_CONTROL,
+ CM_BLNDGAM_MODE_CURRENT, >rgam_lut_mode);
+ if (s->rgam_lut_mode){
+ REG_GET(CM_BLNDGAM_CONTROL, CM_BLNDGAM_SELECT_CURRENT,
_lut_mode);
+ if (!rgam_lut_mode)
+ s->rgam_lut_mode = LUT_RAM_A; // Otherwise, LUT_RAM_B
+ }
}
/*program post scaler scs block in dpp CM*/
void dpp3_program_post_csc(
diff --git a/drivers/gpu/drm/amd/display/dc/inc/hw/dpp.h
b/drivers/gpu/drm/amd/display/dc/inc/hw/dpp.h
index f4aa76e02518..1dfe08dc4364 100644
--- a/drivers/gpu/drm/amd/display/dc/inc/hw/dpp.h
+++ b/drivers/gpu/drm/amd/display/dc/inc/hw/dpp.h
@@ -148,6 +148,14 @@ struct dcn_dpp_state {
uint32_t gamut_remap_c23_c24;
uint32_t gamut_remap_c31_c32;
uint32_t gamut_remap_c33_c34;
+ uint32_t shaper_lut_mode;
+ uint32_t lut3d_mode;
+ uint32_t lut3d_bit_depth;
+ uint32_t lut3d_size;
+ uint32_t blnd_lut_mode;
+ uint32_t pre_dgam_mode;
+ uint32_t pre_dgam_select;
+ uint32_t gamcor_mode;
};
struct CM_bias_params {
Re: [RFC PATCH v2 1/5] drm/amd/display: detach color state from hw state logging
On 9/13/23 10:43, Melissa Wen wrote:
Prepare to hook color state logging according to DCN version.
Signed-off-by: Melissa Wen
---
.../amd/display/dc/dcn10/dcn10_hw_sequencer.c | 27 +--
1 file changed, 19 insertions(+), 8 deletions(-)
diff --git a/drivers/gpu/drm/amd/display/dc/dcn10/dcn10_hw_sequencer.c
b/drivers/gpu/drm/amd/display/dc/dcn10/dcn10_hw_sequencer.c
index 79befa17bb03..a0c489ed218c 100644
--- a/drivers/gpu/drm/amd/display/dc/dcn10/dcn10_hw_sequencer.c
+++ b/drivers/gpu/drm/amd/display/dc/dcn10/dcn10_hw_sequencer.c
@@ -279,19 +279,14 @@ static void dcn10_log_hubp_states(struct dc *dc, void
*log_ctx)
DTN_INFO("\n");
}
-void dcn10_log_hw_state(struct dc *dc,
- struct dc_log_buffer_ctx *log_ctx)
+static void
+dcn10_log_color_state(struct dc *dc,
+ struct dc_log_buffer_ctx *log_ctx)
nitpick:
put the function definition in a single line.
{
struct dc_context *dc_ctx = dc->ctx;
struct resource_pool *pool = dc->res_pool;
int i;
- DTN_INFO_BEGIN();
-
- dcn10_log_hubbub_state(dc, log_ctx);
-
- dcn10_log_hubp_states(dc, log_ctx);
-
DTN_INFO("DPP:IGAM format IGAM modeDGAM modeRGAM mode"
" GAMUT mode C11 C12 C13 C14 C21 C22 C23 C24 "
"C31 C32 C33 C34\n");
@@ -348,6 +343,22 @@ void dcn10_log_hw_state(struct dc *dc,
s.idle);
}
DTN_INFO("\n");
+}
+
+void dcn10_log_hw_state(struct dc *dc,
+ struct dc_log_buffer_ctx *log_ctx)
ditto
+{
+ struct dc_context *dc_ctx = dc->ctx;
+ struct resource_pool *pool = dc->res_pool;
+ int i;
+
+ DTN_INFO_BEGIN();
+
+ dcn10_log_hubbub_state(dc, log_ctx);
+
+ dcn10_log_hubp_states(dc, log_ctx);
+
+ dcn10_log_color_state(dc, log_ctx);
DTN_INFO("OTG: v_bs v_be v_ss v_se vpol vmax vmin vmax_sel vmin_sel h_bs h_be h_ss h_se hpol htot vtot underflow blank_en\n");
Re: [Patch v2 2/3] drm/mst: Refactor the flow for payload allocation/removement
On Mon, Sep 04, 2023 at 06:58:20AM +, Lin, Wayne wrote: > [Public] > > Thank you Lyude and Alex! This patch had i915 changes, please also Cc the intel-...@lists.freedesktop.org list for such patchsets, so that we get CI test results for it. Also, I think patches with i915 changes need an Ack from an i915 developer before pushing. Thanks, Imre > Regards, > Wayne > > -Original Message- > > From: Alex Deucher > > Sent: Saturday, September 2, 2023 3:38 AM > > To: Lyude Paul > > Cc: Lin, Wayne ; dri-devel@lists.freedesktop.org; > > amd-...@lists.freedesktop.org; jani.nik...@intel.com; imre.d...@intel.com; > > Wentland, Harry ; Zuo, Jerry > > ; ville.syrj...@linux.intel.com > > Subject: Re: [Patch v2 2/3] drm/mst: Refactor the flow for payload > > allocation/removement > > > > On Thu, Aug 31, 2023 at 6:45 PM Lyude Paul wrote: > > > > > > On Thu, 2023-08-24 at 04:12 +, Lin, Wayne wrote: > > > > [Public] > > > > > > > > Hi Lyude, > > > > > > > > I'm afraid that I don't have the permissions to push and would like > > > > to have your help. Thanks! > > > > > > Whoops, sorry I only just noticed this message. I set a reminder on my > > > phone to bug me to push it tomorrow :), sorry about the delay > > > > > > > Wayne, I don't see why we couldn't give you commit permissions for drm- > > misc. > > > > Alex > > > > > > > > > > > -Original Message- > > > > > From: Lyude Paul > > > > > Sent: Thursday, August 24, 2023 5:00 AM > > > > > To: Lin, Wayne ; > > > > > dri-devel@lists.freedesktop.org; amd-...@lists.freedesktop.org > > > > > Cc: jani.nik...@intel.com; ville.syrj...@linux.intel.com; > > > > > imre.d...@intel.com; Wentland, Harry ; > > > > > Zuo, Jerry > > > > > Subject: Re: [Patch v2 2/3] drm/mst: Refactor the flow for payload > > > > > allocation/removement > > > > > > > > > > Sure - you're also welcome to push the first two patches after > > > > > fixing the indentation if you'd like > > > > > > > > > > On Wed, 2023-08-23 at 03:19 +, Lin, Wayne wrote: > > > > > > [Public] > > > > > > > > > > > > Thanks, Lyude! > > > > > > Should I push another version to fix the indention? > > > > > > > > > > > > > -Original Message- > > > > > > > From: Lyude Paul > > > > > > > Sent: Friday, August 18, 2023 6:17 AM > > > > > > > To: Lin, Wayne ; > > > > > > > dri-devel@lists.freedesktop.org; amd-...@lists.freedesktop.org > > > > > > > Cc: jani.nik...@intel.com; ville.syrj...@linux.intel.com; > > > > > > > imre.d...@intel.com; Wentland, Harry ; > > > > > > > Zuo, Jerry > > > > > > > Subject: Re: [Patch v2 2/3] drm/mst: Refactor the flow for > > > > > > > payload allocation/removement > > > > > > > > > > > > > > Two small comments: > > > > > > > > > > > > > > On Mon, 2023-08-07 at 10:56 +0800, Wayne Lin wrote: > > > > > > > > [Why] > > > > > > > > Today, the allocation/deallocation steps and status is a bit > > > > > > > > unclear. > > > > > > > > > > > > > > > > For instance, payload->vc_start_slot = -1 stands for "the > > > > > > > > failure of updating DPCD payload ID table" and can also > > > > > > > > represent as "payload is not allocated yet". These two cases > > > > > > > > should be handled differently and hence better to distinguish > > > > > > > > them > > for better understanding. > > > > > > > > > > > > > > > > [How] > > > > > > > > Define enumeration - ALLOCATION_LOCAL, ALLOCATION_DFP and > > > > > > > > ALLOCATION_REMOTE to distinguish different allocation status. > > > > > > > > Adjust the code to handle different status accordingly for > > > > > > > > better understanding the sequence of payload allocation and > > > > > > > > payload > > > > > > > removement. > > > > > > > > > > > > > > > > For payload creation, the procedure should look like this: > > > > > > > > DRM part 1: > > > > > > > > * step 1 - update sw mst mgr variables to add a new payload > > > > > > > > * step 2 - add payload at immediate DFP DPCD payload table > > > > > > > > > > > > > > > > Driver: > > > > > > > > * Add new payload in HW and sync up with DFP by sending ACT > > > > > > > > > > > > > > > > DRM Part 2: > > > > > > > > * Send ALLOCATE_PAYLOAD sideband message to allocate > > > > > > > > bandwidth along > > > > > > > the > > > > > > > > virtual channel. > > > > > > > > > > > > > > > > And as for payload removement, the procedure should look like > > > > > > > > this: > > > > > > > > DRM part 1: > > > > > > > > * step 1 - Send ALLOCATE_PAYLOAD sideband message to release > > > > > bandwidth > > > > > > > >along the virtual channel > > > > > > > > * step 2 - Clear payload allocation at immediate DFP DPCD > > > > > > > > payload table > > > > > > > > > > > > > > > > Driver: > > > > > > > > * Remove the payload in HW and sync up with DFP by sending > > > > > > > > ACT > > > > > > > > > > > > > > > > DRM part 2: > > > > > > > > * update sw mst mgr variables to remove the payload > > > > > > > > > > > > > > > > Note that it's fine to fail when communicate with the branch > > > >
[PATCH 3/4] drm/dp_mst: Tune down error message during payload addition
If a sink is removed in the middle of payload addition the corresponding
AUX transfer will fail as expected, so tune the error message down to a
debug messge.
Cc: Wayne Lin
Cc: Lyude Paul
Cc: dri-devel@lists.freedesktop.org
Signed-off-by: Imre Deak
---
drivers/gpu/drm/display/drm_dp_mst_topology.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/display/drm_dp_mst_topology.c
b/drivers/gpu/drm/display/drm_dp_mst_topology.c
index dbec9cf004594..c490e8befc2fa 100644
--- a/drivers/gpu/drm/display/drm_dp_mst_topology.c
+++ b/drivers/gpu/drm/display/drm_dp_mst_topology.c
@@ -3332,8 +3332,8 @@ int drm_dp_add_payload_part1(struct
drm_dp_mst_topology_mgr *mgr,
ret = drm_dp_create_payload_at_dfp(mgr, payload);
if (ret < 0) {
- drm_warn(mgr->dev, "Failed to create MST payload for port %p:
%d\n",
-payload->port, ret);
+ drm_dbg_kms(mgr->dev, "Failed to create MST payload for port
%p: %d\n",
+ payload->port, ret);
goto put_port;
}
--
2.37.2
[PATCH 2/4] drm/dp_mst: Sanitize error return during payload addition
Return an error during payload addition if the payload port isn't
found. This shouldn't change the behavior since only the i915 driver
checks the return value, printing an error message in case of a failure.
While at it simplify the control flow.
Cc: Wayne Lin
Cc: Lyude Paul
Cc: dri-devel@lists.freedesktop.org
Signed-off-by: Imre Deak
---
drivers/gpu/drm/display/drm_dp_mst_topology.c | 26 +--
1 file changed, 12 insertions(+), 14 deletions(-)
diff --git a/drivers/gpu/drm/display/drm_dp_mst_topology.c
b/drivers/gpu/drm/display/drm_dp_mst_topology.c
index 5f90860d49c34..dbec9cf004594 100644
--- a/drivers/gpu/drm/display/drm_dp_mst_topology.c
+++ b/drivers/gpu/drm/display/drm_dp_mst_topology.c
@@ -3308,8 +3308,7 @@ int drm_dp_add_payload_part1(struct
drm_dp_mst_topology_mgr *mgr,
struct drm_dp_mst_atomic_payload *payload)
{
struct drm_dp_mst_port *port;
- int ret = 0;
- bool allocate = true;
+ int ret;
/* Update mst mgr info */
if (mgr->payload_count == 0)
@@ -3320,29 +3319,28 @@ int drm_dp_add_payload_part1(struct
drm_dp_mst_topology_mgr *mgr,
mgr->payload_count++;
mgr->next_start_slot += payload->time_slots;
+ payload->payload_allocation_status =
DRM_DP_MST_PAYLOAD_ALLOCATION_LOCAL;
+
/* Allocate payload to immediate downstream facing port */
port = drm_dp_mst_topology_get_port_validated(mgr, payload->port);
if (!port) {
drm_dbg_kms(mgr->dev,
"VCPI %d for port %p not in topology, not creating
a payload to remote\n",
payload->vcpi, payload->port);
- allocate = false;
+ return -EIO;
}
- if (allocate) {
- ret = drm_dp_create_payload_at_dfp(mgr, payload);
- if (ret < 0)
- drm_warn(mgr->dev, "Failed to create MST payload for
port %p: %d\n",
-payload->port, ret);
-
+ ret = drm_dp_create_payload_at_dfp(mgr, payload);
+ if (ret < 0) {
+ drm_warn(mgr->dev, "Failed to create MST payload for port %p:
%d\n",
+payload->port, ret);
+ goto put_port;
}
- payload->payload_allocation_status =
- (!allocate || ret < 0) ? DRM_DP_MST_PAYLOAD_ALLOCATION_LOCAL :
-
DRM_DP_MST_PAYLOAD_ALLOCATION_DFP;
+ payload->payload_allocation_status = DRM_DP_MST_PAYLOAD_ALLOCATION_DFP;
- if (port)
- drm_dp_mst_topology_put_port(port);
+put_port:
+ drm_dp_mst_topology_put_port(port);
return ret;
}
--
2.37.2
[PATCH 1/4] drm/dp_mst: Fix NULL dereference during payload addition
Fix the NULL dereference leading to the following stack trace:
[ 129.687181] i915 :00:02.0: [drm:drm_dp_add_payload_part1
[drm_display_helper]] VCPI 1 for port 5be4423e not in topology, not
creating a payload to remote
[ 129.687257] BUG: kernel NULL pointer dereference, address: 0560
[ 129.694276] #PF: supervisor read access in kernel mode
[ 129.699459] #PF: error_code(0x) - not-present page
[ 129.704612] PGD 0 P4D 0
[ 129.707178] Oops: [#1] PREEMPT SMP NOPTI
[ 129.711556] CPU: 2 PID: 1623 Comm: Xorg Tainted: G U
6.6.0-rc1-imre+ #985
[ 129.719744] Hardware name: Intel Corporation Alder Lake Client
Platform/AlderLake-P DDR5 RVP, BIOS RPLPFWI1.R00.4035.A00.2301200723 01/20/2023
[ 129.732509] RIP: 0010:drm_dp_mst_topology_put_port+0x19/0x170
[drm_display_helper]
[ 129.740111] Code: 00 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 0f 1f
44 00 00 55 48 89 e5 41 57 41 56 41 55 41 54 53 48 89 fb 48 83 ec 08 <48> 8b 87
60 05 00 00 44 8b 0f 48 8b 70 58 41 83 e9 01 48 85 f6 74
[ 129.758842] RSP: 0018:c90001daf900 EFLAGS: 00010286
[ 129.764104] RAX: 0001 RBX: RCX:
[ 129.771246] RDX: RSI: 9e73d613 RDI:
[ 129.778394] RBP: c90001daf930 R08: R09: 0020
[ 129.785533] R10: 0010 R11: 000f R12: 888116c65e40
[ 129.792680] R13: R14: R15:
[ 129.799822] FS: 7f39f74b1a80() GS:88840f68()
knlGS:
[ 129.807913] CS: 0010 DS: ES: CR0: 80050033
[ 129.813670] CR2: 0560 CR3: 000138b88000 CR4: 00750ee0
[ 129.820815] PKRU: 5554
[ 129.823551] Call Trace:
[ 129.826022]
[ 129.828154] ? show_regs+0x65/0x70
[ 129.831599] ? __die+0x24/0x70
[ 129.834683] ? page_fault_oops+0x160/0x480
[ 129.838824] ? dev_printk_emit+0x83/0xb0
[ 129.842797] ? do_user_addr_fault+0x2e2/0x680
[ 129.847175] ? exc_page_fault+0x78/0x180
[ 129.851143] ? asm_exc_page_fault+0x27/0x30
[ 129.855353] ? drm_dp_mst_topology_put_port+0x19/0x170 [drm_display_helper]
[ 129.862354] drm_dp_add_payload_part1+0x85/0x100 [drm_display_helper]
[ 129.868832] intel_mst_pre_enable_dp+0x1ef/0x240 [i915]
[ 129.874170] intel_encoders_pre_enable+0x83/0xa0 [i915]
[ 129.879524] hsw_crtc_enable+0xbe/0x750 [i915]
[ 129.884095] intel_enable_crtc+0x68/0xa0 [i915]
[ 129.888752] skl_commit_modeset_enables+0x2c4/0x5d0 [i915]
[ 129.894365] intel_atomic_commit_tail+0x765/0x1070 [i915]
[ 129.899885] intel_atomic_commit+0x3ba/0x400 [i915]
[ 129.904892] drm_atomic_commit+0x96/0xd0 [drm]
[ 129.909405] ? __pfx___drm_printfn_info+0x10/0x10 [drm]
[ 129.914698] drm_atomic_helper_set_config+0x7e/0xc0 [drm_kms_helper]
[ 129.921102] drm_mode_setcrtc+0x5af/0x8d0 [drm]
[ 129.925695] ? __pfx_drm_mode_setcrtc+0x10/0x10 [drm]
[ 129.930810] drm_ioctl_kernel+0xc4/0x170 [drm]
[ 129.935317] drm_ioctl+0x2a4/0x520 [drm]
[ 129.939305] ? __pfx_drm_mode_setcrtc+0x10/0x10 [drm]
[ 129.944415] ? __fget_light+0xa5/0x110
[ 129.948212] __x64_sys_ioctl+0x98/0xd0
[ 129.951985] do_syscall_64+0x37/0x90
[ 129.955581] entry_SYSCALL_64_after_hwframe+0x6e/0xd8
Fixes: 5aa1dfcdf0a4 ("drm/mst: Refactor the flow for payload
allocation/removement")
Cc: Wayne Lin
Cc: Lyude Paul
Cc: dri-devel@lists.freedesktop.org
Signed-off-by: Imre Deak
---
drivers/gpu/drm/display/drm_dp_mst_topology.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/display/drm_dp_mst_topology.c
b/drivers/gpu/drm/display/drm_dp_mst_topology.c
index e04f87ff755ac..5f90860d49c34 100644
--- a/drivers/gpu/drm/display/drm_dp_mst_topology.c
+++ b/drivers/gpu/drm/display/drm_dp_mst_topology.c
@@ -3341,7 +3341,8 @@ int drm_dp_add_payload_part1(struct
drm_dp_mst_topology_mgr *mgr,
(!allocate || ret < 0) ? DRM_DP_MST_PAYLOAD_ALLOCATION_LOCAL :
DRM_DP_MST_PAYLOAD_ALLOCATION_DFP;
- drm_dp_mst_topology_put_port(port);
+ if (port)
+ drm_dp_mst_topology_put_port(port);
return ret;
}
--
2.37.2
Re: [PATCH v1 1/1] drm/i915/pxp: Add drm_dbgs for critical PXP events.
On Mon, 2023-09-11 at 12:26 +0300, Jani Nikula wrote: > On Wed, 06 Sep 2023, Alan Previn wrote: > > Debugging PXP issues can't even begin without understanding precedding > > sequence of events. Add drm_dbg into the most important PXP events. > > > > Signed-off-by: Alan Previn alan:snip > > > + > > + drm_dbg(>ctrl_gt->i915->drm, "PXP: %s invoked", __func__); > > drm_dbg already covers __func__ (via __builtin_return_address(0) in > __drm_dev_dbg), it's redundant. > > Ditto for all added debugs below. My bad - yup - will fix them. Thanks for taking time to review this patch. ...alan >
Re: [RFC PATCH 1/8] drm/panel: nv3052c: Document known register names
On 9/11/2023 2:01 AM, John Watts wrote:
Many of these registers have a known name in the public datasheet.
Document them as comments for reference.
Signed-off-by: John Watts
---
.../gpu/drm/panel/panel-newvision-nv3052c.c | 261 +-
1 file changed, 132 insertions(+), 129 deletions(-)
diff --git a/drivers/gpu/drm/panel/panel-newvision-nv3052c.c
b/drivers/gpu/drm/panel/panel-newvision-nv3052c.c
index 71e57de6d8b2..589431523ce7 100644
--- a/drivers/gpu/drm/panel/panel-newvision-nv3052c.c
+++ b/drivers/gpu/drm/panel/panel-newvision-nv3052c.c
@@ -42,9 +42,9 @@ struct nv3052c_reg {
};
static const struct nv3052c_reg nv3052c_panel_regs[] = {
- { 0xff, 0x30 },
- { 0xff, 0x52 },
- { 0xff, 0x01 },
+ // EXTC Command set enable, select page 1
+ { 0xff, 0x30 }, { 0xff, 0x52 }, { 0xff, 0x01 },
+ // Mostly unknown registers
Hi John,
Just curious, what do you mean by these registers being mostly unknown?
I do see them specified in the online specs -- some even seem to map to
existing MIPI_DCS_* enums (ex. 0x01 to MIPI_DCS_SOFT_RESET, and 0x04 to
MIPI_DCS_GET_DISPLAY_ID).
Thanks,
Jessica Zhang
{ 0xe3, 0x00 },
{ 0x40, 0x00 },
{ 0x03, 0x40 },
@@ -62,15 +62,15 @@ static const struct nv3052c_reg nv3052c_panel_regs[] = {
{ 0x25, 0x06 },
{ 0x26, 0x14 },
{ 0x27, 0x14 },
- { 0x38, 0xcc },
- { 0x39, 0xd7 },
- { 0x3a, 0x4a },
+ { 0x38, 0xcc }, // VCOM_ADJ1
+ { 0x39, 0xd7 }, // VCOM_ADJ2
+ { 0x3a, 0x4a }, // VCOM_ADJ3
{ 0x28, 0x40 },
{ 0x29, 0x01 },
{ 0x2a, 0xdf },
{ 0x49, 0x3c },
- { 0x91, 0x77 },
- { 0x92, 0x77 },
+ { 0x91, 0x77 }, // EXTPW_CTRL2
+ { 0x92, 0x77 }, // EXTPW_CTRL3
{ 0xa0, 0x55 },
{ 0xa1, 0x50 },
{ 0xa4, 0x9c },
@@ -94,123 +94,126 @@ static const struct nv3052c_reg nv3052c_panel_regs[] = {
{ 0xb8, 0x26 },
{ 0xf0, 0x00 },
{ 0xf6, 0xc0 },
- { 0xff, 0x30 },
- { 0xff, 0x52 },
- { 0xff, 0x02 },
- { 0xb0, 0x0b },
- { 0xb1, 0x16 },
- { 0xb2, 0x17 },
- { 0xb3, 0x2c },
- { 0xb4, 0x32 },
- { 0xb5, 0x3b },
- { 0xb6, 0x29 },
- { 0xb7, 0x40 },
- { 0xb8, 0x0d },
- { 0xb9, 0x05 },
- { 0xba, 0x12 },
- { 0xbb, 0x10 },
- { 0xbc, 0x12 },
- { 0xbd, 0x15 },
- { 0xbe, 0x19 },
- { 0xbf, 0x0e },
- { 0xc0, 0x16 },
- { 0xc1, 0x0a },
- { 0xd0, 0x0c },
- { 0xd1, 0x17 },
- { 0xd2, 0x14 },
- { 0xd3, 0x2e },
- { 0xd4, 0x32 },
- { 0xd5, 0x3c },
- { 0xd6, 0x22 },
- { 0xd7, 0x3d },
- { 0xd8, 0x0d },
- { 0xd9, 0x07 },
- { 0xda, 0x13 },
- { 0xdb, 0x13 },
- { 0xdc, 0x11 },
- { 0xdd, 0x15 },
- { 0xde, 0x19 },
- { 0xdf, 0x10 },
- { 0xe0, 0x17 },
- { 0xe1, 0x0a },
- { 0xff, 0x30 },
- { 0xff, 0x52 },
- { 0xff, 0x03 },
- { 0x00, 0x2a },
- { 0x01, 0x2a },
- { 0x02, 0x2a },
- { 0x03, 0x2a },
- { 0x04, 0x61 },
- { 0x05, 0x80 },
- { 0x06, 0xc7 },
- { 0x07, 0x01 },
- { 0x08, 0x03 },
- { 0x09, 0x04 },
- { 0x70, 0x22 },
- { 0x71, 0x80 },
- { 0x30, 0x2a },
- { 0x31, 0x2a },
- { 0x32, 0x2a },
- { 0x33, 0x2a },
- { 0x34, 0x61 },
- { 0x35, 0xc5 },
- { 0x36, 0x80 },
- { 0x37, 0x23 },
- { 0x40, 0x03 },
- { 0x41, 0x04 },
- { 0x42, 0x05 },
- { 0x43, 0x06 },
- { 0x44, 0x11 },
- { 0x45, 0xe8 },
- { 0x46, 0xe9 },
- { 0x47, 0x11 },
- { 0x48, 0xea },
- { 0x49, 0xeb },
- { 0x50, 0x07 },
- { 0x51, 0x08 },
- { 0x52, 0x09 },
- { 0x53, 0x0a },
- { 0x54, 0x11 },
- { 0x55, 0xec },
- { 0x56, 0xed },
- { 0x57, 0x11 },
- { 0x58, 0xef },
- { 0x59, 0xf0 },
- { 0xb1, 0x01 },
- { 0xb4, 0x15 },
- { 0xb5, 0x16 },
- { 0xb6, 0x09 },
- { 0xb7, 0x0f },
- { 0xb8, 0x0d },
- { 0xb9, 0x0b },
- { 0xba, 0x00 },
- { 0xc7, 0x02 },
- { 0xca, 0x17 },
- { 0xcb, 0x18 },
- { 0xcc, 0x0a },
- { 0xcd, 0x10 },
- { 0xce, 0x0e },
- { 0xcf, 0x0c },
- { 0xd0, 0x00 },
- { 0x81, 0x00 },
- { 0x84, 0x15 },
- { 0x85, 0x16 },
- { 0x86, 0x10 },
- { 0x87, 0x0a },
- { 0x88, 0x0c },
- { 0x89, 0x0e },
- { 0x8a, 0x02 },
- { 0x97, 0x00 },
- { 0x9a, 0x17 },
- { 0x9b, 0x18 },
- { 0x9c, 0x0f },
- { 0x9d, 0x09 },
- { 0x9e, 0x0b },
- { 0x9f, 0x0d },
- { 0xa0, 0x01 },
- { 0xff, 0x30 },
- { 0xff, 0x52 },
- { 0xff, 0x02 },
+ // EXTC Command set enable, select page 2
+ { 0xff, 0x30 }, { 0xff, 0x52 }, { 0xff, 0x02 },
+ // Set gray scale voltage to adjust gamma
+
Re: [RFC PATCH 5/8] drm/panel: nv3052c: Allow specifying registers per panel
On 9/11/2023 2:02 AM, John Watts wrote:
Panel initialization registers are per-display and not tied to the
controller itself. Different panels will specify their own registers.
Attach the sequences to the panel info struct so future panels
can specify their own sequences.
Signed-off-by: John Watts
---
.../gpu/drm/panel/panel-newvision-nv3052c.c | 25 ---
1 file changed, 16 insertions(+), 9 deletions(-)
diff --git a/drivers/gpu/drm/panel/panel-newvision-nv3052c.c
b/drivers/gpu/drm/panel/panel-newvision-nv3052c.c
index 307335d0f1fc..b2ad9b3a5eb7 100644
--- a/drivers/gpu/drm/panel/panel-newvision-nv3052c.c
+++ b/drivers/gpu/drm/panel/panel-newvision-nv3052c.c
@@ -20,11 +20,18 @@
#include
#include
+struct nv3052c_reg {
+ u8 cmd;
+ u8 val;
+};
+
struct nv3052c_panel_info {
const struct drm_display_mode *display_modes;
unsigned int num_modes;
u16 width_mm, height_mm;
u32 bus_format, bus_flags;
+ const struct nv3052c_reg *panel_regs;
+ int panel_regs_len;
Hi John,
Having a separate panel_regs_len field seems a bit unnecessary to me.
Looks like it's only being called in the panel prepare() and I don't
seen any reason why we shouldn't just call the ARRAY_SIZE() macro there.
Thanks,
Jessica Zhang
};
struct nv3052c {
@@ -36,12 +43,7 @@ struct nv3052c {
struct gpio_desc *reset_gpio;
};
-struct nv3052c_reg {
- u8 cmd;
- u8 val;
-};
-
-static const struct nv3052c_reg nv3052c_panel_regs[] = {
+static const struct nv3052c_reg ltk035c5444t_panel_regs[] = {
// EXTC Command set enable, select page 1
{ 0xff, 0x30 }, { 0xff, 0x52 }, { 0xff, 0x01 },
// Mostly unknown registers
@@ -244,6 +246,7 @@ static inline struct nv3052c *to_nv3052c(struct drm_panel
*panel)
static int nv3052c_prepare(struct drm_panel *panel)
{
struct nv3052c *priv = to_nv3052c(panel);
+ const struct nv3052c_reg *panel_regs = priv->panel_info->panel_regs;
struct mipi_dbi *dbi = >dbi;
unsigned int i;
int err;
@@ -260,9 +263,11 @@ static int nv3052c_prepare(struct drm_panel *panel)
gpiod_set_value_cansleep(priv->reset_gpio, 0);
msleep(150);
- for (i = 0; i < ARRAY_SIZE(nv3052c_panel_regs); i++) {
- err = mipi_dbi_command(dbi, nv3052c_panel_regs[i].cmd,
- nv3052c_panel_regs[i].val);
+ int panel_regs_len = priv->panel_info->panel_regs_len;
+
+ for (i = 0; i < panel_regs_len; i++) {
+ err = mipi_dbi_command(dbi, panel_regs[i].cmd,
+ panel_regs[i].val);
if (err) {
dev_err(priv->dev, "Unable to set register: %d\n", err);
@@ -466,6 +471,8 @@ static const struct nv3052c_panel_info
ltk035c5444t_panel_info = {
.height_mm = 64,
.bus_format = MEDIA_BUS_FMT_RGB888_1X24,
.bus_flags = DRM_BUS_FLAG_DE_HIGH | DRM_BUS_FLAG_PIXDATA_DRIVE_NEGEDGE,
+ .panel_regs = ltk035c5444t_panel_regs,
+ .panel_regs_len = ARRAY_SIZE(ltk035c5444t_panel_regs),
};
static const struct spi_device_id nv3052c_ids[] = {
--
2.42.0
Re: [PATCH] drm/amd/display: Fix -Wuninitialized in dm_helpers_dp_mst_send_payload_allocation()
On Wed, Sep 13, 2023 at 4:46 PM Hamza Mahfooz wrote:
>
> On 9/13/23 16:03, Alex Deucher wrote:
> > On Wed, Sep 13, 2023 at 3:57 PM Hamza Mahfooz wrote:
> >>
> >>
> >> On 9/13/23 15:54, Alex Deucher wrote:
> >>> On Wed, Sep 13, 2023 at 12:17 PM Hamza Mahfooz
> >>> wrote:
> >>>>
> >>>>
> >>>> On 9/13/23 12:10, Nathan Chancellor wrote:
> >>>>> When building with clang, there is a warning (or error when
> >>>>> CONFIG_WERROR is set):
> >>>>>
> >>>>>
> >>>>> drivers/gpu/drm/amd/amdgpu/../display/amdgpu_dm/amdgpu_dm_helpers.c:368:21:
> >>>>> error: variable 'old_payload' is uninitialized when used here
> >>>>> [-Werror,-Wuninitialized]
> >>>>>368 |
> >>>>> new_payload, old_payload);
> >>>>>|
> >>>>>^~~
> >>>>>
> >>>>> drivers/gpu/drm/amd/amdgpu/../display/amdgpu_dm/amdgpu_dm_helpers.c:344:61:
> >>>>> note: initialize the variable 'old_payload' to silence this warning
> >>>>>344 | struct drm_dp_mst_atomic_payload *new_payload,
> >>>>> *old_payload;
> >>>>>|
> >>>>> ^
> >>>>>|
> >>>>> = NULL
> >>>>> 1 error generated.
> >>>>>
> >>>>> This variable is not required outside of this function so allocate
> >>>>> old_payload on the stack and pass it by reference to
> >>>>> dm_helpers_construct_old_payload(), resolving the warning.
> >>>>>
> >>>>> Closes: https://github.com/ClangBuiltLinux/linux/issues/1931
> >>>>> Fixes: 5aa1dfcdf0a4 ("drm/mst: Refactor the flow for payload
> >>>>> allocation/removement")
> >>>>> Signed-off-by: Nathan Chancellor
> >>>>
> >>>> Reviewed-by: Hamza Mahfooz
> >>>>
> >>>> Hm, seems like this was pushed through drm-misc-next and as such our CI
> >>>> didn't get a chance to test it.
> >>>
> >>> Can you push this to drm-misc? That is where Wayne's patches landed.
> >>> If not, I can push it.
> >>
> >> No need, I cherry-picked Wayne's patches to amd-staging-drm-next and
> >> applied Nathan's fix.
> >
> > Yes, but we can only have patches go upstream via one tree. Wayne's
> > patches are in drm-misc, so that is where the fix should be. It's
> > fine to have them in amd-staging-drm-next for testing purposes, but I
> > won't be upstreaming them via the amdgpu -next tree since they are
> > already in drm-misc.
>
> In that case can you push it to drm-misc?
Pushed. Thanks!
Alex
Alex
>
> >
> > Alex
> >
> >>
> >>>
> >>> Alex
> >>>
> >>>
> >>>>
> >>>>
> >>>>> ---
> >>>>> drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_helpers.c | 6 +++---
> >>>>> 1 file changed, 3 insertions(+), 3 deletions(-)
> >>>>>
> >>>>> diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_helpers.c
> >>>>> b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_helpers.c
> >>>>> index 9ad509279b0a..c4c35f6844f4 100644
> >>>>> --- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_helpers.c
> >>>>> +++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_helpers.c
> >>>>> @@ -341,7 +341,7 @@ bool dm_helpers_dp_mst_send_payload_allocation(
> >>>>> struct amdgpu_dm_connector *aconnector;
> >>>>> struct drm_dp_mst_topology_state *mst_state;
> >>>>> struct drm_dp_mst_topology_mgr *mst_mgr;
> >>>>> - struct drm_dp_mst_atomic_payload *new_payload, *old_payload;
> >>>>> + struct drm_dp_mst_atomic_payload *new_payload, old_payload;
> >>>>> enum mst_progress_status set_flag = MST_ALLOCATE_NEW_PAYLOAD;
> >>>>> enum mst_progress_status clr_flag = MST_CLEAR_ALLOCATED_PAYLOAD;
> >>>>> int ret = 0;
> >>>>> @@ -365,8 +365,8 @@ bool dm_helpers_dp_mst_send_payload_allocation(
> >>>>> ret = drm_dp_add_payload_part2(mst_mgr,
> >>>>> mst_state->base.state, new_payload);
> >>>>> } else {
> >>>>> dm_helpers_construct_old_payload(stream->link,
> >>>>> mst_state->pbn_div,
> >>>>> - new_payload,
> >>>>> old_payload);
> >>>>> - drm_dp_remove_payload_part2(mst_mgr, mst_state,
> >>>>> old_payload, new_payload);
> >>>>> + new_payload,
> >>>>> _payload);
> >>>>> + drm_dp_remove_payload_part2(mst_mgr, mst_state,
> >>>>> _payload, new_payload);
> >>>>> }
> >>>>>
> >>>>> if (ret) {
> >>>>>
> >>>>> ---
> >>>>> base-commit: 8569c31545385195bdb0c021124e68336e91c693
> >>>>> change-id:
> >>>>> 20230913-fix-wuninitialized-dm_helpers_dp_mst_send_payload_allocation-c37b33aaad18
> >>>>>
> >>>>> Best regards,
> >>>> --
> >>>> Hamza
> >>>>
> >> --
> >> Hamza
> >>
> --
> Hamza
>
Re: drm/vkms: deadlock between dev->event_lock and timer
On Wed, Sep 13 2023 at 09:47, Linus Torvalds wrote:
> On Wed, 13 Sept 2023 at 07:21, Tetsuo Handa
> wrote:
>>
>> Hello. A deadlock was reported in drivers/gpu/drm/vkms/ .
>> It looks like this locking pattern remains as of 6.6-rc1. Please fix.
>>
>> void drm_crtc_vblank_off(struct drm_crtc *crtc) {
>> spin_lock_irq(>event_lock);
>> drm_vblank_disable_and_save(dev, pipe) {
>> __disable_vblank(dev, pipe) {
>> crtc->funcs->disable_vblank(crtc) == vkms_disable_vblank {
>> hrtimer_cancel(>vblank_hrtimer) { // Retries with
>> dev->event_lock held until lock_hrtimer_base() succeeds.
>> ret = hrtimer_try_to_cancel(timer) {
>> base = lock_hrtimer_base(timer, ); // Fails forever
>> because vkms_vblank_simulate() is in progress.
>
> Heh. Ok. This is clearly a bug, but it does seem to be limited to just
> the vkms driver, and literally only to the "simulate vblank" case.
>
> The worst part about it is that it's so subtle and not obvious.
>
> Some light grepping seems to show that amdgpu has almost the exact
> same pattern in its own vkms thing, except it uses
>
> hrtimer_try_to_cancel(_crtc->vblank_timer);
>
> directly, which presumably fixes the livelock, but means that the
> cancel will fail if it's currently running.
>
> So just doing the same thing in the vkms driver probably fixes things.
>
> Maybe the vkms people need to add a flag to say "it's canceled" so
> that it doesn't then get re-enabled? Or maybe it doesn't matter
> and/or already happens for some reason I didn't look into.
Maybe the VKMS people need to understand locking in the first place. The
first thing I saw in this code is:
static enum hrtimer_restart vkms_vblank_simulate(struct hrtimer *timer)
{
...
mutex_unlock(>enabled_lock);
What?
Unlocking a mutex in the context of a hrtimer callback is simply
violating all mutex locking rules.
How has this code ever survived lock debugging without triggering a big
fat warning?
Thanks,
tglx
Re: [PATCH] drm/amd/display: Fix -Wuninitialized in dm_helpers_dp_mst_send_payload_allocation()
On 9/13/23 16:03, Alex Deucher wrote:
On Wed, Sep 13, 2023 at 3:57 PM Hamza Mahfooz wrote:
On 9/13/23 15:54, Alex Deucher wrote:
On Wed, Sep 13, 2023 at 12:17 PM Hamza Mahfooz wrote:
On 9/13/23 12:10, Nathan Chancellor wrote:
When building with clang, there is a warning (or error when
CONFIG_WERROR is set):
drivers/gpu/drm/amd/amdgpu/../display/amdgpu_dm/amdgpu_dm_helpers.c:368:21:
error: variable 'old_payload' is uninitialized when used here
[-Werror,-Wuninitialized]
368 | new_payload,
old_payload);
|
^~~
drivers/gpu/drm/amd/amdgpu/../display/amdgpu_dm/amdgpu_dm_helpers.c:344:61:
note: initialize the variable 'old_payload' to silence this warning
344 | struct drm_dp_mst_atomic_payload *new_payload,
*old_payload;
|
^
|
= NULL
1 error generated.
This variable is not required outside of this function so allocate
old_payload on the stack and pass it by reference to
dm_helpers_construct_old_payload(), resolving the warning.
Closes: https://github.com/ClangBuiltLinux/linux/issues/1931
Fixes: 5aa1dfcdf0a4 ("drm/mst: Refactor the flow for payload
allocation/removement")
Signed-off-by: Nathan Chancellor
Reviewed-by: Hamza Mahfooz
Hm, seems like this was pushed through drm-misc-next and as such our CI
didn't get a chance to test it.
Can you push this to drm-misc? That is where Wayne's patches landed.
If not, I can push it.
No need, I cherry-picked Wayne's patches to amd-staging-drm-next and
applied Nathan's fix.
Yes, but we can only have patches go upstream via one tree. Wayne's
patches are in drm-misc, so that is where the fix should be. It's
fine to have them in amd-staging-drm-next for testing purposes, but I
won't be upstreaming them via the amdgpu -next tree since they are
already in drm-misc.
In that case can you push it to drm-misc?
Alex
Alex
---
drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_helpers.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_helpers.c
b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_helpers.c
index 9ad509279b0a..c4c35f6844f4 100644
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_helpers.c
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_helpers.c
@@ -341,7 +341,7 @@ bool dm_helpers_dp_mst_send_payload_allocation(
struct amdgpu_dm_connector *aconnector;
struct drm_dp_mst_topology_state *mst_state;
struct drm_dp_mst_topology_mgr *mst_mgr;
- struct drm_dp_mst_atomic_payload *new_payload, *old_payload;
+ struct drm_dp_mst_atomic_payload *new_payload, old_payload;
enum mst_progress_status set_flag = MST_ALLOCATE_NEW_PAYLOAD;
enum mst_progress_status clr_flag = MST_CLEAR_ALLOCATED_PAYLOAD;
int ret = 0;
@@ -365,8 +365,8 @@ bool dm_helpers_dp_mst_send_payload_allocation(
ret = drm_dp_add_payload_part2(mst_mgr, mst_state->base.state,
new_payload);
} else {
dm_helpers_construct_old_payload(stream->link,
mst_state->pbn_div,
- new_payload, old_payload);
- drm_dp_remove_payload_part2(mst_mgr, mst_state, old_payload,
new_payload);
+ new_payload, _payload);
+ drm_dp_remove_payload_part2(mst_mgr, mst_state, _payload,
new_payload);
}
if (ret) {
---
base-commit: 8569c31545385195bdb0c021124e68336e91c693
change-id:
20230913-fix-wuninitialized-dm_helpers_dp_mst_send_payload_allocation-c37b33aaad18
Best regards,
--
Hamza
--
Hamza
--
Hamza
Re: [PATCH] drm/amd/display: Fix -Wuninitialized in dm_helpers_dp_mst_send_payload_allocation()
On Wed, Sep 13, 2023 at 3:57 PM Hamza Mahfooz wrote:
>
>
> On 9/13/23 15:54, Alex Deucher wrote:
> > On Wed, Sep 13, 2023 at 12:17 PM Hamza Mahfooz
> > wrote:
> >>
> >>
> >> On 9/13/23 12:10, Nathan Chancellor wrote:
> >>> When building with clang, there is a warning (or error when
> >>> CONFIG_WERROR is set):
> >>>
> >>>
> >>> drivers/gpu/drm/amd/amdgpu/../display/amdgpu_dm/amdgpu_dm_helpers.c:368:21:
> >>> error: variable 'old_payload' is uninitialized when used here
> >>> [-Werror,-Wuninitialized]
> >>> 368 | new_payload,
> >>> old_payload);
> >>> |
> >>> ^~~
> >>>
> >>> drivers/gpu/drm/amd/amdgpu/../display/amdgpu_dm/amdgpu_dm_helpers.c:344:61:
> >>> note: initialize the variable 'old_payload' to silence this warning
> >>> 344 | struct drm_dp_mst_atomic_payload *new_payload,
> >>> *old_payload;
> >>> |
> >>> ^
> >>> |
> >>> = NULL
> >>> 1 error generated.
> >>>
> >>> This variable is not required outside of this function so allocate
> >>> old_payload on the stack and pass it by reference to
> >>> dm_helpers_construct_old_payload(), resolving the warning.
> >>>
> >>> Closes: https://github.com/ClangBuiltLinux/linux/issues/1931
> >>> Fixes: 5aa1dfcdf0a4 ("drm/mst: Refactor the flow for payload
> >>> allocation/removement")
> >>> Signed-off-by: Nathan Chancellor
> >>
> >> Reviewed-by: Hamza Mahfooz
> >>
> >> Hm, seems like this was pushed through drm-misc-next and as such our CI
> >> didn't get a chance to test it.
> >
> > Can you push this to drm-misc? That is where Wayne's patches landed.
> > If not, I can push it.
>
> No need, I cherry-picked Wayne's patches to amd-staging-drm-next and
> applied Nathan's fix.
Yes, but we can only have patches go upstream via one tree. Wayne's
patches are in drm-misc, so that is where the fix should be. It's
fine to have them in amd-staging-drm-next for testing purposes, but I
won't be upstreaming them via the amdgpu -next tree since they are
already in drm-misc.
Alex
>
> >
> > Alex
> >
> >
> >>
> >>
> >>> ---
> >>>drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_helpers.c | 6 +++---
> >>>1 file changed, 3 insertions(+), 3 deletions(-)
> >>>
> >>> diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_helpers.c
> >>> b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_helpers.c
> >>> index 9ad509279b0a..c4c35f6844f4 100644
> >>> --- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_helpers.c
> >>> +++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_helpers.c
> >>> @@ -341,7 +341,7 @@ bool dm_helpers_dp_mst_send_payload_allocation(
> >>>struct amdgpu_dm_connector *aconnector;
> >>>struct drm_dp_mst_topology_state *mst_state;
> >>>struct drm_dp_mst_topology_mgr *mst_mgr;
> >>> - struct drm_dp_mst_atomic_payload *new_payload, *old_payload;
> >>> + struct drm_dp_mst_atomic_payload *new_payload, old_payload;
> >>>enum mst_progress_status set_flag = MST_ALLOCATE_NEW_PAYLOAD;
> >>>enum mst_progress_status clr_flag = MST_CLEAR_ALLOCATED_PAYLOAD;
> >>>int ret = 0;
> >>> @@ -365,8 +365,8 @@ bool dm_helpers_dp_mst_send_payload_allocation(
> >>>ret = drm_dp_add_payload_part2(mst_mgr,
> >>> mst_state->base.state, new_payload);
> >>>} else {
> >>>dm_helpers_construct_old_payload(stream->link,
> >>> mst_state->pbn_div,
> >>> - new_payload, old_payload);
> >>> - drm_dp_remove_payload_part2(mst_mgr, mst_state,
> >>> old_payload, new_payload);
> >>> + new_payload, _payload);
> >>> + drm_dp_remove_payload_part2(mst_mgr, mst_state,
> >>> _payload, new_payload);
> >>>}
> >>>
> >>>if (ret) {
> >>>
> >>> ---
> >>> base-commit: 8569c31545385195bdb0c021124e68336e91c693
> >>> change-id:
> >>> 20230913-fix-wuninitialized-dm_helpers_dp_mst_send_payload_allocation-c37b33aaad18
> >>>
> >>> Best regards,
> >> --
> >> Hamza
> >>
> --
> Hamza
>
Re: [PATCH] drm/amd/display: Fix -Wuninitialized in dm_helpers_dp_mst_send_payload_allocation()
On 9/13/23 15:54, Alex Deucher wrote:
On Wed, Sep 13, 2023 at 12:17 PM Hamza Mahfooz wrote:
On 9/13/23 12:10, Nathan Chancellor wrote:
When building with clang, there is a warning (or error when
CONFIG_WERROR is set):
drivers/gpu/drm/amd/amdgpu/../display/amdgpu_dm/amdgpu_dm_helpers.c:368:21:
error: variable 'old_payload' is uninitialized when used here
[-Werror,-Wuninitialized]
368 | new_payload,
old_payload);
|
^~~
drivers/gpu/drm/amd/amdgpu/../display/amdgpu_dm/amdgpu_dm_helpers.c:344:61:
note: initialize the variable 'old_payload' to silence this warning
344 | struct drm_dp_mst_atomic_payload *new_payload, *old_payload;
|^
|
= NULL
1 error generated.
This variable is not required outside of this function so allocate
old_payload on the stack and pass it by reference to
dm_helpers_construct_old_payload(), resolving the warning.
Closes: https://github.com/ClangBuiltLinux/linux/issues/1931
Fixes: 5aa1dfcdf0a4 ("drm/mst: Refactor the flow for payload
allocation/removement")
Signed-off-by: Nathan Chancellor
Reviewed-by: Hamza Mahfooz
Hm, seems like this was pushed through drm-misc-next and as such our CI
didn't get a chance to test it.
Can you push this to drm-misc? That is where Wayne's patches landed.
If not, I can push it.
No need, I cherry-picked Wayne's patches to amd-staging-drm-next and
applied Nathan's fix.
Alex
---
drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_helpers.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_helpers.c
b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_helpers.c
index 9ad509279b0a..c4c35f6844f4 100644
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_helpers.c
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_helpers.c
@@ -341,7 +341,7 @@ bool dm_helpers_dp_mst_send_payload_allocation(
struct amdgpu_dm_connector *aconnector;
struct drm_dp_mst_topology_state *mst_state;
struct drm_dp_mst_topology_mgr *mst_mgr;
- struct drm_dp_mst_atomic_payload *new_payload, *old_payload;
+ struct drm_dp_mst_atomic_payload *new_payload, old_payload;
enum mst_progress_status set_flag = MST_ALLOCATE_NEW_PAYLOAD;
enum mst_progress_status clr_flag = MST_CLEAR_ALLOCATED_PAYLOAD;
int ret = 0;
@@ -365,8 +365,8 @@ bool dm_helpers_dp_mst_send_payload_allocation(
ret = drm_dp_add_payload_part2(mst_mgr, mst_state->base.state,
new_payload);
} else {
dm_helpers_construct_old_payload(stream->link,
mst_state->pbn_div,
- new_payload, old_payload);
- drm_dp_remove_payload_part2(mst_mgr, mst_state, old_payload,
new_payload);
+ new_payload, _payload);
+ drm_dp_remove_payload_part2(mst_mgr, mst_state, _payload,
new_payload);
}
if (ret) {
---
base-commit: 8569c31545385195bdb0c021124e68336e91c693
change-id:
20230913-fix-wuninitialized-dm_helpers_dp_mst_send_payload_allocation-c37b33aaad18
Best regards,
--
Hamza
--
Hamza
Re: [PATCH] drm/amd/display: Fix -Wuninitialized in dm_helpers_dp_mst_send_payload_allocation()
On Wed, Sep 13, 2023 at 12:17 PM Hamza Mahfooz wrote:
>
>
> On 9/13/23 12:10, Nathan Chancellor wrote:
> > When building with clang, there is a warning (or error when
> > CONFIG_WERROR is set):
> >
> >
> > drivers/gpu/drm/amd/amdgpu/../display/amdgpu_dm/amdgpu_dm_helpers.c:368:21:
> > error: variable 'old_payload' is uninitialized when used here
> > [-Werror,-Wuninitialized]
> > 368 | new_payload,
> > old_payload);
> > |
> > ^~~
> >
> > drivers/gpu/drm/amd/amdgpu/../display/amdgpu_dm/amdgpu_dm_helpers.c:344:61:
> > note: initialize the variable 'old_payload' to silence this warning
> > 344 | struct drm_dp_mst_atomic_payload *new_payload,
> > *old_payload;
> > |
> > ^
> > |
> >= NULL
> >1 error generated.
> >
> > This variable is not required outside of this function so allocate
> > old_payload on the stack and pass it by reference to
> > dm_helpers_construct_old_payload(), resolving the warning.
> >
> > Closes: https://github.com/ClangBuiltLinux/linux/issues/1931
> > Fixes: 5aa1dfcdf0a4 ("drm/mst: Refactor the flow for payload
> > allocation/removement")
> > Signed-off-by: Nathan Chancellor
>
> Reviewed-by: Hamza Mahfooz
>
> Hm, seems like this was pushed through drm-misc-next and as such our CI
> didn't get a chance to test it.
Can you push this to drm-misc? That is where Wayne's patches landed.
If not, I can push it.
Alex
>
>
> > ---
> > drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_helpers.c | 6 +++---
> > 1 file changed, 3 insertions(+), 3 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_helpers.c
> > b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_helpers.c
> > index 9ad509279b0a..c4c35f6844f4 100644
> > --- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_helpers.c
> > +++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_helpers.c
> > @@ -341,7 +341,7 @@ bool dm_helpers_dp_mst_send_payload_allocation(
> > struct amdgpu_dm_connector *aconnector;
> > struct drm_dp_mst_topology_state *mst_state;
> > struct drm_dp_mst_topology_mgr *mst_mgr;
> > - struct drm_dp_mst_atomic_payload *new_payload, *old_payload;
> > + struct drm_dp_mst_atomic_payload *new_payload, old_payload;
> > enum mst_progress_status set_flag = MST_ALLOCATE_NEW_PAYLOAD;
> > enum mst_progress_status clr_flag = MST_CLEAR_ALLOCATED_PAYLOAD;
> > int ret = 0;
> > @@ -365,8 +365,8 @@ bool dm_helpers_dp_mst_send_payload_allocation(
> > ret = drm_dp_add_payload_part2(mst_mgr,
> > mst_state->base.state, new_payload);
> > } else {
> > dm_helpers_construct_old_payload(stream->link,
> > mst_state->pbn_div,
> > - new_payload, old_payload);
> > - drm_dp_remove_payload_part2(mst_mgr, mst_state, old_payload,
> > new_payload);
> > + new_payload, _payload);
> > + drm_dp_remove_payload_part2(mst_mgr, mst_state, _payload,
> > new_payload);
> > }
> >
> > if (ret) {
> >
> > ---
> > base-commit: 8569c31545385195bdb0c021124e68336e91c693
> > change-id:
> > 20230913-fix-wuninitialized-dm_helpers_dp_mst_send_payload_allocation-c37b33aaad18
> >
> > Best regards,
> --
> Hamza
>
[pull] amdgpu, amdkfd drm-fixes-6.6
Hi Dave, Daniel, Fixes for 6.6. The following changes since commit afaf2b38025ab327c85e218f36d1819e777d4d45: Merge tag 'drm-misc-next-fixes-2023-09-11' of git://anongit.freedesktop.org/drm/drm-misc into drm-fixes (2023-09-11 16:23:42 +0200) are available in the Git repository at: https://gitlab.freedesktop.org/agd5f/linux.git tags/amd-drm-fixes-6.6-2023-09-13 for you to fetch changes up to edcfe22985d09ee8e2346c9217f5a52ab150099f: drm/amdkfd: Insert missing TLB flush on GFX10 and later (2023-09-12 17:45:40 -0400) amd-drm-fixes-6.6-2023-09-13: amdgpu: - GC 9.4.3 fixes - Fix white screen issues with S/G display on system with >= 64G of ram - Replay fixes - SMU 13.0.6 fixes - AUX backlight fix - NBIO 4.3 SR-IOV fixes for HDP - RAS fixes - DP MST resume fix - Fix segfault on systems with no vbios - DPIA fixes amdkfd: - CWSR grace period fix - Unaligned doorbell fix - CRIU fix for GFX11 - Add missing TLB flush on gfx10 and newer Alex Deucher (2): drm/amdgpu/soc21: don't remap HDP registers for SR-IOV drm/amdgpu/nbio4.3: set proper rmmio_remap.reg_offset for SR-IOV Bhawanpreet Lakha (1): drm/amd/display: Add dirty rect support for Replay Dan Carpenter (1): drm/amdgpu: fix retry loop test David Francis (2): drm/amdkfd: Checkpoint and restore queues on GFX11 drm/amdgpu: Handle null atom context in VBIOS info ioctl Hamza Mahfooz (1): Revert "drm/amd: Disable S/G for APUs when 64GB or more host memory" Harish Kasiviswanathan (1): drm/amdkfd: Insert missing TLB flush on GFX10 and later Hawking Zhang (1): drm/amdgpu: fallback to old RAS error message for aqua_vanjaram Mukul Joshi (5): drm/amdkfd: Fix reg offset for setting CWSR grace period drm/amdkfd: Fix unaligned 64-bit doorbell warning drm/amdgpu: Store CU info from all XCCs for GFX v9.4.3 drm/amdkfd: Update cache info reporting for GFX v9.4.3 drm/amdkfd: Update CU masking for GFX 9.4.3 Mustapha Ghaddar (2): drm/amd/display: Add DPIA Link Encoder Assignment Fix drm/amd/display: Fix 2nd DPIA encoder Assignment Randy Dunlap (1): drm/amd/display: fix replay_mode kernel-doc warning Swapnil Patel (1): drm/amd/display: Don't check registers, if using AUX BL control Wayne Lin (1): drm/amd/display: Adjust the MST resume flow Yifan Zhang (1): drm/amd/display: fix the white screen issue when >= 64GB DRAM drivers/gpu/drm/amd/amdgpu/amdgpu.h| 1 - drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd.c | 2 +- drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gfx_v10.c | 3 +- drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gfx_v10.h | 3 +- drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gfx_v9.c | 6 +- drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gfx_v9.h | 3 +- drivers/gpu/drm/amd/amdgpu/amdgpu_device.c | 26 - drivers/gpu/drm/amd/amdgpu/amdgpu_gfx.h| 3 +- drivers/gpu/drm/amd/amdgpu/amdgpu_kms.c| 19 ++-- drivers/gpu/drm/amd/amdgpu/amdgpu_ras.c| 6 +- drivers/gpu/drm/amd/amdgpu/gfx_v10_0.c | 2 +- drivers/gpu/drm/amd/amdgpu/gfx_v11_0.c | 2 +- drivers/gpu/drm/amd/amdgpu/gfx_v6_0.c | 2 +- drivers/gpu/drm/amd/amdgpu/gfx_v7_0.c | 2 +- drivers/gpu/drm/amd/amdgpu/gfx_v8_0.c | 2 +- drivers/gpu/drm/amd/amdgpu/gfx_v9_0.c | 4 +- drivers/gpu/drm/amd/amdgpu/gfx_v9_4_3.c| 76 ++ drivers/gpu/drm/amd/amdgpu/nbio_v4_3.c | 3 + drivers/gpu/drm/amd/amdgpu/soc21.c | 2 +- drivers/gpu/drm/amd/amdkfd/kfd_crat.c | 3 +- drivers/gpu/drm/amd/amdkfd/kfd_crat.h | 4 + .../gpu/drm/amd/amdkfd/kfd_device_queue_manager.c | 3 +- drivers/gpu/drm/amd/amdkfd/kfd_doorbell.c | 2 + drivers/gpu/drm/amd/amdkfd/kfd_mqd_manager.c | 34 -- drivers/gpu/drm/amd/amdkfd/kfd_mqd_manager.h | 2 +- drivers/gpu/drm/amd/amdkfd/kfd_mqd_manager_cik.c | 2 +- drivers/gpu/drm/amd/amdkfd/kfd_mqd_manager_v10.c | 2 +- drivers/gpu/drm/amd/amdkfd/kfd_mqd_manager_v11.c | 43 +++- drivers/gpu/drm/amd/amdkfd/kfd_mqd_manager_v9.c| 46 ++--- drivers/gpu/drm/amd/amdkfd/kfd_mqd_manager_vi.c| 2 +- drivers/gpu/drm/amd/amdkfd/kfd_packet_manager_v9.c | 3 +- drivers/gpu/drm/amd/amdkfd/kfd_priv.h | 3 +- drivers/gpu/drm/amd/amdkfd/kfd_topology.c | 77 -- drivers/gpu/drm/amd/amdkfd/kfd_topology.h | 2 +- drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 115 + drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.h | 2 +- .../gpu/drm/amd/display/dc/core/dc_link_enc_cfg.c | 35 +-- drivers/gpu/drm/amd/display/dc/dc.h| 1 + .../amd/display/dc/dce110/dce110_hw_sequencer.c|
Patch "drm/ast: Fix DRAM init on AST2200" has been added to the 6.5-stable tree
This is a note to let you know that I've just added the patch titled
drm/ast: Fix DRAM init on AST2200
to the 6.5-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary
The filename of the patch is:
drm-ast-fix-dram-init-on-ast2200.patch
and it can be found in the queue-6.5 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let know about it.
>From 4cfe75f0f14f044dae66ad0e6eea812d038465d9 Mon Sep 17 00:00:00 2001
From: Thomas Zimmermann
Date: Wed, 21 Jun 2023 14:53:35 +0200
Subject: drm/ast: Fix DRAM init on AST2200
From: Thomas Zimmermann
commit 4cfe75f0f14f044dae66ad0e6eea812d038465d9 upstream.
Fix the test for the AST2200 in the DRAM initialization. The value
in ast->chip has to be compared against an enum constant instead of
a numerical value.
This bug got introduced when the driver was first imported into the
kernel.
Signed-off-by: Thomas Zimmermann
Fixes: 312fec1405dd ("drm: Initial KMS driver for AST (ASpeed Technologies)
2000 series (v2)")
Cc: Dave Airlie
Cc: dri-devel@lists.freedesktop.org
Cc: # v3.5+
Reviewed-by: Sui Jingfeng
Reviewed-by: Jocelyn Falempe
Tested-by: Jocelyn Falempe # AST2600
Link:
https://patchwork.freedesktop.org/patch/msgid/20230621130032.3568-2-tzimmerm...@suse.de
Signed-off-by: Greg Kroah-Hartman
---
drivers/gpu/drm/ast/ast_post.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/drivers/gpu/drm/ast/ast_post.c
+++ b/drivers/gpu/drm/ast/ast_post.c
@@ -291,7 +291,7 @@ static void ast_init_dram_reg(struct drm
;
} while (ast_read32(ast, 0x10100) != 0xa8);
} else {/* AST2100/1100 */
- if (ast->chip == AST2100 || ast->chip == 2200)
+ if (ast->chip == AST2100 || ast->chip == AST2200)
dram_reg_info = ast2100_dram_table_data;
else
dram_reg_info = ast1100_dram_table_data;
Patches currently in stable-queue which might be from tzimmerm...@suse.de are
queue-6.5/fbdev-ep93xx-fb-do-not-assign-to-struct-fb_info.dev.patch
queue-6.5/drm-ast-fix-dram-init-on-ast2200.patch
Patch "drm/ast: Fix DRAM init on AST2200" has been added to the 6.1-stable tree
This is a note to let you know that I've just added the patch titled
drm/ast: Fix DRAM init on AST2200
to the 6.1-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary
The filename of the patch is:
drm-ast-fix-dram-init-on-ast2200.patch
and it can be found in the queue-6.1 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let know about it.
>From 4cfe75f0f14f044dae66ad0e6eea812d038465d9 Mon Sep 17 00:00:00 2001
From: Thomas Zimmermann
Date: Wed, 21 Jun 2023 14:53:35 +0200
Subject: drm/ast: Fix DRAM init on AST2200
From: Thomas Zimmermann
commit 4cfe75f0f14f044dae66ad0e6eea812d038465d9 upstream.
Fix the test for the AST2200 in the DRAM initialization. The value
in ast->chip has to be compared against an enum constant instead of
a numerical value.
This bug got introduced when the driver was first imported into the
kernel.
Signed-off-by: Thomas Zimmermann
Fixes: 312fec1405dd ("drm: Initial KMS driver for AST (ASpeed Technologies)
2000 series (v2)")
Cc: Dave Airlie
Cc: dri-devel@lists.freedesktop.org
Cc: # v3.5+
Reviewed-by: Sui Jingfeng
Reviewed-by: Jocelyn Falempe
Tested-by: Jocelyn Falempe # AST2600
Link:
https://patchwork.freedesktop.org/patch/msgid/20230621130032.3568-2-tzimmerm...@suse.de
Signed-off-by: Greg Kroah-Hartman
---
drivers/gpu/drm/ast/ast_post.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/drivers/gpu/drm/ast/ast_post.c
+++ b/drivers/gpu/drm/ast/ast_post.c
@@ -291,7 +291,7 @@ static void ast_init_dram_reg(struct drm
;
} while (ast_read32(ast, 0x10100) != 0xa8);
} else {/* AST2100/1100 */
- if (ast->chip == AST2100 || ast->chip == 2200)
+ if (ast->chip == AST2100 || ast->chip == AST2200)
dram_reg_info = ast2100_dram_table_data;
else
dram_reg_info = ast1100_dram_table_data;
Patches currently in stable-queue which might be from tzimmerm...@suse.de are
queue-6.1/fbdev-ep93xx-fb-do-not-assign-to-struct-fb_info.dev.patch
queue-6.1/drm-ast-fix-dram-init-on-ast2200.patch
Patch "drm/ast: Fix DRAM init on AST2200" has been added to the 5.15-stable tree
This is a note to let you know that I've just added the patch titled
drm/ast: Fix DRAM init on AST2200
to the 5.15-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary
The filename of the patch is:
drm-ast-fix-dram-init-on-ast2200.patch
and it can be found in the queue-5.15 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let know about it.
>From 4cfe75f0f14f044dae66ad0e6eea812d038465d9 Mon Sep 17 00:00:00 2001
From: Thomas Zimmermann
Date: Wed, 21 Jun 2023 14:53:35 +0200
Subject: drm/ast: Fix DRAM init on AST2200
From: Thomas Zimmermann
commit 4cfe75f0f14f044dae66ad0e6eea812d038465d9 upstream.
Fix the test for the AST2200 in the DRAM initialization. The value
in ast->chip has to be compared against an enum constant instead of
a numerical value.
This bug got introduced when the driver was first imported into the
kernel.
Signed-off-by: Thomas Zimmermann
Fixes: 312fec1405dd ("drm: Initial KMS driver for AST (ASpeed Technologies)
2000 series (v2)")
Cc: Dave Airlie
Cc: dri-devel@lists.freedesktop.org
Cc: # v3.5+
Reviewed-by: Sui Jingfeng
Reviewed-by: Jocelyn Falempe
Tested-by: Jocelyn Falempe # AST2600
Link:
https://patchwork.freedesktop.org/patch/msgid/20230621130032.3568-2-tzimmerm...@suse.de
Signed-off-by: Greg Kroah-Hartman
---
drivers/gpu/drm/ast/ast_post.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/drivers/gpu/drm/ast/ast_post.c
+++ b/drivers/gpu/drm/ast/ast_post.c
@@ -291,7 +291,7 @@ static void ast_init_dram_reg(struct drm
;
} while (ast_read32(ast, 0x10100) != 0xa8);
} else {/* AST2100/1100 */
- if (ast->chip == AST2100 || ast->chip == 2200)
+ if (ast->chip == AST2100 || ast->chip == AST2200)
dram_reg_info = ast2100_dram_table_data;
else
dram_reg_info = ast1100_dram_table_data;
Patches currently in stable-queue which might be from tzimmerm...@suse.de are
queue-5.15/backlight-gpio_backlight-compare-against-struct-fb_info.device.patch
queue-5.15/fbdev-ep93xx-fb-do-not-assign-to-struct-fb_info.dev.patch
queue-5.15/backlight-lv5207lp-compare-against-struct-fb_info.device.patch
queue-5.15/backlight-bd6107-compare-against-struct-fb_info.device.patch
queue-5.15/drm-ast-fix-dram-init-on-ast2200.patch
Re: [PATCH] drm/msm/adreno: Add support for SM7150 SoC machine
On 13.09.2023 21:19, Danila Tikhonov wrote:
> SM7150 has 5 power levels which correspond to 5 speed-bin values: 0,
> 128, 146, 167, 172. Speed-bin value is calulated as FMAX/4.8MHz round up
> to zero decimal places.
>
> The vendor's FW GMU is called a618_gmu.bin. And also a618 on SM7150 uses
> a615 zapfw.
Interesting.
GMU fw comes from Qualcomm and should not(?) have any
vendor modifications, btw.
Can you try loading the upstream a630_gmu.bin or a619_gmu.bin
from linux-firmware and seeing if anything changes?
> + }, {
> + .machine = "qcom,sm7150",
> + .chip_ids = ADRENO_CHIP_IDS(0x06010800),
> + .family = ADRENO_6XX_GEN1,
> + .revn = 618,
I'm not sure what Rob's stance on using revn is for values
that have already been used before..
Konrad
> + .fw = {
> + [ADRENO_FW_SQE] = "a630_sqe.fw",
> + [ADRENO_FW_GMU] = "a618_gmu.bin",
> + },
> + .gmem = SZ_512K,
> + .inactive_period = DRM_MSM_INACTIVE_PERIOD,
> + .quirks = ADRENO_QUIRK_HAS_CACHED_COHERENT,
> + .init = a6xx_gpu_init,
> + .zapfw = "a615_zap.mdt",
.mbn?
> + .hwcg = a615_hwcg,
> + .speedbins = ADRENO_SPEEDBINS(
> + { 0, 0 },
> + { 128, 1 },
> + { 146, 2 },
> + { 167, 3 },
> + { 172, 4 },
> + ),
> }, {
> .chip_ids = ADRENO_CHIP_IDS(0x06010800),
> .family = ADRENO_6XX_GEN1,
> @@ -507,6 +529,10 @@ MODULE_FIRMWARE("qcom/a530_zap.b00");
> MODULE_FIRMWARE("qcom/a530_zap.b01");
> MODULE_FIRMWARE("qcom/a530_zap.b02");
> MODULE_FIRMWARE("qcom/a540_gpmu.fw2");
> +MODULE_FIRMWARE("qcom/a615_zap.mbt");
> +MODULE_FIRMWARE("qcom/a615_zap.b00");
> +MODULE_FIRMWARE("qcom/a615_zap.b01");
> +MODULE_FIRMWARE("qcom/a615_zap.b02");
and here too?
Konrad
Patch "drm/ast: Fix DRAM init on AST2200" has been added to the 5.10-stable tree
This is a note to let you know that I've just added the patch titled
drm/ast: Fix DRAM init on AST2200
to the 5.10-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary
The filename of the patch is:
drm-ast-fix-dram-init-on-ast2200.patch
and it can be found in the queue-5.10 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let know about it.
>From 4cfe75f0f14f044dae66ad0e6eea812d038465d9 Mon Sep 17 00:00:00 2001
From: Thomas Zimmermann
Date: Wed, 21 Jun 2023 14:53:35 +0200
Subject: drm/ast: Fix DRAM init on AST2200
From: Thomas Zimmermann
commit 4cfe75f0f14f044dae66ad0e6eea812d038465d9 upstream.
Fix the test for the AST2200 in the DRAM initialization. The value
in ast->chip has to be compared against an enum constant instead of
a numerical value.
This bug got introduced when the driver was first imported into the
kernel.
Signed-off-by: Thomas Zimmermann
Fixes: 312fec1405dd ("drm: Initial KMS driver for AST (ASpeed Technologies)
2000 series (v2)")
Cc: Dave Airlie
Cc: dri-devel@lists.freedesktop.org
Cc: # v3.5+
Reviewed-by: Sui Jingfeng
Reviewed-by: Jocelyn Falempe
Tested-by: Jocelyn Falempe # AST2600
Link:
https://patchwork.freedesktop.org/patch/msgid/20230621130032.3568-2-tzimmerm...@suse.de
Signed-off-by: Greg Kroah-Hartman
---
drivers/gpu/drm/ast/ast_post.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/drivers/gpu/drm/ast/ast_post.c
+++ b/drivers/gpu/drm/ast/ast_post.c
@@ -290,7 +290,7 @@ static void ast_init_dram_reg(struct drm
;
} while (ast_read32(ast, 0x10100) != 0xa8);
} else {/* AST2100/1100 */
- if (ast->chip == AST2100 || ast->chip == 2200)
+ if (ast->chip == AST2100 || ast->chip == AST2200)
dram_reg_info = ast2100_dram_table_data;
else
dram_reg_info = ast1100_dram_table_data;
Patches currently in stable-queue which might be from tzimmerm...@suse.de are
queue-5.10/backlight-gpio_backlight-compare-against-struct-fb_info.device.patch
queue-5.10/fbdev-ep93xx-fb-do-not-assign-to-struct-fb_info.dev.patch
queue-5.10/backlight-lv5207lp-compare-against-struct-fb_info.device.patch
queue-5.10/backlight-bd6107-compare-against-struct-fb_info.device.patch
queue-5.10/drm-ast-fix-dram-init-on-ast2200.patch
Patch "drm/ast: Fix DRAM init on AST2200" has been added to the 5.4-stable tree
This is a note to let you know that I've just added the patch titled
drm/ast: Fix DRAM init on AST2200
to the 5.4-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary
The filename of the patch is:
drm-ast-fix-dram-init-on-ast2200.patch
and it can be found in the queue-5.4 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let know about it.
>From 4cfe75f0f14f044dae66ad0e6eea812d038465d9 Mon Sep 17 00:00:00 2001
From: Thomas Zimmermann
Date: Wed, 21 Jun 2023 14:53:35 +0200
Subject: drm/ast: Fix DRAM init on AST2200
From: Thomas Zimmermann
commit 4cfe75f0f14f044dae66ad0e6eea812d038465d9 upstream.
Fix the test for the AST2200 in the DRAM initialization. The value
in ast->chip has to be compared against an enum constant instead of
a numerical value.
This bug got introduced when the driver was first imported into the
kernel.
Signed-off-by: Thomas Zimmermann
Fixes: 312fec1405dd ("drm: Initial KMS driver for AST (ASpeed Technologies)
2000 series (v2)")
Cc: Dave Airlie
Cc: dri-devel@lists.freedesktop.org
Cc: # v3.5+
Reviewed-by: Sui Jingfeng
Reviewed-by: Jocelyn Falempe
Tested-by: Jocelyn Falempe # AST2600
Link:
https://patchwork.freedesktop.org/patch/msgid/20230621130032.3568-2-tzimmerm...@suse.de
Signed-off-by: Greg Kroah-Hartman
---
drivers/gpu/drm/ast/ast_post.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/drivers/gpu/drm/ast/ast_post.c
+++ b/drivers/gpu/drm/ast/ast_post.c
@@ -294,7 +294,7 @@ static void ast_init_dram_reg(struct drm
;
} while (ast_read32(ast, 0x10100) != 0xa8);
} else {/* AST2100/1100 */
- if (ast->chip == AST2100 || ast->chip == 2200)
+ if (ast->chip == AST2100 || ast->chip == AST2200)
dram_reg_info = ast2100_dram_table_data;
else
dram_reg_info = ast1100_dram_table_data;
Patches currently in stable-queue which might be from tzimmerm...@suse.de are
queue-5.4/drm-fix-double-free-for-gbo-in-drm_gem_vram_init-and-drm_gem_vram_create.patch
queue-5.4/backlight-gpio_backlight-compare-against-struct-fb_info.device.patch
queue-5.4/fbdev-ep93xx-fb-do-not-assign-to-struct-fb_info.dev.patch
queue-5.4/backlight-lv5207lp-compare-against-struct-fb_info.device.patch
queue-5.4/backlight-bd6107-compare-against-struct-fb_info.device.patch
queue-5.4/drm-ast-fix-dram-init-on-ast2200.patch
Patch "drm/ast: Fix DRAM init on AST2200" has been added to the 4.19-stable tree
This is a note to let you know that I've just added the patch titled
drm/ast: Fix DRAM init on AST2200
to the 4.19-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary
The filename of the patch is:
drm-ast-fix-dram-init-on-ast2200.patch
and it can be found in the queue-4.19 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let know about it.
>From 4cfe75f0f14f044dae66ad0e6eea812d038465d9 Mon Sep 17 00:00:00 2001
From: Thomas Zimmermann
Date: Wed, 21 Jun 2023 14:53:35 +0200
Subject: drm/ast: Fix DRAM init on AST2200
From: Thomas Zimmermann
commit 4cfe75f0f14f044dae66ad0e6eea812d038465d9 upstream.
Fix the test for the AST2200 in the DRAM initialization. The value
in ast->chip has to be compared against an enum constant instead of
a numerical value.
This bug got introduced when the driver was first imported into the
kernel.
Signed-off-by: Thomas Zimmermann
Fixes: 312fec1405dd ("drm: Initial KMS driver for AST (ASpeed Technologies)
2000 series (v2)")
Cc: Dave Airlie
Cc: dri-devel@lists.freedesktop.org
Cc: # v3.5+
Reviewed-by: Sui Jingfeng
Reviewed-by: Jocelyn Falempe
Tested-by: Jocelyn Falempe # AST2600
Link:
https://patchwork.freedesktop.org/patch/msgid/20230621130032.3568-2-tzimmerm...@suse.de
Signed-off-by: Greg Kroah-Hartman
---
drivers/gpu/drm/ast/ast_post.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/drivers/gpu/drm/ast/ast_post.c
+++ b/drivers/gpu/drm/ast/ast_post.c
@@ -291,7 +291,7 @@ static void ast_init_dram_reg(struct drm
;
} while (ast_read32(ast, 0x10100) != 0xa8);
} else {/* AST2100/1100 */
- if (ast->chip == AST2100 || ast->chip == 2200)
+ if (ast->chip == AST2100 || ast->chip == AST2200)
dram_reg_info = ast2100_dram_table_data;
else
dram_reg_info = ast1100_dram_table_data;
Patches currently in stable-queue which might be from tzimmerm...@suse.de are
queue-4.19/backlight-gpio_backlight-compare-against-struct-fb_info.device.patch
queue-4.19/fbdev-ep93xx-fb-do-not-assign-to-struct-fb_info.dev.patch
queue-4.19/backlight-lv5207lp-compare-against-struct-fb_info.device.patch
queue-4.19/backlight-bd6107-compare-against-struct-fb_info.device.patch
queue-4.19/drm-ast-fix-dram-init-on-ast2200.patch
queue-4.19/drm-msm-replace-drm_framebuffer_-un-reference-with-p.patch
Patch "drm/ast: Fix DRAM init on AST2200" has been added to the 4.14-stable tree
This is a note to let you know that I've just added the patch titled
drm/ast: Fix DRAM init on AST2200
to the 4.14-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary
The filename of the patch is:
drm-ast-fix-dram-init-on-ast2200.patch
and it can be found in the queue-4.14 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let know about it.
>From 4cfe75f0f14f044dae66ad0e6eea812d038465d9 Mon Sep 17 00:00:00 2001
From: Thomas Zimmermann
Date: Wed, 21 Jun 2023 14:53:35 +0200
Subject: drm/ast: Fix DRAM init on AST2200
From: Thomas Zimmermann
commit 4cfe75f0f14f044dae66ad0e6eea812d038465d9 upstream.
Fix the test for the AST2200 in the DRAM initialization. The value
in ast->chip has to be compared against an enum constant instead of
a numerical value.
This bug got introduced when the driver was first imported into the
kernel.
Signed-off-by: Thomas Zimmermann
Fixes: 312fec1405dd ("drm: Initial KMS driver for AST (ASpeed Technologies)
2000 series (v2)")
Cc: Dave Airlie
Cc: dri-devel@lists.freedesktop.org
Cc: # v3.5+
Reviewed-by: Sui Jingfeng
Reviewed-by: Jocelyn Falempe
Tested-by: Jocelyn Falempe # AST2600
Link:
https://patchwork.freedesktop.org/patch/msgid/20230621130032.3568-2-tzimmerm...@suse.de
Signed-off-by: Greg Kroah-Hartman
---
drivers/gpu/drm/ast/ast_post.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/drivers/gpu/drm/ast/ast_post.c
+++ b/drivers/gpu/drm/ast/ast_post.c
@@ -291,7 +291,7 @@ static void ast_init_dram_reg(struct drm
;
} while (ast_read32(ast, 0x10100) != 0xa8);
} else {/* AST2100/1100 */
- if (ast->chip == AST2100 || ast->chip == 2200)
+ if (ast->chip == AST2100 || ast->chip == AST2200)
dram_reg_info = ast2100_dram_table_data;
else
dram_reg_info = ast1100_dram_table_data;
Patches currently in stable-queue which might be from tzimmerm...@suse.de are
queue-4.14/backlight-gpio_backlight-compare-against-struct-fb_info.device.patch
queue-4.14/fbdev-ep93xx-fb-do-not-assign-to-struct-fb_info.dev.patch
queue-4.14/backlight-lv5207lp-compare-against-struct-fb_info.device.patch
queue-4.14/backlight-bd6107-compare-against-struct-fb_info.device.patch
queue-4.14/drm-ast-fix-dram-init-on-ast2200.patch
Re: [RFT PATCH 0/6] drm: drm-misc drivers call drm_atomic_helper_shutdown() at the right times
Hi,
On Fri, Sep 1, 2023 at 4:40 PM Douglas Anderson wrote:
>
>
> NOTE: in order to avoid email sending limits on the cover letter, I've
> split this patch series in two. Patches that target drm-misc and ones
> that don't. The cover letter of the two is identical other than this note.
>
> This patch series came about after a _long_ discussion between me and
> Maxime Ripard in response to a different patch I sent out [1]. As part
> of that discussion, we realized that it would be good if DRM drivers
> consistently called drm_atomic_helper_shutdown() properly at shutdown
> and driver remove time as it's documented that they should do. The
> eventual goal of this would be to enable removing some hacky code from
> panel drivers where they had to hook into shutdown themselves because
> the DRM driver wasn't calling them.
>
> It turns out that quite a lot of drivers seemed to be missing
> drm_atomic_helper_shutdown() in one or both places that it was
> supposed to be. This patch series attempts to fix all the drivers that
> I was able to identify.
>
> NOTE: fixing this wasn't exactly cookie cutter. Each driver has its
> own unique way of setting itself up and tearing itself down. Some
> drivers also use the component model, which adds extra fun. I've made
> my best guess at solving this and I've run a bunch of compile tests
> (specifically, allmodconfig for amd64, arm64, and powerpc). That being
> said, these code changes are not totally trivial and I've done zero
> real testing on them. Making these patches was also a little mind
> numbing and I'm certain my eyes glazed over at several points when
> writing them. What I'm trying to say is to please double-check that I
> didn't do anything too silly, like cast your driver's drvdata to the
> wrong type. Even better, test these patches!
>
> I've organized this series like this:
> 1. One patch for all simple cases of just needing a call at shutdown
>time for drivers that go through drm-misc.
> 2. A separate patch for "drm/vc4", even though it goes through
>drm-misc, since I wanted to leave an extra note for that one.
> 3. Patches for drivers that just needed a call at shutdown time for
>drivers that _don't_ go through drm-misc.
> 4. Patches for the few drivers that had the call at shutdown time but
>lacked it at remove time.
> 5. One patch for all simple cases of needing a call at shutdown and
>remove (or unbind) time for drivers that go through drm-misc.
> 6. A separate patch for "drm/hisilicon/kirin", even though it goes
>through drm-misc, since I wanted to leave an extra note for that
>one.
> 7. Patches for drivers that needed a call at shutdown and remove (or
>unbind) time for drivers that _don't_ go through drm-misc.
>
> I've labeled this patch series as RFT (request for testing) to help
> call attention to the fact that I didn't personally test any of these
> patches.
>
> If you're a maintainer of one of these drivers and you think that the
> patch for your driver looks fabulous, you've tested it, and you'd like
> to land it right away then please do. For non-drm-misc drivers there
> are no dependencies here. Some of the drm-misc drivers depend on the
> first patch, AKA ("drm/atomic-helper: drm_atomic_helper_shutdown(NULL)
> should be a noop"). I've tried to call this out but it also should be
> obvious once you know to look for it.
>
> I'd like to call out a few drivers that I _didn't_ fix in this series
> and why. If any of these drivers should be fixed then please yell.
> - DRM driers backed by usb_driver (like gud, gm12u320, udl): I didn't
> add the call to drm_atomic_helper_shutdown() at shutdown time
> because there's no ".shutdown" callback for them USB drivers. Given
> that USB is hotpluggable, I'm assuming that they are robust against
> this and the special shutdown callback isn't needed.
> - ofdrm and simpledrm: These didn't have drm_atomic_helper_shutdown()
> in either shutdown or remove, but I didn't add it. I think that's OK
> since they're sorta special and not really directly controlling
> hardware power sequencing.
> - virtio, vkms, vmwgfx, xen: I believe these are all virtual (thus
> they wouldn't directly drive a panel) and adding the shutdown
> didn't look straightforward, so I skipped them.
>
> I've let each patch in the series get CCed straight from
> get_maintainer. That means not everyone will have received every patch
> but everyone should be on the cover letter. I know some people dislike
> this but when touching this many drivers there's not much
> choice. dri-devel and lkml have been CCed and lore/lei exist, so
> hopefully that's enough for folks. I'm happy to add people to the
> whole series for future posts.
>
> [1]
> https://lore.kernel.org/lkml/20230804140605.RFC.4.I930069a32baab6faf46d6b234f89613b5cec0f14@changeid
>
>
> Douglas Anderson (6):
> drm/atomic-helper: drm_atomic_helper_shutdown(NULL) should be a noop
> drm: Call drm_atomic_helper_shutdown() at shutdown time for misc
>
Re: [RFC PATCH 04/10] drm/panel_helper: Introduce drm_panel_helper
Hi, On Thu, Sep 7, 2023 at 7:15 AM Maxime Ripard wrote: > > > a) Block landing the change to "panel-tdo-tl070wsh30.c" until after > > all drivers properly call drm_atomic_helper_shutdown(). > > I don't think we care about all drivers here. Only the driver it's > enabled with would be a blocker. Like, let's say sun4i hasn't been > converted but that panel is only used with rockchip anyway, we don't > really care that sun4i shutdown patch hasn't been merged (yet). Yeah, I suppose that would work, though it would require a bit of research. Some other things have popped onto my plate recently, but for now I'm going to focus on seeing how much of the drivers can get their shutdown fixed. When that stalls out then we can see if we can unblock some of the panels by digging into which DRM drivers they're used with. Also, as my proposal in the cover letter [1], I'm leaving a breadcrumb here that I landed the first 3 patches in this series just to get them out of the way. Those 3 patches didn't depend on the resolution of the issues discussed here. [1] https://lore.kernel.org/lkml/CAD=FV=ufuusrrzmkl8_rl5wlvkjrydwrsay_pwta-hx_p0d...@mail.gmail.com/
Re: [RFT PATCH 13/15] drm/imx/ipuv3: Call drm_atomic_helper_shutdown() at shutdown/unbind time
Hi,
On Fri, Sep 1, 2023 at 4:42 PM Douglas Anderson wrote:
>
> Based on grepping through the source code this driver appears to be
> missing a call to drm_atomic_helper_shutdown() at system shutdown time
> and at driver unbind time. Among other things, this means that if a
> panel is in use that it won't be cleanly powered off at system
> shutdown time.
>
> The fact that we should call drm_atomic_helper_shutdown() in the case
> of OS shutdown/restart and at driver remove (or unbind) time comes
> straight out of the kernel doc "driver instance overview" in
> drm_drv.c.
>
> A few notes about this fix:
> - When adding drm_atomic_helper_shutdown() to the unbind path, I added
> it after drm_kms_helper_poll_fini() since that's when other drivers
> seemed to have it.
> - Technically with a previous patch, ("drm/atomic-helper:
> drm_atomic_helper_shutdown(NULL) should be a noop"), we don't
> actually need to check to see if our "drm" pointer is NULL before
> calling drm_atomic_helper_shutdown(). We'll leave the "if" test in,
> though, so that this patch can land without any dependencies. It
> could potentially be removed later.
> - This patch also makes sure to set the drvdata to NULL in the case of
> bind errors to make sure that shutdown can't access freed data.
>
> Suggested-by: Maxime Ripard
> Signed-off-by: Douglas Anderson
> ---
> This commit is only compile-time tested.
>
> drivers/gpu/drm/imx/ipuv3/imx-drm-core.c | 11 +++
> 1 file changed, 11 insertions(+)
>
> diff --git a/drivers/gpu/drm/imx/ipuv3/imx-drm-core.c
> b/drivers/gpu/drm/imx/ipuv3/imx-drm-core.c
> index 4a866ac60fff..4c8bc49758a7 100644
> --- a/drivers/gpu/drm/imx/ipuv3/imx-drm-core.c
> +++ b/drivers/gpu/drm/imx/ipuv3/imx-drm-core.c
> @@ -257,6 +257,7 @@ static int imx_drm_bind(struct device *dev)
> drm_kms_helper_poll_fini(drm);
> component_unbind_all(drm->dev, drm);
> err_kms:
> + dev_set_drvdata(dev, NULL);
> drm_dev_put(drm);
>
> return ret;
> @@ -269,6 +270,7 @@ static void imx_drm_unbind(struct device *dev)
> drm_dev_unregister(drm);
>
> drm_kms_helper_poll_fini(drm);
> + drm_atomic_helper_shutdown(drm);
>
> component_unbind_all(drm->dev, drm);
>
> @@ -298,6 +300,14 @@ static int imx_drm_platform_remove(struct
> platform_device *pdev)
> return 0;
> }
>
> +static void imx_drm_platform_shutdown(struct platform_device *pdev)
> +{
> + struct drm_device *drm = platform_get_drvdata(pdev);
> +
> + if (drm)
> + drm_atomic_helper_shutdown(platform_get_drvdata(pdev));
Since this is now landing through the drm-misc-next tree, I got rid of
the check for NULL when applying and landed this after the patch
("drm/atomic-helper: drm_atomic_helper_shutdown(NULL) should be a
noop").
> @@ -325,6 +335,7 @@ MODULE_DEVICE_TABLE(of, imx_drm_dt_ids);
> static struct platform_driver imx_drm_pdrv = {
> .probe = imx_drm_platform_probe,
> .remove = imx_drm_platform_remove,
> + .shutdown = imx_drm_platform_shutdown,
There was a trivial context conflict with commit 3095f1122203
("drm/imx/ipuv3: Convert to platform remove callback returning void")
that I resolved while applying.
I've now pushed to drm-misc-next:
02680d71dea8 drm/imx/ipuv3: Call drm_atomic_helper_shutdown() at
shutdown/unbind time
Re: [RFT PATCH 03/15] drm/ingenic: Call drm_atomic_helper_shutdown() at shutdown time
Hi,
On Fri, Sep 1, 2023 at 4:42 PM Douglas Anderson wrote:
>
> Based on grepping through the source code this driver appears to be
> missing a call to drm_atomic_helper_shutdown() at system shutdown
> time. Among other things, this means that if a panel is in use that it
> won't be cleanly powered off at system shutdown time.
>
> The fact that we should call drm_atomic_helper_shutdown() in the case
> of OS shutdown/restart comes straight out of the kernel doc "driver
> instance overview" in drm_drv.c.
>
> Since this driver uses the component model and shutdown happens at the
> base driver, we communicate whether we have to call
> drm_atomic_helper_shutdown() by seeing if drvdata is non-NULL.
>
> Suggested-by: Maxime Ripard
> Signed-off-by: Douglas Anderson
> ---
> This commit is only compile-time tested.
>
> NOTE: this patch touches a lot more than other similar patches since
> the bind() function is long and we want to make sure that we unset the
> drvdata if bind() fails.
>
> While making this patch, I noticed that the bind() function of this
> driver is using "devm" and thus assumes it doesn't need to do much
> explicit error handling. That's actually a bug. As per kernel docs [1]
> "the lifetime of the aggregate driver does not align with any of the
> underlying struct device instances. Therefore devm cannot be used and
> all resources acquired or allocated in this callback must be
> explicitly released in the unbind callback". Fixing that is outside
> the scope of this commit.
>
> [1] https://docs.kernel.org/driver-api/component.html
>
> drivers/gpu/drm/ingenic/ingenic-drm-drv.c | 66 +++
> 1 file changed, 44 insertions(+), 22 deletions(-)
[ ... cut ... ]
> @@ -1612,6 +1633,7 @@ static struct platform_driver ingenic_drm_driver = {
> },
> .probe = ingenic_drm_probe,
> .remove = ingenic_drm_remove,
> + .shutdown = ingenic_drm_shutdown,
I resolved the trivial conflict with commit 2b9b0a9fc548
("drm/ingenic: Convert to platform remove callback returning void"),
then pushed to drm-misc-next:
c3ca98396ffa (HEAD -> drm-misc-next) drm/ingenic: Call
drm_atomic_helper_shutdown() at shutdown time
Re: [RFC PATCH 03/10] drm/panel: otm8009a: Don't double check prepared/enabled
Hi,
On Fri, Aug 4, 2023 at 2:07 PM Douglas Anderson wrote:
>
> As talked about in commit d2aacaf07395 ("drm/panel: Check for already
> prepared/enabled in drm_panel"), we want to remove needless code from
> panel drivers that was storing and double-checking the
> prepared/enabled state. Even if someone was relying on the
> double-check before, that double-check is now in the core and not
> needed in individual drivers.
>
> For the "otm8009a" driver we fully remove the storing of the "enabled"
> state and we remove the double-checking, but we still keep the storing
> of the "prepared" state since the backlight code in the driver checks
> it. This backlight code may not be perfectly safe since there doesn't
> appear to be sufficient synchronization between the backlight driver
> (which userspace can call into directly) and the code that's
> unpreparing the panel. However, this lack of safety is not new and can
> be addressed in a future patch.
>
> Signed-off-by: Douglas Anderson
> ---
> From quick inspection, I think the right way to handle the backlight
> properly is:
> 1. Start calling backlight_get_brightness() instead of directly
>getting "bd->props.brightness" and bd->props.power. This should
>return 0 for a disabled (or blanked or powered off) backlight.
> 2. Cache the backlight level in "struct otm8009a"
> 3. If the backlight isn't changing compared to the cached value, make
>otm8009a_backlight_update_status() a no-op.
> 4. Remove the caching of the "prepared" value.
>
> That should work and always be safe because we always enable/disable
> the backlight in the panel's enable() and disable() functions. The
> backlight core has proper locking in this case. A disabled backlight
> will always return a level of 0 which will always make the backlight's
> update_status a no-op when the panel is disabled and keep us from
> trying to talk to the panel when it's off. Userspace can't directly
> cause a backlight to be enabled/disabled, it can only affect the other
> blanking modes.
Note: I'm not planning to take on the cleanup of making the backlight
of this driver work better. Ideally someone who uses / maintains the
affected hardware could give it a shot.
> .../gpu/drm/panel/panel-orisetech-otm8009a.c| 17 -
> 1 file changed, 17 deletions(-)
In response to the cover letter [1], I proposed landing patches #1-#3
directly from here while we resolve the issues talked about in
response to patch #4 [2]. I didn't hear any complaints, so I took
Linus W's review tag from the cover letter and pushed this to
drm-misc-next.
1e0465eb16a4 drm/panel: otm8009a: Don't double check prepared/enabled
[1]
https://lore.kernel.org/r/CAD=FV=ufuusrrzmkl8_rl5wlvkjrydwrsay_pwta-hx_p0d...@mail.gmail.com
[2]
https://lore.kernel.org/r/20230804140605.RFC.4.I930069a32baab6faf46d6b234f89613b5cec0f14@changeid/
Re: [RFC PATCH 02/10] drm/panel: s6e63m0: Don't store+check prepared/enabled
Hi,
On Fri, Aug 4, 2023 at 2:07 PM Douglas Anderson wrote:
>
> As talked about in commit d2aacaf07395 ("drm/panel: Check for already
> prepared/enabled in drm_panel"), we want to remove needless code from
> panel drivers that was storing and double-checking the
> prepared/enabled state. Even if someone was relying on the
> double-check before, that double-check is now in the core and not
> needed in individual drivers.
>
> For the s6e63m0 panel driver, this actually fixes a subtle/minor error
> handling bug in s6e63m0_prepare(). In one error case s6e63m0_prepare()
> called s6e63m0_unprepare() directly if there was an error. This call
> to s6e63m0_unprepare() would have been a no-op since ctx->prepared
> wasn't set yet.
>
> Signed-off-by: Douglas Anderson
> ---
>
> drivers/gpu/drm/panel/panel-samsung-s6e63m0.c | 25 ---
> 1 file changed, 25 deletions(-)
In response to the cover letter [1], I proposed landing patches #1-#3
directly from here while we resolve the issues talked about in
response to patch #4 [2]. I didn't hear any complaints, so I took
Linus W's review tag from the cover letter and pushed this to
drm-misc-next.
d43f0fe153dc drm/panel: s6e63m0: Don't store+check prepared/enabled
[1]
https://lore.kernel.org/r/CAD=FV=ufuusrrzmkl8_rl5wlvkjrydwrsay_pwta-hx_p0d...@mail.gmail.com
[2]
https://lore.kernel.org/r/20230804140605.RFC.4.I930069a32baab6faf46d6b234f89613b5cec0f14@changeid/
Re: [RFC PATCH 01/10] drm/panel: Don't store+check prepared/enabled for simple cases
Hi,
On Fri, Aug 4, 2023 at 2:07 PM Douglas Anderson wrote:
>
> As talked about in commit d2aacaf07395 ("drm/panel: Check for already
> prepared/enabled in drm_panel"), we want to remove needless code from
> panel drivers that was storing and double-checking the
> prepared/enabled state. Even if someone was relying on the
> double-check before, that double-check is now in the core and not
> needed in individual drivers.
>
> This pile of panel drivers appears to be simple to handle. Based on
> code inspection they seemed to be using the prepared/enabled state
> simply for double-checking that nothing else in the kernel called them
> inconsistently. Now that the core drm_panel is doing the double
> checking (and warning) it should be very clear that these devices
> don't need their own double-check.
>
> Signed-off-by: Douglas Anderson
> ---
>
> .../drm/panel/panel-asus-z00t-tm5p5-n35596.c | 9 -
> .../gpu/drm/panel/panel-boe-bf060y8m-aj0.c| 9 -
> drivers/gpu/drm/panel/panel-jdi-fhd-r63452.c | 9 -
> drivers/gpu/drm/panel/panel-novatek-nt35950.c | 9 -
> drivers/gpu/drm/panel/panel-novatek-nt36523.c | 12 --
> drivers/gpu/drm/panel/panel-raydium-rm68200.c | 38 ---
> .../panel/panel-samsung-s6e88a0-ams452ef01.c | 10 -
> drivers/gpu/drm/panel/panel-samsung-sofef00.c | 9 -
> .../gpu/drm/panel/panel-sharp-ls060t1sx01.c | 10 -
> drivers/gpu/drm/panel/panel-sony-td4353-jdi.c | 9 -
> .../panel/panel-sony-tulip-truly-nt35521.c| 18 -
> .../drm/panel/panel-startek-kd070fhfid015.c | 11 --
> drivers/gpu/drm/panel/panel-truly-nt35597.c | 20 --
> drivers/gpu/drm/panel/panel-visionox-r66451.c | 16
> .../gpu/drm/panel/panel-visionox-rm69299.c| 8
> .../gpu/drm/panel/panel-visionox-vtdr6130.c | 9 -
> 16 files changed, 206 deletions(-)
In response to the cover letter [1], I proposed landing patches #1-#3
directly from here while we resolve the issues talked about in
response to patch #4 [2]. I didn't hear any complaints, so I took
Linus W's review tag from the cover letter and pushed this to
drm-misc-next.
f8c37b88092e drm/panel: Don't store+check prepared/enabled for simple cases
[1]
https://lore.kernel.org/r/CAD=FV=ufuusrrzmkl8_rl5wlvkjrydwrsay_pwta-hx_p0d...@mail.gmail.com
[2]
https://lore.kernel.org/r/20230804140605.RFC.4.I930069a32baab6faf46d6b234f89613b5cec0f14@changeid/
Re: [RFT PATCH 1/6] drm/atomic-helper: drm_atomic_helper_shutdown(NULL) should be a noop
Hi, On Tue, Sep 5, 2023 at 2:14 PM Doug Anderson wrote: > > Hi, > > On Mon, Sep 4, 2023 at 12:55 AM Maxime Ripard wrote: > > > > On Fri, 1 Sep 2023 16:39:52 -0700, Douglas Anderson wrote: > > > As with other places in the Linux kernel--kfree(NULL) being the most > > > famous example--it's convenient to treat being passed a NULL argument > > > as a noop in cleanup functions. Let's make > > > drm_atomic_helper_shutdown() work like this. > > > > > > > > > [ ... ] > > > > Acked-by: Maxime Ripard > > Thanks! If there are no objections, I'd tend to land this patch > sometime early next week just to get it out of the queue, even if > other patches in the series are still being discussed / need spinning. > If anyone objects to that idea, please shout. Landed to drm-misc-next. 2a073968289d drm/atomic-helper: drm_atomic_helper_shutdown(NULL) should be a noop
Re: [PATCH] MAINTAINERS: Update DRM DRIVERS FOR FREESCALE IMX entry
Hi, On Wed, Sep 6, 2023 at 7:28 AM Douglas Anderson wrote: > > As per the discussion on the lists [1], changes to this driver > generally flow through drm-misc. If they need to be coordinated with > v4l2 they sometimes go through Philipp Zabel's tree instead. List both > trees in MAINTAINERS. Also update the title of this driver to specify > that it's just for IMX 5/6 since, as per Philipp "There are a lot more > i.MX that do not use IPUv3 than those that do." > > [1] > https://lore.kernel.org/r/d56dfb568711b4b932edc9601010feda020c2c22.ca...@pengutronix.de > > Signed-off-by: Douglas Anderson > --- > I'd expect this MAINTAINERS update to go through drm-misc. > > MAINTAINERS | 4 +++- > 1 file changed, 3 insertions(+), 1 deletion(-) Pushed to drm-misc-next: 92e62478b62c MAINTAINERS: Update DRM DRIVERS FOR FREESCALE IMX entry
Re: [RFT PATCH 03/15] drm/ingenic: Call drm_atomic_helper_shutdown() at shutdown time
Hi Doug, Le mercredi 13 septembre 2023 à 09:25 -0700, Doug Anderson a écrit : > Hi, > > On Tue, Sep 5, 2023 at 1:16 PM Doug Anderson > wrote: > > > > Paul, > > > > On Mon, Sep 4, 2023 at 2:15 AM Paul Cercueil > > wrote: > > > > > > Hi Douglas, > > > > > > Le vendredi 01 septembre 2023 à 16:41 -0700, Douglas Anderson a > > > écrit : > > > > Based on grepping through the source code this driver appears > > > > to be > > > > missing a call to drm_atomic_helper_shutdown() at system > > > > shutdown > > > > time. Among other things, this means that if a panel is in use > > > > that > > > > it > > > > won't be cleanly powered off at system shutdown time. > > > > > > > > The fact that we should call drm_atomic_helper_shutdown() in > > > > the case > > > > of OS shutdown/restart comes straight out of the kernel doc > > > > "driver > > > > instance overview" in drm_drv.c. > > > > > > > > Since this driver uses the component model and shutdown happens > > > > at > > > > the > > > > base driver, we communicate whether we have to call > > > > drm_atomic_helper_shutdown() by seeing if drvdata is non-NULL. > > > > > > > > Suggested-by: Maxime Ripard > > > > Signed-off-by: Douglas Anderson > > > > > > LGTM. > > > Acked-by: Paul Cercueil > > > > Thanks for the Ack! Would you expect this patch to land through > > "drm-misc", or do you expect it to go through some other tree? > > Running: > > > > ./scripts/get_maintainer.pl --scm -f > > drivers/gpu/drm/ingenic/ingenic-drm-drv.c > > > > ...does not show that this driver normally goes through drm-misc, > > but > > it also doesn't show that it goes through any other tree so maybe > > it's > > just an artifact of the way it's tagged in the MAINTAINERS file? If > > it's fine for this to go through drm-misc, I'll probably land it > > (with > > your Ack and Maxime's Review) sooner rather than later just to make > > this patch series less unwieldy. > > > > > > > > --- > > > > This commit is only compile-time tested. > > > > > > > > NOTE: this patch touches a lot more than other similar patches > > > > since > > > > the bind() function is long and we want to make sure that we > > > > unset > > > > the > > > > drvdata if bind() fails. > > > > > > > > While making this patch, I noticed that the bind() function of > > > > this > > > > driver is using "devm" and thus assumes it doesn't need to do > > > > much > > > > explicit error handling. That's actually a bug. As per kernel > > > > docs > > > > [1] > > > > "the lifetime of the aggregate driver does not align with any > > > > of the > > > > underlying struct device instances. Therefore devm cannot be > > > > used and > > > > all resources acquired or allocated in this callback must be > > > > explicitly released in the unbind callback". Fixing that is > > > > outside > > > > the scope of this commit. > > > > > > > > [1] https://docs.kernel.org/driver-api/component.html > > > > > > > > > > Noted, thanks. > > > > FWIW, I think that at least a few other DRM drivers handle this by > > doing some of their resource allocation / acquiring in the probe() > > function and then only doing things in the bind() that absolutely > > need > > to be in the bind. ;-) > > I've been collecting patches that are ready to land in drm-misc but, > right now, I'm not taking this patch since I didn't get any > clarification of whether it should land through drm-misc or somewhere > else. Sorry, you can take it in drm-misc, yes. Cheers, -Paul
Re: [PATCH v4 6/6] drm/drm-file: Show finer-grained BO sizes in drm_show_memory_stats
On Wed, 13 Sep 2023 09:46:45 -0700 Rob Clark wrote: > On Wed, Sep 13, 2023 at 12:36 AM Boris Brezillon > wrote: > > > > On Tue, 12 Sep 2023 19:14:35 -0700 > > Rob Clark wrote: > > > > > On Tue, Sep 12, 2023 at 6:46 PM Rob Clark wrote: > > > > > > > > On Tue, Sep 12, 2023 at 2:32 AM Boris Brezillon > > > > wrote: > > > > > > > > > > On Tue, 12 Sep 2023 09:37:00 +0100 > > > > > Adrián Larumbe wrote: > > > > > > > > > > > The current implementation will try to pick the highest available > > > > > > size > > > > > > display unit as soon as the BO size exceeds that of the previous > > > > > > multiplier. That can lead to loss of precision in BO's whose size is > > > > > > not a multiple of a MiB. > > > > > > > > > > > > Fix it by changing the unit selection criteria. > > > > > > > > > > > > For much bigger BO's, their size will naturally be aligned on > > > > > > something > > > > > > bigger than a 4 KiB page, so in practice it is very unlikely their > > > > > > display > > > > > > unit would default to KiB. > > > > > > > > > > Let's wait for Rob's opinion on this. > > > > > > > > This would mean that if you have SZ_1G + SZ_1K worth of buffers, you'd > > > > report the result in KiB.. which seems like overkill to me, esp given > > > > that the result is just a snapshot in time of a figure that > > > > realistically is dynamic. > > > > Yeah, my point was that, generally, such big buffers tend to have > > a bigger size alignment (like 2MB for anything bigger than 1GB), but > > maybe this assumption doesn't stand for all drivers. > > Maybe for CMA? Regardless, this # is the sum of buffer sizes, so you > could still get that 1G+1K scenario My bad, for some reason I had per-buffer size printing in mind.
Re: [Intel-gfx] [PATCH] drm/i915: Do not disable preemption for resets
On Wed, 13 Sept 2023 at 18:48, Sebastian Andrzej Siewior
wrote:
>
> On 2023-07-05 10:30:25 [+0100], Tvrtko Ursulin wrote:
> > From: Tvrtko Ursulin
> >
> > Commit ade8a0f59844 ("drm/i915: Make all GPU resets atomic") added a
> > preempt disable section over the hardware reset callback to prepare the
> > driver for being able to reset from atomic contexts.
> …
>
> This missed the v6.6 merge window. Has this been dropped for some reason
> or just missed by chance? Can this be still applied, please?
>
Just an FYI, but I happened to be looking at an internal bug report
for exactly this
error site, so +1 here :)
>
> Sebastian
>
Re: [PATCH v3] drm/plane: Add documentation about software color conversion.
On 9/13/23 10:14, Jocelyn Falempe wrote: > On 12/09/2023 17:57, Michel Dänzer wrote: >> On 9/11/23 10:38, Pekka Paalanen wrote: >>> On Fri, 8 Sep 2023 17:10:46 +0200 >>> Thomas Zimmermann wrote: Am 08.09.23 um 16:41 schrieb Pekka Paalanen: > On Fri, 8 Sep 2023 15:56:51 +0200 > Thomas Zimmermann wrote: >> >> Another point of concern is CPU consumption: Slow I/O buses may stall >> the display thread, but the CPU could do something else in the meantime. >> Doing format conversion on the CPU prevents that, hence affecting other >> parts of the system negatively. Of course, that's more of a gut feeling >> than hard data. >> >> Jocelyn, have you measured if the XRGB -> RGB888 conversion copy takes >> longer than a straight RGB888 -> RGB888 copy in the kernel? > > At least on my Matrox system, the conversion is really negligible compared to > the copy, due to slow memory bandwidth. I wasn't able to see a difference, > using ktime_get_ns(). > > The CPU is an old Intel(R) Core(TM) i3 CPU 540 @ 3.07GHz > in 1280x1024, the RGB888 copy takes 95ms. > and the XRGB->RGB888 takes also 95ms. > (and the full XRGB copy takes 125ms) Then any XRGB → RGB888 conversion in user space has to result in worse performance. > But let's admit that this discussion is going nowhere, and that I failed to > reach a consensus, so I'm now focusing on other things. I see consensus, with one person disagreeing. -- Earthling Michel Dänzer| https://redhat.com Libre software enthusiast | Mesa and Xwayland developer
Re: [RFC PATCH] drm: omapdrm: dsi: add refsel also for omap4
On Wed, 13 Sep 2023 15:11:08 +0300 Tomi Valkeinen wrote: > On 13/09/2023 09:59, Andreas Kemnade wrote: > > Some 3.0 source has it set behind a if (omap4). > > Maybe it is helpful maybe not, at least in the omap4460 > > trm these bits are marked as reserved. > > But maybe some dsi video mode panel starts magically working. > > Sorry, what does this mean? That this fixes something, or you are > just guessing? > just diffing registers between good and bad. It does not fix anything, just reducing the diff. > I'm somewhat sure that the upstream driver used to work on omap4 sdp, > which has two DSI panels. But I can't even remember what omap4 > version it had. > after we are using displays from gpu/drm/displays? Regards Andreas
Re: [PATCH] drm/amd/display: Fix -Wuninitialized in dm_helpers_dp_mst_send_payload_allocation()
On 9/13/23 12:10, Nathan Chancellor wrote:
When building with clang, there is a warning (or error when
CONFIG_WERROR is set):
drivers/gpu/drm/amd/amdgpu/../display/amdgpu_dm/amdgpu_dm_helpers.c:368:21:
error: variable 'old_payload' is uninitialized when used here
[-Werror,-Wuninitialized]
368 | new_payload,
old_payload);
|
^~~
drivers/gpu/drm/amd/amdgpu/../display/amdgpu_dm/amdgpu_dm_helpers.c:344:61:
note: initialize the variable 'old_payload' to silence this warning
344 | struct drm_dp_mst_atomic_payload *new_payload, *old_payload;
|^
|
= NULL
1 error generated.
This variable is not required outside of this function so allocate
old_payload on the stack and pass it by reference to
dm_helpers_construct_old_payload(), resolving the warning.
Closes: https://github.com/ClangBuiltLinux/linux/issues/1931
Fixes: 5aa1dfcdf0a4 ("drm/mst: Refactor the flow for payload
allocation/removement")
Signed-off-by: Nathan Chancellor
Applied, thanks!
---
drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_helpers.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_helpers.c
b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_helpers.c
index 9ad509279b0a..c4c35f6844f4 100644
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_helpers.c
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_helpers.c
@@ -341,7 +341,7 @@ bool dm_helpers_dp_mst_send_payload_allocation(
struct amdgpu_dm_connector *aconnector;
struct drm_dp_mst_topology_state *mst_state;
struct drm_dp_mst_topology_mgr *mst_mgr;
- struct drm_dp_mst_atomic_payload *new_payload, *old_payload;
+ struct drm_dp_mst_atomic_payload *new_payload, old_payload;
enum mst_progress_status set_flag = MST_ALLOCATE_NEW_PAYLOAD;
enum mst_progress_status clr_flag = MST_CLEAR_ALLOCATED_PAYLOAD;
int ret = 0;
@@ -365,8 +365,8 @@ bool dm_helpers_dp_mst_send_payload_allocation(
ret = drm_dp_add_payload_part2(mst_mgr, mst_state->base.state,
new_payload);
} else {
dm_helpers_construct_old_payload(stream->link,
mst_state->pbn_div,
-new_payload, old_payload);
- drm_dp_remove_payload_part2(mst_mgr, mst_state, old_payload,
new_payload);
+new_payload, _payload);
+ drm_dp_remove_payload_part2(mst_mgr, mst_state, _payload,
new_payload);
}
if (ret) {
---
base-commit: 8569c31545385195bdb0c021124e68336e91c693
change-id:
20230913-fix-wuninitialized-dm_helpers_dp_mst_send_payload_allocation-c37b33aaad18
Best regards,
--
Hamza
Re: drm/vkms: deadlock between dev->event_lock and timer
On Wed, 13 Sept 2023 at 07:21, Tetsuo Handa
wrote:
>
> Hello. A deadlock was reported in drivers/gpu/drm/vkms/ .
> It looks like this locking pattern remains as of 6.6-rc1. Please fix.
>
> void drm_crtc_vblank_off(struct drm_crtc *crtc) {
> spin_lock_irq(>event_lock);
> drm_vblank_disable_and_save(dev, pipe) {
> __disable_vblank(dev, pipe) {
> crtc->funcs->disable_vblank(crtc) == vkms_disable_vblank {
> hrtimer_cancel(>vblank_hrtimer) { // Retries with
> dev->event_lock held until lock_hrtimer_base() succeeds.
> ret = hrtimer_try_to_cancel(timer) {
> base = lock_hrtimer_base(timer, ); // Fails forever because
> vkms_vblank_simulate() is in progress.
Heh. Ok. This is clearly a bug, but it does seem to be limited to just
the vkms driver, and literally only to the "simulate vblank" case.
The worst part about it is that it's so subtle and not obvious.
Some light grepping seems to show that amdgpu has almost the exact
same pattern in its own vkms thing, except it uses
hrtimer_try_to_cancel(_crtc->vblank_timer);
directly, which presumably fixes the livelock, but means that the
cancel will fail if it's currently running.
So just doing the same thing in the vkms driver probably fixes things.
Maybe the vkms people need to add a flag to say "it's canceled" so
that it doesn't then get re-enabled? Or maybe it doesn't matter
and/or already happens for some reason I didn't look into.
Linus
Re: [PATCH v4 6/6] drm/drm-file: Show finer-grained BO sizes in drm_show_memory_stats
On Wed, Sep 13, 2023 at 12:36 AM Boris Brezillon
wrote:
>
> On Tue, 12 Sep 2023 19:14:35 -0700
> Rob Clark wrote:
>
> > On Tue, Sep 12, 2023 at 6:46 PM Rob Clark wrote:
> > >
> > > On Tue, Sep 12, 2023 at 2:32 AM Boris Brezillon
> > > wrote:
> > > >
> > > > On Tue, 12 Sep 2023 09:37:00 +0100
> > > > Adrián Larumbe wrote:
> > > >
> > > > > The current implementation will try to pick the highest available size
> > > > > display unit as soon as the BO size exceeds that of the previous
> > > > > multiplier. That can lead to loss of precision in BO's whose size is
> > > > > not a multiple of a MiB.
> > > > >
> > > > > Fix it by changing the unit selection criteria.
> > > > >
> > > > > For much bigger BO's, their size will naturally be aligned on
> > > > > something
> > > > > bigger than a 4 KiB page, so in practice it is very unlikely their
> > > > > display
> > > > > unit would default to KiB.
> > > >
> > > > Let's wait for Rob's opinion on this.
> > >
> > > This would mean that if you have SZ_1G + SZ_1K worth of buffers, you'd
> > > report the result in KiB.. which seems like overkill to me, esp given
> > > that the result is just a snapshot in time of a figure that
> > > realistically is dynamic.
>
> Yeah, my point was that, generally, such big buffers tend to have
> a bigger size alignment (like 2MB for anything bigger than 1GB), but
> maybe this assumption doesn't stand for all drivers.
Maybe for CMA? Regardless, this # is the sum of buffer sizes, so you
could still get that 1G+1K scenario
> > >
> > > Maybe if you have SZ_1G+SZ_1K worth of buffers you should report the
> > > result with more precision than GiB, but more than MiB seems a bit
> > > overkill.
> > >
> > > BR,
> > > -R
> > >
> > > > >
> > > > > Signed-off-by: Adrián Larumbe
> > > > > ---
> > > > > drivers/gpu/drm/drm_file.c | 2 +-
> > > > > 1 file changed, 1 insertion(+), 1 deletion(-)
> > > > >
> > > > > diff --git a/drivers/gpu/drm/drm_file.c b/drivers/gpu/drm/drm_file.c
> > > > > index 762965e3d503..bf7d2fe46bfa 100644
> > > > > --- a/drivers/gpu/drm/drm_file.c
> > > > > +++ b/drivers/gpu/drm/drm_file.c
> > > > > @@ -879,7 +879,7 @@ static void print_size(struct drm_printer *p,
> > > > > const char *stat,
> > > > > unsigned u;
> > > > >
> > > > > for (u = 0; u < ARRAY_SIZE(units) - 1; u++) {
> > > > > - if (sz < SZ_1K)
> >
> > btw, I was thinking more along the lines of:
> >
> >if (sz < 10*SZ_1K)
> >
> > (or perhaps maybe 100*SZ_1K)
>
> I think I suggested doing that at some point:
>
> if ((sz & (SZ_1K - 1)) &&
> sz < UPPER_UNIT_THRESHOLD * SZ_1K)
> break;
>
> so we can keep using the upper unit if the size is a multiple of this
> upper unit, even if it's smaller than the selected threshold.
yeah, that wfm
BR,
-R
>
> >
> > I mean, any visualization tool is going to scale the y axis based on
> > the order of magnitude.. and if I'm looking at the fdinfo with my
> > eyeballs I don't want to count the # of digits manually to do the
> > conversion in my head. The difference btwn 4 or 5 or maybe 6 digits
> > is easy enough to eyeball, but more than that is too much for my
> > eyesight, and I'm not seeing how it is useful ;-)
> >
> > But if someone really has a valid use case for having precision in 1KB
> > then I'm willing to be overruled.
>
> So, precision loss was one aspect, but my main concern was having
> things displayed in KiB when they could have been displayed in MiB,
> because the size is a multiple of a MiB but still not big enough to
> pass the threshold test (which was set to 1x in the previous
> version).
>
> > But I'm not a fan of the earlier
> > approach of different drivers reporting results differently, the whole
> > point of fdinfo was to have some standardized reporting.
>
> Totally agree with that.
>
> >
> > BR,
> > -R
> >
> > > > > + if (sz & (SZ_1K - 1))
> > > > > break;
> > > > > sz = div_u64(sz, SZ_1K);
> > > > > }
> > > >
>
[RFC PATCH v2 3/5] drm/amd/display: create DCN3-specific log for MPC state
Logging DCN3 MPC state was following DCN1 implementation that doesn't
consider new DCN3 MPC color blocks. Create new elements according to
DCN3 MPC color caps and a new DCN3-specific function for reading MPC
data.
Signed-off-by: Melissa Wen
---
.../gpu/drm/amd/display/dc/dcn30/dcn30_mpc.c | 55 ++-
drivers/gpu/drm/amd/display/dc/inc/hw/mpc.h | 13 +
2 files changed, 67 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/amd/display/dc/dcn30/dcn30_mpc.c
b/drivers/gpu/drm/amd/display/dc/dcn30/dcn30_mpc.c
index d1500b223858..d164fbf89212 100644
--- a/drivers/gpu/drm/amd/display/dc/dcn30/dcn30_mpc.c
+++ b/drivers/gpu/drm/amd/display/dc/dcn30/dcn30_mpc.c
@@ -1382,8 +1382,61 @@ static void mpc3_set_mpc_mem_lp_mode(struct mpc *mpc)
}
}
+static void mpc3_read_mpcc_state(
+ struct mpc *mpc,
+ int mpcc_inst,
+ struct mpcc_state *s)
+{
+ struct dcn30_mpc *mpc30 = TO_DCN30_MPC(mpc);
+ uint32_t rmu_status = 0xf;
+
+ REG_GET(MPCC_OPP_ID[mpcc_inst], MPCC_OPP_ID, >opp_id);
+ REG_GET(MPCC_TOP_SEL[mpcc_inst], MPCC_TOP_SEL, >dpp_id);
+ REG_GET(MPCC_BOT_SEL[mpcc_inst], MPCC_BOT_SEL, >bot_mpcc_id);
+ REG_GET_4(MPCC_CONTROL[mpcc_inst], MPCC_MODE, >mode,
+ MPCC_ALPHA_BLND_MODE, >alpha_mode,
+ MPCC_ALPHA_MULTIPLIED_MODE, >pre_multiplied_alpha,
+ MPCC_BLND_ACTIVE_OVERLAP_ONLY, >overlap_only);
+ REG_GET_2(MPCC_STATUS[mpcc_inst], MPCC_IDLE, >idle,
+ MPCC_BUSY, >busy);
+
+ /* Color blocks state */
+ REG_GET(MPC_RMU_CONTROL, MPC_RMU0_MUX_STATUS, _status);
+ if (rmu_status == mpcc_inst) {
+ REG_GET(SHAPER_CONTROL[0],
+ MPC_RMU_SHAPER_LUT_MODE_CURRENT, >shaper_lut_mode);
+ REG_GET(RMU_3DLUT_MODE[0],
+ MPC_RMU_3DLUT_MODE_CURRENT, >lut3d_mode);
+ REG_GET(RMU_3DLUT_READ_WRITE_CONTROL[0],
+ MPC_RMU_3DLUT_30BIT_EN, >lut3d_bit_depth);
+ REG_GET(RMU_3DLUT_MODE[0],
+ MPC_RMU_3DLUT_SIZE, >lut3d_size);
+ } else {
+ REG_GET(SHAPER_CONTROL[1],
+ MPC_RMU_SHAPER_LUT_MODE_CURRENT, >shaper_lut_mode);
+ REG_GET(RMU_3DLUT_MODE[1],
+ MPC_RMU_3DLUT_MODE_CURRENT, >lut3d_mode);
+ REG_GET(RMU_3DLUT_READ_WRITE_CONTROL[1],
+ MPC_RMU_3DLUT_30BIT_EN, >lut3d_bit_depth);
+ REG_GET(RMU_3DLUT_MODE[1],
+ MPC_RMU_3DLUT_SIZE, >lut3d_size);
+ }
+ REG_GET_2(MPCC_OGAM_CONTROL[mpcc_inst],
+ MPCC_OGAM_MODE_CURRENT, >rgam_mode,
+ MPCC_OGAM_SELECT_CURRENT, >rgam_lut);
+ REG_GET(MPCC_GAMUT_REMAP_MODE[mpcc_inst],
+ MPCC_GAMUT_REMAP_MODE_CURRENT, >gamut_remap_mode);
+ if (s->gamut_remap_mode == 1) {
+ s->gamut_remap_c11_c12 =
REG_READ(MPC_GAMUT_REMAP_C11_C12_A[mpcc_inst]);
+ s->gamut_remap_c33_c34 =
REG_READ(MPC_GAMUT_REMAP_C33_C34_A[mpcc_inst]);
+ } else if (s->gamut_remap_mode == 2) {
+ s->gamut_remap_c11_c12 =
REG_READ(MPC_GAMUT_REMAP_C11_C12_B[mpcc_inst]);
+ s->gamut_remap_c33_c34 =
REG_READ(MPC_GAMUT_REMAP_C33_C34_B[mpcc_inst]);
+ }
+}
+
static const struct mpc_funcs dcn30_mpc_funcs = {
- .read_mpcc_state = mpc1_read_mpcc_state,
+ .read_mpcc_state = mpc3_read_mpcc_state,
.insert_plane = mpc1_insert_plane,
.remove_mpcc = mpc1_remove_mpcc,
.mpc_init = mpc1_mpc_init,
diff --git a/drivers/gpu/drm/amd/display/dc/inc/hw/mpc.h
b/drivers/gpu/drm/amd/display/dc/inc/hw/mpc.h
index 8d86159d9de0..e60b3503605b 100644
--- a/drivers/gpu/drm/amd/display/dc/inc/hw/mpc.h
+++ b/drivers/gpu/drm/amd/display/dc/inc/hw/mpc.h
@@ -193,6 +193,19 @@ struct mpcc_state {
uint32_t overlap_only;
uint32_t idle;
uint32_t busy;
+ uint32_t shaper_lut_mode;
+ uint32_t lut3d_mode;
+ uint32_t lut3d_bit_depth;
+ uint32_t lut3d_size;
+ uint32_t rgam_mode;
+ uint32_t rgam_lut;
+ uint32_t gamut_remap_mode;
+ uint32_t gamut_remap_c11_c12;
+ uint32_t gamut_remap_c13_c14;
+ uint32_t gamut_remap_c21_c22;
+ uint32_t gamut_remap_c23_c24;
+ uint32_t gamut_remap_c31_c32;
+ uint32_t gamut_remap_c33_c34;
};
/**
--
2.40.1
[RFC PATCH v2 5/5] drm/amd/display: add DPP and MPC color caps to DTN log
Add color caps information for DPP and MPC block to show HW color caps.
Signed-off-by: Melissa Wen
---
.../amd/display/dc/dcn10/dcn10_hw_sequencer.c | 23 +++
.../drm/amd/display/dc/dcn30/dcn30_hwseq.c| 23 +++
2 files changed, 46 insertions(+)
diff --git a/drivers/gpu/drm/amd/display/dc/dcn10/dcn10_hw_sequencer.c
b/drivers/gpu/drm/amd/display/dc/dcn10/dcn10_hw_sequencer.c
index 9255425ef794..49285f0a146a 100644
--- a/drivers/gpu/drm/amd/display/dc/dcn10/dcn10_hw_sequencer.c
+++ b/drivers/gpu/drm/amd/display/dc/dcn10/dcn10_hw_sequencer.c
@@ -330,6 +330,24 @@ dcn10_log_color_state(struct dc *dc,
DTN_INFO("\n");
}
DTN_INFO("\n");
+ DTN_INFO("DPP Color Caps: input_lut_shared:%d icsc:%d"
+" dgam_ram:%d dgam_rom:
srgb:%d,bt2020:%d,gamma2_2:%d,pq:%d,hlg:%d"
+" post_csc:%d gamcor:%d dgam_rom_for_yuv:%d 3d_lut:%d"
+" blnd_lut:%d oscs:%d\n\n",
+dc->caps.color.dpp.input_lut_shared,
+dc->caps.color.dpp.icsc,
+dc->caps.color.dpp.dgam_ram,
+dc->caps.color.dpp.dgam_rom_caps.srgb,
+dc->caps.color.dpp.dgam_rom_caps.bt2020,
+dc->caps.color.dpp.dgam_rom_caps.gamma2_2,
+dc->caps.color.dpp.dgam_rom_caps.pq,
+dc->caps.color.dpp.dgam_rom_caps.hlg,
+dc->caps.color.dpp.post_csc,
+dc->caps.color.dpp.gamma_corr,
+dc->caps.color.dpp.dgam_rom_for_yuv,
+dc->caps.color.dpp.hw_3d_lut,
+dc->caps.color.dpp.ogam_ram,
+dc->caps.color.dpp.ocsc);
DTN_INFO("MPCC: OPP DPP MPCCBOT MODE ALPHA_MODE PREMULT
OVERLAP_ONLY IDLE\n");
for (i = 0; i < pool->pipe_count; i++) {
@@ -343,6 +361,11 @@ dcn10_log_color_state(struct dc *dc,
s.idle);
}
DTN_INFO("\n");
+ DTN_INFO("MPC Color Caps: gamut_remap:%d, 3dlut:%d, ogam_ram:%d,
ocsc:%d\n\n",
+dc->caps.color.mpc.gamut_remap,
+dc->caps.color.mpc.num_3dluts,
+dc->caps.color.mpc.ogam_ram,
+dc->caps.color.mpc.ocsc);
}
void dcn10_log_hw_state(struct dc *dc,
diff --git a/drivers/gpu/drm/amd/display/dc/dcn30/dcn30_hwseq.c
b/drivers/gpu/drm/amd/display/dc/dcn30/dcn30_hwseq.c
index 47119ae80e98..f604c684c853 100644
--- a/drivers/gpu/drm/amd/display/dc/dcn30/dcn30_hwseq.c
+++ b/drivers/gpu/drm/amd/display/dc/dcn30/dcn30_hwseq.c
@@ -124,6 +124,24 @@ dcn30_log_color_state(struct dc *dc,
DTN_INFO("\n");
}
DTN_INFO("\n");
+ DTN_INFO("DPP Color Caps: input_lut_shared:%d icsc:%d"
+" dgam_ram:%d dgam_rom:
srgb:%d,bt2020:%d,gamma2_2:%d,pq:%d,hlg:%d"
+" post_csc:%d gamcor:%d dgam_rom_for_yuv:%d 3d_lut:%d"
+" blnd_lut:%d oscs:%d\n\n",
+dc->caps.color.dpp.input_lut_shared,
+dc->caps.color.dpp.icsc,
+dc->caps.color.dpp.dgam_ram,
+dc->caps.color.dpp.dgam_rom_caps.srgb,
+dc->caps.color.dpp.dgam_rom_caps.bt2020,
+dc->caps.color.dpp.dgam_rom_caps.gamma2_2,
+dc->caps.color.dpp.dgam_rom_caps.pq,
+dc->caps.color.dpp.dgam_rom_caps.hlg,
+dc->caps.color.dpp.post_csc,
+dc->caps.color.dpp.gamma_corr,
+dc->caps.color.dpp.dgam_rom_for_yuv,
+dc->caps.color.dpp.hw_3d_lut,
+dc->caps.color.dpp.ogam_ram,
+dc->caps.color.dpp.ocsc);
DTN_INFO("MPCC: OPP DPP MPCCBOT MODE ALPHA_MODE PREMULT
OVERLAP_ONLY IDLE"
" SHAPER mode 3DLUT mode 3DLUT bit-depth 3DLUT size OGAM
mode OGAM LUT"
@@ -155,6 +173,11 @@ dcn30_log_color_state(struct dc *dc,
s.gamut_remap_c11_c12, s.gamut_remap_c33_c34);
}
DTN_INFO("\n");
+ DTN_INFO("MPC Color Caps: gamut_remap:%d, 3dlut:%d, ogam_ram:%d,
ocsc:%d\n\n",
+dc->caps.color.mpc.gamut_remap,
+dc->caps.color.mpc.num_3dluts,
+dc->caps.color.mpc.ogam_ram,
+dc->caps.color.mpc.ocsc);
}
bool dcn30_set_blend_lut(
--
2.40.1
[RFC PATCH v2 4/5] drm/amd/display: hook DCN30 color state logging to DTN log
Color caps changed between HW versions which caused DCN10 color state
sections on DTN log no longer fit DCN3.0 versions. Create a
DCN3.0-specific color state logging and hook it to drivers of DCN3.0
family.
rfc-v2:
- detail RAM mode for gamcor and blnd gamma blocks
Signed-off-by: Melissa Wen
---
.../amd/display/dc/dcn10/dcn10_hw_sequencer.c | 5 +-
.../drm/amd/display/dc/dcn30/dcn30_hwseq.c| 88 +++
.../drm/amd/display/dc/dcn30/dcn30_hwseq.h| 3 +
.../gpu/drm/amd/display/dc/dcn30/dcn30_init.c | 1 +
.../drm/amd/display/dc/dcn301/dcn301_init.c | 1 +
.../gpu/drm/amd/display/dc/inc/hw_sequencer.h | 2 +
6 files changed, 99 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/amd/display/dc/dcn10/dcn10_hw_sequencer.c
b/drivers/gpu/drm/amd/display/dc/dcn10/dcn10_hw_sequencer.c
index a0c489ed218c..9255425ef794 100644
--- a/drivers/gpu/drm/amd/display/dc/dcn10/dcn10_hw_sequencer.c
+++ b/drivers/gpu/drm/amd/display/dc/dcn10/dcn10_hw_sequencer.c
@@ -358,7 +358,10 @@ void dcn10_log_hw_state(struct dc *dc,
dcn10_log_hubp_states(dc, log_ctx);
- dcn10_log_color_state(dc, log_ctx);
+ if (dc->hwss.log_color_state)
+ dc->hwss.log_color_state(dc, log_ctx);
+ else
+ dcn10_log_color_state(dc, log_ctx);
DTN_INFO("OTG: v_bs v_be v_ss v_se vpol vmax vmin vmax_sel
vmin_sel h_bs h_be h_ss h_se hpol htot vtot underflow blank_en\n");
diff --git a/drivers/gpu/drm/amd/display/dc/dcn30/dcn30_hwseq.c
b/drivers/gpu/drm/amd/display/dc/dcn30/dcn30_hwseq.c
index 255713ec29bb..47119ae80e98 100644
--- a/drivers/gpu/drm/amd/display/dc/dcn30/dcn30_hwseq.c
+++ b/drivers/gpu/drm/amd/display/dc/dcn30/dcn30_hwseq.c
@@ -69,6 +69,94 @@
#define FN(reg_name, field_name) \
hws->shifts->field_name, hws->masks->field_name
+void
+dcn30_log_color_state(struct dc *dc,
+ struct dc_log_buffer_ctx *log_ctx)
+{
+ struct dc_context *dc_ctx = dc->ctx;
+ struct resource_pool *pool = dc->res_pool;
+ int i;
+
+ DTN_INFO("DPP: DGAM ROM DGAM ROM type DGAM LUT SHAPER mode"
+" 3DLUT mode 3DLUT bit depth 3DLUT size RGAM mode"
+" GAMUT mode "
+"C11 C12 C13 C14 C21 C22 C23 C24 C31 C32 C33 C34\n");
+
+ for (i = 0; i < pool->pipe_count; i++) {
+ struct dpp *dpp = pool->dpps[i];
+ struct dcn_dpp_state s = {0};
+
+ dpp->funcs->dpp_read_state(dpp, );
+
+ if (!s.is_enabled)
+ continue;
+
+ DTN_INFO("[%2d]: %7x %13s %8s %11s %10s %15s %10s %9s"
+" %10x %08xh %08xh %08xh %08xh %08xh %08xh",
+ dpp->inst,
+ s.pre_dgam_mode,
+ (s.pre_dgam_select == 0) ? "sRGB" :
+((s.pre_dgam_select == 1) ? "Gamma 2.2" :
+((s.pre_dgam_select == 2) ? "Gamma 2.4" :
+((s.pre_dgam_select == 3) ? "Gamma 2.6" :
+((s.pre_dgam_select == 4) ? "BT.709" :
+((s.pre_dgam_select == 5) ? "PQ" :
+((s.pre_dgam_select == 6) ? "HLG" :
+"Unknown")),
+ (s.gamcor_mode == 0) ? "Bypass" :
+((s.gamcor_mode == 1) ? "RAM A" :
+"RAM B"),
+ (s.shaper_lut_mode == 1) ? "RAM A" :
+((s.shaper_lut_mode == 2) ? "RAM B" :
+"Bypass"),
+ (s.lut3d_mode == 1) ? "RAM A" :
+((s.lut3d_mode == 2) ? "RAM B" :
+ "Bypass"),
+ (s.lut3d_bit_depth <= 0) ? "12-bit" : "10-bit",
+ (s.lut3d_size == 0) ? "17x17x17" : "9x9x9",
+ (s.rgam_lut_mode == 0) ? "Bypass" :
+((s.rgam_lut_mode == 1) ? "RAM A" :
+ "RAM B"),
+ s.gamut_remap_mode,
+ s.gamut_remap_c11_c12, s.gamut_remap_c13_c14,
+ s.gamut_remap_c21_c22, s.gamut_remap_c23_c24,
+ s.gamut_remap_c31_c32, s.gamut_remap_c33_c34);
+ DTN_INFO("\n");
+ }
+ DTN_INFO("\n");
+
+ DTN_INFO("MPCC: OPP DPP MPCCBOT MODE ALPHA_MODE PREMULT
OVERLAP_ONLY IDLE"
+" SHAPER mode 3DLUT mode 3DLUT bit-depth 3DLUT size OGAM
mode OGAM LUT"
+" GAMUT mode C11 C12 C33 C34\n");
+
+ for (i = 0; i < pool->pipe_count; i++) {
+ struct mpcc_state s = {0};
+
+ pool->mpc->funcs->read_mpcc_state(pool->mpc, i, );
+ if (s.opp_id != 0xf)
+
[RFC PATCH v2 2/5] drm/amd/display: fill up DCN3 DPP color state
DCN3 DPP color state was uncollected and some state elements from DCN1
doesn't fit DCN3. Create new elements according to DCN3 color caps and
fill them up for DTN log output.
rfc-v2:
- fix reading of gamcor and blnd gamma states
Signed-off-by: Melissa Wen
---
.../gpu/drm/amd/display/dc/dcn30/dcn30_dpp.c | 45 +--
drivers/gpu/drm/amd/display/dc/inc/hw/dpp.h | 8
2 files changed, 50 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/amd/display/dc/dcn30/dcn30_dpp.c
b/drivers/gpu/drm/amd/display/dc/dcn30/dcn30_dpp.c
index 50dc83404644..a26b33c84ae0 100644
--- a/drivers/gpu/drm/amd/display/dc/dcn30/dcn30_dpp.c
+++ b/drivers/gpu/drm/amd/display/dc/dcn30/dcn30_dpp.c
@@ -44,11 +44,50 @@
void dpp30_read_state(struct dpp *dpp_base, struct dcn_dpp_state *s)
{
struct dcn3_dpp *dpp = TO_DCN30_DPP(dpp_base);
+ uint32_t gamcor_lut_mode, rgam_lut_mode;
REG_GET(DPP_CONTROL,
- DPP_CLOCK_ENABLE, >is_enabled);
-
- // TODO: Implement for DCN3
+ DPP_CLOCK_ENABLE, >is_enabled);
+ // Pre-degamma (ROM)
+ REG_GET_2(PRE_DEGAM,
+ PRE_DEGAM_MODE, >pre_dgam_mode,
+ PRE_DEGAM_SELECT, >pre_dgam_select);
+ // Gamma Correction (RAM)
+ REG_GET(CM_GAMCOR_CONTROL,
+ CM_GAMCOR_MODE_CURRENT, >gamcor_mode);
+ if (s->gamcor_mode) {
+ REG_GET(CM_GAMCOR_CONTROL, CM_GAMCOR_SELECT_CURRENT,
_lut_mode);
+ if (!gamcor_lut_mode)
+ s->gamcor_mode = LUT_RAM_A; // Otherwise, LUT_RAM_B
+ }
+ // Shaper LUT (RAM), 3D LUT (mode, bit-depth, size)
+ REG_GET(CM_SHAPER_CONTROL,
+ CM_SHAPER_LUT_MODE, >shaper_lut_mode);
+ REG_GET(CM_3DLUT_MODE,
+ CM_3DLUT_MODE_CURRENT, >lut3d_mode);
+ REG_GET(CM_3DLUT_READ_WRITE_CONTROL,
+ CM_3DLUT_30BIT_EN, >lut3d_bit_depth);
+ REG_GET(CM_3DLUT_MODE,
+ CM_3DLUT_SIZE, >lut3d_size);
+ // Gamut Remap Matrix (3x4)
+ REG_GET(CM_GAMUT_REMAP_CONTROL,
+ CM_GAMUT_REMAP_MODE, >gamut_remap_mode);
+ if (s->gamut_remap_mode) {
+ s->gamut_remap_c11_c12 = REG_READ(CM_GAMUT_REMAP_C11_C12);
+ s->gamut_remap_c13_c14 = REG_READ(CM_GAMUT_REMAP_C13_C14);
+ s->gamut_remap_c21_c22 = REG_READ(CM_GAMUT_REMAP_C21_C22);
+ s->gamut_remap_c23_c24 = REG_READ(CM_GAMUT_REMAP_C23_C24);
+ s->gamut_remap_c31_c32 = REG_READ(CM_GAMUT_REMAP_C31_C32);
+ s->gamut_remap_c33_c34 = REG_READ(CM_GAMUT_REMAP_C33_C34);
+ }
+ // Blend/Out Gamma (RAM)
+ REG_GET(CM_BLNDGAM_CONTROL,
+ CM_BLNDGAM_MODE_CURRENT, >rgam_lut_mode);
+ if (s->rgam_lut_mode){
+ REG_GET(CM_BLNDGAM_CONTROL, CM_BLNDGAM_SELECT_CURRENT,
_lut_mode);
+ if (!rgam_lut_mode)
+ s->rgam_lut_mode = LUT_RAM_A; // Otherwise, LUT_RAM_B
+ }
}
/*program post scaler scs block in dpp CM*/
void dpp3_program_post_csc(
diff --git a/drivers/gpu/drm/amd/display/dc/inc/hw/dpp.h
b/drivers/gpu/drm/amd/display/dc/inc/hw/dpp.h
index f4aa76e02518..1dfe08dc4364 100644
--- a/drivers/gpu/drm/amd/display/dc/inc/hw/dpp.h
+++ b/drivers/gpu/drm/amd/display/dc/inc/hw/dpp.h
@@ -148,6 +148,14 @@ struct dcn_dpp_state {
uint32_t gamut_remap_c23_c24;
uint32_t gamut_remap_c31_c32;
uint32_t gamut_remap_c33_c34;
+ uint32_t shaper_lut_mode;
+ uint32_t lut3d_mode;
+ uint32_t lut3d_bit_depth;
+ uint32_t lut3d_size;
+ uint32_t blnd_lut_mode;
+ uint32_t pre_dgam_mode;
+ uint32_t pre_dgam_select;
+ uint32_t gamcor_mode;
};
struct CM_bias_params {
--
2.40.1
[RFC PATCH v2 1/5] drm/amd/display: detach color state from hw state logging
Prepare to hook color state logging according to DCN version.
Signed-off-by: Melissa Wen
---
.../amd/display/dc/dcn10/dcn10_hw_sequencer.c | 27 +--
1 file changed, 19 insertions(+), 8 deletions(-)
diff --git a/drivers/gpu/drm/amd/display/dc/dcn10/dcn10_hw_sequencer.c
b/drivers/gpu/drm/amd/display/dc/dcn10/dcn10_hw_sequencer.c
index 79befa17bb03..a0c489ed218c 100644
--- a/drivers/gpu/drm/amd/display/dc/dcn10/dcn10_hw_sequencer.c
+++ b/drivers/gpu/drm/amd/display/dc/dcn10/dcn10_hw_sequencer.c
@@ -279,19 +279,14 @@ static void dcn10_log_hubp_states(struct dc *dc, void
*log_ctx)
DTN_INFO("\n");
}
-void dcn10_log_hw_state(struct dc *dc,
- struct dc_log_buffer_ctx *log_ctx)
+static void
+dcn10_log_color_state(struct dc *dc,
+ struct dc_log_buffer_ctx *log_ctx)
{
struct dc_context *dc_ctx = dc->ctx;
struct resource_pool *pool = dc->res_pool;
int i;
- DTN_INFO_BEGIN();
-
- dcn10_log_hubbub_state(dc, log_ctx);
-
- dcn10_log_hubp_states(dc, log_ctx);
-
DTN_INFO("DPP:IGAM format IGAM modeDGAM modeRGAM mode"
" GAMUT mode C11 C12 C13 C14 C21 C22 C23 C24 "
"C31 C32 C33 C34\n");
@@ -348,6 +343,22 @@ void dcn10_log_hw_state(struct dc *dc,
s.idle);
}
DTN_INFO("\n");
+}
+
+void dcn10_log_hw_state(struct dc *dc,
+ struct dc_log_buffer_ctx *log_ctx)
+{
+ struct dc_context *dc_ctx = dc->ctx;
+ struct resource_pool *pool = dc->res_pool;
+ int i;
+
+ DTN_INFO_BEGIN();
+
+ dcn10_log_hubbub_state(dc, log_ctx);
+
+ dcn10_log_hubp_states(dc, log_ctx);
+
+ dcn10_log_color_state(dc, log_ctx);
DTN_INFO("OTG: v_bs v_be v_ss v_se vpol vmax vmin vmax_sel
vmin_sel h_bs h_be h_ss h_se hpol htot vtot underflow blank_en\n");
--
2.40.1
[RFC PATCH v2 0/5] drm/amd/display: improve DTN color state log
Hi, This is an update of previous RFC [0] improving the data collection of Gamma Correction and Blend Gamma color blocks. As I mentioned in the last version, I'm updating the color state part of DTN log to match DCN3.0 HW better. Currently, the DTN log considers the DCN10 color pipeline, which is useless for DCN3.0 because of all the differences in color caps between DCN versions. In addition to new color blocks and caps, some semantic differences made the DCN10 output not fit DCN30. In this RFC, the first patch adds new color state elements to DPP and implements the reading of registers according to HW blocks. Similarly to MPC, the second patch also creates a DCN3-specific function to read the MPC state and add the MPC color state logging to it. With DPP and MPC color-register reading, I detach DCN10 color state logging from the HW log and create a `.log_color_state` hook for logging color state according to HW color blocks with DCN30 as the first use case. Finally, the last patch adds DPP and MPC color caps output to facilitate understanding of the color state log. This version works well with the driver-specific color properties[1] and steamdeck/gamescope[2] together, where we can see color state changing from default values. Here is a before vs. after example: Without this series: === DPP:IGAM format IGAM modeDGAM modeRGAM mode GAMUT mode C11 C12 C13 C14 C21 C22 C23 C24 C31 C32 C33 C34 [ 0]:0h BypassFixed Bypass Bypass0h h h h h h [ 3]:0h BypassFixed Bypass Bypass0h h h h h h MPCC: OPP DPP MPCCBOT MODE ALPHA_MODE PREMULT OVERLAP_ONLY IDLE [ 0]: 0h 0h 3h 3 20 0 0 [ 3]: 0h 3h fh 2 20 0 0 With this series (Steamdeck/Gamescope): == DPP: DGAM ROM DGAM ROM type DGAM LUT SHAPER mode 3DLUT mode 3DLUT bit depth 3DLUT size RGAM mode GAMUT mode C11 C12 C13 C14 C21 C22 C23 C24 C31 C32 C33 C34 [ 0]:1 sRGBBypassRAM A RAM B 12-bit17x17x17 RAM A 0 h h h h h h [ 1]:1 sRGBBypassRAM B RAM A 12-bit17x17x17 RAM A 0 h h h h h h [ 2]:1 sRGBBypassRAM B RAM A 12-bit17x17x17 RAM A 0 h h h h h h [ 3]:1 sRGBBypassRAM A RAM B 12-bit17x17x17 RAM A 0 h h h h h h DPP Color Caps: input_lut_shared:0 icsc:1 dgam_ram:0 dgam_rom: srgb:1,bt2020:1,gamma2_2:1,pq:1,hlg:1 post_csc:1 gamcor:1 dgam_rom_for_yuv:0 3d_lut:1 blnd_lut:1 oscs:0 MPCC: OPP DPP MPCCBOT MODE ALPHA_MODE PREMULT OVERLAP_ONLY IDLE SHAPER mode 3DLUT_mode 3DLUT bit-depth 3DLUT size OGAM mode OGAM LUT GAMUT mode C11 C12 C33 C34 [ 0]: 0h 0h 2h 3 01 0 0 Bypass Bypass 12-bit17x17x17RAM A 0 h h [ 1]: 0h 1h fh 2 20 0 0 Bypass Bypass 12-bit17x17x17 Bypass A 0 h h [ 2]: 0h 2h 3h 3 01 0 0 Bypass Bypass 12-bit17x17x17 Bypass A 0 h h [ 3]: 0h 3h 1h 3 20 0 0 Bypass Bypass 12-bit17x17x17 Bypass A 0 h h MPC Color Caps: gamut_remap:1, 3dlut:2, ogam_ram:1, ocsc:1 With this series (Steamdeck/KDE): DPP: DGAM ROM DGAM ROM type DGAM LUT SHAPER mode 3DLUT mode 3DLUT bit depth 3DLUT size RGAM mode GAMUT mode C11 C12 C13 C14 C21 C22 C23 C24 C31 C32 C33 C34 [ 0]:0 sRGBBypass Bypass Bypass 12-bit 9x9x9 Bypass 0 h h h h h h [ 3]:0 sRGBBypass Bypass Bypass 12-bit 9x9x9 Bypass 0 h h h h h h DPP Color Caps: input_lut_shared:0 icsc:1 dgam_ram:0 dgam_rom: srgb:1,bt2020:1,gamma2_2:1,pq:1,hlg:1 post_csc:1 gamcor:1 dgam_rom_for_yuv:0 3d_lut:1 blnd_lut:1 oscs:0 MPCC: OPP DPP MPCCBOT MODE ALPHA_MODE PREMULT OVERLAP_ONLY IDLE SHAPER mode 3DLUT_mode 3DLUT bit-depth 3DLUT size OGAM mode OGAM LUT
Re: [RFT PATCH 03/15] drm/ingenic: Call drm_atomic_helper_shutdown() at shutdown time
Hi, On Tue, Sep 5, 2023 at 1:16 PM Doug Anderson wrote: > > Paul, > > On Mon, Sep 4, 2023 at 2:15 AM Paul Cercueil wrote: > > > > Hi Douglas, > > > > Le vendredi 01 septembre 2023 à 16:41 -0700, Douglas Anderson a écrit : > > > Based on grepping through the source code this driver appears to be > > > missing a call to drm_atomic_helper_shutdown() at system shutdown > > > time. Among other things, this means that if a panel is in use that > > > it > > > won't be cleanly powered off at system shutdown time. > > > > > > The fact that we should call drm_atomic_helper_shutdown() in the case > > > of OS shutdown/restart comes straight out of the kernel doc "driver > > > instance overview" in drm_drv.c. > > > > > > Since this driver uses the component model and shutdown happens at > > > the > > > base driver, we communicate whether we have to call > > > drm_atomic_helper_shutdown() by seeing if drvdata is non-NULL. > > > > > > Suggested-by: Maxime Ripard > > > Signed-off-by: Douglas Anderson > > > > LGTM. > > Acked-by: Paul Cercueil > > Thanks for the Ack! Would you expect this patch to land through > "drm-misc", or do you expect it to go through some other tree? > Running: > > ./scripts/get_maintainer.pl --scm -f drivers/gpu/drm/ingenic/ingenic-drm-drv.c > > ...does not show that this driver normally goes through drm-misc, but > it also doesn't show that it goes through any other tree so maybe it's > just an artifact of the way it's tagged in the MAINTAINERS file? If > it's fine for this to go through drm-misc, I'll probably land it (with > your Ack and Maxime's Review) sooner rather than later just to make > this patch series less unwieldy. > > > > > --- > > > This commit is only compile-time tested. > > > > > > NOTE: this patch touches a lot more than other similar patches since > > > the bind() function is long and we want to make sure that we unset > > > the > > > drvdata if bind() fails. > > > > > > While making this patch, I noticed that the bind() function of this > > > driver is using "devm" and thus assumes it doesn't need to do much > > > explicit error handling. That's actually a bug. As per kernel docs > > > [1] > > > "the lifetime of the aggregate driver does not align with any of the > > > underlying struct device instances. Therefore devm cannot be used and > > > all resources acquired or allocated in this callback must be > > > explicitly released in the unbind callback". Fixing that is outside > > > the scope of this commit. > > > > > > [1] https://docs.kernel.org/driver-api/component.html > > > > > > > Noted, thanks. > > FWIW, I think that at least a few other DRM drivers handle this by > doing some of their resource allocation / acquiring in the probe() > function and then only doing things in the bind() that absolutely need > to be in the bind. ;-) I've been collecting patches that are ready to land in drm-misc but, right now, I'm not taking this patch since I didn't get any clarification of whether it should land through drm-misc or somewhere else. -Doug
Re: [RFT PATCH 03/15] drm/ingenic: Call drm_atomic_helper_shutdown() at shutdown time
Hi, On Wed, Sep 6, 2023 at 1:39 AM Maxime Ripard wrote: > > On Tue, Sep 05, 2023 at 01:16:08PM -0700, Doug Anderson wrote: > > > > --- > > > > This commit is only compile-time tested. > > > > > > > > NOTE: this patch touches a lot more than other similar patches since > > > > the bind() function is long and we want to make sure that we unset > > > > the > > > > drvdata if bind() fails. > > > > > > > > While making this patch, I noticed that the bind() function of this > > > > driver is using "devm" and thus assumes it doesn't need to do much > > > > explicit error handling. That's actually a bug. As per kernel docs > > > > [1] > > > > "the lifetime of the aggregate driver does not align with any of the > > > > underlying struct device instances. Therefore devm cannot be used and > > > > all resources acquired or allocated in this callback must be > > > > explicitly released in the unbind callback". Fixing that is outside > > > > the scope of this commit. > > > > > > > > [1] https://docs.kernel.org/driver-api/component.html > > > > > > > > > > Noted, thanks. > > > > FWIW, I think that at least a few other DRM drivers handle this by > > doing some of their resource allocation / acquiring in the probe() > > function and then only doing things in the bind() that absolutely need > > to be in the bind. ;-) > > That doesn't change much. The fundamental issue is that the DRM device > sticks around until the last application that has an open fd to it > closes it. > > So it doesn't have any relationship with the unbind/remove timing, and > for all we know it can be there indefinitely, while the application > continues to interact with the driver. I spent some time thinking about similar issues recently and, assuming my understanding is correct, I'd at least partially disagree. Specifically, I _think_ the only thing that's truly required to remain valid until userspace closes the last open "fd" is the memory for the "struct drm_device" itself, right? My understanding is that this is similar to how "struct device" works. The memory backing a "struct device" has to live until the last client releases a reference to it even if everything else about a device has gone away. So if it was all working perfectly then if the Linux driver backing the "struct drm_device" goes away then we'd release resources and NULL out a bunch of stuff in the "struct drm_device" but still keep the actual "struct drm_device" around since userspace still has a reference. Pretty much all userspace calls would fail, but at least they wouldn't crash. Is that roughly the gist? Assuming that's correct, then _most_ of the resource acquiring / memory allocation can still happen in the device probe() routine and can still use devm as long as we do something to ensure that any resources released are no longer pointed to by anything in the "struct drm_device". To make it concrete, I think we want this (feel free to correct). For simplicity, I'm assuming a driver that _doesn't_ use the component framework: a) Linux driver probe() happens. The "struct drm_device" is allocated in probe() by devm_drm_dev_alloc(). This takes a reference to the "struct drm_device". The device also acquires resources / allocates memory. b) Userspace acquires a reference to the "struct drm_device". Refcount is now 2 (one from userspace, one from the Linux driver). c) The Linux driver unbinds, presumably because userspace requested it. From earlier I think we decided that we can't (by design) block unbind. Once unbind happens then we shouldn't try to keep operating the device and the driver should stop running. As part of the unbind, the remove() is called and also "devm" resources are deallocated. If any of the things freed are pointed to by the "struct drm_device" then the code needs to NULL them out at this time. Also we should make sure that any callback functions that userspace could cause to be invoked return errors. Our code could go away at any point here since userspace could "rmmod" our module. d) Eventually userspace releases the reference and the "struct drm_device" memory gets automatically freed because it was allocated by devm_drm_dev_alloc() NOTE: potentially some things could be allocated / managed by drmm_xyz() function, like drmm_kmalloc() and that could simplify some things. However, it's not a panacea for everything. Specifically once the Linux driver unbind finishes then the device isn't functional anymore. -Doug
Re: [PATCH] drm/amd/display: Fix -Wuninitialized in dm_helpers_dp_mst_send_payload_allocation()
On 9/13/23 12:10, Nathan Chancellor wrote:
When building with clang, there is a warning (or error when
CONFIG_WERROR is set):
drivers/gpu/drm/amd/amdgpu/../display/amdgpu_dm/amdgpu_dm_helpers.c:368:21:
error: variable 'old_payload' is uninitialized when used here
[-Werror,-Wuninitialized]
368 | new_payload,
old_payload);
|
^~~
drivers/gpu/drm/amd/amdgpu/../display/amdgpu_dm/amdgpu_dm_helpers.c:344:61:
note: initialize the variable 'old_payload' to silence this warning
344 | struct drm_dp_mst_atomic_payload *new_payload, *old_payload;
|^
|
= NULL
1 error generated.
This variable is not required outside of this function so allocate
old_payload on the stack and pass it by reference to
dm_helpers_construct_old_payload(), resolving the warning.
Closes: https://github.com/ClangBuiltLinux/linux/issues/1931
Fixes: 5aa1dfcdf0a4 ("drm/mst: Refactor the flow for payload
allocation/removement")
Signed-off-by: Nathan Chancellor
Reviewed-by: Hamza Mahfooz
Hm, seems like this was pushed through drm-misc-next and as such our CI
didn't get a chance to test it.
---
drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_helpers.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_helpers.c
b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_helpers.c
index 9ad509279b0a..c4c35f6844f4 100644
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_helpers.c
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_helpers.c
@@ -341,7 +341,7 @@ bool dm_helpers_dp_mst_send_payload_allocation(
struct amdgpu_dm_connector *aconnector;
struct drm_dp_mst_topology_state *mst_state;
struct drm_dp_mst_topology_mgr *mst_mgr;
- struct drm_dp_mst_atomic_payload *new_payload, *old_payload;
+ struct drm_dp_mst_atomic_payload *new_payload, old_payload;
enum mst_progress_status set_flag = MST_ALLOCATE_NEW_PAYLOAD;
enum mst_progress_status clr_flag = MST_CLEAR_ALLOCATED_PAYLOAD;
int ret = 0;
@@ -365,8 +365,8 @@ bool dm_helpers_dp_mst_send_payload_allocation(
ret = drm_dp_add_payload_part2(mst_mgr, mst_state->base.state,
new_payload);
} else {
dm_helpers_construct_old_payload(stream->link,
mst_state->pbn_div,
-new_payload, old_payload);
- drm_dp_remove_payload_part2(mst_mgr, mst_state, old_payload,
new_payload);
+new_payload, _payload);
+ drm_dp_remove_payload_part2(mst_mgr, mst_state, _payload,
new_payload);
}
if (ret) {
---
base-commit: 8569c31545385195bdb0c021124e68336e91c693
change-id:
20230913-fix-wuninitialized-dm_helpers_dp_mst_send_payload_allocation-c37b33aaad18
Best regards,
--
Hamza
[PATCH] drm/amd/display: Fix -Wuninitialized in dm_helpers_dp_mst_send_payload_allocation()
When building with clang, there is a warning (or error when
CONFIG_WERROR is set):
drivers/gpu/drm/amd/amdgpu/../display/amdgpu_dm/amdgpu_dm_helpers.c:368:21:
error: variable 'old_payload' is uninitialized when used here
[-Werror,-Wuninitialized]
368 | new_payload,
old_payload);
|
^~~
drivers/gpu/drm/amd/amdgpu/../display/amdgpu_dm/amdgpu_dm_helpers.c:344:61:
note: initialize the variable 'old_payload' to silence this warning
344 | struct drm_dp_mst_atomic_payload *new_payload, *old_payload;
|^
| =
NULL
1 error generated.
This variable is not required outside of this function so allocate
old_payload on the stack and pass it by reference to
dm_helpers_construct_old_payload(), resolving the warning.
Closes: https://github.com/ClangBuiltLinux/linux/issues/1931
Fixes: 5aa1dfcdf0a4 ("drm/mst: Refactor the flow for payload
allocation/removement")
Signed-off-by: Nathan Chancellor
---
drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_helpers.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_helpers.c
b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_helpers.c
index 9ad509279b0a..c4c35f6844f4 100644
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_helpers.c
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_helpers.c
@@ -341,7 +341,7 @@ bool dm_helpers_dp_mst_send_payload_allocation(
struct amdgpu_dm_connector *aconnector;
struct drm_dp_mst_topology_state *mst_state;
struct drm_dp_mst_topology_mgr *mst_mgr;
- struct drm_dp_mst_atomic_payload *new_payload, *old_payload;
+ struct drm_dp_mst_atomic_payload *new_payload, old_payload;
enum mst_progress_status set_flag = MST_ALLOCATE_NEW_PAYLOAD;
enum mst_progress_status clr_flag = MST_CLEAR_ALLOCATED_PAYLOAD;
int ret = 0;
@@ -365,8 +365,8 @@ bool dm_helpers_dp_mst_send_payload_allocation(
ret = drm_dp_add_payload_part2(mst_mgr, mst_state->base.state,
new_payload);
} else {
dm_helpers_construct_old_payload(stream->link,
mst_state->pbn_div,
-new_payload, old_payload);
- drm_dp_remove_payload_part2(mst_mgr, mst_state, old_payload,
new_payload);
+new_payload, _payload);
+ drm_dp_remove_payload_part2(mst_mgr, mst_state, _payload,
new_payload);
}
if (ret) {
---
base-commit: 8569c31545385195bdb0c021124e68336e91c693
change-id:
20230913-fix-wuninitialized-dm_helpers_dp_mst_send_payload_allocation-c37b33aaad18
Best regards,
--
Nathan Chancellor
Re: [PATCH drm-misc-next v3 6/7] drm/gpuvm: generalize dma_resv/extobj handling and GEM validation
On 9/13/23 17:33, Christian König wrote: Am 13.09.23 um 17:15 schrieb Danilo Krummrich: On 9/13/23 16:26, Christian König wrote: Am 13.09.23 um 14:16 schrieb Danilo Krummrich: As mentioned in a different mail thread, the reply is based on the assumption that we don't support anything else than GPUVM updates from the IOCTL. I think that this assumption is incorrect. Well, more precisely I should have said "don't support GPUVM updated from within fence signaling critical sections". And looking at the code, that doesn't seem what you're doing there. Vulkan is just once specific use case, but this here should probably be able to handle other use cases as well. Especially with HMM you get the requirement that you need to be able to invalidate GPUVM mappings without grabbing a reservation lock. What do you mean with "invalidate GPUVM mappings" in this context? drm_gpuvm_bo_evict() should only be called from a ttm_device_funcs::move callback, we should hold the dma-resv lock there. Well the question is which dma-resv lock do we hold? In the move callback we only hold the dma-resv lock of the BO which is moved, but when that is a shared BO then that's not the same as the one for the VM. Correct, Thomas' idea was to use the GEM's dma_resv lock to protect drm_gpuvm_bo::evicted and then actually move the drm_gpuvm_bo to the VM's evicted list once we grabbed all dma-resv locks when locking the VM's BOs using drm_exec. We can remove them from the evicted list on validate(). This way we never touch the evicted list without holding at least the VM's dma-resv lock. Do you have any concerns about that? See what the eviction lock in amdgpu is doing for example. The eviction_lock seems to protect a VM state "evicting" of whether any BO that is associated with the VM is currently evicting. At the same time amdgpu protects the eviceted list of the VM with a different lock. So this seems to be entirely unrelated. Tracking a "currently evicting" state is not part of the GPUVM implementation currently and hence nothing would change for amdgpu there. Sorry for the confusion we use different terminology in amdgpu. The eviction lock and evicted state is for the VM page tables, e.g. if the whole VM is currently not used and swapped out or even de-allocated. This is necessary because we have cases where we need to access the VM data without holding the dma-resv lock of this VM. Especially figuring out which parts of an address space contain mappings and which doesn't. I think this is fine, this has nothing to do with lists of evicted GEM objects or external GEM objects, right? Marking mappings (drm_gpuva) as invalidated (DRM_GPUVA_INVALIDATED) or accessing the VA space does not require any dma-resv locks. This is a requirement which comes with HMM handling, you won't see this with Vulkan (or OpenGL, VAAPI etc..). The invalidation lock on the other hand is what in this discussion is called eviction lock. This one is needed because what I wrote above, during the move callback only the dma-resv of the BO which is moved is locked, but not necessarily the dma-resv of the VM. That's yet another thing, right? This is used to track whether *any* BO that belongs to the VM is currently being evicted, correct? As mentioned, as by now this is not supported in GPUVM and hence would be the same driver specific code with the same driver specifc lock. Regards, Christian. Regards, Christian. On Wed, Sep 13, 2023 at 11:14:46AM +0200, Thomas Hellström wrote: Hi! On Wed, 2023-09-13 at 01:36 +0200, Danilo Krummrich wrote: On Tue, Sep 12, 2023 at 09:23:08PM +0200, Thomas Hellström wrote: On 9/12/23 18:50, Danilo Krummrich wrote: On Tue, Sep 12, 2023 at 06:20:32PM +0200, Thomas Hellström wrote: Hi, Danilo, On 9/9/23 17:31, Danilo Krummrich wrote: So far the DRM GPUVA manager offers common infrastructure to track GPU VA allocations and mappings, generically connect GPU VA mappings to their backing buffers and perform more complex mapping operations on the GPU VA space. However, there are more design patterns commonly used by drivers, which can potentially be generalized in order to make the DRM GPUVA manager represent a basic GPU-VM implementation. In this context, this patch aims at generalizing the following elements. 1) Provide a common dma-resv for GEM objects not being used outside of this GPU-VM. 2) Provide tracking of external GEM objects (GEM objects which are shared with other GPU-VMs). 3) Provide functions to efficiently lock all GEM objects dma- resv the GPU-VM contains mappings of. 4) Provide tracking of evicted GEM objects the GPU-VM contains mappings of, such that validation of evicted GEM objects is accelerated. 5) Provide some convinience functions for common patterns. Rather than being designed as a "framework", the target is to make all features appear as a collection of optional helper functions, such that drivers are free
Re: [RFT PATCH 01/15] drm/armada: Call drm_atomic_helper_shutdown() at shutdown time
Hi, On Tue, Sep 5, 2023 at 7:23 AM Doug Anderson wrote: > > Hi, > > On Sun, Sep 3, 2023 at 8:53 AM Russell King (Oracle) > wrote: > > > > On Fri, Sep 01, 2023 at 04:41:12PM -0700, Douglas Anderson wrote: > > > Based on grepping through the source code this driver appears to be > > > missing a call to drm_atomic_helper_shutdown() at system shutdown > > > time. Among other things, this means that if a panel is in use that it > > > won't be cleanly powered off at system shutdown time. > > > > > > The fact that we should call drm_atomic_helper_shutdown() in the case > > > of OS shutdown/restart comes straight out of the kernel doc "driver > > > instance overview" in drm_drv.c. > > > > > > This driver was fairly easy to update. The drm_device is stored in the > > > drvdata so we just have to make sure the drvdata is NULL whenever the > > > device is not bound. > > > > ... and there I think you have a misunderstanding of the driver model. > > Please have a look at device_unbind_cleanup() which will be called if > > probe fails, or when the device is removed (in other words, when it is > > not bound to a driver.) > > ...and there I think you didn't read this patch closely enough and > perhaps that you have a misunderstanding of the component model. > Please have a look at the difference between armada_drm_unbind() and > armada_drm_remove() and also check which of those two functions is > being modified by my patch. Were this patch adding a call to > "dev_set_drvdata(dev, NULL)" in armada_drm_remove() then your NAK > would be justified. However, I am not aware of anything in the > component unbind path nor in the failure case of component bind that > would NULL the drvdata. > > Kindly look at the patch a second time with this in mind. Since I didn't see any further response, I'll assume that my explanation here has addressed your concerns. If not, I can re-post it without NULLing the "drvdata". While I still believe this is unsafe in some corner cases because of the component model used by this driver, at least it would get the shutdown call in. In any case, what's the process for landing patches to this driver? Running `./scripts/get_maintainer.pl --scm -f drivers/gpu/drm/armada/armada_drv.c` seems to indicate that this should go through the git tree: git git://git.armlinux.org.uk/~rmk/linux-arm.git drm-armada-devel ...but it doesn't appear that recent changes to this driver have gone that way. Should this land through drm-misc? -Doug
Re: [PATCH drm-misc-next v3 6/7] drm/gpuvm: generalize dma_resv/extobj handling and GEM validation
Am 13.09.23 um 17:15 schrieb Danilo Krummrich: On 9/13/23 16:26, Christian König wrote: Am 13.09.23 um 14:16 schrieb Danilo Krummrich: As mentioned in a different mail thread, the reply is based on the assumption that we don't support anything else than GPUVM updates from the IOCTL. I think that this assumption is incorrect. Well, more precisely I should have said "don't support GPUVM updated from within fence signaling critical sections". And looking at the code, that doesn't seem what you're doing there. Vulkan is just once specific use case, but this here should probably be able to handle other use cases as well. Especially with HMM you get the requirement that you need to be able to invalidate GPUVM mappings without grabbing a reservation lock. What do you mean with "invalidate GPUVM mappings" in this context? drm_gpuvm_bo_evict() should only be called from a ttm_device_funcs::move callback, we should hold the dma-resv lock there. Well the question is which dma-resv lock do we hold? In the move callback we only hold the dma-resv lock of the BO which is moved, but when that is a shared BO then that's not the same as the one for the VM. See what the eviction lock in amdgpu is doing for example. The eviction_lock seems to protect a VM state "evicting" of whether any BO that is associated with the VM is currently evicting. At the same time amdgpu protects the eviceted list of the VM with a different lock. So this seems to be entirely unrelated. Tracking a "currently evicting" state is not part of the GPUVM implementation currently and hence nothing would change for amdgpu there. Sorry for the confusion we use different terminology in amdgpu. The eviction lock and evicted state is for the VM page tables, e.g. if the whole VM is currently not used and swapped out or even de-allocated. This is necessary because we have cases where we need to access the VM data without holding the dma-resv lock of this VM. Especially figuring out which parts of an address space contain mappings and which doesn't. This is a requirement which comes with HMM handling, you won't see this with Vulkan (or OpenGL, VAAPI etc..). The invalidation lock on the other hand is what in this discussion is called eviction lock. This one is needed because what I wrote above, during the move callback only the dma-resv of the BO which is moved is locked, but not necessarily the dma-resv of the VM. Regards, Christian. Regards, Christian. On Wed, Sep 13, 2023 at 11:14:46AM +0200, Thomas Hellström wrote: Hi! On Wed, 2023-09-13 at 01:36 +0200, Danilo Krummrich wrote: On Tue, Sep 12, 2023 at 09:23:08PM +0200, Thomas Hellström wrote: On 9/12/23 18:50, Danilo Krummrich wrote: On Tue, Sep 12, 2023 at 06:20:32PM +0200, Thomas Hellström wrote: Hi, Danilo, On 9/9/23 17:31, Danilo Krummrich wrote: So far the DRM GPUVA manager offers common infrastructure to track GPU VA allocations and mappings, generically connect GPU VA mappings to their backing buffers and perform more complex mapping operations on the GPU VA space. However, there are more design patterns commonly used by drivers, which can potentially be generalized in order to make the DRM GPUVA manager represent a basic GPU-VM implementation. In this context, this patch aims at generalizing the following elements. 1) Provide a common dma-resv for GEM objects not being used outside of this GPU-VM. 2) Provide tracking of external GEM objects (GEM objects which are shared with other GPU-VMs). 3) Provide functions to efficiently lock all GEM objects dma- resv the GPU-VM contains mappings of. 4) Provide tracking of evicted GEM objects the GPU-VM contains mappings of, such that validation of evicted GEM objects is accelerated. 5) Provide some convinience functions for common patterns. Rather than being designed as a "framework", the target is to make all features appear as a collection of optional helper functions, such that drivers are free to make use of the DRM GPUVA managers basic functionality and opt-in for other features without setting any feature flags, just by making use of the corresponding functions. Big kudos to Boris Brezillon for his help to figure out locking for drivers updating the GPU VA space within the fence signalling path. Suggested-by: Matthew Brost Signed-off-by: Danilo Krummrich --- drivers/gpu/drm/drm_gpuvm.c | 516 include/drm/drm_gpuvm.h | 197 ++ 2 files changed, 713 insertions(+) diff --git a/drivers/gpu/drm/drm_gpuvm.c b/drivers/gpu/drm/drm_gpuvm.c index f4411047dbb3..8e62a043f719 100644 --- a/drivers/gpu/drm/drm_gpuvm.c +++ b/drivers/gpu/drm/drm_gpuvm.c @@ -73,6 +73,21 @@ * _gem_object list of _gpuvm_bos for an existing instance of this * particular combination. If not existent a new instance is created and linked * to the _gem_object. + * + * _gpuvm_bo structures, since unique for a
Re: [PATCH drm-misc-next v3 6/7] drm/gpuvm: generalize dma_resv/extobj handling and GEM validation
Am 13.09.23 um 17:13 schrieb Thomas Hellström: Hi Christian On 9/13/23 16:26, Christian König wrote: Am 13.09.23 um 14:16 schrieb Danilo Krummrich: As mentioned in a different mail thread, the reply is based on the assumption that we don't support anything else than GPUVM updates from the IOCTL. I think that this assumption is incorrect. Vulkan is just once specific use case, but this here should probably be able to handle other use cases as well. Especially with HMM you get the requirement that you need to be able to invalidate GPUVM mappings without grabbing a reservation lock. Are you referring to the MMU range invalidation notifiers here? Yes, but you need to ping Felix and Philip for the details. See what the eviction lock in amdgpu is doing for example. IMO the statement regarding GPUVM updates from the IOCTL mostly refers to the need to protect the evicted- and extobj lists with additional spinlocks. Supporting userptr and faulting will ofc require additional locks / locking mechanisms. But this code doesn't do that yet. Is your concern that these particular spinlocks for these lists are indeed needed? More or less yes. My main concern is that both Dave and Danilo mentioned that they work with the assumption that they only need to handle Vulkan/IOCTL based use cases. Regards, Christian. /Thomas Regards, Christian. On Wed, Sep 13, 2023 at 11:14:46AM +0200, Thomas Hellström wrote: Hi! On Wed, 2023-09-13 at 01:36 +0200, Danilo Krummrich wrote: On Tue, Sep 12, 2023 at 09:23:08PM +0200, Thomas Hellström wrote: On 9/12/23 18:50, Danilo Krummrich wrote: On Tue, Sep 12, 2023 at 06:20:32PM +0200, Thomas Hellström wrote: Hi, Danilo, On 9/9/23 17:31, Danilo Krummrich wrote: So far the DRM GPUVA manager offers common infrastructure to track GPU VA allocations and mappings, generically connect GPU VA mappings to their backing buffers and perform more complex mapping operations on the GPU VA space. However, there are more design patterns commonly used by drivers, which can potentially be generalized in order to make the DRM GPUVA manager represent a basic GPU-VM implementation. In this context, this patch aims at generalizing the following elements. 1) Provide a common dma-resv for GEM objects not being used outside of this GPU-VM. 2) Provide tracking of external GEM objects (GEM objects which are shared with other GPU-VMs). 3) Provide functions to efficiently lock all GEM objects dma- resv the GPU-VM contains mappings of. 4) Provide tracking of evicted GEM objects the GPU-VM contains mappings of, such that validation of evicted GEM objects is accelerated. 5) Provide some convinience functions for common patterns. Rather than being designed as a "framework", the target is to make all features appear as a collection of optional helper functions, such that drivers are free to make use of the DRM GPUVA managers basic functionality and opt-in for other features without setting any feature flags, just by making use of the corresponding functions. Big kudos to Boris Brezillon for his help to figure out locking for drivers updating the GPU VA space within the fence signalling path. Suggested-by: Matthew Brost Signed-off-by: Danilo Krummrich --- drivers/gpu/drm/drm_gpuvm.c | 516 include/drm/drm_gpuvm.h | 197 ++ 2 files changed, 713 insertions(+) diff --git a/drivers/gpu/drm/drm_gpuvm.c b/drivers/gpu/drm/drm_gpuvm.c index f4411047dbb3..8e62a043f719 100644 --- a/drivers/gpu/drm/drm_gpuvm.c +++ b/drivers/gpu/drm/drm_gpuvm.c @@ -73,6 +73,21 @@ * _gem_object list of _gpuvm_bos for an existing instance of this * particular combination. If not existent a new instance is created and linked * to the _gem_object. + * + * _gpuvm_bo structures, since unique for a given _gpuvm, are also used + * as entry for the _gpuvm's lists of external and evicted objects. Those + * list are maintained in order to accelerate locking of dma-resv locks and + * validation of evicted objects bound in a _gpuvm. For instance the all + * _gem_object's _resv of a given _gpuvm can be locked by calling + * drm_gpuvm_exec_lock(). Once locked drivers can call drm_gpuvm_validate() in + * order to validate all evicted _gem_objects. It is also possible to lock + * additional _gem_objects by providing the corresponding parameters to + * drm_gpuvm_exec_lock() as well as open code the _exec loop while making + * use of helper functions such as drm_gpuvm_prepare_range() or + * drm_gpuvm_prepare_objects(). + * + * Every bound _gem_object is treated as external object when its _resv + * structure is different than the _gpuvm's common _resv structure. */ /** @@ -420,6 +435,20 @@ * Subsequent calls to drm_gpuvm_bo_obtain() for the same _gpuvm and * _gem_object must be able to observe previous creations and destructions * of _gpuvm_bos in order to keep instances unique. + * + *
Re: [PATCH drm-misc-next v3 6/7] drm/gpuvm: generalize dma_resv/extobj handling and GEM validation
Hi Christian On 9/13/23 16:26, Christian König wrote: Am 13.09.23 um 14:16 schrieb Danilo Krummrich: As mentioned in a different mail thread, the reply is based on the assumption that we don't support anything else than GPUVM updates from the IOCTL. I think that this assumption is incorrect. Vulkan is just once specific use case, but this here should probably be able to handle other use cases as well. Especially with HMM you get the requirement that you need to be able to invalidate GPUVM mappings without grabbing a reservation lock. Are you referring to the MMU range invalidation notifiers here? See what the eviction lock in amdgpu is doing for example. IMO the statement regarding GPUVM updates from the IOCTL mostly refers to the need to protect the evicted- and extobj lists with additional spinlocks. Supporting userptr and faulting will ofc require additional locks / locking mechanisms. But this code doesn't do that yet. Is your concern that these particular spinlocks for these lists are indeed needed? /Thomas Regards, Christian. On Wed, Sep 13, 2023 at 11:14:46AM +0200, Thomas Hellström wrote: Hi! On Wed, 2023-09-13 at 01:36 +0200, Danilo Krummrich wrote: On Tue, Sep 12, 2023 at 09:23:08PM +0200, Thomas Hellström wrote: On 9/12/23 18:50, Danilo Krummrich wrote: On Tue, Sep 12, 2023 at 06:20:32PM +0200, Thomas Hellström wrote: Hi, Danilo, On 9/9/23 17:31, Danilo Krummrich wrote: So far the DRM GPUVA manager offers common infrastructure to track GPU VA allocations and mappings, generically connect GPU VA mappings to their backing buffers and perform more complex mapping operations on the GPU VA space. However, there are more design patterns commonly used by drivers, which can potentially be generalized in order to make the DRM GPUVA manager represent a basic GPU-VM implementation. In this context, this patch aims at generalizing the following elements. 1) Provide a common dma-resv for GEM objects not being used outside of this GPU-VM. 2) Provide tracking of external GEM objects (GEM objects which are shared with other GPU-VMs). 3) Provide functions to efficiently lock all GEM objects dma- resv the GPU-VM contains mappings of. 4) Provide tracking of evicted GEM objects the GPU-VM contains mappings of, such that validation of evicted GEM objects is accelerated. 5) Provide some convinience functions for common patterns. Rather than being designed as a "framework", the target is to make all features appear as a collection of optional helper functions, such that drivers are free to make use of the DRM GPUVA managers basic functionality and opt-in for other features without setting any feature flags, just by making use of the corresponding functions. Big kudos to Boris Brezillon for his help to figure out locking for drivers updating the GPU VA space within the fence signalling path. Suggested-by: Matthew Brost Signed-off-by: Danilo Krummrich --- drivers/gpu/drm/drm_gpuvm.c | 516 include/drm/drm_gpuvm.h | 197 ++ 2 files changed, 713 insertions(+) diff --git a/drivers/gpu/drm/drm_gpuvm.c b/drivers/gpu/drm/drm_gpuvm.c index f4411047dbb3..8e62a043f719 100644 --- a/drivers/gpu/drm/drm_gpuvm.c +++ b/drivers/gpu/drm/drm_gpuvm.c @@ -73,6 +73,21 @@ * _gem_object list of _gpuvm_bos for an existing instance of this * particular combination. If not existent a new instance is created and linked * to the _gem_object. + * + * _gpuvm_bo structures, since unique for a given _gpuvm, are also used + * as entry for the _gpuvm's lists of external and evicted objects. Those + * list are maintained in order to accelerate locking of dma-resv locks and + * validation of evicted objects bound in a _gpuvm. For instance the all + * _gem_object's _resv of a given _gpuvm can be locked by calling + * drm_gpuvm_exec_lock(). Once locked drivers can call drm_gpuvm_validate() in + * order to validate all evicted _gem_objects. It is also possible to lock + * additional _gem_objects by providing the corresponding parameters to + * drm_gpuvm_exec_lock() as well as open code the _exec loop while making + * use of helper functions such as drm_gpuvm_prepare_range() or + * drm_gpuvm_prepare_objects(). + * + * Every bound _gem_object is treated as external object when its _resv + * structure is different than the _gpuvm's common _resv structure. */ /** @@ -420,6 +435,20 @@ * Subsequent calls to drm_gpuvm_bo_obtain() for the same _gpuvm and * _gem_object must be able to observe previous creations and destructions * of _gpuvm_bos in order to keep instances unique. + * + * The _gpuvm's lists for keeping track of external and evicted objects are + * protected against concurrent insertion / removal and iteration internally. + * + * However, drivers still need ensure to protect concurrent calls to functions + * iterating those lists, such as drm_gpuvm_validate() and + *
Re: [PATCH drm-misc-next v3 6/7] drm/gpuvm: generalize dma_resv/extobj handling and GEM validation
On Wed, 13 Sep 2023 16:29:30 +0200 Thomas Hellström wrote: > On 9/13/23 16:01, Boris Brezillon wrote: > > On Wed, 13 Sep 2023 15:22:56 +0200 > > Thomas Hellström wrote: > > > >> On 9/13/23 13:33, Boris Brezillon wrote: > >>> On Wed, 13 Sep 2023 12:39:01 +0200 > >>> Thomas Hellström wrote: > >>> > Hi, > > On 9/13/23 09:19, Boris Brezillon wrote: > > On Wed, 13 Sep 2023 17:05:42 +1000 > > Dave Airlie wrote: > > > >> On Wed, 13 Sept 2023 at 17:03, Boris Brezillon > >> wrote: > >>> On Tue, 12 Sep 2023 18:20:32 +0200 > >>> Thomas Hellström wrote: > >>> > > +/** > > + * get_next_vm_bo_from_list() - get the next vm_bo element > > + * @__gpuvm: The GPU VM > > + * @__list_name: The name of the list we're iterating on > > + * @__local_list: A pointer to the local list used to store > > already iterated items > > + * @__prev_vm_bo: The previous element we got from > > drm_gpuvm_get_next_cached_vm_bo() > > + * > > + * This helper is here to provide lockless list iteration. > > Lockless as in, the > > + * iterator releases the lock immediately after picking the first > > element from > > + * the list, so list insertion deletion can happen concurrently. > Are the list spinlocks needed for that async state update from within > the dma-fence critical section we've discussed previously? > >>> Any driver calling _[un]link() from its drm_gpu_scheduler::run_job() > >>> hook will be in this situation (Panthor at the moment, PowerVR soon). > >>> I > >>> get that Xe and Nouveau don't need that because they update the VM > >>> state early (in the ioctl path), but I keep thinking this will hurt us > >>> if we don't think it through from the beginning, because once you've > >>> set this logic to depend only on resv locks, it will be pretty hard to > >>> get back to a solution which lets synchronous VM_BINDs take precedence > >>> on asynchronous request, and, with vkQueueBindSparse() passing > >>> external > >>> deps (plus the fact the VM_BIND queue might be pretty deep), it can > >>> take a long time to get your synchronous VM_BIND executed... > So this would boil down to either (possibly opt-in) keeping the spinlock > approach or pushing the unlink out to a wq then? > >>> Deferred _unlink() would not be an issue, since I already defer the > >>> drm_gpuva destruction to a wq, it would just a be a matter of moving the > >>> _unlink() call there as well. But _link() also takes the GEM gpuva list > >>> lock, and that one is bit tricky, in that sm_map() can trigger 2 more > >>> _link() calls for the prev/next mappings, which we can't guess until we > >>> get to execute the VM update. If we mandate the use of the GEM resv > >>> lock, that simply means async VM updates (AKA calling > >>> drm_gpuvm_sm_[un]map()) are not an option. And if this is what everyone > >>> agrees on, then I'd like the APIs that make this sort of async VM > >>> update possible (drm_gpuvm_sm_[un]map(), the drm_gpuvm_ops::sm_step* > >>> methods, and probably other things) to be dropped, so we don't make it > >>> look like it's something we support. > >>> > BTW, as also asked in a reply to Danilo, how do you call unlink from > run_job() when it was requiring the obj->dma_resv lock, or was that a > WIP? > >>> _unlink() makes sure the GEM gpuva list lock is taken, but this can be > >>> a custom lock (see drm_gem_gpuva_set_lock()). In panthor we have > >>> panthor_gem_object::gpuva_list_lock that's dedicated the gpuva list > >>> protection. We make sure we never take this lock while allocating > >>> memory to guarantee the dma-signalling path can't deadlock. > >>> > >>> > >> btw what is the use case for this? do we have actual vulkan > >> applications we know will have problems here? > > I don't, but I think that's a concern Faith raised at some point (dates > > back from when I was reading threads describing how VM_BIND on i915 > > should work, and I was clearly discovering this whole VM_BIND thing at > > that time, so maybe I misunderstood). > > > >> it feels like a bit of premature optimisation, but maybe we have use > >> cases. > > Might be, but that's the sort of thing that would put us in a corner if > > we don't have a plan for when the needs arise. Besides, if we don't > > want to support that case because it's too complicated, I'd recommend > > dropping all the drm_gpuvm APIs that let people think this mode is > > valid/supported (map/remap/unmap hooks in drm_gpuvm_ops, > > drm_gpuvm_sm_[un]map helpers, etc). Keeping them around just adds to the > > confusion. > Xe allows bypassing the bind-queue with another bind-queue, but to > completely avoid
Re: [PATCH drm-misc-next v3 6/7] drm/gpuvm: generalize dma_resv/extobj handling and GEM validation
On 9/13/23 16:26, Christian König wrote: Am 13.09.23 um 14:16 schrieb Danilo Krummrich: As mentioned in a different mail thread, the reply is based on the assumption that we don't support anything else than GPUVM updates from the IOCTL. I think that this assumption is incorrect. Well, more precisely I should have said "don't support GPUVM updated from within fence signaling critical sections". And looking at the code, that doesn't seem what you're doing there. Vulkan is just once specific use case, but this here should probably be able to handle other use cases as well. Especially with HMM you get the requirement that you need to be able to invalidate GPUVM mappings without grabbing a reservation lock. What do you mean with "invalidate GPUVM mappings" in this context? drm_gpuvm_bo_evict() should only be called from a ttm_device_funcs::move callback, we should hold the dma-resv lock there. See what the eviction lock in amdgpu is doing for example. The eviction_lock seems to protect a VM state "evicting" of whether any BO that is associated with the VM is currently evicting. At the same time amdgpu protects the eviceted list of the VM with a different lock. So this seems to be entirely unrelated. Tracking a "currently evicting" state is not part of the GPUVM implementation currently and hence nothing would change for amdgpu there. Regards, Christian. On Wed, Sep 13, 2023 at 11:14:46AM +0200, Thomas Hellström wrote: Hi! On Wed, 2023-09-13 at 01:36 +0200, Danilo Krummrich wrote: On Tue, Sep 12, 2023 at 09:23:08PM +0200, Thomas Hellström wrote: On 9/12/23 18:50, Danilo Krummrich wrote: On Tue, Sep 12, 2023 at 06:20:32PM +0200, Thomas Hellström wrote: Hi, Danilo, On 9/9/23 17:31, Danilo Krummrich wrote: So far the DRM GPUVA manager offers common infrastructure to track GPU VA allocations and mappings, generically connect GPU VA mappings to their backing buffers and perform more complex mapping operations on the GPU VA space. However, there are more design patterns commonly used by drivers, which can potentially be generalized in order to make the DRM GPUVA manager represent a basic GPU-VM implementation. In this context, this patch aims at generalizing the following elements. 1) Provide a common dma-resv for GEM objects not being used outside of this GPU-VM. 2) Provide tracking of external GEM objects (GEM objects which are shared with other GPU-VMs). 3) Provide functions to efficiently lock all GEM objects dma- resv the GPU-VM contains mappings of. 4) Provide tracking of evicted GEM objects the GPU-VM contains mappings of, such that validation of evicted GEM objects is accelerated. 5) Provide some convinience functions for common patterns. Rather than being designed as a "framework", the target is to make all features appear as a collection of optional helper functions, such that drivers are free to make use of the DRM GPUVA managers basic functionality and opt-in for other features without setting any feature flags, just by making use of the corresponding functions. Big kudos to Boris Brezillon for his help to figure out locking for drivers updating the GPU VA space within the fence signalling path. Suggested-by: Matthew Brost Signed-off-by: Danilo Krummrich --- drivers/gpu/drm/drm_gpuvm.c | 516 include/drm/drm_gpuvm.h | 197 ++ 2 files changed, 713 insertions(+) diff --git a/drivers/gpu/drm/drm_gpuvm.c b/drivers/gpu/drm/drm_gpuvm.c index f4411047dbb3..8e62a043f719 100644 --- a/drivers/gpu/drm/drm_gpuvm.c +++ b/drivers/gpu/drm/drm_gpuvm.c @@ -73,6 +73,21 @@ * _gem_object list of _gpuvm_bos for an existing instance of this * particular combination. If not existent a new instance is created and linked * to the _gem_object. + * + * _gpuvm_bo structures, since unique for a given _gpuvm, are also used + * as entry for the _gpuvm's lists of external and evicted objects. Those + * list are maintained in order to accelerate locking of dma-resv locks and + * validation of evicted objects bound in a _gpuvm. For instance the all + * _gem_object's _resv of a given _gpuvm can be locked by calling + * drm_gpuvm_exec_lock(). Once locked drivers can call drm_gpuvm_validate() in + * order to validate all evicted _gem_objects. It is also possible to lock + * additional _gem_objects by providing the corresponding parameters to + * drm_gpuvm_exec_lock() as well as open code the _exec loop while making + * use of helper functions such as drm_gpuvm_prepare_range() or + * drm_gpuvm_prepare_objects(). + * + * Every bound _gem_object is treated as external object when its _resv + * structure is different than the _gpuvm's common _resv structure. */ /** @@ -420,6 +435,20 @@ * Subsequent calls to drm_gpuvm_bo_obtain() for the same _gpuvm and * _gem_object must be able to observe previous creations and destructions * of _gpuvm_bos in order to keep instances
drm/vkms: deadlock between dev->event_lock and timer
Hello. A deadlock was reported in drivers/gpu/drm/vkms/ .
It looks like this locking pattern remains as of 6.6-rc1. Please fix.
void drm_crtc_vblank_off(struct drm_crtc *crtc) {
spin_lock_irq(>event_lock);
drm_vblank_disable_and_save(dev, pipe) {
__disable_vblank(dev, pipe) {
crtc->funcs->disable_vblank(crtc) == vkms_disable_vblank {
hrtimer_cancel(>vblank_hrtimer) { // Retries with dev->event_lock
held until lock_hrtimer_base() succeeds.
ret = hrtimer_try_to_cancel(timer) {
base = lock_hrtimer_base(timer, ); // Fails forever because
vkms_vblank_simulate() is in progress.
}
}
}
}
}
spin_unlock_irq(>event_lock);
}
static void __run_hrtimer(...) {
restart = fn(timer) == vkms_vblank_simulate {
drm_crtc_handle_vblank(crtc) {
drm_handle_vblank(struct drm_device *dev, unsigned int pipe) {
spin_lock_irqsave(>event_lock, irqflags); // Trying to hold
dev->event_lock inside timer interrupt handler. => Deadlock was reported as a
soft lockup.
spin_unlock_irqrestore(>event_lock, irqflags);
}
}
}
}
On 2023/09/13 20:07, Hillf Danton wrote:
> On Tue, 12 Sep 2023 23:02:56 + Sanan Hasanov
>> Good day, dear maintainers,
>>
>> We found a bug using a modified kernel configuration file used by syzbot.
>>
> Thanks for your report.
>
>> We enhanced the coverage of the configuration file using our tool,
>> klocalizer.
>>
>> Kernel Branch: 6.3.0-next-20230426
>> Kernel Config:
>> https://drive.google.com/file/d/1WSUEWrith9-539qo6xRqmwy4LfDtmKpp/view?usp=sharing
>> Reproducer:
>> https://drive.google.com/file/d/1pN6FfcjuUs6Wx94g1gufuYGjRbMMgiZ4/view?usp=sharing
>> Thank you!
>>
>> Best regards,
>> Sanan Hasanov
>>
>> watchdog: BUG: soft lockup - CPU#5 stuck for 26s! [kworker/u16:1:12]
>> Modules linked in:
>> irq event stamp: 192794
>> hardirqs last enabled at (192793): []
>> asm_sysvec_apic_timer_interrupt+0x1a/0x20 arch/x86/include/asm/idtentry.h:645
>> hardirqs last disabled at (192794): []
>> sysvec_apic_timer_interrupt+0xf/0xc0 arch/x86/kernel/apic/apic.c:1106
>> softirqs last enabled at (187764): [] invoke_softirq
>> kernel/softirq.c:445 [inline]
>> softirqs last enabled at (187764): []
>> __irq_exit_rcu+0x11d/0x190 kernel/softirq.c:650
>> softirqs last disabled at (187671): [] invoke_softirq
>> kernel/softirq.c:445 [inline]
>> softirqs last disabled at (187671): []
>> __irq_exit_rcu+0x11d/0x190 kernel/softirq.c:650
>> CPU: 5 PID: 12 Comm: kworker/u16:1 Not tainted 6.3.0-next-20230426 #1
>> Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.15.0-1
>> 04/01/2014
>> Workqueue: events_unbound toggle_allocation_gate
>> RIP: 0010:csd_lock_wait kernel/smp.c:294 [inline]
>> RIP: 0010:smp_call_function_many_cond+0x5bd/0x1020 kernel/smp.c:828
>> Code: 0b 00 85 ed 74 4d 48 b8 00 00 00 00 00 fc ff df 4d 89 f4 4c 89 f5 49
>> c1 ec 03 83 e5 07 49 01 c4 83 c5 03 e8 b5 07 0b 00 f3 90 <41> 0f b6 04 24 40
>> 38 c5 7c 08 84 c0 0f 85 46 08 00 00 8b 43 08 31
>> RSP: 0018:c90cf9e8 EFLAGS: 0293
>> RAX: RBX: 888119cc4d80 RCX:
>> RDX: 888100325940 RSI: 8176807b RDI: 0005
>> RBP: 0003 R08: 0005 R09:
>> R10: 0001 R11: 0001 R12: ed10233989b1
>> R13: 0001 R14: 888119cc4d88 R15: 0001
>> FS: () GS:888119e8() knlGS:
>> CS: 0010 DS: ES: CR0: 80050033
>> CR2: 56a6cc88 CR3: 0bb73000 CR4: 00350ee0
>> Call Trace:
>>
>> on_each_cpu_cond_mask+0x40/0x90 kernel/smp.c:996
>> on_each_cpu include/linux/smp.h:71 [inline]
>> text_poke_sync arch/x86/kernel/alternative.c:1770 [inline]
>> text_poke_bp_batch+0x237/0x770 arch/x86/kernel/alternative.c:1970
>> text_poke_flush arch/x86/kernel/alternative.c:2161 [inline]
>> text_poke_flush arch/x86/kernel/alternative.c:2158 [inline]
>> text_poke_finish+0x1a/0x30 arch/x86/kernel/alternative.c:2168
>> arch_jump_label_transform_apply+0x17/0x30 arch/x86/kernel/jump_label.c:146
>> jump_label_update+0x321/0x400 kernel/jump_label.c:829
>> static_key_enable_cpuslocked+0x1b5/0x270 kernel/jump_label.c:205
>> static_key_enable+0x1a/0x20 kernel/jump_label.c:218
>> toggle_allocation_gate mm/kfence/core.c:831 [inline]
>> toggle_allocation_gate+0xf4/0x220 mm/kfence/core.c:823
>> process_one_work+0x993/0x15e0 kernel/workqueue.c:2405
>> worker_thread+0x67d/0x10c0 kernel/workqueue.c:2552
>> kthread+0x33e/0x440 kernel/kthread.c:379
>> ret_from_fork+0x1f/0x30 arch/x86/entry/entry_64.S:308
>>
>> Sending NMI from CPU 5 to CPUs 0-4,6-7:
>> NMI backtrace for cpu 1
>> CPU: 1 PID: 20602 Comm: syz-executor.3 Not tainted 6.3.0-next-20230426 #1
>> Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.15.0-1
>> 04/01/2014
>> RIP: 0010:hlock_class kernel/locking/lockdep.c:228 [inline]
>> RIP: 0010:check_wait_context
Re: [PATCH v3 12/13] drm/sched/doc: Add Entity teardown documentaion
Am 12.09.23 um 04:16 schrieb Matthew Brost: Provide documentation to guide in ways to teardown an entity. Signed-off-by: Matthew Brost --- Documentation/gpu/drm-mm.rst | 6 ++ drivers/gpu/drm/scheduler/sched_entity.c | 19 +++ 2 files changed, 25 insertions(+) diff --git a/Documentation/gpu/drm-mm.rst b/Documentation/gpu/drm-mm.rst index c19b34b1c0ed..cb4d6097897e 100644 --- a/Documentation/gpu/drm-mm.rst +++ b/Documentation/gpu/drm-mm.rst @@ -552,6 +552,12 @@ Overview .. kernel-doc:: drivers/gpu/drm/scheduler/sched_main.c :doc: Overview +Entity teardown +--- + +.. kernel-doc:: drivers/gpu/drm/scheduler/sched_entity.c + :doc: Entity teardown + Scheduler Function References - diff --git a/drivers/gpu/drm/scheduler/sched_entity.c b/drivers/gpu/drm/scheduler/sched_entity.c index 37557fbb96d0..76f3e10218bb 100644 --- a/drivers/gpu/drm/scheduler/sched_entity.c +++ b/drivers/gpu/drm/scheduler/sched_entity.c @@ -21,6 +21,25 @@ * */ +/** + * DOC: Entity teardown + * + * Drivers can teardown down an entity for several reasons. Reasons typically + * are a user closes the entity via an IOCTL, the FD associated with the entity + * is closed, or the entity encounters an error. The GPU scheduler provides the + * basic infrastructure to do this in a few different ways. + * + * 1. Let the entity run dry (both the pending list and job queue) and then call + * drm_sched_entity_fini. The backend can accelerate the process of running dry. + * For example set a flag so run_job is a NOP and set the TDR to a low value to + * signal all jobs in a timely manner (this example works for + * DRM_SCHED_POLICY_SINGLE_ENTITY). Please note that it is a requirement from the X server that all externally visible effects of command submission must still be visible even after the fd is closed. This has given us tons amount of headache and is one of the reasons we have the drm_sched_entity_flush() handling in the first place. As long as you don't care about X server compatibility that shouldn't matter to you. Regards, Christian. + * + * 2. Kill the entity directly via drm_sched_entity_flush / + * drm_sched_entity_fini ensuring all pending and queued jobs are off the + * hardware and signaled. + */ + #include #include #include
[PATCH v2 4/4] drm/i915: Implement fbdev emulation as in-kernel client
Replace all code that initializes or releases fbdev emulation
throughout the driver. Instead initialize the fbdev client by a
single call to i915_fbdev_setup() after i915 has registered its
DRM device. Just like similar code in other drivers, i915 fbdev
emulation now acts as a regular DRM client.
The fbdev client setup consists of the initial preparation and the
hot-plugging of the display. The latter creates the fbdev device
and sets up the fbdev framebuffer. The setup performs display
hot-plugging once. If no display can be detected, DRM probe helpers
re-run the detection on each hotplug event.
A call to drm_dev_unregister() releases the client automatically.
No further action is required within i915. If the fbdev framebuffer
has been fully set up, struct fb_ops.fb_destroy implements the
release. For partially initialized emulation, the fbdev client
reverts the initial setup.
v2:
* let drm_client_register() handle initial hotplug
* fix driver name in error message (Jani)
* fix non-fbdev build (kernel test robot)
Signed-off-by: Thomas Zimmermann
---
drivers/gpu/drm/i915/display/intel_display.c | 1 -
.../drm/i915/display/intel_display_driver.c | 18 --
drivers/gpu/drm/i915/display/intel_fbdev.c| 182 --
drivers/gpu/drm/i915/display/intel_fbdev.h| 20 +-
drivers/gpu/drm/i915/i915_driver.c| 2 +
5 files changed, 84 insertions(+), 139 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_display.c
b/drivers/gpu/drm/i915/display/intel_display.c
index 83e1bc858b9fb..64578f991f41d 100644
--- a/drivers/gpu/drm/i915/display/intel_display.c
+++ b/drivers/gpu/drm/i915/display/intel_display.c
@@ -81,7 +81,6 @@
#include "intel_dvo.h"
#include "intel_fb.h"
#include "intel_fbc.h"
-#include "intel_fbdev.h"
#include "intel_fdi.h"
#include "intel_fifo_underrun.h"
#include "intel_frontbuffer.h"
diff --git a/drivers/gpu/drm/i915/display/intel_display_driver.c
b/drivers/gpu/drm/i915/display/intel_display_driver.c
index 0650c0ed30a0c..7f0d6dbc47cae 100644
--- a/drivers/gpu/drm/i915/display/intel_display_driver.c
+++ b/drivers/gpu/drm/i915/display/intel_display_driver.c
@@ -364,10 +364,6 @@ int intel_display_driver_probe(struct drm_i915_private
*i915)
intel_overlay_setup(i915);
- ret = intel_fbdev_init(>drm);
- if (ret)
- return ret;
-
/* Only enable hotplug handling once the fbdev is fully set up. */
intel_hpd_init(i915);
intel_hpd_poll_disable(i915);
@@ -390,16 +386,6 @@ void intel_display_driver_register(struct drm_i915_private
*i915)
intel_display_debugfs_register(i915);
- /*
-* Some ports require correctly set-up hpd registers for
-* detection to work properly (leading to ghost connected
-* connector status), e.g. VGA on gm45. Hence we can only set
-* up the initial fbdev config after hpd irqs are fully
-* enabled. We do it last so that the async config cannot run
-* before the connectors are registered.
-*/
- intel_fbdev_initial_config_async(i915);
-
/*
* We need to coordinate the hotplugs with the asynchronous
* fbdev configuration, for which we use the
@@ -440,9 +426,6 @@ void intel_display_driver_remove_noirq(struct
drm_i915_private *i915)
*/
intel_hpd_poll_fini(i915);
- /* poll work can call into fbdev, hence clean that up afterwards */
- intel_fbdev_fini(i915);
-
intel_unregister_dsm_handler();
/* flush any delayed tasks or pending work */
@@ -479,7 +462,6 @@ void intel_display_driver_unregister(struct
drm_i915_private *i915)
if (!HAS_DISPLAY(i915))
return;
- intel_fbdev_unregister(i915);
intel_audio_deinit(i915);
/*
diff --git a/drivers/gpu/drm/i915/display/intel_fbdev.c
b/drivers/gpu/drm/i915/display/intel_fbdev.c
index 31e8275a70fea..8a13909d3f0b2 100644
--- a/drivers/gpu/drm/i915/display/intel_fbdev.c
+++ b/drivers/gpu/drm/i915/display/intel_fbdev.c
@@ -24,7 +24,6 @@
* David Airlie
*/
-#include
#include
#include
#include
@@ -39,6 +38,7 @@
#include
#include
+#include
#include
#include
#include
@@ -58,7 +58,6 @@ struct intel_fbdev {
struct intel_framebuffer *fb;
struct i915_vma *vma;
unsigned long vma_flags;
- async_cookie_t cookie;
int preferred_bpp;
/* Whether or not fbdev hpd processing is temporarily suspended */
@@ -135,6 +134,26 @@ static int intel_fbdev_mmap(struct fb_info *info, struct
vm_area_struct *vma)
return i915_gem_fb_mmap(obj, vma);
}
+static void intel_fbdev_fb_destroy(struct fb_info *info)
+{
+ struct drm_fb_helper *fb_helper = info->par;
+ struct intel_fbdev *ifbdev = container_of(fb_helper, struct
intel_fbdev, helper);
+
+ drm_fb_helper_fini(>helper);
+
+ /*
+* We rely on the object-free to release the VMA pinning
[PATCH v2 3/4] drm/i915: Implement fbdev client callbacks
Move code from ad-hoc fbdev callbacks into DRM client functions
and remove the old callbacks. The functions instruct the client
to poll for changed output or restore the display.
The DRM core calls both, the old callbacks and the new client
helpers, from the same places. The new functions perform the same
operation as before, so there's no change in functionality.
Signed-off-by: Thomas Zimmermann
---
.../drm/i915/display/intel_display_driver.c | 1 -
drivers/gpu/drm/i915/display/intel_fbdev.c| 11 --
drivers/gpu/drm/i915/display/intel_fbdev.h| 9
drivers/gpu/drm/i915/i915_driver.c| 22 ---
4 files changed, 9 insertions(+), 34 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_display_driver.c
b/drivers/gpu/drm/i915/display/intel_display_driver.c
index 9d9b034b9bdc7..0650c0ed30a0c 100644
--- a/drivers/gpu/drm/i915/display/intel_display_driver.c
+++ b/drivers/gpu/drm/i915/display/intel_display_driver.c
@@ -96,7 +96,6 @@ void intel_display_driver_init_hw(struct drm_i915_private
*i915)
static const struct drm_mode_config_funcs intel_mode_funcs = {
.fb_create = intel_user_framebuffer_create,
.get_format_info = intel_fb_get_format_info,
- .output_poll_changed = intel_fbdev_output_poll_changed,
.mode_valid = intel_mode_valid,
.atomic_check = intel_atomic_check,
.atomic_commit = intel_atomic_commit,
diff --git a/drivers/gpu/drm/i915/display/intel_fbdev.c
b/drivers/gpu/drm/i915/display/intel_fbdev.c
index d8a165582fd59..31e8275a70fea 100644
--- a/drivers/gpu/drm/i915/display/intel_fbdev.c
+++ b/drivers/gpu/drm/i915/display/intel_fbdev.c
@@ -638,7 +638,7 @@ void intel_fbdev_set_suspend(struct drm_device *dev, int
state, bool synchronous
intel_fbdev_hpd_set_suspend(dev_priv, state);
}
-void intel_fbdev_output_poll_changed(struct drm_device *dev)
+static void intel_fbdev_output_poll_changed(struct drm_device *dev)
{
struct intel_fbdev *ifbdev = to_i915(dev)->display.fbdev.fbdev;
bool send_hpd;
@@ -657,7 +657,7 @@ void intel_fbdev_output_poll_changed(struct drm_device *dev)
drm_fb_helper_hotplug_event(>helper);
}
-void intel_fbdev_restore_mode(struct drm_i915_private *dev_priv)
+static void intel_fbdev_restore_mode(struct drm_i915_private *dev_priv)
{
struct intel_fbdev *ifbdev = dev_priv->display.fbdev.fbdev;
@@ -681,11 +681,18 @@ static void intel_fbdev_client_unregister(struct
drm_client_dev *client)
static int intel_fbdev_client_restore(struct drm_client_dev *client)
{
+ struct drm_i915_private *dev_priv = to_i915(client->dev);
+
+ intel_fbdev_restore_mode(dev_priv);
+ vga_switcheroo_process_delayed_switch();
+
return 0;
}
static int intel_fbdev_client_hotplug(struct drm_client_dev *client)
{
+ intel_fbdev_output_poll_changed(client->dev);
+
return 0;
}
diff --git a/drivers/gpu/drm/i915/display/intel_fbdev.h
b/drivers/gpu/drm/i915/display/intel_fbdev.h
index 04fd523a50232..8c953f102ba22 100644
--- a/drivers/gpu/drm/i915/display/intel_fbdev.h
+++ b/drivers/gpu/drm/i915/display/intel_fbdev.h
@@ -19,8 +19,6 @@ void intel_fbdev_initial_config_async(struct drm_i915_private
*dev_priv);
void intel_fbdev_unregister(struct drm_i915_private *dev_priv);
void intel_fbdev_fini(struct drm_i915_private *dev_priv);
void intel_fbdev_set_suspend(struct drm_device *dev, int state, bool
synchronous);
-void intel_fbdev_output_poll_changed(struct drm_device *dev);
-void intel_fbdev_restore_mode(struct drm_i915_private *dev_priv);
struct intel_framebuffer *intel_fbdev_framebuffer(struct intel_fbdev *fbdev);
#else
static inline int intel_fbdev_init(struct drm_device *dev)
@@ -44,13 +42,6 @@ static inline void intel_fbdev_set_suspend(struct drm_device
*dev, int state, bo
{
}
-static inline void intel_fbdev_output_poll_changed(struct drm_device *dev)
-{
-}
-
-static inline void intel_fbdev_restore_mode(struct drm_i915_private *i915)
-{
-}
static inline struct intel_framebuffer *intel_fbdev_framebuffer(struct
intel_fbdev *fbdev)
{
return NULL;
diff --git a/drivers/gpu/drm/i915/i915_driver.c
b/drivers/gpu/drm/i915/i915_driver.c
index f8dbee7a5af7f..14aa863dca60c 100644
--- a/drivers/gpu/drm/i915/i915_driver.c
+++ b/drivers/gpu/drm/i915/i915_driver.c
@@ -921,27 +921,6 @@ static int i915_driver_open(struct drm_device *dev, struct
drm_file *file)
return 0;
}
-/**
- * i915_driver_lastclose - clean up after all DRM clients have exited
- * @dev: DRM device
- *
- * Take care of cleaning up after all DRM clients have exited. In the
- * mode setting case, we want to restore the kernel's initial mode (just
- * in case the last client left us in a bad state).
- *
- * Additionally, in the non-mode setting case, we'll tear down the GTT
- * and DMA structures, since the kernel won't be using them, and clea
- * up any GEM state.
- */
-static void i915_driver_lastclose(struct drm_device
[PATCH v2 2/4] drm/i915: Initialize fbdev DRM client with callback functions
Initialize i915's fbdev client by giving an instance of struct
drm_client_funcs to drm_client_init(). Also clean up with
drm_client_release().
Doing this in i915 prevents fbdev helpers from initializing and
releasing the client internally (see drm_fb_helper_init()). No
functional change yet; the client callbacks will be filled later.
v2:
* call drm_fb_helper_unprepare() in error hndling (Jani)
* fix typo in commit message (Sam)
Signed-off-by: Thomas Zimmermann
---
drivers/gpu/drm/i915/display/intel_fbdev.c | 43 --
1 file changed, 39 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_fbdev.c
b/drivers/gpu/drm/i915/display/intel_fbdev.c
index 8d51550e18fd5..d8a165582fd59 100644
--- a/drivers/gpu/drm/i915/display/intel_fbdev.c
+++ b/drivers/gpu/drm/i915/display/intel_fbdev.c
@@ -378,6 +378,7 @@ static void intel_fbdev_destroy(struct intel_fbdev *ifbdev)
if (ifbdev->fb)
drm_framebuffer_remove(>fb->base);
+ drm_client_release(>helper.client);
drm_fb_helper_unprepare(>helper);
kfree(ifbdev);
}
@@ -671,6 +672,30 @@ void intel_fbdev_restore_mode(struct drm_i915_private
*dev_priv)
intel_fbdev_invalidate(ifbdev);
}
+/*
+ * Fbdev client and struct drm_client_funcs
+ */
+
+static void intel_fbdev_client_unregister(struct drm_client_dev *client)
+{ }
+
+static int intel_fbdev_client_restore(struct drm_client_dev *client)
+{
+ return 0;
+}
+
+static int intel_fbdev_client_hotplug(struct drm_client_dev *client)
+{
+ return 0;
+}
+
+static const struct drm_client_funcs intel_fbdev_client_funcs = {
+ .owner = THIS_MODULE,
+ .unregister = intel_fbdev_client_unregister,
+ .restore= intel_fbdev_client_restore,
+ .hotplug= intel_fbdev_client_hotplug,
+};
+
int intel_fbdev_init(struct drm_device *dev)
{
struct drm_i915_private *dev_priv = to_i915(dev);
@@ -692,16 +717,26 @@ int intel_fbdev_init(struct drm_device *dev)
else
ifbdev->preferred_bpp = ifbdev->helper.preferred_bpp;
+ ret = drm_client_init(dev, >helper.client, "i915-fbdev",
+ _fbdev_client_funcs);
+ if (ret)
+ goto err_drm_fb_helper_unprepare;
+
ret = drm_fb_helper_init(dev, >helper);
- if (ret) {
- kfree(ifbdev);
- return ret;
- }
+ if (ret)
+ goto err_drm_client_release;
dev_priv->display.fbdev.fbdev = ifbdev;
INIT_WORK(_priv->display.fbdev.suspend_work,
intel_fbdev_suspend_worker);
return 0;
+
+err_drm_client_release:
+ drm_client_release(>helper.client);
+err_drm_fb_helper_unprepare:
+ drm_fb_helper_unprepare(>helper);
+ kfree(ifbdev);
+ return ret;
}
static void intel_fbdev_initial_config(void *data, async_cookie_t cookie)
--
2.42.0
[PATCH v2 0/4] drm/i915: Convert fbdev to DRM client
Convert i915's fbdev code to struct drm_client. Replaces the current ad-hoc integration. The conversion includes a number of cleanups. As with most other driver's fbdev emulation, fbdev in i915 is now just another DRM client that runs after the DRM device has been registered. This allows to remove the asynchronous initialization. I've long wanted to send out an update for this patchset. i915 is the last driver with an fbdev emulation that is not build upon struct drm_client. Once reviewed, the patches would ideally go into drm-misc-next, so that the old fbdev helper code can be removed. We can also attempt to add additional in-kernel clients. A DRM-based dmesg log or a bootsplash are commonly mentioned. DRM can then switch easily among the existing clients if/when required. v2: * fix error handling (Jani) * fix non-fbdev builds * various minor fixes and cleanups Thomas Zimmermann (4): drm/i915: Move fbdev functions drm/i915: Initialize fbdev DRM client with callback functions drm/i915: Implement fbdev client callbacks drm/i915: Implement fbdev emulation as in-kernel client drivers/gpu/drm/i915/display/intel_display.c | 1 - .../drm/i915/display/intel_display_driver.c | 19 -- drivers/gpu/drm/i915/display/intel_fbdev.c| 250 ++ drivers/gpu/drm/i915/display/intel_fbdev.h| 29 +- drivers/gpu/drm/i915/i915_driver.c| 24 +- 5 files changed, 139 insertions(+), 184 deletions(-) base-commit: f8d21cb17a99b75862196036bb4bb93ee9637b74 -- 2.42.0
[PATCH v2 1/4] drm/i915: Move fbdev functions
Move functions within intel_fbdev.c to simplify later updates. No
functional changes.
Signed-off-by: Thomas Zimmermann
---
drivers/gpu/drm/i915/display/intel_fbdev.c | 154 ++---
1 file changed, 77 insertions(+), 77 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_fbdev.c
b/drivers/gpu/drm/i915/display/intel_fbdev.c
index 31d0d695d5671..8d51550e18fd5 100644
--- a/drivers/gpu/drm/i915/display/intel_fbdev.c
+++ b/drivers/gpu/drm/i915/display/intel_fbdev.c
@@ -545,58 +545,6 @@ static void intel_fbdev_suspend_worker(struct work_struct
*work)
true);
}
-int intel_fbdev_init(struct drm_device *dev)
-{
- struct drm_i915_private *dev_priv = to_i915(dev);
- struct intel_fbdev *ifbdev;
- int ret;
-
- if (drm_WARN_ON(dev, !HAS_DISPLAY(dev_priv)))
- return -ENODEV;
-
- ifbdev = kzalloc(sizeof(struct intel_fbdev), GFP_KERNEL);
- if (ifbdev == NULL)
- return -ENOMEM;
-
- mutex_init(>hpd_lock);
- drm_fb_helper_prepare(dev, >helper, 32, _fb_helper_funcs);
-
- if (intel_fbdev_init_bios(dev, ifbdev))
- ifbdev->helper.preferred_bpp = ifbdev->preferred_bpp;
- else
- ifbdev->preferred_bpp = ifbdev->helper.preferred_bpp;
-
- ret = drm_fb_helper_init(dev, >helper);
- if (ret) {
- kfree(ifbdev);
- return ret;
- }
-
- dev_priv->display.fbdev.fbdev = ifbdev;
- INIT_WORK(_priv->display.fbdev.suspend_work,
intel_fbdev_suspend_worker);
-
- return 0;
-}
-
-static void intel_fbdev_initial_config(void *data, async_cookie_t cookie)
-{
- struct intel_fbdev *ifbdev = data;
-
- /* Due to peculiar init order wrt to hpd handling this is separate. */
- if (drm_fb_helper_initial_config(>helper))
- intel_fbdev_unregister(to_i915(ifbdev->helper.dev));
-}
-
-void intel_fbdev_initial_config_async(struct drm_i915_private *dev_priv)
-{
- struct intel_fbdev *ifbdev = dev_priv->display.fbdev.fbdev;
-
- if (!ifbdev)
- return;
-
- ifbdev->cookie = async_schedule(intel_fbdev_initial_config, ifbdev);
-}
-
static void intel_fbdev_sync(struct intel_fbdev *ifbdev)
{
if (!ifbdev->cookie)
@@ -607,31 +555,6 @@ static void intel_fbdev_sync(struct intel_fbdev *ifbdev)
ifbdev->cookie = 0;
}
-void intel_fbdev_unregister(struct drm_i915_private *dev_priv)
-{
- struct intel_fbdev *ifbdev = dev_priv->display.fbdev.fbdev;
-
- if (!ifbdev)
- return;
-
- intel_fbdev_set_suspend(_priv->drm, FBINFO_STATE_SUSPENDED, true);
-
- if (!current_is_async())
- intel_fbdev_sync(ifbdev);
-
- drm_fb_helper_unregister_info(>helper);
-}
-
-void intel_fbdev_fini(struct drm_i915_private *dev_priv)
-{
- struct intel_fbdev *ifbdev =
fetch_and_zero(_priv->display.fbdev.fbdev);
-
- if (!ifbdev)
- return;
-
- intel_fbdev_destroy(ifbdev);
-}
-
/* Suspends/resumes fbdev processing of incoming HPD events. When resuming HPD
* processing, fbdev will perform a full connector reprobe if a hotplug event
* was received while HPD was suspended.
@@ -748,6 +671,83 @@ void intel_fbdev_restore_mode(struct drm_i915_private
*dev_priv)
intel_fbdev_invalidate(ifbdev);
}
+int intel_fbdev_init(struct drm_device *dev)
+{
+ struct drm_i915_private *dev_priv = to_i915(dev);
+ struct intel_fbdev *ifbdev;
+ int ret;
+
+ if (drm_WARN_ON(dev, !HAS_DISPLAY(dev_priv)))
+ return -ENODEV;
+
+ ifbdev = kzalloc(sizeof(struct intel_fbdev), GFP_KERNEL);
+ if (ifbdev == NULL)
+ return -ENOMEM;
+
+ mutex_init(>hpd_lock);
+ drm_fb_helper_prepare(dev, >helper, 32, _fb_helper_funcs);
+
+ if (intel_fbdev_init_bios(dev, ifbdev))
+ ifbdev->helper.preferred_bpp = ifbdev->preferred_bpp;
+ else
+ ifbdev->preferred_bpp = ifbdev->helper.preferred_bpp;
+
+ ret = drm_fb_helper_init(dev, >helper);
+ if (ret) {
+ kfree(ifbdev);
+ return ret;
+ }
+
+ dev_priv->display.fbdev.fbdev = ifbdev;
+ INIT_WORK(_priv->display.fbdev.suspend_work,
intel_fbdev_suspend_worker);
+
+ return 0;
+}
+
+static void intel_fbdev_initial_config(void *data, async_cookie_t cookie)
+{
+ struct intel_fbdev *ifbdev = data;
+
+ /* Due to peculiar init order wrt to hpd handling this is separate. */
+ if (drm_fb_helper_initial_config(>helper))
+ intel_fbdev_unregister(to_i915(ifbdev->helper.dev));
+}
+
+void intel_fbdev_initial_config_async(struct drm_i915_private *dev_priv)
+{
+ struct intel_fbdev *ifbdev = dev_priv->display.fbdev.fbdev;
+
+ if (!ifbdev)
+ return;
+
+ ifbdev->cookie = async_schedule(intel_fbdev_initial_config, ifbdev);
+}
+
+void intel_fbdev_unregister(struct drm_i915_private
Re: [PATCH v2 1/3] drm/buddy: Improve contiguous memory allocation
On 11/09/23 03:46, Matthew Auld wrote:
On 09/09/2023 17:09, Arunpravin Paneer Selvam wrote:
Problem statement: The current method roundup_power_of_two()
to allocate contiguous address triggers -ENOSPC in some cases
even though we have enough free spaces and so to help with
that we introduce a try harder mechanism.
In case of -ENOSPC, the new try harder mechanism rounddown the
original size to power of 2 and iterating over the round down
sized freelist blocks to allocate the required size traversing
RHS and LHS.
As part of the above new method implementation we moved
contiguous/alignment size computation part and trim function
to the drm buddy file.
v2: Modify the alloc_range() function to return total allocated size
on -ENOSPC err and traverse RHS/LHS to allocate the required
size (Matthew).
Signed-off-by: Arunpravin Paneer Selvam
---
drivers/gpu/drm/drm_buddy.c | 138
include/drm/drm_buddy.h | 6 +-
2 files changed, 127 insertions(+), 17 deletions(-)
diff --git a/drivers/gpu/drm/drm_buddy.c b/drivers/gpu/drm/drm_buddy.c
index 7098f125b54a..e909eed9cf60 100644
--- a/drivers/gpu/drm/drm_buddy.c
+++ b/drivers/gpu/drm/drm_buddy.c
@@ -480,10 +480,12 @@ alloc_from_freelist(struct drm_buddy *mm,
static int __alloc_range(struct drm_buddy *mm,
struct list_head *dfs,
u64 start, u64 size,
- struct list_head *blocks)
+ struct list_head *blocks,
+ u64 *total_allocated_on_err)
{
struct drm_buddy_block *block;
struct drm_buddy_block *buddy;
+ u64 total_allocated = 0;
LIST_HEAD(allocated);
u64 end;
int err;
@@ -520,6 +522,7 @@ static int __alloc_range(struct drm_buddy *mm,
}
mark_allocated(block);
+ total_allocated += drm_buddy_block_size(mm, block);
mm->avail -= drm_buddy_block_size(mm, block);
list_add_tail(>link, );
continue;
@@ -551,13 +554,20 @@ static int __alloc_range(struct drm_buddy *mm,
__drm_buddy_free(mm, block);
err_free:
- drm_buddy_free_list(mm, );
+ if (err == -ENOSPC && total_allocated_on_err) {
+ list_splice_tail(, blocks);
+ *total_allocated_on_err = total_allocated;
+ } else {
+ drm_buddy_free_list(mm, );
+ }
+
return err;
}
static int __drm_buddy_alloc_range(struct drm_buddy *mm,
u64 start,
u64 size,
+ u64 *total_allocated_on_err,
struct list_head *blocks)
{
LIST_HEAD(dfs);
@@ -566,7 +576,62 @@ static int __drm_buddy_alloc_range(struct
drm_buddy *mm,
for (i = 0; i < mm->n_roots; ++i)
list_add_tail(>roots[i]->tmp_link, );
- return __alloc_range(mm, , start, size, blocks);
+ return __alloc_range(mm, , start, size,
+ blocks, total_allocated_on_err);
+}
+
+static int __alloc_contig_try_harder(struct drm_buddy *mm,
+ u64 size,
+ u64 min_block_size,
+ struct list_head *blocks)
+{
+ u64 rhs_offset, lhs_offset, lhs_size, filled;
+ struct drm_buddy_block *block;
+ struct list_head *list;
+ LIST_HEAD(blocks_lhs);
+ unsigned long pages;
+ unsigned int order;
+ u64 modify_size;
+ int err;
+
+ modify_size = rounddown_pow_of_two(size);
+ pages = modify_size >> ilog2(mm->chunk_size);
+ order = fls(pages) - 1;
+ if (order == 0)
+ return -ENOSPC;
+
+ list = >free_list[order];
+ if (list_empty(list))
+ return -ENOSPC;
+
+ list_for_each_entry_reverse(block, list, link) {
+ /* Allocate blocks traversing RHS */
+ rhs_offset = drm_buddy_block_offset(block);
+ err = __drm_buddy_alloc_range(mm, rhs_offset, size,
+ , blocks);
+ if (!err || err != -ENOSPC)
+ return err;
+
+ lhs_size = max((size - filled), min_block_size);
+ if (!IS_ALIGNED(lhs_size, min_block_size))
+ lhs_size = round_up(lhs_size, min_block_size);
+
+ /* Allocate blocks traversing LHS */
+ lhs_offset = drm_buddy_block_offset(block) - lhs_size;
+ err = __drm_buddy_alloc_range(mm, lhs_offset, lhs_size,
+ NULL, _lhs);
+ if (!err) {
+ list_splice(_lhs, blocks);
+ return 0;
I guess we could attempt to trim this also (could tweak the trim to
work on multiple nodes)? But I guess in practice should be pretty meh,
given that the extra rhs is hopefully not too big in the corner case
where the alignment doesn't fit the min_block_size?
Thanks for the review. good point. I will take a look into it.
Regards,
Arun.
Anyway, for patches 1-3,
Reviewed-by: Matthew Auld
+ } else if (err != -ENOSPC) {
+ drm_buddy_free_list(mm, blocks);
+ return err;
+ }
+ /* Free blocks for the next iteration */
+
[linus:master] [dma] d62c43a953: WARNING:at_mm/slab_common.c:#kmem_cache_destroy
hi, Arvind Yadav,
we know this commit is quite old, but it shows persistent low rate issue and
parent keeps clean even when we run both this commit and parent up to ~300
times.
the config to build both kernel is a randconfig as in
https://download.01.org/0day-ci/archive/20230913/202309132239.70437559-oliver.s...@intel.com
c85d00d4fd8b98ea d62c43a953ce02d54521ec06217
---
fail:runs %reproductionfail:runs
| | |
:300 6% 17:312
dmesg.BUG_mock_fence(Tainted:G_T):Objects_remaining_in_mock_fence_on__kmem_cache_shutdown()
:300 11% 33:312 dmesg.EIP:kmem_cache_destroy
:300 11% 33:312
dmesg.WARNING:at_mm/slab_common.c:#kmem_cache_destroy
at the same time, as in below formal report mentioned, we still observed
similar issue on latest linus/master and linux-next/master, so we just send
out this report FYI.
Hello,
kernel test robot noticed "WARNING:at_mm/slab_common.c:#kmem_cache_destroy" on:
commit: d62c43a953ce02d54521ec06217d0c2ed6d489af ("dma-buf: Enable signaling on
fence for selftests")
https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git master
[test failed on linus/master 0bb80ecc33a8fb5a682236443c1e740d5c917d1d]
[test failed on linux-next/master 3c13c772fc233a10342c8e1605ff0855dfdf0c89]
in testcase: boot
compiler: gcc-12
test machine: qemu-system-i386 -enable-kvm -cpu SandyBridge -smp 2 -m 4G
(please refer to attached dmesg/kmsg for entire log/backtrace)
If you fix the issue in a separate patch/commit (i.e. not just a new version of
the same patch/commit), kindly add following tags
| Reported-by: kernel test robot
| Closes:
https://lore.kernel.org/oe-lkp/202309132239.70437559-oliver.s...@intel.com
[ 21.601153][T1] [ cut here ]
[ 21.693224][ T1] kmem_cache_destroy mock_fence: Slab cache still has objects
when called from dma_fence_chain (drivers/dma-buf/st-dma-fence-chain.c:709)
[ 21.693275][ T1] WARNING: CPU: 0 PID: 1 at mm/slab_common.c:478
kmem_cache_destroy (mm/slab_common.c:478)
[ 21.697039][T1] Modules linked in:
[ 21.697859][T1] CPU: 0 PID: 1 Comm: swapper Tainted: GT
6.0.0-rc2-00744-gd62c43a953ce #1 26be6099e9dfaf1dc1fa091a1f5a61f95afa9121
[ 21.700290][T1] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996),
BIOS 1.16.2-debian-1.16.2-1 04/01/2014
[ 21.702175][ T1] EIP: kmem_cache_destroy (mm/slab_common.c:478)
[ 21.707576][ T1] Code: 00 ff 4b 2c 0f 85 b2 00 00 00 89 d8 e8 ea 4a 02 00 85
c0 74 1f ff 75 04 ff 73 40 68 6c ff 96 d7 68 7d 44 09 d8 e8 40 c8 da 00 <0f> 0b
83 c4 10 e9 88 00 00 00 8d 73 44 89 f0 e8 8a 8e 2e 00 84 c0
All code
0: 00 ff add%bh,%bh
2: 4b 2c 0frex.WXB sub $0xf,%al
5: 85 b2 00 00 00 89 test %esi,-0x7700(%rdx)
b: d8 e8 fsubr %st(0),%st
d: ea (bad)
e: 4a 02 00rex.WX add (%rax),%al
11: 85 c0 test %eax,%eax
13: 74 1f je 0x34
15: ff 75 04push 0x4(%rbp)
18: ff 73 40push 0x40(%rbx)
1b: 68 6c ff 96 d7 push $0xd796ff6c
20: 68 7d 44 09 d8 push $0xd809447d
25: e8 40 c8 da 00 call 0xdac86a
2a:* 0f 0b ud2 <-- trapping instruction
2c: 83 c4 10add$0x10,%esp
2f: e9 88 00 00 00 jmp0xbc
34: 8d 73 44lea0x44(%rbx),%esi
37: 89 f0 mov%esi,%eax
39: e8 8a 8e 2e 00 call 0x2e8ec8
3e: 84 c0 test %al,%al
Code starting with the faulting instruction
===
0: 0f 0b ud2
2: 83 c4 10add$0x10,%esp
5: e9 88 00 00 00 jmp0x92
a: 8d 73 44lea0x44(%rbx),%esi
d: 89 f0 mov%esi,%eax
f: e8 8a 8e 2e 00 call 0x2e8e9e
14: 84 c0 test %al,%al
[ 21.711048][T1] EAX: 0066 EBX: ee62b680 ECX: 0001 EDX: 8001
[ 21.712412][T1] ESI: d87beb98 EDI: EBP: c128dee8 ESP: c128decc
[ 21.713723][T1] DS: 007b ES: 007b FS: GS: SS: 0068 EFLAGS:
00010292
[ 21.715192][T1] CR0: 80050033 CR2: b7d07070 CR3: 189fe000 CR4: 00040690
[ 21.716533][T1] DR0: DR1: DR2: DR3:
[ 21.717859][T1] DR6: fffe0ff0 DR7: 0400
[ 21.718792][T1] Call Trace:
[ 21.719488][ T1] ? dma_fence_chain (drivers/dma-buf/st-dma-fence-chain.c:709)
[ 21.720419][ T1] dma_fence_chain (drivers/dma-buf/st-dma-fence-chain.c:709)
[ 21.721327][ T1] st_init (drivers/dma-buf/selftest.c:141
drivers/dma-buf/selftest.c:155)
[ 21.72
Re: [PATCH] drm/tests: provide exit function
On Wed, Sep 13, 2023 at 03:19:00PM +0300, José Pekkarinen wrote: > Similarly to the drm_exec_test module, the drm_modes_test > shows the following output on dmesg on load: > > [ 5556.674834] KTAP version 1 > [ 5556.674841] 1..1 > [ 5556.675317] KTAP version 1 > [ 5556.675321] # Subtest: drm_modes_analog_tv > [ 5556.675323] # module: drm_modes_test > [ 5556.675327] 1..4 > [ 5556.683731] > == > [ 5556.683777] BUG: KASAN: slab-use-after-free in > drm_dev_put.part.0+0x4b/0x90 [drm] > [ 5556.683882] Read of size 8 at addr 88812db30428 by task > kunit_try_catch/75921 > [ 5556.683882] > [ 5556.683882] CPU: 1 PID: 75921 Comm: kunit_try_catch Tainted: GW > N 6.6.0-rc1-dirty #2 > [ 5556.683882] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 0.0.0 > 02/06/2015 > [ 5556.683882] Call Trace: > [ 5556.683882] > [ 5556.683882] dump_stack_lvl+0x43/0x60 > [ 5556.683882] print_report+0xcf/0x660 > [ 5556.683882] ? __virt_addr_valid+0xd9/0x160 > [ 5556.683882] ? drm_dev_put.part.0+0x4b/0x90 [drm] > [ 5556.683882] kasan_report+0xda/0x110 > [ 5556.683882] ? drm_dev_put.part.0+0x4b/0x90 [drm] > [ 5556.683882] drm_dev_put.part.0+0x4b/0x90 [drm] > [ 5556.683882] release_nodes+0x83/0x160 > [ 5556.683882] devres_release_all+0xe6/0x130 > [ 5556.683882] ? __pfx_devres_release_all+0x10/0x10 > [ 5556.683882] ? mutex_unlock+0x80/0xd0 > [ 5556.683882] ? __pfx_mutex_unlock+0x10/0x10 > [ 5556.683882] device_unbind_cleanup+0x16/0xc0 > [ 5556.683882] device_release_driver_internal+0x28b/0x2e0 > [ 5556.683882] bus_remove_device+0x124/0x1d0 > [ 5556.683882] device_del+0x23d/0x580 > [ 5556.683882] ? __pfx_device_del+0x10/0x10 > [ 5556.683882] ? kasan_set_track+0x21/0x30 > [ 5556.683882] ? _raw_spin_lock_irqsave+0x98/0xf0 > [ 5556.683882] platform_device_del.part.0+0x19/0xe0 > [ 5556.683882] kunit_remove_resource+0xfa/0x140 [kunit] > [ 5556.683882] kunit_cleanup+0x47/0xa0 [kunit] > [ 5556.683882] ? __pfx_kunit_try_run_case_cleanup+0x10/0x10 [kunit] > [ 5556.683882] ? __pfx_kunit_generic_run_threadfn_adapter+0x10/0x10 [kunit] > [ 5556.683882] kunit_generic_run_threadfn_adapter+0x29/0x50 [kunit] > [ 5556.683882] kthread+0x184/0x1c0 > [ 5556.683882] ? __pfx_kthread+0x10/0x10 > [ 5556.683882] ret_from_fork+0x30/0x50 > [ 5556.683882] ? __pfx_kthread+0x10/0x10 > [ 5556.683882] ret_from_fork_asm+0x1b/0x30 > [ 5556.683882] > [ 5556.683882] > [ 5556.683882] Allocated by task 75920: > [ 5556.683882] kasan_save_stack+0x2f/0x50 > [ 5556.683882] kasan_set_track+0x21/0x30 > [ 5556.683882] __kasan_kmalloc+0xa6/0xb0 > [ 5556.683882] __kmalloc+0x5d/0x160 > [ 5556.683882] kunit_kmalloc_array+0x1c/0x50 [kunit] > [ 5556.683882] drm_test_modes_init+0xda/0x260 [drm_modes_test] > [ 5556.683882] kunit_try_run_case+0x6e/0x100 [kunit] > [ 5556.683882] kunit_generic_run_threadfn_adapter+0x29/0x50 [kunit] > [ 5556.683882] kthread+0x184/0x1c0 > [ 5556.683882] ret_from_fork+0x30/0x50 > [ 5556.683882] ret_from_fork_asm+0x1b/0x30 > [ 5556.683882] > [ 5556.683882] Freed by task 75921: > [ 5556.683882] kasan_save_stack+0x2f/0x50 > [ 5556.683882] kasan_set_track+0x21/0x30 > [ 5556.683882] kasan_save_free_info+0x27/0x40 > [ 5556.683882] kasan_slab_free+0x166/0x1c0 > [ 5556.683882] slab_free_freelist_hook+0x9f/0x1e0 > [ 5556.683882] __kmem_cache_free+0x187/0x2d0 > [ 5556.683882] kunit_remove_resource+0xfa/0x140 [kunit] > [ 5556.683882] kunit_cleanup+0x47/0xa0 [kunit] > [ 5556.683882] kunit_generic_run_threadfn_adapter+0x29/0x50 [kunit] > [ 5556.683882] kthread+0x184/0x1c0 > [ 5556.683882] ret_from_fork+0x30/0x50 > [ 5556.683882] ret_from_fork_asm+0x1b/0x30 > [ 5556.683882] > [ 5556.683882] The buggy address belongs to the object at 88812db30400 > [ 5556.683882] which belongs to the cache kmalloc-256 of size 256 > [ 5556.683882] The buggy address is located 40 bytes inside of > [ 5556.683882] freed 256-byte region [88812db30400, 88812db30500) > [ 5556.683882] > [ 5556.683882] The buggy address belongs to the physical page: > [ 5556.683882] page:b3a5f157 refcount:1 mapcount:0 > mapping: index:0x0 pfn:0x12db30 > [ 5556.683882] head:b3a5f157 order:2 entire_mapcount:0 > nr_pages_mapped:0 pincount:0 > [ 5556.683882] ksm flags: > 0x17c840(slab|head|node=0|zone=2|lastcpupid=0x1f) > [ 5556.683882] page_type: 0x() > [ 5556.683882] raw: 0017c840 888100042b40 ea00053e2000 > dead0003 > [ 5556.683882] raw: 80200020 0001 > > [ 5556.683882] page dumped because: kasan: bad access detected > [ 5556.683882] > [ 5556.683882] Memory state around the buggy address: > [ 5556.683882] 88812db30300: fc fc fc fc fc fc fc fc fc fc fc fc fc fc > fc fc > [ 5556.683882] 88812db30380: fc fc fc fc fc fc fc fc fc fc fc fc fc fc > fc fc > [ 5556.683882] >88812db30400: fa fb fb fb fb
Re: [Intel-gfx] [PATCH 05/11] drm/i915: Check lane count when determining FEC support
On Thu, May 25, 2023 at 11:09:30AM +0300, Luca Coelho wrote:
> On Tue, 2023-05-02 at 17:39 +0300, Ville Syrjala wrote:
> > From: Ville Syrjälä
> >
> > ICL doesn't support FEC with a x1 DP link. Make sure
> > we don't try to enable FEC in such cases.
> >
> > Signed-off-by: Ville Syrjälä
> > ---
> > drivers/gpu/drm/i915/display/intel_dp.c | 23 ---
> > 1 file changed, 12 insertions(+), 11 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/display/intel_dp.c
> > b/drivers/gpu/drm/i915/display/intel_dp.c
> > index b27b4fb71ed7..9ac199444155 100644
> > --- a/drivers/gpu/drm/i915/display/intel_dp.c
> > +++ b/drivers/gpu/drm/i915/display/intel_dp.c
> > @@ -1218,7 +1218,8 @@ static bool intel_dp_source_supports_fec(struct
> > intel_dp *intel_dp,
> > if (DISPLAY_VER(dev_priv) >= 12)
> > return true;
> >
> > - if (DISPLAY_VER(dev_priv) == 11 && encoder->port != PORT_A)
> > + if (DISPLAY_VER(dev_priv) == 11 &&
> > + encoder->port != PORT_A && pipe_config->lane_count != 1)
> > return true;
> >
> > return false;
> > @@ -1234,7 +1235,7 @@ static bool intel_dp_supports_fec(struct intel_dp
> > *intel_dp,
> > static bool intel_dp_supports_dsc(struct intel_dp *intel_dp,
> > const struct intel_crtc_state *crtc_state)
> > {
> > - if (intel_crtc_has_type(crtc_state, INTEL_OUTPUT_DP) &&
> > !crtc_state->fec_enable)
> > + if (!intel_dp_is_edp(intel_dp) && !crtc_state->fec_enable)
>
> I'm probably missing something, but this change...
This should have been a separate change I suppose. What this is
currently asserting is DP-SST needs FEC to use DSC, but so does DP-MST
which this is totally forgetting to check. eDP is only case where we
can skip FEC.
>
>
> > return false;
> >
> > return intel_dsc_source_support(crtc_state) &&
> > @@ -1580,15 +1581,6 @@ int intel_dp_dsc_compute_config(struct intel_dp
> > *intel_dp,
> > int pipe_bpp;
> > int ret;
> >
> > - pipe_config->fec_enable = !intel_dp_is_edp(intel_dp) &&
> > - intel_dp_supports_fec(intel_dp, pipe_config);
> > -
> > - if (!intel_dp_supports_dsc(intel_dp, pipe_config))
> > - return -EINVAL;
> > -
> > - if (!intel_dp_dsc_supports_format(intel_dp, pipe_config->output_format))
> > - return -EINVAL;
> > -
> > if (compute_pipe_bpp)
> > pipe_bpp = intel_dp_dsc_compute_bpp(intel_dp,
> > conn_state->max_requested_bpc);
> > else
> > @@ -1615,6 +1607,15 @@ int intel_dp_dsc_compute_config(struct intel_dp
> > *intel_dp,
> > pipe_config->port_clock = limits->max_rate;
> > pipe_config->lane_count = limits->max_lane_count;
> >
> > + pipe_config->fec_enable = !intel_dp_is_edp(intel_dp) &&
> > + intel_dp_supports_fec(intel_dp, pipe_config);
> > +
> > + if (!intel_dp_supports_dsc(intel_dp, pipe_config))
> > + return -EINVAL;
> > +
> > + if (!intel_dp_dsc_supports_format(intel_dp, pipe_config->output_format))
> > + return -EINVAL;
> > +
> > if (intel_dp_is_edp(intel_dp)) {
> > pipe_config->dsc.compressed_bpp =
> > min_t(u16,
> > drm_edp_dsc_sink_output_bpp(intel_dp->dsc_dpcd) >> 4,
>
> ...and this code move are not explained in the commit message? How are
> they related?
This is moved becaue we need to compute lanel_count before we can
actually check it.
--
Ville Syrjälä
Intel
Re: [PATCH] drm/tests: provide exit function
On Wed, Sep 13, 2023 at 05:01:40PM +0300, José Pekkarinen wrote: > On 2023-09-13 12:50, Maxime Ripard wrote: > > Hi, > > > > On Wed, Sep 13, 2023 at 11:32:23AM +0300, José Pekkarinen wrote: > > > Running drm_exec_test by modprobing the module I > > > observe the following output: > > > > > > [ 424.471936] KTAP version 1 > > > [ 424.471942] 1..1 > > > [ 424.472446] KTAP version 1 > > > [ 424.472450] # Subtest: drm_exec > > > [ 424.472453] # module: drm_exec_test > > > [ 424.472459] 1..7 > > > [ 424.479082] > > > == > > > [ 424.479095] BUG: KASAN: slab-use-after-free in > > > drm_dev_put.part.0+0x4b/0x90 [drm] > > > [ 424.479426] Read of size 8 at addr 888132d3e028 by task > > > kunit_try_catch/1866 > > > [ 424.479436] > > > [ 424.479442] CPU: 1 PID: 1866 Comm: kunit_try_catch Tainted: G > > > N 6.6.0-rc1-dirty #2 > > > > That's suspicious > > > > > [ 424.479446] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), > > > BIOS 0.0.0 02/06/2015 > > > [ 424.479446] Call Trace: > > > [ 424.479446] > > > [ 424.479446] dump_stack_lvl+0x43/0x60 > > > [ 424.479446] print_report+0xcf/0x660 > > > [ 424.479446] ? __virt_addr_valid+0xd9/0x160 > > > [ 424.479446] ? drm_dev_put.part.0+0x4b/0x90 [drm] > > > [ 424.479446] kasan_report+0xda/0x110 > > > [ 424.479446] ? drm_dev_put.part.0+0x4b/0x90 [drm] > > > [ 424.479446] drm_dev_put.part.0+0x4b/0x90 [drm] > > > [ 424.479446] release_nodes+0x83/0x160 > > > [ 424.479446] devres_release_all+0xe6/0x130 > > > [ 424.479446] ? __pfx_devres_release_all+0x10/0x10 > > > [ 424.479446] ? mutex_unlock+0x80/0xd0 > > > [ 424.479446] ? __pfx_mutex_unlock+0x10/0x10 > > > [ 424.479446] device_unbind_cleanup+0x16/0xc0 > > > [ 424.479446] device_release_driver_internal+0x28b/0x2e0 > > > [ 424.479446] bus_remove_device+0x124/0x1d0 > > > [ 424.479446] device_del+0x23d/0x580 > > > [ 424.479446] ? __pfx_device_del+0x10/0x10 > > > [ 424.479446] ? kasan_set_track+0x21/0x30 > > > [ 424.479446] ? _raw_spin_lock_irqsave+0x98/0xf0 > > > [ 424.479446] platform_device_del.part.0+0x19/0xe0 > > > [ 424.479446] kunit_remove_resource+0xfa/0x140 [kunit] > > > [ 424.479446] kunit_cleanup+0x47/0xa0 [kunit] > > > [ 424.479446] ? __pfx_kunit_try_run_case_cleanup+0x10/0x10 [kunit] > > > [ 424.479446] ? __pfx_kunit_generic_run_threadfn_adapter+0x10/0x10 > > > [kunit] > > > [ 424.479446] kunit_generic_run_threadfn_adapter+0x29/0x50 [kunit] > > > [ 424.479446] kthread+0x184/0x1c0 > > > [ 424.479446] ? __pfx_kthread+0x10/0x10 > > > [ 424.479446] ret_from_fork+0x30/0x50 > > > [ 424.479446] ? __pfx_kthread+0x10/0x10 > > > [ 424.479446] ret_from_fork_asm+0x1b/0x30 > > > [ 424.479446] > > > [ 424.479446] > > > [ 424.479446] Allocated by task 1865: > > > [ 424.479446] kasan_save_stack+0x2f/0x50 > > > [ 424.479446] kasan_set_track+0x21/0x30 > > > [ 424.479446] __kasan_kmalloc+0xa6/0xb0 > > > [ 424.479446] __kmalloc+0x5d/0x160 > > > [ 424.479446] kunit_kmalloc_array+0x1c/0x50 [kunit] > > > [ 424.479446] drm_exec_test_init+0xef/0x260 [drm_exec_test] > > > [ 424.479446] kunit_try_run_case+0x6e/0x100 [kunit] > > > [ 424.479446] kunit_generic_run_threadfn_adapter+0x29/0x50 [kunit] > > > [ 424.479446] kthread+0x184/0x1c0 > > > [ 424.479446] ret_from_fork+0x30/0x50 > > > [ 424.479446] ret_from_fork_asm+0x1b/0x30 > > > [ 424.479446] > > > [ 424.479446] Freed by task 1866: > > > [ 424.479446] kasan_save_stack+0x2f/0x50 > > > [ 424.479446] kasan_set_track+0x21/0x30 > > > [ 424.479446] kasan_save_free_info+0x27/0x40 > > > [ 424.479446] kasan_slab_free+0x166/0x1c0 > > > [ 424.479446] slab_free_freelist_hook+0x9f/0x1e0 > > > [ 424.479446] __kmem_cache_free+0x187/0x2d0 > > > [ 424.479446] kunit_remove_resource+0xfa/0x140 [kunit] > > > [ 424.479446] kunit_cleanup+0x47/0xa0 [kunit] > > > [ 424.479446] kunit_generic_run_threadfn_adapter+0x29/0x50 [kunit] > > > [ 424.479446] kthread+0x184/0x1c0 > > > [ 424.479446] ret_from_fork+0x30/0x50 > > > [ 424.479446] ret_from_fork_asm+0x1b/0x30 > > > [ 424.479446] > > > [ 424.479446] The buggy address belongs to the object at > > > 888132d3e000 > > > [ 424.479446] which belongs to the cache kmalloc-256 of size 256 > > > [ 424.479446] The buggy address is located 40 bytes inside of > > > [ 424.479446] freed 256-byte region [888132d3e000, > > > 888132d3e100) > > > [ 424.479446] > > > [ 424.479446] The buggy address belongs to the physical page: > > > [ 424.479446] page:92ff6551 refcount:1 mapcount:0 > > > mapping: index:0x888132d3f600 pfn:0x132d3c > > > [ 424.479446] head:92ff6551 order:2 entire_mapcount:0 > > > nr_pages_mapped:0 pincount:0 > > > [ 424.479446] ksm flags: > > > 0x17c840(slab|head|node=0|zone=2|lastcpupid=0x1f) > > > [ 424.479446] page_type: 0x() > > > [ 424.479446] raw: 0017c840
Re: [Intel-gfx] [PATCH v2 08/11] drm/i915: Introduce crtc_state->enhanced_framing
On Thu, May 25, 2023 at 12:51:28PM +0300, Luca Coelho wrote:
> On Wed, 2023-05-03 at 14:36 +0300, Ville Syrjala wrote:
> > From: Ville Syrjälä
> >
> > Track DP enhanced framing properly in the crtc state instead
> > of relying just on the cached DPCD everywhere, and hook it
> > up into the state check and dump.
> >
> > v2: Actually set enhanced_framing in .compute_config()
> >
> > Signed-off-by: Ville Syrjälä
> > ---
> > drivers/gpu/drm/i915/display/g4x_dp.c | 10 --
> > drivers/gpu/drm/i915/display/intel_crt.c | 2 ++
> > drivers/gpu/drm/i915/display/intel_crtc_state_dump.c | 5 +++--
> > drivers/gpu/drm/i915/display/intel_ddi.c | 11 +--
> > drivers/gpu/drm/i915/display/intel_display.c | 1 +
> > drivers/gpu/drm/i915/display/intel_display_types.h| 2 ++
> > drivers/gpu/drm/i915/display/intel_dp.c | 3 +++
> > drivers/gpu/drm/i915/display/intel_dp_link_training.c | 2 +-
> > 8 files changed, 29 insertions(+), 7 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/display/g4x_dp.c
> > b/drivers/gpu/drm/i915/display/g4x_dp.c
> > index 920d570f7594..534546ea7d0b 100644
> > --- a/drivers/gpu/drm/i915/display/g4x_dp.c
> > +++ b/drivers/gpu/drm/i915/display/g4x_dp.c
> > @@ -141,7 +141,7 @@ static void intel_dp_prepare(struct intel_encoder
> > *encoder,
> >
> > intel_de_rmw(dev_priv, TRANS_DP_CTL(crtc->pipe),
> > TRANS_DP_ENH_FRAMING,
> > -drm_dp_enhanced_frame_cap(intel_dp->dpcd) ?
> > +pipe_config->enhanced_framing ?
> > TRANS_DP_ENH_FRAMING : 0);
> > } else {
> > if (IS_G4X(dev_priv) && pipe_config->limited_color_range)
> > @@ -153,7 +153,7 @@ static void intel_dp_prepare(struct intel_encoder
> > *encoder,
> > intel_dp->DP |= DP_SYNC_VS_HIGH;
> > intel_dp->DP |= DP_LINK_TRAIN_OFF;
> >
> > - if (drm_dp_enhanced_frame_cap(intel_dp->dpcd))
> > + if (pipe_config->enhanced_framing)
> > intel_dp->DP |= DP_ENHANCED_FRAMING;
> >
> > if (IS_CHERRYVIEW(dev_priv))
> > @@ -351,6 +351,9 @@ static void intel_dp_get_config(struct intel_encoder
> > *encoder,
> > u32 trans_dp = intel_de_read(dev_priv,
> > TRANS_DP_CTL(crtc->pipe));
> >
> > + if (trans_dp & TRANS_DP_ENH_FRAMING)
> > + pipe_config->enhanced_framing = true;
> > +
> > if (trans_dp & TRANS_DP_HSYNC_ACTIVE_HIGH)
> > flags |= DRM_MODE_FLAG_PHSYNC;
> > else
> > @@ -361,6 +364,9 @@ static void intel_dp_get_config(struct intel_encoder
> > *encoder,
> > else
> > flags |= DRM_MODE_FLAG_NVSYNC;
> > } else {
> > + if (tmp & DP_ENHANCED_FRAMING)
> > + pipe_config->enhanced_framing = true;
> > +
> > if (tmp & DP_SYNC_HS_HIGH)
> > flags |= DRM_MODE_FLAG_PHSYNC;
> > else
> > diff --git a/drivers/gpu/drm/i915/display/intel_crt.c
> > b/drivers/gpu/drm/i915/display/intel_crt.c
> > index 13519f78cf9f..52af64aa9953 100644
> > --- a/drivers/gpu/drm/i915/display/intel_crt.c
> > +++ b/drivers/gpu/drm/i915/display/intel_crt.c
> > @@ -449,6 +449,8 @@ static int hsw_crt_compute_config(struct intel_encoder
> > *encoder,
> > /* FDI must always be 2.7 GHz */
> > pipe_config->port_clock = 135000 * 2;
> >
> > + pipe_config->enhanced_framing = true;
> > +
>
> Just curious, why are you setting it to true by default here?
We always want to use enhanced framing with FDI. Setting it here
and doing the readout allows us to also state check it also for FDI.
>
> Otherwise, the changes look reasonable:
>
> Reviewed-by: Luca Coelho
>
> --
> Cheers,
> Luca.
--
Ville Syrjälä
Intel
Re: [PATCH drm-misc-next v3 6/7] drm/gpuvm: generalize dma_resv/extobj handling and GEM validation
On 9/13/23 16:01, Boris Brezillon wrote: On Wed, 13 Sep 2023 15:22:56 +0200 Thomas Hellström wrote: On 9/13/23 13:33, Boris Brezillon wrote: On Wed, 13 Sep 2023 12:39:01 +0200 Thomas Hellström wrote: Hi, On 9/13/23 09:19, Boris Brezillon wrote: On Wed, 13 Sep 2023 17:05:42 +1000 Dave Airlie wrote: On Wed, 13 Sept 2023 at 17:03, Boris Brezillon wrote: On Tue, 12 Sep 2023 18:20:32 +0200 Thomas Hellström wrote: +/** + * get_next_vm_bo_from_list() - get the next vm_bo element + * @__gpuvm: The GPU VM + * @__list_name: The name of the list we're iterating on + * @__local_list: A pointer to the local list used to store already iterated items + * @__prev_vm_bo: The previous element we got from drm_gpuvm_get_next_cached_vm_bo() + * + * This helper is here to provide lockless list iteration. Lockless as in, the + * iterator releases the lock immediately after picking the first element from + * the list, so list insertion deletion can happen concurrently. Are the list spinlocks needed for that async state update from within the dma-fence critical section we've discussed previously? Any driver calling _[un]link() from its drm_gpu_scheduler::run_job() hook will be in this situation (Panthor at the moment, PowerVR soon). I get that Xe and Nouveau don't need that because they update the VM state early (in the ioctl path), but I keep thinking this will hurt us if we don't think it through from the beginning, because once you've set this logic to depend only on resv locks, it will be pretty hard to get back to a solution which lets synchronous VM_BINDs take precedence on asynchronous request, and, with vkQueueBindSparse() passing external deps (plus the fact the VM_BIND queue might be pretty deep), it can take a long time to get your synchronous VM_BIND executed... So this would boil down to either (possibly opt-in) keeping the spinlock approach or pushing the unlink out to a wq then? Deferred _unlink() would not be an issue, since I already defer the drm_gpuva destruction to a wq, it would just a be a matter of moving the _unlink() call there as well. But _link() also takes the GEM gpuva list lock, and that one is bit tricky, in that sm_map() can trigger 2 more _link() calls for the prev/next mappings, which we can't guess until we get to execute the VM update. If we mandate the use of the GEM resv lock, that simply means async VM updates (AKA calling drm_gpuvm_sm_[un]map()) are not an option. And if this is what everyone agrees on, then I'd like the APIs that make this sort of async VM update possible (drm_gpuvm_sm_[un]map(), the drm_gpuvm_ops::sm_step* methods, and probably other things) to be dropped, so we don't make it look like it's something we support. BTW, as also asked in a reply to Danilo, how do you call unlink from run_job() when it was requiring the obj->dma_resv lock, or was that a WIP? _unlink() makes sure the GEM gpuva list lock is taken, but this can be a custom lock (see drm_gem_gpuva_set_lock()). In panthor we have panthor_gem_object::gpuva_list_lock that's dedicated the gpuva list protection. We make sure we never take this lock while allocating memory to guarantee the dma-signalling path can't deadlock. btw what is the use case for this? do we have actual vulkan applications we know will have problems here? I don't, but I think that's a concern Faith raised at some point (dates back from when I was reading threads describing how VM_BIND on i915 should work, and I was clearly discovering this whole VM_BIND thing at that time, so maybe I misunderstood). it feels like a bit of premature optimisation, but maybe we have use cases. Might be, but that's the sort of thing that would put us in a corner if we don't have a plan for when the needs arise. Besides, if we don't want to support that case because it's too complicated, I'd recommend dropping all the drm_gpuvm APIs that let people think this mode is valid/supported (map/remap/unmap hooks in drm_gpuvm_ops, drm_gpuvm_sm_[un]map helpers, etc). Keeping them around just adds to the confusion. Xe allows bypassing the bind-queue with another bind-queue, but to completely avoid dependencies between queues the Operations may not overlap. So, you check the VM state with some VM lock held (would be the VM resv in my case), and if the mapping is new (no overlaps with pre-existing mappings), you queue it to the fast-track/sync-VM_BIND queue. What would be missing I guess is a way to know if the mapping is active (MMU has been updated) or pending (MMU update queued to the bind-queue), so I can fast-track mapping/unmapping of active mappings. This would leave overlapping sync/async VM updates, which can't happen in practice unless userspace is doing something wrong (sparse bindings always go through vkQueueBindSparse). User-space is allowed to create new bind queues at will, and they execute independently save for range overlaps. I've limited panthor to just one bind-queue that's automatically
Re: [PATCH drm-misc-next v3 6/7] drm/gpuvm: generalize dma_resv/extobj handling and GEM validation
Am 13.09.23 um 14:16 schrieb Danilo Krummrich: As mentioned in a different mail thread, the reply is based on the assumption that we don't support anything else than GPUVM updates from the IOCTL. I think that this assumption is incorrect. Vulkan is just once specific use case, but this here should probably be able to handle other use cases as well. Especially with HMM you get the requirement that you need to be able to invalidate GPUVM mappings without grabbing a reservation lock. See what the eviction lock in amdgpu is doing for example. Regards, Christian. On Wed, Sep 13, 2023 at 11:14:46AM +0200, Thomas Hellström wrote: Hi! On Wed, 2023-09-13 at 01:36 +0200, Danilo Krummrich wrote: On Tue, Sep 12, 2023 at 09:23:08PM +0200, Thomas Hellström wrote: On 9/12/23 18:50, Danilo Krummrich wrote: On Tue, Sep 12, 2023 at 06:20:32PM +0200, Thomas Hellström wrote: Hi, Danilo, On 9/9/23 17:31, Danilo Krummrich wrote: So far the DRM GPUVA manager offers common infrastructure to track GPU VA allocations and mappings, generically connect GPU VA mappings to their backing buffers and perform more complex mapping operations on the GPU VA space. However, there are more design patterns commonly used by drivers, which can potentially be generalized in order to make the DRM GPUVA manager represent a basic GPU-VM implementation. In this context, this patch aims at generalizing the following elements. 1) Provide a common dma-resv for GEM objects not being used outside of this GPU-VM. 2) Provide tracking of external GEM objects (GEM objects which are shared with other GPU-VMs). 3) Provide functions to efficiently lock all GEM objects dma- resv the GPU-VM contains mappings of. 4) Provide tracking of evicted GEM objects the GPU-VM contains mappings of, such that validation of evicted GEM objects is accelerated. 5) Provide some convinience functions for common patterns. Rather than being designed as a "framework", the target is to make all features appear as a collection of optional helper functions, such that drivers are free to make use of the DRM GPUVA managers basic functionality and opt-in for other features without setting any feature flags, just by making use of the corresponding functions. Big kudos to Boris Brezillon for his help to figure out locking for drivers updating the GPU VA space within the fence signalling path. Suggested-by: Matthew Brost Signed-off-by: Danilo Krummrich --- drivers/gpu/drm/drm_gpuvm.c | 516 include/drm/drm_gpuvm.h | 197 ++ 2 files changed, 713 insertions(+) diff --git a/drivers/gpu/drm/drm_gpuvm.c b/drivers/gpu/drm/drm_gpuvm.c index f4411047dbb3..8e62a043f719 100644 --- a/drivers/gpu/drm/drm_gpuvm.c +++ b/drivers/gpu/drm/drm_gpuvm.c @@ -73,6 +73,21 @@ * _gem_object list of _gpuvm_bos for an existing instance of this * particular combination. If not existent a new instance is created and linked * to the _gem_object. + * + * _gpuvm_bo structures, since unique for a given _gpuvm, are also used + * as entry for the _gpuvm's lists of external and evicted objects. Those + * list are maintained in order to accelerate locking of dma-resv locks and + * validation of evicted objects bound in a _gpuvm. For instance the all + * _gem_object's _resv of a given _gpuvm can be locked by calling + * drm_gpuvm_exec_lock(). Once locked drivers can call drm_gpuvm_validate() in + * order to validate all evicted _gem_objects. It is also possible to lock + * additional _gem_objects by providing the corresponding parameters to + * drm_gpuvm_exec_lock() as well as open code the _exec loop while making + * use of helper functions such as drm_gpuvm_prepare_range() or + * drm_gpuvm_prepare_objects(). + * + * Every bound _gem_object is treated as external object when its _resv + * structure is different than the _gpuvm's common _resv structure. */ /** @@ -420,6 +435,20 @@ * Subsequent calls to drm_gpuvm_bo_obtain() for the same _gpuvm and * _gem_object must be able to observe previous creations and destructions * of _gpuvm_bos in order to keep instances unique. + * + * The _gpuvm's lists for keeping track of external and evicted objects are + * protected against concurrent insertion / removal and iteration internally. + * + * However, drivers still need ensure to protect concurrent calls to functions + * iterating those lists, such as drm_gpuvm_validate() and + * drm_gpuvm_prepare_objects(). Every such function contains a particular + * comment and lockdep checks if possible. + * + * Functions adding or removing entries from those lists, such as + * drm_gpuvm_bo_evict() or drm_gpuvm_bo_extobj_add() may be called with external + * locks being held, e.g. in order to avoid the corresponding list to be + * (safely) modified while potentially being iternated by other API functions. + * However, this is entirely optional. */ /** @@ -632,6 +661,131 @@ * }
