On 11/30/2016 05:05 PM, Viresh Kumar wrote:

On 30-11-16, 15:19, Joonyoung Shim wrote:

quoted

Hi Viresh,

On 11/30/2016 12:59 PM, Viresh Kumar wrote:

quoted

From: Stephen Boyd <redacted>

Joonyoung Shim reported an interesting problem on his ARM octa-core
Odoroid-XU3 platform. During system suspend, dev_pm_opp_put_regulator()
was failing for a struct device for which dev_pm_opp_set_regulator() is
called earlier.

This happened because an earlier call to
dev_pm_opp_of_cpumask_remove_table() function (from cpufreq-dt.c file)
removed all the entries from opp_table->dev_list apart from the last CPU
device in the cpumask of CPUs sharing the OPP.

But both dev_pm_opp_set_regulator() and dev_pm_opp_put_regulator()
routines get CPU device for the first CPU in the cpumask. And so the OPP
core failed to find the OPP table for the struct device.

In order to fix that up properly, we need to revisit APIs like
dev_pm_opp_set_regulator() and make them talk in terms of cookies
provided by the OPP core. But such a solution will be hard to backport
to stable kernels.

This patch attempts to fix this problem by returning a pointer to the
opp_table from dev_pm_opp_set_regulator() and using that as the
parameter to dev_pm_opp_put_regulator(). This ensures that the
dev_pm_opp_put_regulator() doesn't fail to find the opp table.

Note that similar design problem also exists with other
dev_pm_opp_put_*() APIs, but those aren't used currently by anyone and
so we don't need to update them for now.

[Viresh]: Written commit log, minor improvements in the patch and tested
on exynos 5250.

Cc: # v4.4+ <redacted>
Reported-by: Joonyoung Shim <redacted>
Signed-off-by: Stephen Boyd <redacted>
Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
---
V3->V4:
- Completely different approach, suggested earlier by Stephen.
- Can be merged safely now as both /me and Stephen agree to this one.

@Joonyoung: Can you please test this last patch please ?

Just system suspend/resume is working

Should I consider that as a Tested-by from you for the problem you
reported at least ?

My Tested-by is ok about the original problem reported by me.

quoted

but i was missing below test case
that you inform when i test for prior patches on my Odroid-XU3 board.

- offline CPU 4
- suspend the system

With this test case, now all patches posted have the problem that is
failed to get clk: -2.

That probably happens because your DT isn't good enough. Following DT
change may fix it for you:

Already i tried and the error was gone but sometimes system resume is
halt. I'm not sure that it has any effect so i need to more dig.

Thanks.