[PATCH v4 0/3] pmdomain: ti_sci: collect and send low-power mode constraints

[PATCH v4 0/3] pmdomain: ti_sci: collect and send low-power mode constraints

[Kevin Hilman]

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@baylibre.com>
---
Changes in v4:
- fixed missing return in wakeirq error path
- updated trailers with reviewed & tested tags
- Link to v3: https://lore.kernel.org/r/20240905-lpm-v6-10-constraints-pmdomain-v3-0-e359cbb39654@baylibre.com

Changes in v3:
- change latency set functions to static void
- Link to v2: https://lore.kernel.org/r/20240819-lpm-v6-10-constraints-pmdomain-v2-0-461325a6008f@baylibre.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 | 72 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
 1 file changed, 72 insertions(+)
---
base-commit: ad7eb1b6b92ee0c959a0a6ae846ddadd7a79ea64
change-id: 20240802-lpm-v6-10-constraints-pmdomain-f33df5aef449
prerequisite-message-id: <20240904194229.109886-1-msp@baylibre.com>
prerequisite-patch-id: a0efbf22e69d23dba8bb96db4032ca644935709b
prerequisite-patch-id: a9b6a17956ff6a09a6ed19c35df9018e28b5059b
prerequisite-patch-id: 2999da190c1ba63aabecc55fae501d442e4e0d7b
prerequisite-patch-id: 69a741b9c81d7990937483fc481aafa70e67669d
prerequisite-patch-id: 945b15416a011cb40007c5d95561786c1776bb98

Best regards,
-- 
Kevin Hilman <khilman@baylibre.com>

[PATCH v4 1/3] pmdomain: ti_sci: add per-device latency constraint management

[Kevin Hilman]

For each device in a TI SCI PM domain, check whether the device has
any resume latency constraints set via per-device PM QoS.  If
constraints are set, send them to DM via the new SCI constraints API.

Checking for constraints happen for each device before system-wide
suspend (via ->suspend() hook.)

An important detail here is that the PM domain driver inserts itself
into the path of both the ->suspend() and ->resume() hook path
of *all* devices in the PM domain.  This allows generic PM domain code
to handle the constraint management and communication with TI SCI.

Further, this allows device drivers to use existing PM QoS APIs to
add/update constraints.

DM firmware clears constraints during its resume, so Linux has
to check/update/send constraints each time system suspends.

Co-developed-by: Vibhore Vardhan <vibhore@ti.com>
Signed-off-by: Vibhore Vardhan <vibhore@ti.com>
Reviewed-by: Markus Schneider-Pargmann <msp@baylibre.com>
Reviewed-by: Ulf Hansson <ulf.hansson@linaro.org>
Tested-by: Dhruva Gole <d-gole@ti.com>
Signed-off-by: Kevin Hilman <khilman@baylibre.com>
---
 drivers/pmdomain/ti/ti_sci_pm_domains.c | 46 ++++++++++++++++++++++++++++++++++++++++++++++
 1 file changed, 46 insertions(+)

diff --git a/drivers/pmdomain/ti/ti_sci_pm_domains.c b/drivers/pmdomain/ti/ti_sci_pm_domains.c
index 1510d5ddae3d..bb95c40ab3ea 100644
--- a/drivers/pmdomain/ti/ti_sci_pm_domains.c
+++ b/drivers/pmdomain/ti/ti_sci_pm_domains.c
@@ -13,6 +13,8 @@
 #include <linux/platform_device.h>
 #include <linux/pm_domain.h>
 #include <linux/slab.h>
+#include <linux/pm_qos.h>
+#include <linux/pm_runtime.h>
 #include <linux/soc/ti/ti_sci_protocol.h>
 #include <dt-bindings/soc/ti,sci_pm_domain.h>
 
@@ -51,6 +53,27 @@ struct ti_sci_pm_domain {
 
 #define genpd_to_ti_sci_pd(gpd) container_of(gpd, struct ti_sci_pm_domain, pd)
 
+static inline bool ti_sci_pd_is_valid_constraint(s32 val)
+{
+	return val != PM_QOS_RESUME_LATENCY_NO_CONSTRAINT;
+}
+
+static void ti_sci_pd_set_lat_constraint(struct device *dev, s32 val)
+{
+	struct generic_pm_domain *genpd = pd_to_genpd(dev->pm_domain);
+	struct ti_sci_pm_domain *pd = genpd_to_ti_sci_pd(genpd);
+	const struct ti_sci_handle *ti_sci = pd->parent->ti_sci;
+	int ret;
+
+	ret = ti_sci->ops.pm_ops.set_latency_constraint(ti_sci, val, TISCI_MSG_CONSTRAINT_SET);
+	if (ret)
+		dev_err(dev, "ti_sci_pd: set latency constraint failed: ret=%d\n",
+			ret);
+	else
+		dev_dbg(dev, "ti_sci_pd: ID:%d set latency constraint %d\n",
+			pd->idx, val);
+}
+
 /*
  * ti_sci_pd_power_off(): genpd power down hook
  * @domain: pointer to the powerdomain to power off
@@ -79,6 +102,22 @@ static int ti_sci_pd_power_on(struct generic_pm_domain *domain)
 		return ti_sci->ops.dev_ops.get_device(ti_sci, pd->idx);
 }
 
+static int ti_sci_pd_suspend(struct device *dev)
+{
+	int ret;
+	s32 val;
+
+	ret = pm_generic_suspend(dev);
+	if (ret)
+		return ret;
+
+	val = dev_pm_qos_read_value(dev, DEV_PM_QOS_RESUME_LATENCY);
+	if (ti_sci_pd_is_valid_constraint(val))
+		ti_sci_pd_set_lat_constraint(dev, val);
+
+	return 0;
+}
+
 /*
  * ti_sci_pd_xlate(): translation service for TI SCI genpds
  * @genpdspec: DT identification data for the genpd
@@ -188,6 +227,13 @@ static int ti_sci_pm_domain_probe(struct platform_device *pdev)
 				pd->pd.power_on = ti_sci_pd_power_on;
 				pd->idx = args.args[0];
 				pd->parent = pd_provider;
+				/*
+				 * If SCI constraint functions are present, then firmware
+				 * supports the constraints API.
+				 */
+				if (pd_provider->ti_sci->ops.pm_ops.set_device_constraint &&
+				    pd_provider->ti_sci->ops.pm_ops.set_latency_constraint)
+					pd->pd.domain.ops.suspend = ti_sci_pd_suspend;
 
 				pm_genpd_init(&pd->pd, NULL, true);
 

-- 
2.46.0

[PATCH v4 2/3] pmdomain: ti_sci: add wakeup constraint management

[Kevin Hilman]

During system-wide suspend, check all devices connected to PM domain
to see if they are wakeup-enabled.  If so, set a TI SCI device
constraint.

Note: DM firmware clears all constraints on resume.

Co-developed-by: Vibhore Vardhan <vibhore@ti.com>
Signed-off-by: Vibhore Vardhan <vibhore@ti.com>
Reviewed-by: Ulf Hansson <ulf.hansson@linaro.org>
Tested-by: Dhruva Gole <d-gole@ti.com>
Signed-off-by: Kevin Hilman <khilman@baylibre.com>
---
 drivers/pmdomain/ti/ti_sci_pm_domains.c | 17 +++++++++++++++++
 1 file changed, 17 insertions(+)

diff --git a/drivers/pmdomain/ti/ti_sci_pm_domains.c b/drivers/pmdomain/ti/ti_sci_pm_domains.c
index bb95c40ab3ea..1ab1e46924ab 100644
--- a/drivers/pmdomain/ti/ti_sci_pm_domains.c
+++ b/drivers/pmdomain/ti/ti_sci_pm_domains.c
@@ -74,6 +74,21 @@ static void ti_sci_pd_set_lat_constraint(struct device *dev, s32 val)
 			pd->idx, val);
 }
 
+static inline void ti_sci_pd_set_wkup_constraint(struct device *dev)
+{
+	struct generic_pm_domain *genpd = pd_to_genpd(dev->pm_domain);
+	struct ti_sci_pm_domain *pd = genpd_to_ti_sci_pd(genpd);
+	const struct ti_sci_handle *ti_sci = pd->parent->ti_sci;
+	int ret;
+
+	if (device_may_wakeup(dev)) {
+		ret = ti_sci->ops.pm_ops.set_device_constraint(ti_sci, pd->idx,
+							       TISCI_MSG_CONSTRAINT_SET);
+		if (!ret)
+			dev_dbg(dev, "ti_sci_pd: ID:%d set device constraint.\n", pd->idx);
+	}
+}
+
 /*
  * ti_sci_pd_power_off(): genpd power down hook
  * @domain: pointer to the powerdomain to power off
@@ -115,6 +130,8 @@ static int ti_sci_pd_suspend(struct device *dev)
 	if (ti_sci_pd_is_valid_constraint(val))
 		ti_sci_pd_set_lat_constraint(dev, val);
 
+	ti_sci_pd_set_wkup_constraint(dev);
+
 	return 0;
 }
 

-- 
2.46.0

Re: [PATCH v4 2/3] pmdomain: ti_sci: add wakeup constraint management

[Markus Schneider-Pargmann]

On Fri, Sep 06, 2024 at 09:14:50AM GMT, Kevin Hilman wrote:
> During system-wide suspend, check all devices connected to PM domain
> to see if they are wakeup-enabled.  If so, set a TI SCI device
> constraint.
> 
> Note: DM firmware clears all constraints on resume.
> 
> Co-developed-by: Vibhore Vardhan <vibhore@ti.com>
> Signed-off-by: Vibhore Vardhan <vibhore@ti.com>
> Reviewed-by: Ulf Hansson <ulf.hansson@linaro.org>
> Tested-by: Dhruva Gole <d-gole@ti.com>
> Signed-off-by: Kevin Hilman <khilman@baylibre.com>

Reviewed-by: Markus Schneider-Pargmann <msp@baylibre.com>

Best
Markus

> ---
>  drivers/pmdomain/ti/ti_sci_pm_domains.c | 17 +++++++++++++++++
>  1 file changed, 17 insertions(+)
> 
> diff --git a/drivers/pmdomain/ti/ti_sci_pm_domains.c b/drivers/pmdomain/ti/ti_sci_pm_domains.c
> index bb95c40ab3ea..1ab1e46924ab 100644
> --- a/drivers/pmdomain/ti/ti_sci_pm_domains.c
> +++ b/drivers/pmdomain/ti/ti_sci_pm_domains.c
> @@ -74,6 +74,21 @@ static void ti_sci_pd_set_lat_constraint(struct device *dev, s32 val)
>  			pd->idx, val);
>  }
>  
> +static inline void ti_sci_pd_set_wkup_constraint(struct device *dev)
> +{
> +	struct generic_pm_domain *genpd = pd_to_genpd(dev->pm_domain);
> +	struct ti_sci_pm_domain *pd = genpd_to_ti_sci_pd(genpd);
> +	const struct ti_sci_handle *ti_sci = pd->parent->ti_sci;
> +	int ret;
> +
> +	if (device_may_wakeup(dev)) {
> +		ret = ti_sci->ops.pm_ops.set_device_constraint(ti_sci, pd->idx,
> +							       TISCI_MSG_CONSTRAINT_SET);
> +		if (!ret)
> +			dev_dbg(dev, "ti_sci_pd: ID:%d set device constraint.\n", pd->idx);
> +	}
> +}
> +
>  /*
>   * ti_sci_pd_power_off(): genpd power down hook
>   * @domain: pointer to the powerdomain to power off
> @@ -115,6 +130,8 @@ static int ti_sci_pd_suspend(struct device *dev)
>  	if (ti_sci_pd_is_valid_constraint(val))
>  		ti_sci_pd_set_lat_constraint(dev, val);
>  
> +	ti_sci_pd_set_wkup_constraint(dev);
> +
>  	return 0;
>  }
>  
> 
> -- 
> 2.46.0
> 

[PATCH v4 3/3] pmdomain: ti_sci: handle wake IRQs for IO daisy chain wakeups

[Kevin Hilman]

When a device supports IO daisy-chain wakeups, it uses a dedicated
wake IRQ.  Devices with IO daisy-chain wakeups enabled should not set
wakeup constraints since these can happen even from deep power states,
so should not prevent the DM from picking deep power states.

Wake IRQs are set with dev_pm_set_wake_irq() or
dev_pm_set_dedicated_wake_irq().  The latter is used by the serial
driver used on K3 platforms (drivers/tty/serial/8250/8250_omap.c)
when the interrupts-extended property is used to describe the
dedicated wakeup interrupt.

Detect these wake IRQs in the suspend path, and if set, skip sending
constraint.

Tested-by: Dhruva Gole <d-gole@ti.com>
Signed-off-by: Kevin Hilman <khilman@baylibre.com>
---
 drivers/pmdomain/ti/ti_sci_pm_domains.c | 9 +++++++++
 1 file changed, 9 insertions(+)

diff --git a/drivers/pmdomain/ti/ti_sci_pm_domains.c b/drivers/pmdomain/ti/ti_sci_pm_domains.c
index 1ab1e46924ab..566af9f055b8 100644
--- a/drivers/pmdomain/ti/ti_sci_pm_domains.c
+++ b/drivers/pmdomain/ti/ti_sci_pm_domains.c
@@ -82,6 +82,15 @@ static inline void ti_sci_pd_set_wkup_constraint(struct device *dev)
 	int ret;
 
 	if (device_may_wakeup(dev)) {
+		/*
+		 * If device can wakeup using IO daisy chain wakeups,
+		 * we do not want to set a constraint.
+		 */
+		if (dev->power.wakeirq) {
+			dev_dbg(dev, "%s: has wake IRQ, not setting constraints\n", __func__);
+			return;
+		}
+
 		ret = ti_sci->ops.pm_ops.set_device_constraint(ti_sci, pd->idx,
 							       TISCI_MSG_CONSTRAINT_SET);
 		if (!ret)

-- 
2.46.0

Re: [PATCH v4 3/3] pmdomain: ti_sci: handle wake IRQs for IO daisy chain wakeups

[Ulf Hansson]

On Fri, 6 Sept 2024 at 18:15, Kevin Hilman <khilman@baylibre.com> wrote:
>
> When a device supports IO daisy-chain wakeups, it uses a dedicated
> wake IRQ.  Devices with IO daisy-chain wakeups enabled should not set
> wakeup constraints since these can happen even from deep power states,
> so should not prevent the DM from picking deep power states.
>
> Wake IRQs are set with dev_pm_set_wake_irq() or
> dev_pm_set_dedicated_wake_irq().  The latter is used by the serial
> driver used on K3 platforms (drivers/tty/serial/8250/8250_omap.c)
> when the interrupts-extended property is used to describe the
> dedicated wakeup interrupt.
>
> Detect these wake IRQs in the suspend path, and if set, skip sending
> constraint.
>
> Tested-by: Dhruva Gole <d-gole@ti.com>
> Signed-off-by: Kevin Hilman <khilman@baylibre.com>

Reviewed-by: Ulf Hansson <ulf.hansson@linaro.org>

Kind regards
Uffe

> ---
>  drivers/pmdomain/ti/ti_sci_pm_domains.c | 9 +++++++++
>  1 file changed, 9 insertions(+)
>
> diff --git a/drivers/pmdomain/ti/ti_sci_pm_domains.c b/drivers/pmdomain/ti/ti_sci_pm_domains.c
> index 1ab1e46924ab..566af9f055b8 100644
> --- a/drivers/pmdomain/ti/ti_sci_pm_domains.c
> +++ b/drivers/pmdomain/ti/ti_sci_pm_domains.c
> @@ -82,6 +82,15 @@ static inline void ti_sci_pd_set_wkup_constraint(struct device *dev)
>         int ret;
>
>         if (device_may_wakeup(dev)) {
> +               /*
> +                * If device can wakeup using IO daisy chain wakeups,
> +                * we do not want to set a constraint.
> +                */
> +               if (dev->power.wakeirq) {
> +                       dev_dbg(dev, "%s: has wake IRQ, not setting constraints\n", __func__);
> +                       return;
> +               }
> +
>                 ret = ti_sci->ops.pm_ops.set_device_constraint(ti_sci, pd->idx,
>                                                                TISCI_MSG_CONSTRAINT_SET);
>                 if (!ret)
>
> --
> 2.46.0
>

Re: [PATCH v4 3/3] pmdomain: ti_sci: handle wake IRQs for IO daisy chain wakeups

[Markus Schneider-Pargmann]

On Fri, Sep 06, 2024 at 09:14:51AM GMT, Kevin Hilman wrote:
> When a device supports IO daisy-chain wakeups, it uses a dedicated
> wake IRQ.  Devices with IO daisy-chain wakeups enabled should not set
> wakeup constraints since these can happen even from deep power states,
> so should not prevent the DM from picking deep power states.
> 
> Wake IRQs are set with dev_pm_set_wake_irq() or
> dev_pm_set_dedicated_wake_irq().  The latter is used by the serial
> driver used on K3 platforms (drivers/tty/serial/8250/8250_omap.c)
> when the interrupts-extended property is used to describe the
> dedicated wakeup interrupt.
> 
> Detect these wake IRQs in the suspend path, and if set, skip sending
> constraint.
> 
> Tested-by: Dhruva Gole <d-gole@ti.com>
> Signed-off-by: Kevin Hilman <khilman@baylibre.com>

Reviewed-by: Markus Schneider-Pargmann <msp@baylibre.com>

Best
Markus

> ---
>  drivers/pmdomain/ti/ti_sci_pm_domains.c | 9 +++++++++
>  1 file changed, 9 insertions(+)
> 
> diff --git a/drivers/pmdomain/ti/ti_sci_pm_domains.c b/drivers/pmdomain/ti/ti_sci_pm_domains.c
> index 1ab1e46924ab..566af9f055b8 100644
> --- a/drivers/pmdomain/ti/ti_sci_pm_domains.c
> +++ b/drivers/pmdomain/ti/ti_sci_pm_domains.c
> @@ -82,6 +82,15 @@ static inline void ti_sci_pd_set_wkup_constraint(struct device *dev)
>  	int ret;
>  
>  	if (device_may_wakeup(dev)) {
> +		/*
> +		 * If device can wakeup using IO daisy chain wakeups,
> +		 * we do not want to set a constraint.
> +		 */
> +		if (dev->power.wakeirq) {
> +			dev_dbg(dev, "%s: has wake IRQ, not setting constraints\n", __func__);
> +			return;
> +		}
> +
>  		ret = ti_sci->ops.pm_ops.set_device_constraint(ti_sci, pd->idx,
>  							       TISCI_MSG_CONSTRAINT_SET);
>  		if (!ret)
> 
> -- 
> 2.46.0
> 

Re: [PATCH v4 0/3] pmdomain: ti_sci: collect and send low-power mode constraints

[Nishanth Menon]

Hi Kevin Hilman,

On Fri, 06 Sep 2024 09:14:48 -0700, Kevin Hilman 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.
> 
> [...]

I have applied the following to branch ti-drivers-soc-next on [1].
Thank you!

Ulf, based on your ack[2], I have assumed that you want me to pick
this series up. Let me know if that is not the case and I can drop the
series.

[1/3] pmdomain: ti_sci: add per-device latency constraint management
      commit: 7c2c8d2651b5ffaffb2d5f723bd5b0493bd66f36
[2/3] pmdomain: ti_sci: add wakeup constraint management
      commit: 5a2d997b1bf8b05379309270063d7b9bd3767dd2
[3/3] pmdomain: ti_sci: handle wake IRQs for IO daisy chain wakeups
      commit: e8f35dc8de8c3216d28dab51b962bb31f20934c8

All being well this means that it will be integrated into the linux-next
tree (usually sometime in the next 24 hours) and sent up the chain during
the next merge window (or sooner if it is a relevant bug fix), however if
problems are discovered then the patch may be dropped or reverted.

You may get further e-mails resulting from automated or manual testing
and review of the tree, please engage with people reporting problems and
send followup patches addressing any issues that are reported if needed.

If any updates are required or you are submitting further changes they
should be sent as incremental updates against current git, existing
patches will not be replaced.

Please add any relevant lists and maintainers to the CCs when replying
to this mail.

[1] https://git.kernel.org/pub/scm/linux/kernel/git/ti/linux.git
[2] https://lore.kernel.org/all/CAPDyKFr9isnz66B+n5y3=QO-ndB05JKZN3kgXO+kXBn7ofcwMw@mail.gmail.com/
-- 
Regards,
Nishanth Menon
Key (0xDDB5849D1736249D) / Fingerprint: F8A2 8693 54EB 8232 17A3  1A34 DDB5 849D 1736 249D

Re: [PATCH v4 0/3] pmdomain: ti_sci: collect and send low-power mode constraints

[Ulf Hansson]

On Wed, 30 Oct 2024 at 14:01, Nishanth Menon <nm@ti.com> wrote:
>
> Hi Kevin Hilman,
>
> On Fri, 06 Sep 2024 09:14:48 -0700, Kevin Hilman 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.
> >
> > [...]
>
> I have applied the following to branch ti-drivers-soc-next on [1].
> Thank you!
>
> Ulf, based on your ack[2], I have assumed that you want me to pick
> this series up. Let me know if that is not the case and I can drop the
> series.

Well, that was a while ago. The reason was because there was a
dependency to another series [2], when this was posted.

If that's not the case anymore, I think it's better to funnel this via
my pmdomain tree. Please let me know how to proceed.

Kind regards
Uffe

>
> [1/3] pmdomain: ti_sci: add per-device latency constraint management
>       commit: 7c2c8d2651b5ffaffb2d5f723bd5b0493bd66f36
> [2/3] pmdomain: ti_sci: add wakeup constraint management
>       commit: 5a2d997b1bf8b05379309270063d7b9bd3767dd2
> [3/3] pmdomain: ti_sci: handle wake IRQs for IO daisy chain wakeups
>       commit: e8f35dc8de8c3216d28dab51b962bb31f20934c8
>
> All being well this means that it will be integrated into the linux-next
> tree (usually sometime in the next 24 hours) and sent up the chain during
> the next merge window (or sooner if it is a relevant bug fix), however if
> problems are discovered then the patch may be dropped or reverted.
>
> You may get further e-mails resulting from automated or manual testing
> and review of the tree, please engage with people reporting problems and
> send followup patches addressing any issues that are reported if needed.
>
> If any updates are required or you are submitting further changes they
> should be sent as incremental updates against current git, existing
> patches will not be replaced.
>
> Please add any relevant lists and maintainers to the CCs when replying
> to this mail.
>
> [1] https://git.kernel.org/pub/scm/linux/kernel/git/ti/linux.git
> [2] https://lore.kernel.org/all/CAPDyKFr9isnz66B+n5y3=QO-ndB05JKZN3kgXO+kXBn7ofcwMw@mail.gmail.com/
> --
> Regards,
> Nishanth Menon
> Key (0xDDB5849D1736249D) / Fingerprint: F8A2 8693 54EB 8232 17A3  1A34 DDB5 849D 1736 249D
>

Re: [PATCH v4 0/3] pmdomain: ti_sci: collect and send low-power mode constraints

[Kevin Hilman]

Ulf Hansson <ulf.hansson@linaro.org> writes:

> On Wed, 30 Oct 2024 at 14:01, Nishanth Menon <nm@ti.com> wrote:
>>
>> Hi Kevin Hilman,
>>
>> On Fri, 06 Sep 2024 09:14:48 -0700, Kevin Hilman 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.
>> >
>> > [...]
>>
>> I have applied the following to branch ti-drivers-soc-next on [1].
>> Thank you!
>>
>> Ulf, based on your ack[2], I have assumed that you want me to pick
>> this series up. Let me know if that is not the case and I can drop the
>> series.
>
> Well, that was a while ago. The reason was because there was a
> dependency to another series [2], when this was posted.
>
> If that's not the case anymore, I think it's better to funnel this via
> my pmdomain tree. Please let me know how to proceed.

The build-time dependency on [2] still exists, and since that was just
queued up by Nishanth, I think this series should (still) go along with
it to keep things simple.

Kevin

> Kind regards
> Uffe
>
>>
>> [1/3] pmdomain: ti_sci: add per-device latency constraint management
>>       commit: 7c2c8d2651b5ffaffb2d5f723bd5b0493bd66f36
>> [2/3] pmdomain: ti_sci: add wakeup constraint management
>>       commit: 5a2d997b1bf8b05379309270063d7b9bd3767dd2
>> [3/3] pmdomain: ti_sci: handle wake IRQs for IO daisy chain wakeups
>>       commit: e8f35dc8de8c3216d28dab51b962bb31f20934c8
>>
>> All being well this means that it will be integrated into the linux-next
>> tree (usually sometime in the next 24 hours) and sent up the chain during
>> the next merge window (or sooner if it is a relevant bug fix), however if
>> problems are discovered then the patch may be dropped or reverted.
>>
>> You may get further e-mails resulting from automated or manual testing
>> and review of the tree, please engage with people reporting problems and
>> send followup patches addressing any issues that are reported if needed.
>>
>> If any updates are required or you are submitting further changes they
>> should be sent as incremental updates against current git, existing
>> patches will not be replaced.
>>
>> Please add any relevant lists and maintainers to the CCs when replying
>> to this mail.
>>
>> [1] https://git.kernel.org/pub/scm/linux/kernel/git/ti/linux.git
>> [2] https://lore.kernel.org/all/CAPDyKFr9isnz66B+n5y3=QO-ndB05JKZN3kgXO+kXBn7ofcwMw@mail.gmail.com/
>> --
>> Regards,
>> Nishanth Menon
>> Key (0xDDB5849D1736249D) / Fingerprint: F8A2 8693 54EB 8232 17A3  1A34 DDB5 849D 1736 249D
>>

Re: [PATCH v4 0/3] pmdomain: ti_sci: collect and send low-power mode constraints

[Ulf Hansson]

On Wed, 30 Oct 2024 at 20:43, Kevin Hilman <khilman@baylibre.com> wrote:
>
> Ulf Hansson <ulf.hansson@linaro.org> writes:
>
> > On Wed, 30 Oct 2024 at 14:01, Nishanth Menon <nm@ti.com> wrote:
> >>
> >> Hi Kevin Hilman,
> >>
> >> On Fri, 06 Sep 2024 09:14:48 -0700, Kevin Hilman 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.
> >> >
> >> > [...]
> >>
> >> I have applied the following to branch ti-drivers-soc-next on [1].
> >> Thank you!
> >>
> >> Ulf, based on your ack[2], I have assumed that you want me to pick
> >> this series up. Let me know if that is not the case and I can drop the
> >> series.
> >
> > Well, that was a while ago. The reason was because there was a
> > dependency to another series [2], when this was posted.
> >
> > If that's not the case anymore, I think it's better to funnel this via
> > my pmdomain tree. Please let me know how to proceed.
>
> The build-time dependency on [2] still exists, and since that was just
> queued up by Nishanth, I think this series should (still) go along with
> it to keep things simple.
>
> Kevin

Right, that makes perfect sense to me too. If we discover conflicts,
let's deal with them then.

[...]

Kind regards
Uffe

Re: [PATCH v4 0/3] pmdomain: ti_sci: collect and send low-power mode constraints

[Nishanth Menon]

On 11:11-20241031, Ulf Hansson wrote:
> On Wed, 30 Oct 2024 at 20:43, Kevin Hilman <khilman@baylibre.com> wrote:
> >
> > Ulf Hansson <ulf.hansson@linaro.org> writes:
> >
> > > On Wed, 30 Oct 2024 at 14:01, Nishanth Menon <nm@ti.com> wrote:
> > >>
> > >> Hi Kevin Hilman,
> > >>
> > >> On Fri, 06 Sep 2024 09:14:48 -0700, Kevin Hilman 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.
> > >> >
> > >> > [...]
> > >>
> > >> I have applied the following to branch ti-drivers-soc-next on [1].
> > >> Thank you!
> > >>
> > >> Ulf, based on your ack[2], I have assumed that you want me to pick
> > >> this series up. Let me know if that is not the case and I can drop the
> > >> series.
> > >
> > > Well, that was a while ago. The reason was because there was a
> > > dependency to another series [2], when this was posted.
> > >
> > > If that's not the case anymore, I think it's better to funnel this via
> > > my pmdomain tree. Please let me know how to proceed.
> >
> > The build-time dependency on [2] still exists, and since that was just
> > queued up by Nishanth, I think this series should (still) go along with
> > it to keep things simple.
> >
> > Kevin
> 
> Right, that makes perfect sense to me too. If we discover conflicts,
> let's deal with them then.


oops.. I missed this response. OK, I will let things be.

-- 
Regards,
Nishanth Menon
Key (0xDDB5849D1736249D) / Fingerprint: F8A2 8693 54EB 8232 17A3  1A34 DDB5 849D 1736 249D

Re: [PATCH v4 0/3] pmdomain: ti_sci: collect and send low-power mode constraints

[Kevin Hilman]

Nishanth Menon <nm@ti.com> writes:

> On 11:11-20241031, Ulf Hansson wrote:
>> On Wed, 30 Oct 2024 at 20:43, Kevin Hilman <khilman@baylibre.com> wrote:
>> >
>> > Ulf Hansson <ulf.hansson@linaro.org> writes:
>> >
>> > > On Wed, 30 Oct 2024 at 14:01, Nishanth Menon <nm@ti.com> wrote:
>> > >>
>> > >> Hi Kevin Hilman,
>> > >>
>> > >> On Fri, 06 Sep 2024 09:14:48 -0700, Kevin Hilman 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.
>> > >> >
>> > >> > [...]
>> > >>
>> > >> I have applied the following to branch ti-drivers-soc-next on [1].
>> > >> Thank you!
>> > >>
>> > >> Ulf, based on your ack[2], I have assumed that you want me to pick
>> > >> this series up. Let me know if that is not the case and I can drop the
>> > >> series.
>> > >
>> > > Well, that was a while ago. The reason was because there was a
>> > > dependency to another series [2], when this was posted.
>> > >
>> > > If that's not the case anymore, I think it's better to funnel this via
>> > > my pmdomain tree. Please let me know how to proceed.
>> >
>> > The build-time dependency on [2] still exists, and since that was just
>> > queued up by Nishanth, I think this series should (still) go along with
>> > it to keep things simple.
>> >
>> > Kevin
>> 
>> Right, that makes perfect sense to me too. If we discover conflicts,
>> let's deal with them then.
>
>
> oops.. I missed this response. OK, I will let things be.
>

Oops, 0day bot found a build error in linux-next when CONFIG_PM_SLEEP is
not defined[1].  Need to respin to fix this.

v5 coming right up....

Kevin

[1] https://lore.kernel.org/all/CA+G9fYtioQ22nVr9m22+qyMqUNRsGdA=cFw_j1OUv=x8Pcs-bw@mail.gmail.com/

Re: [PATCH v4 0/3] pmdomain: ti_sci: collect and send low-power mode constraints

[Nishanth Menon]

On 08:35-20241101, Kevin Hilman wrote:
> Nishanth Menon <nm@ti.com> writes:
> 
> > On 11:11-20241031, Ulf Hansson wrote:
> >> On Wed, 30 Oct 2024 at 20:43, Kevin Hilman <khilman@baylibre.com> wrote:
> >> >
> >> > Ulf Hansson <ulf.hansson@linaro.org> writes:
> >> >
> >> > > On Wed, 30 Oct 2024 at 14:01, Nishanth Menon <nm@ti.com> wrote:
> >> > >>
> >> > >> Hi Kevin Hilman,
> >> > >>
> >> > >> On Fri, 06 Sep 2024 09:14:48 -0700, Kevin Hilman 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.
> >> > >> >
> >> > >> > [...]
> >> > >>
> >> > >> I have applied the following to branch ti-drivers-soc-next on [1].
> >> > >> Thank you!
> >> > >>
> >> > >> Ulf, based on your ack[2], I have assumed that you want me to pick
> >> > >> this series up. Let me know if that is not the case and I can drop the
> >> > >> series.
> >> > >
> >> > > Well, that was a while ago. The reason was because there was a
> >> > > dependency to another series [2], when this was posted.
> >> > >
> >> > > If that's not the case anymore, I think it's better to funnel this via
> >> > > my pmdomain tree. Please let me know how to proceed.
> >> >
> >> > The build-time dependency on [2] still exists, and since that was just
> >> > queued up by Nishanth, I think this series should (still) go along with
> >> > it to keep things simple.
> >> >
> >> > Kevin
> >> 
> >> Right, that makes perfect sense to me too. If we discover conflicts,
> >> let's deal with them then.
> >
> >
> > oops.. I missed this response. OK, I will let things be.
> >
> 
> Oops, 0day bot found a build error in linux-next when CONFIG_PM_SLEEP is
> not defined[1].  Need to respin to fix this.
> 
> v5 coming right up....
> 
> Kevin
> 
> [1] https://lore.kernel.org/all/CA+G9fYtioQ22nVr9m22+qyMqUNRsGdA=cFw_j1OUv=x8Pcs-bw@mail.gmail.com/

Kevin,

Unfortunately, I have chosen to drop the series. We are too late in
the window to take the updated series and wait for new regression
reports. On the flip side, this will clean up the flow for Ulf to take
your V5 since the dependent series should ideally hit rc1 by then.

Thanks for addressing the report fast.

-- 
Regards,
Nishanth Menon
Key (0xDDB5849D1736249D) / Fingerprint: F8A2 8693 54EB 8232 17A3  1A34 DDB5 849D 1736 249D

Re: [PATCH v4 0/3] pmdomain: ti_sci: collect and send low-power mode constraints

[Kevin Hilman]

Nishanth Menon <nm@ti.com> writes:

> On 08:35-20241101, Kevin Hilman wrote:
>> Nishanth Menon <nm@ti.com> writes:
>> 
>> > On 11:11-20241031, Ulf Hansson wrote:
>> >> On Wed, 30 Oct 2024 at 20:43, Kevin Hilman <khilman@baylibre.com> wrote:
>> >> >
>> >> > Ulf Hansson <ulf.hansson@linaro.org> writes:
>> >> >
>> >> > > On Wed, 30 Oct 2024 at 14:01, Nishanth Menon <nm@ti.com> wrote:
>> >> > >>
>> >> > >> Hi Kevin Hilman,
>> >> > >>
>> >> > >> On Fri, 06 Sep 2024 09:14:48 -0700, Kevin Hilman 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.
>> >> > >> >
>> >> > >> > [...]
>> >> > >>
>> >> > >> I have applied the following to branch ti-drivers-soc-next on [1].
>> >> > >> Thank you!
>> >> > >>
>> >> > >> Ulf, based on your ack[2], I have assumed that you want me to pick
>> >> > >> this series up. Let me know if that is not the case and I can drop the
>> >> > >> series.
>> >> > >
>> >> > > Well, that was a while ago. The reason was because there was a
>> >> > > dependency to another series [2], when this was posted.
>> >> > >
>> >> > > If that's not the case anymore, I think it's better to funnel this via
>> >> > > my pmdomain tree. Please let me know how to proceed.
>> >> >
>> >> > The build-time dependency on [2] still exists, and since that was just
>> >> > queued up by Nishanth, I think this series should (still) go along with
>> >> > it to keep things simple.
>> >> >
>> >> > Kevin
>> >> 
>> >> Right, that makes perfect sense to me too. If we discover conflicts,
>> >> let's deal with them then.
>> >
>> >
>> > oops.. I missed this response. OK, I will let things be.
>> >
>> 
>> Oops, 0day bot found a build error in linux-next when CONFIG_PM_SLEEP is
>> not defined[1].  Need to respin to fix this.
>> 
>> v5 coming right up....
>> 
>> Kevin
>> 
>> [1] https://lore.kernel.org/all/CA+G9fYtioQ22nVr9m22+qyMqUNRsGdA=cFw_j1OUv=x8Pcs-bw@mail.gmail.com/
>
> Kevin,
>
> Unfortunately, I have chosen to drop the series. We are too late in
> the window to take the updated series and wait for new regression
> reports. On the flip side, this will clean up the flow for Ulf to take
> your V5 since the dependent series should ideally hit rc1 by then.
>
> Thanks for addressing the report fast.

OK, thanks Nishanth,

I'll work this series through Ulf's pmdomain tree for the next merge
window.

Kevin

Re: [PATCH v4 0/3] pmdomain: ti_sci: collect and send low-power mode constraints

[Nishanth Menon]

On 12:43-20241030, Kevin Hilman wrote:
> Ulf Hansson <ulf.hansson@linaro.org> writes:
> 
> > On Wed, 30 Oct 2024 at 14:01, Nishanth Menon <nm@ti.com> wrote:
> >>
> >> Hi Kevin Hilman,
> >>
> >> On Fri, 06 Sep 2024 09:14:48 -0700, Kevin Hilman 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.
> >> >
> >> > [...]
> >>
> >> I have applied the following to branch ti-drivers-soc-next on [1].
> >> Thank you!
> >>
> >> Ulf, based on your ack[2], I have assumed that you want me to pick
> >> this series up. Let me know if that is not the case and I can drop the
> >> series.
> >
> > Well, that was a while ago. The reason was because there was a
> > dependency to another series [2], when this was posted.
> >
> > If that's not the case anymore, I think it's better to funnel this via
> > my pmdomain tree. Please let me know how to proceed.
> 
> The build-time dependency on [2] still exists, and since that was just
> queued up by Nishanth, I think this series should (still) go along with
> it to keep things simple.

Ulf, are you OK with this? If not, I will drop this series from my tree
(we will have to skip this cycle) and do the regular merge via your tree
once the dependency hits master on rc1.

-- 
Regards,
Nishanth Menon
Key (0xDDB5849D1736249D) / Fingerprint: F8A2 8693 54EB 8232 17A3  1A34 DDB5 849D 1736 249D