* [PATCH 1/2] fixup: "powerpc/perf: Add support for the hv 24x7 interface"
From: Cody P Schafer @ 2014-04-02 22:10 UTC (permalink / raw)
To: Michael Ellerman
Cc: Linux PPC, cody+local, LKML, David.Laight, Anton Blanchard,
Cody P Schafer
In-Reply-To: <1396476654-20623-1-git-send-email-cody@linux.vnet.ibm.com>
Make the "not enabled" message less awful.
Signed-off-by: Cody P Schafer <cody@linux.vnet.ibm.com>
---
arch/powerpc/perf/hv-24x7.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/powerpc/perf/hv-24x7.c b/arch/powerpc/perf/hv-24x7.c
index 297c9105..3246ea2 100644
--- a/arch/powerpc/perf/hv-24x7.c
+++ b/arch/powerpc/perf/hv-24x7.c
@@ -491,7 +491,7 @@ static int hv_24x7_init(void)
hret = hv_perf_caps_get(&caps);
if (hret) {
- pr_info("could not obtain capabilities, error 0x%80lx, not enabling\n",
+ pr_info("could not obtain capabilities, not enabling (%ld)\n",
hret);
return -ENODEV;
}
--
1.9.1
^ permalink raw reply related
* [PATCH 2/2] fixup: "powerpc/perf: Add support for the hv gpci (get performance counter info) interface"
From: Cody P Schafer @ 2014-04-02 22:10 UTC (permalink / raw)
To: Michael Ellerman
Cc: Linux PPC, cody+local, LKML, David.Laight, Anton Blanchard,
Cody P Schafer
In-Reply-To: <1396476654-20623-1-git-send-email-cody@linux.vnet.ibm.com>
Make the "not enabled" message less awful.
Signed-off-by: Cody P Schafer <cody@linux.vnet.ibm.com>
---
arch/powerpc/perf/hv-gpci.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/powerpc/perf/hv-gpci.c b/arch/powerpc/perf/hv-gpci.c
index 278ba7b..f6c471d 100644
--- a/arch/powerpc/perf/hv-gpci.c
+++ b/arch/powerpc/perf/hv-gpci.c
@@ -279,7 +279,7 @@ static int hv_gpci_init(void)
hret = hv_perf_caps_get(&caps);
if (hret) {
- pr_info("could not obtain capabilities, error 0x%80lx, not enabling\n",
+ pr_info("could not obtain capabilities, not enabling (%ld)\n",
hret);
return -ENODEV;
}
--
1.9.1
^ permalink raw reply related
* [PATCH 0/2] powerpc/perf: fixup 2 patches from the 24x7 series
From: Cody P Schafer @ 2014-04-02 22:10 UTC (permalink / raw)
To: Michael Ellerman
Cc: Linux PPC, cody+local, LKML, David.Laight, Anton Blanchard,
Cody P Schafer
mpe: these are fixups for 2 patches already in your merge tree (and in benh's next branch).
f3e622941a7cec587c00c0d17ea31514457c63c8 powerpc/perf: Add support for the hv 24x7 interface
edd354ea4a6774bf9f380b0acf30e699070f4e8a powerpc/perf: Add support for the hv gpci (get performance counter info) interface
The only change is to a pr_info() printed when the interface is not detected.
Anton: I'm hesitant to switch these to pr_debug() as they are the only way
users expecting these PMUs to exist to tell why the kernel decided they didn't
have them. As a result, I've kept them as pr_info() instead of converting to
pr_debug().
Cody P Schafer (2):
fixup: "powerpc/perf: Add support for the hv 24x7 interface"
fixup: "powerpc/perf: Add support for the hv gpci (get performance
counter info) interface"
arch/powerpc/perf/hv-24x7.c | 2 +-
arch/powerpc/perf/hv-gpci.c | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
--
1.9.1
^ permalink raw reply
* Re: [PATCH v2] powernv: kvm: make _PAGE_NUMA take effect
From: Liu ping fan @ 2014-04-03 2:36 UTC (permalink / raw)
To: Alexander Graf
Cc: kvm-devel, kvm-ppc, Paul Mackerras, Aneesh Kumar K.V,
linuxppc-dev
In-Reply-To: <C4D7ADEA-9CEB-4717-9AFD-CC8EFB18184A@suse.de>
Hi Alex, could you help to pick up this patch? since v3.14 kernel can
enable numa fault for powerpc.
Thx,
Fan
On Mon, Jan 27, 2014 at 5:11 PM, Alexander Graf <agraf@suse.de> wrote:
>
> On 21.01.2014, at 10:42, Aneesh Kumar K.V <aneesh.kumar@linux.vnet.ibm.com> wrote:
>
>> Liu Ping Fan <kernelfans@gmail.com> writes:
>>
>>> To make sure that on host, the pages marked with _PAGE_NUMA result in a fault
>>> when guest access them, we should force the checking when guest uses hypercall
>>> to setup hpte.
>>>
>>> Signed-off-by: Liu Ping Fan <pingfank@linux.vnet.ibm.com>
>>
>> Reviewed-by: Aneesh Kumar K.V <aneesh.kumar@linux.vnet.ibm.com>
>>
>> When we mark pte with _PAGE_NUMA we already call mmu_notifier_invalidate_range_start and
>> mmu_notifier_invalidate_range_end, which will mark existing guest hpte
>> entry as HPTE_V_ABSENT. Now we need to do that when we are inserting new
>> guest hpte entries. This patch does that.
>
> So what happens next? We insert a page into the HTAB without HPTE_V_VALID set, so the guest will fail to use it. If the guest does an H_READ on it it will suddenly turn to V_VALID though?
>
> I might need a crash course in the use of HPTE_V_ABSENT.
>
>
> Alex
>
^ permalink raw reply
* RE: [PATCH] cpuidle: add freescale e500 family porcessors idle support
From: Dongsheng.Wang @ 2014-04-03 3:20 UTC (permalink / raw)
To: Daniel Lezcano, Scott Wood
Cc: chenhui.zhao@freescale.com, linux-pm@vger.kernel.org,
rjw@rjwysocki.net, Jason.Jin@freescale.com,
linuxppc-dev@lists.ozlabs.org
In-Reply-To: <533BDA11.9080905@linaro.org>
SGkgRGFuaWVsLA0KDQpUaGFua3MgZm9yIHlvdXIgcmV2aWV3LiBJIHdpbGwgZml4IHlvdXIgY29t
bWVudHMuDQoNCkJUVywgZml4IFJhZmFlbCdzIGVtYWlsLiA6KQ0KDQo+ID4gKyNpbmNsdWRlIDxs
aW51eC9jcHUuaD4NCj4gPiArI2luY2x1ZGUgPGxpbnV4L2NwdWlkbGUuaD4NCj4gPiArI2luY2x1
ZGUgPGxpbnV4L2luaXQuaD4NCj4gPiArI2luY2x1ZGUgPGxpbnV4L2tlcm5lbC5oPg0KPiA+ICsj
aW5jbHVkZSA8bGludXgvbm90aWZpZXIuaD4NCj4gPiArDQo+ID4gKyNpbmNsdWRlIDxhc20vY3B1
dGFibGUuaD4NCj4gPiArI2luY2x1ZGUgPGFzbS9tYWNoZGVwLmg+DQo+ID4gKyNpbmNsdWRlIDxh
c20vbXBjODV4eC5oPg0KPiA+ICsNCj4gPiArc3RhdGljIHVuc2lnbmVkIGludCBtYXhfaWRsZV9z
dGF0ZTsNCj4gPiArc3RhdGljIHN0cnVjdCBjcHVpZGxlX3N0YXRlICpjcHVpZGxlX3N0YXRlX3Rh
YmxlOw0KPiA+ICsNCj4gPiArc3RydWN0IGNwdWlkbGVfZHJpdmVyIGU1MDBfaWRsZV9kcml2ZXIg
PSB7DQo+ID4gKwkubmFtZSA9ICJlNTAwX2lkbGUiLA0KPiA+ICsJLm93bmVyID0gVEhJU19NT0RV
TEUsDQo+ID4gK307DQo+ID4gKw0KPiA+ICtzdGF0aWMgdm9pZCBlNTAwX2NwdWlkbGUodm9pZCkN
Cj4gPiArew0KPiA+ICsJaWYgKGNwdWlkbGVfaWRsZV9jYWxsKCkpDQo+ID4gKwkJY3B1aWRsZV93
YWl0KCk7DQo+ID4gK30NCj4gDQo+IE5vcGUsIHRoYXQgaGFzIGJlZW4gY2hhbmdlZC4gTm8gbW9y
ZSBjYWxsIHRvIGNwdWlkbGVfaWRsZV9jYWxsIGluIGEgZHJpdmVyLg0KPiANCg0KVGhhbmtzLg0K
DQo+ID4gKw0KPiA+ICtzdGF0aWMgaW50IHB3MTBfZW50ZXIoc3RydWN0IGNwdWlkbGVfZGV2aWNl
ICpkZXYsDQo+ID4gKwkJCXN0cnVjdCBjcHVpZGxlX2RyaXZlciAqZHJ2LCBpbnQgaW5kZXgpDQo+
ID4gK3sNCj4gPiArCWNwdWlkbGVfd2FpdCgpOw0KPiA+ICsJcmV0dXJuIGluZGV4Ow0KPiA+ICt9
DQo+ID4gKw0KPiA+ICsjZGVmaW5lIE1BWF9CSVQJNjMNCj4gPiArI2RlZmluZSBNSU5fQklUCTEN
Cj4gPiArZXh0ZXJuIHUzMiBjcHVpZGxlX2VudHJ5X2JpdDsNCj4gPiArc3RhdGljIGludCBwdzIw
X2VudGVyKHN0cnVjdCBjcHVpZGxlX2RldmljZSAqZGV2LA0KPiA+ICsJCXN0cnVjdCBjcHVpZGxl
X2RyaXZlciAqZHJ2LCBpbnQgaW5kZXgpDQo+ID4gK3sNCj4gPiArCXUzMiBwdzIwX2lkbGU7DQo+
ID4gKwl1MzIgZW50cnlfYml0Ow0KPiA+ICsJcHcyMF9pZGxlID0gbWZzcHIoU1BSTl9QV1JNR1RD
UjApOw0KPiA+ICsJaWYgKChwdzIwX2lkbGUgJiBQV1JNR1RDUjBfUFcyMF9FTlQpICE9IFBXUk1H
VENSMF9QVzIwX0VOVCkgew0KPiA+ICsJCXB3MjBfaWRsZSAmPSB+UFdSTUdUQ1IwX1BXMjBfRU5U
Ow0KPiA+ICsJCWVudHJ5X2JpdCA9IE1BWF9CSVQgLSBjcHVpZGxlX2VudHJ5X2JpdDsNCj4gPiAr
CQlwdzIwX2lkbGUgfD0gKGVudHJ5X2JpdCA8PCBQV1JNR1RDUjBfUFcyMF9FTlRfU0hJRlQpOw0K
PiA+ICsJCW10c3ByKFNQUk5fUFdSTUdUQ1IwLCBwdzIwX2lkbGUpOw0KPiA+ICsJfQ0KPiA+ICsN
Cj4gPiArCWNwdWlkbGVfd2FpdCgpOw0KPiA+ICsNCj4gPiArCXB3MjBfaWRsZSAmPSB+UFdSTUdU
Q1IwX1BXMjBfRU5UOw0KPiA+ICsJcHcyMF9pZGxlIHw9IChNSU5fQklUIDw8IFBXUk1HVENSMF9Q
VzIwX0VOVF9TSElGVCk7DQo+ID4gKwltdHNwcihTUFJOX1BXUk1HVENSMCwgcHcyMF9pZGxlKTsN
Cj4gPiArDQo+ID4gKwlyZXR1cm4gaW5kZXg7DQo+ID4gK30NCj4gDQo+IElzIGl0IHBvc3NpYmxl
IHRvIGdpdmUgc29tZSBjb21tZW50cyBhbmQgZW5jYXBzdWxhdGUgdGhlIGNvZGUgd2l0aA0KPiBl
eHBsaWNpdCBmdW5jdGlvbiBuYW1lcyB0byBiZSBpbXBsZW1lbnRlZCBpbiBhbiBhcmNoIHNwZWNp
ZmljIGRpcmVjdG9yeQ0KPiBmaWxlIChlZy4gcG0uYykgYW5kIGV4cG9ydCB0aGVzZSBmdW5jdGlv
bnMgaW4gYSBsaW51eC8gaGVhZGVyID8gV2UgdHJ5DQo+IHRvIHByZXZlbnQgdG8gaW5jbHVkZSBh
c20gaWYgcG9zc2libGUuDQo+IA0KDQpZZXAsIExvb2tzIGJldHRlci4gVGhhbmtzLg0KDQo+ID4g
Kw0KPiA+ICtzdGF0aWMgc3RydWN0IGNwdWlkbGVfc3RhdGUgcHdfaWRsZV9zdGF0ZXNbXSA9IHsN
Cj4gPiArCXsNCj4gPiArCQkubmFtZSA9ICJwdzEwIiwNCj4gPiArCQkuZGVzYyA9ICJwdzEwIiwN
Cj4gPiArCQkuZmxhZ3MgPSBDUFVJRExFX0ZMQUdfVElNRV9WQUxJRCwNCj4gPiArCQkuZXhpdF9s
YXRlbmN5ID0gMCwNCj4gPiArCQkudGFyZ2V0X3Jlc2lkZW5jeSA9IDAsDQo+ID4gKwkJLmVudGVy
ID0gJnB3MTBfZW50ZXINCj4gPiArCX0sDQo+ID4gKw0KPiA+ICsJew0KPiA+ICsJCS5uYW1lID0g
InB3MjAiLA0KPiA+ICsJCS5kZXNjID0gInB3MjAtY29yZS1pZGxlIiwNCj4gPiArCQkuZmxhZ3Mg
PSBDUFVJRExFX0ZMQUdfVElNRV9WQUxJRCwNCj4gPiArCQkuZXhpdF9sYXRlbmN5ID0gMSwNCj4g
PiArCQkudGFyZ2V0X3Jlc2lkZW5jeSA9IDUwLA0KPiA+ICsJCS5lbnRlciA9ICZwdzIwX2VudGVy
DQo+ID4gKwl9LA0KPiA+ICt9Ow0KPiANCj4gTm8gbmVlZCB0byBkZWZpbmUgdGhpcyBpbnRlcm1l
ZGlhdGUgc3RydWN0dXJlIGhlcmUsIHlvdSBjYW4gZGlyZWN0bHkNCj4gaW5pdGlhbGl6ZSB0aGUg
Y3B1aWRsZV9kcml2ZXI6DQo+IA0KDQpUaGFua3MuIDopDQoNCj4gPiArc3RhdGljIGludCBjcHVf
aG90cGx1Z19ub3RpZnkoc3RydWN0IG5vdGlmaWVyX2Jsb2NrICpuLA0KPiA+ICsJCQl1bnNpZ25l
ZCBsb25nIGFjdGlvbiwgdm9pZCAqaGNwdSkNCj4gPiArew0KPiA+ICsJdW5zaWduZWQgbG9uZyBo
b3RjcHUgPSAodW5zaWduZWQgbG9uZyloY3B1Ow0KPiA+ICsJc3RydWN0IGNwdWlkbGVfZGV2aWNl
ICpkZXYgPQ0KPiA+ICsJCQlwZXJfY3B1X3B0cihjcHVpZGxlX2RldmljZXMsIGhvdGNwdSk7DQo+
ID4gKw0KPiA+ICsJaWYgKGRldiAmJiBjcHVpZGxlX2dldF9kcml2ZXIoKSkgew0KPiA+ICsJCXN3
aXRjaCAoYWN0aW9uKSB7DQo+ID4gKwkJY2FzZSBDUFVfT05MSU5FOg0KPiA+ICsJCWNhc2UgQ1BV
X09OTElORV9GUk9aRU46DQo+ID4gKwkJCWNwdWlkbGVfcGF1c2VfYW5kX2xvY2soKTsNCj4gPiAr
CQkJY3B1aWRsZV9lbmFibGVfZGV2aWNlKGRldik7DQo+ID4gKwkJCWNwdWlkbGVfcmVzdW1lX2Fu
ZF91bmxvY2soKTsNCj4gPiArCQkJYnJlYWs7DQo+ID4gKw0KPiA+ICsJCWNhc2UgQ1BVX0RFQUQ6
DQo+ID4gKwkJY2FzZSBDUFVfREVBRF9GUk9aRU46DQo+ID4gKwkJCWNwdWlkbGVfcGF1c2VfYW5k
X2xvY2soKTsNCj4gPiArCQkJY3B1aWRsZV9kaXNhYmxlX2RldmljZShkZXYpOw0KPiA+ICsJCQlj
cHVpZGxlX3Jlc3VtZV9hbmRfdW5sb2NrKCk7DQo+ID4gKwkJCWJyZWFrOw0KPiA+ICsNCj4gPiAr
CQlkZWZhdWx0Og0KPiA+ICsJCQlyZXR1cm4gTk9USUZZX0RPTkU7DQo+ID4gKwkJfQ0KPiA+ICsJ
fQ0KPiA+ICsNCj4gPiArCXJldHVybiBOT1RJRllfT0s7DQo+ID4gK30NCj4gPiArDQo+ID4gK3N0
YXRpYyBzdHJ1Y3Qgbm90aWZpZXJfYmxvY2sgY3B1X2hvdHBsdWdfbm90aWZpZXIgPSB7DQo+ID4g
Kwkubm90aWZpZXJfY2FsbCA9IGNwdV9ob3RwbHVnX25vdGlmeSwNCj4gPiArfTsNCj4gDQo+IENh
biB5b3UgZXhwbGFpbiB3aHkgdGhpcyBpcyBuZWVkZWQgPw0KPiANCg0KSWYgYSBjcHUgd2lsbCBi
ZSBwbHVnZ2VkIG91dC9pbiwgV2Ugc2hvdWxkIGJlIGxldCBDcHVpZGxlIGtub3cgdG8gcmVtb3Zl
DQpjb3JyZXNwb25kaW5nIHN5cyBpbnRlcmZhY2UgYW5kIGRpc2FibGUvZW5hYmxlIGNwdWRpbGUt
Z292ZXJub3IgZm9yIGN1cnJlbnQgY3B1Lg0KDQo+ID4gKwllcnIgPSByZWdpc3Rlcl9jcHVfbm90
aWZpZXIoJmNwdV9ob3RwbHVnX25vdGlmaWVyKTsNCj4gPiArCWlmIChlcnIpDQo+ID4gKwkJcHJf
d2FybigiQ3B1aWRsZSBkcml2ZXI6IHJlZ2lzdGVyIGNwdSBub3RpZmllciBmYWlsZWQuXG4iKTsN
Cj4gPiArDQo+ID4gKwkvKiBSZXBsYWNlIHRoZSBvcmlnaW5hbCB3YXkgb2YgaWRsZSBhZnRlciBj
cHVpZGxlIHJlZ2lzdGVyZWQuICovDQo+ID4gKwlwcGNfbWQucG93ZXJfc2F2ZSA9IGU1MDBfY3B1
aWRsZTsNCj4gPiArCW9uX2VhY2hfY3B1KHJlcGxhY2Vfb3JpZ19pZGxlLCBOVUxMLCAxKTsNCj4g
DQo+IFdoeSA/DQo+IA0KDQpJIGNoZWNrZWQgYWdhaW4sIGlmIHdlIHB1dCBjcHVpZGxlX2lkbGVf
Y2FsbCBpbiBhc20sIHRoaXMgaXMgbm90IG5lZWQuDQoNClJlZ2FyZHMsDQotRG9uZ3NoZW5nDQoN
Cj4gPiArCXByX2luZm8oImU1MDBfaWRsZV9kcml2ZXIgcmVnaXN0ZXJlZC5cbiIpOw0KPiA+ICsN
Cj4gPiArCXJldHVybiAwOw0KPiA+ICt9DQo+ID4gK2xhdGVfaW5pdGNhbGwoZTUwMF9pZGxlX2lu
aXQpOw0KPiA+DQo+IA0KPiBUaGFua3MNCj4gDQo+ICAgIC0tIERhbmllbA0KPiANCj4gDQo+IC0t
DQo+ICAgPGh0dHA6Ly93d3cubGluYXJvLm9yZy8+IExpbmFyby5vcmcg4pSCIE9wZW4gc291cmNl
IHNvZnR3YXJlIGZvciBBUk0gU29Dcw0KPiANCj4gRm9sbG93IExpbmFybzogIDxodHRwOi8vd3d3
LmZhY2Vib29rLmNvbS9wYWdlcy9MaW5hcm8+IEZhY2Vib29rIHwNCj4gPGh0dHA6Ly90d2l0dGVy
LmNvbS8jIS9saW5hcm9vcmc+IFR3aXR0ZXIgfA0KPiA8aHR0cDovL3d3dy5saW5hcm8ub3JnL2xp
bmFyby1ibG9nLz4gQmxvZw0KPiANCj4gDQoNCg==
^ permalink raw reply
* Re: MPC8641 based custom board Kernel stuck at 1000Mhz core clock
From: sanjeev sharma @ 2014-04-03 3:25 UTC (permalink / raw)
To: Valdis Kletnieks; +Cc: scottwood, Ashish, linuxppc-dev, kernelnewbies
In-Reply-To: <3723.1395937889@turing-police.cc.vt.edu>
[-- Attachment #1: Type: text/plain, Size: 900 bytes --]
Are you able to capture kernel logs ?
Regards
Sanjeev Sharma
On Thu, Mar 27, 2014 at 10:01 PM, <Valdis.Kletnieks@vt.edu> wrote:
> On Thu, 27 Mar 2014 16:04:37 +0530, Ashish said:
> > Hi,
> >
> > I am using MPC8641-HPCN based custom board and able to boot linux at
> > MPX clock 400Mhz and core clock 800mhz. When I am increasing core
> > frequency ie MPX clock at 400Mhz and core at 1Ghz, kernel stuck.
>
> Step 0: Prove to us that your core actually runs reliable and stably at
> 1Ghz.
>
> Step 1: Figure out *where* it gets stuck. If you have earlyprintk working
> on
> your board, adding 'initcall_debug ignore_loglevel' to the kernel cmdline
> often
> helps track down where a kernel hangs during boot.
>
>
> _______________________________________________
> Kernelnewbies mailing list
> Kernelnewbies@kernelnewbies.org
> http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
>
>
[-- Attachment #2: Type: text/html, Size: 1466 bytes --]
^ permalink raw reply
* Re: [PATCH] ASoC: fsl_sai: Add imx6sx platform support
From: Nicolin Chen @ 2014-04-03 3:11 UTC (permalink / raw)
To: Mark Brown
Cc: mark.rutland, devicetree, alsa-devel, pawel.moll, linux-doc,
ijc+devicetree, linux-kernel, robh+dt, timur, Li.Xiubo, rob,
galak, linuxppc-dev
In-Reply-To: <20140402195208.GM14763@sirena.org.uk>
On Wed, Apr 02, 2014 at 08:52:08PM +0100, Mark Brown wrote:
> On Tue, Apr 01, 2014 at 07:34:09PM +0800, Nicolin Chen wrote:
> > The next coming i.MX6 Solo X SoC also contains SAI module while we use
> > imp_pcm_init() for i.MX platform.
>
> I've applied this, though obviously it'd be better if we had dmaengine
> support for this SoC so that it was just a compatible string update and
> didn't require any code.
Hmm...actually imx_pcm_init() is just a shell calling dmaengine while it
has its own config and flags. So we still need to extinguish these two
elements for them even if using devm_snd_dmaengine_pcm_register() eventually.
But the idea to merge them into one entry should be great for 3rd platform
or even further one. And a patch for imx-pcm-dma and all callers of it
would be needed then.
Thank you,
Nicolin
^ permalink raw reply
* Re: [PATCH] cpuidle: add freescale e500 family porcessors idle support
From: Daniel Lezcano @ 2014-04-03 6:28 UTC (permalink / raw)
To: Dongsheng.Wang@freescale.com, Scott Wood
Cc: chenhui.zhao@freescale.com, linux-pm@vger.kernel.org,
rjw@rjwysocki.net, Jason.Jin@freescale.com,
linuxppc-dev@lists.ozlabs.org
In-Reply-To: <e32c248e30c54f458f65501227b1ce54@BN1PR03MB188.namprd03.prod.outlook.com>
On 04/03/2014 05:20 AM, Dongsheng.Wang@freescale.com wrote:
> Hi Daniel,
>
> Thanks for your review. I will fix your comments.
>
> BTW, fix Rafael's email. :)
>
>>> +#include <linux/cpu.h>
>>> +#include <linux/cpuidle.h>
>>> +#include <linux/init.h>
>>> +#include <linux/kernel.h>
>>> +#include <linux/notifier.h>
>>> +
>>> +#include <asm/cputable.h>
>>> +#include <asm/machdep.h>
>>> +#include <asm/mpc85xx.h>
>>> +
>>> +static unsigned int max_idle_state;
>>> +static struct cpuidle_state *cpuidle_state_table;
>>> +
>>> +struct cpuidle_driver e500_idle_driver = {
>>> + .name = "e500_idle",
>>> + .owner = THIS_MODULE,
>>> +};
>>> +
>>> +static void e500_cpuidle(void)
>>> +{
>>> + if (cpuidle_idle_call())
>>> + cpuidle_wait();
>>> +}
>>
>> Nope, that has been changed. No more call to cpuidle_idle_call in a driver.
>>
>
> Thanks.
>
>>> +
>>> +static int pw10_enter(struct cpuidle_device *dev,
>>> + struct cpuidle_driver *drv, int index)
>>> +{
>>> + cpuidle_wait();
>>> + return index;
>>> +}
>>> +
>>> +#define MAX_BIT 63
>>> +#define MIN_BIT 1
>>> +extern u32 cpuidle_entry_bit;
>>> +static int pw20_enter(struct cpuidle_device *dev,
>>> + struct cpuidle_driver *drv, int index)
>>> +{
>>> + u32 pw20_idle;
>>> + u32 entry_bit;
>>> + pw20_idle = mfspr(SPRN_PWRMGTCR0);
>>> + if ((pw20_idle & PWRMGTCR0_PW20_ENT) != PWRMGTCR0_PW20_ENT) {
>>> + pw20_idle &= ~PWRMGTCR0_PW20_ENT;
>>> + entry_bit = MAX_BIT - cpuidle_entry_bit;
>>> + pw20_idle |= (entry_bit << PWRMGTCR0_PW20_ENT_SHIFT);
>>> + mtspr(SPRN_PWRMGTCR0, pw20_idle);
>>> + }
>>> +
>>> + cpuidle_wait();
>>> +
>>> + pw20_idle &= ~PWRMGTCR0_PW20_ENT;
>>> + pw20_idle |= (MIN_BIT << PWRMGTCR0_PW20_ENT_SHIFT);
>>> + mtspr(SPRN_PWRMGTCR0, pw20_idle);
>>> +
>>> + return index;
>>> +}
>>
>> Is it possible to give some comments and encapsulate the code with
>> explicit function names to be implemented in an arch specific directory
>> file (eg. pm.c) and export these functions in a linux/ header ? We try
>> to prevent to include asm if possible.
>>
>
> Yep, Looks better. Thanks.
>
>>> +
>>> +static struct cpuidle_state pw_idle_states[] = {
>>> + {
>>> + .name = "pw10",
>>> + .desc = "pw10",
>>> + .flags = CPUIDLE_FLAG_TIME_VALID,
>>> + .exit_latency = 0,
>>> + .target_residency = 0,
>>> + .enter = &pw10_enter
>>> + },
>>> +
>>> + {
>>> + .name = "pw20",
>>> + .desc = "pw20-core-idle",
>>> + .flags = CPUIDLE_FLAG_TIME_VALID,
>>> + .exit_latency = 1,
>>> + .target_residency = 50,
>>> + .enter = &pw20_enter
>>> + },
>>> +};
>>
>> No need to define this intermediate structure here, you can directly
>> initialize the cpuidle_driver:
>>
>
> Thanks. :)
>
>>> +static int cpu_hotplug_notify(struct notifier_block *n,
>>> + unsigned long action, void *hcpu)
>>> +{
>>> + unsigned long hotcpu = (unsigned long)hcpu;
>>> + struct cpuidle_device *dev =
>>> + per_cpu_ptr(cpuidle_devices, hotcpu);
>>> +
>>> + if (dev && cpuidle_get_driver()) {
>>> + switch (action) {
>>> + case CPU_ONLINE:
>>> + case CPU_ONLINE_FROZEN:
>>> + cpuidle_pause_and_lock();
>>> + cpuidle_enable_device(dev);
>>> + cpuidle_resume_and_unlock();
>>> + break;
>>> +
>>> + case CPU_DEAD:
>>> + case CPU_DEAD_FROZEN:
>>> + cpuidle_pause_and_lock();
>>> + cpuidle_disable_device(dev);
>>> + cpuidle_resume_and_unlock();
>>> + break;
>>> +
>>> + default:
>>> + return NOTIFY_DONE;
>>> + }
>>> + }
>>> +
>>> + return NOTIFY_OK;
>>> +}
>>> +
>>> +static struct notifier_block cpu_hotplug_notifier = {
>>> + .notifier_call = cpu_hotplug_notify,
>>> +};
>>
>> Can you explain why this is needed ?
>>
>
> If a cpu will be plugged out/in, We should be let Cpuidle know to remove
> corresponding sys interface and disable/enable cpudile-governor for current cpu.
Ok, this code is a copy-paste of the powers' cpuidle driver.
IIRC, I posted a patchset to move this portion of code in the cpuidle
common framework some time ago.
Could you please get rid of this part of code ?
>>> + err = register_cpu_notifier(&cpu_hotplug_notifier);
>>> + if (err)
>>> + pr_warn("Cpuidle driver: register cpu notifier failed.\n");
>>> +
>>> + /* Replace the original way of idle after cpuidle registered. */
>>> + ppc_md.power_save = e500_cpuidle;
>>> + on_each_cpu(replace_orig_idle, NULL, 1);
>>
>> Why ?
>>
>
> I checked again, if we put cpuidle_idle_call in asm, this is not need.
>
> Regards,
> -Dongsheng
>
>>> + pr_info("e500_idle_driver registered.\n");
>>> +
>>> + return 0;
>>> +}
>>> +late_initcall(e500_idle_init);
>>>
>>
>> Thanks
>>
>> -- Daniel
>>
>>
>> --
>> <http://www.linaro.org/> Linaro.org │ Open source software for ARM SoCs
>>
>> Follow Linaro: <http://www.facebook.com/pages/Linaro> Facebook |
>> <http://twitter.com/#!/linaroorg> Twitter |
>> <http://www.linaro.org/linaro-blog/> Blog
>>
>>
>
--
<http://www.linaro.org/> Linaro.org │ Open source software for ARM SoCs
Follow Linaro: <http://www.facebook.com/pages/Linaro> Facebook |
<http://twitter.com/#!/linaroorg> Twitter |
<http://www.linaro.org/linaro-blog/> Blog
^ permalink raw reply
* [PATCH] powerpc: use of_node_init() for the fakenode in msi_bitmap.c
From: Li Zhong @ 2014-04-03 6:58 UTC (permalink / raw)
To: PowerPC email list; +Cc: grant.likely, Paul Mackerras
This patch uses of_node_init() to initialize the kobject in the fake
node used in test_of_node(), to avoid following kobject warning.
[ 0.897654] kobject: '(null)' (c0000007ca183a08): is not initialized, yet kobject_put() is being called.
[ 0.897682] ------------[ cut here ]------------
[ 0.897688] WARNING: at lib/kobject.c:670
[ 0.897692] Modules linked in:
[ 0.897701] CPU: 4 PID: 1 Comm: swapper/0 Not tainted 3.14.0+ #1
[ 0.897708] task: c0000007ca100000 ti: c0000007ca180000 task.ti: c0000007ca180000
[ 0.897715] NIP: c00000000046a1f0 LR: c00000000046a1ec CTR: 0000000001704660
[ 0.897721] REGS: c0000007ca1835c0 TRAP: 0700 Not tainted (3.14.0+)
[ 0.897727] MSR: 8000000000029032 <SF,EE,ME,IR,DR,RI> CR: 28000024 XER: 0000000d
[ 0.897749] CFAR: c0000000008ef4ec SOFTE: 1
GPR00: c00000000046a1ec c0000007ca183840 c0000000014c59b8 000000000000005c
GPR04: 0000000000000001 c000000000129770 0000000000000000 0000000000000001
GPR08: 0000000000000000 0000000000000000 0000000000000000 0000000000003fef
GPR12: 0000000000000000 c00000000f221200 c00000000000c350 0000000000000000
GPR16: 0000000000000000 0000000000000000 0000000000000000 0000000000000000
GPR20: 0000000000000000 0000000000000000 0000000000000000 0000000000000000
GPR24: 0000000000000000 c00000000144e808 c000000000c56f20 00000000000000d8
GPR28: c000000000cd5058 0000000000000000 c000000001454ca8 c0000007ca183a08
[ 0.897856] NIP [c00000000046a1f0] .kobject_put+0xa0/0xb0
[ 0.897863] LR [c00000000046a1ec] .kobject_put+0x9c/0xb0
[ 0.897868] Call Trace:
[ 0.897874] [c0000007ca183840] [c00000000046a1ec] .kobject_put+0x9c/0xb0 (unreliable)
[ 0.897885] [c0000007ca1838c0] [c000000000743f9c] .of_node_put+0x2c/0x50
[ 0.897894] [c0000007ca183940] [c000000000c83954] .test_of_node+0x1dc/0x208
[ 0.897902] [c0000007ca183b80] [c000000000c839a4] .msi_bitmap_selftest+0x24/0x38
[ 0.897913] [c0000007ca183bf0] [c00000000000bb34] .do_one_initcall+0x144/0x200
[ 0.897922] [c0000007ca183ce0] [c000000000c748e4] .kernel_init_freeable+0x2b4/0x394
[ 0.897931] [c0000007ca183db0] [c00000000000c374] .kernel_init+0x24/0x130
[ 0.897940] [c0000007ca183e30] [c00000000000a2f4] .ret_from_kernel_thread+0x5c/0x68
[ 0.897947] Instruction dump:
[ 0.897952] 7fe3fb78 38210080 e8010010 ebe1fff8 7c0803a6 4800014c e89f0000 3c62ff6e
[ 0.897971] 7fe5fb78 3863a950 48485279 60000000 <0fe00000> 39000000 393f0038 4bffff80
[ 0.897992] ---[ end trace 1eeffdb9f825a556 ]---
Signed-off-by: Li Zhong <zhong@linux.vnet.ibm.com>
---
arch/powerpc/sysdev/msi_bitmap.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/powerpc/sysdev/msi_bitmap.c b/arch/powerpc/sysdev/msi_bitmap.c
index 8ba6042..2ff6302 100644
--- a/arch/powerpc/sysdev/msi_bitmap.c
+++ b/arch/powerpc/sysdev/msi_bitmap.c
@@ -202,7 +202,7 @@ void __init test_of_node(void)
/* There should really be a struct device_node allocator */
memset(&of_node, 0, sizeof(of_node));
- kref_init(&of_node.kobj.kref);
+ of_node_init(&of_node);
of_node.full_name = node_name;
check(0 == msi_bitmap_alloc(&bmp, size, &of_node));
^ permalink raw reply related
* Re: [PATCH 6/7] DMA: Freescale: use spin_lock_bh instead of spin_lock_irqsave
From: Hongbo Zhang @ 2014-04-03 7:00 UTC (permalink / raw)
To: Vinod Koul
Cc: Vinod Koul, linux-kernel, scottwood, dmaengine, dan.j.williams,
linuxppc-dev
In-Reply-To: <20140402163519.GU1976@intel.com>
On 04/03/2014 12:35 AM, Vinod Koul wrote:
> On Mon, Mar 31, 2014 at 12:08:55PM +0800, Hongbo Zhang wrote:
>> On 03/29/2014 09:45 PM, Vinod Koul wrote:
>>> On Fri, Mar 28, 2014 at 02:33:37PM +0800, Hongbo Zhang wrote:
>>>> On 03/26/2014 03:01 PM, Vinod Koul wrote:
>>>>> On Thu, 2014-01-16 at 13:47 +0800, hongbo.zhang@freescale.com wrote:
>>>>>> From: Hongbo Zhang <hongbo.zhang@freescale.com>
>>>>>>
>>>>>> The usage of spin_lock_irqsave() is a stronger locking mechanism than is
>>>>>> required throughout the driver. The minimum locking required should be used
>>>>>> instead. Interrupts will be turned off and context will be saved, it is
>>>>>> unnecessary to use irqsave.
>>>>>>
>>>>>> This patch changes all instances of spin_lock_irqsave() to spin_lock_bh(). All
>>>>>> manipulation of protected fields is done using tasklet context or weaker, which
>>>>>> makes spin_lock_bh() the correct choice.
>>>>>>
>>>>>> /**
>>>>>> @@ -1124,11 +1120,10 @@ static irqreturn_t fsldma_chan_irq(int irq, void *data)
>>>>>> static void dma_do_tasklet(unsigned long data)
>>>>>> {
>>>>>> struct fsldma_chan *chan = (struct fsldma_chan *)data;
>>>>>> - unsigned long flags;
>>>>>> chan_dbg(chan, "tasklet entry\n");
>>>>>> - spin_lock_irqsave(&chan->desc_lock, flags);
>>>>>> + spin_lock_bh(&chan->desc_lock);
>>>>> okay here is the problem :(
>>>>>
>>>>> You moved to _bh variant. So if you grab the lock in rest of the code
>>>>> and irq gets triggered then here we will be spinning to grab the lock.
>>>>> So effectively you made right locking solution into deadlock situation!
>>>> If the rest code grabs lock by spin_lock_bh(), and if irq raised,
>>>> the tasklet could not be executed because it has been disabled by
>>>> the _bh variant function.
>>> yes if you are accessing resources only in tasklet and rest of the code, then
>>> _bh variant works well. The problem here is usage in irq handler
>>>
>> The name dma_do_tasklet may mislead, it is tasklet handler, not irq
>> handler, not a trigger to load tasklet.
>> the irq handler is fsldma_chan_irq, and I don't use lock in it.
> sorry my bad, i misread this as code in fsldma_chan_irq() insteadof
> dma_do_tasklet(). In that case patch is doing the right thing.
>
OK, so I will send a v2 series with only updating 3/7 soon.
^ permalink raw reply
* RE: [PATCH] cpuidle: add freescale e500 family porcessors idle support
From: Dongsheng.Wang @ 2014-04-03 8:03 UTC (permalink / raw)
To: Daniel Lezcano, Scott Wood
Cc: chenhui.zhao@freescale.com, linux-pm@vger.kernel.org,
rjw@rjwysocki.net, Jason.Jin@freescale.com,
linuxppc-dev@lists.ozlabs.org
In-Reply-To: <533CFFA7.6000907@linaro.org>
DQoNCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogRGFuaWVsIExlemNhbm8g
W21haWx0bzpkYW5pZWwubGV6Y2Fub0BsaW5hcm8ub3JnXQ0KPiBTZW50OiBUaHVyc2RheSwgQXBy
aWwgMDMsIDIwMTQgMjoyOSBQTQ0KPiBUbzogV2FuZyBEb25nc2hlbmctQjQwNTM0OyBXb29kIFNj
b3R0LUIwNzQyMQ0KPiBDYzogcmp3QHJqd3lzb2NraS5uZXQ7IExpIFlhbmctTGVvLVI1ODQ3Mjsg
SmluIFpoZW5neGlvbmctUjY0MTg4OyBaaGFvIENoZW5odWktDQo+IEIzNTMzNjsgbGludXgtcG1A
dmdlci5rZXJuZWwub3JnOyBsaW51eHBwYy1kZXZAbGlzdHMub3psYWJzLm9yZw0KPiBTdWJqZWN0
OiBSZTogW1BBVENIXSBjcHVpZGxlOiBhZGQgZnJlZXNjYWxlIGU1MDAgZmFtaWx5IHBvcmNlc3Nv
cnMgaWRsZSBzdXBwb3J0DQo+IA0KPiBPbiAwNC8wMy8yMDE0IDA1OjIwIEFNLCBEb25nc2hlbmcu
V2FuZ0BmcmVlc2NhbGUuY29tIHdyb3RlOg0KPiA+IEhpIERhbmllbCwNCj4gPg0KPiA+IFRoYW5r
cyBmb3IgeW91ciByZXZpZXcuIEkgd2lsbCBmaXggeW91ciBjb21tZW50cy4NCj4gPg0KPiA+IEJU
VywgZml4IFJhZmFlbCdzIGVtYWlsLiA6KQ0KPiA+DQo+ID4+PiArI2luY2x1ZGUgPGxpbnV4L2Nw
dS5oPg0KPiA+Pj4gKyNpbmNsdWRlIDxsaW51eC9jcHVpZGxlLmg+DQo+ID4+PiArI2luY2x1ZGUg
PGxpbnV4L2luaXQuaD4NCj4gPj4+ICsjaW5jbHVkZSA8bGludXgva2VybmVsLmg+DQo+ID4+PiAr
I2luY2x1ZGUgPGxpbnV4L25vdGlmaWVyLmg+DQo+ID4+PiArDQo+ID4+PiArI2luY2x1ZGUgPGFz
bS9jcHV0YWJsZS5oPg0KPiA+Pj4gKyNpbmNsdWRlIDxhc20vbWFjaGRlcC5oPg0KPiA+Pj4gKyNp
bmNsdWRlIDxhc20vbXBjODV4eC5oPg0KPiA+Pj4gKw0KPiA+Pj4gK3N0YXRpYyB1bnNpZ25lZCBp
bnQgbWF4X2lkbGVfc3RhdGU7IHN0YXRpYyBzdHJ1Y3QgY3B1aWRsZV9zdGF0ZQ0KPiA+Pj4gKypj
cHVpZGxlX3N0YXRlX3RhYmxlOw0KPiA+Pj4gKw0KPiA+Pj4gK3N0cnVjdCBjcHVpZGxlX2RyaXZl
ciBlNTAwX2lkbGVfZHJpdmVyID0gew0KPiA+Pj4gKwkubmFtZSA9ICJlNTAwX2lkbGUiLA0KPiA+
Pj4gKwkub3duZXIgPSBUSElTX01PRFVMRSwNCj4gPj4+ICt9Ow0KPiA+Pj4gKw0KPiA+Pj4gK3N0
YXRpYyB2b2lkIGU1MDBfY3B1aWRsZSh2b2lkKQ0KPiA+Pj4gK3sNCj4gPj4+ICsJaWYgKGNwdWlk
bGVfaWRsZV9jYWxsKCkpDQo+ID4+PiArCQljcHVpZGxlX3dhaXQoKTsNCj4gPj4+ICt9DQo+ID4+
DQo+ID4+IE5vcGUsIHRoYXQgaGFzIGJlZW4gY2hhbmdlZC4gTm8gbW9yZSBjYWxsIHRvIGNwdWlk
bGVfaWRsZV9jYWxsIGluIGEgZHJpdmVyLg0KPiA+Pg0KPiA+DQo+ID4gVGhhbmtzLg0KPiA+DQo+
ID4+PiArDQo+ID4+PiArc3RhdGljIGludCBwdzEwX2VudGVyKHN0cnVjdCBjcHVpZGxlX2Rldmlj
ZSAqZGV2LA0KPiA+Pj4gKwkJCXN0cnVjdCBjcHVpZGxlX2RyaXZlciAqZHJ2LCBpbnQgaW5kZXgp
IHsNCj4gPj4+ICsJY3B1aWRsZV93YWl0KCk7DQo+ID4+PiArCXJldHVybiBpbmRleDsNCj4gPj4+
ICt9DQo+ID4+PiArDQo+ID4+PiArI2RlZmluZSBNQVhfQklUCTYzDQo+ID4+PiArI2RlZmluZSBN
SU5fQklUCTENCj4gPj4+ICtleHRlcm4gdTMyIGNwdWlkbGVfZW50cnlfYml0Ow0KPiA+Pj4gK3N0
YXRpYyBpbnQgcHcyMF9lbnRlcihzdHJ1Y3QgY3B1aWRsZV9kZXZpY2UgKmRldiwNCj4gPj4+ICsJ
CXN0cnVjdCBjcHVpZGxlX2RyaXZlciAqZHJ2LCBpbnQgaW5kZXgpIHsNCj4gPj4+ICsJdTMyIHB3
MjBfaWRsZTsNCj4gPj4+ICsJdTMyIGVudHJ5X2JpdDsNCj4gPj4+ICsJcHcyMF9pZGxlID0gbWZz
cHIoU1BSTl9QV1JNR1RDUjApOw0KPiA+Pj4gKwlpZiAoKHB3MjBfaWRsZSAmIFBXUk1HVENSMF9Q
VzIwX0VOVCkgIT0gUFdSTUdUQ1IwX1BXMjBfRU5UKSB7DQo+ID4+PiArCQlwdzIwX2lkbGUgJj0g
flBXUk1HVENSMF9QVzIwX0VOVDsNCj4gPj4+ICsJCWVudHJ5X2JpdCA9IE1BWF9CSVQgLSBjcHVp
ZGxlX2VudHJ5X2JpdDsNCj4gPj4+ICsJCXB3MjBfaWRsZSB8PSAoZW50cnlfYml0IDw8IFBXUk1H
VENSMF9QVzIwX0VOVF9TSElGVCk7DQo+ID4+PiArCQltdHNwcihTUFJOX1BXUk1HVENSMCwgcHcy
MF9pZGxlKTsNCj4gPj4+ICsJfQ0KPiA+Pj4gKw0KPiA+Pj4gKwljcHVpZGxlX3dhaXQoKTsNCj4g
Pj4+ICsNCj4gPj4+ICsJcHcyMF9pZGxlICY9IH5QV1JNR1RDUjBfUFcyMF9FTlQ7DQo+ID4+PiAr
CXB3MjBfaWRsZSB8PSAoTUlOX0JJVCA8PCBQV1JNR1RDUjBfUFcyMF9FTlRfU0hJRlQpOw0KPiA+
Pj4gKwltdHNwcihTUFJOX1BXUk1HVENSMCwgcHcyMF9pZGxlKTsNCj4gPj4+ICsNCj4gPj4+ICsJ
cmV0dXJuIGluZGV4Ow0KPiA+Pj4gK30NCj4gPj4NCj4gPj4gSXMgaXQgcG9zc2libGUgdG8gZ2l2
ZSBzb21lIGNvbW1lbnRzIGFuZCBlbmNhcHN1bGF0ZSB0aGUgY29kZSB3aXRoDQo+ID4+IGV4cGxp
Y2l0IGZ1bmN0aW9uIG5hbWVzIHRvIGJlIGltcGxlbWVudGVkIGluIGFuIGFyY2ggc3BlY2lmaWMN
Cj4gPj4gZGlyZWN0b3J5IGZpbGUgKGVnLiBwbS5jKSBhbmQgZXhwb3J0IHRoZXNlIGZ1bmN0aW9u
cyBpbiBhIGxpbnV4Lw0KPiA+PiBoZWFkZXIgPyBXZSB0cnkgdG8gcHJldmVudCB0byBpbmNsdWRl
IGFzbSBpZiBwb3NzaWJsZS4NCj4gPj4NCj4gPg0KPiA+IFllcCwgTG9va3MgYmV0dGVyLiBUaGFu
a3MuDQo+ID4NCj4gPj4+ICsNCj4gPj4+ICtzdGF0aWMgc3RydWN0IGNwdWlkbGVfc3RhdGUgcHdf
aWRsZV9zdGF0ZXNbXSA9IHsNCj4gPj4+ICsJew0KPiA+Pj4gKwkJLm5hbWUgPSAicHcxMCIsDQo+
ID4+PiArCQkuZGVzYyA9ICJwdzEwIiwNCj4gPj4+ICsJCS5mbGFncyA9IENQVUlETEVfRkxBR19U
SU1FX1ZBTElELA0KPiA+Pj4gKwkJLmV4aXRfbGF0ZW5jeSA9IDAsDQo+ID4+PiArCQkudGFyZ2V0
X3Jlc2lkZW5jeSA9IDAsDQo+ID4+PiArCQkuZW50ZXIgPSAmcHcxMF9lbnRlcg0KPiA+Pj4gKwl9
LA0KPiA+Pj4gKw0KPiA+Pj4gKwl7DQo+ID4+PiArCQkubmFtZSA9ICJwdzIwIiwNCj4gPj4+ICsJ
CS5kZXNjID0gInB3MjAtY29yZS1pZGxlIiwNCj4gPj4+ICsJCS5mbGFncyA9IENQVUlETEVfRkxB
R19USU1FX1ZBTElELA0KPiA+Pj4gKwkJLmV4aXRfbGF0ZW5jeSA9IDEsDQo+ID4+PiArCQkudGFy
Z2V0X3Jlc2lkZW5jeSA9IDUwLA0KPiA+Pj4gKwkJLmVudGVyID0gJnB3MjBfZW50ZXINCj4gPj4+
ICsJfSwNCj4gPj4+ICt9Ow0KPiA+Pg0KPiA+PiBObyBuZWVkIHRvIGRlZmluZSB0aGlzIGludGVy
bWVkaWF0ZSBzdHJ1Y3R1cmUgaGVyZSwgeW91IGNhbiBkaXJlY3RseQ0KPiA+PiBpbml0aWFsaXpl
IHRoZSBjcHVpZGxlX2RyaXZlcjoNCj4gPj4NCj4gPg0KPiA+IFRoYW5rcy4gOikNCj4gPg0KPiA+
Pj4gK3N0YXRpYyBpbnQgY3B1X2hvdHBsdWdfbm90aWZ5KHN0cnVjdCBub3RpZmllcl9ibG9jayAq
biwNCj4gPj4+ICsJCQl1bnNpZ25lZCBsb25nIGFjdGlvbiwgdm9pZCAqaGNwdSkgew0KPiA+Pj4g
Kwl1bnNpZ25lZCBsb25nIGhvdGNwdSA9ICh1bnNpZ25lZCBsb25nKWhjcHU7DQo+ID4+PiArCXN0
cnVjdCBjcHVpZGxlX2RldmljZSAqZGV2ID0NCj4gPj4+ICsJCQlwZXJfY3B1X3B0cihjcHVpZGxl
X2RldmljZXMsIGhvdGNwdSk7DQo+ID4+PiArDQo+ID4+PiArCWlmIChkZXYgJiYgY3B1aWRsZV9n
ZXRfZHJpdmVyKCkpIHsNCj4gPj4+ICsJCXN3aXRjaCAoYWN0aW9uKSB7DQo+ID4+PiArCQljYXNl
IENQVV9PTkxJTkU6DQo+ID4+PiArCQljYXNlIENQVV9PTkxJTkVfRlJPWkVOOg0KPiA+Pj4gKwkJ
CWNwdWlkbGVfcGF1c2VfYW5kX2xvY2soKTsNCj4gPj4+ICsJCQljcHVpZGxlX2VuYWJsZV9kZXZp
Y2UoZGV2KTsNCj4gPj4+ICsJCQljcHVpZGxlX3Jlc3VtZV9hbmRfdW5sb2NrKCk7DQo+ID4+PiAr
CQkJYnJlYWs7DQo+ID4+PiArDQo+ID4+PiArCQljYXNlIENQVV9ERUFEOg0KPiA+Pj4gKwkJY2Fz
ZSBDUFVfREVBRF9GUk9aRU46DQo+ID4+PiArCQkJY3B1aWRsZV9wYXVzZV9hbmRfbG9jaygpOw0K
PiA+Pj4gKwkJCWNwdWlkbGVfZGlzYWJsZV9kZXZpY2UoZGV2KTsNCj4gPj4+ICsJCQljcHVpZGxl
X3Jlc3VtZV9hbmRfdW5sb2NrKCk7DQo+ID4+PiArCQkJYnJlYWs7DQo+ID4+PiArDQo+ID4+PiAr
CQlkZWZhdWx0Og0KPiA+Pj4gKwkJCXJldHVybiBOT1RJRllfRE9ORTsNCj4gPj4+ICsJCX0NCj4g
Pj4+ICsJfQ0KPiA+Pj4gKw0KPiA+Pj4gKwlyZXR1cm4gTk9USUZZX09LOw0KPiA+Pj4gK30NCj4g
Pj4+ICsNCj4gPj4+ICtzdGF0aWMgc3RydWN0IG5vdGlmaWVyX2Jsb2NrIGNwdV9ob3RwbHVnX25v
dGlmaWVyID0gew0KPiA+Pj4gKwkubm90aWZpZXJfY2FsbCA9IGNwdV9ob3RwbHVnX25vdGlmeSwg
fTsNCj4gPj4NCj4gPj4gQ2FuIHlvdSBleHBsYWluIHdoeSB0aGlzIGlzIG5lZWRlZCA/DQo+ID4+
DQo+ID4NCj4gPiBJZiBhIGNwdSB3aWxsIGJlIHBsdWdnZWQgb3V0L2luLCBXZSBzaG91bGQgYmUg
bGV0IENwdWlkbGUga25vdyB0bw0KPiA+IHJlbW92ZSBjb3JyZXNwb25kaW5nIHN5cyBpbnRlcmZh
Y2UgYW5kIGRpc2FibGUvZW5hYmxlIGNwdWRpbGUtZ292ZXJub3IgZm9yDQo+IGN1cnJlbnQgY3B1
Lg0KPiANCj4gT2ssIHRoaXMgY29kZSBpcyBhIGNvcHktcGFzdGUgb2YgdGhlIHBvd2VycycgY3B1
aWRsZSBkcml2ZXIuDQo+IA0KPiBJSVJDLCBJIHBvc3RlZCBhIHBhdGNoc2V0IHRvIG1vdmUgdGhp
cyBwb3J0aW9uIG9mIGNvZGUgaW4gdGhlIGNwdWlkbGUgY29tbW9uDQo+IGZyYW1ld29yayBzb21l
IHRpbWUgYWdvLg0KPiANCj4gQ291bGQgeW91IHBsZWFzZSBnZXQgcmlkIG9mIHRoaXMgcGFydCBv
ZiBjb2RlID8NCj4gDQoNClllcywgSSBjYW4uIDopIENvdWxkIHlvdSBzaGFyZSBtZSB5b3VyIHBh
dGNoc2V0IGxpbms/IEkgY2FuJ3QgZm91bmQgdGhlbSBvbiB5b3VyIHRyZWUuDQoNClJlZ2FyZHMs
DQotRG9uZ3NoZW5nDQoNCj4gDQo+ID4+PiArCWVyciA9IHJlZ2lzdGVyX2NwdV9ub3RpZmllcigm
Y3B1X2hvdHBsdWdfbm90aWZpZXIpOw0KPiA+Pj4gKwlpZiAoZXJyKQ0KPiA+Pj4gKwkJcHJfd2Fy
bigiQ3B1aWRsZSBkcml2ZXI6IHJlZ2lzdGVyIGNwdSBub3RpZmllciBmYWlsZWQuXG4iKTsNCj4g
Pj4+ICsNCj4gPj4+ICsJLyogUmVwbGFjZSB0aGUgb3JpZ2luYWwgd2F5IG9mIGlkbGUgYWZ0ZXIg
Y3B1aWRsZSByZWdpc3RlcmVkLiAqLw0KPiA+Pj4gKwlwcGNfbWQucG93ZXJfc2F2ZSA9IGU1MDBf
Y3B1aWRsZTsNCj4gPj4+ICsJb25fZWFjaF9jcHUocmVwbGFjZV9vcmlnX2lkbGUsIE5VTEwsIDEp
Ow0KPiA+Pg0KPiA+PiBXaHkgPw0KPiA+Pg0KPiA+DQo+ID4gSSBjaGVja2VkIGFnYWluLCBpZiB3
ZSBwdXQgY3B1aWRsZV9pZGxlX2NhbGwgaW4gYXNtLCB0aGlzIGlzIG5vdCBuZWVkLg0KPiA+DQo+
ID4gUmVnYXJkcywNCj4gPiAtRG9uZ3NoZW5nDQo+ID4NCj4gPj4+ICsJcHJfaW5mbygiZTUwMF9p
ZGxlX2RyaXZlciByZWdpc3RlcmVkLlxuIik7DQo+ID4+PiArDQo+ID4+PiArCXJldHVybiAwOw0K
PiA+Pj4gK30NCj4gPj4+ICtsYXRlX2luaXRjYWxsKGU1MDBfaWRsZV9pbml0KTsNCj4gPj4+DQo+
ID4+DQo+ID4+IFRoYW5rcw0KPiA+Pg0KPiA+PiAgICAgLS0gRGFuaWVsDQo+ID4+DQo+ID4+DQo+
ID4+IC0tDQo+ID4+ICAgIDxodHRwOi8vd3d3LmxpbmFyby5vcmcvPiBMaW5hcm8ub3JnIOKUgiBP
cGVuIHNvdXJjZSBzb2Z0d2FyZSBmb3IgQVJNDQo+ID4+IFNvQ3MNCj4gPj4NCj4gPj4gRm9sbG93
IExpbmFybzogIDxodHRwOi8vd3d3LmZhY2Vib29rLmNvbS9wYWdlcy9MaW5hcm8+IEZhY2Vib29r
IHwNCj4gPj4gPGh0dHA6Ly90d2l0dGVyLmNvbS8jIS9saW5hcm9vcmc+IFR3aXR0ZXIgfA0KPiA+
PiA8aHR0cDovL3d3dy5saW5hcm8ub3JnL2xpbmFyby1ibG9nLz4gQmxvZw0KPiA+Pg0KPiA+Pg0K
PiA+DQo+IA0KPiANCj4gLS0NCj4gICA8aHR0cDovL3d3dy5saW5hcm8ub3JnLz4gTGluYXJvLm9y
ZyDilIIgT3BlbiBzb3VyY2Ugc29mdHdhcmUgZm9yIEFSTSBTb0NzDQo+IA0KPiBGb2xsb3cgTGlu
YXJvOiAgPGh0dHA6Ly93d3cuZmFjZWJvb2suY29tL3BhZ2VzL0xpbmFybz4gRmFjZWJvb2sgfA0K
PiA8aHR0cDovL3R3aXR0ZXIuY29tLyMhL2xpbmFyb29yZz4gVHdpdHRlciB8IDxodHRwOi8vd3d3
LmxpbmFyby5vcmcvbGluYXJvLWJsb2cvPg0KPiBCbG9nDQo+IA0KPiANCg0K
^ permalink raw reply
* Re: [PATCH 3/7] DMA: Freescale: add fsl_dma_free_descriptor() to reduce code duplication
From: Hongbo Zhang @ 2014-04-03 8:09 UTC (permalink / raw)
To: Vinod Koul
Cc: scottwood, dmaengine, dan.j.williams, linuxppc-dev, linux-kernel
In-Reply-To: <5334F022.3050402@freescale.com>
On 03/28/2014 11:44 AM, Hongbo Zhang wrote:
>
> On 03/11/2014 07:06 PM, Vinod Koul wrote:
>> On Thu, Jan 16, 2014 at 01:47:22PM +0800, hongbo.zhang@freescale.com
>> wrote:
>>> From: Hongbo Zhang <hongbo.zhang@freescale.com>
>>>
>>> There are several places where descriptors are freed using identical
>>> code.
>>> This patch puts this code into a function to reduce code duplication.
>>>
>>> Signed-off-by: Hongbo Zhang <hongbo.zhang@freescale.com>
>>> Signed-off-by: Qiang Liu <qiang.liu@freescale.com>
>>> ---
>>> drivers/dma/fsldma.c | 38 ++++++++++++++++++++------------------
>>> 1 file changed, 20 insertions(+), 18 deletions(-)
>>>
>>> diff --git a/drivers/dma/fsldma.c b/drivers/dma/fsldma.c
>>> index 95236e6..ad73538 100644
>>> --- a/drivers/dma/fsldma.c
>>> +++ b/drivers/dma/fsldma.c
>>> @@ -418,6 +418,21 @@ static dma_cookie_t fsl_dma_tx_submit(struct
>>> dma_async_tx_descriptor *tx)
>>> }
>>> /**
>>> + * fsl_dma_free_descriptor - Free descriptor from channel's DMA pool.
>>> + * @chan : Freescale DMA channel
>>> + * @desc: descriptor to be freed
>>> + */
>>> +static void fsl_dma_free_descriptor(struct fsldma_chan *chan,
>>> + struct fsl_desc_sw *desc)
>>> +{
>>> + list_del(&desc->node);
>>> +#ifdef FSL_DMA_LD_DEBUG
>>> + chan_dbg(chan, "LD %p free\n", desc);
>>> +#endif
>> why not wrap the define stuff in the defination of chan_dbg rather
>> than its
>> usage :(
>>
>
> OK, I will fix it by another separate patch.
> Thanks.
>
Think it again, I'd like to remove the FSL_DMA_LD_DEBUG usage, because
the chan_dbg is a wrapper of dev_dbg, we do have macro to switch on/off
dev_dbg, and most of other codes are calling chan_dbg directly without
FSL_DMA_LD_DEBUG, the FSL_DMA_LD_DEBUG only shows up 3 times unnecessarily.
>
>
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev@lists.ozlabs.org
> https://lists.ozlabs.org/listinfo/linuxppc-dev
^ permalink raw reply
* Re: [PATCH] cpuidle: add freescale e500 family porcessors idle support
From: Daniel Lezcano @ 2014-04-03 8:12 UTC (permalink / raw)
To: Dongsheng.Wang@freescale.com, Scott Wood
Cc: chenhui.zhao@freescale.com, linux-pm@vger.kernel.org,
rjw@rjwysocki.net, Jason.Jin@freescale.com,
linuxppc-dev@lists.ozlabs.org
In-Reply-To: <69cec4d810a448069df4d30bfc861ea5@BN1PR03MB188.namprd03.prod.outlook.com>
On 04/03/2014 10:03 AM, Dongsheng.Wang@freescale.com wrote:
>
>
>> -----Original Message-----
>> From: Daniel Lezcano [mailto:daniel.lezcano@linaro.org]
>> Sent: Thursday, April 03, 2014 2:29 PM
>> To: Wang Dongsheng-B40534; Wood Scott-B07421
>> Cc: rjw@rjwysocki.net; Li Yang-Leo-R58472; Jin Zhengxiong-R64188; Zhao Chenhui-
>> B35336; linux-pm@vger.kernel.org; linuxppc-dev@lists.ozlabs.org
>> Subject: Re: [PATCH] cpuidle: add freescale e500 family porcessors idle support
>>
>> On 04/03/2014 05:20 AM, Dongsheng.Wang@freescale.com wrote:
>>> Hi Daniel,
>>>
>>> Thanks for your review. I will fix your comments.
>>>
>>> BTW, fix Rafael's email. :)
>>>
>>>>> +#include <linux/cpu.h>
>>>>> +#include <linux/cpuidle.h>
>>>>> +#include <linux/init.h>
>>>>> +#include <linux/kernel.h>
>>>>> +#include <linux/notifier.h>
>>>>> +
>>>>> +#include <asm/cputable.h>
>>>>> +#include <asm/machdep.h>
>>>>> +#include <asm/mpc85xx.h>
>>>>> +
>>>>> +static unsigned int max_idle_state; static struct cpuidle_state
>>>>> +*cpuidle_state_table;
>>>>> +
>>>>> +struct cpuidle_driver e500_idle_driver = {
>>>>> + .name = "e500_idle",
>>>>> + .owner = THIS_MODULE,
>>>>> +};
>>>>> +
>>>>> +static void e500_cpuidle(void)
>>>>> +{
>>>>> + if (cpuidle_idle_call())
>>>>> + cpuidle_wait();
>>>>> +}
>>>>
>>>> Nope, that has been changed. No more call to cpuidle_idle_call in a driver.
>>>>
>>>
>>> Thanks.
>>>
>>>>> +
>>>>> +static int pw10_enter(struct cpuidle_device *dev,
>>>>> + struct cpuidle_driver *drv, int index) {
>>>>> + cpuidle_wait();
>>>>> + return index;
>>>>> +}
>>>>> +
>>>>> +#define MAX_BIT 63
>>>>> +#define MIN_BIT 1
>>>>> +extern u32 cpuidle_entry_bit;
>>>>> +static int pw20_enter(struct cpuidle_device *dev,
>>>>> + struct cpuidle_driver *drv, int index) {
>>>>> + u32 pw20_idle;
>>>>> + u32 entry_bit;
>>>>> + pw20_idle = mfspr(SPRN_PWRMGTCR0);
>>>>> + if ((pw20_idle & PWRMGTCR0_PW20_ENT) != PWRMGTCR0_PW20_ENT) {
>>>>> + pw20_idle &= ~PWRMGTCR0_PW20_ENT;
>>>>> + entry_bit = MAX_BIT - cpuidle_entry_bit;
>>>>> + pw20_idle |= (entry_bit << PWRMGTCR0_PW20_ENT_SHIFT);
>>>>> + mtspr(SPRN_PWRMGTCR0, pw20_idle);
>>>>> + }
>>>>> +
>>>>> + cpuidle_wait();
>>>>> +
>>>>> + pw20_idle &= ~PWRMGTCR0_PW20_ENT;
>>>>> + pw20_idle |= (MIN_BIT << PWRMGTCR0_PW20_ENT_SHIFT);
>>>>> + mtspr(SPRN_PWRMGTCR0, pw20_idle);
>>>>> +
>>>>> + return index;
>>>>> +}
>>>>
>>>> Is it possible to give some comments and encapsulate the code with
>>>> explicit function names to be implemented in an arch specific
>>>> directory file (eg. pm.c) and export these functions in a linux/
>>>> header ? We try to prevent to include asm if possible.
>>>>
>>>
>>> Yep, Looks better. Thanks.
>>>
>>>>> +
>>>>> +static struct cpuidle_state pw_idle_states[] = {
>>>>> + {
>>>>> + .name = "pw10",
>>>>> + .desc = "pw10",
>>>>> + .flags = CPUIDLE_FLAG_TIME_VALID,
>>>>> + .exit_latency = 0,
>>>>> + .target_residency = 0,
>>>>> + .enter = &pw10_enter
>>>>> + },
>>>>> +
>>>>> + {
>>>>> + .name = "pw20",
>>>>> + .desc = "pw20-core-idle",
>>>>> + .flags = CPUIDLE_FLAG_TIME_VALID,
>>>>> + .exit_latency = 1,
>>>>> + .target_residency = 50,
>>>>> + .enter = &pw20_enter
>>>>> + },
>>>>> +};
>>>>
>>>> No need to define this intermediate structure here, you can directly
>>>> initialize the cpuidle_driver:
>>>>
>>>
>>> Thanks. :)
>>>
>>>>> +static int cpu_hotplug_notify(struct notifier_block *n,
>>>>> + unsigned long action, void *hcpu) {
>>>>> + unsigned long hotcpu = (unsigned long)hcpu;
>>>>> + struct cpuidle_device *dev =
>>>>> + per_cpu_ptr(cpuidle_devices, hotcpu);
>>>>> +
>>>>> + if (dev && cpuidle_get_driver()) {
>>>>> + switch (action) {
>>>>> + case CPU_ONLINE:
>>>>> + case CPU_ONLINE_FROZEN:
>>>>> + cpuidle_pause_and_lock();
>>>>> + cpuidle_enable_device(dev);
>>>>> + cpuidle_resume_and_unlock();
>>>>> + break;
>>>>> +
>>>>> + case CPU_DEAD:
>>>>> + case CPU_DEAD_FROZEN:
>>>>> + cpuidle_pause_and_lock();
>>>>> + cpuidle_disable_device(dev);
>>>>> + cpuidle_resume_and_unlock();
>>>>> + break;
>>>>> +
>>>>> + default:
>>>>> + return NOTIFY_DONE;
>>>>> + }
>>>>> + }
>>>>> +
>>>>> + return NOTIFY_OK;
>>>>> +}
>>>>> +
>>>>> +static struct notifier_block cpu_hotplug_notifier = {
>>>>> + .notifier_call = cpu_hotplug_notify, };
>>>>
>>>> Can you explain why this is needed ?
>>>>
>>>
>>> If a cpu will be plugged out/in, We should be let Cpuidle know to
>>> remove corresponding sys interface and disable/enable cpudile-governor for
>> current cpu.
>>
>> Ok, this code is a copy-paste of the powers' cpuidle driver.
>>
>> IIRC, I posted a patchset to move this portion of code in the cpuidle common
>> framework some time ago.
>>
>> Could you please get rid of this part of code ?
>>
>
> Yes, I can. :) Could you share me your patchset link? I can't found them on your tree.
>
It was a while ago. I should have it somewhere locally. I will find it
out and resend the patch next week when finishing my current task.
-- Daniel
>> --
>> <http://www.linaro.org/> Linaro.org │ Open source software for ARM SoCs
>>
>> Follow Linaro: <http://www.facebook.com/pages/Linaro> Facebook |
>> <http://twitter.com/#!/linaroorg> Twitter | <http://www.linaro.org/linaro-blog/>
>> Blog
>>
>>
>
--
<http://www.linaro.org/> Linaro.org │ Open source software for ARM SoCs
Follow Linaro: <http://www.facebook.com/pages/Linaro> Facebook |
<http://twitter.com/#!/linaroorg> Twitter |
<http://www.linaro.org/linaro-blog/> Blog
^ permalink raw reply
* Re: [PATCH] power, sched: stop updating inside arch_update_cpu_topology() when nothing to be update
From: Srivatsa S. Bhat @ 2014-04-03 8:50 UTC (permalink / raw)
To: Michael wang
Cc: sfr, Srikar Dronamraju, LKML, jlarrew, paulus, alistair, nfont,
Andrew Morton, rcj, linuxppc-dev
In-Reply-To: <533B8431.8090507@linux.vnet.ibm.com>
On 04/02/2014 08:59 AM, Michael wang wrote:
> During the testing, we encounter below WARN followed by Oops:
>
> WARNING: at kernel/sched/core.c:6218
> ...
> NIP [c000000000101660] .build_sched_domains+0x11d0/0x1200
> LR [c000000000101358] .build_sched_domains+0xec8/0x1200
> PACATMSCRATCH [800000000000f032]
> Call Trace:
> [c00000001b103850] [c000000000101358] .build_sched_domains+0xec8/0x1200
> [c00000001b1039a0] [c00000000010aad4] .partition_sched_domains+0x484/0x510
> [c00000001b103aa0] [c00000000016d0a8] .rebuild_sched_domains+0x68/0xa0
> [c00000001b103b30] [c00000000005cbf0] .topology_work_fn+0x10/0x30
> ...
> Oops: Kernel access of bad area, sig: 11 [#1]
> ...
> NIP [c00000000045c000] .__bitmap_weight+0x60/0xf0
> LR [c00000000010132c] .build_sched_domains+0xe9c/0x1200
> PACATMSCRATCH [8000000000029032]
> Call Trace:
> [c00000001b1037a0] [c000000000288ff4] .kmem_cache_alloc_node_trace+0x184/0x3a0
> [c00000001b103850] [c00000000010132c] .build_sched_domains+0xe9c/0x1200
> [c00000001b1039a0] [c00000000010aad4] .partition_sched_domains+0x484/0x510
> [c00000001b103aa0] [c00000000016d0a8] .rebuild_sched_domains+0x68/0xa0
> [c00000001b103b30] [c00000000005cbf0] .topology_work_fn+0x10/0x30
> ...
>
> This was caused by that 'sd->groups == NULL' after building groups, which
> was caused by the empty 'sd->span'.
>
> The cpu's domain contain nothing because the cpu was assigned to wrong
> node inside arch_update_cpu_topology() by calling update_lookup_table()
> with the uninitialized param, in the case when there is nothing to be
> update.
>
I think we need to verify this theory. Here are my thoughts:
If we get a topology update notification from the hypervisor, and then the
update happens to be nothing new (as in, new_node == old_node for the given
cpu), then updated_cpus mask will not have any cpus set in it (like you noted
below). In that scenario, the following sequence will take place:
Inside arch_cpu_update_topology(), the 'updates' has been kzalloc()'ed.
So updates[0] will have all its fields set to 0, such as ->cpu, ->new_nid etc.
When we invoke stop_machine() the first time like this:
stop_machine(update_cpu_topology, &updates[0], &updated_cpus);
stop-machine will notice that updated_cpus mask does not have any cpus set
in it, so it will nominate cpumask_first(cpu_online_mask) to run the
update_cpu_topology() function, which means that CPU0 will run it.
So, when CPU0 runs update_cpu_topology(), it will find that cpu == update->cpu
since both are 0, and will invoke unmap_cpu_from_node() and then calls
map_cpu_to_node(), with update->new_nid == 0.
Now, the interesting thing to note here is that, if CPU0's node was already
set as node0, *nothing* should go wrong, since its just a redundant update.
However, if CPU0's original node mapping was something different, or if
node0 doesn't even exist in the machine, then the system can crash.
Have you verified that CPU0's node mapping is different from node 0?
That is, boot the kernel with "numa=debug" in the kernel command line and
it will print out the cpu-to-node associativity during boot. That way you
can figure out what was the original associativity that was set. This will
confirm the theory that the hypervisor sent a redundant update, but because
of the weird pre-allocation using kzalloc that we do inside
arch_update_cpu_topology(), we wrongly updated CPU0's mapping as CPU0 <-> Node0.
Regards,
Srivatsa S. Bhat
> Thus we should stop the updating in such cases, this patch will achieve
> this and fix the issue.
>
> CC: Benjamin Herrenschmidt <benh@kernel.crashing.org>
> CC: Paul Mackerras <paulus@samba.org>
> CC: Nathan Fontenot <nfont@linux.vnet.ibm.com>
> CC: Stephen Rothwell <sfr@canb.auug.org.au>
> CC: Andrew Morton <akpm@linux-foundation.org>
> CC: Robert Jennings <rcj@linux.vnet.ibm.com>
> CC: Jesse Larrew <jlarrew@linux.vnet.ibm.com>
> CC: "Srivatsa S. Bhat" <srivatsa.bhat@linux.vnet.ibm.com>
> CC: Alistair Popple <alistair@popple.id.au>
> Signed-off-by: Michael Wang <wangyun@linux.vnet.ibm.com>
> ---
> arch/powerpc/mm/numa.c | 9 +++++++++
> 1 file changed, 9 insertions(+)
>
> diff --git a/arch/powerpc/mm/numa.c b/arch/powerpc/mm/numa.c
> index 30a42e2..6757690 100644
> --- a/arch/powerpc/mm/numa.c
> +++ b/arch/powerpc/mm/numa.c
> @@ -1591,6 +1591,14 @@ int arch_update_cpu_topology(void)
> cpu = cpu_last_thread_sibling(cpu);
> }
>
> + /*
> + * The 'cpu_associativity_changes_mask' could be cleared if
> + * all the cpus it indicates won't change their node, in
> + * which case the 'updated_cpus' will be empty.
> + */
> + if (!cpumask_weight(&updated_cpus))
> + goto out;
> +
> stop_machine(update_cpu_topology, &updates[0], &updated_cpus);
>
> /*
> @@ -1612,6 +1620,7 @@ int arch_update_cpu_topology(void)
> changed = 1;
> }
>
> +out:
> kfree(updates);
> return changed;
> }
>
^ permalink raw reply
* Re: on kernel 2.6.34.15, vlan and raw packets can not be received with gfar-enet nic
From: zhuyj @ 2014-04-03 9:11 UTC (permalink / raw)
To: sandeep.kumar, netdev, linux-kernel, Tao, Yue,
Yang, Zhangle (Eric), guang.yang, joe, festevam, linuxppc-dev,
richardcochran, clarocq, yongjun_wei, Claudiu Manoil, w, zhuyj
In-Reply-To: <53310F4E.4080104@gmail.com>
[-- Attachment #1: Type: text/plain, Size: 4932 bytes --]
Hi, Claudiu
Please help to review this patch. This patch is for kernel 2.6.x. Thanks
a lot.
Hi, Willy
Please help to merge this patch to longterm: 2.6.32.61 since this
problem also occurs on this kernel. Thanks a lot.
Based on kernel 2.6.x, gianfar nic driver can not work well. The root
cause is that tx vlan of gianfar can not handle VLAN tag 0. So on kernel
3.0+, this tx vlan feature is disabled. But on kernel 2.6.x, this
feature is still enabled. This patch will disable this feature of
gianfar nic driver. If this feature is enabled, gianfar nic can not
support vlan packets and non-vlan packets at the same time. The
following steps will reproduce this problem.
The steps are as below.
1. boot two freescale-p2020 boards with linux kernel 2.6.x, then
connected 2 gfar-enet nic cards with a direct network line;
2. On board 1, checked the driver of eth0
ethtool -i eth0
driver: gfar-enet
version: 1.3
firmware-version: N/A
bus-info: N/A
On board 2, I checked the driver of eth1
ethtool -i eth1
driver: gfar-enet
version: 1.3
firmware-version: N/A
bus-info: N/A
3. Then configure the ip address on the above 2 nic cards.
On board 1,
ifconfig eth0 192.168.1.13/24 up
On board 2,
ifconfig eth1 192.168.1.196/24 up
4. We can access the other board on one board.
For example, on board 1, we can ping board 2.
root@p2020rdb:/root> ping 192.168.1.196
PING 192.168.1.196 (192.168.1.196) 56(84) bytes of data.
64 bytes from 192.168.1.196: icmp_req=1 ttl=64 time=2.92 ms
64 bytes from 192.168.1.196: icmp_req=2 ttl=64 time=0.096 ms
5. We configure vlan on these 2 boards. VLAN tag 0
On board 1,
modprobe 8021q
vconfig add eth0 4091
ifconfig eth0.4091 10.1.1.13/24 up
On board 2,
modprobe 8021q
vconfig add eth1 4091
ifconfig eth1.4091 10.1.1.196/24 up
6. We can access the other board on one board through vlan.
For example, on board 1, we can ping board 2 through vlan nic.
root@p2020rdb:/root> ping 10.1.1.196
PING 10.1.1.196 (10.1.1.196) 56(84) bytes of data.
64 bytes from 10.1.1.196: icmp_req=1 ttl=64 time=2.92 ms
64 bytes from 10.1.1.196: icmp_req=2 ttl=64 time=0.096 ms
But we can not access the other board on one board through raw nic.
For example, on board, we can not ping board 2.
root@p2020rdb:/root> ping 192.168.1.196
From 192.168.1.196 icmp_seq=1 Destination Host Unreachable
From 192.168.1.196 icmp_seq=2 Destination Host Unreachable
From 192.168.1.196 icmp_seq=3 Destination Host Unreachable
Best Regards!
Zhu Yanjun
On 03/25/2014 01:08 PM, zhuyj wrote:
> Hi, Sandeep Gopalpet
>
> I am a developer. Now I confronted an interesting phenomena. When I
> used linux kernel 2.6.34.15 on freescale-p2020, I can not receive raw
> and vlan packets on gfar-enet nic. But with e1000e nic, we can make
> vlan and raw packets work well. I looked into the source code and find
> that maybe it is related with hardware insert and remove vlan head.
> But I have no the specifications of gfar-enet nic. Would you like to
> give some document or some guides?
>
> Thanks a lot.
> Zhu Yanjun
>
> The steps are as below.
>
> 1. I boot two freescale-p2020 boards with linux kernel 2.6.34.15, then
> I connected 2 gfar-enet nic cards with a direct network line;
>
> 2. On board 1, I checked the driver of eth0
>
> ethtool -i eth0
>
> driver: gfar-enet
> version: 1.3
> firmware-version: N/A
> bus-info: N/A
>
> On board 2, I checked the driver of eth1
>
> ethtool -i eth1
>
> driver: gfar-enet
> version: 1.3
> firmware-version: N/A
> bus-info: N/A
>
> 3. Then I configure the ip address on the above 2 nic cards.
>
> On board 1,
>
> ifconfig eth0 192.168.1.13/24 up
>
> On board 2,
>
> ifconfig eth1 192.168.1.196/24 up
>
> 4. We can access the other board on one board.
> For example, on board 1, we can ping board 2.
>
> root@p2020rdb:/root> ping 192.168.1.196
> PING 192.168.1.196 (192.168.1.196) 56(84) bytes of data.
> 64 bytes from 192.168.1.196: icmp_req=1 ttl=64 time=2.92 ms
> 64 bytes from 192.168.1.196: icmp_req=2 ttl=64 time=0.096 ms
>
> 5. We configure vlan on these 2 boards. VLAN tag 0
> On board 1,
>
> modprobe 8021q
> vconfig add eth0 4091
> ifconfig eth0.4091 10.1.1.13/24 up
>
> On board 2,
>
> modprobe 8021q
> vconfig add eth1 4091
> ifconfig eth1.4091 10.1.1.196/24 up
>
> 6. We can access the other board on one board through vlan.
> For example, on board 1, we can ping board 2 through vlan nic.
>
> root@p2020rdb:/root> ping 10.1.1.196
> PING 10.1.1.196 (10.1.1.196) 56(84) bytes of data.
> 64 bytes from 10.1.1.196: icmp_req=1 ttl=64 time=2.92 ms
> 64 bytes from 10.1.1.196: icmp_req=2 ttl=64 time=0.096 ms
>
> But we can not access the other board on one board through raw nic.
> For example, on board, we can not ping board 2.
>
> root@p2020rdb:/root> ping 192.168.1.196
> From 192.168.1.196 icmp_seq=1 Destination Host Unreachable
> From 192.168.1.196 icmp_seq=2 Destination Host Unreachable
> From 192.168.1.196 icmp_seq=3 Destination Host Unreachable
>
>
[-- Attachment #2: 0001-gianfar-disable-TX-vlan-based-on-kernel-2.6.x.patch --]
[-- Type: text/x-patch, Size: 1491 bytes --]
>From afd48fa3ad5b15d519adeb19b2a9c00051327c68 Mon Sep 17 00:00:00 2001
From: Zhu Yanjun <Yanjun.Zhu@windriver.com>
Date: Thu, 3 Apr 2014 16:41:13 +0800
Subject: [PATCH 1/1] gianfar: disable TX vlan based on kernel 2.6.x
Since there is something wrong with tx vlan of gianfar nic driver,
on kernel(3.0+), tx vlan is disabled. But on kernel 2.6.x, tx vlan
is still enabled. Thus,gianfar nic driver can not support vlan
packets and non-vlan packets.
Signed-off-by: Zhu Yanjun <Yanjun.Zhu@windriver.com>
---
drivers/net/gianfar.c | 8 +-------
1 file changed, 1 insertion(+), 7 deletions(-)
diff --git a/drivers/net/gianfar.c b/drivers/net/gianfar.c
index 934a28f..8aa2cf6 100644
--- a/drivers/net/gianfar.c
+++ b/drivers/net/gianfar.c
@@ -365,7 +365,7 @@ static int gfar_probe(struct of_device *ofdev,
priv->vlgrp = NULL;
if (priv->device_flags & FSL_GIANFAR_DEV_HAS_VLAN)
- dev->features |= NETIF_F_HW_VLAN_TX | NETIF_F_HW_VLAN_RX;
+ dev->features |= NETIF_F_HW_VLAN_RX;
if (priv->device_flags & FSL_GIANFAR_DEV_HAS_EXTENDED_HASH) {
priv->extended_hash = 1;
@@ -1451,12 +1451,6 @@ static void gfar_vlan_rx_register(struct net_device *dev,
priv->vlgrp = grp;
if (grp) {
- /* Enable VLAN tag insertion */
- tempval = gfar_read(&priv->regs->tctrl);
- tempval |= TCTRL_VLINS;
-
- gfar_write(&priv->regs->tctrl, tempval);
-
/* Enable VLAN tag extraction */
tempval = gfar_read(&priv->regs->rctrl);
tempval |= (RCTRL_VLEX | RCTRL_PRSDEP_INIT);
--
1.7.9.5
^ permalink raw reply related
* Re: on kernel 2.6.34.15, vlan and raw packets can not be received with gfar-enet nic
From: Willy Tarreau @ 2014-04-03 9:27 UTC (permalink / raw)
To: zhuyj
Cc: Yang, Zhangle (Eric), netdev, richardcochran, linuxppc-dev,
guang.yang, linux-kernel, yongjun_wei, sandeep.kumar,
Claudiu Manoil, Tao, Yue, joe, festevam, clarocq
In-Reply-To: <533D25D4.4000607@gmail.com>
Hi Zhu,
On Thu, Apr 03, 2014 at 05:11:48PM +0800, zhuyj wrote:
> Hi, Claudiu
>
> Please help to review this patch. This patch is for kernel 2.6.x. Thanks
> a lot.
>
> Hi, Willy
>
> Please help to merge this patch to longterm: 2.6.32.61 since this
> problem also occurs on this kernel. Thanks a lot.
Could you please send the reference to the equivalent mainline commit (the one
which disables the tx vlan feature I'm assuming) ? I'll happily queue it for
2.6.32.62.
Thanks,
Willy
^ permalink raw reply
* Re: on kernel 2.6.34.15, vlan and raw packets can not be received with gfar-enet nic
From: zhuyj @ 2014-04-03 9:57 UTC (permalink / raw)
To: Willy Tarreau
Cc: Yang, Zhangle (Eric), netdev, richardcochran, linuxppc-dev,
guang.yang, linux-kernel, yongjun_wei, sandeep.kumar,
Claudiu Manoil, Tao, Yue, joe, festevam, clarocq
In-Reply-To: <20140403092727.GD16158@1wt.eu>
On 04/03/2014 05:27 PM, Willy Tarreau wrote:
> Hi Zhu,
>
> On Thu, Apr 03, 2014 at 05:11:48PM +0800, zhuyj wrote:
>> Hi, Claudiu
>>
>> Please help to review this patch. This patch is for kernel 2.6.x. Thanks
>> a lot.
>>
>> Hi, Willy
>>
>> Please help to merge this patch to longterm: 2.6.32.61 since this
>> problem also occurs on this kernel. Thanks a lot.
> Could you please send the reference to the equivalent mainline commit (the one
> which disables the tx vlan feature I'm assuming) ? I'll happily queue it for
> 2.6.32.62.
>
> Thanks,
> Willy
>
>
Hi, Willy
I reference the following 2 mainline commits. These 2 commits are based
on the current kernel 3.x and ethtool.
If we only backport these 2 commits on kernel 2.6.x, this problem will
not be fixed yet.
Best Regards!
Zhu Yanjun
1. commit 87c288c6e9aa31720b72e2bc2d665e24e1653c3e
Author: Jiri Pirko <jpirko@redhat.com>
Date: Wed Jul 20 04:54:19 2011 +0000
gianfar: do vlan cleanup
- unify vlan and nonvlan rx path
- kill priv->vlgrp and gfar_vlan_rx_register
- allow to turn on/off rx/tx vlan accel via ethtool
Signed-off-by: Jiri Pirko <jpirko@redhat.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
drivers/net/gianfar.c | 55
++++++++++++++++++++++++++-----------------------
1 file changed, 29 insertions(+), 26 deletions(-)
2.commit b852b720877e6b8e12b95a7cb4e00ea351b8cbfc
Author: Sebastian Pöhn <sebastian.belden@googlemail.com>
Date: Tue Jul 26 00:03:13 2011 +0000
gianfar: fix bug caused by 87c288c6e9aa31720b72e2bc2d665e24e1653c3e
commit 87c288c6e9aa31720b72e2bc2d665e24e1653c3e "gianfar: do vlan
cleanup" has two issues:
# permutation of rx and tx flags
# enabling vlan tag insertion by default (this leads to unusable
connections on some configurations)
If VLAN insertion is requested (via ethtool) it will be set at an
other point ...
Signed-off-by: Sebastian Poehn <sebastian.poehn@belden.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
drivers/net/gianfar.c | 6 +-----
1 file changed, 1 insertion(+), 5 deletions(-)
^ permalink raw reply
* Re: on kernel 2.6.34.15, vlan and raw packets can not be received with gfar-enet nic
From: Willy Tarreau @ 2014-04-03 10:01 UTC (permalink / raw)
To: zhuyj
Cc: Yang, Zhangle (Eric), netdev, richardcochran, linuxppc-dev,
guang.yang, linux-kernel, yongjun_wei, sandeep.kumar,
Claudiu Manoil, Tao, Yue, joe, festevam, clarocq
In-Reply-To: <533D30A1.1060509@gmail.com>
Hi Zhu,
On Thu, Apr 03, 2014 at 05:57:53PM +0800, zhuyj wrote:
> I reference the following 2 mainline commits. These 2 commits are based
> on the current kernel 3.x and ethtool.
> If we only backport these 2 commits on kernel 2.6.x, this problem will
> not be fixed yet.
OK fine, I just wanted that we keep the reference of these equivalent
patches in the commit message so that if later a newer patch changes
anything they did, at least we have some indications that the commit
might also have to be revisited.
I'll merge your patch and put these references there.
Thanks,
Willy
^ permalink raw reply
* Re: on kernel 2.6.34.15, vlan and raw packets can not be received with gfar-enet nic
From: zhuyj @ 2014-04-03 10:15 UTC (permalink / raw)
To: Willy Tarreau
Cc: Yang, Zhangle (Eric), netdev, richardcochran, linuxppc-dev,
guang.yang, linux-kernel, yongjun_wei, zhuyj, sandeep.kumar,
Claudiu Manoil, Tao, Yue, joe, festevam, clarocq
In-Reply-To: <20140403092727.GD16158@1wt.eu>
[-- Attachment #1: Type: text/plain, Size: 808 bytes --]
On 04/03/2014 05:27 PM, Willy Tarreau wrote:
> Hi Zhu,
>
> On Thu, Apr 03, 2014 at 05:11:48PM +0800, zhuyj wrote:
>> Hi, Claudiu
>>
>> Please help to review this patch. This patch is for kernel 2.6.x. Thanks
>> a lot.
>>
>> Hi, Willy
>>
>> Please help to merge this patch to longterm: 2.6.32.61 since this
>> problem also occurs on this kernel. Thanks a lot.
> Could you please send the reference to the equivalent mainline commit (the one
> which disables the tx vlan feature I'm assuming) ? I'll happily queue it for
> 2.6.32.62.
>
> Thanks,
> Willy
>
>
Hi, Willy
I made a new patch. In long commit message, I inserted the equivalent
mainline commit
about this feature. Maybe it is better. Now this patch is in the
attachment. Please check
and merge it into kernel 2.6.32.62.
Thanks a lot.
Zhu Yanjun
[-- Attachment #2: 0001-gianfar-disable-TX-vlan-based-on-kernel-2.6.x.patch --]
[-- Type: text/x-patch, Size: 1688 bytes --]
>From 3b74ad6134f8eccce9ee391fb02ff15863630c1b Mon Sep 17 00:00:00 2001
From: Zhu Yanjun <Yanjun.Zhu@windriver.com>
Date: Thu, 3 Apr 2014 16:41:13 +0800
Subject: [PATCH 1/1] gianfar: disable TX vlan based on kernel 2.6.x
2.6.x kernels require a similar logic change as commit e1653c3e
[gianfar: do vlan cleanup] and commit 51b8cbfc
[gianfar: fix bug caused by e1653c3e] introduces for newer kernels.
Since there is something wrong with tx vlan of gianfar nic driver,
in kernel(3.1+), tx vlan is disabled. But in kernel 2.6.x, tx vlan
is still enabled. Thus,gianfar nic driver can not support vlan
packets and non-vlan packets at the same time.
Signed-off-by: Zhu Yanjun <Yanjun.Zhu@windriver.com>
---
drivers/net/gianfar.c | 8 +-------
1 file changed, 1 insertion(+), 7 deletions(-)
diff --git a/drivers/net/gianfar.c b/drivers/net/gianfar.c
index 934a28f..8aa2cf6 100644
--- a/drivers/net/gianfar.c
+++ b/drivers/net/gianfar.c
@@ -365,7 +365,7 @@ static int gfar_probe(struct of_device *ofdev,
priv->vlgrp = NULL;
if (priv->device_flags & FSL_GIANFAR_DEV_HAS_VLAN)
- dev->features |= NETIF_F_HW_VLAN_TX | NETIF_F_HW_VLAN_RX;
+ dev->features |= NETIF_F_HW_VLAN_RX;
if (priv->device_flags & FSL_GIANFAR_DEV_HAS_EXTENDED_HASH) {
priv->extended_hash = 1;
@@ -1451,12 +1451,6 @@ static void gfar_vlan_rx_register(struct net_device *dev,
priv->vlgrp = grp;
if (grp) {
- /* Enable VLAN tag insertion */
- tempval = gfar_read(&priv->regs->tctrl);
- tempval |= TCTRL_VLINS;
-
- gfar_write(&priv->regs->tctrl, tempval);
-
/* Enable VLAN tag extraction */
tempval = gfar_read(&priv->regs->rctrl);
tempval |= (RCTRL_VLEX | RCTRL_PRSDEP_INIT);
--
1.7.9.5
^ permalink raw reply related
* Re: on kernel 2.6.34.15, vlan and raw packets can not be received with gfar-enet nic
From: zhuyj @ 2014-04-03 10:18 UTC (permalink / raw)
To: Willy Tarreau
Cc: Yang, Zhangle (Eric), netdev, richardcochran, linuxppc-dev,
guang.yang, linux-kernel, yongjun_wei, zhuyj, sandeep.kumar,
Claudiu Manoil, Tao, Yue, joe, festevam, clarocq
In-Reply-To: <20140403100128.GE16158@1wt.eu>
On 04/03/2014 06:01 PM, Willy Tarreau wrote:
> Hi Zhu,
>
> On Thu, Apr 03, 2014 at 05:57:53PM +0800, zhuyj wrote:
>> I reference the following 2 mainline commits. These 2 commits are based
>> on the current kernel 3.x and ethtool.
>> If we only backport these 2 commits on kernel 2.6.x, this problem will
>> not be fixed yet.
> OK fine, I just wanted that we keep the reference of these equivalent
> patches in the commit message so that if later a newer patch changes
> anything they did, at least we have some indications that the commit
> might also have to be revisited.
>
> I'll merge your patch and put these references there.
>
> Thanks,
> Willy
OK. Thanks a lot.
Zhu Yanjun
> .
>
^ permalink raw reply
* Re: on kernel 2.6.34.15, vlan and raw packets can not be received with gfar-enet nic
From: Willy Tarreau @ 2014-04-03 10:21 UTC (permalink / raw)
To: zhuyj
Cc: Yang, Zhangle (Eric), netdev, richardcochran, linuxppc-dev,
guang.yang, linux-kernel, yongjun_wei, sandeep.kumar,
Claudiu Manoil, Tao, Yue, joe, festevam, clarocq
In-Reply-To: <533D34BD.900@gmail.com>
On Thu, Apr 03, 2014 at 06:15:25PM +0800, zhuyj wrote:
> Hi, Willy
>
> I made a new patch. In long commit message, I inserted the equivalent
> mainline commit
> about this feature. Maybe it is better. Now this patch is in the
> attachment. Please check
> and merge it into kernel 2.6.32.62.
Sure, it's much better this way.
Thanks!
Willy
^ permalink raw reply
* Re: [PATCH RFC v10 0/6] MPC512x DMA slave s/g support, OF DMA lookup
From: Alexander Popov @ 2014-04-03 10:59 UTC (permalink / raw)
To: Gerhard Sittig, Dan Williams, Vinod Koul, Lars-Peter Clausen,
Arnd Bergmann, Anatolij Gustschin, Andy Shevchenko,
Alexander Popov, linuxppc-dev, dmaengine
Cc: devicetree
In-Reply-To: <1395326878-25243-1-git-send-email-a13xp0p0v88@gmail.com>
Hello,
2014-03-20 18:47 GMT+04:00 Alexander Popov <a13xp0p0v88@gmail.com>:
> Changes in v10:
> Part 2/6:
> - don't use direction field of dma_slave_config in mpc_dma_device_control()
> but store settings in mpc_dma_chan for both DMA_DEV_TO_MEM and
> DMA_MEM_TO_DEV cases; then retrieve the needed values in
> mpc_dma_prep_slave_sg();
> - fix style issue and put 2014 instead of 2013;
> Part 3/6:
> - fix mpc_dma_probe() error path and mpc_dma_remove(): manually free IRQs and
> dispose IRQ mappings before devm_* takes care of other resources;
> Part 6/6:
> - change according the new part 3/6;
> - fix style issue;
Excuse me, could I have a feedback?
Thanks!
> Alexander Popov (5):
> dma: mpc512x: reorder mpc8308 specific instructions
> dma: mpc512x: add support for peripheral transfers
> dma: mpc512x: fix freeing resources in mpc_dma_probe() and
> mpc_dma_remove()
> dma: of: Add common xlate function for matching by channel id
> dma: mpc512x: register for device tree channel lookup
>
> Gerhard Sittig (1):
> dma: mpc512x: add device tree binding document
>
> .../devicetree/bindings/dma/mpc512x-dma.txt | 55 ++++
> arch/powerpc/boot/dts/mpc5121.dtsi | 1 +
> drivers/dma/mpc512x_dma.c | 345 ++++++++++++++++++---
> drivers/dma/of-dma.c | 35 +++
> include/linux/of_dma.h | 4 +
> 5 files changed, 402 insertions(+), 38 deletions(-)
> create mode 100644 Documentation/devicetree/bindings/dma/mpc512x-dma.txt
>
> --
> 1.8.4.2
Best regards,
Alexander
^ permalink raw reply
* Re: [PATCH v2] powernv: kvm: make _PAGE_NUMA take effect
From: Alexander Graf @ 2014-04-03 11:36 UTC (permalink / raw)
To: Liu ping fan, Alexander Graf
Cc: kvm-devel, kvm-ppc, Paul Mackerras, Aneesh Kumar K.V,
linuxppc-dev
In-Reply-To: <CAFgQCTs8LSXUi+AwxR9j+2-QRGw4EFZWx-JxktAnJ3VvwLJb9A@mail.gmail.com>
On 03.04.14 04:36, Liu ping fan wrote:
> Hi Alex, could you help to pick up this patch? since v3.14 kernel can
> enable numa fault for powerpc.
What bad happens without this patch? We map a page even though it was
declared to get NUMA migrated? What happens next?
I'm trying to figure out whether I need to mark this with a stable tag
for 3.14.
Alex
^ permalink raw reply
* Re: [PATCH v2] powernv: kvm: make _PAGE_NUMA take effect
From: Alexander Graf @ 2014-04-03 11:38 UTC (permalink / raw)
To: Liu ping fan, Alexander Graf
Cc: kvm-devel, kvm-ppc, Paul Mackerras, Aneesh Kumar K.V,
linuxppc-dev
In-Reply-To: <533D47CD.906@suse.com>
On 03.04.14 13:36, Alexander Graf wrote:
>
> On 03.04.14 04:36, Liu ping fan wrote:
>> Hi Alex, could you help to pick up this patch? since v3.14 kernel can
>> enable numa fault for powerpc.
>
> What bad happens without this patch? We map a page even though it was
> declared to get NUMA migrated? What happens next?
>
> I'm trying to figure out whether I need to mark this with a stable tag
> for 3.14.
Also, what about the other uses of pre_present()?
Alex
^ permalink raw reply
* Re: [PATCH v2] powernv: kvm: make _PAGE_NUMA take effect
From: Alexander Graf @ 2014-04-03 11:43 UTC (permalink / raw)
To: Liu ping fan, Alexander Graf
Cc: kvm-devel, kvm-ppc, Paul Mackerras, Aneesh Kumar K.V,
linuxppc-dev
In-Reply-To: <533D4834.7050306@suse.com>
On 03.04.14 13:38, Alexander Graf wrote:
>
> On 03.04.14 13:36, Alexander Graf wrote:
>>
>> On 03.04.14 04:36, Liu ping fan wrote:
>>> Hi Alex, could you help to pick up this patch? since v3.14 kernel can
>>> enable numa fault for powerpc.
>>
>> What bad happens without this patch? We map a page even though it was
>> declared to get NUMA migrated? What happens next?
>>
>> I'm trying to figure out whether I need to mark this with a stable
>> tag for 3.14.
>
> Also, what about the other uses of pre_present()?
Oh how I love to reply to myself. The patch doesn't apply to the latest
code anymore either. Also please rework the wording of your patch
subject and patch description to explain the actual problem at hand.
Alex
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox