* Re: [PATCH 1/2] drm/rockchip: dsi: Add maximum per lane bit rate calculation
From: Chaoyi Chen @ 2026-05-12 1:07 UTC (permalink / raw)
To: Heiko Stübner
Cc: Chaoyi Chen, Sandy Huang, Andy Yan, Maarten Lankhorst,
Maxime Ripard, Thomas Zimmermann, David Airlie, Simona Vetter,
Guochun Huang, dri-devel, linux-arm-kernel, linux-rockchip,
linux-kernel
In-Reply-To: <20260324085838.90-1-kernel@airkyi.com>
Hi,
On 3/24/2026 4:58 PM, Chaoyi Chen wrote:
> From: Chaoyi Chen <chaoyi.chen@rock-chips.com>
>
> Different chips have varying support for the maximum bit rate per lane.
>
> Add calculation for the maximum per lane bit rate for various chip
> platforms, and relax the bandwidth margin requirements.
>
> Signed-off-by: Chaoyi Chen <chaoyi.chen@rock-chips.com>
> ---
> .../gpu/drm/rockchip/dw-mipi-dsi-rockchip.c | 21 +++++++++++++++----
> 1 file changed, 17 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/gpu/drm/rockchip/dw-mipi-dsi-rockchip.c b/drivers/gpu/drm/rockchip/dw-mipi-dsi-rockchip.c
> index 3547d91b25d3..d3bacfae174e 100644
> --- a/drivers/gpu/drm/rockchip/dw-mipi-dsi-rockchip.c
> +++ b/drivers/gpu/drm/rockchip/dw-mipi-dsi-rockchip.c
> @@ -268,6 +268,7 @@ struct rockchip_dw_dsi_chip_data {
>
> unsigned int flags;
> unsigned int max_data_lanes;
> + unsigned long max_bit_rate_per_lane;
> };
>
> struct dw_mipi_dsi_rockchip {
> @@ -565,7 +566,7 @@ dw_mipi_dsi_get_lane_mbps(void *priv_data, const struct drm_display_mode *mode,
> int bpp;
> unsigned long mpclk, tmp;
> unsigned int target_mbps = 1000;
> - unsigned int max_mbps = dppa_map[ARRAY_SIZE(dppa_map) - 1].max_mbps;
> + unsigned int max_mbps;
> unsigned long best_freq = 0;
> unsigned long fvco_min, fvco_max, fin, fout;
> unsigned int min_prediv, max_prediv;
> @@ -573,6 +574,7 @@ dw_mipi_dsi_get_lane_mbps(void *priv_data, const struct drm_display_mode *mode,
> unsigned long _fbdiv, best_fbdiv;
> unsigned long min_delta = ULONG_MAX;
>
> + max_mbps = dsi->cdata->max_bit_rate_per_lane;
> dsi->format = format;
> bpp = mipi_dsi_pixel_format_to_bpp(dsi->format);
> if (bpp < 0) {
> @@ -584,8 +586,8 @@ dw_mipi_dsi_get_lane_mbps(void *priv_data, const struct drm_display_mode *mode,
>
> mpclk = DIV_ROUND_UP(mode->clock, MSEC_PER_SEC);
> if (mpclk) {
> - /* take 1 / 0.8, since mbps must big than bandwidth of RGB */
> - tmp = mpclk * (bpp / lanes) * 10 / 8;
> + /* take 1 / 0.9, since mbps must big than bandwidth of RGB */
> + tmp = mpclk * (bpp / lanes) * 10 / 9;
> if (tmp < max_mbps)
> target_mbps = tmp;
> else
> @@ -595,7 +597,7 @@ dw_mipi_dsi_get_lane_mbps(void *priv_data, const struct drm_display_mode *mode,
>
> /* for external phy only a the mipi_dphy_config is necessary */
> if (dsi->phy) {
> - phy_mipi_dphy_get_default_config(mode->clock * 1000 * 10 / 8,
> + phy_mipi_dphy_get_default_config(mode->clock * 1000 * 10 / 9,
> bpp, lanes,
> &dsi->phy_opts.mipi_dphy);
> dsi->lane_mbps = target_mbps;
> @@ -1503,6 +1505,7 @@ static const struct rockchip_dw_dsi_chip_data px30_chip_data[] = {
> PX30_DSI_FORCETXSTOPMODE), 0),
>
> .max_data_lanes = 4,
> + .max_bit_rate_per_lane = 1000000000UL,
> },
> { /* sentinel */ }
> };
> @@ -1515,6 +1518,7 @@ static const struct rockchip_dw_dsi_chip_data rk3128_chip_data[] = {
> RK3128_DSI_FORCERXMODE |
> RK3128_DSI_FORCETXSTOPMODE), 0),
> .max_data_lanes = 4,
> + .max_bit_rate_per_lane = 1000000000UL,
> },
> { /* sentinel */ }
> };
> @@ -1527,6 +1531,7 @@ static const struct rockchip_dw_dsi_chip_data rk3288_chip_data[] = {
> .lcdsel_lit = FIELD_PREP_WM16_CONST(RK3288_DSI0_LCDC_SEL, 1),
>
> .max_data_lanes = 4,
> + .max_bit_rate_per_lane = 1500000000UL,
> },
> {
> .reg = 0xff964000,
> @@ -1535,6 +1540,7 @@ static const struct rockchip_dw_dsi_chip_data rk3288_chip_data[] = {
> .lcdsel_lit = FIELD_PREP_WM16_CONST(RK3288_DSI1_LCDC_SEL, 1),
>
> .max_data_lanes = 4,
> + .max_bit_rate_per_lane = 1500000000UL,
> },
> { /* sentinel */ }
> };
> @@ -1547,6 +1553,7 @@ static const struct rockchip_dw_dsi_chip_data rk3368_chip_data[] = {
> RK3368_DSI_FORCETXSTOPMODE |
> RK3368_DSI_FORCERXMODE), 0),
> .max_data_lanes = 4,
> + .max_bit_rate_per_lane = 1500000000UL,
> },
> { /* sentinel */ }
> };
> @@ -1634,6 +1641,7 @@ static const struct rockchip_dw_dsi_chip_data rk3399_chip_data[] = {
>
> .flags = DW_MIPI_NEEDS_PHY_CFG_CLK | DW_MIPI_NEEDS_GRF_CLK,
> .max_data_lanes = 4,
> + .max_bit_rate_per_lane = 1500000000UL,
> },
> {
> .reg = 0xff968000,
> @@ -1658,6 +1666,7 @@ static const struct rockchip_dw_dsi_chip_data rk3399_chip_data[] = {
>
> .flags = DW_MIPI_NEEDS_PHY_CFG_CLK | DW_MIPI_NEEDS_GRF_CLK,
> .max_data_lanes = 4,
> + .max_bit_rate_per_lane = 1500000000UL,
>
> .dphy_rx_init = rk3399_dphy_tx1rx1_init,
> .dphy_rx_power_on = rk3399_dphy_tx1rx1_power_on,
> @@ -1674,6 +1683,7 @@ static const struct rockchip_dw_dsi_chip_data rk3506_chip_data[] = {
> FIELD_PREP_WM16_CONST(RK3506_DSI_FORCERXMODE, 0) |
> FIELD_PREP_WM16_CONST(RK3506_DSI_FORCETXSTOPMODE, 0)),
> .max_data_lanes = 2,
> + .max_bit_rate_per_lane = 1500000000UL,
> },
> { /* sentinel */ }
> };
> @@ -1687,6 +1697,7 @@ static const struct rockchip_dw_dsi_chip_data rk3568_chip_data[] = {
> FIELD_PREP_WM16_CONST(RK3568_DSI0_TURNDISABLE, 0) |
> FIELD_PREP_WM16_CONST(RK3568_DSI0_FORCERXMODE, 0)),
> .max_data_lanes = 4,
> + .max_bit_rate_per_lane = 1200000000UL,
> },
> {
> .reg = 0xfe070000,
> @@ -1696,6 +1707,7 @@ static const struct rockchip_dw_dsi_chip_data rk3568_chip_data[] = {
> FIELD_PREP_WM16_CONST(RK3568_DSI1_TURNDISABLE, 0) |
> FIELD_PREP_WM16_CONST(RK3568_DSI1_FORCERXMODE, 0)),
> .max_data_lanes = 4,
> + .max_bit_rate_per_lane = 1200000000UL,
> },
> { /* sentinel */ }
> };
> @@ -1708,6 +1720,7 @@ static const struct rockchip_dw_dsi_chip_data rv1126_chip_data[] = {
> FIELD_PREP_WM16_CONST(RV1126_DSI_FORCERXMODE, 0) |
> FIELD_PREP_WM16_CONST(RV1126_DSI_FORCETXSTOPMODE, 0)),
> .max_data_lanes = 4,
> + .max_bit_rate_per_lane = 1000000000UL,
> },
> { /* sentinel */ }
> };
Gentle ping about this.
Thanks!
--
Best,
Chaoyi
^ permalink raw reply
* Re: [PATCH v3] coresight: fix missing error code when trace ID is invalid
From: Jie Gan @ 2026-05-12 0:54 UTC (permalink / raw)
To: Leo Yan
Cc: Richard Cheng, Suzuki K Poulose, Mike Leach, James Clark,
Alexander Shishkin, Tingwei Zhang, coresight, linux-arm-kernel,
linux-kernel
In-Reply-To: <20260511144556.GA34802@e132581.arm.com>
On 5/11/2026 10:45 PM, Leo Yan wrote:
> On Mon, May 11, 2026 at 05:27:10PM +0800, Jie Gan wrote:
>
> [...]
>
>>>> @@ -755,10 +755,16 @@ void coresight_path_assign_trace_id(struct coresight_path *path,
>>>> * Non 0 is either success or fail.
>>>> */
>>>> if (trace_id != 0) {
>>>> - path->trace_id = trace_id;
>>>> - return;
>>>> + if (IS_VALID_CS_TRACE_ID(trace_id)) {
>>>> + path->trace_id = trace_id;
>>>> + return 0;
>>>> + }
>>>> +
>>>> + return -EINVAL;
>
> I'd advocate a bit early exit style, like:
>
> /* 0 means the device has no ID assignment, so keep searching */
> if (trace_id == 0)
> continue;
>
> if (!IS_VALID_CS_TRACE_ID(trace_id))
> return -EINVAL;
>
> path->trace_id = trace_id;
> return 0;
>
> Early exit can reduce indentation depth, and it handles simple cases
> first and then the complex logic. In some cases (maye not this case),
> we may benefit a bit from compiler optimization [1].
>
Thanks, that's a good suggestion and much simpler than my solution.
> [1] https://xania.org/202512/18-partial-inlining
>
> [...]
>
>> The return value has been ignored in perf mode. It will introduce noisy by
>> adding __must_check. So I think its better without __must_check?
>
> Wouldn't it need to update perf mode as well?
I will also update the perf mode for consistent usage.
Thanks,
Jie
>
> Regarding __must_check, I searched Documentation but didn't find
> guidance on when it should be used. I don't want to use this annotation
> randomly (some functions use it and some not), this will be hard for
> everyone to follow up.
>
> IMO, it's fine not to use __must_check here. I would leave this to
> Suzuki and other maintainers if have different opinions.
>
> Thanks,
> Leo
^ permalink raw reply
* Re: [PATCH v19 0/7] ring-buffer: Making persistent ring buffers robust
From: Masami Hiramatsu @ 2026-05-12 0:54 UTC (permalink / raw)
To: Steven Rostedt
Cc: Catalin Marinas, Will Deacon, Mathieu Desnoyers, linux-kernel,
linux-trace-kernel, Ian Rogers, linux-arm-kernel
In-Reply-To: <20260511122943.41e204bc@gandalf.local.home>
On Mon, 11 May 2026 12:29:43 -0400
Steven Rostedt <rostedt@kernel.org> wrote:
> On Thu, 7 May 2026 13:14:16 +0900
> Masami Hiramatsu (Google) <mhiramat@kernel.org> wrote:
>
> > > I'll test this some more, and make a proper patch.
> >
> > Ah, indeed. Thanks for fixing!
> >
> > BTW, shouldn't we unify common logic of those functions?
>
> Hmm, there's not much common between the two. One is a consuming read and
> the other is a non-consuming read that needs to test for a bunch of race
> conditions.
>
> If you see something that can be shared, I'm all for it.
Maybe we can introduce a common inline function to calculate
max_loop, or at least replacing "3" with a common macro.
Thank you,
>
> -- Steve
--
Masami Hiramatsu (Google) <mhiramat@kernel.org>
^ permalink raw reply
* Re: [PATCH v3 4/7] PCI: dwc: Use common pci_host_common_link_train_delay() helper
From: Hans Zhang @ 2026-05-12 0:43 UTC (permalink / raw)
To: Krzysztof Wilczyński
Cc: bhelgaas, lpieralisi, mani, vigneshr, jingoohan1,
thomas.petazzoni, pali, ryder.lee, claudiu.beznea.uj, mpillai,
robh, s-vadapalli, linux-omap, linux-arm-kernel, claudiu.beznea,
linux-mediatek, linux-renesas-soc, linux-pci, linux-kernel
In-Reply-To: <20260511070139.GA1096586@rocinante>
On 5/11/26 15:02, Krzysztof Wilczyński wrote:
> Hello,
>
>> - /*
>> - * As per PCIe r6.0, sec 6.6.1, a Downstream Port that supports Link
>> - * speeds greater than 5.0 GT/s, software must wait a minimum of 100 ms
>> - * after Link training completes before sending a Configuration Request.
>> - */
>> - if (pci->max_link_speed > 2)
>> - msleep(PCIE_RESET_CONFIG_WAIT_MS);
>> + pci_host_common_link_train_delay(pci->max_link_speed);
>
> This comment could move to the helper you added.
Hi Krzysztof,
Will add.
Best regards,
Hans
>
> Thank you!
>
> Krzysztof
^ permalink raw reply
* [PATCH 8/8] arm64: dts: qcom: kaanapali-qrd: Enable GPU
From: Akhil P Oommen @ 2026-05-11 22:23 UTC (permalink / raw)
To: Will Deacon, Robin Murphy, Joerg Roedel, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Bjorn Andersson, Konrad Dybcio,
Rob Clark, Dmitry Baryshkov, Abhinav Kumar, Jessica Zhang,
Marijn Suijten, Maarten Lankhorst, Maxime Ripard,
Thomas Zimmermann, David Airlie, Simona Vetter
Cc: Sean Paul, linux-arm-kernel, iommu, devicetree, linux-kernel,
linux-arm-msm, freedreno, dri-devel, Akhil P Oommen
In-Reply-To: <20260512-kaana-gpu-dt-v1-0-13e1c07c2050@oss.qualcomm.com>
Add the secure firmware name property and enable GPU support on
Kaanapali QRD device.
Signed-off-by: Akhil P Oommen <akhilpo@oss.qualcomm.com>
---
arch/arm64/boot/dts/qcom/kaanapali-qrd.dts | 8 ++++++++
1 file changed, 8 insertions(+)
diff --git a/arch/arm64/boot/dts/qcom/kaanapali-qrd.dts b/arch/arm64/boot/dts/qcom/kaanapali-qrd.dts
index 55d02219ef4e..6bef8ec151f8 100644
--- a/arch/arm64/boot/dts/qcom/kaanapali-qrd.dts
+++ b/arch/arm64/boot/dts/qcom/kaanapali-qrd.dts
@@ -693,6 +693,14 @@ vreg_l7n_3p3: ldo7 {
};
};
+&gpu {
+ status = "okay";
+};
+
+&gpu_zap_shader {
+ firmware-name = "qcom/kaanapali/gen80200_zap.mbn";
+};
+
&pmh0101_flash {
status = "okay";
--
2.51.0
^ permalink raw reply related
* [PATCH 7/8] arm64: dts: qcom: kaanapali-mtp: Enable GPU
From: Akhil P Oommen @ 2026-05-11 22:23 UTC (permalink / raw)
To: Will Deacon, Robin Murphy, Joerg Roedel, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Bjorn Andersson, Konrad Dybcio,
Rob Clark, Dmitry Baryshkov, Abhinav Kumar, Jessica Zhang,
Marijn Suijten, Maarten Lankhorst, Maxime Ripard,
Thomas Zimmermann, David Airlie, Simona Vetter
Cc: Sean Paul, linux-arm-kernel, iommu, devicetree, linux-kernel,
linux-arm-msm, freedreno, dri-devel, Akhil P Oommen
In-Reply-To: <20260512-kaana-gpu-dt-v1-0-13e1c07c2050@oss.qualcomm.com>
Add the secure firmware name property and enable GPU support on
Kaanapali MTP device.
Signed-off-by: Akhil P Oommen <akhilpo@oss.qualcomm.com>
---
arch/arm64/boot/dts/qcom/kaanapali-mtp.dts | 8 ++++++++
1 file changed, 8 insertions(+)
diff --git a/arch/arm64/boot/dts/qcom/kaanapali-mtp.dts b/arch/arm64/boot/dts/qcom/kaanapali-mtp.dts
index f9b5b5718b90..ba256039dd3c 100644
--- a/arch/arm64/boot/dts/qcom/kaanapali-mtp.dts
+++ b/arch/arm64/boot/dts/qcom/kaanapali-mtp.dts
@@ -865,6 +865,14 @@ vreg_l7n_3p3: ldo7 {
};
};
+&gpu {
+ status = "okay";
+};
+
+&gpu_zap_shader {
+ firmware-name = "qcom/kaanapali/gen80200_zap.mbn";
+};
+
&lpass_vamacro {
pinctrl-0 = <&dmic01_default>, <&dmic23_default>;
pinctrl-names = "default";
--
2.51.0
^ permalink raw reply related
* [PATCH 6/8] arm64: dts: qcom: kaanapali: Add GPU cooling
From: Akhil P Oommen @ 2026-05-11 22:23 UTC (permalink / raw)
To: Will Deacon, Robin Murphy, Joerg Roedel, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Bjorn Andersson, Konrad Dybcio,
Rob Clark, Dmitry Baryshkov, Abhinav Kumar, Jessica Zhang,
Marijn Suijten, Maarten Lankhorst, Maxime Ripard,
Thomas Zimmermann, David Airlie, Simona Vetter
Cc: Sean Paul, linux-arm-kernel, iommu, devicetree, linux-kernel,
linux-arm-msm, freedreno, dri-devel, Akhil P Oommen, Gaurav Kohli
In-Reply-To: <20260512-kaana-gpu-dt-v1-0-13e1c07c2050@oss.qualcomm.com>
From: Gaurav Kohli <gaurav.kohli@oss.qualcomm.com>
Unlike the CPU, the GPU does not throttle its speed automatically when it
reaches high temperatures.
Set up GPU cooling by throttling the GPU speed
when reaching 105°C.
Signed-off-by: Gaurav Kohli <gaurav.kohli@oss.qualcomm.com>
Signed-off-by: Akhil P Oommen <akhilpo@oss.qualcomm.com>
---
arch/arm64/boot/dts/qcom/kaanapali.dtsi | 165 ++++++++++++++++++++++++++------
1 file changed, 135 insertions(+), 30 deletions(-)
diff --git a/arch/arm64/boot/dts/qcom/kaanapali.dtsi b/arch/arm64/boot/dts/qcom/kaanapali.dtsi
index c57aea44218e..5089416ec32c 100644
--- a/arch/arm64/boot/dts/qcom/kaanapali.dtsi
+++ b/arch/arm64/boot/dts/qcom/kaanapali.dtsi
@@ -26,6 +26,7 @@
#include <dt-bindings/soc/qcom,gpr.h>
#include <dt-bindings/soc/qcom,rpmh-rsc.h>
#include <dt-bindings/sound/qcom,q6dsp-lpass-ports.h>
+#include <dt-bindings/thermal/thermal.h>
#include "kaanapali-ipcc.h"
@@ -7045,13 +7046,15 @@ nsphmx-3-critical {
};
gpuss-0-thermal {
+ polling-delay-passive = <200>;
+
thermal-sensors = <&tsens5 0>;
trips {
- gpuss-0-hot {
- temperature = <120000>;
+ gpuss_0_alert0: gpuss-0-alert0 {
+ temperature = <105000>;
hysteresis = <5000>;
- type = "hot";
+ type = "passive";
};
gpuss-0-critical {
@@ -7060,16 +7063,25 @@ gpuss-0-critical {
type = "critical";
};
};
+
+ cooling-maps {
+ map0 {
+ trip = <&gpuss_0_alert0>;
+ cooling-device = <&gpu THERMAL_NO_LIMIT THERMAL_NO_LIMIT>;
+ };
+ };
};
gpuss-1-thermal {
+ polling-delay-passive = <200>;
+
thermal-sensors = <&tsens5 1>;
trips {
- gpuss-1-hot {
- temperature = <120000>;
+ gpuss_1_alert0: gpuss-1-alert0 {
+ temperature = <105000>;
hysteresis = <5000>;
- type = "hot";
+ type = "passive";
};
gpuss-1-critical {
@@ -7078,16 +7090,25 @@ gpuss-1-critical {
type = "critical";
};
};
+
+ cooling-maps {
+ map0 {
+ trip = <&gpuss_1_alert0>;
+ cooling-device = <&gpu THERMAL_NO_LIMIT THERMAL_NO_LIMIT>;
+ };
+ };
};
gpuss-2-thermal {
+ polling-delay-passive = <200>;
+
thermal-sensors = <&tsens5 2>;
trips {
- gpuss-2-hot {
- temperature = <120000>;
+ gpuss_2_alert0: gpuss-2-alert0 {
+ temperature = <105000>;
hysteresis = <5000>;
- type = "hot";
+ type = "passive";
};
gpuss-2-critical {
@@ -7096,16 +7117,25 @@ gpuss-2-critical {
type = "critical";
};
};
+
+ cooling-maps {
+ map0 {
+ trip = <&gpuss_2_alert0>;
+ cooling-device = <&gpu THERMAL_NO_LIMIT THERMAL_NO_LIMIT>;
+ };
+ };
};
gpuss-3-thermal {
+ polling-delay-passive = <200>;
+
thermal-sensors = <&tsens5 3>;
trips {
- gpuss-3-hot {
- temperature = <120000>;
+ gpuss_3_alert0: gpuss-3-alert0 {
+ temperature = <105000>;
hysteresis = <5000>;
- type = "hot";
+ type = "passive";
};
gpuss-3-critical {
@@ -7114,16 +7144,25 @@ gpuss-3-critical {
type = "critical";
};
};
+
+ cooling-maps {
+ map0 {
+ trip = <&gpuss_3_alert0>;
+ cooling-device = <&gpu THERMAL_NO_LIMIT THERMAL_NO_LIMIT>;
+ };
+ };
};
gpuss-4-thermal {
+ polling-delay-passive = <200>;
+
thermal-sensors = <&tsens5 4>;
trips {
- gpuss-4-hot {
- temperature = <120000>;
+ gpuss_4_alert0: gpuss-4-alert0 {
+ temperature = <105000>;
hysteresis = <5000>;
- type = "hot";
+ type = "passive";
};
gpuss-4-critical {
@@ -7132,16 +7171,25 @@ gpuss-4-critical {
type = "critical";
};
};
+
+ cooling-maps {
+ map0 {
+ trip = <&gpuss_4_alert0>;
+ cooling-device = <&gpu THERMAL_NO_LIMIT THERMAL_NO_LIMIT>;
+ };
+ };
};
gpuss-5-thermal {
+ polling-delay-passive = <200>;
+
thermal-sensors = <&tsens5 5>;
trips {
- gpuss-5-hot {
- temperature = <120000>;
+ gpuss_5_alert0: gpuss-5-alert0 {
+ temperature = <105000>;
hysteresis = <5000>;
- type = "hot";
+ type = "passive";
};
gpuss-5-critical {
@@ -7150,16 +7198,25 @@ gpuss-5-critical {
type = "critical";
};
};
+
+ cooling-maps {
+ map0 {
+ trip = <&gpuss_5_alert0>;
+ cooling-device = <&gpu THERMAL_NO_LIMIT THERMAL_NO_LIMIT>;
+ };
+ };
};
gpuss-6-thermal {
+ polling-delay-passive = <200>;
+
thermal-sensors = <&tsens5 6>;
trips {
- gpuss-6-hot {
- temperature = <120000>;
+ gpuss_6_alert0: gpuss-6-alert0 {
+ temperature = <105000>;
hysteresis = <5000>;
- type = "hot";
+ type = "passive";
};
gpuss-6-critical {
@@ -7168,16 +7225,25 @@ gpuss-6-critical {
type = "critical";
};
};
+
+ cooling-maps {
+ map0 {
+ trip = <&gpuss_6_alert0>;
+ cooling-device = <&gpu THERMAL_NO_LIMIT THERMAL_NO_LIMIT>;
+ };
+ };
};
gpuss-7-thermal {
+ polling-delay-passive = <200>;
+
thermal-sensors = <&tsens5 7>;
trips {
- gpuss-7-hot {
- temperature = <120000>;
+ gpuss_7_alert0: gpuss-7-alert0 {
+ temperature = <105000>;
hysteresis = <5000>;
- type = "hot";
+ type = "passive";
};
gpuss-7-critical {
@@ -7186,16 +7252,25 @@ gpuss-7-critical {
type = "critical";
};
};
+
+ cooling-maps {
+ map0 {
+ trip = <&gpuss_7_alert0>;
+ cooling-device = <&gpu THERMAL_NO_LIMIT THERMAL_NO_LIMIT>;
+ };
+ };
};
gpuss-8-thermal {
+ polling-delay-passive = <200>;
+
thermal-sensors = <&tsens5 8>;
trips {
- gpuss-8-hot {
- temperature = <120000>;
+ gpuss_8_alert0: gpuss-8-alert0 {
+ temperature = <105000>;
hysteresis = <5000>;
- type = "hot";
+ type = "passive";
};
gpuss-8-critical {
@@ -7204,16 +7279,25 @@ gpuss-8-critical {
type = "critical";
};
};
+
+ cooling-maps {
+ map0 {
+ trip = <&gpuss_8_alert0>;
+ cooling-device = <&gpu THERMAL_NO_LIMIT THERMAL_NO_LIMIT>;
+ };
+ };
};
gpuss-9-thermal {
+ polling-delay-passive = <200>;
+
thermal-sensors = <&tsens5 9>;
trips {
- gpuss-9-hot {
- temperature = <120000>;
+ gpuss_9_alert0: gpuss-9-alert0 {
+ temperature = <105000>;
hysteresis = <5000>;
- type = "hot";
+ type = "passive";
};
gpuss-9-critical {
@@ -7222,12 +7306,26 @@ gpuss-9-critical {
type = "critical";
};
};
+
+ cooling-maps {
+ map0 {
+ trip = <&gpuss_9_alert0>;
+ cooling-device = <&gpu THERMAL_NO_LIMIT THERMAL_NO_LIMIT>;
+ };
+ };
};
gpuss-10-thermal {
+ polling-delay-passive = <200>;
+
thermal-sensors = <&tsens5 10>;
trips {
+ gpuss_10_alert0: gpuss-10-alert0 {
+ temperature = <105000>;
+ hysteresis = <5000>;
+ type = "passive";
+ };
gpuss-10-hot {
temperature = <120000>;
hysteresis = <5000>;
@@ -7240,6 +7338,13 @@ gpuss-10-critical {
type = "critical";
};
};
+
+ cooling-maps {
+ map0 {
+ trip = <&gpuss_10_alert0>;
+ cooling-device = <&gpu THERMAL_NO_LIMIT THERMAL_NO_LIMIT>;
+ };
+ };
};
ddr-thermal {
--
2.51.0
^ permalink raw reply related
* [PATCH 5/8] arm64: dts: qcom: Add GPU support for Kaanapali
From: Akhil P Oommen @ 2026-05-11 22:23 UTC (permalink / raw)
To: Will Deacon, Robin Murphy, Joerg Roedel, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Bjorn Andersson, Konrad Dybcio,
Rob Clark, Dmitry Baryshkov, Abhinav Kumar, Jessica Zhang,
Marijn Suijten, Maarten Lankhorst, Maxime Ripard,
Thomas Zimmermann, David Airlie, Simona Vetter
Cc: Sean Paul, linux-arm-kernel, iommu, devicetree, linux-kernel,
linux-arm-msm, freedreno, dri-devel, Akhil P Oommen
In-Reply-To: <20260512-kaana-gpu-dt-v1-0-13e1c07c2050@oss.qualcomm.com>
Adreno 840 present in Kaanapali SoC is the second generation GPU in
A8x family. It is based on the new slice architecture with 3 slices,
higher GMEM/caches etc.
There is some re-arrangement in the reglist to properly cover maximum
register region. Other than this, the DT description is mostly similar
to the existing chipsets except the OPP tables.
Signed-off-by: Akhil P Oommen <akhilpo@oss.qualcomm.com>
---
arch/arm64/boot/dts/qcom/kaanapali.dtsi | 232 ++++++++++++++++++++++++++++++++
1 file changed, 232 insertions(+)
diff --git a/arch/arm64/boot/dts/qcom/kaanapali.dtsi b/arch/arm64/boot/dts/qcom/kaanapali.dtsi
index 0211fc9f8c88..c57aea44218e 100644
--- a/arch/arm64/boot/dts/qcom/kaanapali.dtsi
+++ b/arch/arm64/boot/dts/qcom/kaanapali.dtsi
@@ -2573,6 +2573,238 @@ videocc: clock-controller@20f0000 {
#power-domain-cells = <1>;
};
+ gpu: gpu@3d00000 {
+ compatible = "qcom,adreno-44050a01", "qcom,adreno";
+ reg = <0x0 0x03d00000 0x0 0x6c000>,
+ <0x0 0x03d9e000 0x0 0x2000>;
+ reg-names = "kgsl_3d0_reg_memory",
+ "cx_mem";
+
+ interrupts = <GIC_SPI 300 IRQ_TYPE_LEVEL_HIGH>;
+
+ iommus = <&adreno_smmu 0 0x0>,
+ <&adreno_smmu 1 0x0>;
+
+ operating-points-v2 = <&gpu_opp_table>;
+
+ qcom,gmu = <&gmu>;
+ #cooling-cells = <2>;
+
+ nvmem-cells = <&gpu_speed_bin>;
+ nvmem-cell-names = "speed_bin";
+
+ interconnects = <&gem_noc MASTER_GFX3D QCOM_ICC_TAG_ALWAYS
+ &mc_virt SLAVE_EBI1 QCOM_ICC_TAG_ALWAYS>;
+ interconnect-names = "gfx-mem";
+
+ gpu_zap_shader: zap-shader {
+ memory-region = <&gpu_microcode_mem>;
+ };
+
+ gpu_opp_table: opp-table {
+ compatible = "operating-points-v2-adreno",
+ "operating-points-v2";
+
+ opp-222000000 {
+ opp-hz = /bits/ 64 <222000000>;
+ opp-level = <RPMH_REGULATOR_LEVEL_LOW_SVS_D2>;
+ opp-peak-kBps = <2136718>;
+ opp-supported-hw = <0x0f>;
+ /* ACD is disabled */
+ };
+
+ opp-282000000 {
+ opp-hz = /bits/ 64 <282000000>;
+ opp-level = <RPMH_REGULATOR_LEVEL_LOW_SVS_D1_1>;
+ opp-peak-kBps = <5285156>;
+ opp-supported-hw = <0x0f>;
+ qcom,opp-acd-level = <0xca2e5ffd>;
+ };
+
+ opp-342000000 {
+ opp-hz = /bits/ 64 <342000000>;
+ opp-level = <RPMH_REGULATOR_LEVEL_LOW_SVS_D1>;
+ opp-peak-kBps = <5285156>;
+ opp-supported-hw = <0x0f>;
+ qcom,opp-acd-level = <0xe22a5ffd>;
+ };
+
+ opp-382000000 {
+ opp-hz = /bits/ 64 <382000000>;
+ opp-level = <RPMH_REGULATOR_LEVEL_LOW_SVS_D0>;
+ opp-peak-kBps = <5285156>;
+ opp-supported-hw = <0x0f>;
+ qcom,opp-acd-level = <0xa22c5ffd>;
+ };
+
+ opp-422000000 {
+ opp-hz = /bits/ 64 <422000000>;
+ opp-level = <RPMH_REGULATOR_LEVEL_LOW_SVS>;
+ opp-peak-kBps = <6074218>;
+ opp-supported-hw = <0x0f>;
+ qcom,opp-acd-level = <0xa22c5ffd>;
+ };
+
+ opp-461000000 {
+ opp-hz = /bits/ 64 <461000000>;
+ opp-level = <RPMH_REGULATOR_LEVEL_LOW_SVS_L0>;
+ opp-peak-kBps = <6074218>;
+ opp-supported-hw = <0x0f>;
+ qcom,opp-acd-level = <0xe82e5ffd>;
+ };
+
+ opp-500000000 {
+ opp-hz = /bits/ 64 <500000000>;
+ opp-level = <RPMH_REGULATOR_LEVEL_LOW_SVS_L1>;
+ opp-peak-kBps = <6074218>;
+ opp-supported-hw = <0x0f>;
+ qcom,opp-acd-level = <0xe82c5ffd>;
+ };
+
+ opp-539000000 {
+ opp-hz = /bits/ 64 <539000000>;
+ opp-level = <RPMH_REGULATOR_LEVEL_LOW_SVS_L2>;
+ opp-peak-kBps = <6074218>;
+ opp-supported-hw = <0x0f>;
+ qcom,opp-acd-level = <0xc82b5ffd>;
+ };
+
+ opp-578000000 {
+ opp-hz = /bits/ 64 <578000000>;
+ opp-level = <RPMH_REGULATOR_LEVEL_SVS>;
+ opp-peak-kBps = <6074218>;
+ opp-supported-hw = <0x0f>;
+ qcom,opp-acd-level = <0xc02c5ffd>;
+ };
+
+ opp-646000000 {
+ opp-hz = /bits/ 64 <646000000>;
+ opp-level = <RPMH_REGULATOR_LEVEL_SVS_L0>;
+ opp-peak-kBps = <8171875>;
+ opp-supported-hw = <0x0f>;
+ qcom,opp-acd-level = <0xc02c5ffd>;
+ };
+
+ opp-726000000 {
+ opp-hz = /bits/ 64 <726000000>;
+ opp-level = <RPMH_REGULATOR_LEVEL_SVS_L1>;
+ opp-peak-kBps = <8171875>;
+ opp-supported-hw = <0x0f>;
+ qcom,opp-acd-level = <0x882f5ffd>;
+ };
+
+ opp-826000000 {
+ opp-hz = /bits/ 64 <826000000>;
+ opp-level = <RPMH_REGULATOR_LEVEL_SVS_L2>;
+ opp-peak-kBps = <12449218>;
+ opp-supported-hw = <0x0f>;
+ qcom,opp-acd-level = <0xa82c5ffd>;
+ };
+
+ opp-902000000 {
+ opp-hz = /bits/ 64 <902000000>;
+ opp-level = <RPMH_REGULATOR_LEVEL_NOM>;
+ opp-peak-kBps = <12449218>;
+ opp-supported-hw = <0x0f>;
+ qcom,opp-acd-level = <0xa82b5ffd>;
+ };
+
+ opp-967000000 {
+ opp-hz = /bits/ 64 <967000000>;
+ opp-level = <RPMH_REGULATOR_LEVEL_NOM_L1>;
+ opp-peak-kBps = <12449218>;
+ opp-supported-hw = <0x0f>;
+ qcom,opp-acd-level = <0x882a5ffd>;
+ };
+
+ opp-1050000000 {
+ opp-hz = /bits/ 64 <1050000000>;
+ opp-level = <RPMH_REGULATOR_LEVEL_TURBO_L1>;
+ opp-peak-kBps = <20832031>;
+ opp-supported-hw = <0x0f>;
+ qcom,opp-acd-level = <0x88295ffd>;
+ };
+
+ opp-1200000000 {
+ opp-hz = /bits/ 64 <1200000000>;
+ opp-level = <RPMH_REGULATOR_LEVEL_TURBO_L3>;
+ opp-peak-kBps = <20832031>;
+ opp-supported-hw = <0x07>;
+ qcom,opp-acd-level = <0xa02e5ffd>;
+ };
+
+ opp-1300000000 {
+ opp-hz = /bits/ 64 <1300000000>;
+ opp-level = <RPMH_REGULATOR_LEVEL_TURBO_L4>;
+ opp-peak-kBps = <20832031>;
+ opp-supported-hw = <0x03>;
+ qcom,opp-acd-level = <0x802d5ffd>;
+ };
+ };
+ };
+
+ gmu: gmu@3d6c000 {
+ compatible = "qcom,adreno-gmu-840.1", "qcom,adreno-gmu";
+
+ reg = <0x0 0x03d6c000 0x0 0x68000>;
+ reg-names = "gmu";
+
+ interrupts = <GIC_SPI 304 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 305 IRQ_TYPE_LEVEL_HIGH>;
+ interrupt-names = "hfi", "gmu";
+
+ clocks = <&gpucc GPU_CC_AHB_CLK>,
+ <&gpucc GPU_CC_CX_GMU_CLK>,
+ <&gpucc GPU_CC_CXO_CLK>,
+ <&gcc GCC_GPU_GEMNOC_GFX_CLK>,
+ <&gpucc GPU_CC_HUB_CX_INT_CLK>;
+ clock-names = "ahb",
+ "gmu",
+ "cxo",
+ "memnoc",
+ "hub";
+
+ power-domains = <&gpucc GPU_CC_CX_GDSC>,
+ <&gxclkctl GX_CLKCTL_GX_GDSC>;
+ power-domain-names = "cx",
+ "gx";
+
+ iommus = <&adreno_smmu 5 0x0>;
+
+ qcom,qmp = <&aoss_qmp>;
+
+ operating-points-v2 = <&gmu_opp_table>;
+
+ gmu_opp_table: opp-table {
+ compatible = "operating-points-v2";
+
+ opp-475000000 {
+ opp-hz = /bits/ 64 <475000000>;
+ opp-level = <RPMH_REGULATOR_LEVEL_LOW_SVS_D1>;
+ };
+
+ opp-575000000 {
+ opp-hz = /bits/ 64 <575000000>;
+ opp-level = <RPMH_REGULATOR_LEVEL_LOW_SVS>;
+ };
+
+ opp-700000000 {
+ opp-hz = /bits/ 64 <700000000>;
+ opp-level = <RPMH_REGULATOR_LEVEL_SVS>;
+ };
+
+ opp-725000000 {
+ opp-hz = /bits/ 64 <725000000>;
+ opp-level = <RPMH_REGULATOR_LEVEL_SVS_L1>;
+ };
+
+ opp-750000000 {
+ opp-hz = /bits/ 64 <750000000>;
+ opp-level = <RPMH_REGULATOR_LEVEL_NOM>;
+ };
+ };
+ };
+
gxclkctl: clock-controller@3d64000 {
compatible = "qcom,kaanapali-gxclkctl";
reg = <0x0 0x03d64000 0x0 0x6000>;
--
2.51.0
^ permalink raw reply related
* [PATCH 3/8] arm64: dts: qcom: kaanapali: add the GPU SMMU node
From: Akhil P Oommen @ 2026-05-11 22:23 UTC (permalink / raw)
To: Will Deacon, Robin Murphy, Joerg Roedel, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Bjorn Andersson, Konrad Dybcio,
Rob Clark, Dmitry Baryshkov, Abhinav Kumar, Jessica Zhang,
Marijn Suijten, Maarten Lankhorst, Maxime Ripard,
Thomas Zimmermann, David Airlie, Simona Vetter
Cc: Sean Paul, linux-arm-kernel, iommu, devicetree, linux-kernel,
linux-arm-msm, freedreno, dri-devel, Akhil P Oommen,
Qingqing Zhou
In-Reply-To: <20260512-kaana-gpu-dt-v1-0-13e1c07c2050@oss.qualcomm.com>
From: Qingqing Zhou <quic_qqzhou@quicinc.com>
Add the Adreno GPU SMMU node for kaanapali platform.
Signed-off-by: Qingqing Zhou <quic_qqzhou@quicinc.com>
Signed-off-by: Akhil P Oommen <akhilpo@oss.qualcomm.com>
---
arch/arm64/boot/dts/qcom/kaanapali.dtsi | 41 +++++++++++++++++++++++++++++++++
1 file changed, 41 insertions(+)
diff --git a/arch/arm64/boot/dts/qcom/kaanapali.dtsi b/arch/arm64/boot/dts/qcom/kaanapali.dtsi
index bab654bbd6d0..26a4de9c8d45 100644
--- a/arch/arm64/boot/dts/qcom/kaanapali.dtsi
+++ b/arch/arm64/boot/dts/qcom/kaanapali.dtsi
@@ -2597,6 +2597,47 @@ gpucc: clock-controller@3d90000 {
#power-domain-cells = <1>;
};
+ adreno_smmu: iommu@3da0000 {
+ compatible = "qcom,kaanapali-smmu-500", "qcom,adreno-smmu",
+ "qcom,smmu-500", "arm,mmu-500";
+ reg = <0x0 0x3da0000 0x0 0x40000>;
+ #iommu-cells = <2>;
+ #global-interrupts = <1>;
+ dma-coherent;
+
+ power-domains = <&gpucc GPU_CC_CX_GDSC>;
+
+ clocks = <&gpucc GPU_CC_GPU_SMMU_VOTE_CLK>;
+ clock-names = "hlos";
+
+ interrupts = <GIC_SPI 674 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 678 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 679 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 680 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 681 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 682 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 683 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 684 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 685 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 686 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 687 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 688 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 422 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 476 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 574 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 575 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 576 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 577 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 660 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 662 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 665 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 666 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 667 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 669 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 670 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 700 IRQ_TYPE_LEVEL_HIGH>;
+ };
+
remoteproc_adsp: remoteproc@6800000 {
compatible = "qcom,kaanapali-adsp-pas", "qcom,sm8550-adsp-pas";
reg = <0x0 0x06800000 0x0 0x10000>;
--
2.51.0
^ permalink raw reply related
* [PATCH 4/8] arm64: dts: qcom: kaanapali: Add qfprom node
From: Akhil P Oommen @ 2026-05-11 22:23 UTC (permalink / raw)
To: Will Deacon, Robin Murphy, Joerg Roedel, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Bjorn Andersson, Konrad Dybcio,
Rob Clark, Dmitry Baryshkov, Abhinav Kumar, Jessica Zhang,
Marijn Suijten, Maarten Lankhorst, Maxime Ripard,
Thomas Zimmermann, David Airlie, Simona Vetter
Cc: Sean Paul, linux-arm-kernel, iommu, devicetree, linux-kernel,
linux-arm-msm, freedreno, dri-devel, Akhil P Oommen, Jingyi Wang
In-Reply-To: <20260512-kaana-gpu-dt-v1-0-13e1c07c2050@oss.qualcomm.com>
From: Jingyi Wang <jingyi.wang@oss.qualcomm.com>
Add the qfprom node and gpu related subnodes on Kaanapali SoC.
Signed-off-by: Jingyi Wang <jingyi.wang@oss.qualcomm.com>
Signed-off-by: Akhil P Oommen <akhilpo@oss.qualcomm.com>
---
arch/arm64/boot/dts/qcom/kaanapali.dtsi | 12 ++++++++++++
1 file changed, 12 insertions(+)
diff --git a/arch/arm64/boot/dts/qcom/kaanapali.dtsi b/arch/arm64/boot/dts/qcom/kaanapali.dtsi
index 26a4de9c8d45..0211fc9f8c88 100644
--- a/arch/arm64/boot/dts/qcom/kaanapali.dtsi
+++ b/arch/arm64/boot/dts/qcom/kaanapali.dtsi
@@ -5868,6 +5868,18 @@ rpmhpd_opp_super_turbo_no_cpr: opp-480 {
};
};
+ efuse@221c8000 {
+ compatible = "qcom,kaanapali-qfprom", "qcom,qfprom";
+ reg = <0x0 0x221c8000 0x0 0x1000>;
+ #address-cells = <1>;
+ #size-cells = <1>;
+
+ gpu_speed_bin: gpu-speed-bin@142 {
+ reg = <0x142 0x2>;
+ bits = <3 9>;
+ };
+ };
+
nsp_noc: interconnect@260c0000 {
compatible = "qcom,kaanapali-nsp-noc";
reg = <0x0 0x260c0000 0x0 0x21280>;
--
2.51.0
^ permalink raw reply related
* [PATCH 2/8] dt-bindings: display/msm: gpu: Document Adreno 840
From: Akhil P Oommen @ 2026-05-11 22:23 UTC (permalink / raw)
To: Will Deacon, Robin Murphy, Joerg Roedel, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Bjorn Andersson, Konrad Dybcio,
Rob Clark, Dmitry Baryshkov, Abhinav Kumar, Jessica Zhang,
Marijn Suijten, Maarten Lankhorst, Maxime Ripard,
Thomas Zimmermann, David Airlie, Simona Vetter
Cc: Sean Paul, linux-arm-kernel, iommu, devicetree, linux-kernel,
linux-arm-msm, freedreno, dri-devel, Akhil P Oommen
In-Reply-To: <20260512-kaana-gpu-dt-v1-0-13e1c07c2050@oss.qualcomm.com>
Adreno 840 GPU found in Kaanapali chipsets belongs to the A8x family.
It is a new IP which features the new slice architecture with 3 slices,
raytracing support, and the highest GMEM size seen so far on a Snapdragon
mobile chipsets. Update the dt bindings documentation to describe this GPU.
Signed-off-by: Akhil P Oommen <akhilpo@oss.qualcomm.com>
---
Documentation/devicetree/bindings/display/msm/gpu.yaml | 5 ++++-
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/Documentation/devicetree/bindings/display/msm/gpu.yaml b/Documentation/devicetree/bindings/display/msm/gpu.yaml
index e67cd708dda2..35c6d38dc379 100644
--- a/Documentation/devicetree/bindings/display/msm/gpu.yaml
+++ b/Documentation/devicetree/bindings/display/msm/gpu.yaml
@@ -415,7 +415,9 @@ allOf:
properties:
compatible:
contains:
- const: qcom,adreno-44070001
+ enum:
+ - qcom,adreno-44050a01
+ - qcom,adreno-44070001
then:
properties:
reg:
@@ -450,6 +452,7 @@ allOf:
- qcom,adreno-43050a01
- qcom,adreno-43050c01
- qcom,adreno-43051401
+ - qcom,adreno-44050a01
- qcom,adreno-44070001
then: # Starting with A6xx, the clocks are usually defined in the GMU node
--
2.51.0
^ permalink raw reply related
* [PATCH 1/8] dt-bindings: arm-smmu: Update the description for Kaanapali GPU SMMU
From: Akhil P Oommen @ 2026-05-11 22:23 UTC (permalink / raw)
To: Will Deacon, Robin Murphy, Joerg Roedel, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Bjorn Andersson, Konrad Dybcio,
Rob Clark, Dmitry Baryshkov, Abhinav Kumar, Jessica Zhang,
Marijn Suijten, Maarten Lankhorst, Maxime Ripard,
Thomas Zimmermann, David Airlie, Simona Vetter
Cc: Sean Paul, linux-arm-kernel, iommu, devicetree, linux-kernel,
linux-arm-msm, freedreno, dri-devel, Akhil P Oommen
In-Reply-To: <20260512-kaana-gpu-dt-v1-0-13e1c07c2050@oss.qualcomm.com>
Extend the sm8750's clock description section to also cover Kaanapali GPU
SMMU since it uses the same single "hlos" vote clock.
Signed-off-by: Akhil P Oommen <akhilpo@oss.qualcomm.com>
---
Documentation/devicetree/bindings/iommu/arm,smmu.yaml | 1 +
1 file changed, 1 insertion(+)
diff --git a/Documentation/devicetree/bindings/iommu/arm,smmu.yaml b/Documentation/devicetree/bindings/iommu/arm,smmu.yaml
index b811ece722c9..d1330fc0178a 100644
--- a/Documentation/devicetree/bindings/iommu/arm,smmu.yaml
+++ b/Documentation/devicetree/bindings/iommu/arm,smmu.yaml
@@ -568,6 +568,7 @@ allOf:
items:
- enum:
- qcom,glymur-smmu-500
+ - qcom,kaanapali-smmu-500
- qcom,sm8750-smmu-500
- const: qcom,adreno-smmu
- const: qcom,smmu-500
--
2.51.0
^ permalink raw reply related
* [PATCH 0/8] arm64: dts: qcom: Devicetree support for Kaanapali GPU
From: Akhil P Oommen @ 2026-05-11 22:23 UTC (permalink / raw)
To: Will Deacon, Robin Murphy, Joerg Roedel, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Bjorn Andersson, Konrad Dybcio,
Rob Clark, Dmitry Baryshkov, Abhinav Kumar, Jessica Zhang,
Marijn Suijten, Maarten Lankhorst, Maxime Ripard,
Thomas Zimmermann, David Airlie, Simona Vetter
Cc: Sean Paul, linux-arm-kernel, iommu, devicetree, linux-kernel,
linux-arm-msm, freedreno, dri-devel, Akhil P Oommen,
Qingqing Zhou, Jingyi Wang, Gaurav Kohli
This series adds the necessary Device Tree bits to enable GPU support
on the Kaanapali-based devices. The Adreno 840 GPU present in Kaanapali
chipsets is based on the new Adreno A8x family of GPUs. It features a
new slice architecture with 3 slices, raytracing support and other
improvements.
This series includes patches that updates DT schema, add GPU SMMU,
GPU/GMU support, GPU cooling, and enables the GPU on Kaanapali MTP and
QRD platforms.
Signed-off-by: Akhil P Oommen <akhilpo@oss.qualcomm.com>
---
Akhil P Oommen (5):
dt-bindings: arm-smmu: Update the description for Kaanapali GPU SMMU
dt-bindings: display/msm: gpu: Document Adreno 840
arm64: dts: qcom: Add GPU support for Kaanapali
arm64: dts: qcom: kaanapali-mtp: Enable GPU
arm64: dts: qcom: kaanapali-qrd: Enable GPU
Gaurav Kohli (1):
arm64: dts: qcom: kaanapali: Add GPU cooling
Jingyi Wang (1):
arm64: dts: qcom: kaanapali: Add qfprom node
Qingqing Zhou (1):
arm64: dts: qcom: kaanapali: add the GPU SMMU node
.../devicetree/bindings/display/msm/gpu.yaml | 5 +-
.../devicetree/bindings/iommu/arm,smmu.yaml | 1 +
arch/arm64/boot/dts/qcom/kaanapali-mtp.dts | 8 +
arch/arm64/boot/dts/qcom/kaanapali-qrd.dts | 8 +
arch/arm64/boot/dts/qcom/kaanapali.dtsi | 450 +++++++++++++++++++--
5 files changed, 441 insertions(+), 31 deletions(-)
---
base-commit: b462608de92a7cac450781f9d8d4c7cf3ccf82db
change-id: 20260412-kaana-gpu-dt-968a70134c22
prerequisite-message-id: <20260427-gfx-clk-fixes-v2-0-797e54b3d464@oss.qualcomm.com>
prerequisite-patch-id: 82e142b3d904e746db0e288fb7ea6812661c3537
prerequisite-patch-id: d141a83ef741d26b03d931cf120b8b541ec51b9c
prerequisite-patch-id: 5bdaf78fd75be779d4aa73b85a185a10d8458366
prerequisite-patch-id: 0263b47f4e1aeb61fc96c6dbd9f7168ffe0eb04e
prerequisite-patch-id: bed1e449dca0167ed99e8c4f1e544ed60ae17014
prerequisite-patch-id: feda87721f22e443f38165787b2b28fe1a40aa18
prerequisite-message-id: <20260512-glymur-gpu-dt-v3-1-84232dc21c03@oss.qualcomm.com>
prerequisite-patch-id: 9175e9ae77ac032c2f0502e2c63bb7b7d1ae4ead
prerequisite-patch-id: a29ab9cea24f74a76a69f144f76f9860e014ad19
prerequisite-patch-id: 6243ab821a3d9cd641a8dca8cdab167fe9da8735
prerequisite-patch-id: 36f4bb7740fd65d808fa6685bce4b03798a547ff
prerequisite-patch-id: 054631082c45d3ab3117f541f0d4d90b660dac73
Best regards,
--
Akhil P Oommen <akhilpo@oss.qualcomm.com>
^ permalink raw reply
* [PATCH AUTOSEL 7.0-5.10] fbdev: ipu-v3: clean up kernel-doc warnings
From: Sasha Levin @ 2026-05-11 22:19 UTC (permalink / raw)
To: patches, stable
Cc: Randy Dunlap, Philipp Zabel, Helge Deller, Sasha Levin, shawnguo,
linux-fbdev, dri-devel, linux-arm-kernel, linux-kernel
In-Reply-To: <20260511221931.2370053-1-sashal@kernel.org>
From: Randy Dunlap <rdunlap@infradead.org>
[ Upstream commit f1fb23a0a0fcbdb66672da51d7d63a259f6396ca ]
Correct all kernel-doc warnings:
- fix a typedef kernel-doc comment
- mark a list_head as private
- use Returns: for function return values
Warning: include/video/imx-ipu-image-convert.h:31 struct member 'list' not
described in 'ipu_image_convert_run'
Warning: include/video/imx-ipu-image-convert.h:40 function parameter
'ipu_image_convert_cb_t' not described in 'void'
Warning: include/video/imx-ipu-image-convert.h:40 expecting prototype for
ipu_image_convert_cb_t(). Prototype was for void() instead
Warning: include/video/imx-ipu-image-convert.h:66 No description found for
return value of 'ipu_image_convert_verify'
Warning: include/video/imx-ipu-image-convert.h:90 No description found for
return value of 'ipu_image_convert_prepare'
Warning: include/video/imx-ipu-image-convert.h:125 No description found for
return value of 'ipu_image_convert_queue'
Warning: include/video/imx-ipu-image-convert.h:163 No description found for
return value of 'ipu_image_convert'
Signed-off-by: Randy Dunlap <rdunlap@infradead.org>
Reviewed-by: Philipp Zabel <p.zabel@pengutronix.de>
Signed-off-by: Helge Deller <deller@gmx.de>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
LLM Generated explanations, may be completely bogus:
## Phase 1: Commit Message Forensics
Step 1.1 Record: subsystem `fbdev: ipu-v3`; action verb `clean up`;
intent is to correct kernel-doc warnings in `include/video/imx-ipu-
image-convert.h`.
Step 1.2 Record: tags in committed message are `Signed-off-by: Randy
Dunlap <rdunlap@infradead.org>`, `Reviewed-by: Philipp Zabel
<p.zabel@pengutronix.de>`, and `Signed-off-by: Helge Deller
<deller@gmx.de>`. No `Fixes:`, `Reported-by:`, `Tested-by:`, `Acked-
by:`, `Link:`, or `Cc: stable@vger.kernel.org` tag is present in the
committed message.
Step 1.3 Record: the described problem is seven kernel-doc warnings: one
undocumented/private list member, malformed typedef documentation, and
missing `Returns:` sections. The visible symptom is documentation
tooling warnings, not a runtime crash, hang, data corruption, or
security issue. No affected kernel version is stated. Root cause is
incorrect kernel-doc comment syntax.
Step 1.4 Record: this is not a hidden runtime bug fix. The body and diff
both show a documentation/comment-only cleanup.
## Phase 2: Diff Analysis
Step 2.1 Record: one file changed: `include/video/imx-ipu-image-
convert.h`, 11 insertions and 5 deletions. Modified documentation covers
`struct ipu_image_convert_run`, `ipu_image_convert_cb_t`,
`ipu_image_convert_verify()`, `ipu_image_convert_prepare()`,
`ipu_image_convert_queue()`, and `ipu_image_convert()`. Scope is single-
file, header-only, surgical.
Step 2.2 Record: hunk behavior:
- `struct ipu_image_convert_run`: before, `list` was documented neither
as a member nor private; after, `/* private: */` tells kernel-doc to
ignore it as an API member.
- `ipu_image_convert_cb_t`: before, kernel-doc treated the typedef
comment as a function prototype mismatch; after, it is marked as a
typedef comment.
- Return docs: before, several returns were plain prose or missing;
after, they use kernel-doc `Returns:` syntax.
- `ipu_image_convert_prepare()`: before, the V4L2 usage note followed
the return prose; after, the return section is last and formatted for
kernel-doc.
Step 2.3 Record: bug category is documentation/kernel-doc warning
cleanup. No error-path, synchronization, refcount, memory-safety,
initialization, type, logic, or hardware workaround change exists.
Step 2.4 Record: fix quality is high for the stated documentation issue:
small, obviously correct kernel-doc syntax changes. Runtime regression
risk is effectively zero because no C declarations, types, function
bodies, data layout, or APIs are changed. Documentation rendering risk
is very low.
## Phase 3: Git History Investigation
Step 3.1 Record: `git blame` shows the affected header comments and
declarations came from `cd98e85a6b786d` by Steve Longerbeam, dated
2016-09-17. `git describe --contains cd98e85a6b786d` reports it as
present by `v4.9-rc1~41^2~24^2`.
Step 3.2 Record: no `Fixes:` tag is present, so there is no tagged
introducing commit to follow. Blame identifies `cd98e85a6b786d` as the
source of the documented preimage; `git show` confirms that commit added
queued IPU image conversion support and the API documentation.
Step 3.3 Record: recent local history for the file shows `96e9d754b35e8`
removing unused `ipu_image_convert_*` functions, `c942fddf8793b` adding
SPDX boilerplate conversion, and `cd98e85a6b786d` adding the header/API.
No prerequisite commit is needed for this documentation-only patch.
Step 3.4 Record: `git log --author='Randy Dunlap'` under fbdev/include
areas shows Randy has related cleanup/documentation work such as `fbdev:
hgafb: fix kernel-doc comments` and `fbdev: fbmon: fix function name in
kernel-doc`. The patch was reviewed by Philipp Zabel and committed by
Helge Deller, verified from the commit and lore thread.
Step 3.5 Record: no dependencies found. The diff changes only comments
and applies locally with `git apply --check`.
## Phase 4: Mailing List And External Research
Step 4.1 Record: `b4 dig -c f1fb23a0a0fcbdb66672da51d7d63a259f6396ca`
failed to find a lore match by patch-id, author/subject, or in-body
From. External fetch found the v3 discussion at
`https://yhbt.net/lore/dri-
devel/20260427183236.656902-1-rdunlap@infradead.org/T/`. The v3 thread
has Helge Deller replying “applied to fbdev git tree.” Web search/fetch
also found v2 and a v2 ping. No NAKs or objections were found.
Step 4.2 Record: `b4 dig -w` also failed for the same reason. The v3
lore mirror shows recipients included `dri-devel`, Philipp Zabel, DRM
maintainers, `imx`, `linux-arm-kernel`, Helge Deller, and `linux-fbdev`.
Step 4.3 Record: no `Reported-by:` or bug-report `Link:` tags exist. No
external crash/security bug report applies.
Step 4.4 Record: this is a standalone one-patch documentation cleanup.
v2 added the reviewed-by and updated Cc list; v3 rebased and resent.
Step 4.5 Record: direct `lore.kernel.org/stable` fetch was blocked by
Anubis. Web search for the exact subject plus `stable` found patch-
thread results but no stable-specific discussion or stable nomination.
## Phase 5: Code Semantic Analysis
Step 5.1 Record: modified documented symbols are
`ipu_image_convert_run`, `ipu_image_convert_cb_t`,
`ipu_image_convert_verify()`, `ipu_image_convert_prepare()`,
`ipu_image_convert_queue()`, and `ipu_image_convert()`.
Step 5.2 Record: `rg` found callers in `drivers/staging/media/imx/imx-
media-csc-scaler.c` for `ipu_image_convert_abort()`,
`ipu_image_convert_queue()`, `ipu_image_convert_adjust()`,
`ipu_image_convert_unprepare()`, and `ipu_image_convert_prepare()`.
Runtime callers are unaffected because only comments changed.
Step 5.3 Record: reading `drivers/gpu/ipu-v3/ipu-image-convert.c`
confirms the documented functions perform image format
adjustment/verification, context allocation, queueing, abort/unprepare,
and single conversion setup. None of those function bodies are touched.
Step 5.4 Record: runtime path is reachable through IPU image conversion
users, but the patch changes no runtime path. The affected path for the
fix is kernel-doc/documentation generation.
Step 5.5 Record: no related same-header kernel-doc fix was found by `git
log --grep='kernel-doc' -- include/video/imx-ipu-image-convert.h`.
## Phase 6: Stable Tree Analysis
Step 6.1 Record: version tags `v5.10`, `v5.15`, `v6.1`, `v6.6`, `v6.12`,
`v6.15`, `v6.16`, and `v6.17` all contain `include/video/imx-ipu-image-
convert.h` with the old kernel-doc text. The API was introduced before
`v4.9-rc1`, so active stable trees checked contain the documentation
issue.
Step 6.2 Record: expected backport difficulty is clean or minor. `git
apply --check` succeeds against the current local tree, and the checked
stable tags contain representative preimage lines. Full per-stable
worktree application was not run.
Step 6.3 Record: no related stable fix for this header was found in
local `git log --grep` searches.
## Phase 7: Subsystem Context
Step 7.1 Record: subsystem is fbdev/gpu IPU-v3 image conversion
documentation in an include header. Runtime criticality is
peripheral/driver-specific; documentation-build criticality is low.
Step 7.2 Record: local subsystem history shows ongoing cleanup/removal
activity in `drivers/gpu/ipu-v3` and the header, including unused-
function removals and treewide cleanup. This patch is not part of a
required functional series.
## Phase 8: Impact And Risk
Step 8.1 Record: affected population is kernel documentation builders,
maintainers, and users consuming generated kernel-doc. Runtime users of
IPU-v3 are not affected by behavior.
Step 8.2 Record: trigger is running kernel-doc/documentation tooling
over this header. It is not triggered by boot, device probe, syscalls,
or ordinary runtime use. Unprivileged runtime trigger does not apply.
Step 8.3 Record: failure mode is documentation warnings only. Severity
is LOW. I did not verify any configuration where these warnings are
fatal, so that does not drive the decision.
Step 8.4 Record: benefit is low but real under the documentation-fix
exception: it makes stable documentation builds cleaner. Risk is
extremely low because only comments change. Risk/benefit is favorable if
stable accepts documentation corrections.
## Phase 9: Final Synthesis
Step 9.1 Record: evidence for backporting: pure documentation
correction, explicitly fixes listed kernel-doc warnings, tiny single-
file patch, reviewed by Philipp Zabel, applied by Helge Deller, old text
exists in active stable tags checked, and documentation/comment fixes
are an allowed stable exception. Evidence against: no runtime bug, no
crash/security/data-corruption impact, no stable nomination found, and
b4 could not match the thread. Unresolved: direct stable-lore search was
blocked; full apply checks on every stable branch were not run.
Step 9.2 Record:
1. Obviously correct and tested? Mostly yes for documentation syntax;
reviewed and applied, but no `Tested-by`.
2. Fixes a real bug that affects users? Yes, a real kernel-doc warning
issue; not a runtime bug.
3. Important issue? No runtime severity; LOW documentation-build
severity.
4. Small and contained? Yes, 11 additions and 5 deletions in one header.
5. No new features or APIs? Yes, comments only.
6. Can apply to stable trees? Likely yes; local apply check passed and
stable tags checked contain the preimage.
Step 9.3 Record: exception category applies: documentation/comment fix.
This is the main reason to accept despite lack of runtime impact.
Step 9.4 Decision: backporting is appropriate under the stable
documentation-fix exception. It is not a stability/security fix, but it
is a correct, reviewed, zero-runtime-risk cleanup of real kernel-doc
warnings in code present across active stable trees.
## Verification
- Phase 1: fetched and inspected committed metadata for
`f1fb23a0a0fcbdb66672da51d7d63a259f6396ca`; confirmed tags and
message.
- Phase 2: `git show --stat --patch` confirmed one header, 11
insertions, 5 deletions, comments only.
- Phase 3: `git blame` confirmed changed comment preimage from
`cd98e85a6b786d`; `git describe --contains` placed it before
`v4.9-rc1`; `git show cd98e85a6b786d` confirmed original API addition.
- Phase 3: `git log` on the header/subsystem found no prerequisite
functional series.
- Phase 4: `b4 dig`, `b4 dig -a`, and `b4 dig -w` all failed to match;
recorded as a tool limitation/failure.
- Phase 4: WebFetch of the v3 lore mirror confirmed the patch thread and
Helge Deller’s applied reply; Spinics fetch confirmed v2 and a later
ping.
- Phase 5: `rg` found runtime users; `ReadFile` of implementation
confirmed function bodies exist but are not changed.
- Phase 6: tag checks confirmed the header and old doc text in `v5.10`,
`v5.15`, `v6.1`, `v6.6`, `v6.12`, `v6.15`, `v6.16`, and `v6.17`; `git
apply --check` succeeded locally.
- Phase 8: severity/risk assessment is derived from the verified
comments-only diff.
- UNVERIFIED: direct `lore.kernel.org/stable` search content was blocked
by Anubis; no actual `make htmldocs` run was performed; full patch
application against every individual stable branch was not performed.
**YES**
include/video/imx-ipu-image-convert.h | 16 +++++++++++-----
1 file changed, 11 insertions(+), 5 deletions(-)
diff --git a/include/video/imx-ipu-image-convert.h b/include/video/imx-ipu-image-convert.h
index 003b3927ede5c..6b77968a6a150 100644
--- a/include/video/imx-ipu-image-convert.h
+++ b/include/video/imx-ipu-image-convert.h
@@ -27,12 +27,13 @@ struct ipu_image_convert_run {
int status;
+ /* private: */
/* internal to image converter, callers don't touch */
struct list_head list;
};
/**
- * ipu_image_convert_cb_t - conversion callback function prototype
+ * typedef ipu_image_convert_cb_t - conversion callback function prototype
*
* @run: the completed conversion run pointer
* @ctx: a private context pointer for the callback
@@ -60,7 +61,7 @@ void ipu_image_convert_adjust(struct ipu_image *in, struct ipu_image *out,
* @out: output image format
* @rot_mode: rotation mode
*
- * Returns 0 if the formats and rotation mode meet IPU restrictions,
+ * Returns: 0 if the formats and rotation mode meet IPU restrictions,
* -EINVAL otherwise.
*/
int ipu_image_convert_verify(struct ipu_image *in, struct ipu_image *out,
@@ -77,11 +78,11 @@ int ipu_image_convert_verify(struct ipu_image *in, struct ipu_image *out,
* @complete: run completion callback
* @complete_context: a context pointer for the completion callback
*
- * Returns an opaque conversion context pointer on success, error pointer
+ * In V4L2, drivers should call ipu_image_convert_prepare() at streamon.
+ *
+ * Returns: an opaque conversion context pointer on success, error pointer
* on failure. The input/output formats and rotation mode must already meet
* IPU retrictions.
- *
- * In V4L2, drivers should call ipu_image_convert_prepare() at streamon.
*/
struct ipu_image_convert_ctx *
ipu_image_convert_prepare(struct ipu_soc *ipu, enum ipu_ic_task ic_task,
@@ -122,6 +123,8 @@ void ipu_image_convert_unprepare(struct ipu_image_convert_ctx *ctx);
* In V4L2, drivers should call ipu_image_convert_queue() while
* streaming to queue the conversion of a received input buffer.
* For example mem2mem devices this would be called in .device_run.
+ *
+ * Returns: 0 on success or -errno on error.
*/
int ipu_image_convert_queue(struct ipu_image_convert_run *run);
@@ -155,6 +158,9 @@ void ipu_image_convert_abort(struct ipu_image_convert_ctx *ctx);
* On successful return the caller can queue more run requests if needed, using
* the prepared context in run->ctx. The caller is responsible for unpreparing
* the context when no more conversion requests are needed.
+ *
+ * Returns: pointer to the created &struct ipu_image_convert_run that has
+ * been queued on success; an ERR_PTR(errno) on error.
*/
struct ipu_image_convert_run *
ipu_image_convert(struct ipu_soc *ipu, enum ipu_ic_task ic_task,
--
2.53.0
^ permalink raw reply related
* [PATCH] arm64: dts: allwinner: Cubie A5E: enable SPI flash
From: Andre Przywara @ 2026-05-11 22:17 UTC (permalink / raw)
To: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Chen-Yu Tsai,
Jernej Skrabec, Samuel Holland
Cc: devicetree, linux-arm-kernel, linux-sunxi
The Cubie A5E board comes with 16MiB of SPI NOR flash.
Enable the SPI0 DT node and describe the configuration.
Signed-off-by: Andre Przywara <andre.przywara@arm.com>
---
.../boot/dts/allwinner/sun55i-a527-cubie-a5e.dts | 15 +++++++++++++++
1 file changed, 15 insertions(+)
diff --git a/arch/arm64/boot/dts/allwinner/sun55i-a527-cubie-a5e.dts b/arch/arm64/boot/dts/allwinner/sun55i-a527-cubie-a5e.dts
index bfdf1728cd14b..7ad22fc85d1fd 100644
--- a/arch/arm64/boot/dts/allwinner/sun55i-a527-cubie-a5e.dts
+++ b/arch/arm64/boot/dts/allwinner/sun55i-a527-cubie-a5e.dts
@@ -344,6 +344,21 @@ &r_pio {
vcc-pm-supply = <®_aldo3>;
};
+&spi0 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&spi0_pc_pins>, <&spi0_cs0_pc_pin>,
+ <&spi0_hold_pc_pin>, <&spi0_wp_pc_pin>;
+ status = "okay";
+
+ flash@0 {
+ compatible = "winbond,w25q128", "jedec,spi-nor";
+ reg = <0>;
+ spi-max-frequency = <40000000>;
+ #address-cells = <1>;
+ #size-cells = <1>;
+ };
+};
+
&uart0 {
pinctrl-names = "default";
pinctrl-0 = <&uart0_pb_pins>;
--
2.46.4
^ permalink raw reply related
* Re: [PATCH 1/4] ARM: dts: imx6qdl-sabrelite: add mdio phy address 0
From: Andrew Lunn @ 2026-05-11 22:15 UTC (permalink / raw)
To: Frank Li
Cc: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Sascha Hauer,
Pengutronix Kernel Team, Fabio Estevam, devicetree, imx,
linux-arm-kernel, linux-kernel
In-Reply-To: <20260511-b4-imx25_dts_simple_warning-v1-1-01b855a5ce25@nxp.com>
On Mon, May 11, 2026 at 05:04:56PM -0400, Frank Li wrote:
> According to IEEE 802.3 Clause 22.2.4.5.5 PHYAD (PHY Address), A PHY that
> is connected to the station management entity via the mechanical interface
> defined in 22.6 shall always respond to transactions addressed to PHY
> Address zero <00000>.
Did you read 22.6? I've not seen a mechanical interface as defined in
22.6 for at least 20 years, maybe 30 years.
That cause does not apply in this context.
> - ethphy: ethernet-phy {
> + ethphy: ethernet-phy@0 {
> compatible = "ethernet-phy-ieee802.3-c22";
> + reg = <0>;
This could very well break this board. Without a reg value, the core
will find the first PHY on the bus, at whatever address it is at. If
you hard code 0, the PHY must be at 0, otherwise it will not be found.
Andrew
^ permalink raw reply
* [PATCH 1/1] dt-bindings: display: imx: add deprecated property 'port' and 'display-timings'
From: Frank Li @ 2026-05-11 22:09 UTC (permalink / raw)
To: Philipp Zabel, Maarten Lankhorst, Maxime Ripard,
Thomas Zimmermann, David Airlie, Simona Vetter, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Frank Li, Sascha Hauer,
Pengutronix Kernel Team, Fabio Estevam,
open list:DRM DRIVERS FOR FREESCALE IMX 5/6,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
open list:ARM/FREESCALE IMX / MXC ARM ARCHITECTURE,
moderated list:ARM/FREESCALE IMX / MXC ARM ARCHITECTURE,
open list
Cc: imx
Add deprecated property 'port' and 'display-timings' for i.MX5 SoCs (over
15 years) to fix below CHECK_DTBS warnings:
arm/boot/dts/nxp/imx/imx51-apf51dev.dtb: disp1 (fsl,imx-parallel-display): 'display-timings', 'port' do not match any of the regexes: '^pinctrl-[0-9]+$'
from schema $id: http://devicetree.org/schemas/display/imx/fsl,imx-parallel-display.yaml
Signed-off-by: Frank Li <Frank.Li@nxp.com>
---
.../display/imx/fsl,imx-parallel-display.yaml | 11 +++++++++++
1 file changed, 11 insertions(+)
diff --git a/Documentation/devicetree/bindings/display/imx/fsl,imx-parallel-display.yaml b/Documentation/devicetree/bindings/display/imx/fsl,imx-parallel-display.yaml
index bbcfe7e2958b7..b0c5869771fae 100644
--- a/Documentation/devicetree/bindings/display/imx/fsl,imx-parallel-display.yaml
+++ b/Documentation/devicetree/bindings/display/imx/fsl,imx-parallel-display.yaml
@@ -42,6 +42,17 @@ properties:
unevaluatedProperties: false
description: output port connected to a panel
+ port:
+ $ref: /schemas/graph.yaml#/properties/port
+ unevaluatedProperties: false
+ deprecated: true
+ description: input port connected to the IPU display interface, see port@0
+
+ display-timings:
+ $ref: /schemas/display/panel/display-timings.yaml#
+ unevaluatedProperties: false
+ deprecated: true
+
required:
- compatible
--
2.43.0
^ permalink raw reply related
* RE: [PATCH 2/3] perf/arm_cspmu: nvidia: handle empty resource list in PCIE-TGT init
From: Besar Wicaksono @ 2026-05-11 22:09 UTC (permalink / raw)
To: Saurav Sachidanand, Will Deacon
Cc: Mark Rutland, Ilkka Koskinen, Jon Hunter,
linux-arm-kernel@lists.infradead.org,
linux-perf-users@vger.kernel.org, linux-kernel@vger.kernel.org,
aghayev@amazon.com, juew@amazon.com
In-Reply-To: <20260511210905.91917-1-sauravsc@amazon.com>
> -----Original Message-----
> From: Saurav Sachidanand <sauravsc@amazon.com>
> Sent: Monday, May 11, 2026 4:09 PM
> To: Will Deacon <will@kernel.org>
> Cc: Mark Rutland <mark.rutland@arm.com>; Besar Wicaksono
> <bwicaksono@nvidia.com>; Ilkka Koskinen
> <ilkka@os.amperecomputing.com>; Jon Hunter <jonathanh@nvidia.com>;
> linux-arm-kernel@lists.infradead.org; linux-perf-users@vger.kernel.org; linux-
> kernel@vger.kernel.org; aghayev@amazon.com; juew@amazon.com; Saurav
> Sachidanand <sauravsc@amazon.com>
> Subject: [PATCH 2/3] perf/arm_cspmu: nvidia: handle empty resource list in
> PCIE-TGT init
>
> External email: Use caution opening links or attachments
>
>
> When acpi_dev_get_memory_resources() returns success but the resource
> list is empty (rentry is NULL), addr_filter_reg remains NULL from
> devm_kzalloc. Since IS_ERR(NULL) is false, the function proceeds
> without error and later dereferences the NULL pointer in
> pcie_tgt_pmu_config_addr_filter().
>
> Set addr_filter_reg to ERR_PTR(-ENODEV) when the resource list is
> empty so the existing IS_ERR check catches it.
>
> Fixes: 3dd73022306b ("perf/arm_cspmu: nvidia: Add Tegra410 PCIE-TGT
> PMU")
> Signed-off-by: Saurav Sachidanand <sauravsc@amazon.com>
> ---
> drivers/perf/arm_cspmu/nvidia_cspmu.c | 8 +++++---
> 1 file changed, 5 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/perf/arm_cspmu/nvidia_cspmu.c
> b/drivers/perf/arm_cspmu/nvidia_cspmu.c
> index bac83e424d6dc..bae722e263e91 100644
> --- a/drivers/perf/arm_cspmu/nvidia_cspmu.c
> +++ b/drivers/perf/arm_cspmu/nvidia_cspmu.c
> @@ -555,14 +555,16 @@ static int pcie_tgt_init_data(struct arm_cspmu
> *cspmu)
>
> rentry = list_first_entry_or_null(
> &resource_list, struct resource_entry, node);
> - if (rentry) {
> + if (rentry)
> data->addr_filter_reg = devm_ioremap_resource(dev, rentry->res);
> - ret = 0;
> - }
> + else
> + data->addr_filter_reg = ERR_PTR(-ENODEV);
>
> if (IS_ERR(data->addr_filter_reg)) {
> dev_err(dev, "failed to get address filter resource\n");
> ret = PTR_ERR(data->addr_filter_reg);
> + } else {
Thanks for fixing.
Reviewed-by: Besar Wicaksono <bwicaksono@nvidia.com>
> + ret = 0;
> }
>
> acpi_dev_free_resource_list(&resource_list);
> --
> 2.47.3
^ permalink raw reply
* RE: [PATCH 3/3] perf/arm_cspmu: nvidia: fix BDF calculation examples in PCIE PMU docs
From: Besar Wicaksono @ 2026-05-11 21:48 UTC (permalink / raw)
To: Saurav Sachidanand, Will Deacon
Cc: Mark Rutland, Ilkka Koskinen, Jon Hunter,
linux-arm-kernel@lists.infradead.org,
linux-perf-users@vger.kernel.org, linux-kernel@vger.kernel.org,
aghayev@amazon.com, juew@amazon.com
In-Reply-To: <20260511210905.91917-2-sauravsc@amazon.com>
> -----Original Message-----
> From: Saurav Sachidanand <sauravsc@amazon.com>
> Sent: Monday, May 11, 2026 4:09 PM
> To: Will Deacon <will@kernel.org>
> Cc: Mark Rutland <mark.rutland@arm.com>; Besar Wicaksono
> <bwicaksono@nvidia.com>; Ilkka Koskinen
> <ilkka@os.amperecomputing.com>; Jon Hunter <jonathanh@nvidia.com>;
> linux-arm-kernel@lists.infradead.org; linux-perf-users@vger.kernel.org; linux-
> kernel@vger.kernel.org; aghayev@amazon.com; juew@amazon.com; Saurav
> Sachidanand <sauravsc@amazon.com>
> Subject: [PATCH 3/3] perf/arm_cspmu: nvidia: fix BDF calculation examples in
> PCIE PMU docs
>
> External email: Use caution opening links or attachments
>
>
> The BDF hex values in the documentation examples are inconsistent with
> the stated formula (bus << 8) + (device << 3) + (function):
>
> - BDF 27:01.1: documented as 0x2781, correct value is 0x2709
> (0x27 << 8) + (0x01 << 3) + 0x1 = 0x2709
> - BDF 01:01.0: documented as 0x0180, correct value is 0x0108
> (0x01 << 8) + (0x01 << 3) + 0x0 = 0x0108
>
> It appears (device << 7) was used instead of (device << 3) when
> computing the example values.
>
> Fixes: bf585ba14726 ("perf/arm_cspmu: nvidia: Add Tegra410 PCIE PMU")
> Signed-off-by: Saurav Sachidanand <sauravsc@amazon.com>
Thanks for the fix.
Reviewed-by: Besar Wicaksono <bwicaksono@nvidia.com>
> ---
> Documentation/admin-guide/perf/nvidia-tegra410-pmu.rst | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/Documentation/admin-guide/perf/nvidia-tegra410-pmu.rst
> b/Documentation/admin-guide/perf/nvidia-tegra410-pmu.rst
> index 0656223b61d47..24f0e801d7b80 100644
> --- a/Documentation/admin-guide/perf/nvidia-tegra410-pmu.rst
> +++ b/Documentation/admin-guide/perf/nvidia-tegra410-pmu.rst
> @@ -170,7 +170,7 @@ The list of event filters:
> devices in root port 0 to 3.
> * src_bdf: the BDF that will be monitored. This is a 16-bit value that
> follows formula: (bus << 8) + (device << 3) + (function). For example, the
> - value of BDF 27:01.1 is 0x2781.
> + value of BDF 27:01.1 is 0x2709.
> * src_bdf_en: enable the BDF filter. If this is set, the BDF filter value in
> "src_bdf" is used to filter the traffic.
>
> @@ -215,7 +215,7 @@ Example usage:
> * Count event id 0x4 from BDF 01:01.0 of PCIE RC-4 on socket 0 targeting all
> destinations::
>
> - perf stat -a -e
> nvidia_pcie_pmu_0_rc_4/event=0x4,src_bdf=0x0180,src_bdf_en=0x1/
> + perf stat -a -e
> nvidia_pcie_pmu_0_rc_4/event=0x4,src_bdf=0x0108,src_bdf_en=0x1/
>
> .. _NVIDIA_T410_PCIE_PMU_RC_Mapping_Section:
>
> --
> 2.47.3
^ permalink raw reply
* Re: [PATCH v13 3/4] gpio: rpmsg: add generic rpmsg GPIO driver
From: Shah, Tanmay @ 2026-05-11 21:35 UTC (permalink / raw)
To: Mathieu Poirier, tanmay.shah
Cc: Arnaud POULIQUEN, Beleswar Prasad Padhi, Shenwei Wang,
Andrew Lunn, Linus Walleij, Bartosz Golaszewski, Jonathan Corbet,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, Bjorn Andersson,
Frank Li, Sascha Hauer, Shuah Khan, linux-gpio@vger.kernel.org,
linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org,
Pengutronix Kernel Team, Fabio Estevam, Peng Fan,
devicetree@vger.kernel.org, linux-remoteproc@vger.kernel.org,
imx@lists.linux.dev, linux-arm-kernel@lists.infradead.org,
dl-linux-imx, Bartosz Golaszewski
In-Reply-To: <CANLsYkz8HpM_8eS7DjN_jmYs4T7P9xY0jYmdiAx5WO=_1zvFpQ@mail.gmail.com>
On 5/11/2026 12:58 PM, Mathieu Poirier wrote:
> On Mon, 11 May 2026 at 10:47, Shah, Tanmay <tanmays@amd.com> wrote:
>>
>>
>>
>> On 5/5/2026 10:52 AM, Shah, Tanmay wrote:
>>>
>>>
>>> On 5/5/2026 4:28 AM, Arnaud POULIQUEN wrote:
>>>> Hi Tanmay,
>>>>
>>>> On 5/4/26 21:19, Shah, Tanmay wrote:
>>>>>
>>>>> Hello all,
>>>>>
>>>>> I have started reviewing this work as well.
>>>>> Thanks Shenwei for this work.
>>>>>
>>>>> I have gone through only the current revision, and would like to provide
>>>>> idea on how to achieve GPIO number multiplexing with the RPMsg protocol.
>>>>> Also, have some bindings related question.
>>>>>
>>>>> Please see below:
>>>>>
>>>>> On 4/30/2026 11:40 AM, Arnaud POULIQUEN wrote:
>>>>>>
>>>>>>
>>>>>> On 4/30/26 14:56, Beleswar Prasad Padhi wrote:
>>>>>>> Hello Arnaud,
>>>>>>>
>>>>>>> On 30/04/26 13:05, Arnaud POULIQUEN wrote:
>>>>>>>> Hello,
>>>>>>>>
>>>>>>>> On 4/29/26 21:20, Mathieu Poirier wrote:
>>>>>>>>> On Wed, 29 Apr 2026 at 12:07, Padhi, Beleswar <b-padhi@ti.com> wrote:
>>>>>>>>>>
>>>>>>>>>> Hi Mathieu,
>>>>>>>>>>
>>>>>>>>>> On 4/29/2026 11:03 PM, Mathieu Poirier wrote:
>>>>>>>>>>> On Wed, 29 Apr 2026 at 10:53, Shenwei Wang <shenwei.wang@nxp.com>
>>>>>>>>>>> wrote:
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>> -----Original Message-----
>>>>>>>>>>>>> From: Mathieu Poirier <mathieu.poirier@linaro.org>
>>>>>>>>>>>>> Sent: Wednesday, April 29, 2026 10:42 AM
>>>>>>>>>>>>> To: Shenwei Wang <shenwei.wang@nxp.com>
>>>>>>>>>>>>> Cc: Andrew Lunn <andrew@lunn.ch>; Padhi, Beleswar <b-
>>>>>>>>>>>>> padhi@ti.com>; Linus
>>>>>>>>>>>>> Walleij <linusw@kernel.org>; Bartosz Golaszewski
>>>>>>>>>>>>> <brgl@kernel.org>; Jonathan
>>>>>>>>>>>>> Corbet <corbet@lwn.net>; Rob Herring <robh@kernel.org>;
>>>>>>>>>>>>> Krzysztof Kozlowski
>>>>>>>>>>>>> <krzk+dt@kernel.org>; Conor Dooley <conor+dt@kernel.org>; Bjorn
>>>>>>>>>>>>> Andersson
>>>>>>>>>>>>> <andersson@kernel.org>; Frank Li <frank.li@nxp.com>; Sascha Hauer
>>>>>>>>>>>>> <s.hauer@pengutronix.de>; Shuah Khan
>>>>>>>>>>>>> <skhan@linuxfoundation.org>; linux-
>>>>>>>>>>>>> gpio@vger.kernel.org; linux-doc@vger.kernel.org; linux-
>>>>>>>>>>>>> kernel@vger.kernel.org;
>>>>>>>>>>>>> Pengutronix Kernel Team <kernel@pengutronix.de>; Fabio Estevam
>>>>>>>>>>>>> <festevam@gmail.com>; Peng Fan <peng.fan@nxp.com>;
>>>>>>>>>>>>> devicetree@vger.kernel.org; linux-remoteproc@vger.kernel.org;
>>>>>>>>>>>>> imx@lists.linux.dev; linux-arm-kernel@lists.infradead.org; dl-
>>>>>>>>>>>>> linux-imx <linux-
>>>>>>>>>>>>> imx@nxp.com>; Bartosz Golaszewski <brgl@bgdev.pl>
>>>>>>>>>>>>> Subject: [EXT] Re: [PATCH v13 3/4] gpio: rpmsg: add generic
>>>>>>>>>>>>> rpmsg GPIO driver
>>>>>>>>>>>>> On Tue, Apr 28, 2026 at 03:24:59PM +0000, Shenwei Wang wrote:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> -----Original Message-----
>>>>>>>>>>>>>>> From: Andrew Lunn <andrew@lunn.ch>
>>>>>>>>>>>>>>> Sent: Monday, April 27, 2026 3:49 PM
>>>>>>>>>>>>>>> To: Shenwei Wang <shenwei.wang@nxp.com>
>>>>>>>>>>>>>>> Cc: Padhi, Beleswar <b-padhi@ti.com>; Linus Walleij
>>>>>>>>>>>>>>> <linusw@kernel.org>; Bartosz Golaszewski <brgl@kernel.org>;
>>>>>>>>>>>>>>> Jonathan
>>>>>>>>>>>>>>> Corbet <corbet@lwn.net>; Rob Herring <robh@kernel.org>;
>>>>>>>>>>>>>>> Krzysztof
>>>>>>>>>>>>>>> Kozlowski <krzk+dt@kernel.org>; Conor Dooley
>>>>>>>>>>>>>>> <conor+dt@kernel.org>;
>>>>>>>>>>>>>>> Bjorn Andersson <andersson@kernel.org>; Mathieu Poirier
>>>>>>>>>>>>>>> <mathieu.poirier@linaro.org>; Frank Li <frank.li@nxp.com>;
>>>>>>>>>>>>>>> Sascha
>>>>>>>>>>>>>>> Hauer <s.hauer@pengutronix.de>; Shuah Khan
>>>>>>>>>>>>>>> <skhan@linuxfoundation.org>; linux-gpio@vger.kernel.org; linux-
>>>>>>>>>>>>>>> doc@vger.kernel.org; linux-kernel@vger.kernel.org; Pengutronix
>>>>>>>>>>>>>>> Kernel Team <kernel@pengutronix.de>; Fabio Estevam
>>>>>>>>>>>>>>> <festevam@gmail.com>; Peng Fan <peng.fan@nxp.com>;
>>>>>>>>>>>>>>> devicetree@vger.kernel.org; linux- remoteproc@vger.kernel.org;
>>>>>>>>>>>>>>> imx@lists.linux.dev; linux-arm- kernel@lists.infradead.org;
>>>>>>>>>>>>>>> dl-linux-imx <linux-imx@nxp.com>; Bartosz Golaszewski
>>>>>>>>>>>>>>> <brgl@bgdev.pl>
>>>>>>>>>>>>>>> Subject: [EXT] Re: [PATCH v13 3/4] gpio: rpmsg: add generic
>>>>>>>>>>>>>>> rpmsg
>>>>>>>>>>>>>>> GPIO driver
>>>>>>>>>>>>>>>>> struct virtio_gpio_response {
>>>>>>>>>>>>>>>>> __u8 status;
>>>>>>>>>>>>>>>>> __u8 value;
>>>>>>>>>>>>>>>>> };
>>>>>>>>>>>>>>>> It is the same message format. Please see the message
>>>>>>>>>>>>>>>> definition
>>>>>>>>>>>>>>> (GET_DIRECTION) below:
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> + +-----+-----+-----+-----+-----+----+
>>>>>>>>>>>>>>>> + |0x00 |0x01 |0x02 |0x03 |0x04 |0x05|
>>>>>>>>>>>>>>>> + | 1 | 2 |port |line | err | dir|
>>>>>>>>>>>>>>>> + +-----+-----+-----+-----+-----+----+
>>>>>>>>>>>>>>> Sorry, but i don't see how two u8 vs six u8 are the same
>>>>>>>>>>>>>>> message format.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Some changes to the message format are necessary.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Virtio uses two communication channels (virtqueues): one for
>>>>>>>>>>>>>> requests and
>>>>>>>>>>>>> replies, and a second one for events.
>>>>>>>>>>>>>> In contrast, rpmsg provides only a single communication
>>>>>>>>>>>>>> channel, so a
>>>>>>>>>>>>>> type field is required to distinguish between different kinds
>>>>>>>>>>>>>> of messages.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Since rpmsg replies and events share the same message format,
>>>>>>>>>>>>>> an additional
>>>>>>>>>>>>> line is introduced to handle both cases.
>>>>>>>>>>>>>> Finally, rpmsg supports multiple GPIO controllers, so a port
>>>>>>>>>>>>>> field is added to
>>>>>>>>>>>>> uniquely identify the target controller.
>>>>>>>>>>>>>
>>>>>>>>>>>>> I have commented on this before - RPMSG is already providing
>>>>>>>>>>>>> multiplexing
>>>>>>>>>>>>> capability by way of endpoints. There is no need for a port
>>>>>>>>>>>>> field. One endpoint,
>>>>>>>>>>>>> one GPIO controller.
>>>>>>>>>>>>>
>>>>>>>>>>>> You still need a way to let the remote side know which port the
>>>>>>>>>>>> endpoint maps to, either
>>>>>>>>>>>> by embedding the port information in the message (the current
>>>>>>>>>>>> way), or by sending it
>>>>>>>>>>>> separately.
>>>>>>>>>>>>
>>>>>>>>>>> An endpoint is created with every namespace request. There
>>>>>>>>>>> should be
>>>>>>>>>>> one namespace request for every GPIO controller, which yields a
>>>>>>>>>>> unique
>>>>>>>>>>> endpoint for each controller and eliminates the need for an extra
>>>>>>>>>>> field to identify them.
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> Right, but this can still be done by just having one namespace
>>>>>>>>>> request.
>>>>>>>>>> We can create new endpoints bound to an existing namespace/
>>>>>>>>>> channel by
>>>>>>>>>> invoking rpmsg_create_ept(). This is what I suggested here too:
>>>>>>>>>> https://lore.kernel.org/all/29485742-6e49-482e-
>>>>>>>>>> b73d-228295daaeec@ti.com/
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> I will look at your suggestion (i.e link above) later this week or
>>>>>>>>> next week.
>>>>>>>>>
>>>>>>>>>> My mental model looks like this for the complete picture:
>>>>>>>>>>
>>>>>>>>>> 1. namespace/channel#1 = rpmsg-io
>>>>>>>>>> a. ept1 -> gpio-controller@1
>>>>>>>>>> b. ept2 -> gpio-controller@2
>>>>>>>>>>
>>>>>
>>>>> If my understanding of what gpio-controller is right, than this won't
>>>>> work. We need one rpmsg channel per gpio-controller, and in most cases
>>>>> there will be only one GPIO-controller on the remote side. If there are
>>>>> multiple or multiple instances of same controller, than we need separate
>>>>> channel name for that controller just like we would have separate device
>>>>> on the Linux.
>>>>
>>>> As done in ehe rpmsg_tty driver it could be instantiated several times with
>>>> the same channel/service name. This would imply a specific rpmsg to
>>>> retreive
>>>> the gpio controller index from the remote side.
>>>>>
>>>>>>>>>
>>>>>>>>> I've asked for one endpoint per GPIO controller since the very
>>>>>>>>> beginning. I don't yet have a strong opinion on whether to use one
>>>>>>>>> namespace request per GPIO controller or a single request that spins
>>>>>>>>> off multiple endpoints. I'll have to look at your link and
>>>>>>>>> reflect on
>>>>>>>>> that. Regardless of how we proceed on that front, multiplexing needs
>>>>>>>>> to happen at the endpoint level rather than the packet level.
>>>>>>>>> This is
>>>>>>>>> the only way this work can move forward.
>>>>>>>>>
>>>>>>>>
>>>>>>>> I would be more in favor of Mathieu’s proposal: “An endpoint is
>>>>>>>> created with every namespace request.”
>>>>>>>>
>>>>>>>> If the endpoint is created only on the Linux side, how do we match
>>>>>>>> the Linux endpoint address with the local port field on the remote
>>>>>>>> side?
>>>>>>>
>>>>>>>
>>>>>>> Simply by sending a message to the remote containing the newly created
>>>>>>> endpoint and the port idx. Note that is this done just one time, after
>>>>>>> this
>>>>>>> Linux need not have the port field in the message everytime its sending
>>>>>>> a message.
>>>>>>>
>>>>>>>>
>>>>>>>> With a multi-namespace approach, the namespace could be rpmsg-io-
>>>>>>>> [addr], where [addr] corresponds to the GPIO controller address in
>>>>>>>> the DT. This would:
>>>>>>>
>>>>>>>
>>>>>>> You will face the same problem in this case also that you asked above:
>>>>>>> "how do we match the Linux endpoint address with the local port field
>>>>>>> on the remote side?"
>>>>>>
>>>>>> Sorry I probably introduced confusion here
>>>>>> my sentence should be;
>>>>>> With a multi-namespace approach, the namespace could be rpmsg-io-
>>>>>> [port],
>>>>>> where [port] corresponds to the GPIO controller port in the DT.
>>>>>>
>>>>>>
>>>>>> For instance:
>>>>>>
>>>>>> rpmsg {
>>>>>> rpmsg-io {
>>>>>> #address-cells = <1>;
>>>>>> #size-cells = <0>;
>>>>>>
>>>>>> gpio@25 {
>>>>>> compatible = "rpmsg-gpio";
>>>>>> reg = <25>;
>>>>>> gpio-controller;
>>>>>> #gpio-cells = <2>;
>>>>>> #interrupt-cells = <2>;
>>>>>> interrupt-controller;
>>>>>> };
>>>>>>
>>>>>> gpio@32 {
>>>>>> compatible = "rpmsg-gpio";
>>>>>> reg = <32>;
>>>>>> gpio-controller;
>>>>>> #gpio-cells = <2>;
>>>>>> #interrupt-cells = <2>;
>>>>>> interrupt-controller;
>>>>>> };
>>>>>> };
>>>>>> };
>>>>>>
>>>>>> rpmsg-io-25 would match with gpio@25
>>>>>> rpmsg-io-32 would match with gpio@32
>>>>>>
>>>>>
>>>>> The problem with this approach is, we will endup creating way too many
>>>>> RPMsg devices/channels. i.e. one channel per one GPIO. That limits how
>>>>> many GPIOs can be handled by remote from memory perspective. At
>>>>> somepoint we might just run-out of number ept & channels created by the
>>>>> remote. As of now, open-amp library supports 128 epts I think.
>>>>
>>>> Right, I proposed a solution in my previous answer to Beleswar who has
>>>> the same concern.
>>>>
>>>>>
>>>>>>
>>>>>>>
>>>>>>> Because the endpoint that is created on a namespace request is also
>>>>>>> dynamic in nature. How will the remote know which endpoint addr
>>>>>>> Linux allocated for a namespace that it announced?
>>>>>>>
>>>>>>> As an example/PoC, I created a firmware example which announces
>>>>>>> 2 name services to Linux, one is the standard "rpmsg_chrdev" and
>>>>>>> the other is a TI specific name service "ti.ipc4.ping-pong". You can
>>>>>>> see it created 2 different addresses (0x400 and 0x401) for each of
>>>>>>> the name service request from the same firmware:
>>>>>>>
>>>>>>> root@j784s4-evm:~# dmesg | grep virtio0 | grep -i channel
>>>>>>> [ 9.290275] virtio_rpmsg_bus virtio0: creating channel
>>>>>>> ti.ipc4.ping-pong addr 0xd
>>>>>>> [ 9.311230] virtio_rpmsg_bus virtio0: creating channel rpmsg_chrdev
>>>>>>> addr 0xe
>>>>>>> [ 9.496645] rpmsg_chrdev virtio0.rpmsg_chrdev.-1.14: DEBUG: Channel
>>>>>>> formed from src = 0x400 to dst = 0xe
>>>>>>> [ 9.707255] rpmsg_client_sample virtio0.ti.ipc4.ping-pong.-1.13:
>>>>>>> new channel: 0x401 -> 0xd!
>>>>>>>
>>>>>>> So in this case, rpmsg-io-1 can have different ept addr than rpmsg-io-2
>>>>>>> Back to same problem. Simple solution is to reply to remote with the
>>>>>>> created ept addr and the index.
>>>>>>
>>>>>> That why I would like to suggest to use the name service field to
>>>>>> identify the port/controller, instead of the endpoint address.
>>>>>>>
>>>>>>>>
>>>>>>>> - match the RPMsg probe with the DT,
>>>>>>>
>>>>>>>
>>>>>>> We can probe from all controllers with a single name service
>>>>>>> announcement too.
>>>>>>>
>>>>>>>> - provide a simple mapping between the port and the endpoint on both
>>>>>>>> sides,
>>>>>>>
>>>>>>>
>>>>>>> We are trying to get rid of this mapping from Linux side to adapt
>>>>>>> the gpio-virtio design.
>>>>>>>
>>>>>>>> - allow multiple endpoints on the remote side,
>>>>>>>
>>>>>>>
>>>>>>> We can support this as well with single nameservice model.
>>>>>>> There is no limitation. Remote has to send a message with
>>>>>>> its newly created ept that's all.
>>>>>>>
>>>>>>>> - provide a simple discovery mechanism for remote capabilities.
>>>>>>>
>>>>>>>
>>>>>>> A single announcement: "rpmsg-io" is also discovery mechanism.
>>>>>>>
>>>>>>> Feel free to let me know if you have concerns with any of the
>>>>>>> suggestions!
>>>>>>
>>>>>> My only concern, whatever the solution, is that we find a smart
>>>>>> solution to associate the correct endpoint with the correct GPIO
>>>>>> port/controller defined in the DT.
>>>>>>
>>>>>> I may have misunderstood your solution. Could you please help me
>>>>>> understand your proposal by explaining how you would handle three
>>>>>> GPIO ports defined in the DT, considering that the endpoint
>>>>>> addresses on the Linux side can be random?
>>>>>> If I assume there is a unique endpoint on the remote side,
>>>>>> I do not understand how you can match, on the firmware side,
>>>>>> the Linux endpoint address to the GPIO port.
>>>>>>
>>>>>> Thanks and Regards,Arnaud
>>>>>>
>>>>>>>
>>>>>>> Thanks,
>>>>>>> Beleswar
>>>>>>>
>>>>>>>>
>>>>>>>> Regards,
>>>>>>>> Arnaud
>>>>>>>>
>>>>>>>>>> 2. namespace/channel#2 = rpmsg-i2c
>>>>>>>>>> a. ept1 -> i2c@1
>>>>>>>>>> b. ept2 -> i2c@2
>>>>>>>>>> c. ept3 -> i2c@3
>>>>>>>>>>
>>>>>>>>>> etc...
>>>>>>>>>>
>>>>>
>>>>> Just want to clear-up few terms before I jump to the solution:
>>>>>
>>>>> **RPMsg channel/device**:
>>>>> - These are devices announced by the remote processor, and created by
>>>>> linux. They are created at: /sys/bus/rpmsg/devices
>>>>> - The channel format: <name>.<src ept>.<dst ept>
>>>>>
>>>>> **RPMsg endpoint**:
>>>>> - Endpoint is differnt than channel. Single channel can have multiple
>>>>> endpoints, and represented in the linux with: /dev/rpmsg? devices.
>>>>>
>>>>> To create endpoint device, we have rpmsg_create_ept API, which takes
>>>>> channel information as input, which has src-ept, dst-ept.
>>>>>
>>>>> Following is proposed solution:
>>>>>
>>>>> 1) Assign RPMsg channel/device per rpmsg-gpio controller (Not per GPIO
>>>>> pin/port).
>>>>> - In our case that would be, single rpmsg-io node. (That makes me
>>>>> question if bindings are correct or not).
>>>>>
>>>>> 2) Assign GPIO number as src ept.
>>>>>
>>>>> i.e. *rpmsg-io.<GPIO number>.<dst ept>*. Do not randomly assign src
>>>>> endpoint.
>>>>>
>>>>> Now, RPMSG channel by spec reserves first 1024 endpoints [1], so we can
>>>>> add 1024 offset to the GPIO number:
>>>>>
>>>>> so, when calling rpmsg_create_ept() API, we assing src_endpoint as:
>>>>> (GPIO_NUMBER + RPMSG_RESERVED_ADDRESSES)
>>>>>
>>>>> Now on the remote side, there is single channel and only single-endpoint
>>>>> is needed that is mapped to the rpmsg-io channel callback.
>>>>>
>>>>> That callback will receive all the payloads from the Linux, which will
>>>>> have src-ept i.e. (RPMSG_RESERVED_ADDRESSES + GPIO_NUMBER).
>>>>
>>>>
>>>> Interesting approach. I also tried to find a similar solution.
>>>>
>>>> The question here is: how can we guarantee continuous addresses? Given
>>>> the static and dynamic allocation of endpoint addresses that are
>>>> implemented, my conclusion was that it is not reliable enough.
>>>>
>>>> but perhaps I missed something...
>>>>
>>>>>
>>>>> It can retrieve GPIO_NUMBER easily, and convert to appropriate pin based
>>>>> on platform specific logic.
>>>>>
>>>>> This doesn't need PORT information at all. Also it makes sure that
>>>>> remote is using only single-endpoint so not much memory is used.
>>>>>
>>>>> *Example*:
>>>>> If only rpmsg-gpio channel is created by the remote side, than following
>>>>> is the representation of the devices when GPIO 25, 26, 27 is assigned to
>>>>> the rpmsg-io controller:
>>>>>
>>>>> Linux Remote
>>>>>
>>>>> rpmsg-channel: rpmsg-gpio.0x400.0x400
>>>>>
>>>>> /dev/rpmsg0 - GPIO25 ept (rpmsg-gpio.0x419.0x400)-|
>>>>> |
>>>>> /dev/rpmsg1 - GPIO26 ept (rpmsg-gpio.0x41a.0x400)-|-> rpmsg-gpio.*.0x400
>>>>> |
>>>>> /dev/rpmsg2 - GPIO27 ept (rpmsg-gpio.0x41b.0x400)-| 0x400 ept callback.
>>>>>
>>>>>
>>>>> *On remote side*:
>>>>>
>>>>> ept_0x400_callback(..., int src_ept, ...,)
>>>>> {
>>>>> int gpio_num = src_ept - RPMSG_RESERVED_ADDRESSES;
>>>>> // platform specific logic to convert gpio num to proper pin,
>>>>> // just like you would convert gpio num to pin on a linux gpio
>>>>> controller.
>>>>> }
>>>>>
>>>>> My question on the binding:
>>>>>
>>>>> Why each GPIO is represented with the separate node? I think rpmsg-gpio
>>>>> can be represented just any other GPIO controller? Please let me know if
>>>>> I am missing something. So rpmsg channel/rpmsg device is not created per
>>>>> GPIO, but per controller. GPIO number multiplexing should be done with
>>>>> rpmsg src ept, that removes the need of having each GPIO as a separate
>>>>> node.
>>>>>
>>>>>
>>>>> rpmsg_gpio: rpmsg-gpio@0 {
>>>>> compatible = "rpmsg-gpio";
>>>>> reg = <0>;
>>>>> gpio-controller;
>>>>> #gpio-cells = <2>;
>>>>> #interrupt-cells = <2>;
>>>>> interrupt-controller;
>>>>> };
>>>>>
>>>>> Then in DT, use like regular GPIO, but with the rpmsg-gpio controller:
>>>>>
>>>>> rpmsg-gpios = <&rpmsg_gpio (GPIO NUM) (flags)>;
>>>>>
>>>>> If the intent to create separate gpio nodes was only for the channel
>>>>> creation, then it's not really needed.
>>>>>
>>>>> [1]
>>>>> https://github.com/torvalds/linux/
>>>>> blob/6d35786de28116ecf78797a62b84e6bf3c45aa5a/drivers/rpmsg/
>>>>> virtio_rpmsg_bus.c#L136
>>>>>
>>>>
>>>> It is already the case. bindings declare GPIO controllers, not directly
>>>> GPIOs in:
>>>>
>>>> [PATCH v13 2/4] dt-bindings: remoteproc: imx_rproc: Add "rpmsg" subnode
>>>> support
>>>>
>>>> The discussion is around having an unique RPmsg endpoint for all
>>>> GPIO controller or one RPmsg endpoint per GPIO controller.
>>>>
>>>
>>> Endpoint where remote side or linux side?
>>>
>>> If unique endpoint on remote side per gpio controller then it makes sense.
>>>
>>> Unique endpoint on linux side doesn't make sense. Instead, unique
>>> channel per gpio controller makes sense, and each channel will have
>>> multiple endpoints on linux side. As I replied to Beleswar on the other
>>> email, I will copy past my answer here too:
>>>
>>>
>>> To be more specific:
>>>
>>> Linux: remote:
>>>
>>> ch1: rpmsg-gpio.-1.1024 -> gpio-controller@1024
>>> - gpio-line ept1
>>> - gpio-line ept2 -> They all map to same callback_ept_1024.
>>> - gpio-line ept3
>>>
>>> ch2: rpmsg-gpio.-1.1025 -> gpio-controller@1025
>>> - gpio-line ept1
>>> - gpio-line ept2 -> They all map to same callback_ept_1025.
>>> - gpio-line ept3
>>>
>>
>>
>> Hi Mathieu,
>>
>> So upon more brain storming in this approach I found limitation:
>>
>> This approach won't work if host OS is any other OS but Linux. For
>> example, if the remote OS is zephyr/baremetal using open-amp, then Only
>> Linux <-> zephyr combination will work, and we won't be able to re-use
>> this approach for zephyr <-> zephyr use case. The concept of rpmsg
>> channel/device exist only in the linux kernel implementation. This
>> brings another question: Should the protocol we decide work on other use
>> cases as well? Or Linux must be the Host OS for this protocol ?
>>
>
> Linux and Zephyr are very distinct OS, each with their own subsystems
> and characteristics. The design we choose here involves RPMSG and,
> inherently, Linux. We can't make decisions based on what may
> potentially happen in Zephyr.
>
>>
>> I think your & Arnaud's proposed approach of single endpoint per
>> gpio-controller on both side makes more sense, as it will work
>> regardless of any OS on host or remote side.
>>
>
> Arnaud, Beleswar, Andrew and I are all advocating for one endpoint per
> GPIO controller. The remaining issue it about the best way to work
> out source and destination addresses between Linux and the remote
> processor. I'm running out of time for today but I'll return to this
> thread with a final analysis by the end of the week.
>
Okay. Then that means multiple endpoints on Linux side can be considered.
If we decide to go single-endpoint per device on both side, then for
that here is the proposal to represent src ept and dst ept:
When we represent any device under rpmsg bus node, I think it should be
considered remote's view of the adddress space. So ideally we can
convert it to Linux view of the address space, via 'ranges' property.
So bindings should include 'ranges' property in the parent node. Then
linux view of the start address becomes src ept, and remote view of the
start address becomes dest ept. The remote view of the start address is
expected to be the static src endpoint on the remote side.
Following representation of the rpmsg devices (gpio, i2c, spi or any other):
rpmsg {
#address-cells = <1>;
#size-cells = <1>;
rpmsg-io {
compatible = "rpmsg-io-bus";
ranges = <remote_view_addr(dst ept) linux_view_addr(src ept) size>;
#address-cells = <1>;
#size-cells = <1>;
gpio@remote_view_addr(or dst ept) {
compatible = "rpmsg-io";
reg = <remote_view_addr addr_space_size>;
gpio-controller;
#gpio-cells = <2>;
interrupt-controller;
#interrupt-cells = <2>;
};
...
};
};
Example device-tree:
rpmsg {
#address-cells = <1>;
#size-cells = <1>;
rpmsg-io {
compatible = "rpmsg-io-bus";
ranges = <0x10000 0x50000 0x1000>,
<0x20000 0x60000 0x1000>;
#address-cells = <1>;
#size-cells = <1>;
gpio@10000 {
compatible = "rpmsg-io";
reg = <0x10000 0x1000>;
gpio-controller;
#gpio-cells = <2>;
interrupt-controller;
#interrupt-cells = <2>;
};
gpio@20000 {
compatible = "rpmsg-io";
reg = <0x20000 0x1000>;
gpio-controller;
#gpio-cells = <2>;
interrupt-controller;
#interrupt-cells = <2>;
};
};
};
Thanks,
Tanmay
>> To be more specific this will look like following:
>>
>> Host (Linux) Remote (baremetal/RTOS)
>>
>> rpmsg ch/device 1:
>> - rpmsg ept 1 <------> rpmsg ept 1 gpio-controller 0
>>
>> rpmsg ch/device 2:
>> - rpmsg ept 2 <------> rpmsg ept 2 gpio-controller 1
>>
>>
>> The question is, how to decide src ept, and dest ept on both sides?
>> I still think it should be static endpoints.
>>
>> I will get back with more reasoning on that.
>>
>>> On the remote side, we have to hardcode Which rpmsg controller is mapped
>>> to which endpoint.
>>>
>>>> Or did I misunderstand your questions?
>>>>
>>>> Thanks,
>>>> Arnaud
>>>>
>>>
>>>
>>> I gave this patch more time yesterday, and I think the 'reg' property
>>> should represent remote endpoint, instead of the gpio-controller index.
>>>
>>> So in this approach remote implementation is expected to provide
>>> hard-coded (static) endpoints for each gpio-controller instance, and
>>> that same number should be represented with the 'reg' property.
>>>
>>> On remote side:
>>>
>>> #define RPMSG_GPIO_0_CONTROLLER_EPT (RPMSG_RESERVED_ADDRESSES + 1) // 1024
>>>
>>> ept_1024_callback() {
>>>
>>> // handle appropriate gpio port ()
>>>
>>> }
>>>
>>> On linux side:
>>>
>>> So new representation of controller:
>>>
>>> rpmsg_gpio_0: gpio@1024 {
>>> compatible = "rpmsg-gpio";
>>> reg = <1024>;
>>> gpio-controller;
>>> #gpio-cells = <2>;
>>> #interrupt-cells = <2>;
>>> interrupt-controller;
>>> };
>>>
>>> rpmsg_gpio_1: gpio@1025 {
>>> compatible = "rpmsg-gpio";
>>> reg = <1025>;
>>> gpio-controller;
>>> #gpio-cells = <2>;
>>> #interrupt-cells = <2>;
>>> interrupt-controller;
>>> };
>>>
>>> gpios = <&rpmsg_gpio_0 (GPIO NUM or PIN) flags>,
>>> <&rpmsg_gpio_1 (GPIO NUM or PIN) flags>;
>>>
>>> Now in the linux driver:
>>>
>>> You can easily retrieve destination endpoint when we want to send the
>>> command to the gpio controller via device's "reg" property.
>>>
>>> This approach also provides built-in security as well. Because now
>>> gpio-controller instance is hardcoded with the endpoint callback, it
>>> can't be modified/addressed without changing the 'reg' property.
>>>
>>> Just like you wouldn't change device address for the instance of the
>>> gpio-controller right?
>>>
>>> This approach can be easily adapted to all the other rpmsg controllers
>>> as well.
>>>
>>> So, dynamic endpoint allocation doesn't make sense in this case. Dynamic
>>> endpoint allocation makes more sense for user-space apps which don't
>>> really care about endpoints and only payloads.
>>>
>>> But, here we are multiplexing device-addresses with endpoints, and so it
>>> has to be fixed, and presented via 'reg' property. So, firmware can't
>>> change device-address without Linux knowing it.
>>>
>>> Thanks,
>>> Tanmay
>>>
>>>
>>>>
>>>>>>>>>> This way device groups are isolated with each channel/namespace, and
>>>>>>>>>> instances within each device groups are also respected with specific
>>>>>>>>>> endpoints.
>>>>>>>>>>
>>>>>>>>>> Thanks,
>>>>>>>>>> Beleswar
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
^ permalink raw reply
* Re: [PATCH RFC v2 1/4] dt-bindings: clk: zte: Add zx297520v3 clock and reset bindings.
From: Stefan Dösinger @ 2026-05-11 21:33 UTC (permalink / raw)
To: Conor Dooley
Cc: Michael Turquette, Stephen Boyd, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Philipp Zabel, linux-clk, devicetree, linux-kernel,
linux-arm-kernel
In-Reply-To: <20260511-backstage-crewman-e44947ab6cfc@spud>
[-- Attachment #1: Type: text/plain, Size: 1602 bytes --]
Hi Conor,
Thanks for your reply!
> Am 11.05.2026 um 19:07 schrieb Conor Dooley <conor@kernel.org>:
>
> How come the "matrixclk" has no constraints on clock properties?
Because I am not sure what the correct/preferred way to express the interface between top and matrix is - see the first question raised in my cover letter.
In short, matrix potentially consumes all clocks available on the top controller. There is no obvious interface between them, like there is between matrix and LSP. So I see two ways to handle this in the bindings:
1) List the top clk inputs, top clk PLL outputs and PLL fractionals as matrix input
2) Be quiet about it
It'd be about 20 clocks or so that I know are consumed. The bigger issue than the number of clocks is that my knowledge of the board is from reverse engineering, not proper datasheets, so I might find out that a clock is missing or wrong.
> Although, these two devices seem too different to be in the same
> dt-binding. Do they have anyhting in common other than the SoC they are
> part of?
No, they don't have anything in common, other than that their concerns are poorly separated in hardware.
I take it from your question that the preferred way is to have separate bindings for them in this case - I guess separate headers as well as separate yaml files. Is this correct?
The third clock controller - LSP - is nicely separated from the other two. I would not be surprised to see this subsystem of the board show up on a different ZTE board. If top and matrix should have different bindings, LSP certainly should as well.
[-- Attachment #2: Message signed with OpenPGP --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply
* [PATCH 4/4] remoteproc: switch drivers to optional resource-table helper
From: Ben Levinsky @ 2026-05-11 21:18 UTC (permalink / raw)
To: Bjorn Andersson, Mathieu Poirier, linux-remoteproc
Cc: Frank Li, Sascha Hauer, Pengutronix Kernel Team, Fabio Estevam,
Geert Uytterhoeven, Magnus Damm, Patrice Chotard, Maxime Coquelin,
Alexandre Torgue, imx, linux-arm-kernel, linux-kernel,
linux-renesas-soc, linux-stm32, tanmay.shah
In-Reply-To: <20260511211841.284809-1-ben.levinsky@amd.com>
Use the shared optional resource-table helper in the remoteproc
drivers that currently ignore a missing table. This keeps the missing
resource-table case non-fatal while letting other parsing failures
propagate to the caller.
Signed-off-by: Ben Levinsky <ben.levinsky@amd.com>
---
drivers/remoteproc/imx_dsp_rproc.c | 10 +--------
drivers/remoteproc/imx_rproc.c | 13 +----------
drivers/remoteproc/rcar_rproc.c | 13 +----------
drivers/remoteproc/stm32_rproc.c | 10 +--------
drivers/remoteproc/xlnx_r5_remoteproc.c | 29 +------------------------
5 files changed, 5 insertions(+), 70 deletions(-)
diff --git a/drivers/remoteproc/imx_dsp_rproc.c b/drivers/remoteproc/imx_dsp_rproc.c
index 2d9f14fbef1d..3e96e7978cd2 100644
--- a/drivers/remoteproc/imx_dsp_rproc.c
+++ b/drivers/remoteproc/imx_dsp_rproc.c
@@ -954,14 +954,6 @@ static int imx_dsp_rproc_elf_load_segments(struct rproc *rproc, const struct fir
return ret;
}
-static int imx_dsp_rproc_parse_fw(struct rproc *rproc, const struct firmware *fw)
-{
- if (rproc_elf_load_rsc_table(rproc, fw))
- dev_warn(&rproc->dev, "no resource table found for this firmware\n");
-
- return 0;
-}
-
static int imx_dsp_rproc_load(struct rproc *rproc, const struct firmware *fw)
{
struct imx_dsp_rproc *priv = rproc->priv;
@@ -997,7 +989,7 @@ static const struct rproc_ops imx_dsp_rproc_ops = {
.stop = imx_dsp_rproc_stop,
.kick = imx_dsp_rproc_kick,
.load = imx_dsp_rproc_load,
- .parse_fw = imx_dsp_rproc_parse_fw,
+ .parse_fw = rproc_elf_load_rsc_table_optional,
.handle_rsc = imx_dsp_rproc_handle_rsc,
.find_loaded_rsc_table = rproc_elf_find_loaded_rsc_table,
.sanity_check = rproc_elf_sanity_check,
diff --git a/drivers/remoteproc/imx_rproc.c b/drivers/remoteproc/imx_rproc.c
index 6249815b54d8..5509048f7e19 100644
--- a/drivers/remoteproc/imx_rproc.c
+++ b/drivers/remoteproc/imx_rproc.c
@@ -680,17 +680,6 @@ static int imx_rproc_prepare(struct rproc *rproc)
return 0;
}
-static int imx_rproc_parse_fw(struct rproc *rproc, const struct firmware *fw)
-{
- int ret;
-
- ret = rproc_elf_load_rsc_table(rproc, fw);
- if (ret)
- dev_info(&rproc->dev, "No resource table in elf\n");
-
- return 0;
-}
-
static void imx_rproc_kick(struct rproc *rproc, int vqid)
{
struct imx_rproc *priv = rproc->priv;
@@ -777,7 +766,7 @@ static const struct rproc_ops imx_rproc_ops = {
.kick = imx_rproc_kick,
.da_to_va = imx_rproc_da_to_va,
.load = rproc_elf_load_segments,
- .parse_fw = imx_rproc_parse_fw,
+ .parse_fw = rproc_elf_load_rsc_table_optional,
.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,
diff --git a/drivers/remoteproc/rcar_rproc.c b/drivers/remoteproc/rcar_rproc.c
index e3121fadd292..7adaa6d37b82 100644
--- a/drivers/remoteproc/rcar_rproc.c
+++ b/drivers/remoteproc/rcar_rproc.c
@@ -55,17 +55,6 @@ static int rcar_rproc_prepare(struct rproc *rproc)
}
}
-static int rcar_rproc_parse_fw(struct rproc *rproc, const struct firmware *fw)
-{
- int ret;
-
- ret = rproc_elf_load_rsc_table(rproc, fw);
- if (ret)
- dev_info(&rproc->dev, "No resource table in elf\n");
-
- return 0;
-}
-
static int rcar_rproc_start(struct rproc *rproc)
{
struct rcar_rproc *priv = rproc->priv;
@@ -104,7 +93,7 @@ static struct rproc_ops rcar_rproc_ops = {
.start = rcar_rproc_start,
.stop = rcar_rproc_stop,
.load = rproc_elf_load_segments,
- .parse_fw = rcar_rproc_parse_fw,
+ .parse_fw = rproc_elf_load_rsc_table_optional,
.find_loaded_rsc_table = rproc_elf_find_loaded_rsc_table,
.sanity_check = rproc_elf_sanity_check,
.get_boot_addr = rproc_elf_get_boot_addr,
diff --git a/drivers/remoteproc/stm32_rproc.c b/drivers/remoteproc/stm32_rproc.c
index 7ac8265b60ac..007175dcd7af 100644
--- a/drivers/remoteproc/stm32_rproc.c
+++ b/drivers/remoteproc/stm32_rproc.c
@@ -232,14 +232,6 @@ static int stm32_rproc_prepare(struct rproc *rproc)
}
}
-static int stm32_rproc_parse_fw(struct rproc *rproc, const struct firmware *fw)
-{
- if (rproc_elf_load_rsc_table(rproc, fw))
- dev_warn(&rproc->dev, "no resource table found for this firmware\n");
-
- return 0;
-}
-
static irqreturn_t stm32_rproc_wdg(int irq, void *data)
{
struct platform_device *pdev = data;
@@ -631,7 +623,7 @@ static const struct rproc_ops st_rproc_ops = {
.detach = stm32_rproc_detach,
.kick = stm32_rproc_kick,
.load = rproc_elf_load_segments,
- .parse_fw = stm32_rproc_parse_fw,
+ .parse_fw = rproc_elf_load_rsc_table_optional,
.find_loaded_rsc_table = rproc_elf_find_loaded_rsc_table,
.get_loaded_rsc_table = stm32_rproc_get_loaded_rsc_table,
.sanity_check = rproc_elf_sanity_check,
diff --git a/drivers/remoteproc/xlnx_r5_remoteproc.c b/drivers/remoteproc/xlnx_r5_remoteproc.c
index e5d1903c9636..92c1f8972551 100644
--- a/drivers/remoteproc/xlnx_r5_remoteproc.c
+++ b/drivers/remoteproc/xlnx_r5_remoteproc.c
@@ -664,33 +664,6 @@ static int add_tcm_banks(struct rproc *rproc)
return ret;
}
-/*
- * zynqmp_r5_parse_fw()
- * @rproc: single R5 core's corresponding rproc instance
- * @fw: ptr to firmware to be loaded onto r5 core
- *
- * get resource table if available
- *
- * return 0 on success, otherwise non-zero value on failure
- */
-static int zynqmp_r5_parse_fw(struct rproc *rproc, const struct firmware *fw)
-{
- int ret;
-
- ret = rproc_elf_load_rsc_table(rproc, fw);
- if (ret == -EINVAL) {
- /*
- * resource table only required for IPC.
- * if not present, this is not necessarily an error;
- * for example, loading r5 hello world application
- * so simply inform user and keep going.
- */
- dev_info(&rproc->dev, "no resource table found.\n");
- ret = 0;
- }
- return ret;
-}
-
/**
* zynqmp_r5_rproc_prepare() - prepare core to boot/attach
* adds carveouts for TCM bank and reserved memory regions
@@ -849,7 +822,7 @@ static const struct rproc_ops zynqmp_r5_rproc_ops = {
.start = zynqmp_r5_rproc_start,
.stop = zynqmp_r5_rproc_stop,
.load = rproc_elf_load_segments,
- .parse_fw = zynqmp_r5_parse_fw,
+ .parse_fw = rproc_elf_load_rsc_table_optional,
.find_loaded_rsc_table = rproc_elf_find_loaded_rsc_table,
.sanity_check = rproc_elf_sanity_check,
.get_boot_addr = rproc_elf_get_boot_addr,
--
2.34.1
^ permalink raw reply related
* [PATCH 3/4] remoteproc: add helper for optional ELF resource tables
From: Ben Levinsky @ 2026-05-11 21:18 UTC (permalink / raw)
To: Bjorn Andersson, Mathieu Poirier, linux-remoteproc
Cc: Frank Li, Sascha Hauer, Pengutronix Kernel Team, Fabio Estevam,
Geert Uytterhoeven, Magnus Damm, Patrice Chotard, Maxime Coquelin,
Alexandre Torgue, imx, linux-arm-kernel, linux-kernel,
linux-renesas-soc, linux-stm32, tanmay.shah
In-Reply-To: <20260511211841.284809-1-ben.levinsky@amd.com>
Add a small helper around rproc_elf_load_rsc_table() for remoteproc
drivers that treat a missing ELF resource table as optional. The helper
returns success on -EINVAL and propagates other failures unchanged.
Signed-off-by: Ben Levinsky <ben.levinsky@amd.com>
---
drivers/remoteproc/remoteproc_internal.h | 12 ++++++++++++
1 file changed, 12 insertions(+)
diff --git a/drivers/remoteproc/remoteproc_internal.h b/drivers/remoteproc/remoteproc_internal.h
index 3724a47a9748..dff87e468837 100644
--- a/drivers/remoteproc/remoteproc_internal.h
+++ b/drivers/remoteproc/remoteproc_internal.h
@@ -146,6 +146,18 @@ static inline int rproc_mem_entry_iounmap(struct rproc *rproc,
return 0;
}
+static inline int rproc_elf_load_rsc_table_optional(struct rproc *rproc,
+ const struct firmware *fw)
+{
+ int ret;
+
+ ret = rproc_elf_load_rsc_table(rproc, fw);
+ if (ret == -EINVAL)
+ dev_dbg(&rproc->dev, "no resource table found\n");
+
+ return ret == -EINVAL ? 0 : ret;
+}
+
static inline int rproc_prepare_device(struct rproc *rproc)
{
if (rproc->ops->prepare)
--
2.34.1
^ permalink raw reply related
* [PATCH 2/4] remoteproc: switch exact-match drivers to wc-ioremap callbacks
From: Ben Levinsky @ 2026-05-11 21:18 UTC (permalink / raw)
To: Bjorn Andersson, Mathieu Poirier, linux-remoteproc
Cc: Frank Li, Sascha Hauer, Pengutronix Kernel Team, Fabio Estevam,
Geert Uytterhoeven, Magnus Damm, Patrice Chotard, Maxime Coquelin,
Alexandre Torgue, imx, linux-arm-kernel, linux-kernel,
linux-renesas-soc, linux-stm32, tanmay.shah
In-Reply-To: <20260511211841.284809-1-ben.levinsky@amd.com>
Replace the exact-match carveout map and unmap callbacks in the
existing remoteproc drivers with the common wc-ioremap helpers. Leave
the zynqmp R5 TCM callbacks alone because they also clear the mapped
memory and are not exact matches.
Signed-off-by: Ben Levinsky <ben.levinsky@amd.com>
---
drivers/remoteproc/imx_dsp_rproc.c | 36 ++++---------------
drivers/remoteproc/imx_rproc.c | 32 ++---------------
drivers/remoteproc/rcar_rproc.c | 33 ++---------------
drivers/remoteproc/st_remoteproc.c | 31 ++--------------
drivers/remoteproc/stm32_rproc.c | 34 ++----------------
drivers/remoteproc/xlnx_r5_remoteproc.c | 47 +++----------------------
6 files changed, 18 insertions(+), 195 deletions(-)
diff --git a/drivers/remoteproc/imx_dsp_rproc.c b/drivers/remoteproc/imx_dsp_rproc.c
index 008741af9f11..2d9f14fbef1d 100644
--- a/drivers/remoteproc/imx_dsp_rproc.c
+++ b/drivers/remoteproc/imx_dsp_rproc.c
@@ -644,32 +644,6 @@ static void imx_dsp_rproc_free_mbox(struct imx_dsp_rproc *priv)
mbox_free_channel(priv->rxdb_ch);
}
-static int imx_dsp_rproc_mem_alloc(struct rproc *rproc,
- struct rproc_mem_entry *mem)
-{
- struct device *dev = rproc->dev.parent;
- void *va;
-
- va = ioremap_wc(mem->dma, mem->len);
- if (!va) {
- dev_err(dev, "Unable to map memory region: %pa+%zx\n",
- &mem->dma, mem->len);
- return -ENOMEM;
- }
-
- mem->va = va;
-
- return 0;
-}
-
-static int imx_dsp_rproc_mem_release(struct rproc *rproc,
- struct rproc_mem_entry *mem)
-{
- iounmap(mem->va);
-
- return 0;
-}
-
/**
* imx_dsp_rproc_add_carveout() - request mailbox channels
* @priv: private data pointer
@@ -700,8 +674,10 @@ static int imx_dsp_rproc_add_carveout(struct imx_dsp_rproc *priv)
/* Register memory region */
mem = rproc_mem_entry_init(dev, NULL, (dma_addr_t)att->sa,
- att->size, da, imx_dsp_rproc_mem_alloc,
- imx_dsp_rproc_mem_release, "dsp_mem");
+ att->size, da,
+ rproc_mem_entry_ioremap_wc,
+ rproc_mem_entry_iounmap,
+ "dsp_mem");
if (mem)
rproc_coredump_add_segment(rproc, da, att->size);
@@ -732,8 +708,8 @@ static int imx_dsp_rproc_add_carveout(struct imx_dsp_rproc *priv)
/* Register memory region */
mem = rproc_mem_entry_init(dev, NULL, (dma_addr_t)res.start,
resource_size(&res), da,
- imx_dsp_rproc_mem_alloc,
- imx_dsp_rproc_mem_release,
+ rproc_mem_entry_ioremap_wc,
+ rproc_mem_entry_iounmap,
"%.*s", strchrnul(res.name, '@') - res.name, res.name);
if (!mem)
return -ENOMEM;
diff --git a/drivers/remoteproc/imx_rproc.c b/drivers/remoteproc/imx_rproc.c
index 7f54322244ac..6249815b54d8 100644
--- a/drivers/remoteproc/imx_rproc.c
+++ b/drivers/remoteproc/imx_rproc.c
@@ -600,35 +600,6 @@ static void *imx_rproc_da_to_va(struct rproc *rproc, u64 da, size_t len, bool *i
return va;
}
-static int imx_rproc_mem_alloc(struct rproc *rproc,
- struct rproc_mem_entry *mem)
-{
- struct device *dev = rproc->dev.parent;
- void *va;
-
- dev_dbg(dev, "map memory: %p+%zx\n", &mem->dma, mem->len);
- va = ioremap_wc(mem->dma, mem->len);
- if (IS_ERR_OR_NULL(va)) {
- dev_err(dev, "Unable to map memory region: %p+%zx\n",
- &mem->dma, mem->len);
- return -ENOMEM;
- }
-
- /* Update memory entry va */
- mem->va = va;
-
- return 0;
-}
-
-static int imx_rproc_mem_release(struct rproc *rproc,
- struct rproc_mem_entry *mem)
-{
- dev_dbg(rproc->dev.parent, "unmap memory: %pa\n", &mem->dma);
- iounmap(mem->va);
-
- return 0;
-}
-
static int imx_rproc_sm_lmm_prepare(struct rproc *rproc)
{
struct imx_rproc *priv = rproc->priv;
@@ -692,7 +663,8 @@ static int imx_rproc_prepare(struct rproc *rproc)
/* Register memory region */
mem = rproc_mem_entry_init(priv->dev, NULL, (dma_addr_t)res.start,
resource_size(&res), da,
- imx_rproc_mem_alloc, imx_rproc_mem_release,
+ rproc_mem_entry_ioremap_wc,
+ rproc_mem_entry_iounmap,
"%.*s", strchrnul(res.name, '@') - res.name,
res.name);
if (!mem)
diff --git a/drivers/remoteproc/rcar_rproc.c b/drivers/remoteproc/rcar_rproc.c
index 3c25625f966d..e3121fadd292 100644
--- a/drivers/remoteproc/rcar_rproc.c
+++ b/drivers/remoteproc/rcar_rproc.c
@@ -19,35 +19,6 @@ struct rcar_rproc {
struct reset_control *rst;
};
-static int rcar_rproc_mem_alloc(struct rproc *rproc,
- struct rproc_mem_entry *mem)
-{
- struct device *dev = &rproc->dev;
- void *va;
-
- dev_dbg(dev, "map memory: %pa+%zx\n", &mem->dma, mem->len);
- va = ioremap_wc(mem->dma, mem->len);
- if (!va) {
- dev_err(dev, "Unable to map memory region: %pa+%zx\n",
- &mem->dma, mem->len);
- return -ENOMEM;
- }
-
- /* Update memory entry va */
- mem->va = va;
-
- return 0;
-}
-
-static int rcar_rproc_mem_release(struct rproc *rproc,
- struct rproc_mem_entry *mem)
-{
- dev_dbg(&rproc->dev, "unmap memory: %pa\n", &mem->dma);
- iounmap(mem->va);
-
- return 0;
-}
-
static int rcar_rproc_prepare(struct rproc *rproc)
{
struct device *dev = rproc->dev.parent;
@@ -73,8 +44,8 @@ static int rcar_rproc_prepare(struct rproc *rproc)
mem = rproc_mem_entry_init(dev, NULL,
res.start,
resource_size(&res), da,
- rcar_rproc_mem_alloc,
- rcar_rproc_mem_release,
+ rproc_mem_entry_ioremap_wc,
+ rproc_mem_entry_iounmap,
res.name);
if (!mem)
diff --git a/drivers/remoteproc/st_remoteproc.c b/drivers/remoteproc/st_remoteproc.c
index a07edf7217d2..486180cdccb4 100644
--- a/drivers/remoteproc/st_remoteproc.c
+++ b/drivers/remoteproc/st_remoteproc.c
@@ -88,33 +88,6 @@ static void st_rproc_kick(struct rproc *rproc, int vqid)
dev_err(dev, "failed to send message via mbox: %d\n", ret);
}
-static int st_rproc_mem_alloc(struct rproc *rproc,
- struct rproc_mem_entry *mem)
-{
- struct device *dev = rproc->dev.parent;
- void *va;
-
- va = ioremap_wc(mem->dma, mem->len);
- if (!va) {
- dev_err(dev, "Unable to map memory region: %pa+%zx\n",
- &mem->dma, mem->len);
- return -ENOMEM;
- }
-
- /* Update memory entry va */
- mem->va = va;
-
- return 0;
-}
-
-static int st_rproc_mem_release(struct rproc *rproc,
- struct rproc_mem_entry *mem)
-{
- iounmap(mem->va);
-
- return 0;
-}
-
static int st_rproc_parse_fw(struct rproc *rproc, const struct firmware *fw)
{
struct device *dev = rproc->dev.parent;
@@ -138,8 +111,8 @@ static int st_rproc_parse_fw(struct rproc *rproc, const struct firmware *fw)
mem = rproc_mem_entry_init(dev, NULL,
(dma_addr_t)res.start,
resource_size(&res), res.start,
- st_rproc_mem_alloc,
- st_rproc_mem_release,
+ rproc_mem_entry_ioremap_wc,
+ rproc_mem_entry_iounmap,
"%.*s",
strchrnul(res.name, '@') - res.name,
res.name);
diff --git a/drivers/remoteproc/stm32_rproc.c b/drivers/remoteproc/stm32_rproc.c
index 632614013dc6..7ac8265b60ac 100644
--- a/drivers/remoteproc/stm32_rproc.c
+++ b/drivers/remoteproc/stm32_rproc.c
@@ -113,35 +113,6 @@ static int stm32_rproc_pa_to_da(struct rproc *rproc, phys_addr_t pa, u64 *da)
return -EINVAL;
}
-static int stm32_rproc_mem_alloc(struct rproc *rproc,
- struct rproc_mem_entry *mem)
-{
- struct device *dev = rproc->dev.parent;
- void *va;
-
- dev_dbg(dev, "map memory: %pad+%zx\n", &mem->dma, mem->len);
- va = (__force void *)ioremap_wc(mem->dma, mem->len);
- if (IS_ERR_OR_NULL(va)) {
- dev_err(dev, "Unable to map memory region: %pad+0x%zx\n",
- &mem->dma, mem->len);
- return -ENOMEM;
- }
-
- /* Update memory entry va */
- mem->va = va;
-
- return 0;
-}
-
-static int stm32_rproc_mem_release(struct rproc *rproc,
- struct rproc_mem_entry *mem)
-{
- dev_dbg(rproc->dev.parent, "unmap memory: %pa\n", &mem->dma);
- iounmap((__force __iomem void *)mem->va);
-
- return 0;
-}
-
static int stm32_rproc_of_memory_translations(struct platform_device *pdev,
struct stm32_rproc *ddata)
{
@@ -237,8 +208,8 @@ static int stm32_rproc_prepare(struct rproc *rproc)
mem = rproc_mem_entry_init(dev, NULL,
(dma_addr_t)res.start,
resource_size(&res), da,
- stm32_rproc_mem_alloc,
- stm32_rproc_mem_release,
+ rproc_mem_entry_ioremap_wc,
+ rproc_mem_entry_iounmap,
"%.*s", strchrnul(res.name, '@') - res.name,
res.name);
if (mem)
@@ -957,4 +928,3 @@ MODULE_DESCRIPTION("STM32 Remote Processor Control Driver");
MODULE_AUTHOR("Ludovic Barre <ludovic.barre@st.com>");
MODULE_AUTHOR("Fabien Dessenne <fabien.dessenne@st.com>");
MODULE_LICENSE("GPL v2");
-
diff --git a/drivers/remoteproc/xlnx_r5_remoteproc.c b/drivers/remoteproc/xlnx_r5_remoteproc.c
index 45a62cb98072..e5d1903c9636 100644
--- a/drivers/remoteproc/xlnx_r5_remoteproc.c
+++ b/drivers/remoteproc/xlnx_r5_remoteproc.c
@@ -447,45 +447,6 @@ static int zynqmp_r5_rproc_stop(struct rproc *rproc)
return ret;
}
-/*
- * zynqmp_r5_mem_region_map()
- * @rproc: single R5 core's corresponding rproc instance
- * @mem: mem descriptor to map reserved memory-regions
- *
- * Callback to map va for memory-region's carveout.
- *
- * return 0 on success, otherwise non-zero value on failure
- */
-static int zynqmp_r5_mem_region_map(struct rproc *rproc,
- struct rproc_mem_entry *mem)
-{
- void __iomem *va;
-
- va = ioremap_wc(mem->dma, mem->len);
- if (IS_ERR_OR_NULL(va))
- return -ENOMEM;
-
- mem->va = (void *)va;
-
- return 0;
-}
-
-/*
- * zynqmp_r5_rproc_mem_unmap
- * @rproc: single R5 core's corresponding rproc instance
- * @mem: mem entry to unmap
- *
- * Unmap memory-region carveout
- *
- * return: always returns 0
- */
-static int zynqmp_r5_mem_region_unmap(struct rproc *rproc,
- struct rproc_mem_entry *mem)
-{
- iounmap((void __iomem *)mem->va);
- return 0;
-}
-
/*
* add_mem_regions_carveout()
* @rproc: single R5 core's corresponding rproc instance
@@ -522,8 +483,8 @@ static int add_mem_regions_carveout(struct rproc *rproc)
rproc_mem = rproc_mem_entry_init(&rproc->dev, NULL,
(dma_addr_t)res.start,
resource_size(&res), res.start,
- zynqmp_r5_mem_region_map,
- zynqmp_r5_mem_region_unmap,
+ rproc_mem_entry_ioremap_wc,
+ rproc_mem_entry_iounmap,
"%.*s",
strchrnul(res.name, '@') - res.name,
res.name);
@@ -560,8 +521,8 @@ static int add_sram_carveouts(struct rproc *rproc)
rproc_mem = rproc_mem_entry_init(&rproc->dev, NULL,
dma_addr,
len, da,
- zynqmp_r5_mem_region_map,
- zynqmp_r5_mem_region_unmap,
+ rproc_mem_entry_ioremap_wc,
+ rproc_mem_entry_iounmap,
sram->sram_res.name);
if (!rproc_mem) {
dev_err(&rproc->dev, "failed to add sram %s da=0x%x, size=0x%lx",
--
2.34.1
^ permalink raw reply related
* [PATCH 1/4] remoteproc: add common wc-ioremap carveout callbacks
From: Ben Levinsky @ 2026-05-11 21:18 UTC (permalink / raw)
To: Bjorn Andersson, Mathieu Poirier, linux-remoteproc
Cc: Frank Li, Sascha Hauer, Pengutronix Kernel Team, Fabio Estevam,
Geert Uytterhoeven, Magnus Damm, Patrice Chotard, Maxime Coquelin,
Alexandre Torgue, imx, linux-arm-kernel, linux-kernel,
linux-renesas-soc, linux-stm32, tanmay.shah
In-Reply-To: <20260511211841.284809-1-ben.levinsky@amd.com>
Several remoteproc drivers open-code the same ioremap_wc() and
iounmap() callbacks for carveout mappings. Add subsystem-private
helpers in remoteproc_internal.h so those drivers can share the same
implementation.
Signed-off-by: Ben Levinsky <ben.levinsky@amd.com>
---
drivers/remoteproc/remoteproc_internal.h | 26 +++++++++++++++++++++++-
1 file changed, 25 insertions(+), 1 deletion(-)
diff --git a/drivers/remoteproc/remoteproc_internal.h b/drivers/remoteproc/remoteproc_internal.h
index 0a5e15744b1d..3724a47a9748 100644
--- a/drivers/remoteproc/remoteproc_internal.h
+++ b/drivers/remoteproc/remoteproc_internal.h
@@ -12,8 +12,9 @@
#ifndef REMOTEPROC_INTERNAL_H
#define REMOTEPROC_INTERNAL_H
-#include <linux/irqreturn.h>
#include <linux/firmware.h>
+#include <linux/io.h>
+#include <linux/irqreturn.h>
struct rproc;
@@ -122,6 +123,29 @@ rproc_find_carveout_by_name(struct rproc *rproc, const char *name, ...);
void rproc_add_rvdev(struct rproc *rproc, struct rproc_vdev *rvdev);
void rproc_remove_rvdev(struct rproc_vdev *rvdev);
+static inline int rproc_mem_entry_ioremap_wc(struct rproc *rproc,
+ struct rproc_mem_entry *mem)
+{
+ void __iomem *va;
+
+ va = ioremap_wc(mem->dma, mem->len);
+ if (!va)
+ return -ENOMEM;
+
+ mem->va = (__force void *)va;
+ mem->is_iomem = true;
+
+ return 0;
+}
+
+static inline int rproc_mem_entry_iounmap(struct rproc *rproc,
+ struct rproc_mem_entry *mem)
+{
+ iounmap((__force __iomem void *)mem->va);
+
+ return 0;
+}
+
static inline int rproc_prepare_device(struct rproc *rproc)
{
if (rproc->ops->prepare)
--
2.34.1
^ permalink raw reply related
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