Re: [Freedreno] [PATCH 5/6] drm/msm/dpu: Add hw revision 4.1 (SDM670)
On 26.09.2023 01:26, Richard Acayan wrote:
> The Snapdragon 670 uses similar clocks (with one frequency added) to the
> Snapdragon 845 but reports DPU revision 4.1. Add support for this DPU
> with configuration from the Pixel 3a downstream kernel.
>
> Since revision 4.0 is SDM845, reuse some configuration from its catalog
> entry.
>
> Link:
> https://android.googlesource.com/kernel/msm/+/368478b0ae76566927a2769a2bf24dfe7f38bb78/arch/arm64/boot/dts/qcom/sdm670-sde.dtsi
> Signed-off-by: Richard Acayan
> ---
> .../msm/disp/dpu1/catalog/dpu_4_1_sdm670.h| 105 ++
> .../gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c| 6 +
> .../gpu/drm/msm/disp/dpu1/dpu_hw_catalog.h| 1 +
> drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c | 1 +
> 4 files changed, 113 insertions(+)
> create mode 100644 drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_4_1_sdm670.h
>
> diff --git a/drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_4_1_sdm670.h
> b/drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_4_1_sdm670.h
> new file mode 100644
> index ..eaccb16b5db9
> --- /dev/null
> +++ b/drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_4_1_sdm670.h
> @@ -0,0 +1,105 @@
> +/* SPDX-License-Identifier: GPL-2.0-only */
> +/*
> + * Copyright (c) 2015-2018, The Linux Foundation. All rights reserved.
> + * Copyright (c) 2022. Qualcomm Innovation Center, Inc. All rights reserved.
> + * Copyright (c) 2023, Richard Acayan. All rights reserved.
> + */
> +
> +#ifndef _DPU_4_1_SDM670_H
> +#define _DPU_4_1_SDM670_H
> +
> +static const struct dpu_mdp_cfg sdm670_mdp = {
> + .name = "top_0",
> + .base = 0x0, .len = 0x45c,
> + .features = BIT(DPU_MDP_AUDIO_SELECT),
> + .clk_ctrls = {
> + [DPU_CLK_CTRL_VIG0] = { .reg_off = 0x2ac, .bit_off = 0},
space before the closing curly bracket, please
[...]
> +
> +static struct dpu_dsc_cfg sdm670_dsc[] = {
const
Konrad
Re: [Freedreno] [PATCH v2 1/1] drm/msm/adreno: Add support for SM7150 SoC machine
On 26.09.2023 21:10, Danila Tikhonov wrote: > > I think you mean by name downstream dt - sdmmagpie-gpu.dtsi > > You can see the forked version of the mainline here: > https://github.com/sm7150-mainline/linux/blob/next/arch/arm64/boot/dts/qcom/sm7150.dtsi > > All fdt that we got here, if it is useful for you: > https://github.com/sm7150-mainline/downstream-fdt > > Best wishes, Danila Taking a look at downstream, atoll.dtsi (SC7180) includes sdmmagpie-gpu.dtsi. Bottom line is, they share the speed bins, so it should be fine to just extend the existing entry. Konrad
Re: [Freedreno] [PATCH v2 1/1] drm/msm/adreno: Add support for SM7150 SoC machine
I think you mean by name downstream dt - sdmmagpie-gpu.dtsi You can see the forked version of the mainline here: https://github.com/sm7150-mainline/linux/blob/next/arch/arm64/boot/dts/qcom/sm7150.dtsi All fdt that we got here, if it is useful for you: https://github.com/sm7150-mainline/downstream-fdt Best wishes, Danila On 26.09.2023 20:40, Konrad Dybcio wrote: > On 26.09.2023 19:42, Danila Tikhonov wrote: > > SM7150 has 5 power levels which correspond to 5 speed-bin values: 0, > > 128, 146, 167, 172. Speed-bin value is calulated as FMAX/4.8MHz round up > > to zero decimal places. > > > > Also a618 on SM7150 uses a615 zapfw. Add a squashed version (.mbn). > > > > Add this as machine = "qcom,sm7150", because speed-bin values are > > different from atoll (sc7180/sm7125). > > > > Signed-off-by: Danila Tikhonov < dan...@jiaxyga.com > > > --- > What's the downstream dt name for 7150? > > Do you have some more complete tree published somewhere? > > Konrad
Re: [Freedreno] [PATCH v2 1/1] drm/msm/adreno: Add support for SM7150 SoC machine
On 26.09.2023 19:42, Danila Tikhonov wrote: > SM7150 has 5 power levels which correspond to 5 speed-bin values: 0, > 128, 146, 167, 172. Speed-bin value is calulated as FMAX/4.8MHz round up > to zero decimal places. > > Also a618 on SM7150 uses a615 zapfw. Add a squashed version (.mbn). > > Add this as machine = "qcom,sm7150", because speed-bin values are > different from atoll (sc7180/sm7125). > > Signed-off-by: Danila Tikhonov > --- What's the downstream dt name for 7150? Do you have some more complete tree published somewhere? Konrad
Re: [Freedreno] [PATCH 4/7] arm64: dts: qcom: sc7280: Add ZAP shader support
On 26.09.2023 20:24, Konrad Dybcio wrote:
> Non-Chrome SC7280-family platforms ship a ZAP shader with the Adreno GPU.
> Describe that and make sure it doesn't interfere with Chrome devices.
>
> Signed-off-by: Konrad Dybcio
> ---
> arch/arm64/boot/dts/qcom/sc7280-chrome-common.dtsi | 2 ++
> arch/arm64/boot/dts/qcom/sc7280.dtsi | 10 ++
> 2 files changed, 12 insertions(+)
>
> diff --git a/arch/arm64/boot/dts/qcom/sc7280-chrome-common.dtsi
> b/arch/arm64/boot/dts/qcom/sc7280-chrome-common.dtsi
> index 5d462ae14ba1..88fc67c3646e 100644
> --- a/arch/arm64/boot/dts/qcom/sc7280-chrome-common.dtsi
> +++ b/arch/arm64/boot/dts/qcom/sc7280-chrome-common.dtsi
> @@ -17,6 +17,8 @@
> * required by the setup for Chrome boards.
> */
>
> +/delete-node/ &gpu_zap_mem;
> +/delete-node/ &gpu_zap_shader;
> /delete-node/ &hyp_mem;
> /delete-node/ &xbl_mem;
> /delete-node/ &reserved_xbl_uefi_log;
> diff --git a/arch/arm64/boot/dts/qcom/sc7280.dtsi
> b/arch/arm64/boot/dts/qcom/sc7280.dtsi
> index 66f1eb83cca7..c38ddf267ef5 100644
> --- a/arch/arm64/boot/dts/qcom/sc7280.dtsi
> +++ b/arch/arm64/boot/dts/qcom/sc7280.dtsi
> @@ -152,6 +152,11 @@ ipa_fw_mem: memory@8b70 {
> no-map;
> };
>
> + gpu_zap_mem: zap@8b71a000 {
> + reg = <0 0x8b71a000 0 0x2000>;
> + no-map;
> + };
> +
> rmtfs_mem: memory@9c90 {
> compatible = "qcom,rmtfs-mem";
> reg = <0x0 0x9c90 0x0 0x28>;
> @@ -2608,6 +2613,11 @@ gpu: gpu@3d0 {
> nvmem-cells = <&gpu_speed_bin>;
> nvmem-cell-names = "speed_bin";
>
> + gpu_zap_shader: zap-shader {
> + memory-region = <&gpu_zap_mem>;
> + firmware-name = "qcom/a660_zap.mdt";
Gah. This line shouldn't have been there.
Considering it's not the only oops, I'll resend.
Konrad
Re: [Freedreno] [PATCH 6/7] arm64: dts: qcom: sc7280: Mark Adreno SMMU as DMA coherent
On 26.09.2023 20:24, Konrad Dybcio wrote:
> The SMMUs on sc7280 are cache-coherent. APPS_SMMU is marked as such,
> mark the GPU one as well.
>
> Signed-off-by: Konrad Dybcio
> ---
Fixes: 96c471970b7b ("arm64: dts: qcom: sc7280: Add gpu support")
Sorry.
Konrad
[Freedreno] [PATCH 7/7] arm64: dts: qcom: sc7280: Add 0xac Adreno speed bin
A643 (A635 speedbin 0xac) tops out at 812 MHz. Fill in the
opp-supported-hw appropriately.
Note that fuseval 0xac is referred to as speedbin 1 downstream, but
that was already in use upstream, so 2 was chosen instead.
Signed-off-by: Konrad Dybcio
---
arch/arm64/boot/dts/qcom/sc7280.dtsi | 12 ++--
1 file changed, 6 insertions(+), 6 deletions(-)
diff --git a/arch/arm64/boot/dts/qcom/sc7280.dtsi
b/arch/arm64/boot/dts/qcom/sc7280.dtsi
index edaca6c2cf8c..ccc2dd6c45de 100644
--- a/arch/arm64/boot/dts/qcom/sc7280.dtsi
+++ b/arch/arm64/boot/dts/qcom/sc7280.dtsi
@@ -2626,14 +2626,14 @@ opp-31500 {
opp-hz = /bits/ 64 <31500>;
opp-level =
;
opp-peak-kBps = <1804000>;
- opp-supported-hw = <0x03>;
+ opp-supported-hw = <0x07>;
};
opp-45000 {
opp-hz = /bits/ 64 <45000>;
opp-level = ;
opp-peak-kBps = <4068000>;
- opp-supported-hw = <0x03>;
+ opp-supported-hw = <0x07>;
};
/* Only applicable for SKUs which has 550Mhz as
Fmax */
@@ -2648,28 +2648,28 @@ opp-55000-1 {
opp-hz = /bits/ 64 <55000>;
opp-level =
;
opp-peak-kBps = <6832000>;
- opp-supported-hw = <0x02>;
+ opp-supported-hw = <0x06>;
};
opp-60800 {
opp-hz = /bits/ 64 <60800>;
opp-level =
;
opp-peak-kBps = <8368000>;
- opp-supported-hw = <0x02>;
+ opp-supported-hw = <0x06>;
};
opp-7 {
opp-hz = /bits/ 64 <7>;
opp-level = ;
opp-peak-kBps = <8532000>;
- opp-supported-hw = <0x02>;
+ opp-supported-hw = <0x06>;
};
opp-81200 {
opp-hz = /bits/ 64 <81200>;
opp-level =
;
opp-peak-kBps = <8532000>;
- opp-supported-hw = <0x02>;
+ opp-supported-hw = <0x06>;
};
opp-84000 {
--
2.42.0
[Freedreno] [PATCH 6/7] arm64: dts: qcom: sc7280: Mark Adreno SMMU as DMA coherent
The SMMUs on sc7280 are cache-coherent. APPS_SMMU is marked as such,
mark the GPU one as well.
Signed-off-by: Konrad Dybcio
---
arch/arm64/boot/dts/qcom/sc7280.dtsi | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arm64/boot/dts/qcom/sc7280.dtsi
b/arch/arm64/boot/dts/qcom/sc7280.dtsi
index 0d96d1454c49..edaca6c2cf8c 100644
--- a/arch/arm64/boot/dts/qcom/sc7280.dtsi
+++ b/arch/arm64/boot/dts/qcom/sc7280.dtsi
@@ -2783,6 +2783,7 @@ adreno_smmu: iommu@3da {
"gpu_cc_hub_aon_clk";
power-domains = <&gpucc GPU_CC_CX_GDSC>;
+ dma-coherent;
};
remoteproc_mpss: remoteproc@408 {
--
2.42.0
[Freedreno] [PATCH 5/7] arm64: dts: qcom: sc7280: Fix up GPU SIDs
GPU_SMMU SID 1 is meant for Adreno LPAC (Low Priority Async Compute).
On platforms that support it (in firmware), it is necessary to
describe that link, or Adreno register access will hang the board.
Add that and fix up the SMR mask of SID 0, which seems to have been
copypasted from another SoC.
Fixes: 96c471970b7b ("arm64: dts: qcom: sc7280: Add gpu support")
Signed-off-by: Konrad Dybcio
---
arch/arm64/boot/dts/qcom/sc7280.dtsi | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/arch/arm64/boot/dts/qcom/sc7280.dtsi
b/arch/arm64/boot/dts/qcom/sc7280.dtsi
index c38ddf267ef5..0d96d1454c49 100644
--- a/arch/arm64/boot/dts/qcom/sc7280.dtsi
+++ b/arch/arm64/boot/dts/qcom/sc7280.dtsi
@@ -2603,7 +2603,8 @@ gpu: gpu@3d0 {
"cx_mem",
"cx_dbgc";
interrupts = ;
- iommus = <&adreno_smmu 0 0x401>;
+ iommus = <&adreno_smmu 0 0x400>,
+<&adreno_smmu 1 0x400>;
operating-points-v2 = <&gpu_opp_table>;
qcom,gmu = <&gmu>;
interconnects = <&gem_noc MASTER_GFX3D 0 &mc_virt
SLAVE_EBI1 0>;
--
2.42.0
[Freedreno] [PATCH 4/7] arm64: dts: qcom: sc7280: Add ZAP shader support
Non-Chrome SC7280-family platforms ship a ZAP shader with the Adreno GPU.
Describe that and make sure it doesn't interfere with Chrome devices.
Signed-off-by: Konrad Dybcio
---
arch/arm64/boot/dts/qcom/sc7280-chrome-common.dtsi | 2 ++
arch/arm64/boot/dts/qcom/sc7280.dtsi | 10 ++
2 files changed, 12 insertions(+)
diff --git a/arch/arm64/boot/dts/qcom/sc7280-chrome-common.dtsi
b/arch/arm64/boot/dts/qcom/sc7280-chrome-common.dtsi
index 5d462ae14ba1..88fc67c3646e 100644
--- a/arch/arm64/boot/dts/qcom/sc7280-chrome-common.dtsi
+++ b/arch/arm64/boot/dts/qcom/sc7280-chrome-common.dtsi
@@ -17,6 +17,8 @@
* required by the setup for Chrome boards.
*/
+/delete-node/ &gpu_zap_mem;
+/delete-node/ &gpu_zap_shader;
/delete-node/ &hyp_mem;
/delete-node/ &xbl_mem;
/delete-node/ &reserved_xbl_uefi_log;
diff --git a/arch/arm64/boot/dts/qcom/sc7280.dtsi
b/arch/arm64/boot/dts/qcom/sc7280.dtsi
index 66f1eb83cca7..c38ddf267ef5 100644
--- a/arch/arm64/boot/dts/qcom/sc7280.dtsi
+++ b/arch/arm64/boot/dts/qcom/sc7280.dtsi
@@ -152,6 +152,11 @@ ipa_fw_mem: memory@8b70 {
no-map;
};
+ gpu_zap_mem: zap@8b71a000 {
+ reg = <0 0x8b71a000 0 0x2000>;
+ no-map;
+ };
+
rmtfs_mem: memory@9c90 {
compatible = "qcom,rmtfs-mem";
reg = <0x0 0x9c90 0x0 0x28>;
@@ -2608,6 +2613,11 @@ gpu: gpu@3d0 {
nvmem-cells = <&gpu_speed_bin>;
nvmem-cell-names = "speed_bin";
+ gpu_zap_shader: zap-shader {
+ memory-region = <&gpu_zap_mem>;
+ firmware-name = "qcom/a660_zap.mdt";
+ };
+
gpu_opp_table: opp-table {
compatible = "operating-points-v2";
--
2.42.0
[Freedreno] [PATCH 1/7] drm/msm/a6xx: Fix unknown speedbin case
When opp-supported-hw is present under an OPP node, but no form of
opp_set_supported_hw() has been called, that OPP is ignored by the API
and marked as unsupported.
Before Commit c928a05e4415 ("drm/msm/adreno: Move speedbin mapping to
device table"), an unknown speedbin would result in marking all OPPs
as available, but it's better to avoid potentially overclocking the
silicon - the GMU will simply refuse to power up the chip.
Currently, the Adreno speedbin code does just that (AND returns an
invalid error, (int)UINT_MAX). Fix that by defaulting to speedbin 0
(which is conveniently always bound to fuseval == 0).
Fixes: c928a05e4415 ("drm/msm/adreno: Move speedbin mapping to device table")
Signed-off-by: Konrad Dybcio
---
drivers/gpu/drm/msm/adreno/a6xx_gpu.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/msm/adreno/a6xx_gpu.c
b/drivers/gpu/drm/msm/adreno/a6xx_gpu.c
index d4e85e24002f..522ca7fe6762 100644
--- a/drivers/gpu/drm/msm/adreno/a6xx_gpu.c
+++ b/drivers/gpu/drm/msm/adreno/a6xx_gpu.c
@@ -2237,7 +2237,7 @@ static int a6xx_set_supported_hw(struct device *dev,
const struct adreno_info *i
DRM_DEV_ERROR(dev,
"missing support for speed-bin: %u. Some OPPs may not
be supported by hardware\n",
speedbin);
- return UINT_MAX;
+ supp_hw = BIT(0); /* Default */
}
ret = devm_pm_opp_set_supported_hw(dev, &supp_hw, 1);
--
2.42.0
[Freedreno] [PATCH 3/7] drm/msm/adreno: Add A635 speedbin 0xac (A643)
Downstream calls this the "speedbin 1", but that number is already
occupied. Use index two.
Signed-off-by: Konrad Dybcio
---
drivers/gpu/drm/msm/adreno/adreno_device.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/gpu/drm/msm/adreno/adreno_device.c
b/drivers/gpu/drm/msm/adreno/adreno_device.c
index 16527fe8584d..4977fd759b5b 100644
--- a/drivers/gpu/drm/msm/adreno/adreno_device.c
+++ b/drivers/gpu/drm/msm/adreno/adreno_device.c
@@ -460,6 +460,7 @@ static const struct adreno_info gpulist[] = {
.speedbins = ADRENO_SPEEDBINS(
{ 0, 0 },
{ 117, 0 },
+ { 172, 2 }, /* Called speedbin 1 downstream, but let's
not break things! */
{ 190, 1 },
),
}, {
--
2.42.0
[Freedreno] [PATCH 2/7] drm/msm/adreno: Add ZAP firmware name to A635
Some (many?) devices with A635 expect a ZAP shader to be loaded.
Set the file name to allow for that.
Signed-off-by: Konrad Dybcio
---
drivers/gpu/drm/msm/adreno/adreno_device.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/gpu/drm/msm/adreno/adreno_device.c
b/drivers/gpu/drm/msm/adreno/adreno_device.c
index fa527935ffd4..16527fe8584d 100644
--- a/drivers/gpu/drm/msm/adreno/adreno_device.c
+++ b/drivers/gpu/drm/msm/adreno/adreno_device.c
@@ -454,6 +454,7 @@ static const struct adreno_info gpulist[] = {
.quirks = ADRENO_QUIRK_HAS_CACHED_COHERENT |
ADRENO_QUIRK_HAS_HW_APRIV,
.init = a6xx_gpu_init,
+ .zapfw = "a660_zap.mbn",
.hwcg = a660_hwcg,
.address_space_size = SZ_16G,
.speedbins = ADRENO_SPEEDBINS(
--
2.42.0
[Freedreno] [PATCH 0/7] Adreno 643 + fixes
as it says on the can drm/msm patches for Rob arm64 patches for linux-arm-msm for use with https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/25408 tested on QCM6490 (SC7280-IOT) Fairphone FP5 Signed-off-by: Konrad Dybcio --- Konrad Dybcio (7): drm/msm/a6xx: Fix unknown speedbin case drm/msm/adreno: Add ZAP firmware name to A635 drm/msm/adreno: Add A635 speedbin 0xac (A643) arm64: dts: qcom: sc7280: Add ZAP shader support arm64: dts: qcom: sc7280: Fix up GPU SIDs arm64: dts: qcom: sc7280: Mark Adreno SMMU as DMA coherent arm64: dts: qcom: sc7280: Add 0xac Adreno speed bin arch/arm64/boot/dts/qcom/sc7280-chrome-common.dtsi | 2 ++ arch/arm64/boot/dts/qcom/sc7280.dtsi | 26 -- drivers/gpu/drm/msm/adreno/a6xx_gpu.c | 2 +- drivers/gpu/drm/msm/adreno/adreno_device.c | 2 ++ 4 files changed, 24 insertions(+), 8 deletions(-) --- base-commit: 4ae73bba62a367f2314f6ce69e3085a941983d8b change-id: 20230926-topic-a643-a7ec9a08a3a1 Best regards, -- Konrad Dybcio
[Freedreno] [PATCH v2 0/1] drm/msm/adreno: Add support for SM7150
This patch adds support for SM7150 SoC machine. Changes in v2: - Use a630_gmu.bin instead of a618_gmu.bin. - Use squashed version of a615_zap (.mbn). - Drop .revn. - Link to v1: https://lore.kernel.org/all/20230913191957.26537-1-dan...@jiaxyga.com/ Danila Tikhonov (1): drm/msm/adreno: Add support for SM7150 SoC machine drivers/gpu/drm/msm/adreno/adreno_device.c | 22 ++ 1 file changed, 22 insertions(+) -- 2.34.1
[Freedreno] [PATCH v2 1/1] drm/msm/adreno: Add support for SM7150 SoC machine
SM7150 has 5 power levels which correspond to 5 speed-bin values: 0,
128, 146, 167, 172. Speed-bin value is calulated as FMAX/4.8MHz round up
to zero decimal places.
Also a618 on SM7150 uses a615 zapfw. Add a squashed version (.mbn).
Add this as machine = "qcom,sm7150", because speed-bin values are
different from atoll (sc7180/sm7125).
Signed-off-by: Danila Tikhonov
---
drivers/gpu/drm/msm/adreno/adreno_device.c | 22 ++
1 file changed, 22 insertions(+)
diff --git a/drivers/gpu/drm/msm/adreno/adreno_device.c
b/drivers/gpu/drm/msm/adreno/adreno_device.c
index fa527935ffd4..cb2f459cbcc4 100644
--- a/drivers/gpu/drm/msm/adreno/adreno_device.c
+++ b/drivers/gpu/drm/msm/adreno/adreno_device.c
@@ -293,6 +293,27 @@ static const struct adreno_info gpulist[] = {
{ 157, 3 },
{ 127, 4 },
),
+ }, {
+ .machine = "qcom,sm7150",
+ .chip_ids = ADRENO_CHIP_IDS(0x06010800),
+ .family = ADRENO_6XX_GEN1,
+ .fw = {
+ [ADRENO_FW_SQE] = "a630_sqe.fw",
+ [ADRENO_FW_GMU] = "a630_gmu.bin",
+ },
+ .gmem = SZ_512K,
+ .inactive_period = DRM_MSM_INACTIVE_PERIOD,
+ .quirks = ADRENO_QUIRK_HAS_CACHED_COHERENT,
+ .init = a6xx_gpu_init,
+ .zapfw = "a615_zap.mbn",
+ .hwcg = a615_hwcg,
+ .speedbins = ADRENO_SPEEDBINS(
+ { 0, 0 },
+ { 128, 1 },
+ { 146, 2 },
+ { 167, 3 },
+ { 172, 4 },
+ ),
}, {
.chip_ids = ADRENO_CHIP_IDS(0x06010800),
.family = ADRENO_6XX_GEN1,
@@ -507,6 +528,7 @@ MODULE_FIRMWARE("qcom/a530_zap.b00");
MODULE_FIRMWARE("qcom/a530_zap.b01");
MODULE_FIRMWARE("qcom/a530_zap.b02");
MODULE_FIRMWARE("qcom/a540_gpmu.fw2");
+MODULE_FIRMWARE("qcom/a615_zap.mbn");
MODULE_FIRMWARE("qcom/a619_gmu.bin");
MODULE_FIRMWARE("qcom/a630_sqe.fw");
MODULE_FIRMWARE("qcom/a630_gmu.bin");
--
2.34.1
Re: [Freedreno] [PATCH RFC v6 00/10] Support for Solid Fill Planes
On 2023-08-28 20:05, Jessica Zhang wrote: > Some drivers support hardware that have optimizations for solid fill > planes. This series aims to expose these capabilities to userspace as > some compositors have a solid fill flag (ex. SOLID_COLOR in the Android > hardware composer HAL) that can be set by apps like the Android Gears > app. > > In order to expose this capability to userspace, this series will: > > - Introduce solid_fill and pixel_source properties to allow userspace to > toggle between FB and solid fill sources > - Loosen NULL FB checks within the DRM atomic commit callstack to allow > for NULL FB when solid fill is enabled. > - Add NULL FB checks in methods where FB was previously assumed to be > non-NULL > - Have MSM DPU driver use drm_plane_state.solid_fill instead of > dpu_plane_state.color_fill > > Note: The solid fill planes feature depends on both the solid_fill *and* > pixel_source properties. > > To use this feature, userspace can set the solid_fill property to a blob > containing the appropriate version number and solid fill color (in > RGB323232 format) and and setting the pixel_source property to > DRM_PLANE_PIXEL_SOURCE_COLOR. This will disable memory fetch and the > resulting plane will display the color specified by the solid_fill blob. > > Currently, there's only one version of the solid_fill blob property. > However if other drivers want to support a similar feature, but require > more than just the solid fill color, they can extend this feature by > creating additional versions of the drm_solid_fill struct. > > This 2 property approach was chosen because passing in a special 1x1 FB > with the necessary color information would have unecessary overhead that > does not reflect the behavior of the solid fill feature. In addition, > assigning the solid fill blob to FB_ID would require loosening some core > drm_property checks that might cause unwanted side effects elsewhere. > I didn't have a detailed review of this patchset but at a high-level this change makes sense to me. Feel free to add my Acked-by: Harry Wentland to patches 1-5. Harry > --- > Changes in v6: > - Have _dpu_plane_color_fill() take in a single ABGR color instead > of having separate alpha and BGR color parameters (Dmitry) > - Drop plane->state->pixel_source != DRM_PLANE_PIXEL_SOURCE_FB check > in SetPlane ioctl (Dmitry) > - Add DRM_PLANE_PIXEL_SOURCE_NONE as a default pixel source (Sebastian) > - Dropped versioning from solid fill property blob (Dmitry) > - Use DRM_ENUM_NAME_FN (Dmitry) > - Use drm_atomic_replace_property_blob_from_id() (Dmitry) > - drm_atomic_check_fb -> drm_atomic_plane_check_fb (Dmitry) > - Group redundant NULL FB checks (Dmitry) > - Squashed drm_plane_needs_disable() implementation with > DRM_PLANE_PIXEL_SOURCE_NONE declaration (Sebastian) > - Add comment to support RGBA solid fill color in the future (Dmitry) > - Link to v5: > https://lore.kernel.org/r/20230728-solid-fill-v5-0-053dbefa9...@quicinc.com > > Changes in v5: > - Added support for PIXEL_SOURCE_NONE (Sebastian) > - Added WARN_ON() in drm_plane_has_visible_data() if pixel_source isn't > set (Dmitry) > - Added debugfs support for both properties (Dmitry) > - Corrected u32 to u8 conversion (Pekka) > - Moved drm_solid_fill_info struct and related documentation to > include/uapi (Pekka) > - Changed drm_solid_fill_info.version to __u32 for data alignment (Pekka) > - Added more detailed UAPI and kernel documentation (Pekka) > - Reordered patch series so that the pixel_source property is introduced > before solid_fill (Dmitry) > - Fixed inconsistent ABGR/RGBA format declaration (Pekka) > - Reset pixel_source to FB in drm_mode_setplane() (Dmitry) > - Rename supported_sources to extra_sources (Dmitry) > - Only destroy old solid_fill blob state if new state is valid (Pekka) > - Link to v4: > https://lore.kernel.org/r/20230404-solid-fill-v4-0-f4ec0caa7...@quicinc.com > > Changes in v4: > - Rebased onto latest kernel > - Reworded cover letter for clarity (Dmitry) > - Reworded commit messages for clarity > - Split existing changes into smaller commits > - Added pixel_source enum property (Dmitry, Pekka, Ville) > - Updated drm-kms comment docs with pixel_source and solid_fill > properties (Dmitry) > - Inlined drm_atomic_convert_solid_fill_info() (Dmitry) > - Passed in plane state alpha value to _dpu_plane_color_fill_pipe() > - Link to v3: > https://lore.kernel.org/r/20230104234036.636-1-quic_jessz...@quicinc.com > > Changes in v3: > - Fixed some logic errors in atomic checks (Dmitry) > - Introduced drm_plane_has_visible_data() and drm_atomic_check_fb() helper > methods (Dmitry) > - Fixed typo in drm_solid_fill struct documentation > - Created drm_plane_has_visible_data() helper and corrected CRTC and FB > NULL-check logic (Dmitry) > - Merged `if (fb)` blocks in drm_atomic_plane_check() and abstracted > them into helper method (Dmitry) > - Inverted `if (solid_fill_enabled) else if (fb)`
Re: [Freedreno] [PATCH 2/2] dt-bindings: display: msm: Make "additionalProperties: true" explicit
On Mon, Sep 25, 2023 at 04:24:25PM -0500, Rob Herring wrote: > Make it explicit that child nodes have additional properties and the > child node schema is not complete. The complete schemas are applied > separately based the compatible strings. > > Signed-off-by: Rob Herring I cross-checked only a handful of these... Acked-by: Conor Dooley Thanks, Conor. > --- > .../bindings/display/msm/qcom,msm8998-mdss.yaml| 6 ++ > .../bindings/display/msm/qcom,qcm2290-mdss.yaml| 6 ++ > .../bindings/display/msm/qcom,sc7180-mdss.yaml | 8 > .../bindings/display/msm/qcom,sc7280-mdss.yaml | 10 ++ > .../bindings/display/msm/qcom,sc8280xp-mdss.yaml | 4 > .../bindings/display/msm/qcom,sdm845-mdss.yaml | 8 > .../bindings/display/msm/qcom,sm6115-mdss.yaml | 6 ++ > .../bindings/display/msm/qcom,sm6125-mdss.yaml | 6 ++ > .../bindings/display/msm/qcom,sm6350-mdss.yaml | 6 ++ > .../bindings/display/msm/qcom,sm6375-mdss.yaml | 6 ++ > .../bindings/display/msm/qcom,sm8150-mdss.yaml | 6 ++ > .../bindings/display/msm/qcom,sm8250-mdss.yaml | 6 ++ > .../bindings/display/msm/qcom,sm8350-mdss.yaml | 8 > .../bindings/display/msm/qcom,sm8450-mdss.yaml | 8 > .../bindings/display/msm/qcom,sm8550-mdss.yaml | 8 > 15 files changed, 102 insertions(+) > > diff --git > a/Documentation/devicetree/bindings/display/msm/qcom,msm8998-mdss.yaml > b/Documentation/devicetree/bindings/display/msm/qcom,msm8998-mdss.yaml > index e320ab1de6de..2d9edab5a30d 100644 > --- a/Documentation/devicetree/bindings/display/msm/qcom,msm8998-mdss.yaml > +++ b/Documentation/devicetree/bindings/display/msm/qcom,msm8998-mdss.yaml > @@ -38,12 +38,16 @@ properties: > patternProperties: >"^display-controller@[0-9a-f]+$": > type: object > +additionalProperties: true > + > properties: >compatible: > const: qcom,msm8998-dpu > >"^dsi@[0-9a-f]+$": > type: object > +additionalProperties: true > + > properties: >compatible: > items: > @@ -52,6 +56,8 @@ patternProperties: > >"^phy@[0-9a-f]+$": > type: object > +additionalProperties: true > + > properties: >compatible: > const: qcom,dsi-phy-10nm-8998 > diff --git > a/Documentation/devicetree/bindings/display/msm/qcom,qcm2290-mdss.yaml > b/Documentation/devicetree/bindings/display/msm/qcom,qcm2290-mdss.yaml > index 4184b84d4c21..5ad155612b6c 100644 > --- a/Documentation/devicetree/bindings/display/msm/qcom,qcm2290-mdss.yaml > +++ b/Documentation/devicetree/bindings/display/msm/qcom,qcm2290-mdss.yaml > @@ -44,18 +44,24 @@ properties: > patternProperties: >"^display-controller@[0-9a-f]+$": > type: object > +additionalProperties: true > + > properties: >compatible: > const: qcom,qcm2290-dpu > >"^dsi@[0-9a-f]+$": > type: object > +additionalProperties: true > + > properties: >compatible: > const: qcom,dsi-ctrl-6g-qcm2290 > >"^phy@[0-9a-f]+$": > type: object > +additionalProperties: true > + > properties: >compatible: > const: qcom,dsi-phy-14nm-2290 > diff --git > a/Documentation/devicetree/bindings/display/msm/qcom,sc7180-mdss.yaml > b/Documentation/devicetree/bindings/display/msm/qcom,sc7180-mdss.yaml > index 3b9c103e504a..3432a2407caa 100644 > --- a/Documentation/devicetree/bindings/display/msm/qcom,sc7180-mdss.yaml > +++ b/Documentation/devicetree/bindings/display/msm/qcom,sc7180-mdss.yaml > @@ -44,18 +44,24 @@ properties: > patternProperties: >"^display-controller@[0-9a-f]+$": > type: object > +additionalProperties: true > + > properties: >compatible: > const: qcom,sc7180-dpu > >"^displayport-controller@[0-9a-f]+$": > type: object > +additionalProperties: true > + > properties: >compatible: > const: qcom,sc7180-dp > >"^dsi@[0-9a-f]+$": > type: object > +additionalProperties: true > + > properties: >compatible: > items: > @@ -64,6 +70,8 @@ patternProperties: > >"^phy@[0-9a-f]+$": > type: object > +additionalProperties: true > + > properties: >compatible: > const: qcom,dsi-phy-10nm > diff --git > a/Documentation/devicetree/bindings/display/msm/qcom,sc7280-mdss.yaml > b/Documentation/devicetree/bindings/display/msm/qcom,sc7280-mdss.yaml > index 43500dad66e7..bbb727831fca 100644 > --- a/Documentation/devicetree/bindings/display/msm/qcom,sc7280-mdss.yaml > +++ b/Documentation/devicetree/bindings/display/msm/qcom,sc7280-mdss.yaml > @@ -44,18 +44,24 @@ properties: > patternProperties: >"^display-controller@[0-9a-f]+$": > type: object > +additionalProperties: true > + > properties: >compatible: > const: qco
Re: [Freedreno] [PATCH 1/2] dt-bindings: display: msm: Add missing unevaluatedProperties on child node schemas
On Mon, Sep 25, 2023 at 04:24:24PM -0500, Rob Herring wrote: > Just as unevaluatedProperties or additionalProperties are required at > the top level of schemas, they should (and will) also be required for > child node schemas. That ensures only documented properties are > present for any node. > > Signed-off-by: Rob Herring Acked-by: Conor Dooley Thanks, Conor. > --- > Documentation/devicetree/bindings/display/msm/dp-controller.yaml | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/Documentation/devicetree/bindings/display/msm/dp-controller.yaml > b/Documentation/devicetree/bindings/display/msm/dp-controller.yaml > index f12558960cd8..dbe398f84ffb 100644 > --- a/Documentation/devicetree/bindings/display/msm/dp-controller.yaml > +++ b/Documentation/devicetree/bindings/display/msm/dp-controller.yaml > @@ -114,6 +114,7 @@ properties: > >port@1: > $ref: /schemas/graph.yaml#/$defs/port-base > +unevaluatedProperties: false > description: Output endpoint of the controller > properties: >endpoint: > -- > 2.40.1 > signature.asc Description: PGP signature
Re: [Freedreno] [PATCH v5 07/10] drm/msm/a6xx: Mostly implement A7xx gpu_state
Hi Konrad,
kernel test robot noticed the following build warnings:
[auto build test WARNING on 8fff9184d1b5810dca5dd1a02726d4f844af88fc]
url:
https://github.com/intel-lab-lkp/linux/commits/Konrad-Dybcio/dt-bindings-display-msm-gmu-Add-Adreno-7-34-0-GMU/20230925-225348
base: 8fff9184d1b5810dca5dd1a02726d4f844af88fc
patch link:
https://lore.kernel.org/r/20230628-topic-a7xx_drmmsm-v5-7-3dc527b472d7%40linaro.org
patch subject: [PATCH v5 07/10] drm/msm/a6xx: Mostly implement A7xx gpu_state
config: sparc-allyesconfig
(https://download.01.org/0day-ci/archive/20230926/202309261932.dha9dool-...@intel.com/config)
compiler: sparc64-linux-gcc (GCC) 13.2.0
reproduce (this is a W=1 build):
(https://download.01.org/0day-ci/archive/20230926/202309261932.dha9dool-...@intel.com/reproduce)
If you fix the issue in a separate patch/commit (i.e. not just a new version of
the same patch/commit), kindly add following tags
| Reported-by: kernel test robot
| Closes:
https://lore.kernel.org/oe-kbuild-all/202309261932.dha9dool-...@intel.com/
All warnings (new ones prefixed by >>):
In file included from drivers/gpu/drm/msm/adreno/a6xx_gpu_state.c:8:
>> drivers/gpu/drm/msm/adreno/a6xx_gpu_state.h:360:36: warning:
>> 'a7xx_gbif_reglist' defined but not used [-Wunused-const-variable=]
360 | static const struct a6xx_registers a7xx_gbif_reglist =
|^
>> drivers/gpu/drm/msm/adreno/a6xx_gpu_state.h:356:36: warning:
>> 'a7xx_ahb_reglist' defined but not used [-Wunused-const-variable=]
356 | static const struct a6xx_registers a7xx_ahb_reglist[] = {
|^~~~
vim +/a7xx_gbif_reglist +360 drivers/gpu/drm/msm/adreno/a6xx_gpu_state.h
355
> 356 static const struct a6xx_registers a7xx_ahb_reglist[] = {
357 REGS(a7xx_ahb_registers, 0, 0),
358 };
359
> 360 static const struct a6xx_registers a7xx_gbif_reglist =
361 REGS(a7xx_gbif_registers, 0, 0);
362
--
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests/wiki
Re: [Freedreno] [PATCH v2 1/2] drm/msm/dpu: fail dpu_plane_atomic_check() based on mdp clk limits
On Tue, 12 Sept 2023 at 01:18, Abhinav Kumar wrote:
>
> Currently, dpu_plane_atomic_check() does not check whether the
> plane can process the image without exceeding the per chipset
> limits for MDP clock. This leads to underflow issues because the
> SSPP is not able to complete the processing for the data rate of
> the display.
>
> Fail the dpu_plane_atomic_check() if the SSPP cannot process the
> image without exceeding the MDP clock limits.
>
> changes in v2:
> - use crtc_state's adjusted_mode instead of mode
>
> Fixes: 25fdd5933e4c ("drm/msm: Add SDM845 DPU support")
> Signed-off-by: Abhinav Kumar
Reviewed-by: Dmitry Baryshkov
> ---
> drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c | 15 ---
> 1 file changed, 12 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c
> b/drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c
> index 98c1b22e9bca..0be195f9149c 100644
> --- a/drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c
> +++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c
> @@ -733,9 +733,11 @@ static int dpu_plane_check_inline_rotation(struct
> dpu_plane *pdpu,
> static int dpu_plane_atomic_check_pipe(struct dpu_plane *pdpu,
> struct dpu_sw_pipe *pipe,
> struct dpu_sw_pipe_cfg *pipe_cfg,
> - const struct dpu_format *fmt)
> + const struct dpu_format *fmt,
> + const struct drm_display_mode *mode)
> {
> uint32_t min_src_size;
> + struct dpu_kms *kms = _dpu_plane_get_kms(&pdpu->base);
>
> min_src_size = DPU_FORMAT_IS_YUV(fmt) ? 2 : 1;
>
> @@ -774,6 +776,12 @@ static int dpu_plane_atomic_check_pipe(struct dpu_plane
> *pdpu,
> return -EINVAL;
> }
>
> + /* max clk check */
> + if (_dpu_plane_calc_clk(mode, pipe_cfg) >
> kms->perf.max_core_clk_rate) {
> + DPU_DEBUG_PLANE(pdpu, "plane exceeds max mdp core clk
> limits\n");
> + return -E2BIG;
> + }
> +
> return 0;
> }
>
> @@ -899,12 +907,13 @@ static int dpu_plane_atomic_check(struct drm_plane
> *plane,
> r_pipe_cfg->dst_rect.x1 = pipe_cfg->dst_rect.x2;
> }
>
> - ret = dpu_plane_atomic_check_pipe(pdpu, pipe, pipe_cfg, fmt);
> + ret = dpu_plane_atomic_check_pipe(pdpu, pipe, pipe_cfg, fmt,
> &crtc_state->adjusted_mode);
> if (ret)
> return ret;
>
> if (r_pipe->sspp) {
> - ret = dpu_plane_atomic_check_pipe(pdpu, r_pipe, r_pipe_cfg,
> fmt);
> + ret = dpu_plane_atomic_check_pipe(pdpu, r_pipe, r_pipe_cfg,
> fmt,
> + &crtc_state->adjusted_mode);
> if (ret)
> return ret;
> }
> --
> 2.40.1
>
--
With best wishes
Dmitry
Re: [Freedreno] [PATCH v2 2/2] drm/msm/dpu: try multirect based on mdp clock limits
On Tue, 12 Sept 2023 at 01:16, Abhinav Kumar wrote: > > It's certainly possible that for large resolutions a single DPU SSPP > cannot process the image without exceeding the MDP clock limits but > it can still process it in multirect mode because the source rectangles > will get divided and can fall within the MDP clock limits. > > If the SSPP cannot process the image even in multirect mode, then it > will be rejected in dpu_plane_atomic_check_pipe(). > > Hence try using multirect for resolutions which cannot be processed > by a single SSPP without exceeding the MDP clock limits. > > changes in v2: > - use crtc_state's adjusted_mode instead of mode > - fix the UBWC condition to check maxlinewidth > > Signed-off-by: Abhinav Kumar Reviewed-by: Dmitry Baryshkov Tested-by: Dmitry Baryshkov -- With best wishes Dmitry
