[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAKohpo=RWi1nRUJq4qx8K+Y7swMDaqwEOH24-KfBCMgdbW=hMQ@mail.gmail.com>
Date: Fri, 22 Nov 2013 18:22:52 +0530
From: Viresh Kumar <viresh.kumar@...aro.org>
To: "Rafael J. Wysocki" <rjw@...ysocki.net>,
Stephen Warren <swarren@...dia.com>,
Kukjin Kim <kgene@...nel.org>,
Amit Daniel Kachhap <amit.daniel@...sung.com>,
Sachin Kamat <sachin.kamat@...aro.org>
Cc: Lists linaro-kernel <linaro-kernel@...ts.linaro.org>,
Patch Tracking <patches@...aro.org>,
"cpufreq@...r.kernel.org" <cpufreq@...r.kernel.org>,
"linux-pm@...r.kernel.org" <linux-pm@...r.kernel.org>,
Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
Lan Tianyu <tianyu.lan@...el.com>, Nishanth Menon <nm@...com>,
jinchoi@...adcom.com,
Sebastian Capella <sebastian.capella@...aro.org>
Subject: Re: [PATCH V2 2/2] cpufreq: Change freq before suspending governors
On 22 November 2013 18:07, Rafael J. Wysocki <rjw@...ysocki.net> wrote:
> On Friday, November 22, 2013 04:59:49 PM Viresh Kumar wrote:
>> Some platforms might want to change frequency before suspending governors. Like:
>> - Some platform which want to set freq to max to speed up suspend/hibernation
>> process.
>> - Some platform (like: Tegra or exynos), set this to min or bootloader's
>> frequency.
>>
>> This patch adds an option for those, so that they can specify this at call to
>> ->init(), so that cpufreq core can take care of this before suspending system.
>>
>> If this variable is not updated by ->init() then its value would be zero and so
>> core wouldn't do anything.
>>
>> Signed-off-by: Viresh Kumar <viresh.kumar@...aro.org>
>
> I don't think this is generally necessary, because the suspend/resume routines
> added by patch [1/2] will be executed very late during suspend or very early
> during resume and it shouldn't really matter what performance levels the CPUs
> are at then.
There are few things here:
- I feel that the current place from where we have suspended stuff is not gonna
fly. We are doing that in noirq and probably devices which might be required
during frequency transitions might already be down.. So we *may* need to
move that in dpm_suspend()..
- Secondly I want to understand why Tegra/Exynos has such code which I
mentioned above..
@Stephen, Kukjin and other samsung folks: Please provide some input here,
before your systems break in mainline :)
> The only exception *may* be hibernation, because the amount of time needed to
> create the image will depend on the current performance level of the boot CPU,
> but that should be an explicitly special case in my opinion.
Hmm.. That looks sensible if there is nothing special required for Tegra/Exynos.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists