| Message ID | 20250302181808.728734-3-prabhakar.mahadev-lad.rj@bp.renesas.com (mailing list archive) |
|---|---|
| State | New |
| Delegated to: | Netdev Maintainers |
| Headers | show |
| Series | Add GBETH glue layer driver for Renesas RZ/V2H(P) SoC | expand |
| Context | Check | Description |
|---|---|---|
| netdev/tree_selection | success | Not a local patch |
> + interrupts: > + items: > + - description: Subsystem interrupt > + - description: The interrupt to manage the remote wake-up packet detection > + - description: The interrupt that occurs when Tx/Rx enters/exits the LPI state > + - description: Per-channel transmission-0 completion interrupt > + - description: Per-channel transmission-1 completion interrupt > + - description: Per-channel transmission-2 completion interrupt > + - description: Per-channel transmission-3 completion interrupt > + - description: Per-channel receive-0 completion interrupt > + - description: Per-channel receive-1 completion interrupt > + - description: Per-channel receive-2 completion interrupt > + - description: Per-channel receive-3 completion interrupt > + > + interrupt-names: > + items: > + - const: macirq > + - const: eth_wake_irq > + - const: eth_lpi > + - const: tx0 > + - const: tx1 > + - const: tx2 > + - const: tx3 > + - const: rx0 > + - const: rx1 > + - const: rx2 > + - const: rx3 There has already been a discussion about trying to make the clock names more uniform. But what about interrupts? Which of these are in the IP databook? What names does the databook use for these interrupts? Andrew
> + clock-names: > + items: > + - const: stmmaceth > + - const: pclk > + - const: ptp_ref > + - const: tx > + - const: rx > + - const: tx-180 > + - const: rx-180 As Russell said in an older thread, tx and tx-180 are effectively the same clock, but with an inverter added. You should be able to arrange the clock tree that if you enable tx, it also enables tx-180 as a parent/sibling relationship. Andrew
On Sun, Mar 02, 2025 at 08:10:26PM +0100, Andrew Lunn wrote: > > + interrupts: > > + items: > > + - description: Subsystem interrupt > > + - description: The interrupt to manage the remote wake-up packet detection > > + - description: The interrupt that occurs when Tx/Rx enters/exits the LPI state > > + - description: Per-channel transmission-0 completion interrupt > > + - description: Per-channel transmission-1 completion interrupt > > + - description: Per-channel transmission-2 completion interrupt > > + - description: Per-channel transmission-3 completion interrupt > > + - description: Per-channel receive-0 completion interrupt > > + - description: Per-channel receive-1 completion interrupt > > + - description: Per-channel receive-2 completion interrupt > > + - description: Per-channel receive-3 completion interrupt > > + > > + interrupt-names: > > + items: > > + - const: macirq > > + - const: eth_wake_irq > > + - const: eth_lpi > > + - const: tx0 > > + - const: tx1 > > + - const: tx2 > > + - const: tx3 > > + - const: rx0 > > + - const: rx1 > > + - const: rx2 > > + - const: rx3 > > There has already been a discussion about trying to make the clock > names more uniform. But what about interrupts? Which of these are in > the IP databook? What names does the databook use for these > interrupts? From a quick look, I haven't found anything that suggests the above is possible, but it clearly is... so I'll look more tomorrow.
Hi Andrew, On Sun, Mar 2, 2025 at 7:25 PM Andrew Lunn <andrew@lunn.ch> wrote: > > > + clock-names: > > + items: > > + - const: stmmaceth > > + - const: pclk > > + - const: ptp_ref > > + - const: tx > > + - const: rx > > + - const: tx-180 > > + - const: rx-180 > > As Russell said in an older thread, tx and tx-180 are effectively the > same clock, but with an inverter added. You should be able to arrange > the clock tree that if you enable tx, it also enables tx-180 as a > parent/sibling relationship. > I can certainly do that, but not sure in the DT we will be describing the HW correctly then. I'll have to hide *-180 clocks In the DT and handle and turning on/off these clocks in the clock driver. Currently eth0: ethernet@15c30000 { compatible = "renesas,r9a09g057-gbeth", "renesas,rzv2h-gbeth", "snps,dwmac-5.20"; reg = <0 0x15c30000 0 0x10000>; interrupts = <GIC_SPI 765 IRQ_TYPE_LEVEL_HIGH>, <GIC_SPI 767 IRQ_TYPE_LEVEL_HIGH>, <GIC_SPI 766 IRQ_TYPE_LEVEL_HIGH>, <GIC_SPI 768 IRQ_TYPE_LEVEL_HIGH>, <GIC_SPI 769 IRQ_TYPE_LEVEL_HIGH>, <GIC_SPI 770 IRQ_TYPE_LEVEL_HIGH>, <GIC_SPI 771 IRQ_TYPE_LEVEL_HIGH>, <GIC_SPI 772 IRQ_TYPE_LEVEL_HIGH>, <GIC_SPI 773 IRQ_TYPE_LEVEL_HIGH>, <GIC_SPI 774 IRQ_TYPE_LEVEL_HIGH>, <GIC_SPI 745 IRQ_TYPE_LEVEL_HIGH>; interrupt-names = "macirq", "eth_wake_irq", "eth_lpi", "tx0", "tx1", "tx2", "tx3", "rx0", "rx1", "rx2", "rx3"; clocks = <&cpg CPG_MOD 0xbd>, <&cpg CPG_MOD 0xbc>, <&cpg CPG_CORE R9A09G057_GBETH_0_CLK_PTP_REF_I>, <&cpg CPG_MOD 0xb8>, <&cpg CPG_MOD 0xb9>, <&cpg CPG_MOD 0xba>, <&cpg CPG_MOD 0xbb>; clock-names = "stmmaceth", "pclk", "ptp_ref", "tx", "rx", "tx-180", "rx-180"; resets = <&cpg 0xb0>; ..... }; Cheers, Prabhakar
On Sun, Mar 02, 2025 at 08:41:39PM +0000, Lad, Prabhakar wrote: > Hi Andrew, > > On Sun, Mar 2, 2025 at 7:25 PM Andrew Lunn <andrew@lunn.ch> wrote: > > > > > + clock-names: > > > + items: > > > + - const: stmmaceth > > > + - const: pclk > > > + - const: ptp_ref > > > + - const: tx > > > + - const: rx > > > + - const: tx-180 > > > + - const: rx-180 > > > > As Russell said in an older thread, tx and tx-180 are effectively the > > same clock, but with an inverter added. You should be able to arrange > > the clock tree that if you enable tx, it also enables tx-180 as a > > parent/sibling relationship. > > > I can certainly do that, but not sure in the DT we will be describing > the HW correctly then. I'll have to hide *-180 clocks In the DT and > handle and turning on/off these clocks in the clock driver. ... > clocks = <&cpg CPG_MOD 0xbd>, > <&cpg CPG_MOD 0xbc>, > <&cpg CPG_CORE R9A09G057_GBETH_0_CLK_PTP_REF_I>, > <&cpg CPG_MOD 0xb8>, > <&cpg CPG_MOD 0xb9>, > <&cpg CPG_MOD 0xba>, > <&cpg CPG_MOD 0xbb>; Your SoC designer really implemented the 0° and 180° as two separate independently controllable clocks?
Hi Russell, On Sun, Mar 2, 2025 at 9:01 PM Russell King (Oracle) <linux@armlinux.org.uk> wrote: > > On Sun, Mar 02, 2025 at 08:41:39PM +0000, Lad, Prabhakar wrote: > > Hi Andrew, > > > > On Sun, Mar 2, 2025 at 7:25 PM Andrew Lunn <andrew@lunn.ch> wrote: > > > > > > > + clock-names: > > > > + items: > > > > + - const: stmmaceth > > > > + - const: pclk > > > > + - const: ptp_ref > > > > + - const: tx > > > > + - const: rx > > > > + - const: tx-180 > > > > + - const: rx-180 > > > > > > As Russell said in an older thread, tx and tx-180 are effectively the > > > same clock, but with an inverter added. You should be able to arrange > > > the clock tree that if you enable tx, it also enables tx-180 as a > > > parent/sibling relationship. > > > > > I can certainly do that, but not sure in the DT we will be describing > > the HW correctly then. I'll have to hide *-180 clocks In the DT and > > handle and turning on/off these clocks in the clock driver. > ... > > clocks = <&cpg CPG_MOD 0xbd>, > > <&cpg CPG_MOD 0xbc>, > > <&cpg CPG_CORE R9A09G057_GBETH_0_CLK_PTP_REF_I>, > > <&cpg CPG_MOD 0xb8>, > > <&cpg CPG_MOD 0xb9>, > > <&cpg CPG_MOD 0xba>, > > <&cpg CPG_MOD 0xbb>; > > Your SoC designer really implemented the 0° and 180° as two separate > independently controllable clocks? > Yes there are separate bits to turn ON/OFF the 0° and 180° clocks. Cheers, Prabhakar
On Sun, Mar 02, 2025 at 07:28:09PM +0000, Russell King (Oracle) wrote: > On Sun, Mar 02, 2025 at 08:10:26PM +0100, Andrew Lunn wrote: > > > + interrupts: > > > + items: > > > + - description: Subsystem interrupt > > > + - description: The interrupt to manage the remote wake-up packet detection > > > + - description: The interrupt that occurs when Tx/Rx enters/exits the LPI state > > > + - description: Per-channel transmission-0 completion interrupt > > > + - description: Per-channel transmission-1 completion interrupt > > > + - description: Per-channel transmission-2 completion interrupt > > > + - description: Per-channel transmission-3 completion interrupt > > > + - description: Per-channel receive-0 completion interrupt > > > + - description: Per-channel receive-1 completion interrupt > > > + - description: Per-channel receive-2 completion interrupt > > > + - description: Per-channel receive-3 completion interrupt > > > + > > > + interrupt-names: > > > + items: > > > + - const: macirq > > > + - const: eth_wake_irq > > > + - const: eth_lpi > > > + - const: tx0 > > > + - const: tx1 > > > + - const: tx2 > > > + - const: tx3 > > > + - const: rx0 > > > + - const: rx1 > > > + - const: rx2 > > > + - const: rx3 > > > > There has already been a discussion about trying to make the clock > > names more uniform. But what about interrupts? Which of these are in > > the IP databook? What names does the databook use for these > > interrupts? > > >From a quick look, I haven't found anything that suggests the above > is possible, but it clearly is... so I'll look more tomorrow. stmmac_platform.c: stmmac_res->irq = platform_get_irq_byname(pdev, "macirq"); stmmac_platform.c: platform_get_irq_byname_optional(pdev, "eth_wake_irq"); stmmac_platform.c: platform_get_irq_byname_optional(pdev, "eth_lpi"); stmmac_platform.c: platform_get_irq_byname_optional(pdev, "sfty"); So it looks like these are already in common code. So there should be no need to name them in individual bindings, they can be named in the common binding, and the vendor binding then just needs to indicate they are required, or not. What i have not yet figure out is how the names tx0, .. tx3 in this binding are used. There is no code added in this patchset. Yet loongson_dwmac_msi_config() and the intel stmmac_config_multi_msi() are the only ones setting res->tx_irq[], neither of which are using DT? I must be missing something somewhere. Andrew
> > > I can certainly do that, but not sure in the DT we will be describing > > > the HW correctly then. I'll have to hide *-180 clocks In the DT and > > > handle and turning on/off these clocks in the clock driver. > > ... > > > clocks = <&cpg CPG_MOD 0xbd>, > > > <&cpg CPG_MOD 0xbc>, > > > <&cpg CPG_CORE R9A09G057_GBETH_0_CLK_PTP_REF_I>, > > > <&cpg CPG_MOD 0xb8>, > > > <&cpg CPG_MOD 0xb9>, > > > <&cpg CPG_MOD 0xba>, > > > <&cpg CPG_MOD 0xbb>; > > > > Your SoC designer really implemented the 0° and 180° as two separate > > independently controllable clocks? > > > Yes there are separate bits to turn ON/OFF the 0° and 180° clocks. Do you know what the clock tree actually looks like? I can think of two different ways this could be implemented: ----+----------on/off--- | +----not---on/off--- or -------on/off-+------------------ | +---not---on/off--- In the first, the clocks are siblings. In the second there is parent/child relationship. Andrew
On Sun, Mar 2, 2025 at 9:39 PM Andrew Lunn <andrew@lunn.ch> wrote: > > > > > I can certainly do that, but not sure in the DT we will be describing > > > > the HW correctly then. I'll have to hide *-180 clocks In the DT and > > > > handle and turning on/off these clocks in the clock driver. > > > ... > > > > clocks = <&cpg CPG_MOD 0xbd>, > > > > <&cpg CPG_MOD 0xbc>, > > > > <&cpg CPG_CORE R9A09G057_GBETH_0_CLK_PTP_REF_I>, > > > > <&cpg CPG_MOD 0xb8>, > > > > <&cpg CPG_MOD 0xb9>, > > > > <&cpg CPG_MOD 0xba>, > > > > <&cpg CPG_MOD 0xbb>; > > > > > > Your SoC designer really implemented the 0° and 180° as two separate > > > independently controllable clocks? > > > > > Yes there are separate bits to turn ON/OFF the 0° and 180° clocks. > > Do you know what the clock tree actually looks like? I can think of > two different ways this could be implemented: > > ----+----------on/off--- > | > +----not---on/off--- > > or > > -------on/off-+------------------ > | > +---not---on/off--- > > In the first, the clocks are siblings. In the second there is > parent/child relationship. > It's the first case in this SoC. Cheers, Prabhakar
On Sun, Mar 02, 2025 at 09:43:47PM +0000, Lad, Prabhakar wrote: > On Sun, Mar 2, 2025 at 9:39 PM Andrew Lunn <andrew@lunn.ch> wrote: > > > > Your SoC designer really implemented the 0° and 180° as two separate > > > > independently controllable clocks? > > > > > > > Yes there are separate bits to turn ON/OFF the 0° and 180° clocks. > > > > Do you know what the clock tree actually looks like? I can think of > > two different ways this could be implemented: > > > > ----+----------on/off--- > > | > > +----not---on/off--- > > > > or > > > > -------on/off-+------------------ > > | > > +---not---on/off--- > > > > In the first, the clocks are siblings. In the second there is > > parent/child relationship. > > > It's the first case in this SoC. Umm, okay. I'll just pick my jaw up off the floor. :D Given that, then yes, go with your existing clock binding, because that's the most sensible. However, what would be useful for future maintenance is to put some commentry at the top of the new glue file describing this (pictorially) so that when someone looks at this later we know why it is this way. It'll be useful information if someone else does the same because then we can say "hey, we already have a binding for this situation!"
On Sun, Mar 02, 2025 at 09:49:55PM +0000, Russell King (Oracle) wrote: > On Sun, Mar 02, 2025 at 09:43:47PM +0000, Lad, Prabhakar wrote: > > On Sun, Mar 2, 2025 at 9:39 PM Andrew Lunn <andrew@lunn.ch> wrote: > > > > > Your SoC designer really implemented the 0° and 180° as two separate > > > > > independently controllable clocks? > > > > > > > > > Yes there are separate bits to turn ON/OFF the 0° and 180° clocks. > > > > > > Do you know what the clock tree actually looks like? I can think of > > > two different ways this could be implemented: > > > > > > ----+----------on/off--- > > > | > > > +----not---on/off--- > > > > > > or > > > > > > -------on/off-+------------------ > > > | > > > +---not---on/off--- > > > > > > In the first, the clocks are siblings. In the second there is > > > parent/child relationship. > > > > > It's the first case in this SoC. > > Umm, okay. I'll just pick my jaw up off the floor. :D > > Given that, then yes, go with your existing clock binding, because > that's the most sensible. > > However, what would be useful for future maintenance is to put some > commentry at the top of the new glue file describing this (pictorially) > so that when someone looks at this later we know why it is this way. > It'll be useful information if someone else does the same because then > we can say "hey, we already have a binding for this situation!" Additionally, it would probably be useful to include it in the dt binding commit description because that will probably assist the review of that patch.
On Sun, Mar 2, 2025 at 9:51 PM Russell King (Oracle) <linux@armlinux.org.uk> wrote: > > On Sun, Mar 02, 2025 at 09:49:55PM +0000, Russell King (Oracle) wrote: > > On Sun, Mar 02, 2025 at 09:43:47PM +0000, Lad, Prabhakar wrote: > > > On Sun, Mar 2, 2025 at 9:39 PM Andrew Lunn <andrew@lunn.ch> wrote: > > > > > > Your SoC designer really implemented the 0° and 180° as two separate > > > > > > independently controllable clocks? > > > > > > > > > > > Yes there are separate bits to turn ON/OFF the 0° and 180° clocks. > > > > > > > > Do you know what the clock tree actually looks like? I can think of > > > > two different ways this could be implemented: > > > > > > > > ----+----------on/off--- > > > > | > > > > +----not---on/off--- > > > > > > > > or > > > > > > > > -------on/off-+------------------ > > > > | > > > > +---not---on/off--- > > > > > > > > In the first, the clocks are siblings. In the second there is > > > > parent/child relationship. > > > > > > > It's the first case in this SoC. > > > > Umm, okay. I'll just pick my jaw up off the floor. :D > > > > Given that, then yes, go with your existing clock binding, because > > that's the most sensible. > > > > However, what would be useful for future maintenance is to put some > > commentry at the top of the new glue file describing this (pictorially) > > so that when someone looks at this later we know why it is this way. > > It'll be useful information if someone else does the same because then > > we can say "hey, we already have a binding for this situation!" > > Additionally, it would probably be useful to include it in the dt > binding commit description because that will probably assist the > review of that patch. > Sure will do that. Cheers, Prabhakar
On Sun, Mar 02, 2025 at 10:33:56PM +0100, Andrew Lunn wrote: > On Sun, Mar 02, 2025 at 07:28:09PM +0000, Russell King (Oracle) wrote: > > On Sun, Mar 02, 2025 at 08:10:26PM +0100, Andrew Lunn wrote: > > > > + interrupts: > > > > + items: > > > > + - description: Subsystem interrupt > > > > + - description: The interrupt to manage the remote wake-up packet detection > > > > + - description: The interrupt that occurs when Tx/Rx enters/exits the LPI state > > > > + - description: Per-channel transmission-0 completion interrupt > > > > + - description: Per-channel transmission-1 completion interrupt > > > > + - description: Per-channel transmission-2 completion interrupt > > > > + - description: Per-channel transmission-3 completion interrupt > > > > + - description: Per-channel receive-0 completion interrupt > > > > + - description: Per-channel receive-1 completion interrupt > > > > + - description: Per-channel receive-2 completion interrupt > > > > + - description: Per-channel receive-3 completion interrupt > > > > + > > > > + interrupt-names: > > > > + items: > > > > + - const: macirq > > > > + - const: eth_wake_irq > > > > + - const: eth_lpi > > > > + - const: tx0 > > > > + - const: tx1 > > > > + - const: tx2 > > > > + - const: tx3 > > > > + - const: rx0 > > > > + - const: rx1 > > > > + - const: rx2 > > > > + - const: rx3 > > > > > > There has already been a discussion about trying to make the clock > > > names more uniform. But what about interrupts? Which of these are in > > > the IP databook? What names does the databook use for these > > > interrupts? > > > > >From a quick look, I haven't found anything that suggests the above > > is possible, but it clearly is... so I'll look more tomorrow. > > stmmac_platform.c: stmmac_res->irq = platform_get_irq_byname(pdev, "macirq"); > stmmac_platform.c: platform_get_irq_byname_optional(pdev, "eth_wake_irq"); > stmmac_platform.c: platform_get_irq_byname_optional(pdev, "eth_lpi"); > stmmac_platform.c: platform_get_irq_byname_optional(pdev, "sfty"); > > So it looks like these are already in common code. So there should be > no need to name them in individual bindings, they can be named in the > common binding, and the vendor binding then just needs to indicate > they are required, or not. The vendor bindings need to define the order. And to define if they are required, you have to list the names again... Rob
diff --git a/Documentation/devicetree/bindings/net/renesas,r9a09g057-gbeth.yaml b/Documentation/devicetree/bindings/net/renesas,r9a09g057-gbeth.yaml new file mode 100644 index 000000000000..dc23e7f401cc --- /dev/null +++ b/Documentation/devicetree/bindings/net/renesas,r9a09g057-gbeth.yaml @@ -0,0 +1,212 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/net/renesas,r9a09g057-gbeth.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: GBETH glue layer for Renesas RZ/V2H(P) (and similar SoCs) + +maintainers: + - Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com> + +select: + properties: + compatible: + contains: + enum: + - renesas,r9a09g057-gbeth + - renesas,rzv2h-gbeth + required: + - compatible + +properties: + compatible: + items: + - enum: + - renesas,r9a09g057-gbeth # RZ/V2H(P) + - const: renesas,rzv2h-gbeth + - const: snps,dwmac-5.20 + + reg: + maxItems: 1 + + clocks: + items: + - description: CSR clock + - description: AXI system clock + - description: PTP clock + - description: TX clock + - description: RX clock + - description: TX clock phase-shifted by 180 degrees + - description: RX clock phase-shifted by 180 degrees + + clock-names: + items: + - const: stmmaceth + - const: pclk + - const: ptp_ref + - const: tx + - const: rx + - const: tx-180 + - const: rx-180 + + interrupts: + items: + - description: Subsystem interrupt + - description: The interrupt to manage the remote wake-up packet detection + - description: The interrupt that occurs when Tx/Rx enters/exits the LPI state + - description: Per-channel transmission-0 completion interrupt + - description: Per-channel transmission-1 completion interrupt + - description: Per-channel transmission-2 completion interrupt + - description: Per-channel transmission-3 completion interrupt + - description: Per-channel receive-0 completion interrupt + - description: Per-channel receive-1 completion interrupt + - description: Per-channel receive-2 completion interrupt + - description: Per-channel receive-3 completion interrupt + + interrupt-names: + items: + - const: macirq + - const: eth_wake_irq + - const: eth_lpi + - const: tx0 + - const: tx1 + - const: tx2 + - const: tx3 + - const: rx0 + - const: rx1 + - const: rx2 + - const: rx3 + + resets: + items: + - description: AXI power-on system reset + +required: + - compatible + - reg + - clocks + - clock-names + - interrupts + - interrupt-names + - resets + +allOf: + - $ref: snps,dwmac.yaml# + +unevaluatedProperties: false + +examples: + - | + #include <dt-bindings/clock/renesas-cpg-mssr.h> + #include <dt-bindings/interrupt-controller/arm-gic.h> + + ethernet@15c30000 { + compatible = "renesas,r9a09g057-gbeth", "renesas,rzv2h-gbeth", "snps,dwmac-5.20"; + reg = <0x15c30000 0x10000>; + clocks = <&cpg CPG_MOD 0xbd>, <&cpg CPG_MOD 0xbc>, + <&ptp_clock>, <&cpg CPG_MOD 0xb8>, + <&cpg CPG_MOD 0xb9>, <&cpg CPG_MOD 0xba>, + <&cpg CPG_MOD 0xbb>; + clock-names = "stmmaceth", "pclk", "ptp_ref", + "tx", "rx", "tx-180", "rx-180"; + resets = <&cpg 0xb0>; + interrupts = <GIC_SPI 765 IRQ_TYPE_LEVEL_HIGH>, + <GIC_SPI 767 IRQ_TYPE_LEVEL_HIGH>, + <GIC_SPI 766 IRQ_TYPE_LEVEL_HIGH>, + <GIC_SPI 768 IRQ_TYPE_LEVEL_HIGH>, + <GIC_SPI 769 IRQ_TYPE_LEVEL_HIGH>, + <GIC_SPI 770 IRQ_TYPE_LEVEL_HIGH>, + <GIC_SPI 771 IRQ_TYPE_LEVEL_HIGH>, + <GIC_SPI 772 IRQ_TYPE_LEVEL_HIGH>, + <GIC_SPI 773 IRQ_TYPE_LEVEL_HIGH>, + <GIC_SPI 774 IRQ_TYPE_LEVEL_HIGH>, + <GIC_SPI 745 IRQ_TYPE_LEVEL_HIGH>; + interrupt-names = "macirq", "eth_wake_irq", "eth_lpi", + "tx0", "tx1", "tx2", "tx3", + "rx0", "rx1", "rx2", "rx3"; + phy-mode = "rgmii-id"; + snps,multicast-filter-bins = <256>; + snps,perfect-filter-entries = <128>; + rx-fifo-depth = <8192>; + tx-fifo-depth = <8192>; + snps,fixed-burst; + snps,force_thresh_dma_mode; + snps,axi-config = <&stmmac_axi_setup>; + snps,mtl-rx-config = <&mtl_rx_setup>; + snps,mtl-tx-config = <&mtl_tx_setup>; + snps,en-tx-lpi-clockgating; + snps,txpbl = <32>; + snps,rxpbl = <32>; + phy-handle = <&phy0>; + + stmmac_axi_setup: stmmac-axi-config { + snps,lpi_en; + snps,wr_osr_lmt = <0xf>; + snps,rd_osr_lmt = <0xf>; + snps,blen = <16 8 4 0 0 0 0>; + }; + + mtl_rx_setup: rx-queues-config { + snps,rx-queues-to-use = <4>; + snps,rx-sched-sp; + + queue0 { + snps,dcb-algorithm; + snps,priority = <0x1>; + snps,map-to-dma-channel = <0>; + }; + + queue1 { + snps,dcb-algorithm; + snps,priority = <0x2>; + snps,map-to-dma-channel = <1>; + }; + + queue2 { + snps,dcb-algorithm; + snps,priority = <0x4>; + snps,map-to-dma-channel = <2>; + }; + + queue3 { + snps,dcb-algorithm; + snps,priority = <0x8>; + snps,map-to-dma-channel = <3>; + }; + }; + + mtl_tx_setup: tx-queues-config { + snps,tx-queues-to-use = <4>; + + queue0 { + snps,dcb-algorithm; + snps,priority = <0x1>; + }; + + queue1 { + snps,dcb-algorithm; + snps,priority = <0x2>; + }; + + queue2 { + snps,dcb-algorithm; + snps,priority = <0x4>; + }; + + queue3 { + snps,dcb-algorithm; + snps,priority = <0x1>; + }; + }; + + mdio { + #address-cells = <1>; + #size-cells = <0>; + compatible = "snps,dwmac-mdio"; + + phy0: ethernet-phy@0 { + reg = <0>; + }; + }; + }; diff --git a/Documentation/devicetree/bindings/net/snps,dwmac.yaml b/Documentation/devicetree/bindings/net/snps,dwmac.yaml index 85d499bd49b5..b5ae3da327bd 100644 --- a/Documentation/devicetree/bindings/net/snps,dwmac.yaml +++ b/Documentation/devicetree/bindings/net/snps,dwmac.yaml @@ -74,6 +74,7 @@ properties: - qcom,sm8150-ethqos - renesas,r9a06g032-gmac - renesas,rzn1-gmac + - renesas,rzv2h-gbeth - rockchip,px30-gmac - rockchip,rk3128-gmac - rockchip,rk3228-gmac