[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <08fbb2fc1a2e581010b6b28cd1a544053a4f1fb0.camel@pengutronix.de>
Date: Wed, 22 Oct 2025 11:38:16 +0200
From: Philipp Zabel <p.zabel@...gutronix.de>
To: Claudiu Beznea <claudiu.beznea@...on.dev>, vkoul@...nel.org,
kishon@...nel.org, robh@...nel.org, krzk+dt@...nel.org,
conor+dt@...nel.org, geert+renesas@...der.be, magnus.damm@...il.com,
yoshihiro.shimoda.uh@...esas.com, biju.das.jz@...renesas.com
Cc: linux-phy@...ts.infradead.org, devicetree@...r.kernel.org,
linux-kernel@...r.kernel.org, linux-renesas-soc@...r.kernel.org, Claudiu
Beznea <claudiu.beznea.uj@...renesas.com>, Wolfram Sang
<wsa+renesas@...g-engineering.com>
Subject: Re: [PATCH v7 4/7] reset: rzg2l-usbphy-ctrl: Add support for USB
PWRRDY
Hi Claudiu,
On Di, 2025-10-21 at 11:48 +0300, Claudiu Beznea wrote:
> Hi, Philipp,
>
> On 10/15/25 11:19, Claudiu Beznea wrote:
> > > > > > > > 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 -
> > > > Yes, this is how the Renesas HW team confirmed they are related.
> > > Ok, understood. I concur that usb2phy-ctrl is the right place for the
> > > sysc property then.
> > >
> > > > > iff it is not sensible to just control the
> > > > > signal from the power domain driver.
> > > > As mentioned above, that can be done as well but, passing a SYSC phandle to
> > > > the CPG DT node will not be valid from the HW description point of view.
> > > >
> > > > > 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.
> > > > From the code inspection I did, that can be done. From what I can tell at
> > > > the moment, I'll have to register a gepnd notifier from
> > > > reset-rzg2l-usbphy-ctrl, before runtime resuming the device and control the
> > > > SYSC PWRRDY from it.
> > > I'd like that.
> > Now, that we found the genpd notifier is not a solution, could you please
> > let me know how would you like me to proceed?
>
> After discussing all the possible (known) solutions, could you please let
> me know if you are OK with the approach in this series?
Yes, I don't have a better idea. Let's revisit the issue of ordering
guarantees when suspend/resume is implemented.
regards
Philipp
Powered by blists - more mailing lists