* Re: [PATCH 1/2] dt-bindings: pci: sophgo: Add dma-coherent property for SG2042
From: Rob Herring (Arm) @ 2026-04-08 14:41 UTC (permalink / raw)
To: Han Gao
Cc: Inochi Amaoto, Conor Dooley, Bjorn Helgaas, devicetree, Albert Ou,
linux-riscv, Lorenzo Pieralisi, Alexandre Ghiti,
Manivannan Sadhasivam, Palmer Dabbelt, Krzysztof Wilczyński,
Chen Wang, Zixian Zeng, Krzysztof Kozlowski, Han Gao,
linux-kernel, sophgo, linux-pci, Paul Walmsley
In-Reply-To: <20260331171248.973014-2-gaohan@iscas.ac.cn>
On Wed, 01 Apr 2026 01:12:47 +0800, Han Gao wrote:
> Add dma-coherent as an allowed property in the SG2042 PCIe host
> controller binding. SG2042's PCIe root complexes are cache-coherent
> with the CPU.
>
> Signed-off-by: Han Gao <gaohan@iscas.ac.cn>
> ---
> .../devicetree/bindings/pci/sophgo,sg2042-pcie-host.yaml | 3 +++
> 1 file changed, 3 insertions(+)
>
Acked-by: Rob Herring (Arm) <robh@kernel.org>
^ permalink raw reply
* Re: [PATCH 06/13] clk: amlogic: Add noglitch clock driver
From: Chuan Liu @ 2026-04-08 14:44 UTC (permalink / raw)
To: Martin Blumenstingl
Cc: Neil Armstrong, Michael Turquette, Stephen Boyd, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, linux-amlogic, linux-clk,
devicetree, linux-kernel
In-Reply-To: <CAFBinCBXFxefUkNj3sqUdnTz7vf72jV_FkCP6gd2veTtLHWnBg@mail.gmail.com>
Hi Martin,
Thanks for review.
On 2/10/2026 5:51 AM, Martin Blumenstingl wrote:
> [ EXTERNAL EMAIL ]
>
> Hi Chuan Liu,
>
> On Mon, Feb 9, 2026 at 6:49 AM Chuan Liu via B4 Relay
> <devnull+chuan.liu.amlogic.com@kernel.org> wrote:
> [...]
>> + * To prevent glitches from propagating to clk_out and affecting the normal
>> + * operation of glitch-sensitive modules, the no-glitch clock must be configured
>> + * following the specified sequence:
>> + * - When the clock gate is disabled: configure it as a normal composite clock
>> + * (any glitches generated will be blocked by the gate and will not
>> + * propagate to clk_out).
> This part is easy and makes sense.
>
>> + * - When the clock gate is enabled: configure it according to the following
>> + * sequence to suppress glitches:
>> + * - Configure and enable the idle composite clock path of the
>> + * noglitch_mux with the target frequency/parent clock.
>> + * - Switch the noglitch_mux to the channel prepared in the previous step.
>> + * - Disable the clock of the original noglitch_mux channel.
>> + */
> From a previous discussion it seems that in reality things need to be
> handled more carefully as you previously mentioned that
> CLK_SET_RATE_GATE is not good enough (the description above is what
> CLK_SET_RATE_GATE already achieves).
> For the more careful handling Jerome suggested using the clock
> protection logic: [0]
> You wanted to try it out at some point: [1]
> Is the verdict that Jerome's suggestion did not work? Can you please
> share some details as to why it doesn't work.
>
In the actual use case, this switching operation completes within the
nanosecond range (with a minimum clock frequency of 24 MHz in typical
scenarios), which is why no issues were observed on our previous SoCs.
Thank you for the reminder, to be on the safe side, I will introduce
some explicit hardware delays in the future revision.
>
> Best regards,
> Martin
>
>
> [0] https://lore.kernel.org/linux-amlogic/1j1pnp5sg7.fsf@starbuckisacylon.baylibre.com/
> [1] https://lore.kernel.org/linux-amlogic/1639bb9d-9cb7-409f-bbf8-bfe4a5d1b8bc@amlogic.com/
--
Best regards,
Chuan
^ permalink raw reply
* Re: [PATCH v6 10/21] dt-bindings: display: renesas,rzg2l-du: Add support for RZ/G3E SoC
From: Tommaso Merciai @ 2026-04-08 14:44 UTC (permalink / raw)
To: Laurent Pinchart
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: <20260408141638.GA1965119@killaraus.ideasonboard.com>
Hi Laurent,
Thanks for your comment.
On 4/8/26 16:16, Laurent Pinchart wrote:
> On Wed, Apr 08, 2026 at 04:02:14PM +0200, Tommaso Merciai wrote:
>> Hi Laurent,
>> Thanks for your review.
>>
>> On 4/8/26 14:24, Laurent Pinchart wrote:
>>> On Wed, Apr 08, 2026 at 12:36:55PM +0200, Tommaso Merciai wrote:
>>>> The RZ/G3E SoC has 2 LCD controllers (LCDC), each containing a Frame
>>>> Compression Processor (FCPVD), a Video Signal Processor (VSPD), and a
>>>> Display Unit (DU).
>>>>
>>>> - LCDC0 supports DSI and LVDS (single or dual-channel) outputs.
>>>> - LCDC1 supports DSI, LVDS (single-channel), and RGB outputs.
>>>>
>>>> Add a new SoC-specific compatible string 'renesas,r9a09g047-du'.
>>>>
>>>> Extend patternProperties from "^port@[0-1]$" to "^port@[0-3]$" to
>>>> allow up to four output ports, and explicitly disable port@2 and port@3
>>>> for existing SoCs that do not expose them.
>>>>
>>>> Describe the four output ports of the RZ/G3E DU:
>>>>
>>>> - port@0: DSI (available on both LCDC instances)
>>>> - port@1: DPAD / parallel RGB (LCDC1 only)
>>>> - port@2: LVDS channel 0 (LCDC0 only)
>>>> - port@3: LVDS channel 1 (available on both LCDC instances)
>>>>
>>>> Signed-off-by: Tommaso Merciai <tommaso.merciai.xr@bp.renesas.com>
>>>> ---
>>>> v5->v6:
>>>> - Extend patternProperties from "^port@[0-1]$" to "^port@[0-3]$" and
>>>> explicitly disable port@2 and port@3 for existing SoCs that do not expose
>>>> them.
>>>> - Reworked ports numbering + improved/fixed ports descriptions in the
>>>> bindings documentation.
>>>> - Improved commit body.
>>>>
>>>> v4->v5:
>>>> - Dropped renesas,id property and updated bindings
>>>> accordingly.
>>>>
>>>> v2->v3:
>>>> - No changes.
>>>>
>>>> v2->v3:
>>>> - No changes.
>>>>
>>>> v1->v2:
>>>> - Use single compatible string instead of multiple compatible strings
>>>> for the two DU instances, leveraging a 'renesas,id' property to
>>>> differentiate between DU0 and DU1.
>>>> - Updated commit message accordingly.
>>>>
>>>> .../bindings/display/renesas,rzg2l-du.yaml | 30 ++++++++++++++++++-
>>>> 1 file changed, 29 insertions(+), 1 deletion(-)
>>>>
>>>> diff --git a/Documentation/devicetree/bindings/display/renesas,rzg2l-du.yaml b/Documentation/devicetree/bindings/display/renesas,rzg2l-du.yaml
>>>> index 5add3b832eab..32da0b5ec88c 100644
>>>> --- a/Documentation/devicetree/bindings/display/renesas,rzg2l-du.yaml
>>>> +++ b/Documentation/devicetree/bindings/display/renesas,rzg2l-du.yaml
>>>> @@ -20,6 +20,7 @@ properties:
>>>> - enum:
>>>> - renesas,r9a07g043u-du # RZ/G2UL
>>>> - renesas,r9a07g044-du # RZ/G2{L,LC}
>>>> + - renesas,r9a09g047-du # RZ/G3E
>>>> - renesas,r9a09g057-du # RZ/V2H(P)
>>>> - items:
>>>> - enum:
>>>> @@ -61,7 +62,7 @@ properties:
>>>> model-dependent. Each port shall have a single endpoint.
>>>>
>>>> patternProperties:
>>>> - "^port@[0-1]$":
>>>> + "^port@[0-3]$":
>>>> $ref: /schemas/graph.yaml#/properties/port
>>>> unevaluatedProperties: false
>>>>
>>>> @@ -103,6 +104,8 @@ allOf:
>>>> port@0:
>>>> description: DPI
>>>> port@1: false
>>>> + port@2: false
>>>> + port@3: false
>>>>
>>>> required:
>>>> - port@0
>>>> @@ -119,6 +122,8 @@ allOf:
>>>> description: DSI
>>>> port@1:
>>>> description: DPI
>>>> + port@2: false
>>>> + port@3: false
>>>>
>>>> required:
>>>> - port@0
>>>> @@ -135,9 +140,32 @@ allOf:
>>>> port@0:
>>>> description: DSI
>>>> port@1: false
>>>> + port@2: false
>>>> + port@3: false
>>>>
>>>> required:
>>>> - port@0
>>>> + - if:
>>>> + properties:
>>>> + compatible:
>>>> + contains:
>>>> + const: renesas,r9a09g047-du
>>>> + then:
>>>> + properties:
>>>> + ports:
>>>> + properties:
>>>> + port@0:
>>>> + description: DSI
>>>> + port@1:
>>>> + description: DPAD
>>>> + port@2:
>>>> + description: LVDS, Channel 0
>>>> + port@3:
>>>> + description: LVDS, Channel 1
>>>> +
>>>> + required:
>>>> + - port@0
>>>> + - port@3
>>>
>>> Why are ports 1 and 2 not required ?
>>
>> About this we had a similar discussion on v5[0]
>> We are using the same compatible and:
>>
>> - LCDC0 supports DSI and LVDS (single or dual-channel) outputs.
>> |
>> --> then has:
>> port@0
>> port@2
>> port@3
>>
>>
>> - LCDC1 supports DSI, LVDS (single-channel), and RGB outputs.
>> |
>> --> then has:
>> port@0
>> port@1
>> port@3
>
> Ah yes, I forget there are two LCDC instances with different output
> configurations.
>
> Something still looks a bit weird to me though. For LCDC1, which
> supports a single LVDS channel, you use the port described as the second
> LVDS channel. Is there a reason not to use port@2 ?
9.11 Low Voltage Differential Signaling (LVDS)
9.11.1.2 Block Diagram
Figure 9.11-1 shows a block diagram of LVDS.
LCDC1 is connected to LVDS, Channel 1
For this reason I'm using port@3.
Kind Regards,
Tommaso
>
>> Then port@1 is required for DU1 but not for DU0.
>> Same port@2 is required for DU0 but not for DU1.
>>
>> [0] https://patchwork.kernel.org/project/linux-renesas-soc/patch/ca022fdbba5236c36e0cb3095db4c31e8e0cb1b8.1770996493.git.tommaso.merciai.xr@bp.renesas.com/
>>
>>>>
>>>> examples:
>>>> # RZ/G2L DU
>
^ permalink raw reply
* Re: [PATCH v2 0/7] thermal: samsung: Add support for Google GS101 TMU
From: Alexey Klimov @ 2026-04-08 14:49 UTC (permalink / raw)
To: Tudor Ambarus
Cc: Rafael J. Wysocki, Daniel Lezcano, Zhang Rui, Lukasz Luba,
Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Krzysztof Kozlowski, Alim Akhtar, Bartlomiej Zolnierkiewicz,
Kees Cook, Gustavo A. R. Silva, Peter Griffin, André Draszik,
willmcvicker, jyescas, shin.son, linux-samsung-soc, linux-kernel,
linux-pm, devicetree, linux-arm-kernel, linux-hardening
In-Reply-To: <20260119-acpm-tmu-v2-0-e02a834f04c6@linaro.org>
On Mon Jan 19, 2026 at 12:08 PM GMT, Tudor Ambarus wrote:
> Add support for the Thermal Management Unit (TMU) on the Google GS101
> SoC.
>
> The GS101 TMU implementation utilizes a hybrid architecture where
> management is shared between the kernel and the Alive Clock and
> Power Manager (ACPM) firmware.
Do you plan to update or work on this series? If, by some reason,
this series is postphoned I can rebase it and re-send, for example.
IIRC it needs a clean rebase as a minimial change.
I am constructing some code on top of it, so it will be nice to have
newer version that can be (re-)tested for Exynos850.
Thanks,
Alexey
[...]
^ permalink raw reply
* Re: [PATCH v5 2/2] dt-bindings: pinctrl: pinctrl-max77620: convert to DT schema
From: Rob Herring @ 2026-04-08 14:52 UTC (permalink / raw)
To: Svyatoslav Ryhel
Cc: Linus Walleij, Krzysztof Kozlowski, Conor Dooley, Liam Girdwood,
Mark Brown, linux-gpio, devicetree, linux-kernel
In-Reply-To: <20260406075114.25672-3-clamor95@gmail.com>
On Mon, Apr 6, 2026 at 2:51 AM Svyatoslav Ryhel <clamor95@gmail.com> wrote:
>
> Convert pinctrl-max77620 devicetree bindings for the MAX77620 PMIC from
> TXT to YAML format. This patch does not change any functionality; the
> bindings remain the same.
>
> Signed-off-by: Svyatoslav Ryhel <clamor95@gmail.com>
> ---
> .../pinctrl/maxim,max77620-pinctrl.yaml | 98 ++++++++++++++
> .../bindings/pinctrl/pinctrl-max77620.txt | 127 ------------------
> 2 files changed, 98 insertions(+), 127 deletions(-)
> create mode 100644 Documentation/devicetree/bindings/pinctrl/maxim,max77620-pinctrl.yaml
> delete mode 100644 Documentation/devicetree/bindings/pinctrl/pinctrl-max77620.txt
Reviewed-by: Rob Herring (Arm) <robh@kernel.org>
This needs to go into 7.1 as the MFD part was already applied.
^ permalink raw reply
* Re: [PATCH net-next v2 4/9] net: dsa: lan9645x: add basic dsa driver for LAN9645X
From: Jens Emil Schulz Ostergaard @ 2026-04-08 14:57 UTC (permalink / raw)
To: Vladimir Oltean
Cc: Jakub Kicinski, UNGLinuxDriver, andrew, davem, edumazet, pabeni,
horms, robh, krzk+dt, conor+dt, woojung.huh, linux,
Steen.Hegelund, daniel.machon, linux-kernel, netdev, devicetree
In-Reply-To: <20260407091217.rrwzho3lcmfip3y5@skbuf>
On Tue, 2026-04-07 at 12:12 +0300, Vladimir Oltean wrote:
> EXTERNAL EMAIL: Do not click links or open attachments unless you know the content is safe
>
> On Wed, Apr 01, 2026 at 01:46:19PM +0200, Jens Emil Schulz Ostergaard wrote:
> > On Sun, 2026-03-29 at 12:56 -0700, Jakub Kicinski wrote:
> > > EXTERNAL EMAIL: Do not click links or open attachments unless you know the content is safe
> > >
> > > This is an AI-generated review of your patch. The human sending this
> > > email has considered the AI review valid, or at least plausible.
> > > ---
> > > Subject: net: dsa: lan9645x: add basic dsa driver for LAN9645X
> > >
> > > This commit adds a basic DSA driver for the Microchip LAN9645X switch. It
> > > includes initialization, port module setup for NPI, CPU, and front ports,
> > > and phylink integration for MAC side configuration.
> > >
> > > diff --git a/drivers/net/dsa/microchip/lan9645x/lan9645x_npi.c b/drivers/net/dsa/microchip/lan9645x/lan9645x_npi.c
> > > --- a/drivers/net/dsa/microchip/lan9645x/lan9645x_npi.c
> > > +++ b/drivers/net/dsa/microchip/lan9645x/lan9645x_npi.c
> > > [ ... ]
> > > > +static void disable_conduit_ipv6(struct lan9645x *lan9645x,
> > > > + struct net_device *conduit)
> > > > +{
> > > > + struct inet6_dev *dev_v6;
> > > > +
> > > > + if (!conduit)
> > > > + return;
> > > > +
> > > > + /* IPv6 on the conduit will generate frames bypassing our tag driver, so
> > > > + * they lack an IFH. This will be garbage in garbage out and we want to
> > > > + * avoid this.
> > > > + */
> > > > + rtnl_lock();
> > > > + dev_v6 = __in6_dev_get(conduit);
> > > > + if (dev_v6) {
> > > > + WRITE_ONCE(dev_v6->cnf.disable_ipv6, 1);
> > > > + dev_warn(lan9645x->dev, "Disabled IPv6 on conduit device: %s\n",
> > > > + netdev_name(conduit));
> > > > + }
> > > > + rtnl_lock();
> > > > +}
> > >
> > > Does directly modifying dev_v6->cnf.disable_ipv6 bypass the proper sysctl
> > > teardown path (addrconf_disable_ipv6) and leave the IPv6 stack in an
> > > inconsistent state on the conduit device by failing to clean up routes,
> > > addresses, and MLD memberships?
> > >
> > > Is it a layering violation for a switch driver to alter the networking
> > > configuration of an external upper device, especially since this change
> > > isn't reverted during driver unbind?
> >
> > Yes this will bypass the sysctl teardown path. I can change this to instead
> > read disable_ipv6 state and warn the user that their device is misconfigured.
>
> I don't want to have to deal with a DSA driver altering the conduit
> configuration outside of the DSA core. NACK to any attempts of trying
> this.
>
> Define "garbage in, garbage out" for your case. The packets are sent to
> random ports? Normally, switches are configured by their drivers to drop
> those packets that don't contain DSA tags. You can also do that, by
> setting up the switch to require an injection prefix.
>
> > > [ ... ]
> > > > + /* Configure IFH prefix mode for NPI port. */
> > > > + lan_rmw(SYS_PORT_MODE_INCL_XTR_HDR_SET(LAN9645X_TAG_PREFIX_LONG) |
> > > > + SYS_PORT_MODE_INCL_INJ_HDR_SET(LAN9645X_TAG_PREFIX_NONE),
> > > > + SYS_PORT_MODE_INCL_XTR_HDR |
> > > > + SYS_PORT_MODE_INCL_INJ_HDR,
> > > > + lan9645x,
> > > > + SYS_PORT_MODE(p->chip_port));
> > >
> > > Setting LAN9645X_TAG_PREFIX_NONE means the hardware interprets the first
> > > bytes of any frame received from the host as an IFH command structure.
> > >
> > > Does this allow a local user to transmit crafted frames (for example, via
> > > raw sockets or standard protocols) whose MAC address bytes map to malicious
> > > IFH commands, thereby bypassing VLAN isolation or flooding the switch?
> > >
> > > Should the hardware be configured to require a strict prefix, such as
> > > LAN9645X_TAG_PREFIX_LONG, for injected frames to prevent this?
> >
> > A prefix offers no protection against the described scenario. The current
> > configuration is correct. If a prefix is configured frames MUST contain the
> > prefix. With the conduit exposed in userspace this is not something we can
> > guarantee.
>
> The short prefix prevents user space from sending frames by mistake
> which will reach the wire (daemons attaching to all interfaces, like for DHCP).
> It still allows user space to intentionally inject frames into the
> switch (for example from XDP on the conduit).
>
> I recommend you go for the short prefix and drop the conduit alterations.
>
By garbage in, garbage out I mean frames will be interpreted as having
an IFH, and may be sent to random ports depending the bytes in the
frame.
Unfortunately, configuring an injection prefix is not a good solution.
If an injection prefix is configured frames MUST contain this prefix. If
frames are received which do not contain the prefix they will corrupt
the queue system leaving the port unusable.
Since the driver does not have control over frames sent to the NPI port,
an injection prefix configuration is highly undesirable.
I will remove the conduit alterations.
> > > diff --git a/drivers/net/dsa/microchip/lan9645x/lan9645x_main.c b/drivers/net/dsa/microchip/lan9645x/lan9645x_main.c
> > > --- a/drivers/net/dsa/microchip/lan9645x/lan9645x_main.c
> > > +++ b/drivers/net/dsa/microchip/lan9645x/lan9645x_main.c
> > > [ ... ]
> > > > +static int lan9645x_setup(struct dsa_switch *ds)
> > > > +{
> > > > + struct lan9645x *lan9645x = ds->priv;
> > > > + struct device *dev = lan9645x->dev;
> > > > + u32 all_phys_ports;
> > > > + int err;
> > > > +
> > > > + lan9645x->num_phys_ports = ds->num_ports;
> > > > + all_phys_ports = GENMASK(lan9645x->num_phys_ports - 1, 0);
> > > > +
> > > > + err = lan9645x_reset_switch(lan9645x);
> > > > + if (err)
> > > > + return err;
> > > > +
> > > > + lan9645x->ports = devm_kcalloc(lan9645x->dev, lan9645x->num_phys_ports,
> > > > + sizeof(struct lan9645x_port *),
> > > > + GFP_KERNEL);
> > >
> > > Since the DSA .setup callback can be invoked multiple times during the
> > > platform device's lifetime (for example, when the DSA master interface is
> > > unbound and bound again), does using devm_kcalloc here cause a memory leak?
> > > Should these allocations be moved to .probe or managed with kcalloc and
> > > freed in .teardown?
> > >
> >
> > Hmm I do not think this is right? I think dsa_tree_teardown is called from
> > dsa_switch_remove which is called by the switch drivers .remove.
> >
> > So I do not think you can get multiple setup/teardown cycles during the device
> > lifetime?
> >
> > As far as I can tell both felix and ksz use device managed allocations in their
> > setup callback.
>
> It's valid feedback in general. In a multi-switch tree, ds->ops->setup()
> is called when the tree is complete, and ds->ops->teardown() when the
> first switch disappears. If there are 2 switches and you unbind and
> rebind the driver from A, then switch B will see a ds->ops->teardown()
> call followed by ds->ops->setup().
>
> In your case, since the switch doesn't support cascading, it probably
> doesn't matter. But the LLM doesn't have the context to know that.
>
OK, I was not aware of this. I tried following the callstack and it did not seem
like the described scenario was possible. If device managed allocations are fine
when you do not support cascading, I would prefer to keep them.
> > > [ ... ]
> > > > + /* Set all the entries to obey VLAN. */
> > > > + for (int i = 0; i < PGID_ENTRIES; ++i)
> > > > + lan_wr(ANA_PGID_CFG_OBEY_VLAN_SET(1),
> > > > + lan9645x, ANA_PGID_CFG(i));
> > >
> > > PGID_ENTRIES is defined as 89, so this loop initializes indices 0 through
> > > 88. Since the CPU port is index 9, its source PGID is PGID_SRC + CPU_PORT
> > > (80 + 9 = 89).
> > >
> > > Is index 89 left uninitialized, breaking the OBEY_VLAN rule and allowing
> > > CPU-injected frames to leak across VLAN boundaries?
> > >
> >
> > No I this misunderstands OBEY_VLAN. When set the vlan table can control
> > whether cpu copy from the pgid table is enabled. It makes no sense for PGID 89.
>
> Explain that in a comment.
>
I will add a comment about this.
> > > [ ... ]
> > > > + /* Multicast to all front ports */
> > > > + lan_wr(all_phys_ports, lan9645x, ANA_PGID(PGID_MC));
> > > > +
> > > > + /* IP multicast to all front ports */
> > > > + lan_wr(all_phys_ports, lan9645x, ANA_PGID(PGID_MCIPV4));
> > > > + lan_wr(all_phys_ports, lan9645x, ANA_PGID(PGID_MCIPV6));
> > > > +
> > > > + /* Unicast to all front ports */
> > > > + lan_wr(all_phys_ports, lan9645x, ANA_PGID(PGID_UC));
> > > > +
> > > > + /* Broadcast to all ports */
> > > > + lan_wr(BIT(CPU_PORT) | all_phys_ports, lan9645x, ANA_PGID(PGID_BC));
> > >
> > > PGID_BC includes BIT(CPU_PORT) and all_phys_ports (which includes the NPI
> > > port). Will this forward broadcast frames to both the CPU extraction queue
> > > and the NPI port's normal egress queue, causing duplicate frames for the host?
> > >
> > > Conversely, the multicast masks and PGID_UC exclude BIT(CPU_PORT). Does
> > > this cause them to bypass the CPU extraction queue entirely, thereby
> > > lacking the LONG extraction prefix and breaking the host's DSA tagger parsing?
> > >
> >
> > No this is not how it works. Generally when you configure the CPU port to use
> > an NPI port, the hardware manages this internally. You do you have to start
> > using the npi port number all of a sudden.
>
> The comment is fair though. Why would you set all_phys_ports to
> GENMASK(lan9645x->num_phys_ports - 1, 0) when you can compute the mask
> of user ports which are enabled? It seems sloppy at best, and also
> contradictory (comments say "all front ports", but code includes the NPI
> port in this mask).
>
I will use dsa_user_ports(ds) as the base mask for the flood masks.
> > > [ ... ]
> > > > +int lan9645x_port_setup(struct dsa_switch *ds, int port)
> > > > +{
> > > > + struct dsa_port *dp = dsa_to_port(ds, port);
> > > > + struct lan9645x *lan9645x = ds->priv;
> > > > + struct lan9645x_port *p;
> > > > +
> > > > + p = lan9645x_to_port(lan9645x, port);
> > > > +
> > > > + if (dp->dn) {
> > > > + p->rx_internal_delay =
> > > > + of_property_present(dp->dn, "rx-internal-delay-ps");
> > > > + p->tx_internal_delay =
> > > > + of_property_present(dp->dn, "tx-internal-delay-ps");
> > > > + }
> > >
> > > These are standard integer properties specifying delays in picoseconds. If
> > > a user explicitly disables the delay via devicetree using a value of 0,
> > > will of_property_present evaluate to true and enable the hardware delay
> > > anyway? Should of_property_read_u32 be used instead to check the value?
> >
> > A value of 0 is not allowed per the bindings. The bindings enforce that if this
> > is present the value must be 2000.
>
> Bindings may change. Please use of_property_read_u32().
>
I will switch to of_property_read_u32.
^ permalink raw reply
* Re: [PATCH v6 13/21] drm: renesas: rz-du: mipi_dsi: Add RZ_MIPI_DSI_FEATURE_GPO0R feature
From: Tommaso Merciai @ 2026-04-08 14:58 UTC (permalink / raw)
To: Laurent Pinchart
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: <20260408141719.GB1965119@killaraus.ideasonboard.com>
Hi Laurent,
Thanks for your comments.
On 4/8/26 16:17, Laurent Pinchart wrote:
> On Wed, Apr 08, 2026 at 04:12:22PM +0200, Tommaso Merciai wrote:
>> Hi Laurent,
>> Thanks for your review.
>>
>> On 4/8/26 14:31, Laurent Pinchart wrote:
>>> On Wed, Apr 08, 2026 at 12:36:58PM +0200, Tommaso Merciai wrote:
>>>> The MIPI DSI ip found in the RZ/G3E SoC select the video input clock
>>>> based on the DU instance actually connected using the GPO0R register.
>>>>
>>>> Add this feature to the driver using `RZ_MIPI_DSI_FEATURE_GPO0R`, update
>>>> the code accordingly to manage the vclk selection with the introduction
>>>> of `rzg2l_mipi_dsi_get_input_port()`.
>>>>
>>>> Signed-off-by: Tommaso Merciai <tommaso.merciai.xr@bp.renesas.com>
>>>> ---
>>>> v5->v6:
>>>> - Moved rzg2l_mipi_dsi_link_write() into rzv2h_mipi_dsi_dphy_init()
>>>> + comments from HW Manual.
>>>>
>>>> v4->v5:
>>>> - No changes.
>>>>
>>>> v3->v4:
>>>> - No changes.
>>>>
>>>> v2->v3:
>>>> - No changes.
>>>>
>>>> v1->v2:
>>>> - No changes.
>>>>
>>>> .../gpu/drm/renesas/rz-du/rzg2l_mipi_dsi.c | 71 +++++++++++++++++--
>>>> .../drm/renesas/rz-du/rzg2l_mipi_dsi_regs.h | 3 +
>>>> 2 files changed, 68 insertions(+), 6 deletions(-)
>>>>
>>>> diff --git a/drivers/gpu/drm/renesas/rz-du/rzg2l_mipi_dsi.c b/drivers/gpu/drm/renesas/rz-du/rzg2l_mipi_dsi.c
>>>> index be6dbf19a24e..947c8e15fc4b 100644
>>>> --- a/drivers/gpu/drm/renesas/rz-du/rzg2l_mipi_dsi.c
>>>> +++ b/drivers/gpu/drm/renesas/rz-du/rzg2l_mipi_dsi.c
>>>> @@ -37,7 +37,9 @@ MODULE_IMPORT_NS("RZV2H_CPG");
>>>>
>>>> #define RZG2L_DCS_BUF_SIZE 128 /* Maximum DCS buffer size in external memory. */
>>>>
>>>> +#define RZ_MIPI_DSI_MAX_INPUT 2
>>>> #define RZ_MIPI_DSI_FEATURE_16BPP BIT(0)
>>>> +#define RZ_MIPI_DSI_FEATURE_GPO0R BIT(1)
>>>>
>>>> struct rzg2l_mipi_dsi;
>>>>
>>>> @@ -81,13 +83,14 @@ struct rzg2l_mipi_dsi {
>>>> struct drm_bridge bridge;
>>>> struct drm_bridge *next_bridge;
>>>>
>>>> - struct clk *vclk;
>>>> + struct clk *vclk[RZ_MIPI_DSI_MAX_INPUT];
>>>> struct clk *lpclk;
>>>>
>>>> enum mipi_dsi_pixel_format format;
>>>> unsigned int num_data_lanes;
>>>> unsigned int lanes;
>>>> unsigned long mode_flags;
>>>> + u8 vclk_idx;
>>>>
>>>> struct rzv2h_dsi_mode_calc mode_calc;
>>>>
>>>> @@ -543,8 +546,8 @@ static int rzg2l_dphy_conf_clks(struct rzg2l_mipi_dsi *dsi, unsigned long mode_f
>>>> unsigned long vclk_rate;
>>>> unsigned int bpp;
>>>>
>>>> - clk_set_rate(dsi->vclk, mode_freq * KILO);
>>>> - vclk_rate = clk_get_rate(dsi->vclk);
>>>> + clk_set_rate(dsi->vclk[dsi->vclk_idx], mode_freq * KILO);
>>>> + vclk_rate = clk_get_rate(dsi->vclk[dsi->vclk_idx]);
>>>> if (vclk_rate != mode_freq * KILO)
>>>> dev_dbg(dsi->dev, "Requested vclk rate %lu, actual %lu mismatch\n",
>>>> mode_freq * KILO, vclk_rate);
>>>> @@ -687,6 +690,19 @@ static int rzv2h_mipi_dsi_dphy_init(struct rzg2l_mipi_dsi *dsi,
>>>> rzg2l_mipi_dsi_phy_write(dsi, PLLCLKSET1R,
>>>> FIELD_PREP(PLLCLKSET1R_PLL_K, dsi_parameters->k));
>>>>
>>>> + /*
>>>> + * From RZ/G3E HW manual (Rev.1.15) section 9.5.3 Operation,
>>>> + * 9.5.3.1 Power on Reset and Initial Settings for All Operations.
>>>> + * Figure 9.5-4 Power On/Off Sequence show that after writing to
>>>> + * GPO0R.VICH register we need to wait for more than 1 x tp before
>>>> + * writing to PLLENR.PLLEN.
>>>> + *
>>>> + * Note: GPO0R is a link register, not a PHY register. This setting
>>>> + * is specific to RZ/G3E.
>>>> + */
>>>> + if (dsi->info->features & RZ_MIPI_DSI_FEATURE_GPO0R)
>>>> + rzg2l_mipi_dsi_link_write(dsi, GPO0R, dsi->vclk_idx);
>>>> +
>>>> /*
>>>> * From RZ/V2H HW manual (Rev.1.20) section 9.5.3 Operation,
>>>> * (C) After write to D-PHY registers we need to wait for more than 1 x tp
>>>> @@ -1005,6 +1021,37 @@ static int rzg2l_mipi_dsi_stop_video(struct rzg2l_mipi_dsi *dsi)
>>>> return ret;
>>>> }
>>>>
>>>> +static int rzg2l_mipi_dsi_get_input_port(struct rzg2l_mipi_dsi *dsi)
>>>> +{
>>>> + struct device_node *np = dsi->dev->of_node;
>>>> + struct device_node *remote_ep, *ep_node;
>>>> + struct of_endpoint ep;
>>>> + bool ep_enabled;
>>>> + int in_port;
>>>> +
>>>> + /* DSI can have only one port enabled */
>>>
>>> Why is that ? The hardware supports dynamic input selection, why can't
>>> it be supported at runtime ?
>>
>> For runtime/dynamic you mean using DT overlay??
>> like, remove:
>>
>> Removing - DU0 --> DSI (input 0 | port@0 ) overlay and
>> install - DU1 --> DSI (input 1 | port@1 ) overlay and
>> viceversa?
>
> No, I mean configurable by userspace, with two CRTCs sharing one DSI
> encoder.
Sorry, question:
- Is it possible to create CRTC from user space?
From hardware point only one DSI input is selectable out of 2 LCDC's at
a time.
References:
- 9.5.2.2.3 9.5 MIPI DSI Interface (DSI)
General Purpose Output 0 Register (DSI_LINK_GPO0R)
- 9.5 MIPI DSI Interface (DSI)
9.5.1.2 Block Diagram
Figure 9.5-1 Video Input Interface
Kind Regards,
Tommaso
>
>>>> + 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)
>
^ permalink raw reply
* Re: [PATCH net-next v2 2/9] dt-bindings: net: lan9645x: add LAN9645X switch bindings
From: Jens Emil Schulz Ostergaard @ 2026-04-08 14:59 UTC (permalink / raw)
To: Rob Herring
Cc: UNGLinuxDriver, Andrew Lunn, Vladimir Oltean, David S. Miller,
Eric Dumazet, Jakub Kicinski, Paolo Abeni, Simon Horman,
Krzysztof Kozlowski, Conor Dooley, Woojung Huh, Russell King,
Steen Hegelund, Daniel Machon, linux-kernel, netdev, devicetree
In-Reply-To: <20260407171854.GA2970003-robh@kernel.org>
On Tue, 2026-04-07 at 12:18 -0500, Rob Herring wrote:
> EXTERNAL EMAIL: Do not click links or open attachments unless you know the content is safe
>
> On Tue, Mar 24, 2026 at 11:46:45AM +0100, Jens Emil Schulz Østergaard wrote:
> > Add bindings for LAN9645X switch. We use a fallback compatible for the
> > smallest SKU microchip,lan96455s-switch.
> >
> > Reviewed-by: Steen Hegelund <Steen.Hegelund@microchip.com>
> > Signed-off-by: Jens Emil Schulz Østergaard <jensemil.schulzostergaard@microchip.com>
> > ---
> > Changes in v2:
> > - rename file to microchip,lan96455s-switch.yaml
> > - remove led vendor property
> > - add {rx,tx}-internal-delay-ps for rgmii delay
> > - remove labels from example
> > - remove container node from example
> > ---
> > .../net/dsa/microchip,lan96455s-switch.yaml | 119 +++++++++++++++++++++
> > MAINTAINERS | 1 +
> > 2 files changed, 120 insertions(+)
> >
> > diff --git a/Documentation/devicetree/bindings/net/dsa/microchip,lan96455s-switch.yaml b/Documentation/devicetree/bindings/net/dsa/microchip,lan96455s-switch.yaml
> > new file mode 100644
> > index 000000000000..0282e25c05d4
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/net/dsa/microchip,lan96455s-switch.yaml
> > @@ -0,0 +1,119 @@
> > +# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
> > +%YAML 1.2
> > +---
> > +$id: http://devicetree.org/schemas/net/dsa/microchip,lan96455s-switch.yaml#
> > +$schema: http://devicetree.org/meta-schemas/core.yaml#
> > +
> > +title: Microchip LAN9645x Ethernet switch
> > +
> > +maintainers:
> > + - Jens Emil Schulz Østergaard <jensemil.schulzostergaard@microchip.com>
> > +
> > +description: |
>
> Don't need '|'
I will remove this.
>
> > + The LAN9645x switch is a multi-port Gigabit AVB/TSN Ethernet switch with
> > + five integrated 10/100/1000Base-T PHYs. In addition to the integrated PHYs,
> > + it supports up to 2 RGMII/RMII, up to 2 BASE-X/SERDES/2.5GBASE-X and one
> > + Quad-SGMII interfaces.
> > +
> > +properties:
> > + compatible:
> > + oneOf:
> > + - enum:
> > + - microchip,lan96455s-switch
> > + - items:
> > + - enum:
> > + - microchip,lan96455f-switch
> > + - microchip,lan96457f-switch
> > + - microchip,lan96459f-switch
> > + - microchip,lan96457s-switch
> > + - microchip,lan96459s-switch
> > + - const: microchip,lan96455s-switch
> > +
> > + reg:
> > + maxItems: 1
> > +
> > +$ref: dsa.yaml#
>
> Since you don't have any custom properties (just constraints), this ref
> should be "dsa.yaml#/$defs/ethernet-ports".
Right, I will update the ref.
>
> > +
> > +patternProperties:
> > + "^(ethernet-)?ports$":
>
> For a new binding, use the preferred name which is ethernet-ports. ports
> and port collide with the graph binding.
>
OK, I will use ethernet-ports and move it from patternProperties to properties.
> > + type: object
> > + additionalProperties: true
> > + patternProperties:
> > + "^(ethernet-)?port@[0-8]$":
>
> And 'ethernet-port'
I will change this and update the example.
>
> > + type: object
> > + description: Ethernet switch ports
> > +
> > + $ref: dsa-port.yaml#
> > +
> > + properties:
> > + rx-internal-delay-ps:
> > + const: 2000
> > +
> > + tx-internal-delay-ps:
> > + const: 2000
> > +
> > + unevaluatedProperties: false
>
> Place this after the $ref.
I will move this.
>
> > +
> > +oneOf:
> > + - required:
> > + - ports
> > + - required:
> > + - ethernet-ports
> > +
> > +required:
> > + - compatible
> > + - reg
> > +
> > +unevaluatedProperties: false
> > +
> > +examples:
> > + - |
> > + ethernet-switch@4000 {
> > + compatible = "microchip,lan96459f-switch", "microchip,lan96455s-switch";
> > + reg = <0x4000 0x244>;
> > +
> > + ethernet-ports {
> > + #address-cells = <1>;
> > + #size-cells = <0>;
> > +
> > + port@0 {
> > + reg = <0>;
> > + phy-mode = "gmii";
> > + phy-handle = <&cuphy0>;
> > + };
> > +
> > + port@1 {
> > + reg = <1>;
> > + phy-mode = "gmii";
> > + phy-handle = <&cuphy1>;
> > + };
> > +
> > + port@2 {
> > + reg = <2>;
> > + phy-mode = "gmii";
> > + phy-handle = <&cuphy2>;
> > + };
> > +
> > + port@3 {
> > + reg = <3>;
> > + phy-mode = "gmii";
> > + phy-handle = <&cuphy3>;
> > + };
> > +
> > + port@7 {
> > + reg = <7>;
> > + phy-mode = "rgmii";
> > + ethernet = <&cpu_host_port>;
> > + rx-internal-delay-ps = <2000>;
> > + tx-internal-delay-ps = <2000>;
> > +
> > + fixed-link {
> > + speed = <1000>;
> > + full-duplex;
> > + pause;
> > + };
> > + };
> > + };
> > + };
> > +...
> > +
> > diff --git a/MAINTAINERS b/MAINTAINERS
> > index 7ae698067c41..8232da1b3951 100644
> > --- a/MAINTAINERS
> > +++ b/MAINTAINERS
> > @@ -17278,6 +17278,7 @@ M: Jens Emil Schulz Østergaard <jensemil.schulzostergaard@microchip.com>
> > M: UNGLinuxDriver@microchip.com
> > L: netdev@vger.kernel.org
> > S: Maintained
> > +F: Documentation/devicetree/bindings/net/dsa/microchip,lan96455s-switch.yaml
> > F: include/linux/dsa/lan9645x.h
> > F: net/dsa/tag_lan9645x.c
> >
> >
> > --
> > 2.52.0
> >
^ permalink raw reply
* Re: [PATCH v6 10/21] dt-bindings: display: renesas,rzg2l-du: Add support for RZ/G3E SoC
From: Laurent Pinchart @ 2026-04-08 15:00 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: <87a18664-d19e-4434-8f92-1c7ce4f3a131@bp.renesas.com>
On Wed, Apr 08, 2026 at 04:44:48PM +0200, Tommaso Merciai wrote:
> On 4/8/26 16:16, Laurent Pinchart wrote:
> > On Wed, Apr 08, 2026 at 04:02:14PM +0200, Tommaso Merciai wrote:
> >> On 4/8/26 14:24, Laurent Pinchart wrote:
> >>> On Wed, Apr 08, 2026 at 12:36:55PM +0200, Tommaso Merciai wrote:
> >>>> The RZ/G3E SoC has 2 LCD controllers (LCDC), each containing a Frame
> >>>> Compression Processor (FCPVD), a Video Signal Processor (VSPD), and a
> >>>> Display Unit (DU).
> >>>>
> >>>> - LCDC0 supports DSI and LVDS (single or dual-channel) outputs.
> >>>> - LCDC1 supports DSI, LVDS (single-channel), and RGB outputs.
> >>>>
> >>>> Add a new SoC-specific compatible string 'renesas,r9a09g047-du'.
> >>>>
> >>>> Extend patternProperties from "^port@[0-1]$" to "^port@[0-3]$" to
> >>>> allow up to four output ports, and explicitly disable port@2 and port@3
> >>>> for existing SoCs that do not expose them.
> >>>>
> >>>> Describe the four output ports of the RZ/G3E DU:
> >>>>
> >>>> - port@0: DSI (available on both LCDC instances)
> >>>> - port@1: DPAD / parallel RGB (LCDC1 only)
> >>>> - port@2: LVDS channel 0 (LCDC0 only)
> >>>> - port@3: LVDS channel 1 (available on both LCDC instances)
> >>>>
> >>>> Signed-off-by: Tommaso Merciai <tommaso.merciai.xr@bp.renesas.com>
> >>>> ---
> >>>> v5->v6:
> >>>> - Extend patternProperties from "^port@[0-1]$" to "^port@[0-3]$" and
> >>>> explicitly disable port@2 and port@3 for existing SoCs that do not expose
> >>>> them.
> >>>> - Reworked ports numbering + improved/fixed ports descriptions in the
> >>>> bindings documentation.
> >>>> - Improved commit body.
> >>>>
> >>>> v4->v5:
> >>>> - Dropped renesas,id property and updated bindings
> >>>> accordingly.
> >>>>
> >>>> v2->v3:
> >>>> - No changes.
> >>>>
> >>>> v2->v3:
> >>>> - No changes.
> >>>>
> >>>> v1->v2:
> >>>> - Use single compatible string instead of multiple compatible strings
> >>>> for the two DU instances, leveraging a 'renesas,id' property to
> >>>> differentiate between DU0 and DU1.
> >>>> - Updated commit message accordingly.
> >>>>
> >>>> .../bindings/display/renesas,rzg2l-du.yaml | 30 ++++++++++++++++++-
> >>>> 1 file changed, 29 insertions(+), 1 deletion(-)
> >>>>
> >>>> diff --git a/Documentation/devicetree/bindings/display/renesas,rzg2l-du.yaml b/Documentation/devicetree/bindings/display/renesas,rzg2l-du.yaml
> >>>> index 5add3b832eab..32da0b5ec88c 100644
> >>>> --- a/Documentation/devicetree/bindings/display/renesas,rzg2l-du.yaml
> >>>> +++ b/Documentation/devicetree/bindings/display/renesas,rzg2l-du.yaml
> >>>> @@ -20,6 +20,7 @@ properties:
> >>>> - enum:
> >>>> - renesas,r9a07g043u-du # RZ/G2UL
> >>>> - renesas,r9a07g044-du # RZ/G2{L,LC}
> >>>> + - renesas,r9a09g047-du # RZ/G3E
> >>>> - renesas,r9a09g057-du # RZ/V2H(P)
> >>>> - items:
> >>>> - enum:
> >>>> @@ -61,7 +62,7 @@ properties:
> >>>> model-dependent. Each port shall have a single endpoint.
> >>>>
> >>>> patternProperties:
> >>>> - "^port@[0-1]$":
> >>>> + "^port@[0-3]$":
> >>>> $ref: /schemas/graph.yaml#/properties/port
> >>>> unevaluatedProperties: false
> >>>>
> >>>> @@ -103,6 +104,8 @@ allOf:
> >>>> port@0:
> >>>> description: DPI
> >>>> port@1: false
> >>>> + port@2: false
> >>>> + port@3: false
> >>>>
> >>>> required:
> >>>> - port@0
> >>>> @@ -119,6 +122,8 @@ allOf:
> >>>> description: DSI
> >>>> port@1:
> >>>> description: DPI
> >>>> + port@2: false
> >>>> + port@3: false
> >>>>
> >>>> required:
> >>>> - port@0
> >>>> @@ -135,9 +140,32 @@ allOf:
> >>>> port@0:
> >>>> description: DSI
> >>>> port@1: false
> >>>> + port@2: false
> >>>> + port@3: false
> >>>>
> >>>> required:
> >>>> - port@0
> >>>> + - if:
> >>>> + properties:
> >>>> + compatible:
> >>>> + contains:
> >>>> + const: renesas,r9a09g047-du
> >>>> + then:
> >>>> + properties:
> >>>> + ports:
> >>>> + properties:
> >>>> + port@0:
> >>>> + description: DSI
> >>>> + port@1:
> >>>> + description: DPAD
> >>>> + port@2:
> >>>> + description: LVDS, Channel 0
> >>>> + port@3:
> >>>> + description: LVDS, Channel 1
> >>>> +
> >>>> + required:
> >>>> + - port@0
> >>>> + - port@3
> >>>
> >>> Why are ports 1 and 2 not required ?
> >>
> >> About this we had a similar discussion on v5[0]
> >> We are using the same compatible and:
> >>
> >> - LCDC0 supports DSI and LVDS (single or dual-channel) outputs.
> >> |
> >> --> then has:
> >> port@0
> >> port@2
> >> port@3
> >>
> >>
> >> - LCDC1 supports DSI, LVDS (single-channel), and RGB outputs.
> >> |
> >> --> then has:
> >> port@0
> >> port@1
> >> port@3
> >
> > Ah yes, I forget there are two LCDC instances with different output
> > configurations.
> >
> > Something still looks a bit weird to me though. For LCDC1, which
> > supports a single LVDS channel, you use the port described as the second
> > LVDS channel. Is there a reason not to use port@2 ?
>
> 9.11 Low Voltage Differential Signaling (LVDS)
> 9.11.1.2 Block Diagram
> Figure 9.11-1 shows a block diagram of LVDS.
>
> LCDC1 is connected to LVDS, Channel 1
> For this reason I'm using port@3.
Re-reading that, I think I've misinterpreted the hardware architecture.
Doesn't the DU have a single output, that is connected the multiple
encoders (LVDS and DSI for LCDC0 and LVDS, DSI and DPI for LCDC1) ? It
seems modelling it with a single port and multiple endpoints would
better match the device.
For LVDS in particular, I see a single LVDS encoder with two channels,
so there should not be two LVDS output ports in the DU. The two ports
should be on the output of the LVDS device.
> >> Then port@1 is required for DU1 but not for DU0.
> >> Same port@2 is required for DU0 but not for DU1.
> >>
> >> [0] https://patchwork.kernel.org/project/linux-renesas-soc/patch/ca022fdbba5236c36e0cb3095db4c31e8e0cb1b8.1770996493.git.tommaso.merciai.xr@bp.renesas.com/
> >>
> >>>>
> >>>> examples:
> >>>> # RZ/G2L DU
--
Regards,
Laurent Pinchart
^ permalink raw reply
* Re: [PATCH v3 0/7] arm64: dts: ti: k3-am62a7-sk: Split r5f memory region
From: Rob Herring @ 2026-04-08 15:03 UTC (permalink / raw)
To: Markus Schneider-Pargmann (TI)
Cc: Bjorn Andersson, Mathieu Poirier, Krzysztof Kozlowski,
Conor Dooley, Suman Anna, Nishanth Menon, Vignesh Raghavendra,
Tero Kristo, Vishal Mahaveer, Kevin Hilman, Dhruva Gole,
Sebin Francis, Kendall Willis, Akashdeep Kaur, linux-remoteproc,
devicetree, linux-kernel, linux-arm-kernel
In-Reply-To: <20260318-topic-am62a-ioddr-dt-v6-19-v3-0-c41473cb23c3@baylibre.com>
On Wed, Mar 18, 2026 at 10:14 AM Markus Schneider-Pargmann (TI)
<msp@baylibre.com> wrote:
>
> Hi,
>
> Split the firmware memory region in more specific parts so it is better
> described where which information is stored. Specifically the LPM metadata
> region is important as bootloader software like U-Boot has to know where
> that data is to be able to read that data and resume from RAM.
>
> IO+DDR is a deep sleep state in which a few pins are set to be sensitive
> for wakeup while the DDR is kept in self refresh. Everything else is
> powered off.
>
> The changes in this series were suggested as part of the IO+DDR u-boot series:
> https://lore.kernel.org/r/814c211f-a9eb-4311-bb84-165b1a69755f@ti.com
>
> There are currently no real users of the memory-region that is split in
> this series. The size of the memory-region in total stays the same.
> The new layout is derived from the software running on the r5f
> processor:
> https://github.com/TexasInstruments/mcupsdk-core-k3/blob/k3_main/examples/drivers/ipc/ipc_rpmsg_echo_linux/am62ax-sk/r5fss0-0_freertos/ti-arm-clang/linker.cmd#L172
> https://github.com/TexasInstruments/mcupsdk-core-k3/blob/k3_main/source/drivers/device_manager/sciclient.h#L459
>
> Additionally the two important devicetree nodes for resuming from IO+DDR
> have the bootph-pre-ram flag added as this data needs to be read before
> the RAM is in use.
>
> Best
> Markus
>
> Signed-off-by: Markus Schneider-Pargmann (TI) <msp@baylibre.com>
> ---
> Changes in v3:
> - Squash the enforcement of the memory-region-names requirement in the
> patch adding the memory-region-names, as suggested.
> - Link to v2: https://lore.kernel.org/r/20260312-topic-am62a-ioddr-dt-v6-19-v2-0-37cb7ceec658@baylibre.com
>
> Changes in v2:
> - Make memory-region-names required if memory-region is present
> - Fixup memory-region and memory-region-names conditions. Require either
> 2 or 6 regions for memory-region and memory-region-names
> - Reword and restructure the binding documentation for memory-region and
> memory-region-names
> - Add memory-region-names to all uses of memory-region
> - Link to v1: https://lore.kernel.org/r/20260303-topic-am62a-ioddr-dt-v6-19-v1-0-12fe72bb40d2@baylibre.com
>
> ---
> Markus Schneider-Pargmann (TI) (7):
> dt-bindings: remoteproc: k3-r5f: Split up memory regions
> dt-bindings: remoteproc: k3-r5f: Add memory-region-names
> arm64: dts: ti: k3: Use memory-region-names for r5f
> arm64: dts: ti: k3-am62a7-sk: Split r5f memory region
> arm64: dts: ti: k3-am62p5-sk: Split r5f memory region
> arm64: dts: ti: k3-am62a7-sk: Add r5f nodes to pre-ram bootphase
> arm64: dts: ti: k3-am62p5-sk: Add r5f nodes to pre-ram bootphase
TI folks, Please make sure these dts patches are picked up for 7.1.
There's now a crap load of warnings in next with the binding change:
58 (ti,am62-r5fss): r5f@78000000: 'memory-region-names' is a
required property
30 (ti,am62-r5fss): r5f@79000000: 'memory-region-names' is a
required property
22 (ti,j721s2-r5fss): r5f@5f00000: 'memory-region-names' is a
required property
22 (ti,j721s2-r5fss): r5f@5e00000: 'memory-region-names' is a
required property
22 (ti,j721s2-r5fss): r5f@5d00000: 'memory-region-names' is a
required property
22 (ti,j721s2-r5fss): r5f@5c00000: 'memory-region-names' is a
required property
22 (ti,j721s2-r5fss): r5f@41400000: 'memory-region-names' is a
required property
22 (ti,j721s2-r5fss): r5f@41000000: 'memory-region-names' is a
required property
21 (ti,am64-r5fss): r5f@78600000: 'memory-region-names' is a
required property
21 (ti,am64-r5fss): r5f@78400000: 'memory-region-names' is a
required property
21 (ti,am64-r5fss): r5f@78200000: 'memory-region-names' is a
required property
21 (ti,am64-r5fss): r5f@78000000: 'memory-region-names' is a
required property
12 (ti,j721s2-r5fss): r5f@5a00000: 'memory-region-names' is a
required property
12 (ti,j721s2-r5fss): r5f@5900000: 'memory-region-names' is a
required property
12 (ti,am654-r5fss): r5f@41400000: 'memory-region-names' is a
required property
12 (ti,am654-r5fss): r5f@41000000: 'memory-region-names' is a
required property
9 (ti,j721e-r5fss): r5f@5f00000: 'memory-region-names' is a
required property
9 (ti,j721e-r5fss): r5f@5e00000: 'memory-region-names' is a
required property
9 (ti,j721e-r5fss): r5f@5d00000: 'memory-region-names' is a
required property
9 (ti,j721e-r5fss): r5f@5c00000: 'memory-region-names' is a
required property
9 (ti,j721e-r5fss): r5f@41400000: 'memory-region-names' is a
required property
9 (ti,j721e-r5fss): r5f@41000000: 'memory-region-names' is a
required property
4 (ti,am62-r5fss): r5f@78400000: 'memory-region-names' is a
required property
3 (ti,j7200-r5fss): r5f@5d00000: 'memory-region-names' is a
required property
3 (ti,j7200-r5fss): r5f@5c00000: 'memory-region-names' is a
required property
3 (ti,j7200-r5fss): r5f@41400000: 'memory-region-names' is a
required property
3 (ti,j7200-r5fss): r5f@41000000: 'memory-region-names' is a
required property
If they aren't applied, making 'memory-region-names' required needs
to be dropped from the binding.
Rob
^ permalink raw reply
* Re: [PATCH v6 13/21] drm: renesas: rz-du: mipi_dsi: Add RZ_MIPI_DSI_FEATURE_GPO0R feature
From: Laurent Pinchart @ 2026-04-08 15:08 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: <136a9922-48ae-48e2-8cb1-14559206e7af@bp.renesas.com>
On Wed, Apr 08, 2026 at 04:58:01PM +0200, Tommaso Merciai wrote:
> On 4/8/26 16:17, Laurent Pinchart wrote:
> > On Wed, Apr 08, 2026 at 04:12:22PM +0200, Tommaso Merciai wrote:
> >> On 4/8/26 14:31, Laurent Pinchart wrote:
> >>> On Wed, Apr 08, 2026 at 12:36:58PM +0200, Tommaso Merciai wrote:
> >>>> The MIPI DSI ip found in the RZ/G3E SoC select the video input clock
> >>>> based on the DU instance actually connected using the GPO0R register.
> >>>>
> >>>> Add this feature to the driver using `RZ_MIPI_DSI_FEATURE_GPO0R`, update
> >>>> the code accordingly to manage the vclk selection with the introduction
> >>>> of `rzg2l_mipi_dsi_get_input_port()`.
> >>>>
> >>>> Signed-off-by: Tommaso Merciai <tommaso.merciai.xr@bp.renesas.com>
> >>>> ---
> >>>> v5->v6:
> >>>> - Moved rzg2l_mipi_dsi_link_write() into rzv2h_mipi_dsi_dphy_init()
> >>>> + comments from HW Manual.
> >>>>
> >>>> v4->v5:
> >>>> - No changes.
> >>>>
> >>>> v3->v4:
> >>>> - No changes.
> >>>>
> >>>> v2->v3:
> >>>> - No changes.
> >>>>
> >>>> v1->v2:
> >>>> - No changes.
> >>>>
> >>>> .../gpu/drm/renesas/rz-du/rzg2l_mipi_dsi.c | 71 +++++++++++++++++--
> >>>> .../drm/renesas/rz-du/rzg2l_mipi_dsi_regs.h | 3 +
> >>>> 2 files changed, 68 insertions(+), 6 deletions(-)
> >>>>
> >>>> diff --git a/drivers/gpu/drm/renesas/rz-du/rzg2l_mipi_dsi.c b/drivers/gpu/drm/renesas/rz-du/rzg2l_mipi_dsi.c
> >>>> index be6dbf19a24e..947c8e15fc4b 100644
> >>>> --- a/drivers/gpu/drm/renesas/rz-du/rzg2l_mipi_dsi.c
> >>>> +++ b/drivers/gpu/drm/renesas/rz-du/rzg2l_mipi_dsi.c
> >>>> @@ -37,7 +37,9 @@ MODULE_IMPORT_NS("RZV2H_CPG");
> >>>>
> >>>> #define RZG2L_DCS_BUF_SIZE 128 /* Maximum DCS buffer size in external memory. */
> >>>>
> >>>> +#define RZ_MIPI_DSI_MAX_INPUT 2
> >>>> #define RZ_MIPI_DSI_FEATURE_16BPP BIT(0)
> >>>> +#define RZ_MIPI_DSI_FEATURE_GPO0R BIT(1)
> >>>>
> >>>> struct rzg2l_mipi_dsi;
> >>>>
> >>>> @@ -81,13 +83,14 @@ struct rzg2l_mipi_dsi {
> >>>> struct drm_bridge bridge;
> >>>> struct drm_bridge *next_bridge;
> >>>>
> >>>> - struct clk *vclk;
> >>>> + struct clk *vclk[RZ_MIPI_DSI_MAX_INPUT];
> >>>> struct clk *lpclk;
> >>>>
> >>>> enum mipi_dsi_pixel_format format;
> >>>> unsigned int num_data_lanes;
> >>>> unsigned int lanes;
> >>>> unsigned long mode_flags;
> >>>> + u8 vclk_idx;
> >>>>
> >>>> struct rzv2h_dsi_mode_calc mode_calc;
> >>>>
> >>>> @@ -543,8 +546,8 @@ static int rzg2l_dphy_conf_clks(struct rzg2l_mipi_dsi *dsi, unsigned long mode_f
> >>>> unsigned long vclk_rate;
> >>>> unsigned int bpp;
> >>>>
> >>>> - clk_set_rate(dsi->vclk, mode_freq * KILO);
> >>>> - vclk_rate = clk_get_rate(dsi->vclk);
> >>>> + clk_set_rate(dsi->vclk[dsi->vclk_idx], mode_freq * KILO);
> >>>> + vclk_rate = clk_get_rate(dsi->vclk[dsi->vclk_idx]);
> >>>> if (vclk_rate != mode_freq * KILO)
> >>>> dev_dbg(dsi->dev, "Requested vclk rate %lu, actual %lu mismatch\n",
> >>>> mode_freq * KILO, vclk_rate);
> >>>> @@ -687,6 +690,19 @@ static int rzv2h_mipi_dsi_dphy_init(struct rzg2l_mipi_dsi *dsi,
> >>>> rzg2l_mipi_dsi_phy_write(dsi, PLLCLKSET1R,
> >>>> FIELD_PREP(PLLCLKSET1R_PLL_K, dsi_parameters->k));
> >>>>
> >>>> + /*
> >>>> + * From RZ/G3E HW manual (Rev.1.15) section 9.5.3 Operation,
> >>>> + * 9.5.3.1 Power on Reset and Initial Settings for All Operations.
> >>>> + * Figure 9.5-4 Power On/Off Sequence show that after writing to
> >>>> + * GPO0R.VICH register we need to wait for more than 1 x tp before
> >>>> + * writing to PLLENR.PLLEN.
> >>>> + *
> >>>> + * Note: GPO0R is a link register, not a PHY register. This setting
> >>>> + * is specific to RZ/G3E.
> >>>> + */
> >>>> + if (dsi->info->features & RZ_MIPI_DSI_FEATURE_GPO0R)
> >>>> + rzg2l_mipi_dsi_link_write(dsi, GPO0R, dsi->vclk_idx);
> >>>> +
> >>>> /*
> >>>> * From RZ/V2H HW manual (Rev.1.20) section 9.5.3 Operation,
> >>>> * (C) After write to D-PHY registers we need to wait for more than 1 x tp
> >>>> @@ -1005,6 +1021,37 @@ static int rzg2l_mipi_dsi_stop_video(struct rzg2l_mipi_dsi *dsi)
> >>>> return ret;
> >>>> }
> >>>>
> >>>> +static int rzg2l_mipi_dsi_get_input_port(struct rzg2l_mipi_dsi *dsi)
> >>>> +{
> >>>> + struct device_node *np = dsi->dev->of_node;
> >>>> + struct device_node *remote_ep, *ep_node;
> >>>> + struct of_endpoint ep;
> >>>> + bool ep_enabled;
> >>>> + int in_port;
> >>>> +
> >>>> + /* DSI can have only one port enabled */
> >>>
> >>> Why is that ? The hardware supports dynamic input selection, why can't
> >>> it be supported at runtime ?
> >>
> >> For runtime/dynamic you mean using DT overlay??
> >> like, remove:
> >>
> >> Removing - DU0 --> DSI (input 0 | port@0 ) overlay and
> >> install - DU1 --> DSI (input 1 | port@1 ) overlay and
> >> viceversa?
> >
> > No, I mean configurable by userspace, with two CRTCs sharing one DSI
> > encoder.
>
> Sorry, question:
> - Is it possible to create CRTC from user space?
No, the CRTCs are created by the driver, but you can have one DRM device
that covers two LCDCs, with one CRTC each, both connected to the same
DSI encoder (and apparently this applies to the LVDS encoder too).
Userspace then selects which CRTC drives which connector.
> From hardware point only one DSI input is selectable out of 2 LCDC's at
> a time.
>
> References:
> - 9.5.2.2.3 9.5 MIPI DSI Interface (DSI)
> General Purpose Output 0 Register (DSI_LINK_GPO0R)
>
> - 9.5 MIPI DSI Interface (DSI)
> 9.5.1.2 Block Diagram
> Figure 9.5-1 Video Input Interface
>
> >>>> + for_each_endpoint_of_node(np, ep_node) {
> >>>> + of_graph_parse_endpoint(ep_node, &ep);
> >>>> + if (ep.port >= RZ_MIPI_DSI_MAX_INPUT)
> >>>> + break;
> >>>> +
> >>>> + remote_ep = of_graph_get_remote_endpoint(ep_node);
> >>>> + ep_enabled = of_device_is_available(remote_ep);
> >>>> + of_node_put(remote_ep);
> >>>> +
> >>>> + if (ep_enabled) {
> >>>> + in_port = ep.port;
> >>>> + break;
> >>>> + }
> >>>> + }
> >>>> +
> >>>> + if (!ep_enabled)
> >>>> + return -EINVAL;
> >>>> +
> >>>> + dev_dbg(dsi->dev, "input port@%d\n", in_port);
> >>>> + return in_port;
> >>>> +}
> >>>> +
> >>>> /* -----------------------------------------------------------------------------
> >>>> * Bridge
> >>>> */
> >>>> @@ -1425,9 +1472,21 @@ static int rzg2l_mipi_dsi_probe(struct platform_device *pdev)
> >>>> if (IS_ERR(dsi->mmio))
> >>>> return PTR_ERR(dsi->mmio);
> >>>>
> >>>> - dsi->vclk = devm_clk_get(dsi->dev, "vclk");
> >>>> - if (IS_ERR(dsi->vclk))
> >>>> - return PTR_ERR(dsi->vclk);
> >>>> + dsi->vclk[0] = devm_clk_get(dsi->dev, "vclk");
> >>>> + if (IS_ERR(dsi->vclk[0]))
> >>>> + return PTR_ERR(dsi->vclk[0]);
> >>>> +
> >>>> + if (dsi->info->features & RZ_MIPI_DSI_FEATURE_GPO0R) {
> >>>> + dsi->vclk[1] = devm_clk_get(dsi->dev, "vclk2");
> >>>> + if (IS_ERR(dsi->vclk[1]))
> >>>> + return PTR_ERR(dsi->vclk[1]);
> >>>> +
> >>>> + ret = rzg2l_mipi_dsi_get_input_port(dsi);
> >>>> + if (ret < 0)
> >>>> + return dev_err_probe(dsi->dev, -EINVAL,
> >>>> + "No available input port\n");
> >>>> + dsi->vclk_idx = ret;
> >>>> + }
> >>>>
> >>>> dsi->lpclk = devm_clk_get(dsi->dev, "lpclk");
> >>>> if (IS_ERR(dsi->lpclk))
> >>>> diff --git a/drivers/gpu/drm/renesas/rz-du/rzg2l_mipi_dsi_regs.h b/drivers/gpu/drm/renesas/rz-du/rzg2l_mipi_dsi_regs.h
> >>>> index 2bef20566648..cee2e0bc5dc5 100644
> >>>> --- a/drivers/gpu/drm/renesas/rz-du/rzg2l_mipi_dsi_regs.h
> >>>> +++ b/drivers/gpu/drm/renesas/rz-du/rzg2l_mipi_dsi_regs.h
> >>>> @@ -83,6 +83,9 @@
> >>>> #define LINKSR_SQCHRUN1 BIT(4)
> >>>> #define LINKSR_SQCHRUN0 BIT(0)
> >>>>
> >>>> +/* RZ/G3E General Purpose Output 0 Register */
> >>>> +#define GPO0R 0xc0
> >>>> +
> >>>> /* Tx Set Register */
> >>>> #define TXSETR 0x100
> >>>> #define TXSETR_NUMLANECAP (0x3 << 16)
--
Regards,
Laurent Pinchart
^ permalink raw reply
* [PATCH] arm64: dts: rockchip: fix rk809 interrupt pin on rk3566-roc-pc
From: guoweix @ 2026-04-08 15:09 UTC (permalink / raw)
To: heiko
Cc: robh, krzk+dt, conor+dt, f.kardame, pgwipeout, devicetree,
linux-arm-kernel, linux-rockchip, linux-kernel, guoweix
The RK809 PMIC interrupt pin on the Firefly ROC-RK3566-PC (Station M2)
is physically connected to GPIO0_A3 (RK_PA3) according to the board's
schematic.
Currently, the PMIC node incorrectly specifies RK_PA7 for the interrupt,
which prevents the PMIC from correctly signaling interrupts. (Note that
the pinctrl node 'pmic_int' correctly configures RK_PA3).
Fix this by updating the interrupts property to use RK_PA3.
Fixes: 30ac9b4e25d8 ("arm64: dts: rockchip: add dts for Firefly Station M2 rk3566")
Signed-off-by: guoweix <2298701336@qq.com>
---
arch/arm64/boot/dts/rockchip/rk3566-roc-pc.dts | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm64/boot/dts/rockchip/rk3566-roc-pc.dts b/arch/arm64/boot/dts/rockchip/rk3566-roc-pc.dts
index 7e499064e035..985770e3a5e2 100644
--- a/arch/arm64/boot/dts/rockchip/rk3566-roc-pc.dts
+++ b/arch/arm64/boot/dts/rockchip/rk3566-roc-pc.dts
@@ -245,7 +245,7 @@ rk809: pmic@20 {
compatible = "rockchip,rk809";
reg = <0x20>;
interrupt-parent = <&gpio0>;
- interrupts = <RK_PA7 IRQ_TYPE_LEVEL_LOW>;
+ interrupts = <RK_PA3 IRQ_TYPE_LEVEL_LOW>;
clock-output-names = "rk808-clkout1", "rk808-clkout2";
assigned-clocks = <&cru I2S1_MCLKOUT_TX>;
assigned-clock-parents = <&cru CLK_I2S1_8CH_TX>;
--
2.43.0
^ permalink raw reply related
* Re: [PATCH v2] net: dsa: microchip: implement KSZ87xx Module 3 low-loss cable errata
From: Fidelio LAWSON @ 2026-04-08 15:25 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: <a350c4b7-d816-455b-83c0-f4d98299c637@lunn.ch>
On 4/8/26 14:43, Andrew Lunn wrote:
>> The control register defines the following modes:
>> bits [1:0]:
>> 00 = workaround disabled
>> 01 = workaround 1 (DSP EQ training adjustment, LinkMD reg 0x3c)
>> 10 = workaround 2 (receiver LPF bandwidth, LinkMD reg 0x4c)
>
> There was a comment, which i only read after making the suggestion to
> use two bits, of exposing the different low pass filter bandwidths,
> rather than just picking one value. How useful is that?
>
> Andrew
Initially I limited the LPF setting to the single bandwidth explicitly
recommended by the errata (62MHz).
But I’ll extend the implementation to expose all documented LPF
bandwidth options so the interface is more flexible for users.
Best regards,
Fidelio
^ permalink raw reply
* Re: [net-next v1 v1 1/5] dt-bindings: net: starfive,jh7110-dwmac: Remove JH8100
From: Andrew Lunn @ 2026-04-08 15:27 UTC (permalink / raw)
To: Minda Chen
Cc: 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, linux-kernel, linux-stm32, devicetree
In-Reply-To: <20260408084416.29753-2-minda.chen@starfivetech.com>
On Wed, Apr 08, 2026 at 04:44:12PM +0800, Minda Chen wrote:
> Remove JH8100 dt-bindings because do not support it now.
Could you expand on that. If there are devices out in the field, we
don't just drop support for it because the vendor has something newer.
If the device never made it outside of the vendors lab, then we might
consider dropping it.
Please explain in detail why this is being dropped.
Andrew
^ permalink raw reply
* Re: [net-next v1 v1 3/5] dt-bindings: net: starfive,jh7110-dwmac: Add JHB100 sgmii rx clk
From: Andrew Lunn @ 2026-04-08 15:33 UTC (permalink / raw)
To: Minda Chen
Cc: 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, linux-kernel, linux-stm32, devicetree
In-Reply-To: <20260408084416.29753-4-minda.chen@starfivetech.com>
> + - description: SGMII RX clock
>
> clock-names:
> - items:
> - - const: stmmaceth
> - - const: pclk
> - - const: ptp_ref
> - - const: tx
> - - const: gtx
> + minItems: 5
> + maxItems: 6
> + contains:
> + enum:
> + - stmmaceth
> + - pclk
> + - ptp_ref
> + - tx
> + - gtx
> + - rx
If this is only used for sgmii, maybe it should have sgmii in the
name?
Andrew
^ permalink raw reply
* Re: [net-next v1 v1 4/5] net: stmmac: starfive: Add JHB100 SGMII interface
From: Andrew Lunn @ 2026-04-08 15:36 UTC (permalink / raw)
To: Minda Chen
Cc: 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, linux-kernel, linux-stm32, devicetree
In-Reply-To: <20260408084416.29753-5-minda.chen@starfivetech.com>
> + 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");
> +
The SGMII clock is optional...
> /* 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;
So you probably want to return an error here if it is missing.
Or you might want to look at the compatible, and make the clock
mandatory for this device.
Andrew
^ permalink raw reply
* Re: [PATCH v4 2/4] ASoC: codecs: Add TAS67524 quad-channel audio amplifier driver
From: Mark Brown @ 2026-04-08 15:41 UTC (permalink / raw)
To: Sen Wang
Cc: linux-sound, lgirdwood, robh, krzk+dt, conor+dt, devicetree,
perex, tiwai, shenghao-ding, kevin-lu, baojun.xu, niranjan.hy,
l-badrinarayanan, devarsht, v-singh1, linux-kernel
In-Reply-To: <20260408053149.1369350-3-sen@ti.com>
[-- Attachment #1: Type: text/plain, Size: 2697 bytes --]
On Wed, Apr 08, 2026 at 12:31:46AM -0500, Sen Wang wrote:
> +static int tas675x_dsp_mem_write(struct tas675x_priv *tas, u8 page, u8 reg, u32 val)
> +{
> +out:
> + __tas675x_select_book(tas, TAS675X_BOOK_DEFAULT);
> + mutex_unlock(&tas->io_lock);
Do we really need to restore the book here? The book select register is
marked as volatile so regmap will figure things out if it's the next
thing to write, and anything else will need to set whatever it wants
anyway. Alternatively if the book register were cached (which wouldn't
be a bad idea) then we'd need to restore whatever the cache has or
invalidate the cache.
> +static int tas675x_dsp_mem_read(struct tas675x_priv *tas, u8 page, u8 reg, u32 *val)
> +{
> +out:
> + __tas675x_select_book(tas, TAS675X_BOOK_DEFAULT);
> + mutex_unlock(&tas->io_lock);
Same here
> +static int tas675x_rtldg_thresh_info(struct snd_kcontrol *kcontrol,
> + struct snd_ctl_elem_info *uinfo)
> +{
> + uinfo->type = SNDRV_CTL_ELEM_TYPE_INTEGER;
> + uinfo->count = 1;
> + uinfo->value.integer.min = 0;
> + /* Accepts 32-bit values, even though 8bit MSB is ignored */
> + uinfo->value.integer.max = 0xFFFFFFFF;
This is going to break on 32 bit architectures since long is a 32 bit
signed value. You want LONG_MAX, or to restrict the value (which would
be more friendly to mixer-test!).
> +static int tas675x_set_dcldg_trigger(struct snd_kcontrol *kcontrol,
> + struct snd_ctl_elem_value *ucontrol)
> +{
> + /* Wait for LOAD_DIAG to exit */
> + regmap_read_poll_timeout(tas->regmap, TAS675X_STATE_REPORT_CH1_CH2_REG,
> + state, (state & 0x0F) != TAS675X_STATE_LOAD_DIAG &&
> + (state >> 4) != TAS675X_STATE_LOAD_DIAG,
> + TAS675X_POLL_INTERVAL_US,
> + TAS675X_STATE_TRANSITION_TIMEOUT_US);
> + regmap_read_poll_timeout(tas->regmap, TAS675X_STATE_REPORT_CH3_CH4_REG,
> + state34, (state34 & 0x0F) != TAS675X_STATE_LOAD_DIAG &&
> + (state34 >> 4) != TAS675X_STATE_LOAD_DIAG,
> + TAS675X_POLL_INTERVAL_US,
> + TAS675X_STATE_TRANSITION_TIMEOUT_US);
Don't know how likely it is in practice but we ignore any timeout
failures in this function.
> +static irqreturn_t tas675x_irq_handler(int irq, void *data)
> +{
> + struct tas675x_priv *tas = data;
> +
> + if (!tas675x_check_faults(tas))
> + return IRQ_NONE;
> +
> + regmap_write(tas->regmap, TAS675X_RESET_REG, TAS675X_FAULT_CLEAR);
> + return IRQ_HANDLED;
> +}
This probably ought to take a runtime PM reference to ensure the I2C
controller is woken up, and in case in future you get regulator support.
Even if the device itself shouldn't be generating interrupts while it's
idle the interrupt might be shared or something might fire for some
other reason.
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply
* Re: [PATCH v2 2/3] remoteproc: imx_rproc: Pass bootaddr to SM CPU/LMM reset vector
From: Mathieu Poirier @ 2026-04-08 15:46 UTC (permalink / raw)
To: Peng Fan
Cc: Peng Fan (OSS), Bjorn Andersson, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Frank Li, Sascha Hauer, Pengutronix Kernel Team,
Fabio Estevam, Daniel Baluta, linux-remoteproc@vger.kernel.org,
devicetree@vger.kernel.org, imx@lists.linux.dev,
linux-arm-kernel@lists.infradead.org,
linux-kernel@vger.kernel.org
In-Reply-To: <PAXPR04MB8459AA009C932EB9D6139A11885BA@PAXPR04MB8459.eurprd04.prod.outlook.com>
On Wed, Apr 08, 2026 at 01:30:16AM +0000, Peng Fan wrote:
> > Subject: Re: [PATCH v2 2/3] remoteproc: imx_rproc: Pass bootaddr to
> > SM CPU/LMM reset vector
> >
> [...]
> >
> > >
> > > Aligning the ELF entry point with the hardware reset base on
> > Cortex‑M
> > > systems is possible, but it comes with several risks.
> >
> > I'm not asking to align the ELF entry point with the hardware reset base.
> > All I want is to have the correct start address embedded in the ELF file
> > to avoid having to use a mask.
>
> I see, per my understanding:
> FreeRTOS typically exposes __isr_vector, which corresponds to the hardware
> reset / vector table base.
> Zephyr (Cortex‑M) exposes _vector_table, which serves the same purpose.
> I am not certain about other RTOSes, but the pattern seems consistent:
> the vector table base is already available as a named ELF symbol.
>
> Given that, if the preferred approach is to parse the ELF and explicitly
> retrieve the hardware reset base, I can update the implementation accordingly.
> If you prefer to parse the elf file to get the hardware reset base,
> I could update to use them.
>
> Options1: Something as below:
> 1. Include rproc_elf_find_symbol in remoteproc_elf_loader.c
> 2. Use below in imx_rproc.c
> ret = rproc_elf_find_symbol(rproc, fw, "__isr_vector", &vector_base);
> if (ret)
> ret = rproc_elf_find_symbol(rproc, fw, "__vector_table", &vector_base);
>
> if (!ret)
> rproc->bootaddr = vector_base
> else
> dev_info(dev, "no __isr_vector or __vector_table\n")
No
>
> This makes the hardware reset base explicit, avoids masking e_entry.
>
> Option 2: User‑provided reset symbol via sysfs
> As an alternative, we could expose a sysfs attribute,
> e.g. reset_symbol, allowing users to specify the symbol name
> to be used as the reset base:
>
> echo __isr_vector > /sys/class/remoteproc/remoteprocX/reset_symbol
>
Definitely not.
The definition of e_entry in the specification is clear, i.e "the address of the
entry point from where the process starts executing". If masking is required
because the tool that puts the image together gets the wrong address, then it
should be fixed.
> The remoteproc core would then resolve that symbol from
> the ELF and set rproc->bootaddr accordingly.
> This provides maximum flexibility but does introduce a new user‑visible ABI,
> so I see it more as an opt‑in or fallback mechanism.
>
> Please let me know which approach you prefer, and I will update
> this series accordingly in v3..
>
> Thanks,
> Peng.
>
>
> >
> > > 1, Semantic mismatch (ELF vs. hardware behavior) 2, Debuggers may
> > > attempt to set breakpoints or start execution at the entry symbol
> > >
^ permalink raw reply
* Re: [PATCH v2 2/3] remoteproc: imx_rproc: Pass bootaddr to SM CPU/LMM reset vector
From: Daniel Baluta @ 2026-04-08 16:00 UTC (permalink / raw)
To: Peng Fan, Mathieu Poirier, Peng Fan (OSS)
Cc: Bjorn Andersson, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Frank Li, Sascha Hauer, Pengutronix Kernel Team, Fabio Estevam,
Daniel Baluta, linux-remoteproc@vger.kernel.org,
devicetree@vger.kernel.org, imx@lists.linux.dev,
linux-arm-kernel@lists.infradead.org,
linux-kernel@vger.kernel.org
In-Reply-To: <PAXPR04MB8459AA009C932EB9D6139A11885BA@PAXPR04MB8459.eurprd04.prod.outlook.com>
On 4/8/26 04:30, Peng Fan wrote:
>> Subject: Re: [PATCH v2 2/3] remoteproc: imx_rproc: Pass bootaddr to
>> SM CPU/LMM reset vector
>>
> [...]
>>> Aligning the ELF entry point with the hardware reset base on
>> Cortex‑M
>>> systems is possible, but it comes with several risks.
>> I'm not asking to align the ELF entry point with the hardware reset base.
>> All I want is to have the correct start address embedded in the ELF file
>> to avoid having to use a mask.
> I see, per my understanding:
> FreeRTOS typically exposes __isr_vector, which corresponds to the hardware
> reset / vector table base.
> Zephyr (Cortex‑M) exposes _vector_table, which serves the same purpose.
> I am not certain about other RTOSes, but the pattern seems consistent:
> the vector table base is already available as a named ELF symbol.
>
> Given that, if the preferred approach is to parse the ELF and explicitly
> retrieve the hardware reset base, I can update the implementation accordingly.
> If you prefer to parse the elf file to get the hardware reset base,
> I could update to use them.
>
> Options1: Something as below:
> 1. Include rproc_elf_find_symbol in remoteproc_elf_loader.c
> 2. Use below in imx_rproc.c
> ret = rproc_elf_find_symbol(rproc, fw, "__isr_vector", &vector_base);
> if (ret)
> ret = rproc_elf_find_symbol(rproc, fw, "__vector_table", &vector_base);
>
> if (!ret)
> rproc->bootaddr = vector_base
> else
> dev_info(dev, "no __isr_vector or __vector_table\n")
>
> This makes the hardware reset base explicit, avoids masking e_entry.
>
> Option 2: User‑provided reset symbol via sysfs
> As an alternative, we could expose a sysfs attribute,
> e.g. reset_symbol, allowing users to specify the symbol name
> to be used as the reset base:
>
> echo __isr_vector > /sys/class/remoteproc/remoteprocX/reset_symbol
>
> The remoteproc core would then resolve that symbol from
> the ELF and set rproc->bootaddr accordingly.
> This provides maximum flexibility but does introduce a new user‑visible ABI,
> so I see it more as an opt‑in or fallback mechanism.
>
> Please let me know which approach you prefer, and I will update
> this series accordingly in v3..
I would go with option 1) as this and having something like this:
#define IMX_RPROC_DEFAULT_RST_VECTOR_NAME "..."
later we can expand that with a configurable name via sysfs.
This was along my initial proposal where you would determine
the reset vector address from the elf file.
^ permalink raw reply
* Re: [PATCH 1/6] net: ipa: fix GENERIC_CMD register field masks for IPA v5.0+
From: Simon Horman @ 2026-04-08 16:34 UTC (permalink / raw)
To: Luca Weiss
Cc: Alex Elder, Andrew Lunn, David S. Miller, Eric Dumazet,
Jakub Kicinski, Paolo Abeni, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Bjorn Andersson, Konrad Dybcio, Alexander Koskovich,
~postmarketos/upstreaming, phone-devel, netdev, linux-kernel,
linux-arm-msm, devicetree
In-Reply-To: <20260403-milos-ipa-v1-1-01e9e4e03d3e@fairphone.com>
On Fri, Apr 03, 2026 at 06:43:47PM +0200, Luca Weiss wrote:
> From: Alexander Koskovich <akoskovich@pm.me>
>
> Fix the field masks to match the hardware layout documented in
> downstream GSI (GSI_V3_0_EE_n_GSI_EE_GENERIC_CMD_*).
>
> Notably this fixes a WARN I was seeing when I tried to send "stop"
> to the MPSS remoteproc while IPA was up.
>
> Fixes: faf0678ec8a0 ("net: ipa: add IPA v5.0 GSI register definitions")
> Signed-off-by: Alexander Koskovich <akoskovich@pm.me>
> Signed-off-by: Luca Weiss <luca.weiss@fairphone.com>
Reviewed-by: Simon Horman <horms@kernel.org>
^ permalink raw reply
* Re: [PATCH 2/6] net: ipa: fix event ring index not programmed for IPA v5.0+
From: Simon Horman @ 2026-04-08 16:35 UTC (permalink / raw)
To: Luca Weiss
Cc: Alex Elder, Andrew Lunn, David S. Miller, Eric Dumazet,
Jakub Kicinski, Paolo Abeni, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Bjorn Andersson, Konrad Dybcio, Alexander Koskovich,
~postmarketos/upstreaming, phone-devel, netdev, linux-kernel,
linux-arm-msm, devicetree
In-Reply-To: <20260403-milos-ipa-v1-2-01e9e4e03d3e@fairphone.com>
On Fri, Apr 03, 2026 at 06:43:48PM +0200, Luca Weiss wrote:
> From: Alexander Koskovich <akoskovich@pm.me>
>
> For IPA v5.0+, the event ring index field moved from CH_C_CNTXT_0 to
> CH_C_CNTXT_1. The v5.0 register definition intended to define this
> field in the CH_C_CNTXT_1 fmask array but used the old identifier of
> ERINDEX instead of CH_ERINDEX.
>
> Without a valid event ring, GSI channels could never signal transfer
> completions. This caused gsi_channel_trans_quiesce() to block
> forever in wait_for_completion().
>
> At least for IPA v5.2 this resolves an issue seen where runtime
> suspend, system suspend, and remoteproc stop all hanged forever. It
> also meant the IPA data path was completely non functional.
>
> Fixes: faf0678ec8a0 ("net: ipa: add IPA v5.0 GSI register definitions")
> Signed-off-by: Alexander Koskovich <akoskovich@pm.me>
> Signed-off-by: Luca Weiss <luca.weiss@fairphone.com>
Reviewed-by: Simon Horman <horms@kernel.org>
^ permalink raw reply
* Re: [PATCH 4/6] net: ipa: add IPA v5.2 configuration data
From: Simon Horman @ 2026-04-08 16:36 UTC (permalink / raw)
To: Luca Weiss
Cc: Alex Elder, Andrew Lunn, David S. Miller, Eric Dumazet,
Jakub Kicinski, Paolo Abeni, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Bjorn Andersson, Konrad Dybcio, Alexander Koskovich,
~postmarketos/upstreaming, phone-devel, netdev, linux-kernel,
linux-arm-msm, devicetree
In-Reply-To: <20260403-milos-ipa-v1-4-01e9e4e03d3e@fairphone.com>
On Fri, Apr 03, 2026 at 06:43:50PM +0200, Luca Weiss wrote:
> Add the configuration data required for IPA v5.2, which is used in
> the Qualcomm Milos SoC.
>
> Signed-off-by: Luca Weiss <luca.weiss@fairphone.com>
> ---
> drivers/net/ipa/Makefile | 2 +-
> drivers/net/ipa/data/ipa_data-v5.2.c | 452 +++++++++++++++++++++++++++++++++++
> drivers/net/ipa/gsi_reg.c | 1 +
> drivers/net/ipa/ipa_data.h | 1 +
> drivers/net/ipa/ipa_main.c | 4 +
> drivers/net/ipa/ipa_reg.c | 1 +
> drivers/net/ipa/ipa_sysfs.c | 2 +
> drivers/net/ipa/ipa_version.h | 2 +
> 8 files changed, 464 insertions(+), 1 deletion(-)
Reviewed-by: Simon Horman <horms@kernel.org>
I'm not suggesting a change to this patch.
But it does seem to me that there is a lot of commonality
between drivers/net/ipa/data/ipa_data-v*.c.
And it would be nice if that could be consolidated somehow.
...
^ permalink raw reply
* [PATCH v2 2/2] fpga: ts73xx-fpga: add OF match table for device tree probing
From: Phil Pemberton @ 2026-04-08 16:52 UTC (permalink / raw)
To: Moritz Fischer, Xu Yilun, Rob Herring, Krzysztof Kozlowski,
Conor Dooley
Cc: Tom Rix, Florian Fainelli, linux-fpga, devicetree, linux-kernel,
Phil Pemberton
In-Reply-To: <20260408165223.3051759-1-philpem@philpem.me.uk>
The ts73xx-fpga driver currently only matches by platform device name,
which prevents it from being probed when the device is described in a
device tree. Add an of_device_id table so the driver can match against
the "technologic,ts7300-fpga" compatible string.
The TS-7350 and TS-7390 use different FPGAs with a different programming
interface, so while the driver is named "ts73xx-fpga", it doesn't apply
to them.
Signed-off-by: Phil Pemberton <philpem@philpem.me.uk>
---
drivers/fpga/ts73xx-fpga.c | 9 +++++++++
1 file changed, 9 insertions(+)
diff --git a/drivers/fpga/ts73xx-fpga.c b/drivers/fpga/ts73xx-fpga.c
index 4e1d2a4d3df4..3460e4809f86 100644
--- a/drivers/fpga/ts73xx-fpga.c
+++ b/drivers/fpga/ts73xx-fpga.c
@@ -11,6 +11,7 @@
#include <linux/delay.h>
#include <linux/io.h>
#include <linux/module.h>
+#include <linux/of.h>
#include <linux/platform_device.h>
#include <linux/string.h>
#include <linux/iopoll.h>
@@ -119,9 +120,17 @@ static int ts73xx_fpga_probe(struct platform_device *pdev)
return PTR_ERR_OR_ZERO(mgr);
}
+static const struct of_device_id ts73xx_fpga_of_match[] = {
+ { .compatible = "technologic,ts7300-fpga" },
+ {},
+};
+
+MODULE_DEVICE_TABLE(of, ts73xx_fpga_of_match);
+
static struct platform_driver ts73xx_fpga_driver = {
.driver = {
.name = "ts73xx-fpga-mgr",
+ .of_match_table = ts73xx_fpga_of_match,
},
.probe = ts73xx_fpga_probe,
};
--
2.43.0
^ permalink raw reply related
* [PATCH v2 0/2] Add device tree binding for ts73xx-fpga
From: Phil Pemberton @ 2026-04-08 16:52 UTC (permalink / raw)
To: Moritz Fischer, Xu Yilun, Rob Herring, Krzysztof Kozlowski,
Conor Dooley
Cc: Tom Rix, Florian Fainelli, linux-fpga, devicetree, linux-kernel,
Phil Pemberton
The driver for the Technologic Systems (EmbeddedTS) TS-7300 board's
onboard FPGA didn't have an OF match table. This prevented it from being
instantiated from a device tree. This is undesirable given EP93xx is
moving to device tree, and effectively prevents it from being used.
This patch series adds the OF match table and a device tree binding.
Changes since v1:
- Use specific compatible "technologic,ts7300-fpga" instead of
wildcard "technologic,ts73xx-fpga" (Krzysztof)
- Fix subject line for dt-bindings patch (Krzysztof)
- Simplify example in binding doc (Krzysztof)
Phil Pemberton (2):
dt-bindings: fpga: Technologic Systems TS-7300 FPGA Manager
fpga: ts73xx-fpga: add OF match table for device tree probing
.../fpga/technologic,ts7300-fpga.yaml | 36 +++++++++++++++++++
drivers/fpga/ts73xx-fpga.c | 9 +++++
2 files changed, 45 insertions(+)
create mode 100644 Documentation/devicetree/bindings/fpga/technologic,ts7300-fpga.yaml
--
2.43.0
^ permalink raw reply
* [PATCH v2 1/2] dt-bindings: fpga: Technologic Systems TS-7300 FPGA Manager
From: Phil Pemberton @ 2026-04-08 16:52 UTC (permalink / raw)
To: Moritz Fischer, Xu Yilun, Rob Herring, Krzysztof Kozlowski,
Conor Dooley
Cc: Tom Rix, Florian Fainelli, linux-fpga, devicetree, linux-kernel,
Phil Pemberton
In-Reply-To: <20260408165223.3051759-1-philpem@philpem.me.uk>
Add device tree binding documentation for the Altera Cyclone II FPGA
found on Technologic Systems (now EmbeddedTS) TS-7300 boards, programmed
via the memory-mapped interface in the CPLD.
Signed-off-by: Phil Pemberton <philpem@philpem.me.uk>
---
.../fpga/technologic,ts7300-fpga.yaml | 36 +++++++++++++++++++
1 file changed, 36 insertions(+)
create mode 100644 Documentation/devicetree/bindings/fpga/technologic,ts7300-fpga.yaml
diff --git a/Documentation/devicetree/bindings/fpga/technologic,ts7300-fpga.yaml b/Documentation/devicetree/bindings/fpga/technologic,ts7300-fpga.yaml
new file mode 100644
index 000000000000..c93e3a1a135b
--- /dev/null
+++ b/Documentation/devicetree/bindings/fpga/technologic,ts7300-fpga.yaml
@@ -0,0 +1,36 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/fpga/technologic,ts7300-fpga.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Technologic Systems TS-7300 FPGA Manager
+
+maintainers:
+ - Florian Fainelli <f.fainelli@gmail.com>
+
+description:
+ FPGA manager for the Altera Cyclone II FPGA on Technologic Systems
+ TS-7300 board. The FPGA is programmed via the memory-mapped interface
+ implemented in the CPLD.
+
+properties:
+ compatible:
+ const: technologic,ts7300-fpga
+
+ reg:
+ maxItems: 1
+
+required:
+ - compatible
+ - reg
+
+additionalProperties: false
+
+examples:
+ - |
+ fpga-mgr@13c00000 {
+ compatible = "technologic,ts7300-fpga";
+ reg = <0x13c00000 0x2>;
+ };
+...
--
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