Message-ID: <CAPDyKFrFX_UeYWuZtQPoxHbZb0CwpLRA=QcMFsALwuiFTY3T5Q@mail.gmail.com>
Date: Thu, 5 Sep 2024 13:38:27 +0200
From: Ulf Hansson <ulf.hansson@...aro.org>
To: Kevin Hilman <khilman@...libre.com>
Cc: linux-pm@...r.kernel.org, Nishanth Menon <nm@...com>, Vibhore Vardhan <vibhore@...com>, 
	Dhruva Gole <d-gole@...com>, Akashdeep Kaur <a-kaur@...com>, Sebin Francis <sebin.francis@...com>, 
	Markus Schneider-Pargmann <msp@...libre.com>, linux-arm-kernel@...ts.infradead.org, 
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH v2 0/3] pmdomain: ti_sci: collect and send low-power mode constraints

On Tue, 20 Aug 2024 at 02:00, Kevin Hilman <khilman@...libre.com> wrote:
>
> The latest (10.x) version of the firmware for the PM co-processor (aka
> device manager, or DM) adds support for a "managed" mode, where the DM
> firmware will select the specific low power state which is entered
> when Linux requests a system-wide suspend.
>
> In this mode, the DM will always attempt the deepest low-power state
> available for the SoC.
>
> However, Linux (or OSes running on other cores) may want to constrain
> the DM for certain use cases.  For example, the deepest state may have
> a wakeup/resume latency that is too long for certain use cases.  Or,
> some wakeup-capable devices may potentially be powered off in deep
> low-power states, but if one of those devices is enabled as a wakeup
> source, it should not be powered off.
>
> These kinds of constraints are are already known in Linux by the use
> of existing APIs such as per-device PM QoS and device wakeup APIs, but
> now we need to communicate these constraints to the DM.
>
> For TI SoCs with TI SCI support, all DM-managed devices will be
> connected to a TI SCI PM domain.  So the goal of this series is to use
> the PM domain driver for TI SCI devices to collect constraints, and
> communicate them to the DM via the new TI SCI APIs.
>
> This is all managed by TI SCI PM domain code.  No new APIs are needed
> by Linux drivers.  Any device that is managed by TI SCI will be
> checked for QoS constraints or wakeup capability and the constraints
> will be collected and sent to the DM.
>
> This series depends on the support for the new TI SCI APIs (v10) and
> was also tested with this series to update 8250_omap serial support
> for AM62x[2].
>
> [1] https://lore.kernel.org/all/20240801195422.2296347-1-msp@baylibre.com
> [2] https://lore.kernel.org/all/20240807141227.1093006-1-msp@baylibre.com/
>
> Signed-off-by: Kevin Hilman <khilman@...libre.com>
> ---
> Changes in v2:
>
> - To simplify this version a bit, drop the pmdomain ->power_off()
>   changes.  Constraints only sent during ->suspend() path.  The pmdomain
>   path was an optimization that may be added back later.
> - With the above simplification, drop the extra state variables that
>   had been added to keep track of constraint status.
> - Link to v1: https://lore.kernel.org/r/20240805-lpm-v6-10-constraints-pmdomain-v1-0-d186b68ded4c@baylibre.com
>
> ---
> Kevin Hilman (3):
>       pmdomain: ti_sci: add per-device latency constraint management
>       pmdomain: ti_sci: add wakeup constraint management
>       pmdomain: ti_sci: handle wake IRQs for IO daisy chain wakeups
>
>  drivers/pmdomain/ti/ti_sci_pm_domains.c | 76 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
>  1 file changed, 76 insertions(+)
> ---
> base-commit: ad7eb1b6b92ee0c959a0a6ae846ddadd7a79ea64
> change-id: 20240802-lpm-v6-10-constraints-pmdomain-f33df5aef449
>
> Best regards,
> --
> Kevin Hilman <khilman@...libre.com>

Besides a couple of minor things that I have commented on for each
patch, this looks okay to me!

Taking into account the other series that this depends on, what is the
best merging strategy? Is it safe for me to take it through my
pmdomain tree?

Kind regards
Uffe

Powered by blists - more mailing lists