* Re: Problems of using APU/FPU under linux
From: Yoshio Kashiwagi @ 2008-04-15 18:20 UTC (permalink / raw)
To: Shanyuan Gao, John Bonesio, Stephen Neuendorffer,
linuxppc-embedded
In-Reply-To: <1B35E815-094F-40CB-AEDA-C04A6CBECC07@gmail.com>
Hi,
The following modification is required if you use APU in user space.
in include/asm-powerpc/reg.h
-#define MSR_USER (MSR_KERNEL|MSR_PR|MSR_EE)
+#define MSR_USER (MSR_KERNEL|MSR_PR|MSR_EE|MSR_VEC)
Yoshio Kashiwagi - Nissin Systems
> Thank you very much, Steve and John!
>
> My advisor and I discussed how Linux works with APU/FPU a few days ago.
And he had the same thoughts with John. My naive guess was it would
automatically decode FP operations and mask the trap. Now it answers my
second question. I will try it later.
>
> But for my first question, I searched all (almost all) the files, such
as head.S, entry.S, head_4xx.S, etc. And added following three lines
before mtmsr or MTMSRD
^ permalink raw reply
* RE: Problems of using APU/FPU under linux
From: Stephen Neuendorffer @ 2008-04-15 18:37 UTC (permalink / raw)
To: Shanyuan Gao, Yoshio Kashiwagi, linuxppc-embedded
In-Reply-To: <607F58E8-CB29-4BD7-9886-DF3C8B495ED7@gmail.com>
U2hhbnl1YW4sDQoNCkRpZCB5b3UgaW5zdGFsbCB0aGUgRlBVX1VOQVZBSUxBQkxFIHRyYXAgaW4g
aGVhZF80MHguUz8NCg0KDQo+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+IEZyb206IFNo
YW55dWFuIEdhbyBbbWFpbHRvOnN5Z2FvLnJlc2VhcmNoQGdtYWlsLmNvbV0NCj4gU2VudDogVHVl
c2RheSwgQXByaWwgMTUsIDIwMDggMTE6MzQgQU0NCj4gVG86IFlvc2hpbyBLYXNoaXdhZ2k7IGxp
bnV4cHBjLWVtYmVkZGVkQG96bGFicy5vcmcNCj4gQ2M6IFN0ZXBoZW4gTmV1ZW5kb3JmZmVyOyBK
b2huIEJvbmVzaW8NCj4gU3ViamVjdDogUmU6IFByb2JsZW1zIG9mIHVzaW5nIEFQVS9GUFUgdW5k
ZXIgbGludXgNCj4gDQo+IFRoYW5rIHlvdSwgWW9zaGlvISENCj4gDQo+IEkganVzdCBhcHBsaWVk
IHRoZSBjaGFuZ2UsIHNlZW1zIGl0IHdvcmtzISBCdXQgaXQgZG9lc24ndCB3b3JrDQo+IGNvcnJl
Y3RseS4gSSBtZWFuIGl0IHdvbid0IGdpdmUgbWUgdHJhcHMgYW55IG1vcmUsIGJ1dCB0aGUgYW5z
d2VyIGlzDQo+IG5vdCBjb3JyZWN0bHkuIEkganVzdCB0cmllZCB0byBtdWx0aXBseSB0d28gZmxv
YXQgbnVtYmVycy4gQnV0IGl0DQo+IGdpdmVzIG1lIDAuDQo+IA0KPiBUaGUgZmlyc3QgdGltZSBJ
IGNoYW5nZSB0aGUgcmVnLmggd2FzIHRvIGVuYWJsZSBhcHUgZW5hYmxlLCBhcHUNCj4gZXhjZXB0
aW9uIGVuYWJsZSBhbmQgZnB1IGVuYWJsZS4gSXQgZ2l2ZXMgbWUgYW5zd2VyIDAuDQo+IFRoZSBz
ZWNvbmQgdHJ5IEkgZGlkIHdhcyBlbmFibGluZyBhcHUgZW5hYmxlIGFuZCBhcHUgZXhjZXB0aW9u
LA0KPiBiZWNhdXNlIEkgbm90aWNlIHRoYXQgaW5zaWRlIC9hcmNoL3Bvd2VycGMva2VybmVsL2Zw
dS5TLCBpdCB3aWxsDQo+IGVuYWJsZSBGUFUgaW4gbG9hZF91cF9mcHUuIFNvIEkgZ3Vlc3MgSSBj
YW5ub3QgZW5hYmxlIEZQVSBhbGwgdGhlDQo+IHRpbWUuIEhvd2V2ZXIsIHRoaXMgdGltZSBpdCBn
YXZlIG1lIHRyYXAgYWdhaW4sIHdlbGwsIHdpdGggYQ0KPiBkaWZmZXJlbnQgTVNSLg0KPiANCj4g
Tm93IG15IGd1ZXNzIGlzIGxvYWRfdXBfZnB1IGlzIG5vdCB3b3JraW5nIGNvcnJlY3RseS4gSSBh
bSB3b3JraW5nIG9uDQo+IHRoYXQuDQo+IA0KPiANCj4gU2hhbg0KPiANCj4gDQo+IA0KPiBPbiBB
cHIgMTUsIDIwMDgsIGF0IDI6MjAgUE0sIFlvc2hpbyBLYXNoaXdhZ2kgd3JvdGU6DQo+IA0KPiA+
IEhpLA0KPiA+DQo+ID4gVGhlIGZvbGxvd2luZyBtb2RpZmljYXRpb24gaXMgcmVxdWlyZWQgaWYg
eW91IHVzZSBBUFUgaW4gdXNlciBzcGFjZS4NCj4gPg0KPiA+IGluIGluY2x1ZGUvYXNtLXBvd2Vy
cGMvcmVnLmgNCj4gPg0KPiA+IC0jZGVmaW5lIE1TUl9VU0VSICAgKE1TUl9LRVJORUx8TVNSX1BS
fE1TUl9FRSkNCj4gPiArI2RlZmluZSBNU1JfVVNFUiAgIChNU1JfS0VSTkVMfE1TUl9QUnxNU1Jf
RUV8TVNSX1ZFQykNCj4gPg0KPiA+IFlvc2hpbyBLYXNoaXdhZ2kgLSBOaXNzaW4gU3lzdGVtcw0K
PiA+DQo+ID4+IFRoYW5rIHlvdSB2ZXJ5IG11Y2gsIFN0ZXZlIGFuZCBKb2huIQ0KPiA+Pg0KPiA+
PiBNeSBhZHZpc29yIGFuZCBJIGRpc2N1c3NlZCBob3cgTGludXggd29ya3Mgd2l0aCBBUFUvRlBV
IGEgZmV3IGRheXMNCj4gPj4gYWdvLg0KPiA+ICBBbmQgaGUgaGFkIHRoZSBzYW1lIHRob3VnaHRz
IHdpdGggSm9obi4gTXkgbmFpdmUgZ3Vlc3Mgd2FzIGl0IHdvdWxkDQo+ID4gYXV0b21hdGljYWxs
eSBkZWNvZGUgRlAgb3BlcmF0aW9ucyBhbmQgbWFzayB0aGUgdHJhcC4gTm93IGl0DQo+ID4gYW5z
d2VycyBteQ0KPiA+IHNlY29uZCBxdWVzdGlvbi4gSSB3aWxsIHRyeSBpdCBsYXRlci4NCj4gPj4N
Cj4gPj4gQnV0IGZvciBteSBmaXJzdCBxdWVzdGlvbiwgSSBzZWFyY2hlZCBhbGwgKGFsbW9zdCBh
bGwpIHRoZSBmaWxlcywNCj4gPj4gc3VjaA0KPiA+IGFzIGhlYWQuUywgZW50cnkuUywgaGVhZF80
eHguUywgZXRjLiBBbmQgYWRkZWQgZm9sbG93aW5nIHRocmVlIGxpbmVzDQo+ID4gYmVmb3JlIG10
bXNyIG9yIE1UTVNSRCDvv71hcmUgdXNlZA0KPiA+Pg0KPiA+PiBvcmkg77+9IO+/vSDvv70g77+9
cjEwLCByMTAsIDE8PDEzIO+/vS8qIGVuYWJsZSBmcHUgKi8NCj4gPj4gb3JpcyDvv70g77+9IO+/
vXIxMCwgcjEwLCAxPDw5IO+/vSDvv70vKiBlbmFibGUgYXB1ICovDQo+ID4+IG9yaXMg77+9IO+/
vSDvv71yMTAsIHIxMCwgMTw8MyDvv70g77+9LyogZW5hYmxlIGFwdSBleGNlcHRpb24gKi8NCj4g
Pj4NCj4gPj4gSG93ZXZlciB0aGUgTVNSIGluIHRyYXAgcHJvbXB0cyBrZWVwcyB0aGUgc2FtZSAo
MmQwMzApIGJlZm9yZSBhbmQNCj4gPiBhZnRlciBJIGFkZGVkIHRob3NlIGxpbmVzLu+/vQ0KPiA+
Pg0KPiA+PiBb77+977+9IDMxLjgxOTA3OV0gQmFkIHRyYXAgYXQgUEM6IDEwMDAwNDU4LCBNU1I6
IDJkMDMwLA0KPiA+PiB2ZWN0b3I9ODAw77+977+977+9IE5vdA0KPiA+IHRhaW50ZWQNCj4gPj4g
W++/ve+/vSAzMS44ODcwMjdd77+977+9IFNpZ25hbDogNQ0KPiA+PiBb77+977+9IDMxLjg4NzA0
Ml3vv73vv70gQ29kZTrvv73vv70gMA0KPiA+PiBb77+977+9IDMxLjg4NzA1OF3vv73vv70gQWRk
cjrvv73vv70gMA0KPiA+PiBUcmFjZS9icmVha3BvaW50IHRyYXANCj4gPj4NCj4gPj4gSSBndWVz
cyB0aGVyZSBtdXN0IGJlIHNvbWUgcGxhY2VzLCBsaWtlIHNvbWUgaW50ZXJydXB0cyB0aGF0IGNo
YW5nZWQNCj4gPiB0aGUgTVNSIHRoYXQgSSBkaWRuJ3Qga25vdy4g77+9DQo+ID4+DQo+ID4+IEFu
ZCBmb3IgRlAgZXhjZXB0aW9ucywgaXQgaGFzIHR3byBiaXRzICh0d28gbW9kZXMpIGluIE1TUi4g
SSB0aGluaw0KPiA+IHRoZXkgYXJlIGZvciBzdWNoIGV4Y2VwdGlvbnMgbGlrZSBkaXZpZGVkIGJ5
IHplcm8uIERvIEkgbmVlZCB0byBzZXQNCj4gPiB0aGVtDQo+ID4gYWxzbz8NCj4gPj4NCj4gPj4g
SW4gbXkgcHJldmlvdXMgYnVpbGQsIEkgYWxzbyBhZGRlZCBQUENfRlBVIHVuZGVyIGNvbmZpZyA0
MHggaW4gYXJjaC8NCj4gPiBwcGMvS2NvbmZpZy4gSXQgY29tcGlsZWQgYXJjaC9wb3dlcnBjL2tl
cm5lbC9mcHUuUyBpbiwgYnV0IGRpZG4ndA0KPiA+IGhlbHAuDQo+ID4gSSB3aWxsIHRyeSBDT05G
SUdfUFBDX0ZQVSBsYXRlci4NCj4gPj4NCj4gPj4NCj4gPj4gU2hhbg0KPiA+Pg0KPiA+PiBPbiBB
cHIgMTQsIDIwMDgsIGF0IDI6MzIgUE0sIEpvaG4gQm9uZXNpbyB3cm90ZToNCj4gPj4NCj4gPj4g
SGksDQo+ID4+DQo+ID4+IFRoZSBMaW51eCBrZXJuZWwgaXRzZWxmIGRvZXNuJ3QgaXNzdWUgZmxv
YXRpbmcgcG9pbnQgaW5zdHJ1Y3Rpb25zDQo+ID4gb3RoZXIgdGhhbiB0byBzYXZlIGFuZCByZXN0
b3JlIHRoZSBmcHUgc3RhdGUgd2hlbiBuZWNlc3NhcnkuDQo+ID4+DQo+ID4+IEluIExpbnV4LCB0
aGUgd2F5IGl0IHNhdmVzIGFuZCByZXN0b3JlcyB0aGUgZnB1IHN0YXRlIGlzIHRvIG1ha2UgdXNl
DQo+ID4gb2YgdGhlIHRyYXAuIFdoZW4gdGhlIHRyYXAgKGZwdSB1bmF2YWlsYWJsZSkgb2NjdXJz
LCBpdCBsb2FkcyB0aGUgZnB1DQo+ID4gc3RhdGUgZm9yIHRoZSBjdXJyZW50IHRhc2ssIHNldHMg
dXAgdGhlIE1TUiwgYW5kIHJldHVybnMgdG8gcmUtdHJ5IHRoZQ0KPiA+IGluc3RydWN0aW9uLg0K
PiA+Pg0KPiA+PiBTbywgZ2V0dGluZyB0aGUgdHJhcCBpcyBub3JtYWwuIElmIHRoZSBGUFUgaXMg
bm90IGJlaW5nIHNldCB1cA0KPiA+IGNvcnJlY3RseSwgdGhlbiB0aGVyZSBtYXkgYmUgYSBwcm9i
bGVtIHdpdGggdGhlIHJlc3RvcmluZyBvZiB0aGUNCj4gPiBzdGF0ZS4NCj4gPj4NCj4gPj4gV2hl
biB5b3UgZ3VpbGQgdGhlIExpbnV4IGtlcm5lbCwgeW91IG5lZWQgdG8gaGF2ZSBDT05GSUdfUFBD
X0ZQVQ0KPiA+IGVuYWJsZWQuIE90aGVyd2lzZSB0aGUga2VybmVsIGRvZXMgbm90IHNldHVwIHRo
ZSBmcHUgZXhjZXB0aW9uDQo+ID4gaGFuZGxpbmcuDQo+ID4+DQo+ID4+IC0gSm9obg0KPiA+Pg0K
PiA+Pg0KPiA+PiBPbiBNb25kYXkgMTQgQXByaWwgMjAwOCAxMDozNSwgU3RlcGhlbiBOZXVlbmRv
cmZmZXIgd3JvdGU6DQo+ID4+DQo+ID4+IEknbSBub3Qgc3VyZSBleGFjdGx5IHdoYXQncyBnb2lu
ZyBvbiBoZXJlLu+/vSBHZW5lcmFsbHkgc3BlYWtpbmcsDQo+ID4+IGlmIHlvdQ0KPiA+PiBoYXZl
IHRoZSBGUFUgaW5zdGFudGlhdGVkIGluIHRoZSBkZXNpZ24gYW5kIGVuYWJsZSB0aGUgQVBVIGlu
IHRoZQ0KPiA+PiBtc3IsDQo+ID4+IHRoZW4gdGhlIHByb2Nlc3NvciBzaG91bGQgZGVjb2RlIEZQ
IGluc3RydWN0aW9ucyBhbmQgc2VuZCB0aGVtDQo+ID4gZGlyZWN0bHkNCj4gPj4gdG8gdGhlIEFQ
VSB3aXRoIG5vIHRyYXAu77+9IEkgaGF2ZW4ndCBkb25lIHRoaXMgbXlzZWxmLCBvciBJIGNvdWxk
DQo+ID4+IHByb2JhYmx5IGdpdmUgeW91IHNvbWUgYmV0dGVyIGhlbHAuLi4NCj4gPj4NCj4gPj4g
T25lIHRoaW5nIHlvdSBzaG91bGQgYmUgYXdhcmUgb2YgaXMgdGhhdCB0aGUgdGhlcmUgYXJlIGdj
YyBjb21waWxlcg0KPiA+PiBwYXRjaGVzIHdoaWNoIGFyZSBuZWNlc3NhcnkgdG8gZ2V0IHRoZSBG
UFUgd29ya2luZyBwcm9wZXJseS7vv70NCj4gPj4gSG93ZXZlciwNCj4gPiBJDQo+ID4+IGRvbid0
IHRoaW5rIHRoZSBmYWlsdXJlIG1vZGUgdGhhdCB0aGVzZSBwYXRjaGVzIHdvcmthcm91bmQgd291
bGQNCj4gPj4gY2F1c2UNCj4gPiBhDQo+ID4+IHRyYXAsIHNvIG15IGd1ZXNzIGlzIHRoYXQgdGhl
cmUgaXMgc3RpbGwgc29tZXRoaW5nIGVsc2Ugd3JvbmcuDQo+ID4+DQo+ID4+IFN0ZXZlDQo+ID4+
DQo+ID4+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+ID4+IEZyb206IGxpbnV4cHBjLWVt
YmVkZGVkLWJvdW5jZXMrc3RlcGhlbj1uZXVlbmRvcmZmZXIubmFtZUBvemxhYnMub3JnDQo+ID4+
IFttYWlsdG86bGludXhwcGMtZW1iZWRkZWQtDQo+ID4+IGJvdW5jZXMrc3RlcGhlbj1uZXVlbmRv
cmZmZXIubmFtZUBvemxhYnMub3JnXSBPbiBCZWhhbGYgT2YgU2hhbnl1YW4NCj4gPj4gR2FvDQo+
ID4+IFNlbnQ6IE1vbmRheSwgQXByaWwgMTQsIDIwMDggOToxOCBBTQ0KPiA+PiBUbzogbGludXhw
cGMtZW1iZWRkZWRAb3psYWJzLm9yZw0KPiA+PiBTdWJqZWN0OiBQcm9ibGVtcyBvZiB1c2luZyBB
UFUvRlBVIHVuZGVyIGxpbnV4DQo+ID4+DQo+ID4+IEhpLA0KPiA+Pg0KPiA+PiBSZWNlbnRseSBJ
IHdhcyB0cnlpbmcgdG8gbWFrZSBBUFUvRlBVIHdvcmtpbmcgdW5kZXIgTGludXggb24gWGlsaW54
DQo+ID4+IE1MNDEwLiBUaGUgc3RhbmRhbG9uZSBwcm9ncmFtcyB3b3JrIHBlcmZlY3RseS4gSG93
ZXZlciB1bmRlciBMaW51eCwNCj4gPj4gd2hlbiBJIHRyeSB0byB1c2UgYSBmbG9hdGluZyBwb2lu
dCBvcGVyYXRpb24sIGxpa2UgKmZtdWxzKiwgaXQgd2lsbA0KPiA+PiBnaXZlIG1lIGEgKnRyYXAq
Lg0KPiA+Pg0KPiA+PiBCeSBzdHVkeWluZyB0aGUgdXNlciBndWlkZSBmcm9tIFhpbGlueCBhbmQg
ZHVtcGluZyB0aGUgb2JqZWN0IGZpbGVzLA0KPiA+PiBJIGtub3cgSSBuZWVkIHRvIGNoYW5nZSB0
aGUgY29ycmVzcG9uZGluZyBiaXRzIChBUFUgZW5hYmxlLCBGUA0KPiA+PiBlbmFibGUsIG1heWJl
IEFQVSBFeGNlcHRpb24gZW5hYmxlKSBpbiBNYWNoaW5lIFN0YXRlIFJlZ2lzdGVyLiBJDQo+ID4+
IGd1ZXNzIEkgbmVlZCB0byBlbmFibGUgdGhlIGJpdHMgd2hlbmV2ZXIgYmVmb3JlIHRoZSBrZXJu
ZWwgdXNlcw0KPiA+PiAqbXRtc3IqLiBIb3dldmVyLCBpdCBkb2Vzbid0IHdvcmsuIEkgZ290IHRo
ZSBzYW1lIHRyYXAgd2l0aCB0aGUgc2FtZQ0KPiA+PiBNU1IsIGFzIEkgaGFkIG5vIEFQVS9GUFUg
YmVmb3JlLiBJIGFsc28gdHJpZWQgdG8gYWRkIHRoZSBGUFUuUyB0byBwcGMNCj4gPj4gdHJlZSwg
YnV0IGl0IGRvZXNuJ3Qgd29yayBlaXRoZXIuDQo+ID4+DQo+ID4+IFRoZSBxdWVzdGlvbnMgYXJl
DQo+ID4+IDEuIEkgZ3Vlc3MgdGhlcmUgbWlnaHQgYmUgc29tZSBwbGFjZSB0aGF0IGNoYW5nZWQg
TVNSIGFmdGVyIGFsbCBteQ0KPiA+PiBjaGFuZ2VzLiBCdXQgSSBkb24ndCBrbm93IHdoZXJlLiBB
bmQgY2FuIEkgd3JpdGUgYSBrZXJuZWwgbW9kdWxlIHRvDQo+ID4+IGNoYW5nZSB0aGUgTVNSIGFm
dGVyIGJvb3RpbmcgaW4gTGludXg/ICh3ZWxsLCBpdCdzIGhhcmQgZm9yIG1lDQo+ID4+IHRob3Vn
aCkNCj4gPj4NCj4gPj4gMi4gRG9lcyBpdCBoYXZlIGFueSBleGNlcHRpb24vaW50ZXJydXB0IG1l
Y2hhbmlzbSB0byBkaXJlY3QgRlANCj4gPj4gb3BlcmF0aW9uIHRvIEFQVS9GUFU/IE9yIGFmdGVy
IGVuYWJsaW5nIEFQVS9GUFUgaXQgd2lsbCBtYXNrIHRoZQ0KPiA+PiBleGNlcHRpb24vaW50ZXJy
dXB0IGFuZCBkZWNvZGUgRlAgb3BlcmF0aW9uIGJ5IGl0c2VsZj8NCj4gPj4NCj4gPj4NCj4gPj4g
QW55IGlkZWFzIGFyZSBhcHByZWNpYXRlZC4gVGhhbmsgeW91IHZlcnkgbXVjaCENCj4gPj4NCj4g
Pj4NCj4gPj4gU2hhbg0KPiA+DQo+IA0KDQo=
^ permalink raw reply
* Re: Problems of using APU/FPU under linux
From: Shanyuan Gao @ 2008-04-15 18:34 UTC (permalink / raw)
To: Yoshio Kashiwagi, linuxppc-embedded; +Cc: John Bonesio, Stephen Neuendorffer
In-Reply-To: <JO200804160320143.12198109@co-nss.co.jp>
Thank you, Yoshio!!
I just applied the change, seems it works! But it doesn't work =20
correctly. I mean it won't give me traps any more, but the answer is =20
not correctly. I just tried to multiply two float numbers. But it =20
gives me 0.
The first time I change the reg.h was to enable apu enable, apu =20
exception enable and fpu enable. It gives me answer 0.
The second try I did was enabling apu enable and apu exception, =20
because I notice that inside /arch/powerpc/kernel/fpu.S, it will =20
enable FPU in load_up_fpu. So I guess I cannot enable FPU all the =20
time. However, this time it gave me trap again, well, with a =20
different MSR.
Now my guess is load_up_fpu is not working correctly. I am working on =20=
that.
Shan
On Apr 15, 2008, at 2:20 PM, Yoshio Kashiwagi wrote:
> Hi,
>
> The following modification is required if you use APU in user space.
>
> in include/asm-powerpc/reg.h
>
> -#define MSR_USER (MSR_KERNEL|MSR_PR|MSR_EE)
> +#define MSR_USER (MSR_KERNEL|MSR_PR|MSR_EE|MSR_VEC)
>
> Yoshio Kashiwagi - Nissin Systems
>
>> Thank you very much, Steve and John!
>>
>> My advisor and I discussed how Linux works with APU/FPU a few days =20=
>> ago.
> And he had the same thoughts with John. My naive guess was it would
> automatically decode FP operations and mask the trap. Now it =20
> answers my
> second question. I will try it later.
>>
>> But for my first question, I searched all (almost all) the files, =20
>> such
> as head.S, entry.S, head_4xx.S, etc. And added following three lines
> before mtmsr or MTMSRD =EF=BF=BDare used
>>
>> ori =EF=BF=BD =EF=BF=BD =EF=BF=BD =EF=BF=BDr10, r10, 1<<13 =EF=BF=BD/* =
enable fpu */
>> oris =EF=BF=BD =EF=BF=BD =EF=BF=BDr10, r10, 1<<9 =EF=BF=BD =EF=BF=BD/* =
enable apu */
>> oris =EF=BF=BD =EF=BF=BD =EF=BF=BDr10, r10, 1<<3 =EF=BF=BD =EF=BF=BD/* =
enable apu exception */
>>
>> However the MSR in trap prompts keeps the same (2d030) before and
> after I added those lines.=EF=BF=BD
>>
>> [=EF=BF=BD=EF=BF=BD 31.819079] Bad trap at PC: 10000458, MSR: 2d030, =20=
>> vector=3D800=EF=BF=BD=EF=BF=BD=EF=BF=BD Not
> tainted
>> [=EF=BF=BD=EF=BF=BD 31.887027]=EF=BF=BD=EF=BF=BD Signal: 5
>> [=EF=BF=BD=EF=BF=BD 31.887042]=EF=BF=BD=EF=BF=BD Code:=EF=BF=BD=EF=BF=BD=
0
>> [=EF=BF=BD=EF=BF=BD 31.887058]=EF=BF=BD=EF=BF=BD Addr:=EF=BF=BD=EF=BF=BD=
0
>> Trace/breakpoint trap
>>
>> I guess there must be some places, like some interrupts that changed
> the MSR that I didn't know. =EF=BF=BD
>>
>> And for FP exceptions, it has two bits (two modes) in MSR. I think
> they are for such exceptions like divided by zero. Do I need to set =20=
> them
> also?
>>
>> In my previous build, I also added PPC_FPU under config 40x in arch/
> ppc/Kconfig. It compiled arch/powerpc/kernel/fpu.S in, but didn't =20
> help.
> I will try CONFIG_PPC_FPU later.
>>
>>
>> Shan
>>
>> On Apr 14, 2008, at 2:32 PM, John Bonesio wrote:
>>
>> Hi,
>>
>> The Linux kernel itself doesn't issue floating point instructions
> other than to save and restore the fpu state when necessary.
>>
>> In Linux, the way it saves and restores the fpu state is to make use
> of the trap. When the trap (fpu unavailable) occurs, it loads the fpu
> state for the current task, sets up the MSR, and returns to re-try the
> instruction.
>>
>> So, getting the trap is normal. If the FPU is not being set up
> correctly, then there may be a problem with the restoring of the =20
> state.
>>
>> When you guild the Linux kernel, you need to have CONFIG_PPC_FPU
> enabled. Otherwise the kernel does not setup the fpu exception =20
> handling.
>>
>> - John
>>
>>
>> On Monday 14 April 2008 10:35, Stephen Neuendorffer wrote:
>>
>> I'm not sure exactly what's going on here.=EF=BF=BD Generally =
speaking, =20
>> if you
>> have the FPU instantiated in the design and enable the APU in the =20
>> msr,
>> then the processor should decode FP instructions and send them
> directly
>> to the APU with no trap.=EF=BF=BD I haven't done this myself, or I =
could
>> probably give you some better help...
>>
>> One thing you should be aware of is that the there are gcc compiler
>> patches which are necessary to get the FPU working properly.=EF=BF=BD =
=20
>> However,
> I
>> don't think the failure mode that these patches workaround would =20
>> cause
> a
>> trap, so my guess is that there is still something else wrong.
>>
>> Steve
>>
>> -----Original Message-----
>> From: linuxppc-embedded-bounces+stephen=3Dneuendorffer.name@ozlabs.org
>> [mailto:linuxppc-embedded-
>> bounces+stephen=3Dneuendorffer.name@ozlabs.org] On Behalf Of Shanyuan
>> Gao
>> Sent: Monday, April 14, 2008 9:18 AM
>> To: linuxppc-embedded@ozlabs.org
>> Subject: Problems of using APU/FPU under linux
>>
>> Hi,
>>
>> Recently I was trying to make APU/FPU working under Linux on Xilinx
>> ML410. The standalone programs work perfectly. However under Linux,
>> when I try to use a floating point operation, like *fmuls*, it will
>> give me a *trap*.
>>
>> By studying the user guide from Xilinx and dumping the object files,
>> I know I need to change the corresponding bits (APU enable, FP
>> enable, maybe APU Exception enable) in Machine State Register. I
>> guess I need to enable the bits whenever before the kernel uses
>> *mtmsr*. However, it doesn't work. I got the same trap with the same
>> MSR, as I had no APU/FPU before. I also tried to add the FPU.S to ppc
>> tree, but it doesn't work either.
>>
>> The questions are
>> 1. I guess there might be some place that changed MSR after all my
>> changes. But I don't know where. And can I write a kernel module to
>> change the MSR after booting in Linux? (well, it's hard for me =20
>> though)
>>
>> 2. Does it have any exception/interrupt mechanism to direct FP
>> operation to APU/FPU? Or after enabling APU/FPU it will mask the
>> exception/interrupt and decode FP operation by itself?
>>
>>
>> Any ideas are appreciated. Thank you very much!
>>
>>
>> Shan
>
^ permalink raw reply
* MCC problem of MPC8568
From: mike zheng @ 2008-04-15 18:29 UTC (permalink / raw)
To: linuxppc-embedded
In-Reply-To: <5c9cd53b0804151129s2006af68n79975e8a8c07177b@mail.gmail.com>
Hi,
Currently, I have problem of the UBoot MCC driver. I setup the
internal loopback on MPC8568. And here is the data of each channel:
Channel # Tx Data Rx Data
0 0x01 0x9D
1 0x02 0xE1
2 0x03 0x9E
3 0x04 0xF1
4 0x05 0x83
...
Any idea on this issue? Or where can I find a working MCC Uboot driver
of MPC8568?
Thanks for your help,
Mike
^ permalink raw reply
* MCC problem of MPC8568
From: mike zheng @ 2008-04-15 18:29 UTC (permalink / raw)
To: linuxppc-dev
Hi,
Currently, I have problem of the UBoot MCC driver. I setup the
internal loopback on MPC8568. And here is the data of each channel:
Channel # Tx Data Rx Data
0 0x01 0x9D
1 0x02 0xE1
2 0x03 0x9E
3 0x04 0xF1
4 0x05 0x83
...
Any idea on this issue? Or where can I find a working MCC Uboot driver
of MPC8568?
Thanks for your help,
Mike
^ permalink raw reply
* RTC no longer being updated in 2.6.16...
From: Robert King @ 2008-04-15 17:29 UTC (permalink / raw)
To: linuxppc-embedded
Disclaimer: I'm working on a new project here, so I'm not 100% up-to-date=
=20on the system as a whole.
I've been tasked to find out why our RTC clock is not being updated after=
=20suynching with a NTP timesource. In our previous release, the RTC see=
med to be updated every 11 minutes via the timer_interrupt() ISR. This n=
o longer seems to be happening. I have determined that timer_isr() is ru=
nning, but ppc_md.set_rtc_time(xtime.tv_sec+1 + timezone_offset) doesn't =
appear to ever get called. There are five conditions that must be true f=
or this to be called:
=20 1 - ppc_md.set_rtc_time
this is true.
=20 2 - ntp_synced()
this seems to become true as soon as I sync with my NTP timesource.
=20 3 - xtime.tv_sec - last_rtc_update >=3D 659
this seems to become true within a few secondws of syncing with my timeso=
urce
=20 4 - abs((xtime.tv_nsec / 1000) - (1000000-1000000/HZ)) < 500000/HZ
this seems to be true fairly often
=20 5 - jiffies - wall_jiffies =3D=3D 1
This seems to be true fairly often.
My checks for these conditions are pretty crude. If one is true, I go in=
to an infinite loop, which eventually kicks off the watchdog timer and th=
e card reboots. Quick & dirty.
#1 #2, and #3 seem pretty obvious. #1 checks for the presence of a time =
sync function, #2 checks to see if we have synchronized with an NTP serve=
r, and #3 checks to see of that sync was at least 11 minutes ago.
#4 and #5 I don't understand so much. I THINK #4 checks to see of we're =
close to a second or half-second boundry (I'm assuming this is becxause o=
f a hardware limitation on the RTC.) #5 I have no clue about. It seems =
that wall_jiffies and jiffies are always the same.
My goal is simply to sync the RTC with the system clock, either periodica=
lly or at system shutdown (which is preferred.) however, I don't have an=
=20RTC driver. Neither do I have hwclock on this system, so my first sho=
t was getting the 11-minute update working. If this is the wrong way to =
go, I'm open to suggestions.
-- Robert King
=20 Sevis Systems, Inc.
#########################################################################=
############
This e-mail message has been scanned for Viruses and Content and cleared =
by MailMarshal
#########################################################################=
############
^ permalink raw reply
* Re: [PATCH] 86xx: mark functions static, other minor cleanups
From: Timur Tabi @ 2008-04-15 16:31 UTC (permalink / raw)
To: Paul Gortmaker; +Cc: linuxppc-dev, sfr
In-Reply-To: <4804D7C4.8060805@windriver.com>
Paul Gortmaker wrote:
> Valid point. Is there a precedent here -- like a printk indicating
> that the old ID matched, to let the user know?
Not really, but a pr_warning() would be nice.
> Actually on this one, we are OK, since the board support didn't exist
> in the default kernel until I'd just sent it last week.
No problem, then.
--
Timur Tabi
Linux kernel developer at Freescale
^ permalink raw reply
* Re: [PATCH] 86xx: mark functions static, other minor cleanups
From: Paul Gortmaker @ 2008-04-15 16:28 UTC (permalink / raw)
To: Timur Tabi; +Cc: linuxppc-dev, sfr
In-Reply-To: <4804D39C.9000309@freescale.com>
Timur Tabi wrote:
> Paul Gortmaker wrote:
>
>
>> -void
>> +static void
>> mpc86xx_hpcn_show_cpuinfo(struct seq_file *m)
>> {
>> struct device_node *root;
>> @@ -190,13 +190,13 @@ static int __init mpc86xx_hpcn_probe(void)
>> {
>> unsigned long root = of_get_flat_dt_root();
>>
>> - if (of_flat_dt_is_compatible(root, "mpc86xx"))
>> + if (of_flat_dt_is_compatible(root, "fsl,mpc86xx"))
>> return 1; /* Looks good */
>>
>
> This breaks compatibility with older device trees. You still need to look for
> "mpc86xx".
>
> A lot of people have been doing this recently, and it needs to stop. You need
> to wait at least one whole kernel version before you can remove support for an
> older device tree.
>
Valid point. Is there a precedent here -- like a printk indicating
that the old ID matched, to let the user know?
>
>> -void
>> +static void
>> sbc8641_show_cpuinfo(struct seq_file *m)
>> {
>> struct device_node *root;
>> @@ -118,13 +111,13 @@ static int __init sbc8641_probe(void)
>> {
>> unsigned long root = of_get_flat_dt_root();
>>
>> - if (of_flat_dt_is_compatible(root, "mpc86xx"))
>> + if (of_flat_dt_is_compatible(root, "wrs,sbc8641"))
>> return 1; /* Looks good */
>>
>
> Same here.
>
Actually on this one, we are OK, since the board support didn't exist
in the default kernel until I'd just sent it last week.
Thanks,
Paul.
^ permalink raw reply
* io_block_mapping & ioremap question
From: Gutson Daniel-ADG035 @ 2008-04-15 16:25 UTC (permalink / raw)
To: linuxppc-embedded
Hi,
I'm doing some work on 2.6.10, and got this problem:
- there are some io_block_mapping calls in the setup_io_mapping
callback, that use the BATs, and passing same va and pa each one.
Problem arises later when vmallocs gets a a pointer within the mapped
ranges. In other words, seems like the VMM is not aware of the BATs
mapping.
So what I did is: called first ioremap and then io_block_mapping in the
callback thus not hardcoding the va, something like:
va =3D ioremap(pa, size);
io_block_mapping(pa, va, size);
Questions:
1) Is it right?
2) Should I unmap that address sometime later? (i.e. after
mem_init_done).
Thanks!
Daniel.
=20
Daniel F. Gutson
Software Engineer
Motorola GSG Argentina
Tel =3D (54)-351-420-9218
Fax =3D (54)-351-420-9202
=20
iProtect Classification
[x] Public
[ ] Internal
[ ] Motorola Confidential Restricted
=20
"we made a big mistake in coming down from the trees in the first place"
- D. Adams
^ permalink raw reply
* [PATCH v2.6.26 2/2] gianfar: Determine TBIPA value dynamically
From: Paul Gortmaker @ 2008-04-15 16:23 UTC (permalink / raw)
To: linuxppc-dev; +Cc: Paul Gortmaker
In-Reply-To: <1208276601-16964-2-git-send-email-paul.gortmaker@windriver.com>
TBIPA needs to be set to a value (on connected MDIO buses) that doesn't
conflict with PHYs on the bus. By hardcoding it to 0x1f, we were preventing
boards with PHYs at 0x1f from working properly. Instead, scan the bus when
it comes up, and find an address that doesn't have a PHY on it. The TBI PHY
configuration code then trusts that the value in TBIPA is either safe, or
doesn't matter (ie - it's not an active bus with other PHYs).
Signed-off-by: Andy Fleming <afleming@freescale.com>
Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
---
drivers/net/gianfar.c | 27 ++++++++++++++-------------
drivers/net/gianfar.h | 1 -
drivers/net/gianfar_mii.c | 38 +++++++++++++++++++++++++++++++++-----
drivers/net/gianfar_mii.h | 3 +++
4 files changed, 50 insertions(+), 19 deletions(-)
diff --git a/drivers/net/gianfar.c b/drivers/net/gianfar.c
index 718cf77..b30809b 100644
--- a/drivers/net/gianfar.c
+++ b/drivers/net/gianfar.c
@@ -130,8 +130,6 @@ static void free_skb_resources(struct gfar_private *priv);
static void gfar_set_multi(struct net_device *dev);
static void gfar_set_hash_for_addr(struct net_device *dev, u8 *addr);
static void gfar_configure_serdes(struct net_device *dev);
-extern int gfar_local_mdio_write(struct gfar_mii __iomem *regs, int mii_id, int regnum, u16 value);
-extern int gfar_local_mdio_read(struct gfar_mii __iomem *regs, int mii_id, int regnum);
#ifdef CONFIG_GFAR_NAPI
static int gfar_poll(struct napi_struct *napi, int budget);
#endif
@@ -476,24 +474,30 @@ static int init_phy(struct net_device *dev)
return 0;
}
+/*
+ * Initialize TBI PHY interface for communicating with the
+ * SERDES lynx PHY on the chip. We communicate with this PHY
+ * through the MDIO bus on each controller, treating it as a
+ * "normal" PHY at the address found in the TBIPA register. We assume
+ * that the TBIPA register is valid. Either the MDIO bus code will set
+ * it to a value that doesn't conflict with other PHYs on the bus, or the
+ * value doesn't matter, as there are no other PHYs on the bus.
+ */
static void gfar_configure_serdes(struct net_device *dev)
{
struct gfar_private *priv = netdev_priv(dev);
struct gfar_mii __iomem *regs =
(void __iomem *)&priv->regs->gfar_mii_regs;
+ int tbipa = gfar_read(&priv->regs->tbipa);
- /* Initialise TBI i/f to communicate with serdes (lynx phy) */
+ /* Single clk mode, mii mode off(for serdes communication) */
+ gfar_local_mdio_write(regs, tbipa, MII_TBICON, TBICON_CLK_SELECT);
- /* Single clk mode, mii mode off(for aerdes communication) */
- gfar_local_mdio_write(regs, TBIPA_VALUE, MII_TBICON, TBICON_CLK_SELECT);
-
- /* Supported pause and full-duplex, no half-duplex */
- gfar_local_mdio_write(regs, TBIPA_VALUE, MII_ADVERTISE,
+ gfar_local_mdio_write(regs, tbipa, MII_ADVERTISE,
ADVERTISE_1000XFULL | ADVERTISE_1000XPAUSE |
ADVERTISE_1000XPSE_ASYM);
- /* ANEG enable, restart ANEG, full duplex mode, speed[1] set */
- gfar_local_mdio_write(regs, TBIPA_VALUE, MII_BMCR, BMCR_ANENABLE |
+ gfar_local_mdio_write(regs, tbipa, MII_BMCR, BMCR_ANENABLE |
BMCR_ANRESTART | BMCR_FULLDPLX | BMCR_SPEED1000);
}
@@ -540,9 +544,6 @@ static void init_registers(struct net_device *dev)
/* Initialize the Minimum Frame Length Register */
gfar_write(&priv->regs->minflr, MINFLR_INIT_SETTINGS);
-
- /* Assign the TBI an address which won't conflict with the PHYs */
- gfar_write(&priv->regs->tbipa, TBIPA_VALUE);
}
diff --git a/drivers/net/gianfar.h b/drivers/net/gianfar.h
index 46cd773..771aa5e 100644
--- a/drivers/net/gianfar.h
+++ b/drivers/net/gianfar.h
@@ -130,7 +130,6 @@ extern const char gfar_driver_version[];
#define DEFAULT_RXCOUNT 16
#define DEFAULT_RXTIME 4
-#define TBIPA_VALUE 0x1f
#define MIIMCFG_INIT_VALUE 0x00000007
#define MIIMCFG_RESET 0x80000000
#define MIIMIND_BUSY 0x00000001
diff --git a/drivers/net/gianfar_mii.c b/drivers/net/gianfar_mii.c
index 2432762..4f23e60 100644
--- a/drivers/net/gianfar_mii.c
+++ b/drivers/net/gianfar_mii.c
@@ -78,7 +78,6 @@ int gfar_local_mdio_write(struct gfar_mii __iomem *regs, int mii_id,
* same as system mdio bus, used for controlling the external PHYs, for eg.
*/
int gfar_local_mdio_read(struct gfar_mii __iomem *regs, int mii_id, int regnum)
-
{
u16 value;
@@ -122,7 +121,7 @@ int gfar_mdio_read(struct mii_bus *bus, int mii_id, int regnum)
}
/* Reset the MIIM registers, and wait for the bus to free */
-int gfar_mdio_reset(struct mii_bus *bus)
+static int gfar_mdio_reset(struct mii_bus *bus)
{
struct gfar_mii __iomem *regs = (void __iomem *)bus->priv;
unsigned int timeout = PHY_INIT_TIMEOUT;
@@ -152,14 +151,15 @@ int gfar_mdio_reset(struct mii_bus *bus)
}
-int gfar_mdio_probe(struct device *dev)
+static int gfar_mdio_probe(struct device *dev)
{
struct platform_device *pdev = to_platform_device(dev);
struct gianfar_mdio_data *pdata;
struct gfar_mii __iomem *regs;
+ struct gfar __iomem *enet_regs;
struct mii_bus *new_bus;
struct resource *r;
- int err = 0;
+ int i, err = 0;
if (NULL == dev)
return -EINVAL;
@@ -199,6 +199,34 @@ int gfar_mdio_probe(struct device *dev)
new_bus->dev = dev;
dev_set_drvdata(dev, new_bus);
+ /*
+ * This is mildly evil, but so is our hardware for doing this.
+ * Also, we have to cast back to struct gfar_mii because of
+ * definition weirdness done in gianfar.h.
+ */
+ enet_regs = (struct gfar __iomem *)
+ ((char *)regs - offsetof(struct gfar, gfar_mii_regs));
+
+ /* Scan the bus, looking for an empty spot for TBIPA */
+ gfar_write(&enet_regs->tbipa, 0);
+ for (i = PHY_MAX_ADDR; i > 0; i--) {
+ u32 phy_id;
+ int r;
+
+ r = get_phy_id(new_bus, i, &phy_id);
+ if (r)
+ return r;
+
+ if (phy_id == 0xffffffff)
+ break;
+ }
+
+ /* The bus is full. We don't support using 31 PHYs, sorry */
+ if (i == 0)
+ return -EBUSY;
+
+ gfar_write(&enet_regs->tbipa, i);
+
err = mdiobus_register(new_bus);
if (0 != err) {
@@ -218,7 +246,7 @@ reg_map_fail:
}
-int gfar_mdio_remove(struct device *dev)
+static int gfar_mdio_remove(struct device *dev)
{
struct mii_bus *bus = dev_get_drvdata(dev);
diff --git a/drivers/net/gianfar_mii.h b/drivers/net/gianfar_mii.h
index b373091..2af28b1 100644
--- a/drivers/net/gianfar_mii.h
+++ b/drivers/net/gianfar_mii.h
@@ -41,6 +41,9 @@ struct gfar_mii {
int gfar_mdio_read(struct mii_bus *bus, int mii_id, int regnum);
int gfar_mdio_write(struct mii_bus *bus, int mii_id, int regnum, u16 value);
+int gfar_local_mdio_write(struct gfar_mii __iomem *regs, int mii_id,
+ int regnum, u16 value);
+int gfar_local_mdio_read(struct gfar_mii __iomem *regs, int mii_id, int regnum);
int __init gfar_mdio_init(void);
void gfar_mdio_exit(void);
#endif /* GIANFAR_PHY_H */
--
1.5.4.3
^ permalink raw reply related
* [PATCH v2.6.26 1/2] phylib: factor out get_phy_id from within get_phy_device
From: Paul Gortmaker @ 2008-04-15 16:23 UTC (permalink / raw)
To: linuxppc-dev; +Cc: Paul Gortmaker
In-Reply-To: <1208276601-16964-1-git-send-email-paul.gortmaker@windriver.com>
We were already doing what amounts to a get_phy_id from within
get_phy_device, and rather than duplicate this for the TBIPA
probing, we might as well just factor it out and make it available
instead.
Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
Acked-by: Andy Fleming <afleming@freescale.com>
---
drivers/net/phy/phy_device.c | 38 +++++++++++++++++++++++++++++---------
include/linux/phy.h | 1 +
2 files changed, 30 insertions(+), 9 deletions(-)
diff --git a/drivers/net/phy/phy_device.c b/drivers/net/phy/phy_device.c
index f4c4fd8..8b1121b 100644
--- a/drivers/net/phy/phy_device.c
+++ b/drivers/net/phy/phy_device.c
@@ -86,35 +86,55 @@ struct phy_device* phy_device_create(struct mii_bus *bus, int addr, int phy_id)
EXPORT_SYMBOL(phy_device_create);
/**
- * get_phy_device - reads the specified PHY device and returns its @phy_device struct
+ * get_phy_id - reads the specified addr for its ID.
* @bus: the target MII bus
* @addr: PHY address on the MII bus
+ * @phy_id: where to store the ID retrieved.
*
* Description: Reads the ID registers of the PHY at @addr on the
- * @bus, then allocates and returns the phy_device to represent it.
+ * @bus, stores it in @phy_id and returns zero on success.
*/
-struct phy_device * get_phy_device(struct mii_bus *bus, int addr)
+int get_phy_id(struct mii_bus *bus, int addr, u32 *phy_id)
{
int phy_reg;
- u32 phy_id;
- struct phy_device *dev = NULL;
/* Grab the bits from PHYIR1, and put them
* in the upper half */
phy_reg = bus->read(bus, addr, MII_PHYSID1);
if (phy_reg < 0)
- return ERR_PTR(phy_reg);
+ return -EIO;
- phy_id = (phy_reg & 0xffff) << 16;
+ *phy_id = (phy_reg & 0xffff) << 16;
/* Grab the bits from PHYIR2, and put them in the lower half */
phy_reg = bus->read(bus, addr, MII_PHYSID2);
if (phy_reg < 0)
- return ERR_PTR(phy_reg);
+ return -EIO;
+
+ *phy_id |= (phy_reg & 0xffff);
+
+ return 0;
+}
+
+/**
+ * get_phy_device - reads the specified PHY device and returns its @phy_device struct
+ * @bus: the target MII bus
+ * @addr: PHY address on the MII bus
+ *
+ * Description: Reads the ID registers of the PHY at @addr on the
+ * @bus, then allocates and returns the phy_device to represent it.
+ */
+struct phy_device * get_phy_device(struct mii_bus *bus, int addr)
+{
+ struct phy_device *dev = NULL;
+ u32 phy_id;
+ int r;
- phy_id |= (phy_reg & 0xffff);
+ r = get_phy_id(bus, addr, &phy_id);
+ if (r)
+ return ERR_PTR(r);
/* If the phy_id is all Fs, there is no device there */
if (0xffffffff == phy_id)
diff --git a/include/linux/phy.h b/include/linux/phy.h
index 5e43ae7..e794c4d 100644
--- a/include/linux/phy.h
+++ b/include/linux/phy.h
@@ -361,6 +361,7 @@ struct phy_driver {
int phy_read(struct phy_device *phydev, u16 regnum);
int phy_write(struct phy_device *phydev, u16 regnum, u16 val);
+int get_phy_id(struct mii_bus *bus, int addr, u32 *phy_id);
struct phy_device* get_phy_device(struct mii_bus *bus, int addr);
int phy_clear_interrupt(struct phy_device *phydev);
int phy_config_interrupt(struct phy_device *phydev, u32 interrupts);
--
1.5.4.3
^ permalink raw reply related
* [PATCH v2.6.26 0/2] Dynamic TBIPA for gianfar
From: Paul Gortmaker @ 2008-04-15 16:23 UTC (permalink / raw)
To: linuxppc-dev
This is the resend of the two patches as per Andy's request for v2.6.26
that allow boards with a PHY at the end of the bus to function, by having
the TBIPA set dynamically. The 1st patch factors out some of the PHY
probe code so it can be recycled by the TBIPA probe, and the second patch
implements the dynamic probe itself.
Paul.
^ permalink raw reply
* Re: BestComm/FEC Linux system crash
From: Sylvain Munaut @ 2008-04-15 16:20 UTC (permalink / raw)
To: Cees van Teylingen; +Cc: linuxppc-dev, dve, Rob Broersen, Nathan Huizinga
In-Reply-To: <4804CE5F.8050907@chess.nl>
Hi
> I hereby take the liberty to contact you regarding an issue we
> experience with the
> MPC5200 BestComm/FEC in our system. I found that you are the writer of
> the drivers
> for these, so apparently with a lot of experience with these devices.
> I hope you can find
> the time and inspiration to look into our case.
Well, feel free to CC me to bring my attention to it, but such question
should still go to the list.
It's been a while since I worked on the 5200 and some other people might
have more recent expertise than I do.
Plus, it's actually Domen Puncer who reworked a lot of the network
driver code quite recently ...
> We are running a Lunix based system based on a MPC5200
Need more precision.
- 5200 or 5200B ?
- What kernel version (version ?, where did you get it ?, external patch
applied ?)
> This process dies after several minutes due to a FEC RxFifo overflow
> interrupt. This interrupt
> now causes the FEC to be re-initialized, but for some reason the
> receiver channel still does
> not work properly, causing the RxFifo overflow to occur nearly
> immediately again, causing
> a subsequent FEC re-init again, again resulting in failing receiver
> channel, causing another
> RxFifo overflow interrupt etc etc etc......
Huh ... you transmit lots of data ... and it's the RX fifo that overlow ...
> In the FEC driver we stumbled upon the following code:
>
> static irqreturn_t fec_rx_interrupt(int irq, void *dev_id)
> {
> struct net_device *dev = dev_id;
> struct fec_priv *priv = (struct fec_priv *)dev->priv;
>
> for (;;) {
> struct sk_buff *skb;
> struct sk_buff *rskb;
> struct bcom_fec_bd *bd;
> u32 status;
>
> if (!bcom_buffer_done(priv->rx_dmatsk))
> break;
>
> [...snipped...]
> Now what we see is that the statement in the FEC interrupt handler
>
> if (!bcom_buffer_done(priv->rx_dmatsk))
> break;
>
> is executed frequently.
>
> Can you explain why this statement is there?
Well ... that test is inside an infinite loop ( for(;;) ... ), so yes,
hopefully it will be 'break' at some point ...
What we do here is that we try to process as much receive buffer as
possible ... So we loop indefinitly until no more buffers are ready ...
> During debug, after receiving the first RxFifo overflow interrupt, we
> suspended all further FEC processing and dumped
> various system status, of which the BestComm receiver descriptors.
> Here we found that always all but one were initialized
> to 0x4000005f2, but the different one to 0x08000040.
Theses are Receive Buffer descriptor. So it the BCOM_BD_READY bit is
_set_, that means, that they're _not_ done (i.e. they are ready for
bestcomm to fill).
If you check the definition of bcom_buffer_done, you'll see that we
check if the bit is _cleared_
So the situation you are describing is essentially :
- One of the buffer is filled with some received packet (length = 0x40)
- All the other buffers are ready for bestcomm and they can contain at
maximum 1522 bytes (0x5f2)
There is nothing 'wrong' about this situation.
> This all directs us somewhat to the believe that the following is
> occurring:
>
> For some reason the BestComm gets confused during FEC reception
> causing a descriptor not to be handled properly, which
> causes its status never to be set to 'ready' (BCOM_BD_READY
> 0x40000000ul). Eventually, because of all receiving
> traffic to be ceased, the RxFifo will overflow causing the described
> interrupt and following re-initialization actions. But the
> BestComm FEC receiver channel fails to re-initialize (or even does not
> get re-initialized at all) and/or the BestComm FEC
> receiver descriptor table does not get re-initialized, causing the
> 0x08000040 status to remain in there. So either BestComm
> fails to work at all for the FEC Receiver channel and/or BestComm
> eventually stumbles upon the 'incorrect' descriptor causing
> the FEC receiver to stall again causing an RxFifo overflow again etc
> etc etc.
Well, given you misunderstood the meaning of BCOM_BD_READY, this theory
doesn't make much sense sorry ...
The re-initialize process should work however ... there is a bug there.
> This all seems plausible for what we experience so far, but does get
> confirmed by any data we can find in datasheets and
> hard-/software descriptions. The FEC receiver has the highest priority
> within BestComm and thus should always get serviced.
> The thing we can not find however is what system impact the PCI DMA by
> the PLX9056 is causing on the BestComm
> performance.
The only interference I see would be contention on the XLB bus ... Maybe
you can try to play with the xlb priority and give a higher one to
bestcomm or a lower one to the PCI.
Look in the platform setup there is some code setting xlb priorities.
And refer to the 'XLB arbiter' section of the manual for the registers
to tweak.
What kind of bandwidth are you using for RX/TX on ethernet and PCI ?
Does your PCI card do _very_ long bursts without releasing the bus
(locking the xlb for a long time), or _very_ short burst causing big
overhead ?
You can also try playing the FEC RX fifo alarm levels.
> We can imagine that it disrupts 'normal' BestComm performance i.e.
> Ethernet traffic, but then again the overflow
> interrupt should take care of a proper re-initialization of all hard-
> and software, allowing the TCP/IP stack to subsequently
> handle correct transfer of missing packets.
The overflow should still not happen ... that's a pretty serious error
imho.
Sylvain
^ permalink raw reply
* Re: [PATCH] 86xx: mark functions static, other minor cleanups
From: Timur Tabi @ 2008-04-15 16:11 UTC (permalink / raw)
To: Paul Gortmaker; +Cc: linuxppc-dev, sfr
In-Reply-To: <1207933186-20555-1-git-send-email-paul.gortmaker@windriver.com>
Paul Gortmaker wrote:
> -void
> +static void
> mpc86xx_hpcn_show_cpuinfo(struct seq_file *m)
> {
> struct device_node *root;
> @@ -190,13 +190,13 @@ static int __init mpc86xx_hpcn_probe(void)
> {
> unsigned long root = of_get_flat_dt_root();
>
> - if (of_flat_dt_is_compatible(root, "mpc86xx"))
> + if (of_flat_dt_is_compatible(root, "fsl,mpc86xx"))
> return 1; /* Looks good */
This breaks compatibility with older device trees. You still need to look for
"mpc86xx".
A lot of people have been doing this recently, and it needs to stop. You need
to wait at least one whole kernel version before you can remove support for an
older device tree.
> -void
> +static void
> sbc8641_show_cpuinfo(struct seq_file *m)
> {
> struct device_node *root;
> @@ -118,13 +111,13 @@ static int __init sbc8641_probe(void)
> {
> unsigned long root = of_get_flat_dt_root();
>
> - if (of_flat_dt_is_compatible(root, "mpc86xx"))
> + if (of_flat_dt_is_compatible(root, "wrs,sbc8641"))
> return 1; /* Looks good */
Same here.
--
Timur Tabi
Linux kernel developer at Freescale
^ permalink raw reply
* Re: [RFC] Using two baud rate generators with the cpm_uart driver
From: Laurent Pinchart @ 2008-04-15 16:03 UTC (permalink / raw)
To: Scott Wood; +Cc: linuxppc-dev
In-Reply-To: <4804D0EB.5020508@freescale.com>
[-- Attachment #1: Type: text/plain, Size: 1016 bytes --]
On Tuesday 15 April 2008 17:59, Scott Wood wrote:
> Laurent Pinchart wrote:
> >> The clean solution would be to have an abstracted clock API, similar to
> >> phylib, where the caller doesn't know details about BRGs and such.
> >> Maybe the linux/clk.h API would be suitable; I haven't looked at it in
> >> detail.
> >
> > The clock API would have to be quite advanced to express things like "the SCC4
> > clock is a combination of BRG2 and BRG5" (and I don't even consider
> > adding "with BRG2 set to 16x the baud rate and BRG5 to the baud rate").
>
> What I was picturing was platform code providing a clock object that the
> cpm_uart driver could be pointed at (possibly by modifying the device
> tree in platform init); the knowledge of the multiple BRG weirdness
> would be contained in platform code.
I'll think about it.
Thanks.
--
Laurent Pinchart
CSE Semaphore Belgium
Chaussee de Bruxelles, 732A
B-1410 Waterloo
Belgium
T +32 (2) 387 42 59
F +32 (2) 387 42 75
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* [PATCH] mpc8313erdb: Update defconfig, enabling FCM NAND and OF partitions
From: Scott Wood @ 2008-04-15 16:03 UTC (permalink / raw)
To: galak; +Cc: linuxppc-dev
Signed-off-by: Scott Wood <scottwood@freescale.com>
---
arch/powerpc/configs/mpc8313_rdb_defconfig | 8 +++++---
1 files changed, 5 insertions(+), 3 deletions(-)
diff --git a/arch/powerpc/configs/mpc8313_rdb_defconfig b/arch/powerpc/configs/mpc8313_rdb_defconfig
index 7a862a6..7d18440 100644
--- a/arch/powerpc/configs/mpc8313_rdb_defconfig
+++ b/arch/powerpc/configs/mpc8313_rdb_defconfig
@@ -1,7 +1,7 @@
#
# Automatically generated make config: don't edit
# Linux kernel version: 2.6.25-rc6
-# Mon Mar 24 08:48:14 2008
+# Fri Apr 11 11:10:09 2008
#
# CONFIG_PPC64 is not set
@@ -196,6 +196,7 @@ CONFIG_PREEMPT_NONE=y
# CONFIG_PREEMPT is not set
CONFIG_BINFMT_ELF=y
# CONFIG_BINFMT_MISC is not set
+CONFIG_FORCE_MAX_ZONEORDER=11
# CONFIG_IOMMU_HELPER is not set
CONFIG_ARCH_ENABLE_MEMORY_HOTPLUG=y
CONFIG_ARCH_HAS_WALK_MEMORY=y
@@ -360,7 +361,7 @@ CONFIG_MTD=y
CONFIG_MTD_PARTITIONS=y
# CONFIG_MTD_REDBOOT_PARTS is not set
# CONFIG_MTD_CMDLINE_PARTS is not set
-# CONFIG_MTD_OF_PARTS is not set
+CONFIG_MTD_OF_PARTS=y
#
# User Modules And Translation Layers
@@ -436,7 +437,7 @@ CONFIG_MTD_NAND_IDS=y
# CONFIG_MTD_NAND_NANDSIM is not set
# CONFIG_MTD_NAND_PLATFORM is not set
# CONFIG_MTD_ALAUDA is not set
-# CONFIG_MTD_NAND_FSL_ELBC is not set
+CONFIG_MTD_NAND_FSL_ELBC=y
# CONFIG_MTD_ONENAND is not set
#
@@ -1293,6 +1294,7 @@ CONFIG_PLIST=y
CONFIG_HAS_IOMEM=y
CONFIG_HAS_IOPORT=y
CONFIG_HAS_DMA=y
+CONFIG_HAVE_LMB=y
#
# Kernel hacking
--
1.5.4.4
^ permalink raw reply related
* [RESEND PATCH] cuboot-pq2: PCI fixes
From: Scott Wood @ 2008-04-15 16:02 UTC (permalink / raw)
To: galak; +Cc: linuxppc-dev
1. Detect (and bail out on) more conditions that violate the
assumptions of the setup code -- we assume in such cases that the device
tree is correct and reflects what the firmware did.
2. The inbound memory mask calculation was wrong.
Signed-off-by: Scott Wood <scottwood@freescale.com>
---
arch/powerpc/boot/cuboot-pq2.c | 27 +++++++++++++++++++--------
1 files changed, 19 insertions(+), 8 deletions(-)
diff --git a/arch/powerpc/boot/cuboot-pq2.c b/arch/powerpc/boot/cuboot-pq2.c
index f56ac6c..9c7d134 100644
--- a/arch/powerpc/boot/cuboot-pq2.c
+++ b/arch/powerpc/boot/cuboot-pq2.c
@@ -128,7 +128,7 @@ static void fixup_pci(void)
u8 *soc_regs;
int i, len;
void *node, *parent_node;
- u32 naddr, nsize, mem_log2;
+ u32 naddr, nsize, mem_pow2, mem_mask;
node = finddevice("/pci");
if (!node || !dt_is_compatible(node, "fsl,pq2-pci"))
@@ -141,7 +141,7 @@ static void fixup_pci(void)
soc_regs = (u8 *)fsl_get_immr();
if (!soc_regs)
- goto err;
+ goto unhandled;
dt_get_reg_format(node, &naddr, &nsize);
if (naddr != 3 || nsize != 2)
@@ -153,7 +153,7 @@ static void fixup_pci(void)
dt_get_reg_format(parent_node, &naddr, &nsize);
if (naddr != 1 || nsize != 1)
- goto err;
+ goto unhandled;
len = getprop(node, "ranges", pci_ranges_buf,
sizeof(pci_ranges_buf));
@@ -170,14 +170,20 @@ static void fixup_pci(void)
}
if (!mem || !mmio || !io)
- goto err;
+ goto unhandled;
+ if (mem->size[1] != mmio->size[1])
+ goto unhandled;
+ if (mem->size[1] & (mem->size[1] - 1))
+ goto unhandled;
+ if (io->size[1] & (io->size[1] - 1))
+ goto unhandled;
if (mem->phys_addr + mem->size[1] == mmio->phys_addr)
mem_base = mem;
else if (mmio->phys_addr + mmio->size[1] == mem->phys_addr)
mem_base = mmio;
else
- goto err;
+ goto unhandled;
out_be32(&pci_regs[1][0], mem_base->phys_addr | 1);
out_be32(&pci_regs[2][0], ~(mem->size[1] + mmio->size[1] - 1));
@@ -201,8 +207,9 @@ static void fixup_pci(void)
out_le32(&pci_regs[0][58], 0);
out_le32(&pci_regs[0][60], 0);
- mem_log2 = 1 << (__ilog2_u32(bd.bi_memsize - 1) + 1);
- out_le32(&pci_regs[0][62], 0xa0000000 | ~((1 << (mem_log2 - 12)) - 1));
+ mem_pow2 = 1 << (__ilog2_u32(bd.bi_memsize - 1) + 1);
+ mem_mask = ~(mem_pow2 - 1) >> 12;
+ out_le32(&pci_regs[0][62], 0xa0000000 | mem_mask);
/* If PCI is disabled, drive RST high to enable. */
if (!(in_le32(&pci_regs[0][32]) & 1)) {
@@ -228,7 +235,11 @@ static void fixup_pci(void)
return;
err:
- printf("Bad PCI node\r\n");
+ printf("Bad PCI node -- using existing firmware setup.\r\n");
+ return;
+
+unhandled:
+ printf("Unsupported PCI node -- using existing firmware setup.\r\n");
}
static void pq2_platform_fixups(void)
--
1.5.3.8
^ permalink raw reply related
* Re: [RFC] Using two baud rate generators with the cpm_uart driver
From: Scott Wood @ 2008-04-15 15:59 UTC (permalink / raw)
To: Laurent Pinchart; +Cc: linuxppc-dev
In-Reply-To: <200804151754.21664.laurentp@cse-semaphore.com>
Laurent Pinchart wrote:
>> The clean solution would be to have an abstracted clock API, similar to
>> phylib, where the caller doesn't know details about BRGs and such.
>> Maybe the linux/clk.h API would be suitable; I haven't looked at it in
>> detail.
>
> The clock API would have to be quite advanced to express things like "the SCC4
> clock is a combination of BRG2 and BRG5" (and I don't even consider
> adding "with BRG2 set to 16x the baud rate and BRG5 to the baud rate").
What I was picturing was platform code providing a clock object that the
cpm_uart driver could be pointed at (possibly by modifying the device
tree in platform init); the knowledge of the multiple BRG weirdness
would be contained in platform code.
-Scott
^ permalink raw reply
* Re: [RFC] Using two baud rate generators with the cpm_uart driver
From: Laurent Pinchart @ 2008-04-15 15:54 UTC (permalink / raw)
To: Scott Wood; +Cc: linuxppc-dev
In-Reply-To: <4804CB12.1000308@freescale.com>
[-- Attachment #1: Type: text/plain, Size: 1869 bytes --]
Hi Scott,
On Tuesday 15 April 2008 17:34, Scott Wood wrote:
> Laurent Pinchart wrote:
> > thanks to a bad hardware design decision, I'm faced with a software issue
> > with the cpm_uart driver.
> >
> > My hardware uses either SCC4 or SMC2 (production-time option) as an RS485
> > port with an external transceiver. The transceiver's data direction is
> > controlled by external logic that monitors the SCC4/SMC2 TxD signal.
> >
> > The external logic needs an input clock at the baud rate frequency on the
> > MPC8248 BRG5 output pin (although I could modify it to accept an input
> > clock at 16x the baud rate frequency). This means the cpm_uart driver has
> > to setup two baud rate generators instead of one.
> >
> > The ppc architecture was easy to hack as it used a fs_uart_platform_info
> > structure in which I added a set_brg function pointer provided by platform
> > code. This isn't possible with the powerpc architecture anymore.
> >
> > Is there a clean way to fix this issue ? Kicking the hardware designer
> > won't help :-)
>
> Maybe not, but it'd be satisfying. :-)
Don't tempt me :-)
> The clean solution would be to have an abstracted clock API, similar to
> phylib, where the caller doesn't know details about BRGs and such.
> Maybe the linux/clk.h API would be suitable; I haven't looked at it in
> detail.
The clock API would have to be quite advanced to express things like "the SCC4
clock is a combination of BRG2 and BRG5" (and I don't even consider
adding "with BRG2 set to 16x the baud rate and BRG5 to the baud rate").
I'm not even sure a generic API should be developed to solve my problem. I'm
more looking for a not too dirty hack.
--
Laurent Pinchart
CSE Semaphore Belgium
Chaussee de Bruxelles, 732A
B-1410 Waterloo
Belgium
T +32 (2) 387 42 59
F +32 (2) 387 42 75
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: Signal backtrace function
From: Detlev Zundel @ 2008-04-15 15:50 UTC (permalink / raw)
To: joakim.tjernlund; +Cc: linuxppc-dev
In-Reply-To: <1208190010.5911.15.camel@gentoo-jocke.transmode.se>
Hi Jocke,
> On Mon, 2008-04-14 at 18:09 +0200, Detlev Zundel wrote:
>> Hi Jocke,
>>
>> > I made my own backtrace function for printing
>> > a trace from within a signal handler. Maybe it
>> > can be useful for the kernel too? General
>> > comments welcome.
>>
>> Probably a dumb question, but doesn't backtrace(3) from glibc work
>> architecture independent already? Why do you need to reimplement it?
>
> Nope, it doesn't give you a good backtrace from within a signal handler.
> On x86 you can use the normal backtrace function with a minor
> workaround, but as ppc doesn't save a FP in leaf functions, that
> workaround does not work well. You can read more about it
> at http://www.linuxjournal.com/article/6391
Thanks for clearing that up. I wasn't aware of that limitation.
Cheers
Detlev
--
In short: much of our country's [USA] counterterrorism security spending is
not designed to protect us from the terrorists, but instead to protect our
public officials from criticism when another attack occurs.
-- Bruce Schneier
--
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-40 Fax: (+49)-8142-66989-80 Email: dzu@denx.de
^ permalink raw reply
* fec_mpc5200: reset FEC on error
From: Robert Schwebel @ 2008-04-15 15:44 UTC (permalink / raw)
To: netdev; +Cc: linuxppc-dev, Domen Puncer
In-Reply-To: <20080415152638.GW13814@pengutronix.de>
From: Sascha Hauer <s.hauer@pengutronix.de>
The error handling for the mpc5200 fec interrupt is broken. The intended
behaviour is like this:
* If one of FEC_IEVENT_RFIFO_ERROR and FEC_IEVENT_XFIFO_ERROR happens,
the datasheet says (MPC5200B User's Guide R1.2, p. 14-13): "When this
occurs, software must ensure both the FIFO Controller and BestComm are
soft-reset".
* On any other error (non-TFINT) interrupt, just issue a debug message.
v2 changed to -p1 and posted on linuxppc list (2008-04-15).
v1 posted on linuxppc list (2008-04-15).
Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
---
drivers/net/fec_mpc52xx.c | 23 +++++++++++++----------
1 file changed, 13 insertions(+), 10 deletions(-)
Index: drivers/net/fec_mpc52xx.c
===================================================================
--- a/drivers/net/fec_mpc52xx.c.orig
+++ b/drivers/net/fec_mpc52xx.c
@@ -491,20 +491,23 @@
out_be32(&fec->ievent, ievent); /* clear pending events */
- if (ievent & ~(FEC_IEVENT_RFIFO_ERROR | FEC_IEVENT_XFIFO_ERROR)) {
- if (ievent & ~FEC_IEVENT_TFINT)
- dev_dbg(&dev->dev, "ievent: %08x\n", ievent);
+ /* on fifo error, soft-reset fec */
+ if (ievent & (FEC_IEVENT_RFIFO_ERROR | FEC_IEVENT_XFIFO_ERROR)) {
+
+ if (net_ratelimit() && (ievent & FEC_IEVENT_RFIFO_ERROR))
+ dev_warn(&dev->dev, "FEC_IEVENT_RFIFO_ERROR\n");
+ if (net_ratelimit() && (ievent & FEC_IEVENT_XFIFO_ERROR))
+ dev_warn(&dev->dev, "FEC_IEVENT_XFIFO_ERROR\n");
+
+ mpc52xx_fec_reset(dev);
+
+ netif_wake_queue(dev);
return IRQ_HANDLED;
}
- if (net_ratelimit() && (ievent & FEC_IEVENT_RFIFO_ERROR))
- dev_warn(&dev->dev, "FEC_IEVENT_RFIFO_ERROR\n");
- if (net_ratelimit() && (ievent & FEC_IEVENT_XFIFO_ERROR))
- dev_warn(&dev->dev, "FEC_IEVENT_XFIFO_ERROR\n");
-
- mpc52xx_fec_reset(dev);
+ if (ievent & ~FEC_IEVENT_TFINT)
+ dev_dbg(&dev->dev, "ievent: %08x\n", ievent);
- netif_wake_queue(dev);
return IRQ_HANDLED;
}
^ permalink raw reply
* Re: [RFC] Using two baud rate generators with the cpm_uart driver
From: Scott Wood @ 2008-04-15 15:34 UTC (permalink / raw)
To: Laurent Pinchart; +Cc: linuxppc-dev
In-Reply-To: <200804151532.27057.laurentp@cse-semaphore.com>
Laurent Pinchart wrote:
> thanks to a bad hardware design decision, I'm faced with a software issue with
> the cpm_uart driver.
>
> My hardware uses either SCC4 or SMC2 (production-time option) as an RS485 port
> with an external transceiver. The transceiver's data direction is controlled
> by external logic that monitors the SCC4/SMC2 TxD signal.
>
> The external logic needs an input clock at the baud rate frequency on the
> MPC8248 BRG5 output pin (although I could modify it to accept an input clock
> at 16x the baud rate frequency). This means the cpm_uart driver has to setup
> two baud rate generators instead of one.
>
> The ppc architecture was easy to hack as it used a fs_uart_platform_info
> structure in which I added a set_brg function pointer provided by platform
> code. This isn't possible with the powerpc architecture anymore.
>
> Is there a clean way to fix this issue ? Kicking the hardware designer won't
> help :-)
Maybe not, but it'd be satisfying. :-)
The clean solution would be to have an abstracted clock API, similar to
phylib, where the caller doesn't know details about BRGs and such.
Maybe the linux/clk.h API would be suitable; I haven't looked at it in
detail.
-Scott
^ permalink raw reply
* Re: fec_mpc5200: reset FEC on error
From: Robert Schwebel @ 2008-04-15 15:32 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-dev, Domen Puncer
In-Reply-To: <F7AFD26F-39FE-4C1F-8918-F799F65F9559@kernel.crashing.org>
On Tue, Apr 15, 2008 at 10:29:26AM -0500, Kumar Gala wrote:
> You really need to also copy netdev and patches to drivers/net.
Hm? Sorry, don't understand what you mean.
Robert
--
Dipl.-Ing. Robert Schwebel | http://www.pengutronix.de
Pengutronix - Linux Solutions for Science and Industry
Handelsregister: Amtsgericht Hildesheim, HRA 2686
Hannoversche Str. 2, 31134 Hildesheim, Germany
Phone: +49-5121-206917-0 | Fax: +49-5121-206917-9
^ permalink raw reply
* Please pull 'for-2.6.26' branch of 4xx tree
From: Josh Boyer @ 2008-04-15 15:27 UTC (permalink / raw)
To: paulus; +Cc: linuxppc-dev
Hi Paul
Please pull from:
master.kernel.org:/pub/scm/linux/kernel/git/jwboyer/powerpc-4xx.git for-2.6.26
to pick up some additional patches for 4xx. This contains the
defconfig reorg, some EMAC patches from Valentine that have been
outstanding for a while, and a new idle loop patch.
josh
Jerone Young (1):
[POWERPC] 4xx: Add idle wait support for 44x platforms
Josh Boyer (2):
[POWERPC] 4xx: Reorganize 4xx defconfigs
[POWERPC] 4xx: Add ppc40x_defconfig
Valentine Barshak (2):
[POWERPC] ibm_newemac: PowerPC 440GX EMAC PHY clock workaround
[POWERPC] ibm_newemac: PowerPC 440EP/440GR EMAC PHY clock workaround
arch/powerpc/configs/{ => 40x}/ep405_defconfig | 0
arch/powerpc/configs/{ => 40x}/kilauea_defconfig | 0
arch/powerpc/configs/{ => 40x}/makalu_defconfig | 0
arch/powerpc/configs/{ => 40x}/walnut_defconfig | 0
arch/powerpc/configs/{ => 44x}/bamboo_defconfig | 0
.../configs/{ => 44x}/canyonlands_defconfig | 0
arch/powerpc/configs/{ => 44x}/ebony_defconfig | 0
arch/powerpc/configs/{ => 44x}/katmai_defconfig | 0
arch/powerpc/configs/{ => 44x}/rainier_defconfig | 0
arch/powerpc/configs/{ => 44x}/sequoia_defconfig | 0
arch/powerpc/configs/{ => 44x}/taishan_defconfig | 0
arch/powerpc/configs/{ => 44x}/warp_defconfig | 0
.../configs/{walnut_defconfig => ppc40x_defconfig} | 31 ++++++---
arch/powerpc/platforms/44x/Makefile | 2 +-
arch/powerpc/platforms/44x/idle.c | 67 ++++++++++++++++++++
drivers/net/ibm_newemac/core.c | 48 +++++++++++++-
drivers/net/ibm_newemac/core.h | 14 +++-
17 files changed, 145 insertions(+), 17 deletions(-)
rename arch/powerpc/configs/{ => 40x}/ep405_defconfig (100%)
rename arch/powerpc/configs/{ => 40x}/kilauea_defconfig (100%)
rename arch/powerpc/configs/{ => 40x}/makalu_defconfig (100%)
copy arch/powerpc/configs/{ => 40x}/walnut_defconfig (100%)
rename arch/powerpc/configs/{ => 44x}/bamboo_defconfig (100%)
rename arch/powerpc/configs/{ => 44x}/canyonlands_defconfig (100%)
rename arch/powerpc/configs/{ => 44x}/ebony_defconfig (100%)
rename arch/powerpc/configs/{ => 44x}/katmai_defconfig (100%)
rename arch/powerpc/configs/{ => 44x}/rainier_defconfig (100%)
rename arch/powerpc/configs/{ => 44x}/sequoia_defconfig (100%)
rename arch/powerpc/configs/{ => 44x}/taishan_defconfig (100%)
rename arch/powerpc/configs/{ => 44x}/warp_defconfig (100%)
rename arch/powerpc/configs/{walnut_defconfig => ppc40x_defconfig} (97%)
create mode 100644 arch/powerpc/platforms/44x/idle.c
^ permalink raw reply
* mpc5200: add interrupt type function
From: Robert Schwebel @ 2008-04-15 15:29 UTC (permalink / raw)
To: linuxppc-dev
From: Sascha Hauer <s.hauer@pengutronix.de>
Add a set_type function for external (GPIO) interrupts.
Signed-off-by: Juergen Beisert <j.beisert@pengutronix.de>
Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
---
arch/powerpc/platforms/52xx/mpc52xx_pic.c | 38 ++++++++++++++++++++++++++++++
1 file changed, 38 insertions(+)
Index: arch/powerpc/platforms/52xx/mpc52xx_pic.c
===================================================================
--- a/arch/powerpc/platforms/52xx/mpc52xx_pic.c.orig 2008-04-15 11:25:29.000000000 +0200
+++ b/arch/powerpc/platforms/52xx/mpc52xx_pic.c 2008-04-15 11:25:39.000000000 +0200
@@ -18,6 +18,7 @@
#undef DEBUG
+#include <linux/interrupt.h>
#include <linux/irq.h>
#include <linux/of.h>
#include <asm/io.h>
@@ -109,11 +110,48 @@
io_be_setbit(&intr->ctrl, 27-l2irq);
}
+static int mpc52xx_extirq_set_type(unsigned int virq, unsigned int flow_type)
+{
+ u32 ctrl_reg, type;
+ int irq;
+ int l2irq;
+
+ irq = irq_map[virq].hwirq;
+ l2irq = (irq & MPC52xx_IRQ_L2_MASK) >> MPC52xx_IRQ_L2_OFFSET;
+
+ pr_debug("%s: irq=%x. l2=%d flow_type=%d\n", __func__, irq, l2irq, flow_type);
+
+ switch (flow_type) {
+ case IRQF_TRIGGER_HIGH:
+ type = 0;
+ break;
+ case IRQF_TRIGGER_RISING:
+ type = 1;
+ break;
+ case IRQF_TRIGGER_FALLING:
+ type = 2;
+ break;
+ case IRQF_TRIGGER_LOW:
+ type = 3;
+ break;
+ default:
+ type = 0;
+ }
+
+ ctrl_reg = in_be32(&intr->ctrl);
+ ctrl_reg &= ~(0x3 << (22 - (l2irq * 2)));
+ ctrl_reg |= (type << (22 - (l2irq * 2)));
+ out_be32(&intr->ctrl, ctrl_reg);
+
+ return 0;
+}
+
static struct irq_chip mpc52xx_extirq_irqchip = {
.typename = " MPC52xx IRQ[0-3] ",
.mask = mpc52xx_extirq_mask,
.unmask = mpc52xx_extirq_unmask,
.ack = mpc52xx_extirq_ack,
+ .set_type = mpc52xx_extirq_set_type,
};
/*
^ 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