From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id E4B75CCD18E for ; Tue, 14 Oct 2025 08:36:35 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender: Content-Transfer-Encoding:Content-Type:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:In-Reply-To:From:References:Cc:To: Subject:MIME-Version:Date:Message-ID:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=85S98jAKqPQkzFUcG3nWM+yh2lGDDaVXLEoy49KATjo=; b=mqgtFn5bFGoQRy PlVRjgzPuVoymEGTmi+5BCzsUWp5/B0k3ODhwdfIUimfoWRe9+Il67zQnOqnUM+pCLzOwlh3mVWbB mS13B7yWxO6fuH/DHBEUkBQyXCw4eQ7m5NFrbOw9agURyA2Ze+UdN8MJipCn47wNw8h/FLcImnmLQ C0UohYEDmrumN08UfS7HjfTXVJ21t/58rYhDe1I5oWUfn/QZd2qkzq1d2vlnPX0MP6RXe36oMTZzg V7bYkCWsurSmDk7FmHcGnzWJFPX6JvW9bF7TGTAsZsFcpM5EgpnMe+fk+F4Nh/FKwPt08JkuqGJ1Z 4slIN8SxhwpHrPZrQywQ==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.98.2 #2 (Red Hat Linux)) id 1v8aWJ-0000000FdbA-2KZK; Tue, 14 Oct 2025 08:36:35 +0000 Received: from mail-wm1-x32f.google.com ([2a00:1450:4864:20::32f]) by bombadil.infradead.org with esmtps (Exim 4.98.2 #2 (Red Hat Linux)) id 1v8aWH-0000000FdaH-04uv for linux-phy@lists.infradead.org; Tue, 14 Oct 2025 08:36:34 +0000 Received: by mail-wm1-x32f.google.com with SMTP id 5b1f17b1804b1-46e5980471eso27081525e9.2 for ; Tue, 14 Oct 2025 01:36:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tuxon.dev; s=google; t=1760430990; x=1761035790; darn=lists.infradead.org; h=content-transfer-encoding:in-reply-to:content-language:from :references:cc:to:subject:user-agent:mime-version:date:message-id :from:to:cc:subject:date:message-id:reply-to; bh=PlCr4KtCOqjtwAQHsCr8GzfdPPkJghN91drUl4fH4VI=; b=C1NlwP6XID+eEhaYs/ZGIy8/rkMkC6EV6jpx5ighZ3IsYYS79+mTvqCSf+r9A0ZMRN yVhyfxwkBB+7zOUrXdueprZh3K7ASNgLaI01Avy45aUJ6uK35DfGj+Z+ova/qESKcTEO 9bKQR102smTJaY0hCys9+w0Eu+kPr2Ig3/sHsfTCUlQeCmX63vhRiJWhQixuA5mq70eF +Gma+HBI/wSrBrAv5/tcwPYQq62bSZFqJjP/IxZLkYpHpKdvEuuZ+JCJsBnG5w5PbExN YEeMGcWobxG8YEBehIUPZaVPYCK9dTvP2km3kFLIY0LwvPeDuXvBuhgrFTghnJaNp9i+ c9nA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1760430990; x=1761035790; h=content-transfer-encoding:in-reply-to:content-language:from :references:cc:to:subject:user-agent:mime-version:date:message-id :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=PlCr4KtCOqjtwAQHsCr8GzfdPPkJghN91drUl4fH4VI=; b=aK88kIhDXPGt/McO0E85V5m9pflDc+Ha6DJKsSmUh3HkiHxcV3L4T4Y0TiXcGnC0sy 5i2cG5hHg3dimYpOpVQMgh8ZCMofRPkiamP+AP0OE6JNyHFayDfbwwynkIXlk6WoEPGE GBubSmFkametzdzzMARqlcnuSLAVA/cEuUKDORgO+ROQjIrYGqvIAn9Da0hAGQBrnPGz GNPUTZ+Ksjdo/5VNpkxHEPhVoCNO7/chdEYL8RCjAzGkVJEWUtntfxW/SQngV9UdmMt9 ej1AvMAen6Rjag4v4jxf8FmLkomOJpaInDymOpFx0wrggFn8GH93ro4rcYTpbt/QIkuE 8Fwg== X-Gm-Message-State: AOJu0Yy2RZNUBSEKCcjVMmMbG/w5KsY1g/kvuNx8U+yT8DitZEUWf/vW UEThDkqgi9sBgZ4BuMEdr2cG+WlWDPyq38dOhmNfIMtVK3+2Z3wTyR4COHz5w4v2AkY= X-Gm-Gg: ASbGncvUYXGKtALX5bcUyrZIK0nbzS3yriadsru2TEcRu1vsyDeRoSfYak6XAzFmFze wHHkyNaQwMA9IPoDVWw3VELwqTLzHMDv9qrergCmLPOH7F7EODdPzlIXtNYHD6fz+wkrCOLA8tr 05hyYuHIBTAz2MT8qI71Y+PvBKC94JVcGs6gcP7mvkJwhZW7VxsLld4+gCPTN2Gzdmkq5s9b9mf 8Y/evFbI/uoEJb0RT6XotS9r3oM1kbz/fCkyQFkV3xtygNYBAbeGFZwpNZtj8sCsYUnbO9cwuf6 quwZ742PIW/bZOziaL976fB+xLklPJljOQLKn9UUu3jvQbKeaJ9LulYuWZsh3PfQkdio4OTL8IL M4xqQIcxsBcRjbfaaAwmUoxzjaWVRHLu1Ik/fx9H6KL9DRCIHQcO6kA5eUJY= X-Google-Smtp-Source: AGHT+IHvca3H/eoAiSfXW7AaqB6vZ9CVuxlAXPqbLcEH7dPAWw/TAns0mWyDT3g0uw99AA+D6AEn0w== X-Received: by 2002:a05:600c:8206:b0:46e:19f8:88d3 with SMTP id 5b1f17b1804b1-46fa9af313bmr162991485e9.22.1760430989453; Tue, 14 Oct 2025 01:36:29 -0700 (PDT) Received: from [192.168.50.4] ([82.78.167.40]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-426ce5e8b31sm22554601f8f.54.2025.10.14.01.36.27 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 14 Oct 2025 01:36:28 -0700 (PDT) Message-ID: <77678dd6-071b-4911-a5c5-f1519c92e91a@tuxon.dev> Date: Tue, 14 Oct 2025 11:36:27 +0300 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v7 4/7] reset: rzg2l-usbphy-ctrl: Add support for USB PWRRDY To: Philipp Zabel , vkoul@kernel.org, kishon@kernel.org, robh@kernel.org, krzk+dt@kernel.org, conor+dt@kernel.org, geert+renesas@glider.be, magnus.damm@gmail.com, yoshihiro.shimoda.uh@renesas.com, biju.das.jz@bp.renesas.com Cc: linux-phy@lists.infradead.org, devicetree@vger.kernel.org, linux-kernel@vger.kernel.org, linux-renesas-soc@vger.kernel.org, Claudiu Beznea , Wolfram Sang References: <20250925100302.3508038-1-claudiu.beznea.uj@bp.renesas.com> <20250925100302.3508038-5-claudiu.beznea.uj@bp.renesas.com> <66d85e70-efb8-4a45-9164-55b123691b70@tuxon.dev> <6d4bc69c-1571-4d98-b0d4-214c68be118e@tuxon.dev> From: Claudiu Beznea Content-Language: en-US In-Reply-To: X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20251014_013633_254483_CA1E1C7A X-CRM114-Status: GOOD ( 35.73 ) X-BeenThere: linux-phy@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: Linux Phy Mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-phy" Errors-To: linux-phy-bounces+linux-phy=archiver.kernel.org@lists.infradead.org Hi, Philipp, On 10/13/25 17:57, Philipp Zabel wrote: > 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 >>>>>>> >>>>>>> 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 The genpd on/off notifier suggestion wasn't tried, but only the implementation of PWRRDY handling through the power domain (what Ulf suggested though "Move the entire reset handling into the PM domain provider, as it obviously knows when the domain is getting turned on/off" in https://lore.kernel.org/all/fa9b3449-ea3e-4482-b7eb-96999445cea5@tuxon.dev/). Sorry if I mislead you. Ulf suggested then here https://lore.kernel.org/all/CAPDyKFpLnREr4C=wZ7o8Lb-CZbQa4Nr2VTuYdZHZ26Rcb1Masg@mail.gmail.com/ that he is not agreeing anymore with having it as power domain due to the discussion in thread https://lore.kernel.org/all/TY3PR01MB1134652F9587CFA0ADE851CA486902@TY3PR01MB11346.jpnprd01.prod.outlook.com/ (I can't remember what made him taking back is ack on this solution and I can't find something in the thread either). If I'm not wrong, with the information that we have at the moment, the best for the notifier would have to register it (before runtime resume) and implement it in this driver (reset-rzg2l-usbphy-ctrl) so that, when the pm_runtime_resume_and_get()/pm_runtime_put() in rzg2l_usbphy_ctrl_probe()/rzg2l_usbphy_ctrl_remove() will be called (or suspend/resume) the notifier will be called and set the PWRRDY bit. Please let me know if you see it otherwise. > it was dismissed. The power domain approach was dismissed as a result of discussion from this thread: https://lore.kernel.org/all/TY3PR01MB1134652F9587CFA0ADE851CA486902@TY3PR01MB11346.jpnprd01.prod.outlook.com/ I don't remember exactly what triggered it and can't find it as well, sorry. > > 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? That is correct, the CPG is a clock power domain. All the clocks that CPG can be provided (including USB clocks) are part of CPG clock power domain. > In the thread it sounded like there were > multiple domains. You probably refer to this: https://lore.kernel.org/all/fa9b3449-ea3e-4482-b7eb-96999445cea5@tuxon.dev/ In there, I was trying to present to Ulf how I did implement (locally, nothing posted) the handling of PWRRDY though power domains. In that case the SYSC (System Controller), where the PWRRDY resides, was modeled as a power domain, I passed to the reset-rzg2l-usbphy-ctrl DT node the phandle to sysc USB power domain as: power-domains = <&cpg R9A08G045_PD_USB_PHY>, <&sysc R9A08G045_SYSC_PD_USB>; along with the cpg, and handled it in the reset-rzg2l-usbphy-ctrl probe(). > > Is the issue that you need the PWRRDY signal to be (de)asserted > independently from the CPG power domain enable/disable? Yes. I need to de-assert it before clocks, MSTOP on probe/resume and assert it back after clocks, MSTOP, on remove/suspend. > (Why?) Due to hardware constraints. This is how Renesas HW team recommended. > > Why can't the power domain provider (cpg) have the renesas,sysc-pwrrdy > property and set the signal together with the power domain? That can be done but, passing a SYSC phandle to the CPG DT node will not be valid from the HW description point of view. > >>>> 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. > 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. Thank you, Claudiu -- linux-phy mailing list linux-phy@lists.infradead.org https://lists.infradead.org/mailman/listinfo/linux-phy