* [PATCH 0/3] Fix reg ranges for dma-controller node
From: Jayesh Choudhary @ 2024-04-05 8:52 UTC (permalink / raw)
To: nm, vigneshr, bb, devicetree, j-choudhary
Cc: kristo, robh, krzk+dt, conor+dt, linux-kernel, linux-arm-kernel
The dma-controller node 'main_pktdma' has few memory regions with
wrong sizes.
DMASS0_PKTDMA_RINGRT is marked as 4MB region when it is actually a 2MB
region. Similarly, DMASS0_PKTDMA_TCHANRT is marked as 256KB region but
the actual size is 128KB as shown in TRM in the section for Main Memory
Map (Table 2-1)
Fix these region across AM62, AM62A and AM62P (which is also used in
J722S)
TRM:
AM625: <https://www.ti.com/lit/pdf/spruiv7>
AM62A7: <https://www.ti.com/lit/pdf/spruj16>
AM62P: <https://www.ti.com/lit/pdf/spruj83>
J722S: <https://www.ti.com/lit/zip/sprujb3>
Jayesh Choudhary (3):
arm64: dts: ti: k3-am62-main: Fix the reg-range for dma-controller
arm64: dts: ti: k3-am62a-main: Fix the reg-range for dma-controller
arm64: dts: ti: k3-am62p-main: Fix the reg-range for dma-controller
arch/arm64/boot/dts/ti/k3-am62-main.dtsi | 4 ++--
arch/arm64/boot/dts/ti/k3-am62a-main.dtsi | 4 ++--
arch/arm64/boot/dts/ti/k3-am62p-main.dtsi | 4 ++--
3 files changed, 6 insertions(+), 6 deletions(-)
--
2.25.1
^ permalink raw reply
* [PATCH 1/3] arm64: dts: ti: k3-am62-main: Fix the reg-range for dma-controller
From: Jayesh Choudhary @ 2024-04-05 8:52 UTC (permalink / raw)
To: nm, vigneshr, bb, devicetree, j-choudhary
Cc: kristo, robh, krzk+dt, conor+dt, linux-kernel, linux-arm-kernel
In-Reply-To: <20240405085208.32227-1-j-choudhary@ti.com>
The TX Channel Realtime Registers region 'tchanrt' is 128KB and Ring
Realtime Registers region 'ringrt' is 2MB as shown in memory map in
the TRM[0]. So fix ranges for those reg-regions.
[0]: <https://www.ti.com/lit/pdf/spruiv7>
Fixes: c37c58fdeb8a ("arm64: dts: ti: k3-am62: Add more peripheral nodes")
Signed-off-by: Jayesh Choudhary <j-choudhary@ti.com>
---
arch/arm64/boot/dts/ti/k3-am62-main.dtsi | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/arm64/boot/dts/ti/k3-am62-main.dtsi b/arch/arm64/boot/dts/ti/k3-am62-main.dtsi
index e9cffca073ef..e10cc9fc0b10 100644
--- a/arch/arm64/boot/dts/ti/k3-am62-main.dtsi
+++ b/arch/arm64/boot/dts/ti/k3-am62-main.dtsi
@@ -141,8 +141,8 @@ main_pktdma: dma-controller@485c0000 {
compatible = "ti,am64-dmss-pktdma";
reg = <0x00 0x485c0000 0x00 0x100>,
<0x00 0x4a800000 0x00 0x20000>,
- <0x00 0x4aa00000 0x00 0x40000>,
- <0x00 0x4b800000 0x00 0x400000>,
+ <0x00 0x4aa00000 0x00 0x20000>,
+ <0x00 0x4b800000 0x00 0x200000>,
<0x00 0x485e0000 0x00 0x10000>,
<0x00 0x484a0000 0x00 0x2000>,
<0x00 0x484c0000 0x00 0x2000>,
--
2.25.1
^ permalink raw reply related
* [PATCH 2/3] arm64: dts: ti: k3-am62a-main: Fix the reg-range for dma-controller
From: Jayesh Choudhary @ 2024-04-05 8:52 UTC (permalink / raw)
To: nm, vigneshr, bb, devicetree, j-choudhary
Cc: kristo, robh, krzk+dt, conor+dt, linux-kernel, linux-arm-kernel
In-Reply-To: <20240405085208.32227-1-j-choudhary@ti.com>
The TX Channel Realtime Registers region 'tchanrt' is 128KB and Ring
Realtime Registers region 'ringrt' is 2MB as shown in memory map in
the TRM[0]. So fix ranges for those reg-regions.
[0]: <https://www.ti.com/lit/pdf/spruj16>
Fixes: 3dad70def7ff ("arm64: dts: ti: k3-am62a-main: Add more peripheral nodes")
Signed-off-by: Jayesh Choudhary <j-choudhary@ti.com>
---
arch/arm64/boot/dts/ti/k3-am62a-main.dtsi | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/arm64/boot/dts/ti/k3-am62a-main.dtsi b/arch/arm64/boot/dts/ti/k3-am62a-main.dtsi
index aa1e057082f0..5a4cb0536c6f 100644
--- a/arch/arm64/boot/dts/ti/k3-am62a-main.dtsi
+++ b/arch/arm64/boot/dts/ti/k3-am62a-main.dtsi
@@ -120,8 +120,8 @@ main_pktdma: dma-controller@485c0000 {
compatible = "ti,am64-dmss-pktdma";
reg = <0x00 0x485c0000 0x00 0x100>,
<0x00 0x4a800000 0x00 0x20000>,
- <0x00 0x4aa00000 0x00 0x40000>,
- <0x00 0x4b800000 0x00 0x400000>,
+ <0x00 0x4aa00000 0x00 0x20000>,
+ <0x00 0x4b800000 0x00 0x200000>,
<0x00 0x485e0000 0x00 0x10000>,
<0x00 0x484a0000 0x00 0x2000>,
<0x00 0x484c0000 0x00 0x2000>,
--
2.25.1
^ permalink raw reply related
* [PATCH 6/6] arm64: dts: qcom: sm8550: Wire up GPU speed bin & more OPPs
From: Konrad Dybcio @ 2024-04-05 8:41 UTC (permalink / raw)
To: Bjorn Andersson, Rob Clark, Abhinav Kumar, Dmitry Baryshkov,
Sean Paul, Marijn Suijten, David Airlie, Daniel Vetter,
Rob Herring, Krzysztof Kozlowski, Conor Dooley
Cc: linux-arm-msm, linux-kernel, dri-devel, freedreno, devicetree,
Neil Armstrong, Konrad Dybcio
In-Reply-To: <20240405-topic-smem_speedbin-v1-0-ce2b864251b1@linaro.org>
Add the speedbin masks to ensure only the desired OPPs are available on
chips of a given bin.
Using this, add the binned 719 MHz OPP and the non-binned 124.8 MHz.
Signed-off-by: Konrad Dybcio <konrad.dybcio@linaro.org>
---
arch/arm64/boot/dts/qcom/sm8550.dtsi | 21 ++++++++++++++++++++-
1 file changed, 20 insertions(+), 1 deletion(-)
diff --git a/arch/arm64/boot/dts/qcom/sm8550.dtsi b/arch/arm64/boot/dts/qcom/sm8550.dtsi
index 5cae8d773cec..2f6842f6a5b7 100644
--- a/arch/arm64/boot/dts/qcom/sm8550.dtsi
+++ b/arch/arm64/boot/dts/qcom/sm8550.dtsi
@@ -2087,48 +2087,67 @@ zap-shader {
memory-region = <&gpu_micro_code_mem>;
};
- /* Speedbin needs more work on A740+, keep only lower freqs */
gpu_opp_table: opp-table {
compatible = "operating-points-v2";
+ opp-719000000 {
+ opp-hz = /bits/ 64 <719000000>;
+ opp-level = <RPMH_REGULATOR_LEVEL_SVS_L2>;
+ opp-supported-hw = <0x1>;
+ };
+
opp-680000000 {
opp-hz = /bits/ 64 <680000000>;
opp-level = <RPMH_REGULATOR_LEVEL_SVS_L1>;
+ opp-supported-hw = <0x3>;
};
opp-615000000 {
opp-hz = /bits/ 64 <615000000>;
opp-level = <RPMH_REGULATOR_LEVEL_SVS_L0>;
+ opp-supported-hw = <0x3>;
};
opp-550000000 {
opp-hz = /bits/ 64 <550000000>;
opp-level = <RPMH_REGULATOR_LEVEL_SVS>;
+ opp-supported-hw = <0x3>;
};
opp-475000000 {
opp-hz = /bits/ 64 <475000000>;
opp-level = <RPMH_REGULATOR_LEVEL_LOW_SVS_L1>;
+ opp-supported-hw = <0x3>;
};
opp-401000000 {
opp-hz = /bits/ 64 <401000000>;
opp-level = <RPMH_REGULATOR_LEVEL_LOW_SVS>;
+ opp-supported-hw = <0x3>;
};
opp-348000000 {
opp-hz = /bits/ 64 <348000000>;
opp-level = <RPMH_REGULATOR_LEVEL_LOW_SVS_D0>;
+ opp-supported-hw = <0x3>;
};
opp-295000000 {
opp-hz = /bits/ 64 <295000000>;
opp-level = <RPMH_REGULATOR_LEVEL_LOW_SVS_D1>;
+ opp-supported-hw = <0x3>;
};
opp-220000000 {
opp-hz = /bits/ 64 <220000000>;
opp-level = <RPMH_REGULATOR_LEVEL_LOW_SVS_D2>;
+ opp-supported-hw = <0x3>;
+ };
+
+ opp-124800000 {
+ opp-hz = /bits/ 64 <124800000>;
+ opp-level = <RPMH_REGULATOR_LEVEL_LOW_SVS_D2>;
+ opp-supported-hw = <0x3>;
};
};
};
--
2.40.1
^ permalink raw reply related
* [PATCH 5/6] drm/msm/adreno: Add speedbin data for SM8550 / A740
From: Konrad Dybcio @ 2024-04-05 8:41 UTC (permalink / raw)
To: Bjorn Andersson, Rob Clark, Abhinav Kumar, Dmitry Baryshkov,
Sean Paul, Marijn Suijten, David Airlie, Daniel Vetter,
Rob Herring, Krzysztof Kozlowski, Conor Dooley
Cc: linux-arm-msm, linux-kernel, dri-devel, freedreno, devicetree,
Neil Armstrong, Konrad Dybcio
In-Reply-To: <20240405-topic-smem_speedbin-v1-0-ce2b864251b1@linaro.org>
Add speebin data for A740, as found on SM8550 and derivative SoCs.
Signed-off-by: Konrad Dybcio <konrad.dybcio@linaro.org>
---
drivers/gpu/drm/msm/adreno/adreno_device.c | 14 ++++++++++++++
1 file changed, 14 insertions(+)
diff --git a/drivers/gpu/drm/msm/adreno/adreno_device.c b/drivers/gpu/drm/msm/adreno/adreno_device.c
index 901ef767e491..c976a485aef2 100644
--- a/drivers/gpu/drm/msm/adreno/adreno_device.c
+++ b/drivers/gpu/drm/msm/adreno/adreno_device.c
@@ -570,6 +570,20 @@ static const struct adreno_info gpulist[] = {
.zapfw = "a740_zap.mdt",
.hwcg = a740_hwcg,
.address_space_size = SZ_16G,
+ .speedbins = ADRENO_SPEEDBINS(
+ { ADRENO_SKU_ID(SOCINFO_PC_UNKNOWN, SOCINFO_FC_AC), 0 },
+ { ADRENO_SKU_ID(SOCINFO_PC_UNKNOWN, SOCINFO_FC_AF), 0 },
+ { ADRENO_SKU_ID(SOCINFO_PCn(1), SOCINFO_FC_UNKNOWN), 1 },
+ { ADRENO_SKU_ID(SOCINFO_PCn(2), SOCINFO_FC_Yn(0x0)), 0 },
+ { ADRENO_SKU_ID(SOCINFO_PCn(2), SOCINFO_FC_Yn(0x2)), 0 },
+ { ADRENO_SKU_ID(SOCINFO_PCn(4), SOCINFO_FC_Yn(0x0)), 0 },
+ { ADRENO_SKU_ID(SOCINFO_PCn(4), SOCINFO_FC_Yn(0x2)), 0 },
+ { ADRENO_SKU_ID(SOCINFO_PCn(6), SOCINFO_FC_Yn(0x0)), 0 },
+ { ADRENO_SKU_ID(SOCINFO_PCn(6), SOCINFO_FC_Yn(0x1)), 0 },
+ { ADRENO_SKU_ID(SOCINFO_PCn(6), SOCINFO_FC_Yn(0xd)), 0 },
+ { ADRENO_SKU_ID(SOCINFO_PCn(6), SOCINFO_FC_Yn(0xe)), 0 },
+ ),
+ .default_speedbin = 1,
}, {
.chip_ids = ADRENO_CHIP_IDS(0x43051401), /* "C520v2" */
.family = ADRENO_7XX_GEN3,
--
2.40.1
^ permalink raw reply related
* [PATCH 4/6] drm/msm/adreno: Implement SMEM-based speed bin
From: Konrad Dybcio @ 2024-04-05 8:41 UTC (permalink / raw)
To: Bjorn Andersson, Rob Clark, Abhinav Kumar, Dmitry Baryshkov,
Sean Paul, Marijn Suijten, David Airlie, Daniel Vetter,
Rob Herring, Krzysztof Kozlowski, Conor Dooley
Cc: linux-arm-msm, linux-kernel, dri-devel, freedreno, devicetree,
Neil Armstrong, Konrad Dybcio
In-Reply-To: <20240405-topic-smem_speedbin-v1-0-ce2b864251b1@linaro.org>
On recent (SM8550+) Snapdragon platforms, the GPU speed bin data is
abstracted through SMEM, instead of being directly available in a fuse.
Add support for SMEM-based speed binning, which includes getting
"feature code" and "product code" from said source and parsing them
to form something that lets us match OPPs against.
Signed-off-by: Konrad Dybcio <konrad.dybcio@linaro.org>
---
drivers/gpu/drm/msm/adreno/a6xx_gpu.c | 8 +++---
drivers/gpu/drm/msm/adreno/adreno_device.c | 2 ++
drivers/gpu/drm/msm/adreno/adreno_gpu.c | 39 +++++++++++++++++++++++++++---
drivers/gpu/drm/msm/adreno/adreno_gpu.h | 12 ++++++---
4 files changed, 51 insertions(+), 10 deletions(-)
diff --git a/drivers/gpu/drm/msm/adreno/a6xx_gpu.c b/drivers/gpu/drm/msm/adreno/a6xx_gpu.c
index 4cbdfabbcee5..6776fd80f7a6 100644
--- a/drivers/gpu/drm/msm/adreno/a6xx_gpu.c
+++ b/drivers/gpu/drm/msm/adreno/a6xx_gpu.c
@@ -2890,13 +2890,15 @@ static u32 fuse_to_supp_hw(const struct adreno_info *info, u32 fuse)
return UINT_MAX;
}
-static int a6xx_set_supported_hw(struct device *dev, const struct adreno_info *info)
+static int a6xx_set_supported_hw(struct adreno_gpu *adreno_gpu,
+ struct device *dev,
+ const struct adreno_info *info)
{
u32 supp_hw;
u32 speedbin;
int ret;
- ret = adreno_read_speedbin(dev, &speedbin);
+ ret = adreno_read_speedbin(adreno_gpu, dev, &speedbin);
/*
* -ENOENT means that the platform doesn't support speedbin which is
* fine
@@ -3056,7 +3058,7 @@ struct msm_gpu *a6xx_gpu_init(struct drm_device *dev)
a6xx_llc_slices_init(pdev, a6xx_gpu, is_a7xx);
- ret = a6xx_set_supported_hw(&pdev->dev, config->info);
+ ret = a6xx_set_supported_hw(adreno_gpu, &pdev->dev, config->info);
if (ret) {
a6xx_destroy(&(a6xx_gpu->base.base));
return ERR_PTR(ret);
diff --git a/drivers/gpu/drm/msm/adreno/adreno_device.c b/drivers/gpu/drm/msm/adreno/adreno_device.c
index c3703a51287b..901ef767e491 100644
--- a/drivers/gpu/drm/msm/adreno/adreno_device.c
+++ b/drivers/gpu/drm/msm/adreno/adreno_device.c
@@ -6,6 +6,8 @@
* Copyright (c) 2014,2017 The Linux Foundation. All rights reserved.
*/
+#include <linux/soc/qcom/socinfo.h>
+
#include "adreno_gpu.h"
bool hang_debug = false;
diff --git a/drivers/gpu/drm/msm/adreno/adreno_gpu.c b/drivers/gpu/drm/msm/adreno/adreno_gpu.c
index 074fb498706f..0e4ff532ac3c 100644
--- a/drivers/gpu/drm/msm/adreno/adreno_gpu.c
+++ b/drivers/gpu/drm/msm/adreno/adreno_gpu.c
@@ -21,6 +21,9 @@
#include "msm_gem.h"
#include "msm_mmu.h"
+#include <linux/soc/qcom/smem.h>
+#include <linux/soc/qcom/socinfo.h>
+
static u64 address_space_size = 0;
MODULE_PARM_DESC(address_space_size, "Override for size of processes private GPU address space");
module_param(address_space_size, ullong, 0600);
@@ -1057,9 +1060,37 @@ void adreno_gpu_ocmem_cleanup(struct adreno_ocmem *adreno_ocmem)
adreno_ocmem->hdl);
}
-int adreno_read_speedbin(struct device *dev, u32 *speedbin)
+int adreno_read_speedbin(struct adreno_gpu *adreno_gpu,
+ struct device *dev, u32 *speedbin)
{
- return nvmem_cell_read_variable_le_u32(dev, "speed_bin", speedbin);
+ u32 fcode, pcode;
+ int ret;
+
+ /* Try reading the speedbin via a nvmem cell first */
+ ret = nvmem_cell_read_variable_le_u32(dev, "speed_bin", speedbin);
+ if (!ret && ret != -EINVAL)
+ return ret;
+
+ ret = qcom_smem_get_feature_code(&fcode);
+ if (ret) {
+ dev_err(dev, "Couldn't get feature code from SMEM!\n");
+ return ret;
+ }
+
+ ret = qcom_smem_get_product_code(&pcode);
+ if (ret) {
+ dev_err(dev, "Couldn't get product code from SMEM!\n");
+ return ret;
+ }
+
+ /* Don't consider fcode for external feature codes */
+ if (fcode <= SOCINFO_FC_EXT_RESERVE)
+ fcode = SOCINFO_FC_UNKNOWN;
+
+ *speedbin = FIELD_PREP(ADRENO_SKU_ID_PCODE, pcode) |
+ FIELD_PREP(ADRENO_SKU_ID_FCODE, fcode);
+
+ return ret;
}
int adreno_gpu_init(struct drm_device *drm, struct platform_device *pdev,
@@ -1098,9 +1129,9 @@ int adreno_gpu_init(struct drm_device *drm, struct platform_device *pdev,
devm_pm_opp_set_clkname(dev, "core");
}
- if (adreno_read_speedbin(dev, &speedbin) || !speedbin)
+ if (adreno_read_speedbin(adreno_gpu, dev, &speedbin) || !speedbin)
speedbin = 0xffff;
- adreno_gpu->speedbin = (uint16_t) (0xffff & speedbin);
+ adreno_gpu->speedbin = speedbin;
gpu_name = devm_kasprintf(dev, GFP_KERNEL, "%"ADRENO_CHIPID_FMT,
ADRENO_CHIPID_ARGS(config->chip_id));
diff --git a/drivers/gpu/drm/msm/adreno/adreno_gpu.h b/drivers/gpu/drm/msm/adreno/adreno_gpu.h
index 460b399be37b..1770a9e20484 100644
--- a/drivers/gpu/drm/msm/adreno/adreno_gpu.h
+++ b/drivers/gpu/drm/msm/adreno/adreno_gpu.h
@@ -81,7 +81,12 @@ extern const struct adreno_reglist a612_hwcg[], a615_hwcg[], a630_hwcg[], a640_h
extern const struct adreno_reglist a660_hwcg[], a690_hwcg[], a702_hwcg[], a730_hwcg[], a740_hwcg[];
struct adreno_speedbin {
- uint16_t fuse;
+ /* <= 16-bit for NVMEM fuses, 32b for SOCID values */
+ uint32_t fuse;
+#define ADRENO_SKU_ID_PCODE GENMASK(31, 16)
+#define ADRENO_SKU_ID_FCODE GENMASK(15, 0)
+#define ADRENO_SKU_ID(pcode, fcode) (pcode << 16 | fcode)
+
uint16_t speedbin;
};
@@ -137,7 +142,7 @@ struct adreno_gpu {
struct msm_gpu base;
const struct adreno_info *info;
uint32_t chip_id;
- uint16_t speedbin;
+ uint32_t speedbin;
const struct adreno_gpu_funcs *funcs;
/* interesting register offsets to dump: */
@@ -520,7 +525,8 @@ int adreno_fault_handler(struct msm_gpu *gpu, unsigned long iova, int flags,
struct adreno_smmu_fault_info *info, const char *block,
u32 scratch[4]);
-int adreno_read_speedbin(struct device *dev, u32 *speedbin);
+int adreno_read_speedbin(struct adreno_gpu *adreno_gpu,
+ struct device *dev, u32 *speedbin);
/*
* For a5xx and a6xx targets load the zap shader that is used to pull the GPU
--
2.40.1
^ permalink raw reply related
* [PATCH 3/6] drm/msm/adreno: Allow specifying default speedbin value
From: Konrad Dybcio @ 2024-04-05 8:41 UTC (permalink / raw)
To: Bjorn Andersson, Rob Clark, Abhinav Kumar, Dmitry Baryshkov,
Sean Paul, Marijn Suijten, David Airlie, Daniel Vetter,
Rob Herring, Krzysztof Kozlowski, Conor Dooley
Cc: linux-arm-msm, linux-kernel, dri-devel, freedreno, devicetree,
Neil Armstrong, Konrad Dybcio
In-Reply-To: <20240405-topic-smem_speedbin-v1-0-ce2b864251b1@linaro.org>
From: Neil Armstrong <neil.armstrong@linaro.org>
Usually, speedbin 0 is the "super SKU", a.k.a the one which can clock
the highest. Falling back to it when things go wrong is largely
suboptimal, as more often than not, the top frequencies are not
supposed to work on other bins.
Let the developer specify the intended "lowest common denominator" bin
in struct adreno_info. If not specified, partial struct initialization
will ensure it's set to zero, retaining previous behavior.
Signed-off-by: Neil Armstrong <neil.armstrong@linaro.org>
[Konrad: clean up, add commit message]
Signed-off-by: Konrad Dybcio <konrad.dybcio@linaro.org>
---
drivers/gpu/drm/msm/adreno/a6xx_gpu.c | 2 +-
drivers/gpu/drm/msm/adreno/adreno_gpu.h | 1 +
2 files changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/msm/adreno/a6xx_gpu.c b/drivers/gpu/drm/msm/adreno/a6xx_gpu.c
index 0674aca0f8a3..4cbdfabbcee5 100644
--- a/drivers/gpu/drm/msm/adreno/a6xx_gpu.c
+++ b/drivers/gpu/drm/msm/adreno/a6xx_gpu.c
@@ -2915,7 +2915,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);
- supp_hw = BIT(0); /* Default */
+ supp_hw = BIT(info->default_speedbin); /* Default */
}
ret = devm_pm_opp_set_supported_hw(dev, &supp_hw, 1);
diff --git a/drivers/gpu/drm/msm/adreno/adreno_gpu.h b/drivers/gpu/drm/msm/adreno/adreno_gpu.h
index 77526892eb8c..460b399be37b 100644
--- a/drivers/gpu/drm/msm/adreno/adreno_gpu.h
+++ b/drivers/gpu/drm/msm/adreno/adreno_gpu.h
@@ -110,6 +110,7 @@ struct adreno_info {
* {SHRT_MAX, 0} sentinal.
*/
struct adreno_speedbin *speedbins;
+ unsigned int default_speedbin;
};
#define ADRENO_CHIP_IDS(tbl...) (uint32_t[]) { tbl, 0 }
--
2.40.1
^ permalink raw reply related
* [PATCH 2/6] soc: qcom: smem: Add pcode/fcode getters
From: Konrad Dybcio @ 2024-04-05 8:41 UTC (permalink / raw)
To: Bjorn Andersson, Rob Clark, Abhinav Kumar, Dmitry Baryshkov,
Sean Paul, Marijn Suijten, David Airlie, Daniel Vetter,
Rob Herring, Krzysztof Kozlowski, Conor Dooley
Cc: linux-arm-msm, linux-kernel, dri-devel, freedreno, devicetree,
Neil Armstrong, Konrad Dybcio
In-Reply-To: <20240405-topic-smem_speedbin-v1-0-ce2b864251b1@linaro.org>
Introduce getters for SoC product and feature codes and export them.
Signed-off-by: Konrad Dybcio <konrad.dybcio@linaro.org>
---
drivers/soc/qcom/smem.c | 66 +++++++++++++++++++++++++++++++++++++++++++
include/linux/soc/qcom/smem.h | 2 ++
2 files changed, 68 insertions(+)
diff --git a/drivers/soc/qcom/smem.c b/drivers/soc/qcom/smem.c
index 7191fa0c087f..e89b4d26877a 100644
--- a/drivers/soc/qcom/smem.c
+++ b/drivers/soc/qcom/smem.c
@@ -795,6 +795,72 @@ int qcom_smem_get_soc_id(u32 *id)
}
EXPORT_SYMBOL_GPL(qcom_smem_get_soc_id);
+/**
+ * qcom_smem_get_feature_code() - return the feature code
+ * @id: On success, we return the feature code here.
+ *
+ * Look up the feature code identifier from SMEM and return it.
+ *
+ * Return: 0 on success, negative errno on failure.
+ */
+int qcom_smem_get_feature_code(u32 *code)
+{
+ struct socinfo *info;
+ u32 raw_code;
+
+ info = qcom_smem_get(QCOM_SMEM_HOST_ANY, SMEM_HW_SW_BUILD_ID, NULL);
+ if (IS_ERR(info))
+ return PTR_ERR(info);
+
+ /* This only makes sense for socinfo >= 16 */
+ if (__le32_to_cpu(info->fmt) < SOCINFO_VERSION(0, 16))
+ return -EINVAL;
+
+ raw_code = __le32_to_cpu(info->feature_code);
+
+ /* Ensure the value makes sense */
+ if (raw_code >= SOCINFO_FC_INT_RESERVE)
+ raw_code = SOCINFO_FC_UNKNOWN;
+
+ *code = raw_code;
+
+ return 0;
+}
+EXPORT_SYMBOL_GPL(qcom_smem_get_feature_code);
+
+/**
+ * qcom_smem_get_product_code() - return the product code
+ * @id: On success, we return the product code here.
+ *
+ * Look up feature code identifier from SMEM and return it.
+ *
+ * Return: 0 on success, negative errno on failure.
+ */
+int qcom_smem_get_product_code(u32 *code)
+{
+ struct socinfo *info;
+ u32 raw_code;
+
+ info = qcom_smem_get(QCOM_SMEM_HOST_ANY, SMEM_HW_SW_BUILD_ID, NULL);
+ if (IS_ERR(info))
+ return PTR_ERR(info);
+
+ /* This only makes sense for socinfo >= 16 */
+ if (__le32_to_cpu(info->fmt) < SOCINFO_VERSION(0, 16))
+ return -EINVAL;
+
+ raw_code = __le32_to_cpu(info->pcode);
+
+ /* Ensure the value makes sense */
+ if (raw_code >= SOCINFO_FC_INT_RESERVE)
+ raw_code = SOCINFO_FC_UNKNOWN;
+
+ *code = raw_code;
+
+ return 0;
+}
+EXPORT_SYMBOL_GPL(qcom_smem_get_product_code);
+
static int qcom_smem_get_sbl_version(struct qcom_smem *smem)
{
struct smem_header *header;
diff --git a/include/linux/soc/qcom/smem.h b/include/linux/soc/qcom/smem.h
index a36a3b9d4929..aef8c9fc6c08 100644
--- a/include/linux/soc/qcom/smem.h
+++ b/include/linux/soc/qcom/smem.h
@@ -13,5 +13,7 @@ int qcom_smem_get_free_space(unsigned host);
phys_addr_t qcom_smem_virt_to_phys(void *p);
int qcom_smem_get_soc_id(u32 *id);
+int qcom_smem_get_feature_code(u32 *code);
+int qcom_smem_get_product_code(u32 *code);
#endif
--
2.40.1
^ permalink raw reply related
* [PATCH 1/6] soc: qcom: Move some socinfo defines to the header, expand them
From: Konrad Dybcio @ 2024-04-05 8:41 UTC (permalink / raw)
To: Bjorn Andersson, Rob Clark, Abhinav Kumar, Dmitry Baryshkov,
Sean Paul, Marijn Suijten, David Airlie, Daniel Vetter,
Rob Herring, Krzysztof Kozlowski, Conor Dooley
Cc: linux-arm-msm, linux-kernel, dri-devel, freedreno, devicetree,
Neil Armstrong, Konrad Dybcio
In-Reply-To: <20240405-topic-smem_speedbin-v1-0-ce2b864251b1@linaro.org>
In preparation for parsing the chip "feature code" (FC) and "product
code" (PC) (essentially the parameters that let us conclusively
characterize the sillicon we're running on, including various speed
bins), move the socinfo version defines to the public header and
include some more FC/PC defines.
Signed-off-by: Konrad Dybcio <konrad.dybcio@linaro.org>
---
drivers/soc/qcom/socinfo.c | 8 --------
include/linux/soc/qcom/socinfo.h | 36 ++++++++++++++++++++++++++++++++++++
2 files changed, 36 insertions(+), 8 deletions(-)
diff --git a/drivers/soc/qcom/socinfo.c b/drivers/soc/qcom/socinfo.c
index 277c07a6603d..cf4616a468f2 100644
--- a/drivers/soc/qcom/socinfo.c
+++ b/drivers/soc/qcom/socinfo.c
@@ -21,14 +21,6 @@
#include <dt-bindings/arm/qcom,ids.h>
-/*
- * SoC version type with major number in the upper 16 bits and minor
- * number in the lower 16 bits.
- */
-#define SOCINFO_MAJOR(ver) (((ver) >> 16) & 0xffff)
-#define SOCINFO_MINOR(ver) ((ver) & 0xffff)
-#define SOCINFO_VERSION(maj, min) ((((maj) & 0xffff) << 16)|((min) & 0xffff))
-
/* Helper macros to create soc_id table */
#define qcom_board_id(id) QCOM_ID_ ## id, __stringify(id)
#define qcom_board_id_named(id, name) QCOM_ID_ ## id, (name)
diff --git a/include/linux/soc/qcom/socinfo.h b/include/linux/soc/qcom/socinfo.h
index e78777bb0f4a..ba7f683bd32c 100644
--- a/include/linux/soc/qcom/socinfo.h
+++ b/include/linux/soc/qcom/socinfo.h
@@ -3,6 +3,8 @@
#ifndef __QCOM_SOCINFO_H__
#define __QCOM_SOCINFO_H__
+#include <linux/types.h>
+
/*
* SMEM item id, used to acquire handles to respective
* SMEM region.
@@ -12,6 +14,14 @@
#define SMEM_SOCINFO_BUILD_ID_LENGTH 32
#define SMEM_SOCINFO_CHIP_ID_LENGTH 32
+/*
+ * SoC version type with major number in the upper 16 bits and minor
+ * number in the lower 16 bits.
+ */
+#define SOCINFO_MAJOR(ver) (((ver) >> 16) & 0xffff)
+#define SOCINFO_MINOR(ver) ((ver) & 0xffff)
+#define SOCINFO_VERSION(maj, min) ((((maj) & 0xffff) << 16)|((min) & 0xffff))
+
/* Socinfo SMEM item structure */
struct socinfo {
__le32 fmt;
@@ -74,4 +84,30 @@ struct socinfo {
__le32 boot_core;
};
+/* Internal feature codes */
+enum feature_code {
+ /* External feature codes */
+ SOCINFO_FC_UNKNOWN = 0x0,
+ SOCINFO_FC_AA,
+ SOCINFO_FC_AB,
+ SOCINFO_FC_AC,
+ SOCINFO_FC_AD,
+ SOCINFO_FC_AE,
+ SOCINFO_FC_AF,
+ SOCINFO_FC_AG,
+ SOCINFO_FC_AH,
+ SOCINFO_FC_EXT_RESERVE,
+};
+
+/* Internal feature codes */
+/* Valid values: 0 <= n <= 0xf */
+#define SOCINFO_FC_Yn(n) (0xf1 + n)
+#define SOCINFO_FC_INT_RESERVE SOCINFO_FC_Yn(0x10)
+
+/* Product codes */
+#define SOCINFO_PC_UNKNOWN 0
+/* Valid values: 0 <= n <= 8, the rest is reserved */
+#define SOCINFO_PCn(n) (n + 1)
+#define SOCINFO_PC_RESERVE (BIT(31) - 1)
+
#endif
--
2.40.1
^ permalink raw reply related
* [PATCH 0/6] Add SMEM-based speedbin matching
From: Konrad Dybcio @ 2024-04-05 8:41 UTC (permalink / raw)
To: Bjorn Andersson, Rob Clark, Abhinav Kumar, Dmitry Baryshkov,
Sean Paul, Marijn Suijten, David Airlie, Daniel Vetter,
Rob Herring, Krzysztof Kozlowski, Conor Dooley
Cc: linux-arm-msm, linux-kernel, dri-devel, freedreno, devicetree,
Neil Armstrong, Konrad Dybcio
Newer (SM8550+) SoCs don't seem to have a nice speedbin fuse anymore,
but instead rely on a set of combinations of "feature code" (FC) and
"product code" (PC) identifiers to match the bins. This series adds
support for that.
I suppose a qcom/for-soc immutable branch would be in order if we want
to land this in the upcoming cycle.
FWIW I preferred the fuses myself..
Signed-off-by: Konrad Dybcio <konrad.dybcio@linaro.org>
---
Konrad Dybcio (5):
soc: qcom: Move some socinfo defines to the header, expand them
soc: qcom: smem: Add pcode/fcode getters
drm/msm/adreno: Implement SMEM-based speed bin
drm/msm/adreno: Add speedbin data for SM8550 / A740
arm64: dts: qcom: sm8550: Wire up GPU speed bin & more OPPs
Neil Armstrong (1):
drm/msm/adreno: Allow specifying default speedbin value
arch/arm64/boot/dts/qcom/sm8550.dtsi | 21 +++++++++-
drivers/gpu/drm/msm/adreno/a6xx_gpu.c | 10 +++--
drivers/gpu/drm/msm/adreno/adreno_device.c | 16 ++++++++
drivers/gpu/drm/msm/adreno/adreno_gpu.c | 39 ++++++++++++++++--
drivers/gpu/drm/msm/adreno/adreno_gpu.h | 13 ++++--
drivers/soc/qcom/smem.c | 66 ++++++++++++++++++++++++++++++
drivers/soc/qcom/socinfo.c | 8 ----
include/linux/soc/qcom/smem.h | 2 +
include/linux/soc/qcom/socinfo.h | 36 ++++++++++++++++
9 files changed, 191 insertions(+), 20 deletions(-)
---
base-commit: 2b3d5988ae2cb5cd945ddbc653f0a71706231fdd
change-id: 20240404-topic-smem_speedbin-8deecd0bef0e
Best regards,
--
Konrad Dybcio <konrad.dybcio@linaro.org>
^ permalink raw reply
* Re: [PATCH v2 02/18] PCI: endpoint: Introduce pci_epc_map_align()
From: Dan Carpenter @ 2024-04-05 8:38 UTC (permalink / raw)
To: oe-kbuild, Damien Le Moal, Manivannan Sadhasivam,
Lorenzo Pieralisi, Kishon Vijay Abraham I, Shawn Lin,
Krzysztof Wilczyński, Bjorn Helgaas, Heiko Stuebner,
linux-pci, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
devicetree
Cc: lkp, oe-kbuild-all, linux-rockchip, linux-arm-kernel,
Rick Wertenbroek, Wilfred Mallawa, Niklas Cassel
In-Reply-To: <20240330041928.1555578-3-dlemoal@kernel.org>
Hi Damien,
kernel test robot noticed the following build warnings:
https://git-scm.com/docs/git-format-patch#_base_tree_information]
url: https://github.com/intel-lab-lkp/linux/commits/Damien-Le-Moal/PCI-endpoint-Introduce-pci_epc_function_is_valid/20240330-122311
base: https://git.kernel.org/pub/scm/linux/kernel/git/pci/pci.git next
patch link: https://lore.kernel.org/r/20240330041928.1555578-3-dlemoal%40kernel.org
patch subject: [PATCH v2 02/18] PCI: endpoint: Introduce pci_epc_map_align()
config: parisc-randconfig-r071-20240405 (https://download.01.org/0day-ci/archive/20240405/202404051508.hvNRDVZq-lkp@intel.com/config)
compiler: hppa-linux-gcc (GCC) 13.2.0
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 <lkp@intel.com>
| Reported-by: Dan Carpenter <dan.carpenter@linaro.org>
| Closes: https://lore.kernel.org/r/202404051508.hvNRDVZq-lkp@intel.com/
smatch warnings:
drivers/pci/endpoint/pci-epc-core.c:493 pci_epc_map_align() error: we previously assumed 'features' could be null (see line 487)
vim +/features +493 drivers/pci/endpoint/pci-epc-core.c
9d2f10d2ace040 Damien Le Moal 2024-03-30 458 int pci_epc_map_align(struct pci_epc *epc, u8 func_no, u8 vfunc_no,
9d2f10d2ace040 Damien Le Moal 2024-03-30 459 u64 pci_addr, size_t size, struct pci_epc_map *map)
9d2f10d2ace040 Damien Le Moal 2024-03-30 460 {
9d2f10d2ace040 Damien Le Moal 2024-03-30 461 const struct pci_epc_features *features;
9d2f10d2ace040 Damien Le Moal 2024-03-30 462 size_t mask;
9d2f10d2ace040 Damien Le Moal 2024-03-30 463 int ret;
9d2f10d2ace040 Damien Le Moal 2024-03-30 464
9d2f10d2ace040 Damien Le Moal 2024-03-30 465 if (!pci_epc_function_is_valid(epc, func_no, vfunc_no))
9d2f10d2ace040 Damien Le Moal 2024-03-30 466 return -EINVAL;
9d2f10d2ace040 Damien Le Moal 2024-03-30 467
9d2f10d2ace040 Damien Le Moal 2024-03-30 468 if (!size || !map)
9d2f10d2ace040 Damien Le Moal 2024-03-30 469 return -EINVAL;
9d2f10d2ace040 Damien Le Moal 2024-03-30 470
9d2f10d2ace040 Damien Le Moal 2024-03-30 471 memset(map, 0, sizeof(*map));
9d2f10d2ace040 Damien Le Moal 2024-03-30 472 map->pci_addr = pci_addr;
9d2f10d2ace040 Damien Le Moal 2024-03-30 473 map->pci_size = size;
9d2f10d2ace040 Damien Le Moal 2024-03-30 474
9d2f10d2ace040 Damien Le Moal 2024-03-30 475 if (epc->ops->map_align) {
9d2f10d2ace040 Damien Le Moal 2024-03-30 476 mutex_lock(&epc->lock);
9d2f10d2ace040 Damien Le Moal 2024-03-30 477 ret = epc->ops->map_align(epc, func_no, vfunc_no, map);
9d2f10d2ace040 Damien Le Moal 2024-03-30 478 mutex_unlock(&epc->lock);
9d2f10d2ace040 Damien Le Moal 2024-03-30 479 return ret;
9d2f10d2ace040 Damien Le Moal 2024-03-30 480 }
9d2f10d2ace040 Damien Le Moal 2024-03-30 481
9d2f10d2ace040 Damien Le Moal 2024-03-30 482 /*
9d2f10d2ace040 Damien Le Moal 2024-03-30 483 * Assume a fixed alignment constraint as specified by the controller
9d2f10d2ace040 Damien Le Moal 2024-03-30 484 * features.
9d2f10d2ace040 Damien Le Moal 2024-03-30 485 */
9d2f10d2ace040 Damien Le Moal 2024-03-30 486 features = pci_epc_get_features(epc, func_no, vfunc_no);
9d2f10d2ace040 Damien Le Moal 2024-03-30 @487 if (!features || !features->align) {
^^^^^^^^^
Check for NULL
9d2f10d2ace040 Damien Le Moal 2024-03-30 488 map->map_pci_addr = pci_addr;
9d2f10d2ace040 Damien Le Moal 2024-03-30 489 map->map_size = size;
9d2f10d2ace040 Damien Le Moal 2024-03-30 490 map->map_ofst = 0;
Missing return 0?
9d2f10d2ace040 Damien Le Moal 2024-03-30 491 }
9d2f10d2ace040 Damien Le Moal 2024-03-30 492
9d2f10d2ace040 Damien Le Moal 2024-03-30 @493 mask = features->align - 1;
^^^^^^^^^^
9d2f10d2ace040 Damien Le Moal 2024-03-30 494 map->map_pci_addr = map->pci_addr & ~mask;
9d2f10d2ace040 Damien Le Moal 2024-03-30 495 map->map_ofst = map->pci_addr & mask;
9d2f10d2ace040 Damien Le Moal 2024-03-30 496 map->map_size = ALIGN(map->map_ofst + map->pci_size, features->align);
9d2f10d2ace040 Damien Le Moal 2024-03-30 497
9d2f10d2ace040 Damien Le Moal 2024-03-30 498 return 0;
9d2f10d2ace040 Damien Le Moal 2024-03-30 499 }
--
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests/wiki
^ permalink raw reply
* Re: Fixing the devicetree of Rock 5 Model B (and possibly others)
From: Pratham Patel @ 2024-04-05 8:32 UTC (permalink / raw)
To: Saravana Kannan
Cc: Dragan Simic, sebastian.reichel, devicetree, linux-arm-kernel,
linux-rockchip, linux-kernel, regressions, stable
In-Reply-To: <D0A2ZL6S8UG6.2BQKIBQWYB36D@thefossguy.com>
On Wednesday, April 3rd, 2024 at 06:33, Pratham Patel <prathampatel@thefossguy.com> wrote:
>
>
> On Wed Apr 3, 2024 at 6:16 AM IST, Saravana Kannan wrote:
>
> > On Tue, Apr 2, 2024 at 4:32 PM Pratham Patel
> > prathampatel@thefossguy.com wrote:
> >
> > > On Tue Apr 2, 2024 at 4:54 AM IST, Saravana Kannan wrote:
> > >
> > > > On Sat, Mar 23, 2024 at 10:10 AM Dragan Simic dsimic@manjaro.org wrote:
> > > >
> > > > > Hello Pratham,
> > > > >
> > > > > On 2024-03-23 18:02, Pratham Patel wrote:
> > > > >
> > > > > > I looked at the patch and tried several things, neither resulted in
> > > > > > anything that would point me to the core issue. Then I tried this:
> > > > >
> > > > > Could you, please, clarify a bit what's the actual issue you're
> > > > > experiencing on your Rock 5B?
> > > >
> > > > Pratham, can you reply to this please? I don't really understand what
> > > > your issue is for me to be able to help.
> > >
> > > Hi,
> > >
> > > I apologize for not replying. Somehow, I did not notice the reply from
> > > Dragan. :(
> > >
> > > Since this patch was applied, an issue in the Rock 5B's DT has been
> > > unearthed which now results in the kernel being unable to boot properly.
> > >
> > > Following is the relevant call trace from the UART capture:
> > >
> > > [ 21.595068] Call trace:
> > > [ 21.595288] smp_call_function_many_cond+0x174/0x5f8
> > > [ 21.595728] on_each_cpu_cond_mask+0x2c/0x40
> > > [ 21.596109] cpuidle_register_driver+0x294/0x318
> > > [ 21.596524] cpuidle_register+0x24/0x100
> > > [ 21.596875] psci_cpuidle_probe+0x2e4/0x490
> > > [ 21.597247] platform_probe+0x70/0xd0
> > > [ 21.597575] really_probe+0x18c/0x3d8
> > > [ 21.597905] __driver_probe_device+0x84/0x180
> > > [ 21.598294] driver_probe_device+0x44/0x120
> > > [ 21.598669] __device_attach_driver+0xc4/0x168
> > > [ 21.599063] bus_for_each_drv+0x8c/0xf0
> > > [ 21.599408] __device_attach+0xa4/0x1c0
> > > [ 21.599748] device_initial_probe+0x1c/0x30
> > > [ 21.600118] bus_probe_device+0xb4/0xc0
> > > [ 21.600462] device_add+0x68c/0x888
> > > [ 21.600775] platform_device_add+0x19c/0x270
> > > [ 21.601154] platform_device_register_full+0xdc/0x178
> > > [ 21.601602] psci_idle_init+0xa0/0xc8
> > > [ 21.601934] do_one_initcall+0x60/0x290
> > > [ 21.602275] kernel_init_freeable+0x20c/0x3e0
> > > [ 21.602664] kernel_init+0x2c/0x1f8
> > > [ 21.602979] ret_from_fork+0x10/0x20
> >
> > This doesn't make a lot of sense. "remote-endpoint" shouldn't be
> > related to anything to do with psci cpuidle. I'm guessing something
> > else is failing much earlier in boot that's indirectly causing this
> > somehow? Can you please take a look at what's failing earlier and let
> > us know? Or see what driver probe is failing up to this point but used
> > to work in the good case.
>
>
> I'm pretty new to this, "just starting". I'm not sure how to do that,
> since the kernel doesn't really "move forward". I will verify if
> a8037ceb8964 fixes it or not and get back by the end of this week.
>
> > Also, where is the dts file that corresponds to this board in upstream? Is it
> > arch/arm64/boot/dts/rockchip/rk3588-rock-5b.dts
>
>
> Yes.
>
> > > > Also, can you give the output of <debugfs>/devices_deferred for the
> > > > good vs bad case?
> > >
> > > I can't provide you with requested output from the bad case, since the
> > > kernel never moves past this to an initramfs rescue shell, but following
> > > is the output from v6.8.1 (with aforementioned patch reverted).
> > >
> > > # cat /sys/kernel/debug/devices_deferred
> > > fc400000.usb platform: wait for supplier /phy@fed90000/usb3-port
> > > 1-0022 typec_fusb302: cannot register tcpm port
> > > fc000000.usb platform: wait for supplier /phy@fed80000/usb3-port
> > >
> > > It seems that v6.8.2 works without needing to revert the patch. I will
> > > have to look into this sometime this week but it seems like
> > > a8037ceb8964 (arm64: dts: rockchip: drop rockchip,trcm-sync-tx-only from rk3588 i2s)
> > > seems to be the one that fixed the root issue. I will have to test it
> > > sometime later this week.
> >
> > Ok, once you find the patch that fixes things, let me know too.
I confirm that a8037ceb8964 fixed this issue for me. Now, v6.8.2+ boots on my Rock 5B,
with my distro's config and the arm64 defconfig.
-- Pratham Patel
^ permalink raw reply
* Re: [PATCH v8 3/7] PCI: qcom: Add ICC bandwidth vote for CPU to PCIe path
From: Manivannan Sadhasivam @ 2024-04-05 8:29 UTC (permalink / raw)
To: Krishna Chaitanya Chundru
Cc: Bjorn Andersson, Konrad Dybcio, Lorenzo Pieralisi,
Krzysztof Wilczyński, Rob Herring, Bjorn Helgaas,
Krzysztof Kozlowski, Conor Dooley, Manivannan Sadhasivam,
Rob Herring, Johan Hovold, Brian Masney, Georgi Djakov,
linux-arm-msm, linux-pci, devicetree, linux-kernel, vireshk,
quic_vbadigan, quic_skananth, quic_nitegupt, quic_parass,
Bryan O'Donoghue
In-Reply-To: <9d878f69-c9d1-1ee4-f80e-1d8f16c6920e@quicinc.com>
On Tue, Mar 05, 2024 at 04:23:21PM +0530, Krishna Chaitanya Chundru wrote:
>
>
> On 3/4/2024 11:11 PM, Manivannan Sadhasivam wrote:
> > On Sat, Mar 02, 2024 at 09:29:57AM +0530, Krishna chaitanya chundru wrote:
> > > To access PCIe registers, PCIe BAR space, config space the CPU-PCIe
> > > ICC (interconnect consumers) path should be voted otherwise it may
> > > lead to NoC (Network on chip) timeout. We are surviving because of
> > > other driver vote for this path.
> > >
> > > As there is less access on this path compared to PCIe to mem path
> > > add minimum vote i.e 1KBps bandwidth always.
> >
> > Please add the info that 1KBps is what shared by the HW team.
> >
> Ack to all the comments
> > >
> > > When suspending, disable this path after register space access
> > > is done.
> > >
> > > Reviewed-by: Bryan O'Donoghue <bryan.odonoghue@linaro.org>
> > > Signed-off-by: Krishna chaitanya chundru <quic_krichai@quicinc.com>
> > > ---
> > > drivers/pci/controller/dwc/pcie-qcom.c | 38 ++++++++++++++++++++++++++++++++--
> > > 1 file changed, 36 insertions(+), 2 deletions(-)
> > >
> > > diff --git a/drivers/pci/controller/dwc/pcie-qcom.c b/drivers/pci/controller/dwc/pcie-qcom.c
> > > index 10f2d0bb86be..a0266bfe71f1 100644
> > > --- a/drivers/pci/controller/dwc/pcie-qcom.c
> > > +++ b/drivers/pci/controller/dwc/pcie-qcom.c
[...]
> > > + ret = icc_disable(pcie->icc_cpu);
> > > + if (ret) {
> > > + dev_err(dev, "failed to disable icc path of cpu-pcie: %d\n", ret);
> >
> > "CPU-PCIe"
> >
> > > + if (pcie->suspended) {
> > > + qcom_pcie_host_init(&pcie->pci->pp);
> >
> > Interesting. So if icc_disable() fails, can the IP continue to function?
> >
> As the ICC already enable before icc_disable() fails, the IP should work.
If icc_disable() fails, then most likely something is wrong with RPMh. How can
the IP continue to work in that case?
- Mani
--
மணிவண்ணன் சதாசிவம்
^ permalink raw reply
* Re: [PATCH v8 7/7] PCI: qcom: Add OPP support to scale performance state of power domain
From: Manivannan Sadhasivam @ 2024-04-05 8:23 UTC (permalink / raw)
To: Krishna Chaitanya Chundru
Cc: Manivannan Sadhasivam, Bjorn Andersson, Konrad Dybcio,
Lorenzo Pieralisi, Krzysztof Wilczyński, Rob Herring,
Bjorn Helgaas, Krzysztof Kozlowski, Conor Dooley, Rob Herring,
Johan Hovold, Brian Masney, Georgi Djakov, linux-arm-msm,
linux-pci, devicetree, linux-kernel, vireshk, quic_vbadigan,
quic_skananth, quic_nitegupt, quic_parass
In-Reply-To: <c74e326e-285d-854e-5e54-329079152df2@quicinc.com>
On Tue, Mar 05, 2024 at 04:44:20PM +0530, Krishna Chaitanya Chundru wrote:
>
>
> On 3/4/2024 11:35 PM, Manivannan Sadhasivam wrote:
> > On Sat, Mar 02, 2024 at 09:30:01AM +0530, Krishna chaitanya chundru wrote:
> > > QCOM Resource Power Manager-hardened (RPMh) is a hardware block which
> > > maintains hardware state of a regulator by performing max aggregation of
> > > the requests made by all of the clients.
> > >
> > > PCIe controller can operate on different RPMh performance state of power
> > > domain based on the speed of the link. And this performance state varies
> > > from target to target, like some controllers support GEN3 in NOM (Nominal)
> > > voltage corner, while some other supports GEN3 in low SVS (static voltage
> > > scaling).
> > >
> > > The SoC can be more power efficient if we scale the performance state
> > > based on the aggregate PCIe link bandwidth.
> > >
> > > Add Operating Performance Points (OPP) support to vote for RPMh state based
> > > on the aggregate link bandwidth.
> > >
> > > OPP can handle ICC bw voting also, so move ICC bw voting through OPP
> > > framework if OPP entries are present.
> > >
> > > Different link configurations may share the same aggregate bandwidth,
> > > e.g., a 2.5 GT/s x2 link and a 5.0 GT/s x1 link have the same bandwidth
> > > and share the same OPP entry.
> > >
> > > As we are moving ICC voting as part of OPP, don't initialize ICC if OPP
> > > is supported.
> > >
> > > Signed-off-by: Krishna chaitanya chundru <quic_krichai@quicinc.com>
> > > ---
> > > drivers/pci/controller/dwc/pcie-qcom.c | 81 +++++++++++++++++++++++++++-------
> > > 1 file changed, 66 insertions(+), 15 deletions(-)
> > >
> > > diff --git a/drivers/pci/controller/dwc/pcie-qcom.c b/drivers/pci/controller/dwc/pcie-qcom.c
> > > index a0266bfe71f1..2ec14bfafcfc 100644
> > > --- a/drivers/pci/controller/dwc/pcie-qcom.c
> > > +++ b/drivers/pci/controller/dwc/pcie-qcom.c
[...]
> > > static int qcom_pcie_link_transition_count(struct seq_file *s, void *data)
> > > @@ -1472,8 +1491,10 @@ static void qcom_pcie_init_debugfs(struct qcom_pcie *pcie)
> > > static int qcom_pcie_probe(struct platform_device *pdev)
> > > {
> > > const struct qcom_pcie_cfg *pcie_cfg;
> > > + unsigned long max_freq = INT_MAX;
> > > struct device *dev = &pdev->dev;
> > > struct qcom_pcie *pcie;
> > > + struct dev_pm_opp *opp;
> > > struct dw_pcie_rp *pp;
> > > struct resource *res;
> > > struct dw_pcie *pci;
> > > @@ -1540,9 +1561,36 @@ static int qcom_pcie_probe(struct platform_device *pdev)
> > > goto err_pm_runtime_put;
> > > }
> > > - ret = qcom_pcie_icc_init(pcie);
> > > - if (ret)
> > > + /* OPP table is optional */
> > > + ret = devm_pm_opp_of_add_table(dev);
> > > + if (ret && ret != -ENODEV) {
> > > + dev_err_probe(dev, ret, "Failed to add OPP table\n");
> > > goto err_pm_runtime_put;
> > > + }
> > > +
> > > + /*
> > > + * Use highest OPP here if the OPP table is present. At the end of
> >
> > Why highest opp? For ICC, we set minimal bandwidth before.
> >
> In OPP we are voting for both ICC and voltage corner also, if we didn't vote
> for maximum voltage core the PCIe link may not come in maximum supported
> speed. Due to that we are voting for Maximum value.
>
Okay, then this information should be part of the comment.
- Mani
--
மணிவண்ணன் சதாசிவம்
^ permalink raw reply
* Re: [PATCH 4/4] clk: en7523: add EN7581 support
From: Lorenzo Bianconi @ 2024-04-05 8:17 UTC (permalink / raw)
To: AngeloGioacchino Del Regno
Cc: linux-clk, mturquette, sboyd, linux-arm-kernel, robh+dt,
krzysztof.kozlowski+dt, conor+dt, nbd, john, devicetree, dd,
catalin.marinas, will, upstream, lorenzo.bianconi83
In-Reply-To: <0297a8ab-2f62-4f03-b2ed-87180a47c57c@collabora.com>
[-- Attachment #1: Type: text/plain, Size: 9826 bytes --]
> Il 03/04/24 18:20, Lorenzo Bianconi ha scritto:
> > Introduce EN7581 clock support to clk-en7523 driver.
> >
> > Tested-by: Zhengping Zhang <zhengping.zhang@airoha.com>
> > Signed-off-by: Lorenzo Bianconi <lorenzo@kernel.org>
> > ---
> > drivers/clk/clk-en7523.c | 130 +++++++++++++++++++++++++++++++++++++--
> > 1 file changed, 125 insertions(+), 5 deletions(-)
> >
> > diff --git a/drivers/clk/clk-en7523.c b/drivers/clk/clk-en7523.c
> > index c7def87b74c6..51a6c0cc7f58 100644
> > --- a/drivers/clk/clk-en7523.c
> > +++ b/drivers/clk/clk-en7523.c
> > @@ -4,13 +4,16 @@
> > #include <linux/clk-provider.h>
> > #include <linux/io.h>
> > #include <linux/of.h>
> > +#include <linux/of_device.h>
> > #include <linux/platform_device.h>
> > #include <dt-bindings/clock/en7523-clk.h>
> > #define REG_PCI_CONTROL 0x88
> > #define REG_PCI_CONTROL_PERSTOUT BIT(29)
> > #define REG_PCI_CONTROL_PERSTOUT1 BIT(26)
> > +#define REG_PCI_CONTROL_REFCLK_EN0 BIT(23)
> > #define REG_PCI_CONTROL_REFCLK_EN1 BIT(22)
> > +#define REG_PCI_CONTROL_PERSTOUT2 BIT(16)
> > #define REG_GSW_CLK_DIV_SEL 0x1b4
> > #define REG_EMI_CLK_DIV_SEL 0x1b8
> > #define REG_BUS_CLK_DIV_SEL 0x1bc
> > @@ -18,10 +21,25 @@
> > #define REG_SPI_CLK_FREQ_SEL 0x1c8
> > #define REG_NPU_CLK_DIV_SEL 0x1fc
> > #define REG_CRYPTO_CLKSRC 0x200
> > -#define REG_RESET_CONTROL 0x834
> > +#define REG_RESET_CONTROL2 0x830
>
> Wait what? The RESET2 register comes before RESET1 ?!?!
>
> Is this a typo? :-)
actually not :)
>
> > +#define REG_RESET2_CONTROL_PCIE2 BIT(27)
> > +#define REG_RESET_CONTROL1 0x834
> > #define REG_RESET_CONTROL_PCIEHB BIT(29)
> > #define REG_RESET_CONTROL_PCIE1 BIT(27)
> > #define REG_RESET_CONTROL_PCIE2 BIT(26)
> > +/* EN7581 */
> > +#define REG_PCIE0_MEM 0x00
> > +#define REG_PCIE0_MEM_MASK 0x04
> > +#define REG_PCIE1_MEM 0x08
> > +#define REG_PCIE1_MEM_MASK 0x0c
> > +#define REG_PCIE2_MEM 0x10
> > +#define REG_PCIE2_MEM_MASK 0x14
> > +#define REG_PCIE_RESET_OPEN_DRAIN 0x018c
> > +#define REG_PCIE_RESET_OPEN_DRAIN_MASK GENMASK(2, 0)
> > +#define REG_NP_SCU_PCIC 0x88
> > +#define REG_NP_SCU_SSTR 0x9c
> > +#define REG_PCIE_XSI0_SEL_MASK GENMASK(14, 13)
> > +#define REG_PCIE_XSI1_SEL_MASK GENMASK(12, 11)
> > struct en_clk_desc {
> > int id;
> > @@ -207,14 +225,14 @@ static int en7523_pci_prepare(struct clk_hw *hw)
> > usleep_range(1000, 2000);
> > /* Reset to default */
> > - val = readl(np_base + REG_RESET_CONTROL);
> > + val = readl(np_base + REG_RESET_CONTROL1);
> > mask = REG_RESET_CONTROL_PCIE1 | REG_RESET_CONTROL_PCIE2 |
> > REG_RESET_CONTROL_PCIEHB;
> > - writel(val & ~mask, np_base + REG_RESET_CONTROL);
> > + writel(val & ~mask, np_base + REG_RESET_CONTROL1);
> > usleep_range(1000, 2000);
> > - writel(val | mask, np_base + REG_RESET_CONTROL);
> > + writel(val | mask, np_base + REG_RESET_CONTROL1);
> > msleep(100);
> > - writel(val & ~mask, np_base + REG_RESET_CONTROL);
> > + writel(val & ~mask, np_base + REG_RESET_CONTROL1);
> > usleep_range(5000, 10000);
> > /* Release device */
> > @@ -262,6 +280,64 @@ static struct clk_hw *en7523_register_pcie_clk(struct device *dev,
> > return &cg->hw;
> > }
> > +static int en7581_pci_is_enabled(struct clk_hw *hw)
> > +{
> > + struct en_clk_gate *cg = container_of(hw, struct en_clk_gate, hw);
> > + u32 val, mask;
> > +
> > + mask = REG_PCI_CONTROL_REFCLK_EN0 | REG_PCI_CONTROL_REFCLK_EN1;
> > + val = readl(cg->base + REG_PCI_CONTROL);
> > + return (val & mask) == mask;
> > +}
> > +
> > +static int en7581_pci_prepare(struct clk_hw *hw)
> > +{
> > + struct en_clk_gate *cg = container_of(hw, struct en_clk_gate, hw);
> > + void __iomem *np_base = cg->base;
> > + u32 val, mask;
> > +
> > + mask = REG_RESET_CONTROL_PCIE1 | REG_RESET_CONTROL_PCIE2 |
> > + REG_RESET_CONTROL_PCIEHB;
> > + val = readl(np_base + REG_RESET_CONTROL1);
> > + writel(val & ~mask, np_base + REG_RESET_CONTROL1);
> > + val = readl(np_base + REG_RESET_CONTROL2);
> > + writel(val & ~REG_RESET2_CONTROL_PCIE2, np_base + REG_RESET_CONTROL2);
> > + usleep_range(5000, 10000);
> > +
> > + mask = REG_PCI_CONTROL_REFCLK_EN0 | REG_PCI_CONTROL_REFCLK_EN1 |
> > + REG_PCI_CONTROL_PERSTOUT1 | REG_PCI_CONTROL_PERSTOUT2 |
> > + REG_PCI_CONTROL_PERSTOUT;
>
> I'm not sure that this is actually something to control in a clock driver...
>
> the right thing to do would be to add a reset controller to this clock driver
> and then assert/deassert reset in the PCIe PHY/MAC driver.
>
> Perhaps REFCLK_EN0/EN1 can be manipulated in a .enable() callback, treating
> this really just as what it appears to really be: a gate clock! (hint: check
> clk-gate.c)
ack, I will look into it.
>
> > + val = readl(np_base + REG_PCI_CONTROL);
> > + writel(val | mask, np_base + REG_PCI_CONTROL);
> > + msleep(250);
> > +
> > + return 0;
> > +}
> > +
> > +static void en7581_pci_unprepare(struct clk_hw *hw)
> > +{
> > + struct en_clk_gate *cg = container_of(hw, struct en_clk_gate, hw);
> > + void __iomem *np_base = cg->base;
> > + u32 val, mask;
> > +
> > + mask = REG_PCI_CONTROL_REFCLK_EN0 | REG_PCI_CONTROL_REFCLK_EN1 |
>
> ...and this should be a clk-gate .disable() callback, I guess :-)
ack, I will look into it.
>
> > + REG_PCI_CONTROL_PERSTOUT1 | REG_PCI_CONTROL_PERSTOUT2 |
> > + REG_PCI_CONTROL_PERSTOUT;
> > + val = readl(np_base + REG_PCI_CONTROL);
> > + writel(val & ~mask, np_base + REG_PCI_CONTROL);
> > + usleep_range(1000, 2000);
> > +
> > + mask = REG_RESET_CONTROL_PCIE1 | REG_RESET_CONTROL_PCIE2 |
> > + REG_RESET_CONTROL_PCIEHB;
> > + val = readl(np_base + REG_RESET_CONTROL1);
> > + writel(val | mask, np_base + REG_RESET_CONTROL1);
> > + mask = REG_RESET_CONTROL_PCIE1 | REG_RESET_CONTROL_PCIE2;
> > + writel(val | mask, np_base + REG_RESET_CONTROL1);
> > + val = readl(np_base + REG_RESET_CONTROL2);
> > + writel(val | REG_RESET_CONTROL_PCIE2, np_base + REG_RESET_CONTROL2);
> > + msleep(100);
> > +}
> > +
> > static void en7523_register_clocks(struct device *dev, struct clk_hw_onecell_data *clk_data,
> > void __iomem *base, void __iomem *np_base)
> > {
> > @@ -291,6 +367,37 @@ static void en7523_register_clocks(struct device *dev, struct clk_hw_onecell_dat
> > clk_data->num = EN7523_NUM_CLOCKS;
> > }
> > +static int en7581_clk_hw_init(struct platform_device *pdev,
> > + void __iomem *base,
> > + void __iomem *np_base)
> > +{
> > + void __iomem *pb_base;
> > + u32 val;
> > +
> > + pb_base = devm_platform_ioremap_resource(pdev, 2);
> > + if (IS_ERR(pb_base))
> > + return PTR_ERR(pb_base);
> > +
> > + val = readl(np_base + REG_NP_SCU_SSTR);
> > + val &= ~(REG_PCIE_XSI0_SEL_MASK | REG_PCIE_XSI1_SEL_MASK);
> > + writel(val, np_base + REG_NP_SCU_SSTR);
> > + val = readl(np_base + REG_NP_SCU_PCIC);
> > + writel(val | 3, np_base + REG_NP_SCU_PCIC);
>
> What is 3?
>
> #define SOMETHING 3 ??
actullay I do not know what it means since write in the pcie_ctrl subfield of
REG_NP_SCU_PCIC but it is a GENMASK(7, 0) and I do not have any more info
about it.
>
> > +
> > + writel(0x20000000, pb_base + REG_PCIE0_MEM);
> > + writel(0xfc000000, pb_base + REG_PCIE0_MEM_MASK);
> > + writel(0x24000000, pb_base + REG_PCIE1_MEM);
> > + writel(0xfc000000, pb_base + REG_PCIE1_MEM_MASK);
> > + writel(0x28000000, pb_base + REG_PCIE2_MEM);
> > + writel(0xfc000000, pb_base + REG_PCIE2_MEM_MASK);
>
> And... this is .. some BIT() and some GENMASK() as far as I understand...
> do we have any clue about what you're setting to those registers?
same as above, they seems undocumented.
@airoha folks: any input about them?
>
> Can MediaTek/Airoha help with this, please?
>
> #define SOMETHING BIT(29) /* this is 0x20000000 */
> #define SOME_MASK GENMASK(31, 26) /* this is 0xfc00000 */
>
> > +
> > + val = readl(base + REG_PCIE_RESET_OPEN_DRAIN);
> > + writel(val | REG_PCIE_RESET_OPEN_DRAIN_MASK,
> > + base + REG_PCIE_RESET_OPEN_DRAIN);
> > +
> > + return 0;
> > +}
> > +
> > static int en7523_clk_probe(struct platform_device *pdev)
> > {
> > struct device_node *node = pdev->dev.of_node;
> > @@ -306,6 +413,12 @@ static int en7523_clk_probe(struct platform_device *pdev)
> > if (IS_ERR(np_base))
> > return PTR_ERR(np_base);
> > + if (of_device_is_compatible(node, "airoha,en7581-scu")) {
> > + r = en7581_clk_hw_init(pdev, base, np_base);
> > + if (r)
> > + return r;
> > + }
> > +
> > clk_data = devm_kzalloc(&pdev->dev,
> > struct_size(clk_data, hws, EN7523_NUM_CLOCKS),
> > GFP_KERNEL);
> > @@ -329,8 +442,15 @@ static const struct clk_ops en7523_pcie_ops = {
> > .unprepare = en7523_pci_unprepare,
> > };
>
> static const struct clk_en7523_pdata en7581_pdata = {
> .init = en7581_clk_hw_init, /* if (pdata->init) pdata->init(x, y, z) */
> .ops = en7581_pcie_ops,
> };
>
> or, alternatively:
>
> static const struct .... = {
> .init = ...,
> .ops = (const struct clk_ops) {
> .is_enabled = en7581_pci_is_enabled,
> .... etc
> }
ack, I will fix it.
Regards,
Lorenzo
> };
>
> Cheers,
> Angelo
>
> > +static const struct clk_ops en7581_pcie_ops = {
> > + .is_enabled = en7581_pci_is_enabled,
> > + .prepare = en7581_pci_prepare,
> > + .unprepare = en7581_pci_unprepare,
> > +};
> > +
> > static const struct of_device_id of_match_clk_en7523[] = {
> > { .compatible = "airoha,en7523-scu", .data = &en7523_pcie_ops },
> > + { .compatible = "airoha,en7581-scu", .data = &en7581_pcie_ops },
> > { /* sentinel */ }
> > };
>
> -
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
^ permalink raw reply
* Re: [PATCH RESEND v3 2/2] Input: atmel_mxt_ts - support poweroff in suspend
From: Stefan Eichenberger @ 2024-04-05 8:15 UTC (permalink / raw)
To: Dmitry Torokhov
Cc: nick, robh+dt, krzysztof.kozlowski+dt, conor+dt, nicolas.ferre,
alexandre.belloni, claudiu.beznea, linus.walleij, linux-input,
devicetree, linux-arm-kernel, linux-kernel, francesco.dolcini,
Stefan Eichenberger
In-Reply-To: <ZfSYp6aV6bRhlPUJ@google.com>
Hi Dmitry,
Thanks for the feedback, I had a first look at the changes and I'm not
sure if we would break some use cases. Therfore, here some questions.
On Fri, Mar 15, 2024 at 11:51:19AM -0700, Dmitry Torokhov wrote:
> > diff --git a/drivers/input/touchscreen/atmel_mxt_ts.c b/drivers/input/touchscreen/atmel_mxt_ts.c
> > index 542a31448c8f..2d5655385702 100644
> > --- a/drivers/input/touchscreen/atmel_mxt_ts.c
> > +++ b/drivers/input/touchscreen/atmel_mxt_ts.c
> > @@ -317,6 +317,7 @@ struct mxt_data {
> > struct gpio_desc *reset_gpio;
> > struct gpio_desc *wake_gpio;
> > bool use_retrigen_workaround;
> > + bool poweroff_sleep;
> >
> > /* Cached parameters from object table */
> > u16 T5_address;
> > @@ -2799,15 +2800,18 @@ static int mxt_configure_objects(struct mxt_data *data,
> > dev_warn(dev, "Error %d updating config\n", error);
> > }
> >
> > - if (data->multitouch) {
> > - error = mxt_initialize_input_device(data);
> > - if (error)
> > - return error;
> > - } else {
> > - dev_warn(dev, "No touch object detected\n");
> > - }
> > + /* If input device is not already registered */
> > + if (!data->input_dev) {
> > + if (data->multitouch) {
> > + error = mxt_initialize_input_device(data);
> > + if (error)
> > + return error;
> > + } else {
> > + dev_warn(dev, "No touch object detected\n");
> > + }
> >
> > - mxt_debug_init(data);
> > + mxt_debug_init(data);
> > + }
> >
> > return 0;
> > }
> > @@ -3325,6 +3329,8 @@ static int mxt_probe(struct i2c_client *client)
> > msleep(MXT_RESET_INVALID_CHG);
> > }
> >
> > + data->poweroff_sleep = device_property_read_bool(&client->dev,
> > + "atmel,poweroff-sleep");
> > /*
> > * Controllers like mXT1386 have a dedicated WAKE line that could be
> > * connected to a GPIO or to I2C SCL pin, or permanently asserted low.
> > @@ -3387,12 +3393,21 @@ static int mxt_suspend(struct device *dev)
> > if (!input_dev)
> > return 0;
> >
> > - mutex_lock(&input_dev->mutex);
> > + if (!device_may_wakeup(dev) && data->poweroff_sleep) {
> > + if (data->reset_gpio)
> > + gpiod_set_value(data->reset_gpio, 1);
> >
> > - if (input_device_enabled(input_dev))
> > - mxt_stop(data);
> > + regulator_bulk_disable(ARRAY_SIZE(data->regulators),
> > + data->regulators);
> > + data->T44_address = 0;
> > + } else {
> > + mutex_lock(&input_dev->mutex);
> > +
> > + if (input_device_enabled(input_dev))
> > + mxt_stop(data);
> >
> > - mutex_unlock(&input_dev->mutex);
> > + mutex_unlock(&input_dev->mutex);
> > + }
>
> This all should go into mxt_stop(), so that if device is closed, or
> inhibited, you power it down as well (if you can).
We would then have to power it up during probe to see if the device is
threre, read the configuration and power it down again afterwards until
the device is opened. If the device is in bootloader mode we would most
likely have to keep the power on all the time and never turn it off,
right?
>
> >
> > disable_irq(data->irq);
> >
> > @@ -3408,14 +3423,37 @@ static int mxt_resume(struct device *dev)
> > if (!input_dev)
> > return 0;
> >
> > - enable_irq(data->irq);
> > + if (!device_may_wakeup(dev) && data->poweroff_sleep) {
> > + int ret;
> >
> > - mutex_lock(&input_dev->mutex);
> > + ret = regulator_bulk_enable(ARRAY_SIZE(data->regulators),
> > + data->regulators);
> > + if (ret) {
> > + dev_err(dev, "failed to enable regulators: %d\n",
> > + ret);
> > + return ret;
> > + }
> > + msleep(MXT_BACKUP_TIME);
> >
> > - if (input_device_enabled(input_dev))
> > - mxt_start(data);
> > + if (data->reset_gpio) {
> > + /* Wait a while and then de-assert the RESET GPIO line */
> > + msleep(MXT_RESET_GPIO_TIME);
> > + gpiod_set_value(data->reset_gpio, 0);
> > + msleep(MXT_RESET_INVALID_CHG);
> > + }
> >
> > - mutex_unlock(&input_dev->mutex);
> > + /* This also enables the irq again */
> > + mxt_initialize(data);
>
> And this needs to go into mxt_start(). Also, we should make sure that
> once resume operation completes the device is fully operational. That
> means you should not request the firmware asynchronously in
> mxt_initialize() in case you are in the resume path. I think you should
> also unwind mxt_initialize() and mxt_configure_objects() to make it
> clear what is the part of initial initialization and what is part of
> re-initializing during resume. The configuration that is exposed to
> userspace (resolution, number of objects, other properties) should stay
> the same, the configuration of the chip itself (power mode, etc) should
> be restored.
Here we would most likely have to load the firmware (configuration)
synchronously all the time if the poweroff_sleep flag is set. Ths makes
sure that the device is ready when we open the device. Would this delay
be acceptable when opening the input device? Normally the configuration
is not that big and should load quite fast.
Regards,
Stefan
^ permalink raw reply
* Re: [PATCH v2] dt-bindings: crypto: ti,omap-sham: Convert to dtschema
From: Animesh Agarwal @ 2024-04-05 8:12 UTC (permalink / raw)
To: Herbert Xu
Cc: David S. Miller, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
linux-crypto, devicetree, linux-kernel
In-Reply-To: <Zg+tgFFDkwLvWgLv@gondor.apana.org.au>
On Fri, Apr 5, 2024 at 1:21 PM Herbert Xu <herbert@gondor.apana.org.au> wrote:
> Patch applied. Thanks.
Glad to hear. Thanks!
---
Animesh Agarwal
^ permalink raw reply
* Re: [PATCH RFT 0/7] arm64: qcom: allow up to 4 lanes for the Type-C DisplayPort Altmode
From: Neil Armstrong @ 2024-04-05 8:08 UTC (permalink / raw)
To: Luca Weiss, Konrad Dybcio, Bjorn Andersson
Cc: Vinod Koul, Kishon Vijay Abraham I, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Abhinav Kumar, linux-arm-msm,
linux-phy, devicetree, linux-kernel
In-Reply-To: <D064242SMIVM.1GUC1I9GE9IGC@fairphone.com>
Hi Luca,
On 29/03/2024 10:02, Luca Weiss wrote:
> On Tue Mar 26, 2024 at 10:02 PM CET, Konrad Dybcio wrote:
>> On 16.03.2024 5:01 PM, Bjorn Andersson wrote:
>>> On Fri, Mar 15, 2024 at 06:35:15PM +0100, Neil Armstrong wrote:
>>>> On 15/03/2024 18:19, Luca Weiss wrote:
>>>>> On Thu Feb 29, 2024 at 2:07 PM CET, Neil Armstrong wrote:
>>>>>> Register a typec mux in order to change the PHY mode on the Type-C
>>>>>> mux events depending on the mode and the svid when in Altmode setup.
>>>>>>
>>>>>> The DisplayPort phy should be left enabled if is still powered on
>>>>>> by the DRM DisplayPort controller, so bail out until the DisplayPort
>>>>>> PHY is not powered off.
>>>>>>
>>>>>> The Type-C Mode/SVID only changes on plug/unplug, and USB SAFE states
>>>>>> will be set in between of USB-Only, Combo and DisplayPort Only so
>>>>>> this will leave enough time to the DRM DisplayPort controller to
>>>>>> turn of the DisplayPort PHY.
>>>>>>
>>>>>> The patchset also includes bindings changes and DT changes.
>>>>>>
>>>>>> This has been successfully tested on an SM8550 board, but the
>>>>>> Thinkpad X13s deserved testing between non-PD USB, non-PD DisplayPort,
>>>>>> PD USB Hubs and PD Altmode Dongles to make sure the switch works
>>>>>> as expected.
>>>>>>
>>>>>> The DisplayPort 4 lanes setup can be check with:
>>>>>> $ cat /sys/kernel/debug/dri/ae01000.display-controller/DP-1/dp_debug
>>>>>> name = msm_dp
>>>>>> drm_dp_link
>>>>>> rate = 540000
>>>>>> num_lanes = 4
>>>>>
>>>>> Hi Neil,
>>>>>
>>>>> I tried this on QCM6490/SC7280 which should also support 4-lane DP but I
>>>>> haven't had any success so far.
>>>>>
>>> [..]
>>>>> [ 1775.563969] [drm:dp_ctrl_link_train] *ERROR* max v_level reached
>>>>> [ 1775.564031] [drm:dp_ctrl_link_train] *ERROR* link training #1 failed. ret=-11
>>>>
>>>> Interesting #1 means the 4 lanes are not physically connected to the other side,
>>>> perhaps QCM6490/SC7280 requires a specific way to enable the 4 lanes in the PHY,
>>>> or some fixups in the init tables.
>>>>
>>>
>>> I tested the same on rb3gen2 (qcs6490) a couple of weeks ago, with the
>>> same outcome. Looking at the AUX reads, after switching to 4-lane the
>>> link training is failing on all 4 lanes, in contrast to succeeding only
>>> on the first 2 if you e.g. forget to mux the other two.
>>>
>>> As such, my expectation is that there's something wrong in the QMP PHY
>>> (or possibly redriver) for this platform.
>>
>> Do we have any downstream tag where 4lane dp works? I'm willing to believe
>> the PHY story..
>
> Just tested on Fairphone 5 downstream and 4 lane appears to work there.
> This is with an USB-C to HDMI adapter that only does HDMI.
>
> FP5:/ # cat /sys/kernel/debug/drm_dp/dp_debug
> state=0x20a5
> link_rate=270000
> num_lanes=4
> resolution=2560x1440@60Hz
> pclock=241500KHz
> bpp=24
> test_req=DP_LINK_STATUS_UPDATED
> lane_count=4
> bw_code=10
> v_level=0
> p_level=0
>
> Sources are here:
> https://gerrit-public.fairphone.software/plugins/gitiles/kernel/msm-5.4/+/refs/heads/odm/rc/target/13/fp5
> And probably more importantly techpack/display:
> https://gerrit-public.fairphone.software/plugins/gitiles/platform/vendor/opensource/display-drivers/+/refs/heads/odm/rc/target/13/fp5
> Dts if useful:
> https://gerrit-public.fairphone.software/plugins/gitiles/kernel/msm-extra/devicetree/+/refs/heads/kernel/13/fp5
Could you retry with this applied ?
https://lore.kernel.org/all/20240405000111.1450598-1-swboyd@chromium.org/
Thanks,
Neil
>
> Regards
> Luca
>
>>
>> Konrad
>
^ permalink raw reply
* Re: [PATCH] dt-bindings: usb: Document the Microchip USB2514 hub
From: Krzysztof Kozlowski @ 2024-04-05 8:04 UTC (permalink / raw)
To: Fabio Estevam, gregkh
Cc: robh, krzk+dt, conor+dt, linux-usb, devicetree, Fabio Estevam
In-Reply-To: <20240404164140.662361-1-festevam@gmail.com>
On 04/04/2024 18:41, Fabio Estevam wrote:
> From: Fabio Estevam <festevam@denx.de>
>
> Document the Microchip USB2514, USB2412, and USB2417 USB hubs.
There is 2514b already. Why it cannot be there? Is the existing file
only for I2C interface and here you add on-board-hub approach interface?
If so, mention it briefly in commit msg (one sentence is enough).
>
> Signed-off-by: Fabio Estevam <festevam@denx.de>
> ---
> .../bindings/usb/microchip,usb2514.yaml | 53 +++++++++++++++++++
> 1 file changed, 53 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/usb/microchip,usb2514.yaml
>
> diff --git a/Documentation/devicetree/bindings/usb/microchip,usb2514.yaml b/Documentation/devicetree/bindings/usb/microchip,usb2514.yaml
> new file mode 100644
> index 000000000000..8df7a5adfbe8
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/usb/microchip,usb2514.yaml
> @@ -0,0 +1,53 @@
> +# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/usb/microchip,usb2514.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: Microchip USB2514 Hub Controller
> +
> +maintainers:
> + - Fabio Estevam <festevam@gmail.com>
> +
> +properties:
> + compatible:
> + enum:
> + - usb424,2412
> + - usb424,2514
> + - usb424,2417
Please keep the list ordered.
> +
> + reg: true
> +
> + reset-gpios:
> + description: GPIO connected to the RESET_N pin.
> +
> + vdd-supply:
> + description: 3.3V power supply.
> +
> + clocks:
> + description: External 24MHz clock connected to the CLKIN pin.
maxItems.
> +
> +required:
> + - compatible
> + - reg
> +
> +unevaluatedProperties: true
No, this must be false.
This does not make really sense. You miss $ref... and when you do not
have $ref you should use additionalProperties: false. Open existing
bindings for device of the same class.
> +
> +examples:
> + - |
> + #include <dt-bindings/clock/imx6qdl-clock.h>
> + #include <dt-bindings/gpio/gpio.h>
> +
> + usb {
> + dr_mode = "host";
Drop property, it's kind of expected/obvious and we want to limit
chances schema will complain about something unrelated to your device.
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + hub@1 {
> + compatible = "usb424,2514";
Inconsistent indentation. Use 4 spaces for example indentation.
> + reg = <1>;
> + clocks = <&clks IMX6QDL_CLK_CKO>;
> + reset-gpios = <&gpio7 12 GPIO_ACTIVE_LOW>;
> + vdd-supply = <®_3v3_hub>;
> + };
> + };
Best regards,
Krzysztof
^ permalink raw reply
* [PATCH v5] dt-bindings: serial: actions,owl-uart: convert to dtschema
From: Kanak Shilledar @ 2024-04-05 8:02 UTC (permalink / raw)
Cc: daniel.baluta, Kanak Shilledar, Krzysztof Kozlowski,
Greg Kroah-Hartman, Jiri Slaby, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Andreas Färber, Manivannan Sadhasivam,
linux-kernel, linux-serial, devicetree, linux-arm-kernel,
linux-actions
From: Kanak Shilledar <kanakshilledar111@protonmail.com>
Convert the Actions Semi Owl UART to newer DT schema.
Created DT schema based on the .txt file which had
`compatible`, `reg` and `interrupts` as the
required properties. This binding is used by Actions S500, S700
and S900 SoC. S700 and S900 use the same UART compatible string.
Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Signed-off-by: Kanak Shilledar <kanakshilledar111@protonmail.com>
---
Changes in v5
- rebased the patch
- sent to all the maintainers
Changes in v4
- updated commit message
- `clocks` property is removed from the required section.
- remove disabled status from example devicetree
---
.../bindings/serial/actions,owl-uart.txt | 16 -------
.../bindings/serial/actions,owl-uart.yaml | 48 +++++++++++++++++++
2 files changed, 48 insertions(+), 16 deletions(-)
delete mode 100644 Documentation/devicetree/bindings/serial/actions,owl-uart.txt
create mode 100644 Documentation/devicetree/bindings/serial/actions,owl-uart.yaml
diff --git a/Documentation/devicetree/bindings/serial/actions,owl-uart.txt b/Documentation/devicetree/bindings/serial/actions,owl-uart.txt
deleted file mode 100644
index aa873eada02d..000000000000
--- a/Documentation/devicetree/bindings/serial/actions,owl-uart.txt
+++ /dev/null
@@ -1,16 +0,0 @@
-Actions Semi Owl UART
-
-Required properties:
-- compatible : "actions,s500-uart", "actions,owl-uart" for S500
- "actions,s900-uart", "actions,owl-uart" for S900
-- reg : Offset and length of the register set for the device.
-- interrupts : Should contain UART interrupt.
-
-
-Example:
-
- uart3: serial@b0126000 {
- compatible = "actions,s500-uart", "actions,owl-uart";
- reg = <0xb0126000 0x1000>;
- interrupts = <GIC_SPI 32 IRQ_TYPE_LEVEL_HIGH>;
- };
diff --git a/Documentation/devicetree/bindings/serial/actions,owl-uart.yaml b/Documentation/devicetree/bindings/serial/actions,owl-uart.yaml
new file mode 100644
index 000000000000..ab1c4514ae93
--- /dev/null
+++ b/Documentation/devicetree/bindings/serial/actions,owl-uart.yaml
@@ -0,0 +1,48 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/serial/actions,owl-uart.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Actions Semi Owl UART
+
+maintainers:
+ - Kanak Shilledar <kanakshilledar111@protonmail.com>
+
+allOf:
+ - $ref: serial.yaml
+
+properties:
+ compatible:
+ items:
+ - enum:
+ - actions,s500-uart
+ - actions,s900-uart
+ - const: actions,owl-uart
+
+ reg:
+ maxItems: 1
+
+ interrupts:
+ maxItems: 1
+
+ clocks:
+ maxItems: 1
+
+required:
+ - compatible
+ - reg
+ - interrupts
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/clock/actions,s500-cmu.h>
+ #include <dt-bindings/interrupt-controller/arm-gic.h>
+ uart0: serial@b0126000 {
+ compatible = "actions,s500-uart", "actions,owl-uart";
+ reg = <0xb0126000 0x1000>;
+ clocks = <&cmu CLK_UART0>;
+ interrupts = <GIC_SPI 32 IRQ_TYPE_LEVEL_HIGH>;
+ };
--
2.34.1
^ permalink raw reply related
* Re: [PATCH] arm64: dts: mediatek: mt7981: add watchdog & WiFi controllers
From: AngeloGioacchino Del Regno @ 2024-04-05 8:02 UTC (permalink / raw)
To: Matthias Brugger, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Rafał Miłecki
Cc: AngeloGioacchino Del Regno, Chunfeng Yun, Greg Kroah-Hartman,
Daniel Golle, linux-usb, linux-arm-kernel, linux-mediatek,
devicetree, linux-kernel, Rafał Miłecki
In-Reply-To: <20240221085547.27840-1-zajec5@gmail.com>
On Wed, 21 Feb 2024 09:55:47 +0100, Rafał Miłecki wrote:
> MT7981 (Filogic 820) is a low cost version of MT7986 (Filogic 830) with
> the same watchdog controller. It also comes with on-SoC 802.11ax
> wireless.
>
>
Applied to v6.9-next/dts64, thanks!
[1/1] arm64: dts: mediatek: mt7981: add watchdog & WiFi controllers
commit: 452f39543ce4cebda3471931b0efc6a46e765458
Cheers,
Angelo
^ permalink raw reply
* Re: (subset) [PATCH 1/2] dt-bindings: usb: mtk-xhci: add compatible for MT7988
From: AngeloGioacchino Del Regno @ 2024-04-05 8:02 UTC (permalink / raw)
To: Matthias Brugger, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Rafał Miłecki
Cc: AngeloGioacchino Del Regno, Chunfeng Yun, Greg Kroah-Hartman,
Daniel Golle, linux-usb, linux-arm-kernel, linux-mediatek,
devicetree, linux-kernel, Rafał Miłecki
In-Reply-To: <20240213130044.1976-1-zajec5@gmail.com>
On Tue, 13 Feb 2024 14:00:43 +0100, Rafał Miłecki wrote:
> From: Rafał Miłecki <rafal@milecki.pl>
>
> MT7988 SoC contains two on-SoC XHCI controllers. Add proper binding.
>
>
Applied to v6.9-next/dts64, thanks!
[2/2] arm64: dts: mediatek: mt7988: add XHCI controllers
commit: 4ee20d528b0487f879f789e010fe2269bc1b2f71
Cheers,
Angelo
^ permalink raw reply
* Re: [PATCH] arm64: dts: mediatek: mt7986: prefix BPI-R3 cooling maps with "map-"
From: AngeloGioacchino Del Regno @ 2024-04-05 8:02 UTC (permalink / raw)
To: Matthias Brugger, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Rafał Miłecki
Cc: AngeloGioacchino Del Regno, Sam Shih, Lorenzo Bianconi,
David S . Miller, Daniel Golle, Frank Wunderlich, devicetree,
linux-kernel, linux-arm-kernel, linux-mediatek,
Rafał Miłecki
In-Reply-To: <20240213061459.17917-1-zajec5@gmail.com>
On Tue, 13 Feb 2024 07:14:59 +0100, Rafał Miłecki wrote:
> This fixes:
> arch/arm64/boot/dts/mediatek/mt7986a-bananapi-bpi-r3.dtb: thermal-zones: cpu-thermal:cooling-maps: 'cpu-active-high', 'cpu-active-low', 'cpu-active-med' do not match any of the regexes: '^map[-a-zA-Z0-9]*$', 'pinctrl-[0-9]+'
> from schema $id: http://devicetree.org/schemas/thermal/thermal-zones.yaml#
>
>
Applied to v6.9-fixes/dts64, thanks!
[1/1] arm64: dts: mediatek: mt7986: prefix BPI-R3 cooling maps with "map-"
commit: f8c65a5e4560781f2ea175d8f26cd75ac98e8d78
Cheers,
Angelo
^ permalink raw reply
* Re: [PATCH] arm64: dts: mediatek: mt2712: fix validation errors
From: AngeloGioacchino Del Regno @ 2024-04-05 8:02 UTC (permalink / raw)
To: Matthias Brugger, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Rafał Miłecki
Cc: AngeloGioacchino Del Regno, Sam Shih, Lorenzo Bianconi,
David S . Miller, Daniel Golle, Frank Wunderlich, devicetree,
linux-kernel, linux-arm-kernel, linux-mediatek,
Rafał Miłecki
In-Reply-To: <20240301074741.8362-1-zajec5@gmail.com>
On Fri, 01 Mar 2024 08:47:41 +0100, Rafał Miłecki wrote:
> 1. Fixup infracfg clock controller binding
> It also acts as reset controller so #reset-cells is required.
> 2. Use -pins suffix for pinctrl
>
> This fixes:
> arch/arm64/boot/dts/mediatek/mt2712-evb.dtb: syscon@10001000: '#reset-cells' is a required property
> from schema $id: http://devicetree.org/schemas/arm/mediatek/mediatek,infracfg.yaml#
> arch/arm64/boot/dts/mediatek/mt2712-evb.dtb: pinctrl@1000b000: 'eth_default', 'eth_sleep', 'usb0_iddig', 'usb1_iddig' do not match any of the regexes: 'pinctrl-[0-9]+', 'pins$'
> from schema $id: http://devicetree.org/schemas/pinctrl/mediatek,mt65xx-pinctrl.yaml#
>
> [...]
Applied to v6.9-fixes/dts64, thanks!
[1/1] arm64: dts: mediatek: mt2712: fix validation errors
commit: 3baac7291effb501c4d52df7019ebf52011e5772
Cheers,
Angelo
^ permalink raw reply
* Re: [PATCH 1/3] arm64: dts: mediatek: mt7986: drop invalid properties from ethsys
From: AngeloGioacchino Del Regno @ 2024-04-05 8:02 UTC (permalink / raw)
To: Matthias Brugger, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Rafał Miłecki
Cc: AngeloGioacchino Del Regno, Sam Shih, Lorenzo Bianconi,
David S . Miller, Daniel Golle, Frank Wunderlich, devicetree,
linux-kernel, linux-arm-kernel, linux-mediatek,
Rafał Miłecki
In-Reply-To: <20240213053739.14387-1-zajec5@gmail.com>
On Tue, 13 Feb 2024 06:37:37 +0100, Rafał Miłecki wrote:
> Mediatek ethsys controller / syscon binding doesn't allow any subnodes
> so "#address-cells" and "#size-cells" are redundant (actually:
> disallowed).
>
> This fixes:
> arch/arm64/boot/dts/mediatek/mt7986a-bananapi-bpi-r3.dtb: syscon@15000000: '#address-cells', '#size-cells' do not match any of the regexes: 'pinctrl-[0-9]+'
> from schema $id: http://devicetree.org/schemas/clock/mediatek,ethsys.yaml#
>
> [...]
Applied to v6.9-fixes/dts64, thanks!
[1/3] arm64: dts: mediatek: mt7986: drop invalid properties from ethsys
commit: 3b449bfd2ff6c5d3ceecfcb18528ff8e1b4ac2fd
[2/3] arm64: dts: mediatek: mt7986: drop "#reset-cells" from Ethernet controller
commit: 9bd88afc94c3570289a0f1c696578b3e1f4e3169
[3/3] arm64: dts: mediatek: mt7986: drop invalid thermal block clock
commit: 970f8b01bd7719a22e577ba6c78e27f9ccf22783
Cheers,
Angelo
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox