* Re: [PATCH v2 02/24] clk: renesas: r9a09g047: Add audio clock and reset support
From: Geert Uytterhoeven @ 2026-04-08 9:38 UTC (permalink / raw)
To: John Madieu
Cc: Geert Uytterhoeven, Kuninori Morimoto, Vinod Koul, Mark Brown,
Rob Herring, Krzysztof Kozlowski, Michael Turquette, Stephen Boyd,
Conor Dooley, Frank Li, Liam Girdwood, Magnus Damm,
Thomas Gleixner, Jaroslav Kysela, Takashi Iwai, Philipp Zabel,
Claudiu Beznea, Biju Das, Fabrizio Castro, Lad Prabhakar,
John Madieu, linux-renesas-soc, linux-clk, devicetree,
linux-kernel, dmaengine, linux-sound
In-Reply-To: <20260402090524.9137-3-john.madieu.xa@bp.renesas.com>
Hi John,
On Thu, 2 Apr 2026 at 11:07, John Madieu <john.madieu.xa@bp.renesas.com> wrote:
> Add clock and reset entries for audio-related modules on the RZ/G3E SoC.
>
> Target modules are:
> - SSIU (Serial Sound Interface Unit) with SSI ch0-ch9
> - SCU (Sampling Rate Converter Unit) with SRC ch0-ch9, DVC ch0-ch1,
> CTU/MIX ch0-ch1
> - ADMAC (Audio DMA Controller)
> - ADG (Audio Clock Generator) with divider input clocks and audio
> master clock outputs
>
> While at it, reorder plldty_div16 to group it with other plldty fixed
> dividers.
>
> Signed-off-by: John Madieu <john.madieu.xa@bp.renesas.com>
Thanks for your patch!
> --- a/drivers/clk/renesas/r9a09g047-cpg.c
> +++ b/drivers/clk/renesas/r9a09g047-cpg.c
> @@ -460,6 +483,96 @@ static const struct rzv2h_mod_clk r9a09g047_mod_clks[] __initconst = {
> BUS_MSTOP(3, BIT(4))),
> DEF_MOD("tsu_1_pclk", CLK_QEXTAL, 16, 10, 8, 10,
> BUS_MSTOP(2, BIT(15))),
> + DEF_MOD("ssif_clk", CLK_PLLCLN_DIV8, 15, 5, 7, 21,
Please preserve sort order (by _onindex, _onbit);
> + BUS_MSTOP(2, BIT(3) | BIT(4))),
> + DEF_MOD("scu_clk", CLK_PLLCLN_DIV8, 15, 6, 7, 22,
> + BUS_MSTOP(2, BIT(0) | BIT(1))),
> + DEF_MOD("scu_clkx2", CLK_PLLCLN_DIV4, 15, 7, 7, 23,
> + BUS_MSTOP(2, BIT(0) | BIT(1))),
> + DEF_MOD("admac_clk", CLK_PLLCLN_DIV8, 15, 8, 7, 24,
> + BUS_MSTOP(2, BIT(5))),
> + DEF_MOD("adg_clks1", CLK_PLLCLN_DIV8, 15, 9, 7, 25,
> + BUS_MSTOP(2, BIT(2))),
> + DEF_MOD("adg_clk_200m", CLK_PLLCLN_DIV8, 15, 10, 7, 26,
> + BUS_MSTOP(2, BIT(2))),
> + DEF_MOD("adg_audio_clka", CLK_AUDIO_CLKA, 15, 11, 7, 27,
> + BUS_MSTOP(2, BIT(2))),
> + DEF_MOD("adg_audio_clkb", CLK_AUDIO_CLKB, 15, 12, 7, 28,
> + BUS_MSTOP(2, BIT(2))),
> + DEF_MOD("adg_audio_clkc", CLK_AUDIO_CLKC, 15, 13, 7, 29,
> + BUS_MSTOP(2, BIT(2))),
> + DEF_MOD("adg_ssi0_clk", CLK_PLLCLN_DIV8, 22, 0, -1, -1,
> + BUS_MSTOP(2, BIT(2))),
> + DEF_MOD("adg_ssi1_clk", CLK_PLLCLN_DIV8, 22, 1, -1, -1,
> + BUS_MSTOP(2, BIT(2))),
> + DEF_MOD("adg_ssi2_clk", CLK_PLLCLN_DIV8, 22, 2, -1, -1,
> + BUS_MSTOP(2, BIT(2))),
> + DEF_MOD("adg_ssi3_clk", CLK_PLLCLN_DIV8, 22, 3, -1, -1,
> + BUS_MSTOP(2, BIT(2))),
> + DEF_MOD("adg_ssi4_clk", CLK_PLLCLN_DIV8, 22, 4, -1, -1,
> + BUS_MSTOP(2, BIT(2))),
> + DEF_MOD("adg_ssi5_clk", CLK_PLLCLN_DIV8, 22, 5, -1, -1,
> + BUS_MSTOP(2, BIT(2))),
> + DEF_MOD("adg_ssi6_clk", CLK_PLLCLN_DIV8, 22, 6, -1, -1,
> + BUS_MSTOP(2, BIT(2))),
> + DEF_MOD("adg_ssi7_clk", CLK_PLLCLN_DIV8, 22, 7, -1, -1,
> + BUS_MSTOP(2, BIT(2))),
> + DEF_MOD("adg_ssi8_clk", CLK_PLLCLN_DIV8, 22, 8, -1, -1,
> + BUS_MSTOP(2, BIT(2))),
> + DEF_MOD("adg_ssi9_clk", CLK_PLLCLN_DIV8, 22, 9, -1, -1,
> + BUS_MSTOP(2, BIT(2))),
> + DEF_MOD("dvc0_clk", CLK_PLLCLN_DIV8, 23, 0, -1, -1,
> + BUS_MSTOP(2, BIT(0) | BIT(1))),
> + DEF_MOD("dvc1_clk", CLK_PLLCLN_DIV8, 23, 1, -1, -1,
> + BUS_MSTOP(2, BIT(0) | BIT(1))),
> + DEF_MOD("ctu0_mix0_clk", CLK_PLLCLN_DIV8, 23, 2, -1, -1,
> + BUS_MSTOP(2, BIT(0) | BIT(1))),
> + DEF_MOD("ctu1_mix1_clk", CLK_PLLCLN_DIV8, 23, 3, -1, -1,
> + BUS_MSTOP(2, BIT(0) | BIT(1))),
> + DEF_MOD("src0_clk", CLK_PLLCLN_DIV8, 23, 4, -1, -1,
> + BUS_MSTOP(2, BIT(0) | BIT(1))),
> + DEF_MOD("src1_clk", CLK_PLLCLN_DIV8, 23, 5, -1, -1,
> + BUS_MSTOP(2, BIT(0) | BIT(1))),
> + DEF_MOD("src2_clk", CLK_PLLCLN_DIV8, 23, 6, -1, -1,
> + BUS_MSTOP(2, BIT(0) | BIT(1))),
> + DEF_MOD("src3_clk", CLK_PLLCLN_DIV8, 23, 7, -1, -1,
> + BUS_MSTOP(2, BIT(0) | BIT(1))),
> + DEF_MOD("src4_clk", CLK_PLLCLN_DIV8, 23, 8, -1, -1,
> + BUS_MSTOP(2, BIT(0) | BIT(1))),
> + DEF_MOD("src5_clk", CLK_PLLCLN_DIV8, 23, 9, -1, -1,
> + BUS_MSTOP(2, BIT(0) | BIT(1))),
> + DEF_MOD("src6_clk", CLK_PLLCLN_DIV8, 23, 10, -1, -1,
> + BUS_MSTOP(2, BIT(0) | BIT(1))),
> + DEF_MOD("src7_clk", CLK_PLLCLN_DIV8, 23, 11, -1, -1,
> + BUS_MSTOP(2, BIT(0) | BIT(1))),
> + DEF_MOD("src8_clk", CLK_PLLCLN_DIV8, 23, 12, -1, -1,
> + BUS_MSTOP(2, BIT(0) | BIT(1))),
> + DEF_MOD("src9_clk", CLK_PLLCLN_DIV8, 23, 13, -1, -1,
> + BUS_MSTOP(2, BIT(0) | BIT(1))),
> + DEF_MOD("scu_supply_clk", CLK_PLLCLN_DIV8, 23, 14, -1, -1,
> + BUS_MSTOP(2, BIT(0) | BIT(1))),
> + DEF_MOD("ssif_supply_clk", CLK_PLLCLN_DIV8, 24, 0, -1, -1,
> + BUS_MSTOP(2, BIT(3) | BIT(4))),
> + DEF_MOD("ssi0_clk", CLK_PLLCLN_DIV8, 24, 1, -1, -1,
> + BUS_MSTOP(2, BIT(3) | BIT(4))),
> + DEF_MOD("ssi1_clk", CLK_PLLCLN_DIV8, 24, 2, -1, -1,
> + BUS_MSTOP(2, BIT(3) | BIT(4))),
> + DEF_MOD("ssi2_clk", CLK_PLLCLN_DIV8, 24, 3, -1, -1,
> + BUS_MSTOP(2, BIT(3) | BIT(4))),
> + DEF_MOD("ssi3_clk", CLK_PLLCLN_DIV8, 24, 4, -1, -1,
> + BUS_MSTOP(2, BIT(3) | BIT(4))),
> + DEF_MOD("ssi4_clk", CLK_PLLCLN_DIV8, 24, 5, -1, -1,
> + BUS_MSTOP(2, BIT(3) | BIT(4))),
> + DEF_MOD("ssi5_clk", CLK_PLLCLN_DIV8, 24, 6, -1, -1,
> + BUS_MSTOP(2, BIT(3) | BIT(4))),
> + DEF_MOD("ssi6_clk", CLK_PLLCLN_DIV8, 24, 7, -1, -1,
> + BUS_MSTOP(2, BIT(3) | BIT(4))),
> + DEF_MOD("ssi7_clk", CLK_PLLCLN_DIV8, 24, 8, -1, -1,
> + BUS_MSTOP(2, BIT(3) | BIT(4))),
> + DEF_MOD("ssi8_clk", CLK_PLLCLN_DIV8, 24, 9, -1, -1,
> + BUS_MSTOP(2, BIT(3) | BIT(4))),
> + DEF_MOD("ssi9_clk", CLK_PLLCLN_DIV8, 24, 10, -1, -1,
> + BUS_MSTOP(2, BIT(3) | BIT(4))),
> };
>
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply
* [PATCH v3] dt-bindings: gpio: cavium,thunder-8890: Remove DT binding
From: Shi Hao @ 2026-04-08 9:33 UTC (permalink / raw)
To: robh
Cc: brgl, krzk+dt, conor+dt, rric, linux-gpio, devicetree,
linux-kernel, i.shihao.999
Remove the cavium,thunder-8890 GPIO binding as there are no active
use cases. A previous attempt was made to convert the binding to DT
schema, but since the binding is unused, remove it instead.
Signed-off-by: Shi Hao <i.shihao.999@gmail.com>
---
v3:
- Remove unused legacy text-based binding
- Drop previous DT schema conversion attempt
v2: https://lore.kernel.org/linux-devicetree/CAL_Jsq+0q8Wb==Xy_bi-j2D29BzZEN81tZr7VPGikL4AM5rbbQ@mail.gmail.com/T/#t
- Rename schema file based on compatible string
- Wrap commit message body as per kernel patch guidelines
- Use appropriate maintainer name and email address in DT schema.
- Change commit subject as per guidelines
- Fix $id path
Note:
* This patch is part of the GSoC2026 application process for device tree bindings conversions
* https://github.com/LinuxFoundationGSoC/ProjectIdeas/wiki/GSoC-2026-Device-Tree-Bindings
---
.../bindings/gpio/gpio-thunderx.txt | 27 -------------------
1 file changed, 27 deletions(-)
delete mode 100644 Documentation/devicetree/bindings/gpio/gpio-thunderx.txt
diff --git a/Documentation/devicetree/bindings/gpio/gpio-thunderx.txt b/Documentation/devicetree/bindings/gpio/gpio-thunderx.txt
deleted file mode 100644
index 3f883ae29d11..000000000000
--- a/Documentation/devicetree/bindings/gpio/gpio-thunderx.txt
+++ /dev/null
@@ -1,27 +0,0 @@
-Cavium ThunderX/OCTEON-TX GPIO controller bindings
-
-Required Properties:
-- reg: The controller bus address.
-- gpio-controller: Marks the device node as a GPIO controller.
-- #gpio-cells: Must be 2.
- - First cell is the GPIO pin number relative to the controller.
- - Second cell is a standard generic flag bitfield as described in gpio.txt.
-
-Optional Properties:
-- compatible: "cavium,thunder-8890-gpio", unused as PCI driver binding is used.
-- interrupt-controller: Marks the device node as an interrupt controller.
-- #interrupt-cells: Must be present and have value of 2 if
- "interrupt-controller" is present.
- - First cell is the GPIO pin number relative to the controller.
- - Second cell is triggering flags as defined in interrupts.txt.
-
-Example:
-
-gpio_6_0: gpio@6,0 {
- compatible = "cavium,thunder-8890-gpio";
- reg = <0x3000 0 0 0 0>; /* DEVFN = 0x30 (6:0) */
- gpio-controller;
- #gpio-cells = <2>;
- interrupt-controller;
- #interrupt-cells = <2>;
-};
--
2.53.0
^ permalink raw reply related
* Re: [PATCH v2 3/4] arm64: dts: qcom: hamoa-pmics: define VADC for pmk8550
From: Konrad Dybcio @ 2026-04-08 9:27 UTC (permalink / raw)
To: Aleksandrs Vinarskis, Bjorn Andersson, Konrad Dybcio, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Hans de Goede,
Ilpo Järvinen, Bryan O'Donoghue
Cc: linux-arm-msm, devicetree, linux-kernel, platform-driver-x86,
laurentiu.tudor1, Abel Vesa, Tobias Heider, Val Packett
In-Reply-To: <20260404-dell-xps-9345-ec-v2-3-c977c3caa81f@vinarskis.com>
On 4/4/26 2:55 PM, Aleksandrs Vinarskis wrote:
> Follow pattern of pmk8350 to add missing pmk8550 VADC to hamoa.
> Register address of 0x9000 matches example schema for spmi-adc5-gen3.
>
> Signed-off-by: Aleksandrs Vinarskis <alex@vinarskis.com>
> ---
Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
Konrad
^ permalink raw reply
* [PATCH v10 2/2] watchdog: qcom: add support to get the bootstatus from IMEM
From: Kathiravan Thirumoorthy @ 2026-04-08 9:24 UTC (permalink / raw)
To: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Bjorn Andersson,
Konrad Dybcio, Wim Van Sebroeck, Guenter Roeck, Rajendra Nayak
Cc: linux-arm-msm, devicetree, linux-kernel, linux-watchdog,
Kathiravan Thirumoorthy, Konrad Dybcio
In-Reply-To: <20260408-wdt_reset_reason-v10-0-caf66786329f@oss.qualcomm.com>
When the system boots up after a watchdog reset, the EXPIRED_STATUS bit
in the WDT_STS register is cleared. To identify if the system was
restarted due to WDT expiry, XBL update the information in the IMEM region.
Update the driver to read the restart reason from IMEM and populate the
bootstatus accordingly.
With the CONFIG_WATCHDOG_SYSFS enabled, user can extract the information
as below:
cat /sys/devices/platform/soc@0/f410000.watchdog/watchdog/watchdog0/bootstatus
32
For backward compatibility, keep the EXPIRED_STATUS bit check. Add a new
function qcom_wdt_get_bootstatus() to read the restart reason from
IMEM.
Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
Signed-off-by: Kathiravan Thirumoorthy <kathiravan.thirumoorthy@oss.qualcomm.com>
---
Changes in v10:
- no changes
Changes in v9:
- Log the error message and continue with probe instead of
returning from the probe
Changes in v8:
- Picked up the R-b tag
- Updated the comment as suggested by Konrad
Changes in v7:
- no changes
Changes in v6:
- Reworked to get the restart reason code from SRAM region
Changes in v5:
- Use dev_err_probe instead of dev_err
Changes in v4:
- Kept only WDIOF_CARDRESET and dropped other codes
- Renamed qcom_wdt_get_reason_reason() to
qcom_wdt_get_bootstatus()
- Moved the existing check inside qcom_wdt_get_bootstatus()
- Dropped the device data and put all the details in the DT node
Changes in v3:
- Split the introduction of device data into separate patch
- s/bootloaders/XBL - for clarity of which bootloader is
involved
- Mention the sysfs path on to extract this information
- s/compatible/imem_compatible in the device data structure to
avoid the confusion / better naming
Changes in v2:
- Use the syscon API to access the IMEM region
- Handle the error cases returned by qcom_wdt_get_restart_reason
- Define device specific data to retrieve the IMEM compatible,
offset and the value for non secure WDT, which allows to
extend the support for other SoCs
---
drivers/watchdog/qcom-wdt.c | 42 ++++++++++++++++++++++++++++++++++++++++--
1 file changed, 40 insertions(+), 2 deletions(-)
diff --git a/drivers/watchdog/qcom-wdt.c b/drivers/watchdog/qcom-wdt.c
index dfaac5995c84..49bd04841f0c 100644
--- a/drivers/watchdog/qcom-wdt.c
+++ b/drivers/watchdog/qcom-wdt.c
@@ -9,6 +9,7 @@
#include <linux/kernel.h>
#include <linux/module.h>
#include <linux/of.h>
+#include <linux/of_address.h>
#include <linux/platform_device.h>
#include <linux/watchdog.h>
@@ -42,6 +43,7 @@ struct qcom_wdt_match_data {
const u32 *offset;
bool pretimeout;
u32 max_tick_count;
+ u32 wdt_reason_val;
};
struct qcom_wdt {
@@ -185,6 +187,7 @@ static const struct qcom_wdt_match_data match_data_ipq5424 = {
.offset = reg_offset_data_kpss,
.pretimeout = true,
.max_tick_count = 0xFFFFFU,
+ .wdt_reason_val = 5,
};
static const struct qcom_wdt_match_data match_data_kpss = {
@@ -193,6 +196,40 @@ static const struct qcom_wdt_match_data match_data_kpss = {
.max_tick_count = 0xFFFFFU,
};
+static int qcom_wdt_get_bootstatus(struct device *dev, struct qcom_wdt *wdt,
+ u32 val)
+{
+ struct device_node *imem;
+ struct resource res;
+ void __iomem *addr;
+ int ret;
+
+ imem = of_parse_phandle(dev->of_node, "sram", 0);
+ if (!imem) {
+ /* Read the EXPIRED_STATUS bit as a fallback */
+ if (readl(wdt_addr(wdt, WDT_STS)) & 1)
+ wdt->wdd.bootstatus = WDIOF_CARDRESET;
+
+ return 0;
+ }
+
+ ret = of_address_to_resource(imem, 0, &res);
+ of_node_put(imem);
+ if (ret)
+ return ret;
+
+ addr = ioremap(res.start, resource_size(&res));
+ if (!addr)
+ return -ENOMEM;
+
+ if (readl(addr) == val)
+ wdt->wdd.bootstatus = WDIOF_CARDRESET;
+
+ iounmap(addr);
+
+ return 0;
+}
+
static int qcom_wdt_probe(struct platform_device *pdev)
{
struct device *dev = &pdev->dev;
@@ -273,8 +310,9 @@ static int qcom_wdt_probe(struct platform_device *pdev)
wdt->wdd.parent = dev;
wdt->layout = data->offset;
- if (readl(wdt_addr(wdt, WDT_STS)) & 1)
- wdt->wdd.bootstatus = WDIOF_CARDRESET;
+ ret = qcom_wdt_get_bootstatus(dev, wdt, data->wdt_reason_val);
+ if (ret)
+ dev_err(dev, "failed to get the bootstatus, %d\n", ret);
/*
* If 'timeout-sec' unspecified in devicetree, assume a 30 second
--
2.34.1
^ permalink raw reply related
* [PATCH v10 1/2] dt-bindings: watchdog: qcom-wdt: Document sram property
From: Kathiravan Thirumoorthy @ 2026-04-08 9:24 UTC (permalink / raw)
To: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Bjorn Andersson,
Konrad Dybcio, Wim Van Sebroeck, Guenter Roeck, Rajendra Nayak
Cc: linux-arm-msm, devicetree, linux-kernel, linux-watchdog,
Kathiravan Thirumoorthy
In-Reply-To: <20260408-wdt_reset_reason-v10-0-caf66786329f@oss.qualcomm.com>
Document the "sram" property for the watchdog device on Qualcomm
IPQ platforms. Use this property to extract the restart reason from
IMEM, which is updated by XBL. Populate the watchdog's bootstatus sysFS
entry with this information, when the system reboots due to a watchdog
timeout.
Describe this property for the IPQ5424 watchdog device and extend support
to other targets subsequently.
Reviewed-by: Rob Herring (Arm) <robh@kernel.org>
Signed-off-by: Kathiravan Thirumoorthy <kathiravan.thirumoorthy@oss.qualcomm.com>
---
Changes in v10:
- no changes
Changes in v9:
- no changes
Changes in v8:
- no changes
Changes in v7:
- Picked up the R-b tag
Changes in v6:
- Update the 'sram' property to point to the SRAM region
Changes in v5:
- Rename the property 'qcom,imem' to 'sram'
Changes in v4:
- New patch
---
Documentation/devicetree/bindings/watchdog/qcom-wdt.yaml | 6 ++++++
1 file changed, 6 insertions(+)
diff --git a/Documentation/devicetree/bindings/watchdog/qcom-wdt.yaml b/Documentation/devicetree/bindings/watchdog/qcom-wdt.yaml
index 9f861045b71e..3ead00da3cd6 100644
--- a/Documentation/devicetree/bindings/watchdog/qcom-wdt.yaml
+++ b/Documentation/devicetree/bindings/watchdog/qcom-wdt.yaml
@@ -84,6 +84,12 @@ properties:
minItems: 1
maxItems: 5
+ sram:
+ maxItems: 1
+ description:
+ A reference to an region residing in IMEM(on-chip SRAM), which contains
+ the system restart reason value populated by the bootloader.
+
required:
- compatible
- reg
--
2.34.1
^ permalink raw reply related
* [PATCH v10 0/2] Add support to read the watchdog bootstatus from IMEM
From: Kathiravan Thirumoorthy @ 2026-04-08 9:24 UTC (permalink / raw)
To: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Bjorn Andersson,
Konrad Dybcio, Wim Van Sebroeck, Guenter Roeck, Rajendra Nayak
Cc: linux-arm-msm, devicetree, linux-kernel, linux-watchdog,
Kathiravan Thirumoorthy, Konrad Dybcio
In Qualcomm IPQ SoCs, if the system is rebooted due to the watchdog
timeout, there is no way to identify it. Current approach of checking
the EXPIRED_STATUS in WDT_STS is not working.
To achieve this, if the system is rebooted due to watchdog timeout, the
information is captured in the IMEM by the bootloader (along with other
reason codes as well).
This series attempts to address this by adding the support to read the
IMEM and populate the information via bootstatus sysfs file.
With the CONFIG_WATCHDOG_SYSFS enabled, user can extract the information
as below:
cat
/sys/devices/platform/soc@0/f410000.watchdog/watchdog/watchdog0/bootstatus
32
Signed-off-by: Kathiravan Thirumoorthy <kathiravan.thirumoorthy@oss.qualcomm.com>
---
Changes in v10:
- Rebased on next-20260407 tag
- Dropped the DTS patches from the series, so that both wdt changes can go
through the watchdog tree and once it is accepted, DTS patches will be
submitted
- Link to v9: https://lore.kernel.org/r/20260228-wdt_reset_reason-v9-0-f96d7a4825d3@oss.qualcomm.com
Changes in v9:
- Picked up the R-b tag for 1/5
- In 4/5, if fetching the boot status failed, just log the error instead
of exiting the probe
- Link to v8: https://lore.kernel.org/r/20260226-wdt_reset_reason-v8-0-011c3a8cb6ff@oss.qualcomm.com
Changes in v8:
- Collected the tags
- Updated the commit msg with reasoning in 1/5
- Updated the comment in 4/5
- Link to v7: https://lore.kernel.org/r/20260225-wdt_reset_reason-v7-0-65d5b7e3e1eb@oss.qualcomm.com
Changes in v7:
- Collected the tags
- Added the reference link in 1/5
- Added the flag 'no-memory-wc' in 2/5
- Link to v6: https://lore.kernel.org/r/20260130-wdt_reset_reason-v6-0-417ab789cd97@oss.qualcomm.com
Changes in v6:
- Moved the IMEM compatible from qcom,imem to sram binding
- Updated the 'sram' property in watchdog binding to point to SRAM
region and update the watchdog driver accordingly
- Dropped the Konrad's R-b tag in 2/5
Changes in v5:
- Rename property 'qcom,imem' to 'sram'
- Use dev_err_probe instead of dev_err
- Link to v4:
https://lore.kernel.org/linux-arm-msm/20250519-wdt_reset_reason-v4-0-d59d21275c75@oss.qualcomm.com/
Changes in v4:
- Kept only the WDIOF_CARDRESET and dropped other codes (Guenter)
- Renamed qcom_wdt_get_restart_reason() to qcom_wdt_get_bootstatus()
- Dropped the device data and describe the required information in the
DT (Konrad)
- Link to v3:
https://lore.kernel.org/linux-arm-msm/20250502-wdt_reset_reason-v3-0-b2dc7ace38ca@oss.qualcomm.com/
Changes in v3:
- Picked up the relevant tags
- Dropped the fallback compatible handling
- Split the driver changes into 2. Introduce the device data in one and
extend the same in another for the use case
- Link to v2:
https://lore.kernel.org/linux-arm-msm/20250416-wdt_reset_reason-v2-0-c65bba312914@oss.qualcomm.com/
Changes in v2:
- Dropped the RFC tag
- Reworked the driver changes to use the syscon API
- Link to v1:
https://lore.kernel.org/linux-arm-msm/20250408-wdt_reset_reason-v1-0-e6ec30c2c926@oss.qualcomm.com/
Signed-off-by: Kathiravan Thirumoorthy <kathiravan.thirumoorthy@oss.qualcomm.com>
---
Kathiravan Thirumoorthy (2):
dt-bindings: watchdog: qcom-wdt: Document sram property
watchdog: qcom: add support to get the bootstatus from IMEM
.../devicetree/bindings/watchdog/qcom-wdt.yaml | 6 ++++
drivers/watchdog/qcom-wdt.c | 42 ++++++++++++++++++++--
2 files changed, 46 insertions(+), 2 deletions(-)
---
base-commit: f3e6330d7fe42b204af05a2dbc68b379e0ad179e
change-id: 20250610-wdt_reset_reason-7a5afe702075
Best regards,
--
Kathiravan Thirumoorthy <kathiravan.thirumoorthy@oss.qualcomm.com>
^ permalink raw reply
* Re: [PATCH 2/2] riscv: dts: sophgo: sg2042: use hex for CPU unit address
From: Inochi Amaoto @ 2026-04-08 9:24 UTC (permalink / raw)
To: Conor Dooley, Inochi Amaoto
Cc: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Paul Walmsley,
Palmer Dabbelt, Albert Ou, Alexandre Ghiti, Chen Wang, Han Gao,
Nutty Liu, Guodong Xu, Guo Ren, Xiaoguang Xing, devicetree,
linux-riscv, sophgo, linux-kernel, Yixun Lan, Longbin Li
In-Reply-To: <20260407-shine-distrust-0546884c2535@spud>
On Tue, Apr 07, 2026 at 05:31:11PM +0100, Conor Dooley wrote:
> On Tue, Apr 07, 2026 at 07:26:55AM +0800, Inochi Amaoto wrote:
> > Previous the CPU unit address cpu of sg2042 use decimal, it is
> > not following the general convention for unit addresses of the
> > OF. Convent the unit address to hex to resolve this problem.
> >
> > The introduces a small ABI break for the CPU id, but it should
> > affect nothing since there is no direct full-path reference to
> > these CPU nodes.
>
> I don't think node names are abi anyway.
> Acked-by: Conor Dooley <conor.dooley@microchip.com>
Hi, Conor,
I do not fully understand this. I agree with that there is no one
use the device node path directly for node reference (especially
for the CPU node), and they prefer to the phandle. But I think it
is a thing that should be persistent, right? May I miss something?
Regards,
Inochi
^ permalink raw reply
* Re: [PATCH RFC 3/4] arm64: dts: qcom: Add GPU support for Glymur
From: Konrad Dybcio @ 2026-04-08 9:23 UTC (permalink / raw)
To: Akhil P Oommen, Bjorn Andersson, Konrad Dybcio, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Rob Clark, Sean Paul,
Dmitry Baryshkov, Abhinav Kumar, Jessica Zhang, Marijn Suijten,
David Airlie, Simona Vetter, Maarten Lankhorst, Maxime Ripard,
Thomas Zimmermann
Cc: linux-arm-msm, devicetree, linux-kernel, dri-devel, freedreno
In-Reply-To: <20260405-glymur-gpu-dt-v1-3-2135eb11c562@oss.qualcomm.com>
On 4/4/26 11:03 PM, Akhil P Oommen wrote:
> The Adreno X2 series GPU present in Glymur SoC belongs to the A8x
> family. It is a new HW IP with architectural improvements as well
> as different set of hw configs like GMEM, num SPs, Caches sizes etc.
>
> Add the GPU and GMU nodes to describe this hardware.
>
> Signed-off-by: Akhil P Oommen <akhilpo@oss.qualcomm.com>
> ---
[...]
> + gpu_zap_shader: zap-shader {
> + status = "disabled";
> + memory-region = <&gpu_microcode_mem>;
> + };
My understanding is that we may drop this
Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
Konrad
^ permalink raw reply
* Re: [PATCH v4 3/5] media: iris: Add platform data for X1P42100
From: Wangao Wang @ 2026-04-08 9:22 UTC (permalink / raw)
To: Dikshita Agarwal, Bryan O'Donoghue, Vikash Garodia,
Abhinav Kumar, Mauro Carvalho Chehab, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Bjorn Andersson, Konrad Dybcio
Cc: wangao.wang, linux-media, linux-arm-msm, devicetree, linux-kernel
In-Reply-To: <fe1379a5-57f2-e618-dbeb-32d1c3c7536a@oss.qualcomm.com>
On 2026/4/8 17:20, Dikshita Agarwal wrote:
>
>
> On 4/8/2026 2:47 PM, Wangao Wang wrote:
>>
>>
>> On 2026/4/1 20:40, Dikshita Agarwal wrote:
>>
>>>> +const struct iris_platform_data x1p42100_data = {
>>>> + .get_instance = iris_hfi_gen2_get_instance,
>>>> + .init_hfi_command_ops = iris_hfi_gen2_command_ops_init,
>>>> + .init_hfi_response_ops = iris_hfi_gen2_response_ops_init,
>>>> + .get_vpu_buffer_size = iris_vpu_buf_size,
>>>
>>> this needs a rebase on latest platform rework series.
>>>
>>> Thanks,
>>> Dikshita
>>>
>>
>> Will fix in next version.
>
> The rework series was expected to land in 7.1, which may no longer be the
> case. Please hold off on any rebasing until it is clear what the correct
> base for this series should be.
>
> Thanks,
> Dikshita
>>
Got it.
--
Best Regards,
Wangao
^ permalink raw reply
* Re: [PATCH v4 3/5] media: iris: Add platform data for X1P42100
From: Dikshita Agarwal @ 2026-04-08 9:20 UTC (permalink / raw)
To: Wangao Wang, Bryan O'Donoghue, Vikash Garodia, Abhinav Kumar,
Mauro Carvalho Chehab, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Bjorn Andersson, Konrad Dybcio
Cc: linux-media, linux-arm-msm, devicetree, linux-kernel
In-Reply-To: <7e7f7778-9a26-45f3-89c1-0113969cc1d8@oss.qualcomm.com>
On 4/8/2026 2:47 PM, Wangao Wang wrote:
>
>
> On 2026/4/1 20:40, Dikshita Agarwal wrote:
>
>>> +const struct iris_platform_data x1p42100_data = {
>>> + .get_instance = iris_hfi_gen2_get_instance,
>>> + .init_hfi_command_ops = iris_hfi_gen2_command_ops_init,
>>> + .init_hfi_response_ops = iris_hfi_gen2_response_ops_init,
>>> + .get_vpu_buffer_size = iris_vpu_buf_size,
>>
>> this needs a rebase on latest platform rework series.
>>
>> Thanks,
>> Dikshita
>>
>
> Will fix in next version.
The rework series was expected to land in 7.1, which may no longer be the
case. Please hold off on any rebasing until it is clear what the correct
base for this series should be.
Thanks,
Dikshita
>
^ permalink raw reply
* Re: [PATCH 3/3] reset: eswin: Add eic7700 HSP reset driver
From: Philipp Zabel @ 2026-04-08 9:19 UTC (permalink / raw)
To: dongxuyang, mturquette, sboyd, robh, krzk+dt, conor+dt, linux-clk,
devicetree, linux-kernel, huangyifeng
Cc: ningyu, linmin, pinkesh.vaghela
In-Reply-To: <20260403093628.780-1-dongxuyang@eswincomputing.com>
On Fr, 2026-04-03 at 17:36 +0800, dongxuyang@eswincomputing.com wrote:
> From: Xuyang Dong <dongxuyang@eswincomputing.com>
>
> Add auxiliary driver to support ESWIN EIC7700 high-speed peripherals
> system. The reset controller is created using the auxiliary device
> framework and set up in the clock driver.
>
> Signed-off-by: Xuyang Dong <dongxuyang@eswincomputing.com>
> ---
> drivers/reset/Kconfig | 13 +++
> drivers/reset/Makefile | 1 +
> drivers/reset/reset-eic7700-hsp.c | 151 ++++++++++++++++++++++++++++++
> 3 files changed, 165 insertions(+)
> create mode 100644 drivers/reset/reset-eic7700-hsp.c
>
> diff --git a/drivers/reset/Kconfig b/drivers/reset/Kconfig
> index 7ce151f6a7e4..50bb0cd069ba 100644
> --- a/drivers/reset/Kconfig
> +++ b/drivers/reset/Kconfig
> @@ -83,6 +83,19 @@ config RESET_EIC7700
> The driver supports eic7700 series chips and provides functionality for
> asserting and deasserting resets on the chip.
>
> +config RESET_EIC7700_HSP
> + tristate "EIC7700 HSP Reset controller"
> + depends on ARCH_ESWIN || COMPILE_TEST
> + depends on COMMON_CLK_EIC7700_HSP
Why?
Please make this buildable under COMPILE_TEST without enabling the
clock driver.
[...]
> diff --git a/drivers/reset/reset-eic7700-hsp.c b/drivers/reset/reset-eic7700-hsp.c
> new file mode 100644
> index 000000000000..fe9822078bcc
> --- /dev/null
> +++ b/drivers/reset/reset-eic7700-hsp.c
> @@ -0,0 +1,151 @@
[...]
> +static int eic7700_hsp_reset_assert(struct reset_controller_dev *rcdev,
> + unsigned long id)
> +{
> + struct eic7700_hsp_reset_data *data = to_eic7700_hsp_reset(rcdev);
> + int ret;
> +
> + if (eic7700_hsp_reset[id].active_low)
> + ret = regmap_clear_bits(data->regmap, eic7700_hsp_reset[id].reg,
> + eic7700_hsp_reset[id].bit);
> + else
> + ret = regmap_set_bits(data->regmap, eic7700_hsp_reset[id].reg,
> + eic7700_hsp_reset[id].bit);
This is essentially regmap_assign_bits() open-coded.
> +
> + return ret;
> +}
> +
> +static int eic7700_hsp_reset_deassert(struct reset_controller_dev *rcdev,
> + unsigned long id)
> +{
> + struct eic7700_hsp_reset_data *data = to_eic7700_hsp_reset(rcdev);
> + int ret;
> +
> + if (eic7700_hsp_reset[id].active_low)
> + ret = regmap_set_bits(data->regmap, eic7700_hsp_reset[id].reg,
> + eic7700_hsp_reset[id].bit);
> + else
> + ret = regmap_clear_bits(data->regmap, eic7700_hsp_reset[id].reg,
> + eic7700_hsp_reset[id].bit);
Same as above.
> +
> + return ret;
> +}
> +
> +static int eic7700_hsp_reset_reset(struct reset_controller_dev *rcdev,
> + unsigned long id)
> +{
> + int ret;
> +
> + ret = eic7700_hsp_reset_assert(rcdev, id);
> + if (ret)
> + return ret;
> +
> + usleep_range(10, 15);
> +
> + return eic7700_hsp_reset_deassert(rcdev, id);
> +}
Does any of the consumer drivers (SATA, USB) actually use
reset_control_reset()? If not, don't implement this.
> +
> +static const struct reset_control_ops eic7700_hsp_reset_ops = {
> + .reset = eic7700_hsp_reset_reset,
> + .assert = eic7700_hsp_reset_assert,
> + .deassert = eic7700_hsp_reset_deassert,
> +};
> +
> +static int eic7700_hsp_reset_probe(struct auxiliary_device *adev,
> + const struct auxiliary_device_id *id)
> +{
> + struct eic7700_hsp_reset_data *data;
> + struct device *dev = &adev->dev;
> +
> + data = devm_kzalloc(dev, sizeof(*data), GFP_KERNEL);
> + if (!data)
> + return -ENOMEM;
> +
> + data->regmap = devm_regmap_init_mmio
> + (dev, (__force void __iomem *)adev->dev.platform_data,
Consider letting the parent clk driver create the regmap und using
dev_get_regmap().
> + &eic7700_hsp_regmap_config);
> + if (IS_ERR(data->regmap))
> + return dev_err_probe(dev, PTR_ERR(data->regmap),
> + "failed to get regmap!\n");
> +
> + data->rcdev.owner = THIS_MODULE;
> + data->rcdev.ops = &eic7700_hsp_reset_ops;
> + data->rcdev.of_node = dev->parent->of_node;
> + data->rcdev.of_reset_n_cells = 1;
No need to set of_reset_n_cells, this value is ignored if of_xlate
isn't also set.
regards
Philipp
^ permalink raw reply
* Re: [PATCH RFC 2/4] arm64: dts: qcom: glymur: Add GPU smmu node
From: Konrad Dybcio @ 2026-04-08 9:18 UTC (permalink / raw)
To: Akhil P Oommen, Bjorn Andersson, Konrad Dybcio, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Rob Clark, Sean Paul,
Dmitry Baryshkov, Abhinav Kumar, Jessica Zhang, Marijn Suijten,
David Airlie, Simona Vetter, Maarten Lankhorst, Maxime Ripard,
Thomas Zimmermann
Cc: linux-arm-msm, devicetree, linux-kernel, dri-devel, freedreno,
Rajendra Nayak, Rajendra Nayak
In-Reply-To: <20260405-glymur-gpu-dt-v1-2-2135eb11c562@oss.qualcomm.com>
On 4/4/26 11:03 PM, Akhil P Oommen wrote:
> From: Rajendra Nayak <quic_rjendra@quicinc.com>
>
> Add the nodes to describe the GPU SMMU node.
>
> Signed-off-by: Rajendra Nayak <rajendra.nayak@oss.qualcomm.com>
> Signed-off-by: Akhil P Oommen <akhilpo@oss.qualcomm.com>
> ---
Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
Konrad
^ permalink raw reply
* Re: [PATCH v4 3/5] media: iris: Add platform data for X1P42100
From: Wangao Wang @ 2026-04-08 9:17 UTC (permalink / raw)
To: Dikshita Agarwal, Bryan O'Donoghue, Vikash Garodia,
Abhinav Kumar, Mauro Carvalho Chehab, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Bjorn Andersson, Konrad Dybcio
Cc: wangao.wang, linux-media, linux-arm-msm, devicetree, linux-kernel
In-Reply-To: <437123c2-35af-227c-3fe1-7d45ea1243da@oss.qualcomm.com>
On 2026/4/1 20:40, Dikshita Agarwal wrote:
>> +const struct iris_platform_data x1p42100_data = {
>> + .get_instance = iris_hfi_gen2_get_instance,
>> + .init_hfi_command_ops = iris_hfi_gen2_command_ops_init,
>> + .init_hfi_response_ops = iris_hfi_gen2_response_ops_init,
>> + .get_vpu_buffer_size = iris_vpu_buf_size,
>
> this needs a rebase on latest platform rework series.
>
> Thanks,
> Dikshita
>
Will fix in next version.
--
Best Regards,
Wangao
^ permalink raw reply
* Re: [PATCH v4 2/5] media: iris: Add hardware power on/off ops for X1P42100
From: Wangao Wang @ 2026-04-08 9:16 UTC (permalink / raw)
To: Krzysztof Kozlowski
Cc: wangao.wang, 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
In-Reply-To: <20260402-lurking-tested-marmoset-f315b4@quoll>
On 2026/4/2 15:08, Krzysztof Kozlowski wrote:
>
> Why no IRIS_HW_AHB_CLK in power on sequence?
>
> So if you rewrite the code that you have list of clocks for hw power on
> (IRIS_HW_CLK + IRIS_HW_AHB_CLK for all variants, +IRIS_BSE_HW_CLK on
> this variant) you could have just one function for all of them and
> devices will be fully compatible.
>
> No?
>
The original patch was to add the IRIS_BSE_HW_CLK operation into the
common API, but Dmitry requested to separate Purwa's implementation out
independently.
--
Best Regards,
Wangao
^ permalink raw reply
* Re: [PATCH v4 2/5] media: iris: Add hardware power on/off ops for X1P42100
From: Wangao Wang @ 2026-04-08 9:14 UTC (permalink / raw)
To: Dikshita Agarwal, Bryan O'Donoghue, Vikash Garodia,
Abhinav Kumar, Mauro Carvalho Chehab, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Bjorn Andersson, Konrad Dybcio
Cc: wangao.wang, linux-media, linux-arm-msm, devicetree, linux-kernel
In-Reply-To: <9bfaf15e-99c8-a98e-d0df-9df86872bfe8@oss.qualcomm.com>
On 2026/4/1 20:37, Dikshita Agarwal wrote:
>> +
>> +static void iris_vpu3_purwa_power_off_hardware(struct iris_core *core)
>> +{
>> + iris_vpu3_power_off_hardware(core);
>
> this will eventually call iris_vpu_power_off_hw which would try to disable
> IRIS_HW_AHB_CLK which is not applicable to purwa I think, will that not
> create any issue?
>
All VPU3s will call this hook, but none of them have IRIS_HW_AHB_CLK.
--
Best Regards,
Wangao
^ permalink raw reply
* Re: [PATCH] arm64: dts: meson-gxl-p230: fix ethernet PHY interrupt number
From: Neil Armstrong @ 2026-04-08 9:12 UTC (permalink / raw)
To: linux-kernel, linux-amlogic, linux-arm-kernel, devicetree,
Jun Yan
Cc: robh, krzk+dt, conor+dt, khilman, jbrunet, martin.blumenstingl
In-Reply-To: <20260330145111.115318-1-jerrysteve1101@gmail.com>
Hi,
On Mon, 30 Mar 2026 22:51:11 +0800, Jun Yan wrote:
> Correct the interrupt number assigned to the Realtek PHY in the p230
>
> following the same logic as commit 3106507e1004 ("ARM64: dts: meson-gxm:
> fix q200 interrupt number"),as reported in [PATCH 0/2] Ethernet PHY
> interrupt improvements [1].
>
> [1] https://lore.kernel.org/all/20171202214037.17017-1-martin.blumenstingl@googlemail.com/
>
> [...]
Thanks, Applied to https://git.kernel.org/pub/scm/linux/kernel/git/amlogic/linux.git (v7.1/arm64-dt)
[1/1] arm64: dts: meson-gxl-p230: fix ethernet PHY interrupt number
https://git.kernel.org/amlogic/c/b18d1b23558114b3c64fec7b515ca80c76e58171
These changes has been applied on the intermediate git tree [1].
The v7.1/arm64-dt branch will then be sent via a formal Pull Request to the Linux SoC maintainers
for inclusion in their intermediate git branches in order to be sent to Linus during
the next merge window, or sooner if it's a set of fixes.
In the cases of fixes, those will be merged in the current release candidate
kernel and as soon they appear on the Linux master branch they will be
backported to the previous Stable and Long-Stable kernels [2].
The intermediate git branches are merged daily in the linux-next tree [3],
people are encouraged testing these pre-release kernels and report issues on the
relevant mailing-lists.
If problems are discovered on those changes, please submit a signed-off-by revert
patch followed by a corrective changeset.
[1] https://git.kernel.org/pub/scm/linux/kernel/git/amlogic/linux.git
[2] https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git
[3] https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git
--
Neil
^ permalink raw reply
* Re: [PATCH] clk: microchip: mpfs-ccc: fix out-of-bounds write
From: Krzysztof Kozlowski @ 2026-04-08 9:11 UTC (permalink / raw)
To: Aleš Pečnik
Cc: Conor Dooley, Daire McNamara, Michael Turquette, Stephen Boyd,
Rob Herring, Krzysztof Kozlowski, linux-riscv, linux-clk,
linux-kernel, devicetree
In-Reply-To: <20260408-mpfs-clk-oob-write-v1-1-8b3b387f2a6f@skylabs.si>
On Wed, Apr 08, 2026 at 07:07:34AM +0200, Aleš Pečnik wrote:
> Issue was allocated array size for clk_data.
> When clocks are being registered their index is taken from defines in
> dt-bindings. The last 2 clocks had their index outside of allocated range.
> Two defines (CLK_CCC_DLL0, CLK_CCC_DLL1) were not used and skipped over
> which was not taken into account when allocating the array.
>
> This patch is minimal change to resolve the issue.
>
> Issue was found using KASAN when debugging unrelated xdma driver issue.
> Consequently fixing this issue also resolved xdma driver issue.
>
> Related dmesg output:
> [ 0.290703] BUG: KASAN: slab-out-of-bounds in mpfs_ccc_register_outputs.constprop.0+0xd0/0x1fa
> [ 0.290984] Write of size 8 at addr ffffffe7be6e3ca8 by task swapper/0/1
> [ 0.291253] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 6.1.43-linux4microchip+fpga-2023.09 #1
> [ 0.291482] Hardware name: Skylabs HPC (DT)
> [ 0.291611] Call Trace:
> ...
> [ 0.292999] [<ffffffff808508c8>] mpfs_ccc_register_outputs.constprop.0+0xd0/0x1fa
> [ 0.293245] [<ffffffff80850b66>] mpfs_ccc_probe+0x174/0x30e
> [ 0.293437] [<ffffffff808d4af2>] platform_probe+0x74/0xba
> ...
>
> Fixes: d39fb172760e ("clk: microchip: add PolarFire SoC fabric clock support")
> Signed-off-by: Aleš Pečnik <ales.pecnik@skylabs.si>
> ---
> drivers/clk/microchip/clk-mpfs-ccc.c | 3 +--
> include/dt-bindings/clock/microchip,mpfs-clock.h | 2 ++
Please run scripts/checkpatch.pl on the patches and fix reported
warnings. After that, run also 'scripts/checkpatch.pl --strict' on the
patches and (probably) fix more warnings. Some warnings can be ignored,
especially from --strict run, but the code here looks like it needs a
fix. Feel free to get in touch if the warning is not clear.
> 2 files changed, 3 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/clk/microchip/clk-mpfs-ccc.c b/drivers/clk/microchip/clk-mpfs-ccc.c
> index 3a3ea2d142f8..71fbb6265ea4 100644
> --- a/drivers/clk/microchip/clk-mpfs-ccc.c
> +++ b/drivers/clk/microchip/clk-mpfs-ccc.c
> @@ -234,8 +234,7 @@ static int mpfs_ccc_probe(struct platform_device *pdev)
> unsigned int num_clks;
> int ret;
>
> - num_clks = ARRAY_SIZE(mpfs_ccc_pll_clks) + ARRAY_SIZE(mpfs_ccc_pll0out_clks) +
> - ARRAY_SIZE(mpfs_ccc_pll1out_clks);
> + num_clks = CLK_CCC_NUM;
>
> clk_data = devm_kzalloc(&pdev->dev, struct_size(clk_data, hw_data.hws, num_clks),
> GFP_KERNEL);
> diff --git a/include/dt-bindings/clock/microchip,mpfs-clock.h b/include/dt-bindings/clock/microchip,mpfs-clock.h
> index b52f19a2b480..8d53f2b81a54 100644
> --- a/include/dt-bindings/clock/microchip,mpfs-clock.h
> +++ b/include/dt-bindings/clock/microchip,mpfs-clock.h
> @@ -73,4 +73,6 @@
> #define CLK_CCC_DLL1_OUT0 14
> #define CLK_CCC_DLL1_OUT1 15
>
> +#define CLK_CCC_NUM 16
Not a binding, drop from bindings. Driver is the place for that.
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH 1/2] dt-bindings: pinctrl: pinctrl-single: Add brcm,bcm7038-padconf
From: Krzysztof Kozlowski @ 2026-04-08 9:11 UTC (permalink / raw)
To: Florian Fainelli
Cc: linux-kernel, Linus Walleij, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Tony Lindgren, Haojian Zhuang,
open list:PIN CONTROL SUBSYSTEM,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
moderated list:PIN CONTROLLER - SINGLE,
open list:PIN CONTROLLER - SINGLE
In-Reply-To: <20260407235611.550515-2-florian.fainelli@broadcom.com>
On Tue, Apr 07, 2026 at 04:56:10PM -0700, Florian Fainelli wrote:
> Add the "brcm,bcm7038-padconf" compatible to the pinctrl-single binding.
>
> Signed-off-by: Florian Fainelli <florian.fainelli@broadcom.com>
> ---
> Documentation/devicetree/bindings/pinctrl/pinctrl-single.yaml | 4 ++++
> 1 file changed, 4 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/pinctrl/pinctrl-single.yaml b/Documentation/devicetree/bindings/pinctrl/pinctrl-single.yaml
> index 9135788cf62e..afe7329a1df2 100644
> --- a/Documentation/devicetree/bindings/pinctrl/pinctrl-single.yaml
> +++ b/Documentation/devicetree/bindings/pinctrl/pinctrl-single.yaml
> @@ -38,6 +38,10 @@ properties:
> - enum:
> - marvell,pxa1908-padconf
> - const: pinconf-single
> + - items:
> + - enum:
> + - brcm,bcm7038-padconf
> + - const: pinctrl-single
If there is going to be a new version, entire block should be placed
before 'ti' to have some sort of sorting by compatible.
But no need to resend just for that.
Acked-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
Best regards,
Krzysztof
^ permalink raw reply
* Re: (subset) [PATCH v5 0/9] arm64: dts: amlogic: Add MMC/SD/SDIO support for Khadas VIM4 (Amlogic T7)
From: Neil Armstrong @ 2026-04-08 9:10 UTC (permalink / raw)
To: Kevin Hilman, Jerome Brunet, Martin Blumenstingl, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Ulf Hansson, Johannes Berg,
van Spriel, Ronald Claveau
Cc: linux-arm-kernel, linux-amlogic, devicetree, linux-kernel,
linux-mmc, linux-wireless, Conor Dooley, Xianwei Zhao, Nick Xie
In-Reply-To: <20260326-add-emmc-t7-vim4-v5-0-d3f182b48e9d@aliel.fr>
Hi,
On Thu, 26 Mar 2026 10:59:11 +0100, Ronald Claveau wrote:
> This patch series depends on Jian's SCMI clock patches yet to merge
> https://lore.kernel.org/all/20260313070022.700437-1-jian.hu@amlogic.com/
>
> This series adds device tree support for the MMC, SD card and SDIO
> interfaces on the Amlogic T7 SoC and the Khadas VIM4 board.
>
> The first patches add the necessary building blocks in the T7 SoC
> DTSI: pinctrl nodes for pin muxing, PWM controller nodes, and MMC
> controller nodes. The amlogic,t7-mmc and amlogic,t7-pwm compatible
> strings are introduced with fallbacks to existing drivers, avoiding
> the need for new driver code.
>
> [...]
Thanks, Applied to https://git.kernel.org/pub/scm/linux/kernel/git/amlogic/linux.git (v7.1/arm64-dt)
[3/9] arm64: dts: amlogic: t7: Add MMC controller nodes
https://git.kernel.org/amlogic/c/759613b88fbf051c8a977a5e5b046b28a18ed5c7
[5/9] arm64: dts: amlogic: t7: Add PWM controller nodes
https://git.kernel.org/amlogic/c/596e3c1bfa7869cf15079e5c6e586575013b2fc3
[7/9] arm64: dts: amlogic: t7: khadas-vim4: Add SDIO power sequence and WiFi clock
https://git.kernel.org/amlogic/c/647228c014ddbd336a97e74bde81cbb2f7cbd927
[9/9] arm64: dts: amlogic: t7: khadas-vim4: Add MMC nodes
https://git.kernel.org/amlogic/c/00cca65deacb29947ef32011827ff88fd59dab55
These changes has been applied on the intermediate git tree [1].
The v7.1/arm64-dt branch will then be sent via a formal Pull Request to the Linux SoC maintainers
for inclusion in their intermediate git branches in order to be sent to Linus during
the next merge window, or sooner if it's a set of fixes.
In the cases of fixes, those will be merged in the current release candidate
kernel and as soon they appear on the Linux master branch they will be
backported to the previous Stable and Long-Stable kernels [2].
The intermediate git branches are merged daily in the linux-next tree [3],
people are encouraged testing these pre-release kernels and report issues on the
relevant mailing-lists.
If problems are discovered on those changes, please submit a signed-off-by revert
patch followed by a corrective changeset.
[1] https://git.kernel.org/pub/scm/linux/kernel/git/amlogic/linux.git
[2] https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git
[3] https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git
--
Neil
^ permalink raw reply
* Re: (subset) [PATCH 0/2] Fix Amlogic T7 null reset ops and DT required property
From: Neil Armstrong @ 2026-04-08 9:10 UTC (permalink / raw)
To: Philipp Zabel, Kevin Hilman, Jerome Brunet, Martin Blumenstingl,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, Ronald Claveau
Cc: linux-arm-kernel, linux-amlogic, linux-kernel, devicetree
In-Reply-To: <20260331-fix-aml-t7-null-reset-v1-0-eb95b625234c@aliel.fr>
Hi,
On Tue, 31 Mar 2026 16:24:03 +0200, Ronald Claveau wrote:
> 1. As reset is required for MMC DT, this patch series aims to add the currently missing required driver ops.
>
> Whithout this patch the following kernel null error appears:
>
> [ 0.459197] Unable to handle kernel NULL pointer dereference at virtual address 0000000000000000
> [ 0.459978] Mem abort info:
> [ 0.460324] ESR = 0x0000000096000004
> [ 0.460791] EC = 0x25: DABT (current EL), IL = 32 bits
> [ 0.461471] SET = 0, FnV = 0
> [ 0.461830] EA = 0, S1PTW = 0
> [ 0.462220] FSC = 0x04: level 0 translation fault
> [ 0.462722] Unable to handle kernel NULL pointer dereference at virtual address 0000000000000000
> [ 0.462826] Data abort info:
> [ 0.462829] ISV = 0, ISS = 0x00000004, ISS2 = 0x00000000
> [ 0.462842] Mem abort info:
> [ 0.462849] CM = 0, WnR = 0, TnD = 0, TagAccess = 0
> [ 0.462859] ESR = 0x0000000096000004
> [ 0.462865] GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0
> [ 0.462874] EC = 0x25: DABT (current EL), IL = 32 bits
> [ 0.462882] [0000000000000000] user address but active_mm is swapper
> [ 0.462890] SET = 0, FnV = 0
> [ 0.462901] Internal error: Oops: 0000000096000004 [#1] SMP
> [ 0.462909] EA = 0, S1PTW = 0
> [ 0.462917] Modules linked in:
> [ 0.462925] FSC = 0x04: level 0 translation fault
> [ 0.462932]
> [ 0.462939] Data abort info:
> [ 0.462951] CPU: 4 UID: 0 PID: 90 Comm: kworker/u34:3 Not tainted 7.0.0-rc4-next-20260319 #41 PREEMPT
> [ 0.463920] ISV = 0, ISS = 0x00000004, ISS2 = 0x00000000
> [ 0.463927] Hardware name: Khadas VIM4 (DT)
> [ 0.463940] CM = 0, WnR = 0, TnD = 0, TagAccess = 0
> [ 0.463951] Workqueue: async async_run_entry_fn
> [ 0.464277] GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0
> [ 0.464286]
> [ 0.464294] [0000000000000000] user address but active_mm is swapper
> [ 0.464304] pstate: 60000005 (nZCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--)
> [ 0.465935] pc : reset_control_reset+0x48/0x1d0
> [ 0.466409] lr : reset_control_reset+0x38/0x1d0
> [ 0.479907] sp : ffff800083943b60
> [ 0.479911] x29: ffff800083943b60 x28: 0000000000000000 x27: 0000000000000000
> [ 0.479926] x26: ffff80008310a9c0 x25: 0000000000000000 x24: ffff000100372005
> [ 0.481212] x23: ffff0001003a4000 x22: ffff000100fee988 x21: 0000000000000000
> [ 0.482976] x20: ffff00023f00a788 x19: ffff000100fee980 x18: 0000000000000006
> [ 0.483865] x17: 64656c62616e655f x16: 7469647561206465 x15: ffff800083943530
> [ 0.484753] x14: 0000000000000000 x13: 000000000000022d x12: 0000000000002000
> [ 0.485642] x11: ffff00023efdc754 x10: ffff00023efdc740 x9 : 0000000000000000
> [ 0.486530] x8 : ffff00023efd8a40 x7 : fffffffffffffe70 x6 : ffff00023efd89e0
> [ 0.487418] x5 : 0000000000000001 x4 : 0000000000000000 x3 : 0000000000000001
> [ 0.488307] x2 : ffff000102002488 x1 : ffff8000822248c0 x0 : 0000000000000000
> [ 0.489196] Call trace:
> [ 0.489500] reset_control_reset+0x48/0x1d0 (P)
> [ 0.490062] __device_reset+0xc8/0xfc
> [ 0.490517] meson_mmc_probe+0xe8/0x3d4
> [ 0.490994] platform_probe+0x5c/0x98
> [ 0.491448] really_probe+0xbc/0x298
> [ 0.491892] __driver_probe_device+0x78/0x12c
> [ 0.492434] driver_probe_device+0xd4/0x164
> [ 0.492954] __device_attach_driver+0xb8/0x140
> [ 0.493507] bus_for_each_drv+0x84/0xe0
> [ 0.493983] __device_attach_async_helper+0xac/0xd0
> [ 0.494590] async_run_entry_fn+0x34/0xe0
> [ 0.495089] process_one_work+0x158/0x29c
> [ 0.495587] worker_thread+0x18c/0x308
> [ 0.496053] kthread+0x11c/0x128
> [ 0.496453] ret_from_fork+0x10/0x20
> [ 0.496904] Code: f9400262 2a0003f5 b4000902 f9400040 (f9400003)
> [ 0.497661] ---[ end trace 0000000000000000 ]---
> [ 0.498234] Internal error: Oops: 0000000096000004 [#2] SMP
> [ 0.498935] Modules linked in:
> [ 0.499319] CPU: 1 UID: 0 PID: 88 Comm: kworker/u34:1 Tainted: G D 7.0.0-rc4-next-20260319 #41 PREEMPT
> [ 0.500669] Tainted: [D]=DIE
> [ 0.501025] Hardware name: Khadas VIM4 (DT)
> [ 0.501547] Workqueue: async async_run_entry_fn
> [ 0.502109] pstate: 60000005 (nZCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--)
> [ 0.502975] pc : reset_control_reset+0x48/0x1d0
> [ 0.503538] lr : reset_control_reset+0x38/0x1d0
> [ 0.504102] sp : ffff800083903b60
> [ 0.504513] x29: ffff800083903b60 x28: 0000000000000000 x27: 0000000000000000
> [ 0.505402] x26: ffff000100059028 x25: 0000000000000000 x24: ffff000100372005
> [ 0.506290] x23: ffff000100ec9400 x22: ffff0001003f6e08 x21: 0000000000000000
> [ 0.507178] x20: ffff00023f00b440 x19: ffff0001003f6e00 x18: 00000000ffffffff
> [ 0.508067] x17: 0000000000000000 x16: 0000000000000000 x15: ffff8000839037e0
> [ 0.508955] x14: 0000000000000000 x13: 0000000000000290 x12: 0000000000002000
> [ 0.509843] x11: ffff00023efdc754 x10: ffff00023efdc740 x9 : 0000000000000000
> [ 0.510732] x8 : ffff00023efd8bc0 x7 : fffffffffffffe70 x6 : ffff00023efd8b60
> [ 0.511620] x5 : 0000000000000001 x4 : 0000000000000000 x3 : 0000000000000001
> [ 0.512508] x2 : ffff000102002488 x1 : ffff800082224a40 x0 : 0000000000000000
> [ 0.513397] Call trace:
> [ 0.513700] reset_control_reset+0x48/0x1d0 (P)
> [ 0.514263] __device_reset+0xc8/0xfc
> [ 0.514718] meson_mmc_probe+0xe8/0x3d4
> [ 0.515195] platform_probe+0x5c/0x98
> [ 0.515650] really_probe+0xbc/0x298
> [ 0.516094] __driver_probe_device+0x78/0x12c
> [ 0.516636] driver_probe_device+0xd4/0x164
> [ 0.517156] __device_attach_driver+0xb8/0x140
> [ 0.517709] bus_for_each_drv+0x84/0xe0
> [ 0.518185] __device_attach_async_helper+0xac/0xd0
> [ 0.518792] async_run_entry_fn+0x34/0xe0
> [ 0.519290] process_one_work+0x158/0x29c
> [ 0.519788] worker_thread+0x18c/0x308
> [ 0.520254] kthread+0x11c/0x128
> [ 0.520655] ret_from_fork+0x10/0x20
> [ 0.521103] Code: f9400262 2a0003f5 b4000902 f9400040 (f9400003)
> [ 0.521860] ---[ end trace 0000000000000000 ]---
>
> [...]
Thanks, Applied to https://git.kernel.org/pub/scm/linux/kernel/git/amlogic/linux.git (v7.1/arm64-dt)
[2/2] arm64: dts: amlogic: t7: Fix missing required reset property
https://git.kernel.org/amlogic/c/98da3e91a6157d2833af356620665a9734d26133
These changes has been applied on the intermediate git tree [1].
The v7.1/arm64-dt branch will then be sent via a formal Pull Request to the Linux SoC maintainers
for inclusion in their intermediate git branches in order to be sent to Linus during
the next merge window, or sooner if it's a set of fixes.
In the cases of fixes, those will be merged in the current release candidate
kernel and as soon they appear on the Linux master branch they will be
backported to the previous Stable and Long-Stable kernels [2].
The intermediate git branches are merged daily in the linux-next tree [3],
people are encouraged testing these pre-release kernels and report issues on the
relevant mailing-lists.
If problems are discovered on those changes, please submit a signed-off-by revert
patch followed by a corrective changeset.
[1] https://git.kernel.org/pub/scm/linux/kernel/git/amlogic/linux.git
[2] https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git
[3] https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git
--
Neil
^ permalink raw reply
* Re: [PATCH 2/2] riscv: dts: sophgo: sg2042: use hex for CPU unit address
From: Chen Wang @ 2026-04-08 9:10 UTC (permalink / raw)
To: Inochi Amaoto, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Paul Walmsley, Palmer Dabbelt, Albert Ou, Alexandre Ghiti,
Han Gao, Nutty Liu, Guodong Xu, Guo Ren, Xiaoguang Xing
Cc: devicetree, linux-riscv, sophgo, linux-kernel, Yixun Lan,
Longbin Li
In-Reply-To: <20260406232655.144043-3-inochiama@gmail.com>
On 4/7/2026 7:26 AM, Inochi Amaoto wrote:
> Previous the CPU unit address cpu of sg2042 use decimal, it is
> not following the general convention for unit addresses of the
> OF. Convent the unit address to hex to resolve this problem.
>
> The introduces a small ABI break for the CPU id, but it should
> affect nothing since there is no direct full-path reference to
> these CPU nodes.
>
> Fixes: ae5bac370ed4 ("riscv: dts: sophgo: Add initial device tree of Sophgo SRD3-10")
> Signed-off-by: Inochi Amaoto <inochiama@gmail.com>
> Link: https://lore.kernel.org/devicetree-spec/00ddad5a-02f5-474e-af9c-11ce7716ddfc@iscas.ac.cn/
Reviewed-by: Chen Wang <unicorn_wang@outlook.com>
Tested-by: Chen Wang <unicorn_wang@outlook.com> on Pioneerbox.
Thanks for your quick action.
Chen
[......]
^ permalink raw reply
* Re: (subset) [PATCH v3 0/3] Add the missing mpll3 clock and clock controller nodes
From: Neil Armstrong @ 2026-04-08 9:09 UTC (permalink / raw)
To: Jerome Brunet, Kevin Hilman, Martin Blumenstingl, Stephen Boyd,
Michael Turquette, robh+dt, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Jian Hu
Cc: devicetree, linux-clk, linux-amlogic, linux-kernel,
linux-arm-kernel, Ronald Claveau, Ferass El Hafidi
In-Reply-To: <20260326092645.1053261-1-jian.hu@amlogic.com>
Hi,
On Thu, 26 Mar 2026 17:26:42 +0800, Jian Hu wrote:
> This series adds the missing mpll3 parent clock and completes the
> Amlogic T7 SoC clock controller DT support.
>
> - Fix redundant hyphen in for gp1 pll
> - Add the missing mpll3 parent clock definition to t7-peripherals-clkc.yaml
> - Add Amlogic T7 SoC clock controller nodes
>
> [...]
Thanks, Applied to https://git.kernel.org/pub/scm/linux/kernel/git/amlogic/linux.git (v7.1/arm64-dt)
[3/3] arm64: dts: amlogic: t7: Add clock controller nodes
https://git.kernel.org/amlogic/c/5f727a999f80a72dae7326577e0d832799ddeaa3
These changes has been applied on the intermediate git tree [1].
The v7.1/arm64-dt branch will then be sent via a formal Pull Request to the Linux SoC maintainers
for inclusion in their intermediate git branches in order to be sent to Linus during
the next merge window, or sooner if it's a set of fixes.
In the cases of fixes, those will be merged in the current release candidate
kernel and as soon they appear on the Linux master branch they will be
backported to the previous Stable and Long-Stable kernels [2].
The intermediate git branches are merged daily in the linux-next tree [3],
people are encouraged testing these pre-release kernels and report issues on the
relevant mailing-lists.
If problems are discovered on those changes, please submit a signed-off-by revert
patch followed by a corrective changeset.
[1] https://git.kernel.org/pub/scm/linux/kernel/git/amlogic/linux.git
[2] https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git
[3] https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git
--
Neil
^ permalink raw reply
* Re: [PATCH 1/2] riscv: dts: sophgo: sg2044: use hex for CPU unit address
From: Chen Wang @ 2026-04-08 9:08 UTC (permalink / raw)
To: Inochi Amaoto, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Paul Walmsley, Palmer Dabbelt, Albert Ou, Alexandre Ghiti,
Han Gao, Nutty Liu, Guodong Xu, Guo Ren, Xiaoguang Xing
Cc: devicetree, linux-riscv, sophgo, linux-kernel, Yixun Lan,
Longbin Li
In-Reply-To: <20260406232655.144043-2-inochiama@gmail.com>
On 4/7/2026 7:26 AM, Inochi Amaoto wrote:
> Previous the CPU unit address cpu of sg2044 use decimal, it is
> not following the general convention for unit addresses of the
> OF. Convent the unit address to hex to resolve this problem.
>
> The introduces a small ABI break for the CPU id, but it should
> affect nothing since there is no direct full-path reference to
> these CPU nodes.
>
> Fixes: 967a94a92aaa ("riscv: dts: add initial Sophgo SG2042 SoC device tree")
> Signed-off-by: Inochi Amaoto <inochiama@gmail.com>
> Link: https://lore.kernel.org/devicetree-spec/00ddad5a-02f5-474e-af9c-11ce7716ddfc@iscas.ac.cn/
Reviewed-by: Chen Wang <unicorn_wang@outlook.com>
Thanks for your quick action.
Chen
[......]
^ permalink raw reply
* Re: [PATCH 1/2] dt-bindings: fpga: add binding for Technologic Systems TS-73xx FPGA
From: Krzysztof Kozlowski @ 2026-04-08 9:08 UTC (permalink / raw)
To: Phil Pemberton
Cc: Moritz Fischer, Xu Yilun, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Tom Rix, Florian Fainelli, linux-fpga, devicetree,
linux-kernel
In-Reply-To: <20260407172730.1779804-2-philpem@philpem.me.uk>
On Tue, Apr 07, 2026 at 06:27:29PM +0100, Phil Pemberton wrote:
> Add device tree binding documentation for the Altera Cyclone II FPGA
> found on Technologic Systems TS-7300 series boards, programmed via a
> CPLD memory-mapped interface.
A nit, subject: drop second/last, redundant "binding for". The
"dt-bindings" prefix is already stating that these are bindings.
See also:
https://elixir.bootlin.com/linux/v6.17-rc3/source/Documentation/devicetree/bindings/submitting-patches.rst#L18
>
> Signed-off-by: Phil Pemberton <philpem@philpem.me.uk>
> ---
> .../fpga/technologic,ts73xx-fpga.yaml | 42 +++++++++++++++++++
> 1 file changed, 42 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/fpga/technologic,ts73xx-fpga.yaml
>
> diff --git a/Documentation/devicetree/bindings/fpga/technologic,ts73xx-fpga.yaml b/Documentation/devicetree/bindings/fpga/technologic,ts73xx-fpga.yaml
> new file mode 100644
> index 000000000000..1f7a651e8f10
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/fpga/technologic,ts73xx-fpga.yaml
> @@ -0,0 +1,42 @@
> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/fpga/technologic,ts73xx-fpga.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: Technologic Systems TS-73xx FPGA Manager
> +
> +maintainers:
> + - Florian Fainelli <f.fainelli@gmail.com>
> +
> +description:
> + FPGA manager for the Altera Cyclone II FPGA on Technologic Systems
> + TS-7300 series boards. The FPGA is programmed via a CPLD interface
> + at a memory-mapped register pair.
> +
> +properties:
> + compatible:
> + const: technologic,ts73xx-fpga
So xx is a wildcard? That's not allowed (see writing bindings or any
talks). You need specific compatible. And compatibility, so fallbacks,
if you have multiple distinctive devices.
> +
> + reg:
> + maxItems: 1
> +
> +required:
> + - compatible
> + - reg
> +
> +additionalProperties: false
> +
> +examples:
> + - |
> + bus {
> + #address-cells = <1>;
> + #size-cells = <1>;
> + ranges;
Drop entire node, not needed.
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH 12/12] arm64: dts: qcom: qcs6490-radxa-dragon-q6a: add LPASS CPU audio variant
From: Konrad Dybcio @ 2026-04-08 9:06 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: <20260407-dragon-q6a-feat-fixes-v1-12-14aca49dde3d@radxa.com>
On 4/7/26 5:20 PM, Xilin Wu wrote:
> Add a qcs6490-radxa-dragon-q6a-lpass-cpu.dts variant for debugging and
> bring-up of the host-controlled LPASS audio path on the Radxa Dragon
> Q6A.
>
> This variant enables the LPASS blocks and codec macros needed by the
> lpass-cpu driver, wires WCD9380 playback/capture and DisplayPort audio
> to the LPASS CDC DMA and DP interfaces, and disables remoteproc_adsp so
> that the audio hardware is owned directly by Linux.
>
> This DTB is an optional configuration for systems booted with the kernel
> running at EL2, where direct CPU access to the LPASS hardware is
> available. It is useful for users who need low-latency and fully
> controllable audio.
I believe on Chrome platforms it was done this way because at some point
it was determined that they would specifically like not to use the DSP.
I think this is more of a hack than anything else.. but at the end of the
commit message you mention low latency - is the impact actually measurable?
Konrad
^ 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