Re: [PATCH] pwm-backlight: Pinctrl-fy
On Wed, Oct 31, 2012 at 05:57:27PM +0200, Pantelis Antoniou wrote:
Enable pinctrl for pwm-backlight.
Signed-off-by: Pantelis Antoniou pa...@antoniou-consulting.com
---
drivers/video/backlight/pwm_bl.c | 7 +++
1 file changed, 7 insertions(+)
diff --git a/drivers/video/backlight/pwm_bl.c
b/drivers/video/backlight/pwm_bl.c
index 0c91023..f3b6194 100644
--- a/drivers/video/backlight/pwm_bl.c
+++ b/drivers/video/backlight/pwm_bl.c
@@ -20,6 +20,8 @@
#include linux/pwm.h
#include linux/pwm_backlight.h
#include linux/slab.h
+#include linux/pinctrl/consumer.h
+#include linux/err.h
struct pwm_bl_data {
struct pwm_device *pwm;
@@ -180,9 +182,14 @@ static int pwm_backlight_probe(struct platform_device
*pdev)
struct backlight_properties props;
struct backlight_device *bl;
struct pwm_bl_data *pb;
+ struct pinctrl *pinctrl;
unsigned int max;
int ret;
+ pinctrl = devm_pinctrl_get_select_default(pdev-dev);
+ if (IS_ERR(pinctrl))
+ dev_warn(pdev-dev, unable to select pin group\n);
+
I just saw this done in a similar way in some other driver and then
remembered your patch. When I reviewed this I wasn't sure if a warning
was good enough in this case. I've checked the kernel tree and it seems
like a majority handled this as failure instead of a warning. I took a
look at the pinctrl core and it seems like indeed if neither pinctrl is
enabled or if there isn't actually a pinmux configuration for a device,
then devm_pinctrl_get_select_default() will actually not return an
error, so in those cases where an error is returned it should actually
be handled as a fatal error.
I'm Cc'ing Linus Walleij, maybe he knows what to do.
Thierry
if (!data) {
ret = pwm_backlight_parse_dt(pdev-dev, defdata);
if (ret 0) {
--
1.7.12
pgpo7QeJNIOqx.pgp
Description: PGP signature
Re: [PATCH v2 06/10] pwm: pwm-tiehrpwm: Add device-tree binding support for EHRPWM driver
On Thu, Nov 08, 2012 at 01:23:13PM +0530, Philip, Avinash wrote: This patch 1. Add support for device-tree binding for EHRWPM driver. 2. Set size of pwm-cells set to 3 to support PWM channel number, PWM period polarity configuration from device tree. 3. Add enable/disable clock gating in PWM subsystem common config space. 4. When here set .owner member in platform_driver structure to THIS_MODULE. Signed-off-by: Philip, Avinash avinashphi...@ti.com Cc: Grant Likely grant.lik...@secretlab.ca Cc: Rob Herring rob.herr...@calxeda.com Cc: Rob Landley r...@landley.net --- Changes since v1: - Add separate patch for pinctrl support - Add conditional check for PWM subsystem clock enable. - Combined with HWMOD changes DT bindings. - Remove the custom of xlate support. :00 100644 000... aa2ed0a... A Documentation/devicetree/bindings/pwm/pwm-tiehrpwm.txt :100644 100644 d3c1dff... fba7f9b... Mdrivers/pwm/pwm-tiehrpwm.c .../devicetree/bindings/pwm/pwm-tiehrpwm.txt | 25 ++ drivers/pwm/pwm-tiehrpwm.c | 49 +++- 2 files changed, 72 insertions(+), 2 deletions(-) The same comments apply as for the pwm-tiecap driver patch. Thierry pgp2ryrW5NLON.pgp Description: PGP signature
Re: kswapd0: excessive CPU usage
Dne 9.11.2012 05:22, Seth Jennings napsal(a): On 11/02/2012 02:45 PM, Jiri Slaby wrote: On 11/02/2012 11:53 AM, Jiri Slaby wrote: On 11/02/2012 11:44 AM, Zdenek Kabelac wrote: Yes, applying this instead of the revert fixes the issue as well. I've applied this patch on 3.7.0-rc3 kernel - and I still see excessive CPU usage - mainly after suspend/resume Here is just simple kswapd backtrace from running kernel: Yup, this is what we were seeing with the former patch only too. Try to apply the other one too: https://patchwork.kernel.org/patch/1673231/ For me I would say, it is fixed by the two patches now. I won't be able to report later, since I'm leaving to a conference tomorrow. Damn it. It recurred right now, with both patches applied. After I started a java program which consumed some more memory. Though there are still 2 gigs free, kswap is spinning: [810b00da] __cond_resched+0x2a/0x40 [811318a0] shrink_slab+0x1c0/0x2d0 [8113478d] kswapd+0x66d/0xb60 [810a25d0] kthread+0xc0/0xd0 [816aa29c] ret_from_fork+0x7c/0xb0 [] 0x I'm also hitting this issue in v3.7-rc4. It appears that the last release not effected by this issue was v3.3. Bisecting the changes included for v3.4-rc1 showed that this commit introduced the issue: fe2c2a106663130a5ab45cb0e3414b52df2fff0c is the first bad commit commit fe2c2a106663130a5ab45cb0e3414b52df2fff0c Author: Rik van Riel r...@redhat.com Date: Wed Mar 21 16:33:51 2012 -0700 vmscan: reclaim at order 0 when compaction is enabled ... This is plausible since the issue seems to be in the kswapd + compaction realm. I've yet to figure out exactly what about this commit results in kswapd spinning. I would be interested if someone can confirm this finding. -- Seth On my system 3.7-rc4 the problem seems to be effectively solved by revert patch: https://lkml.org/lkml/2012/11/5/308 i.e. in 2 days uptime kswapd0 eats 6 seconds which is IMHO ok - I'm not observing any busy loops on CPU with kswapd0. Zdenek -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 08/10] pwm: pwm-tiehrpwm: Adding TBCLK gating support.
On Thu, Nov 08, 2012 at 01:23:15PM +0530, Philip, Avinash wrote:
Some platforms (like AM33XX) requires clock gating from control module
explicitly for TBCLK. Enabling of this clock required for the
functioning of the time base sub module in EHRPWM module. So adding
optional TBCLK handling if DT node populated with tbclkgating. This
helps the driver can coexist for Davinci platforms.
Signed-off-by: Philip, Avinash avinashphi...@ti.com
Cc: Grant Likely grant.lik...@secretlab.ca
Cc: Rob Herring rob.herr...@calxeda.com
Cc: Rob Landley r...@landley.net
---
Changes since v1:
- Moved TBCLK enable from probe to .pwm_enable disable from
remove to .pwm_disable
:100644 100644 07911e6... 927a8ed... Mdrivers/pwm/pwm-tiehrpwm.c
drivers/pwm/pwm-tiehrpwm.c | 22 ++
1 files changed, 22 insertions(+), 0 deletions(-)
diff --git a/drivers/pwm/pwm-tiehrpwm.c b/drivers/pwm/pwm-tiehrpwm.c
index 07911e6..927a8ed 100644
--- a/drivers/pwm/pwm-tiehrpwm.c
+++ b/drivers/pwm/pwm-tiehrpwm.c
@@ -126,6 +126,7 @@ struct ehrpwm_pwm_chip {
void __iomem*mmio_base;
unsigned long period_cycles[NUM_PWM_CHANNEL];
enum pwm_polarity polarity[NUM_PWM_CHANNEL];
+ struct clk *tbclk;
};
static inline struct ehrpwm_pwm_chip *to_ehrpwm_pwm_chip(struct pwm_chip
*chip)
@@ -346,6 +347,13 @@ static int ehrpwm_pwm_enable(struct pwm_chip *chip,
struct pwm_device *pwm)
/* Channels polarity can be configured from action qualifier module */
configure_polarity(pc, pwm-hwpwm);
+ /*
+ * Platforms require explicit clock enabling of TBCLK has
+ * to enable TBCLK explicitly before enabling PWM device
+ */
+ if (pc-tbclk)
+ clk_enable(pc-tbclk);
+
/* Enable time counter for free_run */
ehrpwm_modify(pc-mmio_base, TBCTL, TBCTL_RUN_MASK, TBCTL_FREE_RUN);
return 0;
@@ -374,6 +382,10 @@ static void ehrpwm_pwm_disable(struct pwm_chip *chip,
struct pwm_device *pwm)
ehrpwm_modify(pc-mmio_base, AQCSFRC, aqcsfrc_mask, aqcsfrc_val);
+ /* Disabling TBCLK on PWM disable */
+ if (pc-tbclk)
+ clk_disable(pc-tbclk);
+
/* Stop Time base counter */
ehrpwm_modify(pc-mmio_base, TBCTL, TBCTL_RUN_MASK, TBCTL_STOP_NEXT);
@@ -464,6 +476,16 @@ static int __devinit ehrpwm_pwm_probe(struct
platform_device *pdev)
dev_err(pdev-dev, pwmchip_add() failed: %d\n, ret);
return ret;
}
+
+ /* Some platforms require explicit tbclk gating */
+ if (of_property_read_bool(pdev-dev.of_node, tbclkgating)) {
Is it really necessary to have an extra boolean property for this?
Couldn't this just be handled by not defining a clock for the tbclk
consumer in board setup/DT
+ pc-tbclk = clk_get(pdev-dev, tbclk);
You should be using devm_clk_get() or add a matching clk_put() in
.remove().
Thierry
pgpVSj05EXCSr.pgp
Description: PGP signature
Re: [PATCH v2 04/10] pwm: pwm-tiecap: Add device-tree binding support for APWM driver
On Fri, Nov 09, 2012 at 08:52:19AM +0100, Thierry Reding wrote: On Thu, Nov 08, 2012 at 01:23:11PM +0530, Philip, Avinash wrote: [...] static int __devinit ecap_pwm_probe(struct platform_device *pdev) __devinit can go away. [...] static int __devexit ecap_pwm_remove(struct platform_device *pdev) No __devexit please. [...] .remove = __devexit_p(ecap_pwm_remove), No __devexit_p() please. Okay, ignore these comments. The annotation were not added in this patch so they can be removed in a separate patch. Or when Greg finally removes all traces of them. Thierry pgpWo93u7PMsR.pgp Description: PGP signature
Re: [PATCH V3] memcg, oom: provide more precise dump info while memcg oom happening
(2012/11/09 0:52), Sha Zhengju wrote: From: Sha Zhengju handai@taobao.com Current when a memcg oom is happening the oom dump messages is still global state and provides few useful info for users. This patch prints more pointed memcg page statistics for memcg-oom. We set up a simple cgroup hierarchy for test: root_memcg | 1 (use_hierachy=1, with a process) | 2 (its process will be killed by memcg oom) Following are samples of oom output: (1)Before change: [ 295.754215] mal invoked oom-killer: gfp_mask=0xd0, order=0, oom_score_adj=0 [ 295.754219] mal cpuset=/ mems_allowed=0-1 [ 295.754221] Pid: 4623, comm: mal Not tainted 3.6.0+ #26 [ 295.754223] Call Trace: [ 295.754230] [8111b9c4] dump_header+0x84/0xd0 [ 295.754233] [8111c691] oom_kill_process+0x331/0x350 . (call trace) [ 295.754288] [815171e5] page_fault+0x25/0x30 [ 295.754291] Task in /1/2 killed as a result of limit of /1 [ 295.754293] memory: usage 511640kB, limit 512000kB, failcnt 4471 [ 295.754294] memory+swap: usage 563200kB, limit 563200kB, failcnt 22 [ 295.754296] kmem: usage 0kB, limit 9007199254740991kB, failcnt 0 [ 295.754297] Mem-Info: [ 295.754298] Node 0 DMA per-cpu:print per cpu pageset stat [ 295.754300] CPU0: hi:0, btch: 1 usd: 0 .. [ 295.754302] CPU15: hi:0, btch: 1 usd: 0 [ 295.754448] Node 0 DMA32 per-cpu: [ 295.754450] CPU0: hi: 186, btch: 31 usd: 181 .. [ 295.754451] CPU15: hi: 186, btch: 31 usd: 25 [ 295.754470] Node 0 Normal per-cpu: [ 295.754472] CPU0: hi: 186, btch: 31 usd: 56 .. [ 295.754473] CPU15: hi: 186, btch: 31 usd: 150 [ 295.754493] Node 1 Normal per-cpu: [ 295.754495] CPU0: hi: 186, btch: 31 usd: 0 .. [ 295.754496] CPU15: hi: 186, btch: 31 usd: 0 print global page state [ 295.754519] active_anon:57756 inactive_anon:73437 isolated_anon:0 [ 295.754519] active_file:2659 inactive_file:14291 isolated_file:0 [ 295.754519] unevictable:1268 dirty:0 writeback:4961 unstable:0 [ 295.754519] free:5979740 slab_reclaimable:2955 slab_unreclaimable:5460 [ 295.754519] mapped:2478 shmem:62 pagetables:994 bounce:0 [ 295.754519] free_cma:0 print per zone page state [ 295.754522] Node 0 DMA free:15884kB min:56kB low:68kB high:84kB active_anon:0kB inactive_anon:0kB active_file:0kB inactive_file:0kB unevictable:0kB isolated(anon):0kB isolated(file):0kB present:15884kB mlocked:0kB dirty:0kB writeback:0kB mapped:0kB shmem:0kB slab_reclaimable:0kB slab_unreclaimable:0kB kernel_stack:0kB pagetables:0kB unstable:0kB bounce:0kB free_cma:0kB writeback_tmp:0kB pages_scanned:0 all_unreclaimable? no [ 295.754527] lowmem_reserve[]: 0 2966 12013 12013 [ 295.754530] Node 0 DMA32 free:3041228kB min:11072kB . [ 295.754535] lowmem_reserve[]: 0 0 9046 9046 [ 295.754537] Node 0 Normal free:8616716kB min:33756kB . [ 295.754542] lowmem_reserve[]: 0 0 0 0 [ 295.754545] Node 1 Normal free:12245132kB min:45220kB [ 295.754550] lowmem_reserve[]: 0 0 0 0 [ 295.754552] Node 0 DMA: 1*4kB (U) 1*8kB (U) 0*16kB 0*32kB 2*64kB (U) 1*128kB (U) 1*256kB (U) 0*512kB 1*1024kB (U) 1*2048kB (R) 3*4096kB (M) = 15884kB [ 295.754563] Node 0 DMA32: 5*4kB (M) 3*8kB (M) 6*16kB (UM) ... 738*4096kB (MR) = 3041228kB [ 295.754574] Node 0 Normal: 16*4kB (EM) 165*8kB (UEM) ... 2101*4096kB (MR) = 8616840kB [ 295.754586] Node 1 Normal: 768*4kB (UEM) 924*8kB (UEM) ... 048kB (EM) 2976*4096kB (MR) = 12245264kB [ 295.754598] 25266 total pagecache pages [ 295.754599] 7227 pages in swap cache print global swap cache stat [ 295.754600] Swap cache stats: add 21474, delete 14247, find 533/576 [ 295.754601] Free swap = 2016000kB [ 295.754602] Total swap = 2096444kB [ 295.816119] 6291440 pages RAM [ 295.816121] 108291 pages reserved [ 295.816122] 9427 pages shared [ 295.816123] 195843 pages non-shared [ 295.816124] [ pid ] uid tgid total_vm rss nr_ptes swapents oom_score_adj name [ 295.816161] [ 4569] 0 456916626 475 18 30 0 bash [ 295.816164] [ 4622] 0 4622 10332887541 20814950 0 mal [ 295.816167] [ 4623] 0 4623 10332833468 85 5162 0 mal [ 295.816171] Memory cgroup out of memory: Kill process 4622 (mal) score 699 or sacrifice child [ 295.816173] Killed process 4622 (mal) total-vm:413312kB, anon-rss:349872kB, file-rss:292kB We can see that messages dumped by show_free_areas() are longsome and can provide so limited info for memcg that just happen oom. (2) After change [ 269.225628] mal invoked oom-killer:
Re: [PATCH] firmware loader: Fix the concurrent request_firmware() race for kref_get/put
On Fri, Nov 9, 2012 at 8:28 PM, Chuansheng Liu chuansheng@intel.com wrote:
There is one race that both request_firmware() with the same
firmware name.
The race scenerio is as below:
CPU1 CPU2
request_firmware() --
_request_firmware_load() return err another
request_firmware() is coming --
_request_firmware_cleanup is called --
_request_firmware_prepare --
release_firmware ---
fw_lookup_and_allocate_buf --
spin_lock(fwc-lock)
... __fw_lookup_buf()
return true
fw_free_buf() will be called -- ...
kref_put --
decrease the refcount to 0
kref_get(tmp-ref) ==
it will trigger warning
due to refcount == 0
__fw_free_buf() --
... spin_unlock(fwc-lock)
spin_lock(fwc-lock)
list_del(buf-list)
spin_unlock(fwc-lock)
kfree(buf)
After that, the freed
buf will be used.
The key race is decreasing refcount to 0 and list_del is not protected
together by
fwc-lock, and it is possible another thread try to get it between refcount==0
and list_del.
Fix it here to protect it together.
Good catch, the reference count and the list operation should be atomic.
Signed-off-by: liu chuansheng chuansheng@intel.com
---
drivers/base/firmware_class.c |6 --
1 files changed, 4 insertions(+), 2 deletions(-)
diff --git a/drivers/base/firmware_class.c b/drivers/base/firmware_class.c
index b44ed35..7df32cd 100644
--- a/drivers/base/firmware_class.c
+++ b/drivers/base/firmware_class.c
@@ -246,7 +246,6 @@ static void __fw_free_buf(struct kref *ref)
__func__, buf-fw_id, buf, buf-data,
(unsigned int)buf-size);
- spin_lock(fwc-lock);
list_del(buf-list);
spin_unlock(fwc-lock);
@@ -263,7 +262,10 @@ static void __fw_free_buf(struct kref *ref)
static void fw_free_buf(struct firmware_buf *buf)
{
- kref_put(buf-ref, __fw_free_buf);
+ struct firmware_cache *fwc = buf-fwc;
+ spin_lock(fwc-lock);
+ if(!kref_put(buf-ref, __fw_free_buf))
$./scripts/checkpatch.pl
ERROR: space required before the open parenthesis '('
#97: FILE: drivers/base/firmware_class.c:267:
+ if(!kref_put(buf-ref, __fw_free_buf))
+ spin_unlock(fwc-lock);
}
/* direct firmware loading support */
After fixing the patch style error, you can add my ack:
Acked-by: Ming Lei ming@canonical.com
Thanks,
---
Ming Lei
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
RE: [PATCH] firmware loader: Fix the concurrent request_firmware() race for kref_get/put
$./scripts/checkpatch.pl
ERROR: space required before the open parenthesis '('
#97: FILE: drivers/base/firmware_class.c:267:
+ if(!kref_put(buf-ref, __fw_free_buf))
+ spin_unlock(fwc-lock);
}
/* direct firmware loading support */
After fixing the patch style error, you can add my ack:
Thanks your pointing out, fix it soon.
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH V2] firmware loader: Fix the concurrent request_firmware() race for kref_get/put
There is one race that both request_firmware() with the same
firmware name.
The race scenerio is as below:
CPU1 CPU2
request_firmware() --
_request_firmware_load() return err another
request_firmware() is coming --
_request_firmware_cleanup is called -- _request_firmware_prepare
--
release_firmware ---
fw_lookup_and_allocate_buf --
spin_lock(fwc-lock)
... __fw_lookup_buf() return
true
fw_free_buf() will be called -- ...
kref_put --
decrease the refcount to 0
kref_get(tmp-ref) ==
it will trigger warning
due to refcount == 0
__fw_free_buf() --
... spin_unlock(fwc-lock)
spin_lock(fwc-lock)
list_del(buf-list)
spin_unlock(fwc-lock)
kfree(buf)
After that, the freed buf
will be used.
The key race is decreasing refcount to 0 and list_del is not protected together
by
fwc-lock, and it is possible another thread try to get it between refcount==0
and list_del.
Fix it here to protect it together.
Acked-by: Ming Lei ming@canonical.com
Signed-off-by: liu chuansheng chuansheng@intel.com
---
drivers/base/firmware_class.c |6 --
1 files changed, 4 insertions(+), 2 deletions(-)
diff --git a/drivers/base/firmware_class.c b/drivers/base/firmware_class.c
index b44ed35..be5f7aa 100644
--- a/drivers/base/firmware_class.c
+++ b/drivers/base/firmware_class.c
@@ -246,7 +246,6 @@ static void __fw_free_buf(struct kref *ref)
__func__, buf-fw_id, buf, buf-data,
(unsigned int)buf-size);
- spin_lock(fwc-lock);
list_del(buf-list);
spin_unlock(fwc-lock);
@@ -263,7 +262,10 @@ static void __fw_free_buf(struct kref *ref)
static void fw_free_buf(struct firmware_buf *buf)
{
- kref_put(buf-ref, __fw_free_buf);
+ struct firmware_cache *fwc = buf-fwc;
+ spin_lock(fwc-lock);
+ if (!kref_put(buf-ref, __fw_free_buf))
+ spin_unlock(fwc-lock);
}
/* direct firmware loading support */
--
1.7.0.4
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] pwm: Device tree support for PWM polarity.
On Mon, Oct 29, 2012 at 11:10:27PM +0530, Philip, Avinash wrote:
From: Philip, Avinash avinashphi...@ti.com
Adds support for 3rd cell in pwm-specifier. PWM polarity is encoded in
device tree support in bit encoded form. Platforms require polarity of
PWM device initialized during PWM device initialization has to encode
polarity in 3rd cell of pwm-specifier.
Signed-off-by: Philip, Avinash avinashphi...@ti.com
---
:100644 100644 73ec962... e522c59... M
Documentation/devicetree/bindings/pwm/pwm.txt
:100644 100644 f5acdaa... 1c6d50b... Mdrivers/pwm/core.c
:100644 100644 112b314... d77c5b3... Minclude/linux/pwm.h
Documentation/devicetree/bindings/pwm/pwm.txt | 22 +++---
drivers/pwm/core.c| 13 -
include/linux/pwm.h |7 +++
3 files changed, 38 insertions(+), 4 deletions(-)
diff --git a/Documentation/devicetree/bindings/pwm/pwm.txt
b/Documentation/devicetree/bindings/pwm/pwm.txt
index 73ec962..e522c59 100644
--- a/Documentation/devicetree/bindings/pwm/pwm.txt
+++ b/Documentation/devicetree/bindings/pwm/pwm.txt
@@ -37,10 +37,26 @@ device:
pwm-names = backlight;
};
+Note that in the example above, specifying the pwm-names is redundant
+because the name backlight would be used as fallback anyway.
+
pwm-specifier typically encodes the chip-relative PWM number and the PWM
-period in nanoseconds. Note that in the example above, specifying the
-pwm-names is redundant because the name backlight would be used as
-fallback anyway.
+period in nanoseconds.
Can you separate this by a blank line, please?
+Optional pwm-specifier can be encoded in 3rd cell in bit encoded form.
+ -
+| Property | BIT position | Encoding |
+|-|
+| Polarity | 0 | Set - Polarity inversed |
+|| | Clear - Polarity Normal |
+ -
+
Using this kind of table isn't very common in device tree documentation
and the description above the table is a little vague. Maybe something
like this would be more explicit:
---[snip]---
Optionally, the pwm-specifier can encode a number of flags in a third
cell:
- bit 0: PWM signal polarity (0: normal polarity, 1: inverse polarity)
---[snip]---
+Exapmple with optional PWM specifier for inversed polarity
Example
+
+ bl: backlight {
+ pwms = pwm 0 500 1;
+ pwm-names = backlight;
+ };
+
2) PWM controller nodes
---
diff --git a/drivers/pwm/core.c b/drivers/pwm/core.c
index f5acdaa..1c6d50b 100644
--- a/drivers/pwm/core.c
+++ b/drivers/pwm/core.c
@@ -146,6 +146,15 @@ of_pwm_simple_xlate(struct pwm_chip *pc, const struct
of_phandle_args *args)
pwm_set_period(pwm, args-args[1]);
+ if (pc-of_pwm_n_cells 2) {
+ enum pwm_polarity polarity;
+
+ /* Initialize polarity of PWM device */
+ polarity = args-args[2] POLARITY_BIT ?
+ PWM_POLARITY_INVERSED : PWM_POLARITY_NORMAL;
Can we rewrite this as:
if (args-args[2] POLARITY_BIT)
pwm_set_polarity(pwm, PWM_POLARITY_INVERSED);
else
pwm_set_polarity(pwm, PWM_POLARITY_NORMAL);
?
+ pwm_set_polarity(pwm, polarity);
+ }
+
return pwm;
}
@@ -156,7 +165,9 @@ static void of_pwmchip_add(struct pwm_chip *chip)
if (!chip-of_xlate) {
chip-of_xlate = of_pwm_simple_xlate;
- chip-of_pwm_n_cells = 2;
+
+ if (chip-of_pwm_n_cells != 3)
+ chip-of_pwm_n_cells = 2;
}
I don't like the implicitness in this code. I think we should make this
more explicit for driver writers, so that if .of_xlate is set to NULL,
the default of_pwm_simple_xlate() is used. For all other cases we should
export of_pwm_xlate_with_flags(), so that the driver can explicitly set
the .of_xlate field to that function.
That will of course imply that the extra code that you added to
of_pwm_simple_xlate() is moved into a separate function.
of_node_get(chip-dev-of_node);
diff --git a/include/linux/pwm.h b/include/linux/pwm.h
index 112b314..d77c5b3 100644
--- a/include/linux/pwm.h
+++ b/include/linux/pwm.h
@@ -78,6 +78,13 @@ enum {
PWMF_ENABLED = 1 1,
};
+/*
+ * DT Platform property support.
+ * POLARITY - set bit 0 in DT platform property
+ */
+
+#define POLARITY_BIT BIT(0)
+
This doesn't belong in a public header. It should be defined in the
core.c source file. Maybe rename it to something like PWM_SPEC_POLARITY
to make it more obvious that it defines a bit in the PWM specifier. You
can reduce the comment to a single line, because the second
Re: [RFC v3 0/3] vmpressure_fd: Linux VM pressure notifications
Hi Anton, On Wed, 7 Nov 2012 02:53:49 -0800 Anton Vorontsov anton.voront...@linaro.org wrote: Hi all, This is the third RFC. As suggested by Minchan Kim, the API is much simplified now (comparing to vmevent_fd): Which tree is this against? I'd like to try this series, but it doesn't apply to Linus tree. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Revert mm: vmscan: scale number of pages reclaimed by reclaim/compaction based on failures
On Tue, Nov 06, 2012 at 11:15:54AM +0100, Johannes Hirte wrote:
Am Mon, 5 Nov 2012 14:24:49 +
schrieb Mel Gorman mgor...@suse.de:
Jiri Slaby reported the following:
(It's an effective revert of mm: vmscan: scale number of
pages reclaimed by reclaim/compaction based on failures.) Given
kswapd had hours of runtime in ps/top output yesterday in the morning
and after the revert it's now 2 minutes in sum for the last
24h, I would say, it's gone.
The intention of the patch in question was to compensate for the loss
of lumpy reclaim. Part of the reason lumpy reclaim worked is because
it aggressively reclaimed pages and this patch was meant to be a sane
compromise.
When compaction fails, it gets deferred and both compaction and
reclaim/compaction is deferred avoid excessive reclaim. However, since
commit c6543459 (mm: remove __GFP_NO_KSWAPD), kswapd is woken up each
time and continues reclaiming which was not taken into account when
the patch was developed.
Attempts to address the problem ended up just changing the shape of
the problem instead of fixing it. The release window gets closer and
while a THP allocation failing is not a major problem, kswapd chewing
up a lot of CPU is. This patch reverts mm: vmscan: scale number of
pages reclaimed by reclaim/compaction based on failures and will be
revisited in the future.
Signed-off-by: Mel Gorman mgor...@suse.de
---
mm/vmscan.c | 25 -
1 file changed, 25 deletions(-)
diff --git a/mm/vmscan.c b/mm/vmscan.c
index 2624edc..e081ee8 100644
--- a/mm/vmscan.c
+++ b/mm/vmscan.c
@@ -1760,28 +1760,6 @@ static bool in_reclaim_compaction(struct
scan_control *sc) return false;
}
-#ifdef CONFIG_COMPACTION
-/*
- * If compaction is deferred for sc-order then scale the number of
pages
- * reclaimed based on the number of consecutive allocation failures
- */
-static unsigned long scale_for_compaction(unsigned long
pages_for_compaction,
- struct lruvec *lruvec, struct scan_control
*sc) -{
- struct zone *zone = lruvec_zone(lruvec);
-
- if (zone-compact_order_failed = sc-order)
- pages_for_compaction = zone-compact_defer_shift;
- return pages_for_compaction;
-}
-#else
-static unsigned long scale_for_compaction(unsigned long
pages_for_compaction,
- struct lruvec *lruvec, struct scan_control
*sc) -{
- return pages_for_compaction;
-}
-#endif
-
/*
* Reclaim/compaction is used for high-order allocation requests. It
reclaims
* order-0 pages before compacting the zone.
should_continue_reclaim() returns @@ -1829,9 +1807,6 @@ static inline
bool should_continue_reclaim(struct lruvec *lruvec,
* inactive lists are large enough, continue reclaiming
*/
pages_for_compaction = (2UL sc-order);
-
- pages_for_compaction =
scale_for_compaction(pages_for_compaction,
- lruvec, sc);
inactive_lru_pages = get_lru_size(lruvec, LRU_INACTIVE_FILE);
if (nr_swap_pages 0)
inactive_lru_pages += get_lru_size(lruvec,
LRU_INACTIVE_ANON); --
Even with this patch I see kswapd0 very often on top. Much more than
with kernel 3.6.
How severe is the CPU usage? The higher usage can be explained by mm:
remove __GFP_NO_KSWAPD which allows kswapd to compact memory to reduce
the amount of time processes spend in compaction but will result in the
CPU cost being incurred by kswapd.
Is it really high like the bug was reporting with high usage over long
periods of time or do you just see it using 2-6% of CPU for short
periods?
Thanks.
--
Mel Gorman
SUSE Labs
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [alsa-devel] [PATCH V6 12/15] ALSA: HDA: Make hda sound card usable for Loongson
On 17/08/12 11:09, Takashi Iwai wrote: At Fri, 17 Aug 2012 16:43:32 +0800, Huacai Chen wrote: Lemote A1004(Laptop) and A1205(All-In-One) use Conexant's hda codec, this patch modify patch_conexant.c to add Lemote specific code. Both A1004 and A1205 use the same pin configurations, but A1004 need to increase the default boost of internal mic. Signed-off-by: Jie Chench...@lemote.com Signed-off-by: Huacai Chenche...@lemote.com Signed-off-by: Hongliang Taota...@lemote.com Signed-off-by: Hua Yany...@lemote.com Cc:alsa-de...@alsa-project.org Looks good. Reviewed-by: Takashi Iwaiti...@suse.de Should I apply it to sound git tree or all patches will go through mips tree? thanks, Takashi Hi Takashi, did you take this patch ? I will queue several of the other patches from the series for 3.8 and let them go upstream via the mips tree. We have this patch open in the linux-mips patchwork. I would set it to Other Subsystem if you took it already. Thanks, John -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: kswapd0: excessive CPU usage
On Thu, Nov 08, 2012 at 10:22:05PM -0600, Seth Jennings wrote: On 11/02/2012 02:45 PM, Jiri Slaby wrote: On 11/02/2012 11:53 AM, Jiri Slaby wrote: On 11/02/2012 11:44 AM, Zdenek Kabelac wrote: Yes, applying this instead of the revert fixes the issue as well. I've applied this patch on 3.7.0-rc3 kernel - and I still see excessive CPU usage - mainly after suspend/resume Here is just simple kswapd backtrace from running kernel: Yup, this is what we were seeing with the former patch only too. Try to apply the other one too: https://patchwork.kernel.org/patch/1673231/ For me I would say, it is fixed by the two patches now. I won't be able to report later, since I'm leaving to a conference tomorrow. Damn it. It recurred right now, with both patches applied. After I started a java program which consumed some more memory. Though there are still 2 gigs free, kswap is spinning: [810b00da] __cond_resched+0x2a/0x40 [811318a0] shrink_slab+0x1c0/0x2d0 [8113478d] kswapd+0x66d/0xb60 [810a25d0] kthread+0xc0/0xd0 [816aa29c] ret_from_fork+0x7c/0xb0 [] 0x I'm also hitting this issue in v3.7-rc4. It appears that the last release not effected by this issue was v3.3. Bisecting the changes included for v3.4-rc1 showed that this commit introduced the issue: fe2c2a106663130a5ab45cb0e3414b52df2fff0c is the first bad commit commit fe2c2a106663130a5ab45cb0e3414b52df2fff0c Author: Rik van Riel r...@redhat.com Date: Wed Mar 21 16:33:51 2012 -0700 vmscan: reclaim at order 0 when compaction is enabled ... This is plausible since the issue seems to be in the kswapd + compaction realm. I've yet to figure out exactly what about this commit results in kswapd spinning. I would be interested if someone can confirm this finding. I cannot confirm the actual finding as I don't see the same sort of problems. However, this does make sense and was more or less expected. Reclaiming at order-0 would have forced compaction to be used more instead of lumpy reclaim (less CPU usage but greater system distruption that is harder to measure). Shortly after, lumpy reclaim was removed entirely so now larger amounts of CPU time is spent compacting memory that previously would have been reclaimed. -- Mel Gorman SUSE Labs -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [alsa-devel] [PATCH V6 12/15] ALSA: HDA: Make hda sound card usable for Loongson
At Fri, 09 Nov 2012 09:36:34 +0100, John Crispin wrote: On 17/08/12 11:09, Takashi Iwai wrote: At Fri, 17 Aug 2012 16:43:32 +0800, Huacai Chen wrote: Lemote A1004(Laptop) and A1205(All-In-One) use Conexant's hda codec, this patch modify patch_conexant.c to add Lemote specific code. Both A1004 and A1205 use the same pin configurations, but A1004 need to increase the default boost of internal mic. Signed-off-by: Jie Chench...@lemote.com Signed-off-by: Huacai Chenche...@lemote.com Signed-off-by: Hongliang Taota...@lemote.com Signed-off-by: Hua Yany...@lemote.com Cc:alsa-de...@alsa-project.org Looks good. Reviewed-by: Takashi Iwaiti...@suse.de Should I apply it to sound git tree or all patches will go through mips tree? thanks, Takashi Hi Takashi, did you take this patch ? I will queue several of the other patches from the series for 3.8 and let them go upstream via the mips tree. We have this patch open in the linux-mips patchwork. I would set it to Other Subsystem if you took it already. Yes, this was already merged in sound git tree for 3.8. thanks, Takashi -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] virtio-scsi: Fix incorrect lock release order in virtscsi_kick_cmd
Il 09/11/2012 07:29, Nicholas A. Bellinger ha scritto: From: Nicholas Bellinger n...@linux-iscsi.org This patch fixes a regression bug in virtscsi_kick_cmd() that relinquishes the acquired spinlocks in the incorrect order using the wrong spin_unlock macros, namely releasing vq-vq_lock before tgt-tgt_lock while invoking the calls to virtio_ring.c:virtqueue_add_buf() and friends. This bug was originally introduced in v3.5-rc7 code with: commit 2bd37f0fde99cbf8b78fb55f1128e8c3a63cf1da Author: Paolo Bonzini pbonz...@redhat.com Date: Wed Jun 13 16:56:34 2012 +0200 [SCSI] virtio-scsi: split scatterlist per target Go ahead and make sure that vq-vq_lock is relinquished w/ spin_unlock first, then release tgt-tgt_lock w/ spin_unlock_irqrestore. That's done on purpose. After you do virtqueue_add_buf, you don't need the sg list anymore, nor the lock that protects it. The cover letter is at https://lkml.org/lkml/2012/6/13/295 and had this text: This series reorganizes the locking in virtio-scsi, introducing separate scatterlists for each target and pipelining the locks so that one command can be queued while the other is prepared. This improves performance when there are multiple in-flight operations. In fact, the patch _introduces_ wrong locking because virtqueue_kick_prepare needs the vq_lock. Perhaps what you want is separate local_irq_save/local_irq_restore? Paolo Cc: Paolo Bonzini pbonz...@redhat.com Cc: James Bottomley jbottom...@parallels.com Cc: Christoph Hellwig h...@lst.de Cc: sta...@vger.kernel.org Signed-off-by: Nicholas Bellinger n...@linux-iscsi.org --- drivers/scsi/virtio_scsi.c |4 ++-- 1 files changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/scsi/virtio_scsi.c b/drivers/scsi/virtio_scsi.c index 595af1a..b2abb8a 100644 --- a/drivers/scsi/virtio_scsi.c +++ b/drivers/scsi/virtio_scsi.c @@ -417,11 +417,11 @@ static int virtscsi_kick_cmd(struct virtio_scsi_target_state *tgt, spin_lock(vq-vq_lock); ret = virtqueue_add_buf(vq-vq, tgt-sg, out_num, in_num, cmd, gfp); - spin_unlock(tgt-tgt_lock); + spin_unlock(vq-vq_lock); if (ret = 0) ret = virtqueue_kick_prepare(vq-vq); - spin_unlock_irqrestore(vq-vq_lock, flags); + spin_unlock_irqrestore(tgt-tgt_lock, flags); if (ret 0) virtqueue_notify(vq-vq); -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH V2 RESEND RFC 2/3] kvm: Handle yield_to failure return code for potential undercommit case
Handle yield_to failure return code for potential undercommit case
From: Raghavendra K T raghavendra...@linux.vnet.ibm.com
yield_to returns -ESRCH when When source and target of yield_to
run queue length is one. When we see two successive failures of
yield_to we assume we are in potential undercommit case and abort
from PLE handler.
The assumption is backed by low probability of wrong decision
for even worst case scenarios such as average runqueue length
between 1 and 2.
note that we do not update last boosted vcpu in failure cases.
Thank Avi for raising question on aborting after first fail from yield_to.
Reviewed-by: Srikar Dronamraju sri...@linux.vnet.ibm.com
Signed-off-by: Raghavendra K T raghavendra...@linux.vnet.ibm.com
---
virt/kvm/kvm_main.c | 26 --
1 file changed, 16 insertions(+), 10 deletions(-)
diff --git a/virt/kvm/kvm_main.c b/virt/kvm/kvm_main.c
index be70035..9f390e7 100644
--- a/virt/kvm/kvm_main.c
+++ b/virt/kvm/kvm_main.c
@@ -1639,6 +1639,7 @@ bool kvm_vcpu_yield_to(struct kvm_vcpu *target)
{
struct pid *pid;
struct task_struct *task = NULL;
+ bool ret = false;
rcu_read_lock();
pid = rcu_dereference(target-pid);
@@ -1646,17 +1647,15 @@ bool kvm_vcpu_yield_to(struct kvm_vcpu *target)
task = get_pid_task(target-pid, PIDTYPE_PID);
rcu_read_unlock();
if (!task)
- return false;
+ return ret;
if (task-flags PF_VCPU) {
put_task_struct(task);
- return false;
- }
- if (yield_to(task, 1)) {
- put_task_struct(task);
- return true;
+ return ret;
}
+ ret = yield_to(task, 1);
put_task_struct(task);
- return false;
+
+ return ret;
}
EXPORT_SYMBOL_GPL(kvm_vcpu_yield_to);
@@ -1697,12 +1696,14 @@ bool kvm_vcpu_eligible_for_directed_yield(struct
kvm_vcpu *vcpu)
return eligible;
}
#endif
+
void kvm_vcpu_on_spin(struct kvm_vcpu *me)
{
struct kvm *kvm = me-kvm;
struct kvm_vcpu *vcpu;
int last_boosted_vcpu = me-kvm-last_boosted_vcpu;
int yielded = 0;
+ int try = 2;
int pass;
int i;
@@ -1714,7 +1715,7 @@ void kvm_vcpu_on_spin(struct kvm_vcpu *me)
* VCPU is holding the lock that we need and will release it.
* We approximate round-robin by starting at the last boosted VCPU.
*/
- for (pass = 0; pass 2 !yielded; pass++) {
+ for (pass = 0; pass 2 !yielded try; pass++) {
kvm_for_each_vcpu(i, vcpu, kvm) {
if (!pass i = last_boosted_vcpu) {
i = last_boosted_vcpu;
@@ -1727,10 +1728,15 @@ void kvm_vcpu_on_spin(struct kvm_vcpu *me)
continue;
if (!kvm_vcpu_eligible_for_directed_yield(vcpu))
continue;
- if (kvm_vcpu_yield_to(vcpu)) {
+
+ yielded = kvm_vcpu_yield_to(vcpu);
+ if (yielded 0) {
kvm-last_boosted_vcpu = i;
- yielded = 1;
break;
+ } else if (yielded 0) {
+ try--;
+ if (!try)
+ break;
}
}
}
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v3 12/13] HID: introduce Scan Time
Hi Benjamin, On Wed, Nov 07, 2012 at 05:37:35PM +0100, Benjamin Tissoires wrote: Win 8 digitizer devices provides the actual scan time computed by the hardware itself. The value is global to the frame and is not specific to the multitouch protocol (though only touch, not pen, should use it according to the specification). Signed-off-by: Benjamin Tissoires benjamin.tissoi...@gmail.com --- Documentation/input/event-codes.txt | 9 + drivers/hid/hid-input.c | 4 include/linux/hid.h | 1 + include/linux/input.h | 1 + 4 files changed, 15 insertions(+) diff --git a/Documentation/input/event-codes.txt b/Documentation/input/event-codes.txt index 53305bd..80c06e5 100644 --- a/Documentation/input/event-codes.txt +++ b/Documentation/input/event-codes.txt @@ -174,6 +174,15 @@ A few EV_ABS codes have special meanings: the input device may be used freely in three dimensions, consider ABS_Z instead. +* ABS_SCAN_TIME: + - Used to report the number of microseconds since the last reset. This event +should be coded as an uint32 value, which is allowed to wrap around with +no special consequence. It is assumed that the time difference between two +consecutive events is reliable on a reasonable time scale (hours). +A reset to zero can happen, in which case the time since the last event is +unknown. If the device does not provide this information, the driver must +not provide it to the user space. + This should not be an absolute event but rather EV_MSC/MSC_TIMESTAMP. Thanks. -- Dmitry -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] virtio_scsi: fix memory leak on full queue condition.
Il 08/11/2012 10:55, Eric Northup ha scritto: virtscsi_queuecommand was leaking memory when the virtio queue was full. Tested: Guest operates correctly even with very small queue sizes, validated we're not leaking kmalloc-192 sized allocations anymore. Signed-off-by: Eric Northup digitale...@google.com --- drivers/scsi/virtio_scsi.c |2 ++ 1 files changed, 2 insertions(+), 0 deletions(-) diff --git a/drivers/scsi/virtio_scsi.c b/drivers/scsi/virtio_scsi.c index 595af1a..dd8dc27 100644 --- a/drivers/scsi/virtio_scsi.c +++ b/drivers/scsi/virtio_scsi.c @@ -469,6 +469,8 @@ static int virtscsi_queuecommand(struct Scsi_Host *sh, struct scsi_cmnd *sc) sizeof cmd-req.cmd, sizeof cmd-resp.cmd, GFP_ATOMIC) = 0) ret = 0; + else + mempool_free(cmd, virtscsi_cmd_pool); out: return ret; Acked-by: Paolo Bonzini pbonz...@redhat.com Paolo -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 00/31] numa/core patches
On 10/30/2012 08:20 AM, Mel Gorman wrote: On Thu, Oct 25, 2012 at 02:16:17PM +0200, Peter Zijlstra wrote: Hi all, Here's a re-post of the NUMA scheduling and migration improvement patches that we are working on. These include techniques from AutoNUMA and the sched/numa tree and form a unified basis - it has got all the bits that look good and mergeable. Thanks for the repost. I have not even started a review yet as I was travelling and just online today. It will be another day or two before I can start but I was at least able to do a comparison test between autonuma and schednuma today to see which actually performs the best. Even without the review I was able to stick on similar vmstats as was applied to autonuma to give a rough estimate of the relative overhead of both implementations. Peter, Ingo, do you have any comments on the performance measurements by Mel? Any ideas on how to fix sched/numa or numa/core? At this point, I suspect the easiest way forward might be to merge the basic infrastructure from Mel's combined tree (in -mm? in -tip?), so we can experiment with different NUMA placement policies on top. That way we can do apples to apples comparison of the policies, and figure out what works best, and why. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC PATCH 0/8][Sorted-buddy] mm: Linux VM Infrastructure to support Memory Power Management
On Fri, Nov 09, 2012 at 10:44:16AM +0530, Vaidyanathan Srinivasan wrote: * Mel Gorman mgor...@suse.de [2012-11-08 18:02:57]: On Wed, Nov 07, 2012 at 01:22:13AM +0530, Srivatsa S. Bhat wrote: Hi Mel, Thanks for detailed review and comments. The goal of this patch series is to brainstorm on ideas that enable Linux VM to record and exploit memory region boundaries. I see. The first approach that we had last year (hierarchy) has more runtime overhead. This approach of sorted-buddy was one of the alternative discussed earlier and we are trying to find out if simple requirements of biasing memory allocations can be achieved with this approach. Smart reclaim based on this approach is a key piece we still need to design. Ideas from compaction will certainly help. Today memory subsystems are offer a wide range of capabilities for managing memory power consumption. As a quick example, if a block of memory is not referenced for a threshold amount of time, the memory controller can decide to put that chunk into a low-power content-preserving state. And the next reference to that memory chunk would bring it back to full power for read/write. With this capability in place, it becomes important for the OS to understand the boundaries of such power-manageable chunks of memory and to ensure that references are consolidated to a minimum number of such memory power management domains. How much power is saved? On embedded platform the savings could be around 5% as discussed in the earlier thread: http://article.gmane.org/gmane.linux.kernel.mm/65935 On larger servers with large amounts of memory the savings could be more. We do not yet have all the pieces together to evaluate. Ok, it's something to keep an eye on because if memory power savings require large amounts of CPU (for smart placement or migration) or more disk accesses (due to reclaim) then the savings will be offset by increased power usage elsehwere. ACPI 5.0 has introduced MPST tables (Memory Power State Tables) [5] so that the firmware can expose information regarding the boundaries of such memory power management domains to the OS in a standard way. I'm not familiar with the ACPI spec but is there support for parsing of MPST and interpreting the associated ACPI events? For example, if ACPI fires an event indicating that a memory power node is to enter a low state then presumably the OS should actively migrate pages away -- even if it's going into a state where the contents are still refreshed as exiting that state could take a long time. I did not look closely at the patchset at all because it looked like the actual support to use it and measure the benefit is missing. Correct. The platform interface part is not included in this patch set mainly because there is not much design required there. Each platform can have code to collect the memory region boundaries from BIOS/firmware and load it into the Linux VM. The goal of this patch is to brainstorm on the idea of hos core VM should used the region information. Ok. It does mean that the patches should not be merged until there is some platform support that can take advantage of them. How can Linux VM help memory power savings? o Consolidate memory allocations and/or references such that they are not spread across the entire memory address space. Basically area of memory that is not being referenced, can reside in low power state. Which the series does not appear to do. Correct. We need to design the correct reclaim strategy for this to work. However having buddy list sorted by region address could get us one step closer to shaping the allocations. If you reclaim, it means that the information is going to disk and will have to be refaulted in sooner rather than later. If you concentrate on reclaiming low memory regions and memory is almost full, it will lead to a situation where you almost always reclaim newer pages and increase faulting. You will save a few milliwatts on memory and lose way more than that on increase disk traffic and CPU usage. o Support targeted memory reclaim, where certain areas of memory that can be easily freed can be offlined, allowing those areas of memory to be put into lower power states. Which the series does not appear to do judging from this; include/linux/mm.h | 38 +++ include/linux/mmzone.h | 52 + mm/compaction.c|8 + mm/page_alloc.c| 263 mm/vmstat.c| 59 ++- This does not appear to be doing anything with reclaim and not enough with compaction to indicate that the series actively manages memory placement in response to ACPI events. Correct.
Re: [RFC PATCH 6/8] mm: Demarcate and maintain pageblocks in region-order in the zones' freelists
Hi Ankita,
On 11/09/2012 11:31 AM, Ankita Garg wrote:
Hi Srivatsa,
I understand that you are maintaining the page blocks in region sorted
order. So that way, when the memory requests come in, you can hand out
memory from the regions in that order.
Yes, that's right.
However, do you take this
scenario into account - in some bucket of the buddy allocator, there
might not be any pages belonging to, lets say, region 0, while the next
higher bucket has them. So, instead of handing out memory from whichever
region thats present there, to probably go to the next bucket and split
that region 0 pageblock there and allocate from it ? (Here, region 0 is
just an example). Been a while since I looked at kernel code, so I might
be missing something!
This patchset doesn't attempt to do that because that can hurt the fast
path performance of page allocation (ie., because we could end up trying
to split pageblocks even when we already have pageblocks of the required
order ready at hand... and not to mention the searching involved in finding
out whether any higher order free lists really contain pageblocks belonging
to this region 0). In this patchset, I have consciously tried to keep the
overhead from memory regions as low as possible, and have moved most of
the overhead to the page free path.
But the scenario that you brought out is very relevant, because that would
help achieve more aggressive power-savings. I will try to implement
something to that end with least overhead in the next version and measure
whether its cost vs benefit really works out or not. Thank you very much
for pointing it out!
Regards,
Srivatsa S. Bhat
On Tue, Nov 6, 2012 at 1:53 PM, Srivatsa S. Bhat
srivatsa.b...@linux.vnet.ibm.com
mailto:srivatsa.b...@linux.vnet.ibm.com wrote:
The zones' freelists need to be made region-aware, in order to influence
page allocation and freeing algorithms. So in every free list in the
zone, we
would like to demarcate the pageblocks belonging to different memory
regions
(we can do this using a set of pointers, and thus avoid splitting up the
freelists).
Also, we would like to keep the pageblocks in the freelists sorted in
region-order. That is, pageblocks belonging to region-0 would come
first,
followed by pageblocks belonging to region-1 and so on, within a given
freelist. Of course, a set of pageblocks belonging to the same
region need
not be sorted; it is sufficient if we maintain the pageblocks in
region-sorted-order, rather than a full address-sorted-order.
For each freelist within the zone, we maintain a set of pointers to
pageblocks belonging to the various memory regions in that zone.
Eg:
|---Region0---| |---Region1---| |---Region2-|
-- ||-- ||-- ||-- ||-- ||-- ||--
||--
^ ^ ^
| | |
Reg0 Reg1 Reg2
Page allocation will proceed as usual - pick the first item on the
free list.
But we don't want to keep updating these region pointers every time
we allocate
a pageblock from the freelist. So, instead of pointing to the
*first* pageblock
of that region, we maintain the region pointers such that they point
to the
*last* pageblock in that region, as shown in the figure above. That
way, as
long as there are 1 pageblocks in that region in that freelist,
that region
pointer doesn't need to be updated.
Page allocation algorithm:
-
The heart of the page allocation algorithm remains it is - pick the
first
item on the appropriate freelist and return it.
Pageblock order in the zone freelists:
-
This is the main change - we keep the pageblocks in region-sorted order,
where pageblocks belonging to region-0 come first, followed by those
belonging
to region-1 and so on. But the pageblocks within a given region need
*not* be
sorted, since we need them to be only region-sorted and not fully
address-sorted.
This sorting is performed when adding pages back to the freelists, thus
avoiding any region-related overhead in the critical page allocation
paths.
Page reclaim [Todo]:
Page allocation happens in the order of increasing region number. We
would
like to do page reclaim in the reverse order, to keep allocated
pages within
a minimal number of regions (approximately).
Increasing region
number--
Direction of allocation---
Re: kswapd0: excessive CPU usage
On Fri, Nov 09, 2012 at 09:07:45AM +0100, Zdenek Kabelac wrote: fe2c2a106663130a5ab45cb0e3414b52df2fff0c is the first bad commit commit fe2c2a106663130a5ab45cb0e3414b52df2fff0c Author: Rik van Riel r...@redhat.com Date: Wed Mar 21 16:33:51 2012 -0700 vmscan: reclaim at order 0 when compaction is enabled ... This is plausible since the issue seems to be in the kswapd + compaction realm. I've yet to figure out exactly what about this commit results in kswapd spinning. I would be interested if someone can confirm this finding. -- Seth On my system 3.7-rc4 the problem seems to be effectively solved by revert patch: https://lkml.org/lkml/2012/11/5/308 Ok, while there is still a question on whether it's enough I think it's sensible to at least start with the obvious one. Thanks very much. -- Mel Gorman SUSE Labs -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC v3 0/3] vmpressure_fd: Linux VM pressure notifications
On Fri, Nov 09, 2012 at 09:32:03AM +0100, Luiz Capitulino wrote: Anton Vorontsov anton.voront...@linaro.org wrote: This is the third RFC. As suggested by Minchan Kim, the API is much simplified now (comparing to vmevent_fd): Which tree is this against? I'd like to try this series, but it doesn't apply to Linus tree. Thanks for trying! The tree is a mix of Pekka's linux-vmevent tree and Linus' tree. You can just clone my tree to get the whole thing: git://git.infradead.org/users/cbou/linux-vmevent.git Note that the tree is rebasable. Also be sure to select CONFIG_VMPRESSURE, not CONFIG_VMEVENT. Thanks! Anton. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] spi: make sure all transfer has bits_per_word set
When spi client does the spi transfer and does not sets
the bits_per_word for each transfer then set it as default
of spi device in spi core before calling low level transfer.
Removing the similar code from spi-tegra20-slink driver as
it is not required.
Signed-off-by: Laxman Dewangan ldewan...@nvidia.com
Cc: Stephen Warren swar...@wwwdotorg.org
---
When reviewing the change
[PATCH] spi: tegra: add spi driver for SLINK controller
it was suggested by Mark and Stephen that we should move the
bits_per_word setting to the core as it almost exist in all driver.
Creating this patch for doing this.
Creating teh patch
drivers/spi/spi-tegra20-slink.c |3 +--
drivers/spi/spi.c | 11 ++-
2 files changed, 11 insertions(+), 3 deletions(-)
diff --git a/drivers/spi/spi-tegra20-slink.c b/drivers/spi/spi-tegra20-slink.c
index b8985be..07dc735 100644
--- a/drivers/spi/spi-tegra20-slink.c
+++ b/drivers/spi/spi-tegra20-slink.c
@@ -727,8 +727,7 @@ static int tegra_slink_start_transfer_one(struct spi_device
*spi,
unsigned long command;
unsigned long command2;
- bits_per_word = t-bits_per_word ? t-bits_per_word :
- spi-bits_per_word;
+ bits_per_word = t-bits_per_word;
speed = t-speed_hz ? t-speed_hz : spi-max_speed_hz;
if (!speed)
speed = tspi-spi_max_frequency;
diff --git a/drivers/spi/spi.c b/drivers/spi/spi.c
index fc0da39..6891a03 100644
--- a/drivers/spi/spi.c
+++ b/drivers/spi/spi.c
@@ -1193,6 +1193,7 @@ EXPORT_SYMBOL_GPL(spi_setup);
static int __spi_async(struct spi_device *spi, struct spi_message *message)
{
struct spi_master *master = spi-master;
+ struct spi_transfer *xfer;
/* Half-duplex links include original MicroWire, and ones with
* only one data pin like SPI_3WIRE (switches direction) or where
@@ -1201,7 +1202,6 @@ static int __spi_async(struct spi_device *spi, struct
spi_message *message)
*/
if ((master-flags SPI_MASTER_HALF_DUPLEX)
|| (spi-mode SPI_3WIRE)) {
- struct spi_transfer *xfer;
unsigned flags = master-flags;
list_for_each_entry(xfer, message-transfers, transfer_list) {
@@ -1214,6 +1214,15 @@ static int __spi_async(struct spi_device *spi, struct
spi_message *message)
}
}
+ /**
+* Set transfer bits_per_word as spi device default if it is not
+* set for this transfer.
+*/
+ list_for_each_entry(xfer, message-transfers, transfer_list) {
+ if (!xfer-bits_per_word)
+ xfer-bits_per_word = spi-bits_per_word;
+ }
+
message-spi = spi;
message-status = -EINPROGRESS;
return master-transfer(spi, message);
--
1.7.1.1
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/9 v3] cgroup: add cgroup_subsys-post_create()
On 2012/11/9 3:07, Tejun Heo wrote: Subject: cgroup: add cgroup_subsys-post_create() Currently, there's no way for a controller to find out whether a new cgroup finished all -create() allocatinos successfully and is considered live by cgroup. This becomes a problem later when we add generic descendants walking to cgroup which can be used by controllers as controllers don't have a synchronization point where it can synchronize against new cgroups appearing in such walks. This patch adds -post_create(). It's called after all -create() succeeded and the cgroup is linked into the generic cgroup hierarchy. This plays the counterpart of -pre_destroy(). When used in combination with the to-be-added generic descendant iterators, -post_create() can be used to implement reliable state inheritance. It will be explained with the descendant iterators. v2: Added a paragraph about its future use w/ descendant iterators per Michal. v3: Forgot to add -post_create() invocation to cgroup_load_subsys(). Fixed. Signed-off-by: Tejun Heo t...@kernel.org Acked-by: Michal Hocko mho...@suse.cz Reviewed-by: KAMEZAWA Hiroyuki kamezawa.hir...@jp.fujitsu.com Cc: Glauber Costa glom...@parallels.com Li Zefan lize...@huawei.com -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/9 v3] cgroup: add cgroup_subsys-post_create()
On 2012/11/9 3:07, Tejun Heo wrote: Subject: cgroup: add cgroup_subsys-post_create() Currently, there's no way for a controller to find out whether a new cgroup finished all -create() allocatinos successfully and is considered live by cgroup. This becomes a problem later when we add generic descendants walking to cgroup which can be used by controllers as controllers don't have a synchronization point where it can synchronize against new cgroups appearing in such walks. This patch adds -post_create(). It's called after all -create() succeeded and the cgroup is linked into the generic cgroup hierarchy. This plays the counterpart of -pre_destroy(). When used in combination with the to-be-added generic descendant iterators, -post_create() can be used to implement reliable state inheritance. It will be explained with the descendant iterators. v2: Added a paragraph about its future use w/ descendant iterators per Michal. v3: Forgot to add -post_create() invocation to cgroup_load_subsys(). Fixed. Signed-off-by: Tejun Heo t...@kernel.org Acked-by: Michal Hocko mho...@suse.cz Reviewed-by: KAMEZAWA Hiroyuki kamezawa.hir...@jp.fujitsu.com Cc: Glauber Costa glom...@parallels.com Acked-by: Li Zefan lize...@huawei.com -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2/9] cgroup: Use rculist ops for cgroup-children
On 2012/11/3 16:38, Tejun Heo wrote: Use RCU safe list operations for cgroup-children. This will be used to implement cgroup children / descendant walking which can be used by controllers. Note that cgroup_create() now puts a new cgroup at the end of the -children list instead of head. This isn't strictly necessary but is done so that the iteration order is more conventional. Signed-off-by: Tejun Heo t...@kernel.org Acked-by: Li Zefan lize...@huawei.com -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] spi: tegra: sequence compatible strings as per preference
Sequence compatible list for tegra20-slink driver to first
look for Tegra30 and then Tegra20. Tegra30 have additional
feature in HW which need to be utilize if it is provided from DT.
Signed-off-by: Laxman Dewangan ldewan...@nvidia.com
---
drivers/spi/spi-tegra20-slink.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/spi/spi-tegra20-slink.c b/drivers/spi/spi-tegra20-slink.c
index 07dc735..7882b50 100644
--- a/drivers/spi/spi-tegra20-slink.c
+++ b/drivers/spi/spi-tegra20-slink.c
@@ -1109,8 +1109,8 @@ const struct tegra_slink_chip_data tegra20_spi_cdata = {
};
static struct of_device_id tegra_slink_of_match[] __devinitconst = {
- { .compatible = nvidia,tegra20-slink, .data = tegra20_spi_cdata, },
{ .compatible = nvidia,tegra30-slink, .data = tegra30_spi_cdata, },
+ { .compatible = nvidia,tegra20-slink, .data = tegra20_spi_cdata, },
{}
};
MODULE_DEVICE_TABLE(of, tegra_slink_of_match);
--
1.7.1.1
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Revert mm: vmscan: scale number of pages reclaimed by reclaim/compaction based on failures
On Mon, Nov 05, 2012 at 02:24:49PM +, Mel Gorman wrote: Jiri Slaby reported the following: (It's an effective revert of mm: vmscan: scale number of pages reclaimed by reclaim/compaction based on failures.) Given kswapd had hours of runtime in ps/top output yesterday in the morning and after the revert it's now 2 minutes in sum for the last 24h, I would say, it's gone. The intention of the patch in question was to compensate for the loss of lumpy reclaim. Part of the reason lumpy reclaim worked is because it aggressively reclaimed pages and this patch was meant to be a sane compromise. When compaction fails, it gets deferred and both compaction and reclaim/compaction is deferred avoid excessive reclaim. However, since commit c6543459 (mm: remove __GFP_NO_KSWAPD), kswapd is woken up each time and continues reclaiming which was not taken into account when the patch was developed. Attempts to address the problem ended up just changing the shape of the problem instead of fixing it. The release window gets closer and while a THP allocation failing is not a major problem, kswapd chewing up a lot of CPU is. This patch reverts mm: vmscan: scale number of pages reclaimed by reclaim/compaction based on failures and will be revisited in the future. Signed-off-by: Mel Gorman mgor...@suse.de Andrew, can you pick up this patch please and drop mm-vmscan-scale-number-of-pages-reclaimed-by-reclaim-compaction-only-in-direct-reclaim.patch ? There are mixed reports on how much it helps but it comes down to this fixes a problem versus kswapd is still showing higher usage. I think the higher kswapd usage is explained by the removal of __GFP_NO_KSWAPD and so while higher usage is bad, it is not necessarily unjustified. Ideally it would have been proven that having kswapd doing the work reduced application stalls in direct reclaim but unfortunately I do not have concrete evidence of that at this time. -- Mel Gorman SUSE Labs -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 3/9 v2] cgroup: implement generic child / descendant walk macros
On 2012/11/9 1:59, Tejun Heo wrote: Currently, cgroup doesn't provide any generic helper for walking a given cgroup's children or descendants. This patch adds the following three macros. * cgroup_for_each_child() - walk immediate children of a cgroup. * cgroup_for_each_descendant_pre() - visit all descendants of a cgroup in pre-order tree traversal. * cgroup_for_each_descendant_post() - visit all descendants of a cgroup in post-order tree traversal. All three only require the user to hold RCU read lock during traversal. Verifying that each iterated cgroup is online is the responsibility of the user. When used with proper synchronization, cgroup_for_each_descendant_pre() can be used to propagate state updates to descendants in reliable way. See comments for details. v2: s/config/state/ in commit message and comments per Michal. More documentation on synchronization rules. Signed-off-by: Tejun Heo t...@kernel.org Reviewed-by: KAMEZAWA Hiroyuki kamezawa.hir...@jp.fujisu.com Reviewed-by: Michal Hocko mho...@suse.cz I don't see anything wrong with the comment on cgroup_next_descendant_pre(). Acked-by: Li Zefan lize...@huawei.com -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] mtd: de-select the chip when it is not used
When we scan several nand chips with nand_scan(), such as
...
nand_scan(*, 2);
...
In nand_scan_ident(), the maxchips will become 2, so the current code
will select chip 1 to read the device ID. But the chip 0 is still
selected in this case.
To make the logic clear, we'd better de-select the chip when it is not used.
This patch de-select the nand chip if it is not used any more.
Signed-off-by: Huang Shijie b32...@freescale.com
---
drivers/mtd/nand/nand_base.c | 10 ++
1 files changed, 6 insertions(+), 4 deletions(-)
diff --git a/drivers/mtd/nand/nand_base.c b/drivers/mtd/nand/nand_base.c
index ec6841d..fd5fa3b 100644
--- a/drivers/mtd/nand/nand_base.c
+++ b/drivers/mtd/nand/nand_base.c
@@ -3325,6 +3325,8 @@ int nand_scan_ident(struct mtd_info *mtd, int maxchips,
return PTR_ERR(type);
}
+ chip-select_chip(mtd, -1);
+
/* Check for a chip array */
for (i = 1; i maxchips; i++) {
chip-select_chip(mtd, i);
@@ -3334,8 +3336,11 @@ int nand_scan_ident(struct mtd_info *mtd, int maxchips,
chip-cmdfunc(mtd, NAND_CMD_READID, 0x00, -1);
/* Read manufacturer and device IDs */
if (nand_maf_id != chip-read_byte(mtd) ||
- nand_dev_id != chip-read_byte(mtd))
+ nand_dev_id != chip-read_byte(mtd)) {
+ chip-select_chip(mtd, -1);
break;
+ }
+ chip-select_chip(mtd, -1);
}
if (i 1)
pr_info(%d NAND chips detected\n, i);
@@ -3594,9 +3599,6 @@ int nand_scan_tail(struct mtd_info *mtd)
/* Initialize state */
chip-state = FL_READY;
- /* De-select the device */
- chip-select_chip(mtd, -1);
-
/* Invalidate the pagebuffer reference */
chip-pagebuf = -1;
--
1.7.0.4
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] ARM: kprobes: use BUG_ON where possible
On Thu, 2012-11-08 at 15:23 -0500, Sasha Levin wrote:
Just use BUG_ON() instead of constructions such as:
if (...)
BUG()
A simplified version of the semantic patch that makes this transformation
is as follows: (http://coccinelle.lip6.fr/)
// smpl
@@
expression e;
@@
- if (e) BUG();
+ BUG_ON(e);
// /smpl
Signed-off-by: Sasha Levin sasha.le...@oracle.com
I'm not sure that trivial changes like this are worth it, but equally,
they're not worth having a discussion about, so...
Acked-by: Jon Medhurst t...@linaro.org
---
arch/arm/kernel/kprobes-test.c |3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/arch/arm/kernel/kprobes-test.c b/arch/arm/kernel/kprobes-test.c
index 1862d8f..0fb370d 100644
--- a/arch/arm/kernel/kprobes-test.c
+++ b/arch/arm/kernel/kprobes-test.c
@@ -1212,8 +1212,7 @@ static int register_test_probe(struct test_probe *probe)
{
int ret;
- if (probe-registered)
- BUG();
+ BUG_ON(probe-registered);
ret = register_kprobe(probe-kprobe);
if (ret = 0) {
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] mfd: rtsx_pcr: Include linux/slab.h to fix build error
Hi Axel, On Fri, Nov 09, 2012 at 01:16:41PM +0800, Axel Lin wrote: Fix below build error: I already pushed a similar patch, thanks. Cheers, Samuel. -- Intel Open Source Technology Centre http://oss.intel.com/ -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: ACPI errors with 3.7-rc3
On Thu, Nov 08, 2012 at 05:49:40AM +0800, Rafael J. Wysocki wrote: On Tuesday, November 06, 2012 01:48:26 PM Greg KH wrote: On Tue, Nov 06, 2012 at 04:42:24PM +0400, Azat Khuzhin wrote: I'v also have such errors on my macbook pro. $ dmesg | tail [17056.008564] ACPI Error: Method parse/execution failed [\_SB_.PCI0.LPCB.EC__.SMB0.SBRW] (Node 88026547ea10), AE_TIME (20120711/psparse-536) [17056.011194] ACPI Error: Method parse/execution failed [\_SB_.BAT0.UBST] (Node 88026547e678), AE_TIME (20120711/psparse-536) [17056.013793] ACPI Error: Method parse/execution failed [\_SB_.BAT0._BST] (Node 88026547e740), AE_TIME (20120711/psparse-536) [17056.016383] ACPI Exception: AE_TIME, Evaluating _BST (20120711/battery-464) [17056.511373] ACPI: EC: input buffer is not empty, aborting transaction [17056.512672] ACPI Exception: AE_TIME, Returned by Handler for [EmbeddedControl] (20120711/evregion-501) [17056.515256] ACPI Error: Method parse/execution failed [\_SB_.PCI0.LPCB.EC__.SMB0.SBRW] (Node 88026547ea10), AE_TIME (20120711/psparse-536) [17056.517886] ACPI Error: Method parse/execution failed [\_SB_.BAT0.UBST] (Node 88026547e678), AE_TIME (20120711/psparse-536) [17056.520479] ACPI Error: Method parse/execution failed [\_SB_.BAT0._BST] (Node 88026547e740), AE_TIME (20120711/psparse-536) [17056.523070] ACPI Exception: AE_TIME, Evaluating _BST (20120711/battery-464) I'm seeing this again right now. I'm wondering if it's because I'm running on battery power at the moment: [41694.309264] ACPI Exception: AE_TIME, Returned by Handler for [EmbeddedControl] (20120913/evregion-501) [41694.309282] ACPI Error: Method parse/execution failed [\_SB_.PCI0.LPCB.EC__.SMB0.SBRW] (Node 88045cc64618), AE_TIME (20120913/psparse-536) [41694.309300] ACPI Error: Method parse/execution failed [\_SB_.BAT0.UBST] (Node 88045cc64988), AE_TIME (20120913/psparse-536) [41694.309310] ACPI Error: Method parse/execution failed [\_SB_.BAT0._BST] (Node 88045cc648c0), AE_TIME (20120913/psparse-536) [41694.309324] ACPI Exception: AE_TIME, Evaluating _BST (20120913/battery-464) [41694.809093] ACPI: EC: input buffer is not empty, aborting transaction ec_storm_threshold is still set to 8 in /sys/module/acpi/parameters/ so that's not the issue here. And also loadavg is too high ~ 10 While there is no process that load CPU up to 100% or like that. I think that this because of processes that is done in kernel space. (basically that one who write such errors) $ uname -a Linux macbook-pro-sq 3.6.5macbook-pro-custom-v0.1 #4 SMP Sun Nov 4 12:39:03 UTC 2012 x86_64 GNU/Linux Ah, ok, that means it's not something new in 3.7-rc, so maybe it's just never worked properly for this hardware :) So it's not a regression, just an ACPI issue, any ACPI developer have an idea about this? Can you please send the output of acpidump from the affected machine(s)? I doubt this problem is sometimes inevitable for some machines, because AFAIK most modern machines have the race problem for EC HW controller, as both OS side and the BIOS may access the EC HW at the same time without any race control. For this case, usually the battery and thermal modules (which may be controlled through EC) are always monitored by BIOS, when OS also frequently visit them too, the EC's own state machine may be broken and not responsive due to the race, then cause the timeout error. And how severe the problem will be depends on the EC HW, the quality of BIOS code and OS/driver code. Myself have seen the similar ACPI: EC: input buffer is not empty, aborting transaction error message on one laptop when its EC is busy visited by OS. btw, in EC driver I see a ec-global_lock, don't know if it was designed to control the race between OS and BIOS. Thanks, Feng -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Crypto Fixes for 3.7
Hi Linus: This push fixes a potential panic in cryptd which may occur with crypto drivers such as aesni-intel. Please pull from git://git.kernel.org/pub/scm/linux/kernel/git/herbert/crypto-2.6.git or master.kernel.org:/pub/scm/linux/kernel/git/herbert/crypto-2.6.git Jussi Kivilinna (1): crypto: cryptd - disable softirqs in cryptd_queue_worker to prevent data corruption crypto/cryptd.c | 11 --- 1 files changed, 8 insertions(+), 3 deletions(-) Thanks, -- Email: Herbert Xu herb...@gondor.apana.org.au Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] usb: gadget: ncm: correct endianess conversion
Hi Felipe, On Thu, Nov 8, 2012 at 8:30 PM, Felipe Balbi ba...@ti.com wrote: Hi, On Thu, Nov 08, 2012 at 08:07:57PM +0100, Dmytro Milinevskyy wrote: On Wed, Nov 07, 2012 at 02:14:00PM +0100, Dmytro Milinevskyy wrote: Unfortunately I have some issues with git send-email. I've attached the patch itself .. I'll apply it like that this time, but try to figure out how to send patches properly. We have some very helpful hints on Documentation/email-clients.txt which are hugely underused ;-) well, I try to follow the rules as much as possible as long as tools work ... =) git send-email has thousands of users and it works fine for them (including myself). Maybe you just misconfigured it ?!? ;-) No, I was using it in the past w/o any issue. In fact initial versions of the patch were sent exactly with git-send-email. However I lost my internet connection at home(some issues with ISP) and at work place network environment somehow blocks git-send-email(though thunderbird still can connect to the smtp server ..). thanks, -- dmytro cheers -- balbi -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] crypto: picoxcell: Add terminating entry for platform_device_id table
On Sun, Nov 04, 2012 at 11:36:25PM +0800, Axel Lin wrote: The platform_device_id table is supposed to be zero-terminated. Signed-off-by: Axel Lin axel@ingics.com Patch applied. Thanks! -- Email: Herbert Xu herb...@gondor.apana.org.au Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[GIT PULL REQUEST] UniCore32 update for v3.7-rc4
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
The following changes since commit 0e4a43ed08e2f44aa7b96aa95d0a540d675483e1:
Linus Torvalds (1):
Merge git://git.kernel.org/.../steve/gfs2-3.0-fixes
are available in the git repository at:
git://github.com/gxt/linux.git ..BRANCH.NOT.VERIFIED..
Al Viro (2):
unicore32: switch to generic kernel_thread()/kernel_execve()
unicore32: switch to generic sys_execve()
David Howells (1):
UAPI: (Scripted) Disintegrate arch/unicore32/include/asm
Guan Xuetao (4):
UniCore32 bugfix: add missed CONFIG_ZONE_DMA
UniCore32-bugfix: fix mismatch return value of __xchg_bad_pointer
UniCore32-bugfix: Remove definitions in asm/bug.h to solve difference
between native and cross compiler
unicore32: Use Kbuild infrastructure for kvm_para.h
Kautuk Consul (1):
unicore32/mm/fault.c: Port OOM changes to do_pf
Kees Cook (1):
arch/unicore32: remove CONFIG_EXPERIMENTAL
arch/unicore32/Kconfig |7 ++-
arch/unicore32/include/asm/Kbuild |1 -
arch/unicore32/include/asm/bug.h |5 -
arch/unicore32/include/asm/cmpxchg.h |2 +-
arch/unicore32/include/asm/kvm_para.h |1 -
arch/unicore32/include/asm/processor.h |5 -
arch/unicore32/include/asm/ptrace.h| 76 +
arch/unicore32/include/uapi/asm/Kbuild |7 ++
arch/unicore32/include/{ = uapi}/asm/byteorder.h |0
arch/unicore32/include/uapi/asm/ptrace.h | 90
arch/unicore32/include/{ = uapi}/asm/sigcontext.h |0
arch/unicore32/include/{ = uapi}/asm/unistd.h |1 +
arch/unicore32/kernel/entry.S | 20 ++---
arch/unicore32/kernel/process.c| 58 +++--
arch/unicore32/kernel/setup.h |6 ++
arch/unicore32/kernel/sys.c| 63 --
arch/unicore32/mm/fault.c | 37 ++--
17 files changed, 160 insertions(+), 219 deletions(-)
delete mode 100644 arch/unicore32/include/asm/kvm_para.h
rename arch/unicore32/include/{ = uapi}/asm/byteorder.h (100%)
create mode 100644 arch/unicore32/include/uapi/asm/ptrace.h
rename arch/unicore32/include/{ = uapi}/asm/sigcontext.h (100%)
rename arch/unicore32/include/{ = uapi}/asm/unistd.h (92%)
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.10 (GNU/Linux)
iQIcBAEBAgAGBQJQnM5BAAoJENFylnOm3dTb9aoP/in4QBnMN/+lO2JaiMw4aIAI
CkWKfNCg47NHo1D53ZlOH9kCulIrM4bH3uOXwnnGtHDfvlOaX/BdxOKkqEpovv0r
DJXRzQVuGsbTW2A94AQZYDqOUlgHraO4WvAqQeItoEwZqQUptsHHz36ICgLpUGur
CUAtTWeZ14b3xndY4QEUTThUno+cvIu+J6cDOTTXGcOGqfTSkI7EuKSdAVsAPf9K
RaxLGw+k0OekZmcaLNCLH1B+T2GRskNF5UhTLnb8Sa2gcxGwc2sNoPmm0B+Tj6bC
lS2BneX1LWkWEkisl94rZK7T0OirCzr5bXsgSAChVpykf5biN6SBXjQUtV660yGy
yP/vdWDu4ISrqv625v/CKj8Ar476SEkCljKZZ0m2mUWoPBrFAt3N7+KnLUAZXYtd
tsFx/vvWb15Z6PZktLDfcR47ypEd7nf3/FY8h8OvvZg4GJOW+NxIEOHA/ZOXUV+7
yQObEv7+40kB+ZLOBkPy2gDhUIwAsXvaAnj6HB8zFsC9Z3W5tl94vn9RkGiW+6P6
rd3qNgqmHsXBFLsARq2Ct9dP2O6GE3D90EMMq78iP0mE5Ow37KjAmKxWwJSd9KCB
WnDt1rSzsKcmayIMFgVFWJy8dG9rUANaZvIdl/vrqA0tsYcs/3f0lEcwn1/7/maS
qsHCm+R2kL757t/qF2G/
=b4YB
-END PGP SIGNATURE-
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2/2] drivres/power/jz4740-battery.c: Use devm_request_and_ioremap
On 11/07/2012 12:11 AM, Marcos Paulo de Souza wrote:
No functional changes. Just a cleanup.
Signed-off-by: Marcos Paulo de Souza marcos.souza@gmail.com
Looks good to me:
Acked-by: Lars-Peter Clausen l...@metafoo.de
One minor comment though:
---
drivers/power/jz4740-battery.c | 33 +++--
1 file changed, 7 insertions(+), 26 deletions(-)
diff --git a/drivers/power/jz4740-battery.c b/drivers/power/jz4740-battery.c
index 59900c6..e4ec7eb 100644
--- a/drivers/power/jz4740-battery.c
+++ b/drivers/power/jz4740-battery.c
[...]
- jz_battery-base = ioremap_nocache(jz_battery-mem-start,
- resource_size(jz_battery-mem));
+ jz_battery-base = devm_request_and_ioremap(pdev-dev, mem);
if (!jz_battery-base) {
- ret = -EBUSY;
- dev_err(pdev-dev, Failed to ioremap mmio memory\n);
- goto err_release_mem_region;
+ dev_err(pdev-dev, Failed to request/ioremap mmio memory\n);
devm_request_and_ioremap will print its own error messages if it fails, so
strictly speaking this is not necessary, but I don't think it is worth doing
resend just for this.
Anton, maybe you can just remove the line when applying the patch.
Thanks,
- Lars
+ return -EBUSY;
}
[...]
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] bluetooth: ath3k: Add support for VAIO VPCEH [0489:e027]
Hi Marcos, * Marcos Chaparro mar...@mrkindustries.com.ar [2012-11-06 16:19:11 -0300]: Added Atheros AR3011 internal bluetooth device found in Sony VAIO VPCEH to the devices list. Before this, the bluetooth module was identified as an Foxconn / Hai bluetooth device [0489:e027], now it claims to be an AtherosAR3011 Bluetooth [0cf3:3005]. T: Bus=01 Lev=02 Prnt=02 Port=04 Cnt=02 Dev#= 4 Spd=12 MxCh= 0 D: Ver= 1.10 Cls=e0(wlcon) Sub=01 Prot=01 MxPS=64 #Cfgs= 1 P: Vendor=0489 ProdID=e027 Rev= 0.01 C:* #Ifs= 2 Cfg#= 1 Atr=e0 MxPwr=100mA I:* If#= 0 Alt= 0 #EPs= 3 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb E: Ad=81(I) Atr=03(Int.) MxPS= 16 Ivl=1ms E: Ad=82(I) Atr=02(Bulk) MxPS= 64 Ivl=0ms E: Ad=02(O) Atr=02(Bulk) MxPS= 64 Ivl=0ms I:* If#= 1 Alt= 0 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb E: Ad=83(I) Atr=01(Isoc) MxPS= 0 Ivl=1ms E: Ad=03(O) Atr=01(Isoc) MxPS= 0 Ivl=1ms I: If#= 1 Alt= 1 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb E: Ad=83(I) Atr=01(Isoc) MxPS= 9 Ivl=1ms E: Ad=03(O) Atr=01(Isoc) MxPS= 9 Ivl=1ms I: If#= 1 Alt= 2 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb E: Ad=83(I) Atr=01(Isoc) MxPS= 17 Ivl=1ms E: Ad=03(O) Atr=01(Isoc) MxPS= 17 Ivl=1ms I: If#= 1 Alt= 3 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb E: Ad=83(I) Atr=01(Isoc) MxPS= 25 Ivl=1ms E: Ad=03(O) Atr=01(Isoc) MxPS= 25 Ivl=1ms I: If#= 1 Alt= 4 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb E: Ad=83(I) Atr=01(Isoc) MxPS= 33 Ivl=1ms E: Ad=03(O) Atr=01(Isoc) MxPS= 33 Ivl=1ms I: If#= 1 Alt= 5 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb E: Ad=83(I) Atr=01(Isoc) MxPS= 49 Ivl=1ms E: Ad=03(O) Atr=01(Isoc) MxPS= 49 Ivl=1ms Signed-off-by: Marcos Chaparro mar...@mrkindustries.com.ar --- drivers/bluetooth/ath3k.c |1 + drivers/bluetooth/btusb.c |1 + 2 files changed, 2 insertions(+) Patch has been applied to bluetooth.git. Thanks. Gustavo -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2] i2c-hid: introduce HID over i2c specification implementation
On Tue, 16 Oct 2012, Benjamin Tissoires wrote:
--- /dev/null
+++ b/drivers/hid/i2c-hid/i2c-hid.c
...
+static int i2c_hid_alloc_buffers(struct i2c_hid *ihid)
+{
+ /* the worst case is computed from the set_report command with a
+ * reportID 15 and the maximum report length */
+ int args_len = sizeof(__u8) + /* optional ReportID byte */
+sizeof(__u16) + /* data register */
+sizeof(__u16) + /* size of the report */
+ihid-bufsize; /* report */
+
+ ihid-inbuf = kzalloc(ihid-bufsize, GFP_KERNEL);
+
+ if (!ihid-inbuf)
+ return -ENOMEM;
+
+ ihid-argsbuf = kzalloc(args_len, GFP_KERNEL);
+
+ if (!ihid-argsbuf) {
+ kfree(ihid-inbuf);
+ return -ENOMEM;
+ }
+
+ ihid-cmdbuf = kzalloc(sizeof(union command) + args_len, GFP_KERNEL);
+
+ if (!ihid-cmdbuf) {
+ kfree(ihid-inbuf);
+ kfree(ihid-argsbuf);
+ return -ENOMEM;
+ }
+
+ return 0;
If this is called from hid_start and some of the latter allocation fails
here, you free the buffers appropriately. However if another start
occurs (e.g. by loading another module for that particular device), it
will crash, as the buffers will remain unallocated because at this point
ihid-bufsize == old_bufsize. You should set ihid-bufsize back to
old_bufsize if i2c_hid_alloc_buffers fails and also set the pointers to
NULL here.
well spotted, thanks.
I'll change it in v3 then.
Benjamin,
just a quick check -- are you planning on submitting v3 eventually?
Thanks,
--
Jiri Kosina
SUSE Labs
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC PATCH v1 14/31] ARC: syscall support
On 07/11/12 14:21, Arnd Bergmann wrote: On Wednesday 07 November 2012, Vineet Gupta wrote: + * Being uClibc based we need some of the deprecated syscalls: + * -Not emulated by uClibc at all + * unlink, mkdir,... (needed by Busybox, LTP etc) + * times (needed by LTP pan test harness) + * -Not emulated efficiently + * select: emulated using pselect (but extra code to chk usec 1sec) + * + * some (send/recv) correctly emulated using (recfrom/sendto) and + * some arch specific ones (fork/vfork)can easily be emulated using clone but + * thats the price of using common-denominator + */ +#define __ARCH_WANT_SYSCALL_NO_AT +#define __ARCH_WANT_SYSCALL_NO_FLAGS +#define __ARCH_WANT_SYSCALL_OFF_T +#define __ARCH_WANT_SYSCALL_DEPRECATED I'm pretty sure that this has been solved before, best get in contact with the maintainers of the openrisc/c6x/hexagon platforms, that probably all use uClibc without needing these. You have to remove the legacy calls here. Hi Vineet, FYI, we'll soon be making some uClibc patches available so that it can work without these deprecated syscalls and with the newer IPC interface (the work was needed for metag too). It's based roughly on the OpenRisc patches from last year, but with a fair few changes. Thanks James -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[Acked] [PATCH V2 3/5] checkpatch: Remove reference to feature-removal-schedule.txt.
On Fri, Nov 09, 2012 at 09:38:12AM +0800, Tao Ma wrote:
From: Tao Ma boyu...@taobao.com
In 9c0ece069, Linus removes feature-removal-schedule.txt from Documentation,
but there is still some reference to this file. So remove them.
Cc: Andrew Morton a...@linux-foundation.org
Cc: Andy Whitcroft a...@canonical.com
Signed-off-by: Tao Ma boyu...@taobao.com
---
scripts/checkpatch.pl | 37 -
1 files changed, 0 insertions(+), 37 deletions(-)
diff --git a/scripts/checkpatch.pl b/scripts/checkpatch.pl
index 21a9f5d..b56c5e0 100755
--- a/scripts/checkpatch.pl
+++ b/scripts/checkpatch.pl
@@ -352,27 +352,6 @@ sub deparenthesize {
$chk_signoff = 0 if ($file);
-my @dep_includes = ();
-my @dep_functions = ();
-my $removal = Documentation/feature-removal-schedule.txt;
-if ($tree -f $root/$removal) {
- open(my $REMOVE, '', $root/$removal) ||
- die $P: $removal: open failed - $!\n;
- while ($REMOVE) {
- if (/^Check:\s+(.*\S)/) {
- for my $entry (split(/[, ]+/, $1)) {
- if ($entry =~ m@include/(.*)@) {
- push(@dep_includes, $1);
-
- } elsif ($entry !~ m@/@) {
- push(@dep_functions, $entry);
- }
- }
- }
- }
- close($REMOVE);
-}
-
my @rawlines = ();
my @lines = ();
my $vname;
@@ -3181,22 +3160,6 @@ sub process {
}
}
-# don't include deprecated include files (uses RAW line)
- for my $inc (@dep_includes) {
- if ($rawline =~ m@^.\s*\#\s*include\s*\$inc@) {
- ERROR(DEPRECATED_INCLUDE,
- Don't use $inc: see
Documentation/feature-removal-schedule.txt\n . $herecurr);
- }
- }
-
-# don't use deprecated functions
- for my $func (@dep_functions) {
- if ($line =~ /\b$func\b/) {
- ERROR(DEPRECATED_FUNCTION,
- Don't use $func(): see
Documentation/feature-removal-schedule.txt\n . $herecurr);
- }
- }
-
# no volatiles please
my $asm_volatile =
qr{\b(__asm__|asm)\s+(__volatile__|volatile)\b};
if ($line =~ /\bvolatile\b/ $line !~ /$asm_volatile/) {
--
1.7.0.4
Looks sane and cirtainly if the file is gone we are gaining nothing with
this code.
Acked-by: Andy Whitcroft a...@canonical.com
-apw
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2] i2c-hid: introduce HID over i2c specification implementation
Hi Jiri,
On Fri, Nov 9, 2012 at 4:49 AM, Jiri Kosina jkos...@suse.cz wrote:
On Tue, 16 Oct 2012, Benjamin Tissoires wrote:
--- /dev/null
+++ b/drivers/hid/i2c-hid/i2c-hid.c
...
+static int i2c_hid_alloc_buffers(struct i2c_hid *ihid)
+{
+ /* the worst case is computed from the set_report command with a
+ * reportID 15 and the maximum report length */
+ int args_len = sizeof(__u8) + /* optional ReportID byte */
+sizeof(__u16) + /* data register */
+sizeof(__u16) + /* size of the report */
+ihid-bufsize; /* report */
+
+ ihid-inbuf = kzalloc(ihid-bufsize, GFP_KERNEL);
+
+ if (!ihid-inbuf)
+ return -ENOMEM;
+
+ ihid-argsbuf = kzalloc(args_len, GFP_KERNEL);
+
+ if (!ihid-argsbuf) {
+ kfree(ihid-inbuf);
+ return -ENOMEM;
+ }
+
+ ihid-cmdbuf = kzalloc(sizeof(union command) + args_len,
GFP_KERNEL);
+
+ if (!ihid-cmdbuf) {
+ kfree(ihid-inbuf);
+ kfree(ihid-argsbuf);
+ return -ENOMEM;
+ }
+
+ return 0;
If this is called from hid_start and some of the latter allocation fails
here, you free the buffers appropriately. However if another start
occurs (e.g. by loading another module for that particular device), it
will crash, as the buffers will remain unallocated because at this point
ihid-bufsize == old_bufsize. You should set ihid-bufsize back to
old_bufsize if i2c_hid_alloc_buffers fails and also set the pointers to
NULL here.
well spotted, thanks.
I'll change it in v3 then.
Benjamin,
just a quick check -- are you planning on submitting v3 eventually?
yes sure.
It was not on my top priority list since I started at Red Hat.
Moreover, I've been reported a bug yesterday with the set_report
command.
I'll need to do a few more tests before sending the v3.
If I send it by the end of the day or at the beginning of next week,
will it have a chance to land into 3.8?
Cheers,
Benjamin
Thanks,
--
Jiri Kosina
SUSE Labs
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] fix build waring: drivers/regulator/core.c: warning: ‘val’ may be used uninitialized in this function [-Wuninitialized]
fix build waring on drivers/regulator/core.c
drivers/regulator/core.c: In function ‘regulator_get_bypass_regmap’:
drivers/regulator/core.c:2748:16: warning: ‘val’ may be used uninitialized in
this function [-Wuninitialized]
drivers/regulator/core.c: In function ‘regulator_get_voltage_sel_regmap’:
drivers/regulator/core.c:2016:6: warning: ‘val’ may be used uninitialized in
this function [-Wuninitialized]
drivers/regulator/core.c: In function ‘regulator_is_enabled_regmap’:
drivers/regulator/core.c:1786:14: warning: ‘val’ may be used uninitialized in
this function [-Wuninitialized]
From c5b564ba10101961ffca9a67c6ddcc6216b99dce Mon Sep 17 00:00:00 2001
From: helight xu helight...@gmail.com
Date: Sat, 10 Nov 2012 01:11:14 +0800
Subject: [PATCH] fix build waring: drivers/regulator/core.c: warning: ‘val’ may
be used uninitialized in this function [-Wuninitialized]
Signed-off-by: helight xu helight...@gmail.com
---
drivers/regulator/core.c |6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/regulator/core.c b/drivers/regulator/core.c
index 5c4829c..7ad7174 100644
--- a/drivers/regulator/core.c
+++ b/drivers/regulator/core.c
@@ -1776,8 +1776,8 @@ EXPORT_SYMBOL_GPL(regulator_disable_deferred);
*/
int regulator_is_enabled_regmap(struct regulator_dev *rdev)
{
- unsigned int val;
int ret;
+ unsigned int val = 0;
ret = regmap_read(rdev-regmap, rdev-desc-enable_reg, val);
if (ret != 0)
@@ -2006,8 +2006,8 @@ EXPORT_SYMBOL_GPL(regulator_is_supported_voltage);
*/
int regulator_get_voltage_sel_regmap(struct regulator_dev *rdev)
{
- unsigned int val;
int ret;
+ unsigned int val = 0;
ret = regmap_read(rdev-regmap, rdev-desc-vsel_reg, val);
if (ret != 0)
@@ -2738,8 +2738,8 @@ EXPORT_SYMBOL_GPL(regulator_set_bypass_regmap);
*/
int regulator_get_bypass_regmap(struct regulator_dev *rdev, bool *enable)
{
- unsigned int val;
int ret;
+ unsigned int val = 0;
ret = regmap_read(rdev-regmap, rdev-desc-bypass_reg, val);
if (ret != 0)
--
1.7.10.4
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: linux-next: build warning after merge of the akpm tree
On Fri, Nov 9, 2012 at 3:43 AM, Stephen Rothwell s...@canb.auug.org.au wrote:
Hi Andrew,
After merging the akpm tree, today's linux-next build (powerpc
allnoconfig - among others) produced this warning:
drivers/of/fdt.c: In function 'of_scan_flat_dt':
drivers/of/fdt.c:490:10: warning: assignment discards 'const' qualifier from
pointer target type [enabled by default]
Introduced by commit drivers/of/fdt.c: re-use kernel's kbasename().
Adding this hunk to the patch fixes it:
diff --git a/drivers/of/fdt.c b/drivers/of/fdt.c
index 91a375f..738228f 100644
--- a/drivers/of/fdt.c
+++ b/drivers/of/fdt.c
@@ -459,7 +459,7 @@ int __init of_scan_flat_dt(int (*it)(unsigned long node,
do {
u32 tag = be32_to_cpup((__be32 *)p);
- char *pathp;
+ const char *pathp;
p += 4;
if (tag == OF_DT_END_NODE) {
g.
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: linux-next: manual merge of the arm-soc tree with the pinctrl tree
On Fri, Nov 9, 2012 at 3:31 AM, Stephen Rothwell s...@canb.auug.org.au wrote: Today's linux-next merge of the arm-soc tree got a conflict in drivers/pinctrl/pinctrl-nomadik.c between commit 241e51ebd3b2 (pinctrl/nomadik: make independent of prcmu driver) from the pinctrl tree and commit 44e47ccf8ab6 (Merge branch 'next/multiplatform' into for-next) from the arm-soc tree. I fixed it up (see below) and can carry the fix as necessary (no action is required). This looks like the correct fix, thanks a lot Stephen! Yours, Linus Walleij -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: [PATCH 2/4] ARM: EXYNOS: PL330 MDMA1 fix for revision 0 of Exynos4210 SOC
Bartlomiej Zolnierkiewicz wrote:
Ah, okay. Here is full simplified patch.
From: Bartlomiej Zolnierkiewicz b.zolnier...@samsung.com
Subject: [PATCH v2] ARM: EXYNOS: PL330 MDMA1 fix for revision 0 of
Exynos4210 SOC
Commit 8214513 (ARM: EXYNOS: fix address for EXYNOS4 MDMA1)
changed EXYNOS specific setup of PL330 DMA engine to use 'non-secure'
mdma1 address instead of 'secure' one (from 0x1284 to 0x1285)
to fix issue with some Exynos4212 SOCs. Unfortunately it brakes
PL330 setup for revision 0 of Exynos4210 SOC (mdma1 device cannot
be found at 'non-secure' address):
[0.566245] dma-pl330 dma-pl330.2: PERIPH_ID 0x0, PCELL_ID 0x0 !
[0.566278] dma-pl330: probe of dma-pl330.2 failed with error -22
Fix it by using 'secure' mdma1 address on Exynos4210 revision 0 SOC.
Reviewed-by: Tomasz Figa t.f...@samsung.com
Cc: Kukjin Kim kgene@samsung.com
Signed-off-by: Bartlomiej Zolnierkiewicz b.zolnier...@samsung.com
Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com
---
arch/arm/mach-exynos/dma.c |3 +++
arch/arm/mach-exynos/include/mach/map.h |1 +
2 files changed, 4 insertions(+)
Index: b/arch/arm/mach-exynos/dma.c
===
--- a/arch/arm/mach-exynos/dma.c 2012-11-07 18:20:36.561743865 +0100
+++ b/arch/arm/mach-exynos/dma.c 2012-11-08 10:48:23.445067606 +0100
@@ -275,6 +275,9 @@ static int __init exynos_dma_init(void)
exynos_pdma1_pdata.nr_valid_peri =
ARRAY_SIZE(exynos4210_pdma1_peri);
exynos_pdma1_pdata.peri_id = exynos4210_pdma1_peri;
+
+ if (samsung_rev() == EXYNOS4210_REV_0)
+ exynos_mdma1_device.res.start = EXYNOS4_PA_S_MDMA1;
} else if (soc_is_exynos4212() || soc_is_exynos4412()) {
exynos_pdma0_pdata.nr_valid_peri =
ARRAY_SIZE(exynos4212_pdma0_peri);
Index: b/arch/arm/mach-exynos/include/mach/map.h
===
--- a/arch/arm/mach-exynos/include/mach/map.h 2012-11-07
18:20:44.801743862 +0100
+++ b/arch/arm/mach-exynos/include/mach/map.h 2012-11-08
10:48:40.597067605 +0100
@@ -92,6 +92,7 @@
#define EXYNOS4_PA_MDMA0 0x1081
#define EXYNOS4_PA_MDMA1 0x1285
+#define EXYNOS4_PA_S_MDMA1 0x1284
#define EXYNOS4_PA_PDMA0 0x1268
#define EXYNOS4_PA_PDMA1 0x1269
#define EXYNOS5_PA_MDMA0 0x1080
Looks good to me, and I think, this can be handled separate from this
series.
Vinod, if you're ok, let me pick this up into Samsung tree.
Thanks.
Best regards,
Kgene.
--
Kukjin Kim kgene@samsung.com, Senior Engineer,
SW Solution Development Team, Samsung Electronics Co., Ltd.
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH V3] memcg, oom: provide more precise dump info while memcg oom happening
On 11/09/2012 12:25 AM, Michal Hocko wrote:
On Thu 08-11-12 23:52:47, Sha Zhengju wrote:
[...]
(2) After change
[ 269.225628] mal invoked oom-killer: gfp_mask=0xd0, order=0, oom_score_adj=0
[ 269.225633] mal cpuset=/ mems_allowed=0-1
[ 269.225636] Pid: 4616, comm: mal Not tainted 3.6.0+ #25
[ 269.225637] Call Trace:
[ 269.225647] [8111b9c4] dump_header+0x84/0xd0
[ 269.225650] [8111c691] oom_kill_process+0x331/0x350
[ 269.225710] ...(call trace)
[ 269.225713] [81517325] page_fault+0x25/0x30
[ 269.225716] Task in /1/2 killed as a result of limit of /1
[ 269.225718] memory: usage 511732kB, limit 512000kB, failcnt 5071
[ 269.225720] memory+swap: usage 563200kB, limit 563200kB, failcnt 57
[ 269.225721] kmem: usage 0kB, limit 9007199254740991kB, failcnt 0
[ 269.225722] Memory cgroup stats:cache:8KB rss:511724KB mapped_file:4KB
swap:51468KB inactive_anon:265864KB active_anon:245832KB inactive_file:0KB
active_file:0KB unevictable:0KB
[ 269.225741] [ pid ] uid tgid total_vm rss nr_ptes swapents
oom_score_adj name
[ 269.225757] [ 4554] 0 455416626 473 17 25
0 bash
[ 269.225759] [ 4611] 0 4611 10332890231 20812260
0 mal
[ 269.225762] [ 4616] 0 4616 10332832799 88 7562
0 mal
[ 269.225764] Memory cgroup out of memory: Kill process 4611 (mal) score 699
or sacrifice child
[ 269.225766] Killed process 4611 (mal) total-vm:413312kB, anon-rss:360632kB,
file-rss:292kB
This version provides more pointed info for memcg in Memory cgroup stats
section.
Looks much better!
Change log:
v3--- v2
1. fix towards hierarchy
2. undo rework dump_tasks
v2--- v1
1. some modification towards hierarchy
2. rework dump_tasks
3. rebased on Michal's mm tree since-3.6
Signed-off-by: Sha Zhengjuhandai@taobao.com
---
mm/memcontrol.c | 41 +++--
mm/oom_kill.c |6 --
2 files changed, 35 insertions(+), 12 deletions(-)
diff --git a/mm/memcontrol.c b/mm/memcontrol.c
index 0eab7d5..17317fa 100644
--- a/mm/memcontrol.c
+++ b/mm/memcontrol.c
[...]
@@ -1501,8 +1509,8 @@ static void move_unlock_mem_cgroup(struct mem_cgroup
*memcg,
spin_unlock_irqrestore(memcg-move_lock, *flags);
}
+#define K(x) ((x) (PAGE_SHIFT-10))
/**
- * mem_cgroup_print_oom_info: Called from OOM with tasklist_lock held in read
mode.
No need to remove this just fix it:
* mem_cgroup_print_oom_info: Print OOM information relevant to memory
controller.
* @memcg: The memory cgroup that went over limit
* @p: Task that is going to be killed
*
@@ -1520,8 +1528,10 @@ void mem_cgroup_print_oom_info(struct mem_cgroup *memcg,
struct task_struct *p)
*/
static char memcg_name[PATH_MAX];
int ret;
+ struct mem_cgroup *mi;
+ unsigned int i;
- if (!memcg || !p)
+ if (!p)
return;
rcu_read_lock();
@@ -1569,6 +1579,25 @@ done:
res_counter_read_u64(memcg-kmem, RES_USAGE) 10,
res_counter_read_u64(memcg-kmem, RES_LIMIT) 10,
res_counter_read_u64(memcg-kmem, RES_FAILCNT));
+
+ printk(KERN_INFO Memory cgroup stats:);
Memory cgroup hierarchy stats is probably a better fit with the
current implementation.
+ for (i = 0; i MEM_CGROUP_STAT_NSTATS; i++) {
+ long long val = 0;
+ if (i == MEM_CGROUP_STAT_SWAP !do_swap_account)
+ continue;
+ for_each_mem_cgroup_tree(mi, memcg)
+ val += mem_cgroup_read_stat(mi, i);
+ printk(KERN_CONT %s:%lldKB , mem_cgroup_stat_names[i],
K(val));
+ }
+
+ for (i = 0; i NR_LRU_LISTS; i++) {
+ unsigned long long val = 0;
+
+ for_each_mem_cgroup_tree(mi, memcg)
+ val += mem_cgroup_nr_lru_pages(mi, BIT(i));
+ printk(KERN_CONT %s:%lluKB , mem_cgroup_lru_names[i], K(val));
+ }
+ printk(KERN_CONT \n);
This is nice and simple I am just thinking whether it is enough. Say
that you have a deeper hierarchy and the there is a safety limit in the
its root
A (limit)
/|\
B C D
|\
E F
and we trigger an OOM on the A's limit. Now we know that something blew
up but what it was we do not know. Wouldn't it be better to swap the for
and for_each_mem_cgroup_tree loops? Then we would see the whole
hierarchy and can potentially point at the group which doesn't behave.
Memory cgroup stats for A/: ...
Memory cgroup stats for A/B/: ...
Memory cgroup stats for A/C/: ...
Memory cgroup stats for A/D/: ...
Memory cgroup stats for A/D/E/: ...
Memory cgroup stats for A/D/F/: ...
Would it still fit in with your use case?
[...]
We haven't used those complicate hierarchy yet, but it sounds a good
suggestion. :)
Hierarchy is a little complex to use from
Re: [PATCH 2/2] pinctrl/nomadik: make independent of prcmu driver
On Thu, Nov 8, 2012 at 6:11 PM, Stephen Warren swar...@wwwdotorg.org wrote: Do you actually need to store the run-time data in struct nmk_pinctrl_soc_data too? I would have expected all the soc_data pointers to remain const, and to store the runtime register pointer somewhere else, and perhaps pass it as a separate parameter to the relevant init functions; wouldn't that make the patch much smaller? OK point taken, I'm sending a v2... Yours, Linus Walleij -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: perf: POWER-event translation questions
On Thu, Nov 8, 2012 at 2:10 AM, Sukadev Bhattiprolu
suka...@linux.vnet.ibm.com wrote:
Looking for feedback on this prototype for making POWER-specific event
translations available in sysfs. It is based on the patchset:
https://lkml.org/lkml/2012/11/7/402
which makes the translations for _generic_ events in POWER available in sysfs:
Since this is in POWER7 specific code I am assigning the names given in the
POWER7 CPU spec for now.
I had earlier tried mapping these events to generic names outside sysfs:
Power7 name Generic name
cmpl-stall-fxu stalled-cycles-fixed-point
cmpl-stall-lsu stalled-cycles-load-store
cmpl-stall-ifu stalled-cycles-instruction-fetch
cmpl-stall-bru stalled-cycles-branch-unit
But like Stephane Eranian pointed out mapping such events across architectures
can be confusing.
Another challenge I suspect we will have is the extremely long generic names
we could end up with as the events get more specific.
1. Can we have more than one name for an event ? i.e two sysfs entries,
eg: 'cmpl-stall-fxu' and 'stalled-cycles-fixed-point' for an event ?
Yes, you can. What is really used is the content of the file and two files
can have the same content.
2. Can we allow hyphens in the {name} token (please see my change to
util/parse-events.l below). With this change, I can run:
The current code does not support this but Andi fixed that in his HSW patch
and I use it for the PEBS-LL patch series as well.
perf stat -e cpu/cmplu-stall-bru /tmp/nop
without any changes to the user level tool (parse-events.l) I have
tested some common cases, not sure if it will break something :-)
If we are going to create generic or arch specific sysfs entries in
/sys/bus/event_source/devices/cpu/events, do we need to add corresponding
entry in tools/perf/util/parse-events.l ?
Shouldn't be necessary. perf should grab those events automatically from sysfs.
As per Jiri, the hardcoded tables are only used to support backward
compatibility
for kernels without sysfs event entries.
Sukadev
---
arch/powerpc/perf/power7-pmu.c | 13 +
tools/perf/util/parse-events.l |2 +-
2 files changed, 14 insertions(+), 1 deletions(-)
diff --git a/arch/powerpc/perf/power7-pmu.c b/arch/powerpc/perf/power7-pmu.c
index aa9f588..9f46abc 100644
--- a/arch/powerpc/perf/power7-pmu.c
+++ b/arch/powerpc/perf/power7-pmu.c
@@ -303,6 +303,10 @@ static void power7_disable_pmc(unsigned int pmc,
unsigned long mmcr[])
#definePM_LD_MISS_L1 0x400f0
#definePM_BRU_FIN 0x10068
#definePM_BRU_MPRED0x400f6
+#definePM_CMPLU_STALL_FXU 0x20014
+#definePM_CMPLU_STALL_LSU 0x20012
+#definePM_CMPLU_STALL_IFU 0x4004c
+#definePM_CMPLU_STALL_BRU 0x4004e
static int power7_generic_events[] = {
[PERF_COUNT_HW_CPU_CYCLES] =PM_CYC,
@@ -369,6 +373,11 @@ EVENT_ATTR(cache-misses, LD_MISS_L1);
EVENT_ATTR(branch-instructions,BRU_FIN);
EVENT_ATTR(branch-misses, BRU_MPRED);
+EVENT_ATTR(cmplu-stall-fxu,CMPLU_STALL_FXU);
+EVENT_ATTR(cmplu-stall-lsu,CMPLU_STALL_LSU);
+EVENT_ATTR(cmplu-stall-ifu,CMPLU_STALL_IFU);
+EVENT_ATTR(cmplu-stall-bru,CMPLU_STALL_BRU);
+
static struct attribute *power7_events_attr[] = {
EVENT_PTR(CYC),
EVENT_PTR(GCT_NOSLOT_CYC),
@@ -378,6 +387,10 @@ static struct attribute *power7_events_attr[] = {
EVENT_PTR(LD_MISS_L1),
EVENT_PTR(BRU_FIN),
EVENT_PTR(BRU_MPRED),
+ EVENT_PTR(CMPLU_STALL_FXU),
+ EVENT_PTR(CMPLU_STALL_LSU),
+ EVENT_PTR(CMPLU_STALL_IFU),
+ EVENT_PTR(CMPLU_STALL_BRU),
NULL,
};
diff --git a/tools/perf/util/parse-events.l b/tools/perf/util/parse-events.l
index c87efc1..1967bb2 100644
--- a/tools/perf/util/parse-events.l
+++ b/tools/perf/util/parse-events.l
@@ -80,7 +80,7 @@ event [^,{}/]+
num_dec[0-9]+
num_hex0x[a-fA-F0-9]+
num_raw_hex[a-fA-F0-9]+
-name [a-zA-Z_*?][a-zA-Z0-9_*?]*
+name [-a-zA-Z_*?][-a-zA-Z0-9_*?]*
modifier_event [ukhpGH]{1,8}
modifier_bp[rwx]{1,3}
--
1.7.1
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v2] pinctrl/nomadik: make independent of prcmu driver
From: Jonas Aaberg jonas.ab...@stericsson.com
Currently there are some unnecessary criss-cross
dependencies between the PRCMU driver in MFD and a lot of
other drivers, mainly because other drivers need to poke
around in the PRCM register range.
In cases like this there are actually just a few select
registers that the pinctrl driver need to read/modify/write,
and it turns out that no other driver is actually using
these registers, so there are no concurrency issues
whatsoever.
So: don't let the location of the register range complicate
things, just poke into these registers directly and skip
a layer of indirection.
Take this opportunity to add kerneldoc to the pinctrl
state container.
Cc: Loic Pallardy loic.palla...@st.com
Signed-off-by: Jonas Aaberg jonas.ab...@stericsson.com
Signed-off-by: Linus Walleij linus.wall...@linaro.org
---
ChangeLog v1-v2:
- Have the pointer in the pin controller state container
instead of as part of SoC data.
---
drivers/pinctrl/pinctrl-nomadik.c | 59 ++-
1 file changed, 39 insertions(+), 20 deletions(-)
diff --git a/drivers/pinctrl/pinctrl-nomadik.c
b/drivers/pinctrl/pinctrl-nomadik.c
index 22f6937..6a95d04 100644
--- a/drivers/pinctrl/pinctrl-nomadik.c
+++ b/drivers/pinctrl/pinctrl-nomadik.c
@@ -30,20 +30,6 @@
#include linux/pinctrl/pinconf.h
/* Since we request GPIOs from ourself */
#include linux/pinctrl/consumer.h
-/*
- * For the U8500 archs, use the PRCMU register interface, for the older
- * Nomadik, provide some stubs. The functions using these will only be
- * called on the U8500 series.
- */
-#ifdef CONFIG_ARCH_U8500
-#include linux/mfd/dbx500-prcmu.h
-#else
-static inline u32 prcmu_read(unsigned int reg) {
- return 0;
-}
-static inline void prcmu_write(unsigned int reg, u32 value) {}
-static inline void prcmu_write_masked(unsigned int reg, u32 mask, u32 value) {}
-#endif
#include linux/platform_data/pinctrl-nomadik.h
#include asm/mach/irq.h
@@ -82,10 +68,18 @@ struct nmk_gpio_chip {
u32 lowemi;
};
+/**
+ * struct nmk_pinctrl - state container for the Nomadik pin controller
+ * @dev: containing device pointer
+ * @pctl: corresponding pin controller device
+ * @soc: SoC data for this specific chip
+ * @prcm_base: PRCM register range virtual base
+ */
struct nmk_pinctrl {
struct device *dev;
struct pinctrl_dev *pctl;
const struct nmk_pinctrl_soc_data *soc;
+ void __iomem *prcm_base;
};
static struct nmk_gpio_chip *
@@ -247,6 +241,15 @@ nmk_gpio_disable_lazy_irq(struct nmk_gpio_chip *nmk_chip,
unsigned offset)
dev_dbg(nmk_chip-chip.dev, %d: clearing interrupt mask\n, gpio);
}
+static void nmk_write_masked(void __iomem *reg, u32 mask, u32 value)
+{
+ u32 val;
+
+ val = readl(reg);
+ val = ((val ~mask) | (value mask));
+ writel(val, reg);
+}
+
static void nmk_prcm_altcx_set_mode(struct nmk_pinctrl *npct,
unsigned offset, unsigned alt_num)
{
@@ -285,8 +288,8 @@ static void nmk_prcm_altcx_set_mode(struct nmk_pinctrl
*npct,
if (pin_desc-altcx[i].used == true) {
reg = gpiocr_regs[pin_desc-altcx[i].reg_index];
bit = pin_desc-altcx[i].control_bit;
- if (prcmu_read(reg) BIT(bit)) {
- prcmu_write_masked(reg, BIT(bit), 0);
+ if (readl(npct-prcm_base + reg) BIT(bit)) {
+ nmk_write_masked(npct-prcm_base + reg,
BIT(bit), 0);
dev_dbg(npct-dev,
PRCM GPIOCR: pin %i:
alternate-C%i has been disabled\n,
offset, i+1);
@@ -314,8 +317,8 @@ static void nmk_prcm_altcx_set_mode(struct nmk_pinctrl
*npct,
if (pin_desc-altcx[i].used == true) {
reg = gpiocr_regs[pin_desc-altcx[i].reg_index];
bit = pin_desc-altcx[i].control_bit;
- if (prcmu_read(reg) BIT(bit)) {
- prcmu_write_masked(reg, BIT(bit), 0);
+ if (readl(npct-prcm_base + reg) BIT(bit)) {
+ nmk_write_masked(npct-prcm_base + reg,
BIT(bit), 0);
dev_dbg(npct-dev,
PRCM GPIOCR: pin %i: alternate-C%i has
been disabled\n,
offset, i+1);
@@ -327,7 +330,7 @@ static void nmk_prcm_altcx_set_mode(struct nmk_pinctrl
*npct,
bit = pin_desc-altcx[alt_index].control_bit;
dev_dbg(npct-dev, PRCM GPIOCR: pin %i: alternate-C%i has been
selected\n,
offset, alt_index+1);
- prcmu_write_masked(reg, BIT(bit), BIT(bit));
+ nmk_write_masked(npct-prcm_base + reg, BIT(bit), BIT(bit));
}
static void __nmk_config_pin(struct nmk_gpio_chip
[GIT PULL] sound fixes for 3.7-rc5
Linus, The following changes since commit 16c2e1fae8d60a9d6d16e009a76ba3472568e094: ALSA: ice1724: Fix rate setup after resume (2012-10-31 07:41:42 +0100) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound.git tags/sound-3.7 for you to fetch changes up to 8bb4d9ce08b0a92ca174e41d92c180328f86173f: ALSA: Fix card refcount unbalance (2012-11-08 14:36:18 +0100) Sound fixes for 3.7-rc5 Most of commits are for stable and regression fixes. Except for one fix for a regression in 3.7-rc4, there are all driver local changes, so nothing too much to worry. Adrian Knoth (1): ALSA: hdspm - Fix sync check reporting on RME RayDAT Alexander Stein (1): ALSA: hda: Cirrus: Fix coefficient index for beep configuration Daniel J Blueman (2): ALSA: HDA: Fix digital microphone on CS420x ALSA: HDA: Mark CS260x immutable structures const Kailang Yang (2): ALSA: hda - Improve HP depop when system enter to S3 ALSA: hda - Add new codec ALC668 and ALC900 (default name ALC1150) Lars R. Damerow (1): ALSA: hda - support Teradici 2200 host card audio Masanari Iida (1): ALSA: Fix typo in drivers sound Ondrej Zary (1): ALSA: es1968: Add ESS vendor ID to pm_whitelist Takashi Iwai (6): ALSA: hda - Force to reset IEC958 status bits for AD codecs ALSA: hda - Fix empty DAC filling in patch_via.c ALSA: hda - Fix invalid connections in VT1802 codec ALSA: hda - Add pin fixups for ASUS G75 ALSA: usb-audio: Fix crash at re-preparing the PCM stream ALSA: Fix card refcount unbalance sound/core/oss/mixer_oss.c| 1 + sound/core/oss/pcm_oss.c | 1 + sound/core/pcm_native.c | 6 -- sound/core/sound.c| 2 +- sound/core/sound_oss.c| 2 +- sound/i2c/other/ak4113.c | 2 +- sound/i2c/other/ak4114.c | 2 +- sound/i2c/other/ak4117.c | 2 +- sound/pci/es1968.c| 2 ++ sound/pci/hda/hda_intel.c | 2 ++ sound/pci/hda/patch_analog.c | 1 + sound/pci/hda/patch_cirrus.c | 21 - sound/pci/hda/patch_realtek.c | 26 +- sound/pci/hda/patch_via.c | 36 +--- sound/pci/rme9652/hdspm.c | 5 +++-- sound/soc/codecs/cs42l52.c| 2 +- sound/soc/codecs/wm8994.c | 2 +- sound/usb/endpoint.c | 13 + sound/usb/endpoint.h | 1 + sound/usb/pcm.c | 3 +++ 20 files changed, 92 insertions(+), 40 deletions(-) -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH V3] memcg, oom: provide more precise dump info while memcg oom happening
On 11/09/2012 04:12 PM, Kamezawa Hiroyuki wrote: (2012/11/09 0:52), Sha Zhengju wrote: From: Sha Zhengju handai@taobao.com Current when a memcg oom is happening the oom dump messages is still global state and provides few useful info for users. This patch prints more pointed memcg page statistics for memcg-oom. We set up a simple cgroup hierarchy for test: root_memcg | 1 (use_hierachy=1, with a process) | 2 (its process will be killed by memcg oom) Following are samples of oom output: (1)Before change: [ 295.754215] mal invoked oom-killer: gfp_mask=0xd0, order=0, oom_score_adj=0 [ 295.754219] mal cpuset=/ mems_allowed=0-1 [ 295.754221] Pid: 4623, comm: mal Not tainted 3.6.0+ #26 [ 295.754223] Call Trace: [ 295.754230] [8111b9c4] dump_header+0x84/0xd0 [ 295.754233] [8111c691] oom_kill_process+0x331/0x350 . (call trace) [ 295.754288] [815171e5] page_fault+0x25/0x30 [ 295.754291] Task in /1/2 killed as a result of limit of /1 [ 295.754293] memory: usage 511640kB, limit 512000kB, failcnt 4471 [ 295.754294] memory+swap: usage 563200kB, limit 563200kB, failcnt 22 [ 295.754296] kmem: usage 0kB, limit 9007199254740991kB, failcnt 0 [ 295.754297] Mem-Info: [ 295.754298] Node 0 DMA per-cpu:print per cpu pageset stat [ 295.754300] CPU0: hi:0, btch: 1 usd: 0 .. [ 295.754302] CPU15: hi:0, btch: 1 usd: 0 [ 295.754448] Node 0 DMA32 per-cpu: [ 295.754450] CPU0: hi: 186, btch: 31 usd: 181 .. [ 295.754451] CPU15: hi: 186, btch: 31 usd: 25 [ 295.754470] Node 0 Normal per-cpu: [ 295.754472] CPU0: hi: 186, btch: 31 usd: 56 .. [ 295.754473] CPU15: hi: 186, btch: 31 usd: 150 [ 295.754493] Node 1 Normal per-cpu: [ 295.754495] CPU0: hi: 186, btch: 31 usd: 0 .. [ 295.754496] CPU15: hi: 186, btch: 31 usd: 0 print global page state [ 295.754519] active_anon:57756 inactive_anon:73437 isolated_anon:0 [ 295.754519] active_file:2659 inactive_file:14291 isolated_file:0 [ 295.754519] unevictable:1268 dirty:0 writeback:4961 unstable:0 [ 295.754519] free:5979740 slab_reclaimable:2955 slab_unreclaimable:5460 [ 295.754519] mapped:2478 shmem:62 pagetables:994 bounce:0 [ 295.754519] free_cma:0 print per zone page state [ 295.754522] Node 0 DMA free:15884kB min:56kB low:68kB high:84kB active_anon:0kB inactive_anon:0kB active_file:0kB inactive_file:0kB unevictable:0kB isolated(anon):0kB isolated(file):0kB present:15884kB mlocked:0kB dirty:0kB writeback:0kB mapped:0kB shmem:0kB slab_reclaimable:0kB slab_unreclaimable:0kB kernel_stack:0kB pagetables:0kB unstable:0kB bounce:0kB free_cma:0kB writeback_tmp:0kB pages_scanned:0 all_unreclaimable? no [ 295.754527] lowmem_reserve[]: 0 2966 12013 12013 [ 295.754530] Node 0 DMA32 free:3041228kB min:11072kB . [ 295.754535] lowmem_reserve[]: 0 0 9046 9046 [ 295.754537] Node 0 Normal free:8616716kB min:33756kB . [ 295.754542] lowmem_reserve[]: 0 0 0 0 [ 295.754545] Node 1 Normal free:12245132kB min:45220kB [ 295.754550] lowmem_reserve[]: 0 0 0 0 [ 295.754552] Node 0 DMA: 1*4kB (U) 1*8kB (U) 0*16kB 0*32kB 2*64kB (U) 1*128kB (U) 1*256kB (U) 0*512kB 1*1024kB (U) 1*2048kB (R) 3*4096kB (M) = 15884kB [ 295.754563] Node 0 DMA32: 5*4kB (M) 3*8kB (M) 6*16kB (UM) ... 738*4096kB (MR) = 3041228kB [ 295.754574] Node 0 Normal: 16*4kB (EM) 165*8kB (UEM) ... 2101*4096kB (MR) = 8616840kB [ 295.754586] Node 1 Normal: 768*4kB (UEM) 924*8kB (UEM) ... 048kB (EM) 2976*4096kB (MR) = 12245264kB [ 295.754598] 25266 total pagecache pages [ 295.754599] 7227 pages in swap cache print global swap cache stat [ 295.754600] Swap cache stats: add 21474, delete 14247, find 533/576 [ 295.754601] Free swap = 2016000kB [ 295.754602] Total swap = 2096444kB [ 295.816119] 6291440 pages RAM [ 295.816121] 108291 pages reserved [ 295.816122] 9427 pages shared [ 295.816123] 195843 pages non-shared [ 295.816124] [ pid ] uid tgid total_vm rss nr_ptes swapents oom_score_adj name [ 295.816161] [ 4569] 0 456916626 475 18 30 0 bash [ 295.816164] [ 4622] 0 4622 10332887541 20814950 0 mal [ 295.816167] [ 4623] 0 4623 10332833468 85 5162 0 mal [ 295.816171] Memory cgroup out of memory: Kill process 4622 (mal) score 699 or sacrifice child [ 295.816173] Killed process 4622 (mal) total-vm:413312kB, anon-rss:349872kB, file-rss:292kB We can see that messages dumped by show_free_areas() are longsome and can provide so limited info for memcg that just happen oom. (2) After change [ 269.225628] mal
Re: [PATCH V3] memcg, oom: provide more precise dump info while memcg oom happening
On Fri 09-11-12 18:23:07, Sha Zhengju wrote:
On 11/09/2012 12:25 AM, Michal Hocko wrote:
On Thu 08-11-12 23:52:47, Sha Zhengju wrote:
[...]
+ for (i = 0; i MEM_CGROUP_STAT_NSTATS; i++) {
+ long long val = 0;
+ if (i == MEM_CGROUP_STAT_SWAP !do_swap_account)
+ continue;
+ for_each_mem_cgroup_tree(mi, memcg)
+ val += mem_cgroup_read_stat(mi, i);
+ printk(KERN_CONT %s:%lldKB , mem_cgroup_stat_names[i],
K(val));
+ }
+
+ for (i = 0; i NR_LRU_LISTS; i++) {
+ unsigned long long val = 0;
+
+ for_each_mem_cgroup_tree(mi, memcg)
+ val += mem_cgroup_nr_lru_pages(mi, BIT(i));
+ printk(KERN_CONT %s:%lluKB , mem_cgroup_lru_names[i], K(val));
+ }
+ printk(KERN_CONT \n);
This is nice and simple I am just thinking whether it is enough. Say
that you have a deeper hierarchy and the there is a safety limit in the
its root
A (limit)
/|\
B C D
|\
E F
and we trigger an OOM on the A's limit. Now we know that something blew
up but what it was we do not know. Wouldn't it be better to swap the for
and for_each_mem_cgroup_tree loops? Then we would see the whole
hierarchy and can potentially point at the group which doesn't behave.
Memory cgroup stats for A/: ...
Memory cgroup stats for A/B/: ...
Memory cgroup stats for A/C/: ...
Memory cgroup stats for A/D/: ...
Memory cgroup stats for A/D/E/: ...
Memory cgroup stats for A/D/F/: ...
Would it still fit in with your use case?
[...]
We haven't used those complicate hierarchy yet, but it sounds a good
suggestion. :)
Hierarchy is a little complex to use from our experience, and the
three cgroups involved in memcg oom can be different: memcg of
invoker, killed task, memcg of going over limit.Suppose a process in
B triggers oom and a victim in root A is selected to be killed, we
may as well want to know memcg stats just local in A cgroup(excludes
BCD). So besides hierarchy info, does it acceptable to also print
the local root node stats which as I did in the V1
version(https://lkml.org/lkml/2012/7/30/179).
Ohh, I probably wasn't clear enough. I didn't suggest cumulative
numbers. Only per group. So it would be something like:
for_each_mem_cgroup_tree(mi, memcg) {
printk(Memory cgroup stats for %s, memcg_name);
for (i = 0; i MEM_CGROUP_STAT_NSTATS; i++) {
if (i == MEM_CGROUP_STAT_SWAP !do_swap_account)
continue;
printk(KERN_CONT %s:%lldKB , mem_cgroup_stat_names[i],
K(mem_cgroup_read_stat(mi, i)));
}
for (i = 0; i NR_LRU_LISTS; i++)
printk(KERN_CONT %s:%lluKB , mem_cgroup_lru_names[i],
K(mem_cgroup_nr_lru_pages(mi, BIT(i;
printk(KERN_CONT\n);
}
Another one I'm hesitating is numa stats, it seems the output is
beginning to get more and more
NUMA stats are basically per node - per zone LRU data and that the
for(NR_LRU_LISTS) can be easily extended to cover that.
--
Michal Hocko
SUSE Labs
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] regulator: core: Update regulator_is_supported_voltage for fixed voltages
Commit c5f3939b8fe0 (regulator: core: Support fixed voltages in
regulator_is_supported_voltage()) adds support for fixed regulators
in regulator_is_supported_voltage.
In case of fixed regulators for which voltage cannot be changed,
regulator_is_supported_voltage should return success only if the
min_uV and max_uV parameters are same and it is equal to the current
voltage of the regulator.
Signed-off-by: Tushar Behera tushar.beh...@linaro.org
---
Currently this patch breaks MMC support for boards on which vmmc is a
fixed regulator and the voltage is not equal to either of 3.3v, 3.0v
or 1.8v. Earlier it used to work if the voltage was less than 3.3v.
drivers/regulator/core.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/regulator/core.c b/drivers/regulator/core.c
index 1a35251..4a377a7 100644
--- a/drivers/regulator/core.c
+++ b/drivers/regulator/core.c
@@ -1974,7 +1974,7 @@ int regulator_is_supported_voltage(struct regulator
*regulator,
if (!(rdev-constraints-valid_ops_mask REGULATOR_CHANGE_VOLTAGE)) {
ret = regulator_get_voltage(regulator);
if (ret = 0)
- return (min_uV = ret ret = max_uV);
+ return (ret == min_uV ret == max_uV);
else
return ret;
}
--
1.7.4.1
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[git pull] drm vmwgfx
Hi Linus, dropped the ball on a vmware patch, so two more fixes for vmwgfx are here, one for hibernate issue, one for a BUG trigger. Dave. The following changes since commit 4a48ed2334b7ae61dd11bb114fa35bd4ebdc1ca0: Merge branch 'drm-nouveau-fixes' of git://anongit.freedesktop.org/git/nouveau/linux-2.6 into drm-fixes (2012-11-09 14:57:02 +1000) are available in the git repository at: git://people.freedesktop.org/~airlied/linux drm-fixes for you to fetch changes up to afcc87aa6a233e52df73552dc1dc9ae3881b7cc8: drm/vmwgfx: Fix a case where the code would BUG when trying to pin GMR memory (2012-11-09 20:49:06 +1000) Thomas Hellstrom (2): drm/vmwgfx: Fix hibernation device reset drm/vmwgfx: Fix a case where the code would BUG when trying to pin GMR memory drivers/gpu/drm/vmwgfx/vmwgfx_dmabuf.c | 2 +- drivers/gpu/drm/vmwgfx/vmwgfx_drv.c| 5 + 2 files changed, 6 insertions(+), 1 deletion(-) -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: scsi target, likely GPL violation
For our commercial target core, we only use Linux kernel symbols that are not marked as GPL. In addition, we define the API between the target And this has what meaning ? The Linux kernel is a GPL work, any derivative work is a GPL work. The symbol tags are just a guidance. You do not have permission to build a non GPL derivative work of any code I own. The licensing determination is *derivative work* not symbols marked with _GPL. This has been stated publically by many developers many times. So either your work is truely not derivative of the kernel (which I find wildly improbable) or you have a problem and since you are aware of the complaints publically I guess probably a triple damages sized problem. But that's one for your lawyers and whatever opinion they have on the subject. You do btw have a second thing to consider - there are US patent grants for some functions in the kernel that only extend to GPL code so utilising some of the subsystems in the USA may give you other problems even if you can somehow manage to demonstrate your work is not derivative. RTS OS is based on a stock Linux enterprise kernel. This Linux kernel has naturally the ability to load either one of our standalone self-contained target module versions without any modifications. That's not the usual test for derivative work I've heard applied. I fail to understand the maintainer question however. If you were trying to block people adding target features that competed that would be a different thing. Alan -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: [PATCH v2 04/10] pwm: pwm-tiecap: Add device-tree binding support for APWM driver
On Fri, Nov 09, 2012 at 13:22:19, Thierry Reding wrote:
On Thu, Nov 08, 2012 at 01:23:11PM +0530, Philip, Avinash wrote:
This patch
1. Add support for device-tree binding for ECAP APWM driver.
2. Set size of pwm-cells set to 3 to support PWM channel number, PWM
period polarity configuration from device tree.
3. Add enable/disable clock gating in PWM subsystem common config space.
4. When here set .owner member in platform_driver structure to
THIS_MODULE.
Signed-off-by: Philip, Avinash avinashphi...@ti.com
Cc: Grant Likely grant.lik...@secretlab.ca
Cc: Rob Herring rob.herr...@calxeda.com
Cc: Rob Landley r...@landley.net
---
Changes since v1:
- Add separate patch for pinctrl support
- Add conditional check for PWM subsystem clock enable.
- Combined with HWMOD changes DT bindings.
- Remove the custom of xlate support.
:00 100644 000... fe24cac... A
Documentation/devicetree/bindings/pwm/pwm-tiecap.txt
:100644 100644 d6d4cf0... 0d43266... M drivers/pwm/pwm-tiecap.c
.../devicetree/bindings/pwm/pwm-tiecap.txt | 22 +
drivers/pwm/pwm-tiecap.c | 48
+++-
2 files changed, 69 insertions(+), 1 deletions(-)
diff --git a/Documentation/devicetree/bindings/pwm/pwm-tiecap.txt
b/Documentation/devicetree/bindings/pwm/pwm-tiecap.txt
new file mode 100644
index 000..fe24cac
--- /dev/null
+++ b/Documentation/devicetree/bindings/pwm/pwm-tiecap.txt
@@ -0,0 +1,22 @@
+TI SOC ECAP based APWM controller
+
+Required properties:
+- compatible: Must be ti,am33xx-ecap
+- #pwm-cells: Should be 3. Number of cells being used to specify PWM
property.
+ First cell specifies the per-chip index of the PWM to use, the second
+ cell is the period cycle in nanoseconds and bit 0 in the third cell is
I think this should be period in nanoseconds. I haven't heard period
cycle before.
Ok
+ used to encode the polarity of PWM output.
Maybe you should explicitly say how this is encoded.
Ok I will add details
...
+#define ECAPCLK_EN BIT(0)
+#define ECAPCLK_STOP_REQ BIT(1)
This one doesn't seem to align with the rest. Also, why is bit 0 called
_EN and bit 1 _STOP_REQ? Couldn't they be made more consistent, i.e.
_START and _STOP? Or _ENABLE and _DISABLE?
Ok I will change to PWMSS_ECAPCLK_EN PWMSS_ECAPCLK_STPO_REQ
+
+#define ECAPCLK_EN_ACK BIT(0)
+
+#define PWM_CELL_SIZE 3
You don't need a define for this.
I remove.
+
struct ecap_pwm_chip {
struct pwm_chip chip;
unsigned intclk_rate;
@@ -184,6 +194,16 @@ static const struct pwm_ops ecap_pwm_ops = {
.owner = THIS_MODULE,
};
+#ifdef CONFIG_OF
+static const struct of_device_id ecap_of_match[] = {
+ {
+ .compatible = ti,am33xx-ecap,
+ },
+ {},
+};
+MODULE_DEVICE_TABLE(of, ecap_of_match);
+#endif
+
I'm not sure if I remember correctly, but wasn't AM33xx support supposed
to be DT only? In that case you don't need the CONFIG_OF guards.
I will remove
...
pm_runtime_enable(pdev-dev);
+ pm_runtime_get_sync(pdev-dev);
Maybe put a blank line after this for readability.
Ok
+ if (!(pwmss_submodule_state_change(pdev-dev.parent, ECAPCLK_EN)
+ ECAPCLK_EN_ACK)) {
This is very hard to read, can you split this up into something like the
following please?
status = pwmss_submodule_state_change(pdev-dev.parent, ECAPCLK_EN);
if (!(status ECAPCLK_EN_ACK)) {
...
}
Ok I will correct it.
+ dev_err(pdev-dev, PWMSS config space clock enable
failure\n);
+ ret = -EINVAL;
+ goto pwmss_clk_failure;
+ }
+ pm_runtime_put_sync(pdev-dev);
Another blank line between the two above would be good.
Ok
...
+ .owner = THIS_MODULE,
+ .of_match_table = of_match_ptr(ecap_of_match),
Here as well, if AM33xx is DT-only, then the of_match_ptr() can be
dropped.
Ok I will drop.
Thanks
Avinash
},
.probe = ecap_pwm_probe,
.remove = __devexit_p(ecap_pwm_remove),
No __devexit_p() please.
Thierry
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
RE: [PATCH] pwm: Device tree support for PWM polarity.
On Fri, Nov 09, 2012 at 14:00:28, Thierry Reding wrote:
On Mon, Oct 29, 2012 at 11:10:27PM +0530, Philip, Avinash wrote:
From: Philip, Avinash avinashphi...@ti.com
Adds support for 3rd cell in pwm-specifier. PWM polarity is encoded in
device tree support in bit encoded form. Platforms require polarity of
PWM device initialized during PWM device initialization has to encode
polarity in 3rd cell of pwm-specifier.
Signed-off-by: Philip, Avinash avinashphi...@ti.com
---
:100644 100644 73ec962... e522c59... M
Documentation/devicetree/bindings/pwm/pwm.txt
:100644 100644 f5acdaa... 1c6d50b... M drivers/pwm/core.c
:100644 100644 112b314... d77c5b3... M include/linux/pwm.h
Documentation/devicetree/bindings/pwm/pwm.txt | 22 +++---
drivers/pwm/core.c| 13 -
include/linux/pwm.h |7 +++
3 files changed, 38 insertions(+), 4 deletions(-)
diff --git a/Documentation/devicetree/bindings/pwm/pwm.txt
b/Documentation/devicetree/bindings/pwm/pwm.txt
index 73ec962..e522c59 100644
--- a/Documentation/devicetree/bindings/pwm/pwm.txt
+++ b/Documentation/devicetree/bindings/pwm/pwm.txt
@@ -37,10 +37,26 @@ device:
pwm-names = backlight;
};
+Note that in the example above, specifying the pwm-names is redundant
+because the name backlight would be used as fallback anyway.
+
pwm-specifier typically encodes the chip-relative PWM number and the PWM
-period in nanoseconds. Note that in the example above, specifying the
-pwm-names is redundant because the name backlight would be used as
-fallback anyway.
+period in nanoseconds.
Can you separate this by a blank line, please?
Ok
+Optional pwm-specifier can be encoded in 3rd cell in bit encoded form.
+ -
+| Property | BIT position | Encoding |
+|-|
+| Polarity | 0 | Set - Polarity inversed |
+|| | Clear - Polarity Normal |
+ -
+
Using this kind of table isn't very common in device tree documentation
and the description above the table is a little vague. Maybe something
like this would be more explicit:
---[snip]---
Optionally, the pwm-specifier can encode a number of flags in a third
cell:
- bit 0: PWM signal polarity (0: normal polarity, 1: inverse polarity)
---[snip]---
+Exapmple with optional PWM specifier for inversed polarity
Example
Ok I will correct it.
+
+ bl: backlight {
+ pwms = pwm 0 500 1;
+ pwm-names = backlight;
+ };
+
2) PWM controller nodes
---
diff --git a/drivers/pwm/core.c b/drivers/pwm/core.c
index f5acdaa..1c6d50b 100644
--- a/drivers/pwm/core.c
+++ b/drivers/pwm/core.c
@@ -146,6 +146,15 @@ of_pwm_simple_xlate(struct pwm_chip *pc, const struct
of_phandle_args *args)
pwm_set_period(pwm, args-args[1]);
+ if (pc-of_pwm_n_cells 2) {
+ enum pwm_polarity polarity;
+
+ /* Initialize polarity of PWM device */
+ polarity = args-args[2] POLARITY_BIT ?
+ PWM_POLARITY_INVERSED : PWM_POLARITY_NORMAL;
Can we rewrite this as:
if (args-args[2] POLARITY_BIT)
pwm_set_polarity(pwm, PWM_POLARITY_INVERSED);
else
pwm_set_polarity(pwm, PWM_POLARITY_NORMAL);
?
Ok
+ pwm_set_polarity(pwm, polarity);
+ }
+
return pwm;
}
@@ -156,7 +165,9 @@ static void of_pwmchip_add(struct pwm_chip *chip)
if (!chip-of_xlate) {
chip-of_xlate = of_pwm_simple_xlate;
- chip-of_pwm_n_cells = 2;
+
+ if (chip-of_pwm_n_cells != 3)
+ chip-of_pwm_n_cells = 2;
}
I don't like the implicitness in this code. I think we should make this
more explicit for driver writers, so that if .of_xlate is set to NULL,
the default of_pwm_simple_xlate() is used. For all other cases we should
export of_pwm_xlate_with_flags(), so that the driver can explicitly set
the .of_xlate field to that function.
That will of course imply that the extra code that you added to
of_pwm_simple_xlate() is moved into a separate function.
Ok I will go for export of_pwm_xlate_with_flags().
of_node_get(chip-dev-of_node);
diff --git a/include/linux/pwm.h b/include/linux/pwm.h
index 112b314..d77c5b3 100644
--- a/include/linux/pwm.h
+++ b/include/linux/pwm.h
@@ -78,6 +78,13 @@ enum {
PWMF_ENABLED = 1 1,
};
+/*
+ * DT Platform property support.
+ * POLARITY - set bit 0 in DT platform property
+ */
+
+#define POLARITY_BIT BIT(0)
+
This doesn't belong in a public header. It
RE: [PATCH v2 08/10] pwm: pwm-tiehrpwm: Adding TBCLK gating support.
On Fri, Nov 09, 2012 at 13:41:04, Thierry Reding wrote:
On Thu, Nov 08, 2012 at 01:23:15PM +0530, Philip, Avinash wrote:
...
+ /* Some platforms require explicit tbclk gating */
+ if (of_property_read_bool(pdev-dev.of_node, tbclkgating)) {
Is it really necessary to have an extra boolean property for this?
Couldn't this just be handled by not defining a clock for the tbclk
consumer in board setup/DT
If no clk node defined, driver can still continue expecting this platform
the requirement is not there. So I will check for tbclk with devm_clk_get()
and continue by removing Boolean property.
+ pc-tbclk = clk_get(pdev-dev, tbclk);
You should be using devm_clk_get() or add a matching clk_put() in
.remove().
Ok
Thanks
Avinash
Thierry
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
RE: [PATCH v2 01/10] PWMSS: Add PWM Subsystem driver for parent-child relationship
On Fri, Nov 09, 2012 at 12:59:57, Thierry Reding wrote:
On Thu, Nov 08, 2012 at 01:23:08PM +0530, Philip, Avinash wrote:
diff --git a/Documentation/devicetree/bindings/pwm/tipwmss.txt
b/Documentation/devicetree/bindings/pwm/tipwmss.txt
new file mode 100644
index 000..b6c2814
--- /dev/null
+++ b/Documentation/devicetree/bindings/pwm/tipwmss.txt
@@ -0,0 +1,30 @@
[...]
+Also child nodes should also populated under PWMSS DT node.
+Example:
Maybe put an blank line between these two lines for readability?
Ok I will add.
+pwmss0: pwmss@4830 {
+ compatible = ti,am33xx-pwmss;
+ reg = 0x4830 0x10
+ 0x48300100 0x80
+ 0x48300180 0x80
+ 0x48300200 0x80;
I don't think you should list the register spaces of the children here.
From what I understand, all regions listed in the reg property are
supposed to be requested by the corresponding driver and therefore
cannot be used by any other device.
I will check correct it.
+ ti,hwmods = epwmss0;
+ #address-cells = 1;
+ #size-cells = 1;
+ status = disabled;
+ ranges;
I think to represent which memory regions go to the children, you should
put them in this ranges property, which would then look like this:
ranges = 0x48300100 0x48300100 0x80 /* ECAP */
0x48300180 0x48300180 0x80 /* EQEP */
0x48300200 0x48300200 0x80; /* EHRPWM */
I will correct it.
+
+ /* child nodes go here */
+};
Maybe you should actually list a full set of children here?
Ok.
diff --git a/drivers/pwm/Kconfig b/drivers/pwm/Kconfig
index 6e556c7..384a346 100644
--- a/drivers/pwm/Kconfig
+++ b/drivers/pwm/Kconfig
@@ -136,6 +136,7 @@ config PWM_TEGRA
config PWM_TIECAP
tristate ECAP PWM support
depends on SOC_AM33XX
+ select PWM_TIPWMSS
help
PWM driver support for the ECAP APWM controller found on AM33XX
TI SOC
@@ -146,6 +147,7 @@ config PWM_TIECAP
config PWM_TIEHRPWM
tristate EHRPWM PWM support
depends on SOC_AM33XX
+ select PWM_TIPWMSS
help
PWM driver support for the EHRPWM controller found on AM33XX
TI SOC
@@ -153,6 +155,15 @@ config PWM_TIEHRPWM
To compile this driver as a module, choose M here: the module
will be called pwm-tiehrpwm.
+config PWM_TIPWMSS
+ tristate TI PWM Subsytem parent support
+ depends on SOC_AM33XX (PWM_TIEHRPWM || PWM_TIECAP)
Since you select the symbol from the PWM_TIECAP and PWM_TIEHRPWM symbols
there is no need to depend on them, right? Oh, but maybe that's to make
sure the symbol is deselected automatically if neither user is selected.
I want to make sure that, symbol selected only if either are selected.
Perhaps this should actually be a hidden symbol (i.e. leave away the
prompt string in the tristate option) since it's purely a dependency and
not useful of its own.
Ok I will take care.
+ help
+ PWM Subsystem driver support for AM33xx SOC.
+
+ PWM submodules require PWM config space access from submodule
+ drivers and require common parent driver support.
+
config PWM_TWL6030
tristate TWL6030 PWM support
depends on TWL4030_CORE
diff --git a/drivers/pwm/Makefile b/drivers/pwm/Makefile
index 3b3f4c9..55f6fb2 100644
--- a/drivers/pwm/Makefile
+++ b/drivers/pwm/Makefile
@@ -12,5 +12,6 @@ obj-$(CONFIG_PWM_SPEAR) += pwm-spear.o
obj-$(CONFIG_PWM_TEGRA)+= pwm-tegra.o
obj-$(CONFIG_PWM_TIECAP) += pwm-tiecap.o
obj-$(CONFIG_PWM_TIEHRPWM) += pwm-tiehrpwm.o
+obj-$(CONFIG_PWM_TIPWMSS) += tipwmss.o
This should have a pwm- prefix as well.
Ok I will add.
obj-$(CONFIG_PWM_TWL6030) += pwm-twl6030.o
obj-$(CONFIG_PWM_VT8500) += pwm-vt8500.o
diff --git a/drivers/pwm/tipwmss.c b/drivers/pwm/tipwmss.c
new file mode 100644
index 000..c188348
--- /dev/null
+++ b/drivers/pwm/tipwmss.c
@@ -0,0 +1,142 @@
[...]
+#include tipwmss.h
+
+#define PWMSS_CLKCONFIG0x8 /* Clock gaitng reg, for PWM
submodules */
gating
Ok
+#define PWMSS_CLKSTATUS0xc /* Clock gating status reg */
+
+struct pwmss_info {
+ void __iomem*mmio_base;
+ struct mutexpwmss_lock;
+ u16 pwmss_clkconfig;
The indentation looks weird on this last field.
Ok I will correct it.
+};
+
+u16 pwmss_submodule_state_change(struct device *dev, int set)
+{
+ struct pwmss_info *info = dev_get_drvdata(dev);
+ u16 val;
+
+ val = readw(info-mmio_base + PWMSS_CLKCONFIG);
+ val |= set;
+ mutex_lock(info-pwmss_lock);
+ writew(val , info-mmio_base + PWMSS_CLKCONFIG);
+ mutex_unlock(info-pwmss_lock);
The mutex needs to span the whole read-modify-write sequence, not just
the write.
I missed. I will correct it.
Also, how do you clear this state?
Here is the hardware trick comes.
Re: How to debug system freeze (not detected by kernel debug options)
On Fri, 09 Nov 2012 02:19:33 + (GMT) Jongman Heo jongman@samsung.com wrote: Dear kernel hackers, I have a problem in SMP environment, in x86 platform (Intel Atom based embedded system) In UP, there is no issue, but in SMP, system freezed in tens of minutes (or shorter), if I perform IO test with flash memory and HDD simultaneously (using dd). I enabled relevant kernel debug options, like LOCKDEP, DETECT_SOFTLOCKUP, DETECT_HUNG_TASK, along with nmi_watchdog=1. (Yeah, this is somewhat old kernel, 2.6.35.14). But no debug message is shown. (I had checked that NMI interrupt count correctly increase.). Do you have any thoughts what can cause system freeze without being detected by LOCKDEP, watchdog, and other options. Hardware problems, firmware bugs, PATA controller hangs, some classes of PCI device hang, certain cases where for some reason the crash is so bad the kernel can't get the message out even though it has detected the failure. A good starting point is probably can you make two identical systems do it. If you've got a pair of boards which fed the same software set and have the same flash and hdd crash in the same way its unlikely to be a faulty board. You may find it useful to make the NMI timeout handler trigger a directly detectable event via an I/O port if your platform has a buzzer or LED directly I/O mapped somewhere. Failing that the fastest approach may be to use hardware debugging aids if you have access to them for that platform. Alan -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] fix build waring: drivers/regulator/core.c: warning: ‘val’ may be used uninitialized in this function [-Wuninitialized]
On Fri, Nov 09, 2012 at 05:29:40PM +0800, helight wrote: - unsigned int val; int ret; + unsigned int val = 0; This sort of change is really not at all helpful, we should be making sure that whatever path should be initialising the value but isn't does so, just initialising at declaration means that if the compiler has spotted a genuine error we won't fix it. signature.asc Description: Digital signature
Re: [PATCH 1/9 v3] cgroup: add cgroup_subsys-post_create()
Hi Tejun,
On 08.11.2012 20:07, Tejun Heo wrote: Subject: cgroup: add
cgroup_subsys-post_create()
Currently, there's no way for a controller to find out whether a new
cgroup finished all -create() allocatinos successfully and is
considered live by cgroup.
I'd like add hierarchy support to net_prio and the first thing to
do is to get rid of get_prioidx(). It looks like it would be nice to be
able to use use_id and post_create() for this but as I read the code
this might not work because the netdev might access resources allocated
between create() and post_create(). So my question is would it make
sense to move
cgroup_create():
if (ss-use_id) {
err = alloc_css_id(ss, parent, cgrp);
if (err)
goto err_destroy;
}
part before create() or add some protection between create() and
post_create() callback in net_prio. I have a patch but I see
I could drop it completely if post_create() is there.
cheers,
daniel
From 84fbbdf0dc5d3460389e39a00a3ee553ee55b563 Mon Sep 17 00:00:00 2001
From: Daniel Wagner daniel.wag...@bmw-carit.de
Date: Thu, 8 Nov 2012 17:17:21 +0100
Subject: [PATCH] cgroups: net_prio: Use IDR library to assign netprio index
get_prioidx() allocated a new id whenever it was called. put_prioidx()
gave an id back. get_pioidx() could can reallocate the id later on.
So that is exactly what IDR offers and so let's use it.
Signed-off-by: Daniel Wagner daniel.wag...@bmw-carit.de
---
net/core/netprio_cgroup.c | 51
+--
1 file changed, 9 insertions(+), 42 deletions(-)
diff --git a/net/core/netprio_cgroup.c b/net/core/netprio_cgroup.c
index 847c02b..3c1b612 100644
--- a/net/core/netprio_cgroup.c
+++ b/net/core/netprio_cgroup.c
@@ -27,10 +27,7 @@
#include linux/fdtable.h
-#define PRIOIDX_SZ 128
-
-static unsigned long prioidx_map[PRIOIDX_SZ];
-static DEFINE_SPINLOCK(prioidx_map_lock);
+static DEFINE_IDA(netprio_ida);
static atomic_t max_prioidx = ATOMIC_INIT(0);
static inline struct cgroup_netprio_state *cgrp_netprio_state(struct
cgroup *cgrp)
@@ -39,34 +36,6 @@ static inline struct cgroup_netprio_state
*cgrp_netprio_state(struct cgroup *cgr
struct cgroup_netprio_state, css);
}
-static int get_prioidx(u32 *prio)
-{
- unsigned long flags;
- u32 prioidx;
-
- spin_lock_irqsave(prioidx_map_lock, flags);
- prioidx = find_first_zero_bit(prioidx_map, sizeof(unsigned long) *
PRIOIDX_SZ);
- if (prioidx == sizeof(unsigned long) * PRIOIDX_SZ) {
- spin_unlock_irqrestore(prioidx_map_lock, flags);
- return -ENOSPC;
- }
- set_bit(prioidx, prioidx_map);
- if (atomic_read(max_prioidx) prioidx)
- atomic_set(max_prioidx, prioidx);
- spin_unlock_irqrestore(prioidx_map_lock, flags);
- *prio = prioidx;
- return 0;
-}
-
-static void put_prioidx(u32 idx)
-{
- unsigned long flags;
-
- spin_lock_irqsave(prioidx_map_lock, flags);
- clear_bit(idx, prioidx_map);
- spin_unlock_irqrestore(prioidx_map_lock, flags);
-}
-
static int extend_netdev_table(struct net_device *dev, u32 new_len)
{
size_t new_size = sizeof(struct netprio_map) +
@@ -120,9 +89,9 @@ static struct cgroup_subsys_state *cgrp_create(struct
cgroup *cgrp)
if (cgrp-parent cgrp_netprio_state(cgrp-parent)-prioidx)
goto out;
- ret = get_prioidx(cs-prioidx);
- if (ret 0) {
- pr_warn(No space in priority index array\n);
+ cs-prioidx = ida_simple_get(netprio_ida, 0, 0, GFP_KERNEL);
+ if (cs-prioidx 0) {
+ ret = cs-prioidx;
goto out;
}
@@ -146,7 +115,7 @@ static void cgrp_destroy(struct cgroup *cgrp)
map-priomap[cs-prioidx] = 0;
}
rtnl_unlock();
- put_prioidx(cs-prioidx);
+ ida_simple_remove(netprio_ida, cs-prioidx);
kfree(cs);
}
@@ -284,12 +253,10 @@ struct cgroup_subsys net_prio_subsys = {
.module = THIS_MODULE,
/*
-* net_prio has artificial limit on the number of cgroups and
-* disallows nesting making it impossible to co-mount it with other
-* hierarchical subsystems. Remove the artificially low PRIOIDX_SZ
-* limit and properly nest configuration such that children follow
-* their parents' configurations by default and are allowed to
-* override and remove the following.
+* net_prio has artificial limit on properly nest
+* configuration such that children follow their parents'
+* configurations by default and are allowed to override and
+* remove the following.
*/
.broken_hierarchy = true,
};
--
1.7.11.7
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo
Re: [PATCH v2 04/10] pwm: pwm-tiecap: Add device-tree binding support for APWM driver
On Fri, Nov 09, 2012 at 10:59:30AM +, Philip, Avinash wrote: On Fri, Nov 09, 2012 at 13:22:19, Thierry Reding wrote: On Thu, Nov 08, 2012 at 01:23:11PM +0530, Philip, Avinash wrote: +#define ECAPCLK_EN BIT(0) +#define ECAPCLK_STOP_REQ BIT(1) This one doesn't seem to align with the rest. Also, why is bit 0 called _EN and bit 1 _STOP_REQ? Couldn't they be made more consistent, i.e. _START and _STOP? Or _ENABLE and _DISABLE? Ok I will change to PWMSS_ECAPCLK_EN PWMSS_ECAPCLK_STPO_REQ While at it, maybe move these defines to the pwm-tipwmss.h header file? After all that's the module that accesses the register that contains these bits. pgpAYVt81lNu2.pgp Description: PGP signature
Re: [PATCH cifs-next] fs: cifs: make smb_echo_interval tunable
On Thu, 8 Nov 2012 14:50:28 -0600 Chris J Arges chris.j.ar...@canonical.com wrote: Change SMB_ECHO_INTERVAL to make it a module parameter. BugLink: http://bugs.launchpad.net/bugs/1017622 BugLink: https://bugzilla.samba.org/show_bug.cgi?id=9006 It's customary to write up the reason for a change in the bug description. A pointer to a bug tracker is nice as a reference, but it's not reasonable to expect someone to chase down a bunch of bug tracker links when reading the git logs. It's also possible that these bug reports could go away or be unavailable when someone needs to track down the reason for a change. Reported-by: Oliver Dumschat-Hoette dumschat-hoe...@trisinus.de Signed-off-by: Chris J Arges chris.j.ar...@canonical.com --- fs/cifs/cifsfs.c |5 + fs/cifs/cifsglob.h |5 +++-- 2 files changed, 8 insertions(+), 2 deletions(-) diff --git a/fs/cifs/cifsfs.c b/fs/cifs/cifsfs.c index 5e62f44..25748b3 100644 --- a/fs/cifs/cifsfs.c +++ b/fs/cifs/cifsfs.c @@ -82,6 +82,11 @@ MODULE_PARM_DESC(cifs_max_pending, Simultaneous requests to server. module_param(enable_oplocks, bool, 0644); MODULE_PARM_DESC(enable_oplocks, Enable or disable oplocks. Default: y/Y/1); +unsigned short smb_echo_timeout = 60; +module_param(smb_echo_timeout, ushort, 0644); +MODULE_PARM_DESC(smb_echo_timeout, Timeout between two echo requests. +Default: 60. Timeout in seconds ); + extern mempool_t *cifs_sm_req_poolp; extern mempool_t *cifs_req_poolp; extern mempool_t *cifs_mid_poolp; diff --git a/fs/cifs/cifsglob.h b/fs/cifs/cifsglob.h index f5af252..d64dcd3 100644 --- a/fs/cifs/cifsglob.h +++ b/fs/cifs/cifsglob.h @@ -78,8 +78,9 @@ /* (max path length + 1 for null) * 2 for unicode*/ #define MAX_NAME 514 -/* SMB echo timeout -- FIXME: tunable? */ -#define SMB_ECHO_INTERVAL (60 * HZ) +/* SMB echo timeout */ +extern unsigned short smb_echo_timeout; +#define SMB_ECHO_INTERVAL (smb_echo_timeout * HZ) #include cifspdu.h I'm not so sure I like making this tunable... What would really be better is fixing the code to only echo when there are outstanding calls to the server. This also seems like a bit of a kludgy workaround for the real problem. From looking over the bug reports, it sounds like the real issue is that the server is timing out the connection while the client is suspended. It then has to wait until the next echo comes around to figure that out. Is that the case? If so, then I think what you really want here is a way to tell if the connection is still valid after resume. Perhaps there's some way to force an immediate SMB echo on these connections after resume? With that, there'd be little delay at all in contacting the server after a resume. The server would presumably send back a RST immediately in such a case and we could get on with the business of reconnecting. The cifs_demultiplex_thread does make some calls to try_to_freeze(). Perhaps checking the return value on those and kicking off an immediate echo if it returns true would be a better solution? -- Jeff Layton jlay...@redhat.com -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH V5 0/2] Upstream ST-Ericsson thermal driver
From: hongbo.zhang hongbo.zh...@linaro.com V4-V5 Changes: In patch Thermal: Add ST-Ericsson DB8500 thermal driver: - use flush_work instead of flush_work_sync since the later is deprecated now. - parameter trip_points of db8500_thermal_match_cdev is renamed to trip_point; - re-order oprerations in function db8500_thermal_update_config; hongbo.zhang (2): Thermal: Add ST-Ericsson DB8500 thermal driver. Thermal: Add ST-Ericsson DB8500 thermal properties and platform data. .../devicetree/bindings/thermal/db8500-thermal.txt | 44 ++ arch/arm/boot/dts/dbx5x0.dtsi | 14 + arch/arm/boot/dts/snowball.dts | 31 ++ arch/arm/configs/u8500_defconfig | 2 + arch/arm/mach-ux500/board-mop500.c | 64 +++ drivers/thermal/Kconfig| 20 + drivers/thermal/Makefile | 2 + drivers/thermal/db8500_cpufreq_cooling.c | 108 + drivers/thermal/db8500_thermal.c | 531 + include/linux/platform_data/db8500_thermal.h | 38 ++ 10 files changed, 854 insertions(+) create mode 100644 Documentation/devicetree/bindings/thermal/db8500-thermal.txt create mode 100644 drivers/thermal/db8500_cpufreq_cooling.c create mode 100644 drivers/thermal/db8500_thermal.c create mode 100644 include/linux/platform_data/db8500_thermal.h -- 1.7.11.3 -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH V5 1/2] Thermal: Add ST-Ericsson DB8500 thermal driver.
From: hongbo.zhang hongbo.zh...@linaro.com
This driver is based on the thermal management framework in thermal_sys.c. A
thermal zone device is created with the trip points to which cooling devices
can be bound, the current cooling device is cpufreq, e.g. CPU frequency is
clipped down to cool the CPU, and other cooling devices can be added and bound
to the trip points dynamically. The platform specific PRCMU interrupts are
used to active thermal update when trip points are reached.
Signed-off-by: hongbo.zhang hongbo.zh...@linaro.com
Reviewed-by: Viresh Kumar viresh.ku...@linaro.org
Reviewed-by: Francesco Lavra francescolavra...@gmail.com
---
.../devicetree/bindings/thermal/db8500-thermal.txt | 44 ++
drivers/thermal/Kconfig| 20 +
drivers/thermal/Makefile | 2 +
drivers/thermal/db8500_cpufreq_cooling.c | 108 +
drivers/thermal/db8500_thermal.c | 531 +
include/linux/platform_data/db8500_thermal.h | 38 ++
6 files changed, 743 insertions(+)
create mode 100644 Documentation/devicetree/bindings/thermal/db8500-thermal.txt
create mode 100644 drivers/thermal/db8500_cpufreq_cooling.c
create mode 100644 drivers/thermal/db8500_thermal.c
create mode 100644 include/linux/platform_data/db8500_thermal.h
diff --git a/Documentation/devicetree/bindings/thermal/db8500-thermal.txt
b/Documentation/devicetree/bindings/thermal/db8500-thermal.txt
new file mode 100644
index 000..2e1c06f
--- /dev/null
+++ b/Documentation/devicetree/bindings/thermal/db8500-thermal.txt
@@ -0,0 +1,44 @@
+* ST-Ericsson DB8500 Thermal
+
+** Thermal node properties:
+
+- compatible : stericsson,db8500-thermal;
+- reg : address range of the thermal sensor registers;
+- interrupts : interrupts generated from PRCMU;
+- interrupt-names : IRQ_HOTMON_LOW and IRQ_HOTMON_HIGH;
+- num-trips : number of total trip points, this is required, set it 0 if none,
+ if greater than 0, the following properties must be defined;
+- tripN-temp : temperature of trip point N, should be in ascending order;
+- tripN-type : type of trip point N, should be one of active passive hot
+ critical;
+- tripN-cdev-num : number of the cooling devices which can be bound to trip
+ point N, this is required if trip point N is defined, set it 0 if none,
+ otherwise the following cooling device names must be defined;
+- tripN-cdev-nameM : name of the No. M cooling device of trip point N;
+
+Usually the num-trips and tripN-*** are separated in board related dts files.
+
+Example:
+thermal@801573c0 {
+ compatible = stericsson,db8500-thermal;
+ reg = 0x801573c0 0x40;
+ interrupts = 21 0x4, 22 0x4;
+ interrupt-names = IRQ_HOTMON_LOW, IRQ_HOTMON_HIGH;
+
+ num-trips = 3;
+
+ trip0-temp = 75000;
+ trip0-type = active;
+ trip0-cdev-num = 1;
+ trip0-cdev-name0 = thermal-cpufreq-0;
+
+ trip1-temp = 8;
+ trip1-type = active;
+ trip1-cdev-num = 2;
+ trip1-cdev-name0 = thermal-cpufreq-0;
+ trip1-cdev-name1 = thermal-fan;
+
+ trip2-temp = 85000;
+ trip2-type = critical;
+ trip2-cdev-num = 0;
+}
diff --git a/drivers/thermal/Kconfig b/drivers/thermal/Kconfig
index e1cb6bd..54c8fd0 100644
--- a/drivers/thermal/Kconfig
+++ b/drivers/thermal/Kconfig
@@ -31,6 +31,26 @@ config CPU_THERMAL
and not the ACPI interface.
If you want this support, you should say Y here.
+config DB8500_THERMAL
+ bool DB8500 thermal management
+ depends on THERMAL
+ default y
+ help
+ Adds DB8500 thermal management implementation according to the thermal
+ management framework. A thermal zone with several trip points will be
+ created. Cooling devices can be bound to the trip points to cool this
+ thermal zone if trip points reached.
+
+config DB8500_CPUFREQ_COOLING
+ tristate DB8500 cpufreq cooling
+ depends on CPU_THERMAL
+ default y
+ help
+ Adds DB8500 cpufreq cooling devices, and these cooling devices can be
+ bound to thermal zone trip points. When a trip point reached, the
+ bound cpufreq cooling device turns active to set CPU frequency low to
+ cool down the CPU.
+
config SPEAR_THERMAL
bool SPEAr thermal sensor driver
depends on THERMAL
diff --git a/drivers/thermal/Makefile b/drivers/thermal/Makefile
index 885550d..c7a8dab 100644
--- a/drivers/thermal/Makefile
+++ b/drivers/thermal/Makefile
@@ -7,3 +7,5 @@ obj-$(CONFIG_CPU_THERMAL) += cpu_cooling.o
obj-$(CONFIG_SPEAR_THERMAL)+= spear_thermal.o
obj-$(CONFIG_RCAR_THERMAL) += rcar_thermal.o
obj-$(CONFIG_EXYNOS_THERMAL) += exynos_thermal.o
+obj-$(CONFIG_DB8500_THERMAL) += db8500_thermal.o
+obj-$(CONFIG_DB8500_CPUFREQ_COOLING) += db8500_cpufreq_cooling.o
diff --git a/drivers/thermal/db8500_cpufreq_cooling.c
[PATCH V5 2/2] Thermal: Add ST-Ericsson DB8500 thermal properties and platform data.
From: hongbo.zhang hongbo.zh...@linaro.com
This patch adds device tree properties for ST-Ericsson DB8500 thermal driver,
also adds the platform data to support the old fashion.
Signed-off-by: hongbo.zhang hongbo.zh...@linaro.com
Reviewed-by: Viresh Kumar viresh.ku...@linaro.org
---
arch/arm/boot/dts/dbx5x0.dtsi | 14 +
arch/arm/boot/dts/snowball.dts | 31 ++
arch/arm/configs/u8500_defconfig | 2 ++
arch/arm/mach-ux500/board-mop500.c | 64 ++
4 files changed, 111 insertions(+)
diff --git a/arch/arm/boot/dts/dbx5x0.dtsi b/arch/arm/boot/dts/dbx5x0.dtsi
index 4b0e0ca..731086b 100644
--- a/arch/arm/boot/dts/dbx5x0.dtsi
+++ b/arch/arm/boot/dts/dbx5x0.dtsi
@@ -203,6 +203,14 @@
reg = 0x80157450 0xC;
};
+ thermal@801573c0 {
+ compatible = stericsson,db8500-thermal;
+ reg = 0x801573c0 0x40;
+ interrupts = 21 0x4, 22 0x4;
+ interrupt-names = IRQ_HOTMON_LOW,
IRQ_HOTMON_HIGH;
+ status = disabled;
+};
+
db8500-prcmu-regulators {
compatible =
stericsson,db8500-prcmu-regulator;
@@ -660,5 +668,11 @@
ranges = 0 0x5000 0x400;
status = disabled;
};
+
+ cpufreq-cooling {
+ compatible = stericsson,db8500-cpufreq-cooling;
+ status = disabled;
+};
+
};
};
diff --git a/arch/arm/boot/dts/snowball.dts b/arch/arm/boot/dts/snowball.dts
index 702c0ba..c6f85f0 100644
--- a/arch/arm/boot/dts/snowball.dts
+++ b/arch/arm/boot/dts/snowball.dts
@@ -99,6 +99,33 @@
status = okay;
};
+ prcmu@80157000 {
+ thermal@801573c0 {
+ num-trips = 4;
+
+ trip0-temp = 7;
+ trip0-type = active;
+ trip0-cdev-num = 1;
+ trip0-cdev-name0 = thermal-cpufreq-0;
+
+ trip1-temp = 75000;
+ trip1-type = active;
+ trip1-cdev-num = 1;
+ trip1-cdev-name0 = thermal-cpufreq-0;
+
+ trip2-temp = 8;
+ trip2-type = active;
+ trip2-cdev-num = 1;
+ trip2-cdev-name0 = thermal-cpufreq-0;
+
+ trip3-temp = 85000;
+ trip3-type = critical;
+ trip3-cdev-num = 0;
+
+ status = okay;
+};
+ };
+
external-bus@5000 {
status = okay;
@@ -183,5 +210,9 @@
reg = 0x33;
};
};
+
+ cpufreq-cooling {
+ status = okay;
+ };
};
};
diff --git a/arch/arm/configs/u8500_defconfig b/arch/arm/configs/u8500_defconfig
index da68454..250625d 100644
--- a/arch/arm/configs/u8500_defconfig
+++ b/arch/arm/configs/u8500_defconfig
@@ -69,6 +69,8 @@ CONFIG_GPIO_TC3589X=y
CONFIG_POWER_SUPPLY=y
CONFIG_AB8500_BM=y
CONFIG_AB8500_BATTERY_THERM_ON_BATCTRL=y
+CONFIG_THERMAL=y
+CONFIG_CPU_THERMAL=y
CONFIG_MFD_STMPE=y
CONFIG_MFD_TC3589X=y
CONFIG_AB5500_CORE=y
diff --git a/arch/arm/mach-ux500/board-mop500.c
b/arch/arm/mach-ux500/board-mop500.c
index 416d436..b03216b 100644
--- a/arch/arm/mach-ux500/board-mop500.c
+++ b/arch/arm/mach-ux500/board-mop500.c
@@ -16,6 +16,7 @@
#include linux/io.h
#include linux/i2c.h
#include linux/platform_data/i2c-nomadik.h
+#include linux/platform_data/db8500_thermal.h
#include linux/gpio.h
#include linux/amba/bus.h
#include linux/amba/pl022.h
@@ -229,6 +230,67 @@ static struct ab8500_platform_data ab8500_platdata = {
};
/*
+ * Thermal Sensor
+ */
+
+static struct resource db8500_thsens_resources[] = {
+ {
+ .name = IRQ_HOTMON_LOW,
+ .start = IRQ_PRCMU_HOTMON_LOW,
+ .end= IRQ_PRCMU_HOTMON_LOW,
+ .flags = IORESOURCE_IRQ,
+ },
+ {
+ .name = IRQ_HOTMON_HIGH,
+ .start = IRQ_PRCMU_HOTMON_HIGH,
+ .end= IRQ_PRCMU_HOTMON_HIGH,
+ .flags = IORESOURCE_IRQ,
+ },
+};
+
+static struct db8500_thsens_platform_data db8500_thsens_data = {
+ .trip_points[0] = {
+ .temp = 7,
+ .type = THERMAL_TRIP_ACTIVE,
+ .cdev_name = {
+ [0] = thermal-cpufreq-0,
+
Re: [PATCH] lib/raid6: Add AVX2 optimized recovery functions
Dear Jim, Am Donnerstag, den 08.11.2012, 13:47 -0800 schrieb Jim Kukunas: Optimize RAID6 recovery functions to take advantage of the 256-bit YMM integer instructions introduced in AVX2. in my experiencing optimizations always have to be back up by benchmarks. Could you add those to the commit message please. Signed-off-by: Jim Kukunas james.t.kuku...@linux.intel.com […] Thanks, Paul signature.asc Description: This is a digitally signed message part
[GIT PULL] drbd-8.4.2 for the linux-3.8 merge window
Hi Jens, Please pull drbd-8.4.2 into your for-3.8/drivers branch. The most noticeable change is the support for multiple replicated volumes in a single DRBD connection. This release requires new drbd userland tools = 8.4.0 (available since July 2011). 8.4.x is network protocol compatible with all previous releaes. This release brings a new meta-data format. Forward (8.3 - 8.4) conversion happens complete seamless. Backward conversion is done by a single command (drbdadm apply-al res). The recent changes chapter of our user's guide describes all changes in detail: http://www.drbd.org/users-guide/ap-recent-changes.html Changelog 8.4.2 (api:genl1/proto:86-100) * Go into inconsistent disk state with on-io-error=pass-on policy * Timeouts for requests processing on the peer (previously that worked only if the data socket was congested) * Conflicting write detection is now based on an interval tree, removed the hash-tables (necessary for the unlimited BIO sizes) * Support for multiple volumes (minors, block devices) per connection; up to 65536 volumes per connection supported * Reduced IO latencies during some state changes (esp. start resync) * New on disk format for the AL: double capacity; 4k aligned IO; same space * Multiple AL changes in a single transaction (precondition for unlimited BIO sizes) * DRBD no longer imposes any limit on BIO sizes * Removed DRBD's limits on the number of minor devices * DRBD's minors can now be removed (not only unconfigured) * Switched the user space interface form connector to generic netlink * The wire-protocol is now a regular connection option, which can be changed while the device is online * IO freezing/thawing is done on connection (all volumes) level * fencing is done on connection (all volumes) level * Enforce application of activity log after primary crash in user space * New default values (compared to drbd-8.3) for: minor-count, ko-count, al-extents, c-plan-ahead, c-fill-target, c-min-rate, use-rle, on-io-error * Optional load balancing for read requests: new keyword read-balance * New option 'al-updates no' to disable writing transactions into the activity log. It is use full if you prefer a full sync after a primary crash, for improved performance of a spread out random write work load * Expose the data generation identifies via sysfs Jens, regarding the code: It has the sysfs bits in again. The reason for that is that we want to expose more information by that, and remove the /proc/drbd with the next evolutionary step. -- In case this is a show stopper, let me remove the sysfs bits. Here is the git-pull-request test: (The patch subjects removed to make the mail more digestible) The following changes since commit ccae7868b0c5697508a541c531cf96b361d62c1c: drbd: log request sector offset and size for IO errors (2012-10-30 08:39:18 +0100) are available in the git repository at: git://git.drbd.org/linux-drbd.git for-jens_drbd-8.4.2 for you to fetch changes up to e877f7fdc0b1052b0e881e61f9290268eb21aa2f: drbd: use copy_highpage (2012-11-09 12:06:44 +0100) Akinobu Mita (1): drbd: use copy_highpage Andreas Gruenbacher (210): drbd: Get rid of req_validator_fn typedef [...] David Howells (1): DRBD: Fix comparison always false warning due to long/long long compare Jing Wang (1): drbd: check return of kmalloc in receive_uuids Lars Ellenberg (138): drbd: simplify condition in drbd_may_do_local_read() [...] Philipp Marek (1): drbd: pass some more information to userspace. Philipp Reisner (234): idr: idr_for_each_entry() macro [...] drivers/block/drbd/Makefile|2 + drivers/block/drbd/drbd_actlog.c | 689 +++ drivers/block/drbd/drbd_bitmap.c | 227 ++- drivers/block/drbd/drbd_int.h | 1399 ++--- drivers/block/drbd/drbd_interval.c | 207 ++ drivers/block/drbd/drbd_interval.h | 40 + drivers/block/drbd/drbd_main.c | 3918 ++-- drivers/block/drbd/drbd_nl.c | 3391 ++- drivers/block/drbd/drbd_nla.c | 55 + drivers/block/drbd/drbd_nla.h |8 + drivers/block/drbd/drbd_proc.c | 33 +- drivers/block/drbd/drbd_receiver.c | 3883 --- drivers/block/drbd/drbd_req.c | 1569 +++ drivers/block/drbd/drbd_req.h | 187 +- drivers/block/drbd/drbd_state.c| 1857 + drivers/block/drbd/drbd_state.h| 161 ++ drivers/block/drbd/drbd_strings.c |1 + drivers/block/drbd/drbd_sysfs.c| 86 + drivers/block/drbd/drbd_worker.c | 1168 ++- drivers/block/drbd/drbd_wrappers.h | 11 +- include/linux/drbd.h | 81 +- include/linux/drbd_genl.h | 378 include/linux/drbd_genl_api.h | 55 + include/linux/drbd_limits.h| 90 +-
Re: [PATCH V5 0/2] Upstream ST-Ericsson thermal driver
Hi Rui Zhang, Please have a look at this patch set. Since the previous 1/5, 2/5, 3/5 have been accepted, I'd like to send these last two updated patches with Reviewed-by added in this new thread. Thanks. On 9 November 2012 19:29, hongbo.zhang hongbo.zh...@linaro.org wrote: From: hongbo.zhang hongbo.zh...@linaro.com V4-V5 Changes: In patch Thermal: Add ST-Ericsson DB8500 thermal driver: - use flush_work instead of flush_work_sync since the later is deprecated now. - parameter trip_points of db8500_thermal_match_cdev is renamed to trip_point; - re-order oprerations in function db8500_thermal_update_config; hongbo.zhang (2): Thermal: Add ST-Ericsson DB8500 thermal driver. Thermal: Add ST-Ericsson DB8500 thermal properties and platform data. .../devicetree/bindings/thermal/db8500-thermal.txt | 44 ++ arch/arm/boot/dts/dbx5x0.dtsi | 14 + arch/arm/boot/dts/snowball.dts | 31 ++ arch/arm/configs/u8500_defconfig | 2 + arch/arm/mach-ux500/board-mop500.c | 64 +++ drivers/thermal/Kconfig| 20 + drivers/thermal/Makefile | 2 + drivers/thermal/db8500_cpufreq_cooling.c | 108 + drivers/thermal/db8500_thermal.c | 531 + include/linux/platform_data/db8500_thermal.h | 38 ++ 10 files changed, 854 insertions(+) create mode 100644 Documentation/devicetree/bindings/thermal/db8500-thermal.txt create mode 100644 drivers/thermal/db8500_cpufreq_cooling.c create mode 100644 drivers/thermal/db8500_thermal.c create mode 100644 include/linux/platform_data/db8500_thermal.h -- 1.7.11.3 -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] lib/raid6: Add AVX2 optimized recovery functions
Sorry, we cannot share those at this time since the hardwarenis not yet released. Paul Menzel pm.deb...@googlemail.com wrote: Dear Jim, Am Donnerstag, den 08.11.2012, 13:47 -0800 schrieb Jim Kukunas: Optimize RAID6 recovery functions to take advantage of the 256-bit YMM integer instructions introduced in AVX2. in my experiencing optimizations always have to be back up by benchmarks. Could you add those to the commit message please. Signed-off-by: Jim Kukunas james.t.kuku...@linux.intel.com […] Thanks, Paul -- Sent from my mobile phone. Please excuse brevity and lack of formatting. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [GIT PULL] drbd-8.4.2 for the linux-3.8 merge window
On 2012-11-09 12:36, Philipp Reisner wrote: Hi Jens, Please pull drbd-8.4.2 into your for-3.8/drivers branch. The most noticeable change is the support for multiple replicated volumes in a single DRBD connection. This release requires new drbd userland tools = 8.4.0 (available since July 2011). 8.4.x is network protocol compatible with all previous releaes. This release brings a new meta-data format. Forward (8.3 - 8.4) conversion happens complete seamless. Backward conversion is done by a single command (drbdadm apply-al res). The recent changes chapter of our user's guide describes all changes in detail: http://www.drbd.org/users-guide/ap-recent-changes.html Changelog 8.4.2 (api:genl1/proto:86-100) * Go into inconsistent disk state with on-io-error=pass-on policy * Timeouts for requests processing on the peer (previously that worked only if the data socket was congested) * Conflicting write detection is now based on an interval tree, removed the hash-tables (necessary for the unlimited BIO sizes) * Support for multiple volumes (minors, block devices) per connection; up to 65536 volumes per connection supported * Reduced IO latencies during some state changes (esp. start resync) * New on disk format for the AL: double capacity; 4k aligned IO; same space * Multiple AL changes in a single transaction (precondition for unlimited BIO sizes) * DRBD no longer imposes any limit on BIO sizes * Removed DRBD's limits on the number of minor devices * DRBD's minors can now be removed (not only unconfigured) * Switched the user space interface form connector to generic netlink * The wire-protocol is now a regular connection option, which can be changed while the device is online * IO freezing/thawing is done on connection (all volumes) level * fencing is done on connection (all volumes) level * Enforce application of activity log after primary crash in user space * New default values (compared to drbd-8.3) for: minor-count, ko-count, al-extents, c-plan-ahead, c-fill-target, c-min-rate, use-rle, on-io-error * Optional load balancing for read requests: new keyword read-balance * New option 'al-updates no' to disable writing transactions into the activity log. It is use full if you prefer a full sync after a primary crash, for improved performance of a spread out random write work load * Expose the data generation identifies via sysfs Jens, regarding the code: It has the sysfs bits in again. The reason for that is that we want to expose more information by that, and remove the /proc/drbd with the next evolutionary step. -- In case this is a show stopper, let me remove the sysfs bits. The exact same sysfs bits I complained about last time? If yes, then I don't understand why you haven't changed yet. Or why you are trying to push the same bits again that got rejected last time. Here is the git-pull-request test: (The patch subjects removed to make the mail more digestible) Please don't do that, it basically makes the pull request useless! A few hundred extra lines is not an issue. -- Jens Axboe -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] mfd: max8925: update dt regulator binding doc
On Thu, Nov 08, 2012 at 10:31:32AM +0800, Qing Xu wrote: remove linux specific references, enumerates all supported regulators Applied. As I said the other day please do use subject lines appropriate for the subsystem. signature.asc Description: Digital signature
[PATCH 0/8] Fix coding style in sdhci.c
Documents/CodingStyle Chapter 3 recommends usage of braces for both if and else statements if any of the branches contains multiple statements. Cleaning up drivers/mmc/host/sdhci.c for all these occurrences. Tushar Behera (8): mmc: sdhci: fix coding style in sdhci_calc_timeout mmc: sdhci: fix coding style in sdhci_set_transfer_mode mmc: sdhci: fix coding style in sdhci_finish_data mmc: sdhci: fix coding style in sdhci_set_clock mmc: sdhci: fix coding style in sdhci_do_set_ios mmc: sdhci: fix coding style in sdhci_execute_tuning mmc: sdhci: fix coding style in sdhci_data_irq mmc: sdhci: fix coding style in sdhci_add_host drivers/mmc/host/sdhci.c | 58 + 1 files changed, 32 insertions(+), 26 deletions(-) -- 1.7.4.1 -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 1/8] mmc: sdhci: fix coding style in sdhci_calc_timeout
Signed-off-by: Tushar Behera tushar.beh...@linaro.org
---
drivers/mmc/host/sdhci.c |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/mmc/host/sdhci.c b/drivers/mmc/host/sdhci.c
index c7851c0..2ff2b9e 100644
--- a/drivers/mmc/host/sdhci.c
+++ b/drivers/mmc/host/sdhci.c
@@ -667,9 +667,9 @@ static u8 sdhci_calc_timeout(struct sdhci_host *host,
struct mmc_command *cmd)
return 0xE;
/* timeout in us */
- if (!data)
+ if (!data) {
target_timeout = cmd-cmd_timeout_ms * 1000;
- else {
+ } else {
target_timeout = data-timeout_ns / 1000;
if (host-clock)
target_timeout += data-timeout_clks / host-clock;
--
1.7.4.1
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 3/8] mmc: sdhci: fix coding style in sdhci_finish_data
Signed-off-by: Tushar Behera tushar.beh...@linaro.org
---
drivers/mmc/host/sdhci.c |7 ---
1 files changed, 4 insertions(+), 3 deletions(-)
diff --git a/drivers/mmc/host/sdhci.c b/drivers/mmc/host/sdhci.c
index 2d3d76e..73bb41f 100644
--- a/drivers/mmc/host/sdhci.c
+++ b/drivers/mmc/host/sdhci.c
@@ -924,9 +924,9 @@ static void sdhci_finish_data(struct sdhci_host *host)
host-data = NULL;
if (host-flags SDHCI_REQ_USE_DMA) {
- if (host-flags SDHCI_USE_ADMA)
+ if (host-flags SDHCI_USE_ADMA) {
sdhci_adma_table_post(host, data);
- else {
+ } else {
dma_unmap_sg(mmc_dev(host-mmc), data-sg,
data-sg_len, (data-flags MMC_DATA_READ) ?
DMA_FROM_DEVICE : DMA_TO_DEVICE);
@@ -964,8 +964,9 @@ static void sdhci_finish_data(struct sdhci_host *host)
}
sdhci_send_command(host, data-stop);
- } else
+ } else {
tasklet_schedule(host-finish_tasklet);
+ }
}
static void sdhci_send_command(struct sdhci_host *host, struct mmc_command
*cmd)
--
1.7.4.1
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 5/8] mmc: sdhci: fix coding style in sdhci_do_set_ios
Signed-off-by: Tushar Behera tushar.beh...@linaro.org
---
drivers/mmc/host/sdhci.c | 11 ++-
1 files changed, 6 insertions(+), 5 deletions(-)
diff --git a/drivers/mmc/host/sdhci.c b/drivers/mmc/host/sdhci.c
index 28da461..b947155 100644
--- a/drivers/mmc/host/sdhci.c
+++ b/drivers/mmc/host/sdhci.c
@@ -1386,9 +1386,9 @@ static void sdhci_do_set_ios(struct sdhci_host *host,
struct mmc_ios *ios)
* or if it requires special setup code, you should implement that in
* platform_8bit_width().
*/
- if (host-ops-platform_8bit_width)
+ if (host-ops-platform_8bit_width) {
host-ops-platform_8bit_width(host, ios-bus_width);
- else {
+ } else {
ctrl = sdhci_readb(host, SDHCI_HOST_CONTROL);
if (ios-bus_width == MMC_BUS_WIDTH_8) {
ctrl = ~SDHCI_CTRL_4BITBUS;
@@ -1467,9 +1467,9 @@ static void sdhci_do_set_ios(struct sdhci_host *host,
struct mmc_ios *ios)
clk = ~SDHCI_CLOCK_CARD_EN;
sdhci_writew(host, clk, SDHCI_CLOCK_CONTROL);
- if (host-ops-set_uhs_signaling)
+ if (host-ops-set_uhs_signaling) {
host-ops-set_uhs_signaling(host, ios-timing);
- else {
+ } else {
ctrl_2 = sdhci_readw(host, SDHCI_HOST_CONTROL2);
/* Select Bus Speed Mode for host */
ctrl_2 = ~SDHCI_CTRL_UHS_MASK;
@@ -1492,8 +1492,9 @@ static void sdhci_do_set_ios(struct sdhci_host *host,
struct mmc_ios *ios)
clock = host-clock;
host-clock = 0;
sdhci_set_clock(host, clock);
- } else
+ } else {
sdhci_writeb(host, ctrl, SDHCI_HOST_CONTROL);
+ }
/*
* Some (ENE) controllers go apeshit on some ios operation,
--
1.7.4.1
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 6/8] mmc: sdhci: fix coding style in sdhci_execute_tuning
Signed-off-by: Tushar Behera tushar.beh...@linaro.org
---
drivers/mmc/host/sdhci.c |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/mmc/host/sdhci.c b/drivers/mmc/host/sdhci.c
index b947155..4bed582 100644
--- a/drivers/mmc/host/sdhci.c
+++ b/drivers/mmc/host/sdhci.c
@@ -1792,9 +1792,9 @@ static int sdhci_execute_tuning(struct mmc_host *mmc, u32
opcode)
requires_tuning_nonuhs = true;
if (((ctrl SDHCI_CTRL_UHS_MASK) == SDHCI_CTRL_UHS_SDR104) ||
- requires_tuning_nonuhs)
+ requires_tuning_nonuhs) {
ctrl |= SDHCI_CTRL_EXEC_TUNING;
- else {
+ } else {
spin_unlock(host-lock);
enable_irq(host-irq);
sdhci_runtime_pm_put(host);
--
1.7.4.1
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 7/8] mmc: sdhci: fix coding style in sdhci_data_irq
Signed-off-by: Tushar Behera tushar.beh...@linaro.org
---
drivers/mmc/host/sdhci.c |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/mmc/host/sdhci.c b/drivers/mmc/host/sdhci.c
index 4bed582..47cac71 100644
--- a/drivers/mmc/host/sdhci.c
+++ b/drivers/mmc/host/sdhci.c
@@ -2286,9 +2286,9 @@ static void sdhci_data_irq(struct sdhci_host *host, u32
intmask)
host-data-error = -EIO;
}
- if (host-data-error)
+ if (host-data-error) {
sdhci_finish_data(host);
- else {
+ } else {
if (intmask (SDHCI_INT_DATA_AVAIL | SDHCI_INT_SPACE_AVAIL))
sdhci_transfer_pio(host);
--
1.7.4.1
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 8/8] mmc: sdhci: fix coding style in sdhci_add_host
Signed-off-by: Tushar Behera tushar.beh...@linaro.org
---
drivers/mmc/host/sdhci.c | 20
1 files changed, 12 insertions(+), 8 deletions(-)
diff --git a/drivers/mmc/host/sdhci.c b/drivers/mmc/host/sdhci.c
index 47cac71..5cddb74 100644
--- a/drivers/mmc/host/sdhci.c
+++ b/drivers/mmc/host/sdhci.c
@@ -2786,16 +2786,18 @@ int sdhci_add_host(struct sdhci_host *host)
*/
mmc-ops = sdhci_ops;
mmc-f_max = host-max_clk;
- if (host-ops-get_min_clock)
+ if (host-ops-get_min_clock) {
mmc-f_min = host-ops-get_min_clock(host);
- else if (host-version = SDHCI_SPEC_300) {
+ } else if (host-version = SDHCI_SPEC_300) {
if (host-clk_mul) {
mmc-f_min = (host-max_clk * host-clk_mul) / 1024;
mmc-f_max = host-max_clk * host-clk_mul;
- } else
+ } else {
mmc-f_min = host-max_clk / SDHCI_MAX_DIV_SPEC_300;
- } else
+ }
+ } else {
mmc-f_min = host-max_clk / SDHCI_MAX_DIV_SPEC_200;
+ }
host-timeout_clk =
(caps[0] SDHCI_TIMEOUT_CLK_MASK) SDHCI_TIMEOUT_CLK_SHIFT;
@@ -2860,12 +2862,13 @@ int sdhci_add_host(struct sdhci_host *host)
mmc_hostname(mmc));
host-vqmmc = NULL;
}
- }
- else if (regulator_is_supported_voltage(host-vqmmc, 180, 180))
+ } else if (regulator_is_supported_voltage(host-vqmmc,
+ 180, 180)) {
regulator_enable(host-vqmmc);
- else
+ } else {
caps[1] = ~(SDHCI_SUPPORT_SDR104 | SDHCI_SUPPORT_SDR50 |
SDHCI_SUPPORT_DDR50);
+ }
/* Any UHS-I mode in caps implies SDR12 and SDR25 support. */
if (caps[1] (SDHCI_SUPPORT_SDR104 | SDHCI_SUPPORT_SDR50 |
@@ -2921,8 +2924,9 @@ int sdhci_add_host(struct sdhci_host *host)
mmc_hostname(mmc));
host-vmmc = NULL;
}
- } else
+ } else {
regulator_enable(host-vmmc);
+ }
#ifdef CONFIG_REGULATOR
if (host-vmmc) {
--
1.7.4.1
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] lib/raid6: Add AVX2 optimized recovery functions
Am Freitag, den 09.11.2012, 12:39 +0100 schrieb H. Peter Anvin: Sorry, we cannot share those at this time since the hardwarenis not yet released. Too bad. Then I suggest an additional run time switch to enable and disable that code path. So people later can easily test themselves. Thanks, Paul signature.asc Description: This is a digitally signed message part
[PATCH 4/8] mmc: sdhci: fix coding style in sdhci_set_clock
Signed-off-by: Tushar Behera tushar.beh...@linaro.org
---
drivers/mmc/host/sdhci.c |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/mmc/host/sdhci.c b/drivers/mmc/host/sdhci.c
index 73bb41f..28da461 100644
--- a/drivers/mmc/host/sdhci.c
+++ b/drivers/mmc/host/sdhci.c
@@ -1138,9 +1138,9 @@ static void sdhci_set_clock(struct sdhci_host *host,
unsigned int clock)
}
} else {
/* Version 3.00 divisors must be a multiple of 2. */
- if (host-max_clk = clock)
+ if (host-max_clk = clock) {
div = 1;
- else {
+ } else {
for (div = 2; div SDHCI_MAX_DIV_SPEC_300;
div += 2) {
if ((host-max_clk / div) = clock)
--
1.7.4.1
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 2/8] mmc: sdhci: fix coding style in sdhci_set_transfer_mode
Signed-off-by: Tushar Behera tushar.beh...@linaro.org
---
drivers/mmc/host/sdhci.c |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/mmc/host/sdhci.c b/drivers/mmc/host/sdhci.c
index 2ff2b9e..2d3d76e 100644
--- a/drivers/mmc/host/sdhci.c
+++ b/drivers/mmc/host/sdhci.c
@@ -898,9 +898,9 @@ static void sdhci_set_transfer_mode(struct sdhci_host *host,
* If we are sending CMD23, CMD12 never gets sent
* on successful completion (so no Auto-CMD12).
*/
- if (!host-mrq-sbc (host-flags SDHCI_AUTO_CMD12))
+ if (!host-mrq-sbc (host-flags SDHCI_AUTO_CMD12)) {
mode |= SDHCI_TRNS_AUTO_CMD12;
- else if (host-mrq-sbc (host-flags SDHCI_AUTO_CMD23)) {
+ } else if (host-mrq-sbc (host-flags SDHCI_AUTO_CMD23)) {
mode |= SDHCI_TRNS_AUTO_CMD23;
sdhci_writel(host, host-mrq-sbc-arg,
SDHCI_ARGUMENT2);
}
--
1.7.4.1
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 1/1] ARM: mm: Remove unused variable in mmap.c
Variable 'start_addr' is not used and hence can be removed.
Silences the following compilation warning:
arch/arm/mm/mmap.c: In function ‘arch_get_unmapped_area’:
arch/arm/mm/mmap.c:60:16: warning:
unused variable ‘start_addr’ [-Wunused-variable]
Signed-off-by: Sachin Kamat sachin.ka...@linaro.org
---
This patch is based linux-next tree of 20121109
---
arch/arm/mm/mmap.c |1 -
1 files changed, 0 insertions(+), 1 deletions(-)
diff --git a/arch/arm/mm/mmap.c b/arch/arm/mm/mmap.c
index f4fec6d..10062ce 100644
--- a/arch/arm/mm/mmap.c
+++ b/arch/arm/mm/mmap.c
@@ -57,7 +57,6 @@ arch_get_unmapped_area(struct file *filp, unsigned long addr,
{
struct mm_struct *mm = current-mm;
struct vm_area_struct *vma;
- unsigned long start_addr;
int do_align = 0;
int aliasing = cache_is_vipt_aliasing();
struct vm_unmapped_area_info info;
--
1.7.4.1
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [RESEND PATCH 1/2] ASoC: Ux500: Fixup use of clocks
On Wed, Nov 07, 2012 at 04:42:41PM +0100, Ulf Hansson wrote: From: Ulf Hansson ulf.hans...@linaro.org Make sure clocks are being prepared and unprepared as well as enabled and disabled. Both of these patches are already applied... signature.asc Description: Digital signature
Re: [PATCH] lib/raid6: Add AVX2 optimized recovery functions
On Fri, 09 Nov 2012 12:39:05 +0100 H. Peter Anvin h...@zytor.com wrote: Sorry, we cannot share those at this time since the hardwarenis not yet released. Can I take that to imply Acked-by: H. Peter Anvin h...@zytor.com ?? It would be nice to have at least a statement like: These patches have been tested both with the user-space testing tool and in a RAID6 md array and the pass all test. While we cannot release performance numbers as the hardwere is not released, we can confirm that on that hardware the performance with these patches is faster than without. I guess I should be able to assume that - surely the patches would not be posted if it were not true... But I like to avoid assuming when I can. Thanks, NeilBrown Paul Menzel pm.deb...@googlemail.com wrote: Dear Jim, Am Donnerstag, den 08.11.2012, 13:47 -0800 schrieb Jim Kukunas: Optimize RAID6 recovery functions to take advantage of the 256-bit YMM integer instructions introduced in AVX2. in my experiencing optimizations always have to be back up by benchmarks. Could you add those to the commit message please. Signed-off-by: Jim Kukunas james.t.kuku...@linux.intel.com […] Thanks, Paul signature.asc Description: PGP signature
[PATCH] pwm: spear: Staticize spear_pwm_config()
spear_pwm_config() is not referenced outside of this file, make it static.
Signed-off-by: Axel Lin axel@ingics.com
---
drivers/pwm/pwm-spear.c |4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/pwm/pwm-spear.c b/drivers/pwm/pwm-spear.c
index 6a8fd9b..83b21d9 100644
--- a/drivers/pwm/pwm-spear.c
+++ b/drivers/pwm/pwm-spear.c
@@ -76,8 +76,8 @@ static inline void spear_pwm_writel(struct spear_pwm_chip
*chip,
writel_relaxed(val, chip-mmio_base + (num 4) + offset);
}
-int spear_pwm_config(struct pwm_chip *chip, struct pwm_device *pwm, int
duty_ns,
-int period_ns)
+static int spear_pwm_config(struct pwm_chip *chip, struct pwm_device *pwm,
+ int duty_ns, int period_ns)
{
struct spear_pwm_chip *pc = to_spear_pwm_chip(chip);
u64 val, div, clk_rate;
--
1.7.9.5
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] pwm: spear: Staticize spear_pwm_config()
On 9 November 2012 17:22, Axel Lin axel@ingics.com wrote: spear_pwm_config() is not referenced outside of this file, make it static. Signed-off-by: Axel Lin axel@ingics.com Acked-by: Viresh Kumar viresh.ku...@linaro.org -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH V3 3/5] Thermal: Remove the cooling_cpufreq_list.
On 7 November 2012 14:54, Zhang Rui rui.zh...@intel.com wrote:
On Tue, 2012-10-30 at 17:48 +0100, hongbo.zhang wrote:
From: hongbo.zhang hongbo.zh...@linaro.com
Problem of using this list is that the cpufreq_get_max_state callback will be
called when register cooling device by thermal_cooling_device_register, but
this list isn't ready at this moment. What's more, there is no need to
maintain
such a list, we can get cpufreq_cooling_device instance by the private
thermal_cooling_device.devdata.
Signed-off-by: hongbo.zhang hongbo.zh...@linaro.com
Reviewed-by: Francesco Lavra francescolavra...@gmail.com
Reviewed-by: Amit Daniel Kachhap amit.kach...@linaro.org
applied to thermal-next.
Thanks.
I have sent the other updated 4/5 5/5 patches with Reviewed-by added
in a new thread, please have a look there.
thanks,
rui
---
drivers/thermal/cpu_cooling.c | 91
+--
1 file changed, 19 insertions(+), 72 deletions(-)
diff --git a/drivers/thermal/cpu_cooling.c b/drivers/thermal/cpu_cooling.c
index bfd62b7..392d57d 100644
--- a/drivers/thermal/cpu_cooling.c
+++ b/drivers/thermal/cpu_cooling.c
@@ -58,8 +58,9 @@ struct cpufreq_cooling_device {
};
static LIST_HEAD(cooling_cpufreq_list);
static DEFINE_IDR(cpufreq_idr);
+static DEFINE_MUTEX(cooling_cpufreq_lock);
-static struct mutex cooling_cpufreq_lock;
+static unsigned int cpufreq_dev_count;
/* notify_table passes value to the CPUFREQ_ADJUST callback function. */
#define NOTIFY_INVALID NULL
@@ -240,28 +241,18 @@ static int cpufreq_thermal_notifier(struct
notifier_block *nb,
static int cpufreq_get_max_state(struct thermal_cooling_device *cdev,
unsigned long *state)
{
- int ret = -EINVAL, i = 0;
- struct cpufreq_cooling_device *cpufreq_device;
- struct cpumask *maskPtr;
+ struct cpufreq_cooling_device *cpufreq_device = cdev-devdata;
+ struct cpumask *maskPtr = cpufreq_device-allowed_cpus;
unsigned int cpu;
struct cpufreq_frequency_table *table;
unsigned long count = 0;
+ int i = 0;
- mutex_lock(cooling_cpufreq_lock);
- list_for_each_entry(cpufreq_device, cooling_cpufreq_list, node) {
- if (cpufreq_device cpufreq_device-cool_dev == cdev)
- break;
- }
- if (cpufreq_device == NULL)
- goto return_get_max_state;
-
- maskPtr = cpufreq_device-allowed_cpus;
cpu = cpumask_any(maskPtr);
table = cpufreq_frequency_get_table(cpu);
if (!table) {
*state = 0;
- ret = 0;
- goto return_get_max_state;
+ return 0;
}
for (i = 0; (table[i].frequency != CPUFREQ_TABLE_END); i++) {
@@ -272,12 +263,10 @@ static int cpufreq_get_max_state(struct
thermal_cooling_device *cdev,
if (count 0) {
*state = --count;
- ret = 0;
+ return 0;
}
-return_get_max_state:
- mutex_unlock(cooling_cpufreq_lock);
- return ret;
+ return -EINVAL;
}
/**
@@ -288,20 +277,10 @@ return_get_max_state:
static int cpufreq_get_cur_state(struct thermal_cooling_device *cdev,
unsigned long *state)
{
- int ret = -EINVAL;
- struct cpufreq_cooling_device *cpufreq_device;
+ struct cpufreq_cooling_device *cpufreq_device = cdev-devdata;
- mutex_lock(cooling_cpufreq_lock);
- list_for_each_entry(cpufreq_device, cooling_cpufreq_list, node) {
- if (cpufreq_device cpufreq_device-cool_dev == cdev) {
- *state = cpufreq_device-cpufreq_state;
- ret = 0;
- break;
- }
- }
- mutex_unlock(cooling_cpufreq_lock);
-
- return ret;
+ *state = cpufreq_device-cpufreq_state;
+ return 0;
}
/**
@@ -312,22 +291,9 @@ static int cpufreq_get_cur_state(struct
thermal_cooling_device *cdev,
static int cpufreq_set_cur_state(struct thermal_cooling_device *cdev,
unsigned long state)
{
- int ret = -EINVAL;
- struct cpufreq_cooling_device *cpufreq_device;
+ struct cpufreq_cooling_device *cpufreq_device = cdev-devdata;
- mutex_lock(cooling_cpufreq_lock);
- list_for_each_entry(cpufreq_device, cooling_cpufreq_list, node) {
- if (cpufreq_device cpufreq_device-cool_dev == cdev) {
- ret = 0;
- break;
- }
- }
- if (!ret)
- ret = cpufreq_apply_cooling(cpufreq_device, state);
-
- mutex_unlock(cooling_cpufreq_lock);
-
- return ret;
+ return cpufreq_apply_cooling(cpufreq_device, state);
}
/* Bind cpufreq callbacks to thermal cooling device ops */
@@ -351,14 +317,11 @@ struct thermal_cooling_device
*cpufreq_cooling_register(
{
struct thermal_cooling_device *cool_dev;
struct cpufreq_cooling_device
[PATCH v3] mfd: lpc_ich: Fix resource request for [mem 0x00000000]
The older southbridges supported by the lpc_ich driver do not
provide memory-mapped space of the root complex. The driver
correctly avoids computing the iomem address in this case, yet
submits a zeroed resource request anyway (via mfd_add_devices()).
Remove the iomem resource from the resource array submitted to the
mfd core for the older southbridges.
Acked-by: Aaron Sierra asie...@xes-inc.com
Cc: Peter Tyser pty...@xes-inc.com
Cc: Samuel Ortiz sa...@linux.intel.com
Signed-off-by: Peter Hurley pe...@hurleysoftware.com
---
v2: post-decrement to match existing style
retitle patch subject
v3: respin as standalone patch
drivers/mfd/lpc_ich.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/mfd/lpc_ich.c b/drivers/mfd/lpc_ich.c
index a22544f..f507c09 100644
--- a/drivers/mfd/lpc_ich.c
+++ b/drivers/mfd/lpc_ich.c
@@ -842,6 +842,9 @@ static int __devinit lpc_ich_init_wdt(struct pci_dev *dev,
res = wdt_mem_res(ICH_RES_MEM_GCS);
res-start = base_addr + ACPIBASE_GCS_OFF;
res-end = base_addr + ACPIBASE_GCS_END;
+ } else {
+ /* So don't register iomem for TCO ver 1 */
+ lpc_ich_cells[LPC_WDT].num_resources--;
}
lpc_ich_finalize_cell(lpc_ich_cells[LPC_WDT], id);
--
1.8.0
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2/4] arch/arm: move secure_computing into trace
One really minor nit...
On Thu, Nov 08, 2012 at 08:59:31PM +, Kees Cook wrote:
There is very little difference in the TIF_SECCOMP and TIF_SYSCALL_WORK
path in entry-common.S, so merge TIF_SECCOMP into TIF_SYSCALL_WORK and
move seccomp into the syscall_trace_enter() handler.
Expanded some of the tracehook logic into the callers to make this code
more readable. Since tracehook needs to do register changing, this portion
is best left in its own function instead of copy/pasting into the callers.
Additionally, the return value for secure_computing() is now checked
and a -1 value will result in the system call being skipped.
Signed-off-by: Kees Cook keesc...@chromium.org
[...]
@@ -944,19 +939,39 @@ static int ptrace_syscall_trace(struct pt_regs *regs,
int scno,
asmlinkage int syscall_trace_enter(struct pt_regs *regs, int scno)
{
- scno = ptrace_syscall_trace(regs, scno, PTRACE_SYSCALL_ENTER);
+ current_thread_info()-syscall = scno;
+
+ /* do the secure computing check first */
+ if (secure_computing(scno) == -1) {
+ /* seccomp failures shouldn't expose any additional code. */
+ scno = -1;
+ goto out;
+ }
Can we just return -1 here instead please? The whole jump label code makes
this code messier than it needs to be and there's no cleanup to be done.
+ if (test_thread_flag(TIF_SYSCALL_TRACE))
+ scno = tracehook_report_syscall(regs, PTRACE_SYSCALL_ENTER);
+
if (test_thread_flag(TIF_SYSCALL_TRACEPOINT))
trace_sys_enter(regs, scno);
+
audit_syscall_entry(AUDIT_ARCH_ARM, scno, regs-ARM_r0, regs-ARM_r1,
regs-ARM_r2, regs-ARM_r3);
+
+out:
return scno;
}
Cheers,
Will
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] pwm: spear: Staticize spear_pwm_config()
On Fri, Nov 09, 2012 at 07:52:22PM +0800, Axel Lin wrote:
spear_pwm_config() is not referenced outside of this file, make it static.
Signed-off-by: Axel Lin axel@ingics.com
---
drivers/pwm/pwm-spear.c |4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/pwm/pwm-spear.c b/drivers/pwm/pwm-spear.c
index 6a8fd9b..83b21d9 100644
--- a/drivers/pwm/pwm-spear.c
+++ b/drivers/pwm/pwm-spear.c
@@ -76,8 +76,8 @@ static inline void spear_pwm_writel(struct spear_pwm_chip
*chip,
writel_relaxed(val, chip-mmio_base + (num 4) + offset);
}
-int spear_pwm_config(struct pwm_chip *chip, struct pwm_device *pwm, int
duty_ns,
- int period_ns)
+static int spear_pwm_config(struct pwm_chip *chip, struct pwm_device *pwm,
+ int duty_ns, int period_ns)
{
struct spear_pwm_chip *pc = to_spear_pwm_chip(chip);
u64 val, div, clk_rate;
Applied, thanks.
Thierry
pgp7anAV7dzOr.pgp
Description: PGP signature
Re: [PATCH] pwm: spear: Staticize spear_pwm_config()
On 9 November 2012 17:28, Thierry Reding thierry.red...@avionic-design.de wrote: Applied, thanks. Aah.. That's pretty fast :) within 5 minutes of posting the patch you got ACK and got applied too :) -- viresh -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] usb: gadget: ncm: correct endianess conversion
Hi, On Fri, Nov 09, 2012 at 10:31:47AM +0100, Dmytro Milinevskyy wrote: Hi Felipe, On Thu, Nov 8, 2012 at 8:30 PM, Felipe Balbi ba...@ti.com wrote: Hi, On Thu, Nov 08, 2012 at 08:07:57PM +0100, Dmytro Milinevskyy wrote: On Wed, Nov 07, 2012 at 02:14:00PM +0100, Dmytro Milinevskyy wrote: Unfortunately I have some issues with git send-email. I've attached the patch itself .. I'll apply it like that this time, but try to figure out how to send patches properly. We have some very helpful hints on Documentation/email-clients.txt which are hugely underused ;-) well, I try to follow the rules as much as possible as long as tools work ... =) git send-email has thousands of users and it works fine for them (including myself). Maybe you just misconfigured it ?!? ;-) No, I was using it in the past w/o any issue. In fact initial versions of the patch were sent exactly with git-send-email. However I lost my internet connection at home(some issues with ISP) and at work place network environment somehow blocks git-send-email(though thunderbird still can connect to the smtp server ..). I don't think smtp server can make that distinction. Except for the message-id, there's nothing there which would help smtp server to figure out you're using git send-email. On top of that, it would be just extra work to maintain rules to block a tool which is essentially just sending an email. Make sure you're not missing some authentication with the mail server on your git send-email configuration. my 2 cents. -- balbi signature.asc Description: Digital signature
Re: [RFC] Device Tree Overlays Proposal (Was Re: capebus moving omap_devices to mach-omap2)
On Mon, Nov 5, 2012 at 11:22 PM, Tony Lindgren t...@atomide.com wrote: Hi, * Tabi Timur-B04825 b04...@freescale.com [121105 13:42]: On Mon, Nov 5, 2012 at 2:40 PM, Grant Likely grant.lik...@secretlab.ca wrote: Jane is building custom BeagleBone expansion boards called 'capes'. She can boot the system with a stock BeagleBoard device tree, but additional data is needed before a cape can be used. She could replace the FDT file used by U-Boot with one that contains the extra data, but she uses the same Linux system image regardless of the cape, and it is inconvenient to have to select a different device tree at boot time depending on the cape. What's wrong with having the boot loader detect the presence of the Cape and update the device tree accordingly? We do this all the time in U-Boot. Doing stuff like reading EEPROMs and testing for the presence of hardware is easier in U-Boot than in Linux. For configurations that can be determined by the boot loader, I'm not sure overlays are practical. I guess the beaglebone capes could be stackable and hotpluggable if handled carefully enough. And even if it can't on the beaglebone, it will happen somewhere else. I don't want to exclude that use-case just because nobody thought about it. g. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH V3] memcg, oom: provide more precise dump info while memcg oom happening
On 11/09/2012 06:50 PM, Michal Hocko wrote:
On Fri 09-11-12 18:23:07, Sha Zhengju wrote:
On 11/09/2012 12:25 AM, Michal Hocko wrote:
On Thu 08-11-12 23:52:47, Sha Zhengju wrote:
[...]
+ for (i = 0; i MEM_CGROUP_STAT_NSTATS; i++) {
+ long long val = 0;
+ if (i == MEM_CGROUP_STAT_SWAP !do_swap_account)
+ continue;
+ for_each_mem_cgroup_tree(mi, memcg)
+ val += mem_cgroup_read_stat(mi, i);
+ printk(KERN_CONT %s:%lldKB , mem_cgroup_stat_names[i],
K(val));
+ }
+
+ for (i = 0; i NR_LRU_LISTS; i++) {
+ unsigned long long val = 0;
+
+ for_each_mem_cgroup_tree(mi, memcg)
+ val += mem_cgroup_nr_lru_pages(mi, BIT(i));
+ printk(KERN_CONT %s:%lluKB , mem_cgroup_lru_names[i], K(val));
+ }
+ printk(KERN_CONT \n);
This is nice and simple I am just thinking whether it is enough. Say
that you have a deeper hierarchy and the there is a safety limit in the
its root
A (limit)
/|\
B C D
|\
E F
and we trigger an OOM on the A's limit. Now we know that something blew
up but what it was we do not know. Wouldn't it be better to swap the for
and for_each_mem_cgroup_tree loops? Then we would see the whole
hierarchy and can potentially point at the group which doesn't behave.
Memory cgroup stats for A/: ...
Memory cgroup stats for A/B/: ...
Memory cgroup stats for A/C/: ...
Memory cgroup stats for A/D/: ...
Memory cgroup stats for A/D/E/: ...
Memory cgroup stats for A/D/F/: ...
Would it still fit in with your use case?
[...]
We haven't used those complicate hierarchy yet, but it sounds a good
suggestion. :)
Hierarchy is a little complex to use from our experience, and the
three cgroups involved in memcg oom can be different: memcg of
invoker, killed task, memcg of going over limit.Suppose a process in
B triggers oom and a victim in root A is selected to be killed, we
may as well want to know memcg stats just local in A cgroup(excludes
BCD). So besides hierarchy info, does it acceptable to also print
the local root node stats which as I did in the V1
version(https://lkml.org/lkml/2012/7/30/179).
Ohh, I probably wasn't clear enough. I didn't suggest cumulative
numbers. Only per group. So it would be something like:
for_each_mem_cgroup_tree(mi, memcg) {
printk(Memory cgroup stats for %s, memcg_name);
for (i = 0; i MEM_CGROUP_STAT_NSTATS; i++) {
if (i == MEM_CGROUP_STAT_SWAP !do_swap_account)
continue;
printk(KERN_CONT %s:%lldKB , mem_cgroup_stat_names[i],
K(mem_cgroup_read_stat(mi, i)));
}
for (i = 0; i NR_LRU_LISTS; i++)
printk(KERN_CONT %s:%lluKB , mem_cgroup_lru_names[i],
K(mem_cgroup_nr_lru_pages(mi, BIT(i;
printk(KERN_CONT\n);
}
Now I catch your point and understand the above... It's smarter than I
thought before.
Thanks for explaining!
Another one I'm hesitating is numa stats, it seems the output is
beginning to get more and more
NUMA stats are basically per node - per zone LRU data and that the
for(NR_LRU_LISTS) can be easily extended to cover that.
Yes, the numa_stat cgroup file has done works here. I'll add the numa
stats if you don't feel improper.
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
