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
