* [PATCH 04/61] 8xx: Work around CPU15 erratum.
From: Scott Wood @ 2007-07-18 1:32 UTC (permalink / raw)
To: linuxppc-dev
In-Reply-To: <20070718013137.GA15217@ld0162-tx32.am.freescale.net>
The CPU15 erratum on MPC8xx chips can cause incorrect code execution
under certain circumstances, where there is a conditional or indirect
branch in the last word of a page, with a target in the last cache line
of the next page. This patch implements one of the suggested
workarounds, by forcing a TLB miss whenever execution crosses a page
boundary. This is done by invalidating the pages before and after the
one being loaded into the TLB in the ITLB miss handler.
Signed-off-by: Scott Wood <scottwood@freescale.com>
---
arch/powerpc/kernel/head_8xx.S | 6 ++++++
arch/powerpc/platforms/8xx/Kconfig | 16 ++++++++++++++++
2 files changed, 22 insertions(+), 0 deletions(-)
diff --git a/arch/powerpc/kernel/head_8xx.S b/arch/powerpc/kernel/head_8xx.S
index 901be47..7488f30 100644
--- a/arch/powerpc/kernel/head_8xx.S
+++ b/arch/powerpc/kernel/head_8xx.S
@@ -301,6 +301,12 @@ InstructionTLBMiss:
stw r10, 0(r0)
stw r11, 4(r0)
mfspr r10, SPRN_SRR0 /* Get effective address of fault */
+#ifdef CONFIG_8xx_CPU15
+ addi r11, r10, 0x1000
+ tlbie r11
+ addi r11, r10, -0x1000
+ tlbie r11
+#endif
DO_8xx_CPU6(0x3780, r3)
mtspr SPRN_MD_EPN, r10 /* Have to use MD_EPN for walk, MI_EPN can't */
mfspr r10, SPRN_M_TWB /* Get level 1 table entry address */
diff --git a/arch/powerpc/platforms/8xx/Kconfig b/arch/powerpc/platforms/8xx/Kconfig
index 39bb8c5..b8dd515 100644
--- a/arch/powerpc/platforms/8xx/Kconfig
+++ b/arch/powerpc/platforms/8xx/Kconfig
@@ -99,6 +99,22 @@ config 8xx_CPU6
If in doubt, say N here.
+config 8xx_CPU15
+ bool "CPU15 Silicon Errata"
+ default y
+ help
+ This enables a workaround for erratum CPU15 on MPC8xx chips.
+ This bug can cause incorrect code execution under certain
+ circumstances. This workaround adds some overhead (a TLB miss
+ every time execution crosses a page boundary), and you may wish
+ to disable it if you have worked around the bug in the compiler
+ (by not placing conditional branches or branches to LR or CTR
+ in the last word of a page, with a target of the last cache
+ line in the next page), or if you have used some other
+ workaround.
+
+ If in doubt, say Y here.
+
choice
prompt "Microcode patch selection"
default NO_UCODE_PATCH
--
1.5.0.3
^ permalink raw reply related
* [PATCH 03/61] Only include linux/ide.h if CONFIG_BLOCK is defined.
From: Scott Wood @ 2007-07-18 1:32 UTC (permalink / raw)
To: linuxppc-dev
In-Reply-To: <20070718013137.GA15217@ld0162-tx32.am.freescale.net>
The IDE header file uses type definitions that are undefined if the
CONFIG_BLOCK is deselected. This causes a compilation failure in
setup_32.c.
Signed-off-by: Scott Wood <scottwood@freescale.com>
---
arch/powerpc/kernel/ppc_ksyms.c | 2 ++
arch/powerpc/kernel/setup_32.c | 4 +++-
2 files changed, 5 insertions(+), 1 deletions(-)
diff --git a/arch/powerpc/kernel/ppc_ksyms.c b/arch/powerpc/kernel/ppc_ksyms.c
index a20f195..bc54493 100644
--- a/arch/powerpc/kernel/ppc_ksyms.c
+++ b/arch/powerpc/kernel/ppc_ksyms.c
@@ -12,7 +12,9 @@
#include <linux/irq.h>
#include <linux/pci.h>
#include <linux/delay.h>
+#ifdef CONFIG_BLOCK
#include <linux/ide.h>
+#endif
#include <linux/bitops.h>
#include <asm/page.h>
diff --git a/arch/powerpc/kernel/setup_32.c b/arch/powerpc/kernel/setup_32.c
index 7ec6ba5..ae5d60e 100644
--- a/arch/powerpc/kernel/setup_32.c
+++ b/arch/powerpc/kernel/setup_32.c
@@ -10,7 +10,6 @@
#include <linux/reboot.h>
#include <linux/delay.h>
#include <linux/initrd.h>
-#include <linux/ide.h>
#include <linux/tty.h>
#include <linux/bootmem.h>
#include <linux/seq_file.h>
@@ -51,7 +50,10 @@
extern void bootx_init(unsigned long r4, unsigned long phys);
+#ifdef COFNIG_BLOCK
+#include <linux/ide.h>
struct ide_machdep_calls ppc_ide_md;
+#endif
int boot_cpuid;
EXPORT_SYMBOL_GPL(boot_cpuid);
--
1.5.0.3
^ permalink raw reply related
* [PATCH 02/61] mpc8272ads.dts: Whitespace cleanup
From: Scott Wood @ 2007-07-18 1:32 UTC (permalink / raw)
To: linuxppc-dev
In-Reply-To: <20070718013137.GA15217@ld0162-tx32.am.freescale.net>
Convert spaces to tabs, and add a few newlines where appropriate.
Signed-off-by: Scott Wood <scottwood@freescale.com>
---
arch/powerpc/boot/dts/mpc8272ads.dts | 376 +++++++++++++++++-----------------
1 files changed, 189 insertions(+), 187 deletions(-)
diff --git a/arch/powerpc/boot/dts/mpc8272ads.dts b/arch/powerpc/boot/dts/mpc8272ads.dts
index 1934b80..4d09dca 100644
--- a/arch/powerpc/boot/dts/mpc8272ads.dts
+++ b/arch/powerpc/boot/dts/mpc8272ads.dts
@@ -10,207 +10,209 @@
*/
/ {
- model = "MPC8272ADS";
- compatible = "MPC8260ADS";
- #address-cells = <1>;
- #size-cells = <1>;
-
- cpus {
- #address-cells = <1>;
- #size-cells = <0>;
-
- PowerPC,8272@0 {
- device_type = "cpu";
- reg = <0>;
- d-cache-line-size = <20>; // 32 bytes
- i-cache-line-size = <20>; // 32 bytes
- d-cache-size = <4000>; // L1, 16K
- i-cache-size = <4000>; // L1, 16K
- timebase-frequency = <0>;
- bus-frequency = <0>;
- clock-frequency = <0>;
- 32-bit;
- };
- };
-
- pci_pic: interrupt-controller@f8200000 {
- #address-cells = <0>;
- #interrupt-cells = <2>;
- interrupt-controller;
- reg = <f8200000 f8200004>;
- built-in;
- device_type = "pci-pic";
- };
- memory {
- device_type = "memory";
- reg = <00000000 4000000 f4500000 00000020>;
- };
-
- chosen {
- name = "chosen";
- linux,platform = <0>;
+ model = "MPC8272ADS";
+ compatible = "MPC8260ADS";
+ #address-cells = <1>;
+ #size-cells = <1>;
+
+ cpus {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ PowerPC,8272@0 {
+ device_type = "cpu";
+ reg = <0>;
+ d-cache-line-size = <20>; // 32 bytes
+ i-cache-line-size = <20>; // 32 bytes
+ d-cache-size = <4000>; // L1, 16K
+ i-cache-size = <4000>; // L1, 16K
+ timebase-frequency = <0>;
+ bus-frequency = <0>;
+ clock-frequency = <0>;
+ 32-bit;
+ };
+ };
+
+ pci_pic: interrupt-controller@f8200000 {
+ #address-cells = <0>;
+ #interrupt-cells = <2>;
+ interrupt-controller;
+ reg = <f8200000 f8200004>;
+ built-in;
+ device_type = "pci-pic";
+ };
+
+ memory {
+ device_type = "memory";
+ reg = <00000000 4000000 f4500000 00000020>;
+ };
+
+ chosen {
+ name = "chosen";
+ linux,platform = <0>;
interrupt-controller = <&Cpm_pic>;
- };
-
- soc8272@f0000000 {
- #address-cells = <1>;
- #size-cells = <1>;
- #interrupt-cells = <2>;
- device_type = "soc";
- ranges = <00000000 f0000000 00053000>;
- reg = <f0000000 10000>;
-
- mdio@0 {
- device_type = "mdio";
- compatible = "fs_enet";
- reg = <0 0>;
- #address-cells = <1>;
- #size-cells = <0>;
+ };
+
+ soc8272@f0000000 {
+ #address-cells = <1>;
+ #size-cells = <1>;
+ #interrupt-cells = <2>;
+ device_type = "soc";
+ ranges = <00000000 f0000000 00053000>;
+ reg = <f0000000 10000>;
+
+ mdio@0 {
+ device_type = "mdio";
+ compatible = "fs_enet";
+ reg = <0 0>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+
phy0:ethernet-phy@0 {
interrupt-parent = <&Cpm_pic>;
- interrupts = <17 4>;
- reg = <0>;
- bitbang = [ 12 12 13 02 02 01 ];
- device_type = "ethernet-phy";
- };
+ interrupts = <17 4>;
+ reg = <0>;
+ bitbang = [ 12 12 13 02 02 01 ];
+ device_type = "ethernet-phy";
+ };
+
phy1:ethernet-phy@1 {
interrupt-parent = <&Cpm_pic>;
- interrupts = <17 4>;
- bitbang = [ 12 12 13 02 02 01 ];
- reg = <3>;
- device_type = "ethernet-phy";
- };
- };
-
- ethernet@24000 {
- #address-cells = <1>;
- #size-cells = <0>;
- device_type = "network";
- device-id = <1>;
- compatible = "fs_enet";
- model = "FCC";
- reg = <11300 20 8400 100 11380 30>;
- mac-address = [ 00 11 2F 99 43 54 ];
- interrupts = <20 2>;
+ interrupts = <17 4>;
+ bitbang = [ 12 12 13 02 02 01 ];
+ reg = <3>;
+ device_type = "ethernet-phy";
+ };
+ };
+
+ ethernet@24000 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ device_type = "network";
+ device-id = <1>;
+ compatible = "fs_enet";
+ model = "FCC";
+ reg = <11300 20 8400 100 11380 30>;
+ mac-address = [ 00 11 2F 99 43 54 ];
+ interrupts = <20 2>;
interrupt-parent = <&Cpm_pic>;
phy-handle = <&Phy0>;
- rx-clock = <13>;
- tx-clock = <12>;
- };
-
- ethernet@25000 {
- device_type = "network";
- device-id = <2>;
- compatible = "fs_enet";
- model = "FCC";
- reg = <11320 20 8500 100 113b0 30>;
- mac-address = [ 00 11 2F 99 44 54 ];
- interrupts = <21 2>;
+ rx-clock = <13>;
+ tx-clock = <12>;
+ };
+
+ ethernet@25000 {
+ device_type = "network";
+ device-id = <2>;
+ compatible = "fs_enet";
+ model = "FCC";
+ reg = <11320 20 8500 100 113b0 30>;
+ mac-address = [ 00 11 2F 99 44 54 ];
+ interrupts = <21 2>;
interrupt-parent = <&Cpm_pic>;
phy-handle = <&Phy1>;
- rx-clock = <17>;
- tx-clock = <18>;
- };
-
- cpm@f0000000 {
- #address-cells = <1>;
- #size-cells = <1>;
- #interrupt-cells = <2>;
- device_type = "cpm";
- model = "CPM2";
- ranges = <00000000 00000000 20000>;
- reg = <0 20000>;
- command-proc = <119c0>;
- brg-frequency = <17D7840>;
- cpm_clk = <BEBC200>;
-
- scc@11a00 {
- device_type = "serial";
- compatible = "cpm_uart";
- model = "SCC";
- device-id = <1>;
- reg = <11a00 20 8000 100>;
- current-speed = <1c200>;
- interrupts = <28 2>;
+ rx-clock = <17>;
+ tx-clock = <18>;
+ };
+
+ cpm@f0000000 {
+ #address-cells = <1>;
+ #size-cells = <1>;
+ #interrupt-cells = <2>;
+ device_type = "cpm";
+ model = "CPM2";
+ ranges = <00000000 00000000 20000>;
+ reg = <0 20000>;
+ command-proc = <119c0>;
+ brg-frequency = <17D7840>;
+ cpm_clk = <BEBC200>;
+
+ scc@11a00 {
+ device_type = "serial";
+ compatible = "cpm_uart";
+ model = "SCC";
+ device-id = <1>;
+ reg = <11a00 20 8000 100>;
+ current-speed = <1c200>;
+ interrupts = <28 2>;
interrupt-parent = <&Cpm_pic>;
- clock-setup = <0 00ffffff>;
- rx-clock = <1>;
- tx-clock = <1>;
- };
-
- scc@11a60 {
- device_type = "serial";
- compatible = "cpm_uart";
- model = "SCC";
- device-id = <4>;
- reg = <11a60 20 8300 100>;
- current-speed = <1c200>;
- interrupts = <2b 2>;
+ clock-setup = <0 00ffffff>;
+ rx-clock = <1>;
+ tx-clock = <1>;
+ };
+
+ scc@11a60 {
+ device_type = "serial";
+ compatible = "cpm_uart";
+ model = "SCC";
+ device-id = <4>;
+ reg = <11a60 20 8300 100>;
+ current-speed = <1c200>;
+ interrupts = <2b 2>;
interrupt-parent = <&Cpm_pic>;
- clock-setup = <1b ffffff00>;
- rx-clock = <4>;
- tx-clock = <4>;
- };
-
- };
- cpm_pic:interrupt-controller@10c00 {
- #address-cells = <0>;
- #interrupt-cells = <2>;
- interrupt-controller;
- reg = <10c00 80>;
- built-in;
- device_type = "cpm-pic";
- compatible = "CPM2";
- };
- pci@0500 {
- #interrupt-cells = <1>;
- #size-cells = <2>;
- #address-cells = <3>;
- compatible = "8272";
- device_type = "pci";
- reg = <10430 4dc>;
- clock-frequency = <3f940aa>;
- interrupt-map-mask = <f800 0 0 7>;
- interrupt-map = <
-
- /* IDSEL 0x16 */
- b000 0 0 1 f8200000 40 8
- b000 0 0 2 f8200000 41 8
- b000 0 0 3 f8200000 42 8
- b000 0 0 4 f8200000 43 8
-
- /* IDSEL 0x17 */
- b800 0 0 1 f8200000 43 8
- b800 0 0 2 f8200000 40 8
- b800 0 0 3 f8200000 41 8
- b800 0 0 4 f8200000 42 8
-
- /* IDSEL 0x18 */
- c000 0 0 1 f8200000 42 8
- c000 0 0 2 f8200000 43 8
- c000 0 0 3 f8200000 40 8
- c000 0 0 4 f8200000 41 8>;
+ clock-setup = <1b ffffff00>;
+ rx-clock = <4>;
+ tx-clock = <4>;
+ };
+ };
+
+ cpm_pic:interrupt-controller@10c00 {
+ #address-cells = <0>;
+ #interrupt-cells = <2>;
+ interrupt-controller;
+ reg = <10c00 80>;
+ built-in;
+ device_type = "cpm-pic";
+ compatible = "CPM2";
+ };
+
+ pci@0500 {
+ #interrupt-cells = <1>;
+ #size-cells = <2>;
+ #address-cells = <3>;
+ compatible = "8272";
+ device_type = "pci";
+ reg = <10430 4dc>;
+ clock-frequency = <3f940aa>;
+ interrupt-map-mask = <f800 0 0 7>;
+ interrupt-map = <
+ /* IDSEL 0x16 */
+ b000 0 0 1 f8200000 40 8
+ b000 0 0 2 f8200000 41 8
+ b000 0 0 3 f8200000 42 8
+ b000 0 0 4 f8200000 43 8
+
+ /* IDSEL 0x17 */
+ b800 0 0 1 f8200000 43 8
+ b800 0 0 2 f8200000 40 8
+ b800 0 0 3 f8200000 41 8
+ b800 0 0 4 f8200000 42 8
+
+ /* IDSEL 0x18 */
+ c000 0 0 1 f8200000 42 8
+ c000 0 0 2 f8200000 43 8
+ c000 0 0 3 f8200000 40 8
+ c000 0 0 4 f8200000 41 8>;
interrupt-parent = <&Cpm_pic>;
- interrupts = <14 8>;
- bus-range = <0 0>;
- ranges = <02000000 0 80000000 80000000 0 40000000
- 01000000 0 00000000 f6000000 0 02000000>;
- };
+ interrupts = <14 8>;
+ bus-range = <0 0>;
+ ranges = <02000000 0 80000000 80000000 0 40000000
+ 01000000 0 00000000 f6000000 0 02000000>;
+ };
/* May need to remove if on a part without crypto engine */
- crypto@30000 {
- device_type = "crypto";
- model = "SEC2";
- compatible = "talitos";
- reg = <30000 10000>;
- interrupts = <b 2>;
+ crypto@30000 {
+ device_type = "crypto";
+ model = "SEC2";
+ compatible = "talitos";
+ reg = <30000 10000>;
+ interrupts = <b 2>;
interrupt-parent = <&Cpm_pic>;
- num-channels = <4>;
- channel-fifo-len = <18>;
- exec-units-mask = <0000007e>;
+ num-channels = <4>;
+ channel-fifo-len = <18>;
+ exec-units-mask = <0000007e>;
/* desc mask is for rev1.x, we need runtime fixup for >=2.x */
- descriptor-types-mask = <01010ebf>;
- };
-
- };
+ descriptor-types-mask = <01010ebf>;
+ };
+ };
};
--
1.5.0.3
^ permalink raw reply related
* [PATCH 01/61] Use strcasecmp() rather than strncasecmp() when determining device node compatibility.
From: Scott Wood @ 2007-07-18 1:31 UTC (permalink / raw)
To: linuxppc-dev
The current code assumes "foo-bar" must always be compatible with a node
compatible with "foo", which breaks device trees where this is not so.
The "case" part is also wrong according to Open Firmware, but it's more
likely to have drivers and/or device trees depending on it, and thus
needs to be handled more carefully.
Signed-off-by: Scott Wood <scottwood@freescale.com>
---
arch/powerpc/kernel/prom.c | 4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/powerpc/kernel/prom.c b/arch/powerpc/kernel/prom.c
index 37ff99b..0b136a5 100644
--- a/arch/powerpc/kernel/prom.c
+++ b/arch/powerpc/kernel/prom.c
@@ -218,7 +218,7 @@ int __init of_flat_dt_is_compatible(unsigned long node, const char *compat)
if (cp == NULL)
return 0;
while (cplen > 0) {
- if (strncasecmp(cp, compat, strlen(compat)) == 0)
+ if (strcasecmp(cp, compat) == 0)
return 1;
l = strlen(cp) + 1;
cp += l;
@@ -1099,7 +1099,7 @@ int of_device_is_compatible(const struct device_node *device,
if (cp == NULL)
return 0;
while (cplen > 0) {
- if (strncasecmp(cp, compat, strlen(compat)) == 0)
+ if (strcasecmp(cp, compat) == 0)
return 1;
l = strlen(cp) + 1;
cp += l;
--
1.5.0.3
^ permalink raw reply related
* Re: [PATCH 3/3] First cut at PReP support for arch/powerpc
From: David Gibson @ 2007-07-18 1:31 UTC (permalink / raw)
To: Segher Boessenkool; +Cc: linuxppc-dev, Paul Mackerras
In-Reply-To: <b1bc50e84cd3f8009eca2b470bea026f@kernel.crashing.org>
On Thu, Jun 28, 2007 at 10:59:35AM +0200, Segher Boessenkool wrote:
> > Here is an implementation to allow PReP systems to boot under the
> > arch/powerpc codebase, one of the few remaining platforms supported in
> > arch/ppc but not so far in arch/powerpc.
>
> > Too big for the list, the patch is at:
> > http://ozlabs.org/~dgibson/home/prep-support
>
> Too lazy to split the patch into bite-size chunks, you mean ;-)
Well... much as I like small patches, I don't really like having a big
string of patches, each of which does basically nothing on its own,
i.e. split up just for the sake of making smaller, rather than into
separate logically separate changes.
> Anyway, here goes the DTS bits:
>
> +/*
> + * PReP skeleton device tree
> + *
> + * Paul Mackerras <paulus@samba.org>
> + */
> +
> +/ {
> + device_type = "prep";
> + model = "IBM,PReP";
>
> Not specific enough, leave it out or fill it in in the bootwrapper.
Yeah, I should fill that in with the string from the residual data.
Haven't gotten around to it.
> + compatible = "prep";
>
> Maybe fill this in, too.
>
> + #address-cells = <1>;
> + #size-cells = <1>;
> +
> + cpus {
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + cpu@0 {
>
> Do all (supported) PReP boards have one CPU only?
Well, depends what you mean by "supported", really. My arch/powerpc
port only support UP boards so far... I realise this will need to
change at some point.
>
> + device_type = "cpu";
> + reg = <0>;
> + clock-frequency = <0>; // filled in by bootwrapper
> + bus-frequency = <0>; // filled in by bootwrapper
> + timebase-frequency = <0>; // filled in by bootwrapper
> + i-cache-line-size = <0>; // filled in by bootwrapper
> + d-cache-line-size = <0>; // filled in by bootwrapper
> + d-cache-size = <0>; // filled in by bootwrapper
> + i-cache-size = <0>; // filled in by bootwrapper
> + external-control;
>
> Really?
No idea, just copied that from earlier work of Paulus'. Don't even
know what the property means.
> + graphics;
> + performance-monitor;
> +
> + l2-cache {
> + device_type = "cache";
> + i-cache-size = <00100000>;
> + d-cache-size = <00100000>;
> + i-cache-sets = <00008000>;
> + d-cache-sets = <00008000>;
> + i-cache-line-size = <00000020>;
> + d-cache-line-size = <00000020>;
>
> Drop the leading zeroes, they make my head spin :-)
>
> + cache-unified;
> + };
> + };
> + };
> +
> + memory {
> + device_type = "memory";
> + // dummy range here, zImage wrapper will fill in the actual
> + // amount of memory from the residual data
> + reg = <00000000 00000000>;
> + };
> +
> + pci@80000000 {
> + device_type = "pci";
> + compatible = "prep";
>
> Is that specific enough?
Well, AFAICT, the prep PCI code doesn't need any more info.
> + clock-frequency = <01fca055>;
> + reg = <80000000 7effffff>;
> + 8259-interrupt-acknowledge = <bffffff0>;
> + #address-cells = <3>;
> + #size-cells = <2>;
> + ranges=<01000000 00000000 00000000 80000000 00000000 00800000
> + 01000000 00000000 00800000 81000000 00000000 3e800000
> + 02000000 00000000 00000000 c0000000 00000000 01000000
> + 02000000 00000000 01000000 c1000000 00000000 3e000000>;
> + interrupt-map-mask = <f800 0 0 7>;
> + interrupt-map = <6000 0 0 1 &MPIC 6 0
> + 8000 0 0 1 &MPIC 7 0
> + 9000 0 0 1 &MPIC 2 0
> + b000 0 0 1 &MPIC 1 0>;
>
> I can't believe this "ranges" and interrupt mapping will
> work on all PReP systems...
Probably not, but it should work on a chunk of them. Like I say,
there's still a good deal more that needs to be filled in from
residual data or wherever.
> + isa {
> + device_type = "isa";
> + #address-cells = <2>;
> + #size-cells = <1>;
> + #interrupt-cells = <2>;
> + ranges = <00000001 00000000
> + 01005800 00000000 00000000 00010000
> + 00000000 00000000
> + 02005800 00000000 00000000 01000000>;
> +
> + parallel {
> + device_type = "parallel";
> + compatible = "ecp", "pnpPNP,400";
>
> "pnpPNP,401", "pnpPNP,400"
>
> + reg = <00000001 000003bc 00000008
> + 00000001 000007bc 00000006>;
> + interrupts = <00000007 00000003>;
> + interrupt-parent = <&PIC8259>;
> + };
> +
> + serial@3f8 {
> + device_type = "serial";
> + compatible = "pnpPNP,501";
>
> "pnpPNP,501", "pnpPNP,500" I'd say. Many/some device
> tree users will only care it is _some_ 8250 family thing.
>
> + clock-frequency = <001c2000>;
> + reg = <00000001 000003f8 00000008>;
> + interrupts = <00000004 00000003>;
> + interrupt-parent = <&PIC8259>;
> + };
> + serial@2f8 {
> + device_type = "serial";
> + compatible = "pnpPNP,501";
> + clock-frequency = <001c2000>;
> + reg = <00000001 000002f8 00000008>;
> + interrupts = <00000003 00000003>;
> + interrupt-parent = <&PIC8259>;
> + };
> + PIC8259: interrupt-controller {
> + device_type = "i8259";
>
> device_type = "interrupt-controller".
>
> + compatible = "prep,iic";
> + reg = < 00000001 00000020 00000002
> + 00000001 000000a0 00000002
> + 00000001 000004d0 00000002>;
> + interrupts = <00000000 00000003
> + 00000002 00000003>;
> + interrupt-parent = <&MPIC>;
> + };
> + };
> +
> + MPIC: interrupt-controller@d {
> + device_type = "open-pic";
>
> device_type = "interrupt-controller".
>
> + compatible = "mpic";
> + reg = < 00006800 00000000 00000000 00000000 00000000
> + 02006810 00000000 00000000 00000000 00040000>;
> + assigned-addresses = <
> + 82006810 00000000 3afc0000 00000000 00040000>;
> + };
> + };
> +
> + chosen {
> + linux,stdout-path = "/pci/isa/serial@3f8";
> + };
> +};
>
> What is the plan here -- have the bootwrapper build the
> device tree / fill in the details from the residual data?
Not sure at this stage if it will be best for the bootwrapper to build
a complete tree from residual, or to have a dts skeleton with
substantial chunks filled in by bootwrapper from residual. I was
intending to merge libfdt into the kernel for more flexible device
tree manipulation before investigating that further.
--
David Gibson | I'll have my music baroque, and my code
david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson
^ permalink raw reply
* - add-missing-data_data-in-powerpc.patch removed from -mm tree
From: akpm @ 2007-07-17 23:09 UTC (permalink / raw)
To: mathieu.desnoyers, linuxppc-dev, paulus, mm-commits
The patch titled
powerpc: add missing DATA_DATA
has been removed from the -mm tree. Its filename was
add-missing-data_data-in-powerpc.patch
This patch was dropped because it was merged into mainline or a subsystem tree
------------------------------------------------------
Subject: powerpc: add missing DATA_DATA
From: Mathieu Desnoyers <mathieu.desnoyers@polymtl.ca>
Signed-off-by: Mathieu Desnoyers <mathieu.desnoyers@polymtl.ca>
Cc: <paulus@samba.org>
Cc: <linuxppc-dev@ozlabs.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
---
arch/powerpc/kernel/vmlinux.lds.S | 4 +++-
1 files changed, 3 insertions(+), 1 deletion(-)
diff -puN arch/powerpc/kernel/vmlinux.lds.S~add-missing-data_data-in-powerpc arch/powerpc/kernel/vmlinux.lds.S
--- a/arch/powerpc/kernel/vmlinux.lds.S~add-missing-data_data-in-powerpc
+++ a/arch/powerpc/kernel/vmlinux.lds.S
@@ -174,7 +174,9 @@ SECTIONS
}
#else
.data : {
- *(.data .data.rel* .toc1)
+ DATA_DATA
+ *(.data.rel*)
+ *(.toc1)
*(.branch_lt)
}
_
Patches currently in -mm which might be from mathieu.desnoyers@polymtl.ca are
origin.patch
git-kbuild.patch
^ permalink raw reply
* Re: [RFC][PATCH 6/8] Walnut DTS
From: Benjamin Herrenschmidt @ 2007-07-17 22:58 UTC (permalink / raw)
To: Scott Wood; +Cc: linuxppc-dev, Yoder Stuart-B08248
In-Reply-To: <20070717222507.GA4682@ld0162-tx32.am.freescale.net>
> It could lead someone to the erroneous conclusion that an #address-cells
> other than zero in an interrupt controller that is not a device parent is
> in any way a sane or supported thing to do.
I fail why anyone would ever want to do it though :-)
> It could lead people to write code that doesn't handle the absence of
> #address-cells in such a node properly.
We just need to make mention that it can be absent in the spec, there
shouldn't be that many parsers out there.
> It could lead to flamewars. :-)
Yeah well.
> If there's only one value that could possibly make sense, it *not* being
> the default is crap.
Only for leaf nodes. Other values do make sense for non-leaf nodes.
> The obvious way (which indeed isn't what the suggested algorithm does --
> but the suggested algorithm doesn't do anything sensible) is that if you
> got to the node via an interrupt-parent or interrupt-map, it doesn't use
> #address-cells, and if you got to it by going to the regular device tree
> parent, it does.
Yeah well, that's also somewhat debatable too. You need a #address-cells
to be able to parse an interrupt-map. You can imagine cross-links and
special maps used to handle things like the multiple UICs as David did
in the past. I wouldn't get rid of that flexibility to handle corner
cases that aren't easily represented by the "standard" stuff.
> Pretty much any time you use the unit address in a context other than the
> bus parent, things cease making sense.
I tend to agree.
> There is the ePAPR working group, though.
Yup, true.
Ben.
^ permalink raw reply
* Re: [PATCH] Add StorCenter DTS first draft.
From: Jon Loeliger @ 2007-07-17 22:56 UTC (permalink / raw)
To: Scott Wood; +Cc: linuxppc-dev
In-Reply-To: <469D43DD.8020102@freescale.com>
So, like, the other day Scott Wood mumbled:
> Jon Loeliger wrote:
> > How about "soc8241@80000000" instead?
>
> How about just "soc@80000000"? Those model numbers in the names are a
> PITA to find from limited functionality environments such as the
> bootwrapper, require things like stdout-path to be different on every
> soc, and don't comply with the generic names recommendation.
Oh! Right. No problem.
jdl
^ permalink raw reply
* Re: Linuxppc-embedded Digest, Vol 35, Issue 33
From: Scott Wood @ 2007-07-17 22:51 UTC (permalink / raw)
To: Siva Prasad; +Cc: suresh suresh, linuxppc-embedded
In-Reply-To: <D83235F0F3C86D4D889D8B9A0DA8C6D78D7FAF@corpexc01.corp.networkrobots.com>
Siva Prasad wrote:
> Well!... you can manage any way you want.
>
>
>
> 1) You can store the virtual address in the DpRAM, and convert to
> physical (should I say DMA mapped address) and then pass it on to the
> device under consideration here.
The DPRAM is read directly by the microcode (if it didn't, you'd just be
using RAM). You don't want to put virtual addresses in there.
-Scott
^ permalink raw reply
* Re: [PATCH v2] Allow exec on 32-bit from readable, non-exec pages, with a warning.
From: Scott Wood @ 2007-07-17 22:53 UTC (permalink / raw)
To: Jon Loeliger; +Cc: linuxppc-dev@ozlabs.org, Paul Mackerras
In-Reply-To: <E1IAvmA-00062M-F4@jdl.com>
Jon Loeliger wrote:
> A: They haven't been posted yet.
>
> Q: How do we know Segher has new patches?
He sent it to me to test, and I told him it worked...
-Scott
^ permalink raw reply
* Re: [PATCH v2] Allow exec on 32-bit from readable, non-exec pages, with a warning.
From: Jon Loeliger @ 2007-07-17 22:44 UTC (permalink / raw)
To: Scott Wood; +Cc: linuxppc-dev@ozlabs.org, Paul Mackerras
In-Reply-To: <469D3F60.8000401@freescale.com>
<Top Posting Carnac>
A: They haven't been posted yet.
Q: How do we know Segher has new patches?
</Top Posting Carnac>
So, like, the other day Scott Wood mumbled:
> Jon Loeliger wrote:
> > But luckily, this gave me the opportunity to then realize that
> > we should give a great big...
> >
> > Amen-brother-by: Jon Loeliger <jdl@freescale.com>
> >
> > to this patch from Scott.
> >
> > So, an official plea to Paul to apply this to his tree.
>
> Segher has a newer patch that supersedes this one. I don't know if he's
> posted it to the list yet, though.
>
> -Scott
^ permalink raw reply
* RE: Linuxppc-embedded Digest, Vol 35, Issue 33
From: Siva Prasad @ 2007-07-17 22:41 UTC (permalink / raw)
To: suresh suresh, Scott Wood; +Cc: linuxppc-embedded
In-Reply-To: <e5eb93010707162259l2e78c524s32ff260b3d930bdb@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 1652 bytes --]
Well!... you can manage any way you want.
1) You can store the virtual address in the DpRAM, and convert to
physical (should I say DMA mapped address) and then pass it on to the
device under consideration here.
2) Other way would be... store the physical address in DpRAM. Use that
address for the device, and convert to virtual before you use it in the
code.
My preference is for first option.
- Siva
________________________________
From: suresh suresh [mailto:sureshtang@gmail.com]
Sent: Monday, July 16, 2007 10:59 PM
To: Scott Wood
Cc: Siva Prasad; linuxppc-embedded@ozlabs.org
Subject: Re: Linuxppc-embedded Digest, Vol 35, Issue 33
Thanks....
MPC8280 has internal memory space which contains Dualport(Dp) RAM. In
the DpRAM we allocate some tables and these has to store pointer of the
buffers which are allocated in external memory. Core will use this
pointer to access the buffers, basically these buffers are used for DMA.
Using IMMR register we can get physical address of the internal memory.
Now can I store the address return by the kmalloc() function? or I
should convert it into physical?
Please help me how to resove this address translation.
Regards,
Suresh
On 7/16/07, Scott Wood <scottwood@freescale.com> wrote:
Siva Prasad wrote:
> It returns kernel virtual address. If you use this buffer space for
DMA,
> please use appropriate flags. You may use __pa(address) or
> virt_to_phys() to convert virtual to physical.
No, you may not -- physical and DMA addresses are not always identical.
Use the DMA mapping API.
-Scott
[-- Attachment #2: Type: text/html, Size: 6080 bytes --]
^ permalink raw reply
* Re: [PATCH] Add StorCenter DTS first draft.
From: Scott Wood @ 2007-07-17 22:34 UTC (permalink / raw)
To: Jon Loeliger; +Cc: linuxppc-dev
In-Reply-To: <E1IAvVm-0005yQ-LO@jdl.com>
Jon Loeliger wrote:
> How about "soc8241@80000000" instead?
>
> That would be similar to:
> soc8641@f8000000 {
> and
> soc8272@f0000000 {
How about just "soc@80000000"? Those model numbers in the names are a
PITA to find from limited functionality environments such as the
bootwrapper, require things like stdout-path to be different on every
soc, and don't comply with the generic names recommendation.
-Scott
^ permalink raw reply
* Re: [PATCH] Add StorCenter DTS first draft.
From: Jon Loeliger @ 2007-07-17 22:27 UTC (permalink / raw)
To: Segher Boessenkool; +Cc: linuxppc-dev
In-Reply-To: <630B6BC9-389F-4F5C-AE8F-9C3131C4543E@kernel.crashing.org>
So, like, the other day Segher Boessenkool mumbled:
> > +/ {
> > + model = "StorCenter";
>
> If you can find a real model number, put it in here, instead.
Yep, "StorCenter" is it. No model numer/name beyond that.
> > + compatible = "storcenter";
>
> Needs a manufacturer name in there.
Right. Will use:
compatible = "iomega,storcenter"
> > + PowerPC,603e { /* Really 8241 */
>
> So say "PowerPC,8241@0", or "PowerPC,e300@0" (or whatever
> the CPU core in there is), or simply "cpu@0", following
> the generic naming recommended practice.
Well, its the 8241 SoC with a 603e core... (This is
the same phrase currently being used on the Kurobox.)
I'll use:
PowerPC,8241@0 }
> > + bus-frequency = <0>;
>
> Is this filled in anywhere? Please document that, if so.
Right. boot{loader,wrapper}
> > + soc10x {
>
> Bad name. Where is the binding for this? I don't think
> I saw it before.
It's what is being used, again, by the Kurobox. I understand
that doesn't make it "right", just precedented by now.
How about "soc8241@80000000" instead?
That would be similar to:
soc8641@f8000000 {
and
soc8272@f0000000 {
> > + store-gathering = <0>; /* 0 == off, !0 == on */
>
> Don't define this as "!0", but as "1".
OK.
> > + i2c@fdf03000 {
> > + device_type = "i2c";
>
> No device_type, there is no I2C binding.
Right.
> > + compatible = "fsl-i2c";
>
> Needs to be more specific.
Hmmm... Not sure what to use here then. There are many
existing examples using "fsl-i2c" already. Granted, we've
established that they could be wrong... Should this be
more like this?:
compatible = "fsl,mpc8241-i2c", "fsl-i2c";
> > + mpic: pic@fdf40000 {
>
> interrupt-controller@fdf40000
OK.
> > + pci@fe800000 {
> > + clock-frequency = <d# 100000000>; /* Hz */
>
> 100MHz PCI? Interesting.
Good point. 66666666 seems more likely...
Thanks for the review and help here!
jdl
^ permalink raw reply
* Re: [RFC][PATCH 6/8] Walnut DTS
From: Scott Wood @ 2007-07-17 22:25 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: linuxppc-dev, Yoder Stuart-B08248
In-Reply-To: <1184707558.25235.159.camel@localhost.localdomain>
On Wed, Jul 18, 2007 at 07:25:57AM +1000, Benjamin Herrenschmidt wrote:
> > > which is why I tend to prefer having it
> > > explicitely in the interrupt controller node :-)
> >
> > Which is simply incorrect.
>
> It's absolutely not. Please, stop that moronic pin-head behaviour and
> find me a single case where that would actually be a problem of any sort
> or form.
It could lead someone to the erroneous conclusion that an #address-cells
other than zero in an interrupt controller that is not a device parent is
in any way a sane or supported thing to do.
It could lead people to write code that doesn't handle the absence of
#address-cells in such a node properly.
It could lead to flamewars. :-)
> > You mean, the magic default values you used for #address-cells
> > and #size-cells? That was simply a bug, someone forgot to read
> > the documentation...
>
> No, defaults are crap, period.
If there's only one value that could possibly make sense, it *not* being
the default is crap.
> See above. Besides, as I said, default values are crap. And no, it's not
> obvious which nodes define a physical address space or not, at least not
> for a generic parser.
The obvious way (which indeed isn't what the suggested algorithm does --
but the suggested algorithm doesn't do anything sensible) is that if you
got to the node via an interrupt-parent or interrupt-map, it doesn't use
#address-cells, and if you got to it by going to the regular device tree
parent, it does.
Pretty much any time you use the unit address in a context other than the
bus parent, things cease making sense.
> > In some areas, perhaps. And it would be nice to bring those
> > areas to the attention of the working group, instead of just
> > to complain.
>
> The working group is dead and some of the ex members of it expressed
> their lack of interest in pursuing these matters.
There is the ePAPR working group, though.
-Scott
^ permalink raw reply
* [PATCH] POWERPC: Fix misspelled "CONFIG_CHECK_CACHE_COHERENCY" Kconfig option.
From: Robert P. J. Day @ 2007-07-17 22:21 UTC (permalink / raw)
To: Linux PPC Mailing List; +Cc: Paul Mackerras
Signed-off-by: Robert P. J. Day <rpjday@mindspring.com>
---
arch/powerpc/configs/prpmc2800_defconfig | 2 +-
arch/powerpc/platforms/Kconfig.cputype | 2 +-
arch/powerpc/platforms/embedded6xx/Kconfig | 2 +-
3 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/arch/powerpc/configs/prpmc2800_defconfig b/arch/powerpc/configs/prpmc2800_defconfig
index fb504a7..858f865 100644
--- a/arch/powerpc/configs/prpmc2800_defconfig
+++ b/arch/powerpc/configs/prpmc2800_defconfig
@@ -48,7 +48,7 @@ CONFIG_PPC_STD_MMU_32=y
# CONFIG_PPC_MM_SLICES is not set
# CONFIG_SMP is not set
CONFIG_NOT_COHERENT_CACHE=y
-CONFIG_CONFIG_CHECK_CACHE_COHERENCY=y
+CONFIG_CHECK_CACHE_COHERENCY=y
CONFIG_DEFCONFIG_LIST="/lib/modules/$UNAME_RELEASE/.config"
#
diff --git a/arch/powerpc/platforms/Kconfig.cputype b/arch/powerpc/platforms/Kconfig.cputype
index b8b5fde..e4b2aee 100644
--- a/arch/powerpc/platforms/Kconfig.cputype
+++ b/arch/powerpc/platforms/Kconfig.cputype
@@ -215,7 +215,7 @@ config NOT_COHERENT_CACHE
depends on 4xx || 8xx || E200
default y
-config CONFIG_CHECK_CACHE_COHERENCY
+config CHECK_CACHE_COHERENCY
bool
endmenu
diff --git a/arch/powerpc/platforms/embedded6xx/Kconfig b/arch/powerpc/platforms/embedded6xx/Kconfig
index bec7726..2d12f77 100644
--- a/arch/powerpc/platforms/embedded6xx/Kconfig
+++ b/arch/powerpc/platforms/embedded6xx/Kconfig
@@ -59,7 +59,7 @@ config MPC10X_BRIDGE
config MV64X60
bool
select PPC_INDIRECT_PCI
- select CONFIG_CHECK_CACHE_COHERENCY
+ select CHECK_CACHE_COHERENCY
config MPC10X_OPENPIC
bool
--
========================================================================
Robert P. J. Day
Linux Consulting, Training and Annoying Kernel Pedantry
Waterloo, Ontario, CANADA
http://fsdev.net/wiki/index.php?title=Main_Page
========================================================================
^ permalink raw reply related
* Re: [PATCH] POWERPC: Correct misspelled config variable in arch/powerpc/Kconfig.
From: Robert P. J. Day @ 2007-07-17 22:17 UTC (permalink / raw)
To: Paul Mackerras; +Cc: Linux PPC Mailing List
In-Reply-To: <18076.46827.932735.590316@cargo.ozlabs.ibm.com>
On Tue, 17 Jul 2007, Paul Mackerras wrote:
> Robert P. J. Day writes:
>
> > -config CONFIG_CHECK_CACHE_COHERENCY
> > +config CHECK_CACHE_COHERENCY
>
> Please also fix the occurrence in
> arch/powerpc/platforms/embedded6xx/Kconfig.
ah, i completely missed that one. i'll resubmit the patch shortly.
rday
--
========================================================================
Robert P. J. Day
Linux Consulting, Training and Annoying Kernel Pedantry
Waterloo, Ontario, CANADA
http://fsdev.net/wiki/index.php?title=Main_Page
========================================================================
^ permalink raw reply
* Re: [PATCH] powerpc: Add of_register_i2c_devices()
From: Guennadi Liakhovetski @ 2007-07-17 22:17 UTC (permalink / raw)
To: Segher Boessenkool; +Cc: linuxppc-dev, Paul Mackerras
In-Reply-To: <E0E696F1-2F9E-4D6B-A194-EB42BA826BCD@kernel.crashing.org>
On Wed, 4 Jul 2007, Segher Boessenkool wrote:
> Your device is an rs5c372b. So, that's what you put in
> your device tree. Simple so far, right?
>
> Now some OF I2C code goes looking for IIC devices in the
> device tree. It finds this thing, and from a table or
> something it derives that it has to tell the kernel I2C
> layer this is an "rtc-rs5c372". [It would be nicer if it
> could just instantiate the correct driver directly, but
> if that's how the Linux I2C layer works, so be it].
>
> No change in the I2C "core" needed, just an OF "compatible"
> matching thing like is needed *everywhere else* too.
How about the patch below?
Thanks
Guennadi
---
Guennadi Liakhovetski
Scan the device tree for i2c devices, check their "compatible" property
against a hard-coded table, and, if found, register with i2c boardinfo.
Signed-off-by: G. Liakhovetski <g.liakhovetski@gmx.de>
diff --git a/arch/powerpc/sysdev/fsl_soc.c b/arch/powerpc/sysdev/fsl_soc.c
index 9588b60..c3c7eba 100644
--- a/arch/powerpc/sysdev/fsl_soc.c
+++ b/arch/powerpc/sysdev/fsl_soc.c
@@ -296,6 +296,62 @@ err:
arch_initcall(gfar_of_init);
+#ifdef CONFIG_I2C_BOARDINFO
+#include <linux/i2c.h>
+struct i2c_driver_device {
+ char *of_device;
+ char *i2c_driver;
+ char *i2c_type;
+};
+
+static struct i2c_driver_device i2c_devices[] = {
+ {"rs5c372a", "rtc-rs5c372", "rs5c372a",},
+ {"rs5c372b", "rtc-rs5c372", "rs5c372b",},
+ {"rv5c386", "rtc-rs5c372", "rv5c386",},
+ {"rv5c387a", "rtc-rs5c372", "rv5c387a",},
+};
+
+static int of_find_i2c_driver(struct device_node *node, struct i2c_board_info *info)
+{
+ int i;
+
+ for (i = 0; i < ARRAY_SIZE(i2c_devices); i++) {
+ if (!of_device_is_compatible(node, i2c_devices[i].of_device))
+ continue;
+ strncpy(info->driver_name, i2c_devices[i].i2c_driver, KOBJ_NAME_LEN);
+ strncpy(info->type, i2c_devices[i].i2c_type, I2C_NAME_SIZE);
+ return 0;
+ }
+ return -ENODEV;
+}
+
+static void of_register_i2c_devices(struct device_node *adap_node, int bus_num)
+{
+ struct device_node *node = NULL;
+
+ while ((node = of_get_next_child(adap_node, node))) {
+ struct i2c_board_info info;
+ const u32 *addr;
+ int len;
+
+ addr = of_get_property(node, "reg", &len);
+ if (!addr || len < sizeof(int) || *addr > 0xffff)
+ continue;
+
+ info.irq = irq_of_parse_and_map(node, 0);
+ if (info.irq == NO_IRQ)
+ info.irq = -1;
+
+ if (of_find_i2c_driver(node, &info) < 0)
+ continue;
+
+ info.platform_data = NULL;
+ info.addr = *addr;
+
+ i2c_register_board_info(bus_num, &info, 1);
+ }
+}
+
static int __init fsl_i2c_of_init(void)
{
struct device_node *np;
@@ -340,6 +396,8 @@ static int __init fsl_i2c_of_init(void)
fsl_i2c_platform_data));
if (ret)
goto unreg;
+
+ of_register_i2c_devices(np, i);
}
return 0;
@@ -351,6 +409,7 @@ err:
}
arch_initcall(fsl_i2c_of_init);
+#endif
#ifdef CONFIG_PPC_83xx
static int __init mpc83xx_wdt_init(void)
^ permalink raw reply related
* Re: [PATCH v2] Allow exec on 32-bit from readable, non-exec pages, with a warning.
From: Scott Wood @ 2007-07-17 22:14 UTC (permalink / raw)
To: Jon Loeliger; +Cc: linuxppc-dev@ozlabs.org, Paul Mackerras
In-Reply-To: <1184705168.24473.32.camel@ld0161-tx32>
Jon Loeliger wrote:
> But luckily, this gave me the opportunity to then realize that
> we should give a great big...
>
> Amen-brother-by: Jon Loeliger <jdl@freescale.com>
>
> to this patch from Scott.
>
> So, an official plea to Paul to apply this to his tree.
Segher has a newer patch that supersedes this one. I don't know if he's
posted it to the list yet, though.
-Scott
^ permalink raw reply
* Cypress c67x00 Support?
From: Robertson, Joseph M. @ 2007-07-17 22:14 UTC (permalink / raw)
To: linuxppc-embedded
[-- Attachment #1: Type: text/plain, Size: 1915 bytes --]
Hi,
I have some questions about the Cypress c67x00 code that was posted a few days ago.
I got the many patches from the git (thanks Grant!), but I am wondering,
How did you guys fix up the Kconfigs to work with the Xilinx Virtex-4 fpga?
My hw guys have put the cypress chip on 'the system ace'(OPB?) bus, a 16 bit bus, and I have the address to it.
But its definetely not PCI, and if you use a plain kernel tree like I have, I cannot access any features without turning on the PCI options. Which of course fails, since I have no PCI parameters to feed the code.
Perhaps a better question is: Is this code intended for the Virtex-4?
If no, then I will have to fix it up.
Thanks,
Joe Robertson
Joseph.Robertson@sanmina-sci.com
CONFIDENTIALITY
This e-mail message and any attachments thereto, is intended only for use by the addressee(s) named herein and may contain legally privileged and/or confidential information. If you are not the intended recipient of this e-mail message, you are hereby notified that any dissemination, distribution or copying of this e-mail message, and any attachments thereto, is strictly prohibited. If you have received this e-mail message in error, please immediately notify the sender and permanently delete the original and any copies of this email and any prints thereof.
ABSENT AN EXPRESS STATEMENT TO THE CONTRARY HEREINABOVE, THIS E-MAIL IS NOT INTENDED AS A SUBSTITUTE FOR A WRITING. Notwithstanding the Uniform Electronic Transactions Act or the applicability of any other law of similar substance and effect, absent an express statement to the contrary hereinabove, this e-mail message its contents, and any attachments hereto are not intended to represent an offer or acceptance to enter into a contract and are not otherwise intended to bind the sender, Sanmina-SCI Corporation (or any of its subsidiaries), or any other person or entity.
[-- Attachment #2: Type: text/html, Size: 2385 bytes --]
^ permalink raw reply
* Re: [PATCH 01/10] IB/ehca: Support for multiple event queues
From: Michael S. Tsirkin @ 2007-07-17 21:32 UTC (permalink / raw)
To: Roland Dreier
Cc: Joachim Fenkes, LKML, LinuxPPC-Dev, Hoang-Nam Nguyen, OF-General,
Michael S. Tsirkin, Stefan Roscher
In-Reply-To: <adalkdesyrs.fsf@cisco.com>
> Quoting Roland Dreier <rdreier@cisco.com>:
> Subject: Re: [PATCH 01/10] IB/ehca: Support for multiple event queues
>
> > Here's some anecdotal evidence :)
> > http://lists.openfabrics.org/pipermail/general/2007-May/035758.html
>
> Right, but then we went on to say that we probably want to use
> multiple vectors to separate out multiple HCA ports rather than
> send/sreceive on the same port. And the current IPoIB implementation
> of having that second CQ seems suboptimal anyway, since it seems to
> leave us susceptible to the interrupt overload that NAPI was supposed
> to solve.
Sure, the ipoib patch is just a proof of concept anyway.
And I'm actually working on merging send/recv CQs now,
to address the livelocks.
> At a higher level, I'm left wondering why nobody talked about multiple
> EQs during the last months of the 2.6.22 process and now all of a
> sudden it becomes urgent in the last few days of the 2.6.23 merge
> window.
I don't see any emergency in merging the IPoIB hack either.
I just hoped that once we merge the core changes people will start
experimenting with multiple vectors. This did not seem to have happened.
Could this be because there's no low level driver support upstream yet?
So I wonder whether merging the mthca patch [that was patch 2 of the series]
in 2.6.23 will finally get the
ball rolling, get people to experiment with multiple vectors
in userspace, and that will hopefully teach us something.
> That's not really how I like to merge features....
If you look just at the mthca patch in isolation,
do you still see a problem?
--
MST
^ permalink raw reply
* Re: [RFC][PATCH 6/8] Walnut DTS
From: Benjamin Herrenschmidt @ 2007-07-17 21:25 UTC (permalink / raw)
To: Segher Boessenkool; +Cc: linuxppc-dev, Yoder Stuart-B08248
In-Reply-To: <C2D29334-489F-49B0-8220-0D94E89FEAC3@kernel.crashing.org>
> Yes, I shouldn't say "defaulted" -- a unit interrupt specifier
> simply has no unit address part, in an interrupt domain that
> doesn't correspond to a "normal" bus. But saying it like this
> is a little bit inexact, and it uses more words.
>
> > which is why I tend to prefer having it
> > explicitely in the interrupt controller node :-)
>
> Which is simply incorrect.
It's absolutely not. Please, stop that moronic pin-head behaviour and
find me a single case where that would actually be a problem of any sort
or form.
> You mean, the magic default values you used for #address-cells
> and #size-cells? That was simply a bug, someone forgot to read
> the documentation...
No, defaults are crap, period. This is a general thing. Besides, the
spec itself has issues about the default values (remember those blurbs
about PCI and ISA supposedly having different defaults ?) In any way,
defaults are a bad idea and I'm happy to say don't use them.
> For this? No way:
>
> [From the base spec]:
>
> “#address-cells” S
> Standard property name to define the package’s address format.
> prop-encoded-array: Integer, encoded with encode-int.
>
> This property applies to packages that define a physical
> address space, i.e., those packages with “decode-unit”
> methods. The property value specifies the number of cells
> that are used to encode a physical address within that
> address space. The value of this property affects the other
> functions, commands, and methods that deal with physical
> addresses. In a package with a “decode-unit” method, a missing
> “#address-cells” property signifies that the number of
> address cells is two.
And you omit the various bus bindings that have come up with different
defaults...
> See? The flat device tree unfortunately has no decode-unit, but
> it is still pretty clear which nodes "define a physical address
> space" and which do not.
>
> There is nothing badly defined here.
See above. Besides, as I said, default values are crap. And no, it's not
obvious which nodes define a physical address space or not, at least not
for a generic parser. Defaults are a bad idea, just get it and move on
and stop arguing just for the sake of arguing. Pointing out the letter
of the spec is not a constructive attitude here.
> Nothing in the "interrupt mapping" spec redefines #address-cells
> (OF isn't all that stupid you know); it simply says that a /unit
> interrupt specifier/ has no /unit address/ part if there is no
> #address-cells. The algorithm in paragraph 7 makes it super
> clear how exactly this should work.
No, the algorithm provided isn't clear and is buggy. I have implemented
it so I know what I'm talking about. The fact that basically you end up
with "different" defaults for what is essentially the value
#address-cells depending on whether you are walking the device-tree for
address resolution or for interrupt resolution is stupid. Thus, the
solution is simple: don't do defaults. Explicit values are good.
> > and the spec contains gray areas
> > and contradictions as to what the default values should be in some
> > circumstances.
>
> In some areas, perhaps. And it would be nice to bring those
> areas to the attention of the working group, instead of just
> to complain.
The working group is dead and some of the ex members of it expressed
their lack of interest in pursuing these matters.
> Linux will have to keep supporting them for "real OF", so
> requiring an explicit #address-cells where its value is 2
> doesn't really help much. I'm not opposed to this though,
> for flat device trees at least (I think it's a good thing
> for OF trees as well, but for different reasons; and that's
> beside the point here).
>
> On the other hand, requiring an #address-cells where it is
> supposed to be absent, and you only want it so you can wrap
> your head around the interrupt mapping recommended practice
> in a more confusing and confused way, is simply WRONG.
No, it's not, It's purely having an explicit representation of what was
a stupid default behaviour.
> If it would, the interrupt mapping spec would have had to say
> how the semantics of #address-cells were changed (and they
> weren't, and they shouldn't, and this is such a laughable idea
> I wonder why anyone would suggest it did).
That's bullshit. The semantics are exactly the same. You obviously
decided to be immune to any kind of common sense today.
> What the interrupt mapping spec defines is how to _use_ the
> value of #address-cells, and how to interpret its absence;
> what should be put in #address-cells for separate nodes is
> defined elsewhere (namely, in the base spec, and in relevant
> device bindings).
There is no such crackpot interpretation. A unit interrupt specifier
contains ... an address. An address format/size is defined by a
#address-cells. Period. That's not an "interpretation", that's the
basic, primary semantic of #address-cells. The fact that the absence of
#address-cells will give a different "default" for the address size
depending on "how" you walk the tree is just a plain wrong bad idea. I
see no reason why it would be or cause or be in any way shape or form
wrong or against the "spirit" of the spec (if not the letter) to
explicitely specify in the case of leaf interrupt controllers, that
their #address-cells is 0 and be done with it.
Ben.
^ permalink raw reply
* Re: hugetlbfs for ppc440 - kernel BUG -- follow up
From: Satya @ 2007-07-17 21:07 UTC (permalink / raw)
To: linuxppc-dev; +Cc: kazutomo, edi, david
hello,
Upon investigating the below issue further, I found that
pte_alloc_map() calls kmap_atomic. The allocated pte page must be
unmapped before invoking any function that might_sleep.
In this case clear_huge_page() is being called without invoking
pte_unmap(). The 'normal' counterpart of hugetlb_no_page (which is
do_no_page() in mm/memory.c) does call pte_unmap() before calling
alloc_page() (which might sleep).
So, I believe pte_unmap() must be invoked first in hugetlb_no_page().
But the problem here is, we do not have a reference to the pmd to map
the pte again (using pte_offset_map()). The do_no_page() function does
have a pmd_t* parameter, so it can remap the pte when required.
For now, I resolved the problem by expanding the pte_alloc_map() macro
by hand and replacing kmap_atomic with kmap(), although I think it is
not the right thing to do.
Let me know if my analysis is helping you figure out the problem here. Thanks!
--satya.
On 7/10/07, Satya <satyakiran@gmail.com> wrote:
> hello,
> I am trying to implement hugetlbfs on the IBM Bluegene/L IO node
> (ppc440) and I have a big problem as well as a few questions to ask
> the group. I patched a 2.6.21.6 linux kernel (manually) with Edi
> Shmueli's hugetlbfs implementation (found here:
> http://patchwork.ozlabs.org/linuxppc/patch?id=8427) for this. I did
> have to make slight changes (described at the end) to make it work.
> My test program is a shortened version of a sys v shared memory
> example described in Documentation/vm/hugetlbpage.txt
>
> I get the following kernel BUG when a page fault occurs on a huge page address:
> BUG: scheduling while atomic: shmtest2/0x10000001/1291
> Call Trace:
> [CFF0BCE0] [C00084F4] show_stack+0x4c/0x194 (unreliable)
> [CFF0BD20] [C01A53C4] schedule+0x664/0x668
> [CFF0BD60] [C00175F8] __cond_resched+0x24/0x50
> [CFF0BD80] [C01A5A6C] cond_resched+0x50/0x58
> [CFF0BD90] [C005A31C] clear_huge_page+0x28/0x174
> [CFF0BDC0] [C005B360] hugetlb_no_page+0xb4/0x220
> [CFF0BE00] [C005B5BC] hugetlb_fault+0xf0/0xf4
> [CFF0BE30] [C0052AC0] __handle_mm_fault+0x3a8/0x3ac
> [CFF0BE70] [C00094A0] do_page_fault+0x118/0x428
> [CFF0BF40] [C0002360] handle_page_fault+0xc/0x80
> BUG: scheduling while atomic: shmtest2/0x10000001/1291
>
> Now for my questions:
>
> 1. Can the kernel really reschedule in a page fault handler context ?
>
> 2. Just to test where this "scheduling while atomic" bug is arising, i
> put schedule() calls at various places in the path of the stack trace
> shown above.
> I found that a call to pte_alloc_map() puts the kernel in a context
> where it cannot reschedule without throwing up. Here is a trace of
> what's going on:
>
> __handle_mm_fault -> hugetlb_fault -> huge_pte_alloc() -> pte_alloc_map()
>
> Any call to schedule() before pte_alloc_map() does not throw this
> error. Well, this might be a flawed experiment, I am no expert kernel
> hacker. Does this throw any light on the problem?
>
> Here are the modifications I made to Edi's patch:
>
> arch/ppc/mm/hugetlbpage.c
> struct page *
> follow_huge_addr(struct mm_struct *mm, unsigned long address, int write)
> {
> pte_t *pte;
> struct page *page;
> + struct vm_area_struct *vma;
> +
> + vma = find_vma(mm, address);
> + if (!vma || !is_vm_hugetlb_page(vma))
> + return ERR_PTR(-EINVAL);
>
> pte = huge_pte_offset(mm, address);
> page = pte_page(*pte);
> return page;
> }
>
> +int huge_pmd_unshare(struct mm_struct *mm, unsigned long *addr, pte_t *ptep)
> +{
> + return 0;
> +}
>
> Here is my test program:
>
> #include <stdlib.h>
> #include <stdio.h>
> #include <sys/types.h>
> #include <sys/ipc.h>
> #include <sys/shm.h>
> #include <sys/mman.h>
>
> #ifndef SHM_HUGETLB
> #define SHM_HUGETLB 04000
> #endif
>
> #define LENGTH (16UL*1024*1024)
>
> #define dprintf(x) printf(x)
>
> #define ADDR (void *)(0x0UL)
> #define SHMAT_FLAGS (0)
>
>
> int main(void)
> {
> int shmid;
> unsigned long i;
> char *shmaddr;
>
> if ((shmid = shmget(2, LENGTH,
> SHM_HUGETLB | IPC_CREAT | SHM_R | SHM_W)) < 0) {
> perror("shmget");
> exit(1);
> }
> printf("shmid: 0x%x\n", shmid);
>
> shmaddr = shmat(shmid, ADDR, SHMAT_FLAGS);
> if (shmaddr == (char *)-1) {
> perror("Shared memory attach failure");
> shmctl(shmid, IPC_RMID, NULL);
> exit(2);
> }
> printf("shmaddr: %p\n", shmaddr);
> printf("touching a huge page..\n");
>
> shmaddr[0]='a';
> shmaddr[1]='b';
>
> if (shmdt((const void *)shmaddr) != 0) {
> perror("Detach failure");
> shmctl(shmid, IPC_RMID, NULL);
> exit(3);
> }
>
> shmctl(shmid, IPC_RMID, NULL);
>
> return 0;
> }
>
> thanks!
> Satya.
>
--
...what's remarkable, is that atoms have assembled into entities which
are somehow able to ponder their origins.
--
http://cs.uic.edu/~spopuri
^ permalink raw reply
* Re: [PATCH] iommu virtual merge no longer experimental
From: Benjamin Herrenschmidt @ 2007-07-17 20:56 UTC (permalink / raw)
To: Linas Vepstas; +Cc: linuxppc-dev, paulus, Arnd Bergmann, Tim Schimke
In-Reply-To: <20070717160935.GE5771@austin.ibm.com>
On Tue, 2007-07-17 at 11:09 -0500, Linas Vepstas wrote:
> Per conversations with BenH, iommu virtual merging should no longer
> be considered to be an "experimental" feature. In particular,
> CONFIG_VMERGE has been set to "y" in te defconfigs for quite a while.
>
> Signed-off-by: Linas Vepstas <linas@austin.ibm.com>
Acked-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
> ----
> arch/powerpc/Kconfig | 11 ++++++-----
> 1 file changed, 6 insertions(+), 5 deletions(-)
>
> Index: linux-2.6.22-git2/arch/powerpc/Kconfig
> ===================================================================
> --- linux-2.6.22-git2.orig/arch/powerpc/Kconfig 2007-07-08 18:32:17.000000000 -0500
> +++ linux-2.6.22-git2/arch/powerpc/Kconfig 2007-07-17 11:08:18.000000000 -0500
> @@ -430,16 +430,17 @@ config MATH_EMULATION
> instructions to run.
>
> config IOMMU_VMERGE
> - bool "Enable IOMMU virtual merging (EXPERIMENTAL)"
> - depends on EXPERIMENTAL && PPC64
> - default n
> + bool "Enable IOMMU virtual merging"
> + depends on PPC64
> + default y
> help
> Cause IO segments sent to a device for DMA to be merged virtually
> by the IOMMU when they happen to have been allocated contiguously.
> This doesn't add pressure to the IOMMU allocator. However, some
> drivers don't support getting large merged segments coming back
> - from *_map_sg(). Say Y if you know the drivers you are using are
> - properly handling this case.
> + from *_map_sg().
> +
> + Most drivers don't have this problem; it is safe to say Y here.
>
> config HOTPLUG_CPU
> bool "Support for enabling/disabling CPUs"
^ permalink raw reply
* Re: [PATCH v2] Allow exec on 32-bit from readable, non-exec pages, with a warning.
From: Jon Loeliger @ 2007-07-17 20:46 UTC (permalink / raw)
To: Scott Wood; +Cc: linuxppc-dev@ozlabs.org, Paul Mackerras
In-Reply-To: <20070709214853.GA29912@ld0162-tx32.am.freescale.net>
On Mon, 2007-07-09 at 16:48, Scott Wood wrote:
> In older versions of glibc (through 2.3), the dynamic linker executes a
> small amount of code from the data segment, which is not marked as
> executable. A recent change (commit 9ba4ace39fdfe22268daca9f28c5df384ae462cf)
> stops this from working; there should be a deprecation period before
> older glibc versions stop working.
>
> The problem has been observed on glibc 2.2. While glibc 2.3 has the same
> code, I did not see the problem; it may be that it accesses the page in
> question as data before executing from it, and thus it is already mapped.
>
> Note that this only applies to the classic 32-bit PowerPC MMU and the
> MPC8xx MMU, not Book E, 64-bit, etc. These MMUs do not support per-page
> no-exec, and thus this patch isn't taking away any effective protection
> enforcement. Currently, such accesses will fail only if the page in
> question has not already been faulted on (and thus mapped).
>
> Signed-off-by: Scott Wood <scottwood@freescale.com>
> ---
Well now. I've spent a good chunk of today with Our Friend, git-bisect,
verifying that, in fact, the commit 9ba4ace39fdfe22268daca9f28c5df384ae462cf
breaks the 8641 HPCN port. init doesn't run off an old NFS'ed root FS
worth a Steven J Hill of beans.
But luckily, this gave me the opportunity to then realize that
we should give a great big...
Amen-brother-by: Jon Loeliger <jdl@freescale.com>
to this patch from Scott.
So, an official plea to Paul to apply this to his tree.
jdl
> v2: Added to the changelog to explain why this change isn't harmful.
>
> arch/powerpc/mm/fault.c | 22 +++++++++++++++++++++-
> 1 files changed, 21 insertions(+), 1 deletions(-)
>
> diff --git a/arch/powerpc/mm/fault.c b/arch/powerpc/mm/fault.c
> index 0ece513..2445512 100644
> --- a/arch/powerpc/mm/fault.c
> +++ b/arch/powerpc/mm/fault.c
> @@ -125,6 +125,18 @@ static void do_dabr(struct pt_regs *regs, unsigned long address,
> }
> #endif /* !(CONFIG_4xx || CONFIG_BOOKE)*/
>
> +#ifdef CONFIG_PPC32
> +static void warn_exec_from_noexec(void)
> +{
> + if (printk_ratelimit())
> + printk(KERN_WARNING "Process %s (%d) attempted to execute from "
> + "a non-executable page.\n"
> + KERN_WARNING "This may stop working in future kernels. "
> + "Please upgrade your libc.\n",
> + current->comm, current->pid);
> +}
> +#endif
> +
> /*
> * For 600- and 800-family processors, the error_code parameter is DSISR
> * for a data fault, SRR1 for an instruction fault. For 400-family processors
> @@ -283,8 +295,16 @@ good_area:
> /* protection fault */
> if (error_code & DSISR_PROTFAULT)
> goto bad_area;
> - if (!(vma->vm_flags & VM_EXEC))
> + if (!(vma->vm_flags & VM_EXEC)) {
> +#ifdef CONFIG_PPC32
> + if (vma->vm_flags & VM_READ)
> + warn_exec_from_noexec();
> + else
> + goto bad_area;
> +#else
> goto bad_area;
> +#endif
> + }
> #else
> pte_t *ptep;
> pmd_t *pmdp;
^ 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