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 4/8] PM / OPP: Pass struct dev_pm_opp_supply to _set_opp_voltage()
Date: Tue, 25 Oct 2016 13:26:00 -0700 [thread overview]
Message-ID: <20161025202600.GX26139@codeaurora.org> (raw)
In-Reply-To: <20161025034554.GB9162@vireshk-i7>
On 10/25, Viresh Kumar wrote:
> On 24-10-16, 16:14, Stephen Boyd wrote:
> > On 10/20, Viresh Kumar wrote:
> > > Pass the entire supply structure instead of all of its fields.
> > >
> > > Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
> > > ---
> >
> > This patch should be combined with the previous one.
>
> I think it is a fair to do this separately as this is a completely different
> logical change.
Let's agree to disagree.
>
> > I'm still
> > not sure if it even makes sense to do this though.
>
> :)
>
> > Do we really
> > have to make duplicate "OPP snapshot" structures just because of
> > how OPPs use RCU?
>
> I agree. With RCU, yes this change is probably required. But I am not sure if
> RCU fits that well to OPP core anymore. A rw-lock may be much easier to help.
>
For things like AVS we'll probably want to do that, although it's
sort of funny because replacing RCU with rw-locks is the opposite
direction most people go. With AVS we would be updating the
voltage(s) in use for the current OPP, and we would want that
update to block any OPP transition until the voltage is adjusted.
I don't know how we would do that with RCU very well. Plus, RCU
is for reader heavy things, but we mostly have one or two
readers.
I guess it's ok for now to do all this copying, but it feels like
we'll need to undo a large portion of it later with things like
AVS. Or at least we'll be doing copies for almost no reason
because we'll want to hold the read lock across the whole OPP
transition. I was going to suggest we pass around information
about what we want to grab from the RCU protected data
structures, think index of regulator, etc. and then have small
RCU read-side critical sections to grab that info during the OPP
transition but I'm not sure that's any better. It might be worse
because the OPP could change during the OPP transition and we
could be using half of the old and half of the new data.
--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
next prev parent reply other threads:[~2016-10-25 20:26 UTC|newest]
Thread overview: 32+ 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
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 [this message]
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-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
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=20161025202600.GX26139@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).