Re: Patches added to powerpc.git powerpc-next and master branches
On Tue, Mar 25, 2008 at 6:54 PM, Josh Boyer [EMAIL PROTECTED] wrote: On Wed, 2008-03-26 at 09:35 +1100, Paul Mackerras wrote: I have added the patches listed below to the master and powerpc-next branches of the powerpc.git repository, and pulled in Linus' current tree. I have some patches floating around that I'll be gathering together in my tree tomorrow. I'll send a pull request then. Josh, do you mind pickup up the following patches? I don't have a public git tree at the moment so this is easier. :-) http://patchwork.ozlabs.org/linuxppc/patch?person=1000id=17388 http://patchwork.ozlabs.org/linuxppc/patch?person=1000id=17386 http://patchwork.ozlabs.org/linuxppc/patch?person=1000id=17387 http://patchwork.ozlabs.org/linuxppc/patch?person=486id=17479 http://patchwork.ozlabs.org/linuxppc/patch?person=486id=17410 Use your discretion on the last two. Cheers, g. -- Grant Likely, B.Sc., P.Eng. Secret Lab Technologies Ltd. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
dtc: Rework handling of boot_cpuid_phys
Currently, dtc will put the nonsense value 0xfeedbeef into the
boot_cpuid_phys field of an output blob, unless explicitly given
another value with the -b command line option. As well as being a
totally unuseful default value, this also means that dtc won't
properly preserve the boot_cpuid_phys field in -I dtb -O dtb mode.
This patch reworks things to improve the boot_cpuid handling. The new
semantics are that the output's boot_cpuid_phys value is:
the value given on the command line if -b is used
otherwise
the value from the input, if in -I dtb mode
otherwise
0
Implementation-wise we do the following:
- boot_cpuid_phys is added to struct boot_info, so that
structure now contains all of the blob's semantic information.
- dt_to_blob() and dt_to_asm() output the cpuid given in
boot_info
- dt_from_blob() fills in boot_info based on the input blob
- The other dt_from_*() functions just record 0, but we can
change this easily if e.g. we invent a way of specifying the boot cpu
in the source format.
- main() overrides the cpuid in the boot_info between input
and output if -b is given
We add some testcases to check this new behaviour.
Signed-off-by: David Gibson [EMAIL PROTECTED]
---
dtc-parser.y |4 +--
dtc.c | 12 +++
dtc.h |9 +++-
flattree.c | 14 ++---
fstree.c |2 -
livetree.c |3 +-
tests/Makefile.tests |2 -
tests/boot-cpuid.c | 48 +
tests/dtbs_equal_ordered.c |7 ++
tests/run_tests.sh |8 +++
10 files changed, 88 insertions(+), 21 deletions(-)
Index: dtc/tests/dtbs_equal_ordered.c
===
--- dtc.orig/tests/dtbs_equal_ordered.c 2008-03-26 17:53:17.0 +1100
+++ dtc/tests/dtbs_equal_ordered.c 2008-03-26 17:53:17.0 +1100
@@ -125,6 +125,7 @@
int main(int argc, char *argv[])
{
void *fdt1, *fdt2;
+ uint32_t cpuid1, cpuid2;
test_init(argc, argv);
if (argc != 3)
@@ -135,5 +136,11 @@
compare_mem_rsv(fdt1, fdt2);
compare_structure(fdt1, fdt2);
+ cpuid1 = fdt_boot_cpuid_phys(fdt1);
+ cpuid2 = fdt_boot_cpuid_phys(fdt2);
+ if (cpuid1 != cpuid2)
+ FAIL(boot_cpuid_phys mismatch 0x%x != 0x%x,
+cpuid1, cpuid2);
+
PASS();
}
Index: dtc/dtc-parser.y
===
--- dtc.orig/dtc-parser.y 2008-03-26 17:53:17.0 +1100
+++ dtc/dtc-parser.y2008-03-26 17:53:17.0 +1100
@@ -85,11 +85,11 @@
sourcefile:
DT_V1 ';' memreserves devicetree
{
- the_boot_info = build_boot_info($3, $4);
+ the_boot_info = build_boot_info($3, $4, 0);
}
| v0_memreserves devicetree
{
- the_boot_info = build_boot_info($1, $2);
+ the_boot_info = build_boot_info($1, $2, 0);
}
;
Index: dtc/dtc.c
===
--- dtc.orig/dtc.c 2008-03-26 17:53:17.0 +1100
+++ dtc/dtc.c 2008-03-26 17:53:17.0 +1100
@@ -120,7 +120,7 @@
int opt;
FILE *outf = NULL;
int outversion = DEFAULT_FDT_VERSION;
- int boot_cpuid_phys = 0xfeedbeef;
+ long long cmdline_boot_cpuid = -1;
quiet = 0;
reservenum = 0;
@@ -160,7 +160,7 @@
quiet++;
break;
case 'b':
- boot_cpuid_phys = strtol(optarg, NULL, 0);
+ cmdline_boot_cpuid = strtoll(optarg, NULL, 0);
break;
case 'v':
printf(Version: %s\n, DTC_VERSION);
@@ -194,9 +194,13 @@
else
die(Unknown input format \%s\\n, inform);
+ if (cmdline_boot_cpuid != -1)
+ bi-boot_cpuid_phys = cmdline_boot_cpuid;
+
fill_fullpaths(bi-dt, );
process_checks(force, bi);
+
if (streq(outname, -)) {
outf = stdout;
} else {
@@ -209,9 +213,9 @@
if (streq(outform, dts)) {
dt_to_source(outf, bi);
} else if (streq(outform, dtb)) {
- dt_to_blob(outf, bi, outversion, boot_cpuid_phys);
+ dt_to_blob(outf, bi, outversion);
} else if (streq(outform, asm)) {
- dt_to_asm(outf, bi, outversion, boot_cpuid_phys);
+ dt_to_asm(outf, bi, outversion);
} else if (streq(outform, null)) {
/* do nothing */
} else {
Index: dtc/dtc.h
===
--- dtc.orig/dtc.h
Re: how to use head_fsl_booke.S:abort to restart
Hi Haiying,
On Tue, Mar 25, 2008 at 04:48:23PM -0400, Haiying Wang wrote:
Ok, I see the problem here. For 8540/60 which has e500 v1 core, it
doesn't use RSTCR to assert HRESET_REQ signal to reset the whole system.
We probably need to add abort() in fsl_rstcr_restart() for those
silicons:
diff --git a/arch/powerpc/sysdev/fsl_soc.c
b/arch/powerpc/sysdev/fsl_soc.c
index 2c5388c..c2d07cd 100644
--- a/arch/powerpc/sysdev/fsl_soc.c
+++ b/arch/powerpc/sysdev/fsl_soc.c
@@ -1434,7 +1434,8 @@ void fsl_rstcr_restart(char *cmd)
if (rstcr)
/* set reset control register */
out_be32(rstcr, 0x2); /* HRESET_REQ */
-
+ else
+ abort();
while (1) ;
}
#endif
I have a 8540 board, and that works, but as your patch is written,
compilation fails with :
arch/powerpc/sysdev/fsl_soc.c: In function 'fsl_rstcr_restart':
arch/powerpc/sysdev/fsl_soc.c:1445: error: implicit declaration
of function 'abort'
arch/powerpc/sysdev/fsl_soc.c:1445: warning: incompatible implicit
declaration of built-in function 'abort'
make[1]: *** [arch/powerpc/sysdev/fsl_soc.o] Error 1
make: *** [arch/powerpc/sysdev] Error 2
and if I fix that with :
arch_initcall(setup_rstcr);
+extern void abort(void);
+
void fsl_rstcr_restart(char *cmd)
{
it compiles and does reboot, but at startup I still get the following
annoying message :
rstcr compatible register does not exist!
Philippe
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] cpm_uart: Allocate DPRAM memory for SMC ports onCPM2-based platforms.
Am Dienstag, den 25.03.2008, 17:32 +0100 schrieb Laurent Pinchart: Do you have any opinion about the proposed patch ? I have to say, it could be some off-topic. But if you would use the cpm_uart-driver for cpm2(or cpm1) as kernel module, at linking you can get warnings about: - cpm_setbrg (cpm_set_brg): something with section mismatch - __alloc_bootmem (cpm_uart_allocbuf): the same The symbols are not exported. Is it ok, about kernel modules? Sergej. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Could PowerPC(IBM power blade, js 21, 8844) boot via usb key?
Hi guys, I created a PReP partition in usb key and then did dd and something like that to configure yaboot on it. But the key point is that, when I boot power blade, there is not usb key in the bootable list. I mean, there are just: 1.- Ethernet ( loc=U788D.001.99DXC6K-P1-T7 ) 2.- Ethernet ( loc=U788D.001.99DXC6K-P1-T8 ) 3.- USB CD-ROM ( loc=U788D.001.99DXC6K-P1-T1-L1-L3 ) 4.1 SCSI 36401 MB Harddisk, part=1 () ( loc=U788D.001.99DXC6K-P1-T10-L1-L0 ) My usb key is Kingston's DataTraveler 2GB. Then I change another Sandisk cruzer 2GB usb key, it shows as follows in the boot menu: 1.- Ethernet ( loc=U788D.001.99DXC6K-P1-T7 ) 2.- Ethernet ( loc=U788D.001.99DXC6K-P1-T8 ) 3.- USB CD-ROM ( loc=U788D.001.99DXC6K-P1-T1-L1-L3 ) 4.1 SCSI 36401 MB Harddisk, part=1 () ( loc=U788D.001.99DXC6K-P1-T10-L1-L0 ) 5.- USB CD-ROM ( loc=U788D.001.99DXC6K-P1-T1-L1-L2-L1-L0 ) But this item 5 USB CD-ROM is simulated by Sandisk, not the actual usb key. I can't boot my server via item 5. Could IBM power blade, js 21, 8844 boot via usb key? If not, could you please provide official doc to prove it. Because I have to persuade my boss to give up it. -:) Any comment is appreciated. Thanks a lot in advanced. Kelvin. - 雅虎邮箱，您的终生邮箱！___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCHv2 0/3] cpm2: Reset the CPM at startup and fix the cpm_uart driver accordingly.
Hi everybody, these 3 patches reset the CPM in cpm2_reset() and fix the cpm_uart driver to initialise SMC ports correctly without relying on any initialisation performed by the boot loader/wrapper. They update the EP8248E device tree to match the new SMC registers description. -- Laurent Pinchart CSE Semaphore Belgium Chaussée de Bruxelles, 732A B-1410 Waterloo Belgium T +32 (2) 387 42 59 F +32 (2) 387 42 75 pgpT05gWeKPZI.pgp Description: PGP signature ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCHv2 1/3] cpm_uart: Allocate DPRAM memory for SMC ports on CPM2-based platforms.
This patch allocates parameter RAM for SMC serial ports without relying on
previous initialisation by a boot loader or a wrapper layer.
SMC parameter RAM on CPM2-based platforms can be allocated anywhere in the
general-purpose areas of the dual-port RAM. The current code relies on the
boot loader to allocate a section of general-purpose CPM RAM and gets the
section address from the device tree.
This patch modifies the device tree address usage to reference the SMC
parameter RAM base pointer instead of a pre-allocated RAM section and
allocates memory from the CPM dual-port RAM when initialising the SMC port.
CPM1-based platforms are not affected.
Signed-off-by: Laurent Pinchart [EMAIL PROTECTED]
---
drivers/serial/cpm_uart/cpm_uart.h |3 ++
drivers/serial/cpm_uart/cpm_uart_core.c | 19 +--
drivers/serial/cpm_uart/cpm_uart_cpm1.c | 12 +++
drivers/serial/cpm_uart/cpm_uart_cpm2.c | 52 +++
4 files changed, 76 insertions(+), 10 deletions(-)
diff --git a/drivers/serial/cpm_uart/cpm_uart.h
b/drivers/serial/cpm_uart/cpm_uart.h
index 80a7d60..5334653 100644
--- a/drivers/serial/cpm_uart/cpm_uart.h
+++ b/drivers/serial/cpm_uart/cpm_uart.h
@@ -93,6 +93,9 @@ extern struct uart_cpm_port cpm_uart_ports[UART_NR];
/* these are located in their respective files */
void cpm_line_cr_cmd(struct uart_cpm_port *port, int cmd);
+void __iomem *cpm_uart_map_pram(struct uart_cpm_port *port,
+ struct device_node *np);
+void cpm_uart_unmap_pram(struct uart_cpm_port *port, void __iomem *pram);
int cpm_uart_init_portdesc(void);
int cpm_uart_allocbuf(struct uart_cpm_port *pinfo, unsigned int is_con);
void cpm_uart_freebuf(struct uart_cpm_port *pinfo);
diff --git a/drivers/serial/cpm_uart/cpm_uart_core.c
b/drivers/serial/cpm_uart/cpm_uart_core.c
index 1ea123c..3a44a3f 100644
--- a/drivers/serial/cpm_uart/cpm_uart_core.c
+++ b/drivers/serial/cpm_uart/cpm_uart_core.c
@@ -997,24 +997,23 @@ static int cpm_uart_init_port(struct device_node *np,
if (!mem)
return -ENOMEM;
- pram = of_iomap(np, 1);
- if (!pram) {
- ret = -ENOMEM;
- goto out_mem;
- }
-
if (of_device_is_compatible(np, fsl,cpm1-scc-uart) ||
of_device_is_compatible(np, fsl,cpm2-scc-uart)) {
pinfo-sccp = mem;
- pinfo-sccup = pram;
+ pinfo-sccup = pram = cpm_uart_map_pram(pinfo, np);
} else if (of_device_is_compatible(np, fsl,cpm1-smc-uart) ||
of_device_is_compatible(np, fsl,cpm2-smc-uart)) {
pinfo-flags |= FLAG_SMC;
pinfo-smcp = mem;
- pinfo-smcup = pram;
+ pinfo-smcup = pram = cpm_uart_map_pram(pinfo, np);
} else {
ret = -ENODEV;
- goto out_pram;
+ goto out_mem;
+ }
+
+ if (!pram) {
+ ret = -ENOMEM;
+ goto out_mem;
}
pinfo-tx_nrfifos = TX_NUM_FIFO;
@@ -1038,7 +1037,7 @@ static int cpm_uart_init_port(struct device_node *np,
return cpm_uart_request_port(pinfo-port);
out_pram:
- iounmap(pram);
+ cpm_uart_unmap_pram(pinfo, pram);
out_mem:
iounmap(mem);
return ret;
diff --git a/drivers/serial/cpm_uart/cpm_uart_cpm1.c
b/drivers/serial/cpm_uart/cpm_uart_cpm1.c
index 6ea0366..e692593 100644
--- a/drivers/serial/cpm_uart/cpm_uart_cpm1.c
+++ b/drivers/serial/cpm_uart/cpm_uart_cpm1.c
@@ -54,6 +54,18 @@ void cpm_line_cr_cmd(struct uart_cpm_port *port, int cmd)
{
cpm_command(port-command, cmd);
}
+
+void __iomem *cpm_uart_map_pram(struct uart_cpm_port *port,
+ struct device_node *np)
+{
+ return of_iomap(np, 1);
+}
+
+void cpm_uart_unmap_pram(struct uart_cpm_port *port, void __iomem *pram)
+{
+ iounmap(pram);
+}
+
#else
void cpm_line_cr_cmd(struct uart_cpm_port *port, int cmd)
{
diff --git a/drivers/serial/cpm_uart/cpm_uart_cpm2.c
b/drivers/serial/cpm_uart/cpm_uart_cpm2.c
index 6291094..a4cfb0b 100644
--- a/drivers/serial/cpm_uart/cpm_uart_cpm2.c
+++ b/drivers/serial/cpm_uart/cpm_uart_cpm2.c
@@ -41,6 +41,9 @@
#include asm/io.h
#include asm/irq.h
#include asm/fs_pd.h
+#ifdef CONFIG_PPC_CPM_NEW_BINDING
+#include asm/prom.h
+#endif
#include linux/serial_core.h
#include linux/kernel.h
@@ -54,6 +57,55 @@ void cpm_line_cr_cmd(struct uart_cpm_port *port, int cmd)
{
cpm_command(port-command, cmd);
}
+
+void __iomem *cpm_uart_map_pram(struct uart_cpm_port *port,
+ struct device_node *np)
+{
+ void __iomem *pram;
+ unsigned long offset;
+ struct resource res;
+ unsigned long len;
+
+ /* Don't remap parameter RAM if it has already been initialized
+* during console setup.
+*/
+ if (IS_SMC(port) port-smcup)
+ return port-smcup;
+ else if (!IS_SMC(port) port-sccup)
+
[PATCHv2 2/3] ep8248e: Reference SMC parameter RAM base in the device tree.
This patch modifies the Embedded Planet EP8248E device tree to reference the
SMC paramater RAM base register instead of the parameter RAM allocated by the
boot loader.
The cpm_uart driver will allocate parameter RAM itself, making the serial port
initialisation independent of the boot loader.
Signed-off-by: Laurent Pinchart [EMAIL PROTECTED]
---
arch/powerpc/boot/dts/ep8248e.dts |5 ++---
1 files changed, 2 insertions(+), 3 deletions(-)
diff --git a/arch/powerpc/boot/dts/ep8248e.dts
b/arch/powerpc/boot/dts/ep8248e.dts
index 5d2fb76..756758f 100644
--- a/arch/powerpc/boot/dts/ep8248e.dts
+++ b/arch/powerpc/boot/dts/ep8248e.dts
@@ -121,8 +121,7 @@
[EMAIL PROTECTED] {
compatible = fsl,cpm-muram-data;
- reg = 0 0x1100 0x1140
- 0xec0 0x9800 0x800;
+ reg = 0 0x2000 0x9800 0x800;
};
};
@@ -138,7 +137,7 @@
device_type = serial;
compatible = fsl,mpc8248-smc-uart,
fsl,cpm2-smc-uart;
- reg = 0x11a80 0x20 0x1100 0x40;
+ reg = 0x11a80 0x20 0x87fc 2;
interrupts = 4 8;
interrupt-parent = PIC;
fsl,cpm-brg = 7;
--
1.5.0
--
Laurent Pinchart
CSE Semaphore Belgium
Chaussée de Bruxelles, 732A
B-1410 Waterloo
Belgium
T +32 (2) 387 42 59
F +32 (2) 387 42 75
pgpfdPlbxgeFx.pgp
Description: PGP signature
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCHv2 0/3] cpm2: Reset the CPM when early debugging is not enabled.
Similarly to what is done for PQ1-based platforms, this patch resets the PQ2 Communication Processor Module in cpm2_reset() when early debugging is not enabled. This helps avoiding conflicts when the boot loader configured the CPM in an unexpected way. Signed-off-by: Laurent Pinchart [EMAIL PROTECTED] --- arch/powerpc/sysdev/cpm2.c |6 ++ 1 files changed, 6 insertions(+), 0 deletions(-) diff --git a/arch/powerpc/sysdev/cpm2.c b/arch/powerpc/sysdev/cpm2.c index 7be7112..57ed1a4 100644 --- a/arch/powerpc/sysdev/cpm2.c +++ b/arch/powerpc/sysdev/cpm2.c @@ -80,6 +80,12 @@ void __init cpm2_reset(void) /* Tell everyone where the comm processor resides. */ cpmp = cpm2_immr-im_cpm; + +#ifndef CONFIG_PPC_EARLY_DEBUG_CPM + /* Reset the CPM. +*/ + cpm_command(CPM_CR_RST, 0); +#endif } static DEFINE_SPINLOCK(cmd_lock); -- 1.5.0 -- Laurent Pinchart CSE Semaphore Belgium Chaussée de Bruxelles, 732A B-1410 Waterloo Belgium T +32 (2) 387 42 59 F +32 (2) 387 42 75 pgpN9vhUtQFHw.pgp Description: PGP signature ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCHv2 0/3] cpm2: Reset the CPM when early debugging is not enabled.
This one should of course have been PATCHv2 3/3. -- Laurent Pinchart CSE Semaphore Belgium Chaussée de Bruxelles, 732A B-1410 Waterloo Belgium T +32 (2) 387 42 59 F +32 (2) 387 42 75 pgplBaVg4MUjK.pgp Description: PGP signature ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH 2/2 v3] [POWERPC] Add L2 cache node to AMCC Taishan dts file
This patch adds the L2 cache node to the Taishan 440GX dts file.
Signed-off-by: Stefan Roese [EMAIL PROTECTED]
---
ver3:
Nothing changed
ver2:
Unit address removed.
arch/powerpc/boot/dts/taishan.dts | 10 ++
1 files changed, 10 insertions(+), 0 deletions(-)
diff --git a/arch/powerpc/boot/dts/taishan.dts
b/arch/powerpc/boot/dts/taishan.dts
index 8278068..d0bff33 100644
--- a/arch/powerpc/boot/dts/taishan.dts
+++ b/arch/powerpc/boot/dts/taishan.dts
@@ -104,6 +104,16 @@
// FIXME: anything else?
};
+ L2C0: l2c {
+ compatible = ibm,l2-cache-440gx, ibm,l2-cache;
+ dcr-reg = 20 8 /* Internal SRAM DCR's */
+ 30 8; /* L2 cache DCR's */
+ cache-line-size = 20; /* 32 bytes */
+ cache-size = 4; /* L2, 256K */
+ interrupt-parent = UIC2;
+ interrupts = 17 1;
+ };
+
plb {
compatible = ibm,plb-440gx, ibm,plb4;
#address-cells = 2;
--
1.5.4.4
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] cpm_uart: Allocate DPRAM memory for SMC ports onCPM2-based platforms.
On Wednesday 26 March 2008 09:31, Sergej Stepanov wrote: Am Dienstag, den 25.03.2008, 17:32 +0100 schrieb Laurent Pinchart: Do you have any opinion about the proposed patch ? I have to say, it could be some off-topic. But if you would use the cpm_uart-driver for cpm2(or cpm1) as kernel module, at linking you can get warnings about: - cpm_setbrg (cpm_set_brg): something with section mismatch - __alloc_bootmem (cpm_uart_allocbuf): the same The symbols are not exported. Is it ok, about kernel modules? I get the same section-mismatch warning for __alloc_bootmem in cpm_uart_allocbuf. cpm_setbrg doesn't cause any warning here. Best regards, -- Laurent Pinchart CSE Semaphore Belgium Chaussée de Bruxelles, 732A B-1410 Waterloo Belgium T +32 (2) 387 42 59 F +32 (2) 387 42 75 pgpMpqMw7ZVe4.pgp Description: PGP signature ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 1/2] ibm_newemac: PowerPC 440GX EMAC PHY clock workaround
On Tue, 25 Mar 2008 10:21:53 +1100 Benjamin Herrenschmidt [EMAIL PROTECTED] wrote: On Thu, 2008-03-06 at 16:41 +0300, Valentine Barshak wrote: The PowerPC 440GX Taishan board fails to reset EMAC3 (reset timeout error) if there's no link. Because of that it fails to find PHY chip. The older ibm_emac driver had a workaround for that: the EMAC_CLK_INTERNAL/EMAC_CLK_EXTERNAL macros, which toggle the Ethernet Clock Select bit in the SDR0_MFR register. This patch does the same for ibm,emac-440gx compatible chips. The workaround forces clock on -all- EMACs, so we select clock under global emac_phy_map_lock. Signed-off-by: Valentine Barshak [EMAIL PROTECTED] Acked-by: Benjamin Herrenschmidt [EMAIL PROTECTED] Just get them acked by Jeff now and they can go in via Josh tree. This never went to netdev or Jeff from what I can see. josh ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 2/2] pasemi_mac: Netpoll support
Olof Johansson wrote:
Add netpoll support to allow use of netconsole.
Signed-off-by: Nate Case [EMAIL PROTECTED]
Signed-off-by: Olof Johansson [EMAIL PROTECTED]
diff --git a/drivers/net/pasemi_mac.c b/drivers/net/pasemi_mac.c
index abb1dc4..6030ffe 100644
--- a/drivers/net/pasemi_mac.c
+++ b/drivers/net/pasemi_mac.c
@@ -1648,6 +1648,26 @@ static int pasemi_mac_poll(struct napi_struct *napi, int
budget)
return pkts;
}
+#ifdef CONFIG_NET_POLL_CONTROLLER
+/*
+ * Polling 'interrupt' - used by things like netconsole to send skbs
+ * without having to re-enable interrupts. It's not called while
+ * the interrupt routine is executing.
+ */
+static void pasemi_mac_netpoll(struct net_device *dev)
+{
+ const struct pasemi_mac *mac = netdev_priv(dev);
+
+ disable_irq(mac-tx-chan.irq);
+ pasemi_mac_tx_intr(mac-tx-chan.irq, mac-tx);
+ enable_irq(mac-tx-chan.irq);
+
+ disable_irq(mac-rx-chan.irq);
+ pasemi_mac_rx_intr(mac-rx-chan.irq, dev);
Shouldn't this actually be pasemi_mac_rx_intr(mac-rx-chan.irq, mac-rx)?
Thanks,
Valentine.
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH 1/2] [MTD] Add support for RAM ROM mappings in the physmap_of MTD driver.
Signed-off-by: Laurent Pinchart [EMAIL PROTECTED]
---
drivers/mtd/maps/physmap_of.c |8
1 files changed, 8 insertions(+), 0 deletions(-)
diff --git a/drivers/mtd/maps/physmap_of.c b/drivers/mtd/maps/physmap_of.c
index 49acd41..65c30b5 100644
--- a/drivers/mtd/maps/physmap_of.c
+++ b/drivers/mtd/maps/physmap_of.c
@@ -273,6 +273,14 @@ static struct of_device_id of_flash_match[] = {
.data = (void *)jedec_probe,
},
{
+ .compatible = physmap-ram,
+ .data = (void *)map_ram,
+ },
+ {
+ .compatible = physmap-rom,
+ .data = (void *)map_rom,
+ },
+ {
.type = rom,
.compatible = direct-mapped
},
--
1.5.0
--
Laurent Pinchart
CSE Semaphore Belgium
Chaussée de Bruxelles, 732A
B-1410 Waterloo
Belgium
T +32 (2) 387 42 59
F +32 (2) 387 42 75
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: Patch: FW:Xilinx: BSP: Updated ML405 to match hardware used for testing
Hello all, I'm trying to get things up and running on a Xilinx Virtex-4 ml405 board, and as such I've been trying to figure out the following recent message to the list: http://patchwork.ozlabs.org/linuxppc/patch?person=1226id=17037 I don't understand what this patch applies to: it references files such as ml405_defconfig which are not part of the normal kernel tree and which I cannot find anywhere. Is there some other kind of patch that needs to apply first in order to get for instance CONFIG_XILINX_DRIVERS, CONFIG_XILINX_EMAC, etc... Thanks -- Guillaume Dargaud http://www.gdargaud.net/ ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH 2/2] [POWERPC] Describe memory-mapped RAMROM chips of bindings
Signed-off-by: Laurent Pinchart [EMAIL PROTECTED]
---
Documentation/powerpc/booting-without-of.txt | 31 +-
1 files changed, 30 insertions(+), 1 deletions(-)
diff --git a/Documentation/powerpc/booting-without-of.txt
b/Documentation/powerpc/booting-without-of.txt
index 7b4e8a7..53d1cf8 100644
--- a/Documentation/powerpc/booting-without-of.txt
+++ b/Documentation/powerpc/booting-without-of.txt
@@ -57,7 +57,8 @@ Table of Contents
n) 4xx/Axon EMAC ethernet nodes
o) Xilinx IP cores
p) Freescale Synchronous Serial Interface
- q) USB EHCI controllers
+ q) USB EHCI controllers
+ r) Memory-mapped RAM ROM
VII - Specifying interrupt information for devices
1) interrupts property
@@ -2816,6 +2817,34 @@ platforms are moved over to use the
flattened-device-tree model.
big-endian;
};
+ r) Memory-mapped RAM ROM
+
+Dedicated RAM and ROM chips are often used as storage for temporary or
+permanent data in embedded devices. Possible usage include non-volatile
+storage in battery-backed SRAM, semi-permanent storage in dedicated SRAM
+to preserve data accross reboots and firmware storage in dedicated ROM.
+
+ - compatible : should contain the specific model of RAM/ROM chip(s)
+ used, if known, followed by either physmap-ram or physmap-rom
+ - reg : Address range of the RAM/ROM chip
+ - bank-width : Width (in bytes) of the RAM/ROM bank. Equal to the
+ device width times the number of interleaved chips.
+ - device-width : (optional) Width of a single RAM/ROM chip. If
+ omitted, assumed to be equal to 'bank-width'.
+
+Similarly to memory-mapped NOR flash, memory-mapped RAM ROM chips
+can be partionned. See the j) CFI and JEDEC memory-mapped NOR flash
+section for information about how to represent partitions in the
+device tree.
+
+Example:
+
+ [EMAIL PROTECTED] {
+ compatible = renesas,m5m5w816, physmap-ram;
+ reg = f200 0010;
+ bank-width = 2;
+ };
+
More devices will be defined as this spec matures.
--
1.5.0
--
Laurent Pinchart
CSE Semaphore Belgium
Chaussée de Bruxelles, 732A
B-1410 Waterloo
Belgium
T +32 (2) 387 42 59
F +32 (2) 387 42 75
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: OF compatible MTD platform RAM driver ?
Laurent Pinchart wrote: Regarding non-volatility nothing prevents a user from using a volatile RAM as an MTD device, but there's little point in doing so. Would it be acceptable for the linear-nvram specification not to include volatile RAM ? ROM chips would be excluded too. Is that an issue ? We actually use a volatile ram (SRAM) as an MTD device. We use it to store info from bootloader and system specific values between resets. So we're left with two main options. - Reusing the nvram device type from the Device Support Extensions. Volatile devices wouldn't be supported, and we'd need a separate device specification for linear-mapped volatile RAMs. I'm not very happy with that. - Using another device node with a compatible value set to linear-ram (or something similar). This would support both volatile and non-volatile devices, and a property could be added to specify if the device is volatile or not. I'd go for the second option, and I'd specify a linear-rom compatible value as well while we're at it. Both volatile and non-volatile RAMs can be handled by the physmap_of MTD driver. They both use the same map probe type (map_ram). Volatility isn't handled there. ROMs should be handled by the same driver and should use the mtd_rom map probe type. OK, let's go with it. As all those devices use the physmap_of MTD driver, what about using physmap-ram and physmap-rom as compatibility names ? Heh, we've gone thru physmap before -- it was labelled Linux-specific name (well, I'd agree with that). Best regards, WBR, Sergei ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: Patch: FW:Xilinx: BSP: Updated ML405 to match hardware used for testing
On Wed, Mar 26, 2008 at 5:47 AM, Guillaume Dargaud [EMAIL PROTECTED] wrote: Hello all, I'm trying to get things up and running on a Xilinx Virtex-4 ml405 board, and as such I've been trying to figure out the following recent message to the list: http://patchwork.ozlabs.org/linuxppc/patch?person=1226id=17037 I don't understand what this patch applies to: it references files such as ml405_defconfig which are not part of the normal kernel tree and which I cannot find anywhere. Is there some other kind of patch that needs to apply first in order to get for instance CONFIG_XILINX_DRIVERS, CONFIG_XILINX_EMAC, etc... Thanks It applies to Xilinx's git tree of the Linux kernel. g. -- Grant Likely, B.Sc., P.Eng. Secret Lab Technologies Ltd. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
RE: [PATCH 0/2] Add support for RAM ROM mappings to the physmap_of driver
Laurent Pinchart wrote: Hi everybody, these two patches add support for memory-mapped RAM ROM chips to the physmap_of MTD driver. Whole series acked-by: Rune Torgersen [EMAIL PROTECTED] ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: dtc: Trivial formatting fixes
This patch fixes some trivial indentation and brace/bracket style
problems.
@@ -179,9 +179,8 @@
arg = argv[optind];
/* minsize and padsize are mutually exclusive */
- if ((minsize) (padsize)) {
+ if (minsize padsize)
die(Can't set both -p and -S\n);
- }
I do not consider extra braces a problem, and will
not be applying those changes. The other indentation
fixes will be applied, of course.
jdl
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH v3][OF] Add of_device_is_available function
IEEE 1275 defined a standard status property to indicate the operational
status of a device. The property has four possible values: okay, disabled,
fail, fail-xxx. The absence of this property means the operational status
of the device is unknown or okay.
This adds a function called of_device_is_available that checks the state
of the status property of a device. If the property is absent or set to
either okay or ok, it returns 1. Otherwise it returns 0.
Signed-off-by: Josh Boyer [EMAIL PROTECTED]
---
drivers/of/base.c | 26 ++
include/linux/of.h |1 +
2 files changed, 27 insertions(+)
--- linux-2.6.orig/drivers/of/base.c
+++ linux-2.6/drivers/of/base.c
@@ -117,6 +117,32 @@ int of_device_is_compatible(const struct
EXPORT_SYMBOL(of_device_is_compatible);
/**
+ * of_device_is_available - check if a device is available for use
+ *
+ * @device: Node to check for availability
+ *
+ * Returns 1 if the status property is absent or set to okay or ok,
+ * 0 otherwise
+ */
+int of_device_is_available(const struct device_node *device)
+{
+ const char *status;
+ int statlen;
+
+ status = of_get_property(device, status, statlen);
+ if (status == NULL)
+ return 1;
+
+ if (statlen 0) {
+ if (!strcmp(status, okay) || !strcmp(status, ok))
+ return 1;
+ }
+
+ return 0;
+}
+EXPORT_SYMBOL(of_device_is_available);
+
+/**
* of_get_parent - Get a node's parent if any
* @node: Node to get parent
*
--- linux-2.6.orig/include/linux/of.h
+++ linux-2.6/include/linux/of.h
@@ -62,6 +62,7 @@ extern struct property *of_find_property
int *lenp);
extern int of_device_is_compatible(const struct device_node *device,
const char *);
+extern int of_device_is_available(const struct device_node *device);
extern const void *of_get_property(const struct device_node *node,
const char *name,
int *lenp);
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [RESEND] [PATCH 1/2 v2] [OF] Add of_device_is_available function
We really want just okay and ok. Look for a version 3 of the patch that fixes it later today. You might want to put in a comment that says ok is only a workaround for some broken systems, too. Segher ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 2/2] [POWERPC] Describe memory-mapped RAMROM chips of bindings
+Dedicated RAM and ROM chips are often used as storage for temporary or +permanent data in embedded devices. Possible usage include non-volatile +storage in battery-backed SRAM, semi-permanent storage in dedicated SRAM +to preserve data accross reboots and firmware storage in dedicated ROM. + + - compatible : should contain the specific model of RAM/ROM chip(s) + used, if known, followed by either physmap-ram or physmap-rom + - reg : Address range of the RAM/ROM chip + - bank-width : Width (in bytes) of the RAM/ROM bank. Equal to the + device width times the number of interleaved chips. + - device-width : (optional) Width of a single RAM/ROM chip. If + omitted, assumed to be equal to 'bank-width'. Maybe I'm rehashing some old discussion here, if so, sorry; but why do you have bank-width and device-width here? What useful information does it provide? If this is about saying what the preferred (or only possible) access width is, better names are in order. Segher ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: OF compatible MTD platform RAM driver ?
So we're left with two main options. - Reusing the nvram device type from the Device Support Extensions. This wouldn't bring you anything. A device_type is only used internally by OF, to decide what device nodes support which OF programming model. If you only have a flat device tree, device_type should be used only as a workaround for older kernels that require it. - Using another device node with a compatible value set to linear-ram (or something similar). This would support both volatile and non-volatile devices, and a property could be added to specify if the device is volatile or not. memory-mapped-memory perhaps :-) Or, just memory. Although that one might play havoc with some not-quite-correct main memory probing code. Segher ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 1/2] [MTD] Add support for RAM ROM mappings in the physmap_of MTD driver.
Segher Boessenkool wrote:
{
+.compatible= physmap-ram,
+.data= (void *)map_ram,
+},
+{
+.compatible= physmap-rom,
+.data= (void *)map_rom,
+},
Why the cast? It's redundant afaics.
To be in line with the surrounding code...
Segher
WBR, Sergei
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCHv2 2/3] ep8248e: Reference SMC parameter RAM base in the device tree.
On Wed, Mar 26, 2008 at 12:20:42PM +0100, Laurent Pinchart wrote:
diff --git a/arch/powerpc/boot/dts/ep8248e.dts
b/arch/powerpc/boot/dts/ep8248e.dts
index 5d2fb76..756758f 100644
--- a/arch/powerpc/boot/dts/ep8248e.dts
+++ b/arch/powerpc/boot/dts/ep8248e.dts
@@ -121,8 +121,7 @@
[EMAIL PROTECTED] {
compatible = fsl,cpm-muram-data;
- reg = 0 0x1100 0x1140
-0xec0 0x9800 0x800;
+ reg = 0 0x2000 0x9800 0x800;
};
Can we leave this as reserved, so that udbg still works?
-Scott
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: OF compatible MTD platform RAM driver ?
Segher Boessenkool wrote: - Using another device node with a compatible value set to linear-ram (or something similar). This would support both volatile and non-volatile devices, and a property could be added to specify if the device is volatile or not. memory-mapped-memory perhaps :-) Or, just memory. Although that one might play havoc with some I'd suggest ram and rom then. Luckily the device trees don't contain binding for the real RAM chips yet. :-) not-quite-correct main memory probing code. You mean the there's parsers that search the compatible prop for memory as well as device_type prop? Segher WBR, Sergei ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH] [POWERPC] 85xx: Cleanup TLB initialization
* Determine the RPN we are running the kernel at runtime rather
than using compile time constant for initial TLB
* Cleanup adjust_total_lowmem() to respect memstart_addr and
be a bit more clear on variables that are sizes vs addresses.
Signed-off-by: Kumar Gala [EMAIL PROTECTED]
---
arch/powerpc/kernel/head_fsl_booke.S | 34 --
arch/powerpc/mm/fsl_booke_mmu.c | 37 ++---
2 files changed, 43 insertions(+), 28 deletions(-)
diff --git a/arch/powerpc/kernel/head_fsl_booke.S
b/arch/powerpc/kernel/head_fsl_booke.S
index d9cc2c2..3b69b54 100644
--- a/arch/powerpc/kernel/head_fsl_booke.S
+++ b/arch/powerpc/kernel/head_fsl_booke.S
@@ -68,7 +68,9 @@ _ENTRY(_start);
mr r29,r5
mr r28,r6
mr r27,r7
+ li r25,0 /* phys kernel start (low) */
li r24,0 /* CPU number */
+ li r23,0 /* phys kernel start (high) */
/* We try to not make any assumptions about how the boot loader
* setup or used the TLBs. We invalidate all mappings from the
@@ -167,7 +169,28 @@ skpinv:addir6,r6,1 /*
Increment */
mtspr SPRN_MAS0,r7
tlbre
- /* Just modify the entry ID, EPN and RPN for the temp mapping */
+ /* grab and fixup the RPN */
+ mfspr r6,SPRN_MAS1/* extract MAS1[SIZE] */
+ rlwinm r6,r6,25,27,30
+ li r8,-1
+ addir6,r6,10
+ slw r6,r8,r6/* convert to mask */
+
+ bl 1f /* Find our address */
+1: mflrr7
+
+ mfspr r8,SPRN_MAS3
+#ifdef CONFIG_PHYS_64BIT
+ mfspr r23,SPRN_MAS7
+#endif
+ and r8,r6,r8
+ subfic r9,r6,-4096
+ and r9,r9,r7
+
+ or r25,r8,r9
+ ori r8,r25,(MAS3_SX|MAS3_SW|MAS3_SR)
+
+ /* Just modify the entry ID and EPN for the temp mapping */
lis r7,0x1000 /* Set MAS0(TLBSEL) = 1 */
rlwimi r7,r5,16,4,15 /* Setup MAS0 = TLBSEL | ESEL(r5) */
mtspr SPRN_MAS0,r7
@@ -177,12 +200,10 @@ skpinv: addir6,r6,1 /*
Increment */
ori r6,r6,(MAS1_TSIZE(BOOKE_PAGESZ_4K))@l
mtspr SPRN_MAS1,r6
mfspr r6,SPRN_MAS2
- lis r7,[EMAIL PROTECTED]
+ li r7,0/* temp EPN = 0 */
rlwimi r7,r6,0,20,31
mtspr SPRN_MAS2,r7
- mfspr r6,SPRN_MAS3
- rlwimi r7,r6,0,20,31
- mtspr SPRN_MAS3,r7
+ mtspr SPRN_MAS3,r8
tlbwe
xorir6,r4,1
@@ -232,8 +253,7 @@ skpinv: addir6,r6,1 /*
Increment */
ori r6,r6,[EMAIL PROTECTED]
rlwimi r6,r7,0,20,31
mtspr SPRN_MAS2,r6
- li r7,(MAS3_SX|MAS3_SW|MAS3_SR)
- mtspr SPRN_MAS3,r7
+ mtspr SPRN_MAS3,r8
tlbwe
/* 7. Jump to KERNELBASE mapping */
diff --git a/arch/powerpc/mm/fsl_booke_mmu.c b/arch/powerpc/mm/fsl_booke_mmu.c
index 3dd0c81..59f6649 100644
--- a/arch/powerpc/mm/fsl_booke_mmu.c
+++ b/arch/powerpc/mm/fsl_booke_mmu.c
@@ -49,7 +49,6 @@
#include asm/mmu.h
#include asm/uaccess.h
#include asm/smp.h
-#include asm/bootx.h
#include asm/machdep.h
#include asm/setup.h
@@ -59,7 +58,6 @@ extern void loadcam_entry(unsigned int index);
unsigned int tlbcam_index;
unsigned int num_tlbcam_entries;
static unsigned long __cam0, __cam1, __cam2;
-#define MAX_LOW_MEMCONFIG_LOWMEM_SIZE
#define NUM_TLBCAMS(16)
@@ -195,35 +193,32 @@ unsigned long __init mmu_mapin_ram(void)
void __init
adjust_total_lowmem(void)
{
- unsigned long max_low_mem = MAX_LOW_MEM;
- unsigned long cam_max = 0x1000;
- unsigned long ram;
+ phys_addr_t max_lowmem_size = __max_low_memory;
+ phys_addr_t cam_max_size = 0x1000;
+ phys_addr_t ram;
- /* adjust CAM size to max_low_mem */
- if (max_low_mem cam_max)
- cam_max = max_low_mem;
+ /* adjust CAM size to max_lowmem_size */
+ if (max_lowmem_size cam_max_size)
+ cam_max_size = max_lowmem_size;
- /* adjust lowmem size to max_low_mem */
- if (max_low_mem total_lowmem)
- ram = max_low_mem;
- else
- ram = total_lowmem;
+ /* adjust lowmem size to max_lowmem_size */
+ ram = min(max_lowmem_size, total_lowmem);
/* Calculate CAM values */
__cam0 = 1UL 2 * (__ilog2(ram) / 2);
- if (__cam0 cam_max)
- __cam0 = cam_max;
+ if (__cam0 cam_max_size)
+ __cam0 = cam_max_size;
ram -= __cam0;
if (ram) {
__cam1 = 1UL 2 * (__ilog2(ram) / 2);
- if (__cam1 cam_max)
- __cam1 = cam_max;
+ if (__cam1 cam_max_size)
+ __cam1 = cam_max_size;
ram -= __cam1;
}
if (ram) {
__cam2 = 1UL 2 *
Missing patch for MPC5200B register definitions?
I've just been looking into the MPC5200B AC97 driver breakage with the latest Git kernel, and found the following patch; http://ozlabs.org/pipermail/linuxppc-dev/2007-May/035952.html Is not in the latest tree. As such anything which uses the new MPC5200B registers (especially important on AC97 and probably not used otherwise) has not or was not applied. Since the latest kernel source from git actually includes the MPC5121E differences, I assume this is a regression? How do we go about fixing this? -- Matt Sealey [EMAIL PROTECTED] Genesi, Manager, Developer Relations ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: Missing patch for MPC5200B register definitions?
Oh yes, I forgot.. also, the new MPC5121E stuff includes a lot of unions and defines to make using both PSC formats easier. Since the MPC5200 and MPC5200B PSC structures are different (CCR size), can the original suggestion (in that thread) to support both with a union and some defines to make supporting both CCR sizes, be implemented, or do we still think that MPC5200 (not B) is not worth supporting? -- Matt Sealey [EMAIL PROTECTED] Genesi, Manager, Developer Relations Matt Sealey wrote: I've just been looking into the MPC5200B AC97 driver breakage with the latest Git kernel, and found the following patch; http://ozlabs.org/pipermail/linuxppc-dev/2007-May/035952.html Is not in the latest tree. As such anything which uses the new MPC5200B registers (especially important on AC97 and probably not used otherwise) has not or was not applied. Since the latest kernel source from git actually includes the MPC5121E differences, I assume this is a regression? How do we go about fixing this? ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCHv2 2/3] ep8248e: Reference SMC parameter RAM base in the device tree.
Laurent Pinchart wrote: @@ -138,7 +137,7 @@ device_type = serial; compatible = fsl,mpc8248-smc-uart, fsl,cpm2-smc-uart; - reg = 0x11a80 0x20 0x1100 0x40; + reg = 0x11a80 0x20 0x87fc 2; interrupts = 4 8; interrupt-parent = PIC; fsl,cpm-brg = 7; This breaks the bootwrapper console. -Scott ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] [POWERPC] CPM1: implement GPIO LIB API
Hi Scott,
diff --git a/arch/powerpc/platforms/8xx/Kconfig
b/arch/powerpc/platforms/8xx/Kconfig
index 7fd224c..e12cbf0 100644
--- a/arch/powerpc/platforms/8xx/Kconfig
+++ b/arch/powerpc/platforms/8xx/Kconfig
@@ -4,6 +4,8 @@ config FADS
config CPM1
bool
select CPM
+select GENERIC_GPIO
+select GPIO_LIB
Shouldn't this depend on the user enabling GPIO support? Some 8xx
boards are very memory-constrained, so we don't want to be making the
kernel even bigger than it already is unless it's actually needed.
Are you more comfortable with this?
Implement GPIO LIB API on CPM1 Freescale SoC.
Signed-off-by: Jochen Friedrich [EMAIL PROTECTED]
---
arch/powerpc/platforms/8xx/Kconfig | 10 ++
arch/powerpc/sysdev/cpm1.c | 246 +++-
2 files changed, 255 insertions(+), 1 deletions(-)
diff --git a/arch/powerpc/platforms/8xx/Kconfig
b/arch/powerpc/platforms/8xx/Kconfig
index 7fd224c..9d17425 100644
--- a/arch/powerpc/platforms/8xx/Kconfig
+++ b/arch/powerpc/platforms/8xx/Kconfig
@@ -109,6 +109,16 @@ config 8xx_COPYBACK
If in doubt, say Y here.
+config 8xx_GPIO
+ bool GPIO API Support
+ select GENERIC_GPIO
+ select HAVE_GPIO_LIB
+ help
+ Saying Y here will cause the ports on an MPC8xx processor to be used
+ with the GPIO API. If you say N here, the kernel needs less memory.
+
+ If in doubt, say Y here.
+
config 8xx_CPU6
bool CPU6 Silicon Errata (860 Pre Rev. C)
help
diff --git a/arch/powerpc/sysdev/cpm1.c b/arch/powerpc/sysdev/cpm1.c
index df8bd2b..6c97f3f 100644
--- a/arch/powerpc/sysdev/cpm1.c
+++ b/arch/powerpc/sysdev/cpm1.c
@@ -30,6 +30,7 @@
#include linux/interrupt.h
#include linux/irq.h
#include linux/module.h
+#include linux/spinlock.h
#include asm/page.h
#include asm/pgtable.h
#include asm/8xx_immap.h
@@ -42,6 +43,11 @@
#include asm/fs_pd.h
+#ifdef CONFIG_8xx_GPIO
+#include linux/of_gpio.h
+#include asm/gpio.h
+#endif
+
#define CPM_MAP_SIZE(0x4000)
#ifndef CONFIG_PPC_CPM_NEW_BINDING
@@ -403,7 +409,7 @@ struct cpm_ioport16 {
};
struct cpm_ioport32 {
- __be32 dir, par, sor;
+ __be32 dir, par, sor, dat;
};
static void cpm1_set_pin32(int port, int pin, int flags)
@@ -610,3 +616,241 @@ int cpm1_clk_setup(enum cpm_clk_target target, int clock,
int mode)
return 0;
}
+
+/*
+ * GPIO LIB API implementation
+ */
+#ifdef CONFIG_8xx_GPIO
+
+struct cpm1_gpio16_chip {
+ struct of_mm_gpio_chip mm_gc;
+ spinlock_t lock;
+
+ /* shadowed data register to clear/set bits safely */
+ u16 cpdata;
+};
+
+static inline struct cpm1_gpio16_chip *
+to_cpm1_gpio16_chip(struct of_mm_gpio_chip *mm_gc)
+{
+ return container_of(mm_gc, struct cpm1_gpio16_chip, mm_gc);
+}
+
+static void cpm1_gpio16_save_regs(struct of_mm_gpio_chip *mm_gc)
+{
+ struct cpm1_gpio16_chip *cpm1_gc = to_cpm1_gpio16_chip(mm_gc);
+ struct cpm_ioport16 __iomem *iop = mm_gc-regs;
+
+ cpm1_gc-cpdata = in_be16(iop-dat);
+}
+
+static int cpm1_gpio16_get(struct gpio_chip *gc, unsigned int gpio)
+{
+ struct of_mm_gpio_chip *mm_gc = to_of_mm_gpio_chip(gc);
+ struct cpm_ioport16 __iomem *iop = mm_gc-regs;
+ u16 pin_mask;
+
+ pin_mask = 1 (15 - gpio);
+
+ return !!(in_be16(iop-dat) pin_mask);
+}
+
+static void cpm1_gpio16_set(struct gpio_chip *gc, unsigned int gpio, int value)
+{
+ struct of_mm_gpio_chip *mm_gc = to_of_mm_gpio_chip(gc);
+ struct cpm1_gpio16_chip *cpm1_gc = to_cpm1_gpio16_chip(mm_gc);
+ struct cpm_ioport16 __iomem *iop = mm_gc-regs;
+ unsigned long flags;
+ u16 pin_mask = 1 (15 - gpio);
+
+ spin_lock_irqsave(cpm1_gc-lock, flags);
+
+ if (value)
+ cpm1_gc-cpdata |= pin_mask;
+ else
+ cpm1_gc-cpdata = ~pin_mask;
+
+ out_be16(iop-dat, cpm1_gc-cpdata);
+
+ spin_unlock_irqrestore(cpm1_gc-lock, flags);
+}
+
+static int cpm1_gpio16_dir_out(struct gpio_chip *gc, unsigned int gpio, int
val)
+{
+ struct of_mm_gpio_chip *mm_gc = to_of_mm_gpio_chip(gc);
+ struct cpm_ioport16 __iomem *iop = mm_gc-regs;
+ u16 pin_mask;
+
+ pin_mask = 1 (15 - gpio);
+
+ setbits16(iop-dir, pin_mask);
+
+ cpm1_gpio16_set(gc, gpio, val);
+
+ return 0;
+}
+
+static int cpm1_gpio16_dir_in(struct gpio_chip *gc, unsigned int gpio)
+{
+ struct of_mm_gpio_chip *mm_gc = to_of_mm_gpio_chip(gc);
+ struct cpm_ioport16 __iomem *iop = mm_gc-regs;
+ u16 pin_mask;
+
+ pin_mask = 1 (15 - gpio);
+
+ clrbits16(iop-dir, pin_mask);
+
+ return 0;
+}
+
+int cpm1_gpiochip_add16(struct device_node *np)
+{
+ struct cpm1_gpio16_chip *cpm1_gc;
+ struct of_mm_gpio_chip *mm_gc;
+ struct of_gpio_chip *of_gc;
+ struct gpio_chip *gc;
+
+ cpm1_gc = kzalloc(sizeof(*cpm1_gc), GFP_KERNEL);
+ if (!cpm1_gc)
+ return -ENOMEM;
+
+
Re: [PATCH] [POWERPC] CPM1: implement GPIO LIB API
Jochen Friedrich wrote: Hi Scott, diff --git a/arch/powerpc/platforms/8xx/Kconfig b/arch/powerpc/platforms/8xx/Kconfig index 7fd224c..e12cbf0 100644 --- a/arch/powerpc/platforms/8xx/Kconfig +++ b/arch/powerpc/platforms/8xx/Kconfig @@ -4,6 +4,8 @@ config FADS config CPM1 bool select CPM + select GENERIC_GPIO + select GPIO_LIB Shouldn't this depend on the user enabling GPIO support? Some 8xx boards are very memory-constrained, so we don't want to be making the kernel even bigger than it already is unless it's actually needed. Are you more comfortable with this? Sure. -Scott ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[RESEND][POWERPC] mpc5200: Amalgamated dts fixes and updates
The bulk of this patch is taken from
http://patchwork.ozlabs.org/linuxppc/patch?q=Balakowiczid=16197, with few
other updates.
Signed-off-by: Marian Balakowicz [EMAIL PROTECTED]
---
Addressed comments from the list; would appreciate picking up as the patch
fixes booting issue on TQM5200 and Motion-PRO (cm5200 changes are analogous,
but not tested due to hardware unavailability).
diff --git a/arch/powerpc/boot/dts/cm5200.dts b/arch/powerpc/boot/dts/cm5200.dts
index 30737ea..2d25ca8 100644
--- a/arch/powerpc/boot/dts/cm5200.dts
+++ b/arch/powerpc/boot/dts/cm5200.dts
@@ -212,13 +212,30 @@
[EMAIL PROTECTED] {
device_type = network;
compatible = fsl,mpc5200b-fec,fsl,mpc5200-fec;
- reg = 3000 800;
+ reg = 3000 400;
local-mac-address = [ 00 00 00 00 00 00 ];
interrupts = 2 5 0;
interrupt-parent = mpc5200_pic;
+ phy-handle = phy0;
+ };
+
+ [EMAIL PROTECTED] {
+ #address-cells = 1;
+ #size-cells = 0;
+ compatible = fsl,mpc5200b-mdio,fsl,mpc5200-mdio;
+ reg = 3000 400; // fec range, since we need to
setup fec interrupts
+ interrupts = 2 5 0; // these are for mii command
finished, not link changes co.
+ interrupt-parent = mpc5200_pic;
+
+ phy0:[EMAIL PROTECTED] {
+ device_type = ethernet-phy;
+ reg = 0;
+ };
};
[EMAIL PROTECTED] {
+ #address-cells = 1;
+ #size-cells = 0;
compatible =
fsl,mpc5200b-i2c,fsl,mpc5200-i2c,fsl-i2c;
reg = 3d40 40;
interrupts = 2 10 0;
@@ -231,4 +248,22 @@
reg = 8000 4000;
};
};
+
+ lpb {
+ model = fsl,lpb;
+ compatible = fsl,lpb;
+ #address-cells = 2;
+ #size-cells = 1;
+ ranges = 0 0 fc00 200;
+
+ // 16-bit flash device at LocalPlus Bus CS0
+ [EMAIL PROTECTED],0 {
+ compatible = cfi-flash;
+ reg = 0 0 200;
+ bank-width = 2;
+ device-width = 2;
+ #size-cells = 1;
+ #address-cells = 1;
+ };
+ };
};
diff --git a/arch/powerpc/boot/dts/motionpro.dts
b/arch/powerpc/boot/dts/motionpro.dts
index 76951ab..f27256b 100644
--- a/arch/powerpc/boot/dts/motionpro.dts
+++ b/arch/powerpc/boot/dts/motionpro.dts
@@ -148,7 +148,6 @@
interrupt-parent = mpc5200_pic;
};
-
[EMAIL PROTECTED] {
compatible = fsl,mpc5200b-spi,fsl,mpc5200-spi;
reg = f00 20;
@@ -209,10 +208,25 @@
[EMAIL PROTECTED] {
device_type = network;
compatible = fsl,mpc5200b-fec,fsl,mpc5200-fec;
- reg = 3000 800;
+ reg = 3000 400;
local-mac-address = [ 00 00 00 00 00 00 ];
interrupts = 2 5 0;
interrupt-parent = mpc5200_pic;
+ phy-handle = phy0;
+ };
+
+ [EMAIL PROTECTED] {
+ #address-cells = 1;
+ #size-cells = 0;
+ compatible = fsl,mpc5200b-mdio,fsl,mpc5200-mdio;
+ reg = 3000 400; // fec range, since we need to
setup fec interrupts
+ interrupts = 2 5 0; // these are for mii command
finished, not link changes co.
+ interrupt-parent = mpc5200_pic;
+
+ phy0:[EMAIL PROTECTED] {
+ device_type = ethernet-phy;
+ reg = 2;
+ };
};
[EMAIL PROTECTED] {
@@ -223,11 +237,19 @@
};
[EMAIL PROTECTED] {
+ #address-cells = 1;
+ #size-cells = 0;
compatible =
fsl,mpc5200b-i2c,fsl,mpc5200-i2c,fsl-i2c;
reg = 3d40 40;
interrupts = 2 10 0;
interrupt-parent = mpc5200_pic;
fsl5200-clocking;
+
+ [EMAIL PROTECTED] {
+ device_type = rtc;
+ compatible = dallas,ds1339;
+ reg = 68;
+ };
[PATCH 1/5] of/gpio: export of_simple_xlate function
So we'll able to use it for the non-memory mapped drivers (like
I2C GPIO expanders).
Signed-off-by: Anton Vorontsov [EMAIL PROTECTED]
---
Depends on the previous OF GPIO work.
drivers/of/gpio.c |6 +++---
include/linux/of_gpio.h | 13 +
2 files changed, 16 insertions(+), 3 deletions(-)
diff --git a/drivers/of/gpio.c b/drivers/of/gpio.c
index a6775ff..03e2fed 100644
--- a/drivers/of/gpio.c
+++ b/drivers/of/gpio.c
@@ -106,9 +106,8 @@ err0:
}
EXPORT_SYMBOL(of_get_gpio);
-static int of_gpio_simple_xlate(struct of_gpio_chip *of_gc,
- struct device_node *np,
- const void *gpio_spec)
+int of_gpio_simple_xlate(struct of_gpio_chip *of_gc, struct device_node *np,
+const void *gpio_spec)
{
const u32 *gpio = gpio_spec;
@@ -117,6 +116,7 @@ static int of_gpio_simple_xlate(struct of_gpio_chip *of_gc,
return *gpio;
}
+EXPORT_SYMBOL(of_gpio_simple_xlate);
int of_mm_gpiochip_add(struct device_node *np,
struct of_mm_gpio_chip *mm_gc)
diff --git a/include/linux/of_gpio.h b/include/linux/of_gpio.h
index ca313f0..75c209c 100644
--- a/include/linux/of_gpio.h
+++ b/include/linux/of_gpio.h
@@ -83,6 +83,19 @@ extern int of_get_gpio(struct device_node *np, int index);
extern int of_mm_gpiochip_add(struct device_node *np,
struct of_mm_gpio_chip *mm_gc);
+/**
+ * of_gpio_simple_xlate - translate gpio_spec to the GPIO number
+ * @of_gc: pointer to the of_gpio_chip structure
+ * @np:device node of the GPIO chip
+ * @gpio_spec: gpio specifier as found in the device tree
+ *
+ * This is simple translation function, suitable for the most 1:1 mapped
+ * gpio chips. This function performs only one sanity check: whether gpio
+ * is less than ngpios (that is specified in the gpio_chip).
+ */
+extern int of_gpio_simple_xlate(struct of_gpio_chip *of_gc,
+ struct device_node *np,
+ const void *gpio_spec);
#else
/* Drivers may not strictly depend on the GPIO support, so let them link. */
--
1.5.2.2
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH 2/5] leds: mark led_classdev.default_trigger as const
LED classdev core doesn't modify memory pointed by the default_trigger,
so mark it as const and we'll able to pass const char *s without getting
compiler warnings.
Signed-off-by: Anton Vorontsov [EMAIL PROTECTED]
---
include/linux/leds.h |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/include/linux/leds.h b/include/linux/leds.h
index 0201f6f..2122a77 100644
--- a/include/linux/leds.h
+++ b/include/linux/leds.h
@@ -45,7 +45,7 @@ struct led_classdev {
struct device *dev;
struct list_head node; /* LED Device list */
- char*default_trigger; /* Trigger to use */
+ const char *default_trigger; /* Trigger to use */
#ifdef CONFIG_LEDS_TRIGGERS
/* Protects the trigger data below */
--
1.5.2.2
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH 4/5] i2c: MPC837xRDB Power Management and GPIO expander driver
On the MPC837xRDB boards there is MC9S08QG8 (MCU) chip with the custom
firmware pre-programmed. This firmware offers to control some of the MCU
GPIO pins via I2C (two pins, connected to the LEDs, but also available
from the J28 and J43 headers, plus another (third) pin is a GPIO as well
but on this board it is reserved for Power-Off function). MCU have some
other functions, but these are not implemented yet.
Signed-off-by: Anton Vorontsov [EMAIL PROTECTED]
---
This patch depends on the not yet applied OF/PowerPC GPIO patches, so
please consider this for RFC only.
Thanks.
drivers/i2c/chips/Kconfig |9 ++
drivers/i2c/chips/Makefile |1 +
drivers/i2c/chips/mcu_mpc837xrdb.c | 185
3 files changed, 195 insertions(+), 0 deletions(-)
create mode 100644 drivers/i2c/chips/mcu_mpc837xrdb.c
diff --git a/drivers/i2c/chips/Kconfig b/drivers/i2c/chips/Kconfig
index 09d4937..db81018 100644
--- a/drivers/i2c/chips/Kconfig
+++ b/drivers/i2c/chips/Kconfig
@@ -150,4 +150,13 @@ config OZ99X
This driver can also be built as a module. If so, the module
will be called oz99x.
+config MCU_MPC837XRDB
+ tristate MPC837XRDB MCU driver
+ depends on I2C MPC837x_RDB OF_GPIO
+ help
+ Say Y here to enable soft power-off functionality on the Freescale
+ MPC837X-RDB boards, plus this driver will register MCU GPIOs as a
+ generic GPIO API chip, so you'll able to use MCU1 and MCU2 as GPIOs
+ and LEDs.
+
endmenu
diff --git a/drivers/i2c/chips/Makefile b/drivers/i2c/chips/Makefile
index c69f891..bbe7495 100644
--- a/drivers/i2c/chips/Makefile
+++ b/drivers/i2c/chips/Makefile
@@ -14,6 +14,7 @@ obj-$(CONFIG_TPS65010)+= tps65010.o
obj-$(CONFIG_MENELAUS) += menelaus.o
obj-$(CONFIG_SENSORS_TSL2550) += tsl2550.o
obj-$(CONFIG_OZ99X)+= oz99x.o
+obj-$(CONFIG_MCU_MPC837XRDB) += mcu_mpc837xrdb.o
ifeq ($(CONFIG_I2C_DEBUG_CHIP),y)
EXTRA_CFLAGS += -DDEBUG
diff --git a/drivers/i2c/chips/mcu_mpc837xrdb.c
b/drivers/i2c/chips/mcu_mpc837xrdb.c
new file mode 100644
index 000..a461c0e
--- /dev/null
+++ b/drivers/i2c/chips/mcu_mpc837xrdb.c
@@ -0,0 +1,190 @@
+/*
+ * MPC837xRDB Power Management and GPIO expander driver
+ *
+ * On the MPC837xRDB boards there is MC9S08QG8 (MCU) chip with the custom
+ * firmware pre-programmed. This firmware offers to control some of the MCU
+ * GPIO pins via I2C (two pins, connected to the LEDs, but also available
+ * from the J28 and J43 headers, plus another (third) pin is a GPIO as well
+ * but on this board it is reserved for Power-Off function). MCU have some
+ * other functions, but these are not implemented yet.
+ *
+ * Copyright (c) 2008 MontaVista Software, Inc.
+ *
+ * Author: Anton Vorontsov [EMAIL PROTECTED]
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ */
+
+#include linux/module.h
+#include linux/spinlock.h
+#include linux/i2c.h
+#include linux/of.h
+#include linux/of_gpio.h
+#include asm/machdep.h
+
+/*
+ * I don't have specifications for the MCU firmware that is used on the
+ * MPC837XRDB board, I found this register and bits positions by the
+ * trialerror method.
+ */
+#define MCU_REG_CTRL 0x20
+#define MCU_CTRL_POFF 0x40
+#define MCU_NUM_GPIO 2
+
+struct mcu {
+ spinlock_t lock;
+ struct device_node *np;
+ struct i2c_client *client;
+ struct of_gpio_chip of_gc;
+ u8 reg_ctrl;
+};
+
+static struct mcu *glob_mcu;
+
+static void mcu_power_off(void)
+{
+ struct mcu *mcu = glob_mcu;
+
+ pr_info(Sending power-off request to the MCU...\n);
+ spin_lock(mcu-lock);
+ i2c_smbus_write_byte_data(glob_mcu-client, MCU_REG_CTRL,
+ mcu-reg_ctrl | MCU_CTRL_POFF);
+ spin_unlock(mcu-lock);
+}
+
+static void mcu_gpio_set(struct gpio_chip *gc, unsigned int gpio, int val)
+{
+ struct of_gpio_chip *of_gc = to_of_gpio_chip(gc);
+ struct mcu *mcu = container_of(of_gc, struct mcu, of_gc);
+ u8 bit = 1 (4 + gpio);
+
+ spin_lock(mcu-lock);
+ if (val)
+ mcu-reg_ctrl |= bit;
+ else
+ mcu-reg_ctrl = ~bit;
+
+ i2c_smbus_write_byte_data(mcu-client, MCU_REG_CTRL, mcu-reg_ctrl);
+ spin_unlock(mcu-lock);
+}
+
+static int mcu_gpio_dir_out(struct gpio_chip *gc, unsigned int gpio, int val)
+{
+ mcu_gpio_set(gc, gpio, val);
+ return 0;
+}
+
+static int mcu_gpiochip_add(struct mcu *mcu)
+{
+ struct device_node *np;
+ struct of_gpio_chip *of_gc = mcu-of_gc;
+ struct gpio_chip *gc = of_gc-gc;
+
+ np = of_find_compatible_node(NULL, NULL, fsl,mcu-mpc837xrdb);
+ if (!np)
+ return -ENODEV;
+
+ gc-label = np-full_name;
+
[PATCH 5/5] [POWERPC] mpc837xrdb: add support for MCU
MCU is and external Freescale MC9S08QG8 microcontroller, mainly used to
provide soft power-off function, but also exports two GPIOs (wired to
the mcu1 and mcu2 LEDs and external (J28 and J43) headers.
Signed-off-by: Anton Vorontsov [EMAIL PROTECTED]
---
arch/powerpc/boot/dts/mpc8377_rdb.dts | 26 +-
arch/powerpc/boot/dts/mpc8378_rdb.dts | 26 +-
arch/powerpc/boot/dts/mpc8379_rdb.dts | 26 +-
arch/powerpc/platforms/83xx/Kconfig |2 ++
arch/powerpc/platforms/83xx/mpc837x_rdb.c |1 +
arch/powerpc/sysdev/fsl_soc.c |1 +
6 files changed, 79 insertions(+), 3 deletions(-)
diff --git a/arch/powerpc/boot/dts/mpc8377_rdb.dts
b/arch/powerpc/boot/dts/mpc8377_rdb.dts
index 440aa4d..0897bba 100644
--- a/arch/powerpc/boot/dts/mpc8377_rdb.dts
+++ b/arch/powerpc/boot/dts/mpc8377_rdb.dts
@@ -111,7 +111,7 @@
#address-cells = 1;
#size-cells = 0;
cell-index = 0;
- compatible = fsl-i2c;
+ compatible = fsl-i2c, simple-bus;
reg = 0x3000 0x100;
interrupts = 14 0x8;
interrupt-parent = ipic;
@@ -121,6 +121,30 @@
compatible = dallas,ds1339;
reg = 0x68;
};
+ mcu_pio: [EMAIL PROTECTED] {
+ #gpio-cells = 1;
+ compatible = fsl,mc9s08qg8-mpc837xrdb,
+fsl,mcu-mpc837xrdb,
+simple-bus;
+ reg = 0x0a;
+ gpio-controller;
+
+ [EMAIL PROTECTED] {
+ compatible = fsl,mcu-mpc837xrdb-led2,
+gpio-led;
+ linux,name = mcu2;
+ linux,active-low;
+ gpios = mcu_pio 0;
+ };
+
+ [EMAIL PROTECTED] {
+ compatible = fsl,mcu-mpc837xrdb-led1,
+gpio-led;
+ linux,name = mcu1;
+ linux,active-low;
+ gpios = mcu_pio 1;
+ };
+ };
};
[EMAIL PROTECTED] {
diff --git a/arch/powerpc/boot/dts/mpc8378_rdb.dts
b/arch/powerpc/boot/dts/mpc8378_rdb.dts
index 9271153..e21cbb1 100644
--- a/arch/powerpc/boot/dts/mpc8378_rdb.dts
+++ b/arch/powerpc/boot/dts/mpc8378_rdb.dts
@@ -111,7 +111,7 @@
#address-cells = 1;
#size-cells = 0;
cell-index = 0;
- compatible = fsl-i2c;
+ compatible = fsl-i2c, simple-bus;
reg = 0x3000 0x100;
interrupts = 14 0x8;
interrupt-parent = ipic;
@@ -121,6 +121,30 @@
compatible = dallas,ds1339;
reg = 0x68;
};
+ mcu_pio: [EMAIL PROTECTED] {
+ #gpio-cells = 1;
+ compatible = fsl,mc9s08qg8-mpc837xrdb,
+fsl,mcu-mpc837xrdb,
+simple-bus;
+ reg = 0x0a;
+ gpio-controller;
+
+ [EMAIL PROTECTED] {
+ compatible = fsl,mcu-mpc837xrdb-led2,
+gpio-led;
+ linux,name = mcu2;
+ linux,active-low;
+ gpios = mcu_pio 0;
+ };
+
+ [EMAIL PROTECTED] {
+ compatible = fsl,mcu-mpc837xrdb-led1,
+gpio-led;
+ linux,name = mcu1;
+ linux,active-low;
+ gpios = mcu_pio 1;
+ };
+ };
};
[EMAIL PROTECTED] {
diff --git a/arch/powerpc/boot/dts/mpc8379_rdb.dts
b/arch/powerpc/boot/dts/mpc8379_rdb.dts
index 0dda2fc..45c164b 100644
--- a/arch/powerpc/boot/dts/mpc8379_rdb.dts
+++ b/arch/powerpc/boot/dts/mpc8379_rdb.dts
@@ -111,7 +111,7 @@
Re: [RESEND][POWERPC] mpc5200: Amalgamated dts fixes and updates
Grant Likely wrote:
On Wed, Mar 26, 2008 at 1:45 PM, Bartlomiej Sieka [EMAIL PROTECTED] wrote:
The bulk of this patch is taken from
http://patchwork.ozlabs.org/linuxppc/patch?q=Balakowiczid=16197, with
few
other updates.
Signed-off-by: Marian Balakowicz [EMAIL PROTECTED]
---
Addressed comments from the list; would appreciate picking up as the patch
fixes booting issue on TQM5200 and Motion-PRO (cm5200 changes are analogous,
but not tested due to hardware unavailability).
I see one obvious error; but other than that it looks good. Once that
is fixed I can recommend for Paul to pick it up for .25. It's just
dts changes, so I don't expect it to be a problem.
Cheers,
g.
diff --git a/arch/powerpc/boot/dts/motionpro.dts
b/arch/powerpc/boot/dts/motionpro.dts
index 76951ab..f27256b 100644
--- a/arch/powerpc/boot/dts/motionpro.dts
+++ b/arch/powerpc/boot/dts/motionpro.dts
@@ -209,10 +208,25 @@
+ [EMAIL PROTECTED] {
+ #address-cells = 1;
+ #size-cells = 0;
+ compatible = fsl,mpc5200b-mdio,fsl,mpc5200-mdio;
+ reg = 3000 400; // fec range, since we need
to setup fec interrupts
+ interrupts = 2 5 0; // these are for mii
command finished, not link changes co.
+ interrupt-parent = mpc5200_pic;
+
+ phy0:[EMAIL PROTECTED] {
+ device_type = ethernet-phy;
+ reg = 2;
This doesn't look right. Reg should match the value in [EMAIL PROTECTED]
And whats about the two CAN nodes for tqm5200.dts? Do we have them already?
Thanks,
Wolfgang.
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: PPC upstream kernel ignored DABR bug
On Wed, 12 Mar 2008 18:47:45 -0700 (PDT) Roland McGrath [EMAIL PROTECTED] wrote: The only machine I have at home for testing powerpc is an Apple G5, supplied to me by IBM. It says: cpu : PPC970FX, altivec supported revision: 3.0 (pvr 003c 0300) so I am guessing this document applies to the chips I have. Since I can't test on other chips myself, it is plausible from what I've seen that there is no mysterious kernel problem and only this hardware problem. The description of the hardware problem would not make me think that it would behave this way, but it is not very detailed or precise, or at least does not seem so to a reader not expert on powerpc. I ran the testcase on my older G5 today with: cpu : PPC970, altivec supported revision: 2.2 (pvr 0039 0202) and it also failed after a few iterations. This was with 2.6.25-0.121.rc5.git4.fc9 as the kernel, which is fairly close to mainline. At the least, this doesn't seem to be 970FX related. I'll try building a vanilla 2.6.25-rc7 later this evening to see if that makes a difference. josh ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [RESEND][POWERPC] mpc5200: Amalgamated dts fixes and updates
Bartlomiej Sieka wrote:
+
+ phy0:[EMAIL PROTECTED] {
+ device_type = ethernet-phy;
+ reg = 0;
+ };
What's the parsing of this pan out to? What does it mean?
Having colons in device names is totally contrary to OF device naming
spec. Does the part after the colon have a special meaning to the DTC?
I also was under the impression that device_type was invalid in a DTS
file, have we changed our minds again?
--
Matt Sealey [EMAIL PROTECTED]
Genesi, Manager, Developer Relations
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 3/5] leds: implement OpenFirmare GPIO LEDs driver
Can someone throw me a link to the GPIO spec being implemented here (yes, I would like docs too!) or a pointer to the relevant DTS which implements it? Supporting GPIO in the device tree is something that has been undefined for ages, and I seem to not be able to find the supporting DTS patches for this implementation in patchwork..?? -- Matt Sealey [EMAIL PROTECTED] Genesi, Manager, Developer Relations Grant Likely wrote: On Wed, Mar 26, 2008 at 2:24 PM, Anton Vorontsov [EMAIL PROTECTED] wrote: Despite leds-gpio and leds-of-gpio similar names and purposes, there is actually very few code can be shared between the two (both drivers are mostly the driver bindings anyway). Signed-off-by: Anton Vorontsov [EMAIL PROTECTED] Other than the fact that it needs some documentation of the binding in booting-without-of.txt, it looks pretty good to me. g. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 4/5] i2c: MPC837xRDB Power Management and GPIO expander driver
Anton Vorontsov wrote: +config MCU_MPC837XRDB + tristate MPC837XRDB MCU driver + depends on I2C MPC837x_RDB OF_GPIO The MPC8349E-mITX also has this chip. Can you include support for that board as well? -- Timur Tabi Linux kernel developer at Freescale ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[RESEND2][POWERPC] mpc5200: Amalgamated dts fixes and updates
The bulk of this patch is taken from
http://patchwork.ozlabs.org/linuxppc/patch?q=Balakowiczid=16197, with few
other updates.
Signed-off-by: Marian Balakowicz [EMAIL PROTECTED]
diff --git a/arch/powerpc/boot/dts/cm5200.dts b/arch/powerpc/boot/dts/cm5200.dts
index 30737ea..2d25ca8 100644
--- a/arch/powerpc/boot/dts/cm5200.dts
+++ b/arch/powerpc/boot/dts/cm5200.dts
@@ -212,13 +212,30 @@
[EMAIL PROTECTED] {
device_type = network;
compatible = fsl,mpc5200b-fec,fsl,mpc5200-fec;
- reg = 3000 800;
+ reg = 3000 400;
local-mac-address = [ 00 00 00 00 00 00 ];
interrupts = 2 5 0;
interrupt-parent = mpc5200_pic;
+ phy-handle = phy0;
+ };
+
+ [EMAIL PROTECTED] {
+ #address-cells = 1;
+ #size-cells = 0;
+ compatible = fsl,mpc5200b-mdio,fsl,mpc5200-mdio;
+ reg = 3000 400; // fec range, since we need to
setup fec interrupts
+ interrupts = 2 5 0; // these are for mii command
finished, not link changes co.
+ interrupt-parent = mpc5200_pic;
+
+ phy0:[EMAIL PROTECTED] {
+ device_type = ethernet-phy;
+ reg = 0;
+ };
};
[EMAIL PROTECTED] {
+ #address-cells = 1;
+ #size-cells = 0;
compatible =
fsl,mpc5200b-i2c,fsl,mpc5200-i2c,fsl-i2c;
reg = 3d40 40;
interrupts = 2 10 0;
@@ -231,4 +248,22 @@
reg = 8000 4000;
};
};
+
+ lpb {
+ model = fsl,lpb;
+ compatible = fsl,lpb;
+ #address-cells = 2;
+ #size-cells = 1;
+ ranges = 0 0 fc00 200;
+
+ // 16-bit flash device at LocalPlus Bus CS0
+ [EMAIL PROTECTED],0 {
+ compatible = cfi-flash;
+ reg = 0 0 200;
+ bank-width = 2;
+ device-width = 2;
+ #size-cells = 1;
+ #address-cells = 1;
+ };
+ };
};
diff --git a/arch/powerpc/boot/dts/motionpro.dts
b/arch/powerpc/boot/dts/motionpro.dts
index 76951ab..d86eba0 100644
--- a/arch/powerpc/boot/dts/motionpro.dts
+++ b/arch/powerpc/boot/dts/motionpro.dts
@@ -148,7 +148,6 @@
interrupt-parent = mpc5200_pic;
};
-
[EMAIL PROTECTED] {
compatible = fsl,mpc5200b-spi,fsl,mpc5200-spi;
reg = f00 20;
@@ -209,10 +208,25 @@
[EMAIL PROTECTED] {
device_type = network;
compatible = fsl,mpc5200b-fec,fsl,mpc5200-fec;
- reg = 3000 800;
+ reg = 3000 400;
local-mac-address = [ 00 00 00 00 00 00 ];
interrupts = 2 5 0;
interrupt-parent = mpc5200_pic;
+ phy-handle = phy0;
+ };
+
+ [EMAIL PROTECTED] {
+ #address-cells = 1;
+ #size-cells = 0;
+ compatible = fsl,mpc5200b-mdio,fsl,mpc5200-mdio;
+ reg = 3000 400; // fec range, since we need to
setup fec interrupts
+ interrupts = 2 5 0; // these are for mii command
finished, not link changes co.
+ interrupt-parent = mpc5200_pic;
+
+ phy0:[EMAIL PROTECTED] {
+ device_type = ethernet-phy;
+ reg = 2;
+ };
};
[EMAIL PROTECTED] {
@@ -223,11 +237,19 @@
};
[EMAIL PROTECTED] {
+ #address-cells = 1;
+ #size-cells = 0;
compatible =
fsl,mpc5200b-i2c,fsl,mpc5200-i2c,fsl-i2c;
reg = 3d40 40;
interrupts = 2 10 0;
interrupt-parent = mpc5200_pic;
fsl5200-clocking;
+
+ [EMAIL PROTECTED] {
+ device_type = rtc;
+ compatible = dallas,ds1339;
+ reg = 68;
+ };
};
[EMAIL PROTECTED] {
@@ -240,7 +262,8 @@
compatible = fsl,lpb;
#address-cells = 2;
#size-cells = 1;
- ranges = 1 0
Re: [RESEND][POWERPC] mpc5200: Amalgamated dts fixes and updates
On Wed, Mar 26, 2008 at 3:02 PM, Matt Sealey [EMAIL PROTECTED] wrote:
Bartlomiej Sieka wrote:
+
+ phy0:[EMAIL PROTECTED] {
+ device_type = ethernet-phy;@0
+ reg = 0;
+ };
What's the parsing of this pan out to? What does it mean?
Having colons in device names is totally contrary to OF device naming
spec. Does the part after the colon have a special meaning to the DTC?
phy0: is a label used by dtc.
[EMAIL PROTECTED] is the node name.
I also was under the impression that device_type was invalid in a DTS
file, have we changed our minds again?
No, we haven't. It kind of sneaked back in for ethernet phys. I
don't know why.
Cheers,
g.
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH 0/4] 16G huge page support for powerpc
This patch set builds on Andi Kleen's patches for GB pages for hugetlb posted on March 16th. This set adds support for 16G huge pages on ppc64. Supporting multiple huge page sizes on ppc64 as defined in Andi's patches is not a part of this set; that will be included in a future patch. The first patch here adds an arch callback since the 16G pages are not allocated from bootmem. The 16G pages have to be reserved prior to boot-time. The location of these pages are indicated in the device tree. Support for 16G pages requires a POWER5+ or later machine and a little bit of memory. Jon ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH 1/4] allow arch specific function for allocating gigantic pages
Allow alloc_bm_huge_page() to be overridden by architectures that can't always
use bootmem.
This requires huge_boot_pages to be available for use by this function. Also
huge_page_size()
and other functions need to use a long so that they can handle the 16G page
size.
Signed-off-by: Jon Tollefson [EMAIL PROTECTED]
---
include/linux/hugetlb.h | 10 +-
mm/hugetlb.c| 21 +
2 files changed, 18 insertions(+), 13 deletions(-)
diff --git a/include/linux/hugetlb.h b/include/linux/hugetlb.h
index a8de3c1..35a41be 100644
--- a/include/linux/hugetlb.h
+++ b/include/linux/hugetlb.h
@@ -35,6 +35,7 @@ void hugetlb_unreserve_pages(struct inode *inode, long
offset, long freed);
extern unsigned long hugepages_treat_as_movable;
extern const unsigned long hugetlb_zero, hugetlb_infinity;
extern int sysctl_hugetlb_shm_group;
+extern struct list_head huge_boot_pages;
/* arch callbacks */
@@ -219,9 +220,15 @@ struct hstate {
unsigned int surplus_huge_pages_node[MAX_NUMNODES];
unsigned long parsed_hugepages;
};
+struct huge_bm_page {
+ struct list_head list;
+ struct hstate *hstate;
+};
void __init huge_add_hstate(unsigned order);
struct hstate *huge_lookup_hstate(unsigned long pagesize);
+/* arch callback */
+int alloc_bm_huge_page(struct hstate *h);
#ifndef HUGE_MAX_HSTATE
#define HUGE_MAX_HSTATE 1
@@ -248,7 +255,7 @@ static inline struct hstate *hstate_inode(struct inode *i)
return HUGETLBFS_I(i)-hstate;
}
-static inline unsigned huge_page_size(struct hstate *h)
+static inline unsigned long huge_page_size(struct hstate *h)
{
return PAGE_SIZE h-order;
}
@@ -273,6 +280,7 @@ extern unsigned long
sysctl_overcommit_huge_pages[HUGE_MAX_HSTATE];
#else
struct hstate {};
+#define alloc_bm_huge_page(h) NULL
#define hstate_file(f) NULL
#define hstate_vma(v) NULL
#define hstate_inode(i) NULL
diff --git a/mm/hugetlb.c b/mm/hugetlb.c
index c28b8b6..a0017b0 100644
--- a/mm/hugetlb.c
+++ b/mm/hugetlb.c
@@ -27,6 +27,7 @@ unsigned long max_huge_pages[HUGE_MAX_HSTATE];
unsigned long sysctl_overcommit_huge_pages[HUGE_MAX_HSTATE];
static gfp_t htlb_alloc_mask = GFP_HIGHUSER;
unsigned long hugepages_treat_as_movable;
+struct list_head huge_boot_pages;
static int max_hstate = 1;
@@ -43,7 +44,8 @@ struct hstate *parsed_hstate __initdata = global_hstate;
*/
static DEFINE_SPINLOCK(hugetlb_lock);
-static void clear_huge_page(struct page *page, unsigned long addr, unsigned sz)
+static void clear_huge_page(struct page *page, unsigned long addr,
+ unsigned long sz)
{
int i;
@@ -521,14 +523,8 @@ static __init char *memfmt(char *buf, unsigned long n)
return buf;
}
-static __initdata LIST_HEAD(huge_boot_pages);
-
-struct huge_bm_page {
- struct list_head list;
- struct hstate *hstate;
-};
-
-static int __init alloc_bm_huge_page(struct hstate *h)
+/* Can be overriden by architectures */
+__attribute__((weak)) int alloc_bm_huge_page(struct hstate *h)
{
struct huge_bm_page *m;
m = __alloc_bootmem_node_nopanic(NODE_DATA(h-hugetlb_next_nid),
@@ -614,6 +610,7 @@ static int __init hugetlb_init(void)
{
if (HPAGE_SHIFT == 0)
return 0;
+ INIT_LIST_HEAD(huge_boot_pages);
return hugetlb_init_hstate(global_hstate);
}
module_init(hugetlb_init);
@@ -866,7 +863,7 @@ int hugetlb_report_meminfo(char *buf)
n += dump_field(buf + n, offsetof(struct hstate, surplus_huge_pages));
n += sprintf(buf + n, Hugepagesize: );
for_each_hstate (h)
- n += sprintf(buf + n, %5u, huge_page_size(h) / 1024);
+ n += sprintf(buf + n, %5lu, huge_page_size(h) / 1024);
n += sprintf(buf + n, kB\n);
return n;
}
@@ -947,7 +944,7 @@ int copy_hugetlb_page_range(struct mm_struct *dst, struct
mm_struct *src,
unsigned long addr;
int cow;
struct hstate *h = hstate_vma(vma);
- unsigned sz = huge_page_size(h);
+ unsigned long sz = huge_page_size(h);
cow = (vma-vm_flags (VM_SHARED | VM_MAYWRITE)) == VM_MAYWRITE;
@@ -992,7 +989,7 @@ void __unmap_hugepage_range(struct vm_area_struct *vma,
unsigned long start,
struct page *page;
struct page *tmp;
struct hstate *h = hstate_vma(vma);
- unsigned sz = huge_page_size(h);
+ unsigned long sz = huge_page_size(h);
/*
* A page gathering list, protected by per file i_mmap_lock. The
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH 2/4] powerpc: function for allocating gigantic pages
The 16G page locations have been saved during early boot in an array. The
alloc_bm_huge_page() function adds a page from here to the huge_boot_pages list.
Signed-off-by: Jon Tollefson [EMAIL PROTECTED]
---
hugetlbpage.c | 19 +++
1 file changed, 19 insertions(+)
diff --git a/arch/powerpc/mm/hugetlbpage.c b/arch/powerpc/mm/hugetlbpage.c
index 94625db..31d977b 100644
--- a/arch/powerpc/mm/hugetlbpage.c
+++ b/arch/powerpc/mm/hugetlbpage.c
@@ -29,6 +29,10 @@
#define NUM_LOW_AREAS (0x1UL SID_SHIFT)
#define NUM_HIGH_AREAS (PGTABLE_RANGE HTLB_AREA_SHIFT)
+#define MAX_NUMBER_GPAGES 1024
+
+static void *gpage_freearray[MAX_NUMBER_GPAGES];
+static unsigned nr_gpages;
unsigned int hugepte_shift;
#define PTRS_PER_HUGEPTE (1 hugepte_shift)
@@ -104,6 +108,21 @@ pmd_t *hpmd_alloc(struct mm_struct *mm, pud_t *pud,
unsigned long addr)
}
#endif
+/* Put 16G page address into temporary huge page list because the mem_map
+ * is not up yet.
+ */
+int alloc_bm_huge_page(struct hstate *h)
+{
+ struct huge_bm_page *m;
+ if (nr_gpages == 0)
+ return 0;
+ m = gpage_freearray[--nr_gpages];
+ list_add(m-list, huge_boot_pages);
+ m-hstate = h;
+ return 1;
+}
+
+
/* Modelled after find_linux_pte() */
pte_t *huge_pte_offset(struct mm_struct *mm, unsigned long addr)
{
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH 3/4] powerpc: scan device tree and save gigantic page locations
The 16G huge pages have to be reserved in the HMC prior to boot. The location
of
the pages are placed in the device tree. During very early boot these
locations are
saved for use by hugetlbfs.
Signed-off-by: Jon Tollefson [EMAIL PROTECTED]
---
arch/powerpc/mm/hash_utils_64.c | 41 ++-
arch/powerpc/mm/hugetlbpage.c| 17
include/asm-powerpc/mmu-hash64.h |2 +
3 files changed, 59 insertions(+), 1 deletion(-)
diff --git a/arch/powerpc/mm/hash_utils_64.c b/arch/powerpc/mm/hash_utils_64.c
index a83dfa3..d3f7d92 100644
--- a/arch/powerpc/mm/hash_utils_64.c
+++ b/arch/powerpc/mm/hash_utils_64.c
@@ -67,6 +67,7 @@
#define KB (1024)
#define MB (1024*KB)
+#define GB (1024L*MB)
/*
* Note: pte -- Linux PTE
@@ -302,6 +303,41 @@ static int __init htab_dt_scan_page_sizes(unsigned long
node,
return 0;
}
+/* Scan for 16G memory blocks that have been set aside for huge pages
+ * and reserve those blocks for 16G huge pages.
+ */
+static int __init htab_dt_scan_hugepage_blocks(unsigned long node,
+ const char *uname, int depth,
+ void *data) {
+ char *type = of_get_flat_dt_prop(node, device_type, NULL);
+ unsigned long *lprop;
+ u32 *prop;
+
+ /* We are scanning memory nodes only */
+ if (type == NULL || strcmp(type, memory) != 0)
+ return 0;
+
+ /* This property is the log base 2 of the number of virtual pages that
+* will represent this memory block. */
+ prop = of_get_flat_dt_prop(node, ibm,expected#pages, NULL);
+ if (prop == NULL)
+ return 0;
+ unsigned int expected_pages = (1 prop[0]);
+ lprop = of_get_flat_dt_prop(node, reg, NULL);
+ if (lprop == NULL)
+ return 0;
+ long unsigned int phys_addr = lprop[0];
+ long unsigned int block_size = lprop[1];
+ if (block_size != (16 * GB))
+ return 0;
+ printk(KERN_INFO Reserving huge page memory
+ addr = 0x%lX size = 0x%lX pages = %d\n,
+ phys_addr, block_size, expected_pages);
+ lmb_reserve(phys_addr, block_size * expected_pages);
+ add_gpage(phys_addr, block_size, expected_pages);
+ return 0;
+}
+
static void __init htab_init_page_sizes(void)
{
int rc;
@@ -370,7 +406,10 @@ static void __init htab_init_page_sizes(void)
mmu_psize_defs[mmu_io_psize].shift);
#ifdef CONFIG_HUGETLB_PAGE
- /* Init large page size. Currently, we pick 16M or 1M depending
+ /* Reserve 16G huge page memory sections for huge pages */
+ of_scan_flat_dt(htab_dt_scan_hugepage_blocks, NULL);
+
+/* Init large page size. Currently, we pick 16M or 1M depending
* on what is available
*/
if (mmu_psize_defs[MMU_PAGE_16M].shift)
diff --git a/arch/powerpc/mm/hugetlbpage.c b/arch/powerpc/mm/hugetlbpage.c
index 31d977b..44d3d55 100644
--- a/arch/powerpc/mm/hugetlbpage.c
+++ b/arch/powerpc/mm/hugetlbpage.c
@@ -108,6 +108,23 @@ pmd_t *hpmd_alloc(struct mm_struct *mm, pud_t *pud,
unsigned long addr)
}
#endif
+/* Build list of addresses of gigantic pages. This function is used in early
+ * boot before the buddy allocator is setup.
+ */
+void add_gpage(unsigned long addr, unsigned long page_size,
+ unsigned long number_of_pages)
+{
+ if (addr) {
+ while (number_of_pages 0) {
+ gpage_freearray[nr_gpages] = __va(addr);
+ nr_gpages++;
+ number_of_pages--;
+ addr += page_size;
+ }
+ }
+}
+
+
/* Put 16G page address into temporary huge page list because the mem_map
* is not up yet.
*/
diff --git a/include/asm-powerpc/mmu-hash64.h b/include/asm-powerpc/mmu-hash64.h
index 2864fa3..db1276a 100644
--- a/include/asm-powerpc/mmu-hash64.h
+++ b/include/asm-powerpc/mmu-hash64.h
@@ -279,6 +279,8 @@ extern int htab_bolt_mapping(unsigned long vstart, unsigned
long vend,
unsigned long pstart, unsigned long mode,
int psize, int ssize);
extern void set_huge_psize(int psize);
+extern void add_gpage(unsigned long addr, unsigned long page_size,
+ unsigned long number_of_pages);
extern void demote_segment_4k(struct mm_struct *mm, unsigned long addr);
extern void htab_initialize(void);
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH 4/4] powerpc: define page support for 16G pages
The huge page size is setup for 16G pages if that size is specified at
boot-time. The support for
multiple huge page sizes is not being utilized yet. That will be in a future
patch.
Signed-off-by: Jon Tollefson [EMAIL PROTECTED]
---
hugetlbpage.c | 12 ++--
1 file changed, 10 insertions(+), 2 deletions(-)
diff --git a/arch/powerpc/mm/hugetlbpage.c b/arch/powerpc/mm/hugetlbpage.c
index 44d3d55..b6a02b7 100644
--- a/arch/powerpc/mm/hugetlbpage.c
+++ b/arch/powerpc/mm/hugetlbpage.c
@@ -26,6 +26,7 @@
#define HPAGE_SHIFT_64K16
#define HPAGE_SHIFT_16M24
+#define HPAGE_SHIFT_16G34
#define NUM_LOW_AREAS (0x1UL SID_SHIFT)
#define NUM_HIGH_AREAS (PGTABLE_RANGE HTLB_AREA_SHIFT)
@@ -589,9 +590,11 @@ void set_huge_psize(int psize)
{
/* Check that it is a page size supported by the hardware and
* that it fits within pagetable limits. */
- if (mmu_psize_defs[psize].shift mmu_psize_defs[psize].shift
SID_SHIFT
+ if (mmu_psize_defs[psize].shift
+ mmu_psize_defs[psize].shift SID_SHIFT_1T
(mmu_psize_defs[psize].shift MIN_HUGEPTE_SHIFT ||
- mmu_psize_defs[psize].shift == HPAGE_SHIFT_64K)) {
+mmu_psize_defs[psize].shift == HPAGE_SHIFT_64K ||
+mmu_psize_defs[psize].shift == HPAGE_SHIFT_16G)) {
HPAGE_SHIFT = mmu_psize_defs[psize].shift;
mmu_huge_psize = psize;
#ifdef CONFIG_PPC_64K_PAGES
@@ -599,6 +602,8 @@ void set_huge_psize(int psize)
#else
if (HPAGE_SHIFT == HPAGE_SHIFT_64K)
hugepte_shift = (PMD_SHIFT-HPAGE_SHIFT);
+ else if (HPAGE_SHIFT == HPAGE_SHIFT_16G)
+ hugepte_shift = (PGDIR_SHIFT-HPAGE_SHIFT);
else
hugepte_shift = (PUD_SHIFT-HPAGE_SHIFT);
#endif
@@ -625,6 +630,9 @@ static int __init hugepage_setup_sz(char *str)
case HPAGE_SHIFT_16M:
mmu_psize = MMU_PAGE_16M;
break;
+ case HPAGE_SHIFT_16G:
+ mmu_psize = MMU_PAGE_16G;
+ break;
}
if (mmu_psize =0 mmu_psize_defs[mmu_psize].shift)
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [RESEND][POWERPC] mpc5200: Amalgamated dts fixes and updates
Wolfgang Grandegger wrote: Grant Likely wrote: On Wed, Mar 26, 2008 at 1:45 PM, Bartlomiej Sieka [EMAIL PROTECTED] wrote: The bulk of this patch is taken from http://patchwork.ozlabs.org/linuxppc/patch?q=Balakowiczid=16197, with few other updates. Signed-off-by: Marian Balakowicz [EMAIL PROTECTED] --- Addressed comments from the list; would appreciate picking up as the patch fixes booting issue on TQM5200 and Motion-PRO (cm5200 changes are analogous, but not tested due to hardware unavailability). I see one obvious error; but other than that it looks good. Once that is fixed I can recommend for Paul to pick it up for .25. It's just dts changes, so I don't expect it to be a problem. Cheers, [...] And whats about the two CAN nodes for tqm5200.dts? Do we have them already? Hello Wolfgang, patchwork shows your updates as Awaiting Upstream (http://patchwork.ozlabs.org/linuxppc/patch?q=Grandeggerid=17444), so I haven't included them in my patch. I suppose you should follow-up with Grant/Paulus on the status? Regards, Bartlomiej ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 0/4] 16G huge page support for powerpc
FWIW i turned over the hugepages patchkit to Nick Piggin. So send all future patches to him please. -Andi ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 1/4] allow arch specific function for allocating gigantic pages
Haven't reviewed it in detail, just noticed something.
@@ -614,6 +610,7 @@ static int __init hugetlb_init(void)
{
if (HPAGE_SHIFT == 0)
return 0;
+ INIT_LIST_HEAD(huge_boot_pages);
return hugetlb_init_hstate(global_hstate);
I don't think adding the INIT_LIST_HEAD here is correct. There can
be huge pages added by the __setup handlers before hugetlb_init
-Andi
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] scanlog_init cleanup, minor fixes
On Sun, 2008-03-23 at 17:51 -0500, Nathan Lynch wrote:
scanlog_init() could use some love.
diff --git a/arch/powerpc/platforms/pseries/scanlog.c
b/arch/powerpc/platforms/pseries/scanlog.c
index 8e1ef16..e5b0ea8 100644
--- a/arch/powerpc/platforms/pseries/scanlog.c
+++ b/arch/powerpc/platforms/pseries/scanlog.c
@@ -195,31 +195,30 @@ const struct file_operations scanlog_fops = {
static int __init scanlog_init(void)
{
struct proc_dir_entry *ent;
+ void *data;
+ int err = -ENOMEM;
ibm_scan_log_dump = rtas_token(ibm,scan-log-dump);
- if (ibm_scan_log_dump == RTAS_UNKNOWN_SERVICE) {
- printk(KERN_ERR scan-log-dump not implemented on this
system\n);
- return -EIO;
- }
+ if (ibm_scan_log_dump == RTAS_UNKNOWN_SERVICE)
+ return -ENODEV;
-ent = create_proc_entry(ppc64/rtas/scan-log-dump, S_IRUSR, NULL);
- if (ent) {
- ent-proc_fops = scanlog_fops;
- /* Ideally we could allocate a buffer 4G */
- ent-data = kmalloc(RTAS_DATA_BUF_SIZE, GFP_KERNEL);
- if (!ent-data) {
- printk(KERN_ERR Failed to allocate a buffer\n);
- remove_proc_entry(scan-log-dump, ent-parent);
- return -ENOMEM;
- }
- ((unsigned int *)ent-data)[0] = 0;
- } else {
- printk(KERN_ERR Failed to create ppc64/scan-log-dump proc
entry\n);
- return -EIO;
- }
+ /* Ideally we could allocate a buffer 4G */
+ data = kzalloc(RTAS_DATA_BUF_SIZE, GFP_KERNEL);
+ if (!data)
+ goto err;
Not your bug, but what happens if data is 4G? Kaboom?
cheers
--
Michael Ellerman
OzLabs, IBM Australia Development Lab
wwweb: http://michael.ellerman.id.au
phone: +61 2 6212 1183 (tie line 70 21183)
We do not inherit the earth from our ancestors,
we borrow it from our children. - S.M.A.R.T Person
signature.asc
Description: This is a digitally signed message part
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: dtc: Trivial formatting fixes
On Wed, Mar 26, 2008 at 08:15:35AM -0500, Jon Loeliger wrote:
This patch fixes some trivial indentation and brace/bracket style
problems.
@@ -179,9 +179,8 @@
arg = argv[optind];
/* minsize and padsize are mutually exclusive */
- if ((minsize) (padsize)) {
+ if (minsize padsize)
die(Can't set both -p and -S\n);
- }
I do not consider extra braces a problem, and will
not be applying those changes. The other indentation
fixes will be applied, of course.
Meh, whatever. Usual kernel style - which is what I originally
adopted for dtc - says no braces for one line blocks.
--
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
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH] [POWERPC] Use lowmem_end_addr to limit lmb allocations on ppc32
Now that we have a proper variable that is the address of the top of low memory we can use it to limit the lmb allocations. Signed-off-by: Kumar Gala [EMAIL PROTECTED] --- include/asm-powerpc/lmb.h |4 ++-- 1 files changed, 2 insertions(+), 2 deletions(-) diff --git a/include/asm-powerpc/lmb.h b/include/asm-powerpc/lmb.h index 028184b..6f5fdf0 100644 --- a/include/asm-powerpc/lmb.h +++ b/include/asm-powerpc/lmb.h @@ -6,8 +6,8 @@ #define LMB_DBG(fmt...) udbg_printf(fmt) #ifdef CONFIG_PPC32 -extern unsigned long __max_low_memory; -#define LMB_REAL_LIMIT __max_low_memory +extern phys_addr_t lowmem_end_addr; +#define LMB_REAL_LIMIT lowmem_end_addr #else #define LMB_REAL_LIMIT 0 #endif -- 1.5.4.1 ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[POWERPC] Rename __initial_memory_limit to __initial_memory_limit_addr
We always use __initial_memory_limit as an address so rename it
to be clear.
Signed-off-by: Kumar Gala [EMAIL PROTECTED]
---
arch/powerpc/mm/fsl_booke_mmu.c |2 +-
arch/powerpc/mm/init_32.c | 10 +-
arch/powerpc/mm/mmu_decl.h |2 +-
arch/powerpc/mm/ppc_mmu_32.c|2 +-
4 files changed, 8 insertions(+), 8 deletions(-)
diff --git a/arch/powerpc/mm/fsl_booke_mmu.c b/arch/powerpc/mm/fsl_booke_mmu.c
index 59f6649..ada249b 100644
--- a/arch/powerpc/mm/fsl_booke_mmu.c
+++ b/arch/powerpc/mm/fsl_booke_mmu.c
@@ -227,5 +227,5 @@ adjust_total_lowmem(void)
__cam0 20, __cam1 20, __cam2 20,
(total_lowmem - __cam0 - __cam1 - __cam2) 20);
__max_low_memory = __cam0 + __cam1 + __cam2;
- __initial_memory_limit = memstart_addr + __max_low_memory;
+ __initial_memory_limit_addr = memstart_addr + __max_low_memory;
}
diff --git a/arch/powerpc/mm/init_32.c b/arch/powerpc/mm/init_32.c
index 345a275..555bb7e 100644
--- a/arch/powerpc/mm/init_32.c
+++ b/arch/powerpc/mm/init_32.c
@@ -96,10 +96,10 @@ int __map_without_ltlbs;
unsigned long __max_low_memory = MAX_LOW_MEM;
/*
- * limit of what is accessible with initial MMU setup -
+ * address of the limit of what is accessible with initial MMU setup -
* 256MB usually, but only 16MB on 601.
*/
-unsigned long __initial_memory_limit = 0x1000;
+unsigned long __initial_memory_limit_addr = 0x1000;
/*
* Check for command-line options that affect what MMU_init will do.
@@ -132,10 +132,10 @@ void __init MMU_init(void)
/* 601 can only access 16MB at the moment */
if (PVR_VER(mfspr(SPRN_PVR)) == 1)
- __initial_memory_limit = 0x0100;
+ __initial_memory_limit_addr = 0x0100;
/* 8xx can only access 8MB at the moment */
if (PVR_VER(mfspr(SPRN_PVR)) == 0x50)
- __initial_memory_limit = 0x0080;
+ __initial_memory_limit_addr = 0x0080;
/* parse args from command line */
MMU_setup();
@@ -210,7 +210,7 @@ void __init *early_get_page(void)
p = alloc_bootmem_pages(PAGE_SIZE);
} else {
p = __va(lmb_alloc_base(PAGE_SIZE, PAGE_SIZE,
- __initial_memory_limit));
+ __initial_memory_limit_addr));
}
return p;
}
diff --git a/arch/powerpc/mm/mmu_decl.h b/arch/powerpc/mm/mmu_decl.h
index 67477e7..0480225 100644
--- a/arch/powerpc/mm/mmu_decl.h
+++ b/arch/powerpc/mm/mmu_decl.h
@@ -48,7 +48,7 @@ extern unsigned int num_tlbcam_entries;
extern unsigned long ioremap_bot;
extern unsigned long __max_low_memory;
-extern unsigned long __initial_memory_limit;
+extern phys_addr_t __initial_memory_limit_addr;
extern unsigned long total_memory;
extern unsigned long total_lowmem;
extern phys_addr_t memstart_addr;
diff --git a/arch/powerpc/mm/ppc_mmu_32.c b/arch/powerpc/mm/ppc_mmu_32.c
index 7dea68b..12b6a46 100644
--- a/arch/powerpc/mm/ppc_mmu_32.c
+++ b/arch/powerpc/mm/ppc_mmu_32.c
@@ -234,7 +234,7 @@ void __init MMU_init_hw(void)
*/
if ( ppc_md.progress ) ppc_md.progress(hash:find piece, 0x322);
Hash = __va(lmb_alloc_base(Hash_size, Hash_size,
- __initial_memory_limit));
+ __initial_memory_limit_addr));
cacheable_memzero(Hash, Hash_size);
_SDR1 = __pa(Hash) | SDR1_LOW_BITS;
--
1.5.4.1
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 4/5] i2c: MPC837xRDB Power Management and GPIO expander driver
On Wed, Mar 26, 2008 at 03:56:37PM -0500, Timur Tabi wrote: Anton Vorontsov wrote: +config MCU_MPC837XRDB + tristate MPC837XRDB MCU driver + depends on I2C MPC837x_RDB OF_GPIO The MPC8349E-mITX also has this chip. Can you include support for that board as well? Well, only if it has the same (or compatible) firmware.. then yes. Thanks for the info, I'll look into this. -- Anton Vorontsov email: [EMAIL PROTECTED] irc://irc.freenode.net/bd2 ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [RESEND][POWERPC] mpc5200: Amalgamated dts fixes and updates
David Gibson wrote:
On Wed, Mar 26, 2008 at 03:16:47PM -0600, Grant Likely wrote:
On Wed, Mar 26, 2008 at 3:02 PM, Matt Sealey [EMAIL PROTECTED] wrote:
Bartlomiej Sieka wrote:
+
+ phy0:[EMAIL PROTECTED] {
+ device_type = ethernet-phy;@0
+ reg = 0;
+ };
What's the parsing of this pan out to? What does it mean?
Having colons in device names is totally contrary to OF device naming
spec. Does the part after the colon have a special meaning to the DTC?
phy0: is a label used by dtc.
[EMAIL PROTECTED] is the node name.
I would suggest a space after the colon though, to make this clearer.
That's the style I've been using in all my dts files.
I would suggest taking a hint from C structures...
[EMAIL PROTECTED] {
name = ethernet-phy;
reg = 0;
foo = bar;
} phy0;
I mean, this is really intuitive, we all do this every day...
--
Matt Sealey [EMAIL PROTECTED]
Genesi, Manager, Developer Relations
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 3/5] leds: implement OpenFirmare GPIO LEDs driver
On Wed, Mar 26, 2008 at 09:04:11PM +, Matt Sealey wrote: Can someone throw me a link to the GPIO spec being implemented here (yes, I would like docs too!) or a pointer to the relevant DTS which implements it? Supporting GPIO in the device tree is something that has been undefined for ages, and I seem to not be able to find the supporting DTS patches for this implementation in patchwork..?? Here the last respin starts: http://ozlabs.org/pipermail/linuxppc-dev/2008-March/052881.html Grant Likely wrote: On Wed, Mar 26, 2008 at 2:24 PM, Anton Vorontsov [EMAIL PROTECTED] wrote: Despite leds-gpio and leds-of-gpio similar names and purposes, there is actually very few code can be shared between the two (both drivers are mostly the driver bindings anyway). Signed-off-by: Anton Vorontsov [EMAIL PROTECTED] Other than the fact that it needs some documentation of the binding in booting-without-of.txt, it looks pretty good to me. Thanks, will document it. -- Anton Vorontsov email: [EMAIL PROTECTED] irc://irc.freenode.net/bd2 ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] scanlog_init cleanup, minor fixes
On Wed, 2008-03-26 at 18:09 -0500, Nathan Lynch wrote: Michael Ellerman wrote: + /* Ideally we could allocate a buffer 4G */ + data = kzalloc(RTAS_DATA_BUF_SIZE, GFP_KERNEL); + if (!data) + goto err; Not your bug, but what happens if data is 4G? Kaboom? An old RPA doc (scan-log-dump isn't specified in PAPR) says the buffer should be contiguous real storage, so... yeah, probably. That's why I preserved the comment. Will fix if I get access to a machine to test this code more thoroughly (plenty of other issues in this file, too). Cool, no point changing it if we can't test it. cheers -- Michael Ellerman OzLabs, IBM Australia Development Lab wwweb: http://michael.ellerman.id.au phone: +61 2 6212 1183 (tie line 70 21183) We do not inherit the earth from our ancestors, we borrow it from our children. - S.M.A.R.T Person signature.asc Description: This is a digitally signed message part ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: Which Kernel for Ocotea (440GX)?
Hi Wolfgang, On Tue, Mar 25, 2008 at 11:45:33PM +0100, Wolfgang Denk wrote: You can find Ocotea support (still arch/ppc only) in our kenrel repository - see git://www.denx.de/git/linux-2.6-denx.git I think if you just followed the links on AMCC's web site they should have taken you there, too. Please let me know if this didn't work for some reason. thank you very much, I fetched the kernel and at least it built correctly. It seems I am still doing something wrong with configuration, but as I am getting this far, it should be possible to solve. I just wanted to give feedback in time that the build is OK. Thank you and best regards, Wolfgang At the moment this is what I get: = bootm 0x40 ## Booting image at 0040 ... Image Name: Linux Created: 2008-03-26 23:12:26 UTC Image Type: PowerPC Linux Kernel Image (gzip compressed) Data Size:1428044 Bytes = 1.4 MB Load Address: Entry Point: Verifying Checksum ... OK Uncompressing Kernel Image ... OK id mach(): done MMU:enter MMU:hw init MMU:mapin MMU:setio MMU:exit setup_arch: enter setup_arch: bootmem ocp: exit arch: exit ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [RESEND][POWERPC] mpc5200: Amalgamated dts fixes and updates
On Wed, Mar 26, 2008 at 10:57:30PM +, Matt Sealey wrote:
David Gibson wrote:
On Wed, Mar 26, 2008 at 03:16:47PM -0600, Grant Likely wrote:
On Wed, Mar 26, 2008 at 3:02 PM, Matt Sealey [EMAIL PROTECTED] wrote:
Bartlomiej Sieka wrote:
+
+ phy0:[EMAIL PROTECTED] {
+ device_type = ethernet-phy;@0
+ reg = 0;
+ };
What's the parsing of this pan out to? What does it mean?
Having colons in device names is totally contrary to OF device naming
spec. Does the part after the colon have a special meaning to the DTC?
phy0: is a label used by dtc.
[EMAIL PROTECTED] is the node name.
I would suggest a space after the colon though, to make this clearer.
That's the style I've been using in all my dts files.
I would suggest taking a hint from C structures...
[EMAIL PROTECTED] {
name = ethernet-phy;
reg = 0;
foo = bar;
} phy0;
I mean, this is really intuitive, we all do this every day...
That's a terrible analogy though. The OF name is in no way like a
structure's type, which is what would go there. Plus it separates the
label from the top of the node which will make it harder to read.
The label syntax is already based on C labels, and can be used more
places than just nodes. Putting a space should make it rather
clearer, and is also closer to normal C style (how many people would
write
out:return(err);
--
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
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 1/2] [MTD] Add support for RAM ROM mappings in the physmap_of MTD driver.
On Wed, Mar 26, 2008 at 04:34:58PM +0100, Segher Boessenkool wrote:
{
+.compatible= physmap-ram,
+.data= (void *)map_ram,
+},
+{
+.compatible= physmap-rom,
+.data= (void *)map_rom,
+},
Why the cast? It's redundant afaics.
To be in line with the surrounding code...
I see _that_, but it's not a great argument IMNSHO. Could I trick
you into preceding this patch with a cleanup patch for the existing
casts?
Hrm. Much as I generally dislike redundant casts, these ones do serve
to inform the reader that the data field is not always a string, which
they might otherwise assume.
--
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
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: DTS question
On Wed, Mar 26, 2008 at 04:32:28PM +0100, Segher Boessenkool wrote: Well.. stock ticker is the new convention. IEEE1275 used IEEE assigned OUI strings (Organization Unique Identifiers). Often those are the same as the stock ticker, but not always. Erm, an OUI is a 24-bit number. I think you're confusing something here. Yes, I think I am. I somehow had the impression that in addition to the 24-bit OUIs used in MAC addresses, there were also string-form OUIs assigned. Perhaps, I'm not an expert on this organisational stuff (wow, big understatement). OF uses only the six-hex-digit form though (with a prepended 0, to make it unique). Note that a stock symbol needs to be written in uppercase; in lowercase, it is just a random name that has no collision protection. Um.. bit too late for that. AFAIK, uppercase has been used by *no-one* for stock ticker derived vendor IDs. No, it's used quite a lot actually. Not in DTS files though ;-) Sorry, yes, I was meaning specifically in recent, flattened-device tree practice (which is the context in which the use stock ticker recommendation has been made. It doesn't matter a lot, lowercase names are perfectly valid, you just don't get the nice non-collision reassurance you would get if you used a name in one of the namespaces reserved for that purpose. It's probably best to not use an uppercase stock symbol if you don't have approval from the company in question anyway -- we use a lowercase name (i.e. in the free-for-all space) for our messed up bindings, the companies use an uppercase name (in the stock-ticker namespace) for their own, incompatible, messed-up bindings, and everyone is happy. Or something like that. -- 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 ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: Which Kernel for Ocotea (440GX)? - working now
Hi again, sorry for the confusion, I forgot to activate the serial console support, now the kernel is booting up fine until it tries to mount the root fs. Thanks again, Wolfgang ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[patch 0/6] PS3 patches for 2.6.26
Paul and Jeff, This is a small set of PS3 patches for 2.6.26. Patches 1-5 are ready to apply to the powerpc tree. Patch 6 for the network driver needs an ACK by Jeff. [1/6] PS3: Fix unlikely typo in ps3_get_irq [2/6] PS3: Add ps3_get_speid routine [3/6] PS3: Bootwrapper improvements [4/6] PS3: Save power in busy loops on halt [5/6] PS3: Sys-manager Wake-on-LAN support [6/6] PS3: Gelic network driver Wake-on-LAN support -Geoff -- ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[patch 1/6] PS3: Fix unlikely typo in ps3_get_irq
From: Roel Kluin [EMAIL PROTECTED]
Fix a typo bug 'unlikely(x) == y' and add an unlikely() call to
an unlikely code path in the PS3 interrupt routine ps3_get_irq().
Signed-off-by: Roel Kluin [EMAIL PROTECTED]
Signed-off-by: Geoff Levand [EMAIL PROTECTED]
---
arch/powerpc/platforms/ps3/interrupt.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/arch/powerpc/platforms/ps3/interrupt.c
+++ b/arch/powerpc/platforms/ps3/interrupt.c
@@ -709,7 +709,7 @@ static unsigned int ps3_get_irq(void)
asm volatile(cntlzd %0,%1 : =r (plug) : r (x));
plug = 0x3f;
- if (unlikely(plug) == NO_IRQ) {
+ if (unlikely(plug == NO_IRQ)) {
pr_debug(%s:%d: no plug found: thread_id %lu\n, __func__,
__LINE__, pd-thread_id);
dump_bmp(per_cpu(ps3_private, 0));
--
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
[patch 2/6] PS3: Add ps3_get_speid routine
From: Takashi Yamamoto [EMAIL PROTECTED]
Add a new routine ps3_get_speid() which returns the logical
SPE ID. This ID is needed for profiling support.
Signed-off-by: Takashi Yamamoto [EMAIL PROTECTED]
Signed-off-by: Geoff Levand [EMAIL PROTECTED]
---
arch/powerpc/platforms/ps3/spu.c |7 +++
1 file changed, 7 insertions(+)
--- a/arch/powerpc/platforms/ps3/spu.c
+++ b/arch/powerpc/platforms/ps3/spu.c
@@ -27,6 +27,7 @@
#include asm/spu.h
#include asm/spu_priv1.h
#include asm/lv1call.h
+#include asm/ps3.h
#include ../cell/spufs/spufs.h
#include platform.h
@@ -140,6 +141,12 @@ static void _dump_areas(unsigned int spe
pr_debug(%s:%d: shadow: %lxh\n, func, line, shadow);
}
+inline u64 ps3_get_spe_id(void *arg)
+{
+ return spu_pdata(arg)-spe_id;
+}
+EXPORT_SYMBOL_GPL(ps3_get_spe_id);
+
static unsigned long get_vas_id(void)
{
unsigned long id;
--
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
[patch 3/6] PS3: Bootwrapper improvements
Improve the debuging support of the PS3 bootwraper code:
o Increase the size of the PS3 bootwrapper overlay from 256 to 512 bytes to
allow for more debugging code in the overlay.
o Use the dot symbol to set the size of __system_reset_overlay. The
asembler will then emit an error if the overlay code is too big.
o Remove some unused instructions.
o Update the text describing the PS3 bootwrapper overlay.
o Add a check for null pointer writes.
o Change hcall return value from s64.
Signed-off-by: Geoff Levand [EMAIL PROTECTED]
---
arch/powerpc/boot/ps3-head.S | 25 -
arch/powerpc/boot/ps3.c | 21 +
arch/powerpc/boot/wrapper| 21 +++--
3 files changed, 40 insertions(+), 27 deletions(-)
--- a/arch/powerpc/boot/ps3-head.S
+++ b/arch/powerpc/boot/ps3-head.S
@@ -27,8 +27,9 @@
/*
* __system_reset_overlay - The PS3 first stage entry.
*
- * The bootwraper build script copies the 0x100 bytes at symbol
- * __system_reset_overlay to offset 0x100 of the rom image.
+ * The bootwraper build script copies the 512 bytes at symbol
+ * __system_reset_overlay to offset 0x100 of the rom image. This symbol
+ * must occupy 512 or less bytes.
*
* The PS3 has a single processor with two threads.
*/
@@ -47,8 +48,6 @@ __system_reset_overlay:
mfspr r3, 0x88
cntlzw. r3, r3
- li r4, 0
- li r5, 0
beq 1f
/* Secondary goes to __secondary_hold in kernel. */
@@ -57,8 +56,14 @@ __system_reset_overlay:
mtctr r4
bctr
- /* Primary delays then goes to _zimage_start in wrapper. */
1:
+ /* Save the value at addr zero for a null pointer write check later. */
+
+ li r4, 0
+ lwz r3, 0(r4)
+
+ /* Primary delays then goes to _zimage_start in wrapper. */
+
or 31, 31, 31 /* db16cyc */
or 31, 31, 31 /* db16cyc */
@@ -67,16 +72,18 @@ __system_reset_overlay:
mtctr r4
bctr
+ . = __system_reset_overlay + 512
+
/*
* __system_reset_kernel - Place holder for the kernel reset vector.
*
- * The bootwrapper build script copies 0x100 bytes from offset 0x100
+ * The bootwrapper build script copies 512 bytes from offset 0x100
* of the rom image to the symbol __system_reset_kernel. At runtime
- * the bootwrapper program copies the 0x100 bytes at __system_reset_kernel
- * to ram address 0x100. This symbol must occupy 0x100 bytes.
+ * the bootwrapper program copies the 512 bytes at __system_reset_kernel
+ * to ram address 0x100. This symbol must occupy 512 bytes.
*/
.globl __system_reset_kernel
__system_reset_kernel:
- . = __system_reset_kernel + 0x100
+ . = __system_reset_kernel + 512
--- a/arch/powerpc/boot/ps3.c
+++ b/arch/powerpc/boot/ps3.c
@@ -27,10 +27,10 @@
#include page.h
#include ops.h
-extern s64 lv1_panic(u64 in_1);
-extern s64 lv1_get_logical_partition_id(u64 *out_1);
-extern s64 lv1_get_logical_ppe_id(u64 *out_1);
-extern s64 lv1_get_repository_node_value(u64 in_1, u64 in_2, u64 in_3,
+extern int lv1_panic(u64 in_1);
+extern int lv1_get_logical_partition_id(u64 *out_1);
+extern int lv1_get_logical_ppe_id(u64 *out_1);
+extern int lv1_get_repository_node_value(u64 in_1, u64 in_2, u64 in_3,
u64 in_4, u64 in_5, u64 *out_1, u64 *out_2);
#ifdef DEBUG
@@ -46,6 +46,7 @@ BSS_STACK(4096);
* edit the command line passed to vmlinux (by setting /chosen/bootargs).
* The buffer is put in it's own section so that tools may locate it easier.
*/
+
static char cmdline[COMMAND_LINE_SIZE]
__attribute__((__section__(__builtin_cmdline)));
@@ -75,7 +76,7 @@ static void ps3_exit(void)
static int ps3_repository_read_rm_size(u64 *rm_size)
{
- s64 result;
+ int result;
u64 lpar_id;
u64 ppe_id;
u64 v2;
@@ -114,11 +115,11 @@ void ps3_copy_vectors(void)
{
extern char __system_reset_kernel[];
- memcpy((void *)0x100, __system_reset_kernel, 0x100);
- flush_cache((void *)0x100, 0x100);
+ memcpy((void *)0x100, __system_reset_kernel, 512);
+ flush_cache((void *)0x100, 512);
}
-void platform_init(void)
+void platform_init(unsigned long null_check)
{
const u32 heapsize = 0x100 - (u32)_end; /* 16MiB */
void *chosen;
@@ -151,6 +152,10 @@ void platform_init(void)
printf( flat tree at 0x%lx\n\r, ft_addr);
+ if (*(unsigned long *)0 != null_check)
+ printf(null check failed: %lx != %lx\n\r, *(unsigned long *)0,
+ (unsigned long)null_check);
+
((kernel_entry_t)0)(ft_addr, 0, NULL);
ps3_exit();
--- a/arch/powerpc/boot/wrapper
+++ b/arch/powerpc/boot/wrapper
@@ -298,15 +298,16 @@ treeboot*)
exit 0
;;
ps3)
-# The ps3's loader supports loading gzipped binary images from flash
-# rom to addr zero. The loader enters the image at addr 0x100. A
-# bootwrapper overlay is use to
[patch 4/6] PS3: Save power in busy loops on halt
From: Geert Uytterhoeven [EMAIL PROTECTED]
PS3 save power on halt:
- Replace infinite busy loops by smarter loops calling
lv1_pause() to save power.
- Add ps3_halt() and ps3_sys_manager_halt().
- Add __noreturn annotations.
Signed-off-by: Geert Uytterhoeven [EMAIL PROTECTED]
Signed-off-by: Geoff Levand [EMAIL PROTECTED]
---
arch/powerpc/platforms/ps3/setup.c | 12 +++-
drivers/ps3/ps3-sys-manager.c | 30 --
drivers/ps3/sys-manager-core.c | 16 ++--
include/asm-powerpc/ps3.h |5 +++--
4 files changed, 44 insertions(+), 19 deletions(-)
--- a/arch/powerpc/platforms/ps3/setup.c
+++ b/arch/powerpc/platforms/ps3/setup.c
@@ -95,6 +95,14 @@ static void ps3_power_off(void)
ps3_sys_manager_power_off(); /* never returns */
}
+static void ps3_halt(void)
+{
+ DBG(%s:%d\n, __func__, __LINE__);
+
+ smp_send_stop();
+ ps3_sys_manager_halt(); /* never returns */
+}
+
static void ps3_panic(char *str)
{
DBG(%s:%d %s\n, __func__, __LINE__, str);
@@ -105,7 +113,8 @@ static void ps3_panic(char *str)
printk( Please press POWER button.\n);
printk(\n);
- while(1);
+ while(1)
+ lv1_pause(1);
}
#if defined(CONFIG_FB_PS3) || defined(CONFIG_FB_PS3_MODULE) || \
@@ -266,6 +275,7 @@ define_machine(ps3) {
.progress = ps3_progress,
.restart= ps3_restart,
.power_off = ps3_power_off,
+ .halt = ps3_halt,
#if defined(CONFIG_KEXEC)
.kexec_cpu_down = ps3_kexec_cpu_down,
.machine_kexec = default_machine_kexec,
--- a/drivers/ps3/ps3-sys-manager.c
+++ b/drivers/ps3/ps3-sys-manager.c
@@ -24,6 +24,7 @@
#include linux/reboot.h
#include asm/firmware.h
+#include asm/lv1call.h
#include asm/ps3.h
#include vuart.h
@@ -581,6 +582,23 @@ fail_id:
return -EIO;
}
+static void ps3_sys_manager_fin(struct ps3_system_bus_device *dev)
+{
+ ps3_sys_manager_send_request_shutdown(dev);
+
+ pr_emerg(System Halted, OK to turn off power\n);
+
+ while (ps3_sys_manager_handle_msg(dev)) {
+ /* pause until next DEC interrupt */
+ lv1_pause(0);
+ }
+
+ while (1) {
+ /* pause, ignoring DEC interrupt */
+ lv1_pause(1);
+ }
+}
+
/**
* ps3_sys_manager_final_power_off - The final platform machine_power_off
routine.
*
@@ -602,12 +620,8 @@ static void ps3_sys_manager_final_power_
ps3_sys_manager_send_next_op(dev, PS3_SM_NEXT_OP_SYS_SHUTDOWN,
PS3_SM_WAKE_DEFAULT);
- ps3_sys_manager_send_request_shutdown(dev);
-
- pr_emerg(System Halted, OK to turn off power\n);
- while (1)
- ps3_sys_manager_handle_msg(dev);
+ ps3_sys_manager_fin(dev);
}
/**
@@ -639,12 +653,8 @@ static void ps3_sys_manager_final_restar
ps3_sys_manager_send_attr(dev, 0);
ps3_sys_manager_send_next_op(dev, PS3_SM_NEXT_OP_SYS_REBOOT,
PS3_SM_WAKE_DEFAULT);
- ps3_sys_manager_send_request_shutdown(dev);
-
- pr_emerg(System Halted, OK to turn off power\n);
- while (1)
- ps3_sys_manager_handle_msg(dev);
+ ps3_sys_manager_fin(dev);
}
/**
--- a/drivers/ps3/sys-manager-core.c
+++ b/drivers/ps3/sys-manager-core.c
@@ -19,6 +19,7 @@
*/
#include linux/kernel.h
+#include asm/lv1call.h
#include asm/ps3.h
/**
@@ -50,10 +51,7 @@ void ps3_sys_manager_power_off(void)
if (ps3_sys_manager_ops.power_off)
ps3_sys_manager_ops.power_off(ps3_sys_manager_ops.dev);
- printk(KERN_EMERG System Halted, OK to turn off power\n);
- local_irq_disable();
- while (1)
- (void)0;
+ ps3_sys_manager_halt();
}
void ps3_sys_manager_restart(void)
@@ -61,8 +59,14 @@ void ps3_sys_manager_restart(void)
if (ps3_sys_manager_ops.restart)
ps3_sys_manager_ops.restart(ps3_sys_manager_ops.dev);
- printk(KERN_EMERG System Halted, OK to turn off power\n);
+ ps3_sys_manager_halt();
+}
+
+void ps3_sys_manager_halt(void)
+{
+ pr_emerg(System Halted, OK to turn off power\n);
local_irq_disable();
while (1)
- (void)0;
+ lv1_pause(1);
}
+
--- a/include/asm-powerpc/ps3.h
+++ b/include/asm-powerpc/ps3.h
@@ -434,8 +434,9 @@ struct ps3_sys_manager_ops {
};
void ps3_sys_manager_register_ops(const struct ps3_sys_manager_ops *ops);
-void ps3_sys_manager_power_off(void);
-void ps3_sys_manager_restart(void);
+void __noreturn ps3_sys_manager_power_off(void);
+void __noreturn ps3_sys_manager_restart(void);
+void __noreturn ps3_sys_manager_halt(void);
struct ps3_prealloc {
const char *name;
--
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
[patch 5/6] PS3: Sys-manager Wake-on-LAN support
Add Wake-on-LAN support to the PS3 system-manager. Other OS WOL
support was introduced in PS3 system firmware 2.20.
Signed-off-by: Geoff Levand [EMAIL PROTECTED]
---
drivers/ps3/ps3-sys-manager.c | 46 --
include/asm-powerpc/ps3.h |2 +
2 files changed, 46 insertions(+), 2 deletions(-)
--- a/drivers/ps3/ps3-sys-manager.c
+++ b/drivers/ps3/ps3-sys-manager.c
@@ -188,6 +188,7 @@ enum ps3_sys_manager_next_op {
* controller, and bluetooth controller.
* @PS3_SM_WAKE_RTC:
* @PS3_SM_WAKE_RTC_ERROR:
+ * @PS3_SM_WAKE_W_O_L: Ether or wireless LAN.
* @PS3_SM_WAKE_P_O_R: Power on reset.
*
* Additional wakeup sources when specifying PS3_SM_NEXT_OP_SYS_SHUTDOWN.
@@ -201,10 +202,19 @@ enum ps3_sys_manager_wake_source {
PS3_SM_WAKE_DEFAULT = 0,
PS3_SM_WAKE_RTC = 0x0040,
PS3_SM_WAKE_RTC_ERROR = 0x0080,
+ PS3_SM_WAKE_W_O_L = 0x0400,
PS3_SM_WAKE_P_O_R = 0x8000,
};
/**
+ * user_wake_sources - User specified wakeup sources.
+ *
+ * Logical OR of enum ps3_sys_manager_wake_source types.
+ */
+
+static u32 user_wake_sources = PS3_SM_WAKE_DEFAULT;
+
+/**
* enum ps3_sys_manager_cmd - Command from system manager to guest.
*
* The guest completes the actions needed, then acks or naks the command via
@@ -619,7 +629,7 @@ static void ps3_sys_manager_final_power_
ps3_vuart_cancel_async(dev);
ps3_sys_manager_send_next_op(dev, PS3_SM_NEXT_OP_SYS_SHUTDOWN,
- PS3_SM_WAKE_DEFAULT);
+ user_wake_sources);
ps3_sys_manager_fin(dev);
}
@@ -652,12 +662,44 @@ static void ps3_sys_manager_final_restar
ps3_sys_manager_send_attr(dev, 0);
ps3_sys_manager_send_next_op(dev, PS3_SM_NEXT_OP_SYS_REBOOT,
- PS3_SM_WAKE_DEFAULT);
+ user_wake_sources);
ps3_sys_manager_fin(dev);
}
/**
+ * ps3_sys_manager_get_wol - Get wake-on-lan setting.
+ */
+
+int ps3_sys_manager_get_wol(void)
+{
+ pr_debug(%s:%d\n, __func__, __LINE__);
+
+ return (user_wake_sources PS3_SM_WAKE_W_O_L) != 0;
+}
+EXPORT_SYMBOL_GPL(ps3_sys_manager_get_wol);
+
+/**
+ * ps3_sys_manager_set_wol - Set wake-on-lan setting.
+ */
+
+void ps3_sys_manager_set_wol(int state)
+{
+ static DEFINE_MUTEX(mutex);
+
+ mutex_lock(mutex);
+
+ pr_debug(%s:%d: %d\n, __func__, __LINE__, state);
+
+ if (state)
+ user_wake_sources |= PS3_SM_WAKE_W_O_L;
+ else
+ user_wake_sources = ~PS3_SM_WAKE_W_O_L;
+ mutex_unlock(mutex);
+}
+EXPORT_SYMBOL_GPL(ps3_sys_manager_set_wol);
+
+/**
* ps3_sys_manager_work - Asynchronous read handler.
*
* Signaled when PS3_SM_RX_MSG_LEN_MIN bytes arrive at the vuart port.
--- a/include/asm-powerpc/ps3.h
+++ b/include/asm-powerpc/ps3.h
@@ -437,6 +437,8 @@ void ps3_sys_manager_register_ops(const
void __noreturn ps3_sys_manager_power_off(void);
void __noreturn ps3_sys_manager_restart(void);
void __noreturn ps3_sys_manager_halt(void);
+int ps3_sys_manager_get_wol(void);
+void ps3_sys_manager_set_wol(int state);
struct ps3_prealloc {
const char *name;
--
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
[patch 6/6] PS3: Gelic network driver Wake-on-LAN support
From: Masakazu Mokuno [EMAIL PROTECTED]
Add Wake-on-LAN support to the PS3 Gelic network driver.
Other OS WOL support was introduced in PS3 system firmware
2.20.
Signed-off-by: Masakazu Mokuno [EMAIL PROTECTED]
Signed-off-by: Geoff Levand [EMAIL PROTECTED]
---
drivers/net/ps3_gelic_net.c | 81
drivers/net/ps3_gelic_net.h | 20 ++
2 files changed, 101 insertions(+)
--- a/drivers/net/ps3_gelic_net.c
+++ b/drivers/net/ps3_gelic_net.c
@@ -1266,6 +1266,85 @@ int gelic_net_set_rx_csum(struct net_dev
return 0;
}
+static void gelic_net_get_wol(struct net_device *netdev,
+ struct ethtool_wolinfo *wol)
+{
+ if (0 = ps3_compare_firmware_version(2, 2, 0))
+ wol-supported = WAKE_MAGIC;
+ else
+ wol-supported = 0;
+
+ wol-wolopts = ps3_sys_manager_get_wol() ? wol-supported : 0;
+ memset(wol-sopass, 0, sizeof(wol-sopass));
+}
+static int gelic_net_set_wol(struct net_device *netdev,
+struct ethtool_wolinfo *wol)
+{
+ int status;
+ struct gelic_card *card;
+ u64 v1, v2;
+
+ if (ps3_compare_firmware_version(2, 2, 0) 0 ||
+ !capable(CAP_NET_ADMIN))
+ return -EPERM;
+
+ if (wol-wolopts ~WAKE_MAGIC)
+ return -EINVAL;
+
+ card = netdev_card(netdev);
+ if (wol-wolopts WAKE_MAGIC) {
+ status = lv1_net_control(bus_id(card), dev_id(card),
+GELIC_LV1_SET_WOL,
+GELIC_LV1_WOL_MAGIC_PACKET,
+0, GELIC_LV1_WOL_MP_ENABLE,
+v1, v2);
+ if (status) {
+ pr_info(%s: enabling WOL failed %d\n, __func__,
+ status);
+ status = -EIO;
+ goto done;
+ }
+ status = lv1_net_control(bus_id(card), dev_id(card),
+GELIC_LV1_SET_WOL,
+GELIC_LV1_WOL_ADD_MATCH_ADDR,
+0, GELIC_LV1_WOL_MATCH_ALL,
+v1, v2);
+ if (!status)
+ ps3_sys_manager_set_wol(1);
+ else {
+ pr_info(%s: enabling WOL filter failed %d\n,
+ __func__, status);
+ status = -EIO;
+ }
+ } else {
+ status = lv1_net_control(bus_id(card), dev_id(card),
+GELIC_LV1_SET_WOL,
+GELIC_LV1_WOL_MAGIC_PACKET,
+0, GELIC_LV1_WOL_MP_DISABLE,
+v1, v2);
+ if (status) {
+ pr_info(%s: disabling WOL failed %d\n, __func__,
+ status);
+ status = -EIO;
+ goto done;
+ }
+ status = lv1_net_control(bus_id(card), dev_id(card),
+GELIC_LV1_SET_WOL,
+GELIC_LV1_WOL_DELETE_MATCH_ADDR,
+0, GELIC_LV1_WOL_MATCH_ALL,
+v1, v2);
+ if (!status)
+ ps3_sys_manager_set_wol(0);
+ else {
+ pr_info(%s: removing WOL filter failed %d\n,
+ __func__, status);
+ status = -EIO;
+ }
+ }
+done:
+ return status;
+}
+
static struct ethtool_ops gelic_ether_ethtool_ops = {
.get_drvinfo= gelic_net_get_drvinfo,
.get_settings = gelic_ether_get_settings,
@@ -1274,6 +1353,8 @@ static struct ethtool_ops gelic_ether_et
.set_tx_csum= ethtool_op_set_tx_csum,
.get_rx_csum= gelic_net_get_rx_csum,
.set_rx_csum= gelic_net_set_rx_csum,
+ .get_wol= gelic_net_get_wol,
+ .set_wol= gelic_net_set_wol,
};
/**
--- a/drivers/net/ps3_gelic_net.h
+++ b/drivers/net/ps3_gelic_net.h
@@ -182,12 +182,32 @@ enum gelic_lv1_net_control_code {
GELIC_LV1_GET_ETH_PORT_STATUS = 2,
GELIC_LV1_SET_NEGOTIATION_MODE = 3,
GELIC_LV1_GET_VLAN_ID = 4,
+ GELIC_LV1_SET_WOL = 5,
GELIC_LV1_GET_CHANNEL = 6,
GELIC_LV1_POST_WLAN_CMD = 9,
GELIC_LV1_GET_WLAN_CMD_RESULT = 10,
GELIC_LV1_GET_WLAN_EVENT= 11
};
+/* for GELIC_LV1_SET_WOL */
+enum gelic_lv1_wol_command {
+ GELIC_LV1_WOL_MAGIC_PACKET = 1,
+ GELIC_LV1_WOL_ADD_MATCH_ADDR= 6,
+ GELIC_LV1_WOL_DELETE_MATCH_ADDR = 7,
+};
+
+/* for
Re: [patch 5/6] PS3: Sys-manager Wake-on-LAN support
On Wed, 2008-03-26 at 17:39 -0700, Geoff Levand wrote:
Add Wake-on-LAN support to the PS3 system-manager. Other OS WOL
support was introduced in PS3 system firmware 2.20.
There is no sleep in the first place tho :-) Or does this power it up /
boot it using WoL packets ?
Cheers,
Ben.
Signed-off-by: Geoff Levand [EMAIL PROTECTED]
---
drivers/ps3/ps3-sys-manager.c | 46
--
include/asm-powerpc/ps3.h |2 +
2 files changed, 46 insertions(+), 2 deletions(-)
--- a/drivers/ps3/ps3-sys-manager.c
+++ b/drivers/ps3/ps3-sys-manager.c
@@ -188,6 +188,7 @@ enum ps3_sys_manager_next_op {
* controller, and bluetooth controller.
* @PS3_SM_WAKE_RTC:
* @PS3_SM_WAKE_RTC_ERROR:
+ * @PS3_SM_WAKE_W_O_L: Ether or wireless LAN.
* @PS3_SM_WAKE_P_O_R: Power on reset.
*
* Additional wakeup sources when specifying PS3_SM_NEXT_OP_SYS_SHUTDOWN.
@@ -201,10 +202,19 @@ enum ps3_sys_manager_wake_source {
PS3_SM_WAKE_DEFAULT = 0,
PS3_SM_WAKE_RTC = 0x0040,
PS3_SM_WAKE_RTC_ERROR = 0x0080,
+ PS3_SM_WAKE_W_O_L = 0x0400,
PS3_SM_WAKE_P_O_R = 0x8000,
};
/**
+ * user_wake_sources - User specified wakeup sources.
+ *
+ * Logical OR of enum ps3_sys_manager_wake_source types.
+ */
+
+static u32 user_wake_sources = PS3_SM_WAKE_DEFAULT;
+
+/**
* enum ps3_sys_manager_cmd - Command from system manager to guest.
*
* The guest completes the actions needed, then acks or naks the command via
@@ -619,7 +629,7 @@ static void ps3_sys_manager_final_power_
ps3_vuart_cancel_async(dev);
ps3_sys_manager_send_next_op(dev, PS3_SM_NEXT_OP_SYS_SHUTDOWN,
- PS3_SM_WAKE_DEFAULT);
+ user_wake_sources);
ps3_sys_manager_fin(dev);
}
@@ -652,12 +662,44 @@ static void ps3_sys_manager_final_restar
ps3_sys_manager_send_attr(dev, 0);
ps3_sys_manager_send_next_op(dev, PS3_SM_NEXT_OP_SYS_REBOOT,
- PS3_SM_WAKE_DEFAULT);
+ user_wake_sources);
ps3_sys_manager_fin(dev);
}
/**
+ * ps3_sys_manager_get_wol - Get wake-on-lan setting.
+ */
+
+int ps3_sys_manager_get_wol(void)
+{
+ pr_debug(%s:%d\n, __func__, __LINE__);
+
+ return (user_wake_sources PS3_SM_WAKE_W_O_L) != 0;
+}
+EXPORT_SYMBOL_GPL(ps3_sys_manager_get_wol);
+
+/**
+ * ps3_sys_manager_set_wol - Set wake-on-lan setting.
+ */
+
+void ps3_sys_manager_set_wol(int state)
+{
+ static DEFINE_MUTEX(mutex);
+
+ mutex_lock(mutex);
+
+ pr_debug(%s:%d: %d\n, __func__, __LINE__, state);
+
+ if (state)
+ user_wake_sources |= PS3_SM_WAKE_W_O_L;
+ else
+ user_wake_sources = ~PS3_SM_WAKE_W_O_L;
+ mutex_unlock(mutex);
+}
+EXPORT_SYMBOL_GPL(ps3_sys_manager_set_wol);
+
+/**
* ps3_sys_manager_work - Asynchronous read handler.
*
* Signaled when PS3_SM_RX_MSG_LEN_MIN bytes arrive at the vuart port.
--- a/include/asm-powerpc/ps3.h
+++ b/include/asm-powerpc/ps3.h
@@ -437,6 +437,8 @@ void ps3_sys_manager_register_ops(const
void __noreturn ps3_sys_manager_power_off(void);
void __noreturn ps3_sys_manager_restart(void);
void __noreturn ps3_sys_manager_halt(void);
+int ps3_sys_manager_get_wol(void);
+void ps3_sys_manager_set_wol(int state);
struct ps3_prealloc {
const char *name;
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [patch 5/6] PS3: Sys-manager Wake-on-LAN support
Hi, Benjamin Herrenschmidt wrote: On Wed, 2008-03-26 at 17:39 -0700, Geoff Levand wrote: Add Wake-on-LAN support to the PS3 system-manager. Other OS WOL support was introduced in PS3 system firmware 2.20. There is no sleep in the first place tho :-) Or does this power it up / boot it using WoL packets ? Whenever that red light in ON in the front, the system is in 'stand by' mode. If you setup WOL before entering standby mode (by using linux poweroff command, pressing the power button, etc.), you can wake it up: On ps3 # ethtool -s eth0 wol g # shutdown -h now by remote host (eth1 is connected to the subnet which PS3 resides in) # etherwake -i eth1 aa:bb:cc:dd:ee:ff I plan to send out a how-to to the ceb-oss-dev ML in the next day or so. -Geoff ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
=?gb2312?q?=BB=D8=B8=B4=A3=BA=20Could=20PowerPC(IBM=20power=20blade, =20js?= 21, 8844) boot via usb key?
Does anyone know about it? Thanks a lot. Kelvin Lin [EMAIL PROTECTED] 写道： Hi guys, I created a PReP partition in usb key and then did dd and something like that to configure yaboot on it. But the key point is that, when I boot power blade, there is not usb key in the bootable list. I mean, there are just: 1.- Ethernet ( loc=U788D.001.99DXC6K-P1-T7 ) 2.- Ethernet ( loc=U788D.001.99DXC6K-P1-T8 ) 3.- USB CD-ROM ( loc=U788D.001.99DXC6K-P1-T1-L1-L3 ) 4.1 SCSI 36401 MB Harddisk, part=1 () ( loc=U788D.001.99DXC6K-P1-T10-L1-L0 ) My usb key is Kingston's DataTraveler 2GB. Then I change another Sandisk cruzer 2GB usb key, it shows as follows in the boot menu: 1.- Ethernet ( loc=U788D.001.99DXC6K-P1-T7 ) 2.- Ethernet ( loc=U788D.001.99DXC6K-P1-T8 ) 3.- USB CD-ROM ( loc=U788D.001.99DXC6K-P1-T1-L1-L3 ) 4.1 SCSI 36401 MB Harddisk, part=1 () ( loc=U788D.001.99DXC6K-P1-T10-L1-L0 ) 5.- USB CD-ROM ( loc=U788D.001.99DXC6K-P1-T1-L1-L2-L1-L0 ) But this item 5 USB CD-ROM is simulated by Sandisk, not the actual usb key. I can't boot my server via item 5. Could IBM power blade, js 21, 8844 boot via usb key? If not, could you please provide official doc to prove it. Because I have to persuade my boss to give up it. -:) Any comment is appreciated. Thanks a lot in advanced. Kelvin. - 雅虎邮箱，您的终生邮箱！___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev - 雅虎邮箱，您的终生邮箱！___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH] [POWERPC] Remove CONFIG_PCI_LEGACY from pasemi_defconfig
This should eliminate several build warnings and only removes the possibility of building some ISDN drivers that we don't build anyway. It was done by copying pasemi_defconfig to .config, removing CONFIG_PCI_LEGACY, running make oldconfig and taking the defaults for everything except CONFIG_PCI_LEGACY. Signed-off-by: Stephen Rothwell [EMAIL PROTECTED] --- arch/powerpc/configs/pasemi_defconfig | 139 ++--- 1 files changed, 93 insertions(+), 46 deletions(-) Olof, you should review this carefully to see if anything got turned off that you need (e.g. CONFIG_MTD_NAND_PASEMI) or turned on that you don't want (e.g. Conflicting RTC option has been selected, check GEN_RTC and RTC). I have built this config. This patch is on top of the powerpc master tree. diff --git a/arch/powerpc/configs/pasemi_defconfig b/arch/powerpc/configs/pasemi_defconfig index 797f0df..419ca4e 100644 --- a/arch/powerpc/configs/pasemi_defconfig +++ b/arch/powerpc/configs/pasemi_defconfig @@ -1,7 +1,7 @@ # # Automatically generated make config: don't edit -# Linux kernel version: 2.6.24-rc6 -# Tue Jan 15 10:26:10 2008 +# Linux kernel version: 2.6.25-rc6 +# Thu Mar 27 13:56:20 2008 # CONFIG_PPC64=y @@ -27,6 +27,7 @@ CONFIG_GENERIC_TIME=y CONFIG_GENERIC_TIME_VSYSCALL=y CONFIG_GENERIC_CLOCKEVENTS=y CONFIG_GENERIC_HARDIRQS=y +CONFIG_HAVE_SETUP_PER_CPU_AREA=y CONFIG_IRQ_PER_CPU=y CONFIG_RWSEM_XCHGADD_ALGORITHM=y CONFIG_ARCH_HAS_ILOG2_U32=y @@ -67,17 +68,23 @@ CONFIG_SYSVIPC_SYSCTL=y # CONFIG_POSIX_MQUEUE is not set # CONFIG_BSD_PROCESS_ACCT is not set # CONFIG_TASKSTATS is not set -# CONFIG_USER_NS is not set -# CONFIG_PID_NS is not set # CONFIG_AUDIT is not set # CONFIG_IKCONFIG is not set CONFIG_LOG_BUF_SHIFT=17 # CONFIG_CGROUPS is not set +CONFIG_GROUP_SCHED=y CONFIG_FAIR_GROUP_SCHED=y -CONFIG_FAIR_USER_SCHED=y -# CONFIG_FAIR_CGROUP_SCHED is not set +# CONFIG_RT_GROUP_SCHED is not set +CONFIG_USER_SCHED=y +# CONFIG_CGROUP_SCHED is not set CONFIG_SYSFS_DEPRECATED=y +CONFIG_SYSFS_DEPRECATED_V2=y # CONFIG_RELAY is not set +CONFIG_NAMESPACES=y +# CONFIG_UTS_NS is not set +# CONFIG_IPC_NS is not set +# CONFIG_USER_NS is not set +# CONFIG_PID_NS is not set CONFIG_BLK_DEV_INITRD=y CONFIG_INITRAMFS_SOURCE= # CONFIG_CC_OPTIMIZE_FOR_SIZE is not set @@ -91,11 +98,13 @@ CONFIG_HOTPLUG=y CONFIG_PRINTK=y CONFIG_BUG=y CONFIG_ELF_CORE=y +CONFIG_COMPAT_BRK=y CONFIG_BASE_FULL=y CONFIG_FUTEX=y CONFIG_ANON_INODES=y CONFIG_EPOLL=y CONFIG_SIGNALFD=y +CONFIG_TIMERFD=y CONFIG_EVENTFD=y CONFIG_SHMEM=y CONFIG_VM_EVENT_COUNTERS=y @@ -103,6 +112,15 @@ CONFIG_SLUB_DEBUG=y # CONFIG_SLAB is not set CONFIG_SLUB=y # CONFIG_SLOB is not set +CONFIG_PROFILING=y +# CONFIG_MARKERS is not set +CONFIG_OPROFILE=y +CONFIG_HAVE_OPROFILE=y +# CONFIG_KPROBES is not set +CONFIG_HAVE_KPROBES=y +CONFIG_HAVE_KRETPROBES=y +CONFIG_PROC_PAGE_MONITOR=y +CONFIG_SLABINFO=y CONFIG_RT_MUTEXES=y # CONFIG_TINY_SHMEM is not set CONFIG_BASE_SMALL=0 @@ -130,6 +148,7 @@ CONFIG_DEFAULT_AS=y # CONFIG_DEFAULT_CFQ is not set # CONFIG_DEFAULT_NOOP is not set CONFIG_DEFAULT_IOSCHED=anticipatory +CONFIG_CLASSIC_RCU=y # # Platform support @@ -140,8 +159,8 @@ CONFIG_PPC_MULTIPLATFORM=y # CONFIG_PPC_86xx is not set # CONFIG_PPC_PSERIES is not set # CONFIG_PPC_ISERIES is not set -# CONFIG_PPC_MPC52xx is not set -# CONFIG_PPC_MPC5200 is not set +# CONFIG_PPC_MPC512x is not set +# CONFIG_PPC_MPC5121 is not set # CONFIG_PPC_PMAC is not set # CONFIG_PPC_MAPLE is not set CONFIG_PPC_PASEMI=y @@ -159,6 +178,7 @@ CONFIG_PPC_PASEMI_MDIO=y # CONFIG_PPC_IBM_CELL_BLADE is not set # CONFIG_PQ2ADS is not set CONFIG_PPC_NATIVE=y +# CONFIG_IPIC is not set CONFIG_MPIC=y # CONFIG_MPIC_WEIRD is not set # CONFIG_PPC_I8259 is not set @@ -189,7 +209,6 @@ CONFIG_CPU_FREQ_GOV_ONDEMAND=y # CPU Frequency drivers # CONFIG_PPC_PASEMI_CPUFREQ=y -# CONFIG_CPM2 is not set # CONFIG_FSL_ULI1575 is not set # @@ -204,16 +223,20 @@ CONFIG_GENERIC_CLOCKEVENTS_BUILD=y # CONFIG_HZ_300 is not set CONFIG_HZ_1000=y CONFIG_HZ=1000 +# CONFIG_SCHED_HRTICK is not set CONFIG_PREEMPT_NONE=y # CONFIG_PREEMPT_VOLUNTARY is not set # CONFIG_PREEMPT is not set -# CONFIG_PREEMPT_BKL is not set CONFIG_BINFMT_ELF=y +CONFIG_COMPAT_BINFMT_ELF=y # CONFIG_BINFMT_MISC is not set CONFIG_FORCE_MAX_ZONEORDER=9 CONFIG_HUGETLB_PAGE_SIZE_VARIABLE=y CONFIG_IOMMU_VMERGE=y +CONFIG_IOMMU_HELPER=y CONFIG_ARCH_ENABLE_MEMORY_HOTPLUG=y +CONFIG_ARCH_HAS_WALK_MEMORY=y +CONFIG_ARCH_ENABLE_MEMORY_HOTREMOVE=y # CONFIG_KEXEC is not set # CONFIG_CRASH_DUMP is not set # CONFIG_IRQ_ALL_CPUS is not set @@ -236,12 +259,12 @@ CONFIG_ZONE_DMA_FLAG=1 CONFIG_BOUNCE=y CONFIG_PPC_HAS_HASH_64K=y CONFIG_PPC_64K_PAGES=y +# CONFIG_PPC_SUBPAGE_PROT is not set # CONFIG_SCHED_SMT is not set CONFIG_PROC_DEVICETREE=y # CONFIG_CMDLINE_BOOL is not set # CONFIG_PM is not set # CONFIG_SECCOMP is not set -# CONFIG_WANT_DEVICE_TREE is not set CONFIG_ISA_DMA_API=y # @@ -256,7 +279,7 @@
Re: [PATCH] [POWERPC] Remove CONFIG_PCI_LEGACY from pasemi_defconfig
Hi, On Thu, Mar 27, 2008 at 02:27:43PM +1100, Stephen Rothwell wrote: Olof, you should review this carefully to see if anything got turned off that you need (e.g. CONFIG_MTD_NAND_PASEMI) or turned on that you don't want (e.g. Conflicting RTC option has been selected, check GEN_RTC and RTC). I have built this config. This patch is on top of the powerpc master tree. I've already requested Paul to pull a defconfig update that includes all changes besides the PCI_LEGACY disabling. Since it's not critical, I'll do the same change in the for-2.6.26 branch but let the pull request for 2.6.25 be as-is, if that's OK with you. This is of course with the hopes that Paul will pull and push it before the .25 release. Thanks, -Olof ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: DTS question
On Thu, 27 Mar 2008 10:40:43 +1100 David Gibson [EMAIL PROTECTED] wrote: Note that a stock symbol needs to be written in uppercase; in lowercase, it is just a random name that has no collision protection. Um.. bit too late for that. AFAIK, uppercase has been used by *no-one* for stock ticker derived vendor IDs. No, it's used quite a lot actually. Not in DTS files though ;-) Sorry, yes, I was meaning specifically in recent, flattened-device tree practice (which is the context in which the use stock ticker recommendation has been made. It doesn't matter a lot, lowercase names are perfectly valid, you just don't get the nice non-collision reassurance you would get if you used a name in one of the namespaces reserved for that purpose. It's probably best to not use an uppercase stock symbol if you don't have approval from the company in question anyway -- we use a lowercase name (i.e. in the free-for-all space) for our messed up bindings, the companies use an uppercase name (in the stock-ticker namespace) for their own, incompatible, messed-up bindings, and everyone is happy. Or something like that. Ack, now I am confused. Should I use lower or upper case? To be honest the upper case looks weird since none of the other names have any uppercase characters. Cheers, Sean ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] [POWERPC] Remove CONFIG_PCI_LEGACY from pasemi_defconfig
On Wed, 26 Mar 2008 22:41:03 -0500 Olof Johansson [EMAIL PROTECTED] wrote: I've already requested Paul to pull a defconfig update that includes all changes besides the PCI_LEGACY disabling. Since it's not critical, I'll do the same change in the for-2.6.26 branch but let the pull request for 2.6.25 be as-is, if that's OK with you. This is of course with the hopes that Paul will pull and push it before the .25 release. Yeah, that's fine - I missed your pull request. I'll redo the patch based on your tree. -- Cheers, Stephen Rothwell[EMAIL PROTECTED] http://www.canb.auug.org.au/~sfr/ pgprimTSBOLnz.pgp Description: PGP signature ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: How to use MMC-over-SPI on MPC8313E
Hi, I am also trying to get MMC over SPI working on the 8313E dev board. Could I trouble you to send me whatever you have in the way of drivers, instructions or documentation. I am sorry to bother you, but I saw your message here: http://ozlabs.org/pipermail/linuxppc-dev/2007-September/042119.html and it looks like you guys may have already solved the problem that I am having. Thanks in advance, Bobby ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH] [POWERPC] htab_remove_mapping is only used by MEMORY_HOTPLUG
This eliminates a warning in builds that don't define
CONFIG_MEMORY_HOTPLUG.
Signed-off-by: Stephen Rothwell [EMAIL PROTECTED]
---
arch/powerpc/mm/hash_utils_64.c |2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/arch/powerpc/mm/hash_utils_64.c b/arch/powerpc/mm/hash_utils_64.c
index c2e5f61..96a5790 100644
--- a/arch/powerpc/mm/hash_utils_64.c
+++ b/arch/powerpc/mm/hash_utils_64.c
@@ -192,6 +192,7 @@ int htab_bolt_mapping(unsigned long vstart, unsigned long
vend,
return ret 0 ? ret : 0;
}
+#ifdef CONFIG_MEMORY_HOTPLUG
static void htab_remove_mapping(unsigned long vstart, unsigned long vend,
int psize, int ssize)
{
@@ -209,6 +210,7 @@ static void htab_remove_mapping(unsigned long vstart,
unsigned long vend,
for (vaddr = vstart; vaddr vend; vaddr += step)
ppc_md.hpte_removebolted(vaddr, psize, ssize);
}
+#endif /* CONFIG_MEMORY_HOTPLUG */
static int __init htab_dt_scan_seg_sizes(unsigned long node,
const char *uname, int depth,
--
1.5.4.4
--
Cheers,
Stephen Rothwell[EMAIL PROTECTED]
http://www.canb.auug.org.au/~sfr/
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH] [POWERPC] Remove CONFIG_PCI_LEGACY from some configs
This will remove some build warnings and doesn't stop us building any drivers that we were building previously with these configs. Signed-off-by: Stephen Rothwell [EMAIL PROTECTED] --- arch/powerpc/configs/chrp32_defconfig |7 +++ arch/powerpc/configs/g5_defconfig |7 +++ arch/powerpc/configs/iseries_defconfig |7 +++ arch/powerpc/configs/pmac32_defconfig |7 +++ arch/powerpc/configs/ppc64_defconfig |8 arch/powerpc/configs/pseries_defconfig |8 6 files changed, 20 insertions(+), 24 deletions(-) I have built all these configs. diff --git a/arch/powerpc/configs/chrp32_defconfig b/arch/powerpc/configs/chrp32_defconfig index 38b85b2..d7fd298 100644 --- a/arch/powerpc/configs/chrp32_defconfig +++ b/arch/powerpc/configs/chrp32_defconfig @@ -1,7 +1,7 @@ # # Automatically generated make config: don't edit # Linux kernel version: 2.6.25-rc6 -# Thu Mar 20 10:33:36 2008 +# Thu Mar 27 13:55:37 2008 # # CONFIG_PPC64 is not set @@ -74,8 +74,6 @@ CONFIG_IKCONFIG_PROC=y CONFIG_LOG_BUF_SHIFT=15 # CONFIG_CGROUPS is not set # CONFIG_GROUP_SCHED is not set -# CONFIG_USER_SCHED is not set -# CONFIG_CGROUP_SCHED is not set CONFIG_SYSFS_DEPRECATED=y CONFIG_SYSFS_DEPRECATED_V2=y # CONFIG_RELAY is not set @@ -243,7 +241,7 @@ CONFIG_PCI_SYSCALL=y # CONFIG_PCIEPORTBUS is not set CONFIG_ARCH_SUPPORTS_MSI=y # CONFIG_PCI_MSI is not set -CONFIG_PCI_LEGACY=y +# CONFIG_PCI_LEGACY is not set # CONFIG_PCI_DEBUG is not set # CONFIG_PCCARD is not set # CONFIG_HOTPLUG_PCI is not set @@ -1328,6 +1326,7 @@ CONFIG_PLIST=y CONFIG_HAS_IOMEM=y CONFIG_HAS_IOPORT=y CONFIG_HAS_DMA=y +CONFIG_HAVE_LMB=y # # Kernel hacking diff --git a/arch/powerpc/configs/g5_defconfig b/arch/powerpc/configs/g5_defconfig index 0f82f66..a20501f 100644 --- a/arch/powerpc/configs/g5_defconfig +++ b/arch/powerpc/configs/g5_defconfig @@ -1,7 +1,7 @@ # # Automatically generated make config: don't edit # Linux kernel version: 2.6.25-rc6 -# Thu Mar 20 10:36:41 2008 +# Thu Mar 27 13:55:43 2008 # CONFIG_PPC64=y @@ -77,8 +77,6 @@ CONFIG_IKCONFIG_PROC=y CONFIG_LOG_BUF_SHIFT=17 # CONFIG_CGROUPS is not set # CONFIG_GROUP_SCHED is not set -# CONFIG_USER_SCHED is not set -# CONFIG_CGROUP_SCHED is not set CONFIG_SYSFS_DEPRECATED=y CONFIG_SYSFS_DEPRECATED_V2=y # CONFIG_RELAY is not set @@ -276,7 +274,7 @@ CONFIG_PCI_SYSCALL=y # CONFIG_PCIEPORTBUS is not set CONFIG_ARCH_SUPPORTS_MSI=y CONFIG_PCI_MSI=y -CONFIG_PCI_LEGACY=y +# CONFIG_PCI_LEGACY is not set # CONFIG_PCI_DEBUG is not set # CONFIG_PCCARD is not set # CONFIG_HOTPLUG_PCI is not set @@ -1596,6 +1594,7 @@ CONFIG_PLIST=y CONFIG_HAS_IOMEM=y CONFIG_HAS_IOPORT=y CONFIG_HAS_DMA=y +CONFIG_HAVE_LMB=y # # Kernel hacking diff --git a/arch/powerpc/configs/iseries_defconfig b/arch/powerpc/configs/iseries_defconfig index 8d9a84f..b3128fb 100644 --- a/arch/powerpc/configs/iseries_defconfig +++ b/arch/powerpc/configs/iseries_defconfig @@ -1,7 +1,7 @@ # # Automatically generated make config: don't edit # Linux kernel version: 2.6.25-rc6 -# Thu Mar 20 10:43:46 2008 +# Thu Mar 27 13:55:45 2008 # CONFIG_PPC64=y @@ -77,8 +77,6 @@ CONFIG_IKCONFIG_PROC=y CONFIG_LOG_BUF_SHIFT=17 # CONFIG_CGROUPS is not set # CONFIG_GROUP_SCHED is not set -# CONFIG_USER_SCHED is not set -# CONFIG_CGROUP_SCHED is not set CONFIG_SYSFS_DEPRECATED=y CONFIG_SYSFS_DEPRECATED_V2=y # CONFIG_RELAY is not set @@ -261,7 +259,7 @@ CONFIG_PCI_SYSCALL=y # CONFIG_PCIEPORTBUS is not set CONFIG_ARCH_SUPPORTS_MSI=y # CONFIG_PCI_MSI is not set -CONFIG_PCI_LEGACY=y +# CONFIG_PCI_LEGACY is not set # CONFIG_PCI_DEBUG is not set # CONFIG_PCCARD is not set # CONFIG_HOTPLUG_PCI is not set @@ -1065,6 +1063,7 @@ CONFIG_PLIST=y CONFIG_HAS_IOMEM=y CONFIG_HAS_IOPORT=y CONFIG_HAS_DMA=y +CONFIG_HAVE_LMB=y # # Kernel hacking diff --git a/arch/powerpc/configs/pmac32_defconfig b/arch/powerpc/configs/pmac32_defconfig index 558b0d3..fca1142 100644 --- a/arch/powerpc/configs/pmac32_defconfig +++ b/arch/powerpc/configs/pmac32_defconfig @@ -1,7 +1,7 @@ # # Automatically generated make config: don't edit # Linux kernel version: 2.6.25-rc6 -# Thu Mar 20 11:05:14 2008 +# Thu Mar 27 13:56:21 2008 # # CONFIG_PPC64 is not set @@ -77,8 +77,6 @@ CONFIG_IKCONFIG_PROC=y CONFIG_LOG_BUF_SHIFT=14 # CONFIG_CGROUPS is not set # CONFIG_GROUP_SCHED is not set -# CONFIG_USER_SCHED is not set -# CONFIG_CGROUP_SCHED is not set CONFIG_SYSFS_DEPRECATED=y CONFIG_SYSFS_DEPRECATED_V2=y # CONFIG_RELAY is not set @@ -272,7 +270,7 @@ CONFIG_PCI_SYSCALL=y # CONFIG_PCIEPORTBUS is not set CONFIG_ARCH_SUPPORTS_MSI=y # CONFIG_PCI_MSI is not set -CONFIG_PCI_LEGACY=y +# CONFIG_PCI_LEGACY is not set # CONFIG_PCI_DEBUG is not set CONFIG_PCCARD=m # CONFIG_PCMCIA_DEBUG is not set @@ -1895,6 +1893,7 @@ CONFIG_PLIST=y CONFIG_HAS_IOMEM=y CONFIG_HAS_IOPORT=y CONFIG_HAS_DMA=y +CONFIG_HAVE_LMB=y # # Kernel hacking diff --git a/arch/powerpc/configs/ppc64_defconfig
