* [PATCH 3/3] pmdomain: qcom: rpmhpd: Add power domains for Nord SoC
From: Shawn Guo @ 2026-04-14 3:59 UTC (permalink / raw)
To: Ulf Hansson
Cc: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Bjorn Andersson,
Konrad Dybcio, Kamal Wadhwa, Taniya Das, Bartosz Golaszewski,
Deepti Jaggi, linux-arm-msm, linux-pm, devicetree, linux-kernel,
Shawn Guo
In-Reply-To: <20260414035909.652992-1-shengchao.guo@oss.qualcomm.com>
From: Kamal Wadhwa <kamal.wadhwa@oss.qualcomm.com>
Add RPMh power domains required for Nord SoC. This includes
new definitions for power domains supplying GFX1 and NSP3 subsystem.
Co-developed-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com>
Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com>
Signed-off-by: Kamal Wadhwa <kamal.wadhwa@oss.qualcomm.com>
Signed-off-by: Shawn Guo <shengchao.guo@oss.qualcomm.com>
---
drivers/pmdomain/qcom/rpmhpd.c | 35 ++++++++++++++++++++++++++++++++++
1 file changed, 35 insertions(+)
diff --git a/drivers/pmdomain/qcom/rpmhpd.c b/drivers/pmdomain/qcom/rpmhpd.c
index ba0cf4694435..63120e703923 100644
--- a/drivers/pmdomain/qcom/rpmhpd.c
+++ b/drivers/pmdomain/qcom/rpmhpd.c
@@ -122,6 +122,11 @@ static struct rpmhpd gfx = {
.res_name = "gfx.lvl",
};
+static struct rpmhpd gfx1 = {
+ .pd = { .name = "gfx1", },
+ .res_name = "gfx1.lvl",
+};
+
static struct rpmhpd lcx = {
.pd = { .name = "lcx", },
.res_name = "lcx.lvl",
@@ -217,6 +222,11 @@ static struct rpmhpd nsp2 = {
.res_name = "nsp2.lvl",
};
+static struct rpmhpd nsp3 = {
+ .pd = { .name = "nsp3", },
+ .res_name = "nsp3.lvl",
+};
+
static struct rpmhpd qphy = {
.pd = { .name = "qphy", },
.res_name = "qphy.lvl",
@@ -308,6 +318,30 @@ static const struct rpmhpd_desc sa8775p_desc = {
.num_pds = ARRAY_SIZE(sa8775p_rpmhpds),
};
+/* Nord RPMH powerdomains */
+static struct rpmhpd *nord_rpmhpds[] = {
+ [RPMHPD_CX] = &cx,
+ [RPMHPD_CX_AO] = &cx_ao,
+ [RPMHPD_EBI] = &ebi,
+ [RPMHPD_GFX] = &gfx,
+ [RPMHPD_GFX1] = &gfx1,
+ [RPMHPD_MX] = &mx,
+ [RPMHPD_MX_AO] = &mx_ao,
+ [RPMHPD_MMCX] = &mmcx,
+ [RPMHPD_MMCX_AO] = &mmcx_ao,
+ [RPMHPD_MXC] = &mxc,
+ [RPMHPD_MXC_AO] = &mxc_ao,
+ [RPMHPD_NSP0] = &nsp0,
+ [RPMHPD_NSP1] = &nsp1,
+ [RPMHPD_NSP2] = &nsp2,
+ [RPMHPD_NSP3] = &nsp3,
+};
+
+static const struct rpmhpd_desc nord_desc = {
+ .rpmhpds = nord_rpmhpds,
+ .num_pds = ARRAY_SIZE(nord_rpmhpds),
+};
+
/* SAR2130P RPMH powerdomains */
static struct rpmhpd *sar2130p_rpmhpds[] = {
[RPMHPD_CX] = &cx,
@@ -856,6 +890,7 @@ static const struct of_device_id rpmhpd_match_table[] = {
{ .compatible = "qcom,hawi-rpmhpd", .data = &hawi_desc },
{ .compatible = "qcom,kaanapali-rpmhpd", .data = &kaanapali_desc },
{ .compatible = "qcom,milos-rpmhpd", .data = &milos_desc },
+ { .compatible = "qcom,nord-rpmhpd", .data = &nord_desc },
{ .compatible = "qcom,qcs615-rpmhpd", .data = &qcs615_desc },
{ .compatible = "qcom,qcs8300-rpmhpd", .data = &qcs8300_desc },
{ .compatible = "qcom,qdu1000-rpmhpd", .data = &qdu1000_desc },
--
2.43.0
^ permalink raw reply related
* [PATCH 2/3] dt-bindings: power: qcom,rpmhpd: Add RPMh power domain for Nord SoC
From: Shawn Guo @ 2026-04-14 3:59 UTC (permalink / raw)
To: Ulf Hansson
Cc: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Bjorn Andersson,
Konrad Dybcio, Kamal Wadhwa, Taniya Das, Bartosz Golaszewski,
Deepti Jaggi, linux-arm-msm, linux-pm, devicetree, linux-kernel,
Shawn Guo
In-Reply-To: <20260414035909.652992-1-shengchao.guo@oss.qualcomm.com>
From: Kamal Wadhwa <kamal.wadhwa@oss.qualcomm.com>
Document the RPMh power domain for Nord SoC, and add definitions for
the new power domains present on Nord SoC.
- RPMHPD_NSP3: power domain for the 4th NSP subsystem
- RPMHPD_GFX1: power domain for the 2nd GFX subsystem
Signed-off-by: Kamal Wadhwa <kamal.wadhwa@oss.qualcomm.com>
Signed-off-by: Shawn Guo <shengchao.guo@oss.qualcomm.com>
---
Documentation/devicetree/bindings/power/qcom,rpmpd.yaml | 1 +
include/dt-bindings/power/qcom,rpmhpd.h | 2 ++
2 files changed, 3 insertions(+)
diff --git a/Documentation/devicetree/bindings/power/qcom,rpmpd.yaml b/Documentation/devicetree/bindings/power/qcom,rpmpd.yaml
index 0bf1e13a9964..779380cc7e44 100644
--- a/Documentation/devicetree/bindings/power/qcom,rpmpd.yaml
+++ b/Documentation/devicetree/bindings/power/qcom,rpmpd.yaml
@@ -35,6 +35,7 @@ properties:
- qcom,msm8994-rpmpd
- qcom,msm8996-rpmpd
- qcom,msm8998-rpmpd
+ - qcom,nord-rpmhpd
- qcom,qcm2290-rpmpd
- qcom,qcs404-rpmpd
- qcom,qcs615-rpmhpd
diff --git a/include/dt-bindings/power/qcom,rpmhpd.h b/include/dt-bindings/power/qcom,rpmhpd.h
index 74e910150956..07bd2a7b0150 100644
--- a/include/dt-bindings/power/qcom,rpmhpd.h
+++ b/include/dt-bindings/power/qcom,rpmhpd.h
@@ -30,6 +30,8 @@
#define RPMHPD_GMXC 20
#define RPMHPD_DCX 21
#define RPMHPD_GBX 22
+#define RPMHPD_NSP3 23
+#define RPMHPD_GFX1 24
/* RPMh Power Domain performance levels */
#define RPMH_REGULATOR_LEVEL_RETENTION 16
--
2.43.0
^ permalink raw reply related
* [PATCH 1/3] dt-bindings: power: qcom,rpmhpd: Fix whitespace in RPMHPD defines
From: Shawn Guo @ 2026-04-14 3:59 UTC (permalink / raw)
To: Ulf Hansson
Cc: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Bjorn Andersson,
Konrad Dybcio, Kamal Wadhwa, Taniya Das, Bartosz Golaszewski,
Deepti Jaggi, linux-arm-msm, linux-pm, devicetree, linux-kernel,
Shawn Guo
In-Reply-To: <20260414035909.652992-1-shengchao.guo@oss.qualcomm.com>
Some RPMHPD_* defines in the Generic RPMH Power Domain Indexes section
were using spaces instead of tabs for alignment. Fix them to be
consistent with the rest of the file.
Signed-off-by: Shawn Guo <shengchao.guo@oss.qualcomm.com>
---
include/dt-bindings/power/qcom,rpmhpd.h | 16 ++++++++--------
1 file changed, 8 insertions(+), 8 deletions(-)
diff --git a/include/dt-bindings/power/qcom,rpmhpd.h b/include/dt-bindings/power/qcom,rpmhpd.h
index 67e2634fdc99..74e910150956 100644
--- a/include/dt-bindings/power/qcom,rpmhpd.h
+++ b/include/dt-bindings/power/qcom,rpmhpd.h
@@ -7,7 +7,7 @@
#define _DT_BINDINGS_POWER_QCOM_RPMHPD_H
/* Generic RPMH Power Domain Indexes */
-#define RPMHPD_CX 0
+#define RPMHPD_CX 0
#define RPMHPD_CX_AO 1
#define RPMHPD_EBI 2
#define RPMHPD_GFX 3
@@ -19,14 +19,14 @@
#define RPMHPD_MX_AO 9
#define RPMHPD_MXC 10
#define RPMHPD_MXC_AO 11
-#define RPMHPD_MSS 12
+#define RPMHPD_MSS 12
#define RPMHPD_NSP 13
-#define RPMHPD_NSP0 14
-#define RPMHPD_NSP1 15
-#define RPMHPD_QPHY 16
-#define RPMHPD_DDR 17
-#define RPMHPD_XO 18
-#define RPMHPD_NSP2 19
+#define RPMHPD_NSP0 14
+#define RPMHPD_NSP1 15
+#define RPMHPD_QPHY 16
+#define RPMHPD_DDR 17
+#define RPMHPD_XO 18
+#define RPMHPD_NSP2 19
#define RPMHPD_GMXC 20
#define RPMHPD_DCX 21
#define RPMHPD_GBX 22
--
2.43.0
^ permalink raw reply related
* [PATCH 0/3] pmdomain: qcom: rpmhpd: Add power domains for Nord SoC
From: Shawn Guo @ 2026-04-14 3:59 UTC (permalink / raw)
To: Ulf Hansson
Cc: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Bjorn Andersson,
Konrad Dybcio, Kamal Wadhwa, Taniya Das, Bartosz Golaszewski,
Deepti Jaggi, linux-arm-msm, linux-pm, devicetree, linux-kernel,
Shawn Guo
This series adds RPMh power domain support for the Qualcomm Nord SoC.
The Nord SoC introduces two new power domains beyond the existing set: GFX1
for the second GFX subsystem and NSP3 for the fourth NSP subsystem. Patch 1
is a preparatory cleanup that fixes inconsistent whitespace in the RPMHPD
define block before the new entries are added. Patches 2-3 add the DT
bindings and driver support for Nord respectively.
Kamal Wadhwa (2):
dt-bindings: power: qcom,rpmhpd: Add RPMh power domain for Nord SoC
pmdomain: qcom: rpmhpd: Add power domains for Nord SoC
Shawn Guo (1):
dt-bindings: power: qcom,rpmhpd: Fix whitespace in RPMHPD defines
.../devicetree/bindings/power/qcom,rpmpd.yaml | 1 +
drivers/pmdomain/qcom/rpmhpd.c | 35 +++++++++++++++++++
include/dt-bindings/power/qcom,rpmhpd.h | 18 +++++-----
3 files changed, 46 insertions(+), 8 deletions(-)
--
2.43.0
^ permalink raw reply
* [PATCH v4] ASoC: dt-bindings: ti,pcm3060: add descriptions and rename binding
From: Padmashree S S @ 2026-04-14 3:48 UTC (permalink / raw)
To: k.marinushkin, lgirdwood
Cc: broonie, robh, krzk+dt, conor+dt, linux-sound, devicetree,
linux-kernel, padmashreess2006
In-Reply-To: <20260327121919.603768-1-padmashreess2006@gmail.com>
Add description to reg property and overall binding mentioning that this
driver supports both I2C and SPI. Rename binding to match compatible
naming convention.
Signed-off-by: Padmashree S S <padmashreess2006@gmail.com>
---
Changes in v4:
- Rename binding from pcm3060 to ti,pcm3060
- Add binding description
- Add description to 'reg' property
- Remove unused label in example
Changes in v3:
- Remove description from 'reg' property
---
.../bindings/sound/{pcm3060.yaml => ti,pcm3060.yaml} | 10 +++++-----
1 file changed, 5 insertions(+), 5 deletions(-)
rename Documentation/devicetree/bindings/sound/{pcm3060.yaml => ti,pcm3060.yaml} (74%)
diff --git a/Documentation/devicetree/bindings/sound/pcm3060.yaml b/Documentation/devicetree/bindings/sound/ti,pcm3060.yaml
similarity index 74%
rename from Documentation/devicetree/bindings/sound/pcm3060.yaml
rename to Documentation/devicetree/bindings/sound/ti,pcm3060.yaml
index ceb6f044b196..5a402d8b7daa 100644
--- a/Documentation/devicetree/bindings/sound/pcm3060.yaml
+++ b/Documentation/devicetree/bindings/sound/ti,pcm3060.yaml
@@ -1,11 +1,13 @@
# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
%YAML 1.2
---
-$id: http://devicetree.org/schemas/sound/pcm3060.yaml#
+$id: http://devicetree.org/schemas/sound/ti,pcm3060.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
title: PCM3060 audio CODEC
+description: This driver supports both I2C and SPI.
+
maintainers:
- Kirill Marinushkin <k.marinushkin@gmail.com>
@@ -21,9 +23,7 @@ properties:
ti,out-single-ended:
type: boolean
- description: |
- If present, the output is single-ended.
- If absent, the output is differential.
+ description: If present, the output is single-ended. If absent, the output is differential.
required:
- compatible
@@ -37,7 +37,7 @@ examples:
#address-cells = <1>;
#size-cells = <0>;
- pcm3060: audio-codec@46 {
+ audio-codec@46 {
compatible = "ti,pcm3060";
reg = <0x46>;
ti,out-single-ended;
--
2.43.0
^ permalink raw reply related
* Re: [PATCH v2 1/4] riscv: add UltraRISC SoC family Kconfig support
From: Jia Wang @ 2026-04-14 3:27 UTC (permalink / raw)
To: Conor Dooley
Cc: Jia Wang, Paul Walmsley, Palmer Dabbelt, Albert Ou,
Alexandre Ghiti, Lorenzo Pieralisi, Krzysztof Wilczyński,
Manivannan Sadhasivam, Rob Herring, Bjorn Helgaas, Jingoo Han,
Xincheng Zhang, Krzysztof Kozlowski, Conor Dooley, linux-riscv,
linux-kernel, linux-pci, devicetree
In-Reply-To: <20260408-wise-dividers-ec8a057d4bd2@spud>
On 2026-04-08 18:10 +0100, Conor Dooley wrote:
> On Wed, Apr 08, 2026 at 09:47:04AM +0800, Jia Wang wrote:
> > On 2026-04-07 17:29 +0100, Conor Dooley wrote:
> > > On Tue, Apr 07, 2026 at 10:40:52AM +0800, Jia Wang wrote:
> > > > The first SoC in the UltraRISC series is UR-DP1000, containing octa
> > > > UltraRISC C100 cores.
> > >
> > > Not gonna lie, I find it odd that pcie is where this platform starts
> > > off, but sure. What's the plan for adding the rest of the platform?
> > >
> >
> > Hi Conor,
> >
> > Thanks for the question.
> >
> > Our next step is to upstream the pinctrl driver together with the related
> > DTS updates. The pinctrl series only affects the SoC’s low-speed peripheral
> > interfaces. For GMAC, SPI, I2C, and GPIO, we plan to use the existing
> > kernel drivers, so no new controller drivers are needed
>
> And clocks? pinctrl and clocks would be the bare minimum level of
> support required before a platform should be merged. Obviously, you can
> get device drivers for PCI etc etc merged without clock drivers, but the
> initial dts should contain the clocks too.
>
On our platform, all functional clocks are fully configured and enabled by
the firmware before Linux boots. The kernel is not expected to adjust clock
rates or gate/ungate clocks at runtime.
Therefore, in the initial device tree we only describe the fixed clocks
required by the standard subsystem drivers, using `fixed-clock` where needed.
Since there is no clock controller accessible to the OS, we do not plan to
add a clock driver at this stage. If future hardware versions expose a
programmable clock controller to Linux, we will upstream the corresponding
driver and update the DT accordingly.
> > > >
> > > > Signed-off-by: Jia Wang <wangjia@ultrarisc.com>
> > > > ---
> > > > arch/riscv/Kconfig.socs | 9 +++++++++
> > > > 1 file changed, 9 insertions(+)
> > > >
> > > > diff --git a/arch/riscv/Kconfig.socs b/arch/riscv/Kconfig.socs
> > > > index d621b85dd63b..98708569ec6a 100644
> > > > --- a/arch/riscv/Kconfig.socs
> > > > +++ b/arch/riscv/Kconfig.socs
> > > > @@ -84,6 +84,15 @@ config ARCH_THEAD
> > > > help
> > > > This enables support for the RISC-V based T-HEAD SoCs.
> > > >
> > > > +config ARCH_ULTRARISC
> > > > + bool "UltraRISC RISC-V SoCs"
> > > > + help
> > > > + This enables support for UltraRISC SoC platform hardware,
> > > > + including boards based on the UR-DP1000.
> > >
> > > > + UR-DP1000 is an 8-core 64-bit RISC-V SoC that supports
> > > > + the RV64GCBHX ISA. It supports Hardware Virtualization
> > > > + and RISC-V RV64 ISA H(v1.0) Extension.
> > >
> > > Delete this section IMO, doesn't provide any real value. Don't need nor
> > > want the marketing brochure in the help text. The first sentence is
> > > sufficient.
> > >
> >
> > I’ll drop the SoC description part from the Kconfig help text as you
> > suggested.
> >
> > > > +
> > > > config ARCH_VIRT
> > > > bool "QEMU Virt Machine"
> > > > select POWER_RESET
> > > >
> > > > --
> > > > 2.34.1
> > > >
> >
> > Best regards,
> > Jia Wang
> >
^ permalink raw reply
* Re: [PATCH v7 0/2] arm64: dts/defconfig: enable BST C1200 eMMC
From: Albert Yang @ 2026-04-14 3:10 UTC (permalink / raw)
To: Gordon Ge
Cc: Albert Yang, krzk, arnd, krzk+dt, robh, conor+dt, bst-upstream,
linux-arm-kernel, devicetree, linux-kernel
In-Reply-To: <20260310091211.4171307-1-yangzh0906@thundersoft.com>
Hi Gordon,
Could you please help with:
1) Reviewing the remaining 2 patches in this series.
If acceptable, please reply with an Acked-by on each patch below:
- [PATCH v7 1/2] arm64: dts: bst: enable eMMC controller in C1200 CDCU1.0 board
- [PATCH v7 2/2] arm64: defconfig: enable BST SDHCI controller
I will carry your tags in the next revision.
Thanks,
Albert
^ permalink raw reply
* Re: Re: [PATCH v3 1/2] dt-bindings: pwm: dwc: add reset optional
From: Xuyang Dong @ 2026-04-14 2:52 UTC (permalink / raw)
To: Krzysztof Kozlowski
Cc: ukleinek, robh, krzk+dt, conor+dt, ben-linux, ben.dooks, p.zabel,
linux-pwm, devicetree, linux-kernel, ningyu, linmin, xuxiang,
wangguosheng, pinkesh.vaghela
In-Reply-To: <20260403-glossy-industrious-pug-4f2b2c@quoll>
> >
> > The DesignWare PWM controller provides separate reset signals for each
>
> So one controller has signals. Plural, right? Then why do you define
> only one reset signal?
>
Hi Krzysztof,
There are two reset signals matching the two clocks, so maxItems is set to 2.
> > clock domain, as specified in the hardware documentation. Without
> > asserting and deasserting these resets during probe, PWM outputs may
> > remain in an undefined state after system reboot.
> >
> > To address this, the driver now supports an optional 'resets' property.
>
> This is binding change, not driver.
>
> > A full reset is performed only when no PWM channel is enabled, as
> > determined by reading the enable bit in each channel's control register.
>
> Do you describe hardware or driver behavior? This is not a change about
> driver. Describe the hardware here - what is expected with that reset.
>
> > This allows safe coexistence with bootloaders that have already
> > configured active PWM channels.
>
The improvement commit message for the next version will be revised
as follows:
The DesignWare PWM includes separate reset signals dedicated to each clock
domain:
The presetn signal resets logic in pclk domain.
The timer_N_resetn signal resets logic in the timer_N_clk domain.
The resets are active-low.
In the next version, we will address the changes as described above.
Best regards,
Xuyang Dong
^ permalink raw reply
* Re: [PATCH v2 2/2] usb: dwc3: starfive: Add JHB100 USB 2.0 DRD controller
From: Thinh Nguyen @ 2026-04-14 0:59 UTC (permalink / raw)
To: Minda Chen
Cc: Greg Kroah-Hartman, Thinh Nguyen, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, linux-usb@vger.kernel.org,
linux-kernel@vger.kernel.org, devicetree@vger.kernel.org
In-Reply-To: <20260410112500.90432-3-minda.chen@starfivetech.com>
On Fri, Apr 10, 2026, Minda Chen wrote:
> JHB100 contains 2 dwc3 USB controllers and PHYs and working
> as USB 2.0 speed. It can working in generic platform and
> setting default properties.
>
> Signed-off-by: Minda Chen <minda.chen@starfivetech.com>
> ---
> drivers/usb/dwc3/dwc3-generic-plat.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/drivers/usb/dwc3/dwc3-generic-plat.c b/drivers/usb/dwc3/dwc3-generic-plat.c
> index e846844e0023..e9e29b63aaa4 100644
> --- a/drivers/usb/dwc3/dwc3-generic-plat.c
> +++ b/drivers/usb/dwc3/dwc3-generic-plat.c
> @@ -214,6 +214,7 @@ static const struct of_device_id dwc3_generic_of_match[] = {
> { .compatible = "spacemit,k1-dwc3", },
> { .compatible = "fsl,ls1028a-dwc3", &fsl_ls1028_dwc3},
> { .compatible = "eswin,eic7700-dwc3", &eic7700_dwc3},
> + { .compatible = "starfive,jhb100-dwc3", },
> { /* sentinel */ }
> };
> MODULE_DEVICE_TABLE(of, dwc3_generic_of_match);
> --
> 2.17.1
>
Acked-by: Thinh Nguyen <Thinh.Nguyen@synopsys.com>
BR,
Thinh
^ permalink raw reply
* Re: Re: [PATCH 2/3] clk: eswin: Add eic7700 HSP clock driver
From: Xuyang Dong @ 2026-04-14 2:36 UTC (permalink / raw)
To: Brian Masney
Cc: mturquette, sboyd, robh, krzk+dt, conor+dt, linux-clk, devicetree,
linux-kernel, p.zabel, huangyifeng, ningyu, linmin,
pinkesh.vaghela
In-Reply-To: <ac_H7kSCgzz5HRxV@redhat.com>
> > +
> > +static struct clk_parent_data hsp_usb_sata[] = {
> > + { .fw_name = "hsp_sata" }
> > +};
> > +
> > +static struct eswin_fixed_factor_clock eic7700_hsp_factor_clks[] = {
>
> More places for static const? I'll leave out the others.
>
Hi Brian,
When registering a clock, the 'hw' field in the structure will be assigned,
so these clock structures cannot be declared const.
Other comments will be fixed in the next version.
Best regards,
Xuyang Dong
> > + ESWIN_FACTOR(EIC7700_HSP_CLK_FAC_CFG_DIV2, "factor_hsp_cfg_div2",
> > + hsp_cfg, 1, 2, 0),
> > + ESWIN_FACTOR(EIC7700_HSP_CLK_FAC_CFG_DIV4, "factor_hsp_cfg_div4",
> > + hsp_cfg, 1, 4, 0),
> > + ESWIN_FACTOR(EIC7700_HSP_CLK_FAC_MMC_DIV10, "factor_hsp_mmc_div10",
> > + hsp_mmc, 1, 10, 0),
> > +};
> > +
> > +static struct eswin_gate_clock eic7700_hsp_gate_clks[] = {
> > + ESWIN_GATE(EIC7700_HSP_CLK_GATE_SATA, "gate_clk_hsp_sata", hsp_usb_sata,
> > + CLK_SET_RATE_PARENT, EIC7700_HSP_SATA_REG, 28, 0),
> > + ESWIN_GATE(EIC7700_HSP_CLK_GATE_MSHC0_TMR, "gate_clk_hsp_mshc0_tmr",
> > + hsp_mmc, CLK_SET_RATE_PARENT, EIC7700_HSP_MSHC0_REG, 8, 0),
> > + ESWIN_GATE(EIC7700_HSP_CLK_GATE_MSHC1_TMR, "gate_clk_hsp_mshc1_tmr",
> > + hsp_mmc, CLK_SET_RATE_PARENT, EIC7700_HSP_MSHC1_REG, 8, 0),
> > + ESWIN_GATE(EIC7700_HSP_CLK_GATE_MSHC2_TMR, "gate_clk_hsp_mshc2_tmr",
> > + hsp_mmc, CLK_SET_RATE_PARENT, EIC7700_HSP_MSHC2_REG, 8, 0),
> > +};
> > +
> > +static struct eic7700_hsp_clk_gate eic7700_hsp_spec_gate_clks[] = {
> > + EIC7700_HSP_GATE(EIC7700_HSP_CLK_GATE_USB0, "gate_clk_hsp_usb0",
> > + hsp_usb_sata, CLK_SET_RATE_PARENT,
> > + EIC7700_HSP_USB0_REG, 28, EIC7700_HSP_USB0_REF_REG),
> > + EIC7700_HSP_GATE(EIC7700_HSP_CLK_GATE_USB1, "gate_clk_hsp_usb1",
> > + hsp_usb_sata, CLK_SET_RATE_PARENT,
> > + EIC7700_HSP_USB1_REG, 28, EIC7700_HSP_USB1_REF_REG),
> > +};
> > +
> > +static const struct clk_parent_data mux_mmc_3mux1_p[] = {
> > + { .fw_name = "hsp_cfg" },
> > + { .hw = &eic7700_hsp_factor_clks[0].hw },
> > + { .hw = &eic7700_hsp_factor_clks[1].hw },
> > +};
> > +
> > +static const struct clk_parent_data mux_mmc_2mux1_p[] = {
> > + { .fw_name = "hsp_mmc" },
> > + { .hw = &eic7700_hsp_factor_clks[2].hw },
> > +};
> > +
> > +static u32 mux_mmc_3mux1_tbl[] = { 0x0, 0x1, 0x3 };
> > +
> > +static struct eswin_mux_clock eic7700_hsp_mux_clks[] = {
> > + ESWIN_MUX_TBL(EIC7700_HSP_CLK_MUX_EMMC_3MUX1, "mux_hsp_emmc_3mux1",
> > + mux_mmc_3mux1_p, ARRAY_SIZE(mux_mmc_3mux1_p),
> > + CLK_SET_RATE_PARENT, EIC7700_HSP_MSHC0_REG, 16, 2, 0,
> > + mux_mmc_3mux1_tbl),
> > + ESWIN_MUX_TBL(EIC7700_HSP_CLK_MUX_SD0_3MUX1, "mux_hsp_sd0_3mux1",
> > + mux_mmc_3mux1_p, ARRAY_SIZE(mux_mmc_3mux1_p),
> > + CLK_SET_RATE_PARENT, EIC7700_HSP_MSHC1_REG, 16, 2, 0,
> > + mux_mmc_3mux1_tbl),
> > + ESWIN_MUX_TBL(EIC7700_HSP_CLK_MUX_SD1_3MUX1, "mux_hsp_sd1_3mux1",
> > + mux_mmc_3mux1_p, ARRAY_SIZE(mux_mmc_3mux1_p),
> > + CLK_SET_RATE_PARENT, EIC7700_HSP_MSHC2_REG, 16, 2, 0,
> > + mux_mmc_3mux1_tbl),
> > + ESWIN_MUX(EIC7700_HSP_CLK_MUX_EMMC_CQE_2MUX1, "mux_hsp_emmc_cqe_2mux1",
> > + mux_mmc_2mux1_p, ARRAY_SIZE(mux_mmc_2mux1_p),
> > + CLK_SET_RATE_PARENT, EIC7700_HSP_MSHC0_REG, 0, 1, 0),
> > + ESWIN_MUX(EIC7700_HSP_CLK_MUX_SD0_CQE_2MUX1, "mux_hsp_sd0_cqe_2mux1",
> > + mux_mmc_2mux1_p, ARRAY_SIZE(mux_mmc_2mux1_p),
> > + CLK_SET_RATE_PARENT, EIC7700_HSP_MSHC1_REG, 0, 1, 0),
> > + ESWIN_MUX(EIC7700_HSP_CLK_MUX_SD1_CQE_2MUX1, "mux_hsp_sd1_cqe_2mux1",
> > + mux_mmc_2mux1_p, ARRAY_SIZE(mux_mmc_2mux1_p),
> > + CLK_SET_RATE_PARENT, EIC7700_HSP_MSHC2_REG, 0, 1, 0),
> > +};
> > +
> > +static struct eswin_clk_info eic7700_hsp_clks[] = {
> > + ESWIN_GATE_TYPE(EIC7700_HSP_CLK_GATE_EMMC, "gate_clk_hsp_emmc",
> > + EIC7700_HSP_CLK_MUX_EMMC_3MUX1,
> > + CLK_SET_RATE_PARENT | CLK_IGNORE_UNUSED,
> > + EIC7700_HSP_MSHC0_REG, 24, 0),
> > + ESWIN_GATE_TYPE(EIC7700_HSP_CLK_GATE_SD0, "gate_clk_hsp_sd0",
> > + EIC7700_HSP_CLK_MUX_SD0_3MUX1,
> > + CLK_SET_RATE_PARENT | CLK_IGNORE_UNUSED,
> > + EIC7700_HSP_MSHC1_REG, 24, 0),
> > + ESWIN_GATE_TYPE(EIC7700_HSP_CLK_GATE_SD1, "gate_clk_hsp_sd1",
> > + EIC7700_HSP_CLK_MUX_SD1_3MUX1,
> > + CLK_SET_RATE_PARENT | CLK_IGNORE_UNUSED,
> > + EIC7700_HSP_MSHC2_REG, 24, 0),
> > +};
> > +
> > +static int eic7700_hsp_clk_probe(struct platform_device *pdev)
> > +{
> > + struct device *dev = &pdev->dev;
> > + struct auxiliary_device *adev;
> > + struct eswin_clock_data *data;
> > + struct clk_hw *hw;
> > + int i, ret;
> > +
> > + data = eswin_clk_init(pdev, EIC7700_HSP_NR_CLKS);
> > + if (IS_ERR(data))
> > + return dev_err_probe(dev, PTR_ERR(data),
> > + "failed to get clk data!\n");
> > +
> > + ret = eswin_clk_register_fixed_factor
> > + (dev, eic7700_hsp_factor_clks,
> > + ARRAY_SIZE(eic7700_hsp_factor_clks), data);
>
> The first two lines can be combined together to improve the formatting:
>
> ret = eswin_clk_register_fixed_factor(dev, eic7700_hsp_factor_clks,
>
> > + if (ret)
> > + return dev_err_probe(dev, ret,
> > + "failed to register fixed factor clock\n");
> > +
> > + ret = eswin_clk_register_gate(dev, eic7700_hsp_gate_clks,
> > + ARRAY_SIZE(eic7700_hsp_gate_clks), data);
> > + if (ret)
> > + return dev_err_probe(dev, ret,
> > + "failed to register gate clock\n");
> > +
> > + ret = eswin_clk_register_mux(dev, eic7700_hsp_mux_clks,
> > + ARRAY_SIZE(eic7700_hsp_mux_clks),
> > + data);
> > + if (ret)
> > + return dev_err_probe(dev, ret,
> > + "failed to register mux clock\n");
> > +
> > + ret = eswin_clk_register_clks(dev, eic7700_hsp_clks,
> > + ARRAY_SIZE(eic7700_hsp_clks), data);
> > + if (ret)
> > + return dev_err_probe(dev, ret,
> > + "failed to register clock\n");
> > +
> > + for (i = 0; i < ARRAY_SIZE(eic7700_hsp_spec_gate_clks); i++) {
> > + struct eic7700_hsp_clk_gate *gate;
> > +
> > + gate = &eic7700_hsp_spec_gate_clks[i];
> > + hw = hsp_clk_register_gate(dev, gate->id, gate->name,
> > + gate->parent_data, gate->flags,
> > + data->base + gate->offset,
> > + data->base + gate->ref_offset,
> > + gate->bit_idx, 0, &data->lock);
> > + if (IS_ERR(hw))
> > + return dev_err_probe(dev, PTR_ERR(hw),
> > + "failed to register gate clock\n");
> > +
> > + data->clk_data.hws[gate->id] = hw;
> > + }
> > +
> > + ret = devm_of_clk_add_hw_provider(dev, of_clk_hw_onecell_get,
> > + &data->clk_data);
> > + if (ret)
> > + return dev_err_probe(dev, ret, "add clk provider failed\n");
> > +
> > + adev = devm_auxiliary_device_create(dev, "hsp-reset",
> > + (__force void *)data->base);
>
> So this driver is sharing the same register space with the reset driver,
> and the reset driver calls devm_regmap_init_mmio(). What do you think
> about having a shared regmap between the two drivers so that the __force
> is not needed?
>
> Brian
>
>
> > + if (!adev)
> > + return dev_err_probe(dev, -ENODEV,
> > + "register hsp-reset device failed\n");
> > +
> > + return 0;
> > +}
> > +
> > +static const struct of_device_id eic7700_hsp_clock_dt_ids[] = {
> > + { .compatible = "eswin,eic7700-hspcrg", },
> > + { /* sentinel */ }
> > +};
> > +MODULE_DEVICE_TABLE(of, eic7700_hsp_clock_dt_ids);
> > +
> > +static struct platform_driver eic7700_hsp_clock_driver = {
> > + .probe = eic7700_hsp_clk_probe,
> > + .driver = {
> > + .name = "eic7700-hsp-clock",
> > + .of_match_table = eic7700_hsp_clock_dt_ids,
> > + },
> > +};
> > +
> > +module_platform_driver(eic7700_hsp_clock_driver);
> > +
> > +MODULE_LICENSE("GPL");
> > +MODULE_AUTHOR("Xuyang Dong <dongxuyang@eswincomputing.com>");
> > +MODULE_DESCRIPTION("ESWIN EIC7700 HSP clock controller driver");
> > --
> > 2.34.1
> >
^ permalink raw reply
* Re: [PATCH v2] dt-bindings: arm: marvell: Convert armada-380-mpcore-soc-ctrl to DT Schema
From: Padmashree S S @ 2026-04-14 2:13 UTC (permalink / raw)
To: Rob Herring
Cc: andrew, gregory.clement, sebastian.hesselbarth, krzk+dt, conor+dt,
linux-arm-kernel, devicetree, linux-kernel
In-Reply-To: <20260407184455.GA3369046-robh@kernel.org>
On Wed, Apr 8, 2026 at 12:14 AM Rob Herring <robh@kernel.org> wrote:
>
> On Fri, Mar 27, 2026 at 05:16:53PM +0530, Padmashree S S wrote:
> > Convert armada-380-mpcore-soc-ctrl to DT schema
> >
> > Signed-off-by: Padmashree S S <padmashreess2006@gmail.com>
> > ---
> > .../marvell/armada-380-mpcore-soc-ctrl.txt | 14 --------
> > .../marvell/armada-380-mpcore-soc-ctrl.yaml | 32 +++++++++++++++++++
> > 2 files changed, 32 insertions(+), 14 deletions(-)
> > delete mode 100644 Documentation/devicetree/bindings/arm/marvell/armada-380-mpcore-soc-ctrl.txt
> > create mode 100644 Documentation/devicetree/bindings/arm/marvell/armada-380-mpcore-soc-ctrl.yaml
>
> Please move this to
> bindings/soc/marvell/marvell,armada-380-mpcore-soc-ctrl.yaml
>
> Don't forget to update the '$id' value.
>
> Rob
Thank you for the review, I'll move the binding and change the $id in
the next version of this patch.
^ permalink raw reply
* [PATCH v2 2/2] ASoC: tas2781: Add tas5832 support
From: Baojun Xu @ 2026-04-14 1:54 UTC (permalink / raw)
To: broonie, tiwai
Cc: andriy.shevchenko, 13916275206, shenghao-ding, baojun.xu,
linux-sound, linux-kernel, lgirdwood, robh, krzk+dt, conor+dt,
devicetree, k-yi, henry.lo, robinchen, will-wang, jim.shil,
toastcheng, chinkaiting
In-Reply-To: <20260414015441.2439-1-baojun.xu@ti.com>
TAS5832 is in same family with TAS5827/28/30.
Signed-off-by: Baojun Xu <baojun.xu@ti.com>
---
v2:
- Follow the updated association protocol based on device name and id.
---
include/sound/tas2781.h | 1 +
sound/soc/codecs/tas2781-i2c.c | 5 +++++
2 files changed, 6 insertions(+)
diff --git a/include/sound/tas2781.h b/include/sound/tas2781.h
index e847cf51878c..95296bb4a33a 100644
--- a/include/sound/tas2781.h
+++ b/include/sound/tas2781.h
@@ -131,6 +131,7 @@ enum audio_device {
TAS5827,
TAS5828,
TAS5830,
+ TAS5832,
TAS_OTHERS,
};
diff --git a/sound/soc/codecs/tas2781-i2c.c b/sound/soc/codecs/tas2781-i2c.c
index c593f9da0c5b..86b591c489c2 100644
--- a/sound/soc/codecs/tas2781-i2c.c
+++ b/sound/soc/codecs/tas2781-i2c.c
@@ -119,6 +119,7 @@ static const struct i2c_device_id tasdevice_id[] = {
{ "tas5827", TAS5827 },
{ "tas5828", TAS5828 },
{ "tas5830", TAS5830 },
+ { "tas5832", TAS5832 },
{}
};
@@ -143,6 +144,7 @@ static const struct of_device_id tasdevice_of_match[] = {
{ .compatible = "ti,tas5827", .data = &tasdevice_id[TAS5827] },
{ .compatible = "ti,tas5828", .data = &tasdevice_id[TAS5828] },
{ .compatible = "ti,tas5830", .data = &tasdevice_id[TAS5830] },
+ { .compatible = "ti,tas5832", .data = &tasdevice_id[TAS5832] },
{},
};
MODULE_DEVICE_TABLE(of, tasdevice_of_match);
@@ -1746,6 +1748,7 @@ static void tasdevice_fw_ready(const struct firmware *fmw,
case TAS5827:
case TAS5828:
case TAS5830:
+ case TAS5832:
/* If DSP FW fail, DSP kcontrol won't be created. */
tasdevice_dsp_remove(tas_priv);
}
@@ -1917,6 +1920,7 @@ static int tasdevice_codec_probe(struct snd_soc_component *codec)
case TAS5827:
case TAS5828:
case TAS5830:
+ case TAS5832:
p = (struct snd_kcontrol_new *)tas5825_snd_controls;
size = ARRAY_SIZE(tas5825_snd_controls);
break;
@@ -2104,6 +2108,7 @@ static const struct acpi_device_id tasdevice_acpi_match[] = {
{ "TXNW5827", (kernel_ulong_t)&tasdevice_id[TAS5827] },
{ "TXNW5828", (kernel_ulong_t)&tasdevice_id[TAS5828] },
{ "TXNW5830", (kernel_ulong_t)&tasdevice_id[TAS5830] },
+ { "TXNW5832", (kernel_ulong_t)&tasdevice_id[TAS5832] },
{},
};
--
2.25.1
^ permalink raw reply related
* [PATCH v2 1/2] ASoC: dt-bindings: ti,tas2781: Add TAS5832 support
From: Baojun Xu @ 2026-04-14 1:54 UTC (permalink / raw)
To: broonie, tiwai
Cc: andriy.shevchenko, 13916275206, shenghao-ding, baojun.xu,
linux-sound, linux-kernel, lgirdwood, robh, krzk+dt, conor+dt,
devicetree, k-yi, henry.lo, robinchen, will-wang, jim.shil,
toastcheng, chinkaiting
TAS5832 is in same family with TAS5827/28/30.
Signed-off-by: Baojun Xu <baojun.xu@ti.com>
---
v2:
- No update.
---
Documentation/devicetree/bindings/sound/ti,tas2781.yaml | 7 ++++++-
1 file changed, 6 insertions(+), 1 deletion(-)
diff --git a/Documentation/devicetree/bindings/sound/ti,tas2781.yaml b/Documentation/devicetree/bindings/sound/ti,tas2781.yaml
index f3a5638f4239..b21466bb0730 100644
--- a/Documentation/devicetree/bindings/sound/ti,tas2781.yaml
+++ b/Documentation/devicetree/bindings/sound/ti,tas2781.yaml
@@ -1,5 +1,5 @@
# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
-# Copyright (C) 2022 - 2025 Texas Instruments Incorporated
+# Copyright (C) 2022 - 2026 Texas Instruments Incorporated
%YAML 1.2
---
$id: http://devicetree.org/schemas/sound/ti,tas2781.yaml#
@@ -107,6 +107,9 @@ properties:
ti,tas5830: 65-W Stereo, Digital Input, High Efficiency Closed-Loop
Class-D Amplifier with Class-H Algorithm
+
+ ti,tas5832: 81-W Stereo, Digital Input, High Efficiency Closed-Loop
+ Class-D Amplifier with Class-H Algorithm
oneOf:
- items:
- enum:
@@ -128,6 +131,7 @@ properties:
- ti,tas5827
- ti,tas5828
- ti,tas5830
+ - ti,tas5832
- const: ti,tas2781
- enum:
- ti,tas2781
@@ -264,6 +268,7 @@ allOf:
- ti,tas5827
- ti,tas5828
- ti,tas5830
+ - ti,tas5832
then:
properties:
reg:
--
2.25.1
^ permalink raw reply related
* Re: [PATCH 2/2] dt-bindings: arm: cpus: Add compatible qcom,oryon-1-5
From: Shawn Guo @ 2026-04-14 1:21 UTC (permalink / raw)
To: Krzysztof Kozlowski
Cc: Bjorn Andersson, Konrad Dybcio, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Bartosz Golaszewski, Deepti Jaggi, linux-arm-msm,
devicetree, linux-kernel
In-Reply-To: <d671229f-1c9f-470f-b1d1-7d015c0721e8@kernel.org>
On Mon, Apr 13, 2026 at 06:08:49PM +0200, Krzysztof Kozlowski wrote:
> On 13/04/2026 16:34, Shawn Guo wrote:
> > In short, there will be Nord DTS using the binding coming, and I do not
>
> Maybe there will, maybe there will not.
>
> > think posting them at the same time should be a requirement.
>
> Well, it is a requirement as I explained previously, said that
> *multiple* times on the mailing list, documented expectations in
> mentioned/linked email threads.
To be honest, I can only read the following from mentioned email
threads.
- Binding and DTS should be organized in separate series per subsystem
- DTS should reference binding series by a lore link
These are what I'm trying to do, and I'm not just posting DTS
simultaneously. I do not really read the requirement of posting
binding and DTS using it simultaneously from the email threads.
Taking a step back, even if the requirement is mentioned in an email
thread like this one, I'm not sure it's the correct or well received
way to define a requirement. And that might be why you had to keep
repeating yourself.
> It's also documented in submitting
> patches in DT (although not with that strong wording).
Either I'm blind or reading the wrong document. I failed to find
the requirement of posting binding and DTS using it simultaneously
in Documentation/devicetree/bindings/submitting-patches.rst. Could you
point it out explicitly?
Shawn
^ permalink raw reply
* Re: [PATCH v1 1/2] dt-bindings: usb: dwc3: add support for StarFive JHB100
From: Thinh Nguyen @ 2026-04-14 1:00 UTC (permalink / raw)
To: Minda Chen
Cc: Conor Dooley, Greg Kroah-Hartman, Thinh Nguyen, Rob Herring,
Krzysztof Kozlowski, linux-usb@vger.kernel.org,
linux-kernel@vger.kernel.org, devicetree@vger.kernel.org
In-Reply-To: <SHXPR01MB08631832A55ABCB54FE77273E6592@SHXPR01MB0863.CHNPR01.prod.partner.outlook.cn>
On Fri, Apr 10, 2026, Minda Chen wrote:
> Hi Thinh
> Could you review patch2? Just add a compatible to generic platform driver. Thanks
>
Done.
BR,
Thinh
^ permalink raw reply
* Re: [PATCH v2 4/6] ASoC: renesas: fsi: refactor clock initialization
From: Kuninori Morimoto @ 2026-04-14 0:51 UTC (permalink / raw)
To: phucduc.bui
Cc: broonie, lgirdwood, robh, krzk+dt, conor+dt, geert+renesas,
magnus.damm, perex, tiwai, linux-sound, linux-renesas-soc,
devicetree, linux-kernel
In-Reply-To: <20260413100700.30995-5-phucduc.bui@gmail.com>
Hi
> 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>
> ---
(snip)
> -/*
> - * 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))
I have mentioned in previous mail to just move fsi_clk_init(), but why do
you need to move it ? It works without any issue without moving function,
I guess ?
This patch 1) moves fsi_clk_init() 2) and update it. So there are too many
diffs. Difficult to review.
Note is that the comment /* clock function */ is not only for fsi_clk_init()
but for all fsi_clk_xxx() functions. Here is that position.
> @@ -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);
> - }
You removes fsi_is_clk_master() check in new fsi_clk_init() ?
> @@ -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");
Why don't use fsi->clk_cpg ? And why you need to call fsi_clk_init() twice ?
Thank you for your help !!
Best regards
---
Kuninori Morimoto
^ permalink raw reply
* Re: [PATCH v2 3/6] ASoC: renesas: fsi: Fix trigger stop ordering
From: Kuninori Morimoto @ 2026-04-14 0:28 UTC (permalink / raw)
To: phucduc.bui
Cc: broonie, lgirdwood, robh, krzk+dt, conor+dt, geert+renesas,
magnus.damm, perex, tiwai, linux-sound, linux-renesas-soc,
devicetree, linux-kernel
In-Reply-To: <20260413100700.30995-4-phucduc.bui@gmail.com>
Hi
> 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>
> ---
This patch should appearing much earlier.
> 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
* Re: [PATCH v2 2/6] ASoC: renesas: fsi: Fix hang by enabling SPU clock
From: Kuninori Morimoto @ 2026-04-14 0:27 UTC (permalink / raw)
To: phucduc.bui
Cc: broonie, lgirdwood, robh, krzk+dt, conor+dt, geert+renesas,
magnus.damm, perex, tiwai, linux-sound, linux-renesas-soc,
devicetree, linux-kernel
In-Reply-To: <20260413100700.30995-3-phucduc.bui@gmail.com>
Hi
Hi
> 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>
> ---
(snip)
> @@ -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);
1st, please insert white line between "int ret = 0;" and "/* enable spu
clock */".
2nd, besically, FSI already has "lock", and using it for several protecting.
Please re-use it, and don't add random new-lock. It makes code confusable.
Then, please use guard().
3rd, I don't like above count inc/dec, and mutex_unlock() style, because
the code unnecessarily complicated. It can be...
int ret = 0;
if (master->clk_spu) {
guard(spinlock_irqsave)(&master->lock);
if (master->spu_count == 0)
ret = clk_prepare_enable(master->clk_spu);
master->spu_count++;
}
if (ret < 0)
return ret;
I'm not 100% sure, but I guess you need to count up spu_count anyway
regardless of clk_prepare_enable() result ?
Thank you for your help !!
Best regards
---
Kuninori Morimoto
^ permalink raw reply
* Re: [PATCH v2 1/6] ASoC: renesas: fsi: Add shared SPU clock support
From: Kuninori Morimoto @ 2026-04-14 0:02 UTC (permalink / raw)
To: phucduc.bui
Cc: broonie, lgirdwood, robh, krzk+dt, conor+dt, geert+renesas,
magnus.damm, perex, tiwai, linux-sound, linux-renesas-soc,
devicetree, linux-kernel
In-Reply-To: <20260413100700.30995-2-phucduc.bui@gmail.com>
Hi
> 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>
> ---
(snip)
> 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;
> };
You added clk_spu in this patch, but not touched.
When I checked whole patch-set, you initialize it at [4/6], but [2/6] is
using it. Maybe it works, but is strange.
The total patch orders are opposite, I think.
I think it can be...
As prepare
- Fix trigger stop ordering
- move fsi_clk_init()
- this just moves the function, no change
As adding new feature
- remains
Thank you for your help !!
Best regards
---
Kuninori Morimoto
^ permalink raw reply
* Re: [PATCH net-next v3 0/9] net: dsa: add DSA support for the LAN9645x switch chip family
From: Jakub Kicinski @ 2026-04-13 22:47 UTC (permalink / raw)
To: Jens Emil Schulz Østergaard
Cc: UNGLinuxDriver, Andrew Lunn, Vladimir Oltean, David S. Miller,
Eric Dumazet, Paolo Abeni, Simon Horman, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Woojung Huh, Russell King,
Steen Hegelund, Daniel Machon, linux-kernel, netdev, devicetree
In-Reply-To: <20260410-dsa_lan9645x_switch_driver_base-v3-0-aadc8595306d@microchip.com>
On Fri, 10 Apr 2026 13:48:36 +0200 Jens Emil Schulz Østergaard wrote:
> This series provides the Microchip LAN9645X Switch driver.
>
> The LAN9645x is a family of chips with ethernet switch functionality and
> multiple peripheral functions. The switch delivers up to 9 ethernet
> ports and 12 Gbps switching bandwidth.
>
> The switch chip has 5 integrated copper PHYs, support for 2x RGMII
> interfaces, 2x SGMII and one QSGMII interface.
>
> The switch chip is from the same design architecture family as ocelot
> and lan966x, and the driver reflects this similarity. However, LAN9645x
> does not have an internal CPU in any package, and must be driven
> externally. For register IO it supports interfaces such as SPI, I2C and
> MDIO.
We're wrapping up the 7.1 PR and doesn't look like Vladimir (or any
other DSA expert) had a chance to review this yet, so let's defer to
the next cycle.
--
pw-bot: defer
^ permalink raw reply
* Re: [PATCH v3 09/11] dt-bindings: input: Document hid-over-spi DT schema
From: Rob Herring @ 2026-04-13 22:34 UTC (permalink / raw)
To: Conor Dooley, Dmitry Torokhov, Jingyuan Liang
Cc: Jiri Kosina, Benjamin Tissoires, Jonathan Corbet, Mark Brown,
Steven Rostedt, Masami Hiramatsu, Mathieu Desnoyers,
Krzysztof Kozlowski, Conor Dooley, linux-input, linux-doc,
linux-kernel, linux-spi, linux-trace-kernel, devicetree, hbarnor,
tfiga, Dmitry Antipov, Jarrett Schultz
In-Reply-To: <20260410-sake-dollop-9f253ddb0749@spud>
On Fri, Apr 10, 2026 at 06:35:00PM +0100, Conor Dooley wrote:
> On Thu, Apr 09, 2026 at 10:16:46AM -0700, Dmitry Torokhov wrote:
> > On Thu, Apr 09, 2026 at 05:02:11PM +0100, Conor Dooley wrote:
> > > On Thu, Apr 02, 2026 at 01:59:46AM +0000, Jingyuan Liang wrote:
> > > > Documentation describes the required and optional properties for
> > > > implementing Device Tree for a Microsoft G6 Touch Digitizer that
> > > > supports HID over SPI Protocol 1.0 specification.
> > > >
> > > > The properties are common to HID over SPI.
> > > >
> > > > Signed-off-by: Dmitry Antipov <dmanti@microsoft.com>
> > > > Signed-off-by: Jarrett Schultz <jaschultz@microsoft.com>
> > > > Signed-off-by: Jingyuan Liang <jingyliang@chromium.org>
> > > > ---
> > > > .../devicetree/bindings/input/hid-over-spi.yaml | 126 +++++++++++++++++++++
> > > > 1 file changed, 126 insertions(+)
> > > >
> > > > diff --git a/Documentation/devicetree/bindings/input/hid-over-spi.yaml b/Documentation/devicetree/bindings/input/hid-over-spi.yaml
> > > > new file mode 100644
> > > > index 000000000000..d1b0a2e26c32
> > > > --- /dev/null
> > > > +++ b/Documentation/devicetree/bindings/input/hid-over-spi.yaml
> > > > @@ -0,0 +1,126 @@
> > > > +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> > > > +%YAML 1.2
> > > > +---
> > > > +$id: http://devicetree.org/schemas/input/hid-over-spi.yaml#
> > > > +$schema: http://devicetree.org/meta-schemas/core.yaml#
> > > > +
> > > > +title: HID over SPI Devices
> > > > +
> > > > +maintainers:
> > > > + - Benjamin Tissoires <benjamin.tissoires@redhat.com>
> > > > + - Jiri Kosina <jkosina@suse.cz>
> > >
> > > Why them and not you, the developers of the series?
> > >
> > > > +
> > > > +description: |+
> > > > + HID over SPI provides support for various Human Interface Devices over the
> > > > + SPI bus. These devices can be for example touchpads, keyboards, touch screens
> > > > + or sensors.
> > > > +
> > > > + The specification has been written by Microsoft and is currently available
> > > > + here: https://www.microsoft.com/en-us/download/details.aspx?id=103325
> > > > +
> > > > + If this binding is used, the kernel module spi-hid will handle the
> > > > + communication with the device and the generic hid core layer will handle the
> > > > + protocol.
> > >
> > > This is not relevant to the binding, please remove it.
> > >
> > > > +
> > > > +allOf:
> > > > + - $ref: /schemas/input/touchscreen/touchscreen.yaml#
> > > > +
> > > > +properties:
> > > > + compatible:
> > > > + oneOf:
> > > > + - items:
> > > > + - enum:
> > > > + - microsoft,g6-touch-digitizer
> > > > + - const: hid-over-spi
> > > > + - description: Just "hid-over-spi" alone is allowed, but not recommended.
> > > > + const: hid-over-spi
> > >
> > > Why is it allowed but not recommended? Seems to me like we should
> > > require device-specific compatibles.
> >
> > Why would we want to change the driver code to add a new compatible each
> > time a vendor decides to create a chip that is fully hid-spi-protocol
> > compliant? Or is the plan to still allow "hid-over-spi" fallback but
> > require device-specific compatible that will be ignored unless there is
> > device-specific quirk needed?
The plan is the latter case (the 1st entry up above). The comment is
remove the 2nd entry (with 'Just "hid-over-spi" alone is allowed, but
not recommended.').
> This has nothing to do with the driver, just the oddity of having a
> comment saying that not having a device specific compatible was
> permitted by not recommended in a binding. Requiring device-specific
> compatibles is the norm after all and a comment like this makes draws
> more attention to the fact that this is abnormal. Regardless of what the
> driver does, device-specific compatibles should be required.
>
> > > > +
> > > > + reg:
> > > > + maxItems: 1
> > > > +
> > > > + interrupts:
> > > > + maxItems: 1
> > > > +
> > > > + reset-gpios:
> > > > + maxItems: 1
> > > > + description:
> > > > + GPIO specifier for the digitizer's reset pin (active low). The line must
> > > > + be flagged with GPIO_ACTIVE_LOW.
> > > > +
> > > > + vdd-supply:
> > > > + description:
> > > > + Regulator for the VDD supply voltage.
> > > > +
> > > > + input-report-header-address:
> > > > + $ref: /schemas/types.yaml#/definitions/uint32
> > > > + minimum: 0
> > > > + maximum: 0xffffff
> > > > + description:
> > > > + A value to be included in the Read Approval packet, listing an address of
> > > > + the input report header to be put on the SPI bus. This address has 24
> > > > + bits.
> > > > +
> > > > + input-report-body-address:
> > > > + $ref: /schemas/types.yaml#/definitions/uint32
> > > > + minimum: 0
> > > > + maximum: 0xffffff
> > > > + description:
> > > > + A value to be included in the Read Approval packet, listing an address of
> > > > + the input report body to be put on the SPI bus. This address has 24 bits.
> > > > +
> > > > + output-report-address:
> > > > + $ref: /schemas/types.yaml#/definitions/uint32
> > > > + minimum: 0
> > > > + maximum: 0xffffff
> > > > + description:
> > > > + A value to be included in the Output Report sent by the host, listing an
> > > > + address where the output report on the SPI bus is to be written to. This
> > > > + address has 24 bits.
> > > > +
> > > > + read-opcode:
> > > > + $ref: /schemas/types.yaml#/definitions/uint8
> > > > + description:
> > > > + Value to be used in Read Approval packets. 1 byte.
> > > > +
> > > > + write-opcode:
> > > > + $ref: /schemas/types.yaml#/definitions/uint8
> > > > + description:
> > > > + Value to be used in Write Approval packets. 1 byte.
> > >
> > > Why can none of these things be determined from the device's compatible?
> > > On the surface, they like the kinds of things that could/should be.
> >
> > Why would we want to keep tables of these values in the kernel and again
> > have to update the driver for each new chip?
>
> That's pretty normal though innit? It's what match data does.
> If someone wants to have properties that communicate data that
> can be determined from the compatible, they need to provide
> justification why it is being done.
IIRC, it was explained in prior versions the spec itself says these
values vary by device. If we expect variation, then I think these
properties are fine. But please capture the reasoning for them in this
patch or we will just keep asking the same questions over and over.
Rob
^ permalink raw reply
* Re: [PATCH] dt-bindings: qcom,pdc: document the Hawi Power Domain Controller
From: Rob Herring (Arm) @ 2026-04-13 22:25 UTC (permalink / raw)
To: Mukesh Ojha
Cc: Krzysztof Kozlowski, linux-arm-msm, linux-kernel, devicetree,
Thomas Gleixner, Bjorn Andersson, Conor Dooley, Konrad Dybcio
In-Reply-To: <20260401125004.592925-1-mukesh.ojha@oss.qualcomm.com>
On Wed, 01 Apr 2026 18:20:04 +0530, Mukesh Ojha wrote:
> Document the Power Domain Controller on the Qualcomm Hawi SoC.
>
> Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
> Signed-off-by: Mukesh Ojha <mukesh.ojha@oss.qualcomm.com>
> ---
> .../devicetree/bindings/interrupt-controller/qcom,pdc.yaml | 1 +
> 1 file changed, 1 insertion(+)
>
Applied, thanks!
^ permalink raw reply
* Re: [PATCH v2 3/7] dt-bindings: soc: samsung: exynos-pmu: deprecate google,pmu-intr-gen-syscon
From: Rob Herring @ 2026-04-13 22:25 UTC (permalink / raw)
To: Alexey Klimov
Cc: Sam Protsenko, linux-samsung-soc, Krzysztof Kozlowski,
Peter Griffin, André Draszik, Conor Dooley, Alim Akhtar,
Tudor Ambarus, Krzysztof Kozlowski, linux-arm-kernel, devicetree,
linux-kernel
In-Reply-To: <20260401-exynos850-cpuhotplug-v2-3-c5a760a3e259@linaro.org>
On Wed, Apr 01, 2026 at 05:51:56AM +0100, Alexey Klimov wrote:
> The generic property samsung,pmu-intr-gen-syscon should be used
> by default for Samsung Exynos PMU hardware blocks. Update binding
> document to add deprecated flag for google,pmu-intr-gen-syscon
> property.
> While at this, also add dependency to not allow usage of both
> above mentioned properties in the same time.
>
> Signed-off-by: Alexey Klimov <alexey.klimov@linaro.org>
> ---
> Documentation/devicetree/bindings/soc/samsung/exynos-pmu.yaml | 6 ++++++
> 1 file changed, 6 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/soc/samsung/exynos-pmu.yaml b/Documentation/devicetree/bindings/soc/samsung/exynos-pmu.yaml
> index 92acdfd5d44e..1ff1a8729989 100644
> --- a/Documentation/devicetree/bindings/soc/samsung/exynos-pmu.yaml
> +++ b/Documentation/devicetree/bindings/soc/samsung/exynos-pmu.yaml
> @@ -119,6 +119,7 @@ properties:
> $ref: /schemas/types.yaml#/definitions/phandle
> description:
> Phandle to PMU interrupt generation interface.
> + deprecated: true
Deprecating doesn't really help. We still have to support both forever.
>
> required:
> - compatible
> @@ -207,6 +208,11 @@ allOf:
> properties:
> samsung,pmu-intr-gen-syscon: false
>
> +dependencies:
> + google,pmu-intr-gen-syscon:
> + not:
> + required: ['samsung,pmu-intr-gen-syscon']
Disallowing both means you couldn't update the DT in a compatible way
where you have both properties for some transistion period.
Rob
^ permalink raw reply
* Re: [PATCH v2 2/7] dt-bindings: soc: samsung: exynos-pmu: add samsung,pmu-intr-gen phandle
From: Rob Herring @ 2026-04-13 22:16 UTC (permalink / raw)
To: Alexey Klimov
Cc: Sam Protsenko, linux-samsung-soc, Krzysztof Kozlowski,
Peter Griffin, André Draszik, Conor Dooley, Alim Akhtar,
Tudor Ambarus, Krzysztof Kozlowski, linux-arm-kernel, devicetree,
linux-kernel
In-Reply-To: <20260401-exynos850-cpuhotplug-v2-2-c5a760a3e259@linaro.org>
On Wed, Apr 01, 2026 at 05:51:55AM +0100, Alexey Klimov wrote:
> Some Exynos-based SoCs, for instance Exynos850, require access
> to the pmu interrupt generation register region which is exposed
> as a syscon. Update the exynos-pmu bindings documentation to
> reflect this.
>
> Signed-off-by: Alexey Klimov <alexey.klimov@linaro.org>
> ---
> .../devicetree/bindings/soc/samsung/exynos-pmu.yaml | 18 ++++++++++++++++++
> 1 file changed, 18 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/soc/samsung/exynos-pmu.yaml b/Documentation/devicetree/bindings/soc/samsung/exynos-pmu.yaml
> index 76ce7e98c10f..92acdfd5d44e 100644
> --- a/Documentation/devicetree/bindings/soc/samsung/exynos-pmu.yaml
> +++ b/Documentation/devicetree/bindings/soc/samsung/exynos-pmu.yaml
> @@ -110,6 +110,11 @@ properties:
> description:
> Node for reboot method
>
> + samsung,pmu-intr-gen-syscon:
> + $ref: /schemas/types.yaml#/definitions/phandle
> + description:
> + Phandle to PMU interrupt generation interface.
> +
> google,pmu-intr-gen-syscon:
Does this mean the driver is just going to have to look at both
properties for the same thing? If so, just use the existing property. We
don't need 2. Yeah, 'google' in Samsung SoCs is a bit weird, but that's
Samsung's fault for not upstreaming support for their h/w first.
Rob
^ permalink raw reply
* Re: [PATCH v2 1/7] dt-bindings: soc: move,rename google,gs101-pmu-intr-gen and add exynos850
From: Rob Herring (Arm) @ 2026-04-13 22:11 UTC (permalink / raw)
To: Alexey Klimov
Cc: linux-arm-kernel, linux-samsung-soc, Krzysztof Kozlowski,
devicetree, linux-kernel, Sam Protsenko, André Draszik,
Alim Akhtar, Peter Griffin, Tudor Ambarus, Krzysztof Kozlowski,
Conor Dooley
In-Reply-To: <20260401-exynos850-cpuhotplug-v2-1-c5a760a3e259@linaro.org>
On Wed, 01 Apr 2026 05:51:54 +0100, Alexey Klimov wrote:
> The PMU interrupt generation block introduced for the Google GS101 is
> actually a standard Samsung Exynos IP block found in older SoCs, such
> as the Exynos850, and is not exclusive to Google SoCs. To accurately
> reflect its origin, move the schema file to under soc/samsung/
> directory and rename it.
> Concurrently, add the new "samsung,exynos850-pmu-intr-gen" compatible
> string to the bindings. Support for this block is required to enable
> power management features like CPU hotplug and idle states on Exynos850
> platforms.
> Also, move this file under Exynos850 SoC in MAINTAINERS entry.
>
> Signed-off-by: Alexey Klimov <alexey.klimov@linaro.org>
> ---
> .../samsung,exynos850-pmu-intr-gen.yaml} | 8 +++++---
> MAINTAINERS | 2 +-
> 2 files changed, 6 insertions(+), 4 deletions(-)
>
Reviewed-by: Rob Herring (Arm) <robh@kernel.org>
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox