All of lore.kernel.org
 help / color / mirror / Atom feed
From: Kevin Hilman <khilman@baylibre.com>
To: Ulf Hansson <ulf.hansson@linaro.org>
Cc: linux-pm@vger.kernel.org, Nishanth Menon <nm@ti.com>,
	Vibhore Vardhan <vibhore@ti.com>, Dhruva Gole <d-gole@ti.com>,
	Akashdeep Kaur <a-kaur@ti.com>,
	Sebin Francis <sebin.francis@ti.com>,
	Markus Schneider-Pargmann <msp@baylibre.com>,
	linux-arm-kernel@lists.infradead.org,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH v2 1/3] pmdomain: ti_sci: add per-device latency constraint management
Date: Thu, 05 Sep 2024 14:57:47 -0700	[thread overview]
Message-ID: <7hv7z9ahlw.fsf@baylibre.com> (raw)
In-Reply-To: <CAPDyKFrCyvSLYh9DoC661M-2D33oU9x5tFOe+Oem04V5KfqG3A@mail.gmail.com>

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

> On Tue, 20 Aug 2024 at 02:00, Kevin Hilman <khilman@baylibre.com> wrote:
>>
>> 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>
>> Signed-off-by: Kevin Hilman <khilman@baylibre.com>
>> Signed-off-by: Dhruva Gole <d-gole@ti.com>
>> ---
>>  drivers/pmdomain/ti/ti_sci_pm_domains.c | 48 ++++++++++++++++++++++++++++++++++++++++++++++++
>>  1 file changed, 48 insertions(+)
>>
>> diff --git a/drivers/pmdomain/ti/ti_sci_pm_domains.c b/drivers/pmdomain/ti/ti_sci_pm_domains.c
>> index 1510d5ddae3d..963272fa387b 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,29 @@ 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;
>> +}
>
> Should we perhaps add a generic helper function for this? Seems like a
> similar check is done at other places in the kernel too.

Maybe, but I don't see a lot of this same usage under drivers/*.  But
I'll have a closer look for a follow-up patch that might be able to make
a common helper for this.

>> +
>> +static int ti_sci_pd_set_lat_constraint(struct device *dev, s32 val)
>> +{
>
> Looks like you may want to turn this into a static void rather than
> static int. At least the caller, below, doesn't care about the return
> value.

Yup, OK.

>> +       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);
>> +
>> +       return ret;
>> +}
>> +
>>  /*
>>   * ti_sci_pd_power_off(): genpd power down hook
>>   * @domain: pointer to the powerdomain to power off
>> @@ -79,6 +104,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 +229,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
>>
>
> Other than the minor things above, this looks good to me.

Thanks for the review!   Will spin a v3 shortly.

Kevin

  reply	other threads:[~2024-09-05 21:57 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-08-20  0:00 [PATCH v2 0/3] pmdomain: ti_sci: collect and send low-power mode constraints Kevin Hilman
2024-08-20  0:00 ` [PATCH v2 1/3] pmdomain: ti_sci: add per-device latency constraint management Kevin Hilman
2024-08-20  9:04   ` kernel test robot
2024-08-20 10:27   ` kernel test robot
2024-09-05 11:30   ` Ulf Hansson
2024-09-05 21:57     ` Kevin Hilman [this message]
2024-08-20  0:00 ` [PATCH v2 2/3] pmdomain: ti_sci: add wakeup " Kevin Hilman
2024-09-05 11:31   ` Ulf Hansson
2024-09-05 21:58     ` Kevin Hilman
2024-08-20  0:00 ` [PATCH v2 3/3] pmdomain: ti_sci: handle wake IRQs for IO daisy chain wakeups Kevin Hilman
2024-08-20 10:07 ` [PATCH v2 0/3] pmdomain: ti_sci: collect and send low-power mode constraints Dhruva Gole
2024-09-05 11:38 ` Ulf Hansson
2024-09-05 22:07   ` Kevin Hilman
2024-09-06  9:00     ` Ulf Hansson

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=7hv7z9ahlw.fsf@baylibre.com \
    --to=khilman@baylibre.com \
    --cc=a-kaur@ti.com \
    --cc=d-gole@ti.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-pm@vger.kernel.org \
    --cc=msp@baylibre.com \
    --cc=nm@ti.com \
    --cc=sebin.francis@ti.com \
    --cc=ulf.hansson@linaro.org \
    --cc=vibhore@ti.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.