* [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
* [PATCH v6 14/21] drm: renesas: rz-du: mipi_dsi: Add support for RZ/G3E
From: Tommaso Merciai @ 2026-04-08 10:36 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 MIPI DSI support for the Renesas RZ/G3E SoC.
RZ/V2H(P) and RZ/G3E share identical PLLDSI divider constraints from the
DSI PHY perspective, so both can reuse the existing
rzv2h_plldsi_div_limits structure. However, at the CPG level the limits
differ:
- PLLDSI0 limits apply when vclk1 is used.
- PLLDSI1 limits apply when vclk2 is used.
To support this introduce rzg3e_plldsis_limits for RZ/G3E SoC.
During rzv2h_dphy_mode_clk_check(), the appropriate limits are selected
dynamically based on vclk_idx, which reflects the currently selected
vclk.
Reviewed-by: Biju Das <biju.das.jz@bp.renesas.com>
Signed-off-by: Tommaso Merciai <tommaso.merciai.xr@bp.renesas.com>
---
v5->v6:
- Collected BDas tag.
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 | 33 ++++++++++++++++++-
1 file changed, 32 insertions(+), 1 deletion(-)
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 947c8e15fc4b..9950ce0c76f8 100644
--- a/drivers/gpu/drm/renesas/rz-du/rzg2l_mipi_dsi.c
+++ b/drivers/gpu/drm/renesas/rz-du/rzg2l_mipi_dsi.c
@@ -581,7 +581,7 @@ static unsigned int rzv2h_dphy_mode_clk_check(struct rzg2l_mipi_dsi *dsi,
mode_freq_hz = mul_u32_u32(mode_freq, KILO);
mode_freq_millihz = mode_freq_hz * MILLI;
parameters_found =
- rzv2h_get_pll_divs_pars(dsi->info->cpg_plldsi.limits[0],
+ rzv2h_get_pll_divs_pars(dsi->info->cpg_plldsi.limits[dsi->vclk_idx],
&cpg_dsi_parameters,
dsi->info->cpg_plldsi.table,
dsi->info->cpg_plldsi.table_size,
@@ -1564,6 +1564,36 @@ static void rzg2l_mipi_dsi_remove(struct platform_device *pdev)
pm_runtime_disable(&pdev->dev);
}
+RZG3E_CPG_PLL_DSI0_LIMITS(rzg3e_cpg_pll_dsi0_limits);
+RZG3E_CPG_PLL_DSI1_LIMITS(rzg3e_cpg_pll_dsi1_limits);
+
+static const struct rzv2h_pll_limits *rzg3e_plldsis_limits[] = {
+ &rzg3e_cpg_pll_dsi0_limits,
+ &rzg3e_cpg_pll_dsi1_limits,
+};
+
+static const u8 rzg3e_cpg_div_table[] = {
+ 2, 4, 6, 8, 10, 12, 14, 16,
+};
+
+static struct rzg2l_mipi_dsi_hw_info rzg3e_mipi_dsi_info = {
+ .dphy_init = rzv2h_mipi_dsi_dphy_init,
+ .dphy_startup_late_init = rzv2h_mipi_dsi_dphy_startup_late_init,
+ .dphy_exit = rzv2h_mipi_dsi_dphy_exit,
+ .dphy_mode_clk_check = rzv2h_dphy_mode_clk_check,
+ .dphy_conf_clks = rzv2h_dphy_conf_clks,
+ .cpg_plldsi.limits = rzg3e_plldsis_limits,
+ .cpg_plldsi.table = rzg3e_cpg_div_table,
+ .cpg_plldsi.table_size = ARRAY_SIZE(rzg3e_cpg_div_table),
+ .phy_reg_offset = 0x10000,
+ .link_reg_offset = 0,
+ .min_dclk = 5440,
+ .max_dclk = 187500,
+ .out_port = 2,
+ .features = RZ_MIPI_DSI_FEATURE_16BPP |
+ RZ_MIPI_DSI_FEATURE_GPO0R,
+};
+
RZV2H_CPG_PLL_DSI_LIMITS(rzv2h_cpg_pll_dsi_limits);
static const struct rzv2h_pll_limits *rzv2h_plldsi_limits[] = {
@@ -1602,6 +1632,7 @@ static const struct rzg2l_mipi_dsi_hw_info rzg2l_mipi_dsi_info = {
};
static const struct of_device_id rzg2l_mipi_dsi_of_table[] = {
+ { .compatible = "renesas,r9a09g047-mipi-dsi", .data = &rzg3e_mipi_dsi_info, },
{ .compatible = "renesas,r9a09g057-mipi-dsi", .data = &rzv2h_mipi_dsi_info, },
{ .compatible = "renesas,rzg2l-mipi-dsi", .data = &rzg2l_mipi_dsi_info, },
{ /* sentinel */ }
--
2.43.0
^ permalink raw reply related
* [PATCH v6 13/21] drm: renesas: rz-du: mipi_dsi: Add RZ_MIPI_DSI_FEATURE_GPO0R feature
From: Tommaso Merciai @ 2026-04-08 10:36 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 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 */
+ 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)
--
2.43.0
^ permalink raw reply related
* [PATCH v6 12/21] drm: renesas: rz-du: mipi_dsi: Add out_port to OF data
From: Tommaso Merciai @ 2026-04-08 10:36 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 `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>
---
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[] = {
--
2.43.0
^ permalink raw reply related
* Re: [RFC uL PATCH 2/2] mux-controller: ti: add driver for event mux router
From: rahul sharma @ 2026-04-08 10:39 UTC (permalink / raw)
To: Greg KH; +Cc: peda, robh, krzk+dt, conor+dt, devicetree, vigneshr, linux-kernel
In-Reply-To: <2026033026-shuffling-kisser-ac6c@gregkh>
On 30/03/26 12:33, Greg KH wrote:
> On Mon, Mar 30, 2026 at 11:02:11AM +0530, rahul sharma wrote:
>> CC: Greg Kroah-Hartman
>>
>> Hi Greg,
>>
>> Could you please review this patch(2nd one in the series). It seems Peter is
>> not online for almost a month.
>
> But I am not the mux maintainer, so I am probably not the best one to
> review it :(
Hi Greg,
I agree, but is there any other way to get Peter's attention on this. Or
is there any other maintainer who can review on his behalf. Could you
please guide me on this ?
Also, there was another patch series that was posted last year. It was
trying to do the same but changes were on the generic driver side i.e.
drivers/mux/mmio.c
Link: https://lore.kernel.org/all/20250605063422.3813260-1-c-vankar@ti.com/
On that patch series too there wasn't any comment from Peter. I would
like to know how to go forward on this.
>
> One instant comment though:
>
>> On 13/03/26 11:34, Rahul Sharma wrote:
>>> The driver supports event muxing routers like gpio mux router and timesync
>>> router. This driver is adaptation of original reg-mux driver, along with
>>> changes specific to support TI's mux router.
>>>
>>> The idle states this driver supports are only 2 which active(represented
>>> by 1 in dt-node) and in-active(represented by 0 in dt-node).
>>>
>>> Signed-off-by: Rahul Sharma <r-sharma3@ti.com>
>>> ---
>>> drivers/mux/Kconfig | 15 +++
>>> drivers/mux/Makefile | 2 +
>>> drivers/mux/ti-k3-event-mux.c | 235 ++++++++++++++++++++++++++++++++++
>>> 3 files changed, 252 insertions(+)
>>> create mode 100644 drivers/mux/ti-k3-event-mux.c
>>>
>>> diff --git a/drivers/mux/Kconfig b/drivers/mux/Kconfig
>>> index c68132e38138..ad3af2724d28 100644
>>> --- a/drivers/mux/Kconfig
>>> +++ b/drivers/mux/Kconfig
>>> @@ -59,4 +59,19 @@ config MUX_MMIO
>>> To compile the driver as a module, choose M here: the module will
>>> be called mux-mmio.
>>> +config MUX_TI_K3_EVENT_ROUTER
>>> + tristate "TI Event Mux Router using MMIO registers"
>>> + depends on OF && (REGMAP_MMIO || COMPILE_TEST)
>>> + help
>>> + This is extension of MMIO mux for timesync router and gpiomux
>>> + routers on TI K3 SoCs. This driver supports the 3-field format for
>>> + mux control: <register-offset mask value>.
>>> +
>>> + The driver allows configuration of hardware mux routers using
>>> + memory-mapped registers. It's based on the mmio-mux driver but
>>> + supports the extended 3-field format for more precise control.
>>> +
>>> + To compile the driver as a module, choose M here: the module will
>>> + be called mux-ti-k3-event.
>>> +
>
> Don't you need a blank line before your new config option?
Sure, I will correct this.
BR,
Rahul
>
> thanks,
>
> greg k-h
^ permalink raw reply
* [PATCH v6 11/21] dt-bindings: display: bridge: renesas,dsi: Add support for RZ/G3E SoC
From: Tommaso Merciai @ 2026-04-08 10:36 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 MIPI DSI interface on the RZ/G3E SoC is nearly identical to that of
the RZ/V2H(P) SoC, except that this have 2 input port and can use vclk1
or vclk2 as DSI Video clock, depending on the selected port.
To accommodate these differences, a SoC-specific
`renesas,r9a09g047-mipi-dsi` compatible string has been added for the
RZ/G3E SoC.
Reviewed-by: Biju Das <biju.das.jz@bp.renesas.com>
Reviewed-by: Rob Herring (Arm) <robh@kernel.org>
Signed-off-by: Tommaso Merciai <tommaso.merciai.xr@bp.renesas.com>
---
v5->v6:
- No changes.
v4->v5:
- Collected tag.
v3->v4:
- No changes.
v2->v3:
- No changes.
v1->v2:
- Removed oneOf from clocks property, which is no sufficient to
differentiate between RZ/G3E, RZ/V2H(P) and RZ/G2L.
In particular both RZ/G3E and RZ/G2L have 6 clocks with different
meanings.
- Use the already exist vclk instead of vclk1 for RZ/G3E DSI bindings.
- Updated the allOf section accordingly.
.../bindings/display/bridge/renesas,dsi.yaml | 144 +++++++++++++-----
1 file changed, 109 insertions(+), 35 deletions(-)
diff --git a/Documentation/devicetree/bindings/display/bridge/renesas,dsi.yaml b/Documentation/devicetree/bindings/display/bridge/renesas,dsi.yaml
index c20625b8425e..00ef279129fd 100644
--- a/Documentation/devicetree/bindings/display/bridge/renesas,dsi.yaml
+++ b/Documentation/devicetree/bindings/display/bridge/renesas,dsi.yaml
@@ -28,6 +28,7 @@ properties:
- const: renesas,r9a09g057-mipi-dsi
- enum:
+ - renesas,r9a09g047-mipi-dsi # RZ/G3E
- renesas,r9a09g057-mipi-dsi # RZ/V2H(P)
reg:
@@ -54,20 +55,8 @@ properties:
- const: debug
clocks:
- oneOf:
- - items:
- - description: DSI D-PHY PLL multiplied clock
- - description: DSI D-PHY system clock
- - description: DSI AXI bus clock
- - description: DSI Register access clock
- - description: DSI Video clock
- - description: DSI D-PHY Escape mode transmit clock
- - items:
- - description: DSI D-PHY PLL reference clock
- - description: DSI AXI bus clock
- - description: DSI Register access clock
- - description: DSI Video clock
- - description: DSI D-PHY Escape mode transmit clock
+ minItems: 5
+ maxItems: 6
clock-names:
oneOf:
@@ -78,12 +67,14 @@ properties:
- const: pclk
- const: vclk
- const: lpclk
- - items:
+ - minItems: 5
+ items:
- const: pllrefclk
- const: aclk
- const: pclk
- const: vclk
- const: lpclk
+ - const: vclk2
resets:
oneOf:
@@ -136,13 +127,6 @@ properties:
- const: 3
- const: 4
- required:
- - data-lanes
-
- required:
- - port@0
- - port@1
-
required:
- compatible
- reg
@@ -164,33 +148,123 @@ allOf:
properties:
compatible:
contains:
- const: renesas,r9a09g057-mipi-dsi
+ const: renesas,r9a09g047-mipi-dsi
then:
properties:
- clocks:
- maxItems: 5
+ ports:
+ properties:
+ port@0:
+ description: DSI input port 0
+ port@1:
+ description: DSI input port 1
+ properties:
+ endpoint:
+ properties:
+ data-lanes: false
+ port@2:
+ description: DSI output port
+ properties:
+ endpoint:
+ $ref: /schemas/media/video-interfaces.yaml#
+ unevaluatedProperties: false
+
+ properties:
+ data-lanes:
+ description: array of physical DSI data lane indexes.
+ minItems: 1
+ items:
+ - const: 1
+ - const: 2
+ - const: 3
+ - const: 4
+ required:
+ - data-lanes
+
+ required:
+ - port@0
+ - port@1
+ - port@2
+ else:
+ properties:
+ ports:
+ properties:
+ port@0: true
+ port@1:
+ properties:
+ endpoint:
+ properties:
+ data-lanes: true
+ required:
+ - data-lanes
+
+ required:
+ - port@0
+ - port@1
+ - if:
+ properties:
+ compatible:
+ contains:
+ const: renesas,rzg2l-mipi-dsi
+ then:
+ properties:
+ clocks:
+ items:
+ - description: DSI D-PHY PLL multiplied clock
+ - description: DSI D-PHY system clock
+ - description: DSI AXI bus clock
+ - description: DSI Register access clock
+ - description: DSI Video clock
+ - description: DSI D-PHY Escape mode transmit clock
clock-names:
- maxItems: 5
+ minItems: 6
+ resets:
+ minItems: 3
+ reset-names:
+ minItems: 3
+ - if:
+ properties:
+ compatible:
+ contains:
+ const: renesas,r9a09g047-mipi-dsi
+ then:
+ properties:
+ clocks:
+ items:
+ - description: DSI D-PHY PLL reference clock
+ - description: DSI AXI bus clock
+ - description: DSI Register access clock
+ - description: DSI Video clock
+ - description: DSI D-PHY Escape mode transmit clock
+ - description: DSI Video clock (2nd input clock)
+ clock-names:
+ minItems: 6
resets:
maxItems: 2
-
reset-names:
maxItems: 2
- else:
+
+ - if:
+ properties:
+ compatible:
+ contains:
+ const: renesas,r9a09g057-mipi-dsi
+ then:
properties:
clocks:
- minItems: 6
-
+ items:
+ - description: DSI D-PHY PLL reference clock
+ - description: DSI AXI bus clock
+ - description: DSI Register access clock
+ - description: DSI Video clock
+ - description: DSI D-PHY Escape mode transmit clock
clock-names:
- minItems: 6
-
+ maxItems: 5
resets:
- minItems: 3
-
+ maxItems: 2
reset-names:
- minItems: 3
+ maxItems: 2
examples:
- |
--
2.43.0
^ permalink raw reply related
* [PATCH v6 10/21] dt-bindings: display: renesas,rzg2l-du: Add support for RZ/G3E SoC
From: Tommaso Merciai @ 2026-04-08 10:36 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 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
examples:
# RZ/G2L DU
--
2.43.0
^ permalink raw reply related
* [PATCH v6 09/21] dt-bindings: display: renesas,rzg2l-du: Refuse port@1 for RZ/G2UL
From: Tommaso Merciai @ 2026-04-08 10:36 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, stable
In-Reply-To: <cover.1775636898.git.tommaso.merciai.xr@bp.renesas.com>
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>
---
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
--
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