* Re: [PATCH 1/2] dt-bindings: arm: cpus: Restore qcom,oryon-1-4 compatible
From: Konrad Dybcio @ 2026-04-13 9:57 UTC (permalink / raw)
To: Shawn Guo, Bjorn Andersson
Cc: Konrad Dybcio, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Bartosz Golaszewski, Deepti Jaggi, linux-arm-msm, devicetree,
linux-kernel
In-Reply-To: <20260413091625.607976-2-shengchao.guo@oss.qualcomm.com>
On 4/13/26 11:16 AM, Shawn Guo wrote:
> It seems that compatible qcom,oryon-1-4 was accidentally dropped during
> the conflict resolution in commit f6935ae6147b ("Merge branch 'for-next'
> of https://git.kernel.org/pub/scm/linux/kernel/git/robh/linux.git").
> Restore it.
>
> Signed-off-by: Shawn Guo <shengchao.guo@oss.qualcomm.com>
> ---
Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
Konrad
^ permalink raw reply
* Re: Phandles
From: Krzysztof Kozlowski @ 2026-04-13 9:57 UTC (permalink / raw)
To: Kyle Bonnici
Cc: Herve Codina, devicetree-compiler@vger.kernel.org, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, devicetree@vger.kernel.org
In-Reply-To: <DB5F7CA0-08E8-4CF5-9815-598002AF471F@hotmail.com>
On 13/04/2026 11:50, Kyle Bonnici wrote:
>
>> You cannot have random values. I quoted the DT spec.
>
> Where in the DTS 0.4 spec are property names such as pwms, clocks
> etc… mandated to be of format <phandle cell …>?
Ah, true, this is not expressed but DT spec defines types for only a few
cases.
>
>> Well, we don't use discord but IRC... but that github issue also uses
>> "pwms = <1 &pwm0 1 20 PWM_POLARITY_NORMAL>;"
>>
>> So again - what is "1"?
>>
>> I am asking because if you use incorrect value as phandle value, then
>> DTC warning is obviously expected and nothing to fix here.
>
> The warning is only valid if ‘1’ is expected to be a phandle which is what I am
> Arguing the spec does not mandate this.
The "&foo" used in the property defines that it is phandle, no?
>
>> You asked why phandle has to be the first entry in phandle-value type? I
>> responded that DT spec makes it.
>
> Which section in DTS 0.4 spec?
2.2.4.2. Property Values
"That number is used for the value of properties with a phandle value type.
The properties having phandle value must have proper, well, value :)
>
>> We discuss DTC here, yes? Whether it has or has not a bug? Please help
>> me to understand the topic. Why would we care about Zephyr's
>> implementation? It's Zephyr's problem and I am not a Zephyr developer. I
>> am not saying that it is not important, just saying that I am not the
>> audience to discuss it.
>
> I am arguing that the DTC Spec 0.4 does NOT mandate any of these any of these
> “cooling_device”, “dmas”, “hwlocks”, “io_channels”, “iommus”, “mboxes”,
> “msi_parent”, “mux_controls”, “phys”, “power_domains”, “pwms”, “resets”,
> “clocks”, “sound_dai” and “thermal_sensors”
> must follow <phandle cell …>.
>
> This is only mandated by the dt-schema as far as I understand, that is a used by
> Linux, but not Zephyr and the DTC Making the assumption that this is true for
> all systems
No, dtschema is irrelevant here and DTC was validating it since 2017, so
years before dtschema.
DT spec indeed does not mandate it as pwms, but replacing that check in
DTC with something only validating phandles would not solve your
problem. Your 'pwm' is a phandle-value type, because you use phandle
there, and still is has wrong value.
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH 2/2] dt-bindings: arm: cpus: Add compatible qcom,oryon-1-5
From: Konrad Dybcio @ 2026-04-13 9:58 UTC (permalink / raw)
To: Shawn Guo, Bjorn Andersson
Cc: Konrad Dybcio, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Bartosz Golaszewski, Deepti Jaggi, linux-arm-msm, devicetree,
linux-kernel
In-Reply-To: <20260413091625.607976-3-shengchao.guo@oss.qualcomm.com>
On 4/13/26 11:16 AM, Shawn Guo wrote:
> Qualcomm Oryon 1-5 is found on Nord SoC. Add compatible for it.
>
> $ cat /proc/cpuinfo
> ...
> CPU implementer : 0x51
> CPU architecture: 8
> CPU variant : 0x5
> CPU part : 0x001
> CPU revision : 4
>
> Signed-off-by: Shawn Guo <shengchao.guo@oss.qualcomm.com>
> ---
Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
Konrad
^ permalink raw reply
* Re: [PATCH 1/2] dt-bindings: arm: cpus: Restore qcom,oryon-1-4 compatible
From: Krzysztof Kozlowski @ 2026-04-13 10:01 UTC (permalink / raw)
To: Shawn Guo, Bjorn Andersson
Cc: Konrad Dybcio, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Bartosz Golaszewski, Deepti Jaggi, linux-arm-msm, devicetree,
linux-kernel
In-Reply-To: <20260413091625.607976-2-shengchao.guo@oss.qualcomm.com>
On 13/04/2026 11:16, Shawn Guo wrote:
> It seems that compatible qcom,oryon-1-4 was accidentally dropped during
> the conflict resolution in commit f6935ae6147b ("Merge branch 'for-next'
Don't reference commits which will never make to Linux kernel.
> of https://git.kernel.org/pub/scm/linux/kernel/git/robh/linux.git").
> Restore it.
>
> Signed-off-by: Shawn Guo <shengchao.guo@oss.qualcomm.com>
Well, I said that merge will be difficult but Mark was sure merge is
trivial, so here we are.
Anyway, this cannot be applied. How do you exactly see it? Which tree?
Try yourself...
> ---
> Documentation/devicetree/bindings/arm/cpus.yaml | 1 +
> 1 file changed, 1 insertion(+)
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH 2/2] dt-bindings: arm: cpus: Add compatible qcom,oryon-1-5
From: Krzysztof Kozlowski @ 2026-04-13 10:02 UTC (permalink / raw)
To: Shawn Guo, Bjorn Andersson
Cc: Konrad Dybcio, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Bartosz Golaszewski, Deepti Jaggi, linux-arm-msm, devicetree,
linux-kernel
In-Reply-To: <20260413091625.607976-3-shengchao.guo@oss.qualcomm.com>
On 13/04/2026 11:16, Shawn Guo wrote:
> Qualcomm Oryon 1-5 is found on Nord SoC. Add compatible for it.
>
> $ cat /proc/cpuinfo
> ...
> CPU implementer : 0x51
> CPU architecture: 8
> CPU variant : 0x5
> CPU part : 0x001
> CPU revision : 4
>
> Signed-off-by: Shawn Guo <shengchao.guo@oss.qualcomm.com>
> ---
> Documentation/devicetree/bindings/arm/cpus.yaml | 1 +
> 1 file changed, 1 insertion(+)
No. I said many times. Bindings come with the user. We don't care what
is in cpuinfo of some non-upstream board (and lack of user means it is
non-upstream currently).
Please organize your patchset correctly.
Best regards,
Krzysztof
^ permalink raw reply
* [PATCH v2 0/6] ASoC: renesas: fsi: Fix system hang by adding SPU clock
From: phucduc.bui @ 2026-04-13 10:06 UTC (permalink / raw)
To: kuninori.morimoto.gx, broonie
Cc: lgirdwood, robh, krzk+dt, conor+dt, geert+renesas, magnus.damm,
perex, tiwai, linux-sound, linux-renesas-soc, devicetree,
linux-kernel, bui duc phuc
From: bui duc phuc <phucduc.bui@gmail.com>
Hi all,
The FSI on r8a7740 requires the SPU clock to be enabled before accessing
its internal registers. Without this clock, register access can lead to a
system hang, even when the FSI functional clock is properly enabled.
This series adds the missing clocks and aligns their names with those
used in the driver.
Following feedback from Morimoto-san, the driver is refactored to improve
stability. Clock initialization is moved from the runtime path to the probe
function to simplify the flow and avoid redundant setups. Additionally, the
shutdown sequence is reordered to ensure the stream is properly stopped
before the hardware is shut down.
Changes in v2:
- DT Bindings:
Define "own" clock and add "spu", "icka/b", "diva/b", "xcka/b" to the
clock tree.
Use YAML anchors and "if" rules to enforce clock-names and r8a7740
requirements.
Relocate allOf block and update example with full 8-clock configuration.
- DTS:
Rename "fsi" clock to "own" to match driver implementation.
Add missing clock names: "icka", "ickb", "xcka", "xckb".
- In the driver:
Refactor clock initialization.
Reorder shutdown: stop stream before hardware shutdown.
Move SPU clock enable/disable handling to fsi_hw_startup/shutdown.
v1 links :
https://lore.kernel.org/all/20260403112655.167593-1-phucduc.bui@gmail.com/
Testing:
- Verified on r8a7740 (Armadillo-800EVA): FSI slave / Codec master mode.
- FSI master mode is currently compile-tested only. Full verification
requires a dedicated HDMI driver (FSIB) or hardware modifications
(resoldering board resistors) (FSIA).Full support for fsidiv requires
additional DT bindings and a corresponding driver.
bui duc phuc (6):
ASoC: renesas: fsi: Add shared SPU clock support
ASoC: renesas: fsi: Fix hang by enabling SPU clock
ASoC: renesas: fsi: Fix trigger stop ordering
ASoC: renesas: fsi: refactor clock initialization
arm: dts: renesas: r8a7740: Add clocks for FSI
ASoC: dt-bindings: renesas,fsi: add support for multiple clocks
.../bindings/sound/renesas,fsi.yaml | 61 +++++-
arch/arm/boot/dts/renesas/r8a7740.dtsi | 12 +-
sound/soc/renesas/fsi.c | 181 ++++++++++--------
3 files changed, 171 insertions(+), 83 deletions(-)
--
2.43.0
^ permalink raw reply
* [PATCH v2 1/6] ASoC: renesas: fsi: Add shared SPU clock support
From: phucduc.bui @ 2026-04-13 10:06 UTC (permalink / raw)
To: kuninori.morimoto.gx, broonie
Cc: lgirdwood, robh, krzk+dt, conor+dt, geert+renesas, magnus.damm,
perex, tiwai, linux-sound, linux-renesas-soc, devicetree,
linux-kernel, bui duc phuc
In-Reply-To: <20260413100700.30995-1-phucduc.bui@gmail.com>
From: bui duc phuc <phucduc.bui@gmail.com>
Add SPU clock pointer, reference counter, and locking in fsi_master for
shared FSIA/FSIB usage, and initialize them in fsi_probe().
Signed-off-by: bui duc phuc <phucduc.bui@gmail.com>
---
Changes in v2:
- Add spu_count to track active users of the SPU clock.
- Add clk_lock mutex to prevent race conditions during SPU clock
enable/disable operations.
- Initialize spu_count and clk_lock during driver probe.
sound/soc/renesas/fsi.c | 5 +++++
1 file changed, 5 insertions(+)
diff --git a/sound/soc/renesas/fsi.c b/sound/soc/renesas/fsi.c
index 1491c2f2cc96..196ec7bac33d 100644
--- a/sound/soc/renesas/fsi.c
+++ b/sound/soc/renesas/fsi.c
@@ -292,8 +292,11 @@ struct fsi_master {
void __iomem *base;
struct fsi_priv fsia;
struct fsi_priv fsib;
+ struct clk *clk_spu;
const struct fsi_core *core;
+ int spu_count;
spinlock_t lock;
+ struct mutex clk_lock;
};
static inline int fsi_stream_is_play(struct fsi_priv *fsi,
@@ -1961,7 +1964,9 @@ static int fsi_probe(struct platform_device *pdev)
/* master setting */
master->core = core;
+ master->spu_count = 0;
spin_lock_init(&master->lock);
+ mutex_init(&master->clk_lock);
/* FSI A setting */
fsi = &master->fsia;
--
2.43.0
^ permalink raw reply related
* [PATCH v2 2/6] ASoC: renesas: fsi: Fix hang by enabling SPU clock
From: phucduc.bui @ 2026-04-13 10:06 UTC (permalink / raw)
To: kuninori.morimoto.gx, broonie
Cc: lgirdwood, robh, krzk+dt, conor+dt, geert+renesas, magnus.damm,
perex, tiwai, linux-sound, linux-renesas-soc, devicetree,
linux-kernel, bui duc phuc
In-Reply-To: <20260413100700.30995-1-phucduc.bui@gmail.com>
From: bui duc phuc <phucduc.bui@gmail.com>
Enable/disable the shared SPU clock in hw startup/shutdown. Without this,
accessing FSI registers may hang the system.
Suggested-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Signed-off-by: bui duc phuc <phucduc.bui@gmail.com>
---
Changes in v2:
- Move SPU clock enable/disable handling from fsi_dai_startup/shutdown
to fsi_hw_startup/shutdown
sound/soc/renesas/fsi.c | 17 +++++++++++++++++
1 file changed, 17 insertions(+)
diff --git a/sound/soc/renesas/fsi.c b/sound/soc/renesas/fsi.c
index 196ec7bac33d..109e06b5f32d 100644
--- a/sound/soc/renesas/fsi.c
+++ b/sound/soc/renesas/fsi.c
@@ -1492,6 +1492,18 @@ static int fsi_hw_startup(struct fsi_priv *fsi,
struct device *dev)
{
u32 data = 0;
+ int ret = 0;
+ /* enable spu clock */
+ mutex_lock(&fsi->master->clk_lock);
+ if (fsi->master->clk_spu && fsi->master->spu_count++ == 0) {
+ ret = clk_prepare_enable(fsi->master->clk_spu);
+ if (ret < 0) {
+ fsi->master->spu_count--;
+ mutex_unlock(&fsi->master->clk_lock);
+ return ret;
+ }
+ }
+ mutex_unlock(&fsi->master->clk_lock);
/* clock setting */
if (fsi_is_clk_master(fsi))
@@ -1549,6 +1561,11 @@ static int fsi_hw_shutdown(struct fsi_priv *fsi,
/* stop master clock */
if (fsi_is_clk_master(fsi))
return fsi_clk_disable(dev, fsi);
+ /* stop spu clock */
+ mutex_lock(&fsi->master->clk_lock);
+ if (fsi->master->clk_spu && --fsi->master->spu_count == 0)
+ clk_disable_unprepare(fsi->master->clk_spu);
+ mutex_unlock(&fsi->master->clk_lock);
return 0;
}
--
2.43.0
^ permalink raw reply related
* [PATCH v2 3/6] ASoC: renesas: fsi: Fix trigger stop ordering
From: phucduc.bui @ 2026-04-13 10:06 UTC (permalink / raw)
To: kuninori.morimoto.gx, broonie
Cc: lgirdwood, robh, krzk+dt, conor+dt, geert+renesas, magnus.damm,
perex, tiwai, linux-sound, linux-renesas-soc, devicetree,
linux-kernel, bui duc phuc
In-Reply-To: <20260413100700.30995-1-phucduc.bui@gmail.com>
From: bui duc phuc <phucduc.bui@gmail.com>
Reorder calls to execute fsi_stream_stop() before fsi_hw_shutdown().
This ensures that all register accesses are completed before the clock is
disabled, preventing the system hang observed on r8a7740.
Suggested-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Signed-off-by: bui duc phuc <phucduc.bui@gmail.com>
---
sound/soc/renesas/fsi.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/sound/soc/renesas/fsi.c b/sound/soc/renesas/fsi.c
index 109e06b5f32d..9df3e91ac79c 100644
--- a/sound/soc/renesas/fsi.c
+++ b/sound/soc/renesas/fsi.c
@@ -1606,9 +1606,9 @@ static int fsi_dai_trigger(struct snd_pcm_substream *substream, int cmd,
ret = fsi_stream_transfer(io);
break;
case SNDRV_PCM_TRIGGER_STOP:
+ fsi_stream_stop(fsi, io);
if (!ret)
ret = fsi_hw_shutdown(fsi, dai->dev);
- fsi_stream_stop(fsi, io);
fsi_stream_quit(fsi, io);
break;
}
--
2.43.0
^ permalink raw reply related
* [PATCH v2 4/6] ASoC: renesas: fsi: refactor clock initialization
From: phucduc.bui @ 2026-04-13 10:06 UTC (permalink / raw)
To: kuninori.morimoto.gx, broonie
Cc: lgirdwood, robh, krzk+dt, conor+dt, geert+renesas, magnus.damm,
perex, tiwai, linux-sound, linux-renesas-soc, devicetree,
linux-kernel, bui duc phuc
In-Reply-To: <20260413100700.30995-1-phucduc.bui@gmail.com>
From: bui duc phuc <phucduc.bui@gmail.com>
Move fsi_clk_init() out of set_fmt() and handle clock master logic
internally. This simplifies the flow and aligns with probe-time
initialization.
Suggested-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Signed-off-by: bui duc phuc <phucduc.bui@gmail.com>
---
Note: Due to hardware limitations, only slave mode has been verified.
Testing master mode requires resoldering board resistors or
developing an HDMI driver, so master mode logic is currently
compile-tested only. Full support for fsidiv requires additional
DT bindings and a corresponding driver.
sound/soc/renesas/fsi.c | 157 +++++++++++++++++++++-------------------
1 file changed, 81 insertions(+), 76 deletions(-)
diff --git a/sound/soc/renesas/fsi.c b/sound/soc/renesas/fsi.c
index 9df3e91ac79c..db4ddc30f44f 100644
--- a/sound/soc/renesas/fsi.c
+++ b/sound/soc/renesas/fsi.c
@@ -709,73 +709,6 @@ static void fsi_spdif_clk_ctrl(struct fsi_priv *fsi, int enable)
fsi_core_mask_set(master, b_mclk, mask, val);
}
-/*
- * clock function
- */
-static int fsi_clk_init(struct device *dev,
- struct fsi_priv *fsi,
- int xck,
- int ick,
- int div,
- int (*set_rate)(struct device *dev,
- struct fsi_priv *fsi))
-{
- struct fsi_clk *clock = &fsi->clock;
- int is_porta = fsi_is_port_a(fsi);
-
- clock->xck = NULL;
- clock->ick = NULL;
- clock->div = NULL;
- clock->rate = 0;
- clock->count = 0;
- clock->set_rate = set_rate;
-
- clock->own = devm_clk_get(dev, NULL);
- if (IS_ERR(clock->own))
- return -EINVAL;
-
- /* external clock */
- if (xck) {
- clock->xck = devm_clk_get(dev, is_porta ? "xcka" : "xckb");
- if (IS_ERR(clock->xck)) {
- dev_err(dev, "can't get xck clock\n");
- return -EINVAL;
- }
- if (clock->xck == clock->own) {
- dev_err(dev, "cpu doesn't support xck clock\n");
- return -EINVAL;
- }
- }
-
- /* FSIACLK/FSIBCLK */
- if (ick) {
- clock->ick = devm_clk_get(dev, is_porta ? "icka" : "ickb");
- if (IS_ERR(clock->ick)) {
- dev_err(dev, "can't get ick clock\n");
- return -EINVAL;
- }
- if (clock->ick == clock->own) {
- dev_err(dev, "cpu doesn't support ick clock\n");
- return -EINVAL;
- }
- }
-
- /* FSI-DIV */
- if (div) {
- clock->div = devm_clk_get(dev, is_porta ? "diva" : "divb");
- if (IS_ERR(clock->div)) {
- dev_err(dev, "can't get div clock\n");
- return -EINVAL;
- }
- if (clock->div == clock->own) {
- dev_err(dev, "cpu doesn't support div clock\n");
- return -EINVAL;
- }
- }
-
- return 0;
-}
-
#define fsi_clk_invalid(fsi) fsi_clk_valid(fsi, 0)
static void fsi_clk_valid(struct fsi_priv *fsi, unsigned long rate)
{
@@ -921,6 +854,10 @@ static int fsi_clk_set_rate_external(struct device *dev,
int ackmd, bpfmd;
int ret = 0;
+ if (!xck || !ick) {
+ dev_err(dev, "External (xck) or Internal (ick) clock is missing\n");
+ return -EINVAL;
+ }
/* check clock rate */
xrate = clk_get_rate(xck);
if (xrate % rate) {
@@ -957,6 +894,11 @@ static int fsi_clk_set_rate_cpg(struct device *dev,
int ackmd, bpfmd;
int ret = -EINVAL;
+ if (!ick || !div) {
+ dev_err(dev, "Internal (ick) or Divider (div) clock is missing\n");
+ return -EINVAL;
+ }
+
if (!(12288000 % rate))
target = 12288000;
if (!(11289600 % rate))
@@ -1029,6 +971,76 @@ static int fsi_clk_set_rate_cpg(struct device *dev,
return ret;
}
+/*
+ * clock function
+ */
+static int fsi_clk_init(struct device *dev, struct fsi_priv *fsi, int is_cpg)
+{
+ struct fsi_clk *clock = &fsi->clock;
+ struct fsi_master *master = fsi->master;
+ int is_porta = fsi_is_port_a(fsi);
+ int xck, ick, div;
+
+ if (is_cpg) {
+ xck = 0; ick = 1; div = 1;
+ clock->set_rate = fsi_clk_set_rate_cpg;
+ } else {
+ xck = 1; ick = 1; div = 0;
+ clock->set_rate = fsi_clk_set_rate_external;
+ }
+
+ clock->xck = NULL;
+ clock->ick = NULL;
+ clock->div = NULL;
+ clock->rate = 0;
+ clock->count = 0;
+
+ clock->own = devm_clk_get(dev, NULL);
+ if (IS_ERR(clock->own))
+ return -EINVAL;
+
+ if (!master->clk_spu) {
+ master->clk_spu = devm_clk_get_optional(dev, "spu");
+ if (IS_ERR(master->clk_spu))
+ return PTR_ERR(master->clk_spu);
+ }
+
+ /* external clock */
+ if (xck) {
+ clock->xck = devm_clk_get_optional(dev, is_porta ? "xcka" : "xckb");
+ if (IS_ERR(clock->xck))
+ return dev_err_probe(dev, PTR_ERR(clock->xck), "Can't get xck clock\n");
+ if (clock->xck == clock->own) {
+ dev_err(dev, "cpu doesn't support xck clock\n");
+ return -EINVAL;
+ }
+ }
+
+ /* FSIACLK/FSIBCLK */
+ if (ick) {
+ clock->ick = devm_clk_get_optional(dev, is_porta ? "icka" : "ickb");
+ if (IS_ERR(clock->ick))
+ return dev_err_probe(dev, PTR_ERR(clock->ick), "Can't get ick clock\n");
+ if (clock->ick == clock->own) {
+ dev_err(dev, "cpu doesn't support ick clock\n");
+ return -EINVAL;
+ }
+ }
+
+ /* FSI-DIV */
+ if (div) {
+ clock->div = devm_clk_get_optional(dev, is_porta ? "diva" : "divb");
+ if (IS_ERR(clock->div))
+ return dev_err_probe(dev, PTR_ERR(clock->div), "Can't get div clock\n");
+ if (clock->div == clock->own) {
+ dev_err(dev, "cpu doesn't support div clock\n");
+ return -EINVAL;
+ }
+ }
+
+ return 0;
+}
+
static void fsi_pointer_update(struct fsi_stream *io, int size)
{
io->buff_sample_pos += size;
@@ -1684,15 +1696,6 @@ static int fsi_dai_set_fmt(struct snd_soc_dai *dai, unsigned int fmt)
break;
}
- if (fsi_is_clk_master(fsi)) {
- if (fsi->clk_cpg)
- fsi_clk_init(dai->dev, fsi, 0, 1, 1,
- fsi_clk_set_rate_cpg);
- else
- fsi_clk_init(dai->dev, fsi, 1, 1, 0,
- fsi_clk_set_rate_external);
- }
-
/* set format */
if (fsi_is_spdif(fsi))
ret = fsi_set_fmt_spdif(fsi);
@@ -1992,6 +1995,7 @@ static int fsi_probe(struct platform_device *pdev)
fsi->master = master;
fsi_port_info_init(fsi, &info.port_a);
fsi_handler_init(fsi, &info.port_a);
+ fsi_clk_init(&pdev->dev, fsi, !!(info.port_a.flags & SH_FSI_CLK_CPG));
ret = fsi_stream_probe(fsi, &pdev->dev);
if (ret < 0) {
dev_err(&pdev->dev, "FSIA stream probe failed\n");
@@ -2005,6 +2009,7 @@ static int fsi_probe(struct platform_device *pdev)
fsi->master = master;
fsi_port_info_init(fsi, &info.port_b);
fsi_handler_init(fsi, &info.port_b);
+ fsi_clk_init(&pdev->dev, fsi, !!(info.port_b.flags & SH_FSI_CLK_CPG));
ret = fsi_stream_probe(fsi, &pdev->dev);
if (ret < 0) {
dev_err(&pdev->dev, "FSIB stream probe failed\n");
--
2.43.0
^ permalink raw reply related
* [PATCH v2 5/6] arm: dts: renesas: r8a7740: Add clocks for FSI
From: phucduc.bui @ 2026-04-13 10:06 UTC (permalink / raw)
To: kuninori.morimoto.gx, broonie
Cc: lgirdwood, robh, krzk+dt, conor+dt, geert+renesas, magnus.damm,
perex, tiwai, linux-sound, linux-renesas-soc, devicetree,
linux-kernel, bui duc phuc
In-Reply-To: <20260413100700.30995-1-phucduc.bui@gmail.com>
From: bui duc phuc <phucduc.bui@gmail.com>
Add the SPU clock to the FSI node to ensure it is enabled before register
access, preventing potential system hangs.
Also complete the FSI clock tree by adding:
- CPG DIV6 clocks (icka/b) as functional parents
- External clocks (xcka/b) from the board
Define fsib nodes to support the clock hierarchy.
Signed-off-by: bui duc phuc <phucduc.bui@gmail.com>
---
Changes in v2:
- Rename "fsi" clock to "own" to match driver implementation.
- Add missing clock names: "icka", "ickb", "xcka", "xckb".
arch/arm/boot/dts/renesas/r8a7740.dtsi | 12 +++++++++++-
1 file changed, 11 insertions(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/renesas/r8a7740.dtsi b/arch/arm/boot/dts/renesas/r8a7740.dtsi
index d13ab86c3ab4..b8d903b711be 100644
--- a/arch/arm/boot/dts/renesas/r8a7740.dtsi
+++ b/arch/arm/boot/dts/renesas/r8a7740.dtsi
@@ -393,7 +393,11 @@ sh_fsi2: sound@fe1f0000 {
compatible = "renesas,fsi2-r8a7740", "renesas,sh_fsi2";
reg = <0xfe1f0000 0x400>;
interrupts = <GIC_SPI 9 0x4>;
- clocks = <&mstp3_clks R8A7740_CLK_FSI>;
+ clocks = <&mstp3_clks R8A7740_CLK_FSI>, <&spu_clk>,
+ <&fsia_clk>, <&fsib_clk>, <&fsiack_clk>,
+ <&fsibck_clk>;
+ clock-names = "own", "spu", "icka", "ickb", "xcka",
+ "xckb";
power-domains = <&pd_a4mp>;
status = "disabled";
};
@@ -614,6 +618,12 @@ vou_clk: vou@e6150088 {
<0>;
#clock-cells = <0>;
};
+ fsib_clk: fsib@e6150090 {
+ compatible = "renesas,r8a7740-div6-clock", "renesas,cpg-div6-clock";
+ reg = <0xe6150090 4>;
+ clocks = <&pllc1_div2_clk>, <&fsibck_clk>, <0>, <0>;
+ #clock-cells = <0>;
+ };
stpro_clk: stpro@e615009c {
compatible = "renesas,r8a7740-div6-clock", "renesas,cpg-div6-clock";
reg = <0xe615009c 4>;
--
2.43.0
^ permalink raw reply related
* [PATCH v2 6/6] ASoC: dt-bindings: renesas,fsi: add support for multiple clocks
From: phucduc.bui @ 2026-04-13 10:07 UTC (permalink / raw)
To: kuninori.morimoto.gx, broonie
Cc: lgirdwood, robh, krzk+dt, conor+dt, geert+renesas, magnus.damm,
perex, tiwai, linux-sound, linux-renesas-soc, devicetree,
linux-kernel, bui duc phuc
In-Reply-To: <20260413100700.30995-1-phucduc.bui@gmail.com>
From: bui duc phuc <phucduc.bui@gmail.com>
The FSI on r8a7740 requires the SPU bus/bridge clock to be enabled before
accessing its registers. Without this clock, any register access leads to
a system hang as the FSI block sits behind the SPU bus.
Update the binding to support a flexible positional clock list to properly
describe the hardware clock tree, including:
- SPU bus/bridge clock (spu) for register access.
- CPG DIV6 clocks (icka/b) as functional clock parents.
- FSI internal dividers (diva/b) for audio clock generation.
- External clock inputs (xcka/b) provided by the board.
Signed-off-by: bui duc phuc <phucduc.bui@gmail.com>
---
Changes in v2:
- Rename FSI module clock to "own" to match driver.
- Add "spu", "icka/b", "diva/b", "xcka/b" clock names.
- Use YAML anchors to constrain clock-names properly.
- Add "if" rule to require "spu" clock for r8a7740.
- Update example with full clock configuration.
- Clean up schema by moving allOf location.
.../bindings/sound/renesas,fsi.yaml | 61 +++++++++++++++++--
1 file changed, 56 insertions(+), 5 deletions(-)
diff --git a/Documentation/devicetree/bindings/sound/renesas,fsi.yaml b/Documentation/devicetree/bindings/sound/renesas,fsi.yaml
index df91991699a7..d0ae54f3d321 100644
--- a/Documentation/devicetree/bindings/sound/renesas,fsi.yaml
+++ b/Documentation/devicetree/bindings/sound/renesas,fsi.yaml
@@ -9,9 +9,6 @@ title: Renesas FIFO-buffered Serial Interface (FSI)
maintainers:
- Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
-allOf:
- - $ref: dai-common.yaml#
-
properties:
$nodename:
pattern: "^sound@.*"
@@ -38,7 +35,36 @@ properties:
maxItems: 1
clocks:
- maxItems: 1
+ description: |
+ Clock driving the FSI Controller. The first clock must be
+ the module clock ("own").
+ minItems: 1
+ maxItems: 8
+
+ clock-names:
+ description: |
+ Names of clocks corresponding to entries in "clocks":
+ - "own": Main FSI module clock (must be first and always present)
+ - "spu": SPU bus/bridge clock. On R8A7740, this clock must be
+ enabled to allow register access as the FSI block is connected
+ behind the SPU bus.
+ - "icka" / "ickb": CPG DIV6 functional clocks for FSI port A/B
+ - "diva"/"divb": Internal FSI dividers for port A/B used for
+ audio clock generation
+ - "xcka"/"xckb": External clock inputs for FSI port A/B
+ provided by the board
+ minItems: 1
+ items:
+ - const: own
+ - &fsi_all_clks
+ enum: [spu, icka, ickb, diva, divb, xcka, xckb]
+ - &fsi_no_spu_clks
+ enum: [icka, ickb, diva, divb, xcka, xckb]
+ - *fsi_no_spu_clks
+ - *fsi_no_spu_clks
+ - *fsi_no_spu_clks
+ - *fsi_no_spu_clks
+ - *fsi_no_spu_clks
power-domains:
maxItems: 1
@@ -69,6 +95,27 @@ required:
unevaluatedProperties: false
+allOf:
+ - $ref: dai-common.yaml#
+ - if:
+ properties:
+ compatible:
+ contains:
+ const: renesas,fsi2-r8a7740
+ then:
+ properties:
+ clock-names:
+ minItems: 2
+ items:
+ - const: own
+ - const: spu
+ - *fsi_no_spu_clks
+ - *fsi_no_spu_clks
+ - *fsi_no_spu_clks
+ - *fsi_no_spu_clks
+ - *fsi_no_spu_clks
+ - *fsi_no_spu_clks
+
examples:
- |
#include <dt-bindings/clock/r8a7740-clock.h>
@@ -77,7 +124,11 @@ examples:
compatible = "renesas,fsi2-r8a7740", "renesas,sh_fsi2";
reg = <0xfe1f0000 0x400>;
interrupts = <GIC_SPI 9 0x4>;
- clocks = <&mstp3_clks R8A7740_CLK_FSI>;
+ clocks = <&mstp3_clks R8A7740_CLK_FSI>, <&spu_clk>,
+ <&fsia_clk>, <&fsib_clk>, <&fsidiva_clk>,
+ <&fsidivb_clk>,<&fsiack_clk>,<&fsibck_clk>;
+ clock-names = "own", "spu", "icka", "ickb",
+ "diva", "divb", "xcka", "xckb";
power-domains = <&pd_a4mp>;
#sound-dai-cells = <1>;
--
2.43.0
^ permalink raw reply related
* Re: [PATCH v2 0/4] Add QST QMC5883P magnetometer driver
From: Andy Shevchenko @ 2026-04-13 10:21 UTC (permalink / raw)
To: Hardik Phalet
Cc: Greg Kroah-Hartman, Jonathan Cameron, David Lechner, Nuno Sá,
Andy Shevchenko, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Brigham Campbell, Shuah Khan, linux-iio, devicetree, linux-kernel,
linux-staging
In-Reply-To: <DHR3SE5ACRQ9.2T8T819298YGI@pm.me>
On Sun, Apr 12, 2026 at 10:27:36AM +0000, Hardik Phalet wrote:
> On Fri Apr 10, 2026 at 10:06 AM IST, Andy Shevchenko wrote:
> > On Thu, Apr 09, 2026 at 09:07:11PM +0000, Hardik Phalet wrote:
...
> > - the investigation is rather poor about existence of the driver — make sure
> > there is no compatible (by register layout) driver in IIO or even outside it
> > (for ADCs it might appear as HWMON [drivers/hwmon] or INPUT [drivers/input]
> > in some cases)
> I will dig a bit deeper into this. But I could not find any thing
> realted to the device I am working on (qmc5883p).
It might be that there is a driver with smaller amount of registers available
(or bigger) or some features missing...
> There is a device hmc5843_core.c that already handles HMC5883L. But the
> register layout is different, field ranges, gain encoding etc. are
> different and I think warrants a separate driver. Other than that I
> could not find something related to device I am working on.
This paragraph is a particular case, something like this should be put in the
summary in your case if the brand new driver is needed.
> I will carefully go through HWMON and INPUT too, but do you have a
> strategy to help me find somehting similar? It will be very useful.
> Would `grep`-ing for 5883 and QST be a right starting point?
Grep for words that are case insensitive values of the registers offsets.
This can be done recursively, then you need to apply some heuristics on
the definition names to see if they are about the same thing (or similar)
or not at all.
--
With Best Regards,
Andy Shevchenko
^ permalink raw reply
* Re: [PATCH 2/2] dt-bindings: usb: qcom,dwc3: Correct MSM8994 interrupts
From: Konrad Dybcio @ 2026-04-13 10:26 UTC (permalink / raw)
To: Krzysztof Kozlowski, Greg Kroah-Hartman, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Wesley Cheng, Krishna Kurapati,
Bjorn Andersson, linux-arm-msm, linux-usb, devicetree,
linux-kernel, Dmitry Baryshkov
In-Reply-To: <20260106185012.19551-4-krzysztof.kozlowski@oss.qualcomm.com>
On 1/6/26 7:50 PM, Krzysztof Kozlowski wrote:
> According to the reference manual, MSM8994 does have QUSB2 PHY and does
> not have DP/DM IRQs interrupts. It is also logical it has the same
> constraints as similar device: MSM8996.
It may be that the following mapping is true:
USB0 (DWC3)
DP -> MPM 49
DM -> MPM 58
hsphy -> GIC 133
otg (dwc3_irq?) -> 179
power_event -> 180
ee1 -> GIC 131
ee2 -> GIC 246 (for IPA?)
hs_phy_qgic_irq (qusb2?) -> GIC 311
phy_id -> MPM 48
USB1 (CHIPIDEA)
DP -> MPM 55
DM -> MPM 54
hsphy -> GIC 134
async wakeup -> GIC 140
qusb2_phy -> GIC 312
Do with that what you will.. I can add looking into this more properly
to my ever-growing TODO list (or maybe +Dmitry has a 8994 SBC?)
Konrad
^ permalink raw reply
* Re: [PATCH 03/12] arm64: dts: qcom: qcs6490-radxa-dragon-q6a: Enable USB 3.0 and HDMI ports
From: Konrad Dybcio @ 2026-04-13 10:28 UTC (permalink / raw)
To: Xilin Wu, Bjorn Andersson, Konrad Dybcio, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Dmitry Baryshkov,
Liam Girdwood, Mark Brown, Judy Hsiao
Cc: linux-arm-msm, linux-kernel, devicetree, linux-sound
In-Reply-To: <63630053AE2A689C+fc86c1c4-8daa-4af8-bf64-b432fc8dc1c0@radxa.com>
On 4/12/26 5:14 AM, Xilin Wu wrote:
> On 4/8/2026 5:03 PM, Konrad Dybcio wrote:
>> On 4/7/26 5:19 PM, Xilin Wu wrote:
>>> This board doesn't feature a regular Type-C port. The usb_1_qmpphy's
>>
>> I guess the receptacle on board is power-only?
>
> Yes. The Type-C port is power only.
[...]
>>> +&mdss_dp {
>>> + sound-name-prefix = "Display Port0";
>>
>> Hmmmmm.. other platforms call it "DisplayPort0" (without a space)..
>> But I suppose this name needs to match UCM..
>>
>> We'd also normally push this property to the SoC DTSI
>
> Actually I don't think the name is used in UCM. I can rename it and push the property to SoC DTSI if necessary.
Let's do that
Konrad
^ permalink raw reply
* Re: [PATCH 3/4] arm64: dts: qcom: sdm845: Add missing MDSS reset
From: Konrad Dybcio @ 2026-04-13 10:28 UTC (permalink / raw)
To: Dmitry Baryshkov
Cc: David Heidelberg, Bjorn Andersson, Michael Turquette,
Stephen Boyd, Ulf Hansson, Konrad Dybcio, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, linux-arm-msm, linux-clk,
linux-kernel, devicetree
In-Reply-To: <cm7cowdic42qziuwpe22b2yuakg2k5lqcdnfs3mspvbvprnbto@6kxucxrbnsc6>
On 4/12/26 2:41 AM, Dmitry Baryshkov wrote:
> On Fri, Apr 10, 2026 at 10:55:53AM +0200, Konrad Dybcio wrote:
>> On 4/9/26 11:24 PM, Dmitry Baryshkov wrote:
>>> On Thu, Apr 09, 2026 at 10:38:15PM +0200, David Heidelberg wrote:
>>>> On 18/02/2026 16:59, Dmitry Baryshkov wrote:
>>>>> On Wed, Feb 18, 2026 at 03:28:01PM +0100, Konrad Dybcio wrote:
>>>>>>
>>>>>>
>>>>>> On 18-Feb-26 12:58, Dmitry Baryshkov wrote:
>>>>>>> On Wed, Feb 18, 2026 at 12:24:26PM +0100, Konrad Dybcio wrote:
>>>>>>>> On 2/18/26 12:18 PM, David Heidelberg wrote:
>>>>>>>>> On 18/02/2026 11:30, Konrad Dybcio wrote:
>>>>>>>>>> On 2/17/26 10:20 PM, Dmitry Baryshkov wrote:
>>>>>>>>>>> From: David Heidelberg <david@ixit.cz>
>>>>>>>>>>>
>>>>>>>>>>> If the OS does not support recovering the state left by the
>>>>>>>>>>> bootloader it needs a way to reset display hardware, so that it can
>>>>>>>>>>> start from a clean state. Add a reference to the relevant reset.
>>>>>>>>>>
>>>>>>>>>> This is not the relevant reset
>>>>>>>>>>
>>>>>>>>>> You want MDSS_CORE_BCR @ 0xaf0_2000
>>>>>>>>>
>>>>>>>>> Thanks, I prepared the fixes [1].
>>>>>>>>>
>>>>>>>>> I'll try to test it if it's not breaking anything for us and send as v2 of [2].
>>>>>>>>>
>>>>>>>>> David
>>>>>>>>>
>>>>>>>>> [1] https://codeberg.org/sdm845/linux/commits/branch/b4/mdss-reset
>>>>>>>>> [2] https://patchwork.kernel.org/project/linux-arm-msm/patch/20260112-mdss-reset-v1-1-af7c572204d3@ixit.cz/
>>>>>>>>
>>>>>>>> Please don't alter the contents of dt-bindings, it really doesn't matter
>>>>>>>> if on sdm845 it's reset0 or reset1, that's why we define them in the first
>>>>>>>> place
>>>>>>>
>>>>>>> I dpn't think that will pass. Current reset is defined as RSCC, we can't
>>>>>>> change that to CORE behind the scene. I'd prefer David's approach.
>>>>>>
>>>>>> Back when I replied, David had a patch that removed the current RSCC
>>>>>> reset definition in dt-bindings (at index 0) and re-used that index
>>>>>> for CORE, putting RSCC at index 1. Perhaps it's better to link to
>>>>>> specific commits when making comments, note to self :P
>>>>>
>>>>> Yes, I saw the commit having two resets. Anyway, as we saw, it doesn't
>>>>> work.
>>>>
>>>> So, finally I spent "so much effort" (read throwing it at LLM) looking at:
>>>>
>>>> arm-smmu 15000000.iommu: Unhandled context fault: fsr=0x402,
>>>> iova=0x9d4bb500, fsynr=0x170021, cbfrsynra=0xc88, cb=11
>>>> arm-smmu 15000000.iommu: FSR = 00000402 [Format=2 TF], SID=0xc88
>>>> arm-smmu 15000000.iommu: FSYNR0 = 00170021 [S1CBNDX=23 PNU PLVL=1]
>>>
>>> [...]
>>>
>>>>
>>>> These (or very similar warnings) are around sdm845 definitely 6.19+ /
>>>> linux-next kernels for some time, but pretty harmless.
>>>>
>>>> LLM suggested multiple fixes, but when presenting possibility of
>>>> implementing mdss reset it found it as most preferable [1].
>>>>
>>>> Adding MDSS reset would most likely solve it. It's not critical, but not
>>>> nice to see many red lines in the dmesg.
>>>>
>>>> Is there something I could experiment with to get closer to have proper MDSS reset?
>>>
>>> I don't have a sensible solution at this point. We tried using the MDSS
>>> reset on several SDM845 devices, but they just reset. So... I don't have
>>> any possible solution.
>>
>> The older context talks about altering the existing dt-bindings values
>> and now we're at hardware (mis)behaving? What is the issue here?
>
> The HDK and DB845c reset if I try touching MDSS core reset.
And David, does that also happen on your other boards?
Konrad
^ permalink raw reply
* Re: Phandles
From: Herve Codina @ 2026-04-13 10:30 UTC (permalink / raw)
To: Krzysztof Kozlowski
Cc: Kyle Bonnici, devicetree-compiler@vger.kernel.org, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, devicetree
In-Reply-To: <72dc4a71-1a3d-4e36-9bcc-d9a4de3de6cc@kernel.org>
Hi Krzysztof
On Mon, 13 Apr 2026 08:33:49 +0200
Krzysztof Kozlowski <krzk@kernel.org> wrote:
> On 12/04/2026 17:40, Herve Codina wrote:
> > Hi Kyle,
> >
> > +Cc Kernel device-tree maintainers
> >
> > On Sun, 12 Apr 2026 13:51:35 +0000
> > Kyle Bonnici <kylebonnici@hotmail.com> wrote:
> >
> >>> On 12 Apr 2026, at 14:51, Herve Codina <herve.codina@bootlin.com> wrote:
> >>>
> >>> Hi Kyle,
> >>>
> >>> On Sat, 11 Apr 2026 18:33:33 +0000
> >>> Kyle Bonnici <kylebonnici@hotmail.com> wrote:
> >>>
> >>>> Hi
> >>>>
> >>>> I have been looking at the the code for the compiler and I am wondering which specifications marks the below properties MUST BE Nexus Properties hence the validation.
> >>>>
> >>>> WARNING_PROPERTY_PHANDLE_CELLS(clocks, "clocks", "#clock-cells");
> >>>> WARNING_PROPERTY_PHANDLE_CELLS(cooling_device, "cooling-device", "#cooling-cells");
> >>>> WARNING_PROPERTY_PHANDLE_CELLS(dmas, "dmas", "#dma-cells");
> >>>> WARNING_PROPERTY_PHANDLE_CELLS(hwlocks, "hwlocks", "#hwlock-cells");
> >>>> WARNING_PROPERTY_PHANDLE_CELLS(interrupts_extended, "interrupts-extended", "#interrupt-cells");
> >>>> WARNING_PROPERTY_PHANDLE_CELLS(io_channels, "io-channels", "#io-channel-cells");
> >>>> WARNING_PROPERTY_PHANDLE_CELLS(iommus, "iommus", "#iommu-cells");
> >>>> WARNING_PROPERTY_PHANDLE_CELLS(mboxes, "mboxes", "#mbox-cells");
> >>>> WARNING_PROPERTY_PHANDLE_CELLS(msi_parent, "msi-parent", "#msi-cells", true);
> >>>> WARNING_PROPERTY_PHANDLE_CELLS(mux_controls, "mux-controls", "#mux-control-cells");
> >>>> WARNING_PROPERTY_PHANDLE_CELLS(phys, "phys", "#phy-cells");
> >>>> WARNING_PROPERTY_PHANDLE_CELLS(power_domains, "power-domains", "#power-domain-cells");
> >>>> WARNING_PROPERTY_PHANDLE_CELLS(pwms, "pwms", "#pwm-cells");
> >>>> WARNING_PROPERTY_PHANDLE_CELLS(resets, "resets", "#reset-cells");
> >>>> WARNING_PROPERTY_PHANDLE_CELLS(sound_dai, "sound-dai", "#sound-dai-cells");
> >>>> WARNING_PROPERTY_PHANDLE_CELLS(thermal_sensors, "thermal-sensors", "#thermal-sensor-cells");
> >>>
> >>> All of those properties are defined as phandles.
> >>>
> >>> For instance, the 'pwms' property available in a node means the the node is
> >>> a pwm consumer. It must follow the pwm consumer binding [1] and so a phandle
> >>> is involved.
> >>>
> >>> This phandle can have arguments and the number of argument is defined by the
> >>> #pwm-cells property set in the pwm provider node [2], [3].
> >>>
> >>> [1] https://elixir.bootlin.com/zephyr/v4.4.0-rc3/source/dts/bindings/pwm/pwm-controller.yaml
> >>> [2] https://github.com/zephyrproject-rtos/zephyr/blob/main/dts/bindings/pwm/pwm-controller.yaml
> >>> [3] https://elixir.bootlin.com/linux/v7.0-rc7/source/Documentation/devicetree/bindings/pwm/pwm.yaml
> >>>
> >>>>
> >>>>
> >>>> These can be found here: https://github.com/dgibson/dtc/blob/main/checks.c#L1498 this is relevant for https://github.com/zephyrproject-rtos/zephyr/issues/107066
> >>>
> >>> Examples provided in the zephyrproject issue link are, in my opinion, incorrect.
> >>>
> >>> Case 1:
> >>> / {
> >>> node1 {
> >>> pwms = <1 &pwm0 1 20 PWM_POLARITY_NORMAL>;
> >>>
> >>> Here the first cell '1' is not a phandle.
> >>
> >> Here the compiler is making an assumption here that all `pwms` properties must be specifier properties and all use `pwm` specifier.
> >
> > I think the purpose of 'select: true' is to have the binding always applied:
> > https://github.com/devicetree-org/dt-schema/blob/main/dtschema/schemas/pwm/pwm-consumer.yaml#L15
> >
> > If this is confirmed, DTC performs correct checks as this binding must always
> > be applied and so the 'pwms' property must be a phandle-array property.
> >
> > Device-tree maintainers, can you confirm the purpose of 'select: true' set
> > in a DT binding ?
>
> The quoted parts were mentioning Zephyr. Here you mentioned DTC, but ask
> about "select: true", so dtschema. I don't get the context... dtschema
> has nothing to do with DTC and Zephyr.
I wanted be sure about checks done by DTC itself.
My feeling was that if a binding defined in dtschema has to be always applied
(i.e. select: true) it is a legit case to have DTC performing some checks
according to this binding.
Kyle seems to define the 'pwms' property to be something other than a phandle.
IMHO, this is wrong but the 'pwms' property is only defined in dtschema.
Best regards,
Hervé
^ permalink raw reply
* Re: [PATCH 3/8] firmware: meson: sm: Add thermal calibration SMC call
From: Ronald Claveau @ 2026-04-13 10:31 UTC (permalink / raw)
To: Krzysztof Kozlowski
Cc: linux-pm, linux-amlogic, devicetree, linux-kernel,
linux-arm-kernel, Guillaume La Roque, Rafael J. Wysocki,
Daniel Lezcano, Zhang Rui, Lukasz Luba, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Neil Armstrong, Kevin Hilman,
Jerome Brunet, Martin Blumenstingl
In-Reply-To: <6200b372-149f-48f7-ae91-a5364562058c@kernel.org>
On 4/12/26 12:47 PM, Krzysztof Kozlowski wrote:
> On 10/04/2026 18:48, Ronald Claveau wrote:
>> @@ -245,6 +246,14 @@ struct meson_sm_firmware *meson_sm_get(struct device_node *sm_node)
>> }
>> EXPORT_SYMBOL_GPL(meson_sm_get);
>>
>> +int meson_sm_get_thermal_calib(struct meson_sm_firmware *fw, u32 *trim_info,
>
> Exported functions should have kerneldoc.
>
Thanks for your feedback, I will add it.
>> + u32 tsensor_id)
>> +{
>> + return meson_sm_call(fw, SM_THERMAL_CALIB_READ, trim_info, tsensor_id,
>> + 0, 0, 0, 0);
>
> Best regards,
> Krzysztof
--
Best regards,
Ronald
^ permalink raw reply
* Re: [PATCH 1/8] dt-bindings: thermal: amlogic: Add support for T7
From: Ronald Claveau @ 2026-04-13 10:39 UTC (permalink / raw)
To: Krzysztof Kozlowski
Cc: Guillaume La Roque, Rafael J. Wysocki, Daniel Lezcano, Zhang Rui,
Lukasz Luba, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Neil Armstrong, Kevin Hilman, Jerome Brunet, Martin Blumenstingl,
linux-pm, linux-amlogic, devicetree, linux-kernel,
linux-arm-kernel
In-Reply-To: <20260412-abiding-silver-turkey-1623cc@quoll>
Hello Krzysztof, thank you for this feedback.
On 4/12/26 11:58 AM, Krzysztof Kozlowski wrote:
> On Fri, Apr 10, 2026 at 06:48:02PM +0200, Ronald Claveau wrote:
>> Add the amlogic,t7-thermal compatible for the Amlogic T7 thermal sensor.
>>
>> Unlike existing variants which use a phandle to the ao-secure syscon,
>> the T7 relies on a secure monitor interface described by a phandle and
>> a sensor index argument.
>>
>> Introduce the amlogic,secure-monitor property as a phandle-array and
>> make amlogic,ao-secure or amlogic,secure-monitor conditionally required
>> depending on the compatible.
>>
>> Signed-off-by: Ronald Claveau <linux-kernel-dev@aliel.fr>
>> ---
>> .../bindings/thermal/amlogic,thermal.yaml | 40 +++++++++++++++++++++-
>> 1 file changed, 39 insertions(+), 1 deletion(-)
>>
>> diff --git a/Documentation/devicetree/bindings/thermal/amlogic,thermal.yaml b/Documentation/devicetree/bindings/thermal/amlogic,thermal.yaml
>> index 70b273271754b..85ee73c6e1161 100644
>> --- a/Documentation/devicetree/bindings/thermal/amlogic,thermal.yaml
>> +++ b/Documentation/devicetree/bindings/thermal/amlogic,thermal.yaml
>> @@ -22,6 +22,7 @@ properties:
>> - amlogic,g12a-ddr-thermal
>> - const: amlogic,g12a-thermal
>> - const: amlogic,a1-cpu-thermal
>> + - const: amlogic,t7-thermal
>
> So these two entries are enum.
>
I will change to enum.
>>
>> reg:
>> maxItems: 1
>> @@ -42,12 +43,40 @@ properties:
>> '#thermal-sensor-cells':
>> const: 0
>>
>> + amlogic,secure-monitor:
>> + description: phandle to the secure monitor
>> + $ref: /schemas/types.yaml#/definitions/phandle-array
>> + items:
>> + - items:
>> + - description: phandle to the secure monitor
>> + - description: sensor index
>
> For what exactly this sensor index is needed? commit msg explained me
> nothing, instead repeated what you did. That's pointless, explain why
> you did it.
>
Thanks I will add the explanation in the commit message and in the
description here.
>> +
>> required:
>> - compatible
>> - reg
>> - interrupts
>> - clocks
>> - - amlogic,ao-secure
>> +
>> +allOf:
>> + - if:
>> + properties:
>> + compatible:
>> + contains:
>> + enum:
>> + - amlogic,g12a-cpu-thermal
>> + - amlogic,g12a-ddr-thermal
>
> Drop both, you need only fallback.
>
I hesitated between the two methods. I will change to fallback only.
>> + - amlogic,a1-cpu-thermal
>
> And list is sorted alphabetically.
>
Thanks for the reminder.
>> + then:
>> + required:
>> + - amlogic,ao-secure
>
> Best regards,
> Krzysztof
>
>
> _______________________________________________
> linux-amlogic mailing list
> linux-amlogic@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-amlogic
--
Best regards,
Ronald
^ permalink raw reply
* Re: [PATCH v2 13/13] arm64: defconfig: Enable I3C and SPD5118 hwmon
From: Akhil R @ 2026-04-13 10:46 UTC (permalink / raw)
To: krzk
Cc: Frank.Li, acpica-devel, akhilrajeev, alexandre.belloni, conor+dt,
devicetree, ebiggers, krzk+dt, lenb, linux-acpi, linux-hwmon,
linux-i3c, linux-kernel, linux, miquel.raynal, p.zabel, rafael,
robh, sakari.ailus, smangipudi, wsa+renesas, treding, jonathanh
In-Reply-To: <3d199d1c-066f-4947-8956-c135fb9ba24e@kernel.org>
On Mon, 13 Apr 2026 09:12:18 +0200, Krzysztof Kozlowski wrote:
> On 13/04/2026 08:57, Akhil R wrote:
>>>> Isn't I3C needed for SPD5118. Otherwise I understand even less from this
>>>> rationale - why I3C is being enabled here?
>>>>
>>>> And before author asks what do I want to here: no, it is author's job to
>>>> convince me to accept I3C in defconfig. Not mine.
>>>
>>> BTW, all this was asked at v1 and author did not improve the commit msg
>>> beside giving quite broad/unspecific "Vera".
>>
>> If I am not wrong, the ask in v1 was to specify the product which this is
>> getting used - 'Vera' it is. I do not know why you would think it is
>> unspecific.
>
> I already said why. Because I Googled it and Google told me it can be
> "architecture". And no, you do not use SPD5118 on architecture.
Vera is the CPU and it uses SOCAMM LPDDR5, which has an SPD5118 within.
I will write this down in the next version.
>
>>
>> As Thierry and Guenter mentioned, the lack of policy and 'mix of both' in
>> the defconfig makes it quite difficult to understand what could genuinely
>> be convincing other than putting down every little detail or do a trial
>> and error.
>
> I think the main problem is that people forgot that commits must answer
> WHY you are doing this. Now my assumption is that people sending
> defconfigs do not understand why they are doing it, therefore they
> cannot explain "why" in commit msg.
>
> Look, find me in following nvidia patches any answers to why this change
> is needed:
>
> https://lore.kernel.org/all/20260409131340.168556-7-pshete@nvidia.com/
> https://lore.kernel.org/all/20240829134252.49661-1-jonathanh@nvidia.com/
> https://lore.kernel.org/all/20240509215808.126217-1-bwicaksono@nvidia.com/
>
> I understand that I can clarify what sort of answers to "why?" I expect.
> but lack of such clarification is not excuse to not provide ANY
> explanation in commit msg.
>
> Basically it is logic like:
> "Uh, I don't how to explain this change, why do we need it, why is it
> good, why am I doing that...anyway, let's send it!"
>
> Why doing something in the first place if one does not know the reason
> behind?
The answer I wrote to "why" is that "it is required to support the
SOCAMM in Vera". But I may have overlooked the ambiguity of the
details of Vera available online. I will make it more descriptive.
Regards,
Akhil
^ permalink raw reply
* Re: [PATCH v2 0/2] cpufreq: spacemit: Add cpufreq support for K1 SoC
From: Viresh Kumar @ 2026-04-13 10:49 UTC (permalink / raw)
To: Shuwei Wu
Cc: Rafael J. Wysocki, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Paul Walmsley, Palmer Dabbelt, Albert Ou, Alexandre Ghiti,
Yixun Lan, linux-pm, linux-kernel, linux-riscv, spacemit,
devicetree
In-Reply-To: <20260410-shadow-deps-v2-0-4e16b8c0f60e@mailbox.org>
On 10-04-26, 15:58, Shuwei Wu wrote:
> This series enables dynamic voltage and frequency scaling (DVFS) for
> the SpacemiT K1 SoC using the generic cpufreq-dt driver.
>
> Tested on Banana Pi BPI-F3, the execution time scales as expected
> across different CPU frequencies:
>
> ~ # echo userspace > /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor
>
> ~ # echo 1600000 > /sys/devices/system/cpu/cpu0/cpufreq/scaling_setspeed
> ~ # time awk 'BEGIN{for(i=0;i<1000000;i++){}}'
> real 0m 1.07s
> user 0m 1.07s
> sys 0m 0.00s
>
> ~ # echo 1228800 > /sys/devices/system/cpu/cpu0/cpufreq/scaling_setspeed
> ~ # time awk 'BEGIN{for(i=0;i<1000000;i++){}}'
> real 0m 1.40s
> user 0m 1.40s
> sys 0m 0.00s
>
> ~ # echo 1000000 > /sys/devices/system/cpu/cpu0/cpufreq/scaling_setspeed
> ~ # time awk 'BEGIN{for(i=0;i<1000000;i++){}}'
> real 0m 1.72s
> user 0m 1.72s
> sys 0m 0.00s
>
> ~ # echo 819000 > /sys/devices/system/cpu/cpu0/cpufreq/scaling_setspeed
> ~ # time awk 'BEGIN{for(i=0;i<1000000;i++){}}'
> real 0m 2.10s
> user 0m 2.10s
> sys 0m 0.00s
>
> ~ # echo 614400 > /sys/devices/system/cpu/cpu0/cpufreq/scaling_setspeed
> ~ # time awk 'BEGIN{for(i=0;i<1000000;i++){}}'
> real 0m 2.80s
> user 0m 2.80s
> sys 0m 0.00s
>
> Signed-off-by: Shuwei Wu <shuwei.wu@mailbox.org>
> ---
> Changes in v2:
> - Move OPP tables to dedicated k1-opp.dtsi
> - Enable OPP only on BPI-F3 with cpu-supply present
> - Link to v1: https://lore.kernel.org/r/20260308-shadow-deps-v1-0-0ceb5c7c07eb@mailbox.org
>
> ---
> Shuwei Wu (2):
> cpufreq: dt-platdev: Add SpacemiT K1 SoC to the allowlist
> riscv: dts: spacemit: Add cpu scaling for K1 SoC
>
> arch/riscv/boot/dts/spacemit/k1-bananapi-f3.dts | 35 +++++++-
> arch/riscv/boot/dts/spacemit/k1-opp.dtsi | 105 ++++++++++++++++++++++++
> arch/riscv/boot/dts/spacemit/k1.dtsi | 8 ++
> drivers/cpufreq/cpufreq-dt-platdev.c | 1 +
> 4 files changed, 148 insertions(+), 1 deletion(-)
Feel free to take it via the arch code.
Acked-by: Viresh Kumar <viresh.kumar@linaro.org>
--
viresh
^ permalink raw reply
* Re: [PATCH 3/4] arm64: dts: qcom: sdm845: Add missing MDSS reset
From: David Heidelberg @ 2026-04-13 10:50 UTC (permalink / raw)
To: Konrad Dybcio, Dmitry Baryshkov
Cc: Bjorn Andersson, Michael Turquette, Stephen Boyd, Ulf Hansson,
Konrad Dybcio, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
linux-arm-msm, linux-clk, linux-kernel, devicetree
In-Reply-To: <e321f7dc-4053-4a4d-a0e3-40c3a8fc0fd8@oss.qualcomm.com>
On 13/04/2026 12:28, Konrad Dybcio wrote:
> On 4/12/26 2:41 AM, Dmitry Baryshkov wrote:
>> On Fri, Apr 10, 2026 at 10:55:53AM +0200, Konrad Dybcio wrote:
>>> On 4/9/26 11:24 PM, Dmitry Baryshkov wrote:
>>>> On Thu, Apr 09, 2026 at 10:38:15PM +0200, David Heidelberg wrote:
>>>>> On 18/02/2026 16:59, Dmitry Baryshkov wrote:
>>>>>> On Wed, Feb 18, 2026 at 03:28:01PM +0100, Konrad Dybcio wrote:
>>>>>>>
>>>>>>>
>>>>>>> On 18-Feb-26 12:58, Dmitry Baryshkov wrote:
>>>>>>>> On Wed, Feb 18, 2026 at 12:24:26PM +0100, Konrad Dybcio wrote:
>>>>>>>>> On 2/18/26 12:18 PM, David Heidelberg wrote:
>>>>>>>>>> On 18/02/2026 11:30, Konrad Dybcio wrote:
>>>>>>>>>>> On 2/17/26 10:20 PM, Dmitry Baryshkov wrote:
>>>>>>>>>>>> From: David Heidelberg <david@ixit.cz>
>>>>>>>>>>>>
>>>>>>>>>>>> If the OS does not support recovering the state left by the
>>>>>>>>>>>> bootloader it needs a way to reset display hardware, so that it can
>>>>>>>>>>>> start from a clean state. Add a reference to the relevant reset.
>>>>>>>>>>>
>>>>>>>>>>> This is not the relevant reset
>>>>>>>>>>>
>>>>>>>>>>> You want MDSS_CORE_BCR @ 0xaf0_2000
>>>>>>>>>>
>>>>>>>>>> Thanks, I prepared the fixes [1].
>>>>>>>>>>
>>>>>>>>>> I'll try to test it if it's not breaking anything for us and send as v2 of [2].
>>>>>>>>>>
>>>>>>>>>> David
>>>>>>>>>>
>>>>>>>>>> [1] https://codeberg.org/sdm845/linux/commits/branch/b4/mdss-reset
>>>>>>>>>> [2] https://patchwork.kernel.org/project/linux-arm-msm/patch/20260112-mdss-reset-v1-1-af7c572204d3@ixit.cz/
>>>>>>>>>
>>>>>>>>> Please don't alter the contents of dt-bindings, it really doesn't matter
>>>>>>>>> if on sdm845 it's reset0 or reset1, that's why we define them in the first
>>>>>>>>> place
>>>>>>>>
>>>>>>>> I dpn't think that will pass. Current reset is defined as RSCC, we can't
>>>>>>>> change that to CORE behind the scene. I'd prefer David's approach.
>>>>>>>
>>>>>>> Back when I replied, David had a patch that removed the current RSCC
>>>>>>> reset definition in dt-bindings (at index 0) and re-used that index
>>>>>>> for CORE, putting RSCC at index 1. Perhaps it's better to link to
>>>>>>> specific commits when making comments, note to self :P
>>>>>>
>>>>>> Yes, I saw the commit having two resets. Anyway, as we saw, it doesn't
>>>>>> work.
>>>>>
>>>>> So, finally I spent "so much effort" (read throwing it at LLM) looking at:
>>>>>
>>>>> arm-smmu 15000000.iommu: Unhandled context fault: fsr=0x402,
>>>>> iova=0x9d4bb500, fsynr=0x170021, cbfrsynra=0xc88, cb=11
>>>>> arm-smmu 15000000.iommu: FSR = 00000402 [Format=2 TF], SID=0xc88
>>>>> arm-smmu 15000000.iommu: FSYNR0 = 00170021 [S1CBNDX=23 PNU PLVL=1]
>>>>
>>>> [...]
>>>>
>>>>>
>>>>> These (or very similar warnings) are around sdm845 definitely 6.19+ /
>>>>> linux-next kernels for some time, but pretty harmless.
>>>>>
>>>>> LLM suggested multiple fixes, but when presenting possibility of
>>>>> implementing mdss reset it found it as most preferable [1].
>>>>>
>>>>> Adding MDSS reset would most likely solve it. It's not critical, but not
>>>>> nice to see many red lines in the dmesg.
>>>>>
>>>>> Is there something I could experiment with to get closer to have proper MDSS reset?
>>>>
>>>> I don't have a sensible solution at this point. We tried using the MDSS
>>>> reset on several SDM845 devices, but they just reset. So... I don't have
>>>> any possible solution.
>>>
>>> The older context talks about altering the existing dt-bindings values
>>> and now we're at hardware (mis)behaving? What is the issue here?
>>
>> The HDK and DB845c reset if I try touching MDSS core reset.
>
> And David, does that also happen on your other boards?
yes, I recall OnePlus 6 or 6T going to crashdump and Pixel 3 crashing too.
David
>
> Konrad
--
David Heidelberg
^ permalink raw reply
* [PATCH v2 0/8] arm64: amlogic: T7 thermal support
From: Ronald Claveau @ 2026-04-13 10:52 UTC (permalink / raw)
To: Guillaume La Roque, Rafael J. Wysocki, Daniel Lezcano, Zhang Rui,
Lukasz Luba, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Neil Armstrong, Kevin Hilman, Jerome Brunet, Martin Blumenstingl
Cc: linux-pm, linux-amlogic, devicetree, linux-kernel,
linux-arm-kernel, Ronald Claveau
This series adds thermal monitoring support for the Amlogic T7 SoC,
used on the Khadas VIM4 board.
The T7 exposes six thermal sensors (a53, a73, gpu, nna, vpu, hevc),
each accessible through the secure monitor firmware interface rather
than a directly mapped eFuse register as on older SoCs.
The series is organized as follows:
- Patch 1 extends the amlogic,t7-thermal DT binding to describe the
new amlogic,secure-monitor property.
- Patches 2-3 extend the Meson secure monitor driver to expose a
thermal calibration read command (SMC ID 0x82000047).
- Patch 4 adds the secure monitor readout path to the amlogic thermal
driver and introduces the amlogic,t7-thermal compatible.
- Patches 5-7 wire up the T7 DTSI with CPU cooling cells, sensor
nodes, and thermal zones.
- Patch 8 extends the Khadas VIM4 DTS to map all thermal zones to the
on-board MCU fan controller (states 30–100, corresponding to the
FAN_CTRL register range 0x1E–0x64).
Signed-off-by: Ronald Claveau <linux-kernel-dev@aliel.fr>
---
Changes in v2:
- PATCH 1: change two const entries to enum, explain why sensor index is needed
reorder conditional compatible for required, and fallback only according to
Krzysztof's feedback.
- PATCH 3: Add kerneldoc for meson_sm_get_thermal_calib exported function
according to Krzysztof's feedback.
- Link to v1: https://lore.kernel.org/r/20260410-add-thermal-t7-vim4-v1-0-19f2b8da74d7@aliel.fr
---
Ronald Claveau (8):
dt-bindings: thermal: amlogic: Add support for T7
firmware: meson: sm: Thermal calibration read via secure monitor
firmware: meson: sm: Add thermal calibration SMC call
thermal: amlogic: Add support for secure monitor calibration readout
arm64: dts: amlogic: t7: Add cooling cells to all CPUs
arm64: dts: amlogic: t7: Add thermal sensor nodes
arm64: dts: amlogic: t7: Add thermal zones
arm64: dts: amlogic: t7: khadas-vim4: Add fan cooling to thermal zones
.../bindings/thermal/amlogic,thermal.yaml | 42 +++-
.../dts/amlogic/amlogic-t7-a311d2-khadas-vim4.dts | 102 +++++++++
arch/arm64/boot/dts/amlogic/amlogic-t7.dtsi | 245 +++++++++++++++++++++
drivers/firmware/meson/meson_sm.c | 29 ++-
drivers/thermal/amlogic_thermal.c | 58 ++++-
include/linux/firmware/meson/meson_sm.h | 3 +
6 files changed, 467 insertions(+), 12 deletions(-)
---
base-commit: f7b64ed948718290209074a50bb0df17e5944873
change-id: 20260410-add-thermal-t7-vim4-00e571badcc1
prerequisite-message-id: <20260326092645.1053261-1-jian.hu@amlogic.com>
prerequisite-patch-id: f03a086b4137158412b2d47b3de793b858de8dde
prerequisite-patch-id: 123970c9b29c2090440f2fd71c85d3c6fd8e36de
prerequisite-patch-id: 3e2e56b0926ba327b520f935df4ced5089bbe503
prerequisite-patch-id: 65a5d76ffdbc9b3aab3385bb65cb027004c30e7e
prerequisite-patch-id: 237269801826dd3ad7fb16eb4d7d6d4eab504278
prerequisite-patch-id: 57e9b08a968aedf543d3d0d56cf1ca4db20b2a16
prerequisite-change-id: 20260326-add-bcm43752-compatible-e264a4f7973a:v2
prerequisite-patch-id: cd98b74fa56af72af2553f391c400981d83cd4f4
prerequisite-patch-id: b730f5e42be1d89d193e63a0265495cdbf2c7d7b
prerequisite-change-id: 20260330-fix-invalid-property-bbe54d933f71:v2
prerequisite-patch-id: 8d675e7a239985c762843515b241f0a2f45f9c92
prerequisite-change-id: 20260331-fix-aml-t7-null-reset-2b608ebf9da4:v1
prerequisite-patch-id: 5b5de77af11747ce964404fb827d2ee2bff47ea5
prerequisite-patch-id: 1e37fc75fed1e533adee0f3e7e6ead1f8ff3c55c
prerequisite-patch-id: 65a5d76ffdbc9b3aab3385bb65cb027004c30e7e
prerequisite-patch-id: 2daf583fb5e7449a02bd217d8aca330171b598aa
prerequisite-patch-id: 237269801826dd3ad7fb16eb4d7d6d4eab504278
prerequisite-patch-id: d1ddf9b7710e91f8062de83bd7ba55afb2c4c112
prerequisite-patch-id: 57e9b08a968aedf543d3d0d56cf1ca4db20b2a16
prerequisite-patch-id: cd98b74fa56af72af2553f391c400981d83cd4f4
prerequisite-patch-id: b730f5e42be1d89d193e63a0265495cdbf2c7d7b
prerequisite-patch-id: 9debd88fa60febed9cd7208f86603b4c2d270520
prerequisite-patch-id: 314ef9ff0c4d1d15dab1dea9d92aa065f1eac3e9
prerequisite-change-id: 20260402-add-mcu-fan-khadas-vim4-ac1cbe553c9b:v2
prerequisite-patch-id: f03a086b4137158412b2d47b3de793b858de8dde
prerequisite-patch-id: 123970c9b29c2090440f2fd71c85d3c6fd8e36de
prerequisite-patch-id: 3e2e56b0926ba327b520f935df4ced5089bbe503
prerequisite-patch-id: 65a5d76ffdbc9b3aab3385bb65cb027004c30e7e
prerequisite-patch-id: 237269801826dd3ad7fb16eb4d7d6d4eab504278
prerequisite-patch-id: 57e9b08a968aedf543d3d0d56cf1ca4db20b2a16
prerequisite-patch-id: cd98b74fa56af72af2553f391c400981d83cd4f4
prerequisite-patch-id: b730f5e42be1d89d193e63a0265495cdbf2c7d7b
prerequisite-patch-id: 8d675e7a239985c762843515b241f0a2f45f9c92
prerequisite-patch-id: 9debd88fa60febed9cd7208f86603b4c2d270520
prerequisite-patch-id: 314ef9ff0c4d1d15dab1dea9d92aa065f1eac3e9
prerequisite-patch-id: 34a2bbfe3ce30c530e69af5083aa26534b2c2560
prerequisite-patch-id: 406f88d7dabd3a870b358fb53c21686f29eb32b7
prerequisite-patch-id: d7a75ae3be0f54e0a7e81ccb0043a2f05423c9d0
prerequisite-patch-id: 5e19dc5ace12b532284246f5c2ff3f214d8a9c4f
prerequisite-patch-id: d6a87ebcf5246eb67b94ca0908afa3df9f9383fe
prerequisite-patch-id: 4809bbedf79f59e1abc52c17cffc0b1bbb43d365
prerequisite-patch-id: c050e8bac4b5491f6c7008a5ccb26f20fad38b46
prerequisite-patch-id: 30677db8fc57270787245103c0d5acf8791307b0
Best regards,
--
Ronald Claveau <linux-kernel-dev@aliel.fr>
^ permalink raw reply
* [PATCH v2 1/8] dt-bindings: thermal: amlogic: Add support for T7
From: Ronald Claveau @ 2026-04-13 10:52 UTC (permalink / raw)
To: Guillaume La Roque, Rafael J. Wysocki, Daniel Lezcano, Zhang Rui,
Lukasz Luba, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Neil Armstrong, Kevin Hilman, Jerome Brunet, Martin Blumenstingl
Cc: linux-pm, linux-amlogic, devicetree, linux-kernel,
linux-arm-kernel, Ronald Claveau
In-Reply-To: <20260413-add-thermal-t7-vim4-v2-0-1002d90a0602@aliel.fr>
Add the amlogic,t7-thermal compatible for the Amlogic T7 thermal sensor.
Unlike existing variants which use a phandle to the ao-secure syscon,
the T7 relies on a secure monitor interface described by a phandle and
a sensor index argument.
The T7 integrates multiple thermal sensors, all accessed through the
same SMC call. The sensor index argument is required to identify which
sensor's calibration data the secure monitor should return, as a single
SM_THERMAL_CALIB_READ command serves all of them.
Introduce the amlogic,secure-monitor property as a phandle-array and
make amlogic,ao-secure or amlogic,secure-monitor conditionally required
depending on the compatible.
Signed-off-by: Ronald Claveau <linux-kernel-dev@aliel.fr>
---
.../bindings/thermal/amlogic,thermal.yaml | 42 ++++++++++++++++++++--
1 file changed, 40 insertions(+), 2 deletions(-)
diff --git a/Documentation/devicetree/bindings/thermal/amlogic,thermal.yaml b/Documentation/devicetree/bindings/thermal/amlogic,thermal.yaml
index 70b273271754b..1c096116b2dda 100644
--- a/Documentation/devicetree/bindings/thermal/amlogic,thermal.yaml
+++ b/Documentation/devicetree/bindings/thermal/amlogic,thermal.yaml
@@ -21,7 +21,9 @@ properties:
- amlogic,g12a-cpu-thermal
- amlogic,g12a-ddr-thermal
- const: amlogic,g12a-thermal
- - const: amlogic,a1-cpu-thermal
+ - enum:
+ - amlogic,a1-cpu-thermal
+ - amlogic,t7-thermal
reg:
maxItems: 1
@@ -42,12 +44,39 @@ properties:
'#thermal-sensor-cells':
const: 0
+ amlogic,secure-monitor:
+ description: phandle to the secure monitor
+ $ref: /schemas/types.yaml#/definitions/phandle-array
+ items:
+ - items:
+ - description: phandle to the secure monitor
+ - description: sensor index to get specific calibration data
+
required:
- compatible
- reg
- interrupts
- clocks
- - amlogic,ao-secure
+
+allOf:
+ - if:
+ properties:
+ compatible:
+ contains:
+ enum:
+ - amlogic,a1-cpu-thermal
+ - amlogic,g12a-thermal
+ then:
+ required:
+ - amlogic,ao-secure
+ - if:
+ properties:
+ compatible:
+ contains:
+ const: amlogic,t7-thermal
+ then:
+ required:
+ - amlogic,secure-monitor
unevaluatedProperties: false
@@ -62,4 +91,13 @@ examples:
#thermal-sensor-cells = <0>;
amlogic,ao-secure = <&sec_AO>;
};
+ - |
+ a73_tsensor: temperature-sensor@20000 {
+ compatible = "amlogic,t7-thermal";
+ reg = <0x0 0x20000 0x0 0x50>;
+ interrupts = <GIC_SPI 31 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&clkc_periphs CLKID_TS>;
+ #thermal-sensor-cells = <0>;
+ amlogic,secure-monitor = <&sm 1>;
+ };
...
--
2.49.0
^ permalink raw reply related
* [PATCH v2 2/8] firmware: meson: sm: Thermal calibration read via secure monitor
From: Ronald Claveau @ 2026-04-13 10:52 UTC (permalink / raw)
To: Guillaume La Roque, Rafael J. Wysocki, Daniel Lezcano, Zhang Rui,
Lukasz Luba, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Neil Armstrong, Kevin Hilman, Jerome Brunet, Martin Blumenstingl
Cc: linux-pm, linux-amlogic, devicetree, linux-kernel,
linux-arm-kernel, Ronald Claveau
In-Reply-To: <20260413-add-thermal-t7-vim4-v2-0-1002d90a0602@aliel.fr>
Add SM_THERMAL_CALIB_READ to the secure monitor command enum and
introduce meson_sm_get_thermal_calib() to allow drivers to retrieve
thermal sensor calibration data through the firmware interface.
Signed-off-by: Ronald Claveau <linux-kernel-dev@aliel.fr>
---
include/linux/firmware/meson/meson_sm.h | 3 +++
1 file changed, 3 insertions(+)
diff --git a/include/linux/firmware/meson/meson_sm.h b/include/linux/firmware/meson/meson_sm.h
index 8eaf8922ab020..3ebc2bd9a9760 100644
--- a/include/linux/firmware/meson/meson_sm.h
+++ b/include/linux/firmware/meson/meson_sm.h
@@ -12,6 +12,7 @@ enum {
SM_EFUSE_WRITE,
SM_EFUSE_USER_MAX,
SM_GET_CHIP_ID,
+ SM_THERMAL_CALIB_READ,
SM_A1_PWRC_SET,
SM_A1_PWRC_GET,
};
@@ -27,5 +28,7 @@ int meson_sm_call_read(struct meson_sm_firmware *fw, void *buffer,
unsigned int bsize, unsigned int cmd_index, u32 arg0,
u32 arg1, u32 arg2, u32 arg3, u32 arg4);
struct meson_sm_firmware *meson_sm_get(struct device_node *firmware_node);
+int meson_sm_get_thermal_calib(struct meson_sm_firmware *fw, u32 *trim_info,
+ u32 tsensor_id);
#endif /* _MESON_SM_FW_H_ */
--
2.49.0
^ 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