by Viresh Kumar

[permalink] [raw]

Subject: Re: [PATCH V2 6/8] PM / OPP: Separate out _generic_opp_set_rate()

On 25-10-16, 11:59, Stephen Boyd wrote:
> 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.

Done.

> > patch separates out the code for generic opp_set_rate handler in order
> > to prepare for that.
> >
> > Signed-off-by: Viresh Kumar <[email protected]>
> > ---
> > 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.

Done.

> > +struct clk;
>
> Is struct regulator also forward declared?

Done now.

> > 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?

Done.

> > +
> > +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?

Done.

> > + 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?

Done.

--
viresh

2016-11-10 01:37:04

by Stephen Boyd

[permalink] [raw]

Subject: Re: [PATCH V2 5/8] PM / OPP: Add infrastructure to manage multiple regulators

On 10/26, Viresh Kumar wrote:
> On 25-10-16, 09:49, Stephen Boyd wrote:
> > On 10/20, Viresh Kumar wrote:
> > > diff --git a/drivers/base/power/opp/core.c b/drivers/base/power/opp/core.c
> > > index 37fad2eb0f47..45c70ce07864 100644
> > > --- a/drivers/base/power/opp/core.c
> > > +++ b/drivers/base/power/opp/core.c
> > > @@ -235,21 +237,44 @@ unsigned long dev_pm_opp_get_max_volt_latency(struct device *dev)
> > > return 0;
> > > }
> > >
> > > - reg = opp_table->regulator;
> > > - if (IS_ERR(reg)) {
> > > + count = opp_table->regulator_count;
> > > +
> > > + if (!count) {
> > > /* Regulator may not be required for device */
> > > rcu_read_unlock();
> > > return 0;
> > > }
> > >
> > > - list_for_each_entry_rcu(opp, &opp_table->opp_list, node) {
> > > - if (!opp->available)
> > > - continue;
> > > + size = count * sizeof(*regulators);
> > > + regulators = kmemdup(opp_table->regulators, size, GFP_KERNEL);
> >
> > How do we allocate under RCU? Doesn't that spit out big warnings?
>
> That doesn't. I even tried enabling several locking debug config options.

Please read RCU documentation. From rcu_read_lock() function
documentation:

In non-preemptible RCU implementations (TREE_RCU and TINY_RCU),
it is illegal to block while in an RCU read-side critical section.
In preemptible RCU implementations (TREE_PREEMPT_RCU) in CONFIG_PREEMPT
kernel builds, RCU read-side critical sections may be preempted,
but explicit blocking is illegal. Finally, in preemptible RCU
implementations in real-time (with -rt patchset) kernel builds, RCU
read-side critical sections may be preempted and they may also block, but
only when acquiring spinlocks that are subject to priority inheritance.

I suppose that in certain configurations it will warn and in
others it won't. I thought lockdep would always complain though,
so that's sad it doesn't. At least in some implementations of RCU
rcu_read_lock() is the same as preempt_disable(), which basically
means no sleeping calls like GFP_KERNEL allocations.

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