On 01/13, Viresh Kumar wrote:
> On 13-01-17, 00:52, Stephen Boyd wrote:
> > What still doesn't make sense is how an individual OPP could go
> > away without the table that the OPP lives in also going away.
>
> dev_pm_opp_remove() is one such option, which can remove OPPs
> individually. Over that,
On 13-01-17, 00:52, Stephen Boyd wrote:
> What still doesn't make sense is how an individual OPP could go
> away without the table that the OPP lives in also going away.
dev_pm_opp_remove() is one such option, which can remove OPPs
individually. Over that, while remove tables we remove all the OPP
On 01/10, Viresh Kumar wrote:
> On 09-01-17, 15:44, Stephen Boyd wrote:
> > On 12/07, Viresh Kumar wrote:
> > > Add kref to struct dev_pm_opp for easier accounting of the OPPs.
> > >
> > > Note that the OPPs are freed under the opp_table->lock mutex only.
> >
> > I'm lost. Why add another level o
On 09-01-17, 15:44, Stephen Boyd wrote:
> On 12/07, Viresh Kumar wrote:
> > Add kref to struct dev_pm_opp for easier accounting of the OPPs.
> >
> > Note that the OPPs are freed under the opp_table->lock mutex only.
>
> I'm lost. Why add another level of krefs?
Heh. The earlier krefs were for th
On 12/07, Viresh Kumar wrote:
> Add kref to struct dev_pm_opp for easier accounting of the OPPs.
>
> Note that the OPPs are freed under the opp_table->lock mutex only.
I'm lost. Why add another level of krefs?
--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundat
Add kref to struct dev_pm_opp for easier accounting of the OPPs.
Note that the OPPs are freed under the opp_table->lock mutex only.
Signed-off-by: Viresh Kumar
---
drivers/base/power/opp/core.c | 27 ---
drivers/base/power/opp/opp.h | 3 +++
include/linux/pm_opp.h
6 matches
Mail list logo
