Peter Robinson | 25 May 15:45 2016
Picon

[PATCH v2] thermal: imx: depend on imx SoC arch

Not much use unless the SoC is selected so depend on the ARCH_MXC
and COMPILE_TEST like all the other thermal drivers.

v2: drop extraneous OF

Signed-off-by: Peter Robinson <pbrobinson <at> gmail.com>
---
 drivers/thermal/Kconfig | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/thermal/Kconfig b/drivers/thermal/Kconfig
index 3c3dc4a..d297338 100644
--- a/drivers/thermal/Kconfig
+++ b/drivers/thermal/Kconfig
 <at>  <at>  -186,7 +186,7  <at>  <at>  config HISI_THERMAL

 config IMX_THERMAL
 	tristate "Temperature sensor driver for Freescale i.MX SoCs"
-	depends on CPU_THERMAL
+	depends on (ARCH_MXC && CPU_THERMAL) || COMPILE_TEST
 	depends on MFD_SYSCON
 	depends on OF
 	help
--

-- 
2.7.4

--
To unsubscribe from this list: send the line "unsubscribe linux-pm" in
the body of a message to majordomo <at> vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
(Continue reading)

Peter Robinson | 25 May 15:24 2016
Picon

[PATCH] thermal: imx: depend on imx SoC arch

Not much use unless the SoC is selected so depend on the ARCH_MXC
and COMPILE_TEST like all the other thermal drivers.

Signed-off-by: Peter Robinson <pbrobinson <at> gmail.com>
---
 drivers/thermal/Kconfig | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/thermal/Kconfig b/drivers/thermal/Kconfig
index 3c3dc4a..6b2f550 100644
--- a/drivers/thermal/Kconfig
+++ b/drivers/thermal/Kconfig
 <at>  <at>  -186,7 +186,7  <at>  <at>  config HISI_THERMAL

 config IMX_THERMAL
 	tristate "Temperature sensor driver for Freescale i.MX SoCs"
-	depends on CPU_THERMAL
+	depends on (ARCH_MXC && CPU_THERMAL && OF) || COMPILE_TEST
 	depends on MFD_SYSCON
 	depends on OF
 	help
--

-- 
2.7.4

--
To unsubscribe from this list: send the line "unsubscribe linux-pm" in
the body of a message to majordomo <at> vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

(Continue reading)

Peter Wu | 25 May 00:52 2016
Picon
Gravatar

[PATCH 0/4] nouveau fixes for RPM/Optimus-related hangs

Hi,

Here are two patches to fix an issue reported on kernel bugzilla (infinite loop
due to unchecked function) and a more important fix to fix hanging Optimus
machines when runtime PM is enabled (with pm/pci patches).

An older (obsolete) patch for the first issue was tested by the reporter:
https://bugzilla.kernel.org/show_bug.cgi?id=104791#c11
(it is replaced by "check for function 0x1B before using it").

The second issue will occur when:
 - A modern Optimus laptop is in use (designed for Windows 8 or newer).
 - nouveau runtime PM is enabled (1 or the default -1).
 - The patch "PCI: Add runtime PM support for PCIe ports" from Mika is pulled
   into v4.7 (or v4.8[1]?) via the pci/pm branch,
   https://git.kernel.org/cgit/linux/kernel/git/helgaas/pci.git/commit/?h=pci/pm&id=8b71f5652eeac561acf883da01ab4810f763ee42
(see also the discussion for "[PATCH] PCI: Power on bridges before scanning new
devices" at http://article.gmane.org/gmane.linux.power-management.general/76411)

The first two patches are just refactoring to reduce code duplication (and
scratch an itch) and make the following patches possible. The next two patches
fix the problems reported above.

I intend to get these patches in 4.7 (or the first version where pci/pm gets
merged) to avoid a lockup when runpm is enabled. Note:
 - If the fourth patch is merged before/without Mika's PCIe port patch, then
   those modern Optimus machines above will not be put into D3cold.
 - If the fourth patch is not merged (or merged after Mika's patch), then under
   the above conditions the affected machine can lock up.
 - The three other patches are unrelated to this issue and can safely be merged.
(Continue reading)

Linda Knippers | 24 May 22:37 2016

re: Enforce _PPC limits

Hi Srinivas,

I have a couple of questions about this patch set.
http://comments.gmane.org/gmane.linux.power-management.general/75263

Sorry I'm a bit late to the party but I've just booted 4.6 on my system
and noticed some things.

My first question is about enabling the feature by default on enterprise
and performance servers.  Is there any way to disable it on these servers?
I didn't see a way.  I'm always nervous when something starts looking at
a table that perhaps wasn't used before or introduces a new behavior that
might be unexpected.  Having a way out or not making it the default for a
while would be nice.

My second question is about the 48 instances I got of this when I booted my
2 socket, 48-CPU box:

> intel_pstate: _PPC limits will be enforced

I suppose in theory I could have limits for some CPUs and not others but
even in that case, the message isn't helpful.  I think it should be made
useful or go away, or at least only be printed once.

Thanks,

-- ljk
--
To unsubscribe from this list: send the line "unsubscribe linux-pm" in
the body of a message to majordomo <at> vger.kernel.org
(Continue reading)

Shreyas B. Prabhu | 24 May 15:15 2016
Picon

[PATCH v4 00/10] powerpc/powernv/cpuidle: Add support for POWER ISA v3 idle states

POWER ISA v3 defines a new idle processor core mechanism. In summary,
 a) new instruction named stop is added. This instruction replaces
	instructions like nap, sleep, rvwinkle.
 b) new per thread SPR named PSSCR is added which controls the behavior
	of stop instruction. 
		
