Puthikorn Voravootivat | 22 Oct 03:15 2014

[PATCH] bq27x00_battery: Call power_supply_changed only when capacity changed

In current driver, power_supply_changed() is called whenever any of
the battery attribute changed. This causes kernel to increases the
'/sys/power/wakeup_count' and make suspend not working correctly.

This patch change this behavior to call power_supply_changed()
only when the battery capacity changed.

Signed-off-by: Puthikorn Voravootivat <puthik <at> chromium.org>
Reviewed-by: David Riley <davidriley <at> chromium.org>
Reviewed-by: Benson Leung <bleung <at> chromium.org>
---
 drivers/power/bq27x00_battery.c | 7 ++++---
 1 file changed, 4 insertions(+), 3 deletions(-)

diff --git a/drivers/power/bq27x00_battery.c b/drivers/power/bq27x00_battery.c
index e3bacfe..7ab3de0 100644
--- a/drivers/power/bq27x00_battery.c
+++ b/drivers/power/bq27x00_battery.c
 <at>  <at>  -493,10 +493,11  <at>  <at>  static void bq27x00_update(struct bq27x00_device_info *di)
 			di->charge_design_full = bq27x00_battery_read_ilmd(di);
 	}

-	if (memcmp(&di->cache, &cache, sizeof(cache)) != 0) {
-		di->cache = cache;
+	if (di->cache.capacity != cache.capacity)
 		power_supply_changed(&di->bat);
-	}
+
+	if (memcmp(&di->cache, &cache, sizeof(cache)) != 0)
+		di->cache = cache;
(Continue reading)

Alexandre Belloni | 21 Oct 23:55 2014

[PATCH 0/8] ARM: at91: Remove mach/ includes from the reset driver

This series removes the mach/ headers dependency from the reset driver. It is
also laying some groundwork for the necessary power management support rework.

The first patch adds and export a function to shutdown the sdram from the sdramc
driver.

The second patch makes the sdramc driver usable from the board files.

The third patch actually registers the sdramc driver from the boards files.
The fourth patch does the same, only for sam9g45 and sam9rl to simplify future
merging as the board files have been removed. Simply drop that patch.

The fifth patch makes the at91-reset driver use the newly created
at91_ramc_shutdown() function and removes the mach/ headers inclusion.

Then the sixth and seven patch do some cleanup. Again, you can simply drop patch
7 when merging.

The last patch adds myself a the maintainer for those drivers.

Alexandre Belloni (8):
  memory: atmel-sdramc: export a shutdown function
  memory: atmel-sdramc: allow probing from pdata
  ARM: at91: sam9: probe the RAMC driver from pdata
  ARM: at91: sam9g45/sam9rl: probe the ramc driver
  power: reset: at91-reset: use at91_ramc_shutdown
  ARM: at91: sam9: remove useless resource for rstc
  ARM: at91: sam9g45/sam9rl: remove useless resources for rstc
  MAINTAINERS: add at91 power and memory entries

(Continue reading)

Michal Hocko | 21 Oct 09:27 2014
Picon

[PATCH 0/4 -v2] OOM vs. freezer interaction fixes

Hi Andrew, Rafael,

this has been originally discussed here [1] and previously posted here [2].
I have updated patches according to feedback from Oleg.

The first and third patch are regression fixes and they are a stable
material IMO. The second and fourth patch are simple cleanups.

The 1st patch is fixing a regression introduced in 3.3 since when OOM
killer is not able to kill any frozen task and live lock as a result.
The fix gets us back to the 3.2. As it turned out during the discussion [3]
this was still not 100% sufficient and that's why we need the 3rd patch.

I was thinking about the proper 1st vs. 3rd patch ordering because
the 1st patch basically opens a race window considerably reduced by the
later patch. This path is hard to do completely race free without a complete
synchronization of OOM path (including the allocator) and freezer which is not
worth the trouble.

Original patch from Cong Wang has covered this by checking
cgroup_freezing(current) in __refrigarator path [4]. But this approach
still suffers from OOM vs. PM freezer interaction (OOM killer would
still live lock waiting for a PM frozen task this time).

So I think the most straight forward way is to address only OOM vs.
frozen task interaction in the first patch, mark it for stable 3.3+ and
leave the race to a separate follow up patch which is applicable to
stable 3.2+ (before a3201227f803 made it inefficient).

Switching 1st and 3rd patches would make some sense as well but then
(Continue reading)

Daniel Lezcano | 20 Oct 18:25 2014

[PATCH 1/5] sched: idle: cpuidle: Check the latency req before idle

When the pmqos latency requirement is set to zero that means "poll in all the
cases".

That is correctly implemented on x86 but not on the other archs.

As how is written the code, if the latency request is zero, the governor will
return zero, so corresponding, for x86, to the poll function, but for the
others arch the default idle function. For example, on ARM this is wait-for-
interrupt with a latency of '1', so violating the constraint.

In order to fix that, do the latency requirement check *before* calling the
cpuidle framework in order to jump to the poll function without entering
cpuidle. That has several benefits:

 1. It clarifies and unifies the code
 2. It fixes x86 vs other archs behavior
 3. Factors out the call to the same function
 4. Prevent to enter the cpuidle framework with its expensive cost in
    calculation

As the latency_req is needed in all the cases, change the select API to take
the latency_req as parameter in case it is not equal to zero.

As a positive side effect, it introduces the latency constraint specified
externally, so one more step to the cpuidle/scheduler integration.

Signed-off-by: Daniel Lezcano <daniel.lezcano <at> linaro.org>
---
 drivers/cpuidle/cpuidle.c          |  5 +++--
 drivers/cpuidle/governors/ladder.c |  9 +--------
(Continue reading)

Krzysztof Kozlowski | 20 Oct 16:17 2014

[PATCH] power: charger-manager: Fix accessing invalidated thermal zone device after its unbind

Lock corruption happened after unbinding a driver which provided thermal
zone for charger manager.

The charger manager obtained in probe a reference to thermal zone device.
This device was used to report temperature in its own thermal zone and
get_temp call.

The thermal zone's reference was not updated even if device providing it was
unregistered (e.g. by unbinding a driver providing that thermal zone).  If such
driver was re-binded then charger manager would still use the old reference.

Reproduction:
1. 'cm-thermal-zone' present in DTS.
2. Fuel gauge driver not exporting temperature property.
$ echo "12-0036" > /sys/bus/i2c/drivers/max17042/unbind
$ cat /sys/devices/virtual/power_supply/battery/temp_ambient

[  153.450663] ------------[ cut here ]------------
[  153.455274] WARNING: CPU: 3 PID: 6 at kernel/locking/mutex.c:511 mutex_lock_nested+0x3c4/0x458()
[  153.464022] DEBUG_LOCKS_WARN_ON(l->magic != l)
[  153.468275] Modules linked in:
[  153.471493] CPU: 3 PID: 6 Comm: kworker/u8:0 Tainted: G        W     
3.17.0-next-20141020-00047-g54f3de817616-dirty #374
[  153.482432] Workqueue: charger_manager cm_monitor_poller
[  153.487752] [<c0014d2c>] (unwind_backtrace) from [<c0011c98>] (show_stack+0x10/0x14)
[  153.495457] [<c0011c98>] (show_stack) from [<c04da6dc>] (dump_stack+0x70/0xbc)
[  153.502670] [<c04da6dc>] (dump_stack) from [<c0022e94>] (warn_slowpath_common+0x64/0x88)
[  153.510732] [<c0022e94>] (warn_slowpath_common) from [<c0022f4c>] (warn_slowpath_fmt+0x30/0x40)
[  153.519413] [<c0022f4c>] (warn_slowpath_fmt) from [<c04dd8a8>] (mutex_lock_nested+0x3c4/0x458)
[  153.528006] [<c04dd8a8>] (mutex_lock_nested) from [<c03944e4>] (thermal_zone_get_temp+0x38/0x68)
(Continue reading)

