Re: [Freedreno] [PATCH v2 04/17] drm/msm/dpu: Fix PP_BLK_DIPHER -> DITHER typo
On 2023-04-24 16:09:45, Abhinav Kumar wrote:
> >> dither block should be present on many other chipsets too but looks like
> >> on sm8550 was enabling it. Not sure how it was validated there. But we
> >> are enabling dither, even other chipsets have this block.
> >
> > Correct, they all seem to have it starting at sdm845. My patch message
> > seems to lack the word "exclusively" as the PP on sm8550 appears to
> > exclusively contain a DITHER subblock (unless other blocks are available
> > that simply aren't supported within this driver yet) and no other
> > registers. Hence this aptly named macro exist to emit just the feature
> > bitflag for that and a .len of zero.
> >
>
> I think after the TE blocks were moved to INTF, dither is the only
> sub-block for all Ping-Pongs not just in sm8550.
So you are asking / leaving context to make all >= 5.0.0 pingpong blocks
use this macro with only a single DITHER sblk in PP?
As far as I recall SM8550 is the first SoC to use zero registers in PP,
which is specifically what this macro takes care of too. Then, there
are only a few SoCs downstream still (erroneously?) referencing TE2 as
the only other sub-blk, those SoCs still use sdm845_pp_sblk_te.
> > Now, whether we should have the features contain subblock flags rather
> > than just scanning for their id's or presence in the subblocks is a
> > different discussion / cleanup we should have.
> >
>
> Yes, separate patch and hence I gave R-b on this one. But had to leave
> this comment to not lose context.
Fwiw this is a different suggestion: we already have these flags in the
sub-block `.id` field so there seems to be no reason to duplicate info
in the top-level `.features` field, deduplicating some info and
simplifying some defines.
- Marijn
> > - Marijn
> >
> >>> - PP_BLK_DIPHER("pingpong_0", PINGPONG_0, 0x69000, MERGE_3D_0,
> >>> sc7280_pp_sblk,
> >>> + PP_BLK_DITHER("pingpong_0", PINGPONG_0, 0x69000, MERGE_3D_0,
> >>> sc7280_pp_sblk,
> >>> DPU_IRQ_IDX(MDP_SSPP_TOP0_INTR, 8),
> >>> -1),
> >>> - PP_BLK_DIPHER("pingpong_1", PINGPONG_1, 0x6a000, MERGE_3D_0,
> >>> sc7280_pp_sblk,
> >>> + PP_BLK_DITHER("pingpong_1", PINGPONG_1, 0x6a000, MERGE_3D_0,
> >>> sc7280_pp_sblk,
> >>> DPU_IRQ_IDX(MDP_SSPP_TOP0_INTR, 9),
> >>> -1),
> >>> - PP_BLK_DIPHER("pingpong_2", PINGPONG_2, 0x6b000, MERGE_3D_1,
> >>> sc7280_pp_sblk,
> >>> + PP_BLK_DITHER("pingpong_2", PINGPONG_2, 0x6b000, MERGE_3D_1,
> >>> sc7280_pp_sblk,
> >>> DPU_IRQ_IDX(MDP_SSPP_TOP0_INTR, 10),
> >>> -1),
> >>> - PP_BLK_DIPHER("pingpong_3", PINGPONG_3, 0x6c000, MERGE_3D_1,
> >>> sc7280_pp_sblk,
> >>> + PP_BLK_DITHER("pingpong_3", PINGPONG_3, 0x6c000, MERGE_3D_1,
> >>> sc7280_pp_sblk,
> >>> DPU_IRQ_IDX(MDP_SSPP_TOP0_INTR, 11),
> >>> -1),
> >>> - PP_BLK_DIPHER("pingpong_4", PINGPONG_4, 0x6d000, MERGE_3D_2,
> >>> sc7280_pp_sblk,
> >>> + PP_BLK_DITHER("pingpong_4", PINGPONG_4, 0x6d000, MERGE_3D_2,
> >>> sc7280_pp_sblk,
> >>> DPU_IRQ_IDX(MDP_SSPP_TOP0_INTR2, 30),
> >>> -1),
> >>> - PP_BLK_DIPHER("pingpong_5", PINGPONG_5, 0x6e000, MERGE_3D_2,
> >>> sc7280_pp_sblk,
> >>> + PP_BLK_DITHER("pingpong_5", PINGPONG_5, 0x6e000, MERGE_3D_2,
> >>> sc7280_pp_sblk,
> >>> DPU_IRQ_IDX(MDP_SSPP_TOP0_INTR2, 31),
> >>> -1),
> >>> - PP_BLK_DIPHER("pingpong_6", PINGPONG_6, 0x66000, MERGE_3D_3,
> >>> sc7280_pp_sblk,
> >>> + PP_BLK_DITHER("pingpong_6", PINGPONG_6, 0x66000, MERGE_3D_3,
> >>> sc7280_pp_sblk,
> >>> -1,
> >>> -1),
> >>> - PP_BLK_DIPHER("pingpong_7", PINGPONG_7, 0x66400, MERGE_3D_3,
> >>> sc7280_pp_sblk,
> >>> + PP_BLK_DITHER("pingpong_7", PINGPONG_7, 0x66400, MERGE_3D_3,
> >>> sc7280_pp_sblk,
> >>> -1,
> >>> -1),
> >>>};
> >>> 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 03f162af1a50..ca8a02debda9 100644
> >>> --- a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c
> >>> +++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c
> >>> @@ -491,7 +491,7 @@ static const struct dpu_pingpong_sub_blks
> >>> sc7280_pp_sblk = {
> >>> .len = 0x20, .version = 0x2},
> >>>};
> >>>
> >>> -#define PP_BLK_DIPHER(_name, _id, _base, _merge_3d, _sblk, _done,
> >>> _rdptr) \
> >>> +#define PP_BLK_DITHER(_name, _id, _base, _merge_3d, _sblk, _done,
> >>> _rdptr) \
> >>> {\
> >>> .name = _name, .id = _id, \
> >>> .base = _base, .len = 0, \
> >>>
Re: [Intel-gfx] [PATCH 2/2] Revert "drm/i915/mtl: Define MOCS and PAT tables for MTL"
On 24.04.2023 18:09, Andi Shyti wrote:
This reverts commit b76c0deef6273609c02ed5053209f6397cd1b0fb.
This patch is causing boot failures for MTL.
Revert it.
Signed-off-by: Andi Shyti
Cc: Matt Roper
Cc: Lucas De Marchi
Cc: Aravind Iddamsetty
Cc: Nirmoy Das
Cc: Fei Yang
Cc: Andrzej Hajda
Reviewed-by: Andrzej Hajda
Regards
Andrzej
---
drivers/gpu/drm/i915/gt/intel_gt_regs.h | 6 +--
drivers/gpu/drm/i915/gt/intel_gtt.c | 47 +
drivers/gpu/drm/i915/gt/intel_gtt.h | 8 ---
drivers/gpu/drm/i915/gt/intel_mocs.c| 70 +
4 files changed, 3 insertions(+), 128 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/intel_gt_regs.h
b/drivers/gpu/drm/i915/gt/intel_gt_regs.h
index e8c3b762a92a3..fd1f9cd35e9d7 100644
--- a/drivers/gpu/drm/i915/gt/intel_gt_regs.h
+++ b/drivers/gpu/drm/i915/gt/intel_gt_regs.h
@@ -356,11 +356,7 @@
#define GEN7_TLB_RD_ADDR _MMIO(0x4700)
#define GEN12_PAT_INDEX(index) _MMIO(0x4800 + (index) * 4)
-#define _PAT_INDEX(index) _PICK_EVEN_2RANGES(index, 8, \
- 0x4800,
0x4804, \
- 0x4848,
0x484c)
-#define XEHP_PAT_INDEX(index) MCR_REG(_PAT_INDEX(index))
-#define XELPMP_PAT_INDEX(index)_MMIO(_PAT_INDEX(index))
+#define XEHP_PAT_INDEX(index) MCR_REG(0x4800 + (index) * 4)
#define XEHP_TILE0_ADDR_RANGE MCR_REG(0x4900)
#define XEHP_TILE_LMEM_RANGE_SHIFT 8
diff --git a/drivers/gpu/drm/i915/gt/intel_gtt.c
b/drivers/gpu/drm/i915/gt/intel_gtt.c
index 2f6a9be0ffe61..4f436ba7a3c83 100644
--- a/drivers/gpu/drm/i915/gt/intel_gtt.c
+++ b/drivers/gpu/drm/i915/gt/intel_gtt.c
@@ -468,44 +468,6 @@ void gtt_write_workarounds(struct intel_gt *gt)
}
}
-static void xelpmp_setup_private_ppat(struct intel_uncore *uncore)
-{
- intel_uncore_write(uncore, XELPMP_PAT_INDEX(0),
- MTL_PPAT_L4_0_WB);
- intel_uncore_write(uncore, XELPMP_PAT_INDEX(1),
- MTL_PPAT_L4_1_WT);
- intel_uncore_write(uncore, XELPMP_PAT_INDEX(2),
- MTL_PPAT_L4_3_UC);
- intel_uncore_write(uncore, XELPMP_PAT_INDEX(3),
- MTL_PPAT_L4_0_WB | MTL_2_COH_1W);
- intel_uncore_write(uncore, XELPMP_PAT_INDEX(4),
- MTL_PPAT_L4_0_WB | MTL_3_COH_2W);
-
- /*
-* Remaining PAT entries are left at the hardware-default
-* fully-cached setting
-*/
-}
-
-static void xelpg_setup_private_ppat(struct intel_gt *gt)
-{
- intel_gt_mcr_multicast_write(gt, XEHP_PAT_INDEX(0),
-MTL_PPAT_L4_0_WB);
- intel_gt_mcr_multicast_write(gt, XEHP_PAT_INDEX(1),
-MTL_PPAT_L4_1_WT);
- intel_gt_mcr_multicast_write(gt, XEHP_PAT_INDEX(2),
-MTL_PPAT_L4_3_UC);
- intel_gt_mcr_multicast_write(gt, XEHP_PAT_INDEX(3),
-MTL_PPAT_L4_0_WB | MTL_2_COH_1W);
- intel_gt_mcr_multicast_write(gt, XEHP_PAT_INDEX(4),
-MTL_PPAT_L4_0_WB | MTL_3_COH_2W);
-
- /*
-* Remaining PAT entries are left at the hardware-default
-* fully-cached setting
-*/
-}
-
static void tgl_setup_private_ppat(struct intel_uncore *uncore)
{
/* TGL doesn't support LLC or AGE settings */
@@ -641,14 +603,7 @@ void setup_private_pat(struct intel_gt *gt)
GEM_BUG_ON(GRAPHICS_VER(i915) < 8);
- if (gt->type == GT_MEDIA) {
- xelpmp_setup_private_ppat(gt->uncore);
- return;
- }
-
- if (GRAPHICS_VER_FULL(i915) >= IP_VER(12, 70))
- xelpg_setup_private_ppat(gt);
- else if (GRAPHICS_VER_FULL(i915) >= IP_VER(12, 50))
+ if (GRAPHICS_VER_FULL(i915) >= IP_VER(12, 50))
xehp_setup_private_ppat(gt);
else if (GRAPHICS_VER(i915) >= 12)
tgl_setup_private_ppat(uncore);
diff --git a/drivers/gpu/drm/i915/gt/intel_gtt.h
b/drivers/gpu/drm/i915/gt/intel_gtt.h
index ea17849e7a5c8..69ce55f517f56 100644
--- a/drivers/gpu/drm/i915/gt/intel_gtt.h
+++ b/drivers/gpu/drm/i915/gt/intel_gtt.h
@@ -147,14 +147,6 @@ typedef u64 gen8_pte_t;
#define GEN8_PDE_IPS_64K BIT(11)
#define GEN8_PDE_PS_2M BIT(7)
-#define MTL_PPAT_L4_CACHE_POLICY_MASK REG_GENMASK(3, 2)
-#define MTL_PAT_INDEX_COH_MODE_MASKREG_GENMASK(1, 0)
-#define MTL_PPAT_L4_3_UC REG_FIELD_PREP(MTL_PPAT_L4_CACHE_POLICY_MASK, 3)
-#define MTL_PPAT_L4_1_WT REG_FIELD_PREP(MTL_PPAT_L4_CACHE_POLICY_MASK, 1)
-#define MTL_PPAT_L4_0_WB REG_FIELD_PREP(MTL_PPAT_L4_CACHE_POLICY_MASK, 0)
-#define MTL_3_COH_2W REG_FIELD_PREP(MTL_PAT_INDEX_COH_MODE_MASK, 3)
-#define MTL_2_COH_1W REG_FIELD_PREP(MTL_PAT_INDEX_COH_MODE_MASK, 2)
-
en
Re: [Intel-gfx] [PATCH 1/2] Revert "drm/i915/mtl: fix mocs selftest"
On 24.04.2023 18:09, Andi Shyti wrote:
This reverts commit faca6aaa4838c3c234caa619d3c7d1f09da0d303.
This patch, in series with the next "Define MOCS and PAT tables
for MTL" are causing boot failures for MTL.
Revert them both.
Signed-off-by: Andi Shyti
Cc: Fei Yang
Cc: Matt Roper
Reviewed-by: Andrzej Hajda
Regards
Andrzej
---
drivers/gpu/drm/i915/gt/selftest_mocs.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/selftest_mocs.c
b/drivers/gpu/drm/i915/gt/selftest_mocs.c
index a8446ab825012..ca009a6a13bdb 100644
--- a/drivers/gpu/drm/i915/gt/selftest_mocs.c
+++ b/drivers/gpu/drm/i915/gt/selftest_mocs.c
@@ -131,14 +131,13 @@ static int read_mocs_table(struct i915_request *rq,
const struct drm_i915_mocs_table *table,
u32 *offset)
{
- struct intel_gt *gt = rq->engine->gt;
u32 addr;
if (!table)
return 0;
if (HAS_GLOBAL_MOCS_REGISTERS(rq->engine->i915))
- addr = global_mocs_offset() + gt->uncore->gsi_offset;
+ addr = global_mocs_offset();
else
addr = mocs_offset(rq->engine);
[linux-next:master] BUILD REGRESSION 3b85b9b39960c08f29fa91b8d984d055dde6017e
tree/branch: https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git master branch HEAD: 3b85b9b39960c08f29fa91b8d984d055dde6017e Add linux-next specific files for 20230424 Error/Warning reports: https://lore.kernel.org/oe-kbuild-all/202304102354.q4voxgte-...@intel.com https://lore.kernel.org/oe-kbuild-all/202304210303.nlmi0srq-...@intel.com https://lore.kernel.org/oe-kbuild-all/202304210349.dykci88s-...@intel.com https://lore.kernel.org/oe-kbuild-all/202304230014.ybscpx20-...@intel.com https://lore.kernel.org/oe-kbuild-all/202304250419.ytcltuhg-...@intel.com Error/Warning: (recently discovered and may have been fixed) arch/um/drivers/harddog_user.c:6:10: fatal error: stdio.h: No such file or directory drivers/accel/habanalabs/gaudi/gaudi.c:117:19: warning: unused variable 'gaudi_irq_name' [-Wunused-const-variable] drivers/base/regmap/regcache-maple.c:113:23: warning: 'lower_index' is used uninitialized [-Wuninitialized] drivers/base/regmap/regcache-maple.c:113:36: warning: 'lower_last' is used uninitialized [-Wuninitialized] drivers/gpu/drm/amd/amdgpu/amdgpu_gfx.c:456:16: warning: variable 'j' set but not used [-Wunused-but-set-variable] drivers/gpu/drm/amd/amdgpu/gfx_v9_4_3.c:1078:6: warning: no previous prototype for 'gfx_v9_4_3_disable_gpa_mode' [-Wmissing-prototypes] drivers/gpu/drm/amd/amdgpu/gfx_v9_4_3.c:1078:6: warning: no previous prototype for function 'gfx_v9_4_3_disable_gpa_mode' [-Wmissing-prototypes] drivers/gpu/drm/amd/amdgpu/gfx_v9_4_3.c:48:38: warning: unused variable 'golden_settings_gc_9_4_3' [-Wunused-const-variable] drivers/gpu/drm/i915/gt/uc/guc_capture_fwif.h:62: warning: wrong kernel-doc identifier on line: drivers/gpu/drm/i915/i915_pmu.h:41: warning: This comment starts with '/**', but isn't a kernel-doc comment. Refer Documentation/doc-guide/kernel-doc.rst drivers/gpu/drm/i915/i915_request.h:176: warning: This comment starts with '/**', but isn't a kernel-doc comment. Refer Documentation/doc-guide/kernel-doc.rst drivers/gpu/drm/i915/i915_vma.h:145: warning: expecting prototype for i915_vma_offset(). Prototype was for i915_vma_size() instead drivers/phy/mediatek/phy-mtk-hdmi-mt8195.c:298:6: warning: variable 'ret' is uninitialized when used here [-Wuninitialized] fs/ext4/super.c:1262:13: warning: unused variable 'i' [-Wunused-variable] fs/ext4/super.c:1262:6: warning: unused variable 'i' [-Wunused-variable] ld.lld: error: .btf.vmlinux.bin.o: unknown file type Unverified Error/Warning (likely false positive, please contact us if interested): drivers/acpi/property.c:985 acpi_data_prop_read_single() error: potentially dereferencing uninitialized 'obj'. Error/Warning ids grouped by kconfigs: gcc_recent_errors |-- alpha-allyesconfig | |-- drivers-gpu-drm-amd-amdgpu-amdgpu_gfx.c:warning:variable-j-set-but-not-used | `-- drivers-gpu-drm-amd-amdgpu-gfx_v9_4_3.c:warning:no-previous-prototype-for-gfx_v9_4_3_disable_gpa_mode |-- arc-allyesconfig | |-- drivers-base-regmap-regcache-maple.c:warning:lower_index-is-used-uninitialized | |-- drivers-base-regmap-regcache-maple.c:warning:lower_last-is-used-uninitialized | |-- drivers-gpu-drm-amd-amdgpu-amdgpu_gfx.c:warning:variable-j-set-but-not-used | `-- drivers-gpu-drm-amd-amdgpu-gfx_v9_4_3.c:warning:no-previous-prototype-for-gfx_v9_4_3_disable_gpa_mode |-- arc-randconfig-r043-20230424 | |-- drivers-gpu-drm-amd-amdgpu-amdgpu_gfx.c:warning:variable-j-set-but-not-used | `-- drivers-gpu-drm-amd-amdgpu-gfx_v9_4_3.c:warning:no-previous-prototype-for-gfx_v9_4_3_disable_gpa_mode |-- arm-allmodconfig | |-- drivers-gpu-drm-amd-amdgpu-amdgpu_gfx.c:warning:variable-j-set-but-not-used | `-- drivers-gpu-drm-amd-amdgpu-gfx_v9_4_3.c:warning:no-previous-prototype-for-gfx_v9_4_3_disable_gpa_mode |-- arm-allyesconfig | |-- drivers-gpu-drm-amd-amdgpu-amdgpu_gfx.c:warning:variable-j-set-but-not-used | `-- drivers-gpu-drm-amd-amdgpu-gfx_v9_4_3.c:warning:no-previous-prototype-for-gfx_v9_4_3_disable_gpa_mode |-- arm64-allyesconfig | |-- drivers-gpu-drm-amd-amdgpu-amdgpu_gfx.c:warning:variable-j-set-but-not-used | `-- drivers-gpu-drm-amd-amdgpu-gfx_v9_4_3.c:warning:no-previous-prototype-for-gfx_v9_4_3_disable_gpa_mode |-- arm64-buildonly-randconfig-r001-20230423 | |-- drivers-gpu-drm-amd-amdgpu-amdgpu_gfx.c:warning:variable-j-set-but-not-used | `-- drivers-gpu-drm-amd-amdgpu-gfx_v9_4_3.c:warning:no-previous-prototype-for-gfx_v9_4_3_disable_gpa_mode |-- i386-allyesconfig | |-- drivers-gpu-drm-amd-amdgpu-amdgpu_gfx.c:warning:variable-j-set-but-not-used | `-- drivers-gpu-drm-amd-amdgpu-gfx_v9_4_3.c:warning:no-previous-prototype-for-gfx_v9_4_3_disable_gpa_mode |-- i386-randconfig-a011-20230424 | `-- fs-ext4-super.c:warning:unused-variable-i |-- i386-randconfig-a016-20230424 | `-- fs-ext4-super.c:warning:unused-variable-i |-- i386-randconfig-
Re: [PATCH v8 5/5] MAINTAINERS: Add maintainer for RZ DU drivers
Hi Biju, Thank you for the patch. On Mon, Apr 24, 2023 at 05:10:24PM +0100, Biju Das wrote: > Add my self as maintainer for RZ DU drivers. > While at it, update the entries for rcar-du and shmobile. > > Signed-off-by: Biju Das Reviewed-by: Laurent Pinchart > --- > v8: > * New patch > --- > MAINTAINERS | 13 +++-- > 1 file changed, 11 insertions(+), 2 deletions(-) > > diff --git a/MAINTAINERS b/MAINTAINERS > index 1218a2ec6d97..42db5be4482c 100644 > --- a/MAINTAINERS > +++ b/MAINTAINERS > @@ -6948,7 +6948,7 @@ F: drivers/gpu/host1x/ > F: include/linux/host1x.h > F: include/uapi/drm/tegra_drm.h > > -DRM DRIVERS FOR RENESAS > +DRM DRIVERS FOR RENESAS RCAR AND SHMOBILE > M: Laurent Pinchart > M: Kieran Bingham > L: dri-devel@lists.freedesktop.org > @@ -6959,9 +6959,18 @@ F: > Documentation/devicetree/bindings/display/bridge/renesas,dsi-csi2-tx.yaml > F: Documentation/devicetree/bindings/display/bridge/renesas,dw-hdmi.yaml > F: Documentation/devicetree/bindings/display/bridge/renesas,lvds.yaml > F: Documentation/devicetree/bindings/display/renesas,du.yaml > -F: drivers/gpu/drm/renesas/ > +F: drivers/gpu/drm/renesas/rcar-du/ > +F: drivers/gpu/drm/renesas/shmobile/ > F: include/linux/platform_data/shmob_drm.h > > +DRM DRIVERS FOR RENESAS RZ > +M: Biju Das > +L: dri-devel@lists.freedesktop.org > +L: linux-renesas-...@vger.kernel.org > +S: Maintained > +F: Documentation/devicetree/bindings/display/renesas,rzg2l-du.yaml > +F: drivers/gpu/drm/renesas/rz-du/ > + > DRM DRIVERS FOR ROCKCHIP > M: Sandy Huang > M: Heiko Stübner -- Regards, Laurent Pinchart
Re: [PATCH v8 3/5] dt-bindings: display: renesas,rzg2l-du: Document RZ/V2L DU bindings
Hi Biju,
Thank you for the patch.
On Mon, Apr 24, 2023 at 05:10:22PM +0100, Biju Das wrote:
> Document DU found in RZ/V2L SoC. The DU block is identical to RZ/G2L
> SoC and therefore use RZ/G2L fallback to avoid any driver changes.
>
> Signed-off-by: Biju Das
> Reviewed-by: Rob Herring
Reviewed-by: Laurent Pinchart
> ---
> v7->v8:
> * Fixed the typo vsp2->du
> * Added Rb tag from Rob as the change is trivial.
> v7:
> * New patch.
> ---
> .../devicetree/bindings/display/renesas,rzg2l-du.yaml| 9 +++--
> 1 file changed, 7 insertions(+), 2 deletions(-)
>
> diff --git a/Documentation/devicetree/bindings/display/renesas,rzg2l-du.yaml
> b/Documentation/devicetree/bindings/display/renesas,rzg2l-du.yaml
> index ab99e7d57a7d..98686ea84d53 100644
> --- a/Documentation/devicetree/bindings/display/renesas,rzg2l-du.yaml
> +++ b/Documentation/devicetree/bindings/display/renesas,rzg2l-du.yaml
> @@ -16,8 +16,13 @@ description: |
>
> properties:
>compatible:
> -enum:
> - - renesas,r9a07g044-du # RZ/G2{L,LC}
> +oneOf:
> + - enum:
> + - renesas,r9a07g044-du # RZ/G2{L,LC}
> + - items:
> + - enum:
> + - renesas,r9a07g054-du# RZ/V2L
> + - const: renesas,r9a07g044-du # RZ/G2L fallback
>
>reg:
> maxItems: 1
--
Regards,
Laurent Pinchart
Re: [PATCH v8 2/5] dt-bindings: display: Document Renesas RZ/G2L DU bindings
Hi Biju,
Thank you for the patch.
On Mon, Apr 24, 2023 at 05:10:21PM +0100, Biju Das wrote:
> The RZ/G2L LCD controller is composed of Frame Compression Processor
> (FCPVD), Video Signal Processor (VSPD), and Display Unit (DU).
>
> The DU module supports the following hardware features
> − Display Parallel Interface (DPI) and MIPI LINK Video Interface
> − Display timing master
> − Generates video timings
> − Selecting the polarity of output DCLK, HSYNC, VSYNC, and DE
> − Supports Progressive
> − Input data format (from VSPD): RGB888, RGB666
> − Output data format: same as Input data format
> − Supporting Full HD (1920 pixels x 1080 lines) for MIPI-DSI Output
> − Supporting WXGA (1280 pixels x 800 lines) for Parallel Output
>
> This patch document DU module found on RZ/G2L LCDC.
>
> Signed-off-by: Biju Das
> Reviewed-by: Rob Herring
> ---
> v7->v8:
> * No change
> v6->v7:
> * No change
> v5->v6:
> * No change.
> v4->v5:
> * Added Rb tag from Rob.
> v3->v4:
> * Changed compatible name from renesas,du-r9a07g044->renesas,r9a07g044-du
> * started using same compatible for RZ/G2{L,LC}
> v3: New patch
> ---
> .../bindings/display/renesas,rzg2l-du.yaml| 124 ++
> 1 file changed, 124 insertions(+)
> create mode 100644
> Documentation/devicetree/bindings/display/renesas,rzg2l-du.yaml
>
> diff --git a/Documentation/devicetree/bindings/display/renesas,rzg2l-du.yaml
> b/Documentation/devicetree/bindings/display/renesas,rzg2l-du.yaml
> new file mode 100644
> index ..ab99e7d57a7d
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/display/renesas,rzg2l-du.yaml
> @@ -0,0 +1,124 @@
> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/display/renesas,rzg2l-du.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: Renesas RZ/G2L Display Unit (DU)
> +
> +maintainers:
> + - Biju Das
> + - Laurent Pinchart
> +
> +description: |
> + These DT bindings describe the Display Unit embedded in the Renesas RZ/G2L
> + and RZ/V2L SoCs.
> +
> +properties:
> + compatible:
> +enum:
> + - renesas,r9a07g044-du # RZ/G2{L,LC}
> +
> + reg:
> +maxItems: 1
> +
> + interrupts:
> +maxItems: 1
> +
> + clocks:
> +items:
> + - description: Main clock
> + - description: Register access clock
> + - description: Video clock
> +
> + clock-names:
> +items:
> + - const: aclk
> + - const: pclk
> + - const: vclk
> +
> + resets:
> +maxItems: 1
> +
> + power-domains:
> +maxItems: 1
> +
> + ports:
> +$ref: /schemas/graph.yaml#/properties/ports
> +description: |
> + The connections to the DU output video ports are modeled using the OF
> + graph bindings specified in
> Documentation/devicetree/bindings/graph.txt.
> + The number of ports and their assignment are model-dependent. Each port
> + shall have a single endpoint.
Are there SoCs using this DU that have different ports than the
r9a07g044-du (and that you can mention publicly :-)) ? If not, I'd drop
"The number of ports ... model-dependent", and list the ports
explicitly:
properties:
port@0:
$ref: /schemas/graph.yaml#/properties/port
description: DSI output port
unevaluatedProperties: false
port@1:
$ref: /schemas/graph.yaml#/properties/port
description: DPI output port
unevaluatedProperties: false
The alternative is to specify this in compatible-specific schema rules
like in renesas,du.yaml, which is more complicated.
I'm also wondering, are there really two output ports ? Or does the DU
have a single output, whose signals are output on the parallel interface
and also connected to the DSI encoder ?
> +
> +patternProperties:
> + "^port@[0-1]$":
> +$ref: /schemas/graph.yaml#/properties/port
> +unevaluatedProperties: false
> +
> +required:
> + - port@0
> +
> +unevaluatedProperties: false
> +
> + renesas,vsps:
> +$ref: "/schemas/types.yaml#/definitions/phandle-array"
> +items:
> + items:
> +- description: phandle to VSP instance that serves the DU channel
> +- description: Channel index identifying the LIF instance in that VSP
> +description:
> + A list of phandle and channel index tuples to the VSPs that handle the
> + memory interfaces for the DU channels.
> +
> +required:
> + - compatible
> + - reg
> + - interrupts
> + - clocks
> + - clock-names
> + - resets
> + - power-domains
> + - ports
> + - renesas,vsps
> +
> +additionalProperties: false
> +
> +examples:
> + # RZ/G2L DU
> + - |
> +#include
> +#include
> +
> +display@1089 {
> +compatible = "renesas,r9a07g044-du";
> +reg = <0x1089 0x1>;
> +interrupts = ;
> +clocks = <&cpg CPG_MOD R9A07G044_LCDC_CLK_A>,
> + <&cpg CPG_MOD R9A07G044_LCDC_CLK_P>,
> + <&cpg CPG_MOD R9A
[RESEND PATCH] drm/qxl: prevent memory leak
The allocated memory for qdev->dumb_heads should be released in qxl_destroy_monitors_object before qxl suspend. otherwise,qxl_create_monitors_object will be called to reallocate memory for qdev->dumb_heads after qxl resume, it will cause memory leak. Signed-off-by: Zongmin Zhou --- drivers/gpu/drm/qxl/qxl_display.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/drivers/gpu/drm/qxl/qxl_display.c b/drivers/gpu/drm/qxl/qxl_display.c index 6492a70e3c39..404b0483bb7c 100644 --- a/drivers/gpu/drm/qxl/qxl_display.c +++ b/drivers/gpu/drm/qxl/qxl_display.c @@ -1229,6 +1229,9 @@ int qxl_destroy_monitors_object(struct qxl_device *qdev) if (!qdev->monitors_config_bo) return 0; + kfree(qdev->dumb_heads); + qdev->dumb_heads = NULL; + qdev->monitors_config = NULL; qdev->ram_header->monitors_config = 0; -- 2.34.1
Re: [PATCH 10/11] drm/msm/dpu: tweak lm pairings in msm8998 hw catalog
On 4/19/2023 7:41 AM, Arnaud Vrac wrote: Change lm blocks pairs so that lm blocks with the same features are paired together: LM_0 and LM_1 with PP and DSPP LM_2 and LM_5 with PP LM_3 and LM_4 This matches the sdm845 configuration and allows using pp or dspp when 2 lm blocks are needed in the topology. In the previous config the reservation code could never find an lm pair without a matching feature set. Signed-off-by: Arnaud Vrac Reviewed-by: Abhinav Kumar
Re: [PATCH v2 00/17] drm/msm/dpu: Implement tearcheck support on INTF block
On 4/17/2023 1:21 PM, Marijn Suijten wrote:
Since DPU 5.0.0 the TEARCHECK registers and interrupts moved out of the
PINGPONG block and into the INTF. Implement the necessary callbacks in
the INTF block, and use these callbacks together with the INTF_TEAR
interrupts. Additionally, disable previous register writes and remove
unused interrupts in the PINGPONG and MDP_TOP blocks for these newer
platforms.
With these patches the devices on DPU >= 5.0.0 listed below now update
their panels at 60fps without tearing (nor sluggishness), and without
repeated timeouts in dmesg.
Tested on the following devices with command-mode panels and TE pins:
- Sony Xperia XZ3 (sdm845, DPU 4.0.0, cmdmode panel): no regressions on
PINGPONG TE;
- Sony Xperia 5 (sm8150, DPU 5.0.0);
- Sony Xperia 10 II (sm6125, DPU 5.0.4).
---
I will pickup the fixes from this one and for the rest, since jessica
has been rebasing the DSC 1.2 over DSI on top of this series since the
RFC stage, will let her review and test this out and we can pick up the
rest for 6.5
So please keep her CCed on the next revisions of this if there are more.
Changes in v2:
- Rebase on -next with all the new SC8280XP and SM8[345]50 support;
- Remove duplicate PP_BLK_TE macro now that .features is an argument;
- Fix PP_BLK_DIPHER -> DITHER typo that was added recently;
- Add INTF_TEAR interrupt blocks for DPU 7.0.0 (moved to different
register range);
- Describe INTF_TEAR support for the newly added SM8350, SM8450,
SM8550 and SC8280XP SoCs;
- Remove TE2 subblocks from 8[34]50 and sc8280xp (new patch);
- Rebase on -next with DPU catalog rework;
- Remove dpu_hw_intf_v1_get_status which was inlined in the original
dpu_hw_intf_get_status function in e3969eadc8ee ("drm/msm/disp/dpu:
get timing engine status from intf status register");
- Many changes to move all catalog edits to separate files;
- Add documentation for DPU_MDP_VSYNC_SEL;
- Fix sdm8150_mdp typo, should be sm8150_mdp;
- Move unrelated INTF_INTR offsets out of hwio header (new patch);
- Remove _reg argument from INTF_BLK, since we now have a third
interrupt with a different base register. To prevent confusion all
three interrupts should provide the final value from DPU_IRQ_IDX
directly.
- Only request the new tear_rd_ptr in a new INTF_BLK_DSI_TE macro;
- Drop stray INTF_MISR_SIGNATURE register definition;
- Clean up registers in dpu_hw_intf.c (many new patches);
- merged setup_tearcheck() and enable_tearcheck() callbacks;
- replaced enable_tearcheck(false) with new disable_tearcheck()
callback;
- Moved dpu_encoder_phys_cmd_enable_te intestines (just autorefresh
disablement) to INTF and PP block, replacing 3 callbacks in both
blocks with just a single disable_autorefresh() callback.
v1:
https://lore.kernel.org/r/20221231215006.211860-1-marijn.suij...@somainline.org
---
Konrad Dybcio (1):
drm/msm/dpu: Move dpu_hw_{tear_check,pp_vsync_info} to dpu_hw_mdss.h
Marijn Suijten (16):
drm/msm/dpu: Remove unused INTF0 interrupt mask from SM6115/QCM2290
drm/msm/dpu: Remove TE2 block and feature from DPU >= 7.0.0 hardware
drm/msm/dpu: Move non-MDP_TOP INTF_INTR offsets out of hwio header
drm/msm/dpu: Fix PP_BLK_DIPHER -> DITHER typo
drm/msm/dpu: Remove duplicate register defines from INTF
drm/msm/dpu: Remove extraneous register define indentation
drm/msm/dpu: Sort INTF registers numerically
drm/msm/dpu: Drop unused poll_timeout_wr_ptr PINGPONG callback
drm/msm/dpu: Move autorefresh disable from CMD encoder to pingpong
drm/msm/dpu: Disable pingpong TE on DPU 5.0.0 and above
drm/msm/dpu: Disable MDP vsync source selection on DPU 5.0.0 and above
drm/msm/dpu: Factor out shared interrupt register in INTF_BLK macro
drm/msm/dpu: Document and enable TEAR interrupts on DSI interfaces
drm/msm/dpu: Merge setup_- and enable_tearcheck pingpong callbacks
drm/msm/dpu: Implement tearcheck support on INTF block
drm/msm/dpu: Remove intr_rdptr from DPU >= 5.0.0 pingpong config
.../drm/msm/disp/dpu1/catalog/dpu_3_0_msm8998.h| 26 +-
.../gpu/drm/msm/disp/dpu1/catalog/dpu_4_0_sdm845.h | 26 +-
.../gpu/drm/msm/disp/dpu1/catalog/dpu_5_0_sm8150.h | 40 +--
.../drm/msm/disp/dpu1/catalog/dpu_5_1_sc8180x.h| 48 ++--
.../gpu/drm/msm/disp/dpu1/catalog/dpu_6_0_sm8250.h | 40 +--
.../gpu/drm/msm/disp/dpu1/catalog/dpu_6_2_sc7180.h | 16 +-
.../gpu/drm/msm/disp/dpu1/catalog/dpu_6_3_sm6115.h | 15 +-
.../drm/msm/disp/dpu1/catalog/dpu_6_5_qcm2290.h| 15 +-
.../gpu/drm/msm/disp/dpu1/catalog/dpu_7_0_sm8350.h | 40 +--
.../gpu/drm/msm/disp/dpu1/catalog/dpu_7_2_sc7280.h | 22 +-
.../drm/msm/disp/dpu1/catalog/dpu_8_0_sc8280xp.h | 64 +++--
.../gpu/drm/msm/disp/dpu1/catalog/dpu_8_1_sm8450.h | 46 ++--
.../gpu/drm/msm/disp/dpu1/catalog/dpu_9_0_sm8550.h | 36 ++-
drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c| 11 +
driv
Re: [PATCH v2 06/17] drm/msm/dpu: Remove extraneous register define indentation
On 4/17/2023 1:21 PM, Marijn Suijten wrote: A bunch of registers are indented with two extra spaces, looking as if these are values corresponding to the previous register which is not the case, rather these are simply also register offsets and should only have a single space separating them and the #define keyword. Signed-off-by: Marijn Suijten --- Reviewed-by: Abhinav Kumar
Re: [PATCH v2 05/17] drm/msm/dpu: Remove duplicate register defines from INTF
On 4/17/2023 1:21 PM, Marijn Suijten wrote:
The INTF_FRAME_LINE_COUNT_EN, INTF_FRAME_COUNT and INTF_LINE_COUNT
registers are already defined higher up, in the right place when sorted
numerically.
Fixes: 25fdd5933e4c ("drm/msm: Add SDM845 DPU support")
Signed-off-by: Marijn Suijten
---
Reviewed-by: Abhinav Kumar
Re: [PATCH v2 03/17] drm/msm/dpu: Move non-MDP_TOP INTF_INTR offsets out of hwio header
On 4/24/2023 3:25 PM, Marijn Suijten wrote:
On 2023-04-24 13:44:55, Abhinav Kumar wrote:
On 4/17/2023 1:21 PM, Marijn Suijten wrote:
These offsets do not fall under the MDP TOP block and do not fit the
comment right above. Move them to dpu_hw_interrupts.c next to the
repsective MDP_INTF_x_OFF interrupt block offsets.
Fixes: 25fdd5933e4c ("drm/msm: Add SDM845 DPU support")
Signed-off-by: Marijn Suijten
This change itself is fine, hence
Reviewed-by: Abhinav Kumar
One comment below.
---
drivers/gpu/drm/msm/disp/dpu1/dpu_hw_interrupts.c | 5 -
drivers/gpu/drm/msm/disp/dpu1/dpu_hwio.h | 3 ---
2 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_interrupts.c
b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_interrupts.c
index 53326f25e40e..85c0bda3ff90 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_interrupts.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_interrupts.c
@@ -15,7 +15,7 @@
/*
* Register offsets in MDSS register file for the interrupt registers
- * w.r.t. to the MDP base
+ * w.r.t. the MDP base
*/
#define MDP_SSPP_TOP0_OFF0x0
#define MDP_INTF_0_OFF 0x6A000
@@ -24,6 +24,9 @@
#define MDP_INTF_3_OFF 0x6B800
#define MDP_INTF_4_OFF 0x6C000
#define MDP_INTF_5_OFF 0x6C800
+#define INTF_INTR_EN 0x1c0
+#define INTF_INTR_STATUS 0x1c4
+#define INTF_INTR_CLEAR0x1c8
#define MDP_AD4_0_OFF0x7C000
#define MDP_AD4_1_OFF0x7D000
#define MDP_AD4_INTR_EN_OFF 0x41c
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_hwio.h
b/drivers/gpu/drm/msm/disp/dpu1/dpu_hwio.h
index feb9a729844a..5acd5683d25a 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_hwio.h
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_hwio.h
@@ -21,9 +21,6 @@
#define HIST_INTR_EN0x01c
#define HIST_INTR_STATUS0x020
#define HIST_INTR_CLEAR 0x024
Even HIST_INTR_*** need to be moved then.
These are relative to MDP_SSPP_TOP0_OFF too just like
INTR(2)_{CLEAR,EN,STATUS} so I left them here. Otherwise, *all* these
interrupt masks are probably best moved to dpu_hw_interrupts.c for
clarity, as that's also the only place they are used?
Let me know which way you prefer.
- Marijn
Ah okay, understood, this is fine then.
-#define INTF_INTR_EN0x1C0
-#define INTF_INTR_STATUS0x1C4
-#define INTF_INTR_CLEAR 0x1C8
#define SPLIT_DISPLAY_EN0x2F4
#define SPLIT_DISPLAY_UPPER_PIPE_CTRL 0x2F8
#define DSPP_IGC_COLOR0_RAM_LUTN0x300
Re: [PATCH v2 3/3] drm/msm/dpu: Pass catalog pointers directly from RM instead of IDs
On 4/24/2023 3:54 PM, Dmitry Baryshkov wrote:
On Tue, 25 Apr 2023 at 01:03, Marijn Suijten
wrote:
On 2023-04-21 16:25:15, Abhinav Kumar wrote:
On 4/21/2023 1:53 PM, Marijn Suijten wrote:
The Resource Manager already iterates over all available blocks from the
catalog, only to pass their ID to a dpu_hw_xxx_init() function which
uses an _xxx_offset() helper to search for and find the exact same
catalog pointer again to initialize the block with, fallible error
handling and all.
Instead, pass const pointers to the catalog entries directly to these
_init functions and drop the for loops entirely, saving on both
readability complexity and unnecessary cycles at boot.
Signed-off-by: Marijn Suijten
Reviewed-by: Dmitry Baryshkov
Overall, a nice cleanup!
One comment below.
---
drivers/gpu/drm/msm/disp/dpu1/dpu_hw_ctl.c| 37 +
drivers/gpu/drm/msm/disp/dpu1/dpu_hw_ctl.h| 14
drivers/gpu/drm/msm/disp/dpu1/dpu_hw_dsc.c| 32 +++---
drivers/gpu/drm/msm/disp/dpu1/dpu_hw_dsc.h| 11 +++
drivers/gpu/drm/msm/disp/dpu1/dpu_hw_dspp.c | 38 -
drivers/gpu/drm/msm/disp/dpu1/dpu_hw_dspp.h | 12 +++
drivers/gpu/drm/msm/disp/dpu1/dpu_hw_interrupts.h | 2 +-
drivers/gpu/drm/msm/disp/dpu1/dpu_hw_intf.c | 40
++-
drivers/gpu/drm/msm/disp/dpu1/dpu_hw_intf.h | 12 +++
drivers/gpu/drm/msm/disp/dpu1/dpu_hw_lm.c | 38 -
drivers/gpu/drm/msm/disp/dpu1/dpu_hw_lm.h | 10 +++---
drivers/gpu/drm/msm/disp/dpu1/dpu_hw_merge3d.c| 33 +++
drivers/gpu/drm/msm/disp/dpu1/dpu_hw_merge3d.h| 14
drivers/gpu/drm/msm/disp/dpu1/dpu_hw_pingpong.c | 33 +++
drivers/gpu/drm/msm/disp/dpu1/dpu_hw_pingpong.h | 14
drivers/gpu/drm/msm/disp/dpu1/dpu_hw_sspp.c | 39 --
drivers/gpu/drm/msm/disp/dpu1/dpu_hw_sspp.h | 12 +++
drivers/gpu/drm/msm/disp/dpu1/dpu_hw_vbif.c | 33 +++
drivers/gpu/drm/msm/disp/dpu1/dpu_hw_vbif.h | 11 +++
drivers/gpu/drm/msm/disp/dpu1/dpu_hw_wb.c | 33 ---
drivers/gpu/drm/msm/disp/dpu1/dpu_hw_wb.h | 11 +++
drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c | 17 +-
drivers/gpu/drm/msm/disp/dpu1/dpu_rm.c| 18 +-
23 files changed, 139 insertions(+), 375 deletions(-)
-struct dpu_hw_intf *dpu_hw_intf_init(enum dpu_intf idx,
- void __iomem *addr,
- const struct dpu_mdss_cfg *m)
+struct dpu_hw_intf *dpu_hw_intf_init(const struct dpu_intf_cfg *cfg,
+ void __iomem *addr)
{
struct dpu_hw_intf *c;
- const struct dpu_intf_cfg *cfg;
+
+ if (cfg->type == INTF_NONE) {
+ pr_err("Cannot create interface hw object for INTF_NONE type\n");
+ return ERR_PTR(-EINVAL);
+ }
The caller of dpu_hw_intf_init which is the RM already has protection
for INTF_NONE, see below
for (i = 0; i < cat->intf_count; i++) {
struct dpu_hw_intf *hw;
const struct dpu_intf_cfg *intf = &cat->intf[i];
if (intf->type == INTF_NONE) {
DPU_DEBUG("skip intf %d with type none\n", i);
continue;
}
if (intf->id < INTF_0 || intf->id >= INTF_MAX) {
DPU_ERROR("skip intf %d with invalid id\n",
intf->id);
continue;
}
hw = dpu_hw_intf_init(intf->id, mmio, cat);
So this part can be dropped.
I mainly intended to keep original validation where _intf_offset would
skip INTF_NONE, and error out. RM init is hence expected to filter out
INTF_NONE instead of running into that `-EINVAL`, which I maintained
here.
If you think there won't be another caller of dpu_hw_intf_init, and that
such validation is hence excessive, I can remove it in a followup v3.
I'd prefer to see the checks at dpu_rm to be dropped.
dpu_hw_intf_init() (and other dpu_hw_foo_init() functions) should be
self-contained. If they can not init HW block (e.g. because the index
is out of the boundaries), they should return an error.
They already do that today because even without this it will call into
_intf_offset() and that will bail out for INTF_NONE.
I feel this is a duplicated check because the caller with the loop needs
to validate the index before passing it to dpu_hw_intf_init() otherwise
the loop will get broken at the first return of the error and rest of
the blocks will also not be initialized.
- Marijn
c = kzalloc(sizeof(*c), GFP_KERNEL);
if (!c)
return ERR_PTR(-ENOMEM);
- cfg = _intf_offset(idx, m, addr, &c->hw);
- if (IS_ERR_OR_NULL(cfg)) {
- kfree(c);
- pr_err("failed to create dpu_hw_intf %d\n", idx);
- retur
Re: [Freedreno] [PATCH v2 04/17] drm/msm/dpu: Fix PP_BLK_DIPHER -> DITHER typo
On 4/24/2023 3:30 PM, Marijn Suijten wrote:
On 2023-04-24 13:53:13, Abhinav Kumar wrote:
On 4/17/2023 1:21 PM, Marijn Suijten wrote:
SM8550 only comes with a DITHER subblock inside the PINGPONG block,
hence the name and a block length of zero. However, the PP_BLK macro
name was typo'd to DIPHER rather than DITHER.
Fixes: efcd0107727c ("drm/msm/dpu: add support for SM8550")
Signed-off-by: Marijn Suijten
This change itself is fine, hence
Reviewed-by: Abhinav Kumar
one comment below
---
drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_9_0_sm8550.h | 16
drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c | 2 +-
2 files changed, 9 insertions(+), 9 deletions(-)
diff --git a/drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_9_0_sm8550.h
b/drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_9_0_sm8550.h
index 9e403034093f..d0ab351b6a8b 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_9_0_sm8550.h
+++ b/drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_9_0_sm8550.h
@@ -132,28 +132,28 @@ static const struct dpu_dspp_cfg sm8550_dspp[] = {
&sm8150_dspp_sblk),
};
static const struct dpu_pingpong_cfg sm8550_pp[] = {
dither block should be present on many other chipsets too but looks like
on sm8550 was enabling it. Not sure how it was validated there. But we
are enabling dither, even other chipsets have this block.
Correct, they all seem to have it starting at sdm845. My patch message
seems to lack the word "exclusively" as the PP on sm8550 appears to
exclusively contain a DITHER subblock (unless other blocks are available
that simply aren't supported within this driver yet) and no other
registers. Hence this aptly named macro exist to emit just the feature
bitflag for that and a .len of zero.
I think after the TE blocks were moved to INTF, dither is the only
sub-block for all Ping-Pongs not just in sm8550.
Now, whether we should have the features contain subblock flags rather
than just scanning for their id's or presence in the subblocks is a
different discussion / cleanup we should have.
Yes, separate patch and hence I gave R-b on this one. But had to leave
this comment to not lose context.
- Marijn
- PP_BLK_DIPHER("pingpong_0", PINGPONG_0, 0x69000, MERGE_3D_0,
sc7280_pp_sblk,
+ PP_BLK_DITHER("pingpong_0", PINGPONG_0, 0x69000, MERGE_3D_0,
sc7280_pp_sblk,
DPU_IRQ_IDX(MDP_SSPP_TOP0_INTR, 8),
-1),
- PP_BLK_DIPHER("pingpong_1", PINGPONG_1, 0x6a000, MERGE_3D_0,
sc7280_pp_sblk,
+ PP_BLK_DITHER("pingpong_1", PINGPONG_1, 0x6a000, MERGE_3D_0,
sc7280_pp_sblk,
DPU_IRQ_IDX(MDP_SSPP_TOP0_INTR, 9),
-1),
- PP_BLK_DIPHER("pingpong_2", PINGPONG_2, 0x6b000, MERGE_3D_1,
sc7280_pp_sblk,
+ PP_BLK_DITHER("pingpong_2", PINGPONG_2, 0x6b000, MERGE_3D_1,
sc7280_pp_sblk,
DPU_IRQ_IDX(MDP_SSPP_TOP0_INTR, 10),
-1),
- PP_BLK_DIPHER("pingpong_3", PINGPONG_3, 0x6c000, MERGE_3D_1,
sc7280_pp_sblk,
+ PP_BLK_DITHER("pingpong_3", PINGPONG_3, 0x6c000, MERGE_3D_1,
sc7280_pp_sblk,
DPU_IRQ_IDX(MDP_SSPP_TOP0_INTR, 11),
-1),
- PP_BLK_DIPHER("pingpong_4", PINGPONG_4, 0x6d000, MERGE_3D_2,
sc7280_pp_sblk,
+ PP_BLK_DITHER("pingpong_4", PINGPONG_4, 0x6d000, MERGE_3D_2,
sc7280_pp_sblk,
DPU_IRQ_IDX(MDP_SSPP_TOP0_INTR2, 30),
-1),
- PP_BLK_DIPHER("pingpong_5", PINGPONG_5, 0x6e000, MERGE_3D_2,
sc7280_pp_sblk,
+ PP_BLK_DITHER("pingpong_5", PINGPONG_5, 0x6e000, MERGE_3D_2,
sc7280_pp_sblk,
DPU_IRQ_IDX(MDP_SSPP_TOP0_INTR2, 31),
-1),
- PP_BLK_DIPHER("pingpong_6", PINGPONG_6, 0x66000, MERGE_3D_3,
sc7280_pp_sblk,
+ PP_BLK_DITHER("pingpong_6", PINGPONG_6, 0x66000, MERGE_3D_3,
sc7280_pp_sblk,
-1,
-1),
- PP_BLK_DIPHER("pingpong_7", PINGPONG_7, 0x66400, MERGE_3D_3,
sc7280_pp_sblk,
+ PP_BLK_DITHER("pingpong_7", PINGPONG_7, 0x66400, MERGE_3D_3,
sc7280_pp_sblk,
-1,
-1),
};
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 03f162af1a50..ca8a02debda9 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c
@@ -491,7 +491,7 @@ static const struct dpu_pingpong_sub_blks sc7280_pp_sblk = {
.len = 0x20, .version = 0x2},
};
-#define PP_BLK_DIPHER(_name, _id, _base, _merge_3d, _sblk, _done, _rdptr) \
+#define PP_BLK_DITHER(_name, _id, _base, _merge_3d, _sblk, _done, _rdptr) \
{\
.name = _name, .id = _id, \
.base = _base, .len = 0, \
Re: [PATCH] modules/firmware: add a new option to denote a firmware group to choose one.
On Mon, Apr 24, 2023 at 10:01:13AM -0700, Lucas De Marchi wrote:
> On Mon, Apr 24, 2023 at 03:44:18PM +1000, Dave Airlie wrote:
> > On Fri, 21 Apr 2023 at 05:09, Lucas De Marchi
> > wrote:
> > >
> > > On Wed, Apr 19, 2023 at 02:36:52PM +1000, Dave Airlie wrote:
> > > >From: Dave Airlie
> > > >
> > > >This adds a tag that will go into the module info, only one firmware from
> > > >the group given needs to be available for this driver to work. This
> > > >allows
> > > >dracut to avoid adding in firmware that aren't needed.
> > > >
> > > >This just brackets a module list in the modinfo, the modules in the list
> > > >will get entries in reversed order so the last module in the list is the
> > > >preferred one.
> > > >
> > > >The corresponding dracut code it at:
> > > >https://github.com/dracutdevs/dracut/pull/2309
> > >
> > > it would be good to have the example usage in the commit message here so
> > > it can be easily checked as reference for other drivers.
> >
> > Good point.
> >
> > >
> > > I don't think we ever had any ordering in modinfo being relevant for
> > > other things. Considering the use case and that we could also use a
> > > similar thing for i915 / xe modules wrt to the major version,
> > > couldn't we do something like below?
> > >
> > > MODULE_FIRMWARE_GROUP("nvidia/ga106/gsp/gsp");
> > > MODULE_FIRMWARE("nvidia/ga106/gsp/gsp-5258902.bin");
> > > MODULE_FIRMWARE("nvidia/ga106/gsp/gsp-5303002.bin");
> > >
> > > so the group is created by startswith() rather than by the order the
> > > modinfo appears in the elf section. In i915 we'd have:
> >
> > The way userspace parses these is reverse order, and it doesn't see
>
> the main issue I have with it is that it relies on a order that is
> implicit rather than intended. The order comes from how the .modinfo ELF
> section is assembled together... so the fact that your call to
> kmod_module_get_info() returns a list with the keys in the reverse order
> of the MODULE_FIRMWARE() definitions, is basically because the compiler
> toolchain did it did that way.
>
> It's worse when those sections come from different compilation units as
> the order then is not predictable and can easily break with changes to
> the build infra if the files are linked in different order.
>
> I think the grouping thing here would only be supported with firmware
> defined on the same compilation unit, but it's something to keep in mind
> and document.
I had provided a simple API to help with explicit linker order years ago:
https://git.kernel.org/pub/scm/linux/kernel/git/mcgrof/linux-next.git/log/?h=20170620-linker-tables-v8
Other than that you have to rely on the order in the Makefile or way
in which they are declared.
> > the GROUP until after the FIRMWARE, so this can't work, as it already
> > will have included all the ones below, hence why I bracketed top and
> > bottom with a group.
>
> well... that is something that can be adapted easily by using a 2 pass
> approach, filtering out the list based on the groups.
>
> I agree that yours is simpler though. If we can rely on the
> order produced by the compiler and we document the expectations of
> MODULE_FIRMWARE_GROUP_ONLY_ONE, then I believe we can stay with the
> simpler approach.
>
> Luis, any thoughts here?
I see the Dracut code indicates that the order says now that you should
put the preferred firmware last, and that seems to match most coding
conventions, ie, new firmwares likely get added last, so it's a nice
coincidence. Will this always work? I don't know. But if you like to
hedge, then this seems fine so long as I'm folks follow up to fix issues
later. I think it should and the simplicity is preferred, worth a shot
I think.
But the examples on both sides are pretty terrible. I'd just like to ask
all this gets extended in proper kdoc form and we are able to get users
and developers to read this under "Module support" in:
https://docs.kernel.org/core-api/kernel-api.html
So go to town with a new section for:
Documentation/core-api/kernel-api.rst
Luis
Re: [PATCH v2 3/3] drm/msm/dpu: Pass catalog pointers directly from RM instead of IDs
On Tue, 25 Apr 2023 at 01:03, Marijn Suijten
wrote:
>
> On 2023-04-21 16:25:15, Abhinav Kumar wrote:
> >
> >
> > On 4/21/2023 1:53 PM, Marijn Suijten wrote:
> > > The Resource Manager already iterates over all available blocks from the
> > > catalog, only to pass their ID to a dpu_hw_xxx_init() function which
> > > uses an _xxx_offset() helper to search for and find the exact same
> > > catalog pointer again to initialize the block with, fallible error
> > > handling and all.
> > >
> > > Instead, pass const pointers to the catalog entries directly to these
> > > _init functions and drop the for loops entirely, saving on both
> > > readability complexity and unnecessary cycles at boot.
> > >
> > > Signed-off-by: Marijn Suijten
> > > Reviewed-by: Dmitry Baryshkov
> >
> > Overall, a nice cleanup!
> >
> > One comment below.
> >
> > > ---
> > > drivers/gpu/drm/msm/disp/dpu1/dpu_hw_ctl.c| 37
> > > +
> > > drivers/gpu/drm/msm/disp/dpu1/dpu_hw_ctl.h| 14
> > > drivers/gpu/drm/msm/disp/dpu1/dpu_hw_dsc.c| 32
> > > +++---
> > > drivers/gpu/drm/msm/disp/dpu1/dpu_hw_dsc.h| 11 +++
> > > drivers/gpu/drm/msm/disp/dpu1/dpu_hw_dspp.c | 38
> > > -
> > > drivers/gpu/drm/msm/disp/dpu1/dpu_hw_dspp.h | 12 +++
> > > drivers/gpu/drm/msm/disp/dpu1/dpu_hw_interrupts.h | 2 +-
> > > drivers/gpu/drm/msm/disp/dpu1/dpu_hw_intf.c | 40
> > > ++-
> > > drivers/gpu/drm/msm/disp/dpu1/dpu_hw_intf.h | 12 +++
> > > drivers/gpu/drm/msm/disp/dpu1/dpu_hw_lm.c | 38
> > > -
> > > drivers/gpu/drm/msm/disp/dpu1/dpu_hw_lm.h | 10 +++---
> > > drivers/gpu/drm/msm/disp/dpu1/dpu_hw_merge3d.c| 33
> > > +++
> > > drivers/gpu/drm/msm/disp/dpu1/dpu_hw_merge3d.h| 14
> > > drivers/gpu/drm/msm/disp/dpu1/dpu_hw_pingpong.c | 33
> > > +++
> > > drivers/gpu/drm/msm/disp/dpu1/dpu_hw_pingpong.h | 14
> > > drivers/gpu/drm/msm/disp/dpu1/dpu_hw_sspp.c | 39
> > > --
> > > drivers/gpu/drm/msm/disp/dpu1/dpu_hw_sspp.h | 12 +++
> > > drivers/gpu/drm/msm/disp/dpu1/dpu_hw_vbif.c | 33
> > > +++
> > > drivers/gpu/drm/msm/disp/dpu1/dpu_hw_vbif.h | 11 +++
> > > drivers/gpu/drm/msm/disp/dpu1/dpu_hw_wb.c | 33
> > > ---
> > > drivers/gpu/drm/msm/disp/dpu1/dpu_hw_wb.h | 11 +++
> > > drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c | 17 +-
> > > drivers/gpu/drm/msm/disp/dpu1/dpu_rm.c| 18 +-
> > > 23 files changed, 139 insertions(+), 375 deletions(-)
> > >
> >
> >
> >
> > > -struct dpu_hw_intf *dpu_hw_intf_init(enum dpu_intf idx,
> > > - void __iomem *addr,
> > > - const struct dpu_mdss_cfg *m)
> > > +struct dpu_hw_intf *dpu_hw_intf_init(const struct dpu_intf_cfg *cfg,
> > > + void __iomem *addr)
> > > {
> > > struct dpu_hw_intf *c;
> > > - const struct dpu_intf_cfg *cfg;
> > > +
> > > + if (cfg->type == INTF_NONE) {
> > > + pr_err("Cannot create interface hw object for INTF_NONE
> > > type\n");
> > > + return ERR_PTR(-EINVAL);
> > > + }
> >
> > The caller of dpu_hw_intf_init which is the RM already has protection
> > for INTF_NONE, see below
> >
> > for (i = 0; i < cat->intf_count; i++) {
> > struct dpu_hw_intf *hw;
> > const struct dpu_intf_cfg *intf = &cat->intf[i];
> >
> > if (intf->type == INTF_NONE) {
> > DPU_DEBUG("skip intf %d with type none\n", i);
> > continue;
> > }
> > if (intf->id < INTF_0 || intf->id >= INTF_MAX) {
> > DPU_ERROR("skip intf %d with invalid id\n",
> > intf->id);
> > continue;
> > }
> > hw = dpu_hw_intf_init(intf->id, mmio, cat);
> >
> > So this part can be dropped.
>
> I mainly intended to keep original validation where _intf_offset would
> skip INTF_NONE, and error out. RM init is hence expected to filter out
> INTF_NONE instead of running into that `-EINVAL`, which I maintained
> here.
>
> If you think there won't be another caller of dpu_hw_intf_init, and that
> such validation is hence excessive, I can remove it in a followup v3.
I'd prefer to see the checks at dpu_rm to be dropped.
dpu_hw_intf_init() (and other dpu_hw_foo_init() functions) should be
self-contained. If they can not init HW block (e.g. because the index
is out of the boundaries), they should return an error.
>
> - Marijn
>
> > > c = kzalloc(sizeof(*c), GFP_KERNEL);
> > > if (!c)
> > > return ERR_PTR(-ENOMEM);
> > >
> > > - cfg = _intf_offset(idx, m, addr, &c->hw);
> > > - if (IS_ERR_OR_NULL(cfg)) {
> > > - kfree(c);
> > > - pr
Re: [Freedreno] [PATCH v2 04/17] drm/msm/dpu: Fix PP_BLK_DIPHER -> DITHER typo
On 2023-04-24 13:53:13, Abhinav Kumar wrote:
>
>
> On 4/17/2023 1:21 PM, Marijn Suijten wrote:
> > SM8550 only comes with a DITHER subblock inside the PINGPONG block,
> > hence the name and a block length of zero. However, the PP_BLK macro
> > name was typo'd to DIPHER rather than DITHER.
> >
> > Fixes: efcd0107727c ("drm/msm/dpu: add support for SM8550")
> > Signed-off-by: Marijn Suijten
>
> This change itself is fine, hence
>
> Reviewed-by: Abhinav Kumar
>
> one comment below
>
> > ---
> > drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_9_0_sm8550.h | 16
> >
> > drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c | 2 +-
> > 2 files changed, 9 insertions(+), 9 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_9_0_sm8550.h
> > b/drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_9_0_sm8550.h
> > index 9e403034093f..d0ab351b6a8b 100644
> > --- a/drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_9_0_sm8550.h
> > +++ b/drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_9_0_sm8550.h
> > @@ -132,28 +132,28 @@ static const struct dpu_dspp_cfg sm8550_dspp[] = {
> > &sm8150_dspp_sblk),
> > };
> > static const struct dpu_pingpong_cfg sm8550_pp[] = {
>
> dither block should be present on many other chipsets too but looks like
> on sm8550 was enabling it. Not sure how it was validated there. But we
> are enabling dither, even other chipsets have this block.
Correct, they all seem to have it starting at sdm845. My patch message
seems to lack the word "exclusively" as the PP on sm8550 appears to
exclusively contain a DITHER subblock (unless other blocks are available
that simply aren't supported within this driver yet) and no other
registers. Hence this aptly named macro exist to emit just the feature
bitflag for that and a .len of zero.
Now, whether we should have the features contain subblock flags rather
than just scanning for their id's or presence in the subblocks is a
different discussion / cleanup we should have.
- Marijn
> > - PP_BLK_DIPHER("pingpong_0", PINGPONG_0, 0x69000, MERGE_3D_0,
> > sc7280_pp_sblk,
> > + PP_BLK_DITHER("pingpong_0", PINGPONG_0, 0x69000, MERGE_3D_0,
> > sc7280_pp_sblk,
> > DPU_IRQ_IDX(MDP_SSPP_TOP0_INTR, 8),
> > -1),
> > - PP_BLK_DIPHER("pingpong_1", PINGPONG_1, 0x6a000, MERGE_3D_0,
> > sc7280_pp_sblk,
> > + PP_BLK_DITHER("pingpong_1", PINGPONG_1, 0x6a000, MERGE_3D_0,
> > sc7280_pp_sblk,
> > DPU_IRQ_IDX(MDP_SSPP_TOP0_INTR, 9),
> > -1),
> > - PP_BLK_DIPHER("pingpong_2", PINGPONG_2, 0x6b000, MERGE_3D_1,
> > sc7280_pp_sblk,
> > + PP_BLK_DITHER("pingpong_2", PINGPONG_2, 0x6b000, MERGE_3D_1,
> > sc7280_pp_sblk,
> > DPU_IRQ_IDX(MDP_SSPP_TOP0_INTR, 10),
> > -1),
> > - PP_BLK_DIPHER("pingpong_3", PINGPONG_3, 0x6c000, MERGE_3D_1,
> > sc7280_pp_sblk,
> > + PP_BLK_DITHER("pingpong_3", PINGPONG_3, 0x6c000, MERGE_3D_1,
> > sc7280_pp_sblk,
> > DPU_IRQ_IDX(MDP_SSPP_TOP0_INTR, 11),
> > -1),
> > - PP_BLK_DIPHER("pingpong_4", PINGPONG_4, 0x6d000, MERGE_3D_2,
> > sc7280_pp_sblk,
> > + PP_BLK_DITHER("pingpong_4", PINGPONG_4, 0x6d000, MERGE_3D_2,
> > sc7280_pp_sblk,
> > DPU_IRQ_IDX(MDP_SSPP_TOP0_INTR2, 30),
> > -1),
> > - PP_BLK_DIPHER("pingpong_5", PINGPONG_5, 0x6e000, MERGE_3D_2,
> > sc7280_pp_sblk,
> > + PP_BLK_DITHER("pingpong_5", PINGPONG_5, 0x6e000, MERGE_3D_2,
> > sc7280_pp_sblk,
> > DPU_IRQ_IDX(MDP_SSPP_TOP0_INTR2, 31),
> > -1),
> > - PP_BLK_DIPHER("pingpong_6", PINGPONG_6, 0x66000, MERGE_3D_3,
> > sc7280_pp_sblk,
> > + PP_BLK_DITHER("pingpong_6", PINGPONG_6, 0x66000, MERGE_3D_3,
> > sc7280_pp_sblk,
> > -1,
> > -1),
> > - PP_BLK_DIPHER("pingpong_7", PINGPONG_7, 0x66400, MERGE_3D_3,
> > sc7280_pp_sblk,
> > + PP_BLK_DITHER("pingpong_7", PINGPONG_7, 0x66400, MERGE_3D_3,
> > sc7280_pp_sblk,
> > -1,
> > -1),
> > };
> > 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 03f162af1a50..ca8a02debda9 100644
> > --- a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c
> > +++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c
> > @@ -491,7 +491,7 @@ static const struct dpu_pingpong_sub_blks
> > sc7280_pp_sblk = {
> > .len = 0x20, .version = 0x2},
> > };
> >
> > -#define PP_BLK_DIPHER(_name, _id, _base, _merge_3d, _sblk, _done, _rdptr) \
> > +#define PP_BLK_DITHER(_name, _id, _base, _merge_3d, _sblk, _done, _rdptr) \
> > {\
> > .name = _name, .id = _id, \
> > .base = _base, .len = 0, \
> >
Re: [PATCH v5] drm/sysfs: Link DRM connectors to corresponding Type-C connectors
On Tue, Mar 28, 2023 at 6:23 PM Won Chung wrote:
>
> Create a symlink pointing to USB Type-C connector for DRM connectors
> when they are created. The link will be created only if the firmware is
> able to describe the connection beween the two connectors.
>
> Currently, even if a display uses a USB Type-C port, there is no way for
> the userspace to find which port is used for which display. With the
> symlink, display information would be accessible from Type-C connectors
> and port information would be accessible from DRM connectors.
>
> Associating the two subsystems, userspace would have potential to expose
> and utilize more complex information. ChromeOS intend to use this
> information for metrics collection. For example, we want to tell which
> port is deriving which displays. Also, combined with USB PD information,
> we can tell whether user is charging their device through display.
> Chromium patch for parsing the symlink from the kernel is at
> http://crrev.com/c/4317207.
>
> We already have a framework in typec port-mapper.c where it goes through
> component devices and runs the bind functions for those with matching
> _PLD (physical location of device).
> https://elixir.bootlin.com/linux/v5.18.1/source/drivers/usb/typec/port-mapper.c
> Since _PLD is ACPI specific field, this linking would only work on ACPI
> x86 as long as _PLD field for Type-C connectors and DRM connectors are
> correctly added to the firmware.
>
> Currently, USB ports and USB4 ports are added as components to create a
> symlink with Type C connector.
> USB:
> https://lore.kernel.org/all/20211223082349.45616-1-heikki.kroge...@linux.intel.com/
> USB4:
> https://lore.kernel.org/all/20220418175932.1809770-3-wonch...@google.com/
> So, we follow the same pattern in this patch.
>
> Signed-off-by: Won Chung
> Acked-by: Heikki Krogerus
> ---
> Changes from v4: (4 months ago)
> - Update commit message with an actual use case from cros userspace
> - Move component_add to before ddc check which possibly returns
> - Rebased
>
> Changes from v3:
> - Append to the commit message on why this patch is needed
>
> Changes from v2:
> - Resend the patch to dri-devel list
>
> Changes from v1:
> - Fix multiple lines to single line
>
>
> drivers/gpu/drm/drm_sysfs.c | 40 +
> 1 file changed, 40 insertions(+)
>
> diff --git a/drivers/gpu/drm/drm_sysfs.c b/drivers/gpu/drm/drm_sysfs.c
> index 183130355997..c21312e87aa2 100644
> --- a/drivers/gpu/drm/drm_sysfs.c
> +++ b/drivers/gpu/drm/drm_sysfs.c
> @@ -11,12 +11,14 @@
> */
>
> #include
> +#include
> #include
> #include
> #include
> #include
> #include
> #include
> +#include
> #include
>
> #include
> @@ -96,6 +98,34 @@ static char *drm_devnode(const struct device *dev, umode_t
> *mode)
> return kasprintf(GFP_KERNEL, "dri/%s", dev_name(dev));
> }
>
> +static int typec_connector_bind(struct device *dev,
> + struct device *typec_connector, void *data)
> +{
> + int ret;
> +
> + ret = sysfs_create_link(&dev->kobj, &typec_connector->kobj,
> "typec_connector");
> + if (ret)
> + return ret;
> +
> + ret = sysfs_create_link(&typec_connector->kobj, &dev->kobj,
> "drm_connector");
> + if (ret)
> + sysfs_remove_link(&dev->kobj, "typec_connector");
> +
> + return ret;
> +}
> +
> +static void typec_connector_unbind(struct device *dev,
> + struct device *typec_connector, void *data)
> +{
> + sysfs_remove_link(&typec_connector->kobj, "drm_connector");
> + sysfs_remove_link(&dev->kobj, "typec_connector");
> +}
> +
> +static const struct component_ops typec_connector_ops = {
> + .bind = typec_connector_bind,
> + .unbind = typec_connector_unbind,
> +};
> +
> static CLASS_ATTR_STRING(version, S_IRUGO, "drm 1.1.0 20060810");
>
> /**
> @@ -353,9 +383,16 @@ int drm_sysfs_connector_add(struct drm_connector
> *connector)
>
> connector->kdev = kdev;
>
> + if (dev_fwnode(kdev)) {
> + r = component_add(kdev, &typec_connector_ops);
> + if (r)
> + drm_err(dev, "failed to add component\n");
Can you add more info in this drm_err message about the component that failed to
make it more intuitive
After this fix,
Reviewed-by: Manasi Navare
Manasi
> + }
> +
> if (connector->ddc)
> return sysfs_create_link(&connector->kdev->kobj,
> &connector->ddc->dev.kobj, "ddc");
> +
> return 0;
>
> err_free:
> @@ -371,6 +408,9 @@ void drm_sysfs_connector_remove(struct drm_connector
> *connector)
> if (connector->ddc)
> sysfs_remove_link(&connector->kdev->kobj, "ddc");
>
> + if (dev_fwnode(connector->kdev))
> + component_del(connector->kdev, &typec_connector_ops);
> +
> DRM_DEBUG("removing \"%s\" from sysfs\n",
> connector->name);
>
> --
> 2.40.0.348.gf938b09366-goog
>
Re: [PATCH v2 03/17] drm/msm/dpu: Move non-MDP_TOP INTF_INTR offsets out of hwio header
On 2023-04-24 13:44:55, Abhinav Kumar wrote:
>
>
> On 4/17/2023 1:21 PM, Marijn Suijten wrote:
> > These offsets do not fall under the MDP TOP block and do not fit the
> > comment right above. Move them to dpu_hw_interrupts.c next to the
> > repsective MDP_INTF_x_OFF interrupt block offsets.
> >
> > Fixes: 25fdd5933e4c ("drm/msm: Add SDM845 DPU support")
> > Signed-off-by: Marijn Suijten
>
> This change itself is fine, hence
>
> Reviewed-by: Abhinav Kumar
>
> One comment below.
>
> > ---
> > drivers/gpu/drm/msm/disp/dpu1/dpu_hw_interrupts.c | 5 -
> > drivers/gpu/drm/msm/disp/dpu1/dpu_hwio.h | 3 ---
> > 2 files changed, 4 insertions(+), 4 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_interrupts.c
> > b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_interrupts.c
> > index 53326f25e40e..85c0bda3ff90 100644
> > --- a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_interrupts.c
> > +++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_interrupts.c
> > @@ -15,7 +15,7 @@
> >
> > /*
> >* Register offsets in MDSS register file for the interrupt registers
> > - * w.r.t. to the MDP base
> > + * w.r.t. the MDP base
> >*/
> > #define MDP_SSPP_TOP0_OFF 0x0
> > #define MDP_INTF_0_OFF0x6A000
> > @@ -24,6 +24,9 @@
> > #define MDP_INTF_3_OFF0x6B800
> > #define MDP_INTF_4_OFF0x6C000
> > #define MDP_INTF_5_OFF0x6C800
> > +#define INTF_INTR_EN 0x1c0
> > +#define INTF_INTR_STATUS 0x1c4
> > +#define INTF_INTR_CLEAR0x1c8
> > #define MDP_AD4_0_OFF 0x7C000
> > #define MDP_AD4_1_OFF 0x7D000
> > #define MDP_AD4_INTR_EN_OFF 0x41c
> > diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_hwio.h
> > b/drivers/gpu/drm/msm/disp/dpu1/dpu_hwio.h
> > index feb9a729844a..5acd5683d25a 100644
> > --- a/drivers/gpu/drm/msm/disp/dpu1/dpu_hwio.h
> > +++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_hwio.h
> > @@ -21,9 +21,6 @@
> > #define HIST_INTR_EN0x01c
> > #define HIST_INTR_STATUS0x020
> > #define HIST_INTR_CLEAR 0x024
>
> Even HIST_INTR_*** need to be moved then.
These are relative to MDP_SSPP_TOP0_OFF too just like
INTR(2)_{CLEAR,EN,STATUS} so I left them here. Otherwise, *all* these
interrupt masks are probably best moved to dpu_hw_interrupts.c for
clarity, as that's also the only place they are used?
Let me know which way you prefer.
- Marijn
> > -#define INTF_INTR_EN0x1C0
> > -#define INTF_INTR_STATUS0x1C4
> > -#define INTF_INTR_CLEAR 0x1C8
> > #define SPLIT_DISPLAY_EN0x2F4
> > #define SPLIT_DISPLAY_UPPER_PIPE_CTRL 0x2F8
> > #define DSPP_IGC_COLOR0_RAM_LUTN0x300
> >
Re: [PATCH v2 02/17] drm/msm/dpu: Remove TE2 block and feature from DPU >= 7.0.0 hardware
On 2023-04-24 13:41:07, Abhinav Kumar wrote:
>
>
> On 4/17/2023 1:21 PM, Marijn Suijten wrote:
> > No hardware beyond kona (sm8250) defines the TE2 PINGPONG sub-block
> > offset downstream. Even though neither downstream nor upstream utilizes
> > these registers in any way, remove the erroneous specification for
> > SC8280XP, SM8350 and SM8450 to prevent confusion.
> >
> > Note that downstream enables the PPSPLIT (split-FIFO) topology (single
> > LM for 2 PP and 2 INTF) based on the presence of a TE2 block.
> >
> > Fixes: f0a1bdf64dd7 ("drm/msm/dpu: Introduce SC8280XP")
> > Fixes: 0a72f23f6ef8 ("drm/msm/dpu: Add SM8350 to hw catalog")
> > Fixes: 8cbbc3396065 ("drm/msm/dpu: add support for SM8450")
>
> I cannot find any commits with those hashes.
>
> Should this be
>
> Fixes: 4a352c2fc15a ("drm/msm/dpu: Introduce SC8280XP")
> Fixes: 0e91bcbb0016 ("drm/msm/dpu: Add SM8350 to hw catalog")
> Fixes: 100d7ef6995d ("drm/msm/dpu: add support for SM8450")
Yes they are, thanks for spotting that. These patches were on drm-msm
/ msm-next when I made this patch on January 11th, hence these were the
hashes given to me by git bisect: see how those patches have an author
timestamp of January 9th, while the proper hashes that landed upstream
have a hash of January 12th: the branch has been force-pushed after.
Old:
https://gitlab.freedesktop.org/drm/msm/-/commit/f0a1bdf64dd7
https://gitlab.freedesktop.org/drm/msm/-/commit/0a72f23f6ef8
https://gitlab.freedesktop.org/drm/msm/-/commit/8cbbc3396065
New:
https://gitlab.freedesktop.org/drm/msm/-/commit/4a352c2fc15a
https://gitlab.freedesktop.org/drm/msm/-/commit/0e91bcbb0016
https://gitlab.freedesktop.org/drm/msm/-/commit/100d7ef6995d
> Will wait for a day to fix this up, otherwise I will do it while applying.
Thanks, that's appreciated.
- Marijn
> > Signed-off-by: Marijn Suijten
> > ---
> > drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_7_0_sm8350.h | 4 ++--
> > drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_8_0_sc8280xp.h | 12 ++--
> > drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_8_1_sm8450.h | 4 ++--
> > 3 files changed, 10 insertions(+), 10 deletions(-)
[PATCH v8 7/7] drm/i915: Track gt pm wakerefs
Track every intel_gt_pm_get() until its corresponding release in
intel_gt_pm_put() by returning a cookie to the caller for acquire that
must be passed by on released. When there is an imbalance, we can see who
either tried to free a stale wakeref, or who forgot to free theirs.
Signed-off-by: Andrzej Hajda
---
drivers/gpu/drm/i915/Kconfig.debug | 14
drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c | 7 ++--
.../drm/i915/gem/selftests/i915_gem_coherency.c| 10 +++---
drivers/gpu/drm/i915/gem/selftests/i915_gem_mman.c | 14
drivers/gpu/drm/i915/gt/intel_breadcrumbs.c| 13 +---
drivers/gpu/drm/i915/gt/intel_breadcrumbs_types.h | 3 +-
drivers/gpu/drm/i915/gt/intel_context.h| 4 +--
drivers/gpu/drm/i915/gt/intel_context_types.h | 2 ++
drivers/gpu/drm/i915/gt/intel_engine_pm.c | 7 ++--
drivers/gpu/drm/i915/gt/intel_engine_types.h | 2 ++
.../gpu/drm/i915/gt/intel_execlists_submission.c | 2 +-
drivers/gpu/drm/i915/gt/intel_gt_pm.c | 12 ---
drivers/gpu/drm/i915/gt/intel_gt_pm.h | 38 +-
drivers/gpu/drm/i915/gt/intel_gt_pm_debugfs.c | 4 +--
drivers/gpu/drm/i915/gt/selftest_engine_cs.c | 20 +++-
drivers/gpu/drm/i915/gt/selftest_gt_pm.c | 5 +--
drivers/gpu/drm/i915/gt/selftest_reset.c | 10 +++---
drivers/gpu/drm/i915/gt/selftest_rps.c | 17 ++
drivers/gpu/drm/i915/gt/selftest_slpc.c| 5 +--
drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c | 10 +++---
drivers/gpu/drm/i915/i915_pmu.c| 16 +
drivers/gpu/drm/i915/intel_wakeref.c | 7 +++-
drivers/gpu/drm/i915/intel_wakeref.h | 38 --
23 files changed, 182 insertions(+), 78 deletions(-)
diff --git a/drivers/gpu/drm/i915/Kconfig.debug
b/drivers/gpu/drm/i915/Kconfig.debug
index 76454fcbf65228..01e18e4c0e2590 100644
--- a/drivers/gpu/drm/i915/Kconfig.debug
+++ b/drivers/gpu/drm/i915/Kconfig.debug
@@ -40,6 +40,7 @@ config DRM_I915_DEBUG
select DRM_I915_DEBUG_GEM_ONCE
select DRM_I915_DEBUG_MMIO
select DRM_I915_DEBUG_RUNTIME_PM
+ select DRM_I915_DEBUG_WAKEREF
select DRM_I915_SW_FENCE_DEBUG_OBJECTS
select DRM_I915_SELFTEST
default n
@@ -243,3 +244,16 @@ config DRM_I915_DEBUG_RUNTIME_PM
Recommended for driver developers only.
If in doubt, say "N"
+
+config DRM_I915_DEBUG_WAKEREF
+ bool "Enable extra tracking for wakerefs"
+ depends on DRM_I915
+ select REF_TRACKER
+ select STACKDEPOT
+ select STACKTRACE
+ help
+ Choose this option to turn on extra state checking and usage
+ tracking for the wakerefPM functionality. This may introduce
+ overhead during driver runtime.
+
+ If in doubt, say "N"
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
index 3aeede6aee4dcc..33a034a9c42f11 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
@@ -253,6 +253,7 @@ struct i915_execbuffer {
struct intel_gt *gt; /* gt for the execbuf */
struct intel_context *context; /* logical state for the request */
struct i915_gem_context *gem_context; /** caller's context */
+ intel_wakeref_t wakeref;
/** our requests to build */
struct i915_request *requests[MAX_ENGINE_INSTANCE + 1];
@@ -2709,7 +2710,7 @@ eb_select_engine(struct i915_execbuffer *eb)
for_each_child(ce, child)
intel_context_get(child);
- intel_gt_pm_get(ce->engine->gt);
+ eb->wakeref = intel_gt_pm_get(ce->engine->gt);
if (!test_bit(CONTEXT_ALLOC_BIT, &ce->flags)) {
err = intel_context_alloc_state(ce);
@@ -2748,7 +2749,7 @@ eb_select_engine(struct i915_execbuffer *eb)
return err;
err:
- intel_gt_pm_put(ce->engine->gt);
+ intel_gt_pm_put(ce->engine->gt, eb->wakeref);
for_each_child(ce, child)
intel_context_put(child);
intel_context_put(ce);
@@ -2761,7 +2762,7 @@ eb_put_engine(struct i915_execbuffer *eb)
struct intel_context *child;
i915_vm_put(eb->context->vm);
- intel_gt_pm_put(eb->gt);
+ intel_gt_pm_put(eb->context->engine->gt, eb->wakeref);
for_each_child(eb->context, child)
intel_context_put(child);
intel_context_put(eb->context);
diff --git a/drivers/gpu/drm/i915/gem/selftests/i915_gem_coherency.c
b/drivers/gpu/drm/i915/gem/selftests/i915_gem_coherency.c
index 3bef1beec7cbb5..3fd68a099a85ef 100644
--- a/drivers/gpu/drm/i915/gem/selftests/i915_gem_coherency.c
+++ b/drivers/gpu/drm/i915/gem/selftests/i915_gem_coherency.c
@@ -85,6 +85,7 @@ static int cpu_get(struct context *ctx, unsigned long offset,
u32 *v)
static int gtt_set(struct context *ctx, un
[PATCH v8 6/7] drm/i915: Replace custom intel runtime_pm tracker with ref_tracker library
Beside reusing existing code, the main advantage of ref_tracker is
tracking per instance of wakeref. It allows also to catch double
put.
On the other side we lose information about the first acquire and
the last release, but the advantages outweigh it.
Signed-off-by: Andrzej Hajda
---
drivers/gpu/drm/i915/Kconfig.debug | 4 +
drivers/gpu/drm/i915/display/intel_display_power.c | 2 +-
drivers/gpu/drm/i915/i915_driver.c | 2 +-
drivers/gpu/drm/i915/intel_runtime_pm.c| 221 ++---
drivers/gpu/drm/i915/intel_runtime_pm.h| 11 +-
drivers/gpu/drm/i915/intel_wakeref.c | 28 +++
drivers/gpu/drm/i915/intel_wakeref.h | 35 +++-
7 files changed, 86 insertions(+), 217 deletions(-)
diff --git a/drivers/gpu/drm/i915/Kconfig.debug
b/drivers/gpu/drm/i915/Kconfig.debug
index 47e845353ffad8..76454fcbf65228 100644
--- a/drivers/gpu/drm/i915/Kconfig.debug
+++ b/drivers/gpu/drm/i915/Kconfig.debug
@@ -24,7 +24,9 @@ config DRM_I915_DEBUG
select DEBUG_FS
select PREEMPT_COUNT
select I2C_CHARDEV
+ select REF_TRACKER
select STACKDEPOT
+ select STACKTRACE
select DRM_DP_AUX_CHARDEV
select X86_MSR # used by igt/pm_rpm
select DRM_VGEM # used by igt/prime_vgem (dmabuf interop checks)
@@ -230,7 +232,9 @@ config DRM_I915_DEBUG_RUNTIME_PM
bool "Enable extra state checking for runtime PM"
depends on DRM_I915
default n
+ select REF_TRACKER
select STACKDEPOT
+ select STACKTRACE
help
Choose this option to turn on extra state checking for the
runtime PM functionality. This may introduce overhead during
diff --git a/drivers/gpu/drm/i915/display/intel_display_power.c
b/drivers/gpu/drm/i915/display/intel_display_power.c
index 5150069f3f8218..36d202d3391857 100644
--- a/drivers/gpu/drm/i915/display/intel_display_power.c
+++ b/drivers/gpu/drm/i915/display/intel_display_power.c
@@ -407,7 +407,7 @@ print_async_put_domains_state(struct i915_power_domains
*power_domains)
struct drm_i915_private,
display.power.domains);
- drm_dbg(&i915->drm, "async_put_wakeref %u\n",
+ drm_dbg(&i915->drm, "async_put_wakeref %lu\n",
power_domains->async_put_wakeref);
print_power_domains(power_domains, "async_put_domains[0]",
diff --git a/drivers/gpu/drm/i915/i915_driver.c
b/drivers/gpu/drm/i915/i915_driver.c
index fd198700272b10..4e2fb438e26f04 100644
--- a/drivers/gpu/drm/i915/i915_driver.c
+++ b/drivers/gpu/drm/i915/i915_driver.c
@@ -1018,7 +1018,7 @@ void i915_driver_shutdown(struct drm_i915_private *i915)
intel_power_domains_driver_remove(i915);
enable_rpm_wakeref_asserts(&i915->runtime_pm);
- intel_runtime_pm_driver_release(&i915->runtime_pm);
+ intel_runtime_pm_driver_last_release(&i915->runtime_pm);
}
static bool suspend_to_idle(struct drm_i915_private *dev_priv)
diff --git a/drivers/gpu/drm/i915/intel_runtime_pm.c
b/drivers/gpu/drm/i915/intel_runtime_pm.c
index cf5122299b6b8c..2166c209f17f04 100644
--- a/drivers/gpu/drm/i915/intel_runtime_pm.c
+++ b/drivers/gpu/drm/i915/intel_runtime_pm.c
@@ -52,182 +52,37 @@
#if IS_ENABLED(CONFIG_DRM_I915_DEBUG_RUNTIME_PM)
-#include
-
-#define STACKDEPTH 8
-
-static noinline depot_stack_handle_t __save_depot_stack(void)
-{
- unsigned long entries[STACKDEPTH];
- unsigned int n;
-
- n = stack_trace_save(entries, ARRAY_SIZE(entries), 1);
- return stack_depot_save(entries, n, GFP_NOWAIT | __GFP_NOWARN);
-}
-
static void init_intel_runtime_pm_wakeref(struct intel_runtime_pm *rpm)
{
- spin_lock_init(&rpm->debug.lock);
- stack_depot_init();
+ ref_tracker_dir_init(&rpm->debug, INTEL_REFTRACK_DEAD_COUNT,
dev_name(rpm->kdev));
}
-static noinline depot_stack_handle_t
+static intel_wakeref_t
track_intel_runtime_pm_wakeref(struct intel_runtime_pm *rpm)
{
- depot_stack_handle_t stack, *stacks;
- unsigned long flags;
-
- if (rpm->no_wakeref_tracking)
- return -1;
-
- stack = __save_depot_stack();
- if (!stack)
+ if (!rpm->available || rpm->no_wakeref_tracking)
return -1;
- spin_lock_irqsave(&rpm->debug.lock, flags);
-
- if (!rpm->debug.count)
- rpm->debug.last_acquire = stack;
-
- stacks = krealloc(rpm->debug.owners,
- (rpm->debug.count + 1) * sizeof(*stacks),
- GFP_NOWAIT | __GFP_NOWARN);
- if (stacks) {
- stacks[rpm->debug.count++] = stack;
- rpm->debug.owners = stacks;
- } else {
- stack = -1;
- }
-
- spin_unlock_irqrestore(&rpm->debug.lock, flags);
-
- return stack;
+ return intel_ref_tracker_alloc(&rpm->debug);
}
static void untrac
[PATCH v8 3/7] lib/ref_tracker: add printing to memory buffer
Similar to stack_(depot|trace)_snprint the patch
adds helper to printing stats to memory buffer.
It will be helpful in case of debugfs.
Signed-off-by: Andrzej Hajda
Reviewed-by: Andi Shyti
---
include/linux/ref_tracker.h | 8 +++
lib/ref_tracker.c | 56 ++---
2 files changed, 56 insertions(+), 8 deletions(-)
diff --git a/include/linux/ref_tracker.h b/include/linux/ref_tracker.h
index 19a69e7809d6c1..8eac4f3d52547c 100644
--- a/include/linux/ref_tracker.h
+++ b/include/linux/ref_tracker.h
@@ -46,6 +46,8 @@ void ref_tracker_dir_print_locked(struct ref_tracker_dir *dir,
void ref_tracker_dir_print(struct ref_tracker_dir *dir,
unsigned int display_limit);
+int ref_tracker_dir_snprint(struct ref_tracker_dir *dir, char *buf, size_t
size);
+
int ref_tracker_alloc(struct ref_tracker_dir *dir,
struct ref_tracker **trackerp, gfp_t gfp);
@@ -74,6 +76,12 @@ static inline void ref_tracker_dir_print(struct
ref_tracker_dir *dir,
{
}
+static inline int ref_tracker_dir_snprint(struct ref_tracker_dir *dir,
+ char *buf, size_t size)
+{
+ return 0;
+}
+
static inline int ref_tracker_alloc(struct ref_tracker_dir *dir,
struct ref_tracker **trackerp,
gfp_t gfp)
diff --git a/lib/ref_tracker.c b/lib/ref_tracker.c
index 2ffe79c90c1771..cce4614b07940f 100644
--- a/lib/ref_tracker.c
+++ b/lib/ref_tracker.c
@@ -62,8 +62,27 @@ ref_tracker_get_stats(struct ref_tracker_dir *dir, unsigned
int limit)
return stats;
}
-void ref_tracker_dir_print_locked(struct ref_tracker_dir *dir,
- unsigned int display_limit)
+struct ostream {
+ char *buf;
+ int size, used;
+};
+
+#define pr_ostream(stream, fmt, args...) \
+({ \
+ struct ostream *_s = (stream); \
+\
+ if (!_s->buf) { \
+ pr_err(fmt, ##args); \
+ } else { \
+ int ret, len = _s->size - _s->used; \
+ ret = snprintf(_s->buf + _s->used, len, pr_fmt(fmt), ##args); \
+ _s->used += min(ret, len); \
+ } \
+})
+
+static void
+__ref_tracker_dir_pr_ostream(struct ref_tracker_dir *dir,
+unsigned int display_limit, struct ostream *s)
{
struct ref_tracker_dir_stats *stats;
unsigned int i = 0, skipped;
@@ -77,8 +96,8 @@ void ref_tracker_dir_print_locked(struct ref_tracker_dir *dir,
stats = ref_tracker_get_stats(dir, display_limit);
if (IS_ERR(stats)) {
- pr_err("%s@%pK: couldn't get stats, error %pe\n",
- dir->name, dir, stats);
+ pr_ostream(s, "%s@%pK: couldn't get stats, error %pe\n",
+ dir->name, dir, stats);
return;
}
@@ -88,19 +107,27 @@ void ref_tracker_dir_print_locked(struct ref_tracker_dir
*dir,
stack = stats->stacks[i].stack_handle;
if (sbuf && !stack_depot_snprint(stack, sbuf, STACK_BUF_SIZE,
4))
sbuf[0] = 0;
- pr_err("%s@%pK has %d/%d users at\n%s\n", dir->name, dir,
- stats->stacks[i].count, stats->total, sbuf);
+ pr_ostream(s, "%s@%pK has %d/%d users at\n%s\n", dir->name, dir,
+ stats->stacks[i].count, stats->total, sbuf);
skipped -= stats->stacks[i].count;
}
if (skipped)
- pr_err("%s@%pK skipped reports about %d/%d users.\n",
- dir->name, dir, skipped, stats->total);
+ pr_ostream(s, "%s@%pK skipped reports about %d/%d users.\n",
+ dir->name, dir, skipped, stats->total);
kfree(sbuf);
kfree(stats);
}
+
+void ref_tracker_dir_print_locked(struct ref_tracker_dir *dir,
+ unsigned int display_limit)
+{
+ struct ostream os = {};
+
+ __ref_tracker_dir_pr_ostream(dir, display_limit, &os);
+}
EXPORT_SYMBOL(ref_tracker_dir_print_locked);
void ref_tracker_dir_print(struct ref_tracker_dir *dir,
@@ -114,6 +141,19 @@ void ref_tracker_dir_print(struct ref_tracker_dir *dir,
}
EXPORT_SYMBOL(ref_tracker_dir_print);
+int ref_tracker_dir_snprint(struct ref_tracker_dir *dir, char *buf, size_t
size)
+{
+ struct ostream os = { .buf = buf, .size = size };
+ unsigned long flags;
+
+ spin_lock_irqsave(&dir->lock, flags);
+ __ref_tracker_dir_pr_ostream(dir, 16, &os);
+ spin_unlock_irqrestore(&dir->lock, flags);
+
+ return os.used;
+}
+EXPORT_SYMBOL(ref_tracker_dir_snprint);
+
void ref_tracker_dir_exit(struct ref_tracker_dir *dir)
{
struct ref_tracker *tracker, *n;
--
2.34.1
[PATCH v8 5/7] drm/i915: Correct type of wakeref variable
Wakeref has dedicated type. Assumption it will be int compatible forever is incorrect. Signed-off-by: Andrzej Hajda Reviewed-by: Andi Shyti --- drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c b/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c index ee3e8352637f28..fe390d59929b02 100644 --- a/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c +++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c @@ -3248,7 +3248,7 @@ static void destroyed_worker_func(struct work_struct *w) struct intel_guc *guc = container_of(w, struct intel_guc, submission_state.destroyed_worker); struct intel_gt *gt = guc_to_gt(guc); - int tmp; + intel_wakeref_t tmp; with_intel_gt_pm(gt, tmp) deregister_destroyed_contexts(guc); -- 2.34.1
[PATCH v8 2/7] lib/ref_tracker: improve printing stats
In case the library is tracking busy subsystem, simply
printing stack for every active reference will spam log
with long, hard to read, redundant stack traces. To improve
readabilty following changes have been made:
- reports are printed per stack_handle - log is more compact,
- added display name for ref_tracker_dir - it will differentiate
multiple subsystems,
- stack trace is printed indented, in the same printk call,
- info about dropped references is printed as well.
Signed-off-by: Andrzej Hajda
Reviewed-by: Andi Shyti
---
include/linux/ref_tracker.h | 9 -
lib/ref_tracker.c | 90 +++--
lib/test_ref_tracker.c | 2 +-
net/core/dev.c | 2 +-
net/core/net_namespace.c| 4 +-
5 files changed, 90 insertions(+), 17 deletions(-)
diff --git a/include/linux/ref_tracker.h b/include/linux/ref_tracker.h
index 87a92f2bec1b88..19a69e7809d6c1 100644
--- a/include/linux/ref_tracker.h
+++ b/include/linux/ref_tracker.h
@@ -17,12 +17,15 @@ struct ref_tracker_dir {
booldead;
struct list_headlist; /* List of active trackers */
struct list_headquarantine; /* List of dead trackers */
+ charname[32];
#endif
};
#ifdef CONFIG_REF_TRACKER
+
static inline void ref_tracker_dir_init(struct ref_tracker_dir *dir,
- unsigned int quarantine_count)
+ unsigned int quarantine_count,
+ const char *name)
{
INIT_LIST_HEAD(&dir->list);
INIT_LIST_HEAD(&dir->quarantine);
@@ -31,6 +34,7 @@ static inline void ref_tracker_dir_init(struct
ref_tracker_dir *dir,
dir->dead = false;
refcount_set(&dir->untracked, 1);
refcount_set(&dir->no_tracker, 1);
+ strscpy(dir->name, name, sizeof(dir->name));
stack_depot_init();
}
@@ -51,7 +55,8 @@ int ref_tracker_free(struct ref_tracker_dir *dir,
#else /* CONFIG_REF_TRACKER */
static inline void ref_tracker_dir_init(struct ref_tracker_dir *dir,
- unsigned int quarantine_count)
+ unsigned int quarantine_count,
+ const char *name)
{
}
diff --git a/lib/ref_tracker.c b/lib/ref_tracker.c
index d4eb0929af8f96..2ffe79c90c1771 100644
--- a/lib/ref_tracker.c
+++ b/lib/ref_tracker.c
@@ -1,11 +1,16 @@
// SPDX-License-Identifier: GPL-2.0-or-later
+
+#define pr_fmt(fmt) "ref_tracker: " fmt
+
#include
+#include
#include
#include
#include
#include
#define REF_TRACKER_STACK_ENTRIES 16
+#define STACK_BUF_SIZE 1024
struct ref_tracker {
struct list_headhead; /* anchor into dir->list or
dir->quarantine */
@@ -14,24 +19,87 @@ struct ref_tracker {
depot_stack_handle_tfree_stack_handle;
};
-void ref_tracker_dir_print_locked(struct ref_tracker_dir *dir,
- unsigned int display_limit)
+struct ref_tracker_dir_stats {
+ int total;
+ int count;
+ struct {
+ depot_stack_handle_t stack_handle;
+ unsigned int count;
+ } stacks[];
+};
+
+static struct ref_tracker_dir_stats *
+ref_tracker_get_stats(struct ref_tracker_dir *dir, unsigned int limit)
{
+ struct ref_tracker_dir_stats *stats;
struct ref_tracker *tracker;
- unsigned int i = 0;
- lockdep_assert_held(&dir->lock);
+ stats = kmalloc(struct_size(stats, stacks, limit),
+ GFP_NOWAIT | __GFP_NOWARN);
+ if (!stats)
+ return ERR_PTR(-ENOMEM);
+ stats->total = 0;
+ stats->count = 0;
list_for_each_entry(tracker, &dir->list, head) {
- if (i < display_limit) {
- pr_err("leaked reference.\n");
- if (tracker->alloc_stack_handle)
- stack_depot_print(tracker->alloc_stack_handle);
- i++;
- } else {
- break;
+ depot_stack_handle_t stack = tracker->alloc_stack_handle;
+ int i;
+
+ ++stats->total;
+ for (i = 0; i < stats->count; ++i)
+ if (stats->stacks[i].stack_handle == stack)
+ break;
+ if (i >= limit)
+ continue;
+ if (i >= stats->count) {
+ stats->stacks[i].stack_handle = stack;
+ stats->stacks[i].count = 0;
+ ++stats->count;
}
+ ++stats->stacks[i].count;
+ }
+
+ return stats;
+}
+
+void ref_tracker_dir_print_locked(struct ref_tracker_dir *dir,
+ unsigned int display_limit)
+{
+ struct ref_tracker_dir_stats *stats;
+ unsigned int i = 0, skipped;
+ depot_sta
[PATCH v8 4/7] lib/ref_tracker: remove warnings in case of allocation failure
Library can handle allocation failures. To avoid allocation warnings
__GFP_NOWARN has been added everywhere. Moreover GFP_ATOMIC has been
replaced with GFP_NOWAIT in case of stack allocation on tracker free
call.
Signed-off-by: Andrzej Hajda
Reviewed-by: Andi Shyti
Reviewed-by: Eric Dumazet
---
lib/ref_tracker.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/lib/ref_tracker.c b/lib/ref_tracker.c
index cce4614b07940f..cf5609b1ca7936 100644
--- a/lib/ref_tracker.c
+++ b/lib/ref_tracker.c
@@ -189,7 +189,7 @@ int ref_tracker_alloc(struct ref_tracker_dir *dir,
unsigned long entries[REF_TRACKER_STACK_ENTRIES];
struct ref_tracker *tracker;
unsigned int nr_entries;
- gfp_t gfp_mask = gfp;
+ gfp_t gfp_mask = gfp | __GFP_NOWARN;
unsigned long flags;
WARN_ON_ONCE(dir->dead);
@@ -237,7 +237,8 @@ int ref_tracker_free(struct ref_tracker_dir *dir,
return -EEXIST;
}
nr_entries = stack_trace_save(entries, ARRAY_SIZE(entries), 1);
- stack_handle = stack_depot_save(entries, nr_entries, GFP_ATOMIC);
+ stack_handle = stack_depot_save(entries, nr_entries,
+ GFP_NOWAIT | __GFP_NOWARN);
spin_lock_irqsave(&dir->lock, flags);
if (tracker->dead) {
--
2.34.1
[PATCH v8 1/7] lib/ref_tracker: add unlocked leak print helper
To have reliable detection of leaks, caller must be able to check under
the same lock both: tracked counter and the leaks. dir.lock is natural
candidate for such lock and unlocked print helper can be called with this
lock taken.
As a bonus we can reuse this helper in ref_tracker_dir_exit.
Signed-off-by: Andrzej Hajda
Reviewed-by: Andi Shyti
Reviewed-by: Eric Dumazet
---
include/linux/ref_tracker.h | 8 ++
lib/ref_tracker.c | 66 ++---
2 files changed, 46 insertions(+), 28 deletions(-)
diff --git a/include/linux/ref_tracker.h b/include/linux/ref_tracker.h
index 9ca353ab712b5e..87a92f2bec1b88 100644
--- a/include/linux/ref_tracker.h
+++ b/include/linux/ref_tracker.h
@@ -36,6 +36,9 @@ static inline void ref_tracker_dir_init(struct
ref_tracker_dir *dir,
void ref_tracker_dir_exit(struct ref_tracker_dir *dir);
+void ref_tracker_dir_print_locked(struct ref_tracker_dir *dir,
+ unsigned int display_limit);
+
void ref_tracker_dir_print(struct ref_tracker_dir *dir,
unsigned int display_limit);
@@ -56,6 +59,11 @@ static inline void ref_tracker_dir_exit(struct
ref_tracker_dir *dir)
{
}
+static inline void ref_tracker_dir_print_locked(struct ref_tracker_dir *dir,
+ unsigned int display_limit)
+{
+}
+
static inline void ref_tracker_dir_print(struct ref_tracker_dir *dir,
unsigned int display_limit)
{
diff --git a/lib/ref_tracker.c b/lib/ref_tracker.c
index dc7b14aa3431e2..d4eb0929af8f96 100644
--- a/lib/ref_tracker.c
+++ b/lib/ref_tracker.c
@@ -14,6 +14,38 @@ struct ref_tracker {
depot_stack_handle_tfree_stack_handle;
};
+void ref_tracker_dir_print_locked(struct ref_tracker_dir *dir,
+ unsigned int display_limit)
+{
+ struct ref_tracker *tracker;
+ unsigned int i = 0;
+
+ lockdep_assert_held(&dir->lock);
+
+ list_for_each_entry(tracker, &dir->list, head) {
+ if (i < display_limit) {
+ pr_err("leaked reference.\n");
+ if (tracker->alloc_stack_handle)
+ stack_depot_print(tracker->alloc_stack_handle);
+ i++;
+ } else {
+ break;
+ }
+ }
+}
+EXPORT_SYMBOL(ref_tracker_dir_print_locked);
+
+void ref_tracker_dir_print(struct ref_tracker_dir *dir,
+ unsigned int display_limit)
+{
+ unsigned long flags;
+
+ spin_lock_irqsave(&dir->lock, flags);
+ ref_tracker_dir_print_locked(dir, display_limit);
+ spin_unlock_irqrestore(&dir->lock, flags);
+}
+EXPORT_SYMBOL(ref_tracker_dir_print);
+
void ref_tracker_dir_exit(struct ref_tracker_dir *dir)
{
struct ref_tracker *tracker, *n;
@@ -27,13 +59,13 @@ void ref_tracker_dir_exit(struct ref_tracker_dir *dir)
kfree(tracker);
dir->quarantine_avail++;
}
- list_for_each_entry_safe(tracker, n, &dir->list, head) {
- pr_err("leaked reference.\n");
- if (tracker->alloc_stack_handle)
- stack_depot_print(tracker->alloc_stack_handle);
+ if (!list_empty(&dir->list)) {
+ ref_tracker_dir_print_locked(dir, 16);
leak = true;
- list_del(&tracker->head);
- kfree(tracker);
+ list_for_each_entry_safe(tracker, n, &dir->list, head) {
+ list_del(&tracker->head);
+ kfree(tracker);
+ }
}
spin_unlock_irqrestore(&dir->lock, flags);
WARN_ON_ONCE(leak);
@@ -42,28 +74,6 @@ void ref_tracker_dir_exit(struct ref_tracker_dir *dir)
}
EXPORT_SYMBOL(ref_tracker_dir_exit);
-void ref_tracker_dir_print(struct ref_tracker_dir *dir,
- unsigned int display_limit)
-{
- struct ref_tracker *tracker;
- unsigned long flags;
- unsigned int i = 0;
-
- spin_lock_irqsave(&dir->lock, flags);
- list_for_each_entry(tracker, &dir->list, head) {
- if (i < display_limit) {
- pr_err("leaked reference.\n");
- if (tracker->alloc_stack_handle)
- stack_depot_print(tracker->alloc_stack_handle);
- i++;
- } else {
- break;
- }
- }
- spin_unlock_irqrestore(&dir->lock, flags);
-}
-EXPORT_SYMBOL(ref_tracker_dir_print);
-
int ref_tracker_alloc(struct ref_tracker_dir *dir,
struct ref_tracker **trackerp,
gfp_t gfp)
--
2.34.1
[PATCH v8 0/7] drm/i915: use ref_tracker library for tracking wakerefs
This is revived patchset improving ref_tracker library and converting i915 internal tracker to ref_tracker. The old thread ended without consensus about small kernel allocations, which are performed under spinlock. I have tried to solve the problem by splitting the calls, but it results in complicated API, so I went back to original solution. If there are better solutions I am glad to discuss them. Meanwhile I send original patchset with addressed remaining comments. To: Jani Nikula To: Joonas Lahtinen To: Rodrigo Vivi To: Tvrtko Ursulin To: David Airlie To: Daniel Vetter To: Eric Dumazet Cc: linux-ker...@vger.kernel.org Cc: intel-...@lists.freedesktop.org Cc: dri-devel@lists.freedesktop.org Cc: Chris Wilson Cc: net...@vger.kernel.org Cc: Jakub Kicinski Cc: Dmitry Vyukov Cc: "David S. Miller" Cc: Andi Shyti Cc: Das, Nirmoy Signed-off-by: Andrzej Hajda --- Changes in v8: - addressed comments from Eric, Zhou and CI, thanks, - added ref_tracker_dir_init name argument to all callers in one patch - moved intel_wakeref_tracker_show to *.c - s/intel_wakeref_tracker_show/intel_ref_tracker_show/ - removed 'default n' from Kconfig - changed strlcpy to strscpy, - removed assignement from if condition, - removed long lines from patch description - added tags - Link to v7: https://lore.kernel.org/r/20230224-track_gt-v7-0-11f08358c...@intel.com Changes in v7: - removed 8th patch (hold wakeref), as it was already merged - added tags (thx Andi) - Link to v6: https://lore.kernel.org/r/20230224-track_gt-v6-0-0dc8601fd...@intel.com Changes in v6: - rebased to solve minor conflict and allow CI testing - Link to v5: https://lore.kernel.org/r/20230224-track_gt-v5-0-77be86f2c...@intel.com Changes in v5 (thx Andi for review): - use *_locked convention instead of __*, - improved commit messages, - re-worked i915 patches, squashed separation and conversion patches, - added tags, - Link to v4: https://lore.kernel.org/r/20230224-track_gt-v4-0-464e8ab4c...@intel.com Changes in v4: - split "Separate wakeref tracking" to smaller parts - fixed typos, - Link to v1-v3: https://patchwork.freedesktop.org/series/100327/ --- Andrzej Hajda (7): lib/ref_tracker: add unlocked leak print helper lib/ref_tracker: improve printing stats lib/ref_tracker: add printing to memory buffer lib/ref_tracker: remove warnings in case of allocation failure drm/i915: Correct type of wakeref variable drm/i915: Replace custom intel runtime_pm tracker with ref_tracker library drm/i915: Track gt pm wakerefs drivers/gpu/drm/i915/Kconfig.debug | 18 ++ drivers/gpu/drm/i915/display/intel_display_power.c | 2 +- drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c | 7 +- .../drm/i915/gem/selftests/i915_gem_coherency.c| 10 +- drivers/gpu/drm/i915/gem/selftests/i915_gem_mman.c | 14 +- drivers/gpu/drm/i915/gt/intel_breadcrumbs.c| 13 +- drivers/gpu/drm/i915/gt/intel_breadcrumbs_types.h | 3 +- drivers/gpu/drm/i915/gt/intel_context.h| 4 +- drivers/gpu/drm/i915/gt/intel_context_types.h | 2 + drivers/gpu/drm/i915/gt/intel_engine_pm.c | 7 +- drivers/gpu/drm/i915/gt/intel_engine_types.h | 2 + .../gpu/drm/i915/gt/intel_execlists_submission.c | 2 +- drivers/gpu/drm/i915/gt/intel_gt_pm.c | 12 +- drivers/gpu/drm/i915/gt/intel_gt_pm.h | 38 +++- drivers/gpu/drm/i915/gt/intel_gt_pm_debugfs.c | 4 +- drivers/gpu/drm/i915/gt/selftest_engine_cs.c | 20 +- drivers/gpu/drm/i915/gt/selftest_gt_pm.c | 5 +- drivers/gpu/drm/i915/gt/selftest_reset.c | 10 +- drivers/gpu/drm/i915/gt/selftest_rps.c | 17 +- drivers/gpu/drm/i915/gt/selftest_slpc.c| 5 +- drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c | 12 +- drivers/gpu/drm/i915/i915_driver.c | 2 +- drivers/gpu/drm/i915/i915_pmu.c| 16 +- drivers/gpu/drm/i915/intel_runtime_pm.c| 221 ++--- drivers/gpu/drm/i915/intel_runtime_pm.h| 11 +- drivers/gpu/drm/i915/intel_wakeref.c | 35 +++- drivers/gpu/drm/i915/intel_wakeref.h | 73 ++- include/linux/ref_tracker.h| 25 ++- lib/ref_tracker.c | 179 ++--- lib/test_ref_tracker.c | 2 +- net/core/dev.c | 2 +- net/core/net_namespace.c | 4 +- 32 files changed, 445 insertions(+), 332 deletions(-) --- base-commit: 4d0066a1c0763d50b6fb017e27d12b081ce21b57 change-id: 20230224-track_gt-1b3da8bdacd7 Best regards, -- Andrzej Hajda
Re: [PATCH v2 3/3] drm/msm/dpu: Pass catalog pointers directly from RM instead of IDs
On 2023-04-21 16:25:15, Abhinav Kumar wrote:
>
>
> On 4/21/2023 1:53 PM, Marijn Suijten wrote:
> > The Resource Manager already iterates over all available blocks from the
> > catalog, only to pass their ID to a dpu_hw_xxx_init() function which
> > uses an _xxx_offset() helper to search for and find the exact same
> > catalog pointer again to initialize the block with, fallible error
> > handling and all.
> >
> > Instead, pass const pointers to the catalog entries directly to these
> > _init functions and drop the for loops entirely, saving on both
> > readability complexity and unnecessary cycles at boot.
> >
> > Signed-off-by: Marijn Suijten
> > Reviewed-by: Dmitry Baryshkov
>
> Overall, a nice cleanup!
>
> One comment below.
>
> > ---
> > drivers/gpu/drm/msm/disp/dpu1/dpu_hw_ctl.c| 37
> > +
> > drivers/gpu/drm/msm/disp/dpu1/dpu_hw_ctl.h| 14
> > drivers/gpu/drm/msm/disp/dpu1/dpu_hw_dsc.c| 32 +++---
> > drivers/gpu/drm/msm/disp/dpu1/dpu_hw_dsc.h| 11 +++
> > drivers/gpu/drm/msm/disp/dpu1/dpu_hw_dspp.c | 38
> > -
> > drivers/gpu/drm/msm/disp/dpu1/dpu_hw_dspp.h | 12 +++
> > drivers/gpu/drm/msm/disp/dpu1/dpu_hw_interrupts.h | 2 +-
> > drivers/gpu/drm/msm/disp/dpu1/dpu_hw_intf.c | 40
> > ++-
> > drivers/gpu/drm/msm/disp/dpu1/dpu_hw_intf.h | 12 +++
> > drivers/gpu/drm/msm/disp/dpu1/dpu_hw_lm.c | 38
> > -
> > drivers/gpu/drm/msm/disp/dpu1/dpu_hw_lm.h | 10 +++---
> > drivers/gpu/drm/msm/disp/dpu1/dpu_hw_merge3d.c| 33 +++
> > drivers/gpu/drm/msm/disp/dpu1/dpu_hw_merge3d.h| 14
> > drivers/gpu/drm/msm/disp/dpu1/dpu_hw_pingpong.c | 33 +++
> > drivers/gpu/drm/msm/disp/dpu1/dpu_hw_pingpong.h | 14
> > drivers/gpu/drm/msm/disp/dpu1/dpu_hw_sspp.c | 39
> > --
> > drivers/gpu/drm/msm/disp/dpu1/dpu_hw_sspp.h | 12 +++
> > drivers/gpu/drm/msm/disp/dpu1/dpu_hw_vbif.c | 33 +++
> > drivers/gpu/drm/msm/disp/dpu1/dpu_hw_vbif.h | 11 +++
> > drivers/gpu/drm/msm/disp/dpu1/dpu_hw_wb.c | 33 ---
> > drivers/gpu/drm/msm/disp/dpu1/dpu_hw_wb.h | 11 +++
> > drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c | 17 +-
> > drivers/gpu/drm/msm/disp/dpu1/dpu_rm.c| 18 +-
> > 23 files changed, 139 insertions(+), 375 deletions(-)
> >
>
>
>
> > -struct dpu_hw_intf *dpu_hw_intf_init(enum dpu_intf idx,
> > - void __iomem *addr,
> > - const struct dpu_mdss_cfg *m)
> > +struct dpu_hw_intf *dpu_hw_intf_init(const struct dpu_intf_cfg *cfg,
> > + void __iomem *addr)
> > {
> > struct dpu_hw_intf *c;
> > - const struct dpu_intf_cfg *cfg;
> > +
> > + if (cfg->type == INTF_NONE) {
> > + pr_err("Cannot create interface hw object for INTF_NONE
> > type\n");
> > + return ERR_PTR(-EINVAL);
> > + }
>
> The caller of dpu_hw_intf_init which is the RM already has protection
> for INTF_NONE, see below
>
> for (i = 0; i < cat->intf_count; i++) {
> struct dpu_hw_intf *hw;
> const struct dpu_intf_cfg *intf = &cat->intf[i];
>
> if (intf->type == INTF_NONE) {
> DPU_DEBUG("skip intf %d with type none\n", i);
> continue;
> }
> if (intf->id < INTF_0 || intf->id >= INTF_MAX) {
> DPU_ERROR("skip intf %d with invalid id\n",
> intf->id);
> continue;
> }
> hw = dpu_hw_intf_init(intf->id, mmio, cat);
>
> So this part can be dropped.
I mainly intended to keep original validation where _intf_offset would
skip INTF_NONE, and error out. RM init is hence expected to filter out
INTF_NONE instead of running into that `-EINVAL`, which I maintained
here.
If you think there won't be another caller of dpu_hw_intf_init, and that
such validation is hence excessive, I can remove it in a followup v3.
- Marijn
> > c = kzalloc(sizeof(*c), GFP_KERNEL);
> > if (!c)
> > return ERR_PTR(-ENOMEM);
> >
> > - cfg = _intf_offset(idx, m, addr, &c->hw);
> > - if (IS_ERR_OR_NULL(cfg)) {
> > - kfree(c);
> > - pr_err("failed to create dpu_hw_intf %d\n", idx);
> > - return ERR_PTR(-EINVAL);
> > - }
> > + c->hw.blk_addr = addr + cfg->base;
> > + c->hw.log_mask = DPU_DBG_MASK_INTF;
> >
>
>
Re: [PATCH v4 1/6] drm/vkms: isolate pixel conversion functionality
On 4/18/23 10:05, Maíra Canal wrote:
Currently, the pixel conversion functions repeat the same loop to
iterate the rows. Instead of repeating the same code for each pixel
format, create a function to wrap the loop and isolate the pixel
conversion functionality.
Suggested-by: Arthur Grillo
Signed-off-by: Maíra Canal
Reviewed-by: Arthur Grillo
Applied to drm/drm-misc (drm-misc-next).
Best Regards,
- Maíra Canal
---
drivers/gpu/drm/vkms/vkms_composer.c | 4 +-
drivers/gpu/drm/vkms/vkms_drv.h | 4 +-
drivers/gpu/drm/vkms/vkms_formats.c | 125 +++
drivers/gpu/drm/vkms/vkms_formats.h | 2 +-
drivers/gpu/drm/vkms/vkms_plane.c| 2 +-
5 files changed, 56 insertions(+), 81 deletions(-)
diff --git a/drivers/gpu/drm/vkms/vkms_composer.c
b/drivers/gpu/drm/vkms/vkms_composer.c
index 8e53fa80742b..80164e79af00 100644
--- a/drivers/gpu/drm/vkms/vkms_composer.c
+++ b/drivers/gpu/drm/vkms/vkms_composer.c
@@ -99,7 +99,7 @@ static void blend(struct vkms_writeback_job *wb,
if (!check_y_limit(plane[i]->frame_info, y))
continue;
- plane[i]->plane_read(stage_buffer, plane[i]->frame_info, y);
+ vkms_compose_row(stage_buffer, plane[i], y);
pre_mul_alpha_blend(plane[i]->frame_info, stage_buffer,
output_buffer);
}
@@ -118,7 +118,7 @@ static int check_format_funcs(struct vkms_crtc_state
*crtc_state,
u32 n_active_planes = crtc_state->num_active_planes;
for (size_t i = 0; i < n_active_planes; i++)
- if (!planes[i]->plane_read)
+ if (!planes[i]->pixel_read)
return -1;
if (active_wb && !active_wb->wb_write)
diff --git a/drivers/gpu/drm/vkms/vkms_drv.h b/drivers/gpu/drm/vkms/vkms_drv.h
index 4a248567efb2..f152d54baf76 100644
--- a/drivers/gpu/drm/vkms/vkms_drv.h
+++ b/drivers/gpu/drm/vkms/vkms_drv.h
@@ -56,8 +56,7 @@ struct vkms_writeback_job {
struct vkms_plane_state {
struct drm_shadow_plane_state base;
struct vkms_frame_info *frame_info;
- void (*plane_read)(struct line_buffer *buffer,
- const struct vkms_frame_info *frame_info, int y);
+ void (*pixel_read)(u8 *src_buffer, struct pixel_argb_u16 *out_pixel);
};
struct vkms_plane {
@@ -155,6 +154,7 @@ int vkms_verify_crc_source(struct drm_crtc *crtc, const
char *source_name,
/* Composer Support */
void vkms_composer_worker(struct work_struct *work);
void vkms_set_composer(struct vkms_output *out, bool enabled);
+void vkms_compose_row(struct line_buffer *stage_buffer, struct
vkms_plane_state *plane, int y);
/* Writeback */
int vkms_enable_writeback_connector(struct vkms_device *vkmsdev);
diff --git a/drivers/gpu/drm/vkms/vkms_formats.c
b/drivers/gpu/drm/vkms/vkms_formats.c
index d4950688b3f1..8d948c73741e 100644
--- a/drivers/gpu/drm/vkms/vkms_formats.c
+++ b/drivers/gpu/drm/vkms/vkms_formats.c
@@ -42,100 +42,75 @@ static void *get_packed_src_addr(const struct
vkms_frame_info *frame_info, int y
return packed_pixels_addr(frame_info, x_src, y_src);
}
-static void ARGB_to_argb_u16(struct line_buffer *stage_buffer,
-const struct vkms_frame_info *frame_info, int
y)
+static void ARGB_to_argb_u16(u8 *src_pixels, struct pixel_argb_u16
*out_pixel)
{
- struct pixel_argb_u16 *out_pixels = stage_buffer->pixels;
- u8 *src_pixels = get_packed_src_addr(frame_info, y);
- int x_limit = min_t(size_t, drm_rect_width(&frame_info->dst),
- stage_buffer->n_pixels);
-
- for (size_t x = 0; x < x_limit; x++, src_pixels += 4) {
- /*
-* The 257 is the "conversion ratio". This number is obtained
by the
-* (2^16 - 1) / (2^8 - 1) division. Which, in this case, tries
to get
-* the best color value in a pixel format with more
possibilities.
-* A similar idea applies to others RGB color conversions.
-*/
- out_pixels[x].a = (u16)src_pixels[3] * 257;
- out_pixels[x].r = (u16)src_pixels[2] * 257;
- out_pixels[x].g = (u16)src_pixels[1] * 257;
- out_pixels[x].b = (u16)src_pixels[0] * 257;
- }
+ /*
+* The 257 is the "conversion ratio". This number is obtained by the
+* (2^16 - 1) / (2^8 - 1) division. Which, in this case, tries to get
+* the best color value in a pixel format with more possibilities.
+* A similar idea applies to others RGB color conversions.
+*/
+ out_pixel->a = (u16)src_pixels[3] * 257;
+ out_pixel->r = (u16)src_pixels[2] * 257;
+ out_pixel->g = (u16)src_pixels[1] * 257;
+ out_pixel->b = (u16)src_pixels[0] * 257;
}
-static void XRGB_to_argb_u16(struct line_buffer *stage_buffer,
-
Re: [PATCH net-next 3/6] net: bcmasp: Add support for ASP2.0 Ethernet controller
On Wed, Apr 19, 2023 at 9:33 AM Florian Fainelli wrote:
>
> On 4/18/23 23:35, Heiner Kallweit wrote:
> > On 19.04.2023 02:10, Justin Chen wrote:
> >> Add support for the Broadcom ASP 2.0 Ethernet controller which is first
> >> introduced with 72165. This controller features two distinct Ethernet
> >> ports that can be independently operated.
> >>
> >> This patch supports:
> [snip]
> >> +intf->tx_spb_index = spb_index;
> >> +intf->tx_spb_dma_valid = valid;
> >> +bcmasp_intf_tx_write(intf, intf->tx_spb_dma_valid);
> >> +
> >> +if (tx_spb_ring_full(intf, MAX_SKB_FRAGS + 1))
> >> +netif_stop_queue(dev);
> >> +
> >
> > Here it may be better to use the new macros from
> > include/net/netdev_queues.h.
> > It seems your code (together with the related part in tx_poll) doesn't
> > consider
> > the queue restart case.
> > In addition you should check whether using READ_ONCE()/WRITE_ONCE() is
> > needed,
> > e.g. in ring_full().
>
> Thanks Heiner. Can you trim the parts you are not quoting otherwise one
> has to scroll all the way down to where you responded. Thanks!
> --
> Florian
>
Hello Heiner,
The implementation is a locked single queue xmit. Not sure how
netdev_queues.h fits into the picture here. I believe I am handling
the queue restart here.
+static int bcmasp_tx_poll(struct napi_struct *napi, int budget)
+{
[snip]
+ if (released)
+ netif_wake_queue(intf->ndev);
+
+ return 0;
+}
Let me know if I am misunderstanding the feedback here.
Thanks,
Justin
Re: [Freedreno] [PATCH v2 04/17] drm/msm/dpu: Fix PP_BLK_DIPHER -> DITHER typo
On 4/17/2023 1:21 PM, Marijn Suijten wrote:
SM8550 only comes with a DITHER subblock inside the PINGPONG block,
hence the name and a block length of zero. However, the PP_BLK macro
name was typo'd to DIPHER rather than DITHER.
Fixes: efcd0107727c ("drm/msm/dpu: add support for SM8550")
Signed-off-by: Marijn Suijten
This change itself is fine, hence
Reviewed-by: Abhinav Kumar
one comment below
---
drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_9_0_sm8550.h | 16
drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c | 2 +-
2 files changed, 9 insertions(+), 9 deletions(-)
diff --git a/drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_9_0_sm8550.h
b/drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_9_0_sm8550.h
index 9e403034093f..d0ab351b6a8b 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_9_0_sm8550.h
+++ b/drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_9_0_sm8550.h
@@ -132,28 +132,28 @@ static const struct dpu_dspp_cfg sm8550_dspp[] = {
&sm8150_dspp_sblk),
};
static const struct dpu_pingpong_cfg sm8550_pp[] = {
dither block should be present on many other chipsets too but looks like
on sm8550 was enabling it. Not sure how it was validated there. But we
are enabling dither, even other chipsets have this block.
- PP_BLK_DIPHER("pingpong_0", PINGPONG_0, 0x69000, MERGE_3D_0,
sc7280_pp_sblk,
+ PP_BLK_DITHER("pingpong_0", PINGPONG_0, 0x69000, MERGE_3D_0,
sc7280_pp_sblk,
DPU_IRQ_IDX(MDP_SSPP_TOP0_INTR, 8),
-1),
- PP_BLK_DIPHER("pingpong_1", PINGPONG_1, 0x6a000, MERGE_3D_0,
sc7280_pp_sblk,
+ PP_BLK_DITHER("pingpong_1", PINGPONG_1, 0x6a000, MERGE_3D_0,
sc7280_pp_sblk,
DPU_IRQ_IDX(MDP_SSPP_TOP0_INTR, 9),
-1),
- PP_BLK_DIPHER("pingpong_2", PINGPONG_2, 0x6b000, MERGE_3D_1,
sc7280_pp_sblk,
+ PP_BLK_DITHER("pingpong_2", PINGPONG_2, 0x6b000, MERGE_3D_1,
sc7280_pp_sblk,
DPU_IRQ_IDX(MDP_SSPP_TOP0_INTR, 10),
-1),
- PP_BLK_DIPHER("pingpong_3", PINGPONG_3, 0x6c000, MERGE_3D_1,
sc7280_pp_sblk,
+ PP_BLK_DITHER("pingpong_3", PINGPONG_3, 0x6c000, MERGE_3D_1,
sc7280_pp_sblk,
DPU_IRQ_IDX(MDP_SSPP_TOP0_INTR, 11),
-1),
- PP_BLK_DIPHER("pingpong_4", PINGPONG_4, 0x6d000, MERGE_3D_2,
sc7280_pp_sblk,
+ PP_BLK_DITHER("pingpong_4", PINGPONG_4, 0x6d000, MERGE_3D_2,
sc7280_pp_sblk,
DPU_IRQ_IDX(MDP_SSPP_TOP0_INTR2, 30),
-1),
- PP_BLK_DIPHER("pingpong_5", PINGPONG_5, 0x6e000, MERGE_3D_2,
sc7280_pp_sblk,
+ PP_BLK_DITHER("pingpong_5", PINGPONG_5, 0x6e000, MERGE_3D_2,
sc7280_pp_sblk,
DPU_IRQ_IDX(MDP_SSPP_TOP0_INTR2, 31),
-1),
- PP_BLK_DIPHER("pingpong_6", PINGPONG_6, 0x66000, MERGE_3D_3,
sc7280_pp_sblk,
+ PP_BLK_DITHER("pingpong_6", PINGPONG_6, 0x66000, MERGE_3D_3,
sc7280_pp_sblk,
-1,
-1),
- PP_BLK_DIPHER("pingpong_7", PINGPONG_7, 0x66400, MERGE_3D_3,
sc7280_pp_sblk,
+ PP_BLK_DITHER("pingpong_7", PINGPONG_7, 0x66400, MERGE_3D_3,
sc7280_pp_sblk,
-1,
-1),
};
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 03f162af1a50..ca8a02debda9 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c
@@ -491,7 +491,7 @@ static const struct dpu_pingpong_sub_blks sc7280_pp_sblk = {
.len = 0x20, .version = 0x2},
};
-#define PP_BLK_DIPHER(_name, _id, _base, _merge_3d, _sblk, _done, _rdptr) \
+#define PP_BLK_DITHER(_name, _id, _base, _merge_3d, _sblk, _done, _rdptr) \
{\
.name = _name, .id = _id, \
.base = _base, .len = 0, \
Re: [PATCH v2 03/17] drm/msm/dpu: Move non-MDP_TOP INTF_INTR offsets out of hwio header
On 4/17/2023 1:21 PM, Marijn Suijten wrote:
These offsets do not fall under the MDP TOP block and do not fit the
comment right above. Move them to dpu_hw_interrupts.c next to the
repsective MDP_INTF_x_OFF interrupt block offsets.
Fixes: 25fdd5933e4c ("drm/msm: Add SDM845 DPU support")
Signed-off-by: Marijn Suijten
This change itself is fine, hence
Reviewed-by: Abhinav Kumar
One comment below.
---
drivers/gpu/drm/msm/disp/dpu1/dpu_hw_interrupts.c | 5 -
drivers/gpu/drm/msm/disp/dpu1/dpu_hwio.h | 3 ---
2 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_interrupts.c
b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_interrupts.c
index 53326f25e40e..85c0bda3ff90 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_interrupts.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_interrupts.c
@@ -15,7 +15,7 @@
/*
* Register offsets in MDSS register file for the interrupt registers
- * w.r.t. to the MDP base
+ * w.r.t. the MDP base
*/
#define MDP_SSPP_TOP0_OFF 0x0
#define MDP_INTF_0_OFF0x6A000
@@ -24,6 +24,9 @@
#define MDP_INTF_3_OFF0x6B800
#define MDP_INTF_4_OFF0x6C000
#define MDP_INTF_5_OFF0x6C800
+#define INTF_INTR_EN 0x1c0
+#define INTF_INTR_STATUS 0x1c4
+#define INTF_INTR_CLEAR0x1c8
#define MDP_AD4_0_OFF 0x7C000
#define MDP_AD4_1_OFF 0x7D000
#define MDP_AD4_INTR_EN_OFF 0x41c
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_hwio.h
b/drivers/gpu/drm/msm/disp/dpu1/dpu_hwio.h
index feb9a729844a..5acd5683d25a 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_hwio.h
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_hwio.h
@@ -21,9 +21,6 @@
#define HIST_INTR_EN0x01c
#define HIST_INTR_STATUS0x020
#define HIST_INTR_CLEAR 0x024
Even HIST_INTR_*** need to be moved then.
-#define INTF_INTR_EN0x1C0
-#define INTF_INTR_STATUS0x1C4
-#define INTF_INTR_CLEAR 0x1C8
#define SPLIT_DISPLAY_EN0x2F4
#define SPLIT_DISPLAY_UPPER_PIPE_CTRL 0x2F8
#define DSPP_IGC_COLOR0_RAM_LUTN0x300
Re: [PATCH v2 1/2] phy: mediatek: hdmi: mt8195: fix uninitialized variable usage in pll_calc
On Fri, Apr 21, 2023 at 3:13 PM Nathan Chancellor wrote:
>
> On Fri, Apr 14, 2023 at 06:07:46PM +0200, Guillaume Ranquet wrote:
> > The ret variable in mtk_hdmi_pll_calc() was used unitialized as reported
> > by the kernel test robot.
> >
> > Fix the issue by removing the variable altogether and testing out the
> > return value of mtk_hdmi_pll_set_hw()
> >
> > Fixes: 45810d486bb44 ("phy: mediatek: add support for phy-mtk-hdmi-mt8195")
> > Reported-by: kernel test robot
> > Signed-off-by: Guillaume Ranquet
>
> Reviewed-by: Nathan Chancellor
>
> Can somebody pick this up? It fixes a rather obvious warning, which is
> breaking clang builds (as evidenced by three versions of the same fix).
$ ./scripts/get_maintainer.pl -f
drivers/phy/mediatek/phy-mtk-hdmi-mt8195.c | grep maintainer
Chunfeng Yun (maintainer:ARM/Mediatek USB3
PHY DRIVER)
Matthias Brugger (maintainer:ARM/Mediatek SoC support)
Chunfeng, Matthias, can one of you pick this up, please?
Or Vinod who merged 45810d486bb44 FWICT?
>
> > ---
> > drivers/phy/mediatek/phy-mtk-hdmi-mt8195.c | 8 ++--
> > 1 file changed, 2 insertions(+), 6 deletions(-)
> >
> > diff --git a/drivers/phy/mediatek/phy-mtk-hdmi-mt8195.c
> > b/drivers/phy/mediatek/phy-mtk-hdmi-mt8195.c
> > index abfc077fb0a8..054b73cb31ee 100644
> > --- a/drivers/phy/mediatek/phy-mtk-hdmi-mt8195.c
> > +++ b/drivers/phy/mediatek/phy-mtk-hdmi-mt8195.c
> > @@ -213,7 +213,7 @@ static int mtk_hdmi_pll_calc(struct mtk_hdmi_phy
> > *hdmi_phy, struct clk_hw *hw,
> > u64 tmds_clk, pixel_clk, da_hdmitx21_ref_ck, ns_hdmipll_ck, pcw;
> > u8 txpredivs[4] = { 2, 4, 6, 12 };
> > u32 fbkdiv_low;
> > - int i, ret;
> > + int i;
> >
> > pixel_clk = rate;
> > tmds_clk = pixel_clk;
> > @@ -292,13 +292,9 @@ static int mtk_hdmi_pll_calc(struct mtk_hdmi_phy
> > *hdmi_phy, struct clk_hw *hw,
> > if (!(digital_div <= 32 && digital_div >= 1))
> > return -EINVAL;
> >
> > - mtk_hdmi_pll_set_hw(hw, PLL_PREDIV, fbkdiv_high, fbkdiv_low,
> > + return mtk_hdmi_pll_set_hw(hw, PLL_PREDIV, fbkdiv_high, fbkdiv_low,
> > PLL_FBKDIV_HS3, posdiv1, posdiv2, txprediv,
> > txposdiv, digital_div);
> > - if (ret)
> > - return -EINVAL;
> > -
> > - return 0;
> > }
> >
> > static int mtk_hdmi_pll_drv_setting(struct clk_hw *hw)
> >
> > --
> > 2.40.0
> >
>
--
Thanks,
~Nick Desaulniers
Re: [PATCH v2 02/17] drm/msm/dpu: Remove TE2 block and feature from DPU >= 7.0.0 hardware
On 4/17/2023 1:21 PM, Marijn Suijten wrote:
No hardware beyond kona (sm8250) defines the TE2 PINGPONG sub-block
offset downstream. Even though neither downstream nor upstream utilizes
these registers in any way, remove the erroneous specification for
SC8280XP, SM8350 and SM8450 to prevent confusion.
Note that downstream enables the PPSPLIT (split-FIFO) topology (single
LM for 2 PP and 2 INTF) based on the presence of a TE2 block.
Fixes: f0a1bdf64dd7 ("drm/msm/dpu: Introduce SC8280XP")
Fixes: 0a72f23f6ef8 ("drm/msm/dpu: Add SM8350 to hw catalog")
Fixes: 8cbbc3396065 ("drm/msm/dpu: add support for SM8450")
I cannot find any commits with those hashes.
Should this be
Fixes: 4a352c2fc15a ("drm/msm/dpu: Introduce SC8280XP")
Fixes: 0e91bcbb0016 ("drm/msm/dpu: Add SM8350 to hw catalog")
Fixes: 100d7ef6995d ("drm/msm/dpu: add support for SM8450")
Will wait for a day to fix this up, otherwise I will do it while applying.
Signed-off-by: Marijn Suijten
---
drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_7_0_sm8350.h | 4 ++--
drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_8_0_sc8280xp.h | 12 ++--
drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_8_1_sm8450.h | 4 ++--
3 files changed, 10 insertions(+), 10 deletions(-)
diff --git a/drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_7_0_sm8350.h
b/drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_7_0_sm8350.h
index ca107ca8de46..41ef0c8fc993 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_7_0_sm8350.h
+++ b/drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_7_0_sm8350.h
@@ -127,10 +127,10 @@ static const struct dpu_dspp_cfg sm8350_dspp[] = {
};
static const struct dpu_pingpong_cfg sm8350_pp[] = {
- PP_BLK_TE("pingpong_0", PINGPONG_0, 0x69000, MERGE_3D_0,
sdm845_pp_sblk_te,
+ PP_BLK("pingpong_0", PINGPONG_0, 0x69000, MERGE_3D_0, sdm845_pp_sblk,
DPU_IRQ_IDX(MDP_SSPP_TOP0_INTR, 8),
DPU_IRQ_IDX(MDP_SSPP_TOP0_INTR, 12)),
- PP_BLK_TE("pingpong_1", PINGPONG_1, 0x6a000, MERGE_3D_0,
sdm845_pp_sblk_te,
+ PP_BLK("pingpong_1", PINGPONG_1, 0x6a000, MERGE_3D_0, sdm845_pp_sblk,
DPU_IRQ_IDX(MDP_SSPP_TOP0_INTR, 9),
DPU_IRQ_IDX(MDP_SSPP_TOP0_INTR, 13)),
PP_BLK("pingpong_2", PINGPONG_2, 0x6b000, MERGE_3D_1, sdm845_pp_sblk,
diff --git a/drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_8_0_sc8280xp.h
b/drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_8_0_sc8280xp.h
index 9aab110b8c44..12c14d15e386 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_8_0_sc8280xp.h
+++ b/drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_8_0_sc8280xp.h
@@ -121,17 +121,17 @@ static const struct dpu_dspp_cfg sc8280xp_dspp[] = {
};
static const struct dpu_pingpong_cfg sc8280xp_pp[] = {
- PP_BLK_TE("pingpong_0", PINGPONG_0, 0x69000, MERGE_3D_0,
sdm845_pp_sblk_te,
+ PP_BLK("pingpong_0", PINGPONG_0, 0x69000, MERGE_3D_0, sdm845_pp_sblk,
DPU_IRQ_IDX(MDP_SSPP_TOP0_INTR, 8), -1),
- PP_BLK_TE("pingpong_1", PINGPONG_1, 0x6a000, MERGE_3D_0,
sdm845_pp_sblk_te,
+ PP_BLK("pingpong_1", PINGPONG_1, 0x6a000, MERGE_3D_0, sdm845_pp_sblk,
DPU_IRQ_IDX(MDP_SSPP_TOP0_INTR, 9), -1),
- PP_BLK_TE("pingpong_2", PINGPONG_2, 0x6b000, MERGE_3D_1,
sdm845_pp_sblk_te,
+ PP_BLK("pingpong_2", PINGPONG_2, 0x6b000, MERGE_3D_1, sdm845_pp_sblk,
DPU_IRQ_IDX(MDP_SSPP_TOP0_INTR, 10), -1),
- PP_BLK_TE("pingpong_3", PINGPONG_3, 0x6c000, MERGE_3D_1,
sdm845_pp_sblk_te,
+ PP_BLK("pingpong_3", PINGPONG_3, 0x6c000, MERGE_3D_1, sdm845_pp_sblk,
DPU_IRQ_IDX(MDP_SSPP_TOP0_INTR, 11), -1),
- PP_BLK_TE("pingpong_4", PINGPONG_4, 0x6d000, MERGE_3D_2,
sdm845_pp_sblk_te,
+ PP_BLK("pingpong_4", PINGPONG_4, 0x6d000, MERGE_3D_2, sdm845_pp_sblk,
DPU_IRQ_IDX(MDP_SSPP_TOP0_INTR2, 30), -1),
- PP_BLK_TE("pingpong_5", PINGPONG_5, 0x6e000, MERGE_3D_2,
sdm845_pp_sblk_te,
+ PP_BLK("pingpong_5", PINGPONG_5, 0x6e000, MERGE_3D_2, sdm845_pp_sblk,
DPU_IRQ_IDX(MDP_SSPP_TOP0_INTR2, 31), -1),
};
diff --git a/drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_8_1_sm8450.h b/drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_8_1_sm8450.h
index 02a259b6b426..e409c119b0a2 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_8_1_sm8450.h
+++ b/drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_8_1_sm8450.h
@@ -128,10 +128,10 @@ static const struct dpu_dspp_cfg sm8450_dspp[] = {
};
/* FIXME: interrupts */
static const struct dpu_pingpong_cfg sm8450_pp[] = {
- PP_BLK_TE("pingpong_0", PINGPONG_0, 0x69000, MERGE_3D_0,
sdm845_pp_sblk_te,
+ PP_BLK("pingpong_0", PINGPONG_0, 0x69000, MERGE_3D_0, sdm845_pp_sblk,
DPU_IRQ_IDX(MDP_SSPP_TOP0_INTR, 8),
DPU_IRQ_IDX(MDP_SSPP_TOP0_INTR, 12)),
- PP_BLK_TE("pingpong_1", PINGPONG_1, 0x6a000, MERGE_3D_0,
sdm845_pp_sblk_te,
+ PP_BLK("pingpong_1", PINGPONG_1, 0x6a000, MERGE_3D_0, sdm845_pp_sblk,
Re: [PATCH] drm/amd/display: Fix a test dml32_rq_dlg_get_rq_reg()
On 4/17/23 17:41, Christophe JAILLET wrote:
It is likely p1_min_meta_chunk_bytes was expected here, instead of
min_meta_chunk_bytes.
Test the correct variable.
Fixes: dda4fb85e433 ("drm/amd/display: DML changes for DCN32/321")
Signed-off-by: Christophe JAILLET
Applied, thanks!
---
.../gpu/drm/amd/display/dc/dml/dcn32/display_rq_dlg_calc_32.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/amd/display/dc/dml/dcn32/display_rq_dlg_calc_32.c
b/drivers/gpu/drm/amd/display/dc/dml/dcn32/display_rq_dlg_calc_32.c
index 395ae8761980..9ba6cb67655f 100644
--- a/drivers/gpu/drm/amd/display/dc/dml/dcn32/display_rq_dlg_calc_32.c
+++ b/drivers/gpu/drm/amd/display/dc/dml/dcn32/display_rq_dlg_calc_32.c
@@ -116,7 +116,7 @@ void dml32_rq_dlg_get_rq_reg(display_rq_regs_st *rq_regs,
else
rq_regs->rq_regs_l.min_meta_chunk_size =
dml_log2(min_meta_chunk_bytes) - 6 + 1;
- if (min_meta_chunk_bytes == 0)
+ if (p1_min_meta_chunk_bytes == 0)
rq_regs->rq_regs_c.min_meta_chunk_size = 0;
else
rq_regs->rq_regs_c.min_meta_chunk_size =
dml_log2(p1_min_meta_chunk_bytes) - 6 + 1;
--
Hamza
Re: [PATCH] drm/amd/display: Fix a test CalculatePrefetchSchedule()
On 4/17/23 17:35, Christophe JAILLET wrote:
It is likely Height was expected here, instead of Width.
Test the correct variable.
Fixes: 17529ea2acfa ("drm/amd/display: Optimizations for DML math")
Signed-off-by: Christophe JAILLET
Applied, thanks!
---
drivers/gpu/drm/amd/display/dc/dml/dcn21/display_mode_vba_21.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/amd/display/dc/dml/dcn21/display_mode_vba_21.c
b/drivers/gpu/drm/amd/display/dc/dml/dcn21/display_mode_vba_21.c
index b7c2844d0cbe..f294f2f8c75b 100644
--- a/drivers/gpu/drm/amd/display/dc/dml/dcn21/display_mode_vba_21.c
+++ b/drivers/gpu/drm/amd/display/dc/dml/dcn21/display_mode_vba_21.c
@@ -810,7 +810,7 @@ static bool CalculatePrefetchSchedule(
*swath_width_chroma_ub = dml_ceil(SwathWidthY / 2 - 1,
myPipe->BlockWidth256BytesC) + myPipe->BlockWidth256BytesC;
} else {
*swath_width_luma_ub = dml_ceil(SwathWidthY - 1,
myPipe->BlockHeight256BytesY) + myPipe->BlockHeight256BytesY;
- if (myPipe->BlockWidth256BytesC > 0)
+ if (myPipe->BlockHeight256BytesC > 0)
*swath_width_chroma_ub = dml_ceil(SwathWidthY / 2 - 1,
myPipe->BlockHeight256BytesC) + myPipe->BlockHeight256BytesC;
}
--
Hamza
Re: [PATCH v5 0/5] Create tests for the drm_rect functions
On 4/18/23 20:01, Arthur Grillo wrote: This patchset seeks to add unit tests for the rest of the functions on the drm_rect.c. The test coverage report generated by the gcov[1] tool states that this set reaches 100% of coverage on the drm_rect.c file. This would be very good for future development on the file. If you want to see the coverage report, I uploaded on the link below: https://grillo-0.github.io/coverage-reports/more-rect-tests/drivers/gpu/drm/drm_rect.c.gcov.html Thanks for reviewing! Best regards, ~Arthur Grillo I just applied the series to drm/drm-misc (drm-misc-next). Thanks for improving the tests! Best Regards, - Maíra Canal --- v1->v2: https://lore.kernel.org/all/20230322140701.69852-1-arthurgri...@riseup.net/ - Create parameterized tests for drm_rect_intersect(). - Use .16 binary fixed point values on the drm_rect_calc_hscale() and drm_rect_calc_vscale() tests. - Replace INT_MIN for 0 on the on the drm_rect_calc_hscale() and drm_rect_calc_vscale() tests. - Assign nonzero values to the width and height parameters of the drm_rect_rotate() and drm_rect_rotate_inv() tests. - Switch memcpy to a simple variable assignment on the drm_rect_rotate() and drm_rect_rotate_inv() tests. v2->v3: https://lore.kernel.org/all/20230327133848.5250-1-arthurgri...@riseup.net/ - Change "x" to lowercase on the drm_rect_intersect() cases. - Remove the option for no description on the drm_rect_intersect() cases. - Add a test for rects with zero height and width on the drm_rect_intersect(). - Switch to parameterized tests for drm_rect_calc_hscale() and drm_rect_calc_vscale(). - Add a test for a dst drm_rect with zero width for drm_rect_calc_hscale() and zero height for drm_rect_calc_vscale(). - Place an "-" on the drm_rect_rotate case names to match the userspace. - s/drm_rect_case_desc/drm_rect_rotate_case_desc/ - Improve the commit messages. v3->v4: https://lore.kernel.org/all/20230404184158.26290-1-arthurgri...@riseup.net/ - Place parenthesis around .16 fixed point values before making it negative to avoid error when generating tests coverages. v4->v5: https://lore.kernel.org/all/20230406115338.36228-1-arthurgri...@riseup.net/ - Use the same parameters for drm_rect_calc_hscale() and drm_rect_calc_vscale() by scaling both sides at the same time. - Place nonzero values for .x1 and .y1 on the drm_rect_rotate() test cases. --- [1]: https://gcc.gnu.org/onlinedocs/gcc/Gcov.html#Gcov --- Arthur Grillo (5): drm/tests: Add test cases for drm_rect_intersect() drm/tests: Add test cases for drm_rect_calc_hscale() drm/tests: Add test cases for drm_rect_calc_vscale() drm/tests: Add test cases for drm_rect_rotate() drm/test: Add test cases for drm_rect_rotate_inv() drivers/gpu/drm/tests/drm_rect_test.c | 315 ++ 1 file changed, 315 insertions(+)
RE: [Intel-gfx] [PATCH 0/8] drm/i915/mtl: Define MOCS and PAT tables for MTL
On 2023-04-16 23:43:20, Yang, Fei wrote: > > fei.y...@intel.com kirjoitti 17.4.2023 klo 9.24: > >> From: Fei Yang > >> > >> The series includes patches needed to enable MTL. > >> Also add new extension for GEM_CREATE uAPI to let user space set cache > >> policy for buffer objects. > > > > if I'm counting right, this would be version 5 of the series, yet > > that is not shown anywhere nor the changes between series.. > > Yes, mostly addressing minor issues, just want to keep the commit > message clean as it's the enablement patch set for new platform. One thing that could help is to use the --subject-prefix parameter to git format-patch so "PATCH v5" would be in the subject of the emails. Additionally, it's helpful to include full a version history in the cover-letter (0/8) patch so it's clear what has changed in each version of the patches sent out. -Jordan
Re: [Intel-gfx] [PATCH 3/8] drm/i915/mtl: Add PTE encode function
> On Sun, Apr 23, 2023 at 12:37:27AM -0700, Yang, Fei wrote:
>>> On Fri, Apr 21, 2023 at 10:27:22AM -0700, Yang, Fei wrote:
> On Wed, Apr 19, 2023 at 04:00:53PM -0700, fei.y...@intel.com wrote:
>> From: Fei Yang
>>
>> PTE encode functions are platform dependent. This patch implements
>> PTE functions for MTL, and ensures the correct PTE encode function
>> is used by calling pte_encode function pointer instead of the
>> hardcoded gen8 version of PTE encode.
>>
>> Signed-off-by: Fei Yang
>> Reviewed-by: Andrzej Hajda
>> Reviewed-by: Andi Shyti
>> Acked-by: Nirmoy Das
>
> Bspec: 45015, 45040
>
>> ---
>> drivers/gpu/drm/i915/display/intel_dpt.c | 2 +-
>> drivers/gpu/drm/i915/gt/gen8_ppgtt.c | 45
>> drivers/gpu/drm/i915/gt/intel_ggtt.c | 36 +--
>> 3 files changed, 72 insertions(+), 11 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/i915/display/intel_dpt.c
b/drivers/gpu/drm/i915/display/intel_dpt.c
>> index b8027392144d..c5eacfdba1a5 100644
>> --- a/drivers/gpu/drm/i915/display/intel_dpt.c
>> +++ b/drivers/gpu/drm/i915/display/intel_dpt.c
>> @@ -300,7 +300,7 @@ intel_dpt_create(struct intel_framebuffer *fb)
>>vm->vma_ops.bind_vma= dpt_bind_vma;
>>vm->vma_ops.unbind_vma = dpt_unbind_vma;
>>
>> - vm->pte_encode = gen8_ggtt_pte_encode;
>> + vm->pte_encode = vm->gt->ggtt->vm.pte_encode;
>>
>>dpt->obj = dpt_obj;
>>dpt->obj->is_dpt = true;
>> diff --git a/drivers/gpu/drm/i915/gt/gen8_ppgtt.c
>> b/drivers/gpu/drm/i915/gt/gen8_ppgtt.c
>> index 4daaa6f55668..11b91e0453c8 100644
>> --- a/drivers/gpu/drm/i915/gt/gen8_ppgtt.c
>> +++ b/drivers/gpu/drm/i915/gt/gen8_ppgtt.c
>> @@ -55,6 +55,34 @@ static u64 gen8_pte_encode(dma_addr_t addr,
>>return pte;
>> }
>>
>> +static u64 mtl_pte_encode(dma_addr_t addr,
>> + enum i915_cache_level level,
>> + u32 flags)
>> +{
>> + gen8_pte_t pte = addr | GEN8_PAGE_PRESENT | GEN8_PAGE_RW;
>> +
>> + if (unlikely(flags & PTE_READ_ONLY))
>> + pte &= ~GEN8_PAGE_RW;
>> +
>> + if (flags & PTE_LM)
>> + pte |= GEN12_PPGTT_PTE_LM | GEN12_PPGTT_PTE_NC;
>
> GEN12_PPGTT_PTE_NC got defined in the previous patch as BIT(5). But
> according to bspec 45040, bit 5 is ignored in the PTE encoding. What is
> this trying to do?
This takes effect only for PTE_LM, doesn't affect MTL.
PTE_NC is needed for PVC (use of access counter).
I believe this function was writen based on the one for PVC. And this
function did get extended to cover all gen12 in a later patch.
>>>
>>> Even though MTL doesn't have local memory, PTE_LM is supposed to be
>>> used on MTL for access to BAR2 stolen memory.
>>
>> You were right, but I still think this code is fine because this bit is
>> ignored for MTL anyway and it is needed for other platforms with LMEM.
>> Otherwise this code would have some sort of platform checking which is
>> hard to do because we don't have platform info here.
>> Or we would have to define another PTE encode function for platforms
>> needing PTE_NC just for this one difference, then manage the function
>> pointer correctly.
>
> MTL is the only platform that uses this function right now:
>
> + if (GRAPHICS_VER_FULL(gt->i915) >= IP_VER(12, 70))
> + ppgtt->vm.pte_encode = mtl_pte_encode;
> + else
> + ppgtt->vm.pte_encode = gen8_pte_encode;
>
> If this is intended for PVC, then you have it in the wrong function to
> begin with (and it also shouldn't be in a patch labelled "mtl"). If
> you're trying to future-proof for some post-MTL discrete platform, then
> such code should be saved until we enable that platform so that it can
> be properly reviewed.
dropped GEN12_PPGTT_PTE_NC bit in v2 of
https://patchwork.freedesktop.org/series/116900/
> Matt
>
>>
>> -Fei
>>
>>> Matt
>>>
-Fei
> Matt
>
>> +
>> + switch (level) {
>> + case I915_CACHE_NONE:
>> + pte |= GEN12_PPGTT_PTE_PAT1;
>> + break;
Re: [PATCH v6 0/3] Add sync object UAPI support to VirtIO-GPU driver
On Wed, Apr 19, 2023 at 2:22 PM Dmitry Osipenko wrote: > > Hello Gurchetan, > > On 4/18/23 02:17, Gurchetan Singh wrote: > > On Sun, Apr 16, 2023 at 4:53 AM Dmitry Osipenko < > > dmitry.osipe...@collabora.com> wrote: > > > >> We have multiple Vulkan context types that are awaiting for the addition > >> of the sync object DRM UAPI support to the VirtIO-GPU kernel driver: > >> > >> 1. Venus context > >> 2. Native contexts (virtio-freedreno, virtio-intel, virtio-amdgpu) > >> > >> Mesa core supports DRM sync object UAPI, providing Vulkan drivers with a > >> generic fencing implementation that we want to utilize. > >> > >> This patch adds initial sync objects support. It creates fundament for a > >> further fencing improvements. Later on we will want to extend the > >> VirtIO-GPU > >> fencing API with passing fence IDs to host for waiting, it will be a new > >> additional VirtIO-GPU IOCTL and more. Today we have several VirtIO-GPU > >> context > >> drivers in works that require VirtIO-GPU to support sync objects UAPI. > >> > >> The patch is heavily inspired by the sync object UAPI implementation of the > >> MSM driver. > >> > > > > The changes seem good, but I would recommend getting a full end-to-end > > solution (i.e, you've proxied the host fence with these changes and shared > > with the host compositor) working first. You'll never know what you'll > > find after completing this exercise. Or is that the plan already? > > > > Typically, you want to land the uAPI and virtio spec changes last. > > Mesa/gfxstream/virglrenderer/crosvm all have the ability to test out > > unstable uAPIs ... > > The proxied host fence isn't directly related to sync objects, though I > prepared code such that it could be extended with a proxied fence later > on, based on a prototype that was made some time ago. Proxying the host fence is the novel bit. If you have code that does this, you should rebase/send that out (even as an RFC) so it's easier to see how the pieces fit. Right now, if you've only tested synchronization objects between the same virtio-gpu context that skips the guest side wait, I think you can already do that with the current uAPI (since ideally you'd wait on the host side and can encode the sync resource in the command stream). Also, try to come with a simple test (so we can meet requirements here [a]) that showcases the new feature/capability. An example would be the virtio-intel native context sharing a fence with KMS or even Wayland. [a] https://dri.freedesktop.org/docs/drm/gpu/drm-uapi.html#open-source-userspace-requirements > > The proxied host fence shouldn't require UAPI changes, but only > virtio-gpu proto extension. Normally, all in-fences belong to a job's > context, and thus, waits are skipped by the guest kernel. Hence, fence > proxying is a separate feature from sync objects, it can be added > without sync objects. > > Sync objects primarily wanted by native context drivers because Mesa > relies on the sync object UAPI presence. It's one of direct blockers for > Intel and AMDGPU drivers, both of which has been using this sync object > UAPI for a few months and now wanting it to land upstream. > > -- > Best regards, > Dmitry >
Re: [PATCH v8 4/5] drm: Add RZ/G2L DU Support
Hi Biju,
On Mon, Apr 24, 2023 at 05:10:23PM +0100, Biju Das wrote:
> The LCD controller is composed of Frame Compression Processor (FCPVD),
> Video Signal Processor (VSPD), and Display Unit (DU).
>
> It has DPI/DSI interfaces and supports a maximum resolution of 1080p
> along with 2 RPFs to support the blending of two picture layers and
> raster operations (ROPs).
>
> The DU module is connected to VSPD. Add RZ/G2L DU support for RZ/G2L
> alike SoCs.
>
> Signed-off-by: Biju Das
[...]
> diff --git a/drivers/gpu/drm/renesas/rz-du/rzg2l_du_crtc.c
> b/drivers/gpu/drm/renesas/rz-du/rzg2l_du_crtc.c
> new file mode 100644
> index ..af877d0dadc2
> --- /dev/null
> +++ b/drivers/gpu/drm/renesas/rz-du/rzg2l_du_crtc.c
> @@ -0,0 +1,716 @@
[...]
> +static int rzg2l_du_crtc_get(struct rzg2l_du_crtc *rcrtc)
> +{
> + int ret;
> +
> + /*
> + * Guard against double-get, as the function is called from both the
> + * .atomic_enable() and .atomic_begin() handlers.
> + */
> + if (rcrtc->initialized)
> + return 0;
> +
> + ret = clk_prepare_enable(rcrtc->rzg2l_clocks.aclk);
> + if (ret < 0)
> + return ret;
> +
> + ret = clk_prepare_enable(rcrtc->rzg2l_clocks.pclk);
> + if (ret < 0)
> + goto error_clock;
> +
> + ret = reset_control_deassert(rcrtc->rstc);
> + if (ret < 0)
> + goto error_reset;
> +
> + rzg2l_du_crtc_setup(rcrtc);
> + rcrtc->initialized = true;
> +
> + return 0;
> +
> +error_reset:
> + reset_control_assert(rcrtc->rstc);
If deassertion did not succeed, there is no need to assert.
Worse, for shared reset controls this messes up the deassert_count.
You can just drop the reset_control_assert() here.
regards
Philipp
Re: [PATCH v3 29/65] clk: socfpga: gate: Add a determine_rate hook
Hi Maxime,
On 4/4/23 05:11, Maxime Ripard wrote:
The SoCFGPA gate clock implements a mux with a set_parent hook, but
doesn't provide a determine_rate implementation.
This is a bit odd, since set_parent() is there to, as its name implies,
change the parent of a clock. However, the most likely candidate to
trigger that parent change is a call to clk_set_rate(), with
determine_rate() figuring out which parent is the best suited for a
given rate.
The other trigger would be a call to clk_set_parent(), but it's far less
used, and it doesn't look like there's any obvious user for that clock.
So, the set_parent hook is effectively unused, possibly because of an
oversight. However, it could also be an explicit decision by the
original author to avoid any reparenting but through an explicit call to
clk_set_parent().
The latter case would be equivalent to setting the flag
CLK_SET_RATE_NO_REPARENT, together with setting our determine_rate hook
to __clk_mux_determine_rate(). Indeed, if no determine_rate
implementation is provided, clk_round_rate() (through
clk_core_round_rate_nolock()) will call itself on the parent if
CLK_SET_RATE_PARENT is set, and will not change the clock rate
otherwise. __clk_mux_determine_rate() has the exact same behavior when
CLK_SET_RATE_NO_REPARENT is set.
And if it was an oversight, then we are at least explicit about our
behavior now and it can be further refined down the line.
Signed-off-by: Maxime Ripard
---
drivers/clk/socfpga/clk-gate.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/clk/socfpga/clk-gate.c b/drivers/clk/socfpga/clk-gate.c
index 32ccda960f28..cbba8462a09e 100644
--- a/drivers/clk/socfpga/clk-gate.c
+++ b/drivers/clk/socfpga/clk-gate.c
@@ -110,6 +110,7 @@ static unsigned long socfpga_clk_recalc_rate(struct clk_hw
*hwclk,
static struct clk_ops gateclk_ops = {
.recalc_rate = socfpga_clk_recalc_rate,
+ .determine_rate = __clk_mux_determine_rate,
.get_parent = socfpga_clk_get_parent,
.set_parent = socfpga_clk_set_parent,
};
@@ -166,7 +167,7 @@ void __init socfpga_gate_init(struct device_node *node)
init.name = clk_name;
init.ops = ops;
- init.flags = 0;
+ init.flags = CLK_SET_RATE_NO_REPARENT;
init.num_parents = of_clk_parent_fill(node, parent_name, SOCFPGA_MAX_PARENTS);
if (init.num_parents < 2) {
This patch broke SoCFPGA boot serial port. The characters are mangled.
Dinh
[PATCH v2 2/2] drm/i915/mtl: workaround coherency issue for Media
From: Fei Yang
This patch implements Wa_22016122933.
In MTL, memory writes initiated by the Media tile update the whole
cache line, even for partial writes. This creates a coherency
problem for cacheable memory if both CPU and GPU are writing data
to different locations within a single cache line.
This patch circumvents the issue by making CPU/GPU shared memory
uncacheable (WC on CPU side, and PAT index 2 for GPU). Additionally,
it ensures that CPU writes are visible to the GPU with an
intel_guc_write_barrier().
While fixing the CTB issue, we noticed some random GSC firmware
loading failure because the share buffers are cacheable (WB) on CPU
side but uncached on GPU side. To fix these issues we need to map
such shared buffers as WC on CPU side. Since such allocations are
not all done through GuC allocator, to avoid too many code changes,
the i915_coherent_map_type() is now hard coded to return WC for MTL.
v2: Simplify the commit message(Matt).
BSpec: 45101
Signed-off-by: Fei Yang
Reviewed-by: Andi Shyti
Acked-by: Nirmoy Das
Reviewed-by: Andrzej Hajda
Reviewed-by: Matt Roper
Signed-off-by: Nirmoy Das
---
drivers/gpu/drm/i915/gem/i915_gem_pages.c | 5 -
drivers/gpu/drm/i915/gt/uc/intel_gsc_fw.c | 13 +
drivers/gpu/drm/i915/gt/uc/intel_guc.c| 7 +++
drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c | 6 ++
4 files changed, 30 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_pages.c
b/drivers/gpu/drm/i915/gem/i915_gem_pages.c
index ecd86130b74f..89fc8ea6bcfc 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_pages.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_pages.c
@@ -469,7 +469,10 @@ enum i915_map_type i915_coherent_map_type(struct
drm_i915_private *i915,
struct drm_i915_gem_object *obj,
bool always_coherent)
{
- if (i915_gem_object_is_lmem(obj))
+ /*
+* Wa_22016122933: always return I915_MAP_WC for MTL
+*/
+ if (i915_gem_object_is_lmem(obj) || IS_METEORLAKE(i915))
return I915_MAP_WC;
if (HAS_LLC(i915) || always_coherent)
return I915_MAP_WB;
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_gsc_fw.c
b/drivers/gpu/drm/i915/gt/uc/intel_gsc_fw.c
index 1d9fdfb11268..236673c02f9a 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_gsc_fw.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_gsc_fw.c
@@ -110,6 +110,13 @@ static int gsc_fw_load_prepare(struct intel_gsc_uc *gsc)
if (obj->base.size < gsc->fw.size)
return -ENOSPC;
+ /*
+* Wa_22016122933: For MTL the shared memory needs to be mapped
+* as WC on CPU side and UC (PAT index 2) on GPU side
+*/
+ if (IS_METEORLAKE(i915))
+ i915_gem_object_set_cache_coherency(obj, I915_CACHE_NONE);
+
dst = i915_gem_object_pin_map_unlocked(obj,
i915_coherent_map_type(i915,
obj, true));
if (IS_ERR(dst))
@@ -125,6 +132,12 @@ static int gsc_fw_load_prepare(struct intel_gsc_uc *gsc)
memset(dst, 0, obj->base.size);
memcpy(dst, src, gsc->fw.size);
+ /*
+* Wa_22016122933: Making sure the data in dst is
+* visible to GSC right away
+*/
+ intel_guc_write_barrier(>->uc.guc);
+
i915_gem_object_unpin_map(gsc->fw.obj);
i915_gem_object_unpin_map(obj);
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc.c
b/drivers/gpu/drm/i915/gt/uc/intel_guc.c
index e89f16ecf1ae..c9f20385f6a0 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_guc.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_guc.c
@@ -744,6 +744,13 @@ struct i915_vma *intel_guc_allocate_vma(struct intel_guc
*guc, u32 size)
if (IS_ERR(obj))
return ERR_CAST(obj);
+ /*
+* Wa_22016122933: For MTL the shared memory needs to be mapped
+* as WC on CPU side and UC (PAT index 2) on GPU side
+*/
+ if (IS_METEORLAKE(gt->i915))
+ i915_gem_object_set_cache_coherency(obj, I915_CACHE_NONE);
+
vma = i915_vma_instance(obj, >->ggtt->vm, NULL);
if (IS_ERR(vma))
goto err;
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c
b/drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c
index 1803a633ed64..99a0a89091e7 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c
@@ -902,6 +902,12 @@ static int ct_read(struct intel_guc_ct *ct, struct
ct_incoming_msg **msg)
/* now update descriptor */
WRITE_ONCE(desc->head, head);
+ /*
+* Wa_22016122933: Making sure the head update is
+* visible to GuC right away
+*/
+ intel_guc_write_barrier(ct_to_guc(ct));
+
return available - len;
corrupted:
--
2.25.1
[PATCH v2 0/2] drm/i915/mtl: Add PTE encode functions
From: Fei Yang Extract PTE patch from https://patchwork.freedesktop.org/series/116868/ to fix MTL boot issue caused by MOCS/PAT update. v2: address comment from Matt. Fei Yang (2): drm/i915/mtl: Add PTE encode function drm/i915/mtl: workaround coherency issue for Media drivers/gpu/drm/i915/display/intel_dpt.c | 2 +- drivers/gpu/drm/i915/gem/i915_gem_pages.c | 5 ++- drivers/gpu/drm/i915/gt/gen8_ppgtt.c | 45 +++ drivers/gpu/drm/i915/gt/intel_ggtt.c | 36 -- drivers/gpu/drm/i915/gt/intel_gtt.h | 12 +- drivers/gpu/drm/i915/gt/uc/intel_gsc_fw.c | 13 +++ drivers/gpu/drm/i915/gt/uc/intel_guc.c| 7 drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c | 6 +++ 8 files changed, 112 insertions(+), 14 deletions(-) -- 2.25.1
[PATCH v2 1/2] drm/i915/mtl: Add PTE encode function
From: Fei Yang
PTE encode functions are platform dependent. This patch implements
PTE functions for MTL, and ensures the correct PTE encode function
is used by calling pte_encode function pointer instead of the
hardcoded gen8 version of PTE encode.
Fixes: b76c0deef627 ("drm/i915/mtl: Define MOCS and PAT tables for MTL")
Signed-off-by: Fei Yang
Reviewed-by: Andrzej Hajda
Reviewed-by: Andi Shyti
Acked-by: Nirmoy Das
---
drivers/gpu/drm/i915/display/intel_dpt.c | 2 +-
drivers/gpu/drm/i915/gt/gen8_ppgtt.c | 45
drivers/gpu/drm/i915/gt/intel_ggtt.c | 36 +--
drivers/gpu/drm/i915/gt/intel_gtt.h | 12 +--
4 files changed, 82 insertions(+), 13 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_dpt.c
b/drivers/gpu/drm/i915/display/intel_dpt.c
index b8027392144d..c5eacfdba1a5 100644
--- a/drivers/gpu/drm/i915/display/intel_dpt.c
+++ b/drivers/gpu/drm/i915/display/intel_dpt.c
@@ -300,7 +300,7 @@ intel_dpt_create(struct intel_framebuffer *fb)
vm->vma_ops.bind_vma= dpt_bind_vma;
vm->vma_ops.unbind_vma = dpt_unbind_vma;
- vm->pte_encode = gen8_ggtt_pte_encode;
+ vm->pte_encode = vm->gt->ggtt->vm.pte_encode;
dpt->obj = dpt_obj;
dpt->obj->is_dpt = true;
diff --git a/drivers/gpu/drm/i915/gt/gen8_ppgtt.c
b/drivers/gpu/drm/i915/gt/gen8_ppgtt.c
index 4daaa6f55668..4c9a2f2db908 100644
--- a/drivers/gpu/drm/i915/gt/gen8_ppgtt.c
+++ b/drivers/gpu/drm/i915/gt/gen8_ppgtt.c
@@ -55,6 +55,34 @@ static u64 gen8_pte_encode(dma_addr_t addr,
return pte;
}
+static u64 mtl_pte_encode(dma_addr_t addr,
+ enum i915_cache_level level,
+ u32 flags)
+{
+ gen8_pte_t pte = addr | GEN8_PAGE_PRESENT | GEN8_PAGE_RW;
+
+ if (unlikely(flags & PTE_READ_ONLY))
+ pte &= ~GEN8_PAGE_RW;
+
+ if (flags & PTE_LM)
+ pte |= GEN12_PPGTT_PTE_LM;
+
+ switch (level) {
+ case I915_CACHE_NONE:
+ pte |= GEN12_PPGTT_PTE_PAT1;
+ break;
+ case I915_CACHE_LLC:
+ case I915_CACHE_L3_LLC:
+ pte |= GEN12_PPGTT_PTE_PAT0 | GEN12_PPGTT_PTE_PAT1;
+ break;
+ case I915_CACHE_WT:
+ pte |= GEN12_PPGTT_PTE_PAT0;
+ break;
+ }
+
+ return pte;
+}
+
static void gen8_ppgtt_notify_vgt(struct i915_ppgtt *ppgtt, bool create)
{
struct drm_i915_private *i915 = ppgtt->vm.i915;
@@ -427,7 +455,7 @@ gen8_ppgtt_insert_pte(struct i915_ppgtt *ppgtt,
u32 flags)
{
struct i915_page_directory *pd;
- const gen8_pte_t pte_encode = gen8_pte_encode(0, cache_level, flags);
+ const gen8_pte_t pte_encode = ppgtt->vm.pte_encode(0, cache_level,
flags);
gen8_pte_t *vaddr;
pd = i915_pd_entry(pdp, gen8_pd_index(idx, 2));
@@ -580,7 +608,7 @@ static void gen8_ppgtt_insert_huge(struct
i915_address_space *vm,
enum i915_cache_level cache_level,
u32 flags)
{
- const gen8_pte_t pte_encode = gen8_pte_encode(0, cache_level, flags);
+ const gen8_pte_t pte_encode = vm->pte_encode(0, cache_level, flags);
unsigned int rem = sg_dma_len(iter->sg);
u64 start = vma_res->start;
@@ -743,7 +771,7 @@ static void gen8_ppgtt_insert_entry(struct
i915_address_space *vm,
GEM_BUG_ON(pt->is_compact);
vaddr = px_vaddr(pt);
- vaddr[gen8_pd_index(idx, 0)] = gen8_pte_encode(addr, level, flags);
+ vaddr[gen8_pd_index(idx, 0)] = vm->pte_encode(addr, level, flags);
drm_clflush_virt_range(&vaddr[gen8_pd_index(idx, 0)], sizeof(*vaddr));
}
@@ -773,7 +801,7 @@ static void __xehpsdv_ppgtt_insert_entry_lm(struct
i915_address_space *vm,
}
vaddr = px_vaddr(pt);
- vaddr[gen8_pd_index(idx, 0) / 16] = gen8_pte_encode(addr, level, flags);
+ vaddr[gen8_pd_index(idx, 0) / 16] = vm->pte_encode(addr, level, flags);
}
static void xehpsdv_ppgtt_insert_entry(struct i915_address_space *vm,
@@ -820,8 +848,8 @@ static int gen8_init_scratch(struct i915_address_space *vm)
pte_flags |= PTE_LM;
vm->scratch[0]->encode =
- gen8_pte_encode(px_dma(vm->scratch[0]),
- I915_CACHE_NONE, pte_flags);
+ vm->pte_encode(px_dma(vm->scratch[0]),
+ I915_CACHE_NONE, pte_flags);
for (i = 1; i <= vm->top; i++) {
struct drm_i915_gem_object *obj;
@@ -963,7 +991,10 @@ struct i915_ppgtt *gen8_ppgtt_create(struct intel_gt *gt,
*/
ppgtt->vm.alloc_scratch_dma = alloc_pt_dma;
- ppgtt->vm.pte_encode = gen8_pte_encode;
+ if (GRAPHICS_VER_FULL(gt->i915) >= IP_VER(12, 70))
+ ppgtt->vm.pte_encode = mtl_pte_encode;
+ else
+ ppgtt->vm.pte_encode = gen8_pte_encode;
ppgtt->vm.bind_async_flags = I915
Re: [PATCH net-next 1/6] dt-bindings: net: Brcm ASP 2.0 Ethernet controller
On 4/24/23 11:14, Justin Chen wrote:
On Fri, Apr 21, 2023 at 12:29 AM Krzysztof Kozlowski
wrote:
On 19/04/2023 02:10, Justin Chen wrote:
From: Florian Fainelli
Add a binding document for the Broadcom ASP 2.0 Ethernet
controller.
Signed-off-by: Florian Fainelli
Signed-off-by: Justin Chen
---
.../devicetree/bindings/net/brcm,asp-v2.0.yaml | 146 +
1 file changed, 146 insertions(+)
create mode 100644 Documentation/devicetree/bindings/net/brcm,asp-v2.0.yaml
diff --git a/Documentation/devicetree/bindings/net/brcm,asp-v2.0.yaml
b/Documentation/devicetree/bindings/net/brcm,asp-v2.0.yaml
new file mode 100644
index ..3817d722244f
--- /dev/null
+++ b/Documentation/devicetree/bindings/net/brcm,asp-v2.0.yaml
@@ -0,0 +1,146 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: "http://devicetree.org/schemas/net/brcm,asp-v2.0.yaml#";
+$schema: "http://devicetree.org/meta-schemas/core.yaml#";
Drop quotes.
+
+title: Broadcom ASP 2.0 Ethernet controller
+
+maintainers:
+ - Justin Chen
+ - Florian Fainelli
+
+description: Broadcom Ethernet controller first introduced with 72165
+
+properties:
+ '#address-cells':
+const: 1
+ '#size-cells':
+const: 1
+
+ compatible:
+enum:
+ - brcm,bcm72165-asp-v2.0
+ - brcm,asp-v2.0
+ - brcm,asp-v2.1
Is this part of SoC? If so, then SoC compatibles are preferred, not IP
block versions.
We have the same IP on different chips. So no, it isn't tied to a specific SoC.
+
+ reg:
+maxItems: 1
+description: ASP registers
Drop description.
+
+ ranges: true
+
+ interrupts:
+minItems: 1
+items:
+ - description: RX/TX interrupt
+ - description: Port 0 Wake-on-LAN
+ - description: Port 1 Wake-on-LAN
+
+ clocks:
+$ref: /schemas/types.yaml#/definitions/phandle-array
Drop.
+description: Phandle to clock controller
Drop.
Instead maxItems.
+
+ clock-names:
+const: sw_asp
Drop entire property.
+
+ ethernet-ports:
+type: object
+properties:
+ '#address-cells':
+const: 1
+ '#size-cells':
+const: 0
Missing additionalProperties:false. Look at existing bindings how it is
done.
+
+patternProperties:
+ "^port@[0-9]+$":
+type: object
+
+$ref: ethernet-controller.yaml#
+
+properties:
+ reg:
+maxItems: 1
+description: Port number
+
+ channel:
+maxItems: 1
+description: ASP channel number
+
+required:
+ - reg
+ - channel
+
+patternProperties:
+ "^mdio@[0-9a-f]+$":
+type: object
+$ref: "brcm,unimac-mdio.yaml"
+
+description:
+ ASP internal UniMAC MDIO bus
+
+required:
+ - compatible
+ - reg
+ - interrupts
+ - clocks
+ - clock-names
+ - ranges
+
+additionalProperties: false
+
+examples:
+ - |
+asp@9c0 {
Node names should be generic.
https://devicetree-specification.readthedocs.io/en/latest/chapter2-devicetree-basics.html#generic-names-recommendation
+compatible = "brcm,asp-v2.0";
+reg = <0x9c0 0x1fff14>;
+interrupts = <0x0 0x33 0x4>;
Use proper defines for flags.
Not understanding this comment. Can you elaborate?
I believe Krzysztof would prefer that you use:
interrupts =
here, which would require using defined from
include/dt-bindings/interrupt-controller/{arm-gic.h,irq.h}
--
Florian
Re: [PATCH net-next 1/6] dt-bindings: net: Brcm ASP 2.0 Ethernet controller
On Fri, Apr 21, 2023 at 12:29 AM Krzysztof Kozlowski
wrote:
>
> On 19/04/2023 02:10, Justin Chen wrote:
> > From: Florian Fainelli
> >
> > Add a binding document for the Broadcom ASP 2.0 Ethernet
> > controller.
> >
> > Signed-off-by: Florian Fainelli
> > Signed-off-by: Justin Chen
> > ---
> > .../devicetree/bindings/net/brcm,asp-v2.0.yaml | 146
> > +
> > 1 file changed, 146 insertions(+)
> > create mode 100644 Documentation/devicetree/bindings/net/brcm,asp-v2.0.yaml
> >
> > diff --git a/Documentation/devicetree/bindings/net/brcm,asp-v2.0.yaml
> > b/Documentation/devicetree/bindings/net/brcm,asp-v2.0.yaml
> > new file mode 100644
> > index ..3817d722244f
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/net/brcm,asp-v2.0.yaml
> > @@ -0,0 +1,146 @@
> > +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> > +%YAML 1.2
> > +---
> > +$id: "http://devicetree.org/schemas/net/brcm,asp-v2.0.yaml#";
> > +$schema: "http://devicetree.org/meta-schemas/core.yaml#";
>
> Drop quotes.
>
> > +
> > +title: Broadcom ASP 2.0 Ethernet controller
> > +
> > +maintainers:
> > + - Justin Chen
> > + - Florian Fainelli
> > +
> > +description: Broadcom Ethernet controller first introduced with 72165
> > +
> > +properties:
> > + '#address-cells':
> > +const: 1
> > + '#size-cells':
> > +const: 1
> > +
> > + compatible:
> > +enum:
> > + - brcm,bcm72165-asp-v2.0
> > + - brcm,asp-v2.0
> > + - brcm,asp-v2.1
>
> Is this part of SoC? If so, then SoC compatibles are preferred, not IP
> block versions.
We have the same IP on different chips. So no, it isn't tied to a specific SoC.
>
> > +
> > + reg:
> > +maxItems: 1
> > +description: ASP registers
>
> Drop description.
>
> > +
> > + ranges: true
> > +
> > + interrupts:
> > +minItems: 1
> > +items:
> > + - description: RX/TX interrupt
> > + - description: Port 0 Wake-on-LAN
> > + - description: Port 1 Wake-on-LAN
> > +
> > + clocks:
> > +$ref: /schemas/types.yaml#/definitions/phandle-array
>
> Drop.
>
> > +description: Phandle to clock controller
>
> Drop.
>
> Instead maxItems.
>
> > +
> > + clock-names:
> > +const: sw_asp
>
> Drop entire property.
>
> > +
> > + ethernet-ports:
> > +type: object
> > +properties:
> > + '#address-cells':
> > +const: 1
> > + '#size-cells':
> > +const: 0
>
> Missing additionalProperties:false. Look at existing bindings how it is
> done.
>
> > +
> > +patternProperties:
> > + "^port@[0-9]+$":
> > +type: object
> > +
> > +$ref: ethernet-controller.yaml#
> > +
> > +properties:
> > + reg:
> > +maxItems: 1
> > +description: Port number
> > +
> > + channel:
> > +maxItems: 1
> > +description: ASP channel number
> > +
> > +required:
> > + - reg
> > + - channel
> > +
> > +patternProperties:
> > + "^mdio@[0-9a-f]+$":
> > +type: object
> > +$ref: "brcm,unimac-mdio.yaml"
> > +
> > +description:
> > + ASP internal UniMAC MDIO bus
> > +
> > +required:
> > + - compatible
> > + - reg
> > + - interrupts
> > + - clocks
> > + - clock-names
> > + - ranges
> > +
> > +additionalProperties: false
> > +
> > +examples:
> > + - |
> > +asp@9c0 {
>
> Node names should be generic.
> https://devicetree-specification.readthedocs.io/en/latest/chapter2-devicetree-basics.html#generic-names-recommendation
>
> > +compatible = "brcm,asp-v2.0";
> > +reg = <0x9c0 0x1fff14>;
> > +interrupts = <0x0 0x33 0x4>;
>
> Use proper defines for flags.
Not understanding this comment. Can you elaborate?
Thanks,
Justin
>
> > +ranges;
> > +clocks = <&scmi 14>;
> > +clock-names = "sw_asp";
> > +#address-cells = <1>;
> > +#size-cells = <1>;
>
>
> Best regards,
> Krzysztof
>
Re: [PATCH] drm/amd/display: return status of dmub_srv_get_fw_boot_status
On 4/24/23 10:02 AM, Hamza Mahfooz wrote:
On 4/20/23 09:59, Tom Rix wrote:
gcc with W=1 reports
drivers/gpu/drm/amd/amdgpu/../display/dc/dc_dmub_srv.c:
In function ‘dc_dmub_srv_optimized_init_done’:
drivers/gpu/drm/amd/amdgpu/../display/dc/dc_dmub_srv.c:184:26:
error: variable ‘dmub’ set but not used
[-Werror=unused-but-set-variable]
184 | struct dmub_srv *dmub;
| ^~~~
The return status is never set.
It looks like a call to dmub_srv_get_fw_boot_status is missing.
Fixes: 499e4b1c722e ("drm/amd/display: add mechanism to skip DCN init")
What tree is this based on? I am unable to find that exact commit on
amd-staging-drm-next.
linux-next
Tom
Signed-off-by: Tom Rix
---
drivers/gpu/drm/amd/display/dc/dc_dmub_srv.c | 13 +++--
1 file changed, 11 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/amd/display/dc/dc_dmub_srv.c
b/drivers/gpu/drm/amd/display/dc/dc_dmub_srv.c
index d15ec32243e2..36d936ab4300 100644
--- a/drivers/gpu/drm/amd/display/dc/dc_dmub_srv.c
+++ b/drivers/gpu/drm/amd/display/dc/dc_dmub_srv.c
@@ -182,14 +182,23 @@ bool dc_dmub_srv_cmd_run_list(struct
dc_dmub_srv *dc_dmub_srv, unsigned int coun
bool dc_dmub_srv_optimized_init_done(struct dc_dmub_srv *dc_dmub_srv)
{
struct dmub_srv *dmub;
- union dmub_fw_boot_status status;
+ struct dc_context *dc_ctx;
+ union dmub_fw_boot_status boot_status;
+ enum dmub_status status;
if (!dc_dmub_srv || !dc_dmub_srv->dmub)
return false;
dmub = dc_dmub_srv->dmub;
+ dc_ctx = dc_dmub_srv->ctx;
+
+ status = dmub_srv_get_fw_boot_status(dmub, &boot_status);
+ if (status != DMUB_STATUS_OK) {
+ DC_ERROR("Error querying DMUB boot status: error=%d\n",
status);
+ return false;
+ }
- return status.bits.optimized_init_done;
+ return boot_status.bits.optimized_init_done;
}
bool dc_dmub_srv_notify_stream_mask(struct dc_dmub_srv *dc_dmub_srv,
Re: [Intel-gfx] [PATCH 3/8] drm/i915/mtl: Add PTE encode function
On Sun, Apr 23, 2023 at 12:37:27AM -0700, Yang, Fei wrote:
> > On Fri, Apr 21, 2023 at 10:27:22AM -0700, Yang, Fei wrote:
> >>> On Wed, Apr 19, 2023 at 04:00:53PM -0700, fei.y...@intel.com wrote:
> From: Fei Yang
>
> PTE encode functions are platform dependent. This patch implements
> PTE functions for MTL, and ensures the correct PTE encode function
> is used by calling pte_encode function pointer instead of the
> hardcoded gen8 version of PTE encode.
>
> Signed-off-by: Fei Yang
> Reviewed-by: Andrzej Hajda
> Reviewed-by: Andi Shyti
> Acked-by: Nirmoy Das
> >>>
> >>> Bspec: 45015, 45040
> >>>
> ---
> drivers/gpu/drm/i915/display/intel_dpt.c | 2 +-
> drivers/gpu/drm/i915/gt/gen8_ppgtt.c | 45
> drivers/gpu/drm/i915/gt/intel_ggtt.c | 36 +--
> 3 files changed, 72 insertions(+), 11 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_dpt.c
> >>b/drivers/gpu/drm/i915/display/intel_dpt.c
> index b8027392144d..c5eacfdba1a5 100644
> --- a/drivers/gpu/drm/i915/display/intel_dpt.c
> +++ b/drivers/gpu/drm/i915/display/intel_dpt.c
> @@ -300,7 +300,7 @@ intel_dpt_create(struct intel_framebuffer *fb)
> vm->vma_ops.bind_vma= dpt_bind_vma;
> vm->vma_ops.unbind_vma = dpt_unbind_vma;
>
> - vm->pte_encode = gen8_ggtt_pte_encode;
> + vm->pte_encode = vm->gt->ggtt->vm.pte_encode;
>
> dpt->obj = dpt_obj;
> dpt->obj->is_dpt = true;
> diff --git a/drivers/gpu/drm/i915/gt/gen8_ppgtt.c
> b/drivers/gpu/drm/i915/gt/gen8_ppgtt.c
> index 4daaa6f55668..11b91e0453c8 100644
> --- a/drivers/gpu/drm/i915/gt/gen8_ppgtt.c
> +++ b/drivers/gpu/drm/i915/gt/gen8_ppgtt.c
> @@ -55,6 +55,34 @@ static u64 gen8_pte_encode(dma_addr_t addr,
> return pte;
> }
>
> +static u64 mtl_pte_encode(dma_addr_t addr,
> + enum i915_cache_level level,
> + u32 flags)
> +{
> + gen8_pte_t pte = addr | GEN8_PAGE_PRESENT | GEN8_PAGE_RW;
> +
> + if (unlikely(flags & PTE_READ_ONLY))
> + pte &= ~GEN8_PAGE_RW;
> +
> + if (flags & PTE_LM)
> + pte |= GEN12_PPGTT_PTE_LM | GEN12_PPGTT_PTE_NC;
> >>>
> >>> GEN12_PPGTT_PTE_NC got defined in the previous patch as BIT(5). But
> >>> according to bspec 45040, bit 5 is ignored in the PTE encoding. What is
> >>> this trying to do?
> >>
> >> This takes effect only for PTE_LM, doesn't affect MTL.
> >> PTE_NC is needed for PVC (use of access counter).
> >> I believe this function was writen based on the one for PVC. And this
> >> function did get extended to cover all gen12 in a later patch.
> >
> > Even though MTL doesn't have local memory, PTE_LM is supposed to be
> > used on MTL for access to BAR2 stolen memory.
>
> You were right, but I still think this code is fine because this bit is
> ignored for MTL anyway and it is needed for other platforms with LMEM.
> Otherwise this code would have some sort of platform checking which is
> hard to do because we don't have platform info here.
> Or we would have to define another PTE encode function for platforms
> needing PTE_NC just for this one difference, then manage the function
> pointer correctly.
MTL is the only platform that uses this function right now:
+ if (GRAPHICS_VER_FULL(gt->i915) >= IP_VER(12, 70))
+ ppgtt->vm.pte_encode = mtl_pte_encode;
+ else
+ ppgtt->vm.pte_encode = gen8_pte_encode;
If this is intended for PVC, then you have it in the wrong function to
begin with (and it also shouldn't be in a patch labelled "mtl"). If
you're trying to future-proof for some post-MTL discrete platform, then
such code should be saved until we enable that platform so that it can
be properly reviewed.
Matt
>
> -Fei
>
> > Matt
> >
> >> -Fei
> >>> Matt
> >>>
> +
> + switch (level) {
> + case I915_CACHE_NONE:
> + pte |= GEN12_PPGTT_PTE_PAT1;
> + break;
--
Matt Roper
Graphics Software Engineer
Linux GPU Platform Enablement
Intel Corporation
Re: [Intel-gfx] [PATCH 8/8] drm/i915: Allow user to set cache at BO creation
On 2023-04-24 02:08:43, Tvrtko Ursulin wrote: > > Being able to "list" supported extensions sounds like a reasonable > principle, albeit a departure from the design direction to date. > Which means there are probably no quick solutions. Also, AFAIU, only > PXP context create is the problematic one, right? Everything else is > pretty much instant or delayed allocation so super cheap to probe by > attempting to use. > > If I got that right and given this series is about > drm_i915_gem_create_ext I don't think this side discussion should be > blocking it. This still leaves the issue of no reasonable detection mechanism for the extension. If the discussion gets too complicated, then can we add a GET_PARAM for the SET_PAT extension? I'm hoping we could either come up with something better reasonably quickly, or i915/Xe can add a new param for each new extensions until a better approach is available. > Furthermore the PXP context create story is even more complicated, > in a way that it is not just about querying whether the extension is > supported, but the expensive check is something more complicated. > > Going back to implementation details for this proposed new feature, > one alternative to query could be something like: > >drm_i915_gem_create_ext.flags |= I915_GEM_CREATE_EXT_FLAG_PROBE_EXTENSIONS; > > That would be somewhat more light weight to implement that the > i915_query route. And it appears it would work for all ioctls which > support extensions apart for i915_context_param_engines. This seems little better than the "try it, and if it works then it's supported". I'm not suggesting that userspace should be able to check that scenario x+y+z will work, but more a list of extensions that conceivably could work. Normally this should just a matter of the kernel unconditionally adding the newly implemented extension to the list returned in the query call. If a GET_PARAM can be made for the PXP case, then it seems like a query item returning CONTEXT_CREATE extensions could conditionally omit that extension just as easily as implementing the proposed new GET_PARAM. -Jordan
Re: [PATCH v8 1/5] drm: Place Renesas drivers in a separate dir
Hi Biju,
Thank you for the patch.
On Mon, Apr 24, 2023 at 05:10:20PM +0100, Biju Das wrote:
> Create vendor specific renesas directory and move renesas drivers
> to that directory.
>
> Signed-off-by: Biju Das
Reviewed-by: Laurent Pinchart
> ---
> MAINTAINERS | 3 +--
> drivers/gpu/drm/Kconfig | 4 +---
> drivers/gpu/drm/Makefile | 3 +--
> drivers/gpu/drm/renesas/Kconfig | 4
> drivers/gpu/drm/renesas/Makefile | 4
> drivers/gpu/drm/{ => renesas}/rcar-du/Kconfig| 0
> drivers/gpu/drm/{ => renesas}/rcar-du/Makefile | 0
> drivers/gpu/drm/{ => renesas}/rcar-du/rcar_cmm.c | 0
> drivers/gpu/drm/{ => renesas}/rcar-du/rcar_cmm.h | 0
> drivers/gpu/drm/{ => renesas}/rcar-du/rcar_du_crtc.c | 0
> drivers/gpu/drm/{ => renesas}/rcar-du/rcar_du_crtc.h | 0
> drivers/gpu/drm/{ => renesas}/rcar-du/rcar_du_drv.c | 0
> drivers/gpu/drm/{ => renesas}/rcar-du/rcar_du_drv.h | 0
> drivers/gpu/drm/{ => renesas}/rcar-du/rcar_du_encoder.c | 0
> drivers/gpu/drm/{ => renesas}/rcar-du/rcar_du_encoder.h | 0
> drivers/gpu/drm/{ => renesas}/rcar-du/rcar_du_group.c| 0
> drivers/gpu/drm/{ => renesas}/rcar-du/rcar_du_group.h| 0
> drivers/gpu/drm/{ => renesas}/rcar-du/rcar_du_kms.c | 0
> drivers/gpu/drm/{ => renesas}/rcar-du/rcar_du_kms.h | 0
> drivers/gpu/drm/{ => renesas}/rcar-du/rcar_du_plane.c| 0
> drivers/gpu/drm/{ => renesas}/rcar-du/rcar_du_plane.h| 0
> drivers/gpu/drm/{ => renesas}/rcar-du/rcar_du_regs.h | 0
> drivers/gpu/drm/{ => renesas}/rcar-du/rcar_du_vsp.c | 0
> drivers/gpu/drm/{ => renesas}/rcar-du/rcar_du_vsp.h | 0
> drivers/gpu/drm/{ => renesas}/rcar-du/rcar_du_writeback.c| 0
> drivers/gpu/drm/{ => renesas}/rcar-du/rcar_du_writeback.h| 0
> drivers/gpu/drm/{ => renesas}/rcar-du/rcar_dw_hdmi.c | 0
> drivers/gpu/drm/{ => renesas}/rcar-du/rcar_lvds.c| 0
> drivers/gpu/drm/{ => renesas}/rcar-du/rcar_lvds.h| 0
> drivers/gpu/drm/{ => renesas}/rcar-du/rcar_lvds_regs.h | 0
> drivers/gpu/drm/{ => renesas}/rcar-du/rcar_mipi_dsi.c| 0
> drivers/gpu/drm/{ => renesas}/rcar-du/rcar_mipi_dsi.h| 0
> drivers/gpu/drm/{ => renesas}/rcar-du/rcar_mipi_dsi_regs.h | 0
> drivers/gpu/drm/{ => renesas}/rcar-du/rzg2l_mipi_dsi.c | 0
> drivers/gpu/drm/{ => renesas}/rcar-du/rzg2l_mipi_dsi_regs.h | 0
> drivers/gpu/drm/{ => renesas}/shmobile/Kconfig | 0
> drivers/gpu/drm/{ => renesas}/shmobile/Makefile | 0
> drivers/gpu/drm/{ => renesas}/shmobile/shmob_drm_backlight.c | 0
> drivers/gpu/drm/{ => renesas}/shmobile/shmob_drm_backlight.h | 0
> drivers/gpu/drm/{ => renesas}/shmobile/shmob_drm_crtc.c | 0
> drivers/gpu/drm/{ => renesas}/shmobile/shmob_drm_crtc.h | 0
> drivers/gpu/drm/{ => renesas}/shmobile/shmob_drm_drv.c | 0
> drivers/gpu/drm/{ => renesas}/shmobile/shmob_drm_drv.h | 0
> drivers/gpu/drm/{ => renesas}/shmobile/shmob_drm_kms.c | 0
> drivers/gpu/drm/{ => renesas}/shmobile/shmob_drm_kms.h | 0
> drivers/gpu/drm/{ => renesas}/shmobile/shmob_drm_plane.c | 0
> drivers/gpu/drm/{ => renesas}/shmobile/shmob_drm_plane.h | 0
> drivers/gpu/drm/{ => renesas}/shmobile/shmob_drm_regs.h | 0
> 48 files changed, 11 insertions(+), 7 deletions(-)
> create mode 100644 drivers/gpu/drm/renesas/Kconfig
> create mode 100644 drivers/gpu/drm/renesas/Makefile
> rename drivers/gpu/drm/{ => renesas}/rcar-du/Kconfig (100%)
> rename drivers/gpu/drm/{ => renesas}/rcar-du/Makefile (100%)
> rename drivers/gpu/drm/{ => renesas}/rcar-du/rcar_cmm.c (100%)
> rename drivers/gpu/drm/{ => renesas}/rcar-du/rcar_cmm.h (100%)
> rename drivers/gpu/drm/{ => renesas}/rcar-du/rcar_du_crtc.c (100%)
> rename drivers/gpu/drm/{ => renesas}/rcar-du/rcar_du_crtc.h (100%)
> rename drivers/gpu/drm/{ => renesas}/rcar-du/rcar_du_drv.c (100%)
> rename drivers/gpu/drm/{ => renesas}/rcar-du/rcar_du_drv.h (100%)
> rename drivers/gpu/drm/{ => renesas}/rcar-du/rcar_du_encoder.c (100%)
> rename drivers/gpu/drm/{ => renesas}/rcar-du/rcar_du_encoder.h (100%)
> rename drivers/gpu/drm/{ => renesas}/rcar-du/rcar_du_group.c (100%)
> rename drivers/gpu/drm/{ => renesas}/rcar-du/rcar_du_group.h (100%)
> rename drivers/gpu/drm/{ => renesas}/rcar-du/rcar_du_kms.c (100%)
> rename drivers/gpu/drm/{ => renesas}/rcar-du/rcar_du_kms.h (100%)
> rename drivers/gpu/drm/{ => renesas}/rcar-du/rcar_du_plane.c (100%)
> rename drivers/gpu/drm/{ => renesas}/rcar-du/rcar_du_plane.h (100%)
> rename drivers/gpu/drm/{ => renesas}/rcar-du/rcar_du_regs.h (100%)
> rename drivers/gpu/drm/{ => renesas}/rcar-du/rcar_du_vsp.c (100%)
> rename drivers/gpu/drm/{ => renesas}/rcar-du/rcar_
Re: [PATCH] modules/firmware: add a new option to denote a firmware group to choose one.
On Mon, Apr 24, 2023 at 03:44:18PM +1000, Dave Airlie wrote:
On Fri, 21 Apr 2023 at 05:09, Lucas De Marchi wrote:
On Wed, Apr 19, 2023 at 02:36:52PM +1000, Dave Airlie wrote:
>From: Dave Airlie
>
>This adds a tag that will go into the module info, only one firmware from
>the group given needs to be available for this driver to work. This allows
>dracut to avoid adding in firmware that aren't needed.
>
>This just brackets a module list in the modinfo, the modules in the list
>will get entries in reversed order so the last module in the list is the
>preferred one.
>
>The corresponding dracut code it at:
>https://github.com/dracutdevs/dracut/pull/2309
it would be good to have the example usage in the commit message here so
it can be easily checked as reference for other drivers.
Good point.
I don't think we ever had any ordering in modinfo being relevant for
other things. Considering the use case and that we could also use a
similar thing for i915 / xe modules wrt to the major version,
couldn't we do something like below?
MODULE_FIRMWARE_GROUP("nvidia/ga106/gsp/gsp");
MODULE_FIRMWARE("nvidia/ga106/gsp/gsp-5258902.bin");
MODULE_FIRMWARE("nvidia/ga106/gsp/gsp-5303002.bin");
so the group is created by startswith() rather than by the order the
modinfo appears in the elf section. In i915 we'd have:
The way userspace parses these is reverse order, and it doesn't see
the main issue I have with it is that it relies on a order that is
implicit rather than intended. The order comes from how the .modinfo ELF
section is assembled together... so the fact that your call to
kmod_module_get_info() returns a list with the keys in the reverse order
of the MODULE_FIRMWARE() definitions, is basically because the compiler
toolchain did it did that way.
It's worse when those sections come from different compilation units as
the order then is not predictable and can easily break with changes to
the build infra if the files are linked in different order.
I think the grouping thing here would only be supported with firmware
defined on the same compilation unit, but it's something to keep in mind
and document.
the GROUP until after the FIRMWARE, so this can't work, as it already
will have included all the ones below, hence why I bracketed top and
bottom with a group.
well... that is something that can be adapted easily by using a 2 pass
approach, filtering out the list based on the groups.
I agree that yours is simpler though. If we can rely on the
order produced by the compiler and we document the expectations of
MODULE_FIRMWARE_GROUP_ONLY_ONE, then I believe we can stay with the
simpler approach.
Luis, any thoughts here?
thanks
Lucas De Marchi
MODULE_FIRMWARE_GROUP("i915/tgl_guc")
There is still an order the kernel would probably like: latest version.
But then it's an order only among things with the same key.
Dave.
Re: [PATCH] drm/amd/display: return status of dmub_srv_get_fw_boot_status
On 4/20/23 09:59, Tom Rix wrote:
gcc with W=1 reports
drivers/gpu/drm/amd/amdgpu/../display/dc/dc_dmub_srv.c:
In function ‘dc_dmub_srv_optimized_init_done’:
drivers/gpu/drm/amd/amdgpu/../display/dc/dc_dmub_srv.c:184:26:
error: variable ‘dmub’ set but not used [-Werror=unused-but-set-variable]
184 | struct dmub_srv *dmub;
| ^~~~
The return status is never set.
It looks like a call to dmub_srv_get_fw_boot_status is missing.
Fixes: 499e4b1c722e ("drm/amd/display: add mechanism to skip DCN init")
What tree is this based on? I am unable to find that exact commit on
amd-staging-drm-next.
Signed-off-by: Tom Rix
---
drivers/gpu/drm/amd/display/dc/dc_dmub_srv.c | 13 +++--
1 file changed, 11 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/amd/display/dc/dc_dmub_srv.c
b/drivers/gpu/drm/amd/display/dc/dc_dmub_srv.c
index d15ec32243e2..36d936ab4300 100644
--- a/drivers/gpu/drm/amd/display/dc/dc_dmub_srv.c
+++ b/drivers/gpu/drm/amd/display/dc/dc_dmub_srv.c
@@ -182,14 +182,23 @@ bool dc_dmub_srv_cmd_run_list(struct dc_dmub_srv
*dc_dmub_srv, unsigned int coun
bool dc_dmub_srv_optimized_init_done(struct dc_dmub_srv *dc_dmub_srv)
{
struct dmub_srv *dmub;
- union dmub_fw_boot_status status;
+ struct dc_context *dc_ctx;
+ union dmub_fw_boot_status boot_status;
+ enum dmub_status status;
if (!dc_dmub_srv || !dc_dmub_srv->dmub)
return false;
dmub = dc_dmub_srv->dmub;
+ dc_ctx = dc_dmub_srv->ctx;
+
+ status = dmub_srv_get_fw_boot_status(dmub, &boot_status);
+ if (status != DMUB_STATUS_OK) {
+ DC_ERROR("Error querying DMUB boot status: error=%d\n", status);
+ return false;
+ }
- return status.bits.optimized_init_done;
+ return boot_status.bits.optimized_init_done;
}
bool dc_dmub_srv_notify_stream_mask(struct dc_dmub_srv *dc_dmub_srv,
--
Hamza
Re: [PATCH v1 5/5] drm/msm/dpu: add DSC 1.2 hw blocks for relevant chipsets
On 4/21/2023 4:22 PM, Dmitry Baryshkov wrote:
On 22/04/2023 02:16, Kuogee Hsieh wrote:
On 4/21/2023 4:11 PM, Dmitry Baryshkov wrote:
On 22/04/2023 02:08, Kuogee Hsieh wrote:
On 4/21/2023 3:16 PM, Dmitry Baryshkov wrote:
On 22/04/2023 01:05, Kuogee Hsieh wrote:
On 4/20/2023 5:07 PM, Dmitry Baryshkov wrote:
On 21/04/2023 02:25, Kuogee Hsieh wrote:
From: Abhinav Kumar
Add DSC 1.2 hardware blocks to the catalog with necessary
sub-block and feature flag information.
Each display compression engine (DCE) contains dual hard
slice DSC encoders so both share same base address but with
its own different sub block address.
Please correct line wrapping. 72-75 is usually the preferred width
Signed-off-by: Abhinav Kumar
Signed-off-by: Kuogee Hsieh
---
.../gpu/drm/msm/disp/dpu1/catalog/dpu_7_0_sm8350.h | 19
+++
.../gpu/drm/msm/disp/dpu1/catalog/dpu_7_2_sc7280.h | 11
+++
.../drm/msm/disp/dpu1/catalog/dpu_8_0_sc8280xp.h | 21
+
.../gpu/drm/msm/disp/dpu1/catalog/dpu_8_1_sm8450.h | 19
+++
.../gpu/drm/msm/disp/dpu1/catalog/dpu_9_0_sm8550.h | 19
+++
drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c | 12 ++--
6 files changed, 99 insertions(+), 2 deletions(-)
[I commented on sm8550, it applies to all the rest of platforms]
diff --git
a/drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_9_0_sm8550.h
b/drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_9_0_sm8550.h
index 9e40303..72a7bcf 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_9_0_sm8550.h
+++ b/drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_9_0_sm8550.h
@@ -165,6 +165,23 @@ static const struct dpu_merge_3d_cfg
sm8550_merge_3d[] = {
MERGE_3D_BLK("merge_3d_3", MERGE_3D_3, 0x66700),
};
+static const struct dpu_dsc_sub_blks sm8550_dsc_sblk_0 = {
+ .enc = {.base = 0x100, .len = 0x100},
+ .ctl = {.base = 0xF00, .len = 0x10},
+};
+
+static const struct dpu_dsc_sub_blks sm8550_dsc_sblk_1 = {
+ .enc = {.base = 0x200, .len = 0x100},
+ .ctl = {.base = 0xF80, .len = 0x10},
+};
Please keep sblk in dpu_hw_catalog for now.
+
+static const struct dpu_dsc_cfg sm8550_dsc[] = {
+ DSC_BLK_1_2("dsc_0", DSC_0, 0x8, 0x100, 0,
sm8550_dsc_sblk_0),
+ DSC_BLK_1_2("dsc_0", DSC_1, 0x8, 0x100, 0,
sm8550_dsc_sblk_1),
Is there a reason why index in "dsc_N" doesn't match the DSC_n
which comes next to it?
usually each DCE (display compression engine) contains two hard
slice encoders.
DSC_0 and DSC_1 (index) is belong to dsc_0.
If there are two DCE, then DSC_2 and DSC_3 belong to dsc_1
Ah, I see now. So, the block register space is the following:
DCEi ->
common
dsc0_enc
dsc1_enc
dsc0_ctl
dsc1_ctl
Instead of declaring a single DCE unit with two DSC blocks, we
declare two distinct DSC blocks. This raises a question, how
independent are these two parts of a single DCE block? For
example, can we use them to perform compression with different
parameters? Or use one of them for the DP DSC and another one for
DSI DSC? Can we have the following configuration:
DSC_0 => DP DSC
DSC_1, DSC_2 => DSI DSC in DSC_MERGE topology?
no, For merge mode you have to use same DCE, such as DSC_2 and DSC3
(pair)
Ok, this is for the merge mode. So the dpu_rm should be extended to
allocate them in pairs if merge mode is requested.
What about using DSC_0 for DP and DSC_1 for DSI? Is it possible?
I never do that, but i think it should works since they can work
independently.
Good, thanks for the confirmation. For v2, could you please describe
this arrangement of DCE -> 2xDSC in a comment close to DSC_BLK_1_2 and
corresponding sblk definitions?
Also could you please fix dpu_rm to allocate DSC blocks in pairs for
DSC_MERGE mode.
yes, I will fix DSC_MERGE mode at next patch serial.
Last, but not least, would it make sense to name the blocks as "dceN"
instead of "dscN"?
+ DSC_BLK_1_2("dsc_1", DSC_2, 0x81000, 0x100,
BIT(DPU_DSC_NATIVE_422_EN), sm8550_dsc_sblk_0),
+ DSC_BLK_1_2("dsc_1", DSC_3, 0x81000, 0x100,
BIT(DPU_DSC_NATIVE_422_EN), sm8550_dsc_sblk_1),
+};
+
static const struct dpu_intf_cfg sm8550_intf[] = {
INTF_BLK("intf_0", INTF_0, 0x34000, 0x280, INTF_DP,
MSM_DP_CONTROLLER_0, 24, INTF_SC7280_MASK, MDP_SSPP_TOP0_INTR,
24, 25),
/* TODO TE sub-blocks for intf1 & intf2 */
@@ -218,6 +235,8 @@ const struct dpu_mdss_cfg dpu_sm8550_cfg = {
.dspp = sm8550_dspp,
.pingpong_count = ARRAY_SIZE(sm8550_pp),
.pingpong = sm8550_pp,
+ .dsc = sm8550_dsc,
+ .dsc_count = ARRAY_SIZE(sm8550_dsc),
.merge_3d_count = ARRAY_SIZE(sm8550_merge_3d),
.merge_3d = sm8550_merge_3d,
.intf_count = ARRAY_SIZE(sm8550_intf),
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 03f162a..be08158 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c
@@ -1,6 +1,6 @@
// SPDX-Li
Re: [PATCH v2 01/17] drm/msm/dpu: Remove unused INTF0 interrupt mask from SM6115/QCM2290
On 4/17/2023 1:21 PM, Marijn Suijten wrote:
Neither of these SoCs has INTF0, they only have a DSI interface on index
1. Stop enabling an interrupt that can't fire.
Fixes: 3581b7062cec ("drm/msm/disp/dpu1: add support for display on SM6115")
Fixes: 5334087ee743 ("drm/msm: add support for QCM2290 MDSS")
Signed-off-by: Marijn Suijten
Reviewed-by: Dmitry Baryshkov
Reviewed-by: Konrad Dybcio
---
Yes, this is right, Both of these chipsets only have DSI on index 1.
Reviewed-by: Abhinav Kumar
[PATCH 2/2] drm/i915/mtl: workaround coherency issue for Media
From: Fei Yang
This patch implements Wa_22016122933.
In MTL, memory writes initiated by the Media tile update the whole
cache line, even for partial writes. This creates a coherency
problem for cacheable memory if both CPU and GPU are writing data
to different locations within a single cache line.
This patch circumvents the issue by making CPU/GPU shared memory
uncacheable (WC on CPU side, and PAT index 2 for GPU). Additionally,
it ensures that CPU writes are visible to the GPU with an
intel_guc_write_barrier().
While fixing the CTB issue, we noticed some random GSC firmware
loading failure because the share buffers are cacheable (WB) on CPU
side but uncached on GPU side. To fix these issues we need to map
such shared buffers as WC on CPU side. Since such allocations are
not all done through GuC allocator, to avoid too many code changes,
the i915_coherent_map_type() is now hard coded to return WC for MTL.
v2: Simplify the commit message(Matt).
BSpec: 45101
Signed-off-by: Fei Yang
Reviewed-by: Andi Shyti
Acked-by: Nirmoy Das
Reviewed-by: Andrzej Hajda
Reviewed-by: Matt Roper
Signed-off-by: Nirmoy Das
---
drivers/gpu/drm/i915/gem/i915_gem_pages.c | 5 -
drivers/gpu/drm/i915/gt/uc/intel_gsc_fw.c | 13 +
drivers/gpu/drm/i915/gt/uc/intel_guc.c| 7 +++
drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c | 6 ++
4 files changed, 30 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_pages.c
b/drivers/gpu/drm/i915/gem/i915_gem_pages.c
index ecd86130b74f..89fc8ea6bcfc 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_pages.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_pages.c
@@ -469,7 +469,10 @@ enum i915_map_type i915_coherent_map_type(struct
drm_i915_private *i915,
struct drm_i915_gem_object *obj,
bool always_coherent)
{
- if (i915_gem_object_is_lmem(obj))
+ /*
+* Wa_22016122933: always return I915_MAP_WC for MTL
+*/
+ if (i915_gem_object_is_lmem(obj) || IS_METEORLAKE(i915))
return I915_MAP_WC;
if (HAS_LLC(i915) || always_coherent)
return I915_MAP_WB;
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_gsc_fw.c
b/drivers/gpu/drm/i915/gt/uc/intel_gsc_fw.c
index 1d9fdfb11268..236673c02f9a 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_gsc_fw.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_gsc_fw.c
@@ -110,6 +110,13 @@ static int gsc_fw_load_prepare(struct intel_gsc_uc *gsc)
if (obj->base.size < gsc->fw.size)
return -ENOSPC;
+ /*
+* Wa_22016122933: For MTL the shared memory needs to be mapped
+* as WC on CPU side and UC (PAT index 2) on GPU side
+*/
+ if (IS_METEORLAKE(i915))
+ i915_gem_object_set_cache_coherency(obj, I915_CACHE_NONE);
+
dst = i915_gem_object_pin_map_unlocked(obj,
i915_coherent_map_type(i915,
obj, true));
if (IS_ERR(dst))
@@ -125,6 +132,12 @@ static int gsc_fw_load_prepare(struct intel_gsc_uc *gsc)
memset(dst, 0, obj->base.size);
memcpy(dst, src, gsc->fw.size);
+ /*
+* Wa_22016122933: Making sure the data in dst is
+* visible to GSC right away
+*/
+ intel_guc_write_barrier(>->uc.guc);
+
i915_gem_object_unpin_map(gsc->fw.obj);
i915_gem_object_unpin_map(obj);
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc.c
b/drivers/gpu/drm/i915/gt/uc/intel_guc.c
index e89f16ecf1ae..c9f20385f6a0 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_guc.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_guc.c
@@ -744,6 +744,13 @@ struct i915_vma *intel_guc_allocate_vma(struct intel_guc
*guc, u32 size)
if (IS_ERR(obj))
return ERR_CAST(obj);
+ /*
+* Wa_22016122933: For MTL the shared memory needs to be mapped
+* as WC on CPU side and UC (PAT index 2) on GPU side
+*/
+ if (IS_METEORLAKE(gt->i915))
+ i915_gem_object_set_cache_coherency(obj, I915_CACHE_NONE);
+
vma = i915_vma_instance(obj, >->ggtt->vm, NULL);
if (IS_ERR(vma))
goto err;
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c
b/drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c
index 1803a633ed64..99a0a89091e7 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c
@@ -902,6 +902,12 @@ static int ct_read(struct intel_guc_ct *ct, struct
ct_incoming_msg **msg)
/* now update descriptor */
WRITE_ONCE(desc->head, head);
+ /*
+* Wa_22016122933: Making sure the head update is
+* visible to GuC right away
+*/
+ intel_guc_write_barrier(ct_to_guc(ct));
+
return available - len;
corrupted:
--
2.25.1
[PATCH 1/2] drm/i915/mtl: Add PTE encode function
From: Fei Yang
PTE encode functions are platform dependent. This patch implements
PTE functions for MTL, and ensures the correct PTE encode function
is used by calling pte_encode function pointer instead of the
hardcoded gen8 version of PTE encode.
Fixes: b76c0deef627 ("drm/i915/mtl: Define MOCS and PAT tables for MTL")
Signed-off-by: Fei Yang
Reviewed-by: Andrzej Hajda
Reviewed-by: Andi Shyti
Acked-by: Nirmoy Das
---
drivers/gpu/drm/i915/display/intel_dpt.c | 2 +-
drivers/gpu/drm/i915/gt/gen8_ppgtt.c | 45
drivers/gpu/drm/i915/gt/intel_ggtt.c | 36 +--
drivers/gpu/drm/i915/gt/intel_gtt.h | 13 +--
4 files changed, 83 insertions(+), 13 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_dpt.c
b/drivers/gpu/drm/i915/display/intel_dpt.c
index b8027392144d..c5eacfdba1a5 100644
--- a/drivers/gpu/drm/i915/display/intel_dpt.c
+++ b/drivers/gpu/drm/i915/display/intel_dpt.c
@@ -300,7 +300,7 @@ intel_dpt_create(struct intel_framebuffer *fb)
vm->vma_ops.bind_vma= dpt_bind_vma;
vm->vma_ops.unbind_vma = dpt_unbind_vma;
- vm->pte_encode = gen8_ggtt_pte_encode;
+ vm->pte_encode = vm->gt->ggtt->vm.pte_encode;
dpt->obj = dpt_obj;
dpt->obj->is_dpt = true;
diff --git a/drivers/gpu/drm/i915/gt/gen8_ppgtt.c
b/drivers/gpu/drm/i915/gt/gen8_ppgtt.c
index 4daaa6f55668..11b91e0453c8 100644
--- a/drivers/gpu/drm/i915/gt/gen8_ppgtt.c
+++ b/drivers/gpu/drm/i915/gt/gen8_ppgtt.c
@@ -55,6 +55,34 @@ static u64 gen8_pte_encode(dma_addr_t addr,
return pte;
}
+static u64 mtl_pte_encode(dma_addr_t addr,
+ enum i915_cache_level level,
+ u32 flags)
+{
+ gen8_pte_t pte = addr | GEN8_PAGE_PRESENT | GEN8_PAGE_RW;
+
+ if (unlikely(flags & PTE_READ_ONLY))
+ pte &= ~GEN8_PAGE_RW;
+
+ if (flags & PTE_LM)
+ pte |= GEN12_PPGTT_PTE_LM | GEN12_PPGTT_PTE_NC;
+
+ switch (level) {
+ case I915_CACHE_NONE:
+ pte |= GEN12_PPGTT_PTE_PAT1;
+ break;
+ case I915_CACHE_LLC:
+ case I915_CACHE_L3_LLC:
+ pte |= GEN12_PPGTT_PTE_PAT0 | GEN12_PPGTT_PTE_PAT1;
+ break;
+ case I915_CACHE_WT:
+ pte |= GEN12_PPGTT_PTE_PAT0;
+ break;
+ }
+
+ return pte;
+}
+
static void gen8_ppgtt_notify_vgt(struct i915_ppgtt *ppgtt, bool create)
{
struct drm_i915_private *i915 = ppgtt->vm.i915;
@@ -427,7 +455,7 @@ gen8_ppgtt_insert_pte(struct i915_ppgtt *ppgtt,
u32 flags)
{
struct i915_page_directory *pd;
- const gen8_pte_t pte_encode = gen8_pte_encode(0, cache_level, flags);
+ const gen8_pte_t pte_encode = ppgtt->vm.pte_encode(0, cache_level,
flags);
gen8_pte_t *vaddr;
pd = i915_pd_entry(pdp, gen8_pd_index(idx, 2));
@@ -580,7 +608,7 @@ static void gen8_ppgtt_insert_huge(struct
i915_address_space *vm,
enum i915_cache_level cache_level,
u32 flags)
{
- const gen8_pte_t pte_encode = gen8_pte_encode(0, cache_level, flags);
+ const gen8_pte_t pte_encode = vm->pte_encode(0, cache_level, flags);
unsigned int rem = sg_dma_len(iter->sg);
u64 start = vma_res->start;
@@ -743,7 +771,7 @@ static void gen8_ppgtt_insert_entry(struct
i915_address_space *vm,
GEM_BUG_ON(pt->is_compact);
vaddr = px_vaddr(pt);
- vaddr[gen8_pd_index(idx, 0)] = gen8_pte_encode(addr, level, flags);
+ vaddr[gen8_pd_index(idx, 0)] = vm->pte_encode(addr, level, flags);
drm_clflush_virt_range(&vaddr[gen8_pd_index(idx, 0)], sizeof(*vaddr));
}
@@ -773,7 +801,7 @@ static void __xehpsdv_ppgtt_insert_entry_lm(struct
i915_address_space *vm,
}
vaddr = px_vaddr(pt);
- vaddr[gen8_pd_index(idx, 0) / 16] = gen8_pte_encode(addr, level, flags);
+ vaddr[gen8_pd_index(idx, 0) / 16] = vm->pte_encode(addr, level, flags);
}
static void xehpsdv_ppgtt_insert_entry(struct i915_address_space *vm,
@@ -820,8 +848,8 @@ static int gen8_init_scratch(struct i915_address_space *vm)
pte_flags |= PTE_LM;
vm->scratch[0]->encode =
- gen8_pte_encode(px_dma(vm->scratch[0]),
- I915_CACHE_NONE, pte_flags);
+ vm->pte_encode(px_dma(vm->scratch[0]),
+ I915_CACHE_NONE, pte_flags);
for (i = 1; i <= vm->top; i++) {
struct drm_i915_gem_object *obj;
@@ -963,7 +991,10 @@ struct i915_ppgtt *gen8_ppgtt_create(struct intel_gt *gt,
*/
ppgtt->vm.alloc_scratch_dma = alloc_pt_dma;
- ppgtt->vm.pte_encode = gen8_pte_encode;
+ if (GRAPHICS_VER_FULL(gt->i915) >= IP_VER(12, 70))
+ ppgtt->vm.pte_encode = mtl_pte_encode;
+ else
+ ppgtt->vm.pte_encode = gen8_pte_encode;
ppgtt->vm.bi
[PATCH 0/2] drm/i915/mtl: Add PTE encode functions
From: Fei Yang Extract PTE patch from https://patchwork.freedesktop.org/series/116868/ to fix MTL boot issue caused by MOCS/PAT update. Fei Yang (2): drm/i915/mtl: Add PTE encode function drm/i915/mtl: workaround coherency issue for Media drivers/gpu/drm/i915/display/intel_dpt.c | 2 +- drivers/gpu/drm/i915/gem/i915_gem_pages.c | 5 ++- drivers/gpu/drm/i915/gt/gen8_ppgtt.c | 45 +++ drivers/gpu/drm/i915/gt/intel_ggtt.c | 36 -- drivers/gpu/drm/i915/gt/intel_gtt.h | 13 ++- drivers/gpu/drm/i915/gt/uc/intel_gsc_fw.c | 13 +++ drivers/gpu/drm/i915/gt/uc/intel_guc.c| 7 drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c | 6 +++ 8 files changed, 113 insertions(+), 14 deletions(-) -- 2.25.1
Re: [PATCH] drm/amdgpu: Mark contexts guilty for any reset type
Soft resets are fatal just as hard resets, but no reset is "always fatal".
There are cases when apps keep working depending on which features are
being used. It's still unsafe.
Marek
On Mon, Apr 24, 2023, 03:03 Christian König
wrote:
> Am 24.04.23 um 03:43 schrieb André Almeida:
> > When a DRM job timeout, the GPU is probably hang and amdgpu have some
> > ways to deal with that, ranging from soft recoveries to full device
> > reset. Anyway, when userspace ask the kernel the state of the context
> > (via AMDGPU_CTX_OP_QUERY_STATE), the kernel reports that the device was
> > reset, regardless if a full reset happened or not.
> >
> > However, amdgpu only marks a context guilty in the ASIC reset path. This
> > makes the userspace report incomplete, given that on soft recovery path
> > the guilty context is not told that it's the guilty one.
> >
> > Fix this by marking the context guilty for every type of reset when a
> > job timeouts.
>
> The guilty handling is pretty much broken by design and only works
> because we go through multiple hops of validating the entity after the
> job has already been pushed to the hw.
>
> I think we should probably just remove that completely and use an
> approach where we check the in flight submissions in the query state
> IOCTL. See my other patch on the mailing list regarding that.
>
> Additional to that I currently didn't considered soft-recovered
> submissions as fatal and continue accepting submissions from that
> context, but already wanted to talk with Marek about that behavior.
>
> Regards,
> Christian.
>
> >
> > Signed-off-by: André Almeida
> > ---
> > drivers/gpu/drm/amd/amdgpu/amdgpu_device.c | 3 ---
> > drivers/gpu/drm/amd/amdgpu/amdgpu_job.c| 8 +++-
> > 2 files changed, 7 insertions(+), 4 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
> b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
> > index ac78caa7cba8..ea169d1689e2 100644
> > --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
> > +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
> > @@ -4771,9 +4771,6 @@ int amdgpu_device_pre_asic_reset(struct
> amdgpu_device *adev,
> >
> > amdgpu_fence_driver_isr_toggle(adev, false);
> >
> > - if (job && job->vm)
> > - drm_sched_increase_karma(&job->base);
> > -
> > r = amdgpu_reset_prepare_hwcontext(adev, reset_context);
> > /* If reset handler not implemented, continue; otherwise return */
> > if (r == -ENOSYS)
> > diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_job.c
> b/drivers/gpu/drm/amd/amdgpu/amdgpu_job.c
> > index c3d9d75143f4..097ed8f06865 100644
> > --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_job.c
> > +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_job.c
> > @@ -51,6 +51,13 @@ static enum drm_gpu_sched_stat
> amdgpu_job_timedout(struct drm_sched_job *s_job)
> > memset(&ti, 0, sizeof(struct amdgpu_task_info));
> > adev->job_hang = true;
> >
> > + amdgpu_vm_get_task_info(ring->adev, job->pasid, &ti);
> > +
> > + if (job && job->vm) {
> > + DRM_INFO("marking %s context as guilty", ti.process_name);
> > + drm_sched_increase_karma(&job->base);
> > + }
> > +
> > if (amdgpu_gpu_recovery &&
> > amdgpu_ring_soft_recovery(ring, job->vmid,
> s_job->s_fence->parent)) {
> > DRM_ERROR("ring %s timeout, but soft recovered\n",
> > @@ -58,7 +65,6 @@ static enum drm_gpu_sched_stat
> amdgpu_job_timedout(struct drm_sched_job *s_job)
> > goto exit;
> > }
> >
> > - amdgpu_vm_get_task_info(ring->adev, job->pasid, &ti);
> > DRM_ERROR("ring %s timeout, signaled seq=%u, emitted seq=%u\n",
> > job->base.sched->name,
> atomic_read(&ring->fence_drv.last_seq),
> > ring->fence_drv.sync_seq);
>
>
Re: [PATCH v8 1/5] drm: Place Renesas drivers in a separate dir
Quoting Biju Das (2023-04-24 17:10:20) > Create vendor specific renesas directory and move renesas drivers > to that directory. > > Signed-off-by: Biju Das Acked-by: Kieran Bingham
Re: [PATCH] drm/amd/display: return status of abm_feature_support
On 4/20/23 09:21, Tom Rix wrote:
gcc with W=1 reports
drivers/gpu/drm/amd/amdgpu/../display/dc/dce/dmub_abm.c:
In function ‘dmub_abm_set_event_ex’:
drivers/gpu/drm/amd/amdgpu/../display/dc/dce/dmub_abm.c:138:22: error: variable
‘feature_support’ set but not used [-Werror=unused-but-set-variable]
138 | unsigned int feature_support;
| ^~~
This variable is not used so remove it.
The status of amb_feature_support should have been returned, so
set ret and return it.
Fixes: b8fe56375f78 ("drm/amd/display: Refactor ABM feature")
Signed-off-by: Tom Rix
Since set_abm_event() is never used. I would prefer if it was dropped
entirely.
---
drivers/gpu/drm/amd/display/dc/dce/dmub_abm.c | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/amd/display/dc/dce/dmub_abm.c
b/drivers/gpu/drm/amd/display/dc/dce/dmub_abm.c
index a66f83a61402..8f285c3be4c6 100644
--- a/drivers/gpu/drm/amd/display/dc/dce/dmub_abm.c
+++ b/drivers/gpu/drm/amd/display/dc/dce/dmub_abm.c
@@ -134,10 +134,9 @@ static bool dmub_abm_set_pipe_ex(struct abm *abm, uint32_t
otg_inst, uint32_t op
static bool dmub_abm_set_event_ex(struct abm *abm, unsigned int full_screen,
unsigned int video_mode,
unsigned int hdr_mode, unsigned int panel_inst)
{
- bool ret = false;
- unsigned int feature_support;
+ bool ret;
- feature_support = abm_feature_support(abm, panel_inst);
+ ret = abm_feature_support(abm, panel_inst);
return ret;
}
--
Hamza
[drm-misc:drm-misc-next 11/19] drivers/video/sticore.c:888:14: sparse: sparse: cast to restricted __le32
Hi Thomas,
First bad commit (maybe != root cause):
tree: git://anongit.freedesktop.org/drm/drm-misc drm-misc-next
head: 70102d77ff22dd88a0111b1c3bac5099ac5d0425
commit: 7470849745e6cd746ae773a6e59b309867310181 [11/19] video: Move HP PARISC
STI core code to shared location
config: parisc-randconfig-s052-20230423
(https://download.01.org/0day-ci/archive/20230425/202304250018.7fbssppq-...@intel.com/config)
compiler: hppa-linux-gcc (GCC) 12.1.0
reproduce:
wget
https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O
~/bin/make.cross
chmod +x ~/bin/make.cross
# apt-get install sparse
# sparse version: v0.6.4-39-gce1a6720-dirty
git remote add drm-misc git://anongit.freedesktop.org/drm/drm-misc
git fetch --no-tags drm-misc drm-misc-next
git checkout 7470849745e6cd746ae773a6e59b309867310181
# save the config file
mkdir build_dir && cp config build_dir/.config
COMPILER_INSTALL_PATH=$HOME/0day COMPILER=gcc-12.1.0 make.cross C=1
CF='-fdiagnostic-prefix -D__CHECK_ENDIAN__' O=build_dir ARCH=parisc olddefconfig
COMPILER_INSTALL_PATH=$HOME/0day COMPILER=gcc-12.1.0 make.cross C=1
CF='-fdiagnostic-prefix -D__CHECK_ENDIAN__' O=build_dir ARCH=parisc
SHELL=/bin/bash drivers/video/
If you fix the issue, kindly add following tag where applicable
| Reported-by: kernel test robot
| Link:
https://lore.kernel.org/oe-kbuild-all/202304250018.7fbssppq-...@intel.com/
sparse warnings: (new ones prefixed by >>)
>> drivers/video/sticore.c:888:14: sparse: sparse: cast to restricted __le32
>> drivers/video/sticore.c:888:14: sparse: sparse: cast to restricted __le32
>> drivers/video/sticore.c:888:14: sparse: sparse: cast to restricted __le32
>> drivers/video/sticore.c:888:14: sparse: sparse: cast to restricted __le32
>> drivers/video/sticore.c:888:14: sparse: sparse: cast to restricted __le32
>> drivers/video/sticore.c:888:14: sparse: sparse: cast to restricted __le32
>> drivers/video/sticore.c:902:17: sparse: sparse: cast to restricted __le16
>> drivers/video/sticore.c:902:17: sparse: sparse: cast to restricted __le16
>> drivers/video/sticore.c:902:17: sparse: sparse: cast to restricted __le16
>> drivers/video/sticore.c:902:17: sparse: sparse: cast to restricted __le16
drivers/video/sticore.c:904:29: sparse: sparse: cast to restricted __le16
drivers/video/sticore.c:904:29: sparse: sparse: cast to restricted __le16
drivers/video/sticore.c:904:29: sparse: sparse: cast to restricted __le16
drivers/video/sticore.c:904:29: sparse: sparse: cast to restricted __le16
drivers/video/sticore.c:914:28: sparse: sparse: cast to restricted __le32
drivers/video/sticore.c:914:28: sparse: sparse: cast to restricted __le32
drivers/video/sticore.c:914:28: sparse: sparse: cast to restricted __le32
drivers/video/sticore.c:914:28: sparse: sparse: cast to restricted __le32
drivers/video/sticore.c:914:28: sparse: sparse: cast to restricted __le32
drivers/video/sticore.c:914:28: sparse: sparse: cast to restricted __le32
vim +888 drivers/video/sticore.c
^1da177e4c3f41 drivers/video/console/sticore.c Linus Torvalds 2005-04-16
859
48c68c4f1b5424 drivers/video/console/sticore.c Greg Kroah-Hartman 2012-12-21
860 static struct sti_struct *sti_try_rom_generic(unsigned long address,
48c68c4f1b5424 drivers/video/console/sticore.c Greg Kroah-Hartman 2012-12-21
861 unsigned long hpa,
48c68c4f1b5424 drivers/video/console/sticore.c Greg Kroah-Hartman 2012-12-21
862 struct pci_dev *pd)
^1da177e4c3f41 drivers/video/console/sticore.c Linus Torvalds 2005-04-16
863 {
^1da177e4c3f41 drivers/video/console/sticore.c Linus Torvalds 2005-04-16
864 struct sti_struct *sti;
^1da177e4c3f41 drivers/video/console/sticore.c Linus Torvalds 2005-04-16
865 int ok;
^1da177e4c3f41 drivers/video/console/sticore.c Linus Torvalds 2005-04-16
866 u32 sig;
^1da177e4c3f41 drivers/video/console/sticore.c Linus Torvalds 2005-04-16
867
^1da177e4c3f41 drivers/video/console/sticore.c Linus Torvalds 2005-04-16
868 if (num_sti_roms >= MAX_STI_ROMS) {
7ff3f14ddc355b drivers/video/console/sticore.c Helge Deller 2020-10-12
869 pr_warn("maximum number of STI ROMS reached !\n");
^1da177e4c3f41 drivers/video/console/sticore.c Linus Torvalds 2005-04-16
870 return NULL;
^1da177e4c3f41 drivers/video/console/sticore.c Linus Torvalds 2005-04-16
871 }
^1da177e4c3f41 drivers/video/console/sticore.c Linus Torvalds 2005-04-16
872
cb6fc18e9ca615 drivers/video/console/sticore.c Helge Deller 2006-01-17
873 sti = kzalloc(sizeof(*sti), GFP_KERNEL);
3af04d5c459485 drivers/video/console/sticore.c Markus Elfring 2018-03-28
874 if (!sti)
^1da177e4c3f41 drivers/video/console/sticore.c Linus Torvalds 2005-04-16
875 re
Re: [PATCH 0/2] Restore MTL boot
On 4/24/2023 6:09 PM, Andi Shyti wrote: Hi, The two patches reverted in this series are, together, preventing MTL from booting. Revert them until the fix is deployed. Andi Andi Shyti (2): Revert "drm/i915/mtl: fix mocs selftest" Revert "drm/i915/mtl: Define MOCS and PAT tables for MTL" Series is Reviewed-by: Nirmoy Das drivers/gpu/drm/i915/gt/intel_gt_regs.h | 6 +-- drivers/gpu/drm/i915/gt/intel_gtt.c | 47 + drivers/gpu/drm/i915/gt/intel_gtt.h | 8 --- drivers/gpu/drm/i915/gt/intel_mocs.c| 70 + drivers/gpu/drm/i915/gt/selftest_mocs.c | 3 +- 5 files changed, 4 insertions(+), 130 deletions(-)
[PATCH 2/2] Revert "drm/i915/mtl: Define MOCS and PAT tables for MTL"
This reverts commit b76c0deef6273609c02ed5053209f6397cd1b0fb.
This patch is causing boot failures for MTL.
Revert it.
Signed-off-by: Andi Shyti
Cc: Matt Roper
Cc: Lucas De Marchi
Cc: Aravind Iddamsetty
Cc: Nirmoy Das
Cc: Fei Yang
Cc: Andrzej Hajda
---
drivers/gpu/drm/i915/gt/intel_gt_regs.h | 6 +--
drivers/gpu/drm/i915/gt/intel_gtt.c | 47 +
drivers/gpu/drm/i915/gt/intel_gtt.h | 8 ---
drivers/gpu/drm/i915/gt/intel_mocs.c| 70 +
4 files changed, 3 insertions(+), 128 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/intel_gt_regs.h
b/drivers/gpu/drm/i915/gt/intel_gt_regs.h
index e8c3b762a92a3..fd1f9cd35e9d7 100644
--- a/drivers/gpu/drm/i915/gt/intel_gt_regs.h
+++ b/drivers/gpu/drm/i915/gt/intel_gt_regs.h
@@ -356,11 +356,7 @@
#define GEN7_TLB_RD_ADDR _MMIO(0x4700)
#define GEN12_PAT_INDEX(index) _MMIO(0x4800 + (index) * 4)
-#define _PAT_INDEX(index) _PICK_EVEN_2RANGES(index, 8, \
- 0x4800,
0x4804, \
- 0x4848,
0x484c)
-#define XEHP_PAT_INDEX(index) MCR_REG(_PAT_INDEX(index))
-#define XELPMP_PAT_INDEX(index)_MMIO(_PAT_INDEX(index))
+#define XEHP_PAT_INDEX(index) MCR_REG(0x4800 + (index) * 4)
#define XEHP_TILE0_ADDR_RANGE MCR_REG(0x4900)
#define XEHP_TILE_LMEM_RANGE_SHIFT 8
diff --git a/drivers/gpu/drm/i915/gt/intel_gtt.c
b/drivers/gpu/drm/i915/gt/intel_gtt.c
index 2f6a9be0ffe61..4f436ba7a3c83 100644
--- a/drivers/gpu/drm/i915/gt/intel_gtt.c
+++ b/drivers/gpu/drm/i915/gt/intel_gtt.c
@@ -468,44 +468,6 @@ void gtt_write_workarounds(struct intel_gt *gt)
}
}
-static void xelpmp_setup_private_ppat(struct intel_uncore *uncore)
-{
- intel_uncore_write(uncore, XELPMP_PAT_INDEX(0),
- MTL_PPAT_L4_0_WB);
- intel_uncore_write(uncore, XELPMP_PAT_INDEX(1),
- MTL_PPAT_L4_1_WT);
- intel_uncore_write(uncore, XELPMP_PAT_INDEX(2),
- MTL_PPAT_L4_3_UC);
- intel_uncore_write(uncore, XELPMP_PAT_INDEX(3),
- MTL_PPAT_L4_0_WB | MTL_2_COH_1W);
- intel_uncore_write(uncore, XELPMP_PAT_INDEX(4),
- MTL_PPAT_L4_0_WB | MTL_3_COH_2W);
-
- /*
-* Remaining PAT entries are left at the hardware-default
-* fully-cached setting
-*/
-}
-
-static void xelpg_setup_private_ppat(struct intel_gt *gt)
-{
- intel_gt_mcr_multicast_write(gt, XEHP_PAT_INDEX(0),
-MTL_PPAT_L4_0_WB);
- intel_gt_mcr_multicast_write(gt, XEHP_PAT_INDEX(1),
-MTL_PPAT_L4_1_WT);
- intel_gt_mcr_multicast_write(gt, XEHP_PAT_INDEX(2),
-MTL_PPAT_L4_3_UC);
- intel_gt_mcr_multicast_write(gt, XEHP_PAT_INDEX(3),
-MTL_PPAT_L4_0_WB | MTL_2_COH_1W);
- intel_gt_mcr_multicast_write(gt, XEHP_PAT_INDEX(4),
-MTL_PPAT_L4_0_WB | MTL_3_COH_2W);
-
- /*
-* Remaining PAT entries are left at the hardware-default
-* fully-cached setting
-*/
-}
-
static void tgl_setup_private_ppat(struct intel_uncore *uncore)
{
/* TGL doesn't support LLC or AGE settings */
@@ -641,14 +603,7 @@ void setup_private_pat(struct intel_gt *gt)
GEM_BUG_ON(GRAPHICS_VER(i915) < 8);
- if (gt->type == GT_MEDIA) {
- xelpmp_setup_private_ppat(gt->uncore);
- return;
- }
-
- if (GRAPHICS_VER_FULL(i915) >= IP_VER(12, 70))
- xelpg_setup_private_ppat(gt);
- else if (GRAPHICS_VER_FULL(i915) >= IP_VER(12, 50))
+ if (GRAPHICS_VER_FULL(i915) >= IP_VER(12, 50))
xehp_setup_private_ppat(gt);
else if (GRAPHICS_VER(i915) >= 12)
tgl_setup_private_ppat(uncore);
diff --git a/drivers/gpu/drm/i915/gt/intel_gtt.h
b/drivers/gpu/drm/i915/gt/intel_gtt.h
index ea17849e7a5c8..69ce55f517f56 100644
--- a/drivers/gpu/drm/i915/gt/intel_gtt.h
+++ b/drivers/gpu/drm/i915/gt/intel_gtt.h
@@ -147,14 +147,6 @@ typedef u64 gen8_pte_t;
#define GEN8_PDE_IPS_64K BIT(11)
#define GEN8_PDE_PS_2M BIT(7)
-#define MTL_PPAT_L4_CACHE_POLICY_MASK REG_GENMASK(3, 2)
-#define MTL_PAT_INDEX_COH_MODE_MASKREG_GENMASK(1, 0)
-#define MTL_PPAT_L4_3_UC REG_FIELD_PREP(MTL_PPAT_L4_CACHE_POLICY_MASK, 3)
-#define MTL_PPAT_L4_1_WT REG_FIELD_PREP(MTL_PPAT_L4_CACHE_POLICY_MASK, 1)
-#define MTL_PPAT_L4_0_WB REG_FIELD_PREP(MTL_PPAT_L4_CACHE_POLICY_MASK, 0)
-#define MTL_3_COH_2W REG_FIELD_PREP(MTL_PAT_INDEX_COH_MODE_MASK, 3)
-#define MTL_2_COH_1W REG_FIELD_PREP(MTL_PAT_INDEX_COH_MODE_MASK, 2)
-
enum i915_cache_level;
struct drm_i915_gem_object;
diff --git a/drivers/
[PATCH 0/2] Restore MTL boot
Hi, The two patches reverted in this series are, together, preventing MTL from booting. Revert them until the fix is deployed. Andi Andi Shyti (2): Revert "drm/i915/mtl: fix mocs selftest" Revert "drm/i915/mtl: Define MOCS and PAT tables for MTL" drivers/gpu/drm/i915/gt/intel_gt_regs.h | 6 +-- drivers/gpu/drm/i915/gt/intel_gtt.c | 47 + drivers/gpu/drm/i915/gt/intel_gtt.h | 8 --- drivers/gpu/drm/i915/gt/intel_mocs.c| 70 + drivers/gpu/drm/i915/gt/selftest_mocs.c | 3 +- 5 files changed, 4 insertions(+), 130 deletions(-) -- 2.40.0
[PATCH v8 5/5] MAINTAINERS: Add maintainer for RZ DU drivers
Add my self as maintainer for RZ DU drivers. While at it, update the entries for rcar-du and shmobile. Signed-off-by: Biju Das --- v8: * New patch --- MAINTAINERS | 13 +++-- 1 file changed, 11 insertions(+), 2 deletions(-) diff --git a/MAINTAINERS b/MAINTAINERS index 1218a2ec6d97..42db5be4482c 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -6948,7 +6948,7 @@ F:drivers/gpu/host1x/ F: include/linux/host1x.h F: include/uapi/drm/tegra_drm.h -DRM DRIVERS FOR RENESAS +DRM DRIVERS FOR RENESAS RCAR AND SHMOBILE M: Laurent Pinchart M: Kieran Bingham L: dri-devel@lists.freedesktop.org @@ -6959,9 +6959,18 @@ F: Documentation/devicetree/bindings/display/bridge/renesas,dsi-csi2-tx.yaml F: Documentation/devicetree/bindings/display/bridge/renesas,dw-hdmi.yaml F: Documentation/devicetree/bindings/display/bridge/renesas,lvds.yaml F: Documentation/devicetree/bindings/display/renesas,du.yaml -F: drivers/gpu/drm/renesas/ +F: drivers/gpu/drm/renesas/rcar-du/ +F: drivers/gpu/drm/renesas/shmobile/ F: include/linux/platform_data/shmob_drm.h +DRM DRIVERS FOR RENESAS RZ +M: Biju Das +L: dri-devel@lists.freedesktop.org +L: linux-renesas-...@vger.kernel.org +S: Maintained +F: Documentation/devicetree/bindings/display/renesas,rzg2l-du.yaml +F: drivers/gpu/drm/renesas/rz-du/ + DRM DRIVERS FOR ROCKCHIP M: Sandy Huang M: Heiko Stübner -- 2.25.1
[PATCH v8 3/5] dt-bindings: display: renesas, rzg2l-du: Document RZ/V2L DU bindings
Document DU found in RZ/V2L SoC. The DU block is identical to RZ/G2L
SoC and therefore use RZ/G2L fallback to avoid any driver changes.
Signed-off-by: Biju Das
Reviewed-by: Rob Herring
---
v7->v8:
* Fixed the typo vsp2->du
* Added Rb tag from Rob as the change is trivial.
v7:
* New patch.
---
.../devicetree/bindings/display/renesas,rzg2l-du.yaml| 9 +++--
1 file changed, 7 insertions(+), 2 deletions(-)
diff --git a/Documentation/devicetree/bindings/display/renesas,rzg2l-du.yaml
b/Documentation/devicetree/bindings/display/renesas,rzg2l-du.yaml
index ab99e7d57a7d..98686ea84d53 100644
--- a/Documentation/devicetree/bindings/display/renesas,rzg2l-du.yaml
+++ b/Documentation/devicetree/bindings/display/renesas,rzg2l-du.yaml
@@ -16,8 +16,13 @@ description: |
properties:
compatible:
-enum:
- - renesas,r9a07g044-du # RZ/G2{L,LC}
+oneOf:
+ - enum:
+ - renesas,r9a07g044-du # RZ/G2{L,LC}
+ - items:
+ - enum:
+ - renesas,r9a07g054-du# RZ/V2L
+ - const: renesas,r9a07g044-du # RZ/G2L fallback
reg:
maxItems: 1
--
2.25.1
[PATCH v8 4/5] drm: Add RZ/G2L DU Support
The LCD controller is composed of Frame Compression Processor (FCPVD),
Video Signal Processor (VSPD), and Display Unit (DU).
It has DPI/DSI interfaces and supports a maximum resolution of 1080p
along with 2 RPFs to support the blending of two picture layers and
raster operations (ROPs).
The DU module is connected to VSPD. Add RZ/G2L DU support for RZ/G2L
alike SoCs.
Signed-off-by: Biju Das
---
v7->v8:
Ref:
https://lore.kernel.org/linux-renesas-soc/os0pr01mb5922717e4ccfe07f3c25fbc986...@os0pr01mb5922.jpnprd01.prod.outlook.com/#t
* Dropped RCar du lib and created RZ/G2L DU DRM driver by creating rz_du
folder.
* Updated KConfig and Makefile.
v6->v7:
* Split DU lib and RZ/G2L du driver as separate patch series as
DU support added to more platforms based on RZ/G2L alike SoCs.
* Rebased to latest drm-tip.
* Added patch #2 for binding support for RZ/V2L DU
* Added patch #4 for driver support for RZ/V2L DU
* Added patch #5 for SoC DTSI support for RZ/G2L DU
* Added patch #6 for SoC DTSI support for RZ/V2L DU
* Added patch #7 for Enabling DU on SMARC EVK based on RZ/{G2L,V2L} SoCs.
* Added patch #8 for Enabling DU on SMARC EVK based on RZ/G2LC SoC.
---
drivers/gpu/drm/renesas/Kconfig | 1 +
drivers/gpu/drm/renesas/Makefile | 1 +
drivers/gpu/drm/renesas/rz-du/Kconfig | 20 +
drivers/gpu/drm/renesas/rz-du/Makefile| 8 +
drivers/gpu/drm/renesas/rz-du/rzg2l_du_crtc.c | 716
drivers/gpu/drm/renesas/rz-du/rzg2l_du_crtc.h | 99 +++
drivers/gpu/drm/renesas/rz-du/rzg2l_du_drv.c | 188 +
drivers/gpu/drm/renesas/rz-du/rzg2l_du_drv.h | 89 ++
.../gpu/drm/renesas/rz-du/rzg2l_du_encoder.c | 112 +++
.../gpu/drm/renesas/rz-du/rzg2l_du_encoder.h | 28 +
drivers/gpu/drm/renesas/rz-du/rzg2l_du_kms.c | 770 ++
drivers/gpu/drm/renesas/rz-du/rzg2l_du_kms.h | 43 +
drivers/gpu/drm/renesas/rz-du/rzg2l_du_regs.h | 67 ++
drivers/gpu/drm/renesas/rz-du/rzg2l_du_vsp.c | 430 ++
drivers/gpu/drm/renesas/rz-du/rzg2l_du_vsp.h | 94 +++
15 files changed, 2666 insertions(+)
create mode 100644 drivers/gpu/drm/renesas/rz-du/Kconfig
create mode 100644 drivers/gpu/drm/renesas/rz-du/Makefile
create mode 100644 drivers/gpu/drm/renesas/rz-du/rzg2l_du_crtc.c
create mode 100644 drivers/gpu/drm/renesas/rz-du/rzg2l_du_crtc.h
create mode 100644 drivers/gpu/drm/renesas/rz-du/rzg2l_du_drv.c
create mode 100644 drivers/gpu/drm/renesas/rz-du/rzg2l_du_drv.h
create mode 100644 drivers/gpu/drm/renesas/rz-du/rzg2l_du_encoder.c
create mode 100644 drivers/gpu/drm/renesas/rz-du/rzg2l_du_encoder.h
create mode 100644 drivers/gpu/drm/renesas/rz-du/rzg2l_du_kms.c
create mode 100644 drivers/gpu/drm/renesas/rz-du/rzg2l_du_kms.h
create mode 100644 drivers/gpu/drm/renesas/rz-du/rzg2l_du_regs.h
create mode 100644 drivers/gpu/drm/renesas/rz-du/rzg2l_du_vsp.c
create mode 100644 drivers/gpu/drm/renesas/rz-du/rzg2l_du_vsp.h
diff --git a/drivers/gpu/drm/renesas/Kconfig b/drivers/gpu/drm/renesas/Kconfig
index 3777dad17f81..21862a8ef710 100644
--- a/drivers/gpu/drm/renesas/Kconfig
+++ b/drivers/gpu/drm/renesas/Kconfig
@@ -1,4 +1,5 @@
# SPDX-License-Identifier: GPL-2.0-only
source "drivers/gpu/drm/renesas/rcar-du/Kconfig"
+source "drivers/gpu/drm/renesas/rz-du/Kconfig"
source "drivers/gpu/drm/renesas/shmobile/Kconfig"
diff --git a/drivers/gpu/drm/renesas/Makefile b/drivers/gpu/drm/renesas/Makefile
index ec0e89e7a592..b8d8bc53967f 100644
--- a/drivers/gpu/drm/renesas/Makefile
+++ b/drivers/gpu/drm/renesas/Makefile
@@ -1,4 +1,5 @@
# SPDX-License-Identifier: GPL-2.0
obj-y += rcar-du/
+obj-y += rz-du/
obj-$(CONFIG_DRM_SHMOBILE) += shmobile/
diff --git a/drivers/gpu/drm/renesas/rz-du/Kconfig
b/drivers/gpu/drm/renesas/rz-du/Kconfig
new file mode 100644
index ..90b1bf72e23b
--- /dev/null
+++ b/drivers/gpu/drm/renesas/rz-du/Kconfig
@@ -0,0 +1,20 @@
+# SPDX-License-Identifier: GPL-2.0
+config DRM_RZG2L_DU
+ tristate "DRM Support for RZ/G2L Display Unit"
+ depends on DRM && OF
+ depends on ARM64
+ depends on DRM_RCAR_VSP
+ depends on ARCH_RZG2L || COMPILE_TEST
+ select DRM_KMS_HELPER
+ select DRM_GEM_DMA_HELPER
+ select VIDEOMODE_HELPERS
+ help
+ Choose this option if you have an RZ/G2L alike chipset.
+ If M is selected the module will be called rzg2l-du-drm.
+
+config DRM_RCAR_VSP
+ bool "R-Car DU VSP Compositor Support" if ARM
+ default y if ARM64
+ depends on VIDEO_RENESAS_VSP1
+ help
+ Enable support to expose the R-Car VSP Compositor as KMS planes.
diff --git a/drivers/gpu/drm/renesas/rz-du/Makefile
b/drivers/gpu/drm/renesas/rz-du/Makefile
new file mode 100644
index ..2cdf3ccd0459
--- /dev/null
+++ b/drivers/gpu/drm/renesas/rz-du/Makefile
@@ -0,0 +1,8 @@
+# SPDX-License-Identifier: GPL-2.0
+rzg2l-du-drm-y := rzg2l_du_crtc.o \
+ rzg2l_du_drv.o \
+ rzg2l_du_encoder.o \
+
[PATCH v8 2/5] dt-bindings: display: Document Renesas RZ/G2L DU bindings
The RZ/G2L LCD controller is composed of Frame Compression Processor
(FCPVD), Video Signal Processor (VSPD), and Display Unit (DU).
The DU module supports the following hardware features
− Display Parallel Interface (DPI) and MIPI LINK Video Interface
− Display timing master
− Generates video timings
− Selecting the polarity of output DCLK, HSYNC, VSYNC, and DE
− Supports Progressive
− Input data format (from VSPD): RGB888, RGB666
− Output data format: same as Input data format
− Supporting Full HD (1920 pixels x 1080 lines) for MIPI-DSI Output
− Supporting WXGA (1280 pixels x 800 lines) for Parallel Output
This patch document DU module found on RZ/G2L LCDC.
Signed-off-by: Biju Das
Reviewed-by: Rob Herring
---
v7->v8:
* No change
v6->v7:
* No change
v5->v6:
* No change.
v4->v5:
* Added Rb tag from Rob.
v3->v4:
* Changed compatible name from renesas,du-r9a07g044->renesas,r9a07g044-du
* started using same compatible for RZ/G2{L,LC}
v3: New patch
---
.../bindings/display/renesas,rzg2l-du.yaml| 124 ++
1 file changed, 124 insertions(+)
create mode 100644
Documentation/devicetree/bindings/display/renesas,rzg2l-du.yaml
diff --git a/Documentation/devicetree/bindings/display/renesas,rzg2l-du.yaml
b/Documentation/devicetree/bindings/display/renesas,rzg2l-du.yaml
new file mode 100644
index ..ab99e7d57a7d
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/renesas,rzg2l-du.yaml
@@ -0,0 +1,124 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/display/renesas,rzg2l-du.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Renesas RZ/G2L Display Unit (DU)
+
+maintainers:
+ - Biju Das
+ - Laurent Pinchart
+
+description: |
+ These DT bindings describe the Display Unit embedded in the Renesas RZ/G2L
+ and RZ/V2L SoCs.
+
+properties:
+ compatible:
+enum:
+ - renesas,r9a07g044-du # RZ/G2{L,LC}
+
+ reg:
+maxItems: 1
+
+ interrupts:
+maxItems: 1
+
+ clocks:
+items:
+ - description: Main clock
+ - description: Register access clock
+ - description: Video clock
+
+ clock-names:
+items:
+ - const: aclk
+ - const: pclk
+ - const: vclk
+
+ resets:
+maxItems: 1
+
+ power-domains:
+maxItems: 1
+
+ ports:
+$ref: /schemas/graph.yaml#/properties/ports
+description: |
+ The connections to the DU output video ports are modeled using the OF
+ graph bindings specified in Documentation/devicetree/bindings/graph.txt.
+ The number of ports and their assignment are model-dependent. Each port
+ shall have a single endpoint.
+
+patternProperties:
+ "^port@[0-1]$":
+$ref: /schemas/graph.yaml#/properties/port
+unevaluatedProperties: false
+
+required:
+ - port@0
+
+unevaluatedProperties: false
+
+ renesas,vsps:
+$ref: "/schemas/types.yaml#/definitions/phandle-array"
+items:
+ items:
+- description: phandle to VSP instance that serves the DU channel
+- description: Channel index identifying the LIF instance in that VSP
+description:
+ A list of phandle and channel index tuples to the VSPs that handle the
+ memory interfaces for the DU channels.
+
+required:
+ - compatible
+ - reg
+ - interrupts
+ - clocks
+ - clock-names
+ - resets
+ - power-domains
+ - ports
+ - renesas,vsps
+
+additionalProperties: false
+
+examples:
+ # RZ/G2L DU
+ - |
+#include
+#include
+
+display@1089 {
+compatible = "renesas,r9a07g044-du";
+reg = <0x1089 0x1>;
+interrupts = ;
+clocks = <&cpg CPG_MOD R9A07G044_LCDC_CLK_A>,
+ <&cpg CPG_MOD R9A07G044_LCDC_CLK_P>,
+ <&cpg CPG_MOD R9A07G044_LCDC_CLK_D>;
+clock-names = "aclk", "pclk", "vclk";
+resets = <&cpg R9A07G044_LCDC_RESET_N>;
+power-domains = <&cpg>;
+
+renesas,vsps = <&vspd0 0>;
+
+ports {
+#address-cells = <1>;
+#size-cells = <0>;
+
+port@0 {
+reg = <0>;
+endpoint {
+remote-endpoint = <&dsi0_in>;
+};
+};
+port@1 {
+reg = <1>;
+endpoint {
+};
+};
+};
+};
+
+...
--
2.25.1
[PATCH v8 1/5] drm: Place Renesas drivers in a separate dir
Create vendor specific renesas directory and move renesas drivers
to that directory.
Signed-off-by: Biju Das
---
MAINTAINERS | 3 +--
drivers/gpu/drm/Kconfig | 4 +---
drivers/gpu/drm/Makefile | 3 +--
drivers/gpu/drm/renesas/Kconfig | 4
drivers/gpu/drm/renesas/Makefile | 4
drivers/gpu/drm/{ => renesas}/rcar-du/Kconfig| 0
drivers/gpu/drm/{ => renesas}/rcar-du/Makefile | 0
drivers/gpu/drm/{ => renesas}/rcar-du/rcar_cmm.c | 0
drivers/gpu/drm/{ => renesas}/rcar-du/rcar_cmm.h | 0
drivers/gpu/drm/{ => renesas}/rcar-du/rcar_du_crtc.c | 0
drivers/gpu/drm/{ => renesas}/rcar-du/rcar_du_crtc.h | 0
drivers/gpu/drm/{ => renesas}/rcar-du/rcar_du_drv.c | 0
drivers/gpu/drm/{ => renesas}/rcar-du/rcar_du_drv.h | 0
drivers/gpu/drm/{ => renesas}/rcar-du/rcar_du_encoder.c | 0
drivers/gpu/drm/{ => renesas}/rcar-du/rcar_du_encoder.h | 0
drivers/gpu/drm/{ => renesas}/rcar-du/rcar_du_group.c| 0
drivers/gpu/drm/{ => renesas}/rcar-du/rcar_du_group.h| 0
drivers/gpu/drm/{ => renesas}/rcar-du/rcar_du_kms.c | 0
drivers/gpu/drm/{ => renesas}/rcar-du/rcar_du_kms.h | 0
drivers/gpu/drm/{ => renesas}/rcar-du/rcar_du_plane.c| 0
drivers/gpu/drm/{ => renesas}/rcar-du/rcar_du_plane.h| 0
drivers/gpu/drm/{ => renesas}/rcar-du/rcar_du_regs.h | 0
drivers/gpu/drm/{ => renesas}/rcar-du/rcar_du_vsp.c | 0
drivers/gpu/drm/{ => renesas}/rcar-du/rcar_du_vsp.h | 0
drivers/gpu/drm/{ => renesas}/rcar-du/rcar_du_writeback.c| 0
drivers/gpu/drm/{ => renesas}/rcar-du/rcar_du_writeback.h| 0
drivers/gpu/drm/{ => renesas}/rcar-du/rcar_dw_hdmi.c | 0
drivers/gpu/drm/{ => renesas}/rcar-du/rcar_lvds.c| 0
drivers/gpu/drm/{ => renesas}/rcar-du/rcar_lvds.h| 0
drivers/gpu/drm/{ => renesas}/rcar-du/rcar_lvds_regs.h | 0
drivers/gpu/drm/{ => renesas}/rcar-du/rcar_mipi_dsi.c| 0
drivers/gpu/drm/{ => renesas}/rcar-du/rcar_mipi_dsi.h| 0
drivers/gpu/drm/{ => renesas}/rcar-du/rcar_mipi_dsi_regs.h | 0
drivers/gpu/drm/{ => renesas}/rcar-du/rzg2l_mipi_dsi.c | 0
drivers/gpu/drm/{ => renesas}/rcar-du/rzg2l_mipi_dsi_regs.h | 0
drivers/gpu/drm/{ => renesas}/shmobile/Kconfig | 0
drivers/gpu/drm/{ => renesas}/shmobile/Makefile | 0
drivers/gpu/drm/{ => renesas}/shmobile/shmob_drm_backlight.c | 0
drivers/gpu/drm/{ => renesas}/shmobile/shmob_drm_backlight.h | 0
drivers/gpu/drm/{ => renesas}/shmobile/shmob_drm_crtc.c | 0
drivers/gpu/drm/{ => renesas}/shmobile/shmob_drm_crtc.h | 0
drivers/gpu/drm/{ => renesas}/shmobile/shmob_drm_drv.c | 0
drivers/gpu/drm/{ => renesas}/shmobile/shmob_drm_drv.h | 0
drivers/gpu/drm/{ => renesas}/shmobile/shmob_drm_kms.c | 0
drivers/gpu/drm/{ => renesas}/shmobile/shmob_drm_kms.h | 0
drivers/gpu/drm/{ => renesas}/shmobile/shmob_drm_plane.c | 0
drivers/gpu/drm/{ => renesas}/shmobile/shmob_drm_plane.h | 0
drivers/gpu/drm/{ => renesas}/shmobile/shmob_drm_regs.h | 0
48 files changed, 11 insertions(+), 7 deletions(-)
create mode 100644 drivers/gpu/drm/renesas/Kconfig
create mode 100644 drivers/gpu/drm/renesas/Makefile
rename drivers/gpu/drm/{ => renesas}/rcar-du/Kconfig (100%)
rename drivers/gpu/drm/{ => renesas}/rcar-du/Makefile (100%)
rename drivers/gpu/drm/{ => renesas}/rcar-du/rcar_cmm.c (100%)
rename drivers/gpu/drm/{ => renesas}/rcar-du/rcar_cmm.h (100%)
rename drivers/gpu/drm/{ => renesas}/rcar-du/rcar_du_crtc.c (100%)
rename drivers/gpu/drm/{ => renesas}/rcar-du/rcar_du_crtc.h (100%)
rename drivers/gpu/drm/{ => renesas}/rcar-du/rcar_du_drv.c (100%)
rename drivers/gpu/drm/{ => renesas}/rcar-du/rcar_du_drv.h (100%)
rename drivers/gpu/drm/{ => renesas}/rcar-du/rcar_du_encoder.c (100%)
rename drivers/gpu/drm/{ => renesas}/rcar-du/rcar_du_encoder.h (100%)
rename drivers/gpu/drm/{ => renesas}/rcar-du/rcar_du_group.c (100%)
rename drivers/gpu/drm/{ => renesas}/rcar-du/rcar_du_group.h (100%)
rename drivers/gpu/drm/{ => renesas}/rcar-du/rcar_du_kms.c (100%)
rename drivers/gpu/drm/{ => renesas}/rcar-du/rcar_du_kms.h (100%)
rename drivers/gpu/drm/{ => renesas}/rcar-du/rcar_du_plane.c (100%)
rename drivers/gpu/drm/{ => renesas}/rcar-du/rcar_du_plane.h (100%)
rename drivers/gpu/drm/{ => renesas}/rcar-du/rcar_du_regs.h (100%)
rename drivers/gpu/drm/{ => renesas}/rcar-du/rcar_du_vsp.c (100%)
rename drivers/gpu/drm/{ => renesas}/rcar-du/rcar_du_vsp.h (100%)
rename drivers/gpu/drm/{ => renesas}/rcar-du/rcar_du_writeback.c (100%)
rename drivers/gpu/drm/{ => renesas}/rcar-du/rcar_du_writeback.h (100%)
rename drivers/gpu/drm/{ => renesas}/rcar-du/rcar_dw_hdmi.c (100%)
rename drivers/gpu/drm/{ => renesas}/rcar-du/r
[PATCH 1/2] Revert "drm/i915/mtl: fix mocs selftest"
This reverts commit faca6aaa4838c3c234caa619d3c7d1f09da0d303.
This patch, in series with the next "Define MOCS and PAT tables
for MTL" are causing boot failures for MTL.
Revert them both.
Signed-off-by: Andi Shyti
Cc: Fei Yang
Cc: Matt Roper
---
drivers/gpu/drm/i915/gt/selftest_mocs.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/selftest_mocs.c
b/drivers/gpu/drm/i915/gt/selftest_mocs.c
index a8446ab825012..ca009a6a13bdb 100644
--- a/drivers/gpu/drm/i915/gt/selftest_mocs.c
+++ b/drivers/gpu/drm/i915/gt/selftest_mocs.c
@@ -131,14 +131,13 @@ static int read_mocs_table(struct i915_request *rq,
const struct drm_i915_mocs_table *table,
u32 *offset)
{
- struct intel_gt *gt = rq->engine->gt;
u32 addr;
if (!table)
return 0;
if (HAS_GLOBAL_MOCS_REGISTERS(rq->engine->i915))
- addr = global_mocs_offset() + gt->uncore->gsi_offset;
+ addr = global_mocs_offset();
else
addr = mocs_offset(rq->engine);
--
2.40.0
[PATCH v8 0/5] Add RZ/{G2L,G2LC} and RZ/V2L Display Unit support
RZ/G2L LCD controller composed of Frame compression Processor(FCPVD), Video
signal processor (VSPD) and Display unit(DU). The output of LCDC is
connected to Display parallel interface and MIPI link video interface.
The output from DSI is connected to ADV7535.
Created a vendor specific directory renesas and moved all renesas drm drivers
to it (rcar-du and shmobile). Then added support for RZ/G2L DU DRM driver by
creating rz_du directory.
v7->v8:
Ref:
https://lore.kernel.org/linux-renesas-soc/os0pr01mb5922717e4ccfe07f3c25fbc986...@os0pr01mb5922.jpnprd01.prod.outlook.com/#t
* Moved rcar-du and shmobile DRM drivers to renesas specific vendor directory.
* Fixed the typo vsp2->du in RZ/V2L DU bindings patch.
* Added Rb tag from Rob for RZ/V2L DU bindings patch.
* Dropped RCar du lib and created RZ/G2L DU DRM driver by creating rz_du
folder.
* Updated MAINTAINERS entries.
v6->v7:
* Split DU lib and RZ/G2L du driver as separate patch series as
DU support added to more platforms based on RZ/G2L alike SoCs.
* Rebased to latest drm-tip.
* Added patch #2 for binding support for RZ/V2L DU
* Added patch #4 for driver support for RZ/V2L DU
* Added patch #5 for SoC DTSI support for RZ/G2L DU
* Added patch #6 for SoC DTSI support for RZ/V2L DU
* Added patch #7 for Enabling DU on SMARC EVK based on RZ/{G2L,V2L} SoCs.
* Added patch #8 for Enabling DU on SMARC EVK based on RZ/G2LC SoC.
v5->v6:
* Merged DU lib and RZ/G2L du driver in same patch series
* Rebased to latest drm-misc.
* Merged patch#1 to RZ/G2L Driver patch.
* Updated KConfig dependency from ARCH_RENESAS->ARCH_RZG2L.
* Optimized rzg2l_du_output_name() by removing unsupported outputs.
v4->v5:
* Added Rb tag from Rob for binding patch.
* Started using RCar DU libs(kms, vsp and encoder)
* Started using rcar_du_device, rcar_du_write, rcar_du_crtc,
rcar_du_format_info and rcar_du_encoder.
v3->v4:
* Changed compatible name from renesas,du-r9a07g044->renesas,r9a07g044-du
* started using same compatible for RZ/G2{L,LC}
* Removed rzg2l_du_group.h and struct rzg2l_du_group
* Renamed __rzg2l_du_group_start_stop->rzg2l_du_start_stop
* Removed rzg2l_du_group_restart
* Updated rzg2l_du_crtc_set_display_timing
* Removed mode_valid callback.
* Updated rzg2l_du_crtc_create() parameters
* Updated compatible
* Removed RZG2L_DU_MAX_GROUPS
V2->v3:
* Added new bindings for RZ/G2L DU
* Removed indirection and created new DRM driver based on R-Car DU
v1->v2:
* Based on [1], all references to 'rzg2l_lcdc' replaced with 'rzg2l_du'
* Updated commit description for bindings
* Removed LCDC references from bindings
* Changed clock name from du.0->aclk from bindings
* Changed reset name from du.0->du from bindings
* Replaced crtc_helper_funcs->rcar_crtc_helper_funcs
* Updated macro DRM_RZG2L_LCDC->DRM_RZG2L_DU
* Replaced rzg2l-lcdc-drm->rzg2l-du-drm
* Added forward declaration for struct reset_control
[1]
https://patchwork.kernel.org/project/linux-renesas-soc/patch/20220312084205.31462-2-biju.das...@bp.renesas.com/
Biju Das (5):
drm: Place Renesas drivers in a separate dir
dt-bindings: display: Document Renesas RZ/G2L DU bindings
dt-bindings: display: renesas,rzg2l-du: Document RZ/V2L DU bindings
drm: Add RZ/G2L DU Support
MAINTAINERS: Add maintainer for RZ DU drivers
.../bindings/display/renesas,rzg2l-du.yaml| 129 +++
MAINTAINERS | 14 +-
drivers/gpu/drm/Kconfig | 4 +-
drivers/gpu/drm/Makefile | 3 +-
drivers/gpu/drm/renesas/Kconfig | 5 +
drivers/gpu/drm/renesas/Makefile | 5 +
drivers/gpu/drm/{ => renesas}/rcar-du/Kconfig | 0
.../gpu/drm/{ => renesas}/rcar-du/Makefile| 0
.../gpu/drm/{ => renesas}/rcar-du/rcar_cmm.c | 0
.../gpu/drm/{ => renesas}/rcar-du/rcar_cmm.h | 0
.../drm/{ => renesas}/rcar-du/rcar_du_crtc.c | 0
.../drm/{ => renesas}/rcar-du/rcar_du_crtc.h | 0
.../drm/{ => renesas}/rcar-du/rcar_du_drv.c | 0
.../drm/{ => renesas}/rcar-du/rcar_du_drv.h | 0
.../{ => renesas}/rcar-du/rcar_du_encoder.c | 0
.../{ => renesas}/rcar-du/rcar_du_encoder.h | 0
.../drm/{ => renesas}/rcar-du/rcar_du_group.c | 0
.../drm/{ => renesas}/rcar-du/rcar_du_group.h | 0
.../drm/{ => renesas}/rcar-du/rcar_du_kms.c | 0
.../drm/{ => renesas}/rcar-du/rcar_du_kms.h | 0
.../drm/{ => renesas}/rcar-du/rcar_du_plane.c | 0
.../drm/{ => renesas}/rcar-du/rcar_du_plane.h | 0
.../drm/{ => renesas}/rcar-du/rcar_du_regs.h | 0
.../drm/{ => renesas}/rcar-du/rcar_du_vsp.c | 0
.../drm/{ => renesas}/rcar-du/rcar_du_vsp.h | 0
.../{ => renesas}/rcar-du/rcar_du_writeback.c | 0
.../{ => renesas}/rcar-du/rcar_du_writeback.h | 0
.../drm/{ => renesas}/rcar-du/rcar_dw_hdmi.c | 0
.../gpu/drm/{ => renesas}/rcar-du/rcar_lvds.c | 0
.../gpu/drm/{ => renesas}/rcar-du/rcar_lvds.h | 0
.../{ => renesas}/rcar-du/rcar_lvds_regs.h| 0
.../drm/{ => renesas}/rcar-
Re: [PATCH] drm/amd/display: remove unused variables dispclk_delay_subtotal and dout
On 4/20/23 14:07, Tom Rix wrote:
clang with W=1 reports
drivers/gpu/drm/amd/amdgpu/../display/dc/dml/dcn314/display_rq_dlg_calc_314.c:1003:15:
error: variable 'dispclk_delay_subtotal' set but not used
[-Werror,-Wunused-but-set-variable]
unsigned int dispclk_delay_subtotal;
^
This variable is not used, so remove it.
Which made dout unused, so also remove.
Signed-off-by: Tom Rix
Applied, thanks!
---
.../display/dc/dml/dcn314/display_rq_dlg_calc_314.c| 10 --
1 file changed, 10 deletions(-)
diff --git
a/drivers/gpu/drm/amd/display/dc/dml/dcn314/display_rq_dlg_calc_314.c
b/drivers/gpu/drm/amd/display/dc/dml/dcn314/display_rq_dlg_calc_314.c
index ea4eb66066c4..239cb8160c77 100644
--- a/drivers/gpu/drm/amd/display/dc/dml/dcn314/display_rq_dlg_calc_314.c
+++ b/drivers/gpu/drm/amd/display/dc/dml/dcn314/display_rq_dlg_calc_314.c
@@ -951,7 +951,6 @@ static void dml_rq_dlg_get_dlg_params(
{
const display_pipe_source_params_st *src =
&e2e_pipe_param[pipe_idx].pipe.src;
const display_pipe_dest_params_st *dst =
&e2e_pipe_param[pipe_idx].pipe.dest;
- const display_output_params_st *dout = &e2e_pipe_param[pipe_idx].dout;
const display_clocks_and_cfg_st *clks =
&e2e_pipe_param[pipe_idx].clks_cfg;
const scaler_ratio_depth_st *scl =
&e2e_pipe_param[pipe_idx].pipe.scale_ratio_depth;
const scaler_taps_st *taps = &e2e_pipe_param[pipe_idx].pipe.scale_taps;
@@ -1000,8 +999,6 @@ static void dml_rq_dlg_get_dlg_params(
unsigned int vupdate_width;
unsigned int vready_offset;
- unsigned int dispclk_delay_subtotal;
-
unsigned int vstartup_start;
unsigned int dst_x_after_scaler;
unsigned int dst_y_after_scaler;
@@ -1127,13 +1124,6 @@ static void dml_rq_dlg_get_dlg_params(
vupdate_offset = dst->vupdate_offset;
vupdate_width = dst->vupdate_width;
vready_offset = dst->vready_offset;
- dispclk_delay_subtotal = mode_lib->ip.dispclk_delay_subtotal;
-
- if (dout->dsc_enable) {
- double dsc_delay = get_dsc_delay(mode_lib, e2e_pipe_param,
num_pipes, pipe_idx); // FROM VBA
-
- dispclk_delay_subtotal += dsc_delay;
- }
vstartup_start = dst->vstartup_start;
if (interlaced) {
--
Hamza
Re: [PATCH] drm/amdgpu: Mark contexts guilty for any reset type
On 4/24/23 15:26, André Almeida wrote: >> >> Additional to that I currently didn't considered soft-recovered submissions >> as fatal and continue accepting submissions from that context, but already >> wanted to talk with Marek about that behavior. >> > > Interesting. I will try to test and validate this approach to see if the > contexts keep working as expected on soft-resets. FWIW, on this Thinkpad E595 with a Picasso APU, I've hit soft-resets (usually either in Firefox or gnome-shell) a number of times, and usually continued using the GNOME session for a few days without any issues. (Interestingly, Firefox reacts to the soft-resets by falling back to software rendering, even when it's not guilty itself) -- Earthling Michel Dänzer| https://redhat.com Libre software enthusiast | Mesa and Xwayland developer
Re: Disabling -Warray-bounds for gcc-13 too
On Sun, Apr 23, 2023 at 10:24 PM Kees Cook wrote:
>
> On April 23, 2023 10:36:24 AM PDT, Linus Torvalds
> wrote:
> >Kees,
> > I made the mistake of upgrading my M2 Macbook Air to Fedora-38, and
> >in the process I got gcc-13 which is not WERROR-clean because we only
> >limited the 'array-bounds' warning to gcc-11 and gcc-12. But gcc-13
> >has all the same issues.
> >
> >And I want to be able to do my arm64 builds with WERROR on still...
> >
> >I guess it never made much sense to hope it was going to go away
> >without having a confirmation, so I just changed it to be gcc-11+.
>
> Yeah, that's fine. GCC 13 released without having a fix for at least one
> (hopefully last) known array-bounds vs jump threading bug:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109071
>
> >And one of them is from you.
> >
> >In particular, commit 4076ea2419cf ("drm/nouveau/disp: Fix
> >nvif_outp_acquire_dp() argument size") cannot possibly be right, It
> >changes
> >
> > nvif_outp_acquire_dp(struct nvif_outp *outp, u8 dpcd[16],
> >
> >to
> >
> > nvif_outp_acquire_dp(struct nvif_outp *outp, u8 dpcd[DP_RECEIVER_CAP_SIZE],
> >
> >and then does
> >
> >memcpy(args.dp.dpcd, dpcd, sizeof(args.dp.dpcd));
> >
> >where that 'args.dp.dpcd' is a 16-byte array, and DP_RECEIVER_CAP_SIZE is 15.
>
> Yeah, it was an incomplete fix. I sent the other half here, but it fell
> through the cracks:
> https://lore.kernel.org/lkml/20230204184307.never.825-k...@kernel.org/
>
left a review on that patch. Any preferred way of getting it upstream?
I could push it through drm-misc, but the delay until it reaches
Linus' tree is a bit high.
>
>
> >
>
> >I think it's all entirely harmless from a code generation standpoint,
> >because the 15-byte field will be padded out to 16 bytes in the
> >structure that contains it, but it's most definitely buggy.
>
> Right; between this, that GCC 13 wasn't released yet, and I had no feedback
> from NV folks, I didn't chase down landing that fix.
>
> >
> >So that warning does find real cases of wrong code. But when those
> >real cases are hidden by hundreds of lines of unfixable false
> >positives, we don't have much choice.
>
> Yup, totally agreed. The false positives I've looked at all seem to be
> similar to the outstanding jump threading bug, so I'm hoping once that gets
> fixed we'll finally have a good signal with that warning enabled. :)
>
> -Kees
>
>
> --
> Kees Cook
>
Re: [PATCH] drm/nouveau/disp: More DP_RECEIVER_CAP_SIZE array fixes
On Wed, Mar 22, 2023 at 10:40 PM Gustavo A. R. Silva
wrote:
>
>
>
> On 2/4/23 12:43, Kees Cook wrote:
> > More arrays (and arguments) for dcpd were set to 16, when it looks like
> > DP_RECEIVER_CAP_SIZE (15) should be used. Fix the remaining cases, seen
> > with GCC 13:
> >
> > ../drivers/gpu/drm/nouveau/nvif/outp.c: In function 'nvif_outp_acquire_dp':
> > ../include/linux/fortify-string.h:57:33: warning: array subscript 'unsigned
> > char[16][0]' is partly outside array bounds of 'u8[15]' {aka 'unsigned
> > char[15]'} [-Warray-bounds=]
> > 57 | #define __underlying_memcpy __builtin_memcpy
> >| ^
> > ...
> > ../drivers/gpu/drm/nouveau/nvif/outp.c:140:9: note: in expansion of macro
> > 'memcpy'
> >140 | memcpy(args.dp.dpcd, dpcd, sizeof(args.dp.dpcd));
> >| ^~
> > ../drivers/gpu/drm/nouveau/nvif/outp.c:130:49: note: object 'dpcd' of size
> > [0, 15]
> >130 | nvif_outp_acquire_dp(struct nvif_outp *outp, u8
> > dpcd[DP_RECEIVER_CAP_SIZE],
> >|
> > ~~~^~
> >
> > Fixes: 813443721331 ("drm/nouveau/disp: move DP link config into acquire")
> > Cc: Ben Skeggs
> > Cc: Lyude Paul
> > Cc: Karol Herbst
> > Cc: David Airlie
> > Cc: Daniel Vetter
> > Cc: Dave Airlie
> > Cc: "Gustavo A. R. Silva"
> > Cc: dri-devel@lists.freedesktop.org
> > Cc: nouv...@lists.freedesktop.org
> > Signed-off-by: Kees Cook
>
> Reviewed-by: Gustavo A. R. Silva
>
Reviewed-by: Karol Herbst
sorry for not seeing this earlier.
> Thanks!
> --
> Gustavo
>
> > ---
> > drivers/gpu/drm/nouveau/include/nvif/if0012.h| 4 +++-
> > drivers/gpu/drm/nouveau/nvkm/engine/disp/outp.h | 3 ++-
> > drivers/gpu/drm/nouveau/nvkm/engine/disp/uoutp.c | 2 +-
> > 3 files changed, 6 insertions(+), 3 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/nouveau/include/nvif/if0012.h
> > b/drivers/gpu/drm/nouveau/include/nvif/if0012.h
> > index eb99d84eb844..16d4ad5023a3 100644
> > --- a/drivers/gpu/drm/nouveau/include/nvif/if0012.h
> > +++ b/drivers/gpu/drm/nouveau/include/nvif/if0012.h
> > @@ -2,6 +2,8 @@
> > #ifndef __NVIF_IF0012_H__
> > #define __NVIF_IF0012_H__
> >
> > +#include
> > +
> > union nvif_outp_args {
> > struct nvif_outp_v0 {
> > __u8 version;
> > @@ -63,7 +65,7 @@ union nvif_outp_acquire_args {
> > __u8 hda;
> > __u8 mst;
> > __u8 pad04[4];
> > - __u8 dpcd[16];
> > + __u8 dpcd[DP_RECEIVER_CAP_SIZE];
> > } dp;
> > };
> > } v0;
> > diff --git a/drivers/gpu/drm/nouveau/nvkm/engine/disp/outp.h
> > b/drivers/gpu/drm/nouveau/nvkm/engine/disp/outp.h
> > index b7631c1ab242..4e7f873f66e2 100644
> > --- a/drivers/gpu/drm/nouveau/nvkm/engine/disp/outp.h
> > +++ b/drivers/gpu/drm/nouveau/nvkm/engine/disp/outp.h
> > @@ -3,6 +3,7 @@
> > #define __NVKM_DISP_OUTP_H__
> > #include "priv.h"
> >
> > +#include
> > #include
> > #include
> > #include
> > @@ -42,7 +43,7 @@ struct nvkm_outp {
> > bool aux_pwr_pu;
> > u8 lttpr[6];
> > u8 lttprs;
> > - u8 dpcd[16];
> > + u8 dpcd[DP_RECEIVER_CAP_SIZE];
> >
> > struct {
> > int dpcd; /* -1, or index into
> > SUPPORTED_LINK_RATES table */
> > diff --git a/drivers/gpu/drm/nouveau/nvkm/engine/disp/uoutp.c
> > b/drivers/gpu/drm/nouveau/nvkm/engine/disp/uoutp.c
> > index 4f0ca709c85a..fc283a4a1522 100644
> > --- a/drivers/gpu/drm/nouveau/nvkm/engine/disp/uoutp.c
> > +++ b/drivers/gpu/drm/nouveau/nvkm/engine/disp/uoutp.c
> > @@ -146,7 +146,7 @@ nvkm_uoutp_mthd_release(struct nvkm_outp *outp, void
> > *argv, u32 argc)
> > }
> >
> > static int
> > -nvkm_uoutp_mthd_acquire_dp(struct nvkm_outp *outp, u8 dpcd[16],
> > +nvkm_uoutp_mthd_acquire_dp(struct nvkm_outp *outp, u8
> > dpcd[DP_RECEIVER_CAP_SIZE],
> > u8 link_nr, u8 link_bw, bool hda, bool mst)
> > {
> > int ret;
>
Re: [RFC PATCH] x86/mm: Fix PAT bit missing from page protection modify mask
On Mon, Apr 24, 2023 at 02:35:24PM +0200, Janusz Krzysztofik wrote:
> Visible glitches have been observed when running graphics applications on
> Linux under Xen hypervisor. Those observations have been confirmed with
> failures from kms_pwrite_crc Intel GPU test that verifies data coherency
> of DRM frame buffer objects using hardware CRC checksums calculated by
> display controllers, exposed to userspace via debugfs. Affected
> processing paths have then been identified with new test variants that
> mmap the objects using different methods and caching modes.
>
> When running as a Xen PV guest, Linux uses Xen provided PAT configuration
> which is different from its native one. In particular, Xen specific PTE
> encoding of write-combining caching, likely used by graphics applications,
> differs from the Linux default one found among statically defined minimal
> set of supported modes. Since Xen defines PTE encoding of the WC mode as
> _PAGE_PAT, it no longer belongs to the minimal set, depends on correct
> handling of _PAGE_PAT bit, and can be mismatched with write-back caching.
>
> When a user calls mmap() for a DRM buffer object, DRM device specific
> .mmap file operation, called from mmap_region(), takes care of setting PTE
> encoding bits in a vm_page_prot field of an associated virtual memory area
> structure. Unfortunately, _PAGE_PAT bit is not preserved when the vma's
> .vm_flags are then applied to .vm_page_prot via vm_set_page_prot(). Bits
> to be preserved are determined with _PAGE_CHG_MASK symbol that doesn't
> cover _PAGE_PAT. As a consequence, WB caching is requested instead of WC
> when running under Xen (also, WP is silently changed to WT, and UC
> downgraded to UC_MINUS). When running on bare metal, WC is not affected,
> but WP and WT extra modes are unintentionally replaced with WC and UC,
> respectively.
>
> WP and WT modes, encoded with _PAGE_PAT bit set, were introduced by commit
> 281d4078bec3 ("x86: Make page cache mode a real type"). Care was taken
> to extend _PAGE_CACHE_MASK symbol with that additional bit, but that
> symbol has never been used for identification of bits preserved when
> applying page protection flags. Support for all cache modes under Xen,
> including the problematic WC mode, was then introduced by commit
> 47591df50512 ("xen: Support Xen pv-domains using PAT").
>
> Extend bitmask used by pgprot_modify() for selecting bits to be preserved
> with _PAGE_PAT bit. However, since that bit can be reused as _PAGE_PSE,
> and the _PAGE_CHG_MASK symbol, primarly used by pte_modify(), is likely
> intentionally defined with that bit not set, keep that symbol unchanged.
>
> Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/7648
> Fixes: 281d4078bec3 ("x86: Make page cache mode a real type")
> Signed-off-by: Janusz Krzysztofik
> Cc: sta...@vger.kernel.org # v3.19+
I can confirm it fixes the issue, thanks!
Tested-by: Marek Marczykowski-Górecki
--
Best Regards,
Marek Marczykowski-Górecki
Invisible Things Lab
signature.asc
Description: PGP signature
Re: [PATCH] drm:amd:amdgpu: Fix missing bo unlock in failure path
On Mon, Apr 24, 2023 at 3:07 AM Christian König
wrote:
>
> Am 24.04.23 um 07:59 schrieb Sukrut Bellary:
> > smatch warning - inconsistent handling of buffer object reserve
> > and unreserve.
> >
> > Signed-off-by: Sukrut Bellary
>
> For now that patch is Reviewed-by: Christian König
> .
Applied. Thanks.
>
> But for the record mapping/unmapping the MQD like this is a very bad
> idea in the first place.
>
> We could need to shuffle memory around for that during resume and that
> is not something we really want to do.
We should probably just keep the MQDs mapped. On suspend we need to
save out the MQD state so it can be restored on resume when the MQDs
are in vram.
Alex
>
> Christian.
>
> > ---
> > drivers/gpu/drm/amd/amdgpu/gfx_v8_0.c | 4 +++-
> > 1 file changed, 3 insertions(+), 1 deletion(-)
> >
> > diff --git a/drivers/gpu/drm/amd/amdgpu/gfx_v8_0.c
> > b/drivers/gpu/drm/amd/amdgpu/gfx_v8_0.c
> > index 278416acf060..5de44d7e92de 100644
> > --- a/drivers/gpu/drm/amd/amdgpu/gfx_v8_0.c
> > +++ b/drivers/gpu/drm/amd/amdgpu/gfx_v8_0.c
> > @@ -4686,8 +4686,10 @@ static int gfx_v8_0_kiq_resume(struct amdgpu_device
> > *adev)
> > return r;
> >
> > r = amdgpu_bo_kmap(ring->mqd_obj, &ring->mqd_ptr);
> > - if (unlikely(r != 0))
> > + if (unlikely(r != 0)) {
> > + amdgpu_bo_unreserve(ring->mqd_obj);
> > return r;
> > + }
> >
> > gfx_v8_0_kiq_init_queue(ring);
> > amdgpu_bo_kunmap(ring->mqd_obj);
>
Re: [PATCH 0/2] Use i915 instead of dev_priv
Hi Jani, > >> just another "Friday patch". While reviewing some patches from > >> Tejas I found a bit confusing the use of dev_priv__ inside the > >> for_each_engine(), perhaps it should be moved inside the gt/? > >> > >> As I was at it I made the /dev_priv/i915/ change which is still > >> harmless. Next in queue is to change the i915_irq.h, which is a > >> bit tricky (but not much) as the "dev_priv" is hardcoded inside > >> some defines. > >> > >> Andi > >> > >> Andi Shyti (2): > >> drm/i915/i915_drv: Use proper parameter naming in for_each_gt() > >> drm/i915/i915_drv: Use i915 instead of dev_priv insied the file_priv > >> structure > >> > >> drivers/gpu/drm/i915/i915_drv.h | 462 > >> 1 file changed, 231 insertions(+), 231 deletions(-) > > > > Pushed to dmr-intel-gt-next. > > That's going to create problems for us for weeks to come. I'm actually > tempted to ask Joonas or Tvrtko to just force push that out of there. > > Only use drm-intel-gt-next for stuff that's specifically about gt or > gem, and touches files used by gt or gem only. For everything else, use > drm-intel-next. When in doubt, err on the side of drm-intel-next. sorry, I did think of it. But... > It's not enough that one of the patches changes parameters of > for_each_gt() macro. ... I was fooled by the gt/i915 parameter. Thanks and sorry, Andi > We can cross-merge drm-intel-next to drm-intel-gt-next, but we can't > cross-merge drm-intel-gt-next to drm-intel-next. This means the only way > to sync those i915_drv.h changes to drm-intel-next is to have a > drm-intel-gt-next pull request merged to drm-next, and then backmerged > to drm-intel-next. That's not going to happen for several weeks. > > Any change aimed at drm-intel-next that conflicts with the i915_drv.h > changes will now be pending on those merges.
Re: [PATCH v2 4/5] drm/msm/mdss: Handle the reg bus ICC path
Hi Konrad,
On 18.04.23 15:10, Konrad Dybcio wrote:
Apart from the already handled data bus (MAS_MDP_Pn<->DDR), there's
another path that needs to be handled to ensure MDSS functions properly,
namely the "reg bus", a.k.a the CPU-MDSS interconnect.
Gating that path may have a variety of effects.. from none to otherwise
inexplicable DSI timeouts..
On the MDSS side, we only have to ensure that it's on at what Qualcomm
downstream calls "77 MHz", a.k.a 76.8 Mbps and turn it off at suspend.
To achieve that, make msm_mdss_icc_request_bw() accept a boolean to
indicate whether we want the busses to be on or off, as this function's
only use is to vote for minimum or no bandwidth at all.
Signed-off-by: Konrad Dybcio
---
drivers/gpu/drm/msm/msm_mdss.c | 17 +
1 file changed, 13 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/msm/msm_mdss.c b/drivers/gpu/drm/msm/msm_mdss.c
[..]
-static void msm_mdss_icc_request_bw(struct msm_mdss *msm_mdss, unsigned long
bw)
+static void msm_mdss_icc_request_bw(struct msm_mdss *msm_mdss, bool enable)
{
int i;
for (i = 0; i < msm_mdss->num_mdp_paths; i++)
- icc_set_bw(msm_mdss->mdp_path[i], 0, Bps_to_icc(bw));
+ icc_set_bw(msm_mdss->mdp_path[i], 0, enable ?
Bps_to_icc(MIN_IB_BW) : 0);
+
+ if (msm_mdss->reg_bus_path)
+ icc_set_bw(msm_mdss->reg_bus_path, 0, enable ? 76800 : 0);
Please use Bps_to_icc, kbps_to_icc or any of the other macros.
BR,
Georgi
Re: [PATCH v10 2/2] drm: add kms driver for loongson display controller
Hi,
On 2023/4/4 22:10, Emil Velikov wrote:
--- /dev/null
+++ b/drivers/gpu/drm/loongson/lsdc_debugfs.c
+void lsdc_debugfs_init(struct drm_minor *minor)
+{
+#ifdef CONFIG_DEBUG_FS
+ drm_debugfs_create_files(lsdc_debugfs_list,
+ARRAY_SIZE(lsdc_debugfs_list),
+minor->debugfs_root,
+minor);
+#endif
+}
Should probably build the file when debugfs is enabled and provide
no-op stub in the header. See nouveau for an example.
It seem that the drm core already done this for us, are we really need
those #ifdef guard anymore?
I remove all of the #ifdef CONFIG_DEBUG_FS in my program and disable
the debugfs option in menuconfig
my driver compile without any error.
Re: [PATCH v2 2/3] DRM: Create new Content Protection connector property
Hi Mark (and Dmitry)
On Fri, 21 Apr 2023 at 18:07, Dmitry Baryshkov
wrote:
>
> On 21/04/2023 19:27, Mark Yacoub wrote:
> > From: Mark Yacoub
>
> Nit: is there a reason for this header? My first impression is that it
> matches your outgoing name & email address and as such is not necessary.
>
> Nit#2: subject should mention 'Key', as you are creating a property for
> the key.
>
> >
> > [Why]
> > To enable Protected Content, some drivers require a key to be injected
> > from user space to enable HDCP on the connector.
> >
> > [How]
> > Create new "Content Protection Property" of type "Blob"
>
> Generic observation is that the ability to inject HDCP keys manually
> seems to be quite unique to your hardware. As such, I think the debugfs
> or sysfs suits better in comparison to the DRM property.
I was about to reply to v1 with a very similar comment over the
requirement to keep HDCP keys secret.
v2 has added WRITE_ONLY blobs so at least another process can't just
read the blob back out again, but it feels like there are still
numerous ways to grab those keys. For an unsecured userspace to have
the keys in the first place seems like a bad move, and IMHO they
should only be held in either a secure environment, or only held in
hardware (passed direct from OTP to HDCP block).
There's also the DRM uAPI requirement for having reviewed patches for
an open source project to go alongside any uAPI change. Do such
patches exist?
https://docs.kernel.org/gpu/drm-uapi.html#open-source-userspace-requirements
Dave
> >
> > Signed-off-by: Mark Yacoub
> > ---
> > drivers/gpu/drm/drm_atomic_uapi.c | 9 +
> > include/drm/drm_connector.h | 6 ++
> > include/drm/drm_mode_config.h | 6 ++
> > 3 files changed, 21 insertions(+)
> >
> > diff --git a/drivers/gpu/drm/drm_atomic_uapi.c
> > b/drivers/gpu/drm/drm_atomic_uapi.c
> > index d867e7f9f2cd5..e20bc57cdb05c 100644
> > --- a/drivers/gpu/drm/drm_atomic_uapi.c
> > +++ b/drivers/gpu/drm/drm_atomic_uapi.c
> > @@ -749,6 +749,11 @@ static int drm_atomic_connector_set_property(struct
> > drm_connector *connector,
> > state->content_protection = val;
> > } else if (property == config->hdcp_content_type_property) {
> > state->hdcp_content_type = val;
> > + } else if (property == config->content_protection_key_property) {
> > + ret = drm_atomic_replace_property_blob_from_id(
> > + dev, &state->content_protection_key, val, -1, -1,
> > + &replaced);
> > + return ret;
> > } else if (property == connector->colorspace_property) {
> > state->colorspace = val;
> > } else if (property == config->writeback_fb_id_property) {
> > @@ -843,6 +848,10 @@ drm_atomic_connector_get_property(struct drm_connector
> > *connector,
> > *val = state->content_protection;
> > } else if (property == config->hdcp_content_type_property) {
> > *val = state->hdcp_content_type;
> > + } else if (property == config->content_protection_key_property) {
> > + *val = state->content_protection_key ?
> > +state->content_protection_key->base.id :
> > +0;
> > } else if (property == config->writeback_fb_id_property) {
> > /* Writeback framebuffer is one-shot, write and forget */
> > *val = 0;
> > diff --git a/include/drm/drm_connector.h b/include/drm/drm_connector.h
> > index 7b5048516185c..2fbe51272bfeb 100644
> > --- a/include/drm/drm_connector.h
> > +++ b/include/drm/drm_connector.h
> > @@ -896,6 +896,12 @@ struct drm_connector_state {
> >*/
> > unsigned int content_protection;
> >
> > + /**
> > + * @content_protection_key: DRM blob property for holding the Content
> > + * Protection Key injected from user space.
> > + */
> > + struct drm_property_blob *content_protection_key;
> > +
> > /**
> >* @colorspace: State variable for Connector property to request
> >* colorspace change on Sink. This is most commonly used to switch
> > diff --git a/include/drm/drm_mode_config.h b/include/drm/drm_mode_config.h
> > index e5b053001d22e..615d1e5f57562 100644
> > --- a/include/drm/drm_mode_config.h
> > +++ b/include/drm/drm_mode_config.h
> > @@ -887,6 +887,12 @@ struct drm_mode_config {
> >*/
> > struct drm_property *hdcp_content_type_property;
> >
> > + /**
> > + * @content_protection_key_property: DRM blob property that receives
> > the
> > + * content protection key from user space to be injected into the
> > kernel.
> > + */
> > + struct drm_property *content_protection_key_property;
> > +
> > /* dumb ioctl parameters */
> > uint32_t preferred_depth, prefer_shadow;
> >
>
> --
> With best wishes
> Dmitry
>
Re: [RFC PATCH] x86/mm: Fix PAT bit missing from page protection modify mask
On 24.04.23 14:35, Janusz Krzysztofik wrote:
Visible glitches have been observed when running graphics applications on
Linux under Xen hypervisor. Those observations have been confirmed with
failures from kms_pwrite_crc Intel GPU test that verifies data coherency
of DRM frame buffer objects using hardware CRC checksums calculated by
display controllers, exposed to userspace via debugfs. Affected
processing paths have then been identified with new test variants that
mmap the objects using different methods and caching modes.
When running as a Xen PV guest, Linux uses Xen provided PAT configuration
which is different from its native one. In particular, Xen specific PTE
encoding of write-combining caching, likely used by graphics applications,
differs from the Linux default one found among statically defined minimal
set of supported modes. Since Xen defines PTE encoding of the WC mode as
_PAGE_PAT, it no longer belongs to the minimal set, depends on correct
handling of _PAGE_PAT bit, and can be mismatched with write-back caching.
When a user calls mmap() for a DRM buffer object, DRM device specific
.mmap file operation, called from mmap_region(), takes care of setting PTE
encoding bits in a vm_page_prot field of an associated virtual memory area
structure. Unfortunately, _PAGE_PAT bit is not preserved when the vma's
.vm_flags are then applied to .vm_page_prot via vm_set_page_prot(). Bits
to be preserved are determined with _PAGE_CHG_MASK symbol that doesn't
cover _PAGE_PAT. As a consequence, WB caching is requested instead of WC
when running under Xen (also, WP is silently changed to WT, and UC
downgraded to UC_MINUS). When running on bare metal, WC is not affected,
but WP and WT extra modes are unintentionally replaced with WC and UC,
respectively.
WP and WT modes, encoded with _PAGE_PAT bit set, were introduced by commit
281d4078bec3 ("x86: Make page cache mode a real type"). Care was taken
to extend _PAGE_CACHE_MASK symbol with that additional bit, but that
symbol has never been used for identification of bits preserved when
applying page protection flags. Support for all cache modes under Xen,
including the problematic WC mode, was then introduced by commit
47591df50512 ("xen: Support Xen pv-domains using PAT").
Extend bitmask used by pgprot_modify() for selecting bits to be preserved
with _PAGE_PAT bit. However, since that bit can be reused as _PAGE_PSE,
and the _PAGE_CHG_MASK symbol, primarly used by pte_modify(), is likely
intentionally defined with that bit not set, keep that symbol unchanged.
Hmm, I wonder whether pte_mkhuge() shouldn't just set _PAGE_PSE, but use
pgprot_4k_2_large() before doing so.
OTOH a use case like in remove_migration_pte(), where pte_mkhuge() is
directly followed by a call of arch_make_huge_pte(), which in turn is
calling pte_mkhuge() again, would set _always_ the PAT bit.
When running as a Xen PV guest this doesn't matter at all, as large or
huge pages aren't supported there. So clearly something for the MM
maintainers. :-)
Juergen
P.S.: Janusz, nice catch! The QubesOS folks who reported the problem
originally will test your patch under Xen soon.
OpenPGP_0xB0DE9DD628BF132F.asc
Description: OpenPGP public key
OpenPGP_signature
Description: OpenPGP digital signature
[PATCH] drm:amd:amdgpu: Fix missing bo unlock in failure path
smatch warning - inconsistent handling of buffer object reserve
and unreserve.
Signed-off-by: Sukrut Bellary
---
drivers/gpu/drm/amd/amdgpu/gfx_v8_0.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/gfx_v8_0.c
b/drivers/gpu/drm/amd/amdgpu/gfx_v8_0.c
index 278416acf060..5de44d7e92de 100644
--- a/drivers/gpu/drm/amd/amdgpu/gfx_v8_0.c
+++ b/drivers/gpu/drm/amd/amdgpu/gfx_v8_0.c
@@ -4686,8 +4686,10 @@ static int gfx_v8_0_kiq_resume(struct amdgpu_device
*adev)
return r;
r = amdgpu_bo_kmap(ring->mqd_obj, &ring->mqd_ptr);
- if (unlikely(r != 0))
+ if (unlikely(r != 0)) {
+ amdgpu_bo_unreserve(ring->mqd_obj);
return r;
+ }
gfx_v8_0_kiq_init_queue(ring);
amdgpu_bo_kunmap(ring->mqd_obj);
--
2.34.1
Re: [PATCH] drm/bridge:Fix the panic problem caused by bridge->funcs->attach
two separate pipeline:crtc->encoder->bridge->connector->panel Jagan Teki 于2023年4月23日周日 19:10写道： > + Bridge Maintainers > > On Wed, Apr 19, 2023 at 8:35 AM 余治国 wrote: > > > > The log looks like this: > > [ 31.723823] Internal error: Oops: 9604 [#1] SMP\013 \010 > > [ 31.729030] Modules linked in:\013 \010 > > [ 31.733395] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 5.10.59+2.0.0 > #250\013 > > \010 > > [ 31.745167] pstate: 60c5 (nZCv daif +PAN +UAO -TCO BTYPE=--)\013 > \010 > > [ 31.752785] pc : drm_bridge_attach+0xdc/0x1a4\013 \010 > > [ 31.757518] lr : drm_bridge_attach+0x40/0x1a4\013 \010 > > [ 31.762104] sp : 000678f0\013 \010 > > [ 31.765726] x29: 000678f0 x28: 0031c880 \013 \010 > > [ 31.771599] x27: 0060 x26: 800010539e90 \013 \010 > > [ 31.777340] x25: 000a6000 x24: 00129c10 \013 \010 > > [ 31.783060] x23: x22: 000131c0 \013 \010 > > [ 31.788770] x21: 80001052a5b8 x20: 003e2c80 \013 \010 > > [ 31.794506] x19: 00017080 x18: 0010 \013 \010 > > [ 31.800210] x17: 5fcfcd6c x16: d27b105e \013 \010 > > [ 31.805907] x15: 00c7 x14: 000675d0 \013 \010 > > [ 31.811599] x13: ffea x12: 8000114158c0 \013 \010 > > [ 31.817282] x11: 0003 x10: 800011295880 \013 \010 > > [ 31.823000] x9 : 8000112958d8 x8 : 0017ffe8 \013 \010 > > [ 31.828731] x7 : c000fffe x6 : 0001 \013 \010 > > [ 31.834425] x5 : 0057ffa8 x4 : \013 \010 > > [ 31.840101] x3 : x2 : 00013218 \013 \010 > > [ 31.845787] x1 : 003e2cf8 x0 : \013 \010 > > [ 31.851594] Call trace:\013 \010 > > [ 31.854603] drm_bridge_attach+0xdc/0x1a4\013 \010 > > [ 31.859079] dw_mipi_dsi_bridge_attach+0x98/0xa8\013 \010 > > [ 31.864035] drm_bridge_attach+0x104/0x1a4\013 \010 > > [ 31.869211] dw_mipi_dsi_bind+0x24/0x58\013 \010 > > drm_bridge_attach will call bridge->funcs in many cases, so I think it > is necessary to check。 > > I don't think the bridge pointer or bridge->funcs pointer is NULL > here. It looks like the controlling is attaching the bridge prior to > registering it. If I remember correctly, I got a similar issue with > rockchip-drm pipeline. Would you please share your pipeline as well? > > Thanks, > Jagan. >
Re: [PATCH] drm/amdgpu: Mark contexts guilty for any reset type
Hi Christian, thank you for your comments. Em 24/04/2023 04:03, Christian König escreveu: Am 24.04.23 um 03:43 schrieb André Almeida: When a DRM job timeout, the GPU is probably hang and amdgpu have some ways to deal with that, ranging from soft recoveries to full device reset. Anyway, when userspace ask the kernel the state of the context (via AMDGPU_CTX_OP_QUERY_STATE), the kernel reports that the device was reset, regardless if a full reset happened or not. However, amdgpu only marks a context guilty in the ASIC reset path. This makes the userspace report incomplete, given that on soft recovery path the guilty context is not told that it's the guilty one. Fix this by marking the context guilty for every type of reset when a job timeouts. The guilty handling is pretty much broken by design and only works because we go through multiple hops of validating the entity after the job has already been pushed to the hw. I see, thanks. I think we should probably just remove that completely and use an approach where we check the in flight submissions in the query state IOCTL. Like the DRM_IOCTL_I915_GET_RESET_STATS approach? > See my other patch on the mailing list regarding that. Which one, the "[PATCH 1/8] drm/scheduler: properly forward fence errors" series? Additional to that I currently didn't considered soft-recovered submissions as fatal and continue accepting submissions from that context, but already wanted to talk with Marek about that behavior. Interesting. I will try to test and validate this approach to see if the contexts keep working as expected on soft-resets. Regards, Christian.
Re: [PATCH V2 4/6] drm: bridge: samsung-dsim: Dynamically configure DPHY timing
On Mon, Apr 24, 2023 at 4:50 AM Adam Ford wrote:
>
> On Mon, Apr 24, 2023 at 4:47 AM Marek Szyprowski
> wrote:
> >
> > On 24.04.2023 11:44, Chen-Yu Tsai wrote:
> > > On Mon, Apr 24, 2023 at 5:31 PM Adam Ford wrote:
> > >> On Mon, Apr 24, 2023 at 1:12 AM Chen-Yu Tsai wrote:
> > >>> On Sun, Apr 23, 2023 at 8:13 PM Adam Ford wrote:
> > The DPHY timings are currently hard coded. Since the input
> > clock can be variable, the phy timings need to be variable
> > too. Add an additional variable to the driver data to enable
> > this feature to prevent breaking boards that don't support it.
> >
> > The phy_mipi_dphy_get_default_config function configures the
> > DPHY timings in pico-seconds, and a small macro converts those
> > timings into clock cycles based on the pixel clock rate.
> >
> > Signed-off-by: Adam Ford
> > ---
> > drivers/gpu/drm/bridge/samsung-dsim.c | 79
> > +++
> > include/drm/bridge/samsung-dsim.h | 1 +
> > 2 files changed, 70 insertions(+), 10 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/bridge/samsung-dsim.c
> > b/drivers/gpu/drm/bridge/samsung-dsim.c
> > index 5b6e7825b92f..f165483d5044 100644
> > --- a/drivers/gpu/drm/bridge/samsung-dsim.c
> > +++ b/drivers/gpu/drm/bridge/samsung-dsim.c
> > @@ -18,9 +18,7 @@
> > #include
> > #include
> > #include
> > -
> > #include
> > -
> > #include
> > #include
> > #include
> > @@ -218,6 +216,8 @@
> >
> > #define OLD_SCLK_MIPI_CLK_NAME "pll_clk"
> >
> > +#define PS_TO_CYCLE(PS, MHz) DIV64_U64_ROUND_CLOSEST(((PS) * (MHz)),
> > 1ULL)
> > +
> > static const char *const clk_names[5] = {
> > "bus_clk",
> > "sclk_mipi",
> > @@ -487,6 +487,7 @@ static const struct samsung_dsim_driver_data
> > imx8mm_dsi_driver_data = {
> > .m_min = 64,
> > .m_max = 1023,
> > .vco_min = 1050,
> > + .dynamic_dphy = 1,
> > };
> >
> > static const struct samsung_dsim_driver_data *
> > @@ -698,13 +699,50 @@ static void samsung_dsim_set_phy_ctrl(struct
> > samsung_dsim *dsi)
> > const struct samsung_dsim_driver_data *driver_data =
> > dsi->driver_data;
> > const unsigned int *reg_values = driver_data->reg_values;
> > u32 reg;
> > + struct drm_display_mode *m = &dsi->mode;
> > + int bpp = mipi_dsi_pixel_format_to_bpp(dsi->format);
> > + struct phy_configure_opts_mipi_dphy cfg;
> > + int clk_prepare, lpx, clk_zero, clk_post, clk_trail;
> > + int hs_exit, hs_prepare, hs_zero, hs_trail;
> > + unsigned long long clock_in_hz = m->clock * 1000;
> >
> > if (driver_data->has_freqband)
> > return;
> >
> > + /* The dynamic_phy has the ability to adjust PHY Timing
> > settings */
> > + if (driver_data->dynamic_dphy) {
> > + phy_mipi_dphy_get_default_config(clock_in_hz, bpp,
> > dsi->lanes, &cfg);
> > >>> This requires adding "select GENERIC_PHY_MIPI_DPHY" to DRM_SAMSUNG_DSIM,
> > >>> otherwise with CONFIG_DRM_SAMSUNG_DSIM=m:
> > >>>
> > >>> ERROR: modpost: "phy_mipi_dphy_get_default_config"
> > >>> [drivers/gpu/drm/bridge/samsung-dsim.ko] undefined!
> > >>> make[5]: *** [scripts/Makefile.modpost:136: Module.symvers] Error 1
> > >>> make[4]: *** [Makefile:1978: modpost] Error 2
> > >>> make[3]: *** [Makefile:357: __build_one_by_one] Error 2
> > >>>
> > >>> I'm sure there'll be a similar error if CONFIG_DRM_SAMSUNG_DSIM=y.
> > >> That's interesting, I didn't come across that.
> > >> What did you use for a starting point when you applied the patches?
> > >> I want to see if I can replicate it.
> > > next-20230421. My config is pretty much tailored to the Hummingbird Pulse.
> > > Device drivers for other hardware or things that I can't enable are all
> > > disabled. For example I don't have PHY_MIXEL_MIPI_DPHY enabled.
> > >
> > > Maybe you have some other bridge or phy that selects it enabled?
> >
> >
> > I've observed similar issue while building exynos_defconfig for arm 32bit.
>
> Thanks to both of you for the head's up. I'll add a patch to update
> Kconfig to explicitly select that when I do V3. I was just using the
> base arm64 'defconfig' option without any customization.
Marek S & Chen-Yu,
I added a patch into the series to make this select
GENERIC_PHY_MIPI_DPHY, and I tested it with the 32-bit arm config,
exynos_defconfig and it now builds successfully.
I'm going to wait a few more hours to see if anyone else has any
feedback before I send V3.
adam
>
> adam
> >
> >
> > Best regards
> > --
> > Marek Szyprowski, PhD
> > Samsung R&D Institute Poland
> >
[RFC PATCH] x86/mm: Fix PAT bit missing from page protection modify mask
Visible glitches have been observed when running graphics applications on
Linux under Xen hypervisor. Those observations have been confirmed with
failures from kms_pwrite_crc Intel GPU test that verifies data coherency
of DRM frame buffer objects using hardware CRC checksums calculated by
display controllers, exposed to userspace via debugfs. Affected
processing paths have then been identified with new test variants that
mmap the objects using different methods and caching modes.
When running as a Xen PV guest, Linux uses Xen provided PAT configuration
which is different from its native one. In particular, Xen specific PTE
encoding of write-combining caching, likely used by graphics applications,
differs from the Linux default one found among statically defined minimal
set of supported modes. Since Xen defines PTE encoding of the WC mode as
_PAGE_PAT, it no longer belongs to the minimal set, depends on correct
handling of _PAGE_PAT bit, and can be mismatched with write-back caching.
When a user calls mmap() for a DRM buffer object, DRM device specific
.mmap file operation, called from mmap_region(), takes care of setting PTE
encoding bits in a vm_page_prot field of an associated virtual memory area
structure. Unfortunately, _PAGE_PAT bit is not preserved when the vma's
.vm_flags are then applied to .vm_page_prot via vm_set_page_prot(). Bits
to be preserved are determined with _PAGE_CHG_MASK symbol that doesn't
cover _PAGE_PAT. As a consequence, WB caching is requested instead of WC
when running under Xen (also, WP is silently changed to WT, and UC
downgraded to UC_MINUS). When running on bare metal, WC is not affected,
but WP and WT extra modes are unintentionally replaced with WC and UC,
respectively.
WP and WT modes, encoded with _PAGE_PAT bit set, were introduced by commit
281d4078bec3 ("x86: Make page cache mode a real type"). Care was taken
to extend _PAGE_CACHE_MASK symbol with that additional bit, but that
symbol has never been used for identification of bits preserved when
applying page protection flags. Support for all cache modes under Xen,
including the problematic WC mode, was then introduced by commit
47591df50512 ("xen: Support Xen pv-domains using PAT").
Extend bitmask used by pgprot_modify() for selecting bits to be preserved
with _PAGE_PAT bit. However, since that bit can be reused as _PAGE_PSE,
and the _PAGE_CHG_MASK symbol, primarly used by pte_modify(), is likely
intentionally defined with that bit not set, keep that symbol unchanged.
Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/7648
Fixes: 281d4078bec3 ("x86: Make page cache mode a real type")
Signed-off-by: Janusz Krzysztofik
Cc: sta...@vger.kernel.org # v3.19+
---
arch/x86/include/asm/pgtable.h | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/arch/x86/include/asm/pgtable.h b/arch/x86/include/asm/pgtable.h
index 7425f32e52932..f797f8da2e5b6 100644
--- a/arch/x86/include/asm/pgtable.h
+++ b/arch/x86/include/asm/pgtable.h
@@ -654,8 +654,10 @@ static inline pmd_t pmd_modify(pmd_t pmd, pgprot_t newprot)
#define pgprot_modify pgprot_modify
static inline pgprot_t pgprot_modify(pgprot_t oldprot, pgprot_t newprot)
{
- pgprotval_t preservebits = pgprot_val(oldprot) & _PAGE_CHG_MASK;
- pgprotval_t addbits = pgprot_val(newprot) & ~_PAGE_CHG_MASK;
+ unsigned long mask = _PAGE_CHG_MASK | _PAGE_CACHE_MASK;
+
+ pgprotval_t preservebits = pgprot_val(oldprot) & mask;
+ pgprotval_t addbits = pgprot_val(newprot) & ~mask;
return __pgprot(preservebits | addbits);
}
--
2.40.0
[PATCH 2/5] drm/debugfs: disallow debugfs access when device isn't registered
During device bringup it might be that we can't access the debugfs files.
Return -ENODEV until the registration is completed on access.
Signed-off-by: Christian König
---
drivers/gpu/drm/drm_debugfs.c | 7 +++
1 file changed, 7 insertions(+)
diff --git a/drivers/gpu/drm/drm_debugfs.c b/drivers/gpu/drm/drm_debugfs.c
index 54376e2400bb..796cda62ad12 100644
--- a/drivers/gpu/drm/drm_debugfs.c
+++ b/drivers/gpu/drm/drm_debugfs.c
@@ -148,6 +148,9 @@ static int drm_debugfs_open(struct inode *inode, struct
file *file)
{
struct drm_info_node *node = inode->i_private;
+ if (!device_is_registered(node->minor->kdev))
+ return -ENODEV;
+
return single_open(file, node->info_ent->show, node);
}
@@ -155,6 +158,10 @@ static int drm_debugfs_entry_open(struct inode *inode,
struct file *file)
{
struct drm_debugfs_entry *entry = inode->i_private;
struct drm_debugfs_info *node = &entry->file;
+ struct drm_minor *minor = entry->dev->primary ?: entry->dev->accel;
+
+ if (!device_is_registered(minor->kdev))
+ return -ENODEV;
return single_open(file, node->show, entry);
}
--
2.34.1
[PATCH 3/5] drm/debugfs: rework debugfs directory creation v4
Instead of the per minor directories only create a single debugfs
directory for the whole device directly when the device is initialized.
For DRM devices each minor gets a symlink to the per device directory
for now until we can be sure that this isn't useful any more in any way.
Accel devices create only the per device directory and also drops the mid
layer callback to create driver specific files.
v2: cleanup accel component as well
v3: fix typo when debugfs is disabled
v4: call drm_debugfs_dev_fini() during release as well,
some kerneldoc typos fixed
Signed-off-by: Christian König
---
drivers/accel/drm_accel.c | 27 +++
drivers/gpu/drm/drm_atomic.c| 4 +-
drivers/gpu/drm/drm_client.c| 4 +-
drivers/gpu/drm/drm_crtc_internal.h | 2 +-
drivers/gpu/drm/drm_debugfs.c | 73 -
drivers/gpu/drm/drm_drv.c | 21 +++--
drivers/gpu/drm/drm_framebuffer.c | 4 +-
drivers/gpu/drm/drm_internal.h | 20 ++--
include/drm/drm_accel.h | 9 +++-
include/drm/drm_client.h| 2 +-
include/drm/drm_device.h| 7 +++
include/drm/drm_drv.h | 8
include/drm/drm_file.h | 1 +
13 files changed, 130 insertions(+), 52 deletions(-)
diff --git a/drivers/accel/drm_accel.c b/drivers/accel/drm_accel.c
index d473388ee807..34fda8a9b829 100644
--- a/drivers/accel/drm_accel.c
+++ b/drivers/accel/drm_accel.c
@@ -79,26 +79,33 @@ static const struct drm_info_list accel_debugfs_list[] = {
#define ACCEL_DEBUGFS_ENTRIES ARRAY_SIZE(accel_debugfs_list)
/**
- * accel_debugfs_init() - Initialize debugfs for accel minor
+ * accel_debugfs_init() - Initialize debugfs for device
+ * @dev: Pointer to the device instance.
+ *
+ * This function creates a root directory for the device in debugfs.
+ */
+void accel_debugfs_init(struct drm_device *dev)
+{
+ drm_debugfs_dev_init(dev, accel_debugfs_root);
+}
+
+/**
+ * accel_debugfs_register() - Register debugfs for device
* @minor: Pointer to the drm_minor instance.
* @minor_id: The minor's id
*
- * This function initializes the drm minor's debugfs members and creates
- * a root directory for the minor in debugfs. It also creates common files
- * for accelerators and calls the driver's debugfs init callback.
+ * Creates common files for accelerators.
*/
-void accel_debugfs_init(struct drm_minor *minor, int minor_id)
+void accel_debugfs_register(struct drm_device *dev)
{
- struct drm_device *dev = minor->dev;
- char name[64];
+ struct drm_minor *minor = dev->accel;
INIT_LIST_HEAD(&minor->debugfs_list);
mutex_init(&minor->debugfs_lock);
- sprintf(name, "%d", minor_id);
- minor->debugfs_root = debugfs_create_dir(name, accel_debugfs_root);
+ minor->debugfs_root = dev->debugfs_root;
drm_debugfs_create_files(accel_debugfs_list, ACCEL_DEBUGFS_ENTRIES,
-minor->debugfs_root, minor);
+dev->debugfs_root, minor);
}
/**
diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
index b4c6ffc438da..87d0269f063a 100644
--- a/drivers/gpu/drm/drm_atomic.c
+++ b/drivers/gpu/drm/drm_atomic.c
@@ -1831,9 +1831,9 @@ static const struct drm_debugfs_info
drm_atomic_debugfs_list[] = {
{"state", drm_state_info, 0},
};
-void drm_atomic_debugfs_init(struct drm_minor *minor)
+void drm_atomic_debugfs_init(struct drm_device *dev)
{
- drm_debugfs_add_files(minor->dev, drm_atomic_debugfs_list,
+ drm_debugfs_add_files(dev, drm_atomic_debugfs_list,
ARRAY_SIZE(drm_atomic_debugfs_list));
}
#endif
diff --git a/drivers/gpu/drm/drm_client.c b/drivers/gpu/drm/drm_client.c
index f6292ba0e6fc..a91132276f21 100644
--- a/drivers/gpu/drm/drm_client.c
+++ b/drivers/gpu/drm/drm_client.c
@@ -514,9 +514,9 @@ static const struct drm_debugfs_info
drm_client_debugfs_list[] = {
{ "internal_clients", drm_client_debugfs_internal_clients, 0 },
};
-void drm_client_debugfs_init(struct drm_minor *minor)
+void drm_client_debugfs_init(struct drm_device *dev)
{
- drm_debugfs_add_files(minor->dev, drm_client_debugfs_list,
+ drm_debugfs_add_files(dev, drm_client_debugfs_list,
ARRAY_SIZE(drm_client_debugfs_list));
}
#endif
diff --git a/drivers/gpu/drm/drm_crtc_internal.h
b/drivers/gpu/drm/drm_crtc_internal.h
index 501a10edd0e1..8556c3b3ff88 100644
--- a/drivers/gpu/drm/drm_crtc_internal.h
+++ b/drivers/gpu/drm/drm_crtc_internal.h
@@ -232,7 +232,7 @@ int drm_mode_dirtyfb_ioctl(struct drm_device *dev,
/* drm_atomic.c */
#ifdef CONFIG_DEBUG_FS
struct drm_minor;
-void drm_atomic_debugfs_init(struct drm_minor *minor);
+void drm_atomic_debugfs_init(struct drm_device *dev);
#endif
int __drm_atomic_helper_disable_plane(struct drm_plane *plane,
diff --git a/drivers/gpu/drm/drm_debugfs.c b/drivers/gpu/drm/drm_debugfs.c
index 796cda62a
[PATCH 5/5] drm/debugfs: rework drm_debugfs_create_files implementation
Use managed memory allocation for this. That allows us to not keep
track of all the files any more.
Signed-off-by: Christian König
---
drivers/accel/drm_accel.c | 2 -
drivers/gpu/drm/drm_debugfs.c | 75 +-
drivers/gpu/drm/drm_drv.c | 2 -
drivers/gpu/drm/drm_internal.h | 5 ---
drivers/gpu/drm/tegra/dc.c | 9 +++-
drivers/gpu/drm/tegra/dsi.c| 1 +
drivers/gpu/drm/tegra/hdmi.c | 3 +-
drivers/gpu/drm/tegra/sor.c| 1 +
include/drm/drm_debugfs.h | 4 +-
include/drm/drm_file.h | 4 --
10 files changed, 34 insertions(+), 72 deletions(-)
diff --git a/drivers/accel/drm_accel.c b/drivers/accel/drm_accel.c
index 34fda8a9b829..2f42292abd73 100644
--- a/drivers/accel/drm_accel.c
+++ b/drivers/accel/drm_accel.c
@@ -100,8 +100,6 @@ void accel_debugfs_register(struct drm_device *dev)
{
struct drm_minor *minor = dev->accel;
- INIT_LIST_HEAD(&minor->debugfs_list);
- mutex_init(&minor->debugfs_lock);
minor->debugfs_root = dev->debugfs_root;
drm_debugfs_create_files(accel_debugfs_list, ACCEL_DEBUGFS_ENTRIES,
diff --git a/drivers/gpu/drm/drm_debugfs.c b/drivers/gpu/drm/drm_debugfs.c
index d723143852e3..7aea06cb6be9 100644
--- a/drivers/gpu/drm/drm_debugfs.c
+++ b/drivers/gpu/drm/drm_debugfs.c
@@ -208,7 +208,7 @@ void drm_debugfs_create_files(const struct drm_info_list
*files, int count,
if (features && !drm_core_check_all_features(dev, features))
continue;
- tmp = kmalloc(sizeof(struct drm_info_node), GFP_KERNEL);
+ tmp = drmm_kzalloc(dev, sizeof(*tmp), GFP_KERNEL);
if (tmp == NULL)
continue;
@@ -217,14 +217,28 @@ void drm_debugfs_create_files(const struct drm_info_list
*files, int count,
0444, root, tmp,
&drm_debugfs_fops);
tmp->info_ent = &files[i];
-
- mutex_lock(&minor->debugfs_lock);
- list_add(&tmp->list, &minor->debugfs_list);
- mutex_unlock(&minor->debugfs_lock);
}
}
EXPORT_SYMBOL(drm_debugfs_create_files);
+int drm_debugfs_remove_files(const struct drm_info_list *files, int count,
+struct dentry *root, struct drm_minor *minor)
+{
+ int i;
+
+ for (i = 0; i < count; i++) {
+ struct dentry *dent = debugfs_lookup(files[i].name, root);
+
+ if (!dent)
+ continue;
+
+ drmm_kfree(minor->dev, d_inode(dent)->i_private);
+ debugfs_remove(dent);
+ }
+ return 0;
+}
+EXPORT_SYMBOL(drm_debugfs_remove_files);
+
/**
* drm_debugfs_dev_init - create debugfs directory for the device
* @dev: the device which we want to create the directory for
@@ -267,11 +281,8 @@ int drm_debugfs_register(struct drm_minor *minor, int
minor_id,
struct drm_device *dev = minor->dev;
char name[64];
- INIT_LIST_HEAD(&minor->debugfs_list);
- mutex_init(&minor->debugfs_lock);
sprintf(name, "%d", minor_id);
- minor->debugfs_symlink = debugfs_create_symlink(name, root,
- dev->unique);
+ debugfs_create_symlink(name, root, dev->unique);
/* TODO: Only for compatibility with drivers */
minor->debugfs_root = dev->debugfs_root;
@@ -282,52 +293,6 @@ int drm_debugfs_register(struct drm_minor *minor, int
minor_id,
return 0;
}
-int drm_debugfs_remove_files(const struct drm_info_list *files, int count,
-struct drm_minor *minor)
-{
- struct list_head *pos, *q;
- struct drm_info_node *tmp;
- int i;
-
- mutex_lock(&minor->debugfs_lock);
- for (i = 0; i < count; i++) {
- list_for_each_safe(pos, q, &minor->debugfs_list) {
- tmp = list_entry(pos, struct drm_info_node, list);
- if (tmp->info_ent == &files[i]) {
- debugfs_remove(tmp->dent);
- list_del(pos);
- kfree(tmp);
- }
- }
- }
- mutex_unlock(&minor->debugfs_lock);
- return 0;
-}
-EXPORT_SYMBOL(drm_debugfs_remove_files);
-
-static void drm_debugfs_remove_all_files(struct drm_minor *minor)
-{
- struct drm_info_node *node, *tmp;
-
- mutex_lock(&minor->debugfs_lock);
- list_for_each_entry_safe(node, tmp, &minor->debugfs_list, list) {
- debugfs_remove(node->dent);
- list_del(&node->list);
- kfree(node);
- }
- mutex_unlock(&minor->debugfs_lock);
-}
-
-void drm_debugfs_cleanup(struct drm_minor *minor)
-{
- if (!minor->debugfs_symlink)
- return;
-
- drm_debugfs_remove_all_files(minor);
- debugfs_remove(minor->deb
[PATCH 4/5] drm/debugfs: remove dev->debugfs_list and debugfs_mutex v2
The mutex was completely pointless in the first place since any
parallel adding of files to this list would result in random
behavior since the list is filled and consumed multiple times.
Completely drop that approach and just create the files directly but
return -ENODEV while opening the file when the minors are not
registered yet.
v2: rebase on debugfs directory rework, limit access before minors are
registered.
Signed-off-by: Christian König
---
drivers/gpu/drm/drm_debugfs.c | 27 ++-
drivers/gpu/drm/drm_drv.c | 3 ---
drivers/gpu/drm/drm_internal.h| 5 -
drivers/gpu/drm/drm_mode_config.c | 2 --
include/drm/drm_device.h | 15 ---
5 files changed, 2 insertions(+), 50 deletions(-)
diff --git a/drivers/gpu/drm/drm_debugfs.c b/drivers/gpu/drm/drm_debugfs.c
index 65b6e0aae96e..d723143852e3 100644
--- a/drivers/gpu/drm/drm_debugfs.c
+++ b/drivers/gpu/drm/drm_debugfs.c
@@ -265,7 +265,6 @@ int drm_debugfs_register(struct drm_minor *minor, int
minor_id,
struct dentry *root)
{
struct drm_device *dev = minor->dev;
- struct drm_debugfs_entry *entry, *tmp;
char name[64];
INIT_LIST_HEAD(&minor->debugfs_list);
@@ -280,30 +279,9 @@ int drm_debugfs_register(struct drm_minor *minor, int
minor_id,
if (dev->driver->debugfs_init && dev->render != minor)
dev->driver->debugfs_init(minor);
- list_for_each_entry_safe(entry, tmp, &dev->debugfs_list, list) {
- debugfs_create_file(entry->file.name, 0444,
- minor->debugfs_root, entry,
&drm_debugfs_entry_fops);
- list_del(&entry->list);
- }
-
return 0;
}
-void drm_debugfs_late_register(struct drm_device *dev)
-{
- struct drm_minor *minor = dev->primary;
- struct drm_debugfs_entry *entry, *tmp;
-
- if (!minor)
- return;
-
- list_for_each_entry_safe(entry, tmp, &dev->debugfs_list, list) {
- debugfs_create_file(entry->file.name, 0444,
- minor->debugfs_root, entry,
&drm_debugfs_entry_fops);
- list_del(&entry->list);
- }
-}
-
int drm_debugfs_remove_files(const struct drm_info_list *files, int count,
struct drm_minor *minor)
{
@@ -373,9 +351,8 @@ void drm_debugfs_add_file(struct drm_device *dev, const
char *name,
entry->file.data = data;
entry->dev = dev;
- mutex_lock(&dev->debugfs_mutex);
- list_add(&entry->list, &dev->debugfs_list);
- mutex_unlock(&dev->debugfs_mutex);
+ debugfs_create_file(name, 0444, dev->debugfs_root, entry,
+ &drm_debugfs_entry_fops);
}
EXPORT_SYMBOL(drm_debugfs_add_file);
diff --git a/drivers/gpu/drm/drm_drv.c b/drivers/gpu/drm/drm_drv.c
index 9505c4c3f10e..bc15fbf5a304 100644
--- a/drivers/gpu/drm/drm_drv.c
+++ b/drivers/gpu/drm/drm_drv.c
@@ -597,7 +597,6 @@ static void drm_dev_init_release(struct drm_device *dev,
void *res)
mutex_destroy(&dev->clientlist_mutex);
mutex_destroy(&dev->filelist_mutex);
mutex_destroy(&dev->struct_mutex);
- mutex_destroy(&dev->debugfs_mutex);
drm_legacy_destroy_members(dev);
}
@@ -638,14 +637,12 @@ static int drm_dev_init(struct drm_device *dev,
INIT_LIST_HEAD(&dev->filelist_internal);
INIT_LIST_HEAD(&dev->clientlist);
INIT_LIST_HEAD(&dev->vblank_event_list);
- INIT_LIST_HEAD(&dev->debugfs_list);
spin_lock_init(&dev->event_lock);
mutex_init(&dev->struct_mutex);
mutex_init(&dev->filelist_mutex);
mutex_init(&dev->clientlist_mutex);
mutex_init(&dev->master_mutex);
- mutex_init(&dev->debugfs_mutex);
ret = drmm_add_action_or_reset(dev, drm_dev_init_release, NULL);
if (ret)
diff --git a/drivers/gpu/drm/drm_internal.h b/drivers/gpu/drm/drm_internal.h
index bf4a4f24bd4c..5a98fd1613ee 100644
--- a/drivers/gpu/drm/drm_internal.h
+++ b/drivers/gpu/drm/drm_internal.h
@@ -185,7 +185,6 @@ void drm_debugfs_dev_register(struct drm_device *dev);
int drm_debugfs_register(struct drm_minor *minor, int minor_id,
struct dentry *root);
void drm_debugfs_cleanup(struct drm_minor *minor);
-void drm_debugfs_late_register(struct drm_device *dev);
void drm_debugfs_connector_add(struct drm_connector *connector);
void drm_debugfs_connector_remove(struct drm_connector *connector);
void drm_debugfs_crtc_add(struct drm_crtc *crtc);
@@ -210,10 +209,6 @@ static inline void drm_debugfs_cleanup(struct drm_minor
*minor)
{
}
-static inline void drm_debugfs_late_register(struct drm_device *dev)
-{
-}
-
static inline void drm_debugfs_connector_add(struct drm_connector *connector)
{
}
diff --git a/drivers/gpu/drm/drm_mode_config.c
b/drivers/gpu/drm/drm_mode_config.c
index 87eb591fe9b5..8525ef851540 100644
--- a/drivers/gpu/drm/drm_mode_config.c
+++ b/
[PATCH 1/5] drm/debugfs: drop debugfs_init() for the render and accel node v2
We want to remove per minor debugfs directories. Start by stopping
drivers from adding anything inside of those in the mid layer callback.
v2: drop it for the accel node as well
Signed-off-by: Christian König
---
drivers/accel/drm_accel.c | 3 ---
drivers/gpu/drm/drm_debugfs.c | 2 +-
2 files changed, 1 insertion(+), 4 deletions(-)
diff --git a/drivers/accel/drm_accel.c b/drivers/accel/drm_accel.c
index 1b69824286fd..d473388ee807 100644
--- a/drivers/accel/drm_accel.c
+++ b/drivers/accel/drm_accel.c
@@ -99,9 +99,6 @@ void accel_debugfs_init(struct drm_minor *minor, int minor_id)
drm_debugfs_create_files(accel_debugfs_list, ACCEL_DEBUGFS_ENTRIES,
minor->debugfs_root, minor);
-
- if (dev->driver->debugfs_init)
- dev->driver->debugfs_init(minor);
}
/**
diff --git a/drivers/gpu/drm/drm_debugfs.c b/drivers/gpu/drm/drm_debugfs.c
index 4855230ba2c6..54376e2400bb 100644
--- a/drivers/gpu/drm/drm_debugfs.c
+++ b/drivers/gpu/drm/drm_debugfs.c
@@ -242,7 +242,7 @@ int drm_debugfs_init(struct drm_minor *minor, int minor_id,
drm_client_debugfs_init(minor);
}
- if (dev->driver->debugfs_init)
+ if (dev->driver->debugfs_init && dev->render != minor)
dev->driver->debugfs_init(minor);
list_for_each_entry_safe(entry, tmp, &dev->debugfs_list, list) {
--
2.34.1
Re: [PATCH 2/5] drm/debugfs: rework debugfs directory creation v3
Am 17.04.23 um 12:26 schrieb Stanislaw Gruszka:
On Mon, Apr 17, 2023 at 09:18:31AM +0200, Christian König wrote:
Am 16.04.23 um 18:03 schrieb Tomer Tayar:
On 12/04/2023 17:52, Christian König wrote:
/**
- * accel_debugfs_init() - Initialize debugfs for accel minor
+ * accel_debugfs_init() - Register debugfs for accel minor
+ * @dev: Pointer to the device instance.
+ *
+ * This function creates a root directory for the device in debugfs.
+ */
+void accel_debugfs_init(struct drm_device *dev)
+{
+ drm_debugfs_dev_init(dev, accel_debugfs_root);
+}
+
+/**
+ * accel_debugfs_register() - Register debugfs for device
* @minor: Pointer to the drm_minor instance.
* @minor_id: The minor's id
*
- * This function initializes the drm minor's debugfs members and creates
- * a root directory for the minor in debugfs. It also creates common files
- * for accelerators and calls the driver's debugfs init callback.
+ * Creates common files for accelerators.
*/
-void accel_debugfs_init(struct drm_minor *minor, int minor_id)
+void accel_debugfs_register(struct drm_device *dev)
{
I wonder if we need this and can not use drm_debugfs_dev_register() ?
In drm there are two additional files "clients" and "gem_names" which are
appropriate to accel as well and so far we do not have any accel
specific files.
I was wondering the same thing while going over this, but then decided
to leave it as it is for now.
My primary concern is to remove the mid layering with the driver
callback because that is blocking functionality from working correctly,
cleanup and re-joining of functionality can then come later on.
Regards,
Christian.
Regards
Stanislaw
Re: In-flight collision: DRM_AMD_DC_DCN renaming
Hi Lukas,
Lukas Bulwahn writes:
> Dear Michael, dear Harry, dear Alex,
>
> The commit 4652ae7a51b7 ("drm/amd/display: Rename DCN config to FP")
> renames config DRM_AMD_DC_DCN to config DRM_AMD_DC_FP. The concurrent
> commit 78f0929884d4 ("powerpc/64: Always build with 128-bit long
> double") overrides the renaming change for the select in config
> DRM_AMD_DC, and this leads to selecting the non-existent
> DRM_AMD_DC_DCN.
The powerpc commit doesn't override the name change, in the powerpc tree
where it's applied the name change hasn't happened yet, see the diff:
diff --git a/drivers/gpu/drm/amd/display/Kconfig
b/drivers/gpu/drm/amd/display/Kconfig
index 0c9bd0a53e60..e36261d546af 100644
--- a/drivers/gpu/drm/amd/display/Kconfig
+++ b/drivers/gpu/drm/amd/display/Kconfig
@@ -8,7 +8,7 @@ config DRM_AMD_DC
depends on BROKEN || !CC_IS_CLANG || X86_64 || SPARC64 || ARM64
select SND_HDA_COMPONENT if SND_HDA_CORE
# !CC_IS_CLANG: https://github.com/ClangBuiltLinux/linux/issues/1752
- select DRM_AMD_DC_DCN if (X86 || PPC_LONG_DOUBLE_128 || (ARM64 &&
KERNEL_MODE_NEON && !CC_IS_CLANG))
+ select DRM_AMD_DC_DCN if (X86 || (PPC64 && ALTIVEC) || (ARM64 &&
KERNEL_MODE_NEON && !CC_IS_CLANG))
help
Choose this option if you want to use the new display engine
support for AMDGPU. This adds required support for Vega and
The problem is that the resolution of the merge conflict in linux-next
is incorrect, it takes the powerpc change without taking into account
the rename from the amdgpu commit.
The correct resolution is:
diff --cc drivers/gpu/drm/amd/display/Kconfig
index e36261d546af,06b438217c61..
--- a/drivers/gpu/drm/amd/display/Kconfig
+++ b/drivers/gpu/drm/amd/display/Kconfig
@@@ -8,7 -8,7 +8,7 @@@ config DRM_AMD_D
depends on BROKEN || !CC_IS_CLANG || X86_64 || SPARC64 || ARM64
select SND_HDA_COMPONENT if SND_HDA_CORE
# !CC_IS_CLANG: https://github.com/ClangBuiltLinux/linux/issues/1752
- select DRM_AMD_DC_DCN if (X86 || (PPC64 && ALTIVEC) || (ARM64 &&
KERNEL_MODE_NEON && !CC_IS_CLANG))
- select DRM_AMD_DC_FP if (X86 || PPC64 || (ARM64 && KERNEL_MODE_NEON &&
!CC_IS_CLANG))
++ select DRM_AMD_DC_FP if (X86 || (PPC64 && ALTIVEC) || (ARM64 &&
KERNEL_MODE_NEON && !CC_IS_CLANG))
help
Choose this option if you want to use the new display engine
support for AMDGPU. This adds required support for Vega and
(Note that 4652ae7a51b7 incorrectly changed PPC_LONG_DOUBLE_128 to plain
PPC64, which is why PPC_LONG_DOUBLE_128 doesn't appear in the diff above.)
Possibly the merge resoulution can be fixed in linux-next.
And ultimately the fix is for Linus to do the proper merge resolution
when he eventually merges the two trees.
cheers
Re: [PATCH 1/5] drm/bridge: anx7625: Drop of_gpio header
On 8/12/22 17:57, Maíra Canal wrote: This driver includes the deprecated OF GPIO header yet fail to use symbols from it, so drop the include. Cc: Andrzej Hajda Cc: Neil Armstrong Cc: Robert Foss Cc: Laurent Pinchart Cc: Jonas Karlman Cc: Jernej Skrabec Signed-off-by: Maíra Canal Applied to drm/drm-misc (drm-misc-next). Best Regards, - Maíra Canal --- drivers/gpu/drm/bridge/analogix/anx7625.c | 1 - 1 file changed, 1 deletion(-) diff --git a/drivers/gpu/drm/bridge/analogix/anx7625.c b/drivers/gpu/drm/bridge/analogix/anx7625.c index 79fc7a50b497..d7d4ca1c8b30 100644 --- a/drivers/gpu/drm/bridge/analogix/anx7625.c +++ b/drivers/gpu/drm/bridge/analogix/anx7625.c @@ -17,7 +17,6 @@ #include #include -#include #include #include
Re: [PATCH 4/5] drm/sti: Drop of_gpio header
On 8/12/22 17:57, Maíra Canal wrote: This driver includes the deprecated OF GPIO header yet fail to use symbols from it, so drop this include. Cc: Alain Volmat Signed-off-by: Maíra Canal Applied to drm/drm-misc (drm-misc-next). Best Regards, - Maíra Canal --- drivers/gpu/drm/sti/sti_dvo.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/sti/sti_dvo.c b/drivers/gpu/drm/sti/sti_dvo.c index b6ee8a82e656..0fc7710b054a 100644 --- a/drivers/gpu/drm/sti/sti_dvo.c +++ b/drivers/gpu/drm/sti/sti_dvo.c @@ -8,7 +8,7 @@ #include #include #include -#include +#include #include #include
Re: [PATCH 0/2] Use i915 instead of dev_priv
On Sun, 23 Apr 2023, Andi Shyti wrote: > Hi, > > On Fri, Apr 21, 2023 at 03:46:52PM +0200, Andi Shyti wrote: >> Hi, >> >> just another "Friday patch". While reviewing some patches from >> Tejas I found a bit confusing the use of dev_priv__ inside the >> for_each_engine(), perhaps it should be moved inside the gt/? >> >> As I was at it I made the /dev_priv/i915/ change which is still >> harmless. Next in queue is to change the i915_irq.h, which is a >> bit tricky (but not much) as the "dev_priv" is hardcoded inside >> some defines. >> >> Andi >> >> Andi Shyti (2): >> drm/i915/i915_drv: Use proper parameter naming in for_each_gt() >> drm/i915/i915_drv: Use i915 instead of dev_priv insied the file_priv >> structure >> >> drivers/gpu/drm/i915/i915_drv.h | 462 >> 1 file changed, 231 insertions(+), 231 deletions(-) > > Pushed to dmr-intel-gt-next. That's going to create problems for us for weeks to come. I'm actually tempted to ask Joonas or Tvrtko to just force push that out of there. Only use drm-intel-gt-next for stuff that's specifically about gt or gem, and touches files used by gt or gem only. For everything else, use drm-intel-next. When in doubt, err on the side of drm-intel-next. It's not enough that one of the patches changes parameters of for_each_gt() macro. We can cross-merge drm-intel-next to drm-intel-gt-next, but we can't cross-merge drm-intel-gt-next to drm-intel-next. This means the only way to sync those i915_drv.h changes to drm-intel-next is to have a drm-intel-gt-next pull request merged to drm-next, and then backmerged to drm-intel-next. That's not going to happen for several weeks. Any change aimed at drm-intel-next that conflicts with the i915_drv.h changes will now be pending on those merges. BR, Jani. > > Thanks Rodrigo and Andrzej for your review. > > Andi -- Jani Nikula, Intel Open Source Graphics Center
