Re: [PATCH v2] dt-bindings: display: mediatek: Compatible list cleanup
On Thu, Mar 2 2023 at 05:08:30 PM +01:00:00, AngeloGioacchino Del Regno wrote: Il 02/03/23 15:12, Yassine Oudjana ha scritto: From: Yassine Oudjana Several DT bindings of MediaTek display blocks make unnecessary use of "oneOf" and "items". Remove them and replace them with enums where necessary. Signed-off-by: Yassine Oudjana --- Changes since v1: - Leave enums with 1 element as they are. .../bindings/display/mediatek/mediatek,ccorr.yaml | 7 +++ .../bindings/display/mediatek/mediatek,color.yaml | 10 -- .../bindings/display/mediatek/mediatek,dither.yaml | 3 +-- .../bindings/display/mediatek/mediatek,dsc.yaml | 4 +--- .../bindings/display/mediatek/mediatek,gamma.yaml | 7 +++ .../bindings/display/mediatek/mediatek,merge.yaml | 8 +++- .../bindings/display/mediatek/mediatek,od.yaml | 8 +++- .../bindings/display/mediatek/mediatek,ovl-2l.yaml | 7 +++ .../bindings/display/mediatek/mediatek,ovl.yaml | 13 + .../display/mediatek/mediatek,postmask.yaml | 3 +-- .../bindings/display/mediatek/mediatek,rdma.yaml| 13 + .../bindings/display/mediatek/mediatek,split.yaml | 4 +--- .../bindings/display/mediatek/mediatek,ufoe.yaml| 4 +--- .../bindings/display/mediatek/mediatek,wdma.yaml| 4 +--- 14 files changed, 35 insertions(+), 60 deletions(-) diff --git a/Documentation/devicetree/bindings/display/mediatek/mediatek,ccorr.yaml b/Documentation/devicetree/bindings/display/mediatek/mediatek,ccorr.yaml index b04820c95b22..dc22bd522523 100644 --- a/Documentation/devicetree/bindings/display/mediatek/mediatek,ccorr.yaml +++ b/Documentation/devicetree/bindings/display/mediatek/mediatek,ccorr.yaml @@ -21,10 +21,9 @@ description: | properties: compatible: oneOf: - - items: - - const: mediatek,mt8183-disp-ccorr - - items: - - const: mediatek,mt8192-disp-ccorr + - enum: + - mediatek,mt8183-disp-ccorr + - mediatek,mt8192-disp-ccorr This change is ok. - items: - enum: - mediatek,mt8188-disp-ccorr diff --git a/Documentation/devicetree/bindings/display/mediatek/mediatek,color.yaml b/Documentation/devicetree/bindings/display/mediatek/mediatek,color.yaml index 62306c88f485..d0ea77fc4b06 100644 --- a/Documentation/devicetree/bindings/display/mediatek/mediatek,color.yaml +++ b/Documentation/devicetree/bindings/display/mediatek/mediatek,color.yaml @@ -22,12 +22,10 @@ description: | properties: compatible: oneOf: - - items: - - const: mediatek,mt2701-disp-color - - items: - - const: mediatek,mt8167-disp-color - - items: - - const: mediatek,mt8173-disp-color + - enum: + - mediatek,mt2701-disp-color + - mediatek,mt8167-disp-color + - mediatek,mt8173-disp-color OK. - items: - enum: - mediatek,mt7623-disp-color diff --git a/Documentation/devicetree/bindings/display/mediatek/mediatek,dither.yaml b/Documentation/devicetree/bindings/display/mediatek/mediatek,dither.yaml index 5c7445c174e5..9d74de63fe63 100644 --- a/Documentation/devicetree/bindings/display/mediatek/mediatek,dither.yaml +++ b/Documentation/devicetree/bindings/display/mediatek/mediatek,dither.yaml @@ -22,8 +22,7 @@ description: | properties: compatible: oneOf: - - items: - - const: mediatek,mt8183-disp-dither + - const: mediatek,mt8183-disp-dither OK. - items: - enum: - mediatek,mt8186-disp-dither diff --git a/Documentation/devicetree/bindings/display/mediatek/mediatek,dsc.yaml b/Documentation/devicetree/bindings/display/mediatek/mediatek,dsc.yaml index 49248864514b..37bf6bf4a1ab 100644 --- a/Documentation/devicetree/bindings/display/mediatek/mediatek,dsc.yaml +++ b/Documentation/devicetree/bindings/display/mediatek/mediatek,dsc.yaml @@ -19,9 +19,7 @@ description: | properties: compatible: -oneOf: - - items: - - const: mediatek,mt8195-disp-dsc +const: mediatek,mt8195-disp-dsc This will grow, and you'll get devicetree declaring something like: compatible = "mediatek,(different-new-chip)-disp-dsc"; and compatible = "mediatek,(current-chip)-disp-dsc", "mediatek,mt8195-disp-dsc"; Note: Some smartphone SoCs (Dimensity series) do have the same disp-dsc as the Chromebook variant MT8195! :-) reg: maxItems: 1 diff --git a/Documentation/devicetree/bindings/display/mediatek/mediatek,gamma.yaml b/Documentation/devicetree/bindings/display/mediatek/mediatek,gamma.yaml index a5c6a91fac71..6c2be9d6840b 100644 --- a/Documentation/devicetree/bindings/display/mediatek/mediatek,gamma.yaml +++ b/Documentation/devicetree/bindings/display/mediatek/mediatek,gamma.yaml @@ -21,10 +21,9 @@ description: | properties: compatible: oneOf: - - items: - - const:
Re: [PATCH v2] dt-bindings: display: mediatek: Compatible list cleanup
On 02/03/2023 17:08, AngeloGioacchino Del Regno wrote: > Il 02/03/23 15:12, Yassine Oudjana ha scritto: >> From: Yassine Oudjana >> >> Several DT bindings of MediaTek display blocks make unnecessary use of >> "oneOf" and "items". Remove them and replace them with enums where >> necessary. >> diff --git >> a/Documentation/devicetree/bindings/display/mediatek/mediatek,wdma.yaml >> b/Documentation/devicetree/bindings/display/mediatek/mediatek,wdma.yaml >> index 7d7cc1ab526b..52f233fe1c0f 100644 >> --- a/Documentation/devicetree/bindings/display/mediatek/mediatek,wdma.yaml >> +++ b/Documentation/devicetree/bindings/display/mediatek/mediatek,wdma.yaml >> @@ -20,9 +20,7 @@ description: | >> >> properties: >> compatible: >> -oneOf: >> - - items: >> - - const: mediatek,mt8173-disp-wdma >> +const: mediatek,mt8173-disp-wdma >> > > This is present on all MediaTek SoCs - literally. The issue is that the driver > currently does not support command mode panels for real, so this binding is... > ...well, somehow in forgotten-land... > > I would hope that command mode panels get implemented soon(er-than-later), but > I'll leave the choice to you and Krzysztof - I'm only providing the > information > here. :-) Yep, if you predict now that oneOf sooner or later will come back to these, just keep it. Does not hurt much and later re-introducing it makes patch much more difficult to read. Therefore I prefer to have unused oneOf than later a patch which introduces new compatible and re-indents old one (so unneeded diff changes). Best regards, Krzysztof
Re: [PATCH v6] drm/virtio: Add option to disable KMS support
On Thu, Mar 02, 2023 at 03:35:06PM -0800, Rob Clark wrote: > From: Rob Clark > > Add a build option to disable modesetting support. This is useful in > cases where the guest only needs to use the GPU in a headless mode, or > (such as in the CrOS usage) window surfaces are proxied to a host > compositor. > > As the modesetting ioctls are a big surface area for potential security > bugs to be found (it's happened in the past, we should assume it will > again in the future), it makes sense to have a build option to disable > those ioctls in cases where they serve no legitimate purpose. > > v2: Use more if (IS_ENABLED(...)) > v3: Also permit the host to advertise no scanouts > v4: Spiff out commit msg > v5: Make num_scanouts==0 and DRM_VIRTIO_GPU_KMS=n behave the same > v6: Drop conditionally building virtgpu_display.c and early-out of > it's init/fini fxns instead Reviewed-by: Gerd Hoffmann
[PATCH] Change the meaning of the fields in the ttm_place structure from pfn to bytes
Change the ttm_place structure member fpfn, lpfn, mem_type to
res_start, res_end, res_type.
Change the unsigned to u64.
Fix the dependence in all the DRM drivers and
clean up PAGE_SHIFT operation.
Signed-off-by: Somalapuram Amaranath
---
drivers/gpu/drm/amd/amdgpu/amdgpu_gtt_mgr.c | 11 +-
drivers/gpu/drm/amd/amdgpu/amdgpu_object.c| 66 ++--
drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c | 22 ++--
drivers/gpu/drm/amd/amdgpu/amdgpu_uvd.c | 4 +-
drivers/gpu/drm/amd/amdgpu/amdgpu_vce.c | 17 +--
drivers/gpu/drm/amd/amdgpu/amdgpu_vram_mgr.c | 40 ---
drivers/gpu/drm/drm_gem_vram_helper.c | 10 +-
drivers/gpu/drm/i915/gem/i915_gem_ttm.c | 22 ++--
drivers/gpu/drm/i915/gem/i915_gem_ttm_move.c | 2 +-
drivers/gpu/drm/i915/i915_ttm_buddy_manager.c | 102 --
drivers/gpu/drm/i915/i915_ttm_buddy_manager.h | 2 +-
drivers/gpu/drm/i915/intel_region_ttm.c | 12 +--
drivers/gpu/drm/nouveau/nouveau_bo.c | 41 +++
drivers/gpu/drm/nouveau/nouveau_mem.c | 10 +-
drivers/gpu/drm/qxl/qxl_object.c | 14 +--
drivers/gpu/drm/qxl/qxl_ttm.c | 8 +-
drivers/gpu/drm/radeon/radeon_object.c| 50 -
drivers/gpu/drm/radeon/radeon_ttm.c | 20 ++--
drivers/gpu/drm/radeon/radeon_uvd.c | 8 +-
drivers/gpu/drm/ttm/ttm_bo.c | 20 ++--
drivers/gpu/drm/ttm/ttm_range_manager.c | 21 ++--
drivers/gpu/drm/ttm/ttm_resource.c| 8 +-
drivers/gpu/drm/vmwgfx/vmwgfx_bo.c| 46
drivers/gpu/drm/vmwgfx/vmwgfx_ttm_buffer.c| 30 +++---
include/drm/ttm/ttm_placement.h | 12 +--
25 files changed, 293 insertions(+), 305 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_gtt_mgr.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_gtt_mgr.c
index 44367f03316f..5b5104e724e3 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_gtt_mgr.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_gtt_mgr.c
@@ -131,11 +131,12 @@ static int amdgpu_gtt_mgr_new(struct ttm_resource_manager
*man,
goto err_free;
}
- if (place->lpfn) {
+ if (place->res_end) {
spin_lock(>lock);
r = drm_mm_insert_node_in_range(>mm, >mm_nodes[0],
- num_pages, tbo->page_alignment,
- 0, place->fpfn, place->lpfn,
+ num_pages, tbo->page_alignment,
0,
+ place->res_start << PAGE_SHIFT,
+ place->res_end << PAGE_SHIFT,
DRM_MM_INSERT_BEST);
spin_unlock(>lock);
if (unlikely(r))
@@ -219,7 +220,7 @@ static bool amdgpu_gtt_mgr_intersects(struct
ttm_resource_manager *man,
const struct ttm_place *place,
size_t size)
{
- return !place->lpfn || amdgpu_gtt_mgr_has_gart_addr(res);
+ return !place->res_end || amdgpu_gtt_mgr_has_gart_addr(res);
}
/**
@@ -237,7 +238,7 @@ static bool amdgpu_gtt_mgr_compatible(struct
ttm_resource_manager *man,
const struct ttm_place *place,
size_t size)
{
- return !place->lpfn || amdgpu_gtt_mgr_has_gart_addr(res);
+ return !place->res_end || amdgpu_gtt_mgr_has_gart_addr(res);
}
/**
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c
index 283e8fe608ce..2926389e21d4 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c
@@ -130,15 +130,15 @@ void amdgpu_bo_placement_from_domain(struct amdgpu_bo
*abo, u32 domain)
u32 c = 0;
if (domain & AMDGPU_GEM_DOMAIN_VRAM) {
- unsigned visible_pfn = adev->gmc.visible_vram_size >>
PAGE_SHIFT;
+ u64 visible_pfn = adev->gmc.visible_vram_size;
- places[c].fpfn = 0;
- places[c].lpfn = 0;
- places[c].mem_type = TTM_PL_VRAM;
+ places[c].res_start = 0;
+ places[c].res_end = 0;
+ places[c].res_type = TTM_PL_VRAM;
places[c].flags = 0;
if (flags & AMDGPU_GEM_CREATE_CPU_ACCESS_REQUIRED)
- places[c].lpfn = visible_pfn;
+ places[c].res_end = visible_pfn;
else
places[c].flags |= TTM_PL_FLAG_TOPDOWN;
@@ -148,9 +148,9 @@ void amdgpu_bo_placement_from_domain(struct amdgpu_bo *abo,
u32 domain)
}
if (domain & AMDGPU_GEM_DOMAIN_GTT) {
- places[c].fpfn = 0;
- places[c].lpfn = 0;
- places[c].mem_type =
+ places[c].res_start = 0;
+ places[c].res_end =
Re: [PATCH] drm/i915/gvt: Make use of idr_find and idr_for_each_entry in dmabuf
On 2023.03.02 19:53:18 +0800, Cai Huoqing wrote:
> This patch uses the already existing IDR mechanism to simplify
> and improve the dmabuf code.
>
> Using 'vgpu.object_idr' directly instead of 'dmabuf_obj_list_head'
> or 'dmabuf.list', because the dmabuf_obj can be found by 'idr_find'
> or 'idr_for_each_entry'.
>
> Signed-off-by: Cai Huoqing
> ---
> drivers/gpu/drm/i915/gvt/dmabuf.c | 69 +++
> drivers/gpu/drm/i915/gvt/dmabuf.h | 1 -
> drivers/gpu/drm/i915/gvt/gvt.h| 1 -
> drivers/gpu/drm/i915/gvt/vgpu.c | 1 -
> 4 files changed, 16 insertions(+), 56 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/gvt/dmabuf.c
> b/drivers/gpu/drm/i915/gvt/dmabuf.c
> index 6834f9fe40cf..7933bd843ae8 100644
> --- a/drivers/gpu/drm/i915/gvt/dmabuf.c
> +++ b/drivers/gpu/drm/i915/gvt/dmabuf.c
> @@ -133,21 +133,15 @@ static void dmabuf_gem_object_free(struct kref *kref)
> struct intel_vgpu_dmabuf_obj *obj =
> container_of(kref, struct intel_vgpu_dmabuf_obj, kref);
> struct intel_vgpu *vgpu = obj->vgpu;
> - struct list_head *pos;
> struct intel_vgpu_dmabuf_obj *dmabuf_obj;
> + int id;
>
> - if (vgpu && test_bit(INTEL_VGPU_STATUS_ACTIVE, vgpu->status) &&
> - !list_empty(>dmabuf_obj_list_head)) {
> - list_for_each(pos, >dmabuf_obj_list_head) {
> - dmabuf_obj = list_entry(pos, struct
> intel_vgpu_dmabuf_obj, list);
> - if (dmabuf_obj == obj) {
> - list_del(pos);
> - idr_remove(>object_idr,
> -dmabuf_obj->dmabuf_id);
> - kfree(dmabuf_obj->info);
> - kfree(dmabuf_obj);
> - break;
> - }
> + if (vgpu && test_bit(INTEL_VGPU_STATUS_ACTIVE, vgpu->status)) {
> + idr_for_each_entry(>object_idr, dmabuf_obj, id) {
> + idr_remove(>object_idr, id);
> + kfree(dmabuf_obj->info);
> + kfree(dmabuf_obj);
This is wrong, it is not to free all dmabuf objects, but just for target one.
> + break;
> }
> } else {
> /* Free the orphan dmabuf_objs here */
> @@ -340,13 +334,11 @@ static struct intel_vgpu_dmabuf_obj *
> pick_dmabuf_by_info(struct intel_vgpu *vgpu,
> struct intel_vgpu_fb_info *latest_info)
> {
> - struct list_head *pos;
> struct intel_vgpu_fb_info *fb_info;
> struct intel_vgpu_dmabuf_obj *dmabuf_obj = NULL;
> - struct intel_vgpu_dmabuf_obj *ret = NULL;
> + int id;
>
> - list_for_each(pos, >dmabuf_obj_list_head) {
> - dmabuf_obj = list_entry(pos, struct intel_vgpu_dmabuf_obj,
> list);
> + idr_for_each_entry(>object_idr, dmabuf_obj, id) {
> if (!dmabuf_obj->info)
> continue;
>
> @@ -357,31 +349,11 @@ pick_dmabuf_by_info(struct intel_vgpu *vgpu,
> (fb_info->drm_format_mod == latest_info->drm_format_mod) &&
> (fb_info->drm_format == latest_info->drm_format) &&
> (fb_info->width == latest_info->width) &&
> - (fb_info->height == latest_info->height)) {
> - ret = dmabuf_obj;
> - break;
> - }
Maybe just keep original code's use of extra ret to not include this cumbersome
diff?
> - }
> -
> - return ret;
> -}
> -
> -static struct intel_vgpu_dmabuf_obj *
> -pick_dmabuf_by_num(struct intel_vgpu *vgpu, u32 id)
> -{
> - struct list_head *pos;
> - struct intel_vgpu_dmabuf_obj *dmabuf_obj = NULL;
> - struct intel_vgpu_dmabuf_obj *ret = NULL;
> -
> - list_for_each(pos, >dmabuf_obj_list_head) {
> - dmabuf_obj = list_entry(pos, struct intel_vgpu_dmabuf_obj,
> list);
> - if (dmabuf_obj->dmabuf_id == id) {
> - ret = dmabuf_obj;
> - break;
> - }
> + (fb_info->height == latest_info->height))
> + return dmabuf_obj;
> }
>
> - return ret;
> + return dmabuf_obj;
> }
>
> static void update_fb_info(struct vfio_device_gfx_plane_info *gvt_dmabuf,
> @@ -477,11 +449,6 @@ int intel_vgpu_query_plane(struct intel_vgpu *vgpu, void
> *args)
>
> update_fb_info(gfx_plane_info, _info);
>
> - INIT_LIST_HEAD(_obj->list);
> - mutex_lock(>dmabuf_lock);
> - list_add_tail(_obj->list, >dmabuf_obj_list_head);
> - mutex_unlock(>dmabuf_lock);
> -
> gvt_dbg_dpy("vgpu%d: %s new dmabuf_obj ref %d, id %d\n", vgpu->id,
> __func__, kref_read(_obj->kref), ret);
>
> @@ -508,7 +475,7 @@ int intel_vgpu_get_dmabuf(struct intel_vgpu *vgpu,
> unsigned int dmabuf_id)
>
> mutex_lock(>dmabuf_lock);
>
> - dmabuf_obj = pick_dmabuf_by_num(vgpu, dmabuf_id);
> + dmabuf_obj =
[PATCH v2 5/7] drm/i915/display: Fill in native_420 field
Now that we have laid the groundwork for YUV420 Enablement
we fill up native_420 field in vdsc_cfg and add appropriate
checks wherever required.
---v2
-adding native_422 field as 0 [Vandita]
-filling in second_line_bpg_offset, second_line_offset_adj
and nsl_bpg_offset in vds_cfg when native_420 is true
---v3
-adding display version check to solve igt issue
--v7
-remove is_pipe_dsc check as its always true for D14 [Jani]
--v10
-keep sink capability check [Jani]
-move from !(x == y || w == z) to x !=y && w != z [Jani]
--v11
-avoid native_420 computation if not gen14 [Uma]
--v12
-fix state mismatch issue of compressed_bpp
Cc: Uma Shankar
Cc: Jani Nikula
Signed-off-by: Suraj Kandpal
---
drivers/gpu/drm/i915/display/icl_dsi.c| 2 -
drivers/gpu/drm/i915/display/intel_dp.c | 16 +++-
drivers/gpu/drm/i915/display/intel_vdsc.c | 98 ---
3 files changed, 100 insertions(+), 16 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/icl_dsi.c
b/drivers/gpu/drm/i915/display/icl_dsi.c
index b5316715bb3b..fb7efab8e9e6 100644
--- a/drivers/gpu/drm/i915/display/icl_dsi.c
+++ b/drivers/gpu/drm/i915/display/icl_dsi.c
@@ -1539,8 +1539,6 @@ static int gen11_dsi_dsc_compute_config(struct
intel_encoder *encoder,
if (crtc_state->dsc.slice_count > 1)
crtc_state->dsc.dsc_split = true;
- vdsc_cfg->convert_rgb = true;
-
/* FIXME: initialize from VBT */
vdsc_cfg->rc_model_size = DSC_RC_MODEL_SIZE_CONST;
diff --git a/drivers/gpu/drm/i915/display/intel_dp.c
b/drivers/gpu/drm/i915/display/intel_dp.c
index 2649e8b8ef57..86b9348b74bb 100644
--- a/drivers/gpu/drm/i915/display/intel_dp.c
+++ b/drivers/gpu/drm/i915/display/intel_dp.c
@@ -1467,9 +1467,10 @@ static int intel_dp_dsc_compute_params(struct
intel_encoder *encoder,
vdsc_cfg->dsc_version_minor =
min(intel_dp_source_dsc_version_minor(intel_dp),
intel_dp_sink_dsc_version_minor(intel_dp));
-
- vdsc_cfg->convert_rgb = intel_dp->dsc_dpcd[DP_DSC_DEC_COLOR_FORMAT_CAP
- DP_DSC_SUPPORT] &
- DP_DSC_RGB;
+ if (vdsc_cfg->convert_rgb)
+ vdsc_cfg->convert_rgb =
+ intel_dp->dsc_dpcd[DP_DSC_DEC_COLOR_FORMAT_CAP -
DP_DSC_SUPPORT] &
+ DP_DSC_RGB;
line_buf_depth = drm_dp_dsc_sink_line_buf_depth(intel_dp->dsc_dpcd);
if (!line_buf_depth) {
@@ -1587,6 +1588,15 @@ int intel_dp_dsc_compute_config(struct intel_dp
*intel_dp,
pipe_config->bigjoiner_pipes,
pipe_bpp,
timeslots);
+ /*
+* According to DSC 1.2a Section 4.1.1 Table 4.1 the
maximum
+* supported PPS value can be 63.9375 and with the
further
+* mention that bpp should be programmed double the
target bpp
+* restricting our target bpp to be 31.9375 at max
+*/
+ if (pipe_config->output_format ==
INTEL_OUTPUT_FORMAT_YCBCR420)
+ dsc_max_output_bpp = min_t(u16,
dsc_max_output_bpp, 31 << 4);
+
if (!dsc_max_output_bpp) {
drm_dbg_kms(_priv->drm,
"Compressed BPP not supported\n");
diff --git a/drivers/gpu/drm/i915/display/intel_vdsc.c
b/drivers/gpu/drm/i915/display/intel_vdsc.c
index ed16f63d6355..44243fc81b46 100644
--- a/drivers/gpu/drm/i915/display/intel_vdsc.c
+++ b/drivers/gpu/drm/i915/display/intel_vdsc.c
@@ -460,14 +460,50 @@ int intel_dsc_compute_params(struct intel_crtc_state
*pipe_config)
vdsc_cfg->pic_width = pipe_config->hw.adjusted_mode.crtc_hdisplay;
vdsc_cfg->slice_width = DIV_ROUND_UP(vdsc_cfg->pic_width,
pipe_config->dsc.slice_count);
-
- /* Gen 11 does not support YCbCr */
+ /*
+* According to DSC 1.2 specs if colorspace is YCbCr then convert_rgb
is 0
+* else 1
+*/
+ vdsc_cfg->convert_rgb = pipe_config->output_format !=
INTEL_OUTPUT_FORMAT_YCBCR420 &&
+ pipe_config->output_format !=
INTEL_OUTPUT_FORMAT_YCBCR444;
+
+ if (DISPLAY_VER(dev_priv) >= 14 &&
+ pipe_config->output_format == INTEL_OUTPUT_FORMAT_YCBCR420)
+ vdsc_cfg->native_420 = true;
+ /* We do not support YcBCr422 as of now */
+ vdsc_cfg->native_422 = false;
vdsc_cfg->simple_422 = false;
/* Gen 11 does not support VBR */
vdsc_cfg->vbr_enable = false;
/* Gen 11 only supports integral values of bpp */
vdsc_cfg->bits_per_pixel = compressed_bpp << 4;
+
+ /*
+* According to DSC 1.2 specs in Section 4.1 if native_420 is set:
+* -We need to
Re: [PATCH v9 15/15] drm/i915: Add deadline based boost support
On Thu, Mar 02, 2023 at 03:53:37PM -0800, Rob Clark wrote:
> From: Rob Clark
>
missing some wording here...
> v2: rebase
>
> Signed-off-by: Rob Clark
> ---
> drivers/gpu/drm/i915/i915_request.c | 20
> 1 file changed, 20 insertions(+)
>
> diff --git a/drivers/gpu/drm/i915/i915_request.c
> b/drivers/gpu/drm/i915/i915_request.c
> index 7503dcb9043b..44491e7e214c 100644
> --- a/drivers/gpu/drm/i915/i915_request.c
> +++ b/drivers/gpu/drm/i915/i915_request.c
> @@ -97,6 +97,25 @@ static bool i915_fence_enable_signaling(struct dma_fence
> *fence)
> return i915_request_enable_breadcrumb(to_request(fence));
> }
>
> +static void i915_fence_set_deadline(struct dma_fence *fence, ktime_t
> deadline)
> +{
> + struct i915_request *rq = to_request(fence);
> +
> + if (i915_request_completed(rq))
> + return;
> +
> + if (i915_request_started(rq))
> + return;
why do we skip the boost if already started?
don't we want to boost the freq anyway?
> +
> + /*
> + * TODO something more clever for deadlines that are in the
> + * future. I think probably track the nearest deadline in
> + * rq->timeline and set timer to trigger boost accordingly?
> + */
I'm afraid it will be very hard to find some heuristics of what's
late enough for the boost no?
I mean, how early to boost the freq on an upcoming deadline for the
timer?
> +
> + intel_rps_boost(rq);
> +}
> +
> static signed long i915_fence_wait(struct dma_fence *fence,
> bool interruptible,
> signed long timeout)
> @@ -182,6 +201,7 @@ const struct dma_fence_ops i915_fence_ops = {
> .signaled = i915_fence_signaled,
> .wait = i915_fence_wait,
> .release = i915_fence_release,
> + .set_deadline = i915_fence_set_deadline,
> };
>
> static void irq_execute_cb(struct irq_work *wrk)
> --
> 2.39.1
>
Re: [PATCH v6 3/8] drm/i915/pxp: Add MTL helpers to submit Heci-Cmd-Packet to GSC
On Mon, 2023-02-27 at 18:21 -0800, Teres Alexis, Alan Previn wrote:
> Add helper functions into a new file for heci-packet-submission.
> The helpers will handle generating the MTL GSC-CS Memory-Header
> and submission of the Heci-Cmd-Packet instructions to the engine.
>
>
alan:snip
> +int
> +intel_gsc_uc_heci_cmd_submit_nonpriv(struct intel_gsc_uc *gsc,
> + struct intel_context *ce,
> + struct intel_gsc_heci_non_priv_pkt *pkt,
> + u32 *cmd, int timeout_ms)
> +{
> + struct intel_engine_cs *eng;
> + struct i915_request *rq;
> + int err;
> +
> + rq = intel_context_create_request(ce);
> + if (IS_ERR(rq))
> + return PTR_ERR(rq);
> +
> + emit_gsc_heci_pkt_nonpriv(cmd, pkt);
> +
> + i915_vma_lock(pkt->bb_vma);
> + err = i915_vma_move_to_active(pkt->bb_vma, rq, EXEC_OBJECT_WRITE);
> + i915_vma_unlock(pkt->bb_vma);
> + if (err)
> + goto out_rq;
> +
alan:
depending on timing (appears to be a racy trigger event), in <5% of the time
when I tested this internally,
I am seeing lockdep issues when running live_selftests(gt_timelines) followed
by a PXP teardown at pxp-fini.
The lockdep kernel logs point to the sequence of calling
"intel_context_create_request" followed by
i915_vma_lock/move_to_active/i915_vma_unlock for the objects (and how the
internal ww-locks vs timeline-locks are taken)
Internal discussions realize that i really shouldnt be using these function
call sequences and should instead
follow what our workaround batch buffers do:
(the following is the current fix proposal from internal discussions, but i
still need to do more testing +
debug before i re-rev but i wanted to put this review comment first so the
follow-up action is not lost)
i915_gem_ww_ctx_init(, false);
i915_gem_object_lock(pkt->bb_vma->obj, );
intel_context_pin_ww(ce, );
i915_request_create(ce);
i915_vma_move_to_active(pkt->bb_vma, rq, EXEC_OBJECT_WRITE);
submit (breadcrumbs, init-bb, flush...)
i915_request_get/add/put(rq);
intel_context_unpin(ce);
i915_gem_ww_ctx_fini();
alan:snip
[PATCH v9 12/15] drm/msm: Add deadline based boost support
From: Rob Clark
Track the nearest deadline on a fence timeline and set a timer to expire
shortly before to trigger boost if the fence has not yet been signaled.
v2: rebase
Signed-off-by: Rob Clark
---
drivers/gpu/drm/msm/msm_fence.c | 74 +
drivers/gpu/drm/msm/msm_fence.h | 20 +
2 files changed, 94 insertions(+)
diff --git a/drivers/gpu/drm/msm/msm_fence.c b/drivers/gpu/drm/msm/msm_fence.c
index 56641408ea74..51b461f32103 100644
--- a/drivers/gpu/drm/msm/msm_fence.c
+++ b/drivers/gpu/drm/msm/msm_fence.c
@@ -8,6 +8,35 @@
#include "msm_drv.h"
#include "msm_fence.h"
+#include "msm_gpu.h"
+
+static struct msm_gpu *fctx2gpu(struct msm_fence_context *fctx)
+{
+ struct msm_drm_private *priv = fctx->dev->dev_private;
+ return priv->gpu;
+}
+
+static enum hrtimer_restart deadline_timer(struct hrtimer *t)
+{
+ struct msm_fence_context *fctx = container_of(t,
+ struct msm_fence_context, deadline_timer);
+
+ kthread_queue_work(fctx2gpu(fctx)->worker, >deadline_work);
+
+ return HRTIMER_NORESTART;
+}
+
+static void deadline_work(struct kthread_work *work)
+{
+ struct msm_fence_context *fctx = container_of(work,
+ struct msm_fence_context, deadline_work);
+
+ /* If deadline fence has already passed, nothing to do: */
+ if (msm_fence_completed(fctx, fctx->next_deadline_fence))
+ return;
+
+ msm_devfreq_boost(fctx2gpu(fctx), 2);
+}
struct msm_fence_context *
@@ -36,6 +65,13 @@ msm_fence_context_alloc(struct drm_device *dev, volatile
uint32_t *fenceptr,
fctx->completed_fence = fctx->last_fence;
*fctx->fenceptr = fctx->last_fence;
+ hrtimer_init(>deadline_timer, CLOCK_MONOTONIC, HRTIMER_MODE_ABS);
+ fctx->deadline_timer.function = deadline_timer;
+
+ kthread_init_work(>deadline_work, deadline_work);
+
+ fctx->next_deadline = ktime_get();
+
return fctx;
}
@@ -62,6 +98,8 @@ void msm_update_fence(struct msm_fence_context *fctx,
uint32_t fence)
spin_lock_irqsave(>spinlock, flags);
if (fence_after(fence, fctx->completed_fence))
fctx->completed_fence = fence;
+ if (msm_fence_completed(fctx, fctx->next_deadline_fence))
+ hrtimer_cancel(>deadline_timer);
spin_unlock_irqrestore(>spinlock, flags);
}
@@ -92,10 +130,46 @@ static bool msm_fence_signaled(struct dma_fence *fence)
return msm_fence_completed(f->fctx, f->base.seqno);
}
+static void msm_fence_set_deadline(struct dma_fence *fence, ktime_t deadline)
+{
+ struct msm_fence *f = to_msm_fence(fence);
+ struct msm_fence_context *fctx = f->fctx;
+ unsigned long flags;
+ ktime_t now;
+
+ spin_lock_irqsave(>spinlock, flags);
+ now = ktime_get();
+
+ if (ktime_after(now, fctx->next_deadline) ||
+ ktime_before(deadline, fctx->next_deadline)) {
+ fctx->next_deadline = deadline;
+ fctx->next_deadline_fence =
+ max(fctx->next_deadline_fence, (uint32_t)fence->seqno);
+
+ /*
+* Set timer to trigger boost 3ms before deadline, or
+* if we are already less than 3ms before the deadline
+* schedule boost work immediately.
+*/
+ deadline = ktime_sub(deadline, ms_to_ktime(3));
+
+ if (ktime_after(now, deadline)) {
+ kthread_queue_work(fctx2gpu(fctx)->worker,
+ >deadline_work);
+ } else {
+ hrtimer_start(>deadline_timer, deadline,
+ HRTIMER_MODE_ABS);
+ }
+ }
+
+ spin_unlock_irqrestore(>spinlock, flags);
+}
+
static const struct dma_fence_ops msm_fence_ops = {
.get_driver_name = msm_fence_get_driver_name,
.get_timeline_name = msm_fence_get_timeline_name,
.signaled = msm_fence_signaled,
+ .set_deadline = msm_fence_set_deadline,
};
struct dma_fence *
diff --git a/drivers/gpu/drm/msm/msm_fence.h b/drivers/gpu/drm/msm/msm_fence.h
index 7f1798c54cd1..cdaebfb94f5c 100644
--- a/drivers/gpu/drm/msm/msm_fence.h
+++ b/drivers/gpu/drm/msm/msm_fence.h
@@ -52,6 +52,26 @@ struct msm_fence_context {
volatile uint32_t *fenceptr;
spinlock_t spinlock;
+
+ /*
+* TODO this doesn't really deal with multiple deadlines, like
+* if userspace got multiple frames ahead.. OTOH atomic updates
+* don't queue, so maybe that is ok
+*/
+
+ /** next_deadline: Time of next deadline */
+ ktime_t next_deadline;
+
+ /**
+* next_deadline_fence:
+*
+* Fence value for next pending deadline. The deadline timer is
+* canceled when this fence is signaled.
+*/
+ uint32_t next_deadline_fence;
+
+ struct hrtimer
[PATCH v9 15/15] drm/i915: Add deadline based boost support
From: Rob Clark
v2: rebase
Signed-off-by: Rob Clark
---
drivers/gpu/drm/i915/i915_request.c | 20
1 file changed, 20 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915_request.c
b/drivers/gpu/drm/i915/i915_request.c
index 7503dcb9043b..44491e7e214c 100644
--- a/drivers/gpu/drm/i915/i915_request.c
+++ b/drivers/gpu/drm/i915/i915_request.c
@@ -97,6 +97,25 @@ static bool i915_fence_enable_signaling(struct dma_fence
*fence)
return i915_request_enable_breadcrumb(to_request(fence));
}
+static void i915_fence_set_deadline(struct dma_fence *fence, ktime_t deadline)
+{
+ struct i915_request *rq = to_request(fence);
+
+ if (i915_request_completed(rq))
+ return;
+
+ if (i915_request_started(rq))
+ return;
+
+ /*
+* TODO something more clever for deadlines that are in the
+* future. I think probably track the nearest deadline in
+* rq->timeline and set timer to trigger boost accordingly?
+*/
+
+ intel_rps_boost(rq);
+}
+
static signed long i915_fence_wait(struct dma_fence *fence,
bool interruptible,
signed long timeout)
@@ -182,6 +201,7 @@ const struct dma_fence_ops i915_fence_ops = {
.signaled = i915_fence_signaled,
.wait = i915_fence_wait,
.release = i915_fence_release,
+ .set_deadline = i915_fence_set_deadline,
};
static void irq_execute_cb(struct irq_work *wrk)
--
2.39.1
[PATCH v9 14/15] drm/msm/atomic: Switch to vblank_start helper
From: Rob Clark
Drop our custom thing and switch to drm_crtc_next_vblank_start() for
calculating the time of the start of the next vblank period.
Signed-off-by: Rob Clark
---
drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c | 15 ---
drivers/gpu/drm/msm/msm_atomic.c| 8 +---
drivers/gpu/drm/msm/msm_kms.h | 8
3 files changed, 5 insertions(+), 26 deletions(-)
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c
b/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c
index a683bd9b5a04..43996aecaf8c 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c
@@ -411,20 +411,6 @@ static void dpu_kms_disable_commit(struct msm_kms *kms)
pm_runtime_put_sync(_kms->pdev->dev);
}
-static ktime_t dpu_kms_vsync_time(struct msm_kms *kms, struct drm_crtc *crtc)
-{
- struct drm_encoder *encoder;
-
- drm_for_each_encoder_mask(encoder, crtc->dev,
crtc->state->encoder_mask) {
- ktime_t vsync_time;
-
- if (dpu_encoder_vsync_time(encoder, _time) == 0)
- return vsync_time;
- }
-
- return ktime_get();
-}
-
static void dpu_kms_prepare_commit(struct msm_kms *kms,
struct drm_atomic_state *state)
{
@@ -953,7 +939,6 @@ static const struct msm_kms_funcs kms_funcs = {
.irq = dpu_core_irq,
.enable_commit = dpu_kms_enable_commit,
.disable_commit = dpu_kms_disable_commit,
- .vsync_time = dpu_kms_vsync_time,
.prepare_commit = dpu_kms_prepare_commit,
.flush_commit= dpu_kms_flush_commit,
.wait_flush = dpu_kms_wait_flush,
diff --git a/drivers/gpu/drm/msm/msm_atomic.c b/drivers/gpu/drm/msm/msm_atomic.c
index 1686fbb611fd..c5e71c05f038 100644
--- a/drivers/gpu/drm/msm/msm_atomic.c
+++ b/drivers/gpu/drm/msm/msm_atomic.c
@@ -186,8 +186,7 @@ void msm_atomic_commit_tail(struct drm_atomic_state *state)
struct msm_kms *kms = priv->kms;
struct drm_crtc *async_crtc = NULL;
unsigned crtc_mask = get_crtc_mask(state);
- bool async = kms->funcs->vsync_time &&
- can_do_async(state, _crtc);
+ bool async = can_do_async(state, _crtc);
trace_msm_atomic_commit_tail_start(async, crtc_mask);
@@ -231,7 +230,9 @@ void msm_atomic_commit_tail(struct drm_atomic_state *state)
kms->pending_crtc_mask |= crtc_mask;
- vsync_time = kms->funcs->vsync_time(kms, async_crtc);
+ if (drm_crtc_next_vblank_start(async_crtc, _time))
+ goto fallback;
+
wakeup_time = ktime_sub(vsync_time, ms_to_ktime(1));
msm_hrtimer_queue_work(>work, wakeup_time,
@@ -253,6 +254,7 @@ void msm_atomic_commit_tail(struct drm_atomic_state *state)
return;
}
+fallback:
/*
* If there is any async flush pending on updated crtcs, fold
* them into the current flush.
diff --git a/drivers/gpu/drm/msm/msm_kms.h b/drivers/gpu/drm/msm/msm_kms.h
index f8ed7588928c..086a3f1ff956 100644
--- a/drivers/gpu/drm/msm/msm_kms.h
+++ b/drivers/gpu/drm/msm/msm_kms.h
@@ -59,14 +59,6 @@ struct msm_kms_funcs {
void (*enable_commit)(struct msm_kms *kms);
void (*disable_commit)(struct msm_kms *kms);
- /**
-* If the kms backend supports async commit, it should implement
-* this method to return the time of the next vsync. This is
-* used to determine a time slightly before vsync, for the async
-* commit timer to run and complete an async commit.
-*/
- ktime_t (*vsync_time)(struct msm_kms *kms, struct drm_crtc *crtc);
-
/**
* Prepare for atomic commit. This is called after any previous
* (async or otherwise) commit has completed.
--
2.39.1
[PATCH v9 13/15] drm/msm: Add wait-boost support
From: Rob Clark
Add a way for various userspace waits to signal urgency.
Signed-off-by: Rob Clark
---
drivers/gpu/drm/msm/msm_drv.c | 12
drivers/gpu/drm/msm/msm_gem.c | 5 +
include/uapi/drm/msm_drm.h| 14 --
3 files changed, 25 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/msm/msm_drv.c b/drivers/gpu/drm/msm/msm_drv.c
index aca48c868c14..f6764a86b2da 100644
--- a/drivers/gpu/drm/msm/msm_drv.c
+++ b/drivers/gpu/drm/msm/msm_drv.c
@@ -46,6 +46,7 @@
* - 1.8.0 - Add MSM_BO_CACHED_COHERENT for supported GPUs (a6xx)
* - 1.9.0 - Add MSM_SUBMIT_FENCE_SN_IN
* - 1.10.0 - Add MSM_SUBMIT_BO_NO_IMPLICIT
+ * - 1.11.0 - Add wait boost (MSM_WAIT_FENCE_BOOST, MSM_PREP_BOOST)
*/
#define MSM_VERSION_MAJOR 1
#define MSM_VERSION_MINOR 10
@@ -899,7 +900,7 @@ static int msm_ioctl_gem_info(struct drm_device *dev, void
*data,
}
static int wait_fence(struct msm_gpu_submitqueue *queue, uint32_t fence_id,
- ktime_t timeout)
+ ktime_t timeout, uint32_t flags)
{
struct dma_fence *fence;
int ret;
@@ -929,6 +930,9 @@ static int wait_fence(struct msm_gpu_submitqueue *queue,
uint32_t fence_id,
if (!fence)
return 0;
+ if (flags & MSM_WAIT_FENCE_BOOST)
+ dma_fence_set_deadline(fence, ktime_get());
+
ret = dma_fence_wait_timeout(fence, true, timeout_to_jiffies());
if (ret == 0) {
ret = -ETIMEDOUT;
@@ -949,8 +953,8 @@ static int msm_ioctl_wait_fence(struct drm_device *dev,
void *data,
struct msm_gpu_submitqueue *queue;
int ret;
- if (args->pad) {
- DRM_ERROR("invalid pad: %08x\n", args->pad);
+ if (args->flags & ~MSM_WAIT_FENCE_FLAGS) {
+ DRM_ERROR("invalid flags: %08x\n", args->flags);
return -EINVAL;
}
@@ -961,7 +965,7 @@ static int msm_ioctl_wait_fence(struct drm_device *dev,
void *data,
if (!queue)
return -ENOENT;
- ret = wait_fence(queue, args->fence, to_ktime(args->timeout));
+ ret = wait_fence(queue, args->fence, to_ktime(args->timeout),
args->flags);
msm_submitqueue_put(queue);
diff --git a/drivers/gpu/drm/msm/msm_gem.c b/drivers/gpu/drm/msm/msm_gem.c
index 1dee0d18abbb..dd4a0d773f6e 100644
--- a/drivers/gpu/drm/msm/msm_gem.c
+++ b/drivers/gpu/drm/msm/msm_gem.c
@@ -846,6 +846,11 @@ int msm_gem_cpu_prep(struct drm_gem_object *obj, uint32_t
op, ktime_t *timeout)
op & MSM_PREP_NOSYNC ? 0 : timeout_to_jiffies(timeout);
long ret;
+ if (op & MSM_PREP_BOOST) {
+ dma_resv_set_deadline(obj->resv, dma_resv_usage_rw(write),
+ ktime_get());
+ }
+
ret = dma_resv_wait_timeout(obj->resv, dma_resv_usage_rw(write),
true, remain);
if (ret == 0)
diff --git a/include/uapi/drm/msm_drm.h b/include/uapi/drm/msm_drm.h
index 329100016e7c..dbf0d6f43fa9 100644
--- a/include/uapi/drm/msm_drm.h
+++ b/include/uapi/drm/msm_drm.h
@@ -151,8 +151,13 @@ struct drm_msm_gem_info {
#define MSM_PREP_READ0x01
#define MSM_PREP_WRITE 0x02
#define MSM_PREP_NOSYNC 0x04
+#define MSM_PREP_BOOST 0x08
-#define MSM_PREP_FLAGS (MSM_PREP_READ | MSM_PREP_WRITE | MSM_PREP_NOSYNC)
+#define MSM_PREP_FLAGS (MSM_PREP_READ | \
+ MSM_PREP_WRITE | \
+ MSM_PREP_NOSYNC | \
+ MSM_PREP_BOOST | \
+ 0)
struct drm_msm_gem_cpu_prep {
__u32 handle; /* in */
@@ -286,6 +291,11 @@ struct drm_msm_gem_submit {
};
+#define MSM_WAIT_FENCE_BOOST 0x0001
+#define MSM_WAIT_FENCE_FLAGS ( \
+ MSM_WAIT_FENCE_BOOST | \
+ 0)
+
/* The normal way to synchronize with the GPU is just to CPU_PREP on
* a buffer if you need to access it from the CPU (other cmdstream
* submission from same or other contexts, PAGE_FLIP ioctl, etc, all
@@ -295,7 +305,7 @@ struct drm_msm_gem_submit {
*/
struct drm_msm_wait_fence {
__u32 fence; /* in */
- __u32 pad;
+ __u32 flags; /* in, bitmask of MSM_WAIT_FENCE_x */
struct drm_msm_timespec timeout; /* in */
__u32 queueid; /* in, submitqueue id */
};
--
2.39.1
[PATCH v9 10/15] drm/vblank: Add helper to get next vblank time
From: Rob Clark
Will be used in the next commit to set a deadline on fences that an
atomic update is waiting on.
v2: Calculate time at *start* of vblank period, not end
v3: Fix kbuild complaints
Signed-off-by: Rob Clark
Reviewed-by: Mario Kleiner
---
drivers/gpu/drm/drm_vblank.c | 53 ++--
include/drm/drm_vblank.h | 1 +
2 files changed, 45 insertions(+), 9 deletions(-)
diff --git a/drivers/gpu/drm/drm_vblank.c b/drivers/gpu/drm/drm_vblank.c
index 2ff31717a3de..299fa2a19a90 100644
--- a/drivers/gpu/drm/drm_vblank.c
+++ b/drivers/gpu/drm/drm_vblank.c
@@ -844,10 +844,9 @@ bool drm_crtc_vblank_helper_get_vblank_timestamp(struct
drm_crtc *crtc,
EXPORT_SYMBOL(drm_crtc_vblank_helper_get_vblank_timestamp);
/**
- * drm_get_last_vbltimestamp - retrieve raw timestamp for the most recent
- * vblank interval
- * @dev: DRM device
- * @pipe: index of CRTC whose vblank timestamp to retrieve
+ * drm_crtc_get_last_vbltimestamp - retrieve raw timestamp for the most
+ * recent vblank interval
+ * @crtc: CRTC whose vblank timestamp to retrieve
* @tvblank: Pointer to target time which should receive the timestamp
* @in_vblank_irq:
* True when called from drm_crtc_handle_vblank(). Some drivers
@@ -865,10 +864,9 @@ EXPORT_SYMBOL(drm_crtc_vblank_helper_get_vblank_timestamp);
* True if timestamp is considered to be very precise, false otherwise.
*/
static bool
-drm_get_last_vbltimestamp(struct drm_device *dev, unsigned int pipe,
- ktime_t *tvblank, bool in_vblank_irq)
+drm_crtc_get_last_vbltimestamp(struct drm_crtc *crtc, ktime_t *tvblank,
+ bool in_vblank_irq)
{
- struct drm_crtc *crtc = drm_crtc_from_index(dev, pipe);
bool ret = false;
/* Define requested maximum error on timestamps (nanoseconds). */
@@ -876,8 +874,6 @@ drm_get_last_vbltimestamp(struct drm_device *dev, unsigned
int pipe,
/* Query driver if possible and precision timestamping enabled. */
if (crtc && crtc->funcs->get_vblank_timestamp && max_error > 0) {
- struct drm_crtc *crtc = drm_crtc_from_index(dev, pipe);
-
ret = crtc->funcs->get_vblank_timestamp(crtc, _error,
tvblank, in_vblank_irq);
}
@@ -891,6 +887,15 @@ drm_get_last_vbltimestamp(struct drm_device *dev, unsigned
int pipe,
return ret;
}
+static bool
+drm_get_last_vbltimestamp(struct drm_device *dev, unsigned int pipe,
+ ktime_t *tvblank, bool in_vblank_irq)
+{
+ struct drm_crtc *crtc = drm_crtc_from_index(dev, pipe);
+
+ return drm_crtc_get_last_vbltimestamp(crtc, tvblank, in_vblank_irq);
+}
+
/**
* drm_crtc_vblank_count - retrieve "cooked" vblank counter value
* @crtc: which counter to retrieve
@@ -980,6 +985,36 @@ u64 drm_crtc_vblank_count_and_time(struct drm_crtc *crtc,
}
EXPORT_SYMBOL(drm_crtc_vblank_count_and_time);
+/**
+ * drm_crtc_next_vblank_start - calculate the time of the next vblank
+ * @crtc: the crtc for which to calculate next vblank time
+ * @vblanktime: pointer to time to receive the next vblank timestamp.
+ *
+ * Calculate the expected time of the start of the next vblank period,
+ * based on time of previous vblank and frame duration
+ */
+int drm_crtc_next_vblank_start(struct drm_crtc *crtc, ktime_t *vblanktime)
+{
+ unsigned int pipe = drm_crtc_index(crtc);
+ struct drm_vblank_crtc *vblank = >dev->vblank[pipe];
+ struct drm_display_mode *mode = >hwmode;
+ u64 vblank_start;
+
+ if (!vblank->framedur_ns || !vblank->linedur_ns)
+ return -EINVAL;
+
+ if (!drm_crtc_get_last_vbltimestamp(crtc, vblanktime, false))
+ return -EINVAL;
+
+ vblank_start = DIV_ROUND_DOWN_ULL(
+ (u64)vblank->framedur_ns * mode->crtc_vblank_start,
+ mode->crtc_vtotal);
+ *vblanktime = ktime_add(*vblanktime, ns_to_ktime(vblank_start));
+
+ return 0;
+}
+EXPORT_SYMBOL(drm_crtc_next_vblank_start);
+
static void send_vblank_event(struct drm_device *dev,
struct drm_pending_vblank_event *e,
u64 seq, ktime_t now)
diff --git a/include/drm/drm_vblank.h b/include/drm/drm_vblank.h
index 733a3e2d1d10..7f3957943dd1 100644
--- a/include/drm/drm_vblank.h
+++ b/include/drm/drm_vblank.h
@@ -230,6 +230,7 @@ bool drm_dev_has_vblank(const struct drm_device *dev);
u64 drm_crtc_vblank_count(struct drm_crtc *crtc);
u64 drm_crtc_vblank_count_and_time(struct drm_crtc *crtc,
ktime_t *vblanktime);
+int drm_crtc_next_vblank_start(struct drm_crtc *crtc, ktime_t *vblanktime);
void drm_crtc_send_vblank_event(struct drm_crtc *crtc,
struct drm_pending_vblank_event *e);
void drm_crtc_arm_vblank_event(struct drm_crtc *crtc,
--
2.39.1
[PATCH v9 11/15] drm/atomic-helper: Set fence deadline for vblank
From: Rob Clark
For an atomic commit updating a single CRTC (ie. a pageflip) calculate
the next vblank time, and inform the fence(s) of that deadline.
v2: Comment typo fix (danvet)
Signed-off-by: Rob Clark
Reviewed-by: Daniel Vetter
Signed-off-by: Rob Clark
---
drivers/gpu/drm/drm_atomic_helper.c | 36 +
1 file changed, 36 insertions(+)
diff --git a/drivers/gpu/drm/drm_atomic_helper.c
b/drivers/gpu/drm/drm_atomic_helper.c
index d579fd8f7cb8..d8ee98ce2fc5 100644
--- a/drivers/gpu/drm/drm_atomic_helper.c
+++ b/drivers/gpu/drm/drm_atomic_helper.c
@@ -1511,6 +1511,40 @@ void drm_atomic_helper_commit_modeset_enables(struct
drm_device *dev,
}
EXPORT_SYMBOL(drm_atomic_helper_commit_modeset_enables);
+/*
+ * For atomic updates which touch just a single CRTC, calculate the time of the
+ * next vblank, and inform all the fences of the deadline.
+ */
+static void set_fence_deadline(struct drm_device *dev,
+ struct drm_atomic_state *state)
+{
+ struct drm_crtc *crtc, *wait_crtc = NULL;
+ struct drm_crtc_state *new_crtc_state;
+ struct drm_plane *plane;
+ struct drm_plane_state *new_plane_state;
+ ktime_t vbltime;
+ int i;
+
+ for_each_new_crtc_in_state (state, crtc, new_crtc_state, i) {
+ if (wait_crtc)
+ return;
+ wait_crtc = crtc;
+ }
+
+ /* If no CRTCs updated, then nothing to do: */
+ if (!wait_crtc)
+ return;
+
+ if (drm_crtc_next_vblank_start(wait_crtc, ))
+ return;
+
+ for_each_new_plane_in_state (state, plane, new_plane_state, i) {
+ if (!new_plane_state->fence)
+ continue;
+ dma_fence_set_deadline(new_plane_state->fence, vbltime);
+ }
+}
+
/**
* drm_atomic_helper_wait_for_fences - wait for fences stashed in plane state
* @dev: DRM device
@@ -1540,6 +1574,8 @@ int drm_atomic_helper_wait_for_fences(struct drm_device
*dev,
struct drm_plane_state *new_plane_state;
int i, ret;
+ set_fence_deadline(dev, state);
+
for_each_new_plane_in_state(state, plane, new_plane_state, i) {
if (!new_plane_state->fence)
continue;
--
2.39.1
[PATCH v9 09/15] drm/syncobj: Add deadline support for syncobj waits
From: Rob Clark
Add a new flag to let userspace provide a deadline as a hint for syncobj
and timeline waits. This gives a hint to the driver signaling the
backing fences about how soon userspace needs it to compete work, so it
can addjust GPU frequency accordingly. An immediate deadline can be
given to provide something equivalent to i915 "wait boost".
v2: Use absolute u64 ns value for deadline hint, drop cap and driver
feature flag in favor of allowing count_handles==0 as a way for
userspace to probe kernel for support of new flag
v3: More verbose comments about UAPI
Signed-off-by: Rob Clark
---
drivers/gpu/drm/drm_syncobj.c | 64 ---
include/uapi/drm/drm.h| 17 ++
2 files changed, 68 insertions(+), 13 deletions(-)
diff --git a/drivers/gpu/drm/drm_syncobj.c b/drivers/gpu/drm/drm_syncobj.c
index 0c2be8360525..a85e9464f07b 100644
--- a/drivers/gpu/drm/drm_syncobj.c
+++ b/drivers/gpu/drm/drm_syncobj.c
@@ -126,6 +126,11 @@
* synchronize between the two.
* This requirement is inherited from the Vulkan fence API.
*
+ * If _SYNCOBJ_WAIT_FLAGS_WAIT_DEADLINE is set, the ioctl will also set
+ * a fence deadline hint on the backing fences before waiting, to provide the
+ * fence signaler with an appropriate sense of urgency. The deadline is
+ * specified as an absolute _MONOTONIC value in units of ns.
+ *
* Similarly, _IOCTL_SYNCOBJ_TIMELINE_WAIT takes an array of syncobj
* handles as well as an array of u64 points and does a host-side wait on all
* of syncobj fences at the given points simultaneously.
@@ -973,7 +978,8 @@ static signed long drm_syncobj_array_wait_timeout(struct
drm_syncobj **syncobjs,
uint32_t count,
uint32_t flags,
signed long timeout,
- uint32_t *idx)
+ uint32_t *idx,
+ ktime_t *deadline)
{
struct syncobj_wait_entry *entries;
struct dma_fence *fence;
@@ -1053,6 +1059,15 @@ static signed long drm_syncobj_array_wait_timeout(struct
drm_syncobj **syncobjs,
drm_syncobj_fence_add_wait(syncobjs[i], [i]);
}
+ if (deadline) {
+ for (i = 0; i < count; ++i) {
+ fence = entries[i].fence;
+ if (!fence)
+ continue;
+ dma_fence_set_deadline(fence, *deadline);
+ }
+ }
+
do {
set_current_state(TASK_INTERRUPTIBLE);
@@ -1151,7 +1166,8 @@ static int drm_syncobj_array_wait(struct drm_device *dev,
struct drm_file *file_private,
struct drm_syncobj_wait *wait,
struct drm_syncobj_timeline_wait
*timeline_wait,
- struct drm_syncobj **syncobjs, bool timeline)
+ struct drm_syncobj **syncobjs, bool timeline,
+ ktime_t *deadline)
{
signed long timeout = 0;
uint32_t first = ~0;
@@ -1162,7 +1178,8 @@ static int drm_syncobj_array_wait(struct drm_device *dev,
NULL,
wait->count_handles,
wait->flags,
-timeout, );
+timeout, ,
+deadline);
if (timeout < 0)
return timeout;
wait->first_signaled = first;
@@ -1172,7 +1189,8 @@ static int drm_syncobj_array_wait(struct drm_device *dev,
u64_to_user_ptr(timeline_wait->points),
timeline_wait->count_handles,
timeline_wait->flags,
-timeout, );
+timeout, ,
+deadline);
if (timeout < 0)
return timeout;
timeline_wait->first_signaled = first;
@@ -1243,17 +1261,22 @@ drm_syncobj_wait_ioctl(struct drm_device *dev, void
*data,
{
struct drm_syncobj_wait *args = data;
struct drm_syncobj **syncobjs;
+ unsigned possible_flags;
+ ktime_t t, *tp = NULL;
int ret = 0;
if (!drm_core_check_feature(dev, DRIVER_SYNCOBJ))
return -EOPNOTSUPP;
- if (args->flags &
[PATCH v9 08/15] drm/scheduler: Add fence deadline support
As the finished fence is the one that is exposed to userspace, and
therefore the one that other operations, like atomic update, would
block on, we need to propagate the deadline from from the finished
fence to the actual hw fence.
v2: Split into drm_sched_fence_set_parent() (ckoenig)
v3: Ensure a thread calling drm_sched_fence_set_deadline_finished() sees
fence->parent set before drm_sched_fence_set_parent() does this
test_bit(DMA_FENCE_FLAG_HAS_DEADLINE_BIT).
Signed-off-by: Rob Clark
Acked-by: Luben Tuikov
---
drivers/gpu/drm/scheduler/sched_fence.c | 46 +
drivers/gpu/drm/scheduler/sched_main.c | 2 +-
include/drm/gpu_scheduler.h | 17 +
3 files changed, 64 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/scheduler/sched_fence.c
b/drivers/gpu/drm/scheduler/sched_fence.c
index 7fd869520ef2..fe9c6468e440 100644
--- a/drivers/gpu/drm/scheduler/sched_fence.c
+++ b/drivers/gpu/drm/scheduler/sched_fence.c
@@ -123,6 +123,37 @@ static void drm_sched_fence_release_finished(struct
dma_fence *f)
dma_fence_put(>scheduled);
}
+static void drm_sched_fence_set_deadline_finished(struct dma_fence *f,
+ ktime_t deadline)
+{
+ struct drm_sched_fence *fence = to_drm_sched_fence(f);
+ struct dma_fence *parent;
+ unsigned long flags;
+
+ spin_lock_irqsave(>lock, flags);
+
+ /* If we already have an earlier deadline, keep it: */
+ if (test_bit(DRM_SCHED_FENCE_FLAG_HAS_DEADLINE_BIT, >flags) &&
+ ktime_before(fence->deadline, deadline)) {
+ spin_unlock_irqrestore(>lock, flags);
+ return;
+ }
+
+ fence->deadline = deadline;
+ set_bit(DRM_SCHED_FENCE_FLAG_HAS_DEADLINE_BIT, >flags);
+
+ spin_unlock_irqrestore(>lock, flags);
+
+ /*
+* smp_load_aquire() to ensure that if we are racing another
+* thread calling drm_sched_fence_set_parent(), that we see
+* the parent set before it calls test_bit(HAS_DEADLINE_BIT)
+*/
+ parent = smp_load_acquire(>parent);
+ if (parent)
+ dma_fence_set_deadline(parent, deadline);
+}
+
static const struct dma_fence_ops drm_sched_fence_ops_scheduled = {
.get_driver_name = drm_sched_fence_get_driver_name,
.get_timeline_name = drm_sched_fence_get_timeline_name,
@@ -133,6 +164,7 @@ static const struct dma_fence_ops
drm_sched_fence_ops_finished = {
.get_driver_name = drm_sched_fence_get_driver_name,
.get_timeline_name = drm_sched_fence_get_timeline_name,
.release = drm_sched_fence_release_finished,
+ .set_deadline = drm_sched_fence_set_deadline_finished,
};
struct drm_sched_fence *to_drm_sched_fence(struct dma_fence *f)
@@ -147,6 +179,20 @@ struct drm_sched_fence *to_drm_sched_fence(struct
dma_fence *f)
}
EXPORT_SYMBOL(to_drm_sched_fence);
+void drm_sched_fence_set_parent(struct drm_sched_fence *s_fence,
+ struct dma_fence *fence)
+{
+ /*
+* smp_store_release() to ensure another thread racing us
+* in drm_sched_fence_set_deadline_finished() sees the
+* fence's parent set before test_bit()
+*/
+ smp_store_release(_fence->parent, dma_fence_get(fence));
+ if (test_bit(DRM_SCHED_FENCE_FLAG_HAS_DEADLINE_BIT,
+_fence->finished.flags))
+ dma_fence_set_deadline(fence, s_fence->deadline);
+}
+
struct drm_sched_fence *drm_sched_fence_alloc(struct drm_sched_entity *entity,
void *owner)
{
diff --git a/drivers/gpu/drm/scheduler/sched_main.c
b/drivers/gpu/drm/scheduler/sched_main.c
index 4e6ad6e122bc..007f98c48f8d 100644
--- a/drivers/gpu/drm/scheduler/sched_main.c
+++ b/drivers/gpu/drm/scheduler/sched_main.c
@@ -1019,7 +1019,7 @@ static int drm_sched_main(void *param)
drm_sched_fence_scheduled(s_fence);
if (!IS_ERR_OR_NULL(fence)) {
- s_fence->parent = dma_fence_get(fence);
+ drm_sched_fence_set_parent(s_fence, fence);
/* Drop for original kref_init of the fence */
dma_fence_put(fence);
diff --git a/include/drm/gpu_scheduler.h b/include/drm/gpu_scheduler.h
index 9db9e5e504ee..99584e457153 100644
--- a/include/drm/gpu_scheduler.h
+++ b/include/drm/gpu_scheduler.h
@@ -41,6 +41,15 @@
*/
#define DRM_SCHED_FENCE_DONT_PIPELINE DMA_FENCE_FLAG_USER_BITS
+/**
+ * DRM_SCHED_FENCE_FLAG_HAS_DEADLINE_BIT - A fence deadline hint has been set
+ *
+ * Because we could have a deadline hint can be set before the backing hw
+ * fence is created, we need to keep track of whether a deadline has already
+ * been set.
+ */
+#define DRM_SCHED_FENCE_FLAG_HAS_DEADLINE_BIT (DMA_FENCE_FLAG_USER_BITS + 1)
+
enum dma_resv_usage;
struct dma_resv;
struct drm_gem_object;
@@ -280,6 +289,12 @@ struct drm_sched_fence {
[PATCH v9 07/15] dma-buf/sw_sync: Add fence deadline support
From: Rob Clark
This consists of simply storing the most recent deadline, and adding an
ioctl to retrieve the deadline. This can be used in conjunction with
the SET_DEADLINE ioctl on a fence fd for testing. Ie. create various
sw_sync fences, merge them into a fence-array, set deadline on the
fence-array and confirm that it is propagated properly to each fence.
v2: Switch UABI to express deadline as u64
v3: More verbose UAPI docs, show how to convert from timespec
v4: Better comments, track the soonest deadline, as a normal fence
implementation would, return an error if no deadline set.
Signed-off-by: Rob Clark
Reviewed-by: Christian König
Acked-by: Pekka Paalanen
---
drivers/dma-buf/sw_sync.c| 81
drivers/dma-buf/sync_debug.h | 2 +
2 files changed, 83 insertions(+)
diff --git a/drivers/dma-buf/sw_sync.c b/drivers/dma-buf/sw_sync.c
index 348b3a9170fa..f53071bca3af 100644
--- a/drivers/dma-buf/sw_sync.c
+++ b/drivers/dma-buf/sw_sync.c
@@ -52,12 +52,33 @@ struct sw_sync_create_fence_data {
__s32 fence; /* fd of new fence */
};
+/**
+ * struct sw_sync_get_deadline - get the deadline hint of a sw_sync fence
+ * @deadline_ns: absolute time of the deadline
+ * @pad: must be zero
+ * @fence_fd: the sw_sync fence fd (in)
+ *
+ * Return the earliest deadline set on the fence. The timebase for the
+ * deadline is CLOCK_MONOTONIC (same as vblank). If there is no deadline
+ * set on the fence, this ioctl will return -ENOENT.
+ */
+struct sw_sync_get_deadline {
+ __u64 deadline_ns;
+ __u32 pad;
+ __s32 fence_fd;
+};
+
#define SW_SYNC_IOC_MAGIC 'W'
#define SW_SYNC_IOC_CREATE_FENCE _IOWR(SW_SYNC_IOC_MAGIC, 0,\
struct sw_sync_create_fence_data)
#define SW_SYNC_IOC_INC_IOW(SW_SYNC_IOC_MAGIC, 1,
__u32)
+#define SW_SYNC_GET_DEADLINE _IOWR(SW_SYNC_IOC_MAGIC, 2, \
+ struct sw_sync_get_deadline)
+
+
+#define SW_SYNC_HAS_DEADLINE_BIT DMA_FENCE_FLAG_USER_BITS
static const struct dma_fence_ops timeline_fence_ops;
@@ -171,6 +192,22 @@ static void timeline_fence_timeline_value_str(struct
dma_fence *fence,
snprintf(str, size, "%d", parent->value);
}
+static void timeline_fence_set_deadline(struct dma_fence *fence, ktime_t
deadline)
+{
+ struct sync_pt *pt = dma_fence_to_sync_pt(fence);
+ unsigned long flags;
+
+ spin_lock_irqsave(fence->lock, flags);
+ if (test_bit(SW_SYNC_HAS_DEADLINE_BIT, >flags)) {
+ if (ktime_before(deadline, pt->deadline))
+ pt->deadline = deadline;
+ } else {
+ pt->deadline = deadline;
+ set_bit(SW_SYNC_HAS_DEADLINE_BIT, >flags);
+ }
+ spin_unlock_irqrestore(fence->lock, flags);
+}
+
static const struct dma_fence_ops timeline_fence_ops = {
.get_driver_name = timeline_fence_get_driver_name,
.get_timeline_name = timeline_fence_get_timeline_name,
@@ -179,6 +216,7 @@ static const struct dma_fence_ops timeline_fence_ops = {
.release = timeline_fence_release,
.fence_value_str = timeline_fence_value_str,
.timeline_value_str = timeline_fence_timeline_value_str,
+ .set_deadline = timeline_fence_set_deadline,
};
/**
@@ -387,6 +425,46 @@ static long sw_sync_ioctl_inc(struct sync_timeline *obj,
unsigned long arg)
return 0;
}
+static int sw_sync_ioctl_get_deadline(struct sync_timeline *obj, unsigned long
arg)
+{
+ struct sw_sync_get_deadline data;
+ struct dma_fence *fence;
+ struct sync_pt *pt;
+ int ret = 0;
+
+ if (copy_from_user(, (void __user *)arg, sizeof(data)))
+ return -EFAULT;
+
+ if (data.deadline_ns || data.pad)
+ return -EINVAL;
+
+ fence = sync_file_get_fence(data.fence_fd);
+ if (!fence)
+ return -EINVAL;
+
+ pt = dma_fence_to_sync_pt(fence);
+ if (!pt)
+ return -EINVAL;
+
+ spin_lock(fence->lock);
+ if (test_bit(SW_SYNC_HAS_DEADLINE_BIT, >flags)) {
+ data.deadline_ns = ktime_to_ns(pt->deadline);
+ } else {
+ ret = -ENOENT;
+ }
+ spin_unlock(fence->lock);
+
+ dma_fence_put(fence);
+
+ if (ret)
+ return ret;
+
+ if (copy_to_user((void __user *)arg, , sizeof(data)))
+ return -EFAULT;
+
+ return 0;
+}
+
static long sw_sync_ioctl(struct file *file, unsigned int cmd,
unsigned long arg)
{
@@ -399,6 +477,9 @@ static long sw_sync_ioctl(struct file *file, unsigned int
cmd,
case SW_SYNC_IOC_INC:
return sw_sync_ioctl_inc(obj, arg);
+ case SW_SYNC_GET_DEADLINE:
+ return sw_sync_ioctl_get_deadline(obj, arg);
+
default:
return -ENOTTY;
}
diff --git a/drivers/dma-buf/sync_debug.h b/drivers/dma-buf/sync_debug.h
index
[PATCH v9 06/15] dma-buf/sync_file: Add SET_DEADLINE ioctl
From: Rob Clark
The initial purpose is for igt tests, but this would also be useful for
compositors that wait until close to vblank deadline to make decisions
about which frame to show.
The igt tests can be found at:
https://gitlab.freedesktop.org/robclark/igt-gpu-tools/-/commits/fence-deadline
v2: Clarify the timebase, add link to igt tests
v3: Use u64 value in ns to express deadline.
v4: More doc
Signed-off-by: Rob Clark
Acked-by: Pekka Paalanen
---
drivers/dma-buf/dma-fence.c| 3 ++-
drivers/dma-buf/sync_file.c| 19 +++
include/uapi/linux/sync_file.h | 22 ++
3 files changed, 43 insertions(+), 1 deletion(-)
diff --git a/drivers/dma-buf/dma-fence.c b/drivers/dma-buf/dma-fence.c
index f177c56269bb..74e36f6d05b0 100644
--- a/drivers/dma-buf/dma-fence.c
+++ b/drivers/dma-buf/dma-fence.c
@@ -933,7 +933,8 @@ EXPORT_SYMBOL(dma_fence_wait_any_timeout);
* the GPU's devfreq to reduce frequency, when in fact the opposite is what
is
* needed.
*
- * To this end, deadline hint(s) can be set on a _fence via
_fence_set_deadline.
+ * To this end, deadline hint(s) can be set on a _fence via
_fence_set_deadline
+ * (or indirectly via userspace facing ioctls like _set_deadline).
* The deadline hint provides a way for the waiting driver, or userspace, to
* convey an appropriate sense of urgency to the signaling driver.
*
diff --git a/drivers/dma-buf/sync_file.c b/drivers/dma-buf/sync_file.c
index af57799c86ce..418021cfb87c 100644
--- a/drivers/dma-buf/sync_file.c
+++ b/drivers/dma-buf/sync_file.c
@@ -350,6 +350,22 @@ static long sync_file_ioctl_fence_info(struct sync_file
*sync_file,
return ret;
}
+static int sync_file_ioctl_set_deadline(struct sync_file *sync_file,
+ unsigned long arg)
+{
+ struct sync_set_deadline ts;
+
+ if (copy_from_user(, (void __user *)arg, sizeof(ts)))
+ return -EFAULT;
+
+ if (ts.pad)
+ return -EINVAL;
+
+ dma_fence_set_deadline(sync_file->fence, ns_to_ktime(ts.deadline_ns));
+
+ return 0;
+}
+
static long sync_file_ioctl(struct file *file, unsigned int cmd,
unsigned long arg)
{
@@ -362,6 +378,9 @@ static long sync_file_ioctl(struct file *file, unsigned int
cmd,
case SYNC_IOC_FILE_INFO:
return sync_file_ioctl_fence_info(sync_file, arg);
+ case SYNC_IOC_SET_DEADLINE:
+ return sync_file_ioctl_set_deadline(sync_file, arg);
+
default:
return -ENOTTY;
}
diff --git a/include/uapi/linux/sync_file.h b/include/uapi/linux/sync_file.h
index 7e42a5b7558b..d61752dca4c6 100644
--- a/include/uapi/linux/sync_file.h
+++ b/include/uapi/linux/sync_file.h
@@ -76,6 +76,27 @@ struct sync_file_info {
__u64 sync_fence_info;
};
+/**
+ * struct sync_set_deadline - SYNC_IOC_SET_DEADLINE - set a deadline hint on a
fence
+ * @deadline_ns: absolute time of the deadline
+ * @pad: must be zero
+ *
+ * Allows userspace to set a deadline on a fence, see _fence_set_deadline
+ *
+ * The timebase for the deadline is CLOCK_MONOTONIC (same as vblank). For
+ * example
+ *
+ * clock_gettime(CLOCK_MONOTONIC, );
+ * deadline_ns = (t.tv_sec * 10L) + t.tv_nsec + ns_until_deadline
+ */
+struct sync_set_deadline {
+ __u64 deadline_ns;
+ /* Not strictly needed for alignment but gives some possibility
+* for future extension:
+*/
+ __u64 pad;
+};
+
#define SYNC_IOC_MAGIC '>'
/*
@@ -87,5 +108,6 @@ struct sync_file_info {
#define SYNC_IOC_MERGE _IOWR(SYNC_IOC_MAGIC, 3, struct sync_merge_data)
#define SYNC_IOC_FILE_INFO _IOWR(SYNC_IOC_MAGIC, 4, struct sync_file_info)
+#define SYNC_IOC_SET_DEADLINE _IOW(SYNC_IOC_MAGIC, 5, struct
sync_set_deadline)
#endif /* _UAPI_LINUX_SYNC_H */
--
2.39.1
[PATCH v9 05/15] dma-buf/sync_file: Surface sync-file uABI
From: Rob Clark
We had all of the internal driver APIs, but not the all important
userspace uABI, in the dma-buf doc. Fix that. And re-arrange the
comments slightly as otherwise the comments for the ioctl nr defines
would not show up.
v2: Fix docs build warning coming from newly including the uabi header
in the docs build
Signed-off-by: Rob Clark
Acked-by: Pekka Paalanen
---
Documentation/driver-api/dma-buf.rst | 10 ++--
include/uapi/linux/sync_file.h | 37 +++-
2 files changed, 23 insertions(+), 24 deletions(-)
diff --git a/Documentation/driver-api/dma-buf.rst
b/Documentation/driver-api/dma-buf.rst
index 183e480d8cea..ff3f8da296af 100644
--- a/Documentation/driver-api/dma-buf.rst
+++ b/Documentation/driver-api/dma-buf.rst
@@ -203,8 +203,8 @@ DMA Fence unwrap
.. kernel-doc:: include/linux/dma-fence-unwrap.h
:internal:
-DMA Fence uABI/Sync File
-
+DMA Fence Sync File
+~~~
.. kernel-doc:: drivers/dma-buf/sync_file.c
:export:
@@ -212,6 +212,12 @@ DMA Fence uABI/Sync File
.. kernel-doc:: include/linux/sync_file.h
:internal:
+DMA Fence Sync File uABI
+
+
+.. kernel-doc:: include/uapi/linux/sync_file.h
+ :internal:
+
Indefinite DMA Fences
~
diff --git a/include/uapi/linux/sync_file.h b/include/uapi/linux/sync_file.h
index ee2dcfb3d660..7e42a5b7558b 100644
--- a/include/uapi/linux/sync_file.h
+++ b/include/uapi/linux/sync_file.h
@@ -16,12 +16,16 @@
#include
/**
- * struct sync_merge_data - data passed to merge ioctl
+ * struct sync_merge_data - SYNC_IOC_MERGE: merge two fences
* @name: name of new fence
* @fd2: file descriptor of second fence
* @fence: returns the fd of the new fence to userspace
* @flags: merge_data flags
* @pad: padding for 64-bit alignment, should always be zero
+ *
+ * Creates a new fence containing copies of the sync_pts in both
+ * the calling fd and sync_merge_data.fd2. Returns the new fence's
+ * fd in sync_merge_data.fence
*/
struct sync_merge_data {
charname[32];
@@ -34,8 +38,8 @@ struct sync_merge_data {
/**
* struct sync_fence_info - detailed fence information
* @obj_name: name of parent sync_timeline
-* @driver_name:name of driver implementing the parent
-* @status: status of the fence 0:active 1:signaled <0:error
+ * @driver_name: name of driver implementing the parent
+ * @status:status of the fence 0:active 1:signaled <0:error
* @flags: fence_info flags
* @timestamp_ns: timestamp of status change in nanoseconds
*/
@@ -48,14 +52,19 @@ struct sync_fence_info {
};
/**
- * struct sync_file_info - data returned from fence info ioctl
+ * struct sync_file_info - SYNC_IOC_FILE_INFO: get detailed information on a
sync_file
* @name: name of fence
* @status:status of fence. 1: signaled 0:active <0:error
* @flags: sync_file_info flags
* @num_fences number of fences in the sync_file
* @pad: padding for 64-bit alignment, should always be zero
- * @sync_fence_info: pointer to array of structs sync_fence_info with all
+ * @sync_fence_info: pointer to array of struct _fence_info with all
* fences in the sync_file
+ *
+ * Takes a struct sync_file_info. If num_fences is 0, the field is updated
+ * with the actual number of fences. If num_fences is > 0, the system will
+ * use the pointer provided on sync_fence_info to return up to num_fences of
+ * struct sync_fence_info, with detailed fence information.
*/
struct sync_file_info {
charname[32];
@@ -69,30 +78,14 @@ struct sync_file_info {
#define SYNC_IOC_MAGIC '>'
-/**
+/*
* Opcodes 0, 1 and 2 were burned during a API change to avoid users of the
* old API to get weird errors when trying to handling sync_files. The API
* change happened during the de-stage of the Sync Framework when there was
* no upstream users available.
*/
-/**
- * DOC: SYNC_IOC_MERGE - merge two fences
- *
- * Takes a struct sync_merge_data. Creates a new fence containing copies of
- * the sync_pts in both the calling fd and sync_merge_data.fd2. Returns the
- * new fence's fd in sync_merge_data.fence
- */
#define SYNC_IOC_MERGE _IOWR(SYNC_IOC_MAGIC, 3, struct sync_merge_data)
-
-/**
- * DOC: SYNC_IOC_FILE_INFO - get detailed information on a sync_file
- *
- * Takes a struct sync_file_info. If num_fences is 0, the field is updated
- * with the actual number of fences. If num_fences is > 0, the system will
- * use the pointer provided on sync_fence_info to return up to num_fences of
- * struct sync_fence_info, with detailed fence information.
- */
#define SYNC_IOC_FILE_INFO _IOWR(SYNC_IOC_MAGIC, 4, struct sync_file_info)
#endif /* _UAPI_LINUX_SYNC_H */
--
2.39.1
[PATCH v9 04/15] dma-buf/dma-resv: Add a way to set fence deadline
From: Rob Clark
Add a way to set a deadline on remaining resv fences according to the
requested usage.
Signed-off-by: Rob Clark
Reviewed-by: Christian König
---
drivers/dma-buf/dma-resv.c | 22 ++
include/linux/dma-resv.h | 2 ++
2 files changed, 24 insertions(+)
diff --git a/drivers/dma-buf/dma-resv.c b/drivers/dma-buf/dma-resv.c
index 1c76aed8e262..2a594b754af1 100644
--- a/drivers/dma-buf/dma-resv.c
+++ b/drivers/dma-buf/dma-resv.c
@@ -684,6 +684,28 @@ long dma_resv_wait_timeout(struct dma_resv *obj, enum
dma_resv_usage usage,
}
EXPORT_SYMBOL_GPL(dma_resv_wait_timeout);
+/**
+ * dma_resv_set_deadline - Set a deadline on reservation's objects fences
+ * @obj: the reservation object
+ * @usage: controls which fences to include, see enum dma_resv_usage.
+ * @deadline: the requested deadline (MONOTONIC)
+ *
+ * May be called without holding the dma_resv lock. Sets @deadline on
+ * all fences filtered by @usage.
+ */
+void dma_resv_set_deadline(struct dma_resv *obj, enum dma_resv_usage usage,
+ ktime_t deadline)
+{
+ struct dma_resv_iter cursor;
+ struct dma_fence *fence;
+
+ dma_resv_iter_begin(, obj, usage);
+ dma_resv_for_each_fence_unlocked(, fence) {
+ dma_fence_set_deadline(fence, deadline);
+ }
+ dma_resv_iter_end();
+}
+EXPORT_SYMBOL_GPL(dma_resv_set_deadline);
/**
* dma_resv_test_signaled - Test if a reservation object's fences have been
diff --git a/include/linux/dma-resv.h b/include/linux/dma-resv.h
index 0637659a702c..8d0e34dad446 100644
--- a/include/linux/dma-resv.h
+++ b/include/linux/dma-resv.h
@@ -479,6 +479,8 @@ int dma_resv_get_singleton(struct dma_resv *obj, enum
dma_resv_usage usage,
int dma_resv_copy_fences(struct dma_resv *dst, struct dma_resv *src);
long dma_resv_wait_timeout(struct dma_resv *obj, enum dma_resv_usage usage,
bool intr, unsigned long timeout);
+void dma_resv_set_deadline(struct dma_resv *obj, enum dma_resv_usage usage,
+ ktime_t deadline);
bool dma_resv_test_signaled(struct dma_resv *obj, enum dma_resv_usage usage);
void dma_resv_describe(struct dma_resv *obj, struct seq_file *seq);
--
2.39.1
[PATCH v9 03/15] dma-buf/fence-chain: Add fence deadline support
From: Rob Clark
Propagate the deadline to all the fences in the chain.
v2: Use dma_fence_chain_contained [Tvrtko]
Signed-off-by: Rob Clark
Reviewed-by: Christian König for this one.
---
drivers/dma-buf/dma-fence-chain.c | 12
1 file changed, 12 insertions(+)
diff --git a/drivers/dma-buf/dma-fence-chain.c
b/drivers/dma-buf/dma-fence-chain.c
index a0d920576ba6..9663ba1bb6ac 100644
--- a/drivers/dma-buf/dma-fence-chain.c
+++ b/drivers/dma-buf/dma-fence-chain.c
@@ -206,6 +206,17 @@ static void dma_fence_chain_release(struct dma_fence
*fence)
dma_fence_free(fence);
}
+
+static void dma_fence_chain_set_deadline(struct dma_fence *fence,
+ktime_t deadline)
+{
+ dma_fence_chain_for_each(fence, fence) {
+ struct dma_fence *f = dma_fence_chain_contained(fence);
+
+ dma_fence_set_deadline(f, deadline);
+ }
+}
+
const struct dma_fence_ops dma_fence_chain_ops = {
.use_64bit_seqno = true,
.get_driver_name = dma_fence_chain_get_driver_name,
@@ -213,6 +224,7 @@ const struct dma_fence_ops dma_fence_chain_ops = {
.enable_signaling = dma_fence_chain_enable_signaling,
.signaled = dma_fence_chain_signaled,
.release = dma_fence_chain_release,
+ .set_deadline = dma_fence_chain_set_deadline,
};
EXPORT_SYMBOL(dma_fence_chain_ops);
--
2.39.1
[PATCH v9 02/15] dma-buf/fence-array: Add fence deadline support
From: Rob Clark
Propagate the deadline to all the fences in the array.
Signed-off-by: Rob Clark
Reviewed-by: Christian König
---
drivers/dma-buf/dma-fence-array.c | 11 +++
1 file changed, 11 insertions(+)
diff --git a/drivers/dma-buf/dma-fence-array.c
b/drivers/dma-buf/dma-fence-array.c
index 5c8a7084577b..9b3ce8948351 100644
--- a/drivers/dma-buf/dma-fence-array.c
+++ b/drivers/dma-buf/dma-fence-array.c
@@ -123,12 +123,23 @@ static void dma_fence_array_release(struct dma_fence
*fence)
dma_fence_free(fence);
}
+static void dma_fence_array_set_deadline(struct dma_fence *fence,
+ktime_t deadline)
+{
+ struct dma_fence_array *array = to_dma_fence_array(fence);
+ unsigned i;
+
+ for (i = 0; i < array->num_fences; ++i)
+ dma_fence_set_deadline(array->fences[i], deadline);
+}
+
const struct dma_fence_ops dma_fence_array_ops = {
.get_driver_name = dma_fence_array_get_driver_name,
.get_timeline_name = dma_fence_array_get_timeline_name,
.enable_signaling = dma_fence_array_enable_signaling,
.signaled = dma_fence_array_signaled,
.release = dma_fence_array_release,
+ .set_deadline = dma_fence_array_set_deadline,
};
EXPORT_SYMBOL(dma_fence_array_ops);
--
2.39.1
[PATCH v9 01/15] dma-buf/dma-fence: Add deadline awareness
From: Rob Clark
Add a way to hint to the fence signaler of an upcoming deadline, such as
vblank, which the fence waiter would prefer not to miss. This is to aid
the fence signaler in making power management decisions, like boosting
frequency as the deadline approaches and awareness of missing deadlines
so that can be factored in to the frequency scaling.
v2: Drop dma_fence::deadline and related logic to filter duplicate
deadlines, to avoid increasing dma_fence size. The fence-context
implementation will need similar logic to track deadlines of all
the fences on the same timeline. [ckoenig]
v3: Clarify locking wrt. set_deadline callback
v4: Clarify in docs comment that this is a hint
v5: Drop DMA_FENCE_FLAG_HAS_DEADLINE_BIT.
v6: More docs
v7: Fix typo, clarify past deadlines
Signed-off-by: Rob Clark
Reviewed-by: Christian König
Acked-by: Pekka Paalanen
Reviewed-by: Bagas Sanjaya
---
Documentation/driver-api/dma-buf.rst | 6 +++
drivers/dma-buf/dma-fence.c | 59
include/linux/dma-fence.h| 22 +++
3 files changed, 87 insertions(+)
diff --git a/Documentation/driver-api/dma-buf.rst
b/Documentation/driver-api/dma-buf.rst
index 622b8156d212..183e480d8cea 100644
--- a/Documentation/driver-api/dma-buf.rst
+++ b/Documentation/driver-api/dma-buf.rst
@@ -164,6 +164,12 @@ DMA Fence Signalling Annotations
.. kernel-doc:: drivers/dma-buf/dma-fence.c
:doc: fence signalling annotation
+DMA Fence Deadline Hints
+
+
+.. kernel-doc:: drivers/dma-buf/dma-fence.c
+ :doc: deadline hints
+
DMA Fences Functions Reference
~~
diff --git a/drivers/dma-buf/dma-fence.c b/drivers/dma-buf/dma-fence.c
index 0de0482cd36e..f177c56269bb 100644
--- a/drivers/dma-buf/dma-fence.c
+++ b/drivers/dma-buf/dma-fence.c
@@ -912,6 +912,65 @@ dma_fence_wait_any_timeout(struct dma_fence **fences,
uint32_t count,
}
EXPORT_SYMBOL(dma_fence_wait_any_timeout);
+/**
+ * DOC: deadline hints
+ *
+ * In an ideal world, it would be possible to pipeline a workload sufficiently
+ * that a utilization based device frequency governor could arrive at a minimum
+ * frequency that meets the requirements of the use-case, in order to minimize
+ * power consumption. But in the real world there are many workloads which
+ * defy this ideal. For example, but not limited to:
+ *
+ * * Workloads that ping-pong between device and CPU, with alternating periods
+ * of CPU waiting for device, and device waiting on CPU. This can result in
+ * devfreq and cpufreq seeing idle time in their respective domains and in
+ * result reduce frequency.
+ *
+ * * Workloads that interact with a periodic time based deadline, such as
double
+ * buffered GPU rendering vs vblank sync'd page flipping. In this scenario,
+ * missing a vblank deadline results in an *increase* in idle time on the GPU
+ * (since it has to wait an additional vblank period), sending a signal to
+ * the GPU's devfreq to reduce frequency, when in fact the opposite is what
is
+ * needed.
+ *
+ * To this end, deadline hint(s) can be set on a _fence via
_fence_set_deadline.
+ * The deadline hint provides a way for the waiting driver, or userspace, to
+ * convey an appropriate sense of urgency to the signaling driver.
+ *
+ * A deadline hint is given in absolute ktime (CLOCK_MONOTONIC for userspace
+ * facing APIs). The time could either be some point in the future (such as
+ * the vblank based deadline for page-flipping, or the start of a compositor's
+ * composition cycle), or the current time to indicate an immediate deadline
+ * hint (Ie. forward progress cannot be made until this fence is signaled).
+ *
+ * Multiple deadlines may be set on a given fence, even in parallel. See the
+ * documentation for _fence_ops.set_deadline.
+ *
+ * The deadline hint is just that, a hint. The driver that created the fence
+ * may react by increasing frequency, making different scheduling choices, etc.
+ * Or doing nothing at all.
+ */
+
+/**
+ * dma_fence_set_deadline - set desired fence-wait deadline hint
+ * @fence:the fence that is to be waited on
+ * @deadline: the time by which the waiter hopes for the fence to be
+ *signaled
+ *
+ * Give the fence signaler a hint about an upcoming deadline, such as
+ * vblank, by which point the waiter would prefer the fence to be
+ * signaled by. This is intended to give feedback to the fence signaler
+ * to aid in power management decisions, such as boosting GPU frequency
+ * if a periodic vblank deadline is approaching but the fence is not
+ * yet signaled..
+ */
+void dma_fence_set_deadline(struct dma_fence *fence, ktime_t deadline)
+{
+ if (fence->ops->set_deadline && !dma_fence_is_signaled(fence))
+ fence->ops->set_deadline(fence, deadline);
+}
+EXPORT_SYMBOL(dma_fence_set_deadline);
+
/**
* dma_fence_describe - Dump fence describtion into seq_file
* @fence: the 6fence to
[PATCH v9 00/15] dma-fence: Deadline awareness
From: Rob Clark This series adds a deadline hint to fences, so realtime deadlines such as vblank can be communicated to the fence signaller for power/ frequency management decisions. This is partially inspired by a trick i915 does, but implemented via dma-fence for a couple of reasons: 1) To continue to be able to use the atomic helpers 2) To support cases where display and gpu are different drivers This iteration adds a dma-fence ioctl to set a deadline (both to support igt-tests, and compositors which delay decisions about which client buffer to display), and a sw_sync ioctl to read back the deadline. IGT tests utilizing these can be found at: https://gitlab.freedesktop.org/robclark/igt-gpu-tools/-/commits/fence-deadline v1: https://patchwork.freedesktop.org/series/93035/ v2: Move filtering out of later deadlines to fence implementation to avoid increasing the size of dma_fence v3: Add support in fence-array and fence-chain; Add some uabi to support igt tests and userspace compositors. v4: Rebase, address various comments, and add syncobj deadline support, and sync_file EPOLLPRI based on experience with perf/ freq issues with clvk compute workloads on i915 (anv) v5: Clarify that this is a hint as opposed to a more hard deadline guarantee, switch to using u64 ns values in UABI (still absolute CLOCK_MONOTONIC values), drop syncobj related cap and driver feature flag in favor of allowing count_handles==0 for probing kernel support. v6: Re-work vblank helper to calculate time of _start_ of vblank, and work correctly if the last vblank event was more than a frame ago. Add (mostly unrelated) drm/msm patch which also uses the vblank helper. Use dma_fence_chain_contained(). More verbose syncobj UABI comments. Drop DMA_FENCE_FLAG_HAS_DEADLINE_BIT. v7: Fix kbuild complaints about vblank helper. Add more docs. v8: Add patch to surface sync_file UAPI, and more docs updates. v9: Drop (E)POLLPRI support.. I still like it, but not essential and it can always be revived later. Fix doc build warning. Rob Clark (15): dma-buf/dma-fence: Add deadline awareness dma-buf/fence-array: Add fence deadline support dma-buf/fence-chain: Add fence deadline support dma-buf/dma-resv: Add a way to set fence deadline dma-buf/sync_file: Surface sync-file uABI dma-buf/sync_file: Add SET_DEADLINE ioctl dma-buf/sw_sync: Add fence deadline support drm/scheduler: Add fence deadline support drm/syncobj: Add deadline support for syncobj waits drm/vblank: Add helper to get next vblank time drm/atomic-helper: Set fence deadline for vblank drm/msm: Add deadline based boost support drm/msm: Add wait-boost support drm/msm/atomic: Switch to vblank_start helper drm/i915: Add deadline based boost support Documentation/driver-api/dma-buf.rst| 16 - drivers/dma-buf/dma-fence-array.c | 11 drivers/dma-buf/dma-fence-chain.c | 12 drivers/dma-buf/dma-fence.c | 60 ++ drivers/dma-buf/dma-resv.c | 22 +++ drivers/dma-buf/sw_sync.c | 81 + drivers/dma-buf/sync_debug.h| 2 + drivers/dma-buf/sync_file.c | 19 ++ drivers/gpu/drm/drm_atomic_helper.c | 36 +++ drivers/gpu/drm/drm_syncobj.c | 64 +++ drivers/gpu/drm/drm_vblank.c| 53 +--- drivers/gpu/drm/i915/i915_request.c | 20 ++ drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c | 15 - drivers/gpu/drm/msm/msm_atomic.c| 8 ++- drivers/gpu/drm/msm/msm_drv.c | 12 ++-- drivers/gpu/drm/msm/msm_fence.c | 74 ++ drivers/gpu/drm/msm/msm_fence.h | 20 ++ drivers/gpu/drm/msm/msm_gem.c | 5 ++ drivers/gpu/drm/msm/msm_kms.h | 8 --- drivers/gpu/drm/scheduler/sched_fence.c | 46 ++ drivers/gpu/drm/scheduler/sched_main.c | 2 +- include/drm/drm_vblank.h| 1 + include/drm/gpu_scheduler.h | 17 ++ include/linux/dma-fence.h | 22 +++ include/linux/dma-resv.h| 2 + include/uapi/drm/drm.h | 17 ++ include/uapi/drm/msm_drm.h | 14 - include/uapi/linux/sync_file.h | 59 +++--- 28 files changed, 639 insertions(+), 79 deletions(-) -- 2.39.1
Re: [git pull] drm-next-fixes for 6.3-rc1
The pull request you sent on Fri, 3 Mar 2023 09:07:58 +1000: > git://anongit.freedesktop.org/drm/drm tags/drm-next-2023-03-03-1 has been merged into torvalds/linux.git: https://git.kernel.org/torvalds/c/2eb29d59ddf02e39774abfb60b2030b0b7e27c1f Thank you! -- Deet-doot-dot, I am a bot. https://korg.docs.kernel.org/prtracker.html
[PATCH v6] drm/virtio: Add option to disable KMS support
From: Rob Clark
Add a build option to disable modesetting support. This is useful in
cases where the guest only needs to use the GPU in a headless mode, or
(such as in the CrOS usage) window surfaces are proxied to a host
compositor.
As the modesetting ioctls are a big surface area for potential security
bugs to be found (it's happened in the past, we should assume it will
again in the future), it makes sense to have a build option to disable
those ioctls in cases where they serve no legitimate purpose.
v2: Use more if (IS_ENABLED(...))
v3: Also permit the host to advertise no scanouts
v4: Spiff out commit msg
v5: Make num_scanouts==0 and DRM_VIRTIO_GPU_KMS=n behave the same
v6: Drop conditionally building virtgpu_display.c and early-out of
it's init/fini fxns instead
Signed-off-by: Rob Clark
Reviewed-by: Dmitry Osipenko
Reviewed-by: Javier Martinez Canillas
---
drivers/gpu/drm/virtio/Kconfig | 11 +++
drivers/gpu/drm/virtio/virtgpu_display.c | 6 ++
drivers/gpu/drm/virtio/virtgpu_drv.c | 4
drivers/gpu/drm/virtio/virtgpu_kms.c | 23 ++-
4 files changed, 35 insertions(+), 9 deletions(-)
diff --git a/drivers/gpu/drm/virtio/Kconfig b/drivers/gpu/drm/virtio/Kconfig
index 51ec7c3240c9..ea06ff2aa4b4 100644
--- a/drivers/gpu/drm/virtio/Kconfig
+++ b/drivers/gpu/drm/virtio/Kconfig
@@ -11,3 +11,14 @@ config DRM_VIRTIO_GPU
QEMU based VMMs (like KVM or Xen).
If unsure say M.
+
+config DRM_VIRTIO_GPU_KMS
+ bool "Virtio GPU driver modesetting support"
+ depends on DRM_VIRTIO_GPU
+ default y
+ help
+ Enable modesetting support for virtio GPU driver. This can be
+ disabled in cases where only "headless" usage of the GPU is
+ required.
+
+ If unsure, say Y.
diff --git a/drivers/gpu/drm/virtio/virtgpu_display.c
b/drivers/gpu/drm/virtio/virtgpu_display.c
index 9ea7611a9e0f..ad924a8502e9 100644
--- a/drivers/gpu/drm/virtio/virtgpu_display.c
+++ b/drivers/gpu/drm/virtio/virtgpu_display.c
@@ -336,6 +336,9 @@ int virtio_gpu_modeset_init(struct virtio_gpu_device *vgdev)
{
int i, ret;
+ if (!vgdev->num_scanouts)
+ return 0;
+
ret = drmm_mode_config_init(vgdev->ddev);
if (ret)
return ret;
@@ -362,6 +365,9 @@ void virtio_gpu_modeset_fini(struct virtio_gpu_device
*vgdev)
{
int i;
+ if (!vgdev->num_scanouts)
+ return;
+
for (i = 0 ; i < vgdev->num_scanouts; ++i)
kfree(vgdev->outputs[i].edid);
}
diff --git a/drivers/gpu/drm/virtio/virtgpu_drv.c
b/drivers/gpu/drm/virtio/virtgpu_drv.c
index ae97b98750b6..add075681e18 100644
--- a/drivers/gpu/drm/virtio/virtgpu_drv.c
+++ b/drivers/gpu/drm/virtio/virtgpu_drv.c
@@ -172,6 +172,10 @@ MODULE_AUTHOR("Alon Levy");
DEFINE_DRM_GEM_FOPS(virtio_gpu_driver_fops);
static const struct drm_driver driver = {
+ /*
+* If KMS is disabled DRIVER_MODESET and DRIVER_ATOMIC are masked
+* out via drm_device::driver_features:
+*/
.driver_features = DRIVER_MODESET | DRIVER_GEM | DRIVER_RENDER |
DRIVER_ATOMIC,
.open = virtio_gpu_driver_open,
.postclose = virtio_gpu_driver_postclose,
diff --git a/drivers/gpu/drm/virtio/virtgpu_kms.c
b/drivers/gpu/drm/virtio/virtgpu_kms.c
index 27b7f14dae89..02e5c18c2c75 100644
--- a/drivers/gpu/drm/virtio/virtgpu_kms.c
+++ b/drivers/gpu/drm/virtio/virtgpu_kms.c
@@ -223,12 +223,15 @@ int virtio_gpu_init(struct virtio_device *vdev, struct
drm_device *dev)
num_scanouts, _scanouts);
vgdev->num_scanouts = min_t(uint32_t, num_scanouts,
VIRTIO_GPU_MAX_SCANOUTS);
- if (!vgdev->num_scanouts) {
- DRM_ERROR("num_scanouts is zero\n");
- ret = -EINVAL;
- goto err_scanouts;
+
+ if (IS_ENABLED(CONFIG_DRM_VIRTIO_GPU_KMS) || !vgdev->num_scanouts) {
+ DRM_INFO("KMS disabled\n");
+ vgdev->num_scanouts = 0;
+ vgdev->has_edid = false;
+ dev->driver_features &= ~(DRIVER_MODESET | DRIVER_ATOMIC);
+ } else {
+ DRM_INFO("number of scanouts: %d\n", num_scanouts);
}
- DRM_INFO("number of scanouts: %d\n", num_scanouts);
virtio_cread_le(vgdev->vdev, struct virtio_gpu_config,
num_capsets, _capsets);
@@ -246,10 +249,12 @@ int virtio_gpu_init(struct virtio_device *vdev, struct
drm_device *dev)
virtio_gpu_get_capsets(vgdev, num_capsets);
if (vgdev->has_edid)
virtio_gpu_cmd_get_edids(vgdev);
- virtio_gpu_cmd_get_display_info(vgdev);
- virtio_gpu_notify(vgdev);
- wait_event_timeout(vgdev->resp_wq, !vgdev->display_info_pending,
- 5 * HZ);
+ if (vgdev->num_scanouts) {
+ virtio_gpu_cmd_get_display_info(vgdev);
+
Re: [PATCH v5] drm/virtio: Add option to disable KMS support
On Wed, Mar 1, 2023 at 11:25 PM Gerd Hoffmann wrote:
>
> On Thu, Mar 02, 2023 at 12:39:33AM +0300, Dmitry Osipenko wrote:
> > On 3/1/23 21:54, Rob Clark wrote:
> > > /* virtgpu_display.c */
> > > +#if defined(CONFIG_DRM_VIRTIO_GPU_KMS)
> > > int virtio_gpu_modeset_init(struct virtio_gpu_device *vgdev);
> > > void virtio_gpu_modeset_fini(struct virtio_gpu_device *vgdev);
> > > +#else
> > > +static inline int virtio_gpu_modeset_init(struct virtio_gpu_device
> > > *vgdev)
> > > +{
> > > + return 0;
> > > +}
> > > +static inline void virtio_gpu_modeset_fini(struct virtio_gpu_device
> > > *vgdev)
> > > +{
> > > +}
> > > +#endif
> >
> > In v4 Gerd wanted to keep building the virtgpu_display.o and instead add
> > the KSM config check to virtio_gpu_modeset_init/fini().
>
> The main point is that the code workflow should be the same in both
> cases. The patch does that for virtio_gpu_modeset_init() but doesn't
> for virtio_gpu_modeset_fini().
>
> Return early in the functions (and drop the #ifdef here) is how I would
> implement this, but I wouldn't insist on that, there are other ways to
> solve this too ;)
Ahh, true, I guess omitting that one file doesn't save anything and
early return makes for a bit simpler/smaller patch
BR,
-R
Re: [PATCH] drm/msm: Initialize mode_config earlier
On Wed, Mar 01, 2023 at 02:58:50PM +0100, Johan Hovold wrote: > On Tue, Jan 24, 2023 at 09:09:02AM +0100, Johan Hovold wrote: > > On Mon, Jan 23, 2023 at 09:17:49AM -0800, Bjorn Andersson wrote: > > > On Mon, Jan 23, 2023 at 05:01:45PM +0100, Johan Hovold wrote: > > > > On Tue, Jan 17, 2023 at 09:04:39AM +0100, Johan Hovold wrote: > > > > > On Mon, Jan 16, 2023 at 08:51:22PM -0600, Bjorn Andersson wrote: > > > > > > > > Perhaps we have shuffled other things around to avoid this bug? > > > > > > Either > > > > > > way, let's this on hold until further proof that it's still > > > > > > reproducible. > > > > > > > > > > As I've mentioned off list, I haven't hit the apparent race I reported > > > > > here: > > > > > > > > > > > > > > > https://lore.kernel.org/all/y1efjh11b5uqz...@hovoldconsulting.com/ > > > > > > > > > > since moving to 6.2. I did hit it with both 6.0 and 6.1-rc2, but it > > > > > could very well be that something has changes that fixes (or hides) > > > > > the > > > > > issue since. > > > > > > > > For unrelated reasons, I tried enabling async probing, and apart from > > > > apparently causing the panel driver to probe defer indefinitely, I also > > > > again hit the WARN_ON() I had added to catch this: > > > > > > > > [ 13.593235] WARNING: CPU: 0 PID: 125 at > > > > drivers/gpu/drm/drm_probe_helper.c:664 > > > > drm_kms_helper_hotplug_event+0x48/0x7 > > > > 0 [drm_kms_helper] > > > > > > So the bug still appears to be there (and the MSM DRM driver is fragile > > > > and broken, but we knew that). > > > > > > > > > > But the ordering between mode_config.funcs = !NULL and > > > drm_kms_helper_poll_init() in msm_drm_init() seems pretty clear. > > > > > > And my testing shows that drm_kms_helper_poll_init() is the cause for > > > getting bridge->hpd_cb != NULL. > > > > > > So the ordering seems legit, unless there's something else causing the > > > assignment of bridge->hpd_cb to happen earlier in this scenario. > > > > I'm not saying that this patch is correct (indeed it doesn't seem to > > be), but only that the bug I reported still appears to be present in > > 6.2. > > So after debugging this issue a third time, I can conclude that it is > still very much present in 6.2. > > It appears you looked at the linux-next tree when you concluded that > this patch was not needed. In 6.2 the bridge->hpd_cb callback is set > before mode_config.funcs is initialised as part of > kms->funcs->hw_init(kms). > > The hpd DRM changes heading into 6.3 do appear to avoid the NULL-pointer > dereference by moving the bridge->hpd_cb initialisation to > drm_kms_helper_poll_init() as you mention above. > > The PMIC GLINK altmode driver still happily forwards notifications > regardless of the DRM driver state though, which can lead to missed > hotplug events. It seems you need to implement the > hpd_enable()/disable() callbacks and either cache or not enable events > in fw until the DRM driver is ready. > It's not clear to me what the expectation from the DRM framework is on this point. We register a drm_bridge which is only capable of signaling HPD events (DRM_BRIDGE_OP_HPD), not querying HPD state (DRM_BRIDGE_OP_DETECT). Does this imply that any such bridge must ensure that hpd events are re-delivered once hpd_enable() has been invoked (we can't invoke it from hpd_enable...)? Is it reasonable to do this retriggering in the altmode driver? Or is it the job of the TCPM (it seems reasonable to not send the PAN_EN message until we get hpd_enable()...)? Regards, Bjorn
[git pull] drm-next-fixes for 6.3-rc1
Hi Linus, This is the fixes for the last couple of weeks on top of the drm-next, I don't think this contains any next content it should be all fixes. amdgpu and i915 mostly, the amdgpu ones are bigger because it's two weeks in one. hopefully this week I got the subject line right. Dave. drm-next-2023-03-03-1: drm-next-fixes for 6.3-rc1 fbdev: - fix uninit var in error path shmem: - revert unGPLing an export i915: - Don't use stolen memory or BAR mappings for ring buffers with LLC - Add inverted backlight quirk for HP 14-r206nv - Fix GSI offset for MCR lookups - GVT fixes (memleak, debugfs attributes, kconfig, typos) amdgpu: - SMU 13 fixes - Enable TMZ for GC 10.3.6 - Misc display fixes - Buddy allocator fixes - GC 11 fixes - S0ix fix - INFO IOCTL queries for GC 11 - VCN harvest fixes for SR-IOV - UMC 8.10 RAS fixes - Don't restrict bpc to 8 - NBIO 7.5 fix - Allow freesync on PCon for more devices amdkfd: - SDMA fix - Illegal memory access fix The following changes since commit a48bba98380cb0b43dcd01d276c7efc282e3c33f: msm/fbdev: fix unused variable warning with clang. (2023-02-23 09:48:05 +1000) are available in the Git repository at: git://anongit.freedesktop.org/drm/drm tags/drm-next-2023-03-03-1 for you to fetch changes up to 54ceb92724a8cf5294c284d5e9f770fc763cdab2: Merge tag 'amd-drm-fixes-6.3-2023-03-02' of https://gitlab.freedesktop.org/agd5f/linux into drm-next (2023-03-03 08:26:59 +1000) drm-next-fixes for 6.3-rc1 fbdev: - fix uninit var in error path shmem: - revert unGPLing an export i915: - Don't use stolen memory or BAR mappings for ring buffers with LLC - Add inverted backlight quirk for HP 14-r206nv - Fix GSI offset for MCR lookups - GVT fixes (memleak, debugfs attributes, kconfig, typos) amdgpu: - SMU 13 fixes - Enable TMZ for GC 10.3.6 - Misc display fixes - Buddy allocator fixes - GC 11 fixes - S0ix fix - INFO IOCTL queries for GC 11 - VCN harvest fixes for SR-IOV - UMC 8.10 RAS fixes - Don't restrict bpc to 8 - NBIO 7.5 fix - Allow freesync on PCon for more devices amdkfd: - SDMA fix - Illegal memory access fix Alex Hung (1): drm/amd/display: fix shift-out-of-bounds in CalculateVMAndRowBytes Aric Cyr (1): Revert "drm/amd/display: Do not set DRR on pipe commit" Asahi Lina (1): drm/shmem-helper: Revert accidental non-GPL export Candice Li (3): drm/amdgpu: Add convert_error_address function for umc v8_10 drm/amdgpu: Add ecc info query interface for umc v8_10 drm/amdgpu: Make umc_v8_10_convert_error_address static and remove unused variable Colin Ian King (1): i915/gvt: Fix spelling mistake "vender" -> "vendor" Dave Airlie (3): Merge tag 'drm-misc-next-fixes-2023-02-28' of git://anongit.freedesktop.org/drm/drm-misc into drm-next Merge tag 'drm-intel-next-fixes-2023-02-27' of git://anongit.freedesktop.org/drm/drm-intel into drm-next Merge tag 'amd-drm-fixes-6.3-2023-03-02' of https://gitlab.freedesktop.org/agd5f/linux into drm-next Deepak R Varma (2): drm/i915/gvt: Avoid full proxy f_ops for debugfs attributes drm/i915/gvt: Remove extra semicolon Evan Quan (2): drm/amd/pm: correct the baco state setting for ArmD3 scenario drm/amd/pm: no pptable resetup on runpm exiting Greg Kroah-Hartman (1): i915: fix memory leak with using debugfs_lookup() Guchun Chen (1): drm/amd/pm: downgrade log level upon SMU IF version mismatch Hamza Mahfooz (1): drm/amd/display: only warn once in dce110_edp_wait_for_hpd_ready() Harry Wentland (2): drm/amdgpu: Select DRM_DISPLAY_HDCP_HELPER in amdgpu drm/amd/display: Don't restrict bpc to 8 bpc Hawking Zhang (1): drm/amdgpu: fix incorrect active rb bitmap for gfx11 Horatio Zhang (1): drm/amdgpu: fix ttm_bo calltrace warning in psp_hw_fini Jane Jian (1): drm/amdgpu/vcn: set and use harvest config Jani Nikula (1): Merge tag 'gvt-next-fixes-2023-02-23' of https://github.com/intel/gvt-linux into drm-intel-next-fixes Jesse Zhang (1): drm/amdgpu: add tmz support for GC 10.3.6 John Harrison (2): drm/i915: Don't use stolen memory for ring buffers with LLC drm/i915: Don't use BAR mappings for ring buffers with LLC Kenneth Feng (1): drm/amd/pm: re-enable ac/dc on smu_v13_0_0/10 Marek Olšák (1): drm/amdgpu: add more fields into device info, caches sizes, etc. Mario Limonciello (2): drm/amd: Don't allow s0ix on APUs older than Raven drm/amd: Fix initialization for nbio 7.5.1 Mark Hawrylak (1): drm/radeon: Fix eDP for single-display iMac11,2 Matt Roper (1): drm/i915/xelpmp: Consider GSI offset when doing MCR lookups Mavroudis Chatzilaridis (1): drm/i915/quirks: Add inverted backlight quirk for HP 14-r206nv Nathan Chancellor (1): drm: omapdrm: Do not use helper unininitialized in omap_fbdev_init() Qu
[Bug 217110] GPU Lockup on Radeon Pitcairn - VAAPI related
https://bugzilla.kernel.org/show_bug.cgi?id=217110 --- Comment #3 from Ed Martin (edman...@edman007.com) --- Thanks, reported here https://gitlab.freedesktop.org/drm/amd/-/issues/2440 -- You may reply to this email to add a comment. You are receiving this mail because: You are watching the assignee of the bug.
RE: [PATCH] drm/i915: Set wedged if enable guc communication failed
Thanks Jani.
Updated patch sent, let me know if you have any comments.
Regards,
Zhanjun
> -Original Message-
> From: Jani Nikula
> Sent: February 27, 2023 6:30 AM
> To: Dong, Zhanjun ; intel-
> g...@lists.freedesktop.org; dri-devel@lists.freedesktop.org
> Cc: Dong, Zhanjun
> Subject: Re: [PATCH] drm/i915: Set wedged if enable guc communication
> failed
>
> On Fri, 24 Feb 2023, Zhanjun Dong wrote:
> > Add err code check for enable_communication on resume path, set
> wedged if failed.
>
> I can see that this is *what* the code does, but the commit message should
> answer the question *why*.
>
> >
> > Signed-off-by: Zhanjun Dong
> > ---
> > drivers/gpu/drm/i915/gt/intel_gt_pm.c | 5 -
> > drivers/gpu/drm/i915/gt/uc/intel_uc.c | 9 +++--
> > 2 files changed, 11 insertions(+), 3 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/gt/intel_gt_pm.c
> > b/drivers/gpu/drm/i915/gt/intel_gt_pm.c
> > index cef3d6f5c34e..f3bb7cbbd293 100644
> > --- a/drivers/gpu/drm/i915/gt/intel_gt_pm.c
> > +++ b/drivers/gpu/drm/i915/gt/intel_gt_pm.c
> > @@ -401,8 +401,11 @@ int intel_gt_runtime_resume(struct intel_gt *gt)
> > intel_ggtt_restore_fences(gt->ggtt);
> >
> > ret = intel_uc_runtime_resume(>uc);
> > - if (ret)
> > + if (ret) {
> > + /* Set wedge if uc resume failed */
>
> This comment is just a reiteration of the C code in English, but doesn't
> provide any useful additional information.
>
> BR,
> Jani.
>
> > + intel_gt_set_wedged(gt);
> > return ret;
> > + }
> >
> > return 0;
> > }
> > diff --git a/drivers/gpu/drm/i915/gt/uc/intel_uc.c
> > b/drivers/gpu/drm/i915/gt/uc/intel_uc.c
> > index 6648691bd645..d4f428acf20a 100644
> > --- a/drivers/gpu/drm/i915/gt/uc/intel_uc.c
> > +++ b/drivers/gpu/drm/i915/gt/uc/intel_uc.c
> > @@ -698,8 +698,13 @@ static int __uc_resume(struct intel_uc *uc, bool
> enable_communication)
> > /* Make sure we enable communication if and only if it's disabled */
> > GEM_BUG_ON(enable_communication ==
> intel_guc_ct_enabled(>ct));
> >
> > - if (enable_communication)
> > - guc_enable_communication(guc);
> > + if (enable_communication) {
> > + err = guc_enable_communication(guc);
> > + if (err) {
> > + guc_dbg(guc, "Failed to resume, %pe", ERR_PTR(err));
> > + return err;
> > + }
> > + }
> >
> > /* If we are only resuming GuC communication but not reloading
> > * GuC, we need to ensure the ARAT timer interrupt is enabled
>
> --
> Jani Nikula, Intel Open Source Graphics Center
[PATCH] drm/i915: Set wedged if enable guc communication failed
Add err code check for enable_communication on resume path. When resume failed,
we can no longer use the GPU, marking the GPU as wedged.
Signed-off-by: Zhanjun Dong
---
drivers/gpu/drm/i915/gt/intel_gt_pm.c | 7 ++-
drivers/gpu/drm/i915/gt/uc/intel_uc.c | 9 +++--
2 files changed, 13 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/intel_gt_pm.c
b/drivers/gpu/drm/i915/gt/intel_gt_pm.c
index cef3d6f5c34e..42a7d75ce39e 100644
--- a/drivers/gpu/drm/i915/gt/intel_gt_pm.c
+++ b/drivers/gpu/drm/i915/gt/intel_gt_pm.c
@@ -401,8 +401,13 @@ int intel_gt_runtime_resume(struct intel_gt *gt)
intel_ggtt_restore_fences(gt->ggtt);
ret = intel_uc_runtime_resume(>uc);
- if (ret)
+ if (ret) {
+ /* Resume failed, we can no longer use the GPU, marking the GPU
+* as wedged.
+*/
+ intel_gt_set_wedged(gt);
return ret;
+ }
return 0;
}
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_uc.c
b/drivers/gpu/drm/i915/gt/uc/intel_uc.c
index 6648691bd645..d4f428acf20a 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_uc.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_uc.c
@@ -698,8 +698,13 @@ static int __uc_resume(struct intel_uc *uc, bool
enable_communication)
/* Make sure we enable communication if and only if it's disabled */
GEM_BUG_ON(enable_communication == intel_guc_ct_enabled(>ct));
- if (enable_communication)
- guc_enable_communication(guc);
+ if (enable_communication) {
+ err = guc_enable_communication(guc);
+ if (err) {
+ guc_dbg(guc, "Failed to resume, %pe", ERR_PTR(err));
+ return err;
+ }
+ }
/* If we are only resuming GuC communication but not reloading
* GuC, we need to ensure the ARAT timer interrupt is enabled
--
2.34.1
Re: [PATCH v4 3/4] drm/msm/dpu: Remove empty prepare_commit() function
On 3/1/2023 2:13 AM, Marijn Suijten wrote:
On 2023-03-01 11:08:16, Marijn Suijten wrote:
On 2023-02-21 10:42:55, Jessica Zhang wrote:
Now that the TE setup has been moved to prepare_for_kickoff(), we have
not prepare_commit() callbacks left. This makes dpu_encoder_prepare_commit()
s/not/no
do nothing. Remove prepare_commit() from DPU driver.
And again, this:
Changes in V3:
- Reworded commit message to be more clear
- Corrected spelling mistake in commit message
Changes in V4:
- Reworded commit message for clarity
... should go below the cut.
Signed-off-by: Jessica Zhang
With the above two issues fixed:
Reviewed-by: Marijn Suijten
---
drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c | 19 ---
drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.h | 7 ---
drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c | 21 -
3 files changed, 47 deletions(-)
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
index dcceed91aed8..35e120b5ef53 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
@@ -2090,25 +2090,6 @@ void dpu_encoder_helper_phys_cleanup(struct
dpu_encoder_phys *phys_enc)
ctl->ops.clear_pending_flush(ctl);
}
-void dpu_encoder_prepare_commit(struct drm_encoder *drm_enc)
-{
- struct dpu_encoder_virt *dpu_enc;
- struct dpu_encoder_phys *phys;
- int i;
-
- if (!drm_enc) {
- DPU_ERROR("invalid encoder\n");
- return;
- }
- dpu_enc = to_dpu_encoder_virt(drm_enc);
-
- for (i = 0; i < dpu_enc->num_phys_encs; i++) {
- phys = dpu_enc->phys_encs[i];
- if (phys->ops.prepare_commit)
- phys->ops.prepare_commit(phys);
In hindsight, Dmitry asked in v2 to remove prepare_commit from
dpu_encoder_phys_ops (and its documentation comment) in
dpu_encoder_phys.h, but that has not happened yet. Can we do that in a
v5?
Ah, forgot to include that change. Will add it in the v5. Thanks for
catching it!
- Jessica Zhang
- Marijn
- }
-}
-
#ifdef CONFIG_DEBUG_FS
static int _dpu_encoder_status_show(struct seq_file *s, void *data)
{
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.h
b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.h
index 9e7236ef34e6..2c9ef8d1b877 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.h
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.h
@@ -146,13 +146,6 @@ struct drm_encoder *dpu_encoder_init(
int dpu_encoder_setup(struct drm_device *dev, struct drm_encoder *enc,
struct msm_display_info *disp_info);
-/**
- * dpu_encoder_prepare_commit - prepare encoder at the very beginning of an
- * atomic commit, before any registers are written
- * @drm_enc:Pointer to previously created drm encoder structure
- */
-void dpu_encoder_prepare_commit(struct drm_encoder *drm_enc);
-
/**
* dpu_encoder_set_idle_timeout - set the idle timeout for video
*and command mode encoders.
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c
b/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c
index 165958d47ec6..6f7ddbf0d9b7 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c
@@ -425,26 +425,6 @@ static ktime_t dpu_kms_vsync_time(struct msm_kms *kms,
struct drm_crtc *crtc)
return ktime_get();
}
-static void dpu_kms_prepare_commit(struct msm_kms *kms,
- struct drm_atomic_state *state)
-{
- struct drm_crtc *crtc;
- struct drm_crtc_state *crtc_state;
- struct drm_encoder *encoder;
- int i;
-
- if (!kms)
- return;
-
- /* Call prepare_commit for all affected encoders */
- for_each_new_crtc_in_state(state, crtc, crtc_state, i) {
- drm_for_each_encoder_mask(encoder, crtc->dev,
- crtc_state->encoder_mask) {
- dpu_encoder_prepare_commit(encoder);
- }
- }
-}
-
static void dpu_kms_flush_commit(struct msm_kms *kms, unsigned crtc_mask)
{
struct dpu_kms *dpu_kms = to_dpu_kms(kms);
@@ -949,7 +929,6 @@ static const struct msm_kms_funcs kms_funcs = {
.enable_commit = dpu_kms_enable_commit,
.disable_commit = dpu_kms_disable_commit,
.vsync_time = dpu_kms_vsync_time,
- .prepare_commit = dpu_kms_prepare_commit,
.flush_commit= dpu_kms_flush_commit,
.wait_flush = dpu_kms_wait_flush,
.complete_commit = dpu_kms_complete_commit,
--
2.39.2
[PATCH 12/17] udmabuf: remove MODULE_LICENSE in non-modules
Since commit 8b41fc4454e ("kbuild: create modules.builtin without
Makefile.modbuiltin or tristate.conf"), MODULE_LICENSE declarations
are used to identify modules. As a consequence, uses of the macro
in non-modules will cause modprobe to misidentify their containing
object file as a module when it is not (false positives), and modprobe
might succeed rather than failing with a suitable error message.
So remove it in the files in this commit, none of which can be built as
modules.
Signed-off-by: Nick Alcock
Suggested-by: Luis Chamberlain
Cc: Luis Chamberlain
Cc: linux-modu...@vger.kernel.org
Cc: linux-ker...@vger.kernel.org
Cc: Hitomi Hasegawa
Cc: Gerd Hoffmann
Cc: Sumit Semwal
Cc: "Christian König"
Cc: dri-devel@lists.freedesktop.org
Cc: linux-me...@vger.kernel.org
Cc: linaro-mm-...@lists.linaro.org
---
drivers/dma-buf/udmabuf.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/dma-buf/udmabuf.c b/drivers/dma-buf/udmabuf.c
index 283816fbd72fc..d5c09a86df6c1 100644
--- a/drivers/dma-buf/udmabuf.c
+++ b/drivers/dma-buf/udmabuf.c
@@ -402,4 +402,3 @@ module_init(udmabuf_dev_init)
module_exit(udmabuf_dev_exit)
MODULE_AUTHOR("Gerd Hoffmann ");
-MODULE_LICENSE("GPL v2");
--
2.39.1.268.g9de2f9a303
[PATCH 00/17] MODULE_LICENSE removals, sixth tranche
This series, based on current modules-next, is part of a treewide cleanup suggested by Luis Chamberlain, to remove the LICENSE_MODULE usage from files/objects that are not tristate. Due to recent changes to kbuild, these uses are now problematic. See the commit logs for more details. (The commit log prefixes and Cc lists are automatically determined. I've eyeballed them, and they seem reasonable: my apologies if they are not.) This is the last tranche of patches in this series. (In total, there are 121 patches in this series.) The series at a whole can be found here: https://github.com/nickalcock/linux module-license (This is a respin with kbuild: prefixes dropped. The previous series, used in the mailouts of tranche 3 and earlier, is in the module-license-kbuild-prefix branch.) Cc: dri-devel@lists.freedesktop.org Cc: linux-fsde...@vger.kernel.org Cc: linux-ker...@vger.kernel.org Cc: linux-me...@vger.kernel.org Cc: linux...@kvack.org Cc: linux-modu...@vger.kernel.org Cc: x...@kernel.org Nick Alcock (17): irqchip: remove MODULE_LICENSE in non-modules bus: remove MODULE_LICENSE in non-modules braille_console: remove MODULE_LICENSE in non-modules arm-cci: remove MODULE_LICENSE in non-modules drivers: bus: simple-pm-bus: remove MODULE_LICENSE in non-modules watch_queue: remove MODULE_LICENSE in non-modules btree: remove MODULE_LICENSE in non-modules lib: remove MODULE_LICENSE in non-modules fprobe: remove MODULE_LICENSE in non-modules tty: remove MODULE_LICENSE in non-modules unicode: remove MODULE_LICENSE in non-modules udmabuf: remove MODULE_LICENSE in non-modules regulator: stm32-pwr: remove MODULE_LICENSE in non-modules mm: remove MODULE_LICENSE in non-modules xen: remove MODULE_LICENSE in non-modules zpool: remove MODULE_LICENSE in non-modules zswap: remove MODULE_LICENSE in non-modules arch/x86/mm/debug_pagetables.c | 1 - drivers/accessibility/braille/braille_console.c | 1 - drivers/bus/arm-cci.c | 1 - drivers/bus/bt1-apb.c | 1 - drivers/bus/bt1-axi.c | 1 - drivers/bus/simple-pm-bus.c | 1 - drivers/dma-buf/udmabuf.c | 1 - drivers/irqchip/irq-ti-sci-inta.c | 1 - drivers/irqchip/irq-ti-sci-intr.c | 1 - drivers/regulator/stm32-pwr.c | 1 - drivers/tty/n_null.c| 1 - drivers/xen/grant-dma-ops.c | 1 - drivers/xen/xenbus/xenbus_probe.c | 1 - fs/unicode/utf8-core.c | 1 - kernel/watch_queue.c| 1 - lib/btree.c | 1 - lib/glob.c | 1 - lib/test_fprobe.c | 1 - mm/zpool.c | 1 - mm/zswap.c | 1 - 20 files changed, 20 deletions(-) -- 2.39.1.268.g9de2f9a303
[PATCH] drm/format_helper: Add Kunit tests for drm_fb_xrgb8888_to_mono()
Extend the existing test cases to test the conversion from XRGB to
monochromatic.
Signed-off-by: Arthur Grillo
---
.../gpu/drm/tests/drm_format_helper_test.c| 73 +++
1 file changed, 73 insertions(+)
diff --git a/drivers/gpu/drm/tests/drm_format_helper_test.c
b/drivers/gpu/drm/tests/drm_format_helper_test.c
index 9536829c6e3a..0610341e7349 100644
--- a/drivers/gpu/drm/tests/drm_format_helper_test.c
+++ b/drivers/gpu/drm/tests/drm_format_helper_test.c
@@ -67,6 +67,11 @@ struct convert_to_argb2101010_result {
const u32 expected[TEST_BUF_SIZE];
};
+struct convert_to_mono_result {
+ unsigned int dst_pitch;
+ const u8 expected[TEST_BUF_SIZE];
+};
+
struct convert_xrgb_case {
const char *name;
unsigned int pitch;
@@ -82,6 +87,7 @@ struct convert_xrgb_case {
struct convert_to_argb_result argb_result;
struct convert_to_xrgb2101010_result xrgb2101010_result;
struct convert_to_argb2101010_result argb2101010_result;
+ struct convert_to_mono_result mono_result;
};
static struct convert_xrgb_case convert_xrgb_cases[] = {
@@ -131,6 +137,10 @@ static struct convert_xrgb_case
convert_xrgb_cases[] = {
.dst_pitch = 0,
.expected = { 0xFFF0 },
},
+ .mono_result = {
+ .dst_pitch = 0,
+ .expected = { 0x00 },
+ },
},
{
.name = "single_pixel_clip_rectangle",
@@ -181,6 +191,10 @@ static struct convert_xrgb_case
convert_xrgb_cases[] = {
.dst_pitch = 0,
.expected = { 0xFFF0 },
},
+ .mono_result = {
+ .dst_pitch = 0,
+ .expected = { 0x00 },
+ },
},
{
/* Well known colors: White, black, red, green, blue, magenta,
@@ -293,6 +307,15 @@ static struct convert_xrgb_case
convert_xrgb_cases[] = {
0xFC00, 0xC00F,
},
},
+ .mono_result = {
+ .dst_pitch = 0,
+ .expected = {
+ 0x01,
+ 0x02,
+ 0x00,
+ 0x03,
+ },
+ },
},
{
/* Randomly picked colors. Full buffer within the clip area. */
@@ -392,6 +415,14 @@ static struct convert_xrgb_case
convert_xrgb_cases[] = {
0xEA20300C, 0xDB1705CD, 0xC3844672, 0x,
0x,
},
},
+ .mono_result = {
+ .dst_pitch = 0,
+ .expected = {
+ 0x00,
+ 0x00,
+ 0x00,
+ },
+ },
},
};
@@ -419,6 +450,17 @@ static size_t conversion_buf_size(u32 dst_format, unsigned
int dst_pitch,
return dst_pitch * drm_rect_height(clip);
}
+static size_t conversion_buf_size_mono(unsigned int dst_pitch, const struct
drm_rect *clip)
+{
+ if (!dst_pitch) {
+ unsigned int linepixels = drm_rect_width(clip) * 1;
+
+ dst_pitch = DIV_ROUND_UP(linepixels, 8);
+ }
+
+ return dst_pitch * drm_rect_height(clip);
+}
+
static u16 *le16buf_to_cpu(struct kunit *test, const __le16 *buf, size_t
buf_size)
{
u16 *dst = NULL;
@@ -789,6 +831,36 @@ static void drm_test_fb_xrgb_to_argb2101010(struct
kunit *test)
KUNIT_EXPECT_MEMEQ(test, buf, result->expected, dst_size);
}
+static void drm_test_fb_xrgb_to_mono(struct kunit *test)
+{
+ const struct convert_xrgb_case *params = test->param_value;
+ const struct convert_to_mono_result *result = >mono_result;
+ size_t dst_size;
+ u8 *buf = NULL;
+ __le32 *xrgb = NULL;
+ struct iosys_map dst, src;
+
+ struct drm_framebuffer fb = {
+ .format = drm_format_info(DRM_FORMAT_XRGB),
+ .pitches = { params->pitch, 0, 0 },
+ };
+
+ dst_size = conversion_buf_size_mono(result->dst_pitch, >clip);
+
+ KUNIT_ASSERT_GT(test, dst_size, 0);
+
+ buf = kunit_kzalloc(test, dst_size, GFP_KERNEL);
+ KUNIT_ASSERT_NOT_ERR_OR_NULL(test, buf);
+ iosys_map_set_vaddr(, buf);
+
+ xrgb = cpubuf_to_le32(test, params->xrgb, TEST_BUF_SIZE);
+ KUNIT_ASSERT_NOT_ERR_OR_NULL(test, xrgb);
+ iosys_map_set_vaddr(, xrgb);
+
+ drm_fb_xrgb_to_mono(, >dst_pitch, , ,
>clip);
+ KUNIT_EXPECT_MEMEQ(test, buf, result->expected, dst_size);
+}
+
static struct kunit_case drm_format_helper_test_cases[] = {
Re: [PATCH 05/22] drm/atmel-hlcdc: Use GEM DMA fbdev emulation
On Wed, Mar 01, 2023 at 04:30:44PM +0100, Thomas Zimmermann wrote: > Use the fbdev emulation that is optimized for DMA helpers. Avoids > possible shadow buffering and makes the code simpler. > > Signed-off-by: Thomas Zimmermann Acked-by: Sam Ravnborg > --- > drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.c | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) > > diff --git a/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.c > b/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.c > index 4e806b06d35d..29603561d501 100644 > --- a/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.c > +++ b/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.c > @@ -19,7 +19,7 @@ > #include > #include > #include > -#include > +#include > #include > #include > #include > @@ -760,7 +760,7 @@ static int atmel_hlcdc_dc_drm_probe(struct > platform_device *pdev) > if (ret) > goto err_unload; > > - drm_fbdev_generic_setup(ddev, 24); > + drm_fbdev_dma_setup(ddev, 24); > > return 0; > > -- > 2.39.2
Re: [PATCH v3] drm/msm/dp: check core_initialized flag at both host_init() and host_deinit()
On Thu, 2 Mar 2023 at 20:41, Kuogee Hsieh wrote: > > > On 3/1/2023 1:15 PM, Dmitry Baryshkov wrote: > > On 01/03/2023 18:57, Kuogee Hsieh wrote: > >> > >> On 2/28/2023 6:16 PM, Dmitry Baryshkov wrote: > >>> On Wed, 1 Mar 2023 at 02:17, Kuogee Hsieh > >>> wrote: > There is a reboot/suspend test case where system suspend is forced > during system booting up. Since dp_display_host_init() of external > DP is executed at hpd thread context, this test case may created a > scenario that dp_display_host_deinit() from pm_suspend() run before > dp_display_host_init() if hpd thread has no chance to run during > booting up while suspend request command was issued. At this scenario > system will crash at aux register access at dp_display_host_deinit() > since aux clock had not yet been enabled by dp_display_host_init(). > Therefore we have to ensure aux clock enabled by checking > core_initialized flag before access aux registers at pm_suspend. > >>> Can a call to dp_display_host_init() be moved from > >>> dp_display_config_hpd() to dp_display_bind()? > >> > >> yes, Sankeerth's "drm/msm/dp: enable pm_runtime support for dp > >> driver" patch is doing that which is under review. > >> > >> https://patchwork.freedesktop.org/patch/523879/?series=114297=1 > > > > No, he is doing another thing. He is moving these calls to pm_runtime > > callbacks, not to the dp_display_bind(). > > > >>> Related question: what is the primary reason for having > >>> EV_HPD_INIT_SETUP and calling dp_display_config_hpd() via the event > >>> thread? Does DP driver really depend on DPU irqs being installed? As > >>> far as I understand, DP device uses MDSS interrupts and those IRQs are > >>> available and working at the time of dp_display_probe() / > >>> dp_display_bind(). > >> > >> HDP gpio pin has to run through DP aux module 100ms denouncing logic > >> and have its mask bits. > >> > >> Therefore DP irq has to be enabled to receive DP isr with mask bits set. > > > > So... DP irq is enabled by the MDSS, not by the DPU. Again, why does > > DP driver depend on DPU irqs being installed? > > sorry, previously i mis understand your question -- why does DP driver > depend on DPU irqs being installed? > > now, I think you are asking why dpu_irq_postinstall() ==> > msm_dp_irq_postinstall() ==> event_thread ==> dp_display_config_hdp() > ==> enable_irq(dp->irq) > > With the below test i had run, i think the reason is to make sure > dp->irq be requested before enable it. > > I just run the execution timing order test and collect execution order > as descending order at below, > > 1) dp_display_probe() -- start > > 2) dp_display_bind() > > 3) msm_dp_modeset_init() ==> dp_display_request_irq() ==> > dp_display_get_next_bridge() > > 4) dpu_irq_postinstall() ==> msm_dp_irq_postinstall() ==> > enable_irq(dp->irq) > > 5) dp_display_probe() -- end > > dp->irq is request at msm_dp_modeset_init() and enabled after. Should be moved to probe. > > That bring up the issue to move DP's dp_display_host_init() executed at > dp_display_bind(). > > Since eDP have dp_dispaly_host_init() executed at > dp_display_get_next_bridge() which executed after dp_display_bind(). > > If moved DP's dp_display_host_init() to dp_dispaly_bind() which means DP > will be ready to receive HPD irq before eDP ready. And the AUX bus population should also be moved to probe(), which means we should call dp_display_host_init() from probe() too. Having aux_bus_populate in probe would allow moving component_add() to the done_probing() callback, making probe/defer case more robust > This may create some uncertainties at execution flow and complicate > things up. Hopefully the changes suggested above will make it simpler. -- With best wishes Dmitry
Re: [PATCH v3] drm/msm/dp: check core_initialized flag at both host_init() and host_deinit()
On 3/1/2023 1:15 PM, Dmitry Baryshkov wrote:
On 01/03/2023 18:57, Kuogee Hsieh wrote:
On 2/28/2023 6:16 PM, Dmitry Baryshkov wrote:
On Wed, 1 Mar 2023 at 02:17, Kuogee Hsieh
wrote:
There is a reboot/suspend test case where system suspend is forced
during system booting up. Since dp_display_host_init() of external
DP is executed at hpd thread context, this test case may created a
scenario that dp_display_host_deinit() from pm_suspend() run before
dp_display_host_init() if hpd thread has no chance to run during
booting up while suspend request command was issued. At this scenario
system will crash at aux register access at dp_display_host_deinit()
since aux clock had not yet been enabled by dp_display_host_init().
Therefore we have to ensure aux clock enabled by checking
core_initialized flag before access aux registers at pm_suspend.
Can a call to dp_display_host_init() be moved from
dp_display_config_hpd() to dp_display_bind()?
yes, Sankeerth's "drm/msm/dp: enable pm_runtime support for dp
driver" patch is doing that which is under review.
https://patchwork.freedesktop.org/patch/523879/?series=114297=1
No, he is doing another thing. He is moving these calls to pm_runtime
callbacks, not to the dp_display_bind().
Related question: what is the primary reason for having
EV_HPD_INIT_SETUP and calling dp_display_config_hpd() via the event
thread? Does DP driver really depend on DPU irqs being installed? As
far as I understand, DP device uses MDSS interrupts and those IRQs are
available and working at the time of dp_display_probe() /
dp_display_bind().
HDP gpio pin has to run through DP aux module 100ms denouncing logic
and have its mask bits.
Therefore DP irq has to be enabled to receive DP isr with mask bits set.
So... DP irq is enabled by the MDSS, not by the DPU. Again, why does
DP driver depend on DPU irqs being installed?
sorry, previously i mis understand your question -- why does DP driver
depend on DPU irqs being installed?
now, I think you are asking why dpu_irq_postinstall() ==>
msm_dp_irq_postinstall() ==> event_thread ==> dp_display_config_hdp()
==> enable_irq(dp->irq)
With the below test i had run, i think the reason is to make sure
dp->irq be requested before enable it.
I just run the execution timing order test and collect execution order
as descending order at below,
1) dp_display_probe() -- start
2) dp_display_bind()
3) msm_dp_modeset_init() ==> dp_display_request_irq() ==>
dp_display_get_next_bridge()
4) dpu_irq_postinstall() ==> msm_dp_irq_postinstall() ==>
enable_irq(dp->irq)
5) dp_display_probe() -- end
dp->irq is request at msm_dp_modeset_init() and enabled after.
That bring up the issue to move DP's dp_display_host_init() executed at
dp_display_bind().
Since eDP have dp_dispaly_host_init() executed at
dp_display_get_next_bridge() which executed after dp_display_bind().
If moved DP's dp_display_host_init() to dp_dispaly_bind() which means DP
will be ready to receive HPD irq before eDP ready.
This may create some uncertainties at execution flow and complicate
things up.
Similar mechanism is used for mdp, dsi, etc.
And none of them uses irq_postinstall callback.
Changes in v2:
-- at commit text, dp_display_host_init() instead of host_init()
-- at commit text, dp_display_host_deinit() instead of host_deinit()
Changes in v3:
-- re arrange to avoid commit text line over 75 chars
Fixes: 989ebe7bc446 ("drm/msm/dp: do not initialize phy until
plugin interrupt received")
Signed-off-by: Kuogee Hsieh
Reviewed-by: Stephen Boyd
---
drivers/gpu/drm/msm/dp/dp_display.c | 20
1 file changed, 12 insertions(+), 8 deletions(-)
diff --git a/drivers/gpu/drm/msm/dp/dp_display.c
b/drivers/gpu/drm/msm/dp/dp_display.c
index bde1a7c..1850738 100644
--- a/drivers/gpu/drm/msm/dp/dp_display.c
+++ b/drivers/gpu/drm/msm/dp/dp_display.c
@@ -460,10 +460,12 @@ static void dp_display_host_init(struct
dp_display_private *dp)
dp->dp_display.connector_type, dp->core_initialized,
dp->phy_initialized);
- dp_power_init(dp->power, false);
- dp_ctrl_reset_irq_ctrl(dp->ctrl, true);
- dp_aux_init(dp->aux);
- dp->core_initialized = true;
+ if (!dp->core_initialized) {
+ dp_power_init(dp->power, false);
+ dp_ctrl_reset_irq_ctrl(dp->ctrl, true);
+ dp_aux_init(dp->aux);
+ dp->core_initialized = true;
+ }
}
static void dp_display_host_deinit(struct dp_display_private *dp)
@@ -472,10 +474,12 @@ static void dp_display_host_deinit(struct
dp_display_private *dp)
dp->dp_display.connector_type, dp->core_initialized,
dp->phy_initialized);
- dp_ctrl_reset_irq_ctrl(dp->ctrl, false);
- dp_aux_deinit(dp->aux);
- dp_power_deinit(dp->power);
- dp->core_initialized = false;
+ if (dp->core_initialized) {
+
[PATCH v2] dt-bindings: display: mediatek: Compatible list cleanup
From: Yassine Oudjana Several DT bindings of MediaTek display blocks make unnecessary use of "oneOf" and "items". Remove them and replace them with enums where necessary. Signed-off-by: Yassine Oudjana --- Changes since v1: - Leave enums with 1 element as they are. .../bindings/display/mediatek/mediatek,ccorr.yaml | 7 +++ .../bindings/display/mediatek/mediatek,color.yaml | 10 -- .../bindings/display/mediatek/mediatek,dither.yaml | 3 +-- .../bindings/display/mediatek/mediatek,dsc.yaml | 4 +--- .../bindings/display/mediatek/mediatek,gamma.yaml | 7 +++ .../bindings/display/mediatek/mediatek,merge.yaml | 8 +++- .../bindings/display/mediatek/mediatek,od.yaml | 8 +++- .../bindings/display/mediatek/mediatek,ovl-2l.yaml | 7 +++ .../bindings/display/mediatek/mediatek,ovl.yaml | 13 + .../display/mediatek/mediatek,postmask.yaml | 3 +-- .../bindings/display/mediatek/mediatek,rdma.yaml| 13 + .../bindings/display/mediatek/mediatek,split.yaml | 4 +--- .../bindings/display/mediatek/mediatek,ufoe.yaml| 4 +--- .../bindings/display/mediatek/mediatek,wdma.yaml| 4 +--- 14 files changed, 35 insertions(+), 60 deletions(-) diff --git a/Documentation/devicetree/bindings/display/mediatek/mediatek,ccorr.yaml b/Documentation/devicetree/bindings/display/mediatek/mediatek,ccorr.yaml index b04820c95b22..dc22bd522523 100644 --- a/Documentation/devicetree/bindings/display/mediatek/mediatek,ccorr.yaml +++ b/Documentation/devicetree/bindings/display/mediatek/mediatek,ccorr.yaml @@ -21,10 +21,9 @@ description: | properties: compatible: oneOf: - - items: - - const: mediatek,mt8183-disp-ccorr - - items: - - const: mediatek,mt8192-disp-ccorr + - enum: + - mediatek,mt8183-disp-ccorr + - mediatek,mt8192-disp-ccorr - items: - enum: - mediatek,mt8188-disp-ccorr diff --git a/Documentation/devicetree/bindings/display/mediatek/mediatek,color.yaml b/Documentation/devicetree/bindings/display/mediatek/mediatek,color.yaml index 62306c88f485..d0ea77fc4b06 100644 --- a/Documentation/devicetree/bindings/display/mediatek/mediatek,color.yaml +++ b/Documentation/devicetree/bindings/display/mediatek/mediatek,color.yaml @@ -22,12 +22,10 @@ description: | properties: compatible: oneOf: - - items: - - const: mediatek,mt2701-disp-color - - items: - - const: mediatek,mt8167-disp-color - - items: - - const: mediatek,mt8173-disp-color + - enum: + - mediatek,mt2701-disp-color + - mediatek,mt8167-disp-color + - mediatek,mt8173-disp-color - items: - enum: - mediatek,mt7623-disp-color diff --git a/Documentation/devicetree/bindings/display/mediatek/mediatek,dither.yaml b/Documentation/devicetree/bindings/display/mediatek/mediatek,dither.yaml index 5c7445c174e5..9d74de63fe63 100644 --- a/Documentation/devicetree/bindings/display/mediatek/mediatek,dither.yaml +++ b/Documentation/devicetree/bindings/display/mediatek/mediatek,dither.yaml @@ -22,8 +22,7 @@ description: | properties: compatible: oneOf: - - items: - - const: mediatek,mt8183-disp-dither + - const: mediatek,mt8183-disp-dither - items: - enum: - mediatek,mt8186-disp-dither diff --git a/Documentation/devicetree/bindings/display/mediatek/mediatek,dsc.yaml b/Documentation/devicetree/bindings/display/mediatek/mediatek,dsc.yaml index 49248864514b..37bf6bf4a1ab 100644 --- a/Documentation/devicetree/bindings/display/mediatek/mediatek,dsc.yaml +++ b/Documentation/devicetree/bindings/display/mediatek/mediatek,dsc.yaml @@ -19,9 +19,7 @@ description: | properties: compatible: -oneOf: - - items: - - const: mediatek,mt8195-disp-dsc +const: mediatek,mt8195-disp-dsc reg: maxItems: 1 diff --git a/Documentation/devicetree/bindings/display/mediatek/mediatek,gamma.yaml b/Documentation/devicetree/bindings/display/mediatek/mediatek,gamma.yaml index a5c6a91fac71..6c2be9d6840b 100644 --- a/Documentation/devicetree/bindings/display/mediatek/mediatek,gamma.yaml +++ b/Documentation/devicetree/bindings/display/mediatek/mediatek,gamma.yaml @@ -21,10 +21,9 @@ description: | properties: compatible: oneOf: - - items: - - const: mediatek,mt8173-disp-gamma - - items: - - const: mediatek,mt8183-disp-gamma + - enum: + - mediatek,mt8173-disp-gamma + - mediatek,mt8183-disp-gamma - items: - enum: - mediatek,mt8186-disp-gamma diff --git a/Documentation/devicetree/bindings/display/mediatek/mediatek,merge.yaml b/Documentation/devicetree/bindings/display/mediatek/mediatek,merge.yaml index 69ba75777dac..c474ee6fa05b 100644 --- a/Documentation/devicetree/bindings/display/mediatek/mediatek,merge.yaml +++
[PATCH] dt-bindings: display: mediatek: Compatible list cleanup
From: Yassine Oudjana Several DT bindings of MediaTek display blocks make unnecessary use of "oneOf" and "items", and have some enums with only 1 element. Remove unnecessary "oneOf" and "items", and replace enums that have 1 element with "const". Signed-off-by: Yassine Oudjana --- .../bindings/display/mediatek/mediatek,aal.yaml | 3 +-- .../display/mediatek/mediatek,ccorr.yaml | 10 -- .../display/mediatek/mediatek,color.yaml | 10 -- .../display/mediatek/mediatek,dither.yaml| 3 +-- .../bindings/display/mediatek/mediatek,dsc.yaml | 4 +--- .../display/mediatek/mediatek,gamma.yaml | 7 +++ .../display/mediatek/mediatek,merge.yaml | 8 +++- .../bindings/display/mediatek/mediatek,od.yaml | 8 +++- .../display/mediatek/mediatek,ovl-2l.yaml| 10 -- .../bindings/display/mediatek/mediatek,ovl.yaml | 16 ++-- .../display/mediatek/mediatek,postmask.yaml | 3 +-- .../bindings/display/mediatek/mediatek,rdma.yaml | 13 + .../display/mediatek/mediatek,split.yaml | 4 +--- .../bindings/display/mediatek/mediatek,ufoe.yaml | 4 +--- .../bindings/display/mediatek/mediatek,wdma.yaml | 4 +--- 15 files changed, 39 insertions(+), 68 deletions(-) diff --git a/Documentation/devicetree/bindings/display/mediatek/mediatek,aal.yaml b/Documentation/devicetree/bindings/display/mediatek/mediatek,aal.yaml index 92741486c24d..d8d78abd6c6c 100644 --- a/Documentation/devicetree/bindings/display/mediatek/mediatek,aal.yaml +++ b/Documentation/devicetree/bindings/display/mediatek/mediatek,aal.yaml @@ -25,8 +25,7 @@ properties: - mediatek,mt8173-disp-aal - mediatek,mt8183-disp-aal - items: - - enum: - - mediatek,mt2712-disp-aal + - const: mediatek,mt2712-disp-aal - const: mediatek,mt8173-disp-aal - items: - enum: diff --git a/Documentation/devicetree/bindings/display/mediatek/mediatek,ccorr.yaml b/Documentation/devicetree/bindings/display/mediatek/mediatek,ccorr.yaml index b04820c95b22..e72d2884bb49 100644 --- a/Documentation/devicetree/bindings/display/mediatek/mediatek,ccorr.yaml +++ b/Documentation/devicetree/bindings/display/mediatek/mediatek,ccorr.yaml @@ -21,18 +21,16 @@ description: | properties: compatible: oneOf: - - items: - - const: mediatek,mt8183-disp-ccorr - - items: - - const: mediatek,mt8192-disp-ccorr + - enum: + - mediatek,mt8183-disp-ccorr + - mediatek,mt8192-disp-ccorr - items: - enum: - mediatek,mt8188-disp-ccorr - mediatek,mt8195-disp-ccorr - const: mediatek,mt8192-disp-ccorr - items: - - enum: - - mediatek,mt8186-disp-ccorr + - const: mediatek,mt8186-disp-ccorr - const: mediatek,mt8192-disp-ccorr reg: diff --git a/Documentation/devicetree/bindings/display/mediatek/mediatek,color.yaml b/Documentation/devicetree/bindings/display/mediatek/mediatek,color.yaml index 62306c88f485..d0ea77fc4b06 100644 --- a/Documentation/devicetree/bindings/display/mediatek/mediatek,color.yaml +++ b/Documentation/devicetree/bindings/display/mediatek/mediatek,color.yaml @@ -22,12 +22,10 @@ description: | properties: compatible: oneOf: - - items: - - const: mediatek,mt2701-disp-color - - items: - - const: mediatek,mt8167-disp-color - - items: - - const: mediatek,mt8173-disp-color + - enum: + - mediatek,mt2701-disp-color + - mediatek,mt8167-disp-color + - mediatek,mt8173-disp-color - items: - enum: - mediatek,mt7623-disp-color diff --git a/Documentation/devicetree/bindings/display/mediatek/mediatek,dither.yaml b/Documentation/devicetree/bindings/display/mediatek/mediatek,dither.yaml index 5c7445c174e5..9d74de63fe63 100644 --- a/Documentation/devicetree/bindings/display/mediatek/mediatek,dither.yaml +++ b/Documentation/devicetree/bindings/display/mediatek/mediatek,dither.yaml @@ -22,8 +22,7 @@ description: | properties: compatible: oneOf: - - items: - - const: mediatek,mt8183-disp-dither + - const: mediatek,mt8183-disp-dither - items: - enum: - mediatek,mt8186-disp-dither diff --git a/Documentation/devicetree/bindings/display/mediatek/mediatek,dsc.yaml b/Documentation/devicetree/bindings/display/mediatek/mediatek,dsc.yaml index 49248864514b..37bf6bf4a1ab 100644 --- a/Documentation/devicetree/bindings/display/mediatek/mediatek,dsc.yaml +++ b/Documentation/devicetree/bindings/display/mediatek/mediatek,dsc.yaml @@ -19,9 +19,7 @@ description: | properties: compatible: -oneOf: - - items: - - const: mediatek,mt8195-disp-dsc +const: mediatek,mt8195-disp-dsc reg: maxItems: 1 diff --git
[PATCH] gpu: amd/pm: mark symbols static where possible for smu11
I get one warning when building kernel with -Werror=missing-prototypes :
drivers/gpu/drm/amd/amdgpu/../pm/swsmu/smu11/vangogh_ppt.c:1600:5:
error: no previous prototype for ‘vangogh_set_apu_thermal_limit’
[-Werror=missing-prototypes]
int vangogh_set_apu_thermal_limit(struct smu_context *smu, uint32_t limit)
In fact, this function don't need a declaration due to it's only used
in the file which they are.
So this patch marks the function with 'static'.
Signed-off-by: Jeff Pang
---
drivers/gpu/drm/amd/pm/swsmu/smu11/vangogh_ppt.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/amd/pm/swsmu/smu11/vangogh_ppt.c
b/drivers/gpu/drm/amd/pm/swsmu/smu11/vangogh_ppt.c
index 016d5621e0b3..24046af60933 100644
--- a/drivers/gpu/drm/amd/pm/swsmu/smu11/vangogh_ppt.c
+++ b/drivers/gpu/drm/amd/pm/swsmu/smu11/vangogh_ppt.c
@@ -1597,7 +1597,7 @@ static int vangogh_get_apu_thermal_limit(struct
smu_context *smu, uint32_t *limi
0, limit);
}
-int vangogh_set_apu_thermal_limit(struct smu_context *smu, uint32_t limit)
+static int vangogh_set_apu_thermal_limit(struct smu_context *smu, uint32_t
limit)
{
return smu_cmn_send_smc_msg_with_param(smu,
SMU_MSG_SetReducedThermalLimit,
--
2.34.1
Re: [PATCH] drm/edid: fix info leak when failing to get panel id
Hi,
On Wed, Mar 1, 2023 at 11:49 PM Johan Hovold wrote:
>
> Make sure to clear the transfer buffer before fetching the EDID to
> avoid leaking slab data to the logs on errors that leave the buffer
> unchanged.
>
> Fixes: 69c7717c20cc ("drm/edid: Dump the EDID when drm_edid_get_panel_id()
> has an error")
> Cc: sta...@vger.kernel.org # 6.2
> Cc: Douglas Anderson
> Signed-off-by: Johan Hovold
> ---
> drivers/gpu/drm/drm_edid.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
> index 3841aba17abd..8707fe72a028 100644
> --- a/drivers/gpu/drm/drm_edid.c
> +++ b/drivers/gpu/drm/drm_edid.c
> @@ -2797,7 +2797,7 @@ u32 drm_edid_get_panel_id(struct i2c_adapter *adapter)
> * the EDID then we'll just return 0.
> */
>
> - base_block = kmalloc(EDID_LENGTH, GFP_KERNEL);
> + base_block = kzalloc(EDID_LENGTH, GFP_KERNEL);
Good catch! I'm landing this to drm-misc-fixes right away.
4d8457fe0eb9 drm/edid: fix info leak when failing to get panel id
I'm sure I copied the kmalloc() from _drm_do_get_edid(), but it looks
like in _that_ case if the read fails we never print the buffer so
that one is OK.
-Doug
Re: [RFT PATCH v2 1/3] drm/bridge: tc358762: Set pre_enable_prev_first
On Thu, 2 Mar 2023 at 19:26, Doug Anderson wrote:
>
> Hi,
>
> On Mon, Feb 27, 2023 at 5:24 PM Dmitry Baryshkov
> wrote:
> >
> > On 28/02/2023 02:26, Doug Anderson wrote:
> > > Hi,
> > >
> > > On Wed, Feb 1, 2023 at 1:51 AM Dave Stevenson
> > > wrote:
> > >>
> > >> On Tue, 31 Jan 2023 at 22:22, Douglas Anderson
> > >> wrote:
> > >>>
> > >>> Set the "pre_enable_prev_first" as provided by commit 4fb912e5e190
> > >>> ("drm/bridge: Introduce pre_enable_prev_first to alter bridge init
> > >>> order"). This should allow us to revert commit ec7981e6c614
> > >>> ("drm/msm/dsi: don't powerup at modeset time for parade-ps8640") and
> > >>> commit 7d8e9a90509f ("drm/msm/dsi: move DSI host powerup to modeset
> > >>> time").
> > >>
> > >> I see no reference in the TC358762 datasheet to requiring the DSI
> > >> interface to be in any particular state.
> > >> However, setting this flag does mean that the DSI host doesn't need to
> > >> power up and down for each host_transfer request from
> > >> tc358762_pre_enable/tc358762_init, so on that basis I'm good with it.
> > >>
> > >> Reviewed-by: Dave Stevenson
> > >>
> > >>> Cc: Dave Stevenson
> > >>> Cc: Dmitry Baryshkov
> > >>> Cc: Abhinav Kumar
> > >>> Signed-off-by: Douglas Anderson
> > >>> ---
> > >>>
> > >>> (no changes since v1)
> > >>>
> > >>> drivers/gpu/drm/bridge/tc358762.c | 1 +
> > >>> 1 file changed, 1 insertion(+)
> > >>>
> > >>> diff --git a/drivers/gpu/drm/bridge/tc358762.c
> > >>> b/drivers/gpu/drm/bridge/tc358762.c
> > >>> index 0b6a28436885..77f7f7f54757 100644
> > >>> --- a/drivers/gpu/drm/bridge/tc358762.c
> > >>> +++ b/drivers/gpu/drm/bridge/tc358762.c
> > >>> @@ -229,6 +229,7 @@ static int tc358762_probe(struct mipi_dsi_device
> > >>> *dsi)
> > >>> ctx->bridge.funcs = _bridge_funcs;
> > >>> ctx->bridge.type = DRM_MODE_CONNECTOR_DPI;
> > >>> ctx->bridge.of_node = dev->of_node;
> > >>> + ctx->bridge.pre_enable_prev_first = true;
> > >>>
> > >>> drm_bridge_add(>bridge);
> > >
> > > Abhinav asked what the plan was for landing this [1]. Since this isn't
> > > urgent, I guess the plan is to land patch #1 in drm-misc-next. Then we
> > > sit and wait until it percolates into mainline and, once it does, then
> > > patch #2 and #3 can land.
> > >
> > > Since I have Dave's review I can commit this to drm-misc-next myself.
> > > My plan will be to wait until Thursday or Friday of this week (to give
> > > people a bit of time to object) and then land patch #1. Then I'll
> > > snooze things for a while and poke Abhinav and Dmitry to land patch #2
> > > / #3 when I notice it in mainline. If, at any point, someone comes out
> > > of the woodwork and yells that this is breaking them then, worst case,
> > > we can revert.
> >
> > This plan sounds good to me.
>
> Pushed to drm-misc-next:
>
> 55cac10739d5 drm/bridge: tc358762: Set pre_enable_prev_first
>
> If my math is right then I'd expect that to get into mainline for
> 6.4-rc1. I guess that means it'll be in Linus's tree mid-May. I'll
> schedule a reminder to suggest landing at patches #2 and #3 again in
> late May.
It might be earlier, if msm-next merges drm-misc earlier (e.g. for the
PSR patches).
--
With best wishes
Dmitry
Re: [RFT PATCH v2 1/3] drm/bridge: tc358762: Set pre_enable_prev_first
Hi,
On Mon, Feb 27, 2023 at 5:24 PM Dmitry Baryshkov
wrote:
>
> On 28/02/2023 02:26, Doug Anderson wrote:
> > Hi,
> >
> > On Wed, Feb 1, 2023 at 1:51 AM Dave Stevenson
> > wrote:
> >>
> >> On Tue, 31 Jan 2023 at 22:22, Douglas Anderson
> >> wrote:
> >>>
> >>> Set the "pre_enable_prev_first" as provided by commit 4fb912e5e190
> >>> ("drm/bridge: Introduce pre_enable_prev_first to alter bridge init
> >>> order"). This should allow us to revert commit ec7981e6c614
> >>> ("drm/msm/dsi: don't powerup at modeset time for parade-ps8640") and
> >>> commit 7d8e9a90509f ("drm/msm/dsi: move DSI host powerup to modeset
> >>> time").
> >>
> >> I see no reference in the TC358762 datasheet to requiring the DSI
> >> interface to be in any particular state.
> >> However, setting this flag does mean that the DSI host doesn't need to
> >> power up and down for each host_transfer request from
> >> tc358762_pre_enable/tc358762_init, so on that basis I'm good with it.
> >>
> >> Reviewed-by: Dave Stevenson
> >>
> >>> Cc: Dave Stevenson
> >>> Cc: Dmitry Baryshkov
> >>> Cc: Abhinav Kumar
> >>> Signed-off-by: Douglas Anderson
> >>> ---
> >>>
> >>> (no changes since v1)
> >>>
> >>> drivers/gpu/drm/bridge/tc358762.c | 1 +
> >>> 1 file changed, 1 insertion(+)
> >>>
> >>> diff --git a/drivers/gpu/drm/bridge/tc358762.c
> >>> b/drivers/gpu/drm/bridge/tc358762.c
> >>> index 0b6a28436885..77f7f7f54757 100644
> >>> --- a/drivers/gpu/drm/bridge/tc358762.c
> >>> +++ b/drivers/gpu/drm/bridge/tc358762.c
> >>> @@ -229,6 +229,7 @@ static int tc358762_probe(struct mipi_dsi_device *dsi)
> >>> ctx->bridge.funcs = _bridge_funcs;
> >>> ctx->bridge.type = DRM_MODE_CONNECTOR_DPI;
> >>> ctx->bridge.of_node = dev->of_node;
> >>> + ctx->bridge.pre_enable_prev_first = true;
> >>>
> >>> drm_bridge_add(>bridge);
> >
> > Abhinav asked what the plan was for landing this [1]. Since this isn't
> > urgent, I guess the plan is to land patch #1 in drm-misc-next. Then we
> > sit and wait until it percolates into mainline and, once it does, then
> > patch #2 and #3 can land.
> >
> > Since I have Dave's review I can commit this to drm-misc-next myself.
> > My plan will be to wait until Thursday or Friday of this week (to give
> > people a bit of time to object) and then land patch #1. Then I'll
> > snooze things for a while and poke Abhinav and Dmitry to land patch #2
> > / #3 when I notice it in mainline. If, at any point, someone comes out
> > of the woodwork and yells that this is breaking them then, worst case,
> > we can revert.
>
> This plan sounds good to me.
Pushed to drm-misc-next:
55cac10739d5 drm/bridge: tc358762: Set pre_enable_prev_first
If my math is right then I'd expect that to get into mainline for
6.4-rc1. I guess that means it'll be in Linus's tree mid-May. I'll
schedule a reminder to suggest landing at patches #2 and #3 again in
late May.
-Doug
Re: [Intel-gfx] [PATCH RESEND] drm/tests: Suballocator test
Hi Thomas, Thank you for the patch! Yet something to improve: [auto build test ERROR on drm-tip/drm-tip] url: https://github.com/intel-lab-lkp/linux/commits/Thomas-Hellstr-m/drm-tests-Suballocator-test/20230302-163704 base: git://anongit.freedesktop.org/drm/drm-tip drm-tip patch link: https://lore.kernel.org/r/20230302083422.76608-1-thomas.hellstrom%40linux.intel.com patch subject: [Intel-gfx] [PATCH RESEND] drm/tests: Suballocator test config: arm-allmodconfig (https://download.01.org/0day-ci/archive/20230303/202303030052.ybiikxrn-...@intel.com/config) compiler: arm-linux-gnueabi-gcc (GCC) 12.1.0 reproduce (this is a W=1 build): wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross chmod +x ~/bin/make.cross # https://github.com/intel-lab-lkp/linux/commit/e970911bccf3145b76cd755e2d78c0c0f7f22ca1 git remote add linux-review https://github.com/intel-lab-lkp/linux git fetch --no-tags linux-review Thomas-Hellstr-m/drm-tests-Suballocator-test/20230302-163704 git checkout e970911bccf3145b76cd755e2d78c0c0f7f22ca1 # save the config file mkdir build_dir && cp config build_dir/.config COMPILER_INSTALL_PATH=$HOME/0day COMPILER=gcc-12.1.0 make.cross W=1 O=build_dir ARCH=arm olddefconfig COMPILER_INSTALL_PATH=$HOME/0day COMPILER=gcc-12.1.0 make.cross W=1 O=build_dir ARCH=arm SHELL=/bin/bash If you fix the issue, kindly add following tag where applicable | Reported-by: kernel test robot | Link: https://lore.kernel.org/oe-kbuild-all/202303030052.ybiikxrn-...@intel.com/ All errors (new ones prefixed by >>, old ones prefixed by <<): >> ERROR: modpost: "__aeabi_uldivmod" >> [drivers/gpu/drm/tests/drm_suballoc_test.ko] undefined! -- 0-DAY CI Kernel Test Service https://github.com/intel/lkp-tests
Re: [PATCH] dt-bindings: Fix SPI and I2C bus node names in examples
Hi Rob.
> .../bindings/display/bridge/analogix,anx7625.yaml | 2 +-
> .../bindings/display/bridge/anx6345.yaml | 2 +-
> .../bindings/display/bridge/lontium,lt8912b.yaml | 2 +-
> .../bindings/display/bridge/nxp,ptn3460.yaml | 2 +-
> .../bindings/display/bridge/ps8640.yaml | 2 +-
> .../bindings/display/bridge/sil,sii9234.yaml | 2 +-
> .../bindings/display/bridge/ti,dlpc3433.yaml | 2 +-
> .../bindings/display/bridge/toshiba,tc358762.yaml | 2 +-
> .../bindings/display/bridge/toshiba,tc358768.yaml | 2 +-
> .../bindings/display/panel/nec,nl8048hl11.yaml| 2 +-
Acked-by: Sam Ravnborg
> index 669f70b1b4c4..8bd58913804a 100644
> --- a/Documentation/devicetree/bindings/display/solomon,ssd1307fb.yaml
> +++ b/Documentation/devicetree/bindings/display/solomon,ssd1307fb.yaml
> @@ -226,7 +226,7 @@ unevaluatedProperties: false
>
> examples:
>- |
> -i2c1 {
> +i2c {
> #address-cells = <1>;
> #size-cells = <0>;
>
> @@ -239,7 +239,7 @@ examples:
>
> ssd1306_i2c: oled@3d {
> compatible = "solomon,ssd1306";
> -reg = <0x3c>;
> +reg = <0x3d>;
> pwms = < 4 3000>;
> reset-gpios = < 7>;
> solomon,com-lrremap;
I can see this align the example with i2c-mux-gpio.yaml so the change
should be fine. I am just positive surprised the tooling caught it.
The change is
Acked-by: Sam Ravnborg
the above was just me thinking loud.
Sam
Re: [Intel-gfx] [PATCH RESEND] drm/tests: Suballocator test
Hi Thomas, Thank you for the patch! Yet something to improve: [auto build test ERROR on drm-tip/drm-tip] url: https://github.com/intel-lab-lkp/linux/commits/Thomas-Hellstr-m/drm-tests-Suballocator-test/20230302-163704 base: git://anongit.freedesktop.org/drm/drm-tip drm-tip patch link: https://lore.kernel.org/r/20230302083422.76608-1-thomas.hellstrom%40linux.intel.com patch subject: [Intel-gfx] [PATCH RESEND] drm/tests: Suballocator test config: mips-allyesconfig (https://download.01.org/0day-ci/archive/20230303/202303030056.cnezgrqr-...@intel.com/config) compiler: mips-linux-gcc (GCC) 12.1.0 reproduce (this is a W=1 build): wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross chmod +x ~/bin/make.cross # https://github.com/intel-lab-lkp/linux/commit/e970911bccf3145b76cd755e2d78c0c0f7f22ca1 git remote add linux-review https://github.com/intel-lab-lkp/linux git fetch --no-tags linux-review Thomas-Hellstr-m/drm-tests-Suballocator-test/20230302-163704 git checkout e970911bccf3145b76cd755e2d78c0c0f7f22ca1 # save the config file mkdir build_dir && cp config build_dir/.config COMPILER_INSTALL_PATH=$HOME/0day COMPILER=gcc-12.1.0 make.cross W=1 O=build_dir ARCH=mips olddefconfig COMPILER_INSTALL_PATH=$HOME/0day COMPILER=gcc-12.1.0 make.cross W=1 O=build_dir ARCH=mips SHELL=/bin/bash If you fix the issue, kindly add following tag where applicable | Reported-by: kernel test robot | Link: https://lore.kernel.org/oe-kbuild-all/202303030056.cnezgrqr-...@intel.com/ All errors (new ones prefixed by >>): arch/mips/kernel/head.o: in function `kernel_entry': (.ref.text+0xac): relocation truncated to fit: R_MIPS_26 against `start_kernel' init/main.o: in function `set_reset_devices': main.c:(.init.text+0x20): relocation truncated to fit: R_MIPS_26 against `_mcount' main.c:(.init.text+0x30): relocation truncated to fit: R_MIPS_26 against `__sanitizer_cov_trace_pc' init/main.o: in function `debug_kernel': main.c:(.init.text+0xa4): relocation truncated to fit: R_MIPS_26 against `_mcount' main.c:(.init.text+0xb4): relocation truncated to fit: R_MIPS_26 against `__sanitizer_cov_trace_pc' init/main.o: in function `quiet_kernel': main.c:(.init.text+0x128): relocation truncated to fit: R_MIPS_26 against `_mcount' main.c:(.init.text+0x138): relocation truncated to fit: R_MIPS_26 against `__sanitizer_cov_trace_pc' init/main.o: in function `warn_bootconfig': main.c:(.init.text+0x1ac): relocation truncated to fit: R_MIPS_26 against `_mcount' main.c:(.init.text+0x1bc): relocation truncated to fit: R_MIPS_26 against `__sanitizer_cov_trace_pc' init/main.o: in function `init_setup': main.c:(.init.text+0x234): relocation truncated to fit: R_MIPS_26 against `_mcount' main.c:(.init.text+0x254): additional relocation overflows omitted from the output mips-linux-ld: drivers/gpu/drm/tests/drm_suballoc_test.o: in function `drm_test_suballoc': >> drm_suballoc_test.c:(.text.drm_test_suballoc+0xcbc): undefined reference to >> `__udivdi3' >> mips-linux-ld: drm_suballoc_test.c:(.text.drm_test_suballoc+0xd20): >> undefined reference to `__udivdi3' mips-linux-ld: drm_suballoc_test.c:(.text.drm_test_suballoc+0xd84): undefined reference to `__udivdi3' mips-linux-ld: drm_suballoc_test.c:(.text.drm_test_suballoc+0xde8): undefined reference to `__udivdi3' mips-linux-ld: drm_suballoc_test.c:(.text.drm_test_suballoc+0xe40): undefined reference to `__udivdi3' mips-linux-ld: drivers/gpu/drm/tests/drm_suballoc_test.o:drm_suballoc_test.c:(.text.drm_test_suballoc+0xfb4): more undefined references to `__udivdi3' follow -- 0-DAY CI Kernel Test Service https://github.com/intel/lkp-tests
Re: [PATCH v14 14/14] drm/msm/dp: set self refresh aware based on PSR support
On 02/03/2023 18:33, Vinod Polimera wrote: For the PSR to kick in, self_refresh_aware has to be set. Initialize it based on the PSR support for the eDP interface. Signed-off-by: Vinod Polimera Reviewed-by: Dmitry Baryshkov -- With best wishes Dmitry
RE: [PATCH v13 00/13] Add PSR support for eDP
> -Original Message- > From: Doug Anderson > Sent: Thursday, March 2, 2023 2:02 AM > To: Vinod Polimera (QUIC) > Cc: dri-devel@lists.freedesktop.org; linux-arm-...@vger.kernel.org; > freedr...@lists.freedesktop.org; devicet...@vger.kernel.org; linux- > ker...@vger.kernel.org; robdcl...@gmail.com; swb...@chromium.org; > Kalyan Thota (QUIC) ; > dmitry.barysh...@linaro.org; Kuogee Hsieh (QUIC) > ; Vishnuvardhan Prodduturi (QUIC) > ; Bjorn Andersson (QUIC) > ; Abhinav Kumar (QUIC) > ; Sankeerth Billakanti (QUIC) > > Subject: Re: [PATCH v13 00/13] Add PSR support for eDP > > Hi, > > On Wed, Mar 1, 2023 at 11:06 AM Doug Anderson > wrote: > > > > Hi, > > > > On Sun, Feb 12, 2023 at 8:29 AM Vinod Polimera > > wrote: > > > > > > Changes in v2: > > > - Use dp bridge to set psr entry/exit instead of dpu_enocder. > > > - Don't modify whitespaces. > > > - Set self refresh aware from atomic_check. > > > - Set self refresh aware only if psr is supported. > > > - Provide a stub for msm_dp_display_set_psr. > > > - Move dp functions to bridge code. > > > > > > Changes in v3: > > > - Change callback names to reflect atomic interfaces. > > > - Move bridge callback change to separate patch as suggested by Dmitry. > > > - Remove psr function declaration from msm_drv.h. > > > - Set self_refresh_aware flag only if psr is supported. > > > - Modify the variable names to simpler form. > > > - Define bit fields for PSR settings. > > > - Add comments explaining the steps to enter/exit psr. > > > - Change DRM_INFO to drm_dbg_db. > > > > > > Changes in v4: > > > - Move the get crtc functions to drm_atomic. > > > - Add atomic functions for DP bridge too. > > > - Add ternary operator to choose eDP or DP ops. > > > - Return true/false instead of 1/0. > > > - mode_valid missing in the eDP bridge ops. > > > - Move the functions to get crtc into drm_atomic.c. > > > - Fix compilation issues. > > > - Remove dpu_assign_crtc and get crtc from drm_enc instead of > dpu_enc. > > > - Check for crtc state enable while reserving resources. > > > > > > Changes in v5: > > > - Move the mode_valid changes into a different patch. > > > - Complete psr_op_comp only when isr is set. > > > - Move the DP atomic callback changes to a different patch. > > > - Get crtc from drm connector state crtc. > > > - Move to separate patch for check for crtc state enable while > > > reserving resources. > > > > > > Changes in v6: > > > - Remove crtc from dpu_encoder_virt struct. > > > - fix crtc check during vblank toggle crtc. > > > - Misc changes. > > > > > > Changes in v7: > > > - Add fix for underrun issue on kasan build. > > > > > > Changes in v8: > > > - Drop the enc spinlock as it won't serve any purpose in > > > protetcing conn state.(Dmitry/Doug) > > > > > > Changes in v9: > > > - Update commit message and fix alignment using spaces.(Marijn) > > > - Misc changes.(Marijn) > > > > > > Changes in v10: > > > - Get crtc cached in dpu_enc during obj init.(Dmitry) > > > > > > Changes in v11: > > > - Remove crtc cached in dpu_enc during obj init. > > > - Update dpu_enc crtc state on crtc enable/disable during self refresh. > > > > > > Changes in v12: > > > - Update sc7180 intf mask to get intf timing gen status > > > based on DPU_INTF_STATUS_SUPPORTED bit.(Dmitry) > > > - Remove "clear active interface in the datapath cleanup" change > > > as it is already included. > > > > > > Changes in v13: > > > - Move core changes to top of the series.(Dmitry) > > > - Drop self refresh aware disable change after psr entry.(Dmitry) > > > > > > Vinod Polimera (13): > > > drm: add helper functions to retrieve old and new crtc > > > drm/bridge: use atomic enable/disable callbacks for panel bridge > > > drm/bridge: add psr support for panel bridge callbacks > > > drm/msm/disp/dpu: check for crtc enable rather than crtc active to > > > release shared resources > > > drm/msm/disp/dpu: get timing engine status from intf status register > > > drm/msm/disp/dpu: wait for extra vsync till timing engine status is > > > disabled > > > drm/msm/disp/dpu: reset the datapath after timing engine disable > > > drm/msm/dp: use atomic callbacks for DP bridge ops > > > drm/msm/dp: Add basic PSR support for eDP > > > drm/msm/dp: use the eDP bridge ops to validate eDP modes > > > drm/msm/disp/dpu: use atomic enable/disable callbacks for encoder > > > functions > > > drm/msm/disp/dpu: add PSR support for eDP interface in dpu driver > > > drm/msm/disp/dpu: update dpu_enc crtc state on crtc enable/disable > > > during self refresh > > > > I'm curious what the plan is for landing this series. I could land the > > first two in drm-misc if you want, but I'm a lowly committer and so I > > couldn't make an immutable branch for you nor can I officially Ack the > > changes to land in your branch. That means you'd be blocked for an > > extra version. Do you already have a plan?
Re: [PATCH] drm/amd/display: Simplify same effect if/else blocks
On 3/1/23 15:21, Deepak R Varma wrote:
> On Mon, Jan 23, 2023 at 12:23:19AM +0530, Deepak R Varma wrote:
>> On Sun, Jan 15, 2023 at 12:52:10PM -0800, Joe Perches wrote:
>>> On Sun, 2023-01-15 at 15:30 +0530, Deepak R Varma wrote:
The if / else block code has same effect irrespective of the logical
evaluation. Hence, simply the implementation by removing the unnecessary
conditional evaluation. While at it, also fix the long line checkpatch
complaint. Issue identified using cond_no_effect.cocci Coccinelle
semantic patch script.
Signed-off-by: Deepak R Varma
---
Please note: The proposed change is compile tested only. If there are any
inbuilt test cases that I should run for further verification, I will
appreciate
guidance about it. Thank you.
>>>
>>> Preface: I do not know the code.
>>>
>>> Perhaps Rodrigo Siqueira made a copy/paste error submitting the code for
>>> commit 9114b55fabae ("drm/amd/display: Fix SubVP control flow in the MPO
>>> context")
>>> as the code prior to this change is identical.
>>>
>>> Perhaps one of the false uses should be true or dependent on the
>>> interdependent_update_lock state.
>>
>> Thank you Joe for the recommendation.
>>
>> Hi Rodrigo,
>> Can you review and comment on if and what is wrong with your commit?
>
> Hello Rodrigo, Alex,
> Could you please suggest what would be the necessary fix for this typo error?
>
It's not quite a "typo" error. When I look at this code in our internal repo I
see
a couple missing lock calls here that differ between the two cases. I don't
know why
this was never ported over and am surprised it doesn't lead to issues.
I would prefer we keep the code as-is for now until this gets sorted.
Harry
> Thank you,
> Deepak.
>
>>
>> Thank you,
>> ./drv
>>
>>>
diff --git a/drivers/gpu/drm/amd/display/dc/core/dc.c
b/drivers/gpu/drm/amd/display/dc/core/dc.c
>>> []
@@ -3470,14 +3470,9 @@ static void commit_planes_for_stream(struct dc *dc,
/* Since phantom pipe programming is moved to
post_unlock_program_front_end,
* move the SubVP lock to after the phantom pipes have been
setup
*/
- if (should_lock_all_pipes &&
dc->hwss.interdependent_update_lock) {
- if (dc->hwss.subvp_pipe_control_lock)
- dc->hwss.subvp_pipe_control_lock(dc, context,
false, should_lock_all_pipes, NULL, subvp_prev_use);
- } else {
- if (dc->hwss.subvp_pipe_control_lock)
- dc->hwss.subvp_pipe_control_lock(dc, context,
false, should_lock_all_pipes, NULL, subvp_prev_use);
- }
-
>>>
>>> Perhaps something like:
>>>
>>> if (dc->hwss.subvp_pipe_control_lock)
>>> dc->hwss.subvp_pipe_control_lock(dc, context,
>>> should_lock_all_pipes
>>> &&
>>>
>>> dc->hwss.interdependent_update_lock,
>>> should_lock_all_pipes,
>>> NULL, subvp_prev_use);
>>>
+ if (dc->hwss.subvp_pipe_control_lock)
+ dc->hwss.subvp_pipe_control_lock(dc, context, false,
should_lock_all_pipes,
+ NULL, subvp_prev_use);
return;
}
>>>
>>
>>
>
>
[PATCH v14 14/14] drm/msm/dp: set self refresh aware based on PSR support
For the PSR to kick in, self_refresh_aware has to be set. Initialize it based on the PSR support for the eDP interface. Signed-off-by: Vinod Polimera --- drivers/gpu/drm/msm/dp/dp_drm.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/drivers/gpu/drm/msm/dp/dp_drm.c b/drivers/gpu/drm/msm/dp/dp_drm.c index 029e08c..785d766 100644 --- a/drivers/gpu/drm/msm/dp/dp_drm.c +++ b/drivers/gpu/drm/msm/dp/dp_drm.c @@ -117,6 +117,8 @@ static int edp_bridge_atomic_check(struct drm_bridge *drm_bridge, if (WARN_ON(!conn_state)) return -ENODEV; + conn_state->self_refresh_aware = dp->psr_supported; + if (!conn_state->crtc || !crtc_state) return 0; -- 2.7.4
[PATCH v14 13/14] drm/msm/disp/dpu: update dpu_enc crtc state on crtc enable/disable during self refresh
Populate the enocder software structure to reflect the updated
crtc appropriately during crtc enable/disable for a new commit
while taking care of the self refresh transitions when crtc
disable is triggered from the drm self refresh library.
Signed-off-by: Vinod Polimera
---
drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c | 29 +
1 file changed, 25 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c
b/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c
index 60e5984..b1ec0c3 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c
@@ -1022,8 +1022,17 @@ static void dpu_crtc_disable(struct drm_crtc *crtc,
DRM_DEBUG_KMS("crtc%d\n", crtc->base.id);
- if (old_crtc_state->self_refresh_active)
+ /* If disable is triggered while in self refresh mode,
+* reset the encoder software state so that in enable
+* it won't trigger a warn while assigning crtc.
+*/
+ if (old_crtc_state->self_refresh_active) {
+ drm_for_each_encoder_mask(encoder, crtc->dev,
+ old_crtc_state->encoder_mask) {
+ dpu_encoder_assign_crtc(encoder, NULL);
+ }
return;
+ }
/* Disable/save vblank irq handling */
drm_crtc_vblank_off(crtc);
@@ -1036,7 +1045,14 @@ static void dpu_crtc_disable(struct drm_crtc *crtc,
*/
if (dpu_encoder_get_intf_mode(encoder) == INTF_MODE_VIDEO)
release_bandwidth = true;
- dpu_encoder_assign_crtc(encoder, NULL);
+
+ /*
+* If disable is triggered during psr active(e.g: screen dim in
PSR),
+* we will need encoder->crtc connection to process the device
sleep &
+* preserve it during psr sequence.
+*/
+ if (!crtc->state->self_refresh_active)
+ dpu_encoder_assign_crtc(encoder, NULL);
}
/* wait for frame_event_done completion */
@@ -1084,6 +1100,9 @@ static void dpu_crtc_enable(struct drm_crtc *crtc,
struct dpu_crtc *dpu_crtc = to_dpu_crtc(crtc);
struct drm_encoder *encoder;
bool request_bandwidth = false;
+ struct drm_crtc_state *old_crtc_state;
+
+ old_crtc_state = drm_atomic_get_old_crtc_state(state, crtc);
pm_runtime_get_sync(crtc->dev->dev);
@@ -1106,8 +1125,10 @@ static void dpu_crtc_enable(struct drm_crtc *crtc,
trace_dpu_crtc_enable(DRMID(crtc), true, dpu_crtc);
dpu_crtc->enabled = true;
- drm_for_each_encoder_mask(encoder, crtc->dev, crtc->state->encoder_mask)
- dpu_encoder_assign_crtc(encoder, crtc);
+ if (!old_crtc_state->self_refresh_active) {
+ drm_for_each_encoder_mask(encoder, crtc->dev,
crtc->state->encoder_mask)
+ dpu_encoder_assign_crtc(encoder, crtc);
+ }
/* Enable/restore vblank irq handling */
drm_crtc_vblank_on(crtc);
--
2.7.4
[PATCH v14 12/14] drm/msm/disp/dpu: add PSR support for eDP interface in dpu driver
Enable PSR on eDP interface using drm self-refresh librabry.
This patch uses a trigger from self-refresh library to enter/exit
into PSR, when there are no updates from framework.
Signed-off-by: Kalyan Thota
Signed-off-by: Vinod Polimera
Reviewed-by: Dmitry Baryshkov
---
drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c| 13 -
drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c | 14 ++
drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c | 2 +-
3 files changed, 27 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c
b/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c
index f29a339..60e5984 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c
@@ -21,6 +21,7 @@
#include
#include
#include
+#include
#include "dpu_kms.h"
#include "dpu_hw_lm.h"
@@ -1021,6 +1022,9 @@ static void dpu_crtc_disable(struct drm_crtc *crtc,
DRM_DEBUG_KMS("crtc%d\n", crtc->base.id);
+ if (old_crtc_state->self_refresh_active)
+ return;
+
/* Disable/save vblank irq handling */
drm_crtc_vblank_off(crtc);
@@ -1577,7 +1581,7 @@ struct drm_crtc *dpu_crtc_init(struct drm_device *dev,
struct drm_plane *plane,
{
struct drm_crtc *crtc = NULL;
struct dpu_crtc *dpu_crtc = NULL;
- int i;
+ int i, ret;
dpu_crtc = kzalloc(sizeof(*dpu_crtc), GFP_KERNEL);
if (!dpu_crtc)
@@ -1614,6 +1618,13 @@ struct drm_crtc *dpu_crtc_init(struct drm_device *dev,
struct drm_plane *plane,
/* initialize event handling */
spin_lock_init(_crtc->event_lock);
+ ret = drm_self_refresh_helper_init(crtc);
+ if (ret) {
+ DPU_ERROR("Failed to initialize %s with self-refresh helpers
%d\n",
+ crtc->name, ret);
+ return ERR_PTR(ret);
+ }
+
DRM_DEBUG_KMS("%s: successfully initialized crtc\n", dpu_crtc->name);
return crtc;
}
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
index 01b7509..450abb1 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
@@ -12,6 +12,7 @@
#include
#include
+#include
#include
#include
#include
@@ -1212,11 +1213,24 @@ static void dpu_encoder_virt_atomic_disable(struct
drm_encoder *drm_enc,
struct drm_atomic_state *state)
{
struct dpu_encoder_virt *dpu_enc = NULL;
+ struct drm_crtc *crtc;
+ struct drm_crtc_state *old_state = NULL;
int i = 0;
dpu_enc = to_dpu_encoder_virt(drm_enc);
DPU_DEBUG_ENC(dpu_enc, "\n");
+ crtc = drm_atomic_get_old_crtc_for_encoder(state, drm_enc);
+ if (crtc)
+ old_state = drm_atomic_get_old_crtc_state(state, crtc);
+
+ /*
+* The encoder is already disabled if self refresh mode was set earlier,
+* in the old_state for the corresponding crtc.
+*/
+ if (old_state && old_state->self_refresh_active)
+ return;
+
mutex_lock(_enc->enc_lock);
dpu_enc->enabled = false;
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c
b/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c
index a683bd9..681dd2e 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c
@@ -491,7 +491,7 @@ static void dpu_kms_wait_for_commit_done(struct msm_kms
*kms,
return;
}
- if (!crtc->state->active) {
+ if (!drm_atomic_crtc_effectively_active(crtc->state)) {
DPU_DEBUG("[crtc:%d] not active\n", crtc->base.id);
return;
}
--
2.7.4
[PATCH v14 11/14] drm/msm/disp/dpu: use atomic enable/disable callbacks for encoder functions
Use atomic variants for encoder callback functions such that
certain states like self-refresh can be accessed as part of
enable/disable sequence.
Signed-off-by: Kalyan Thota
Signed-off-by: Vinod Polimera
Reviewed-by: Dmitry Baryshkov
---
drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c | 10 ++
1 file changed, 6 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
index c237003..01b7509 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
@@ -1171,7 +1171,8 @@ void dpu_encoder_virt_runtime_resume(struct drm_encoder
*drm_enc)
mutex_unlock(_enc->enc_lock);
}
-static void dpu_encoder_virt_enable(struct drm_encoder *drm_enc)
+static void dpu_encoder_virt_atomic_enable(struct drm_encoder *drm_enc,
+ struct drm_atomic_state *state)
{
struct dpu_encoder_virt *dpu_enc = NULL;
int ret = 0;
@@ -1207,7 +1208,8 @@ static void dpu_encoder_virt_enable(struct drm_encoder
*drm_enc)
mutex_unlock(_enc->enc_lock);
}
-static void dpu_encoder_virt_disable(struct drm_encoder *drm_enc)
+static void dpu_encoder_virt_atomic_disable(struct drm_encoder *drm_enc,
+ struct drm_atomic_state *state)
{
struct dpu_encoder_virt *dpu_enc = NULL;
int i = 0;
@@ -2388,8 +2390,8 @@ static void dpu_encoder_frame_done_timeout(struct
timer_list *t)
static const struct drm_encoder_helper_funcs dpu_encoder_helper_funcs = {
.atomic_mode_set = dpu_encoder_virt_atomic_mode_set,
- .disable = dpu_encoder_virt_disable,
- .enable = dpu_encoder_virt_enable,
+ .atomic_disable = dpu_encoder_virt_atomic_disable,
+ .atomic_enable = dpu_encoder_virt_atomic_enable,
.atomic_check = dpu_encoder_virt_atomic_check,
};
--
2.7.4
[PATCH v14 10/14] drm/msm/dp: use the eDP bridge ops to validate eDP modes
The eDP and DP interfaces shared the bridge operations and
the eDP specific changes were implemented under is_edp check.
To add psr support for eDP, we started using a new set of eDP
bridge ops. We are moving the eDP specific code in the
dp_bridge_mode_valid function to a new eDP function,
edp_bridge_mode_valid under the eDP bridge ops.
Signed-off-by: Sankeerth Billakanti
Signed-off-by: Vinod Polimera
Reviewed-by: Dmitry Baryshkov
---
drivers/gpu/drm/msm/dp/dp_display.c | 8
drivers/gpu/drm/msm/dp/dp_drm.c | 34 +-
2 files changed, 33 insertions(+), 9 deletions(-)
diff --git a/drivers/gpu/drm/msm/dp/dp_display.c
b/drivers/gpu/drm/msm/dp/dp_display.c
index 86ed80c..ffb21a6 100644
--- a/drivers/gpu/drm/msm/dp/dp_display.c
+++ b/drivers/gpu/drm/msm/dp/dp_display.c
@@ -996,14 +996,6 @@ enum drm_mode_status dp_bridge_mode_valid(struct
drm_bridge *bridge,
return -EINVAL;
}
- /*
-* The eDP controller currently does not have a reliable way of
-* enabling panel power to read sink capabilities. So, we rely
-* on the panel driver to populate only supported modes for now.
-*/
- if (dp->is_edp)
- return MODE_OK;
-
if (mode->clock > DP_MAX_PIXEL_CLK_KHZ)
return MODE_CLOCK_HIGH;
diff --git a/drivers/gpu/drm/msm/dp/dp_drm.c b/drivers/gpu/drm/msm/dp/dp_drm.c
index 3b38bd9..029e08c 100644
--- a/drivers/gpu/drm/msm/dp/dp_drm.c
+++ b/drivers/gpu/drm/msm/dp/dp_drm.c
@@ -226,12 +226,44 @@ static void edp_bridge_atomic_post_disable(struct
drm_bridge *drm_bridge,
dp_bridge_atomic_post_disable(drm_bridge, old_bridge_state);
}
+/**
+ * edp_bridge_mode_valid - callback to determine if specified mode is valid
+ * @bridge: Pointer to drm bridge structure
+ * @info: display info
+ * @mode: Pointer to drm mode structure
+ * Returns: Validity status for specified mode
+ */
+static enum drm_mode_status edp_bridge_mode_valid(struct drm_bridge *bridge,
+ const struct drm_display_info *info,
+ const struct drm_display_mode *mode)
+{
+ struct msm_dp *dp;
+ int mode_pclk_khz = mode->clock;
+
+ dp = to_dp_bridge(bridge)->dp_display;
+
+ if (!dp || !mode_pclk_khz || !dp->connector) {
+ DRM_ERROR("invalid params\n");
+ return -EINVAL;
+ }
+
+ if (mode->clock > DP_MAX_PIXEL_CLK_KHZ)
+ return MODE_CLOCK_HIGH;
+
+ /*
+* The eDP controller currently does not have a reliable way of
+* enabling panel power to read sink capabilities. So, we rely
+* on the panel driver to populate only supported modes for now.
+*/
+ return MODE_OK;
+}
+
static const struct drm_bridge_funcs edp_bridge_ops = {
.atomic_enable = edp_bridge_atomic_enable,
.atomic_disable = edp_bridge_atomic_disable,
.atomic_post_disable = edp_bridge_atomic_post_disable,
.mode_set = dp_bridge_mode_set,
- .mode_valid = dp_bridge_mode_valid,
+ .mode_valid = edp_bridge_mode_valid,
.atomic_reset = drm_atomic_helper_bridge_reset,
.atomic_duplicate_state = drm_atomic_helper_bridge_duplicate_state,
.atomic_destroy_state = drm_atomic_helper_bridge_destroy_state,
--
2.7.4
[PATCH v14 09/14] drm/msm/dp: Add basic PSR support for eDP
Add support for basic panel self refresh (PSR) feature for eDP.
Add a new interface to set PSR state in the sink from DPU.
Program the eDP controller to issue PSR enter and exit SDP to
the sink.
Signed-off-by: Sankeerth Billakanti
Signed-off-by: Vinod Polimera
Reviewed-by: Dmitry Baryshkov
---
drivers/gpu/drm/msm/dp/dp_catalog.c | 80 ++
drivers/gpu/drm/msm/dp/dp_catalog.h | 4 ++
drivers/gpu/drm/msm/dp/dp_ctrl.c| 80 ++
drivers/gpu/drm/msm/dp/dp_ctrl.h| 3 +
drivers/gpu/drm/msm/dp/dp_display.c | 19 ++
drivers/gpu/drm/msm/dp/dp_display.h | 2 +
drivers/gpu/drm/msm/dp/dp_drm.c | 133 +++-
drivers/gpu/drm/msm/dp/dp_link.c| 36 ++
drivers/gpu/drm/msm/dp/dp_panel.c | 22 ++
drivers/gpu/drm/msm/dp/dp_panel.h | 6 ++
drivers/gpu/drm/msm/dp/dp_reg.h | 27
11 files changed, 411 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/msm/dp/dp_catalog.c
b/drivers/gpu/drm/msm/dp/dp_catalog.c
index 676279d..c12a5d9 100644
--- a/drivers/gpu/drm/msm/dp/dp_catalog.c
+++ b/drivers/gpu/drm/msm/dp/dp_catalog.c
@@ -47,6 +47,14 @@
#define DP_INTERRUPT_STATUS2_MASK \
(DP_INTERRUPT_STATUS2 << DP_INTERRUPT_STATUS_MASK_SHIFT)
+#define DP_INTERRUPT_STATUS4 \
+ (PSR_UPDATE_INT | PSR_CAPTURE_INT | PSR_EXIT_INT | \
+ PSR_UPDATE_ERROR_INT | PSR_WAKE_ERROR_INT)
+
+#define DP_INTERRUPT_MASK4 \
+ (PSR_UPDATE_MASK | PSR_CAPTURE_MASK | PSR_EXIT_MASK | \
+ PSR_UPDATE_ERROR_MASK | PSR_WAKE_ERROR_MASK)
+
struct dp_catalog_private {
struct device *dev;
struct drm_device *drm_dev;
@@ -359,6 +367,23 @@ void dp_catalog_ctrl_lane_mapping(struct dp_catalog
*dp_catalog)
ln_mapping);
}
+void dp_catalog_ctrl_psr_mainlink_enable(struct dp_catalog *dp_catalog,
+ bool enable)
+{
+ u32 val;
+ struct dp_catalog_private *catalog = container_of(dp_catalog,
+ struct dp_catalog_private, dp_catalog);
+
+ val = dp_read_link(catalog, REG_DP_MAINLINK_CTRL);
+
+ if (enable)
+ val |= DP_MAINLINK_CTRL_ENABLE;
+ else
+ val &= ~DP_MAINLINK_CTRL_ENABLE;
+
+ dp_write_link(catalog, REG_DP_MAINLINK_CTRL, val);
+}
+
void dp_catalog_ctrl_mainlink_ctrl(struct dp_catalog *dp_catalog,
bool enable)
{
@@ -610,6 +635,47 @@ void dp_catalog_ctrl_hpd_config(struct dp_catalog
*dp_catalog)
dp_write_aux(catalog, REG_DP_DP_HPD_CTRL, DP_DP_HPD_CTRL_HPD_EN);
}
+static void dp_catalog_enable_sdp(struct dp_catalog_private *catalog)
+{
+ /* trigger sdp */
+ dp_write_link(catalog, MMSS_DP_SDP_CFG3, UPDATE_SDP);
+ dp_write_link(catalog, MMSS_DP_SDP_CFG3, 0x0);
+}
+
+void dp_catalog_ctrl_config_psr(struct dp_catalog *dp_catalog)
+{
+ struct dp_catalog_private *catalog = container_of(dp_catalog,
+ struct dp_catalog_private, dp_catalog);
+ u32 config;
+
+ /* enable PSR1 function */
+ config = dp_read_link(catalog, REG_PSR_CONFIG);
+ config |= PSR1_SUPPORTED;
+ dp_write_link(catalog, REG_PSR_CONFIG, config);
+
+ dp_write_ahb(catalog, REG_DP_INTR_MASK4, DP_INTERRUPT_MASK4);
+ dp_catalog_enable_sdp(catalog);
+}
+
+void dp_catalog_ctrl_set_psr(struct dp_catalog *dp_catalog, bool enter)
+{
+ struct dp_catalog_private *catalog = container_of(dp_catalog,
+ struct dp_catalog_private, dp_catalog);
+ u32 cmd;
+
+ cmd = dp_read_link(catalog, REG_PSR_CMD);
+
+ cmd &= ~(PSR_ENTER | PSR_EXIT);
+
+ if (enter)
+ cmd |= PSR_ENTER;
+ else
+ cmd |= PSR_EXIT;
+
+ dp_catalog_enable_sdp(catalog);
+ dp_write_link(catalog, REG_PSR_CMD, cmd);
+}
+
u32 dp_catalog_link_is_connected(struct dp_catalog *dp_catalog)
{
struct dp_catalog_private *catalog = container_of(dp_catalog,
@@ -645,6 +711,20 @@ u32 dp_catalog_hpd_get_intr_status(struct dp_catalog
*dp_catalog)
return isr & (mask | ~DP_DP_HPD_INT_MASK);
}
+u32 dp_catalog_ctrl_read_psr_interrupt_status(struct dp_catalog *dp_catalog)
+{
+ struct dp_catalog_private *catalog = container_of(dp_catalog,
+ struct dp_catalog_private, dp_catalog);
+ u32 intr, intr_ack;
+
+ intr = dp_read_ahb(catalog, REG_DP_INTR_STATUS4);
+ intr_ack = (intr & DP_INTERRUPT_STATUS4)
+ << DP_INTERRUPT_STATUS_ACK_SHIFT;
+ dp_write_ahb(catalog, REG_DP_INTR_STATUS4, intr_ack);
+
+ return intr;
+}
+
int dp_catalog_ctrl_get_interrupt(struct dp_catalog *dp_catalog)
{
struct dp_catalog_private *catalog = container_of(dp_catalog,
diff --git a/drivers/gpu/drm/msm/dp/dp_catalog.h
b/drivers/gpu/drm/msm/dp/dp_catalog.h
index 1f717f4..2174bb5 100644
---
[PATCH v14 08/14] drm/msm/dp: use atomic callbacks for DP bridge ops
Use atomic variants for DP bridge callback functions so that
the atomic state can be accessed in the interface drivers.
The atomic state will help the driver find out if the display
is in self refresh state.
Signed-off-by: Sankeerth Billakanti
Signed-off-by: Vinod Polimera
Reviewed-by: Dmitry Baryshkov
Reviewed-by: Douglas Anderson
---
drivers/gpu/drm/msm/dp/dp_display.c | 9 ++---
drivers/gpu/drm/msm/dp/dp_drm.c | 6 +++---
drivers/gpu/drm/msm/dp/dp_drm.h | 9 ++---
3 files changed, 15 insertions(+), 9 deletions(-)
diff --git a/drivers/gpu/drm/msm/dp/dp_display.c
b/drivers/gpu/drm/msm/dp/dp_display.c
index bde1a7c..985287e 100644
--- a/drivers/gpu/drm/msm/dp/dp_display.c
+++ b/drivers/gpu/drm/msm/dp/dp_display.c
@@ -1652,7 +1652,8 @@ int msm_dp_modeset_init(struct msm_dp *dp_display, struct
drm_device *dev,
return 0;
}
-void dp_bridge_enable(struct drm_bridge *drm_bridge)
+void dp_bridge_atomic_enable(struct drm_bridge *drm_bridge,
+struct drm_bridge_state *old_bridge_state)
{
struct msm_dp_bridge *dp_bridge = to_dp_bridge(drm_bridge);
struct msm_dp *dp = dp_bridge->dp_display;
@@ -1707,7 +1708,8 @@ void dp_bridge_enable(struct drm_bridge *drm_bridge)
mutex_unlock(_display->event_mutex);
}
-void dp_bridge_disable(struct drm_bridge *drm_bridge)
+void dp_bridge_atomic_disable(struct drm_bridge *drm_bridge,
+ struct drm_bridge_state *old_bridge_state)
{
struct msm_dp_bridge *dp_bridge = to_dp_bridge(drm_bridge);
struct msm_dp *dp = dp_bridge->dp_display;
@@ -1718,7 +1720,8 @@ void dp_bridge_disable(struct drm_bridge *drm_bridge)
dp_ctrl_push_idle(dp_display->ctrl);
}
-void dp_bridge_post_disable(struct drm_bridge *drm_bridge)
+void dp_bridge_atomic_post_disable(struct drm_bridge *drm_bridge,
+ struct drm_bridge_state *old_bridge_state)
{
struct msm_dp_bridge *dp_bridge = to_dp_bridge(drm_bridge);
struct msm_dp *dp = dp_bridge->dp_display;
diff --git a/drivers/gpu/drm/msm/dp/dp_drm.c b/drivers/gpu/drm/msm/dp/dp_drm.c
index 275370f..3252d50 100644
--- a/drivers/gpu/drm/msm/dp/dp_drm.c
+++ b/drivers/gpu/drm/msm/dp/dp_drm.c
@@ -94,9 +94,9 @@ static const struct drm_bridge_funcs dp_bridge_ops = {
.atomic_duplicate_state = drm_atomic_helper_bridge_duplicate_state,
.atomic_destroy_state = drm_atomic_helper_bridge_destroy_state,
.atomic_reset = drm_atomic_helper_bridge_reset,
- .enable = dp_bridge_enable,
- .disable = dp_bridge_disable,
- .post_disable = dp_bridge_post_disable,
+ .atomic_enable = dp_bridge_atomic_enable,
+ .atomic_disable = dp_bridge_atomic_disable,
+ .atomic_post_disable= dp_bridge_atomic_post_disable,
.mode_set = dp_bridge_mode_set,
.mode_valid = dp_bridge_mode_valid,
.get_modes= dp_bridge_get_modes,
diff --git a/drivers/gpu/drm/msm/dp/dp_drm.h b/drivers/gpu/drm/msm/dp/dp_drm.h
index 250f7c6..afe79b8 100644
--- a/drivers/gpu/drm/msm/dp/dp_drm.h
+++ b/drivers/gpu/drm/msm/dp/dp_drm.h
@@ -23,9 +23,12 @@ struct drm_connector *dp_drm_connector_init(struct msm_dp
*dp_display, struct dr
struct drm_bridge *dp_bridge_init(struct msm_dp *dp_display, struct drm_device
*dev,
struct drm_encoder *encoder);
-void dp_bridge_enable(struct drm_bridge *drm_bridge);
-void dp_bridge_disable(struct drm_bridge *drm_bridge);
-void dp_bridge_post_disable(struct drm_bridge *drm_bridge);
+void dp_bridge_atomic_enable(struct drm_bridge *drm_bridge,
+struct drm_bridge_state *old_bridge_state);
+void dp_bridge_atomic_disable(struct drm_bridge *drm_bridge,
+ struct drm_bridge_state *old_bridge_state);
+void dp_bridge_atomic_post_disable(struct drm_bridge *drm_bridge,
+ struct drm_bridge_state *old_bridge_state);
enum drm_mode_status dp_bridge_mode_valid(struct drm_bridge *bridge,
const struct drm_display_info *info,
const struct drm_display_mode *mode);
--
2.7.4
[PATCH v14 06/14] drm/msm/disp/dpu: wait for extra vsync till timing engine status is disabled
There can be a race between timing gen disable and vblank irq. The
wait post timing gen disable may return early but intf disable sequence
might not be completed. Ensure that, intf status is disabled before
we retire the function.
Signed-off-by: Vinod Polimera
Reviewed-by: Dmitry Baryshkov
---
.../gpu/drm/msm/disp/dpu1/dpu_encoder_phys_vid.c| 21 +
1 file changed, 21 insertions(+)
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys_vid.c
b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys_vid.c
index 48c4810..0396084 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys_vid.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys_vid.c
@@ -523,6 +523,7 @@ static void dpu_encoder_phys_vid_disable(struct
dpu_encoder_phys *phys_enc)
{
unsigned long lock_flags;
int ret;
+ struct intf_status intf_status = {0};
if (!phys_enc->parent || !phys_enc->parent->dev) {
DPU_ERROR("invalid encoder/device\n");
@@ -567,6 +568,26 @@ static void dpu_encoder_phys_vid_disable(struct
dpu_encoder_phys *phys_enc)
}
}
+ if (phys_enc->hw_intf && phys_enc->hw_intf->ops.get_status)
+ phys_enc->hw_intf->ops.get_status(phys_enc->hw_intf,
_status);
+
+ /*
+* Wait for a vsync if timing en status is on after timing engine
+* is disabled.
+*/
+ if (intf_status.is_en && dpu_encoder_phys_vid_is_master(phys_enc)) {
+ spin_lock_irqsave(phys_enc->enc_spinlock, lock_flags);
+ dpu_encoder_phys_inc_pending(phys_enc);
+ spin_unlock_irqrestore(phys_enc->enc_spinlock, lock_flags);
+ ret = dpu_encoder_phys_vid_wait_for_vblank(phys_enc);
+ if (ret) {
+ atomic_set(_enc->pending_kickoff_cnt, 0);
+ DRM_ERROR("wait disable failed: id:%u intf:%d ret:%d\n",
+ DRMID(phys_enc->parent),
+ phys_enc->hw_intf->idx - INTF_0, ret);
+ }
+ }
+
phys_enc->enable_state = DPU_ENC_DISABLED;
}
--
2.7.4
[PATCH v14 07/14] drm/msm/disp/dpu: reset the datapath after timing engine disable
Reset the datapath after disabling the timing gen, such that it can start on a clean slate when the intf is enabled back. This was a recommended sequence from the DPU HW programming guide. Signed-off-by: Vinod Polimera Reviewed-by: Dmitry Baryshkov --- drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys_vid.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys_vid.c b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys_vid.c index 0396084..3a37429 100644 --- a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys_vid.c +++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys_vid.c @@ -588,6 +588,7 @@ static void dpu_encoder_phys_vid_disable(struct dpu_encoder_phys *phys_enc) } } + dpu_encoder_helper_phys_cleanup(phys_enc); phys_enc->enable_state = DPU_ENC_DISABLED; } -- 2.7.4
[PATCH v14 04/14] drm/msm/disp/dpu: check for crtc enable rather than crtc active to release shared resources
According to KMS documentation, The driver must not release any shared
resources if active is set to false but enable still true.
Fixes: ccc862b957c6 ("drm/msm/dpu: Fix reservation failures in modeset")
Signed-off-by: Vinod Polimera
Reviewed-by: Dmitry Baryshkov
---
drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
index 758261e..c237003 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
@@ -652,7 +652,7 @@ static int dpu_encoder_virt_atomic_check(
if (drm_atomic_crtc_needs_modeset(crtc_state)) {
dpu_rm_release(global_state, drm_enc);
- if (!crtc_state->active_changed || crtc_state->active)
+ if (!crtc_state->active_changed || crtc_state->enable)
ret = dpu_rm_reserve(_kms->rm, global_state,
drm_enc, crtc_state, topology);
}
--
2.7.4
[PATCH v14 05/14] drm/msm/disp/dpu: get timing engine status from intf status register
Recommended way of reading the interface timing gen status is via
status register. Timing gen status register will give a reliable status
of the interface especially during ON/OFF transitions. This support was
added from DPU version 5.0.0.
Signed-off-by: Vinod Polimera
Reviewed-by: Dmitry Baryshkov
---
drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c | 3 ++-
drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.h | 12 +++-
drivers/gpu/drm/msm/disp/dpu1/dpu_hw_intf.c| 8 +++-
3 files changed, 16 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c
b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c
index cf053e8..85b29d6 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c
@@ -78,7 +78,8 @@
#define INTF_SDM845_MASK (0)
-#define INTF_SC7180_MASK BIT(DPU_INTF_INPUT_CTRL) | BIT(DPU_INTF_TE)
+#define INTF_SC7180_MASK \
+ (BIT(DPU_INTF_INPUT_CTRL) | BIT(DPU_INTF_TE) |
BIT(DPU_INTF_STATUS_SUPPORTED))
#define INTF_SC7280_MASK INTF_SC7180_MASK | BIT(DPU_DATA_HCTL_EN)
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.h
b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.h
index ddab9ca..08cd1a1 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.h
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.h
@@ -213,17 +213,19 @@ enum {
/**
* INTF sub-blocks
- * @DPU_INTF_INPUT_CTRL Supports the setting of pp block from which
- * pixel data arrives to this INTF
- * @DPU_INTF_TE INTF block has TE configuration support
- * @DPU_DATA_HCTL_ENAllows data to be transferred at different rate
-than video timing
+ * @DPU_INTF_INPUT_CTRL Supports the setting of pp block from which
+ * pixel data arrives to this INTF
+ * @DPU_INTF_TE INTF block has TE configuration support
+ * @DPU_DATA_HCTL_ENAllows data to be transferred at different
rate
+ * than video timing
+ * @DPU_INTF_STATUS_SUPPORTED INTF block has INTF_STATUS register
* @DPU_INTF_MAX
*/
enum {
DPU_INTF_INPUT_CTRL = 0x1,
DPU_INTF_TE,
DPU_DATA_HCTL_EN,
+ DPU_INTF_STATUS_SUPPORTED,
DPU_INTF_MAX
};
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_intf.c
b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_intf.c
index 7ce66bf..84ee2ef 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_intf.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_intf.c
@@ -62,6 +62,7 @@
#define INTF_LINE_COUNT 0x0B0
#define INTF_MUX 0x25C
+#define INTF_STATUS 0x26C
#define INTF_CFG_ACTIVE_H_EN BIT(29)
#define INTF_CFG_ACTIVE_V_EN BIT(30)
@@ -297,8 +298,13 @@ static void dpu_hw_intf_get_status(
struct intf_status *s)
{
struct dpu_hw_blk_reg_map *c = >hw;
+ unsigned long cap = intf->cap->features;
+
+ if (cap & BIT(DPU_INTF_STATUS_SUPPORTED))
+ s->is_en = DPU_REG_READ(c, INTF_STATUS) & BIT(0);
+ else
+ s->is_en = DPU_REG_READ(c, INTF_TIMING_ENGINE_EN);
- s->is_en = DPU_REG_READ(c, INTF_TIMING_ENGINE_EN);
s->is_prog_fetch_en = !!(DPU_REG_READ(c, INTF_CONFIG) & BIT(31));
if (s->is_en) {
s->frame_count = DPU_REG_READ(c, INTF_FRAME_COUNT);
--
2.7.4
[PATCH v14 03/14] drm/bridge: add psr support for panel bridge callbacks
This change will handle the psr entry exit cases in the panel
bridge atomic callback functions. For example, the panel power
should not turn off if the panel is entering psr.
Signed-off-by: Sankeerth Billakanti
Signed-off-by: Vinod Polimera
Reviewed-by: Daniel Vetter
---
drivers/gpu/drm/bridge/panel.c | 48 ++
1 file changed, 48 insertions(+)
diff --git a/drivers/gpu/drm/bridge/panel.c b/drivers/gpu/drm/bridge/panel.c
index 04e9fb0..a2c6f30 100644
--- a/drivers/gpu/drm/bridge/panel.c
+++ b/drivers/gpu/drm/bridge/panel.c
@@ -113,6 +113,18 @@ static void panel_bridge_atomic_pre_enable(struct
drm_bridge *bridge,
struct drm_bridge_state *old_bridge_state)
{
struct panel_bridge *panel_bridge = drm_bridge_to_panel_bridge(bridge);
+ struct drm_atomic_state *atomic_state = old_bridge_state->base.state;
+ struct drm_encoder *encoder = bridge->encoder;
+ struct drm_crtc *crtc;
+ struct drm_crtc_state *old_crtc_state;
+
+ crtc = drm_atomic_get_new_crtc_for_encoder(atomic_state, encoder);
+ if (!crtc)
+ return;
+
+ old_crtc_state = drm_atomic_get_old_crtc_state(atomic_state, crtc);
+ if (old_crtc_state && old_crtc_state->self_refresh_active)
+ return;
drm_panel_prepare(panel_bridge->panel);
}
@@ -121,6 +133,18 @@ static void panel_bridge_atomic_enable(struct drm_bridge
*bridge,
struct drm_bridge_state *old_bridge_state)
{
struct panel_bridge *panel_bridge = drm_bridge_to_panel_bridge(bridge);
+ struct drm_atomic_state *atomic_state = old_bridge_state->base.state;
+ struct drm_encoder *encoder = bridge->encoder;
+ struct drm_crtc *crtc;
+ struct drm_crtc_state *old_crtc_state;
+
+ crtc = drm_atomic_get_new_crtc_for_encoder(atomic_state, encoder);
+ if (!crtc)
+ return;
+
+ old_crtc_state = drm_atomic_get_old_crtc_state(atomic_state, crtc);
+ if (old_crtc_state && old_crtc_state->self_refresh_active)
+ return;
drm_panel_enable(panel_bridge->panel);
}
@@ -129,6 +153,18 @@ static void panel_bridge_atomic_disable(struct drm_bridge
*bridge,
struct drm_bridge_state *old_bridge_state)
{
struct panel_bridge *panel_bridge = drm_bridge_to_panel_bridge(bridge);
+ struct drm_atomic_state *atomic_state = old_bridge_state->base.state;
+ struct drm_encoder *encoder = bridge->encoder;
+ struct drm_crtc *crtc;
+ struct drm_crtc_state *new_crtc_state;
+
+ crtc = drm_atomic_get_old_crtc_for_encoder(atomic_state, encoder);
+ if (!crtc)
+ return;
+
+ new_crtc_state = drm_atomic_get_new_crtc_state(atomic_state, crtc);
+ if (new_crtc_state && new_crtc_state->self_refresh_active)
+ return;
drm_panel_disable(panel_bridge->panel);
}
@@ -137,6 +173,18 @@ static void panel_bridge_atomic_post_disable(struct
drm_bridge *bridge,
struct drm_bridge_state *old_bridge_state)
{
struct panel_bridge *panel_bridge = drm_bridge_to_panel_bridge(bridge);
+ struct drm_atomic_state *atomic_state = old_bridge_state->base.state;
+ struct drm_encoder *encoder = bridge->encoder;
+ struct drm_crtc *crtc;
+ struct drm_crtc_state *new_crtc_state;
+
+ crtc = drm_atomic_get_old_crtc_for_encoder(atomic_state, encoder);
+ if (!crtc)
+ return;
+
+ new_crtc_state = drm_atomic_get_new_crtc_state(atomic_state, crtc);
+ if (new_crtc_state && new_crtc_state->self_refresh_active)
+ return;
drm_panel_unprepare(panel_bridge->panel);
}
--
2.7.4
[PATCH v14 02/14] drm/bridge: use atomic enable/disable callbacks for panel bridge
Use atomic variants for panel bridge callback functions such that
certain states like self-refresh can be accessed as part of
enable/disable sequence.
Signed-off-by: Sankeerth Billakanti
Signed-off-by: Vinod Polimera
Reviewed-by: Dmitry Baryshkov
Reviewed-by: Daniel Vetter
---
drivers/gpu/drm/bridge/panel.c | 20
1 file changed, 12 insertions(+), 8 deletions(-)
diff --git a/drivers/gpu/drm/bridge/panel.c b/drivers/gpu/drm/bridge/panel.c
index e8aae3c..04e9fb0 100644
--- a/drivers/gpu/drm/bridge/panel.c
+++ b/drivers/gpu/drm/bridge/panel.c
@@ -109,28 +109,32 @@ static void panel_bridge_detach(struct drm_bridge *bridge)
drm_connector_cleanup(connector);
}
-static void panel_bridge_pre_enable(struct drm_bridge *bridge)
+static void panel_bridge_atomic_pre_enable(struct drm_bridge *bridge,
+ struct drm_bridge_state *old_bridge_state)
{
struct panel_bridge *panel_bridge = drm_bridge_to_panel_bridge(bridge);
drm_panel_prepare(panel_bridge->panel);
}
-static void panel_bridge_enable(struct drm_bridge *bridge)
+static void panel_bridge_atomic_enable(struct drm_bridge *bridge,
+ struct drm_bridge_state *old_bridge_state)
{
struct panel_bridge *panel_bridge = drm_bridge_to_panel_bridge(bridge);
drm_panel_enable(panel_bridge->panel);
}
-static void panel_bridge_disable(struct drm_bridge *bridge)
+static void panel_bridge_atomic_disable(struct drm_bridge *bridge,
+ struct drm_bridge_state *old_bridge_state)
{
struct panel_bridge *panel_bridge = drm_bridge_to_panel_bridge(bridge);
drm_panel_disable(panel_bridge->panel);
}
-static void panel_bridge_post_disable(struct drm_bridge *bridge)
+static void panel_bridge_atomic_post_disable(struct drm_bridge *bridge,
+ struct drm_bridge_state *old_bridge_state)
{
struct panel_bridge *panel_bridge = drm_bridge_to_panel_bridge(bridge);
@@ -159,10 +163,10 @@ static void panel_bridge_debugfs_init(struct drm_bridge
*bridge,
static const struct drm_bridge_funcs panel_bridge_bridge_funcs = {
.attach = panel_bridge_attach,
.detach = panel_bridge_detach,
- .pre_enable = panel_bridge_pre_enable,
- .enable = panel_bridge_enable,
- .disable = panel_bridge_disable,
- .post_disable = panel_bridge_post_disable,
+ .atomic_pre_enable = panel_bridge_atomic_pre_enable,
+ .atomic_enable = panel_bridge_atomic_enable,
+ .atomic_disable = panel_bridge_atomic_disable,
+ .atomic_post_disable = panel_bridge_atomic_post_disable,
.get_modes = panel_bridge_get_modes,
.atomic_reset = drm_atomic_helper_bridge_reset,
.atomic_duplicate_state = drm_atomic_helper_bridge_duplicate_state,
--
2.7.4
[PATCH v14 01/14] drm: add helper functions to retrieve old and new crtc
Add new helper functions, drm_atomic_get_old_crtc_for_encoder
and drm_atomic_get_new_crtc_for_encoder to retrieve the
corresponding crtc for the encoder.
Signed-off-by: Sankeerth Billakanti
Signed-off-by: Vinod Polimera
Reviewed-by: Douglas Anderson
Reviewed-by: Daniel Vetter
---
drivers/gpu/drm/drm_atomic.c | 60
include/drm/drm_atomic.h | 7 ++
2 files changed, 67 insertions(+)
diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
index 5457c02..7cc39f6 100644
--- a/drivers/gpu/drm/drm_atomic.c
+++ b/drivers/gpu/drm/drm_atomic.c
@@ -985,6 +985,66 @@ drm_atomic_get_new_connector_for_encoder(const struct
drm_atomic_state *state,
EXPORT_SYMBOL(drm_atomic_get_new_connector_for_encoder);
/**
+ * drm_atomic_get_old_crtc_for_encoder - Get old crtc for an encoder
+ * @state: Atomic state
+ * @encoder: The encoder to fetch the crtc state for
+ *
+ * This function finds and returns the crtc that was connected to @encoder
+ * as specified by the @state.
+ *
+ * Returns: The old crtc connected to @encoder, or NULL if the encoder is
+ * not connected.
+ */
+struct drm_crtc *
+drm_atomic_get_old_crtc_for_encoder(struct drm_atomic_state *state,
+ struct drm_encoder *encoder)
+{
+ struct drm_connector *connector;
+ struct drm_connector_state *conn_state;
+
+ connector = drm_atomic_get_old_connector_for_encoder(state, encoder);
+ if (!connector)
+ return NULL;
+
+ conn_state = drm_atomic_get_old_connector_state(state, connector);
+ if (!conn_state)
+ return NULL;
+
+ return conn_state->crtc;
+}
+EXPORT_SYMBOL(drm_atomic_get_old_crtc_for_encoder);
+
+/**
+ * drm_atomic_get_new_crtc_for_encoder - Get new crtc for an encoder
+ * @state: Atomic state
+ * @encoder: The encoder to fetch the crtc state for
+ *
+ * This function finds and returns the crtc that will be connected to @encoder
+ * as specified by the @state.
+ *
+ * Returns: The new crtc connected to @encoder, or NULL if the encoder is
+ * not connected.
+ */
+struct drm_crtc *
+drm_atomic_get_new_crtc_for_encoder(struct drm_atomic_state *state,
+ struct drm_encoder *encoder)
+{
+ struct drm_connector *connector;
+ struct drm_connector_state *conn_state;
+
+ connector = drm_atomic_get_new_connector_for_encoder(state, encoder);
+ if (!connector)
+ return NULL;
+
+ conn_state = drm_atomic_get_new_connector_state(state, connector);
+ if (!conn_state)
+ return NULL;
+
+ return conn_state->crtc;
+}
+EXPORT_SYMBOL(drm_atomic_get_new_crtc_for_encoder);
+
+/**
* drm_atomic_get_connector_state - get connector state
* @state: global atomic state object
* @connector: connector to get state object for
diff --git a/include/drm/drm_atomic.h b/include/drm/drm_atomic.h
index 92586ab..9a022ca 100644
--- a/include/drm/drm_atomic.h
+++ b/include/drm/drm_atomic.h
@@ -528,6 +528,13 @@ struct drm_connector *
drm_atomic_get_new_connector_for_encoder(const struct drm_atomic_state *state,
struct drm_encoder *encoder);
+struct drm_crtc *
+drm_atomic_get_old_crtc_for_encoder(struct drm_atomic_state *state,
+struct drm_encoder *encoder);
+struct drm_crtc *
+drm_atomic_get_new_crtc_for_encoder(struct drm_atomic_state *state,
+struct drm_encoder *encoder);
+
/**
* drm_atomic_get_existing_crtc_state - get CRTC state, if it exists
* @state: global atomic state object
--
2.7.4
[PATCH v14 00/14] Add PSR support for eDP
Changes in v2: - Use dp bridge to set psr entry/exit instead of dpu_enocder. - Don't modify whitespaces. - Set self refresh aware from atomic_check. - Set self refresh aware only if psr is supported. - Provide a stub for msm_dp_display_set_psr. - Move dp functions to bridge code. Changes in v3: - Change callback names to reflect atomic interfaces. - Move bridge callback change to separate patch as suggested by Dmitry. - Remove psr function declaration from msm_drv.h. - Set self_refresh_aware flag only if psr is supported. - Modify the variable names to simpler form. - Define bit fields for PSR settings. - Add comments explaining the steps to enter/exit psr. - Change DRM_INFO to drm_dbg_db. Changes in v4: - Move the get crtc functions to drm_atomic. - Add atomic functions for DP bridge too. - Add ternary operator to choose eDP or DP ops. - Return true/false instead of 1/0. - mode_valid missing in the eDP bridge ops. - Move the functions to get crtc into drm_atomic.c. - Fix compilation issues. - Remove dpu_assign_crtc and get crtc from drm_enc instead of dpu_enc. - Check for crtc state enable while reserving resources. Changes in v5: - Move the mode_valid changes into a different patch. - Complete psr_op_comp only when isr is set. - Move the DP atomic callback changes to a different patch. - Get crtc from drm connector state crtc. - Move to separate patch for check for crtc state enable while reserving resources. Changes in v6: - Remove crtc from dpu_encoder_virt struct. - fix crtc check during vblank toggle crtc. - Misc changes. Changes in v7: - Add fix for underrun issue on kasan build. Changes in v8: - Drop the enc spinlock as it won't serve any purpose in protetcing conn state.(Dmitry/Doug) Changes in v9: - Update commit message and fix alignment using spaces.(Marijn) - Misc changes.(Marijn) Changes in v10: - Get crtc cached in dpu_enc during obj init.(Dmitry) Changes in v11: - Remove crtc cached in dpu_enc during obj init. - Update dpu_enc crtc state on crtc enable/disable during self refresh. Changes in v12: - Update sc7180 intf mask to get intf timing gen status based on DPU_INTF_STATUS_SUPPORTED bit.(Dmitry) - Remove "clear active interface in the datapath cleanup" change as it is already included. Changes in v13: - Move core changes to top of the series.(Dmitry) - Drop self refresh aware disable change after psr entry.(Dmitry) Changes in v14: - Set self_refresh_aware for the PSR to kick in. Vinod Polimera (14): drm: add helper functions to retrieve old and new crtc drm/bridge: use atomic enable/disable callbacks for panel bridge drm/bridge: add psr support for panel bridge callbacks drm/msm/disp/dpu: check for crtc enable rather than crtc active to release shared resources drm/msm/disp/dpu: get timing engine status from intf status register drm/msm/disp/dpu: wait for extra vsync till timing engine status is disabled drm/msm/disp/dpu: reset the datapath after timing engine disable drm/msm/dp: use atomic callbacks for DP bridge ops drm/msm/dp: Add basic PSR support for eDP drm/msm/dp: use the eDP bridge ops to validate eDP modes drm/msm/disp/dpu: use atomic enable/disable callbacks for encoder functions drm/msm/disp/dpu: add PSR support for eDP interface in dpu driver drm/msm/disp/dpu: update dpu_enc crtc state on crtc enable/disable during self refresh drm/msm/dp: set self refresh aware based on psr support drivers/gpu/drm/bridge/panel.c | 68 +++- drivers/gpu/drm/drm_atomic.c | 60 +++ drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c | 40 - drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c| 26 +++- .../gpu/drm/msm/disp/dpu1/dpu_encoder_phys_vid.c | 22 +++ drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c | 3 +- drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.h | 12 +- drivers/gpu/drm/msm/disp/dpu1/dpu_hw_intf.c| 8 +- drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c| 2 +- drivers/gpu/drm/msm/dp/dp_catalog.c| 80 ++ drivers/gpu/drm/msm/dp/dp_catalog.h| 4 + drivers/gpu/drm/msm/dp/dp_ctrl.c | 80 ++ drivers/gpu/drm/msm/dp/dp_ctrl.h | 3 + drivers/gpu/drm/msm/dp/dp_display.c| 36 +++-- drivers/gpu/drm/msm/dp/dp_display.h| 2 + drivers/gpu/drm/msm/dp/dp_drm.c| 173 - drivers/gpu/drm/msm/dp/dp_drm.h| 9 +- drivers/gpu/drm/msm/dp/dp_link.c | 36 + drivers/gpu/drm/msm/dp/dp_panel.c | 22 +++ drivers/gpu/drm/msm/dp/dp_panel.h | 6 + drivers/gpu/drm/msm/dp/dp_reg.h| 27 include/drm/drm_atomic.h | 7 + 22 files changed, 683 insertions(+), 43 deletions(-) -- 2.7.4
Re: [PATCH v2] dt-bindings: display: mediatek: Compatible list cleanup
Il 02/03/23 15:12, Yassine Oudjana ha scritto: From: Yassine Oudjana Several DT bindings of MediaTek display blocks make unnecessary use of "oneOf" and "items". Remove them and replace them with enums where necessary. Signed-off-by: Yassine Oudjana --- Changes since v1: - Leave enums with 1 element as they are. .../bindings/display/mediatek/mediatek,ccorr.yaml | 7 +++ .../bindings/display/mediatek/mediatek,color.yaml | 10 -- .../bindings/display/mediatek/mediatek,dither.yaml | 3 +-- .../bindings/display/mediatek/mediatek,dsc.yaml | 4 +--- .../bindings/display/mediatek/mediatek,gamma.yaml | 7 +++ .../bindings/display/mediatek/mediatek,merge.yaml | 8 +++- .../bindings/display/mediatek/mediatek,od.yaml | 8 +++- .../bindings/display/mediatek/mediatek,ovl-2l.yaml | 7 +++ .../bindings/display/mediatek/mediatek,ovl.yaml | 13 + .../display/mediatek/mediatek,postmask.yaml | 3 +-- .../bindings/display/mediatek/mediatek,rdma.yaml| 13 + .../bindings/display/mediatek/mediatek,split.yaml | 4 +--- .../bindings/display/mediatek/mediatek,ufoe.yaml| 4 +--- .../bindings/display/mediatek/mediatek,wdma.yaml| 4 +--- 14 files changed, 35 insertions(+), 60 deletions(-) diff --git a/Documentation/devicetree/bindings/display/mediatek/mediatek,ccorr.yaml b/Documentation/devicetree/bindings/display/mediatek/mediatek,ccorr.yaml index b04820c95b22..dc22bd522523 100644 --- a/Documentation/devicetree/bindings/display/mediatek/mediatek,ccorr.yaml +++ b/Documentation/devicetree/bindings/display/mediatek/mediatek,ccorr.yaml @@ -21,10 +21,9 @@ description: | properties: compatible: oneOf: - - items: - - const: mediatek,mt8183-disp-ccorr - - items: - - const: mediatek,mt8192-disp-ccorr + - enum: + - mediatek,mt8183-disp-ccorr + - mediatek,mt8192-disp-ccorr This change is ok. - items: - enum: - mediatek,mt8188-disp-ccorr diff --git a/Documentation/devicetree/bindings/display/mediatek/mediatek,color.yaml b/Documentation/devicetree/bindings/display/mediatek/mediatek,color.yaml index 62306c88f485..d0ea77fc4b06 100644 --- a/Documentation/devicetree/bindings/display/mediatek/mediatek,color.yaml +++ b/Documentation/devicetree/bindings/display/mediatek/mediatek,color.yaml @@ -22,12 +22,10 @@ description: | properties: compatible: oneOf: - - items: - - const: mediatek,mt2701-disp-color - - items: - - const: mediatek,mt8167-disp-color - - items: - - const: mediatek,mt8173-disp-color + - enum: + - mediatek,mt2701-disp-color + - mediatek,mt8167-disp-color + - mediatek,mt8173-disp-color OK. - items: - enum: - mediatek,mt7623-disp-color diff --git a/Documentation/devicetree/bindings/display/mediatek/mediatek,dither.yaml b/Documentation/devicetree/bindings/display/mediatek/mediatek,dither.yaml index 5c7445c174e5..9d74de63fe63 100644 --- a/Documentation/devicetree/bindings/display/mediatek/mediatek,dither.yaml +++ b/Documentation/devicetree/bindings/display/mediatek/mediatek,dither.yaml @@ -22,8 +22,7 @@ description: | properties: compatible: oneOf: - - items: - - const: mediatek,mt8183-disp-dither + - const: mediatek,mt8183-disp-dither OK. - items: - enum: - mediatek,mt8186-disp-dither diff --git a/Documentation/devicetree/bindings/display/mediatek/mediatek,dsc.yaml b/Documentation/devicetree/bindings/display/mediatek/mediatek,dsc.yaml index 49248864514b..37bf6bf4a1ab 100644 --- a/Documentation/devicetree/bindings/display/mediatek/mediatek,dsc.yaml +++ b/Documentation/devicetree/bindings/display/mediatek/mediatek,dsc.yaml @@ -19,9 +19,7 @@ description: | properties: compatible: -oneOf: - - items: - - const: mediatek,mt8195-disp-dsc +const: mediatek,mt8195-disp-dsc This will grow, and you'll get devicetree declaring something like: compatible = "mediatek,(different-new-chip)-disp-dsc"; and compatible = "mediatek,(current-chip)-disp-dsc", "mediatek,mt8195-disp-dsc"; Note: Some smartphone SoCs (Dimensity series) do have the same disp-dsc as the Chromebook variant MT8195! :-) reg: maxItems: 1 diff --git a/Documentation/devicetree/bindings/display/mediatek/mediatek,gamma.yaml b/Documentation/devicetree/bindings/display/mediatek/mediatek,gamma.yaml index a5c6a91fac71..6c2be9d6840b 100644 --- a/Documentation/devicetree/bindings/display/mediatek/mediatek,gamma.yaml +++ b/Documentation/devicetree/bindings/display/mediatek/mediatek,gamma.yaml @@ -21,10 +21,9 @@ description: | properties: compatible: oneOf: - - items: - - const: mediatek,mt8173-disp-gamma - - items: - - const: mediatek,mt8183-disp-gamma + - enum: +
Re: [PATCH v2 1/2] drm/prime: reject DMA-BUF attach when get_sg_table is missing
Am 02.03.23 um 15:35 schrieb Simon Ser:
drm_gem_map_dma_buf() requires drm_gem_object_funcs.get_sg_table
to be implemented, or else WARNs.
Allow drivers to leave this hook unimplemented to implement purely
local DMA-BUFs (ie, DMA-BUFs which cannot be imported anywhere
else but the device which allocated them). In that case, reject
imports to other devices in drm_gem_map_attach().
v2: new patch
Signed-off-by: Simon Ser
Cc: Daniel Vetter
Cc: Thomas Zimmermann
Cc: Tian Tao
Cc: Maxime Ripard
Cc: Christian König
Cc: Hans de Goede
With Thomas comment addressed: Reviewed-by: Christian König
for the series.
---
drivers/gpu/drm/drm_prime.c | 6 +-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/drm_prime.c b/drivers/gpu/drm/drm_prime.c
index f924b8b4ab6b..ab1d21d63a03 100644
--- a/drivers/gpu/drm/drm_prime.c
+++ b/drivers/gpu/drm/drm_prime.c
@@ -544,7 +544,8 @@ int drm_prime_handle_to_fd_ioctl(struct drm_device *dev,
void *data,
* Optional pinning of buffers is handled at dma-buf attach and detach time in
* drm_gem_map_attach() and drm_gem_map_detach(). Backing storage itself is
* handled by drm_gem_map_dma_buf() and drm_gem_unmap_dma_buf(), which relies
on
- * _gem_object_funcs.get_sg_table.
+ * _gem_object_funcs.get_sg_table. If _gem_object_funcs.get_sg_table is
+ * unimplemented, exports into another device are rejected.
*
* For kernel-internal access there's drm_gem_dmabuf_vmap() and
* drm_gem_dmabuf_vunmap(). Userspace mmap support is provided by
@@ -583,6 +584,9 @@ int drm_gem_map_attach(struct dma_buf *dma_buf,
{
struct drm_gem_object *obj = dma_buf->priv;
+ if (!obj->funcs->get_sg_table)
+ return -EOPNOTSUPP;
+
return drm_gem_pin(obj);
}
EXPORT_SYMBOL(drm_gem_map_attach);
Re: [PATCH v3] drm/i915/active: Fix misuse of non-idle barriers as fence trackers
Hi Janusz,
On Thu, Mar 02, 2023 at 01:08:20PM +0100, Janusz Krzysztofik wrote:
> Users reported oopses on list corruptions when using i915 perf with a
> number of concurrently running graphics applications. Root cause analysis
> pointed at an issue in barrier processing code -- a race among perf open /
> close replacing active barriers with perf requests on kernel context and
> concurrent barrier preallocate / acquire operations performed during user
> context first pin / last unpin.
>
> When adding a request to a composite tracker, we try to reuse an existing
> fence tracker, already allocated and registered with that composite. The
> tracker we obtain may already track another fence, may be an idle barrier,
> or an active barrier.
>
> If the tracker we get occurs a non-idle barrier then we try to delete that
> barrier from a list of barrier tasks it belongs to. However, while doing
> that we don't respect return value from a function that performs the
> barrier deletion. Should the deletion ever fail, we would end up reusing
> the tracker still registered as a barrier task. Since the same structure
> field is reused with both fence callback lists and barrier tasks list,
> list corruptions would likely occur.
>
> Barriers are now deleted from a barrier tasks list by temporarily removing
> the list content, traversing that content with skip over the node to be
> deleted, then populating the list back with the modified content. Should
> that intentionally racy concurrent deletion attempts be not serialized,
> one or more of those may fail because of the list being temporary empty.
>
> Related code that ignores the results of barrier deletion was initially
> introduced in v5.4 by commit d8af05ff38ae ("drm/i915: Allow sharing the
> idle-barrier from other kernel requests"). However, all users of the
> barrier deletion routine were apparently serialized at that time, then the
> issue didn't exhibit itself. Results of git bisect with help of a newly
> developed igt@gem_barrier_race@remote-request IGT test indicate that list
> corruptions might start to appear after commit 311770173fac ("drm/i915/gt:
> Schedule request retirement when timeline idles"), introduced in v5.5.
>
> Respect results of barrier deletion attempts -- mark the barrier as idle
> only if successfully deleted from the list. Then, before proceeding with
> setting our fence as the one currently tracked, make sure that the tracker
> we've got is not a non-idle barrier. If that check fails then don't use
> that tracker but go back and try to acquire a new, usable one.
>
> v3: use unlikely() to document what outcome we expect (Andi),
> - fix bad grammar in commit description.
> v2: no code changes,
> - blame commit 311770173fac ("drm/i915/gt: Schedule request retirement
> when timeline idles"), v5.5, not commit d8af05ff38ae ("drm/i915: Allow
> sharing the idle-barrier from other kernel requests"), v5.4,
> - reword commit description.
>
> Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/6333
> Fixes: 311770173fac ("drm/i915/gt: Schedule request retirement when timeline
> idles")
> Cc: Chris Wilson
> Cc: sta...@vger.kernel.org # v5.5
> Cc: Andi Shyti
> Signed-off-by: Janusz Krzysztofik
Reviewed-by: Andi Shyti
I hope to see some future cleanups here, as well. Let's tie a
knot in our handkerchiefs to remind ourselves to revisit this in
the future.
Thanks,
Andi
Re: [PATCH v2 2/2] drm/vram-helper: turn on PRIME import/export
Am 02.03.23 um 15:35 schrieb Simon Ser: We don't populate drm_driver.gem_prime_import_sg_table so only DMA-BUFs exported from our own device can be imported. We don't populate drm_gem_object_funcs.get_sg_table so DMA-BUFs cannot be imported into another device. Still, this is useful to user-space to share buffers between processes and between API boundaries (e.g. wlroots hard-requires PRIME import/export support). v2: expand commit message Signed-off-by: Simon Ser Cc: Daniel Vetter Cc: Thomas Zimmermann Cc: Tian Tao Cc: Maxime Ripard Cc: Christian König Cc: Hans de Goede --- include/drm/drm_gem_vram_helper.h | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/include/drm/drm_gem_vram_helper.h b/include/drm/drm_gem_vram_helper.h index d3e8920c0b64..f4aab64411d8 100644 --- a/include/drm/drm_gem_vram_helper.h +++ b/include/drm/drm_gem_vram_helper.h @@ -160,7 +160,9 @@ void drm_gem_vram_simple_display_pipe_cleanup_fb( .debugfs_init = drm_vram_mm_debugfs_init, \ .dumb_create = drm_gem_vram_driver_dumb_create, \ .dumb_map_offset = drm_gem_ttm_dumb_map_offset, \ - .gem_prime_mmap = drm_gem_prime_mmap + .gem_prime_mmap = drm_gem_prime_mmap, \ + .prime_handle_to_fd = drm_gem_prime_handle_to_fd, \ + .prime_fd_to_handle = drm_gem_prime_fd_to_handle Acked-by: Thomas Zimmermann /* * VRAM memory manager -- Thomas Zimmermann Graphics Driver Developer SUSE Software Solutions Germany GmbH Maxfeldstr. 5, 90409 Nürnberg, Germany (HRB 36809, AG Nürnberg) Geschäftsführer: Ivo Totev OpenPGP_signature Description: OpenPGP digital signature
Re: [PATCH v2 1/2] drm/prime: reject DMA-BUF attach when get_sg_table is missing
Hi
Am 02.03.23 um 16:03 schrieb Thomas Zimmermann:
Hi
Am 02.03.23 um 15:35 schrieb Simon Ser:
drm_gem_map_dma_buf() requires drm_gem_object_funcs.get_sg_table
to be implemented, or else WARNs.
Allow drivers to leave this hook unimplemented to implement purely
local DMA-BUFs (ie, DMA-BUFs which cannot be imported anywhere
else but the device which allocated them). In that case, reject
imports to other devices in drm_gem_map_attach().
v2: new patch
Signed-off-by: Simon Ser
Cc: Daniel Vetter
Cc: Thomas Zimmermann
Cc: Tian Tao
Cc: Maxime Ripard
Cc: Christian König
Cc: Hans de Goede
---
drivers/gpu/drm/drm_prime.c | 6 +-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/drm_prime.c b/drivers/gpu/drm/drm_prime.c
index f924b8b4ab6b..ab1d21d63a03 100644
--- a/drivers/gpu/drm/drm_prime.c
+++ b/drivers/gpu/drm/drm_prime.c
@@ -544,7 +544,8 @@ int drm_prime_handle_to_fd_ioctl(struct drm_device
*dev, void *data,
* Optional pinning of buffers is handled at dma-buf attach and
detach time in
* drm_gem_map_attach() and drm_gem_map_detach(). Backing storage
itself is
* handled by drm_gem_map_dma_buf() and drm_gem_unmap_dma_buf(),
which relies on
- * _gem_object_funcs.get_sg_table.
+ * _gem_object_funcs.get_sg_table. If
_gem_object_funcs.get_sg_table is
+ * unimplemented, exports into another device are rejected.
*
* For kernel-internal access there's drm_gem_dmabuf_vmap() and
* drm_gem_dmabuf_vunmap(). Userspace mmap support is provided by
@@ -583,6 +584,9 @@ int drm_gem_map_attach(struct dma_buf *dma_buf,
{
struct drm_gem_object *obj = dma_buf->priv;
+ if (!obj->funcs->get_sg_table)
+ return -EOPNOTSUPP;
-ENOSYS please.
With this changed:
Acked-by: Thomas Zimmermann
Best regards
Thomas
+
return drm_gem_pin(obj);
}
EXPORT_SYMBOL(drm_gem_map_attach);
--
Thomas Zimmermann
Graphics Driver Developer
SUSE Software Solutions Germany GmbH
Maxfeldstr. 5, 90409 Nürnberg, Germany
(HRB 36809, AG Nürnberg)
Geschäftsführer: Ivo Totev
OpenPGP_signature
Description: OpenPGP digital signature
Re: [PATCH v2 1/2] drm/prime: reject DMA-BUF attach when get_sg_table is missing
Hi
Am 02.03.23 um 15:35 schrieb Simon Ser:
drm_gem_map_dma_buf() requires drm_gem_object_funcs.get_sg_table
to be implemented, or else WARNs.
Allow drivers to leave this hook unimplemented to implement purely
local DMA-BUFs (ie, DMA-BUFs which cannot be imported anywhere
else but the device which allocated them). In that case, reject
imports to other devices in drm_gem_map_attach().
v2: new patch
Signed-off-by: Simon Ser
Cc: Daniel Vetter
Cc: Thomas Zimmermann
Cc: Tian Tao
Cc: Maxime Ripard
Cc: Christian König
Cc: Hans de Goede
---
drivers/gpu/drm/drm_prime.c | 6 +-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/drm_prime.c b/drivers/gpu/drm/drm_prime.c
index f924b8b4ab6b..ab1d21d63a03 100644
--- a/drivers/gpu/drm/drm_prime.c
+++ b/drivers/gpu/drm/drm_prime.c
@@ -544,7 +544,8 @@ int drm_prime_handle_to_fd_ioctl(struct drm_device *dev,
void *data,
* Optional pinning of buffers is handled at dma-buf attach and detach time in
* drm_gem_map_attach() and drm_gem_map_detach(). Backing storage itself is
* handled by drm_gem_map_dma_buf() and drm_gem_unmap_dma_buf(), which relies
on
- * _gem_object_funcs.get_sg_table.
+ * _gem_object_funcs.get_sg_table. If _gem_object_funcs.get_sg_table is
+ * unimplemented, exports into another device are rejected.
*
* For kernel-internal access there's drm_gem_dmabuf_vmap() and
* drm_gem_dmabuf_vunmap(). Userspace mmap support is provided by
@@ -583,6 +584,9 @@ int drm_gem_map_attach(struct dma_buf *dma_buf,
{
struct drm_gem_object *obj = dma_buf->priv;
+ if (!obj->funcs->get_sg_table)
+ return -EOPNOTSUPP;
-ENOSYS please.
Best regards
Thomas
+
return drm_gem_pin(obj);
}
EXPORT_SYMBOL(drm_gem_map_attach);
--
Thomas Zimmermann
Graphics Driver Developer
SUSE Software Solutions Germany GmbH
Maxfeldstr. 5, 90409 Nürnberg, Germany
(HRB 36809, AG Nürnberg)
Geschäftsführer: Ivo Totev
OpenPGP_signature
Description: OpenPGP digital signature
Re: [PATCH] drm/vram-helper: turn on PRIME import/export
On Thursday, March 2nd, 2023 at 14:45, Christian König wrote: > Am 02.03.23 um 14:37 schrieb Simon Ser: > > > On Thursday, March 2nd, 2023 at 14:21, Christian König > > christian.koe...@amd.com wrote: > > > > > Am 02.03.23 um 11:14 schrieb Simon Ser: > > > > > > > On Thursday, March 2nd, 2023 at 08:11, Christian König > > > > christian.koe...@amd.com wrote: > > > > > > > > > Am 01.03.23 um 23:29 schrieb Simon Ser: > > > > > > > > > > > We don't populate gem_prime_import_sg_table so only DMA-BUFs > > > > > > exported from our own device can be imported. Still, this is useful > > > > > > to user-space. > > > > > > But what happens if one of your BOs is imported into another device? > > > > > > Is there a way to make this fail, always? > > > > > > Well you could return an error from the attach callback if I'm not > > > > > > completely mistaken. > > > > > > Hmm, but with GEM helpers this is handled by drm_gem_map_attach(). > > > > > > That > > > > > > function calls drm_gem_object_funcs.pin but doesn't pass along the > > > > > > dma_buf_attachment so there no way to reject the attach based on the > > > > > > other device there… > > > > Would it be unreasonable to add a drm_driver.gem_prime_attach hook? Or > > is there a better way to implement this? > > That would be the mid layering we usually try hard to avoid. Indeed! > Your obj doesn't implement the obj->funcs->get_sg_table() callback > doesn't it? In this case drm_gem_map_dma_buf() would fail just a little > bit later anyway. > > What you could do is to add a check for the get_sg_table callback a bit > earlier in drm_gem_map_attach() and if that's not implemented reject the > attachment. That's a good idea, thanks for the suggestion! Done in v2.
[PATCH v2 1/2] drm/prime: reject DMA-BUF attach when get_sg_table is missing
drm_gem_map_dma_buf() requires drm_gem_object_funcs.get_sg_table
to be implemented, or else WARNs.
Allow drivers to leave this hook unimplemented to implement purely
local DMA-BUFs (ie, DMA-BUFs which cannot be imported anywhere
else but the device which allocated them). In that case, reject
imports to other devices in drm_gem_map_attach().
v2: new patch
Signed-off-by: Simon Ser
Cc: Daniel Vetter
Cc: Thomas Zimmermann
Cc: Tian Tao
Cc: Maxime Ripard
Cc: Christian König
Cc: Hans de Goede
---
drivers/gpu/drm/drm_prime.c | 6 +-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/drm_prime.c b/drivers/gpu/drm/drm_prime.c
index f924b8b4ab6b..ab1d21d63a03 100644
--- a/drivers/gpu/drm/drm_prime.c
+++ b/drivers/gpu/drm/drm_prime.c
@@ -544,7 +544,8 @@ int drm_prime_handle_to_fd_ioctl(struct drm_device *dev,
void *data,
* Optional pinning of buffers is handled at dma-buf attach and detach time in
* drm_gem_map_attach() and drm_gem_map_detach(). Backing storage itself is
* handled by drm_gem_map_dma_buf() and drm_gem_unmap_dma_buf(), which relies
on
- * _gem_object_funcs.get_sg_table.
+ * _gem_object_funcs.get_sg_table. If _gem_object_funcs.get_sg_table is
+ * unimplemented, exports into another device are rejected.
*
* For kernel-internal access there's drm_gem_dmabuf_vmap() and
* drm_gem_dmabuf_vunmap(). Userspace mmap support is provided by
@@ -583,6 +584,9 @@ int drm_gem_map_attach(struct dma_buf *dma_buf,
{
struct drm_gem_object *obj = dma_buf->priv;
+ if (!obj->funcs->get_sg_table)
+ return -EOPNOTSUPP;
+
return drm_gem_pin(obj);
}
EXPORT_SYMBOL(drm_gem_map_attach);
--
2.39.2
[PATCH v2 2/2] drm/vram-helper: turn on PRIME import/export
We don't populate drm_driver.gem_prime_import_sg_table so only DMA-BUFs exported from our own device can be imported. We don't populate drm_gem_object_funcs.get_sg_table so DMA-BUFs cannot be imported into another device. Still, this is useful to user-space to share buffers between processes and between API boundaries (e.g. wlroots hard-requires PRIME import/export support). v2: expand commit message Signed-off-by: Simon Ser Cc: Daniel Vetter Cc: Thomas Zimmermann Cc: Tian Tao Cc: Maxime Ripard Cc: Christian König Cc: Hans de Goede --- include/drm/drm_gem_vram_helper.h | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/include/drm/drm_gem_vram_helper.h b/include/drm/drm_gem_vram_helper.h index d3e8920c0b64..f4aab64411d8 100644 --- a/include/drm/drm_gem_vram_helper.h +++ b/include/drm/drm_gem_vram_helper.h @@ -160,7 +160,9 @@ void drm_gem_vram_simple_display_pipe_cleanup_fb( .debugfs_init = drm_vram_mm_debugfs_init, \ .dumb_create = drm_gem_vram_driver_dumb_create, \ .dumb_map_offset = drm_gem_ttm_dumb_map_offset, \ - .gem_prime_mmap = drm_gem_prime_mmap + .gem_prime_mmap = drm_gem_prime_mmap, \ + .prime_handle_to_fd = drm_gem_prime_handle_to_fd, \ + .prime_fd_to_handle = drm_gem_prime_fd_to_handle /* * VRAM memory manager -- 2.39.2
Re: [PATCH] dt-bindings: display: mediatek: Compatible list cleanup
On 02/03/2023 14:35, Yassine Oudjana wrote: > From: Yassine Oudjana > > Several DT bindings of MediaTek display blocks make unnecessary use of > "oneOf" and "items", and have some enums with only 1 element. Remove > unnecessary "oneOf" and "items", and replace enums that have 1 element > with "const". > > Signed-off-by: Yassine Oudjana > --- > .../bindings/display/mediatek/mediatek,aal.yaml | 3 +-- > .../display/mediatek/mediatek,ccorr.yaml | 10 -- > .../display/mediatek/mediatek,color.yaml | 10 -- > .../display/mediatek/mediatek,dither.yaml| 3 +-- > .../bindings/display/mediatek/mediatek,dsc.yaml | 4 +--- > .../display/mediatek/mediatek,gamma.yaml | 7 +++ > .../display/mediatek/mediatek,merge.yaml | 8 +++- > .../bindings/display/mediatek/mediatek,od.yaml | 8 +++- > .../display/mediatek/mediatek,ovl-2l.yaml| 10 -- > .../bindings/display/mediatek/mediatek,ovl.yaml | 16 ++-- > .../display/mediatek/mediatek,postmask.yaml | 3 +-- > .../bindings/display/mediatek/mediatek,rdma.yaml | 13 + > .../display/mediatek/mediatek,split.yaml | 4 +--- > .../bindings/display/mediatek/mediatek,ufoe.yaml | 4 +--- > .../bindings/display/mediatek/mediatek,wdma.yaml | 4 +--- > 15 files changed, 39 insertions(+), 68 deletions(-) > > diff --git > a/Documentation/devicetree/bindings/display/mediatek/mediatek,aal.yaml > b/Documentation/devicetree/bindings/display/mediatek/mediatek,aal.yaml > index 92741486c24d..d8d78abd6c6c 100644 > --- a/Documentation/devicetree/bindings/display/mediatek/mediatek,aal.yaml > +++ b/Documentation/devicetree/bindings/display/mediatek/mediatek,aal.yaml > @@ -25,8 +25,7 @@ properties: >- mediatek,mt8173-disp-aal >- mediatek,mt8183-disp-aal >- items: > - - enum: > - - mediatek,mt2712-disp-aal > + - const: mediatek,mt2712-disp-aal This was I think intentional - it will grow. The same in all other one-enum cases, it might be unnecessary change which soon will be reverted converting back to enum. >- const: mediatek,mt8173-disp-aal >- items: >- enum: > diff --git > a/Documentation/devicetree/bindings/display/mediatek/mediatek,ccorr.yaml > b/Documentation/devicetree/bindings/display/mediatek/mediatek,ccorr.yaml > index b04820c95b22..e72d2884bb49 100644 > --- a/Documentation/devicetree/bindings/display/mediatek/mediatek,ccorr.yaml > +++ b/Documentation/devicetree/bindings/display/mediatek/mediatek,ccorr.yaml > @@ -21,18 +21,16 @@ description: | > properties: >compatible: > oneOf: > - - items: > - - const: mediatek,mt8183-disp-ccorr > - - items: > - - const: mediatek,mt8192-disp-ccorr > + - enum: > + - mediatek,mt8183-disp-ccorr > + - mediatek,mt8192-disp-ccorr Such changes are fine. Best regards, Krzysztof
Re: [PATCH] drm/vram-helper: turn on PRIME import/export
Am 02.03.23 um 14:37 schrieb Simon Ser: On Thursday, March 2nd, 2023 at 14:21, Christian König wrote: Am 02.03.23 um 11:14 schrieb Simon Ser: On Thursday, March 2nd, 2023 at 08:11, Christian König christian.koe...@amd.com wrote: Am 01.03.23 um 23:29 schrieb Simon Ser: We don't populate gem_prime_import_sg_table so only DMA-BUFs exported from our own device can be imported. Still, this is useful to user-space. But what happens if one of your BOs is imported into another device? Is there a way to make this fail, always? Well you could return an error from the attach callback if I'm not completely mistaken. Hmm, but with GEM helpers this is handled by drm_gem_map_attach(). That function calls drm_gem_object_funcs.pin but doesn't pass along the dma_buf_attachment so there no way to reject the attach based on the other device there… Would it be unreasonable to add a drm_driver.gem_prime_attach hook? Or is there a better way to implement this? That would be the mid layering we usually try hard to avoid. Your obj doesn't implement the obj->funcs->get_sg_table() callback doesn't it? In this case drm_gem_map_dma_buf() would fail just a little bit later anyway. What you could do is to add a check for the get_sg_table callback a bit earlier in drm_gem_map_attach() and if that's not implemented reject the attachment. Regards, Christian.
Re: [PATCH] drm/vram-helper: turn on PRIME import/export
On Thursday, March 2nd, 2023 at 14:21, Christian König wrote: > Am 02.03.23 um 11:14 schrieb Simon Ser: > > > On Thursday, March 2nd, 2023 at 08:11, Christian König > > christian.koe...@amd.com wrote: > > > > > Am 01.03.23 um 23:29 schrieb Simon Ser: > > > > > > > We don't populate gem_prime_import_sg_table so only DMA-BUFs > > > > exported from our own device can be imported. Still, this is useful > > > > to user-space. > > > > But what happens if one of your BOs is imported into another device? > > > > Is there a way to make this fail, always? > > Well you could return an error from the attach callback if I'm not > completely mistaken. Hmm, but with GEM helpers this is handled by drm_gem_map_attach(). That function calls drm_gem_object_funcs.pin but doesn't pass along the dma_buf_attachment so there no way to reject the attach based on the other device there… Would it be unreasonable to add a drm_driver.gem_prime_attach hook? Or is there a better way to implement this?
Re: [PATCH] drm/i915/gvt: Make use of idr_find and idr_for_each_entry in dmabuf
On 02 3月 23 19:53:18, Cai Huoqing wrote:
> This patch uses the already existing IDR mechanism to simplify
> and improve the dmabuf code.
>
> Using 'vgpu.object_idr' directly instead of 'dmabuf_obj_list_head'
> or 'dmabuf.list', because the dmabuf_obj can be found by 'idr_find'
> or 'idr_for_each_entry'.
>
> Signed-off-by: Cai Huoqing
> ---
> drivers/gpu/drm/i915/gvt/dmabuf.c | 69 +++
> drivers/gpu/drm/i915/gvt/dmabuf.h | 1 -
> drivers/gpu/drm/i915/gvt/gvt.h| 1 -
> drivers/gpu/drm/i915/gvt/vgpu.c | 1 -
> 4 files changed, 16 insertions(+), 56 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/gvt/dmabuf.c
> b/drivers/gpu/drm/i915/gvt/dmabuf.c
> index 6834f9fe40cf..7933bd843ae8 100644
> --- a/drivers/gpu/drm/i915/gvt/dmabuf.c
> +++ b/drivers/gpu/drm/i915/gvt/dmabuf.c
> @@ -133,21 +133,15 @@ static void dmabuf_gem_object_free(struct kref *kref)
> struct intel_vgpu_dmabuf_obj *obj =
> container_of(kref, struct intel_vgpu_dmabuf_obj, kref);
> struct intel_vgpu *vgpu = obj->vgpu;
> - struct list_head *pos;
> struct intel_vgpu_dmabuf_obj *dmabuf_obj;
> + int id;
>
> - if (vgpu && test_bit(INTEL_VGPU_STATUS_ACTIVE, vgpu->status) &&
> - !list_empty(>dmabuf_obj_list_head)) {
> - list_for_each(pos, >dmabuf_obj_list_head) {
> - dmabuf_obj = list_entry(pos, struct
> intel_vgpu_dmabuf_obj, list);
> - if (dmabuf_obj == obj) {
> - list_del(pos);
> - idr_remove(>object_idr,
> -dmabuf_obj->dmabuf_id);
> - kfree(dmabuf_obj->info);
> - kfree(dmabuf_obj);
> - break;
> - }
> + if (vgpu && test_bit(INTEL_VGPU_STATUS_ACTIVE, vgpu->status)) {
Here should add '&& !idr_is_empty()' like '&& !list_empty()',
I will fix it in patch v2
Thanks
Cai-
> + idr_for_each_entry(>object_idr, dmabuf_obj, id) {
> + idr_remove(>object_idr, id);
> + kfree(dmabuf_obj->info);
> + kfree(dmabuf_obj);
> + break;
> }
> } else {
> /* Free the orphan dmabuf_objs here */
> @@ -340,13 +334,11 @@ static struct intel_vgpu_dmabuf_obj *
> pick_dmabuf_by_info(struct intel_vgpu *vgpu,
> struct intel_vgpu_fb_info *latest_info)
> {
> - struct list_head *pos;
> struct intel_vgpu_fb_info *fb_info;
> struct intel_vgpu_dmabuf_obj *dmabuf_obj = NULL;
> - struct intel_vgpu_dmabuf_obj *ret = NULL;
> + int id;
>
> - list_for_each(pos, >dmabuf_obj_list_head) {
> - dmabuf_obj = list_entry(pos, struct intel_vgpu_dmabuf_obj,
> list);
> + idr_for_each_entry(>object_idr, dmabuf_obj, id) {
> if (!dmabuf_obj->info)
> continue;
>
> @@ -357,31 +349,11 @@ pick_dmabuf_by_info(struct intel_vgpu *vgpu,
> (fb_info->drm_format_mod == latest_info->drm_format_mod) &&
> (fb_info->drm_format == latest_info->drm_format) &&
> (fb_info->width == latest_info->width) &&
> - (fb_info->height == latest_info->height)) {
> - ret = dmabuf_obj;
> - break;
> - }
> - }
> -
> - return ret;
> -}
> -
> -static struct intel_vgpu_dmabuf_obj *
> -pick_dmabuf_by_num(struct intel_vgpu *vgpu, u32 id)
> -{
> - struct list_head *pos;
> - struct intel_vgpu_dmabuf_obj *dmabuf_obj = NULL;
> - struct intel_vgpu_dmabuf_obj *ret = NULL;
> -
> - list_for_each(pos, >dmabuf_obj_list_head) {
> - dmabuf_obj = list_entry(pos, struct intel_vgpu_dmabuf_obj,
> list);
> - if (dmabuf_obj->dmabuf_id == id) {
> - ret = dmabuf_obj;
> - break;
> - }
> + (fb_info->height == latest_info->height))
> + return dmabuf_obj;
> }
>
> - return ret;
> + return dmabuf_obj;
> }
>
> static void update_fb_info(struct vfio_device_gfx_plane_info *gvt_dmabuf,
> @@ -477,11 +449,6 @@ int intel_vgpu_query_plane(struct intel_vgpu *vgpu, void
> *args)
>
> update_fb_info(gfx_plane_info, _info);
>
> - INIT_LIST_HEAD(_obj->list);
> - mutex_lock(>dmabuf_lock);
> - list_add_tail(_obj->list, >dmabuf_obj_list_head);
> - mutex_unlock(>dmabuf_lock);
> -
> gvt_dbg_dpy("vgpu%d: %s new dmabuf_obj ref %d, id %d\n", vgpu->id,
> __func__, kref_read(_obj->kref), ret);
>
> @@ -508,7 +475,7 @@ int intel_vgpu_get_dmabuf(struct intel_vgpu *vgpu,
> unsigned int dmabuf_id)
>
> mutex_lock(>dmabuf_lock);
>
> - dmabuf_obj = pick_dmabuf_by_num(vgpu, dmabuf_id);
> + dmabuf_obj = idr_find(>object_idr, dmabuf_id);
> if (dmabuf_obj == NULL) {
>
Re: [PATCH] drm/vram-helper: turn on PRIME import/export
Am 02.03.23 um 11:14 schrieb Simon Ser: On Thursday, March 2nd, 2023 at 08:11, Christian König wrote: Am 01.03.23 um 23:29 schrieb Simon Ser: We don't populate gem_prime_import_sg_table so only DMA-BUFs exported from our own device can be imported. Still, this is useful to user-space. But what happens if one of your BOs is imported into another device? Is there a way to make this fail, always? Well you could return an error from the attach callback if I'm not completely mistaken. But that's certainly not a standard function of the DRM helpers. Regards, Christian.
Re: [PATCH RESEND] drm/tests: Suballocator test
Am 02.03.23 um 09:34 schrieb Thomas Hellström:
Add a suballocator test to get some test coverage for the new drm
suballocator, and perform some basic timing (elapsed time).
Signed-off-by: Thomas Hellström
Nice, I haven't had time to go over it in all detail but it looks pretty
sophisticated.
Feel free to add an Acked-by: Christian König .
Regards,
Christian.
---
drivers/gpu/drm/Kconfig | 1 +
drivers/gpu/drm/tests/Makefile| 3 +-
drivers/gpu/drm/tests/drm_suballoc_test.c | 356 ++
3 files changed, 359 insertions(+), 1 deletion(-)
create mode 100644 drivers/gpu/drm/tests/drm_suballoc_test.c
diff --git a/drivers/gpu/drm/Kconfig b/drivers/gpu/drm/Kconfig
index 8fbe57407c60..dced53723721 100644
--- a/drivers/gpu/drm/Kconfig
+++ b/drivers/gpu/drm/Kconfig
@@ -78,6 +78,7 @@ config DRM_KUNIT_TEST
select DRM_LIB_RANDOM
select DRM_KMS_HELPER
select DRM_BUDDY
+ select DRM_SUBALLOC_HELPER
select DRM_EXPORT_FOR_TESTS if m
select DRM_KUNIT_TEST_HELPERS
default KUNIT_ALL_TESTS
diff --git a/drivers/gpu/drm/tests/Makefile b/drivers/gpu/drm/tests/Makefile
index bca726a8f483..c664944a48ab 100644
--- a/drivers/gpu/drm/tests/Makefile
+++ b/drivers/gpu/drm/tests/Makefile
@@ -17,6 +17,7 @@ obj-$(CONFIG_DRM_KUNIT_TEST) += \
drm_modes_test.o \
drm_plane_helper_test.o \
drm_probe_helper_test.o \
- drm_rect_test.o
+ drm_rect_test.o \
+ drm_suballoc_test.o
CFLAGS_drm_mm_test.o := $(DISABLE_STRUCTLEAK_PLUGIN)
diff --git a/drivers/gpu/drm/tests/drm_suballoc_test.c
b/drivers/gpu/drm/tests/drm_suballoc_test.c
new file mode 100644
index ..e7303a5505a0
--- /dev/null
+++ b/drivers/gpu/drm/tests/drm_suballoc_test.c
@@ -0,0 +1,356 @@
+// SPDX-License-Identifier: GPL-2.0 OR MIT
+/*
+ * Test case for the drm_suballoc suballocator manager
+ * Copyright 2023 Intel Corporation.
+ */
+
+#include
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#define SA_ITERATIONS 1
+#define SA_SIZE SZ_1M
+#define SA_DEFAULT_ALIGN SZ_4K
+
+static bool intr = true;
+static bool from_reclaim;
+static bool pre_throttle;
+static unsigned int num_rings = 4;
+static unsigned int iterations = SA_ITERATIONS;
+
+static atomic64_t free_space;
+
+static atomic_t other_id;
+
+struct suballoc_fence;
+
+/**
+ * struct suballoc_ring - fake gpu engine.
+ * @list: List of fences to signal.
+ * @signal_time: Accumulated fence signal execution time.
+ * @lock: Protects the suballoc ring members. hardirq safe.
+ * @hrtimer: Fake execution time timer.
+ * @active: The currently active fence for which we have pending work or a
+ * timer running.
+ * @seqno: Fence submissin seqno.
+ * @idx: Index for calculation of fake execution time.
+ * @work: Work struct used solely to move the timer start to a different
+ *processor than that used for submission.
+ */
+struct suballoc_ring {
+ ktime_t signal_time;
+ struct list_head list;
+ /* Protect the ring processing. */
+ spinlock_t lock;
+ struct hrtimer hrtimer;
+ struct suballoc_fence *active;
+ atomic64_t seqno;
+ u32 idx;
+ struct work_struct work;
+};
+
+/**
+ * struct suballoc_fence - Hrtimer-driven fence.
+ * @fence: The base class fence struct.
+ * @link: Link for the ring's fence list.
+ * @size: The size of the suballocator range associated with this fence.
+ * @id: Cpu id likely used by the submission thread for suballoc allocation.
+ */
+struct suballoc_fence {
+ struct dma_fence fence;
+ struct list_head link;
+ size_t size;
+ unsigned int id;
+};
+
+/* A varying but repeatable fake execution time */
+static ktime_t ring_next_delay(struct suballoc_ring *ring)
+{
+ return ns_to_ktime((u64)(++ring->idx % 8) * 200 * NSEC_PER_USEC);
+}
+
+/*
+ * Launch from a work item to decrease the likelyhood of the timer expiry
+ * callback getting called from the allocating cpu.
+ * We want to trigger cache-line bouncing between allocating and signalling
+ * cpus.
+ */
+static void ring_launch_timer_work(struct work_struct *work)
+{
+ struct suballoc_ring *ring =
+ container_of(work, typeof(*ring), work);
+
+ spin_lock_irq(>lock);
+ if (ring->active)
+ hrtimer_start_range_ns(>hrtimer, ring_next_delay(ring),
+ 100ULL * NSEC_PER_USEC,
+ HRTIMER_MODE_REL_PINNED);
+
+ spin_unlock_irq(>lock);
+}
+
+/*
+ * Signal an active fence and pull the next off the list if any and make it
+ * active.
+ */
+static enum hrtimer_restart ring_hrtimer_expired(struct hrtimer *hrtimer)
+{
+ struct suballoc_ring *ring =
+ container_of(hrtimer, typeof(*ring), hrtimer);
+ struct suballoc_fence *sfence;
+ ktime_t now, then;
+ unsigned long irqflags;
+
+
[PATCH] drm/nouveau/nvfw/acr: set wpr_generic_header_dump storage-class-specifier to static
gcc with W=1 reports
drivers/gpu/drm/nouveau/nvkm/nvfw/acr.c:49:1: error: no previous
prototype for ‘wpr_generic_header_dump’ [-Werror=missing-prototypes]
49 | wpr_generic_header_dump(struct nvkm_subdev *subdev,
| ^~~
wpr_generic_header_dump is only used in acr.c, so it should be static
Signed-off-by: Tom Rix
---
drivers/gpu/drm/nouveau/nvkm/nvfw/acr.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/nouveau/nvkm/nvfw/acr.c
b/drivers/gpu/drm/nouveau/nvkm/nvfw/acr.c
index 83a9c48bc58c..7ac90c495737 100644
--- a/drivers/gpu/drm/nouveau/nvkm/nvfw/acr.c
+++ b/drivers/gpu/drm/nouveau/nvkm/nvfw/acr.c
@@ -45,7 +45,7 @@ wpr_header_v1_dump(struct nvkm_subdev *subdev, const struct
wpr_header_v1 *hdr)
nvkm_debug(subdev, "\tstatus: %d\n", hdr->status);
}
-void
+static void
wpr_generic_header_dump(struct nvkm_subdev *subdev, const struct
wpr_generic_header *hdr)
{
nvkm_debug(subdev, "wprGenericHeader\n");
--
2.27.0
[PATCH] drm/rockchip: vop2: add polarity flags to RGB output
Use h/v-sync and pixel clock polarity flags for RGB output. For all other outputs this is already implemented. Signed-off-by: Gerald Loacker --- drivers/gpu/drm/rockchip/rockchip_drm_vop2.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_vop2.c b/drivers/gpu/drm/rockchip/rockchip_drm_vop2.c index 8cecf81a5ae0..e8b61973ade2 100644 --- a/drivers/gpu/drm/rockchip/rockchip_drm_vop2.c +++ b/drivers/gpu/drm/rockchip/rockchip_drm_vop2.c @@ -1435,6 +1435,8 @@ static void rk3568_set_intf_mux(struct vop2_video_port *vp, int id, die &= ~RK3568_SYS_DSP_INFACE_EN_RGB_MUX; die |= RK3568_SYS_DSP_INFACE_EN_RGB | FIELD_PREP(RK3568_SYS_DSP_INFACE_EN_RGB_MUX, vp->id); + dip &= ~RK3568_DSP_IF_POL__RGB_LVDS_PIN_POL; + dip |= FIELD_PREP(RK3568_DSP_IF_POL__RGB_LVDS_PIN_POL, polflags); if (polflags & POLFLAG_DCLK_INV) regmap_write(vop2->grf, RK3568_GRF_VO_CON1, BIT(3 + 16) | BIT(3)); else -- 2.37.2
[PATCH v3] drm/i915/active: Fix misuse of non-idle barriers as fence trackers
Users reported oopses on list corruptions when using i915 perf with a
number of concurrently running graphics applications. Root cause analysis
pointed at an issue in barrier processing code -- a race among perf open /
close replacing active barriers with perf requests on kernel context and
concurrent barrier preallocate / acquire operations performed during user
context first pin / last unpin.
When adding a request to a composite tracker, we try to reuse an existing
fence tracker, already allocated and registered with that composite. The
tracker we obtain may already track another fence, may be an idle barrier,
or an active barrier.
If the tracker we get occurs a non-idle barrier then we try to delete that
barrier from a list of barrier tasks it belongs to. However, while doing
that we don't respect return value from a function that performs the
barrier deletion. Should the deletion ever fail, we would end up reusing
the tracker still registered as a barrier task. Since the same structure
field is reused with both fence callback lists and barrier tasks list,
list corruptions would likely occur.
Barriers are now deleted from a barrier tasks list by temporarily removing
the list content, traversing that content with skip over the node to be
deleted, then populating the list back with the modified content. Should
that intentionally racy concurrent deletion attempts be not serialized,
one or more of those may fail because of the list being temporary empty.
Related code that ignores the results of barrier deletion was initially
introduced in v5.4 by commit d8af05ff38ae ("drm/i915: Allow sharing the
idle-barrier from other kernel requests"). However, all users of the
barrier deletion routine were apparently serialized at that time, then the
issue didn't exhibit itself. Results of git bisect with help of a newly
developed igt@gem_barrier_race@remote-request IGT test indicate that list
corruptions might start to appear after commit 311770173fac ("drm/i915/gt:
Schedule request retirement when timeline idles"), introduced in v5.5.
Respect results of barrier deletion attempts -- mark the barrier as idle
only if successfully deleted from the list. Then, before proceeding with
setting our fence as the one currently tracked, make sure that the tracker
we've got is not a non-idle barrier. If that check fails then don't use
that tracker but go back and try to acquire a new, usable one.
v3: use unlikely() to document what outcome we expect (Andi),
- fix bad grammar in commit description.
v2: no code changes,
- blame commit 311770173fac ("drm/i915/gt: Schedule request retirement
when timeline idles"), v5.5, not commit d8af05ff38ae ("drm/i915: Allow
sharing the idle-barrier from other kernel requests"), v5.4,
- reword commit description.
Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/6333
Fixes: 311770173fac ("drm/i915/gt: Schedule request retirement when timeline
idles")
Cc: Chris Wilson
Cc: sta...@vger.kernel.org # v5.5
Cc: Andi Shyti
Signed-off-by: Janusz Krzysztofik
---
drivers/gpu/drm/i915/i915_active.c | 25 ++---
1 file changed, 14 insertions(+), 11 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_active.c
b/drivers/gpu/drm/i915/i915_active.c
index 7412abf166a8c..a9fea115f2d26 100644
--- a/drivers/gpu/drm/i915/i915_active.c
+++ b/drivers/gpu/drm/i915/i915_active.c
@@ -422,12 +422,12 @@ replace_barrier(struct i915_active *ref, struct
i915_active_fence *active)
* we can use it to substitute for the pending idle-barrer
* request that we want to emit on the kernel_context.
*/
- __active_del_barrier(ref, node_from_active(active));
- return true;
+ return __active_del_barrier(ref, node_from_active(active));
}
int i915_active_add_request(struct i915_active *ref, struct i915_request *rq)
{
+ u64 idx = i915_request_timeline(rq)->fence_context;
struct dma_fence *fence = >fence;
struct i915_active_fence *active;
int err;
@@ -437,16 +437,19 @@ int i915_active_add_request(struct i915_active *ref,
struct i915_request *rq)
if (err)
return err;
- active = active_instance(ref, i915_request_timeline(rq)->fence_context);
- if (!active) {
- err = -ENOMEM;
- goto out;
- }
+ do {
+ active = active_instance(ref, idx);
+ if (!active) {
+ err = -ENOMEM;
+ goto out;
+ }
+
+ if (replace_barrier(ref, active)) {
+ RCU_INIT_POINTER(active->fence, NULL);
+ atomic_dec(>count);
+ }
+ } while (unlikely(is_barrier(active)));
- if (replace_barrier(ref, active)) {
- RCU_INIT_POINTER(active->fence, NULL);
- atomic_dec(>count);
- }
if (!__i915_active_fence_set(active, fence))
Re: gud: set PATH connector property
On Tuesday, February 28th, 2023 at 16:16, Peter Stuge wrote: > Simon Ser wrote: > > > > > Would it be possible to set the PATH connector property based on the > > > > USB port used by gud? > > > > > > Sadly not really easily. > > > > > > The physical topology underneath each host controller is stable but > > > bus numbers (usb1, usb2 etc.) are not. > > > > Oh, that's news to me. So if I unplug and replug a USB device, the bus > > number and bus device number might change? > > The bus number is stable as long as the bus (host controller) exists. > > > Or does this happen after a power-cycle? Or is this hardware-specific? > > Consider a host controller on a plug-in card, like ExpressCard (usb1) > and perhaps Thunderbolt (usb2) for a more modern example. > > The bus on each new host controller gets the next available bus number. > > Plug ExpressCard before Thunderbolt to get the order above. Unplug > both (usb1+usb2 disappear) then plug Thunderbolt back in before > ExpressCard; now Thunderbolt is usb1 and ExpressCard usb2. Hm, right. With a first-come-first-served scheme, there is no way to have stable identifiers. I'm having a look at prior art: udev has similar needs for network interface names. For USB they use [2] a scheme with port/config/interface. I have no idea what meaning these have, but would they be useful for building a PATH KMS property? [1]: https://www.freedesktop.org/software/systemd/man/systemd.net-naming-scheme.html [2]: https://github.com/systemd/systemd/blob/7a67afe33192ce4a55e6825b80554fb4ebbb4b03/src/udev/udev-builtin-net_id.c#L758 > > > For onboard host controllers it could be possible to anchor to a > > > PCI or platform bus device. > > > > But the PCI bus device isn't enough I think? If I have a onboard host > > controller with 2 physical USB ports, the PCI bus device isn't enough > > to tell these 2 physical ports apart? > > Only the PCI bus device is not enough, but it could serve as a > unique anchor and some host controller-specific information (e.g. > root port number) can be added to that. > > > > How about using e.g. the serial number of the gud USB device instead > > > of host topology, or maybe some other information from the panel > > > behind it? > > > > The PATH property is really about the port path, not the sink. IOW, if > > I have two USB displays, one USB port, and switch between the two > > displays on this one port, the PATH property isn't supposed to change. > > Hmm. What is "port path" supposed to mean across a hot-pluggable bus? > > Should PATH refer to the one ExpressCard host controller if it moves > between slots (assuming a computer with two slots) or should it > rather refer to "the upper USB port on the right hand side ExpressCard" > so I can insert another brand host controller in that slot without > PATH changing? I think the latter makes most sense. I'll try to send a patch to improve the PATH property docs.
[PATCH] dma-buf/dma-buf.c: add a blank line between the two adjoining functions
Signed-off-by: suijingfeng <15330273...@189.cn>
---
drivers/dma-buf/dma-buf.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/dma-buf/dma-buf.c b/drivers/dma-buf/dma-buf.c
index 757c0fb77a6c..45d56aa4319c 100644
--- a/drivers/dma-buf/dma-buf.c
+++ b/drivers/dma-buf/dma-buf.c
@@ -777,10 +777,10 @@ static void mangle_sg_table(struct sg_table *sg_table)
for_each_sgtable_sg(sg_table, sg, i)
sg->page_link ^= ~0xffUL;
#endif
-
}
-static struct sg_table * __map_dma_buf(struct dma_buf_attachment *attach,
- enum dma_data_direction direction)
+
+static struct sg_table *__map_dma_buf(struct dma_buf_attachment *attach,
+ enum dma_data_direction direction)
{
struct sg_table *sg_table;
signed long ret;
--
2.25.1
[PATCH] drm/i915/gvt: Make use of idr_find and idr_for_each_entry in dmabuf
This patch uses the already existing IDR mechanism to simplify
and improve the dmabuf code.
Using 'vgpu.object_idr' directly instead of 'dmabuf_obj_list_head'
or 'dmabuf.list', because the dmabuf_obj can be found by 'idr_find'
or 'idr_for_each_entry'.
Signed-off-by: Cai Huoqing
---
drivers/gpu/drm/i915/gvt/dmabuf.c | 69 +++
drivers/gpu/drm/i915/gvt/dmabuf.h | 1 -
drivers/gpu/drm/i915/gvt/gvt.h| 1 -
drivers/gpu/drm/i915/gvt/vgpu.c | 1 -
4 files changed, 16 insertions(+), 56 deletions(-)
diff --git a/drivers/gpu/drm/i915/gvt/dmabuf.c
b/drivers/gpu/drm/i915/gvt/dmabuf.c
index 6834f9fe40cf..7933bd843ae8 100644
--- a/drivers/gpu/drm/i915/gvt/dmabuf.c
+++ b/drivers/gpu/drm/i915/gvt/dmabuf.c
@@ -133,21 +133,15 @@ static void dmabuf_gem_object_free(struct kref *kref)
struct intel_vgpu_dmabuf_obj *obj =
container_of(kref, struct intel_vgpu_dmabuf_obj, kref);
struct intel_vgpu *vgpu = obj->vgpu;
- struct list_head *pos;
struct intel_vgpu_dmabuf_obj *dmabuf_obj;
+ int id;
- if (vgpu && test_bit(INTEL_VGPU_STATUS_ACTIVE, vgpu->status) &&
- !list_empty(>dmabuf_obj_list_head)) {
- list_for_each(pos, >dmabuf_obj_list_head) {
- dmabuf_obj = list_entry(pos, struct
intel_vgpu_dmabuf_obj, list);
- if (dmabuf_obj == obj) {
- list_del(pos);
- idr_remove(>object_idr,
- dmabuf_obj->dmabuf_id);
- kfree(dmabuf_obj->info);
- kfree(dmabuf_obj);
- break;
- }
+ if (vgpu && test_bit(INTEL_VGPU_STATUS_ACTIVE, vgpu->status)) {
+ idr_for_each_entry(>object_idr, dmabuf_obj, id) {
+ idr_remove(>object_idr, id);
+ kfree(dmabuf_obj->info);
+ kfree(dmabuf_obj);
+ break;
}
} else {
/* Free the orphan dmabuf_objs here */
@@ -340,13 +334,11 @@ static struct intel_vgpu_dmabuf_obj *
pick_dmabuf_by_info(struct intel_vgpu *vgpu,
struct intel_vgpu_fb_info *latest_info)
{
- struct list_head *pos;
struct intel_vgpu_fb_info *fb_info;
struct intel_vgpu_dmabuf_obj *dmabuf_obj = NULL;
- struct intel_vgpu_dmabuf_obj *ret = NULL;
+ int id;
- list_for_each(pos, >dmabuf_obj_list_head) {
- dmabuf_obj = list_entry(pos, struct intel_vgpu_dmabuf_obj,
list);
+ idr_for_each_entry(>object_idr, dmabuf_obj, id) {
if (!dmabuf_obj->info)
continue;
@@ -357,31 +349,11 @@ pick_dmabuf_by_info(struct intel_vgpu *vgpu,
(fb_info->drm_format_mod == latest_info->drm_format_mod) &&
(fb_info->drm_format == latest_info->drm_format) &&
(fb_info->width == latest_info->width) &&
- (fb_info->height == latest_info->height)) {
- ret = dmabuf_obj;
- break;
- }
- }
-
- return ret;
-}
-
-static struct intel_vgpu_dmabuf_obj *
-pick_dmabuf_by_num(struct intel_vgpu *vgpu, u32 id)
-{
- struct list_head *pos;
- struct intel_vgpu_dmabuf_obj *dmabuf_obj = NULL;
- struct intel_vgpu_dmabuf_obj *ret = NULL;
-
- list_for_each(pos, >dmabuf_obj_list_head) {
- dmabuf_obj = list_entry(pos, struct intel_vgpu_dmabuf_obj,
list);
- if (dmabuf_obj->dmabuf_id == id) {
- ret = dmabuf_obj;
- break;
- }
+ (fb_info->height == latest_info->height))
+ return dmabuf_obj;
}
- return ret;
+ return dmabuf_obj;
}
static void update_fb_info(struct vfio_device_gfx_plane_info *gvt_dmabuf,
@@ -477,11 +449,6 @@ int intel_vgpu_query_plane(struct intel_vgpu *vgpu, void
*args)
update_fb_info(gfx_plane_info, _info);
- INIT_LIST_HEAD(_obj->list);
- mutex_lock(>dmabuf_lock);
- list_add_tail(_obj->list, >dmabuf_obj_list_head);
- mutex_unlock(>dmabuf_lock);
-
gvt_dbg_dpy("vgpu%d: %s new dmabuf_obj ref %d, id %d\n", vgpu->id,
__func__, kref_read(_obj->kref), ret);
@@ -508,7 +475,7 @@ int intel_vgpu_get_dmabuf(struct intel_vgpu *vgpu, unsigned
int dmabuf_id)
mutex_lock(>dmabuf_lock);
- dmabuf_obj = pick_dmabuf_by_num(vgpu, dmabuf_id);
+ dmabuf_obj = idr_find(>object_idr, dmabuf_id);
if (dmabuf_obj == NULL) {
gvt_vgpu_err("invalid dmabuf id:%d\n", dmabuf_id);
ret = -EINVAL;
@@ -570,23 +537,19 @@ int intel_vgpu_get_dmabuf(struct intel_vgpu *vgpu,
unsigned int dmabuf_id)
void intel_vgpu_dmabuf_cleanup(struct intel_vgpu *vgpu)
{
-
Re: gud: set PATH connector property
On Wednesday, March 1st, 2023 at 19:07, Noralf Trønnes wrote: > > Would it be possible to set the PATH connector property based on the > > USB port used by gud? > > > > This would give user-space a persistent identifier for the connector: > > if the user plugs in a USB display on a given port, the PATH would be > > the same even if the machine rebooted or the displays were plugged in > > in a different order. > > > > DP-MST already sets this. User-space can use this property to store > > output configuration metadata. > > drm_mode_connector_set_path_property() docs: > > This creates a property to expose to userspace to specify a connector > path. This is mainly used for DisplayPort MST where connectors have a > topology and we want to allow userspace to give them more meaningful names. > > Here it says that it's about giving meaningful names to connectors, I > think it would be useful to know that a HDMI-A connector is on a USB > adapter for instance and not on the laptop/motherboard. FWIW, the DP-MST PATH properties look like "mst:92-1". > You mention output configuration however, why does userspace use the > path to a connector when storing the multi display config and not some > unique property on the displays themselves like the serial number? It depends on the use-case. The reason why I'm asking about PATH is that Sway users want a way to configure specifically by port and not by sink. For instance, let's say I have a one USB display at home and another USB display at work. I always use the same USB port to connect USB displays. I want the USB display to always be arranged on the left of my primary display, as long as that USB port is used, regardless of which specific USB display is plugged in. See the wlroots patch [1] and the original Sway issue [2]. [1]: https://gitlab.freedesktop.org/wlroots/wlroots/-/merge_requests/3979 [2]: https://github.com/swaywm/sway/issues/7062
Re: [PATCH v2] drm/i915/active: Fix misuse of non-idle barriers as fence trackers
Hi Andy,
Thanks for review.
On Thursday, 2 March 2023 01:42:05 CET Andi Shyti wrote:
> Hi Janusz,
>
> On Sat, Feb 25, 2023 at 11:12:18PM +0100, Janusz Krzysztofik wrote:
> > Users reported oopses on list corruptions when using i915 perf with a
> > number of concurrently running graphics applications. Root cause analysis
> > pointed at an issue in barrier processing code -- a race among perf open /
> > close replacing active barriers with perf requests on kernel context and
> > concurrent barrier preallocate / acquire operations performed during user
> > context first pin / last unpin.
> >
> > When adding a request to a composite tracker, we try to reuse an existing
> > fence tracker, already allocated and registered with that composite. The
> > tracker we obtain may already track another fence, may be an idle barrier,
> > or an active barrier.
> >
> > If the tracker we get occurs a non-idle barrier then we try to delete that
> > barrier from a list of barrier tasks it belongs to. However, while doing
> > that we don't respect return value from a function that performs the
> > barrier deletion. Should the deletion ever failed, we would end up
> > reusing the tracker still registered as a barrier task. Since the same
> > structure field is reused with both fence callback lists and barrier
> > tasks list, list corruptions would likely occur.
> >
> > Barriers are now deleted from a barrier tasks list by temporarily removing
> > the list content, traversing that content with skip over the node to be
> > deleted, then populating the list back with the modified content. Should
> > that intentionally racy concurrent deletion attempts be not serialized,
> > one or more of those may fail because of the list being temporary empty.
> >
> > Related code that ignores the results of barrier deletion was initially
> > introduced in v5.4 by commit d8af05ff38ae ("drm/i915: Allow sharing the
> > idle-barrier from other kernel requests"). However, all users of the
> > barrier deletion routine were apparently serialized at that time, then the
> > issue didn't exhibit itself. Results of git bisect with help of a newly
> > developed igt@gem_barrier_race@remote-request IGT test indicate that list
> > corruptions might start to appear after commit 311770173fac ("drm/i915/gt:
> > Schedule request retirement when timeline idles"), introduced in v5.5.
> >
> > Respect results of barrier deletion attempts -- mark the barrier as idle
> > only if successfully deleted from the list. Then, before proceeding with
> > setting our fence as the one currently tracked, make sure that the tracker
> > we've got is not a non-idle barrier. If that check fails then don't use
> > that tracker but go back and try to acquire a new, usable one.
> >
> > v2: no code changes,
> > - blame commit 311770173fac ("drm/i915/gt: Schedule request retirement
> > when timeline idles"), v5.5, not commit d8af05ff38ae ("drm/i915: Allow
> > sharing the idle-barrier from other kernel requests"), v5.4,
> > - reword commit description.
>
> That's a very good explanation and very much needed for such a
> catch. Thanks!
>
> > Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/6333
> > Fixes: 311770173fac ("drm/i915/gt: Schedule request retirement when
timeline idles")
> > Cc: Chris Wilson
> > Cc: sta...@vger.kernel.org # v5.5
> > Signed-off-by: Janusz Krzysztofik
> > ---
> > drivers/gpu/drm/i915/i915_active.c | 25 ++---
> > 1 file changed, 14 insertions(+), 11 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/i915_active.c b/drivers/gpu/drm/i915/
i915_active.c
> > index 7412abf166a8c..f9282b8c87c1c 100644
> > --- a/drivers/gpu/drm/i915/i915_active.c
> > +++ b/drivers/gpu/drm/i915/i915_active.c
> > @@ -422,12 +422,12 @@ replace_barrier(struct i915_active *ref, struct
i915_active_fence *active)
> > * we can use it to substitute for the pending idle-barrer
> > * request that we want to emit on the kernel_context.
> > */
> > - __active_del_barrier(ref, node_from_active(active));
> > - return true;
> > + return __active_del_barrier(ref, node_from_active(active));
>
> In general, I support the idea of always checking the return
> value, even if we expect a certain outcome. In these cases, the
> likely/unlikely macros can be helpful.
OK.
> Given this change, I
> believe the patch deserves an ack.
>
> That being said, I was curious whether using an explicit lock
> and a normal list of active barriers, rather than a lockless
> list, could have solved the problem. It seems like using a
> lockless list and iterating over it could be overkill, unless
> there are specific scenarios where the lockless properties are
> necessary.
>
> Of course, this may be something to consider in a future cleanup,
> as it may be outside the scope of this particular patch.
Yes, I think so.
>
> > }
> >
> > int i915_active_add_request(struct i915_active *ref, struct i915_request
*rq)
> > {
> > + u64
Re: [PATCH] drm/vram-helper: turn on PRIME import/export
On Thursday, March 2nd, 2023 at 09:07, Thomas Zimmermann wrote: > Am 01.03.23 um 23:29 schrieb Simon Ser: > > > We don't populate gem_prime_import_sg_table so only DMA-BUFs > > exported from our own device can be imported. Still, this is useful > > to user-space. > > VRAM helpers don't really offer much flexibility or control in where to > place a BO. That's fine. The goal here is purely export/import to the exact same device. > What happens if the BO is located in device video ram and cannot be > used by the other participant? A blank screen? A failure at import-time should happen. But maybe this patch isn't enough to make this happen?
Re: [PATCH v2] MAINTAINERS: Add myself as maintainer for DRM Panels drivers
On 02/03/2023 11:29, Neil Armstrong wrote: Hi, On Wed, 01 Mar 2023 10:47:35 +0100, Neil Armstrong wrote: Add myself as co-maintainer for DRM Panel Drivers in order to help reviewing and getting new panels drivers merged, and Remove Thierry as he suggested since he wasn't active for a while. Thanks Thierry for all your work! [...] Thanks, Applied to https://anongit.freedesktop.org/git/drm/drm-misc.git (drm-misc-next-fixes) It's a typo from b4, it was applied on drm-misc-next. No idea why b4 uses drm-misc-next-fixes, the commit isn't in this branch... Neil [1/1] MAINTAINERS: Add myself as maintainer for DRM Panels drivers https://cgit.freedesktop.org/drm/drm-misc/commit/?id=4ddeb90d602ac58bcf99924eb34d8b2f820ce11d
Re: [PATCH v2] MAINTAINERS: Add myself as maintainer for DRM Panels drivers
Hi, On Wed, 01 Mar 2023 10:47:35 +0100, Neil Armstrong wrote: > Add myself as co-maintainer for DRM Panel Drivers in order to help > reviewing and getting new panels drivers merged, and Remove Thierry > as he suggested since he wasn't active for a while. > > Thanks Thierry for all your work! > > > [...] Thanks, Applied to https://anongit.freedesktop.org/git/drm/drm-misc.git (drm-misc-next-fixes) [1/1] MAINTAINERS: Add myself as maintainer for DRM Panels drivers https://cgit.freedesktop.org/drm/drm-misc/commit/?id=4ddeb90d602ac58bcf99924eb34d8b2f820ce11d -- Neil
Re: [PATCH 1/2] habanalabs: unify err log of hw-fini failure in dirty state
On Thu, Mar 02, 2023 at 11:15:16AM +0200, Oded Gabbay wrote: > From: Dafna Hirschfeld > > print more informative message when failing in dirty state > > Signed-off-by: Dafna Hirschfeld > Reviewed-by: Oded Gabbay > Signed-off-by: Oded Gabbay Reviewed-by: Stanislaw Gruszka > ---
Re: [PATCH 2/2] habanalabs: use scnprintf() in print_device_in_use_info()
On Thu, Mar 02, 2023 at 11:15:17AM +0200, Oded Gabbay wrote: > From: Tomer Tayar > > compose_device_in_use_info() was added to handle the snprintf() return > value in a single place. > However, the buffer size in print_device_in_use_info() is set such that > it would be enough for the max possible print, so > compose_device_in_use_info() is not really needed. > Moreover, scnprintf() can be used instead of snprintf(), to save the > check if the return value larger than the given size. > > Cc: Stanislaw Gruszka > Signed-off-by: Tomer Tayar > Reviewed-by: Oded Gabbay > Signed-off-by: Oded Gabbay Reviewed-by: Stanislaw Gruszka
Re: [PATCH] drm/vram-helper: turn on PRIME import/export
On Thursday, March 2nd, 2023 at 08:11, Christian König wrote: > Am 01.03.23 um 23:29 schrieb Simon Ser: > > > We don't populate gem_prime_import_sg_table so only DMA-BUFs > > exported from our own device can be imported. Still, this is useful > > to user-space. > > But what happens if one of your BOs is imported into another device? Is there a way to make this fail, always?
RE: [PATCH] gpu: amd/pm: mark symbols static where possible for smu11
[AMD Official Use Only - General]
Thanks. But I think there was already a patch from Kun Liu to address this
issue.
https://lists.freedesktop.org/archives/amd-gfx/2023-March/090029.html
BR
Evan
> -Original Message-
> From: Jeff Pang
> Sent: Thursday, March 2, 2023 5:16 PM
> To: Quan, Evan
> Cc: amd-...@lists.freedesktop.org; linux-ker...@vger.kernel.org; dri-
> de...@lists.freedesktop.org; Jeff Pang
> Subject: [PATCH] gpu: amd/pm: mark symbols static where possible for
> smu11
>
> I get one warning when building kernel with -Werror=missing-prototypes :
>
> drivers/gpu/drm/amd/amdgpu/../pm/swsmu/smu11/vangogh_ppt.c:1600:5:
> error: no previous prototype for ‘vangogh_set_apu_thermal_limit’
> [-Werror=missing-prototypes]
> int vangogh_set_apu_thermal_limit(struct smu_context *smu, uint32_t limit)
>
> In fact, this function don't need a declaration due to it's only used in the
> file
> which they are.
> So this patch marks the function with 'static'.
>
> Signed-off-by: Jeff Pang
> ---
> drivers/gpu/drm/amd/pm/swsmu/smu11/vangogh_ppt.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/amd/pm/swsmu/smu11/vangogh_ppt.c
> b/drivers/gpu/drm/amd/pm/swsmu/smu11/vangogh_ppt.c
> index 016d5621e0b3..24046af60933 100644
> --- a/drivers/gpu/drm/amd/pm/swsmu/smu11/vangogh_ppt.c
> +++ b/drivers/gpu/drm/amd/pm/swsmu/smu11/vangogh_ppt.c
> @@ -1597,7 +1597,7 @@ static int vangogh_get_apu_thermal_limit(struct
> smu_context *smu, uint32_t *limi
> 0, limit);
> }
>
> -int vangogh_set_apu_thermal_limit(struct smu_context *smu, uint32_t
> limit)
> +static int vangogh_set_apu_thermal_limit(struct smu_context *smu,
> +uint32_t limit)
> {
> return smu_cmn_send_smc_msg_with_param(smu,
>
> SMU_MSG_SetReducedThermalLimit,
> --
> 2.34.1
[PATCH 2/2] habanalabs: use scnprintf() in print_device_in_use_info()
From: Tomer Tayar
compose_device_in_use_info() was added to handle the snprintf() return
value in a single place.
However, the buffer size in print_device_in_use_info() is set such that
it would be enough for the max possible print, so
compose_device_in_use_info() is not really needed.
Moreover, scnprintf() can be used instead of snprintf(), to save the
check if the return value larger than the given size.
Cc: Stanislaw Gruszka
Signed-off-by: Tomer Tayar
Reviewed-by: Oded Gabbay
Signed-off-by: Oded Gabbay
---
drivers/accel/habanalabs/common/device.c | 36 +++-
1 file changed, 10 insertions(+), 26 deletions(-)
diff --git a/drivers/accel/habanalabs/common/device.c
b/drivers/accel/habanalabs/common/device.c
index 99e793dfb126..8db00cb3b71d 100644
--- a/drivers/accel/habanalabs/common/device.c
+++ b/drivers/accel/habanalabs/common/device.c
@@ -482,48 +482,32 @@ int hl_hpriv_put(struct hl_fpriv *hpriv)
return kref_put(>refcount, hpriv_release);
}
-static void compose_device_in_use_info(char **buf, size_t *buf_size, const
char *fmt, ...)
-{
- struct va_format vaf;
- va_list args;
- int size;
-
- va_start(args, fmt);
- vaf.fmt = fmt;
- vaf.va =
-
- size = snprintf(*buf, *buf_size, "%pV", );
- if (size >= *buf_size)
- size = *buf_size;
-
- *buf += size;
- *buf_size -= size;
-
- va_end(args);
-}
-
static void print_device_in_use_info(struct hl_device *hdev, const char
*message)
{
u32 active_cs_num, dmabuf_export_cnt;
- char buf[64], *buf_ptr = buf;
- size_t buf_size = sizeof(buf);
bool unknown_reason = true;
+ char buf[128];
+ size_t size;
+ int offset;
+
+ size = sizeof(buf);
+ offset = 0;
active_cs_num = hl_get_active_cs_num(hdev);
if (active_cs_num) {
unknown_reason = false;
- compose_device_in_use_info(_ptr, _size, " [%u active
CS]", active_cs_num);
+ offset += scnprintf(buf + offset, size - offset, " [%u active
CS]", active_cs_num);
}
dmabuf_export_cnt = atomic_read(>dmabuf_export_cnt);
if (dmabuf_export_cnt) {
unknown_reason = false;
- compose_device_in_use_info(_ptr, _size, " [%u exported
dma-buf]",
- dmabuf_export_cnt);
+ offset += scnprintf(buf + offset, size - offset, " [%u exported
dma-buf]",
+ dmabuf_export_cnt);
}
if (unknown_reason)
- compose_device_in_use_info(_ptr, _size, " [unknown
reason]");
+ scnprintf(buf + offset, size - offset, " [unknown reason]");
dev_notice(hdev->dev, "%s%s\n", message, buf);
}
--
2.39.2
[PATCH 1/2] habanalabs: unify err log of hw-fini failure in dirty state
From: Dafna Hirschfeld
print more informative message when failing in dirty state
Signed-off-by: Dafna Hirschfeld
Reviewed-by: Oded Gabbay
Signed-off-by: Oded Gabbay
---
drivers/accel/habanalabs/gaudi2/gaudi2.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/accel/habanalabs/gaudi2/gaudi2.c
b/drivers/accel/habanalabs/gaudi2/gaudi2.c
index 58e3bffb8c25..99af319cd023 100644
--- a/drivers/accel/habanalabs/gaudi2/gaudi2.c
+++ b/drivers/accel/habanalabs/gaudi2/gaudi2.c
@@ -2896,7 +2896,7 @@ static int gaudi2_early_init(struct hl_device *hdev)
dev_dbg(hdev->dev, "H/W state is dirty, must reset before
initializing\n");
rc = hdev->asic_funcs->hw_fini(hdev, true, false);
if (rc) {
- dev_err(hdev->dev, "failed to reset HW during early
init (%d)\n", rc);
+ dev_err(hdev->dev, "failed to reset HW in dirty state
(%d)\n", rc);
goto pci_fini;
}
}
--
2.39.2
[PATCH RESEND] drm/tests: Suballocator test
Add a suballocator test to get some test coverage for the new drm
suballocator, and perform some basic timing (elapsed time).
Signed-off-by: Thomas Hellström
---
drivers/gpu/drm/Kconfig | 1 +
drivers/gpu/drm/tests/Makefile| 3 +-
drivers/gpu/drm/tests/drm_suballoc_test.c | 356 ++
3 files changed, 359 insertions(+), 1 deletion(-)
create mode 100644 drivers/gpu/drm/tests/drm_suballoc_test.c
diff --git a/drivers/gpu/drm/Kconfig b/drivers/gpu/drm/Kconfig
index 8fbe57407c60..dced53723721 100644
--- a/drivers/gpu/drm/Kconfig
+++ b/drivers/gpu/drm/Kconfig
@@ -78,6 +78,7 @@ config DRM_KUNIT_TEST
select DRM_LIB_RANDOM
select DRM_KMS_HELPER
select DRM_BUDDY
+ select DRM_SUBALLOC_HELPER
select DRM_EXPORT_FOR_TESTS if m
select DRM_KUNIT_TEST_HELPERS
default KUNIT_ALL_TESTS
diff --git a/drivers/gpu/drm/tests/Makefile b/drivers/gpu/drm/tests/Makefile
index bca726a8f483..c664944a48ab 100644
--- a/drivers/gpu/drm/tests/Makefile
+++ b/drivers/gpu/drm/tests/Makefile
@@ -17,6 +17,7 @@ obj-$(CONFIG_DRM_KUNIT_TEST) += \
drm_modes_test.o \
drm_plane_helper_test.o \
drm_probe_helper_test.o \
- drm_rect_test.o
+ drm_rect_test.o \
+ drm_suballoc_test.o
CFLAGS_drm_mm_test.o := $(DISABLE_STRUCTLEAK_PLUGIN)
diff --git a/drivers/gpu/drm/tests/drm_suballoc_test.c
b/drivers/gpu/drm/tests/drm_suballoc_test.c
new file mode 100644
index ..e7303a5505a0
--- /dev/null
+++ b/drivers/gpu/drm/tests/drm_suballoc_test.c
@@ -0,0 +1,356 @@
+// SPDX-License-Identifier: GPL-2.0 OR MIT
+/*
+ * Test case for the drm_suballoc suballocator manager
+ * Copyright 2023 Intel Corporation.
+ */
+
+#include
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#define SA_ITERATIONS 1
+#define SA_SIZE SZ_1M
+#define SA_DEFAULT_ALIGN SZ_4K
+
+static bool intr = true;
+static bool from_reclaim;
+static bool pre_throttle;
+static unsigned int num_rings = 4;
+static unsigned int iterations = SA_ITERATIONS;
+
+static atomic64_t free_space;
+
+static atomic_t other_id;
+
+struct suballoc_fence;
+
+/**
+ * struct suballoc_ring - fake gpu engine.
+ * @list: List of fences to signal.
+ * @signal_time: Accumulated fence signal execution time.
+ * @lock: Protects the suballoc ring members. hardirq safe.
+ * @hrtimer: Fake execution time timer.
+ * @active: The currently active fence for which we have pending work or a
+ * timer running.
+ * @seqno: Fence submissin seqno.
+ * @idx: Index for calculation of fake execution time.
+ * @work: Work struct used solely to move the timer start to a different
+ *processor than that used for submission.
+ */
+struct suballoc_ring {
+ ktime_t signal_time;
+ struct list_head list;
+ /* Protect the ring processing. */
+ spinlock_t lock;
+ struct hrtimer hrtimer;
+ struct suballoc_fence *active;
+ atomic64_t seqno;
+ u32 idx;
+ struct work_struct work;
+};
+
+/**
+ * struct suballoc_fence - Hrtimer-driven fence.
+ * @fence: The base class fence struct.
+ * @link: Link for the ring's fence list.
+ * @size: The size of the suballocator range associated with this fence.
+ * @id: Cpu id likely used by the submission thread for suballoc allocation.
+ */
+struct suballoc_fence {
+ struct dma_fence fence;
+ struct list_head link;
+ size_t size;
+ unsigned int id;
+};
+
+/* A varying but repeatable fake execution time */
+static ktime_t ring_next_delay(struct suballoc_ring *ring)
+{
+ return ns_to_ktime((u64)(++ring->idx % 8) * 200 * NSEC_PER_USEC);
+}
+
+/*
+ * Launch from a work item to decrease the likelyhood of the timer expiry
+ * callback getting called from the allocating cpu.
+ * We want to trigger cache-line bouncing between allocating and signalling
+ * cpus.
+ */
+static void ring_launch_timer_work(struct work_struct *work)
+{
+ struct suballoc_ring *ring =
+ container_of(work, typeof(*ring), work);
+
+ spin_lock_irq(>lock);
+ if (ring->active)
+ hrtimer_start_range_ns(>hrtimer, ring_next_delay(ring),
+ 100ULL * NSEC_PER_USEC,
+ HRTIMER_MODE_REL_PINNED);
+
+ spin_unlock_irq(>lock);
+}
+
+/*
+ * Signal an active fence and pull the next off the list if any and make it
+ * active.
+ */
+static enum hrtimer_restart ring_hrtimer_expired(struct hrtimer *hrtimer)
+{
+ struct suballoc_ring *ring =
+ container_of(hrtimer, typeof(*ring), hrtimer);
+ struct suballoc_fence *sfence;
+ ktime_t now, then;
+ unsigned long irqflags;
+
+ spin_lock_irqsave(>lock, irqflags);
+ sfence = ring->active;
+
+ if (sfence) {
+ struct dma_fence *fence = >fence;
+
+ if (sfence->id != get_cpu())
+ atomic_inc(_id);
+
[PATCHv4 2/2] i915/display/dp: SDP CRC16 for 128b132b link layer
Enable SDP error detection configuration, this will set CRC16 in
128b/132b link layer.
For Display version 13 a hardware bit31 in register VIDEO_DIP_CTL is
added to enable/disable SDP CRC applicable for DP2.0 only, but the
default value of this bit will enable CRC16 in 128b/132b hence
skipping this write.
Corrective actions on SDP corruption is yet to be defined.
v2: Moved the CRC enable to link training init(Jani N)
v3: Moved crc enable to ddi pre enable
v4: Separate function for SDP CRC16 (Jani N)
Signed-off-by: Arun R Murthy
---
drivers/gpu/drm/i915/display/intel_ddi.c | 4
.../drm/i915/display/intel_dp_link_training.c | 20 +++
.../drm/i915/display/intel_dp_link_training.h | 2 ++
3 files changed, 26 insertions(+)
diff --git a/drivers/gpu/drm/i915/display/intel_ddi.c
b/drivers/gpu/drm/i915/display/intel_ddi.c
index e5979427b38b..127b3035f92d 100644
--- a/drivers/gpu/drm/i915/display/intel_ddi.c
+++ b/drivers/gpu/drm/i915/display/intel_ddi.c
@@ -2519,6 +2519,10 @@ static void intel_ddi_pre_enable_dp(struct
intel_atomic_state *state,
{
struct drm_i915_private *dev_priv = to_i915(encoder->base.dev);
+ if (HAS_DP20(dev_priv))
+ intel_dp_128b132b_sdp_crc16(enc_to_intel_dp(encoder),
+ crtc_state);
+
if (DISPLAY_VER(dev_priv) >= 12)
tgl_ddi_pre_enable_dp(state, encoder, crtc_state, conn_state);
else
diff --git a/drivers/gpu/drm/i915/display/intel_dp_link_training.c
b/drivers/gpu/drm/i915/display/intel_dp_link_training.c
index 3d3efcf02011..35d31e4efab9 100644
--- a/drivers/gpu/drm/i915/display/intel_dp_link_training.c
+++ b/drivers/gpu/drm/i915/display/intel_dp_link_training.c
@@ -1454,3 +1454,23 @@ void intel_dp_start_link_train(struct intel_dp *intel_dp,
if (!passed)
intel_dp_schedule_fallback_link_training(intel_dp, crtc_state);
}
+
+void intel_dp_128b132b_sdp_crc16(struct intel_dp *intel_dp,
+const struct intel_crtc_state *crtc_state)
+{
+ struct drm_i915_private *i915 = dp_to_i915(intel_dp);
+
+ /*
+* VIDEO_DIP_CTL register bit 31 should be set to '0' to not
+* disable SDP CRC. This is applicable for Display version 13.
+* Default value of bit 31 is '0' hence discarding the write
+* TODO: Corrective actions on SDP corruption yet to be defined
+*/
+ if (intel_dp_is_uhbr(crtc_state))
+ /* DP v2.0 SCR on SDP CRC16 for 128b/132b Link Layer */
+ drm_dp_dpcd_writeb(_dp->aux,
+ DP_SDP_ERROR_DETECTION_CONFIGURATION,
+ DP_SDP_CRC16_128B132B_EN);
+
+ drm_dbg_kms(>drm, "DP2.0 SDP CRC16 for 128b/132b enabled\n");
+}
diff --git a/drivers/gpu/drm/i915/display/intel_dp_link_training.h
b/drivers/gpu/drm/i915/display/intel_dp_link_training.h
index 7fa1c0833096..2c8f2775891b 100644
--- a/drivers/gpu/drm/i915/display/intel_dp_link_training.h
+++ b/drivers/gpu/drm/i915/display/intel_dp_link_training.h
@@ -39,4 +39,6 @@ static inline u8 intel_dp_training_pattern_symbol(u8 pattern)
return pattern & ~DP_LINK_SCRAMBLING_DISABLE;
}
+void intel_dp_128b132b_sdp_crc16(struct intel_dp *intel_dp,
+const struct intel_crtc_state *crtc_state);
#endif /* __INTEL_DP_LINK_TRAINING_H__ */
--
2.25.1