PSSCR has following key fields
	Bits 0:3  - Power-Saving Level Status. This field indicates the
	lowest power-saving state the thread entered since stop
	instruction was last executed.
		
	Bit 42 - Enable State Loss                          
	0 - No state is lost irrespective of other fields  
	1 - Allows state loss
		
	Bits 44:47 - Power-Saving Level Limit      
	This limits the power-saving level that can be entered into.
		
	Bits 60:63 - Requested Level              
	Used to specify which power-saving level must be entered on
	executing stop instruction
		
Stop idle states and their properties like name, latency, target
residency, psscr value are exposed via device tree.

This patch series adds support for this new mechanism.

Patches 1-7 are cleanups and code movement.
Patch 8 adds platform specific support for stop and psscr handling.
Patch 9 adds cpuidle driver support.
(Continue reading)

Viresh Kumar | 24 May 06:56 2016
Gravatar

[PATCH] cpufreq: Send START policy notifier after sending CREATE

The sequence got a bit wrong as we are sending CPUFREQ_START notifier
even before we have sent CPUFREQ_CREATE_POLICY.

Fix it.

Signed-off-by: Viresh Kumar <viresh.kumar <at> linaro.org>
---
 drivers/cpufreq/cpufreq.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/cpufreq/cpufreq.c b/drivers/cpufreq/cpufreq.c
index 36bc11a106aa..c3f950f0e5f0 100644
--- a/drivers/cpufreq/cpufreq.c
+++ b/drivers/cpufreq/cpufreq.c
 <at>  <at>  -1265,9 +1265,6  <at>  <at>  static int cpufreq_online(unsigned int cpu)
 		}
 	}

-	blocking_notifier_call_chain(&cpufreq_policy_notifier_list,
-				     CPUFREQ_START, policy);
-
 	if (new_policy) {
 		ret = cpufreq_add_dev_interface(policy);
 		if (ret)
 <at>  <at>  -1280,6 +1277,9  <at>  <at>  static int cpufreq_online(unsigned int cpu)
 		write_unlock_irqrestore(&cpufreq_driver_lock, flags);
 	}

+	blocking_notifier_call_chain(&cpufreq_policy_notifier_list,
+				     CPUFREQ_START, policy);
(Continue reading)

Jacob Pan | 23 May 18:45 2016
Picon

[PATCH 0/2] Misc RAPL updates

A couple of small updates to support Skylake server and make it less
noisy on KVM.

Jacob Pan (2):
  powercap/rapl: add support for skx
  powercap/rapl: reduce warning level

 drivers/powercap/intel_rapl.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

--

-- 
1.9.1

--
To unsubscribe from this list: send the line "unsubscribe linux-pm" in
the body of a message to majordomo <at> vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Shreyas B. Prabhu | 23 May 17:18 2016
Picon

[PATCH v3 0/9] powerpc/powernv/cpuidle: Add support for POWER ISA v3 idle states

POWER ISA v3 defines a new idle processor core mechanism. In summary,
 a) new instruction named stop is added. This instruction replaces
	instructions like nap, sleep, rvwinkle.
 b) new per thread SPR named PSSCR is added which controls the behavior
	of stop instruction. 
		
PSSCR has following key fields
	Bits 0:3  - Power-Saving Level Status. This field indicates the
	lowest power-saving state the thread entered since stop
	instruction was last executed.
		
	Bit 42 - Enable State Loss                          
	0 - No state is lost irrespective of other fields  
	1 - Allows state loss
		
	Bits 44:47 - Power-Saving Level Limit      
	This limits the power-saving level that can be entered into.
		
	Bits 60:63 - Requested Level              
	Used to specify which power-saving level must be entered on
	executing stop instruction
		
