* [PATCH] powerpc/kvm: fix build with older toolchains
From: Nishanth Aravamudan @ 2011-11-07 23:36 UTC (permalink / raw)
To: Alexander Graf; +Cc: Paul Mackerras, linuxppc-dev, kvm-ppc
Fix KVM build for older toolchains (found with .powerpc64-unknown-linux-gnu-gcc
(crosstool-NG-1.8.1) 4.3.2):
AS arch/powerpc/kvm/book3s_hv_rmhandlers.o
arch/powerpc/kvm/book3s_hv_rmhandlers.S: Assembler messages:
arch/powerpc/kvm/book3s_hv_rmhandlers.S:1388: Error: Unrecognized opcode: `popcntw'
make[1]: *** [arch/powerpc/kvm/book3s_hv_rmhandlers.o] Error 1
make: *** [_module_arch/powerpc/kvm] Error 2
Signed-off-by: Nishanth Aravamudan <nacc@us.ibm.com>
diff --git a/arch/powerpc/kvm/book3s_hv_rmhandlers.S b/arch/powerpc/kvm/book3s_hv_rmhandlers.S
index 0607909..a053db1 100644
--- a/arch/powerpc/kvm/book3s_hv_rmhandlers.S
+++ b/arch/powerpc/kvm/book3s_hv_rmhandlers.S
@@ -1385,7 +1385,7 @@ END_FTR_SECTION_IFCLR(CPU_FTR_ARCH_206)
addi r6,r5,VCORE_NAPPING_THREADS
31: lwarx r4,0,r6
or r4,r4,r0
- popcntw r7,r4
+ PPC_POPCNTW(r7,r4)
cmpw r7,r8
bge 2f
stwcx. r4,0,r6
--
Nishanth Aravamudan <nacc@us.ibm.com>
IBM Linux Technology Center
^ permalink raw reply related
* [PATCH] powerpc: add KVM as module to defconfigs
From: Michael Neuling @ 2011-11-08 0:49 UTC (permalink / raw)
To: benh; +Cc: linuxppc-dev, Paul Mackerras, anton
Add HV mode KVM to Book3 server 64bit defconfigs as a module.
Doesn't add much to the size:
text data bss dec hex filename
8244109 4686767 994000 13924876 d47a0c vmlinux.vanilla
8256092 4691607 994128 13941827 d4bc43 vmlinux.kvm
This should enable more testing of this configuration.
Signed-off-by: Michael Neuling <mikey@neuling.org>
---
arch/powerpc/configs/ppc64_defconfig | 4 ++++
arch/powerpc/configs/pseries_defconfig | 4 ++++
2 files changed, 8 insertions(+)
Index: linux-ozlabs/arch/powerpc/configs/ppc64_defconfig
===================================================================
--- linux-ozlabs.orig/arch/powerpc/configs/ppc64_defconfig
+++ linux-ozlabs/arch/powerpc/configs/ppc64_defconfig
@@ -485,3 +485,7 @@ CONFIG_CRYPTO_TWOFISH=m
CONFIG_CRYPTO_LZO=m
# CONFIG_CRYPTO_ANSI_CPRNG is not set
# CONFIG_CRYPTO_HW is not set
+CONFIG_VIRTUALIZATION=y
+CONFIG_KVM_BOOK3S_64=m
+CONFIG_KVM_BOOK3S_64_HV=y
+CONFIG_VHOST_NET=m
Index: linux-ozlabs/arch/powerpc/configs/pseries_defconfig
===================================================================
--- linux-ozlabs.orig/arch/powerpc/configs/pseries_defconfig
+++ linux-ozlabs/arch/powerpc/configs/pseries_defconfig
@@ -362,3 +362,7 @@ CONFIG_CRYPTO_TWOFISH=m
CONFIG_CRYPTO_LZO=m
# CONFIG_CRYPTO_ANSI_CPRNG is not set
# CONFIG_CRYPTO_HW is not set
+CONFIG_VIRTUALIZATION=y
+CONFIG_KVM_BOOK3S_64=m
+CONFIG_KVM_BOOK3S_64_HV=y
+CONFIG_VHOST_NET=m
^ permalink raw reply
* [git pull] Please pull powerpc.git merge branch
From: Benjamin Herrenschmidt @ 2011-11-08 4:21 UTC (permalink / raw)
To: Linus Torvalds; +Cc: linuxppc-dev list, Andrew Morton, Linux Kernel list
Hi Linus !
Me again :-) So yesterday you pulled my -next branch with the bulk of
what happened since the last merge window up to when I left for my long
vacation (5 weeks). Today are a few remaining nits that happened during
that time.
Essentially small fixes, a defconfig bit, some janitorial stuff
(IRQ_DISABLED removal), a board support for 52xx that I forgot to pull
from Anatolij, and a fix to properly parse NUMA info from the
device-tree on powernc.
Ah, also finally add main memory to /proc/iomem. I've resisted that for
a long time but too much userspace gunk relies on it so here we go.
Cheers,
Ben.
The following changes since commit 1ea6b8f48918282bdca0b32a34095504ee65bab5:
Linux 3.2-rc1 (2011-11-07 16:16:02 -0800)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/benh/powerpc.git merge
Anton Blanchard (1):
powerpc: Add System RAM to /proc/iomem
Benjamin Herrenschmidt (1):
Merge remote-tracking branch 'agust/next' into merge
Dipankar Sarma (1):
powerpc/numa: NUMA topology support for PowerNV
Geoff Levand (2):
powerpc/ps3: Fix PS3 repository build warnings
powerpc/ps3: Fix lv1_gpu_attribute hcall
Heiko Schocher (2):
powerpc/5200: add support for charon board
powerpc, tqm5200: update tqm5200_defconfig to fit for charon board.
Michael Neuling (1):
powerpc: Add KVM as module to defconfigs
Nishanth Aravamudan (1):
powerpc/kvm: Fix build with older toolchains
Yong Zhang (2):
powerpc/irq: Remove IRQF_DISABLED
powerpc/ps3: irq: Remove IRQF_DISABLED
arch/powerpc/boot/dts/charon.dts | 236 ++++++++++++++++++++++++
arch/powerpc/configs/52xx/tqm5200_defconfig | 20 ++-
arch/powerpc/configs/ppc64_defconfig | 4 +
arch/powerpc/configs/pseries_defconfig | 4 +
arch/powerpc/include/asm/floppy.h | 4 +-
arch/powerpc/include/asm/lv1call.h | 2 +-
arch/powerpc/include/asm/xics.h | 4 +-
arch/powerpc/kernel/smp.c | 2 +-
arch/powerpc/kvm/book3s_hv_rmhandlers.S | 2 +-
arch/powerpc/mm/mem.c | 30 +++
arch/powerpc/mm/numa.c | 24 ++-
arch/powerpc/platforms/52xx/mpc5200_simple.c | 1 +
arch/powerpc/platforms/cell/beat.c | 2 +-
arch/powerpc/platforms/cell/celleb_scc_pciex.c | 2 +-
arch/powerpc/platforms/cell/iommu.c | 3 +-
arch/powerpc/platforms/cell/pmu.c | 2 +-
arch/powerpc/platforms/cell/spu_base.c | 9 +-
arch/powerpc/platforms/powermac/pic.c | 1 -
arch/powerpc/platforms/powermac/smp.c | 4 +-
arch/powerpc/platforms/ps3/device-init.c | 2 +-
arch/powerpc/platforms/ps3/repository.c | 32 ++--
arch/powerpc/sysdev/mpic.c | 2 -
arch/powerpc/sysdev/ppc4xx_soc.c | 2 +-
arch/powerpc/sysdev/xics/xics-common.c | 5 +-
drivers/ps3/ps3-vuart.c | 2 +-
drivers/ps3/ps3stor_lib.c | 2 +-
sound/ppc/snd_ps3.c | 2 +-
27 files changed, 343 insertions(+), 62 deletions(-)
create mode 100644 arch/powerpc/boot/dts/charon.dts
^ permalink raw reply
* Re: [git pull] Please pull powerpc.git merge branch
From: Benjamin Herrenschmidt @ 2011-11-08 4:42 UTC (permalink / raw)
To: Linus Torvalds; +Cc: linuxppc-dev list, Andrew Morton, Linux Kernel list
In-Reply-To: <1320726103.9419.14.camel@pasglop>
On Tue, 2011-11-08 at 15:21 +1100, Benjamin Herrenschmidt wrote:
> Hi Linus !
>
> Me again :-) So yesterday you pulled my -next branch with the bulk of
> what happened since the last merge window up to when I left for my long
> vacation (5 weeks). Today are a few remaining nits that happened during
> that time.
.. Add added a build fix (the defconfig change enables KVM which hits a
compile problem with some config combinations) so new pull request
bellow. Sorry about that.
Cheers,
Ben.
The following changes since commit 1ea6b8f48918282bdca0b32a34095504ee65bab5:
Linux 3.2-rc1 (2011-11-07 16:16:02 -0800)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/benh/powerpc.git merge
Alexander Graf (1):
powerpc/kvm: Fix build failure with HV KVM and CBE
Anton Blanchard (1):
powerpc: Add System RAM to /proc/iomem
Benjamin Herrenschmidt (1):
Merge remote-tracking branch 'agust/next' into merge
Dipankar Sarma (1):
powerpc/numa: NUMA topology support for PowerNV
Geoff Levand (2):
powerpc/ps3: Fix PS3 repository build warnings
powerpc/ps3: Fix lv1_gpu_attribute hcall
Heiko Schocher (2):
powerpc/5200: add support for charon board
powerpc, tqm5200: update tqm5200_defconfig to fit for charon board.
Michael Neuling (1):
powerpc: Add KVM as module to defconfigs
Nishanth Aravamudan (1):
powerpc/kvm: Fix build with older toolchains
Yong Zhang (2):
powerpc/irq: Remove IRQF_DISABLED
powerpc/ps3: irq: Remove IRQF_DISABLED
arch/powerpc/boot/dts/charon.dts | 236 ++++++++++++++++++++++++
arch/powerpc/configs/52xx/tqm5200_defconfig | 20 ++-
arch/powerpc/configs/ppc64_defconfig | 4 +
arch/powerpc/configs/pseries_defconfig | 4 +
arch/powerpc/include/asm/floppy.h | 4 +-
arch/powerpc/include/asm/lv1call.h | 2 +-
arch/powerpc/include/asm/xics.h | 4 +-
arch/powerpc/kernel/exceptions-64s.S | 6 +-
arch/powerpc/kernel/smp.c | 2 +-
arch/powerpc/kvm/book3s_hv_rmhandlers.S | 2 +-
arch/powerpc/mm/mem.c | 30 +++
arch/powerpc/mm/numa.c | 24 ++-
arch/powerpc/platforms/52xx/mpc5200_simple.c | 1 +
arch/powerpc/platforms/cell/beat.c | 2 +-
arch/powerpc/platforms/cell/celleb_scc_pciex.c | 2 +-
arch/powerpc/platforms/cell/iommu.c | 3 +-
arch/powerpc/platforms/cell/pmu.c | 2 +-
arch/powerpc/platforms/cell/spu_base.c | 9 +-
arch/powerpc/platforms/powermac/pic.c | 1 -
arch/powerpc/platforms/powermac/smp.c | 4 +-
arch/powerpc/platforms/ps3/device-init.c | 2 +-
arch/powerpc/platforms/ps3/repository.c | 32 ++--
arch/powerpc/sysdev/mpic.c | 2 -
arch/powerpc/sysdev/ppc4xx_soc.c | 2 +-
arch/powerpc/sysdev/xics/xics-common.c | 5 +-
drivers/ps3/ps3-vuart.c | 2 +-
drivers/ps3/ps3stor_lib.c | 2 +-
sound/ppc/snd_ps3.c | 2 +-
28 files changed, 346 insertions(+), 65 deletions(-)
create mode 100644 arch/powerpc/boot/dts/charon.dts
^ permalink raw reply
* RE: [PATCH] powerpc/p1023: set IRQ[4:6, 11] to high level sensitive for PCIe
From: Zang Roy-R61911 @ 2011-11-08 5:51 UTC (permalink / raw)
To: Wood Scott-B07421; +Cc: linuxppc-dev@lists.ozlabs.org
In-Reply-To: <4EB826F1.50402@freescale.com>
DQoNCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogV29vZCBTY290dC1CMDc0
MjENCj4gU2VudDogVHVlc2RheSwgTm92ZW1iZXIgMDgsIDIwMTEgMjo0NCBBTQ0KPiBUbzogWmFu
ZyBSb3ktUjYxOTExDQo+IENjOiBsaW51eHBwYy1kZXZAbGlzdHMub3psYWJzLm9yZw0KPiBTdWJq
ZWN0OiBSZTogW1BBVENIXSBwb3dlcnBjL3AxMDIzOiBzZXQgSVJRWzQ6NiwgMTFdIHRvIGhpZ2gg
bGV2ZWwgc2Vuc2l0aXZlIGZvcg0KPiBQQ0llDQo+IA0KPiBPbiAxMS8wNy8yMDExIDAyOjMyIEFN
LCBSb3kgWmFuZyB3cm90ZToNCj4gPiBQMTAyMyBleHRlcm5hbCBJUlFbNDo2LCAxMV0gZG8gbm90
IHBpbiBvdXQsIGJ1dCB0aGUgaW50ZXJydXB0cyBhcmUNCj4gPiBzaGFyZWQgd2l0aCBQQ0llIGNv
bnRyb2xsZXIuDQo+ID4gVGhlIHNpbGljb24gaW50ZXJuYWxseSB0aWVzIHRoZSBpbnRlcnJ1cHRz
IHRvIEwsIHNvIGNoYW5nZSB0aGUNCj4gPiBJUlFbNDo2LDExXSB0byBoaWdoIGxldmVsIHNlbnNp
dGl2ZSBmb3IgUENJZS4NCj4gDQo+IFNvbWUgZXh0cmEgY29tbWVudGFyeSBvbiB3aHkgdGhpcyB3
b3JrcyB3b3VsZCBiZSBuaWNlLg0KSSBkbyBub3Qga25vdyB3aGF0IGtpbmQgb2YgZXh0cmEgY29t
bWVudGFyeSB5b3UgcmVxdWVzdC4gDQpJUlEgNCw1LDYsIDExIGFyZSBpbnRlcm5hbGx5IHRpZSB0
byBsb3cgYnkgc2lsaWNvbi4gVG8gdXNlIHRoZXNlIGludGVycnVwdHMgZm9yIFBDSWUsIHRoZXkg
bmVlZCB0byBzZXQgaGlnaCBsZXZlbCBzZW5zaXRpdmUuDQpJdCBpcyBjbGVhciBlbm91Z2ggZm9y
IHRoaXMgcGF0Y2guDQoNCj4gDQo+IFRoZSBtYW51YWwgc2F5czoNCj4gDQo+ID4gSWYgYSBQQ0kg
RXhwcmVzcyBJTlR4IGludGVycnVwdCBpcyBiZWluZyB1c2VkLCB0aGVuIHRoZSBQSUMgbXVzdCBi
ZSBjb25maWd1cmVkDQo+IHNvIHRoYXQgZXh0ZXJuYWwgaW50ZXJydXB0cw0KPiA+IGFyZSBsZXZl
bC1zZW5zaXRpdmUgKEVJVlBSbltTXSA9IDEpLg0KVGhhdCBpcyB0cnVlIGZvciBhbGwgRlNMIHBv
d2VycGMgc2lsaWNvbiB3aXRoIFBDSWUgY29udHJvbGxlciBiZXNpZGUgUDEwMjMuDQoNCj4gDQo+
IGFuZA0KPiANCj4gPiBJbiBnZW5lcmFsLCB0aGVzZSBzaWduYWxzIHNob3VsZCBiZSBjb25zaWRl
cmVkIG11dHVhbGx5IGV4Y2x1c2l2ZS4gSWYgYSBQQ0kNCj4gRXhwcmVzcyBJTlR4IHNpZ25hbCBp
cyBiZWluZw0KPiA+IHVzZWQsIHRoZSBQSUMgbXVzdCBiZSBjb25maWd1cmVkIHNvIHRoYXQgZXh0
ZXJuYWwgaW50ZXJydXB0cyBhcmUgbGV2ZWwNCj4gc2Vuc2l0aXZlIChFSVZQUm5bU10gPSAxKS4g
SWYgYW4gSVJRbg0KPiA+IHNpZ25hbCBpcyBiZWluZyB1c2VkIGFzIGVkZ2UtdHJpZ2dlcmVkIChF
SVZQUm5bU10gPSAwKSwgdGhlIHN5c3RlbSBtdXN0IG5vdA0KPiBhbGxvdyBpbmJvdW5kIFBDSSBF
eHByZXNzDQo+ID4gSU5UeCB0cmFuc2FjdGlvbnMuDQo+ID4NCj4gPiBOb3RlIHRoYXQgaXQgaXMg
cG9zc2libGUgdG8gc2hhcmUgSVJRbiBhbmQgSU5UeCBpZiB0aGUgZXh0ZXJuYWwgaW50ZXJydXB0
IGlzDQo+IGxldmVsIHNlbnNpdGl2ZTsgaG93ZXZlciwgaWYgYW4NCj4gPiBpbnRlcnJ1cHQgb2Nj
dXJzLCB0aGUgaW50ZXJydXB0IHNlcnZpY2Ugcm91dGluZSBtdXN0IHBvbGwgYm90aCB0aGUgZXh0
ZXJuYWwNCj4gc291cmNlcyBjb25uZWN0ZWQgdG8gdGhlIElSUW4NCj4gPiBpbnB1dCBhbmQgdGhl
IFBDSSBFeHByZXNzIElOVHggc291cmNlcyB0byBkZXRlcm1pbmUgZnJvbSB3aGljaCBwYXRoIHRo
ZQ0KPiBleHRlcm5hbCBpbnRlcnJ1cHQgY2FtZS4gSW4gYW55DQo+ID4gY2FzZSwgSVJRbiBzaG91
bGQgYmUgcHVsbGVkIHRvIHRoZSBuZWdhdGVkIHN0YXRlIGFzIGRldGVybWluZWQgYnkgdGhlDQo+
IGFzc29jaWF0ZWQgcG9sYXJpdHkgc2V0dGluZyBpbg0KPiA+IEVJVlBSbltQXS4NCj4gDQo+IFNv
IGl0IGxvb2tzIGxpa2UgdGhlcmUncyBzb21lIG1hZ2ljIHdoZXJlYnkgdGhlIGNvbmZpZ3VyYXRp
b24gb2YgdGhlDQo+IE1QSUMgYWZmZWN0cyBob3cgdGhlIFBDSWUgZmVlZHMgdGhlIGludGVycnVw
dCBpbi4NCj4gDQo+IElzIHRoZXJlIChvciB3aWxsIHRoZXJlIGJlKSBhbiBlcnJhdHVtLCBvciBh
bnl0aGluZyBpbiB0aGUgbWFudWFsDQo+IGJlc2lkZXMgbm90IGJlaW5nIGRvY3VtZW50ZWQgYXMg
ZXh0ZXJuYWwgaW50ZXJydXB0cywgYWJvdXQgdGhlc2UNCj4gc3BlY2lmaWMgaW50ZXJydXB0cyBi
ZWluZyB0aWVkIGxvdyBpbiBzaWxpY29uIG9yIG5lZWRpbmcgdG8gYmUgYWN0aXZlIGhpZ2g/DQpJ
IGRvIG5vdCB0aGluayB0aGVyZSBpcyAod2lsbCkgYW4gZXJyYXR1bS4gQnV0IEkgYWdyZWUgdGhl
IG1hbnVhbCBuZWVkcyB0byBkb2N1bWVudCB0aGlzIG1vcmUgY2xlYXIuDQp0aGFua3MuDQpSb3kN
Cg0K
^ permalink raw reply
* Re: [PATCH] powerpc: Export PIR data through sysfs
From: Ananth N Mavinakayanahalli @ 2011-11-08 6:58 UTC (permalink / raw)
To: Scott Wood; +Cc: linuxppc-dev, Anton Blanchard, mahesh
In-Reply-To: <4EB812E8.9090107@freescale.com>
On Mon, Nov 07, 2011 at 11:18:32AM -0600, Scott Wood wrote:
> On 11/06/2011 10:47 PM, Ananth N Mavinakayanahalli wrote:
> > The Processor Identification Register (PIR) on powerpc provides
> > information to decode the processor identification tag. Decoding
> > this information platform specfic.
> >
> > Export PIR data via sysfs.
> >
> > (Powerpc manuals state this register is 'optional'. I am not sure
> > though if there are any Linux supported powerpc platforms that
> > don't have it. Code in the kernel referencing PIR isn't under
> > a platform ifdef).
>
> Those references are in platform-specific files, under #ifdef
> CONFIG_SMP, often in areas that would only be executed in the presence
> of multiple CPUs (e.g. secondary release). The reference in misc_32.S
> is inside #ifdef CONFIG_KEXEC and is fairly recent -- it may not have
> been tested on these systems.
>
> I don't see PIR (other than in the acronym definition section) in
> manuals for UP-only cores such as e300, 8xx, and 750.
I saw that SPRN_PIR is defined for booke in reg_booke.h but wasn't sure
if it is applicable to all platforms. Thanks for the clarification.
> What use does userspace have for this? If you want to return the
> currently executing CPU (which unless you're pinned could change as soon
> as the value is read...), why not just return smp_processor_id() or
> hard_smp_processor_id()?
Its not just the current cpu. Decoding PIR can tell you the core id,
thread id in case of SMT, and this information can be used by userspace
apps to set affinities, etc.
How does the following look?
Ananth
---
From: Ananth N Mavinakayanahalli <ananth@in.ibm.com>
The Processor Identification Register (PIR) on powerpc provides
information to decode the processor identification tag. Decoding
this information platform specfic.
Export PIR data via sysfs.
Signed-off-by: Ananth N Mavinakayanahalli <ananth@in.ibm.com>
---
arch/powerpc/kernel/sysfs.c | 13 +++++++++++++
1 file changed, 13 insertions(+)
Index: linux-3.1/arch/powerpc/kernel/sysfs.c
===================================================================
--- linux-3.1.orig/arch/powerpc/kernel/sysfs.c
+++ linux-3.1/arch/powerpc/kernel/sysfs.c
@@ -330,6 +330,11 @@ static struct sysdev_attribute pa6t_attr
#endif /* HAS_PPC_PMC_PA6T */
#endif /* HAS_PPC_PMC_CLASSIC */
+#if defined(CONFIG_SMP) && defined(SPRN_PIR)
+SYSFS_PMCSETUP(pir, SPRN_PIR);
+static SYSDEV_ATTR(pir, 0400, show_pir, NULL);
+#endif
+
static void __cpuinit register_cpu_online(unsigned int cpu)
{
struct cpu *c = &per_cpu(cpu_devices, cpu);
@@ -394,6 +399,10 @@ static void __cpuinit register_cpu_onlin
sysdev_create_file(s, &attr_dscr);
#endif /* CONFIG_PPC64 */
+#if defined(CONFIG_SMP) && defined(SPRN_PIR)
+ sysdev_create_file(s, &attr_pir);
+#endif
+
cacheinfo_cpu_online(cpu);
}
@@ -464,6 +473,10 @@ static void unregister_cpu_online(unsign
sysdev_remove_file(s, &attr_dscr);
#endif /* CONFIG_PPC64 */
+#if defined(CONFIG_SMP) && defined(SPRN_PIR)
+ sysdev_remove_file(s, &attr_pir);
+#endif
+
cacheinfo_cpu_offline(cpu);
}
^ permalink raw reply
* Re: [PATCH v2 1/5] [ppc] Process dynamic relocations for kernel
From: Suzuki Poulose @ 2011-11-08 7:11 UTC (permalink / raw)
To: Josh Poimboeuf
Cc: Nathan Miller, Josh Poimboeuf, Dave Hansen, Alan Modra,
Scott Wood, Paul Mackerras, linuxppc-dev
In-Reply-To: <1320678819.2750.15.camel@treble>
On 11/07/11 20:43, Josh Poimboeuf wrote:
> On Fri, 2011-11-04 at 14:06 +0530, Suzuki Poulose wrote:
>> On 11/03/11 05:06, Josh Poimboeuf wrote:
>>> On Tue, 2011-10-25 at 17:23 +0530, Suzuki K. Poulose wrote:
>>> @@ -137,6 +137,9 @@ get_type:
>>> lwz r0, 8(r9) /* r_addend */
>>> add r0, r0, r3 /* final addend */
>>> stwx r0, r4, r7 /* memory[r4+r7]) = (u32)r0 */
>>> + dcbst r4,r7 /* flush dcache line to memory */
>>> + sync /* wait for flush to complete */
>>> + icbi r4,r7 /* invalidate icache line */
>>
>> Doing it this way has two drawbacks :
>>
>> 1) Placing it here in relocate would do the flushing for each and every update.
>
> I agree. My kernel had around 80,000 relocations, which means 80,000
> d-cache line flushes (for a 32k d-cache) and 80,000 i-cache line
> invalidates (for a 32k i-cache). Which is obviously a little overkill.
> Although I didn't notice a performance hit during boot.
>
>
>> 2) I would like to keep this code as generic as possible for the PPC32 code.
>>
>> Could we move this to the place from relocate is called and flush the d-cache and
>> i-cache entirely ?
>
> Why not put the cache flushing code at the end of relocate? Would some
> of the other PPC32 platforms not require the cache flushing?
What I was suggesting is, instead of flushing the cache in relocate(), lets do it
like:
for e.g, on 440x, (in head_44x.S :)
#ifdef CONFIG_RELOCATABLE
...
bl relocate
#Flush the d-cache and invalidate the i-cache here
#endif
This would let the different platforms do the the cache invalidation in their
own way.
Btw, I didn't find an instruction to flush the entire d-cache in PPC440 manual.
We have instructions to flush only a block corresponding to an address.
However, we have 'iccci' which would invalidate the entire i-cache which, which
I think is better than 80,000 i-cache invalidates.
Kumar / Josh,
Do you have any suggestions here ?
>
> My PPC32 knowledge is 4xx-centric, so please feel free to rewrite the
> patch as needed to accommodate other PPC32 cores.
Same here :)
Thanks
Suzuki
^ permalink raw reply
* [PATCH] net: fsl_pq_mdio: fix oops when using uninitialized mutex
From: Baruch Siach @ 2011-11-08 7:23 UTC (permalink / raw)
To: netdev; +Cc: Andy Fleming, Baruch Siach, linuxppc-dev
The get_phy_id() routine (called via fsl_pq_mdio_find_free()) tries to acquire
the mdio_lock mutex which is only initialized when of_mdiobus_register() gets
called later. This causes the following oops:
Unable to handle kernel paging request for data at address 0x00000000
Faulting instruction address: 0xc02eda74
Oops: Kernel access of bad area, sig: 11 [#1]
P1020 RDB
NIP: c02eda74 LR: c01b3aa4 CTR: 00000007
REGS: cf039d70 TRAP: 0300 Not tainted (3.2.0-rc1-00004-gdc9d867-dirty)
MSR: 00029000 <EE,ME,CE> CR: 24024028 XER: 00000000
DEAR: 00000000, ESR: 00800000
TASK = cf034000[1] 'swapper' THREAD: cf038000
GPR00: cf039e28 cf039e20 cf034000 cf368228 00000020 00000002 ffeb02ad 000000d0
GPR08: 00001083 00000000 d1080000 cf039e90 00000000 100ae780 00000000 00000000
GPR16: c0000900 00000012 0fffffff 00ffa000 00000015 00000001 c0470000 00000000
GPR24: 00000000 00000000 c03b4e89 d1072030 cf034000 00000020 cf36822c cf368228
NIP [c02eda74] __mutex_lock_slowpath+0x30/0xb0
LR [c01b3aa4] mdiobus_read+0x38/0x68
Call Trace:
[cf039e20] [ffeb0000] 0xffeb0000 (unreliable)
[cf039e50] [c01b3aa4] mdiobus_read+0x38/0x68
[cf039e70] [c01b2af0] get_phy_id+0x24/0x70
[cf039e90] [c01b4128] fsl_pq_mdio_probe+0x364/0x414
[cf039ec0] [c0195050] platform_drv_probe+0x20/0x30
[cf039ed0] [c0193a70] driver_probe_device+0xc8/0x170
[cf039ef0] [c0193b88] __driver_attach+0x70/0x98
[cf039f10] [c019294c] bus_for_each_dev+0x60/0x90
[cf039f40] [c0193cc8] driver_attach+0x24/0x34
[cf039f50] [c0192f88] bus_add_driver+0xbc/0x230
[cf039f70] [c0194594] driver_register+0xb8/0x13c
[cf039f90] [c0195b40] platform_driver_register+0x6c/0x7c
[cf039fa0] [c03e433c] fsl_pq_mdio_init+0x18/0x28
[cf039fb0] [c03ce824] do_one_initcall+0xdc/0x1b4
[cf039fe0] [c03ce984] kernel_init+0x88/0x118
[cf039ff0] [c000bd5c] kernel_thread+0x4c/0x68
Instruction dump:
9421ffd0 7c0802a6 81230008 bf61001c 3bc30004 7c7f1b78 90010034 38010008
7c5c1378 90030008 93c10008 9121000c
3800ffff 90410010 7d201828
Fix this by moving the of_mdiobus_register() call earlier.
Cc: Andy Fleming <afleming@freescale.com>
Signed-off-by: Baruch Siach <baruch@tkos.co.il>
---
drivers/net/ethernet/freescale/fsl_pq_mdio.c | 14 +++++++-------
1 files changed, 7 insertions(+), 7 deletions(-)
diff --git a/drivers/net/ethernet/freescale/fsl_pq_mdio.c b/drivers/net/ethernet/freescale/fsl_pq_mdio.c
index 52f4e8a..e17fd2f 100644
--- a/drivers/net/ethernet/freescale/fsl_pq_mdio.c
+++ b/drivers/net/ethernet/freescale/fsl_pq_mdio.c
@@ -385,6 +385,13 @@ static int fsl_pq_mdio_probe(struct platform_device *ofdev)
tbiaddr = *prop;
}
+ err = of_mdiobus_register(new_bus, np);
+ if (err) {
+ printk (KERN_ERR "%s: Cannot register as MDIO bus\n",
+ new_bus->name);
+ goto err_free_irqs;
+ }
+
if (tbiaddr == -1) {
out_be32(tbipa, 0);
@@ -403,13 +410,6 @@ static int fsl_pq_mdio_probe(struct platform_device *ofdev)
out_be32(tbipa, tbiaddr);
- err = of_mdiobus_register(new_bus, np);
- if (err) {
- printk (KERN_ERR "%s: Cannot register as MDIO bus\n",
- new_bus->name);
- goto err_free_irqs;
- }
-
return 0;
err_free_irqs:
--
1.7.7.1
^ permalink raw reply related
* [PATCH v4] powerpc: 85xx: separate e500 from e500mc
From: Baruch Siach @ 2011-11-08 7:31 UTC (permalink / raw)
To: linuxppc-dev; +Cc: Scott Wood, Baruch Siach, Timur Tabi
CONFIG_E500MC breaks e500/e500v2 systems. It defines L1_CACHE_SHIFT to 6, thus
breaking clear_pages(), probably others too.
This patch adds a new "Processor Type" entry for e500mc, and makes e500 systems
depend on PPC_E500_V1_V2.
Cc: Kumar Gala <galak@kernel.crashing.org>
Signed-off-by: Baruch Siach <baruch@tkos.co.il>
---
Changes from v3:
* Rebase on 3.2-rc1 (add P3060_QDS)
Changes from v2:
* s/CONFIG_PPC_E500/CONFIG_PPC_E500_V1_V2/ as suggested by Scott Wood
Changes from v1:
* Rebase on 3.1-rc1
* Remove the list of processor families from the PPC_E500 and
PPC_E500MC options description. The P20xx can be either e500v2 or
e500mc.
arch/powerpc/platforms/85xx/Kconfig | 14 +++++++++-----
arch/powerpc/platforms/Kconfig.cputype | 27 +++++++++++++++------------
2 files changed, 24 insertions(+), 17 deletions(-)
diff --git a/arch/powerpc/platforms/85xx/Kconfig b/arch/powerpc/platforms/85xx/Kconfig
index 45023e2..cfa2bc9 100644
--- a/arch/powerpc/platforms/85xx/Kconfig
+++ b/arch/powerpc/platforms/85xx/Kconfig
@@ -13,6 +13,8 @@ if FSL_SOC_BOOKE
if PPC32
+if PPC_E500_V1_V2
+
config MPC8540_ADS
bool "Freescale MPC8540 ADS"
select DEFAULT_UIMAGE
@@ -171,10 +173,13 @@ config SBC8560
help
This option enables support for the Wind River SBC8560 board
+endif # PPC_E500_V1_V2
+
+if PPC_E500MC
+
config P2041_RDB
bool "Freescale P2041 RDB"
select DEFAULT_UIMAGE
- select PPC_E500MC
select PHYS_64BIT
select SWIOTLB
select ARCH_REQUIRE_GPIOLIB
@@ -187,7 +192,6 @@ config P2041_RDB
config P3041_DS
bool "Freescale P3041 DS"
select DEFAULT_UIMAGE
- select PPC_E500MC
select PHYS_64BIT
select SWIOTLB
select ARCH_REQUIRE_GPIOLIB
@@ -200,7 +204,6 @@ config P3041_DS
config P3060_QDS
bool "Freescale P3060 QDS"
select DEFAULT_UIMAGE
- select PPC_E500MC
select PHYS_64BIT
select SWIOTLB
select MPC8xxx_GPIO
@@ -212,7 +215,6 @@ config P3060_QDS
config P4080_DS
bool "Freescale P4080 DS"
select DEFAULT_UIMAGE
- select PPC_E500MC
select PHYS_64BIT
select SWIOTLB
select ARCH_REQUIRE_GPIOLIB
@@ -222,13 +224,15 @@ config P4080_DS
help
This option enables support for the P4080 DS board
+endif # PPC_E500MC
+
endif # PPC32
config P5020_DS
bool "Freescale P5020 DS"
+ depends on PPC_E500MC
select DEFAULT_UIMAGE
select E500
- select PPC_E500MC
select PHYS_64BIT
select SWIOTLB
select ARCH_REQUIRE_GPIOLIB
diff --git a/arch/powerpc/platforms/Kconfig.cputype b/arch/powerpc/platforms/Kconfig.cputype
index fbecae0..e08d1e3 100644
--- a/arch/powerpc/platforms/Kconfig.cputype
+++ b/arch/powerpc/platforms/Kconfig.cputype
@@ -10,13 +10,13 @@ choice
prompt "Processor Type"
depends on PPC32
help
- There are five families of 32 bit PowerPC chips supported.
+ There are six families of 32 bit PowerPC chips supported.
The most common ones are the desktop and server CPUs (601, 603,
604, 740, 750, 74xx) CPUs from Freescale and IBM, with their
embedded 512x/52xx/82xx/83xx/86xx counterparts.
- The other embeeded parts, namely 4xx, 8xx, e200 (55xx) and e500
- (85xx) each form a family of their own that is not compatible
- with the others.
+ The other embedded parts, namely 4xx, 8xx, e200 (55xx), e500
+ (85xx), and e500mc each form a family of their own that is not
+ compatible with the others.
If unsure, select 52xx/6xx/7xx/74xx/82xx/83xx/86xx.
@@ -24,10 +24,15 @@ config PPC_BOOK3S_32
bool "512x/52xx/6xx/7xx/74xx/82xx/83xx/86xx"
select PPC_FPU
-config PPC_85xx
- bool "Freescale 85xx"
+config PPC_E500_V1_V2
+ bool "Freescale e500v1/e500v2"
+ select PPC_85xx
select E500
+config PPC_E500MC
+ bool "Freescale e500mc/e5500"
+ select PPC_85xx
+
config PPC_8xx
bool "Freescale 8xx"
select FSL_SOC
@@ -129,15 +134,13 @@ config TUNE_CELL
config 8xx
bool
-config E500
+config PPC_85xx
+ bool
select FSL_EMB_PERFMON
select PPC_FSL_BOOK3E
- bool
-config PPC_E500MC
- bool "e500mc Support"
- select PPC_FPU
- depends on E500
+config E500
+ bool
config PPC_FPU
bool
--
1.7.7.1
^ permalink raw reply related
* RE: [PATCH 1/7] powerpc/85xx: re-enable timebase sync disabled by KEXEC patch
From: Li Yang-R58472 @ 2011-11-08 9:06 UTC (permalink / raw)
To: Wood Scott-B07421, Zhao Chenhui-B35336; +Cc: linuxppc-dev@lists.ozlabs.org
In-Reply-To: <4EB421FD.6010805@freescale.com>
>-----Original Message-----
>From: linuxppc-dev-bounces+leoli=3Dfreescale.com@lists.ozlabs.org
>[mailto:linuxppc-dev-bounces+leoli=3Dfreescale.com@lists.ozlabs.org] On
>Behalf Of Scott Wood
>Sent: Saturday, November 05, 2011 1:34 AM
>To: Zhao Chenhui-B35336
>Cc: linuxppc-dev@lists.ozlabs.org
>Subject: Re: [PATCH 1/7] powerpc/85xx: re-enable timebase sync disabled by
>KEXEC patch
>
>On 11/04/2011 07:29 AM, Zhao Chenhui wrote:
>> From: Li Yang <leoli@freescale.com>
>>
>> The timebase sync is not only necessary when using KEXEC. It should also
>> be used by normal boot up and cpu hotplug. Remove the ifdef added by
>> the KEXEC patch.
>
>The KEXEC patch didn't just add the ifdef, it also added the initializers:
Yes. But the code suggests that the timebase synchronization is only neces=
sary for KEXEC, but it turns out that sleep/wakeup also need it. Maybe the=
description of the patch need to be changed as KEXEC is not to be blamed.
>
>> @@ -105,8 +107,64 @@ smp_85xx_setup_cpu(int cpu_nr)
>>
>> struct smp_ops_t smp_85xx_ops =3D {
>> .kick_cpu =3D smp_85xx_kick_cpu,
>> +#ifdef CONFIG_KEXEC
>> + .give_timebase =3D smp_generic_give_timebase,
>> + .take_timebase =3D smp_generic_take_timebase,
>> +#endif
>> };
>
>U-Boot synchronizes the timebase on 85xx. With what chip and U-Boot
>version are you seeing this not happen?
I'm curious why don't we make it happen in kernel as we are against adding =
dependency to the bootloader? Other architectures don't have this dependen=
cy, it will be better if we don't add this dependency either IMO.
>
>If you are seeing only a small (around one tick) difference, make sure
>you're running a U-Boot that has this commit:
>
>> commit 7afc45ad7d9493208d89072cbb78a5bfc8034b59
>> Author: Kumar Gala <galak@kernel.crashing.org>
>> Date: Sun Mar 13 10:55:53 2011 -0500
>>
>> powerpc/85xx: Fix synchronization of timebase on MP boot
>>
>> There is a small ordering issue in the master core in that we need
>to
>> make sure the disabling of the timebase in the SoC is visible before
>we
>> set the value to 0. We can simply just read back the value to
>> synchronizatize the write, before we set TB to 0.
>>
>> Reported-by: Dan Hettena
>> Tested-by: Dan Hettena
>> Signed-off-by: Kumar Gala <galak@kernel.crashing.org>
>
>
>-Scott
>
>_______________________________________________
>Linuxppc-dev mailing list
>Linuxppc-dev@lists.ozlabs.org
>https://lists.ozlabs.org/listinfo/linuxppc-dev
^ permalink raw reply
* RE: [PATCH 2/7] powerpc/85xx: add HOTPLUG_CPU support
From: Li Yang-R58472 @ 2011-11-08 10:05 UTC (permalink / raw)
To: Wood Scott-B07421, Zhao Chenhui-B35336; +Cc: linuxppc-dev@lists.ozlabs.org
In-Reply-To: <4EB4305C.6030303@freescale.com>
>Subject: Re: [PATCH 2/7] powerpc/85xx: add HOTPLUG_CPU support
>
>On 11/04/2011 07:31 AM, Zhao Chenhui wrote:
>> From: Li Yang <leoli@freescale.com>
>>
>> Add support to disable and re-enable individual cores at runtime
>> on MPC85xx/QorIQ SMP machines. Currently support e500 core.
>>
>> MPC85xx machines use ePAPR spin-table in boot page for CPU kick-off.
>> This patch uses the boot page from bootloader to boot core at runtime.
>> It supports 32-bit and 36-bit physical address.
>
>Note that there is no guarantee that the bootloader can handle you
>resetting a core. In ePAPR the spin table is a one-time release
>mechanism, not a core reset mechanism. If this has a U-Boot dependency,
>document that.
Actually we suggested to add a spin table in kernel so that we won't have t=
he dependency on u-boot. But there seems to be some opposite opinion in th=
e internal discussion. I personally prefer to remove the u-boot dependency=
and add the mechanism in kernel.
>
>> #ifdef CONFIG_SMP
>> /* When we get here, r24 needs to hold the CPU # */
>> .globl __secondary_start
>> diff --git a/arch/powerpc/kernel/smp.c b/arch/powerpc/kernel/smp.c
>> index 7bf2187..12a54f0 100644
>> --- a/arch/powerpc/kernel/smp.c
>> +++ b/arch/powerpc/kernel/smp.c
>> @@ -381,8 +381,14 @@ void generic_cpu_die(unsigned int cpu)
>>
>> for (i =3D 0; i < 100; i++) {
>> smp_rmb();
>> - if (per_cpu(cpu_state, cpu) =3D=3D CPU_DEAD)
>> + if (per_cpu(cpu_state, cpu) =3D=3D CPU_DEAD) {
>> + /*
>> + * After another core sets cpu_state to CPU_DEAD,
>> + * it needs some time to die.
>> + */
>> + msleep(10);
>> return;
>> + }
>> msleep(100);
>
>It would be better to do this as a call into platform-specific code than
>can check registers to determine whether the core has checked out (in
>our case, whether it has entered nap) -- or to do a suitable delay for
>that platform if this isn't possible.
It will be easier if we can add a platform specific cpu_die instead of usin=
g the generic one?
>
>> diff --git a/arch/powerpc/platforms/85xx/smp.c
>b/arch/powerpc/platforms/85xx/smp.c
>> index 9b0de9c..5a54fc1 100644
>> --- a/arch/powerpc/platforms/85xx/smp.c
>> +++ b/arch/powerpc/platforms/85xx/smp.c
>> @@ -17,6 +17,7 @@
>> #include <linux/of.h>
>> #include <linux/kexec.h>
>> #include <linux/highmem.h>
>> +#include <linux/cpu.h>
>>
>> #include <asm/machdep.h>
>> #include <asm/pgtable.h>
>> @@ -30,26 +31,141 @@
>>
>> extern void __early_start(void);
>>
>> -#define BOOT_ENTRY_ADDR_UPPER 0
>> -#define BOOT_ENTRY_ADDR_LOWER 1
>> -#define BOOT_ENTRY_R3_UPPER 2
>> -#define BOOT_ENTRY_R3_LOWER 3
>> -#define BOOT_ENTRY_RESV 4
>> -#define BOOT_ENTRY_PIR 5
>> -#define BOOT_ENTRY_R6_UPPER 6
>> -#define BOOT_ENTRY_R6_LOWER 7
>> -#define NUM_BOOT_ENTRY 8
>> -#define SIZE_BOOT_ENTRY (NUM_BOOT_ENTRY * sizeof(u32))
>> -
>> -static int __init
>> -smp_85xx_kick_cpu(int nr)
>> +#define MPC85xx_BPTR_OFF 0x00020
>> +#define MPC85xx_BPTR_EN 0x80000000
>> +#define MPC85xx_BPTR_BOOT_PAGE_MASK 0x00ffffff
>> +#define MPC85xx_BRR_OFF 0xe0e4
>> +#define MPC85xx_ECM_EEBPCR_OFF 0x01010
>> +#define MPC85xx_PIC_PIR_OFF 0x41090
>> +
>> +struct epapr_entry {
>
>ePAPR is more than just the spin table. Call it something like
>epapr_spin_table.
>
>> + u32 addr_h;
>> + u32 addr_l;
>> + u32 r3_h;
>> + u32 r3_l;
>> + u32 reserved;
>> + u32 pir;
>> + u32 r6_h;
>> + u32 r6_l;
>> +};
>
>Get rid of r6, it is not part of the ePAPR spin table.
Agree.
>
>> +static int is_corenet;
>> +static void __cpuinit smp_85xx_setup_cpu(int cpu_nr);
>> +
>> +#if defined(CONFIG_HOTPLUG_CPU) && defined(CONFIG_PPC32)
>
>Why PPC32?
Not sure if it is the same for e5500. E5500 support will be verified later=
.
>
>> +extern void flush_disable_L1(void);
>
>If this isn't already in a header file, put it in one.
>
>> +static void __cpuinit smp_85xx_mach_cpu_die(void)
>> +{
>> + unsigned int cpu =3D smp_processor_id();
>> + register u32 tmp;
>> +
>> + local_irq_disable();
>> + idle_task_exit();
>> + generic_set_cpu_dead(cpu);
>> + smp_wmb();
>> +
>> + mtspr(SPRN_TSR, TSR_ENW | TSR_WIS | TSR_DIS | TSR_FIS);
>> + mtspr(SPRN_TCR, 0);
>
>If clearing TSR matters at all (I'm not sure that it does), first clear
>TCR, then TSR.
>
>> + flush_disable_L1();
>
>You'll also need to take down L2 on e500mc.
Right. E500mc support is beyond this patch series. We will work on it aft=
er the e500v2 support is finalized.
>
>> + tmp =3D 0;
>> + if (cpu_has_feature(CPU_FTR_CAN_NAP))
>> + tmp =3D HID0_NAP;
>> + else if (cpu_has_feature(CPU_FTR_CAN_DOZE))
>> + tmp =3D HID0_DOZE;
>
>Those FTR bits are for what we can do in idle, and can be cleared if the
>user sets CONFIG_BDI_SWITCH.
It is powersave_nap variable shows what we can do in idle. I think it's co=
rrect to use the CPU_FTR_CAN_* macro as CPU capability.
>
>On 85xx we always want to nap here, and at least on e500mc it seems to
>be mandatory. From the p5020 RM description of PIR:
>
>> For proper system operation, a core should be reset in this way only if
>the core is already in nap or sleep
>> state. Because a core in either state cannot perform the necessary write
>to cause a hard reset, a core cannot
>> put itself into hard reset.
>
>Note that on e500mc we don't use HID0/MSR_WE to enter nap, we need to
>hit the CCSR register. And unless you can somehow guarantee that only
>one core at a time is doing this, we'll need some oher core to actually
>place us in nap (since once we enter nap we're not running so can't
>release a lock).
>
>> + if (tmp) {
>> + tmp |=3D mfspr(SPRN_HID0) & ~(HID0_DOZE|HID0_NAP|HID0_SLEEP);
>> +
>> + smp_mb();
>
>smp_mb()? This is always SMP... It looks like you meant some specific
>sync instruction as part of an architected sequence, so just use that.
>
>> + isync();
>> + mtspr(SPRN_HID0, tmp);
>> + isync();
>> +
>> + tmp =3D mfmsr();
>> + tmp |=3D MSR_WE;
>> + smp_mb();
>> + mtmsr(tmp);
>> + isync();
>> + }
>> +
>> + for (;;);
>> +}
>> +
>> +static void __cpuinit smp_85xx_reset_core(int nr)
>> +{
>> + __iomem u32 *vaddr, *pir_vaddr;
>> + u32 val, cpu_mask;
>> +
>> + /* If CoreNet platform, use BRR as release register. */
>> + if (is_corenet) {
>> + cpu_mask =3D 1 << nr;
>> + vaddr =3D ioremap(get_immrbase() + MPC85xx_BRR_OFF, 4);
>> + } else {
>> + cpu_mask =3D 1 << (24 + nr);
>> + vaddr =3D ioremap(get_immrbase() + MPC85xx_ECM_EEBPCR_OFF, 4);
>> + }
>
>Please use the device tree node, not get_immrbase().
The get_immrbase() implementation uses the device tree node.
>
>> + val =3D in_be32(vaddr);
>> + if (!(val & cpu_mask)) {
>> + out_be32(vaddr, val | cpu_mask);
>> + } else {
>> + /* reset core */
>> + pir_vaddr =3D ioremap(get_immrbase() + MPC85xx_PIC_PIR_OFF, 4);
>> + val =3D in_be32(pir_vaddr);
>> + /* reset assert */
>> + val |=3D (1 << nr);
>> + out_be32(pir_vaddr, val);
>
>Use setbits32().
>
>> + val =3D in_be32(pir_vaddr);
>> + val &=3D ~(1 << nr);
>> + /* reset negate */
>> + out_be32(pir_vaddr, val);
>
>clrbits32().
>
>Is there any amount of time we need to keep the reset pin asserted?
We don't know, but it's already working without any wait.
>
>> + iounmap(pir_vaddr);
>> + }
>> + iounmap(vaddr);
>> +}
>> +
>> +static int __cpuinit smp_85xx_map_bootpg(u32 page)
>> +{
>> + __iomem u32 *bootpg_ptr;
>> + u32 bptr;
>> +
>> + /* Get the BPTR */
>> + bootpg_ptr =3D ioremap(get_immrbase() + MPC85xx_BPTR_OFF, 4);
>> +
>> + /* Set the BPTR to the secondary boot page */
>> + bptr =3D MPC85xx_BPTR_EN | (page & MPC85xx_BPTR_BOOT_PAGE_MASK);
>> + out_be32(bootpg_ptr, bptr);
>> +
>> + iounmap(bootpg_ptr);
>> + return 0;
>> +}
>
>Shouldn't the boot page already be set by U-Boot?
The register should be lost after a deep sleep. Better to do it again.
>
>> +static int __cpuinit smp_85xx_kick_cpu(int nr)
>> {
>> unsigned long flags;
>> const u64 *cpu_rel_addr;
>> - __iomem u32 *bptr_vaddr;
>> + __iomem struct epapr_entry *epapr;
>> struct device_node *np;
>> - int n =3D 0;
>> + int n =3D 0, hw_cpu =3D get_hard_smp_processor_id(nr);
>> int ioremappable;
>> + int ret =3D 0;
>>
>> WARN_ON (nr < 0 || nr >=3D NR_CPUS);
>>
>> @@ -73,46 +189,79 @@ smp_85xx_kick_cpu(int nr)
>>
>> /* Map the spin table */
>> if (ioremappable)
>> - bptr_vaddr =3D ioremap(*cpu_rel_addr, SIZE_BOOT_ENTRY);
>> + epapr =3D ioremap(*cpu_rel_addr, sizeof(struct epapr_entry));
>> else
>> - bptr_vaddr =3D phys_to_virt(*cpu_rel_addr);
>> + epapr =3D phys_to_virt(*cpu_rel_addr);
>>
>> local_irq_save(flags);
>>
>> - out_be32(bptr_vaddr + BOOT_ENTRY_PIR, nr);
>> + out_be32(&epapr->pir, hw_cpu);
>> #ifdef CONFIG_PPC32
>> - out_be32(bptr_vaddr + BOOT_ENTRY_ADDR_LOWER, __pa(__early_start));
>> +#ifdef CONFIG_HOTPLUG_CPU
>> + if (system_state =3D=3D SYSTEM_RUNNING) {
>> + out_be32(&epapr->addr_l, 0);
>> + smp_85xx_map_bootpg((u32)(*cpu_rel_addr >> PAGE_SHIFT));
>
>Why is this inside PPC32?
Not tested on 64-bit yet. Might require a different implementation on PPC6=
4.
>
>> + smp_85xx_reset_core(hw_cpu);
>> +
>> + /* wait until core is ready... */
>> + n =3D 0;
>> + while ((in_be32(&epapr->addr_l) !=3D 1) && (++n < 1000))
>> + udelay(100);
>> + if (n > 1000) {
>
>if (n =3D=3D 1000)
>
>or
>
>if (in_be32(&epapr->addr_l) !=3D 1)
>
>> + pr_err("timeout waiting for core%d to reset\n", nr);
>> + ret =3D -ENOENT;
>> + goto out;
>> + }
>> + /* clear the acknowledge status */
>> + __secondary_hold_acknowledge =3D -1;
>> +
>> + smp_85xx_unmap_bootpg();
>> + }
>> +#endif
>> + out_be32(&epapr->addr_l, __pa(__early_start));
>>
>> if (!ioremappable)
>> - flush_dcache_range((ulong)bptr_vaddr,
>> - (ulong)(bptr_vaddr + SIZE_BOOT_ENTRY));
>> + flush_dcache_range((ulong)epapr,
>> + (ulong)epapr + sizeof(struct epapr_entry));
>>
>> /* Wait a bit for the CPU to ack. */
>> - while ((__secondary_hold_acknowledge !=3D nr) && (++n < 1000))
>> + n =3D 0;
>> + while ((__secondary_hold_acknowledge !=3D hw_cpu) && (++n < 1000))
>> mdelay(1);
>> + if (n > 1000) {
>
>if (n =3D=3D 1000)
>
>or
>
>if (__secondary_hold_acknowledge !=3D hw_cpu)
>
>> + pr_err("timeout waiting for core%d to ack\n", nr);
>
>pr_err("%s: timeout waiting for core %d to ack\n", __func__, nr);
>
>Likewise elsewhere. Maybe also/instead mention hw_cpu.
>
>> + ret =3D -ENOENT;
>> + goto out;
>> + }
>> +out:
>> #else
>> smp_generic_kick_cpu(nr);
>>
>> - out_be64((u64 *)(bptr_vaddr + BOOT_ENTRY_ADDR_UPPER),
>> + out_be64((u64 *)(&epapr->addr_h),
>> __pa((u64)*((unsigned long long *)
>generic_secondary_smp_init)));
>>
>> if (!ioremappable)
>> - flush_dcache_range((ulong)bptr_vaddr,
>> - (ulong)(bptr_vaddr + SIZE_BOOT_ENTRY));
>> + flush_dcache_range((ulong)epapr,
>> + (ulong)epapr + sizeof(struct epapr_entry));
>
>We don't wait for the core to come up on 64-bit?
Not sure about it. But at least the normal boot up should be tested on P50=
20, right?
>
>> @@ -228,14 +376,18 @@ void __init mpc85xx_smp_init(void)
>> {
>> struct device_node *np;
>>
>> - smp_85xx_ops.setup_cpu =3D smp_85xx_setup_cpu;
>> -
>> np =3D of_find_node_by_type(NULL, "open-pic");
>> if (np) {
>> smp_85xx_ops.probe =3D smp_mpic_probe;
>> smp_85xx_ops.message_pass =3D smp_mpic_message_pass;
>> }
>>
>> + /* Check if the chip is based on CoreNet platform. */
>> + is_corenet =3D 0;
>> + np =3D of_find_compatible_node(NULL, NULL, "fsl,qoriq-device-config-
>1.0");
>> + if (np)
>> + is_corenet =3D 1;
>
>Please also check for the non-corenet guts node. If you don't find
>either, disable the mechanism -- you're probably running under a
>hypervisor.
Ok.
- Leo
^ permalink raw reply
* RE: [PATCH 3/7] powerpc/85xx: add sleep and deep sleep support
From: Li Yang-R58472 @ 2011-11-08 10:27 UTC (permalink / raw)
To: Felix Radensky, Zhao Chenhui-B35336,
linuxppc-dev@lists.ozlabs.org
In-Reply-To: <4EB4229C.1050403@embedded-sol.com>
>To: Zhao Chenhui-B35336; linuxppc-dev@lists.ozlabs.org
>Subject: Re: [PATCH 3/7] powerpc/85xx: add sleep and deep sleep support
>
>Hi Zhao,
>
>From: Li Yang <leoli at freescale.com>
>
>Some Freescale chips like MPC8536 and P1022 has deep sleep PM mode in
>addtion to the sleep PM mode.
>
>In sleep PM mode, the clocks of e500 core and unused IP blocks is turned
>off. IP blocks which are allowed to wake up the processor are still
>running
>
>While in deep sleep PM mode, additionally, the power supply is removed
>from e500 core and most IP blocks. Only the blocks needed to wake up the
>chip out of deep sleep are ON.
>
>This patch supports 32-bit and 36-bit address space.
>
>The deep sleep mode is equal to the Suspend-to-RAM state of Linux Power
>Management.
>
>Command to enter deep sleep mode.
> echo mem > /sys/power/state
>
>
>Thanks a lot for bringing this code to mainline. I was recently involved
>in enabling deep sleep on a custom P1022 board, and would like to make
>some remarks based on this experience.
>
>1. I think 85xx deep sleep code would be more complete if you also port
>FSL
>=A0=A0=A0 BSP code that saves eLBC configuration before entering deep slee=
p and
>=A0=A0=A0 restores it afterwards. Otherwise all eLBC customization done by=
u-
>boot is lost.
Thanks for the comment. That work is also being considered for upstream, b=
ut not in this series.
>
>2. You should implement fsl_deep_sleep() routine for 85xx. The default
>implementation
>=A0=A0=A0 in include/linux/fsl_devices.h always returns 0. The routine is =
used
>by FSL USB host
>=A0=A0=A0 driver, drivers/usb/host/ehci-fsl.c to restore USB hardware stat=
e
>after deep sleep.
>=A0=A0=A0 With default implementation USB is dead on 85xx after deep sleep=
if
>USB PHY is
>=A0=A0=A0 powered down completely.
Added to the to-do list. Thanks.
- Leo
^ permalink raw reply
* RE: [PATCH 3/7] powerpc/85xx: add sleep and deep sleep support
From: Li Yang-R58472 @ 2011-11-08 10:32 UTC (permalink / raw)
To: Wood Scott-B07421, Zhao Chenhui-B35336; +Cc: linuxppc-dev@lists.ozlabs.org
In-Reply-To: <4EB432C1.1000601@freescale.com>
>Subject: Re: [PATCH 3/7] powerpc/85xx: add sleep and deep sleep support
>
>On 11/04/2011 07:33 AM, Zhao Chenhui wrote:
>> +/* Cast the ccsrbar to 64-bit parameter so that the assembly
>> + * code can be compatible with both 32-bit & 36-bit */
>> +extern void mpc85xx_enter_deep_sleep(u64 ccsrbar, u32 powmgtreq);
>
>/*
> * Please use proper
> * Linux multi-line comment format.
> */
>
>> static int pmc_suspend_enter(suspend_state_t state)
>> {
>> int ret;
>> + u32 powmgtreq =3D 0x00500000;
>
>Where does this 0x00500000 come from? Please symbolically define
>individual bits.
>
>The comment in the asm code says it should be 0x00100000, BTW.
I think we should get rid of the powmgtreq argument, as we don't support mu=
ltiple modes for mpc85xx_enter_deep_sleep() now.
>
>> +
>> + switch (state) {
>> + case PM_SUSPEND_MEM:
>> +#ifdef CONFIG_SPE
>> + enable_kernel_spe();
>> +#endif
>
>Should comment that currently only e500v2 hardware supports deep sleep
>-- else we'd need to save normal FP here.
>
>> + pr_debug("Entering deep sleep\n");
>> +
>> + local_irq_disable();
>> + mpc85xx_enter_deep_sleep(get_immrbase(),
>> + powmgtreq);
>> + pr_debug("Resumed from deep sleep\n");
>> +
>> + return 0;
>> +
>> + /* else fall-through */
>> + case PM_SUSPEND_STANDBY:
>
>What fall-through? You just returned.
>
>> + }
>>
>> - /* Upon resume, wait for SLP bit to be clear. */
>> - ret =3D spin_event_timeout((in_be32(&pmc_regs->pmcsr) & PMCSR_SLP) =3D=
=3D
>0,
>> - 10000, 10) ? 0 : -ETIMEDOUT;
>> - if (ret)
>> - dev_err(pmc_dev, "tired waiting for SLP bit to clear\n");
>> - return ret;
>> }
>
>Remove that blank line as well.
>
>> @@ -58,13 +101,23 @@ static const struct platform_suspend_ops
>pmc_suspend_ops =3D {
>> .enter =3D pmc_suspend_enter,
>> };
>>
>> -static int pmc_probe(struct platform_device *ofdev)
>> +static int pmc_probe(struct platform_device *pdev)
>> {
>> - pmc_regs =3D of_iomap(ofdev->dev.of_node, 0);
>> + struct device_node *np =3D pdev->dev.of_node;
>> +
>> + pmc_regs =3D of_iomap(pdev->dev.of_node, 0);
>> if (!pmc_regs)
>> return -ENOMEM;
>>
>> - pmc_dev =3D &ofdev->dev;
>> + has_deep_sleep =3D 0;
>> + if (of_device_is_compatible(np, "fsl,mpc8536-pmc"))
>> + has_deep_sleep =3D 1;
>> +
>> + has_lossless =3D 0;
>> + if (of_device_is_compatible(np, "fsl,p1022-pmc"))
>> + has_lossless =3D 1;
>> +
>
>You never use has_lossless.
It will be used in the later patch in the series.
- Leo
^ permalink raw reply
* RE: [PATCH 5/7] fsl_pmc: update device bindings
From: Li Yang-R58472 @ 2011-11-08 10:56 UTC (permalink / raw)
To: Wood Scott-B07421, Zhao Chenhui-B35336; +Cc: linuxppc-dev@lists.ozlabs.org
In-Reply-To: <4EB4456F.9020005@freescale.com>
>-----Original Message-----
>From: linuxppc-dev-bounces+leoli=3Dfreescale.com@lists.ozlabs.org
>[mailto:linuxppc-dev-bounces+leoli=3Dfreescale.com@lists.ozlabs.org] On
>Behalf Of Scott Wood
>Sent: Saturday, November 05, 2011 4:05 AM
>To: Zhao Chenhui-B35336
>Cc: linuxppc-dev@lists.ozlabs.org
>Subject: Re: [PATCH 5/7] fsl_pmc: update device bindings
>
>On 11/04/2011 07:36 AM, Zhao Chenhui wrote:
>> From: Li Yang <leoli@freescale.com>
>>
>> Signed-off-by: Li Yang <leoli@freescale.com>
>> ---
>> .../devicetree/bindings/powerpc/fsl/pmc.txt | 63 +++++++++++--
>------
>> 1 files changed, 36 insertions(+), 27 deletions(-)
>>
>> diff --git a/Documentation/devicetree/bindings/powerpc/fsl/pmc.txt
>b/Documentation/devicetree/bindings/powerpc/fsl/pmc.txt
>> index 07256b7..d84b4f8 100644
>> --- a/Documentation/devicetree/bindings/powerpc/fsl/pmc.txt
>> +++ b/Documentation/devicetree/bindings/powerpc/fsl/pmc.txt
>> @@ -9,22 +9,27 @@ Properties:
>>
>> "fsl,mpc8548-pmc" should be listed for any chip whose PMC is
>> compatible. "fsl,mpc8536-pmc" should also be listed for any chip
>> - whose PMC is compatible, and implies deep-sleep capability.
>> + whose PMC is compatible, and implies deep-sleep capability and
>> + wake on user defined packet(wakeup on ARP).
>
>Why does the PMC care? This is an ethernet controller feature, the PMC
>is just keeping the wakeup-relevant parts of the ethernet controller
>alive (whatever they happen to be).
>
>Do we have any chips that have ethernet controller support for wake on
>user-defined packet, but a sleep mode that doesn't let it be used?
I think it is more a PMC feature cause Ethernet controller on many SoCs hav=
e the filer feature, but only very limited SoCs can support using it as a w=
ake-up source. The differences should be mostly in the PM controller block=
.
Also the wake on user-defined packet feature was never mentioned in the Eth=
ernet controller part of UM.
>
>BTW, please remove fsl,mpc8536-pmc from the p1023rds device tree -- it
>was wrong before (no deep sleep, though it does appear to have jog
>mode...), and is even more wrong with this provision (it has a different
>ethernet controller).
>
>> + "fsl,p1022-pmc" should be listed for any chip whose PMC is
>> + compatible, and implies lossless Ethernet capability during sleep.
>>
>> "fsl,mpc8641d-pmc" should be listed for any chip whose PMC is
>> compatible; all statements below that apply to "fsl,mpc8548-pmc" also
>> apply to "fsl,mpc8641d-pmc".
>>
>> Compatibility does not include bit assignments in SCCR/PMCDR/DEVDISR;
>these
>> - bit assignments are indicated via the sleep specifier in each
>device's
>> - sleep property.
>> + bit assignments are indicated via the clock nodes. Device which has
>a
>> + controllable clock source should have a "clk-handle" property
>pointing
>> + to the clock node.
>
>Do we have any code to use this?
Yes, in another patch in the series.
>
>Normally that shouldn't matter, but we already an unused binding for
>this. :-)
>
>Please provide rationale for doing it this way. Ideally it should
>probably use whatever http://devicetree.org/ClockBindings ends up being.
I have looked into that binding. The binding was primarily defined for the=
Linux clock API which is not same as what we are doing here(set wakeup sou=
rce). If in the future the clock API also covers wakeup related features, =
we can change to use it.
- Leo
^ permalink raw reply
* Re: [PATCH RFC 0/3] Support multiple VirtioConsoles.
From: Amit Shah @ 2011-11-08 11:00 UTC (permalink / raw)
To: Miche Baker-Harvey
Cc: Stephen Rothwell, Greg Kroah-Hartman, Konrad Rzeszutek Wilk,
Rusty Russell, linux-kernel, Mike Waychison, xen-devel,
Anton Blanchard, virtualization, ppc-dev
In-Reply-To: <20111102221905.9722.62090.stgit@miche.sea.corp.google.com>
On (Wed) 02 Nov 2011 [15:19:06], Miche Baker-Harvey wrote:
> This patchset applies to linux-next/next-20111102.
Did you forget to send out the patches? I don't see anything on any
of the lists nor my inbox.
Amit
^ permalink raw reply
* RE: [PATCH 7/7] gianfar: add support for wake-on-packet
From: Li Yang-R58472 @ 2011-11-08 11:07 UTC (permalink / raw)
To: Wood Scott-B07421, Zhao Chenhui-B35336
Cc: netdev@vger.kernel.org, linuxppc-dev@lists.ozlabs.org,
Fleming Andy-AFLEMING
In-Reply-To: <4EB4558A.8070105@freescale.com>
>-----Original Message-----
>From: linuxppc-dev-bounces+leoli=3Dfreescale.com@lists.ozlabs.org
>[mailto:linuxppc-dev-bounces+leoli=3Dfreescale.com@lists.ozlabs.org] On
>Behalf Of Scott Wood
>Sent: Saturday, November 05, 2011 5:14 AM
>To: Zhao Chenhui-B35336
>Cc: netdev@vger.kernel.org; linuxppc-dev@lists.ozlabs.org; Fleming Andy-
>AFLEMING
>Subject: Re: [PATCH 7/7] gianfar: add support for wake-on-packet
>
>On 11/04/2011 04:11 PM, Scott Wood wrote:
>> On 11/04/2011 07:40 AM, Zhao Chenhui wrote:
>>> static int gfar_suspend(struct device *dev) { @@ -1268,9 +1443,17
>>> @@ static int gfar_suspend(struct device *dev)
>>> struct gfar __iomem *regs =3D priv->gfargrp[0].regs;
>>> unsigned long flags;
>>> u32 tempval;
>>> -
>>> int magic_packet =3D priv->wol_en &&
>>> - (priv->device_flags & FSL_GIANFAR_DEV_HAS_MAGIC_PACKET);
>>> + (priv->wol_opts & GIANFAR_WOL_MAGIC);
>>> + int arp_packet =3D priv->wol_en &&
>>> + (priv->wol_opts & GIANFAR_WOL_ARP);
>>> +
>>> + if (arp_packet) {
>>> + pmc_enable_wake(priv->ofdev, PM_SUSPEND_MEM, 1);
>>> + pmc_enable_lossless(1);
>>> + gfar_arp_suspend(ndev);
>>> + return 0;
>>> + }
>>
>> How do we know this isn't standby?
>
>Or suspend to disk, for that matter?
There is nothing we can do for hibernation. The whole system is literally =
off.
- Leo
^ permalink raw reply
* RE: [PATCH 6/7] fsl_pmc: Add API to enable device as wakeup event source
From: Li Yang-R58472 @ 2011-11-08 11:12 UTC (permalink / raw)
To: Wood Scott-B07421, Zhao Chenhui-B35336
Cc: netdev@vger.kernel.org, linuxppc-dev@lists.ozlabs.org
In-Reply-To: <4EB455B1.8030009@freescale.com>
>-----Original Message-----
>From: linuxppc-dev-bounces+leoli=3Dfreescale.com@lists.ozlabs.org
>[mailto:linuxppc-dev-bounces+leoli=3Dfreescale.com@lists.ozlabs.org] On
>Behalf Of Scott Wood
>Sent: Saturday, November 05, 2011 5:14 AM
>To: Zhao Chenhui-B35336
>Cc: netdev@vger.kernel.org; linuxppc-dev@lists.ozlabs.org
>Subject: Re: [PATCH 6/7] fsl_pmc: Add API to enable device as wakeup event
>source
>
>On 11/04/2011 07:39 AM, Zhao Chenhui wrote:
>> @@ -45,6 +46,72 @@ static int has_lossless;
>> * code can be compatible with both 32-bit & 36-bit */ extern void
>> mpc85xx_enter_deep_sleep(u64 ccsrbar, u32 powmgtreq);
>>
>> +#ifdef CONFIG_FSL_PMC
>> +/**
>> + * pmc_enable_wake - enable OF device as wakeup event source
>> + * @pdev: platform device affected
>> + * @state: PM state from which device will issue wakeup events
>> + * @enable: True to enable event generation; false to disable
>> + *
>> + * This enables the device as a wakeup event source, or disables it.
>> + *
>> + * RETURN VALUE:
>> + * 0 is returned on success
>> + * -EINVAL is returned if device is not supposed to wake up the
>> +system
>> + * Error code depending on the platform is returned if both the
>> +platform and
>> + * the native mechanism fail to enable the generation of wake-up
>> +events */ int pmc_enable_wake(struct platform_device *pdev,
>> + suspend_state_t state, bool enable)
>
>"pmc" is too generic for a global function. If this can be either enable
>or disable, perhaps it should be something like mpc85xx_pmc_set_wake().
>
>> +{
>> + int ret =3D 0;
>> + struct device_node *clk_np;
>> + u32 *pmcdr_mask;
>> +
>> + if (!pmc_regs) {
>> + printk(KERN_WARNING "PMC is unavailable\n");
>> + return -ENOMEM;
>> + }
>
>-ENOMEM is not appropriate here, maybe -ENODEV?
>
>Should print __func__ so the user knows what's complaining.
>
>> + if (enable && !device_may_wakeup(&pdev->dev))
>> + return -EINVAL;
>> +
>> + clk_np =3D of_parse_phandle(pdev->dev.of_node, "clk-handle", 0);
>> + if (!clk_np)
>> + return -EINVAL;
>> +
>> + pmcdr_mask =3D (u32 *)of_get_property(clk_np, "fsl,pmcdr-mask", NULL);
>> + if (!pmcdr_mask) {
>> + ret =3D -EINVAL;
>> + goto out;
>> + }
>> +
>> + /* clear to enable clock in low power mode */
>> + if (enable)
>> + clrbits32(&pmc_regs->pmcdr, *pmcdr_mask);
>> + else
>> + setbits32(&pmc_regs->pmcdr, *pmcdr_mask);
>
>We should probably initialize PMCDR to all bits set (or at least all ones
>we know are valid) -- the default should be "not a wakeup source".
Ideally I agree with you. But currently we only have the UI of changing wa=
ke-up source for Ethernet device. Will do when we can change all of the de=
vices.
>
>> +/**
>> + * pmc_enable_lossless - enable lossless ethernet in low power mode
>> + * @enable: True to enable event generation; false to disable */
>> +void pmc_enable_lossless(int enable) {
>> + if (enable && has_lossless)
>> + setbits32(&pmc_regs->pmcsr, PMCSR_LOSSLESS);
>> + else
>> + clrbits32(&pmc_regs->pmcsr, PMCSR_LOSSLESS); }
>> +EXPORT_SYMBOL_GPL(pmc_enable_lossless);
>> +#endif
>
>Won't we overwrite this later?
You are right. Will remove the code that overwrite this.
- Leo
^ permalink raw reply
* RE: [PATCH 7/7] gianfar: add support for wake-on-packet
From: Li Yang-R58472 @ 2011-11-08 11:20 UTC (permalink / raw)
To: Wood Scott-B07421, Zhao Chenhui-B35336
Cc: netdev@vger.kernel.org, linuxppc-dev@lists.ozlabs.org,
Fleming Andy-AFLEMING
In-Reply-To: <4EB45515.6060405@freescale.com>
>-----Original Message-----
>From: linuxppc-dev-bounces+leoli=3Dfreescale.com@lists.ozlabs.org
>[mailto:linuxppc-dev-bounces+leoli=3Dfreescale.com@lists.ozlabs.org] On
>Behalf Of Scott Wood
>Sent: Saturday, November 05, 2011 5:12 AM
>To: Zhao Chenhui-B35336
>Cc: netdev@vger.kernel.org; linuxppc-dev@lists.ozlabs.org; Fleming Andy-
>AFLEMING
>Subject: Re: [PATCH 7/7] gianfar: add support for wake-on-packet
>
>On 11/04/2011 07:40 AM, Zhao Chenhui wrote:
>> diff --git a/Documentation/devicetree/bindings/net/fsl-tsec-phy.txt
>b/Documentation/devicetree/bindings/net/fsl-tsec-phy.txt
>> index 2c6be03..543e36c 100644
>> --- a/Documentation/devicetree/bindings/net/fsl-tsec-phy.txt
>> +++ b/Documentation/devicetree/bindings/net/fsl-tsec-phy.txt
>> @@ -56,6 +56,9 @@ Properties:
>> hardware.
>> - fsl,magic-packet : If present, indicates that the hardware supports
>> waking up via magic packet.
>> + - fsl,wake-on-filer : If present, indicates that the hardware
>supports
>> + waking up via arp request to local ip address or unicast packet to
>> + local mac address.
>
>Is there any way to determine this at runtime via the device's registers?
>
>I think TSEC_ID2[TSEC_CFG] can be used. The manual describes it
>awkwardly, but it looks like 0x20 is the bit for the filer.
That bit only defines the filer feature but not wakeup on it. Another solu=
tion is to get the capability from the fsl_pmc driver, but will make the dr=
iver a lot more complex.
>
>> @@ -751,7 +764,6 @@ static int gfar_of_init(struct platform_device
>*ofdev, struct net_device **pdev)
>> FSL_GIANFAR_DEV_HAS_PADDING |
>> FSL_GIANFAR_DEV_HAS_CSUM |
>> FSL_GIANFAR_DEV_HAS_VLAN |
>> - FSL_GIANFAR_DEV_HAS_MAGIC_PACKET |
>> FSL_GIANFAR_DEV_HAS_EXTENDED_HASH |
>> FSL_GIANFAR_DEV_HAS_TIMER;
>
>This is an unrelated change. Are there any eTSECs that don't support
>magic packet?
I'm not sure. But as we have the property for it in device tree, we use it=
.
>
>> +static int gfar_get_ip(struct net_device *dev)
>> +{
>> + struct gfar_private *priv =3D netdev_priv(dev);
>> + struct in_device *in_dev =3D (struct in_device *)dev->ip_ptr;
>> + struct in_ifaddr *ifa;
>> +
>> + if (in_dev !=3D NULL) {
>> + ifa =3D (struct in_ifaddr *)in_dev->ifa_list;
>> + if (ifa !=3D NULL) {
>> + memcpy(priv->ip_addr, &ifa->ifa_address, 4);
>> + return 0;
>> + }
>> + }
>> + return -ENOENT;
>> +}
>
>Unnecessary cast, ifa_list is already struct in_ifaddr *.
>
>Better, use for_primary_ifa(), and document that you won't wake on ARP
>packets for secondary IP addresses.
>
>> static int gfar_suspend(struct device *dev)
>> {
>> @@ -1268,9 +1443,17 @@ static int gfar_suspend(struct device *dev)
>> struct gfar __iomem *regs =3D priv->gfargrp[0].regs;
>> unsigned long flags;
>> u32 tempval;
>> -
>> int magic_packet =3D priv->wol_en &&
>> - (priv->device_flags & FSL_GIANFAR_DEV_HAS_MAGIC_PACKET);
>> + (priv->wol_opts & GIANFAR_WOL_MAGIC);
>> + int arp_packet =3D priv->wol_en &&
>> + (priv->wol_opts & GIANFAR_WOL_ARP);
>> +
>> + if (arp_packet) {
>> + pmc_enable_wake(priv->ofdev, PM_SUSPEND_MEM, 1);
>> + pmc_enable_lossless(1);
>> + gfar_arp_suspend(ndev);
>> + return 0;
>> + }
>
>How do we know this isn't standby?
Maybe we can remove the PM state parameter from the API.
- Leo
^ permalink raw reply
* Re: [PATCH 7/7] gianfar: add support for wake-on-packet
From: Kumar Gala @ 2011-11-08 13:42 UTC (permalink / raw)
To: Li Yang-R58472
Cc: Wood Scott-B07421, netdev@vger.kernel.org,
linuxppc-dev@lists.ozlabs.org, Fleming Andy-AFLEMING,
Zhao Chenhui-B35336
In-Reply-To: <3F607A5180246847A760FD34122A1E052BC9C7@039-SN1MPN1-004.039d.mgd.msft.net>
On Nov 8, 2011, at 5:20 AM, Li Yang-R58472 wrote:
>=20
>=20
>> -----Original Message-----
>> From: linuxppc-dev-bounces+leoli=3Dfreescale.com@lists.ozlabs.org
>> [mailto:linuxppc-dev-bounces+leoli=3Dfreescale.com@lists.ozlabs.org] =
On
>> Behalf Of Scott Wood
>> Sent: Saturday, November 05, 2011 5:12 AM
>> To: Zhao Chenhui-B35336
>> Cc: netdev@vger.kernel.org; linuxppc-dev@lists.ozlabs.org; Fleming =
Andy-
>> AFLEMING
>> Subject: Re: [PATCH 7/7] gianfar: add support for wake-on-packet
>>=20
>> On 11/04/2011 07:40 AM, Zhao Chenhui wrote:
>>> diff --git a/Documentation/devicetree/bindings/net/fsl-tsec-phy.txt
>> b/Documentation/devicetree/bindings/net/fsl-tsec-phy.txt
>>> index 2c6be03..543e36c 100644
>>> --- a/Documentation/devicetree/bindings/net/fsl-tsec-phy.txt
>>> +++ b/Documentation/devicetree/bindings/net/fsl-tsec-phy.txt
>>> @@ -56,6 +56,9 @@ Properties:
>>> hardware.
>>> - fsl,magic-packet : If present, indicates that the hardware =
supports
>>> waking up via magic packet.
>>> + - fsl,wake-on-filer : If present, indicates that the hardware
>> supports
>>> + waking up via arp request to local ip address or unicast packet =
to
>>> + local mac address.
>>=20
>> Is there any way to determine this at runtime via the device's =
registers?
>>=20
>> I think TSEC_ID2[TSEC_CFG] can be used. The manual describes it
>> awkwardly, but it looks like 0x20 is the bit for the filer.
>=20
> That bit only defines the filer feature but not wakeup on it. Another =
solution is to get the capability from the fsl_pmc driver, but will make =
the driver a lot more complex.
I don't believe there is a way to know this from the controller itself. =
We have to use device tree for it.
- k=
^ permalink raw reply
* [PATCH] powerpc: signal32: fix sigset_t conversion when copying to user
From: Will Deacon @ 2011-11-08 14:51 UTC (permalink / raw)
To: linuxppc-dev; +Cc: Will Deacon
On PPC64, put_sigset_t converts a sigset_t to a compat_sigset_t
before copying it to userspace. There is a typo in the case that
we have 4 words to copy, meaning that we corrupt the compat_sigset_t.
It appears that _NSIG_WORDS can't be greater than 2 at the moment
so this code is probably always optimised away anyway.
Signed-off-by: Will Deacon <will.deacon@arm.com>
---
arch/powerpc/kernel/signal_32.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/arch/powerpc/kernel/signal_32.c b/arch/powerpc/kernel/signal_32.c
index 78b76dc..836a5a1 100644
--- a/arch/powerpc/kernel/signal_32.c
+++ b/arch/powerpc/kernel/signal_32.c
@@ -97,7 +97,7 @@ static inline int put_sigset_t(compat_sigset_t __user *uset, sigset_t *set)
compat_sigset_t cset;
switch (_NSIG_WORDS) {
- case 4: cset.sig[5] = set->sig[3] & 0xffffffffull;
+ case 4: cset.sig[6] = set->sig[3] & 0xffffffffull;
cset.sig[7] = set->sig[3] >> 32;
case 3: cset.sig[4] = set->sig[2] & 0xffffffffull;
cset.sig[5] = set->sig[2] >> 32;
--
1.7.4.1
^ permalink raw reply related
* Re: [PATCH v2 1/5] [ppc] Process dynamic relocations for kernel
From: Josh Poimboeuf @ 2011-11-08 16:19 UTC (permalink / raw)
To: Suzuki Poulose
Cc: Nathan Miller, Josh Poimboeuf, Dave Hansen, Alan Modra,
Scott Wood, Paul Mackerras, linuxppc-dev
In-Reply-To: <4EB8D628.2090304@in.ibm.com>
On Tue, 2011-11-08 at 12:41 +0530, Suzuki Poulose wrote:
> What I was suggesting is, instead of flushing the cache in relocate(), lets do it
> like:
>
> for e.g, on 440x, (in head_44x.S :)
>
> #ifdef CONFIG_RELOCATABLE
> ...
> bl relocate
>
> #Flush the d-cache and invalidate the i-cache here
> #endif
>
>
> This would let the different platforms do the the cache invalidation in their
> own way.
>
> Btw, I didn't find an instruction to flush the entire d-cache in PPC440 manual.
> We have instructions to flush only a block corresponding to an address.
>
> However, we have 'iccci' which would invalidate the entire i-cache which, which
> I think is better than 80,000 i-cache invalidates.
In misc_32.S there are already some platform-independent cache
management functions. If we use those, then relocate() could simply
call them. Then the different platforms calling relocate() wouldn't
have to worry about flushing/invalidating caches.
For example, there's a clean_dcache_range() function. Given any range
twice the size of the d-cache, it should flush the entire d-cache. But
the only drawback is that it would require the caller to know the size
of the d-cache.
Instead, I think it would be preferable to create a new clean_dcache()
(or clean_dcache_all()?) function in misc_32.S, which could call
clean_dcache_range() with the appropriate args for flushing the entire
d-cache. relocate() could then call the platform-independent
clean_dcache().
For i-cache invalidation there's already the (incorrectly named?)
flush_instruction_cache(). It uses the appropriate platform-specific
methods (e.g. iccci for 44x) to invalidate the entire i-cache.
Suzuki, if you agree with this direction, I could work up a new patch if
needed.
Josh
^ permalink raw reply
* Re: [PATCH] powerpc/p1023: set IRQ[4:6, 11] to high level sensitive for PCIe
From: Scott Wood @ 2011-11-08 16:54 UTC (permalink / raw)
To: Zang Roy-R61911; +Cc: Wood Scott-B07421, linuxppc-dev@lists.ozlabs.org
In-Reply-To: <2239AC579C7D3646A720227A37E0268120D5C5@039-SN1MPN1-004.039d.mgd.msft.net>
On 11/07/2011 11:51 PM, Zang Roy-R61911 wrote:
>
>
>> -----Original Message-----
>> From: Wood Scott-B07421
>> Sent: Tuesday, November 08, 2011 2:44 AM
>> To: Zang Roy-R61911
>> Cc: linuxppc-dev@lists.ozlabs.org
>> Subject: Re: [PATCH] powerpc/p1023: set IRQ[4:6, 11] to high level sensitive for
>> PCIe
>>
>> On 11/07/2011 02:32 AM, Roy Zang wrote:
>>> P1023 external IRQ[4:6, 11] do not pin out, but the interrupts are
>>> shared with PCIe controller.
>>> The silicon internally ties the interrupts to L, so change the
>>> IRQ[4:6,11] to high level sensitive for PCIe.
>>
>> Some extra commentary on why this works would be nice.
> I do not know what kind of extra commentary you request.
Just a note that there's magic to allow the PCIe block to output these
interrupts as either active-high or active-low, depending on how they're
configured at the mpic.
> IRQ 4,5,6, 11 are internally tie to low by silicon. To use these interrupts for PCIe, they need to set high level sensitive.
> It is clear enough for this patch.
It's odd enough that I felt the need to go reading through the docs to
see why such a thing would work at all.
>> The manual says:
>>
>>> If a PCI Express INTx interrupt is being used, then the PIC must be configured
>> so that external interrupts
>>> are level-sensitive (EIVPRn[S] = 1).
> That is true for all FSL powerpc silicon with PCIe controller beside P1023.
Sure, my point was more that it didn't say anything there about how to
configure EIVPRn[P].
-Scott
^ permalink raw reply
* Re: [PATCH] powerpc: Export PIR data through sysfs
From: Scott Wood @ 2011-11-08 16:59 UTC (permalink / raw)
To: ananth; +Cc: linuxppc-dev, Anton Blanchard, mahesh
In-Reply-To: <20111108065811.GA9109@in.ibm.com>
On 11/08/2011 12:58 AM, Ananth N Mavinakayanahalli wrote:
> On Mon, Nov 07, 2011 at 11:18:32AM -0600, Scott Wood wrote:
>> What use does userspace have for this? If you want to return the
>> currently executing CPU (which unless you're pinned could change as soon
>> as the value is read...), why not just return smp_processor_id() or
>> hard_smp_processor_id()?
>
> Its not just the current cpu. Decoding PIR can tell you the core id,
> thread id in case of SMT, and this information can be used by userspace
> apps to set affinities, etc.
Wouldn't it make more sense to expose the thread to core mappings in a
general way, not tied to hardware or what thread we're currently running on?
What's the use case for knowing this information only about the current
thread (or rather the state the current thread was in a few moments ago)?
> +#if defined(CONFIG_SMP) && defined(SPRN_PIR)
> +SYSFS_PMCSETUP(pir, SPRN_PIR);
> +static SYSDEV_ATTR(pir, 0400, show_pir, NULL);
> +#endif
This only helps on architectures such as 8xx where you can't build as
SMP -- and I don't think #ifdef SPRN_PIR excludes any builds.
It doesn't help on chips like 750 or e300 where you can run a normal 6xx
SMP build, you just won't have multiple CPUs, and thus won't run things
like the secondary entry code.
-Scott
^ permalink raw reply
* [PATCH] KVM: PPC: move compute_tlbie_rb to book3s_64 common header
From: Andreas Schwab @ 2011-11-08 17:08 UTC (permalink / raw)
To: Alexander Graf; +Cc: linuxppc-dev, paulus, kvm, kvm-ppc
In-Reply-To: <1312907508-14599-2-git-send-email-agraf@suse.de>
compute_tlbie_rb is only used on ppc64 and cannot be compiled on ppc32.
Signed-off-by: Andreas Schwab <schwab@linux-m68k.org>
---
arch/powerpc/include/asm/kvm_book3s.h | 33 ------------------------------
arch/powerpc/include/asm/kvm_book3s_64.h | 33 ++++++++++++++++++++++++++++++
2 files changed, 33 insertions(+), 33 deletions(-)
diff --git a/arch/powerpc/include/asm/kvm_book3s.h b/arch/powerpc/include/asm/kvm_book3s.h
index a384ffd..db73fa3 100644
--- a/arch/powerpc/include/asm/kvm_book3s.h
+++ b/arch/powerpc/include/asm/kvm_book3s.h
@@ -383,39 +383,6 @@ static inline bool kvmppc_critical_section(struct kvm_vcpu *vcpu)
}
#endif
-static inline unsigned long compute_tlbie_rb(unsigned long v, unsigned long r,
- unsigned long pte_index)
-{
- unsigned long rb, va_low;
-
- rb = (v & ~0x7fUL) << 16; /* AVA field */
- va_low = pte_index >> 3;
- if (v & HPTE_V_SECONDARY)
- va_low = ~va_low;
- /* xor vsid from AVA */
- if (!(v & HPTE_V_1TB_SEG))
- va_low ^= v >> 12;
- else
- va_low ^= v >> 24;
- va_low &= 0x7ff;
- if (v & HPTE_V_LARGE) {
- rb |= 1; /* L field */
- if (cpu_has_feature(CPU_FTR_ARCH_206) &&
- (r & 0xff000)) {
- /* non-16MB large page, must be 64k */
- /* (masks depend on page size) */
- rb |= 0x1000; /* page encoding in LP field */
- rb |= (va_low & 0x7f) << 16; /* 7b of VA in AVA/LP field */
- rb |= (va_low & 0xfe); /* AVAL field (P7 doesn't seem to care) */
- }
- } else {
- /* 4kB page */
- rb |= (va_low & 0x7ff) << 12; /* remaining 11b of VA */
- }
- rb |= (v >> 54) & 0x300; /* B field */
- return rb;
-}
-
/* Magic register values loaded into r3 and r4 before the 'sc' assembly
* instruction for the OSI hypercalls */
#define OSI_SC_MAGIC_R3 0x113724FA
diff --git a/arch/powerpc/include/asm/kvm_book3s_64.h b/arch/powerpc/include/asm/kvm_book3s_64.h
index e43fe42..d0ac94f 100644
--- a/arch/powerpc/include/asm/kvm_book3s_64.h
+++ b/arch/powerpc/include/asm/kvm_book3s_64.h
@@ -29,4 +29,37 @@ static inline struct kvmppc_book3s_shadow_vcpu *to_svcpu(struct kvm_vcpu *vcpu)
#define SPAPR_TCE_SHIFT 12
+static inline unsigned long compute_tlbie_rb(unsigned long v, unsigned long r,
+ unsigned long pte_index)
+{
+ unsigned long rb, va_low;
+
+ rb = (v & ~0x7fUL) << 16; /* AVA field */
+ va_low = pte_index >> 3;
+ if (v & HPTE_V_SECONDARY)
+ va_low = ~va_low;
+ /* xor vsid from AVA */
+ if (!(v & HPTE_V_1TB_SEG))
+ va_low ^= v >> 12;
+ else
+ va_low ^= v >> 24;
+ va_low &= 0x7ff;
+ if (v & HPTE_V_LARGE) {
+ rb |= 1; /* L field */
+ if (cpu_has_feature(CPU_FTR_ARCH_206) &&
+ (r & 0xff000)) {
+ /* non-16MB large page, must be 64k */
+ /* (masks depend on page size) */
+ rb |= 0x1000; /* page encoding in LP field */
+ rb |= (va_low & 0x7f) << 16; /* 7b of VA in AVA/LP field */
+ rb |= (va_low & 0xfe); /* AVAL field (P7 doesn't seem to care) */
+ }
+ } else {
+ /* 4kB page */
+ rb |= (va_low & 0x7ff) << 12; /* remaining 11b of VA */
+ }
+ rb |= (v >> 54) & 0x300; /* B field */
+ return rb;
+}
+
#endif /* __ASM_KVM_BOOK3S_64_H__ */
--
1.7.7.2
--
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5
"And now for something completely different."
^ permalink raw reply related
* [PATCH] KVM: PPC: protect use of kvmppc_h_pr
From: Andreas Schwab @ 2011-11-08 17:17 UTC (permalink / raw)
To: Alexander Graf; +Cc: linuxppc-dev, paulus, kvm, kvm-ppc
In-Reply-To: <1312907508-14599-10-git-send-email-agraf@suse.de>
kvmppc_h_pr is only available if CONFIG_KVM_BOOK3S_64_PR.
Signed-off-by: Andreas Schwab <schwab@linux-m68k.org>
---
arch/powerpc/kvm/book3s_pr.c | 2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/arch/powerpc/kvm/book3s_pr.c b/arch/powerpc/kvm/book3s_pr.c
index bc4d50d..05473b5 100644
--- a/arch/powerpc/kvm/book3s_pr.c
+++ b/arch/powerpc/kvm/book3s_pr.c
@@ -660,10 +660,12 @@ program_interrupt:
ulong cmd = kvmppc_get_gpr(vcpu, 3);
int i;
+#ifdef CONFIG_KVM_BOOK3S_64_PR
if (kvmppc_h_pr(vcpu, cmd) == EMULATE_DONE) {
r = RESUME_GUEST;
break;
}
+#endif
run->papr_hcall.nr = cmd;
for (i = 0; i < 9; ++i) {
--
1.7.7.2
--
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5
"And now for something completely different."
^ 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