All of lore.kernel.org
 help / color / mirror / Atom feed
From: Stephen Boyd <sboyd@codeaurora.org>
To: Viresh Kumar <viresh.kumar@linaro.org>
Cc: Rafael Wysocki <rjw@rjwysocki.net>,
	nm@ti.com, Viresh Kumar <vireshk@kernel.org>,
	linaro-kernel@lists.linaro.org, linux-pm@vger.kernel.org,
	linux-kernel@vger.kernel.org,
	Vincent Guittot <vincent.guittot@linaro.org>,
	robh@kernel.org, d-gerlach@ti.com, broonie@kernel.org
Subject: Re: [PATCH V2 6/8] PM / OPP: Separate out _generic_opp_set_rate()
Date: Tue, 25 Oct 2016 11:59:07 -0700	[thread overview]
Message-ID: <20161025185907.GU26139@codeaurora.org> (raw)
In-Reply-To: <219e9ed658b4cef58ffeed09ac36af20523c7a46.1476952750.git.viresh.kumar@linaro.org>

On 10/20, Viresh Kumar wrote:
> Later patches would add support for custom opp_set_rate callbacks. This

I know the OPP consumer function has "rate" in the name, but it
makes more sense to call the callback set_opp instead because we
could be doing a lot more than setting the opp rate.

> patch separates out the code for generic opp_set_rate handler in order
> to prepare for that.
> 
> Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
> ---
> diff --git a/drivers/base/power/opp/core.c b/drivers/base/power/opp/core.c
> index 45c70ce07864..96f04392daef 100644
> --- a/drivers/base/power/opp/core.c
> +++ b/drivers/base/power/opp/core.c
> @@ -596,6 +596,73 @@ static int _set_opp_voltage(struct device *dev, struct regulator *reg,
>  	return ret;
>  }
>  
> +static inline int
> +_generic_opp_set_rate_clk_only(struct device *dev, struct clk *clk,
> +			       unsigned long old_freq, unsigned long freq)
> +{
> +	int ret;
> +
> +	/* Change frequency */
> +	dev_dbg(dev, "%s: switching OPP: %lu Hz --> %lu Hz\n",
> +		__func__, old_freq, freq);

Perhaps this should stay at the beginning of OPP transitions?
Otherwise it can get confusing when multiple switching OPP
messages appear on OPP transition failures.

> +
> +	ret = clk_set_rate(clk, freq);
> +	if (ret) {
> +		dev_err(dev, "%s: failed to set clock rate: %d\n", __func__,
> +			ret);
> +	}
> +
> +	return ret;
> +}
> +
> diff --git a/drivers/base/power/opp/opp.h b/drivers/base/power/opp/opp.h
> index d3f0861f9bff..6629c53c0aa1 100644
> --- a/drivers/base/power/opp/opp.h
> +++ b/drivers/base/power/opp/opp.h
> @@ -47,22 +47,6 @@ extern struct list_head opp_tables;
>   */
>  
>  /**
> - * struct dev_pm_opp_supply - Power supply voltage/current values
> - * @u_volt:	Target voltage in microvolts corresponding to this OPP
> - * @u_volt_min:	Minimum voltage in microvolts corresponding to this OPP
> - * @u_volt_max:	Maximum voltage in microvolts corresponding to this OPP
> - * @u_amp:	Maximum current drawn by the device in microamperes
> - *
> - * This structure stores the voltage/current values for a single power supply.
> - */
> -struct dev_pm_opp_supply {
> -	unsigned long u_volt;
> -	unsigned long u_volt_min;
> -	unsigned long u_volt_max;
> -	unsigned long u_amp;
> -};
> -
> -/**
>   * struct dev_pm_opp - Generic OPP description structure
>   * @node:	opp table node. The nodes are maintained throughout the lifetime
>   *		of boot. It is expected only an optimal set of OPPs are
> diff --git a/include/linux/pm_opp.h b/include/linux/pm_opp.h
> index 0606b70a8b97..73713a8424b1 100644
> --- a/include/linux/pm_opp.h
> +++ b/include/linux/pm_opp.h
> @@ -17,6 +17,7 @@
>  #include <linux/err.h>
>  #include <linux/notifier.h>
>  
> +struct clk;

Is struct regulator also forward declared?

>  struct dev_pm_opp;
>  struct device;
>  
> @@ -24,6 +25,36 @@ enum dev_pm_opp_event {
>  	OPP_EVENT_ADD, OPP_EVENT_REMOVE, OPP_EVENT_ENABLE, OPP_EVENT_DISABLE,
>  };
>  
> +/**
> + * struct dev_pm_opp_supply - Power supply voltage/current values
> + * @u_volt:	Target voltage in microvolts corresponding to this OPP
> + * @u_volt_min:	Minimum voltage in microvolts corresponding to this OPP
> + * @u_volt_max:	Maximum voltage in microvolts corresponding to this OPP
> + * @u_amp:	Maximum current drawn by the device in microamperes
> + *
> + * This structure stores the voltage/current values for a single power supply.
> + */
> +struct dev_pm_opp_supply {
> +	unsigned long u_volt;
> +	unsigned long u_volt_min;
> +	unsigned long u_volt_max;
> +	unsigned long u_amp;
> +};

This structure moved during this series. Can we avoid that and
already have it in the right place to begin with?

> +
> +struct dev_pm_opp_info {
> +	unsigned long rate;
> +	struct dev_pm_opp_supply *supplies;
> +};
> +
> +struct dev_pm_set_rate_data {

dev_pm_set_opp_data?

> +	struct dev_pm_opp_info old_opp;
> +	struct dev_pm_opp_info new_opp;
> +
> +	struct regulator **regulators;
> +	unsigned int regulator_count;
> +	struct clk *clk;
> +};

The above two structures don't get kernel doc?

> +
>  #if defined(CONFIG_PM_OPP)
>  
>  unsigned long dev_pm_opp_get_voltage(struct dev_pm_opp *opp);
> -- 
> 2.7.1.410.g6faf27b
> 

-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project

  reply	other threads:[~2016-10-25 18:59 UTC|newest]

Thread overview: 34+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-10-20  8:44 [PATCH V2 0/8] PM / OPP: Multiple regulator support Viresh Kumar
2016-10-20  8:44 ` [PATCH V2 1/8] PM / OPP: Reword binding supporting multiple regulators per device Viresh Kumar
     [not found]   ` <891ef8705e13dff331a3135647f4c18f88402a12.1476952750.git.viresh.kumar-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
2016-10-24 22:48     ` Stephen Boyd
2016-10-24 22:48       ` Stephen Boyd
2016-10-20  8:44 ` [PATCH V2 2/8] PM / OPP: Don't use OPP structure outside of rcu protected section Viresh Kumar
2016-10-24 22:52   ` Stephen Boyd
2016-10-25  3:37     ` Viresh Kumar
2016-10-20  8:44 ` [PATCH V2 3/8] PM / OPP: Manage supply's voltage/current in a separate structure Viresh Kumar
2016-10-20  8:44 ` [PATCH V2 4/8] PM / OPP: Pass struct dev_pm_opp_supply to _set_opp_voltage() Viresh Kumar
2016-10-24 23:14   ` Stephen Boyd
2016-10-25  3:45     ` Viresh Kumar
2016-10-25 20:26       ` Stephen Boyd
2016-10-26  3:34         ` Viresh Kumar
2016-10-20  8:44 ` [PATCH V2 5/8] PM / OPP: Add infrastructure to manage multiple regulators Viresh Kumar
2016-10-21 22:32   ` Dave Gerlach
2016-10-21 22:32     ` Dave Gerlach
2016-10-24  3:35     ` Viresh Kumar
2016-10-25 16:49   ` Stephen Boyd
2016-10-26  6:05     ` Viresh Kumar
2016-11-10  1:37       ` Stephen Boyd
2016-10-20  8:45 ` [PATCH V2 6/8] PM / OPP: Separate out _generic_opp_set_rate() Viresh Kumar
2016-10-25 18:59   ` Stephen Boyd [this message]
2016-10-26  6:07     ` Viresh Kumar
2016-10-20  8:45 ` [PATCH V2 7/8] PM / OPP: Allow platform specific custom opp_set_rate() callbacks Viresh Kumar
2016-10-25 19:01   ` Stephen Boyd
2016-10-26  6:07     ` Viresh Kumar
2016-10-20  8:45 ` [PATCH V2 8/8] PM / OPP: Don't WARN on multiple calls to dev_pm_opp_set_regulators() Viresh Kumar
2016-10-25 19:01   ` Stephen Boyd
2016-10-21 13:39 ` [PATCH V2 0/8] PM / OPP: Multiple regulator support Rafael J. Wysocki
2016-10-21 15:40   ` Viresh Kumar
2016-10-24  1:08     ` Dave Gerlach
2016-10-24  4:26       ` Viresh Kumar
2016-10-25 21:13         ` Dave Gerlach
2016-10-26  3:21           ` Viresh Kumar

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=20161025185907.GU26139@codeaurora.org \
    --to=sboyd@codeaurora.org \
    --cc=broonie@kernel.org \
    --cc=d-gerlach@ti.com \
    --cc=linaro-kernel@lists.linaro.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-pm@vger.kernel.org \
    --cc=nm@ti.com \
    --cc=rjw@rjwysocki.net \
    --cc=robh@kernel.org \
    --cc=vincent.guittot@linaro.org \
    --cc=viresh.kumar@linaro.org \
    --cc=vireshk@kernel.org \
    /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.