* Re: [PATCH 2/4] ASoC: dt-bindings: Add support for the GPIOs driven amplifier
From: Mark Brown @ 2026-04-08 13:14 UTC (permalink / raw)
To: Rob Herring
Cc: Herve Codina, Liam Girdwood, Krzysztof Kozlowski, Conor Dooley,
Saravana Kannan, Jaroslav Kysela, Takashi Iwai, linux-sound,
devicetree, linux-kernel, Christophe Leroy, Thomas Petazzoni
In-Reply-To: <20260408122901.GA42727-robh@kernel.org>
[-- Attachment #1: Type: text/plain, Size: 368 bytes --]
On Wed, Apr 08, 2026 at 07:29:01AM -0500, Rob Herring wrote:
> On Mon, Mar 30, 2026 at 12:16:06PM +0200, Herve Codina wrote:
> > +dependencies:
> > + gain-points: [ gain-gpios ]
> > + gain-range: [ gain-gpios ]
> > + gain-labels: [ gain-gpios ]
> gain-gpios is really optional?
You've still got mute control, and power up/down - each feature should
be optional.
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply
* Re: [PATCH v6 21/21] arm64: dts: renesas: r9a09g047e57-smarc: Enable DU0 and DSI support
From: Geert Uytterhoeven @ 2026-04-08 13:01 UTC (permalink / raw)
To: Tommaso Merciai
Cc: tomm.merciai, laurent.pinchart, linux-renesas-soc, biju.das.jz,
Maarten Lankhorst, Maxime Ripard, Thomas Zimmermann, David Airlie,
Simona Vetter, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Geert Uytterhoeven, Michael Turquette, Stephen Boyd, Magnus Damm,
Laurent Pinchart, Tomi Valkeinen, dri-devel, devicetree,
linux-kernel, linux-clk
In-Reply-To: <481fefa0c9f6f0629a663fe3da1fb17e7f4a1a05.1775636898.git.tommaso.merciai.xr@bp.renesas.com>
Hi Tommaso,
On Wed, 8 Apr 2026 at 12:40, Tommaso Merciai
<tommaso.merciai.xr@bp.renesas.com> wrote:
> Enable DU0, DSI and ADV7535 on RZ/G3E SMARC EVK.
>
> Signed-off-by: Tommaso Merciai <tommaso.merciai.xr@bp.renesas.com>
Thanks for your patch!
> --- a/arch/arm64/boot/dts/renesas/rzg3e-smarc-som.dtsi
> +++ b/arch/arm64/boot/dts/renesas/rzg3e-smarc-som.dtsi
> @@ -33,6 +33,7 @@ aliases {
> ethernet0 = ð0;
> ethernet1 = ð1;
> i2c2 = &i2c2;
> + i2c7 = &i2c7;
> mmc0 = &sdhi0;
> mmc2 = &sdhi2;
> };
> @@ -77,12 +78,47 @@ reg_vdd0p8v_others: regulator-vdd0p8v-others {
> regulator-always-on;
> };
>
> + reg_1p8v_adv: regulator-1p8v-adv {
Please preserve sort order (alphabetical, by node name).
> + compatible = "regulator-fixed";
> + regulator-name = "fixed-1.8V";
> + regulator-min-microvolt = <1800000>;
> + regulator-max-microvolt = <1800000>;
> + regulator-boot-on;
> + regulator-always-on;
> + };
> +
> + reg_3p3v_adv: regulator-3p3v-adv {
> + compatible = "regulator-fixed";
> + regulator-name = "fixed-3.3V";
> + regulator-min-microvolt = <3300000>;
> + regulator-max-microvolt = <3300000>;
> + regulator-boot-on;
> + regulator-always-on;
> + };
Why not reusing the existing reg_1p8v and reg_3p3v?
Note that reg_1p8v driving eMMC and QSPI are also not the same
physical power rail.
> +
> + osc1: cec-clock {
Please preserve sort order (alphabetical, by node name).
> + compatible = "fixed-clock";
> + #clock-cells = <0>;
> + clock-frequency = <12000000>;
> + };
> +
> /* 32.768kHz crystal */
> x3: x3-clock {
> compatible = "fixed-clock";
> #clock-cells = <0>;
> clock-frequency = <32768>;
> };
> +
> + dsi-to-hdmi-out {
hdmi-out?
Please preserve sort order (alphabetical, by node name).
> + compatible = "hdmi-connector";
> + type = "d";
> +
> + port {
> + dsi_to_hdmi_out: endpoint {
> + remote-endpoint = <&adv7535_out>;
> + };
> + };
> + };
> };
>
> &audio_extal_clk {
> @@ -107,6 +143,37 @@ ð1 {
> status = "okay";
> };
>
> +&dsi {
Please preserve sort-order (alphabetical, by label).
> + status = "okay";
> +
> + ports {
> + port@0 {
> + dsi_in0: endpoint {
> + remote-endpoint = <&du0_out_dsi>;
> + };
> + };
> +
> + port@2 {
> + dsi_out: endpoint {
> + remote-endpoint = <&adv7535_in>;
> + data-lanes = <1 2 3 4>;
> + };
> + };
> + };
> +};
> +
> +&du0 {
> + status = "okay";
> +
> + ports {
> + port@0 {
> + du0_out_dsi: endpoint {
> + remote-endpoint = <&dsi_in0>;
> + };
> + };
> + };
> +};
> +
> &gpu {
> status = "okay";
> mali-supply = <®_vdd0p8v_others>;
> @@ -132,6 +199,48 @@ raa215300: pmic@12 {
> };
> };
>
> +&i2c7 {
> + pinctrl-0 = <&i2c7_pins>;
> + pinctrl-names = "default";
> + status = "okay";
> + clock-frequency = <400000>;
> +
> + adv7535: hdmi@3d {
> + compatible = "adi,adv7535";
> + reg = <0x3d>, <0x4d>, <0x2d>, <0x5d>;
> + reg-names = "main", "edid", "cec", "packet";
> + clocks = <&osc1>;
> + clock-names = "cec";
> + avdd-supply = <®_1p8v_adv>;
> + dvdd-supply = <®_1p8v_adv>;
> + pvdd-supply = <®_1p8v_adv>;
> + a2vdd-supply = <®_1p8v_adv>;
> + v3p3-supply = <®_3p3v_adv>;
> + v1p2-supply = <®_1p8v_adv>;
> + adi,dsi-lanes = <4>;
> + interrupts-extended = <&pinctrl RZG3E_GPIO(L, 4) IRQ_TYPE_EDGE_FALLING>;
> +
> + ports {
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + port@0 {
> + reg = <0>;
> + adv7535_in: endpoint {
> + remote-endpoint = <&dsi_out>;
> + };
> + };
> +
> + port@1 {
> + reg = <1>;
> + adv7535_out: endpoint {
> + remote-endpoint = <&dsi_to_hdmi_out>;
> + };
> + };
> + };
> + };
> +};
> +
> &i3c {
> pinctrl-0 = <&i3c_pins>;
> pinctrl-names = "default";
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
* Re: [PATCH v2 2/3] mailbox: exynos: Add support for Exynos850 mailbox
From: Alexey Klimov @ 2026-04-08 13:08 UTC (permalink / raw)
To: Tudor Ambarus
Cc: Krzysztof Kozlowski, Sylwester Nawrocki, Chanwoo Choi,
Alim Akhtar, Sam Protsenko, Michael Turquette, Stephen Boyd,
Rob Herring, Conor Dooley, Jassi Brar, Krzysztof Kozlowski,
Peter Griffin, linux-samsung-soc, linux-arm-kernel, linux-clk,
devicetree, linux-kernel
In-Reply-To: <a02a693e-b06e-43bf-ac5f-8253f298c83d@linaro.org>
Hi Tudor,
On Thu Apr 2, 2026 at 9:42 AM BST, Tudor Ambarus wrote:
> Hi, Alexey,
>
> On 4/2/26 5:20 AM, Alexey Klimov wrote:
>> Exynos850-based platforms support ACPM and has similar workflow
>> of communicating with ACPM via mailbox, however mailbox controller
>> registers are located at different offsets and writes/reads could be
>> different. To distinguish between such different behaviours,
>> the registers offsets for Exynos850 and the platform-specific data
>> structs are introduced and configuration is described in such structs
>> for gs101 and exynos850 based SoCs. Probe routine now selects the
>> corresponding platform-specific data via device_get_match_data().
>>
>> Signed-off-by: Alexey Klimov <alexey.klimov@linaro.org>
>> ---
>> drivers/mailbox/exynos-mailbox.c | 67 ++++++++++++++++++++++++++++++++++++++--
>> 1 file changed, 64 insertions(+), 3 deletions(-)
>>
>> diff --git a/drivers/mailbox/exynos-mailbox.c b/drivers/mailbox/exynos-mailbox.c
>> index d2355b128ba4..f9c59c07558a 100644
>> --- a/drivers/mailbox/exynos-mailbox.c
>> +++ b/drivers/mailbox/exynos-mailbox.c
>> @@ -31,14 +31,61 @@
>>
>> #define EXYNOS_MBOX_CHAN_COUNT HWEIGHT32(EXYNOS_MBOX_INTGR1_MASK)
>>
>> +#define EXYNOS850_MBOX_MCUCTRL 0x0 /* Mailbox Control Register */
>> +#define EXYNOS850_MBOX_INTGR0 0x8 /* Interrupt Generation Register 0 */
>> +#define EXYNOS850_MBOX_INTCR0 0x0C /* Interrupt Clear Register 0 */
>> +#define EXYNOS850_MBOX_INTMR0 0x10 /* Interrupt Mask Register 0 */
>> +#define EXYNOS850_MBOX_INTSR0 0x14 /* Interrupt Status Register 0 */
>> +#define EXYNOS850_MBOX_INTMSR0 0x18 /* Interrupt Mask Status Register 0 */
>> +#define EXYNOS850_MBOX_INTGR1 0x1C /* Interrupt Generation Register 1 */
>> +#define EXYNOS850_MBOX_INTMR1 0x24 /* Interrupt Mask Register 1 */
>> +#define EXYNOS850_MBOX_INTSR1 0x28 /* Interrupt Status Register 1 */
>> +#define EXYNOS850_MBOX_INTMSR1 0x2C /* Interrupt Mask Status Register 1 */
>> +#define EXYNOS850_MBOX_VERSION 0x70
>
> Please consider defining just the registers that are used, to not
> pollute the driver. You may drop the unused gs101 definitions too.
Sure. Thanks. I was surprised how many unused defines were introduced
by gs101 SoC in the first place all over.
>> +#define EXYNOS850_MBOX_INTMR1_MASK GENMASK(15, 0)
>> +
>> +/**
>> + * struct exynos_mbox_driver_data - platform-specific mailbox configuration.
>> + * @irq_doorbell_offset: offset to the IRQ generation register, doorbell
>> + * to APM co-processor.
>> + * @irq_doorbell_shift: shift to apply to the value written to IRQ
>> + * generation register.
>> + * @irq_mask_offset: offset to the IRQ mask register.
>> + * @irq_mask_value: value to right to the mask register to mask out
>> + * all interrupts.
>> + */
>> +struct exynos_mbox_driver_data {
>> + u16 irq_doorbell_offset;
>> + u16 irq_doorbell_shift;
>> + u16 irq_mask_offset;
>> + u16 irq_mask_value;
>> +};
>> +
>> /**
>> * struct exynos_mbox - driver's private data.
>> * @regs: mailbox registers base address.
>> * @mbox: pointer to the mailbox controller.
>> + * @data: pointer to driver platform-specific data.
>> */
>> struct exynos_mbox {
>> void __iomem *regs;
>> struct mbox_controller *mbox;
>> + const struct exynos_mbox_driver_data *data;
>> +};
>> +
>> +static const struct exynos_mbox_driver_data exynos850_mbox_data = {
>> + .irq_doorbell_offset = EXYNOS850_MBOX_INTGR0,
>> + .irq_doorbell_shift = 16,
>> + .irq_mask_offset = EXYNOS850_MBOX_INTMR1,
>> + .irq_mask_value = EXYNOS850_MBOX_INTMR1_MASK,
>> +};
>> +
>> +static const struct exynos_mbox_driver_data exynos_gs101_mbox_data = {
>> + .irq_doorbell_offset = EXYNOS_MBOX_INTGR1,
>> + .irq_doorbell_shift = 0,
>> + .irq_mask_offset = EXYNOS_MBOX_INTMR0,
>> + .irq_mask_value = EXYNOS_MBOX_INTMR0_MASK,
>> };
>
> I find it strange that the SoCs use different registers. Are you sure you're
> using the right direction? i.e. ring the doorbell to APM and not to AP?
Well, I am not sure I correctly understood the questions and comment. So,
this all was tested with ACPM TMU code with 3 temp sensors and it seems
to work and sensors react in the right way.
Downstream clearly does the following (see also [1],[2]) when sending
ACPM msg:
static void apm_interrupt_gen(unsigned int id)
{
/* APM NVIC INTERRUPT GENERATE */
writel((1 << id) << 16, acpm_ipc->intr + INTGR0);
}
I am aware that gs101 downstream uses INTGR1 in apm_interrupt_gen().
When I use INTGR1 for e850 then I observe acpm timeouts. Hence, out of
curiosity, what's the expected behaviour when/if I ring the doorbell to
AP (to itself as far as I understand)? My understanding that it won't
work at all in such case unless APM firmware does some very fast
polling.
[1]: https://gitlab.com/Linaro/96boards/e850-96/kernel/-/blob/android-exynos-4.14-linaro/drivers/soc/samsung/acpm/acpm_ipc.c?ref_type=heads#L423
[2]: https://github.com/samsungexynos850/android_kernel_samsung_exynos850/blob/0af517be2336bf8e09c59d576c4c314446713101/drivers/soc/samsung/acpm/acpm_ipc.c#L426
>> static int exynos_mbox_send_data(struct mbox_chan *chan, void *data)
>> @@ -57,7 +104,8 @@ static int exynos_mbox_send_data(struct mbox_chan *chan, void *data)
>> return -EINVAL;
>> }
>>
>> - writel(BIT(msg->chan_id), exynos_mbox->regs + EXYNOS_MBOX_INTGR1);
>> + writel(BIT(msg->chan_id) << exynos_mbox->data->irq_doorbell_shift,
>> + exynos_mbox->regs + exynos_mbox->data->irq_doorbell_offset);
>
> Use FIELD_PREP from <linux/bitfield.h> please. You will use a mask instead of
> a shift.
>
> I would rename irq_doorbell_offset to intgr. It aligns with the register name
> from the datasheet. You won't need to prepend _offset to the name, we already
> see it's an offset when doing the writel().
Sure. Thanks. Let's use FIELD_PREP.
"doorbell" naming was chosen for readability and maintainability reasons.
It seems to be more generic enough name that better reflects the workflow
of what's going on in ACPM+mailbox machinery. We can rename it to just
"doorbell" for instance.
From platform data it will be clear to which register it is set, INTGR0
or INTGR1, to align it with datasheet (which is closed anyway).
Regarding intgr vs doorbell name, the intgr is a bit unclear for a
reader if it means interrupt generation register or something else.
But if you prefer, I can go with "intgr".
One more option is add a comment, smth like /* Ring the doorbell */
before that writel().
[..]
>> @@ -133,7 +194,7 @@ static int exynos_mbox_probe(struct platform_device *pdev)
>> platform_set_drvdata(pdev, exynos_mbox);
>>
>> /* Mask out all interrupts. We support just polling channels for now. */
>> - writel(EXYNOS_MBOX_INTMR0_MASK, exynos_mbox->regs + EXYNOS_MBOX_INTMR0);
>> + writel(data->irq_mask_value, exynos_mbox->regs + data->irq_mask_offset);
>>
>
> and here I would s/irq_mask_value/intmr_mask and irq_mask_offset/intmr.
Ack. Thanks.
Best regards,
Alexey
^ permalink raw reply
* Re: [PATCH 0/2] arm64: dts: renesas: Add missing #mux-state-cells to usb2phy-reset nodes
From: Geert Uytterhoeven @ 2026-04-08 13:07 UTC (permalink / raw)
To: Tommaso Merciai
Cc: tomm.merciai, peda, p.zabel, linux-renesas-soc, biju.das.jz,
Magnus Damm, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
devicetree, linux-kernel
In-Reply-To: <cover.1775575276.git.tommaso.merciai.xr@bp.renesas.com>
Hi Tommaso,
On Tue, 7 Apr 2026 at 17:35, Tommaso Merciai
<tommaso.merciai.xr@bp.renesas.com> wrote:
> The renesas,rzv2h-usb2phy-reset binding schema defines #mux-state-cells as a
> required property. Add it to the USB2 PHY reset nodes in the RZ/V2H and RZ/V2N
> device trees to fix dtbs_check warnings.
>
> "arch/arm64/boot/dts/renesas/r9a09g056n48-rzv2n-evk.dtb: usb20phy-reset@15830000 (renesas,r9a09g056-usb2phy-reset): '#mux-state-cells' is a required property"
> "arch/arm64/boot/dts/renesas/r9a09g056n48-rzv2n-evk-cn15-emmc.dtb: usb20phy-reset@15830000 (renesas,r9a09g056-usb2phy-reset): '#mux-state-cells' is a required property"
> "arch/arm64/boot/dts/renesas/r9a09g056n48-rzv2n-evk-cn15-sd.dtb: usb20phy-reset@15830000 (renesas,r9a09g056-usb2phy-reset): '#mux-state-cells' is a required property"
> "arch/arm64/boot/dts/renesas/r9a09g057h44-rzv2h-evk.dtb: usb20phy-reset@15830000 (renesas,r9a09g057-usb2phy-reset): '#mux-state-cells' is a required property"
> "arch/arm64/boot/dts/renesas/r9a09g057h44-rzv2h-evk.dtb: usb21phy-reset@15840000 (renesas,r9a09g057-usb2phy-reset): '#mux-state-cells' is a required property"
> "arch/arm64/boot/dts/renesas/r9a09g057h44-rzv2h-evk-cn15-emmc.dtb: usb20phy-reset@15830000 (renesas,r9a09g057-usb2phy-reset): '#mux-state-cells' is a required property"
> "arch/arm64/boot/dts/renesas/r9a09g057h44-rzv2h-evk-cn15-emmc.dtb: usb21phy-reset@15840000 (renesas,r9a09g057-usb2phy-reset): '#mux-state-cells' is a required property"
> "arch/arm64/boot/dts/renesas/r9a09g057h44-rzv2h-evk-cn15-sd.dtb: usb20phy-reset@15830000 (renesas,r9a09g057-usb2phy-reset): '#mux-state-cells' is a required property"
> "arch/arm64/boot/dts/renesas/r9a09g057h44-rzv2h-evk-cn15-sd.dtb: usb21phy-reset@15840000 (renesas,r9a09g057-usb2phy-reset): '#mux-state-cells' is a required property"
>
> Kind Regards,
> Tommaso
>
> Tommaso Merciai (2):
> arm64: dts: renesas: r9a09g057: Add #mux-state-cells to
> usb2{0,1}phyrst
> arm64: dts: renesas: r9a09g056: Add #mux-state-cells to usb20phyrst
Does this series supersedes "[PATCH v5 16/22] arm64: dts: renesas:
r9a09g056: Add USB2.0 VBUS_SEL mux-controller support"[1] and "[PATCH
v5 17/22] arm64: dts: renesas: r9a09g056: Add USB2.0 PHY VBUS internal
regulator node"[2]?
Thanks!
[1] https://lore.kernel.org/c63d0a62d439a78e9ccc0b4176b84bbc32629a8e.1764241212.git.tommaso.merciai.xr@bp.renesas.com
[2] https://lore.kernel.org/f33b5566511a946e4e909854213e75c12d89a441.1764241212.git.tommaso.merciai.xr@bp.renesas.com
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
* Re: [PATCH v4 1/2] dt-bindings: PCI: mediatek: Add support for EcoNet EN7528
From: Caleb James DeLisle @ 2026-04-08 13:03 UTC (permalink / raw)
To: Krzysztof Kozlowski
Cc: linux-pci, linux-mips, naseefkm, ryder.lee, helgaas, lpieralisi,
kwilczynski, mani, robh, krzk+dt, conor+dt, matthias.bgg,
angelogioacchino.delregno, ansuelsmth, linux-mediatek, devicetree,
linux-kernel
In-Reply-To: <20260405-phenomenal-messy-shark-bdefbd@quoll>
On 05/04/2026 09:03, Krzysztof Kozlowski wrote:
> On Sat, Apr 04, 2026 at 06:28:53PM +0000, Caleb James DeLisle wrote:
>> Introduce EcoNet EN7528 SoC compatible in MediaTek PCIe controller
>> binding.
>>
>> EcoNet PCIe controller has the same configuration model as
>> Mediatek v2 but is initialized more similarly to an MT7621
>> PCIe.
>>
> <form letter>
> This is a friendly reminder during the review process.
>
> It looks like you received a tag and forgot to add it.
>
Whoops, that was a failed-to-press-save error, thanks for catching it, I
will update in a few days after waiting for any additional commentary.
Caleb
The missing line:
Acked-by: Conor Dooley <conor.dooley@microchip.com>
^ permalink raw reply
* Re: [PATCH v2 02/11] dt-bindings: regulator: ti,pbias-regulator: Add pbias_sim_omap4 regulator
From: Thomas Richard @ 2026-04-08 13:01 UTC (permalink / raw)
To: Rob Herring
Cc: Krzysztof Kozlowski, Aaro Koskinen, Andreas Kemnade, Kevin Hilman,
Roger Quadros, Tony Lindgren, Liam Girdwood, Mark Brown,
Krzysztof Kozlowski, Conor Dooley, Lee Jones, Thomas Petazzoni,
linux-omap, linux-kernel, devicetree
In-Reply-To: <20260408124109.GB1864812-robh@kernel.org>
On 4/8/26 2:41 PM, Rob Herring wrote:
> On Wed, Apr 08, 2026 at 09:58:15AM +0200, Thomas Richard wrote:
>> Hello Krzysztof,
>>
>> On 3/31/26 10:22 AM, Krzysztof Kozlowski wrote:
>>> On Mon, Mar 30, 2026 at 03:43:59PM +0200, Thomas Richard wrote:
>>>> Define pbias_sim_omap4 regulator for OMAP4. This regulators drives SIM_VDDS
>>>> supply and allows to unlock USB I/O cell.
>>>>
>>>> Signed-off-by: Thomas Richard <thomas.richard@bootlin.com>
>>>> ---
>>>> Documentation/devicetree/bindings/regulator/ti,pbias-regulator.yaml | 1 +
>>>> 1 file changed, 1 insertion(+)
>>>>
>>>> diff --git a/Documentation/devicetree/bindings/regulator/ti,pbias-regulator.yaml b/Documentation/devicetree/bindings/regulator/ti,pbias-regulator.yaml
>>>> index 3e020d87701b..908fbb46b5cf 100644
>>>> --- a/Documentation/devicetree/bindings/regulator/ti,pbias-regulator.yaml
>>>> +++ b/Documentation/devicetree/bindings/regulator/ti,pbias-regulator.yaml
>>>> @@ -89,6 +89,7 @@ allOf:
>>>> contains:
>>>> enum:
>>>> - pbias_mmc_omap4
>>>> + - pbias_sim_omap4
>>>
>>> Names cannot be fixed, because they represent different board naming.
>>> Why growing the deprecated style?
>>
>> Okay, so I'll drop all if statements, add a regex which matches
>> regulator names and fix the regulator name in the driver.
>
> If a driver depends on the names, you can't change them.
>
I mean the new regulator I add with this series. At this time it does
not exist yet in the driver.
Best Regards,
Thomas
^ permalink raw reply
* Re: [PATCH net-next v2 1/4] dt-bindings: net: dsa: add MT7628 ESW
From: Rob Herring @ 2026-04-08 13:00 UTC (permalink / raw)
To: Joris Vaisvila
Cc: netdev, horms, pabeni, kuba, edumazet, davem, olteanv,
Andrew Lunn, devicetree, Krzysztof Kozlowski, Conor Dooley
In-Reply-To: <20260330184017.766200-2-joey@tinyisr.com>
On Mon, Mar 30, 2026 at 09:40:14PM +0300, Joris Vaisvila wrote:
> Add bindings for MT7628 SoC's Embedded Switch.
>
> Signed-off-by: Joris Vaisvila <joey@tinyisr.com>
> ---
> .../bindings/net/dsa/mediatek,mt7628-esw.yaml | 101 ++++++++++++++++++
> 1 file changed, 101 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/net/dsa/mediatek,mt7628-esw.yaml
>
> diff --git a/Documentation/devicetree/bindings/net/dsa/mediatek,mt7628-esw.yaml b/Documentation/devicetree/bindings/net/dsa/mediatek,mt7628-esw.yaml
> new file mode 100644
> index 000000000000..d6c66ab677d0
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/net/dsa/mediatek,mt7628-esw.yaml
> @@ -0,0 +1,101 @@
> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/net/dsa/mediatek,mt7628-esw.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: Mediatek MT7628 Embedded Ethernet Switch
> +
> +maintainers:
> + - Joris Vaisvila <joey@tinyisr.com>
> +
> +description:
> + The MT7628 SoC's built-in Ethernet Switch is a five port switch with
> + integrated 10/100 PHYs. The switch registers are directly mapped in the SoC's
> + memory. The switch has an internally connected 1G CPU port and 5 user ports
> + connected to the built-in Fast Ethernet PHYs.
> +
> +unevaluatedProperties: false
> +
> +allOf:
> + - $ref: dsa.yaml#/$defs/ethernet-ports
> +
> +properties:
> + compatible:
> + const: mediatek,mt7628-esw
> +
> + reg:
> + maxItems: 1
> + description: MMIO address of the switch
Drop the description.
> +
> + resets:
> + items:
> + - description: Phandle of system reset controller with ESW reset index
> + - description: Phandle of system reset controller with EPHY reset index
Just describe these in terms of what they reset, not the provider.
> +
> + reset-names:
> + items:
> + - const: esw
> + - const: ephy
> +
> + mdio:
> + $ref: /schemas/net/mdio.yaml#
> + unevaluatedProperties: false
> +
> +required:
> + - compatible
> + - reg
> + - resets
> + - reset-names
Surely 'ethernet-ports' is required?
> +
> +examples:
> + - |
> + switch0: switch@10110000 {
> + reg = <0x10110000 0x8000>;
> +
> + resets = <&sysc 23>, <&sysc 24>;
> + reset-names = "esw", "ephy";
> +
> + compatible = "mediatek,mt7628-esw";
compatible goes before reg.
> +
> + ports {
"ethernet-ports" for new bindings.
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + port@0 {
And ethernet-port
> + reg = <0>;
> + phy-mode = "internal";
> + };
> +
> + port@1 {
> + reg = <1>;
> + phy-mode = "internal";
> + };
> +
> + port@2 {
> + reg = <2>;
> + phy-mode = "internal";
> + };
> +
> + port@3 {
> + reg = <3>;
> + phy-mode = "internal";
> + };
> +
> + port@4 {
> + reg = <4>;
> + phy-mode = "internal";
> + };
> +
> + port@6 {
> + reg = <6>;
> + phy-mode = "internal";
> + ethernet = <ðernet>;
> +
> + fixed-link {
> + speed = <1000>;
> + full-duplex;
> + };
> + };
> + };
> + };
> --
> 2.53.0
>
^ permalink raw reply
* Re: [PATCH v2 8/8] mips: dts: Add PCIe to EcoNet EN751221
From: Caleb James DeLisle @ 2026-04-08 12:58 UTC (permalink / raw)
To: Thomas Bogendoerfer
Cc: linux-mips, naseefkm, mturquette, sboyd, robh, krzk+dt, conor+dt,
ryder.lee, jianjun.wang, lpieralisi, kwilczynski, mani, bhelgaas,
vkoul, neil.armstrong, p.zabel, matthias.bgg,
angelogioacchino.delregno, nbd, ansuelsmth, linux-clk, devicetree,
linux-kernel, linux-pci, linux-mediatek, linux-phy,
linux-arm-kernel
In-Reply-To: <adOo9xZxXT3FkufM@alpha.franken.de>
On 06/04/2026 14:37, Thomas Bogendoerfer wrote:
> On Mon, Mar 09, 2026 at 01:18:18PM +0000, Caleb James DeLisle wrote:
>> Add PCIe based on EN7528 PCIe driver, also add two MT76 wifi devices
>> to SmartFiber XP8421-B.
>>
>> Signed-off-by: Caleb James DeLisle <cjd@cjdns.fr>
>> ---
>> arch/mips/boot/dts/econet/en751221.dtsi | 114 ++++++++++++++++++
>> .../econet/en751221_smartfiber_xp8421-b.dts | 21 ++++
>> arch/mips/econet/Kconfig | 2 +
>> 3 files changed, 137 insertions(+)
>>
> applied to mips-next
Thank you very much.
Caleb
>
> Thomas.
>
^ permalink raw reply
* Re: [PATCH v2 08/11] dt-bindings: mfd: ti,omap-usb-host: Convert to DT schema
From: Rob Herring @ 2026-04-08 12:55 UTC (permalink / raw)
To: Thomas Richard
Cc: Aaro Koskinen, Andreas Kemnade, Kevin Hilman, Roger Quadros,
Tony Lindgren, Liam Girdwood, Mark Brown, Krzysztof Kozlowski,
Conor Dooley, Lee Jones, Thomas Petazzoni, linux-omap,
linux-kernel, devicetree
In-Reply-To: <20260330-omap4-fix-usb-support-v2-8-1c1e11b190dc@bootlin.com>
On Mon, Mar 30, 2026 at 03:44:05PM +0200, Thomas Richard wrote:
> Convert OMAP HS USB Host binding to DT schema. The 'ti,hwmods' property is
> not mandatory anymore as it is no longer required when the omap-usb-host
> node is a child of a new interconnect target (ti,sysc).
>
> Signed-off-by: Thomas Richard <thomas.richard@bootlin.com>
> ---
> .../devicetree/bindings/mfd/omap-usb-host.txt | 103 -------------
> .../devicetree/bindings/mfd/ti,omap-usb-host.yaml | 161 +++++++++++++++++++++
> MAINTAINERS | 1 +
> 3 files changed, 162 insertions(+), 103 deletions(-)
>
> diff --git a/Documentation/devicetree/bindings/mfd/omap-usb-host.txt b/Documentation/devicetree/bindings/mfd/omap-usb-host.txt
> deleted file mode 100644
> index a0d8c30c2631..000000000000
> --- a/Documentation/devicetree/bindings/mfd/omap-usb-host.txt
> +++ /dev/null
> @@ -1,103 +0,0 @@
> -OMAP HS USB Host
> -
> -Required properties:
> -
> -- compatible: should be "ti,usbhs-host"
> -- reg: should contain one register range i.e. start and length
> -- ti,hwmods: must contain "usb_host_hs"
> -
> -Optional properties:
> -
> -- num-ports: number of USB ports. Usually this is automatically detected
> - from the IP's revision register but can be overridden by specifying
> - this property. A maximum of 3 ports are supported at the moment.
> -
> -- portN-mode: String specifying the port mode for port N, where N can be
> - from 1 to 3. If the port mode is not specified, that port is treated
> - as unused. When specified, it must be one of the following.
> - "ehci-phy",
> - "ehci-tll",
> - "ehci-hsic",
> - "ohci-phy-6pin-datse0",
> - "ohci-phy-6pin-dpdm",
> - "ohci-phy-3pin-datse0",
> - "ohci-phy-4pin-dpdm",
> - "ohci-tll-6pin-datse0",
> - "ohci-tll-6pin-dpdm",
> - "ohci-tll-3pin-datse0",
> - "ohci-tll-4pin-dpdm",
> - "ohci-tll-2pin-datse0",
> - "ohci-tll-2pin-dpdm",
> -
> -- single-ulpi-bypass: Must be present if the controller contains a single
> - ULPI bypass control bit. e.g. OMAP3 silicon <= ES2.1
> -
> -- clocks: a list of phandles and clock-specifier pairs, one for each entry in
> - clock-names.
> -
> -- clock-names: should include:
> - For OMAP3
> - * "usbhost_120m_fck" - 120MHz Functional clock.
> -
> - For OMAP4+
> - * "refclk_60m_int" - 60MHz internal reference clock for UTMI clock mux
> - * "refclk_60m_ext_p1" - 60MHz external ref. clock for Port 1's UTMI clock mux.
> - * "refclk_60m_ext_p2" - 60MHz external ref. clock for Port 2's UTMI clock mux
> - * "utmi_p1_gfclk" - Port 1 UTMI clock mux.
> - * "utmi_p2_gfclk" - Port 2 UTMI clock mux.
> - * "usb_host_hs_utmi_p1_clk" - Port 1 UTMI clock gate.
> - * "usb_host_hs_utmi_p2_clk" - Port 2 UTMI clock gate.
> - * "usb_host_hs_utmi_p3_clk" - Port 3 UTMI clock gate.
> - * "usb_host_hs_hsic480m_p1_clk" - Port 1 480MHz HSIC clock gate.
> - * "usb_host_hs_hsic480m_p2_clk" - Port 2 480MHz HSIC clock gate.
> - * "usb_host_hs_hsic480m_p3_clk" - Port 3 480MHz HSIC clock gate.
> - * "usb_host_hs_hsic60m_p1_clk" - Port 1 60MHz HSIC clock gate.
> - * "usb_host_hs_hsic60m_p2_clk" - Port 2 60MHz HSIC clock gate.
> - * "usb_host_hs_hsic60m_p3_clk" - Port 3 60MHz HSIC clock gate.
> -
> -Required properties if child node exists:
> -
> -- #address-cells: Must be 1
> -- #size-cells: Must be 1
> -- ranges: must be present
> -
> -Properties for children:
> -
> -The OMAP HS USB Host subsystem contains EHCI and OHCI controllers.
> -See Documentation/devicetree/bindings/usb/generic-ehci.yaml and
> -Documentation/devicetree/bindings/usb/generic-ohci.yaml.
> -
> -Example for OMAP4:
> -
> -usbhshost: usbhshost@4a064000 {
> - compatible = "ti,usbhs-host";
> - reg = <0x4a064000 0x800>;
> - ti,hwmods = "usb_host_hs";
> - #address-cells = <1>;
> - #size-cells = <1>;
> - ranges;
> -
> - usbhsohci: ohci@4a064800 {
> - compatible = "ti,ohci-omap3";
> - reg = <0x4a064800 0x400>;
> - interrupt-parent = <&gic>;
> - interrupts = <0 76 0x4>;
> - };
> -
> - usbhsehci: ehci@4a064c00 {
> - compatible = "ti,ehci-omap";
> - reg = <0x4a064c00 0x400>;
> - interrupt-parent = <&gic>;
> - interrupts = <0 77 0x4>;
> - };
> -};
> -
> -&usbhshost {
> - port1-mode = "ehci-phy";
> - port2-mode = "ehci-tll";
> - port3-mode = "ehci-phy";
> -};
> -
> -&usbhsehci {
> - phys = <&hsusb1_phy 0 &hsusb3_phy>;
> -};
> diff --git a/Documentation/devicetree/bindings/mfd/ti,omap-usb-host.yaml b/Documentation/devicetree/bindings/mfd/ti,omap-usb-host.yaml
> new file mode 100644
> index 000000000000..3b5b041f0321
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/mfd/ti,omap-usb-host.yaml
> @@ -0,0 +1,161 @@
> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/mfd/ti,omap-usb-host.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: OMAP HS USB Host
> +
> +maintainers:
> + - Thomas Richard <thomas.richard@bootlin.com>
> +
> +properties:
> + compatible:
> + const: ti,usbhs-host
> +
> + reg:
> + maxItems: 1
> +
> + ti,hwmods:
> + const: usb_host_hs
> +
> + num-ports:
> + description:
> + number of USB ports. Usually this is automatically detected from the IP's
> + revision register but can be overridden by specifying this property. A
> + maximum of 3 ports are supported at the moment.
> + maximum: 3
> +
> + single-ulpi-bypass:
> + $ref: /schemas/types.yaml#/definitions/flag
> + description:
> + Must be present if the controller contains a single ULPI bypass control
> + bit. e.g. OMAP3 silicon <= ES2.1ULPI bypass control bit.
> + e.g. OMAP3 silicon <= ES2.1.
> +
> + clocks:
> + description: clock-specifier
> +
> + clock-names:
> + oneOf:
> + - items:
> + - const: usbhost_120m_fck
> + - items:
> + - const: refclk_60m_int
> + - const: refclk_60m_ext_p1
> + - const: refclk_60m_ext_p2
> + - items:
> + - const: refclk_60m_int
> + - const: refclk_60m_ext_p1
> + - const: refclk_60m_ext_p2
> + - const: usb_host_hs_utmi_p1_clk
> + - const: usb_host_hs_hsic480m_p1_clk
> + - const: usb_host_hs_hsic60m_p1_clk
> + - items:
> + - const: refclk_60m_int
> + - const: refclk_60m_ext_p1
> + - const: refclk_60m_ext_p2
> + - const: usb_host_hs_utmi_p1_clk
> + - const: usb_host_hs_hsic480m_p1_clk
> + - const: usb_host_hs_hsic60m_p1_clk
> + - const: usb_host_hs_utmi_p2_clk
> + - const: usb_host_hs_hsic480m_p2_clk
> + - const: usb_host_hs_hsic60m_p2_clk
> + - items:
> + - const: refclk_60m_int
> + - const: refclk_60m_ext_p1
> + - const: refclk_60m_ext_p2
> + - const: usb_host_hs_utmi_p1_clk
> + - const: usb_host_hs_hsic480m_p1_clk
> + - const: usb_host_hs_hsic60m_p1_clk
> + - const: usb_host_hs_utmi_p2_clk
> + - const: usb_host_hs_hsic480m_p2_clk
> + - const: usb_host_hs_hsic60m_p2_clk
> + - const: usb_host_hs_utmi_p3_clk
> + - const: usb_host_hs_hsic480m_p3_clk
> + - const: usb_host_hs_hsic60m_p3_clk
All but the first one can be combined to this last entry plus
'minItems: 3'.
> +
> + "#address-cells":
> + const: 1
> +
> + "#size-cells":
> + const: 1
> +
> + ranges: true
> +
> +patternProperties:
> + "^port[0-3]-mode$":
> + $ref: /schemas/types.yaml#/definitions/string
> + description:
> + String specifying the port mode for port N, where N can be from 1 to 3.
> + the port mode is not specified, that port is treated as unused. When
> + specified, it must be one of the following.
> + enum:
> + - ehci-phy
> + - ehci-tll
> + - ehci-hsic
> + - ohci-phy-6pin-datse0
> + - ohci-phy-6pin-dpdm
> + - ohci-phy-3pin-datse0
> + - ohci-phy-4pin-dpdm
> + - ohci-tll-6pin-datse0
> + - ohci-tll-6pin-dpdm
> + - ohci-tll-3pin-datse0
> + - ohci-tll-4pin-dpdm
> + - ohci-tll-2pin-datse0
> + - ohci-tll-2pin-dpdm
> +
> + "^usb@":
> + type: object
> + oneOf:
> + - $ref: /schemas/usb/generic-ohci.yaml#
> + - $ref: /schemas/usb/generic-ehci.yaml#
This causes the schemas to be applied twice and oneOf causes confusing
warnings. Instead just do this:
type: object
properties:
compatible:
contains:
enum:
- ti,ehci-omap
- ti,ohci-omap3
required:
- compatible
> +
> +required:
> + - compatible
> + - reg
> +
> +allOf:
> + - if:
> + patternProperties:
> + "^usb@": true
This will always be true. Unfortunately there's no way to do required
pattern properties in json-schema.
Is it valid to have no usb nodes? I wouldn't think so, so just make
these properties always required.
> + then:
> + required:
> + - ranges
> + - "#address-cells"
> + - "#size-cells"
> +
> +additionalProperties: false
> +
> +examples:
> + - |
> + bus {
> + #address-cells = <1>;
> + #size-cells = <1>;
> +
> + usbhshost: usbhshost@4a064000 {
> + compatible = "ti,usbhs-host";
> + reg = <0x4a064000 0x800>;
> + ti,hwmods = "usb_host_hs";
> + port1-mode = "ehci-phy";
> + port2-mode = "ehci-tll";
> + port3-mode = "ehci-phy";
> + #address-cells = <1>;
> + #size-cells = <1>;
> + ranges;
> +
> + usbhsohci: usb@4a064800 {
> + compatible = "ti,ohci-omap3";
> + reg = <0x4a064800 0x400>;
> + interrupt-parent = <&gic>;
> + interrupts = <0 76 0x4>;
> + };
> +
> + usbhsehci: usb@4a064c00 {
> + compatible = "ti,ehci-omap";
> + reg = <0x4a064c00 0x400>;
> + interrupt-parent = <&gic>;
> + interrupts = <0 77 0x4>;
> + };
> + };
> + };
> diff --git a/MAINTAINERS b/MAINTAINERS
> index 15052c0f5377..d1dadba8ed0a 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -19406,6 +19406,7 @@ W: http://linux.omap.com/
> Q: http://patchwork.kernel.org/project/linux-omap/list/
> T: git git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap.git
> F: Documentation/devicetree/bindings/arm/ti/omap.yaml
> +F: Documentation/devicetree/bindings/mfd/ti,omap-usb-host.yaml
> F: Documentation/devicetree/bindings/regulator/ti,pbias-regulator.yaml
> F: arch/arm/configs/omap2plus_defconfig
> F: arch/arm/mach-omap2/
>
> --
> 2.53.0
>
^ permalink raw reply
* Re: [PATCH v2] net: dsa: microchip: implement KSZ87xx Module 3 low-loss cable errata
From: Andrew Lunn @ 2026-04-08 12:49 UTC (permalink / raw)
To: Fidelio Lawson
Cc: Woojung Huh, UNGLinuxDriver, Vladimir Oltean, David S. Miller,
Eric Dumazet, Jakub Kicinski, Paolo Abeni, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Marek Vasut, Maxime Chevallier,
netdev, devicetree, linux-kernel, Fidelio Lawson
In-Reply-To: <20260408-ksz87xx_errata_low_loss_connections-v2-1-9cfe38691713@exotec.com>
> The register can be read and written from userspace via standard Clause 22 PHY
> accesses (for example using phytool) on DSA user ports.
Please add a phy tunable. .get_tunable/.set_tunable.
Andrew
^ permalink raw reply
* Re: [PATCH v2] net: dsa: microchip: implement KSZ87xx Module 3 low-loss cable errata
From: Andrew Lunn @ 2026-04-08 12:43 UTC (permalink / raw)
To: Fidelio Lawson
Cc: Woojung Huh, UNGLinuxDriver, Vladimir Oltean, David S. Miller,
Eric Dumazet, Jakub Kicinski, Paolo Abeni, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Marek Vasut, Maxime Chevallier,
netdev, devicetree, linux-kernel, Fidelio Lawson
In-Reply-To: <20260408-ksz87xx_errata_low_loss_connections-v2-1-9cfe38691713@exotec.com>
> The control register defines the following modes:
> bits [1:0]:
> 00 = workaround disabled
> 01 = workaround 1 (DSP EQ training adjustment, LinkMD reg 0x3c)
> 10 = workaround 2 (receiver LPF bandwidth, LinkMD reg 0x4c)
There was a comment, which i only read after making the suggestion to
use two bits, of exposing the different low pass filter bandwidths,
rather than just picking one value. How useful is that?
Andrew
^ permalink raw reply
* Re: [PATCH v2 02/11] dt-bindings: regulator: ti,pbias-regulator: Add pbias_sim_omap4 regulator
From: Rob Herring @ 2026-04-08 12:41 UTC (permalink / raw)
To: Thomas Richard
Cc: Krzysztof Kozlowski, Aaro Koskinen, Andreas Kemnade, Kevin Hilman,
Roger Quadros, Tony Lindgren, Liam Girdwood, Mark Brown,
Krzysztof Kozlowski, Conor Dooley, Lee Jones, Thomas Petazzoni,
linux-omap, linux-kernel, devicetree
In-Reply-To: <9d76f827-3967-4ab6-b6f0-77d1bd564278@bootlin.com>
On Wed, Apr 08, 2026 at 09:58:15AM +0200, Thomas Richard wrote:
> Hello Krzysztof,
>
> On 3/31/26 10:22 AM, Krzysztof Kozlowski wrote:
> > On Mon, Mar 30, 2026 at 03:43:59PM +0200, Thomas Richard wrote:
> >> Define pbias_sim_omap4 regulator for OMAP4. This regulators drives SIM_VDDS
> >> supply and allows to unlock USB I/O cell.
> >>
> >> Signed-off-by: Thomas Richard <thomas.richard@bootlin.com>
> >> ---
> >> Documentation/devicetree/bindings/regulator/ti,pbias-regulator.yaml | 1 +
> >> 1 file changed, 1 insertion(+)
> >>
> >> diff --git a/Documentation/devicetree/bindings/regulator/ti,pbias-regulator.yaml b/Documentation/devicetree/bindings/regulator/ti,pbias-regulator.yaml
> >> index 3e020d87701b..908fbb46b5cf 100644
> >> --- a/Documentation/devicetree/bindings/regulator/ti,pbias-regulator.yaml
> >> +++ b/Documentation/devicetree/bindings/regulator/ti,pbias-regulator.yaml
> >> @@ -89,6 +89,7 @@ allOf:
> >> contains:
> >> enum:
> >> - pbias_mmc_omap4
> >> + - pbias_sim_omap4
> >
> > Names cannot be fixed, because they represent different board naming.
> > Why growing the deprecated style?
>
> Okay, so I'll drop all if statements, add a regex which matches
> regulator names and fix the regulator name in the driver.
If a driver depends on the names, you can't change them.
Rob
^ permalink raw reply
* Re: [PATCH v2 01/11] dt-bindings: regulator: ti,pbias-regulator: Convert to DT schema
From: Rob Herring @ 2026-04-08 12:38 UTC (permalink / raw)
To: Thomas Richard
Cc: Krzysztof Kozlowski, Aaro Koskinen, Andreas Kemnade, Kevin Hilman,
Roger Quadros, Tony Lindgren, Liam Girdwood, Mark Brown,
Krzysztof Kozlowski, Conor Dooley, Lee Jones, Thomas Petazzoni,
linux-omap, linux-kernel, devicetree
In-Reply-To: <6b637950-2018-41d8-bdd2-27382a9b67d8@bootlin.com>
On Wed, Apr 08, 2026 at 09:57:20AM +0200, Thomas Richard wrote:
> Hello Krzysztof,
>
> On 3/31/26 10:21 AM, Krzysztof Kozlowski wrote:
> > On Mon, Mar 30, 2026 at 03:43:58PM +0200, Thomas Richard wrote:
> >> +$id: http://devicetree.org/schemas/regulator/ti,pbias-regulator.yaml#
> >> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> >> +
> >> +title: PBIAS internal regulator
> >> +
> >> +maintainers:
> >> + - Thomas Richard <thomas.richard@bootlin.com>
> >> +
> >> +description: |
> >
> > Do not need '|' unless you need to preserve formatting.
> >
> >> + PBIAS internal regulator for SD card dual voltage i/o pads on OMAP SoCs.
> >> +
> >> +properties:
> >> + compatible:
> >> + items:
> >> + - enum:
> >> + - ti,pbias-dra7
> >> + - ti,pbias-omap2
> >> + - ti,pbias-omap3
> >> + - ti,pbias-omap4
> >> + - ti,pbias-omap5
> >> + - const: ti,pbias-omap
> >> +
> >> + reg:
> >> + maxItems: 1
> >> +
> >> + syscon:
> >> + description: Phandle of the system control module
> >> + $ref: /schemas/types.yaml#/definitions/phandle
> >> +
> >> +patternProperties:
> >> + '^pbias_*':
> >
> > That wasn't in old binding and underscore is not allowed, so this needs
> > explanation. Old binding mentioned only the names.
>
> I did it to match existing devicetrees.
> I guess I should define properties like 'pbias-mmc' and 'pbias-sim',
> then update node names in devicetrees to match binding.
For this ancient stuff, I would just leave the dts files alone. Just
explain that in the commit message.
Your pattern should be '^pbias_' though.
Rob
^ permalink raw reply
* Re: [PATCH v2 5/5] arm64: dts: qcom: qcs8550: add QCS8550 RB5Gen2 board support
From: Neil Armstrong @ 2026-04-08 12:35 UTC (permalink / raw)
To: Konrad Dybcio, jsandom, Bjorn Andersson, Konrad Dybcio,
Rob Herring, Krzysztof Kozlowski, Conor Dooley
Cc: linux-arm-msm, devicetree, linux-kernel
In-Reply-To: <4359bb07-d848-4b77-b1a9-f1c6f53caa10@oss.qualcomm.com>
On 4/8/26 11:57, Konrad Dybcio wrote:
> On 4/7/26 5:46 PM, Joe Sandom via B4 Relay wrote:
>> From: Joe Sandom <jsandom@axon.com>
>>
>> The RB5gen2 is an embedded development platform for the
>> QCS8550, based on the Snapdragon 8 Gen 2 SoC (SM8550).
>
> [...]
>
>
>> + /* Lontium LT9611UXC fails FW upgrade and has timeouts with geni-i2c */
>> + /* Workaround is to use bit-banged I2C */
>
> Interesting.. I was under the impression that it was only an issue on
> RB1 and RB2 boards.. perhaps we're missing some magic register write..
On the SM8650-HDK, the HDMI i2c is shared with the battmgr in ADSP, causing a lot
of issues... the only solution is [1] to declare the bus shared and use GPI DMA.
I assume it's the same here.
Sharing the same bus between APPS and ADSP is a weird feat... It seems that having
26 i2c busses and 212 gpios available on the system is not enough.
[1] https://lore.kernel.org/all/20241129144357.2008465-1-quic_msavaliy@quicinc.com/
>
>
> [...]
>
>> + pinctrl-names = "default";
>> + pinctrl-0 = <&wlan_en>, <&bt_default>, <&sw_ctrl_default>,
>> + <&pmk8550_sleep_clk>;
>
> nit: let's keep the order of
>
> property-n
> property-names
>
> file-wide
>
> [...]
>
>> +&sdhc_2 {
>> + cd-gpios = <&pm8550_gpios 12 GPIO_ACTIVE_LOW>;
>> +
>> + pinctrl-0 = <&sdc2_default>, <&sdc2_card_det_n>;
>> + pinctrl-1 = <&sdc2_sleep>, <&sdc2_card_det_n>;
>> + pinctrl-names = "default", "sleep";
>> +
>> + vmmc-supply = <&vreg_l9b_2p9>;
>> + vqmmc-supply = <&vreg_l8b_1p8>;
>> +
>> + max-sd-hs-hz = <37000000>;
>
> Are you sure you want to overwrite that? The value in the SoC DTSI is
> set to half a MHz higher
>
>
>> +
>> + no-sdio;
>> + no-mmc;
>> +
>> + status = "okay";
>> +};
>> +
>> +&sleep_clk {
>> + clock-frequency = <32764>;
>> +};
>> +
>> +&spi11 {
>> + status = "okay";
>> +
>> + can@0 {
>> + compatible = "microchip,mcp2518fd";
>> + reg = <0>;
>> + interrupts-extended = <&tlmm 55 IRQ_TYPE_LEVEL_LOW>;
>> + clocks = <&clk40m>;
>> + spi-max-frequency = <10000000>;
>> + vdd-supply = <&vreg_l14b_3p2>;
>> + xceiver-supply = <&vreg_l14b_3p2>;
>
> It may be that for this chip to actually be able to communiate with devices
> on the bus, you need to set the new 'microchip,xstbyen' property
>
> see:
>
> https://lore.kernel.org/linux-arm-msm/20260321135031.3107408-1-viken.dadhaniya@oss.qualcomm.com/
>
> [...]
>
>> +&tlmm {
>> + gpio-reserved-ranges = <32 8>;
>
> Would you happen to know what these pins are connected to, and if
> so, add a comment (like in arch/arm64/boot/dts/qcom/x1-crd.dtsi)?
>
>
>
>> +
>> + bt_default: bt-default-state {
>> + pins = "gpio81";
>
> It would be best to keep these entries ordered by pin idx
>
>> + function = "gpio";
>> + drive-strength = <16>;
>> + bias-disable;
>> + };
>> +
>> + sw_ctrl_default: sw-ctrl-default-state {
>> + pins = "gpio82";
>> + function = "gpio";
>> + bias-pull-down;
>> + };
>> +
>> + lt9611_irq_pin: lt9611-irq-state {
>> + pins = "gpio40";
>> + function = "gpio";
>> + bias-disable;
>> + };
>> +
>> + lt9611_rst_pin: lt9611-rst-state {
>> + pins = "gpio7";
>> + function = "gpio";
>> + output-high;
>
> You shouldn't need to assert the GPIO state in the pin entry node
> - the driver should take care of that
>
>
>> + };
>> +
>> + ntn0_en: ntn0-en-state {
>> + pins = "gpio67";
>> + function = "gpio";
>> + drive-strength = <2>;
>> + bias-disable;
>> + };
>> +
>> + ntn1_en: ntn1-en-state {
>> + pins = "gpio42";
>> + function = "gpio";
>> + drive-strength = <2>;
>> + bias-disable;
>> + };
>> +
>> + upd_1p05_en: upd-1p05-en-state {
>> + pins = "gpio179";
>> + function = "gpio";
>> + drive-strength = <2>;
>> + bias-pull-up;
>> + };
>
> I don't know if pulling up an active-high pin is what you want
> (there's some more occurences)
>
> Konrad
^ permalink raw reply
* Re: [PATCH v12 2/2] arm: dts: aspeed: ventura: add Meta Ventura BMC
From: Andrew Lunn @ 2026-04-08 12:34 UTC (permalink / raw)
To: P.K. Lee
Cc: robh+dt, krzysztof.kozlowski+dt, conor+dt, joel, andrew,
devicetree, linux-arm-kernel, linux-aspeed, linux-kernel,
Jason-Hsu, p.k.lee
In-Reply-To: <CAK8yEOAYC0iApNHBApt+xu1Fz=+N1wX0XrLGOPzmeRq=OjWnhg@mail.gmail.com>
> > > > If there are no devices on the bus, why enable it?
> > >
> > > We intentionally enable it so user-space tools can access the switch
> > > registers. I have added a comment in v13 to clarify this.
> >
> > Why would user space want to access the switch registers for an
> > unmanaged switch? It sounds like you are using Marvells SDK in
> > userspace to manage the switch, rather than using DSA.
> >
>
> We do have a custom user-space daemon that configures the switch
> registers for our specific use case. Should I remove the &mdio0 node
> if it is only enabled and has no other configuration in the upstream
> device tree?
Please just be truthful that you have a user space driver, so need the
bus enabled.
I also guess you have some other kernel code that allows you to
actually use the bus from user space? The typical ethernet IOCTL
handler does not work for you, since you don't have an ethernet device
using this bus. Such code is unlikely to be accepted into mainline. We
don't like user space drivers when there is a perfectly good kernel
driver for this switch.
Andrew
^ permalink raw reply
* Re: [PATCH v6 13/21] drm: renesas: rz-du: mipi_dsi: Add RZ_MIPI_DSI_FEATURE_GPO0R feature
From: Laurent Pinchart @ 2026-04-08 12:31 UTC (permalink / raw)
To: Tommaso Merciai
Cc: tomm.merciai, geert, linux-renesas-soc, biju.das.jz,
Maarten Lankhorst, Maxime Ripard, Thomas Zimmermann, David Airlie,
Simona Vetter, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Geert Uytterhoeven, Michael Turquette, Stephen Boyd, Magnus Damm,
Tomi Valkeinen, dri-devel, devicetree, linux-kernel, linux-clk
In-Reply-To: <9e0f64dd5e1efb0d27219416121c91a19da96ebd.1775636898.git.tommaso.merciai.xr@bp.renesas.com>
On Wed, Apr 08, 2026 at 12:36:58PM +0200, Tommaso Merciai wrote:
> The MIPI DSI ip found in the RZ/G3E SoC select the video input clock
> based on the DU instance actually connected using the GPO0R register.
>
> Add this feature to the driver using `RZ_MIPI_DSI_FEATURE_GPO0R`, update
> the code accordingly to manage the vclk selection with the introduction
> of `rzg2l_mipi_dsi_get_input_port()`.
>
> Signed-off-by: Tommaso Merciai <tommaso.merciai.xr@bp.renesas.com>
> ---
> v5->v6:
> - Moved rzg2l_mipi_dsi_link_write() into rzv2h_mipi_dsi_dphy_init()
> + comments from HW Manual.
>
> v4->v5:
> - No changes.
>
> v3->v4:
> - No changes.
>
> v2->v3:
> - No changes.
>
> v1->v2:
> - No changes.
>
> .../gpu/drm/renesas/rz-du/rzg2l_mipi_dsi.c | 71 +++++++++++++++++--
> .../drm/renesas/rz-du/rzg2l_mipi_dsi_regs.h | 3 +
> 2 files changed, 68 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/gpu/drm/renesas/rz-du/rzg2l_mipi_dsi.c b/drivers/gpu/drm/renesas/rz-du/rzg2l_mipi_dsi.c
> index be6dbf19a24e..947c8e15fc4b 100644
> --- a/drivers/gpu/drm/renesas/rz-du/rzg2l_mipi_dsi.c
> +++ b/drivers/gpu/drm/renesas/rz-du/rzg2l_mipi_dsi.c
> @@ -37,7 +37,9 @@ MODULE_IMPORT_NS("RZV2H_CPG");
>
> #define RZG2L_DCS_BUF_SIZE 128 /* Maximum DCS buffer size in external memory. */
>
> +#define RZ_MIPI_DSI_MAX_INPUT 2
> #define RZ_MIPI_DSI_FEATURE_16BPP BIT(0)
> +#define RZ_MIPI_DSI_FEATURE_GPO0R BIT(1)
>
> struct rzg2l_mipi_dsi;
>
> @@ -81,13 +83,14 @@ struct rzg2l_mipi_dsi {
> struct drm_bridge bridge;
> struct drm_bridge *next_bridge;
>
> - struct clk *vclk;
> + struct clk *vclk[RZ_MIPI_DSI_MAX_INPUT];
> struct clk *lpclk;
>
> enum mipi_dsi_pixel_format format;
> unsigned int num_data_lanes;
> unsigned int lanes;
> unsigned long mode_flags;
> + u8 vclk_idx;
>
> struct rzv2h_dsi_mode_calc mode_calc;
>
> @@ -543,8 +546,8 @@ static int rzg2l_dphy_conf_clks(struct rzg2l_mipi_dsi *dsi, unsigned long mode_f
> unsigned long vclk_rate;
> unsigned int bpp;
>
> - clk_set_rate(dsi->vclk, mode_freq * KILO);
> - vclk_rate = clk_get_rate(dsi->vclk);
> + clk_set_rate(dsi->vclk[dsi->vclk_idx], mode_freq * KILO);
> + vclk_rate = clk_get_rate(dsi->vclk[dsi->vclk_idx]);
> if (vclk_rate != mode_freq * KILO)
> dev_dbg(dsi->dev, "Requested vclk rate %lu, actual %lu mismatch\n",
> mode_freq * KILO, vclk_rate);
> @@ -687,6 +690,19 @@ static int rzv2h_mipi_dsi_dphy_init(struct rzg2l_mipi_dsi *dsi,
> rzg2l_mipi_dsi_phy_write(dsi, PLLCLKSET1R,
> FIELD_PREP(PLLCLKSET1R_PLL_K, dsi_parameters->k));
>
> + /*
> + * From RZ/G3E HW manual (Rev.1.15) section 9.5.3 Operation,
> + * 9.5.3.1 Power on Reset and Initial Settings for All Operations.
> + * Figure 9.5-4 Power On/Off Sequence show that after writing to
> + * GPO0R.VICH register we need to wait for more than 1 x tp before
> + * writing to PLLENR.PLLEN.
> + *
> + * Note: GPO0R is a link register, not a PHY register. This setting
> + * is specific to RZ/G3E.
> + */
> + if (dsi->info->features & RZ_MIPI_DSI_FEATURE_GPO0R)
> + rzg2l_mipi_dsi_link_write(dsi, GPO0R, dsi->vclk_idx);
> +
> /*
> * From RZ/V2H HW manual (Rev.1.20) section 9.5.3 Operation,
> * (C) After write to D-PHY registers we need to wait for more than 1 x tp
> @@ -1005,6 +1021,37 @@ static int rzg2l_mipi_dsi_stop_video(struct rzg2l_mipi_dsi *dsi)
> return ret;
> }
>
> +static int rzg2l_mipi_dsi_get_input_port(struct rzg2l_mipi_dsi *dsi)
> +{
> + struct device_node *np = dsi->dev->of_node;
> + struct device_node *remote_ep, *ep_node;
> + struct of_endpoint ep;
> + bool ep_enabled;
> + int in_port;
> +
> + /* DSI can have only one port enabled */
Why is that ? The hardware supports dynamic input selection, why can't
it be supported at runtime ?
> + for_each_endpoint_of_node(np, ep_node) {
> + of_graph_parse_endpoint(ep_node, &ep);
> + if (ep.port >= RZ_MIPI_DSI_MAX_INPUT)
> + break;
> +
> + remote_ep = of_graph_get_remote_endpoint(ep_node);
> + ep_enabled = of_device_is_available(remote_ep);
> + of_node_put(remote_ep);
> +
> + if (ep_enabled) {
> + in_port = ep.port;
> + break;
> + }
> + }
> +
> + if (!ep_enabled)
> + return -EINVAL;
> +
> + dev_dbg(dsi->dev, "input port@%d\n", in_port);
> + return in_port;
> +}
> +
> /* -----------------------------------------------------------------------------
> * Bridge
> */
> @@ -1425,9 +1472,21 @@ static int rzg2l_mipi_dsi_probe(struct platform_device *pdev)
> if (IS_ERR(dsi->mmio))
> return PTR_ERR(dsi->mmio);
>
> - dsi->vclk = devm_clk_get(dsi->dev, "vclk");
> - if (IS_ERR(dsi->vclk))
> - return PTR_ERR(dsi->vclk);
> + dsi->vclk[0] = devm_clk_get(dsi->dev, "vclk");
> + if (IS_ERR(dsi->vclk[0]))
> + return PTR_ERR(dsi->vclk[0]);
> +
> + if (dsi->info->features & RZ_MIPI_DSI_FEATURE_GPO0R) {
> + dsi->vclk[1] = devm_clk_get(dsi->dev, "vclk2");
> + if (IS_ERR(dsi->vclk[1]))
> + return PTR_ERR(dsi->vclk[1]);
> +
> + ret = rzg2l_mipi_dsi_get_input_port(dsi);
> + if (ret < 0)
> + return dev_err_probe(dsi->dev, -EINVAL,
> + "No available input port\n");
> + dsi->vclk_idx = ret;
> + }
>
> dsi->lpclk = devm_clk_get(dsi->dev, "lpclk");
> if (IS_ERR(dsi->lpclk))
> diff --git a/drivers/gpu/drm/renesas/rz-du/rzg2l_mipi_dsi_regs.h b/drivers/gpu/drm/renesas/rz-du/rzg2l_mipi_dsi_regs.h
> index 2bef20566648..cee2e0bc5dc5 100644
> --- a/drivers/gpu/drm/renesas/rz-du/rzg2l_mipi_dsi_regs.h
> +++ b/drivers/gpu/drm/renesas/rz-du/rzg2l_mipi_dsi_regs.h
> @@ -83,6 +83,9 @@
> #define LINKSR_SQCHRUN1 BIT(4)
> #define LINKSR_SQCHRUN0 BIT(0)
>
> +/* RZ/G3E General Purpose Output 0 Register */
> +#define GPO0R 0xc0
> +
> /* Tx Set Register */
> #define TXSETR 0x100
> #define TXSETR_NUMLANECAP (0x3 << 16)
--
Regards,
Laurent Pinchart
^ permalink raw reply
* Re: [PATCH v6 12/21] drm: renesas: rz-du: mipi_dsi: Add out_port to OF data
From: Laurent Pinchart @ 2026-04-08 12:30 UTC (permalink / raw)
To: Tommaso Merciai
Cc: tomm.merciai, geert, linux-renesas-soc, biju.das.jz,
Maarten Lankhorst, Maxime Ripard, Thomas Zimmermann, David Airlie,
Simona Vetter, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Geert Uytterhoeven, Michael Turquette, Stephen Boyd, Magnus Damm,
Tomi Valkeinen, dri-devel, devicetree, linux-kernel, linux-clk
In-Reply-To: <d4d1d75183944f17d392256d9123523a6bd1a3c0.1775636898.git.tommaso.merciai.xr@bp.renesas.com>
On Wed, Apr 08, 2026 at 12:36:57PM +0200, Tommaso Merciai wrote:
> Add `out_port` field to the `rzg2l_mipi_dsi_hw_info` structure to store
> the DSI output port index. RZ/G2L and RZ/V2H(P) use port 1 for DSI
> output, while RZ/G3E uses port 2.
>
> Update `rzg2l_mipi_dsi_host_attach()` and `rzg2l_mipi_dsi_probe()` to
> use this `out_port` from the OF data, facilitating future support for
> RZ/G3E SoC.
>
> Signed-off-by: Tommaso Merciai <tommaso.merciai.xr@bp.renesas.com>
Another option would be to add the second input port for G3E as port@2,
keeping port@1 as the output port on all SoCs. Both options work.
Reviewed-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
> ---
> v5->v6:
> - No changes.
>
> v4->v5:
> - No changes.
>
> v3->v4:
> - No changes.
>
> v2->v3:
> - No changes.
>
> v1->v2:
> - No changes.
>
> drivers/gpu/drm/renesas/rz-du/rzg2l_mipi_dsi.c | 9 +++++++--
> 1 file changed, 7 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/renesas/rz-du/rzg2l_mipi_dsi.c b/drivers/gpu/drm/renesas/rz-du/rzg2l_mipi_dsi.c
> index 715872130780..be6dbf19a24e 100644
> --- a/drivers/gpu/drm/renesas/rz-du/rzg2l_mipi_dsi.c
> +++ b/drivers/gpu/drm/renesas/rz-du/rzg2l_mipi_dsi.c
> @@ -58,6 +58,7 @@ struct rzg2l_mipi_dsi_hw_info {
> u32 link_reg_offset;
> unsigned long min_dclk;
> unsigned long max_dclk;
> + u8 out_port;
> u8 features;
> };
>
> @@ -1158,7 +1159,7 @@ static int rzg2l_mipi_dsi_host_attach(struct mipi_dsi_host *host,
> dsi->mode_flags = device->mode_flags;
>
> dsi->next_bridge = devm_drm_of_get_bridge(dsi->dev, dsi->dev->of_node,
> - 1, 0);
> + dsi->info->out_port, 0);
> if (IS_ERR(dsi->next_bridge)) {
> ret = PTR_ERR(dsi->next_bridge);
> dev_err(dsi->dev, "failed to get next bridge: %d\n", ret);
> @@ -1411,7 +1412,9 @@ static int rzg2l_mipi_dsi_probe(struct platform_device *pdev)
>
> dsi->info = of_device_get_match_data(&pdev->dev);
>
> - ret = drm_of_get_data_lanes_count_ep(dsi->dev->of_node, 1, 0, 1, 4);
> + ret = drm_of_get_data_lanes_count_ep(dsi->dev->of_node,
> + dsi->info->out_port,
> + 0, 1, 4);
> if (ret < 0)
> return dev_err_probe(dsi->dev, ret,
> "missing or invalid data-lanes property\n");
> @@ -1525,6 +1528,7 @@ static const struct rzg2l_mipi_dsi_hw_info rzv2h_mipi_dsi_info = {
> .link_reg_offset = 0,
> .min_dclk = 5440,
> .max_dclk = 187500,
> + .out_port = 1,
> .features = RZ_MIPI_DSI_FEATURE_16BPP,
> };
>
> @@ -1535,6 +1539,7 @@ static const struct rzg2l_mipi_dsi_hw_info rzg2l_mipi_dsi_info = {
> .link_reg_offset = 0x10000,
> .min_dclk = 5803,
> .max_dclk = 148500,
> + .out_port = 1,
> };
>
> static const struct of_device_id rzg2l_mipi_dsi_of_table[] = {
--
Regards,
Laurent Pinchart
^ permalink raw reply
* Re: [PATCH] media: dt-bindings: media: renesas,fcp: Document RZ/G3L FCPVD IP
From: Rob Herring (Arm) @ 2026-04-08 12:29 UTC (permalink / raw)
To: Biju
Cc: Mauro Carvalho Chehab, Geert Uytterhoeven, linux-kernel,
Krzysztof Kozlowski, Magnus Damm, Prabhakar Mahadev Lad,
Conor Dooley, devicetree, linux-renesas-soc, Laurent Pinchart,
Biju Das, linux-media
In-Reply-To: <20260330110012.131273-1-biju.das.jz@bp.renesas.com>
On Mon, 30 Mar 2026 12:00:10 +0100, Biju wrote:
> From: Biju Das <biju.das.jz@bp.renesas.com>
>
> The FCPVD block on the RZ/G3L SoC is identical to the one found on the
> RZ/G2L SoC. Document RZ/G3L FCPVD IP.
>
> Signed-off-by: Biju Das <biju.das.jz@bp.renesas.com>
> ---
> Documentation/devicetree/bindings/media/renesas,fcp.yaml | 2 ++
> 1 file changed, 2 insertions(+)
>
Acked-by: Rob Herring (Arm) <robh@kernel.org>
^ permalink raw reply
* Re: [PATCH] media: dt-bindings: media: renesas,vsp1: Document RZ/G3L VSPD
From: Rob Herring (Arm) @ 2026-04-08 12:29 UTC (permalink / raw)
To: Biju
Cc: linux-renesas-soc, Conor Dooley, Geert Uytterhoeven,
Prabhakar Mahadev Lad, Mauro Carvalho Chehab, Biju Das,
devicetree, Magnus Damm, linux-media, Kieran Bingham,
Laurent Pinchart, linux-kernel, Krzysztof Kozlowski
In-Reply-To: <20260330105637.130189-1-biju.das.jz@bp.renesas.com>
On Mon, 30 Mar 2026 11:56:29 +0100, Biju wrote:
> From: Biju Das <biju.das.jz@bp.renesas.com>
>
> The VSPD block on the RZ/G3L SoC is identical to the one found on the
> RZ/G2L SoC. Document RZ/G3L VSPD.
>
> Signed-off-by: Biju Das <biju.das.jz@bp.renesas.com>
> ---
> Documentation/devicetree/bindings/media/renesas,vsp1.yaml | 1 +
> 1 file changed, 1 insertion(+)
>
Acked-by: Rob Herring (Arm) <robh@kernel.org>
^ permalink raw reply
* Re: [PATCH 2/4] ASoC: dt-bindings: Add support for the GPIOs driven amplifier
From: Rob Herring @ 2026-04-08 12:29 UTC (permalink / raw)
To: Herve Codina
Cc: Liam Girdwood, Mark Brown, Krzysztof Kozlowski, Conor Dooley,
Saravana Kannan, Jaroslav Kysela, Takashi Iwai, linux-sound,
devicetree, linux-kernel, Christophe Leroy, Thomas Petazzoni
In-Reply-To: <20260330101610.57942-3-herve.codina@bootlin.com>
On Mon, Mar 30, 2026 at 12:16:06PM +0200, Herve Codina wrote:
> Some amplifiers based on analog switches and op-amps can be present in
> the audio path and can be driven by GPIOs in order to control their gain
> value, their mute and/or bypass functions.
>
> Those components needs to be viewed as audio components in order to be
> fully integrated in the audio path.
>
> audio-gpio-amplifier allows to consider these GPIO driven amplifiers as
> auxiliary audio devices.
>
> Signed-off-by: Herve Codina <herve.codina@bootlin.com>
> ---
> .../bindings/sound/audio-gpio-amp.yaml | 309 ++++++++++++++++++
> 1 file changed, 309 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/sound/audio-gpio-amp.yaml
>
> diff --git a/Documentation/devicetree/bindings/sound/audio-gpio-amp.yaml b/Documentation/devicetree/bindings/sound/audio-gpio-amp.yaml
> new file mode 100644
> index 000000000000..15dc898f8574
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/sound/audio-gpio-amp.yaml
> @@ -0,0 +1,309 @@
> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/sound/audio-gpio-amp.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: Audio amplifier driven by GPIOs
> +
> +maintainers:
> + - Herve Codina <herve.codina@bootlin.com>
> +
> +description: |
> + Audio GPIO amplifiers are driven by GPIO in order to control the gain value
> + of the amplifier, its mute function and/or its bypass function.
> +
> + Those amplifiers are based on discrete components (analog switches, op-amps
> + and more) where some of them, mostly analog switches, are controlled by GPIOs
> + to adjust the gain value of the whole amplifier and/or to control
> + the mute and/or bypass function.
> +
> + For instance, the following piece of hardware is a GPIO amplifier
> +
> + +5VA
> + ^
> + |\ |
> + | \
> + Vin >---------------------------|+ \
> + | +-------+-----> Vout
> + .--\/\/\/--+------------|- / |
> + | | | / |
> + v | |/ | |
> + GND o v |
> + \ GND |
> + gpio >-----------> \ |
> + o o |
> + | | |
> + | '--\/\/\/--. |
> + | +--\/\/\/--'
> + '---------------'
> +
> + A GPIO driven amplifier can work in several mode depending on the electronic
> + design.
> + - points defined:
> + The values of GPIOs used to control gain set a specific gain value
> + without any specific relationship between each value. For instance,
> + using 2 GPIOS:
> + 0b00 <-> -10.0 dB
> + 0b01 <-> +3.0 dB
> + 0b10 <-> 0 dB
> + 0b11 <-> +6.0 dB
> +
> + This can be described using the gain-points property.
> +
> + - range defined:
> + The values of GPIOs used to control gain set a specific gain value
> + following a linear dB range from a minimum dB value to a maximum dB
> + value. For instance, using 2 GPIOS:
> + 0b00 <-> -3.0 dB
> + 0b01 <-> 0 db
> + 0b10 <-> +3.0 dB
> + 0b11 <-> +6.0 dB
> +
> + This can be described using the gain-range property.
> +
> + - labels defined:
> + Some electronic design are not meant to a specific dB gain value. In
> + that case it is relevant to use labels to describe them. For instance,
> + using 2 GPIOS:
> + 0b00 <-> Low boost
> + 0b01 <-> Middle boost
> + 0b10 <-> High boost
> + 0b11 <-> Max boost
> +
> + This can be described using the gain-labels property
> +
> +properties:
> + compatible:
> + const: audio-gpio-amp
To be consistent with other GPIO controlled devices: gpio-audio-amp
> +
> + vdd-supply:
> + description: Main power supply of the amplifier
> +
> + vddio-supply:
> + description: Power supply related to the control path
> +
> + vdda1-supply:
> + description: Analog power supply
> +
> + vdda2-supply:
> + description: Additional analog power supply
> +
> + mute-gpios:
> + description: GPIO to control the mute function
> + maxItems: 1
> +
> + bypass-gpios:
> + description: GPIO to control the bypass function
> + maxItems: 1
> +
> + gain-gpios:
> + description: |
> + GPIOs to control the amplifier gain
> +
> + The gain value is computed from GPIOs value from 0 to 2^N-1 with N the
> + number of GPIO described. The first GPIO described is the lsb of the gain
> + value.
> +
> + For instance assuming 2 gpios
> + gain-gpios = <&gpio1 GPIO_ACTIVE_HIGH> <&gpio2 GPIO_ACTIVE_HIGH>;
> + The gain value will be the following:
> +
> + gpio1 | gpio2 | gain
> + ------+-------+-----
> + 0 | 0 | 0b00 -> 0
> + 1 | 0 | 0b01 -> 1
> + 0 | 1 | 0b10 -> 2
> + 1 | 1 | 0b11 -> 3
> + ------+-------+-----
> +
> + Note: The gain value, bits set to 1 or 0, indicate the state active (bit
> + set) or the state inactive (bit unset) of the related GPIO. The
> + physical voltage corresponding to this active/inactive state is
> + given by the GPIO_ACTIVE_HIGH and GPIO_ACTIVE_LOW flags.
> +
> + minItems: 1
> + maxItems: 32
2^32 levels? Seems like a bit much. Also, unless you can change the
values of all the GPIOs atomically, aren't you going to get some
artifacts while the gain is being changed? Unless you mute I guess.
> +
> + gain-points:
> + $ref: /schemas/types.yaml#/definitions/int32-matrix
> + items:
> + items:
> + - description: The GPIOs value
Can't this just be the index?
If not, then gain-range could be expressed using gain-points instead.
> + - description: The related amplifier gain in 0.01 dB unit
> + minItems: 2
> + description: |
> + List of the GPIOs value / Gain value in dB pair defining the gain
> + set on each GPIOs value.
> +
> + With 2 GPIOs controlling the gain, GPIOs value can be 0, 1, 2 and 3.
> + Assuming that GPIOs values set the hardware gains according to the
> + following table:
> +
> + GPIOs | Hardware
> + value | amplification
> + ------+--------------
> + 0 | -10.0 dB
> + 1 | +3.0 dB
> + 2 | 0 dB
> + 3 | +6.0 dB
> + ------+--------------
> +
> + The description using gain points can be:
> + gain-points = <0 (-1000)>, <1 300>, <2 0>, <3 600>;
> +
> + gain-range:
> + $ref: /schemas/types.yaml#/definitions/int32-array
> + items:
> + - description: Gain in 0.01 dB unit when all GPIOs are inactive
> + - description: Gain in 0.01 dB unit when all GPIOs are active
> + description: |
> + Gains (in 0.01 dB unit) set by the extremum (minimal and maximum) value
> + of GPIOs. The following formula must be satisfied.
> +
> + gain-range[1] - gain-range[0]
> + Gain = ------------------------------- x GPIO_value + gain-range[0]
> + 2^N - 1
> +
> + With N, the number of GPIOs used to control the gain and Gain computed in
> + 0.01 dB unit.
> +
> + With 2 GPIOs controlling the gain, GPIOs value can be 0, 1, 2 and 3.
> + Assuming that gain value set the hardware according to the following
> + table:
> +
> + GPIOs | Hardware 1 | Hardware 2
> + value | amplification | amplification
> + ------+---------------+---------------
> + 0 | -3.0 dB | +10.0 dB
> + 1 | 0 dB | +5.0 dB
> + 2 | +3.0 dB | 0 dB
> + 3 | +6.0 dB | -5.0 dB
> + ------+---------------+---------------
> +
> + The description for hardware 1 using a gain range can be:
> + gain-range = <(-300) 600>;
> +
> + The description for hardware 2 using a gain range can be:
> + gain-range = <1000 (-500)>;
> +
> + gain-labels:
> + $ref: /schemas/types.yaml#/definitions/string-array
minItems: 2
maxItems: 0x100000000
> + description: |
> + List of the gain labels attached to the combination of GPIOs controlling
> + the gain. The first label is related to the gain value 0, the second label
> + is related to the gain value 1 and so on.
> +
> + With 2 GPIOs controlling the gain, GPIOs value can be 0, 1, 2 and 3.
> + Assuming that gain value set the hardware according to the following
> + table:
> +
> + GPIOs | Hardware
> + value | amplification
> + ------+--------------
> + 0 | Low
> + 1 | Middle
> + 2 | High
> + 3 | Max
> + ------+--------------
> +
> + The description using gain labels can be:
> + gain-labels = "Low", "Middle", "High", "Max";
Do we need to allow these to be anything? It's going to get hard to come
up with 2^32 names.
> +
> +dependencies:
> + gain-points: [ gain-gpios ]
> + gain-range: [ gain-gpios ]
> + gain-labels: [ gain-gpios ]
gain-gpios is really optional?
> +
> +required:
> + - compatible
> + - vdd-supply
> +
> +anyOf:
> + - required:
> + - gain-gpios
> + - required:
> + - mute-gpios
> + - required:
> + - bypass-gpios
> +
> +allOf:
> + - $ref: dai-common.yaml#
> + - if:
> + required:
> + - gain-points
> + then:
> + properties:
> + gain-range: false
> + gain-labels: false
> + - if:
> + required:
> + - gain-range
> + then:
> + properties:
> + gain-points: false
> + gain-labels: false
> + - if:
> + required:
> + - gain-labels
> + then:
> + properties:
> + gain-points: false
> + gain-range: false
> +
> +unevaluatedProperties: false
> +
> +examples:
> + - |
> + #include <dt-bindings/gpio/gpio.h>
> +
> + /* Gain controlled by gpios */
> + amplifier0 {
amplifier-0
> + compatible = "audio-gpio-amp";
> + vdd-supply = <®ulator>;
> + gain-gpios = <&gpio 0 GPIO_ACTIVE_HIGH>, <&gpio 1 GPIO_ACTIVE_HIGH>;
> + };
> +
> + /* Gain controlled by gpio using range */
> + amplifier1 {
> + compatible = "audio-gpio-amp";
> + vdd-supply = <®ulator>;
> + gain-gpios = <&gpio 0 GPIO_ACTIVE_HIGH>, <&gpio 1 GPIO_ACTIVE_HIGH>;
> + gain-range = <(-300) 600>;
> + };
> +
> + /* Gain controlled by gpio using points */
> + amplifier2 {
> + compatible = "audio-gpio-amp";
> + vdd-supply = <®ulator>;
> + gain-gpios = <&gpio 0 GPIO_ACTIVE_HIGH>, <&gpio 1 GPIO_ACTIVE_HIGH>;
> + gain-points = <0 (-1000)>, <1 300>, <2 0>, <3 600>;
> + };
> +
> + /* Gain controlled by gpio with labels */
> + amplifier3 {
> + compatible = "audio-gpio-amp";
> + vdd-supply = <®ulator>;
> + gain-gpios = <&gpio 0 GPIO_ACTIVE_HIGH>;
> + gain-labels = "Low", "High";
> + };
> +
> + /* A mutable amplifier without any gain control */
> + amplifier4 {
> + compatible = "audio-gpio-amp";
> + vdd-supply = <®ulator>;
> + mute-gpios = <&gpio 0 GPIO_ACTIVE_HIGH>;
This case is just simple-amplifier...
> + };
> +
> + /* Several supplies, gain controlled using range, mute and bypass */
> + amplifier5 {
> + compatible = "audio-gpio-amp";
> + vdd-supply = <®ulator>;
> + vddio-supply = <®ulator1>;
> + vdda1-supply = <®ulator2>;
> + gain-gpios = <&gpio 0 GPIO_ACTIVE_HIGH>, <&gpio 1 GPIO_ACTIVE_HIGH>;
> + gain-range = <(-300) 600>;
> + mute-gpios = <&gpio 2 GPIO_ACTIVE_HIGH>;
> + bypass-gpios = <&gpio 3 GPIO_ACTIVE_HIGH>;
> + };
> +...
> --
> 2.53.0
>
^ permalink raw reply
* Re: [PATCH v6 10/21] dt-bindings: display: renesas,rzg2l-du: Add support for RZ/G3E SoC
From: Laurent Pinchart @ 2026-04-08 12:24 UTC (permalink / raw)
To: Tommaso Merciai
Cc: tomm.merciai, geert, linux-renesas-soc, biju.das.jz,
Maarten Lankhorst, Maxime Ripard, Thomas Zimmermann, David Airlie,
Simona Vetter, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Geert Uytterhoeven, Michael Turquette, Stephen Boyd, Magnus Damm,
Tomi Valkeinen, dri-devel, devicetree, linux-kernel, linux-clk
In-Reply-To: <8f814f22ff62dcde6153260e2c8c29a5415c9a89.1775636898.git.tommaso.merciai.xr@bp.renesas.com>
On Wed, Apr 08, 2026 at 12:36:55PM +0200, Tommaso Merciai wrote:
> The RZ/G3E SoC has 2 LCD controllers (LCDC), each containing a Frame
> Compression Processor (FCPVD), a Video Signal Processor (VSPD), and a
> Display Unit (DU).
>
> - LCDC0 supports DSI and LVDS (single or dual-channel) outputs.
> - LCDC1 supports DSI, LVDS (single-channel), and RGB outputs.
>
> Add a new SoC-specific compatible string 'renesas,r9a09g047-du'.
>
> Extend patternProperties from "^port@[0-1]$" to "^port@[0-3]$" to
> allow up to four output ports, and explicitly disable port@2 and port@3
> for existing SoCs that do not expose them.
>
> Describe the four output ports of the RZ/G3E DU:
>
> - port@0: DSI (available on both LCDC instances)
> - port@1: DPAD / parallel RGB (LCDC1 only)
> - port@2: LVDS channel 0 (LCDC0 only)
> - port@3: LVDS channel 1 (available on both LCDC instances)
>
> Signed-off-by: Tommaso Merciai <tommaso.merciai.xr@bp.renesas.com>
> ---
> v5->v6:
> - Extend patternProperties from "^port@[0-1]$" to "^port@[0-3]$" and
> explicitly disable port@2 and port@3 for existing SoCs that do not expose
> them.
> - Reworked ports numbering + improved/fixed ports descriptions in the
> bindings documentation.
> - Improved commit body.
>
> v4->v5:
> - Dropped renesas,id property and updated bindings
> accordingly.
>
> v2->v3:
> - No changes.
>
> v2->v3:
> - No changes.
>
> v1->v2:
> - Use single compatible string instead of multiple compatible strings
> for the two DU instances, leveraging a 'renesas,id' property to
> differentiate between DU0 and DU1.
> - Updated commit message accordingly.
>
> .../bindings/display/renesas,rzg2l-du.yaml | 30 ++++++++++++++++++-
> 1 file changed, 29 insertions(+), 1 deletion(-)
>
> diff --git a/Documentation/devicetree/bindings/display/renesas,rzg2l-du.yaml b/Documentation/devicetree/bindings/display/renesas,rzg2l-du.yaml
> index 5add3b832eab..32da0b5ec88c 100644
> --- a/Documentation/devicetree/bindings/display/renesas,rzg2l-du.yaml
> +++ b/Documentation/devicetree/bindings/display/renesas,rzg2l-du.yaml
> @@ -20,6 +20,7 @@ properties:
> - enum:
> - renesas,r9a07g043u-du # RZ/G2UL
> - renesas,r9a07g044-du # RZ/G2{L,LC}
> + - renesas,r9a09g047-du # RZ/G3E
> - renesas,r9a09g057-du # RZ/V2H(P)
> - items:
> - enum:
> @@ -61,7 +62,7 @@ properties:
> model-dependent. Each port shall have a single endpoint.
>
> patternProperties:
> - "^port@[0-1]$":
> + "^port@[0-3]$":
> $ref: /schemas/graph.yaml#/properties/port
> unevaluatedProperties: false
>
> @@ -103,6 +104,8 @@ allOf:
> port@0:
> description: DPI
> port@1: false
> + port@2: false
> + port@3: false
>
> required:
> - port@0
> @@ -119,6 +122,8 @@ allOf:
> description: DSI
> port@1:
> description: DPI
> + port@2: false
> + port@3: false
>
> required:
> - port@0
> @@ -135,9 +140,32 @@ allOf:
> port@0:
> description: DSI
> port@1: false
> + port@2: false
> + port@3: false
>
> required:
> - port@0
> + - if:
> + properties:
> + compatible:
> + contains:
> + const: renesas,r9a09g047-du
> + then:
> + properties:
> + ports:
> + properties:
> + port@0:
> + description: DSI
> + port@1:
> + description: DPAD
> + port@2:
> + description: LVDS, Channel 0
> + port@3:
> + description: LVDS, Channel 1
> +
> + required:
> + - port@0
> + - port@3
Why are ports 1 and 2 not required ?
>
> examples:
> # RZ/G2L DU
--
Regards,
Laurent Pinchart
^ permalink raw reply
* Re: [PATCH v6 09/21] dt-bindings: display: renesas,rzg2l-du: Refuse port@1 for RZ/G2UL
From: Laurent Pinchart @ 2026-04-08 12:21 UTC (permalink / raw)
To: Tommaso Merciai
Cc: tomm.merciai, geert, linux-renesas-soc, biju.das.jz,
Maarten Lankhorst, Maxime Ripard, Thomas Zimmermann, David Airlie,
Simona Vetter, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Geert Uytterhoeven, Michael Turquette, Stephen Boyd, Magnus Damm,
Tomi Valkeinen, dri-devel, devicetree, linux-kernel, linux-clk,
stable
In-Reply-To: <8a3dd4df30a6d950e5f38d46f4d9f396da67aa71.1775636898.git.tommaso.merciai.xr@bp.renesas.com>
On Wed, Apr 08, 2026 at 12:36:54PM +0200, Tommaso Merciai wrote:
> The RZ/G2UL DU supports only a single port@0 DPI. Explicitly refuse
> port@1 in the ports node.
>
> Fixes: 2ef7cb1cea7d ("dt-bindings: display: renesas,rzg2l-du: Document RZ/G2UL DU bindings")
> Cc: stable@vger.kernel.org
> Signed-off-by: Tommaso Merciai <tommaso.merciai.xr@bp.renesas.com>
Reviewed-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
> ---
> v5->v6:
> - New patch.
>
> Documentation/devicetree/bindings/display/renesas,rzg2l-du.yaml | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/Documentation/devicetree/bindings/display/renesas,rzg2l-du.yaml b/Documentation/devicetree/bindings/display/renesas,rzg2l-du.yaml
> index 2cc66dcef870..5add3b832eab 100644
> --- a/Documentation/devicetree/bindings/display/renesas,rzg2l-du.yaml
> +++ b/Documentation/devicetree/bindings/display/renesas,rzg2l-du.yaml
> @@ -102,6 +102,7 @@ allOf:
> properties:
> port@0:
> description: DPI
> + port@1: false
>
> required:
> - port@0
--
Regards,
Laurent Pinchart
^ permalink raw reply
* Re: [PATCH v6 20/21] arm64: dts: renesas: r9a09g047: Add DU{0,1} and DSI nodes
From: Laurent Pinchart @ 2026-04-08 12:11 UTC (permalink / raw)
To: Tommaso Merciai
Cc: tomm.merciai, geert, linux-renesas-soc, biju.das.jz,
Maarten Lankhorst, Maxime Ripard, Thomas Zimmermann, David Airlie,
Simona Vetter, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Geert Uytterhoeven, Michael Turquette, Stephen Boyd, Magnus Damm,
Tomi Valkeinen, dri-devel, devicetree, linux-kernel, linux-clk
In-Reply-To: <ca31352b03689fa9902660be5cb4d0972ce04304.1775636898.git.tommaso.merciai.xr@bp.renesas.com>
On Wed, Apr 08, 2026 at 12:37:05PM +0200, Tommaso Merciai wrote:
> Add DU0, DU1, DSI nodes to RZ/RZG3E SoC DTSI.
>
> Signed-off-by: Tommaso Merciai <tommaso.merciai.xr@bp.renesas.com>
> ---
> v5->v6:
> - Update ports numbering accordingly to the latest DT bindings.
>
> v4->v5:
> - Rename du0_out_dsi0 into du0_out_dsi.
> - Rename du1_out_dsi0 into du1_out_dsi.
> - Drop renesas,id entry from DU nodes.
>
> v3->v4:
> - No changes.
>
> v2->v3:
> - No changes.
>
> v1->v2:
> - Use single compatible string instead of multiple compatible strings
> for the two DU instances, leveraging a 'renesas,id' property to
> differentiate between DU0 and DU1.
> - Use vclk instead of vclk1 for DSI Node and set to the right position.
>
> arch/arm64/boot/dts/renesas/r9a09g047.dtsi | 120 +++++++++++++++++++++
> 1 file changed, 120 insertions(+)
>
> diff --git a/arch/arm64/boot/dts/renesas/r9a09g047.dtsi b/arch/arm64/boot/dts/renesas/r9a09g047.dtsi
> index f2fdaadd9d39..25d3a503a6cc 100644
> --- a/arch/arm64/boot/dts/renesas/r9a09g047.dtsi
> +++ b/arch/arm64/boot/dts/renesas/r9a09g047.dtsi
> @@ -1585,6 +1585,126 @@ csi2cru: endpoint@0 {
> };
> };
>
> + dsi: dsi@16430000 {
> + compatible = "renesas,r9a09g047-mipi-dsi";
> + reg = <0 0x16430000 0 0x20000>;
> + interrupts = <GIC_SPI 874 IRQ_TYPE_LEVEL_HIGH>,
> + <GIC_SPI 875 IRQ_TYPE_LEVEL_HIGH>,
> + <GIC_SPI 876 IRQ_TYPE_LEVEL_HIGH>,
> + <GIC_SPI 877 IRQ_TYPE_LEVEL_HIGH>,
> + <GIC_SPI 878 IRQ_TYPE_LEVEL_HIGH>,
> + <GIC_SPI 879 IRQ_TYPE_LEVEL_HIGH>,
> + <GIC_SPI 880 IRQ_TYPE_LEVEL_HIGH>;
> + interrupt-names = "seq0", "seq1", "vin1", "rcv",
> + "ferr", "ppi", "debug";
> + clocks = <&cpg CPG_MOD 0xec>, <&cpg CPG_MOD 0xe9>,
> + <&cpg CPG_MOD 0xe8>, <&cpg CPG_MOD 0xea>,
> + <&cpg CPG_MOD 0x190>, <&cpg CPG_MOD 0xeb>;
> + clock-names = "pllrefclk", "aclk", "pclk", "vclk",
> + "lpclk", "vclk2";
> + resets = <&cpg 0xd8>, <&cpg 0xd7>;
> + reset-names = "arst", "prst";
> + power-domains = <&cpg>;
> + status = "disabled";
> +
> + ports {
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + port@0 {
> + reg = <0>;
> + dsi_in0: endpoint {
> + };
> + };
> +
> + port@1 {
> + reg = <1>;
> + dsi_in1: endpoint {
> + };
> + };
> +
> + port@2 {
> + reg = <2>;
> + dsi_out: endpoint {
> + };
> + };
> + };
> + };
> +
> + du0: display@16460000 {
> + compatible = "renesas,r9a09g047-du";
> + reg = <0 0x16460000 0 0x10000>;
> + interrupts = <GIC_SPI 882 IRQ_TYPE_LEVEL_HIGH>;
> + clocks = <&cpg CPG_MOD 0xed>,
> + <&cpg CPG_MOD 0xee>,
> + <&cpg CPG_MOD 0xef>;
> + clock-names = "aclk", "pclk", "vclk";
> + power-domains = <&cpg>;
> + resets = <&cpg 0xdc>;
I'm a bit concerned here. The same reset line is shared by the FCP, VSP
and DU. The FCP driver doesn't currently control it, but the VSP and DU
both assert and de-assert reset, without any coordination. Does it work
by chance ?
> + renesas,vsps = <&vspd0 0>;
> + status = "disabled";
> +
> + ports {
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + port@0 {
> + reg = <0>;
> + du0_out_dsi: endpoint {
> + };
> + };
> +
> + port@2 {
> + reg = <2>;
> + du0_out_lvds0: endpoint {
> + };
> + };
> +
> + port@3 {
> + reg = <3>;
> + du0_out_lvds1: endpoint {
> + };
> + };
> + };
> + };
> +
> + du1: display@16490000 {
> + compatible = "renesas,r9a09g047-du";
> + reg = <0 0x16490000 0 0x10000>;
> + interrupts = <GIC_SPI 922 IRQ_TYPE_LEVEL_HIGH>;
> + clocks = <&cpg CPG_MOD 0x1a8>,
> + <&cpg CPG_MOD 0x1a9>,
> + <&cpg CPG_MOD 0x1aa>;
> + clock-names = "aclk", "pclk", "vclk";
> + power-domains = <&cpg>;
> + resets = <&cpg 0x11e>;
> + renesas,vsps = <&vspd1 0>;
> + status = "disabled";
> +
> + ports {
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + port@0 {
> + reg = <0>;
> + du1_out_dsi: endpoint {
> + };
> + };
> +
> + port@1 {
> + reg = <1>;
> + du1_out_rgb: endpoint {
> + };
> + };
> +
> + port@3 {
> + reg = <3>;
> + du1_out_lvds1: endpoint {
> + };
> + };
> + };
> + };
> +
> fcpvd0: fcp@16470000 {
> compatible = "renesas,r9a09g047-fcpvd",
> "renesas,fcpv";
--
Regards,
Laurent Pinchart
^ permalink raw reply
* Re: [PATCH v4 1/2] dt-bindings: spi: renesas,rzv2h-rspi: Document RZ/G3L SoC
From: Mark Brown @ 2026-04-08 12:06 UTC (permalink / raw)
To: Biju
Cc: Fabrizio Castro, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Geert Uytterhoeven, Magnus Damm, Biju Das, linux-spi,
linux-renesas-soc, devicetree, linux-kernel,
Prabhakar Mahadev Lad, Krzysztof Kozlowski
In-Reply-To: <20260408085418.18770-2-biju.das.jz@bp.renesas.com>
[-- Attachment #1: Type: text/plain, Size: 584 bytes --]
On Wed, Apr 08, 2026 at 09:54:14AM +0100, Biju wrote:
> From: Biju Das <biju.das.jz@bp.renesas.com>
>
> Document RSPI IP found on the RZ/G3L SoC. The RSPI IP is compatible with
> the RZ/V2H RSPI IP, but has 2 clocks compared to 3 on RZ/V2H.
Please submit patches using subject lines reflecting the style for the
subsystem, this makes it easier for people to identify relevant patches.
Look at what existing commits in the area you're changing are doing and
make sure your subject lines visually resemble what they're doing.
There's no need to resubmit to fix this alone.
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply
* [PATCH v2] net: dsa: microchip: implement KSZ87xx Module 3 low-loss cable errata
From: Fidelio Lawson @ 2026-04-08 11:57 UTC (permalink / raw)
To: Woojung Huh, UNGLinuxDriver, Andrew Lunn, Vladimir Oltean,
David S. Miller, Eric Dumazet, Jakub Kicinski, Paolo Abeni,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, Marek Vasut,
Maxime Chevallier
Cc: Woojung Huh, netdev, devicetree, linux-kernel, Fidelio Lawson
Implement the "Module 3: Equalizer fix for short cables" erratum from
Microchip document DS80000687C for KSZ87xx switches.
The issue affects short or low-loss cable links (e.g. CAT5e/CAT6),
where the PHY receiver equalizer may amplify high-amplitude signals
excessively, resulting in internal distortion and link establishment
failures.
KSZ87xx devices require a workaround for the Module 3 low-loss cable
condition, controlled through the switch TABLE_LINK_MD_V indirect
registers.
The affected registers are part of the switch address space and are not
directly accessible from the PHY driver. To keep the PHY-facing API
clean and avoid leaking switch-specific details, model this errata
control as vendor-specific Clause 22 PHY registers.
Two vendor-defined bits are introduced in PHY_REG_LOW_LOSS_CTRL,
and ksz8_r_phy() / ksz8_w_phy() translate accesses to these bits
into the appropriate indirect TABLE_LINK_MD_V accesses.
The control register defines the following modes:
bits [1:0]:
00 = workaround disabled
01 = workaround 1 (DSP EQ training adjustment, LinkMD reg 0x3c)
10 = workaround 2 (receiver LPF bandwidth, LinkMD reg 0x4c)
Workaround 1: Adjusts the DSP EQ training behavior via LinkMD register
0x3C. Widens and optimizes the DSP EQ compensation range,
and is expected to solve most short/low-loss cable issues.
Workaround 2: for the cases where Workaround 1 is not sufficient.
This one adjusts the receiver low-pass filter bandwidth, effectively
reducing the high-frequency component of the received signal
The register is accessible through standard PHY read/write operations
(e.g. phytool), without requiring any switch-specific userspace
interface. This allows robust link establishment on short or
low-loss cabling without requiring DTS properties and without
constraining hardware design choices.
The erratum affects the shared PHY analog front-end and therefore
applies globally to the switch.
Signed-off-by: Fidelio Lawson <fidelio.lawson@exotec.com>
---
Hello,
This patch implements the “Module 3: Equalizer fix for short cables” erratum
described in Microchip document DS80000687C for KSZ87xx switches.
According to the erratum, the embedded PHY receiver in KSZ87xx switches is
tuned by default for long, high-loss Ethernet cables. When operating with
short or low-loss cables (for example CAT5e or CAT6), the PHY equalizer may
over-amplify the incoming signal, leading to internal distortion and link
establishment failures.
Microchip provides two workarounds, each requiring a write to a different
indirect PHY register access mechanism.
The workaround requires programming internal PHY/DSP registers located in the
LinkMD table, accessed through the KSZ8 indirect register mechanism. Since these
registers belong to the switch address space and are not directly accessible
from a standalone PHY driver, the erratum control is modeled as a vendor-specific
Clause 22 PHY register, virtualized by the KSZ8 DSA driver.
Reads and writes to this register are intercepted by ksz8_r_phy() /
ksz8_w_phy() and translated into the required TABLE_LINK_MD_V indirect accesses.
The erratum affects the shared PHY analog front-end and therefore applies
globally to the switch.
The register defines three modes:
- 0x0: workaround disabled
- 0x1: workaround 1 (DSP EQ training adjustment)
- 0x2: workaround 2 (receiver low-pass filter bandwidth reduction)
The register can be read and written from userspace via standard Clause 22 PHY
accesses (for example using phytool) on DSA user ports.
This series is based on Linux v7.0-rc1.
---
Changes in v2:
- Dropped the device tree approache based on review feedback
- Modeled the errata control as a vendor-specific Clause 22 PHY register
- Added KSZ87xx-specific guards and replaced magic values with named macros
- Rebased on Linux v7.0-rc1
- Link to v1: https://patch.msgid.link/20260326-ksz87xx_errata_low_loss_connections-v1-0-79a698f43626@exotec.com
---
drivers/net/dsa/microchip/ksz8.c | 33 +++++++++++++++++++++++++++++++++
drivers/net/dsa/microchip/ksz8_reg.h | 20 +++++++++++++++++++-
drivers/net/dsa/microchip/ksz_common.h | 3 +++
3 files changed, 55 insertions(+), 1 deletion(-)
diff --git a/drivers/net/dsa/microchip/ksz8.c b/drivers/net/dsa/microchip/ksz8.c
index c354abdafc1b..d11da6e9ff54 100644
--- a/drivers/net/dsa/microchip/ksz8.c
+++ b/drivers/net/dsa/microchip/ksz8.c
@@ -1058,6 +1058,11 @@ int ksz8_r_phy(struct ksz_device *dev, u16 phy, u16 reg, u16 *val)
if (ret)
return ret;
+ break;
+ case PHY_REG_KSZ87XX_LOW_LOSS:
+ if (!ksz_is_ksz87xx(dev))
+ return -EOPNOTSUPP;
+ data = dev->low_loss_wa_mode;
break;
default:
processed = false;
@@ -1271,6 +1276,34 @@ int ksz8_w_phy(struct ksz_device *dev, u16 phy, u16 reg, u16 val)
if (ret)
return ret;
break;
+ case PHY_REG_KSZ87XX_LOW_LOSS:
+ if (!ksz_is_ksz87xx(dev))
+ return -EOPNOTSUPP;
+
+ switch (val & PHY_KSZ87XX_LOW_LOSS_MASK) {
+ case PHY_LOW_LOSS_ERRATA_DISABLED:
+ ret = ksz8_ind_write8(dev, TABLE_LINK_MD, KSZ87XX_REG_EQ_TRAIN,
+ KSZ87XX_EQ_TRAIN_DEFAULT);
+ if (!ret)
+ ret = ksz8_ind_write8(dev, TABLE_LINK_MD,
+ KSZ87XX_REG_PHY_LPF,
+ KSZ87XX_PHY_LPF_DEFAULT);
+ break;
+ case KSZ87XX_LOW_LOSS_WA_EQ:
+ ret = ksz8_ind_write8(dev, TABLE_LINK_MD, KSZ87XX_REG_EQ_TRAIN,
+ KSZ87XX_EQ_TRAIN_LOW_LOSS);
+ break;
+ case KSZ87XX_LOW_LOSS_WA_LPF:
+ ret = ksz8_ind_write8(dev, TABLE_LINK_MD, KSZ87XX_REG_PHY_LPF,
+ KSZ87XX_PHY_LPF_62MHZ);
+ break;
+ default:
+ return -EINVAL;
+ }
+
+ if (!ret)
+ dev->low_loss_wa_mode = val & PHY_KSZ87XX_LOW_LOSS_MASK;
+ return ret;
default:
break;
}
diff --git a/drivers/net/dsa/microchip/ksz8_reg.h b/drivers/net/dsa/microchip/ksz8_reg.h
index 332408567b47..cd1092aa0eaf 100644
--- a/drivers/net/dsa/microchip/ksz8_reg.h
+++ b/drivers/net/dsa/microchip/ksz8_reg.h
@@ -202,6 +202,10 @@
#define REG_PORT_3_STATUS_0 0x38
#define REG_PORT_4_STATUS_0 0x48
+/* KSZ87xx LinkMD registers (TABLE_LINK_MD_V) */
+#define KSZ87XX_REG_EQ_TRAIN 0x3C
+#define KSZ87XX_REG_PHY_LPF 0x4C
+
/* For KSZ8765. */
#define PORT_REMOTE_ASYM_PAUSE BIT(5)
#define PORT_REMOTE_SYM_PAUSE BIT(4)
@@ -342,7 +346,7 @@
#define TABLE_EEE (TABLE_EEE_V << TABLE_EXT_SELECT_S)
#define TABLE_ACL (TABLE_ACL_V << TABLE_EXT_SELECT_S)
#define TABLE_PME (TABLE_PME_V << TABLE_EXT_SELECT_S)
-#define TABLE_LINK_MD (TABLE_LINK_MD << TABLE_EXT_SELECT_S)
+#define TABLE_LINK_MD (TABLE_LINK_MD_V << TABLE_EXT_SELECT_S)
#define TABLE_READ BIT(4)
#define TABLE_SELECT_S 2
#define TABLE_STATIC_MAC_V 0
@@ -729,6 +733,20 @@
#define PHY_POWER_SAVING_ENABLE BIT(2)
#define PHY_REMOTE_LOOPBACK BIT(1)
+/* Equalizer low-loss workaround */
+/* bits [1:0]: 00 = disabled, 01 = workaround 1, 10 = workaround 2 */
+#define PHY_REG_KSZ87XX_LOW_LOSS 0x1C
+#define PHY_KSZ87XX_LOW_LOSS_MASK GENMASK(1, 0)
+
+#define PHY_LOW_LOSS_ERRATA_DISABLED 0
+#define KSZ87XX_LOW_LOSS_WA_EQ 1
+#define KSZ87XX_LOW_LOSS_WA_LPF 2
+
+#define KSZ87XX_EQ_TRAIN_DEFAULT 0x0A
+#define KSZ87XX_EQ_TRAIN_LOW_LOSS 0x15
+#define KSZ87XX_PHY_LPF_DEFAULT 0x00
+#define KSZ87XX_PHY_LPF_62MHZ 0x40
+
/* KSZ8463 specific registers. */
#define P1MBCR 0x4C
#define P1MBSR 0x4E
diff --git a/drivers/net/dsa/microchip/ksz_common.h b/drivers/net/dsa/microchip/ksz_common.h
index 929aff4c55de..729996c7160c 100644
--- a/drivers/net/dsa/microchip/ksz_common.h
+++ b/drivers/net/dsa/microchip/ksz_common.h
@@ -219,6 +219,9 @@ struct ksz_device {
* the switch’s internal PHYs, bypassing the main SPI interface.
*/
struct mii_bus *parent_mdio_bus;
+
+ /* Equalizer low-loss workaround tunable */
+ u8 low_loss_wa_mode; /* bits [1:0]: 00 = disabled, 01 = workaround 1, 10 = workaround 2 */
};
/* List of supported models */
---
base-commit: 2d1373e4246da3b58e1df058374ed6b101804e07
change-id: 20260323-ksz87xx_errata_low_loss_connections-b65e76e2b403
Best regards,
--
Fidelio Lawson <fidelio.lawson@exotec.com>
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox