* Re: [PATCH 0/3] coupled cpuidle state support
From: Shilimkar, Santosh @ 2011-12-22 8:35 UTC (permalink / raw)
To: Colin Cross
Cc: Kevin Hilman, Len Brown, linux-kernel, Amit Kucheria, linux-tegra,
linux-pm, linux-omap, Arjan van de Ven, linux-arm-kernel
In-Reply-To: <CAMbhsRSPCo9MSGp57Fv0sRdYUFcdwx8jEz1-CfX8LdKf8X4MVg@mail.gmail.com>
On Thu, Dec 22, 2011 at 1:12 AM, Colin Cross <ccross@android.com> wrote:
> On Wed, Dec 21, 2011 at 11:36 AM, Arjan van de Ven
> <arjan@linux.intel.com> wrote:
>>>>
>>>> .. or it enters WFI, and a physical device sends it an interrupt,
>>>> at which point it exits.
>>>
>>> None of the cpus will return to the idle loop until all cpus have
>>> decremented the ready counter back to 0, so they can't wrap around
>>> again.
>>
>>
>> yikes, so you IPI all the cpus on the first exit.
>> that must burn power ;-(
>
> No, you're not understanding the point of this series.
>
> If your cpus can go in and out of idle independently, you don't use
> this code at all. Each cpu can call WFI and come back out without
> talking to the other cpu.
>
Indeed. The SOCs, Arch's which does support low power
state independently and doesn't need any co-ordination between CPU's
will continue to work same way as before with this series.
> However, if you have two cpus that share some part of the SoC that can
> be turned off in idle, like the L2 cache controller or the system bus,
> the two cpus need to go to idle together, and they will both boot
> together when either one receives an interrupt (although one will
> likely immediately go back to a shallower state that doesn't require
> coordination with the other cpu). There is no way around this, it's
> how the hardware works on some ARM platforms.
Apart from shared peripherals which Colin pointed out, OMAP also
brings in the security software state which is kind of executing in
parallel with linux. This state is lost in certain deeper low power
states and since the security software is affine to only master CPU
(because of OMAP security architecture), the co-ordination is
mandatory to achieve those low power states.
So this additional CPU co-ordination logic for such C-states
really helps to solve the issue in most generic way.
Regards
Santosh
^ permalink raw reply
* Re: [PATCH 0/3] coupled cpuidle state support
From: Arjan van de Ven @ 2011-12-22 8:53 UTC (permalink / raw)
To: Shilimkar, Santosh
Cc: Kevin Hilman, Len Brown, linux-kernel, Amit Kucheria, Colin Cross,
linux-tegra, linux-pm, linux-omap, linux-arm-kernel
In-Reply-To: <CAMQu2gxws83BUdj_eMbF0xpA1Mo_OA_MswE7KUm5pvbn3YbMuQ@mail.gmail.com>
On 12/22/2011 9:35 AM, Shilimkar, Santosh wrote:
> Indeed. The SOCs, Arch's which does support low power
> state independently and doesn't need any co-ordination between CPU's
> will continue to work same way as before with this series.
btw I think you misunderstand; I don't object to a need for something
like this, I am just very concerned that this may not be possible to be
done in a race-free way.
^ permalink raw reply
* Re: [PATCH 0/3] coupled cpuidle state support
From: Shilimkar, Santosh @ 2011-12-22 9:30 UTC (permalink / raw)
To: Arjan van de Ven
Cc: Kevin Hilman, Len Brown, linux-kernel, Amit Kucheria, Colin Cross,
linux-tegra, linux-pm, linux-omap, linux-arm-kernel
In-Reply-To: <4EF2F01E.8060307@linux.intel.com>
On Thu, Dec 22, 2011 at 2:23 PM, Arjan van de Ven <arjan@linux.intel.com> wrote:
> On 12/22/2011 9:35 AM, Shilimkar, Santosh wrote:
>
>> Indeed. The SOCs, Arch's which does support low power
>> state independently and doesn't need any co-ordination between CPU's
>> will continue to work same way as before with this series.
>
> btw I think you misunderstand; I don't object to a need for something
> like this,
I did. Thanks for clarification.
> I am just very concerned that this may not be possible to be
> done in a race-free way.
>
I agree to those races but may be they are harmless.
Also the safe state need not be just WFI and can be bit deeper
where the co-ordination between isn't necessary. So that should
still not burn the power that much.
For simplicity let's assume a two CPU scenario.
Ideal scenario:
CPU 1 has entered idle and incremented counter for the
co-ordinated C state. CPU0 also enter and increments the
counter and now the subsystem and interconnect can go
down along with CPU cluster.
Few of the race conditions will possibly lead to void
the above conditions and in that case the counter would
reflect that and such a C-state won't be attempted and
a safe C-state would be attempted. That should still work
fine.
Some how this hardware/security restriction is bit stupid
and likely going against the existing CPUIDLE design
which expect that a CPUIDLE thread are per CPU and it should
be independent and local to that CPU.
Regards
Santosh
^ permalink raw reply
* Re: [PATCH 0/3] coupled cpuidle state support
From: Colin Cross @ 2011-12-22 21:20 UTC (permalink / raw)
To: Arjan van de Ven
Cc: Kevin Hilman, Len Brown, linux-kernel, Amit Kucheria, linux-tegra,
linux-pm, linux-omap, linux-arm-kernel
In-Reply-To: <4EF2F01E.8060307@linux.intel.com>
On Thu, Dec 22, 2011 at 12:53 AM, Arjan van de Ven
<arjan@linux.intel.com> wrote:
> On 12/22/2011 9:35 AM, Shilimkar, Santosh wrote:
>
>> Indeed. The SOCs, Arch's which does support low power
>> state independently and doesn't need any co-ordination between CPU's
>> will continue to work same way as before with this series.
>
> btw I think you misunderstand; I don't object to a need for something
> like this, I am just very concerned that this may not be possible to be
> done in a race-free way.
I agree that there are many potential races in this code, but I
believe I've handled all of them. This patch set is a refactoring of
the common parts of the SMP idle code that has shipped on Tegra and
OMAP4 devices, so the basic idea has been hammered on extensively.
I think I've explained the protection against the race condition you
asked about earlier. As for the power impact, the power savings of
getting into the deeper coupled power states far outweighs the cost of
booting all coupled cpus out of idle and letting them loop back to a
shallower idle state.
On an OMAP4 platform, at the slowest cpu speed, the system-wide power
usage with both cpus in the non-coupled state (WFI) is around 50 mA,
while the deepest coupled state is 12 mA. At the fastest cpu speed,
WFI is over 100 mA.
On some platforms it may be possible to have only one cpu boot out of
idle when an interrupt arrives, but that introduces the race condition
you asked about before, where the last cpu tries to go into idle at
the same time that an already-idle cpu comes back out. This way has
fairly minimal overhead (booting the 2nd cpu and then going to WFI),
and that's a path that already needs to be fast because it's part of
the normal single-cpu idle path.
^ permalink raw reply
* Re: [PATCH] PM / Hibernate: Improve performance of LZO/plain hibernation, checksum image
From: Barry Song @ 2011-12-27 12:27 UTC (permalink / raw)
To: bojan, rjw; +Cc: linux-pm, LKML, DL-SHA-WorkGroupLinux
> Use threads for LZO compression/decompression on hibernate/thaw.
> Improve buffering on hibernate/thaw.
> Calculate/verify CRC32 of the image pages on hibernate/thaw.
> In my testing, this improved write/read speed by a factor of about two.
> Signed-off-by: Bojan Smojver <bojan@rexursive.com>
> Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
hi Bojan,
this patch is definitely great!
any plan to write the same patch for decompress and restore? i think
that is probably more important than compression and hibernation to
improve bootup speed.
Thanks
barry
^ permalink raw reply
* Re: [PATCH] PM / Hibernate: Improve performance of LZO/plain hibernation, checksum image
From: Bojan Smojver @ 2011-12-28 23:40 UTC (permalink / raw)
To: Barry Song; +Cc: linux-pm, LKML, DL-SHA-WorkGroupLinux
In-Reply-To: <CAGsJ_4yXU62GZ38fe7TCH8uKLHJvZ8jtFbJLywqv1kgC7y9V_A@mail.gmail.com>
On Tue, 2011-12-27 at 20:27 +0800, Barry Song wrote:
> this patch is definitely great!
Thanks, I'm glad you liked it.
> any plan to write the same patch for decompress and restore? i think
> that is probably more important than compression and hibernation to
> improve bootup speed.
I'm not sure I understand what you mean here. Can you elaborate?
--
Bojan
^ permalink raw reply
* Re: [PATCH] PM / Hibernate: Improve performance of LZO/plain hibernation, checksum image
From: Barry Song @ 2011-12-29 2:37 UTC (permalink / raw)
To: Bojan Smojver; +Cc: linux-pm, LKML, DL-SHA-WorkGroupLinux
In-Reply-To: <1325115628.2029.1.camel@shrek.rexursive.com>
2011/12/29 Bojan Smojver <bojan@rexursive.com>:
> On Tue, 2011-12-27 at 20:27 +0800, Barry Song wrote:
>> this patch is definitely great!
>
> Thanks, I'm glad you liked it.
>
>> any plan to write the same patch for decompress and restore? i think
>> that is probably more important than compression and hibernation to
>> improve bootup speed.
>
> I'm not sure I understand what you mean here. Can you elaborate?
i mean we can load image and decompress them in different threads when
we reboot from hibernation.
after i read codes more carefully, that has actually been done by
lzo_decompress_threadfn().
here the problem is we didn't seem to get any faster after applying
your compression patch when doing hibernation on SD/NAND.
we are trying to figure out the reason.
>
> --
> Bojan
>
-barry
^ permalink raw reply
* Re: [PATCH] PM / Hibernate: Improve performance of LZO/plain hibernation, checksum image
From: Bojan Smojver @ 2011-12-29 2:58 UTC (permalink / raw)
To: Barry Song; +Cc: linux-pm, LKML, DL-SHA-WorkGroupLinux
In-Reply-To: <CAGsJ_4xH-9MXq8UJJFLW=upBqK+PXbWfDJhttBN=n2_M0PzMSw@mail.gmail.com>
On Thu, 2011-12-29 at 10:37 +0800, Barry Song wrote:
> i mean we can load image and decompress them in different threads when
> we reboot from hibernation. after i read codes more carefully, that
> has actually been done by lzo_decompress_threadfn().
Correct. Both hibernation and thaw are multi-threaded.
> here the problem is we didn't seem to get any faster after applying
> your compression patch when doing hibernation on SD/NAND.
> we are trying to figure out the reason.
This may depend on many factors:
- how much CPU power you have
- how many CPUs you have
- how much I/O can your disk do
Remember, there is one thread that does CRC32 as well and other threads
will have to sync with that thread.
Anyhow, it would be interesting to know where the bottleneck is on your
particular system. If you system has lots of CPU power and fast I/O, the
patch indeed may not do anything at all.
PS. I did my testing on a ThinkPad T510 laptop. It has a Core i5 M520
2.4 GHz mobile CPU (this appears to the system as 4 CPUs - it's two
physical cores with hyper-threading enabled). The disk is classic
platter based disk (Seagate ST9500420AS). There is 8 GB of RAM on this
system.
--
Bojan
^ permalink raw reply
* Re: [PATCH] PM / Hibernate: Improve performance of LZO/plain hibernation, checksum image
From: Barry Song @ 2011-12-29 3:20 UTC (permalink / raw)
To: Bojan Smojver; +Cc: linux-pm, LKML, DL-SHA-WorkGroupLinux
In-Reply-To: <1325127531.2029.13.camel@shrek.rexursive.com>
2011/12/29 Bojan Smojver <bojan@rexursive.com>:
> On Thu, 2011-12-29 at 10:37 +0800, Barry Song wrote:
>> i mean we can load image and decompress them in different threads when
>> we reboot from hibernation. after i read codes more carefully, that
>> has actually been done by lzo_decompress_threadfn().
>
> Correct. Both hibernation and thaw are multi-threaded.
>
>> here the problem is we didn't seem to get any faster after applying
>> your compression patch when doing hibernation on SD/NAND.
>> we are trying to figure out the reason.
>
> This may depend on many factors:
>
> - how much CPU power you have
> - how many CPUs you have
> - how much I/O can your disk do
>
> Remember, there is one thread that does CRC32 as well and other threads
> will have to sync with that thread.
>
> Anyhow, it would be interesting to know where the bottleneck is on your
> particular system. If you system has lots of CPU power and fast I/O, the
> patch indeed may not do anything at all.
>
> PS. I did my testing on a ThinkPad T510 laptop. It has a Core i5 M520
> 2.4 GHz mobile CPU (this appears to the system as 4 CPUs - it's two
> physical cores with hyper-threading enabled). The disk is classic
> platter based disk (Seagate ST9500420AS). There is 8 GB of RAM on this
> system.
well. our guys are still debugging.
the platform is ARM cortex-a9 single-core 1Ghz SoC and we save image
to a SD card or NAND.
a phenomenon we saw is that multi-BIOs is not merged into a request by
block level elevator. so the SD/NANDdisk driver handles many small
request one page by one page.
>
> --
> Bojan
>
-barry
^ permalink raw reply
* Re: [PATCH] PM / Hibernate: Improve performance of LZO/plain hibernation, checksum image
From: Bojan Smojver @ 2011-12-29 3:54 UTC (permalink / raw)
To: Barry Song; +Cc: linux-pm, LKML, DL-SHA-WorkGroupLinux
In-Reply-To: <CAGsJ_4x2yCNf48xnVzBCZLJhdUaAOfoNHx5AFamZMXgLZ0PEKw@mail.gmail.com>
On Thu, 2011-12-29 at 11:20 +0800, Barry Song wrote:
> the platform is ARM cortex-a9 single-core 1Ghz SoC and we save image
> to a SD card or NAND.
> a phenomenon we saw is that multi-BIOs is not merged into a request by
> block level elevator. so the SD/NANDdisk driver handles many small
> request one page by one page.
Interesting, thanks.
--
Bojan
^ permalink raw reply
* [PATCH] s3c_adc_battery: average over more than one adc sample
From: Heiko Stübner @ 2011-12-29 11:52 UTC (permalink / raw)
To: Anton Vorontsov, David Woodhouse
Cc: Vasily Khoruzhick, Linux PM mailing list, linux-kernel
Some sources for adc battery information provide only inaccurate results
where the read value differs from the real value with positive and negative
offsets. For such sources it can be more accurate to collect two or more
value sample and use the average of all collected values.
This patch adds pdata options volt_samples, current_samples and
backup_volt_samples to specifiy the number of samples to collect,
reads the specified number of samples and calculates the average of those.
For unset sample-number-values a default of 1 is assumed.
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
---
drivers/power/s3c_adc_battery.c | 25 ++++++++++++++++++++++---
include/linux/s3c_adc_battery.h | 4 ++++
2 files changed, 26 insertions(+), 3 deletions(-)
diff --git a/drivers/power/s3c_adc_battery.c b/drivers/power/s3c_adc_battery.c
index d32d0d7..98520a8 100644
--- a/drivers/power/s3c_adc_battery.c
+++ b/drivers/power/s3c_adc_battery.c
@@ -47,6 +47,22 @@ static void s3c_adc_bat_ext_power_changed(struct power_supply *psy)
msecs_to_jiffies(JITTER_DELAY));
}
+static int gather_samples(struct s3c_adc_client *client, int num, int channel)
+{
+ int value, i;
+
+ /* default to 1 if nothing is set */
+ if (num < 1)
+ num = 1;
+
+ value = 0;
+ for (i = 0; i < num; i++)
+ value += s3c_adc_read(client, channel);
+ value /= num;
+
+ return value;
+}
+
static enum power_supply_property s3c_adc_backup_bat_props[] = {
POWER_SUPPLY_PROP_VOLTAGE_NOW,
POWER_SUPPLY_PROP_VOLTAGE_MIN,
@@ -67,7 +83,8 @@ static int s3c_adc_backup_bat_get_property(struct power_supply *psy,
if (bat->volt_value < 0 ||
jiffies_to_msecs(jiffies - bat->timestamp) >
BAT_POLL_INTERVAL) {
- bat->volt_value = s3c_adc_read(bat->client,
+ bat->volt_value = gather_samples(bat->client,
+ bat->pdata->backup_volt_samples,
bat->pdata->backup_volt_channel);
bat->volt_value *= bat->pdata->backup_volt_mult;
bat->timestamp = jiffies;
@@ -139,9 +156,11 @@ static int s3c_adc_bat_get_property(struct power_supply *psy,
if (bat->volt_value < 0 || bat->cur_value < 0 ||
jiffies_to_msecs(jiffies - bat->timestamp) >
BAT_POLL_INTERVAL) {
- bat->volt_value = s3c_adc_read(bat->client,
+ bat->volt_value = gather_samples(bat->client,
+ bat->pdata->volt_samples,
bat->pdata->volt_channel) * bat->pdata->volt_mult;
- bat->cur_value = s3c_adc_read(bat->client,
+ bat->cur_value = gather_samples(bat->client,
+ bat->pdata->current_samples,
bat->pdata->current_channel) * bat->pdata->current_mult;
bat->timestamp = jiffies;
}
diff --git a/include/linux/s3c_adc_battery.h b/include/linux/s3c_adc_battery.h
index fbe58b7..99dadbf 100644
--- a/include/linux/s3c_adc_battery.h
+++ b/include/linux/s3c_adc_battery.h
@@ -25,6 +25,10 @@ struct s3c_adc_bat_pdata {
const unsigned int current_channel;
const unsigned int backup_volt_channel;
+ const unsigned int volt_samples;
+ const unsigned int current_samples;
+ const unsigned int backup_volt_samples;
+
const unsigned int volt_mult;
const unsigned int current_mult;
const unsigned int backup_volt_mult;
--
1.7.2.3
^ permalink raw reply related
* Re: [PATCH] PM / Hibernate: Improve performance of LZO/plain hibernation, checksum image
From: Barry Song @ 2011-12-31 8:56 UTC (permalink / raw)
To: Bojan Smojver; +Cc: linux-pm, LKML, DL-SHA-WorkGroupLinux
In-Reply-To: <1325130899.2029.18.camel@shrek.rexursive.com>
2011/12/29 Bojan Smojver <bojan@rexursive.com>:
> On Thu, 2011-12-29 at 11:20 +0800, Barry Song wrote:
>> the platform is ARM cortex-a9 single-core 1Ghz SoC and we save image
>> to a SD card or NAND.
>> a phenomenon we saw is that multi-BIOs is not merged into a request by
>> block level elevator. so the SD/NANDdisk driver handles many small
>> request one page by one page.
>
> Interesting, thanks.
we did see some visible IO performance improvement now. the main
reason we didn't see that before is because we enable on-demand
cpufreq in default status. while saving and resuming from snapshot,
cpu frequence is switched frequently due to IO sleep and
compression/uncompression CPU consume. then we enable Performance
policy while booting, and move to on-demand after system boot, we did
see a great performance improvement.
for our inand card, the speed to read/uncompress snapshot is improved
from 7.x MB to 11MB.
>
> --
> Bojan
>
-barry
^ permalink raw reply
* Re: [PATCH 1/7] x86, acpi, tboot: Have a ACPI os prepare sleep instead of calling tboot_sleep.
From: Konrad Rzeszutek Wilk @ 2012-01-03 17:13 UTC (permalink / raw)
To: linux-kernel, rjw, x86, len.brown, joseph.cihula, linux-pm,
tboot-devel, linux-acpi, liang.tang
Cc: Shane Wang, Thomas Gleixner, xen-devel, hpa
In-Reply-To: <1324075099-11397-2-git-send-email-konrad.wilk@oracle.com>
On Fri, Dec 16, 2011 at 05:38:13PM -0500, Konrad Rzeszutek Wilk wrote:
> From: Tang Liang <liang.tang@oracle.com>
Hey Joseph,
I remember you acked the initial rfc patches I had posted.
But I was wondering if these ones are to your liking (I think they are -
they aren't that much different, but I didn't want to blindly sticking
'Acked-by' as they did change a bit).
Thanks!
>
> The ACPI suspend path makes a call to tboot_sleep right before
> it writes the PM1A, PM1B values. We replace the direct call to
> tboot via an registration callback similar to __acpi_register_gsi.
>
> CC: Thomas Gleixner <tglx@linutronix.de>
> CC: "H. Peter Anvin" <hpa@zytor.com>
> CC: x86@kernel.org
> CC: Len Brown <len.brown@intel.com>
> CC: Joseph Cihula <joseph.cihula@intel.com>
> CC: Shane Wang <shane.wang@intel.com>
> CC: xen-devel@lists.xensource.com
> CC: linux-pm@lists.linux-foundation.org
> CC: tboot-devel@lists.sourceforge.net
> CC: linux-acpi@vger.kernel.org
> [v1: Added __attribute__ ((unused))]
> [v2: Introduced a wrapper instead of changing tboot_sleep return values]
> [v3: Added return value AE_CTRL_SKIP for acpi_os_sleep_prepare]
> Signed-off-by: Tang Liang <liang.tang@oracle.com>
> [v1: Fix compile issues on IA64 and PPC64]
> [v2: Fix where __acpi_os_prepare_sleep==NULL and did not go in sleep properly]
> Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
> ---
> arch/x86/kernel/tboot.c | 8 ++++++++
> drivers/acpi/acpica/hwsleep.c | 10 +++++++---
> drivers/acpi/osl.c | 24 ++++++++++++++++++++++++
> include/acpi/acexcep.h | 1 +
> include/linux/acpi.h | 10 ++++++++++
> include/linux/tboot.h | 1 -
> 6 files changed, 50 insertions(+), 4 deletions(-)
>
> diff --git a/arch/x86/kernel/tboot.c b/arch/x86/kernel/tboot.c
> index e2410e2..1a4ab7d 100644
> --- a/arch/x86/kernel/tboot.c
> +++ b/arch/x86/kernel/tboot.c
> @@ -297,6 +297,12 @@ void tboot_sleep(u8 sleep_state, u32 pm1a_control, u32 pm1b_control)
>
> tboot_shutdown(acpi_shutdown_map[sleep_state]);
> }
> +static int tboot_sleep_wrapper(u8 sleep_state, u32 pm1a_control,
> + u32 pm1b_control)
> +{
> + tboot_sleep(sleep_state, pm1a_control, pm1b_control);
> + return 0;
> +}
>
> static atomic_t ap_wfs_count;
>
> @@ -345,6 +351,8 @@ static __init int tboot_late_init(void)
>
> atomic_set(&ap_wfs_count, 0);
> register_hotcpu_notifier(&tboot_cpu_notifier);
> +
> + acpi_os_set_prepare_sleep(&tboot_sleep_wrapper);
> return 0;
> }
>
> diff --git a/drivers/acpi/acpica/hwsleep.c b/drivers/acpi/acpica/hwsleep.c
> index d52da30..992359a 100644
> --- a/drivers/acpi/acpica/hwsleep.c
> +++ b/drivers/acpi/acpica/hwsleep.c
> @@ -43,9 +43,9 @@
> */
>
> #include <acpi/acpi.h>
> +#include <linux/acpi.h>
> #include "accommon.h"
> #include "actables.h"
> -#include <linux/tboot.h>
> #include <linux/module.h>
>
> #define _COMPONENT ACPI_HARDWARE
> @@ -344,8 +344,12 @@ acpi_status asmlinkage acpi_enter_sleep_state(u8 sleep_state)
>
> ACPI_FLUSH_CPU_CACHE();
>
> - tboot_sleep(sleep_state, pm1a_control, pm1b_control);
> -
> + status = acpi_os_prepare_sleep(sleep_state, pm1a_control,
> + pm1b_control);
> + if (ACPI_SKIP(status))
> + return_ACPI_STATUS(AE_OK);
> + if (ACPI_FAILURE(status))
> + return_ACPI_STATUS(status);
> /* Write #2: Write both SLP_TYP + SLP_EN */
>
> status = acpi_hw_write_pm1_control(pm1a_control, pm1b_control);
> diff --git a/drivers/acpi/osl.c b/drivers/acpi/osl.c
> index f31c5c5..f3aae4b 100644
> --- a/drivers/acpi/osl.c
> +++ b/drivers/acpi/osl.c
> @@ -76,6 +76,9 @@ EXPORT_SYMBOL(acpi_in_debugger);
> extern char line_buf[80];
> #endif /*ENABLE_DEBUGGER */
>
> +static int (*__acpi_os_prepare_sleep)(u8 sleep_state, u32 pm1a_ctrl,
> + u32 pm1b_ctrl);
> +
> static acpi_osd_handler acpi_irq_handler;
> static void *acpi_irq_context;
> static struct workqueue_struct *kacpid_wq;
> @@ -1659,3 +1662,24 @@ acpi_status acpi_os_terminate(void)
>
> return AE_OK;
> }
> +
> +acpi_status acpi_os_prepare_sleep(u8 sleep_state, u32 pm1a_control,
> + u32 pm1b_control)
> +{
> + int rc = 0;
> + if (__acpi_os_prepare_sleep)
> + rc = __acpi_os_prepare_sleep(sleep_state,
> + pm1a_control, pm1b_control);
> + if (rc < 0)
> + return AE_ERROR;
> + else if (rc > 0)
> + return AE_CTRL_SKIP;
> +
> + return AE_OK;
> +}
> +
> +void acpi_os_set_prepare_sleep(int (*func)(u8 sleep_state,
> + u32 pm1a_ctrl, u32 pm1b_ctrl))
> +{
> + __acpi_os_prepare_sleep = func;
> +}
> diff --git a/include/acpi/acexcep.h b/include/acpi/acexcep.h
> index 5b6c391..fa0d22c 100644
> --- a/include/acpi/acexcep.h
> +++ b/include/acpi/acexcep.h
> @@ -57,6 +57,7 @@
> #define ACPI_SUCCESS(a) (!(a))
> #define ACPI_FAILURE(a) (a)
>
> +#define ACPI_SKIP(a) (a == AE_CTRL_SKIP)
> #define AE_OK (acpi_status) 0x0000
>
> /*
> diff --git a/include/linux/acpi.h b/include/linux/acpi.h
> index 6001b4da..fccd017 100644
> --- a/include/linux/acpi.h
> +++ b/include/linux/acpi.h
> @@ -359,4 +359,14 @@ static inline int suspend_nvs_register(unsigned long a, unsigned long b)
> }
> #endif
>
> +#ifdef CONFIG_ACPI
> +void acpi_os_set_prepare_sleep(int (*func)(u8 sleep_state,
> + u32 pm1a_ctrl, u32 pm1b_ctrl));
> +
> +acpi_status acpi_os_prepare_sleep(u8 sleep_state,
> + u32 pm1a_control, u32 pm1b_control);
> +#else
> +#define acpi_os_set_prepare_sleep(func, pm1a_ctrl, pm1b_ctrl) do { } while (0)
> +#endif
> +
> #endif /*_LINUX_ACPI_H*/
> diff --git a/include/linux/tboot.h b/include/linux/tboot.h
> index 1dba6ee..c75128b 100644
> --- a/include/linux/tboot.h
> +++ b/include/linux/tboot.h
> @@ -143,7 +143,6 @@ static inline int tboot_enabled(void)
>
> extern void tboot_probe(void);
> extern void tboot_shutdown(u32 shutdown_type);
> -extern void tboot_sleep(u8 sleep_state, u32 pm1a_control, u32 pm1b_control);
> extern struct acpi_table_header *tboot_get_dmar_table(
> struct acpi_table_header *dmar_tbl);
> extern int tboot_force_iommu(void);
> --
> 1.7.7.4
^ permalink raw reply
* Re: [lm-sensors] [RFC PATCH 2/3] thermal: exynos4: Register the tmu sensor with the thermal interface layer
From: Amit Kachhap @ 2012-01-04 10:14 UTC (permalink / raw)
To: guenter.roeck, Donggeun Kim
Cc: linux-samsung-soc@vger.kernel.org, linaro-dev@lists.linaro.org,
patches@linaro.org, linux-kernel@vger.kernel.org,
lm-sensors@lm-sensors.org, linux-acpi@vger.kernel.org,
linux-pm@lists.linux-foundation.org
In-Reply-To: <1325629553.26706.11.camel@groeck-laptop>
Hi Guenter,
The main idea of this work is to leave the current userspace based
notification scheme and add the kernel based cooling scheme on top of
it. Anyway, It is a good idea to move the file hwmon/exynos4_tmu.c as
this creates 2 hwmon entries.
Adding CC: Donggeun Kim to know his opinion.
Thanks,
Amit Daniel
On 4 January 2012 03:55, Guenter Roeck <guenter.roeck@ericsson.com> wrote:
> On Wed, 2011-12-21 at 06:59 -0500, Amit Daniel Kachhap wrote:
>> Export and register information from the hwmon tmu sensor to the samsung
>> exynos kernel thermal framework where different cooling devices and thermal
>> zone are binded. The exported information is based according to the data
>> structure thermal_sensor_conf present in exynos_thermal.h. HWMON sysfs
>> functions are currently left although all of them are present in generic
>> linux thermal layer.
>> Also the platform data structure is modified to pass frequency cooling
>> in percentages for each thermal level.
>>
> Hi Amit,
>
> wouldn't it make more sense to merge the code as necessary from
> hwmon/exynos4_tmu.c into the new thermal/exynos_thermal.c, and drop
> hwmon/exynos4_tmu.c entirely ?
>
> With that, you should get the hwmon entries for free, and we would not
> have to maintain two drivers with overlapping functionality.
>
> Thanks,
> Guenter
>
>> Signed-off-by: Amit Daniel Kachhap <amit.kachhap@linaro.org>
>> ---
>> drivers/hwmon/exynos4_tmu.c | 34 ++++++++++++++++++++++++++--
>> include/linux/platform_data/exynos4_tmu.h | 7 ++++++
>> 2 files changed, 38 insertions(+), 3 deletions(-)
>>
>> diff --git a/drivers/hwmon/exynos4_tmu.c b/drivers/hwmon/exynos4_tmu.c
>> index f2359a0..6912a7f 100644
>> --- a/drivers/hwmon/exynos4_tmu.c
>> +++ b/drivers/hwmon/exynos4_tmu.c
>> @@ -37,6 +37,9 @@
>> #include <linux/hwmon-sysfs.h>
>>
>> #include <linux/platform_data/exynos4_tmu.h>
>> +#ifdef CONFIG_SAMSUNG_THERMAL_INTERFACE
>> +#include <linux/exynos_thermal.h>
>> +#endif
>>
>> #define EXYNOS4_TMU_REG_TRIMINFO 0x0
>> #define EXYNOS4_TMU_REG_CONTROL 0x20
>> @@ -248,10 +251,13 @@ static void exynos4_tmu_work(struct work_struct *work)
>>
>> kobject_uevent(&data->hwmon_dev->kobj, KOBJ_CHANGE);
>>
>> - enable_irq(data->irq);
>>
>> clk_disable(data->clk);
>> mutex_unlock(&data->lock);
>> +#ifdef CONFIG_SAMSUNG_THERMAL_INTERFACE
>> + exynos4_report_trigger();
>> +#endif
>> + enable_irq(data->irq);
>> }
>>
>> static irqreturn_t exynos4_tmu_irq(int irq, void *id)
>> @@ -345,6 +351,14 @@ static const struct attribute_group exynos4_tmu_attr_group = {
>> .attrs = exynos4_tmu_attributes,
>> };
>>
>> +#ifdef CONFIG_SAMSUNG_THERMAL_INTERFACE
>> +static struct thermal_sensor_conf exynos4_sensor_conf = {
>> + .name = "exynos4-therm",
>> + .read_temperature = (int (*)(void *))exynos4_tmu_read,
>> +};
>> +#endif
>> +/*CONFIG_SAMSUNG_THERMAL_INTERFACE*/
>> +
>> static int __devinit exynos4_tmu_probe(struct platform_device *pdev)
>> {
>> struct exynos4_tmu_data *data;
>> @@ -432,9 +446,20 @@ static int __devinit exynos4_tmu_probe(struct platform_device *pdev)
>> }
>>
>> exynos4_tmu_control(pdev, true);
>> -
>> +#ifdef CONFIG_SAMSUNG_THERMAL_INTERFACE
>> + (&exynos4_sensor_conf)->private_data = data;
>> + (&exynos4_sensor_conf)->sensor_data = pdata;
>> + ret = exynos4_register_thermal(&exynos4_sensor_conf);
>> + if (ret) {
>> + dev_err(&pdev->dev, "Failed to register thermal interface\n");
>> + goto err_hwmon_device;
>> + }
>> +#endif
>> return 0;
>> -
>> +#ifdef CONFIG_SAMSUNG_THERMAL_INTERFACE
>> +err_hwmon_device:
>> + hwmon_device_unregister(data->hwmon_dev);
>> +#endif
>> err_create_group:
>> sysfs_remove_group(&pdev->dev.kobj, &exynos4_tmu_attr_group);
>> err_clk:
>> @@ -458,6 +483,9 @@ static int __devexit exynos4_tmu_remove(struct platform_device *pdev)
>>
>> exynos4_tmu_control(pdev, false);
>>
>> +#ifdef CONFIG_SAMSUNG_THERMAL_INTERFACE
>> + exynos4_unregister_thermal();
>> +#endif
>> hwmon_device_unregister(data->hwmon_dev);
>> sysfs_remove_group(&pdev->dev.kobj, &exynos4_tmu_attr_group);
>>
>> diff --git a/include/linux/platform_data/exynos4_tmu.h b/include/linux/platform_data/exynos4_tmu.h
>> index 39e038c..642c508 100644
>> --- a/include/linux/platform_data/exynos4_tmu.h
>> +++ b/include/linux/platform_data/exynos4_tmu.h
>> @@ -21,6 +21,7 @@
>>
>> #ifndef _LINUX_EXYNOS4_TMU_H
>> #define _LINUX_EXYNOS4_TMU_H
>> +#include <linux/cpu_cooling.h>
>>
>> enum calibration_type {
>> TYPE_ONE_POINT_TRIMMING,
>> @@ -64,6 +65,9 @@ enum calibration_type {
>> * in the positive-TC generator block
>> * 0 <= reference_voltage <= 31
>> * @cal_type: calibration type for temperature
>> + * @freq_pctg_table: Table representing frequency reduction percentage.
>> + * @freq_tab_count: Count of the above table as frequency reduction may
>> + * applicable to only some of the trigger levels.
>> *
>> * This structure is required for configuration of exynos4_tmu driver.
>> */
>> @@ -79,5 +83,8 @@ struct exynos4_tmu_platform_data {
>> u8 reference_voltage;
>>
>> enum calibration_type cal_type;
>> +
>> + struct freq_pctg_table freq_tab[4];
>> + unsigned int freq_tab_count;
>> };
>> #endif /* _LINUX_EXYNOS4_TMU_H */
>
>
^ permalink raw reply
* Re: [lm-sensors] [RFC PATCH 2/3] thermal: exynos4: Register the tmu sensor with the thermal interface layer
From: R, Durgadoss @ 2012-01-04 10:23 UTC (permalink / raw)
To: Amit Kachhap, guenter.roeck@ericsson.com, Donggeun Kim
Cc: linux-samsung-soc@vger.kernel.org, linaro-dev@lists.linaro.org,
patches@linaro.org, linux-kernel@vger.kernel.org,
lm-sensors@lm-sensors.org, linux-acpi@vger.kernel.org,
linux-pm@lists.linux-foundation.org
In-Reply-To: <CAK44p20XeLVkJyox2SsDqyy=RYgEQNpyGGypwTMPXpueQT1T3g@mail.gmail.com>
Hi Amit Daniel,
> Hi Guenter,
>
> The main idea of this work is to leave the current userspace based
> notification scheme and add the kernel based cooling scheme on top of
> it. Anyway, It is a good idea to move the file hwmon/exynos4_tmu.c as
But, What I feel is, kernel based cooling scheme will work only for
Controlling 'CPU' frequency. But in SoC's there are other devices that
Contribute to Thermal. For example, GPU, Display, Battery (during charging)
etc.. In this case, we need a user space to control these devices. So, in a
way, the user space notification mechanism is a unified solution for
throttling all devices and keeps the kernel code light weight.
I am also curious to know why the existing mechanism did not work for you ?
Thanks,
Durga
> this creates 2 hwmon entries.
> Adding CC: Donggeun Kim to know his opinion.
>
> Thanks,
> Amit Daniel
[snip.]
^ permalink raw reply
* Re: [PATCH 1/3] cpuidle: refactor out cpuidle_enter_state
From: Jean Pihet @ 2012-01-04 14:08 UTC (permalink / raw)
To: Colin Cross
Cc: Kevin Hilman, Len Brown, linux-kernel, Amit Kucheria, linux-tegra,
linux-pm, linux-omap, Arjan van de Ven, linux-arm-kernel
In-Reply-To: <1324426147-16735-2-git-send-email-ccross@android.com>
Hi Colin,
On Wed, Dec 21, 2011 at 1:09 AM, Colin Cross <ccross@android.com> wrote:
> Split the code to enter a state and update the stats into a helper
> function, cpuidle_enter_state, and export it. This function will
> be called by the coupled state code to handle entering the safe
> state and the final coupled state.
>
> Signed-off-by: Colin Cross <ccross@android.com>
> ---
> drivers/cpuidle/cpuidle.c | 43 +++++++++++++++++++++++++++++--------------
> drivers/cpuidle/cpuidle.h | 2 ++
> 2 files changed, 31 insertions(+), 14 deletions(-)
>
> diff --git a/drivers/cpuidle/cpuidle.c b/drivers/cpuidle/cpuidle.c
> index 06ce268..1486b3c 100644
> --- a/drivers/cpuidle/cpuidle.c
> +++ b/drivers/cpuidle/cpuidle.c
> @@ -54,6 +54,34 @@ static void cpuidle_kick_cpus(void) {}
> static int __cpuidle_register_device(struct cpuidle_device *dev);
>
> /**
> + * cpuidle_enter_state
> + *
> + * enter the state and update stats
> + */
> +int cpuidle_enter_state(struct cpuidle_device *dev, struct cpuidle_driver *drv,
> + int next_state)
> +{
> + int entered_state;
> + struct cpuidle_state *target_state;
> +
> + target_state = &drv->states[next_state];
> +
> + entered_state = target_state->enter(dev, drv, next_state);
> +
> + if (entered_state >= 0) {
> + /* Update cpuidle counters */
> + /* This can be moved to within driver enter routine
> + * but that results in multiple copies of same code.
> + */
> + dev->states_usage[entered_state].time +=
> + (unsigned long long)dev->last_residency;
> + dev->states_usage[entered_state].usage++;
> + }
> +
> + return entered_state;
> +}
> +
> +/**
> * cpuidle_idle_call - the main idle loop
> *
> * NOTE: no locks or semaphores should be used here
> @@ -63,7 +91,6 @@ int cpuidle_idle_call(void)
> {
> struct cpuidle_device *dev = __this_cpu_read(cpuidle_devices);
> struct cpuidle_driver *drv = cpuidle_get_driver();
> - struct cpuidle_state *target_state;
> int next_state, entered_state;
>
> if (off)
> @@ -92,26 +119,14 @@ int cpuidle_idle_call(void)
> return 0;
> }
>
> - target_state = &drv->states[next_state];
> -
> trace_power_start(POWER_CSTATE, next_state, dev->cpu);
> trace_cpu_idle(next_state, dev->cpu);
>
> - entered_state = target_state->enter(dev, drv, next_state);
> + entered_state = cpuidle_enter_state(dev, drv, next_state);
>
> trace_power_end(dev->cpu);
> trace_cpu_idle(PWR_EVENT_EXIT, dev->cpu);
The cpu_idle traces are only present in this function and not in
cpuidle_enter_state. Is that expected? Can all the transitions from
all the cpus get traced that way?
Regards,
Jean
^ permalink raw reply
* Re: [PATCH 0/3] coupled cpuidle state support
From: Shilimkar, Santosh @ 2012-01-04 17:27 UTC (permalink / raw)
To: Kevin Hilman
Cc: Len Brown, linux-kernel, Amit Kucheria, Colin Cross, linux-tegra,
linux-pm, linux-omap, Arjan van de Ven, linux-arm-kernel
In-Reply-To: <87sjjw70zs.fsf@ti.com>
On Wed, Jan 4, 2012 at 1:41 AM, Kevin Hilman <khilman@ti.com> wrote:
> Colin Cross <ccross@android.com> writes:
>
>
>> This patch series implements an alternative solution, where each
>> cpu will wait in the WFI state until all cpus are ready to enter
>> a coupled state, at which point the coupled state function will
>> be called on all cpus at approximately the same time.
>
> This looks great, and is certainly preferred to hotplug IMO.
>
> [...]
>
>> None of the platforms I work with have an SMP idle implementation
>> upstream, so I can't easily show a patch that converts a platform
>> from hotplug governor to coupled cpuidle states.
>
> Basic OMAP4 CPUidle support is in now queued for v3.3 (see omap4
> branch Tony's tree[1].)
>
> Can you (or Santosh) send a patch that adds coupled support to that
> driver so it can see some broader testing on OMAP4?
>
I briefly attempted OMAP4 idle with this series but had some lock
up related issues which we faced in the older development.
Then I got busy into other activities which will keep me occupied for
next few weeks. I will be happy to share the patches in case some one
would like to have a look till then.
Regards
Santosh
^ permalink raw reply
* [RFC]: [PATCH] Export cpuidle_(un)register_governor
From: Jan-Simon Möller @ 2012-01-04 17:48 UTC (permalink / raw)
To: linux-pm; +Cc: Arjan van de Ven
[-- Attachment #1: Type: text/plain, Size: 473 bytes --]
Hi all!
This patch exports cpuidle_register_governor and cpuidle_unregister_governor
with EXPORT_SYMBOL_GPL (as the other cpuidle_(un)register_* ).
Reasoning: allow runtime loading of a cpuidle governor (mainly for
development for now).
Usually we don't need this as we're using built-ins for the governors - but
during development it is really handy to load and unload a cpuidle governor
(together with the cpuidle_sysfs_switch).
Comments ?
Best,
Jan-Simon
[-- Attachment #2: 0001-Export-cpuidle_register_governor-and-cpuidle_unregis.patch --]
[-- Type: text/x-patch, Size: 1166 bytes --]
>From a21a054fa64f898576ee62fced30508e0affe243 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Jan-Simon=20M=C3=B6ller?= <jansimon.moeller@gmx.de>
Date: Mon, 12 Dec 2011 14:40:56 +0100
Subject: [PATCH] Export cpuidle_register_governor and
cpuidle_unregister_governor with EXPORT_SYMBOL_GPL (as the
other cpuidle_(un)register_* ).
Reasoning: allow runtime loading of a cpuidle governor (mainly for
development for now).
---
drivers/cpuidle/governor.c | 3 +++
1 files changed, 3 insertions(+), 0 deletions(-)
diff --git a/drivers/cpuidle/governor.c b/drivers/cpuidle/governor.c
index ea2f8e7..552f5a4 100644
--- a/drivers/cpuidle/governor.c
+++ b/drivers/cpuidle/governor.c
@@ -97,6 +97,8 @@ int cpuidle_register_governor(struct cpuidle_governor *gov)
return ret;
}
+EXPORT_SYMBOL_GPL(cpuidle_register_governor);
+
/**
* cpuidle_replace_governor - find a replacement governor
* @exclude_rating: the rating that will be skipped while looking for
@@ -139,3 +141,4 @@ void cpuidle_unregister_governor(struct cpuidle_governor *gov)
mutex_unlock(&cpuidle_lock);
}
+EXPORT_SYMBOL_GPL(cpuidle_unregister_governor);
--
1.7.7
[-- Attachment #3: Type: text/plain, Size: 0 bytes --]
^ permalink raw reply
* Re: [RFC]: [PATCH] Export cpuidle_(un)register_governor
From: Arjan van de Ven @ 2012-01-04 17:51 UTC (permalink / raw)
To: Jan-Simon Möller; +Cc: linux-pm
In-Reply-To: <7458223.HLZRiFjcWF@frodo.auenland.lan>
On 1/4/2012 9:48 AM, Jan-Simon Möller wrote:
> Hi all!
>
> This patch exports cpuidle_register_governor and cpuidle_unregister_governor
> with EXPORT_SYMBOL_GPL (as the other cpuidle_(un)register_* ).
>
> Reasoning: allow runtime loading of a cpuidle governor (mainly for
> development for now).
>
> Usually we don't need this as we're using built-ins for the governors - but
> during development it is really handy to load and unload a cpuidle governor
> (together with the cpuidle_sysfs_switch).
while I don't mind this for development purposes, I really am
opposed to loadable governors; cpufreq did this and it has been a huge
disaster in terms of complexity and locking.... it's really not a good
idea to repeat this mistake.... and it's not like normally this sort of
thing should or would switch.
_______________________________________________
linux-pm mailing list
linux-pm@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/linux-pm
^ permalink raw reply
* Re: sysrq-o broken since 2.6.38
From: Rafael J. Wysocki @ 2012-01-04 22:52 UTC (permalink / raw)
To: Phil Oester; +Cc: linux-pm
In-Reply-To: <20120104053618.GA20879@linuxace.com>
On Wednesday, January 04, 2012, Phil Oester wrote:
> In commit 1eb208ae [PM: Make CONFIG_PM depend on (CONFIG_PM_SLEEP || CONFIG_PM_RUNTIME)],
> sysrq-o option no longer works unless PM_SLEEP or PM_RUNTIME is enabled. I doubt
> this was an intended consequence of this change. Could someone confirm?
No, it wasn't.
I'll try to find out what the problem is.
Thanks,
Rafael
^ permalink raw reply
* Re: [lm-sensors] [RFC PATCH 2/3] thermal: exynos4: Register the tmu sensor with the thermal interface layer
From: Donggeun Kim @ 2012-01-05 5:57 UTC (permalink / raw)
To: Amit Kachhap
Cc: linux-samsung-soc@vger.kernel.org, linaro-dev@lists.linaro.org,
patches@linaro.org, linux-kernel@vger.kernel.org,
lm-sensors@lm-sensors.org, linux-acpi@vger.kernel.org,
linux-pm@lists.linux-foundation.org, guenter.roeck
In-Reply-To: <CAK44p20XeLVkJyox2SsDqyy=RYgEQNpyGGypwTMPXpueQT1T3g@mail.gmail.com>
Actually, the TMU driver is closely related to thermal layer.
I think it's okay to move it to the thermal.
Thanks.
-Donggeun
On 2012년 01월 04일 19:14, Amit Kachhap wrote:
> Hi Guenter,
>
> The main idea of this work is to leave the current userspace based
> notification scheme and add the kernel based cooling scheme on top of
> it. Anyway, It is a good idea to move the file hwmon/exynos4_tmu.c as
> this creates 2 hwmon entries.
> Adding CC: Donggeun Kim to know his opinion.
>
> Thanks,
> Amit Daniel
>
> On 4 January 2012 03:55, Guenter Roeck <guenter.roeck@ericsson.com> wrote:
>> On Wed, 2011-12-21 at 06:59 -0500, Amit Daniel Kachhap wrote:
>>> Export and register information from the hwmon tmu sensor to the samsung
>>> exynos kernel thermal framework where different cooling devices and thermal
>>> zone are binded. The exported information is based according to the data
>>> structure thermal_sensor_conf present in exynos_thermal.h. HWMON sysfs
>>> functions are currently left although all of them are present in generic
>>> linux thermal layer.
>>> Also the platform data structure is modified to pass frequency cooling
>>> in percentages for each thermal level.
>>>
>> Hi Amit,
>>
>> wouldn't it make more sense to merge the code as necessary from
>> hwmon/exynos4_tmu.c into the new thermal/exynos_thermal.c, and drop
>> hwmon/exynos4_tmu.c entirely ?
>>
>> With that, you should get the hwmon entries for free, and we would not
>> have to maintain two drivers with overlapping functionality.
>>
>> Thanks,
>> Guenter
>>
>>> Signed-off-by: Amit Daniel Kachhap <amit.kachhap@linaro.org>
>>> ---
>>> drivers/hwmon/exynos4_tmu.c | 34 ++++++++++++++++++++++++++--
>>> include/linux/platform_data/exynos4_tmu.h | 7 ++++++
>>> 2 files changed, 38 insertions(+), 3 deletions(-)
>>>
>>> diff --git a/drivers/hwmon/exynos4_tmu.c b/drivers/hwmon/exynos4_tmu.c
>>> index f2359a0..6912a7f 100644
>>> --- a/drivers/hwmon/exynos4_tmu.c
>>> +++ b/drivers/hwmon/exynos4_tmu.c
>>> @@ -37,6 +37,9 @@
>>> #include <linux/hwmon-sysfs.h>
>>>
>>> #include <linux/platform_data/exynos4_tmu.h>
>>> +#ifdef CONFIG_SAMSUNG_THERMAL_INTERFACE
>>> +#include <linux/exynos_thermal.h>
>>> +#endif
>>>
>>> #define EXYNOS4_TMU_REG_TRIMINFO 0x0
>>> #define EXYNOS4_TMU_REG_CONTROL 0x20
>>> @@ -248,10 +251,13 @@ static void exynos4_tmu_work(struct work_struct *work)
>>>
>>> kobject_uevent(&data->hwmon_dev->kobj, KOBJ_CHANGE);
>>>
>>> - enable_irq(data->irq);
>>>
>>> clk_disable(data->clk);
>>> mutex_unlock(&data->lock);
>>> +#ifdef CONFIG_SAMSUNG_THERMAL_INTERFACE
>>> + exynos4_report_trigger();
>>> +#endif
>>> + enable_irq(data->irq);
>>> }
>>>
>>> static irqreturn_t exynos4_tmu_irq(int irq, void *id)
>>> @@ -345,6 +351,14 @@ static const struct attribute_group exynos4_tmu_attr_group = {
>>> .attrs = exynos4_tmu_attributes,
>>> };
>>>
>>> +#ifdef CONFIG_SAMSUNG_THERMAL_INTERFACE
>>> +static struct thermal_sensor_conf exynos4_sensor_conf = {
>>> + .name = "exynos4-therm",
>>> + .read_temperature = (int (*)(void *))exynos4_tmu_read,
>>> +};
>>> +#endif
>>> +/*CONFIG_SAMSUNG_THERMAL_INTERFACE*/
>>> +
>>> static int __devinit exynos4_tmu_probe(struct platform_device *pdev)
>>> {
>>> struct exynos4_tmu_data *data;
>>> @@ -432,9 +446,20 @@ static int __devinit exynos4_tmu_probe(struct platform_device *pdev)
>>> }
>>>
>>> exynos4_tmu_control(pdev, true);
>>> -
>>> +#ifdef CONFIG_SAMSUNG_THERMAL_INTERFACE
>>> + (&exynos4_sensor_conf)->private_data = data;
>>> + (&exynos4_sensor_conf)->sensor_data = pdata;
>>> + ret = exynos4_register_thermal(&exynos4_sensor_conf);
>>> + if (ret) {
>>> + dev_err(&pdev->dev, "Failed to register thermal interface\n");
>>> + goto err_hwmon_device;
>>> + }
>>> +#endif
>>> return 0;
>>> -
>>> +#ifdef CONFIG_SAMSUNG_THERMAL_INTERFACE
>>> +err_hwmon_device:
>>> + hwmon_device_unregister(data->hwmon_dev);
>>> +#endif
>>> err_create_group:
>>> sysfs_remove_group(&pdev->dev.kobj, &exynos4_tmu_attr_group);
>>> err_clk:
>>> @@ -458,6 +483,9 @@ static int __devexit exynos4_tmu_remove(struct platform_device *pdev)
>>>
>>> exynos4_tmu_control(pdev, false);
>>>
>>> +#ifdef CONFIG_SAMSUNG_THERMAL_INTERFACE
>>> + exynos4_unregister_thermal();
>>> +#endif
>>> hwmon_device_unregister(data->hwmon_dev);
>>> sysfs_remove_group(&pdev->dev.kobj, &exynos4_tmu_attr_group);
>>>
>>> diff --git a/include/linux/platform_data/exynos4_tmu.h b/include/linux/platform_data/exynos4_tmu.h
>>> index 39e038c..642c508 100644
>>> --- a/include/linux/platform_data/exynos4_tmu.h
>>> +++ b/include/linux/platform_data/exynos4_tmu.h
>>> @@ -21,6 +21,7 @@
>>>
>>> #ifndef _LINUX_EXYNOS4_TMU_H
>>> #define _LINUX_EXYNOS4_TMU_H
>>> +#include <linux/cpu_cooling.h>
>>>
>>> enum calibration_type {
>>> TYPE_ONE_POINT_TRIMMING,
>>> @@ -64,6 +65,9 @@ enum calibration_type {
>>> * in the positive-TC generator block
>>> * 0 <= reference_voltage <= 31
>>> * @cal_type: calibration type for temperature
>>> + * @freq_pctg_table: Table representing frequency reduction percentage.
>>> + * @freq_tab_count: Count of the above table as frequency reduction may
>>> + * applicable to only some of the trigger levels.
>>> *
>>> * This structure is required for configuration of exynos4_tmu driver.
>>> */
>>> @@ -79,5 +83,8 @@ struct exynos4_tmu_platform_data {
>>> u8 reference_voltage;
>>>
>>> enum calibration_type cal_type;
>>> +
>>> + struct freq_pctg_table freq_tab[4];
>>> + unsigned int freq_tab_count;
>>> };
>>> #endif /* _LINUX_EXYNOS4_TMU_H */
>>
>>
>
_______________________________________________
linux-pm mailing list
linux-pm@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/linux-pm
^ permalink raw reply
* Re: [PATCH v2] PM: HIBERNATION: skip the swap size check if the snapshot image size is anticipative
From: Pavel Machek @ 2012-01-05 18:46 UTC (permalink / raw)
To: Barry Song
Cc: Xiangzhen Ye, linux-kernel, workgroup.linux, linux-arm-kernel,
Barry Song, linux-pm
In-Reply-To: <CAGsJ_4ziRj1oEhmMYjc6yJvS2FHYn+uRWmSaggnJQQjqi=B6gw@mail.gmail.com>
Hi!
Is the check even useful these days? Should we remove it altogether?
Pavel
> Pavel ,Rafael, any feedback?
> -barry
>
> 2011/11/25 Barry Song <Barry.Song@csr.com>:
> > From: Barry Song <baohua.song@csr.com>
> >
> > Current swsusp requires swap partitions even larger than real saved pages
> > based on the worst compression ratio:
> > but for an embedded system, which has limited storage space, then it might
> > can't give the large partition to save snapshot.
> > In the another way, some embedded systems can definitely know the most size
> > needed for snapshot since they run some specific application lists.
> > So this patch provides the possibility for users to tell kernel even
> > the system has a little snapshot partition, but it is still enough.
> > For example, if the system need to save 120MB memory, origin swsusp will require
> > a 130MB partition to save snapshot. but if users know 30MB is enough for them(
> > compressed image will be less than 30MB), they just make a 30MB partition by
> > echo 0 > /sys/power/check_swap_size
> >
> > Signed-off-by: Barry Song <Baohua.Song@csr.com>
> > Cc: Xiangzhen Ye <Xiangzhen.Ye@csr.com>
> > ---
> > -v2:drop swap_enough bootargs and use /sys/power/check_swap_size node
> >
> > Documentation/power/interface.txt | 5 +++++
> > kernel/power/hibernate.c | 22 ++++++++++++++++++++++
> > kernel/power/power.h | 2 ++
> > kernel/power/swap.c | 9 +++++++++
> > 4 files changed, 38 insertions(+), 0 deletions(-)
> >
> > diff --git a/Documentation/power/interface.txt b/Documentation/power/interface.txt
> > index c537834..5e205f0 100644
> > --- a/Documentation/power/interface.txt
> > +++ b/Documentation/power/interface.txt
> > @@ -47,6 +47,11 @@ Writing to this file will accept one of
> > 'testproc'
> > 'test'
> >
> > +/sys/power/check_swap_size controls whether we can skip checking the swap
> > +partition size by worst compression ratio. If users know the swap partition
> > +is enough for compressed snapshot, write 0 to /sys/power/check_swap_size.
> > +It is useful for an embedded system with known running softwares.
> > +
> > /sys/power/image_size controls the size of the image created by
> > the suspend-to-disk mechanism. It can be written a string
> > representing a non-negative integer that will be used as an upper
> > diff --git a/kernel/power/hibernate.c b/kernel/power/hibernate.c
> > index 1c53f7f..5552473 100644
> > --- a/kernel/power/hibernate.c
> > +++ b/kernel/power/hibernate.c
> > @@ -1024,11 +1024,33 @@ static ssize_t reserved_size_store(struct kobject *kobj,
> >
> > power_attr(reserved_size);
> >
> > +static ssize_t check_swap_size_show(struct kobject *kobj, struct kobj_attribute *attr,
> > + char *buf)
> > +{
> > + return sprintf(buf, "%d\n", check_swap_size);
> > +}
> > +
> > +static ssize_t check_swap_size_store(struct kobject *kobj, struct kobj_attribute *attr,
> > + const char *buf, size_t n)
> > +{
> > + int check_size;
> > +
> > + if (sscanf(buf, "%d", &check_size) == 1) {
> > + check_swap_size = check_size;
> > + return n;
> > + }
> > +
> > + return -EINVAL;
> > +}
> > +
> > +power_attr(check_swap_size);
> > +
> > static struct attribute * g[] = {
> > &disk_attr.attr,
> > &resume_attr.attr,
> > &image_size_attr.attr,
> > &reserved_size_attr.attr,
> > + &check_swap_size_attr.attr,
> > NULL,
> > };
> >
> > diff --git a/kernel/power/power.h b/kernel/power/power.h
> > index 23a2db1..4f0fa78 100644
> > --- a/kernel/power/power.h
> > +++ b/kernel/power/power.h
> > @@ -74,6 +74,8 @@ static struct kobj_attribute _name##_attr = { \
> >
> > /* Preferred image size in bytes (default 500 MB) */
> > extern unsigned long image_size;
> > +/* If 0, skip checking whether the swap size is enough for compressed snapshot */
> > +extern int check_swap_size;
> > /* Size of memory reserved for drivers (default SPARE_PAGES x PAGE_SIZE) */
> > extern unsigned long reserved_size;
> > extern int in_suspend;
> > diff --git a/kernel/power/swap.c b/kernel/power/swap.c
> > index 11a594c..db90195 100644
> > --- a/kernel/power/swap.c
> > +++ b/kernel/power/swap.c
> > @@ -37,6 +37,12 @@
> > #define HIBERNATE_SIG "S1SUSPEND"
> >
> > /*
> > + * if users know swap partitions are enough for compressed snapshots,
> > + * echo 0 > /sys/power/check_swap_size
> > + */
> > +int check_swap_size = 1;
> > +
> > +/*
> > * The swap map is a data structure used for keeping track of each page
> > * written to a swap partition. It consists of many swap_map_page
> > * structures that contain each an array of MAP_PAGE_ENTRIES swap entries.
> > @@ -772,6 +778,9 @@ static int enough_swap(unsigned int nr_pages, unsigned int flags)
> > unsigned int free_swap = count_swap_pages(root_swap, 1);
> > unsigned int required;
> >
> > + if (!check_swap_size)
> > + return 1;
> > +
> > pr_debug("PM: Free swap pages: %u\n", free_swap);
> >
> > required = PAGES_FOR_IO + ((flags & SF_NOCOMPRESS_MODE) ?
> > --
> > 1.7.1
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
^ permalink raw reply
* [PATCH 0/6] RFC: CPU frequency min/max as PM QoS params
From: Antti P Miettinen @ 2012-01-06 0:36 UTC (permalink / raw)
To: linux-pm; +Cc: Antti P Miettinen
The inspiration for this patch series is the N9 CPU frequency boost
upon input events:
http://www.spinics.net/lists/cpufreq/msg00667.html
and the related changes in git://codeaurora.org/kernel/msm.git tree.
Those patches modify the ondemand cpufreq governor. This patch series
adds minimum and maximum CPU frequency as PM QoS parameters and
modifies the cpufreq core to enforce the PM QoS limits. There is also
an example module for boosting the frequency upon input events.
I've been testing these changes against Ubuntu 3.2 kernel on a Dell
E6420 with the ACPI cpufreq driver. The patches are against
linux-next/master, compile tested against it.
--Antti
Alex Frid (1):
PM QoS: Simplify PM QoS expansion/merge
Antti P Miettinen (5):
PM QoS: Add CPU frequency min/max as PM QoS params
cpufreq: Export user_policy min/max
cpufreq: Preserve sysfs min/max request
cpufreq: Enforce PM QoS min/max limits
input: CPU frequency booster
drivers/cpufreq/cpufreq.c | 57 +++++++++++++-
drivers/input/Kconfig | 9 ++
drivers/input/Makefile | 1 +
drivers/input/input-cfboost.c | 174 +++++++++++++++++++++++++++++++++++++++++
include/linux/pm_qos.h | 19 ++++-
kernel/power/qos.c | 55 ++++++++++----
6 files changed, 293 insertions(+), 22 deletions(-)
create mode 100644 drivers/input/input-cfboost.c
--
1.7.4.1
^ permalink raw reply
* [PATCH 1/6] PM QoS: Simplify PM QoS expansion/merge
From: Antti P Miettinen @ 2012-01-06 0:36 UTC (permalink / raw)
To: linux-pm; +Cc: Alex Frid
In-Reply-To: <1325810186-28986-1-git-send-email-amiettinen@nvidia.com>
From: Alex Frid <afrid@nvidia.com>
- Replace class ID #define with enumeration
- Loop through PM QoS objects during initialization (rather than
initializing them one-by-one)
Signed-off-by: Alex Frid <afrid@nvidia.com>
Reviewed-by: Antti Miettinen <amiettinen@nvidia.com>
Reviewed-by: Diwakar Tundlam <dtundlam@nvidia.com>
Reviewed-by: Scott Williams <scwilliams@nvidia.com>
Reviewed-by: Yu-Huan Hsu <yhsu@nvidia.com>
---
include/linux/pm_qos.h | 14 +++++++++-----
kernel/power/qos.c | 23 ++++++++++-------------
2 files changed, 19 insertions(+), 18 deletions(-)
diff --git a/include/linux/pm_qos.h b/include/linux/pm_qos.h
index e5bbcba..5ac91d8 100644
--- a/include/linux/pm_qos.h
+++ b/include/linux/pm_qos.h
@@ -9,12 +9,16 @@
#include <linux/miscdevice.h>
#include <linux/device.h>
-#define PM_QOS_RESERVED 0
-#define PM_QOS_CPU_DMA_LATENCY 1
-#define PM_QOS_NETWORK_LATENCY 2
-#define PM_QOS_NETWORK_THROUGHPUT 3
+enum {
+ PM_QOS_RESERVED = 0,
+ PM_QOS_CPU_DMA_LATENCY,
+ PM_QOS_NETWORK_LATENCY,
+ PM_QOS_NETWORK_THROUGHPUT,
+
+ /* insert new class ID */
+ PM_QOS_NUM_CLASSES,
+};
-#define PM_QOS_NUM_CLASSES 4
#define PM_QOS_DEFAULT_VALUE -1
#define PM_QOS_CPU_DMA_LAT_DEFAULT_VALUE (2000 * USEC_PER_SEC)
diff --git a/kernel/power/qos.c b/kernel/power/qos.c
index 995e3bd..d6d6dbd 100644
--- a/kernel/power/qos.c
+++ b/kernel/power/qos.c
@@ -469,21 +469,18 @@ static ssize_t pm_qos_power_write(struct file *filp, const char __user *buf,
static int __init pm_qos_power_init(void)
{
int ret = 0;
+ int i;
- ret = register_pm_qos_misc(&cpu_dma_pm_qos);
- if (ret < 0) {
- printk(KERN_ERR "pm_qos_param: cpu_dma_latency setup failed\n");
- return ret;
- }
- ret = register_pm_qos_misc(&network_lat_pm_qos);
- if (ret < 0) {
- printk(KERN_ERR "pm_qos_param: network_latency setup failed\n");
- return ret;
+ BUILD_BUG_ON(ARRAY_SIZE(pm_qos_array) != PM_QOS_NUM_CLASSES);
+
+ for (i = 1; i < PM_QOS_NUM_CLASSES; i++) {
+ ret = register_pm_qos_misc(pm_qos_array[i]);
+ if (ret < 0) {
+ printk(KERN_ERR "pm_qos_param: %s setup failed\n",
+ pm_qos_array[i]->name);
+ return ret;
+ }
}
- ret = register_pm_qos_misc(&network_throughput_pm_qos);
- if (ret < 0)
- printk(KERN_ERR
- "pm_qos_param: network_throughput setup failed\n");
return ret;
}
--
1.7.4.1
^ permalink raw reply related
* [PATCH 2/6] PM QoS: Add CPU frequency min/max as PM QoS params
From: Antti P Miettinen @ 2012-01-06 0:36 UTC (permalink / raw)
To: linux-pm; +Cc: Antti P Miettinen
In-Reply-To: <1325810186-28986-1-git-send-email-amiettinen@nvidia.com>
Add minimum and maximum CPU frequency as PM QoS parameters.
Signed-off-by: Antti P Miettinen <amiettinen@nvidia.com>
---
include/linux/pm_qos.h | 5 +++++
kernel/power/qos.c | 32 +++++++++++++++++++++++++++++++-
2 files changed, 36 insertions(+), 1 deletions(-)
diff --git a/include/linux/pm_qos.h b/include/linux/pm_qos.h
index 5ac91d8..7b8d08b 100644
--- a/include/linux/pm_qos.h
+++ b/include/linux/pm_qos.h
@@ -14,8 +14,11 @@ enum {
PM_QOS_CPU_DMA_LATENCY,
PM_QOS_NETWORK_LATENCY,
PM_QOS_NETWORK_THROUGHPUT,
+ PM_QOS_CPU_FREQ_MIN,
+ PM_QOS_CPU_FREQ_MAX,
/* insert new class ID */
+
PM_QOS_NUM_CLASSES,
};
@@ -25,6 +28,8 @@ enum {
#define PM_QOS_NETWORK_LAT_DEFAULT_VALUE (2000 * USEC_PER_SEC)
#define PM_QOS_NETWORK_THROUGHPUT_DEFAULT_VALUE 0
#define PM_QOS_DEV_LAT_DEFAULT_VALUE 0
+#define PM_QOS_CPU_FREQ_MIN_DEFAULT_VALUE 0
+#define PM_QOS_CPU_FREQ_MAX_DEFAULT_VALUE LONG_MAX
struct pm_qos_request {
struct plist_node node;
diff --git a/kernel/power/qos.c b/kernel/power/qos.c
index d6d6dbd..66ae05e 100644
--- a/kernel/power/qos.c
+++ b/kernel/power/qos.c
@@ -101,11 +101,41 @@ static struct pm_qos_object network_throughput_pm_qos = {
};
+static BLOCKING_NOTIFIER_HEAD(cpu_freq_min_notifier);
+static struct pm_qos_constraints cpu_freq_min_constraints = {
+ .list = PLIST_HEAD_INIT(cpu_freq_min_constraints.list),
+ .target_value = PM_QOS_CPU_FREQ_MIN_DEFAULT_VALUE,
+ .default_value = PM_QOS_CPU_FREQ_MIN_DEFAULT_VALUE,
+ .type = PM_QOS_MAX,
+ .notifiers = &cpu_freq_min_notifier,
+};
+static struct pm_qos_object cpu_freq_min_pm_qos = {
+ .constraints = &cpu_freq_min_constraints,
+ .name = "cpu_freq_min",
+};
+
+
+static BLOCKING_NOTIFIER_HEAD(cpu_freq_max_notifier);
+static struct pm_qos_constraints cpu_freq_max_constraints = {
+ .list = PLIST_HEAD_INIT(cpu_freq_max_constraints.list),
+ .target_value = PM_QOS_CPU_FREQ_MAX_DEFAULT_VALUE,
+ .default_value = PM_QOS_CPU_FREQ_MAX_DEFAULT_VALUE,
+ .type = PM_QOS_MIN,
+ .notifiers = &cpu_freq_max_notifier,
+};
+static struct pm_qos_object cpu_freq_max_pm_qos = {
+ .constraints = &cpu_freq_max_constraints,
+ .name = "cpu_freq_max",
+};
+
+
static struct pm_qos_object *pm_qos_array[] = {
&null_pm_qos,
&cpu_dma_pm_qos,
&network_lat_pm_qos,
- &network_throughput_pm_qos
+ &network_throughput_pm_qos,
+ &cpu_freq_min_pm_qos,
+ &cpu_freq_max_pm_qos
};
static ssize_t pm_qos_power_write(struct file *filp, const char __user *buf,
--
1.7.4.1
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox