* RE: [PATCH V2 RESEND] fsl-sata: I/O load balancing
From: Liu Qiang-B32616 @ 2012-02-17 3:30 UTC (permalink / raw)
To: Benjamin Herrenschmidt
Cc: linux-ide@vger.kernel.org, jgarzik@pobox.com,
linuxppc-dev@lists.ozlabs.org, linux-kernel@vger.kernel.org
In-Reply-To: <1329448660.2892.42.camel@pasglop>
PiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBCZW5qYW1pbiBIZXJyZW5zY2ht
aWR0IFttYWlsdG86YmVuaEBrZXJuZWwuY3Jhc2hpbmcub3JnXQ0KPiBTZW50OiBGcmlkYXksIEZl
YnJ1YXJ5IDE3LCAyMDEyIDExOjE4IEFNDQo+IFRvOiBMaXUgUWlhbmctQjMyNjE2DQo+IENjOiBq
Z2FyemlrQHBvYm94LmNvbTsgbGludXgtaWRlQHZnZXIua2VybmVsLm9yZzsgbGludXhwcGMtDQo+
IGRldkBsaXN0cy5vemxhYnMub3JnOyBsaW51eC1rZXJuZWxAdmdlci5rZXJuZWwub3JnDQo+IFN1
YmplY3Q6IFJFOiBbUEFUQ0ggVjIgUkVTRU5EXSBmc2wtc2F0YTogSS9PIGxvYWQgYmFsYW5jaW5n
DQo+IA0KPiBPbiBGcmksIDIwMTItMDItMTcgYXQgMDE6NTQgKzAwMDAsIExpdSBRaWFuZy1CMzI2
MTYgd3JvdGU6DQo+ID4gVGhlIGRlZmF1bHQgd2lsbCBiZSBzZXQgaW4gYSBjb21tb24gaW50ZXJm
YWNlDQo+ID4gZnNsX3NhdGFfc2V0X2lycV9jb2FsZXNjaW5nIHdoZW4gaW5pdGlhbGl6ZSB0aGUg
Y29udHJvbGxlci4gVGhpcw0KPiA+IGludGVyZmFjZSB3aWxsIGNoZWNrIHRoZSByYW5nZSBvZiBp
bnRyIGNvdW50IGFuZCB0aWNrcyBhbmQgbWFrZSBzdXJlDQo+IHRoZSB2YWx1ZXMgYXJlIHJlYXNv
bmFibHkuDQo+IA0KPiBBbGxyaWdodCwgYnV0IHRoZSBjdXJyZW50IGRlZmF1bHRzIGFyZSBiYXNp
Y2FsbHkgbm8gY29hbGVzY2luZyByaWdodCA/DQo+IA0KPiA+IEl0J3MgaGFyZCB0byBmaW5kIGEg
YWdncmVzc2l2ZSB2YWx1ZSB0byBhZGFwdCBhbGwgc2NlbmFyaW9zLCBzbyBJIHVzZQ0KPiA+IGVj
aG8gdG8gYWRqdXN0IHRoZSB2YWx1ZS4gSSByZW1lbWJlciBQNTAyMCBoYXZlIHNvbWUgcGVyZm9y
bWFuY2UgaXNzdWUsDQo+IEkgd2lsbCBjaGVjayBpdC4NCj4gPiBCVFcsIHdoaWNoIGZpbGVzeXN0
ZW0gZG8geW91IHVzZT8gRXh0MiBpcyBsb3dlciB0aGFuIGV4dDQgYmVjYXVzZQ0KPiA+IG1ldGFk
YXRhIGlzIGNvbnRpbnVvdXNseSB3cm90ZSB0byBkaXNrLiBZb3UgY2FuIHRyeSBleHQ0IG9yIHhm
cy4NCj4gDQo+IGV4dDMgYXQgdGhlIG1vbWVudCwgSSBwbGFuIHRvIHN3aXRjaCB0byBleHQ0IHdo
ZW4gSSBmaW5pc2ggdGhhdCBmc2NrIHBhc3MNCj4gd2hpY2ggaXMgdGFraW5nIGhvdXJzLi4uIEkg
YW0gbm90IGF3YXJlIG9mIHRoZSA1MDIwIHBlcmZvcm1hbmNlIGlzc3VlcywNCj4gaXMgdGhpcyBz
b21ldGhpbmcgZG9jdW1lbnRlZCBhbmQvb3IgZml4YWJsZSA/DQo+IA0KDQpNeSBwYXRjaCBtYXkg
bm90IG1lZXQgeW91ciByZXF1aXJlbWVudDooDQpGb3IgeW91ciBwZXJmb3JtYW5jZSByZXF1aXJl
bWVudCwgSSBzdWdnZXN0IHVzZSBleHQ0IGZpbGVzeXN0ZW0gYW5kIFNTRC4NCg0KVGhhbmtzLg0K
DQo+IENoZWVycywNCj4gQmVuLg0KPiANCj4gDQoNCg==
^ permalink raw reply
* RE: [PATCH] powerpc/usb: fix bug of kernel hang when initializing usb
From: Benjamin Herrenschmidt @ 2012-02-17 3:42 UTC (permalink / raw)
To: Pan Jiafei-B37022
Cc: Liu Shengzhou-B36685, linux-usb@vger.kernel.org,
linuxppc-dev@lists.ozlabs.org
In-Reply-To: <4F9F958A64F25C4DA463F3D6931E533140828E@039-SN1MPN1-003.039d.mgd.msft.net>
On Fri, 2012-02-17 at 03:20 +0000, Pan Jiafei-B37022 wrote:
> FYI, I once fixed this issue when backport P5020 BSP for WR Linux, The
> following is the patch which I have submitted to linuxbj-internal.
Should I just apply this to upstream ?
Cheers,
Ben.
> From: linuxbj-internal-bounces@linux.freescale.net [mailto:linuxbj-internal-bounces@linux.freescale.net] On Behalf Of Pan Jiafei-B37022
> Sent: Friday, December 16, 2011 12:49 PM
> To: linuxbj-internal@linux.freescale.net
> Cc: Pan Jiafei-B37022
> Subject: [Linuxbj-internal] [PATCH] USB: ehci-fsl: Turn on cache snooping on MPC8xxx
>
> If a MPC8xxx was being used, 'have_sysif_regs' should be set and
> it should setup cache snooping for all the 4GB space on both PPC32
> and PPC64.
>
> Signed-off-by: Pan Jiafei <Jiafei.Pan@freescale.com>
> ---
> drivers/usb/host/ehci-fsl.c | 23 ++++++++++-------------
> 1 files changed, 10 insertions(+), 13 deletions(-)
>
> diff --git a/drivers/usb/host/ehci-fsl.c b/drivers/usb/host/ehci-fsl.c
> index 90534cc..ee14fa7 100644
> --- a/drivers/usb/host/ehci-fsl.c
> +++ b/drivers/usb/host/ehci-fsl.c
> @@ -260,21 +260,18 @@ static void ehci_fsl_usb_setup(struct ehci_hcd *ehci)
> if (pdata->have_sysif_regs) {
> temp = in_be32(non_ehci + FSL_SOC_USB_CTRL);
> out_be32(non_ehci + FSL_SOC_USB_CTRL, temp | 0x00000004);
> - out_be32(non_ehci + FSL_SOC_USB_SNOOP1, 0x0000001b);
> - }
>
> -#if defined(CONFIG_PPC32) && !defined(CONFIG_NOT_COHERENT_CACHE)
> - /*
> - * Turn on cache snooping hardware, since some PowerPC platforms
> - * wholly rely on hardware to deal with cache coherent
> - */
> + /*
> + * Turn on cache snooping hardware, since some PowerPC platforms
> + * wholly rely on hardware to deal with cache coherent
> + */
>
> - /* Setup Snooping for all the 4GB space */
> - /* SNOOP1 starts from 0x0, size 2G */
> - out_be32(non_ehci + FSL_SOC_USB_SNOOP1, 0x0 | SNOOP_SIZE_2GB);
> - /* SNOOP2 starts from 0x80000000, size 2G */
> - out_be32(non_ehci + FSL_SOC_USB_SNOOP2, 0x80000000 | SNOOP_SIZE_2GB);
> -#endif
> + /* Setup Snooping for all the 4GB space */
> + /* SNOOP1 starts from 0x0, size 2G */
> + out_be32(non_ehci + FSL_SOC_USB_SNOOP1, 0x0 | SNOOP_SIZE_2GB);
> + /* SNOOP2 starts from 0x80000000, size 2G */
> + out_be32(non_ehci + FSL_SOC_USB_SNOOP2, 0x80000000 | SNOOP_SIZE_2GB);
> + }
>
> if ((pdata->operating_mode == FSL_USB2_DR_HOST) ||
> (pdata->operating_mode == FSL_USB2_DR_OTG))
^ permalink raw reply
* RE: [PATCH] powerpc/usb: fix bug of kernel hang when initializing usb
From: Pan Jiafei-B37022 @ 2012-02-17 3:46 UTC (permalink / raw)
To: Benjamin Herrenschmidt
Cc: Liu Shengzhou-B36685, linux-usb@vger.kernel.org,
linuxppc-dev@lists.ozlabs.org
In-Reply-To: <1329450178.2892.50.camel@pasglop>
DQoNCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogQmVuamFtaW4gSGVycmVu
c2NobWlkdCBbbWFpbHRvOmJlbmhAa2VybmVsLmNyYXNoaW5nLm9yZ10NCj4gU2VudDogRnJpZGF5
LCBGZWJydWFyeSAxNywgMjAxMiAxMTo0MyBBTQ0KPiBUbzogUGFuIEppYWZlaS1CMzcwMjINCj4g
Q2M6IExpdSBTaGVuZ3pob3UtQjM2Njg1OyBsaW51eC11c2JAdmdlci5rZXJuZWwub3JnOyBsaW51
eHBwYy0NCj4gZGV2QGxpc3RzLm96bGFicy5vcmcNCj4gU3ViamVjdDogUkU6IFtQQVRDSF0gcG93
ZXJwYy91c2I6IGZpeCBidWcgb2Yga2VybmVsIGhhbmcgd2hlbg0KPiBpbml0aWFsaXppbmcgdXNi
DQo+IA0KPiBPbiBGcmksIDIwMTItMDItMTcgYXQgMDM6MjAgKzAwMDAsIFBhbiBKaWFmZWktQjM3
MDIyIHdyb3RlOg0KPiA+IEZZSSwgSSBvbmNlIGZpeGVkIHRoaXMgaXNzdWUgd2hlbiBiYWNrcG9y
dCBQNTAyMCBCU1AgZm9yIFdSIExpbnV4LCBUaGUNCj4gPiBmb2xsb3dpbmcgaXMgdGhlIHBhdGNo
IHdoaWNoIEkgaGF2ZSBzdWJtaXR0ZWQgdG8gbGludXhiai1pbnRlcm5hbC4NCj4gDQo+IFNob3Vs
ZCBJIGp1c3QgYXBwbHkgdGhpcyB0byB1cHN0cmVhbSA/DQo+IA0KPiBDaGVlcnMsDQo+IEJlbi4N
Cj4gDQpbUGFuIEppYWZlaS1CMzcwMjJdIA0KRmVlbCBmcmVlIHRvIGFwcGx5IHRoaXMgdG8gdXBz
dHJlYW0sIHRoYW5rcw0KDQpCZXN0IFJlZ2FyZHMuDQpKaWFmZWkNCg0KPiA+IEZyb206IGxpbnV4
YmotaW50ZXJuYWwtYm91bmNlc0BsaW51eC5mcmVlc2NhbGUubmV0DQo+ID4gW21haWx0bzpsaW51
eGJqLWludGVybmFsLWJvdW5jZXNAbGludXguZnJlZXNjYWxlLm5ldF0gT24gQmVoYWxmIE9mIFBh
bg0KPiA+IEppYWZlaS1CMzcwMjINCj4gPiBTZW50OiBGcmlkYXksIERlY2VtYmVyIDE2LCAyMDEx
IDEyOjQ5IFBNDQo+ID4gVG86IGxpbnV4YmotaW50ZXJuYWxAbGludXguZnJlZXNjYWxlLm5ldA0K
PiA+IENjOiBQYW4gSmlhZmVpLUIzNzAyMg0KPiA+IFN1YmplY3Q6IFtMaW51eGJqLWludGVybmFs
XSBbUEFUQ0hdIFVTQjogZWhjaS1mc2w6IFR1cm4gb24gY2FjaGUNCj4gPiBzbm9vcGluZyBvbiBN
UEM4eHh4DQo+ID4NCj4gPiBJZiBhIE1QQzh4eHggd2FzIGJlaW5nIHVzZWQsICdoYXZlX3N5c2lm
X3JlZ3MnIHNob3VsZCBiZSBzZXQgYW5kIGl0DQo+ID4gc2hvdWxkIHNldHVwIGNhY2hlIHNub29w
aW5nIGZvciBhbGwgdGhlIDRHQiBzcGFjZSBvbiBib3RoIFBQQzMyIGFuZA0KPiA+IFBQQzY0Lg0K
PiA+DQo+ID4gU2lnbmVkLW9mZi1ieTogUGFuIEppYWZlaSA8SmlhZmVpLlBhbkBmcmVlc2NhbGUu
Y29tPg0KPiA+IC0tLQ0KPiA+IGRyaXZlcnMvdXNiL2hvc3QvZWhjaS1mc2wuYyB8ICAgMjMgKysr
KysrKysrKy0tLS0tLS0tLS0tLS0NCj4gPiAxIGZpbGVzIGNoYW5nZWQsIDEwIGluc2VydGlvbnMo
KyksIDEzIGRlbGV0aW9ucygtKQ0KPiA+DQo+ID4gZGlmZiAtLWdpdCBhL2RyaXZlcnMvdXNiL2hv
c3QvZWhjaS1mc2wuYyBiL2RyaXZlcnMvdXNiL2hvc3QvZWhjaS1mc2wuYw0KPiA+IGluZGV4IDkw
NTM0Y2MuLmVlMTRmYTcgMTAwNjQ0DQo+ID4gLS0tIGEvZHJpdmVycy91c2IvaG9zdC9laGNpLWZz
bC5jDQo+ID4gKysrIGIvZHJpdmVycy91c2IvaG9zdC9laGNpLWZzbC5jDQo+ID4gQEAgLTI2MCwy
MSArMjYwLDE4IEBAIHN0YXRpYyB2b2lkIGVoY2lfZnNsX3VzYl9zZXR1cChzdHJ1Y3QgZWhjaV9o
Y2QNCj4gKmVoY2kpDQo+ID4gICAgIGlmIChwZGF0YS0+aGF2ZV9zeXNpZl9yZWdzKSB7DQo+ID4g
ICAgICAgICAgIHRlbXAgPSBpbl9iZTMyKG5vbl9laGNpICsgRlNMX1NPQ19VU0JfQ1RSTCk7DQo+
ID4gICAgICAgICAgIG91dF9iZTMyKG5vbl9laGNpICsgRlNMX1NPQ19VU0JfQ1RSTCwgdGVtcCB8
IDB4MDAwMDAwMDQpOw0KPiA+IC0gICAgICAgICAgb3V0X2JlMzIobm9uX2VoY2kgKyBGU0xfU09D
X1VTQl9TTk9PUDEsIDB4MDAwMDAwMWIpOw0KPiA+IC0gICAgfQ0KPiA+DQo+ID4gLSNpZiBkZWZp
bmVkKENPTkZJR19QUEMzMikgJiYgIWRlZmluZWQoQ09ORklHX05PVF9DT0hFUkVOVF9DQUNIRSkN
Cj4gPiAtICAgIC8qDQo+ID4gLSAgICAqIFR1cm4gb24gY2FjaGUgc25vb3BpbmcgaGFyZHdhcmUs
IHNpbmNlIHNvbWUgUG93ZXJQQyBwbGF0Zm9ybXMNCj4gPiAtICAgICogd2hvbGx5IHJlbHkgb24g
aGFyZHdhcmUgdG8gZGVhbCB3aXRoIGNhY2hlIGNvaGVyZW50DQo+ID4gLSAgICAqLw0KPiA+ICsg
ICAgICAgICAgLyoNCj4gPiArICAgICAgICAgICogVHVybiBvbiBjYWNoZSBzbm9vcGluZyBoYXJk
d2FyZSwgc2luY2Ugc29tZSBQb3dlclBDDQo+IHBsYXRmb3Jtcw0KPiA+ICsgICAgICAgICAgKiB3
aG9sbHkgcmVseSBvbiBoYXJkd2FyZSB0byBkZWFsIHdpdGggY2FjaGUgY29oZXJlbnQNCj4gPiAr
ICAgICAgICAgICovDQo+ID4NCj4gPiAtICAgIC8qIFNldHVwIFNub29waW5nIGZvciBhbGwgdGhl
IDRHQiBzcGFjZSAqLw0KPiA+IC0gICAgLyogU05PT1AxIHN0YXJ0cyBmcm9tIDB4MCwgc2l6ZSAy
RyAqLw0KPiA+IC0gICAgb3V0X2JlMzIobm9uX2VoY2kgKyBGU0xfU09DX1VTQl9TTk9PUDEsIDB4
MCB8IFNOT09QX1NJWkVfMkdCKTsNCj4gPiAtICAgIC8qIFNOT09QMiBzdGFydHMgZnJvbSAweDgw
MDAwMDAwLCBzaXplIDJHICovDQo+ID4gLSAgICBvdXRfYmUzMihub25fZWhjaSArIEZTTF9TT0Nf
VVNCX1NOT09QMiwgMHg4MDAwMDAwMCB8DQo+IFNOT09QX1NJWkVfMkdCKTsNCj4gPiAtI2VuZGlm
DQo+ID4gKyAgICAgICAgICAvKiBTZXR1cCBTbm9vcGluZyBmb3IgYWxsIHRoZSA0R0Igc3BhY2Ug
Ki8NCj4gPiArICAgICAgICAgIC8qIFNOT09QMSBzdGFydHMgZnJvbSAweDAsIHNpemUgMkcgKi8N
Cj4gPiArICAgICAgICAgIG91dF9iZTMyKG5vbl9laGNpICsgRlNMX1NPQ19VU0JfU05PT1AxLCAw
eDAgfA0KPiBTTk9PUF9TSVpFXzJHQik7DQo+ID4gKyAgICAgICAgICAvKiBTTk9PUDIgc3RhcnRz
IGZyb20gMHg4MDAwMDAwMCwgc2l6ZSAyRyAqLw0KPiA+ICsgICAgICAgICAgb3V0X2JlMzIobm9u
X2VoY2kgKyBGU0xfU09DX1VTQl9TTk9PUDIsIDB4ODAwMDAwMDAgfA0KPiBTTk9PUF9TSVpFXzJH
Qik7DQo+ID4gKyAgICB9DQo+ID4NCj4gPiAgICAgIGlmICgocGRhdGEtPm9wZXJhdGluZ19tb2Rl
ID09IEZTTF9VU0IyX0RSX0hPU1QpIHx8DQo+ID4gICAgICAgICAgICAgICAgKHBkYXRhLT5vcGVy
YXRpbmdfbW9kZSA9PSBGU0xfVVNCMl9EUl9PVEcpKQ0KPiANCj4gDQoNCg==
^ permalink raw reply
* RE: [PATCH] powerpc/usb: fix bug of kernel hang when initializing usb
From: Pan Jiafei-B37022 @ 2012-02-17 3:54 UTC (permalink / raw)
To: Benjamin Herrenschmidt
Cc: Liu Shengzhou-B36685, linux-usb@vger.kernel.org,
linuxppc-dev@lists.ozlabs.org
In-Reply-To: <1329450178.2892.50.camel@pasglop>
PiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBCZW5qYW1pbiBIZXJyZW5zY2ht
aWR0IFttYWlsdG86YmVuaEBrZXJuZWwuY3Jhc2hpbmcub3JnXQ0KPiBTZW50OiBGcmlkYXksIEZl
YnJ1YXJ5IDE3LCAyMDEyIDExOjQzIEFNDQo+IFRvOiBQYW4gSmlhZmVpLUIzNzAyMg0KPiBDYzog
TGl1IFNoZW5nemhvdS1CMzY2ODU7IGxpbnV4LXVzYkB2Z2VyLmtlcm5lbC5vcmc7IGxpbnV4cHBj
LQ0KPiBkZXZAbGlzdHMub3psYWJzLm9yZw0KPiBTdWJqZWN0OiBSRTogW1BBVENIXSBwb3dlcnBj
L3VzYjogZml4IGJ1ZyBvZiBrZXJuZWwgaGFuZyB3aGVuDQo+IGluaXRpYWxpemluZyB1c2INCj4g
DQo+IE9uIEZyaSwgMjAxMi0wMi0xNyBhdCAwMzoyMCArMDAwMCwgUGFuIEppYWZlaS1CMzcwMjIg
d3JvdGU6DQo+ID4gRllJLCBJIG9uY2UgZml4ZWQgdGhpcyBpc3N1ZSB3aGVuIGJhY2twb3J0IFA1
MDIwIEJTUCBmb3IgV1IgTGludXgsIFRoZQ0KPiA+IGZvbGxvd2luZyBpcyB0aGUgcGF0Y2ggd2hp
Y2ggSSBoYXZlIHN1Ym1pdHRlZCB0byBsaW51eGJqLWludGVybmFsLg0KPiANCj4gU2hvdWxkIEkg
anVzdCBhcHBseSB0aGlzIHRvIHVwc3RyZWFtID8NCj4gDQo+IENoZWVycywNCj4gQmVuLg0KPiAN
CltQYW4gSmlhZmVpLUIzNzAyMl0gDQpPaywgdGhhbmtzLCBJIHdpbGwgcmVzZW5kIHRoZSBwYXRj
aCBmb3JtYWxseSENCg0KQmVzdCBSZWdhcmRzLg0KSmlhZmVpLg0KDQo+ID4gRnJvbTogbGludXhi
ai1pbnRlcm5hbC1ib3VuY2VzQGxpbnV4LmZyZWVzY2FsZS5uZXQNCj4gPiBbbWFpbHRvOmxpbnV4
YmotaW50ZXJuYWwtYm91bmNlc0BsaW51eC5mcmVlc2NhbGUubmV0XSBPbiBCZWhhbGYgT2YgUGFu
DQo+ID4gSmlhZmVpLUIzNzAyMg0KPiA+IFNlbnQ6IEZyaWRheSwgRGVjZW1iZXIgMTYsIDIwMTEg
MTI6NDkgUE0NCj4gPiBUbzogbGludXhiai1pbnRlcm5hbEBsaW51eC5mcmVlc2NhbGUubmV0DQo+
ID4gQ2M6IFBhbiBKaWFmZWktQjM3MDIyDQo+ID4gU3ViamVjdDogW0xpbnV4YmotaW50ZXJuYWxd
IFtQQVRDSF0gVVNCOiBlaGNpLWZzbDogVHVybiBvbiBjYWNoZQ0KPiA+IHNub29waW5nIG9uIE1Q
Qzh4eHgNCj4gPg0KPiA+IElmIGEgTVBDOHh4eCB3YXMgYmVpbmcgdXNlZCwgJ2hhdmVfc3lzaWZf
cmVncycgc2hvdWxkIGJlIHNldCBhbmQgaXQNCj4gPiBzaG91bGQgc2V0dXAgY2FjaGUgc25vb3Bp
bmcgZm9yIGFsbCB0aGUgNEdCIHNwYWNlIG9uIGJvdGggUFBDMzIgYW5kDQo+ID4gUFBDNjQuDQo+
ID4NCj4gPiBTaWduZWQtb2ZmLWJ5OiBQYW4gSmlhZmVpIDxKaWFmZWkuUGFuQGZyZWVzY2FsZS5j
b20+DQo+ID4gLS0tDQo+ID4gZHJpdmVycy91c2IvaG9zdC9laGNpLWZzbC5jIHwgICAyMyArKysr
KysrKysrLS0tLS0tLS0tLS0tLQ0KPiA+IDEgZmlsZXMgY2hhbmdlZCwgMTAgaW5zZXJ0aW9ucygr
KSwgMTMgZGVsZXRpb25zKC0pDQo+ID4NCj4gPiBkaWZmIC0tZ2l0IGEvZHJpdmVycy91c2IvaG9z
dC9laGNpLWZzbC5jIGIvZHJpdmVycy91c2IvaG9zdC9laGNpLWZzbC5jDQo+ID4gaW5kZXggOTA1
MzRjYy4uZWUxNGZhNyAxMDA2NDQNCj4gPiAtLS0gYS9kcml2ZXJzL3VzYi9ob3N0L2VoY2ktZnNs
LmMNCj4gPiArKysgYi9kcml2ZXJzL3VzYi9ob3N0L2VoY2ktZnNsLmMNCj4gPiBAQCAtMjYwLDIx
ICsyNjAsMTggQEAgc3RhdGljIHZvaWQgZWhjaV9mc2xfdXNiX3NldHVwKHN0cnVjdCBlaGNpX2hj
ZA0KPiAqZWhjaSkNCj4gPiAgICAgaWYgKHBkYXRhLT5oYXZlX3N5c2lmX3JlZ3MpIHsNCj4gPiAg
ICAgICAgICAgdGVtcCA9IGluX2JlMzIobm9uX2VoY2kgKyBGU0xfU09DX1VTQl9DVFJMKTsNCj4g
PiAgICAgICAgICAgb3V0X2JlMzIobm9uX2VoY2kgKyBGU0xfU09DX1VTQl9DVFJMLCB0ZW1wIHwg
MHgwMDAwMDAwNCk7DQo+ID4gLSAgICAgICAgICBvdXRfYmUzMihub25fZWhjaSArIEZTTF9TT0Nf
VVNCX1NOT09QMSwgMHgwMDAwMDAxYik7DQo+ID4gLSAgICB9DQo+ID4NCj4gPiAtI2lmIGRlZmlu
ZWQoQ09ORklHX1BQQzMyKSAmJiAhZGVmaW5lZChDT05GSUdfTk9UX0NPSEVSRU5UX0NBQ0hFKQ0K
PiA+IC0gICAgLyoNCj4gPiAtICAgICogVHVybiBvbiBjYWNoZSBzbm9vcGluZyBoYXJkd2FyZSwg
c2luY2Ugc29tZSBQb3dlclBDIHBsYXRmb3Jtcw0KPiA+IC0gICAgKiB3aG9sbHkgcmVseSBvbiBo
YXJkd2FyZSB0byBkZWFsIHdpdGggY2FjaGUgY29oZXJlbnQNCj4gPiAtICAgICovDQo+ID4gKyAg
ICAgICAgICAvKg0KPiA+ICsgICAgICAgICAgKiBUdXJuIG9uIGNhY2hlIHNub29waW5nIGhhcmR3
YXJlLCBzaW5jZSBzb21lIFBvd2VyUEMNCj4gcGxhdGZvcm1zDQo+ID4gKyAgICAgICAgICAqIHdo
b2xseSByZWx5IG9uIGhhcmR3YXJlIHRvIGRlYWwgd2l0aCBjYWNoZSBjb2hlcmVudA0KPiA+ICsg
ICAgICAgICAgKi8NCj4gPg0KPiA+IC0gICAgLyogU2V0dXAgU25vb3BpbmcgZm9yIGFsbCB0aGUg
NEdCIHNwYWNlICovDQo+ID4gLSAgICAvKiBTTk9PUDEgc3RhcnRzIGZyb20gMHgwLCBzaXplIDJH
ICovDQo+ID4gLSAgICBvdXRfYmUzMihub25fZWhjaSArIEZTTF9TT0NfVVNCX1NOT09QMSwgMHgw
IHwgU05PT1BfU0laRV8yR0IpOw0KPiA+IC0gICAgLyogU05PT1AyIHN0YXJ0cyBmcm9tIDB4ODAw
MDAwMDAsIHNpemUgMkcgKi8NCj4gPiAtICAgIG91dF9iZTMyKG5vbl9laGNpICsgRlNMX1NPQ19V
U0JfU05PT1AyLCAweDgwMDAwMDAwIHwNCj4gU05PT1BfU0laRV8yR0IpOw0KPiA+IC0jZW5kaWYN
Cj4gPiArICAgICAgICAgIC8qIFNldHVwIFNub29waW5nIGZvciBhbGwgdGhlIDRHQiBzcGFjZSAq
Lw0KPiA+ICsgICAgICAgICAgLyogU05PT1AxIHN0YXJ0cyBmcm9tIDB4MCwgc2l6ZSAyRyAqLw0K
PiA+ICsgICAgICAgICAgb3V0X2JlMzIobm9uX2VoY2kgKyBGU0xfU09DX1VTQl9TTk9PUDEsIDB4
MCB8DQo+IFNOT09QX1NJWkVfMkdCKTsNCj4gPiArICAgICAgICAgIC8qIFNOT09QMiBzdGFydHMg
ZnJvbSAweDgwMDAwMDAwLCBzaXplIDJHICovDQo+ID4gKyAgICAgICAgICBvdXRfYmUzMihub25f
ZWhjaSArIEZTTF9TT0NfVVNCX1NOT09QMiwgMHg4MDAwMDAwMCB8DQo+IFNOT09QX1NJWkVfMkdC
KTsNCj4gPiArICAgIH0NCj4gPg0KPiA+ICAgICAgaWYgKChwZGF0YS0+b3BlcmF0aW5nX21vZGUg
PT0gRlNMX1VTQjJfRFJfSE9TVCkgfHwNCj4gPiAgICAgICAgICAgICAgICAocGRhdGEtPm9wZXJh
dGluZ19tb2RlID09IEZTTF9VU0IyX0RSX09URykpDQo+IA0KPiANCg0K
^ permalink raw reply
* RE: [PATCH 1/2] powerpc/85xx: fix problem that prevents PHYS_64BIT from configurable
From: Li Yang-R58472 @ 2012-02-17 4:32 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-dev@ozlabs.org
In-Reply-To: <EDB74FED-002D-4F94-B134-995BFB4C0A6B@kernel.crashing.org>
>Subject: Re: [PATCH 1/2] powerpc/85xx: fix problem that prevents
>PHYS_64BIT from configurable
>
>
>On Feb 16, 2012, at 6:10 AM, Li Yang wrote:
>
>> Fix the problem that large physical address support cannot be disabled
>> when some platforms which only provides 36-bit support are selected.
>> According to the philosophy of kernel config enabling a platform
>> support doesn't mean the kernel is only running on that platform.
>> Remove the auto selection of PHYS_64BIT option for these platforms.
>> They will need to use a 36bit default config that selects PHYS_64BIT
>> explicitly.
>>
>> The reason why we need to keep PHYS_64BIT option configurable is that
>> enabling it cause negative performance impact on various aspects like
>> TLB miss and physical address manipulating. We should not enable it
>> unless really needed, e.g. use large memory of 4GB or bigger.
>>
>> Signed-off-by: Li Yang <leoli@freescale.com>
>> ---
>> arch/powerpc/platforms/85xx/Kconfig | 6 ------
>> 1 files changed, 0 insertions(+), 6 deletions(-)
>
>Nak, this isn't correct.
>
>For some of these platforms like P2041RDB, P3041DS, P3060QDS, P4080DS, &
>P5020DS only a 36-bit physical address map is supported by u-boot and the
>device tree. This was a decision that was made to NOT support 32-bit
>address map for these boards and accept the performance implication of it
>to reduce the # of builds, etc.
Ok. Although personally I don't think # of builds matters that much.
>
>Additionally, outside of maybe P2041RDB I believe the majority of these
>boards ship with 4G of DDR (but that off the top of my head) and thus
>require the 36-bit / PHYS_64BIT support to be enabled.
I know that current support of DPAA boards requires 36-bit. But I don't th=
ink they need to select the PHYS_64BIT option directly and make it not conf=
igurable. It's conflicting with the logic that enabling a platform support=
doesn't mean the kernel is only running on that platform. Btw: what's you=
r recommendations on solving this?
- Leo
^ permalink raw reply
* linux-next: build failure after merge of the final tree (akpm tree related)
From: Stephen Rothwell @ 2012-02-17 5:30 UTC (permalink / raw)
To: Andrew Morton; +Cc: linux-next, ppc-dev, linux-kernel, H. Peter Anvin
[-- Attachment #1: Type: text/plain, Size: 1816 bytes --]
Hi Andrew,
After merging the final tree, today's linux-next build (powerpc
allnoconfig) failed like this:
In file included from include/linux/posix_types.h:47:0,
from include/linux/types.h:17,
from include/linux/page-flags.h:8,
from kernel/bounds.c:9:
arch/powerpc/include/asm/posix_types.h:15:14: error: conflicting types for '__kernel_size_t'
arch/powerpc/include/asm/posix_types.h:14:22: note: previous declaration of '__kernel_size_t' was here
In file included from include/linux/page-flags.h:8:0,
from kernel/bounds.c:9:
include/linux/types.h:68:1: error: unknown type name '__kernel_ssize_t'
Caused by commit a9dbe86e5995 ("powerpc: use generic posix_types.h").
This think was pointed out a couple of days ago, so maybe Andrew needs a
newer version of the patch.
I added this fix patch for today:
From: Stephen Rothwell <sfr@canb.auug.org.au>
Date: Fri, 17 Feb 2012 16:25:48 +1100
Subject: [PATCH] powerpc: use generic posix_types.h fix
Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
---
arch/powerpc/include/asm/posix_types.h | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/arch/powerpc/include/asm/posix_types.h b/arch/powerpc/include/asm/posix_types.h
index 1fbe027f..f139325 100644
--- a/arch/powerpc/include/asm/posix_types.h
+++ b/arch/powerpc/include/asm/posix_types.h
@@ -12,7 +12,7 @@ typedef unsigned long __kernel_old_dev_t;
#define __kernel_old_dev_t __kernel_old_dev_t
#else
typedef unsigned int __kernel_size_t;
-typedef int __kernel_size_t;
+typedef int __kernel_ssize_t;
typedef long __kernel_ptrdiff_t;
#define __kernel_size_t __kernel_size_t
--
1.7.9
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply related
* Re: [PATCH v1 0/4][makedumpfile] vmalloc translation support for PPC32
From: Suzuki K. Poulose @ 2012-02-17 5:55 UTC (permalink / raw)
To: Atsushi Kumagai; +Cc: linux ppc dev, kexec
In-Reply-To: <20120217093220.0c2993a1.kumagai-atsushi@mxc.nes.nec.co.jp>
On 02/17/2012 06:02 AM, Atsushi Kumagai wrote:
> Hi, Suzuki
>
> On Thu, 16 Feb 2012 09:05:17 +0530
> "Suzuki K. Poulose"<suzuki@in.ibm.com> wrote:
>
>> The series introduces an infrastructure to define platform specific
>> bits for page translation for PPC and PPC44x support for vmalloc
>> translation.
>>
>> This is similar to what we have implemented for Crash-utility.
>>
>> The patches are based makedumpfile-1.4.2 + PPC32 support patches
>> which is queued in for 1.4.3.
>>
>> ---
>>
>> Suzuki K. Poulose (4):
>> [makedumpfile][ppc] PPC44x page translation definitions
>> [makedumpfile][ppc] Define platform descriptors for page translation
>> [makedumpfile][ppc] Generic vmalloc translation support
>> [makedumpfile] Add read_string routine
>>
>>
>> arch/ppc.c | 108 ++++++++++++++++++++++++++++++++++++++++++++++++++++++--
>> makedumpfile.c | 14 +++++++
>> makedumpfile.h | 21 +++++++++++
>> 3 files changed, 139 insertions(+), 4 deletions(-)
>>
>> --
>> Suzuki Poulose
>
> Could you tell me what kind of data is stored in vmalloc region in PPC ?
> I want to estimate importance of your patches for makedumpfile.
I know at least the modules are loaded in the vmalloc'd region. I have
Cc'ed linux-ppc dev. We should be able to get enough info from the experts here.
Josh / Kumar / Others,
Could you please let us know your thoughts ?
Thanks
Suzuki
^ permalink raw reply
* [PATCH] USB: ehci-fsl: Turn on cache snooping on MPC8xxx
From: Pan Jiafei @ 2012-02-17 5:57 UTC (permalink / raw)
To: linuxppc-dev; +Cc: linux-usb, Pan Jiafei
If a MPC8xxx was being used, 'have_sysif_regs' should be set and
it should setup cache snooping for all the 4GB space on both PPC32
and PPC64.
Signed-off-by: Pan Jiafei <Jiafei.Pan@freescale.com>
---
drivers/usb/host/ehci-fsl.c | 23 ++++++++++-------------
1 files changed, 10 insertions(+), 13 deletions(-)
diff --git a/drivers/usb/host/ehci-fsl.c b/drivers/usb/host/ehci-fsl.c
index c26a82e..8327d3e 100644
--- a/drivers/usb/host/ehci-fsl.c
+++ b/drivers/usb/host/ehci-fsl.c
@@ -252,21 +252,18 @@ static int ehci_fsl_usb_setup(struct ehci_hcd *ehci)
if (pdata->have_sysif_regs) {
temp = in_be32(non_ehci + FSL_SOC_USB_CTRL);
out_be32(non_ehci + FSL_SOC_USB_CTRL, temp | 0x00000004);
- out_be32(non_ehci + FSL_SOC_USB_SNOOP1, 0x0000001b);
- }
-#if defined(CONFIG_PPC32) && !defined(CONFIG_NOT_COHERENT_CACHE)
- /*
- * Turn on cache snooping hardware, since some PowerPC platforms
- * wholly rely on hardware to deal with cache coherent
- */
+ /*
+ * Turn on cache snooping hardware, since some PowerPC platforms
+ * wholly rely on hardware to deal with cache coherent
+ */
- /* Setup Snooping for all the 4GB space */
- /* SNOOP1 starts from 0x0, size 2G */
- out_be32(non_ehci + FSL_SOC_USB_SNOOP1, 0x0 | SNOOP_SIZE_2GB);
- /* SNOOP2 starts from 0x80000000, size 2G */
- out_be32(non_ehci + FSL_SOC_USB_SNOOP2, 0x80000000 | SNOOP_SIZE_2GB);
-#endif
+ /* Setup Snooping for all the 4GB space */
+ /* SNOOP1 starts from 0x0, size 2G */
+ out_be32(non_ehci + FSL_SOC_USB_SNOOP1, 0x0 | SNOOP_SIZE_2GB);
+ /* SNOOP2 starts from 0x80000000, size 2G */
+ out_be32(non_ehci + FSL_SOC_USB_SNOOP2, 0x80000000 | SNOOP_SIZE_2GB);
+ }
if ((pdata->operating_mode == FSL_USB2_DR_HOST) ||
(pdata->operating_mode == FSL_USB2_DR_OTG))
--
1.7.5.1
^ permalink raw reply related
* Re: linux-next: build failure after merge of the final tree (akpm tree related)
From: Benjamin Herrenschmidt @ 2012-02-17 6:07 UTC (permalink / raw)
To: Stephen Rothwell
Cc: Andrew Morton, linux-next, ppc-dev, linux-kernel, H. Peter Anvin
In-Reply-To: <20120217163057.8af53b853b36365b7fff203c@canb.auug.org.au>
On Fri, 2012-02-17 at 16:30 +1100, Stephen Rothwell wrote:
> Hi Andrew,
>
> After merging the final tree, today's linux-next build (powerpc
> allnoconfig) failed like this:
>
> In file included from include/linux/posix_types.h:47:0,
> from include/linux/types.h:17,
> from include/linux/page-flags.h:8,
> from kernel/bounds.c:9:
> arch/powerpc/include/asm/posix_types.h:15:14: error: conflicting types for '__kernel_size_t'
> arch/powerpc/include/asm/posix_types.h:14:22: note: previous declaration of '__kernel_size_t' was here
> In file included from include/linux/page-flags.h:8:0,
> from kernel/bounds.c:9:
> include/linux/types.h:68:1: error: unknown type name '__kernel_ssize_t'
>
> Caused by commit a9dbe86e5995 ("powerpc: use generic posix_types.h").
>
> This think was pointed out a couple of days ago, so maybe Andrew needs a
> newer version of the patch.
Yes, I pointed that out to Peter a while back, maybe it got lost ...
Cheers,
Ben.
> I added this fix patch for today:
>
> From: Stephen Rothwell <sfr@canb.auug.org.au>
> Date: Fri, 17 Feb 2012 16:25:48 +1100
> Subject: [PATCH] powerpc: use generic posix_types.h fix
>
> Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
> ---
> arch/powerpc/include/asm/posix_types.h | 2 +-
> 1 files changed, 1 insertions(+), 1 deletions(-)
>
> diff --git a/arch/powerpc/include/asm/posix_types.h b/arch/powerpc/include/asm/posix_types.h
> index 1fbe027f..f139325 100644
> --- a/arch/powerpc/include/asm/posix_types.h
> +++ b/arch/powerpc/include/asm/posix_types.h
> @@ -12,7 +12,7 @@ typedef unsigned long __kernel_old_dev_t;
> #define __kernel_old_dev_t __kernel_old_dev_t
> #else
> typedef unsigned int __kernel_size_t;
> -typedef int __kernel_size_t;
> +typedef int __kernel_ssize_t;
> typedef long __kernel_ptrdiff_t;
> #define __kernel_size_t __kernel_size_t
>
> --
> 1.7.9
>
^ permalink raw reply
* Re: [PATCH] USB: ehci-fsl: Turn on cache snooping on MPC8xxx
From: Li Yang @ 2012-02-17 6:56 UTC (permalink / raw)
To: Pan Jiafei; +Cc: linux-usb, linuxppc-dev
In-Reply-To: <1329458236-4619-1-git-send-email-Jiafei.Pan@freescale.com>
On Fri, Feb 17, 2012 at 1:57 PM, Pan Jiafei <Jiafei.Pan@freescale.com> wrot=
e:
> If a MPC8xxx was being used, 'have_sysif_regs' should be set and
> it should setup cache snooping for all the 4GB space on both PPC32
> and PPC64.
>
> Signed-off-by: Pan Jiafei <Jiafei.Pan@freescale.com>
Hi Jiafei,
You should have sent this patch upstream earlier. I remember you
asked about it a few months ago. :)
Acked-by: Li Yang <leoli@freescale.com>
> ---
> =C2=A0drivers/usb/host/ehci-fsl.c | =C2=A0 23 ++++++++++-------------
> =C2=A01 files changed, 10 insertions(+), 13 deletions(-)
>
> diff --git a/drivers/usb/host/ehci-fsl.c b/drivers/usb/host/ehci-fsl.c
> index c26a82e..8327d3e 100644
> --- a/drivers/usb/host/ehci-fsl.c
> +++ b/drivers/usb/host/ehci-fsl.c
> @@ -252,21 +252,18 @@ static int ehci_fsl_usb_setup(struct ehci_hcd *ehci=
)
> =C2=A0 =C2=A0 =C2=A0 =C2=A0if (pdata->have_sysif_regs) {
> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0temp =3D in_be32(n=
on_ehci + FSL_SOC_USB_CTRL);
> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0out_be32(non_ehci =
+ FSL_SOC_USB_CTRL, temp | 0x00000004);
> - =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 out_be32(non_ehci + FS=
L_SOC_USB_SNOOP1, 0x0000001b);
> - =C2=A0 =C2=A0 =C2=A0 }
>
> -#if defined(CONFIG_PPC32) && !defined(CONFIG_NOT_COHERENT_CACHE)
> - =C2=A0 =C2=A0 =C2=A0 /*
> - =C2=A0 =C2=A0 =C2=A0 =C2=A0* Turn on cache snooping hardware, since som=
e PowerPC platforms
> - =C2=A0 =C2=A0 =C2=A0 =C2=A0* wholly rely on hardware to deal with cache=
coherent
> - =C2=A0 =C2=A0 =C2=A0 =C2=A0*/
> + =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 /*
> + =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 * Turn on cache snoopi=
ng hardware, since some PowerPC platforms
> + =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 * wholly rely on hardw=
are to deal with cache coherent
> + =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 */
>
> - =C2=A0 =C2=A0 =C2=A0 /* Setup Snooping for all the 4GB space */
> - =C2=A0 =C2=A0 =C2=A0 /* SNOOP1 starts from 0x0, size 2G */
> - =C2=A0 =C2=A0 =C2=A0 out_be32(non_ehci + FSL_SOC_USB_SNOOP1, 0x0 | SNOO=
P_SIZE_2GB);
> - =C2=A0 =C2=A0 =C2=A0 /* SNOOP2 starts from 0x80000000, size 2G */
> - =C2=A0 =C2=A0 =C2=A0 out_be32(non_ehci + FSL_SOC_USB_SNOOP2, 0x80000000=
| SNOOP_SIZE_2GB);
> -#endif
> + =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 /* Setup Snooping for =
all the 4GB space */
> + =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 /* SNOOP1 starts from =
0x0, size 2G */
> + =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 out_be32(non_ehci + FS=
L_SOC_USB_SNOOP1, 0x0 | SNOOP_SIZE_2GB);
> + =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 /* SNOOP2 starts from =
0x80000000, size 2G */
> + =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 out_be32(non_ehci + FS=
L_SOC_USB_SNOOP2, 0x80000000 | SNOOP_SIZE_2GB);
> + =C2=A0 =C2=A0 =C2=A0 }
>
> =C2=A0 =C2=A0 =C2=A0 =C2=A0if ((pdata->operating_mode =3D=3D FSL_USB2_DR_=
HOST) ||
> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0(pdata->operating_mode =3D=3D FSL_USB2_DR_OTG))
> --
> 1.7.5.1
^ permalink raw reply
* [PATCH 1/2] powerpc/44x: Add new compatible value for EMAC node of APM821XX dts file.
From: Duc Dang @ 2012-02-17 8:06 UTC (permalink / raw)
To: Benjamin Herrenschmidt, Paul Mackerras
Cc: Duc Dang, linuxppc-dev, linux-kernel
This compatible value will be used to distinguish some special
features of APM821XX EMAC: no half duplex mode support, configuring
jumbo frame.
Signed-off-by: Duc Dang <dhdang@apm.com>
---
arch/powerpc/boot/dts/bluestone.dts | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/arch/powerpc/boot/dts/bluestone.dts b/arch/powerpc/boot/dts/bluestone.dts
index 2a56a0d..74876f7 100644
--- a/arch/powerpc/boot/dts/bluestone.dts
+++ b/arch/powerpc/boot/dts/bluestone.dts
@@ -222,7 +222,7 @@
EMAC0: ethernet@ef600c00 {
device_type = "network";
- compatible = "ibm,emac4sync";
+ compatible = "ibm,emac-apm821xx", "ibm,emac4sync";
interrupt-parent = <&EMAC0>;
interrupts = <0x0 0x1>;
#interrupt-cells = <1>;
--
1.7.5.4
^ permalink raw reply related
* [PATCH 2/2] powerpc/44x: Add more changes for APM821XX EMAC driver
From: Duc Dang @ 2012-02-17 8:07 UTC (permalink / raw)
To: Benjamin Herrenschmidt, Paul Mackerras
Cc: Duc Dang, linuxppc-dev, linux-kernel
This patch includes:
Configure EMAC PHY clock source (clock from PHY or internal clock).
Do not advertise PHY half duplex capability as APM821XX EMAC does not
support half duplex mode.
Add changes to support configuring jumbo frame for APM821XX EMAC.
Signed-off-by: Duc Dang <dhdang@apm.com>
---
drivers/net/ethernet/ibm/emac/core.c | 26 +++++++++++++++++++++++++-
drivers/net/ethernet/ibm/emac/core.h | 13 +++++++++++--
drivers/net/ethernet/ibm/emac/emac.h | 5 ++++-
3 files changed, 40 insertions(+), 4 deletions(-)
diff --git a/drivers/net/ethernet/ibm/emac/core.c b/drivers/net/ethernet/ibm/emac/core.c
index ed79b2d..de620f1 100644
--- a/drivers/net/ethernet/ibm/emac/core.c
+++ b/drivers/net/ethernet/ibm/emac/core.c
@@ -434,6 +434,11 @@ static inline u32 emac_iff2rmr(struct net_device *ndev)
else if (!netdev_mc_empty(ndev))
r |= EMAC_RMR_MAE;
+ if (emac_has_feature(dev, EMAC_APM821XX_REQ_JUMBO_FRAME_SIZE)) {
+ r &= ~EMAC4_RMR_MJS_MASK;
+ r |= EMAC4_RMR_MJS(ndev->mtu);
+ }
+
return r;
}
@@ -965,6 +970,7 @@ static int emac_resize_rx_ring(struct emac_instance *dev, int new_mtu)
int rx_sync_size = emac_rx_sync_size(new_mtu);
int rx_skb_size = emac_rx_skb_size(new_mtu);
int i, ret = 0;
+ int mr1_jumbo_bit_change = 0;
mutex_lock(&dev->link_lock);
emac_netif_stop(dev);
@@ -1013,7 +1019,14 @@ static int emac_resize_rx_ring(struct emac_instance *dev, int new_mtu)
}
skip:
/* Check if we need to change "Jumbo" bit in MR1 */
- if ((new_mtu > ETH_DATA_LEN) ^ (dev->ndev->mtu > ETH_DATA_LEN)) {
+ if (emac_has_feature(dev, EMAC_APM821XX_REQ_JUMBO_FRAME_SIZE))
+ mr1_jumbo_bit_change = (new_mtu > ETH_DATA_LEN) ||
+ (dev->ndev->mtu > ETH_DATA_LEN);
+ else
+ mr1_jumbo_bit_change = (new_mtu > ETH_DATA_LEN) ^
+ (dev->ndev->mtu > ETH_DATA_LEN);
+
+ if (mr1_jumbo_bit_change) {
/* This is to prevent starting RX channel in emac_rx_enable() */
set_bit(MAL_COMMAC_RX_STOPPED, &dev->commac.flags);
@@ -2471,6 +2484,7 @@ static int __devinit emac_init_phy(struct emac_instance *dev)
/* Disable any PHY features not supported by the platform */
dev->phy.def->features &= ~dev->phy_feat_exc;
+ dev->phy.features &= ~dev->phy_feat_exc;
/* Setup initial link parameters */
if (dev->phy.features & SUPPORTED_Autoneg) {
@@ -2568,6 +2582,10 @@ static int __devinit emac_init_config(struct emac_instance *dev)
if (of_device_is_compatible(np, "ibm,emac-405ex") ||
of_device_is_compatible(np, "ibm,emac-405exr"))
dev->features |= EMAC_FTR_440EP_PHY_CLK_FIX;
+ if (of_device_is_compatible(np, "ibm,emac-apm821xx"))
+ dev->features |= (EMAC_APM821XX_REQ_JUMBO_FRAME_SIZE
+ | EMAC_FTR_APM821XX_NO_HALF_DUPLEX
+ | EMAC_FTR_460EX_PHY_CLK_FIX);
} else if (of_device_is_compatible(np, "ibm,emac4")) {
dev->features |= EMAC_FTR_EMAC4;
if (of_device_is_compatible(np, "ibm,emac-440gx"))
@@ -2818,6 +2836,12 @@ static int __devinit emac_probe(struct platform_device *ofdev)
dev->stop_timeout = STOP_TIMEOUT_100;
INIT_DELAYED_WORK(&dev->link_work, emac_link_timer);
+ /* Some SoCs like APM821xx does not support Half Duplex mode. */
+ if (emac_has_feature(dev, EMAC_FTR_APM821XX_NO_HALF_DUPLEX))
+ dev->phy_feat_exc = (SUPPORTED_1000baseT_Half
+ | SUPPORTED_100baseT_Half
+ | SUPPORTED_10baseT_Half);
+
/* Find PHY if any */
err = emac_init_phy(dev);
if (err != 0)
diff --git a/drivers/net/ethernet/ibm/emac/core.h b/drivers/net/ethernet/ibm/emac/core.h
index fa3ec57..9dea85a 100644
--- a/drivers/net/ethernet/ibm/emac/core.h
+++ b/drivers/net/ethernet/ibm/emac/core.h
@@ -325,7 +325,14 @@ struct emac_instance {
* Set if we need phy clock workaround for 460ex or 460gt
*/
#define EMAC_FTR_460EX_PHY_CLK_FIX 0x00000400
-
+/*
+ * APM821xx requires Jumbo frame size set explicitly
+ */
+#define EMAC_APM821XX_REQ_JUMBO_FRAME_SIZE 0x00000800
+/*
+ * APM821xx does not support Half Duplex mode
+ */
+#define EMAC_FTR_APM821XX_NO_HALF_DUPLEX 0x00001000
/* Right now, we don't quite handle the always/possible masks on the
* most optimal way as we don't have a way to say something like
@@ -353,7 +360,9 @@ enum {
EMAC_FTR_NO_FLOW_CONTROL_40x |
#endif
EMAC_FTR_460EX_PHY_CLK_FIX |
- EMAC_FTR_440EP_PHY_CLK_FIX,
+ EMAC_FTR_440EP_PHY_CLK_FIX |
+ EMAC_APM821XX_REQ_JUMBO_FRAME_SIZE |
+ EMAC_FTR_APM821XX_NO_HALF_DUPLEX,
};
static inline int emac_has_feature(struct emac_instance *dev,
diff --git a/drivers/net/ethernet/ibm/emac/emac.h b/drivers/net/ethernet/ibm/emac/emac.h
index 1568278..36bcd69 100644
--- a/drivers/net/ethernet/ibm/emac/emac.h
+++ b/drivers/net/ethernet/ibm/emac/emac.h
@@ -212,7 +212,10 @@ struct emac_regs {
#define EMAC4_RMR_RFAF_64_1024 0x00000006
#define EMAC4_RMR_RFAF_128_2048 0x00000007
#define EMAC4_RMR_BASE EMAC4_RMR_RFAF_128_2048
-
+#if defined(CONFIG_APM821xx)
+#define EMAC4_RMR_MJS_MASK 0x0001fff8
+#define EMAC4_RMR_MJS(s) (((s) << 3) & EMAC4_RMR_MJS_MASK)
+#endif
/* EMACx_ISR & EMACx_ISER */
#define EMAC4_ISR_TXPE 0x20000000
#define EMAC4_ISR_RXPE 0x10000000
--
1.7.5.4
^ permalink raw reply related
* Re: [PATCH v1 0/4][makedumpfile] vmalloc translation support for PPC32
From: Benjamin Herrenschmidt @ 2012-02-17 8:39 UTC (permalink / raw)
To: Suzuki K. Poulose; +Cc: linux ppc dev, Atsushi Kumagai, kexec
In-Reply-To: <4F3DEBCF.8000201@in.ibm.com>
On Fri, 2012-02-17 at 11:25 +0530, Suzuki K. Poulose wrote:
> > Could you tell me what kind of data is stored in vmalloc region in
> PPC ?
> > I want to estimate importance of your patches for makedumpfile.
> I know at least the modules are loaded in the vmalloc'd region. I have
> Cc'ed linux-ppc dev. We should be able to get enough info from the
> experts here.
>
> Josh / Kumar / Others,
>
> Could you please let us know your thoughts ?
Modules, driver IO mappings, etc... I can see that being useful for
crashdumps.
Cheers,
Ben.
^ permalink raw reply
* Re: [PATCH 1/2] powerpc/85xx: fix problem that prevents PHYS_64BIT from configurable
From: Benjamin Herrenschmidt @ 2012-02-17 8:42 UTC (permalink / raw)
To: Li Yang; +Cc: linuxppc-dev
In-Reply-To: <1329394210-1014-1-git-send-email-leoli@freescale.com>
On Thu, 2012-02-16 at 20:10 +0800, Li Yang wrote:
> Fix the problem that large physical address support cannot be
> disabled when some platforms which only provides 36-bit support
> are selected. According to the philosophy of kernel config
> enabling a platform support doesn't mean the kernel is only
> running on that platform. Remove the auto selection of PHYS_64BIT
> option for these platforms. They will need to use a 36bit default
> config that selects PHYS_64BIT explicitly.
No, but unless I'm wrong, with your patch, enabling those platforms will
build the code ... but they won't work unless you -also- enable
PHYS_64BIT one way or another. I thus disagree.
If I enable CONFIG_P1022_DS, I expect those boards to work.
If that's going to negatively impact perfs on other boards that I also
enabled, then so be it (and we should document it in the help text).
Cheers,
Ben.
> The reason why we need to keep PHYS_64BIT option configurable is
> that enabling it cause negative performance impact on various
> aspects like TLB miss and physical address manipulating. We should
> not enable it unless really needed, e.g. use large memory of 4GB
> or bigger.
>
> Signed-off-by: Li Yang <leoli@freescale.com>
> ---
> arch/powerpc/platforms/85xx/Kconfig | 6 ------
> 1 files changed, 0 insertions(+), 6 deletions(-)
>
> diff --git a/arch/powerpc/platforms/85xx/Kconfig b/arch/powerpc/platforms/85xx/Kconfig
> index d7946be..d9bc0bd 100644
> --- a/arch/powerpc/platforms/85xx/Kconfig
> +++ b/arch/powerpc/platforms/85xx/Kconfig
> @@ -80,7 +80,6 @@ config P1010_RDB
> config P1022_DS
> bool "Freescale P1022 DS"
> select DEFAULT_UIMAGE
> - select PHYS_64BIT # The DTS has 36-bit addresses
> select SWIOTLB
> help
> This option enables support for the Freescale P1022DS reference board.
> @@ -175,7 +174,6 @@ config P2041_RDB
> bool "Freescale P2041 RDB"
> select DEFAULT_UIMAGE
> select PPC_E500MC
> - select PHYS_64BIT
> select SWIOTLB
> select ARCH_REQUIRE_GPIOLIB
> select GPIO_MPC8XXX
> @@ -188,7 +186,6 @@ config P3041_DS
> bool "Freescale P3041 DS"
> select DEFAULT_UIMAGE
> select PPC_E500MC
> - select PHYS_64BIT
> select SWIOTLB
> select ARCH_REQUIRE_GPIOLIB
> select GPIO_MPC8XXX
> @@ -201,7 +198,6 @@ config P3060_QDS
> bool "Freescale P3060 QDS"
> select DEFAULT_UIMAGE
> select PPC_E500MC
> - select PHYS_64BIT
> select SWIOTLB
> select GPIO_MPC8XXX
> select HAS_RAPIDIO
> @@ -213,7 +209,6 @@ config P4080_DS
> bool "Freescale P4080 DS"
> select DEFAULT_UIMAGE
> select PPC_E500MC
> - select PHYS_64BIT
> select SWIOTLB
> select ARCH_REQUIRE_GPIOLIB
> select GPIO_MPC8XXX
> @@ -229,7 +224,6 @@ config P5020_DS
> select DEFAULT_UIMAGE
> select E500
> select PPC_E500MC
> - select PHYS_64BIT
> select SWIOTLB
> select ARCH_REQUIRE_GPIOLIB
> select GPIO_MPC8XXX
^ permalink raw reply
* RE: [PATCH 1/2] powerpc/85xx: fix problem that prevents PHYS_64BIT from configurable
From: Benjamin Herrenschmidt @ 2012-02-17 8:43 UTC (permalink / raw)
To: Li Yang-R58472; +Cc: linuxppc-dev@ozlabs.org
In-Reply-To: <94F013E7935FF44C83EBE7784D62AD3F057427B6@039-SN2MPN1-023.039d.mgd.msft.net>
On Fri, 2012-02-17 at 04:32 +0000, Li Yang-R58472 wrote:
> >Additionally, outside of maybe P2041RDB I believe the majority of
> these
> >boards ship with 4G of DDR (but that off the top of my head) and thus
> >require the 36-bit / PHYS_64BIT support to be enabled.
>
> I know that current support of DPAA boards requires 36-bit. But I
> don't think they need to select the PHYS_64BIT option directly and
> make it not configurable. It's conflicting with the logic that
> enabling a platform support doesn't mean the kernel is only running on
> that platform. Btw: what's your recommendations on solving this?
But selecting PHYS_64BIT shouldn't prevent running on the other
platforms. If it does, then this needs to be fixed.
Cheers,
Ben.
^ permalink raw reply
* Re: [RFC PATCH 13/16] powerpc/booke: Provide exception macros with interrupt name
From: Benjamin Herrenschmidt @ 2012-02-17 8:50 UTC (permalink / raw)
To: Scott Wood; +Cc: kvm-ppc, linuxppc-dev, agraf, kvm
In-Reply-To: <20111221013440.GM8378@schlenkerla.am.freescale.net>
On Tue, 2011-12-20 at 19:34 -0600, Scott Wood wrote:
>
> There is an existing set of arbitrary numbers that Linux passes,
> but it's an undocumented mess that sort of corresponds to
> server/classic
> exception vectors but not really.
>
> FIXME: Replace the existing trap numbering rather than add to it.
While this is a good idea, the problem is that we do have quite a few
things here or there that check regs->trap and act based on the trap
number, so we'd have to find them all and replace those comparison with
something symbolic.
Cheers,
Ben.
^ permalink raw reply
* RE: [PATCH v4 1/3] KVM: PPC: epapr: Factor out the epapr init
From: Liu Yu-B13201 @ 2012-02-17 10:03 UTC (permalink / raw)
To: Wood Scott-B07421
Cc: linuxppc-dev@ozlabs.org, agraf@suse.de, kvm-ppc@vger.kernel.org,
kvm@vger.kernel.org
In-Reply-To: <4F3D3933.3020501@freescale.com>
DQoNCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogV29vZCBTY290dC1CMDc0
MjENCj4gU2VudDogRnJpZGF5LCBGZWJydWFyeSAxNywgMjAxMiAxOjEzIEFNDQo+IFRvOiBMaXUg
WXUtQjEzMjAxDQo+IENjOiBhZ3JhZkBzdXNlLmRlOyBrdm0tcHBjQHZnZXIua2VybmVsLm9yZzsg
a3ZtQHZnZXIua2VybmVsLm9yZzsNCj4gbGludXhwcGMtZGV2QG96bGFicy5vcmc7IFdvb2QgU2Nv
dHQtQjA3NDIxDQo+IFN1YmplY3Q6IFJlOiBbUEFUQ0ggdjQgMS8zXSBLVk06IFBQQzogZXBhcHI6
IEZhY3RvciBvdXQgdGhlIGVwYXByIGluaXQNCj4gDQo+IE9uIDAyLzE2LzIwMTIgMDM6MjYgQU0s
IExpdSBZdSB3cm90ZToNCj4gPiBmcm9tIHRoZSBrdm0gZ3Vlc3QgcGFyYXZpcnQgaW5pdCBjb2Rl
Lg0KPiA+DQo+ID4gU2lnbmVkLW9mZi1ieTogTGl1IFl1IDx5dS5saXVAZnJlZXNjYWxlLmNvbT4N
Cj4gPiAtLS0NCj4gPiB2NDoNCj4gPiAxLiBjb2RlIGNsZWFudXANCj4gPiAyLiBtb3ZlIGt2bV9o
eXBlcmNhbGxfc3RhcnQoKSB0byBlcGFwcl9oeXBlcmNhbGxfc3RhcnQoKQ0KPiA+DQo+ID4gIGFy
Y2gvcG93ZXJwYy9LY29uZmlnICAgICAgICAgICAgICAgICAgICB8ICAgIDQgKysNCj4gPiAgYXJj
aC9wb3dlcnBjL2luY2x1ZGUvYXNtL2VwYXByX2hjYWxscy5oIHwgICAgMiArDQo+ID4gIGFyY2gv
cG93ZXJwYy9rZXJuZWwvTWFrZWZpbGUgICAgICAgICAgICB8ICAgIDEgKw0KPiA+ICBhcmNoL3Bv
d2VycGMva2VybmVsL2VwYXByLlMgICAgICAgICAgICAgfCAgIDI1ICsrKysrKysrKysrKysrKysN
Cj4gPiAgYXJjaC9wb3dlcnBjL2tlcm5lbC9lcGFwcl9wYXJhLmMgICAgICAgIHwgICA0OQ0KPiAr
KysrKysrKysrKysrKysrKysrKysrKysrKysrKysrDQo+ID4gIGFyY2gvcG93ZXJwYy9rZXJuZWwv
a3ZtLmMgICAgICAgICAgICAgICB8ICAgMjggKystLS0tLS0tLS0tLS0tLS0tDQo+ID4gIGFyY2gv
cG93ZXJwYy9rZXJuZWwva3ZtX2VtdWwuUyAgICAgICAgICB8ICAgMTAgLS0tLS0tDQo+ID4gIGFy
Y2gvcG93ZXJwYy9rdm0vS2NvbmZpZyAgICAgICAgICAgICAgICB8ICAgIDEgKw0KPiA+ICA4IGZp
bGVzIGNoYW5nZWQsIDg1IGluc2VydGlvbnMoKyksIDM1IGRlbGV0aW9ucygtKSAgY3JlYXRlIG1v
ZGUNCj4gPiAxMDA2NDQgYXJjaC9wb3dlcnBjL2tlcm5lbC9lcGFwci5TICBjcmVhdGUgbW9kZSAx
MDA2NDQNCj4gPiBhcmNoL3Bvd2VycGMva2VybmVsL2VwYXByX3BhcmEuYw0KPiANCj4gVGhlIGNv
bW1lbnQgYWJvdXQgc3BlbGxpbmcgb3V0ICJwYXJhdmlydCIgd2Fzbm4ndCBtZWFudCB0byBiZSBy
ZXN0cmljdGVkDQo+IHRvIHRoZSBrY29uZmlnIHN5bWJvbC4gIFRoZXJlIGFyZSBsb3RzIG9mIHdv
cmRzIHRoYXQgYmVnaW4gd2l0aCAicGFyYSIsDQo+IGFuZCBlUEFQUiBpc24ndCBqdXN0IGFib3V0
IHZpcnR1YWxpemF0aW9uLg0KDQpXaGF0IGRvIHlvdSBtZWFuPyBEbyB5b3Ugc3VnZ2VzdCB0aGF0
IHdlIHNob3VsZCBuYW1lIGl0IGVwYXByX3BhcmF2aXJ0LmM/DQoNClRoYW5rcywNCll1DQo=
^ permalink raw reply
* RE: [linuxppc-release] [PATCH 1/2] powerpc: document the FSL MPIC message register binding
From: Yoder Stuart-B08248 @ 2012-02-17 15:50 UTC (permalink / raw)
To: Jia Hongtao-B38951, linuxppc-dev@lists.ozlabs.org
Cc: meador_inge@mentor.com, Li Yang-R58472
In-Reply-To: <1329446943-9732-1-git-send-email-B38951@freescale.com>
> -----Original Message-----
> From: linuxppc-release-bounces@linux.freescale.net [mailto:linuxppc-relea=
se-
> bounces@linux.freescale.net] On Behalf Of Jia Hongtao-B38951
> Sent: Thursday, February 16, 2012 8:49 PM
> To: linuxppc-dev@lists.ozlabs.org
> Cc: meador_inge@mentor.com; Li Yang-R58472; Jia Hongtao-B38951
> Subject: [linuxppc-release] [PATCH 1/2] powerpc: document the FSL MPIC me=
ssage register
> binding
>=20
> This binding documents how the message register blocks found in some FSL =
MPIC implementations
> shall be represented in a device tree.
>=20
> Signed-off-by: Meador Inge <meador_inge@mentor.com>
> Signed-off-by: Jia Hongtao <B38951@freescale.com>
> Signed-off-by: Li Yang <leoli@freescale.com>
> ---
> .../devicetree/bindings/powerpc/fsl/mpic-msgr.txt | 62 ++++++++++++++=
++++++
> 1 files changed, 62 insertions(+), 0 deletions(-) create mode 100644
> Documentation/devicetree/bindings/powerpc/fsl/mpic-msgr.txt
>=20
> diff --git a/Documentation/devicetree/bindings/powerpc/fsl/mpic-msgr.txt
> b/Documentation/devicetree/bindings/powerpc/fsl/mpic-msgr.txt
> new file mode 100644
> index 0000000..b4ae70e
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/powerpc/fsl/mpic-msgr.txt
> @@ -0,0 +1,62 @@
> +* FSL MPIC Message Registers
> +
> +This binding specifies what properties must be available in the device
> +tree representation of the message register blocks found in some FSL
> +MPIC implementations.
> +
> +Required properties:
> +
> + - compatible: Specifies the compatibility list for the message regis=
ter
> + block. The type shall be <string> and the value shall be of the f=
orm
> + "fsl,mpic-v<version>-msgr", where <version> is the version number =
of
> + the MPIC containing the message registers.
The type for compatibles is a <string-list>.
> + - reg: Specifies the base physical address(s) and size(s) of the
> + message register block's addressable register space. The type sha=
ll be
> + <prop-encoded-array>.
> +
> + - interrupts: Specifies a list of interrupt source and level-sense p=
airs.
> + The type shall be <prop-encoded-array>. The length shall be equal=
to
> + the number of registers that are available for receiving interrupt=
s.
How many interrupts are there? If more than 1, this is where
you need to specify what each interrupt is for.
> +Optional properties:
> +
> + - mpic-msgr-receive-mask: Specifies what registers in the containing=
block
> + are allowed to receive interrupts. The value is a bit mask where =
a set
> + bit at bit 'n' indicates that message register 'n' can receive int=
errupts.
> + The type shall be <prop-encoded-array>. If not present, then all =
of
> + the message registers in the block are available.
Your example implies that this is 1 32-bit cell. If that is the case then
this really should be of type '<u32>'.
^ permalink raw reply
* [PATCH] params: Fix parse_args() use in PowerPC's reserve_hugetlb_gpages()
From: Pawel Moll @ 2012-02-17 16:08 UTC (permalink / raw)
To: Rusty Russell
Cc: Stephen Rothwell, Michael Neuling, Pawel Moll, linuxppc-dev,
linux-next, McClintock Matthew-B29882
In-Reply-To: <20120216111513.918494b07a5331eabe3d32ac@canb.auug.org.au>
Commit b8076966e8e1 ("params: <level>_initcall-like kernel parameters")
changed the parse_args() API without fixing all the callers. Done now.
Signed-off-by: Pawel Moll <pawel.moll@arm.com>
---
arch/powerpc/mm/hugetlbpage.c | 3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/arch/powerpc/mm/hugetlbpage.c b/arch/powerpc/mm/hugetlbpage.c
index 57c7465..a3e6287 100644
--- a/arch/powerpc/mm/hugetlbpage.c
+++ b/arch/powerpc/mm/hugetlbpage.c
@@ -310,7 +310,8 @@ void __init reserve_hugetlb_gpages(void)
=09int i;
=20
=09strlcpy(cmdline, boot_command_line, COMMAND_LINE_SIZE);
-=09parse_args("hugetlb gpages", cmdline, NULL, 0, &do_gpage_early_setup);
+=09parse_args("hugetlb gpages", cmdline, NULL, 0, 0, 0,
+=09=09=09&do_gpage_early_setup);
=20
=09/*
=09 * Walk gpage list in reverse, allocating larger page sizes first.
--=20
1.7.5.4
^ permalink raw reply related
* Re: [PATCH 1/2] powerpc/85xx: fix problem that prevents PHYS_64BIT from configurable
From: Tabi Timur-B04825 @ 2012-02-17 16:22 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-dev@ozlabs.org, Li Yang-R58472
In-Reply-To: <EDB74FED-002D-4F94-B134-995BFB4C0A6B@kernel.crashing.org>
On Thu, Feb 16, 2012 at 7:27 PM, Kumar Gala <galak@kernel.crashing.org> wro=
te:
> For some of these platforms like P2041RDB, P3041DS, P3060QDS, P4080DS, & =
P5020DS only a 36-bit physical address map is supported by u-boot and the d=
evice tree. =A0This was a decision that was made to NOT support 32-bit addr=
ess map for these boards and accept the performance implication of it to re=
duce the # of builds, etc.
Was this a Freescale internal decision, or is this a generic 85xx decision?
For the record, I'm in favor in leaving out support for 32-bit address
map in the upstream kernel, and having it be an option on the SDK
only. However, in order to do that, we cannot have "select
PHYS_64BIT" in the Kconfigs. It needs to be in the defconfigs
instead. Putting it in the defconfig will eliminate the need to have
it in every Kconfig block, so I think that's an improvement.
Then the SDK can include a defconfig that does not have PHYS_64BIT
defined. And the SDK can include 32-bit U-Boots and 32-bit device
trees for any board where Freescale determines there is a need.
I think Leo's patch simplifies things for everyone.
--=20
Timur Tabi
Linux kernel developer at Freescale=
^ permalink raw reply
* [PATCH 06/30] KVM: PPC: e500: rename e500_tlb.h to e500.h
From: Alexander Graf @ 2012-02-17 16:56 UTC (permalink / raw)
To: kvm-ppc; +Cc: Scott Wood, linuxppc-dev, list
In-Reply-To: <1329497818-9729-1-git-send-email-agraf@suse.de>
From: Scott Wood <scottwood@freescale.com>
This is in preparation for merging in the contents of
arch/powerpc/include/asm/kvm_e500.h.
Signed-off-by: Scott Wood <scottwood@freescale.com>
Signed-off-by: Alexander Graf <agraf@suse.de>
---
arch/powerpc/kvm/e500.c | 2 +-
arch/powerpc/kvm/{e500_tlb.h => e500.h} | 6 +++---
arch/powerpc/kvm/e500_emulate.c | 2 +-
arch/powerpc/kvm/e500_tlb.c | 2 +-
4 files changed, 6 insertions(+), 6 deletions(-)
rename arch/powerpc/kvm/{e500_tlb.h => e500.h} (98%)
diff --git a/arch/powerpc/kvm/e500.c b/arch/powerpc/kvm/e500.c
index ac6c9ae..5c450ba 100644
--- a/arch/powerpc/kvm/e500.c
+++ b/arch/powerpc/kvm/e500.c
@@ -24,7 +24,7 @@
#include <asm/kvm_ppc.h>
#include "booke.h"
-#include "e500_tlb.h"
+#include "e500.h"
void kvmppc_core_load_host_debugstate(struct kvm_vcpu *vcpu)
{
diff --git a/arch/powerpc/kvm/e500_tlb.h b/arch/powerpc/kvm/e500.h
similarity index 98%
rename from arch/powerpc/kvm/e500_tlb.h
rename to arch/powerpc/kvm/e500.h
index 5c6d2d7..02ecde2 100644
--- a/arch/powerpc/kvm/e500_tlb.h
+++ b/arch/powerpc/kvm/e500.h
@@ -12,8 +12,8 @@
* published by the Free Software Foundation.
*/
-#ifndef __KVM_E500_TLB_H__
-#define __KVM_E500_TLB_H__
+#ifndef KVM_E500_H
+#define KVM_E500_H
#include <linux/kvm_host.h>
#include <asm/mmu-book3e.h>
@@ -171,4 +171,4 @@ static inline int tlbe_is_host_safe(const struct kvm_vcpu *vcpu,
return 1;
}
-#endif /* __KVM_E500_TLB_H__ */
+#endif /* KVM_E500_H */
diff --git a/arch/powerpc/kvm/e500_emulate.c b/arch/powerpc/kvm/e500_emulate.c
index 6d0b2bd..2a1a228 100644
--- a/arch/powerpc/kvm/e500_emulate.c
+++ b/arch/powerpc/kvm/e500_emulate.c
@@ -17,7 +17,7 @@
#include <asm/kvm_e500.h>
#include "booke.h"
-#include "e500_tlb.h"
+#include "e500.h"
#define XOP_TLBIVAX 786
#define XOP_TLBSX 914
diff --git a/arch/powerpc/kvm/e500_tlb.c b/arch/powerpc/kvm/e500_tlb.c
index 6e53e41..1d623a0 100644
--- a/arch/powerpc/kvm/e500_tlb.c
+++ b/arch/powerpc/kvm/e500_tlb.c
@@ -29,7 +29,7 @@
#include <asm/kvm_e500.h>
#include "../mm/mmu_decl.h"
-#include "e500_tlb.h"
+#include "e500.h"
#include "trace.h"
#include "timing.h"
--
1.6.0.2
^ permalink raw reply related
* [PATCH 05/30] KVM: PPC: booke: Move vm core init/destroy out of booke.c
From: Alexander Graf @ 2012-02-17 16:56 UTC (permalink / raw)
To: kvm-ppc; +Cc: Scott Wood, linuxppc-dev, list
In-Reply-To: <1329497818-9729-1-git-send-email-agraf@suse.de>
From: Scott Wood <scottwood@freescale.com>
e500mc will want to do lpid allocation/deallocation here.
Signed-off-by: Scott Wood <scottwood@freescale.com>
Signed-off-by: Alexander Graf <agraf@suse.de>
---
arch/powerpc/kvm/44x.c | 9 +++++++++
arch/powerpc/kvm/booke.c | 9 ---------
arch/powerpc/kvm/e500.c | 9 +++++++++
3 files changed, 18 insertions(+), 9 deletions(-)
diff --git a/arch/powerpc/kvm/44x.c b/arch/powerpc/kvm/44x.c
index 879a1a7..50e7dbc 100644
--- a/arch/powerpc/kvm/44x.c
+++ b/arch/powerpc/kvm/44x.c
@@ -163,6 +163,15 @@ void kvmppc_core_vcpu_free(struct kvm_vcpu *vcpu)
kmem_cache_free(kvm_vcpu_cache, vcpu_44x);
}
+int kvmppc_core_init_vm(struct kvm *kvm)
+{
+ return 0;
+}
+
+void kvmppc_core_destroy_vm(struct kvm *kvm)
+{
+}
+
static int __init kvmppc_44x_init(void)
{
int r;
diff --git a/arch/powerpc/kvm/booke.c b/arch/powerpc/kvm/booke.c
index a2456c7..2ee9bae 100644
--- a/arch/powerpc/kvm/booke.c
+++ b/arch/powerpc/kvm/booke.c
@@ -932,15 +932,6 @@ void kvmppc_core_commit_memory_region(struct kvm *kvm,
{
}
-int kvmppc_core_init_vm(struct kvm *kvm)
-{
- return 0;
-}
-
-void kvmppc_core_destroy_vm(struct kvm *kvm)
-{
-}
-
void kvmppc_set_tcr(struct kvm_vcpu *vcpu, u32 new_tcr)
{
vcpu->arch.tcr = new_tcr;
diff --git a/arch/powerpc/kvm/e500.c b/arch/powerpc/kvm/e500.c
index 2d5fe04..ac6c9ae 100644
--- a/arch/powerpc/kvm/e500.c
+++ b/arch/powerpc/kvm/e500.c
@@ -226,6 +226,15 @@ void kvmppc_core_vcpu_free(struct kvm_vcpu *vcpu)
kmem_cache_free(kvm_vcpu_cache, vcpu_e500);
}
+int kvmppc_core_init_vm(struct kvm *kvm)
+{
+ return 0;
+}
+
+void kvmppc_core_destroy_vm(struct kvm *kvm)
+{
+}
+
static int __init kvmppc_e500_init(void)
{
int r, i;
--
1.6.0.2
^ permalink raw reply related
* [PATCH 04/30] KVM: PPC: booke: add booke-level vcpu load/put
From: Alexander Graf @ 2012-02-17 16:56 UTC (permalink / raw)
To: kvm-ppc; +Cc: Scott Wood, linuxppc-dev, list
In-Reply-To: <1329497818-9729-1-git-send-email-agraf@suse.de>
From: Scott Wood <scottwood@freescale.com>
This gives us a place to put load/put actions that correspond to
code that is booke-specific but not specific to a particular core.
Signed-off-by: Scott Wood <scottwood@freescale.com>
Signed-off-by: Alexander Graf <agraf@suse.de>
---
arch/powerpc/kvm/44x.c | 3 +++
arch/powerpc/kvm/booke.c | 8 ++++++++
arch/powerpc/kvm/booke.h | 3 +++
arch/powerpc/kvm/e500.c | 3 +++
4 files changed, 17 insertions(+), 0 deletions(-)
diff --git a/arch/powerpc/kvm/44x.c b/arch/powerpc/kvm/44x.c
index 7b612a7..879a1a7 100644
--- a/arch/powerpc/kvm/44x.c
+++ b/arch/powerpc/kvm/44x.c
@@ -29,15 +29,18 @@
#include <asm/kvm_ppc.h>
#include "44x_tlb.h"
+#include "booke.h"
void kvmppc_core_vcpu_load(struct kvm_vcpu *vcpu, int cpu)
{
+ kvmppc_booke_vcpu_load(vcpu, cpu);
kvmppc_44x_tlb_load(vcpu);
}
void kvmppc_core_vcpu_put(struct kvm_vcpu *vcpu)
{
kvmppc_44x_tlb_put(vcpu);
+ kvmppc_booke_vcpu_put(vcpu);
}
int kvmppc_core_check_processor_compat(void)
diff --git a/arch/powerpc/kvm/booke.c b/arch/powerpc/kvm/booke.c
index ee9e1ee..a2456c7 100644
--- a/arch/powerpc/kvm/booke.c
+++ b/arch/powerpc/kvm/booke.c
@@ -968,6 +968,14 @@ void kvmppc_decrementer_func(unsigned long data)
kvmppc_set_tsr_bits(vcpu, TSR_DIS);
}
+void kvmppc_booke_vcpu_load(struct kvm_vcpu *vcpu, int cpu)
+{
+}
+
+void kvmppc_booke_vcpu_put(struct kvm_vcpu *vcpu)
+{
+}
+
int __init kvmppc_booke_init(void)
{
unsigned long ivor[16];
diff --git a/arch/powerpc/kvm/booke.h b/arch/powerpc/kvm/booke.h
index 2fe2027..05d1d99 100644
--- a/arch/powerpc/kvm/booke.h
+++ b/arch/powerpc/kvm/booke.h
@@ -71,4 +71,7 @@ void kvmppc_save_guest_spe(struct kvm_vcpu *vcpu);
/* high-level function, manages flags, host state */
void kvmppc_vcpu_disable_spe(struct kvm_vcpu *vcpu);
+void kvmppc_booke_vcpu_load(struct kvm_vcpu *vcpu, int cpu);
+void kvmppc_booke_vcpu_put(struct kvm_vcpu *vcpu);
+
#endif /* __KVM_BOOKE_H__ */
diff --git a/arch/powerpc/kvm/e500.c b/arch/powerpc/kvm/e500.c
index ddcd896..2d5fe04 100644
--- a/arch/powerpc/kvm/e500.c
+++ b/arch/powerpc/kvm/e500.c
@@ -36,6 +36,7 @@ void kvmppc_core_load_guest_debugstate(struct kvm_vcpu *vcpu)
void kvmppc_core_vcpu_load(struct kvm_vcpu *vcpu, int cpu)
{
+ kvmppc_booke_vcpu_load(vcpu, cpu);
kvmppc_e500_tlb_load(vcpu, cpu);
}
@@ -47,6 +48,8 @@ void kvmppc_core_vcpu_put(struct kvm_vcpu *vcpu)
if (vcpu->arch.shadow_msr & MSR_SPE)
kvmppc_vcpu_disable_spe(vcpu);
#endif
+
+ kvmppc_booke_vcpu_put(vcpu);
}
int kvmppc_core_check_processor_compat(void)
--
1.6.0.2
^ permalink raw reply related
* [PATCH 02/30] powerpc/e500: split CPU_FTRS_ALWAYS/CPU_FTRS_POSSIBLE
From: Alexander Graf @ 2012-02-17 16:56 UTC (permalink / raw)
To: kvm-ppc; +Cc: Scott Wood, linuxppc-dev, list
In-Reply-To: <1329497818-9729-1-git-send-email-agraf@suse.de>
From: Scott Wood <scottwood@freescale.com>
Split e500 (v1/v2) and e500mc/e5500 to allow optimization of feature
checks that differ between the two.
Signed-off-by: Scott Wood <scottwood@freescale.com>
Signed-off-by: Alexander Graf <agraf@suse.de>
---
arch/powerpc/include/asm/cputable.h | 12 ++++++++----
1 files changed, 8 insertions(+), 4 deletions(-)
diff --git a/arch/powerpc/include/asm/cputable.h b/arch/powerpc/include/asm/cputable.h
index 6a034a2..2022f2d 100644
--- a/arch/powerpc/include/asm/cputable.h
+++ b/arch/powerpc/include/asm/cputable.h
@@ -483,8 +483,10 @@ enum {
CPU_FTRS_E200 |
#endif
#ifdef CONFIG_E500
- CPU_FTRS_E500 | CPU_FTRS_E500_2 | CPU_FTRS_E500MC |
- CPU_FTRS_E5500 |
+ CPU_FTRS_E500 | CPU_FTRS_E500_2 |
+#endif
+#ifdef CONFIG_PPC_E500MC
+ CPU_FTRS_E500MC | CPU_FTRS_E5500 |
#endif
0,
};
@@ -528,8 +530,10 @@ enum {
CPU_FTRS_E200 &
#endif
#ifdef CONFIG_E500
- CPU_FTRS_E500 & CPU_FTRS_E500_2 & CPU_FTRS_E500MC &
- CPU_FTRS_E5500 &
+ CPU_FTRS_E500 & CPU_FTRS_E500_2 &
+#endif
+#ifdef CONFIG_PPC_E500MC
+ CPU_FTRS_E500MC & CPU_FTRS_E5500 &
#endif
CPU_FTRS_POSSIBLE,
};
--
1.6.0.2
^ permalink raw reply related
* [PATCH 00/30] KVM: PPC: e500mc support
From: Alexander Graf @ 2012-02-17 16:56 UTC (permalink / raw)
To: kvm-ppc; +Cc: Scott Wood, linuxppc-dev, list
This is Scott's e500mc RFC patch set rebased, berobbed of its pt_regs
parts and fixed for bisectability. On top of them, I addressed all the
comments that I had on the code and that came up in his code as FIXMEs.
I verified that this patch set works just fine on e500mc and doesn't
break e500v2, so I would say it's good to go as it is, unless someone
has strong objections to how things are done. Everything hereafter
I would prefer to do based on a working upstream version rather than
a downstream fork, as that way exposure is a lot higher.
Alex
Alexander Graf (15):
KVM: PPC: e500mc: Add doorbell emulation support
KVM: PPC: e500mc: implicitly set MSR_GS
KVM: PPC: e500mc: Move r1/r2 restoration very early
KVM: PPC: e500mc: add load inst fixup
KVM: PPC: rename CONFIG_KVM_E500 -> CONFIG_KVM_E500V2
KVM: PPC: make e500v2 and e500mc mutually exclusive
KVM: PPC: booke: remove leftover debugging
KVM: PPC: booke: deliver program int on emulation failure
KVM: PPC: booke: call resched after every exit
KVM: PPC: booke: BOOKE_IRQPRIO_MAX is n+1
KVM: PPC: bookehv: fix exit timing
KVM: PPC: bookehv: remove negation for CONFIG_64BIT
KVM: PPC: bookehv: remove SET_VCPU
KVM: PPC: bookehv: disable MAS register updates early
KVM: PPC: bookehv: add comment about shadow_msr
Scott Wood (15):
powerpc/booke: Set CPU_FTR_DEBUG_LVL_EXC on 32-bit
powerpc/e500: split CPU_FTRS_ALWAYS/CPU_FTRS_POSSIBLE
KVM: PPC: factor out lpid allocator from book3s_64_mmu_hv
KVM: PPC: booke: add booke-level vcpu load/put
KVM: PPC: booke: Move vm core init/destroy out of booke.c
KVM: PPC: e500: rename e500_tlb.h to e500.h
KVM: PPC: e500: merge <asm/kvm_e500.h> into arch/powerpc/kvm/e500.h
KVM: PPC: e500: clean up arch/powerpc/kvm/e500.h
KVM: PPC: e500: refactor core-specific TLB code
KVM: PPC: e500: Track TLB1 entries with a bitmap
KVM: PPC: e500: emulate tlbilx
powerpc/booke: Provide exception macros with interrupt name
KVM: PPC: booke: category E.HV (GS-mode) support
KVM: PPC: booke: standard PPC floating point support
KVM: PPC: e500mc support
arch/powerpc/include/asm/cputable.h | 21 +-
arch/powerpc/include/asm/dbell.h | 1 +
arch/powerpc/include/asm/kvm.h | 1 +
arch/powerpc/include/asm/kvm_asm.h | 8 +
arch/powerpc/include/asm/kvm_book3s.h | 3 +
arch/powerpc/include/asm/kvm_booke.h | 3 +
arch/powerpc/include/asm/kvm_booke_hv_asm.h | 49 +++
arch/powerpc/include/asm/kvm_e500.h | 96 -----
arch/powerpc/include/asm/kvm_host.h | 22 +-
arch/powerpc/include/asm/kvm_ppc.h | 8 +
arch/powerpc/include/asm/mmu-book3e.h | 6 +
arch/powerpc/include/asm/processor.h | 3 +
arch/powerpc/include/asm/reg.h | 2 +
arch/powerpc/include/asm/reg_booke.h | 34 ++
arch/powerpc/include/asm/system.h | 1 +
arch/powerpc/kernel/asm-offsets.c | 15 +-
arch/powerpc/kernel/cpu_setup_fsl_booke.S | 1 +
arch/powerpc/kernel/head_44x.S | 23 +-
arch/powerpc/kernel/head_booke.h | 69 ++-
arch/powerpc/kernel/head_fsl_booke.S | 98 ++++-
arch/powerpc/kvm/44x.c | 12 +
arch/powerpc/kvm/Kconfig | 26 +-
arch/powerpc/kvm/Makefile | 15 +-
arch/powerpc/kvm/book3s_64_mmu_hv.c | 26 +-
arch/powerpc/kvm/booke.c | 379 ++++++++++++++---
arch/powerpc/kvm/booke.h | 57 +++-
arch/powerpc/kvm/booke_emulate.c | 23 +-
arch/powerpc/kvm/bookehv_interrupts.S | 609 +++++++++++++++++++++++++++
arch/powerpc/kvm/e500.c | 372 ++++++++++++++---
arch/powerpc/kvm/e500.h | 302 +++++++++++++
arch/powerpc/kvm/e500_emulate.c | 110 +++++-
arch/powerpc/kvm/e500_tlb.c | 588 +++++++++++---------------
arch/powerpc/kvm/e500_tlb.h | 174 --------
arch/powerpc/kvm/e500mc.c | 342 +++++++++++++++
arch/powerpc/kvm/powerpc.c | 47 ++-
arch/powerpc/kvm/timing.h | 6 +
36 files changed, 2717 insertions(+), 835 deletions(-)
create mode 100644 arch/powerpc/include/asm/kvm_booke_hv_asm.h
delete mode 100644 arch/powerpc/include/asm/kvm_e500.h
create mode 100644 arch/powerpc/kvm/bookehv_interrupts.S
create mode 100644 arch/powerpc/kvm/e500.h
delete mode 100644 arch/powerpc/kvm/e500_tlb.h
create mode 100644 arch/powerpc/kvm/e500mc.c
^ 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