Grygorii Strashko | 20 Oct 14:56 2014
Picon

[PATCH v2 0/3] ARM: keystone: pm: switch to use generic pm domains

Hi Santosh, Kevin,

This series switches Keystone 2 PM code to use Generic PM domains
instead of PM clock domains because of the lack of DT support
for the last.
It will finally allow to enable Runtime PM for Keystone 2.

Patch 1 was reused from [1].

RFC version of patches can be found at [2].

Changes in v2:
- minor comments applied and rebased on top of Linux 3.18-rc1.

Link on v1:
  https://lkml.org/lkml/2014/9/29/382

[1] "[PATCH/RFC 0/4] of: Register clocks for Runtime PM with PM core"
  https://lkml.org/lkml/2014/4/24/1118

[2] "[RFC PATCH 0/4] ARM: keystone: pm: switch to use generic pm domains"
  https://lkml.org/lkml/2014/9/25/364

Geert Uytterhoeven (1):
  PM / clock_ops: Add pm_clk_add_clk()

Grygorii Strashko (2):
  ARM: keystone: pm: switch to use generic pm domains
  ARM: dts: keystone: add generic pm controller node

(Continue reading)

Krzysztof Kozlowski | 20 Oct 11:04 2014

[PATCH v8 0/5] amba/dma: pl330: add Power Management support

Hi,

Changes since v7:
=================
1. Add reviewed-by Ulf Hansson (patches 3, 4 and 5).
2. Patch 2/5: Fix missing return in amba_pclk_prepare() (suggested by
   Ulf Hansson).
3. Rebased on next-20141020.

Changes since v6:
=================
1. Add patch 5 removing the amba_pclk_*able macros.
2. Patch 2/5: Remove IS_ERR, use static inline functions instead
   of macros.
3. Patch 4/5: Force runtime suspend/resume in system sleep
   callbacks. Put with autosuspend at end of probe instead of no_idle.
   Suggested by Ulf Hansson.

Changes since v5:
=================
1. Patch 1/4: Add Ulf Hansson's reviewed-by.
2. Patch 4/4: Use PM runtime autosuspend (suggested by Ulf Hansson).
3. Rebase on next-20140922. 

Changes since v4:
1. Patch 3/4: Explicitly initialize amba_device.irq_safe field after
   probing driver (suggested by Russell King).

Changes since v3:
1. Patch 1/4: Document new API in Documentation/power/runtime_pm.txt
(Continue reading)

Yao Dongdong | 20 Oct 10:27 2014

[PATCH 1/2] Thermal:Fix memory leak if occur goto unregister

Signed-off-by:yaodongdong <at> huawei.com

---
 drivers/thermal/thermal_core.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/thermal/thermal_core.c b/drivers/thermal/thermal_core.c
index 71b0ec0..5b7d466 100644
--- a/drivers/thermal/thermal_core.c
+++ b/drivers/thermal/thermal_core.c
 <at>  <at>  -1574,6 +1574,7  <at>  <at>  struct thermal_zone_device *thermal_zone_device_register(const char *type,
 unregister:
    release_idr(&thermal_tz_idr, &thermal_idr_lock, tz->id);
    device_unregister(&tz->device);
+   kfree(tz);
    return ERR_PTR(result);
 }
 EXPORT_SYMBOL_GPL(thermal_zone_device_register);
--
1.8.0.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

Stefan Wahren | 18 Oct 00:09 2014

[PATCH V2 0/2] cpufreq: cpufreq-dt: Improvements for set_target()

This patch series contains 2 improvements for set_target().

changes in V2:
  - rebase because of name change cpufreq-cpu0 to cpufreq-dt

Stefan Wahren (2):
  cpufreq: cpufreq-dt: Improve debug about matching OPP
  cpufreq: cpufreq-dt: Handle regulator_get_voltage() failure

 drivers/cpufreq/cpufreq-dt.c |    9 +++++++--
 1 file changed, 7 insertions(+), 2 deletions(-)

--

