| Message ID | 20241126092050.1825607-2-claudiu.beznea.uj@bp.renesas.com (mailing list archive) |
|---|---|
| State | New |
| Headers | show |
| Series | Add initial USB support for the Renesas RZ/G3S SoC | expand |
Hi Claudiu, CC Ulf Thanks for your patch! On Tue, Nov 26, 2024 at 10:21 AM Claudiu <claudiu.beznea@tuxon.dev> wrote: > From: Claudiu Beznea <claudiu.beznea.uj@bp.renesas.com> > > The RZ/G3S system controller (SYSC) has registers to control signals that > are routed to various IPs. These signals must be controlled during > configuration of the respective IPs. One such signal is the USB PWRRDY, > which connects the SYSC and the USB PHY. This signal must to be controlled > before and after the power to the USB PHY is turned off/on. > > Other similar signals include the following (according to the RZ/G3S > hardware manual): > > * PCIe: > - ALLOW_ENTER_L1 signal controlled through the SYS_PCIE_CFG register > - PCIE_RST_RSM_B signal controlled through the SYS_PCIE_RST_RSM_B > register > - MODE_RXTERMINATION signal controlled through SYS_PCIE_PHY register > > * SPI: > - SEL_SPI_OCTA signal controlled through SYS_IPCONT_SEL_SPI_OCTA > register > > * I2C/I3C: > - af_bypass I2C signals controlled through SYS_I2Cx_CFG registers > (x=0..3) > - af_bypass I3C signal controlled through SYS_I3C_CFG register > > * Ethernet: > - FEC_GIGA_ENABLE Ethernet signals controlled through SYS_GETHx_CFG > registers (x=0..1) > > Add #renesas,sysc-signal-cells DT property to allow different SYSC signals > consumers to manage these signals. > > The goal is to enable consumers to specify the required access data for > these signals (through device tree) and let their respective drivers > control these signals via the syscon regmap provided by the system > controller driver. For example, the USB PHY will describe this relation > using the following DT property: > > usb2_phy1: usb-phy@11e30200 { > // ... > renesas,sysc-signal = <&sysc 0xd70 0x1>; > // ... > }; IIUIC, the consumer driver will appear to control the SYSC bits directly, but due to the use of custom validating regmap accessors and reference counting in the SYSC driver, this is safe? The extra safety requires duplicating the register bits in both DT and the SYSC driver. Both usb-phy nodes on RZG3S use the same renesas,sysc-signal, so the reference counting is indeed needed. They are in different power domains, could that be an issue w.r.t. ordering? I am not a big fan of describing register bits in DT, but for the other SYSC users you list above, syscon+regmap seems to be a valid solution. For USB and PCIe control, the situation is different. I more liked the approach with "reset IDs" you had in v1, as it abstracts the DT description from the register bits, and the USB and PCIe reset bits use a different polarity (on RZ/G3S). If future SoC integration changes the polarity, you have to handle that in the consumer (USB or PCIe) driver, too. Unfortunately such "reset IDs" are only suitable for use with the reset or pmdomain frameworks, which didn't survive the earlier discussions. One other option would be to let SYSC expose regulators? While that would work for USB and PCIe control, we would still need syscon+regmap for the other bits. So the more I think about it, the more I like your (clever) solution... > Along with it, add the syscon to the compatible list as it will be > requested by the consumer drivers. The syscon was added to the rest of > system controller variants as these are similar with RZ/G3S and can > benefit from the implementation proposed in this series. > > Signed-off-by: Claudiu Beznea <claudiu.beznea.uj@bp.renesas.com> Gr{oetje,eeting}s, Geert -- Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org In personal conversations with technical people, I call myself a hacker. But when I'm talking to journalists I just say "programmer" or something like that. -- Linus Torvalds
Hi, Geert, On 28.11.2024 17:46, Geert Uytterhoeven wrote: > Hi Claudiu, > > CC Ulf > > Thanks for your patch! > > On Tue, Nov 26, 2024 at 10:21 AM Claudiu <claudiu.beznea@tuxon.dev> wrote: >> From: Claudiu Beznea <claudiu.beznea.uj@bp.renesas.com> >> >> The RZ/G3S system controller (SYSC) has registers to control signals that >> are routed to various IPs. These signals must be controlled during >> configuration of the respective IPs. One such signal is the USB PWRRDY, >> which connects the SYSC and the USB PHY. This signal must to be controlled >> before and after the power to the USB PHY is turned off/on. >> >> Other similar signals include the following (according to the RZ/G3S >> hardware manual): >> >> * PCIe: >> - ALLOW_ENTER_L1 signal controlled through the SYS_PCIE_CFG register >> - PCIE_RST_RSM_B signal controlled through the SYS_PCIE_RST_RSM_B >> register >> - MODE_RXTERMINATION signal controlled through SYS_PCIE_PHY register >> >> * SPI: >> - SEL_SPI_OCTA signal controlled through SYS_IPCONT_SEL_SPI_OCTA >> register >> >> * I2C/I3C: >> - af_bypass I2C signals controlled through SYS_I2Cx_CFG registers >> (x=0..3) >> - af_bypass I3C signal controlled through SYS_I3C_CFG register >> >> * Ethernet: >> - FEC_GIGA_ENABLE Ethernet signals controlled through SYS_GETHx_CFG >> registers (x=0..1) >> >> Add #renesas,sysc-signal-cells DT property to allow different SYSC signals >> consumers to manage these signals. >> >> The goal is to enable consumers to specify the required access data for >> these signals (through device tree) and let their respective drivers >> control these signals via the syscon regmap provided by the system >> controller driver. For example, the USB PHY will describe this relation >> using the following DT property: >> >> usb2_phy1: usb-phy@11e30200 { >> // ... >> renesas,sysc-signal = <&sysc 0xd70 0x1>; >> // ... >> }; > > IIUIC, the consumer driver will appear to control the SYSC bits > directly, but due to the use of custom validating regmap accessors > and reference counting in the SYSC driver, this is safe? I'm not sure I fully understand the safety concern. > The extra safety requires duplicating the register bits in both DT > and the SYSC driver. One other option I saw was to have common defines for registers that could have been shared b/w driver and DTSes. But it looked better to me the way it has been presented in this series. > Both usb-phy nodes on RZG3S use the same renesas,sysc-signal, so the > reference counting is indeed needed. They are in different power > domains, could that be an issue w.r.t. ordering? In chapter "32.4.2.1 USB/PHY related pins", section "When either Port1 or Port2 is unused" of the RZ/G3S HW manual it is mentioned "Since USB_VDD18 / USB_VDD33 are common to 2 Port PHY, it is necessary to supply power even when one of the ports is not in use". (From the discussions w/ the internal HW team) The PWRRDY is an (software controlled) indicator to the USB PHY that power supply is ready. From that and [1] I get that both PHYs are powered by the same regulators (USB_VDD18/USB_VDD33) and the USB PWRRDY signal need to be set before/after the USB PHY power off/on. Because of this I consider the order doesn't matter. [1] https://gcdnb.pbrd.co/images/0a1zYBFZXZVb.png > > I am not a big fan of describing register bits in DT, +1 > but for the other > SYSC users you list above, syscon+regmap seems to be a valid solution. > For USB and PCIe control, the situation is different. I more liked the > approach with "reset IDs" you had in v1, as it abstracts the DT > description from the register bits, +1 > and the USB and PCIe reset bits use > a different polarity (on RZ/G3S). If future SoC integration changes > the polarity, you have to handle that in the consumer (USB or PCIe) > driver, too. That's true. The idea of this implementation was that the consumer would know what they need to set for themselves on the SYSC side. > Unfortunately such "reset IDs" are only suitable for > use with the reset or pmdomain frameworks, which didn't survive the > earlier discussions. > > One other option would be to let SYSC expose regulators? We can try, but we can hit the wall again, as the PWRRDY signal is not a regulator either. From the internal HW discussion is an indicator (software controlled) that the power to the USB PHY is ready. > While that would work for USB and PCIe control, we would still need > syscon+regmap for the other bits. That is true. > > So the more I think about it, the more I like your (clever) solution... > >> Along with it, add the syscon to the compatible list as it will be >> requested by the consumer drivers. The syscon was added to the rest of >> system controller variants as these are similar with RZ/G3S and can >> benefit from the implementation proposed in this series. >> >> Signed-off-by: Claudiu Beznea <claudiu.beznea.uj@bp.renesas.com> > > Gr{oetje,eeting}s, > > Geert > > -- > Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org > > In personal conversations with technical people, I call myself a hacker. But > when I'm talking to journalists I just say "programmer" or something like that. > -- Linus Torvalds
Hi Claudiu, On Fri, Nov 29, 2024 at 9:21 AM Claudiu Beznea <claudiu.beznea@tuxon.dev> wrote: > On 28.11.2024 17:46, Geert Uytterhoeven wrote: > > On Tue, Nov 26, 2024 at 10:21 AM Claudiu <claudiu.beznea@tuxon.dev> wrote: > >> From: Claudiu Beznea <claudiu.beznea.uj@bp.renesas.com> > >> > >> The RZ/G3S system controller (SYSC) has registers to control signals that > >> are routed to various IPs. These signals must be controlled during > >> configuration of the respective IPs. One such signal is the USB PWRRDY, > >> which connects the SYSC and the USB PHY. This signal must to be controlled > >> before and after the power to the USB PHY is turned off/on. > >> > >> Other similar signals include the following (according to the RZ/G3S > >> hardware manual): > >> > >> * PCIe: > >> - ALLOW_ENTER_L1 signal controlled through the SYS_PCIE_CFG register > >> - PCIE_RST_RSM_B signal controlled through the SYS_PCIE_RST_RSM_B > >> register > >> - MODE_RXTERMINATION signal controlled through SYS_PCIE_PHY register > >> > >> * SPI: > >> - SEL_SPI_OCTA signal controlled through SYS_IPCONT_SEL_SPI_OCTA > >> register > >> > >> * I2C/I3C: > >> - af_bypass I2C signals controlled through SYS_I2Cx_CFG registers > >> (x=0..3) > >> - af_bypass I3C signal controlled through SYS_I3C_CFG register > >> > >> * Ethernet: > >> - FEC_GIGA_ENABLE Ethernet signals controlled through SYS_GETHx_CFG > >> registers (x=0..1) > >> > >> Add #renesas,sysc-signal-cells DT property to allow different SYSC signals > >> consumers to manage these signals. > >> > >> The goal is to enable consumers to specify the required access data for > >> these signals (through device tree) and let their respective drivers > >> control these signals via the syscon regmap provided by the system > >> controller driver. For example, the USB PHY will describe this relation > >> using the following DT property: > >> > >> usb2_phy1: usb-phy@11e30200 { > >> // ... > >> renesas,sysc-signal = <&sysc 0xd70 0x1>; > >> // ... > >> }; > > > > IIUIC, the consumer driver will appear to control the SYSC bits > > directly, but due to the use of custom validating regmap accessors > > and reference counting in the SYSC driver, this is safe? > > I'm not sure I fully understand the safety concern. Sorry for my bad expression, this was more like a rhetorical question. I meant that it is safe because: 1. Consumers cannot perform arbitrary register accesses, 2. The reference counting guarantees correct operation, despite both usb-phy nodes using the same renesas,sysc-signal. So everything is fine. > > The extra safety requires duplicating the register bits in both DT > > and the SYSC driver. > > One other option I saw was to have common defines for registers that could > have been shared b/w driver and DTSes. But it looked better to me the way > it has been presented in this series. > > > Both usb-phy nodes on RZG3S use the same renesas,sysc-signal, so the > > reference counting is indeed needed. They are in different power > > domains, could that be an issue w.r.t. ordering? > > In chapter "32.4.2.1 USB/PHY related pins", section "When either Port1 or > Port2 is unused" of the RZ/G3S HW manual it is mentioned "Since USB_VDD18 / > USB_VDD33 are common to 2 Port PHY, it is necessary to supply power even > when one of the > ports is not in use". Does that mean you have to power the other PHY on through the CPG_BUS_PERI_COM_MSTOP register, too? (I know you haven't added R9A08G045_PD_USBx to the USB nodes yet, as #power-domain-cells is still 0). > (From the discussions w/ the internal HW team) The PWRRDY is an (software > controlled) indicator to the USB PHY that power supply is ready. > > From that and [1] I get that both PHYs are powered by the same regulators > (USB_VDD18/USB_VDD33) and the USB PWRRDY signal need to be set before/after > the USB PHY power off/on. Because of this I consider the order doesn't matter. > > [1] https://gcdnb.pbrd.co/images/0a1zYBFZXZVb.png Gr{oetje,eeting}s, Geert
diff --git a/Documentation/devicetree/bindings/soc/renesas/renesas,rzg2l-sysc.yaml b/Documentation/devicetree/bindings/soc/renesas/renesas,rzg2l-sysc.yaml index 4386b2c3fa4d..90f827e8de3e 100644 --- a/Documentation/devicetree/bindings/soc/renesas/renesas,rzg2l-sysc.yaml +++ b/Documentation/devicetree/bindings/soc/renesas/renesas,rzg2l-sysc.yaml @@ -19,11 +19,13 @@ description: properties: compatible: - enum: - - renesas,r9a07g043-sysc # RZ/G2UL and RZ/Five - - renesas,r9a07g044-sysc # RZ/G2{L,LC} - - renesas,r9a07g054-sysc # RZ/V2L - - renesas,r9a08g045-sysc # RZ/G3S + items: + - enum: + - renesas,r9a07g043-sysc # RZ/G2UL and RZ/Five + - renesas,r9a07g044-sysc # RZ/G2{L,LC} + - renesas,r9a07g054-sysc # RZ/V2L + - renesas,r9a08g045-sysc # RZ/G3S + - const: syscon reg: maxItems: 1 @@ -42,9 +44,17 @@ properties: - const: cm33stbyr_int - const: ca55_deny + "#renesas,sysc-signal-cells": + description: + The number of cells needed to configure a SYSC controlled signal. First + cell specifies the SYSC offset of the configuration register, second cell + specifies the bitmask in register. + const: 2 + required: - compatible - reg + - "#renesas,sysc-signal-cells" additionalProperties: false @@ -53,7 +63,7 @@ examples: #include <dt-bindings/interrupt-controller/arm-gic.h> sysc: system-controller@11020000 { - compatible = "renesas,r9a07g044-sysc"; + compatible = "renesas,r9a07g044-sysc", "syscon"; reg = <0x11020000 0x10000>; interrupts = <GIC_SPI 42 IRQ_TYPE_LEVEL_HIGH>, <GIC_SPI 43 IRQ_TYPE_LEVEL_HIGH>, @@ -61,4 +71,5 @@ examples: <GIC_SPI 45 IRQ_TYPE_LEVEL_HIGH>; interrupt-names = "lpm_int", "ca55stbydone_int", "cm33stbyr_int", "ca55_deny"; + #renesas,sysc-signal-cells = <2>; };