* 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
* [PATCH 08/30] KVM: PPC: e500: clean up arch/powerpc/kvm/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>
Move vcpu to the beginning of vcpu_e500 to give it appropriate
prominence, especially if more fields end up getting added to the
end of vcpu_e500 (and vcpu ends up in the middle).
Remove gratuitous "extern" and add parameter names to prototypes.
Signed-off-by: Scott Wood <scottwood@freescale.com>
[agraf: fix bisectability]
Signed-off-by: Alexander Graf <agraf@suse.de>
---
arch/powerpc/kvm/e500.h | 25 ++++++++++++++-----------
1 files changed, 14 insertions(+), 11 deletions(-)
diff --git a/arch/powerpc/kvm/e500.h b/arch/powerpc/kvm/e500.h
index 51d13bd..a48af00 100644
--- a/arch/powerpc/kvm/e500.h
+++ b/arch/powerpc/kvm/e500.h
@@ -42,6 +42,8 @@ struct kvmppc_e500_tlb_params {
};
struct kvmppc_vcpu_e500 {
+ struct kvm_vcpu vcpu;
+
/* Unmodified copy of the guest's TLB -- shared with host userspace. */
struct kvm_book3e_206_tlb_entry *gtlb_arch;
@@ -85,8 +87,6 @@ struct kvmppc_vcpu_e500 {
struct page **shared_tlb_pages;
int num_shared_tlb_pages;
-
- struct kvm_vcpu vcpu;
};
static inline struct kvmppc_vcpu_e500 *to_e500(struct kvm_vcpu *vcpu)
@@ -113,19 +113,22 @@ static inline struct kvmppc_vcpu_e500 *to_e500(struct kvm_vcpu *vcpu)
(MAS3_U0 | MAS3_U1 | MAS3_U2 | MAS3_U3 \
| E500_TLB_USER_PERM_MASK | E500_TLB_SUPER_PERM_MASK)
-extern void kvmppc_dump_tlbs(struct kvm_vcpu *);
-extern int kvmppc_e500_emul_mt_mmucsr0(struct kvmppc_vcpu_e500 *, ulong);
-extern int kvmppc_e500_emul_tlbwe(struct kvm_vcpu *);
-extern int kvmppc_e500_emul_tlbre(struct kvm_vcpu *);
-extern int kvmppc_e500_emul_tlbivax(struct kvm_vcpu *, int, int);
-extern int kvmppc_e500_emul_tlbsx(struct kvm_vcpu *, int);
-extern int kvmppc_e500_tlb_search(struct kvm_vcpu *, gva_t, unsigned int, int);
extern void kvmppc_e500_tlb_put(struct kvm_vcpu *);
extern void kvmppc_e500_tlb_load(struct kvm_vcpu *, int);
-extern int kvmppc_e500_tlb_init(struct kvmppc_vcpu_e500 *);
-extern void kvmppc_e500_tlb_uninit(struct kvmppc_vcpu_e500 *);
extern void kvmppc_e500_tlb_setup(struct kvmppc_vcpu_e500 *);
extern void kvmppc_e500_recalc_shadow_pid(struct kvmppc_vcpu_e500 *);
+int kvmppc_e500_emul_mt_mmucsr0(struct kvmppc_vcpu_e500 *vcpu_e500,
+ ulong value);
+int kvmppc_e500_emul_tlbwe(struct kvm_vcpu *vcpu);
+int kvmppc_e500_emul_tlbre(struct kvm_vcpu *vcpu);
+int kvmppc_e500_emul_tlbivax(struct kvm_vcpu *vcpu, int ra, int rb);
+int kvmppc_e500_emul_tlbsx(struct kvm_vcpu *vcpu, int rb);
+int kvmppc_e500_tlb_search(struct kvm_vcpu *, gva_t, unsigned int, int);
+int kvmppc_e500_tlb_init(struct kvmppc_vcpu_e500 *vcpu_e500);
+void kvmppc_e500_tlb_uninit(struct kvmppc_vcpu_e500 *vcpu_e500);
+
+void kvmppc_get_sregs_e500_tlb(struct kvm_vcpu *vcpu, struct kvm_sregs *sregs);
+int kvmppc_set_sregs_e500_tlb(struct kvm_vcpu *vcpu, struct kvm_sregs *sregs);
/* TLB helper functions */
static inline unsigned int
--
1.6.0.2
^ permalink raw reply related
* [PATCH 01/30] powerpc/booke: Set CPU_FTR_DEBUG_LVL_EXC on 32-bit
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>
Currently 32-bit only cares about this for choice of exception
vector, which is done in core-specific code. However, KVM will
want to distinguish as well.
Signed-off-by: Scott Wood <scottwood@freescale.com>
Signed-off-by: Alexander Graf <agraf@suse.de>
---
arch/powerpc/include/asm/cputable.h | 5 +++--
1 files changed, 3 insertions(+), 2 deletions(-)
diff --git a/arch/powerpc/include/asm/cputable.h b/arch/powerpc/include/asm/cputable.h
index ad55a1c..6a034a2 100644
--- a/arch/powerpc/include/asm/cputable.h
+++ b/arch/powerpc/include/asm/cputable.h
@@ -376,7 +376,8 @@ extern const char *powerpc_base_platform;
#define CPU_FTRS_47X (CPU_FTRS_440x6)
#define CPU_FTRS_E200 (CPU_FTR_USE_TB | CPU_FTR_SPE_COMP | \
CPU_FTR_NODSISRALIGN | CPU_FTR_COHERENT_ICACHE | \
- CPU_FTR_UNIFIED_ID_CACHE | CPU_FTR_NOEXECUTE)
+ CPU_FTR_UNIFIED_ID_CACHE | CPU_FTR_NOEXECUTE | \
+ CPU_FTR_DEBUG_LVL_EXC)
#define CPU_FTRS_E500 (CPU_FTR_MAYBE_CAN_DOZE | CPU_FTR_USE_TB | \
CPU_FTR_SPE_COMP | CPU_FTR_MAYBE_CAN_NAP | CPU_FTR_NODSISRALIGN | \
CPU_FTR_NOEXECUTE)
@@ -385,7 +386,7 @@ extern const char *powerpc_base_platform;
CPU_FTR_NODSISRALIGN | CPU_FTR_NOEXECUTE)
#define CPU_FTRS_E500MC (CPU_FTR_USE_TB | CPU_FTR_NODSISRALIGN | \
CPU_FTR_L2CSR | CPU_FTR_LWSYNC | CPU_FTR_NOEXECUTE | \
- CPU_FTR_DBELL)
+ CPU_FTR_DBELL | CPU_FTR_DEBUG_LVL_EXC)
#define CPU_FTRS_E5500 (CPU_FTR_USE_TB | CPU_FTR_NODSISRALIGN | \
CPU_FTR_L2CSR | CPU_FTR_LWSYNC | CPU_FTR_NOEXECUTE | \
CPU_FTR_DBELL | CPU_FTR_POPCNTB | CPU_FTR_POPCNTD | \
--
1.6.0.2
^ permalink raw reply related
* [PATCH 14/30] KVM: PPC: booke: standard PPC floating point support
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 has a normal PPC FPU, rather than SPE which is found
on e500v1/v2.
Based on code from Liu Yu <yu.liu@freescale.com>.
Signed-off-by: Scott Wood <scottwood@freescale.com>
Signed-off-by: Alexander Graf <agraf@suse.de>
---
arch/powerpc/include/asm/system.h | 1 +
arch/powerpc/kvm/booke.c | 44 +++++++++++++++++++++++++++++++++++++
arch/powerpc/kvm/booke.h | 30 +++++++++++++++++++++++++
3 files changed, 75 insertions(+), 0 deletions(-)
diff --git a/arch/powerpc/include/asm/system.h b/arch/powerpc/include/asm/system.h
index c377457..73eee86 100644
--- a/arch/powerpc/include/asm/system.h
+++ b/arch/powerpc/include/asm/system.h
@@ -140,6 +140,7 @@ extern void via_cuda_init(void);
extern void read_rtc_time(void);
extern void pmac_find_display(void);
extern void giveup_fpu(struct task_struct *);
+extern void load_up_fpu(void);
extern void disable_kernel_fp(void);
extern void enable_kernel_fp(void);
extern void flush_fp_to_thread(struct task_struct *);
diff --git a/arch/powerpc/kvm/booke.c b/arch/powerpc/kvm/booke.c
index af9561e..3dd200d 100644
--- a/arch/powerpc/kvm/booke.c
+++ b/arch/powerpc/kvm/booke.c
@@ -457,6 +457,11 @@ void kvmppc_core_prepare_to_enter(struct kvm_vcpu *vcpu)
int kvmppc_vcpu_run(struct kvm_run *kvm_run, struct kvm_vcpu *vcpu)
{
int ret;
+#ifdef CONFIG_PPC_FPU
+ unsigned int fpscr;
+ int fpexc_mode;
+ u64 fpr[32];
+#endif
if (!vcpu->arch.sane) {
kvm_run->exit_reason = KVM_EXIT_INTERNAL_ERROR;
@@ -479,7 +484,46 @@ int kvmppc_vcpu_run(struct kvm_run *kvm_run, struct kvm_vcpu *vcpu)
}
kvm_guest_enter();
+
+#ifdef CONFIG_PPC_FPU
+ /* Save userspace FPU state in stack */
+ enable_kernel_fp();
+ memcpy(fpr, current->thread.fpr, sizeof(current->thread.fpr));
+ fpscr = current->thread.fpscr.val;
+ fpexc_mode = current->thread.fpexc_mode;
+
+ /* Restore guest FPU state to thread */
+ memcpy(current->thread.fpr, vcpu->arch.fpr, sizeof(vcpu->arch.fpr));
+ current->thread.fpscr.val = vcpu->arch.fpscr;
+
+ /*
+ * Since we can't trap on MSR_FP in GS-mode, we consider the guest
+ * as always using the FPU. Kernel usage of FP (via
+ * enable_kernel_fp()) in this thread must not occur while
+ * vcpu->fpu_active is set.
+ */
+ vcpu->fpu_active = 1;
+
+ kvmppc_load_guest_fp(vcpu);
+#endif
+
ret = __kvmppc_vcpu_run(kvm_run, vcpu);
+
+#ifdef CONFIG_PPC_FPU
+ kvmppc_save_guest_fp(vcpu);
+
+ vcpu->fpu_active = 0;
+
+ /* Save guest FPU state from thread */
+ memcpy(vcpu->arch.fpr, current->thread.fpr, sizeof(vcpu->arch.fpr));
+ vcpu->arch.fpscr = current->thread.fpscr.val;
+
+ /* Restore userspace FPU state from stack */
+ memcpy(current->thread.fpr, fpr, sizeof(current->thread.fpr));
+ current->thread.fpscr.val = fpscr;
+ current->thread.fpexc_mode = fpexc_mode;
+#endif
+
kvm_guest_exit();
out:
diff --git a/arch/powerpc/kvm/booke.h b/arch/powerpc/kvm/booke.h
index d53bcf2..3bf5eda 100644
--- a/arch/powerpc/kvm/booke.h
+++ b/arch/powerpc/kvm/booke.h
@@ -96,4 +96,34 @@ enum int_class {
void kvmppc_set_pending_interrupt(struct kvm_vcpu *vcpu, enum int_class type);
+/*
+ * Load up guest vcpu FP state if it's needed.
+ * It also set the MSR_FP in thread so that host know
+ * we're holding FPU, and then host can help to save
+ * guest vcpu FP state if other threads require to use FPU.
+ * This simulates an FP unavailable fault.
+ *
+ * It requires to be called with preemption disabled.
+ */
+static inline void kvmppc_load_guest_fp(struct kvm_vcpu *vcpu)
+{
+#ifdef CONFIG_PPC_FPU
+ if (vcpu->fpu_active && !(current->thread.regs->msr & MSR_FP)) {
+ load_up_fpu();
+ current->thread.regs->msr |= MSR_FP;
+ }
+#endif
+}
+
+/*
+ * Save guest vcpu FP state into thread.
+ * It requires to be called with preemption disabled.
+ */
+static inline void kvmppc_save_guest_fp(struct kvm_vcpu *vcpu)
+{
+#ifdef CONFIG_PPC_FPU
+ if (vcpu->fpu_active && (current->thread.regs->msr & MSR_FP))
+ giveup_fpu(current);
+#endif
+}
#endif /* __KVM_BOOKE_H__ */
--
1.6.0.2
^ permalink raw reply related
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