* [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
* [PATCH] ARM: dts: exynos: Add bluetooth support to manta
From: Lukas Timmermann @ 2026-04-08 11:56 UTC (permalink / raw)
To: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Alim Akhtar
Cc: devicetree, linux-arm-kernel, linux-samsung-soc, linux-kernel,
Lukas Timmermann, Alexandre Marquet
Enable the bcm4330-bt device for manta boards on serial0.
Also adds the necessary pin definitions and interrupt handling for
wakeup.
Signed-off-by: Lukas Timmermann <linux@timmermann.space>
Co-developed-by: Alexandre Marquet <tb@a-marquet.fr>
Signed-off-by: Alexandre Marquet <tb@a-marquet.fr>
---
This patch depends on previous patches which are
currently only found in linux-next.
See: https://lore.kernel.org/all/177214038655.341086.4114348823043257597.b4-ty@kernel.org/
---
arch/arm/boot/dts/samsung/exynos5250-manta.dts | 41 +++++++++++++++++++++++++-
1 file changed, 40 insertions(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/samsung/exynos5250-manta.dts b/arch/arm/boot/dts/samsung/exynos5250-manta.dts
index 24a27b342227..76d3657eb22f 100644
--- a/arch/arm/boot/dts/samsung/exynos5250-manta.dts
+++ b/arch/arm/boot/dts/samsung/exynos5250-manta.dts
@@ -461,6 +461,13 @@ acc_int: acc-int-pins {
samsung,pin-pud = <EXYNOS_PIN_PULL_UP>;
};
+ bt_host_wakeup: bt-host-wakeup-pins {
+ samsung,pins = "gpx2-6";
+ samsung,pin-function = <EXYNOS_PIN_FUNC_INPUT>;
+ samsung,pin-pud = <EXYNOS_PIN_PULL_NONE>;
+ samsung,pin-drv = <EXYNOS4_PIN_DRV_LV1>;
+ };
+
max77686_irq: max77686-irq-pins {
samsung,pins = "gpx0-2";
samsung,pin-function = <EXYNOS_PIN_FUNC_F>;
@@ -488,6 +495,20 @@ bh1721fvc_reset: bh1721fvc-reset-pins {
samsung,pin-pud = <EXYNOS_PIN_PULL_NONE>;
};
+ bt_reg_on: bt-reg-on-pins {
+ samsung,pins = "gph0-0";
+ samsung,pin-function = <EXYNOS_PIN_FUNC_OUTPUT>;
+ samsung,pin-con-pdn = <EXYNOS_PIN_PDN_PREV>;
+ samsung,pin-pud-pdn = <EXYNOS_PIN_PULL_NONE>;
+ };
+
+ bt_wake: bt-wake-pins {
+ samsung,pins = "gph1-3";
+ samsung,pin-function = <EXYNOS_PIN_FUNC_OUTPUT>;
+ samsung,pin-con-pdn = <EXYNOS_PIN_PDN_PREV>;
+ samsung,pin-pud-pdn = <EXYNOS_PIN_PULL_NONE>;
+ };
+
msense_reset: msense-reset-pins {
samsung,pins = "gpg2-0";
samsung,pin-function = <EXYNOS_PIN_FUNC_OUTPUT>;
@@ -536,7 +557,25 @@ &sd1_cmd {
/* Bluetooth */
&serial_0 {
- status = "disabled";
+ pinctrl-0 = <&uart0_data &uart0_fctl>;
+ pinctrl-names = "default";
+
+ bluetooth {
+ compatible = "brcm,bcm4330-bt";
+
+ pinctrl-0 = <&bt_reg_on &bt_wake &bt_host_wakeup>;
+ pinctrl-names = "default";
+
+ shutdown-gpios = <&gph0 0 GPIO_ACTIVE_HIGH>;
+ device-wakeup-gpios = <&gph1 3 GPIO_ACTIVE_HIGH>;
+
+ interrupt-parent = <&gpx2>;
+ interrupts = <6 IRQ_TYPE_EDGE_FALLING>;
+ interrupt-names = "host-wakeup";
+
+ clocks = <&max77686 MAX77686_CLK_PMIC>;
+ clock-names = "lpo";
+ };
};
/* GPS */
---
base-commit: e5f7e05a699f41275d6380c497293446034bc8af
change-id: 20260404-manta-bluetooth-836133028bb6
Best regards,
--
Lukas Timmermann <linux@timmermann.space>
^ permalink raw reply related
* Re: [PATCH v7 0/3] riscv: Use GCR.U timer device as clocksource
From: Aleksa Paunovic @ 2026-04-08 11:53 UTC (permalink / raw)
To: devnull+aleksa.paunovic.htecgroup.com@kernel.org
Cc: Aleksa Paunovic, alex@ghiti.fr, aou@eecs.berkeley.edu,
cfu@mips.com, conor+dt@kernel.org, conor.dooley@microchip.com,
daniel.lezcano@linaro.org, devicetree@vger.kernel.org,
Djordje Todorovic, jstultz@google.com, krzk+dt@kernel.org,
linux-kernel@vger.kernel.org, linux-riscv@lists.infradead.org,
palmer@dabbelt.com, paul.walmsley@sifive.com, pjw@kernel.org,
robh@kernel.org, sboyd@kernel.org, tglx@linutronix.de,
wangruikang@iscas.ac.cn
In-Reply-To: <20260311-riscv-time-mmio-v7-0-016845a0f808@htecgroup.com>
On 3/11/26 14:26, Aleksa Paunovic via B4 Relay wrote:
> This series adds bindings for the GCR.U timer device and corresponding
> driver support. Accessing the memory mapped shadow of the mtime register
> in the GCR.U region should be faster
> than trapping to M mode each time the timer needs to be read.
> The timer device does not implement any interrupts, therefore the
> timer-riscv clockevent implementation should suffice.
>
> We tested the patchset both on QEMU and the Boston board with the P8700 bitfile:
> - Coremark and timer kselftests on QEMU emulating an 8 core CPU
> - Coremark and timer kselftests on the Boston board with a single core CPU.
Gentle ping.
^ permalink raw reply
* Re: [PATCH 3/3] net: dsa: microchip: implement KSZ87xx Module 3 low-loss cable errata
From: Fidelio LAWSON @ 2026-04-08 11:50 UTC (permalink / raw)
To: Andrew Lunn
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: <c235ee5c-6057-4c10-9960-9c5a3527bf22@lunn.ch>
On 4/4/26 16:45, Andrew Lunn wrote:
> On Fri, Apr 03, 2026 at 11:43:24AM +0200, Fidelio LAWSON wrote:
>> On 3/26/26 13:18, Andrew Lunn wrote:
>>>> + mutex_lock(&dev->alu_mutex);
>>>> +
>>>> + ret = ksz_write8(dev, regs[REG_IND_CTRL_0], 0xA0);
>>>> +
>>>> + if (!ret)
>>>> + ret = ksz_write8(dev, 0x6F, indir_reg);
>>>> +
>>>> + if (!ret)
>>>> + ret = ksz_write8(dev, regs[REG_IND_BYTE], indir_val);
>>>> +
>>>> + mutex_unlock(&dev->alu_mutex);
>>>
>>> What address space are these registers in? Normally workarounds for a
>>> PHY would be in the PHY driver. But that assumes the registers are
>>> accessible from the PHY driver.
>>>
>>> Andrew
>>
>> Hi Andrew,
>> These registers belong to the KSZ87xx switch address space, accessed through
>> the switch’s indirect access mechanism. In particular, the offsets used here
>> correspond to entries within the TABLE_LINK_MD_V indirect table of the
>> KSZ8-family switches.
>
> So this errata is for ksz87xx only?
>
> For this PHY, do all PHY register reads and writes go through
>
> https://elixir.bootlin.com/linux/v6.19.11/source/drivers/net/dsa/microchip/ksz8.c#L957
> ksz8_r_phy()
>
> and
>
> https://elixir.bootlin.com/linux/v6.19.11/source/drivers/net/dsa/microchip/ksz8.c#L1221
> ksz8_w_phy()?
>
> We already have some "interesting" things going on in these
> functions. PHY_REG_LINK_MD and PHY_REG_PHY_CTRL are not standard C22
> PHY registers. They take the values 0x1d and 0x1f. The 802.3 standard
> defines 0x10-0x1f as vendor specific, so this is O.K.
>
> So you could define 2 bits in say register 0x1c to indicate the errata
> mode. You can have a PHY tunable which does reads/writes to these two
> bits, and ksz8_w_phy/ksz8_r_phy which translates them to indirect
> register accesses?
>
> It is not even really violating the layering.
>
> Andrew
Hi Andrew,
Thanks a lot for the feedback, it was very helpful.
Yes, the erratum affects KSZ87xx devices only, and all accesses to the
embedded PHYs indeed go through ksz8_r_phy() / ksz8_w_phy(), as you
pointed out.
I followed your suggestion and reworked the implementation accordingly:
the errata selection is now modeled as a vendor‑specific Clause 22 PHY
register (0x1c), handled entirely in ksz8_r_phy() / ksz8_w_phy(), which
translate reads and writes into the appropriate indirect TABLE_LINK_MD_V
accesses. This keeps the PHY‑facing API clean without breaking the layering.
I’ve dropped the DT approach and adjusted the implementation based on
the review comments. I’m sending a v2 with these changes shortly.
Thanks again for the guidance.
Best regards,
Fidelio
^ permalink raw reply
* Re: [PATCH v8 1/7] dt-bindings: input: syna,rmi4: Document syna,rmi4-s3706b
From: David Heidelberg @ 2026-04-08 11:50 UTC (permalink / raw)
To: Dmitry Torokhov
Cc: Kaustabh Chakraborty, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Jason A. Donenfeld, Matthias Schiffer,
Vincent Huang, Casey Connolly, linux-input, devicetree,
linux-kernel, phone-devel, Krzysztof Kozlowski
In-Reply-To: <adSMQXgbco8fvRLo@google.com>
On 07/04/2026 06:48, Dmitry Torokhov wrote:
> On Wed, Mar 25, 2026 at 12:33:23PM +0100, David Heidelberg wrote:
>> On 24/03/2026 20:42, Dmitry Torokhov wrote:
>>> On Tue, Mar 24, 2026 at 08:40:34PM +0100, David Heidelberg via B4 Relay wrote:
>>>> From: David Heidelberg <david@ixit.cz>
>>>>
>>>> Mostly irrelevant for authentic Synaptics touchscreens, but very important
>>>> for applying workarounds to cheap TS knockoffs.
>>>>
>>>> These knockoffs work well with the downstream driver, and since the user
>>>> has no way to distinguish them, later in this patch set, we introduce
>>>> workarounds to ensure they function as well as possible.
>>>>
>>>> Acked-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
>>>> Signed-off-by: David Heidelberg <david@ixit.cz>
>>>> ---
>>>> Documentation/devicetree/bindings/input/syna,rmi4.yaml | 11 ++++++++---
>>>> 1 file changed, 8 insertions(+), 3 deletions(-)
>>>>
>>>> diff --git a/Documentation/devicetree/bindings/input/syna,rmi4.yaml b/Documentation/devicetree/bindings/input/syna,rmi4.yaml
>>>> index 8685ef4481f4a..fb4804ac3544d 100644
>>>> --- a/Documentation/devicetree/bindings/input/syna,rmi4.yaml
>>>> +++ b/Documentation/devicetree/bindings/input/syna,rmi4.yaml
>>>> @@ -18,9 +18,14 @@ description: |
>>>> properties:
>>>> compatible:
>>>> - enum:
>>>> - - syna,rmi4-i2c
>>>> - - syna,rmi4-spi
>>>> + oneOf:
>>>> + - enum:
>>>> + - syna,rmi4-i2c
>>>> + - syna,rmi4-spi
>>>> + - items:
>>>> + - enum:
>>>> + - syna,rmi4-s3706b # OnePlus 6/6T
>>>
>>> I thought that all the workarounds will be keyed off this new
>>> compatible, but I do not see that. What am I missing?
>>
>> The compatible is used for sequence in the
>>
>> Input: synaptics-rmi4 - support fallback values for PDT descriptor bytes
>>
>> where it is used to provide values missing for OP6 (and possible others in
>> the future, when added).
>>
>> From my understanding the series, only two patches (1st and last) are
>> specific for the OP6, rest will likely benefit various TS not implementing
>> full Synaptics set. All measures apply only when touchscreen reports
>> something wrong.
>
> If the sensor does not implement RMI4 protocol properly it should not
> use rmi4 compatibility. I will not apply any patches that work around
> incomplete implementations unless they are triggered by a dedicated
> compatible.
Ok, good.
Can we agree on subset which is correct now?
I think that
[PATCH v8 4/7] Input: synaptics-rmi4 - f55: handle zero electrode count
[PATCH v8 6/7] Input: synaptics-rmi4 - read product ID on aftermarket touch ICs
could be reasonable to keep as is, except I would reword the 6/7, as reading
product ID isn't anything aftermarket specific.
Then I would send this subset to get in first and work on the rest, does it
sounds good to you?
David>
> Thanks.
>
--
David Heidelberg
^ permalink raw reply
* Re: [PATCH v6 19/21] arm64: dts: renesas: r9a09g047: Add vspd{0,1} nodes
From: Laurent Pinchart @ 2026-04-08 11:33 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: <46547aaff3cdb8ea6e17cf1fdec699d83a1cd71b.1775636898.git.tommaso.merciai.xr@bp.renesas.com>
On Wed, Apr 08, 2026 at 12:37:04PM +0200, Tommaso Merciai wrote:
> Add vspd{0,1} nodes to RZ/G3E SoC DTSI.
>
> Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
> Signed-off-by: Tommaso Merciai <tommaso.merciai.xr@bp.renesas.com>
> ---
> v5->v6:
> - No changes.
>
> v4->v5:
> - No changes.
>
> v3->v4:
> - No changes.
>
> v2->v3:
> - No changes.
>
> v1->v2:
> - Squashed vspd0 and vspd1 patches into a single patch.
> - Collected tags.
>
> arch/arm64/boot/dts/renesas/r9a09g047.dtsi | 28 ++++++++++++++++++++++
> 1 file changed, 28 insertions(+)
>
> diff --git a/arch/arm64/boot/dts/renesas/r9a09g047.dtsi b/arch/arm64/boot/dts/renesas/r9a09g047.dtsi
> index 3115ab4b050f..f2fdaadd9d39 100644
> --- a/arch/arm64/boot/dts/renesas/r9a09g047.dtsi
> +++ b/arch/arm64/boot/dts/renesas/r9a09g047.dtsi
> @@ -1608,6 +1608,34 @@ fcpvd1: fcp@164a0000 {
> resets = <&cpg 0x11e>;
> power-domains = <&cpg>;
> };
> +
> + vspd0: vsp@16480000 {
> + compatible = "renesas,r9a09g047-vsp2",
> + "renesas,r9a07g044-vsp2";
> + reg = <0 0x16480000 0 0x10000>;
> + interrupts = <GIC_SPI 881 IRQ_TYPE_LEVEL_HIGH>;
> + clocks = <&cpg CPG_MOD 0xed>,
> + <&cpg CPG_MOD 0xee>,
> + <&cpg CPG_MOD 0xef>;
> + clock-names = "aclk", "pclk", "vclk";
> + resets = <&cpg 0xdc>;
> + power-domains = <&cpg>;
> + renesas,fcp = <&fcpvd0>;
> + };
> +
> + vspd1: vsp@164b0000 {
> + compatible = "renesas,r9a09g047-vsp2",
> + "renesas,r9a07g044-vsp2";
> + reg = <0 0x164b0000 0 0x10000>;
> + interrupts = <GIC_SPI 921 IRQ_TYPE_LEVEL_HIGH>;
> + clocks = <&cpg CPG_MOD 0x1a8>,
> + <&cpg CPG_MOD 0x1a9>,
> + <&cpg CPG_MOD 0x1aa>;
> + clock-names = "aclk", "pclk", "vclk";
> + resets = <&cpg 0x11e>;
> + power-domains = <&cpg>;
> + renesas,fcp = <&fcpvd1>;
> + };
This matches the documentation.
Reviewed-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
> };
>
> stmmac_axi_setup: stmmac-axi-config {
--
Regards,
Laurent Pinchart
^ permalink raw reply
* Re: [PATCH v6 18/21] arm64: dts: renesas: r9a09g047: Add fcpvd{0,1} nodes
From: Laurent Pinchart @ 2026-04-08 11:32 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: <1ba6a98ace4ad9525d054cbaa308d3aeeecfa22a.1775636898.git.tommaso.merciai.xr@bp.renesas.com>
On Wed, Apr 08, 2026 at 12:37:03PM +0200, Tommaso Merciai wrote:
> Add fcpvd{0,1} nodes to RZ/G3E SoC DTSI.
>
> Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
> Signed-off-by: Tommaso Merciai <tommaso.merciai.xr@bp.renesas.com>
> ---
> v5->v6:
> - No changes.
>
> v4->v5:
> - No changes.
>
> v3->v4:
> - No changes.
>
> v2->v3:
> - No changes.
>
> v1->v2:
> - Squashed fcpvd0 and fcpvd1 patches into a single patch.
> - Collected tags.
>
> arch/arm64/boot/dts/renesas/r9a09g047.dtsi | 24 ++++++++++++++++++++++
> 1 file changed, 24 insertions(+)
>
> diff --git a/arch/arm64/boot/dts/renesas/r9a09g047.dtsi b/arch/arm64/boot/dts/renesas/r9a09g047.dtsi
> index 95a4e30a064d..3115ab4b050f 100644
> --- a/arch/arm64/boot/dts/renesas/r9a09g047.dtsi
> +++ b/arch/arm64/boot/dts/renesas/r9a09g047.dtsi
> @@ -1584,6 +1584,30 @@ csi2cru: endpoint@0 {
> };
> };
> };
> +
> + fcpvd0: fcp@16470000 {
> + compatible = "renesas,r9a09g047-fcpvd",
> + "renesas,fcpv";
> + reg = <0 0x16470000 0 0x10000>;
> + clocks = <&cpg CPG_MOD 0xed>,
> + <&cpg CPG_MOD 0xee>,
> + <&cpg CPG_MOD 0xef>;
> + clock-names = "aclk", "pclk", "vclk";
> + resets = <&cpg 0xdc>;
> + power-domains = <&cpg>;
> + };
> +
> + fcpvd1: fcp@164a0000 {
> + compatible = "renesas,r9a09g047-fcpvd",
> + "renesas,fcpv";
> + reg = <0 0x164a0000 0 0x10000>;
> + clocks = <&cpg CPG_MOD 0x1a8>,
> + <&cpg CPG_MOD 0x1a9>,
> + <&cpg CPG_MOD 0x1aa>;
> + clock-names = "aclk", "pclk", "vclk";
> + resets = <&cpg 0x11e>;
> + power-domains = <&cpg>;
> + };
This matches the documentation.
Reviewed-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
> };
>
> stmmac_axi_setup: stmmac-axi-config {
--
Regards,
Laurent Pinchart
^ permalink raw reply
* [net-next v1 v1 4/5] net: stmmac: starfive: Add JHB100 SGMII interface
From: Minda Chen @ 2026-04-08 8:44 UTC (permalink / raw)
To: Alexandre Torgue, Andrew Lunn, David S . Miller, Eric Dumazet,
Jakub Kicinski, Paolo Abeni, Maxime Coquelin,
Emil Renner Berthing, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, netdev
Cc: linux-kernel, linux-stm32, devicetree, Minda Chen
In-Reply-To: <20260408084416.29753-1-minda.chen@starfivetech.com>
Add JHB100 compatible and SGMII support. JHB100 soc contains
2 SGMII interfaces and integrated with serdes PHY. SGMII with
split TX/RX MAC clock and need to set 2.5M/25M/125M TX/RX clock
rate in 10M/100M/1000M speed mode.
Signed-off-by: Minda Chen <minda.chen@starfivetech.com>
---
.../ethernet/stmicro/stmmac/dwmac-starfive.c | 36 +++++++++++++++++--
1 file changed, 34 insertions(+), 2 deletions(-)
diff --git a/drivers/net/ethernet/stmicro/stmmac/dwmac-starfive.c b/drivers/net/ethernet/stmicro/stmmac/dwmac-starfive.c
index 16b955a6d77b..df7b2fc9989d 100644
--- a/drivers/net/ethernet/stmicro/stmmac/dwmac-starfive.c
+++ b/drivers/net/ethernet/stmicro/stmmac/dwmac-starfive.c
@@ -26,6 +26,7 @@ struct starfive_dwmac_data {
struct starfive_dwmac {
struct device *dev;
const struct starfive_dwmac_data *data;
+ struct clk *sgmii_rx;
};
static int starfive_dwmac_set_mode(struct plat_stmmacenet_data *plat_dat)
@@ -36,6 +37,9 @@ static int starfive_dwmac_set_mode(struct plat_stmmacenet_data *plat_dat)
int phy_intf_sel;
int err;
+ if (plat_dat->phy_interface == PHY_INTERFACE_MODE_SGMII)
+ return 0;
+
phy_intf_sel = stmmac_get_phy_intf_sel(plat_dat->phy_interface);
if (phy_intf_sel != PHY_INTF_SEL_RGMII &&
phy_intf_sel != PHY_INTF_SEL_RMII) {
@@ -68,6 +72,24 @@ static int starfive_dwmac_set_mode(struct plat_stmmacenet_data *plat_dat)
return 0;
}
+static int stmmac_starfive_sgmii_set_clk_rate(void *bsp_priv, struct clk *clk_tx_i,
+ phy_interface_t interface, int speed)
+{
+ struct starfive_dwmac *dwmac = (void *)bsp_priv;
+ long rate = rgmii_clock(speed);
+ int ret;
+
+ /* MAC clock rate the same as RGMII */
+ if (rate < 0)
+ return 0;
+
+ ret = clk_set_rate(clk_tx_i, rate);
+ if (ret)
+ return ret;
+
+ return clk_set_rate(dwmac->sgmii_rx, rate);
+}
+
static int starfive_dwmac_probe(struct platform_device *pdev)
{
struct plat_stmmacenet_data *plat_dat;
@@ -102,14 +124,23 @@ static int starfive_dwmac_probe(struct platform_device *pdev)
return dev_err_probe(&pdev->dev, PTR_ERR(clk_gtx),
"error getting gtx clock\n");
+ dwmac->sgmii_rx = devm_clk_get_optional(&pdev->dev, "rx");
+ if (IS_ERR(dwmac->sgmii_rx))
+ return dev_err_probe(&pdev->dev, PTR_ERR(dwmac->sgmii_rx),
+ "error getting sgmii rx clock\n");
+
/* Generally, the rgmii_tx clock is provided by the internal clock,
* which needs to match the corresponding clock frequency according
* to different speeds. If the rgmii_tx clock is provided by the
* external rgmii_rxin, there is no need to configure the clock
* internally, because rgmii_rxin will be adaptively adjusted.
*/
- if (!device_property_read_bool(&pdev->dev, "starfive,tx-use-rgmii-clk"))
- plat_dat->set_clk_tx_rate = stmmac_set_clk_tx_rate;
+ if (!device_property_read_bool(&pdev->dev, "starfive,tx-use-rgmii-clk")) {
+ if (plat_dat->phy_interface == PHY_INTERFACE_MODE_SGMII)
+ plat_dat->set_clk_tx_rate = stmmac_starfive_sgmii_set_clk_rate;
+ else
+ plat_dat->set_clk_tx_rate = stmmac_set_clk_tx_rate;
+ }
dwmac->dev = &pdev->dev;
plat_dat->flags |= STMMAC_FLAG_EN_TX_LPI_CLK_PHY_CAP;
@@ -130,6 +161,7 @@ static const struct starfive_dwmac_data jh7100_data = {
static const struct of_device_id starfive_dwmac_match[] = {
{ .compatible = "starfive,jh7100-dwmac", .data = &jh7100_data },
{ .compatible = "starfive,jh7110-dwmac" },
+ { .compatible = "starfive,jhb100-dwmac" },
{ /* sentinel */ }
};
MODULE_DEVICE_TABLE(of, starfive_dwmac_match);
--
2.17.1
^ permalink raw reply related
* RE: [PATCH v4 net-next 13/14] net: dsa: netc: initialize buffer bool table and implement flow-control
From: Wei Fang @ 2026-04-08 11:16 UTC (permalink / raw)
To: Jakub Kicinski
Cc: Claudiu Manoil, Vladimir Oltean, Clark Wang,
andrew+netdev@lunn.ch, davem@davemloft.net, edumazet@google.com,
pabeni@redhat.com, robh@kernel.org, krzk+dt@kernel.org,
conor+dt@kernel.org, f.fainelli@gmail.com, Frank Li,
chleroy@kernel.org, horms@kernel.org, linux@armlinux.org.uk,
andrew@lunn.ch, netdev@vger.kernel.org,
linux-kernel@vger.kernel.org, devicetree@vger.kernel.org,
linuxppc-dev@lists.ozlabs.org,
linux-arm-kernel@lists.infradead.org, imx@lists.linux.dev
In-Reply-To: <20260403011745.1795759-1-kuba@kernel.org>
> > +static u32 netc_get_buffer_pool_num(struct netc_switch *priv)
> > +{
> > + /* The BPCAPR register is a read only register, the hardware
> > + * guarantees that the BPCAPR_NUM_BP field will not be 0.
> > + */
> > + return netc_base_rd(&priv->regs, NETC_BPCAPR) & BPCAPR_NUM_BP;
> > +}
> [ ... ]
> > +static void netc_ipv_to_buffer_pool_mapping(struct netc_switch *priv)
> > +{
> > + int bp_per_port = priv->num_bp / priv->info->num_ports;
> > + int q = NETC_IPV_NUM / bp_per_port;
> > + int r = NETC_IPV_NUM % bp_per_port;
>
> If the hardware register read in netc_get_buffer_pool_num() returns a value
> smaller than priv->info->num_ports (for instance, during a bus error or
> reset state), bp_per_port will evaluate to 0.
>
> Can this lead to a division by zero panic here?
>
> Should priv->num_bp be validated against the number of ports before
> performing this calculation to ensure the driver fails gracefully if the
> hardware returns an unexpected value?
If the hardware is so unstable and prone to such malfunctions, that would
be terrible, but I believe it won't. The AI review is being a bit too nitpicky.
Anyway, I will ll add this check to avoid AI review warnings.
^ permalink raw reply
* Re: [PATCH 0/3] arm-smmu-v3: Add PMCG child support and update PMU MMIO mapping
From: Robin Murphy @ 2026-04-08 11:15 UTC (permalink / raw)
To: Peng Fan (OSS), Will Deacon, Joerg Roedel, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Mark Rutland
Cc: linux-arm-kernel, iommu, devicetree, linux-kernel,
linux-perf-users, Peng Fan
In-Reply-To: <20260408-smmu-perf-v1-0-d75dac96e828@nxp.com>
On 2026-04-08 8:51 am, Peng Fan (OSS) wrote:
> This patch series adds proper support for describing and probing the
> Arm SMMU v3 PMCG (Performance Monitor Control Group) as a child node of
> the SMMU in Devicetree, and updates the relevant drivers accordingly.
>
> The SMMU v3 architecture allows an optional PMCG block, typically
> associated with TCUs, to be implemented within the SMMU register
> address space. For example, mmu700 PMCG is at the offset 0x2000 of the
> TCU page 0.
But what's wrong with the existing binding? Especially given that it
even has an upstream user already:
https://git.kernel.org/torvalds/c/aef9703dcbf8
> Patch 1 updates the SMMU v3 Devicetree binding to allow PMCG child nodes,
> referencing the existing arm,smmu-v3-pmcg binding.
>
> Patch 2 updates the arm-smmu-v3 driver to populate platform devices for
> child nodes described in DT once the SMMU probe succeeds.
>
> Patch 3 updates the SMMUv3 PMU driver to correctly handle MMIO mapping when
> PMCG is described as a child node. The PMCG registers occupy a sub-region
> of the parent SMMU MMIO window, which is already requested by the SMMU
That has not been the case since 52f3fab0067d ("iommu/arm-smmu-v3: Don't
reserve implementation defined register space") nearly 6 years ago,
where the whole purpose was to support Arm's PMCG implementation
properly. What kernel is this based on?
Thanks,
Robin.
> Signed-off-by: Peng Fan <peng.fan@nxp.com>
> ---
> Peng Fan (3):
> dt-bindings: iommu: arm-smmu-v3: Allow PMU child nodes
> iommu/arm-smmu-v3: Populate PMU child devices from Devicetree
> perf/arm-smmuv3: Avoid double-requesting shared SMMU MMIO for PMCG
>
> .../devicetree/bindings/iommu/arm,smmu-v3.yaml | 10 ++++++++++
> drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c | 3 +++
> drivers/perf/arm_smmuv3_pmu.c | 19 ++++++++++++++++---
> 3 files changed, 29 insertions(+), 3 deletions(-)
> ---
> base-commit: f3e6330d7fe42b204af05a2dbc68b379e0ad179e
> change-id: 20260408-smmu-perf-754367fe66c8
>
> Best regards,
^ permalink raw reply
* Re: [PATCH v2 2/2] drm: bridge: ti-sn65dsi83: Add support for dual-link LVDS video mode
From: tessolveupstream @ 2026-04-08 11:10 UTC (permalink / raw)
To: Luca Ceresoli, andrzej.hajda, neil.armstrong, rfoss, Marek Vasut,
Alexander Stein
Cc: Laurent.pinchart, jonas, jernej.skrabec, maarten.lankhorst,
mripard, tzimmermann, airlied, simona, robh, krzk+dt, conor+dt,
marex, valentin, philippe.schenker, dri-devel, linux-kernel,
devicetree
In-Reply-To: <35eed359-8088-4ec0-9e16-e5cb31e0952e@gmail.com>
On 06-04-2026 14:05, tessolveupstream@gmail.com wrote:
>
>
> On 18-03-2026 14:22, Luca Ceresoli wrote:
>> Hello Sudarshan,
>>
>> On Wed Mar 18, 2026 at 6:53 AM CET, tessolveupstream wrote:
>>>>> + if (ctx->dual_link_video_mode) {
>>>>> + regmap_write(ctx->regmap, REG_RC_LVDS_PLL, 0x05);
>>>>> + regmap_write(ctx->regmap, REG_RC_PLL_EN, 0x00);
>>>>> + regmap_write(ctx->regmap, REG_DSI_CLK, 0x53);
>>>>> + regmap_write(ctx->regmap, REG_LVDS_FMT, 0x6f);
>>>>> + regmap_write(ctx->regmap, REG_LVDS_VCOM, 0x00);
>>>>> + regmap_write(ctx->regmap,
>>>>> + REG_VID_CHA_VERTICAL_DISPLAY_SIZE_LOW, 0x00);
>>>>> + regmap_write(ctx->regmap,
>>>>> + REG_VID_CHA_VERTICAL_DISPLAY_SIZE_HIGH, 0x00);
>>>>> + regmap_write(ctx->regmap,
>>>>> + REG_VID_CHA_HSYNC_PULSE_WIDTH_LOW, 0x10);
>>>>> + regmap_write(ctx->regmap,
>>>>> + REG_VID_CHA_HORIZONTAL_BACK_PORCH, 0x28);
>>>>> + regmap_write(ctx->regmap,
>>>>> + REG_VID_CHA_VERTICAL_BACK_PORCH, 0x00);
>>>>> + regmap_write(ctx->regmap,
>>>>> + REG_VID_CHA_HORIZONTAL_FRONT_PORCH, 0x00);
>>>>> + regmap_write(ctx->regmap,
>>>>> + REG_VID_CHA_VERTICAL_FRONT_PORCH, 0x00);
>>>>> + }
>>>>
>>>> I guess these hard-coded values are sepcific to your panel. They must
>>>> instead be computed based on the timings in order to work for every panel.
>>>>
>>>
>>> The hard-coded values were initially derived from the TI DSI Tuner output
>>> during our bring-up testing. TI had also mentioned that when PATGEN is
>>> enabled with dual-LVDS output on the SN65DSI84, the horizontal timings
>>> must be divided by 2. They also noted that the current driver does not
>>> appear to divide the horizontal timings when PATGEN is enabled in
>>> dual-LVDS mode.
>>>
>>> Based on that suggestion, we had tried adjusting the horizontal timing
>>> registers accordingly to match the tuner output.
>>> Could you please advise how these register values are expected to be
>>> derived from the mode timings so that they work correctly for different
>>> panels?
>>
>> Well, the principle is quite simple:
>>
>> 1. the panel docs tell you which timings the panel needs, e.g. HBP must be
>> 10 clock cycles
>>
>> 2. your panel description in dts or implementation in a panel driver will
>> then be written accordingly
>>
>> 3. the ti-sn65dsi83 driver will receive a struct drm_display_mode* with
>> these values
>>
>> 4. based on those values it sets the registers so the SN65DSI84 uses the
>> timings required by the panel (with a bit of math if needed):
>>
>> regmap_write(ctx->regmap, REG_VID_CHA_HORIZONTAL_BACK_PORCH,
>> mode->htotal - mode->hsync_end);
>>
>> Same for all other timings.
>>
>> Ti is more complicated if more cases need to be handled, such as dual-LVDS,
>> and the chip documentation is vague about what must be done in those cases.
>>
>> I suggested next steps to move forward in reply to the cover letter.
>>
>
> Thank you so much for your suggestion.
>
>>>>> @@ -965,9 +1001,15 @@ static int sn65dsi83_host_attach(struct sn65dsi83 *ctx)
>>>>>
>>>>> dsi->lanes = dsi_lanes;
>>>>> dsi->format = MIPI_DSI_FMT_RGB888;
>>>>> - dsi->mode_flags = MIPI_DSI_MODE_VIDEO | MIPI_DSI_MODE_VIDEO_BURST |
>>>>> - MIPI_DSI_MODE_VIDEO_NO_HFP | MIPI_DSI_MODE_VIDEO_NO_HBP |
>>>>> - MIPI_DSI_MODE_VIDEO_NO_HSA | MIPI_DSI_MODE_NO_EOT_PACKET;
>>>>> + if (ctx->dual_link_video_mode)
>>>>> + dsi->mode_flags = MIPI_DSI_MODE_VIDEO;
>>>>> + else
>>>>> + dsi->mode_flags = MIPI_DSI_MODE_VIDEO |
>>>>> + MIPI_DSI_MODE_VIDEO_BURST |
>>>>> + MIPI_DSI_MODE_VIDEO_NO_HFP |
>>>>> + MIPI_DSI_MODE_VIDEO_NO_HBP |
>>>>> + MIPI_DSI_MODE_VIDEO_NO_HSA |
>>>>> + MIPI_DSI_MODE_NO_EOT_PACKET;
>>>>
>>>> There is no explanation about this, can you elaborate on why?
>>>>
>>>> I'm working on bringing up a dual-LVDS panel on a board with the SN65DSI84,
>>>> and the removing MIPI_DSI_MODE_VIDEO_BURST seems to help, but I still have
>>>> no idea why. Should you have any info, maybe from TI, it would be very
>>>> interesting.
>>>>
>>>
>>> During our earlier bring-up, TI mentioned that one possible reason for the DSI
>>> REFCLK not behaving as expected could be that the DSI output is configured in
>>> burst mode instead of non-burst mode. In burst mode the DSI clock may not be
>>> continuous, whereas non-burst mode provides a more predictable DSI clock.
>>
>> Uhm, this is a bit vague. They basically said "burst can be more
>> problematic than continuous", which is obvious, and "try disabling burst
>> and see whether it helps" with no explanation on why one works and not the
>> other. Shoudl you have more info from them you'd be welcome to share it. In
>> particular, is disabling burst mode specifically related to dual-LVDS, or
>> just a way to (try to) get rid of some problems without a clear
>> understanding?
>>
>> On my side I also have a dual-LVDS panel connected to a SN65DSI84, which
>> works only by disabling burst mode. I haven't tried upstreaming it because
>> I don't have an explanation of why it fixes the panel and so I have no idea
>> how to teach the driver when it should disable burst mode.
>>
>> Additionally inyour patch you remove many other flags. Any explanation from
>> those?
>>
>
> Thanks for your inputs.
>
> I wanted to share a quick observation from our side. With your suggested 3
> patches (links below), the panel started working after simplifying the
> dsi-> mode_flags:
>
> https://lore.kernel.org/all/20260226-ti-sn65dsi83-dual-lvds-fixes-and-test-pattern-v1-1-2e15f5a9a6a0@bootlin.com/
>
> https://lore.kernel.org/all/20260226-ti-sn65dsi83-dual-lvds-fixes-and-test-pattern-v1-2-2e15f5a9a6a0@bootlin.com/
>
> https://lore.kernel.org/lkml/20260309-ti-sn65dsi83-dual-lvds-fixes-and-test-pattern-v2-1-e6aaa7e1d181@bootlin.com/
>
> Earlier configuration:
>
> MIPI_DSI_MODE_VIDEO | MIPI_DSI_MODE_VIDEO_BURST |
> MIPI_DSI_MODE_VIDEO_NO_HFP | MIPI_DSI_MODE_VIDEO_NO_HBP |
> MIPI_DSI_MODE_VIDEO_NO_HSA | MIPI_DSI_MODE_NO_EOT_PACKET;
>
> Working configuration:
>
> MIPI_DSI_MODE_VIDEO | MIPI_DSI_MODE_VIDEO_NO_HSA |
> MIPI_DSI_MODE_NO_EOT_PACKET;
>
> From our testing, removing MIPI_DSI_MODE_VIDEO_BURST along with the NO_HFP/NO_HBP
> flags results in stable LVDS output in dual-link mode.
>
> Could you please suggest how you would prefer to handle this change for
> upstreaming?
>
I wanted to revisit the earlier discussion and share a consolidated summary
of our observations below.
With your suggested patches (links below), the panel started working after
simplifying the dsi->mode_flags:
https://lore.kernel.org/all/20260226-ti-sn65dsi83-dual-lvds-fixes-and-test-pattern-v1-1-2e15f5a9a6a0@bootlin.com/
https://lore.kernel.org/all/20260226-ti-sn65dsi83-dual-lvds-fixes-and-test-pattern-v1-2-2e15f5a9a6a0@bootlin.com/
https://lore.kernel.org/lkml/20260309-ti-sn65dsi83-dual-lvds-fixes-and-test-pattern-v2-1-e6aaa7e1d181@bootlin.com/
Working 'dsi-> mode_flags' configuration is:
dsi->mode_flags = MIPI_DSI_MODE_VIDEO | MIPI_DSI_MODE_VIDEO_NO_HSA |
MIPI_DSI_MODE_NO_EOT_PACKET;
From our testing, removing MIPI_DSI_MODE_VIDEO_BURST along with the NO_HFP
and NO_HBP flags results in stable LVDS output in dual-link mode.
Also I am sharing an update from our side after consulting the 'dsi->
mode_flags' behavior with the TI expert.
Based on their inputs:
1. The SN65DSI83/84 reconstructs LVDS timing from the incoming DSI stream
and requires explicit horizontal blanking (HFP/HBP) to do so reliably.
2. Suppressing HFP/HBP prevents correct timing reconstruction and can
result in unstable LVDS output, even when register timings are programmed.
3. DSI burst mode is supported, but depending on the host controller, it may
result in non‑continuous DSI clocking and HS/LP transitions.
4. Non‑burst (continuous) DSI video mode provides a more stable and
predictable timing stream, which is better suited for LVDS panels.
5. Ensuring continuous DSI video with standard horizontal blanking has been
observed to produce stable LVDS operation, particularly in dual‑link
configurations.
Given these observations, we would appreciate your guidance on how to
proceed with up-streaming.
>> Best regards,
>> Luca
>>
>> --
>> Luca Ceresoli, Bootlin
>> Embedded Linux and Kernel engineering
>> https://bootlin.com
>
^ permalink raw reply
* RE: [PATCH v4 net-next 12/14] net: dsa: netc: add more basic functions support
From: Wei Fang @ 2026-04-08 11:09 UTC (permalink / raw)
To: Jakub Kicinski
Cc: Claudiu Manoil, Vladimir Oltean, Clark Wang,
andrew+netdev@lunn.ch, davem@davemloft.net, edumazet@google.com,
pabeni@redhat.com, robh@kernel.org, krzk+dt@kernel.org,
conor+dt@kernel.org, f.fainelli@gmail.com, Frank Li,
chleroy@kernel.org, horms@kernel.org, linux@armlinux.org.uk,
andrew@lunn.ch, netdev@vger.kernel.org,
linux-kernel@vger.kernel.org, devicetree@vger.kernel.org,
linuxppc-dev@lists.ozlabs.org,
linux-arm-kernel@lists.infradead.org, imx@lists.linux.dev
In-Reply-To: <20260403011743.1795726-1-kuba@kernel.org>
> > +static int netc_add_standalone_vlan_entry(struct netc_switch *priv)
> > +{
> > + u32 bitmap_stg = VFT_STG_ID(0) | netc_available_port_bitmap(priv);
>
> Does putting all standalone ports into a single shared VLAN 0 break the DSA
> isolation requirements?
>
> If a user manually adds a static FDB entry to a standalone port, it is
> programmed into VLAN 0. Because all standalone ports reside in this VLAN, a
> frame arriving on one standalone port with a matching destination MAC might
> be hardware-switched directly to another standalone port, bypassing the CPU.
I think the FDB entry can only be added to the CPU port if the port is a
standalone port not a bridge port. So this case will not be true.
>
> [ ... ]
>
> > +static int netc_port_set_fdb_entry(struct netc_port *np,
> > + const unsigned char *addr, u16 vid)
> > +{
>
> [ ... ]
>
> > + /* If the entry already exists, but not on this port, we need to
> > + * update the port bitmap. In general, it should only be valid
> > + * for multicast or broadcast address.
> > + */
> > + port_bitmap ^= BIT(port);
> > + entry->cfge.port_bitmap = cpu_to_le32(port_bitmap);
>
> Can this XOR operation cause multi-port floods during unicast MAC migrations?
>
> When a unicast MAC address moves to a new port, the bridging layer issues an
> ADD for the new port. The XOR operation leaves the old port bit set alongside
> the new port bit. Does the driver need to differentiate between unicast and
> multicast addresses and explicitly overwrite the bitmap for unicast entries?
I think the old FDB entry should be removed first when a unicast MAC address
moves to a new port rather than only adding a new entry. If AI refers to adding
before deleting, then this problem will indeed occur, and it is unavoidable.
>
> [ ... ]
>
> > +static int netc_port_del_fdb_entry(struct netc_port *np,
> > + const unsigned char *addr, u16 vid)
> > +{
> > + struct netc_switch *priv = np->switch_priv;
> > + struct ntmp_user *ntmp = &priv->ntmp;
> > + struct netc_fdb_entry *entry;
> > + int port = np->dp->index;
> > + u32 port_bitmap;
> > + int err = 0;
> > +
> > + mutex_lock(&priv->fdbt_lock);
> > +
> > + entry = netc_lookup_fdb_entry(priv, addr, vid);
> > + if (unlikely(!entry))
> > + goto unlock_fdbt;
>
> Will this prevent dynamically learned FDB entries from being deleted?
>
> Since the CPU port is configured with MLO_HW, the switch hardware
Currently we only support single port mode, so only support static FDB
entry. The MLO_HW should be removed from the code, I will improve
the logic.
> dynamically
> learns MAC addresses, but they are not added to the software priv->fdb_list.
> If a user attempts to delete a dynamic entry, the software lookup will fail
> here and return 0 (success), leaving the stale dynamically learned entry
> active in hardware.
>
> [ ... ]
>
> > +static int netc_port_change_mtu(struct dsa_switch *ds,
> > + int port, int mtu)
> > +{
> > + u32 max_frame_size = mtu + VLAN_ETH_HLEN + ETH_FCS_LEN;
> > + struct netc_port *np = NETC_PORT(ds, port);
> > +
> > + if (dsa_is_cpu_port(ds, port))
> > + max_frame_size += NETC_TAG_MAX_LEN;
>
> Does this double-count the DSA tag overhead for the CPU port?
>
> The DSA core computes the CPU port's MTU by adding the tagger overhead
> before
> calling the switch's .port_change_mtu() function. If the maximum MTU of 9582
> bytes is requested, the CPU port receives an MTU of 9596. Adding
> NETC_TAG_MAX_LEN again here results in 9628 bytes, which exceeds the
> hardware limit of 9600 (NETC_MAX_FRAME_LEN) and might lead to truncation.
It seems a bug, I will fix it.
>
> [ ... ]
>
> > +static int netc_port_fdb_add(struct dsa_switch *ds, int port,
> > + const unsigned char *addr, u16 vid,
> > + struct dsa_db db)
> > +{
> > + struct netc_port *np = NETC_PORT(ds, port);
> > +
> > + /* Currently, we only support standalone port mode, so all VLANs
> > + * should be converted to NETC_STANDALONE_PVID.
> > + */
> > + return netc_port_set_fdb_entry(np, addr, NETC_STANDALONE_PVID);
> > +}
>
> Is it safe to silently override user-requested VLAN IDs to VLAN 0?
>
> If a user explicitly attempts to configure a MAC address for a specific VLAN,
> the hardware is programmed for VLAN 0 and returns success. Should this
> instead check if the requested vid is not 0 and not NETC_STANDALONE_PVID,
> and return -EOPNOTSUPP to inform the networking stack?
Okay, I will add a check.
>
> [ ... ]
>
> > +static void netc_port_set_host_flood(struct dsa_switch *ds, int port,
> > + bool uc, bool mc)
> > +{
> > + struct netc_port *np = NETC_PORT(ds, port);
> > +
> > + if (np->uc == uc && np->mc == mc)
> > + return;
> > +
> > + /* IPFT does not support in-place updates to the KEYE element,
> > + * so we need to delete the old IPFT entry and then add a new
> > + * one.
> > + */
> > + if (np->host_flood)
> > + netc_port_remove_host_flood(np);
> > +
> > + if (netc_port_add_host_flood_rule(np, uc, mc))
> > + dev_err(ds->dev, "Failed to add host flood rule on port %d\n",
> > + port);
> > +}
>
> Could this permanently lose the host flood configuration if the new rule
> addition fails?
>
> If the call to netc_port_add_host_flood_rule() fails (for example, due to
> -ENOMEM), the function logs an error and returns, leaving the port entirely
> without a host flood rule. Should the driver revert to the previous
> configuration on failure to avoid blackholing traffic meant for the CPU?
Okay, I will improve it.
^ permalink raw reply
* Re: [PATCH v6 17/21] media: dt-bindings: media: renesas,fcp: Document RZ/G3E SoC
From: Laurent Pinchart @ 2026-04-08 10:53 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,
Krzysztof Kozlowski
In-Reply-To: <5aaf561a66c24639477a99d3861ca969a81673f0.1775636898.git.tommaso.merciai.xr@bp.renesas.com>
On Wed, Apr 08, 2026 at 12:37:02PM +0200, Tommaso Merciai wrote:
> The FCPVD block on the RZ/G3E SoC is identical to the one found on the
> RZ/G2L SoC.
>
> No driver changes are required, as `renesas,fcpv` will be used as a
> fallback compatible string on the RZ/G3E SoC.
>
> Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
> Acked-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
> Signed-off-by: Tommaso Merciai <tommaso.merciai.xr@bp.renesas.com>
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:
> - Collected tags.
>
> Documentation/devicetree/bindings/media/renesas,fcp.yaml | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/media/renesas,fcp.yaml b/Documentation/devicetree/bindings/media/renesas,fcp.yaml
> index b5eff6fec8a9..f7e486e90e43 100644
> --- a/Documentation/devicetree/bindings/media/renesas,fcp.yaml
> +++ b/Documentation/devicetree/bindings/media/renesas,fcp.yaml
> @@ -30,6 +30,7 @@ properties:
> - renesas,r9a07g043u-fcpvd # RZ/G2UL
> - renesas,r9a07g044-fcpvd # RZ/G2{L,LC}
> - renesas,r9a07g054-fcpvd # RZ/V2L
> + - renesas,r9a09g047-fcpvd # RZ/G3E
> - renesas,r9a09g056-fcpvd # RZ/V2N
> - renesas,r9a09g057-fcpvd # RZ/V2H(P)
> - const: renesas,fcpv # Generic FCP for VSP fallback
> @@ -77,6 +78,7 @@ allOf:
> - renesas,r9a07g043u-fcpvd
> - renesas,r9a07g044-fcpvd
> - renesas,r9a07g054-fcpvd
> + - renesas,r9a09g047-fcpvd
> - renesas,r9a09g056-fcpvd
> - renesas,r9a09g057-fcpvd
> then:
--
Regards,
Laurent Pinchart
^ permalink raw reply
* Re: [PATCH v6 16/21] media: dt-bindings: media: renesas,vsp1: Document RZ/G3E
From: Laurent Pinchart @ 2026-04-08 10:52 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,
Krzysztof Kozlowski
In-Reply-To: <c1e2eb36af01e0cddd8050ba70847c3a0821c91e.1775636898.git.tommaso.merciai.xr@bp.renesas.com>
On Wed, Apr 08, 2026 at 12:37:01PM +0200, Tommaso Merciai wrote:
> The VSPD block on the RZ/G3E SoC is identical to the one found on the
> RZ/G2L SoC.
>
> No driver changes are required, as `renesas,r9a07g044-vsp2` will be used
> as a fallback compatible string on the RZ/G3E SoC.
>
> Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
> Acked-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
> Signed-off-by: Tommaso Merciai <tommaso.merciai.xr@bp.renesas.com>
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:
> - Collected tags.
>
> Documentation/devicetree/bindings/media/renesas,vsp1.yaml | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/Documentation/devicetree/bindings/media/renesas,vsp1.yaml b/Documentation/devicetree/bindings/media/renesas,vsp1.yaml
> index 07a97dd87a5b..62bff3ce3eaa 100644
> --- a/Documentation/devicetree/bindings/media/renesas,vsp1.yaml
> +++ b/Documentation/devicetree/bindings/media/renesas,vsp1.yaml
> @@ -25,6 +25,7 @@ properties:
> - enum:
> - renesas,r9a07g043u-vsp2 # RZ/G2UL
> - renesas,r9a07g054-vsp2 # RZ/V2L
> + - renesas,r9a09g047-vsp2 # RZ/G3E
> - renesas,r9a09g056-vsp2 # RZ/V2N
> - renesas,r9a09g057-vsp2 # RZ/V2H(P)
> - const: renesas,r9a07g044-vsp2 # RZ/G2L fallback
--
Regards,
Laurent Pinchart
^ permalink raw reply
* Re: [PATCH] arm64: dts: imx93-9x9-qsb: Add tianma,tm050rdh03 panel
From: Frank Li @ 2026-04-08 10:50 UTC (permalink / raw)
To: Liu Ying
Cc: Sascha Hauer, Pengutronix Kernel Team, Fabio Estevam, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, imx, linux-arm-kernel,
devicetree, linux-kernel
In-Reply-To: <5ce48659-2c6c-4c60-a8e8-9031bdbaa2a3@nxp.com>
On Wed, Apr 08, 2026 at 04:40:37PM +0800, Liu Ying wrote:
> On Wed, Apr 08, 2026 at 04:28:40AM -0400, Frank Li wrote:
...
> >>>>>
> >>>>> Is it possible to appply this overlay file and kd50g21-40nt-a1 overlay file
> >>>>>
> >>>>> to imx93-9x9-qsb.dtb, so needn't create dtsi.
> >>>>
> >>>> I'm sorry, I don't get your question here.
> >>>> Anyway, the DT overlays are needed, because the 40-pin EXP/PRI interface on
> >>>> the i.MX93 9x9 QSB board can not only connect to a DPI panel adapter board
> >>>> but also to an audio hat[2], and maybe more. The newly introduced .dtsi
> >>>> file just aims to avoid duplicated code.
> >>>
> >>> My means apply two overlay files to dtb
> >>>
> >>> imx93-9x9-qsb-tianma-tm050rdh03-dtbs += imx93-9x9-qsb.dtb imx93-9x9-qsb-ontat-kd50g21-40nt-a1.dtbo imx93-9x9-qsb-tianma-tm050rdh03.dtbo
>
> This ...
>
> >>>
> >>> In imx93-9x9-qsb-tianma-tm050rdh03.dtbo, only include
> >>> &{/} {
> >>> panel {
> >>> compatible = "tianma,tm050rdh03";
> >>> enable-gpios = <&pcal6524 8 GPIO_ACTIVE_HIGH>;
> >>> };
> >>> };
> >>
> >> If an user wants to use imx93-9x9-qsb.dtb and the DT overlay blob
> >> imx93-9x9-qsb-tianma-tm050rdh03.dtbo to enable the tianma,tm050rdh03
> >> DPI panel, then it won't work unless the user also apply
> >> imx93-9x9-qsb-ontat-kd50g21-40nt-a1.dtbo, right?
> >>
> >>>
> >
> > Yes, imx93-9x9-qsb-tianma-tm050rdh03.dtb already created, which already
> > applied both overlay file.
>
> .... indicates that imx93-9x9-qsb-tianma-tm050rdh03.dtb is generated by
> applying both imx93-9x9-qsb-ontat-kd50g21-40nt-a1.dtbo and
> imx93-9x9-qsb-tianma-tm050rdh03.dtbo to imx93-9x9-qsb.dtb.
> While, imx93-9x9-qsb-tianma-tm050rdh03.dtbo(a DT overlay blob) just contains
> the panel node, which means that an user __cannot_ enable the tianma,tm050rdh03
> DPI panel by only applying it to imx93-9x9-qsb.dtb, unless the user also
> applies imx93-9x9-qsb-ontat-kd50g21-40nt-a1.dtbo. That's why the .dtsi
> file is needed.
what's problem if we require user do that? Makefile already create finial
imx93-9x9-qsb-tianma-tm050rdh03.dtb.
Any user really apply dtso manaully without use kernel's Makefile?
>
> >
> > can the same board be use for imx91 or other evk boards?
>
> Yes, both tianma,tm050rdh03 and ontat,kd50g21-40nt-a1 DPI panels can be
> connected to i.MX91/93 11x11 EVK and 9x9 QSB boards.
Is it possible to use one overlay files for all imx91/imx93 boards?
Frank
>
> >
> > Frank
> >
> >>> Frank
> >>>>
> >>>> [2] https://www.nxp.com/design/design-center/development-boards-and-designs/mx93aud-hat-audio-board:MX93AUD-HAT
> >>>>
> >>>>>
> >>>>> Frank
> >>>>>>
> >>>>>> ---
> >>>>>> base-commit: 816f193dd0d95246f208590924dd962b192def78
> >>>>>> change-id: 20260407-tianma-tm050rdh03-imx93-9x9-qsb-6e4bbbde3d08
> >>>>>>
> >>>>>> Best regards,
> >>>>>> --
> >>>>>> Liu Ying <victor.liu@nxp.com>
> >>>>>>
> >>>>
> >>>> --
> >>>> Regards,
> >>>> Liu Ying
> >>
> >> --
> >> Regards,
> >> Liu Ying
>
> --
> Regards,
> Liu Ying
^ permalink raw reply
* Re: [PATCH v2 2/2] pwm: clk-pwm: add GPIO and pinctrl support for constant output levels
From: Nikita Travkin @ 2026-04-08 10:42 UTC (permalink / raw)
To: Xilin Wu
Cc: Uwe Kleine-König, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, linux-pwm, devicetree, linux-kernel, linux-arm-msm
In-Reply-To: <20260408-clk-pwm-gpio-v2-2-d22f1f3498a0@radxa.com>
Xilin Wu писал(а) 08.04.2026 15:07:
> The clk-pwm driver cannot guarantee a defined output level when the
> PWM is disabled or when 0%/100% duty cycle is requested, because the
> pin state when the clock is stopped is hardware-dependent.
>
> Add optional GPIO and pinctrl support: when a GPIO descriptor and
> pinctrl states ("default" for clock mux, "gpio" for GPIO mode) are
> provided in the device tree, the driver switches the pin to GPIO mode
> and drives the appropriate level for disabled/0%/100% states. For
> normal PWM output, the pin is switched back to its clock function mux.
>
> If no GPIO is provided, the driver falls back to the original
> clock-only behavior.
>
> Signed-off-by: Xilin Wu <sophon@radxa.com>
> ---
> drivers/pwm/pwm-clk.c | 84 ++++++++++++++++++++++++++++++++++++++++++++++++---
> 1 file changed, 80 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/pwm/pwm-clk.c b/drivers/pwm/pwm-clk.c
> index f8f5af57acba..d7d8d2c2dd0f 100644
> --- a/drivers/pwm/pwm-clk.c
> +++ b/drivers/pwm/pwm-clk.c
> @@ -11,11 +11,20 @@
> * - Due to the fact that exact behavior depends on the underlying
> * clock driver, various limitations are possible.
> * - Underlying clock may not be able to give 0% or 100% duty cycle
> - * (constant off or on), exact behavior will depend on the clock.
> + * (constant off or on), exact behavior will depend on the clock,
> + * unless a gpio pinctrl state is supplied.
> * - When the PWM is disabled, the clock will be disabled as well,
> - * line state will depend on the clock.
> + * line state will depend on the clock, unless a gpio pinctrl
> + * state is supplied.
> * - The clk API doesn't expose the necessary calls to implement
> * .get_state().
> + *
> + * Optionally, a GPIO descriptor and pinctrl states ("default" and
> + * "gpio") can be provided. When a constant output level is needed
> + * (0% duty, 100% duty, or disabled), the driver switches the pin to
> + * GPIO mode and drives the appropriate level. For normal PWM output
> + * the pin is switched back to its clock function mux. If no GPIO is
> + * provided, the driver falls back to the original clock-only behavior.
> */
>
> #include <linux/kernel.h>
> @@ -25,11 +34,17 @@
> #include <linux/of.h>
> #include <linux/platform_device.h>
> #include <linux/clk.h>
> +#include <linux/gpio/consumer.h>
> +#include <linux/pinctrl/consumer.h>
> #include <linux/pwm.h>
>
> struct pwm_clk_chip {
> struct clk *clk;
> bool clk_enabled;
> + struct pinctrl *pinctrl;
> + struct pinctrl_state *pins_default; /* clock function mux */
> + struct pinctrl_state *pins_gpio; /* GPIO mode */
> + struct gpio_desc *gpiod;
> };
>
> static inline struct pwm_clk_chip *to_pwm_clk_chip(struct pwm_chip *chip)
> @@ -45,14 +60,36 @@ static int pwm_clk_apply(struct pwm_chip *chip, struct pwm_device *pwm,
> u32 rate;
> u64 period = state->period;
> u64 duty_cycle = state->duty_cycle;
> + bool constant_level = false;
> + int gpio_value = 0;
>
> if (!state->enabled) {
> - if (pwm->state.enabled) {
> + constant_level = true;
> + gpio_value = 0;
> + } else if (state->duty_cycle == 0) {
> + constant_level = true;
> + gpio_value = (state->polarity == PWM_POLARITY_INVERSED) ? 1 : 0;
> + } else if (state->duty_cycle >= state->period) {
> + constant_level = true;
> + gpio_value = (state->polarity == PWM_POLARITY_INVERSED) ? 0 : 1;
> + }
> +
So I'm looking at it again, and I'm a bit confused.
Old behavior was:
- pwm was enabled and being disabled -> stop the clock and hope state is 0;
- pwm is still enabled but
- duty=0% -> set clk duty to 0%
- duty=100% -> set clk duty to 100%
New behavior if we have gpio:
- pwm was enabled and being disabled -> constant 0
- pwm is still enabled but
- duty=0% -> constant 0
- duty=100% -> constant 1
New behavior if we don't have gpio:
Same as above but
- if we need constant 0 -> clock is halted and we pray it's 0
- if we need constant 1 -> clock is halted and we pray it's 1 (??)
Per my recollection, when I wrote this driver 5 years ago, I've manually
verified that at least on qcom setting duty cycle to 0% and 100% worked
properly, so this feels like it would regress it if left as-is...
(Btw I wonder what's the platform you need this for?)
> + if (constant_level) {
> + if (pcchip->gpiod) {
> + gpiod_direction_output(pcchip->gpiod, gpio_value);
> + pinctrl_select_state(pcchip->pinctrl, pcchip->pins_gpio);
> + }
> + if (pcchip->clk_enabled) {
> clk_disable(pcchip->clk);
> pcchip->clk_enabled = false;
> }
> return 0;
> - } else if (!pwm->state.enabled) {
> + }
> +
> + if (pcchip->gpiod)
> + pinctrl_select_state(pcchip->pinctrl, pcchip->pins_default);
> +
> + if (!pcchip->clk_enabled) {
> ret = clk_enable(pcchip->clk);
> if (ret)
> return ret;
> @@ -97,6 +134,45 @@ static int pwm_clk_probe(struct platform_device *pdev)
> return dev_err_probe(&pdev->dev, PTR_ERR(pcchip->clk),
> "Failed to get clock\n");
>
> + pcchip->pinctrl = devm_pinctrl_get(&pdev->dev);
> + if (IS_ERR(pcchip->pinctrl)) {
> + ret = PTR_ERR(pcchip->pinctrl);
> + pcchip->pinctrl = NULL;
> + if (ret == -EPROBE_DEFER)
> + return ret;
> + } else {
> + pcchip->pins_default = pinctrl_lookup_state(pcchip->pinctrl,
> + PINCTRL_STATE_DEFAULT);
> + pcchip->pins_gpio = pinctrl_lookup_state(pcchip->pinctrl,
> + "gpio");
> + if (IS_ERR(pcchip->pins_default) || IS_ERR(pcchip->pins_gpio))
> + pcchip->pinctrl = NULL;
> + }
> +
> + /*
> + * Switch to GPIO pinctrl state before requesting the GPIO.
> + * The driver core has already applied the "default" state, which
> + * muxes the pin to the clock function and claims it. We must
> + * release that claim first so that gpiolib can request the pin.
> + */
> + if (pcchip->pinctrl)
> + pinctrl_select_state(pcchip->pinctrl, pcchip->pins_gpio);
> +
> + pcchip->gpiod = devm_gpiod_get_optional(&pdev->dev, NULL, GPIOD_ASIS);
> + if (IS_ERR(pcchip->gpiod))
> + return dev_err_probe(&pdev->dev, PTR_ERR(pcchip->gpiod),
> + "Failed to get gpio\n");
> +
> + /*
> + * If pinctrl states were found but no GPIO was provided, the pin is
> + * stuck in GPIO mode from the switch above. Restore the default
> + * (clock-function) mux and fall back to clock-only operation.
> + */
Feels slightly weird to silently allow "broken" DT, it would make no sense
for it to have "gpio" pinctrl and not have a gpio defined, would it?
Perhaps it makes more sense to put getting a gpio under having pins_gpio
and make it strict, so two allowed states for the driver would be either
no pinctrl-1 and no gpio, or having both at the same time?
(maybe then also worth adding cross dependency of pinctrl-1 and gpio in
the binding, it's one way only currently, not sure what's the correct
way to describe it tho)
Nikita
> + if (pcchip->pinctrl && !pcchip->gpiod) {
> + pinctrl_select_state(pcchip->pinctrl, pcchip->pins_default);
> + pcchip->pinctrl = NULL;
> + }
> +
> chip->ops = &pwm_clk_ops;
>
> ret = pwmchip_add(chip);
^ permalink raw reply
* Re: [PATCH v13 2/7] qcom-tgu: Add TGU driver
From: Konrad Dybcio @ 2026-04-08 10:42 UTC (permalink / raw)
To: Songwei Chai, andersson, alexander.shishkin, mike.leach,
suzuki.poulose, james.clark, krzk+dt, conor+dt
Cc: linux-kernel, linux-arm-kernel, linux-arm-msm, coresight,
devicetree, gregkh
In-Reply-To: <20260402092838.341295-3-songwei.chai@oss.qualcomm.com>
On 4/2/26 11:28 AM, Songwei Chai wrote:
> Add driver to support device TGU (Trigger Generation Unit).
> TGU is a Data Engine which can be utilized to sense a plurality of
> signals and create a trigger into the CTI or generate interrupts to
> processors. Add probe/enable/disable functions for tgu.
>
> Signed-off-by: Songwei Chai <songwei.chai@oss.qualcomm.com>
> ---
Acked-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
Konrad
^ permalink raw reply
* Re: [PATCH v4 2/5] media: iris: Add hardware power on/off ops for X1P42100
From: Krzysztof Kozlowski @ 2026-04-08 10:41 UTC (permalink / raw)
To: Wangao Wang
Cc: Bryan O'Donoghue, Vikash Garodia, Dikshita Agarwal,
Abhinav Kumar, Mauro Carvalho Chehab, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Bjorn Andersson, Konrad Dybcio,
linux-media, linux-arm-msm, devicetree, linux-kernel
In-Reply-To: <9bd4e289-9cf1-4502-baa5-d85cf6e07df1@oss.qualcomm.com>
On 08/04/2026 11:16, Wangao Wang wrote:
>
>
> On 2026/4/2 15:08, Krzysztof Kozlowski wrote:
>>
>> Why no IRIS_HW_AHB_CLK in power on sequence?
>>
>> So if you rewrite the code that you have list of clocks for hw power on
>> (IRIS_HW_CLK + IRIS_HW_AHB_CLK for all variants, +IRIS_BSE_HW_CLK on
>> this variant) you could have just one function for all of them and
>> devices will be fully compatible.
>>
>> No?
>>
> The original patch was to add the IRIS_BSE_HW_CLK operation into the
> common API, but Dmitry requested to separate Purwa's implementation out
> independently.
So you don't know why you are doing things? I don't understand what sort
of argument is that.
You are duplicating code, while all this is simply the same logic -
three clocks which need to be enabled.
Best regards,
Krzysztof
^ permalink raw reply
* [PATCH v6 21/21] arm64: dts: renesas: r9a09g047e57-smarc: Enable DU0 and DSI support
From: Tommaso Merciai @ 2026-04-08 10:37 UTC (permalink / raw)
To: tomm.merciai, geert, laurent.pinchart
Cc: linux-renesas-soc, biju.das.jz, Tommaso Merciai,
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: <cover.1775636898.git.tommaso.merciai.xr@bp.renesas.com>
Enable DU0, DSI and ADV7535 on RZ/G3E SMARC EVK.
Signed-off-by: Tommaso Merciai <tommaso.merciai.xr@bp.renesas.com>
---
v5->v6:
- No changes.
v4->v5:
- Use DU0 -> DSI instead of DU1 -> DSI and update commit body and commit
message accordingly.
v3->v4:
- No changes.
v2->v3:
- No changes.
v1->v2:
- Fixed: dsi, du and adv7535 are part of the the R9A09G047E57
SMARC SoM board then add entries in the rzg3e-smarc-som.dtsi instead
of using the r9a09g047e57-smarc-du1-adv7535.dtsi.
.../boot/dts/renesas/rzg3e-smarc-som.dtsi | 114 ++++++++++++++++++
1 file changed, 114 insertions(+)
diff --git a/arch/arm64/boot/dts/renesas/rzg3e-smarc-som.dtsi b/arch/arm64/boot/dts/renesas/rzg3e-smarc-som.dtsi
index d978619155d2..74a5e4a9f312 100644
--- 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 {
+ 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;
+ };
+
+ osc1: cec-clock {
+ 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 {
+ 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 {
+ 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";
@@ -240,6 +349,11 @@ i2c2_pins: i2c {
<RZG3E_PORT_PINMUX(3, 5, 1)>; /* SDA2 */
};
+ i2c7_pins: i2c7 {
+ pinmux = <RZG3E_PORT_PINMUX(A, 4, 4)>, /* SCL7 */
+ <RZG3E_PORT_PINMUX(A, 5, 4)>; /* SDA7 */
+ };
+
i3c_pins: i3c {
pinmux = <RZG3E_PORT_PINMUX(2, 0, 2)>, /* I3C0_SCL */
<RZG3E_PORT_PINMUX(2, 1, 2)>; /* I3C0_SDA */
--
2.43.0
^ permalink raw reply related
* [PATCH v6 20/21] arm64: dts: renesas: r9a09g047: Add DU{0,1} and DSI nodes
From: Tommaso Merciai @ 2026-04-08 10:37 UTC (permalink / raw)
To: tomm.merciai, geert, laurent.pinchart
Cc: linux-renesas-soc, biju.das.jz, Tommaso Merciai,
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: <cover.1775636898.git.tommaso.merciai.xr@bp.renesas.com>
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>;
+ 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";
--
2.43.0
^ permalink raw reply related
* [PATCH v6 19/21] arm64: dts: renesas: r9a09g047: Add vspd{0,1} nodes
From: Tommaso Merciai @ 2026-04-08 10:37 UTC (permalink / raw)
To: tomm.merciai, geert, laurent.pinchart
Cc: linux-renesas-soc, biju.das.jz, Tommaso Merciai,
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: <cover.1775636898.git.tommaso.merciai.xr@bp.renesas.com>
Add vspd{0,1} nodes to RZ/G3E SoC DTSI.
Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
Signed-off-by: Tommaso Merciai <tommaso.merciai.xr@bp.renesas.com>
---
v5->v6:
- No changes.
v4->v5:
- No changes.
v3->v4:
- No changes.
v2->v3:
- No changes.
v1->v2:
- Squashed vspd0 and vspd1 patches into a single patch.
- Collected tags.
arch/arm64/boot/dts/renesas/r9a09g047.dtsi | 28 ++++++++++++++++++++++
1 file changed, 28 insertions(+)
diff --git a/arch/arm64/boot/dts/renesas/r9a09g047.dtsi b/arch/arm64/boot/dts/renesas/r9a09g047.dtsi
index 3115ab4b050f..f2fdaadd9d39 100644
--- a/arch/arm64/boot/dts/renesas/r9a09g047.dtsi
+++ b/arch/arm64/boot/dts/renesas/r9a09g047.dtsi
@@ -1608,6 +1608,34 @@ fcpvd1: fcp@164a0000 {
resets = <&cpg 0x11e>;
power-domains = <&cpg>;
};
+
+ vspd0: vsp@16480000 {
+ compatible = "renesas,r9a09g047-vsp2",
+ "renesas,r9a07g044-vsp2";
+ reg = <0 0x16480000 0 0x10000>;
+ interrupts = <GIC_SPI 881 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&cpg CPG_MOD 0xed>,
+ <&cpg CPG_MOD 0xee>,
+ <&cpg CPG_MOD 0xef>;
+ clock-names = "aclk", "pclk", "vclk";
+ resets = <&cpg 0xdc>;
+ power-domains = <&cpg>;
+ renesas,fcp = <&fcpvd0>;
+ };
+
+ vspd1: vsp@164b0000 {
+ compatible = "renesas,r9a09g047-vsp2",
+ "renesas,r9a07g044-vsp2";
+ reg = <0 0x164b0000 0 0x10000>;
+ interrupts = <GIC_SPI 921 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&cpg CPG_MOD 0x1a8>,
+ <&cpg CPG_MOD 0x1a9>,
+ <&cpg CPG_MOD 0x1aa>;
+ clock-names = "aclk", "pclk", "vclk";
+ resets = <&cpg 0x11e>;
+ power-domains = <&cpg>;
+ renesas,fcp = <&fcpvd1>;
+ };
};
stmmac_axi_setup: stmmac-axi-config {
--
2.43.0
^ permalink raw reply related
* [PATCH v6 18/21] arm64: dts: renesas: r9a09g047: Add fcpvd{0,1} nodes
From: Tommaso Merciai @ 2026-04-08 10:37 UTC (permalink / raw)
To: tomm.merciai, geert, laurent.pinchart
Cc: linux-renesas-soc, biju.das.jz, Tommaso Merciai,
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: <cover.1775636898.git.tommaso.merciai.xr@bp.renesas.com>
Add fcpvd{0,1} nodes to RZ/G3E SoC DTSI.
Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
Signed-off-by: Tommaso Merciai <tommaso.merciai.xr@bp.renesas.com>
---
v5->v6:
- No changes.
v4->v5:
- No changes.
v3->v4:
- No changes.
v2->v3:
- No changes.
v1->v2:
- Squashed fcpvd0 and fcpvd1 patches into a single patch.
- Collected tags.
arch/arm64/boot/dts/renesas/r9a09g047.dtsi | 24 ++++++++++++++++++++++
1 file changed, 24 insertions(+)
diff --git a/arch/arm64/boot/dts/renesas/r9a09g047.dtsi b/arch/arm64/boot/dts/renesas/r9a09g047.dtsi
index 95a4e30a064d..3115ab4b050f 100644
--- a/arch/arm64/boot/dts/renesas/r9a09g047.dtsi
+++ b/arch/arm64/boot/dts/renesas/r9a09g047.dtsi
@@ -1584,6 +1584,30 @@ csi2cru: endpoint@0 {
};
};
};
+
+ fcpvd0: fcp@16470000 {
+ compatible = "renesas,r9a09g047-fcpvd",
+ "renesas,fcpv";
+ reg = <0 0x16470000 0 0x10000>;
+ clocks = <&cpg CPG_MOD 0xed>,
+ <&cpg CPG_MOD 0xee>,
+ <&cpg CPG_MOD 0xef>;
+ clock-names = "aclk", "pclk", "vclk";
+ resets = <&cpg 0xdc>;
+ power-domains = <&cpg>;
+ };
+
+ fcpvd1: fcp@164a0000 {
+ compatible = "renesas,r9a09g047-fcpvd",
+ "renesas,fcpv";
+ reg = <0 0x164a0000 0 0x10000>;
+ clocks = <&cpg CPG_MOD 0x1a8>,
+ <&cpg CPG_MOD 0x1a9>,
+ <&cpg CPG_MOD 0x1aa>;
+ clock-names = "aclk", "pclk", "vclk";
+ resets = <&cpg 0x11e>;
+ power-domains = <&cpg>;
+ };
};
stmmac_axi_setup: stmmac-axi-config {
--
2.43.0
^ permalink raw reply related
* [PATCH v6 17/21] media: dt-bindings: media: renesas,fcp: Document RZ/G3E SoC
From: Tommaso Merciai @ 2026-04-08 10:37 UTC (permalink / raw)
To: tomm.merciai, geert, laurent.pinchart
Cc: linux-renesas-soc, biju.das.jz, Tommaso Merciai,
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, Krzysztof Kozlowski
In-Reply-To: <cover.1775636898.git.tommaso.merciai.xr@bp.renesas.com>
The FCPVD block on the RZ/G3E SoC is identical to the one found on the
RZ/G2L SoC.
No driver changes are required, as `renesas,fcpv` will be used as a
fallback compatible string on the RZ/G3E SoC.
Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
Acked-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
Signed-off-by: Tommaso Merciai <tommaso.merciai.xr@bp.renesas.com>
---
v5->v6:
- No changes.
v4->v5:
- No changes.
v3->v4:
- No changes.
v2->v3:
- No changes.
v1->v2:
- Collected tags.
Documentation/devicetree/bindings/media/renesas,fcp.yaml | 2 ++
1 file changed, 2 insertions(+)
diff --git a/Documentation/devicetree/bindings/media/renesas,fcp.yaml b/Documentation/devicetree/bindings/media/renesas,fcp.yaml
index b5eff6fec8a9..f7e486e90e43 100644
--- a/Documentation/devicetree/bindings/media/renesas,fcp.yaml
+++ b/Documentation/devicetree/bindings/media/renesas,fcp.yaml
@@ -30,6 +30,7 @@ properties:
- renesas,r9a07g043u-fcpvd # RZ/G2UL
- renesas,r9a07g044-fcpvd # RZ/G2{L,LC}
- renesas,r9a07g054-fcpvd # RZ/V2L
+ - renesas,r9a09g047-fcpvd # RZ/G3E
- renesas,r9a09g056-fcpvd # RZ/V2N
- renesas,r9a09g057-fcpvd # RZ/V2H(P)
- const: renesas,fcpv # Generic FCP for VSP fallback
@@ -77,6 +78,7 @@ allOf:
- renesas,r9a07g043u-fcpvd
- renesas,r9a07g044-fcpvd
- renesas,r9a07g054-fcpvd
+ - renesas,r9a09g047-fcpvd
- renesas,r9a09g056-fcpvd
- renesas,r9a09g057-fcpvd
then:
--
2.43.0
^ permalink raw reply related
* [PATCH v6 16/21] media: dt-bindings: media: renesas,vsp1: Document RZ/G3E
From: Tommaso Merciai @ 2026-04-08 10:37 UTC (permalink / raw)
To: tomm.merciai, geert, laurent.pinchart
Cc: linux-renesas-soc, biju.das.jz, Tommaso Merciai,
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, Krzysztof Kozlowski
In-Reply-To: <cover.1775636898.git.tommaso.merciai.xr@bp.renesas.com>
The VSPD block on the RZ/G3E SoC is identical to the one found on the
RZ/G2L SoC.
No driver changes are required, as `renesas,r9a07g044-vsp2` will be used
as a fallback compatible string on the RZ/G3E SoC.
Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
Acked-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
Signed-off-by: Tommaso Merciai <tommaso.merciai.xr@bp.renesas.com>
---
v5->v6:
- No changes.
v4->v5:
- No changes.
v3->v4:
- No changes.
v2->v3:
- No changes.
v1->v2:
- Collected tags.
Documentation/devicetree/bindings/media/renesas,vsp1.yaml | 1 +
1 file changed, 1 insertion(+)
diff --git a/Documentation/devicetree/bindings/media/renesas,vsp1.yaml b/Documentation/devicetree/bindings/media/renesas,vsp1.yaml
index 07a97dd87a5b..62bff3ce3eaa 100644
--- a/Documentation/devicetree/bindings/media/renesas,vsp1.yaml
+++ b/Documentation/devicetree/bindings/media/renesas,vsp1.yaml
@@ -25,6 +25,7 @@ properties:
- enum:
- renesas,r9a07g043u-vsp2 # RZ/G2UL
- renesas,r9a07g054-vsp2 # RZ/V2L
+ - renesas,r9a09g047-vsp2 # RZ/G3E
- renesas,r9a09g056-vsp2 # RZ/V2N
- renesas,r9a09g057-vsp2 # RZ/V2H(P)
- const: renesas,r9a07g044-vsp2 # RZ/G2L fallback
--
2.43.0
^ permalink raw reply related
* [PATCH v6 15/21] drm: renesas: rz-du: Add RZ/G3E support
From: Tommaso Merciai @ 2026-04-08 10:37 UTC (permalink / raw)
To: tomm.merciai, geert, laurent.pinchart
Cc: linux-renesas-soc, biju.das.jz, Tommaso Merciai,
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: <cover.1775636898.git.tommaso.merciai.xr@bp.renesas.com>
The RZ/G3E Soc has 2 LCD controller (LCDC), contain a Frame Compression
Processor (FCPVD), a Video Signal Processor (VSPD), Video Signal
Processor (VSPD), and Display Unit (DU).
LCDC0 supports DSI and LVDS (single or dual-channel) outputs.
LCDC1 supports DSI, LVDS (single-channel), and RGB outputs.
Depending on the selected output, the correct SMUX2 clock parent must be
chosen based on the requested duty cycle:
- Index 0 for LVDS -> CDIV7_DSIx_CLK (DUTY H/L=4/3, 4/7 duty cycle)
- Index 1 for DSI/DPAD -> CSDIV_2to16_PLLDSIx (symmetric 50% duty cycle)
To support this behavior, introduce the `RZG2L_DU_FEATURE_SMUX2_DSI_CLK`
feature flag and extend the `rzg2l_du_device_info` structure to include a
features field. Also, add a new helper function `rzg2l_du_has()` to check
for feature flags.
Add support for the RZ/G3E SoC by introducing:
- `rzg2l_du_r9a09g047_du_info` structure
- The `renesas,r9a09g047-du` compatible string
Additionally, introduce the missing output definitions
`RZG2L_DU_OUTPUT_LVDS{0,1}`.
Introduce `rzg2l_du_crtc_atomic_check()` helper to store the routes from
the CRTC output to the DU outputs.
Signed-off-by: Tommaso Merciai <tommaso.merciai.xr@bp.renesas.com>
---
v5->v6:
- Aligned ports numbering with the bindings changes.
v4->v5:
- Fixed RG2L_DU_FEATURE_SMUX2_DSI_CLK to RZG2L_DU_FEATURE_SMUX2_DSI_CLK,
update commit body accordingly.
- Added features field documentation.
v3->v4:
- No changes.
v2->v3:
- No changes.
v1->v2:
- Instead of using clk-provider API to select the right parent clock,
based on the outputs. Just set the correct duty cycle based on the
output, this reflects at CPG lvl to select the right parent.
- Updated commit message accordingly.
drivers/gpu/drm/renesas/rz-du/rzg2l_du_crtc.c | 48 +++++++++++++++++++
drivers/gpu/drm/renesas/rz-du/rzg2l_du_drv.c | 28 ++++++++++-
drivers/gpu/drm/renesas/rz-du/rzg2l_du_drv.h | 12 +++++
3 files changed, 87 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/renesas/rz-du/rzg2l_du_crtc.c b/drivers/gpu/drm/renesas/rz-du/rzg2l_du_crtc.c
index 18e2b981b691..834bc6f77ec1 100644
--- a/drivers/gpu/drm/renesas/rz-du/rzg2l_du_crtc.c
+++ b/drivers/gpu/drm/renesas/rz-du/rzg2l_du_crtc.c
@@ -64,11 +64,32 @@
static void rzg2l_du_crtc_set_display_timing(struct rzg2l_du_crtc *rcrtc)
{
const struct drm_display_mode *mode = &rcrtc->crtc.state->adjusted_mode;
+ struct rzg2l_du_crtc_state *rstate =
+ to_rzg2l_crtc_state(rcrtc->crtc.state);
unsigned long mode_clock = mode->clock * 1000;
u32 ditr0, ditr1, ditr2, ditr3, ditr4, pbcr0;
struct rzg2l_du_device *rcdu = rcrtc->dev;
clk_prepare_enable(rcrtc->rzg2l_clocks.dclk);
+
+ if (rzg2l_du_has(rcdu, RZG2L_DU_FEATURE_SMUX2_DSI_CLK)) {
+ struct clk *clk_parent;
+
+ clk_parent = clk_get_parent(rcrtc->rzg2l_clocks.dclk);
+
+ /*
+ * Request appropriate duty cycle to let clock driver select
+ * the correct parent:
+ * - CDIV7_DSIx_CLK (LVDS path) has DUTY H/L=4/3, 4/7 duty cycle.
+ * - CSDIV_2to16_PLLDSIx (DSI/RGB path) has symmetric 50% duty cycle.
+ */
+ if (rstate->outputs == BIT(RZG2L_DU_OUTPUT_LVDS0) ||
+ rstate->outputs == BIT(RZG2L_DU_OUTPUT_LVDS1))
+ clk_set_duty_cycle(clk_parent, 4, 7);
+ else
+ clk_set_duty_cycle(clk_parent, 1, 2);
+ }
+
clk_set_rate(rcrtc->rzg2l_clocks.dclk, mode_clock);
ditr0 = (DU_DITR0_DEMD_HIGH
@@ -248,6 +269,32 @@ static void rzg2l_du_crtc_stop(struct rzg2l_du_crtc *rcrtc)
* CRTC Functions
*/
+static int rzg2l_du_crtc_atomic_check(struct drm_crtc *crtc,
+ struct drm_atomic_state *state)
+{
+ struct drm_crtc_state *crtc_state = drm_atomic_get_new_crtc_state(state,
+ crtc);
+ struct rzg2l_du_crtc_state *rstate = to_rzg2l_crtc_state(crtc_state);
+ struct drm_encoder *encoder;
+
+ /* Store the routes from the CRTC output to the DU outputs. */
+ rstate->outputs = 0;
+
+ drm_for_each_encoder_mask(encoder, crtc->dev,
+ crtc_state->encoder_mask) {
+ struct rzg2l_du_encoder *renc;
+
+ /* Skip the writeback encoder. */
+ if (encoder->encoder_type == DRM_MODE_ENCODER_VIRTUAL)
+ continue;
+
+ renc = to_rzg2l_encoder(encoder);
+ rstate->outputs |= BIT(renc->output);
+ }
+
+ return 0;
+}
+
static void rzg2l_du_crtc_atomic_enable(struct drm_crtc *crtc,
struct drm_atomic_state *state)
{
@@ -296,6 +343,7 @@ static void rzg2l_du_crtc_atomic_flush(struct drm_crtc *crtc,
}
static const struct drm_crtc_helper_funcs crtc_helper_funcs = {
+ .atomic_check = rzg2l_du_crtc_atomic_check,
.atomic_flush = rzg2l_du_crtc_atomic_flush,
.atomic_enable = rzg2l_du_crtc_atomic_enable,
.atomic_disable = rzg2l_du_crtc_atomic_disable,
diff --git a/drivers/gpu/drm/renesas/rz-du/rzg2l_du_drv.c b/drivers/gpu/drm/renesas/rz-du/rzg2l_du_drv.c
index 0fef33a5a089..b6143c1df583 100644
--- a/drivers/gpu/drm/renesas/rz-du/rzg2l_du_drv.c
+++ b/drivers/gpu/drm/renesas/rz-du/rzg2l_du_drv.c
@@ -51,6 +51,29 @@ static const struct rzg2l_du_device_info rzg2l_du_r9a07g044_info = {
}
};
+static const struct rzg2l_du_device_info rzg2l_du_r9a09g047_du_info = {
+ .features = RZG2L_DU_FEATURE_SMUX2_DSI_CLK,
+ .channels_mask = BIT(0),
+ .routes = {
+ [RZG2L_DU_OUTPUT_DSI0] = {
+ .possible_outputs = BIT(0),
+ .port = 0,
+ },
+ [RZG2L_DU_OUTPUT_DPAD0] = {
+ .possible_outputs = BIT(0),
+ .port = 1,
+ },
+ [RZG2L_DU_OUTPUT_LVDS0] = {
+ .possible_outputs = BIT(0),
+ .port = 2,
+ },
+ [RZG2L_DU_OUTPUT_LVDS1] = {
+ .possible_outputs = BIT(0),
+ .port = 3,
+ },
+ },
+};
+
static const struct rzg2l_du_device_info rzg2l_du_r9a09g057_info = {
.channels_mask = BIT(0),
.routes = {
@@ -64,6 +87,7 @@ static const struct rzg2l_du_device_info rzg2l_du_r9a09g057_info = {
static const struct of_device_id rzg2l_du_of_table[] = {
{ .compatible = "renesas,r9a07g043u-du", .data = &rzg2l_du_r9a07g043u_info },
{ .compatible = "renesas,r9a07g044-du", .data = &rzg2l_du_r9a07g044_info },
+ { .compatible = "renesas,r9a09g047-du", .data = &rzg2l_du_r9a09g047_du_info },
{ .compatible = "renesas,r9a09g057-du", .data = &rzg2l_du_r9a09g057_info },
{ /* sentinel */ }
};
@@ -74,7 +98,9 @@ const char *rzg2l_du_output_name(enum rzg2l_du_output output)
{
static const char * const names[] = {
[RZG2L_DU_OUTPUT_DSI0] = "DSI0",
- [RZG2L_DU_OUTPUT_DPAD0] = "DPAD0"
+ [RZG2L_DU_OUTPUT_DPAD0] = "DPAD0",
+ [RZG2L_DU_OUTPUT_LVDS0] = "LVDS0",
+ [RZG2L_DU_OUTPUT_LVDS1] = "LVDS1"
};
if (output >= ARRAY_SIZE(names))
diff --git a/drivers/gpu/drm/renesas/rz-du/rzg2l_du_drv.h b/drivers/gpu/drm/renesas/rz-du/rzg2l_du_drv.h
index 58806c2a8f2b..4a4ea556ed3b 100644
--- a/drivers/gpu/drm/renesas/rz-du/rzg2l_du_drv.h
+++ b/drivers/gpu/drm/renesas/rz-du/rzg2l_du_drv.h
@@ -20,9 +20,13 @@
struct device;
struct drm_property;
+#define RZG2L_DU_FEATURE_SMUX2_DSI_CLK BIT(0) /* Per output mux */
+
enum rzg2l_du_output {
RZG2L_DU_OUTPUT_DSI0,
RZG2L_DU_OUTPUT_DPAD0,
+ RZG2L_DU_OUTPUT_LVDS0,
+ RZG2L_DU_OUTPUT_LVDS1,
RZG2L_DU_OUTPUT_MAX,
};
@@ -42,10 +46,12 @@ struct rzg2l_du_output_routing {
/*
* struct rzg2l_du_device_info - DU model-specific information
+ * @features: device features (RZG2L_DU_FEATURE_*)
* @channels_mask: bit mask of available DU channels
* @routes: array of CRTC to output routes, indexed by output (RZG2L_DU_OUTPUT_*)
*/
struct rzg2l_du_device_info {
+ unsigned int features;
unsigned int channels_mask;
struct rzg2l_du_output_routing routes[RZG2L_DU_OUTPUT_MAX];
};
@@ -73,6 +79,12 @@ static inline struct rzg2l_du_device *to_rzg2l_du_device(struct drm_device *dev)
return container_of(dev, struct rzg2l_du_device, ddev);
}
+static inline bool rzg2l_du_has(struct rzg2l_du_device *rcdu,
+ unsigned int feature)
+{
+ return rcdu->info->features & feature;
+}
+
const char *rzg2l_du_output_name(enum rzg2l_du_output output);
#endif /* __RZG2L_DU_DRV_H__ */
--
2.43.0
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox