* [PATCH v2 2/6] dt-bindings: opp: ti-cpu: Add ti,soc-info property
From: Akashdeep Kaur @ 2026-04-01 10:54 UTC (permalink / raw)
To: krzk, praneeth, nm, vigneshr, kristo, robh, krzk+dt, conor+dt,
rafael, viresh.kumar, linux-arm-kernel, devicetree, linux-kernel,
linux-pm, d-gole
Cc: vishalm, sebin.francis, k-willis, a-kaur
In-Reply-To: <20260401105404.1194717-1-a-kaur@ti.com>
Add ti,soc-info property to allow OPP tables to reference the SoC info
device (chipid) for establishing device link dependencies.
This is used on K3 SoCs (AM625, AM62A7, AM62L3, AM62P5) to ensure proper
probe ordering between ti-cpufreq and k3-socinfo drivers. The ti-cpufreq
driver depends on k3-socinfo registering the SoC device for revision
detection via soc_device_match().
The device link also prevents unbinding k3-socinfo while ti-cpufreq is
using it, maintaining system stability.
Signed-off-by: Akashdeep Kaur <a-kaur@ti.com>
---
.../bindings/opp/operating-points-v2-ti-cpu.yaml | 11 +++++++++++
1 file changed, 11 insertions(+)
diff --git a/Documentation/devicetree/bindings/opp/operating-points-v2-ti-cpu.yaml b/Documentation/devicetree/bindings/opp/operating-points-v2-ti-cpu.yaml
index 624d1f3f1382..f318494d5295 100644
--- a/Documentation/devicetree/bindings/opp/operating-points-v2-ti-cpu.yaml
+++ b/Documentation/devicetree/bindings/opp/operating-points-v2-ti-cpu.yaml
@@ -34,6 +34,16 @@ properties:
points to syscon node representing the control module
register space of the SoC.
+ ti,soc-info:
+ $ref: /schemas/types.yaml#/definitions/phandle
+ description: |
+ Optional phandle to the SoC info device (chipid). Used on K3 SoCs
+ to establish device link dependencies ensuring proper probe ordering
+ (ti-cpufreq after k3-socinfo) and preventing unbinding of k3-socinfo
+ while the OPP table is in use. This is needed because ti-cpufreq uses
+ soc_device_match() to detect SoC revision information provided by
+ k3-socinfo.
+
opp-shared: true
patternProperties:
@@ -82,6 +92,7 @@ examples:
opp-table {
compatible = "operating-points-v2-ti-cpu";
syscon = <&scm_conf>;
+ ti,soc-info = <&chipid>;
opp-300000000 {
opp-hz = /bits/ 64 <300000000>;
--
2.34.1
^ permalink raw reply related
* [PATCH v2 3/6] cpufreq: ti: Add device link to k3-socinfo
From: Akashdeep Kaur @ 2026-04-01 10:54 UTC (permalink / raw)
To: krzk, praneeth, nm, vigneshr, kristo, robh, krzk+dt, conor+dt,
rafael, viresh.kumar, linux-arm-kernel, devicetree, linux-kernel,
linux-pm, d-gole
Cc: vishalm, sebin.francis, k-willis, a-kaur
In-Reply-To: <20260401105404.1194717-1-a-kaur@ti.com>
Create explicit device link from CPU device to k3-socinfo when the OPP
table specifies ti,soc-info property. This prevents unbinding k3-socinfo
while ti-cpufreq is using it for SoC revision detection.
This complements the EPROBE_DEFER handling that ensures initial probe
ordering.
Signed-off-by: Akashdeep Kaur <a-kaur@ti.com>
---
drivers/cpufreq/ti-cpufreq.c | 52 ++++++++++++++++++++++++++++++++++++
1 file changed, 52 insertions(+)
diff --git a/drivers/cpufreq/ti-cpufreq.c b/drivers/cpufreq/ti-cpufreq.c
index 88f7912ef6a8..7bd45b367b36 100644
--- a/drivers/cpufreq/ti-cpufreq.c
+++ b/drivers/cpufreq/ti-cpufreq.c
@@ -12,6 +12,7 @@
#include <linux/module.h>
#include <linux/init.h>
#include <linux/of.h>
+#include <linux/of_platform.h>
#include <linux/platform_device.h>
#include <linux/pm_opp.h>
#include <linux/regmap.h>
@@ -111,6 +112,7 @@ struct ti_cpufreq_data {
struct device_node *opp_node;
struct regmap *syscon;
const struct ti_cpufreq_soc_data *soc_data;
+ struct device_link *soc_link;
};
static unsigned long amx3_efuse_xlate(struct ti_cpufreq_data *opp_data,
@@ -542,6 +544,7 @@ static int ti_cpufreq_probe(struct platform_device *pdev)
return -ENOMEM;
opp_data->soc_data = match->data;
+ platform_set_drvdata(pdev, opp_data);
opp_data->cpu_dev = get_cpu_device(0);
if (!opp_data->cpu_dev) {
@@ -560,6 +563,42 @@ static int ti_cpufreq_probe(struct platform_device *pdev)
if (ret)
goto fail_put_node;
+ /* Create device link to k3-socinfo if specified in DT */
+ if (opp_data->soc_data == &am625_soc_data ||
+ opp_data->soc_data == &am62a7_soc_data ||
+ opp_data->soc_data == &am62l3_soc_data ||
+ opp_data->soc_data == &am62p5_soc_data) {
+ struct device_node *socinfo_np;
+
+ socinfo_np = of_parse_phandle(opp_data->opp_node, "ti,soc-info", 0);
+ if (socinfo_np) {
+ struct platform_device *socinfo_pdev;
+ struct device_link *link;
+
+ socinfo_pdev = of_find_device_by_node(socinfo_np);
+ of_node_put(socinfo_np);
+
+ if (!socinfo_pdev) {
+ ret = -EPROBE_DEFER;
+ goto fail_put_node;
+ }
+
+ if (!socinfo_pdev->dev.driver) {
+ put_device(&socinfo_pdev->dev);
+ ret = -EPROBE_DEFER;
+ goto fail_put_node;
+ }
+
+ link = device_link_add(opp_data->cpu_dev,
+ &socinfo_pdev->dev,
+ DL_FLAG_STATELESS);
+ if (link)
+ opp_data->soc_link = link;
+
+ put_device(&socinfo_pdev->dev);
+ }
+ }
+
/*
* OPPs determine whether or not they are supported based on
* two metrics:
@@ -600,6 +639,18 @@ static int ti_cpufreq_probe(struct platform_device *pdev)
return ret;
}
+static void ti_cpufreq_remove(struct platform_device *pdev)
+{
+ struct ti_cpufreq_data *opp_data = platform_get_drvdata(pdev);
+
+ /*
+ * Device link is automatically removed with DL_FLAG_AUTOREMOVE_CONSUMER,
+ * but explicitly delete it for safety.
+ */
+ if (opp_data && opp_data->soc_link)
+ device_link_del(opp_data->soc_link);
+}
+
static int __init ti_cpufreq_init(void)
{
const struct of_device_id *match;
@@ -616,6 +667,7 @@ module_init(ti_cpufreq_init);
static struct platform_driver ti_cpufreq_driver = {
.probe = ti_cpufreq_probe,
+ .remove = ti_cpufreq_remove,
.driver = {
.name = "ti-cpufreq",
},
--
2.34.1
^ permalink raw reply related
* [PATCH v2 4/6] arm64: dts: ti: k3-am625: Add ti,soc-info to OPP table
From: Akashdeep Kaur @ 2026-04-01 10:54 UTC (permalink / raw)
To: krzk, praneeth, nm, vigneshr, kristo, robh, krzk+dt, conor+dt,
rafael, viresh.kumar, linux-arm-kernel, devicetree, linux-kernel,
linux-pm, d-gole
Cc: vishalm, sebin.francis, k-willis, a-kaur
In-Reply-To: <20260401105404.1194717-1-a-kaur@ti.com>
Link CPU OPP table to k3-socinfo driver for dependency tracking.
Signed-off-by: Akashdeep Kaur <a-kaur@ti.com>
---
arch/arm64/boot/dts/ti/k3-am625.dtsi | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arm64/boot/dts/ti/k3-am625.dtsi b/arch/arm64/boot/dts/ti/k3-am625.dtsi
index c249883a8a8d..b0020e667882 100644
--- a/arch/arm64/boot/dts/ti/k3-am625.dtsi
+++ b/arch/arm64/boot/dts/ti/k3-am625.dtsi
@@ -109,6 +109,7 @@ a53_opp_table: opp-table {
compatible = "operating-points-v2-ti-cpu";
opp-shared;
syscon = <&opp_efuse_table>;
+ ti,soc-info = <&chipid>;
opp-200000000 {
opp-hz = /bits/ 64 <200000000>;
--
2.34.1
^ permalink raw reply related
* [PATCH v2 5/6] arm64: dts: ti: k3-am62a7: Add ti,soc-info to OPP table
From: Akashdeep Kaur @ 2026-04-01 10:54 UTC (permalink / raw)
To: krzk, praneeth, nm, vigneshr, kristo, robh, krzk+dt, conor+dt,
rafael, viresh.kumar, linux-arm-kernel, devicetree, linux-kernel,
linux-pm, d-gole
Cc: vishalm, sebin.francis, k-willis, a-kaur
In-Reply-To: <20260401105404.1194717-1-a-kaur@ti.com>
Link CPU OPP table to k3-socinfo driver for dependency tracking.
Signed-off-by: Akashdeep Kaur <a-kaur@ti.com>
---
arch/arm64/boot/dts/ti/k3-am62a7.dtsi | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arm64/boot/dts/ti/k3-am62a7.dtsi b/arch/arm64/boot/dts/ti/k3-am62a7.dtsi
index b6e5eee99370..6d1459e9ea71 100644
--- a/arch/arm64/boot/dts/ti/k3-am62a7.dtsi
+++ b/arch/arm64/boot/dts/ti/k3-am62a7.dtsi
@@ -109,6 +109,7 @@ a53_opp_table: opp-table {
compatible = "operating-points-v2-ti-cpu";
opp-shared;
syscon = <&opp_efuse_table>;
+ ti,soc-info = <&chipid>;
opp-200000000 {
opp-hz = /bits/ 64 <200000000>;
--
2.34.1
^ permalink raw reply related
* [PATCH v2 6/6] arm64: dts: ti: k3-am62p5: Add ti,soc-info to OPP table
From: Akashdeep Kaur @ 2026-04-01 10:54 UTC (permalink / raw)
To: krzk, praneeth, nm, vigneshr, kristo, robh, krzk+dt, conor+dt,
rafael, viresh.kumar, linux-arm-kernel, devicetree, linux-kernel,
linux-pm, d-gole
Cc: vishalm, sebin.francis, k-willis, a-kaur
In-Reply-To: <20260401105404.1194717-1-a-kaur@ti.com>
Link CPU OPP table to k3-socinfo driver for dependency tracking.
Signed-off-by: Akashdeep Kaur <a-kaur@ti.com>
---
arch/arm64/boot/dts/ti/k3-am62p5.dtsi | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arm64/boot/dts/ti/k3-am62p5.dtsi b/arch/arm64/boot/dts/ti/k3-am62p5.dtsi
index 8982a7b9f1a6..1a498c5eb3d1 100644
--- a/arch/arm64/boot/dts/ti/k3-am62p5.dtsi
+++ b/arch/arm64/boot/dts/ti/k3-am62p5.dtsi
@@ -108,6 +108,7 @@ a53_opp_table: opp-table {
compatible = "operating-points-v2-ti-cpu";
opp-shared;
syscon = <&opp_efuse_table>;
+ ti,soc-info = <&chipid>;
opp-200000000 {
opp-hz = /bits/ 64 <200000000>;
--
2.34.1
^ permalink raw reply related
* Re: [PATCH v2 0/2] Enable Mali G310 GPU support on i.MX952 board
From: Daniel Baluta @ 2026-04-01 10:58 UTC (permalink / raw)
To: Guangliu Ding, Daniel Almeida, Alice Ryhl, Boris Brezillon,
Steven Price, Liviu Dudau, David Airlie, Simona Vetter,
Maarten Lankhorst, Maxime Ripard, Thomas Zimmermann, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Frank Li, Sascha Hauer,
Pengutronix Kernel Team, Fabio Estevam
Cc: dri-devel, devicetree, linux-kernel, imx, linux-arm-kernel
In-Reply-To: <20260401-master-v2-0-20d3fbcd19d6@nxp.com>
On 4/1/26 13:19, Guangliu Ding wrote:
> This series enable Mali G310 GPU support on i.MX952 boards, the same GPU
> IP as the instance on i.MX95 boards.
>
> Signed-off-by: Guangliu Ding <guangliu.ding@nxp.com>
Please wait until there is a resolution to all the questions asked
by reviewers.
Otherwise, this v2 is just useless.
^ permalink raw reply
* Re: [PATCH 1/2] dt-bindings: nvmem: qfprom: Add Milos compatible
From: Krzysztof Kozlowski @ 2026-04-01 10:55 UTC (permalink / raw)
To: Alexander Koskovich
Cc: Srinivas Kandagatla, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Bjorn Andersson, Konrad Dybcio, Luca Weiss,
linux-arm-msm, devicetree, linux-kernel
In-Reply-To: <20260331-milos-qfprom-v1-1-36017cc642db@pm.me>
On Wed, Apr 01, 2026 at 02:24:57AM +0000, Alexander Koskovich wrote:
> Document compatible string for the QFPROM on Milos platform.
>
> Signed-off-by: Alexander Koskovich <akoskovich@pm.me>
> ---
> Documentation/devicetree/bindings/nvmem/qcom,qfprom.yaml | 1 +
> 1 file changed, 1 insertion(+)
Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH v5 2/5] media: iris: scale MMCX power domain on SM8250
From: Bryan O'Donoghue @ 2026-04-01 10:58 UTC (permalink / raw)
To: Ulf Hansson, Dmitry Baryshkov
Cc: Dikshita Agarwal, Bjorn Andersson, Michael Turquette,
Stephen Boyd, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Taniya Das, Jonathan Marek, Rafael J. Wysocki, Vikash Garodia,
Mauro Carvalho Chehab, Stanimir Varbanov, Abhinav Kumar,
Hans Verkuil, Stefan Schmidt, Konrad Dybcio, Bryan O'Donoghue,
Dikshita Agarwal, linux-arm-msm, linux-clk, devicetree,
linux-kernel, linux-pm, linux-media, Mauro Carvalho Chehab
In-Reply-To: <CAPDyKFpm7ujNw51dVpPaHCwssjgYe1JVBEyrQ_1CsPbDJuW0Ww@mail.gmail.com>
On 01/04/2026 11:46, Ulf Hansson wrote:
>>> The intent was for this patch to be part of v7.0-rc1, but I failed
>>> with my pull-request to Linus.
>>>
>>> Instead this will be part of v7.1-rc1, assuming everything goes as expected.
>>>
>>> Is it possible to drop/defer these changes until v7.2?
>> It would be very sad.
> Right.
>
> Since it's my mistake, let me reconsider. If I rebase my branch and
> share the necessary commit through an immutable branch that you can
> pull in. Would that work for you?
>
> Kind regards
> Uffe
Yes. Please go ahead.
---
bod
^ permalink raw reply
* Re: [PATCH 5/5] cpufreq: ti: Add device link to k3-socinfo
From: Akashdeep Kaur @ 2026-04-01 10:59 UTC (permalink / raw)
To: Krzysztof Kozlowski, praneeth, nm, vigneshr, kristo, robh,
krzk+dt, conor+dt, rafael, viresh.kumar, linux-arm-kernel,
devicetree, linux-kernel, linux-pm, d-gole
Cc: vishalm, sebin.francis, k-willis
In-Reply-To: <da225ab1-d659-455d-b3c9-e7ff4864119e@kernel.org>
Hi Krzysztof,
On 30/03/26 18:52, Krzysztof Kozlowski wrote:
> On 30/03/2026 14:01, Akashdeep Kaur wrote:
>> opp_data->cpu_dev = get_cpu_device(0);
>> if (!opp_data->cpu_dev) {
>> @@ -560,6 +563,42 @@ static int ti_cpufreq_probe(struct platform_device *pdev)
>> if (ret)
>> goto fail_put_node;
>>
>> + /* Create device link to k3-socinfo if specified in DT */
>> + if (opp_data->soc_data == &am625_soc_data ||
>> + opp_data->soc_data == &am62a7_soc_data ||
>> + opp_data->soc_data == &am62l3_soc_data ||
>> + opp_data->soc_data == &am62p5_soc_data) {
>> + struct device_node *socinfo_np;
>> +
>> + socinfo_np = of_parse_phandle(opp_data->opp_node, "ti,soc-info", 0);
>
> Undocumented ABI.
Added missing patch in next version, thanks for pointing this out.
Regards,
Akashdeep Kaur
>
> Best regards,
> Krzysztof
^ permalink raw reply
* RE: Re: [PATCH 1/2] dt-bindings: gpu: mali-valhall-csf: Document i.MX952 support
From: Guangliu Ding @ 2026-04-01 11:01 UTC (permalink / raw)
To: Krzysztof Kozlowski, Liviu Dudau
Cc: Daniel Baluta (OSS), Daniel Almeida, Alice Ryhl, Boris Brezillon,
Steven Price, David Airlie, Simona Vetter, Maarten Lankhorst,
Maxime Ripard, Thomas Zimmermann, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Frank Li, Sascha Hauer,
Pengutronix Kernel Team, Fabio Estevam,
dri-devel@lists.freedesktop.org, devicetree@vger.kernel.org,
linux-kernel@vger.kernel.org, imx@lists.linux.dev,
linux-arm-kernel@lists.infradead.org, Jiyu Yang
In-Reply-To: <2f4c4063-daf6-48f2-b830-9f58dc7af80d@kernel.org>
Hi Krzysztof
> On 01/04/2026 12:31, Guangliu Ding wrote:
> >> Either add the patch(es) that use the compatible to this series in
> >> v2, or put a comment in the commit message on where we can see the
> driver changes.
> >>
> >
> > According to discussions with the GPU vendor, this is a hardware
> > limitation of Mali-G310 rather than a hardware bug, and it has been
> > addressed in newer Mali GPU families.
> >
> > In addition, ipa_counters are not enabled in the current Panthor
> > driver. We observed this issue with the private Mali DDK where ipa_counters
> were enabled.
> > Therefore, keeping the compatible string is necessary to allow for future
> divergence.
>
> No one discusses here whether you need separate compatible string.
> writing bindings and all my talks are (e.g. DTS 101) are clearly expecting you.
>
> We discuss only the lack of compatibility in terms of DT, how DT sees
> compatible devices.
>
> And lack of driver code is clear indication that devices are compatible in terms
> how DT understands it. Feel encouraged to bring actual arguments in commit
> msgs in the future.
>
> Best regards,
> Krzysztof
So the best approach is only reserve "arm,mali-valhall-csf" for now, since currently there is
no need for an additional compatible entry from a DT compatibility perspective.
We can introduce "nxp,imx952-mali" in future commits if hardware or driver differences
actually require it, and include more detailed justification in the commit message. Right?
^ permalink raw reply
* Re: [PATCH v5 2/5] media: iris: scale MMCX power domain on SM8250
From: Dmitry Baryshkov @ 2026-04-01 11:01 UTC (permalink / raw)
To: Ulf Hansson
Cc: Dikshita Agarwal, Bjorn Andersson, Michael Turquette,
Stephen Boyd, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Taniya Das, Jonathan Marek, Rafael J. Wysocki,
Bryan O'Donoghue, Vikash Garodia, Mauro Carvalho Chehab,
Stanimir Varbanov, Abhinav Kumar, Hans Verkuil, Stefan Schmidt,
Konrad Dybcio, Bryan O'Donoghue, Dikshita Agarwal,
linux-arm-msm, linux-clk, devicetree, linux-kernel, linux-pm,
linux-media, Mauro Carvalho Chehab
In-Reply-To: <CAPDyKFpm7ujNw51dVpPaHCwssjgYe1JVBEyrQ_1CsPbDJuW0Ww@mail.gmail.com>
On Wed, Apr 01, 2026 at 12:46:01PM +0200, Ulf Hansson wrote:
> On Tue, 31 Mar 2026 at 20:46, Dmitry Baryshkov
> <dmitry.baryshkov@oss.qualcomm.com> wrote:
> >
> > On Tue, Mar 31, 2026 at 01:33:35PM +0200, Ulf Hansson wrote:
> > > On Mon, 30 Mar 2026 at 15:06, Dikshita Agarwal
> > > <dikshita.agarwal@oss.qualcomm.com> wrote:
> > > >
> > > >
> > > >
> > > > On 3/30/2026 4:45 PM, Dmitry Baryshkov wrote:
> > > > > On Mon, Mar 30, 2026 at 10:55:02AM +0530, Dikshita Agarwal wrote:
> > > > >>
> > > > >>
> > > > >> On 2/9/2026 7:02 AM, Dmitry Baryshkov wrote:
> > > > >>> On SM8250 most of the video clocks are powered by the MMCX domain, while
> > > > >>> the PLL is powered on by the MX domain. Extend the driver to support
> > > > >>> scaling both power domains, while keeping compatibility with the
> > > > >>> existing DTs, which define only the MX domain.
> > > > >>>
> > > > >>> Fixes: 79865252acb6 ("media: iris: enable video driver probe of SM8250 SoC")
> > > > >>> Reviewed-by: Dikshita Agarwal <dikshita.agarwal@oss.qualcomm.com>
> > > > >>> Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
> > > > >>> ---
> > > > >>> drivers/media/platform/qcom/iris/iris_platform_gen1.c | 2 +-
> > > > >>> drivers/media/platform/qcom/iris/iris_probe.c | 7 +++++++
> > > > >>> 2 files changed, 8 insertions(+), 1 deletion(-)
> > > > >>>
> > > > >>> diff --git a/drivers/media/platform/qcom/iris/iris_platform_gen1.c b/drivers/media/platform/qcom/iris/iris_platform_gen1.c
> > > > >>> index df8e6bf9430e..aa71f7f53ee3 100644
> > > > >>> --- a/drivers/media/platform/qcom/iris/iris_platform_gen1.c
> > > > >>> +++ b/drivers/media/platform/qcom/iris/iris_platform_gen1.c
> > > > >>> @@ -281,7 +281,7 @@ static const struct bw_info sm8250_bw_table_dec[] = {
> > > > >>>
> > > > >>> static const char * const sm8250_pmdomain_table[] = { "venus", "vcodec0" };
> > > > >>>
> > > > >>> -static const char * const sm8250_opp_pd_table[] = { "mx" };
> > > > >>> +static const char * const sm8250_opp_pd_table[] = { "mx", "mmcx" };
> > > > >>>
> > > > >>> static const struct platform_clk_data sm8250_clk_table[] = {
> > > > >>> {IRIS_AXI_CLK, "iface" },
> > > > >>> diff --git a/drivers/media/platform/qcom/iris/iris_probe.c b/drivers/media/platform/qcom/iris/iris_probe.c
> > > > >>> index 7b612ad37e4f..74ec81e3d622 100644
> > > > >>> --- a/drivers/media/platform/qcom/iris/iris_probe.c
> > > > >>> +++ b/drivers/media/platform/qcom/iris/iris_probe.c
> > > > >>> @@ -64,6 +64,13 @@ static int iris_init_power_domains(struct iris_core *core)
> > > > >>> return ret;
> > > > >>>
> > > > >>> ret = devm_pm_domain_attach_list(core->dev, &iris_opp_pd_data, &core->opp_pmdomain_tbl);
> > > > >>> + /* backwards compatibility for incomplete ABI SM8250 */
> > > > >>> + if (ret == -ENODEV &&
> > > > >>> + of_device_is_compatible(core->dev->of_node, "qcom,sm8250-venus")) {
> > > > >>> + iris_opp_pd_data.num_pd_names--;
> > > > >>> + ret = devm_pm_domain_attach_list(core->dev, &iris_opp_pd_data,
> > > > >>> + &core->opp_pmdomain_tbl);
> > > > >>> + }
> > > > >>> if (ret < 0)
> > > > >>> return ret;
> > > > >>>
> > > > >>>
> > > > >>
> > > > >> Hitting below compilation error on latest kernel
> > > > >>
> > > > >> drivers/media/platform/qcom/iris/iris_probe.c: In function
> > > > >> ‘iris_init_power_domains’:
> > > > >> drivers/media/platform/qcom/iris/iris_probe.c:71:46: error: decrement of
> > > > >> read-only member ‘num_pd_names’
> > > > >> 71 | iris_opp_pd_data.num_pd_names--;
> > > > >
> > > > > See commit 7ad7f43e568b ("pmdomain: de-constify fields struct
> > > > > dev_pm_domain_attach_data")
> > >
> > > The intent was for this patch to be part of v7.0-rc1, but I failed
> > > with my pull-request to Linus.
> > >
> > > Instead this will be part of v7.1-rc1, assuming everything goes as expected.
> > >
> > > Is it possible to drop/defer these changes until v7.2?
> >
> > It would be very sad.
>
> Right.
>
> Since it's my mistake, let me reconsider. If I rebase my branch and
> share the necessary commit through an immutable branch that you can
> pull in. Would that work for you?
I think that question goes to Vikash, Dikshita, Bryan and linux-media
maintainers. Bryan, what is the plan for this patchset? Should Ulf
rebase the branch? Or is this patchset delayed for some other reasons?
--
With best wishes
Dmitry
^ permalink raw reply
* Re: [PATCH 1/2] dt-bindings: gpu: mali-valhall-csf: Document i.MX952 support
From: Krzysztof Kozlowski @ 2026-04-01 11:03 UTC (permalink / raw)
To: Guangliu Ding, Liviu Dudau
Cc: Daniel Baluta (OSS), Daniel Almeida, Alice Ryhl, Boris Brezillon,
Steven Price, David Airlie, Simona Vetter, Maarten Lankhorst,
Maxime Ripard, Thomas Zimmermann, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Frank Li, Sascha Hauer,
Pengutronix Kernel Team, Fabio Estevam,
dri-devel@lists.freedesktop.org, devicetree@vger.kernel.org,
linux-kernel@vger.kernel.org, imx@lists.linux.dev,
linux-arm-kernel@lists.infradead.org, Jiyu Yang
In-Reply-To: <AM0PR04MB4707D758EC8B08C6D42F3A82F350A@AM0PR04MB4707.eurprd04.prod.outlook.com>
On 01/04/2026 13:01, Guangliu Ding wrote:
> Hi Krzysztof
>
>> On 01/04/2026 12:31, Guangliu Ding wrote:
>>>> Either add the patch(es) that use the compatible to this series in
>>>> v2, or put a comment in the commit message on where we can see the
>> driver changes.
>>>>
>>>
>>> According to discussions with the GPU vendor, this is a hardware
>>> limitation of Mali-G310 rather than a hardware bug, and it has been
>>> addressed in newer Mali GPU families.
>>>
>>> In addition, ipa_counters are not enabled in the current Panthor
>>> driver. We observed this issue with the private Mali DDK where ipa_counters
>> were enabled.
>>> Therefore, keeping the compatible string is necessary to allow for future
>> divergence.
>>
>> No one discusses here whether you need separate compatible string.
>> writing bindings and all my talks are (e.g. DTS 101) are clearly expecting you.
>>
>> We discuss only the lack of compatibility in terms of DT, how DT sees
>> compatible devices.
>>
>> And lack of driver code is clear indication that devices are compatible in terms
>> how DT understands it. Feel encouraged to bring actual arguments in commit
>> msgs in the future.
>>
>> Best regards,
>> Krzysztof
>
> So the best approach is only reserve "arm,mali-valhall-csf" for now, since currently there is
> no need for an additional compatible entry from a DT compatibility perspective.
> We can introduce "nxp,imx952-mali" in future commits if hardware or driver differences
> actually require it, and include more detailed justification in the commit message. Right?
So does that mean you decided not to read writing bindings document?
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH v4 4/5] arm64: dts: qcom: purwa: Override Iris clocks and operating points
From: Dmitry Baryshkov @ 2026-04-01 11:03 UTC (permalink / raw)
To: Wangao Wang
Cc: Bryan O'Donoghue, Vikash Garodia, Dikshita Agarwal,
Abhinav Kumar, Mauro Carvalho Chehab, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Bjorn Andersson, Konrad Dybcio,
linux-media, linux-arm-msm, devicetree, linux-kernel,
Konrad Dybcio
In-Reply-To: <20260401-enable_iris_on_purwa-v4-4-ca784552a3e9@oss.qualcomm.com>
On Wed, Apr 01, 2026 at 06:24:41PM +0800, Wangao Wang wrote:
> The Iris block on X1P differs from SM8550/X1E in its clock configuration
> and requires a dedicated OPP table. The node inherited from the X1E cannot
> be reused directly, and the fallback compatible "qcom,sm8550-iris" cannot
> be applied.
>
> Override the inherited clocks, clock-names, and operating points, and
> replaces them with the X1P42100-specific definitions. A new OPP table
> is provided to support the correct performance levels on this platform.
>
> Depends-on: https://lore.kernel.org/all/20260331-purwa-videocc-camcc-v3-0-6daca180a4b1@oss.qualcomm.com/
This doesn't make sense in the commit message.
>
> Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
> Signed-off-by: Wangao Wang <wangao.wang@oss.qualcomm.com>
> ---
> arch/arm64/boot/dts/qcom/purwa.dtsi | 50 +++++++++++++++++++++++++++++++++++++
> 1 file changed, 50 insertions(+)
Other than that,
Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
--
With best wishes
Dmitry
^ permalink raw reply
* Re: [PATCH v5 2/5] media: iris: scale MMCX power domain on SM8250
From: Bryan O'Donoghue @ 2026-04-01 11:05 UTC (permalink / raw)
To: Dmitry Baryshkov, Ulf Hansson
Cc: Dikshita Agarwal, Bjorn Andersson, Michael Turquette,
Stephen Boyd, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Taniya Das, Jonathan Marek, Rafael J. Wysocki,
Bryan O'Donoghue, Vikash Garodia, Mauro Carvalho Chehab,
Stanimir Varbanov, Abhinav Kumar, Hans Verkuil, Stefan Schmidt,
Konrad Dybcio, Dikshita Agarwal, linux-arm-msm, linux-clk,
devicetree, linux-kernel, linux-pm, linux-media,
Mauro Carvalho Chehab
In-Reply-To: <4fiyjcqt5smotudsfzyqrevxxnx3sf5grbgfluzkndbp2od6pq@vlyikcvl3xkb>
On 01/04/2026 12:01, Dmitry Baryshkov wrote:
>> Right.
>>
>> Since it's my mistake, let me reconsider. If I rebase my branch and
>> share the necessary commit through an immutable branch that you can
>> pull in. Would that work for you?
> I think that question goes to Vikash, Dikshita, Bryan and linux-media
> maintainers. Bryan, what is the plan for this patchset? Should Ulf
> rebase the branch? Or is this patchset delayed for some other reasons?
Yeah no it's grand, immutable tag works fine.
---
bod
^ permalink raw reply
* Re: [PATCH 4/6] arm64: dts: qcom: kaanapali-mtp: Enable bluetooth and Wifi
From: Dmitry Baryshkov @ 2026-04-01 11:08 UTC (permalink / raw)
To: Zijun Hu
Cc: Jingyi Wang, Bjorn Andersson, Konrad Dybcio, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, aiqun.yu, tingwei.zhang,
trilok.soni, yijie.yang, linux-arm-msm, devicetree, linux-kernel,
20260224-knp-dts-misc-v6-0-79d20dab8a60
In-Reply-To: <bf1df5d9-787c-40e9-93db-536612982427@oss.qualcomm.com>
On Wed, Apr 01, 2026 at 06:39:19PM +0800, Zijun Hu wrote:
> On 3/30/2026 7:53 PM, Dmitry Baryshkov wrote:
> >>> - Is the pin defined in the schema?
> >> schema define property 'swctrl-gpios' with description
> >> "GPIO line indicating the state of the clock supply to the BT module"
> >>
> >>> - Is the pin wired in the hardware?
> >> pin SW_CTRL is wired in hardware.
> > Granted your three answers, it can and should be described in the DT.
> >
> >> i have below confusions about 'swctrl-gpios' of 'qcom,wcn7850-pmu'
> >> which WCN7850 pin is 'swctrl-gpios' mean for ?
> >> Why to introduce 'swctrl-gpios' ?
> >> what problem does it solve ?
> >> how to solve the problem ?
> > Please descibe the hardware in the DT. Problem solving belongs to the
> > driver.
>
> sorry for not agreeing with your points here.
>
> it is better to correct or remove 'swctrl-gpios' within DT binding spec at least
> for 'qcom,wcn7850-pmu' with below reasons:
>
> 1) provided that 'swctrl-gpios' is for pin SW_CTRL of datasheet, binding spec's
> both description and its expected usage are wrong.
Please correct it.
> 2) its driver does not parse and use the property 'swctrl-gpios', moreover, the
> property have no user within upstream DT tree.
There is no "driver" in the "DT bindings"
> 3) the property is not mandatory based on binding spec.
Which is expected, because on some platforms it might be not wired up
and on the other platforms the pin to which it is wired to might be
unknown (think about all the phones for which the community doesn't have
schematics).
> 4) upstream DT tree have had many such usages as mine which just set default pin
> configuration and not specify 'swctrl-gpios' explicitly.
I don't understand this part.
> 5) kaanapali-mtp is originally preinstalled with android OS which supports some
> qualcomm specific feature which have not been supported by up-stream kernel.
> so kaanapali-mtp H/W has some wired pins which is not used by up-stream
> kernel sometimes
Again, what does that have to do with the hardware description?
--
With best wishes
Dmitry
^ permalink raw reply
* Re: [PATCH 1/3] dt-bindings: gpio: realtek: Add realtek,rtd1625-gpio
From: Krzysztof Kozlowski @ 2026-04-01 11:12 UTC (permalink / raw)
To: Yu-Chun Lin [林祐君]
Cc: linusw@kernel.org, brgl@kernel.org, robh@kernel.org,
krzk+dt@kernel.org, conor+dt@kernel.org, afaerber@suse.com,
TY_Chang[張子逸], linux-gpio@vger.kernel.org,
devicetree@vger.kernel.org, linux-kernel@vger.kernel.org,
linux-arm-kernel@lists.infradead.org,
linux-realtek-soc@lists.infradead.org,
CY_Huang[黃鉦晏],
Stanley Chang[昌育德],
James Tai [戴志峰]
In-Reply-To: <8a4f558fdc6649be8c6239403e706621@realtek.com>
On 01/04/2026 13:10, Yu-Chun Lin [林祐君] wrote:
>>> + compatible = "realtek,rtd1625-isom-gpio";
>>> + reg = <0x89120 0x10>,
>>
>> 0x10 feels very short range.
>>
>>> + <0x89100 0x20>;
>>
>> And this means it's continuous. Are you sure these are two separate address
>> spaces?
>>
>> Best regards,
>> Krzysztof
>
> Agreed, they are continuous. I will merge them into a single region in v2.
I assume you checked in the datasheet/manual.
Best regards,
Krzysztof
^ permalink raw reply
* RE: [PATCH 1/3] dt-bindings: gpio: realtek: Add realtek,rtd1625-gpio
From: Yu-Chun Lin [林祐君] @ 2026-04-01 11:10 UTC (permalink / raw)
To: Krzysztof Kozlowski
Cc: linusw@kernel.org, brgl@kernel.org, robh@kernel.org,
krzk+dt@kernel.org, conor+dt@kernel.org, afaerber@suse.com,
TY_Chang[張子逸], linux-gpio@vger.kernel.org,
devicetree@vger.kernel.org, linux-kernel@vger.kernel.org,
linux-arm-kernel@lists.infradead.org,
linux-realtek-soc@lists.infradead.org,
CY_Huang[黃鉦晏],
Stanley Chang[昌育德],
James Tai [戴志峰]
In-Reply-To: <20260401-idealistic-grinning-wallaby-8c3cd5@quoll>
> On Tue, Mar 31, 2026 at 07:38:33PM +0800, Yu-Chun Lin wrote:
> > + reg:
> > + items:
> > + - description: GPIO controller registers
> > + - description: GPIO interrupt registers
> > +
> > + interrupts:
> > + items:
> > + - description: Interrupt number of the assert GPIO interrupt, which
> is
> > + triggered when there is a rising edge.
> > + - description: Interrupt number of the deassert GPIO interrupt,
> which is
> > + triggered when there is a falling edge.
> > + - description: Interrupt number of the level-sensitive GPIO interrupt,
> > + triggered by a configured logic level.
> > +
> > + interrupt-controller: true
> > +
> > + "#interrupt-cells":
> > + const: 2
> > +
> > + gpio-ranges: true
> > +
> > + gpio-controller: true
> > +
> > + "#gpio-cells":
> > + const: 2
> > +
> > +required:
> > + - compatible
> > + - reg
> > + - gpio-ranges
> > + - gpio-controller
> > + - "#gpio-cells"
> > +
> > +additionalProperties: false
> > +
> > +examples:
> > + - |
> > + gpio@89120 {
> > + compatible = "realtek,rtd1625-isom-gpio";
> > + reg = <0x89120 0x10>,
>
> 0x10 feels very short range.
>
> > + <0x89100 0x20>;
>
> And this means it's continuous. Are you sure these are two separate address
> spaces?
>
> Best regards,
> Krzysztof
Agreed, they are continuous. I will merge them into a single region in v2.
Best regards,
Yu-Chun
^ permalink raw reply
* Re: [PATCH 2/2] arm64: dts: qcom: milos: Add qfprom efuse node
From: Dmitry Baryshkov @ 2026-04-01 11:16 UTC (permalink / raw)
To: Alexander Koskovich
Cc: Srinivas Kandagatla, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Bjorn Andersson, Konrad Dybcio, Luca Weiss,
linux-arm-msm, devicetree, linux-kernel
In-Reply-To: <20260331-milos-qfprom-v1-2-36017cc642db@pm.me>
On Wed, Apr 01, 2026 at 02:25:07AM +0000, Alexander Koskovich wrote:
> Add the qfprom efuse node and describe where the GPU speedbin fuse is
> located on Milos.
>
> Note that for SM7635-AB at least, the value is "221", the max frequency
> for this is 1050MHz. There's another speedbin out there for 1150MHz but
> we do not know the value for it so just document in this commit.
>
> Once the value is discovered we should add the speedbins to the A810
> Adreno entry and update devicetree.
>
> Signed-off-by: Alexander Koskovich <akoskovich@pm.me>
> ---
> arch/arm64/boot/dts/qcom/milos.dtsi | 12 ++++++++++++
> 1 file changed, 12 insertions(+)
Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
>
--
With best wishes
Dmitry
^ permalink raw reply
* Re: [PATCH v2 3/3] ARM: dts: qcom: msm8960: expressatt: Add MAX17048 fuel gauge
From: Dmitry Baryshkov @ 2026-04-01 11:19 UTC (permalink / raw)
To: Rudraksha Gupta
Cc: Bjorn Andersson, Konrad Dybcio, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, linux-arm-msm, devicetree, linux-kernel
In-Reply-To: <20260401-expressatt_fuel_guage-v2-3-947922834df1@gmail.com>
On Wed, Apr 01, 2026 at 01:28:50AM -0700, Rudraksha Gupta wrote:
> Add MAX17048 fuel gauge support.
>
> Tested by comparing battery capacity readings between upstream (mainline
> max17040 driver) and downstream (Samsung max17048_fuelgauge driver)
> across a full discharge cycle. Upstream reads ~3% lower throughout. Both
> track the discharge curve correctly:
>
> Upstream: 95 92 88 87 86 87 83 82 80 68 60 55 50 45 40 35 30 20 16 10 10 5 5 1
> Downstream: 95 94 92 91 91 89 87 86 84 73 64 59 51 48 43 38 33 23 17 14 12 8 6 3
>
> Each pair of readings was collected by checking the upstream capacity
> first, then moving the battery to a second expressatt running downstream
> Android to check its capacity. The battery was then moved back to the
> upstream device for the next reading. This swap occasionally caused the
> upstream capacity to read slightly higher than the previous value
> (e.g. 86 -> 87). When this happened, the reading was retaken after the
> value settled.
>
> Link: https://github.com/LineageOS/android_kernel_samsung_d2/blob/stable/cm-11.0-XNG3C/arch/arm/mach-msm/board-apexq-battery.c
> Link: https://github.com/LineageOS/android_kernel_samsung_d2/blob/stable/cm-11.0-XNG3C/drivers/battery/Makefile#L5
> Link: https://github.com/LineageOS/android_kernel_samsung_d2/blob/stable/cm-11.0-XNG3C/arch/arm/mach-msm/Makefile#L308
>
> Assisted-by: Claude:claude-opus-4.6
> Signed-off-by: Rudraksha Gupta <guptarud@gmail.com>
> ---
> .../dts/qcom/qcom-msm8960-samsung-expressatt.dts | 24 ++++++++++++++++++++++
> 1 file changed, 24 insertions(+)
>
Nice!
Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
--
With best wishes
Dmitry
^ permalink raw reply
* Re: [PATCH v2 6/7] dt-bindings: PCI: intel,lgm-pcie: Make atu resource mandatory
From: Florian Eckert @ 2026-04-01 11:20 UTC (permalink / raw)
To: Rob Herring
Cc: Lorenzo Pieralisi, Krzysztof Wilczyński,
Manivannan Sadhasivam, Bjorn Helgaas, Johan Hovold, Sajid Dalvi,
Ajay Agarwal, Krzysztof Kozlowski, Conor Dooley, Rahul Tanwar,
linux-pci, linux-kernel, devicetree, Eckert.Florian, ms
In-Reply-To: <20260331152150.GA1255126-robh@kernel.org>
On 2026-03-31 17:21, Rob Herring wrote:
> On Mon, Mar 30, 2026 at 11:07:16AM +0200, Florian Eckert wrote:
>> The ATU information is already set in the dwc core if it is specified
>> in
>> the DTS. The driver uses its own value here [1]. This information is
>> hardware specific and should therefore be maintained in the DTS rather
>> than in the source.
>>
>> Backwards compatibility is not an issue here [5], as the driver is
>> exclusively used by Maxlinear.
>>
>> Old DTS entry for PCIe:
>>
>> reg = <0xd1000000 0x1000>,
>> <0xd3000000 0x20000>,
>> <0xd0c41000.0x1000>;
>> reg-names = "dbi", "config", "app";
>>
>> New DTS entry for PCIe:
>>
>> reg = <0xd1000000 0x1000>,
>> <0xd10c0000 0x1000>,
>> <0xd3000000 0x20000>,
>> <0xd0c41000.0x1000>;
>> reg-names = "dbi", "atu", "config", "app";
>>
>> [1]
>> https://elixir.bootlin.com/linux/v6.19.10/source/drivers/pci/controller/dwc/pcie-intel-gw.c#L301
>> [2]
>> https://lore.kernel.org/all/BY3PR19MB507667CE7531D863E1E5F8AEBDD82@BY3PR19MB5076.namprd19.prod.outlook.com/
>>
>> Signed-off-by: Florian Eckert <fe@dev.tdt.de>
>> ---
>> Documentation/devicetree/bindings/pci/intel-gw-pcie.yaml | 5 ++++-
>> 1 file changed, 4 insertions(+), 1 deletion(-)
>>
>> diff --git a/Documentation/devicetree/bindings/pci/intel-gw-pcie.yaml
>> b/Documentation/devicetree/bindings/pci/intel-gw-pcie.yaml
>> index
>> 54e2890ae6314ac6847fc23f49440d05d66d87d4..e4b781f57e8ae84a3ffc33635a421e1a5761587e
>> 100644
>> --- a/Documentation/devicetree/bindings/pci/intel-gw-pcie.yaml
>> +++ b/Documentation/devicetree/bindings/pci/intel-gw-pcie.yaml
>> @@ -29,12 +29,14 @@ properties:
>> reg:
>> items:
>> - description: Controller control and status registers.
>> + - description: Internal Address Translation Unit (iATU)
>> registers.
>> - description: PCIe configuration registers.
>> - description: Controller application registers.
>>
>> reg-names:
>> items:
>> - const: dbi
>> + - const: atu
>
> Put this at the end and add 'minItems: 3' and you avoid any ABI issues.
Unfortunately, I misunderstood what you meant. This is still wrong in v3
[1]
I send to day. I’ve only changed it in the documentation. I forgot to do
that in the example, as I didn’t realize that we can not always access
resources by name, but also by index. That’s why the order matters. I’ve
got
it now.
Thanks!
My mistake – I’ll change that in v4 tomorrow so that your bot is happy
too.
--
Florian
[1]
https://lore.kernel.org/all/20260401-pcie-intel-gw-v3-0-63b008c5b7b2@dev.tdt.de/T/#t
>
>> - const: config
>> - const: app
>>
^ permalink raw reply
* Re: [PATCH v5 2/5] media: iris: scale MMCX power domain on SM8250
From: Dikshita Agarwal @ 2026-04-01 11:21 UTC (permalink / raw)
To: Dmitry Baryshkov, Ulf Hansson
Cc: Bjorn Andersson, Michael Turquette, Stephen Boyd, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Taniya Das, Jonathan Marek,
Rafael J. Wysocki, Bryan O'Donoghue, Vikash Garodia,
Mauro Carvalho Chehab, Stanimir Varbanov, Abhinav Kumar,
Hans Verkuil, Stefan Schmidt, Konrad Dybcio, Bryan O'Donoghue,
Dikshita Agarwal, linux-arm-msm, linux-clk, devicetree,
linux-kernel, linux-pm, linux-media, Mauro Carvalho Chehab
In-Reply-To: <4fiyjcqt5smotudsfzyqrevxxnx3sf5grbgfluzkndbp2od6pq@vlyikcvl3xkb>
On 4/1/2026 4:31 PM, Dmitry Baryshkov wrote:
> On Wed, Apr 01, 2026 at 12:46:01PM +0200, Ulf Hansson wrote:
>> On Tue, 31 Mar 2026 at 20:46, Dmitry Baryshkov
>> <dmitry.baryshkov@oss.qualcomm.com> wrote:
>>>
>>> On Tue, Mar 31, 2026 at 01:33:35PM +0200, Ulf Hansson wrote:
>>>> On Mon, 30 Mar 2026 at 15:06, Dikshita Agarwal
>>>> <dikshita.agarwal@oss.qualcomm.com> wrote:
>>>>>
>>>>>
>>>>>
>>>>> On 3/30/2026 4:45 PM, Dmitry Baryshkov wrote:
>>>>>> On Mon, Mar 30, 2026 at 10:55:02AM +0530, Dikshita Agarwal wrote:
>>>>>>>
>>>>>>>
>>>>>>> On 2/9/2026 7:02 AM, Dmitry Baryshkov wrote:
>>>>>>>> On SM8250 most of the video clocks are powered by the MMCX domain, while
>>>>>>>> the PLL is powered on by the MX domain. Extend the driver to support
>>>>>>>> scaling both power domains, while keeping compatibility with the
>>>>>>>> existing DTs, which define only the MX domain.
>>>>>>>>
>>>>>>>> Fixes: 79865252acb6 ("media: iris: enable video driver probe of SM8250 SoC")
>>>>>>>> Reviewed-by: Dikshita Agarwal <dikshita.agarwal@oss.qualcomm.com>
>>>>>>>> Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
>>>>>>>> ---
>>>>>>>> drivers/media/platform/qcom/iris/iris_platform_gen1.c | 2 +-
>>>>>>>> drivers/media/platform/qcom/iris/iris_probe.c | 7 +++++++
>>>>>>>> 2 files changed, 8 insertions(+), 1 deletion(-)
>>>>>>>>
>>>>>>>> diff --git a/drivers/media/platform/qcom/iris/iris_platform_gen1.c b/drivers/media/platform/qcom/iris/iris_platform_gen1.c
>>>>>>>> index df8e6bf9430e..aa71f7f53ee3 100644
>>>>>>>> --- a/drivers/media/platform/qcom/iris/iris_platform_gen1.c
>>>>>>>> +++ b/drivers/media/platform/qcom/iris/iris_platform_gen1.c
>>>>>>>> @@ -281,7 +281,7 @@ static const struct bw_info sm8250_bw_table_dec[] = {
>>>>>>>>
>>>>>>>> static const char * const sm8250_pmdomain_table[] = { "venus", "vcodec0" };
>>>>>>>>
>>>>>>>> -static const char * const sm8250_opp_pd_table[] = { "mx" };
>>>>>>>> +static const char * const sm8250_opp_pd_table[] = { "mx", "mmcx" };
>>>>>>>>
>>>>>>>> static const struct platform_clk_data sm8250_clk_table[] = {
>>>>>>>> {IRIS_AXI_CLK, "iface" },
>>>>>>>> diff --git a/drivers/media/platform/qcom/iris/iris_probe.c b/drivers/media/platform/qcom/iris/iris_probe.c
>>>>>>>> index 7b612ad37e4f..74ec81e3d622 100644
>>>>>>>> --- a/drivers/media/platform/qcom/iris/iris_probe.c
>>>>>>>> +++ b/drivers/media/platform/qcom/iris/iris_probe.c
>>>>>>>> @@ -64,6 +64,13 @@ static int iris_init_power_domains(struct iris_core *core)
>>>>>>>> return ret;
>>>>>>>>
>>>>>>>> ret = devm_pm_domain_attach_list(core->dev, &iris_opp_pd_data, &core->opp_pmdomain_tbl);
>>>>>>>> + /* backwards compatibility for incomplete ABI SM8250 */
>>>>>>>> + if (ret == -ENODEV &&
>>>>>>>> + of_device_is_compatible(core->dev->of_node, "qcom,sm8250-venus")) {
>>>>>>>> + iris_opp_pd_data.num_pd_names--;
>>>>>>>> + ret = devm_pm_domain_attach_list(core->dev, &iris_opp_pd_data,
>>>>>>>> + &core->opp_pmdomain_tbl);
>>>>>>>> + }
>>>>>>>> if (ret < 0)
>>>>>>>> return ret;
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>> Hitting below compilation error on latest kernel
>>>>>>>
>>>>>>> drivers/media/platform/qcom/iris/iris_probe.c: In function
>>>>>>> ‘iris_init_power_domains’:
>>>>>>> drivers/media/platform/qcom/iris/iris_probe.c:71:46: error: decrement of
>>>>>>> read-only member ‘num_pd_names’
>>>>>>> 71 | iris_opp_pd_data.num_pd_names--;
>>>>>>
>>>>>> See commit 7ad7f43e568b ("pmdomain: de-constify fields struct
>>>>>> dev_pm_domain_attach_data")
>>>>
>>>> The intent was for this patch to be part of v7.0-rc1, but I failed
>>>> with my pull-request to Linus.
>>>>
>>>> Instead this will be part of v7.1-rc1, assuming everything goes as expected.
>>>>
>>>> Is it possible to drop/defer these changes until v7.2?
>>>
>>> It would be very sad.
>>
>> Right.
>>
>> Since it's my mistake, let me reconsider. If I rebase my branch and
>> share the necessary commit through an immutable branch that you can
>> pull in. Would that work for you?
>
> I think that question goes to Vikash, Dikshita, Bryan and linux-media
> maintainers. Bryan, what is the plan for this patchset? Should Ulf
> rebase the branch? Or is this patchset delayed for some other reasons?
Its good to go, Bryan can comment as he will be raising the PR.
Thanks,
Dikshita
>
^ permalink raw reply
* RE: [PATCH 2/3] arm64: dts: realtek: Add GPIO support for RTD1625
From: Yu-Chun Lin [林祐君] @ 2026-04-01 11:21 UTC (permalink / raw)
To: Krzysztof Kozlowski
Cc: linusw@kernel.org, brgl@kernel.org, robh@kernel.org,
krzk+dt@kernel.org, conor+dt@kernel.org, afaerber@suse.com,
TY_Chang[張子逸], linux-gpio@vger.kernel.org,
devicetree@vger.kernel.org, linux-kernel@vger.kernel.org,
linux-arm-kernel@lists.infradead.org,
linux-realtek-soc@lists.infradead.org,
CY_Huang[黃鉦晏],
Stanley Chang[昌育德],
James Tai [戴志峰]
In-Reply-To: <20260401-liberal-nondescript-muskrat-0ebe93@quoll>
> On Tue, Mar 31, 2026 at 07:38:34PM +0800, Yu-Chun Lin wrote:
> > Add the GPIO node for the Realtek RTD1625 SoC.
> >
> > Signed-off-by: Yu-Chun Lin <eleanor.lin@realtek.com>
> > ---
> > arch/arm64/boot/dts/realtek/kent.dtsi | 43
> ++++++++++++++++++++++++
> > arch/arm64/boot/dts/realtek/rtd1501.dtsi | 8 +++++
> > arch/arm64/boot/dts/realtek/rtd1861.dtsi | 8 +++++
> > arch/arm64/boot/dts/realtek/rtd1920.dtsi | 8 +++++
> > 4 files changed, 67 insertions(+)
> >
>
> Why the DTS is in the middle? Drivers cannot depend on it. Please read
> submitting patches (both documents).
>
I will move DTS to the end in v2.
> > diff --git a/arch/arm64/boot/dts/realtek/kent.dtsi
> > b/arch/arm64/boot/dts/realtek/kent.dtsi
> > index 8d4293cd4c03..746932c26724 100644
> > --- a/arch/arm64/boot/dts/realtek/kent.dtsi
> > +++ b/arch/arm64/boot/dts/realtek/kent.dtsi
> > @@ -151,6 +151,39 @@ uart0: serial@7800 {
> > status = "disabled";
> > };
> >
> > + gpio: gpio@31100 {
> > + compatible = "realtek,rtd1625-iso-gpio";
> > + reg = <0x31100 0x398>,
> > + <0x31000 0x100>;
> > + gpio-controller;
> > + gpio-ranges = <&isom_pinctrl 0 0 2>,
> > + <&ve4_pinctrl 2 0 6>,
> > + <&iso_pinctrl 8 0 4>,
> > + <&ve4_pinctrl 12 6 2>,
> > + <&main2_pinctrl 14 0
> 2>,
> > + <&ve4_pinctrl 16 8 4>,
> > + <&main2_pinctrl 20 2
> 3>,
> > + <&ve4_pinctrl 23 12
> 3>,
> > + <&iso_pinctrl 26 4 2>,
> > + <&isom_pinctrl 28 2
> 2>,
> > + <&ve4_pinctrl 30 15
> 6>,
> > + <&main2_pinctrl 36 5
> 6>,
> > + <&ve4_pinctrl 42 21
> 3>,
> > + <&iso_pinctrl 45 6 6>,
> > + <&ve4_pinctrl 51 24
> 1>,
> > + <&iso_pinctrl 52 12
> 1>,
> > + <&ve4_pinctrl 53 25
> 11>,
> > + <&main2_pinctrl 64
> 11 28>,
> > + <&ve4_pinctrl 92 36
> 2>,
> > + <&iso_pinctrl 94 13
> 19>,
> > + <&iso_pinctrl 128 32
> 4>,
> > + <&ve4_pinctrl 132 38
> 13>,
> > + <&iso_pinctrl 145 36
> 19>,
> > + <&ve4_pinctrl 164 51
> 2>;
> > + #gpio-cells = <2>;
> > + status = "disabled";
>
> Why is it disabled? What is missing in the SoC? Which resources are missing?
>
Nothing is missing, so I will remove status = "disabled".
> > + };
> > +
> > iso_pinctrl: pinctrl@4e000 {
> > compatible =
> "realtek,rtd1625-iso-pinctrl";
> > reg = <0x4e000 0x1a4>; @@ -161,6
> +194,16
> > @@ main2_pinctrl: pinctrl@4f200 {
> > reg = <0x4f200 0x50>;
> > };
> >
> > + iso_m_gpio: gpio@89120 {
> > + compatible =
> "realtek,rtd1625-isom-gpio";
> > + reg = <0x89120 0x10>,
> > + <0x89100 0x20>;
> > + gpio-controller;
> > + gpio-ranges = <&isom_pinctrl 0 0 4>;
> > + #gpio-cells = <2>;
> > + status = "disabled";
> > + };
> > +
> > isom_pinctrl: pinctrl@146200 {
> > compatible =
> "realtek,rtd1625-isom-pinctrl";
> > reg = <0x146200 0x34>; diff --git
> > a/arch/arm64/boot/dts/realtek/rtd1501.dtsi
> > b/arch/arm64/boot/dts/realtek/rtd1501.dtsi
> > index 65f7ede3df73..ae246a01f126 100644
> > --- a/arch/arm64/boot/dts/realtek/rtd1501.dtsi
> > +++ b/arch/arm64/boot/dts/realtek/rtd1501.dtsi
> > @@ -10,3 +10,11 @@
> > &uart0 {
> > status = "okay";
> > };
> > +
> > +&gpio {
>
> Why aren't you following DTS coding style? What style is applicable for
> Realtek?
>
> Best regards,
> Krzysztof
I should sort them in alphabetical order. But after removing the status property,
the board-level node will be removed entirely.
Best regards,
Yu-Chun
^ permalink raw reply
* Re: [PATCH v6 0/2] TQ-Systems TQMa62xx SoM and MBa62xx board
From: Nora Schiffer @ 2026-04-01 11:22 UTC (permalink / raw)
To: Nishanth Menon, Vignesh Raghavendra, Tero Kristo
Cc: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Kees Cook,
Tony Luck, Guilherme G. Piccoli, linux-arm-kernel, devicetree,
linux-kernel, linux
In-Reply-To: <6e34ecefae8e2f187c5ecfdfd343fb717711c21d.camel@ew.tq-group.com>
On Tue, 2026-03-17 at 10:08 +0100, Nora Schiffer wrote:
> On Mon, 2026-03-02 at 11:14 +0100, Nora Schiffer wrote:
> > This adds Device Trees for our AM62x-based SoM TQMa62xx and its
> > reference carrier board MBa62xx.
> >
> > Not yet included are overlays to enable LVDS display output and MIPI-CSI
> > camera input.
>
> Hi Nishanth,
>
> do you have any further comments on these patches? Can we get the series into
> v7.1?
>
> Best,
> Nora
Hi Vignesh,
ti-k3-dt-for-v7.1 is tagged now, does that mean we missed the window to get this
series applied again? If there are still any issues, I'll gladly fix them up,
but we have not received any review comments on this last revision of the
patches.
Best,
Nora
>
>
>
>
> >
> > Changed in v6:
> > - Update author information following name change
> > - Rebase onto latest ti-k3-dts-next
> > - Disable incomplete panel node
> > - Add various comments to explain why nodes are disabled
> > - Extend comment explaining disabled 1400MHz OPP
> > - Use consistent comment style for pinmux
> >
> > Changes in v5:
> > - Rebase onto latest ti-k3-dts-next
> >
> > Changes in v4:
> > - Rebase onto latest ti-k3-dts-next
> > - Reorder boot phase tags after other standard DT properties
> > - Add missing supply regulators in SPI-NOR flash and USB hub
> > - Set status = "okay" in &cpsw3g, as it is disabled in k3-am62-main.dtsi
> > now
> > - Add disabled 1400MHz OPP entry (will be enabled by bootloader if
> > supported by PMIC configuration)
> > - Update copyright years in new files
> >
> > Changes in v3:
> > - Rebased onto ti-k3-dt-for-v6.18
> > - 3 of the 5 patches in v2 have been applied already and are dropped
> > - Include k3-am62-ti-ipc-firmware.dtsi, drop now redundant configuration
> > - Change node name for MCU reserved memory to 'memory'
> > - Use rgmii-id PHY mode
> > - Drop now redundant ti,rx-internal-delay
> > - Update simple-audio-card,name to match other TQ SOMs with compatible
> > configuration
> > - Reference dss_pins in dss node (actual display support will be added
> > in a follow-up patch series)
> > - Consistently use GPIO_ACTIVE_HIGH define
> > - Drop unneeded usb0 quirk flags
> > - Add boot phase tags
> >
> > Changes in v2:
> > - Collected acks and reviews
> > - Rebased onto v6.13-rc1
> >
> >
> > Nora Schiffer (2):
> > dt-bindings: arm: ti: Add compatible for AM625-based TQMa62xx SOM
> > family and carrier board
> > arm64: dts: ti: Add TQ-Systems TQMa62xx SoM and MBa62xx carrier board
> > Device Trees
> >
> > .../devicetree/bindings/arm/ti/k3.yaml | 7 +
> > arch/arm64/boot/dts/ti/Makefile | 1 +
> > .../boot/dts/ti/k3-am625-tqma62xx-mba62xx.dts | 1034 +++++++++++++++++
> > arch/arm64/boot/dts/ti/k3-am625-tqma62xx.dtsi | 360 ++++++
> > 4 files changed, 1402 insertions(+)
> > create mode 100644 arch/arm64/boot/dts/ti/k3-am625-tqma62xx-mba62xx.dts
> > create mode 100644 arch/arm64/boot/dts/ti/k3-am625-tqma62xx.dtsi
> >
>
--
TQ-Systems GmbH | Mühlstraße 2, Gut Delling | 82229 Seefeld, Germany
Amtsgericht München, HRB 105018
Geschäftsführer: Detlef Schneider, Rüdiger Stahl, Stefan Schneider
https://www.tq-group.com/
^ permalink raw reply
* Re: [PATCH 2/2] spmi: spmi-pmic-arb: add support for PMIC arbiter v8.5
From: Dmitry Baryshkov @ 2026-04-01 11:22 UTC (permalink / raw)
To: Fenglin Wu
Cc: Stephen Boyd, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Konrad Dybcio, Subbaraman Narayanamurthy, David Collins,
linux-arm-msm, linux-kernel, devicetree, kernel
In-Reply-To: <20260401-hawi-spmi-v1-2-c40963041078@oss.qualcomm.com>
On Wed, Apr 01, 2026 at 02:41:24AM -0700, Fenglin Wu wrote:
> PMIC arbiter v8.5 is an extension of PMIC arbiter v8 that updated
> the definition of the channel status register bit fields. Add support
> to handle this difference.
>
> Signed-off-by: Fenglin Wu <fenglin.wu@oss.qualcomm.com>
> ---
> drivers/spmi/spmi-pmic-arb.c | 69 ++++++++++++++++++++++++++++++++++++++------
> 1 file changed, 60 insertions(+), 9 deletions(-)
>
> diff --git a/drivers/spmi/spmi-pmic-arb.c b/drivers/spmi/spmi-pmic-arb.c
> index 69f8d456324a..deeaa39bb647 100644
> --- a/drivers/spmi/spmi-pmic-arb.c
> +++ b/drivers/spmi/spmi-pmic-arb.c
> @@ -28,6 +28,7 @@
> #define PMIC_ARB_VERSION_V5_MIN 0x50000000
> #define PMIC_ARB_VERSION_V7_MIN 0x70000000
> #define PMIC_ARB_VERSION_V8_MIN 0x80000000
> +#define PMIC_ARB_VERSION_V8P5_MIN 0x80050000
> #define PMIC_ARB_INT_EN 0x0004
>
> #define PMIC_ARB_FEATURES 0x0004
> @@ -63,11 +64,34 @@
> #define SPMI_OWNERSHIP_PERIPH2OWNER(X) ((X) & 0x7)
>
> /* Channel Status fields */
> -enum pmic_arb_chnl_status {
> - PMIC_ARB_STATUS_DONE = BIT(0),
> - PMIC_ARB_STATUS_FAILURE = BIT(1),
> - PMIC_ARB_STATUS_DENIED = BIT(2),
> - PMIC_ARB_STATUS_DROPPED = BIT(3),
> +struct pmic_arb_chnl_status_mask {
> + u8 done;
> + u8 failure;
> + u8 crc;
> + u8 parity;
> + u8 nack;
> + u8 denied;
> + u8 dropped;
> +};
> +
> +static const struct pmic_arb_chnl_status_mask chnl_status_mask = {
> + .done = BIT(0),
> + .failure = BIT(1),
> + .crc = 0,
> + .parity = 0,
> + .nack = 0,
> + .denied = BIT(2),
> + .dropped = BIT(3),
> +};
> +
> +static const struct pmic_arb_chnl_status_mask chnl_status_mask_v8p5 = {
> + .done = BIT(0),
> + .failure = BIT(1),
> + .crc = BIT(2),
> + .parity = BIT(3),
> + .nack = BIT(4),
> + .denied = BIT(5),
> + .dropped = BIT(6),
Would it be better to extract generation-specific callback to decode the
error rather than defining the list of masks?
> };
>
> /* Command register fields */
--
With best wishes
Dmitry
^ permalink raw reply
* [PATCH v3 0/2] Make TPS65219 poweroff handler conditional
From: Akashdeep Kaur @ 2026-04-01 11:22 UTC (permalink / raw)
To: lee, praneeth, nm, afd, vigneshr, kristo, robh, krzk+dt, conor+dt,
aaro.koskinen, andreas, khilman, rogerq, tony, linux-arm-kernel,
devicetree, linux-kernel, linux-omap, s-ramamoorthy
Cc: vishalm, sebin.francis, d-gole, k-willis, a-kaur
This series makes the TPS65219 PMIC poweroff handler registration
conditional based on device tree configuration, following standard
kernel patterns.
Currently, the TPS65219 driver unconditionally registers as the system
poweroff handler. This creates conflicts on platforms where alternative
poweroff mechanisms (such as TF-A firmware or other power controllers)
should handle system shutdown instead.
The standard kernel approach is to use the "system-power-controller"
device tree property to explicitly designate which component is
responsible for system poweroff operations.
Patch 1: Add "system-power-controller" property to AM62-LP-SK device
tree, explicitly designating the TPS65219 PMIC as the system
power controller for this platform. This property was missing
only on AM62-LP-SK among all in-tree TPS65219-based devices.
Patch 2: Update TPS65219 driver to only register poweroff handler when
"system-power-controller" property is present. This allows
other systems using this PMIC to use alternative poweroff
mechanisms.
Impact:
- AM62-LP-SK: No functional change (property added, handler still
registers)
- Other TPS65219-based systems: Poweroff handler registration becomes
opt-in via DT property
Tested on AM62-LP-SK - system poweroff works correctly.
Changes in v3:
- Fixed minor formatting issues in PMIC driver
- Link to v2: https://lore.kernel.org/all/20260324101419.95616-1-a-kaur@ti.com/
Changes in v2:
- Addressed review feedback by removing comment on self explanatory code
- Link to v1: https://lore.kernel.org/all/20260310111846.1084623-1-a-kaur@ti.com/
Signed-off-by: Akashdeep Kaur <a-kaur@ti.com>
---
Akashdeep Kaur (2):
arm64: dts: ti: k3-am62-lp-sk: Add system-power-controller
mfd: tps65219: Make poweroff handler conditional on
system-power-controller
arch/arm64/boot/dts/ti/k3-am62-lp-sk.dts | 1 +
drivers/mfd/tps65219.c | 14 ++++++++------
2 files changed, 9 insertions(+), 6 deletions(-)
--
2.34.1
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox