* RE: Problem in getting shared memory access on P1022RDK
From: Arshad, Farrukh @ 2012-01-04 9:56 UTC (permalink / raw)
To: Scott Wood; +Cc: linuxppc-dev@lists.ozlabs.org
In-Reply-To: <4F033685.6000509@freescale.com>
Some of the other things which I am experiencing which may help to trace th=
is issue.=20
1: For Core 0 printk is not working in setup_arch "just before call to pagi=
ng_init", where as on Core 1 printk is working in the same function. I see =
the source uses ppc_md.progress to display debug messages so it seems print=
k will not work then why it is working on Core 1.=20
2: During kernel boot of both cores boot messages of Core 0 are mixed in Co=
re 1 messages.=20
3: If I change memory partitioning to following, then on Core 1 when I mmap=
shared memory area (starting 0x0C00,0000) I receive error that can not mma=
p RAM. If my both systems memory partitions are defined clearly then this a=
rea does not belong to system RAM then I shouldn't receive this error in th=
is memory partitioning.
Core Base Address Size
Core 0 0x0000,0000 0x0C00,0000 --> CONFIG_PHYSICAL_START =3D bootm_low =
=3D Base Address
Shared Mem 0x0C00,0000 0x0400,0000
Core 1 0x1000,0000 0x1000,0000 --> CONFIG_PHYSICAL_START =3D bootm_low =
=3D Base Address
I believe there is some bug / or patch which I am missing in both kernels m=
emory initialization which is causing all these issues. Kernel sources / co=
nfiguration of both cores are 100% same except (CONFIG_PHYSICAL_START) para=
m and kernel version is 2.6.32.13.=20
Any thoughts.
Regards,
Farrukh Arshad
-----Original Message-----
From: Arshad, Farrukh=20
Sent: Wednesday, January 04, 2012 11:50 AM
To: 'Scott Wood'
Cc: linuxppc-dev@lists.ozlabs.org
Subject: RE: Problem in getting shared memory access on P1022RDK
How can I verify if the memory mapped is coherent on both cores. My memory =
partitioning is given below
Core Base Address Size
Core 0 0x0000,0000 0x1000,0000 --> CONFIG_PHYSICAL_START =3D bootm_low =
=3D Base Address
Core 1 0x1000,0000 0x0C00,0000 --> CONFIG_PHYSICAL_START =3D bootm_low =
=3D Base Address
Shared Mem 0x1C00,0000 0x0400,0000
Regards,
Farrukh Arshad
-----Original Message-----
From: Scott Wood [mailto:scottwood@freescale.com]
Sent: Tuesday, January 03, 2012 10:10 PM
To: Arshad, Farrukh
Cc: linuxppc-dev@lists.ozlabs.org
Subject: Re: Problem in getting shared memory access on P1022RDK
On 01/03/2012 03:42 AM, Arshad, Farrukh wrote:
> Adding more to it,
>=20
> =20
>=20
> When I write from Core 1 on the shared memory region it is visible at=20
> Core 0 and it can read what I have written from Core 1 but when I=20
> write from Core 0 on this shared memory it is not visible on Core 1.
Is the memory mapped coherent on both cores?
-Scott
^ permalink raw reply
* RE: [PATCH v3] powerpc/85xx: add support to JOG feature using cpufreq interface
From: Zhao Chenhui-B35336 @ 2012-01-04 9:34 UTC (permalink / raw)
To: Wood Scott-B07421
Cc: Huang Changming-R66093, Liu Dave-R63238,
linuxppc-dev@lists.ozlabs.org, Li Yang-R58472
In-Reply-To: <4F037DB8.4080207@freescale.com>
PiBPbiAxMi8yNy8yMDExIDA1OjI1IEFNLCBaaGFvIENoZW5odWkgd3JvdGU6DQo+ID4gICogVGhl
IGRyaXZlciBkb2Vzbid0IHN1cHBvcnQgTVBDODUzNiBSZXYgMS4wIGR1ZSB0byBhIEpPRyBlcnJh
dHVtLg0KPiA+ICAgIFN1YnNlcXVlbnQgcmV2aXNpb25zIG9mIE1QQzg1MzYgaGF2ZSBjb3JyZWN0
ZWQgdGhlIGVycmF0dW0uDQo+IA0KPiBXaGVyZSBkbyB5b3UgY2hlY2sgZm9yIHRoaXM/DQoNCk5v
d2hlcmUuIEkganVzdCBub3RpZnkgdGhpcyBwYXRjaCBkb24ndCBzdXBwb3J0IE1QQzg1MzYgUmV2
IDEuMC4NCg0KPiANCj4gPiArI2RlZmluZSBQT1dNR1RDU1JfTE9TU0xFU1NfTUFTSwkweDAwNDAw
MDAwDQo+ID4gKyNkZWZpbmUgUE9XTUdUQ1NSX0pPR19NQVNLCTB4MDAyMDAwMDANCj4gDQo+IEFy
ZSB0aGVzZSByZWFsbHkgbWFza3MsIG9yIGp1c3QgdmFsdWVzIHRvIHVzZT8NCg0KVGhleSBhcmUg
bWFza3MuDQoNCj4gDQo+ID4gKyNkZWZpbmUgUE9XTUdUQ1NSX0NPUkUwX0lSUV9NU0sJMHg4MDAw
MDAwMA0KPiA+ICsjZGVmaW5lIFBPV01HVENTUl9DT1JFMF9DSV9NU0sJMHg0MDAwMDAwMA0KPiA+
ICsjZGVmaW5lIFBPV01HVENTUl9DT1JFMF9ET1pJTkcJMHgwMDAwMDAwOA0KPiA+ICsjZGVmaW5l
IFBPV01HVENTUl9DT1JFMF9OQVBQSU5HCTB4MDAwMDAwMDQNCj4gPiArDQo+ID4gKyNkZWZpbmUg
UE9XTUdUQ1NSX0NPUkVfSU5UX01TSwkweDAwMDAwODAwDQo+ID4gKyNkZWZpbmUgUE9XTUdUQ1NS
X0NPUkVfQ0lOVF9NU0sJMHgwMDAwMDQwMA0KPiA+ICsjZGVmaW5lIFBPV01HVENTUl9DT1JFX1VE
RV9NU0sJMHgwMDAwMDIwMA0KPiA+ICsjZGVmaW5lIFBPV01HVENTUl9DT1JFX01DUF9NU0sJMHgw
MDAwMDEwMA0KPiA+ICsjZGVmaW5lIFAxMDIyX1BPV01HVENTUl9NU0sJKFBPV01HVENTUl9DT1JF
X0lOVF9NU0sgfCBcDQo+ID4gKwkJCQkgUE9XTUdUQ1NSX0NPUkVfQ0lOVF9NU0sgfCBcDQo+ID4g
KwkJCQkgUE9XTUdUQ1NSX0NPUkVfVURFX01TSyB8IFwNCj4gPiArCQkJCSBQT1dNR1RDU1JfQ09S
RV9NQ1BfTVNLKQ0KPiA+ICsNCj4gPiArc3RhdGljIHZvaWQga2VlcF93YWtpbmdfdXAodm9pZCAq
ZHVtbXkpDQo+ID4gK3sNCj4gPiArCXVuc2lnbmVkIGxvbmcgZmxhZ3M7DQo+ID4gKw0KPiA+ICsJ
bG9jYWxfaXJxX3NhdmUoZmxhZ3MpOw0KPiA+ICsJbWIoKTsNCj4gPiArDQo+ID4gKwlpbl9qb2df
cHJvY2VzcyA9IDE7DQo+ID4gKwltYigpOw0KPiA+ICsNCj4gPiArCXdoaWxlIChpbl9qb2dfcHJv
Y2VzcyAhPSAwKQ0KPiA+ICsJCW1iKCk7DQo+ID4gKw0KPiA+ICsJbG9jYWxfaXJxX3Jlc3RvcmUo
ZmxhZ3MpOw0KPiA+ICt9DQo+IA0KPiBQbGVhc2UgZG9jdW1lbnQgdGhpcy4gIENvbXBhcmUgaW5f
am9nX3Byb2Nlc3MgPT0gMSwgbm90ICE9IDAgLS0gaXQncw0KPiB1bmxpa2VseSwgYnV0IHdoYXQg
aWYgdGhlIG90aGVyIGNwdSBzZWVzIHRoYXQgaW5fam9nX3Byb2Nlc3MgaGFzIGJlZW4NCj4gc2V0
IHRvIDEsIGV4aXRzIGFuZCBzZXRzIGluX2pvZ19wcm9jZXNzIHRvIDAsIHRoZW4gcmUtZW50ZXJz
IHNldF9wbGwgYW5kDQo+IHNldHMgaW5fam9nX3Byb2Nlc3MgdG8gLTEgYWdhaW4gYmVmb3JlIHRo
aXMgZnVuY3Rpb24gZG9lcyBhbm90aGVyIGxvYWQNCj4gb2YgaW5fam9nX3Byb2Nlc3M/DQoNClRo
YW5rcy4gSSdsbCBmaXggaXQuDQoNCj4gDQo+IERvIHlvdSByZWFsbHkgbmVlZCBhbGwgdGhlc2Ug
bWIoKXM/ICBJIHRoaW5rIHRoaXMgd291bGQgc3VmZmljZToNCj4gDQo+IAlsb2NhbF9pcnFfc2F2
ZShmbGFncyk7DQo+IA0KPiAJaW5fam9nX3Byb2Nlc3MgPSAxOw0KPiANCj4gCXdoaWxlIChpbl9q
b2dfcHJvY2VzcyA9PSAxKQ0KPiAJCWJhcnJpZXIoKTsNCj4gDQo+IAlsb2NhbF9pcnFfcmVzdG9y
ZSgpOw0KPiANCj4gSXQncyBub3QgcmVhbGx5IGEgcGVyZm9ybWFuY2UgaXNzdWUsIGp1c3Qgc2lt
cGxpY2l0eS4NCj4gDQo+ID4gK3N0YXRpYyBpbnQgcDEwMjJfc2V0X3BsbCh1bnNpZ25lZCBpbnQg
Y3B1LCB1bnNpZ25lZCBpbnQgcGxsKQ0KPiA+ICt7DQo+ID4gKwlpbnQgaW5kZXgsIGh3X2NwdSA9
IGdldF9oYXJkX3NtcF9wcm9jZXNzb3JfaWQoY3B1KTsNCj4gPiArCWludCBzaGlmdDsNCj4gPiAr
CXUzMiBjb3JlZnJlcSwgdmFsLCBtYXNrID0gMDsNCj4gPiArCXVuc2lnbmVkIGludCBjdXJfcGxs
ID0gZ2V0X3BsbChod19jcHUpOw0KPiA+ICsJdW5zaWduZWQgbG9uZyBmbGFnczsNCj4gPiArCWlu
dCByZXQgPSAwOw0KPiA+ICsNCj4gPiArCWlmIChwbGwgPT0gY3VyX3BsbCkNCj4gPiArCQlyZXR1
cm4gMDsNCj4gPiArDQo+ID4gKwlzaGlmdCA9IGh3X2NwdSAqIENPUkVfUkFUSU9fQklUUyArIENP
UkUwX1JBVElPX1NISUZUOw0KPiA+ICsJdmFsID0gKHBsbCAmIENPUkVfUkFUSU9fTUFTSykgPDwg
c2hpZnQ7DQo+ID4gKw0KPiA+ICsJY29yZWZyZXEgPSBzeXNmcmVxICogcGxsIC8gMjsNCj4gPiAr
CS8qDQo+ID4gKwkgKiBTZXQgdGhlIENPUkV4X1NQRCBiaXQgaWYgdGhlIHJlcXVlc3RlZCBjb3Jl
IGZyZXF1ZW5jeQ0KPiA+ICsJICogaXMgbGFyZ2VyIHRoYW4gdGhlIHRocmVzaG9sZCBmcmVxdWVu
Y3kuDQo+ID4gKwkgKi8NCj4gPiArCWlmIChjb3JlZnJlcSA+IEZSRVFfNTMzTUh6KQ0KPiA+ICsJ
CXZhbCB8PSBQTUpDUl9DT1JFMF9TUERfTUFTSyA8PCBod19jcHU7DQo+IA0KPiBQMTAyMiBtYW51
YWwgc2F5cyB0aGUgdGhyZXNob2xkIGlzIDUwMCBNSHogKGJ1dCBkb2Vzbid0IHNheSBob3cgdG8g
c2V0DQo+IHRoZSBiaXQgaWYgdGhlIGZyZXF1ZW5jeSBpcyBleGFjdGx5IDUwMCBNSHopLiAgV2hl
cmUgZGlkIDUzMzM0MDAwMCBjb21lDQo+IGZyb20/DQoNClBsZWFzZSByZWZlciB0byBDaGFwdGVy
IDI1ICIyNS40LjEuMTEgUG93ZXIgTWFuYWdlbWVudCBKb2cgQ29udHJvbCBSZWdpc3RlciAoUE1K
Q1IpIi4NCg0KPiANCj4gPiArDQo+ID4gKwltYXNrID0gKENPUkVfUkFUSU9fTUFTSyA8PCBzaGlm
dCkgfCAoUE1KQ1JfQ09SRTBfU1BEX01BU0sgPDwNCj4gaHdfY3B1KTsNCj4gPiArCWNscnNldGJp
dHNfYmUzMihndXRzICsgUE1KQ1IsIG1hc2ssIHZhbCk7DQo+ID4gKw0KPiA+ICsJLyogcmVhZGJh
Y2sgdG8gc3luYyB3cml0ZSAqLw0KPiA+ICsJdmFsID0gaW5fYmUzMihndXRzICsgUE1KQ1IpOw0K
PiANCj4gWW91IGRvbid0IHVzZSB2YWwgYWZ0ZXIgdGhpcyAtLSBqdXN0IGlnbm9yZSB0aGUgcmV0
dXJuIHZhbHVlIGZyb20NCj4gaW5fYmUzMigpLg0KDQpPSy4NCg0KPiANCj4gPiArCS8qDQo+ID4g
KwkgKiBBIEpvZyByZXF1ZXN0IGNhbiBub3QgYmUgYXNzZXJ0ZWQgd2hlbiBhbnkgY29yZSBpcyBp
biBhIGxvdw0KPiA+ICsJICogcG93ZXIgc3RhdGUgb24gUDEwMjIuIEJlZm9yZSBleGVjdXRpbmcg
YSBqb2cgcmVxdWVzdCwgYW55DQo+ID4gKwkgKiBjb3JlIHdoaWNoIGlzIGluIGEgbG93IHBvd2Vy
IHN0YXRlIG11c3QgYmUgd2FrZWQgYnkgYQ0KPiA+ICsJICogaW50ZXJydXB0LCBhbmQga2VlcCB3
YWtpbmcgdXAgdW50aWwgdGhlIHNlcXVlbmNlIGlzDQo+ID4gKwkgKiBmaW5pc2hlZC4NCj4gPiAr
CSAqLw0KPiA+ICsJZm9yX2VhY2hfcHJlc2VudF9jcHUoaW5kZXgpIHsNCj4gPiArCQlpZiAoIWNw
dV9vbmxpbmUoaW5kZXgpKQ0KPiA+ICsJCQlyZXR1cm4gLUVGQVVMVDsNCj4gPiArCX0NCj4gDQo+
IEVGQVVMVCBpcyBub3QgdGhlIGFwcHJvcHJpYXRlIGVycm9yIGNvZGUgLS0gaXQgaXMgZm9yIHdo
ZW4gdXNlcnNwYWNlDQo+IHBhc3NlcyBhIGJhZCB2aXJ0dWFsIGFkZHJlc3MuDQo+IA0KPiBCZXR0
ZXIsIGRvbid0IGZhaWwgaGVyZSAtLSBicmluZyB0aGUgb3RoZXIgY29yZSBvdXQgb2YgdGhlIGxv
dyBwb3dlcg0KPiBzdGF0ZSBpbiBvcmRlciB0byBkbyB0aGUgam9nLiAgY3B1ZnJlcSBzaG91bGRu
J3Qgc3RvcCB3b3JraW5nIGp1c3QNCj4gYmVjYXVzZSB3ZSB0b29rIGEgY29yZSBvZmZsaW5lLg0K
PiANCj4gV2hhdCBwcmV2ZW50cyBhIGNvcmUgZnJvbSBnb2luZyBvZmZsaW5lIGp1c3QgYWZ0ZXIg
eW91IGNoZWNrIGhlcmU/DQo+IA0KPiA+ICsJaW5fam9nX3Byb2Nlc3MgPSAtMTsNCj4gPiArCW1i
KCk7DQo+ID4gKwlzbXBfY2FsbF9mdW5jdGlvbihrZWVwX3dha2luZ191cCwgTlVMTCwgMCk7DQo+
IA0KPiBXaGF0IGRvZXMgImtlZXAgd2FraW5nIHVwIiBtZWFuPyAgU29tZXRoaW5nIGxpa2Ugc3Bp
bl93aGlsZV9qb2dnaW5nDQo+IG1pZ2h0IGJlIGNsZWFyZXIuDQo+IA0KPiA+ICsJbG9jYWxfaXJx
X3NhdmUoZmxhZ3MpOw0KPiA+ICsJbWIoKTsNCj4gPiArCS8qIFdhaXQgZm9yIHRoZSBvdGhlciBj
b3JlIHRvIHdha2UuICovDQo+ID4gKwl3aGlsZSAoaW5fam9nX3Byb2Nlc3MgIT0gMSkNCj4gPiAr
CQltYigpOw0KPiANCj4gVGltZW91dD8gIEFuZCBtb3JlIHVubmVjZXNzYXJ5IG1iKClzLg0KPiAN
Cj4gTWlnaHQgYmUgbmljZSB0byBzdXBwb3J0IG1vcmUgdGhhbiB0d28gY29yZXMsIGV2ZW4gaWYg
dGhpcyBjb2RlIGlzbid0DQo+IGN1cnJlbnRseSBleHBlY3RlZCB0byBiZSB1c2VkIG9uIHN1Y2gg
aGFyZHdhcmUgKGl0J3MganVzdCBhIGdlbmVyaWMNCj4gImhvbGQgb3RoZXIgY3B1cyIgbG9vcDsg
bWlnaHQgYXMgd2VsbCBtYWtlIGl0IHJldXNhYmxlKS4gIFlvdSBjb3VsZCBkbw0KPiB0aGlzIGJ5
IHVzaW5nIGFuIGF0b21pYyBjb3VudCBmb3Igb3RoZXIgY29yZXMgdG8gY2hlY2sgaW4gYW5kIG91
dCBvZiB0aGUNCj4gc3BpbiBsb29wLg0KDQpUaGlzIGlzIGp1c3QgZm9yIFAxMDIyLCBhIGR1YWwt
Y29yZSBjaGlwLiBBIHNlcGFyYXRlIHBhdGNoIHdpbGwNCnN1cHBvcnQgbXVsdGktY29yZSBjaGlw
cywgc3VjaCBhcyBQNDA4MCwgZXRjLg0KDQo+IA0KPiA+ICsJb3V0X2JlMzIoZ3V0cyArIFBPV01H
VENTUiwgUE9XTUdUQ1NSX0pPR19NQVNLIHwNCj4gUDEwMjJfUE9XTUdUQ1NSX01TSyk7DQo+ID4g
Kw0KPiA+ICsJaWYgKCFzcGluX2V2ZW50X3RpbWVvdXQoKChpbl9iZTMyKGd1dHMgKyBQT1dNR1RD
U1IpICYNCj4gPiArCSAgICBQT1dNR1RDU1JfSk9HX01BU0spID09IDApLCAxMDAwMCwgMTApKSB7
DQo+ID4gKwkJcHJfZXJyKCIlczogRmFpbCB0byBzd2l0Y2ggdGhlIGNvcmUgZnJlcXVlbmN5Llxu
IiwgX19mdW5jX18pOw0KPiA+ICsJCXJldCA9IC1FRkFVTFQ7DQo+ID4gKwl9DQo+ID4gKw0KPiA+
ICsJY2xyYml0czMyKGd1dHMgKyBQT1dNR1RDU1IsIFAxMDIyX1BPV01HVENTUl9NU0spOw0KPiA+
ICsJaW5fam9nX3Byb2Nlc3MgPSAwOw0KPiA+ICsJbWIoKTsNCj4gDQo+IFRoaXMgbWIoKSAob3Ig
YmV0dGVyLCBhIHJlYWRiYWNrIG9mIFBPV01HVENTUikgc2hvdWxkIGJlIGJlZm9yZSB5b3UNCj4g
Y2xlYXIgaW5fam9nX3Byb2Nlc3MuICBGb3IgY2xhcml0eSBvZiBpdHMgcHVycG9zZSwgdGhlIGNs
ZWFyaW5nIG9mDQo+IFBPV01HVENTUiBzaG91bGQgZ28gaW4gdGhlIGZhaWx1cmUgYnJhbmNoIG9m
IHNwaW5fZXZlbnRfdGltZW91dCgpLg0KDQpBY2NvcmRpbmcgdG8gdGhlIG1hbnVhbCwgUDEwMjJf
UE9XTUdUQ1NSX01TSyBzaG91bGQgYmUgcmVzZXQNCmJ5IHNvZnR3YXJlIHJlZ2FyZGxlc3Mgb2Yg
ZmFpbHVyZSBvciBzdWNjZXNzLg0KDQotY2hlbmh1aQ0K
^ permalink raw reply
* Re: linux-next: build warnings after merge of the final tree
From: hpanvin@gmail.com @ 2012-01-04 9:23 UTC (permalink / raw)
To: Stephen Rothwell
Cc: Peter Zijlstra, linux-kernel, Steven Rostedt, linux-next,
Paul Mackerras, Thomas Gleixner, linuxppc-dev, Ingo Molnar
In-Reply-To: <20120104190613.2e76daaa000ccf61121fdcc1@canb.auug.org.au>
I thought it had been...? Need to investigate (as baby permits...)
Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>Hi again,
>
>On Thu, 22 Dec 2011 16:33:04 +1100 Stephen Rothwell
><sfr@canb.auug.org.au> wrote:
>>
>> On Wed, 14 Dec 2011 08:47:01 -0800 "H. Peter Anvin" <hpa@zytor.com>
>wrote:
>> >
>> > On 12/14/2011 08:32 AM, Steven Rostedt wrote:
>> > > On Wed, 2011-12-14 at 18:15 +1100, Stephen Rothwell wrote:
>> > >
>> > >> Maybe caused by commit d5e553d6e0a4 ("trace: Include
><asm/asm-offsets.h>
>> > >> in trace_syscalls.c") from the tip tree. These warnings may
>have been
>> > >> here for a while as it is hard to catch the new ones among the
>flood.
>> > >>
>> > >
>> > > hpa,
>> > >
>> > > Was this change only needed for x86? If so, could you put that
>into
>> > > asm/ftrace.h instead?
>> >
>> > Yes (on both accounts). It was part of the syscall changes; I'll
>move
>> > the include.
>>
>> Ping?
>
>Can we please have this fixed ...
>--
>Cheers,
>Stephen Rothwell sfr@canb.auug.org.au
>http://www.canb.auug.org.au/~sfr/
--
Sent from my Android phone with K-9 Mail. Please excuse my brevity.
^ permalink raw reply
* Re: linux-next: build warnings after merge of the final tree
From: Stephen Rothwell @ 2012-01-04 8:06 UTC (permalink / raw)
To: H. Peter Anvin
Cc: Peter Zijlstra, linux-kernel, Steven Rostedt, linux-next,
Paul Mackerras, Thomas Gleixner, linuxppc-dev, Ingo Molnar
In-Reply-To: <20111222163304.26be6d0f5e514fefb078c0a6@canb.auug.org.au>
[-- Attachment #1: Type: text/plain, Size: 942 bytes --]
Hi again,
On Thu, 22 Dec 2011 16:33:04 +1100 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>
> On Wed, 14 Dec 2011 08:47:01 -0800 "H. Peter Anvin" <hpa@zytor.com> wrote:
> >
> > On 12/14/2011 08:32 AM, Steven Rostedt wrote:
> > > On Wed, 2011-12-14 at 18:15 +1100, Stephen Rothwell wrote:
> > >
> > >> Maybe caused by commit d5e553d6e0a4 ("trace: Include <asm/asm-offsets.h>
> > >> in trace_syscalls.c") from the tip tree. These warnings may have been
> > >> here for a while as it is hard to catch the new ones among the flood.
> > >>
> > >
> > > hpa,
> > >
> > > Was this change only needed for x86? If so, could you put that into
> > > asm/ftrace.h instead?
> >
> > Yes (on both accounts). It was part of the syscall changes; I'll move
> > the include.
>
> Ping?
Can we please have this fixed ...
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/
[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply
* RE: Problem in getting shared memory access on P1022RDK
From: Arshad, Farrukh @ 2012-01-04 6:49 UTC (permalink / raw)
To: Scott Wood; +Cc: linuxppc-dev@lists.ozlabs.org
In-Reply-To: <4F033685.6000509@freescale.com>
How can I verify if the memory mapped is coherent on both cores. My memory =
partitioning is given below
Core Base Address Size
Core 0 0x0000,0000 0x1000,0000 --> CONFIG_PHYSICAL_START =3D bootm_low =
=3D Base Address
Core 1 0x1000,0000 0x0C00,0000 --> CONFIG_PHYSICAL_START =3D bootm_low =
=3D Base Address
Shared Mem 0x1C00,0000 0x0400,0000
Regards,
Farrukh Arshad
-----Original Message-----
From: Scott Wood [mailto:scottwood@freescale.com]=20
Sent: Tuesday, January 03, 2012 10:10 PM
To: Arshad, Farrukh
Cc: linuxppc-dev@lists.ozlabs.org
Subject: Re: Problem in getting shared memory access on P1022RDK
On 01/03/2012 03:42 AM, Arshad, Farrukh wrote:
> Adding more to it,
>=20
> =20
>=20
> When I write from Core 1 on the shared memory region it is visible at=20
> Core 0 and it can read what I have written from Core 1 but when I=20
> write from Core 0 on this shared memory it is not visible on Core 1.
Is the memory mapped coherent on both cores?
-Scott
^ permalink raw reply
* Re: [PATCH 2/2] mtd/nand: Fix IFC driver to support 2K NAND page
From: Prabhakar @ 2012-01-04 4:58 UTC (permalink / raw)
To: Scott Wood; +Cc: linux-mtd, linuxppc-dev, Poonam Aggrwal
In-Reply-To: <4F035BDF.5070207@freescale.com>
On Wednesday 04 January 2012 01:19 AM, Scott Wood wrote:
> On 12/28/2011 10:59 PM, Prabhakar Kushwaha wrote:
>> 1) OOB area should be updated irrespective of NAND page size. Earlier it was
>> updated only for 512byte NAND page.
>>
>> 2) During OOB update fbcr should be equal to OOB size.
>>
>> Signed-off-by: Poonam Aggrwal<poonam.aggrwal@freescale.com>
>> Signed-off-by: Prabhakar Kushwaha<prabhakar@freescale.com>
>> ---
>> git://git.kernel.org/pub/scm/linux/kernel/git/galak/powerpc.git (branch next)
> The IFC driver hasn't been merged into that tree that I can see.
This patch is created on top of IFC driver patch (already floated in
mailing list). Please find there link:
http://patchwork.ozlabs.org/patch/133315/
http://patchwork.ozlabs.org/patch/133316/
>> Tested on P1010RDB
>>
>> drivers/mtd/nand/fsl_ifc_nand.c | 20 ++++++++------------
>> 1 files changed, 8 insertions(+), 12 deletions(-)
>>
>> diff --git a/drivers/mtd/nand/fsl_ifc_nand.c b/drivers/mtd/nand/fsl_ifc_nand.c
>> index 2df7206..2c02168 100644
>> --- a/drivers/mtd/nand/fsl_ifc_nand.c
>> +++ b/drivers/mtd/nand/fsl_ifc_nand.c
>> @@ -439,20 +439,16 @@ static void fsl_ifc_cmdfunc(struct mtd_info *mtd, unsigned int command,
>> out_be32(&ifc->ifc_nand.nand_fir1,
>> (IFC_FIR_OP_CW1<< IFC_NAND_FIR1_OP5_SHIFT));
>>
>> - if (column>= mtd->writesize) {
>> - /* OOB area --> READOOB */
>> - column -= mtd->writesize;
>> - nand_fcr0 |= NAND_CMD_READOOB<<
>> - IFC_NAND_FCR0_CMD0_SHIFT;
>> - ifc_nand_ctrl->oob = 1;
>> - } else if (column< 256)
>> + if (column< 256)
>> /* First 256 bytes --> READ0 */
>> nand_fcr0 |=
>> NAND_CMD_READ0<< IFC_NAND_FCR0_CMD0_SHIFT;
>> - else
>> - /* Second 256 bytes --> READ1 */
>> - nand_fcr0 |=
>> - NAND_CMD_READ1<< IFC_NAND_FCR0_CMD0_SHIFT;
>> + }
>> +
>> + if (column>= mtd->writesize) {
>> + /* OOB area --> READOOB */
>> + column -= mtd->writesize;
>> + ifc_nand_ctrl->oob = 1;
>> }
> Where is NAND_CMD_READOOB going to be set in the small-page case?
2K NAND flash does not require NAND_CMD_READOOB. So i thought same
should be applied to 512byte NAND. but i am wrong.
Thanks for pointing it out :)
>
> The small-page code should read something like:
>
> if (column>= mtd->writesize) {
> nand_fcr0 |=
> NAND_CMD_READOOB<< IFC_NAND_FCR0_CMD0_SHIFT;
> } else {
> nand_fcr0 |=
> NAND_CMD_READ0<< IFC_NAND_FCR0_CMD0_SHIFT;
> }
>
> It looks like we can get rid of ctrl->column, BTW.
>
I will take care this in next patch release
--Prabhakar
^ permalink raw reply
* Re: [PATCH 1/2] mtd/nand:Fix wrong address read in is_blank()
From: Prabhakar @ 2012-01-04 4:35 UTC (permalink / raw)
To: Scott Wood; +Cc: linux-mtd, linuxppc-dev, Poonam Aggrwal
In-Reply-To: <4F0363E2.6040702@freescale.com>
On Wednesday 04 January 2012 01:54 AM, Scott Wood wrote:
> On 12/28/2011 10:59 PM, Prabhakar Kushwaha wrote:
>> IFC NAND Machine calculates ECC on 512byte sector. Same is taken care in
>> fsl_ifc_run_command() while ECC status verification. Here buffer number is
>> calculated assuming 512byte sector and same is passed to is_blank.
>> However in is_blank() buffer address is calculated using mdt->writesize which is
>> wrong. It should be calculated on basis of ecc sector size.
>>
>> Also, in fsl_ifc_run_command() bufferpage is calculated on the basis of ecc sector
>> size instead of hard coded value.
>>
>> Signed-off-by: Poonam Aggrwal<poonam.aggrwal@freescale.com>
>> Signed-off-by: Prabhakar Kushwaha<prabhakar@freescale.com>
>> ---
>> git://git.kernel.org/pub/scm/linux/kernel/git/galak/powerpc.git (branch next)
>>
>> Tested on P1010RDB
>>
>> drivers/mtd/nand/fsl_ifc_nand.c | 6 ++++--
>> 1 files changed, 4 insertions(+), 2 deletions(-)
>>
>> diff --git a/drivers/mtd/nand/fsl_ifc_nand.c b/drivers/mtd/nand/fsl_ifc_nand.c
>> index 8475b88..2df7206 100644
>> --- a/drivers/mtd/nand/fsl_ifc_nand.c
>> +++ b/drivers/mtd/nand/fsl_ifc_nand.c
>> @@ -191,7 +191,9 @@ static int is_blank(struct mtd_info *mtd, unsigned int bufnum)
>> {
>> struct nand_chip *chip = mtd->priv;
>> struct fsl_ifc_mtd *priv = chip->priv;
>> - u8 __iomem *addr = priv->vbase + bufnum * (mtd->writesize * 2);
>> + int bufperpage = mtd->writesize / chip->ecc.size;
>> + u8 __iomem *addr = priv->vbase + bufnum / bufperpage
>> + * (mtd->writesize * 2);
>> u32 __iomem *mainarea = (u32 *)addr;
>> u8 __iomem *oob = addr + mtd->writesize;
>> int i;
> This function should only be checking one ECC block, not the entire
> page. The caller is responsible for passing in the appropriate buffer
> numbers.
>
> I think what the current code needs is for (mtd->writesize * 2) to be
> replaced with chip->ecc.size, and for the calling code to multiply the
> starting bufnum by two.
Got your point :). I will take care in next patch version.
>> @@ -273,7 +275,7 @@ static void fsl_ifc_run_command(struct mtd_info *mtd)
>> dev_err(priv->dev, "NAND Flash Write Protect Error\n");
>>
>> if (nctrl->eccread) {
>> - int bufperpage = mtd->writesize / 512;
>> + int bufperpage = mtd->writesize / chip->ecc.size;
>> int bufnum = (nctrl->page& priv->bufnum_mask) * bufperpage;
>> int bufnum_end = bufnum + bufperpage - 1;
>>
> Currently this driver always sets chip->ecc.size to 512. If we want to
> support other ECC block sizes that future versions of IFC may have, can
> we calculate bufperpage during chip init (similar to bufnum_mask) to
> avoid the runtime division? It's probably not huge overhead compared to
> everything else we do per NAND page transfer, but still...
>
Yes. I agree.
We are working on this in order to support new controller version.
--Prabhakar
^ permalink raw reply
* RE: [PATCH] DTS: fix the bug and add the chip compatible for eSDHC
From: Huang Changming-R66093 @ 2012-01-04 3:14 UTC (permalink / raw)
To: Tabi Timur-B04825; +Cc: linuxppc-dev@lists.ozlabs.org
In-Reply-To: <CAOZdJXXXvTuJO_ZpyeRatWxTMbmcEVokA9qx7ajNdzKyiEgBhw@mail.gmail.com>
> -----Original Message-----
> From: Tabi Timur-B04825
> Sent: Tuesday, January 03, 2012 4:30 AM
> To: Huang Changming-R66093
> Cc: linuxppc-dev@lists.ozlabs.org; Huang Changming-R66093
> Subject: Re: [PATCH] DTS: fix the bug and add the chip compatible for
> eSDHC
>=20
> On Fri, Dec 23, 2011 at 12:10 AM, <r66093@freescale.com> wrote:
> >
> > Accordint to latest kernel, the auto-cmd12 property should be
> > "sdhci,auto-cmd12", and according to the SDHC binding and the
> > workaround for the special chip, add the chip compatible for eSDHC:
> > "fsl,p1022-esdhc", "fsl,mpc8536-esdhc", "fsl,p2020-esdhc" and
> "fsl,p1010-esdhc".
>=20
> Please do not use the phrase "fix the bug" in patch summaries.
>=20
Then, could you tell me how to describe it?
^ permalink raw reply
* RE: [PATCH] DTS: fix the bug and add the chip compatible for eSDHC
From: Huang Changming-R66093 @ 2012-01-04 3:11 UTC (permalink / raw)
To: Wood Scott-B07421; +Cc: linuxppc-dev@lists.ozlabs.org
In-Reply-To: <4F01F721.7090407@freescale.com>
> -----Original Message-----
> From: Wood Scott-B07421
> Sent: Tuesday, January 03, 2012 2:28 AM
> To: Huang Changming-R66093
> Cc: linuxppc-dev@lists.ozlabs.org; Huang Changming-R66093
> Subject: Re: [PATCH] DTS: fix the bug and add the chip compatible for
> eSDHC
>=20
> On 12/23/2011 12:10 AM, r66093@freescale.com wrote:
> > From: Jerry Huang <Chang-Ming.Huang@freescale.com>
> >
> > Accordint to latest kernel, the auto-cmd12 property should be
> > "sdhci,auto-cmd12", and according to the SDHC binding and the
> > workaround for the special chip, add the chip compatible for eSDHC:
> > "fsl,p1022-esdhc", "fsl,mpc8536-esdhc", "fsl,p2020-esdhc" and
> "fsl,p1010-esdhc".
> >
> > Signed-off-by: Jerry Huang <Chang-Ming.Huang@freescale.com>
> > ---
> > arch/powerpc/boot/dts/fsl/mpc8536si-post.dtsi | 4 ++++
> > arch/powerpc/boot/dts/fsl/p1010si-post.dtsi | 3 ++-
> > arch/powerpc/boot/dts/fsl/p1022si-post.dtsi | 3 ++-
> > arch/powerpc/boot/dts/fsl/p2020si-post.dtsi | 4 ++++
> > 4 files changed, 12 insertions(+), 2 deletions(-)
> >
> > diff --git a/arch/powerpc/boot/dts/fsl/mpc8536si-post.dtsi
> > b/arch/powerpc/boot/dts/fsl/mpc8536si-post.dtsi
> > index 89af626..44e0ed9 100644
> > --- a/arch/powerpc/boot/dts/fsl/mpc8536si-post.dtsi
> > +++ b/arch/powerpc/boot/dts/fsl/mpc8536si-post.dtsi
> > @@ -236,6 +236,10 @@
> > };
> >
> > /include/ "pq3-esdhc-0.dtsi"
> > + sdhc@2e000 {
> > + compatible =3D "fsl,esdhc", "fsl,mpc8536-esdhc";
> > + };
>=20
> More-specific compatible entries should come first.
I don't understand you, why more-specific compatible entries should come?
The Documentation/devicetree/bindings/mmc/fsl-esdhc.txt has introduced it:
- compatible : should be
"fsl,<chip>-esdhc", "fsl,esdhc"
I don't think I should introduce new entries.
^ permalink raw reply
* Re: [PATCH v3] powerpc/85xx: add support to JOG feature using cpufreq interface
From: Scott Wood @ 2012-01-03 22:14 UTC (permalink / raw)
To: Zhao Chenhui; +Cc: linuxppc-dev, Jerry Huang
In-Reply-To: <1324985129-26219-1-git-send-email-chenhui.zhao@freescale.com>
On 12/27/2011 05:25 AM, Zhao Chenhui wrote:
> * The driver doesn't support MPC8536 Rev 1.0 due to a JOG erratum.
> Subsequent revisions of MPC8536 have corrected the erratum.
Where do you check for this?
> +#define POWMGTCSR_LOSSLESS_MASK 0x00400000
> +#define POWMGTCSR_JOG_MASK 0x00200000
Are these really masks, or just values to use?
> +#define POWMGTCSR_CORE0_IRQ_MSK 0x80000000
> +#define POWMGTCSR_CORE0_CI_MSK 0x40000000
> +#define POWMGTCSR_CORE0_DOZING 0x00000008
> +#define POWMGTCSR_CORE0_NAPPING 0x00000004
> +
> +#define POWMGTCSR_CORE_INT_MSK 0x00000800
> +#define POWMGTCSR_CORE_CINT_MSK 0x00000400
> +#define POWMGTCSR_CORE_UDE_MSK 0x00000200
> +#define POWMGTCSR_CORE_MCP_MSK 0x00000100
> +#define P1022_POWMGTCSR_MSK (POWMGTCSR_CORE_INT_MSK | \
> + POWMGTCSR_CORE_CINT_MSK | \
> + POWMGTCSR_CORE_UDE_MSK | \
> + POWMGTCSR_CORE_MCP_MSK)
> +
> +static void keep_waking_up(void *dummy)
> +{
> + unsigned long flags;
> +
> + local_irq_save(flags);
> + mb();
> +
> + in_jog_process = 1;
> + mb();
> +
> + while (in_jog_process != 0)
> + mb();
> +
> + local_irq_restore(flags);
> +}
Please document this. Compare in_jog_process == 1, not != 0 -- it's
unlikely, but what if the other cpu sees that in_jog_process has been
set to 1, exits and sets in_jog_process to 0, then re-enters set_pll and
sets in_jog_process to -1 again before this function does another load
of in_jog_process?
Do you really need all these mb()s? I think this would suffice:
local_irq_save(flags);
in_jog_process = 1;
while (in_jog_process == 1)
barrier();
local_irq_restore();
It's not really a performance issue, just simplicity.
> +static int p1022_set_pll(unsigned int cpu, unsigned int pll)
> +{
> + int index, hw_cpu = get_hard_smp_processor_id(cpu);
> + int shift;
> + u32 corefreq, val, mask = 0;
> + unsigned int cur_pll = get_pll(hw_cpu);
> + unsigned long flags;
> + int ret = 0;
> +
> + if (pll == cur_pll)
> + return 0;
> +
> + shift = hw_cpu * CORE_RATIO_BITS + CORE0_RATIO_SHIFT;
> + val = (pll & CORE_RATIO_MASK) << shift;
> +
> + corefreq = sysfreq * pll / 2;
> + /*
> + * Set the COREx_SPD bit if the requested core frequency
> + * is larger than the threshold frequency.
> + */
> + if (corefreq > FREQ_533MHz)
> + val |= PMJCR_CORE0_SPD_MASK << hw_cpu;
P1022 manual says the threshold is 500 MHz (but doesn't say how to set
the bit if the frequency is exactly 500 MHz). Where did 533340000 come
from?
> +
> + mask = (CORE_RATIO_MASK << shift) | (PMJCR_CORE0_SPD_MASK << hw_cpu);
> + clrsetbits_be32(guts + PMJCR, mask, val);
> +
> + /* readback to sync write */
> + val = in_be32(guts + PMJCR);
You don't use val after this -- just ignore the return value from in_be32().
> + /*
> + * A Jog request can not be asserted when any core is in a low
> + * power state on P1022. Before executing a jog request, any
> + * core which is in a low power state must be waked by a
> + * interrupt, and keep waking up until the sequence is
> + * finished.
> + */
> + for_each_present_cpu(index) {
> + if (!cpu_online(index))
> + return -EFAULT;
> + }
EFAULT is not the appropriate error code -- it is for when userspace
passes a bad virtual address.
Better, don't fail here -- bring the other core out of the low power
state in order to do the jog. cpufreq shouldn't stop working just
because we took a core offline.
What prevents a core from going offline just after you check here?
> + in_jog_process = -1;
> + mb();
> + smp_call_function(keep_waking_up, NULL, 0);
What does "keep waking up" mean? Something like spin_while_jogging
might be clearer.
> + local_irq_save(flags);
> + mb();
> + /* Wait for the other core to wake. */
> + while (in_jog_process != 1)
> + mb();
Timeout? And more unnecessary mb()s.
Might be nice to support more than two cores, even if this code isn't
currently expected to be used on such hardware (it's just a generic
"hold other cpus" loop; might as well make it reusable). You could do
this by using an atomic count for other cores to check in and out of the
spin loop.
> + out_be32(guts + POWMGTCSR, POWMGTCSR_JOG_MASK | P1022_POWMGTCSR_MSK);
> +
> + if (!spin_event_timeout(((in_be32(guts + POWMGTCSR) &
> + POWMGTCSR_JOG_MASK) == 0), 10000, 10)) {
> + pr_err("%s: Fail to switch the core frequency.\n", __func__);
> + ret = -EFAULT;
> + }
> +
> + clrbits32(guts + POWMGTCSR, P1022_POWMGTCSR_MSK);
> + in_jog_process = 0;
> + mb();
This mb() (or better, a readback of POWMGTCSR) should be before you
clear in_jog_process. For clarity of its purpose, the clearing of
POWMGTCSR should go in the failure branch of spin_event_timeout().
> + /* the latency of a transition, the unit is ns */
> + policy->cpuinfo.transition_latency = 2000;
Is this based on observation?
> diff --git a/arch/powerpc/platforms/85xx/sleep.S b/arch/powerpc/platforms/85xx/sleep.S
> index 763d2f2..919781d 100644
> --- a/arch/powerpc/platforms/85xx/sleep.S
> +++ b/arch/powerpc/platforms/85xx/sleep.S
> @@ -59,6 +59,7 @@ powmgtreq:
> * r5 = JOG or deep sleep request
> * JOG-0x00200000, deep sleep-0x00100000
> */
> +_GLOBAL(mpc85xx_enter_jog)
> _GLOBAL(mpc85xx_enter_deep_sleep)
> lis r6, ccsrbase_low@ha
> stw r4, ccsrbase_low@l(r6)
Why does this need two entry points rather than a more appropriate name?
> diff --git a/arch/powerpc/platforms/Kconfig b/arch/powerpc/platforms/Kconfig
> index 3fe6d92..1d0c4e0 100644
> --- a/arch/powerpc/platforms/Kconfig
> +++ b/arch/powerpc/platforms/Kconfig
> @@ -200,6 +200,14 @@ config CPU_FREQ_PMAC64
> This adds support for frequency switching on Apple iMac G5,
> and some of the more recent desktop G5 machines as well.
>
> +config MPC85xx_CPUFREQ
> + bool "Support for Freescale MPC85xx CPU freq"
> + depends on PPC_85xx && PPC32
> + select CPU_FREQ_TABLE
> + help
> + This adds support for frequency switching on Freescale MPC85xx,
> + currently including P1022 and MPC8536.
default y, given the dependencies? Or wait for more testing before we
do that?
-Scott
^ permalink raw reply
* Re: [PATCH 1/2] mtd/nand:Fix wrong address read in is_blank()
From: Scott Wood @ 2012-01-03 20:24 UTC (permalink / raw)
To: Prabhakar Kushwaha; +Cc: linux-mtd, linuxppc-dev, Poonam Aggrwal
In-Reply-To: <1325134779-3571-2-git-send-email-prabhakar@freescale.com>
On 12/28/2011 10:59 PM, Prabhakar Kushwaha wrote:
> IFC NAND Machine calculates ECC on 512byte sector. Same is taken care in
> fsl_ifc_run_command() while ECC status verification. Here buffer number is
> calculated assuming 512byte sector and same is passed to is_blank.
> However in is_blank() buffer address is calculated using mdt->writesize which is
> wrong. It should be calculated on basis of ecc sector size.
>
> Also, in fsl_ifc_run_command() bufferpage is calculated on the basis of ecc sector
> size instead of hard coded value.
>
> Signed-off-by: Poonam Aggrwal <poonam.aggrwal@freescale.com>
> Signed-off-by: Prabhakar Kushwaha <prabhakar@freescale.com>
> ---
> git://git.kernel.org/pub/scm/linux/kernel/git/galak/powerpc.git (branch next)
>
> Tested on P1010RDB
>
> drivers/mtd/nand/fsl_ifc_nand.c | 6 ++++--
> 1 files changed, 4 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/mtd/nand/fsl_ifc_nand.c b/drivers/mtd/nand/fsl_ifc_nand.c
> index 8475b88..2df7206 100644
> --- a/drivers/mtd/nand/fsl_ifc_nand.c
> +++ b/drivers/mtd/nand/fsl_ifc_nand.c
> @@ -191,7 +191,9 @@ static int is_blank(struct mtd_info *mtd, unsigned int bufnum)
> {
> struct nand_chip *chip = mtd->priv;
> struct fsl_ifc_mtd *priv = chip->priv;
> - u8 __iomem *addr = priv->vbase + bufnum * (mtd->writesize * 2);
> + int bufperpage = mtd->writesize / chip->ecc.size;
> + u8 __iomem *addr = priv->vbase + bufnum / bufperpage
> + * (mtd->writesize * 2);
> u32 __iomem *mainarea = (u32 *)addr;
> u8 __iomem *oob = addr + mtd->writesize;
> int i;
This function should only be checking one ECC block, not the entire
page. The caller is responsible for passing in the appropriate buffer
numbers.
I think what the current code needs is for (mtd->writesize * 2) to be
replaced with chip->ecc.size, and for the calling code to multiply the
starting bufnum by two.
> @@ -273,7 +275,7 @@ static void fsl_ifc_run_command(struct mtd_info *mtd)
> dev_err(priv->dev, "NAND Flash Write Protect Error\n");
>
> if (nctrl->eccread) {
> - int bufperpage = mtd->writesize / 512;
> + int bufperpage = mtd->writesize / chip->ecc.size;
> int bufnum = (nctrl->page & priv->bufnum_mask) * bufperpage;
> int bufnum_end = bufnum + bufperpage - 1;
>
Currently this driver always sets chip->ecc.size to 512. If we want to
support other ECC block sizes that future versions of IFC may have, can
we calculate bufperpage during chip init (similar to bufnum_mask) to
avoid the runtime division? It's probably not huge overhead compared to
everything else we do per NAND page transfer, but still...
-Scott
^ permalink raw reply
* Re: [PATCH 2/2] mtd/nand: Fix IFC driver to support 2K NAND page
From: Scott Wood @ 2012-01-03 19:49 UTC (permalink / raw)
To: Prabhakar Kushwaha; +Cc: linux-mtd, linuxppc-dev, Poonam Aggrwal
In-Reply-To: <1325134779-3571-3-git-send-email-prabhakar@freescale.com>
On 12/28/2011 10:59 PM, Prabhakar Kushwaha wrote:
> 1) OOB area should be updated irrespective of NAND page size. Earlier it was
> updated only for 512byte NAND page.
>
> 2) During OOB update fbcr should be equal to OOB size.
>
> Signed-off-by: Poonam Aggrwal <poonam.aggrwal@freescale.com>
> Signed-off-by: Prabhakar Kushwaha <prabhakar@freescale.com>
> ---
> git://git.kernel.org/pub/scm/linux/kernel/git/galak/powerpc.git (branch next)
The IFC driver hasn't been merged into that tree that I can see.
> Tested on P1010RDB
>
> drivers/mtd/nand/fsl_ifc_nand.c | 20 ++++++++------------
> 1 files changed, 8 insertions(+), 12 deletions(-)
>
> diff --git a/drivers/mtd/nand/fsl_ifc_nand.c b/drivers/mtd/nand/fsl_ifc_nand.c
> index 2df7206..2c02168 100644
> --- a/drivers/mtd/nand/fsl_ifc_nand.c
> +++ b/drivers/mtd/nand/fsl_ifc_nand.c
> @@ -439,20 +439,16 @@ static void fsl_ifc_cmdfunc(struct mtd_info *mtd, unsigned int command,
> out_be32(&ifc->ifc_nand.nand_fir1,
> (IFC_FIR_OP_CW1 << IFC_NAND_FIR1_OP5_SHIFT));
>
> - if (column >= mtd->writesize) {
> - /* OOB area --> READOOB */
> - column -= mtd->writesize;
> - nand_fcr0 |= NAND_CMD_READOOB <<
> - IFC_NAND_FCR0_CMD0_SHIFT;
> - ifc_nand_ctrl->oob = 1;
> - } else if (column < 256)
> + if (column < 256)
> /* First 256 bytes --> READ0 */
> nand_fcr0 |=
> NAND_CMD_READ0 << IFC_NAND_FCR0_CMD0_SHIFT;
> - else
> - /* Second 256 bytes --> READ1 */
> - nand_fcr0 |=
> - NAND_CMD_READ1 << IFC_NAND_FCR0_CMD0_SHIFT;
> + }
> +
> + if (column >= mtd->writesize) {
> + /* OOB area --> READOOB */
> + column -= mtd->writesize;
> + ifc_nand_ctrl->oob = 1;
> }
Where is NAND_CMD_READOOB going to be set in the small-page case?
The small-page code should read something like:
if (column >= mtd->writesize) {
nand_fcr0 |=
NAND_CMD_READOOB << IFC_NAND_FCR0_CMD0_SHIFT;
} else {
nand_fcr0 |=
NAND_CMD_READ0 << IFC_NAND_FCR0_CMD0_SHIFT;
}
It looks like we can get rid of ctrl->column, BTW.
-Scott
^ permalink raw reply
* Re: Problem in getting shared memory access on P1022RDK
From: Scott Wood @ 2012-01-03 17:10 UTC (permalink / raw)
To: Arshad, Farrukh; +Cc: linuxppc-dev@lists.ozlabs.org
In-Reply-To: <93CD5F41FDBC6042A6B449764F3B35CC050CCA80@EU-MBX-03.mgc.mentorg.com>
On 01/03/2012 03:42 AM, Arshad, Farrukh wrote:
> Adding more to it,
>
>
>
> When I write from Core 1 on the shared memory region it is visible at
> Core 0 and it can read what I have written from Core 1 but when I write
> from Core 0 on this shared memory it is not visible on Core 1.
Is the memory mapped coherent on both cores?
-Scott
^ permalink raw reply
* Re: [RFC PATCH 0/9] Remove useless on_each_cpu return value
From: Gilad Ben-Yossef @ 2012-01-03 16:08 UTC (permalink / raw)
To: Michal Nazarewicz
Cc: linux-ia64, David Airlie, Will Deacon, dri-devel, Paul Mackerras,
H. Peter Anvin, Russell King, x86, Ingo Molnar,
Arnaldo Carvalho de Melo, Matt Turner, Fenghua Yu, Peter Zijlstra,
devicetree-discuss, Rob Herring, Ivan Kokshaysky, Thomas Gleixner,
linux-arm-kernel, Richard Henderson, Tony Luck, linux-kernel,
linux-alpha, linuxppc-dev
In-Reply-To: <op.v7iidbwz3l0zgt@mpn-glaptop>
2012/1/3 Michal Nazarewicz <mina86@mina86.com>:
> On Tue, 03 Jan 2012 15:19:04 +0100, Gilad Ben-Yossef <gilad@benyossef.com=
>
> wrote:
>>
>> on_each_cpu() returns as its own return value the return value of
>> smp_call_function(). smp_call_function() in turn returns a hard
>> coded value of zero.
>>
>> Some callers to on_each_cpu() waste cycles and bloat code space
>> by checking the return value to on_each_cpu(), probably for
>> historical reasons.
>>
>> This patch set refactors callers to not test on_each_cpu()
>> (fixed) return value and then refactors on_each_cpu to
>> return void to avoid confusing future users.
>>
>> In other words, this patch aims to delete 18 source code lines
>> while not changing any functionality :-)
>>
>> I tested as best as I could the x86 changes and compiled some
>> of the others, but I don't have access to all the needed hardware
>> for testing. Reviewers and testers welcome!
>
>
> Other then the lack of Signed-off-by in the patches, looks good to me,
Blimey! I'll resend with a proper Signed-off-by after more people have
a chance to
comment. And thanks for the review.
> even though personally I'd choose a bottom-up approach, ie. make
> smp_call_function() return void and from that conclude that
> on_each_cpu() can return void. =A0With those patches, we have a situation=
,
> where smp_call_function() has a return value which is then lost for no
> immediately apparent reason lost in on_each_cpu().
There are so many call site of smp_call_function() that do not check the
return value right now that I think we can tolerate it for just a
little bit longer
until that get fixed as well... :-)
Thanks,
Gilad
--=20
Gilad Ben-Yossef
Chief Coffee Drinker
gilad@benyossef.com
Israel Cell: +972-52-8260388
US Cell: +1-973-8260388
http://benyossef.com
"Unfortunately, cache misses are an equal opportunity pain provider."
-- Mike Galbraith, LKML
^ permalink raw reply
* Re: [RFC PATCH 0/9] Remove useless on_each_cpu return value
From: Michal Nazarewicz @ 2012-01-03 14:25 UTC (permalink / raw)
To: linux-kernel, Gilad Ben-Yossef
Cc: linux-ia64, David Airlie, Will Deacon, dri-devel, Paul Mackerras,
H. Peter Anvin, Russell King, x86, Ingo Molnar,
Arnaldo Carvalho de Melo, Matt Turner, Fenghua Yu, Peter Zijlstra,
devicetree-discuss, Rob Herring, Ivan Kokshaysky, Thomas Gleixner,
linux-arm-kernel, Richard Henderson, Tony Luck, linux-alpha,
linuxppc-dev
In-Reply-To: <1325600353-10895-1-git-send-email-gilad@benyossef.com>
On Tue, 03 Jan 2012 15:19:04 +0100, Gilad Ben-Yossef <gilad@benyossef.co=
m> wrote:
> on_each_cpu() returns as its own return value the return value of
> smp_call_function(). smp_call_function() in turn returns a hard
> coded value of zero.
>
> Some callers to on_each_cpu() waste cycles and bloat code space
> by checking the return value to on_each_cpu(), probably for
> historical reasons.
>
> This patch set refactors callers to not test on_each_cpu()
> (fixed) return value and then refactors on_each_cpu to
> return void to avoid confusing future users.
>
> In other words, this patch aims to delete 18 source code lines
> while not changing any functionality :-)
>
> I tested as best as I could the x86 changes and compiled some
> of the others, but I don't have access to all the needed hardware
> for testing. Reviewers and testers welcome!
Other then the lack of Signed-off-by in the patches, looks good to me,
even though personally I'd choose a bottom-up approach, ie. make
smp_call_function() return void and from that conclude that
on_each_cpu() can return void. With those patches, we have a situation,=
where smp_call_function() has a return value which is then lost for no
immediately apparent reason lost in on_each_cpu().
-- =
Best regards, _ _
.o. | Liege of Serenely Enlightened Majesty of o' \,=3D./ `o
..o | Computer Science, Micha=C5=82 =E2=80=9Cmina86=E2=80=9D Nazarewicz=
(o o)
ooo +----<email/xmpp: mpn@google.com>--------------ooO--(_)--Ooo--
^ permalink raw reply
* [RFC PATCH 8/9] smp: refactor on_each_cpu to void returning func
From: Gilad Ben-Yossef @ 2012-01-03 14:19 UTC (permalink / raw)
To: linux-kernel
Cc: linux-ia64, David Airlie, Will Deacon, dri-devel, Paul Mackerras,
H. Peter Anvin, Russell King, x86, Ingo Molnar,
Arnaldo Carvalho de Melo, Matt Turner, Fenghua Yu, Peter Zijlstra,
devicetree-discuss, Michal Nazarewicz, Gilad Ben-Yossef,
Ivan Kokshaysky, Rob Herring, Thomas Gleixner, linux-arm-kernel,
Richard Henderson, Tony Luck, linux-alpha, linuxppc-dev
In-Reply-To: <1325600353-10895-1-git-send-email-gilad@benyossef.com>
on_each_cpu returns the retunr value of smp_call_function
which is hard coded to 0.
Refactor on_each_cpu to a void function and the few callers
that check the return value to save compares and branches.
CC: Michal Nazarewicz <mina86@mina86.com>
CC: David Airlie <airlied@linux.ie>
CC: dri-devel@lists.freedesktop.org
CC: Benjamin Herrenschmidt <benh@kernel.crashing.org>
CC: Paul Mackerras <paulus@samba.org>
CC: Grant Likely <grant.likely@secretlab.ca>
CC: Rob Herring <rob.herring@calxeda.com>
CC: linuxppc-dev@lists.ozlabs.org
CC: devicetree-discuss@lists.ozlabs.org
CC: Richard Henderson <rth@twiddle.net>
CC: Ivan Kokshaysky <ink@jurassic.park.msu.ru>
CC: Matt Turner <mattst88@gmail.com>
CC: linux-alpha@vger.kernel.org
CC: Thomas Gleixner <tglx@linutronix.de>
CC: Ingo Molnar <mingo@redhat.com>
CC: "H. Peter Anvin" <hpa@zytor.com>
CC: x86@kernel.org
CC: Tony Luck <tony.luck@intel.com>
CC: Fenghua Yu <fenghua.yu@intel.com>
CC: linux-ia64@vger.kernel.org
CC: Will Deacon <will.deacon@arm.com>
CC: Peter Zijlstra <a.p.zijlstra@chello.nl>
CC: Arnaldo Carvalho de Melo <acme@ghostprotocols.net>
CC: Russell King <linux@arm.linux.org.uk>
CC: linux-arm-kernel@lists.infradead.org
---
include/linux/smp.h | 7 +++----
kernel/smp.c | 6 ++----
2 files changed, 5 insertions(+), 8 deletions(-)
diff --git a/include/linux/smp.h b/include/linux/smp.h
index 8cc38d3..050ddd4 100644
--- a/include/linux/smp.h
+++ b/include/linux/smp.h
@@ -99,7 +99,7 @@ static inline void call_function_init(void) { }
/*
* Call a function on all processors
*/
-int on_each_cpu(smp_call_func_t func, void *info, int wait);
+void on_each_cpu(smp_call_func_t func, void *info, int wait);
/*
* Mark the boot cpu "online" so that it can call console drivers in
@@ -126,12 +126,11 @@ static inline int up_smp_call_function(smp_call_func_t func, void *info)
#define smp_call_function(func, info, wait) \
(up_smp_call_function(func, info))
#define on_each_cpu(func,info,wait) \
- ({ \
+ { \
local_irq_disable(); \
func(info); \
local_irq_enable(); \
- 0; \
- })
+ }
static inline void smp_send_reschedule(int cpu) { }
#define num_booting_cpus() 1
#define smp_prepare_boot_cpu() do {} while (0)
diff --git a/kernel/smp.c b/kernel/smp.c
index db197d6..f66a1b2 100644
--- a/kernel/smp.c
+++ b/kernel/smp.c
@@ -687,17 +687,15 @@ void __init smp_init(void)
* early_boot_irqs_disabled is set. Use local_irq_save/restore() instead
* of local_irq_disable/enable().
*/
-int on_each_cpu(void (*func) (void *info), void *info, int wait)
+void on_each_cpu(void (*func) (void *info), void *info, int wait)
{
unsigned long flags;
- int ret = 0;
preempt_disable();
- ret = smp_call_function(func, info, wait);
+ smp_call_function(func, info, wait);
local_irq_save(flags);
func(info);
local_irq_restore(flags);
preempt_enable();
- return ret;
}
EXPORT_SYMBOL(on_each_cpu);
--
1.7.0.4
^ permalink raw reply related
* [RFC PATCH 5/9] ppc: avoid using on_each_cpu hard coded ret value
From: Gilad Ben-Yossef @ 2012-01-03 14:19 UTC (permalink / raw)
To: linux-kernel
Cc: devicetree-discuss, Rob Herring, Gilad Ben-Yossef, Paul Mackerras,
Michal Nazarewicz, linuxppc-dev
In-Reply-To: <1325600353-10895-1-git-send-email-gilad@benyossef.com>
on_each_cpu always returns a hard coded return code of zero.
Removing all tests based on this return value saves run time
cycles for compares and code bloat for branches.
CC: Michal Nazarewicz <mina86@mina86.com>
CC: Benjamin Herrenschmidt <benh@kernel.crashing.org>
CC: Paul Mackerras <paulus@samba.org>
CC: Grant Likely <grant.likely@secretlab.ca>
CC: Rob Herring <rob.herring@calxeda.com>
CC: linuxppc-dev@lists.ozlabs.org
CC: devicetree-discuss@lists.ozlabs.org
---
arch/powerpc/kernel/rtas.c | 3 +--
1 files changed, 1 insertions(+), 2 deletions(-)
diff --git a/arch/powerpc/kernel/rtas.c b/arch/powerpc/kernel/rtas.c
index 517b1d8..829629e 100644
--- a/arch/powerpc/kernel/rtas.c
+++ b/arch/powerpc/kernel/rtas.c
@@ -850,8 +850,7 @@ int rtas_ibm_suspend_me(struct rtas_args *args)
/* Call function on all CPUs. One of us will make the
* rtas call
*/
- if (on_each_cpu(rtas_percpu_suspend_me, &data, 0))
- atomic_set(&data.error, -EINVAL);
+ on_each_cpu(rtas_percpu_suspend_me, &data, 0);
wait_for_completion(&done);
--
1.7.0.4
^ permalink raw reply related
* [RFC PATCH 0/9] Remove useless on_each_cpu return value
From: Gilad Ben-Yossef @ 2012-01-03 14:19 UTC (permalink / raw)
To: linux-kernel
Cc: linux-ia64, David Airlie, Will Deacon, dri-devel, Paul Mackerras,
H. Peter Anvin, Russell King, x86, Ingo Molnar,
Arnaldo Carvalho de Melo, Matt Turner, Fenghua Yu, Peter Zijlstra,
devicetree-discuss, Michal Nazarewicz, Gilad Ben-Yossef,
Ivan Kokshaysky, Rob Herring, Thomas Gleixner, linux-arm-kernel,
Richard Henderson, Tony Luck, linux-alpha, linuxppc-dev
on_each_cpu() returns as its own return value the return value of
smp_call_function(). smp_call_function() in turn returns a hard
coded value of zero.
Some callers to on_each_cpu() waste cycles and bloat code space
by checking the return value to on_each_cpu(), probably for
historical reasons.
This patch set refactors callers to not test on_each_cpu()
(fixed) return value and then refactors on_each_cpu to
return void to avoid confusing future users.
In other words, this patch aims to delete 18 source code lines
while not changing any functionality :-)
I tested as best as I could the x86 changes and compiled some
of the others, but I don't have access to all the needed hardware
for testing. Reviewers and testers welcome!
CC: Michal Nazarewicz <mina86@mina86.com>
CC: David Airlie <airlied@linux.ie>
CC: dri-devel@lists.freedesktop.org
CC: Benjamin Herrenschmidt <benh@kernel.crashing.org>
CC: Paul Mackerras <paulus@samba.org>
CC: Grant Likely <grant.likely@secretlab.ca>
CC: Rob Herring <rob.herring@calxeda.com>
CC: linuxppc-dev@lists.ozlabs.org
CC: devicetree-discuss@lists.ozlabs.org
CC: Richard Henderson <rth@twiddle.net>
CC: Ivan Kokshaysky <ink@jurassic.park.msu.ru>
CC: Matt Turner <mattst88@gmail.com>
CC: linux-alpha@vger.kernel.org
CC: Thomas Gleixner <tglx@linutronix.de>
CC: Ingo Molnar <mingo@redhat.com>
CC: "H. Peter Anvin" <hpa@zytor.com>
CC: x86@kernel.org
CC: Tony Luck <tony.luck@intel.com>
CC: Fenghua Yu <fenghua.yu@intel.com>
CC: linux-ia64@vger.kernel.org
CC: Will Deacon <will.deacon@arm.com>
CC: Peter Zijlstra <a.p.zijlstra@chello.nl>
CC: Arnaldo Carvalho de Melo <acme@ghostprotocols.net>
CC: Russell King <linux@arm.linux.org.uk>
CC: linux-arm-kernel@lists.infradead.org
Gilad Ben-Yossef (9):
arm: avoid using on_each_cpu hard coded ret value
ia64: avoid using on_each_cpu hard coded ret value
x86: avoid using on_each_cpu hard coded ret value
alpha: avoid using on_each_cpu hard coded ret value
ppc: avoid using on_each_cpu hard coded ret value
agp: avoid using on_each_cpu hard coded ret value
drm: avoid using on_each_cpu hard coded ret value
smp: refactor on_each_cpu to void returning func
x86: refactor wbinvd_on_all_cpus to void function
arch/alpha/kernel/smp.c | 7 ++-----
arch/arm/kernel/perf_event.c | 2 +-
arch/ia64/kernel/perfmon.c | 12 ++----------
arch/powerpc/kernel/rtas.c | 3 +--
arch/x86/include/asm/smp.h | 5 ++---
arch/x86/lib/cache-smp.c | 4 ++--
drivers/char/agp/generic.c | 3 +--
drivers/gpu/drm/drm_cache.c | 3 +--
include/linux/smp.h | 7 +++----
kernel/smp.c | 6 ++----
10 files changed, 17 insertions(+), 35 deletions(-)
^ permalink raw reply
* RE: Problem in getting shared memory access on P1022RDK
From: Arshad, Farrukh @ 2012-01-03 9:42 UTC (permalink / raw)
To: linuxppc-dev@lists.ozlabs.org
In-Reply-To: <93CD5F41FDBC6042A6B449764F3B35CC050CCA22@EU-MBX-03.mgc.mentorg.com>
[-- Attachment #1: Type: text/plain, Size: 1807 bytes --]
Adding more to it,
When I write from Core 1 on the shared memory region it is visible at Core 0 and it can read what I have written from Core 1 but when I write from Core 0 on this shared memory it is not visible on Core 1.
Regards,
Farrukh Arshad
From: Arshad, Farrukh
Sent: Tuesday, January 03, 2012 12:11 AM
To: linuxppc-dev@lists.ozlabs.org
Subject: Problem in getting shared memory access on P1022RDK
Greetings All,
Please excuse me for a 'not very precise' question but I just need some clue or point to look for the trouble.
I am running linux in AMP configuration on P1022RDK dual core. My memory partitioning is given below
Core Base Address (CONFIG_PHYSICAL_START / bootm_low)
Size (bootm_size / mem kernel boot parameter)
Core 0 0x0000,0000
0x1000,0000
Core 1 0x1000,0000
0x0C00,0000
Shared Memory 0x1C00,0000
0x0400,0000
I have set bootm_low / bootm_size and provided mem parameter in both kernel configurations, both
kernels are booting up fine. I have a shared memory driver running in both cores. My shared memory
driver just exposes the physical memory (0x1C00,0000) to user-space.
The problem I am facing is I can not get access to same shared memory in user-space on both kernels.
I have verified my shared memory driver on another platform (p1022ds) and it works perfect. I have also
tried using non-cached memory mapping in shared memory driver but that does not work as well.
To me it seems one of my kernels is going beyond its defined memory partition (which I have set above), I have
set kernel's partitioning as CONFIG_PHYSICAL_START, bootm_size, bootm_low and mem kernel boot param.
Besides the shared memory driver, can anyone suggest or give me clue where should I look for the
trouble in the kernel.
Regards,
Farrukh Arshad.
[-- Attachment #2: Type: text/html, Size: 9938 bytes --]
^ permalink raw reply
* Re: [PATCH powerpc] fix unpaired __trace_hcall_entry and __trace_hcall_exit
From: Benjamin Herrenschmidt @ 2012-01-03 0:54 UTC (permalink / raw)
To: Li Zhong
Cc: PowerPC email list, Paul E. McKenney, Paul Mackerras, LKML,
Anton Blanchard
In-Reply-To: <1324260407.3006.17.camel@ThinkPad-T61>
On Mon, 2011-12-19 at 10:06 +0800, Li Zhong wrote:
> Unpaired calling of __trace_hcall_entry and __trace_hcall_exit could
> cause incorrect preempt count. And it might happen as the global
> variable hcall_tracepoint_refcount is checked separately before calling
> them.
>
> I don't know much about the powerpc arch. But the idea here is to store
> the hcall_tracepoint_refcount locally, so __trace_hcall_entry and
> __trace_hcall_exit will be called or not called in pair by checking the
> same value.
Can you re-use an existing spot in the stack frame rather than adding
this entry ? There's plenty of unused spots :-) For example the link
editor doubleword is never going to be used in that function, we could
hijack it safely. It would make the patch (and the code) simpler.
Cheers,
Ben.
> Reported-by: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
> Signed-off-by: Li Zhong <zhong@linux.vnet.ibm.com>
> Tested-by: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
> ---
> arch/powerpc/platforms/pseries/hvCall.S | 20 +++++++++++---------
> 1 files changed, 11 insertions(+), 9 deletions(-)
>
> diff --git a/arch/powerpc/platforms/pseries/hvCall.S b/arch/powerpc/platforms/pseries/hvCall.S
> index fd05fde..1240bd2 100644
> --- a/arch/powerpc/platforms/pseries/hvCall.S
> +++ b/arch/powerpc/platforms/pseries/hvCall.S
> @@ -14,6 +14,7 @@
> #include <asm/ptrace.h>
>
> #define STK_PARM(i) (48 + ((i)-3)*8)
> +#define REG_SIZE (2*8)
>
> #ifdef CONFIG_TRACEPOINTS
>
> @@ -32,11 +33,12 @@ hcall_tracepoint_refcount:
> * unconditional cpu feature.
> */
> #define HCALL_INST_PRECALL(FIRST_REG) \
> + std r31,-8(r1); \
> BEGIN_FTR_SECTION; \
> b 1f; \
> END_FTR_SECTION(0, 1); \
> - ld r12,hcall_tracepoint_refcount@toc(r2); \
> - cmpdi r12,0; \
> + ld r31,hcall_tracepoint_refcount@toc(r2); \
> + cmpdi r31,0; \
> beq+ 1f; \
> mflr r0; \
> std r3,STK_PARM(r3)(r1); \
> @@ -49,9 +51,9 @@ END_FTR_SECTION(0, 1); \
> std r10,STK_PARM(r10)(r1); \
> std r0,16(r1); \
> addi r4,r1,STK_PARM(FIRST_REG); \
> - stdu r1,-STACK_FRAME_OVERHEAD(r1); \
> + stdu r1,-STACK_FRAME_OVERHEAD-REG_SIZE(r1); \
> bl .__trace_hcall_entry; \
> - addi r1,r1,STACK_FRAME_OVERHEAD; \
> + addi r1,r1,STACK_FRAME_OVERHEAD+REG_SIZE; \
> ld r0,16(r1); \
> ld r3,STK_PARM(r3)(r1); \
> ld r4,STK_PARM(r4)(r1); \
> @@ -74,8 +76,7 @@ END_FTR_SECTION(0, 1); \
> BEGIN_FTR_SECTION; \
> b 1f; \
> END_FTR_SECTION(0, 1); \
> - ld r12,hcall_tracepoint_refcount@toc(r2); \
> - cmpdi r12,0; \
> + cmpdi r31,0; \
> beq+ 1f; \
> mflr r0; \
> ld r6,STK_PARM(r3)(r1); \
> @@ -83,13 +84,14 @@ END_FTR_SECTION(0, 1); \
> mr r4,r3; \
> mr r3,r6; \
> std r0,16(r1); \
> - stdu r1,-STACK_FRAME_OVERHEAD(r1); \
> + stdu r1,-STACK_FRAME_OVERHEAD-REG_SIZE(r1); \
> bl .__trace_hcall_exit; \
> - addi r1,r1,STACK_FRAME_OVERHEAD; \
> + addi r1,r1,STACK_FRAME_OVERHEAD+REG_SIZE; \
> ld r0,16(r1); \
> ld r3,STK_PARM(r3)(r1); \
> mtlr r0; \
> -1:
> +1: \
> + ld r31,-8(r1);
>
> #define HCALL_INST_POSTCALL_NORETS \
> li r5,0; \
^ permalink raw reply
* Re: [PATCH] DTS: fix the bug and add the chip compatible for eSDHC
From: Tabi Timur-B04825 @ 2012-01-02 20:30 UTC (permalink / raw)
To: Huang Changming-R66093
Cc: Huang Changming-R66093, linuxppc-dev@lists.ozlabs.org
In-Reply-To: <1324620659-7135-1-git-send-email-r66093@freescale.com>
On Fri, Dec 23, 2011 at 12:10 AM, <r66093@freescale.com> wrote:
>
> Accordint to latest kernel, the auto-cmd12 property should be
> "sdhci,auto-cmd12", and according to the SDHC binding and the workaround =
for
> the special chip, add the chip compatible for eSDHC: "fsl,p1022-esdhc",
> "fsl,mpc8536-esdhc", "fsl,p2020-esdhc" and "fsl,p1010-esdhc".
Please do not use the phrase "fix the bug" in patch summaries.
--=20
Timur Tabi
Linux kernel developer at Freescale=
^ permalink raw reply
* Problem in getting shared memory access on P1022RDK
From: Arshad, Farrukh @ 2012-01-02 19:10 UTC (permalink / raw)
To: linuxppc-dev@lists.ozlabs.org
[-- Attachment #1: Type: text/plain, Size: 1381 bytes --]
Greetings All,
Please excuse me for a 'not very precise' question but I just need some clue or point to look for the trouble.
I am running linux in AMP configuration on P1022RDK dual core. My memory partitioning is given below
Core Base Address (CONFIG_PHYSICAL_START / bootm_low) Size (bootm_size / mem kernel boot parameter)
Core 0 0x0000,0000 0x1000,0000
Core 1 0x1000,0000 0x0C00,0000
Shared Memory 0x1C00,0000 0x0400,0000
I have set bootm_low / bootm_size and provided mem parameter in both kernel configurations, both
kernels are booting up fine. I have a shared memory driver running in both cores. My shared memory
driver just exposes the physical memory (0x1C00,0000) to user-space.
The problem I am facing is I can not get access to same shared memory in user-space on both kernels.
I have verified my shared memory driver on another platform (p1022ds) and it works perfect. I have also
tried using non-cached memory mapping in shared memory driver but that does not work as well.
To me it seems one of my kernels is going beyond its defined memory partition (which I have set above), I have
set kernel's partitioning as CONFIG_PHYSICAL_START, bootm_size, bootm_low and mem kernel boot param.
Besides the shared memory driver, can anyone suggest or give me clue where should I look for the
trouble in the kernel.
Regards,
Farrukh Arshad.
[-- Attachment #2: Type: text/html, Size: 2532 bytes --]
^ permalink raw reply
* Re: [PATCH] DTS: fix the bug and add the chip compatible for eSDHC
From: Scott Wood @ 2012-01-02 18:27 UTC (permalink / raw)
To: r66093; +Cc: Jerry Huang, linuxppc-dev
In-Reply-To: <1324620659-7135-1-git-send-email-r66093@freescale.com>
On 12/23/2011 12:10 AM, r66093@freescale.com wrote:
> From: Jerry Huang <Chang-Ming.Huang@freescale.com>
>
> Accordint to latest kernel, the auto-cmd12 property should be
> "sdhci,auto-cmd12", and according to the SDHC binding and the workaround for
> the special chip, add the chip compatible for eSDHC: "fsl,p1022-esdhc",
> "fsl,mpc8536-esdhc", "fsl,p2020-esdhc" and "fsl,p1010-esdhc".
>
> Signed-off-by: Jerry Huang <Chang-Ming.Huang@freescale.com>
> ---
> arch/powerpc/boot/dts/fsl/mpc8536si-post.dtsi | 4 ++++
> arch/powerpc/boot/dts/fsl/p1010si-post.dtsi | 3 ++-
> arch/powerpc/boot/dts/fsl/p1022si-post.dtsi | 3 ++-
> arch/powerpc/boot/dts/fsl/p2020si-post.dtsi | 4 ++++
> 4 files changed, 12 insertions(+), 2 deletions(-)
>
> diff --git a/arch/powerpc/boot/dts/fsl/mpc8536si-post.dtsi b/arch/powerpc/boot/dts/fsl/mpc8536si-post.dtsi
> index 89af626..44e0ed9 100644
> --- a/arch/powerpc/boot/dts/fsl/mpc8536si-post.dtsi
> +++ b/arch/powerpc/boot/dts/fsl/mpc8536si-post.dtsi
> @@ -236,6 +236,10 @@
> };
>
> /include/ "pq3-esdhc-0.dtsi"
> + sdhc@2e000 {
> + compatible = "fsl,esdhc", "fsl,mpc8536-esdhc";
> + };
More-specific compatible entries should come first.
-Scott
^ permalink raw reply
* Re: Mac address in the DTS file
From: Scott Wood @ 2012-01-02 17:53 UTC (permalink / raw)
To: smitha.vanga; +Cc: linuxppc-dev
In-Reply-To: <40631E9A2581F14BA60888C87A76A1FE01C6BB@HYD-MKD-MBX4.wipro.com>
On 12/30/2011 06:51 AM, smitha.vanga@wipro.com wrote:
>
> Hi Scott,
>
> In my DTS file for mpc8247 I have defined the ether MAC in the node as below.
>
> ethernet@24000 {
> #address-cells = <1>;
> #size-cells = <0>;
> device_type = "network";
> device-id = <1>;
> compatible = "fs_enet";
> model = "FCC";
> reg = <11300 20 8400 100 11380 30>;
> mac-address = [ 00 e0 ee 00 05 2e ];
> interrupts = <20 2>;
> interrupt-parent = <10c00>;
> phy-handle = <2452000>;
> rx-clock = <13>;
> tx-clock = <12>;
> };
Others have answered your question (the mac address should not be in the
.dts file -- it should be patched in by boot software), but I'd like to
point out that this is a deprecated device tree binding that was very
short-lived in a very old kernel, from an early attempt at 82xx support
in arch/powerpc. Why are you still using it? It will not work with
current kernels (which suggests you're also using a very old kernel).
-Scott
^ permalink raw reply
* Re: [PATCH 1/2][v2] Integrated Flash Controller support
From: Scott Wood @ 2012-01-02 17:31 UTC (permalink / raw)
To: dpervushin; +Cc: Liu Shuo, linuxppc-dev, Prabhakar Kushwaha
In-Reply-To: <1325079052.12535.22.camel@mrki-medvjed.diimka.lan>
On 12/28/2011 07:30 AM, dmitry pervushin wrote:
> If you're using memory-mapped structure, shouldn't it be announced with
> __attribute__(packed) ?
Why? We know this isn't going to be compiled on some strange ABI where
a struct with nothing but u32 gets padding. __attribute__((packed))
also tells GCC the struct itself could be unaligned which is not true.
-Scott
^ 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