[PATCH v2] drm/ttm: Remove redundant code in ttm_tt_init_fields
Remove redundant assignment code for ttm->caching as it's overwritten
just a few lines later.
v2:
- Update the commit message.
Signed-off-by: Ma Jun
---
drivers/gpu/drm/ttm/ttm_tt.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/gpu/drm/ttm/ttm_tt.c b/drivers/gpu/drm/ttm/ttm_tt.c
index 02b812dacc5d..45a44544b656 100644
--- a/drivers/gpu/drm/ttm/ttm_tt.c
+++ b/drivers/gpu/drm/ttm/ttm_tt.c
@@ -143,7 +143,6 @@ static void ttm_tt_init_fields(struct ttm_tt *ttm,
unsigned long extra_pages)
{
ttm->num_pages = (PAGE_ALIGN(bo->base.size) >> PAGE_SHIFT) +
extra_pages;
- ttm->caching = ttm_cached;
ttm->page_flags = page_flags;
ttm->dma_address = NULL;
ttm->swap_storage = NULL;
--
2.34.1
Re: [PATCH] drm/exynos: fix race condition UAF in exynos_g2d_exec_ioctl
Hi Andi, On Wed, May 31, 2023 at 6:21 AM Andi Shyti wrote: > > Hi Min, > > On Fri, May 26, 2023 at 09:01:31PM +0800, Min Li wrote: > > If it is async, runqueue_node is freed in g2d_runqueue_worker on another > > worker thread. So in extreme cases, if g2d_runqueue_worker runs first, and > > then executes the following if statement, there will be use-after-free. > > > > Signed-off-by: Min Li > > --- > > drivers/gpu/drm/exynos/exynos_drm_g2d.c | 2 +- > > 1 file changed, 1 insertion(+), 1 deletion(-) > > > > diff --git a/drivers/gpu/drm/exynos/exynos_drm_g2d.c > > b/drivers/gpu/drm/exynos/exynos_drm_g2d.c > > index ec784e58da5c..414e585ec7dd 100644 > > --- a/drivers/gpu/drm/exynos/exynos_drm_g2d.c > > +++ b/drivers/gpu/drm/exynos/exynos_drm_g2d.c > > @@ -1335,7 +1335,7 @@ int exynos_g2d_exec_ioctl(struct drm_device *drm_dev, > > void *data, > > /* Let the runqueue know that there is work to do. */ > > queue_work(g2d->g2d_workq, >runqueue_work); > > > > - if (runqueue_node->async) > > + if (req->async) > > did you actually hit this? If you did, then the fix is not OK. No, I didn't actually hit this. I found it through code review. This is only a theoretical issue that can only be triggered in extreme cases. > > Andi > > > goto out; > > > > wait_for_completion(_node->complete); > > -- > > 2.34.1 > > -- Min Li
[PATCH] drm/nouveau/nvif: use struct_size()
Use struct_size() instead of hand writing it.
This is less verbose and more informative.
Signed-off-by: Su Hui
---
drivers/gpu/drm/nouveau/nvif/object.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/nouveau/nvif/object.c
b/drivers/gpu/drm/nouveau/nvif/object.c
index 4d1aaee8fe15..4bd693aa4ee0 100644
--- a/drivers/gpu/drm/nouveau/nvif/object.c
+++ b/drivers/gpu/drm/nouveau/nvif/object.c
@@ -65,7 +65,7 @@ nvif_object_sclass_get(struct nvif_object *object, struct
nvif_sclass **psclass)
u32 size;
while (1) {
- size = sizeof(*args) + cnt * sizeof(args->sclass.oclass[0]);
+ size = struct_size(args, sclass.oclass, cnt);
if (!(args = kmalloc(size, GFP_KERNEL)))
return -ENOMEM;
args->ioctl.version = 0;
--
2.30.2
[PATCH v3 1/3] drm/msm/adreno: Add Adreno A690 support
From: Bjorn Andersson
Introduce support for the Adreno A690, found in Qualcomm SC8280XP.
Tested-by: Steev Klimaszewski
Reviewed-by: Konrad Dybcio
Signed-off-by: Bjorn Andersson
Signed-off-by: Bjorn Andersson
---
Changes since v2:
- None
Changes since v1:
- Moved a690 to adreno_is_a660_family(), which simplifies hw_init() and
ensured that pdc_in_aop got set.
- Dropped dynamic lookup in cmd-db. Will look into posting this
separately.
drivers/gpu/drm/msm/adreno/a6xx_gpu.c | 113 -
drivers/gpu/drm/msm/adreno/a6xx_hfi.c | 33 ++
drivers/gpu/drm/msm/adreno/adreno_device.c | 14 +++
drivers/gpu/drm/msm/adreno/adreno_gpu.h| 11 +-
4 files changed, 166 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/msm/adreno/a6xx_gpu.c
b/drivers/gpu/drm/msm/adreno/a6xx_gpu.c
index 9fb214f150dd..cabc8f9a12d7 100644
--- a/drivers/gpu/drm/msm/adreno/a6xx_gpu.c
+++ b/drivers/gpu/drm/msm/adreno/a6xx_gpu.c
@@ -588,6 +588,63 @@ const struct adreno_reglist a660_hwcg[] = {
{},
};
+const struct adreno_reglist a690_hwcg[] = {
+ {REG_A6XX_RBBM_CLOCK_CNTL_SP0, 0x0222},
+ {REG_A6XX_RBBM_CLOCK_CNTL2_SP0, 0x0220},
+ {REG_A6XX_RBBM_CLOCK_DELAY_SP0, 0x0080},
+ {REG_A6XX_RBBM_CLOCK_HYST_SP0, 0xF3CF},
+ {REG_A6XX_RBBM_CLOCK_CNTL_TP0, 0x},
+ {REG_A6XX_RBBM_CLOCK_CNTL2_TP0, 0x},
+ {REG_A6XX_RBBM_CLOCK_CNTL3_TP0, 0x},
+ {REG_A6XX_RBBM_CLOCK_CNTL4_TP0, 0x0002},
+ {REG_A6XX_RBBM_CLOCK_DELAY_TP0, 0x},
+ {REG_A6XX_RBBM_CLOCK_DELAY2_TP0, 0x},
+ {REG_A6XX_RBBM_CLOCK_DELAY3_TP0, 0x},
+ {REG_A6XX_RBBM_CLOCK_DELAY4_TP0, 0x0001},
+ {REG_A6XX_RBBM_CLOCK_HYST_TP0, 0x},
+ {REG_A6XX_RBBM_CLOCK_HYST2_TP0, 0x},
+ {REG_A6XX_RBBM_CLOCK_HYST3_TP0, 0x},
+ {REG_A6XX_RBBM_CLOCK_HYST4_TP0, 0x0007},
+ {REG_A6XX_RBBM_CLOCK_CNTL_RB0, 0x},
+ {REG_A6XX_RBBM_CLOCK_CNTL2_RB0, 0x0100},
+ {REG_A6XX_RBBM_CLOCK_CNTL_CCU0, 0x2220},
+ {REG_A6XX_RBBM_CLOCK_HYST_RB_CCU0, 0x00040F00},
+ {REG_A6XX_RBBM_CLOCK_CNTL_RAC, 0x25222022},
+ {REG_A6XX_RBBM_CLOCK_CNTL2_RAC, 0x},
+ {REG_A6XX_RBBM_CLOCK_DELAY_RAC, 0x0011},
+ {REG_A6XX_RBBM_CLOCK_HYST_RAC, 0x00445044},
+ {REG_A6XX_RBBM_CLOCK_CNTL_TSE_RAS_RBBM, 0x0422},
+ {REG_A6XX_RBBM_CLOCK_MODE_VFD, 0x},
+ {REG_A6XX_RBBM_CLOCK_MODE_GPC, 0x0022},
+ {REG_A6XX_RBBM_CLOCK_DELAY_HLSQ_2, 0x0002},
+ {REG_A6XX_RBBM_CLOCK_MODE_HLSQ, 0x},
+ {REG_A6XX_RBBM_CLOCK_DELAY_TSE_RAS_RBBM, 0x4000},
+ {REG_A6XX_RBBM_CLOCK_DELAY_VFD, 0x},
+ {REG_A6XX_RBBM_CLOCK_DELAY_GPC, 0x0200},
+ {REG_A6XX_RBBM_CLOCK_DELAY_HLSQ, 0x},
+ {REG_A6XX_RBBM_CLOCK_HYST_TSE_RAS_RBBM, 0x},
+ {REG_A6XX_RBBM_CLOCK_HYST_VFD, 0x},
+ {REG_A6XX_RBBM_CLOCK_HYST_GPC, 0x04104004},
+ {REG_A6XX_RBBM_CLOCK_HYST_HLSQ, 0x},
+ {REG_A6XX_RBBM_CLOCK_CNTL_TEX_FCHE, 0x0222},
+ {REG_A6XX_RBBM_CLOCK_DELAY_TEX_FCHE, 0x0111},
+ {REG_A6XX_RBBM_CLOCK_HYST_TEX_FCHE, 0x},
+ {REG_A6XX_RBBM_CLOCK_CNTL_UCHE, 0x},
+ {REG_A6XX_RBBM_CLOCK_HYST_UCHE, 0x0004},
+ {REG_A6XX_RBBM_CLOCK_DELAY_UCHE, 0x0002},
+ {REG_A6XX_RBBM_CLOCK_CNTL, 0x8AA8AA82},
+ {REG_A6XX_RBBM_ISDB_CNT, 0x0182},
+ {REG_A6XX_RBBM_RAC_THRESHOLD_CNT, 0x},
+ {REG_A6XX_RBBM_SP_HYST_CNT, 0x},
+ {REG_A6XX_RBBM_CLOCK_CNTL_GMU_GX, 0x0222},
+ {REG_A6XX_RBBM_CLOCK_DELAY_GMU_GX, 0x0111},
+ {REG_A6XX_RBBM_CLOCK_HYST_GMU_GX, 0x0555},
+ {REG_A6XX_GPU_GMU_AO_GMU_CGC_MODE_CNTL, 0x20200},
+ {REG_A6XX_GPU_GMU_AO_GMU_CGC_DELAY_CNTL, 0x10111},
+ {REG_A6XX_GPU_GMU_AO_GMU_CGC_HYST_CNTL, 0x},
+ {}
+};
+
static void a6xx_set_hwcg(struct msm_gpu *gpu, bool state)
{
struct adreno_gpu *adreno_gpu = to_adreno_gpu(gpu);
@@ -747,6 +804,45 @@ static const u32 a660_protect[] = {
A6XX_PROTECT_NORDWR(0x1f8c0, 0x), /* note: infinite range */
};
+/* These are for a690 */
+static const u32 a690_protect[] = {
+ A6XX_PROTECT_RDONLY(0x0, 0x004ff),
+ A6XX_PROTECT_RDONLY(0x00501, 0x1),
+ A6XX_PROTECT_RDONLY(0x0050b, 0x002f4),
+ A6XX_PROTECT_NORDWR(0x0050e, 0x0),
+ A6XX_PROTECT_NORDWR(0x00510, 0x0),
+ A6XX_PROTECT_NORDWR(0x00534, 0x0),
+ A6XX_PROTECT_NORDWR(0x00800, 0x00082),
+ A6XX_PROTECT_NORDWR(0x008a0, 0x8),
+ A6XX_PROTECT_NORDWR(0x008ab, 0x00024),
+ A6XX_PROTECT_RDONLY(0x008d0, 0x000bc),
+ A6XX_PROTECT_NORDWR(0x00900, 0x0004d),
+ A6XX_PROTECT_NORDWR(0x0098d, 0x00272),
+ A6XX_PROTECT_NORDWR(0x00e00, 0x1),
+ A6XX_PROTECT_NORDWR(0x00e03, 0xc),
+ A6XX_PROTECT_NORDWR(0x03c00, 0x000c3),
+
[PATCH v3 2/3] arm64: dts: qcom: sc8280xp: Add GPU related nodes
From: Bjorn Andersson
Add Adreno SMMU, GPU clock controller, GMU and GPU nodes for the
SC8280XP.
Tested-by: Steev Klimaszewski
Signed-off-by: Bjorn Andersson
Signed-off-by: Bjorn Andersson
---
Changes since v2:
- Added missing opp level (both gpu and gmu)
- Corrected opp-level for highest gpu opp
- Added dma-coherent to gpu smmu
Note that in order for the GPU driver to probe, the last change
requires:
https://lore.kernel.org/linux-arm-msm/20230410185226.3240336-1-dmitry.barysh...@linaro.org/
Changes since v1:
- Dropped gmu_pdc_seq region from , as it shouldn't have been used.
- Added missing compatible to _smmu.
- Dropped aoss_qmp clock in and _smmu.
arch/arm64/boot/dts/qcom/sc8280xp.dtsi | 181 +
1 file changed, 181 insertions(+)
diff --git a/arch/arm64/boot/dts/qcom/sc8280xp.dtsi
b/arch/arm64/boot/dts/qcom/sc8280xp.dtsi
index 6730349e34f4..00f4df7fdcad 100644
--- a/arch/arm64/boot/dts/qcom/sc8280xp.dtsi
+++ b/arch/arm64/boot/dts/qcom/sc8280xp.dtsi
@@ -6,6 +6,7 @@
#include
#include
+#include
#include
#include
#include
@@ -2340,6 +2341,186 @@ tcsr: syscon@1fc {
reg = <0x0 0x01fc 0x0 0x3>;
};
+ gpu: gpu@3d0 {
+ compatible = "qcom,adreno-690.0", "qcom,adreno";
+
+ reg = <0 0x03d0 0 0x4>,
+ <0 0x03d9e000 0 0x1000>,
+ <0 0x03d61000 0 0x800>;
+ reg-names = "kgsl_3d0_reg_memory",
+ "cx_mem",
+ "cx_dbgc";
+ interrupts = ;
+ iommus = <_smmu 0 0xc00>, <_smmu 1 0xc00>;
+ operating-points-v2 = <_opp_table>;
+
+ qcom,gmu = <>;
+ interconnects = <_noc MASTER_GFX3D 0 _virt
SLAVE_EBI1 0>;
+ interconnect-names = "gfx-mem";
+ #cooling-cells = <2>;
+
+ status = "disabled";
+
+ gpu_opp_table: opp-table {
+ compatible = "operating-points-v2";
+
+ opp-27000 {
+ opp-hz = /bits/ 64 <27000>;
+ opp-level =
;
+ opp-peak-kBps = <451000>;
+ };
+
+ opp-41000 {
+ opp-hz = /bits/ 64 <41000>;
+ opp-level = ;
+ opp-peak-kBps = <1555000>;
+ };
+
+ opp-5 {
+ opp-hz = /bits/ 64 <5>;
+ opp-level =
;
+ opp-peak-kBps = <1555000>;
+ };
+
+ opp-54700 {
+ opp-hz = /bits/ 64 <54700>;
+ opp-level =
;
+ opp-peak-kBps = <1555000>;
+ };
+
+ opp-60600 {
+ opp-hz = /bits/ 64 <60600>;
+ opp-level = ;
+ opp-peak-kBps = <2736000>;
+ };
+
+ opp-64000 {
+ opp-hz = /bits/ 64 <64000>;
+ opp-level =
;
+ opp-peak-kBps = <2736000>;
+ };
+
+ opp-65500 {
+ opp-hz = /bits/ 64 <65500>;
+ opp-level =
;
+ opp-peak-kBps = <2736000>;
+ };
+
+ opp-69000 {
+ opp-hz = /bits/ 64 <69000>;
+ opp-level =
;
+ opp-peak-kBps = <2736000>;
+ };
+ };
+ };
+
+ gmu: gmu@3d6a000 {
+ compatible = "qcom,adreno-gmu-690.0", "qcom,adreno-gmu";
+ reg = <0 0x03d6a000 0 0x34000>,
+ <0 0x03de 0 0x1>,
+ <0 0x0b29 0 0x1>;
+ reg-names = "gmu", "rscc", "gmu_pdc";
+ interrupts = ,
+;
+ interrupt-names = "hfi", "gmu";
+ clocks = <
[PATCH v3 3/3] arm64: dts: qcom: sc8280xp: Enable GPU related nodes
From: Bjorn Andersson
Add memory reservation for the zap-shader and enable the Adreno SMMU,
GPU clock controller, GMU and the GPU nodes for the SC8280XP CRD and the
Lenovo ThinkPad X13s.
Tested-by: Steev Klimaszewski
Signed-off-by: Bjorn Andersson
Signed-off-by: Bjorn Andersson
---
Changes since v2:
- None
Changes since v1:
- None
arch/arm64/boot/dts/qcom/sc8280xp-crd.dts | 26 +++
.../qcom/sc8280xp-lenovo-thinkpad-x13s.dts| 26 +++
2 files changed, 52 insertions(+)
diff --git a/arch/arm64/boot/dts/qcom/sc8280xp-crd.dts
b/arch/arm64/boot/dts/qcom/sc8280xp-crd.dts
index cd7e0097d8bc..58b1d920ea9c 100644
--- a/arch/arm64/boot/dts/qcom/sc8280xp-crd.dts
+++ b/arch/arm64/boot/dts/qcom/sc8280xp-crd.dts
@@ -210,6 +210,11 @@ vreg_wwan: regulator-wwan {
};
reserved-memory {
+ gpu_mem: gpu-mem@8bf0 {
+ reg = <0 0x8bf0 0 0x2000>;
+ no-map;
+ };
+
linux,cma {
compatible = "shared-dma-pool";
size = <0x0 0x800>;
@@ -259,6 +264,10 @@ usb1_sbu_mux: endpoint {
};
};
+_smmu {
+ status = "okay";
+};
+
_rsc {
regulators-0 {
compatible = "qcom,pm8350-rpmh-regulators";
@@ -390,6 +399,23 @@ {
status = "okay";
};
+ {
+ status = "okay";
+};
+
+ {
+ status = "okay";
+
+ zap-shader {
+ memory-region = <_mem>;
+ firmware-name = "qcom/sc8280xp/qcdxkmsuc8280.mbn";
+ };
+};
+
+ {
+ status = "okay";
+};
+
{
status = "okay";
};
diff --git a/arch/arm64/boot/dts/qcom/sc8280xp-lenovo-thinkpad-x13s.dts
b/arch/arm64/boot/dts/qcom/sc8280xp-lenovo-thinkpad-x13s.dts
index 5ae057ad6438..382f27946468 100644
--- a/arch/arm64/boot/dts/qcom/sc8280xp-lenovo-thinkpad-x13s.dts
+++ b/arch/arm64/boot/dts/qcom/sc8280xp-lenovo-thinkpad-x13s.dts
@@ -264,6 +264,11 @@ vreg_wwan: regulator-wwan {
};
reserved-memory {
+ gpu_mem: gpu-mem@8bf0 {
+ reg = <0 0x8bf0 0 0x2000>;
+ no-map;
+ };
+
linux,cma {
compatible = "shared-dma-pool";
size = <0x0 0x800>;
@@ -359,6 +364,10 @@ usb1_sbu_mux: endpoint {
};
};
+_smmu {
+ status = "okay";
+};
+
_rsc {
regulators-0 {
compatible = "qcom,pm8350-rpmh-regulators";
@@ -518,6 +527,23 @@ {
status = "okay";
};
+ {
+ status = "okay";
+};
+
+ {
+ status = "okay";
+
+ zap-shader {
+ memory-region = <_mem>;
+ firmware-name = "qcom/sc8280xp/LENOVO/21BX/qcdxkmsuc8280.mbn";
+ };
+};
+
+ {
+ status = "okay";
+};
+
{
status = "okay";
};
--
2.39.2
[PATCH v3 0/3] drm/msm/adreno: GPU support on SC8280XP
This series introduces support for A690 in the DRM/MSM driver and enables it for the two SC8280XP laptops. Bjorn Andersson (3): drm/msm/adreno: Add Adreno A690 support arm64: dts: qcom: sc8280xp: Add GPU related nodes arm64: dts: qcom: sc8280xp: Enable GPU related nodes arch/arm64/boot/dts/qcom/sc8280xp-crd.dts | 26 +++ .../qcom/sc8280xp-lenovo-thinkpad-x13s.dts| 26 +++ arch/arm64/boot/dts/qcom/sc8280xp.dtsi| 181 ++ drivers/gpu/drm/msm/adreno/a6xx_gpu.c | 113 ++- drivers/gpu/drm/msm/adreno/a6xx_hfi.c | 33 drivers/gpu/drm/msm/adreno/adreno_device.c| 14 ++ drivers/gpu/drm/msm/adreno/adreno_gpu.h | 11 +- 7 files changed, 399 insertions(+), 5 deletions(-) -- 2.39.2
Re: [Freedreno] [PATCH] drm/msm/dpu: re-introduce dpu core revision to the catalog
On 5/30/2023 7:53 PM, Dmitry Baryshkov wrote:
On Wed, 31 May 2023 at 03:54, Abhinav Kumar wrote:
With [1] dpu core revision was dropped in favor of using the
compatible string from the device tree to select the dpu catalog
being used in the device.
This approach works well however also necessitates adding catalog
entries for small register level details as dpu capabilities and/or
features bloating the catalog unnecessarily. Examples include but
are not limited to data_compress, interrupt register set, widebus etc.
Introduce the dpu core revision back as an entry to the catalog so that
we can just use dpu revision checks and enable those bits which
should be enabled unconditionally and not controlled by a catalog
and also simplify the changes to do something like:
if (dpu_core_revision > x && dpu_core_revision < x)
enable the bit;
Also, add some of the useful macros back to be able to use dpu core
revision effectively.
[1]: https://patchwork.freedesktop.org/patch/530891/?series=113910=4
Signed-off-by: Abhinav Kumar
---
.../msm/disp/dpu1/catalog/dpu_3_0_msm8998.h | 1 +
.../msm/disp/dpu1/catalog/dpu_4_0_sdm845.h| 1 +
.../msm/disp/dpu1/catalog/dpu_5_0_sm8150.h| 1 +
.../msm/disp/dpu1/catalog/dpu_5_1_sc8180x.h | 1 +
.../msm/disp/dpu1/catalog/dpu_6_0_sm8250.h| 1 +
.../msm/disp/dpu1/catalog/dpu_6_2_sc7180.h| 1 +
.../msm/disp/dpu1/catalog/dpu_6_3_sm6115.h| 1 +
.../msm/disp/dpu1/catalog/dpu_6_5_qcm2290.h | 1 +
.../msm/disp/dpu1/catalog/dpu_7_0_sm8350.h| 1 +
.../msm/disp/dpu1/catalog/dpu_7_2_sc7280.h| 1 +
.../msm/disp/dpu1/catalog/dpu_8_0_sc8280xp.h | 1 +
.../msm/disp/dpu1/catalog/dpu_8_1_sm8450.h| 1 +
.../msm/disp/dpu1/catalog/dpu_9_0_sm8550.h| 1 +
.../gpu/drm/msm/disp/dpu1/dpu_hw_catalog.h| 31 ++-
14 files changed, 43 insertions(+), 1 deletion(-)
[skipped catalog changes]
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.h
b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.h
index 677048cc3b7d..cc4aa75a1219 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.h
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.h
@@ -19,6 +19,33 @@
*/
#define MAX_BLOCKS12
+#define DPU_HW_VER(MAJOR, MINOR, STEP)\
+ unsigned int)MAJOR & 0xF) << 28) |\
+ ((MINOR & 0xFFF) << 16) |\
+ (STEP & 0x))
+
+#define DPU_HW_MAJOR(rev)((rev) >> 28)
+#define DPU_HW_MINOR(rev)(((rev) >> 16) & 0xFFF)
+#define DPU_HW_STEP(rev)((rev) & 0x)
+#define DPU_HW_MAJOR_MINOR(rev)((rev) >> 16)
+
+#define IS_DPU_MAJOR_MINOR_SAME(rev1, rev2) \
+(DPU_HW_MAJOR_MINOR((rev1)) == DPU_HW_MAJOR_MINOR((rev2)))
+
+#define DPU_HW_VER_300 DPU_HW_VER(3, 0, 0) /* 8998 v1.0 */
+#define DPU_HW_VER_400 DPU_HW_VER(4, 0, 0) /* sdm845 v1.0 */
+#define DPU_HW_VER_500 DPU_HW_VER(5, 0, 0) /* sm8150 v1.0 */
+#define DPU_HW_VER_510 DPU_HW_VER(5, 1, 1) /* sc8180 */
+#define DPU_HW_VER_600 DPU_HW_VER(6, 0, 0) /* sm8250 */
+#define DPU_HW_VER_620 DPU_HW_VER(6, 2, 0) /* sc7180 v1.0 */
+#define DPU_HW_VER_630 DPU_HW_VER(6, 3, 0) /* sm6115|sm4250 */
+#define DPU_HW_VER_650 DPU_HW_VER(6, 5, 0) /* qcm2290|sm4125 */
+#define DPU_HW_VER_700 DPU_HW_VER(7, 0, 0) /* sm8350 */
+#define DPU_HW_VER_720 DPU_HW_VER(7, 2, 0) /* sc7280 */
+#define DPU_HW_VER_800 DPU_HW_VER(8, 0, 0) /* sc8280xp */
+#define DPU_HW_VER_810 DPU_HW_VER(8, 1, 0) /* sm8450 */
+#define DPU_HW_VER_900 DPU_HW_VER(9, 0, 0) /* sm8550 */
Instead of having defines for all SoCs (which can quickly become
unmanageable) and can cause merge conflicts, I'd suggest inlining all
the defines into respective catalog files.
Sure, that can be done.
Also, I'm not sure that the "step" should be a part of the catalog. I
know that this follows the hardware revision. However, please correct
me if I'm wrong, different step levels are used for revisions of the
same SoC. The original code that was reading the hw revision from the
hardware register, listed both 5.0.0 and 5.0.1 for sm8150.
This is one of the things i noticed while making this change.
Before the catalog rework, we used to handle even steps as we used to
read that from the register and match it with the mdss_cfg handler. But
after the rework, we dont handle steps anymore. Yes, you are right that
different step levels are used for the revisions of the same SOC and so
with that, i dont expect or atleast am not aware of DPU differences
between steps but I am not able to rule it out.
So are you suggesting we drop step altogether and DPU_HW_VER() macro
shall only handle major and minor versions? With the current chipsets I
see, it should not make a difference . Its just that I am not sure if
that will never happen.
+
#define DPU_HW_BLK_NAME_LEN16
#define MAX_IMG_WIDTH 0x3fff
@@ -769,7 +796,7 @@ struct dpu_perf_cfg {
/**
* struct dpu_mdss_cfg - information of MDSS HW
* This is the main catalog data structure representing
- * this HW
Re: [PATCH] drm/msm/dpu: re-introduce dpu core revision to the catalog
On Wed, 31 May 2023 at 03:54, Abhinav Kumar wrote:
>
> With [1] dpu core revision was dropped in favor of using the
> compatible string from the device tree to select the dpu catalog
> being used in the device.
>
> This approach works well however also necessitates adding catalog
> entries for small register level details as dpu capabilities and/or
> features bloating the catalog unnecessarily. Examples include but
> are not limited to data_compress, interrupt register set, widebus etc.
>
> Introduce the dpu core revision back as an entry to the catalog so that
> we can just use dpu revision checks and enable those bits which
> should be enabled unconditionally and not controlled by a catalog
> and also simplify the changes to do something like:
>
> if (dpu_core_revision > x && dpu_core_revision < x)
> enable the bit;
>
> Also, add some of the useful macros back to be able to use dpu core
> revision effectively.
>
> [1]: https://patchwork.freedesktop.org/patch/530891/?series=113910=4
>
> Signed-off-by: Abhinav Kumar
> ---
> .../msm/disp/dpu1/catalog/dpu_3_0_msm8998.h | 1 +
> .../msm/disp/dpu1/catalog/dpu_4_0_sdm845.h| 1 +
> .../msm/disp/dpu1/catalog/dpu_5_0_sm8150.h| 1 +
> .../msm/disp/dpu1/catalog/dpu_5_1_sc8180x.h | 1 +
> .../msm/disp/dpu1/catalog/dpu_6_0_sm8250.h| 1 +
> .../msm/disp/dpu1/catalog/dpu_6_2_sc7180.h| 1 +
> .../msm/disp/dpu1/catalog/dpu_6_3_sm6115.h| 1 +
> .../msm/disp/dpu1/catalog/dpu_6_5_qcm2290.h | 1 +
> .../msm/disp/dpu1/catalog/dpu_7_0_sm8350.h| 1 +
> .../msm/disp/dpu1/catalog/dpu_7_2_sc7280.h| 1 +
> .../msm/disp/dpu1/catalog/dpu_8_0_sc8280xp.h | 1 +
> .../msm/disp/dpu1/catalog/dpu_8_1_sm8450.h| 1 +
> .../msm/disp/dpu1/catalog/dpu_9_0_sm8550.h| 1 +
> .../gpu/drm/msm/disp/dpu1/dpu_hw_catalog.h| 31 ++-
> 14 files changed, 43 insertions(+), 1 deletion(-)
>
[skipped catalog changes]
> diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.h
> b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.h
> index 677048cc3b7d..cc4aa75a1219 100644
> --- a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.h
> +++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.h
> @@ -19,6 +19,33 @@
> */
> #define MAX_BLOCKS12
>
> +#define DPU_HW_VER(MAJOR, MINOR, STEP)\
> + unsigned int)MAJOR & 0xF) << 28) |\
> + ((MINOR & 0xFFF) << 16) |\
> + (STEP & 0x))
> +
> +#define DPU_HW_MAJOR(rev)((rev) >> 28)
> +#define DPU_HW_MINOR(rev)(((rev) >> 16) & 0xFFF)
> +#define DPU_HW_STEP(rev)((rev) & 0x)
> +#define DPU_HW_MAJOR_MINOR(rev)((rev) >> 16)
> +
> +#define IS_DPU_MAJOR_MINOR_SAME(rev1, rev2) \
> +(DPU_HW_MAJOR_MINOR((rev1)) == DPU_HW_MAJOR_MINOR((rev2)))
> +
> +#define DPU_HW_VER_300 DPU_HW_VER(3, 0, 0) /* 8998 v1.0 */
> +#define DPU_HW_VER_400 DPU_HW_VER(4, 0, 0) /* sdm845 v1.0 */
> +#define DPU_HW_VER_500 DPU_HW_VER(5, 0, 0) /* sm8150 v1.0 */
> +#define DPU_HW_VER_510 DPU_HW_VER(5, 1, 1) /* sc8180 */
> +#define DPU_HW_VER_600 DPU_HW_VER(6, 0, 0) /* sm8250 */
> +#define DPU_HW_VER_620 DPU_HW_VER(6, 2, 0) /* sc7180 v1.0 */
> +#define DPU_HW_VER_630 DPU_HW_VER(6, 3, 0) /* sm6115|sm4250 */
> +#define DPU_HW_VER_650 DPU_HW_VER(6, 5, 0) /* qcm2290|sm4125 */
> +#define DPU_HW_VER_700 DPU_HW_VER(7, 0, 0) /* sm8350 */
> +#define DPU_HW_VER_720 DPU_HW_VER(7, 2, 0) /* sc7280 */
> +#define DPU_HW_VER_800 DPU_HW_VER(8, 0, 0) /* sc8280xp */
> +#define DPU_HW_VER_810 DPU_HW_VER(8, 1, 0) /* sm8450 */
> +#define DPU_HW_VER_900 DPU_HW_VER(9, 0, 0) /* sm8550 */
Instead of having defines for all SoCs (which can quickly become
unmanageable) and can cause merge conflicts, I'd suggest inlining all
the defines into respective catalog files.
Also, I'm not sure that the "step" should be a part of the catalog. I
know that this follows the hardware revision. However, please correct
me if I'm wrong, different step levels are used for revisions of the
same SoC. The original code that was reading the hw revision from the
hardware register, listed both 5.0.0 and 5.0.1 for sm8150.
> +
> #define DPU_HW_BLK_NAME_LEN16
>
> #define MAX_IMG_WIDTH 0x3fff
> @@ -769,7 +796,7 @@ struct dpu_perf_cfg {
> /**
> * struct dpu_mdss_cfg - information of MDSS HW
> * This is the main catalog data structure representing
> - * this HW version. Contains number of instances,
> + * this HW version. Contains dpu core revision, number of instances,
> * register offsets, capabilities of the all MDSS HW sub-blocks.
> *
> * @dma_formatsSupported formats for dma pipe
> @@ -778,6 +805,8 @@ struct dpu_perf_cfg {
> * @mdss_irqs: Bitmap with the irqs supported by the target
> */
> struct dpu_mdss_cfg {
> + u32 core_rev;
> +
> const struct dpu_caps *caps;
>
> const struct dpu_ubwc_cfg *ubwc;
> --
> 2.40.1
>
--
With best wishes
Dmitry
Re: [PATCH] drm/panel-edp: Convert to platform remove callback returning void
Hi, On Tue, May 30, 2023 at 12:42 AM Uwe Kleine-König wrote: > > The .remove() callback for a platform driver returns an int which makes > many driver authors wrongly assume it's possible to do error handling by > returning an error code. However the value returned is (mostly) ignored > and this typically results in resource leaks. To improve here there is a > quest to make the remove callback return void. In the first step of this > quest all drivers are converted to .remove_new() which already returns > void. > > panel_edp_remove() always returned zero, so convert it to return void > without any loss and then just drop the return from > panel_edp_platform_remove(). > > Signed-off-by: Uwe Kleine-König > --- > drivers/gpu/drm/panel/panel-edp.c | 10 -- > 1 file changed, 4 insertions(+), 6 deletions(-) Looks great, thanks. Reviewed-by: Douglas Anderson I see no reason for a delay in applying, so I pushed to drm-misc-next: 72a597aed1d9 drm/panel-edp: Convert to platform remove callback returning void
Re: [PATCH] drm/msm/dpu: re-introduce dpu core revision to the catalog
On 5/30/2023 7:16 PM, Bjorn Andersson wrote:
On Tue, May 30, 2023 at 05:53:55PM -0700, Abhinav Kumar wrote:
With [1] dpu core revision was dropped in favor of using the
compatible string from the device tree to select the dpu catalog
being used in the device.
This approach works well however also necessitates adding catalog
entries for small register level details as dpu capabilities and/or
features bloating the catalog unnecessarily. Examples include but
are not limited to data_compress, interrupt register set, widebus etc.
Introduce the dpu core revision back as an entry to the catalog so that
we can just use dpu revision checks and enable those bits which
should be enabled unconditionally and not controlled by a catalog
and also simplify the changes to do something like:
if (dpu_core_revision > x && dpu_core_revision < x)
enable the bit;
Also, add some of the useful macros back to be able to use dpu core
revision effectively.
[1]: https://patchwork.freedesktop.org/patch/530891/?series=113910=4
No concerns with the patch, it looks good and the argumentation sounds
reasonable. But it would be preferable to introduce it together with an
actual user (or am I just missing it?).
Regards,
Bjorn
The plan is that the DSC over DP (to be posted in a week or week.5), DSC
over DSI (already on the list) , widebus (already on the list) and
perhaps even the interrupt cleanup (already on the list) will be rebased
on top of this.
Its just that the authors for those are different.
If we agree on this change, the rebased versions for those can be posted
to the list. That was the intention of posting this first as I didnt
want others to rebase if this wasnt going to be accepted.
Signed-off-by: Abhinav Kumar
---
.../msm/disp/dpu1/catalog/dpu_3_0_msm8998.h | 1 +
.../msm/disp/dpu1/catalog/dpu_4_0_sdm845.h| 1 +
.../msm/disp/dpu1/catalog/dpu_5_0_sm8150.h| 1 +
.../msm/disp/dpu1/catalog/dpu_5_1_sc8180x.h | 1 +
.../msm/disp/dpu1/catalog/dpu_6_0_sm8250.h| 1 +
.../msm/disp/dpu1/catalog/dpu_6_2_sc7180.h| 1 +
.../msm/disp/dpu1/catalog/dpu_6_3_sm6115.h| 1 +
.../msm/disp/dpu1/catalog/dpu_6_5_qcm2290.h | 1 +
.../msm/disp/dpu1/catalog/dpu_7_0_sm8350.h| 1 +
.../msm/disp/dpu1/catalog/dpu_7_2_sc7280.h| 1 +
.../msm/disp/dpu1/catalog/dpu_8_0_sc8280xp.h | 1 +
.../msm/disp/dpu1/catalog/dpu_8_1_sm8450.h| 1 +
.../msm/disp/dpu1/catalog/dpu_9_0_sm8550.h| 1 +
.../gpu/drm/msm/disp/dpu1/dpu_hw_catalog.h| 31 ++-
14 files changed, 43 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_3_0_msm8998.h
b/drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_3_0_msm8998.h
index 3c732a0360c7..16c2861e0359 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_3_0_msm8998.h
+++ b/drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_3_0_msm8998.h
@@ -185,6 +185,7 @@ static const struct dpu_perf_cfg msm8998_perf_data = {
};
const struct dpu_mdss_cfg dpu_msm8998_cfg = {
+ .core_rev = DPU_HW_VER_300,
.caps = _dpu_caps,
.ubwc = _ubwc_cfg,
.mdp_count = ARRAY_SIZE(msm8998_mdp),
diff --git a/drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_4_0_sdm845.h
b/drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_4_0_sdm845.h
index 36ea1af10894..1c003935c948 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_4_0_sdm845.h
+++ b/drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_4_0_sdm845.h
@@ -183,6 +183,7 @@ static const struct dpu_perf_cfg sdm845_perf_data = {
};
const struct dpu_mdss_cfg dpu_sdm845_cfg = {
+ .core_rev = DPU_HW_VER_400,
.caps = _dpu_caps,
.ubwc = _ubwc_cfg,
.mdp_count = ARRAY_SIZE(sdm845_mdp),
diff --git a/drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_5_0_sm8150.h
b/drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_5_0_sm8150.h
index b5f751354267..8c914be62a88 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_5_0_sm8150.h
+++ b/drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_5_0_sm8150.h
@@ -208,6 +208,7 @@ static const struct dpu_perf_cfg sm8150_perf_data = {
};
const struct dpu_mdss_cfg dpu_sm8150_cfg = {
+ .core_rev = DPU_HW_VER_500,
.caps = _dpu_caps,
.ubwc = _ubwc_cfg,
.mdp_count = ARRAY_SIZE(sm8150_mdp),
diff --git a/drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_5_1_sc8180x.h
b/drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_5_1_sc8180x.h
index 8ed2b263c5ea..9465bde128eb 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_5_1_sc8180x.h
+++ b/drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_5_1_sc8180x.h
@@ -214,6 +214,7 @@ static const struct dpu_perf_cfg sc8180x_perf_data = {
};
const struct dpu_mdss_cfg dpu_sc8180x_cfg = {
+ .core_rev = DPU_HW_VER_510,
.caps = _dpu_caps,
.ubwc = _ubwc_cfg,
.mdp_count = ARRAY_SIZE(sc8180x_mdp),
diff --git a/drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_6_0_sm8250.h
b/drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_6_0_sm8250.h
index daebd2170041..1b04ecfb7cde
Re: [PATCH v2] drm: Switch i2c drivers back to use .probe()
Hi,
On Fri, May 26, 2023 at 7:43 AM Doug Anderson wrote:
>
> Hi,
>
> On Fri, May 26, 2023 at 2:08 AM Uwe Kleine-König
> wrote:
> >
> > After commit b8a1a4cd5a98 ("i2c: Provide a temporary .probe_new()
> > call-back type"), all drivers being converted to .probe_new() and then
> > 03c835f498b5 ("i2c: Switch .probe() to not take an id parameter") convert
> > back to (the new) .probe() to be able to eventually drop .probe_new() from
> > struct i2c_driver.
> >
> > Signed-off-by: Uwe Kleine-König
> > ---
> > Hello,
> >
> > I didn't get feedback for (implicit) v1 that was sent with Message-Id:
> > <20230427175954.666464-1-u.kleine-koe...@pengutronix.de>. This is a
> > rebase on v6.4-rc1 as the former patch doesn't apply cleanly any more.
> >
> > I also added more people to Cc, maybe that helps to get feedback.
> >
> > This patch is based on v6.4-rc1, and applies fine on today's next.
> > (There are also no new drivers that need adaption in next.)
> >
> > Thanks for considering,
> > Uwe
> >
> > drivers/gpu/drm/bridge/adv7511/adv7511_drv.c | 2 +-
> > drivers/gpu/drm/bridge/analogix/analogix-anx6345.c | 2 +-
> > drivers/gpu/drm/bridge/analogix/analogix-anx78xx.c | 2 +-
> > drivers/gpu/drm/bridge/analogix/anx7625.c| 2 +-
> > drivers/gpu/drm/bridge/chipone-icn6211.c | 2 +-
> > drivers/gpu/drm/bridge/chrontel-ch7033.c | 2 +-
> > drivers/gpu/drm/bridge/cros-ec-anx7688.c | 2 +-
> > drivers/gpu/drm/bridge/ite-it6505.c | 2 +-
> > drivers/gpu/drm/bridge/ite-it66121.c | 2 +-
> > drivers/gpu/drm/bridge/lontium-lt8912b.c | 2 +-
> > drivers/gpu/drm/bridge/lontium-lt9211.c | 2 +-
> > drivers/gpu/drm/bridge/lontium-lt9611.c | 2 +-
> > drivers/gpu/drm/bridge/lontium-lt9611uxc.c | 2 +-
> > drivers/gpu/drm/bridge/megachips-stdp-ge-b850v3-fw.c | 4 ++--
> > drivers/gpu/drm/bridge/nxp-ptn3460.c | 2 +-
> > drivers/gpu/drm/bridge/parade-ps8622.c | 2 +-
> > drivers/gpu/drm/bridge/parade-ps8640.c | 2 +-
> > drivers/gpu/drm/bridge/sii902x.c | 2 +-
> > drivers/gpu/drm/bridge/sii9234.c | 2 +-
> > drivers/gpu/drm/bridge/sil-sii8620.c | 2 +-
> > drivers/gpu/drm/bridge/tc358767.c| 2 +-
> > drivers/gpu/drm/bridge/tc358768.c| 2 +-
> > drivers/gpu/drm/bridge/tc358775.c| 2 +-
> > drivers/gpu/drm/bridge/ti-dlpc3433.c | 2 +-
> > drivers/gpu/drm/bridge/ti-sn65dsi83.c| 2 +-
> > drivers/gpu/drm/bridge/ti-sn65dsi86.c| 2 +-
> > drivers/gpu/drm/bridge/ti-tfp410.c | 2 +-
> > drivers/gpu/drm/i2c/tda9950.c| 2 +-
> > drivers/gpu/drm/i2c/tda998x_drv.c| 2 +-
> > drivers/gpu/drm/panel/panel-olimex-lcd-olinuxino.c | 2 +-
> > drivers/gpu/drm/panel/panel-raspberrypi-touchscreen.c| 2 +-
> > drivers/gpu/drm/solomon/ssd130x-i2c.c| 2 +-
> > 32 files changed, 33 insertions(+), 33 deletions(-)
>
> Reviewed-by: Douglas Anderson
>
> This does apply to drm-misc-next and I'm happy to apply it there, but
> I'm a bit iffy doing it on the Friday before a 3-day weekend (Monday
> is a holiday in the US). If this is still pending next Tuesday and I'm
> not swamped then, I'll plan to apply it. I'm more than happy if a
> different drm commtter wants to apply it sooner. Thanks!
As promised, pushed to drm-misc-next:
332af828ce78 drm: Switch i2c drivers back to use .probe()
[PATCH -next] drm/i915: remove unreachable code
The code after the return will not be executed, so remove them. Eliminate the following warning: drivers/gpu/drm/i915/display/intel_color.c:1808 intel_color_prepare_commit() warn: ignoring unreachable code. Reported-by: Abaci Robot Closes: https://bugzilla.openanolis.cn/show_bug.cgi?id=5342 Signed-off-by: Yang Li --- drivers/gpu/drm/i915/display/intel_color.c | 5 - 1 file changed, 5 deletions(-) diff --git a/drivers/gpu/drm/i915/display/intel_color.c b/drivers/gpu/drm/i915/display/intel_color.c index 8966e6560516..0bfebac1e3e2 100644 --- a/drivers/gpu/drm/i915/display/intel_color.c +++ b/drivers/gpu/drm/i915/display/intel_color.c @@ -1804,11 +1804,6 @@ void intel_color_prepare_commit(struct intel_crtc_state *crtc_state) /* FIXME DSB has issues loading LUTs, disable it for now */ return; - - if (!crtc_state->pre_csc_lut && !crtc_state->post_csc_lut) - return; - - crtc_state->dsb = intel_dsb_prepare(crtc, 1024); } void intel_color_cleanup_commit(struct intel_crtc_state *crtc_state) -- 2.20.1.7.g153144c
Re: [PATCH] drm/msm/dpu: re-introduce dpu core revision to the catalog
On Tue, May 30, 2023 at 05:53:55PM -0700, Abhinav Kumar wrote:
> With [1] dpu core revision was dropped in favor of using the
> compatible string from the device tree to select the dpu catalog
> being used in the device.
>
> This approach works well however also necessitates adding catalog
> entries for small register level details as dpu capabilities and/or
> features bloating the catalog unnecessarily. Examples include but
> are not limited to data_compress, interrupt register set, widebus etc.
>
> Introduce the dpu core revision back as an entry to the catalog so that
> we can just use dpu revision checks and enable those bits which
> should be enabled unconditionally and not controlled by a catalog
> and also simplify the changes to do something like:
>
> if (dpu_core_revision > x && dpu_core_revision < x)
> enable the bit;
>
> Also, add some of the useful macros back to be able to use dpu core
> revision effectively.
>
> [1]: https://patchwork.freedesktop.org/patch/530891/?series=113910=4
>
No concerns with the patch, it looks good and the argumentation sounds
reasonable. But it would be preferable to introduce it together with an
actual user (or am I just missing it?).
Regards,
Bjorn
> Signed-off-by: Abhinav Kumar
> ---
> .../msm/disp/dpu1/catalog/dpu_3_0_msm8998.h | 1 +
> .../msm/disp/dpu1/catalog/dpu_4_0_sdm845.h| 1 +
> .../msm/disp/dpu1/catalog/dpu_5_0_sm8150.h| 1 +
> .../msm/disp/dpu1/catalog/dpu_5_1_sc8180x.h | 1 +
> .../msm/disp/dpu1/catalog/dpu_6_0_sm8250.h| 1 +
> .../msm/disp/dpu1/catalog/dpu_6_2_sc7180.h| 1 +
> .../msm/disp/dpu1/catalog/dpu_6_3_sm6115.h| 1 +
> .../msm/disp/dpu1/catalog/dpu_6_5_qcm2290.h | 1 +
> .../msm/disp/dpu1/catalog/dpu_7_0_sm8350.h| 1 +
> .../msm/disp/dpu1/catalog/dpu_7_2_sc7280.h| 1 +
> .../msm/disp/dpu1/catalog/dpu_8_0_sc8280xp.h | 1 +
> .../msm/disp/dpu1/catalog/dpu_8_1_sm8450.h| 1 +
> .../msm/disp/dpu1/catalog/dpu_9_0_sm8550.h| 1 +
> .../gpu/drm/msm/disp/dpu1/dpu_hw_catalog.h| 31 ++-
> 14 files changed, 43 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_3_0_msm8998.h
> b/drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_3_0_msm8998.h
> index 3c732a0360c7..16c2861e0359 100644
> --- a/drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_3_0_msm8998.h
> +++ b/drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_3_0_msm8998.h
> @@ -185,6 +185,7 @@ static const struct dpu_perf_cfg msm8998_perf_data = {
> };
>
> const struct dpu_mdss_cfg dpu_msm8998_cfg = {
> + .core_rev = DPU_HW_VER_300,
> .caps = _dpu_caps,
> .ubwc = _ubwc_cfg,
> .mdp_count = ARRAY_SIZE(msm8998_mdp),
> diff --git a/drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_4_0_sdm845.h
> b/drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_4_0_sdm845.h
> index 36ea1af10894..1c003935c948 100644
> --- a/drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_4_0_sdm845.h
> +++ b/drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_4_0_sdm845.h
> @@ -183,6 +183,7 @@ static const struct dpu_perf_cfg sdm845_perf_data = {
> };
>
> const struct dpu_mdss_cfg dpu_sdm845_cfg = {
> + .core_rev = DPU_HW_VER_400,
> .caps = _dpu_caps,
> .ubwc = _ubwc_cfg,
> .mdp_count = ARRAY_SIZE(sdm845_mdp),
> diff --git a/drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_5_0_sm8150.h
> b/drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_5_0_sm8150.h
> index b5f751354267..8c914be62a88 100644
> --- a/drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_5_0_sm8150.h
> +++ b/drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_5_0_sm8150.h
> @@ -208,6 +208,7 @@ static const struct dpu_perf_cfg sm8150_perf_data = {
> };
>
> const struct dpu_mdss_cfg dpu_sm8150_cfg = {
> + .core_rev = DPU_HW_VER_500,
> .caps = _dpu_caps,
> .ubwc = _ubwc_cfg,
> .mdp_count = ARRAY_SIZE(sm8150_mdp),
> diff --git a/drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_5_1_sc8180x.h
> b/drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_5_1_sc8180x.h
> index 8ed2b263c5ea..9465bde128eb 100644
> --- a/drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_5_1_sc8180x.h
> +++ b/drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_5_1_sc8180x.h
> @@ -214,6 +214,7 @@ static const struct dpu_perf_cfg sc8180x_perf_data = {
> };
>
> const struct dpu_mdss_cfg dpu_sc8180x_cfg = {
> + .core_rev = DPU_HW_VER_510,
> .caps = _dpu_caps,
> .ubwc = _ubwc_cfg,
> .mdp_count = ARRAY_SIZE(sc8180x_mdp),
> diff --git a/drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_6_0_sm8250.h
> b/drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_6_0_sm8250.h
> index daebd2170041..1b04ecfb7cde 100644
> --- a/drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_6_0_sm8250.h
> +++ b/drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_6_0_sm8250.h
> @@ -214,6 +214,7 @@ static const struct dpu_perf_cfg sm8250_perf_data = {
> };
>
> const struct dpu_mdss_cfg dpu_sm8250_cfg = {
> + .core_rev = DPU_HW_VER_600,
> .caps = _dpu_caps,
> .ubwc = _ubwc_cfg,
> .mdp_count = ARRAY_SIZE(sm8250_mdp),
> diff --git
[PATCH -next] drm/amdkfd: clean up one inconsistent indenting
drivers/gpu/drm/amd/amdgpu/../amdkfd/kfd_device.c:1036 kgd2kfd_interrupt()
warn: inconsistent indenting
Signed-off-by: Yang Li
---
drivers/gpu/drm/amd/amdkfd/kfd_device.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/amd/amdkfd/kfd_device.c
b/drivers/gpu/drm/amd/amdkfd/kfd_device.c
index 862a50f7b490..0398a8c52a44 100644
--- a/drivers/gpu/drm/amd/amdkfd/kfd_device.c
+++ b/drivers/gpu/drm/amd/amdkfd/kfd_device.c
@@ -1033,7 +1033,7 @@ void kgd2kfd_interrupt(struct kfd_dev *kfd, const void
*ih_ring_entry)
is_patched ? patched_ihre : ih_ring_entry)) {
kfd_queue_work(node->ih_wq, >interrupt_work);
spin_unlock_irqrestore(>interrupt_lock, flags);
- return;
+ return;
}
spin_unlock_irqrestore(>interrupt_lock, flags);
}
--
2.20.1.7.g153144c
[PATCH] dt-bindings: samsung,mipi-dsim: Use port-base reference
From: Fabio Estevam
Use port-base reference for port@0 and port@1.
This fixes the following schema warning:
imx8mm-evk.dtb: dsi@32e1: ports:port@1:endpoint: Unevaluated properties are
not allowed ('data-lanes' was unexpected)
>From schema:
>Documentation/devicetree/bindings/display/bridge/samsung,mipi-dsim.yaml
Fixes: 1f0d40d88f7a ("dt-bindings: bridge: Convert Samsung MIPI DSIM bridge to
yaml")
Signed-off-by: Fabio Estevam
---
.../devicetree/bindings/display/bridge/samsung,mipi-dsim.yaml | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git
a/Documentation/devicetree/bindings/display/bridge/samsung,mipi-dsim.yaml
b/Documentation/devicetree/bindings/display/bridge/samsung,mipi-dsim.yaml
index 9f61ebdfefa8..51879030dd6d 100644
--- a/Documentation/devicetree/bindings/display/bridge/samsung,mipi-dsim.yaml
+++ b/Documentation/devicetree/bindings/display/bridge/samsung,mipi-dsim.yaml
@@ -93,14 +93,14 @@ properties:
properties:
port@0:
-$ref: /schemas/graph.yaml#/properties/port
+$ref: /schemas/graph.yaml#/$defs/port-base
description:
Input port node to receive pixel data from the
display controller. Exactly one endpoint must be
specified.
port@1:
-$ref: /schemas/graph.yaml#/properties/port
+$ref: /schemas/graph.yaml#/$defs/port-base
description:
DSI output port node to the panel or the next bridge
in the chain.
--
2.34.1
Re: [PATCH] drm/ttm: Remove redundant code in ttm_tt_init_fields
On 5/30/2023 4:59 PM, Christian König wrote:
> Am 29.05.23 um 11:28 schrieb Ma Jun:
>> Remove redundant assignment code for ttm->caching
>
> The explanation is missing why this is redundant, e.g. something like
> "this is overwritten just a few lines later"..
>
Thanks for review. Will update the commit message in v2
Regards,
Ma Jun
> Apart from that looks good to me,
> Christian.,
>
>>
>> Signed-off-by: Ma Jun
>> ---
>> drivers/gpu/drm/ttm/ttm_tt.c | 1 -
>> 1 file changed, 1 deletion(-)
>>
>> diff --git a/drivers/gpu/drm/ttm/ttm_tt.c b/drivers/gpu/drm/ttm/ttm_tt.c
>> index 02b812dacc5d..45a44544b656 100644
>> --- a/drivers/gpu/drm/ttm/ttm_tt.c
>> +++ b/drivers/gpu/drm/ttm/ttm_tt.c
>> @@ -143,7 +143,6 @@ static void ttm_tt_init_fields(struct ttm_tt *ttm,
>> unsigned long extra_pages)
>> {
>> ttm->num_pages = (PAGE_ALIGN(bo->base.size) >> PAGE_SHIFT) +
>> extra_pages;
>> -ttm->caching = ttm_cached;
>> ttm->page_flags = page_flags;
>> ttm->dma_address = NULL;
>> ttm->swap_storage = NULL;
>
[PATCH] drm/msm/dpu: re-introduce dpu core revision to the catalog
With [1] dpu core revision was dropped in favor of using the
compatible string from the device tree to select the dpu catalog
being used in the device.
This approach works well however also necessitates adding catalog
entries for small register level details as dpu capabilities and/or
features bloating the catalog unnecessarily. Examples include but
are not limited to data_compress, interrupt register set, widebus etc.
Introduce the dpu core revision back as an entry to the catalog so that
we can just use dpu revision checks and enable those bits which
should be enabled unconditionally and not controlled by a catalog
and also simplify the changes to do something like:
if (dpu_core_revision > x && dpu_core_revision < x)
enable the bit;
Also, add some of the useful macros back to be able to use dpu core
revision effectively.
[1]: https://patchwork.freedesktop.org/patch/530891/?series=113910=4
Signed-off-by: Abhinav Kumar
---
.../msm/disp/dpu1/catalog/dpu_3_0_msm8998.h | 1 +
.../msm/disp/dpu1/catalog/dpu_4_0_sdm845.h| 1 +
.../msm/disp/dpu1/catalog/dpu_5_0_sm8150.h| 1 +
.../msm/disp/dpu1/catalog/dpu_5_1_sc8180x.h | 1 +
.../msm/disp/dpu1/catalog/dpu_6_0_sm8250.h| 1 +
.../msm/disp/dpu1/catalog/dpu_6_2_sc7180.h| 1 +
.../msm/disp/dpu1/catalog/dpu_6_3_sm6115.h| 1 +
.../msm/disp/dpu1/catalog/dpu_6_5_qcm2290.h | 1 +
.../msm/disp/dpu1/catalog/dpu_7_0_sm8350.h| 1 +
.../msm/disp/dpu1/catalog/dpu_7_2_sc7280.h| 1 +
.../msm/disp/dpu1/catalog/dpu_8_0_sc8280xp.h | 1 +
.../msm/disp/dpu1/catalog/dpu_8_1_sm8450.h| 1 +
.../msm/disp/dpu1/catalog/dpu_9_0_sm8550.h| 1 +
.../gpu/drm/msm/disp/dpu1/dpu_hw_catalog.h| 31 ++-
14 files changed, 43 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_3_0_msm8998.h
b/drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_3_0_msm8998.h
index 3c732a0360c7..16c2861e0359 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_3_0_msm8998.h
+++ b/drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_3_0_msm8998.h
@@ -185,6 +185,7 @@ static const struct dpu_perf_cfg msm8998_perf_data = {
};
const struct dpu_mdss_cfg dpu_msm8998_cfg = {
+ .core_rev = DPU_HW_VER_300,
.caps = _dpu_caps,
.ubwc = _ubwc_cfg,
.mdp_count = ARRAY_SIZE(msm8998_mdp),
diff --git a/drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_4_0_sdm845.h
b/drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_4_0_sdm845.h
index 36ea1af10894..1c003935c948 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_4_0_sdm845.h
+++ b/drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_4_0_sdm845.h
@@ -183,6 +183,7 @@ static const struct dpu_perf_cfg sdm845_perf_data = {
};
const struct dpu_mdss_cfg dpu_sdm845_cfg = {
+ .core_rev = DPU_HW_VER_400,
.caps = _dpu_caps,
.ubwc = _ubwc_cfg,
.mdp_count = ARRAY_SIZE(sdm845_mdp),
diff --git a/drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_5_0_sm8150.h
b/drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_5_0_sm8150.h
index b5f751354267..8c914be62a88 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_5_0_sm8150.h
+++ b/drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_5_0_sm8150.h
@@ -208,6 +208,7 @@ static const struct dpu_perf_cfg sm8150_perf_data = {
};
const struct dpu_mdss_cfg dpu_sm8150_cfg = {
+ .core_rev = DPU_HW_VER_500,
.caps = _dpu_caps,
.ubwc = _ubwc_cfg,
.mdp_count = ARRAY_SIZE(sm8150_mdp),
diff --git a/drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_5_1_sc8180x.h
b/drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_5_1_sc8180x.h
index 8ed2b263c5ea..9465bde128eb 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_5_1_sc8180x.h
+++ b/drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_5_1_sc8180x.h
@@ -214,6 +214,7 @@ static const struct dpu_perf_cfg sc8180x_perf_data = {
};
const struct dpu_mdss_cfg dpu_sc8180x_cfg = {
+ .core_rev = DPU_HW_VER_510,
.caps = _dpu_caps,
.ubwc = _ubwc_cfg,
.mdp_count = ARRAY_SIZE(sc8180x_mdp),
diff --git a/drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_6_0_sm8250.h
b/drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_6_0_sm8250.h
index daebd2170041..1b04ecfb7cde 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_6_0_sm8250.h
+++ b/drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_6_0_sm8250.h
@@ -214,6 +214,7 @@ static const struct dpu_perf_cfg sm8250_perf_data = {
};
const struct dpu_mdss_cfg dpu_sm8250_cfg = {
+ .core_rev = DPU_HW_VER_600,
.caps = _dpu_caps,
.ubwc = _ubwc_cfg,
.mdp_count = ARRAY_SIZE(sm8250_mdp),
diff --git a/drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_6_2_sc7180.h
b/drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_6_2_sc7180.h
index 0b05da2592c0..16e905e35025 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_6_2_sc7180.h
+++ b/drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_6_2_sc7180.h
@@ -128,6 +128,7 @@ static const struct dpu_perf_cfg sc7180_perf_data = {
};
const struct dpu_mdss_cfg dpu_sc7180_cfg = {
+ .core_rev = DPU_HW_VER_620,
Re: [PATCH v3 5/7] drm/i915/mtl/huc: auth HuC via GSC
On Fri, 2023-05-26 at 17:52 -0700, Ceraolo Spurio, Daniele wrote:
> The full authentication via the GSC requires an heci packet submission
> to the GSC FW via the GSC CS. The GSC has new PXP command for this
> (literally called NEW_HUC_AUTH).
> The intel_huc_auth fuction is also updated to handle both authentication
> types.
>
alan:snip
> diff --git a/drivers/gpu/drm/i915/gt/uc/intel_gsc_uc.c
> b/drivers/gpu/drm/i915/gt/uc/intel_gsc_uc.c
> index b26f493f86fa..c659cc01f32f 100644
> --- a/drivers/gpu/drm/i915/gt/uc/intel_gsc_uc.c
> +++ b/drivers/gpu/drm/i915/gt/uc/intel_gsc_uc.c
> @@ -29,13 +29,32 @@ static void gsc_work(struct work_struct *work)
>
> if (actions & GSC_ACTION_FW_LOAD) {
> ret = intel_gsc_uc_fw_upload(gsc);
> - if (ret == -EEXIST) /* skip proxy if not a new load */
> - actions &= ~GSC_ACTION_FW_LOAD;
> - else if (ret)
> + if (!ret)
> + /* setup proxy on a new load */
> + actions |= GSC_ACTION_SW_PROXY;
> + else if (ret != -EEXIST)
> goto out_put;
alan: I realize that this worker doesnt print error values that
come back from intel_gsc_uc_fw_upload - wonder if we should print
it before goto out_put.
> +
> + /*
> + * The HuC auth can be done both before or after the proxy init;
> + * if done after, a proxy request will be issued and must be
> + * serviced before the authentication can complete.
> + * Since this worker also handles proxy requests, we can't
> + * perform an action that requires the proxy from within it and
> + * then stall waiting for it, because we'd be blocking the
> + * service path. Therefore, it is easier for us to load HuC
> + * first and do proxy later. The GSC will ack the HuC auth and
> + * then send the HuC proxy request as part of the proxy init
> + * flow.
> + * Note that we can only do the GSC auth if the GuC auth was
> + * successful.
> + */
> + if (intel_uc_uses_huc(>uc) &&
> + intel_huc_is_authenticated(>uc.huc,
> INTEL_HUC_AUTH_BY_GUC))
> + intel_huc_auth(>uc.huc, INTEL_HUC_AUTH_BY_GSC);
> }
>
> - if (actions & (GSC_ACTION_FW_LOAD | GSC_ACTION_SW_PROXY)) {
> + if (actions & GSC_ACTION_SW_PROXY) {
> if (!intel_gsc_uc_fw_init_done(gsc)) {
> gt_err(gt, "Proxy request received with GSC not
> loaded!\n");
> goto out_put;
> diff --git a/drivers/gpu/drm/i915/gt/uc/intel_gsc_uc_heci_cmd_submit.c
> b/drivers/gpu/drm/i915/gt/uc/intel_gsc_uc_heci_cmd_submit.c
> index 579c0f5a1438..0ad090304ca0 100644
> --- a/drivers/gpu/drm/i915/gt/uc/intel_gsc_uc_heci_cmd_submit.c
> +++ b/drivers/gpu/drm/i915/gt/uc/intel_gsc_uc_heci_cmd_submit.c
>
alan:snip
> diff --git a/drivers/gpu/drm/i915/gt/uc/intel_huc.c
> b/drivers/gpu/drm/i915/gt/uc/intel_huc.c
> index ab5246ae3979..5a4058d39550 100644
> --- a/drivers/gpu/drm/i915/gt/uc/intel_huc.c
> +++ b/drivers/gpu/drm/i915/gt/uc/intel_huc.c
>
alan:snip
> diff --git a/drivers/gpu/drm/i915/gt/uc/intel_huc_fw.c
> b/drivers/gpu/drm/i915/gt/uc/intel_huc_fw.c
> index d2b4176c81d6..8e538d639b05 100644
> --- a/drivers/gpu/drm/i915/gt/uc/intel_huc_fw.c
> +++ b/drivers/gpu/drm/i915/gt/uc/intel_huc_fw.c
>
alan:snip
> +int intel_huc_fw_auth_via_gsccs(struct intel_huc *huc)
> +{
> + struct drm_i915_gem_object *obj;
> + void *pkt_vaddr;
> + u64 pkt_offset;
> + int retry = 5;
> + int err = 0;
> +
> + if (!huc->heci_pkt)
> + return -ENODEV;
> +
> + obj = huc->heci_pkt->obj;
> + pkt_offset = i915_ggtt_offset(huc->heci_pkt);
> +
> + pkt_vaddr = i915_gem_object_pin_map_unlocked(obj,
> +
> i915_coherent_map_type(i915, obj, true));
> + if (IS_ERR(pkt_vaddr))
> + return PTR_ERR(pkt_vaddr);
> +
> + msg_in = pkt_vaddr;
> + msg_out = pkt_vaddr + SZ_4K;
this 4K*2 (4k for input and 4K for output) seems to be hardcoded in two
different locations.
One is here in intel_huc_fw_auth_via_gsccs and the other location in
intel_huc_init which was
even in a different file. Perhaps its better to use a #define after to the
definition of
PXP43_CMDID_NEW_HUC_AUTH... maybe something like a "#define
PXP43_NEW_HUC_AUTH_INOUT_PKT_SIZE (SZ_4K)"
> +
> + intel_gsc_uc_heci_cmd_emit_mtl_header(_in->header,
> + HECI_MEADDRESS_PXP,
> + sizeof(*msg_in), 0);
> +
> + msg_in->huc_in.header.api_version = PXP_APIVER(4, 3);
> + msg_in->huc_in.header.command_id = PXP43_CMDID_NEW_HUC_AUTH;
> + msg_in->huc_in.header.status = 0;
> + msg_in->huc_in.header.buffer_len = sizeof(msg_in->huc_in) -
> +
Re: [PATCH v3 3/7] drm/i915/huc: Load GSC-enabled HuC via DMA xfer if the fuse says so
On 5/30/2023 5:20 PM, John Harrison wrote:
On 5/30/2023 17:11, Ceraolo Spurio, Daniele wrote:
On 5/30/2023 4:51 PM, John Harrison wrote:
On 5/26/2023 17:52, Daniele Ceraolo Spurio wrote:
In the previous patch we extracted the offset of the legacy-style HuC
binary located within the GSC-enabled blob, so now we can use that to
load the HuC via DMA if the fuse is set that way.
Note that we now need to differentiate between "GSC-enabled binary"
and
"loaded by GSC", so the former case has been renamed to "has GSC
headers"
for clarity, while the latter is now based on the fuse instead of the
binary format. This way, all the legacy load paths are automatically
taken (including the auth by GuC) without having to implement further
code changes.
v2: s/is_meu_binary/has_gsc_headers/, clearer logs (John)
Signed-off-by: Daniele Ceraolo Spurio
Cc: Alan Previn
Cc: John Harrison
---
drivers/gpu/drm/i915/gt/uc/intel_huc.c | 29
++-
drivers/gpu/drm/i915/gt/uc/intel_huc.h | 4 +++-
drivers/gpu/drm/i915/gt/uc/intel_huc_fw.c | 2 +-
drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c | 12 +-
drivers/gpu/drm/i915/gt/uc/intel_uc_fw.h | 2 +-
5 files changed, 29 insertions(+), 20 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_huc.c
b/drivers/gpu/drm/i915/gt/uc/intel_huc.c
index 6d795438b3e4..37c6a8ca5c71 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_huc.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_huc.c
@@ -298,31 +298,38 @@ void intel_huc_init_early(struct intel_huc *huc)
static int check_huc_loading_mode(struct intel_huc *huc)
{
struct intel_gt *gt = huc_to_gt(huc);
- bool fw_needs_gsc = intel_huc_is_loaded_by_gsc(huc);
- bool hw_uses_gsc = false;
+ bool gsc_enabled = huc->fw.has_gsc_headers;
/*
* The fuse for HuC load via GSC is only valid on platforms
that have
* GuC deprivilege.
*/
if (HAS_GUC_DEPRIVILEGE(gt->i915))
- hw_uses_gsc = intel_uncore_read(gt->uncore,
GUC_SHIM_CONTROL2) &
- GSC_LOADS_HUC;
+ huc->loaded_via_gsc = intel_uncore_read(gt->uncore,
GUC_SHIM_CONTROL2) &
+ GSC_LOADS_HUC;
- if (fw_needs_gsc != hw_uses_gsc) {
- huc_err(huc, "mismatch between FW (%s) and HW (%s) load
modes\n",
- HUC_LOAD_MODE_STRING(fw_needs_gsc),
HUC_LOAD_MODE_STRING(hw_uses_gsc));
+ if (huc->loaded_via_gsc && !gsc_enabled) {
+ huc_err(huc, "HW requires a GSC-enabled blob, but we found
a legacy one\n");
return -ENOEXEC;
}
- /* make sure we can access the GSC via the mei driver if we
need it */
+ /*
+ * Newer GSC_enabled blobs contain the old FW structure
inside. If we
+ * found that, we can use it to load the legacy way.
+ */
+ if (!huc->loaded_via_gsc && gsc_enabled &&
!huc->fw.dma_start_offset) {
+ huc_err(huc,"HW in DMA mode, but we have an incompatible
GSC-enabled blob\n");
+ return -ENOEXEC;
+ }
The comment above doesn't seem to match the check. The comment says
'we can load the old way if possible' whereas the check is more 'can
we load the old way if we need to'.
I'll reword it.
+
+ /* make sure we can access the GSC if we need it */
if (!(IS_ENABLED(CONFIG_INTEL_MEI_PXP) &&
IS_ENABLED(CONFIG_INTEL_MEI_GSC)) &&
- fw_needs_gsc) {
- huc_info(huc, "can't load due to missing MEI modules\n");
+ !HAS_ENGINE(gt, GSC0) && huc->loaded_via_gsc) {
This test still looks wrong when you read it. I think it needs a
more detailed comment. Some kind of explanation that the modules
only apply to one platform and the engine to a different platform.
Or even breaking into two separate tests with an 'if(DG2)' between
them? It certainly confuses me every time I look at it.
Is it clearer if I split it like this?
/*
* if the FW is loaded via GSC and we're not on a platform that
* has the GSC CS, we need the mei modules to access the GSC.
*/
if (huc->loaded_via_gsc && !HAS_ENGINE(gt, GSC0)) {
if (!IS_ENABLED(MEI_PXP) || !IS_ENABLED(MEI_GSC)
// error
}
It is guaranteed that if the GSC engine is present then no modules are
required? And that if the GSC engine is not present, then the modules
are all that is required?
What happens if the GSC engine has been fused off? Or disabled by some
future module override, workaround, etc.?
I thinking it would be both clearer and safer to say 'if (DG2) {check
DG2 specific stuff} else {check other stuff}'.
ok, will do.
Daniele
John.
Daniele
John.
+ huc_info(huc, "can't load due to missing mei modules or
GSCCS\n");
return -EIO;
}
- huc_dbg(huc, "loaded by GSC = %s\n", str_yes_no(fw_needs_gsc));
+ huc_dbg(huc, "loaded by GSC = %s\n",
str_yes_no(huc->loaded_via_gsc));
return 0;
}
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_huc.h
b/drivers/gpu/drm/i915/gt/uc/intel_huc.h
index 0789184d81a2..112f0dce4702 100644
---
Re: [PATCH v4] drm/i915/huc: differentiate the 2 steps of the MTL HuC auth flow
On 5/30/2023 17:14, Ceraolo Spurio, Daniele wrote:
On 5/30/2023 5:01 PM, John Harrison wrote:
On 5/30/2023 08:29, Daniele Ceraolo Spurio wrote:
Before we add the second step of the MTL HuC auth (via GSC), we need to
have the ability to differentiate between them. To do so, the huc
authentication check is duplicated for GuC and GSC auth, with meu
meu?
leftover from the meu drop. Will reword.
binaries being considered fully authenticated only after the GSC auth
step.
To report the difference between the 2 auth steps, a new case is added
to the HuC getparam. This way, the clear media driver can start
submitting before full auth, as partial auth is enough for those
workloads.
v2: fix authentication status check for DG2
v3: add a better comment at the top of the HuC file to explain the
different approaches to load and auth (John)
v4: update call to intel_huc_is_authenticated in the pxp code to check
for GSC authentication
Signed-off-by: Daniele Ceraolo Spurio
Cc: Alan Previn
Cc: John Harrison
Reviewed-by: Alan Previn #v2
---
drivers/gpu/drm/i915/gt/uc/intel_huc.c | 111
-
drivers/gpu/drm/i915/gt/uc/intel_huc.h | 16 ++-
drivers/gpu/drm/i915/gt/uc/intel_huc_fw.c | 4 +-
drivers/gpu/drm/i915/i915_reg.h | 3 +
drivers/gpu/drm/i915/pxp/intel_pxp_gsccs.c | 2 +-
include/uapi/drm/i915_drm.h | 3 +-
6 files changed, 104 insertions(+), 35 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_huc.c
b/drivers/gpu/drm/i915/gt/uc/intel_huc.c
index 37c6a8ca5c71..ab5246ae3979 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_huc.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_huc.c
@@ -10,6 +10,7 @@
#include "intel_huc.h"
#include "intel_huc_print.h"
#include "i915_drv.h"
+#include "i915_reg.h"
#include
#include
@@ -22,15 +23,23 @@
* capabilities by adding HuC specific commands to batch buffers.
*
* The kernel driver is only responsible for loading the HuC
firmware and
- * triggering its security authentication, which is performed by
the GuC on
- * older platforms and by the GSC on newer ones. For the GuC to
correctly
- * perform the authentication, the HuC binary must be loaded before
the GuC one.
+ * triggering its security authentication. This is done differently
depending
+ * on the platform:
+ * - older platforms (from Gen9 to most Gen12s): the load is
performed via DMA
+ * and the authentication via GuC
+ * - DG2: load and authentication are both performed via GSC.
+ * - MTL and newer platforms: the load is performed via DMA (same
as with
+ * not-DG2 older platforms), while the authentication is done in
2-steps,
+ * a first auth for clear-media workloads via GuC and a second
one for all
+ * workloads via GSC.
+ * On platforms where the GuC does the authentication, to correctly
do so the
+ * HuC binary must be loaded before the GuC one.
* Loading the HuC is optional; however, not using the HuC might
negatively
* impact power usage and/or performance of media workloads,
depending on the
* use-cases.
* HuC must be reloaded on events that cause the WOPCM to lose its
contents
- * (S3/S4, FLR); GuC-authenticated HuC must also be reloaded on
GuC/GT reset,
- * while GSC-managed HuC will survive that.
+ * (S3/S4, FLR); on older platforms the HuC must also be reloaded
on GuC/GT
+ * reset, while on newer ones it will survive that.
*
* See https://github.com/intel/media-driver for the latest
details on HuC
* functionality.
@@ -106,7 +115,7 @@ static enum hrtimer_restart
huc_delayed_load_timer_callback(struct hrtimer *hrti
{
struct intel_huc *huc = container_of(hrtimer, struct
intel_huc, delayed_load.timer);
- if (!intel_huc_is_authenticated(huc)) {
+ if (!intel_huc_is_authenticated(huc, INTEL_HUC_AUTH_BY_GSC)) {
if (huc->delayed_load.status == INTEL_HUC_WAITING_ON_GSC)
huc_notice(huc, "timed out waiting for MEI GSC\n");
else if (huc->delayed_load.status ==
INTEL_HUC_WAITING_ON_PXP)
@@ -124,7 +133,7 @@ static void huc_delayed_load_start(struct
intel_huc *huc)
{
ktime_t delay;
- GEM_BUG_ON(intel_huc_is_authenticated(huc));
+ GEM_BUG_ON(intel_huc_is_authenticated(huc,
INTEL_HUC_AUTH_BY_GSC));
/*
* On resume we don't have to wait for MEI-GSC to be
re-probed, but we
@@ -284,13 +293,23 @@ void intel_huc_init_early(struct intel_huc *huc)
}
if (GRAPHICS_VER(i915) >= 11) {
- huc->status.reg = GEN11_HUC_KERNEL_LOAD_INFO;
- huc->status.mask = HUC_LOAD_SUCCESSFUL;
- huc->status.value = HUC_LOAD_SUCCESSFUL;
+ huc->status[INTEL_HUC_AUTH_BY_GUC].reg =
GEN11_HUC_KERNEL_LOAD_INFO;
+ huc->status[INTEL_HUC_AUTH_BY_GUC].mask = HUC_LOAD_SUCCESSFUL;
+ huc->status[INTEL_HUC_AUTH_BY_GUC].value =
HUC_LOAD_SUCCESSFUL;
} else {
- huc->status.reg = HUC_STATUS2;
- huc->status.mask = HUC_FW_VERIFIED;
-
Re: [PATCH v3 3/7] drm/i915/huc: Load GSC-enabled HuC via DMA xfer if the fuse says so
On 5/30/2023 17:11, Ceraolo Spurio, Daniele wrote:
On 5/30/2023 4:51 PM, John Harrison wrote:
On 5/26/2023 17:52, Daniele Ceraolo Spurio wrote:
In the previous patch we extracted the offset of the legacy-style HuC
binary located within the GSC-enabled blob, so now we can use that to
load the HuC via DMA if the fuse is set that way.
Note that we now need to differentiate between "GSC-enabled binary" and
"loaded by GSC", so the former case has been renamed to "has GSC
headers"
for clarity, while the latter is now based on the fuse instead of the
binary format. This way, all the legacy load paths are automatically
taken (including the auth by GuC) without having to implement further
code changes.
v2: s/is_meu_binary/has_gsc_headers/, clearer logs (John)
Signed-off-by: Daniele Ceraolo Spurio
Cc: Alan Previn
Cc: John Harrison
---
drivers/gpu/drm/i915/gt/uc/intel_huc.c | 29
++-
drivers/gpu/drm/i915/gt/uc/intel_huc.h | 4 +++-
drivers/gpu/drm/i915/gt/uc/intel_huc_fw.c | 2 +-
drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c | 12 +-
drivers/gpu/drm/i915/gt/uc/intel_uc_fw.h | 2 +-
5 files changed, 29 insertions(+), 20 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_huc.c
b/drivers/gpu/drm/i915/gt/uc/intel_huc.c
index 6d795438b3e4..37c6a8ca5c71 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_huc.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_huc.c
@@ -298,31 +298,38 @@ void intel_huc_init_early(struct intel_huc *huc)
static int check_huc_loading_mode(struct intel_huc *huc)
{
struct intel_gt *gt = huc_to_gt(huc);
- bool fw_needs_gsc = intel_huc_is_loaded_by_gsc(huc);
- bool hw_uses_gsc = false;
+ bool gsc_enabled = huc->fw.has_gsc_headers;
/*
* The fuse for HuC load via GSC is only valid on platforms
that have
* GuC deprivilege.
*/
if (HAS_GUC_DEPRIVILEGE(gt->i915))
- hw_uses_gsc = intel_uncore_read(gt->uncore,
GUC_SHIM_CONTROL2) &
- GSC_LOADS_HUC;
+ huc->loaded_via_gsc = intel_uncore_read(gt->uncore,
GUC_SHIM_CONTROL2) &
+ GSC_LOADS_HUC;
- if (fw_needs_gsc != hw_uses_gsc) {
- huc_err(huc, "mismatch between FW (%s) and HW (%s) load
modes\n",
- HUC_LOAD_MODE_STRING(fw_needs_gsc),
HUC_LOAD_MODE_STRING(hw_uses_gsc));
+ if (huc->loaded_via_gsc && !gsc_enabled) {
+ huc_err(huc, "HW requires a GSC-enabled blob, but we found
a legacy one\n");
return -ENOEXEC;
}
- /* make sure we can access the GSC via the mei driver if we
need it */
+ /*
+ * Newer GSC_enabled blobs contain the old FW structure inside.
If we
+ * found that, we can use it to load the legacy way.
+ */
+ if (!huc->loaded_via_gsc && gsc_enabled &&
!huc->fw.dma_start_offset) {
+ huc_err(huc,"HW in DMA mode, but we have an incompatible
GSC-enabled blob\n");
+ return -ENOEXEC;
+ }
The comment above doesn't seem to match the check. The comment says
'we can load the old way if possible' whereas the check is more 'can
we load the old way if we need to'.
I'll reword it.
+
+ /* make sure we can access the GSC if we need it */
if (!(IS_ENABLED(CONFIG_INTEL_MEI_PXP) &&
IS_ENABLED(CONFIG_INTEL_MEI_GSC)) &&
- fw_needs_gsc) {
- huc_info(huc, "can't load due to missing MEI modules\n");
+ !HAS_ENGINE(gt, GSC0) && huc->loaded_via_gsc) {
This test still looks wrong when you read it. I think it needs a more
detailed comment. Some kind of explanation that the modules only
apply to one platform and the engine to a different platform. Or even
breaking into two separate tests with an 'if(DG2)' between them? It
certainly confuses me every time I look at it.
Is it clearer if I split it like this?
/*
* if the FW is loaded via GSC and we're not on a platform that
* has the GSC CS, we need the mei modules to access the GSC.
*/
if (huc->loaded_via_gsc && !HAS_ENGINE(gt, GSC0)) {
if (!IS_ENABLED(MEI_PXP) || !IS_ENABLED(MEI_GSC)
// error
}
It is guaranteed that if the GSC engine is present then no modules are
required? And that if the GSC engine is not present, then the modules
are all that is required?
What happens if the GSC engine has been fused off? Or disabled by some
future module override, workaround, etc.?
I thinking it would be both clearer and safer to say 'if (DG2) {check
DG2 specific stuff} else {check other stuff}'.
John.
Daniele
John.
+ huc_info(huc, "can't load due to missing mei modules or
GSCCS\n");
return -EIO;
}
- huc_dbg(huc, "loaded by GSC = %s\n", str_yes_no(fw_needs_gsc));
+ huc_dbg(huc, "loaded by GSC = %s\n",
str_yes_no(huc->loaded_via_gsc));
return 0;
}
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_huc.h
b/drivers/gpu/drm/i915/gt/uc/intel_huc.h
index 0789184d81a2..112f0dce4702 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_huc.h
+++
Re: [PATCH v4] drm/i915/huc: differentiate the 2 steps of the MTL HuC auth flow
On 5/30/2023 5:01 PM, John Harrison wrote:
On 5/30/2023 08:29, Daniele Ceraolo Spurio wrote:
Before we add the second step of the MTL HuC auth (via GSC), we need to
have the ability to differentiate between them. To do so, the huc
authentication check is duplicated for GuC and GSC auth, with meu
meu?
leftover from the meu drop. Will reword.
binaries being considered fully authenticated only after the GSC auth
step.
To report the difference between the 2 auth steps, a new case is added
to the HuC getparam. This way, the clear media driver can start
submitting before full auth, as partial auth is enough for those
workloads.
v2: fix authentication status check for DG2
v3: add a better comment at the top of the HuC file to explain the
different approaches to load and auth (John)
v4: update call to intel_huc_is_authenticated in the pxp code to check
for GSC authentication
Signed-off-by: Daniele Ceraolo Spurio
Cc: Alan Previn
Cc: John Harrison
Reviewed-by: Alan Previn #v2
---
drivers/gpu/drm/i915/gt/uc/intel_huc.c | 111 -
drivers/gpu/drm/i915/gt/uc/intel_huc.h | 16 ++-
drivers/gpu/drm/i915/gt/uc/intel_huc_fw.c | 4 +-
drivers/gpu/drm/i915/i915_reg.h | 3 +
drivers/gpu/drm/i915/pxp/intel_pxp_gsccs.c | 2 +-
include/uapi/drm/i915_drm.h | 3 +-
6 files changed, 104 insertions(+), 35 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_huc.c
b/drivers/gpu/drm/i915/gt/uc/intel_huc.c
index 37c6a8ca5c71..ab5246ae3979 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_huc.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_huc.c
@@ -10,6 +10,7 @@
#include "intel_huc.h"
#include "intel_huc_print.h"
#include "i915_drv.h"
+#include "i915_reg.h"
#include
#include
@@ -22,15 +23,23 @@
* capabilities by adding HuC specific commands to batch buffers.
*
* The kernel driver is only responsible for loading the HuC
firmware and
- * triggering its security authentication, which is performed by the
GuC on
- * older platforms and by the GSC on newer ones. For the GuC to
correctly
- * perform the authentication, the HuC binary must be loaded before
the GuC one.
+ * triggering its security authentication. This is done differently
depending
+ * on the platform:
+ * - older platforms (from Gen9 to most Gen12s): the load is
performed via DMA
+ * and the authentication via GuC
+ * - DG2: load and authentication are both performed via GSC.
+ * - MTL and newer platforms: the load is performed via DMA (same as
with
+ * not-DG2 older platforms), while the authentication is done in
2-steps,
+ * a first auth for clear-media workloads via GuC and a second one
for all
+ * workloads via GSC.
+ * On platforms where the GuC does the authentication, to correctly
do so the
+ * HuC binary must be loaded before the GuC one.
* Loading the HuC is optional; however, not using the HuC might
negatively
* impact power usage and/or performance of media workloads,
depending on the
* use-cases.
* HuC must be reloaded on events that cause the WOPCM to lose its
contents
- * (S3/S4, FLR); GuC-authenticated HuC must also be reloaded on
GuC/GT reset,
- * while GSC-managed HuC will survive that.
+ * (S3/S4, FLR); on older platforms the HuC must also be reloaded on
GuC/GT
+ * reset, while on newer ones it will survive that.
*
* See https://github.com/intel/media-driver for the latest details
on HuC
* functionality.
@@ -106,7 +115,7 @@ static enum hrtimer_restart
huc_delayed_load_timer_callback(struct hrtimer *hrti
{
struct intel_huc *huc = container_of(hrtimer, struct intel_huc,
delayed_load.timer);
- if (!intel_huc_is_authenticated(huc)) {
+ if (!intel_huc_is_authenticated(huc, INTEL_HUC_AUTH_BY_GSC)) {
if (huc->delayed_load.status == INTEL_HUC_WAITING_ON_GSC)
huc_notice(huc, "timed out waiting for MEI GSC\n");
else if (huc->delayed_load.status == INTEL_HUC_WAITING_ON_PXP)
@@ -124,7 +133,7 @@ static void huc_delayed_load_start(struct
intel_huc *huc)
{
ktime_t delay;
- GEM_BUG_ON(intel_huc_is_authenticated(huc));
+ GEM_BUG_ON(intel_huc_is_authenticated(huc, INTEL_HUC_AUTH_BY_GSC));
/*
* On resume we don't have to wait for MEI-GSC to be re-probed,
but we
@@ -284,13 +293,23 @@ void intel_huc_init_early(struct intel_huc *huc)
}
if (GRAPHICS_VER(i915) >= 11) {
- huc->status.reg = GEN11_HUC_KERNEL_LOAD_INFO;
- huc->status.mask = HUC_LOAD_SUCCESSFUL;
- huc->status.value = HUC_LOAD_SUCCESSFUL;
+ huc->status[INTEL_HUC_AUTH_BY_GUC].reg =
GEN11_HUC_KERNEL_LOAD_INFO;
+ huc->status[INTEL_HUC_AUTH_BY_GUC].mask = HUC_LOAD_SUCCESSFUL;
+ huc->status[INTEL_HUC_AUTH_BY_GUC].value = HUC_LOAD_SUCCESSFUL;
} else {
- huc->status.reg = HUC_STATUS2;
- huc->status.mask = HUC_FW_VERIFIED;
- huc->status.value = HUC_FW_VERIFIED;
+
Re: [PATCH v3 3/7] drm/i915/huc: Load GSC-enabled HuC via DMA xfer if the fuse says so
On 5/30/2023 4:51 PM, John Harrison wrote:
On 5/26/2023 17:52, Daniele Ceraolo Spurio wrote:
In the previous patch we extracted the offset of the legacy-style HuC
binary located within the GSC-enabled blob, so now we can use that to
load the HuC via DMA if the fuse is set that way.
Note that we now need to differentiate between "GSC-enabled binary" and
"loaded by GSC", so the former case has been renamed to "has GSC
headers"
for clarity, while the latter is now based on the fuse instead of the
binary format. This way, all the legacy load paths are automatically
taken (including the auth by GuC) without having to implement further
code changes.
v2: s/is_meu_binary/has_gsc_headers/, clearer logs (John)
Signed-off-by: Daniele Ceraolo Spurio
Cc: Alan Previn
Cc: John Harrison
---
drivers/gpu/drm/i915/gt/uc/intel_huc.c | 29 ++-
drivers/gpu/drm/i915/gt/uc/intel_huc.h | 4 +++-
drivers/gpu/drm/i915/gt/uc/intel_huc_fw.c | 2 +-
drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c | 12 +-
drivers/gpu/drm/i915/gt/uc/intel_uc_fw.h | 2 +-
5 files changed, 29 insertions(+), 20 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_huc.c
b/drivers/gpu/drm/i915/gt/uc/intel_huc.c
index 6d795438b3e4..37c6a8ca5c71 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_huc.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_huc.c
@@ -298,31 +298,38 @@ void intel_huc_init_early(struct intel_huc *huc)
static int check_huc_loading_mode(struct intel_huc *huc)
{
struct intel_gt *gt = huc_to_gt(huc);
- bool fw_needs_gsc = intel_huc_is_loaded_by_gsc(huc);
- bool hw_uses_gsc = false;
+ bool gsc_enabled = huc->fw.has_gsc_headers;
/*
* The fuse for HuC load via GSC is only valid on platforms
that have
* GuC deprivilege.
*/
if (HAS_GUC_DEPRIVILEGE(gt->i915))
- hw_uses_gsc = intel_uncore_read(gt->uncore,
GUC_SHIM_CONTROL2) &
- GSC_LOADS_HUC;
+ huc->loaded_via_gsc = intel_uncore_read(gt->uncore,
GUC_SHIM_CONTROL2) &
+ GSC_LOADS_HUC;
- if (fw_needs_gsc != hw_uses_gsc) {
- huc_err(huc, "mismatch between FW (%s) and HW (%s) load
modes\n",
- HUC_LOAD_MODE_STRING(fw_needs_gsc),
HUC_LOAD_MODE_STRING(hw_uses_gsc));
+ if (huc->loaded_via_gsc && !gsc_enabled) {
+ huc_err(huc, "HW requires a GSC-enabled blob, but we found a
legacy one\n");
return -ENOEXEC;
}
- /* make sure we can access the GSC via the mei driver if we
need it */
+ /*
+ * Newer GSC_enabled blobs contain the old FW structure inside.
If we
+ * found that, we can use it to load the legacy way.
+ */
+ if (!huc->loaded_via_gsc && gsc_enabled &&
!huc->fw.dma_start_offset) {
+ huc_err(huc,"HW in DMA mode, but we have an incompatible
GSC-enabled blob\n");
+ return -ENOEXEC;
+ }
The comment above doesn't seem to match the check. The comment says
'we can load the old way if possible' whereas the check is more 'can
we load the old way if we need to'.
I'll reword it.
+
+ /* make sure we can access the GSC if we need it */
if (!(IS_ENABLED(CONFIG_INTEL_MEI_PXP) &&
IS_ENABLED(CONFIG_INTEL_MEI_GSC)) &&
- fw_needs_gsc) {
- huc_info(huc, "can't load due to missing MEI modules\n");
+ !HAS_ENGINE(gt, GSC0) && huc->loaded_via_gsc) {
This test still looks wrong when you read it. I think it needs a more
detailed comment. Some kind of explanation that the modules only apply
to one platform and the engine to a different platform. Or even
breaking into two separate tests with an 'if(DG2)' between them? It
certainly confuses me every time I look at it.
Is it clearer if I split it like this?
/*
* if the FW is loaded via GSC and we're not on a platform that
* has the GSC CS, we need the mei modules to access the GSC.
*/
if (huc->loaded_via_gsc && !HAS_ENGINE(gt, GSC0)) {
if (!IS_ENABLED(MEI_PXP) || !IS_ENABLED(MEI_GSC)
// error
}
Daniele
John.
+ huc_info(huc, "can't load due to missing mei modules or
GSCCS\n");
return -EIO;
}
- huc_dbg(huc, "loaded by GSC = %s\n", str_yes_no(fw_needs_gsc));
+ huc_dbg(huc, "loaded by GSC = %s\n",
str_yes_no(huc->loaded_via_gsc));
return 0;
}
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_huc.h
b/drivers/gpu/drm/i915/gt/uc/intel_huc.h
index 0789184d81a2..112f0dce4702 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_huc.h
+++ b/drivers/gpu/drm/i915/gt/uc/intel_huc.h
@@ -39,6 +39,8 @@ struct intel_huc {
struct notifier_block nb;
enum intel_huc_delayed_load_status status;
} delayed_load;
+
+ bool loaded_via_gsc;
};
int intel_huc_sanitize(struct intel_huc *huc);
@@ -73,7 +75,7 @@ static inline bool intel_huc_is_used(struct
intel_huc *huc)
static inline bool intel_huc_is_loaded_by_gsc(const struct
intel_huc *huc)
{
- return huc->fw.loaded_via_gsc;
+ return
Re: [PATCH v3 2/7] drm/i915/huc: Parse the GSC-enabled HuC binary
On 5/30/2023 17:06, Ceraolo Spurio, Daniele wrote:
On 5/30/2023 4:30 PM, John Harrison wrote:
On 5/26/2023 17:52, Daniele Ceraolo Spurio wrote:
The new binaries that support the 2-step authentication contain the
legacy-style binary, which we can use for loading the HuC via DMA. To
find out where this is located in the image, we need to parse the
manifest of the GSC-enabled HuC binary. The manifest consist of a
partition header followed by entries, one of which contains the offset
we're looking for.
Note that the DG2 GSC binary contains entries with the same names, but
it doesn't contain a full legacy binary, so we need to skip assigning
the dma offset in that case (which we can do by checking the ccs).
Also, since we're now parsing the entries, we can extract the HuC
version that way instead of using hardcoded offsets.
Note that the GSC binary uses the same structures in its binary header,
so they've been added in their own header file.
v2: fix structure names to match meu defines (s/CPT/CPD/), update
commit
message, check ccs validity, drop old version location defines.
v3: drop references to the MEU tool to reduce confusion, fix log (John)
Signed-off-by: Daniele Ceraolo Spurio
Cc: Alan Previn
Cc: John Harrison
Reviewed-by: Alan Previn #v2
---
.../drm/i915/gt/uc/intel_gsc_binary_headers.h | 74 ++
drivers/gpu/drm/i915/gt/uc/intel_huc.c | 11 +-
drivers/gpu/drm/i915/gt/uc/intel_huc_fw.c | 135
++
drivers/gpu/drm/i915/gt/uc/intel_huc_fw.h | 5 +-
drivers/gpu/drm/i915/gt/uc/intel_huc_print.h | 21 +++
drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c | 71 +
drivers/gpu/drm/i915/gt/uc/intel_uc_fw.h | 2 +
drivers/gpu/drm/i915/gt/uc/intel_uc_fw_abi.h | 6 -
8 files changed, 272 insertions(+), 53 deletions(-)
create mode 100644
drivers/gpu/drm/i915/gt/uc/intel_gsc_binary_headers.h
create mode 100644 drivers/gpu/drm/i915/gt/uc/intel_huc_print.h
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_gsc_binary_headers.h
b/drivers/gpu/drm/i915/gt/uc/intel_gsc_binary_headers.h
new file mode 100644
index ..714f0c256118
--- /dev/null
+++ b/drivers/gpu/drm/i915/gt/uc/intel_gsc_binary_headers.h
@@ -0,0 +1,74 @@
+/* SPDX-License-Identifier: MIT */
+/*
+ * Copyright © 2023 Intel Corporation
+ */
+
+#ifndef _INTEL_GSC_BINARY_HEADERS_H_
+#define _INTEL_GSC_BINARY_HEADERS_H_
+
+#include
+
+/* Code partition directory (CPD) structures */
+struct intel_gsc_cpd_header_v2 {
+ u32 header_marker;
+#define INTEL_GSC_CPD_HEADER_MARKER 0x44504324
+
+ u32 num_of_entries;
+ u8 header_version;
+ u8 entry_version;
+ u8 header_length; /* in bytes */
+ u8 flags;
+ u32 partition_name;
+ u32 crc32;
+} __packed;
+
+struct intel_gsc_cpd_entry {
+ u8 name[12];
+
+ /*
+ * Bits 0-24: offset from the beginning of the code partition
+ * Bit 25: huffman compressed
+ * Bits 26-31: reserved
+ */
+ u32 offset;
+#define INTEL_GSC_CPD_ENTRY_OFFSET_MASK GENMASK(24, 0)
+#define INTEL_GSC_CPD_ENTRY_HUFFMAN_COMP BIT(25)
+
+ /*
+ * Module/Item length, in bytes. For Huffman-compressed
modules, this
+ * refers to the uncompressed size. For software-compressed
modules,
+ * this refers to the compressed size.
+ */
+ u32 length;
+
+ u8 reserved[4];
+} __packed;
+
+struct intel_gsc_version {
+ u16 major;
+ u16 minor;
+ u16 hotfix;
+ u16 build;
+} __packed;
+
+struct intel_gsc_manifest_header {
+ u32 header_type; /* 0x4 for manifest type */
+ u32 header_length; /* in dwords */
+ u32 header_version;
+ u32 flags;
+ u32 vendor;
+ u32 date;
+ u32 size; /* In dwords, size of entire manifest (header +
extensions) */
+ u32 header_id;
+ u32 internal_data;
+ struct intel_gsc_version fw_version;
+ u32 security_version;
+ struct intel_gsc_version meu_kit_version;
+ u32 meu_manifest_version;
+ u8 general_data[4];
+ u8 reserved3[56];
+ u32 modulus_size; /* in dwords */
+ u32 exponent_size; /* in dwords */
+} __packed;
+
+#endif
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_huc.c
b/drivers/gpu/drm/i915/gt/uc/intel_huc.c
index 268e036f8f28..6d795438b3e4 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_huc.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_huc.c
@@ -6,23 +6,14 @@
#include
#include "gt/intel_gt.h"
-#include "gt/intel_gt_print.h"
#include "intel_guc_reg.h"
#include "intel_huc.h"
+#include "intel_huc_print.h"
#include "i915_drv.h"
#include
#include
-#define huc_printk(_huc, _level, _fmt, ...) \
- gt_##_level(huc_to_gt(_huc), "HuC: " _fmt, ##__VA_ARGS__)
-#define huc_err(_huc, _fmt, ...) huc_printk((_huc), err, _fmt,
##__VA_ARGS__)
-#define huc_warn(_huc, _fmt, ...) huc_printk((_huc), warn, _fmt,
##__VA_ARGS__)
-#define huc_notice(_huc, _fmt, ...) huc_printk((_huc), notice,
_fmt, ##__VA_ARGS__)
-#define huc_info(_huc, _fmt, ...) huc_printk((_huc), info, _fmt,
##__VA_ARGS__)
-#define
Re: [PATCH v3 2/7] drm/i915/huc: Parse the GSC-enabled HuC binary
On 5/30/2023 4:30 PM, John Harrison wrote:
On 5/26/2023 17:52, Daniele Ceraolo Spurio wrote:
The new binaries that support the 2-step authentication contain the
legacy-style binary, which we can use for loading the HuC via DMA. To
find out where this is located in the image, we need to parse the
manifest of the GSC-enabled HuC binary. The manifest consist of a
partition header followed by entries, one of which contains the offset
we're looking for.
Note that the DG2 GSC binary contains entries with the same names, but
it doesn't contain a full legacy binary, so we need to skip assigning
the dma offset in that case (which we can do by checking the ccs).
Also, since we're now parsing the entries, we can extract the HuC
version that way instead of using hardcoded offsets.
Note that the GSC binary uses the same structures in its binary header,
so they've been added in their own header file.
v2: fix structure names to match meu defines (s/CPT/CPD/), update commit
message, check ccs validity, drop old version location defines.
v3: drop references to the MEU tool to reduce confusion, fix log (John)
Signed-off-by: Daniele Ceraolo Spurio
Cc: Alan Previn
Cc: John Harrison
Reviewed-by: Alan Previn #v2
---
.../drm/i915/gt/uc/intel_gsc_binary_headers.h | 74 ++
drivers/gpu/drm/i915/gt/uc/intel_huc.c | 11 +-
drivers/gpu/drm/i915/gt/uc/intel_huc_fw.c | 135 ++
drivers/gpu/drm/i915/gt/uc/intel_huc_fw.h | 5 +-
drivers/gpu/drm/i915/gt/uc/intel_huc_print.h | 21 +++
drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c | 71 +
drivers/gpu/drm/i915/gt/uc/intel_uc_fw.h | 2 +
drivers/gpu/drm/i915/gt/uc/intel_uc_fw_abi.h | 6 -
8 files changed, 272 insertions(+), 53 deletions(-)
create mode 100644
drivers/gpu/drm/i915/gt/uc/intel_gsc_binary_headers.h
create mode 100644 drivers/gpu/drm/i915/gt/uc/intel_huc_print.h
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_gsc_binary_headers.h
b/drivers/gpu/drm/i915/gt/uc/intel_gsc_binary_headers.h
new file mode 100644
index ..714f0c256118
--- /dev/null
+++ b/drivers/gpu/drm/i915/gt/uc/intel_gsc_binary_headers.h
@@ -0,0 +1,74 @@
+/* SPDX-License-Identifier: MIT */
+/*
+ * Copyright © 2023 Intel Corporation
+ */
+
+#ifndef _INTEL_GSC_BINARY_HEADERS_H_
+#define _INTEL_GSC_BINARY_HEADERS_H_
+
+#include
+
+/* Code partition directory (CPD) structures */
+struct intel_gsc_cpd_header_v2 {
+ u32 header_marker;
+#define INTEL_GSC_CPD_HEADER_MARKER 0x44504324
+
+ u32 num_of_entries;
+ u8 header_version;
+ u8 entry_version;
+ u8 header_length; /* in bytes */
+ u8 flags;
+ u32 partition_name;
+ u32 crc32;
+} __packed;
+
+struct intel_gsc_cpd_entry {
+ u8 name[12];
+
+ /*
+ * Bits 0-24: offset from the beginning of the code partition
+ * Bit 25: huffman compressed
+ * Bits 26-31: reserved
+ */
+ u32 offset;
+#define INTEL_GSC_CPD_ENTRY_OFFSET_MASK GENMASK(24, 0)
+#define INTEL_GSC_CPD_ENTRY_HUFFMAN_COMP BIT(25)
+
+ /*
+ * Module/Item length, in bytes. For Huffman-compressed modules,
this
+ * refers to the uncompressed size. For software-compressed
modules,
+ * this refers to the compressed size.
+ */
+ u32 length;
+
+ u8 reserved[4];
+} __packed;
+
+struct intel_gsc_version {
+ u16 major;
+ u16 minor;
+ u16 hotfix;
+ u16 build;
+} __packed;
+
+struct intel_gsc_manifest_header {
+ u32 header_type; /* 0x4 for manifest type */
+ u32 header_length; /* in dwords */
+ u32 header_version;
+ u32 flags;
+ u32 vendor;
+ u32 date;
+ u32 size; /* In dwords, size of entire manifest (header +
extensions) */
+ u32 header_id;
+ u32 internal_data;
+ struct intel_gsc_version fw_version;
+ u32 security_version;
+ struct intel_gsc_version meu_kit_version;
+ u32 meu_manifest_version;
+ u8 general_data[4];
+ u8 reserved3[56];
+ u32 modulus_size; /* in dwords */
+ u32 exponent_size; /* in dwords */
+} __packed;
+
+#endif
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_huc.c
b/drivers/gpu/drm/i915/gt/uc/intel_huc.c
index 268e036f8f28..6d795438b3e4 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_huc.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_huc.c
@@ -6,23 +6,14 @@
#include
#include "gt/intel_gt.h"
-#include "gt/intel_gt_print.h"
#include "intel_guc_reg.h"
#include "intel_huc.h"
+#include "intel_huc_print.h"
#include "i915_drv.h"
#include
#include
-#define huc_printk(_huc, _level, _fmt, ...) \
- gt_##_level(huc_to_gt(_huc), "HuC: " _fmt, ##__VA_ARGS__)
-#define huc_err(_huc, _fmt, ...) huc_printk((_huc), err, _fmt,
##__VA_ARGS__)
-#define huc_warn(_huc, _fmt, ...) huc_printk((_huc), warn, _fmt,
##__VA_ARGS__)
-#define huc_notice(_huc, _fmt, ...) huc_printk((_huc), notice,
_fmt, ##__VA_ARGS__)
-#define huc_info(_huc, _fmt, ...) huc_printk((_huc), info, _fmt,
##__VA_ARGS__)
-#define huc_dbg(_huc, _fmt, ...) huc_printk((_huc), dbg, _fmt,
[PATCH v3 2/3] drm/bridge: display-connector: rename dp_pwr to connector_pwr
In preparation to adding support for the hdmi_pwr supply, rename dp_pwr
structure field to the generic connector_pwr.
Reviewed-by: Laurent Pinchart
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/bridge/display-connector.c | 18 +-
1 file changed, 9 insertions(+), 9 deletions(-)
diff --git a/drivers/gpu/drm/bridge/display-connector.c
b/drivers/gpu/drm/bridge/display-connector.c
index 56ae511367b1..cad3105ab186 100644
--- a/drivers/gpu/drm/bridge/display-connector.c
+++ b/drivers/gpu/drm/bridge/display-connector.c
@@ -24,7 +24,7 @@ struct display_connector {
struct gpio_desc*hpd_gpio;
int hpd_irq;
- struct regulator*dp_pwr;
+ struct regulator*supply;
struct gpio_desc*ddc_en;
};
@@ -316,14 +316,14 @@ static int display_connector_probe(struct platform_device
*pdev)
if (type == DRM_MODE_CONNECTOR_DisplayPort) {
int ret;
- conn->dp_pwr = devm_regulator_get_optional(>dev,
"dp-pwr");
+ conn->supply = devm_regulator_get_optional(>dev,
"dp-pwr");
- if (IS_ERR(conn->dp_pwr)) {
- ret = PTR_ERR(conn->dp_pwr);
+ if (IS_ERR(conn->supply)) {
+ ret = PTR_ERR(conn->supply);
switch (ret) {
case -ENODEV:
- conn->dp_pwr = NULL;
+ conn->supply = NULL;
break;
case -EPROBE_DEFER:
@@ -335,8 +335,8 @@ static int display_connector_probe(struct platform_device
*pdev)
}
}
- if (conn->dp_pwr) {
- ret = regulator_enable(conn->dp_pwr);
+ if (conn->supply) {
+ ret = regulator_enable(conn->supply);
if (ret) {
dev_err(>dev, "failed to enable DP PWR
regulator: %d\n", ret);
return ret;
@@ -386,8 +386,8 @@ static void display_connector_remove(struct platform_device
*pdev)
if (conn->ddc_en)
gpiod_set_value(conn->ddc_en, 0);
- if (conn->dp_pwr)
- regulator_disable(conn->dp_pwr);
+ if (conn->supply)
+ regulator_disable(conn->supply);
drm_bridge_remove(>bridge);
--
2.39.2
[PATCH v3 3/3] drm/bridge: display-connector: handle hdmi-pwr supply
On some devices the +5V Power pin of the HDMI connector and/or the ESD
protection logic is powered on by a separate regulator. Instead of
declaring this regulator as always-on, make hdmi-connector support the
additional hdmi-pwr supply.
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/bridge/display-connector.c | 55 --
1 file changed, 29 insertions(+), 26 deletions(-)
diff --git a/drivers/gpu/drm/bridge/display-connector.c
b/drivers/gpu/drm/bridge/display-connector.c
index cad3105ab186..f7f436cf96e0 100644
--- a/drivers/gpu/drm/bridge/display-connector.c
+++ b/drivers/gpu/drm/bridge/display-connector.c
@@ -191,6 +191,18 @@ static irqreturn_t display_connector_hpd_irq(int irq, void
*arg)
return IRQ_HANDLED;
}
+static int display_connector_get_supply(struct platform_device *pdev,
+ struct display_connector *conn,
+ const char *name)
+{
+ conn->supply = devm_regulator_get_optional(>dev, name);
+
+ if (conn->supply == ERR_PTR(-ENODEV))
+ conn->supply = NULL;
+
+ return PTR_ERR_OR_ZERO(conn->supply);
+}
+
static int display_connector_probe(struct platform_device *pdev)
{
struct display_connector *conn;
@@ -316,36 +328,15 @@ static int display_connector_probe(struct platform_device
*pdev)
if (type == DRM_MODE_CONNECTOR_DisplayPort) {
int ret;
- conn->supply = devm_regulator_get_optional(>dev,
"dp-pwr");
-
- if (IS_ERR(conn->supply)) {
- ret = PTR_ERR(conn->supply);
-
- switch (ret) {
- case -ENODEV:
- conn->supply = NULL;
- break;
-
- case -EPROBE_DEFER:
- return -EPROBE_DEFER;
-
- default:
- dev_err(>dev, "failed to get DP PWR
regulator: %d\n", ret);
- return ret;
- }
- }
-
- if (conn->supply) {
- ret = regulator_enable(conn->supply);
- if (ret) {
- dev_err(>dev, "failed to enable DP PWR
regulator: %d\n", ret);
- return ret;
- }
- }
+ ret = display_connector_get_supply(pdev, conn, "dp-pwr");
+ if (ret < 0)
+ return dev_err_probe(>dev, ret, "failed to get DP
PWR regulator\n");
}
/* enable DDC */
if (type == DRM_MODE_CONNECTOR_HDMIA) {
+ int ret;
+
conn->ddc_en = devm_gpiod_get_optional(>dev, "ddc-en",
GPIOD_OUT_HIGH);
@@ -353,6 +344,18 @@ static int display_connector_probe(struct platform_device
*pdev)
dev_err(>dev, "Couldn't get ddc-en gpio\n");
return PTR_ERR(conn->ddc_en);
}
+
+ ret = display_connector_get_supply(pdev, conn, "hdmi-pwr");
+ if (ret < 0)
+ return dev_err_probe(>dev, ret, "failed to get
HDMI +5V Power regulator\n");
+ }
+
+ if (conn->supply) {
+ ret = regulator_enable(conn->supply);
+ if (ret) {
+ dev_err(>dev, "failed to enable PWR regulator:
%d\n", ret);
+ return ret;
+ }
}
conn->bridge.funcs = _connector_bridge_funcs;
--
2.39.2
[PATCH v3 1/3] dt-bindings: display: hdmi-connector: add hdmi-pwr supply
Follow the dp-connector example and add hdmi-pwr supply to drive the 5V pin of the HDMI connector (together with some simple glue logic possibly attached to the connector). Reviewed-by: Laurent Pinchart Acked-by: Krzysztof Kozlowski Signed-off-by: Dmitry Baryshkov --- .../devicetree/bindings/display/connector/hdmi-connector.yaml | 3 +++ 1 file changed, 3 insertions(+) diff --git a/Documentation/devicetree/bindings/display/connector/hdmi-connector.yaml b/Documentation/devicetree/bindings/display/connector/hdmi-connector.yaml index 83c0d008265b..3ee8f9225984 100644 --- a/Documentation/devicetree/bindings/display/connector/hdmi-connector.yaml +++ b/Documentation/devicetree/bindings/display/connector/hdmi-connector.yaml @@ -36,6 +36,9 @@ properties: description: GPIO signal to enable DDC bus maxItems: 1 + hdmi-pwr-supply: +description: Power supply for the HDMI +5V Power pin + port: $ref: /schemas/graph.yaml#/properties/port description: Connection to controller providing HDMI signals -- 2.39.2
[PATCH v3 0/3] drm/bridge: display-connector: add external supply support
On some devices the 5V pin of the HDMI connector and/or the ESD protection logic is powered on by a separate regulator. The dp-connector for such usecases provides dp-pwr supply support. Follow this example and make hdmi-connector support the hdmi-pwr supply. Changes since v2: - Changed to use proper supply name instead of hardcoded "dp-pwr" (Neil) Changes since v1: - Changed the pin description to HDMI +5V Power - Renamed 'connector_pwr' to simpler 'supply' - Extracted the common supply-handling code for DP and HDMI Dmitry Baryshkov (3): dt-bindings: display: hdmi-connector: add hdmi-pwr supply drm/bridge: display-connector: rename dp_pwr to connector_pwr drm/bridge: display-connector: handle hdmi-pwr supply .../display/connector/hdmi-connector.yaml | 3 + drivers/gpu/drm/bridge/display-connector.c| 61 ++- 2 files changed, 35 insertions(+), 29 deletions(-) -- 2.39.2
Re: [PATCH v4] drm/i915/huc: differentiate the 2 steps of the MTL HuC auth flow
On 5/30/2023 08:29, Daniele Ceraolo Spurio wrote:
Before we add the second step of the MTL HuC auth (via GSC), we need to
have the ability to differentiate between them. To do so, the huc
authentication check is duplicated for GuC and GSC auth, with meu
meu?
binaries being considered fully authenticated only after the GSC auth
step.
To report the difference between the 2 auth steps, a new case is added
to the HuC getparam. This way, the clear media driver can start
submitting before full auth, as partial auth is enough for those
workloads.
v2: fix authentication status check for DG2
v3: add a better comment at the top of the HuC file to explain the
different approaches to load and auth (John)
v4: update call to intel_huc_is_authenticated in the pxp code to check
for GSC authentication
Signed-off-by: Daniele Ceraolo Spurio
Cc: Alan Previn
Cc: John Harrison
Reviewed-by: Alan Previn #v2
---
drivers/gpu/drm/i915/gt/uc/intel_huc.c | 111 -
drivers/gpu/drm/i915/gt/uc/intel_huc.h | 16 ++-
drivers/gpu/drm/i915/gt/uc/intel_huc_fw.c | 4 +-
drivers/gpu/drm/i915/i915_reg.h| 3 +
drivers/gpu/drm/i915/pxp/intel_pxp_gsccs.c | 2 +-
include/uapi/drm/i915_drm.h| 3 +-
6 files changed, 104 insertions(+), 35 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_huc.c
b/drivers/gpu/drm/i915/gt/uc/intel_huc.c
index 37c6a8ca5c71..ab5246ae3979 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_huc.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_huc.c
@@ -10,6 +10,7 @@
#include "intel_huc.h"
#include "intel_huc_print.h"
#include "i915_drv.h"
+#include "i915_reg.h"
#include
#include
@@ -22,15 +23,23 @@
* capabilities by adding HuC specific commands to batch buffers.
*
* The kernel driver is only responsible for loading the HuC firmware and
- * triggering its security authentication, which is performed by the GuC on
- * older platforms and by the GSC on newer ones. For the GuC to correctly
- * perform the authentication, the HuC binary must be loaded before the GuC
one.
+ * triggering its security authentication. This is done differently depending
+ * on the platform:
+ * - older platforms (from Gen9 to most Gen12s): the load is performed via DMA
+ * and the authentication via GuC
+ * - DG2: load and authentication are both performed via GSC.
+ * - MTL and newer platforms: the load is performed via DMA (same as with
+ * not-DG2 older platforms), while the authentication is done in 2-steps,
+ * a first auth for clear-media workloads via GuC and a second one for all
+ * workloads via GSC.
+ * On platforms where the GuC does the authentication, to correctly do so the
+ * HuC binary must be loaded before the GuC one.
* Loading the HuC is optional; however, not using the HuC might negatively
* impact power usage and/or performance of media workloads, depending on the
* use-cases.
* HuC must be reloaded on events that cause the WOPCM to lose its contents
- * (S3/S4, FLR); GuC-authenticated HuC must also be reloaded on GuC/GT reset,
- * while GSC-managed HuC will survive that.
+ * (S3/S4, FLR); on older platforms the HuC must also be reloaded on GuC/GT
+ * reset, while on newer ones it will survive that.
*
* See https://github.com/intel/media-driver for the latest details on HuC
* functionality.
@@ -106,7 +115,7 @@ static enum hrtimer_restart
huc_delayed_load_timer_callback(struct hrtimer *hrti
{
struct intel_huc *huc = container_of(hrtimer, struct intel_huc,
delayed_load.timer);
- if (!intel_huc_is_authenticated(huc)) {
+ if (!intel_huc_is_authenticated(huc, INTEL_HUC_AUTH_BY_GSC)) {
if (huc->delayed_load.status == INTEL_HUC_WAITING_ON_GSC)
huc_notice(huc, "timed out waiting for MEI GSC\n");
else if (huc->delayed_load.status == INTEL_HUC_WAITING_ON_PXP)
@@ -124,7 +133,7 @@ static void huc_delayed_load_start(struct intel_huc *huc)
{
ktime_t delay;
- GEM_BUG_ON(intel_huc_is_authenticated(huc));
+ GEM_BUG_ON(intel_huc_is_authenticated(huc, INTEL_HUC_AUTH_BY_GSC));
/*
* On resume we don't have to wait for MEI-GSC to be re-probed, but we
@@ -284,13 +293,23 @@ void intel_huc_init_early(struct intel_huc *huc)
}
if (GRAPHICS_VER(i915) >= 11) {
- huc->status.reg = GEN11_HUC_KERNEL_LOAD_INFO;
- huc->status.mask = HUC_LOAD_SUCCESSFUL;
- huc->status.value = HUC_LOAD_SUCCESSFUL;
+ huc->status[INTEL_HUC_AUTH_BY_GUC].reg =
GEN11_HUC_KERNEL_LOAD_INFO;
+ huc->status[INTEL_HUC_AUTH_BY_GUC].mask = HUC_LOAD_SUCCESSFUL;
+ huc->status[INTEL_HUC_AUTH_BY_GUC].value = HUC_LOAD_SUCCESSFUL;
} else {
- huc->status.reg = HUC_STATUS2;
- huc->status.mask = HUC_FW_VERIFIED;
- huc->status.value = HUC_FW_VERIFIED;
+ huc->status[INTEL_HUC_AUTH_BY_GUC].reg
Re: [Freedreno] [PATCH v2 0/7] drm/msm/dpu: simplify DPU encoder init
On 5/23/2023 12:30 PM, Abhinav Kumar wrote: On 5/23/2023 12:23 PM, Dmitry Baryshkov wrote: On Tue, 23 May 2023 at 22:14, Abhinav Kumar wrote: On 5/23/2023 7:36 AM, Dmitry Baryshkov wrote: On 23/05/2023 10:31, Neil Armstrong wrote: On 23/05/2023 09:20, Dmitry Baryshkov wrote: On Tue, 23 May 2023 at 04:58, Abhinav Kumar wrote: On 5/18/2023 7:38 PM, Dmitry Baryshkov wrote: Rework dpu_encoder initialization code, simplifying calling sequences and separating common init parts. Changes since v1: - Withdrawn two pathes for a later consideration - Changed dpu_encoder_phys_init() to return void (Abhinav) - Added small simplifications of dpu_encoder_phys_cmd_init() and dpu_encoder_phys_wb_init() I had previously given these comments on the cover letter of v1, so giving it again. Please mention that your series was made on top of https://patchwork.freedesktop.org/series/116530/. Figured it out when I tried to apply it to my branch to test. I had tested v1, and between v1 and v2 i only see very trivial change, so i think its okay to retain: Tested-by: Abhinav Kumar # sc7280 Unfortunately patchwork ignores tags sent in the cover letter thread. But b4 does with -t option to b4 shazam or b4 am Yes. But b4 doesn't append Patchwork headers. If thats the case, either the author can add them to the patches manually like we do sometimes for R-b tags OR I will go ahead and add it one by one for every patch now. I'd prefer either to have a single T-B on the latest patch on the series, or a pile of replies with T-B tags. Thank you (for the testing and for providing the feedback). If we ever switch from git-pw to b4, this requirement will be lifted. Latest patch means, the last one in the series? In this case, that would look a bit odd as that one just removes a temp variable. I will provide it on all the patches by tomorrow. This patch doesnt apply cleanly on msm-next-lumag now. Do you have to rebase this? Otherwise please list the dependency on top of msm-next-lumag. Let me know what you prefer. Neil Dmitry Baryshkov (7): drm/msm/dpu: merge dpu_encoder_init() and dpu_encoder_setup() drm/msm/dpu: separate common function to init physical encoder drm/msm/dpu: drop duplicated intf/wb indices from encoder structs drm/msm/dpu: inline dpu_encoder_get_wb() drm/msm/dpu: call dpu_rm_get_intf() from dpu_encoder_get_intf() drm/msm/dpu: drop temp variable from dpu_encoder_phys_cmd_init() drm/msm/dpu: simplify dpu_encoder_phys_wb_init() drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c | 178 -- drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.h | 14 +- .../gpu/drm/msm/disp/dpu1/dpu_encoder_phys.h | 15 +- .../drm/msm/disp/dpu1/dpu_encoder_phys_cmd.c | 35 ++-- .../drm/msm/disp/dpu1/dpu_encoder_phys_vid.c | 19 +- .../drm/msm/disp/dpu1/dpu_encoder_phys_wb.c | 35 +--- drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c | 87 - 7 files changed, 140 insertions(+), 243 deletions(-)
Re: [PATCH v3 3/7] drm/i915/huc: Load GSC-enabled HuC via DMA xfer if the fuse says so
On 5/26/2023 17:52, Daniele Ceraolo Spurio wrote:
In the previous patch we extracted the offset of the legacy-style HuC
binary located within the GSC-enabled blob, so now we can use that to
load the HuC via DMA if the fuse is set that way.
Note that we now need to differentiate between "GSC-enabled binary" and
"loaded by GSC", so the former case has been renamed to "has GSC headers"
for clarity, while the latter is now based on the fuse instead of the
binary format. This way, all the legacy load paths are automatically
taken (including the auth by GuC) without having to implement further
code changes.
v2: s/is_meu_binary/has_gsc_headers/, clearer logs (John)
Signed-off-by: Daniele Ceraolo Spurio
Cc: Alan Previn
Cc: John Harrison
---
drivers/gpu/drm/i915/gt/uc/intel_huc.c| 29 ++-
drivers/gpu/drm/i915/gt/uc/intel_huc.h| 4 +++-
drivers/gpu/drm/i915/gt/uc/intel_huc_fw.c | 2 +-
drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c | 12 +-
drivers/gpu/drm/i915/gt/uc/intel_uc_fw.h | 2 +-
5 files changed, 29 insertions(+), 20 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_huc.c
b/drivers/gpu/drm/i915/gt/uc/intel_huc.c
index 6d795438b3e4..37c6a8ca5c71 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_huc.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_huc.c
@@ -298,31 +298,38 @@ void intel_huc_init_early(struct intel_huc *huc)
static int check_huc_loading_mode(struct intel_huc *huc)
{
struct intel_gt *gt = huc_to_gt(huc);
- bool fw_needs_gsc = intel_huc_is_loaded_by_gsc(huc);
- bool hw_uses_gsc = false;
+ bool gsc_enabled = huc->fw.has_gsc_headers;
/*
* The fuse for HuC load via GSC is only valid on platforms that have
* GuC deprivilege.
*/
if (HAS_GUC_DEPRIVILEGE(gt->i915))
- hw_uses_gsc = intel_uncore_read(gt->uncore, GUC_SHIM_CONTROL2) &
- GSC_LOADS_HUC;
+ huc->loaded_via_gsc = intel_uncore_read(gt->uncore,
GUC_SHIM_CONTROL2) &
+ GSC_LOADS_HUC;
- if (fw_needs_gsc != hw_uses_gsc) {
- huc_err(huc, "mismatch between FW (%s) and HW (%s) load
modes\n",
- HUC_LOAD_MODE_STRING(fw_needs_gsc),
HUC_LOAD_MODE_STRING(hw_uses_gsc));
+ if (huc->loaded_via_gsc && !gsc_enabled) {
+ huc_err(huc, "HW requires a GSC-enabled blob, but we found a legacy
one\n");
return -ENOEXEC;
}
- /* make sure we can access the GSC via the mei driver if we need it */
+ /*
+* Newer GSC_enabled blobs contain the old FW structure inside. If we
+* found that, we can use it to load the legacy way.
+*/
+ if (!huc->loaded_via_gsc && gsc_enabled && !huc->fw.dma_start_offset) {
+ huc_err(huc,"HW in DMA mode, but we have an incompatible GSC-enabled
blob\n");
+ return -ENOEXEC;
+ }
The comment above doesn't seem to match the check. The comment says 'we
can load the old way if possible' whereas the check is more 'can we load
the old way if we need to'.
+
+ /* make sure we can access the GSC if we need it */
if (!(IS_ENABLED(CONFIG_INTEL_MEI_PXP) && IS_ENABLED(CONFIG_INTEL_MEI_GSC))
&&
- fw_needs_gsc) {
- huc_info(huc, "can't load due to missing MEI modules\n");
+ !HAS_ENGINE(gt, GSC0) && huc->loaded_via_gsc) {
This test still looks wrong when you read it. I think it needs a more
detailed comment. Some kind of explanation that the modules only apply
to one platform and the engine to a different platform. Or even breaking
into two separate tests with an 'if(DG2)' between them? It certainly
confuses me every time I look at it.
John.
+ huc_info(huc, "can't load due to missing mei modules or
GSCCS\n");
return -EIO;
}
- huc_dbg(huc, "loaded by GSC = %s\n", str_yes_no(fw_needs_gsc));
+ huc_dbg(huc, "loaded by GSC = %s\n", str_yes_no(huc->loaded_via_gsc));
return 0;
}
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_huc.h
b/drivers/gpu/drm/i915/gt/uc/intel_huc.h
index 0789184d81a2..112f0dce4702 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_huc.h
+++ b/drivers/gpu/drm/i915/gt/uc/intel_huc.h
@@ -39,6 +39,8 @@ struct intel_huc {
struct notifier_block nb;
enum intel_huc_delayed_load_status status;
} delayed_load;
+
+ bool loaded_via_gsc;
};
int intel_huc_sanitize(struct intel_huc *huc);
@@ -73,7 +75,7 @@ static inline bool intel_huc_is_used(struct intel_huc *huc)
static inline bool intel_huc_is_loaded_by_gsc(const struct intel_huc *huc)
{
- return huc->fw.loaded_via_gsc;
+ return huc->loaded_via_gsc;
}
static inline bool intel_huc_wait_required(struct intel_huc *huc)
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_huc_fw.c
b/drivers/gpu/drm/i915/gt/uc/intel_huc_fw.c
index 037d2ad4879d..3355dc1e2bc6 100644
Re: [PATCH v3 2/7] drm/i915/huc: Parse the GSC-enabled HuC binary
On 5/26/2023 17:52, Daniele Ceraolo Spurio wrote:
The new binaries that support the 2-step authentication contain the
legacy-style binary, which we can use for loading the HuC via DMA. To
find out where this is located in the image, we need to parse the
manifest of the GSC-enabled HuC binary. The manifest consist of a
partition header followed by entries, one of which contains the offset
we're looking for.
Note that the DG2 GSC binary contains entries with the same names, but
it doesn't contain a full legacy binary, so we need to skip assigning
the dma offset in that case (which we can do by checking the ccs).
Also, since we're now parsing the entries, we can extract the HuC
version that way instead of using hardcoded offsets.
Note that the GSC binary uses the same structures in its binary header,
so they've been added in their own header file.
v2: fix structure names to match meu defines (s/CPT/CPD/), update commit
message, check ccs validity, drop old version location defines.
v3: drop references to the MEU tool to reduce confusion, fix log (John)
Signed-off-by: Daniele Ceraolo Spurio
Cc: Alan Previn
Cc: John Harrison
Reviewed-by: Alan Previn #v2
---
.../drm/i915/gt/uc/intel_gsc_binary_headers.h | 74 ++
drivers/gpu/drm/i915/gt/uc/intel_huc.c| 11 +-
drivers/gpu/drm/i915/gt/uc/intel_huc_fw.c | 135 ++
drivers/gpu/drm/i915/gt/uc/intel_huc_fw.h | 5 +-
drivers/gpu/drm/i915/gt/uc/intel_huc_print.h | 21 +++
drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c | 71 +
drivers/gpu/drm/i915/gt/uc/intel_uc_fw.h | 2 +
drivers/gpu/drm/i915/gt/uc/intel_uc_fw_abi.h | 6 -
8 files changed, 272 insertions(+), 53 deletions(-)
create mode 100644 drivers/gpu/drm/i915/gt/uc/intel_gsc_binary_headers.h
create mode 100644 drivers/gpu/drm/i915/gt/uc/intel_huc_print.h
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_gsc_binary_headers.h
b/drivers/gpu/drm/i915/gt/uc/intel_gsc_binary_headers.h
new file mode 100644
index ..714f0c256118
--- /dev/null
+++ b/drivers/gpu/drm/i915/gt/uc/intel_gsc_binary_headers.h
@@ -0,0 +1,74 @@
+/* SPDX-License-Identifier: MIT */
+/*
+ * Copyright © 2023 Intel Corporation
+ */
+
+#ifndef _INTEL_GSC_BINARY_HEADERS_H_
+#define _INTEL_GSC_BINARY_HEADERS_H_
+
+#include
+
+/* Code partition directory (CPD) structures */
+struct intel_gsc_cpd_header_v2 {
+ u32 header_marker;
+#define INTEL_GSC_CPD_HEADER_MARKER 0x44504324
+
+ u32 num_of_entries;
+ u8 header_version;
+ u8 entry_version;
+ u8 header_length; /* in bytes */
+ u8 flags;
+ u32 partition_name;
+ u32 crc32;
+} __packed;
+
+struct intel_gsc_cpd_entry {
+ u8 name[12];
+
+ /*
+* Bits 0-24: offset from the beginning of the code partition
+* Bit 25: huffman compressed
+* Bits 26-31: reserved
+*/
+ u32 offset;
+#define INTEL_GSC_CPD_ENTRY_OFFSET_MASK GENMASK(24, 0)
+#define INTEL_GSC_CPD_ENTRY_HUFFMAN_COMP BIT(25)
+
+ /*
+* Module/Item length, in bytes. For Huffman-compressed modules, this
+* refers to the uncompressed size. For software-compressed modules,
+* this refers to the compressed size.
+*/
+ u32 length;
+
+ u8 reserved[4];
+} __packed;
+
+struct intel_gsc_version {
+ u16 major;
+ u16 minor;
+ u16 hotfix;
+ u16 build;
+} __packed;
+
+struct intel_gsc_manifest_header {
+ u32 header_type; /* 0x4 for manifest type */
+ u32 header_length; /* in dwords */
+ u32 header_version;
+ u32 flags;
+ u32 vendor;
+ u32 date;
+ u32 size; /* In dwords, size of entire manifest (header + extensions) */
+ u32 header_id;
+ u32 internal_data;
+ struct intel_gsc_version fw_version;
+ u32 security_version;
+ struct intel_gsc_version meu_kit_version;
+ u32 meu_manifest_version;
+ u8 general_data[4];
+ u8 reserved3[56];
+ u32 modulus_size; /* in dwords */
+ u32 exponent_size; /* in dwords */
+} __packed;
+
+#endif
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_huc.c
b/drivers/gpu/drm/i915/gt/uc/intel_huc.c
index 268e036f8f28..6d795438b3e4 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_huc.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_huc.c
@@ -6,23 +6,14 @@
#include
#include "gt/intel_gt.h"
-#include "gt/intel_gt_print.h"
#include "intel_guc_reg.h"
#include "intel_huc.h"
+#include "intel_huc_print.h"
#include "i915_drv.h"
#include
#include
-#define huc_printk(_huc, _level, _fmt, ...) \
- gt_##_level(huc_to_gt(_huc), "HuC: " _fmt, ##__VA_ARGS__)
-#define huc_err(_huc, _fmt, ...) huc_printk((_huc), err, _fmt,
##__VA_ARGS__)
-#define huc_warn(_huc, _fmt, ...) huc_printk((_huc), warn, _fmt,
##__VA_ARGS__)
-#define huc_notice(_huc, _fmt, ...)huc_printk((_huc), notice, _fmt,
##__VA_ARGS__)
-#define huc_info(_huc, _fmt, ...) huc_printk((_huc), info, _fmt,
Re: [PATCH RFC 03/10] drm/panel: Add LGD panel driver for Sony Xperia XZ3
On 30/05/2023 21:13, Marijn Suijten wrote:
On 2023-05-30 10:54:17, Abhinav Kumar wrote:
On 30/05/2023 00:07, Marijn Suijten wrote:
On 2023-05-22 15:58:56, Dmitry Baryshkov wrote:
On Mon, 22 May 2023 at 12:04, Neil Armstrong
wrote:
On 22/05/2023 03:16, Dmitry Baryshkov wrote:
On 22/05/2023 00:23, Marijn Suijten wrote:
Sony provides an unlabeled LGD + Atmel maXTouch assembly in its
Xperia
XZ3 (tama akatsuki) phone, with custom DCS commands to match.
This panel features Display Stream Compression 1.1.
Signed-off-by: Marijn Suijten
---
drivers/gpu/drm/panel/Kconfig | 11 +
drivers/gpu/drm/panel/Makefile | 1 +
drivers/gpu/drm/panel/panel-sony-akatsuki-lgd.c | 362
3 files changed, 374 insertions(+)
diff --git a/drivers/gpu/drm/panel/Kconfig
b/drivers/gpu/drm/panel/Kconfig
index 67ef898d133f2..18bd116e78a71 100644
--- a/drivers/gpu/drm/panel/Kconfig
+++ b/drivers/gpu/drm/panel/Kconfig
@@ -706,6 +706,17 @@ config DRM_PANEL_SONY_ACX565AKM
Say Y here if you want to enable support for the Sony
ACX565AKM
800x600 3.5" panel (found on the Nokia N900).
+config DRM_PANEL_SONY_AKATSUKI_LGD
+ tristate "Sony Xperia XZ3 LGD panel"
+ depends on GPIOLIB && OF
+ depends on DRM_MIPI_DSI
+ depends on BACKLIGHT_CLASS_DEVICE
+ help
+ Say Y here if you want to enable support for the Sony
Xperia XZ3
+ 1440x2880@60 6.0" OLED DSI cmd mode panel produced by LG
Display.
+
+ This panel uses Display Stream Compression 1.1.
+
config DRM_PANEL_SONY_TD4353_JDI
tristate "Sony TD4353 JDI panel"
depends on GPIOLIB && OF
diff --git a/drivers/gpu/drm/panel/Makefile
b/drivers/gpu/drm/panel/Makefile
index ff169781e82d7..85133f73558f3 100644
--- a/drivers/gpu/drm/panel/Makefile
+++ b/drivers/gpu/drm/panel/Makefile
@@ -71,6 +71,7 @@ obj-$(CONFIG_DRM_PANEL_SITRONIX_ST7701) +=
panel-sitronix-st7701.o
obj-$(CONFIG_DRM_PANEL_SITRONIX_ST7703) += panel-sitronix-st7703.o
obj-$(CONFIG_DRM_PANEL_SITRONIX_ST7789V) +=
panel-sitronix-st7789v.o
obj-$(CONFIG_DRM_PANEL_SONY_ACX565AKM) += panel-sony-acx565akm.o
+obj-$(CONFIG_DRM_PANEL_SONY_AKATSUKI_LGD) +=
panel-sony-akatsuki-lgd.o
obj-$(CONFIG_DRM_PANEL_SONY_TD4353_JDI) += panel-sony-td4353-jdi.o
obj-$(CONFIG_DRM_PANEL_SONY_TULIP_TRULY_NT35521) +=
panel-sony-tulip-truly-nt35521.o
obj-$(CONFIG_DRM_PANEL_TDO_TL070WSH30) += panel-tdo-tl070wsh30.o
diff --git a/drivers/gpu/drm/panel/panel-sony-akatsuki-lgd.c
b/drivers/gpu/drm/panel/panel-sony-akatsuki-lgd.c
new file mode 100644
index 0..f55788f963dab
--- /dev/null
+++ b/drivers/gpu/drm/panel/panel-sony-akatsuki-lgd.c
@@ -0,0 +1,362 @@
+// SPDX-License-Identifier: GPL-2.0-only
+/*
+ * Copyright (c) 2023 Marijn Suijten
+ *
+ * Based on Sony Downstream's "Atmel LGD ID5" Akatsuki panel dtsi.
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include
+
+#include
+#include
+#include
+#include
+#include
+#include
+
+struct sony_akatsuki_lgd {
+ struct drm_panel panel;
+ struct mipi_dsi_device *dsi;
+ struct regulator *vddio;
+ struct gpio_desc *reset_gpio;
+ bool prepared;
+};
+
+static inline struct sony_akatsuki_lgd
*to_sony_akatsuki_lgd(struct drm_panel *panel)
+{
+ return container_of(panel, struct sony_akatsuki_lgd, panel);
+}
+
+static int sony_akatsuki_lgd_on(struct sony_akatsuki_lgd *ctx)
+{
+ struct mipi_dsi_device *dsi = ctx->dsi;
+ struct device *dev = >dev;
+ int ret;
+
+ dsi->mode_flags |= MIPI_DSI_MODE_LPM;
+
+ mipi_dsi_dcs_write_seq(dsi, 0x7f, 0x5a, 0x5a);
+ mipi_dsi_dcs_write_seq(dsi, 0xf0, 0x5a, 0x5a);
+ mipi_dsi_dcs_write_seq(dsi, 0xf1, 0x5a, 0x5a);
+ mipi_dsi_dcs_write_seq(dsi, 0xf2, 0x5a, 0x5a);
+ mipi_dsi_dcs_write_seq(dsi, 0x02, 0x01);
+ mipi_dsi_dcs_write_seq(dsi, 0x59, 0x01);
+ /* Enable backlight control */
+ mipi_dsi_dcs_write_seq(dsi, MIPI_DCS_WRITE_CONTROL_DISPLAY,
BIT(5));
+ mipi_dsi_dcs_write_seq(dsi, 0x57, 0x20, 0x80, 0xde, 0x60, 0x00);
+
+ ret = mipi_dsi_dcs_set_column_address(dsi, 0, 1440 - 1);
+ if (ret < 0) {
+ dev_err(dev, "Failed to set column address: %d\n", ret);
+ return ret;
+ }
+
+ ret = mipi_dsi_dcs_set_page_address(dsi, 0, 2880 - 1);
+ if (ret < 0) {
+ dev_err(dev, "Failed to set page address: %d\n", ret);
+ return ret;
+ }
+
+ mipi_dsi_dcs_write_seq(dsi, MIPI_DCS_WRITE_POWER_SAVE, 0x00);
+
+ ret = mipi_dsi_dcs_set_tear_on(dsi,
MIPI_DSI_DCS_TEAR_MODE_VBLANK);
+ if (ret < 0) {
+ dev_err(dev, "Failed to set tear on: %d\n", ret);
+ return ret;
+ }
+
+ mipi_dsi_dcs_write_seq(dsi, 0x7f, 0x5a, 0x5a);
+ mipi_dsi_dcs_write_seq(dsi, 0xf0, 0x5a, 0x5a);
+ mipi_dsi_dcs_write_seq(dsi, 0xf1, 0x5a, 0x5a);
+ mipi_dsi_dcs_write_seq(dsi, 0xf2, 0x5a, 0x5a);
+ mipi_dsi_dcs_write_seq(dsi, 0xb0, 0x03);
+ mipi_dsi_dcs_write_seq(dsi, 0xf6, 0x04);
+
Re: [PATCH 2/2] drm/panel: Add driver for Visionox r66451 panel
On 30/05/2023 23:09, Jessica Zhang wrote:
On 5/18/2023 3:17 PM, Jessica Zhang wrote:
On 5/17/2023 5:19 PM, Dmitry Baryshkov wrote:
On 16/05/2023 23:20, Jessica Zhang wrote:
Add support for the 1080x2340 Visionox R66451 AMOLED DSI panel that
comes with the Qualcomm HDK8350 display expansion pack.
The panel enables display compression (DSC v1.2) by default.
Signed-off-by: Jessica Zhang
---
drivers/gpu/drm/panel/Kconfig | 8 +
drivers/gpu/drm/panel/Makefile | 1 +
drivers/gpu/drm/panel/panel-visionox-r66451.c | 395
++
3 files changed, 404 insertions(+)
diff --git a/drivers/gpu/drm/panel/Kconfig
b/drivers/gpu/drm/panel/Kconfig
index 29cf5fa39ff2..9c2c36dbddf3 100644
--- a/drivers/gpu/drm/panel/Kconfig
+++ b/drivers/gpu/drm/panel/Kconfig
@@ -766,6 +766,14 @@ config DRM_PANEL_VISIONOX_VTDR6130
Say Y here if you want to enable support for Visionox
VTDR6130 1080x2400 AMOLED DSI panel.
+config DRM_PANEL_VISIONOX_R66451
+ tristate "Visionox R66451"
+ depends on OF
+ depends on DRM_MIPI_DSI
+ help
+ Say Y here if you want to enable support for Visionox
+ R66451 1080x2340 AMOLED DSI panel.
+
config DRM_PANEL_WIDECHIPS_WS2401
tristate "Widechips WS2401 DPI panel driver"
depends on SPI && GPIOLIB
diff --git a/drivers/gpu/drm/panel/Makefile
b/drivers/gpu/drm/panel/Makefile
index b3e8ba29edd3..e043a92ee676 100644
--- a/drivers/gpu/drm/panel/Makefile
+++ b/drivers/gpu/drm/panel/Makefile
@@ -78,5 +78,6 @@ obj-$(CONFIG_DRM_PANEL_TPO_TPG110) +=
panel-tpo-tpg110.o
obj-$(CONFIG_DRM_PANEL_TRULY_NT35597_WQXGA) += panel-truly-nt35597.o
obj-$(CONFIG_DRM_PANEL_VISIONOX_RM69299) += panel-visionox-rm69299.o
obj-$(CONFIG_DRM_PANEL_VISIONOX_VTDR6130) +=
panel-visionox-vtdr6130.o
+obj-$(CONFIG_DRM_PANEL_VISIONOX_R66451) += panel-visionox-r66451.o
obj-$(CONFIG_DRM_PANEL_WIDECHIPS_WS2401) += panel-widechips-ws2401.o
obj-$(CONFIG_DRM_PANEL_XINPENG_XPP055C272) +=
panel-xinpeng-xpp055c272.o
diff --git a/drivers/gpu/drm/panel/panel-visionox-r66451.c
b/drivers/gpu/drm/panel/panel-visionox-r66451.c
new file mode 100644
index ..e3648ead3e84
--- /dev/null
+++ b/drivers/gpu/drm/panel/panel-visionox-r66451.c
@@ -0,0 +1,395 @@
+//SPDX-License-Identifier: GPL-2.0-only
+//Copyright (c) 2023 Qualcomm Innovation Center, Inc. All rights
reserved.
+
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include
+#include
+#include
+#include
+#include
+
+#include
+
+struct visionox_r66451 {
+ struct drm_panel panel;
+ struct mipi_dsi_device *dsi;
+ struct gpio_desc *reset_gpio;
+ struct regulator_bulk_data supplies[2];
+ bool prepared, enabled;
+};
+
+static inline struct visionox_r66451 *to_visionox_r66451(struct
drm_panel *panel)
+{
+ return container_of(panel, struct visionox_r66451, panel);
+}
+
+static void visionox_r66451_reset(struct visionox_r66451 *ctx)
+{
+ gpiod_set_value_cansleep(ctx->reset_gpio, 0);
+ usleep_range(1, 10100);
+ gpiod_set_value_cansleep(ctx->reset_gpio, 1);
+ usleep_range(1, 10100);
+ gpiod_set_value_cansleep(ctx->reset_gpio, 0);
+ usleep_range(1, 10100);
+}
+
+static int visionox_r66451_on(struct visionox_r66451 *ctx)
+{
+ struct mipi_dsi_device *dsi = ctx->dsi;
+ struct device *dev = >dev;
+ int ret;
+
+ dsi->mode_flags |= MIPI_DSI_MODE_LPM;
+
+ mipi_dsi_dcs_write_seq(dsi, 0xb0, 0x00);
+ mipi_dsi_dcs_write_seq(dsi, 0xc2,
+ 0x09, 0x24, 0x0c, 0x00, 0x00, 0x0c, 0x00, 0x00,
0x00,
+ 0x09, 0x3c);
+ mipi_dsi_dcs_write_seq(dsi, 0xd7,
+ 0x00, 0xb9, 0x3c, 0x00, 0x40, 0x04, 0x00, 0xa0,
0x0a,
+ 0x00, 0x40, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
0x19,
+ 0x3c, 0x00, 0x40, 0x04, 0x00, 0xa0, 0x0a);
+ mipi_dsi_dcs_write_seq(dsi, 0xb0, 0x80);
+ mipi_dsi_dcs_write_seq(dsi, 0xde,
+ 0x40, 0x00, 0x18, 0x00, 0x18, 0x00, 0x18, 0x00,
0x18,
+ 0x10, 0x00, 0x18, 0x00, 0x18, 0x00, 0x18, 0x02,
0x00, 0x00);
+ mipi_dsi_dcs_write_seq(dsi, 0xb0, 0x04);
+ mipi_dsi_dcs_write_seq(dsi, 0xe8, 0x00, 0x02);
+ mipi_dsi_dcs_write_seq(dsi, 0xe4, 0x00, 0x08);
+ mipi_dsi_dcs_write_seq(dsi, 0xb0, 0x00);
+ mipi_dsi_dcs_write_seq(dsi, 0xc4,
+ 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
0x00,
+ 0x00, 0x00, 0x02, 0x00, 0x00, 0x00, 0x32);
+ mipi_dsi_dcs_write_seq(dsi, 0xcf,
+ 0x64, 0x0b, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
0x08,
+ 0x00, 0x0b, 0x77, 0x01, 0x01, 0x01, 0x01, 0x01,
0x01,
+ 0x02, 0x02, 0x02, 0x02, 0x02, 0x03);
+ mipi_dsi_dcs_write_seq(dsi, 0xd3,
+ 0x45, 0x00, 0x00, 0x01, 0x13, 0x15, 0x00, 0x15,
0x07,
+ 0x0f, 0x77, 0x77, 0x77, 0x37, 0xb2, 0x11, 0x00,
0xa0,
+ 0x3c, 0x9c);
+ mipi_dsi_dcs_write_seq(dsi,
Re: [PATCH][next] drm/amdgpu/discovery: Replace fake flex-arrays with flexible-array members
On Sun, May 28, 2023 at 02:26:37PM -0600, Gustavo A. R. Silva wrote:
> Zero-length and one-element arrays are deprecated, and we are moving
> towards adopting C99 flexible-array members, instead.
>
> Use the DECLARE_FLEX_ARRAY() helper macro to transform zero-length
> arrays in a union into flexible-array members. And replace a one-element
> array with a C99 flexible-array member.
>
> Address the following warnings found with GCC-13 and
> -fstrict-flex-arrays=3 enabled:
> drivers/gpu/drm/amd/amdgpu/amdgpu_discovery.c:1009:89: warning: array
> subscript kk is outside array bounds of ‘uint32_t[0]’ {aka ‘unsigned int[]’}
> [-Warray-bounds=]
> drivers/gpu/drm/amd/amdgpu/amdgpu_discovery.c:1007:94: warning: array
> subscript kk is outside array bounds of ‘uint64_t[0]’ {aka ‘long long
> unsigned int[]’} [-Warray-bounds=]
> drivers/gpu/drm/amd/amdgpu/amdgpu_discovery.c:1310:94: warning: array
> subscript k is outside array bounds of ‘uint64_t[0]’ {aka ‘long long unsigned
> int[]’} [-Warray-bounds=]
> drivers/gpu/drm/amd/amdgpu/amdgpu_discovery.c:1309:57: warning: array
> subscript k is outside array bounds of ‘uint32_t[0]’ {aka ‘unsigned int[]’}
> [-Warray-bounds=]
>
> This helps with the ongoing efforts to tighten the FORTIFY_SOURCE
> routines on memcpy() and help us make progress towards globally
> enabling -fstrict-flex-arrays=3 [1].
>
> This results in no differences in binary output.
>
> Link: https://github.com/KSPP/linux/issues/21
> Link: https://github.com/KSPP/linux/issues/193
> Link: https://github.com/KSPP/linux/issues/300
> Link: https://gcc.gnu.org/pipermail/gcc-patches/2022-October/602902.html [1]
> Signed-off-by: Gustavo A. R. Silva
Reviewed-by: Kees Cook
--
Kees Cook
Re: [PATCH v1 3/3] drm/msm/dpu: remove msm_dsi_get_dsc_config()
On 30/05/2023 19:31, Kuogee Hsieh wrote: Since msm_dsi_bridge_get_dsc_config() was added to retrieve DSI DSC info through DRM bridge, msm_dsi_get_dsc_config() become redundant and should be removed. Signed-off-by: Kuogee Hsieh --- drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c | 2 -- drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.h | 2 -- drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c | 2 -- drivers/gpu/drm/msm/dsi/dsi.c | 5 - drivers/gpu/drm/msm/msm_drv.h | 6 -- 5 files changed, 17 deletions(-) Reviewed-by: Dmitry Baryshkov -- With best wishes Dmitry
Re: [PATCH] drm/i2c: tda998x: Replace all non-returning strlcpy with strscpy
On Mon, 22 May 2023 15:53:50 +, Azeem Shaikh wrote: > strlcpy() reads the entire source buffer first. > This read may exceed the destination size limit. > This is both inefficient and can lead to linear read > overflows if a source string is not NUL-terminated [1]. > In an effort to remove strlcpy() completely [2], replace > strlcpy() here with strscpy(). > No return values were used, so direct replacement is safe. > > [...] Applied to for-next/hardening, thanks! [1/1] drm/i2c: tda998x: Replace all non-returning strlcpy with strscpy https://git.kernel.org/kees/c/a7aba6fa2750 -- Kees Cook
Re: [PATCH v1 2/3] drm/msm/dpu: retrieve DSI DSC struct at atomic_check()
On 30/05/2023 19:31, Kuogee Hsieh wrote:
At current implementation, DSI DSC struct is populated at display setup
during system bootup. This mechanism works fine with embedded display.
But will run into problem with plugin/unplug oriented external display,
such as DP, due to DSC struct will become stale once external display
unplugged. New DSC struct has to be re populated to reflect newer external
display which just plugged in. Move retrieving of DSI DSC struct to
atomic_check() so that same mechanism will work for both embedded display
and external plugin/unplug oriented display.
Signed-off-by: Kuogee Hsieh
---
drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c | 15 ++-
drivers/gpu/drm/msm/msm_drv.h | 6 ++
2 files changed, 20 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
index 3b416e1..2927d20 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
@@ -16,6 +16,8 @@
#include
#include
#include
+#include
+#include
#include "msm_drv.h"
#include "dpu_kms.h"
@@ -639,6 +641,15 @@ static int dpu_encoder_virt_atomic_check(
}
}
+ if (dpu_enc->disp_info.intf_type == DRM_MODE_ENCODER_DSI) {
INTF_DSI
+ struct drm_bridge *bridge;
+
+ if (!dpu_enc->dsc) {
This condition is not correct. We should be updating the DSC even if
there is one.
+ bridge = drm_bridge_chain_get_first_bridge(drm_enc);
+ dpu_enc->dsc = msm_dsi_bridge_get_dsc_config(bridge);
This approach will not work for the hot-pluggable outputs. The dpu_enc
is not a part of the state. It should not be touched before
atomic_commit actually commits changes.
Also, I don't think I like the API. It makes it impossible for the
driver to check that the bridge is the actually our DSI bridge or not.
Once you add DP here, the code will explode.
I think instead we should extend the drm_bridge API to be able to get
the DSC configuration from it directly. Additional care should be put to
design an assymetrical API. Theoretically a drm_bridge can be both DSC
source and DSC sink. Imagine a DSI-to-DP or DSI-to-HDMI bridge,
supporting DSC on the DSI side too.
+ }
+ }
+
topology = dpu_encoder_get_topology(dpu_enc, dpu_kms, adj_mode,
crtc_state);
/*
@@ -2121,8 +2132,10 @@ void dpu_encoder_helper_phys_cleanup(struct
dpu_encoder_phys *phys_enc)
phys_enc->hw_pp->merge_3d->idx);
}
- if (dpu_enc->dsc)
+ if (dpu_enc->dsc) {
dpu_encoder_unprep_dsc(dpu_enc);
+ dpu_enc->dsc = NULL;
+ }
intf_cfg.stream_sel = 0; /* Don't care value for video mode */
intf_cfg.mode_3d = dpu_encoder_helper_get_3d_blend_mode(phys_enc);
diff --git a/drivers/gpu/drm/msm/msm_drv.h b/drivers/gpu/drm/msm/msm_drv.h
index e13a8cb..5a7c1f4 100644
--- a/drivers/gpu/drm/msm/msm_drv.h
+++ b/drivers/gpu/drm/msm/msm_drv.h
@@ -341,6 +341,7 @@ bool msm_dsi_is_cmd_mode(struct msm_dsi *msm_dsi);
bool msm_dsi_is_bonded_dsi(struct msm_dsi *msm_dsi);
bool msm_dsi_is_master_dsi(struct msm_dsi *msm_dsi);
struct drm_dsc_config *msm_dsi_get_dsc_config(struct msm_dsi *msm_dsi);
+struct drm_dsc_config *msm_dsi_bridge_get_dsc_config(struct drm_bridge
*bridge);
#else
static inline void __init msm_dsi_register(void)
{
@@ -374,6 +375,11 @@ static inline struct drm_dsc_config
*msm_dsi_get_dsc_config(struct msm_dsi *msm_
{
return NULL;
}
+
+struct drm_dsc_config *msm_dsi_bridge_get_dsc_config(struct drm_bridge *bridge)
+{
+ return NULL;
+}
These two chunks belong to the previous patch.
#endif
#ifdef CONFIG_DRM_MSM_DP
--
With best wishes
Dmitry
Re: [PATCH] drm/mediatek: Replace all non-returning strlcpy with strscpy
On Mon, 22 May 2023 15:53:06 +, Azeem Shaikh wrote: > strlcpy() reads the entire source buffer first. > This read may exceed the destination size limit. > This is both inefficient and can lead to linear read > overflows if a source string is not NUL-terminated [1]. > In an effort to remove strlcpy() completely [2], replace > strlcpy() here with strscpy(). > No return values were used, so direct replacement is safe. > > [...] Applied to for-next/hardening, thanks! [1/1] drm/mediatek: Replace all non-returning strlcpy with strscpy https://git.kernel.org/kees/c/99ae1670e488 -- Kees Cook
Re: [PATCH] drm/sun4i: hdmi: Replace all non-returning strlcpy with strscpy
On Mon, 22 May 2023 15:53:31 +, Azeem Shaikh wrote: > strlcpy() reads the entire source buffer first. > This read may exceed the destination size limit. > This is both inefficient and can lead to linear read > overflows if a source string is not NUL-terminated [1]. > In an effort to remove strlcpy() completely [2], replace > strlcpy() here with strscpy(). > No return values were used, so direct replacement is safe. > > [...] Applied to for-next/hardening, thanks! [1/1] drm/sun4i: hdmi: Replace all non-returning strlcpy with strscpy https://git.kernel.org/kees/c/6036094a9380 -- Kees Cook
Re: [PATCH] drm/rockchip: Replace all non-returning strlcpy with strscpy
On Mon, 22 May 2023 15:51:49 +, Azeem Shaikh wrote: > strlcpy() reads the entire source buffer first. > This read may exceed the destination size limit. > This is both inefficient and can lead to linear read > overflows if a source string is not NUL-terminated [1]. > In an effort to remove strlcpy() completely [2], replace > strlcpy() here with strscpy(). > No return values were used, so direct replacement is safe. > > [...] Applied to for-next/hardening, thanks! [1/1] drm/rockchip: Replace all non-returning strlcpy with strscpy https://git.kernel.org/kees/c/3bc490653e12 -- Kees Cook
Re: [PATCH] drm/display/dp_mst: Replace all non-returning strlcpy with strscpy
On Mon, 22 May 2023 15:51:24 +, Azeem Shaikh wrote: > strlcpy() reads the entire source buffer first. > This read may exceed the destination size limit. > This is both inefficient and can lead to linear read > overflows if a source string is not NUL-terminated [1]. > In an effort to remove strlcpy() completely [2], replace > strlcpy() here with strscpy(). > No return values were used, so direct replacement is safe. > > [...] Applied to for-next/hardening, thanks! [1/1] drm/display/dp_mst: Replace all non-returning strlcpy with strscpy https://git.kernel.org/kees/c/09c8ecb20243 -- Kees Cook
Re: [PATCH v3 1/7] drm/i915/uc: perma-pin firmwares
On 5/26/2023 17:52, Daniele Ceraolo Spurio wrote:
Now that each FW has its own reserved area, we can keep them always
pinned and skip the pin/unpin dance on reset. This will make things
easier for the 2-step HuC authentication, which requires the FW to be
pinned in GGTT after the xfer is completed.
Since the vma is now valid for a long time and not just for the quick
pin-load-unpin dance, the name "dummy" is no longer appropriare and has
been replaced with vma_res. All the functions have also been updated to
operate on vma_res for consistency.
Given that we pin the vma behind the allocator's back (which is ok
because we do the pinning in an area that was previously reserved for
thus purpose), we do need to explicitly re-pin on resume because the
automated helper won't cover us.
v2: better comments and commit message, s/dummy/vma_res/
Signed-off-by: Daniele Ceraolo Spurio
Cc: Alan Previn
Cc: John Harrison
Reviewed-by: John Harrison
---
drivers/gpu/drm/i915/gt/intel_ggtt.c | 3 ++
drivers/gpu/drm/i915/gt/uc/intel_gsc_uc.c | 7 +++-
drivers/gpu/drm/i915/gt/uc/intel_guc.c| 2 +-
drivers/gpu/drm/i915/gt/uc/intel_huc.c| 2 +-
drivers/gpu/drm/i915/gt/uc/intel_uc.c | 8
drivers/gpu/drm/i915/gt/uc/intel_uc.h | 2 +
drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c | 50 ---
drivers/gpu/drm/i915/gt/uc/intel_uc_fw.h | 22 ++
8 files changed, 71 insertions(+), 25 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/intel_ggtt.c
b/drivers/gpu/drm/i915/gt/intel_ggtt.c
index 2a7942fac798..f4e8aa8246e8 100644
--- a/drivers/gpu/drm/i915/gt/intel_ggtt.c
+++ b/drivers/gpu/drm/i915/gt/intel_ggtt.c
@@ -1326,6 +1326,9 @@ void i915_ggtt_resume(struct i915_ggtt *ggtt)
ggtt->vm.scratch_range(>vm, ggtt->error_capture.start,
ggtt->error_capture.size);
+ list_for_each_entry(gt, >gt_list, ggtt_link)
+ intel_uc_resume_mappings(>uc);
+
ggtt->invalidate(ggtt);
if (flush)
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_gsc_uc.c
b/drivers/gpu/drm/i915/gt/uc/intel_gsc_uc.c
index fb0984f875f9..b26f493f86fa 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_gsc_uc.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_gsc_uc.c
@@ -90,7 +90,12 @@ void intel_gsc_uc_init_early(struct intel_gsc_uc *gsc)
{
struct intel_gt *gt = gsc_uc_to_gt(gsc);
- intel_uc_fw_init_early(>fw, INTEL_UC_FW_TYPE_GSC);
+ /*
+* GSC FW needs to be copied to a dedicated memory allocations for
+* loading (see gsc->local), so we don't need to GGTT map the FW image
+* itself into GGTT.
+*/
+ intel_uc_fw_init_early(>fw, INTEL_UC_FW_TYPE_GSC, false);
INIT_WORK(>work, gsc_work);
/* we can arrive here from i915_driver_early_probe for primary
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc.c
b/drivers/gpu/drm/i915/gt/uc/intel_guc.c
index c9f20385f6a0..2eb891b270ae 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_guc.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_guc.c
@@ -164,7 +164,7 @@ void intel_guc_init_early(struct intel_guc *guc)
struct intel_gt *gt = guc_to_gt(guc);
struct drm_i915_private *i915 = gt->i915;
- intel_uc_fw_init_early(>fw, INTEL_UC_FW_TYPE_GUC);
+ intel_uc_fw_init_early(>fw, INTEL_UC_FW_TYPE_GUC, true);
intel_guc_ct_init_early(>ct);
intel_guc_log_init_early(>log);
intel_guc_submission_init_early(guc);
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_huc.c
b/drivers/gpu/drm/i915/gt/uc/intel_huc.c
index 04724ff56ded..268e036f8f28 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_huc.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_huc.c
@@ -276,7 +276,7 @@ void intel_huc_init_early(struct intel_huc *huc)
struct drm_i915_private *i915 = huc_to_gt(huc)->i915;
struct intel_gt *gt = huc_to_gt(huc);
- intel_uc_fw_init_early(>fw, INTEL_UC_FW_TYPE_HUC);
+ intel_uc_fw_init_early(>fw, INTEL_UC_FW_TYPE_HUC, true);
/*
* we always init the fence as already completed, even if HuC is not
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_uc.c
b/drivers/gpu/drm/i915/gt/uc/intel_uc.c
index c8b9cbb7ba3a..1e7f5cc9d550 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_uc.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_uc.c
@@ -700,6 +700,12 @@ void intel_uc_suspend(struct intel_uc *uc)
}
}
+static void __uc_resume_mappings(struct intel_uc *uc)
+{
+ intel_uc_fw_resume_mapping(>guc.fw);
+ intel_uc_fw_resume_mapping(>huc.fw);
+}
+
static int __uc_resume(struct intel_uc *uc, bool enable_communication)
{
struct intel_guc *guc = >guc;
@@ -767,4 +773,6 @@ static const struct intel_uc_ops uc_ops_on = {
.init_hw = __uc_init_hw,
.fini_hw = __uc_fini_hw,
+
+ .resume_mappings = __uc_resume_mappings,
};
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_uc.h
b/drivers/gpu/drm/i915/gt/uc/intel_uc.h
index d585524d94de..014bb7d83689 100644
---
Re: [PATCH] drm/exynos: fix race condition UAF in exynos_g2d_exec_ioctl
Hi Min, On Fri, May 26, 2023 at 09:01:31PM +0800, Min Li wrote: > If it is async, runqueue_node is freed in g2d_runqueue_worker on another > worker thread. So in extreme cases, if g2d_runqueue_worker runs first, and > then executes the following if statement, there will be use-after-free. > > Signed-off-by: Min Li > --- > drivers/gpu/drm/exynos/exynos_drm_g2d.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/drivers/gpu/drm/exynos/exynos_drm_g2d.c > b/drivers/gpu/drm/exynos/exynos_drm_g2d.c > index ec784e58da5c..414e585ec7dd 100644 > --- a/drivers/gpu/drm/exynos/exynos_drm_g2d.c > +++ b/drivers/gpu/drm/exynos/exynos_drm_g2d.c > @@ -1335,7 +1335,7 @@ int exynos_g2d_exec_ioctl(struct drm_device *drm_dev, > void *data, > /* Let the runqueue know that there is work to do. */ > queue_work(g2d->g2d_workq, >runqueue_work); > > - if (runqueue_node->async) > + if (req->async) did you actually hit this? If you did, then the fix is not OK. Andi > goto out; > > wait_for_completion(_node->complete); > -- > 2.34.1 >
Re: [PATCH 3/3] drm/i915/guc: Track all sent actions to GuC
On 5/26/2023 16:55, john.c.harri...@intel.com wrote:
From: Michal Wajdeczko
For easier debug of any unexpected error responses from GuC that
might be related to non-blocking fast requests, track action code (and
stack if under DEBUG_GUC config) for every H2G request.
Signed-off-by: Michal Wajdeczko
Signed-off-by: John Harrison
Reviewed-by: John Harrison
---
drivers/gpu/drm/i915/Kconfig.debug| 1 +
drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c | 68 ++-
drivers/gpu/drm/i915/gt/uc/intel_guc_ct.h | 11
3 files changed, 77 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/i915/Kconfig.debug
b/drivers/gpu/drm/i915/Kconfig.debug
index 47e845353ffad..2d21930d55015 100644
--- a/drivers/gpu/drm/i915/Kconfig.debug
+++ b/drivers/gpu/drm/i915/Kconfig.debug
@@ -157,6 +157,7 @@ config DRM_I915_SW_FENCE_CHECK_DAG
config DRM_I915_DEBUG_GUC
bool "Enable additional driver debugging for GuC"
depends on DRM_I915
+ select STACKDEPOT
default n
help
Choose this option to turn on extra driver debugging that may affect
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 3a71bb582089e..4aa903be1317b 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c
@@ -376,6 +376,24 @@ void intel_guc_ct_disable(struct intel_guc_ct *ct)
}
}
+#if IS_ENABLED(CONFIG_DRM_I915_DEBUG_GEM)
+static void ct_track_lost_and_found(struct intel_guc_ct *ct, u32 fence, u32
action)
+{
+ unsigned int lost = fence % ARRAY_SIZE(ct->requests.lost_and_found);
+#if IS_ENABLED(CONFIG_DRM_I915_DEBUG_GUC)
+ unsigned long entries[SZ_32];
+ unsigned int n;
+
+ n = stack_trace_save(entries, ARRAY_SIZE(entries), 1);
+
+ /* May be called under spinlock, so avoid sleeping */
+ ct->requests.lost_and_found[lost].stack = stack_depot_save(entries, n,
GFP_NOWAIT);
+#endif
+ ct->requests.lost_and_found[lost].fence = fence;
+ ct->requests.lost_and_found[lost].action = action;
+}
+#endif
+
static u32 ct_get_next_fence(struct intel_guc_ct *ct)
{
/* For now it's trivial */
@@ -447,6 +465,11 @@ static int ct_write(struct intel_guc_ct *ct,
}
GEM_BUG_ON(tail > size);
+#if IS_ENABLED(CONFIG_DRM_I915_DEBUG_GEM)
+ ct_track_lost_and_found(ct, fence,
+ FIELD_GET(GUC_HXG_EVENT_MSG_0_ACTION,
action[0]));
+#endif
+
/*
* make sure H2G buffer update and LRC tail update (if this triggering a
* submission) are visible before updating the descriptor tail
@@ -953,6 +976,43 @@ static int ct_read(struct intel_guc_ct *ct, struct
ct_incoming_msg **msg)
return -EPIPE;
}
+#if IS_ENABLED(CONFIG_DRM_I915_DEBUG_GEM)
+static bool ct_check_lost_and_found(struct intel_guc_ct *ct, u32 fence)
+{
+ unsigned int n;
+ char *buf = NULL;
+ bool found = false;
+
+ lockdep_assert_held(>requests.lock);
+
+ for (n = 0; n < ARRAY_SIZE(ct->requests.lost_and_found); n++) {
+ if (ct->requests.lost_and_found[n].fence != fence)
+ continue;
+ found = true;
+
+#if IS_ENABLED(CONFIG_DRM_I915_DEBUG_GUC)
+ buf = kmalloc(SZ_4K, GFP_NOWAIT);
+ if (buf &&
stack_depot_snprint(ct->requests.lost_and_found[n].stack,
+ buf, SZ_4K, 0)) {
+ CT_ERROR(ct, "Fence %u was used by action %#04x sent
at\n%s",
+fence, ct->requests.lost_and_found[n].action,
buf);
+ break;
+ }
+#endif
+ CT_ERROR(ct, "Fence %u was used by action %#04x\n",
+fence, ct->requests.lost_and_found[n].action);
+ break;
+ }
+ kfree(buf);
+ return found;
+}
+#else
+static bool ct_check_lost_and_found(struct intel_guc_ct *ct, u32 fence)
+{
+ return false;
+}
+#endif
+
static int ct_handle_response(struct intel_guc_ct *ct, struct ct_incoming_msg
*response)
{
u32 len = FIELD_GET(GUC_CTB_MSG_0_NUM_DWORDS, response->msg[0]);
@@ -996,9 +1056,11 @@ static int ct_handle_response(struct intel_guc_ct *ct,
struct ct_incoming_msg *r
if (!found) {
CT_ERROR(ct, "Unsolicited response message: len %u, data %#x (fence
%u, last %u)\n",
len, hxg[0], fence, ct->requests.last_fence);
- list_for_each_entry(req, >requests.pending, link)
- CT_ERROR(ct, "request %u awaits response\n",
-req->fence);
+ if (!ct_check_lost_and_found(ct, fence)) {
+ list_for_each_entry(req, >requests.pending, link)
+ CT_ERROR(ct, "request %u awaits response\n",
+req->fence);
+ }
Re: [PATCH 2/3] drm/i915/guc: Update log for unsolicited CTB response
On 5/26/2023 16:55, john.c.harri...@intel.com wrote:
From: Michal Wajdeczko
Instead of printing message fence twice, include HXG header of the
unexpected message and its len.
Signed-off-by: Michal Wajdeczko
Signed-off-by: John Harrison
Reviewed-by: John Harrison
---
drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
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 af52ed4ffc7fb..3a71bb582089e 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c
@@ -994,9 +994,8 @@ static int ct_handle_response(struct intel_guc_ct *ct,
struct ct_incoming_msg *r
break;
}
if (!found) {
- CT_ERROR(ct, "Unsolicited response (fence %u)\n", fence);
- CT_ERROR(ct, "Could not find fence=%u, last_fence=%u\n", fence,
-ct->requests.last_fence);
+ CT_ERROR(ct, "Unsolicited response message: len %u, data %#x (fence
%u, last %u)\n",
+len, hxg[0], fence, ct->requests.last_fence);
list_for_each_entry(req, >requests.pending, link)
CT_ERROR(ct, "request %u awaits response\n",
req->fence);
Re: [PATCH 1/3] drm/i915/guc: Use FAST_REQUEST for non-blocking H2G calls
On 5/26/2023 16:55, john.c.harri...@intel.com wrote: From: Michal Wajdeczko In addition to the already defined REQUEST HXG message format, which is used when sender expects some confirmation or data, HXG protocol includes definition of the FAST REQUEST message, that may be used when sender does not expect any useful data to be returned. Using this instead of GUC_HXG_TYPE_EVENT for non-blocking CTB requests will allow GuC to send back GUC_HXG_TYPE_RESPONSE_FAILURE in case of errors. Note that it is not possible to return such errors to the caller, since this is for non-blocking calls and the related fence is not stored. Instead such messages are treated as unexpected, which will give an indication of potential GuC misprogramming that warrants extra debugging effort. Signed-off-by: Michal Wajdeczko Signed-off-by: John Harrison Reviewed-by: John Harrison --- .../gpu/drm/i915/gt/uc/abi/guc_messages_abi.h | 30 +++ drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c | 6 ++-- 2 files changed, 33 insertions(+), 3 deletions(-) diff --git a/drivers/gpu/drm/i915/gt/uc/abi/guc_messages_abi.h b/drivers/gpu/drm/i915/gt/uc/abi/guc_messages_abi.h index 7d5ba4d97d708..98eb4f46572b9 100644 --- a/drivers/gpu/drm/i915/gt/uc/abi/guc_messages_abi.h +++ b/drivers/gpu/drm/i915/gt/uc/abi/guc_messages_abi.h @@ -24,6 +24,7 @@ * | | 30:28 | **TYPE** - message type | * | | | - _`GUC_HXG_TYPE_REQUEST` = 0 | * | | | - _`GUC_HXG_TYPE_EVENT` = 1 | + * | | | - _`GUC_HXG_TYPE_FAST_REQUEST` = 2 | * | | | - _`GUC_HXG_TYPE_NO_RESPONSE_BUSY` = 3 | * | | | - _`GUC_HXG_TYPE_NO_RESPONSE_RETRY` = 5 | * | | | - _`GUC_HXG_TYPE_RESPONSE_FAILURE` = 6 | @@ -46,6 +47,7 @@ #define GUC_HXG_MSG_0_TYPE(0x7 << 28) #define GUC_HXG_TYPE_REQUEST0u #define GUC_HXG_TYPE_EVENT 1u +#define GUC_HXG_TYPE_FAST_REQUEST2u #define GUC_HXG_TYPE_NO_RESPONSE_BUSY 3u #define GUC_HXG_TYPE_NO_RESPONSE_RETRY 5u #define GUC_HXG_TYPE_RESPONSE_FAILURE 6u @@ -89,6 +91,34 @@ #define GUC_HXG_REQUEST_MSG_0_ACTION (0x << 0) #define GUC_HXG_REQUEST_MSG_n_DATAn GUC_HXG_MSG_n_PAYLOAD +/** + * DOC: HXG Fast Request + * + * The `HXG Request`_ message should be used to initiate asynchronous activity + * for which confirmation or return data is not expected. + * + * If confirmation is required then `HXG Request`_ shall be used instead. + * + * The recipient of this message may only use `HXG Failure`_ message if it was + * unable to accept this request (like invalid data). + * + * Format of `HXG Fast Request`_ message is same as `HXG Request`_ except @TYPE. + * + * +---+---+--+ + * | | Bits | Description | + * +===+===+==+ + * | 0 |31 | ORIGIN - see `HXG Message`_ | + * | +---+--+ + * | | 30:28 | TYPE = `GUC_HXG_TYPE_FAST_REQUEST`_ | + * | +---+--+ + * | | 27:16 | DATA0 - see `HXG Request`_ | + * | +---+--+ + * | | 15:0 | ACTION - see `HXG Request`_ | + * +---+---+--+ + * |...| | DATAn - see `HXG Request`_ | + * +---+---+--+ + */ + /** * DOC: HXG Event * 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 a22e33f37cae6..af52ed4ffc7fb 100644 --- a/drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c +++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c @@ -426,11 +426,11 @@ static int ct_write(struct intel_guc_ct *ct, FIELD_PREP(GUC_CTB_MSG_0_NUM_DWORDS, len) | FIELD_PREP(GUC_CTB_MSG_0_FENCE, fence); - type = (flags & INTEL_GUC_CT_SEND_NB) ? GUC_HXG_TYPE_EVENT : + type = (flags & INTEL_GUC_CT_SEND_NB) ? GUC_HXG_TYPE_FAST_REQUEST : GUC_HXG_TYPE_REQUEST; hxg = FIELD_PREP(GUC_HXG_MSG_0_TYPE, type) | - FIELD_PREP(GUC_HXG_EVENT_MSG_0_ACTION | - GUC_HXG_EVENT_MSG_0_DATA0, action[0]); + FIELD_PREP(GUC_HXG_REQUEST_MSG_0_ACTION | + GUC_HXG_REQUEST_MSG_0_DATA0,
Re: [PATCH 2/2] drm/bridge: tc358762: Add reset GPIO support
On Tue, May 30, 2023 at 9:28 PM Marek Vasut wrote:
>
> Add reset GPIO support. The reset GPIO is cleared after supply regulator
> was enabled, and set before supply regulator is disabled.
>
> Signed-off-by: Marek Vasut
> ---
> Cc: Andrzej Hajda
> Cc: Conor Dooley
> Cc: Daniel Vetter
> Cc: David Airlie
> Cc: Jernej Skrabec
> Cc: Jonas Karlman
> Cc: Krzysztof Kozlowski
> Cc: Laurent Pinchart
> Cc: Marek Vasut
> Cc: Neil Armstrong
> Cc: Rob Herring
> Cc: Robert Foss
> Cc: devicet...@vger.kernel.org
> Cc: dri-devel@lists.freedesktop.org
> ---
> drivers/gpu/drm/bridge/tc358762.c | 15 +++
> 1 file changed, 15 insertions(+)
>
> diff --git a/drivers/gpu/drm/bridge/tc358762.c
> b/drivers/gpu/drm/bridge/tc358762.c
> index 77f7f7f547570..5641395fd310e 100644
> --- a/drivers/gpu/drm/bridge/tc358762.c
> +++ b/drivers/gpu/drm/bridge/tc358762.c
> @@ -11,6 +11,7 @@
> */
>
> #include
> +#include
> #include
> #include
> #include
> @@ -63,6 +64,7 @@ struct tc358762 {
> struct drm_bridge bridge;
> struct regulator *regulator;
> struct drm_bridge *panel_bridge;
> + struct gpio_desc *reset_gpio;
> bool pre_enabled;
> int error;
> };
> @@ -138,6 +140,9 @@ static void tc358762_post_disable(struct drm_bridge
> *bridge)
>
> ctx->pre_enabled = false;
>
> + if (ctx->reset_gpio)
> + gpiod_set_value_cansleep(ctx->reset_gpio, 0);
> +
> ret = regulator_disable(ctx->regulator);
> if (ret < 0)
> dev_err(ctx->dev, "error disabling regulators (%d)\n", ret);
> @@ -152,6 +157,11 @@ static void tc358762_pre_enable(struct drm_bridge
> *bridge)
> if (ret < 0)
> dev_err(ctx->dev, "error enabling regulators (%d)\n", ret);
>
> + if (ctx->reset_gpio) {
> + gpiod_set_value_cansleep(ctx->reset_gpio, 1);
> + usleep_range(5000, 1);
> + }
> +
> ret = tc358762_init(ctx);
> if (ret < 0)
> dev_err(ctx->dev, "error initializing bridge (%d)\n", ret);
> @@ -185,6 +195,11 @@ static int tc358762_parse_dt(struct tc358762 *ctx)
>
> ctx->panel_bridge = panel_bridge;
>
> + /* Reset GPIO is optional */
> + ctx->reset_gpio = devm_gpiod_get_optional(dev, "reset",
> GPIOD_OUT_LOW);
> + if (IS_ERR(ctx->reset_gpio))
> + return PTR_ERR(ctx->reset_gpio);
> +
> return 0;
> }
>
> --
> 2.39.2
>
This all looks good, snoozing it for a few days before applying.
Reviewed-by: Robert Foss
Re: [PATCH 32/33] drm/amdkfd: add debug device snapshot operation
Am 2023-05-25 um 13:27 schrieb Jonathan Kim:
Similar to queue snapshot, return an array of device information using
an entry_size check and return.
Unlike queue snapshots, the debugger needs to pass to correct number of
devices that exist. If it fails to do so, the KFD will return the
number of actual devices so that the debugger can make a subsequent
successful call.
v2: add num_xcc to device snapshot and fixup new kfd_node reference
Signed-off-by: Jonathan Kim
Reviewed-by: Felix Kuehling
---
drivers/gpu/drm/amd/amdkfd/kfd_chardev.c | 7 ++-
drivers/gpu/drm/amd/amdkfd/kfd_debug.c | 73
drivers/gpu/drm/amd/amdkfd/kfd_debug.h | 5 ++
3 files changed, 83 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdkfd/kfd_chardev.c
b/drivers/gpu/drm/amd/amdkfd/kfd_chardev.c
index b24a73fd53af..f522325b409b 100644
--- a/drivers/gpu/drm/amd/amdkfd/kfd_chardev.c
+++ b/drivers/gpu/drm/amd/amdkfd/kfd_chardev.c
@@ -3060,8 +3060,11 @@ static int kfd_ioctl_set_debug_trap(struct file *filep,
struct kfd_process *p, v
>queue_snapshot.entry_size);
break;
case KFD_IOC_DBG_TRAP_GET_DEVICE_SNAPSHOT:
- pr_warn("Debug op %i not supported yet\n", args->op);
- r = -EACCES;
+ r = kfd_dbg_trap_device_snapshot(target,
+ args->device_snapshot.exception_mask,
+ (void __user
*)args->device_snapshot.snapshot_buf_ptr,
+ >device_snapshot.num_devices,
+ >device_snapshot.entry_size);
break;
default:
pr_err("Invalid option: %i\n", args->op);
diff --git a/drivers/gpu/drm/amd/amdkfd/kfd_debug.c
b/drivers/gpu/drm/amd/amdkfd/kfd_debug.c
index 24e2b285448a..125274445f43 100644
--- a/drivers/gpu/drm/amd/amdkfd/kfd_debug.c
+++ b/drivers/gpu/drm/amd/amdkfd/kfd_debug.c
@@ -22,6 +22,7 @@
#include "kfd_debug.h"
#include "kfd_device_queue_manager.h"
+#include "kfd_topology.h"
#include
#include
@@ -1010,6 +1011,78 @@ int kfd_dbg_trap_query_exception_info(struct kfd_process *target,
return r;
}
+int kfd_dbg_trap_device_snapshot(struct kfd_process *target,
+ uint64_t exception_clear_mask,
+ void __user *user_info,
+ uint32_t *number_of_device_infos,
+ uint32_t *entry_size)
+{
+ struct kfd_dbg_device_info_entry device_info;
+ uint32_t tmp_entry_size = *entry_size, tmp_num_devices;
+ int i, r = 0;
+
+ if (!(target && user_info && number_of_device_infos && entry_size))
+ return -EINVAL;
+
+ tmp_num_devices = min_t(size_t, *number_of_device_infos,
target->n_pdds);
+ *number_of_device_infos = target->n_pdds;
+ *entry_size = min_t(size_t, *entry_size, sizeof(device_info));
+
+ if (!tmp_num_devices)
+ return 0;
+
+ memset(_info, 0, sizeof(device_info));
+
+ mutex_lock(>event_mutex);
+
+ /* Run over all pdd of the process */
+ for (i = 0; i < tmp_num_devices; i++) {
+ struct kfd_process_device *pdd = target->pdds[i];
+ struct kfd_topology_device *topo_dev =
kfd_topology_device_by_id(pdd->dev->id);
+
+ device_info.gpu_id = pdd->dev->id;
+ device_info.exception_status = pdd->exception_status;
+ device_info.lds_base = pdd->lds_base;
+ device_info.lds_limit = pdd->lds_limit;
+ device_info.scratch_base = pdd->scratch_base;
+ device_info.scratch_limit = pdd->scratch_limit;
+ device_info.gpuvm_base = pdd->gpuvm_base;
+ device_info.gpuvm_limit = pdd->gpuvm_limit;
+ device_info.location_id = topo_dev->node_props.location_id;
+ device_info.vendor_id = topo_dev->node_props.vendor_id;
+ device_info.device_id = topo_dev->node_props.device_id;
+ device_info.revision_id = pdd->dev->adev->pdev->revision;
+ device_info.subsystem_vendor_id =
pdd->dev->adev->pdev->subsystem_vendor;
+ device_info.subsystem_device_id =
pdd->dev->adev->pdev->subsystem_device;
+ device_info.fw_version = pdd->dev->kfd->mec_fw_version;
+ device_info.gfx_target_version =
+ topo_dev->node_props.gfx_target_version;
+ device_info.simd_count = topo_dev->node_props.simd_count;
+ device_info.max_waves_per_simd =
+ topo_dev->node_props.max_waves_per_simd;
+ device_info.array_count = topo_dev->node_props.array_count;
+ device_info.simd_arrays_per_engine =
+ topo_dev->node_props.simd_arrays_per_engine;
+ device_info.num_xcc = NUM_XCC(pdd->dev->xcc_mask);
+ device_info.capability = topo_dev->node_props.capability;
+
Re: [PATCH 28/33] drm/amdkfd: add debug set flags operation
Am 2023-05-25 um 13:27 schrieb Jonathan Kim:
Allow the debugger to set single memory and single ALU operations.
Some exceptions are imprecise (memory violations, address watch) in the
sense that a trap occurs only when the exception interrupt occurs and
not at the non-halting faulty instruction. Trap temporaries 0 & 1 save
the program counter address, which means that these values will not point
to the faulty instruction address but to whenever the interrupt was
raised.
Setting the Single Memory Operations flag will inject an automatic wait
on every memory operation instruction forcing imprecise memory exceptions
to become precise at the cost of performance. This setting is not
permitted on debug devices that support only a global setting of this
option.
Return the previous set flags to the debugger as well.
v2: fixup with new kfd_node struct reference mes checks
Signed-off-by: Jonathan Kim
Reviewed-by: Felix Kuehling
---
drivers/gpu/drm/amd/amdkfd/kfd_chardev.c | 2 +
drivers/gpu/drm/amd/amdkfd/kfd_debug.c | 58
drivers/gpu/drm/amd/amdkfd/kfd_debug.h | 1 +
3 files changed, 61 insertions(+)
diff --git a/drivers/gpu/drm/amd/amdkfd/kfd_chardev.c
b/drivers/gpu/drm/amd/amdkfd/kfd_chardev.c
index e88be582d44d..e5d95b144dcd 100644
--- a/drivers/gpu/drm/amd/amdkfd/kfd_chardev.c
+++ b/drivers/gpu/drm/amd/amdkfd/kfd_chardev.c
@@ -3035,6 +3035,8 @@ static int kfd_ioctl_set_debug_trap(struct file *filep,
struct kfd_process *p, v
args->clear_node_address_watch.id);
break;
case KFD_IOC_DBG_TRAP_SET_FLAGS:
+ r = kfd_dbg_trap_set_flags(target, >set_flags.flags);
+ break;
case KFD_IOC_DBG_TRAP_QUERY_DEBUG_EVENT:
case KFD_IOC_DBG_TRAP_QUERY_EXCEPTION_INFO:
case KFD_IOC_DBG_TRAP_GET_QUEUE_SNAPSHOT:
diff --git a/drivers/gpu/drm/amd/amdkfd/kfd_debug.c
b/drivers/gpu/drm/amd/amdkfd/kfd_debug.c
index 4b36cc8b5fb7..43c3170998d3 100644
--- a/drivers/gpu/drm/amd/amdkfd/kfd_debug.c
+++ b/drivers/gpu/drm/amd/amdkfd/kfd_debug.c
@@ -23,6 +23,7 @@
#include "kfd_debug.h"
#include "kfd_device_queue_manager.h"
#include
+#include
#define MAX_WATCH_ADDRESSES 4
@@ -423,6 +424,59 @@ static void kfd_dbg_clear_process_address_watch(struct kfd_process *target)
kfd_dbg_trap_clear_dev_address_watch(target->pdds[i],
j);
}
+int kfd_dbg_trap_set_flags(struct kfd_process *target, uint32_t *flags)
+{
+ uint32_t prev_flags = target->dbg_flags;
+ int i, r = 0, rewind_count = 0;
+
+ for (i = 0; i < target->n_pdds; i++) {
+ if (!kfd_dbg_is_per_vmid_supported(target->pdds[i]->dev) &&
+ (*flags & KFD_DBG_TRAP_FLAG_SINGLE_MEM_OP)) {
+ *flags = prev_flags;
+ return -EACCES;
+ }
+ }
+
+ target->dbg_flags = *flags & KFD_DBG_TRAP_FLAG_SINGLE_MEM_OP;
+ *flags = prev_flags;
+ for (i = 0; i < target->n_pdds; i++) {
+ struct kfd_process_device *pdd = target->pdds[i];
+
+ if (!kfd_dbg_is_per_vmid_supported(pdd->dev))
+ continue;
+
+ if (!pdd->dev->kfd->shared_resources.enable_mes)
+ r = debug_refresh_runlist(pdd->dev->dqm);
+ else
+ r = kfd_dbg_set_mes_debug_mode(pdd);
+
+ if (r) {
+ target->dbg_flags = prev_flags;
+ break;
+ }
+
+ rewind_count++;
+ }
+
+ /* Rewind flags */
+ if (r) {
+ target->dbg_flags = prev_flags;
+
+ for (i = 0; i < rewind_count; i++) {
+ struct kfd_process_device *pdd = target->pdds[i];
+
+ if (!kfd_dbg_is_per_vmid_supported(pdd->dev))
+ continue;
+
+ if (!pdd->dev->kfd->shared_resources.enable_mes)
+ debug_refresh_runlist(pdd->dev->dqm);
+ else
+ kfd_dbg_set_mes_debug_mode(pdd);
+ }
+ }
+
+ return r;
+}
/* kfd_dbg_trap_deactivate:
*target: target process
@@ -437,9 +491,13 @@ void kfd_dbg_trap_deactivate(struct kfd_process *target,
bool unwind, int unwind
int i;
if (!unwind) {
+ uint32_t flags = 0;
+
cancel_work_sync(>debug_event_workarea);
kfd_dbg_clear_process_address_watch(target);
kfd_dbg_trap_set_wave_launch_mode(target, 0);
+
+ kfd_dbg_trap_set_flags(target, );
}
for (i = 0; i < target->n_pdds; i++) {
diff --git a/drivers/gpu/drm/amd/amdkfd/kfd_debug.h
b/drivers/gpu/drm/amd/amdkfd/kfd_debug.h
index 7f0757c2af2c..ef8e9f7f1716 100644
--- a/drivers/gpu/drm/amd/amdkfd/kfd_debug.h
+++ b/drivers/gpu/drm/amd/amdkfd/kfd_debug.h
@@
Re: [PATCH 27/33] drm/amdkfd: add debug set and clear address watch points operation
Am 2023-05-25 um 13:27 schrieb Jonathan Kim:
Shader read, write and atomic memory operations can be alerted to the
debugger as an address watch exception.
Allow the debugger to pass in a watch point to a particular memory
address per device.
Note that there exists only 4 watch points per devices to date, so have
the KFD keep track of what watch points are allocated or not.
v2: fixup with new kfd_node struct reference for mes and watch point
checks
Signed-off-by: Jonathan Kim
Reviewed-by: Felix Kuehling
---
.../drm/amd/amdgpu/amdgpu_amdkfd_aldebaran.c | 51 +++
.../drm/amd/amdgpu/amdgpu_amdkfd_arcturus.c | 2 +
.../drm/amd/amdgpu/amdgpu_amdkfd_gfx_v10.c| 78 ++
.../drm/amd/amdgpu/amdgpu_amdkfd_gfx_v10.h| 8 ++
.../drm/amd/amdgpu/amdgpu_amdkfd_gfx_v10_3.c | 5 +-
.../drm/amd/amdgpu/amdgpu_amdkfd_gfx_v11.c| 52 ++-
.../gpu/drm/amd/amdgpu/amdgpu_amdkfd_gfx_v9.c | 77 ++
.../gpu/drm/amd/amdgpu/amdgpu_amdkfd_gfx_v9.h | 8 ++
drivers/gpu/drm/amd/amdkfd/kfd_chardev.c | 24
drivers/gpu/drm/amd/amdkfd/kfd_debug.c| 136 ++
drivers/gpu/drm/amd/amdkfd/kfd_debug.h| 8 +-
drivers/gpu/drm/amd/amdkfd/kfd_device.c | 2 +
drivers/gpu/drm/amd/amdkfd/kfd_priv.h | 6 +-
13 files changed, 452 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_aldebaran.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_aldebaran.c
index 774ecfc3451a..efd6a72aab4e 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_aldebaran.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_aldebaran.c
@@ -118,6 +118,55 @@ static uint32_t kgd_aldebaran_set_wave_launch_mode(struct
amdgpu_device *adev,
return data;
}
+#define TCP_WATCH_STRIDE (regTCP_WATCH1_ADDR_H - regTCP_WATCH0_ADDR_H)
+static uint32_t kgd_gfx_aldebaran_set_address_watch(
+ struct amdgpu_device *adev,
+ uint64_t watch_address,
+ uint32_t watch_address_mask,
+ uint32_t watch_id,
+ uint32_t watch_mode,
+ uint32_t debug_vmid)
+{
+ uint32_t watch_address_high;
+ uint32_t watch_address_low;
+ uint32_t watch_address_cntl;
+
+ watch_address_cntl = 0;
+ watch_address_low = lower_32_bits(watch_address);
+ watch_address_high = upper_32_bits(watch_address) & 0x;
+
+ watch_address_cntl = REG_SET_FIELD(watch_address_cntl,
+ TCP_WATCH0_CNTL,
+ MODE,
+ watch_mode);
+
+ watch_address_cntl = REG_SET_FIELD(watch_address_cntl,
+ TCP_WATCH0_CNTL,
+ MASK,
+ watch_address_mask >> 6);
+
+ watch_address_cntl = REG_SET_FIELD(watch_address_cntl,
+ TCP_WATCH0_CNTL,
+ VALID,
+ 1);
+
+ WREG32_RLC((SOC15_REG_OFFSET(GC, 0, regTCP_WATCH0_ADDR_H) +
+ (watch_id * TCP_WATCH_STRIDE)),
+ watch_address_high);
+
+ WREG32_RLC((SOC15_REG_OFFSET(GC, 0, regTCP_WATCH0_ADDR_L) +
+ (watch_id * TCP_WATCH_STRIDE)),
+ watch_address_low);
+
+ return watch_address_cntl;
+}
+
+uint32_t kgd_gfx_aldebaran_clear_address_watch(struct amdgpu_device *adev,
+ uint32_t watch_id)
+{
+ return 0;
+}
+
const struct kfd2kgd_calls aldebaran_kfd2kgd = {
.program_sh_mem_settings = kgd_gfx_v9_program_sh_mem_settings,
.set_pasid_vmid_mapping = kgd_gfx_v9_set_pasid_vmid_mapping,
@@ -141,6 +190,8 @@ const struct kfd2kgd_calls aldebaran_kfd2kgd = {
.validate_trap_override_request =
kgd_aldebaran_validate_trap_override_request,
.set_wave_launch_trap_override =
kgd_aldebaran_set_wave_launch_trap_override,
.set_wave_launch_mode = kgd_aldebaran_set_wave_launch_mode,
+ .set_address_watch = kgd_gfx_aldebaran_set_address_watch,
+ .clear_address_watch = kgd_gfx_aldebaran_clear_address_watch,
.get_iq_wait_times = kgd_gfx_v9_get_iq_wait_times,
.build_grace_period_packet_info =
kgd_gfx_v9_build_grace_period_packet_info,
.program_trap_handler_settings =
kgd_gfx_v9_program_trap_handler_settings,
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_arcturus.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_arcturus.c
index fbdc1b7b1e42..6df215aba4c4 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_arcturus.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_arcturus.c
@@ -413,6 +413,8 @@ const struct kfd2kgd_calls arcturus_kfd2kgd = {
.validate_trap_override_request =
kgd_gfx_v9_validate_trap_override_request,
.set_wave_launch_trap_override =
Re: [PATCH 26/33] drm/amdkfd: add debug suspend and resume process queues operation
Am 2023-05-25 um 13:27 schrieb Jonathan Kim:
In order to inspect waves from the saved context at any point during a
debug session, the debugger must be able to preempt queues to trigger
context save by suspending them.
On queue suspend, the KFD will copy the context save header information
so that the debugger can correctly crawl the appropriate size of the saved
context. The debugger must then also be allowed to resume suspended queues.
A queue that is newly created cannot be suspended because queue ids are
recycled after destruction so the debugger needs to know that this has
occurred. Query functions will be later added that will clear a given
queue of its new queue status.
A queue cannot be destroyed while it is suspended to preserve its saved
context during debugger inspection. Have queue destruction block while
a queue is suspended and unblocked when it is resumed. Likewise, if a
queue is about to be destroyed, it cannot be suspended.
Return the number of queues successfully suspended or resumed along with
a per queue status array where the upper bits per queue status show that
the request was invalid (new/destroyed queue suspend request, missing
queue) or an error occurred (HWS in a fatal state so it can't suspend or
resume queues).
v2: fixup new kfd_node struct reference for mes fw check.
also fixup missing EC_QUEUE_NEW flagging on newly created queue.
Signed-off-by: Jonathan Kim
Reviewed-by: Felix Kuehling
---
drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd.c| 5 +
drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd.h| 1 +
drivers/gpu/drm/amd/amdkfd/kfd_chardev.c | 11 +
drivers/gpu/drm/amd/amdkfd/kfd_debug.c| 7 +
.../drm/amd/amdkfd/kfd_device_queue_manager.c | 447 +-
.../drm/amd/amdkfd/kfd_device_queue_manager.h | 10 +
.../gpu/drm/amd/amdkfd/kfd_mqd_manager_v10.c | 10 +
.../gpu/drm/amd/amdkfd/kfd_mqd_manager_v11.c | 15 +-
.../gpu/drm/amd/amdkfd/kfd_mqd_manager_v9.c | 14 +-
drivers/gpu/drm/amd/amdkfd/kfd_priv.h | 5 +-
.../amd/amdkfd/kfd_process_queue_manager.c| 1 +
11 files changed, 512 insertions(+), 14 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd.c
index 98cd52bb005f..b4fcad0e62f7 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd.c
@@ -772,6 +772,11 @@ bool amdgpu_amdkfd_have_atomics_support(struct
amdgpu_device *adev)
return adev->have_atomics_support;
}
+void amdgpu_amdkfd_debug_mem_fence(struct amdgpu_device *adev)
+{
+ amdgpu_device_flush_hdp(adev, NULL);
+}
+
void amdgpu_amdkfd_ras_poison_consumption_handler(struct amdgpu_device *adev,
bool reset)
{
amdgpu_umc_poison_handler(adev, reset);
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd.h
b/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd.h
index dd740e64e6e1..2d0406bff84e 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd.h
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd.h
@@ -322,6 +322,7 @@ int amdgpu_amdkfd_gpuvm_import_dmabuf(struct amdgpu_device
*adev,
uint64_t *mmap_offset);
int amdgpu_amdkfd_gpuvm_export_dmabuf(struct kgd_mem *mem,
struct dma_buf **dmabuf);
+void amdgpu_amdkfd_debug_mem_fence(struct amdgpu_device *adev);
int amdgpu_amdkfd_get_tile_config(struct amdgpu_device *adev,
struct tile_config *config);
void amdgpu_amdkfd_ras_poison_consumption_handler(struct amdgpu_device *adev,
diff --git a/drivers/gpu/drm/amd/amdkfd/kfd_chardev.c
b/drivers/gpu/drm/amd/amdkfd/kfd_chardev.c
index 4b45d4539d48..adda60273456 100644
--- a/drivers/gpu/drm/amd/amdkfd/kfd_chardev.c
+++ b/drivers/gpu/drm/amd/amdkfd/kfd_chardev.c
@@ -410,6 +410,7 @@ static int kfd_ioctl_create_queue(struct file *filep,
struct kfd_process *p,
pr_debug("Write ptr address == 0x%016llX\n",
args->write_pointer_address);
+ kfd_dbg_ev_raise(KFD_EC_MASK(EC_QUEUE_NEW), p, dev, queue_id, false, NULL, 0);
return 0;
err_create_queue:
@@ -2996,7 +2997,17 @@ static int kfd_ioctl_set_debug_trap(struct file *filep,
struct kfd_process *p, v
args->launch_mode.launch_mode);
break;
case KFD_IOC_DBG_TRAP_SUSPEND_QUEUES:
+ r = suspend_queues(target,
+ args->suspend_queues.num_queues,
+ args->suspend_queues.grace_period,
+ args->suspend_queues.exception_mask,
+ (uint32_t
*)args->suspend_queues.queue_array_ptr);
+
+ break;
case KFD_IOC_DBG_TRAP_RESUME_QUEUES:
+ r = resume_queues(target, args->resume_queues.num_queues,
+ (uint32_t
*)args->resume_queues.queue_array_ptr);
+ break;
case
Re: [PATCH 25/33] drm/amdkfd: add debug wave launch mode operation
Am 2023-05-25 um 13:27 schrieb Jonathan Kim:
Allow the debugger to set wave behaviour on to either normally operate,
halt at launch, trap on every instruction, terminate immediately or
stall on allocation.
v2: fixup with new kfd_node struct reference for mes check
Signed-off-by: Jonathan Kim
Reviewed-by: Felix Kuehling
---
.../drm/amd/amdgpu/amdgpu_amdkfd_aldebaran.c | 12 +++
.../drm/amd/amdgpu/amdgpu_amdkfd_arcturus.c | 1 +
.../drm/amd/amdgpu/amdgpu_amdkfd_gfx_v10.c| 25 +
.../drm/amd/amdgpu/amdgpu_amdkfd_gfx_v10.h| 3 ++
.../drm/amd/amdgpu/amdgpu_amdkfd_gfx_v10_3.c | 3 +-
.../drm/amd/amdgpu/amdgpu_amdkfd_gfx_v11.c| 14 +++-
.../gpu/drm/amd/amdgpu/amdgpu_amdkfd_gfx_v9.c | 25 +
.../gpu/drm/amd/amdgpu/amdgpu_amdkfd_gfx_v9.h | 3 ++
drivers/gpu/drm/amd/amdkfd/kfd_chardev.c | 3 ++
drivers/gpu/drm/amd/amdkfd/kfd_debug.c| 36 ++-
drivers/gpu/drm/amd/amdkfd/kfd_debug.h| 2 ++
11 files changed, 124 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_aldebaran.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_aldebaran.c
index d7881bbd828d..774ecfc3451a 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_aldebaran.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_aldebaran.c
@@ -107,6 +107,17 @@ static uint32_t
kgd_aldebaran_set_wave_launch_trap_override(struct amdgpu_device
return data;
}
+static uint32_t kgd_aldebaran_set_wave_launch_mode(struct amdgpu_device *adev,
+ uint8_t wave_launch_mode,
+ uint32_t vmid)
+{
+ uint32_t data = 0;
+
+ data = REG_SET_FIELD(data, SPI_GDBG_PER_VMID_CNTL, LAUNCH_MODE,
wave_launch_mode);
+
+ return data;
+}
+
const struct kfd2kgd_calls aldebaran_kfd2kgd = {
.program_sh_mem_settings = kgd_gfx_v9_program_sh_mem_settings,
.set_pasid_vmid_mapping = kgd_gfx_v9_set_pasid_vmid_mapping,
@@ -129,6 +140,7 @@ const struct kfd2kgd_calls aldebaran_kfd2kgd = {
.disable_debug_trap = kgd_aldebaran_disable_debug_trap,
.validate_trap_override_request =
kgd_aldebaran_validate_trap_override_request,
.set_wave_launch_trap_override =
kgd_aldebaran_set_wave_launch_trap_override,
+ .set_wave_launch_mode = kgd_aldebaran_set_wave_launch_mode,
.get_iq_wait_times = kgd_gfx_v9_get_iq_wait_times,
.build_grace_period_packet_info =
kgd_gfx_v9_build_grace_period_packet_info,
.program_trap_handler_settings =
kgd_gfx_v9_program_trap_handler_settings,
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_arcturus.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_arcturus.c
index ec2587664001..fbdc1b7b1e42 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_arcturus.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_arcturus.c
@@ -412,6 +412,7 @@ const struct kfd2kgd_calls arcturus_kfd2kgd = {
.disable_debug_trap = kgd_arcturus_disable_debug_trap,
.validate_trap_override_request =
kgd_gfx_v9_validate_trap_override_request,
.set_wave_launch_trap_override =
kgd_gfx_v9_set_wave_launch_trap_override,
+ .set_wave_launch_mode = kgd_gfx_v9_set_wave_launch_mode,
.get_iq_wait_times = kgd_gfx_v9_get_iq_wait_times,
.build_grace_period_packet_info =
kgd_gfx_v9_build_grace_period_packet_info,
.get_cu_occupancy = kgd_gfx_v9_get_cu_occupancy,
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gfx_v10.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gfx_v10.c
index 7ea0362dcab3..a7a6edda557f 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gfx_v10.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gfx_v10.c
@@ -856,6 +856,30 @@ uint32_t kgd_gfx_v10_set_wave_launch_trap_override(struct
amdgpu_device *adev,
return 0;
}
+uint32_t kgd_gfx_v10_set_wave_launch_mode(struct amdgpu_device *adev,
+ uint8_t wave_launch_mode,
+ uint32_t vmid)
+{
+ uint32_t data = 0;
+ bool is_mode_set = !!wave_launch_mode;
+
+ mutex_lock(>grbm_idx_mutex);
+
+ kgd_gfx_v10_set_wave_launch_stall(adev, vmid, true);
+
+ data = REG_SET_FIELD(data, SPI_GDBG_WAVE_CNTL2,
+ VMID_MASK, is_mode_set ? 1 << vmid : 0);
+ data = REG_SET_FIELD(data, SPI_GDBG_WAVE_CNTL2,
+ MODE, is_mode_set ? wave_launch_mode : 0);
+ WREG32(SOC15_REG_OFFSET(GC, 0, mmSPI_GDBG_WAVE_CNTL2), data);
+
+ kgd_gfx_v10_set_wave_launch_stall(adev, vmid, false);
+
+ mutex_unlock(>grbm_idx_mutex);
+
+ return 0;
+}
+
/* kgd_gfx_v10_get_iq_wait_times: Returns the mmCP_IQ_WAIT_TIME1/2 values
* The values read are:
* ib_offload_wait_time -- Wait Count for Indirect Buffer Offloads.
@@ -944,6 +968,7 @@ const struct kfd2kgd_calls gfx_v10_kfd2kgd = {
.disable_debug_trap = kgd_gfx_v10_disable_debug_trap,
Re: [PATCH 24/33] drm/amdkfd: add debug wave launch override operation
Am 2023-05-25 um 13:27 schrieb Jonathan Kim:
This operation allows the debugger to override the enabled HW
exceptions on the device.
On debug devices that only support the debugging of a single process,
the HW exceptions are global and set through the SPI_GDBG_TRAP_MASK
register.
Because they are global, only address watch exceptions are allowed to
be enabled. In other words, the debugger must preserve all non-address
watch exception states in normal mode operation by barring a full
replacement override or a non-address watch override request.
For multi-process debugging, all HW exception overrides are per-VMID so
all exceptions can be overridden or fully replaced.
In order for the debugger to know what is permissible, returned the
supported override mask back to the debugger along with the previously
enable overrides.
v2: fixup with new kfd_node struct reference for mes check
Signed-off-by: Jonathan Kim
Reviewed-by: Felix Kuehling
---
.../drm/amd/amdgpu/amdgpu_amdkfd_aldebaran.c | 47 ++
.../drm/amd/amdgpu/amdgpu_amdkfd_arcturus.c | 2 +
.../drm/amd/amdgpu/amdgpu_amdkfd_gfx_v10.c| 55
.../drm/amd/amdgpu/amdgpu_amdkfd_gfx_v10.h| 10 +++
.../drm/amd/amdgpu/amdgpu_amdkfd_gfx_v10_3.c | 5 +-
.../drm/amd/amdgpu/amdgpu_amdkfd_gfx_v11.c| 87 ++-
.../gpu/drm/amd/amdgpu/amdgpu_amdkfd_gfx_v9.c | 55
.../gpu/drm/amd/amdgpu/amdgpu_amdkfd_gfx_v9.h | 10 +++
drivers/gpu/drm/amd/amdkfd/kfd_chardev.c | 7 ++
drivers/gpu/drm/amd/amdkfd/kfd_debug.c| 69 +++
drivers/gpu/drm/amd/amdkfd/kfd_debug.h| 6 ++
11 files changed, 351 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_aldebaran.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_aldebaran.c
index b811a0985050..d7881bbd828d 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_aldebaran.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_aldebaran.c
@@ -25,6 +25,7 @@
#include "amdgpu_amdkfd_gfx_v9.h"
#include "gc/gc_9_4_2_offset.h"
#include "gc/gc_9_4_2_sh_mask.h"
+#include
/*
* Returns TRAP_EN, EXCP_EN and EXCP_REPLACE.
@@ -62,6 +63,50 @@ static uint32_t kgd_aldebaran_disable_debug_trap(struct
amdgpu_device *adev,
return data;
}
+static int kgd_aldebaran_validate_trap_override_request(struct amdgpu_device *adev,
+ uint32_t trap_override,
+ uint32_t
*trap_mask_supported)
+{
+ *trap_mask_supported &= KFD_DBG_TRAP_MASK_FP_INVALID |
+ KFD_DBG_TRAP_MASK_FP_INPUT_DENORMAL |
+ KFD_DBG_TRAP_MASK_FP_DIVIDE_BY_ZERO |
+ KFD_DBG_TRAP_MASK_FP_OVERFLOW |
+ KFD_DBG_TRAP_MASK_FP_UNDERFLOW |
+ KFD_DBG_TRAP_MASK_FP_INEXACT |
+ KFD_DBG_TRAP_MASK_INT_DIVIDE_BY_ZERO |
+ KFD_DBG_TRAP_MASK_DBG_ADDRESS_WATCH |
+ KFD_DBG_TRAP_MASK_DBG_MEMORY_VIOLATION;
+
+ if (trap_override != KFD_DBG_TRAP_OVERRIDE_OR &&
+ trap_override != KFD_DBG_TRAP_OVERRIDE_REPLACE)
+ return -EPERM;
+
+ return 0;
+}
+
+/* returns TRAP_EN, EXCP_EN and EXCP_RPLACE. */
+static uint32_t kgd_aldebaran_set_wave_launch_trap_override(struct
amdgpu_device *adev,
+ uint32_t vmid,
+ uint32_t trap_override,
+ uint32_t trap_mask_bits,
+ uint32_t trap_mask_request,
+ uint32_t *trap_mask_prev,
+ uint32_t kfd_dbg_trap_cntl_prev)
+
+{
+ uint32_t data = 0;
+
+ *trap_mask_prev = REG_GET_FIELD(kfd_dbg_trap_cntl_prev,
SPI_GDBG_PER_VMID_CNTL, EXCP_EN);
+ trap_mask_bits = (trap_mask_bits & trap_mask_request) |
+ (*trap_mask_prev & ~trap_mask_request);
+
+ data = REG_SET_FIELD(data, SPI_GDBG_PER_VMID_CNTL, TRAP_EN, 1);
+ data = REG_SET_FIELD(data, SPI_GDBG_PER_VMID_CNTL, EXCP_EN,
trap_mask_bits);
+ data = REG_SET_FIELD(data, SPI_GDBG_PER_VMID_CNTL, EXCP_REPLACE,
trap_override);
+
+ return data;
+}
+
const struct kfd2kgd_calls aldebaran_kfd2kgd = {
.program_sh_mem_settings = kgd_gfx_v9_program_sh_mem_settings,
.set_pasid_vmid_mapping = kgd_gfx_v9_set_pasid_vmid_mapping,
@@ -82,6 +127,8 @@ const struct kfd2kgd_calls aldebaran_kfd2kgd = {
.get_cu_occupancy = kgd_gfx_v9_get_cu_occupancy,
.enable_debug_trap = kgd_aldebaran_enable_debug_trap,
.disable_debug_trap = kgd_aldebaran_disable_debug_trap,
+ .validate_trap_override_request =
kgd_aldebaran_validate_trap_override_request,
+ .set_wave_launch_trap_override =
Re: [PATCH] pci/vgaarb: make vga_is_firmware_default() arch independent
On Mon, May 29, 2023 at 11:45:04PM +0800, Sui Jingfeng wrote:
> The vga_is_firmware_default() function will work on non-x86 architectures
> as long as the arch has UEFI GOP support, which passes the firmware
> framebuffer base address and size.
>
> This patch makes the vga_is_firmware_default() function arch-independent.
> This could help the VGAARB subsystem make the right choice for multiple
> GPU systems. Usually an integrated one and a discrete one for desktop
> computers. Depending on the firmware framebuffer being put into which
> GPU's VRAM, VGAARB could inherit the firmware's choice, which in turn,
> is the exact choice of the user.
Is there a system that needs this change? If so, the commit log
should mention it.
It's definitely nice to remove #ifdefs, but it's better if we have an
actual reason and some testing of another arch that makes use of this.
Also, take a look at the git history and match the subject line and
commit log style (prefix, capitalization, imperative voice).
> Signed-off-by: Sui Jingfeng
> ---
> drivers/pci/vgaarb.c | 7 ++-
> 1 file changed, 2 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/pci/vgaarb.c b/drivers/pci/vgaarb.c
> index 5a696078b382..f81b6c54e327 100644
> --- a/drivers/pci/vgaarb.c
> +++ b/drivers/pci/vgaarb.c
> @@ -61,7 +61,6 @@ static bool vga_arbiter_used;
> static DEFINE_SPINLOCK(vga_lock);
> static DECLARE_WAIT_QUEUE_HEAD(vga_wait_queue);
>
> -
> static const char *vga_iostate_to_str(unsigned int iostate)
> {
> /* Ignore VGA_RSRC_IO and VGA_RSRC_MEM */
> @@ -545,7 +544,6 @@ EXPORT_SYMBOL(vga_put);
>
> static bool vga_is_firmware_default(struct pci_dev *pdev)
> {
> -#if defined(CONFIG_X86) || defined(CONFIG_IA64)
> u64 base = screen_info.lfb_base;
> u64 size = screen_info.lfb_size;
> struct resource *r;
> @@ -571,7 +569,7 @@ static bool vga_is_firmware_default(struct pci_dev *pdev)
>
> return true;
> }
> -#endif
> +
> return false;
> }
>
> @@ -865,8 +863,7 @@ static bool vga_arbiter_del_pci_device(struct pci_dev
> *pdev)
> }
>
> /* this is called with the lock */
> -static inline void vga_update_device_decodes(struct vga_device *vgadev,
> - int new_decodes)
> +static void vga_update_device_decodes(struct vga_device *vgadev, int
> new_decodes)
I don't mind removing the "inline" here, but it shouldn't be combined
with the rest of the patch. When it's combined, I can't tell whether
there's a reason we need this change or if it's just a cleanup.
> {
> struct device *dev = >pdev->dev;
> int old_decodes, decodes_removed, decodes_unlocked;
> --
> 2.25.1
>
Re: [PATCH 22/33] drm/amdkfd: update process interrupt handling for debug events
Am 2023-05-25 um 13:27 schrieb Jonathan Kim:
The debugger must be notified by any debugger subscribed exception
that comes from hardware interrupts.
If a debugger session exits, any exceptions it subscribed to may still
have interrupts in the interrupt ring buffer or KGD/KFD pipeline.
To prevent a new session from inheriting stale interrupts, when a new
queue is created, open an interrupt drain and allow the IH ring to drain
from a timestamped checkpoint. Then inject a custom IV so that once
the custom IV is picked up by the KFD, it's safe to close the drain
and proceed with queue creation.
The drain must also be on debug disable as SW interrupts may still
be processed. Drain at this time and clear all the exception status.
The debugger may also not be attached nor subscibed to certain
exceptions so forward them directly to the runtime.
GFX10 also requires its own IV processing, hence the creation of
kfd_int_process_v10.c. This is because the IV from SQ interrupts are
packed into a new continguous format unlike GFX9. To make this clear,
a separate interrupting handling code file was created.
v2: use new kfd_node struct in prototypes.
Signed-off-by: Jonathan Kim
Reviewed-by: Felix Kuehling
---
drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd.c| 16 +
drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd.h| 2 +
drivers/gpu/drm/amd/amdkfd/Makefile | 1 +
drivers/gpu/drm/amd/amdkfd/kfd_debug.c| 84
drivers/gpu/drm/amd/amdkfd/kfd_debug.h| 6 +
drivers/gpu/drm/amd/amdkfd/kfd_device.c | 4 +-
.../gpu/drm/amd/amdkfd/kfd_int_process_v10.c | 405 ++
.../gpu/drm/amd/amdkfd/kfd_int_process_v11.c | 21 +-
.../gpu/drm/amd/amdkfd/kfd_int_process_v9.c | 98 -
drivers/gpu/drm/amd/amdkfd/kfd_priv.h | 12 +
drivers/gpu/drm/amd/amdkfd/kfd_process.c | 47 ++
.../amd/amdkfd/kfd_process_queue_manager.c| 4 +
12 files changed, 680 insertions(+), 20 deletions(-)
create mode 100644 drivers/gpu/drm/amd/amdkfd/kfd_int_process_v10.c
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd.c
index 66f80b9ab0c5..98cd52bb005f 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd.c
@@ -777,6 +777,22 @@ void amdgpu_amdkfd_ras_poison_consumption_handler(struct
amdgpu_device *adev, bo
amdgpu_umc_poison_handler(adev, reset);
}
+int amdgpu_amdkfd_send_close_event_drain_irq(struct amdgpu_device *adev,
+ uint32_t *payload)
+{
+ int ret;
+
+ /* Device or IH ring is not ready so bail. */
+ ret = amdgpu_ih_wait_on_checkpoint_process_ts(adev, >irq.ih);
+ if (ret)
+ return ret;
+
+ /* Send payload to fence KFD interrupts */
+ amdgpu_amdkfd_interrupt(adev, payload);
+
+ return 0;
+}
+
bool amdgpu_amdkfd_ras_query_utcl2_poison_status(struct amdgpu_device *adev)
{
if (adev->gfx.ras && adev->gfx.ras->query_utcl2_poison_status)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd.h
b/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd.h
index 94cc456761e5..dd740e64e6e1 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd.h
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd.h
@@ -250,6 +250,8 @@ int amdgpu_amdkfd_get_xgmi_bandwidth_mbytes(struct
amdgpu_device *dst,
struct amdgpu_device *src,
bool is_min);
int amdgpu_amdkfd_get_pcie_bandwidth_mbytes(struct amdgpu_device *adev, bool
is_min);
+int amdgpu_amdkfd_send_close_event_drain_irq(struct amdgpu_device *adev,
+ uint32_t *payload);
/* Read user wptr from a specified user address space with page fault
* disabled. The memory must be pinned and mapped to the hardware when
diff --git a/drivers/gpu/drm/amd/amdkfd/Makefile
b/drivers/gpu/drm/amd/amdkfd/Makefile
index 747754428073..2ec8f27c5366 100644
--- a/drivers/gpu/drm/amd/amdkfd/Makefile
+++ b/drivers/gpu/drm/amd/amdkfd/Makefile
@@ -53,6 +53,7 @@ AMDKFD_FILES := $(AMDKFD_PATH)/kfd_module.o \
$(AMDKFD_PATH)/kfd_events.o \
$(AMDKFD_PATH)/cik_event_interrupt.o \
$(AMDKFD_PATH)/kfd_int_process_v9.o \
+ $(AMDKFD_PATH)/kfd_int_process_v10.o \
$(AMDKFD_PATH)/kfd_int_process_v11.o \
$(AMDKFD_PATH)/kfd_smi_events.o \
$(AMDKFD_PATH)/kfd_crat.o \
diff --git a/drivers/gpu/drm/amd/amdkfd/kfd_debug.c
b/drivers/gpu/drm/amd/amdkfd/kfd_debug.c
index 17e8e9edccbf..68b657398d41 100644
--- a/drivers/gpu/drm/amd/amdkfd/kfd_debug.c
+++ b/drivers/gpu/drm/amd/amdkfd/kfd_debug.c
@@ -125,6 +125,64 @@ bool kfd_dbg_ev_raise(uint64_t event_mask,
return is_subscribed;
}
+/* set pending event queue entry from ring entry */
+bool kfd_set_dbg_ev_from_interrupt(struct kfd_node *dev,
+
Re: [PATCH 1/2] drm/msm/dpu: drop SSPP register dumpers
On Tue, 30 May 2023 at 20:37, Abhinav Kumar wrote: > > > > On 5/29/2023 2:36 PM, Marijn Suijten wrote: > > On 2023-05-24 12:18:09, Abhinav Kumar wrote: > >> > >> > >> On 5/24/2023 2:48 AM, Marijn Suijten wrote: > >>> On 2023-05-23 13:01:13, Abhinav Kumar wrote: > > > On 5/21/2023 10:21 AM, Dmitry Baryshkov wrote: > > Drop SSPP-specifig debugfs register dumps in favour of using > > debugfs/dri/0/kms or devcoredump. > > > > I did see another series which removes src_blk from the catalog (I am > yet to review that one) . Lets assume that one is fine and this change > will be going on top of that one right? > >>> > >>> It replaces src_blk with directly accessing the blk (non-sub-block) > >>> directly, because they were overlapping anyway. > >>> > The concern I have with this change is that although I do agree that we > should be in favor of using debugfs/dri/0/kms ( i have used it a few > times and it works pretty well ), devcoredump does not have the support > to dump sub-blocks . Something which we should add with priority because > even with DSC blocks with the separation of enc/ctl blocks we need that > like I wrote in one of the responses. > > So the "len" of the blocks having sub-blocks will be ignored in favor of > the len of the sub-blocks. > >>> > >>> The sub-blocks are not always contiguous with their parent block, are > >>> they? It's probably better to print the sub-blocks separately with > >> > >> Yes, not contiguous otherwise we could have just had them in one big range. > >> > >>> clear headers anyway rather than dumping the range parent_blk_base to > >>> max(parent_blk_base+len, parent_blk_base+sblk_base+sblk_len...). > >>> > >>> - Marijn > >> > >> When I meant sub-block support to devcoredump, this is how I visualize > >> them to be printed > >> > >> =SSPP xxx === > >> =SSPP_CSC ===(for SSPP_xxx) > >> =SSPP_QSEED =(for SSPP_xxx) > > > > Yeah something along those lines, though I don't really like the `(for > > SSPP_xxx)` suffix which we should either drop entirely and make the > > "heading" less of a "heading" > > > > I wrote that "for SSPP_xxx" to explain the idea, ofcourse it wont be > part of the print itself. > > Without that, it matches what you have shared below. > > > > = SSPP xxx === > > ... > > - SSPP_CSC --- > > ... > > - SSPP_QSEED - > > ... > > > > And/or inline the numbers: > > > > = SSPP xxx === > > ... > > --- SSPP_xxx_CSC - > > ... > > -- SSPP_xxx_QSEED > > ... I'd prefer this format. It eases grepping. > > > > sure this is also fine with me. > > > Either works, or any other pattern in the title (e.g `SSPP xxx: CSC`) > > that clearly tells the blocks and sub-blocks apart. > > > > - Marijn -- With best wishes Dmitry
Re: [PATCH 20/33] drm/amdkfd: add runtime enable operation
Am 2023-05-25 um 13:27 schrieb Jonathan Kim:
The debugger can attach to a process prior to HSA enablement (i.e.
inferior is spawned by the debugger and attached to immediately before
target process has been enabled for HSA dispatches) or it
can attach to a running target that is already HSA enabled. Either
way, the debugger needs to know the enablement status to know when
it can inspect queues.
For the scenario where the debugger spawns the target process,
it will have to wait for ROCr's runtime enable request from the target.
The runtime enable request will be able to see that its process has been
debug attached. ROCr raises an EC_PROCESS_RUNTIME signal to the
debugger then blocks the target process while waiting the debugger's
response. Once the debugger has received the runtime signal, it will
unblock the target process.
For the scenario where the debugger attaches to a running target
process, ROCr will set the target process' runtime status as enabled so
that on an attach request, the debugger will be able to see this
status and will continue with debug enablement as normal.
A secondary requirement is to conditionally enable the trap tempories only
if the user requests it (env var HSA_ENABLE_DEBUG=1) or if the debugger
attaches with HSA runtime enabled. This is because setting up the trap
temporaries incurs a performance overhead that is unacceptable for
microbench performance in normal mode for certain customers.
In the scenario where the debugger spawns the target process, when ROCr
detects that the debugger has attached during the runtime enable
request, it will enable the trap temporaries before it blocks the target
process while waiting for the debugger to respond.
In the scenario where the debugger attaches to a running target process,
it will enable to trap temporaries itself.
Finally, there is an additional restriction that is required to be
enforced with runtime enable and HW debug mode setting. The debugger must
first ensure that HW debug mode has been enabled before permitting HW debug
mode operations.
With single process debug devices, allowing the debugger to set debug
HW modes prior to trap activation means that debug HW mode setting can
occur before the KFD has reserved the debug VMID (0xf) from the hardware
scheduler's VMID allocation resource pool. This can result in the
hardware scheduler assigning VMID 0xf to a non-debugged process and
having that process inherit debug HW mode settings intended for the
debugged target process instead, which is both incorrect and potentially
fatal for normal mode operation.
With multi process debug devices, allowing the debugger to set debug
HW modes prior to trap activation means that non-debugged processes
migrating to a new VMID could inherit unintended debug settings.
All debug operations that touch HW settings must require trap activation
where trap activation is triggered by both debug attach and runtime
enablement (target has KFD opened and is ready to dispatch work).
v2: fixup with new kfd_node struct reference
Signed-off-by: Jonathan Kim
Reviewed-by: Felix Kuehling
---
drivers/gpu/drm/amd/amdkfd/kfd_chardev.c | 143 ++-
drivers/gpu/drm/amd/amdkfd/kfd_debug.c | 6 +-
drivers/gpu/drm/amd/amdkfd/kfd_debug.h | 4 +
drivers/gpu/drm/amd/amdkfd/kfd_priv.h| 1 +
4 files changed, 150 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdkfd/kfd_chardev.c
b/drivers/gpu/drm/amd/amdkfd/kfd_chardev.c
index ec5a85454192..73cb5abce431 100644
--- a/drivers/gpu/drm/amd/amdkfd/kfd_chardev.c
+++ b/drivers/gpu/drm/amd/amdkfd/kfd_chardev.c
@@ -2738,11 +2738,140 @@ static int kfd_ioctl_criu(struct file *filep, struct
kfd_process *p, void *data)
return ret;
}
-static int kfd_ioctl_runtime_enable(struct file *filep, struct kfd_process *p, void *data)
+static int runtime_enable(struct kfd_process *p, uint64_t r_debug,
+ bool enable_ttmp_setup)
+{
+ int i = 0, ret = 0;
+
+ if (p->is_runtime_retry)
+ goto retry;
+
+ if (p->runtime_info.runtime_state != DEBUG_RUNTIME_STATE_DISABLED)
+ return -EBUSY;
+
+ for (i = 0; i < p->n_pdds; i++) {
+ struct kfd_process_device *pdd = p->pdds[i];
+
+ if (pdd->qpd.queue_count)
+ return -EEXIST;
+ }
+
+ p->runtime_info.runtime_state = DEBUG_RUNTIME_STATE_ENABLED;
+ p->runtime_info.r_debug = r_debug;
+ p->runtime_info.ttmp_setup = enable_ttmp_setup;
+
+ if (p->runtime_info.ttmp_setup) {
+ for (i = 0; i < p->n_pdds; i++) {
+ struct kfd_process_device *pdd = p->pdds[i];
+
+ if (!kfd_dbg_is_rlc_restore_supported(pdd->dev)) {
+ amdgpu_gfx_off_ctrl(pdd->dev->adev, false);
+ pdd->dev->kfd2kgd->enable_debug_trap(
+ pdd->dev->adev,
+
Re: [PATCH 2/2] drm/panel: Add driver for Visionox r66451 panel
On 5/18/2023 3:17 PM, Jessica Zhang wrote:
On 5/17/2023 5:19 PM, Dmitry Baryshkov wrote:
On 16/05/2023 23:20, Jessica Zhang wrote:
Add support for the 1080x2340 Visionox R66451 AMOLED DSI panel that
comes with the Qualcomm HDK8350 display expansion pack.
The panel enables display compression (DSC v1.2) by default.
Signed-off-by: Jessica Zhang
---
drivers/gpu/drm/panel/Kconfig | 8 +
drivers/gpu/drm/panel/Makefile | 1 +
drivers/gpu/drm/panel/panel-visionox-r66451.c | 395
++
3 files changed, 404 insertions(+)
diff --git a/drivers/gpu/drm/panel/Kconfig
b/drivers/gpu/drm/panel/Kconfig
index 29cf5fa39ff2..9c2c36dbddf3 100644
--- a/drivers/gpu/drm/panel/Kconfig
+++ b/drivers/gpu/drm/panel/Kconfig
@@ -766,6 +766,14 @@ config DRM_PANEL_VISIONOX_VTDR6130
Say Y here if you want to enable support for Visionox
VTDR6130 1080x2400 AMOLED DSI panel.
+config DRM_PANEL_VISIONOX_R66451
+ tristate "Visionox R66451"
+ depends on OF
+ depends on DRM_MIPI_DSI
+ help
+ Say Y here if you want to enable support for Visionox
+ R66451 1080x2340 AMOLED DSI panel.
+
config DRM_PANEL_WIDECHIPS_WS2401
tristate "Widechips WS2401 DPI panel driver"
depends on SPI && GPIOLIB
diff --git a/drivers/gpu/drm/panel/Makefile
b/drivers/gpu/drm/panel/Makefile
index b3e8ba29edd3..e043a92ee676 100644
--- a/drivers/gpu/drm/panel/Makefile
+++ b/drivers/gpu/drm/panel/Makefile
@@ -78,5 +78,6 @@ obj-$(CONFIG_DRM_PANEL_TPO_TPG110) +=
panel-tpo-tpg110.o
obj-$(CONFIG_DRM_PANEL_TRULY_NT35597_WQXGA) += panel-truly-nt35597.o
obj-$(CONFIG_DRM_PANEL_VISIONOX_RM69299) += panel-visionox-rm69299.o
obj-$(CONFIG_DRM_PANEL_VISIONOX_VTDR6130) += panel-visionox-vtdr6130.o
+obj-$(CONFIG_DRM_PANEL_VISIONOX_R66451) += panel-visionox-r66451.o
obj-$(CONFIG_DRM_PANEL_WIDECHIPS_WS2401) += panel-widechips-ws2401.o
obj-$(CONFIG_DRM_PANEL_XINPENG_XPP055C272) +=
panel-xinpeng-xpp055c272.o
diff --git a/drivers/gpu/drm/panel/panel-visionox-r66451.c
b/drivers/gpu/drm/panel/panel-visionox-r66451.c
new file mode 100644
index ..e3648ead3e84
--- /dev/null
+++ b/drivers/gpu/drm/panel/panel-visionox-r66451.c
@@ -0,0 +1,395 @@
+//SPDX-License-Identifier: GPL-2.0-only
+//Copyright (c) 2023 Qualcomm Innovation Center, Inc. All rights
reserved.
+
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include
+#include
+#include
+#include
+#include
+
+#include
+
+struct visionox_r66451 {
+ struct drm_panel panel;
+ struct mipi_dsi_device *dsi;
+ struct gpio_desc *reset_gpio;
+ struct regulator_bulk_data supplies[2];
+ bool prepared, enabled;
+};
+
+static inline struct visionox_r66451 *to_visionox_r66451(struct
drm_panel *panel)
+{
+ return container_of(panel, struct visionox_r66451, panel);
+}
+
+static void visionox_r66451_reset(struct visionox_r66451 *ctx)
+{
+ gpiod_set_value_cansleep(ctx->reset_gpio, 0);
+ usleep_range(1, 10100);
+ gpiod_set_value_cansleep(ctx->reset_gpio, 1);
+ usleep_range(1, 10100);
+ gpiod_set_value_cansleep(ctx->reset_gpio, 0);
+ usleep_range(1, 10100);
+}
+
+static int visionox_r66451_on(struct visionox_r66451 *ctx)
+{
+ struct mipi_dsi_device *dsi = ctx->dsi;
+ struct device *dev = >dev;
+ int ret;
+
+ dsi->mode_flags |= MIPI_DSI_MODE_LPM;
+
+ mipi_dsi_dcs_write_seq(dsi, 0xb0, 0x00);
+ mipi_dsi_dcs_write_seq(dsi, 0xc2,
+ 0x09, 0x24, 0x0c, 0x00, 0x00, 0x0c, 0x00, 0x00,
0x00,
+ 0x09, 0x3c);
+ mipi_dsi_dcs_write_seq(dsi, 0xd7,
+ 0x00, 0xb9, 0x3c, 0x00, 0x40, 0x04, 0x00, 0xa0,
0x0a,
+ 0x00, 0x40, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
0x19,
+ 0x3c, 0x00, 0x40, 0x04, 0x00, 0xa0, 0x0a);
+ mipi_dsi_dcs_write_seq(dsi, 0xb0, 0x80);
+ mipi_dsi_dcs_write_seq(dsi, 0xde,
+ 0x40, 0x00, 0x18, 0x00, 0x18, 0x00, 0x18, 0x00,
0x18,
+ 0x10, 0x00, 0x18, 0x00, 0x18, 0x00, 0x18, 0x02,
0x00, 0x00);
+ mipi_dsi_dcs_write_seq(dsi, 0xb0, 0x04);
+ mipi_dsi_dcs_write_seq(dsi, 0xe8, 0x00, 0x02);
+ mipi_dsi_dcs_write_seq(dsi, 0xe4, 0x00, 0x08);
+ mipi_dsi_dcs_write_seq(dsi, 0xb0, 0x00);
+ mipi_dsi_dcs_write_seq(dsi, 0xc4,
+ 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
0x00,
+ 0x00, 0x00, 0x02, 0x00, 0x00, 0x00, 0x32);
+ mipi_dsi_dcs_write_seq(dsi, 0xcf,
+ 0x64, 0x0b, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
0x08,
+ 0x00, 0x0b, 0x77, 0x01, 0x01, 0x01, 0x01, 0x01,
0x01,
+ 0x02, 0x02, 0x02, 0x02, 0x02, 0x03);
+ mipi_dsi_dcs_write_seq(dsi, 0xd3,
+ 0x45, 0x00, 0x00, 0x01, 0x13, 0x15, 0x00, 0x15,
0x07,
+ 0x0f, 0x77, 0x77, 0x77, 0x37, 0xb2, 0x11, 0x00,
0xa0,
+ 0x3c, 0x9c);
+ mipi_dsi_dcs_write_seq(dsi, 0xd7,
+ 0x00, 0xb9, 0x34,
Re: [PATCH 18/33] drm/amdkfd: add raise exception event function
Am 2023-05-25 um 13:27 schrieb Jonathan Kim:
Exception events can be generated from interrupts or queue activitity.
The raise event function will save exception status of a queue, device
or process then notify the debugger of the status change by writing to
a debugger polled file descriptor that the debugger provides during
debug attach.
For memory violation exceptions, extra exception data will be saved.
The debugger will be able to query the saved exception states by query
operation that will be provided by follow up patches.
v2: use new kfd_node struct in prototype.
Signed-off-by: Jonathan Kim
Reviewed-by: Felix Kuehling
---
drivers/gpu/drm/amd/amdkfd/kfd_debug.c | 104 +++
drivers/gpu/drm/amd/amdkfd/kfd_debug.h | 7 ++
drivers/gpu/drm/amd/amdkfd/kfd_priv.h| 10 +++
drivers/gpu/drm/amd/amdkfd/kfd_process.c | 2 +
4 files changed, 123 insertions(+)
diff --git a/drivers/gpu/drm/amd/amdkfd/kfd_debug.c
b/drivers/gpu/drm/amd/amdkfd/kfd_debug.c
index 5e2ee2d1acc4..dccb27fc764b 100644
--- a/drivers/gpu/drm/amd/amdkfd/kfd_debug.c
+++ b/drivers/gpu/drm/amd/amdkfd/kfd_debug.c
@@ -24,6 +24,107 @@
#include "kfd_device_queue_manager.h"
#include
+void debug_event_write_work_handler(struct work_struct *work)
+{
+ struct kfd_process *process;
+
+ static const char write_data = '.';
+ loff_t pos = 0;
+
+ process = container_of(work,
+ struct kfd_process,
+ debug_event_workarea);
+
+ kernel_write(process->dbg_ev_file, _data, 1, );
+}
+
+/* update process/device/queue exception status, write to descriptor
+ * only if exception_status is enabled.
+ */
+bool kfd_dbg_ev_raise(uint64_t event_mask,
+ struct kfd_process *process, struct kfd_node *dev,
+ unsigned int source_id, bool use_worker,
+ void *exception_data, size_t exception_data_size)
+{
+ struct process_queue_manager *pqm;
+ struct process_queue_node *pqn;
+ int i;
+ static const char write_data = '.';
+ loff_t pos = 0;
+ bool is_subscribed = true;
+
+ if (!(process && process->debug_trap_enabled))
+ return false;
+
+ mutex_lock(>event_mutex);
+
+ if (event_mask & KFD_EC_MASK_DEVICE) {
+ for (i = 0; i < process->n_pdds; i++) {
+ struct kfd_process_device *pdd = process->pdds[i];
+
+ if (pdd->dev != dev)
+ continue;
+
+ pdd->exception_status |= event_mask &
KFD_EC_MASK_DEVICE;
+
+ if (event_mask &
KFD_EC_MASK(EC_DEVICE_MEMORY_VIOLATION)) {
+ if (!pdd->vm_fault_exc_data) {
+ pdd->vm_fault_exc_data = kmemdup(
+ exception_data,
+ exception_data_size,
+ GFP_KERNEL);
+ if (!pdd->vm_fault_exc_data)
+ pr_debug("Failed to allocate
exception data memory");
+ } else {
+ pr_debug("Debugger exception data not
saved\n");
+ print_hex_dump_bytes("exception data: ",
+ DUMP_PREFIX_OFFSET,
+ exception_data,
+ exception_data_size);
+ }
+ }
+ break;
+ }
+ } else if (event_mask & KFD_EC_MASK_PROCESS) {
+ process->exception_status |= event_mask & KFD_EC_MASK_PROCESS;
+ } else {
+ pqm = >pqm;
+ list_for_each_entry(pqn, >queues,
+ process_queue_list) {
+ int target_id;
+
+ if (!pqn->q)
+ continue;
+
+ target_id = event_mask & KFD_EC_MASK(EC_QUEUE_NEW) ?
+ pqn->q->properties.queue_id :
+ pqn->q->doorbell_id;
+
+ if (pqn->q->device != dev || target_id != source_id)
+ continue;
+
+ pqn->q->properties.exception_status |= event_mask;
+ break;
+ }
+ }
+
+ if (process->exception_enable_mask & event_mask) {
+ if (use_worker)
+ schedule_work(>debug_event_workarea);
+ else
+ kernel_write(process->dbg_ev_file,
+ _data,
+
Re: [PATCH 16/33] drm/amdkfd: add per process hw trap enable and disable functions
Am 2023-05-25 um 13:27 schrieb Jonathan Kim:
To enable HW debug mode per process, all devices must be debug enabled
successfully. If a failure occures, rewind the enablement of debug mode
on the enabled devices.
A power management scenario that needs to be considered is HW
debug mode setting during GFXOFF. During GFXOFF, these registers
will be unreachable so we have to transiently disable GFXOFF when
setting. Also, some devices don't support the RLC save restore
function for these debug registers so we have to disable GFXOFF
completely during a debug session.
Cooperative launch also has debugging restriction based on HW/FW bugs.
If such bugs exists, the debugger cannot attach to a process that uses GWS
resources nor can GWS resources be requested if a process is being
debugged.
Multi-process debug devices can only enable trap temporaries based
on certain runtime scenerios, which will be explained when the
runtime enable functions are implemented in a follow up patch.
v2: spot fix with new kfd_node references
Signed-off-by: Jonathan Kim
Reviewed-by: Felix Kuehling
---
drivers/gpu/drm/amd/amdkfd/kfd_chardev.c | 5 +
drivers/gpu/drm/amd/amdkfd/kfd_debug.c | 148 ++-
drivers/gpu/drm/amd/amdkfd/kfd_debug.h | 29 +
drivers/gpu/drm/amd/amdkfd/kfd_process.c | 10 ++
4 files changed, 190 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdkfd/kfd_chardev.c
b/drivers/gpu/drm/amd/amdkfd/kfd_chardev.c
index 7082d5d0f0e9..9d0c247f80fe 100644
--- a/drivers/gpu/drm/amd/amdkfd/kfd_chardev.c
+++ b/drivers/gpu/drm/amd/amdkfd/kfd_chardev.c
@@ -1488,6 +1488,11 @@ static int kfd_ioctl_alloc_queue_gws(struct file *filep,
goto out_unlock;
}
+ if (!kfd_dbg_has_gws_support(dev) && p->debug_trap_enabled) {
+ retval = -EBUSY;
+ goto out_unlock;
+ }
+
retval = pqm_set_gws(>pqm, args->queue_id, args->num_gws ? dev->gws
: NULL);
mutex_unlock(>mutex);
diff --git a/drivers/gpu/drm/amd/amdkfd/kfd_debug.c b/drivers/gpu/drm/amd/amdkfd/kfd_debug.c
index 898cc1fe3d13..73b07b5f17f1 100644
--- a/drivers/gpu/drm/amd/amdkfd/kfd_debug.c
+++ b/drivers/gpu/drm/amd/amdkfd/kfd_debug.c
@@ -21,13 +21,78 @@
*/
#include "kfd_debug.h"
+#include "kfd_device_queue_manager.h"
#include
+static int kfd_dbg_set_mes_debug_mode(struct kfd_process_device *pdd)
+{
+ uint32_t spi_dbg_cntl = pdd->spi_dbg_override |
pdd->spi_dbg_launch_mode;
+ uint32_t flags = pdd->process->dbg_flags;
+
+ if (!kfd_dbg_is_per_vmid_supported(pdd->dev))
+ return 0;
+
+ return amdgpu_mes_set_shader_debugger(pdd->dev->adev,
pdd->proc_ctx_gpu_addr, spi_dbg_cntl,
+ pdd->watch_points, flags);
+}
+
+/* kfd_dbg_trap_deactivate:
+ * target: target process
+ * unwind: If this is unwinding a failed kfd_dbg_trap_enable()
+ * unwind_count:
+ * If unwind == true, how far down the pdd list we need
+ * to unwind
+ * else: ignored
+ */
+static void kfd_dbg_trap_deactivate(struct kfd_process *target, bool unwind,
int unwind_count)
+{
+ int i;
+
+ for (i = 0; i < target->n_pdds; i++) {
+ struct kfd_process_device *pdd = target->pdds[i];
+
+ /* If this is an unwind, and we have unwound the required
+* enable calls on the pdd list, we need to stop now
+* otherwise we may mess up another debugger session.
+*/
+ if (unwind && i == unwind_count)
+ break;
+
+ /* GFX off is already disabled by debug activate if not RLC
restore supported. */
+ if (kfd_dbg_is_rlc_restore_supported(pdd->dev))
+ amdgpu_gfx_off_ctrl(pdd->dev->adev, false);
+ pdd->spi_dbg_override =
+ pdd->dev->kfd2kgd->disable_debug_trap(
+ pdd->dev->adev,
+ target->runtime_info.ttmp_setup,
+ pdd->dev->vm_info.last_vmid_kfd);
+ amdgpu_gfx_off_ctrl(pdd->dev->adev, true);
+
+ if (!kfd_dbg_is_per_vmid_supported(pdd->dev) &&
+ release_debug_trap_vmid(pdd->dev->dqm,
>qpd))
+ pr_err("Failed to release debug vmid on [%i]\n",
pdd->dev->id);
+
+ if (!pdd->dev->kfd->shared_resources.enable_mes)
+ debug_refresh_runlist(pdd->dev->dqm);
+ else
+ kfd_dbg_set_mes_debug_mode(pdd);
+ }
+}
+
int kfd_dbg_trap_disable(struct kfd_process *target)
{
if (!target->debug_trap_enabled)
return 0;
+ /*
+* Defer deactivation to runtime if runtime not enabled otherwise reset
+* attached running target runtime state to enable for re-attach.
+*/
+
RE: [PATCH 14/33] drm/amdgpu: prepare map process for multi-process debug devices
[Public]
> -Original Message-
> From: Kuehling, Felix
> Sent: Tuesday, May 30, 2023 3:56 PM
> To: Kim, Jonathan ; amd-
> g...@lists.freedesktop.org; dri-devel@lists.freedesktop.org
> Cc: Huang, JinHuiEric
> Subject: Re: [PATCH 14/33] drm/amdgpu: prepare map process for multi-
> process debug devices
>
> Am 2023-05-25 um 13:27 schrieb Jonathan Kim:
> > Unlike single process debug devices, multi-process debug devices allow
> > debug mode setting per-VMID (non-device-global).
> >
> > Because the HWS manages PASID-VMID mapping, the new MAP_PROCESS
> API allows
> > the KFD to forward the required SPI debug register write requests.
> >
> > To request a new debug mode setting change, the KFD must be able to
> > preempt all queues then remap all queues with these new setting
> > requests for MAP_PROCESS to take effect.
> >
> > Note that by default, trap enablement in non-debug mode must be
> disabled
> > for performance reasons for multi-process debug devices due to setup
> > overhead in FW.
> >
> > v2: spot fixup new kfd_node references
> >
> > Signed-off-by: Jonathan Kim
> > ---
> > drivers/gpu/drm/amd/amdkfd/kfd_debug.h| 5 ++
> > .../drm/amd/amdkfd/kfd_device_queue_manager.c | 51
> +++
> > .../drm/amd/amdkfd/kfd_device_queue_manager.h | 3 ++
> > .../drm/amd/amdkfd/kfd_packet_manager_v9.c| 14 +
> > drivers/gpu/drm/amd/amdkfd/kfd_priv.h | 9
> > drivers/gpu/drm/amd/amdkfd/kfd_process.c | 5 ++
> > 6 files changed, 87 insertions(+)
> >
> > diff --git a/drivers/gpu/drm/amd/amdkfd/kfd_debug.h
> b/drivers/gpu/drm/amd/amdkfd/kfd_debug.h
> > index a8abfe2a0a14..db6d72e7930f 100644
> > --- a/drivers/gpu/drm/amd/amdkfd/kfd_debug.h
> > +++ b/drivers/gpu/drm/amd/amdkfd/kfd_debug.h
> > @@ -29,4 +29,9 @@ int kfd_dbg_trap_disable(struct kfd_process *target);
> > int kfd_dbg_trap_enable(struct kfd_process *target, uint32_t fd,
> > void __user *runtime_info,
> > uint32_t *runtime_info_size);
> > +static inline bool kfd_dbg_is_per_vmid_supported(struct kfd_node *dev)
> > +{
> > + return KFD_GC_VERSION(dev) == IP_VERSION(9, 4, 2);
>
> This needs to be updated to include 9.4.3 as well. Is that coming in a
> different patch? Other than that, this patch is
That's correct. This series does not enable the debugger for GFX9.4.3.
This will be a follow-up series that Eric will provide.
Thanks.
Jon
>
> Reviewed-by: Felix Kuehling
>
>
> > +}
> > +
> > #endif
> > diff --git a/drivers/gpu/drm/amd/amdkfd/kfd_device_queue_manager.c
> b/drivers/gpu/drm/amd/amdkfd/kfd_device_queue_manager.c
> > index c8519adc89ac..badfe1210bc4 100644
> > --- a/drivers/gpu/drm/amd/amdkfd/kfd_device_queue_manager.c
> > +++ b/drivers/gpu/drm/amd/amdkfd/kfd_device_queue_manager.c
> > @@ -36,6 +36,7 @@
> > #include "kfd_kernel_queue.h"
> > #include "amdgpu_amdkfd.h"
> > #include "mes_api_def.h"
> > +#include "kfd_debug.h"
> >
> > /* Size of the per-pipe EOP queue */
> > #define CIK_HPD_EOP_BYTES_LOG2 11
> > @@ -2593,6 +2594,56 @@ int release_debug_trap_vmid(struct
> device_queue_manager *dqm,
> > return r;
> > }
> >
> > +int debug_lock_and_unmap(struct device_queue_manager *dqm)
> > +{
> > + int r;
> > +
> > + if (dqm->sched_policy == KFD_SCHED_POLICY_NO_HWS) {
> > + pr_err("Unsupported on sched_policy: %i\n", dqm-
> >sched_policy);
> > + return -EINVAL;
> > + }
> > +
> > + if (!kfd_dbg_is_per_vmid_supported(dqm->dev))
> > + return 0;
> > +
> > + dqm_lock(dqm);
> > +
> > + r = unmap_queues_cpsch(dqm,
> KFD_UNMAP_QUEUES_FILTER_ALL_QUEUES, 0, 0, false);
> > + if (r)
> > + dqm_unlock(dqm);
> > +
> > + return r;
> > +}
> > +
> > +int debug_map_and_unlock(struct device_queue_manager *dqm)
> > +{
> > + int r;
> > +
> > + if (dqm->sched_policy == KFD_SCHED_POLICY_NO_HWS) {
> > + pr_err("Unsupported on sched_policy: %i\n", dqm-
> >sched_policy);
> > + return -EINVAL;
> > + }
> > +
> > + if (!kfd_dbg_is_per_vmid_supported(dqm->dev))
> > + return 0;
> > +
> > + r = map_queues_cpsch(dqm);
> > +
> > + dqm_unlock(dqm);
> > +
> > + return r;
> > +}
> > +
> > +int debug_refresh_runlist(struct device_queue_manager *dqm)
> > +{
> > + int r = debug_lock_and_unmap(dqm);
> > +
> > + if (r)
> > + return r;
> > +
> > + return debug_map_and_unlock(dqm);
> > +}
> > +
> > #if defined(CONFIG_DEBUG_FS)
> >
> > static void seq_reg_dump(struct seq_file *m,
> > diff --git a/drivers/gpu/drm/amd/amdkfd/kfd_device_queue_manager.h
> b/drivers/gpu/drm/amd/amdkfd/kfd_device_queue_manager.h
> > index bf7aa3f84182..bb75d93712eb 100644
> > --- a/drivers/gpu/drm/amd/amdkfd/kfd_device_queue_manager.h
> > +++ b/drivers/gpu/drm/amd/amdkfd/kfd_device_queue_manager.h
> > @@ -290,6 +290,9 @@ int reserve_debug_trap_vmid(struct
> device_queue_manager *dqm,
> > struct qcm_process_device *qpd);
> > int release_debug_trap_vmid(struct
Re: [PATCH 14/33] drm/amdgpu: prepare map process for multi-process debug devices
Am 2023-05-25 um 13:27 schrieb Jonathan Kim:
Unlike single process debug devices, multi-process debug devices allow
debug mode setting per-VMID (non-device-global).
Because the HWS manages PASID-VMID mapping, the new MAP_PROCESS API allows
the KFD to forward the required SPI debug register write requests.
To request a new debug mode setting change, the KFD must be able to
preempt all queues then remap all queues with these new setting
requests for MAP_PROCESS to take effect.
Note that by default, trap enablement in non-debug mode must be disabled
for performance reasons for multi-process debug devices due to setup
overhead in FW.
v2: spot fixup new kfd_node references
Signed-off-by: Jonathan Kim
---
drivers/gpu/drm/amd/amdkfd/kfd_debug.h| 5 ++
.../drm/amd/amdkfd/kfd_device_queue_manager.c | 51 +++
.../drm/amd/amdkfd/kfd_device_queue_manager.h | 3 ++
.../drm/amd/amdkfd/kfd_packet_manager_v9.c| 14 +
drivers/gpu/drm/amd/amdkfd/kfd_priv.h | 9
drivers/gpu/drm/amd/amdkfd/kfd_process.c | 5 ++
6 files changed, 87 insertions(+)
diff --git a/drivers/gpu/drm/amd/amdkfd/kfd_debug.h
b/drivers/gpu/drm/amd/amdkfd/kfd_debug.h
index a8abfe2a0a14..db6d72e7930f 100644
--- a/drivers/gpu/drm/amd/amdkfd/kfd_debug.h
+++ b/drivers/gpu/drm/amd/amdkfd/kfd_debug.h
@@ -29,4 +29,9 @@ int kfd_dbg_trap_disable(struct kfd_process *target);
int kfd_dbg_trap_enable(struct kfd_process *target, uint32_t fd,
void __user *runtime_info,
uint32_t *runtime_info_size);
+static inline bool kfd_dbg_is_per_vmid_supported(struct kfd_node *dev)
+{
+ return KFD_GC_VERSION(dev) == IP_VERSION(9, 4, 2);
This needs to be updated to include 9.4.3 as well. Is that coming in a
different patch? Other than that, this patch is
Reviewed-by: Felix Kuehling
+}
+
#endif
diff --git a/drivers/gpu/drm/amd/amdkfd/kfd_device_queue_manager.c
b/drivers/gpu/drm/amd/amdkfd/kfd_device_queue_manager.c
index c8519adc89ac..badfe1210bc4 100644
--- a/drivers/gpu/drm/amd/amdkfd/kfd_device_queue_manager.c
+++ b/drivers/gpu/drm/amd/amdkfd/kfd_device_queue_manager.c
@@ -36,6 +36,7 @@
#include "kfd_kernel_queue.h"
#include "amdgpu_amdkfd.h"
#include "mes_api_def.h"
+#include "kfd_debug.h"
/* Size of the per-pipe EOP queue */
#define CIK_HPD_EOP_BYTES_LOG2 11
@@ -2593,6 +2594,56 @@ int release_debug_trap_vmid(struct device_queue_manager
*dqm,
return r;
}
+int debug_lock_and_unmap(struct device_queue_manager *dqm)
+{
+ int r;
+
+ if (dqm->sched_policy == KFD_SCHED_POLICY_NO_HWS) {
+ pr_err("Unsupported on sched_policy: %i\n", dqm->sched_policy);
+ return -EINVAL;
+ }
+
+ if (!kfd_dbg_is_per_vmid_supported(dqm->dev))
+ return 0;
+
+ dqm_lock(dqm);
+
+ r = unmap_queues_cpsch(dqm, KFD_UNMAP_QUEUES_FILTER_ALL_QUEUES, 0, 0,
false);
+ if (r)
+ dqm_unlock(dqm);
+
+ return r;
+}
+
+int debug_map_and_unlock(struct device_queue_manager *dqm)
+{
+ int r;
+
+ if (dqm->sched_policy == KFD_SCHED_POLICY_NO_HWS) {
+ pr_err("Unsupported on sched_policy: %i\n", dqm->sched_policy);
+ return -EINVAL;
+ }
+
+ if (!kfd_dbg_is_per_vmid_supported(dqm->dev))
+ return 0;
+
+ r = map_queues_cpsch(dqm);
+
+ dqm_unlock(dqm);
+
+ return r;
+}
+
+int debug_refresh_runlist(struct device_queue_manager *dqm)
+{
+ int r = debug_lock_and_unmap(dqm);
+
+ if (r)
+ return r;
+
+ return debug_map_and_unlock(dqm);
+}
+
#if defined(CONFIG_DEBUG_FS)
static void seq_reg_dump(struct seq_file *m,
diff --git a/drivers/gpu/drm/amd/amdkfd/kfd_device_queue_manager.h
b/drivers/gpu/drm/amd/amdkfd/kfd_device_queue_manager.h
index bf7aa3f84182..bb75d93712eb 100644
--- a/drivers/gpu/drm/amd/amdkfd/kfd_device_queue_manager.h
+++ b/drivers/gpu/drm/amd/amdkfd/kfd_device_queue_manager.h
@@ -290,6 +290,9 @@ int reserve_debug_trap_vmid(struct device_queue_manager
*dqm,
struct qcm_process_device *qpd);
int release_debug_trap_vmid(struct device_queue_manager *dqm,
struct qcm_process_device *qpd);
+int debug_lock_and_unmap(struct device_queue_manager *dqm);
+int debug_map_and_unlock(struct device_queue_manager *dqm);
+int debug_refresh_runlist(struct device_queue_manager *dqm);
static inline unsigned int get_sh_mem_bases_32(struct kfd_process_device *pdd)
{
diff --git a/drivers/gpu/drm/amd/amdkfd/kfd_packet_manager_v9.c
b/drivers/gpu/drm/amd/amdkfd/kfd_packet_manager_v9.c
index 0fe73dbd28af..29a2d0499b67 100644
--- a/drivers/gpu/drm/amd/amdkfd/kfd_packet_manager_v9.c
+++ b/drivers/gpu/drm/amd/amdkfd/kfd_packet_manager_v9.c
@@ -88,6 +88,10 @@ static int pm_map_process_aldebaran(struct packet_manager
*pm,
{
struct pm4_mes_map_process_aldebaran *packet;
uint64_t
Re: [PATCH 9/9] drm/amd/pm: enable Wifi RFI mitigation feature support for SMU13.0.7
Hi Evan, kernel test robot noticed the following build errors: [auto build test ERROR on drm-misc/drm-misc-next] [also build test ERROR on kvalo-ath/ath-next wireless-next/main wireless/main] [cannot apply to linus/master v6.4-rc4 next-20230530] [If your patch is applied to the wrong git tree, kindly drop us a note. And when submitting patch, we suggest to use '--base' as documented in https://git-scm.com/docs/git-format-patch#_base_tree_information] url: https://github.com/intel-lab-lkp/linux/commits/Evan-Quan/drivers-acpi-Add-support-for-Wifi-band-RF-mitigations/20230530-104541 base: git://anongit.freedesktop.org/drm/drm-misc drm-misc-next patch link: https://lore.kernel.org/r/20230530024227.2139632-10-evan.quan%40amd.com patch subject: [PATCH 9/9] drm/amd/pm: enable Wifi RFI mitigation feature support for SMU13.0.7 config: arm-allyesconfig (https://download.01.org/0day-ci/archive/20230531/202305310314.eamx2aee-...@intel.com/config) compiler: arm-linux-gnueabi-gcc (GCC) 12.3.0 reproduce (this is a W=1 build): mkdir -p ~/bin wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross chmod +x ~/bin/make.cross # https://github.com/intel-lab-lkp/linux/commit/8c935eeab7a439739f3dd369516f18ddd86ef348 git remote add linux-review https://github.com/intel-lab-lkp/linux git fetch --no-tags linux-review Evan-Quan/drivers-acpi-Add-support-for-Wifi-band-RF-mitigations/20230530-104541 git checkout 8c935eeab7a439739f3dd369516f18ddd86ef348 # save the config file mkdir build_dir && cp config build_dir/.config COMPILER_INSTALL_PATH=$HOME/0day COMPILER=gcc-12.3.0 ~/bin/make.cross W=1 O=build_dir ARCH=arm olddefconfig COMPILER_INSTALL_PATH=$HOME/0day COMPILER=gcc-12.3.0 ~/bin/make.cross W=1 O=build_dir ARCH=arm SHELL=/bin/bash If you fix the issue, kindly add following tag where applicable | Reported-by: kernel test robot | Closes: https://lore.kernel.org/oe-kbuild-all/202305310314.eamx2aee-...@intel.com/ All errors (new ones prefixed by >>): arm-linux-gnueabi-ld: drivers/gpu/drm/amd/pm/swsmu/smu13/smu_v13_0_0_ppt.o: in function `smu_v13_0_0_set_wbrf_exclusion_ranges': smu_v13_0_0_ppt.c:(.text+0xfa8): undefined reference to `__aeabi_uldivmod' arm-linux-gnueabi-ld: smu_v13_0_0_ppt.c:(.text+0xfc0): undefined reference to `__aeabi_uldivmod' arm-linux-gnueabi-ld: smu_v13_0_0_ppt.c:(.text+0xfd4): undefined reference to `__aeabi_uldivmod' arm-linux-gnueabi-ld: drivers/gpu/drm/amd/pm/swsmu/smu13/smu_v13_0_7_ppt.o: in function `smu_v13_0_7_set_wbrf_exclusion_ranges': >> smu_v13_0_7_ppt.c:(.text+0xe9c): undefined reference to `__aeabi_uldivmod' >> arm-linux-gnueabi-ld: smu_v13_0_7_ppt.c:(.text+0xeb4): undefined reference >> to `__aeabi_uldivmod' arm-linux-gnueabi-ld: drivers/gpu/drm/amd/pm/swsmu/smu13/smu_v13_0_7_ppt.o:smu_v13_0_7_ppt.c:(.text+0xec8): more undefined references to `__aeabi_uldivmod' follow -- 0-DAY CI Kernel Test Service https://github.com/intel/lkp-tests/wiki
Re: [Intel-gfx] [PATCH] drm/i915/pxp: Fix size_t format specifier in gsccs_send_message()
Hi Nathan,
On Tue, May 30, 2023 at 11:37:56AM -0700, Nathan Chancellor wrote:
> When building ARCH=i386 allmodconfig, the following warning occurs:
>
> In file included from include/linux/device.h:15,
>from include/linux/node.h:18,
>from include/linux/cpu.h:17,
>from include/linux/static_call.h:135,
>from arch/x86/include/asm/perf_event.h:5,
>from include/linux/perf_event.h:25,
>from drivers/gpu/drm/i915/i915_pmu.h:11,
>from drivers/gpu/drm/i915/gt/intel_engine_types.h:21,
>from drivers/gpu/drm/i915/gt/intel_context_types.h:18,
>from drivers/gpu/drm/i915/gem/i915_gem_context_types.h:20,
>from drivers/gpu/drm/i915/i915_request.h:34,
>from drivers/gpu/drm/i915/i915_active.h:13,
>from drivers/gpu/drm/i915/gt/intel_context.h:13,
>from drivers/gpu/drm/i915/pxp/intel_pxp_gsccs.c:8:
> drivers/gpu/drm/i915/pxp/intel_pxp_gsccs.c: In function
> 'gsccs_send_message':
> include/drm/drm_print.h:456:39: error: format '%ld' expects argument of
> type 'long int', but argument 4 has type 'size_t' {aka 'unsigned int'}
> [-Werror=format=]
> 456 | dev_##level##type((drm)->dev, "[drm] " fmt, ##__VA_ARGS__)
> | ^~~~
> include/linux/dev_printk.h:110:30: note: in definition of macro
> 'dev_printk_index_wrap'
> 110 | _p_func(dev, fmt, ##__VA_ARGS__);
> \
> | ^~~
> include/linux/dev_printk.h:146:61: note: in expansion of macro 'dev_fmt'
> 146 | dev_printk_index_wrap(_dev_warn, KERN_WARNING, dev,
> dev_fmt(fmt), ##__VA_ARGS__)
> | ^~~
> include/drm/drm_print.h:456:9: note: in expansion of macro 'dev_warn'
> 456 | dev_##level##type((drm)->dev, "[drm] " fmt, ##__VA_ARGS__)
> | ^~~~
> include/drm/drm_print.h:466:9: note: in expansion of macro '__drm_printk'
> 466 | __drm_printk((drm), warn,, fmt, ##__VA_ARGS__)
> | ^~~~
> drivers/gpu/drm/i915/pxp/intel_pxp_gsccs.c:146:17: note: in expansion of
> macro 'drm_warn'
> 146 | drm_warn(>drm, "caller with insufficient PXP
> reply size %u (%ld)\n",
> | ^~~~
> cc1: all warnings being treated as errors
>
> Use the '%zu' format specifier, as the variable is a 'size_t'.
>
> Fixes: dc9ac125d81f ("drm/i915/pxp: Add GSC-CS backend to send GSC fw
> messages")
> Signed-off-by: Nathan Chancellor
yes, as specified in Documentation/core-api/printk-formats.rst.
Reviewed-by: Andi Shyti
Thanks,
Andi
Re: [PATCH 13/33] drm/amdkfd: prepare map process for single process debug devices
Am 2023-05-25 um 13:27 schrieb Jonathan Kim:
Older HW only supports debugging on a single process because the
SPI debug mode setting registers are device global.
The HWS has supplied a single pinned VMID (0xf) for MAP_PROCESS
for debug purposes. To pin the VMID, the KFD will remove the VMID from
the HWS dynamic VMID allocation via SET_RESOUCES so that a debugged
process will never migrate away from its pinned VMID.
The KFD is responsible for reserving and releasing this pinned VMID
accordingly whenever the debugger attaches and detaches respectively.
v2: spot fix ups using new kfd_node references
Signed-off-by: Jonathan Kim
Reviewed-by: Felix Kuehling
---
.../drm/amd/amdkfd/kfd_device_queue_manager.c | 93 +++
.../drm/amd/amdkfd/kfd_device_queue_manager.h | 5 +
.../drm/amd/amdkfd/kfd_packet_manager_v9.c| 9 ++
.../gpu/drm/amd/amdkfd/kfd_pm4_headers_ai.h | 5 +-
4 files changed, 111 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/amd/amdkfd/kfd_device_queue_manager.c
b/drivers/gpu/drm/amd/amdkfd/kfd_device_queue_manager.c
index d1f44feb7084..c8519adc89ac 100644
--- a/drivers/gpu/drm/amd/amdkfd/kfd_device_queue_manager.c
+++ b/drivers/gpu/drm/amd/amdkfd/kfd_device_queue_manager.c
@@ -1524,6 +1524,7 @@ static int initialize_cpsch(struct device_queue_manager
*dqm)
dqm->gws_queue_count = 0;
dqm->active_runlist = false;
INIT_WORK(>hw_exception_work, kfd_process_hw_exception);
+ dqm->trap_debug_vmid = 0;
init_sdma_bitmaps(dqm);
@@ -2500,6 +2501,98 @@ static void kfd_process_hw_exception(struct work_struct *work)
amdgpu_amdkfd_gpu_reset(dqm->dev->adev);
}
+int reserve_debug_trap_vmid(struct device_queue_manager *dqm,
+ struct qcm_process_device *qpd)
+{
+ int r;
+ int updated_vmid_mask;
+
+ if (dqm->sched_policy == KFD_SCHED_POLICY_NO_HWS) {
+ pr_err("Unsupported on sched_policy: %i\n", dqm->sched_policy);
+ return -EINVAL;
+ }
+
+ dqm_lock(dqm);
+
+ if (dqm->trap_debug_vmid != 0) {
+ pr_err("Trap debug id already reserved\n");
+ r = -EBUSY;
+ goto out_unlock;
+ }
+
+ r = unmap_queues_cpsch(dqm, KFD_UNMAP_QUEUES_FILTER_ALL_QUEUES, 0,
+ USE_DEFAULT_GRACE_PERIOD, false);
+ if (r)
+ goto out_unlock;
+
+ updated_vmid_mask = dqm->dev->kfd->shared_resources.compute_vmid_bitmap;
+ updated_vmid_mask &= ~(1 << dqm->dev->vm_info.last_vmid_kfd);
+
+ dqm->dev->kfd->shared_resources.compute_vmid_bitmap = updated_vmid_mask;
+ dqm->trap_debug_vmid = dqm->dev->vm_info.last_vmid_kfd;
+ r = set_sched_resources(dqm);
+ if (r)
+ goto out_unlock;
+
+ r = map_queues_cpsch(dqm);
+ if (r)
+ goto out_unlock;
+
+ pr_debug("Reserved VMID for trap debug: %i\n", dqm->trap_debug_vmid);
+
+out_unlock:
+ dqm_unlock(dqm);
+ return r;
+}
+
+/*
+ * Releases vmid for the trap debugger
+ */
+int release_debug_trap_vmid(struct device_queue_manager *dqm,
+ struct qcm_process_device *qpd)
+{
+ int r;
+ int updated_vmid_mask;
+ uint32_t trap_debug_vmid;
+
+ if (dqm->sched_policy == KFD_SCHED_POLICY_NO_HWS) {
+ pr_err("Unsupported on sched_policy: %i\n", dqm->sched_policy);
+ return -EINVAL;
+ }
+
+ dqm_lock(dqm);
+ trap_debug_vmid = dqm->trap_debug_vmid;
+ if (dqm->trap_debug_vmid == 0) {
+ pr_err("Trap debug id is not reserved\n");
+ r = -EINVAL;
+ goto out_unlock;
+ }
+
+ r = unmap_queues_cpsch(dqm, KFD_UNMAP_QUEUES_FILTER_ALL_QUEUES, 0,
+ USE_DEFAULT_GRACE_PERIOD, false);
+ if (r)
+ goto out_unlock;
+
+ updated_vmid_mask = dqm->dev->kfd->shared_resources.compute_vmid_bitmap;
+ updated_vmid_mask |= (1 << dqm->dev->vm_info.last_vmid_kfd);
+
+ dqm->dev->kfd->shared_resources.compute_vmid_bitmap = updated_vmid_mask;
+ dqm->trap_debug_vmid = 0;
+ r = set_sched_resources(dqm);
+ if (r)
+ goto out_unlock;
+
+ r = map_queues_cpsch(dqm);
+ if (r)
+ goto out_unlock;
+
+ pr_debug("Released VMID for trap debug: %i\n", trap_debug_vmid);
+
+out_unlock:
+ dqm_unlock(dqm);
+ return r;
+}
+
#if defined(CONFIG_DEBUG_FS)
static void seq_reg_dump(struct seq_file *m,
diff --git a/drivers/gpu/drm/amd/amdkfd/kfd_device_queue_manager.h
b/drivers/gpu/drm/amd/amdkfd/kfd_device_queue_manager.h
index d4dd3b4acbf0..bf7aa3f84182 100644
--- a/drivers/gpu/drm/amd/amdkfd/kfd_device_queue_manager.h
+++ b/drivers/gpu/drm/amd/amdkfd/kfd_device_queue_manager.h
@@ -250,6 +250,7 @@ struct device_queue_manager {
struct kfd_mem_obj *fence_mem;
boolactive_runlist;
Re: [PATCH v5 05/17] clk: meson: g12a: make VCLK2 and ENCL clock path configurable by CCF
Hi Neil, On Tue, May 30, 2023 at 5:57 PM Neil Armstrong wrote: [...] > >> The mipi_dsi_pxclk_div is set as RO in order to use the same GP0 > >> for mipi_dsi_pxclk and vclk2_input. > > > > I don't think notifiers is the appropriate approach here. > > Whenever there is clock change the motifiers would trigger an off/on of > > the clock, regardless of the clock usage or state. > > If you have several consummers on this vclk2, this would > > cause glitches and maybe this is not desirable. > > > > I think it would be better to handle the enable and reset with a > > specific gate driver, in prepare() or enable(), and the give the clock > > CLK_SET_RATE_GATE flag. > > > > This would require the clock to be properly turn off before changing the > > rate. > > Sure, will see how to switch to that, seem Martin did than on Meson8. You can start here: [0] It may not be the nicest logic but so far it works (for me). Please note that I don't mix between CCF and direct register IO clock handling: For the old SoCs I'm relying only on CCF to manage the clocks. Best regards, Martin [0] https://github.com/xdarklight/linux/blob/meson-mx-integration-6.3-20230410/drivers/gpu/drm/meson/meson_vclk.c#L1177-L1179
[PATCH] drm/panel: simple: Fix Powertip PH800480T013 bpc specifier
This panel is 8 bits per channel DPI panel, add the missing .bpc
specifier otherwise the kernel is complaining about it as follows:
"
panel-simple panel: Expected bpc in {6,8} but got: 0
"
Fixes: d69de69f2be1 ("drm/panel: simple: Add Powertip PH800480T013 panel")
Signed-off-by: Marek Vasut
---
Cc: Daniel Vetter
Cc: David Airlie
Cc: Neil Armstrong
Cc: Sam Ravnborg
Cc: dri-devel@lists.freedesktop.org
---
drivers/gpu/drm/panel/panel-simple.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/gpu/drm/panel/panel-simple.c
b/drivers/gpu/drm/panel/panel-simple.c
index 108ebe95590bc..02e3ddf58af07 100644
--- a/drivers/gpu/drm/panel/panel-simple.c
+++ b/drivers/gpu/drm/panel/panel-simple.c
@@ -3327,6 +3327,7 @@ static const struct drm_display_mode
powertip_ph800480t013_idf02_mode = {
static const struct panel_desc powertip_ph800480t013_idf02 = {
.modes = _ph800480t013_idf02_mode,
.num_modes = 1,
+ .bpc = 8,
.size = {
.width = 152,
.height = 91,
--
2.39.2
Re: [PATCH 1/2] dt-bindings: display: bridge: tc358762: Document reset-gpios
On Tue, May 30, 2023 at 09:28:04PM +0200, Marek Vasut wrote: > This chip has one reset GPIO input, document it. The reset GPIO > is optional as it is sometimes not connected on some hardware. > > Signed-off-by: Marek Vasut Acked-by: Conor Dooley Cheers, Conor. signature.asc Description: PGP signature
Re: [PATCH 12/33] drm/amdgpu: add configurable grace period for unmap queues
Am 2023-05-25 um 13:27 schrieb Jonathan Kim:
|diff --git a/drivers/gpu/drm/amd/amdkfd/kfd_packet_manager_vi.c
b/drivers/gpu/drm/amd/amdkfd/kfd_packet_manager_vi.c index
faf4772ed317..a0cfd57ea84a 100644 ---
a/drivers/gpu/drm/amd/amdkfd/kfd_packet_manager_vi.c +++
b/drivers/gpu/drm/amd/amdkfd/kfd_packet_manager_vi.c @@ -303,6 +303,7
@@ const struct packet_manager_funcs kfd_vi_pm_funcs = {
.set_resources = pm_set_resources_vi, .map_queues = pm_map_queues_vi,
.unmap_queues = pm_unmap_queues_vi, + .set_grace_period = NULL,
.query_status = pm_query_status_vi, .release_mem = pm_release_mem_vi,
.map_process_size = sizeof(struct pm4_mes_map_process), @@ -310,6
+311,7 @@ const struct packet_manager_funcs kfd_vi_pm_funcs = {
.set_resources_size = sizeof(struct pm4_mes_set_resources),
.map_queues_size = sizeof(struct pm4_mes_map_queues),
.unmap_queues_size = sizeof(struct pm4_mes_unmap_queues), +
.set_grace_period = 0,|
|Did you mean set_grace_period_size here? With that fixed, the patch is|
|Reviewed-by: Felix Kuehling
|
|.query_status_size = sizeof(struct pm4_mes_query_status),
.release_mem_size = sizeof(struct pm4_mec_release_mem)|
[PATCH 2/2] drm/bridge: tc358762: Add reset GPIO support
Add reset GPIO support. The reset GPIO is cleared after supply regulator
was enabled, and set before supply regulator is disabled.
Signed-off-by: Marek Vasut
---
Cc: Andrzej Hajda
Cc: Conor Dooley
Cc: Daniel Vetter
Cc: David Airlie
Cc: Jernej Skrabec
Cc: Jonas Karlman
Cc: Krzysztof Kozlowski
Cc: Laurent Pinchart
Cc: Marek Vasut
Cc: Neil Armstrong
Cc: Rob Herring
Cc: Robert Foss
Cc: devicet...@vger.kernel.org
Cc: dri-devel@lists.freedesktop.org
---
drivers/gpu/drm/bridge/tc358762.c | 15 +++
1 file changed, 15 insertions(+)
diff --git a/drivers/gpu/drm/bridge/tc358762.c
b/drivers/gpu/drm/bridge/tc358762.c
index 77f7f7f547570..5641395fd310e 100644
--- a/drivers/gpu/drm/bridge/tc358762.c
+++ b/drivers/gpu/drm/bridge/tc358762.c
@@ -11,6 +11,7 @@
*/
#include
+#include
#include
#include
#include
@@ -63,6 +64,7 @@ struct tc358762 {
struct drm_bridge bridge;
struct regulator *regulator;
struct drm_bridge *panel_bridge;
+ struct gpio_desc *reset_gpio;
bool pre_enabled;
int error;
};
@@ -138,6 +140,9 @@ static void tc358762_post_disable(struct drm_bridge *bridge)
ctx->pre_enabled = false;
+ if (ctx->reset_gpio)
+ gpiod_set_value_cansleep(ctx->reset_gpio, 0);
+
ret = regulator_disable(ctx->regulator);
if (ret < 0)
dev_err(ctx->dev, "error disabling regulators (%d)\n", ret);
@@ -152,6 +157,11 @@ static void tc358762_pre_enable(struct drm_bridge *bridge)
if (ret < 0)
dev_err(ctx->dev, "error enabling regulators (%d)\n", ret);
+ if (ctx->reset_gpio) {
+ gpiod_set_value_cansleep(ctx->reset_gpio, 1);
+ usleep_range(5000, 1);
+ }
+
ret = tc358762_init(ctx);
if (ret < 0)
dev_err(ctx->dev, "error initializing bridge (%d)\n", ret);
@@ -185,6 +195,11 @@ static int tc358762_parse_dt(struct tc358762 *ctx)
ctx->panel_bridge = panel_bridge;
+ /* Reset GPIO is optional */
+ ctx->reset_gpio = devm_gpiod_get_optional(dev, "reset", GPIOD_OUT_LOW);
+ if (IS_ERR(ctx->reset_gpio))
+ return PTR_ERR(ctx->reset_gpio);
+
return 0;
}
--
2.39.2
[PATCH 1/2] dt-bindings: display: bridge: tc358762: Document reset-gpios
This chip has one reset GPIO input, document it. The reset GPIO is optional as it is sometimes not connected on some hardware. Signed-off-by: Marek Vasut --- Cc: Andrzej Hajda Cc: Conor Dooley Cc: Daniel Vetter Cc: David Airlie Cc: Jernej Skrabec Cc: Jonas Karlman Cc: Krzysztof Kozlowski Cc: Laurent Pinchart Cc: Marek Vasut Cc: Neil Armstrong Cc: Rob Herring Cc: Robert Foss Cc: devicet...@vger.kernel.org Cc: dri-devel@lists.freedesktop.org --- .../devicetree/bindings/display/bridge/toshiba,tc358762.yaml | 3 +++ 1 file changed, 3 insertions(+) diff --git a/Documentation/devicetree/bindings/display/bridge/toshiba,tc358762.yaml b/Documentation/devicetree/bindings/display/bridge/toshiba,tc358762.yaml index 81ca3cbc7abed..6c1de0b217228 100644 --- a/Documentation/devicetree/bindings/display/bridge/toshiba,tc358762.yaml +++ b/Documentation/devicetree/bindings/display/bridge/toshiba,tc358762.yaml @@ -21,6 +21,9 @@ properties: maxItems: 1 description: virtual channel number of a DSI peripheral + reset-gpios: +maxItems: 1 + vddc-supply: description: Regulator for 1.2V internal core power. -- 2.39.2
Re: [PATCH 05/33] drm/amdgpu: setup hw debug registers on driver initialization
Am 2023-05-25 um 13:27 schrieb Jonathan Kim:
Add missing debug trap registers references and initialize all debug
registers on boot by clearing the hardware exception overrides and the
wave allocation ID index.
The debugger requires that TTMPs 6 & 7 save the dispatch ID to map
waves onto dispatch during compute context inspection.
In order to correctly set this up, set the special reserved CP bit by
default whenever the MQD is initailized.
v2: add missing 0-init of SPI_GDBG_TRAP_DATA0/1
Signed-off-by: Jonathan Kim
Reviewed-by: Felix Kuehling
---
drivers/gpu/drm/amd/amdgpu/gfx_v10_0.c| 26 +++
drivers/gpu/drm/amd/amdgpu/gfx_v11_0.c| 1 +
drivers/gpu/drm/amd/amdgpu/gfx_v9_0.c | 30
drivers/gpu/drm/amd/amdgpu/gfx_v9_4_2.c | 3 +
.../gpu/drm/amd/amdkfd/kfd_mqd_manager_v10.c | 5 ++
.../gpu/drm/amd/amdkfd/kfd_mqd_manager_v11.c | 5 ++
.../gpu/drm/amd/amdkfd/kfd_mqd_manager_v9.c | 5 ++
.../include/asic_reg/gc/gc_10_1_0_offset.h| 14
.../include/asic_reg/gc/gc_10_1_0_sh_mask.h | 69 +++
.../include/asic_reg/gc/gc_10_3_0_offset.h| 10 +++
.../include/asic_reg/gc/gc_10_3_0_sh_mask.h | 4 ++
.../include/asic_reg/gc/gc_11_0_0_sh_mask.h | 4 ++
12 files changed, 176 insertions(+)
diff --git a/drivers/gpu/drm/amd/amdgpu/gfx_v10_0.c
b/drivers/gpu/drm/amd/amdgpu/gfx_v10_0.c
index f7ad883a70fa..be984f8c71c7 100644
--- a/drivers/gpu/drm/amd/amdgpu/gfx_v10_0.c
+++ b/drivers/gpu/drm/amd/amdgpu/gfx_v10_0.c
@@ -4825,6 +4825,29 @@ static u32
gfx_v10_0_init_pa_sc_tile_steering_override(struct amdgpu_device *ade
#define DEFAULT_SH_MEM_BASES (0x6000)
+static void gfx_v10_0_debug_trap_config_init(struct amdgpu_device *adev,
+ uint32_t first_vmid,
+ uint32_t last_vmid)
+{
+ uint32_t data;
+ uint32_t trap_config_vmid_mask = 0;
+ int i;
+
+ /* Calculate trap config vmid mask */
+ for (i = first_vmid; i < last_vmid; i++)
+ trap_config_vmid_mask |= (1 << i);
+
+ data = REG_SET_FIELD(0, SPI_GDBG_TRAP_CONFIG,
+ VMID_SEL, trap_config_vmid_mask);
+ data = REG_SET_FIELD(data, SPI_GDBG_TRAP_CONFIG,
+ TRAP_EN, 1);
+ WREG32(SOC15_REG_OFFSET(GC, 0, mmSPI_GDBG_TRAP_CONFIG), data);
+ WREG32(SOC15_REG_OFFSET(GC, 0, mmSPI_GDBG_TRAP_MASK), 0);
+
+ WREG32(SOC15_REG_OFFSET(GC, 0, mmSPI_GDBG_TRAP_DATA0), 0);
+ WREG32(SOC15_REG_OFFSET(GC, 0, mmSPI_GDBG_TRAP_DATA1), 0);
+}
+
static void gfx_v10_0_init_compute_vmid(struct amdgpu_device *adev)
{
int i;
@@ -4856,6 +4879,9 @@ static void gfx_v10_0_init_compute_vmid(struct
amdgpu_device *adev)
WREG32_SOC15_OFFSET(GC, 0, mmGDS_GWS_VMID0, i, 0);
WREG32_SOC15_OFFSET(GC, 0, mmGDS_OA_VMID0, i, 0);
}
+
+ gfx_v10_0_debug_trap_config_init(adev, adev->vm_manager.first_kfd_vmid,
+ AMDGPU_NUM_VMID);
}
static void gfx_v10_0_init_gds_vmid(struct amdgpu_device *adev)
diff --git a/drivers/gpu/drm/amd/amdgpu/gfx_v11_0.c
b/drivers/gpu/drm/amd/amdgpu/gfx_v11_0.c
index da21bf868080..690e121d9dda 100644
--- a/drivers/gpu/drm/amd/amdgpu/gfx_v11_0.c
+++ b/drivers/gpu/drm/amd/amdgpu/gfx_v11_0.c
@@ -1638,6 +1638,7 @@ static void gfx_v11_0_init_compute_vmid(struct
amdgpu_device *adev)
/* Enable trap for each kfd vmid. */
data = RREG32_SOC15(GC, 0, regSPI_GDBG_PER_VMID_CNTL);
data = REG_SET_FIELD(data, SPI_GDBG_PER_VMID_CNTL, TRAP_EN, 1);
+ WREG32_SOC15(GC, 0, regSPI_GDBG_PER_VMID_CNTL, data);
}
soc21_grbm_select(adev, 0, 0, 0, 0);
mutex_unlock(>srbm_mutex);
diff --git a/drivers/gpu/drm/amd/amdgpu/gfx_v9_0.c
b/drivers/gpu/drm/amd/amdgpu/gfx_v9_0.c
index 0189e50bd89f..7f17e0061027 100644
--- a/drivers/gpu/drm/amd/amdgpu/gfx_v9_0.c
+++ b/drivers/gpu/drm/amd/amdgpu/gfx_v9_0.c
@@ -2303,6 +2303,29 @@ static void gfx_v9_0_setup_rb(struct amdgpu_device *adev)
adev->gfx.config.num_rbs = hweight32(active_rbs);
}
+static void gfx_v9_0_debug_trap_config_init(struct amdgpu_device *adev,
+ uint32_t first_vmid,
+ uint32_t last_vmid)
+{
+ uint32_t data;
+ uint32_t trap_config_vmid_mask = 0;
+ int i;
+
+ /* Calculate trap config vmid mask */
+ for (i = first_vmid; i < last_vmid; i++)
+ trap_config_vmid_mask |= (1 << i);
+
+ data = REG_SET_FIELD(0, SPI_GDBG_TRAP_CONFIG,
+ VMID_SEL, trap_config_vmid_mask);
+ data = REG_SET_FIELD(data, SPI_GDBG_TRAP_CONFIG,
+ TRAP_EN, 1);
+ WREG32(SOC15_REG_OFFSET(GC, 0, mmSPI_GDBG_TRAP_CONFIG), data);
+ WREG32(SOC15_REG_OFFSET(GC, 0, mmSPI_GDBG_TRAP_MASK), 0);
+
+ WREG32(SOC15_REG_OFFSET(GC, 0, mmSPI_GDBG_TRAP_DATA0), 0);
+
Re: [PATCH 02/33] drm/amdkfd: display debug capabilities
Am 2023-05-25 um 13:27 schrieb Jonathan Kim:
Expose debug capabilities in the KFD topology node's HSA capabilities and
debug properties flags.
Ensure correct capabilities are exposed based on firmware support.
Flag definitions can be referenced in uapi/linux/kfd_sysfs.h.
v2: rebase topology fw check fix with kfd_node struct update
Signed-off-by: Jonathan Kim
Reviewed-by: Felix Kuehling
---
drivers/gpu/drm/amd/amdkfd/kfd_topology.c | 101 --
drivers/gpu/drm/amd/amdkfd/kfd_topology.h | 6 ++
include/uapi/linux/kfd_sysfs.h| 15
3 files changed, 117 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdkfd/kfd_topology.c
b/drivers/gpu/drm/amd/amdkfd/kfd_topology.c
index 8302d8967158..3def25b2bdbb 100644
--- a/drivers/gpu/drm/amd/amdkfd/kfd_topology.c
+++ b/drivers/gpu/drm/amd/amdkfd/kfd_topology.c
@@ -535,6 +535,8 @@ static ssize_t node_show(struct kobject *kobj, struct
attribute *attr,
dev->gpu->kfd->mec_fw_version);
sysfs_show_32bit_prop(buffer, offs, "capability",
dev->node_props.capability);
+ sysfs_show_64bit_prop(buffer, offs, "debug_prop",
+ dev->node_props.debug_prop);
sysfs_show_32bit_prop(buffer, offs, "sdma_fw_version",
dev->gpu->kfd->sdma_fw_version);
sysfs_show_64bit_prop(buffer, offs, "unique_id",
@@ -1857,6 +1859,97 @@ static int kfd_topology_add_device_locked(struct
kfd_node *gpu, uint32_t gpu_id,
return res;
}
+static void kfd_topology_set_dbg_firmware_support(struct kfd_topology_device *dev)
+{
+ bool firmware_supported = true;
+
+ if (KFD_GC_VERSION(dev->gpu) >= IP_VERSION(11, 0, 0) &&
+ KFD_GC_VERSION(dev->gpu) < IP_VERSION(12, 0, 0)) {
+ firmware_supported =
+ (dev->gpu->adev->mes.sched_version &
AMDGPU_MES_VERSION_MASK) >= 9;
+ goto out;
+ }
+
+ /*
+* Note: Any unlisted devices here are assumed to support exception
handling.
+* Add additional checks here as needed.
+*/
+ switch (KFD_GC_VERSION(dev->gpu)) {
+ case IP_VERSION(9, 0, 1):
+ firmware_supported = dev->gpu->kfd->mec_fw_version >= 459 +
32768;
+ break;
+ case IP_VERSION(9, 1, 0):
+ case IP_VERSION(9, 2, 1):
+ case IP_VERSION(9, 2, 2):
+ case IP_VERSION(9, 3, 0):
+ case IP_VERSION(9, 4, 0):
+ firmware_supported = dev->gpu->kfd->mec_fw_version >= 459;
+ break;
+ case IP_VERSION(9, 4, 1):
+ firmware_supported = dev->gpu->kfd->mec_fw_version >= 60;
+ break;
+ case IP_VERSION(9, 4, 2):
+ firmware_supported = dev->gpu->kfd->mec_fw_version >= 51;
+ break;
+ case IP_VERSION(10, 1, 10):
+ case IP_VERSION(10, 1, 2):
+ case IP_VERSION(10, 1, 1):
+ firmware_supported = dev->gpu->kfd->mec_fw_version >= 144;
+ break;
+ case IP_VERSION(10, 3, 0):
+ case IP_VERSION(10, 3, 2):
+ case IP_VERSION(10, 3, 1):
+ case IP_VERSION(10, 3, 4):
+ case IP_VERSION(10, 3, 5):
+ firmware_supported = dev->gpu->kfd->mec_fw_version >= 89;
+ break;
+ case IP_VERSION(10, 1, 3):
+ case IP_VERSION(10, 3, 3):
+ firmware_supported = false;
+ break;
+ default:
+ break;
+ }
+
+out:
+ if (firmware_supported)
+ dev->node_props.capability |=
HSA_CAP_TRAP_DEBUG_FIRMWARE_SUPPORTED;
+}
+
+static void kfd_topology_set_capabilities(struct kfd_topology_device *dev)
+{
+ dev->node_props.capability |= ((HSA_CAP_DOORBELL_TYPE_2_0 <<
+ HSA_CAP_DOORBELL_TYPE_TOTALBITS_SHIFT) &
+ HSA_CAP_DOORBELL_TYPE_TOTALBITS_MASK);
+
+ dev->node_props.capability |= HSA_CAP_TRAP_DEBUG_SUPPORT |
+ HSA_CAP_TRAP_DEBUG_WAVE_LAUNCH_TRAP_OVERRIDE_SUPPORTED |
+ HSA_CAP_TRAP_DEBUG_WAVE_LAUNCH_MODE_SUPPORTED;
+
+ if (KFD_GC_VERSION(dev->gpu) < IP_VERSION(10, 0, 0)) {
+ dev->node_props.debug_prop |=
HSA_DBG_WATCH_ADDR_MASK_LO_BIT_GFX9 |
+ HSA_DBG_WATCH_ADDR_MASK_HI_BIT;
+
+ if (KFD_GC_VERSION(dev->gpu) < IP_VERSION(9, 4, 2))
+ dev->node_props.debug_prop |=
+ HSA_DBG_DISPATCH_INFO_ALWAYS_VALID;
+ else
+ dev->node_props.capability |=
+
HSA_CAP_TRAP_DEBUG_PRECISE_MEMORY_OPERATIONS_SUPPORTED;
+ } else {
+ dev->node_props.debug_prop |=
HSA_DBG_WATCH_ADDR_MASK_LO_BIT_GFX10 |
+
Re: [PATCH 01/33] drm/amdkfd: add debug and runtime enable interface
Am 2023-05-25 um 13:27 schrieb Jonathan Kim:
Introduce the GPU debug operations interface.
For ROCm-GDB to extend the GNU Debugger's ability to inspect the AMD GPU
instruction set, provide the necessary interface to allow the debugger
to HW debug-mode set and query exceptions per HSA queue, process or
device.
The runtime_enable interface coordinates exception handling with the
HSA runtime.
Usage is available in the kern docs at uapi/linux/kfd_ioctl.h.
v2: add num_xcc to device snapshot entry.
fixup missing EC_QUEUE_PACKET_RESERVED mask.
Signed-off-by: Jonathan Kim
Reviewed-by: Felix Kuehling
---
drivers/gpu/drm/amd/amdkfd/kfd_chardev.c | 48 ++
include/uapi/linux/kfd_ioctl.h | 668 ++-
2 files changed, 715 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/amd/amdkfd/kfd_chardev.c
b/drivers/gpu/drm/amd/amdkfd/kfd_chardev.c
index 88fe1f31739d..f4b50b74818e 100644
--- a/drivers/gpu/drm/amd/amdkfd/kfd_chardev.c
+++ b/drivers/gpu/drm/amd/amdkfd/kfd_chardev.c
@@ -2729,6 +2729,48 @@ static int kfd_ioctl_criu(struct file *filep, struct
kfd_process *p, void *data)
return ret;
}
+static int kfd_ioctl_runtime_enable(struct file *filep, struct kfd_process *p, void *data)
+{
+ return 0;
+}
+
+static int kfd_ioctl_set_debug_trap(struct file *filep, struct kfd_process *p,
void *data)
+{
+ struct kfd_ioctl_dbg_trap_args *args = data;
+ int r = 0;
+
+ if (sched_policy == KFD_SCHED_POLICY_NO_HWS) {
+ pr_err("Debugging does not support sched_policy %i",
sched_policy);
+ return -EINVAL;
+ }
+
+ switch (args->op) {
+ case KFD_IOC_DBG_TRAP_ENABLE:
+ case KFD_IOC_DBG_TRAP_DISABLE:
+ case KFD_IOC_DBG_TRAP_SEND_RUNTIME_EVENT:
+ case KFD_IOC_DBG_TRAP_SET_EXCEPTIONS_ENABLED:
+ case KFD_IOC_DBG_TRAP_SET_WAVE_LAUNCH_OVERRIDE:
+ case KFD_IOC_DBG_TRAP_SET_WAVE_LAUNCH_MODE:
+ case KFD_IOC_DBG_TRAP_SUSPEND_QUEUES:
+ case KFD_IOC_DBG_TRAP_RESUME_QUEUES:
+ case KFD_IOC_DBG_TRAP_SET_NODE_ADDRESS_WATCH:
+ case KFD_IOC_DBG_TRAP_CLEAR_NODE_ADDRESS_WATCH:
+ case KFD_IOC_DBG_TRAP_SET_FLAGS:
+ case KFD_IOC_DBG_TRAP_QUERY_DEBUG_EVENT:
+ case KFD_IOC_DBG_TRAP_QUERY_EXCEPTION_INFO:
+ case KFD_IOC_DBG_TRAP_GET_QUEUE_SNAPSHOT:
+ case KFD_IOC_DBG_TRAP_GET_DEVICE_SNAPSHOT:
+ pr_warn("Debugging not supported yet\n");
+ r = -EACCES;
+ break;
+ default:
+ pr_err("Invalid option: %i\n", args->op);
+ r = -EINVAL;
+ }
+
+ return r;
+}
+
#define AMDKFD_IOCTL_DEF(ioctl, _func, _flags) \
[_IOC_NR(ioctl)] = {.cmd = ioctl, .func = _func, .flags = _flags, \
.cmd_drv = 0, .name = #ioctl}
@@ -2841,6 +2883,12 @@ static const struct amdkfd_ioctl_desc amdkfd_ioctls[] = {
AMDKFD_IOCTL_DEF(AMDKFD_IOC_EXPORT_DMABUF,
kfd_ioctl_export_dmabuf, 0),
+
+ AMDKFD_IOCTL_DEF(AMDKFD_IOC_RUNTIME_ENABLE,
+ kfd_ioctl_runtime_enable, 0),
+
+ AMDKFD_IOCTL_DEF(AMDKFD_IOC_DBG_TRAP,
+ kfd_ioctl_set_debug_trap, 0),
};
#define AMDKFD_CORE_IOCTL_COUNT ARRAY_SIZE(amdkfd_ioctls)
diff --git a/include/uapi/linux/kfd_ioctl.h b/include/uapi/linux/kfd_ioctl.h
index 2a9671e1ddb5..dfe745ee427e 100644
--- a/include/uapi/linux/kfd_ioctl.h
+++ b/include/uapi/linux/kfd_ioctl.h
@@ -110,6 +110,32 @@ struct kfd_ioctl_get_available_memory_args {
__u32 pad;
};
+struct kfd_dbg_device_info_entry {
+ __u64 exception_status;
+ __u64 lds_base;
+ __u64 lds_limit;
+ __u64 scratch_base;
+ __u64 scratch_limit;
+ __u64 gpuvm_base;
+ __u64 gpuvm_limit;
+ __u32 gpu_id;
+ __u32 location_id;
+ __u32 vendor_id;
+ __u32 device_id;
+ __u32 revision_id;
+ __u32 subsystem_vendor_id;
+ __u32 subsystem_device_id;
+ __u32 fw_version;
+ __u32 gfx_target_version;
+ __u32 simd_count;
+ __u32 max_waves_per_simd;
+ __u32 array_count;
+ __u32 simd_arrays_per_engine;
+ __u32 num_xcc;
+ __u32 capability;
+ __u32 debug_prop;
+};
+
/* For kfd_ioctl_set_memory_policy_args.default_policy and alternate_policy */
#define KFD_IOC_CACHE_POLICY_COHERENT 0
#define KFD_IOC_CACHE_POLICY_NONCOHERENT 1
@@ -775,6 +801,640 @@ struct kfd_ioctl_set_xnack_mode_args {
__s32 xnack_enabled;
};
+/* Wave launch override modes */
+enum kfd_dbg_trap_override_mode {
+ KFD_DBG_TRAP_OVERRIDE_OR = 0,
+ KFD_DBG_TRAP_OVERRIDE_REPLACE = 1
+};
+
+/* Wave launch overrides */
+enum kfd_dbg_trap_mask {
+ KFD_DBG_TRAP_MASK_FP_INVALID = 1,
+ KFD_DBG_TRAP_MASK_FP_INPUT_DENORMAL = 2,
+ KFD_DBG_TRAP_MASK_FP_DIVIDE_BY_ZERO = 4,
+ KFD_DBG_TRAP_MASK_FP_OVERFLOW = 8,
+ KFD_DBG_TRAP_MASK_FP_UNDERFLOW = 16,
+
RE: [PATCH 2/2] drm/i915/gt: Fix parameter in gmch_ggtt_insert_{entries,page}()
> Subject: [PATCH 2/2] drm/i915/gt: Fix parameter in
> gmch_ggtt_insert_{entries,page}()
>
> When building with clang's -Wincompatible-function-pointer-types-strict,
> the following warnings occur:
>
> drivers/gpu/drm/i915/gt/intel_ggtt_gmch.c:102:23: error: incompatible
> function pointer types assigning to 'void (*)(struct i915_address_space *,
> dma_addr_t, u64, unsigned int, u32)' (aka 'void (*)(struct i915_address_space
> *, unsigned int, unsigned long long, unsigned int, unsigned int)') from 'void
> (struct i915_address_space *, dma_addr_t, u64, enum i915_cache_level, u32)'
> (aka 'void (struct i915_address_space *, unsigned int, unsigned long long,
> enum i915_cache_level, unsigned int)')
> [-Werror,-Wincompatible-function-pointer-types-strict]
> ggtt->vm.insert_page = gmch_ggtt_insert_page;
>^ ~
> drivers/gpu/drm/i915/gt/intel_ggtt_gmch.c:103:26: error: incompatible
> function pointer types assigning to 'void (*)(struct i915_address_space *,
> struct i915_vma_resource *, unsigned int, u32)' (aka 'void (*)(struct
> i915_address_space *, struct i915_vma_resource *, unsigned int, unsigned
> int)') from 'void (struct i915_address_space *, struct i915_vma_resource *,
> enum i915_cache_level, u32)' (aka 'void (struct i915_address_space *, struct
> i915_vma_resource *, enum i915_cache_level, unsigned int)') [-Werror,
> -Wincompatible-function-pointer-types-strict]
> ggtt->vm.insert_entries = gmch_ggtt_insert_entries;
> ^
> 2 errors generated.
>
> The warning is pointing out that while 'enum i915_cache_level' and 'unsigned
> int' are ABI compatible, these indirect calls will fail clang's kernel
> Control Flow Integrity (kCFI) checks, as the callback's signature does not
> exactly match the prototype's signature.
>
> To fix this, replace the cache_level parameter with pat_index, as was done in
> other places within i915 where there is no difference between cache_level and
> pat_index on certain generations.
>
> Fixes: 9275277d5324 ("drm/i915: use pat_index instead of cache_level")
> Signed-off-by: Nathan Chancellor
Reviewed-by: Fei Yang
> ---
> drivers/gpu/drm/i915/gt/intel_ggtt_gmch.c | 8
> 1 file changed, 4 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/gt/intel_ggtt_gmch.c
> b/drivers/gpu/drm/i915/gt/intel_ggtt_gmch.c
> index d6a74ae2527b..866c416afb73 100644
> --- a/drivers/gpu/drm/i915/gt/intel_ggtt_gmch.c
> +++ b/drivers/gpu/drm/i915/gt/intel_ggtt_gmch.c
> @@ -18,10 +18,10 @@
> static void gmch_ggtt_insert_page(struct i915_address_space *vm,
> dma_addr_t addr,
> u64 offset,
> - enum i915_cache_level cache_level,
> + unsigned int pat_index,
> u32 unused)
> {
> - unsigned int flags = (cache_level == I915_CACHE_NONE) ?
> + unsigned int flags = (pat_index == I915_CACHE_NONE) ?
> AGP_USER_MEMORY : AGP_USER_CACHED_MEMORY;
>
> intel_gmch_gtt_insert_page(addr, offset >> PAGE_SHIFT, flags); @@
> -29,10 +29,10 @@ static void gmch_ggtt_insert_page(struct i915_address_space
> *vm,
>
> static void gmch_ggtt_insert_entries(struct i915_address_space *vm,
>struct i915_vma_resource *vma_res,
> - enum i915_cache_level cache_level,
> + unsigned int pat_index,
>u32 unused)
> {
> - unsigned int flags = (cache_level == I915_CACHE_NONE) ?
> + unsigned int flags = (pat_index == I915_CACHE_NONE) ?
> AGP_USER_MEMORY : AGP_USER_CACHED_MEMORY;
>
> intel_gmch_gtt_insert_sg_entries(vma_res->bi.pages, vma_res->start >>
> PAGE_SHIFT,
>
> --
> 2.40.1
RE: [PATCH 1/2] drm/i915/gt: Fix second parameter type of pre-gen8 pte_encode callbacks
> Subject: [PATCH 1/2] drm/i915/gt: Fix second parameter type of pre-gen8
> pte_encode callbacks
>
> When booting a kernel compiled with CONFIG_CFI_CLANG (kCFI), there is a CFI
> failure in ggtt_probe_common() when trying to call hsw_pte_encode() via an
> indirect call:
>
> [5.030027] CFI failure at ggtt_probe_common+0xd1/0x130 [i915] (target:
> hsw_pte_encode+0x0/0x30 [i915]; expected type: 0xf5c1d0fc)
>
> With kCFI, indirect calls are validated against their expected type versus
> actual type and failures occur when the two types do not match.
>
> clang's -Wincompatible-function-pointer-types-strict can catch this at
> compile time but it is not enabled for the kernel yet:
>
> drivers/gpu/drm/i915/gt/intel_ggtt.c:1155:23: error: incompatible function
> pointer types assigning to 'u64 (*)(dma_addr_t, unsigned int, u32)' (aka
> 'unsigned long long (*)(unsigned int, unsigned int, unsigned int)') from 'u64
> (dma_addr_t,
> enum i915_cache_level, u32)' (aka 'unsigned long long (unsigned int, enum
> i915_cache_level, unsigned int)')
> [-Werror,-Wincompatible-function-pointer-types-strict]
> ggtt->vm.pte_encode = iris_pte_encode;
> ^ ~~~
> drivers/gpu/drm/i915/gt/intel_ggtt.c:1157:23: error: incompatible function
> pointer types assigning to 'u64 (*)(dma_addr_t, unsigned int, u32)' (aka
> 'unsigned long long (*)(unsigned int, unsigned int, unsigned int)') from 'u64
> (dma_addr_t,
> enum i915_cache_level, u32)' (aka 'unsigned long long (unsigned int, enum
> i915_cache_level, unsigned int)')
> [-Werror,-Wincompatible-function-pointer-types-strict]
> ggtt->vm.pte_encode = hsw_pte_encode;
> ^ ~~
> drivers/gpu/drm/i915/gt/intel_ggtt.c:1159:23: error: incompatible function
> pointer types assigning to 'u64 (*)(dma_addr_t, unsigned int, u32)' (aka
> 'unsigned long long (*)(unsigned int, unsigned int, unsigned int)') from 'u64
> (dma_addr_t,
> enum i915_cache_level, u32)' (aka 'unsigned long long (unsigned int, enum
> i915_cache_level, unsigned int)')
> [-Werror,-Wincompatible-function-pointer-types-strict]
> ggtt->vm.pte_encode = byt_pte_encode;
> ^ ~~
> drivers/gpu/drm/i915/gt/intel_ggtt.c:1161:23: error: incompatible function
> pointer types assigning to 'u64 (*)(dma_addr_t, unsigned int, u32)' (aka
> 'unsigned long long (*)(unsigned int, unsigned int, unsigned int)') from 'u64
> (dma_addr_t,
> enum i915_cache_level, u32)' (aka 'unsigned long long (unsigned int, enum
> i915_cache_level, unsigned int)')
> [-Werror,-Wincompatible-function-pointer-types-strict]
> ggtt->vm.pte_encode = ivb_pte_encode;
> ^ ~~
> drivers/gpu/drm/i915/gt/intel_ggtt.c:1163:23: error: incompatible function
> pointer types assigning to 'u64 (*)(dma_addr_t, unsigned int, u32)' (aka
> 'unsigned long long (*)(unsigned int, unsigned int, unsigned int)') from 'u64
> (dma_addr_t,
> enum i915_cache_level, u32)' (aka 'unsigned long long (unsigned int, enum
> i915_cache_level, unsigned int)')
> [-Werror,-Wincompatible-function-pointer-types-strict]
> ggtt->vm.pte_encode = snb_pte_encode;
> ^ ~~
> 5 errors generated.
>
> In this case, the pre-gen8 pte_encode functions have a second parameter type
> of 'enum i915_cache_level' whereas the function pointer prototype in 'struct
> i915_address_space' expects a second parameter type of 'unsigned int'.
>
> Update the second parameter of the callbacks and the comment above them
> noting that these statements are still valid, which matches other functions
> and files, to clear up the kCFI failures at run time.
>
> Fixes: 9275277d5324 ("drm/i915: use pat_index instead of cache_level")
> Signed-off-by: Nathan Chancellor
Reviewed-by: Fei Yang
> ---
> drivers/gpu/drm/i915/gt/intel_ggtt.c | 26 +-
> 1 file changed, 13 insertions(+), 13 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/gt/intel_ggtt.c
> b/drivers/gpu/drm/i915/gt/intel_ggtt.c
> index 2a7942fac798..122197737ef2 100644
> --- a/drivers/gpu/drm/i915/gt/intel_ggtt.c
> +++ b/drivers/gpu/drm/i915/gt/intel_ggtt.c
> @@ -1015,16 +1015,16 @@ static int gen8_gmch_probe(struct i915_ggtt *ggtt)
>
> /*
> * For pre-gen8 platforms pat_index is the same as enum i915_cache_level,
> - * so these PTE encode functions are left with using cache_level.
> + * so the switch-case statements in these PTE encode functions are still
> valid.
> * See translation table LEGACY_CACHELEVEL.
> */
> static u64 snb_pte_encode(dma_addr_t addr,
> - enum i915_cache_level level,
> + unsigned int pat_index,
> u32 flags)
> {
> gen6_pte_t pte = GEN6_PTE_ADDR_ENCODE(addr) |
Re: [PATCH v6 5/6] drm/etnaviv: add driver support for the PCI devices
On Wed, May 31, 2023 at 12:06:42AM +0800, Sui Jingfeng wrote:
> This patch adds PCI driver support on top of what already have. Take the
> GC1000 in LS7A1000/LS2K1000 as the first instance of the PCI device driver.
> There is only one GPU core for the GC1000 in the LS7A1000 and LS2K1000.
> Therefore, component frameworks can be avoided. Because we want to bind the
> DRM driver service to the PCI driver manually.
> + * Loongson Mips and LoongArch CPU(ls3a5000, ls3a4000, ls2k1000la)
> + * maintain cache coherency by hardware
> + */
> + if (IS_ENABLED(CONFIG_CPU_LOONGSON64) || IS_ENABLED(CONFIG_LOONGARCH))
> + priv->has_cached_coherent = true;
This looks like something that should be a runtime check, not a
compile-time check.
If it's possible to build a single kernel image that runs on Loongson
MIPS or LoongArch CPU and, in addition, runs on other platforms, you
cannot assume that all the others maintain this cache coherency.
> +static struct etnaviv_drm_private *etna_private_s;
A static pointer looks wrong because it probably limits you to a
single instance of something.
> @@ -727,6 +756,12 @@ static int __init etnaviv_init(void)
> if (ret != 0)
> goto unregister_gpu_driver;
>
> +#ifdef CONFIG_DRM_ETNAVIV_PCI_DRIVER
> + ret = pci_register_driver(_pci_driver);
> +#endif
> + if (ret != 0)
> + goto unregister_platform_driver;
Why is this outside the #ifdef? If CONFIG_DRM_ETNAVIV_PCI_DRIVER is
not set, you already tested "ret != 0" above and will never take this
goto.
> +static int etnaviv_gpu_plat_drv_init(struct etnaviv_gpu *gpu, bool component)
> +{
> + struct device *dev = gpu->dev;
> + struct platform_device *pdev = to_platform_device(dev);
> + int err;
> +
> + /* Map registers: */
> + gpu->mmio = devm_platform_ioremap_resource(pdev, 0);
> + if (IS_ERR(gpu->mmio))
> + return PTR_ERR(gpu->mmio);
> +
> + if (component) {
> + err = component_add(dev, _ops);
> + if (err < 0) {
> + dev_err(dev, "failed to register component: %d\n", err);
> + return err;
> + }
> + }
> +
> + return 0;
> +}
All this platform driver rearrangement looks like it should be a
separate patch so adding PCI support only adds PCI-related stuff.
> +++ b/drivers/gpu/drm/etnaviv/etnaviv_pci_drv.c
> @@ -0,0 +1,87 @@
> +// SPDX-License-Identifier: GPL-2.0
> +
> +#include
> +
> +#include "etnaviv_drv.h"
> +#include "etnaviv_gpu.h"
> +#include "etnaviv_pci_drv.h"
> +
> +enum etnaviv_pci_gpu_family {
> + GC1000_IN_LS7A1000 = 0,
> + GC1000_IN_LS2K1000 = 1,
Seems unused; why is this here?
> +static int etnaviv_pci_probe(struct pci_dev *pdev,
> + const struct pci_device_id *ent)
> +{
> + struct device *dev = >dev;
> + int ret;
> +
> + ret = pcim_enable_device(pdev);
> + if (ret) {
> + dev_err(>dev, "failed to enable\n");
Use "dev", no need for ">dev" since you already looked it up
above. Also below for dma_set_mask_and_coherent().
> + return ret;
> + }
> +
> + pci_set_master(pdev);
> +
> + ret = dma_set_mask_and_coherent(>dev, DMA_BIT_MASK(32));
> +static const struct pci_device_id etnaviv_pci_id_lists[] = {
> + {0x0014, 0x7a15, PCI_ANY_ID, PCI_ANY_ID, 0, 0, GC1000_IN_LS7A1000},
> + {0x0014, 0x7a05, PCI_ANY_ID, PCI_ANY_ID, 0, 0, GC1000_IN_LS2K1000},
> + {0, 0, 0, 0, 0, 0, 0}
Should probably use PCI_DEVICE_DATA(). Use PCI_VENDOR_ID_LOONGSON.
Only "{ }" required to terminate.
> +++ b/drivers/gpu/drm/etnaviv/etnaviv_pci_drv.h
> @@ -0,0 +1,12 @@
> +/* SPDX-License-Identifier: GPL-2.0 */
> +
> +#ifndef __ETNAVIV_PCI_DRV_H__
> +#define __ETNAVIV_PCI_DRV_H__
> +
> +#include
This #include isn't required by this file.
> +#ifdef CONFIG_DRM_ETNAVIV_PCI_DRIVER
> +extern struct pci_driver etnaviv_pci_driver;
> +#endif
> +
> +#endif
Re: [PATCH v6 6/6] drm/etnaviv: allow usperspace create cached coherent bo
s/usperspace/userspace/ (in subject) On Wed, May 31, 2023 at 12:06:43AM +0800, Sui Jingfeng wrote: > cached system RAM is coherent on loongson CPUs, and the GPU and DC allways > snoop the CPU's cache. write-combine caching property is not suitiable for > us. s/allways/always/ s/suitiable/suitable/
Re: [PATCH 2/2] drm/i915/gt: Fix parameter in gmch_ggtt_insert_{entries,page}()
Hi Nathan,
On Tue, May 30, 2023 at 11:24:39AM -0700, Nathan Chancellor wrote:
> When building with clang's -Wincompatible-function-pointer-types-strict,
> the following warnings occur:
>
> drivers/gpu/drm/i915/gt/intel_ggtt_gmch.c:102:23: error: incompatible
> function pointer types assigning to 'void (*)(struct i915_address_space *,
> dma_addr_t, u64, unsigned int, u32)' (aka 'void (*)(struct i915_address_space
> *, unsigned int, unsigned long long, unsigned int, unsigned int)') from 'void
> (struct i915_address_space *, dma_addr_t, u64, enum i915_cache_level, u32)'
> (aka 'void (struct i915_address_space *, unsigned int, unsigned long long,
> enum i915_cache_level, unsigned int)')
> [-Werror,-Wincompatible-function-pointer-types-strict]
> ggtt->vm.insert_page = gmch_ggtt_insert_page;
>^ ~
> drivers/gpu/drm/i915/gt/intel_ggtt_gmch.c:103:26: error: incompatible
> function pointer types assigning to 'void (*)(struct i915_address_space *,
> struct i915_vma_resource *, unsigned int, u32)' (aka 'void (*)(struct
> i915_address_space *, struct i915_vma_resource *, unsigned int, unsigned
> int)') from 'void (struct i915_address_space *, struct i915_vma_resource *,
> enum i915_cache_level, u32)' (aka 'void (struct i915_address_space *, struct
> i915_vma_resource *, enum i915_cache_level, unsigned int)') [-Werror,
> -Wincompatible-function-pointer-types-strict]
> ggtt->vm.insert_entries = gmch_ggtt_insert_entries;
> ^
> 2 errors generated.
>
> The warning is pointing out that while 'enum i915_cache_level' and
> 'unsigned int' are ABI compatible, these indirect calls will fail
> clang's kernel Control Flow Integrity (kCFI) checks, as the callback's
> signature does not exactly match the prototype's signature.
>
> To fix this, replace the cache_level parameter with pat_index, as was
> done in other places within i915 where there is no difference between
> cache_level and pat_index on certain generations.
>
> Fixes: 9275277d5324 ("drm/i915: use pat_index instead of cache_level")
> Signed-off-by: Nathan Chancellor
same clang issue as before, I'm OK with this patch, from my side:
Reviewed-by: Andi Shyti
Thanks,
Andi
Re: [PATCH 1/2] drm/i915/gt: Fix second parameter type of pre-gen8 pte_encode callbacks
Hi Nathan,
On Tue, May 30, 2023 at 11:24:38AM -0700, Nathan Chancellor wrote:
> When booting a kernel compiled with CONFIG_CFI_CLANG (kCFI), there is a
> CFI failure in ggtt_probe_common() when trying to call hsw_pte_encode()
> via an indirect call:
>
> [5.030027] CFI failure at ggtt_probe_common+0xd1/0x130 [i915] (target:
> hsw_pte_encode+0x0/0x30 [i915]; expected type: 0xf5c1d0fc)
>
> With kCFI, indirect calls are validated against their expected type
> versus actual type and failures occur when the two types do not match.
>
> clang's -Wincompatible-function-pointer-types-strict can catch this at
> compile time but it is not enabled for the kernel yet:
>
> drivers/gpu/drm/i915/gt/intel_ggtt.c:1155:23: error: incompatible function
> pointer types assigning to 'u64 (*)(dma_addr_t, unsigned int, u32)' (aka
> 'unsigned long long (*)(unsigned int, unsigned int, unsigned int)') from 'u64
> (dma_addr_t,
> enum i915_cache_level, u32)' (aka 'unsigned long long (unsigned int, enum
> i915_cache_level, unsigned int)')
> [-Werror,-Wincompatible-function-pointer-types-strict]
> ggtt->vm.pte_encode = iris_pte_encode;
> ^ ~~~
> drivers/gpu/drm/i915/gt/intel_ggtt.c:1157:23: error: incompatible function
> pointer types assigning to 'u64 (*)(dma_addr_t, unsigned int, u32)' (aka
> 'unsigned long long (*)(unsigned int, unsigned int, unsigned int)') from 'u64
> (dma_addr_t,
> enum i915_cache_level, u32)' (aka 'unsigned long long (unsigned int, enum
> i915_cache_level, unsigned int)')
> [-Werror,-Wincompatible-function-pointer-types-strict]
> ggtt->vm.pte_encode = hsw_pte_encode;
> ^ ~~
> drivers/gpu/drm/i915/gt/intel_ggtt.c:1159:23: error: incompatible function
> pointer types assigning to 'u64 (*)(dma_addr_t, unsigned int, u32)' (aka
> 'unsigned long long (*)(unsigned int, unsigned int, unsigned int)') from 'u64
> (dma_addr_t,
> enum i915_cache_level, u32)' (aka 'unsigned long long (unsigned int, enum
> i915_cache_level, unsigned int)')
> [-Werror,-Wincompatible-function-pointer-types-strict]
> ggtt->vm.pte_encode = byt_pte_encode;
> ^ ~~
> drivers/gpu/drm/i915/gt/intel_ggtt.c:1161:23: error: incompatible function
> pointer types assigning to 'u64 (*)(dma_addr_t, unsigned int, u32)' (aka
> 'unsigned long long (*)(unsigned int, unsigned int, unsigned int)') from 'u64
> (dma_addr_t,
> enum i915_cache_level, u32)' (aka 'unsigned long long (unsigned int, enum
> i915_cache_level, unsigned int)')
> [-Werror,-Wincompatible-function-pointer-types-strict]
> ggtt->vm.pte_encode = ivb_pte_encode;
> ^ ~~
> drivers/gpu/drm/i915/gt/intel_ggtt.c:1163:23: error: incompatible function
> pointer types assigning to 'u64 (*)(dma_addr_t, unsigned int, u32)' (aka
> 'unsigned long long (*)(unsigned int, unsigned int, unsigned int)') from 'u64
> (dma_addr_t,
> enum i915_cache_level, u32)' (aka 'unsigned long long (unsigned int, enum
> i915_cache_level, unsigned int)')
> [-Werror,-Wincompatible-function-pointer-types-strict]
> ggtt->vm.pte_encode = snb_pte_encode;
> ^ ~~
> 5 errors generated.
>
> In this case, the pre-gen8 pte_encode functions have a second parameter
> type of 'enum i915_cache_level' whereas the function pointer prototype
> in 'struct i915_address_space' expects a second parameter type of
> 'unsigned int'.
>
> Update the second parameter of the callbacks and the comment above them
> noting that these statements are still valid, which matches other
> functions and files, to clear up the kCFI failures at run time.
>
> Fixes: 9275277d5324 ("drm/i915: use pat_index instead of cache_level")
> Signed-off-by: Nathan Chancellor
That's correct!
Reviewed-by: Andi Shyti
Thanks,
Andi
[PATCH] drm/i915/pxp: Fix size_t format specifier in gsccs_send_message()
When building ARCH=i386 allmodconfig, the following warning occurs:
In file included from include/linux/device.h:15,
from include/linux/node.h:18,
from include/linux/cpu.h:17,
from include/linux/static_call.h:135,
from arch/x86/include/asm/perf_event.h:5,
from include/linux/perf_event.h:25,
from drivers/gpu/drm/i915/i915_pmu.h:11,
from drivers/gpu/drm/i915/gt/intel_engine_types.h:21,
from drivers/gpu/drm/i915/gt/intel_context_types.h:18,
from drivers/gpu/drm/i915/gem/i915_gem_context_types.h:20,
from drivers/gpu/drm/i915/i915_request.h:34,
from drivers/gpu/drm/i915/i915_active.h:13,
from drivers/gpu/drm/i915/gt/intel_context.h:13,
from drivers/gpu/drm/i915/pxp/intel_pxp_gsccs.c:8:
drivers/gpu/drm/i915/pxp/intel_pxp_gsccs.c: In function 'gsccs_send_message':
include/drm/drm_print.h:456:39: error: format '%ld' expects argument of type
'long int', but argument 4 has type 'size_t' {aka 'unsigned int'}
[-Werror=format=]
456 | dev_##level##type((drm)->dev, "[drm] " fmt, ##__VA_ARGS__)
| ^~~~
include/linux/dev_printk.h:110:30: note: in definition of macro
'dev_printk_index_wrap'
110 | _p_func(dev, fmt, ##__VA_ARGS__);
\
| ^~~
include/linux/dev_printk.h:146:61: note: in expansion of macro 'dev_fmt'
146 | dev_printk_index_wrap(_dev_warn, KERN_WARNING, dev,
dev_fmt(fmt), ##__VA_ARGS__)
| ^~~
include/drm/drm_print.h:456:9: note: in expansion of macro 'dev_warn'
456 | dev_##level##type((drm)->dev, "[drm] " fmt, ##__VA_ARGS__)
| ^~~~
include/drm/drm_print.h:466:9: note: in expansion of macro '__drm_printk'
466 | __drm_printk((drm), warn,, fmt, ##__VA_ARGS__)
| ^~~~
drivers/gpu/drm/i915/pxp/intel_pxp_gsccs.c:146:17: note: in expansion of
macro 'drm_warn'
146 | drm_warn(>drm, "caller with insufficient PXP
reply size %u (%ld)\n",
| ^~~~
cc1: all warnings being treated as errors
Use the '%zu' format specifier, as the variable is a 'size_t'.
Fixes: dc9ac125d81f ("drm/i915/pxp: Add GSC-CS backend to send GSC fw messages")
Signed-off-by: Nathan Chancellor
---
drivers/gpu/drm/i915/pxp/intel_pxp_gsccs.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/pxp/intel_pxp_gsccs.c
b/drivers/gpu/drm/i915/pxp/intel_pxp_gsccs.c
index 8dc41de3f6f7..a217821eb0fb 100644
--- a/drivers/gpu/drm/i915/pxp/intel_pxp_gsccs.c
+++ b/drivers/gpu/drm/i915/pxp/intel_pxp_gsccs.c
@@ -143,7 +143,7 @@ gsccs_send_message(struct intel_pxp *pxp,
reply_size = header->message_size - sizeof(*header);
if (reply_size > msg_out_size_max) {
- drm_warn(>drm, "caller with insufficient PXP reply size
%u (%ld)\n",
+ drm_warn(>drm, "caller with insufficient PXP reply size
%u (%zu)\n",
reply_size, msg_out_size_max);
reply_size = msg_out_size_max;
}
---
base-commit: 08264f85c5c05ecc38d409c84d48cfb00ccd3bc4
change-id: 20230530-i915-pxp-size_t-wformat-1d73ed1f8d23
Best regards,
--
Nathan Chancellor
[PATCH 2/2] drm/i915/gt: Fix parameter in gmch_ggtt_insert_{entries,page}()
When building with clang's -Wincompatible-function-pointer-types-strict,
the following warnings occur:
drivers/gpu/drm/i915/gt/intel_ggtt_gmch.c:102:23: error: incompatible
function pointer types assigning to 'void (*)(struct i915_address_space *,
dma_addr_t, u64, unsigned int, u32)' (aka 'void (*)(struct i915_address_space
*, unsigned int, unsigned long long, unsigned int, unsigned int)') from 'void
(struct i915_address_space *, dma_addr_t, u64, enum i915_cache_level, u32)'
(aka 'void (struct i915_address_space *, unsigned int, unsigned long long, enum
i915_cache_level, unsigned int)')
[-Werror,-Wincompatible-function-pointer-types-strict]
ggtt->vm.insert_page = gmch_ggtt_insert_page;
^ ~
drivers/gpu/drm/i915/gt/intel_ggtt_gmch.c:103:26: error: incompatible
function pointer types assigning to 'void (*)(struct i915_address_space *,
struct i915_vma_resource *, unsigned int, u32)' (aka 'void (*)(struct
i915_address_space *, struct i915_vma_resource *, unsigned int, unsigned int)')
from 'void (struct i915_address_space *, struct i915_vma_resource *, enum
i915_cache_level, u32)' (aka 'void (struct i915_address_space *, struct
i915_vma_resource *, enum i915_cache_level, unsigned int)') [-Werror,
-Wincompatible-function-pointer-types-strict]
ggtt->vm.insert_entries = gmch_ggtt_insert_entries;
^
2 errors generated.
The warning is pointing out that while 'enum i915_cache_level' and
'unsigned int' are ABI compatible, these indirect calls will fail
clang's kernel Control Flow Integrity (kCFI) checks, as the callback's
signature does not exactly match the prototype's signature.
To fix this, replace the cache_level parameter with pat_index, as was
done in other places within i915 where there is no difference between
cache_level and pat_index on certain generations.
Fixes: 9275277d5324 ("drm/i915: use pat_index instead of cache_level")
Signed-off-by: Nathan Chancellor
---
drivers/gpu/drm/i915/gt/intel_ggtt_gmch.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/intel_ggtt_gmch.c
b/drivers/gpu/drm/i915/gt/intel_ggtt_gmch.c
index d6a74ae2527b..866c416afb73 100644
--- a/drivers/gpu/drm/i915/gt/intel_ggtt_gmch.c
+++ b/drivers/gpu/drm/i915/gt/intel_ggtt_gmch.c
@@ -18,10 +18,10 @@
static void gmch_ggtt_insert_page(struct i915_address_space *vm,
dma_addr_t addr,
u64 offset,
- enum i915_cache_level cache_level,
+ unsigned int pat_index,
u32 unused)
{
- unsigned int flags = (cache_level == I915_CACHE_NONE) ?
+ unsigned int flags = (pat_index == I915_CACHE_NONE) ?
AGP_USER_MEMORY : AGP_USER_CACHED_MEMORY;
intel_gmch_gtt_insert_page(addr, offset >> PAGE_SHIFT, flags);
@@ -29,10 +29,10 @@ static void gmch_ggtt_insert_page(struct i915_address_space
*vm,
static void gmch_ggtt_insert_entries(struct i915_address_space *vm,
struct i915_vma_resource *vma_res,
-enum i915_cache_level cache_level,
+unsigned int pat_index,
u32 unused)
{
- unsigned int flags = (cache_level == I915_CACHE_NONE) ?
+ unsigned int flags = (pat_index == I915_CACHE_NONE) ?
AGP_USER_MEMORY : AGP_USER_CACHED_MEMORY;
intel_gmch_gtt_insert_sg_entries(vma_res->bi.pages, vma_res->start >>
PAGE_SHIFT,
--
2.40.1
[PATCH 1/2] drm/i915/gt: Fix second parameter type of pre-gen8 pte_encode callbacks
When booting a kernel compiled with CONFIG_CFI_CLANG (kCFI), there is a
CFI failure in ggtt_probe_common() when trying to call hsw_pte_encode()
via an indirect call:
[5.030027] CFI failure at ggtt_probe_common+0xd1/0x130 [i915] (target:
hsw_pte_encode+0x0/0x30 [i915]; expected type: 0xf5c1d0fc)
With kCFI, indirect calls are validated against their expected type
versus actual type and failures occur when the two types do not match.
clang's -Wincompatible-function-pointer-types-strict can catch this at
compile time but it is not enabled for the kernel yet:
drivers/gpu/drm/i915/gt/intel_ggtt.c:1155:23: error: incompatible function
pointer types assigning to 'u64 (*)(dma_addr_t, unsigned int, u32)' (aka
'unsigned long long (*)(unsigned int, unsigned int, unsigned int)') from 'u64
(dma_addr_t,
enum i915_cache_level, u32)' (aka 'unsigned long long (unsigned int, enum
i915_cache_level, unsigned int)')
[-Werror,-Wincompatible-function-pointer-types-strict]
ggtt->vm.pte_encode = iris_pte_encode;
^ ~~~
drivers/gpu/drm/i915/gt/intel_ggtt.c:1157:23: error: incompatible function
pointer types assigning to 'u64 (*)(dma_addr_t, unsigned int, u32)' (aka
'unsigned long long (*)(unsigned int, unsigned int, unsigned int)') from 'u64
(dma_addr_t,
enum i915_cache_level, u32)' (aka 'unsigned long long (unsigned int, enum
i915_cache_level, unsigned int)')
[-Werror,-Wincompatible-function-pointer-types-strict]
ggtt->vm.pte_encode = hsw_pte_encode;
^ ~~
drivers/gpu/drm/i915/gt/intel_ggtt.c:1159:23: error: incompatible function
pointer types assigning to 'u64 (*)(dma_addr_t, unsigned int, u32)' (aka
'unsigned long long (*)(unsigned int, unsigned int, unsigned int)') from 'u64
(dma_addr_t,
enum i915_cache_level, u32)' (aka 'unsigned long long (unsigned int, enum
i915_cache_level, unsigned int)')
[-Werror,-Wincompatible-function-pointer-types-strict]
ggtt->vm.pte_encode = byt_pte_encode;
^ ~~
drivers/gpu/drm/i915/gt/intel_ggtt.c:1161:23: error: incompatible function
pointer types assigning to 'u64 (*)(dma_addr_t, unsigned int, u32)' (aka
'unsigned long long (*)(unsigned int, unsigned int, unsigned int)') from 'u64
(dma_addr_t,
enum i915_cache_level, u32)' (aka 'unsigned long long (unsigned int, enum
i915_cache_level, unsigned int)')
[-Werror,-Wincompatible-function-pointer-types-strict]
ggtt->vm.pte_encode = ivb_pte_encode;
^ ~~
drivers/gpu/drm/i915/gt/intel_ggtt.c:1163:23: error: incompatible function
pointer types assigning to 'u64 (*)(dma_addr_t, unsigned int, u32)' (aka
'unsigned long long (*)(unsigned int, unsigned int, unsigned int)') from 'u64
(dma_addr_t,
enum i915_cache_level, u32)' (aka 'unsigned long long (unsigned int, enum
i915_cache_level, unsigned int)')
[-Werror,-Wincompatible-function-pointer-types-strict]
ggtt->vm.pte_encode = snb_pte_encode;
^ ~~
5 errors generated.
In this case, the pre-gen8 pte_encode functions have a second parameter
type of 'enum i915_cache_level' whereas the function pointer prototype
in 'struct i915_address_space' expects a second parameter type of
'unsigned int'.
Update the second parameter of the callbacks and the comment above them
noting that these statements are still valid, which matches other
functions and files, to clear up the kCFI failures at run time.
Fixes: 9275277d5324 ("drm/i915: use pat_index instead of cache_level")
Signed-off-by: Nathan Chancellor
---
drivers/gpu/drm/i915/gt/intel_ggtt.c | 26 +-
1 file changed, 13 insertions(+), 13 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/intel_ggtt.c
b/drivers/gpu/drm/i915/gt/intel_ggtt.c
index 2a7942fac798..122197737ef2 100644
--- a/drivers/gpu/drm/i915/gt/intel_ggtt.c
+++ b/drivers/gpu/drm/i915/gt/intel_ggtt.c
@@ -1015,16 +1015,16 @@ static int gen8_gmch_probe(struct i915_ggtt *ggtt)
/*
* For pre-gen8 platforms pat_index is the same as enum i915_cache_level,
- * so these PTE encode functions are left with using cache_level.
+ * so the switch-case statements in these PTE encode functions are still valid.
* See translation table LEGACY_CACHELEVEL.
*/
static u64 snb_pte_encode(dma_addr_t addr,
- enum i915_cache_level level,
+ unsigned int pat_index,
u32 flags)
{
gen6_pte_t pte = GEN6_PTE_ADDR_ENCODE(addr) | GEN6_PTE_VALID;
- switch (level) {
+ switch (pat_index) {
case I915_CACHE_L3_LLC:
case I915_CACHE_LLC:
pte |= GEN6_PTE_CACHE_LLC;
@@ -1033,19 +1033,19 @@ static u64 snb_pte_encode(dma_addr_t addr,
pte |= GEN6_PTE_UNCACHED;
break;
[PATCH v2 7/7] ARM: dts: qcom: msm8226: Add mdss nodes
Add the nodes that describe the mdss so that display can work on
MSM8226.
Signed-off-by: Luca Weiss
---
arch/arm/boot/dts/qcom-msm8226.dtsi | 127
1 file changed, 127 insertions(+)
diff --git a/arch/arm/boot/dts/qcom-msm8226.dtsi
b/arch/arm/boot/dts/qcom-msm8226.dtsi
index 42acb9ddb8cc..c794f5ece1d1 100644
--- a/arch/arm/boot/dts/qcom-msm8226.dtsi
+++ b/arch/arm/boot/dts/qcom-msm8226.dtsi
@@ -636,6 +636,133 @@ smd-edge {
label = "lpass";
};
};
+
+ mdss: display-subsystem@fd90 {
+ compatible = "qcom,mdss";
+ reg = <0xfd90 0x100>, <0xfd924000 0x1000>;
+ reg-names = "mdss_phys", "vbif_phys";
+
+ power-domains = < MDSS_GDSC>;
+
+ clocks = < MDSS_AHB_CLK>,
+< MDSS_AXI_CLK>,
+< MDSS_VSYNC_CLK>;
+ clock-names = "iface",
+ "bus",
+ "vsync";
+
+ interrupts = ;
+
+ interrupt-controller;
+ #interrupt-cells = <1>;
+
+ #address-cells = <1>;
+ #size-cells = <1>;
+ ranges;
+
+ status = "disabled";
+
+ mdp: display-controller@fd90 {
+ compatible = "qcom,msm8226-mdp5", "qcom,mdp5";
+ reg = <0xfd900100 0x22000>;
+ reg-names = "mdp_phys";
+
+ interrupt-parent = <>;
+ interrupts = <0>;
+
+ clocks = < MDSS_AHB_CLK>,
+< MDSS_AXI_CLK>,
+< MDSS_MDP_CLK>,
+< MDSS_VSYNC_CLK>;
+ clock-names = "iface",
+ "bus",
+ "core",
+ "vsync";
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port@0 {
+ reg = <0>;
+ mdp5_intf1_out: endpoint {
+ remote-endpoint =
<_in>;
+ };
+ };
+ };
+ };
+
+ dsi0: dsi@fd922800 {
+ compatible = "qcom,msm8226-dsi-ctrl",
+"qcom,mdss-dsi-ctrl";
+ reg = <0xfd922800 0x1f8>;
+ reg-names = "dsi_ctrl";
+
+ interrupt-parent = <>;
+ interrupts = <4>;
+
+ assigned-clocks = < BYTE0_CLK_SRC>,
+ < PCLK0_CLK_SRC>;
+ assigned-clock-parents = <_phy0 0>,
+<_phy0 1>;
+
+ clocks = < MDSS_MDP_CLK>,
+< MDSS_AHB_CLK>,
+< MDSS_AXI_CLK>,
+< MDSS_BYTE0_CLK>,
+< MDSS_PCLK0_CLK>,
+< MDSS_ESC0_CLK>,
+< MMSS_MISC_AHB_CLK>;
+ clock-names = "mdp_core",
+ "iface",
+ "bus",
+ "byte",
+ "pixel",
+ "core",
+ "core_mmss";
+
+ phys = <_phy0>;
+
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port@0 {
+ reg = <0>;
+ dsi0_in: endpoint {
+ remote-endpoint =
<_intf1_out>;
+ };
+
[PATCH 0/2] drm/i915/gt: Fix recent kCFI violations
Hi all,
This series fixes a few clang kernel Control Flow Integrity (kCFI)
violations that appear after commit 9275277d5324 ("drm/i915: use
pat_index instead of cache_level"). They were found between run time
testing on real hardware and compile time testing with
-Wincompatible-function-pointer-types-strict (which is not yet enabled
for the kernel but I build with it locally to catch new instances).
If there are any problems or questions, please let me know.
---
Nathan Chancellor (2):
drm/i915/gt: Fix second parameter type of pre-gen8 pte_encode callbacks
drm/i915/gt: Fix parameter in gmch_ggtt_insert_{entries,page}()
drivers/gpu/drm/i915/gt/intel_ggtt.c | 26 +-
drivers/gpu/drm/i915/gt/intel_ggtt_gmch.c | 8
2 files changed, 17 insertions(+), 17 deletions(-)
---
base-commit: 08264f85c5c05ecc38d409c84d48cfb00ccd3bc4
change-id:
20230530-i915-gt-cache_level-wincompatible-function-pointer-types-strict-32a5c65249a5
Best regards,
--
Nathan Chancellor
[PATCH v2 5/7] drm/msm/dsi: Add configuration for MSM8226
Add the config for the v1.0.2 DSI found on MSM8226. We can reuse
existing bits from other revisions that are identical for v1.0.2.
Reviewed-by: Dmitry Baryshkov
Reviewed-by: Konrad Dybcio
Signed-off-by: Luca Weiss
---
drivers/gpu/drm/msm/dsi/dsi_cfg.c | 2 ++
drivers/gpu/drm/msm/dsi/dsi_cfg.h | 1 +
2 files changed, 3 insertions(+)
diff --git a/drivers/gpu/drm/msm/dsi/dsi_cfg.c
b/drivers/gpu/drm/msm/dsi/dsi_cfg.c
index 29ccd755cc2e..8a5fb6df7210 100644
--- a/drivers/gpu/drm/msm/dsi/dsi_cfg.c
+++ b/drivers/gpu/drm/msm/dsi/dsi_cfg.c
@@ -245,6 +245,8 @@ static const struct msm_dsi_cfg_handler dsi_cfg_handlers[]
= {
_dsi_cfg, _dsi_v2_host_ops},
{MSM_DSI_VER_MAJOR_6G, MSM_DSI_6G_VER_MINOR_V1_0,
_apq8084_dsi_cfg, _dsi_6g_host_ops},
+ {MSM_DSI_VER_MAJOR_6G, MSM_DSI_6G_VER_MINOR_V1_0_2,
+ _apq8084_dsi_cfg, _dsi_6g_host_ops},
{MSM_DSI_VER_MAJOR_6G, MSM_DSI_6G_VER_MINOR_V1_1,
_apq8084_dsi_cfg, _dsi_6g_host_ops},
{MSM_DSI_VER_MAJOR_6G, MSM_DSI_6G_VER_MINOR_V1_1_1,
diff --git a/drivers/gpu/drm/msm/dsi/dsi_cfg.h
b/drivers/gpu/drm/msm/dsi/dsi_cfg.h
index 91bdaf50bb1a..43f0dd74edb6 100644
--- a/drivers/gpu/drm/msm/dsi/dsi_cfg.h
+++ b/drivers/gpu/drm/msm/dsi/dsi_cfg.h
@@ -11,6 +11,7 @@
#define MSM_DSI_VER_MAJOR_V2 0x02
#define MSM_DSI_VER_MAJOR_6G 0x03
#define MSM_DSI_6G_VER_MINOR_V1_0 0x1000
+#define MSM_DSI_6G_VER_MINOR_V1_0_20x1002
#define MSM_DSI_6G_VER_MINOR_V1_1 0x1001
#define MSM_DSI_6G_VER_MINOR_V1_1_10x10010001
#define MSM_DSI_6G_VER_MINOR_V1_2 0x1002
--
2.40.1
[PATCH v2 4/7] drm/msm/mdp5: Add MDP5 configuration for MSM8226
Add the required config for the v1.1 MDP5 found on MSM8226.
Reviewed-by: Dmitry Baryshkov
Signed-off-by: Luca Weiss
---
drivers/gpu/drm/msm/disp/mdp5/mdp5_cfg.c | 82
1 file changed, 82 insertions(+)
diff --git a/drivers/gpu/drm/msm/disp/mdp5/mdp5_cfg.c
b/drivers/gpu/drm/msm/disp/mdp5/mdp5_cfg.c
index 2eec2d78f32a..694d54341337 100644
--- a/drivers/gpu/drm/msm/disp/mdp5/mdp5_cfg.c
+++ b/drivers/gpu/drm/msm/disp/mdp5/mdp5_cfg.c
@@ -103,6 +103,87 @@ static const struct mdp5_cfg_hw msm8x74v1_config = {
.max_clk = 2,
};
+static const struct mdp5_cfg_hw msm8x26_config = {
+ .name = "msm8x26",
+ .mdp = {
+ .count = 1,
+ .caps = MDP_CAP_SMP |
+ 0,
+ },
+ .smp = {
+ .mmb_count = 7,
+ .mmb_size = 4096,
+ .clients = {
+ [SSPP_VIG0] = 1,
+ [SSPP_DMA0] = 4,
+ [SSPP_RGB0] = 7,
+ },
+ },
+ .ctl = {
+ .count = 2,
+ .base = { 0x00500, 0x00600 },
+ .flush_hw_mask = 0x0003,
+ },
+ .pipe_vig = {
+ .count = 1,
+ .base = { 0x01100 },
+ .caps = MDP_PIPE_CAP_HFLIP |
+ MDP_PIPE_CAP_VFLIP |
+ MDP_PIPE_CAP_SCALE |
+ MDP_PIPE_CAP_CSC |
+ 0,
+ },
+ .pipe_rgb = {
+ .count = 1,
+ .base = { 0x01d00 },
+ .caps = MDP_PIPE_CAP_HFLIP |
+ MDP_PIPE_CAP_VFLIP |
+ MDP_PIPE_CAP_SCALE |
+ 0,
+ },
+ .pipe_dma = {
+ .count = 1,
+ .base = { 0x02900 },
+ .caps = MDP_PIPE_CAP_HFLIP |
+ MDP_PIPE_CAP_VFLIP |
+ 0,
+ },
+ .lm = {
+ .count = 2,
+ .base = { 0x03100, 0x03d00 },
+ .instances = {
+ { .id = 0, .pp = 0, .dspp = 0,
+ .caps = MDP_LM_CAP_DISPLAY, },
+ { .id = 1, .pp = -1, .dspp = -1,
+ .caps = MDP_LM_CAP_WB },
+},
+ .nb_stages = 2,
+ .max_width = 2048,
+ .max_height = 0x,
+ },
+ .dspp = {
+ .count = 1,
+ .base = { 0x04500 },
+ },
+ .pp = {
+ .count = 1,
+ .base = { 0x21a00 },
+ },
+ .intf = {
+ .base = { 0x0, 0x21200 },
+ .connect = {
+ [0] = INTF_DISABLED,
+ [1] = INTF_DSI,
+ },
+ },
+ .perf = {
+ .ab_inefficiency = 100,
+ .ib_inefficiency = 200,
+ .clk_inefficiency = 125
+ },
+ .max_clk = 2,
+};
+
static const struct mdp5_cfg_hw msm8x74v2_config = {
.name = "msm8x74",
.mdp = {
@@ -1236,6 +1317,7 @@ static const struct mdp5_cfg_hw sdm660_config = {
static const struct mdp5_cfg_handler cfg_handlers_v1[] = {
{ .revision = 0, .config = { .hw = _config } },
+ { .revision = 1, .config = { .hw = _config } },
{ .revision = 2, .config = { .hw = _config } },
{ .revision = 3, .config = { .hw = _config } },
{ .revision = 6, .config = { .hw = _config } },
--
2.40.1
[PATCH v2 2/7] dt-bindings: display/msm: dsi-controller-main: Add msm8226 compatible
Add the compatible for the DSI found on MSM8226. Acked-by: Conor Dooley Signed-off-by: Luca Weiss --- Documentation/devicetree/bindings/display/msm/dsi-controller-main.yaml | 2 ++ 1 file changed, 2 insertions(+) diff --git a/Documentation/devicetree/bindings/display/msm/dsi-controller-main.yaml b/Documentation/devicetree/bindings/display/msm/dsi-controller-main.yaml index 130e16d025bc..660e0f496826 100644 --- a/Documentation/devicetree/bindings/display/msm/dsi-controller-main.yaml +++ b/Documentation/devicetree/bindings/display/msm/dsi-controller-main.yaml @@ -15,6 +15,7 @@ properties: - items: - enum: - qcom,apq8064-dsi-ctrl + - qcom,msm8226-dsi-ctrl - qcom,msm8916-dsi-ctrl - qcom,msm8953-dsi-ctrl - qcom,msm8974-dsi-ctrl @@ -256,6 +257,7 @@ allOf: compatible: contains: enum: + - qcom,msm8226-dsi-ctrl - qcom,msm8974-dsi-ctrl then: properties: -- 2.40.1
[PATCH v2 3/7] dt-bindings: display/msm: qcom,mdp5: Add msm8226 compatible
Add the compatible for the MDP5 found on MSM8226. Acked-by: Conor Dooley Signed-off-by: Luca Weiss --- Documentation/devicetree/bindings/display/msm/qcom,mdp5.yaml | 1 + 1 file changed, 1 insertion(+) diff --git a/Documentation/devicetree/bindings/display/msm/qcom,mdp5.yaml b/Documentation/devicetree/bindings/display/msm/qcom,mdp5.yaml index a763cf8da122..2fe032d0e8f8 100644 --- a/Documentation/devicetree/bindings/display/msm/qcom,mdp5.yaml +++ b/Documentation/devicetree/bindings/display/msm/qcom,mdp5.yaml @@ -22,6 +22,7 @@ properties: - items: - enum: - qcom,apq8084-mdp5 + - qcom,msm8226-mdp5 - qcom,msm8916-mdp5 - qcom,msm8917-mdp5 - qcom,msm8953-mdp5 -- 2.40.1
[PATCH v2 6/7] drm/msm/dsi: Add phy configuration for MSM8226
MSM8226 uses a modified PLL lock sequence compared to MSM8974, which is
based on the function dsi_pll_enable_seq_m in the msm-3.10 kernel.
Worth noting that the msm-3.10 downstream kernel also will try other
sequences in case this one doesn't work, but during testing it has shown
that the _m sequence succeeds first time also:
.pll_enable_seqs[0] = dsi_pll_enable_seq_m,
.pll_enable_seqs[1] = dsi_pll_enable_seq_m,
.pll_enable_seqs[2] = dsi_pll_enable_seq_d,
.pll_enable_seqs[3] = dsi_pll_enable_seq_d,
.pll_enable_seqs[4] = dsi_pll_enable_seq_f1,
.pll_enable_seqs[5] = dsi_pll_enable_seq_c,
.pll_enable_seqs[6] = dsi_pll_enable_seq_e,
We may need to expand this in the future.
Signed-off-by: Luca Weiss
---
drivers/gpu/drm/msm/dsi/phy/dsi_phy.c | 2 +
drivers/gpu/drm/msm/dsi/phy/dsi_phy.h | 3 +-
drivers/gpu/drm/msm/dsi/phy/dsi_phy_28nm.c | 97 ++
3 files changed, 101 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/msm/dsi/phy/dsi_phy.c
b/drivers/gpu/drm/msm/dsi/phy/dsi_phy.c
index bb09cbe8ff86..9d5795c58a98 100644
--- a/drivers/gpu/drm/msm/dsi/phy/dsi_phy.c
+++ b/drivers/gpu/drm/msm/dsi/phy/dsi_phy.c
@@ -541,6 +541,8 @@ static const struct of_device_id dsi_phy_dt_match[] = {
.data = _phy_28nm_hpm_famb_cfgs },
{ .compatible = "qcom,dsi-phy-28nm-lp",
.data = _phy_28nm_lp_cfgs },
+ { .compatible = "qcom,dsi-phy-28nm-8226",
+ .data = _phy_28nm_8226_cfgs },
#endif
#ifdef CONFIG_DRM_MSM_DSI_20NM_PHY
{ .compatible = "qcom,dsi-phy-20nm",
diff --git a/drivers/gpu/drm/msm/dsi/phy/dsi_phy.h
b/drivers/gpu/drm/msm/dsi/phy/dsi_phy.h
index 7137a17ae523..8b640d174785 100644
--- a/drivers/gpu/drm/msm/dsi/phy/dsi_phy.h
+++ b/drivers/gpu/drm/msm/dsi/phy/dsi_phy.h
@@ -46,8 +46,9 @@ struct msm_dsi_phy_cfg {
extern const struct msm_dsi_phy_cfg dsi_phy_28nm_hpm_cfgs;
extern const struct msm_dsi_phy_cfg dsi_phy_28nm_hpm_famb_cfgs;
extern const struct msm_dsi_phy_cfg dsi_phy_28nm_lp_cfgs;
-extern const struct msm_dsi_phy_cfg dsi_phy_20nm_cfgs;
+extern const struct msm_dsi_phy_cfg dsi_phy_28nm_8226_cfgs;
extern const struct msm_dsi_phy_cfg dsi_phy_28nm_8960_cfgs;
+extern const struct msm_dsi_phy_cfg dsi_phy_20nm_cfgs;
extern const struct msm_dsi_phy_cfg dsi_phy_14nm_cfgs;
extern const struct msm_dsi_phy_cfg dsi_phy_14nm_660_cfgs;
extern const struct msm_dsi_phy_cfg dsi_phy_14nm_2290_cfgs;
diff --git a/drivers/gpu/drm/msm/dsi/phy/dsi_phy_28nm.c
b/drivers/gpu/drm/msm/dsi/phy/dsi_phy_28nm.c
index 4c1bf55c5f38..ceec7bb87bf1 100644
--- a/drivers/gpu/drm/msm/dsi/phy/dsi_phy_28nm.c
+++ b/drivers/gpu/drm/msm/dsi/phy/dsi_phy_28nm.c
@@ -37,6 +37,7 @@
/* v2.0.0 28nm LP implementation */
#define DSI_PHY_28NM_QUIRK_PHY_LP BIT(0)
+#define DSI_PHY_28NM_QUIRK_PHY_8226BIT(1)
#define LPFR_LUT_SIZE 10
struct lpfr_cfg {
@@ -377,6 +378,74 @@ static int dsi_pll_28nm_vco_prepare_hpm(struct clk_hw *hw)
return ret;
}
+static int dsi_pll_28nm_vco_prepare_8226(struct clk_hw *hw)
+{
+ struct dsi_pll_28nm *pll_28nm = to_pll_28nm(hw);
+ struct device *dev = _28nm->phy->pdev->dev;
+ void __iomem *base = pll_28nm->phy->pll_base;
+ u32 max_reads = 5, timeout_us = 100;
+ bool locked;
+ u32 val;
+ int i;
+
+ DBG("id=%d", pll_28nm->phy->id);
+
+ pll_28nm_software_reset(pll_28nm);
+
+ /*
+* PLL power up sequence.
+* Add necessary delays recommended by hardware.
+*/
+ dsi_phy_write(base + REG_DSI_28nm_PHY_PLL_CAL_CFG1, 0x34);
+
+ val = DSI_28nm_PHY_PLL_GLB_CFG_PLL_PWRDN_B;
+ dsi_phy_write_udelay(base + REG_DSI_28nm_PHY_PLL_GLB_CFG, val, 200);
+
+ val |= DSI_28nm_PHY_PLL_GLB_CFG_PLL_PWRGEN_PWRDN_B;
+ dsi_phy_write_udelay(base + REG_DSI_28nm_PHY_PLL_GLB_CFG, val, 200);
+
+ val |= DSI_28nm_PHY_PLL_GLB_CFG_PLL_LDO_PWRDN_B;
+ val |= DSI_28nm_PHY_PLL_GLB_CFG_PLL_ENABLE;
+ dsi_phy_write_udelay(base + REG_DSI_28nm_PHY_PLL_GLB_CFG, val, 600);
+
+ for (i = 0; i < 7; i++) {
+ /* DSI Uniphy lock detect setting */
+ dsi_phy_write(base + REG_DSI_28nm_PHY_PLL_LKDET_CFG2, 0x0d);
+ dsi_phy_write_udelay(base + REG_DSI_28nm_PHY_PLL_LKDET_CFG2,
+ 0x0c, 100);
+ dsi_phy_write(base + REG_DSI_28nm_PHY_PLL_LKDET_CFG2, 0x0d);
+
+ /* poll for PLL ready status */
+ locked = pll_28nm_poll_for_ready(pll_28nm,
+ max_reads, timeout_us);
+ if (locked)
+ break;
+
+ pll_28nm_software_reset(pll_28nm);
+
+ /*
+* PLL power up sequence.
+* Add necessary delays recommended by hardware.
+*/
+ dsi_phy_write_udelay(base + REG_DSI_28nm_PHY_PLL_PWRGEN_CFG,
0x00, 50);
+
+ val = DSI_28nm_PHY_PLL_GLB_CFG_PLL_PWRDN_B;
[PATCH v2 0/7] Display support for MSM8226
This series adds the required configs for MDP5 and DSI blocks that are needed for MDSS on MSM8226. Finally we can add the new nodes into the dts. Tested on apq8026-lg-lenok and msm8926-htc-memul. Signed-off-by: Luca Weiss --- Changes in v2: - In dsi-phy-28nm.yaml fix the order of the compatibles 1/7 (Conor) - Remove leftover debugging comments from 6/7 (Konrad) - Rewrap some clock-names lines and move status property last in 7/7 (Konrad) - Pick up tags - Link to v1: https://lore.kernel.org/r/20230308-msm8226-mdp-v1-0-679f335d3...@z3ntu.xyz --- Luca Weiss (7): dt-bindings: msm: dsi-phy-28nm: Document msm8226 compatible dt-bindings: display/msm: dsi-controller-main: Add msm8226 compatible dt-bindings: display/msm: qcom,mdp5: Add msm8226 compatible drm/msm/mdp5: Add MDP5 configuration for MSM8226 drm/msm/dsi: Add configuration for MSM8226 drm/msm/dsi: Add phy configuration for MSM8226 ARM: dts: qcom: msm8226: Add mdss nodes .../bindings/display/msm/dsi-controller-main.yaml | 2 + .../bindings/display/msm/dsi-phy-28nm.yaml | 3 +- .../devicetree/bindings/display/msm/qcom,mdp5.yaml | 1 + .../devicetree/bindings/display/msm/qcom,mdss.yaml | 1 + arch/arm/boot/dts/qcom-msm8226.dtsi| 127 + drivers/gpu/drm/msm/disp/mdp5/mdp5_cfg.c | 82 + drivers/gpu/drm/msm/dsi/dsi_cfg.c | 2 + drivers/gpu/drm/msm/dsi/dsi_cfg.h | 1 + drivers/gpu/drm/msm/dsi/phy/dsi_phy.c | 2 + drivers/gpu/drm/msm/dsi/phy/dsi_phy.h | 3 +- drivers/gpu/drm/msm/dsi/phy/dsi_phy_28nm.c | 97 11 files changed, 319 insertions(+), 2 deletions(-) --- base-commit: e5c87df1b3ab5220362ec48f907cc62ba8928b01 change-id: 20230308-msm8226-mdp-6431e8d672a0 Best regards, -- Luca Weiss
[PATCH v2 1/7] dt-bindings: msm: dsi-phy-28nm: Document msm8226 compatible
The MSM8226 SoC uses a slightly different 28nm dsi phy. Add a new compatible for it. And while we're at it, in the dsi-phy-28nm.yaml move the 8960 compatible to its correct place so its sorted alphabetically. Acked-by: Conor Dooley Signed-off-by: Luca Weiss --- Documentation/devicetree/bindings/display/msm/dsi-phy-28nm.yaml | 3 ++- Documentation/devicetree/bindings/display/msm/qcom,mdss.yaml| 1 + 2 files changed, 3 insertions(+), 1 deletion(-) diff --git a/Documentation/devicetree/bindings/display/msm/dsi-phy-28nm.yaml b/Documentation/devicetree/bindings/display/msm/dsi-phy-28nm.yaml index cf4a338c4661..62fb3e484eb2 100644 --- a/Documentation/devicetree/bindings/display/msm/dsi-phy-28nm.yaml +++ b/Documentation/devicetree/bindings/display/msm/dsi-phy-28nm.yaml @@ -15,10 +15,11 @@ allOf: properties: compatible: enum: + - qcom,dsi-phy-28nm-8226 + - qcom,dsi-phy-28nm-8960 - qcom,dsi-phy-28nm-hpm - qcom,dsi-phy-28nm-hpm-fam-b - qcom,dsi-phy-28nm-lp - - qcom,dsi-phy-28nm-8960 reg: items: diff --git a/Documentation/devicetree/bindings/display/msm/qcom,mdss.yaml b/Documentation/devicetree/bindings/display/msm/qcom,mdss.yaml index b0100105e428..db9f07c6142d 100644 --- a/Documentation/devicetree/bindings/display/msm/qcom,mdss.yaml +++ b/Documentation/devicetree/bindings/display/msm/qcom,mdss.yaml @@ -125,6 +125,7 @@ patternProperties: - qcom,dsi-phy-14nm-660 - qcom,dsi-phy-14nm-8953 - qcom,dsi-phy-20nm + - qcom,dsi-phy-28nm-8226 - qcom,dsi-phy-28nm-hpm - qcom,dsi-phy-28nm-lp - qcom,hdmi-phy-8084 -- 2.40.1
[linux-next:master] BUILD REGRESSION 8c33787278ca8db73ad7d23f932c8c39b9f6e543
tree/branch:
https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git master
branch HEAD: 8c33787278ca8db73ad7d23f932c8c39b9f6e543 Add linux-next specific
files for 20230530
Error/Warning reports:
https://lore.kernel.org/oe-kbuild-all/202305070840.x0g3ofjl-...@intel.com
Error/Warning: (recently discovered and may have been fixed)
include/drm/drm_print.h:456:39: error: format '%ld' expects argument of type
'long int', but argument 4 has type 'size_t' {aka 'unsigned int'}
[-Werror=format=]
Unverified Error/Warning (likely false positive, please contact us if
interested):
arch/arm64/kvm/mmu.c:147:3-9: preceding lock on line 140
fs/smb/client/cifsfs.c:982 cifs_smb3_do_mount() warn: possible memory leak of
'cifs_sb'
fs/smb/client/cifssmb.c:4089 CIFSFindFirst() warn: missing error code? 'rc'
fs/smb/client/cifssmb.c:4216 CIFSFindNext() warn: missing error code? 'rc'
fs/smb/client/connect.c:2725 cifs_match_super() error: 'tlink' dereferencing
possible ERR_PTR()
fs/smb/client/connect.c:2924 generic_ip_connect() error: we previously assumed
'socket' could be null (see line 2912)
fs/smb/server/oplock.c:1013 find_same_lease_key() warn: missing error code 'err'
fs/smb/server/smb2pdu.c:529 smb2_allocate_rsp_buf() warn: Please consider using
kvzalloc instead of kvmalloc
fs/smb/server/smb2pdu.c:6070 smb2_read_pipe() warn: Please consider using
kvzalloc instead of kvmalloc
fs/smb/server/smb2pdu.c:6222 smb2_read() warn: Please consider using kvzalloc
instead of kvmalloc
fs/smb/server/smb2pdu.c:6371 smb2_write_rdma_channel() warn: Please consider
using kvzalloc instead of kvmalloc
fs/smb/server/smb_common.c:350 smb1_allocate_rsp_buf() warn: Please consider
using kzalloc instead of kmalloc
fs/smb/server/transport_ipc.c:232 ipc_msg_alloc() warn: Please consider using
kvzalloc instead of kvmalloc
fs/smb/server/transport_ipc.c:271 handle_response() warn: Please consider using
kvzalloc instead of kvmalloc
fs/smb/server/vfs.c:431 ksmbd_vfs_stream_write() warn: Please consider using
kvzalloc instead of kvmalloc
fs/smb/server/vfs.c:833 ksmbd_vfs_listxattr() warn: Please consider using
kvzalloc instead of kvmalloc
kernel/events/uprobes.c:478 uprobe_write_opcode() warn: passing zero to
'PTR_ERR'
m68k-linux-ld: section .rodata VMA [1000,001556af] overlaps section .text
VMA [0400,006ed04f]
mm/mempolicy.c:1222 new_folio() error: uninitialized symbol 'address'.
Error/Warning ids grouped by kconfigs:
gcc_recent_errors
|-- arm64-randconfig-c031-20230530
| `-- arch-arm64-kvm-mmu.c:preceding-lock-on-line
|-- i386-allyesconfig
| `--
include-drm-drm_print.h:error:format-ld-expects-argument-of-type-long-int-but-argument-has-type-size_t-aka-unsigned-int
|-- i386-randconfig-m021-20230530
| |--
fs-smb-client-cifsfs.c-cifs_smb3_do_mount()-warn:possible-memory-leak-of-cifs_sb
| |-- fs-smb-client-cifssmb.c-CIFSFindFirst()-warn:missing-error-code-rc
| |-- fs-smb-client-cifssmb.c-CIFSFindNext()-warn:missing-error-code-rc
| |--
fs-smb-client-connect.c-cifs_match_super()-error:tlink-dereferencing-possible-ERR_PTR()
| `--
fs-smb-client-connect.c-generic_ip_connect()-error:we-previously-assumed-socket-could-be-null-(see-line-)
|-- m68k-randconfig-m031-20230530
| `--
m68k-linux-ld:section-.rodata-VMA-1556af-overlaps-section-.text-VMA-0ed04f
|-- s390-randconfig-s031-20230530
| `-- mm-filemap.c:sparse:sparse:Using-plain-integer-as-NULL-pointer
`-- x86_64-randconfig-m001-20230530
|--
fs-smb-client-cifsfs.c-cifs_smb3_do_mount()-warn:possible-memory-leak-of-cifs_sb
|-- fs-smb-client-cifssmb.c-CIFSFindFirst()-warn:missing-error-code-rc
|-- fs-smb-client-cifssmb.c-CIFSFindNext()-warn:missing-error-code-rc
|--
fs-smb-client-connect.c-cifs_match_super()-error:tlink-dereferencing-possible-ERR_PTR()
|--
fs-smb-client-connect.c-generic_ip_connect()-error:we-previously-assumed-socket-could-be-null-(see-line-)
|-- fs-smb-server-oplock.c-find_same_lease_key()-warn:missing-error-code-err
|--
fs-smb-server-smb2pdu.c-smb2_allocate_rsp_buf()-warn:Please-consider-using-kvzalloc-instead-of-kvmalloc
|--
fs-smb-server-smb2pdu.c-smb2_read()-warn:Please-consider-using-kvzalloc-instead-of-kvmalloc
|--
fs-smb-server-smb2pdu.c-smb2_read_pipe()-warn:Please-consider-using-kvzalloc-instead-of-kvmalloc
|--
fs-smb-server-smb2pdu.c-smb2_write_rdma_channel()-warn:Please-consider-using-kvzalloc-instead-of-kvmalloc
|--
fs-smb-server-smb_common.c-smb1_allocate_rsp_buf()-warn:Please-consider-using-kzalloc-instead-of-kmalloc
|--
fs-smb-server-transport_ipc.c-handle_response()-warn:Please-consider-using-kvzalloc-instead-of-kvmalloc
|--
fs-smb-server-transport_ipc.c-ipc_msg_alloc()-warn:Please-consider-using-kvzalloc-instead-of-kvmalloc
|--
fs-smb-server-vfs.c-ksmbd_vfs_listxattr()-warn:Please-consider-using-kvzalloc-instead-of-kvmalloc
|--
fs-smb-server-vfs.c-ksmbd_vfs_stream_write()-warn:Please-consider-using-kvzalloc-instead-of-kvmalloc
Re: [PATCH RFC 03/10] drm/panel: Add LGD panel driver for Sony Xperia XZ3
On 2023-05-30 14:11:06, Dmitry Baryshkov wrote:
> On Tue, 30 May 2023 at 11:27, Marijn Suijten
> wrote:
> >
> > On 2023-05-30 01:39:10, Dmitry Baryshkov wrote:
> > > On 30/05/2023 01:37, Marijn Suijten wrote:
> > > > On 2023-05-30 01:18:40, Dmitry Baryshkov wrote:
> > > >
> > > >>> +ret = mipi_dsi_dcs_set_display_on(dsi);
> > > >>> +if (ret < 0) {
> > > >>> +dev_err(dev, "Failed to turn display on: %d\n", ret);
> > > >>> +return ret;
> > > >>> +}
> > > >>
> > > >> My usual question: should the mipi_dsi_dcs_exit_sleep_mode() /
> > > >> mipi_dsi_dcs_set_display_on() be moved from prepare() to enable()
> > > >> part?
> > > >
> > > >
> > > > No, prepare is called before the video stream is started and when
> > > > display is still in LPM mode and the mode hasn't been set.
> > > >
> > >
> > > Yes, that's my point. Shouldn't we enable the panel _after_ starting
> > > the stream?
> > > >>>
> > > >>> I have never investigated what it takes to split these functions, but
> > > >>> some of these panels do show some corruption at startup which may be
> > > >>> circumvented by powering the panel on after starting the video stream?
> > > >>>
> > > >>> I'm just not sure where to make the split: downstream does describe a
> > > >>> qcom,mdss-dsi-on-command and qcom,mdss-dsi-post-panel-on-command,
> > > >>> where
> > > >>> the latter only contains set_display_on() (not exit_sleep_mode()).
> > > >>> It is documented like:
> > > >>>
> > > >>> same as "qcom,mdss-dsi-on-command" except commands are sent
> > > >>> after
> > > >>> displaying an image."
> > > >>>
> > > >>> So this seems like the right way to split them up, I'll test this out
> > > >>> on
> > > >>> all submitted panel drivers.
> > > >>
> > > >> Interesting enough, Neil suggested that sending all the commands during
> > > >> pre_enable() is the correct sequence (especially for VIDEO mode
> > > >> panels),
> > > >> since not all DSI hosts can send commands after switching to the VIDEO
> > > >> mode.
> > > >
> > > > Note that all these panels and Driver-ICs are command-mode, and/or
> > > > programmed to run in command-mode, so there shouldn't be any notion of a
> > > > VIDEO stream (any command-mode frame is just an "arbitrary command" as
> > > > far as I understood).
> > >
> > > Yes, from the data stream point of view. I was talking about the DSI
> > > host being able to send arbitrary commands or not after enabling the
> > > video/cmd stream.
> >
> > Is this a known limitation of SM8250 then? Or is the brightness_set
> > issue more likely a "problem" with the panel that the downstream kernel
> > is "somehow" working around or aware of, and I just haven't found
> > how/where it deals with that?
> > (Alternatively we could be "doing it wrong" for other panels but it
> > turns out to be working anyway)
>
> Please excuse me for not being explicit enough. Qualcomm hardware
> doesn't have this problem. Thus I was completely unaware of it before
> talking to Neil.
> So, our hardware works in most of the cases.
Also excuse me for mocking the hardware here; it seems quite illogical
for it to not work on this specific device which is more likely a
failure in porting the panel DT to the driver than related to this
specific SoC. There's probably one of the hundred-or-so DT params
responsible for triggering a setting, delay, or other magic sequence
that gets the brightness toggle working.
- Marijn
Re: [PATCH RFC 03/10] drm/panel: Add LGD panel driver for Sony Xperia XZ3
On 2023-05-30 10:54:17, Abhinav Kumar wrote:
> > On 30/05/2023 00:07, Marijn Suijten wrote:
> >> On 2023-05-22 15:58:56, Dmitry Baryshkov wrote:
> >>> On Mon, 22 May 2023 at 12:04, Neil Armstrong
> >>> wrote:
>
> On 22/05/2023 03:16, Dmitry Baryshkov wrote:
> > On 22/05/2023 00:23, Marijn Suijten wrote:
> >> Sony provides an unlabeled LGD + Atmel maXTouch assembly in its
> >> Xperia
> >> XZ3 (tama akatsuki) phone, with custom DCS commands to match.
> >>
> >> This panel features Display Stream Compression 1.1.
> >>
> >> Signed-off-by: Marijn Suijten
> >> ---
> >> drivers/gpu/drm/panel/Kconfig | 11 +
> >> drivers/gpu/drm/panel/Makefile | 1 +
> >> drivers/gpu/drm/panel/panel-sony-akatsuki-lgd.c | 362
> >>
> >> 3 files changed, 374 insertions(+)
> >>
> >> diff --git a/drivers/gpu/drm/panel/Kconfig
> >> b/drivers/gpu/drm/panel/Kconfig
> >> index 67ef898d133f2..18bd116e78a71 100644
> >> --- a/drivers/gpu/drm/panel/Kconfig
> >> +++ b/drivers/gpu/drm/panel/Kconfig
> >> @@ -706,6 +706,17 @@ config DRM_PANEL_SONY_ACX565AKM
> >> Say Y here if you want to enable support for the Sony
> >> ACX565AKM
> >> 800x600 3.5" panel (found on the Nokia N900).
> >> +config DRM_PANEL_SONY_AKATSUKI_LGD
> >> + tristate "Sony Xperia XZ3 LGD panel"
> >> + depends on GPIOLIB && OF
> >> + depends on DRM_MIPI_DSI
> >> + depends on BACKLIGHT_CLASS_DEVICE
> >> + help
> >> + Say Y here if you want to enable support for the Sony
> >> Xperia XZ3
> >> + 1440x2880@60 6.0" OLED DSI cmd mode panel produced by LG
> >> Display.
> >> +
> >> + This panel uses Display Stream Compression 1.1.
> >> +
> >> config DRM_PANEL_SONY_TD4353_JDI
> >> tristate "Sony TD4353 JDI panel"
> >> depends on GPIOLIB && OF
> >> diff --git a/drivers/gpu/drm/panel/Makefile
> >> b/drivers/gpu/drm/panel/Makefile
> >> index ff169781e82d7..85133f73558f3 100644
> >> --- a/drivers/gpu/drm/panel/Makefile
> >> +++ b/drivers/gpu/drm/panel/Makefile
> >> @@ -71,6 +71,7 @@ obj-$(CONFIG_DRM_PANEL_SITRONIX_ST7701) +=
> >> panel-sitronix-st7701.o
> >> obj-$(CONFIG_DRM_PANEL_SITRONIX_ST7703) += panel-sitronix-st7703.o
> >> obj-$(CONFIG_DRM_PANEL_SITRONIX_ST7789V) +=
> >> panel-sitronix-st7789v.o
> >> obj-$(CONFIG_DRM_PANEL_SONY_ACX565AKM) += panel-sony-acx565akm.o
> >> +obj-$(CONFIG_DRM_PANEL_SONY_AKATSUKI_LGD) +=
> >> panel-sony-akatsuki-lgd.o
> >> obj-$(CONFIG_DRM_PANEL_SONY_TD4353_JDI) += panel-sony-td4353-jdi.o
> >> obj-$(CONFIG_DRM_PANEL_SONY_TULIP_TRULY_NT35521) +=
> >> panel-sony-tulip-truly-nt35521.o
> >> obj-$(CONFIG_DRM_PANEL_TDO_TL070WSH30) += panel-tdo-tl070wsh30.o
> >> diff --git a/drivers/gpu/drm/panel/panel-sony-akatsuki-lgd.c
> >> b/drivers/gpu/drm/panel/panel-sony-akatsuki-lgd.c
> >> new file mode 100644
> >> index 0..f55788f963dab
> >> --- /dev/null
> >> +++ b/drivers/gpu/drm/panel/panel-sony-akatsuki-lgd.c
> >> @@ -0,0 +1,362 @@
> >> +// SPDX-License-Identifier: GPL-2.0-only
> >> +/*
> >> + * Copyright (c) 2023 Marijn Suijten
> >> + *
> >> + * Based on Sony Downstream's "Atmel LGD ID5" Akatsuki panel dtsi.
> >> + */
> >> +
> >> +#include
> >> +#include
> >> +#include
> >> +#include
> >> +#include
> >> +#include
> >> +#include
> >> +
> >> +#include
> >> +
> >> +#include
> >> +#include
> >> +#include
> >> +#include
> >> +#include
> >> +#include
> >> +
> >> +struct sony_akatsuki_lgd {
> >> + struct drm_panel panel;
> >> + struct mipi_dsi_device *dsi;
> >> + struct regulator *vddio;
> >> + struct gpio_desc *reset_gpio;
> >> + bool prepared;
> >> +};
> >> +
> >> +static inline struct sony_akatsuki_lgd
> >> *to_sony_akatsuki_lgd(struct drm_panel *panel)
> >> +{
> >> + return container_of(panel, struct sony_akatsuki_lgd, panel);
> >> +}
> >> +
> >> +static int sony_akatsuki_lgd_on(struct sony_akatsuki_lgd *ctx)
> >> +{
> >> + struct mipi_dsi_device *dsi = ctx->dsi;
> >> + struct device *dev = >dev;
> >> + int ret;
> >> +
> >> + dsi->mode_flags |= MIPI_DSI_MODE_LPM;
> >> +
> >> + mipi_dsi_dcs_write_seq(dsi, 0x7f, 0x5a, 0x5a);
> >> + mipi_dsi_dcs_write_seq(dsi, 0xf0, 0x5a, 0x5a);
> >> + mipi_dsi_dcs_write_seq(dsi, 0xf1, 0x5a, 0x5a);
> >> + mipi_dsi_dcs_write_seq(dsi, 0xf2, 0x5a, 0x5a);
> >> + mipi_dsi_dcs_write_seq(dsi, 0x02, 0x01);
> >> + mipi_dsi_dcs_write_seq(dsi, 0x59, 0x01);
> >> + /* Enable backlight control */
> >> + mipi_dsi_dcs_write_seq(dsi,
Re: [PATCH 2/2] drm/scheduler: avoid infinite loop if entity's dependency is a scheduled error fence
Am 17.05.23 um 23:01 schrieb Alex Deucher:
On Wed, May 17, 2023 at 11:02 AM Alex Deucher wrote:
+ dri-devel for scheduler
On Tue, May 9, 2023 at 6:23 AM ZhenGuo Yin wrote:
[Why]
drm_sched_entity_add_dependency_cb ignores the scheduled fence and return false.
If entity's dependency is a schedulerd error fence and drm_sched_stop is called
typo: schedulerd -> scheduler
due to TDR, drm_sched_entity_pop_job will wait for the dependency infinitely.
[How]
Do not wait or ignore the scheduled error fence, add drm_sched_entity_wakeup
callback for the dependency with scheduled error fence.
Signed-off-by: ZhenGuo Yin
The series looks good to me, but it would be good to have Christian
take a look as well. Series is:
Acked-by: Alex Deucher
With Alex comments fixes Reviewed-by: Christian König
.
But Luben should probably push the patches upstream through drm-misc-next.
Christian.
---
drivers/gpu/drm/scheduler/sched_entity.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/scheduler/sched_entity.c
b/drivers/gpu/drm/scheduler/sched_entity.c
index d3f4ada6a68e..96e173b0a6c6 100644
--- a/drivers/gpu/drm/scheduler/sched_entity.c
+++ b/drivers/gpu/drm/scheduler/sched_entity.c
@@ -384,7 +384,7 @@ static bool drm_sched_entity_add_dependency_cb(struct
drm_sched_entity *entity)
}
s_fence = to_drm_sched_fence(fence);
- if (s_fence && s_fence->sched == sched &&
+ if (!fence->error && s_fence && s_fence->sched == sched &&
!test_bit(DRM_SCHED_FENCE_DONT_PIPELINE, >flags)) {
/*
--
2.35.1
Re: [PATCH RFC 03/10] drm/panel: Add LGD panel driver for Sony Xperia XZ3
On 5/29/2023 3:18 PM, Dmitry Baryshkov wrote:
On 30/05/2023 00:07, Marijn Suijten wrote:
On 2023-05-22 15:58:56, Dmitry Baryshkov wrote:
On Mon, 22 May 2023 at 12:04, Neil Armstrong
wrote:
On 22/05/2023 03:16, Dmitry Baryshkov wrote:
On 22/05/2023 00:23, Marijn Suijten wrote:
Sony provides an unlabeled LGD + Atmel maXTouch assembly in its
Xperia
XZ3 (tama akatsuki) phone, with custom DCS commands to match.
This panel features Display Stream Compression 1.1.
Signed-off-by: Marijn Suijten
---
drivers/gpu/drm/panel/Kconfig | 11 +
drivers/gpu/drm/panel/Makefile | 1 +
drivers/gpu/drm/panel/panel-sony-akatsuki-lgd.c | 362
3 files changed, 374 insertions(+)
diff --git a/drivers/gpu/drm/panel/Kconfig
b/drivers/gpu/drm/panel/Kconfig
index 67ef898d133f2..18bd116e78a71 100644
--- a/drivers/gpu/drm/panel/Kconfig
+++ b/drivers/gpu/drm/panel/Kconfig
@@ -706,6 +706,17 @@ config DRM_PANEL_SONY_ACX565AKM
Say Y here if you want to enable support for the Sony
ACX565AKM
800x600 3.5" panel (found on the Nokia N900).
+config DRM_PANEL_SONY_AKATSUKI_LGD
+ tristate "Sony Xperia XZ3 LGD panel"
+ depends on GPIOLIB && OF
+ depends on DRM_MIPI_DSI
+ depends on BACKLIGHT_CLASS_DEVICE
+ help
+ Say Y here if you want to enable support for the Sony
Xperia XZ3
+ 1440x2880@60 6.0" OLED DSI cmd mode panel produced by LG
Display.
+
+ This panel uses Display Stream Compression 1.1.
+
config DRM_PANEL_SONY_TD4353_JDI
tristate "Sony TD4353 JDI panel"
depends on GPIOLIB && OF
diff --git a/drivers/gpu/drm/panel/Makefile
b/drivers/gpu/drm/panel/Makefile
index ff169781e82d7..85133f73558f3 100644
--- a/drivers/gpu/drm/panel/Makefile
+++ b/drivers/gpu/drm/panel/Makefile
@@ -71,6 +71,7 @@ obj-$(CONFIG_DRM_PANEL_SITRONIX_ST7701) +=
panel-sitronix-st7701.o
obj-$(CONFIG_DRM_PANEL_SITRONIX_ST7703) += panel-sitronix-st7703.o
obj-$(CONFIG_DRM_PANEL_SITRONIX_ST7789V) +=
panel-sitronix-st7789v.o
obj-$(CONFIG_DRM_PANEL_SONY_ACX565AKM) += panel-sony-acx565akm.o
+obj-$(CONFIG_DRM_PANEL_SONY_AKATSUKI_LGD) +=
panel-sony-akatsuki-lgd.o
obj-$(CONFIG_DRM_PANEL_SONY_TD4353_JDI) += panel-sony-td4353-jdi.o
obj-$(CONFIG_DRM_PANEL_SONY_TULIP_TRULY_NT35521) +=
panel-sony-tulip-truly-nt35521.o
obj-$(CONFIG_DRM_PANEL_TDO_TL070WSH30) += panel-tdo-tl070wsh30.o
diff --git a/drivers/gpu/drm/panel/panel-sony-akatsuki-lgd.c
b/drivers/gpu/drm/panel/panel-sony-akatsuki-lgd.c
new file mode 100644
index 0..f55788f963dab
--- /dev/null
+++ b/drivers/gpu/drm/panel/panel-sony-akatsuki-lgd.c
@@ -0,0 +1,362 @@
+// SPDX-License-Identifier: GPL-2.0-only
+/*
+ * Copyright (c) 2023 Marijn Suijten
+ *
+ * Based on Sony Downstream's "Atmel LGD ID5" Akatsuki panel dtsi.
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include
+
+#include
+#include
+#include
+#include
+#include
+#include
+
+struct sony_akatsuki_lgd {
+ struct drm_panel panel;
+ struct mipi_dsi_device *dsi;
+ struct regulator *vddio;
+ struct gpio_desc *reset_gpio;
+ bool prepared;
+};
+
+static inline struct sony_akatsuki_lgd
*to_sony_akatsuki_lgd(struct drm_panel *panel)
+{
+ return container_of(panel, struct sony_akatsuki_lgd, panel);
+}
+
+static int sony_akatsuki_lgd_on(struct sony_akatsuki_lgd *ctx)
+{
+ struct mipi_dsi_device *dsi = ctx->dsi;
+ struct device *dev = >dev;
+ int ret;
+
+ dsi->mode_flags |= MIPI_DSI_MODE_LPM;
+
+ mipi_dsi_dcs_write_seq(dsi, 0x7f, 0x5a, 0x5a);
+ mipi_dsi_dcs_write_seq(dsi, 0xf0, 0x5a, 0x5a);
+ mipi_dsi_dcs_write_seq(dsi, 0xf1, 0x5a, 0x5a);
+ mipi_dsi_dcs_write_seq(dsi, 0xf2, 0x5a, 0x5a);
+ mipi_dsi_dcs_write_seq(dsi, 0x02, 0x01);
+ mipi_dsi_dcs_write_seq(dsi, 0x59, 0x01);
+ /* Enable backlight control */
+ mipi_dsi_dcs_write_seq(dsi, MIPI_DCS_WRITE_CONTROL_DISPLAY,
BIT(5));
+ mipi_dsi_dcs_write_seq(dsi, 0x57, 0x20, 0x80, 0xde, 0x60, 0x00);
+
+ ret = mipi_dsi_dcs_set_column_address(dsi, 0, 1440 - 1);
+ if (ret < 0) {
+ dev_err(dev, "Failed to set column address: %d\n", ret);
+ return ret;
+ }
+
+ ret = mipi_dsi_dcs_set_page_address(dsi, 0, 2880 - 1);
+ if (ret < 0) {
+ dev_err(dev, "Failed to set page address: %d\n", ret);
+ return ret;
+ }
+
+ mipi_dsi_dcs_write_seq(dsi, MIPI_DCS_WRITE_POWER_SAVE, 0x00);
+
+ ret = mipi_dsi_dcs_set_tear_on(dsi,
MIPI_DSI_DCS_TEAR_MODE_VBLANK);
+ if (ret < 0) {
+ dev_err(dev, "Failed to set tear on: %d\n", ret);
+ return ret;
+ }
+
+ mipi_dsi_dcs_write_seq(dsi, 0x7f, 0x5a, 0x5a);
+ mipi_dsi_dcs_write_seq(dsi, 0xf0, 0x5a, 0x5a);
+ mipi_dsi_dcs_write_seq(dsi, 0xf1, 0x5a, 0x5a);
+ mipi_dsi_dcs_write_seq(dsi, 0xf2, 0x5a, 0x5a);
+ mipi_dsi_dcs_write_seq(dsi, 0xb0, 0x03);
+ mipi_dsi_dcs_write_seq(dsi, 0xf6, 0x04);
+ mipi_dsi_dcs_write_seq(dsi, 0xb0, 0x05);
+
