Re: 4xx support in arch/ppc is going away Real Soon Now
On Sun, 8 Jun 2008, Jon Loeliger wrote:
Grant Likely writes:
Oh, and we're going try to create the longest acked-by chain in
Linux history.
Cool :)
Paul.
So far, I think it looks like this, sorted:
Acked-by: Arnd Bergmann [EMAIL PROTECTED]
Acked-by: Becky Bruce [EMAIL PROTECTED]
Acked-by: Benjamin Herrenschmidt [EMAIL PROTECTED]
Acked-by: Grant Likely [EMAIL PROTECTED]
Acked-by: Jochen Friedrich [EMAIL PROTECTED]
Acked-by: Jon Loeliger [EMAIL PROTECTED]
Acked-by: Josh Boyer [EMAIL PROTECTED]
Acked-by: Kumar Gala [EMAIL PROTECTED]
Acked-by: Olof Johansson [EMAIL PROTECTED]
Acked-by: Peter Korsgaard [EMAIL PROTECTED]
Acked-by: Scott Wood [EMAIL PROTECTED]
Acked-by: Sean MacLennan [EMAIL PROTECTED]
Acked-by: Segher Boessenkool [EMAIL PROTECTED]
Acked-by: Stefan Roese [EMAIL PROTECTED]
Acked-by: Stephen Neuendorffer [EMAIL PROTECTED]
Acked-by: Wolfgang Denk [EMAIL PROTECTED]
I'm not sure, but I _think_ there are a few other PowerPC
developers out there still... :-)
As there's no CHRP LongTrail support (bummer, mine died 4 years ago) left in
arch/ppc/, I don't mind you killing the whole arch/ppc/ ;-)
Acked-by: Geert Uytterhoeven [EMAIL PROTECTED]
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- [EMAIL PROTECTED]
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say programmer or something like that.
-- Linus Torvalds
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: Comments on device tree for pcm030
On Monday 09 June 2008 01:28, Grant Likely wrote: On Sun, Jun 8, 2008 at 1:08 PM, Jon Smirl [EMAIL PROTECTED] wrote: Why not a compatible field in the top of the tree? Then you wouldn't need to list the boards in mpc5200_simple.c. compatible = phytec,pcm030,simple-mpc5200; Here's the problem; what does compatible really mean at the board level? Does it mean the board has 100% of the same capabilities? Does it mean that it uses the same chip? Does it mean that the chip is configured in a particular way? It is really hard to define what a compatible value means at the board level. The meaning of compatible at the device level is very well defined, but that meaning does not extend well to the board level. Therefore, it is best to be conservative here and require a specific list of supported boards in platform code. Besides, it is really a Linux specific thing that is trying to be described. In Linux, we've decided to support as many 5200 boards as possible using the same platform code, but that may not be true, or it may be a different set of boards, when a different OS is used. To attempt to encode those decisions is overreaching the intent of using the device tree. Device tree has an entry for AC97 on PSC1. I don't think the Phytec module or carrier board has AC97 hardware. Might be a bug NACK. The baseboard for the pcm030 CPU board has AC97 hardware connected to PSC1. And it plays audio... The RTC chip says pcf8563, phytec doc says it is a pcf8564. Sounds like a bug These devices are mostly the same. You can use the pcf8563 driver for the pcf8564. There should be an i2c entry for the eeprom but I don't know the part number for it. Yes, i2c devices should be described. Its a 24C32. I believe Wolfram has a newer OFtree for the pcm030 so I add him as CC. Regards, Juergen -- Dipl.-Ing. Juergen Beisert | http://www.pengutronix.de Pengutronix - Linux Solutions for Science and Industry Handelsregister: Amtsgericht Hildesheim, HRA 2686 Vertretung Sued/Muenchen, Germany Phone: +49-8766-939 228 | Fax: +49-5121-206917-9 ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH v3] [NAND] driver extension to support NAND on TQM85xx modules
This patch extends the FSL UPM NAND driver from Anton Vorontsov to
support hardware which does not have the R/B pin of the NAND chip
connected, like the TQM8548 module:
- The OF_GPIO dependency has been removed from the Kconfig option
because GPIO is not needed. The relevant gpio_* function are then
stubbed out in linux/gpio.h.
- It re-introduces the chip-delay property to define an appropriate
maximum delay time (tR) required for read operations. The binding
will be documented in a separate patch.
Note: this patch is based on a patch from Anton Vorontsov aöready
posted to this list:
http://ozlabs.org/pipermail/linuxppc-dev/2008-April/055587.html.
http://ozlabs.org/pipermail/linuxppc-dev/2008-May/057158.html
Signed-off-by: Wolfgang Grandegger [EMAIL PROTECTED]
---
drivers/mtd/nand/Kconfig |2 +-
drivers/mtd/nand/fsl_upm.c | 17 +
2 files changed, 14 insertions(+), 5 deletions(-)
Index: linux-2.6-galak/drivers/mtd/nand/Kconfig
===
--- linux-2.6-galak.orig/drivers/mtd/nand/Kconfig
+++ linux-2.6-galak/drivers/mtd/nand/Kconfig
@@ -380,7 +380,7 @@ config MTD_NAND_FSL_ELBC
config MTD_NAND_FSL_UPM
tristate Support for NAND on Freescale UPM
- depends on MTD_NAND OF_GPIO (PPC_83xx || PPC_85xx)
+ depends on MTD_NAND (PPC_83xx || PPC_85xx)
select FSL_LBC
help
Enables support for NAND Flash chips wired onto Freescale PowerPC
Index: linux-2.6-galak/drivers/mtd/nand/fsl_upm.c
===
--- linux-2.6-galak.orig/drivers/mtd/nand/fsl_upm.c
+++ linux-2.6-galak/drivers/mtd/nand/fsl_upm.c
@@ -13,6 +13,7 @@
#include linux/kernel.h
#include linux/module.h
+#include linux/delay.h
#include linux/mtd/nand.h
#include linux/mtd/nand_ecc.h
#include linux/mtd/partitions.h
@@ -36,6 +37,7 @@ struct fsl_upm_nand {
uint8_t upm_cmd_offset;
void __iomem *io_base;
int rnb_gpio;
+ int chip_delay;
};
#define to_fsl_upm_nand(mtd) container_of(mtd, struct fsl_upm_nand, mtd)
@@ -58,10 +60,11 @@ static void fun_wait_rnb(struct fsl_upm_
if (fun-rnb_gpio = 0) {
while (--cnt !fun_chip_ready(fun-mtd))
cpu_relax();
+ if (!cnt)
+ dev_err(fun-dev, tired waiting for RNB\n);
+ } else {
+ ndelay(100);
}
-
- if (!cnt)
- dev_err(fun-dev, tired waiting for RNB\n);
}
static void fun_cmd_ctrl(struct mtd_info *mtd, int cmd, unsigned int ctrl)
@@ -129,7 +132,7 @@ static int __devinit fun_chip_init(struc
fun-chip.IO_ADDR_R = fun-io_base;
fun-chip.IO_ADDR_W = fun-io_base;
fun-chip.cmd_ctrl = fun_cmd_ctrl;
- fun-chip.chip_delay = 50;
+ fun-chip.chip_delay = fun-chip_delay;
fun-chip.read_byte = fun_read_byte;
fun-chip.read_buf = fun_read_buf;
fun-chip.write_buf = fun_write_buf;
@@ -233,6 +236,12 @@ static int __devinit fun_probe(struct of
goto err2;
}
+ prop = of_get_property(ofdev-node, chip-delay, NULL);
+ if (prop)
+ fun-chip_delay = *prop;
+ else
+ fun-chip_delay = 50;
+
fun-io_base = devm_ioremap_nocache(ofdev-dev, io_res.start,
io_res.end - io_res.start + 1);
if (!fun-io_base) {
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH v2] [NAND] driver extension to support NAND on TQM85xx modules
David Woodhouse wrote: On Thu, 2008-06-05 at 10:50 +0200, Wolfgang Grandegger wrote: [NAND] driver extension to support NAND on TQM85xx modules This patch extends the FSL UPM NAND driver from Anton Vorontsov to support NAND on the TQM85xx modules. Unfortunately, the hardware does not support the R/B pins of the NAND chip and therefore the specified maximum delay time must used. It therefore re-introduces the chip-delay property. Note: this patch is based on various patches from Anton Vorontsov posted to this list: http://ozlabs.org/pipermail/linuxppc-dev/2008-April/055587.html. Do you also want me to apply that patch (on which this one depends)? It says 'Signed-off-by: not yet' ... You should probably comment on the removal of the OF_GPIO dependency. It looks fine, since the relevant functions all get stubbed out and will do the right thing, but it's worth a comment in the commit text. I just sent v3 of this patch with some better description. Thanks, Wolfgang. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
2.6.26-rc5-mm1: procfs whine
At boot, using http://userweb.kernel.org/~akpm/config-g5.txt on a mac g5: io scheduler cfq registered proc_dir_entry '00' already registered Call Trace: [c0017a0fbb70] [c00120fc] .show_stack+0x58/0x1dc (unreliable) [c0017a0fbc20] [c01415a8] .proc_register+0x218/0x260 [c0017a0fbcd0] [c01419d4] .proc_mkdir_mode+0x40/0x74 [c0017a0fbd50] [c01e6640] .pci_proc_attach_device+0x90/0x134 [c0017a0fbdf0] [c05e5250] .pci_proc_init+0x68/0xa0 [c0017a0fbe70] [c05c0cd4] .kernel_init+0x228/0x49c [c0017a0fbf90] [c0026e0c] .kernel_thread+0x4c/0x68 nvidiafb: Device ID: 10de0141 ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH v2] [NAND] driver extension to support NAND on TQM85xx modules
Segher Boessenkool wrote: I see. I think I should then also post the bindings (update of booting-without-of.txt) separately. Yes please. They are much easier to review that way (and they should be reviewed as a separate entity anyway). I just sent the patch [PATCH] booting-without-of: add more bindings for FSL UPM driver describing the binding separately. Wolfgang. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: Comments on device tree for pcm030
Hi,
On Sun, Jun 08, 2008 at 03:08:33PM -0400, Jon Smirl wrote:
Why not a compatible field in the top of the tree? Then you wouldn't
need to list the boards in mpc5200_simple.c.
compatible = phytec,pcm030,simple-mpc5200;
Device tree has an entry for AC97 on PSC1. I don't think the Phytec
module or carrier board has AC97 hardware.
The RTC chip says pcf8563, phytec doc says it is a pcf8564.
There should be an i2c entry for the eeprom but I don't know the part
number for it.
What about the flash on the local bus? Could we use something like
this, or the same without the partition data?
[EMAIL PROTECTED] {
compatible = fsl,lpb;
ranges = 0 ff00 0100;
[EMAIL PROTECTED] {
compatible = cfi-flash;
reg = 0100;
bank-width = 2;
The board comes with different flash sizes with different bank widths.
That's why I decided to no put the flash entries into the tree.
We used to detect the flash size/bankwidth using the bootcs config
register (which was previously set by U-Boot). We could change U-Boot to
adjust the device tree accordingly, but we haven't done this so far,
sorry.
#size-cells = 1;
#address-cells = 1;
[EMAIL PROTECTED] {
label = ubootl;
reg = 0004;
};
[EMAIL PROTECTED] {
label = kernel;
reg = 0004 001c;
};
[EMAIL PROTECTED] {
label = jffs2;
reg = 0020 00D0;
};
[EMAIL PROTECTED] {
label = uboot;
reg = 00f0 0004;
};
[EMAIL PROTECTED] {
label = oftree;
reg = 00f4 0004;
};
[EMAIL PROTECTED] {
label = space;
reg = 00f8 0008;
};
I think partitions shouldn't go into the default device tree, as people
may have different partitioning.
Sascha
--
Pengutronix e.K. - Linux Solutions for Science and Industry
---
Kontakt-Informationen finden Sie im Header dieser Mail oder
auf der Webseite - http://www.pengutronix.de/impressum/ -
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: Default flats for running dtc from kernel build
Hello, Kumar Gala írta: diff --git a/arch/powerpc/boot/Makefile b/arch/powerpc/boot/Makefile index c40fb82..52db85a 100644 --- a/arch/powerpc/boot/Makefile +++ b/arch/powerpc/boot/Makefile @@ -29,6 +29,8 @@ ifdef CONFIG_DEBUG_INFO BOOTCFLAGS += -g endif +DTS_FLAGS ?= -R4 -S 0x3000 + ifeq ($(call cc-option-yn, -fstack-protector),y) BOOTCFLAGS += -fno-stack-protector endif I have a 8610 standing next to my desk with U-Boot 1.3.0 (Mar 13 2008 - 10:14:26). It came with 2.6.23. I wanted to compile a kernel from the latest available kernel sources ( 2.6.26-RC5-git2 ). I compiled it using mpc8610_hpcd_defconfig. I also did a make mpc8610_hpcd.dtb to have a matching dtb file for the kernel. This is how far it gets: = boot 11032 bytes read 1708346 bytes read ## Booting image at 0100 ... Image Name: Linux-2.6.26-rc5-git2-czp7 Image Type: PowerPC Linux Kernel Image (gzip compressed) Data Size:1708282 Bytes = 1.6 MB Load Address: Entry Point: Verifying Checksum ... OK Uncompressing Kernel Image ... OK Booting using the fdt at 0xc0 Loading Device Tree to 007fb000, end 007fdb17 ... OK When I use the 2.6.26 kernel, but the original dtb file from the BSP, then I get two more lines on the serial console: [EMAIL PROTECTED] first_busno=0 last_busno=0 [EMAIL PROTECTED] first_busno=0 last_busno=0 So I suspected, that this might be something with the dtb file. This is when I ran into this thread. I tried all the different options for DTS_FLAGS to generate a working dtb file, but I got the same result, Loading Device Tree to 007fb000, end 007fdb17 ... OK was the last line on screen. Any additional ideas, how to create a working dtb file for the 8610 board for later kernels? Bye, CzP ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] booting-without-of: add more bindings for FSL UPM driver
+ - chip-delay : may specify a delay value in milliseconds. Delay for what? The binding should say. chip-delay is a bit too generic name as well, it could be more descriptive perhaps. Shouldn't this be a property of the NAND device anyway, not the NAND controller? Segher ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH] IB/ehca: Reject recv WRs if QP is in RESET state
Signed-off-by: Joachim Fenkes [EMAIL PROTECTED]
---
On Friday 06 June 2008 22:20, Dotan Barak wrote:
I checked the code in the ehca driver and noticed that
post RR to a QP is being accepted in any state (including the RESET state).
You're right, this is only consistent -- thanks for pointing it out!
Regards,
Joachim
drivers/infiniband/hw/ehca/ehca_reqs.c | 12 ++--
1 files changed, 10 insertions(+), 2 deletions(-)
diff --git a/drivers/infiniband/hw/ehca/ehca_reqs.c
b/drivers/infiniband/hw/ehca/ehca_reqs.c
index f093b00..ad197f4 100644
--- a/drivers/infiniband/hw/ehca/ehca_reqs.c
+++ b/drivers/infiniband/hw/ehca/ehca_reqs.c
@@ -544,8 +544,16 @@ int ehca_post_recv(struct ib_qp *qp,
struct ib_recv_wr *recv_wr,
struct ib_recv_wr **bad_recv_wr)
{
- return internal_post_recv(container_of(qp, struct ehca_qp, ib_qp),
- qp-device, recv_wr, bad_recv_wr);
+ struct ehca_qp *my_qp = container_of(qp, struct ehca_qp, ib_qp);
+
+ /* Reject WR if QP is in RESET state */
+ if (unlikely(my_qp-state == IB_QPS_RESET)) {
+ ehca_err(qp-device, Invalid QP state qp_state=%d qpn=%x,
+my_qp-state, qp-qp_num);
+ return -EINVAL;
+ }
+
+ return internal_post_recv(my_qp, qp-device, recv_wr, bad_recv_wr);
}
int ehca_post_srq_recv(struct ib_srq *srq,
--
1.5.5
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Changing from [POWERPC] to powerpc: in git headlines
Upon prodding from Andrew Morton, and after discussing it with a few people, I have decided to change the way we format the git headline (the first line of the commit text) for powerpc-related patches. Instead of starting the headline with [POWERPC] or [POWERPC]: subsystem, we're now going to use powerpc: or powerpc/subsystem:. This is in line with what many other subsystems are doing these days and it conforms with the principle that square brackets in patch subjects are used to delimit information which shouldn't go into the permanent record (e.g., [1/7] or [RESEND]). I'm making this change from now on for commits that are queued up for 2.6.27. For 2.6.26 I'm going to stick with the old convention. So if people are sending patches for 2.6.27, it would be helpful if you put powerpc: or powerpc/subsystem: at the start of the patch subject. People who are putting commits destined for 2.6.27 or later into a git tree for me to pull need to make sure they format the commits this way. (It's more important to get it right in the git tree case because I can edit patches but not git commits.) Paul. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[git pull] Please pull powerpc.git merge branch
Please pull from the 'merge' branch of git://git.kernel.org/pub/scm/linux/kernel/git/paulus/powerpc.git merge to get 4 more bug-fix commits, plus one from Stephen Rothwell that changes one place where we do sprintf(pci_name(dev), ... to use dev_set_name() instead, so that we don't end up with an error when a change that is in Greg KH's tree (changing pci_name(dev) to be const) hits your tree. Thanks, Paul. arch/powerpc/boot/Makefile |4 ++-- arch/powerpc/kernel/pci_64.c|2 +- arch/powerpc/kernel/signal_64.c |4 +++- arch/powerpc/mm/mem.c |3 +-- drivers/net/Kconfig |2 +- include/linux/memory_hotplug.h | 16 6 files changed, 16 insertions(+), 15 deletions(-) Adrian Bunk (1): [POWERPC] boot/Makefile CONFIG_ variable fixes Benjamin Herrenschmidt (1): [POWERPC] Fix incorrect enabling of VMX when building signal or user context Nathan Lynch (2): [POWERPC] Make walk_memory_resource available with MEMORY_HOTPLUG=n [POWERPC] ehea: Remove dependency on MEMORY_HOTPLUG Stephen Rothwell (1): [POWERPC] Use dev_set_name in pci_64.c ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
More commits added to powerpc.git powerpc-next and master branches
Here is the list of commits that have been added to the powerpc-next
and master branches of the powerpc.git repository since the last such
message from me. It includes the much-acked removal of arch/ppc and
include/asm-ppc, commits pulled from Josh Boyer's tree and Kumar
Gala's tree, plus various other things. Sharp-eyed readers will
notice that I have started using the powerpc: prefix as promised.
Paul.
Anton Vorontsov (2):
[POWERPC] fsl_msi: few (mostly cosmetic) fixes
powerpc/mpic: Fix ambiguous else statement
Benjamin Herrenschmidt (1):
powerpc: Free a PTE bit on ppc64 with 64K pages
Bryan O'Donoghue (1):
[POWERPC] 83xx: Add support for Analogue Micro ASP837E board
David Gibson (1):
[POWERPC] Convert remaining dts-v0 files to v1
Emil Medve (1):
powerpc: Add the PC speaker only when requested
Jason Jin (4):
[POWERPC] Update booting-without-of for Freescale PCIe MSI
[POWERPC] fsl: PCIe MSI support for 83xx/85xx/86xx processors.
[POWERPC] 86xx: Enable MSI support for MPC8610HPCD board
[POWERPC] 85xx: Enable MSI support for 85xxds board
Josh Boyer (2):
[POWERPC] 4xx: Fix PCI mem in rainier DTS
[POWERPC] 4xx: Fix compiler warning on DCR_NATIVE only builds
Kumar Gala (5):
[POWERPC] Cleanup mpic nodes in .dts
[POWERPC] 85xx: Add next-level-cache property
[POWERPC] Move to runtime allocated exception stacks
[POWERPC] Rework EXC_LEVEL_EXCEPTION_PROLOG code
[POWERPC] 40x/Book-E: Save/restore volatile exception registers
Michael Ellerman (4):
powerpc: Rework Axon MSI setup so we can avoid freeing the irq_host
powerpc: Rework ipic_init() so we can avoid freeing the irq_host
powerpc: Rework qe_ic_init() so we can avoid freeing the irq_host
powerpc: Fix irq_alloc_host() reference counting and callers
Paul Mackerras (2):
powerpc: Remove arch/ppc and include/asm-ppc
Remi Machet (5):
powerpc: DTS file for the C2K
powerpc: Boot code for the C2K
powerpc: C2K board driver
powerpc: Default configuration for C2K
powerpc: Add C2K to configuration
Rune Torgersen (1):
powerpc: Check that TASK_SIZE does not overlap KERNEL_START
Sean MacLennan (2):
[POWERPC] PIKA Warp: Update DTS to support Rev B boards
[POWERPC] PIKA Warp: Update platform code to support Rev B boards
Stephen Neuendorffer (1):
[POWERPC] Refactor DCR code
Stephen Rothwell (2):
of_serial: Use linux/of_platform.h instead of asm
platinumfb: Use linux/of_{device,platform}.h instead of asm
Timur Tabi (3):
[POWERPC] fsl: Add warning for unrecognized I2C nodes in the device tree
[POWERPC] fsl: Add CS4270 i2c data to fsl_soc.c
[POWERPC] fsl: Update fsl_soc to use cell-index property of I2C nodes
Trent Piepho (1):
powerpc: Improve (in|out)_[bl]eXX() asm code
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH 1/4] arch/powerpc: add missing of_node_put
From: Julia Lawall [EMAIL PROTECTED]
of_node_put is needed before discarding a value received from
of_find_node_by_type, eg in error handling code.
The semantic patch that makes the change is as follows:
(http://www.emn.fr/x-info/coccinelle/)
// smpl
@@
struct device_node *n;
struct device_node *n1;
struct device_node *n2;
statement S;
identifier f1,f2;
expression E1,E2;
constant C;
@@
n = of_find_node_by_type(...)
...
if (!n) S
... when != of_node_put(n)
when != n1 = f1(n,...)
when != E1 = n
when any
when strict
(
+ of_node_put(n);
return -C;
|
of_node_put(n);
|
n2 = f2(n,...)
|
E2 = n
|
return ...;
)
// /smpl
Signed-off-by: Julia Lawall [EMAIL PROTECTED]
---
diff -u -p a/arch/powerpc/platforms/pseries/nvram.c
b/arch/powerpc/platforms/pseries/nvram.c
--- a/arch/powerpc/platforms/pseries/nvram.c
+++ b/arch/powerpc/platforms/pseries/nvram.c
@@ -131,8 +131,10 @@ int __init pSeries_nvram_init(void)
return -ENODEV;
nbytes_p = of_get_property(nvram, #bytes, proplen);
- if (nbytes_p == NULL || proplen != sizeof(unsigned int))
+ if (nbytes_p == NULL || proplen != sizeof(unsigned int)) {
+ of_node_put(nvram);
return -EIO;
+ }
nvram_size = *nbytes_p;
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH 2/4] drivers/macintosh/smu.c: add missing of_node_put
From: Julia Lawall [EMAIL PROTECTED]
of_node_put is needed before discarding a value received from
of_find_node_by_type, eg in error handling code.
The semantic patch that makes the change is as follows:
(http://www.emn.fr/x-info/coccinelle/)
// smpl
@@
struct device_node *n;
struct device_node *n1;
struct device_node *n2;
statement S;
identifier f1,f2;
expression E1,E2;
constant C;
@@
n = of_find_node_by_type(...)
...
if (!n) S
... when != of_node_put(n)
when != n1 = f1(n,...)
when != E1 = n
when any
when strict
(
+ of_node_put(n);
return -C;
|
of_node_put(n);
|
n2 = f2(n,...)
|
E2 = n
|
return ...;
)
// /smpl
Signed-off-by: Julia Lawall [EMAIL PROTECTED]
---
diff -u -p a/drivers/macintosh/smu.c b/drivers/macintosh/smu.c
--- a/drivers/macintosh/smu.c
+++ b/drivers/macintosh/smu.c
@@ -483,12 +483,15 @@ int __init smu_init (void)
if (smu_cmdbuf_abs == 0) {
printk(KERN_ERR SMU: Command buffer not allocated !\n);
+ of_node_put(np);
return -EINVAL;
}
smu = alloc_bootmem(sizeof(struct smu_device));
- if (smu == NULL)
+ if (smu == NULL) {
+ of_node_put(np);
return -ENOMEM;
+ }
memset(smu, 0, sizeof(*smu));
spin_lock_init(smu-lock);
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH 4/4] drivers/macintosh/therm_adt746x.c: add missing of_node_put
From: Julia Lawall [EMAIL PROTECTED]
of_node_put is needed before discarding a value received from
of_find_node_by_name, eg in error handling code.
The semantic patch that makes the change is as follows:
(http://www.emn.fr/x-info/coccinelle/)
// smpl
@@
struct device_node *n;
struct device_node *n1;
statement S;
identifier f;
expression E;
constant C;
@@
n = of_find_node_by_name(...)
...
if (!n) S
... when != of_node_put(n)
when != n1 = f(n,...)
when != E = n
when any
when strict
(
+ of_node_put(n);
return -C;
|
of_node_put(n);
|
n1 = f(n,...)
|
E = n
|
return ...;
)
// /smpl
Signed-off-by: Julia Lawall [EMAIL PROTECTED]
---
diff -u -p a/drivers/macintosh/therm_adt746x.c
b/drivers/macintosh/therm_adt746x.c
--- a/drivers/macintosh/therm_adt746x.c
+++ b/drivers/macintosh/therm_adt746x.c
@@ -562,18 +562,24 @@ thermostat_init(void)
therm_type = ADT7460;
else if (of_device_is_compatible(np, adt7467))
therm_type = ADT7467;
- else
+ else {
+ of_node_put(np);
return -ENODEV;
+ }
prop = of_get_property(np, hwsensor-params-version, NULL);
printk(KERN_INFO adt746x: version %d (%ssupported)\n, *prop,
(*prop == 1)?:un);
- if (*prop != 1)
+ if (*prop != 1) {
+ of_node_put(np);
return -ENODEV;
+ }
prop = of_get_property(np, reg, NULL);
- if (!prop)
+ if (!prop) {
+ of_node_put(np);
return -ENODEV;
+ }
/* look for bus either by path or using reg */
if (strstr(np-full_name, /i2c-bus@) != NULL) {
@@ -610,5 +616,6 @@ thermostat_init(void)
if (of_dev == NULL) {
printk(KERN_ERR Can't register temperatures device !\n);
+ of_node_put(np);
return -ENODEV;
}
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: Comments on device tree for pcm030
On 6/9/08, Juergen Beisert [EMAIL PROTECTED] wrote: Device tree has an entry for AC97 on PSC1. I don't think the Phytec module or carrier board has AC97 hardware. Might be a bug NACK. The baseboard for the pcm030 CPU board has AC97 hardware connected to PSC1. And it plays audio... I'm staring at a baseboard for the pcm030 in my hand, I don't see any AC97 hardware. It has two serial, two CAN, ethernet and power. Where's the AC97? http://www.phytec.com/products/rdk/PowerPC/phyCORE-MPC5200B-tinyRDK.html -- Jon Smirl [EMAIL PROTECTED] ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: Comments on device tree for pcm030
On 6/9/08, Juergen Beisert [EMAIL PROTECTED] wrote: On Monday 09 June 2008 01:28, Grant Likely wrote: On Sun, Jun 8, 2008 at 1:08 PM, Jon Smirl [EMAIL PROTECTED] wrote: Why not a compatible field in the top of the tree? Then you wouldn't need to list the boards in mpc5200_simple.c. compatible = phytec,pcm030,simple-mpc5200; Here's the problem; what does compatible really mean at the board level? Does it mean the board has 100% of the same capabilities? Does it mean that it uses the same chip? Does it mean that the chip is configured in a particular way? It is really hard to define what a compatible value means at the board level. The meaning of compatible at the device level is very well defined, but that meaning does not extend well to the board level. Therefore, it is best to be conservative here and require a specific list of supported boards in platform code. Besides, it is really a Linux specific thing that is trying to be described. In Linux, we've decided to support as many 5200 boards as possible using the same platform code, but that may not be true, or it may be a different set of boards, when a different OS is used. To attempt to encode those decisions is overreaching the intent of using the device tree. Device tree has an entry for AC97 on PSC1. I don't think the Phytec module or carrier board has AC97 hardware. Might be a bug NACK. The baseboard for the pcm030 CPU board has AC97 hardware connected to PSC1. And it plays audio... The RTC chip says pcf8563, phytec doc says it is a pcf8564. Sounds like a bug These devices are mostly the same. You can use the pcf8563 driver for the pcf8564. Let's put the right chip number in the tree. While these have the same drivers on Linux they may not on other OSes. There should be an i2c entry for the eeprom but I don't know the part number for it. Yes, i2c devices should be described. Its a 24C32. I believe Wolfram has a newer OFtree for the pcm030 so I add him as CC. Regards, Juergen -- Dipl.-Ing. Juergen Beisert | http://www.pengutronix.de Pengutronix - Linux Solutions for Science and Industry Handelsregister: Amtsgericht Hildesheim, HRA 2686 Vertretung Sued/Muenchen, Germany Phone: +49-8766-939 228 | Fax: +49-5121-206917-9 -- Jon Smirl [EMAIL PROTECTED] ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: zImage.chrp is getting gziped on Efika
Something that went into 2.6.26 has broken the image build for the Efika. Matt has confirm it too. -- Jon Smirl [EMAIL PROTECTED] ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 1/4] arch/powerpc: add missing of_node_put
On Mon, 9 Jun 2008 14:20:04 +0200 (CEST) Julia Lawall [EMAIL PROTECTED] wrote: From: Julia Lawall [EMAIL PROTECTED] of_node_put is needed before discarding a value received from of_find_node_by_type, eg in error handling code. The semantic patch that makes the change is as follows: (http://www.emn.fr/x-info/coccinelle/) // smpl @@ struct device_node *n; struct device_node *n1; struct device_node *n2; statement S; identifier f1,f2; expression E1,E2; constant C; @@ n = of_find_node_by_type(...) ... if (!n) S ... when != of_node_put(n) when != n1 = f1(n,...) when != E1 = n when any when strict ( + of_node_put(n); return -C; | of_node_put(n); | n2 = f2(n,...) | E2 = n | return ...; ) // /smpl Signed-off-by: Julia Lawall [EMAIL PROTECTED] Acked-by: Stephen Rothwell [EMAIL PROTECTED] -- Cheers, Stephen Rothwell[EMAIL PROTECTED] http://www.canb.auug.org.au/~sfr/ pgpaPvHX4uNSO.pgp Description: PGP signature ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: Comments on device tree for pcm030
Jon, On Monday 09 June 2008 14:37, Jon Smirl wrote: On 6/9/08, Juergen Beisert [EMAIL PROTECTED] wrote: Device tree has an entry for AC97 on PSC1. I don't think the Phytec module or carrier board has AC97 hardware. Might be a bug NACK. The baseboard for the pcm030 CPU board has AC97 hardware connected to PSC1. And it plays audio... I'm staring at a baseboard for the pcm030 in my hand, I don't see any AC97 hardware. It has two serial, two CAN, ethernet and power. Where's the AC97? It seems you have an old development hardware. Here I have the PCM-030-02REI (=CPU card) and PCM-973-tiny (=baseboard). The PCM-973-tiny comes with a Wolfson AC97 sound device. This is the current combination everyone can buy. http://www.phytec.com/products/rdk/PowerPC/phyCORE-MPC5200B-tinyRDK.html Yes. This kit contains the PCM-973-tiny with AC97 sound. Regards, Juergen -- Dipl.-Ing. Juergen Beisert | http://www.pengutronix.de Pengutronix - Linux Solutions for Science and Industry Handelsregister: Amtsgericht Hildesheim, HRA 2686 Vertretung Sued/Muenchen, Germany Phone: +49-8766-939 228 | Fax: +49-5121-206917-9 ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 2/4] drivers/macintosh/smu.c: add missing of_node_put
On Mon, 9 Jun 2008 14:20:42 +0200 (CEST) Julia Lawall [EMAIL PROTECTED] wrote: From: Julia Lawall [EMAIL PROTECTED] of_node_put is needed before discarding a value received from of_find_node_by_type, eg in error handling code. The semantic patch that makes the change is as follows: (http://www.emn.fr/x-info/coccinelle/) // smpl @@ struct device_node *n; struct device_node *n1; struct device_node *n2; statement S; identifier f1,f2; expression E1,E2; constant C; @@ n = of_find_node_by_type(...) ... if (!n) S ... when != of_node_put(n) when != n1 = f1(n,...) when != E1 = n when any when strict ( + of_node_put(n); return -C; | of_node_put(n); | n2 = f2(n,...) | E2 = n | return ...; ) // /smpl Signed-off-by: Julia Lawall [EMAIL PROTECTED] Acked-by: Stephen Rothwell [EMAIL PROTECTED] However, the error handling in that routine (smu_init) needs much more work. -- Cheers, Stephen Rothwell[EMAIL PROTECTED] http://www.canb.auug.org.au/~sfr/ pgp0wnP6Fbm2h.pgp Description: PGP signature ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 4/4] drivers/macintosh/therm_adt746x.c: add missing of_node_put
On Mon, 9 Jun 2008 14:21:51 +0200 (CEST) Julia Lawall [EMAIL PROTECTED] wrote: From: Julia Lawall [EMAIL PROTECTED] of_node_put is needed before discarding a value received from of_find_node_by_name, eg in error handling code. The semantic patch that makes the change is as follows: (http://www.emn.fr/x-info/coccinelle/) // smpl @@ struct device_node *n; struct device_node *n1; statement S; identifier f; expression E; constant C; @@ n = of_find_node_by_name(...) ... if (!n) S ... when != of_node_put(n) when != n1 = f(n,...) when != E = n when any when strict ( + of_node_put(n); return -C; | of_node_put(n); | n1 = f(n,...) | E = n | return ...; ) // /smpl Signed-off-by: Julia Lawall [EMAIL PROTECTED] Acked-by: Stephen Rothwell [EMAIL PROTECTED] -- Cheers, Stephen Rothwell[EMAIL PROTECTED] http://www.canb.auug.org.au/~sfr/ pgpsYaWE3r82Q.pgp Description: PGP signature ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 2/4] drivers/macintosh/smu.c: add missing of_node_put
However, the error handling in that routine (smu_init) needs much more work. Indeed, the smu = NULL at the end of the function seems a bit brutal - a lot of allocated data ends up not getting freed. I can try to do something about it. Did you see something else? julia ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 2/4] drivers/macintosh/smu.c: add missing of_node_put
Hi Julia, On Mon, 9 Jun 2008 15:22:53 +0200 (CEST) Julia Lawall [EMAIL PROTECTED] wrote: However, the error handling in that routine (smu_init) needs much more work. Indeed, the smu = NULL at the end of the function seems a bit brutal - a lot of allocated data ends up not getting freed. I can try to do something about it. Did you see something else? There are paths to fail: where you would need to of_node_put smu-db_node or smu-msg_node (or both) and undo the smu-db_buf ioremap. -- Cheers, Stephen Rothwell[EMAIL PROTECTED] http://www.canb.auug.org.au/~sfr/ pgpGXFgUzRbpi.pgp Description: PGP signature ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: Comments on device tree for pcm030
On Mon, Jun 9, 2008 at 1:56 AM, Juergen Beisert [EMAIL PROTECTED] wrote: On Monday 09 June 2008 01:28, Grant Likely wrote: On Sun, Jun 8, 2008 at 1:08 PM, Jon Smirl [EMAIL PROTECTED] wrote: Device tree has an entry for AC97 on PSC1. I don't think the Phytec module or carrier board has AC97 hardware. Might be a bug NACK. The baseboard for the pcm030 CPU board has AC97 hardware connected to PSC1. And it plays audio... Okay, I didn't know. The RTC chip says pcf8563, phytec doc says it is a pcf8564. Sounds like a bug These devices are mostly the same. You can use the pcf8563 driver for the pcf8564. Then compatible should be something 'compatible = nxp,pcf8564, nxp,pcf8563;' 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
RE: [RFC] Kprobes for book-e
Kumar Gala wrote on Tuesday, June 03, 2008 9:16 PM To: Sulibhavi, Madhvesh Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED]; linuxppc-dev@ozlabs.org; Paul Mackerras Subject: Re: [RFC] Kprobes for book-e ..snip I think the block code under CONFIG_BOOKE may not be required now if exception cleanup fixes address the stack problem which i had explained in my port. I have to look into exception fix patches and confirm about these changes. Can you please provide me the thread where exception cleanup is posted as i haven't tracked the list from long time. http://ozlabs.org/pipermail/linuxppc-dev/2008-May/056457.html What was the original thinking about why you had to enable MSR_EE and MSR_CE? I found that this code is redundant and it was added while debugging the flags status during my port. This is a bug since it modifies the MSR status and enables the critical and external bits which is not supposed to. The interrupts status should be kept back to original state without enabling interrupt bits after executing the post_handler. So this change is not valid and it can be taken out. The code within the prepare_single_step() is already doing the job of disabling interrupts and setting bits required for single step and hence no additional changes are required for Book-e version of kprobes. I confirmed the above changes in my local tree and found no issues for kprobes, jprobes and kretprobes. But this testing is done using 2.6.22.y+ppc arch. Once after fixing the binutils-2.17 issue i am facing for latest kernel, i will retest and inform if any problems to new patches. -madhvesh --- This email is confidential and intended only for the use of the individual or entity named above and may contain information that is privileged. If you are not the intended recipient, you are notified that any dissemination, distribution or copying of this email is strictly prohibited. If you have received this email in error, please notify us immediately by return email or telephone and destroy the original message. - This mail is sent via Sony Asia Pacific Mail Gateway. --- ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Please pull from 'for-2.6.26' branch
Please pull from 'for-2.6.26' branch of master.kernel.org:/pub/scm/linux/kernel/git/galak/powerpc.git for-2.6.26 to receive the following updates: arch/powerpc/boot/dts/mpc8548cds.dts |4 arch/powerpc/configs/83xx/mpc8313_rdb_defconfig | 155 +++--- arch/powerpc/configs/83xx/mpc8315_rdb_defconfig | 162 +++ arch/powerpc/configs/83xx/mpc832x_mds_defconfig | 146 ++ arch/powerpc/configs/83xx/mpc832x_rdb_defconfig | 150 ++ arch/powerpc/configs/83xx/mpc834x_itx_defconfig | 157 +++--- arch/powerpc/configs/83xx/mpc834x_itxgp_defconfig | 150 ++ arch/powerpc/configs/83xx/mpc834x_mds_defconfig | 146 ++ arch/powerpc/configs/83xx/mpc836x_mds_defconfig | 146 ++ arch/powerpc/configs/83xx/mpc837x_mds_defconfig | 146 ++ arch/powerpc/configs/83xx/mpc837x_rdb_defconfig | 222 +++ arch/powerpc/configs/83xx/sbc834x_defconfig | 140 ++--- arch/powerpc/configs/85xx/ksi8560_defconfig | 168 +++ arch/powerpc/configs/85xx/mpc8540_ads_defconfig | 133 ++--- arch/powerpc/configs/85xx/mpc8544_ds_defconfig| 210 +- arch/powerpc/configs/85xx/mpc8560_ads_defconfig | 135 ++--- arch/powerpc/configs/85xx/mpc8568mds_defconfig| 150 ++ arch/powerpc/configs/85xx/mpc8572_ds_defconfig| 210 +- arch/powerpc/configs/85xx/mpc85xx_cds_defconfig | 137 ++--- arch/powerpc/configs/85xx/sbc8548_defconfig | 131 ++--- arch/powerpc/configs/85xx/sbc8560_defconfig | 135 ++--- arch/powerpc/configs/85xx/stx_gp3_defconfig | 152 ++ arch/powerpc/configs/85xx/tqm8540_defconfig | 147 ++ arch/powerpc/configs/85xx/tqm8541_defconfig | 146 ++ arch/powerpc/configs/85xx/tqm8555_defconfig | 146 ++ arch/powerpc/configs/85xx/tqm8560_defconfig | 146 ++ arch/powerpc/configs/adder875_defconfig | 52 ++- arch/powerpc/configs/ep8248e_defconfig| 124 +--- arch/powerpc/configs/ep88xc_defconfig | 47 ++- arch/powerpc/configs/linkstation_defconfig| 172 +++ arch/powerpc/configs/mpc7448_hpc2_defconfig | 136 ++--- arch/powerpc/configs/mpc8272_ads_defconfig| 126 +--- arch/powerpc/configs/mpc83xx_defconfig| 151 ++ arch/powerpc/configs/mpc85xx_defconfig| 210 +- arch/powerpc/configs/mpc8610_hpcd_defconfig | 316 -- arch/powerpc/configs/mpc8641_hpcn_defconfig | 210 +- arch/powerpc/configs/mpc866_ads_defconfig | 128 +--- arch/powerpc/configs/mpc885_ads_defconfig | 47 ++- arch/powerpc/configs/pq2fads_defconfig| 133 ++--- arch/powerpc/configs/prpmc2800_defconfig | 153 ++ arch/powerpc/configs/sbc8641d_defconfig | 150 ++ arch/powerpc/configs/storcenter_defconfig | 71 ++-- arch/powerpc/platforms/85xx/Kconfig |1 43 files changed, 3960 insertions(+), 2137 deletions(-) Kumar Gala (3): [POWERPC] 85xx: MPC85xx MDS - Unconditionally select PHYLIB for board fixups [POWERPC] 85xx: MPC8548CDS - Fix size of PCIe IO space [POWERPC] Updated Freescale PPC defconfigs Timur Tabi (1): [POWERPC] 8610: Update defconfig for MPC8610 HPCD r ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH][2.6.26] ehea: set mac address fix
eHEA has to call firmware functions in order to change the mac address
of a logical port. This patch checks if the logical port is up
when calling the register / deregister mac address calls. If the port
is down these firmware calls would fail and are therefore not executed.
Signed-off-by: Jan-Bernd Themann [EMAIL PROTECTED]
---
diff -Nurp -X dontdiff linux-2.6.26-rc4/drivers/net/ehea/ehea_main.c
patched_kernel/drivers/net/ehea/ehea_main.c
--- linux-2.6.26-rc4/drivers/net/ehea/ehea_main.c 2008-05-26
20:08:11.0 +0200
+++ patched_kernel/drivers/net/ehea/ehea_main.c 2008-06-09 15:42:17.0
+0200
@@ -1766,16 +1766,20 @@ static int ehea_set_mac_addr(struct net_
mutex_lock(ehea_bcmc_regs.lock);
/* Deregister old MAC in pHYP */
- ret = ehea_broadcast_reg_helper(port, H_DEREG_BCMC);
- if (ret)
- goto out_upregs;
+ if (port-state == EHEA_PORT_UP) {
+ ret = ehea_broadcast_reg_helper(port, H_DEREG_BCMC);
+ if (ret)
+ goto out_upregs;
+ }
port-mac_addr = cb0-port_mac_addr 16;
/* Register new MAC in pHYP */
- ret = ehea_broadcast_reg_helper(port, H_REG_BCMC);
- if (ret)
- goto out_upregs;
+ if (port-state == EHEA_PORT_UP) {
+ ret = ehea_broadcast_reg_helper(port, H_REG_BCMC);
+ if (ret)
+ goto out_upregs;
+ }
ret = 0;
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Is there any significant difference of memory management between PPC 405 and 440?
Hi, all:
It may be a silly question.
There is a 405 and a 440 board. We create a kernel module which will
allocate 3MB memory every time it is loaded. It runs basically well in
440 board, which owns 256MB memory. However, in 405 board, which only
has 32MB memory, loading the module always results in Data machine
check in kernel mode:
Data machine check in kernel mode.
PLB0: BEAR= 0x03016004 ACR= 0x BESR= 0x00c0
PLB0 to OPB: BEAR= 0x0400 BESR0= 0x BESR1= 0x
Oops: machine check, sig: 7 [#1]
NIP: 2D10 LR: 10A8 CTR: C3170160
REGS: c0282f50 TRAP: 0202 Not tainted (2.6.19.2)
MSR: 00021000 ME CR: 2488 XER:
TASK = c3016000[0] '' THREAD: c0264000
GPR00: 0800 C08ABCB0 C3016000 C08ABCC0 C3177250 C3016000 C3018000
GPR08: C3018000 00021032 008ABCB0 030161B0 10019DA8
GPR16: 10102260 1009DF98 100F 100F7998 C317 0002 0028
C317
GPR24: 0001 C317 C317 0001 0001
NIP [2D10] 0x2d10
LR [10A8] 0x10a8
Call Trace:
Instruction dump:
Kernel panic - not syncing: Attempted to kill the idle task!
0Rebooting in 180 seconds..NULL
We have checked that once the 405 board boots successfully, there is
only about 5MB free memory. So we have tried to change the memory
allocated size in the module to smaller than 3MB, e.g. 1KB, 3KB, 1.5MB
etc., but got the same results.
Here we run the same codes in these two boards but get totally
different results, therefore, we wonder what the exact cause of Data
machine check in kernel mode. We think it relates to memory management,
but is there any other potential reasons?
If there is significant difference of memory management between 405
and 440, would anyone like to tell us something about it? And what
should we pay attention to in our implementation for these two boards?
Thank you very much!
Best Regards
Evangelion
June 9th, 2008
__
¸Ï¿ì×¢²áÑÅ»¢³¬´óÈÝÁ¿Ãâ·ÑÓÊÏä?
http://cn.mail.yahoo.com
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] booting-without-of: add more bindings for FSL UPM driver
Segher Boessenkool wrote:
+ - chip-delay : may specify a delay value in milliseconds.
Delay for what? The binding should say. chip-delay is a bit
too generic name as well, it could be more descriptive perhaps.
The chip-delay property defines an appropriate maximum delay
time (tR) required for read operations if the R/B pin is not
connected. It's used as shown below:
+ /* Note: NAND support needs to be enabled in U-Boot */
+ [EMAIL PROTECTED],0 {
+ #address-cells = 0;
+ #size-cells = 0;
+ compatible = fsl,upm-nand;
+ reg = 3 0x0 0x800;
+ fsl,upm-addr-offset = 0x10;
+ fsl,upm-cmd-offset = 0x08;
+ chip-delay = 25; // in micro-seconds
+
+ [EMAIL PROTECTED] {
+ #address-cells = 1;
+ #size-cells = 1;
+
+ [EMAIL PROTECTED] {
+ label = fs;
+ reg = 0x 0x0100;
+ };
+ };
+ };
+ };
+
Shouldn't this be a property of the NAND device anyway, not the
NAND controller?
Strictly speaking, it's a property of the NAND device. Therefore it
should be inside the node [EMAIL PROTECTED], I thhink:
+ [EMAIL PROTECTED] {
+ #address-cells = 1;
+ #size-cells = 1;
+ chip-delay = 25; // in micro-seconds
+
+ [EMAIL PROTECTED] {
+ label = fs;
+ reg = 0x 0x0100;
+ };
+ };
Where should that be documented?
Wolfgang.
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH 0/2] Prevent loss of interrupts in IB/ehca
This patchset contains two changes for IB/ehca and ibmebus. The first patch enables ibmebus_request_irq() to optionally return the IRQ number, which is used by the second patch to trigger EOI in case of lost interrupts. They should apply cleanly against 2.6.26 git tree. Thanks Stefan ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH 1/2] ibmebus: Change ibmebus_request_irq() to optionally return irq number
Signed-off-by: Stefan Roscher [EMAIL PROTECTED]
---
arch/powerpc/kernel/ibmebus.c|5 -
drivers/infiniband/hw/ehca/ehca_eq.c |4 ++--
drivers/net/ehea/ehea_main.c |6 +++---
include/asm-powerpc/ibmebus.h|2 +-
4 files changed, 10 insertions(+), 7 deletions(-)
diff --git a/arch/powerpc/kernel/ibmebus.c b/arch/powerpc/kernel/ibmebus.c
index 9971159..a002fdf 100644
--- a/arch/powerpc/kernel/ibmebus.c
+++ b/arch/powerpc/kernel/ibmebus.c
@@ -208,7 +208,7 @@ void ibmebus_unregister_driver(struct of_platform_driver
*drv)
}
EXPORT_SYMBOL(ibmebus_unregister_driver);
-int ibmebus_request_irq(u32 ist, irq_handler_t handler,
+int ibmebus_request_irq(u32 ist, int *irq_number, irq_handler_t handler,
unsigned long irq_flags, const char *devname,
void *dev_id)
{
@@ -217,6 +217,9 @@ int ibmebus_request_irq(u32 ist, irq_handler_t handler,
if (irq == NO_IRQ)
return -EINVAL;
+ if (irq_number)
+ *irq_number = irq;
+
return request_irq(irq, handler, irq_flags, devname, dev_id);
}
EXPORT_SYMBOL(ibmebus_request_irq);
diff --git a/drivers/infiniband/hw/ehca/ehca_eq.c
b/drivers/infiniband/hw/ehca/ehca_eq.c
index 49660df..5bc494f 100644
--- a/drivers/infiniband/hw/ehca/ehca_eq.c
+++ b/drivers/infiniband/hw/ehca/ehca_eq.c
@@ -122,7 +122,7 @@ int ehca_create_eq(struct ehca_shca *shca,
/* register interrupt handlers and initialize work queues */
if (type == EHCA_EQ) {
- ret = ibmebus_request_irq(eq-ist, ehca_interrupt_eq,
+ ret = ibmebus_request_irq(eq-ist, NULL, ehca_interrupt_eq,
IRQF_DISABLED, ehca_eq,
(void *)shca);
if (ret 0)
@@ -130,7 +130,7 @@ int ehca_create_eq(struct ehca_shca *shca,
tasklet_init(eq-interrupt_task, ehca_tasklet_eq, (long)shca);
} else if (type == EHCA_NEQ) {
- ret = ibmebus_request_irq(eq-ist, ehca_interrupt_neq,
+ ret = ibmebus_request_irq(eq-ist, NULL, ehca_interrupt_neq,
IRQF_DISABLED, ehca_neq,
(void *)shca);
if (ret 0)
diff --git a/drivers/net/ehea/ehea_main.c b/drivers/net/ehea/ehea_main.c
index 287a619..102ffeb 100644
--- a/drivers/net/ehea/ehea_main.c
+++ b/drivers/net/ehea/ehea_main.c
@@ -1216,7 +1216,7 @@ static int ehea_reg_interrupts(struct net_device *dev)
snprintf(port-int_aff_name, EHEA_IRQ_NAME_SIZE - 1, %s-aff,
dev-name);
- ret = ibmebus_request_irq(port-qp_eq-attr.ist1,
+ ret = ibmebus_request_irq(port-qp_eq-attr.ist1, NULL,
ehea_qp_aff_irq_handler,
IRQF_DISABLED, port-int_aff_name, port);
if (ret) {
@@ -1234,7 +1234,7 @@ static int ehea_reg_interrupts(struct net_device *dev)
pr = port-port_res[i];
snprintf(pr-int_send_name, EHEA_IRQ_NAME_SIZE - 1,
%s-queue%d, dev-name, i);
- ret = ibmebus_request_irq(pr-eq-attr.ist1,
+ ret = ibmebus_request_irq(pr-eq-attr.ist1, NULL,
ehea_recv_irq_handler,
IRQF_DISABLED, pr-int_send_name,
pr);
@@ -3414,7 +3414,7 @@ static int __devinit ehea_probe_adapter(struct of_device
*dev,
tasklet_init(adapter-neq_tasklet, ehea_neq_tasklet,
(unsigned long)adapter);
- ret = ibmebus_request_irq(adapter-neq-attr.ist1,
+ ret = ibmebus_request_irq(adapter-neq-attr.ist1, NULL,
ehea_interrupt_neq, IRQF_DISABLED,
ehea_neq, adapter);
if (ret) {
diff --git a/include/asm-powerpc/ibmebus.h b/include/asm-powerpc/ibmebus.h
index 1a9d9ae..3a2618a 100644
--- a/include/asm-powerpc/ibmebus.h
+++ b/include/asm-powerpc/ibmebus.h
@@ -51,7 +51,7 @@ extern struct bus_type ibmebus_bus_type;
int ibmebus_register_driver(struct of_platform_driver *drv);
void ibmebus_unregister_driver(struct of_platform_driver *drv);
-int ibmebus_request_irq(u32 ist, irq_handler_t handler,
+int ibmebus_request_irq(u32 ist, int *irq_number, irq_handler_t handler,
unsigned long irq_flags, const char *devname,
void *dev_id);
void ibmebus_free_irq(u32 ist, void *dev_id);
--
1.5.5
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH 2/2] IB/ehca: In case of lost interrupts, trigger EOI to reenable interrupts
Signed-off-by: Stefan Roscher [EMAIL PROTECTED]
---
drivers/infiniband/hw/ehca/ehca_classes.h |1 +
drivers/infiniband/hw/ehca/ehca_eq.c |6 --
drivers/infiniband/hw/ehca/ehca_main.c| 12 ++--
3 files changed, 15 insertions(+), 4 deletions(-)
diff --git a/drivers/infiniband/hw/ehca/ehca_classes.h
b/drivers/infiniband/hw/ehca/ehca_classes.h
index 1e9e99a..4de363d 100644
--- a/drivers/infiniband/hw/ehca/ehca_classes.h
+++ b/drivers/infiniband/hw/ehca/ehca_classes.h
@@ -86,6 +86,7 @@ struct ehca_eq {
u32 ist;
spinlock_t irq_spinlock;
struct ehca_eqe_cache_entry eqe_cache[EHCA_EQE_CACHE_SIZE];
+ int irq_number;
};
struct ehca_sma_attr {
diff --git a/drivers/infiniband/hw/ehca/ehca_eq.c
b/drivers/infiniband/hw/ehca/ehca_eq.c
index 5bc494f..b70e5e5 100644
--- a/drivers/infiniband/hw/ehca/ehca_eq.c
+++ b/drivers/infiniband/hw/ehca/ehca_eq.c
@@ -122,7 +122,8 @@ int ehca_create_eq(struct ehca_shca *shca,
/* register interrupt handlers and initialize work queues */
if (type == EHCA_EQ) {
- ret = ibmebus_request_irq(eq-ist, NULL, ehca_interrupt_eq,
+ ret = ibmebus_request_irq(eq-ist, eq-irq_number,
+ ehca_interrupt_eq,
IRQF_DISABLED, ehca_eq,
(void *)shca);
if (ret 0)
@@ -130,7 +131,8 @@ int ehca_create_eq(struct ehca_shca *shca,
tasklet_init(eq-interrupt_task, ehca_tasklet_eq, (long)shca);
} else if (type == EHCA_NEQ) {
- ret = ibmebus_request_irq(eq-ist, NULL, ehca_interrupt_neq,
+ ret = ibmebus_request_irq(eq-ist, eq-irq_number,
+ ehca_interrupt_neq,
IRQF_DISABLED, ehca_neq,
(void *)shca);
if (ret 0)
diff --git a/drivers/infiniband/hw/ehca/ehca_main.c
b/drivers/infiniband/hw/ehca/ehca_main.c
index 482103e..d713317 100644
--- a/drivers/infiniband/hw/ehca/ehca_main.c
+++ b/drivers/infiniband/hw/ehca/ehca_main.c
@@ -44,6 +44,7 @@
#include linux/slab.h
#endif
+#include linux/irq.h
#include ehca_classes.h
#include ehca_iverbs.h
#include ehca_mrmw.h
@@ -937,6 +938,8 @@ static struct of_platform_driver ehca_driver = {
void ehca_poll_eqs(unsigned long data)
{
struct ehca_shca *shca;
+ int irq;
+ irq_desc_t *desc;
spin_lock(shca_list_lock);
list_for_each_entry(shca, shca_list, shca_list) {
@@ -955,8 +958,13 @@ void ehca_poll_eqs(unsigned long data)
spin_unlock_irqrestore(eq-spinlock, flags);
max--;
} while (q_ofs == q_ofs2 max 0);
- if (q_ofs == q_ofs2)
- ehca_process_eq(shca, 0);
+ if (q_ofs == q_ofs2) {
+ irq = shca-eq.irq_number;
+ desc = get_irq_desc(irq);
+ if (desc-chip desc-chip-eoi)
+ desc-chip-eoi(irq);
+ tasklet_hi_schedule(shca-eq.interrupt_task);
+ }
}
}
mod_timer(poll_eqs_timer, round_jiffies(jiffies + HZ));
--
1.5.5
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 1/2] ibmebus: Change ibmebus_request_irq() to optionally return irq number
Stefan Roscher [EMAIL PROTECTED] wrote on 09.06.2008 17:44:29:
Signed-off-by: Stefan Roscher [EMAIL PROTECTED]
---
arch/powerpc/kernel/ibmebus.c|5 -
drivers/infiniband/hw/ehca/ehca_eq.c |4 ++--
drivers/net/ehea/ehea_main.c |6 +++---
include/asm-powerpc/ibmebus.h|2 +-
4 files changed, 10 insertions(+), 7 deletions(-)
diff --git a/arch/powerpc/kernel/ibmebus.c
b/arch/powerpc/kernel/ibmebus.c
index 9971159..a002fdf 100644
--- a/arch/powerpc/kernel/ibmebus.c
+++ b/arch/powerpc/kernel/ibmebus.c
@@ -208,7 +208,7 @@ void ibmebus_unregister_driver(struct
of_platform_driver *drv)
}
EXPORT_SYMBOL(ibmebus_unregister_driver);
-int ibmebus_request_irq(u32 ist, irq_handler_t handler,
+int ibmebus_request_irq(u32 ist, int *irq_number, irq_handler_t
handler,
unsigned long irq_flags, const char *devname,
void *dev_id)
{
@@ -217,6 +217,9 @@ int ibmebus_request_irq(u32 ist, irq_handler_t
handler,
if (irq == NO_IRQ)
return -EINVAL;
+ if (irq_number)
+ *irq_number = irq;
+
return request_irq(irq, handler, irq_flags, devname, dev_id);
}
EXPORT_SYMBOL(ibmebus_request_irq);
diff --git a/drivers/infiniband/hw/ehca/ehca_eq.c
b/drivers/infiniband/hw/ehca/ehca_eq.c
index 49660df..5bc494f 100644
--- a/drivers/infiniband/hw/ehca/ehca_eq.c
+++ b/drivers/infiniband/hw/ehca/ehca_eq.c
@@ -122,7 +122,7 @@ int ehca_create_eq(struct ehca_shca *shca,
/* register interrupt handlers and initialize work queues */
if (type == EHCA_EQ) {
- ret = ibmebus_request_irq(eq-ist, ehca_interrupt_eq,
+ ret = ibmebus_request_irq(eq-ist, NULL, ehca_interrupt_eq,
IRQF_DISABLED, ehca_eq,
(void *)shca);
if (ret 0)
@@ -130,7 +130,7 @@ int ehca_create_eq(struct ehca_shca *shca,
tasklet_init(eq-interrupt_task, ehca_tasklet_eq, (long)shca);
} else if (type == EHCA_NEQ) {
- ret = ibmebus_request_irq(eq-ist, ehca_interrupt_neq,
+ ret = ibmebus_request_irq(eq-ist, NULL, ehca_interrupt_neq,
IRQF_DISABLED, ehca_neq,
(void *)shca);
if (ret 0)
diff --git a/drivers/net/ehea/ehea_main.c b/drivers/net/ehea/ehea_main.c
index 287a619..102ffeb 100644
--- a/drivers/net/ehea/ehea_main.c
+++ b/drivers/net/ehea/ehea_main.c
@@ -1216,7 +1216,7 @@ static int ehea_reg_interrupts(struct net_device
*dev)
snprintf(port-int_aff_name, EHEA_IRQ_NAME_SIZE - 1, %s-aff,
dev-name);
- ret = ibmebus_request_irq(port-qp_eq-attr.ist1,
+ ret = ibmebus_request_irq(port-qp_eq-attr.ist1, NULL,
ehea_qp_aff_irq_handler,
IRQF_DISABLED, port-int_aff_name, port);
if (ret) {
@@ -1234,7 +1234,7 @@ static int ehea_reg_interrupts(struct net_device
*dev)
pr = port-port_res[i];
snprintf(pr-int_send_name, EHEA_IRQ_NAME_SIZE - 1,
%s-queue%d, dev-name, i);
- ret = ibmebus_request_irq(pr-eq-attr.ist1,
+ ret = ibmebus_request_irq(pr-eq-attr.ist1, NULL,
ehea_recv_irq_handler,
IRQF_DISABLED, pr-int_send_name,
pr);
@@ -3414,7 +3414,7 @@ static int __devinit ehea_probe_adapter(struct
of_device *dev,
tasklet_init(adapter-neq_tasklet, ehea_neq_tasklet,
(unsigned long)adapter);
- ret = ibmebus_request_irq(adapter-neq-attr.ist1,
+ ret = ibmebus_request_irq(adapter-neq-attr.ist1, NULL,
ehea_interrupt_neq, IRQF_DISABLED,
ehea_neq, adapter);
if (ret) {
diff --git a/include/asm-powerpc/ibmebus.h
b/include/asm-powerpc/ibmebus.h
index 1a9d9ae..3a2618a 100644
--- a/include/asm-powerpc/ibmebus.h
+++ b/include/asm-powerpc/ibmebus.h
@@ -51,7 +51,7 @@ extern struct bus_type ibmebus_bus_type;
int ibmebus_register_driver(struct of_platform_driver *drv);
void ibmebus_unregister_driver(struct of_platform_driver *drv);
-int ibmebus_request_irq(u32 ist, irq_handler_t handler,
+int ibmebus_request_irq(u32 ist, int *irq_number, irq_handler_t
handler,
unsigned long irq_flags, const char *devname,
void *dev_id);
void ibmebus_free_irq(u32 ist, void *dev_id);
--
1.5.5
Concerning the eHEA part:
Acked-by: Jan-Bernd Themann [EMAIL PROTECTED]
Regards,
Jan-Bernd
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: Comments on device tree for pcm030
On Sunday 08 June 2008 21:08, Jon Smirl wrote:
What about the flash on the local bus? Could we use something like
this, or the same without the partition data?
[EMAIL PROTECTED] {
compatible = fsl,lpb;
ranges = 0 ff00 0100;
[EMAIL PROTECTED] {
compatible = cfi-flash;
reg = 0100;
bank-width = 2;
#size-cells = 1;
#address-cells = 1;
[EMAIL PROTECTED] {
label = ubootl;
reg = 0004;
};
[EMAIL PROTECTED] {
label = kernel;
reg = 0004 001c;
};
[EMAIL PROTECTED] {
label = jffs2;
reg = 0020 00D0;
};
[EMAIL PROTECTED] {
label = uboot;
reg = 00f0 0004;
};
[EMAIL PROTECTED] {
label = oftree;
reg = 00f4 0004;
};
[EMAIL PROTECTED] {
label = space;
reg = 00f8 0008;
};
};
};
Hmm, I tried with these setting (and many others) to make the flash on my
board work again.
But the physmap_of.c driver always fails. It tries to request the region
0xfe00 to 0x (my flash is 32MiB in size at 0xfe0 to
0x) and fails badly. What are the correct settings in the OFTree to
make the physmap_of.c driver work?
Regards,
Juergen
--
Dipl.-Ing. Juergen Beisert | http://www.pengutronix.de
Pengutronix - Linux Solutions for Science and Industry
Handelsregister: Amtsgericht Hildesheim, HRA 2686
Vertretung Sued/Muenchen, Germany
Phone: +49-8766-939 228 | Fax: +49-5121-206917-9
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 2/2] IB/ehca: In case of lost interrupts, trigger EOI to reenable interrupts
+if (desc-chip desc-chip-eoi) +desc-chip-eoi(irq); This doesn't seem like the type of thing a device driver should be doing. Both patches are rather short on changelog text -- what is the issue here and how does this fix it? - R. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
RE: 4xx support in arch/ppc is going away Real Soon Now
-Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Geert Uytterhoeven Sent: Monday, June 09, 2008 1:46 AM To: Jon Loeliger Cc: linuxppc-dev@ozlabs.org; Adrian Bunk; Paul Mackerras Subject: Re: 4xx support in arch/ppc is going away Real Soon Now On Sun, 8 Jun 2008, Jon Loeliger wrote: Grant Likely writes: Oh, and we're going try to create the longest acked-by chain in Linux history. Cool :) Paul. So far, I think it looks like this, sorted: Acked-by: Arnd Bergmann [EMAIL PROTECTED] Acked-by: Becky Bruce [EMAIL PROTECTED] Acked-by: Benjamin Herrenschmidt [EMAIL PROTECTED] Acked-by: Grant Likely [EMAIL PROTECTED] Acked-by: Jochen Friedrich [EMAIL PROTECTED] Acked-by: Jon Loeliger [EMAIL PROTECTED] Acked-by: Josh Boyer [EMAIL PROTECTED] Acked-by: Kumar Gala [EMAIL PROTECTED] Acked-by: Olof Johansson [EMAIL PROTECTED] Acked-by: Peter Korsgaard [EMAIL PROTECTED] Acked-by: Scott Wood [EMAIL PROTECTED] Acked-by: Sean MacLennan [EMAIL PROTECTED] Acked-by: Segher Boessenkool [EMAIL PROTECTED] Acked-by: Stefan Roese [EMAIL PROTECTED] Acked-by: Stephen Neuendorffer [EMAIL PROTECTED] Acked-by: Wolfgang Denk [EMAIL PROTECTED] Acked-by: Geert Uytterhoeven [EMAIL PROTECTED] Acked-by: John Linn [EMAIL PROTECTED] Looking forward to meeting some of you at the Linux Symposium in July. -- John This email and any attachments are intended for the sole use of the named recipient(s) and contain(s) confidential information that may be proprietary, privileged or copyrighted under applicable law. If you are not the intended recipient, do not read, copy, or forward this email message or any attachments. Delete this email message and any attachments immediately. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: 2.6.26-rc5-mm1: procfs whine
On Monday, June 09, 2008 1:48 am Andrew Morton wrote: At boot, using http://userweb.kernel.org/~akpm/config-g5.txt on a mac g5: io scheduler cfq registered proc_dir_entry '00' already registered Call Trace: [c0017a0fbb70] [c00120fc] .show_stack+0x58/0x1dc (unreliable) [c0017a0fbc20] [c01415a8] .proc_register+0x218/0x260 [c0017a0fbcd0] [c01419d4] .proc_mkdir_mode+0x40/0x74 [c0017a0fbd50] [c01e6640] .pci_proc_attach_device+0x90/0x134 [c0017a0fbdf0] [c05e5250] .pci_proc_init+0x68/0xa0 [c0017a0fbe70] [c05c0cd4] .kernel_init+0x228/0x49c [c0017a0fbf90] [c0026e0c] .kernel_thread+0x4c/0x68 nvidiafb: Device ID: 10de0141 Maybe something in the powerpc PCI init code changed recently? It looks like pci_bus_add_devices() is getting called more than once (or at least pci_bus_add_device() for this specific device). Jesse ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Making the Kernel
Good Afternoon, I've gone through the process of configuring a kernel for my Xilinx board design using the mhs-devtree, dts+'make menuconfig' options-'make all' process and things seem to have succeeded. I was under the expectation that I would find a file arch/powerpc/boot/zImage.virtex, which is a type of .elf file that I can use to make a bitstream, but I didn't find this said file in the output. I found several zImage files (zImage, zImage.pmac,.miboot,.chrp,.lds,.cofflds), but none of them had the desired '.virtex' extension. Am I looking for something that doesn't exist? If not, can someone help me generate the necessary file? This is my first time through this process so I appreciate your advice. Sincerely, Jake Poteet ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
RE: Making the Kernel
The kernel at git.xilinx.com has a rule to make zImage.virtex. Note that this elf file will almost certainly *not* fit in blockram, hence you can't use it to 'make a bitstream'. You can use it to generate a SystemAce file, however. If you are using a current mainline kernel, then you need to make a simpleImage, which requires having a dts file that starts with the 'virtex-' prefix. Steve -Original Message- From: [EMAIL PROTECTED] [mailto:linuxppc-dev- [EMAIL PROTECTED] On Behalf Of Jacob Holladay Poteet Sent: Monday, June 09, 2008 1:09 PM To: linuxppc-dev@ozlabs.org Subject: Making the Kernel Good Afternoon, I've gone through the process of configuring a kernel for my Xilinx board design using the mhs-devtree, dts+'make menuconfig' options-'make all' process and things seem to have succeeded. I was under the expectation that I would find a file arch/powerpc/boot/zImage.virtex, which is a type of .elf file that I can use to make a bitstream, but I didn't find this said file in the output. I found several zImage files (zImage, zImage.pmac,.miboot,.chrp,.lds,.cofflds), but none of them had the desired '.virtex' extension. Am I looking for something that doesn't exist? If not, can someone help me generate the necessary file? This is my first time through this process so I appreciate your advice. Sincerely, Jake Poteet ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev This email and any attachments are intended for the sole use of the named recipient(s) and contain(s) confidential information that may be proprietary, privileged or copyrighted under applicable law. If you are not the intended recipient, do not read, copy, or forward this email message or any attachments. Delete this email message and any attachments immediately. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: Comments on device tree for pcm030
On Mon, Jun 09, 2008 at 11:13:35AM +0200, Sascha Hauer wrote: I think partitions shouldn't go into the default device tree, as people may have different partitioning. It is also a chicken-and-egg thing, because the oftree would describe the partition it is in. Robert -- Dipl.-Ing. Robert Schwebel | http://www.pengutronix.de Pengutronix - Linux Solutions for Science and Industry Handelsregister: Amtsgericht Hildesheim, HRA 2686 Hannoversche Str. 2, 31134 Hildesheim, Germany Phone: +49-5121-206917-0 | Fax: +49-5121-206917-9 ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: Comments on device tree for pcm030
On Sun, Jun 08, 2008 at 03:08:33PM -0400, Jon Smirl wrote: There should be an i2c entry for the eeprom but I don't know the part number for it. Wolfram has oftree bindings for the new at24 driver which will be used in combination with this board. For patches, please see the i2c list. Robert -- Dipl.-Ing. Robert Schwebel | http://www.pengutronix.de Pengutronix - Linux Solutions for Science and Industry Handelsregister: Amtsgericht Hildesheim, HRA 2686 Hannoversche Str. 2, 31134 Hildesheim, Germany Phone: +49-5121-206917-0 | Fax: +49-5121-206917-9 ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: Comments on device tree for pcm030
On 6/9/08, Juergen Beisert [EMAIL PROTECTED] wrote:
On Sunday 08 June 2008 21:08, Jon Smirl wrote:
What about the flash on the local bus? Could we use something like
this, or the same without the partition data?
[EMAIL PROTECTED] {
compatible = fsl,lpb;
ranges = 0 ff00 0100;
[EMAIL PROTECTED] {
compatible = cfi-flash;
reg = 0100;
bank-width = 2;
#size-cells = 1;
#address-cells = 1;
[EMAIL PROTECTED] {
label = ubootl;
reg = 0004;
};
[EMAIL PROTECTED] {
label = kernel;
reg = 0004 001c;
};
[EMAIL PROTECTED] {
label = jffs2;
reg = 0020 00D0;
};
[EMAIL PROTECTED] {
label = uboot;
reg = 00f0 0004;
};
[EMAIL PROTECTED] {
label = oftree;
reg = 00f4 0004;
};
[EMAIL PROTECTED] {
label = space;
reg = 00f8 0008;
};
};
};
Hmm, I tried with these setting (and many others) to make the flash on my
board work again.
But the physmap_of.c driver always fails. It tries to request the region
0xfe00 to 0x (my flash is 32MiB in size at 0xfe0 to
0x) and fails badly. What are the correct settings in the OFTree to
make the physmap_of.c driver work?
This is my boot log:
ff00.flash: Found 1 x16 devices at 0x0 in 16-bit bank
Intel/Sharp Extended Query Table at 0x0031
Using buffer write method
cfi_cmdset_0001: Erase suspend on write enabled
RedBoot partition parsing not available
Creating 6 MTD partitions on ff00.flash:
0x-0x0004 : ubootl
0x0004-0x0020 : kernel
0x0020-0x00f0 : jffs2
0x00f0-0x00f4 : uboot
0x00f4-0x00f8 : oftree
0x00f8-0x0100 : space
CONFIG_MTD=y
# CONFIG_MTD_DEBUG is not set
CONFIG_MTD_CONCAT=y
CONFIG_MTD_PARTITIONS=y
# CONFIG_MTD_REDBOOT_PARTS is not set
CONFIG_MTD_CMDLINE_PARTS=y
#
# User Modules And Translation Layers
#
CONFIG_MTD_CHAR=y
CONFIG_MTD_BLKDEVS=y
CONFIG_MTD_BLOCK=y
# CONFIG_FTL is not set
# CONFIG_NFTL is not set
# CONFIG_INFTL is not set
# CONFIG_RFD_FTL is not set
# CONFIG_SSFDC is not set
# CONFIG_MTD_OOPS is not set
#
# RAM/ROM/Flash chip drivers
#
CONFIG_MTD_CFI=y
# CONFIG_MTD_JEDECPROBE is not set
CONFIG_MTD_GEN_PROBE=y
# CONFIG_MTD_CFI_ADV_OPTIONS is not set
CONFIG_MTD_MAP_BANK_WIDTH_1=y
CONFIG_MTD_MAP_BANK_WIDTH_2=y
CONFIG_MTD_MAP_BANK_WIDTH_4=y
# CONFIG_MTD_MAP_BANK_WIDTH_8 is not set
# CONFIG_MTD_MAP_BANK_WIDTH_16 is not set
# CONFIG_MTD_MAP_BANK_WIDTH_32 is not set
CONFIG_MTD_CFI_I1=y
CONFIG_MTD_CFI_I2=y
# CONFIG_MTD_CFI_I4 is not set
# CONFIG_MTD_CFI_I8 is not set
CONFIG_MTD_CFI_INTELEXT=y
# CONFIG_MTD_CFI_AMDSTD is not set
# CONFIG_MTD_CFI_STAA is not set
CONFIG_MTD_CFI_UTIL=y
# CONFIG_MTD_RAM is not set
# CONFIG_MTD_ROM is not set
# CONFIG_MTD_ABSENT is not set
#
# Mapping drivers for chip access
#
# CONFIG_MTD_COMPLEX_MAPPINGS is not set
# CONFIG_MTD_PHYSMAP is not set
CONFIG_MTD_PHYSMAP_OF=y
# CONFIG_MTD_INTEL_VR_NOR is not set
# CONFIG_MTD_PLATRAM is not set
Regards,
Juergen
--
Dipl.-Ing. Juergen Beisert | http://www.pengutronix.de
Pengutronix - Linux Solutions for Science and Industry
Handelsregister: Amtsgericht Hildesheim, HRA 2686
Vertretung Sued/Muenchen, Germany
Phone: +49-8766-939 228 | Fax: +49-5121-206917-9
--
Jon Smirl
[EMAIL PROTECTED]
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
[2.6 patch] drivers/macintosh/: possible cleanups
This patch contains the following possible cleanups:
- make the following needlessly global code static:
- adb.c: adb_controller
- adb.c: adb_init()
- adbhid.c: adb_to_linux_keycodes[]
- via-pmu68k.c: backlight_level
- via-pmu68k.c: backlight_enabled
- remove the following unused code:
- via-pmu68k.c: sleep_notifier_list
Signed-off-by: Adrian Bunk [EMAIL PROTECTED]
---
drivers/macintosh/adb.c|5 ++---
drivers/macintosh/adbhid.c |2 +-
drivers/macintosh/via-pmu68k.c |5 ++---
include/linux/adb.h|1 -
4 files changed, 5 insertions(+), 8 deletions(-)
45413fb42fb4215d80bb15f50a5bdc869465e9a1 diff --git a/drivers/macintosh/adb.c
b/drivers/macintosh/adb.c
index dbaad39..61b62a6 100644
--- a/drivers/macintosh/adb.c
+++ b/drivers/macintosh/adb.c
@@ -46,7 +46,6 @@
#endif
-EXPORT_SYMBOL(adb_controller);
EXPORT_SYMBOL(adb_client_list);
extern struct adb_driver via_macii_driver;
@@ -80,7 +79,7 @@ static struct adb_driver *adb_driver_list[] = {
static struct class *adb_dev_class;
-struct adb_driver *adb_controller;
+static struct adb_driver *adb_controller;
BLOCKING_NOTIFIER_HEAD(adb_client_list);
static int adb_got_sleep;
static int adb_inited;
@@ -290,7 +289,7 @@ static int adb_resume(struct platform_device *dev)
}
#endif /* CONFIG_PM */
-int __init adb_init(void)
+static int __init adb_init(void)
{
struct adb_driver *driver;
int i;
diff --git a/drivers/macintosh/adbhid.c b/drivers/macintosh/adbhid.c
index ef4c117..af72f97 100644
--- a/drivers/macintosh/adbhid.c
+++ b/drivers/macintosh/adbhid.c
@@ -75,7 +75,7 @@ static struct notifier_block adbhid_adb_notifier = {
#define ADB_KEY_POWER_OLD 0x7e
#define ADB_KEY_POWER 0x7f
-u16 adb_to_linux_keycodes[128] = {
+static u16 adb_to_linux_keycodes[128] = {
/* 0x00 */ KEY_A, /* 30 */
/* 0x01 */ KEY_S, /* 31 */
/* 0x02 */ KEY_D, /* 32 */
diff --git a/drivers/macintosh/via-pmu68k.c b/drivers/macintosh/via-pmu68k.c
index e2f84da..b64741c 100644
--- a/drivers/macintosh/via-pmu68k.c
+++ b/drivers/macintosh/via-pmu68k.c
@@ -101,7 +101,6 @@ static int pmu_kind = PMU_UNKNOWN;
static int pmu_fully_inited;
int asleep;
-BLOCKING_NOTIFIER_HEAD(sleep_notifier_list);
static int pmu_probe(void);
static int pmu_init(void);
@@ -741,8 +740,8 @@ pmu_handle_data(unsigned char *data, int len)
}
}
-int backlight_level = -1;
-int backlight_enabled = 0;
+static int backlight_level = -1;
+static int backlight_enabled = 0;
#define LEVEL_TO_BRIGHT(lev) ((lev) 1? 0x7f: 0x4a - ((lev) 1))
diff --git a/include/linux/adb.h b/include/linux/adb.h
index 64d8878..63bca50 100644
--- a/include/linux/adb.h
+++ b/include/linux/adb.h
@@ -84,7 +84,6 @@ enum adb_message {
ADB_MSG_PRE_RESET, /* Called before resetting the bus */
ADB_MSG_POST_RESET /* Called after resetting the bus (re-do init
register) */
};
-extern struct adb_driver *adb_controller;
extern struct blocking_notifier_head adb_client_list;
int adb_request(struct adb_request *req, void (*done)(struct adb_request *),
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 0/2] Prevent loss of interrupts in IB/ehca
Stefan Roscher writes: This patchset contains two changes for IB/ehca and ibmebus. The first patch enables ibmebus_request_irq() to optionally return the IRQ number, which is used by the second patch to trigger EOI in case of lost interrupts. At first sight it seems like a very bad idea for a driver to be poking into the internals of the interrupt subsystem like this. Under what circumstances do interrupts get lost, and why does doing an extra EOI like this fix the problem? Paul. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 1/2] ibmebus: Change ibmebus_request_irq() to optionally return irq number
Hi Stefan, On Mon, 9 Jun 2008 17:44:29 +0200 Stefan Roscher [EMAIL PROTECTED] wrote: Signed-off-by: Stefan Roscher [EMAIL PROTECTED] Before Paulus gets to you: Why are we doing this? Please write an explanatory commit message. -- Cheers, Stephen Rothwell[EMAIL PROTECTED] http://www.canb.auug.org.au/~sfr/ pgpkOyIIPyz4u.pgp Description: PGP signature ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[patch 2/5] spufs: convert nopfn to fault
From: Nick Piggin [EMAIL PROTECTED]
spufs: convert nopfn to fault
Signed-off-by: Nick Piggin [EMAIL PROTECTED]
Acked-by: Jeremy Kerr [EMAIL PROTECTED]
Cc: Paul Mackerras [EMAIL PROTECTED]
Cc: Benjamin Herrenschmidt [EMAIL PROTECTED]
Signed-off-by: Andrew Morton [EMAIL PROTECTED]
---
arch/powerpc/platforms/cell/spufs/file.c | 98 -
arch/powerpc/platforms/cell/spufs/sputrace.c |8 -
2 files changed, 54 insertions(+), 52 deletions(-)
diff -puN arch/powerpc/platforms/cell/spufs/file.c~spufs-convert-nopfn-to-fault
arch/powerpc/platforms/cell/spufs/file.c
--- a/arch/powerpc/platforms/cell/spufs/file.c~spufs-convert-nopfn-to-fault
+++ a/arch/powerpc/platforms/cell/spufs/file.c
@@ -238,11 +238,13 @@ spufs_mem_write(struct file *file, const
return size;
}
-static unsigned long spufs_mem_mmap_nopfn(struct vm_area_struct *vma,
- unsigned long address)
+static int
+spufs_mem_mmap_fault(struct vm_area_struct *vma, struct vm_fault *vmf)
{
struct spu_context *ctx = vma-vm_file-private_data;
- unsigned long pfn, offset, addr0 = address;
+ unsigned long address = (unsigned long)vmf-virtual_address;
+ unsigned long pfn, offset;
+
#ifdef CONFIG_SPU_FS_64K_LS
struct spu_state *csa = ctx-csa;
int psize;
@@ -260,15 +262,15 @@ static unsigned long spufs_mem_mmap_nopf
}
#endif /* CONFIG_SPU_FS_64K_LS */
- offset = (address - vma-vm_start) + (vma-vm_pgoff PAGE_SHIFT);
+ offset = vmf-pgoff PAGE_SHIFT;
if (offset = LS_SIZE)
- return NOPFN_SIGBUS;
+ return VM_FAULT_SIGBUS;
- pr_debug(spufs_mem_mmap_nopfn address=0x%lx - 0x%lx, offset=0x%lx\n,
-addr0, address, offset);
+ pr_debug(spufs_mem_mmap_fault address=0x%lx, offset=0x%lx\n,
+ address, offset);
if (spu_acquire(ctx))
- return NOPFN_REFAULT;
+ return VM_FAULT_NOPAGE;
if (ctx-state == SPU_STATE_SAVED) {
vma-vm_page_prot = __pgprot(pgprot_val(vma-vm_page_prot)
@@ -283,12 +285,12 @@ static unsigned long spufs_mem_mmap_nopf
spu_release(ctx);
- return NOPFN_REFAULT;
+ return VM_FAULT_NOPAGE;
}
static struct vm_operations_struct spufs_mem_mmap_vmops = {
- .nopfn = spufs_mem_mmap_nopfn,
+ .fault = spufs_mem_mmap_fault,
};
static int spufs_mem_mmap(struct file *file, struct vm_area_struct *vma)
@@ -351,20 +353,19 @@ static const struct file_operations spuf
#endif
};
-static unsigned long spufs_ps_nopfn(struct vm_area_struct *vma,
- unsigned long address,
+static int spufs_ps_fault(struct vm_area_struct *vma,
+ struct vm_fault *vmf,
unsigned long ps_offs,
unsigned long ps_size)
{
struct spu_context *ctx = vma-vm_file-private_data;
- unsigned long area, offset = address - vma-vm_start;
+ unsigned long area, offset = vmf-pgoff PAGE_SHIFT;
int ret = 0;
- spu_context_nospu_trace(spufs_ps_nopfn__enter, ctx);
+ spu_context_nospu_trace(spufs_ps_fault__enter, ctx);
- offset += vma-vm_pgoff PAGE_SHIFT;
if (offset = ps_size)
- return NOPFN_SIGBUS;
+ return VM_FAULT_SIGBUS;
/*
* Because we release the mmap_sem, the context may be destroyed while
@@ -378,7 +379,7 @@ static unsigned long spufs_ps_nopfn(stru
* pages to hand out to the user, but we don't want to wait
* with the mmap_sem held.
* It is possible to drop the mmap_sem here, but then we need
-* to return NOPFN_REFAULT because the mappings may have
+* to return VM_FAULT_NOPAGE because the mappings may have
* hanged.
*/
if (spu_acquire(ctx))
@@ -386,14 +387,15 @@ static unsigned long spufs_ps_nopfn(stru
if (ctx-state == SPU_STATE_SAVED) {
up_read(current-mm-mmap_sem);
- spu_context_nospu_trace(spufs_ps_nopfn__sleep, ctx);
+ spu_context_nospu_trace(spufs_ps_fault__sleep, ctx);
ret = spufs_wait(ctx-run_wq, ctx-state == SPU_STATE_RUNNABLE);
- spu_context_trace(spufs_ps_nopfn__wake, ctx, ctx-spu);
+ spu_context_trace(spufs_ps_fault__wake, ctx, ctx-spu);
down_read(current-mm-mmap_sem);
} else {
area = ctx-spu-problem_phys + ps_offs;
- vm_insert_pfn(vma, address, (area + offset) PAGE_SHIFT);
- spu_context_trace(spufs_ps_nopfn__insert, ctx, ctx-spu);
+ vm_insert_pfn(vma, (unsigned long)vmf-virtual_address,
+ (area + offset) PAGE_SHIFT);
+ spu_context_trace(spufs_ps_fault__insert, ctx, ctx-spu);
}
if (!ret)
@@ -401,18 +403,18 @@ static unsigned
[patch 1/5] powerpc: fix for OProfile callgraph for Power 64 bit user apps
From: Carl Love [EMAIL PROTECTED]
Fix the 64 bit user code backtrace which currently may hang the system.
Signed-off-by: Carl Love [EMAIL PROTECTED]
Cc: Maynard Johnson [EMAIL PROTECTED]
On Thu, 15 May 2008 10:20:44 +1000
Michael Ellerman [EMAIL PROTECTED] wrote:
__copy_from_user_inatomic() accepts any value for n, it just has a
special case for 1, 2, 4 and 8 - but it should still work for other
values.
The old code copied 24 bytes from sp, and the new code copies 8 bytes
from sp and 8 bytes from sp + 16 - so I don't see where the 48 bytes
comes in to it?
\ufeffAlso the comment is a little hard to parse, I think you mean Issue:
the .., but I read Issue as a verb in that sentence. And Don't read
more then should be than.
Signed-off-by: Andrew Morton [EMAIL PROTECTED]
---
arch/powerpc/oprofile/backtrace.c | 33 ++--
1 file changed, 27 insertions(+), 6 deletions(-)
diff -puN
arch/powerpc/oprofile/backtrace.c~powerpc-fix-for-oprofile-callgraph-for-power-64-bit-user-apps
arch/powerpc/oprofile/backtrace.c
---
a/arch/powerpc/oprofile/backtrace.c~powerpc-fix-for-oprofile-callgraph-for-power-64-bit-user-apps
+++ a/arch/powerpc/oprofile/backtrace.c
@@ -53,19 +53,40 @@ static unsigned int user_getsp32(unsigne
#ifdef CONFIG_PPC64
static unsigned long user_getsp64(unsigned long sp, int is_first)
{
- unsigned long stack_frame[3];
+ unsigned long stk_frm_lr;
+ unsigned long stk_frm_sp;
+ unsigned long size;
+
+ /* Issue the __copy_from_user_inatomic() third argument currently
+* only takes sizes 1, 2, 4 or 8 bytes. Don't read more then the
+* first 48 bytes of the stack frame. That is all that is
+* guaranteed to exist. Reading more may cause the system to hang.
+*
+* 64 bit stack frame layout:
+* 0-7 bytes is the pointer to previous stack
+* 8-15 bytes condition register save area
+* 16-23 bytes link register save area
+*/
+ size = sizeof(unsigned long);
+ if (!access_ok(VERIFY_READ, (void __user *)sp, size))
+ return 0;
- if (!access_ok(VERIFY_READ, (void __user *)sp, sizeof(stack_frame)))
+ if (__copy_from_user_inatomic(stk_frm_sp, (void __user *)sp,
+ size))
return 0;
- if (__copy_from_user_inatomic(stack_frame, (void __user *)sp,
- sizeof(stack_frame)))
+ /* get the LR from the user stack */
+ if (!access_ok(VERIFY_READ, (void __user *)(sp+16), size))
+ return 0;
+
+ if (__copy_from_user_inatomic(stk_frm_lr, (void __user *)(sp+16),
+ size))
return 0;
if (!is_first)
- oprofile_add_trace(STACK_LR64(stack_frame));
+ oprofile_add_trace(stk_frm_lr);
- return STACK_SP(stack_frame);
+ return stk_frm_sp;
}
#endif
_
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
[patch 5/5] arch/powerpc/platforms/pseries/eeh_driver.c: fix warning
From: Andrew Morton [EMAIL PROTECTED]
Fix this:
/usr/src/devel/arch/powerpc/platforms/pseries/eeh_driver.c: In function
'print_device_node_tree':
/usr/src/devel/arch/powerpc/platforms/pseries/eeh_driver.c:55: warning: ISO C90
forbids mixed declarations and code
also make that function look like it's part of Linux. I mean, wtf are you
guys up to down there??
[EMAIL PROTECTED]: coding-style fixes]
Cc: Benjamin Herrenschmidt [EMAIL PROTECTED]
Cc: Paul Mackerras [EMAIL PROTECTED]
Signed-off-by: Andrew Morton [EMAIL PROTECTED]
---
arch/powerpc/platforms/pseries/eeh_driver.c | 11 +++
1 file changed, 7 insertions(+), 4 deletions(-)
diff -puN
arch/powerpc/platforms/pseries/eeh_driver.c~arch-powerpc-platforms-pseries-eeh_driverc-fix-warning
arch/powerpc/platforms/pseries/eeh_driver.c
---
a/arch/powerpc/platforms/pseries/eeh_driver.c~arch-powerpc-platforms-pseries-eeh_driverc-fix-warning
+++ a/arch/powerpc/platforms/pseries/eeh_driver.c
@@ -42,17 +42,20 @@ static inline const char * pcid_name (st
}
#ifdef DEBUG
-static void print_device_node_tree (struct pci_dn *pdn, int dent)
+static void print_device_node_tree(struct pci_dn *pdn, int dent)
{
int i;
- if (!pdn) return;
- for (i=0;ident; i++)
+ struct device_node *pc;
+
+ if (!pdn)
+ return;
+ for (i = 0; i dent; i++)
printk( );
printk(dn=%s mode=%x \tcfg_addr=%x pe_addr=%x \tfull=%s\n,
pdn-node-name, pdn-eeh_mode, pdn-eeh_config_addr,
pdn-eeh_pe_config_addr, pdn-node-full_name);
dent += 3;
- struct device_node *pc = pdn-node-child;
+ pc = pdn-node-child;
while (pc) {
print_device_node_tree(PCI_DN(pc), dent);
pc = pc-sibling;
_
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
[patch 1/1] fsldma: the MPC8377MDS board device tree node for fsldma driver
From: Zhang Wei [EMAIL PROTECTED]
The fsldma driver is tested on MPC8377MDS board. The patch adds fsldma driver
support into MPC8377MDS device tree.
Signed-off-by: Zhang Wei [EMAIL PROTECTED]
Cc: Nelson, Shannon [EMAIL PROTECTED]
Cc: Dan Williams [EMAIL PROTECTED]
Cc: Kumar Gala [EMAIL PROTECTED]
Cc: Paul Mackerras [EMAIL PROTECTED]
Cc: Benjamin Herrenschmidt [EMAIL PROTECTED]
Cc: Scott Wood [EMAIL PROTECTED]
Cc: Li Yang [EMAIL PROTECTED]
On Wed, 14 May 2008 18:28:08 -0500
Scott Wood [EMAIL PROTECTED] wrote:
[EMAIL PROTECTED] wrote:
From: Zhang Wei [EMAIL PROTECTED]
According to booting-without-of.txt, the interrupts property should be
repeated in each channel. The driver also needs to be fixed to remember
whether it registered a DMA-block-level interrupt handler already, and
not try to register a channel interrupt.
Signed-off-by: Andrew Morton [EMAIL PROTECTED]
---
arch/powerpc/boot/dts/mpc8377_mds.dts | 27
1 file changed, 27 insertions(+)
diff -puN
arch/powerpc/boot/dts/mpc8377_mds.dts~fsldma-the-mpc8377mds-board-device-tree-node-for-fsldma-driver
arch/powerpc/boot/dts/mpc8377_mds.dts
---
a/arch/powerpc/boot/dts/mpc8377_mds.dts~fsldma-the-mpc8377mds-board-device-tree-node-for-fsldma-driver
+++ a/arch/powerpc/boot/dts/mpc8377_mds.dts
@@ -303,6 +303,33 @@
};
};
+ [EMAIL PROTECTED] {
+ #address-cells = 1;
+ #size-cells = 1;
+ compatible = fsl,mpc8349-dma;
+ reg = 0x82a8 4;
+ ranges = 0 0x8100 0x1a8;
+ interrupt-parent = ipic;
+ interrupts = 0x47 8;
+ cell-index = 0;
+ [EMAIL PROTECTED] {
+ compatible = fsl,mpc8349-dma-channel;
+ reg = 0 0x80;
+ };
+ [EMAIL PROTECTED] {
+ compatible = fsl,mpc8349-dma-channel;
+ reg = 0x80 0x80;
+ };
+ [EMAIL PROTECTED] {
+ compatible = fsl,mpc8349-dma-channel;
+ reg = 0x100 0x80;
+ };
+ [EMAIL PROTECTED] {
+ compatible = fsl,mpc8349-dma-channel;
+ reg = 0x180 0x28;
+ };
+ };
+
/* IPIC
* interrupts cell = intr #, sense
* sense values match linux IORESOURCE_IRQ_* defines:
_
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
[patch 4/5] macintosh: media bay: semaphore to mutex
From: Daniel Walker [EMAIL PROTECTED]
Signed-off-by: Daniel Walker [EMAIL PROTECTED]
Signed-off-by: Andrew Morton [EMAIL PROTECTED]
---
drivers/macintosh/mediabay.c | 27 ++-
1 file changed, 14 insertions(+), 13 deletions(-)
diff -puN drivers/macintosh/mediabay.c~macintosh-media-bay-semaphore-to-mutex
drivers/macintosh/mediabay.c
--- a/drivers/macintosh/mediabay.c~macintosh-media-bay-semaphore-to-mutex
+++ a/drivers/macintosh/mediabay.c
@@ -21,6 +21,7 @@
#include linux/init.h
#include linux/ide.h
#include linux/kthread.h
+#include linux/mutex.h
#include asm/prom.h
#include asm/pgtable.h
#include asm/io.h
@@ -77,7 +78,7 @@ struct media_bay_info {
int index;
int cached_gpio;
int sleeping;
- struct semaphorelock;
+ struct mutexlock;
#ifdef CONFIG_BLK_DEV_IDE_PMAC
ide_hwif_t *cd_port;
void __iomem*cd_base;
@@ -459,27 +460,27 @@ int media_bay_set_ide_infos(struct devic
if (bay-mdev which_bay == bay-mdev-ofdev.node) {
int timeout = 5000, index = hwif-index;
- down(bay-lock);
+ mutex_lock(bay-lock);
bay-cd_port= hwif;
bay-cd_base= (void __iomem *) base;
bay-cd_irq = irq;
if ((MB_CD != bay-content_id) || bay-state != mb_up) {
- up(bay-lock);
+ mutex_unlock(bay-lock);
return 0;
}
printk(KERN_DEBUG Registered ide%d for media bay
%d\n, index, i);
do {
if (MB_IDE_READY(i)) {
bay-cd_index = index;
- up(bay-lock);
+ mutex_unlock(bay-lock);
return 0;
}
mdelay(1);
} while(--timeout);
printk(KERN_DEBUG Timeount waiting IDE in bay %d\n,
i);
- up(bay-lock);
+ mutex_unlock(bay-lock);
return -ENODEV;
}
}
@@ -616,10 +617,10 @@ static int media_bay_task(void *x)
while (!kthread_should_stop()) {
for (i = 0; i media_bay_count; ++i) {
- down(media_bays[i].lock);
+ mutex_lock(media_bays[i].lock);
if (!media_bays[i].sleeping)
media_bay_step(i);
- up(media_bays[i].lock);
+ mutex_unlock(media_bays[i].lock);
}
msleep_interruptible(MB_POLL_DELAY);
@@ -659,7 +660,7 @@ static int __devinit media_bay_attach(st
bay-index = i;
bay-ops = match-data;
bay-sleeping = 0;
- init_MUTEX(bay-lock);
+ mutex_init(bay-lock);
/* Init HW probing */
if (bay-ops-init)
@@ -697,10 +698,10 @@ static int media_bay_suspend(struct maci
if (state.event != mdev-ofdev.dev.power.power_state.event
(state.event PM_EVENT_SLEEP)) {
- down(bay-lock);
+ mutex_lock(bay-lock);
bay-sleeping = 1;
set_mb_power(bay, 0);
- up(bay-lock);
+ mutex_unlock(bay-lock);
msleep(MB_POLL_DELAY);
mdev-ofdev.dev.power.power_state = state;
}
@@ -719,12 +720,12 @@ static int media_bay_resume(struct macio
they seem to help the 3400 get it right.
*/
/* Force MB power to 0 */
- down(bay-lock);
+ mutex_lock(bay-lock);
set_mb_power(bay, 0);
msleep(MB_POWER_DELAY);
if (bay-ops-content(bay) != bay-content_id) {
printk(mediabay%d: content changed during sleep...\n,
bay-index);
- up(bay-lock);
+ mutex_unlock(bay-lock);
return 0;
}
set_mb_power(bay, 1);
@@ -740,7 +741,7 @@ static int media_bay_resume(struct macio
} while((bay-state != mb_empty)
(bay-state != mb_up));
bay-sleeping = 0;
- up(bay-lock);
+ mutex_unlock(bay-lock);
}
return 0;
}
_
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
[patch 3/5] macintosh: therm_windtunnel: semaphore to mutex
From: Daniel Walker [EMAIL PROTECTED]
Signed-off-by: Daniel Walker [EMAIL PROTECTED]
Signed-off-by: Andrew Morton [EMAIL PROTECTED]
---
drivers/macintosh/therm_windtunnel.c | 16
1 file changed, 8 insertions(+), 8 deletions(-)
diff -puN
drivers/macintosh/therm_windtunnel.c~macintosh-therm_windtunnel-semaphore-to-mutex
drivers/macintosh/therm_windtunnel.c
---
a/drivers/macintosh/therm_windtunnel.c~macintosh-therm_windtunnel-semaphore-to-mutex
+++ a/drivers/macintosh/therm_windtunnel.c
@@ -62,7 +62,7 @@ static struct {
volatile intrunning;
struct task_struct *poll_task;
- struct semaphorelock;
+ struct mutexlock;
struct of_device*of_dev;
struct i2c_client *thermostat;
@@ -286,23 +286,23 @@ restore_regs( void )
static int control_loop(void *dummy)
{
- down(x.lock);
+ mutex_lock(x.lock);
setup_hardware();
- up(x.lock);
+ mutex_unlock(x.lock);
for (;;) {
msleep_interruptible(8000);
if (kthread_should_stop())
break;
- down(x.lock);
+ mutex_lock(x.lock);
poll_temp();
- up(x.lock);
+ mutex_unlock(x.lock);
}
- down(x.lock);
+ mutex_lock(x.lock);
restore_regs();
- up(x.lock);
+ mutex_unlock(x.lock);
return 0;
}
@@ -489,7 +489,7 @@ g4fan_init( void )
const struct apple_thermal_info *info;
struct device_node *np;
- init_MUTEX( x.lock );
+ mutex_init(x.lock);
if( !(np=of_find_node_by_name(NULL, power-mgt)) )
return -ENODEV;
_
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [patch 1/5] powerpc: fix for OProfile callgraph for Power 64 bit user apps
On Mon, 2008-06-09 at 16:26 -0700, [EMAIL PROTECTED] wrote:
From: Carl Love [EMAIL PROTECTED]
Fix the 64 bit user code backtrace which currently may hang the system.
Signed-off-by: Carl Love [EMAIL PROTECTED]
Cc: Maynard Johnson [EMAIL PROTECTED]
That looks weird. I doubt it's the right fix for the problem. Paul,
I remember this was discussed earlier, did we come up with a proper fix
already ?
Cheers,
Ben.
On Thu, 15 May 2008 10:20:44 +1000
Michael Ellerman [EMAIL PROTECTED] wrote:
__copy_from_user_inatomic() accepts any value for n, it just has a
special case for 1, 2, 4 and 8 - but it should still work for other
values.
The old code copied 24 bytes from sp, and the new code copies 8 bytes
from sp and 8 bytes from sp + 16 - so I don't see where the 48 bytes
comes in to it?
\ufeffAlso the comment is a little hard to parse, I think you mean Issue:
the .., but I read Issue as a verb in that sentence. And Don't read
more then should be than.
Signed-off-by: Andrew Morton [EMAIL PROTECTED]
---
arch/powerpc/oprofile/backtrace.c | 33 ++--
1 file changed, 27 insertions(+), 6 deletions(-)
diff -puN
arch/powerpc/oprofile/backtrace.c~powerpc-fix-for-oprofile-callgraph-for-power-64-bit-user-apps
arch/powerpc/oprofile/backtrace.c
---
a/arch/powerpc/oprofile/backtrace.c~powerpc-fix-for-oprofile-callgraph-for-power-64-bit-user-apps
+++ a/arch/powerpc/oprofile/backtrace.c
@@ -53,19 +53,40 @@ static unsigned int user_getsp32(unsigne
#ifdef CONFIG_PPC64
static unsigned long user_getsp64(unsigned long sp, int is_first)
{
- unsigned long stack_frame[3];
+ unsigned long stk_frm_lr;
+ unsigned long stk_frm_sp;
+ unsigned long size;
+
+ /* Issue the __copy_from_user_inatomic() third argument currently
+ * only takes sizes 1, 2, 4 or 8 bytes. Don't read more then the
+ * first 48 bytes of the stack frame. That is all that is
+ * guaranteed to exist. Reading more may cause the system to hang.
+ *
+ * 64 bit stack frame layout:
+ * 0-7 bytes is the pointer to previous stack
+ * 8-15 bytes condition register save area
+ * 16-23 bytes link register save area
+ */
+ size = sizeof(unsigned long);
+ if (!access_ok(VERIFY_READ, (void __user *)sp, size))
+ return 0;
- if (!access_ok(VERIFY_READ, (void __user *)sp, sizeof(stack_frame)))
+ if (__copy_from_user_inatomic(stk_frm_sp, (void __user *)sp,
+ size))
return 0;
- if (__copy_from_user_inatomic(stack_frame, (void __user *)sp,
- sizeof(stack_frame)))
+ /* get the LR from the user stack */
+ if (!access_ok(VERIFY_READ, (void __user *)(sp+16), size))
+ return 0;
+
+ if (__copy_from_user_inatomic(stk_frm_lr, (void __user *)(sp+16),
+ size))
return 0;
if (!is_first)
- oprofile_add_trace(STACK_LR64(stack_frame));
+ oprofile_add_trace(stk_frm_lr);
- return STACK_SP(stack_frame);
+ return stk_frm_sp;
}
#endif
_
___
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
Re: [patch 3/5] macintosh: therm_windtunnel: semaphore to mutex
On Mon, 2008-06-09 at 16:26 -0700, [EMAIL PROTECTED] wrote:
From: Daniel Walker [EMAIL PROTECTED]
Signed-off-by: Daniel Walker [EMAIL PROTECTED]
Signed-off-by: Andrew Morton [EMAIL PROTECTED]
Acked-by: Benjamin Herrenschmidt [EMAIL PROTECTED]
---
drivers/macintosh/therm_windtunnel.c | 16
1 file changed, 8 insertions(+), 8 deletions(-)
diff -puN
drivers/macintosh/therm_windtunnel.c~macintosh-therm_windtunnel-semaphore-to-mutex
drivers/macintosh/therm_windtunnel.c
---
a/drivers/macintosh/therm_windtunnel.c~macintosh-therm_windtunnel-semaphore-to-mutex
+++ a/drivers/macintosh/therm_windtunnel.c
@@ -62,7 +62,7 @@ static struct {
volatile intrunning;
struct task_struct *poll_task;
- struct semaphorelock;
+ struct mutexlock;
struct of_device*of_dev;
struct i2c_client *thermostat;
@@ -286,23 +286,23 @@ restore_regs( void )
static int control_loop(void *dummy)
{
- down(x.lock);
+ mutex_lock(x.lock);
setup_hardware();
- up(x.lock);
+ mutex_unlock(x.lock);
for (;;) {
msleep_interruptible(8000);
if (kthread_should_stop())
break;
- down(x.lock);
+ mutex_lock(x.lock);
poll_temp();
- up(x.lock);
+ mutex_unlock(x.lock);
}
- down(x.lock);
+ mutex_lock(x.lock);
restore_regs();
- up(x.lock);
+ mutex_unlock(x.lock);
return 0;
}
@@ -489,7 +489,7 @@ g4fan_init( void )
const struct apple_thermal_info *info;
struct device_node *np;
- init_MUTEX( x.lock );
+ mutex_init(x.lock);
if( !(np=of_find_node_by_name(NULL, power-mgt)) )
return -ENODEV;
_
___
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
Re: [patch 2/5] spufs: convert nopfn to fault
On Mon, 2008-06-09 at 16:26 -0700, [EMAIL PROTECTED] wrote: From: Nick Piggin [EMAIL PROTECTED] spufs: convert nopfn to fault Signed-off-by: Nick Piggin [EMAIL PROTECTED] Acked-by: Jeremy Kerr [EMAIL PROTECTED] Cc: Paul Mackerras [EMAIL PROTECTED] Acked-by: Benjamin Herrenschmidt [EMAIL PROTECTED] Signed-off-by: Andrew Morton [EMAIL PROTECTED] ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [patch 5/5] arch/powerpc/platforms/pseries/eeh_driver.c: fix warning
On Mon, 2008-06-09 at 16:26 -0700, [EMAIL PROTECTED] wrote: From: Andrew Morton [EMAIL PROTECTED] Fix this: /usr/src/devel/arch/powerpc/platforms/pseries/eeh_driver.c: In function 'print_device_node_tree': /usr/src/devel/arch/powerpc/platforms/pseries/eeh_driver.c:55: warning: ISO C90 forbids mixed declarations and code also make that function look like it's part of Linux. I mean, wtf are you guys up to down there?? The EEH code ... oh well. It does need some love... [EMAIL PROTECTED]: coding-style fixes] Acked-by: Benjamin Herrenschmidt [EMAIL PROTECTED] Cc: Paul Mackerras [EMAIL PROTECTED] Signed-off-by: Andrew Morton [EMAIL PROTECTED] --- ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] booting-without-of: add more bindings for FSL UPM driver
+ - chip-delay : may specify a delay value in milliseconds.
Delay for what? The binding should say. chip-delay is a bit
too generic name as well, it could be more descriptive perhaps.
The chip-delay property defines an appropriate maximum delay
time (tR) required for read operations if the R/B pin is not
connected.
Yeah. So please put that in the binding.
Shouldn't this be a property of the NAND device anyway, not the
NAND controller?
Strictly speaking, it's a property of the NAND device. Therefore it
should be inside the node [EMAIL PROTECTED], I thhink:
+ [EMAIL PROTECTED] {
+ #address-cells = 1;
+ #size-cells = 1;
+ chip-delay = 25; // in micro-seconds
Something like that, yes. You wrote milliseconds before; which is it?
And, a better property name, please.
Where should that be documented?
In the binding for nand devices. If there isn't any yet, it might be
best to include that with the binding for your nand controller (i.e.,
describe the whole sub node there).
Segher
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [patch 4/5] macintosh: media bay: semaphore to mutex
On Mon, 2008-06-09 at 16:26 -0700, [EMAIL PROTECTED] wrote:
From: Daniel Walker [EMAIL PROTECTED]
Signed-off-by: Daniel Walker [EMAIL PROTECTED]
Signed-off-by: Andrew Morton [EMAIL PROTECTED]
Acked-by: Benjamin Herrenschmidt [EMAIL PROTECTED]
---
drivers/macintosh/mediabay.c | 27 ++-
1 file changed, 14 insertions(+), 13 deletions(-)
diff -puN drivers/macintosh/mediabay.c~macintosh-media-bay-semaphore-to-mutex
drivers/macintosh/mediabay.c
--- a/drivers/macintosh/mediabay.c~macintosh-media-bay-semaphore-to-mutex
+++ a/drivers/macintosh/mediabay.c
@@ -21,6 +21,7 @@
#include linux/init.h
#include linux/ide.h
#include linux/kthread.h
+#include linux/mutex.h
#include asm/prom.h
#include asm/pgtable.h
#include asm/io.h
@@ -77,7 +78,7 @@ struct media_bay_info {
int index;
int cached_gpio;
int sleeping;
- struct semaphorelock;
+ struct mutexlock;
#ifdef CONFIG_BLK_DEV_IDE_PMAC
ide_hwif_t *cd_port;
void __iomem*cd_base;
@@ -459,27 +460,27 @@ int media_bay_set_ide_infos(struct devic
if (bay-mdev which_bay == bay-mdev-ofdev.node) {
int timeout = 5000, index = hwif-index;
- down(bay-lock);
+ mutex_lock(bay-lock);
bay-cd_port= hwif;
bay-cd_base= (void __iomem *) base;
bay-cd_irq = irq;
if ((MB_CD != bay-content_id) || bay-state != mb_up) {
- up(bay-lock);
+ mutex_unlock(bay-lock);
return 0;
}
printk(KERN_DEBUG Registered ide%d for media bay
%d\n, index, i);
do {
if (MB_IDE_READY(i)) {
bay-cd_index = index;
- up(bay-lock);
+ mutex_unlock(bay-lock);
return 0;
}
mdelay(1);
} while(--timeout);
printk(KERN_DEBUG Timeount waiting IDE in bay %d\n,
i);
- up(bay-lock);
+ mutex_unlock(bay-lock);
return -ENODEV;
}
}
@@ -616,10 +617,10 @@ static int media_bay_task(void *x)
while (!kthread_should_stop()) {
for (i = 0; i media_bay_count; ++i) {
- down(media_bays[i].lock);
+ mutex_lock(media_bays[i].lock);
if (!media_bays[i].sleeping)
media_bay_step(i);
- up(media_bays[i].lock);
+ mutex_unlock(media_bays[i].lock);
}
msleep_interruptible(MB_POLL_DELAY);
@@ -659,7 +660,7 @@ static int __devinit media_bay_attach(st
bay-index = i;
bay-ops = match-data;
bay-sleeping = 0;
- init_MUTEX(bay-lock);
+ mutex_init(bay-lock);
/* Init HW probing */
if (bay-ops-init)
@@ -697,10 +698,10 @@ static int media_bay_suspend(struct maci
if (state.event != mdev-ofdev.dev.power.power_state.event
(state.event PM_EVENT_SLEEP)) {
- down(bay-lock);
+ mutex_lock(bay-lock);
bay-sleeping = 1;
set_mb_power(bay, 0);
- up(bay-lock);
+ mutex_unlock(bay-lock);
msleep(MB_POLL_DELAY);
mdev-ofdev.dev.power.power_state = state;
}
@@ -719,12 +720,12 @@ static int media_bay_resume(struct macio
they seem to help the 3400 get it right.
*/
/* Force MB power to 0 */
- down(bay-lock);
+ mutex_lock(bay-lock);
set_mb_power(bay, 0);
msleep(MB_POWER_DELAY);
if (bay-ops-content(bay) != bay-content_id) {
printk(mediabay%d: content changed during sleep...\n,
bay-index);
- up(bay-lock);
+ mutex_unlock(bay-lock);
return 0;
}
set_mb_power(bay, 1);
@@ -740,7 +741,7 @@ static int media_bay_resume(struct macio
} while((bay-state != mb_empty)
(bay-state != mb_up));
bay-sleeping = 0;
- up(bay-lock);
+ mutex_unlock(bay-lock);
}
return 0;
}
_
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
Re: [patch 5/5] arch/powerpc/platforms/pseries/eeh_driver.c: fix warning
On Tue, 10 Jun 2008 09:47:02 +1000 Benjamin Herrenschmidt [EMAIL PROTECTED] wrote: On Mon, 2008-06-09 at 16:26 -0700, [EMAIL PROTECTED] wrote: From: Andrew Morton [EMAIL PROTECTED] Fix this: /usr/src/devel/arch/powerpc/platforms/pseries/eeh_driver.c: In function 'print_device_node_tree': /usr/src/devel/arch/powerpc/platforms/pseries/eeh_driver.c:55: warning: ISO C90 forbids mixed declarations and code also make that function look like it's part of Linux. I mean, wtf are you guys up to down there?? The EEH code ... oh well. It does need some love... Feel free to make the changelog more family-friendly. You can always tell how many build errors I fixed in the predecing six hours.. [EMAIL PROTECTED]: coding-style fixes] Acked-by: Benjamin Herrenschmidt [EMAIL PROTECTED] Thanks. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: zImage.chrp is getting gziped on Efika
This doesn't look right. I don't think vmlinux.strip should be 3.2GB for the Efika. rwxr-xr-x 1 jonsmirl jonsmirl 32429434 2008-06-09 20:12 vmlinux -rw-r--r-- 1 jonsmirl jonsmirl 61735424 2008-06-09 20:12 vmlinux.o -rwxr-xr-x 1 jonsmirl jonsmirl 322404 2008-06-08 21:11 vmlinux.strip -rwxr-xr-x 1 jonsmirl jonsmirl 3224175192 2008-06-09 20:12 vmlinux.strip.21504 -rw--- 1 jonsmirl jonsmirl2064384 2008-06-09 20:12 vmlinux.strip.21504.gz -rwxr-xr-x 1 jonsmirl jonsmirl4477568 2008-06-09 00:17 vmlinux.strip.gz -rw-r--r-- 1 jonsmirl jonsmirl 3224000765 2008-06-08 21:12 zImage.6451.o [EMAIL PROTECTED]:~/es$ -- Jon Smirl [EMAIL PROTECTED] ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [2.6 patch] drivers/macintosh/: possible cleanups
Hi Adrian,
On Tue, 10 Jun 2008 01:23:12 +0300 Adrian Bunk [EMAIL PROTECTED] wrote:
+++ b/drivers/macintosh/adbhid.c
@@ -75,7 +75,7 @@ static struct notifier_block adbhid_adb_notifier = {
#define ADB_KEY_POWER_OLD0x7e
#define ADB_KEY_POWER0x7f
-u16 adb_to_linux_keycodes[128] = {
+static u16 adb_to_linux_keycodes[128] = {
This could be const as well.
--
Cheers,
Stephen Rothwell[EMAIL PROTECTED]
http://www.canb.auug.org.au/~sfr/
pgpTsSEAiZFg7.pgp
Description: PGP signature
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [patch 1/5] powerpc: fix for OProfile callgraph for Power 64 bit user apps
On Tue, 2008-06-10 at 09:41 +1000, Benjamin Herrenschmidt wrote: On Mon, 2008-06-09 at 16:26 -0700, [EMAIL PROTECTED] wrote: From: Carl Love [EMAIL PROTECTED] Fix the 64 bit user code backtrace which currently may hang the system. Signed-off-by: Carl Love [EMAIL PROTECTED] Cc: Maynard Johnson [EMAIL PROTECTED] That looks weird. I doubt it's the right fix for the problem. Paul, I remember this was discussed earlier, did we come up with a proper fix already ? We decided there probably wasn't a bug there at all: http://ozlabs.org/pipermail/linuxppc-dev/2008-May/056449.html Haven't heard from Carl if he reproduced the hang and traced it to something else. 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: [patch 1/5] powerpc: fix for OProfile callgraph for Power 64 bit user apps
[EMAIL PROTECTED] writes: From: Carl Love [EMAIL PROTECTED] Fix the 64 bit user code backtrace which currently may hang the system. NAK - Carl withdrew this patch ages ago. Paul. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] [POWERPC] Free a PTE bit on ppc64 with 64K pages
On Thu, 2008-05-29 at 15:51 +1000, Benjamin Herrenschmidt wrote: This patch frees a PTE bit when using 64K pages on ppc64. This is done by getting rid of the separate _PAGE_HASHPTE bit. Instead, we just test if any of the 16 sub-page bits is set. For non-combo pages (ie. real 64K pages), we set SUB0 and the location encoding in that field. Signed-off-by: Benjamin Herrenschmidt [EMAIL PROTECTED] --- Please review and make sure I didn't miss something ... This doesn't build for CONFIG_PPC_64K_PAGES=n and CONFIG_PPC_HAS_HASH_64K=y, because the asm is protected by the latter but the header definitions are protected by the former. 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: [patch 1/1] fsldma: the MPC8377MDS board device tree node for fsldma driver
On Jun 9, 2008, at 6:29 PM, [EMAIL PROTECTED] wrote: From: Zhang Wei [EMAIL PROTECTED] The fsldma driver is tested on MPC8377MDS board. The patch adds fsldma driver support into MPC8377MDS device tree. Signed-off-by: Zhang Wei [EMAIL PROTECTED] Cc: Nelson, Shannon [EMAIL PROTECTED] Cc: Dan Williams [EMAIL PROTECTED] Cc: Kumar Gala [EMAIL PROTECTED] Cc: Paul Mackerras [EMAIL PROTECTED] Cc: Benjamin Herrenschmidt [EMAIL PROTECTED] Cc: Scott Wood [EMAIL PROTECTED] Cc: Li Yang [EMAIL PROTECTED] On Wed, 14 May 2008 18:28:08 -0500 Scott Wood [EMAIL PROTECTED] wrote: [EMAIL PROTECTED] wrote: From: Zhang Wei [EMAIL PROTECTED] According to booting-without-of.txt, the interrupts property should be repeated in each channel. The driver also needs to be fixed to remember whether it registered a DMA-block-level interrupt handler already, and not try to register a channel interrupt. Signed-off-by: Andrew Morton [EMAIL PROTECTED] --- arch/powerpc/boot/dts/mpc8377_mds.dts | 27 1 file changed, 27 insertions(+) This is already in Linus's tree as commit 3f346935f4f7141b0253ab0d8dfefb6e20ad08c3 - k ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
