On Tue, 3 Sept 2024 at 12:58, claudiu beznea <claudiu.beznea@xxxxxxxxx> wrote: > > > > On 03.09.2024 13:35, Ulf Hansson wrote: > > On Sat, 31 Aug 2024 at 12:32, Ulf Hansson <ulf.hansson@xxxxxxxxxx> wrote: > >> > >> [...] > >> > >>>> > >>>> If not, there are two other options that can be considered I think. > >>>> *) Using the genpd on/off notifiers, to really allow the consumer > >>>> driver of the reset-control to know when the PM domain gets turned > >>>> on/off. > >>>> **) Move the entire reset handling into the PM domain provider, as it > >>>> obviously knows when the domain is getting turned on/off. > >>> > >>> This option is what I've explored, tested on my side. > >>> > >>> I explored it in 2 ways: > >>> > >>> 1/ SYSC modeled as an individual PM domain provider (this is more > >>> appropriate to how HW manual described the hardware) with this the PHY > >>> reset DT node would have to get 2 PM domains handlers (one for the > >>> current PM domain provider and the other one for SYSC): > >>> > >>> + phyrst: usbphy-ctrl@11e00000 { > >>> + compatible = "renesas,r9a08g045-usbphy-ctrl"; > >>> + reg = <0 0x11e00000 0 0x10000>; > >>> + clocks = <&cpg CPG_MOD R9A08G045_USB_PCLK>; > >>> + resets = <&cpg R9A08G045_USB_PRESETN>; > >>> + power-domain-names = "cpg", "sysc"; > >>> + power-domains = <&cpg R9A08G045_PD_USB_PHY>, <&sysc > >>> R9A08G045_SYSC_PD_USB>; > >>> + #reset-cells = <1>; > >>> + status = "disabled"; > >>> + > >>> + usb0_vbus_otg: regulator-vbus { > >>> + regulator-name = "vbus"; > >>> + }; > >>> + }; > >>> + > >> > >> According to what you have described earlier/above, modelling the SYSC > >> as a PM domain provider seems like a better description of the HW to > >> me. Although, as I said earlier, if you prefer the reset approach, I > >> would not object to that. > > > > Following the discussion I believe I should take this back. If I > > understand correctly, SYSC signal seems best to be modelled as a > > reset. > > > > Although, it looks like the USB PM domain provider should rather be > > the consumer of that reset, instead of having the reset being consumed > > by the consumers of the USB PM domain. > > The PM domain provider for USB is the provider for the rest of IPs. To work > like this the SYSC these signals should be handled in the USB domains power > on/off function. It's not impossible to have it implemented like this but > it will complicate a bit the code, AFAICT. This will not describe the > hardware, also. > > With the information that we had up to yesterday, the connection b/w HW > blocks was something as follows: > > USB area > +--------------------------+ > sig | PHY -> USB controller X | > SYSC -------->| ^ | > | | | > | PHY reset | > +--------------------------+ > > In this implementation the SYSC signal was connected to PHY reset block as > it is the root of the devices used in the USB setup and no USB > functionality can exist w/o the PHY reset being setup. > > There is a new information arrived just yesterday from hardware team saying > this about SYSC signals: "When turning off USB PHY and PCIe PHY, if they > are not controlled, PHY may break" which may means that it is just > connected to the PHYs not to the USB area/region or PCIe area/region as > initially expressed in HW manual. > > With that the HW connection b/w the USB devices and SYSC might become > something like: > > USB area > +--------------------------+ > sig +--->PHY -> USB controller X | > SYSC ------+ | ^ | > | | | > | PHY reset | > +--------------------------+ > > I haven't got the chance to test this topology, though. > > With this new information would you be OK to still have it as a reset > signal and connected only to the PHY driver ? As long as it's a better description of the HW, I am fine with that too. Although, please note that pm_runtime_get|put() doesn't give you full controll of how the USB PM domain is being powered. So in that case, it sounds like you need to use the genpd on/off notifiers too. Kind regards Uffe