From mboxrd@z Thu Jan 1 00:00:00 1970 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=bootlin.com header.i=@bootlin.com header.b="eY5eglF9" Received: from relay6-d.mail.gandi.net (relay6-d.mail.gandi.net [IPv6:2001:4b98:dc4:8::226]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 7E65485; Mon, 27 Nov 2023 05:26:01 -0800 (PST) Received: by mail.gandi.net (Postfix) with ESMTPSA id 608B7C000D; Mon, 27 Nov 2023 13:25:58 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bootlin.com; s=gm1; t=1701091560; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=A2YChlyfbMPmIhM4ZAtNvRzQpOjcTZdxdAoI6XnzuAM=; b=eY5eglF9GmoTKCK3yOrebScc9pb2iRDEQFN2aINDLK4+baN8wZ41yC4OrCcEpBqUHqG2qJ CMIPi8PMAIl5AsfSZiEKZC7Je3gUH+B6tak719ivTd3DCtml+YoMscAw7XPAK5wHJCnu4o uo0a9lPsRwfdFzR5kg1hmTTF/M1+NALjQjcY1KzX2uBxJgyxnx7GqmZt8FjLlv2e6Ytr4F PPeq95Qb69Jb33tuyNXQ7qJ1DPFXjuQeDxlaS+a42yaHxVGVtTRIpMuOI1tFkhT8qY/I+B SGavC6PPR1ICEe7NgXliY+GHENhMQWXlhkvAPJQ/8oNgY+Kt76754c780+9bqg== Precedence: bulk X-Mailing-List: devicetree@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: Mime-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=UTF-8 Date: Mon, 27 Nov 2023 14:25:58 +0100 Message-Id: To: "Kevin Hilman" , "Roger Quadros" , "Greg Kroah-Hartman" , "Rob Herring" , "Krzysztof Kozlowski" , "Conor Dooley" , "Peter Chen" , "Pawel Laszczak" , "Nishanth Menon" , "Vignesh Raghavendra" , "Tero Kristo" , "Vardhan, Vibhore" From: =?utf-8?q?Th=C3=A9o_Lebrun?= Subject: Re: [PATCH 3/6] usb: cdns3-ti: add suspend/resume procedures for J7200 Cc: , , , , =?utf-8?q?Gr=C3=A9gory_Clement?= , "Thomas Petazzoni" X-Mailer: aerc 0.15.2 References: <20231113-j7200-usb-suspend-v1-0-ad1ee714835c@bootlin.com> <20231113-j7200-usb-suspend-v1-3-ad1ee714835c@bootlin.com> <5080372b-1f48-4cbc-a6c4-8689c28983cb@kernel.org> <3e00b2ad-b58f-4b09-9230-683c58d3bb92@kernel.org> <7h34wxfmwn.fsf@baylibre.com> <7hil5odtwl.fsf@baylibre.com> In-Reply-To: <7hil5odtwl.fsf@baylibre.com> X-GND-Sasl: theo.lebrun@bootlin.com Hello, On Sun Nov 26, 2023 at 11:36 PM CET, Kevin Hilman wrote: > Th=C3=A9o Lebrun writes: > > On Wed Nov 22, 2023 at 11:23 PM CET, Kevin Hilman wrote: > >> Th=C3=A9o Lebrun writes: > >> The point is to signal to the power domain the device is in that it ca= n > >> power on/off. These IP blocks are (re)used on many different SoCs, so > >> the driver should not make any assumptions about what power domain it = is > >> in (if any.) > > > > On my platform, when the device is attached to the PD it gets turned on= . > > That feels logical to me: if a driver is not RPM aware it "just works". > > It "just works"... until the domain gets turned off. > > > Are there platforms where RPM must get enabled for the attached > > power-domains to be turned on? > > Yes, but but more importantly, there are platforms where RPM must get > enabled for the power domain to *stay* on. For example, the power > domain might get turned on due to devices probing etc, but as soon as > all the RPM-enabled drivers drop their refcount, the domain will turn > off. If there is a device in that domain with a non-RPM enabled driver, > that device will be powered off anc cause a crash. OK, that makes sense, thanks for taking the time to explain. This topic makes me see two things that I feel are close to being bugs. I'd be curious to get your view on both. - If a device does not use RPM but its children do, it might get its associated power-domain turned off. That forces every single driver that want to stay alive to enable & increment RPM. What I naively expect: a genpd with a device attached to it that is not using RPM should mean that it should not be powered off at runtime_suspend. Benefit: no RPM calls in drivers that do not use it, and the behavior is that the genpd associated stays alive "as expected". - If a device uses RPM & has a refcount strictly positive, its associated power-domain gets turned off either way at suspend_noirq. That feels non-intuitive as well. What I naively expect: check for RPM refcounts of attached devices when doing suspend_noirq of power-domains. Benefit: control of what power-domains do from attached devices is done through the RPM API. Regards, -- Th=C3=A9o Lebrun, Bootlin Embedded Linux and Kernel engineering https://bootlin.com