* Re: [PATCH 11/39] powerpc: endian safe trampoline
From: Olof Johansson @ 2013-12-28 7:24 UTC (permalink / raw)
To: Anton Blanchard; +Cc: Paul Mackerras, linuxppc-dev, chzigotzky
In-Reply-To: <1379901913-5945-12-git-send-email-anton@samba.org>
Nothing like some holiday powerpc early boot debugging. :-)
On Sun, Sep 22, 2013 at 7:04 PM, Anton Blanchard <anton@samba.org> wrote:
> From: Benjamin Herrenschmidt <benh@kernel.crashing.org>
>
> Create a trampoline that works in either endian and flips to
> the expected endian. Use it for primary and secondary thread
> entry as well as RTAS and OF call return.
>
> Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
> Signed-off-by: Anton Blanchard <anton@samba.org>
Some users reported failure with their kernel config to build and run
3.13-rc5. pasemi_defconfig boots just fine, but it seems that
ppc64_defconfig does not.
I've bisected it down to this particular patch. More below.
> diff --git a/arch/powerpc/include/asm/ppc_asm.h b/arch/powerpc/include/asm/ppc_asm.h
> index 0c51fb4..ce05bba 100644
> --- a/arch/powerpc/include/asm/ppc_asm.h
> +++ b/arch/powerpc/include/asm/ppc_asm.h
> @@ -845,6 +845,35 @@ END_FTR_SECTION_NESTED(CPU_FTR_HAS_PPR,CPU_FTR_HAS_PPR,946)
> #define N_SLINE 68
> #define N_SO 100
>
> -#endif /* __ASSEMBLY__ */
> +/*
> + * Create an endian fixup trampoline
> + *
> + * This starts with a "tdi 0,0,0x48" instruction which is
> + * essentially a "trap never", and thus akin to a nop.
> + *
> + * The opcode for this instruction read with the wrong endian
> + * however results in a b . + 8
> + *
> + * So essentially we use that trick to execute the following
> + * trampoline in "reverse endian" if we are running with the
> + * MSR_LE bit set the "wrong" way for whatever endianness the
> + * kernel is built for.
> + */
>
> +#ifdef CONFIG_PPC_BOOK3E
> +#define FIXUP_ENDIAN
> +#else
> +#define FIXUP_ENDIAN \
> + tdi 0,0,0x48; /* Reverse endian of b . + 8 */ \
> + b $+36; /* Skip trampoline if endian is good */ \
> + .long 0x05009f42; /* bcl 20,31,$+4 */ \
> + .long 0xa602487d; /* mflr r10 */ \
> + .long 0x1c004a39; /* addi r10,r10,28 */ \
> + .long 0xa600607d; /* mfmsr r11 */ \
> + .long 0x01006b69; /* xori r11,r11,1 */ \
> + .long 0xa6035a7d; /* mtsrr0 r10 */ \
> + .long 0xa6037b7d; /* mtsrr1 r11 */ \
> + .long 0x2400004c /* rfid */
So, the combination of this sequence and its execution at __start
seems to be what's causing problems for me. I've both commented out
and nopped out the second instruction and the handcoded LE opcodes,
and it makes no difference -- it seems to be the execution of the tdi
that traps or causes some other problem. And yeah -- it definitely
shouldn't since TO is 0. Likewise if I replace the tdi with nop and
keep the rest it runs fine.
I'm a bit baffled that there's a difference based on what config is
booted. I'm booting a raw vmlinux from a BE firmware. Initial code
sequence is largely the same for both configs.
Unfortunately I no longer have a JTAG environment such that I can
check the value of r0 at the time of tdi execution. Still, based on
docs it shouldn't matter since there are no TO bits set. I don't see a
rational reason to why the above should fail. And indeed, if I load a
known-different value and set TO=4, I still see failures. Etc.
I also tried moving the FIXUP_ENDIAN call until after the branch to
__start_initialization_multiplatform but before 64-bit enable and
there it runs just fine.
So, I'm really quite baffled right now. Any ideas would be welcome,
I'm sort of stumped. In particular since pasemi_defconfig boots fine.
-Olof
^ permalink raw reply
* Re: [PATCH 11/39] powerpc: endian safe trampoline
From: Benjamin Herrenschmidt @ 2013-12-28 7:58 UTC (permalink / raw)
To: Olof Johansson; +Cc: linuxppc-dev, Paul Mackerras, Anton Blanchard, chzigotzky
In-Reply-To: <CAOesGMgKjAe5VR9waKCboK+mRwVfde89x+6gew9wjiCf8mAd8A@mail.gmail.com>
On Fri, 2013-12-27 at 23:24 -0800, Olof Johansson wrote:
>
> So, I'm really quite baffled right now. Any ideas would be welcome,
> I'm sort of stumped. In particular since pasemi_defconfig boots fine.
So you are coming in with "good" endian... what if you stick an
isync in there just for fun ? I wonder if it prefetches the "bad"
instructions and somewhat gets itself confused.
Also did you try sticking a b . around 0x700 see if that's where it's
going and what condition gets set ?
Cheers,
Ben.
^ permalink raw reply
* Please pull 'merge' branch of 5xxx tree
From: Anatolij Gustschin @ 2013-12-28 12:05 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: linuxppc-dev list
Hi Ben !
Please pull two DTS fixes for MPC5125 tower board. Without
them the v3.13-rcX kernels do not boot.
Thanks,
Anatolij
The following changes since commit 803c2d2f84da9dc2619449994af34d27148ab20d:
powerpc/powernv: Fix OPAL LPC access in Little Endian (2013-12-13 15:55:15 +1100)
are available in the git repository at:
git://git.denx.de/linux-2.6-agust.git merge
for you to fetch changes up to 11daf32be9a6041a2406c2cbf76b75a9c4a6eaaa:
powerpc/512x: dts: disable MPC5125 usb module (2013-12-20 22:12:07 +0100)
----------------------------------------------------------------
Gerhard Sittig (1):
powerpc/512x: dts: remove misplaced IRQ spec from 'soc' node (5125)
Matteo Facchinetti (1):
powerpc/512x: dts: disable MPC5125 usb module
arch/powerpc/boot/dts/mpc5125twr.dts | 6 +++++-
1 file changed, 5 insertions(+), 1 deletion(-)
^ permalink raw reply
* [PATCH] powerpc: Fix alignment of secondary cpu spin vars
From: Olof Johansson @ 2013-12-28 21:01 UTC (permalink / raw)
To: benh; +Cc: Olof Johansson, linuxppc-dev, linux-kernel, anton
Commit 5c0484e25ec0 ('powerpc: Endian safe trampoline') resulted in
losing proper alignment of the spinlock variables used when booting
secondary CPUs, causing some quite odd issues with failing to boot on
PA Semi-based systems.
This showed itself on ppc64_defconfig, but not on pasemi_defconfig,
so it had gone unnoticed when I initially tested the LE patch set.
Fix is to add explicit alignment instead of relying on good luck. :)
Fixes: 5c0484e25ec0 ('powerpc: Endian safe trampoline')
Reported-by: Christian Zigotzky <chzigotzky@xenosoft.de>
Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=67811
Signed-off-by: Olof Johansson <olof@lixom.net>
---
arch/powerpc/kernel/head_64.S | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/powerpc/kernel/head_64.S b/arch/powerpc/kernel/head_64.S
index 2ae41ab..4d94477 100644
--- a/arch/powerpc/kernel/head_64.S
+++ b/arch/powerpc/kernel/head_64.S
@@ -80,6 +80,7 @@ END_FTR_SECTION(0, 1)
* of the function that the cpu should jump to to continue
* initialization.
*/
+ .balign 8
.globl __secondary_hold_spinloop
__secondary_hold_spinloop:
.llong 0x0
--
1.7.10.4
^ permalink raw reply related
* Re: [PATCH] powerpc: Fix alignment of secondary cpu spin vars
From: Olof Johansson @ 2013-12-28 21:05 UTC (permalink / raw)
To: Benjamin Herrenschmidt
Cc: Olof Johansson, linuxppc-dev, linux-kernel@vger.kernel.org,
Anton Blanchard
In-Reply-To: <1388264507-5100-1-git-send-email-olof@lixom.net>
On Sat, Dec 28, 2013 at 1:01 PM, Olof Johansson <olof@lixom.net> wrote:
> Commit 5c0484e25ec0 ('powerpc: Endian safe trampoline') resulted in
> losing proper alignment of the spinlock variables used when booting
> secondary CPUs, causing some quite odd issues with failing to boot on
> PA Semi-based systems.
>
> This showed itself on ppc64_defconfig, but not on pasemi_defconfig,
> so it had gone unnoticed when I initially tested the LE patch set.
>
> Fix is to add explicit alignment instead of relying on good luck. :)
>
> Fixes: 5c0484e25ec0 ('powerpc: Endian safe trampoline')
> Reported-by: Christian Zigotzky <chzigotzky@xenosoft.de>
> Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=67811
> Signed-off-by: Olof Johansson <olof@lixom.net>
Sigh, it's not this after all. I did a clean build with this applied
and still see failures. Something else is (also?) going on here.
-Olof
^ permalink raw reply
* Re: [PATCH 19/25] fix error return code
From: Geert Uytterhoeven @ 2013-12-29 21:58 UTC (permalink / raw)
To: Julia Lawall
Cc: cbe-oss-dev@lists.ozlabs.org, scsi, Geoff Levand,
kernel-janitors@vger.kernel.org, linux-kernel@vger.kernel.org,
James E.J. Bottomley, linuxppc-dev@lists.ozlabs.org
In-Reply-To: <1388357260-4843-20-git-send-email-Julia.Lawall@lip6.fr>
On Sun, Dec 29, 2013 at 11:47 PM, Julia Lawall <Julia.Lawall@lip6.fr> wrote:
> From: Julia Lawall <Julia.Lawall@lip6.fr>
>
> Set the return variable to an error code as done elsewhere in the function.
>
> A simplified version of the semantic match that finds this problem is as
> follows: (http://coccinelle.lip6.fr/)
>
> // <smpl>
> (
> if@p1 (\(ret < 0\|ret != 0\))
> { ... return ret; }
> |
> ret@p1 = 0
> )
> ... when != ret = e1
> when != &ret
> *if(...)
> {
> ... when != ret = e2
> when forall
> return ret;
> }
>
> // </smpl>
>
> Signed-off-by: Julia Lawall <Julia.Lawall@lip6.fr>
Acked-by: Geert Uytterhoeven <geert@linux-m68k.org>
> ---
> Not tested.
>
> drivers/scsi/ps3rom.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/drivers/scsi/ps3rom.c b/drivers/scsi/ps3rom.c
> index e6e2a30..04d77ce 100644
> --- a/drivers/scsi/ps3rom.c
> +++ b/drivers/scsi/ps3rom.c
> @@ -387,6 +387,7 @@ static int ps3rom_probe(struct ps3_system_bus_device *_dev)
> if (!host) {
> dev_err(&dev->sbd.core, "%s:%u: scsi_host_alloc failed\n",
> __func__, __LINE__);
> + error = -ENOMEM;
> goto fail_teardown;
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply
* [PATCH 0/25] fix error return code
From: Julia Lawall @ 2013-12-29 22:47 UTC (permalink / raw)
To: linux-input
Cc: cbe-oss-dev, davinci-linux-open-source, linux-pcmcia, rtc-linux,
linux-scsi, linux-pm, linux-rdma, netdev, linux-usb,
kernel-janitors, linux-kernel, platform-driver-x86,
linux-samsung-soc, linux-mtd, dmaengine, linuxppc-dev,
linux-arm-kernel, linux-media
These patches fix cases where the return variable is not set to an error
code in an error case.
^ permalink raw reply
* [PATCH 19/25] fix error return code
From: Julia Lawall @ 2013-12-29 22:47 UTC (permalink / raw)
To: Geoff Levand
Cc: cbe-oss-dev, linux-scsi, kernel-janitors, linux-kernel,
James E.J. Bottomley, linuxppc-dev
In-Reply-To: <1388357260-4843-1-git-send-email-Julia.Lawall@lip6.fr>
From: Julia Lawall <Julia.Lawall@lip6.fr>
Set the return variable to an error code as done elsewhere in the function.
A simplified version of the semantic match that finds this problem is as
follows: (http://coccinelle.lip6.fr/)
// <smpl>
(
if@p1 (\(ret < 0\|ret != 0\))
{ ... return ret; }
|
ret@p1 = 0
)
... when != ret = e1
when != &ret
*if(...)
{
... when != ret = e2
when forall
return ret;
}
// </smpl>
Signed-off-by: Julia Lawall <Julia.Lawall@lip6.fr>
---
Not tested.
drivers/scsi/ps3rom.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/scsi/ps3rom.c b/drivers/scsi/ps3rom.c
index e6e2a30..04d77ce 100644
--- a/drivers/scsi/ps3rom.c
+++ b/drivers/scsi/ps3rom.c
@@ -387,6 +387,7 @@ static int ps3rom_probe(struct ps3_system_bus_device *_dev)
if (!host) {
dev_err(&dev->sbd.core, "%s:%u: scsi_host_alloc failed\n",
__func__, __LINE__);
+ error = -ENOMEM;
goto fail_teardown;
}
^ permalink raw reply related
* Re: [question] Can the execution of the atomtic operation instruction pair lwarx/stwcx be interrrupted by local HW interruptions?
From: wyang @ 2013-12-30 1:54 UTC (permalink / raw)
To: Gavin Hu, Linuxppc-dev
In-Reply-To: <CABiPGEfmEFovARBy0rwjbDpBnVeRrmvQrxgnH+32z0RLUX3Nkw@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 1150 bytes --]
On 12/28/2013 01:41 PM, Gavin Hu wrote:
> Hi
>
> I notice that there is a pair ppc instructions lwarx and stwcx used to
> atomtic operation for instance, atomic_inc/atomic_dec.
>
> In some ppc manuals, they more emphasize its mechanism is that lwarx
> can reseve the target memory address preventing other CORE from
> modifying it.
>
> I assume that there is atomtic operation executing on the CORE0 in a
> multicore system. In this situation, does the CORE0 disable the local
> HW interrupt?
> Can the executing process from the beginning of lwarx and end of stwcx
> be interrupted by HW interruptions/exceptions? Anyway, they are two
> assembly instructions.
It should just like other arch, the processor should response any
interrupt after the execution of a instruction, so the local HW
interrupt is not disabled.
Thanks
Wei
>
> Thanks a lot!
>
> "1: lwarx %0,0,%2 # atomic_inc\n\
> addic %0,%0,1\n"
> " stwcx. %0,0,%2 \n\
>
>
> BR
> Gavin. Hu
>
>
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev@lists.ozlabs.org
> https://lists.ozlabs.org/listinfo/linuxppc-dev
[-- Attachment #2: Type: text/html, Size: 2655 bytes --]
^ permalink raw reply
* RE: [PATCH] powerpc/mpic_timer: fix the time calculation is not accurate
From: Dongsheng.Wang @ 2013-12-30 2:21 UTC (permalink / raw)
To: Scott Wood; +Cc: linuxppc-dev@lists.ozlabs.org
In-Reply-To: <1388188783.21454.27.camel@snotra.buserror.net>
DQoNCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogV29vZCBTY290dC1CMDc0
MjENCj4gU2VudDogU2F0dXJkYXksIERlY2VtYmVyIDI4LCAyMDEzIDg6MDAgQU0NCj4gVG86IFdh
bmcgRG9uZ3NoZW5nLUI0MDUzNA0KPiBDYzogZ2FsYWtAa2VybmVsLmNyYXNoaW5nLm9yZzsgbGlu
dXhwcGMtZGV2QGxpc3RzLm96bGFicy5vcmcNCj4gU3ViamVjdDogUmU6IFtQQVRDSF0gcG93ZXJw
Yy9tcGljX3RpbWVyOiBmaXggdGhlIHRpbWUgY2FsY3VsYXRpb24gaXMgbm90DQo+IGFjY3VyYXRl
DQo+IA0KPiBPbiBNb24sIDIwMTMtMTItMjMgYXQgMTA6MzMgKzA4MDAsIERvbmdzaGVuZyBXYW5n
IHdyb3RlOg0KPiA+IEZyb206IFdhbmcgRG9uZ3NoZW5nIDxkb25nc2hlbmcud2FuZ0BmcmVlc2Nh
bGUuY29tPg0KPiA+DQo+ID4gV2hlbiB0aGUgdGltZXIgR1RDQ1IgdG9nZ2xlIGJpdCBpcyBpbnZl
cnRlZCwgd2UgY2FsY3VsYXRlZCB0aGUgcmVzdCBvZg0KPiA+IHRoZSB0aW1lIGlzIG5vdCBhY2N1
cmF0ZS4gU28gd2UgbmVlZCB0byBpZ25vcmUgdGhpcyBiaXQuDQo+ID4NCj4gPiBTaWduZWQtb2Zm
LWJ5OiBXYW5nIERvbmdzaGVuZyA8ZG9uZ3NoZW5nLndhbmdAZnJlZXNjYWxlLmNvbT4NCj4gPg0K
PiA+IGRpZmYgLS1naXQgYS9hcmNoL3Bvd2VycGMvc3lzZGV2L21waWNfdGltZXIuYw0KPiA+IGIv
YXJjaC9wb3dlcnBjL3N5c2Rldi9tcGljX3RpbWVyLmMNCj4gPiBpbmRleCAyMmQ3ZDU3Li4wZmI3
MGM5IDEwMDY0NA0KPiA+IC0tLSBhL2FyY2gvcG93ZXJwYy9zeXNkZXYvbXBpY190aW1lci5jDQo+
ID4gKysrIGIvYXJjaC9wb3dlcnBjL3N5c2Rldi9tcGljX3RpbWVyLmMNCj4gPiBAQCAtNDEsNiAr
NDEsNyBAQA0KPiA+ICAjZGVmaW5lIE1QSUNfVElNRVJfVENSX1JPVlJfT0ZGU0VUCTI0DQo+ID4N
Cj4gPiAgI2RlZmluZSBUSU1FUl9TVE9QCQkJMHg4MDAwMDAwMA0KPiA+ICsjZGVmaW5lIEdUQ0NS
X1RPRwkJCTB4ODAwMDAwMDANCj4gPiAgI2RlZmluZSBUSU1FUlNfUEVSX0dST1VQCQk0DQo+ID4g
ICNkZWZpbmUgTUFYX1RJQ0tTCQkJKH4wVSA+PiAxKQ0KPiA+ICAjZGVmaW5lIE1BWF9USUNLU19D
QVNDQURFCQkofjBVKQ0KPiA+IEBAIC05Niw4ICs5NywxNSBAQCBzdGF0aWMgdm9pZCBjb252ZXJ0
X3RpY2tzX3RvX3RpbWUoc3RydWN0IHRpbWVyX2dyb3VwX3ByaXYNCj4gKnByaXYsDQo+ID4gIAl0
aW1lLT50dl9zZWMgPSAoX19rZXJuZWxfdGltZV90KWRpdl91NjQodGlja3MsIHByaXYtPnRpbWVy
ZnJlcSk7DQo+ID4gIAl0bXBfc2VjID0gKHU2NCl0aW1lLT50dl9zZWMgKiAodTY0KXByaXYtPnRp
bWVyZnJlcTsNCj4gPg0KPiA+IC0JdGltZS0+dHZfdXNlYyA9IChfX2tlcm5lbF9zdXNlY29uZHNf
dCkNCj4gPiAtCQlkaXZfdTY0KCh0aWNrcyAtIHRtcF9zZWMpICogMTAwMDAwMCwgcHJpdi0+dGlt
ZXJmcmVxKTsNCj4gPiArCXRpbWUtPnR2X3VzZWMgPSAwOw0KPiA+ICsNCj4gPiArCS8qDQo+ID4g
KwkgKiBJbiBzb21lIGNhc2VzIHRtcF9zZWMgbWF5IGJlIGdyZWF0ZXIgdGhhbiB0aWNrcywgYmVj
YXVzZSBpbiB0aGUNCj4gPiArCSAqIHByb2Nlc3Mgb2YgY2FsY3VsYXRpb24gdGlja3MgYW5kIHRt
cF9zZWMgd2lsbCBiZSByb3VuZGVkLg0KPiA+ICsJICovDQo+ID4gKwlpZiAodG1wX3NlYyA8PSB0
aWNrcykNCj4gPiArCQl0aW1lLT50dl91c2VjID0gKF9fa2VybmVsX3N1c2Vjb25kc190KQ0KPiA+
ICsJCQlkaXZfdTY0KCh0aWNrcyAtIHRtcF9zZWMpICogMTAwMDAwMCwgcHJpdi0+dGltZXJmcmVx
KTsNCj4gDQo+IEkgZG9uJ3Qgc2VlIGhvdyB0aGlzIHBhcnQgb2YgdGhlIHBhdGNoIHJlbGF0ZXMg
dG8gdGhlIHBhdGNoIGRlc2NyaXB0aW9uLg0KPiANClRoYW5rcywgSSBtaXNzIHRoaXMgZGVzY3Jp
cHRpb24sIDooLg0KSSBzaG91bGQgc3BsaXQgdGhlIHBhdGNoLg0KDQotRG9uZ3NoZW5nDQoNCj4g
LVNjb3R0DQo+IA0KDQo=
^ permalink raw reply
* RE: [PATCH v6 1/4] powerpc/fsl: add E6500 PVR and SPRN_PWRMGTCR0 define
From: Dongsheng.Wang @ 2013-12-30 2:37 UTC (permalink / raw)
To: Scott Wood, Bharat.Bhushan@freescale.com
Cc: linuxppc-dev@lists.ozlabs.org, Dongsheng.Wang@freescale.com
In-Reply-To: <1387268222-9703-1-git-send-email-dongsheng.wang@freescale.com>
Hi Scott,
Could you apply these patches?
[v6,1/4] powerpc/fsl: add E6500 PVR and SPRN_PWRMGTCR0 define, http://patch=
work.ozlabs.org/patch/302045/
[v6,2/4] powerpc/85xx: add hardware automatically enter altivec idle state,=
http://patchwork.ozlabs.org/patch/302046/
[v6,3/4] powerpc/85xx: add hardware automatically enter pw20 state, http://=
patchwork.ozlabs.org/patch/302047/
[v6,4/4] powerpc/85xx: add sysfs for pw20 state and altivec idle, http://pa=
tchwork.ozlabs.org/patch/302048/
-Dongsheng
> -----Original Message-----
> From: Dongsheng Wang [mailto:dongsheng.wang@freescale.com]
> Sent: Tuesday, December 17, 2013 4:17 PM
> To: Wood Scott-B07421; Bhushan Bharat-R65777
> Cc: linuxppc-dev@lists.ozlabs.org; Wang Dongsheng-B40534
> Subject: [PATCH v6 1/4] powerpc/fsl: add E6500 PVR and SPRN_PWRMGTCR0 def=
ine
>=20
> From: Wang Dongsheng <dongsheng.wang@freescale.com>
>=20
> E6500 PVR and SPRN_PWRMGTCR0 will be used in subsequent pw20/altivec
> idle patches.
>=20
> Signed-off-by: Wang Dongsheng <dongsheng.wang@freescale.com>
> ---
> *v3:
> Add bit definitions for PWRMGTCR0.
>=20
> arch/powerpc/include/asm/reg.h | 2 ++
> arch/powerpc/include/asm/reg_booke.h | 9 +++++++++
> 2 files changed, 11 insertions(+)
>=20
> diff --git a/arch/powerpc/include/asm/reg.h b/arch/powerpc/include/asm/re=
g.h
> index 64264bf..d4160ca 100644
> --- a/arch/powerpc/include/asm/reg.h
> +++ b/arch/powerpc/include/asm/reg.h
> @@ -1053,6 +1053,8 @@
> #define PVR_8560 0x80200000
> #define PVR_VER_E500V1 0x8020
> #define PVR_VER_E500V2 0x8021
> +#define PVR_VER_E6500 0x8040
> +
> /*
> * For the 8xx processors, all of them report the same PVR family for
> * the PowerPC core. The various versions of these processors must be
> diff --git a/arch/powerpc/include/asm/reg_booke.h
> b/arch/powerpc/include/asm/reg_booke.h
> index ed8f836..4a6457e 100644
> --- a/arch/powerpc/include/asm/reg_booke.h
> +++ b/arch/powerpc/include/asm/reg_booke.h
> @@ -170,6 +170,7 @@
> #define SPRN_L2CSR1 0x3FA /* L2 Data Cache Control and Status Register 1
> */
> #define SPRN_DCCR 0x3FA /* Data Cache Cacheability Register */
> #define SPRN_ICCR 0x3FB /* Instruction Cache Cacheability Register */
> +#define SPRN_PWRMGTCR0 0x3FB /* Power management control register 0 */
> #define SPRN_SVR 0x3FF /* System Version Register */
>=20
> /*
> @@ -216,6 +217,14 @@
> #define CCR1_DPC 0x00000100 /* Disable L1 I-Cache/D-Cache parity
> checking */
> #define CCR1_TCS 0x00000080 /* Timer Clock Select */
>=20
> +/* Bit definitions for PWRMGTCR0. */
> +#define PWRMGTCR0_PW20_WAIT (1 << 14) /* PW20 state enable bit */
> +#define PWRMGTCR0_PW20_ENT_SHIFT 8
> +#define PWRMGTCR0_PW20_ENT 0x3F00
> +#define PWRMGTCR0_AV_IDLE_PD_EN (1 << 22) /* Altivec idle enable */
> +#define PWRMGTCR0_AV_IDLE_CNT_SHIFT 16
> +#define PWRMGTCR0_AV_IDLE_CNT 0x3F0000
> +
> /* Bit definitions for the MCSR. */
> #define MCSR_MCS 0x80000000 /* Machine Check Summary */
> #define MCSR_IB 0x40000000 /* Instruction PLB Error */
> --
> 1.8.0
>=20
^ permalink raw reply
* Re: [PATCH] of/irq: Fix device_node refcount in of_irq_parse_raw()
From: Benjamin Herrenschmidt @ 2013-12-30 2:37 UTC (permalink / raw)
To: Cédric Le Goater
Cc: grant.likely, devicetree, Thierry Reding, linuxppc-dev,
Linux Kernel list
In-Reply-To: <1387301573-30502-1-git-send-email-clg@fr.ibm.com>
On Tue, 2013-12-17 at 18:32 +0100, Cédric Le Goater wrote:
> Commit 2361613206e6, "of/irq: Refactor interrupt-map parsing" changed
> the refcount on the device_node causing an error in of_node_put():
Grant, Thierry, this is a regression, please send to Linus ASAP...
Cheers,
Ben.
> ERROR: Bad of_node_put() on /pci@800000020000000
> CPU: 0 PID: 1 Comm: swapper/0 Not tainted 3.13.0-rc3-dirty #2
> Call Trace:
> [c00000003e403500] [c0000000000144fc] .show_stack+0x7c/0x1f0 (unreliable)
> [c00000003e4035d0] [c00000000070f250] .dump_stack+0x88/0xb4
> [c00000003e403650] [c0000000005e8768] .of_node_release+0xd8/0xf0
> [c00000003e4036e0] [c0000000005eeafc] .of_irq_parse_one+0x10c/0x280
> [c00000003e4037a0] [c0000000005efd4c] .of_irq_parse_pci+0x3c/0x1d0
> [c00000003e403840] [c000000000038240] .pcibios_setup_device+0xa0/0x2e0
> [c00000003e403910] [c0000000000398f0] .pcibios_setup_bus_devices+0x60/0xd0
> [c00000003e403990] [c00000000003b3a4] .__of_scan_bus+0x1a4/0x2b0
> [c00000003e403a80] [c00000000003a62c] .pcibios_scan_phb+0x30c/0x410
> [c00000003e403b60] [c0000000009fe430] .pcibios_init+0x7c/0xd4
>
> This patch adjusts the refcount in the walk of the interrupt tree.
> When a match is found, there is no need to increase the refcount
> on 'out_irq->np' as 'newpar' is already holding a ref. The refcount
> balance between 'ipar' and 'newpar' is maintained in the skiplevel:
> goto label.
>
> This patch also removes the usage of the device_node variable 'old'
> which seems useless after the latest changes.
>
> Signed-off-by: Cédric Le Goater <clg@fr.ibm.com>
> ---
>
> This patch was tested on powerpc, pseries and powernv. This is a
> new area for me so I might have missed a path. Please take a look.
>
> We could now introduce an helper routine to look for #address-cells in
> of_irq_parse_raw(). This can be the subject of another patch.
>
> Thanks,
>
> C.
>
> drivers/of/irq.c | 5 +----
> 1 file changed, 1 insertion(+), 4 deletions(-)
>
> diff --git a/drivers/of/irq.c b/drivers/of/irq.c
> index 786b0b47fae4..27212402c532 100644
> --- a/drivers/of/irq.c
> +++ b/drivers/of/irq.c
> @@ -165,7 +165,6 @@ int of_irq_parse_raw(const __be32 *addr, struct of_phandle_args *out_irq)
> if (of_get_property(ipar, "interrupt-controller", NULL) !=
> NULL) {
> pr_debug(" -> got it !\n");
> - of_node_put(old);
> return 0;
> }
>
> @@ -250,8 +249,7 @@ int of_irq_parse_raw(const __be32 *addr, struct of_phandle_args *out_irq)
> * Successfully parsed an interrrupt-map translation; copy new
> * interrupt specifier into the out_irq structure
> */
> - of_node_put(out_irq->np);
> - out_irq->np = of_node_get(newpar);
> + out_irq->np = newpar;
>
> match_array = imap - newaddrsize - newintsize;
> for (i = 0; i < newintsize; i++)
> @@ -268,7 +266,6 @@ int of_irq_parse_raw(const __be32 *addr, struct of_phandle_args *out_irq)
> }
> fail:
> of_node_put(ipar);
> - of_node_put(out_irq->np);
> of_node_put(newpar);
>
> return -EINVAL;
^ permalink raw reply
* RE: [PATCH 1/2] powerpc/p1022ds: fix rtc compatible string
From: Dongsheng.Wang @ 2013-12-30 2:39 UTC (permalink / raw)
To: Scott Wood, Chang-Ming.Huang@freescale.com, Roy Zang
Cc: linuxppc-dev@lists.ozlabs.org, Dongsheng.Wang@freescale.com
In-Reply-To: <1387355964-39486-1-git-send-email-dongsheng.wang@freescale.com>
Hi Scott,
Could you apply these patches?
[1/2] powerpc/p1022ds: fix rtc compatible string, http://patchwork.ozlabs.o=
rg/patch/302741/
[2/2] powerpc/p1022ds: add a interrupt for rtc node, http://patchwork.ozlab=
s.org/patch/302742/
-Dongsheng
> -----Original Message-----
> From: Dongsheng Wang [mailto:dongsheng.wang@freescale.com]
> Sent: Wednesday, December 18, 2013 4:39 PM
> To: Wood Scott-B07421; Huang Changming-R66093; Zang Roy-R61911
> Cc: linuxppc-dev@lists.ozlabs.org; Wang Dongsheng-B40534
> Subject: [PATCH 1/2] powerpc/p1022ds: fix rtc compatible string
>=20
> From: Wang Dongsheng <dongsheng.wang@freescale.com>
>=20
> RTC Hardware(ds3232) and rtc compatible string does not match.
> Change "dallas,ds1339" to "dallas,ds3232".
>=20
> Signed-off-by: Wang Dongsheng <dongsheng.wang@freescale.com>
>=20
> diff --git a/arch/powerpc/boot/dts/p1022ds.dtsi
> b/arch/powerpc/boot/dts/p1022ds.dtsi
> index 873da35..5725058 100644
> --- a/arch/powerpc/boot/dts/p1022ds.dtsi
> +++ b/arch/powerpc/boot/dts/p1022ds.dtsi
> @@ -146,7 +146,7 @@
> */
> };
> rtc@68 {
> - compatible =3D "dallas,ds1339";
> + compatible =3D "dallas,ds3232";
> reg =3D <0x68>;
> };
> adt7461@4c {
> --
> 1.8.5
>=20
^ permalink raw reply
* Re: [PATCH] of/irq: Fix device_node refcount in of_irq_parse_raw()
From: Rob Herring @ 2013-12-30 2:42 UTC (permalink / raw)
To: Benjamin Herrenschmidt
Cc: devicetree@vger.kernel.org, Linux Kernel list, Thierry Reding,
Grant Likely, linuxppc-dev, Cédric Le Goater
In-Reply-To: <1388371049.4373.22.camel@pasglop>
[-- Attachment #1: Type: text/plain, Size: 3817 bytes --]
On Sun, Dec 29, 2013 at 8:37 PM, Benjamin Herrenschmidt <
benh@kernel.crashing.org> wrote:
> On Tue, 2013-12-17 at 18:32 +0100, Cédric Le Goater wrote:
> > Commit 2361613206e6, "of/irq: Refactor interrupt-map parsing" changed
> > the refcount on the device_node causing an error in of_node_put():
>
> Grant, Thierry, this is a regression, please send to Linus ASAP...
>
>
I'm working on doing that right this moment.
Rob
> Cheers,
> Ben.
>
> > ERROR: Bad of_node_put() on /pci@800000020000000
> > CPU: 0 PID: 1 Comm: swapper/0 Not tainted 3.13.0-rc3-dirty #2
> > Call Trace:
> > [c00000003e403500] [c0000000000144fc] .show_stack+0x7c/0x1f0 (unreliable)
> > [c00000003e4035d0] [c00000000070f250] .dump_stack+0x88/0xb4
> > [c00000003e403650] [c0000000005e8768] .of_node_release+0xd8/0xf0
> > [c00000003e4036e0] [c0000000005eeafc] .of_irq_parse_one+0x10c/0x280
> > [c00000003e4037a0] [c0000000005efd4c] .of_irq_parse_pci+0x3c/0x1d0
> > [c00000003e403840] [c000000000038240] .pcibios_setup_device+0xa0/0x2e0
> > [c00000003e403910] [c0000000000398f0]
> .pcibios_setup_bus_devices+0x60/0xd0
> > [c00000003e403990] [c00000000003b3a4] .__of_scan_bus+0x1a4/0x2b0
> > [c00000003e403a80] [c00000000003a62c] .pcibios_scan_phb+0x30c/0x410
> > [c00000003e403b60] [c0000000009fe430] .pcibios_init+0x7c/0xd4
> >
> > This patch adjusts the refcount in the walk of the interrupt tree.
> > When a match is found, there is no need to increase the refcount
> > on 'out_irq->np' as 'newpar' is already holding a ref. The refcount
> > balance between 'ipar' and 'newpar' is maintained in the skiplevel:
> > goto label.
> >
> > This patch also removes the usage of the device_node variable 'old'
> > which seems useless after the latest changes.
> >
> > Signed-off-by: Cédric Le Goater <clg@fr.ibm.com>
> > ---
> >
> > This patch was tested on powerpc, pseries and powernv. This is a
> > new area for me so I might have missed a path. Please take a look.
> >
> > We could now introduce an helper routine to look for #address-cells in
> > of_irq_parse_raw(). This can be the subject of another patch.
> >
> > Thanks,
> >
> > C.
> >
> > drivers/of/irq.c | 5 +----
> > 1 file changed, 1 insertion(+), 4 deletions(-)
> >
> > diff --git a/drivers/of/irq.c b/drivers/of/irq.c
> > index 786b0b47fae4..27212402c532 100644
> > --- a/drivers/of/irq.c
> > +++ b/drivers/of/irq.c
> > @@ -165,7 +165,6 @@ int of_irq_parse_raw(const __be32 *addr, struct
> of_phandle_args *out_irq)
> > if (of_get_property(ipar, "interrupt-controller", NULL) !=
> > NULL) {
> > pr_debug(" -> got it !\n");
> > - of_node_put(old);
> > return 0;
> > }
> >
> > @@ -250,8 +249,7 @@ int of_irq_parse_raw(const __be32 *addr, struct
> of_phandle_args *out_irq)
> > * Successfully parsed an interrrupt-map translation; copy
> new
> > * interrupt specifier into the out_irq structure
> > */
> > - of_node_put(out_irq->np);
> > - out_irq->np = of_node_get(newpar);
> > + out_irq->np = newpar;
> >
> > match_array = imap - newaddrsize - newintsize;
> > for (i = 0; i < newintsize; i++)
> > @@ -268,7 +266,6 @@ int of_irq_parse_raw(const __be32 *addr, struct
> of_phandle_args *out_irq)
> > }
> > fail:
> > of_node_put(ipar);
> > - of_node_put(out_irq->np);
> > of_node_put(newpar);
> >
> > return -EINVAL;
>
>
> --
> To unsubscribe from this list: send the line "unsubscribe devicetree" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
[-- Attachment #2: Type: text/html, Size: 5511 bytes --]
^ permalink raw reply
* Re: commit e38c0a1f breaks powerpc boards with uli1575 chip
From: Benjamin Herrenschmidt @ 2013-12-30 3:13 UTC (permalink / raw)
To: Nikita Yushchenko
Cc: devicetree@vger.kernel.org, Arnd Bergmann, Dmitry Krivoschekov,
Alexey Lugovskoy, Thierry Reding, linux-kernel, Rob Herring,
Grant Likely, linuxppc-dev
In-Reply-To: <201312190842.02702@blacky.localdomain>
On Thu, 2013-12-19 at 08:42 +0400, Nikita Yushchenko wrote:
> No, this does not help.
>
> I've dumped the actual content of 'range' and 'addr' at the failure
> point
> (i.e. ar point that returns error with e38c0a1f but passes without
> e38c0a1f ):
>
> OF: default map, cp=0, s=10000, da=70
> range: 01 00 00 00 00 00 00 00 00 00 00 00
> addr: 00 00 00 00 00 00 00 00 00 00 00 70
Something that has a #address-cells larger than 2, or more generally,
an address field that contains more than a single number, must have
a specific translation backend, like we have for PCI.
This is a bit annoying but originates from the original OFW stuff on
which this stuff is based where the bus node would provide the methods
for translation.
Cheers,
Ben.
^ permalink raw reply
* Re: [PATCH] of/irq: Fix device_node refcount in of_irq_parse_raw()
From: Benjamin Herrenschmidt @ 2013-12-30 3:59 UTC (permalink / raw)
To: Rob Herring
Cc: devicetree@vger.kernel.org, Linux Kernel list, Thierry Reding,
Grant Likely, linuxppc-dev, Cédric Le Goater
In-Reply-To: <CAL_JsqJRtk+U4nA7hh9Kh2C4UgbWP6V7sYMnTpAooR_zaySZaw@mail.gmail.com>
On Sun, 2013-12-29 at 20:42 -0600, Rob Herring wrote:
> On Sun, Dec 29, 2013 at 8:37 PM, Benjamin Herrenschmidt
> <benh@kernel.crashing.org> wrote:
>
> On Tue, 2013-12-17 at 18:32 +0100, Cédric Le Goater wrote:
> > Commit 2361613206e6, "of/irq: Refactor interrupt-map
> parsing" changed
> > the refcount on the device_node causing an error in
> of_node_put():
>
>
> Grant, Thierry, this is a regression, please send to Linus
> ASAP...
>
>
>
> I'm working on doing that right this moment.
Thanks, looks like I'm not the only trying to get some work done
today :)
Cheers,
Ben.
>
> Rob
>
> Cheers,
> Ben.
>
> > ERROR: Bad of_node_put() on /pci@800000020000000
> > CPU: 0 PID: 1 Comm: swapper/0 Not tainted 3.13.0-rc3-dirty
> #2
> > Call Trace:
> > [c00000003e403500] [c0000000000144fc] .show_stack+0x7c/0x1f0
> (unreliable)
> > [c00000003e4035d0] [c00000000070f250] .dump_stack+0x88/0xb4
> > [c00000003e403650] [c0000000005e8768] .of_node_release
> +0xd8/0xf0
> > [c00000003e4036e0] [c0000000005eeafc] .of_irq_parse_one
> +0x10c/0x280
> > [c00000003e4037a0] [c0000000005efd4c] .of_irq_parse_pci
> +0x3c/0x1d0
> > [c00000003e403840] [c000000000038240] .pcibios_setup_device
> +0xa0/0x2e0
> > [c00000003e403910]
> [c0000000000398f0] .pcibios_setup_bus_devices+0x60/0xd0
> > [c00000003e403990] [c00000000003b3a4] .__of_scan_bus
> +0x1a4/0x2b0
> > [c00000003e403a80] [c00000000003a62c] .pcibios_scan_phb
> +0x30c/0x410
> > [c00000003e403b60] [c0000000009fe430] .pcibios_init
> +0x7c/0xd4
> >
> > This patch adjusts the refcount in the walk of the interrupt
> tree.
> > When a match is found, there is no need to increase the
> refcount
> > on 'out_irq->np' as 'newpar' is already holding a ref. The
> refcount
> > balance between 'ipar' and 'newpar' is maintained in the
> skiplevel:
> > goto label.
> >
> > This patch also removes the usage of the device_node
> variable 'old'
> > which seems useless after the latest changes.
> >
> > Signed-off-by: Cédric Le Goater <clg@fr.ibm.com>
> > ---
> >
> > This patch was tested on powerpc, pseries and powernv. This
> is a
> > new area for me so I might have missed a path. Please take a
> look.
> >
> > We could now introduce an helper routine to look for
> #address-cells in
> > of_irq_parse_raw(). This can be the subject of another
> patch.
> >
> > Thanks,
> >
> > C.
> >
> > drivers/of/irq.c | 5 +----
> > 1 file changed, 1 insertion(+), 4 deletions(-)
> >
> > diff --git a/drivers/of/irq.c b/drivers/of/irq.c
> > index 786b0b47fae4..27212402c532 100644
> > --- a/drivers/of/irq.c
> > +++ b/drivers/of/irq.c
> > @@ -165,7 +165,6 @@ int of_irq_parse_raw(const __be32 *addr,
> struct of_phandle_args *out_irq)
> > if (of_get_property(ipar,
> "interrupt-controller", NULL) !=
> > NULL) {
> > pr_debug(" -> got it !\n");
> > - of_node_put(old);
> > return 0;
> > }
> >
> > @@ -250,8 +249,7 @@ int of_irq_parse_raw(const __be32 *addr,
> struct of_phandle_args *out_irq)
> > * Successfully parsed an interrrupt-map
> translation; copy new
> > * interrupt specifier into the out_irq
> structure
> > */
> > - of_node_put(out_irq->np);
> > - out_irq->np = of_node_get(newpar);
> > + out_irq->np = newpar;
> >
> > match_array = imap - newaddrsize - newintsize;
> > for (i = 0; i < newintsize; i++)
> > @@ -268,7 +266,6 @@ int of_irq_parse_raw(const __be32 *addr,
> struct of_phandle_args *out_irq)
> > }
> > fail:
> > of_node_put(ipar);
> > - of_node_put(out_irq->np);
> > of_node_put(newpar);
> >
> > return -EINVAL;
>
>
> --
>
> To unsubscribe from this list: send the line "unsubscribe
> devicetree" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at
> http://vger.kernel.org/majordomo-info.html
>
>
>
^ permalink raw reply
* [git pull] Please pull powerpc.git merge branch
From: Benjamin Herrenschmidt @ 2013-12-30 4:37 UTC (permalink / raw)
To: Linus Torvalds; +Cc: linuxppc-dev list, Linux Kernel list
Hi Linus !
Here are a few more powerpc fixes for 3.13. A bit more endian
problems found during testing of 3.13 and a few other simple fixes
and regressions fixes.
Cheers,
Ben.
The following changes since commit 803c2d2f84da9dc2619449994af34d27148ab20d:
powerpc/powernv: Fix OPAL LPC access in Little Endian (2013-12-13 15:55:15 +1100)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/benh/powerpc.git merge
for you to fetch changes up to f991db1cf1bdca43675b5d2df0af991719727029:
Merge remote-tracking branch 'agust/merge' into merge (2013-12-30 14:48:27 +1100)
----------------------------------------------------------------
Anton Blanchard (1):
powerpc: Align p_end
Brian W Hart (2):
powernv/eeh: Fix possible buffer overrun in ioda_eeh_phb_diag()
powernv/eeh: Add buffer for P7IOC hub error data
Gerhard Sittig (1):
powerpc/512x: dts: remove misplaced IRQ spec from 'soc' node (5125)
Matteo Facchinetti (1):
powerpc/512x: dts: disable MPC5125 usb module
Michael Neuling (1):
powerpc: Fix bad stack check in exception entry
Olof Johansson (1):
powerpc: Fix alignment of secondary cpu spin vars
Paul E. McKenney (1):
powerpc: Make 64-bit non-VMX __copy_tofrom_user bi-endian
Rajesh B Prathipati (1):
powerpc: Make unaligned accesses endian-safe for powerpc
arch/powerpc/boot/dts/mpc5125twr.dts | 6 +++-
arch/powerpc/include/asm/exception-64s.h | 2 +-
arch/powerpc/include/asm/unaligned.h | 7 +++-
arch/powerpc/kernel/head_64.S | 2 ++
arch/powerpc/lib/copyuser_64.S | 53 ++++++++++++++++++++++---------
arch/powerpc/platforms/powernv/eeh-ioda.c | 20 +++---------
arch/powerpc/platforms/powernv/pci.h | 4 ++-
7 files changed, 60 insertions(+), 34 deletions(-)
^ permalink raw reply
* [PATCH -V2] POWERPC: BOOK3S: KVM: Use the saved dsisr and dar values on book3s 64
From: Aneesh Kumar K.V @ 2013-12-30 6:04 UTC (permalink / raw)
To: agraf, benh, paulus; +Cc: linuxppc-dev, kvm, kvm-ppc, Aneesh Kumar K.V
From: "Aneesh Kumar K.V" <aneesh.kumar@linux.vnet.ibm.com>
Although it's optional IBM POWER cpus always had DAR value set on
alignment interrupt. So don't try to compute these values.
Signed-off-by: Aneesh Kumar K.V <aneesh.kumar@linux.vnet.ibm.com>
---
arch/powerpc/kvm/book3s_emulate.c | 28 ++++++++++++++++++++++++++++
1 file changed, 28 insertions(+)
diff --git a/arch/powerpc/kvm/book3s_emulate.c b/arch/powerpc/kvm/book3s_emulate.c
index 502a47ac4453..d8e2d079483d 100644
--- a/arch/powerpc/kvm/book3s_emulate.c
+++ b/arch/powerpc/kvm/book3s_emulate.c
@@ -599,6 +599,19 @@ unprivileged:
u32 kvmppc_alignment_dsisr(struct kvm_vcpu *vcpu, unsigned int inst)
{
+#ifdef CONFIG_PPC_BOOK3S_64
+ return vcpu->arch.fault_dsisr;
+#else
+ /*
+ * Mac OS X has some applications - namely the Finder - that require
+ * alignment interrupts to work properly. So we need to implement them.
+
+ * But the spec for 970 and 750 also looks different. While 750 requires
+ * the DSISR and DAR fields to reflect some instruction bits (DSISR) and
+ * the fault address (DAR), the 970 declares this as an optional feature.
+ * So we need to reconstruct DSISR and DAR manually.
+ */
+
u32 dsisr = 0;
/*
@@ -637,10 +650,24 @@ u32 kvmppc_alignment_dsisr(struct kvm_vcpu *vcpu, unsigned int inst)
dsisr |= (inst >> 16) & 0x03ff; /* bits 22:31 */
return dsisr;
+#endif
}
ulong kvmppc_alignment_dar(struct kvm_vcpu *vcpu, unsigned int inst)
{
+#ifdef CONFIG_PPC_BOOK3S_64
+ return vcpu->arch.fault_dar;
+#else
+ /*
+ * Mac OS X has some applications - namely the Finder - that require
+ * alignment interrupts to work properly. So we need to implement them.
+
+ * But the spec for 970 and 750 also looks different. While 750 requires
+ * the DSISR and DAR fields to reflect some instruction bits (DSISR) and
+ * the fault address (DAR), the 970 declares this as an optional feature.
+ * So we need to reconstruct DSISR and DAR manually.
+ */
+
ulong dar = 0;
ulong ra = get_ra(inst);
ulong rb = get_rb(inst);
@@ -665,4 +692,5 @@ ulong kvmppc_alignment_dar(struct kvm_vcpu *vcpu, unsigned int inst)
}
return dar;
+#endif
}
--
1.8.3.2
^ permalink raw reply related
* [PATCH] block/ps3: Remove obsolete reference to MTD
From: Geert Uytterhoeven @ 2013-12-30 9:07 UTC (permalink / raw)
To: Geoff Levand, Jim Paris
Cc: cbe-oss-dev, Geert Uytterhoeven, linuxppc-dev, linux-kernel
The ps3vram driver is a plain block device driver since commit
f507cd22035fdadd5dbb476dd05e9e7ee21c3b84 ("ps3/block: Replace mtd/ps3vram
by block/ps3vram").
Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org>
---
drivers/block/ps3vram.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/block/ps3vram.c b/drivers/block/ps3vram.c
index 06a2e53e5f37..313ee641ea10 100644
--- a/drivers/block/ps3vram.c
+++ b/drivers/block/ps3vram.c
@@ -1,5 +1,5 @@
/*
- * ps3vram - Use extra PS3 video ram as MTD block device.
+ * ps3vram - Use extra PS3 video ram as block device.
*
* Copyright 2009 Sony Corporation
*
--
1.7.9.5
^ permalink raw reply related
* Re: [PATCH -V2] POWERPC: BOOK3S: KVM: Use the saved dsisr and dar values on book3s 64
From: Alexander Graf @ 2013-12-30 9:12 UTC (permalink / raw)
To: Aneesh Kumar K.V
Cc: kvm@vger.kernel.org, kvm-ppc@vger.kernel.org, paulus@samba.org,
Aneesh Kumar K.V, linuxppc-dev@lists.ozlabs.org
In-Reply-To: <1388383469-6411-1-git-send-email-aneesh.kumar@linux.vnet.ibm.com>
> Am 30.12.2013 um 07:04 schrieb "Aneesh Kumar K.V" <aneesh.kumar@linux.vnet=
.ibm.com>:
>=20
> From: "Aneesh Kumar K.V" <aneesh.kumar@linux.vnet.ibm.com>
>=20
> Although it's optional IBM POWER cpus always had DAR value set on
> alignment interrupt. So don't try to compute these values.
>=20
> Signed-off-by: Aneesh Kumar K.V <aneesh.kumar@linux.vnet.ibm.com>
> ---
> arch/powerpc/kvm/book3s_emulate.c | 28 ++++++++++++++++++++++++++++
> 1 file changed, 28 insertions(+)
>=20
> diff --git a/arch/powerpc/kvm/book3s_emulate.c b/arch/powerpc/kvm/book3s_e=
mulate.c
> index 502a47ac4453..d8e2d079483d 100644
> --- a/arch/powerpc/kvm/book3s_emulate.c
> +++ b/arch/powerpc/kvm/book3s_emulate.c
> @@ -599,6 +599,19 @@ unprivileged:
>=20
> u32 kvmppc_alignment_dsisr(struct kvm_vcpu *vcpu, unsigned int inst)
> {
> +#ifdef CONFIG_PPC_BOOK3S_64
> + return vcpu->arch.fault_dsisr;
This is still wrong when you virtualize a 750 on a 970 for example.
Alex
> +#else
> + /*
> + * Mac OS X has some applications - namely the Finder - that require
> + * alignment interrupts to work properly. So we need to implement the=
m.
> +
> + * But the spec for 970 and 750 also looks different. While 750 requi=
res
> + * the DSISR and DAR fields to reflect some instruction bits (DSISR) a=
nd
> + * the fault address (DAR), the 970 declares this as an optional feat=
ure.
> + * So we need to reconstruct DSISR and DAR manually.
> + */
> +
> u32 dsisr =3D 0;
>=20
> /*
> @@ -637,10 +650,24 @@ u32 kvmppc_alignment_dsisr(struct kvm_vcpu *vcpu, un=
signed int inst)
> dsisr |=3D (inst >> 16) & 0x03ff; /* bits 22:31 */
>=20
> return dsisr;
> +#endif
> }
>=20
> ulong kvmppc_alignment_dar(struct kvm_vcpu *vcpu, unsigned int inst)
> {
> +#ifdef CONFIG_PPC_BOOK3S_64
> + return vcpu->arch.fault_dar;
> +#else
> + /*
> + * Mac OS X has some applications - namely the Finder - that require
> + * alignment interrupts to work properly. So we need to implement the=
m.
> +
> + * But the spec for 970 and 750 also looks different. While 750 requi=
res
> + * the DSISR and DAR fields to reflect some instruction bits (DSISR) a=
nd
> + * the fault address (DAR), the 970 declares this as an optional feat=
ure.
> + * So we need to reconstruct DSISR and DAR manually.
> + */
> +
> ulong dar =3D 0;
> ulong ra =3D get_ra(inst);
> ulong rb =3D get_rb(inst);
> @@ -665,4 +692,5 @@ ulong kvmppc_alignment_dar(struct kvm_vcpu *vcpu, unsi=
gned int inst)
> }
>=20
> return dar;
> +#endif
> }
> --=20
> 1.8.3.2
>=20
^ permalink raw reply
* [PATCH 1/2] powerpc: Fix the setup of CPU-to-Node mappings during CPU online
From: Srivatsa S. Bhat @ 2013-12-30 11:35 UTC (permalink / raw)
To: benh, paulus, nfont; +Cc: Srivatsa S. Bhat, maddy, linuxppc-dev, linux-kernel
On POWER platforms, the hypervisor can notify the guest kernel about dynamic
changes in the cpu-numa associativity (VPHN topology update). Hence the
cpu-to-node mappings that we got from the firmware during boot, may no longer
be valid after such updates. This is handled using the arch_update_cpu_topology()
hook in the scheduler, and the sched-domains are rebuilt according to the new
mappings.
But unfortunately, at the moment, CPU hotplug ignores these updated mappings
and instead queries the firmware for the cpu-to-numa relationships and uses
them during CPU online. So the kernel can end up assigning wrong NUMA nodes
to CPUs during subsequent CPU hotplug online operations (after booting).
Further, a particularly problematic scenario can result from this bug:
On POWER platforms, the SMT mode can be switched between 1, 2, 4 (and even 8)
threads per core. The switch to Single-Threaded (ST) mode is performed by
offlining all except the first CPU thread in each core. Switching back to
SMT mode involves onlining those other threads back, in each core.
Now consider this scenario:
1. During boot, the kernel gets the cpu-to-node mappings from the firmware
and assigns the CPUs to NUMA nodes appropriately, during CPU online.
2. Later on, the hypervisor updates the cpu-to-node mappings dynamically and
communicates this update to the kernel. The kernel in turn updates its
cpu-to-node associations and rebuilds its sched domains. Everything is
fine so far.
3. Now, the user switches the machine from SMT to ST mode (say, by running
ppc64_cpu --smt=1). This involves offlining all except 1 thread in each
core.
4. The user then tries to switch back from ST to SMT mode (say, by running
ppc64_cpu --smt=4), and this involves onlining those threads back. Since
CPU hotplug ignores the new mappings, it queries the firmware and tries to
associate the newly onlined sibling threads to the old NUMA nodes. This
results in sibling threads within the same core getting associated with
different NUMA nodes, which is incorrect.
The scheduler's build-sched-domains code gets thoroughly confused with this
and enters an infinite loop and causes soft-lockups, as explained in detail
in commit 3be7db6ab (powerpc: VPHN topology change updates all siblings).
So to fix this, use the numa_cpu_lookup_table to remember the updated
cpu-to-node mappings, and use them during CPU hotplug online operations.
Further, we also need to ensure that all threads in a core are assigned to a
common NUMA node, irrespective of whether all those threads were online during
the topology update. To achieve this, we take care not to use cpu_sibling_mask()
since it is not hotplug invariant. Instead, we use cpu_first_sibling_thread()
and set up the mappings manually using the 'threads_per_core' value for that
particular platform. This helps us ensure that we don't hit this bug with any
combination of CPU hotplug and SMT mode switching.
Cc: stable@vger.kernel.org
Signed-off-by: Srivatsa S. Bhat <srivatsa.bhat@linux.vnet.ibm.com>
---
arch/powerpc/include/asm/topology.h | 10 +++++
arch/powerpc/mm/numa.c | 70 ++++++++++++++++++++++++++++++++++-
2 files changed, 76 insertions(+), 4 deletions(-)
diff --git a/arch/powerpc/include/asm/topology.h b/arch/powerpc/include/asm/topology.h
index 89e3ef2..d0b5fca 100644
--- a/arch/powerpc/include/asm/topology.h
+++ b/arch/powerpc/include/asm/topology.h
@@ -22,7 +22,15 @@ struct device_node;
static inline int cpu_to_node(int cpu)
{
- return numa_cpu_lookup_table[cpu];
+ int nid;
+
+ nid = numa_cpu_lookup_table[cpu];
+
+ /*
+ * During early boot, the numa-cpu lookup table might not have been
+ * setup for all CPUs yet. In such cases, default to node 0.
+ */
+ return (nid < 0) ? 0 : nid;
}
#define parent_node(node) (node)
diff --git a/arch/powerpc/mm/numa.c b/arch/powerpc/mm/numa.c
index 078d3e0..6847d50 100644
--- a/arch/powerpc/mm/numa.c
+++ b/arch/powerpc/mm/numa.c
@@ -31,6 +31,8 @@
#include <asm/sparsemem.h>
#include <asm/prom.h>
#include <asm/smp.h>
+#include <asm/cputhreads.h>
+#include <asm/topology.h>
#include <asm/firmware.h>
#include <asm/paca.h>
#include <asm/hvcall.h>
@@ -152,9 +154,22 @@ static void __init get_node_active_region(unsigned long pfn,
}
}
-static void map_cpu_to_node(int cpu, int node)
+static void reset_numa_cpu_lookup_table(void)
+{
+ unsigned int cpu;
+
+ for_each_possible_cpu(cpu)
+ numa_cpu_lookup_table[cpu] = -1;
+}
+
+static void update_numa_cpu_lookup_table(unsigned int cpu, int node)
{
numa_cpu_lookup_table[cpu] = node;
+}
+
+static void map_cpu_to_node(int cpu, int node)
+{
+ update_numa_cpu_lookup_table(cpu, node);
dbg("adding cpu %d to node %d\n", cpu, node);
@@ -522,11 +537,24 @@ static int of_drconf_to_nid_single(struct of_drconf_cell *drmem,
*/
static int numa_setup_cpu(unsigned long lcpu)
{
- int nid = 0;
- struct device_node *cpu = of_get_cpu_node(lcpu, NULL);
+ int nid;
+ struct device_node *cpu;
+
+ /*
+ * If a valid cpu-to-node mapping is already available, use it
+ * directly instead of querying the firmware, since it represents
+ * the most recent mapping notified to us by the platform (eg: VPHN).
+ */
+ if ((nid = numa_cpu_lookup_table[lcpu]) >= 0) {
+ map_cpu_to_node(lcpu, nid);
+ return nid;
+ }
+
+ cpu = of_get_cpu_node(lcpu, NULL);
if (!cpu) {
WARN_ON(1);
+ nid = 0;
goto out;
}
@@ -1067,6 +1095,7 @@ void __init do_init_bootmem(void)
*/
setup_node_to_cpumask_map();
+ reset_numa_cpu_lookup_table();
register_cpu_notifier(&ppc64_numa_nb);
cpu_numa_callback(&ppc64_numa_nb, CPU_UP_PREPARE,
(void *)(unsigned long)boot_cpuid);
@@ -1445,6 +1474,33 @@ static int update_cpu_topology(void *data)
return 0;
}
+static int update_lookup_table(void *data)
+{
+ struct topology_update_data *update;
+
+ if (!data)
+ return -EINVAL;
+
+ /*
+ * Upon topology update, the numa-cpu lookup table needs to be updated
+ * for all threads in the core, including offline CPUs, to ensure that
+ * future hotplug operations respect the cpu-to-node associativity
+ * properly.
+ */
+ for (update = data; update; update = update->next) {
+ int nid, base, j;
+
+ nid = update->new_nid;
+ base = cpu_first_thread_sibling(update->cpu);
+
+ for (j = 0; j < threads_per_core; j++) {
+ update_numa_cpu_lookup_table(base + j, nid);
+ }
+ }
+
+ return 0;
+}
+
/*
* Update the node maps and sysfs entries for each cpu whose home node
* has changed. Returns 1 when the topology has changed, and 0 otherwise.
@@ -1513,6 +1569,14 @@ int arch_update_cpu_topology(void)
stop_machine(update_cpu_topology, &updates[0], &updated_cpus);
+ /*
+ * Update the numa-cpu lookup table with the new mappings, even for
+ * offline CPUs. It is best to perform this update from the stop-
+ * machine context.
+ */
+ stop_machine(update_lookup_table, &updates[0],
+ cpumask_of(raw_smp_processor_id()));
+
for (ud = &updates[0]; ud; ud = ud->next) {
unregister_cpu_under_node(ud->cpu, ud->old_nid);
register_cpu_under_node(ud->cpu, ud->new_nid);
^ permalink raw reply related
* [PATCH 2/2] powerpc: Add debug checks to catch invalid cpu-to-node mappings
From: Srivatsa S. Bhat @ 2013-12-30 11:36 UTC (permalink / raw)
To: benh, paulus, nfont; +Cc: Srivatsa S. Bhat, maddy, linuxppc-dev, linux-kernel
In-Reply-To: <20131230113517.11508.7224.stgit@srivatsabhat.in.ibm.com>
There have been some weird bugs in the past where the kernel tried to associate
threads of the same core to different NUMA nodes, and things went haywire after
that point (as expected).
But unfortunately, root-causing such issues have been quite challenging, due to
the lack of appropriate debug checks in the kernel. These bugs usually lead to
some odd soft-lockups in the scheduler's build-sched-domain code in the CPU
hotplug path, which makes it very hard to trace it back to the incorrect
cpu-to-node mappings.
So add appropriate debug checks to catch such invalid cpu-to-node mappings
as early as possible.
Signed-off-by: Srivatsa S. Bhat <srivatsa.bhat@linux.vnet.ibm.com>
---
arch/powerpc/mm/numa.c | 26 ++++++++++++++++++++++++--
1 file changed, 24 insertions(+), 2 deletions(-)
diff --git a/arch/powerpc/mm/numa.c b/arch/powerpc/mm/numa.c
index 6847d50..4f50c6a 100644
--- a/arch/powerpc/mm/numa.c
+++ b/arch/powerpc/mm/numa.c
@@ -570,16 +570,38 @@ out:
return nid;
}
+static void verify_cpu_node_mapping(int cpu, int node)
+{
+ int base, sibling, i;
+
+ /* Verify that all the threads in the core belong to the same node */
+ base = cpu_first_thread_sibling(cpu);
+
+ for (i = 0; i < threads_per_core; i++) {
+ sibling = base + i;
+
+ if (sibling == cpu || cpu_is_offline(sibling))
+ continue;
+
+ if (cpu_to_node(sibling) != node) {
+ WARN(1, "CPU thread siblings %d and %d don't belong"
+ " to the same node!\n", cpu, sibling);
+ break;
+ }
+ }
+}
+
static int cpu_numa_callback(struct notifier_block *nfb, unsigned long action,
void *hcpu)
{
unsigned long lcpu = (unsigned long)hcpu;
- int ret = NOTIFY_DONE;
+ int ret = NOTIFY_DONE, nid;
switch (action) {
case CPU_UP_PREPARE:
case CPU_UP_PREPARE_FROZEN:
- numa_setup_cpu(lcpu);
+ nid = numa_setup_cpu(lcpu);
+ verify_cpu_node_mapping((int)lcpu, nid);
ret = NOTIFY_OK;
break;
#ifdef CONFIG_HOTPLUG_CPU
^ permalink raw reply related
* Re: [PATCH] ASoC: fsl_sai: Move the global registers setting to _dai_probe()
From: Mark Brown @ 2013-12-30 12:01 UTC (permalink / raw)
To: Xiubo Li
Cc: alsa-devel, lgirdwood, tiwai, linux-kernel, timur, perex,
shawn.guo, linuxppc-dev, b47053
In-Reply-To: <1387941614-7629-1-git-send-email-Li.Xiubo@freescale.com>
[-- Attachment #1: Type: text/plain, Size: 396 bytes --]
On Wed, Dec 25, 2013 at 11:20:14AM +0800, Xiubo Li wrote:
> Because we cannot make sure which one of _dai_fmt() and _dai_sysclk()
> will be firstly called. So move the RCSR/TCSR and TCR1/RCR1's
> initialization to _dai_probe(), and this can make sure that before any
> of {T,R}CR{1~5} register to be set the RCSR/TCSR's RE/TE bit has been
> cleared for the hareware limitation.
Applied, thanks.
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply
* Re: [PATCH] ASoC: fsl_sai: Fix one bug for hardware limitation.
From: Mark Brown @ 2013-12-30 12:15 UTC (permalink / raw)
To: Xiubo Li
Cc: alsa-devel, lgirdwood, tiwai, linux-kernel, timur, perex,
shawn.guo, linuxppc-dev, b47053
In-Reply-To: <1388026642-1464-1-git-send-email-Li.Xiubo@freescale.com>
[-- Attachment #1: Type: text/plain, Size: 1230 bytes --]
On Thu, Dec 26, 2013 at 10:57:22AM +0800, Xiubo Li wrote:
> This is maybe one bug or a limitation of the hardware that the {T,R}CR2's
> Synchronous Mode bits must be set as late as possible, or the SAI device
> maybe hanged up, and there has not any explaination about this limitation
> in the SAI Data Sheet.
If they really should be set as late as possible then I'd expect them to
be being set in the trigger function, that's what gets called as the
audio actually starts streaming. This is moving it to the startup
function which is one of the first things that happens during audio
stream setup so presumably makes things worse.
Also...
> @@ -62,6 +62,7 @@ static int fsl_sai_set_dai_sysclk_tr(struct snd_soc_dai *cpu_dai,
> reg_cr2 = FSL_SAI_RCR2;
>
> val_cr2 = sai_readl(sai, sai->base + reg_cr2);
> +
> switch (clk_id) {
> case FSL_SAI_CLK_BUS:
> val_cr2 &= ~FSL_SAI_CR2_MSEL_MASK;
> @@ -82,6 +83,7 @@ static int fsl_sai_set_dai_sysclk_tr(struct snd_soc_dai *cpu_dai,
> default:
> return -EINVAL;
> }
> +
> sai_writel(sai, val_cr2, sai->base + reg_cr2);
>
> return 0;
These appear to be unrelated changes - please send as a separate patch
if they're useful.
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply
* Re: [PATCH] ASoC: fsl_sai: Add disable operation for the corresponding data channel.
From: Mark Brown @ 2013-12-30 12:17 UTC (permalink / raw)
To: Xiubo Li
Cc: alsa-devel, lgirdwood, tiwai, linux-kernel, timur, perex,
shawn.guo, linuxppc-dev, b47053
In-Reply-To: <1387946404-24029-1-git-send-email-Li.Xiubo@freescale.com>
[-- Attachment #1: Type: text/plain, Size: 257 bytes --]
On Wed, Dec 25, 2013 at 12:40:04PM +0800, Xiubo Li wrote:
> Enables/Disables the corresponding data channel for tx/rx operation.
> A channel must be enabled before its FIFO is accessed, and then disable
> it when tx/rx is stopped or idle.
Applied, thanks.
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
^ 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