Re: [PATCH v7 4/7] reset: rzg2l-usbphy-ctrl: Add support for USB PWRRDY

[Philipp Zabel <p.zabel@pengutronix.de>]

Hi Claudiu,

On Fr, 2025-10-10 at 14:26 +0300, Claudiu Beznea wrote:
> Hi, Philipp,
> 
> On 10/8/25 15:16, Claudiu Beznea wrote:
> > Hi, Philipp,
> > 
> > On 10/8/25 13:23, Philipp Zabel wrote:
> > > Hi Claudiu,
> > > 
> > > On Mi, 2025-10-08 at 12:29 +0300, Claudiu Beznea wrote:
> > > > Hi, Philipp,
> > > > 
> > > > On 10/8/25 11:34, Philipp Zabel wrote:
> > > > > Hi Claudiu,
> > > > > 
> > > > > On Do, 2025-09-25 at 13:02 +0300, Claudiu wrote:
> > > > > > From: Claudiu Beznea <claudiu.beznea.uj@bp.renesas.com>
> > > > > > 
> > > > > > On the Renesas RZ/G3S SoC, the USB PHY block has an input signal called
> > > > > > PWRRDY. This signal is managed by the system controller and must be
> > > > > > de-asserted after powering on the area where USB PHY resides and asserted
> > > > > > before powering it off.
> > > > > > 
> > > > > > On power-on the USB PWRRDY signal need to be de-asserted before enabling
> > > > > > clock and switching the module to normal state (through MSTOP support). The
> > > > > > power-on configuration sequence
> > > > > The wording makes me wonder, have you considered implementing this as a
> > > > > power sequencing driver?
> > > > No, haven't tried as power sequencing. At the moment this was started I
> > > > think the power sequencing support wasn't merged.
> > > > 
> > > > The approaches considered were:
> > > > a/ power domain
> > > Letting a power domain control a corresponding power ready signal would
> > > have been my first instinct as well.
> > > 
> > > > b/ regulator
> > > > c/ as a reference counted bit done through regmap read/writes APIs
> > > > 
> > > > a and b failed as a result of discussions in the previous posted versions.
> > > Could you point me to the discussion related to a?
> > It's this one
> > https://lore.kernel.org/all/
> > CAPDyKFrS4Dhd7DZa2zz=oPro1TiTJFix0awzzzp8Qatm-8Z2Ug@mail.gmail.com/

Thank you! From this discussion it still isn't clear to me whether
Ulf's suggestion of using genpd on/off notifiers was considered and why
it was dismissed.

From the DT patches it looks like there is no actual separate power
domain for USB, just the single always-on CPG power domain (in rzg2l-
cpg.c). Is that correct? In the thread it sounded like there were
multiple domains.

Is the issue that you need the PWRRDY signal to be (de)asserted
independently from the CPG power domain enable/disable? (Why?)

Why can't the power domain provider (cpg) have the renesas,sysc-pwrrdy
property and set the signal together with the power domain?

> > > I see v2 and v3 tried to control the bit from the PHY drivers, and in
> > > v4 we were are already back to the reset driver.
> > v2 passed the system controller (SYSC) phandle to the USB PHYs only (though
> > renesas,sysc-signals DT property) where the PWRRDY bit was set. The PWRRDY
> > bit was referenced counted in the SYSC driver though regmap APIs.
> > 
> > v3 used the approach from v2 but passed the renesas,sysc-signals to all the
> > USB related drivers.
> > 
> > Then, in v4, the PWRRDY refcounting was dropped and passed
> > renesas,sysc-signals only to the USB PHY CTRL DT node in the idea that this
> > is the node that will always be probed first as all the other USB blocks
> > need it and request resets from it.
> > 
> > v5 and v6 kept the approach from v4 and only addressed misc comments or
> > things that I noticed.
> 
> Could you please let me know if you are OK with the approach proposed in
> v7, so that I can start preparing a new version addressing your comments?

If the PWRRDY signal is an input to the USB2PHY control block, and not
only to the PHY blocks, I have no issue with this being handled in the
usb2phy reset driver - iff it is not sensible to just control the
signal from the power domain driver.

If we have to handle it in the reset driver, I'd prefer to see this
controlled with a dev_pm_genpd_add_notifier(). If that is not possible,
I'd like to understand why.

regards
Philipp

-- 
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy