* [PATCH v5 2/2] arm64: dts: qcom: sdm670: add thermal zones and thermal devices
From: Richard Acayan @ 2026-03-30 16:52 UTC (permalink / raw)
To: Bjorn Andersson, Konrad Dybcio, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Amit Kucheria, Thara Gopinath, Rafael J. Wysocki,
Daniel Lezcano, Zhang Rui, Lukasz Luba, linux-arm-msm, devicetree,
linux-pm
Cc: Richard Acayan
In-Reply-To: <20260330165237.101045-1-mailingradian@gmail.com>
Add thermal zones to safeguard from overheating to high temperatures,
along with the thermal sensors (TSENS) and CPU frequency limits (LMh).
The temperatures are very high, but should still be safeguard for
devices that do not specify their own thermal zones.
Signed-off-by: Richard Acayan <mailingradian@gmail.com>
---
arch/arm64/boot/dts/qcom/sdm670.dtsi | 400 +++++++++++++++++++++++++++
1 file changed, 400 insertions(+)
diff --git a/arch/arm64/boot/dts/qcom/sdm670.dtsi b/arch/arm64/boot/dts/qcom/sdm670.dtsi
index f115bc6e64f3..c5f7655421a3 100644
--- a/arch/arm64/boot/dts/qcom/sdm670.dtsi
+++ b/arch/arm64/boot/dts/qcom/sdm670.dtsi
@@ -20,6 +20,7 @@
#include <dt-bindings/phy/phy-qcom-qusb2.h>
#include <dt-bindings/power/qcom-rpmpd.h>
#include <dt-bindings/soc/qcom,rpmh-rsc.h>
+#include <dt-bindings/thermal/thermal.h>
/ {
interrupt-parent = <&intc>;
@@ -62,6 +63,7 @@ cpu0: cpu@0 {
<&osm_l3 MASTER_OSM_L3_APPS &osm_l3 SLAVE_OSM_L3>;
power-domains = <&cpu_pd0>;
power-domain-names = "psci";
+ #cooling-cells = <2>;
next-level-cache = <&l2_0>;
l2_0: l2-cache {
compatible = "cache";
@@ -89,6 +91,7 @@ cpu1: cpu@100 {
<&osm_l3 MASTER_OSM_L3_APPS &osm_l3 SLAVE_OSM_L3>;
power-domains = <&cpu_pd1>;
power-domain-names = "psci";
+ #cooling-cells = <2>;
next-level-cache = <&l2_100>;
l2_100: l2-cache {
compatible = "cache";
@@ -111,6 +114,7 @@ cpu2: cpu@200 {
<&osm_l3 MASTER_OSM_L3_APPS &osm_l3 SLAVE_OSM_L3>;
power-domains = <&cpu_pd2>;
power-domain-names = "psci";
+ #cooling-cells = <2>;
next-level-cache = <&l2_200>;
l2_200: l2-cache {
compatible = "cache";
@@ -133,6 +137,7 @@ cpu3: cpu@300 {
<&osm_l3 MASTER_OSM_L3_APPS &osm_l3 SLAVE_OSM_L3>;
power-domains = <&cpu_pd3>;
power-domain-names = "psci";
+ #cooling-cells = <2>;
next-level-cache = <&l2_300>;
l2_300: l2-cache {
compatible = "cache";
@@ -155,6 +160,7 @@ cpu4: cpu@400 {
<&osm_l3 MASTER_OSM_L3_APPS &osm_l3 SLAVE_OSM_L3>;
power-domains = <&cpu_pd4>;
power-domain-names = "psci";
+ #cooling-cells = <2>;
next-level-cache = <&l2_400>;
l2_400: l2-cache {
compatible = "cache";
@@ -177,6 +183,7 @@ cpu5: cpu@500 {
<&osm_l3 MASTER_OSM_L3_APPS &osm_l3 SLAVE_OSM_L3>;
power-domains = <&cpu_pd5>;
power-domain-names = "psci";
+ #cooling-cells = <2>;
next-level-cache = <&l2_500>;
l2_500: l2-cache {
compatible = "cache";
@@ -199,6 +206,7 @@ cpu6: cpu@600 {
<&osm_l3 MASTER_OSM_L3_APPS &osm_l3 SLAVE_OSM_L3>;
power-domains = <&cpu_pd6>;
power-domain-names = "psci";
+ #cooling-cells = <2>;
next-level-cache = <&l2_600>;
l2_600: l2-cache {
compatible = "cache";
@@ -221,6 +229,7 @@ cpu7: cpu@700 {
<&osm_l3 MASTER_OSM_L3_APPS &osm_l3 SLAVE_OSM_L3>;
power-domains = <&cpu_pd7>;
power-domain-names = "psci";
+ #cooling-cells = <2>;
next-level-cache = <&l2_700>;
l2_700: l2-cache {
compatible = "cache";
@@ -1408,6 +1417,8 @@ gpu: gpu@5000000 {
nvmem-cells = <&gpu_speed_bin>;
nvmem-cell-names = "speed_bin";
+ #cooling-cells = <2>;
+
status = "disabled";
gpu_zap_shader: zap-shader {
@@ -2100,6 +2111,28 @@ dispcc: clock-controller@af00000 {
#power-domain-cells = <1>;
};
+ tsens0: thermal-sensor@c263000 {
+ compatible = "qcom,sdm670-tsens", "qcom,tsens-v2";
+ reg = <0 0x0c263000 0 0x1000>,
+ <0 0x0c222000 0 0x1000>;
+ interrupts-extended = <&pdc 26 IRQ_TYPE_EDGE_RISING>,
+ <&pdc 28 IRQ_TYPE_EDGE_RISING>;
+ interrupt-names = "uplow", "critical";
+ #thermal-sensor-cells = <1>;
+ #qcom,sensors = <13>;
+ };
+
+ tsens1: thermal-sensor@c265000 {
+ compatible = "qcom,sdm670-tsens", "qcom,tsens-v2";
+ reg = <0 0x0c265000 0 0x1000>,
+ <0 0x0c223000 0 0x1000>;
+ interrupts-extended = <&pdc 27 IRQ_TYPE_EDGE_RISING>,
+ <&pdc 29 IRQ_TYPE_EDGE_RISING>;
+ interrupt-names = "uplow", "critical";
+ #thermal-sensor-cells = <1>;
+ #qcom,sensors = <8>;
+ };
+
apps_smmu: iommu@15000000 {
compatible = "qcom,sdm670-smmu-500", "qcom,smmu-500", "arm,mmu-500";
reg = <0 0x15000000 0 0x80000>;
@@ -2289,5 +2322,372 @@ cpufreq_hw: cpufreq@17d43000 {
#freq-domain-cells = <1>;
};
+
+ lmh_cluster1: lmh@17d70800 {
+ compatible = "qcom,sdm670-lmh", "qcom,sdm845-lmh";
+ reg = <0 0x17d70800 0 0x400>;
+ interrupts = <GIC_SPI 33 IRQ_TYPE_LEVEL_HIGH>;
+ cpus = <&cpu6>;
+ qcom,lmh-temp-arm-millicelsius = <65000>;
+ qcom,lmh-temp-low-millicelsius = <94500>;
+ qcom,lmh-temp-high-millicelsius = <95000>;
+ interrupt-controller;
+ #interrupt-cells = <1>;
+ };
+
+ lmh_cluster0: lmh@17d78800 {
+ compatible = "qcom,sdm670-lmh", "qcom,sdm845-lmh";
+ reg = <0 0x17d78800 0 0x400>;
+ interrupts = <GIC_SPI 32 IRQ_TYPE_LEVEL_HIGH>;
+ cpus = <&cpu0>;
+ qcom,lmh-temp-arm-millicelsius = <65000>;
+ qcom,lmh-temp-low-millicelsius = <94500>;
+ qcom,lmh-temp-high-millicelsius = <95000>;
+ interrupt-controller;
+ #interrupt-cells = <1>;
+ };
+ };
+
+ thermal-zones {
+ aoss0-thermal {
+ polling-delay-passive = <250>;
+ polling-delay = <1000>;
+
+ thermal-sensors = <&tsens0 0>;
+
+ trips {
+ aoss0_crit: trip-point0 {
+ temperature = <125000>;
+ hysteresis = <1000>;
+ type = "critical";
+ };
+ };
+ };
+
+ cpu0-thermal {
+ polling-delay-passive = <250>;
+ polling-delay = <1000>;
+
+ thermal-sensors = <&tsens0 1>;
+
+ trips {
+ cpu0_crit: trip-point1 {
+ temperature = <125000>;
+ hysteresis = <1000>;
+ type = "critical";
+ };
+ };
+ };
+
+ cpu1-thermal {
+ polling-delay-passive = <250>;
+ polling-delay = <1000>;
+
+ thermal-sensors = <&tsens0 2>;
+
+ trips {
+ cpu1_crit: trip-point1 {
+ temperature = <125000>;
+ hysteresis = <1000>;
+ type = "critical";
+ };
+ };
+ };
+
+ cpu2-thermal {
+ polling-delay-passive = <250>;
+ polling-delay = <1000>;
+
+ thermal-sensors = <&tsens0 3>;
+
+ trips {
+ cpu2_crit: trip-point1 {
+ temperature = <125000>;
+ hysteresis = <1000>;
+ type = "critical";
+ };
+ };
+ };
+
+ cpu3-thermal {
+ polling-delay-passive = <250>;
+ polling-delay = <1000>;
+
+ thermal-sensors = <&tsens0 4>;
+
+ trips {
+ cpu3_crit: trip-point1 {
+ temperature = <125000>;
+ hysteresis = <1000>;
+ type = "critical";
+ };
+ };
+ };
+
+ cluster0-thermal {
+ polling-delay-passive = <250>;
+ polling-delay = <1000>;
+
+ thermal-sensors = <&tsens0 5>;
+
+ trips {
+ cluster0_crit: trip-point1 {
+ temperature = <125000>;
+ hysteresis = <1000>;
+ type = "critical";
+ };
+ };
+ };
+
+ cluster1-thermal {
+ polling-delay-passive = <250>;
+ polling-delay = <1000>;
+
+ thermal-sensors = <&tsens0 6>;
+
+ trips {
+ cluster1_crit: trip-point1 {
+ temperature = <125000>;
+ hysteresis = <1000>;
+ type = "critical";
+ };
+ };
+ };
+
+ cpu4-thermal {
+ polling-delay-passive = <250>;
+ polling-delay = <1000>;
+
+ thermal-sensors = <&tsens0 7>;
+
+ trips {
+ cpu4_crit: trip-point1 {
+ temperature = <125000>;
+ hysteresis = <1000>;
+ type = "critical";
+ };
+ };
+ };
+
+ cpu5-thermal {
+ polling-delay-passive = <250>;
+ polling-delay = <1000>;
+
+ thermal-sensors = <&tsens0 8>;
+
+ trips {
+ cpu5_crit: trip-point1 {
+ temperature = <125000>;
+ hysteresis = <1000>;
+ type = "critical";
+ };
+ };
+ };
+
+ cpu6-thermal {
+ polling-delay-passive = <250>;
+ polling-delay = <1000>;
+
+ thermal-sensors = <&tsens0 9>;
+
+ trips {
+ cpu6_crit: trip-point1 {
+ temperature = <125000>;
+ hysteresis = <1000>;
+ type = "critical";
+ };
+ };
+ };
+
+ cpu7-thermal {
+ polling-delay-passive = <250>;
+ polling-delay = <1000>;
+
+ thermal-sensors = <&tsens0 10>;
+
+ trips {
+ cpu7_crit: trip-point1 {
+ temperature = <125000>;
+ hysteresis = <1000>;
+ type = "critical";
+ };
+ };
+ };
+
+ gpu0-thermal {
+ polling-delay-passive = <250>;
+ polling-delay = <1000>;
+
+ thermal-sensors = <&tsens0 11>;
+
+ cooling-maps {
+ map0 {
+ trip = <&gpu0_alert0>;
+ cooling-device = <&gpu THERMAL_NO_LIMIT THERMAL_NO_LIMIT>;
+ };
+ };
+
+ trips {
+ gpu0_alert0: trip-point0 {
+ temperature = <95000>;
+ hysteresis = <1000>;
+ type = "passive";
+ };
+
+ gpu0_crit: trip-point1 {
+ temperature = <125000>;
+ hysteresis = <1000>;
+ type = "critical";
+ };
+ };
+ };
+
+ gpu1-thermal {
+ polling-delay-passive = <250>;
+ polling-delay = <1000>;
+
+ thermal-sensors = <&tsens0 12>;
+
+ cooling-maps {
+ map0 {
+ trip = <&gpu1_alert0>;
+ cooling-device = <&gpu THERMAL_NO_LIMIT THERMAL_NO_LIMIT>;
+ };
+ };
+
+ trips {
+ gpu1_alert0: trip-point0 {
+ temperature = <95000>;
+ hysteresis = <1000>;
+ type = "passive";
+ };
+
+ gpu1_crit: trip-point1 {
+ temperature = <125000>;
+ hysteresis = <1000>;
+ type = "critical";
+ };
+ };
+ };
+
+ aoss1-thermal {
+ polling-delay-passive = <250>;
+ polling-delay = <1000>;
+
+ thermal-sensors = <&tsens1 0>;
+
+ trips {
+ aoss1_crit: trip-point0 {
+ temperature = <125000>;
+ hysteresis = <1000>;
+ type = "critical";
+ };
+ };
+ };
+
+ q6-modem-thermal {
+ polling-delay-passive = <250>;
+ polling-delay = <1000>;
+
+ thermal-sensors = <&tsens1 1>;
+
+ trips {
+ q6_modem_crit: trip-point0 {
+ temperature = <125000>;
+ hysteresis = <1000>;
+ type = "critical";
+ };
+ };
+ };
+
+ mem-thermal {
+ polling-delay-passive = <250>;
+ polling-delay = <1000>;
+
+ thermal-sensors = <&tsens1 2>;
+
+ trips {
+ mem_crit: trip-point1 {
+ temperature = <125000>;
+ hysteresis = <1000>;
+ type = "critical";
+ };
+ };
+ };
+
+ wlan-thermal {
+ polling-delay-passive = <250>;
+ polling-delay = <1000>;
+
+ thermal-sensors = <&tsens1 3>;
+
+ trips {
+ wlan_crit: trip-point0 {
+ temperature = <125000>;
+ hysteresis = <1000>;
+ type = "critical";
+ };
+ };
+ };
+
+ q6-hvx-thermal {
+ polling-delay-passive = <250>;
+ polling-delay = <1000>;
+
+ thermal-sensors = <&tsens1 4>;
+
+ trips {
+ q6_hvx_crit: trip-point0 {
+ temperature = <125000>;
+ hysteresis = <1000>;
+ type = "critical";
+ };
+ };
+ };
+
+ camera-thermal {
+ polling-delay-passive = <250>;
+ polling-delay = <1000>;
+
+ thermal-sensors = <&tsens1 5>;
+
+ trips {
+ camera_crit: trip-point0 {
+ temperature = <125000>;
+ hysteresis = <1000>;
+ type = "critical";
+ };
+ };
+ };
+
+ video-thermal {
+ polling-delay-passive = <250>;
+ polling-delay = <1000>;
+
+ thermal-sensors = <&tsens1 6>;
+
+ trips {
+ video_crit: trip-point0 {
+ temperature = <125000>;
+ hysteresis = <1000>;
+ type = "critical";
+ };
+ };
+ };
+
+ modem-thermal {
+ polling-delay-passive = <250>;
+ polling-delay = <1000>;
+
+ thermal-sensors = <&tsens1 7>;
+
+ trips {
+ modem_crit: trip-point0 {
+ temperature = <125000>;
+ hysteresis = <1000>;
+ type = "critical";
+ };
+ };
+ };
};
};
--
2.53.0
^ permalink raw reply related
* [PATCH v5 1/2] thermal/qcom/lmh: support SDM670 and its CPU clusters
From: Richard Acayan @ 2026-03-30 16:52 UTC (permalink / raw)
To: Bjorn Andersson, Konrad Dybcio, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Amit Kucheria, Thara Gopinath, Rafael J. Wysocki,
Daniel Lezcano, Zhang Rui, Lukasz Luba, linux-arm-msm, devicetree,
linux-pm
Cc: Richard Acayan
In-Reply-To: <20260330165237.101045-1-mailingradian@gmail.com>
The LMh driver was made for Qualcomm SoCs with clusters of 4 CPUs, but
some SoCs divide the CPUs into different sizes of clusters. In SDM670,
the first 6 CPUs are in the little cluster and the next 2 are in the big
cluster. Define the clusters in the match data and define the different
cluster configuration for SDM670.
Currently, this tolerates linking to any CPU in a given cluster.
Signed-off-by: Richard Acayan <mailingradian@gmail.com>
---
drivers/thermal/qcom/lmh.c | 54 ++++++++++++++++++++++++--------------
1 file changed, 34 insertions(+), 20 deletions(-)
diff --git a/drivers/thermal/qcom/lmh.c b/drivers/thermal/qcom/lmh.c
index 3d072b7a4a6d..81ab2f0be9c8 100644
--- a/drivers/thermal/qcom/lmh.c
+++ b/drivers/thermal/qcom/lmh.c
@@ -30,14 +30,17 @@
#define LMH_REG_DCVS_INTR_CLR 0x8
-#define LMH_ENABLE_ALGOS 1
-
struct lmh_hw_data {
void __iomem *base;
struct irq_domain *domain;
int irq;
};
+struct lmh_soc_data {
+ bool enable_algos;
+ unsigned int clus1_start_idx;
+};
+
static irqreturn_t lmh_handle_irq(int hw_irq, void *data)
{
struct lmh_hw_data *lmh_data = data;
@@ -100,8 +103,8 @@ static int lmh_probe(struct platform_device *pdev)
struct device_node *np = dev->of_node;
struct device_node *cpu_node;
struct lmh_hw_data *lmh_data;
+ const struct lmh_soc_data *match_data;
int temp_low, temp_high, temp_arm, cpu_id, ret;
- unsigned int enable_alg;
u32 node_id;
if (!qcom_scm_is_available())
@@ -121,6 +124,11 @@ static int lmh_probe(struct platform_device *pdev)
cpu_id = of_cpu_node_to_id(cpu_node);
of_node_put(cpu_node);
+ if (cpu_id < 0) {
+ dev_err(dev, "Wrong CPU id associated with LMh node\n");
+ return -EINVAL;
+ }
+
ret = of_property_read_u32(np, "qcom,lmh-temp-high-millicelsius", &temp_high);
if (ret) {
dev_err(dev, "missing qcom,lmh-temp-high-millicelsius property\n");
@@ -139,26 +147,16 @@ static int lmh_probe(struct platform_device *pdev)
return ret;
}
- /*
- * Only sdm845 has lmh hardware currently enabled from hlos. If this is needed
- * for other platforms, revisit this to check if the <cpu-id, node-id> should be part
- * of a dt match table.
- */
- if (cpu_id == 0) {
+ match_data = of_device_get_match_data(dev);
+ if (cpu_id < match_data->clus1_start_idx)
node_id = LMH_CLUSTER0_NODE_ID;
- } else if (cpu_id == 4) {
+ else
node_id = LMH_CLUSTER1_NODE_ID;
- } else {
- dev_err(dev, "Wrong CPU id associated with LMh node\n");
- return -EINVAL;
- }
if (!qcom_scm_lmh_dcvsh_available())
return -EINVAL;
- enable_alg = (uintptr_t)of_device_get_match_data(dev);
-
- if (enable_alg) {
+ if (match_data->enable_algos) {
ret = qcom_scm_lmh_dcvsh(LMH_SUB_FN_CRNT, LMH_ALGO_MODE_ENABLE, 1,
LMH_NODE_DCVS, node_id, 0);
if (ret)
@@ -231,10 +229,26 @@ static int lmh_probe(struct platform_device *pdev)
return 0;
}
+static const struct lmh_soc_data sdm670_lmh_data = {
+ .enable_algos = true,
+ .clus1_start_idx = 6,
+};
+
+static const struct lmh_soc_data sdm845_lmh_data = {
+ .enable_algos = true,
+ .clus1_start_idx = 4,
+};
+
+static const struct lmh_soc_data sm8150_lmh_data = {
+ .enable_algos = false,
+ .clus1_start_idx = 4,
+};
+
static const struct of_device_id lmh_table[] = {
- { .compatible = "qcom,sc8180x-lmh", },
- { .compatible = "qcom,sdm845-lmh", .data = (void *)LMH_ENABLE_ALGOS},
- { .compatible = "qcom,sm8150-lmh", },
+ { .compatible = "qcom,sc8180x-lmh", .data = &sm8150_lmh_data },
+ { .compatible = "qcom,sdm670-lmh", .data = &sdm670_lmh_data },
+ { .compatible = "qcom,sdm845-lmh", .data = &sdm845_lmh_data },
+ { .compatible = "qcom,sm8150-lmh", .data = &sm8150_lmh_data },
{}
};
MODULE_DEVICE_TABLE(of, lmh_table);
--
2.53.0
^ permalink raw reply related
* [PATCH v5 0/2] SDM670 Basic SoC thermal zones
From: Richard Acayan @ 2026-03-30 16:52 UTC (permalink / raw)
To: Bjorn Andersson, Konrad Dybcio, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Amit Kucheria, Thara Gopinath, Rafael J. Wysocki,
Daniel Lezcano, Zhang Rui, Lukasz Luba, linux-arm-msm, devicetree,
linux-pm
Cc: Richard Acayan
This adds support for the thermal sensor, for thermal-based CPU
throttling via LMh, and for thermal zones.
Changes since v4 (https://lore.kernel.org/r/20260328014041.83777-1-mailingradian@gmail.com):
- use simple comparison to differentiate between cluster 0 and 1 (1/2)
- drop applied dt-bindings patches (previously 1-2/4)
Changes since v3 (https://lore.kernel.org/r/20260310002037.1863-1-mailingradian@gmail.com):
- support LMh clusters starting at CPU 6 (dt-bindings tag dropped) (3/4)
Changes since v2 (https://lore.kernel.org/r/20260304014530.27775-1-mailingradian@gmail.com):
- remove cooling from memory thermal zone (3/3)
Changes since v1 (https://lore.kernel.org/r/20260210021607.12576-1-mailingradian@gmail.com):
- add review tag from Krzysztof (1/3)
- replace CPU thermal zones with lmh (2/3, 3/3)
Richard Acayan (2):
thermal/qcom/lmh: support SDM670 and its CPU clusters
arm64: dts: qcom: sdm670: add thermal zones and thermal devices
arch/arm64/boot/dts/qcom/sdm670.dtsi | 400 +++++++++++++++++++++++++++
drivers/thermal/qcom/lmh.c | 54 ++--
2 files changed, 434 insertions(+), 20 deletions(-)
--
2.53.0
^ permalink raw reply
* Re: [PATCH v5 08/10] dmaengine: tegra: Use iommu-map for stream ID
From: Frank Li @ 2026-03-30 16:47 UTC (permalink / raw)
To: Akhil R
Cc: Vinod Koul, Frank Li, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Thierry Reding, Jonathan Hunter, Laxman Dewangan,
Philipp Zabel, dmaengine, devicetree, linux-tegra, linux-kernel
In-Reply-To: <20260330144456.13551-9-akhilrajeev@nvidia.com>
On Mon, Mar 30, 2026 at 08:14:54PM +0530, Akhil R wrote:
> Use 'iommu-map', when provided, to get the stream ID to be programmed
> for each channel. Iterate over the channels registered and configure
> each channel device separately using of_dma_configure_id() to allow
> it to use a separate IOMMU domain for the transfer. However, do this
> in a second loop since the first loop populates the DMA device channels
> list and async_device_register() registers the channels. Both are
> prerequisites for using the channel device in the next loop.
>
> Channels will continue to use the same global stream ID if the
> 'iommu-map' property is not present in the device tree.
>
> Signed-off-by: Akhil R <akhilrajeev@nvidia.com>
> ---
...
>
> + /*
> + * Configure stream ID for each channel from the channels registered
> + * above. This is done in a separate iteration to ensure that only
> + * the channels available and registered for the DMA device are used.
> + */
> + list_for_each_entry(chan, &tdma->dma_dev.channels, device_node) {
> + chdev = &chan->dev->device;
> + tdc = to_tegra_dma_chan(chan);
> +
> + if (use_iommu_map) {
> + chdev->bus = pdev->dev.bus;
> + dma_coerce_mask_and_coherent(chdev, DMA_BIT_MASK(cdata->addr_bits));
> +
> + ret = of_dma_configure_id(chdev, pdev->dev.of_node,
> + true, &tdc->id);
> + if (ret)
> + return dev_err_probe(chdev, ret,
> + "Failed to configure IOMMU for channel %d", tdc->id);
> +
> + if (!tegra_dev_iommu_get_stream_id(chdev, &stream_id)) {
> + dev_err(chdev, "Failed to get stream ID for channel %d\n",
> + tdc->id);
> + return -EINVAL;
Can you check similar problem before post patch, here also can use
return dev_err_probe()
Frank
> + }
> +
> + chan->dev->chan_dma_dev = true;
> + }
> +
> + /* program stream-id for this channel */
> + tegra_dma_program_sid(tdc, stream_id);
> + tdc->stream_id = stream_id;
> + }
> +
> ret = devm_of_dma_controller_register(&pdev->dev, pdev->dev.of_node,
> tegra_dma_of_xlate, tdma);
> if (ret < 0) {
> --
> 2.50.1
>
^ permalink raw reply
* [PATCH v4 5/5] arm64: dts: qcom: sdm670-google: add reserved lpi gpios
From: Richard Acayan @ 2026-03-30 16:47 UTC (permalink / raw)
To: Bjorn Andersson, Linus Walleij, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Konrad Dybcio, Srinivas Kandagatla, linux-arm-msm,
linux-gpio, devicetree
Cc: Richard Acayan
In-Reply-To: <20260330164707.87441-1-mailingradian@gmail.com>
Some of the GPIOs are reserved for sensors since the ADSP also handles
sensors on SDM670. Add the reserved GPIOs for the LPI pin controller.
Signed-off-by: Richard Acayan <mailingradian@gmail.com>
Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
---
arch/arm64/boot/dts/qcom/sdm670-google-common.dtsi | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/arch/arm64/boot/dts/qcom/sdm670-google-common.dtsi b/arch/arm64/boot/dts/qcom/sdm670-google-common.dtsi
index cf7b130ea0c4..b0da24fd1aee 100644
--- a/arch/arm64/boot/dts/qcom/sdm670-google-common.dtsi
+++ b/arch/arm64/boot/dts/qcom/sdm670-google-common.dtsi
@@ -519,6 +519,10 @@ rmi4_f12: rmi4-f12@12 {
};
};
+&lpi_tlmm {
+ gpio-reserved-ranges = <0 8>, <12 6>;
+};
+
&mdss {
status = "okay";
};
--
2.53.0
^ permalink raw reply related
* [PATCH v4 4/5] arm64: dts: qcom: sdm670: add lpi pinctrl
From: Richard Acayan @ 2026-03-30 16:47 UTC (permalink / raw)
To: Bjorn Andersson, Linus Walleij, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Konrad Dybcio, Srinivas Kandagatla, linux-arm-msm,
linux-gpio, devicetree
Cc: Richard Acayan
In-Reply-To: <20260330164707.87441-1-mailingradian@gmail.com>
The Snapdragon 670 has a separate TLMM for audio pins. Add the device
node for it.
Signed-off-by: Richard Acayan <mailingradian@gmail.com>
Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
---
arch/arm64/boot/dts/qcom/sdm670.dtsi | 73 ++++++++++++++++++++++++++++
1 file changed, 73 insertions(+)
diff --git a/arch/arm64/boot/dts/qcom/sdm670.dtsi b/arch/arm64/boot/dts/qcom/sdm670.dtsi
index c5f7655421a3..85a34e2f0907 100644
--- a/arch/arm64/boot/dts/qcom/sdm670.dtsi
+++ b/arch/arm64/boot/dts/qcom/sdm670.dtsi
@@ -2346,6 +2346,79 @@ lmh_cluster0: lmh@17d78800 {
interrupt-controller;
#interrupt-cells = <1>;
};
+
+ lpi_tlmm: pinctrl@62b40000 {
+ compatible = "qcom,sdm670-lpass-lpi-pinctrl";
+ reg = <0 0x62b40000 0 0x20000>;
+ gpio-controller;
+ #gpio-cells = <2>;
+ gpio-ranges = <&lpi_tlmm 0 0 32>;
+
+ cdc_pdm_default: cdc-pdm-default-state {
+ clk-pins {
+ pins = "gpio18";
+ function = "slimbus_clk";
+ drive-strength = <4>;
+ output-low;
+ };
+
+ sync-pins {
+ pins = "gpio19";
+ function = "pdm_sync";
+ drive-strength = <4>;
+ output-low;
+ };
+
+ tx-pins {
+ pins = "gpio20";
+ function = "pdm_tx";
+ drive-strength = <8>;
+ };
+
+ rx-pins {
+ pins = "gpio21", "gpio23", "gpio25";
+ function = "pdm_rx";
+ drive-strength = <4>;
+ output-low;
+ };
+ };
+
+ cdc_comp_default: cdc-comp-default-state {
+ pins = "gpio22", "gpio24";
+ function = "comp_rx";
+ drive-strength = <4>;
+ };
+
+ cdc_dmic_default: cdc-dmic-default-state {
+ clk1-pins {
+ pins = "gpio26";
+ function = "dmic1_clk";
+ drive-strength = <8>;
+ output-high;
+ };
+
+ clk2-pins {
+ pins = "gpio28";
+ function = "dmic2_clk";
+ drive-strength = <8>;
+ output-high;
+ };
+
+ data1-pins {
+ pins = "gpio27";
+ function = "dmic1_data";
+ drive-strength = <8>;
+ input-enable;
+ };
+
+ data2-pins {
+ pins = "gpio29";
+ function = "dmic2_data";
+ drive-strength = <8>;
+ input-enable;
+ };
+ };
+ };
};
thermal-zones {
--
2.53.0
^ permalink raw reply related
* [PATCH v4 3/5] pinctrl: qcom: add sdm670 lpi tlmm
From: Richard Acayan @ 2026-03-30 16:47 UTC (permalink / raw)
To: Bjorn Andersson, Linus Walleij, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Konrad Dybcio, Srinivas Kandagatla, linux-arm-msm,
linux-gpio, devicetree
Cc: Richard Acayan
In-Reply-To: <20260330164707.87441-1-mailingradian@gmail.com>
The Snapdragon 670 has an Low-Power Island (LPI) TLMM for configuring
pins related to audio. Add the driver for this.
Signed-off-by: Richard Acayan <mailingradian@gmail.com>
Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
---
drivers/pinctrl/qcom/Kconfig | 10 ++
drivers/pinctrl/qcom/Makefile | 1 +
.../pinctrl/qcom/pinctrl-sdm670-lpass-lpi.c | 166 ++++++++++++++++++
3 files changed, 177 insertions(+)
create mode 100644 drivers/pinctrl/qcom/pinctrl-sdm670-lpass-lpi.c
diff --git a/drivers/pinctrl/qcom/Kconfig b/drivers/pinctrl/qcom/Kconfig
index f56592411cf6..eb8ed3effd58 100644
--- a/drivers/pinctrl/qcom/Kconfig
+++ b/drivers/pinctrl/qcom/Kconfig
@@ -89,6 +89,16 @@ config PINCTRL_SM4250_LPASS_LPI
Qualcomm Technologies Inc LPASS (Low Power Audio SubSystem) LPI
(Low Power Island) found on the Qualcomm Technologies Inc SM4250 platform.
+config PINCTRL_SDM670_LPASS_LPI
+ tristate "Qualcomm Technologies Inc SDM670 LPASS LPI pin controller driver"
+ depends on GPIOLIB
+ depends on ARM64 || COMPILE_TEST
+ depends on PINCTRL_LPASS_LPI
+ help
+ This is the pinctrl, pinmux, pinconf and gpiolib driver for the
+ Qualcomm Technologies Inc LPASS (Low Power Audio SubSystem) LPI
+ (Low Power Island) found on the Qualcomm Technologies Inc SDM670 platform.
+
config PINCTRL_SM6115_LPASS_LPI
tristate "Qualcomm Technologies Inc SM6115 LPASS LPI pin controller driver"
depends on ARM64 || COMPILE_TEST
diff --git a/drivers/pinctrl/qcom/Makefile b/drivers/pinctrl/qcom/Makefile
index 4269d1781015..ed2127d26912 100644
--- a/drivers/pinctrl/qcom/Makefile
+++ b/drivers/pinctrl/qcom/Makefile
@@ -48,6 +48,7 @@ obj-$(CONFIG_PINCTRL_SC8280XP) += pinctrl-sc8280xp.o
obj-$(CONFIG_PINCTRL_SDM660) += pinctrl-sdm660.o
obj-$(CONFIG_PINCTRL_SDM660_LPASS_LPI) += pinctrl-sdm660-lpass-lpi.o
obj-$(CONFIG_PINCTRL_SDM670) += pinctrl-sdm670.o
+obj-$(CONFIG_PINCTRL_SDM670_LPASS_LPI) += pinctrl-sdm670-lpass-lpi.o
obj-$(CONFIG_PINCTRL_SDM845) += pinctrl-sdm845.o
obj-$(CONFIG_PINCTRL_SDX55) += pinctrl-sdx55.o
obj-$(CONFIG_PINCTRL_SDX65) += pinctrl-sdx65.o
diff --git a/drivers/pinctrl/qcom/pinctrl-sdm670-lpass-lpi.c b/drivers/pinctrl/qcom/pinctrl-sdm670-lpass-lpi.c
new file mode 100644
index 000000000000..6270c6d09c22
--- /dev/null
+++ b/drivers/pinctrl/qcom/pinctrl-sdm670-lpass-lpi.c
@@ -0,0 +1,166 @@
+// SPDX-License-Identifier: GPL-2.0-only
+/*
+ * Copyright (c) 2023-2026, Richard Acayan. All rights reserved.
+ */
+
+#include <linux/kernel.h>
+#include <linux/module.h>
+#include <linux/of.h>
+#include <linux/platform_device.h>
+#include <linux/pinctrl/pinctrl.h>
+
+#include "pinctrl-lpass-lpi.h"
+
+enum lpass_lpi_functions {
+ LPI_MUX_comp_rx,
+ LPI_MUX_dmic1_clk,
+ LPI_MUX_dmic1_data,
+ LPI_MUX_dmic2_clk,
+ LPI_MUX_dmic2_data,
+ LPI_MUX_i2s1_clk,
+ LPI_MUX_i2s1_data,
+ LPI_MUX_i2s1_ws,
+ LPI_MUX_lpi_cdc_rst,
+ LPI_MUX_mclk0,
+ LPI_MUX_pdm_rx,
+ LPI_MUX_pdm_sync,
+ LPI_MUX_pdm_tx,
+ LPI_MUX_slimbus_clk,
+ LPI_MUX_gpio,
+ LPI_MUX__,
+};
+
+static const struct pinctrl_pin_desc sdm670_lpi_pinctrl_pins[] = {
+ PINCTRL_PIN(0, "gpio0"),
+ PINCTRL_PIN(1, "gpio1"),
+ PINCTRL_PIN(2, "gpio2"),
+ PINCTRL_PIN(3, "gpio3"),
+ PINCTRL_PIN(4, "gpio4"),
+ PINCTRL_PIN(5, "gpio5"),
+ PINCTRL_PIN(6, "gpio6"),
+ PINCTRL_PIN(7, "gpio7"),
+ PINCTRL_PIN(8, "gpio8"),
+ PINCTRL_PIN(9, "gpio9"),
+ PINCTRL_PIN(10, "gpio10"),
+ PINCTRL_PIN(11, "gpio11"),
+ PINCTRL_PIN(12, "gpio12"),
+ PINCTRL_PIN(13, "gpio13"),
+ PINCTRL_PIN(14, "gpio14"),
+ PINCTRL_PIN(15, "gpio15"),
+ PINCTRL_PIN(16, "gpio16"),
+ PINCTRL_PIN(17, "gpio17"),
+ PINCTRL_PIN(18, "gpio18"),
+ PINCTRL_PIN(19, "gpio19"),
+ PINCTRL_PIN(20, "gpio20"),
+ PINCTRL_PIN(21, "gpio21"),
+ PINCTRL_PIN(22, "gpio22"),
+ PINCTRL_PIN(23, "gpio23"),
+ PINCTRL_PIN(24, "gpio24"),
+ PINCTRL_PIN(25, "gpio25"),
+ PINCTRL_PIN(26, "gpio26"),
+ PINCTRL_PIN(27, "gpio27"),
+ PINCTRL_PIN(28, "gpio28"),
+ PINCTRL_PIN(29, "gpio29"),
+ PINCTRL_PIN(30, "gpio30"),
+ PINCTRL_PIN(31, "gpio31"),
+};
+
+static const char * const comp_rx_groups[] = { "gpio22", "gpio24" };
+static const char * const dmic1_clk_groups[] = { "gpio26" };
+static const char * const dmic1_data_groups[] = { "gpio27" };
+static const char * const dmic2_clk_groups[] = { "gpio28" };
+static const char * const dmic2_data_groups[] = { "gpio29" };
+static const char * const i2s1_clk_groups[] = { "gpio8" };
+static const char * const i2s1_ws_groups[] = { "gpio9" };
+static const char * const i2s1_data_groups[] = { "gpio10", "gpio11" };
+static const char * const lpi_cdc_rst_groups[] = { "gpio29" };
+static const char * const mclk0_groups[] = { "gpio19" };
+static const char * const pdm_rx_groups[] = { "gpio21", "gpio23", "gpio25" };
+static const char * const pdm_sync_groups[] = { "gpio19" };
+static const char * const pdm_tx_groups[] = { "gpio20" };
+static const char * const slimbus_clk_groups[] = { "gpio18" };
+
+const struct lpi_pingroup sdm670_lpi_pinctrl_groups[] = {
+ LPI_PINGROUP(0, LPI_NO_SLEW, _, _, _, _),
+ LPI_PINGROUP(1, LPI_NO_SLEW, _, _, _, _),
+ LPI_PINGROUP(2, LPI_NO_SLEW, _, _, _, _),
+ LPI_PINGROUP(3, LPI_NO_SLEW, _, _, _, _),
+ LPI_PINGROUP(4, LPI_NO_SLEW, _, _, _, _),
+ LPI_PINGROUP(5, LPI_NO_SLEW, _, _, _, _),
+ LPI_PINGROUP(6, LPI_NO_SLEW, _, _, _, _),
+ LPI_PINGROUP(7, LPI_NO_SLEW, _, _, _, _),
+ LPI_PINGROUP(8, LPI_NO_SLEW, _, _, i2s1_clk, _),
+ LPI_PINGROUP(9, LPI_NO_SLEW, _, _, i2s1_ws, _),
+ LPI_PINGROUP(10, LPI_NO_SLEW, _, _, _, i2s1_data),
+ LPI_PINGROUP(11, LPI_NO_SLEW, _, i2s1_data, _, _),
+ LPI_PINGROUP(12, LPI_NO_SLEW, _, _, _, _),
+ LPI_PINGROUP(13, LPI_NO_SLEW, _, _, _, _),
+ LPI_PINGROUP(14, LPI_NO_SLEW, _, _, _, _),
+ LPI_PINGROUP(15, LPI_NO_SLEW, _, _, _, _),
+ LPI_PINGROUP(16, LPI_NO_SLEW, _, _, _, _),
+ LPI_PINGROUP(17, LPI_NO_SLEW, _, _, _, _),
+ LPI_PINGROUP(18, LPI_NO_SLEW, _, slimbus_clk, _, _),
+ LPI_PINGROUP(19, LPI_NO_SLEW, mclk0, _, pdm_sync, _),
+ LPI_PINGROUP(20, LPI_NO_SLEW, _, pdm_tx, _, _),
+ LPI_PINGROUP(21, LPI_NO_SLEW, _, pdm_rx, _, _),
+ LPI_PINGROUP(22, LPI_NO_SLEW, _, comp_rx, _, _),
+ LPI_PINGROUP(23, LPI_NO_SLEW, pdm_rx, _, _, _),
+ LPI_PINGROUP(24, LPI_NO_SLEW, comp_rx, _, _, _),
+ LPI_PINGROUP(25, LPI_NO_SLEW, pdm_rx, _, _, _),
+ LPI_PINGROUP(26, LPI_NO_SLEW, dmic1_clk, _, _, _),
+ LPI_PINGROUP(27, LPI_NO_SLEW, dmic1_data, _, _, _),
+ LPI_PINGROUP(28, LPI_NO_SLEW, dmic2_clk, _, _, _),
+ LPI_PINGROUP(29, LPI_NO_SLEW, dmic2_data, lpi_cdc_rst, _, _),
+ LPI_PINGROUP(30, LPI_NO_SLEW, _, _, _, _),
+ LPI_PINGROUP(31, LPI_NO_SLEW, _, _, _, _),
+};
+
+const struct lpi_function sdm670_lpi_pinctrl_functions[] = {
+ LPI_FUNCTION(comp_rx),
+ LPI_FUNCTION(dmic1_clk),
+ LPI_FUNCTION(dmic1_data),
+ LPI_FUNCTION(dmic2_clk),
+ LPI_FUNCTION(dmic2_data),
+ LPI_FUNCTION(i2s1_clk),
+ LPI_FUNCTION(i2s1_data),
+ LPI_FUNCTION(i2s1_ws),
+ LPI_FUNCTION(lpi_cdc_rst),
+ LPI_FUNCTION(mclk0),
+ LPI_FUNCTION(pdm_tx),
+ LPI_FUNCTION(pdm_rx),
+ LPI_FUNCTION(pdm_sync),
+ LPI_FUNCTION(slimbus_clk),
+};
+
+static const struct lpi_pinctrl_variant_data sdm670_lpi_pinctrl_data = {
+ .pins = sdm670_lpi_pinctrl_pins,
+ .npins = ARRAY_SIZE(sdm670_lpi_pinctrl_pins),
+ .groups = sdm670_lpi_pinctrl_groups,
+ .ngroups = ARRAY_SIZE(sdm670_lpi_pinctrl_groups),
+ .functions = sdm670_lpi_pinctrl_functions,
+ .nfunctions = ARRAY_SIZE(sdm670_lpi_pinctrl_functions),
+ .flags = LPI_FLAG_SLEW_RATE_SAME_REG,
+};
+
+static const struct of_device_id sdm670_lpi_pinctrl_of_match[] = {
+ {
+ .compatible = "qcom,sdm670-lpass-lpi-pinctrl",
+ .data = &sdm670_lpi_pinctrl_data,
+ },
+ { }
+};
+MODULE_DEVICE_TABLE(of, sdm670_lpi_pinctrl_of_match);
+
+static struct platform_driver sdm670_lpi_pinctrl_driver = {
+ .driver = {
+ .name = "qcom-sdm670-lpass-lpi-pinctrl",
+ .of_match_table = sdm670_lpi_pinctrl_of_match,
+ },
+ .probe = lpi_pinctrl_probe,
+ .remove = lpi_pinctrl_remove,
+};
+module_platform_driver(sdm670_lpi_pinctrl_driver);
+
+MODULE_AUTHOR("Richard Acayan <mailingradian@gmail.com>");
+MODULE_DESCRIPTION("QTI SDM670 LPI GPIO pin control driver");
+MODULE_LICENSE("GPL");
--
2.53.0
^ permalink raw reply related
* [PATCH v4 2/5] dt-bindings: pinctrl: qcom: Add SDM670 LPASS LPI pinctrl
From: Richard Acayan @ 2026-03-30 16:47 UTC (permalink / raw)
To: Bjorn Andersson, Linus Walleij, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Konrad Dybcio, Srinivas Kandagatla, linux-arm-msm,
linux-gpio, devicetree
Cc: Richard Acayan
In-Reply-To: <20260330164707.87441-1-mailingradian@gmail.com>
Add the pin controller for the audio Low-Power Island (LPI) on SDM670.
Signed-off-by: Richard Acayan <mailingradian@gmail.com>
Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
---
.../qcom,sdm670-lpass-lpi-pinctrl.yaml | 81 +++++++++++++++++++
1 file changed, 81 insertions(+)
create mode 100644 Documentation/devicetree/bindings/pinctrl/qcom,sdm670-lpass-lpi-pinctrl.yaml
diff --git a/Documentation/devicetree/bindings/pinctrl/qcom,sdm670-lpass-lpi-pinctrl.yaml b/Documentation/devicetree/bindings/pinctrl/qcom,sdm670-lpass-lpi-pinctrl.yaml
new file mode 100644
index 000000000000..c76ad70e6b9f
--- /dev/null
+++ b/Documentation/devicetree/bindings/pinctrl/qcom,sdm670-lpass-lpi-pinctrl.yaml
@@ -0,0 +1,81 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/pinctrl/qcom,sdm670-lpass-lpi-pinctrl.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Qualcomm SDM670 SoC LPASS LPI TLMM
+
+maintainers:
+ - Richard Acayan <mailingradian@gmail.com>
+
+description:
+ Top Level Mode Multiplexer pin controller in the Low Power Audio SubSystem
+ (LPASS) Low Power Island (LPI) of Qualcomm SDM670 SoC.
+
+properties:
+ compatible:
+ const: qcom,sdm670-lpass-lpi-pinctrl
+
+ reg:
+ items:
+ - description: LPASS LPI TLMM Control and Status registers
+
+patternProperties:
+ "-state$":
+ oneOf:
+ - $ref: "#/$defs/qcom-sdm670-lpass-state"
+ - patternProperties:
+ "-pins$":
+ $ref: "#/$defs/qcom-sdm670-lpass-state"
+ additionalProperties: false
+
+$defs:
+ qcom-sdm670-lpass-state:
+ type: object
+ description:
+ Pinctrl node's client devices use subnodes for desired pin configuration.
+ Client device subnodes use below standard properties.
+ $ref: qcom,lpass-lpi-common.yaml#/$defs/qcom-tlmm-state
+ unevaluatedProperties: false
+
+ properties:
+ pins:
+ description:
+ List of gpio pins affected by the properties specified in this
+ subnode.
+ items:
+ pattern: "^gpio([0-9]|1[0-9]|2[0-9]|3[0-1])$"
+
+ function:
+ enum: [ gpio, comp_rx, dmic1_clk, dmic1_data, dmic2_clk, dmic2_data,
+ i2s1_clk, i2s_data, i2s_ws, lpi_cdc_rst, mclk0, pdm_rx,
+ pdm_sync, pdm_tx, slimbus_clk ]
+ description:
+ Specify the alternative function to be configured for the specified
+ pins.
+
+allOf:
+ - $ref: qcom,lpass-lpi-common.yaml#
+
+required:
+ - compatible
+ - reg
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ lpi_tlmm: pinctrl@62b40000 {
+ compatible = "qcom,sdm670-lpass-lpi-pinctrl";
+ reg = <0x62b40000 0x20000>;
+ gpio-controller;
+ #gpio-cells = <2>;
+ gpio-ranges = <&lpi_tlmm 0 0 32>;
+
+ cdc_comp_default: cdc-comp-default-state {
+ pins = "gpio22", "gpio24";
+ function = "comp_rx";
+ drive-strength = <4>;
+ };
+ };
--
2.53.0
^ permalink raw reply related
* [PATCH v4 1/5] dt-bindings: qcom: lpass-lpi-common: add reserved GPIOs property
From: Richard Acayan @ 2026-03-30 16:47 UTC (permalink / raw)
To: Bjorn Andersson, Linus Walleij, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Konrad Dybcio, Srinivas Kandagatla, linux-arm-msm,
linux-gpio, devicetree
Cc: Richard Acayan
In-Reply-To: <20260330164707.87441-1-mailingradian@gmail.com>
There can be reserved GPIOs on the LPASS LPI pin controller to possibly
control sensors. Add the property for reserved GPIOs so they can be
avoided appropriately.
Adapted from the same entry in qcom,tlmm-common.yaml.
Signed-off-by: Richard Acayan <mailingradian@gmail.com>
Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
---
.../bindings/pinctrl/qcom,lpass-lpi-common.yaml | 8 ++++++++
1 file changed, 8 insertions(+)
diff --git a/Documentation/devicetree/bindings/pinctrl/qcom,lpass-lpi-common.yaml b/Documentation/devicetree/bindings/pinctrl/qcom,lpass-lpi-common.yaml
index 619341dd637c..30f93b8159fd 100644
--- a/Documentation/devicetree/bindings/pinctrl/qcom,lpass-lpi-common.yaml
+++ b/Documentation/devicetree/bindings/pinctrl/qcom,lpass-lpi-common.yaml
@@ -27,6 +27,14 @@ properties:
gpio-ranges:
maxItems: 1
+ gpio-reserved-ranges:
+ minItems: 1
+ maxItems: 30
+ description:
+ Pins can be reserved for trusted applications or for LPASS, thereby
+ inaccessible from the OS. This property can be used to mark the pins
+ which resources should not be accessed by the OS.
+
required:
- gpio-controller
- "#gpio-cells"
--
2.53.0
^ permalink raw reply related
* [PATCH v4 0/5] SDM670 LPASS LPI pin controller support
From: Richard Acayan @ 2026-03-30 16:47 UTC (permalink / raw)
To: Bjorn Andersson, Linus Walleij, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Konrad Dybcio, Srinivas Kandagatla, linux-arm-msm,
linux-gpio, devicetree
Cc: Richard Acayan
This adds support for the LPASS LPI pin controller on SDM670, which
controls some audio pins (e.g. TDM or PDM busses). The ADSP patches are
not sent yet.
Dependencies:
- SDM670 Basic SoC thermal zones (devicetree nodes are touching)
https://lore.kernel.org/r/20260310002037.1863-1-mailingradian@gmail.com
- Support for the Pixel 3a XL with the Tianma panel (for reserved GPIOs)
https://lore.kernel.org/r/20260310002606.16413-1-mailingradian@gmail.com
Changes since v2 (https://lore.kernel.org/r/20260328021036.85945-1-mailingradian@gmail.com):
- restore review tags (2-5/5)
- add review tags (1/5)
Changes since v2 (https://lore.kernel.org/r/20260310012446.32226-1-mailingradian@gmail.com):
- add minItems and maxItems (1/5)
- add review tags (2-5/5)
Changes since v1 (https://lore.kernel.org/r/20260210021109.11906-1-mailingradian@gmail.com):
- add LPASS in dt-bindings patch subject (2/5)
- change pin names (2/5, 3/5, 4/5)
- add reviewed-by from Krzysztof (2/5)
- specify gpio-reserved-ranges (1/5, 5/5)
Richard Acayan (5):
dt-bindings: qcom: lpass-lpi-common: add reserved GPIOs property
dt-bindings: pinctrl: qcom: Add SDM670 LPASS LPI pinctrl
pinctrl: qcom: add sdm670 lpi tlmm
arm64: dts: qcom: sdm670: add lpi pinctrl
arm64: dts: qcom: sdm670-google: add reserved lpi gpios
.../pinctrl/qcom,lpass-lpi-common.yaml | 8 +
.../qcom,sdm670-lpass-lpi-pinctrl.yaml | 81 +++++++++
.../boot/dts/qcom/sdm670-google-common.dtsi | 4 +
arch/arm64/boot/dts/qcom/sdm670.dtsi | 73 ++++++++
drivers/pinctrl/qcom/Kconfig | 10 ++
drivers/pinctrl/qcom/Makefile | 1 +
.../pinctrl/qcom/pinctrl-sdm670-lpass-lpi.c | 166 ++++++++++++++++++
7 files changed, 343 insertions(+)
create mode 100644 Documentation/devicetree/bindings/pinctrl/qcom,sdm670-lpass-lpi-pinctrl.yaml
create mode 100644 drivers/pinctrl/qcom/pinctrl-sdm670-lpass-lpi.c
--
2.53.0
^ permalink raw reply
* Re: [PATCH 0/4] ASoC: Add support for GPIOs driven amplifiers
From: Herve Codina @ 2026-03-30 16:41 UTC (permalink / raw)
To: Mark Brown
Cc: Liam Girdwood, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Saravana Kannan, Jaroslav Kysela, Takashi Iwai, linux-sound,
devicetree, linux-kernel, Christophe Leroy, Thomas Petazzoni
In-Reply-To: <27e23c7b-4aca-41d2-96b8-df02c52e8121@sirena.org.uk>
On Mon, 30 Mar 2026 16:48:54 +0100
Mark Brown <broonie@kernel.org> wrote:
> On Mon, Mar 30, 2026 at 05:39:44PM +0200, Herve Codina wrote:
> > Mark Brown <broonie@kernel.org> wrote:
>
> > > This sounds a lot like simple-amplifier.c?
>
> > The gpio driven amplifier proposed is more generic and can handle
> > more complex design. I.e. op-amp + resistor and/or line (mute,
> > bypass) switching. Hardwares handled by this driver are a superset
> > of just dio2125 and so simple-amplifier.c.
>
> > IMHO, it makes sense to have a specific driver for those kind
> > of hardware design.
>
> Right, and if it's a superset it feels like it should all be one driver
> rather than two separate ones.
Also, it is worth noting that simple-amplifier.c considered a stereo
amplifier (left + right).
Considering the two op-amp available in dio2125 as just two op-amp used
in two separated mono channel with additional component to switch related
to resistors (independant switching for each channel) means that almost
everything proposed in audio-gpio-amp have to be duplicated (gain, mute,
bypass per channel) instead of just instantiate two audio-gpio-amps.
On the other hand, there is no reason to handle a stereo component in
audio-gpio-amp. Further more with the hardware I have handling a stereo
component doesn't make sense. Indeed, I only have independent mono lines
with their own resistor switched amplification circuitry.
I could merge everything in one .c file but only a few part of source code
will be common to simple-amplifier and audio-gpio-amp. IMHO the resulting
merged code will look like two different drivers merged in one .c file.
Best regards,
Hervé
^ permalink raw reply
* Re: [PATCH v2 09/11] dt-bindings: mfd: ti,omap-usb-host: Add 'pbias-supply' property
From: Thomas Richard @ 2026-03-30 16:40 UTC (permalink / raw)
To: Aaro Koskinen, Andreas Kemnade, Kevin Hilman, Roger Quadros,
Tony Lindgren, Liam Girdwood, Mark Brown, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Lee Jones
Cc: Thomas Petazzoni, linux-omap, linux-kernel, devicetree
In-Reply-To: <20260330-omap4-fix-usb-support-v2-9-1c1e11b190dc@bootlin.com>
On 3/30/26 3:44 PM, Thomas Richard wrote:
> Add the 'pbias-supply' property, it is used to specify the voltage
> regulator that provides the bias voltage for USB cell.
>
> Signed-off-by: Thomas Richard <thomas.richard@bootlin.com>
> ---
> Documentation/devicetree/bindings/mfd/ti,omap-usb-host.yaml | 6 ++++++
> 1 file changed, 6 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/mfd/ti,omap-usb-host.yaml b/Documentation/devicetree/bindings/mfd/ti,omap-usb-host.yaml
> index 3b5b041f0321..d0a61dec4961 100644
> --- a/Documentation/devicetree/bindings/mfd/ti,omap-usb-host.yaml
> +++ b/Documentation/devicetree/bindings/mfd/ti,omap-usb-host.yaml
> @@ -83,6 +83,12 @@ properties:
>
> ranges: true
>
> + pbias-supply:
> + $ref: /schemas/types.yaml#/definitions/phandle
I'm sorry, I missed dt_binding_check error. $ref is not needed.
Best Regards,
Thomas
^ permalink raw reply
* Re: [PATCH v5 4/4] platform: Add initial synology microp driver
From: Conor Dooley @ 2026-03-30 16:31 UTC (permalink / raw)
To: Krzysztof Kozlowski
Cc: markus.probst, Hans de Goede, Ilpo Järvinen,
Bryan O'Donoghue, Lee Jones, Pavel Machek, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Miguel Ojeda, Boqun Feng,
Gary Guo, Björn Roy Baron, Benno Lossin, Andreas Hindborg,
Alice Ryhl, Trevor Gross, Danilo Krummrich, Greg Kroah-Hartman,
Rafael J. Wysocki, Len Brown, Saravana Kannan,
platform-driver-x86, linux-leds, devicetree, linux-kernel,
rust-for-linux, linux-acpi
In-Reply-To: <6d2fb01a-216b-4f51-8a26-527d724002d7@kernel.org>
[-- Attachment #1: Type: text/plain, Size: 3373 bytes --]
On Mon, Mar 30, 2026 at 08:51:14AM +0200, Krzysztof Kozlowski wrote:
> On 29/03/2026 20:02, Markus Probst via B4 Relay wrote:
> > +
> > +kernel::of_device_table!(
> > + pub(crate) OF_TABLE,
> > + MODULE_OF_TABLE,
> > + Model,
> > + models![
> > + apollolake @ [
> > + ds918p,
> > + ],
> > + evansport @ [
> > + ds214play,
> > + ],
> > + geminilakenk @ [
> > + ds225p.led_usb_copy(),
> > + ds425p,
> > + ],
> > + pineview @ [
> > + ds710p.led_esata(),
> > + ds1010p.led_alert(Color::Orange),
> > + ],
> > + r1000 @ [
> > + ds923p,
> > + ds723p,
> > + ds1522p,
> > + rs422p.led_power(Color::Green),
> > + ],
> > + r1000nk @ [
> > + ds725p,
> > + ],
> > + rtd1296 @ [
> > + ds118,
> > + ],
> > + rtd1619b @ [
> > + ds124,
> > + ds223.led_usb_copy(),
> > + ds223j,
> > + ],
> > + v1000 @ [
> > + ds1823xsp,
> > + rs822p.led_power(Color::Green),
> > + rs1221p.led_power(Color::Green),
> > + rs1221rpp.led_power(Color::Green),
> > + ],
> > + v1000nk @ [
> > + ds925p,
> > + ds1525p,
> > + ds1825p,
> I don't see any compatible strings here. Actually, nowhere in the
> driver. If that's how you write Rust drivers then NAK. Compatibles must
> be greppable. Not only for humans but also for ABI check.
The code immediately prior creates a macro, which is called here to
produce these. This macro is barely grokkable to begin with IMO, but
you can see the DeviceID::new() call down there that creates the
compatible using string concatenation.
Definitely on the same page as you about compatibles being greppable.
It's not as if it is difficult to create the list using vim or whatever
code generator llm you wanna use. Probably making the macro was more
effort than writing them out!
+macro_rules! models {
+ [
+ $($arch:ident $(.$arch_func:ident( $($arch_arg:tt)* ))*
+ @ [
+ $($model:ident $(.$func:ident( $($arg:tt)* ))*, )*
+ ],
+ )*
+ ] => {
+ models![
+ $(
+ {
+ Architecture::new()
+ $(
+ .$arch_func($($arch_arg)*)
+ )*
+ }
+ @
+ [
+ $(
+ $model $(.$func($($arg)*))*,
+ )*
+ ],
+ )*
+ ]
+ };
+ [
+ $($arch:block
+ @ [
+ $($model:ident $(.$func:ident( $($arg:tt)* ))*, )*
+ ],
+ )*
+ ] => {
+ [
+ $(
+ $((
+ DeviceId::new(::kernel::c_str!(
+ ::core::concat!(
+ "synology,",
+ ::core::stringify!($model),
+ "-microp",
+ )
+ )),
+ Model::new($arch)
+ $(
+ .$func($($arg)*)
+ )*
+ ),)*
+ )*
+ ]
+ };
+}
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
^ permalink raw reply
* Re: [PATCH 0/2] Add support for Infineon Digital eFuse XDP720
From: Guenter Roeck @ 2026-03-30 16:25 UTC (permalink / raw)
To: ASHISH YADAV, Rob Herring, Krzysztof Kozlowski, Conor Dooley
Cc: linux-hwmon, devicetree, linux-kernel, Ashish Yadav
In-Reply-To: <20260330102345.37065-1-Ashish.Yadav@infineon.com>
Hi,
On 3/30/26 03:23, ASHISH YADAV wrote:
> From: Ashish Yadav <ashish.yadav@infineon.com>
>
> Hi,
>
> These patches add support for Infineon Digital eFuse XDP720.
> XDP720 provides accurate system telemetry (V, I, P, T) and
> reports analog current at the IMON pin for post-processing.
>
> The Current and Power measurement depends on the RIMON and GIMON values.
> Please look into data sheet sections 5.4.2 and 5.4.4 for more details:
> https://www.infineon.com/assets/row/public/documents/24/49/infineon-xdp720-001-datasheet-en.pdf
>
Please address the issues reported in
https://sashiko.dev/#/patchset/20260330102345.37065-1-Ashish.Yadav%40infineon.com
Thanks,
Guenter
> With Best Regards,
> Ashish Yadav
>
>
> Ashish Yadav (2):
> dt-bindings: hwmon/pmbus: Add Infineon XDP720
> hwmon:(pmbus/xdp720) Add support for efuse xdp720
>
> .../bindings/hwmon/pmbus/infineon,xdp720.yaml | 52 ++++++++
> drivers/hwmon/pmbus/Kconfig | 9 ++
> drivers/hwmon/pmbus/Makefile | 1 +
> drivers/hwmon/pmbus/xdp720.c | 122 ++++++++++++++++++
> 4 files changed, 184 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/hwmon/pmbus/infineon,xdp720.yaml
> create mode 100644 drivers/hwmon/pmbus/xdp720.c
>
^ permalink raw reply
* Re: [PATCH v2 2/3] remoteproc: imx_rproc: Pass bootaddr to SM CPU/LMM reset vector
From: Mathieu Poirier @ 2026-03-30 16:22 UTC (permalink / raw)
To: Peng Fan (OSS)
Cc: Bjorn Andersson, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Frank Li, Sascha Hauer, Pengutronix Kernel Team, Fabio Estevam,
Daniel Baluta, linux-remoteproc, devicetree, imx,
linux-arm-kernel, linux-kernel, Peng Fan
In-Reply-To: <20260327-imx943-rproc-v2-2-a547a3588730@nxp.com>
On Fri, Mar 27, 2026 at 10:42:03AM +0800, Peng Fan (OSS) wrote:
> From: Peng Fan <peng.fan@nxp.com>
>
> Cortex-M[7,33] processors use a fixed reset vector table format:
>
> 0x00 Initial SP value
> 0x04 Reset vector
> 0x08 NMI
> 0x0C ...
> ...
> IRQ[n]
>
> In ELF images, the corresponding layout is:
>
> reset_vectors: --> hardware reset address
> .word __stack_end__
> .word Reset_Handler
> .word NMI_Handler
> .word HardFault_Handler
> ...
> .word UART_IRQHandler
> .word SPI_IRQHandler
> ...
>
> Reset_Handler: --> ELF entry point address
> ...
>
> The hardware fetches the first two words from reset_vectors and populates
> SP with __stack_end__ and PC with Reset_Handler. Execution proceeds from
> Reset_Handler.
>
> However, the ELF entry point does not always match the hardware reset
> address. For example, on i.MX94 CM33S:
>
> ELF entry point: 0x0ffc211d
> hardware reset base: 0x0ffc0000 (default reset value, sw programmable)
>
But why? Why can't the ELF image be set to the right reset base?
> To derive the correct hardware reset address, the unused lower bits must
> be masked off. The boot code should apply a SoC-specific mask before
> programming the reset address registers, e.g.:
>
> reset_address = entry & reset_vector_mask
>
> Current driver always programs the reset vector as 0. But i.MX94 CM33S's
> default reset base is 0x0ffc0000, so the correct reset vector must be
> passed to the SM API; otherwise the M33 Sync core cannot boot successfully.
>
> rproc_elf_get_boot_addr() returns the ELF entry point, which is not the
> hardware reset vector address. To derive the proper reset vector, this
> patch introduces imx_rproc_get_boot_addr(), which masks the ELF entry
> point using the SoC‑specific 'reset_vector_mask'. The resulting reset
> vector address is then passed to the SM CPU/LMM reset vector API calls.
>
> Signed-off-by: Peng Fan <peng.fan@nxp.com>
> ---
> drivers/remoteproc/imx_rproc.c | 17 ++++++++++++++---
> drivers/remoteproc/imx_rproc.h | 2 ++
> 2 files changed, 16 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/remoteproc/imx_rproc.c b/drivers/remoteproc/imx_rproc.c
> index 0dd80e688b0ea3df4c66e5726884dc86c8a5a881..d8ead42640881bd523d605fa7002935ef6e98077 100644
> --- a/drivers/remoteproc/imx_rproc.c
> +++ b/drivers/remoteproc/imx_rproc.c
> @@ -345,7 +345,7 @@ static int imx_rproc_sm_cpu_start(struct rproc *rproc)
> const struct imx_rproc_dcfg *dcfg = priv->dcfg;
> int ret;
>
> - ret = scmi_imx_cpu_reset_vector_set(dcfg->cpuid, 0, true, false, false);
> + ret = scmi_imx_cpu_reset_vector_set(dcfg->cpuid, rproc->bootaddr, true, false, false);
> if (ret) {
> dev_err(priv->dev, "Failed to set reset vector cpuid(%u): %d\n", dcfg->cpuid, ret);
> return ret;
> @@ -365,7 +365,7 @@ static int imx_rproc_sm_lmm_start(struct rproc *rproc)
> * If the remoteproc core can't start the M7, it will already be
> * handled in imx_rproc_sm_lmm_prepare().
> */
> - ret = scmi_imx_lmm_reset_vector_set(dcfg->lmid, dcfg->cpuid, 0, 0);
> + ret = scmi_imx_lmm_reset_vector_set(dcfg->lmid, dcfg->cpuid, 0, rproc->bootaddr);
> if (ret) {
> dev_err(dev, "Failed to set reset vector lmid(%u), cpuid(%u): %d\n",
> dcfg->lmid, dcfg->cpuid, ret);
> @@ -739,6 +739,17 @@ imx_rproc_elf_find_loaded_rsc_table(struct rproc *rproc, const struct firmware *
> return rproc_elf_find_loaded_rsc_table(rproc, fw);
> }
>
> +static u64 imx_rproc_get_boot_addr(struct rproc *rproc, const struct firmware *fw)
> +{
> + struct imx_rproc *priv = rproc->priv;
> + u32 reset_vector_mask = GENMASK_U32(31, 0);
> +
> + if (priv->dcfg->reset_vector_mask)
> + reset_vector_mask = priv->dcfg->reset_vector_mask;
> +
> + return rproc_elf_get_boot_addr(rproc, fw) & reset_vector_mask;
> +}
> +
> static const struct rproc_ops imx_rproc_ops = {
> .prepare = imx_rproc_prepare,
> .attach = imx_rproc_attach,
> @@ -752,7 +763,7 @@ static const struct rproc_ops imx_rproc_ops = {
> .find_loaded_rsc_table = imx_rproc_elf_find_loaded_rsc_table,
> .get_loaded_rsc_table = imx_rproc_get_loaded_rsc_table,
> .sanity_check = rproc_elf_sanity_check,
> - .get_boot_addr = rproc_elf_get_boot_addr,
> + .get_boot_addr = imx_rproc_get_boot_addr,
> };
>
> static int imx_rproc_addr_init(struct imx_rproc *priv,
> diff --git a/drivers/remoteproc/imx_rproc.h b/drivers/remoteproc/imx_rproc.h
> index d37e6f90548cec727b4aeb874680b42af85bdbb4..0d7d48352a1091ad24e8e083172ce6da6d26ae10 100644
> --- a/drivers/remoteproc/imx_rproc.h
> +++ b/drivers/remoteproc/imx_rproc.h
> @@ -41,6 +41,8 @@ struct imx_rproc_dcfg {
> /* For System Manager(SM) based SoCs */
> u32 cpuid; /* ID of the remote core */
> u32 lmid; /* ID of the Logcial Machine */
> + /* reset_vector = elf_entry_addr & reset_vector_mask */
> + u32 reset_vector_mask;
> };
>
> #endif /* _IMX_RPROC_H */
>
> --
> 2.37.1
>
^ permalink raw reply
* Re: [PATCH net-next v5 00/14] macb usrio/tsu patches
From: Conor Dooley @ 2026-03-30 16:20 UTC (permalink / raw)
To: Jiawen Wu
Cc: patchwork-bot+netdevbpf, netdev, conor.dooley,
Valentina.FernandezAlanis, andrew+netdev, davem, edumazet, kuba,
pabeni, robh, krzk+dt, conor+dt, daire.mcnamara, pjw, palmer, aou,
alex, nicolas.ferre, claudiu.beznea, richardcochran,
samuel.holland, devicetree, linux-kernel, linux-riscv,
dave.stevenson, sean.anderson, vineeth.karumanchi, abin.joseph,
theo.lebrun, Ryan.Wanner, haokexin
In-Reply-To: <06a701dcc014$86def5b0$949ce110$@trustnetic.com>
[-- Attachment #1: Type: text/plain, Size: 972 bytes --]
On Mon, Mar 30, 2026 at 03:12:10PM +0800, Jiawen Wu wrote:
> > Hello:
> >
> > This series was applied to netdev/net-next.git (main)
> > by Jakub Kicinski <kuba@kernel.org>:
> >
> > On Wed, 25 Mar 2026 16:28:04 +0000 you wrote:
> > > From: Conor Dooley <conor.dooley@microchip.com>
> > >
> > > Hey folks,
> > >
> > > At the very least, it'd be good of the soc vendor folks could check
> > > their platforms and see if their usrio stuff actually lines up with what
> > > the driver currently calls "macb_default_usrio". Ours didn't and it was
> > > a nasty surprise.
> > >
> > > [...]
> >
> > Here is the summary with links:
> > - [net-next,v5,02/14] net: macb: rename macb_default_usrio to at91_default_usrio as not all platforms have mii mode control in
> There are compilation errors after merging this patch set.
> I believe the error occurred where the CONFIG_OF is not set.
Thanks for the report. I have sent what's hopefully a fix..
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
^ permalink raw reply
* Re: [PATCH v3] dt-bindings: timer: Add SiFive CLINT2
From: Conor Dooley @ 2026-03-30 16:16 UTC (permalink / raw)
To: Charles Perry
Cc: Nick Hu, Daniel Lezcano, Thomas Gleixner, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Paul Walmsley, Samuel Holland,
Palmer Dabbelt, Anup Patel, linux-kernel, devicetree, linux-riscv
In-Reply-To: <acWdSsAtmyTTFVHb@bby-cbu-swbuild03.eng.microchip.com>
[-- Attachment #1: Type: text/plain, Size: 3448 bytes --]
On Thu, Mar 26, 2026 at 01:55:38PM -0700, Charles Perry wrote:
> On Fri, Mar 21, 2025 at 04:35:06PM +0800, Nick Hu wrote:
> > Add compatible string and property for the SiFive CLINT v2. The SiFive
> > CLINT v2 is incompatible with the SiFive CLINT v0 due to differences
> > in their control methods.
>
> Hello Nick,
>
> Can you help me understand what is this different control method? I've
> found that both OpenSBI [1] and U-Boot [2] use the same match data in their
> clint driver which would indicate that they are compatible.
Hmm, good point. I didn't see that the drivers were not doing anything
different. I guess really the clintv2 should fall back to the clintv0,
and the difference in hardware should be elaborated on.
I think I also dropped the ball on sifive,fine-ctr-bits, and that should
be removed and the counter width determined from the compatible.
There's no users for that yet I think, and there's no valid users of the
clintv2 compatible /at all/ so maybe it can just get culled.
>
> Also, do you know if there's an easy way to tell if a sifive clint is a v0
> or v2?
>
> Thanks,
> Charles
>
> [1]: https://elixir.bootlin.com/opensbi/v1.8.1/source/lib/utils/timer/fdt_timer_mtimer.c#L163
> [2]: https://elixir.bootlin.com/u-boot/v2026.01/source/drivers/timer/riscv_aclint_timer.c#L86
>
> >
> > Signed-off-by: Nick Hu <nick.hu@sifive.com>
> > Reviewed-by: Samuel Holland <samuel.holland@sifive.com>
> > ---
> > - v3 changes:
> > - Add the reason for the incompatibility between sifive,clint2 and
> > sifive,clint0.
> > - v2 changes:
> > - Don't allow sifive,clint2 by itself. Add '-{}' to the first entry
> > - Mark the sifive,fine-ctr-bits as the required property when
> > the compatible includes the sifive,clint2
> >
> > .../bindings/timer/sifive,clint.yaml | 22 +++++++++++++++++++
> > 1 file changed, 22 insertions(+)
> >
> > diff --git a/Documentation/devicetree/bindings/timer/sifive,clint.yaml b/Documentation/devicetree/bindings/timer/sifive,clint.yaml
> > index 76d83aea4e2b..34684cda8b15 100644
> > --- a/Documentation/devicetree/bindings/timer/sifive,clint.yaml
> > +++ b/Documentation/devicetree/bindings/timer/sifive,clint.yaml
> > @@ -36,6 +36,12 @@ properties:
> > - starfive,jh7110-clint # StarFive JH7110
> > - starfive,jh8100-clint # StarFive JH8100
> > - const: sifive,clint0 # SiFive CLINT v0 IP block
> > + - items:
> > + - {}
> > + - const: sifive,clint2 # SiFive CLINT v2 IP block
> > + description:
> > + SiFive CLINT v2 is the HRT that supports the Zicntr. The control of sifive,clint2
> > + differs from that of sifive,clint0, making them incompatible.
> > - items:
> > - enum:
> > - allwinner,sun20i-d1-clint
> > @@ -62,6 +68,22 @@ properties:
> > minItems: 1
> > maxItems: 4095
> >
> > + sifive,fine-ctr-bits:
> > + maximum: 15
> > + description: The width in bits of the fine counter.
> > +
> > +if:
> > + properties:
> > + compatible:
> > + contains:
> > + const: sifive,clint2
> > +then:
> > + required:
> > + - sifive,fine-ctr-bits
> > +else:
> > + properties:
> > + sifive,fine-ctr-bits: false
> > +
> > additionalProperties: false
> >
> > required:
> > --
> > 2.17.1
> >
> >
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
^ permalink raw reply
* Re: [PATCH v5 0/2] Add support for Texas Instruments INA4230 power monitor
From: Guenter Roeck @ 2026-03-30 16:07 UTC (permalink / raw)
To: Alexey Charkov, Rob Herring, Krzysztof Kozlowski, Conor Dooley
Cc: linux-hwmon, devicetree, linux-kernel, Krzysztof Kozlowski
In-Reply-To: <20260330-ina4230-v5-0-eeb322d95b3a@flipper.net>
On 3/30/26 08:14, Alexey Charkov wrote:
> TI INA4230 is a 4-channel power monitor with I2C interface, similar in
> operation to INA3221 (3-channel) and INA219 (single-channel) but with
> a different register layout, different alerting mechanism and slightly
> different support for directly reading calculated current/power/energy
> values (pre-multiplied by the device itself and needing only to be scaled
> by the driver depending on its selected LSB unit values).
>
> In this initial implementation, the driver supports reading voltage,
> current, power and energy values, but does not yet support alerts, which
> can be added separately if needed. Also the overflows during hardware
> calculations are not yet handled, nor is the support for the device's
> internal 32-bit energy counter reset.
>
> An example device tree using this binding and driver is available at [1]
> (not currently upstreamed, as the device in question is in engineering
> phase and not yet publicly available)
>
> [1] https://github.com/flipperdevices/flipper-linux-kernel/blob/flipper-devel/arch/arm64/boot/dts/rockchip/rk3576-flipper-one-rev-f0b0c1.dts
>
> Signed-off-by: Alexey Charkov <alchark@flipper.net>
> ---
> Changes in v5:
> - Reworded per-channel subnodes description in the binding for clarity (Sashiko)
> - NB: Sashiko's suggestion to allow interrupts in the binding sounds premature,
> as the alerts mechanism is not implemented yet and there are no known users
> to test it. If anyone has hardware with the alert pins wired to an interrupt
> line - please shout and we can test/extend it together
The bindings are supposed to be complete, even if not implemented, so I am not sure
if the DT maintainers will agree here. We'll see.
Thanks,
Guenter
^ permalink raw reply
* Re: [PATCH v9 0/5] Add support to read the watchdog bootstatus from IMEM
From: Kathiravan Thirumoorthy @ 2026-03-30 16:07 UTC (permalink / raw)
To: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Bjorn Andersson,
Konrad Dybcio, Wim Van Sebroeck, Guenter Roeck, Rajendra Nayak
Cc: linux-arm-msm, devicetree, linux-kernel, linux-watchdog,
Krzysztof Kozlowski, Dmitry Baryshkov, Konrad Dybcio
In-Reply-To: <7593d19b-c124-48fb-9c0f-af8177dab1ac@oss.qualcomm.com>
On 3/16/2026 2:36 PM, Kathiravan Thirumoorthy wrote:
>
> On 2/28/2026 5:58 PM, Kathiravan Thirumoorthy wrote:
>> In Qualcomm IPQ SoCs, if the system is rebooted due to the watchdog
>> timeout, there is no way to identify it. Current approach of checking
>> the EXPIRED_STATUS in WDT_STS is not working.
>>
>> To achieve this, if the system is rebooted due to watchdog timeout, the
>> information is captured in the IMEM by the bootloader (along with other
>> reason codes as well).
>>
>> This series attempts to address this by adding the support to read the
>> IMEM and populate the information via bootstatus sysfs file.
>>
>> With the CONFIG_WATCHDOG_SYSFS enabled, user can extract the information
>> as below:
>>
>> cat
>> /sys/devices/platform/soc@0/f410000.watchdog/watchdog/watchdog0/bootstatus
>>
>> 32
>>
>> Signed-off-by: Kathiravan Thirumoorthy
>> <kathiravan.thirumoorthy@oss.qualcomm.com>
>
> Gentle Reminder on this series. If there are no further comments, can
> this be picked up for v7.1?
Bjorn, Guenter, Wim — gentle ping. FWIW, this series applies cleanly to
the next-20260327 tag. Please let me know if any improvements are required.
^ permalink raw reply
* Re: [PATCH 2/7] cache: andes_llcache: refactor initialization and cache operations
From: Conor Dooley @ 2026-03-30 16:05 UTC (permalink / raw)
To: Hui Min Mina Chou
Cc: pjw, palmer, aou, alex, geert+renesas, prabhakar.mahadev-lad.rj,
magnus.damm, ben717, robh, krzk+dt, conor+dt, jonathan.cameron,
devicetree, linux-riscv, linux-kernel, linux-renesas-soc, tim609,
alex749, az70021
In-Reply-To: <20260330102724.1012470-3-minachou@andestech.com>
[-- Attachment #1: Type: text/plain, Size: 4492 bytes --]
On Mon, Mar 30, 2026 at 06:27:19PM +0800, Hui Min Mina Chou wrote:
> This patch cleans up the Andes LLC cache driver:
> - improved error handling in andes_cache_init() by using goto labels
I don't agree that this is an improvement. There's no meaningful
teardown shared.
> - updated andes_dma_cache_inv/wback() to check for !size instead of
> start == end
> - cache-line-size mismatch from an error to a warning
> - Use ALIGN and ALIGN_DOWN helpers instead of the alignment logic in
> andes_dma_cache_inv() and andes_dma_cache_wback().
>
> Signed-off-by: Hui Min Mina Chou <minachou@andestech.com>
> ---
> drivers/cache/andes_llcache.c | 56 ++++++++++++++++++-----------------
> 1 file changed, 29 insertions(+), 27 deletions(-)
>
> diff --git a/drivers/cache/andes_llcache.c b/drivers/cache/andes_llcache.c
> index d5e382f3c801..d318b8009f7f 100644
> --- a/drivers/cache/andes_llcache.c
> +++ b/drivers/cache/andes_llcache.c
> @@ -111,21 +111,17 @@ static void andes_dma_cache_inv(phys_addr_t paddr, size_t size)
> {
> unsigned long start = (unsigned long)phys_to_virt(paddr);
> unsigned long end = start + size;
> - unsigned long line_size;
> + unsigned long line_size = andes_priv.andes_cache_line_size;
> unsigned long flags;
>
> - if (unlikely(start == end))
> + if (unlikely(!size))
> return;
>
> - line_size = andes_priv.andes_cache_line_size;
> -
> - start = start & (~(line_size - 1));
> - end = ((end + line_size - 1) & (~(line_size - 1)));
> + start = ALIGN_DOWN(start, line_size);
> + end = ALIGN(end, line_size);
>
> local_irq_save(flags);
> -
> andes_cpu_dcache_inval_range(start, end);
> -
> local_irq_restore(flags);
> }
>
> @@ -133,15 +129,15 @@ static void andes_dma_cache_wback(phys_addr_t paddr, size_t size)
> {
> unsigned long start = (unsigned long)phys_to_virt(paddr);
> unsigned long end = start + size;
> - unsigned long line_size;
> + unsigned long line_size = andes_priv.andes_cache_line_size;
> unsigned long flags;
>
> - if (unlikely(start == end))
> + if (unlikely(!size))
> return;
>
> - line_size = andes_priv.andes_cache_line_size;
> - start = start & (~(line_size - 1));
> - end = ((end + line_size - 1) & (~(line_size - 1)));
> + start = ALIGN_DOWN(start, line_size);
> + end = ALIGN(end, line_size);
> +
> local_irq_save(flags);
> andes_cpu_dcache_wb_range(start, end);
> local_irq_restore(flags);
> @@ -159,14 +155,13 @@ static int andes_get_llc_line_size(struct device_node *np)
>
> ret = of_property_read_u32(np, "cache-line-size", &andes_priv.andes_cache_line_size);
> if (ret) {
> - pr_err("Failed to get cache-line-size, defaulting to 64 bytes\n");
> + pr_err("Cache: Failed to get cache-line-size\n");
> return ret;
> }
>
> if (andes_priv.andes_cache_line_size != ANDES_CACHE_LINE_SIZE) {
> - pr_err("Expected cache-line-size to be 64 bytes (found:%u)\n",
> - andes_priv.andes_cache_line_size);
> - return -EINVAL;
> + pr_warn("Cache: Expected cache-line-size to be 64 bytes (found:%u)\n",
> + andes_priv.andes_cache_line_size);
> }
>
> return 0;
> @@ -186,16 +181,18 @@ static const struct of_device_id andes_cache_ids[] = {
> static int __init andes_cache_init(void)
> {
> struct resource res;
> - int ret;
> + int ret = 0;
>
> struct device_node *np __free(device_node) =
> of_find_matching_node(NULL, andes_cache_ids);
> - if (!of_device_is_available(np))
> - return -ENODEV;
> + if (!of_device_is_available(np)) {
> + ret = -ENODEV;
> + goto err_ret;
> + }
>
> ret = of_address_to_resource(np, 0, &res);
> if (ret)
> - return ret;
> + goto err_ret;
>
> /*
> * If IOCP is present on the Andes AX45MP core riscv_cbom_block_size
> @@ -208,17 +205,22 @@ static int __init andes_cache_init(void)
> return 0;
>
> andes_priv.llc_base = ioremap(res.start, resource_size(&res));
> - if (!andes_priv.llc_base)
> - return -ENOMEM;
> + if (!andes_priv.llc_base) {
> + ret = -ENOMEM;
> + goto err_ret;
> + }
>
> ret = andes_get_llc_line_size(np);
> - if (ret) {
> - iounmap(andes_priv.llc_base);
> - return ret;
> - }
> + if (ret)
> + goto err_unmap;
>
> riscv_noncoherent_register_cache_ops(&andes_cmo_ops);
>
> return 0;
> +
> +err_unmap:
> + iounmap(andes_priv.llc_base);
> +err_ret:
> + return ret;
> }
> early_initcall(andes_cache_init);
> --
> 2.34.1
>
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
^ permalink raw reply
* Re: [PATCH 3/7] cache: andes_llcache: improve performance of LLC operation
From: Conor Dooley @ 2026-03-30 16:04 UTC (permalink / raw)
To: Hui Min Mina Chou
Cc: pjw, palmer, aou, alex, geert+renesas, prabhakar.mahadev-lad.rj,
magnus.damm, ben717, robh, krzk+dt, conor+dt, jonathan.cameron,
devicetree, linux-riscv, linux-kernel, linux-renesas-soc, tim609,
alex749, az70021, Leo Yu-Chi Liang
In-Reply-To: <20260330102724.1012470-4-minachou@andestech.com>
[-- Attachment #1: Type: text/plain, Size: 3879 bytes --]
On Mon, Mar 30, 2026 at 06:27:20PM +0800, Hui Min Mina Chou wrote:
> Eliminate get_cpu() on !CONFIG_SMP and switch readl/writel to their
Where is the get_cpu() that you're talking about eliminating here?
> relaxed variants to remove unnecessary fence instructions on I/O
> memory access. The platform specification defines all I/O regions are
> on channel 0 (point-to-point strongly ordered), so explicit fences are
> not required [1][2][3]. Explicit memory barriers (mb) are added before
> and after the CCTL loop to ensure overall memory consistency.
>
> Also fix hart ID mapping by switching to cpuid_to_hartid_map() instead
> of using the logical CPU ID directly. In AMP setups (e.g. Linux on
> Hart 1, RTOS on Hart 0), Linux sees itself as CPU 0 but must access
> Hart 1's CCTL registers, so using the logical ID would cause accidental
> interference with other cores.
This seems like it should be a separate fix for sure.
>
> [1] platform spec 2.1.1: https://github.com/riscvarchive/riscv-platform-specs/blob/main/riscv-platform-spec.adoc?plain=1#L169
> [2] privileged spec 3.6.5: https://github.com/riscv/riscv-isa-manual/blob/main/src/machine.adoc?plain=1#L2835
> [3] riscv: asm/mmio.h: https://gitea.andestech.com/RD-SW/linux/src/branch/ast-v5_4_0-branch/arch/riscv/include/asm/mmio.h#L105
>
> Signed-off-by: Leo Yu-Chi Liang <ycliang@andestech.com>
> Signed-off-by: Hui Min Mina Chou <minachou@andestech.com>
> ---
> drivers/cache/andes_llcache.c | 18 ++++++++++++++----
> 1 file changed, 14 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/cache/andes_llcache.c b/drivers/cache/andes_llcache.c
> index d318b8009f7f..57f666bc537a 100644
> --- a/drivers/cache/andes_llcache.c
> +++ b/drivers/cache/andes_llcache.c
> @@ -66,7 +66,7 @@ static struct andes_priv andes_priv;
> /* LLC operations */
> static inline uint32_t andes_cpu_llc_get_cctl_status(void)
> {
> - return readl(andes_priv.llc_base + ANDES_LLC_REG_CCTL_STATUS_OFFSET_C0);
> + return readl_relaxed(andes_priv.llc_base + ANDES_LLC_REG_CCTL_STATUS_OFFSET_C0);
> }
>
> static void andes_cpu_cache_operation(unsigned long start, unsigned long end,
> @@ -74,16 +74,22 @@ static void andes_cpu_cache_operation(unsigned long start, unsigned long end,
> {
> unsigned long line_size = andes_priv.andes_cache_line_size;
> void __iomem *base = andes_priv.llc_base;
> - int mhartid = smp_processor_id();
> unsigned long pa;
> + int mhartid = 0;
>
> + if (IS_ENABLED(CONFIG_SMP))
> + mhartid = cpuid_to_hartid_map(get_cpu());
But I dunno why this dance is required. Can't you just retain the call
to smp_processor_id() and pass the result unconditionally to
cpuid_to_hartid_map()? Or just make it a oneliner with
cpuid_to_hartid_map(smp_processor_id())?
> + else
> + mhartid = cpuid_to_hartid_map(0);
> +
> + mb(); /* complete earlier memory accesses before the cache flush */
> while (end > start) {
> csr_write(CSR_UCCTLBEGINADDR, start);
> csr_write(CSR_UCCTLCOMMAND, l1_op);
>
> pa = virt_to_phys((void *)start);
> - writel(pa, base + ANDES_LLC_REG_CCTL_ACC_OFFSET_BY_CORE(mhartid));
> - writel(llc_op, base + ANDES_LLC_REG_CCTL_CMD_OFFSET_BY_CORE(mhartid));
> + writel_relaxed(pa, base + ANDES_LLC_REG_CCTL_ACC_OFFSET_BY_CORE(mhartid));
> + writel_relaxed(llc_op, base + ANDES_LLC_REG_CCTL_CMD_OFFSET_BY_CORE(mhartid));
> while ((andes_cpu_llc_get_cctl_status() &
> ANDES_LLC_CCTL_STATUS_MASK_BY_CORE(mhartid)) !=
> ANDES_LLC_CCTL_STATUS_IDLE)
> @@ -91,6 +97,10 @@ static void andes_cpu_cache_operation(unsigned long start, unsigned long end,
>
> start += line_size;
> }
> + mb(); /* issue later memory accesses after the cache flush */
> +
> + if (IS_ENABLED(CONFIG_SMP))
> + put_cpu();
> }
>
> /* Write-back L1 and LLC entry */
> --
> 2.34.1
>
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
^ permalink raw reply
* Re: [PATCH V2 5/5] dmaengine: xilinx_dma: Add support for reporting transfer size to AXI DMA / MCDMA client when app fields are unavailable
From: Frank Li @ 2026-03-30 16:04 UTC (permalink / raw)
To: Srinivas Neeli
Cc: Vinod Koul, git, Frank Li, Michal Simek, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Suraj Gupta,
Radhey Shyam Pandey, Thomas Gessler, Folker Schwesinger,
Tomi Valkeinen, Kees Cook, Abin Joseph, dmaengine, devicetree,
linux-arm-kernel, linux-kernel
In-Reply-To: <20260313062533.421249-6-srinivas.neeli@amd.com>
On Fri, Mar 13, 2026 at 11:55:33AM +0530, Srinivas Neeli wrote:
> From: Suraj Gupta <suraj.gupta2@amd.com>
>
> The AXI4-stream status and control interface is optional in the AXI DMA /
> MCDMA IP design; when it is not present, app fields are not available in
> DMA descriptor. In such cases, the transferred byte count can be
> communicated to the client using the status field (bits 0-25) of
> AXI DMA / MCDMA descriptor.
>
> Add a xferred_bytes field to struct xilinx_dma_tx_descriptor to record the
> number of bytes transferred for each transaction. The value is calculated
> using the existing xilinx_dma_get_residue() function, which traverses all
> hardware descriptors associated with the async transaction descriptor,
> avoiding redundant traversal.
Can you split this change to new patch?
Frank
>
> The driver uses the xlnx,include-stscntrl-strm device tree property to
> determine if the status/control stream interface is present and selects the
> appropriate metadata source accordingly.
>
> Signed-off-by: Suraj Gupta <suraj.gupta2@amd.com>
> ---
> drivers/dma/xilinx/xilinx_dma.c | 28 ++++++++++++++++++++++++----
> 1 file changed, 24 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/dma/xilinx/xilinx_dma.c b/drivers/dma/xilinx/xilinx_dma.c
> index 52203d44e7a4..f5ef03a1297c 100644
> --- a/drivers/dma/xilinx/xilinx_dma.c
> +++ b/drivers/dma/xilinx/xilinx_dma.c
> @@ -380,6 +380,8 @@ struct xilinx_cdma_tx_segment {
> * @cyclic: Check for cyclic transfers.
> * @err: Whether the descriptor has an error.
> * @residue: Residue of the completed descriptor
> + * @xferred_bytes: Number of bytes transferred by this transaction
> + * descriptor.
> */
> struct xilinx_dma_tx_descriptor {
> struct xilinx_dma_chan *chan;
> @@ -389,6 +391,7 @@ struct xilinx_dma_tx_descriptor {
> bool cyclic;
> bool err;
> u32 residue;
> + u32 xferred_bytes;
> };
>
> /**
> @@ -515,6 +518,7 @@ struct xilinx_dma_config {
> * @mm2s_chan_id: DMA mm2s channel identifier
> * @max_buffer_len: Max buffer length
> * @has_axistream_connected: AXI DMA connected to AXI Stream IP
> + * @has_stsctrl_stream: AXI4-stream status and control interface is enabled
> */
> struct xilinx_dma_device {
> void __iomem *regs;
> @@ -534,6 +538,7 @@ struct xilinx_dma_device {
> u32 mm2s_chan_id;
> u32 max_buffer_len;
> bool has_axistream_connected;
> + bool has_stsctrl_stream;
> };
>
> /* Macros */
> @@ -672,8 +677,12 @@ static void *xilinx_dma_get_metadata_ptr(struct dma_async_tx_descriptor *tx,
> struct xilinx_axidma_tx_segment, node);
> metadata_ptr = seg->hw.app;
> }
> - *max_len = *payload_len = sizeof(u32) * XILINX_DMA_NUM_APP_WORDS;
> - return metadata_ptr;
> + if (desc->chan->xdev->has_stsctrl_stream) {
> + *max_len = *payload_len = sizeof(u32) * XILINX_DMA_NUM_APP_WORDS;
> + return metadata_ptr;
> + }
> + *max_len = *payload_len = sizeof(desc->xferred_bytes);
> + return (void *)&desc->xferred_bytes;
> }
>
> static struct dma_descriptor_metadata_ops xilinx_dma_metadata_ops = {
> @@ -864,6 +873,7 @@ xilinx_dma_alloc_tx_descriptor(struct xilinx_dma_chan *chan)
> return NULL;
>
> desc->chan = chan;
> + desc->xferred_bytes = 0;
> INIT_LIST_HEAD(&desc->segments);
>
> return desc;
> @@ -1014,6 +1024,7 @@ static u32 xilinx_dma_get_residue(struct xilinx_dma_chan *chan,
> struct xilinx_aximcdma_desc_hw *aximcdma_hw;
> struct list_head *entry;
> u32 residue = 0;
> + u32 xferred = 0;
>
> list_for_each(entry, &desc->segments) {
> if (chan->xdev->dma_config->dmatype == XDMA_TYPE_CDMA) {
> @@ -1031,25 +1042,32 @@ static u32 xilinx_dma_get_residue(struct xilinx_dma_chan *chan,
> axidma_hw = &axidma_seg->hw;
> residue += (axidma_hw->control - axidma_hw->status) &
> chan->xdev->max_buffer_len;
> + xferred += axidma_hw->status & chan->xdev->max_buffer_len;
> } else {
> aximcdma_seg =
> list_entry(entry,
> struct xilinx_aximcdma_tx_segment,
> node);
> aximcdma_hw = &aximcdma_seg->hw;
> - if (chan->direction == DMA_DEV_TO_MEM)
> + if (chan->direction == DMA_DEV_TO_MEM) {
> residue +=
> (aximcdma_hw->control -
> aximcdma_hw->s2mm_status) &
> chan->xdev->max_buffer_len;
> - else
> + xferred += aximcdma_hw->s2mm_status &
> + chan->xdev->max_buffer_len;
> + } else {
> residue +=
> (aximcdma_hw->control -
> aximcdma_hw->mm2s_status) &
> chan->xdev->max_buffer_len;
> + xferred += aximcdma_hw->mm2s_status &
> + chan->xdev->max_buffer_len;
> + }
> }
> }
>
> + desc->xferred_bytes = xferred;
> return residue;
> }
>
> @@ -3284,6 +3302,8 @@ static int xilinx_dma_probe(struct platform_device *pdev)
> xdev->dma_config->dmatype == XDMA_TYPE_AXIMCDMA) {
> xdev->has_axistream_connected =
> of_property_read_bool(node, "xlnx,axistream-connected");
> + xdev->has_stsctrl_stream =
> + of_property_read_bool(node, "xlnx,include-stscntrl-strm");
> }
>
> if (xdev->dma_config->dmatype == XDMA_TYPE_VDMA) {
> --
> 2.43.0
>
^ permalink raw reply
* Re: (subset) [PATCH v2 1/1] arm64: dts: qcom: hamoa: Fix incomplete Root Port property migration
From: Bjorn Andersson @ 2026-03-30 16:01 UTC (permalink / raw)
To: konradybcio, robh, krzk+dt, conor+dt, jingoohan1, mani,
lpieralisi, kwilczynski, bhelgaas, johan+linaro, vkoul, kishon,
neil.armstrong, Abel Vesa, Ziyue Zhang
Cc: linux-arm-msm, devicetree, linux-kernel, linux-pci, linux-phy,
qiang.yu, quic_krichai, quic_vbadigan
In-Reply-To: <20260330020934.3501247-1-ziyue.zhang@oss.qualcomm.com>
On Mon, 30 Mar 2026 10:09:34 +0800, Ziyue Zhang wrote:
> Historically, the Qualcomm PCIe controller node (Host bridge) described
> all Root Port properties, such as PHY, PERST#, and WAKE#. But to provide
> a more accurate hardware description and to support future multi-Root Port
> controllers, these properties were moved to the Root Port node in the
> devicetree bindings.
>
> Commit 960609b22be5 ("arm64: dts: qcom: hamoa: Move PHY, PERST, and Wake
> GPIOs to PCIe port nodes and add port Nodes for all PCIe ports")
> initiated this transition for the Hamoa platform by moving the PHY
> property to the Root Port node in hamoa.dtsi. However, it only updated
> some platform specific DTS files for PERST# and WAKE#, leaving others in
> a "mixed" binding state.
>
> [...]
Applied, thanks!
[1/1] arm64: dts: qcom: hamoa: Fix incomplete Root Port property migration
commit: 11b72b1ca9891c77bc876ef9fc39d6825847ffee
Best regards,
--
Bjorn Andersson <andersson@kernel.org>
^ permalink raw reply
* Re: [PATCH] arm64: dts: qcom: msm8939-asus-z00t: add regulators for ambient light and proximity sensor
From: Bjorn Andersson @ 2026-03-30 16:01 UTC (permalink / raw)
To: Konrad Dybcio, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Erikas Bitovtas
Cc: linux-arm-msm, devicetree, linux-kernel,
~postmarketos/upstreaming, phone-devel
In-Reply-To: <20260330-z00t-cm36686-regulators-v1-1-03e23b03bd70@gmail.com>
On Mon, 30 Mar 2026 02:37:57 +0300, Erikas Bitovtas wrote:
> VCNL4000 includes support for regulators. Add regulators listed in the
> downstream device tree so they can be powered in during initialization.
> VLED supply is missing downstream, so it will be powered on by a dummy.
>
>
Applied, thanks!
[1/1] arm64: dts: qcom: msm8939-asus-z00t: add regulators for ambient light and proximity sensor
commit: f757451504c4eaa77b3f87fdbed7a11d1f80df29
Best regards,
--
Bjorn Andersson <andersson@kernel.org>
^ permalink raw reply
* Re: [PATCH 0/3] arm64: dts: qcom: msm8916-samsung-coreprimeltevzw: add device tree
From: Bjorn Andersson @ 2026-03-30 16:01 UTC (permalink / raw)
To: linux-kernel, Raymond Hackley
Cc: Konrad Dybcio, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
linux-arm-msm, devicetree, phone-devel, Max McNamee,
Stephan Gerhold, Nikita Travkin, ~postmarketos/upstreaming
In-Reply-To: <20260223220514.2556033-1-wonderfulshrinemaidenofparadise@postmarketos.org>
On Mon, 23 Feb 2026 22:05:11 +0000, Raymond Hackley wrote:
> Samsung Galaxy Core Prime Verizon Wireless is a phone based on MSM8916.
> They are similar to the other Samsung devices based on MSM8916 with only a
> few minor differences.
>
> The device trees contain initial support with:
> - GPIO keys
> - Regulator haptic
> - SDHCI (internal and external storage)
> - USB Device Mode
> - UART (on USB connector via the SM5502 MUIC)
> - WCNSS (WiFi/BT)
> - Regulators
> - QDSP6 audio
> - Speaker/earpiece/headphones/microphones via digital/analog codec in
> MSM8916/PM8916
> - WWAN Internet via BAM-DMUX
> - PMIC and charger
> - Touchscreen
>
> [...]
Applied, thanks!
[1/3] arm64: dts: qcom: msm8916-samsung-fortuna: Move SM5504 from rossa and refactor MUIC
commit: 21450547506ece7e36bef75681479a52e518c53b
[2/3] dt-bindings: qcom: Document samsung,coreprimeltevzw
commit: bb0a09a4fa4821a5a1da1b707e0e169d6a4e8cd2
[3/3] arm64: dts: qcom: msm8916-samsung-coreprimeltevzw: add device tree
commit: 2ce450f77f1de5eb7b489fcd829a7f494952e1bf
Best regards,
--
Bjorn Andersson <andersson@kernel.org>
^ 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