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 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).