-- 
1.7.9.5

--
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

Prarit Bhargava | 17 Oct 14:12 2014
Picon

Re: [PATCH 1/2] cpufreq: serialize calls to __cpufreq_governor()


On 10/16/2014 06:58 AM, Viresh Kumar wrote:
> On 14 October 2014 22:42, Prarit Bhargava <prarit <at> redhat.com> wrote:
>> I spoke too soon :(  On a larger system (128 processors, 64 cores, two threads
>> each)) the system locks up in about 1 minute using Robert's test.  The
> 
> :(
> 
>> [ 2484.634827] NMI watchdog: BUG: soft lockup - CPU#31 stuck for 22s! [tee:34538]^M
>> [ 2484.634827] Modules linked in: sg nfsv3 rpcsec_gss_krb5 nfsv4 dns_resolver
>> nfs fscache cfg80211 rfkill x86_pkg_temp_thermal intel_powerclamp coretemp
>> kvm_intel kvm crct10dif_pclmul crc32_pclmul crc32c_intel ghash_clmulni_intel
>> aesni_intel lrw igb gf128mul iTCO_wdt ioatdma ptp glue_helper sb_edac
>> iTCO_vendor_support ablk_helper pps_core lpc_ich edac_core dca cryptd mfd_core
>> shpchp pcspkr i2c_i801 ipmi_si ipmi_msghandler wmi nfsd acpi_cpufreq auth_rpcgss
>> nfs_acl lockd grace sunrpc xfs libcrc32c sd_mod sr_mod cdrom crc_t10dif
>> crct10dif_common mgag200 syscopyarea sysfillrect sysimgblt i2c_algo_bit
>> drm_kms_helper ttm isci drm libsas ahci libahci scsi_transport_sas libata
>> i2c_core dm_mirror dm_region_hash dm_log dm_mod^M
>>
>> [ 2484.634850] CPU: 31 PID: 34538 Comm: tee Tainted: G             L 3.17.0+ #10^M
>> [ 2484.634851] Hardware name: Intel Corporation S2600CP/S2600CP, BIOS
>> RMLSDP.86I.00.29.D696.1311111329 11/11/2013^M
>> [ 2484.634851] task: ffff881010376c80 ti: ffff880804938000 task.ti:
>> ffff880804938000^M
>> [ 2484.634852] RIP: 0010:[<ffffffff814e65dc>]  [<ffffffff814e65dc>]
>> __cpufreq_governor+0x6c/0x2c0^M
>> [ 2484.634855] RSP: 0018:ffff88080493bc68  EFLAGS: 00000246^M
>> [ 2484.634856] RAX: 0000000000000001 RBX: ffffffff8165a622 RCX: 0000000000262988^M
>> [ 2484.634857] RDX: 0000000000000000 RSI: ffffffff81a72960 RDI: ffff88100db9b400^M
(Continue reading)

Prarit Bhargava | 17 Oct 14:09 2014
Picon

Re: [PATCH 1/2] cpufreq: serialize calls to __cpufreq_governor()


On 10/16/2014 06:57 AM, Viresh Kumar wrote:
> On 14 October 2014 17:12, Prarit Bhargava <prarit <at> redhat.com> wrote:
>> I've been running both my test and Robert's test for about 5 mins.  In Robert's
>> case I don't see any problems ... in my case I do occasionally get a system
>> panic because of the sysfs access race I described in the other thread (cpu 1
>> holds a sysfs file open, while cpu 2 changes the governor ...)
> 
> Can you give me the exact script? I wasn't able to reproduce it.

#!/bin/bash

i=0
while [ True ]; do
        i=$((i+1))
        echo "ondemand" > /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor &
        echo "performance" > /sys/devices/system/cpu/cpu1/cpufreq/scaling_governor &
        echo "ondemand" > /sys/devices/system/cpu/cpu1/cpufreq/scaling_governor &
        echo "performance" > /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor &
        if [ $((i % 100)) = 0 ]; then
                echo $i
        fi
done

P.
--
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)


Gmane