Re: [PATCH] powerpc: i2c-ibm_iic register child nodes
Hi Sean, On Tue, 8 Jul 2008 14:46:09 -0400, Sean MacLennan wrote: This patch completes the conversion of the IBM IIC driver to an of-platform driver. It removes the index from the IBM IIC driver and makes it an unnumbered driver. It then calls of_register_i2c_devices to properly register all the child nodes in the DTS. Signed-off-by: Sean MacLennan [EMAIL PROTECTED] --- diff --git a/drivers/i2c/busses/i2c-ibm_iic.c b/drivers/i2c/busses/i2c-ibm_iic.c index 070f078..651f2f1 100644 --- a/drivers/i2c/busses/i2c-ibm_iic.c +++ b/drivers/i2c/busses/i2c-ibm_iic.c @@ -43,6 +43,7 @@ #include linux/i2c.h #include linux/i2c-id.h #include linux/of_platform.h +#include linux/of_i2c.h #include i2c-ibm_iic.h @@ -696,7 +697,7 @@ static int __devinit iic_probe(struct of_device *ofdev, struct device_node *np = ofdev-node; struct ibm_iic_private *dev; struct i2c_adapter *adap; - const u32 *indexp, *freq; + const u32 *freq; int ret; dev = kzalloc(sizeof(*dev), GFP_KERNEL); @@ -707,14 +708,6 @@ static int __devinit iic_probe(struct of_device *ofdev, dev_set_drvdata(ofdev-dev, dev); - indexp = of_get_property(np, index, NULL); - if (!indexp) { - dev_err(ofdev-dev, no index specified\n); - ret = -EINVAL; - goto error_cleanup; - } - dev-idx = *indexp; - dev-vaddr = of_iomap(np, 0); if (dev-vaddr == NULL) { dev_err(ofdev-dev, failed to iomap device\n); @@ -757,14 +750,16 @@ static int __devinit iic_probe(struct of_device *ofdev, adap-class = I2C_CLASS_HWMON | I2C_CLASS_SPD; adap-algo = iic_algo; adap-timeout = 1; - adap-nr = dev-idx; - ret = i2c_add_numbered_adapter(adap); + ret = i2c_add_adapter(adap); if (ret 0) { dev_err(ofdev-dev, failed to register i2c adapter\n); goto error_cleanup; } + /* Now register all the child nodes */ + of_register_i2c_devices(adap, np); + dev_info(ofdev-dev, using %s mode\n, dev-fast_mode ? fast (400 kHz) : standard (100 kHz)); Looks OK. As I already have patches touching drivers/i2c/busses/i2c-ibm_iic.c in my tree, I'm taking this patch also. I will push it upstream during the 2.6.27 merge window. Thanks, -- Jean Delvare ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[BUG] fec_mpc52xx: Don't call mpc52xx_fec_reset() in ISR
Hello, today, I was debugging a kernel crash on a board with a MPC5200B using 2.6.26-rc9. I found the following code in drivers/net/fec_mpc52xx.c: static irqreturn_t mpc52xx_fec_interrupt(int irq, void *dev_id) { [...] /* on fifo error, soft-reset fec */ if (ievent (FEC_IEVENT_RFIFO_ERROR | FEC_IEVENT_XFIFO_ERROR)) { if (net_ratelimit() (ievent FEC_IEVENT_RFIFO_ERROR)) dev_warn(dev-dev, FEC_IEVENT_RFIFO_ERROR\n); if (net_ratelimit() (ievent FEC_IEVENT_XFIFO_ERROR)) dev_warn(dev-dev, FEC_IEVENT_XFIFO_ERROR\n); mpc52xx_fec_reset(dev); netif_wake_queue(dev); return IRQ_HANDLED; } [...] } Calling mpc52xx_fec_reset() from interrupt context is bad, at least because a) it calls phy_write, which contains BUG_ON(in_interrupt()) b) it calls mpc52xx_fec_hw_init, which has a delay-loop to check if the reset was successful (1..50 us) I assume the proper thing to do is to set a flag in the ISR and handle the soft reset later in some other context. Having never dealt with the network core and its drivers so far, I am not sure which place would be the right one to perform the soft reset. To not make things worse, I hope people with more insight to network stuff can deliver a suitable solution to this problem. All the best, Wolfram -- Dipl.-Ing. Wolfram Sang | http://www.pengutronix.de Pengutronix - Linux Solutions for Science and Industry signature.asc Description: Digital signature ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [RFC][WIP][PATCH] powerpc: Refactor device bindings
On Jul 9, 2008, at 8:52 PM, David Gibson wrote: On Tue, Jul 08, 2008 at 08:20:56AM -0500, Kumar Gala wrote: Moved Freescale SoC related bindings out of booting-without-of.txt and into their own files. Signed-off-by: Kumar Gala [EMAIL PROTECTED] Acked-by: David Gibson [EMAIL PROTECTED] Of course, what I'd *really* like to do is to get a website / wiki set up somewhere to be the definitive home of all bindings, but I don't think it's going to happen any time real soon. agreed, I know there has been some talk of power.org trying to do this, but not sure what happened there. - k ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: Please pull from 'powerpc-next' branch
On Jul 9, 2008, at 12:13 PM, Stephen Rothwell wrote: Hi Kumar, On Wed, 9 Jul 2008 08:13:03 -0500 (CDT) Kumar Gala [EMAIL PROTECTED] wrote: Please pull from 'powerpc-next' branch of master.kernel.org:/pub/scm/linux/kernel/git/galak/dts.git powerpc- next $ git ls-remote ssh://master.kernel.org/pub/scm/linux/kernel/git/galak/dts.git fatal: '/pub/scm/linux/kernel/git/galak/dts.git': unable to chdir or not a git archive fatal: The remote end hung up unexpectedly Did you mean .../powerpc.git? yes. the script I use was run from the wrong dir. Also, the master branch of that tree has the same problem I came up against in linux-next today: include/asm-powerpc/pgtable-ppc64.h mismerges between Linus' tree and the Paul's tree so you end up with two copies of huge_ptep_set_wrprotect. So you should amend the merge to remove one. Thanks, will fix up by hand. - k ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: latencytop support for powerpc?
On Thursday 10 July 2008, Chris Friesen wrote: Just wondering if anyone has looked at what it would take to support latency top on powerpc? Just guessing something like the patch below, not more that that, but without the bugs ;-). Haven't tested at all, so it will probably fall apart, but give it a try if you like. Subject: powerpc: support for latencytop Implement save_stack_trace_tsk on powerpc, so that we can run with latencytop. Signed-off-by: Arnd Bergmann [EMAIL PROTECTED] diff --git a/arch/powerpc/Kconfig b/arch/powerpc/Kconfig index ff5217a..b1fd369 100644 --- a/arch/powerpc/Kconfig +++ b/arch/powerpc/Kconfig @@ -53,6 +53,9 @@ config STACKTRACE_SUPPORT bool default y +config HAVE_LATENCYTOP_SUPPORT + def_bool y + config TRACE_IRQFLAGS_SUPPORT bool depends on PPC64 diff --git a/arch/powerpc/kernel/stacktrace.c b/arch/powerpc/kernel/stacktrace.c index 9861f17..2b8c14d 100644 --- a/arch/powerpc/kernel/stacktrace.c +++ b/arch/powerpc/kernel/stacktrace.c @@ -10,19 +10,18 @@ * 2 of the License, or (at your option) any later version. */ +#include linux/module.h #include linux/sched.h #include linux/stacktrace.h #include asm/ptrace.h +#include asm/processor.h /* * Save stack-backtrace addresses into a stack_trace buffer. */ -void save_stack_trace(struct stack_trace *trace) +static void save_context_stack(struct stack_trace *trace, unsigned long sp, + struct task_struct *tsk, int savesched) { - unsigned long sp; - - asm(mr %0,1 : =r (sp)); - for (;;) { unsigned long *stack = (unsigned long *) sp; unsigned long newsp, ip; @@ -33,10 +32,12 @@ void save_stack_trace(struct stack_trace *trace) newsp = stack[0]; ip = stack[STACK_FRAME_LR_SAVE]; - if (!trace-skip) - trace-entries[trace-nr_entries++] = ip; - else - trace-skip--; + if (savesched || !in_sched_functions(ip)) { + if (!trace-skip) + trace-entries[trace-nr_entries++] = ip; + else + trace-skip--; + } if (trace-nr_entries = trace-max_entries) return; @@ -44,4 +45,19 @@ void save_stack_trace(struct stack_trace *trace) sp = newsp; } } + +void save_stack_trace(struct stack_trace *trace) +{ + unsigned long sp; + + asm(mr %0,1 : =r (sp)); + + save_context_stack(trace, sp, current, 1); +} EXPORT_SYMBOL_GPL(save_stack_trace); + +void save_stack_trace_tsk(struct task_struct *tsk, struct stack_trace *trace) +{ + save_context_stack(trace, tsk-thread.regs-gpr[1], tsk, 0); +} +EXPORT_SYMBOL_GPL(save_stack_trace_tsk); ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH] powerpc: support for latencytop
Implement save_stack_trace_tsk on powerpc, so that we can run with latencytop. Signed-off-by: Arnd Bergmann [EMAIL PROTECTED] --- On Thursday 10 July 2008, Arnd Bergmann wrote: Just guessing something like the patch below, not more that that, but without the bugs ;-). Obvious bug #1: needs to use the task we want to dump, not 'current'. diff --git a/arch/powerpc/Kconfig b/arch/powerpc/Kconfig index ff5217a..b1fd369 100644 --- a/arch/powerpc/Kconfig +++ b/arch/powerpc/Kconfig @@ -53,6 +53,9 @@ config STACKTRACE_SUPPORT bool default y +config HAVE_LATENCYTOP_SUPPORT + def_bool y + config TRACE_IRQFLAGS_SUPPORT bool depends on PPC64 diff --git a/arch/powerpc/kernel/stacktrace.c b/arch/powerpc/kernel/stacktrace.c index 9861f17..6a4fb00 100644 --- a/arch/powerpc/kernel/stacktrace.c +++ b/arch/powerpc/kernel/stacktrace.c @@ -10,33 +10,34 @@ * 2 of the License, or (at your option) any later version. */ +#include linux/module.h #include linux/sched.h #include linux/stacktrace.h #include asm/ptrace.h +#include asm/processor.h /* * Save stack-backtrace addresses into a stack_trace buffer. */ -void save_stack_trace(struct stack_trace *trace) +static void save_context_stack(struct stack_trace *trace, unsigned long sp, + struct task_struct *tsk, int savesched) { - unsigned long sp; - - asm(mr %0,1 : =r (sp)); - for (;;) { unsigned long *stack = (unsigned long *) sp; unsigned long newsp, ip; - if (!validate_sp(sp, current, STACK_FRAME_OVERHEAD)) + if (!validate_sp(sp, tsk, STACK_FRAME_OVERHEAD)) return; newsp = stack[0]; ip = stack[STACK_FRAME_LR_SAVE]; - if (!trace-skip) - trace-entries[trace-nr_entries++] = ip; - else - trace-skip--; + if (savesched || !in_sched_functions(ip)) { + if (!trace-skip) + trace-entries[trace-nr_entries++] = ip; + else + trace-skip--; + } if (trace-nr_entries = trace-max_entries) return; @@ -44,4 +45,19 @@ void save_stack_trace(struct stack_trace *trace) sp = newsp; } } + +void save_stack_trace(struct stack_trace *trace) +{ + unsigned long sp; + + asm(mr %0,1 : =r (sp)); + + save_context_stack(trace, sp, current, 1); +} EXPORT_SYMBOL_GPL(save_stack_trace); + +void save_stack_trace_tsk(struct task_struct *tsk, struct stack_trace *trace) +{ + save_context_stack(trace, tsk-thread.regs-gpr[1], tsk, 0); +} +EXPORT_SYMBOL_GPL(save_stack_trace_tsk); ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 0/2] Fix register misuse in drivers/net/phy/marvel.c
Welch, Martyn (GE EntSol, Intelligent Platforms) 写道: Wang Jian wrote: It may not be appropriate to post here instead of netdev, but I am using powerpc dev board and I think there will be someone here who has board to test. Wang Jian 写道: These 2 patches fixed misuse of register for 88e. Notice: These two patches didn't fix some auto selection problem yet. I will discuss the problem in seperate email. Hi, I have a board here with a pair of 88e's, though I'm not sure how to go about testing these patches. It's not the applying or compiling that the problem, but how to test it... Do you have any test case in mind? Hi, The problem I want to fix is: 1. Plug the fiber and start the board in u-boot, the fiber link is established, you can transfer data using fiber link; 2. boot the kernel (not fixed one), when you ifconfig ethX up (ethX uses 88e), the fiber link light goes off, the fiber link is lost; After apply the patch #1, for the step 2, you can ifconfig ethX w.x.y.z and fiber link is ok. You can use the fiber link to transfer data. I my case, the chip is in GMII mode. The patch #2 is obvious but I can't test it myself. BTW, the two patches doesn't fix the problem when you unplug the fiber then plug back. That is another problem I have _partially_ fixed by patch marvell_read_status(). ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [Cbe-oss-dev] [patch 02/02] powerpc/cell: add support for power button of future IBM cell blades
On Wednesday 09 July 2008, Benjamin Herrenschmidt wrote: On Wed, 2008-07-09 at 15:15 +0200, Arnd Bergmann wrote: Ugly, but doable, yes. I wonder if there is a way that we can trigger some interrupt from system_reset_exception context in order to get around the polling though. tasklets and workqueues unfortunately won't do us any good here because they also depend on disabling interrupts. You can trigger a DEC interrupt at any time but you don't have a nice hook to catch it. You can probably trigger an IPI to yourself using a special call to the iic, do we have any available number ? Yes, we are only using 4 out of 15 possible IPIs. Probably worth a try, but it might not be cleaner than your suggested solution. Arnd ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [BUG] fec_mpc52xx: Don't call mpc52xx_fec_reset() in ISR
On Thu, Jul 10, 2008 at 02:39:09PM +0200, Wolfram Sang wrote: Hello, today, I was debugging a kernel crash on a board with a MPC5200B using 2.6.26-rc9. I found the following code in drivers/net/fec_mpc52xx.c: snip I assume the proper thing to do is to set a flag in the ISR and handle the soft reset later in some other context. Having never dealt with the network core and its drivers so far, I am not sure which place would be the right one to perform the soft reset. To not make things worse, I hope people with more insight to network stuff can deliver a suitable solution to this problem. Thanks for the bug report. I'll take a look. g. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] powerpc: Fix problems with 32bit PPC's running with more than 2GB of RAM
On Jul 9, 2008, at 7:44 PM, Josh Boyer wrote: On Thu, 10 Jul 2008 06:39:39 +1000 Benjamin Herrenschmidt [EMAIL PROTECTED] wrote: On Wed, 2008-07-09 at 16:22 -0400, Josh Boyer wrote: On Thu, 10 Jul 2008 06:02:38 +1000 Benjamin Herrenschmidt [EMAIL PROTECTED] wrote: On Wed, 2008-07-09 at 15:44 +0200, Stefan Roese wrote: This patch enables 32bit PPC's (with 36bit physical address space, e.g. IBM/AMCC PPC44x) to run with more than 2GB of RAM. Mostly its just replacing types (unsigned long - phys_addr_t). Tested on an AMCC Katmai with 4GB of DDR2. Signed-off-by: Stefan Roese [EMAIL PROTECTED] But DMAs will break no ? How? Hrm... forget it. It's fine up to 4G of RAM... (ie. as long as DMA is below 32 bits). Right. We haven't really dealt with anything larger than 4 GiB, and we certainly aren't dealing with discontiguous DRAM due to I/O ranges. Are you *sure* you can see all 4GB? I thought we lost some of the 32- bit PCI address space for PCI IO.. Disclaimer: I'm no expert on PCI :) FYI, I'm *very* close to having swiotlb fully functional on powerpc to support larger RAM - I am able to boot with 6GB on 8641 right now. There are some bugs that I'm still shaking out - I hope to push this out in the next couple of weeks. Cheers, B ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH] powerpc: Xilinx: PS2: driver updates based on review
Review comments were incorporated to improve the driver. 1. Some data was eliminated that was not needed. 2. Renaming of variables for clarity. 3. Removed unneeded type casting. 4. Changed to use dev_err rather than other I/O. 5. Merged together some functions. 6. Added kerneldoc format to functions. Signed-off-by: Sadanand [EMAIL PROTECTED] Signed-off-by: John Linn [EMAIL PROTECTED] --- This patch is an incremental patch to be applied to [V3] powerpc: Xilinx: PS2: Added new XPS PS2 driver. drivers/input/serio/xilinx_ps2.c | 220 + 1 files changed, 125 insertions(+), 95 deletions(-) diff --git a/drivers/input/serio/xilinx_ps2.c b/drivers/input/serio/xilinx_ps2.c index e86f11b..eba46c7 100644 --- a/drivers/input/serio/xilinx_ps2.c +++ b/drivers/input/serio/xilinx_ps2.c @@ -58,23 +58,20 @@ /* Mask for all the Receive Interrupts */ #define XPS2_IPIXR_RX_ALL (XPS2_IPIXR_RX_OVF | XPS2_IPIXR_RX_ERR | \ - XPS2_IPIXR_RX_FULL) +XPS2_IPIXR_RX_FULL) /* Mask for all the Interrupts */ #define XPS2_IPIXR_ALL (XPS2_IPIXR_TX_ALL | XPS2_IPIXR_RX_ALL | \ - XPS2_IPIXR_WDT_TOUT) +XPS2_IPIXR_WDT_TOUT) /* Global Interrupt Enable mask */ #define XPS2_GIER_GIE_MASK 0x8000 struct xps2data { int irq; - u32 phys_addr; - u32 remap_size; spinlock_t lock; - u8 rxb; /* Rx buffer */ void __iomem *base_address; /* virt. address of control registers */ - unsigned int dfl; + unsigned int flags; struct serio serio; /* serio */ }; @@ -82,8 +79,13 @@ struct xps2data { /* XPS PS/2 data transmission calls */ // -/* - * xps2_recv() will attempt to receive a byte of data from the PS/2 port. +/** + * xps2_recv() - attempts to receive a byte from the PS/2 port. + * @drvdata: pointer to ps2 device private data structure + * @byte: address where the read data will be copied + * + * If there is any data available in the PS/2 receiver, this functions reads + * the data, otherwise it returns error. */ static int xps2_recv(struct xps2data *drvdata, u8 *byte) { @@ -105,7 +107,7 @@ static int xps2_recv(struct xps2data *drvdata, u8 *byte) /*/ static irqreturn_t xps2_interrupt(int irq, void *dev_id) { - struct xps2data *drvdata = (struct xps2data *)dev_id; + struct xps2data *drvdata = dev_id; u32 intr_sr; u8 c; int status; @@ -115,35 +117,28 @@ static irqreturn_t xps2_interrupt(int irq, void *dev_id) out_be32(drvdata-base_address + XPS2_IPISR_OFFSET, intr_sr); /* Check which interrupt is active */ - if (intr_sr XPS2_IPIXR_RX_OVF) { - printk(KERN_ERR %s: receive overrun error\n, - drvdata-serio.name); - } + if (intr_sr XPS2_IPIXR_RX_OVF) + dev_err(drvdata-serio.dev.parent, receive overrun error\n); if (intr_sr XPS2_IPIXR_RX_ERR) - drvdata-dfl |= SERIO_PARITY; + drvdata-flags |= SERIO_PARITY; if (intr_sr (XPS2_IPIXR_TX_NOACK | XPS2_IPIXR_WDT_TOUT)) - drvdata-dfl |= SERIO_TIMEOUT; + drvdata-flags |= SERIO_TIMEOUT; if (intr_sr XPS2_IPIXR_RX_FULL) { - status = xps2_recv(drvdata, drvdata-rxb); + status = xps2_recv(drvdata, c); /* Error, if a byte is not received */ if (status) { - printk(KERN_ERR - %s: wrong rcvd byte count (%d)\n, - drvdata-serio.name, status); + dev_err(drvdata-serio.dev.parent, + wrong rcvd byte count\n); } else { - c = drvdata-rxb; - serio_interrupt(drvdata-serio, c, drvdata-dfl); - drvdata-dfl = 0; + serio_interrupt(drvdata-serio, c, drvdata-flags); + drvdata-flags = 0; } } - if (intr_sr XPS2_IPIXR_TX_ACK) - drvdata-dfl = 0; - return IRQ_HANDLED; } @@ -151,8 +146,15 @@ static irqreturn_t xps2_interrupt(int irq, void *dev_id) /* serio callbacks */ /***/ -/* - * sxps2_write() sends a byte out through the PS/2 interface. +/** + * sxps2_write() - sends a byte out through the PS/2 port. + * @pserio:pointer to the serio structure of the PS/2 port + * @c: data that needs to be written to the PS/2 port + * + * This fucntion checks if the PS/2 transmitter is empty and sends a byte. + * Otherwise it returns error. Transmission fails only when nothing is connected + * to the PS/2 port. Thats why, we do not try to resend the data in case of a + *
Re: [PATCH 1/2] Convert i2c-mpc from a platform driver into a of_platform driver, V4
On Jul 9, 2008, at 1:22 PM, Grant Likely wrote: On Mon, Jun 30, 2008 at 5:01 PM, Jon Smirl [EMAIL PROTECTED] wrote: Convert i2c-mpc to an of_platform driver. Utilize the code in drivers/of-i2c.c to make i2c modules dynamically loadable by the device tree. Timur, can you please test this one on an 83xx platform? It works on 5200, but I want to make sure 83xx doesn't break before I pick it up. I'm on vacation this week, so I'll have to deal with it next week, after I've handled higher-priority issues. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Making __copy_tofrom_user more readable for powerpc (arch/powerpc/lib/copy_32.S)
Hi all, I am trying to optimize the __copy_tofrom_user function for PPC4xx, and I would want to know why the exception handling code has been made so complicated. All the fixup code should do is to store the number of bytes that failed in copy in r3 and return back. The current code tries to copy one byte at a time after read fault. I don't understand why that is necessary. It then clears out the destination. All these logic has made the code very unfriendly to read. I have a version which just keeps a count of bytes copied till any fault happened. Then for any exception, I just substract this value from the total number of bytes to be copied, and store in r3 and return back. This is the common fixup code for all paths. It makes the code much more readable like other architectures (eg. x86). My questions are: 1) Why do we need to distinguish between load and store failure? If either load or store fails, the copy did not go thru. But the code sets r9 to 0 for load failure, and r9 to 1 for write failure. Why do we need to care for that? 2) For read failure, why do we clear out the destination? Other architecture don't do that. I would appreciate any comments. I will submit my patch later. Thanks, Prodyut ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: powerpc/cell/cpufreq: add spu aware cpufreq governor
On Tue, Jul 08, 2008 at 11:27:28AM -0400, Dave Jones wrote: On Tue, Jul 08, 2008 at 08:43:43AM +0200, Arnd Bergmann wrote: On Monday 07 July 2008, Dave Jones wrote: One question I do have though, is how userspace scripts are supposed to know they're to echo cbe_spu_governor into the relevant parts of sysfs. I've not used anything with a cell. Do they expose the SPUs as regular CPUs, or do they show up in a different part of the tree? An SPU is very different from a CPU from the user perspective. SPUs show up in /sys/devices/system/spus, and if a user wants to access them, the spufs file system needs to be mounted in the system, by convention on /spu. Ok, that should be fairly simple to write scripts for. Actually, cpufreq-set -g spu_governor should be enough. (BTW, do we really want this name?) Best, Dominik ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] powerpc: Xilinx: PS2: driver updates based on review
John == John Linn [EMAIL PROTECTED] writes: Review comments were incorporated to improve the driver. 1. Some data was eliminated that was not needed. 2. Renaming of variables for clarity. 3. Removed unneeded type casting. 4. Changed to use dev_err rather than other I/O. 5. Merged together some functions. 6. Added kerneldoc format to functions. Signed-off-by: Sadanand [EMAIL PROTECTED] Signed-off-by: John Linn [EMAIL PROTECTED] If the minor issues below gets fixed: Acked-by: Peter Korsgaard [EMAIL PROTECTED] This patch is an incremental patch to be applied to [V3] powerpc: Xilinx: PS2: Added new XPS PS2 driver. drivers/input/serio/xilinx_ps2.c | 220 + 1 files changed, 125 insertions(+), 95 deletions(-) diff --git a/drivers/input/serio/xilinx_ps2.c b/drivers/input/serio/xilinx_ps2.c index e86f11b..eba46c7 100644 --- a/drivers/input/serio/xilinx_ps2.c +++ b/drivers/input/serio/xilinx_ps2.c @@ -58,23 +58,20 @@ /* Mask for all the Receive Interrupts */ #define XPS2_IPIXR_RX_ALL (XPS2_IPIXR_RX_OVF | XPS2_IPIXR_RX_ERR | \ -XPS2_IPIXR_RX_FULL) + XPS2_IPIXR_RX_FULL) /* Mask for all the Interrupts */ #define XPS2_IPIXR_ALL (XPS2_IPIXR_TX_ALL | XPS2_IPIXR_RX_ALL | \ -XPS2_IPIXR_WDT_TOUT) + XPS2_IPIXR_WDT_TOUT) /* Global Interrupt Enable mask */ #define XPS2_GIER_GIE_MASK 0x8000 struct xps2data { int irq; -u32 phys_addr; -u32 remap_size; spinlock_t lock; -u8 rxb; /* Rx buffer */ void __iomem *base_address; /* virt. address of control registers */ -unsigned int dfl; +unsigned int flags; struct serio serio; /* serio */ }; @@ -82,8 +79,13 @@ struct xps2data { /* XPS PS/2 data transmission calls */ // -/* - * xps2_recv() will attempt to receive a byte of data from the PS/2 port. +/** + * xps2_recv() - attempts to receive a byte from the PS/2 port. + * @drvdata:pointer to ps2 device private data structure + * @byte: address where the read data will be copied + * + * If there is any data available in the PS/2 receiver, this functions reads + * the data, otherwise it returns error. */ static int xps2_recv(struct xps2data *drvdata, u8 *byte) { @@ -105,7 +107,7 @@ static int xps2_recv(struct xps2data *drvdata, u8 *byte) /*/ static irqreturn_t xps2_interrupt(int irq, void *dev_id) { -struct xps2data *drvdata = (struct xps2data *)dev_id; +struct xps2data *drvdata = dev_id; u32 intr_sr; u8 c; int status; @@ -115,35 +117,28 @@ static irqreturn_t xps2_interrupt(int irq, void *dev_id) out_be32(drvdata-base_address + XPS2_IPISR_OFFSET, intr_sr); /* Check which interrupt is active */ -if (intr_sr XPS2_IPIXR_RX_OVF) { -printk(KERN_ERR %s: receive overrun error\n, -drvdata-serio.name); -} +if (intr_sr XPS2_IPIXR_RX_OVF) +dev_err(drvdata-serio.dev.parent, receive overrun error\n); if (intr_sr XPS2_IPIXR_RX_ERR) -drvdata-dfl |= SERIO_PARITY; +drvdata-flags |= SERIO_PARITY; if (intr_sr (XPS2_IPIXR_TX_NOACK | XPS2_IPIXR_WDT_TOUT)) -drvdata-dfl |= SERIO_TIMEOUT; +drvdata-flags |= SERIO_TIMEOUT; if (intr_sr XPS2_IPIXR_RX_FULL) { -status = xps2_recv(drvdata, drvdata-rxb); +status = xps2_recv(drvdata, c); /* Error, if a byte is not received */ if (status) { -printk(KERN_ERR -%s: wrong rcvd byte count (%d)\n, -drvdata-serio.name, status); +dev_err(drvdata-serio.dev.parent, +wrong rcvd byte count\n); You used to print the byte count - Isn't that interesting debugging data? } else { -c = drvdata-rxb; -serio_interrupt(drvdata-serio, c, drvdata-dfl); -drvdata-dfl = 0; +serio_interrupt(drvdata-serio, c, drvdata-flags); +drvdata-flags = 0; } } -if (intr_sr XPS2_IPIXR_TX_ACK) -drvdata-dfl = 0; - return IRQ_HANDLED; } @@ -151,8 +146,15 @@ static irqreturn_t xps2_interrupt(int irq, void *dev_id) /* serio callbacks */ /***/ -/* - * sxps2_write() sends a byte out through the PS/2 interface. +/** + * sxps2_write() - sends a byte out through the PS/2 port. + * @pserio: pointer to the serio structure of the PS/2 port + * @c: data that
Re: [PATCH] mpc7448: add alias list to DTS, clean out old chosen node
Paul Gortmaker wrote: The mpc7448hpc2 board doesn't have an alias block like most of the other modern eval boards have. We need this block in order to have u-boot be able to make use of the CONFIG_OF_STDOUT_VIA_ALIAS (vs. having a hard coded node) in the future. Also remove the old, redundant chosen node. Of all the modern Freescale eval boards (incl. 83xx, 85xx, 86xx) this is the only one which still has it. Its presence also breaks with some older versions of u-boot, like 1.3.1 -- which try and insert a second chosen node. The chosen node is still required for output from the cuboot wrapper. -Scott ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] mpc7448: add alias list to DTS, clean out old chosen node
Scott Wood wrote: Paul Gortmaker wrote: The mpc7448hpc2 board doesn't have an alias block like most of the other modern eval boards have. We need this block in order to have u-boot be able to make use of the CONFIG_OF_STDOUT_VIA_ALIAS (vs. having a hard coded node) in the future. Also remove the old, redundant chosen node. Of all the modern Freescale eval boards (incl. 83xx, 85xx, 86xx) this is the only one which still has it. Its presence also breaks with some older versions of u-boot, like 1.3.1 -- which try and insert a second chosen node. The chosen node is still required for output from the cuboot wrapper. OK, so does that mean that the cuboot wrapper is explicitly not supported for all the 83xx, 85xx, and 86xx boards? Thanks, Paul. -Scott ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] mpc7448: add alias list to DTS, clean out old chosen node
Paul Gortmaker wrote: OK, so does that mean that the cuboot wrapper is explicitly not supported for all the 83xx, 85xx, and 86xx boards? No (except 86xx, which doesn't have cuboot, because it never existed in arch/ppc and thus there's no compatibility to maintain), it just means that chosen was never added to those dts files, and thus cuboot has no console output. -Scott ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: powerpc/cell/cpufreq: add spu aware cpufreq governor
On Thursday 10 July 2008, Dominik Brodowski wrote: Actually, cpufreq-set -g spu_governor should be enough. (BTW, do we really want this name?) Do you have a better suggestion for the name? I don't think there was a particularly strong reason to choose it over something else. Arnd ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] mpc7448: add alias list to DTS, clean out old chosen node
Scott Wood wrote: Paul Gortmaker wrote: OK, so does that mean that the cuboot wrapper is explicitly not supported for all the 83xx, 85xx, and 86xx boards? No (except 86xx, which doesn't have cuboot, because it never existed in arch/ppc and thus there's no compatibility to maintain), it just means that chosen was never added to those dts files, and thus cuboot has no console output. Also note that nothing stops the causal kernel booter from _starting_ with an arch/powerpc/boot/dts/ file, adding a node to it, and using _that_. jdl ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] mpc7448: add alias list to DTS, clean out old chosen node
Jon Loeliger wrote: Scott Wood wrote: Paul Gortmaker wrote: OK, so does that mean that the cuboot wrapper is explicitly not supported for all the 83xx, 85xx, and 86xx boards? No (except 86xx, which doesn't have cuboot, because it never existed in arch/ppc and thus there's no compatibility to maintain), it just means that chosen was never added to those dts files, and thus cuboot has no console output. Also note that nothing stops the causal kernel booter As opposed to the spontaneous kernel booter? :-) from _starting_ with an arch/powerpc/boot/dts/ file, adding a node to it, and using _that_. The casual user shouldn't need to make any changes, especially for the kernel's own dts files to work with the kernel's own wrapper. The decision on whether to put the chosen node in the device tree should be based on which version of u-boot it's more important to maintain compatibility with (for some platforms, no chosen-duplicating version of u-boot supported device trees on the platform), and what the consequences of each form of incompatibility are (e.g. no console output during the bootwrapper, versus no boot arguments or initrd in the kernel). -Scott ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[RFC] (almost) booting allyesconfig -- please don't poke super-io without request_region
After the following patch to mark the isa region busy and applying a few patches[1], I was able to kexec boot into an all-yes-config kernel from linux-next, with the following KCONFIG_ALLCONFIG file: # CONFIG_KALLSYMS_EXTRA_PASS is not set # CONFIG_CRASH_DUMP is not set CONFIG_PPC_EARLY_DEBUG_RTAS_CONSOLE=y # CONFIG_NSC_FIR is not set # CONFIG_SMC_IRCC_FIR is not set # CONFIG_ALI_FIR is not set # CONFIG_TCG_NSC is not set # CONFIG_TCG_ATMEL is not set # CONFIG_SENSORS_F71805F is not set # CONFIG_SENSORS_F71882FG is not set # CONFIG_SENSORS_F75375S is not set # CONFIG_SENSORS_IT87 is not set # CONFIG_SENSORS_PC87360 is not set # CONFIG_SENSORS_PC87427 is not set # CONFIG_SENSORS_DME1737 is not set # CONFIG_SENSORS_SMSC47M1 is not set # CONFIG_SENSORS_SMSC47B397 is not set # CONFIG_SENSORS_VT1211 is not set # CONFIG_SENSORS_W83627HF is not set # CONFIG_SENSORS_W83627EHF is not set While the first two might not be required, and the third is just selecting the right platform, it would be nice to get the drivers to play as well as the rest of the kernel. The drivers all are for super-io chips, either irda/FIR drivers or hwmon, and poke at isa ports without checking request_region. It would be great if these 17 super-io drivers would check for resource availability before poking at io ports. [not that I expect this to merge as it, but maybe insert-resource or something] [1] 3 section layout patches and the MTD DISKONCHIP patch, see linuxppc-dev for full list diff --git a/arch/powerpc/platforms/pseries/pci.c b/arch/powerpc/platforms/pseries/pci.c index 2c6ded2..db54620 100644 --- a/arch/powerpc/platforms/pseries/pci.c +++ b/arch/powerpc/platforms/pseries/pci.c @@ -58,8 +58,10 @@ DECLARE_PCI_FIXUP_HEADER(PCI_ANY_ID, PCI_ANY_ID, pcibios_name_device); static void __init pSeries_request_regions(void) { - if (!isa_io_base) + if (!isa_io_base) { + request_region(0x0,0x400,isa); return; + } request_region(0x20,0x20,pic1); request_region(0xa0,0x20,pic2); ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
mtd: remove __PPC__ hardcoded address from nand/diskonchip and devices/docprobe
Such a hardcoded address can cause a checkstop or machine check if the driver is in the kernel but the address is not acknowledged. Both drivers allow an address to be specified as either a module parameter or config option. Any future powerpc board should either use one of these methods or find the address in the device tree. Signed-off-by: Milton Miller [EMAIL PROTECTED] --- There is no powerpc defconfig that sets either CONFIG_DOC200{0,1*} nor CONFIG_MTD_NAND_DISKONCHIP in next-20080710. diff --git a/drivers/mtd/devices/docprobe.c b/drivers/mtd/devices/docprobe.c index 6e5d811..6e62922 100644 --- a/drivers/mtd/devices/docprobe.c +++ b/drivers/mtd/devices/docprobe.c @@ -76,8 +76,6 @@ static unsigned long __initdata doc_locations[] = { 0xe, 0xe2000, 0xe4000, 0xe6000, 0xe8000, 0xea000, 0xec000, 0xee000, #endif /* CONFIG_MTD_DOCPROBE_HIGH */ -#elif defined(__PPC__) - 0xe400, #else #warning Unknown architecture for DiskOnChip. No default probe locations defined #endif diff --git a/drivers/mtd/nand/diskonchip.c b/drivers/mtd/nand/diskonchip.c index cd4393c..765d4f0 100644 --- a/drivers/mtd/nand/diskonchip.c +++ b/drivers/mtd/nand/diskonchip.c @@ -52,8 +52,6 @@ static unsigned long __initdata doc_locations[] = { 0xe, 0xe2000, 0xe4000, 0xe6000, 0xe8000, 0xea000, 0xec000, 0xee000, #endif /* CONFIG_MTD_DOCPROBE_HIGH */ -#elif defined(__PPC__) - 0xe400, #else #warning Unknown architecture for DiskOnChip. No default probe locations defined #endif ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
powerpc: numa.c: always trim to lmb_end_of_DRAM
numa_enforce_memory_limit trys to be smart and only trim the memory it finds to lmb_end_of_DRAM when a memory limit is set. However, the early boot code may also limit memory when iommu=off is specified. When this happens, the page allocator is told of pages not in the linear mapping and gets a fatal DSI. Signed-off-by: Milton Miller [EMAIL PROTECTED] -- Previously this patch tried to check if iommu=off was specified, but it was requested that the check just be removed. http://patchwork.ozlabs.org/linuxppc/patch?id=11774 diff --git a/arch/powerpc/mm/numa.c b/arch/powerpc/mm/numa.c index cf4bffb..590406c 100644 --- a/arch/powerpc/mm/numa.c +++ b/arch/powerpc/mm/numa.c @@ -472,12 +472,10 @@ static unsigned long __init numa_enforce_memory_limit(unsigned long start, /* * We use lmb_end_of_DRAM() in here instead of memory_limit because * we've already adjusted it for the limit and it takes care of -* having memory holes below the limit. +* having memory holes below the limit. Also, in the case of +* iommu_is_off, memory_limit is not set but is implicitly enforced. */ - if (! memory_limit) - return size; - if (start + size = lmb_end_of_DRAM()) return size; ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
powerpc: pseries, cell: use cpu_thread_in_core in smp_init for of_spin_map
Replace a left over % 2 to be a check for the primary thread and update the comments. Note: We assume the secondary threads are not spinning, but they are actually spinning if we start via kexec. This means that we call rtas to spin up the secondary threads. If we get a bad return code from we skip bringing the cpu online, leaving the thread spinning on the paca. We don't handle this case in kexec, and will leave the thread wild during another kexec. Signed-off-by: Milton Miller [EMAIL PROTECTED] --- I added a debug print and manually verified the correct cpumask was generated on pSeries. I ran across the identical code in cell by the grep of System.map. diff --git a/arch/powerpc/platforms/cell/smp.c b/arch/powerpc/platforms/cell/smp.c index efb3964..c0d86e1 100644 --- a/arch/powerpc/platforms/cell/smp.c +++ b/arch/powerpc/platforms/cell/smp.c @@ -54,8 +54,8 @@ #endif /* - * The primary thread of each non-boot processor is recorded here before - * smp init. + * The Primary thread of each non-boot processor was started from the OF client + * interface by prom_hold_cpus and is spinning on secondary_hold_spinloop. */ static cpumask_t of_spin_map; @@ -208,11 +208,7 @@ void __init smp_init_cell(void) /* Mark threads which are still spinning in hold loops. */ if (cpu_has_feature(CPU_FTR_SMT)) { for_each_present_cpu(i) { - if (i % 2 == 0) - /* -* Even-numbered logical cpus correspond to -* primary threads. -*/ + if (cpu_thread_in_core(i) == 0) cpu_set(i, of_spin_map); } } else { diff --git a/arch/powerpc/platforms/pseries/smp.c b/arch/powerpc/platforms/pseries/smp.c index 9d8f8c8..c9337c7 100644 --- a/arch/powerpc/platforms/pseries/smp.c +++ b/arch/powerpc/platforms/pseries/smp.c @@ -52,8 +52,8 @@ /* - * The primary thread of each non-boot processor is recorded here before - * smp init. + * The Primary thread of each non-boot processor was started from the OF client + * interface by prom_hold_cpus and is spinning on secondary_hold_spinloop. */ static cpumask_t of_spin_map; @@ -191,8 +191,7 @@ static void __devinit smp_pSeries_kick_cpu(int nr) static int smp_pSeries_cpu_bootable(unsigned int nr) { /* Special case - we inhibit secondary thread startup -* during boot if the user requests it. Odd-numbered -* cpus are assumed to be secondary threads. +* during boot if the user requests it. */ if (system_state SYSTEM_RUNNING cpu_has_feature(CPU_FTR_SMT) @@ -229,11 +228,7 @@ static void __init smp_init_pseries(void) /* Mark threads which are still spinning in hold loops. */ if (cpu_has_feature(CPU_FTR_SMT)) { for_each_present_cpu(i) { - if (i % 2 == 0) - /* -* Even-numbered logical cpus correspond to -* primary threads. -*/ + if (cpu_thread_in_core(i) == 0) cpu_set(i, of_spin_map); } } else { ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
powerpc: find and destroy possible stale kernel added properties
Because we copy the image using the kernels virtual memory system, we require kexec user space to avoid overwriting the static kernel image, tce tables, and the hash table. Kexec userspace gets this information by reading propertys the kernel adds, but does not filter these propertys when starting the next kernel. When the second kernel trys to add its propertys, the export via /proc/device-tree is hidden by the pre-existing but stale value from the flat tree. Kexec userspace reads the old property, allocates the new kernel at the old kernel's end, and gets rejected by the check Search and remove these stale properties before adding the new values. Signed-off-by: Milton Miller [EMAIL PROTECTED] --- While there is an override flag to tell kexec a minimum memory to use, that is a crude workaround and this should be applied to stable. diff --git a/arch/powerpc/kernel/machine_kexec_64.c b/arch/powerpc/kernel/machine_kexec_64.c index a168514..4bd8b4f 100644 --- a/arch/powerpc/kernel/machine_kexec_64.c +++ b/arch/powerpc/kernel/machine_kexec_64.c @@ -312,11 +312,24 @@ static struct property kernel_end_prop = { static void __init export_htab_values(void) { struct device_node *node; + struct property *prop; node = of_find_node_by_path(/chosen); if (!node) return; + /* remove any stale propertys so ours can be found */ + prop = of_find_property(node, kernel_end_prop.name, NULL); + if (prop) + prom_remove_property(node, prop); + prop = of_find_property(node, htab_base_prop.name, NULL); + if (prop) + prom_remove_property(node, prop); + prop = of_find_property(node, htab_size_prop.name, NULL); + if (prop) + prom_remove_property(node, prop); + + /* information needed by userspace when using default_machine_kexec */ kernel_end = __pa(_end); prom_add_property(node, kernel_end_prop); ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH] spufs: correct kcalloc usage
kcalloc is supposed to be called with the count as its first argument and the element size as the second. Signed-off-by: Milton Miller [EMAIL PROTECTED] --- Both arguments are size_t so does not affect correctness. This callsite is during module_init and therefore not performance critical. Another patch will optimize the case when the count is variable but the size is fixed. diff --git a/arch/powerpc/platforms/cell/spufs/sputrace.c b/arch/powerpc/platforms/cell/spufs/sputrace.c index 8c0e957..92d20e9 100644 --- a/arch/powerpc/platforms/cell/spufs/sputrace.c +++ b/arch/powerpc/platforms/cell/spufs/sputrace.c @@ -196,8 +196,7 @@ static int __init sputrace_init(void) struct proc_dir_entry *entry; int i, error = -ENOMEM; - sputrace_log = kcalloc(sizeof(struct sputrace), - bufsize, GFP_KERNEL); + sputrace_log = kcalloc(bufsize, sizeof(struct sputrace), GFP_KERNEL); if (!sputrace_log) goto out; ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] mpc7448: add alias list to DTS, clean out old chosen node
Paul Gortmaker wrote: Well, for the mpc7448hpc2, I can say for sure that there are chosen-duplicating versions of u-boot 1.3.1 in use -- since there wasn't a prebuilt, validated image newer than 1.1.3(?) available anywhere back some 6 months ago, I'd built 1.3.1 and made it available with our 2.6.21 kernel. OK, if that version's in widespread use it probably makes sense to remove the chosen node. If all the other boards run cuboot without console output, They don't *all* run without output -- see the 8xx, 82xx, and 4xx boards. -Scott ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [lm-sensors] [RFC] (almost) booting allyesconfig -- please don't poke super-io without request_region
On Jul 10, 2008, at 4:33 PM, Hans de Goede wrote: Milton Miller wrote: After the following patch to mark the isa region busy and applying a few patches[1], I was able to kexec boot into an all-yes-config kernel from linux-next, with the following KCONFIG_ALLCONFIG file: ... While the first two might not be required, and the third is just selecting the right platform, it would be nice to get the drivers to play as well as the rest of the kernel. The drivers all are for super-io chips, either irda/FIR drivers or hwmon, and poke at isa ports without checking request_region. Erm, The superio sensor drivers only poke the superio chip registers without request region during the probe phase, iow they try to detect the chip, using a widely document and standardized (part of isa pnp AFAIK) procedure on standardized ports. Let me try to explain a bit about superio chips, they have 2 superio control registers (an index and data register) with which things like a manufacturer and device id can be read, besides these id registers they also have a set of registers with config for different logical devices. Once the id is matched, the driver knows which logical device config to read, reads a (different) isa base address + range from the logical device config, and then does a request_region on the region actually used by the logical device. The superio control registers are thus a sort of pci configuration space if you want, doing a request_region on these is not such a good idea, as multiple drivers (for different logical devices within the superio device) may use these, so trying to gain exclusive access will lead to troubles. I hope with this info about the problem space, that you maybe have a suggestion on howto fix this? My point is that they are probing without even knowing that a such a IO range exists. These are the only drivers left in the tree that still do this. (At least that are not blocked on a powerpc allyesconfig for 64-bit, !CONFIG_VIRT_TO_BUS). One could make a superio driver, and create sub-devices for the IR, I2C, floppy, parallel, etc nodes. I would even accept a check_region (horrors!), it would impove the situation. But most other drivers do this by request_region, probe, then release the region afterwards. Besides, one could argue the superio region should be requested while probing, to prevent other cpus from poking at the super io chip at the same time. Think of it as missing locking. milton ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] mpc7448: add alias list to DTS, clean out old chosen node
Scott Wood wrote: Paul Gortmaker wrote: Well, for the mpc7448hpc2, I can say for sure that there are chosen-duplicating versions of u-boot 1.3.1 in use -- since there wasn't a prebuilt, validated image newer than 1.1.3(?) available anywhere back some 6 months ago, I'd built 1.3.1 and made it available with our 2.6.21 kernel. OK, if that version's in widespread use it probably makes sense to remove the chosen node. Sounds good - thanks. If all the other boards run cuboot without console output, They don't *all* run without output -- see the 8xx, 82xx, and 4xx boards. Yep, saw those when grepping around. My all was implicitly still referring to the newer 83xx/85xx/(86xx) reference boards, and whether it made sense to be adding chosen nodes to those so the cuImage had console output too -- if folks thought that was a better route, then I could see leaving the 7448 as-is, adding the nodes to the other boards, and just dealing with educating folks on the chosen-duplicating version issue as it comes up. Paul. -Scott ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 1/4] kdump : add support for ibm, dynamic-reconfiguration-memory for kexec/kdump
Hello Chandru, static int __init early_init_dt_scan_drconf_memory(unsigned long node) { - cell_t *dm, *ls; + cell_t *dm, *ls, *endp, *usm; unsigned long l, n, flags; u64 base, size, lmb_size; + char buf[32], t[8]; ls = (cell_t *)of_get_flat_dt_prop(node, ibm,lmb-size, l); if (ls == NULL || l dt_root_size_cells * sizeof(cell_t)) @@ -917,7 +918,33 @@ static int __init early_init_dt_scan_drc if ((base + size) 0x8000ul) size = 0x8000ul - base; } - lmb_add(base, size); + strcpy(buf, linux,usable-memory); + sprintf(t, %d, (int)n); + strcat(buf, t); + usm = (cell_t *)of_get_flat_dt_prop(node, +(const char *)buf, l); + if (usm != NULL) { + endp = usm + (l / sizeof(cell_t)); + while ((endp - usm) = (dt_root_addr_cells + +dt_root_size_cells)) { + base = dt_mem_next_cell(dt_root_addr_cells, +usm); + size = dt_mem_next_cell(dt_root_size_cells, +usm); + if (size == 0) + continue; + if (iommu_is_off) { + if ((base + size) 0x8000ul) + size = 0x8000ul - base; + } + lmb_add(base, size); + } + + /* Continue with next lmb entry */ + continue; + } else { + lmb_add(base, size); + } } I am still digging through the kexec tools but I don't think you want the processing of the linux,usable-memory property inside of the for (; n!= 0; --n) loop. This should be moved up so that it looks for the linux,usable-memory property and parses it, then if it is not found look for the ibm,dynamic-reconfiguration-memory property and parse it. There is no need to look for the linux-usable-memory property every time a piece of the ibm,dynamic-reconfiguration-memory property is parsed. -Nathan ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Making __copy_tofrom_user more readable for powerpc (arch/powerpc/lib/copy_32.S)
Hi all, I am trying to optimize the __copy_tofrom_user function for PPC4xx, and I would want to know why the exception handling code has been made so complicated. All the fixup code should do is to store the number of bytes that failed in copy in r3 and return back. The current code tries to copy one byte at a time after read fault. I don't understand why that is necessary. It then clears out the destination. All these logic has made the code very unfriendly to read. I have a version which just keeps a count of bytes copied till any fault happened. Then for any exception, I just substract this value from the total number of bytes to be copied, and store in r3 and return back. This is the common fixup code for all paths. It makes the fixup code much more readable like other architectures (eg. x86). My questions are: 1) Why do we need to distinguish between load and store failure? If either load or store fails, the copy did not go thru. But the code sets r9 to 0 for load failure, and r9 to 1 for write failure. Why do we need to care for that? 2) For read failure, why do we clear out the destination (lines 509 to 529 in arch/powerpc/lib/copy_32.S)? Other architecture don't do that. I would appreciate any comments. Thanks, Prodyut ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [RFC][WIP][PATCH] powerpc: Refactor device bindings
On Thu, Jul 10, 2008 at 08:22:53AM -0500, Kumar Gala wrote: On Jul 9, 2008, at 8:52 PM, David Gibson wrote: On Tue, Jul 08, 2008 at 08:20:56AM -0500, Kumar Gala wrote: Moved Freescale SoC related bindings out of booting-without-of.txt and into their own files. Signed-off-by: Kumar Gala [EMAIL PROTECTED] Acked-by: David Gibson [EMAIL PROTECTED] Of course, what I'd *really* like to do is to get a website / wiki set up somewhere to be the definitive home of all bindings, but I don't think it's going to happen any time real soon. agreed, I know there has been some talk of power.org trying to do this, but not sure what happened there. Yeah, neither do I. I should chase that up again, but I don't have the energy at the moment. -- David Gibson| I'll have my music baroque, and my code david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_ | _way_ _around_! http://www.ozlabs.org/~dgibson ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] mpc7448: add alias list to DTS, clean out old chosen node
On Fri, 2008-07-11 at 04:21 +0800, Paul Gortmaker wrote: The mpc7448hpc2 board doesn't have an alias block like most of the other modern eval boards have. We need this block in order to have u-boot be able to make use of the CONFIG_OF_STDOUT_VIA_ALIAS (vs. having a hard coded node) in the future. Also remove the old, redundant chosen node. Of all the modern Freescale eval boards (incl. 83xx, 85xx, 86xx) this is the only one which still has it. Its presence also breaks with some older versions of u-boot, like 1.3.1 -- which try and insert a second chosen node. Signed-off-by: Paul Gortmaker [EMAIL PROTECTED] --- Acked-by: Roy Zang [EMAIL PROTECTED] Roy ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [lm-sensors] [RFC] (almost) booting allyesconfig -- please don't poke super-io without request_region
Milton Miller wrote: After the following patch to mark the isa region busy and applying a few patches[1], I was able to kexec boot into an all-yes-config kernel from linux-next, with the following KCONFIG_ALLCONFIG file: # CONFIG_KALLSYMS_EXTRA_PASS is not set # CONFIG_CRASH_DUMP is not set CONFIG_PPC_EARLY_DEBUG_RTAS_CONSOLE=y # CONFIG_NSC_FIR is not set # CONFIG_SMC_IRCC_FIR is not set # CONFIG_ALI_FIR is not set # CONFIG_TCG_NSC is not set # CONFIG_TCG_ATMEL is not set # CONFIG_SENSORS_F71805F is not set # CONFIG_SENSORS_F71882FG is not set # CONFIG_SENSORS_F75375S is not set # CONFIG_SENSORS_IT87 is not set # CONFIG_SENSORS_PC87360 is not set # CONFIG_SENSORS_PC87427 is not set # CONFIG_SENSORS_DME1737 is not set # CONFIG_SENSORS_SMSC47M1 is not set # CONFIG_SENSORS_SMSC47B397 is not set # CONFIG_SENSORS_VT1211 is not set # CONFIG_SENSORS_W83627HF is not set # CONFIG_SENSORS_W83627EHF is not set While the first two might not be required, and the third is just selecting the right platform, it would be nice to get the drivers to play as well as the rest of the kernel. The drivers all are for super-io chips, either irda/FIR drivers or hwmon, and poke at isa ports without checking request_region. Erm, The superio sensor drivers only poke the superio chip registers without request region during the probe phase, iow they try to detect the chip, using a widely document and standardized (part of isa pnp AFAIK) procedure on standardized ports. Let me try to explain a bit about superio chips, they have 2 superio control registers (an index and data register) with which things like a manufacturer and device id can be read, besides these id registers they also have a set of registers with config for different logical devices. Once the id is matched, the driver knows which logical device config to read, reads a (different) isa base address + range from the logical device config, and then does a request_region on the region actually used by the logical device. The superio control registers are thus a sort of pci configuration space if you want, doing a request_region on these is not such a good idea, as multiple drivers (for different logical devices within the superio device) may use these, so trying to gain exclusive access will lead to troubles. I hope with this info about the problem space, that you maybe have a suggestion on howto fix this? Regards, Hans ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH v2] ibm_newemac: Add MII mode support to the EMAC RGMII bridge.
Benjamin Herrenschmidt wrote: On Tue, 2008-07-08 at 08:03 -0700, Grant Erickson wrote: This patch adds support to the RGMII handler in the EMAC driver for the MII PHY mode such that device tree entries of the form `phy-mode = mii;' are recognized and handled appropriately. While logically, in software, gmii and mii modes are the same, they are wired differently, so it makes sense to allow DTS authors to specify each explicitly. Signed-off-by: Grant Erickson [EMAIL PROTECTED] Acked-by: Benjamin Herrenschmidt [EMAIL PROTECTED] ACK Jeff, I'd like to apply that (and other EMAC patches for 2.6.27, do you have anything else pending ?) via my tree provided you give me your ack. The reason is that the multicast fix one is going that way as it touches other arch files, and subsequent ones are now likely to conflict. Let me know if that's ok with you in which case I'll stick your ack in there. Ok w/ me! ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev