From: Viresh Kumar <viresh.kumar@linaro.org>
To: Stephen Boyd <sboyd@codeaurora.org>
Cc: Rafael Wysocki <rjw@rjwysocki.net>,
jy0922.shim@samsung.com, Viresh Kumar <vireshk@kernel.org>,
Nishanth Menon <nm@ti.com>,
linaro-kernel@lists.linaro.org, linux-pm@vger.kernel.org,
linux-kernel@vger.kernel.org, stable@vger.kernel.org
Subject: Re: [PATCH] PM / OPP: Allow inactive opp_device to be present in dev list
Date: Tue, 29 Nov 2016 09:25:31 +0530 [thread overview]
Message-ID: <20161129035531.GC3288@vireshk-i7> (raw)
In-Reply-To: <20161129024647.GY6095@codeaurora.org>
On 28-11-16, 18:46, Stephen Boyd wrote:
> That's a lot of lines for something that we want to backport to
> stable kernels!
Hmm, I agree.
> The whole dev_list design seems fairly broken to me. Another
> solution would be to iterate the cpumask in reverse, but there
> doesn't seem to be a construct for that and adding one is
> probably not worth the effort.
>
> Adding yet another member to the structure and doing accounting
> in different places seems to be papering over the problem as
> well. Now we want to have "inactive" devices in the list? That
> seems like a problem for cpufreq to solve. It can decide to not
> call OPP APIs when the cpu device isn't actually physically
> removed if it wants to.
>
> It also exposes the OPP API's strong reliance on struct device
> for everything. Really we shouldn't be storing device pointers in
> the OPP core at all because we're not treating them like the
> reference counted objects they are. The dev_list should go
> probably go away and be replaced with some sort of counter. It
> would also be nice if struct device had a pointer to the OPP
> table(s) for a device so the lookup is direct.
If the struct device gets a pointer to the opp-table, then yes we can kill the
dev-list completely. I will work on cleaning up OPP core a bit later on.
> BTW, _dev_pm_opp_remove_table() calls _find_opp_dev() twice, once
> to find the opp_table for a device and then to find the
> opp_device inside the table that was used to match up the table
> in the first place. Madness!
>
> Anyway, rant over, how about handing out the opp table pointer to
> the caller so they can pass it back in when they call the put
> side? That should fix the same problem if I understand correctly.
Yes, that can be a solution for the time being.
> We should think about changing the API further so that callers
> have to "get" the OPP table cookie for their device and then pass
> that pointer to the dev_pm_*_set() APIs instead of passing a
> struct device pointer. That would save lots of cycles searching
> for something we already had.
Hmm, we need to do some cleanup soon I believe. Also note that we want to kill
the RCU thing :)
> -static inline void dev_pm_opp_put_regulator(struct device *dev) {}
> +static inline void dev_pm_opp_put_regulator(struct opp_table *opp_table) {}
We need to modify few more things as well. I will send a patch for that soon.
--
viresh
next prev parent reply other threads:[~2016-11-29 3:55 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <CGME20161125065330epcas1p23c3bc3b47fde680f84d3b7c3252ad9ed@epcas1p2.samsung.com>
2016-11-25 6:53 ` [PATCH] PM / OPP: Allow inactive opp_device to be present in dev list Viresh Kumar
2016-11-25 6:55 ` Viresh Kumar
2016-11-25 15:55 ` Rafael J. Wysocki
2016-11-25 7:28 ` Joonyoung Shim
2016-11-29 2:46 ` Stephen Boyd
2016-11-29 3:55 ` Viresh Kumar [this message]
2016-11-29 5:11 ` Viresh Kumar
2016-11-29 20:56 ` Stephen Boyd
2016-11-30 1:36 ` Viresh Kumar
2016-11-30 5:33 ` 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=20161129035531.GC3288@vireshk-i7 \
--to=viresh.kumar@linaro.org \
--cc=jy0922.shim@samsung.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=sboyd@codeaurora.org \
--cc=stable@vger.kernel.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.