Stop idle states and their properties like name, latency, target
residency, psscr value are exposed via device tree.

This patch series adds support for this new mechanism.

Patches 1-6 are cleanups and code movement.
Patch 7 adds platform specific support for stop and psscr handling.
Patch 8 adds cpuidle driver support.
(Continue reading)

Peter Zijlstra | 22 May 12:39 2016

Re: [RFC PATCH] Increase in idle power with schedutil

On Fri, May 20, 2016 at 05:53:41PM +0530, Shilpasri G Bhat wrote:
> 
> Below are the comparisons by disabling watchdog.
> Both schedutil and ondemand have a similar ramp-down trend. And in both the
> cases I can see that frequency of the cpu is not reduced in deterministic
> fashion. In a observation window of 30 seconds after running a workload I can
> see that the frequency is not ramped down on some cpus in the system and are
> idling at max frequency.

So does it actually matter what the frequency is when you idle? Isn't
the whole thing clock gated anyway?

Because this seems to generate contradictory requirements, on the one
hand we want to stay idle as long as possible while on the other hand
you seem to want to clock down while idle, which requires not being
idle.

If it matters; should not your idle state muck explicitly set/restore
frequency?
--
To unsubscribe from this list: send the line "unsubscribe linux-pm" in
the body of a message to majordomo <at> vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Kees Cook | 21 May 18:39 2016
Gravatar

Re: PROBLEM: Resume form hibernate broken by setting NX on gap

On Fri, May 20, 2016 at 6:57 PM, Logan Gunthorpe <logang <at> deltatee.com> wrote:
> On 20/05/16 04:16 PM, Kees Cook wrote:
>>
>> On Fri, May 20, 2016 at 2:59 PM, Kees Cook <keescook <at> chromium.org> wrote:
>>>
>>> On Fri, May 20, 2016 at 2:46 PM, Rafael J. Wysocki <rafael <at> kernel.org>
>>> wrote:
>>>>
>>>> On Fri, May 20, 2016 at 3:56 PM, Stephen Smalley <sds <at> tycho.nsa.gov>
>>>> wrote:
>>>>>
>>>>> On 05/20/2016 07:34 AM, Rafael J. Wysocki wrote:
>>>>>>
>>>>>> On Fri, May 20, 2016 at 9:15 AM, Ingo Molnar <mingo <at> kernel.org> wrote:
>>>>>>>
>>>>>>>
>>>>>>> * Logan Gunthorpe <logang <at> deltatee.com> wrote:
>>>>>>>
>>>>>>>> Hi,
>>>>>>>>
>>>>>>>> I have been working on a bug that causes my laptop to freeze during
>>>>>>>> resume from hibernation. I did a bisect to find the offending
>>>>>>>> commit:
>>>>>>>>
>>>>>>>> [ab76f7b4ab] x86/mm: Set NX on gap between __ex_table and rodata
>>>>>>>>
>>>>>>>> There is more information in the bugzilla report [1] that
>>>>>>>> I've been working on but I will summarize things below.
>>>>>>>>
>>>>>>>> I've experienced intermittent but reproducible freezes when resuming
(Continue reading)

Andrea Gelmini | 21 May 14:13 2016
Picon
Gravatar

[PATCH 0273/1529] Fix typo

Signed-off-by: Andrea Gelmini <andrea.gelmini <at> gelma.net>
---
 arch/x86/kernel/acpi/sleep.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/x86/kernel/acpi/sleep.c b/arch/x86/kernel/acpi/sleep.c
index adb3eaf..b3aff1a 100644
--- a/arch/x86/kernel/acpi/sleep.c
+++ b/arch/x86/kernel/acpi/sleep.c
 <at>  <at>  -30,7 +30,7  <at>  <at>  static char temp_stack[4096];
  * x86_acpi_enter_sleep_state - enter sleep state
  *  <at> state: Sleep state to enter.
  *
- * Wrapper around acpi_enter_sleep_state() to be called by assmebly.
+ * Wrapper around acpi_enter_sleep_state() to be called by assembly.
  */
 acpi_status asmlinkage __visible x86_acpi_enter_sleep_state(u8 state)
 {
--

-- 
2.8.2.534.g1f66975

--
To unsubscribe from this list: send the line "unsubscribe linux-pm" in
the body of a message to majordomo <at> vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Gmane