Re: [PATCH] ps3: ps3-lpm.c compile fix
On Sun, 2 Nov 2008, Alexey Dobriyan wrote: drivers/ps3/ps3-lpm.c:838: error: implicit declaration of function 'get_hard_smp_processor_id' Signed-off-by: Alexey Dobriyan [EMAIL PROTECTED] --- drivers/ps3/ps3-lpm.c |1 + 1 file changed, 1 insertion(+) --- a/drivers/ps3/ps3-lpm.c +++ b/drivers/ps3/ps3-lpm.c @@ -22,6 +22,7 @@ #include linux/module.h #include linux/interrupt.h #include linux/uaccess.h +#include asm/smp.h #include linux/smp.h? #include asm/time.h #include asm/ps3.h #include asm/lv1call.h ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev With kind regards, Geert Uytterhoeven Software Architect Sony Techsoft Centre Europe The Corporate Village · Da Vincilaan 7-D1 · B-1935 Zaventem · Belgium Phone:+32 (0)2 700 8453 Fax: +32 (0)2 700 8622 E-mail: [EMAIL PROTECTED] Internet: http://www.sony-europe.com/ A division of Sony Europe (Belgium) N.V. VAT BE 0413.825.160 · RPR Brussels Fortis · BIC GEBABEBB · IBAN BE41293037680010___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] cell: fix ras.c compilation
On Sun, 2 Nov 2008, Alexey Dobriyan wrote: arch/powerpc/platforms/cell/ras.c:299: error: implicit declaration of function 'crash_shutdown_register' Signed-off-by: Alexey Dobriyan [EMAIL PROTECTED] --- arch/powerpc/platforms/cell/ras.c |1 + 1 file changed, 1 insertion(+) --- a/arch/powerpc/platforms/cell/ras.c +++ b/arch/powerpc/platforms/cell/ras.c @@ -16,6 +16,7 @@ #include linux/kexec.h #include linux/crash_dump.h +#include asm/kexec.h #include linux/kexec.h? With kind regards, Geert Uytterhoeven Software Architect Sony Techsoft Centre Europe The Corporate Village · Da Vincilaan 7-D1 · B-1935 Zaventem · Belgium Phone:+32 (0)2 700 8453 Fax: +32 (0)2 700 8622 E-mail: [EMAIL PROTECTED] Internet: http://www.sony-europe.com/ A division of Sony Europe (Belgium) N.V. VAT BE 0413.825.160 · RPR Brussels Fortis · BIC GEBABEBB · IBAN BE41293037680010___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [rfc][patch] powerpc: replace isync with lwsync
On Mon, Nov 03, 2008 at 04:32:22PM +1100, Paul Mackerras wrote: Nick Piggin writes: This is an interesting one for me. AFAIKS it is possible to use lwsync for a full barrier after a successful ll/sc operation, right? (or stop me here if I'm wrong). An lwsync would order subsequent loads after the lwarx/ldarx, and subsequent stores after the stcwx./stcdx., which should be good enough. OK, thanks for confirmation. isync followed by a branch I guess does something like puts a bubble into the pipeline until the branch retires? So it is probably always going to cost some cycles. I don't know about retires, but isync is going to stop following instructions from executing until the outcome of the branch is known. OK, I probably don't use the right terminology. I assume the branch retires when its outcome is known and the CPU starts executing the result. On machines that don't have lwsync we will still want to use isync (since the other alternative would be the full heavyweight sync). Your patch doesn't seem to do that. No, it's just a quick hack at the moment. I think your reply gets it past the not-totally-broken stage :) But at this point I can't justify sending such a change upstream based on a small improvement on G5. I would like to know about newer POWER CPUs, and even unreleased ones. If there is some reason lwsync gets relatively more constraining or difficult to execute than isync, then maybe this change is not useful. Thanks, Nick ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] cell: fix ras.c compilation
On Mon, 2008-11-03 at 09:20 +0100, Geert Uytterhoeven wrote: On Sun, 2 Nov 2008, Alexey Dobriyan wrote: arch/powerpc/platforms/cell/ras.c:299: error: implicit declaration of function 'crash_shutdown_register' Signed-off-by: Alexey Dobriyan [EMAIL PROTECTED] --- arch/powerpc/platforms/cell/ras.c |1 + 1 file changed, 1 insertion(+) --- a/arch/powerpc/platforms/cell/ras.c +++ b/arch/powerpc/platforms/cell/ras.c @@ -16,6 +16,7 @@ #include linux/kexec.h #include linux/crash_dump.h +#include asm/kexec.h #include linux/kexec.h? That struck me too. But the generic header only includes the arch one if CONFIG_KEXEC=y, and this code needs things from asm/kexec.h even when it =n. So I think this is the best fix. 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] cell: fix ras.c compilation
On Mon, 3 Nov 2008, Michael Ellerman wrote: On Mon, 2008-11-03 at 09:20 +0100, Geert Uytterhoeven wrote: On Sun, 2 Nov 2008, Alexey Dobriyan wrote: arch/powerpc/platforms/cell/ras.c:299: error: implicit declaration of function 'crash_shutdown_register' Signed-off-by: Alexey Dobriyan [EMAIL PROTECTED] --- arch/powerpc/platforms/cell/ras.c |1 + 1 file changed, 1 insertion(+) --- a/arch/powerpc/platforms/cell/ras.c +++ b/arch/powerpc/platforms/cell/ras.c @@ -16,6 +16,7 @@ #include linux/kexec.h #include linux/crash_dump.h +#include asm/kexec.h #include linux/kexec.h? That struck me too. But the generic header only includes the arch one if CONFIG_KEXEC=y, and this code needs things from asm/kexec.h even when it =n. So I think this is the best fix. IC. The real crash_shutdown_register() in arch/powerpc/kernel/crash.c only exists if CONFIG_KEXEC. So arch/powerpc/include/asm/kexec.h has a dummy one if !CONFIG_KEXEC. But as you point out you don't get to see asm/kexec.h if !CONFIG_KEXEC, so the dummy one doesn't help much... With kind regards, Geert Uytterhoeven Software Architect Sony Techsoft Centre Europe The Corporate Village · Da Vincilaan 7-D1 · B-1935 Zaventem · Belgium Phone:+32 (0)2 700 8453 Fax: +32 (0)2 700 8622 E-mail: [EMAIL PROTECTED] Internet: http://www.sony-europe.com/ A division of Sony Europe (Belgium) N.V. VAT BE 0413.825.160 · RPR Brussels Fortis · BIC GEBABEBB · IBAN BE41293037680010___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH V2] powerpc: Fix Book-E watchdog timer interval setting
Timur, I missed you posting. But you are right. My patch is ok for 4xx CPUs and touching the CONFIG_FSL_BOOKE path was not my intention. So for CONFIG_FSL_BOOKE WDTP_MASK should be WDTP(0). There is still a slightly difference between WDTP(0)=(3 30) | (0x3c 15) and (3 30) | (15 15). Can you check that please and I will resend my patch. Thanks for pointing that out. Matthias On Tuesday 23 September 2008 18:31, Timur Tabi wrote: On Tue, Sep 23, 2008 at 10:04 AM, Matthias Fuchs [EMAIL PROTECTED] wrote: #ifdef CONFIG_FSL_BOOKE #define WDTP(x)63-x)0x3)30)|(((63-x)0x3c)15)) +#define WDTP_MASK (WDTP(63)) WDTP(63) is 63-63)0x3)30)|(((63-63)0x3c)15)), which is equal to 0. Shouldn't WDTP_MASK be equal to (3 30) | (15 15)? ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: Connecting to PCI command write interrupt on 4xx platforms
Hi Ben, On Thursday 30 October 2008 21:15, Benjamin Herrenschmidt wrote: On Thu, 2008-10-30 at 11:58 +0100, Matthias Fuchs wrote: I need to connect to the PCI command write interrupt on a 440EPx platform. This is UIC0/int#5. Where should I add this interrupt in the DT? To the PCI node? In this case it will collide with the PCI interrupts. My application is a 440EPx on a PCI addon card. So the PCI node is disabled in the DT. Is there a way to get an interrupt number for request_irq() without querying the DT? What is this interrupt precisely ? What emits it ? If it's coming from The interrupt is emitted by the pci bridge when someone writes to the PCI_COMMAND register. We use it on PCI adapter hardware where the CPU is not the system CPU. In this case a host driver writes to the adapter's PCI_COMMAND register to trigger a remote interrupt that is handled by a special pci communication driver. Adding this interrupt to the PCI node would make (logical) sense. But on PCI adapter (add-in cards) designs we typically disable the PCI node of the DT to disable PCI PnP. This should not prevent us from adding the interrupt to the node but it looks a little bit weird to take an interrupt from a disabled node, right? the actual PCI bridge, then you can stick an interrupts property in the PCI host bridge node in the DT just fine. The PCI node already contains the interrupt-map for the PCI interrupts. Doesn't adding a further interrupt property cause some trouble with the PCI interrupts? Matthias Cheers, Ben. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] mpc52xx_uart: report serial errors to users v2
I regenerated the patch with respect to your comments.
Grant Likely wrote:
On Thu, Oct 30, 2008 at 12:14 AM, René Bürgel [EMAIL PROTECTED] wrote:
Hi! This patch adds the capability to the mpc52xx-uart to report framing
errors, parity errors, breaks and overruns to userspace. These values may be
requested in userspace by using the ioctl TIOCGICOUNT.
Signed-off-by: René Bürgel [EMAIL PROTECTED]
Looks mostly good. A few comments below. Make sure you CC: me when
you send the next version (which goes for all 5xxx patches).
g.
--
René Bürgel
Software Engineer
Unicontrol Systemtechnik GmbH
OT Dittersbach
Sachsenburger Weg 34
09669 Frankenberg
Tel.: 03 72 06/ 88 73 - 19
Fax: 03 72 06/ 88 73 - 60
E-Mail: [EMAIL PROTECTED]
Internet: www.unicontrol.de
Unicontrol Systemtechnik GmbH
Geschäftsführer: Dipl.-Ing. Siegfried Heinze
Sitz der Gesellschaft: Frankenberg
Registergericht: Amtsgericht Chemnitz, HRB 15 475
diff --git a/drivers/serial/mpc52xx_uart.c b/drivers/serial/mpc52xx_uart.c
index 6117d3d..2669aec 100644
--- a/drivers/serial/mpc52xx_uart.c
+++ b/drivers/serial/mpc52xx_uart.c
@@ -752,10 +752,15 @@ mpc52xx_uart_int_rx_chars(struct uart_port *port)
if (status MPC52xx_PSC_SR_RB) {
flag = TTY_BREAK;
uart_handle_break(port);
- } else if (status MPC52xx_PSC_SR_PE)
+ port-icount.brk++;
+ } else if (status MPC52xx_PSC_SR_PE) {
flag = TTY_PARITY;
- else if (status MPC52xx_PSC_SR_FE)
+ port-icount.parity++;
+ }
+ else if (status MPC52xx_PSC_SR_FE) {
flag = TTY_FRAME;
+ port-icount.frame++;
+ }
/* Clear error condition */
out_8(PSC(port)-command, MPC52xx_PSC_RST_ERR_STAT);
@@ -769,6 +774,7 @@ mpc52xx_uart_int_rx_chars(struct uart_port *port)
* affect the current character
*/
tty_insert_flip_char(tty, 0, TTY_OVERRUN);
+ port-icount.overrun++;
}
}
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 1/2] powerpc: add 16K/64K pages support for the 44x PPC32 architectures.
On Mon, 03 Nov 2008 11:43:54 +1100 Benjamin Herrenschmidt [EMAIL PROTECTED] wrote: Cropping the size of the memory node. That was simplest to do from the cuboot wrapper at the time. If marking it reserved via a reserve map is more elegant and correct, we could do that. But I will still like to know what about the other way is hairy please. I don't like it :-) Bad feeling ... don't like having a memory node entry that isn't aligned to some large power of two typically. Erm, ok. And does your heebie-geebies extend to people using the mem= parameter in a similar fashion? josh ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] i2c-cpm: Detect and report NAK right away instead of timing out.
Hi Ben, On Fri, Oct 31, 2008 at 05:29:25PM -0700, Mike Ditto wrote: Make the driver report an ENXIO error immediately upon NAK instead of waiting for another interrupt and getting a timeout. Signed-off-by: Mike Ditto [EMAIL PROTECTED] Acked-by: Jochen Friedrich [EMAIL PROTECTED] It looks ok, I'll merge and push out to linus with the s3c fixes. Thanks! Jochen -- To unsubscribe from this list: send the line unsubscribe linux-i2c in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Connecting to PCI command write interrupt on 4xx platforms
On Monday 03 November 2008 12:54, Stefan Roese wrote: On Monday 03 November 2008, Benjamin Herrenschmidt wrote: On Mon, 2008-11-03 at 10:10 +0100, Matthias Fuchs wrote: Adding this interrupt to the PCI node would make (logical) sense. But on PCI adapter (add-in cards) designs we typically disable the PCI node of the DT to disable PCI PnP. This should not prevent us from adding the interrupt to the node but it looks a little bit weird to take an interrupt from a disabled node, right? You can make a pci-endpoint node that isn't detected as a host bridge. In fact, I think we have some way to even tell in the DT not to activate host bridge function on 44x nowadays no ? I dont remember for sure but it's easy enough to add. Yes, it's there. But only for PCIe and not for PCI(-X). This patch added it for PCIe: [POWERPC] 4xx: Add endpoint support to 4xx PCIe driver It should be easy to add this for PCI and PCI-X as well. Yes, I already though about that. Currently I set the status attribute of the pci node to disabled when running as endpoint. But adding endpoint support similiar as you did for PCIe makes sense to me. Matthias ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] ps3: ps3-lpm.c compile fix
On Mon, Nov 03, 2008 at 09:20:28AM +0100, Geert Uytterhoeven wrote: On Sun, 2 Nov 2008, Alexey Dobriyan wrote: drivers/ps3/ps3-lpm.c:838: error: implicit declaration of function 'get_hard_smp_processor_id' Signed-off-by: Alexey Dobriyan [EMAIL PROTECTED] --- drivers/ps3/ps3-lpm.c |1 + 1 file changed, 1 insertion(+) --- a/drivers/ps3/ps3-lpm.c +++ b/drivers/ps3/ps3-lpm.c @@ -22,6 +22,7 @@ #include linux/module.h #include linux/interrupt.h #include linux/uaccess.h +#include asm/smp.h #include linux/smp.h? Nope, everybody else uses asm/smp.h. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: Connecting to PCI command write interrupt on 4xx platforms
On Monday 03 November 2008 11:57, Benjamin Herrenschmidt wrote: On Mon, 2008-11-03 at 10:10 +0100, Matthias Fuchs wrote: Adding this interrupt to the PCI node would make (logical) sense. But on PCI adapter (add-in cards) designs we typically disable the PCI node of the DT to disable PCI PnP. This should not prevent us from adding the interrupt to the node but it looks a little bit weird to take an interrupt from a disabled node, right? You can make a pci-endpoint node that isn't detected as a host bridge. In fact, I think we have some way to even tell in the DT not to activate host bridge function on 44x nowadays no ? I dont remember for sure but it's easy enough to add. We have endpoint support for PCIe and the possibility to disable PCI through the status attribute. the actual PCI bridge, then you can stick an interrupts property in the PCI host bridge node in the DT just fine. The PCI node already contains the interrupt-map for the PCI interrupts. Only relevant for master, not endpoint. Doesn't adding a further interrupt property cause some trouble with the PCI interrupts? Not for endpoint. I see. I will try to add endpoint support for PCI as well. I would like to have a single PCI node and let the device_type attribute decide if we are running in hostbridge or endpoint mode. Matthias ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [USB] powerpc: Workaround for the PPC440EPX USBH_23 errata [take 3]
On Mon, 3 Nov 2008, Vitaly Bordug wrote: A published errata for ppc440epx states, that when running Linux with both EHCI and OHCI modules loaded, the EHCI module experiences a fatal error when a high-speed device is connected to the USB2.0, and functions normally if OHCI module is not loaded. There used to be recommendation to use only hi-speed or full-speed devices with specific conditions, when respective module was unloaded. Later, it was observed that ohci suspend is enough to keep things going, and it was turned into workaround, as explained below. Please fix this patch so that it does not cause a build error on non-PowerPC architectures. Alan Stern ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: Connecting to PCI command write interrupt on 4xx platforms
On Monday 03 November 2008, Benjamin Herrenschmidt wrote: On Mon, 2008-11-03 at 10:10 +0100, Matthias Fuchs wrote: Adding this interrupt to the PCI node would make (logical) sense. But on PCI adapter (add-in cards) designs we typically disable the PCI node of the DT to disable PCI PnP. This should not prevent us from adding the interrupt to the node but it looks a little bit weird to take an interrupt from a disabled node, right? You can make a pci-endpoint node that isn't detected as a host bridge. In fact, I think we have some way to even tell in the DT not to activate host bridge function on 44x nowadays no ? I dont remember for sure but it's easy enough to add. Yes, it's there. But only for PCIe and not for PCI(-X). This patch added it for PCIe: [POWERPC] 4xx: Add endpoint support to 4xx PCIe driver It should be easy to add this for PCI and PCI-X as well. Best regards, Stefan ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: USB support on mpc5200 broken
On Wed, Sep 24, 2008 at 6:09 PM, Jon Smirl [EMAIL PROTECTED] wrote: On Wed, Sep 24, 2008 at 5:51 PM, Jon Smirl [EMAIL PROTECTED] wrote: USB is not working my hardware, so I booted my Efika and it's not working there either. This is with linus' current git. Can anyone verify this? Or know what happened to USB? USB is loading but it is not finding anything plugged in. lsusb doesn't show anything. Last time I noticed it was working was about ten days ago. I don't use it everyday. Efika is broken because of this: ohci-ppc-of.c... is_bigendian = of_device_is_compatible(dn, ohci-bigendian) || of_device_is_compatible(dn, ohci-be); Efika doesn't have either of those in it's compatible string. I finally got my Efika out and booted again. I do not see this issue. My efika shows compatible = ohci-bigendian, ohci-be, mpc5200-ohci, mpc5200-usb; I'm running stock firmware without any forth scripts. g. -- Grant Likely, B.Sc., P.Eng. Secret Lab Technologies Ltd. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] ndfc driver
Hi, I can confirm that this driver works fine on custom 4060EX board. The NAND is 256MiB Samsumg, with 2K page size. I had to modify U-boot to provide EBC ranges property for NAND, but otherwise it worked from the beginning. I didn't see any reaction to Sean's post, but this driver is important IMHO, since several in-tree 44X boards (e.g Canyonlands and Glacier) lack NAND support, and Warp uses old platform device model for its NAND. Felix Radensky Embedded Solutions Ltd. http://www.embedded-sol.com ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: USB support on mpc5200 broken
On Mon, Nov 3, 2008 at 10:41 AM, Grant Likely [EMAIL PROTECTED] wrote: On Wed, Sep 24, 2008 at 6:09 PM, Jon Smirl [EMAIL PROTECTED] wrote: On Wed, Sep 24, 2008 at 5:51 PM, Jon Smirl [EMAIL PROTECTED] wrote: USB is not working my hardware, so I booted my Efika and it's not working there either. This is with linus' current git. Can anyone verify this? Or know what happened to USB? USB is loading but it is not finding anything plugged in. lsusb doesn't show anything. Last time I noticed it was working was about ten days ago. I don't use it everyday. Efika is broken because of this: ohci-ppc-of.c... is_bigendian = of_device_is_compatible(dn, ohci-bigendian) || of_device_is_compatible(dn, ohci-be); Efika doesn't have either of those in it's compatible string. I finally got my Efika out and booted again. I do not see this issue. My efika shows compatible = ohci-bigendian, ohci-be, mpc5200-ohci, mpc5200-usb; It's been too long and I've lost track of what happened. -- Jon Smirl [EMAIL PROTECTED] ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH V2] powerpc: Fix Book-E watchdog timer interval setting
Matthias Fuchs wrote: Timur, I missed you posting. But you are right. My patch is ok for 4xx CPUs and touching the CONFIG_FSL_BOOKE path was not my intention. So for CONFIG_FSL_BOOKE WDTP_MASK should be WDTP(0). There is still a slightly difference between WDTP(0)=(3 30) | (0x3c 15) and (3 30) | (15 15). Can you check that please and I will resend my patch. Yes, I think WDTP(0) is correct for Book E. -- Timur Tabi Linux kernel developer at Freescale ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] gianfar: Omit TBI auto-negotiation based on device tree
On Thu, 2008-10-30 at 18:07 -0700, Trent Piepho wrote: But more relevant to your serdes problem, I also have a patch that prevents restarting serdes auto-negotiation if the serdes link is already up. My SGMII PHY will auto-negotiate, but it takes about 3 seconds. Avoiding an unnecessary 3 second auto-negotiation when the gianfar device is opened lets me cut my power-on to DHCP completion time in half. I wonder if this would also fix your problem, without needing to add the extra workaround? I just verified that your patch solves my problem without the need for my workaround. So at this point, it looks like we can drop this patch (Omit TBI auto-negotiation based on device tree). I tested when booting the kernel in U-Boot both via both TFTP and flash (I was worried that your patch may only fix things for the TFTP boot case, but that wasn't the case fortunately). Thanks for the patch! -- Nate Case [EMAIL PROTECTED] ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] ps3: ps3-lpm.c compile fix
Alexey Dobriyan wrote: On Mon, Nov 03, 2008 at 09:20:28AM +0100, Geert Uytterhoeven wrote: On Sun, 2 Nov 2008, Alexey Dobriyan wrote: drivers/ps3/ps3-lpm.c:838: error: implicit declaration of function 'get_hard_smp_processor_id' Signed-off-by: Alexey Dobriyan [EMAIL PROTECTED] Acked-by: Geoff Levand [EMAIL PROTECTED] --- a/drivers/ps3/ps3-lpm.c +++ b/drivers/ps3/ps3-lpm.c @@ -22,6 +22,7 @@ #include linux/module.h #include linux/interrupt.h #include linux/uaccess.h +#include asm/smp.h #include linux/smp.h? Nope, everybody else uses asm/smp.h. That doesn't quite seem like enough reason for me. Looking at the source, I see linux/smp.h only includes asm/smp.h when CONFIG_SMP=y, so we at least need to include asm/smp.h to get the get_hard_smp_processor_id def when CONFIG_SMP=n. -Geoff ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: Connecting to PCI command write interrupt on 4xx platforms
On Mon, 2008-11-03 at 10:10 +0100, Matthias Fuchs wrote: Adding this interrupt to the PCI node would make (logical) sense. But on PCI adapter (add-in cards) designs we typically disable the PCI node of the DT to disable PCI PnP. This should not prevent us from adding the interrupt to the node but it looks a little bit weird to take an interrupt from a disabled node, right? You can make a pci-endpoint node that isn't detected as a host bridge. In fact, I think we have some way to even tell in the DT not to activate host bridge function on 44x nowadays no ? I dont remember for sure but it's easy enough to add. the actual PCI bridge, then you can stick an interrupts property in the PCI host bridge node in the DT just fine. The PCI node already contains the interrupt-map for the PCI interrupts. Only relevant for master, not endpoint. Doesn't adding a further interrupt property cause some trouble with the PCI interrupts? Not for endpoint. Ben. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH] workaround for mpc52xx erratum #364 (serial may not be reset in break state)
Hi
This patch is a workaround for bug #364 found in the MPC52xx processor.
The errata document can be found under
http://www.freescale.com/files/32bit/doc/errata/MPC5200E.pdf?fpsp=1WT_TYPE=ErrataWT_VENDOR=FREESCALEWT_FILE_FORMAT=pdfWT_ASSET=Documentation
When a device with a low baudrate is connected to the serial port, but
the processor listens on a higher baudrate, it might falsely receive
breaks from the controller. During a break, the serial controller may
not be reset. The appended patch provides a workaround for that
situation by lowering the baudrate without resetting the controller and
waiting until no break is received anymore.
--
René Bürgel
Software Engineer
Unicontrol Systemtechnik GmbH
OT Dittersbach
Sachsenburger Weg 34
09669 Frankenberg
Tel.: 03 72 06/ 88 73 - 19
Fax: 03 72 06/ 88 73 - 60
E-Mail: [EMAIL PROTECTED]
Internet: www.unicontrol.de
Unicontrol Systemtechnik GmbH
Geschäftsführer: Dipl.-Ing. Siegfried Heinze
Sitz der Gesellschaft: Frankenberg
Registergericht: Amtsgericht Chemnitz, HRB 15 475
diff --git a/drivers/serial/mpc52xx_uart.c b/drivers/serial/mpc52xx_uart.c
index 6117d3d..929524b 100644
--- a/drivers/serial/mpc52xx_uart.c
+++ b/drivers/serial/mpc52xx_uart.c
@@ -496,6 +496,27 @@ mpc52xx_uart_break_ctl(struct uart_port *port, int ctl)
spin_unlock_irqrestore(port-lock, flags);
}
+/* macro with helper macros to safely reset rx which mustn't be done in break
state.
+ * This is a workaround for processor bug #364 described in MPC5200 (L25R)
Errata.
+ *
+ * The workaround resets the baudrate to 4800, waits for a stable state and
resets break state repeatedly if necessary
+ * optionally it can release the lock while waiting.
+ * 1 character at 4800 baud takes 2ms, 3ms should be enough for 1 character at
higher speed and 1 char at lowest
+ * works only with longer delays
+ */
+#define LOCK(code) code
+#define DONT_LOCK(code)
+#define mpc52xx_uart_reset_rx(LOCK)
\
+ out_8(psc-ctur,0x01);
\
+ out_8(psc-ctlr,0xae);
\
+ do {
\
+ out_8(psc-command,MPC52xx_PSC_RST_ERR_STAT);
\
+ LOCK(disable_irq(port-irq);
spin_unlock_irqrestore(port-lock, flags)); \
+ mdelay(10);
\
+ LOCK(spin_lock_irqsave(port-lock, flags);
enable_irq(port-irq)); \
+ } while ((in_be16(psc-mpc52xx_psc_status)) MPC52xx_PSC_SR_RB);
\
+ out_8(psc-command,MPC52xx_PSC_RST_RX);
+
static int
mpc52xx_uart_startup(struct uart_port *port)
{
@@ -510,7 +531,7 @@ mpc52xx_uart_startup(struct uart_port *port)
return ret;
/* Reset/activate the port, clear and enable interrupts */
- out_8(psc-command, MPC52xx_PSC_RST_RX);
+ mpc52xx_uart_reset_rx(DONT_LOCK);
out_8(psc-command, MPC52xx_PSC_RST_TX);
out_be32(psc-sicr, 0);/* UART mode DCD ignored */
@@ -529,7 +550,7 @@ mpc52xx_uart_shutdown(struct uart_port *port)
struct mpc52xx_psc __iomem *psc = PSC(port);
/* Shut down the port. Leave TX active if on a console port */
- out_8(psc-command, MPC52xx_PSC_RST_RX);
+ mpc52xx_uart_reset_rx(DONT_LOCK);
if (!uart_console(port))
out_8(psc-command, MPC52xx_PSC_RST_TX);
@@ -588,9 +609,6 @@ mpc52xx_uart_set_termios(struct uart_port *port, struct
ktermios *new,
/* Get the lock */
spin_lock_irqsave(port-lock, flags);
- /* Update the per-port timeout */
- uart_update_timeout(port, new-c_cflag, baud);
-
/* Do our best to flush TX RX, so we don't loose anything */
/* But we don't wait indefinitly ! */
j = 500;/* Maximum wait */
@@ -607,9 +625,12 @@ mpc52xx_uart_set_termios(struct uart_port *port, struct
ktermios *new,
Some chars may have been lost.\n);
/* Reset the TX RX */
- out_8(psc-command, MPC52xx_PSC_RST_RX);
+ mpc52xx_uart_reset_rx(LOCK);
out_8(psc-command, MPC52xx_PSC_RST_TX);
+ /* Update the per-port timeout */
+ uart_update_timeout(port, new-c_cflag, baud);
+
/* Send new mode settings */
out_8(psc-command, MPC52xx_PSC_SEL_MODE_REG_1);
out_8(psc-mode, mr1);
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 1/2] powerpc: add 16K/64K pages support for the 44x PPC32 architectures.
On Mon, 2008-11-03 at 11:43 +1100, Benjamin Herrenschmidt wrote:
Cropping the size of the memory node. That was simplest to do from the
cuboot wrapper at the time. If marking it reserved via a reserve map
is more elegant and correct, we could do that.
But I will still like to know what about the other way is hairy please.
I don't like it :-) Bad feeling ... don't like having a memory
node entry that isn't aligned to some large power of two typically.
More specifically, mm/bootmem.c seems to be making the implicit
assumption that memory size is an even multiple of PAGE_SIZE. With 4K
pages, 0x000 bytes of RAM fits; with 64K pages it does not.
Using the device tree reserve map stuff does indeed seem to solve the
problem. However, I really don't understand the layering in
arch/powerpc/boot at all, so I'll just put this patch out here and
people can play with wrappers and prototypes all they want:
powerpc/4xx: work around CHIP11 errata in a more PAGE_SIZE-friendly way
The current CHIP11 errata truncates the device tree memory node, and assumes a
4K page size. This breaks kernels with non-4K PAGE_SIZE.
Instead, use a device tree memory reservation to reserve only the 256 bytes
actually affected by the errata, leaving the total memory size unaltered.
Signed-off-by: Hollis Blanchard [EMAIL PROTECTED]
diff --git a/arch/powerpc/boot/4xx.c b/arch/powerpc/boot/4xx.c
--- a/arch/powerpc/boot/4xx.c
+++ b/arch/powerpc/boot/4xx.c
@@ -21,7 +21,7 @@
#include reg.h
#include dcr.h
-static unsigned long chip_11_errata(unsigned long memsize)
+static void chip_11_errata(unsigned long memsize)
{
unsigned long pvr;
@@ -31,13 +31,11 @@ static unsigned long chip_11_errata(unsi
case 0x4850:
case 0x48d0:
case 0x28d0:
- memsize -= 4096;
+ fdt_reserve_mem(memsize - 256, 256);
break;
default:
break;
}
-
- return memsize;
}
/* Read the 4xx SDRAM controller to get size of system memory. */
@@ -53,7 +51,7 @@ void ibm4xx_sdram_fixup_memsize(void)
memsize += SDRAM_CONFIG_BANK_SIZE(bank_config);
}
- memsize = chip_11_errata(memsize);
+ chip_11_errata(memsize);
dt_fixup_memory(0, memsize);
}
@@ -219,7 +217,7 @@ void ibm4xx_denali_fixup_memsize(void)
bank = 4; /* 4 banks */
memsize = cs * (1 (col+row)) * bank * dpath;
- memsize = chip_11_errata(memsize);
+ chip_11_errata(memsize);
dt_fixup_memory(0, memsize);
}
diff --git a/arch/powerpc/boot/libfdt-wrapper.c
b/arch/powerpc/boot/libfdt-wrapper.c
--- a/arch/powerpc/boot/libfdt-wrapper.c
+++ b/arch/powerpc/boot/libfdt-wrapper.c
@@ -167,6 +167,11 @@ static unsigned long fdt_wrapper_finaliz
return (unsigned long)fdt;
}
+int fdt_reserve_mem(unsigned long addr, unsigned long bytes)
+{
+ return fdt_add_mem_rsv(fdt, addr, bytes);
+}
+
void fdt_init(void *blob)
{
int err;
diff --git a/arch/powerpc/boot/ops.h b/arch/powerpc/boot/ops.h
--- a/arch/powerpc/boot/ops.h
+++ b/arch/powerpc/boot/ops.h
@@ -83,6 +83,7 @@ extern struct loader_info loader_info;
void start(void);
void fdt_init(void *blob);
+int fdt_reserve_mem(unsigned long addr, unsigned long bytes);
int serial_console_init(void);
int ns16550_console_init(void *devp, struct serial_console_data *scdp);
int mpsc_console_init(void *devp, struct serial_console_data *scdp);
--
Hollis Blanchard
IBM Linux Technology Center
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH 2/2] powerpc: enable kexec support on mpc8544ds
From: Sebastian Andrzej Siewior [EMAIL PROTECTED]
Signed-off-by: Sebastian Andrzej Siewior [EMAIL PROTECTED]
---
arch/powerpc/Kconfig |2 +-
arch/powerpc/platforms/85xx/mpc85xx_ds.c |6 ++
2 files changed, 7 insertions(+), 1 deletions(-)
diff --git a/arch/powerpc/Kconfig b/arch/powerpc/Kconfig
index 587da5e..c2c6a20 100644
--- a/arch/powerpc/Kconfig
+++ b/arch/powerpc/Kconfig
@@ -304,7 +304,7 @@ config ARCH_ENABLE_MEMORY_HOTREMOVE
config KEXEC
bool kexec system call (EXPERIMENTAL)
- depends on (PPC_PRPMC2800 || PPC_MULTIPLATFORM) EXPERIMENTAL
+ depends on (PPC_PRPMC2800 || PPC_MULTIPLATFORM || MPC85xx_DS)
EXPERIMENTAL
help
kexec is a system call that implements the ability to shutdown your
current kernel, and to start another kernel. It is like a reboot
diff --git a/arch/powerpc/platforms/85xx/mpc85xx_ds.c
b/arch/powerpc/platforms/85xx/mpc85xx_ds.c
index 3d5f21b..ae573e8 100644
--- a/arch/powerpc/platforms/85xx/mpc85xx_ds.c
+++ b/arch/powerpc/platforms/85xx/mpc85xx_ds.c
@@ -30,6 +30,7 @@
#include asm/udbg.h
#include asm/mpic.h
#include asm/i8259.h
+#include linux/kexec.h
#include sysdev/fsl_soc.h
#include sysdev/fsl_pci.h
@@ -227,6 +228,11 @@ define_machine(mpc8544_ds) {
.restart= fsl_rstcr_restart,
.calibrate_decr = generic_calibrate_decr,
.progress = udbg_progress,
+#ifdef CONFIG_KEXEC
+ .machine_kexec = default_machine_kexec,
+ .machine_kexec_prepare = default_machine_kexec_prepare,
+ .machine_crash_shutdown = default_machine_crash_shutdown,
+#endif
};
define_machine(mpc8572_ds) {
--
1.5.6.5
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Add kexec support for fsl-book-e [V2]
This is the kernel part of the kexec support for mpc8544 / FSL BookE. This version should fix the two things Ben noticed during his review. Changelog: v1: - Removed runtime detection between fsl-book-e no-mmu part - Marked the mmu-setup part as FSL BookE because it does not work on BooKE in general Sebastian ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH 1/2] powerpc: add kexec support on FSL-Book-E
From: Sebastian Andrzej Siewior [EMAIL PROTECTED] The relocate_new_kernel() code usually disables the MMU and the small code operates on physicall pages while moving the kernel to its final position. Book-E doesn't support this so a 1:1 mapping must be created. This patch adds support for FSL-BOOK-E implementation. Signed-off-by: Sebastian Andrzej Siewior [EMAIL PROTECTED] --- arch/powerpc/kernel/machine_kexec_32.c |5 +- arch/powerpc/kernel/misc_32.S | 129 ++- 2 files changed, 127 insertions(+), 7 deletions(-) diff --git a/arch/powerpc/kernel/machine_kexec_32.c b/arch/powerpc/kernel/machine_kexec_32.c index ae63a96..6fa8ed3 100644 --- a/arch/powerpc/kernel/machine_kexec_32.c +++ b/arch/powerpc/kernel/machine_kexec_32.c @@ -16,10 +16,10 @@ #include asm/hw_irq.h #include asm/io.h -typedef NORET_TYPE void (*relocate_new_kernel_t)( +typedef void (*relocate_new_kernel_t)( unsigned long indirection_page, unsigned long reboot_code_buffer, - unsigned long start_address) ATTRIB_NORET; + unsigned long start_address); /* * This is a generic machine_kexec function suitable at least for @@ -57,6 +57,7 @@ void default_machine_kexec(struct kimage *image) /* now call it */ rnk = (relocate_new_kernel_t) reboot_code_buffer; (*rnk)(page_list, reboot_code_buffer_phys, image-start); + BUG(); } int default_machine_kexec_prepare(struct kimage *image) diff --git a/arch/powerpc/kernel/misc_32.S b/arch/powerpc/kernel/misc_32.S index 7a6dfbc..68ab147 100644 --- a/arch/powerpc/kernel/misc_32.S +++ b/arch/powerpc/kernel/misc_32.S @@ -878,9 +878,120 @@ relocate_new_kernel: /* r4 = reboot_code_buffer */ /* r5 = start_address */ - li r0, 0 + mflrr28 + mr r29, r3 + mr r30, r4 + mr r31, r5 + +#ifdef CONFIG_FSL_BOOKE + + li r25, 0 /* phys kernel start (low) */ + +/* 1. Find the index of the entry we're executing in */ + bl invstr /* Find our address */ +invstr: + mflrr6 /* Make it accessible */ + mfmsr r7 + rlwinm r4,r7,27,31,31 /* extract MSR[IS] */ + mfspr r7, SPRN_PID0 + slwir7,r7,16 + or r7,r7,r4 + mtspr SPRN_MAS6,r7 + tlbsx 0,r6/* search MSR[IS], SPID=PID0 */ + mfspr r7,SPRN_MAS1 + andis. r7,r7,[EMAIL PROTECTED] + bne match_TLB /* +* We search just in PID0 because kernel's global mapping has to be +* there. We simply return to the caller if we didn't find the mapping +* since we didn't (yet) pass the point of no return. This should not +* happen. +*/ + mtlrr28 + blr + +match_TLB: + mfspr r7,SPRN_MAS0 + rlwinm r3,r7,16,20,31 /* Extract MAS0(Entry) */ + + mfspr r7,SPRN_MAS1/* Insure IPROT set */ + orisr7,r7,[EMAIL PROTECTED] + mtspr SPRN_MAS1,r7 + tlbwe + +/* 2. Invalidate all entries except the entry we're executing in */ + mfspr r9,SPRN_TLB1CFG + andi. r9,r9,0xfff + li r6,0/* Set Entry counter to 0 */ +1: + lis r7,0x1000 /* Set MAS0(TLBSEL) = 1 */ + rlwimi r7,r6,16,4,15 /* Setup MAS0 = TLBSEL | ESEL(r6) */ + mtspr SPRN_MAS0,r7 + tlbre + mfspr r7,SPRN_MAS1 + rlwinm r7,r7,0,2,31/* Clear MAS1 Valid and IPROT */ + cmpwr3,r6 + beq skpinv /* Dont update the current execution TLB */ + mtspr SPRN_MAS1,r7 + tlbwe + isync +skpinv: + addir6,r6,1 /* Increment */ + cmpwr6,r9 /* Are we done? */ + bne 1b /* If not, repeat */ + + /* Invalidate TLB0 */ + li r6,0x04 + tlbivax 0,r6 + TLBSYNC + /* Invalidate TLB1 */ + li r6,0x0c + tlbivax 0,r6 + TLBSYNC + +/* 3. Setup a temp mapping and jump to it */ + andi. r5, r3, 0x1 /* Find an entry not used and is non-zero */ + addir5, r5, 0x1 + lis r7, 0x1000 /* Set MAS0(TLBSEL) = 1 */ + rlwimi r7, r3, 16, 4, 15 /* Setup MAS0 = TLBSEL | ESEL(r3) */ + mtspr SPRN_MAS0,r7 + tlbre + + /* Just modify the entry ID and EPN for the temp mapping */ + lis r7,0x1000 /* Set MAS0(TLBSEL) = 1 */ + rlwimi r7,r5,16,4,15 /* Setup MAS0 = TLBSEL | ESEL(r5) */ + mtspr SPRN_MAS0,r7 + + xorir6,r4,1 /* Setup TMP mapping in the other Address space */ + slwir6,r6,12 + orisr6,r6,(MAS1_VALID|MAS1_IPROT)@h + ori
Re: [PATCH 1/2] powerpc: add 16K/64K pages support for the 44x PPC32 architectures.
On Mon, 03 Nov 2008 13:55:21 -0600
Hollis Blanchard [EMAIL PROTECTED] wrote:
On Mon, 2008-11-03 at 11:43 +1100, Benjamin Herrenschmidt wrote:
Cropping the size of the memory node. That was simplest to do from the
cuboot wrapper at the time. If marking it reserved via a reserve map
is more elegant and correct, we could do that.
But I will still like to know what about the other way is hairy please.
I don't like it :-) Bad feeling ... don't like having a memory
node entry that isn't aligned to some large power of two typically.
More specifically, mm/bootmem.c seems to be making the implicit
assumption that memory size is an even multiple of PAGE_SIZE. With 4K
pages, 0x000 bytes of RAM fits; with 64K pages it does not.
Hmm.. I dunno what to think about that. Again, how does mem= play
into this? (I will look myself in a bit, but if someone knows offhand
that would be nice..)
Using the device tree reserve map stuff does indeed seem to solve the
problem. However, I really don't understand the layering in
arch/powerpc/boot at all, so I'll just put this patch out here and
people can play with wrappers and prototypes all they want:
This actually looks pretty nice. I'll wait for David to Ack the fdt
parts.
josh
powerpc/4xx: work around CHIP11 errata in a more PAGE_SIZE-friendly way
The current CHIP11 errata truncates the device tree memory node, and assumes a
4K page size. This breaks kernels with non-4K PAGE_SIZE.
Instead, use a device tree memory reservation to reserve only the 256 bytes
actually affected by the errata, leaving the total memory size unaltered.
Signed-off-by: Hollis Blanchard [EMAIL PROTECTED]
diff --git a/arch/powerpc/boot/4xx.c b/arch/powerpc/boot/4xx.c
--- a/arch/powerpc/boot/4xx.c
+++ b/arch/powerpc/boot/4xx.c
@@ -21,7 +21,7 @@
#include reg.h
#include dcr.h
-static unsigned long chip_11_errata(unsigned long memsize)
+static void chip_11_errata(unsigned long memsize)
{
unsigned long pvr;
@@ -31,13 +31,11 @@ static unsigned long chip_11_errata(unsi
case 0x4850:
case 0x48d0:
case 0x28d0:
- memsize -= 4096;
+ fdt_reserve_mem(memsize - 256, 256);
break;
default:
break;
}
-
- return memsize;
}
/* Read the 4xx SDRAM controller to get size of system memory. */
@@ -53,7 +51,7 @@ void ibm4xx_sdram_fixup_memsize(void)
memsize += SDRAM_CONFIG_BANK_SIZE(bank_config);
}
- memsize = chip_11_errata(memsize);
+ chip_11_errata(memsize);
dt_fixup_memory(0, memsize);
}
@@ -219,7 +217,7 @@ void ibm4xx_denali_fixup_memsize(void)
bank = 4; /* 4 banks */
memsize = cs * (1 (col+row)) * bank * dpath;
- memsize = chip_11_errata(memsize);
+ chip_11_errata(memsize);
dt_fixup_memory(0, memsize);
}
diff --git a/arch/powerpc/boot/libfdt-wrapper.c
b/arch/powerpc/boot/libfdt-wrapper.c
--- a/arch/powerpc/boot/libfdt-wrapper.c
+++ b/arch/powerpc/boot/libfdt-wrapper.c
@@ -167,6 +167,11 @@ static unsigned long fdt_wrapper_finaliz
return (unsigned long)fdt;
}
+int fdt_reserve_mem(unsigned long addr, unsigned long bytes)
+{
+ return fdt_add_mem_rsv(fdt, addr, bytes);
+}
+
void fdt_init(void *blob)
{
int err;
diff --git a/arch/powerpc/boot/ops.h b/arch/powerpc/boot/ops.h
--- a/arch/powerpc/boot/ops.h
+++ b/arch/powerpc/boot/ops.h
@@ -83,6 +83,7 @@ extern struct loader_info loader_info;
void start(void);
void fdt_init(void *blob);
+int fdt_reserve_mem(unsigned long addr, unsigned long bytes);
int serial_console_init(void);
int ns16550_console_init(void *devp, struct serial_console_data *scdp);
int mpsc_console_init(void *devp, struct serial_console_data *scdp);
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] powerpc/44x: declare tlb_44x_index for use in C code
On Fri, 31 Oct 2008 14:03:12 -0500
Hollis Blanchard [EMAIL PROTECTED] wrote:
# HG changeset patch
# User Hollis Blanchard [EMAIL PROTECTED]
# Date 1225479768 18000
# Node ID 59bd162a744af080479fedffa97d01e26dceee6a
# Parent 635f3f74befc230d93f79dc3198c509394247ee8
powerpc/44x: declare tlb_44x_index for use in C code
KVM currently ignores the host's round robin TLB eviction selection, instead
maintaining its own TLB state and its own round robin index. However, by
participating in the normal 44x TLB selection, we can drop the alternate TLB
processing in KVM. This results in a significant performance improvement,
since that processing currently must be done on *every* guest exit.
Accordingly, KVM needs to be able to access and increment tlb_44x_index.
(KVM on 440 cannot be a module, so there is no need to export this symbol.)
Signed-off-by: Hollis Blanchard [EMAIL PROTECTED]
Acked-by: Josh Boyer [EMAIL PROTECTED]
---
Josh, can I get your ack? I'll submit through the KVM tree as usual.
diff --git a/arch/powerpc/include/asm/mmu-44x.h
b/arch/powerpc/include/asm/mmu-44x.h
--- a/arch/powerpc/include/asm/mmu-44x.h
+++ b/arch/powerpc/include/asm/mmu-44x.h
@@ -54,6 +54,7 @@
#ifndef __ASSEMBLY__
extern unsigned int tlb_44x_hwater;
+extern unsigned int tlb_44x_index;
typedef struct {
unsigned long id;
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [RFC] a little disassembly infrastructure
On Fri, 2008-10-31 at 12:21 -0500, Hollis Blanchard wrote:
On Sat, 2008-10-25 at 13:55 +1100, Paul Mackerras wrote:
Hollis Blanchard writes:
I've also found xmon's ppc-opc.c. That parses the opcode and operands,
so could use some shared macros.
That's a direct copy from GNU binutils. I'm reluctant to modify it
because then maintenance becomes more than just copying in the latest
version.
OK, makes sense.
Can I get an Acked-by on this patch, or should I move the code to a
KVM-specific header? Either way I'll submit it via the KVM tree as
usual.
Paul, is this OK? I'm waiting for your ack before sending a number of
dependent KVM patches to Avi.
ppc: Create disassemble.h to extract instruction fields
This is used in a couple places in KVM, but isn't KVM-specific.
However, xmon uses a direct copy of ppc_opc.c from binutils, so xmon won't use
this. emulate_instruction() doesn't need it either, because it can use a series
of mask tests.
Signed-off-by: Hollis Blanchard [EMAIL PROTECTED]
diff --git a/arch/powerpc/include/asm/disassemble.h
b/arch/powerpc/include/asm/disassemble.h
new file mode 100644
--- /dev/null
+++ b/arch/powerpc/include/asm/disassemble.h
@@ -0,0 +1,80 @@
+/*
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License, version 2, as
+ * published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.
+ *
+ * Copyright IBM Corp. 2008
+ *
+ * Authors: Hollis Blanchard [EMAIL PROTECTED]
+ */
+
+#ifndef __ASM_PPC_DISASSEMBLE_H__
+#define __ASM_PPC_DISASSEMBLE_H__
+
+#include linux/types.h
+
+static inline unsigned int get_op(u32 inst)
+{
+ return inst 26;
+}
+
+static inline unsigned int get_xop(u32 inst)
+{
+ return (inst 1) 0x3ff;
+}
+
+static inline unsigned int get_sprn(u32 inst)
+{
+ return ((inst 16) 0x1f) | ((inst 6) 0x3e0);
+}
+
+static inline unsigned int get_dcrn(u32 inst)
+{
+ return ((inst 16) 0x1f) | ((inst 6) 0x3e0);
+}
+
+static inline unsigned int get_rt(u32 inst)
+{
+ return (inst 21) 0x1f;
+}
+
+static inline unsigned int get_rs(u32 inst)
+{
+ return (inst 21) 0x1f;
+}
+
+static inline unsigned int get_ra(u32 inst)
+{
+ return (inst 16) 0x1f;
+}
+
+static inline unsigned int get_rb(u32 inst)
+{
+ return (inst 11) 0x1f;
+}
+
+static inline unsigned int get_rc(u32 inst)
+{
+ return inst 0x1;
+}
+
+static inline unsigned int get_ws(u32 inst)
+{
+ return (inst 11) 0x1f;
+}
+
+static inline unsigned int get_d(u32 inst)
+{
+ return inst 0x;
+}
+
+#endif /* __ASM_PPC_DISASSEMBLE_H__ */
diff --git a/arch/powerpc/kvm/emulate.c b/arch/powerpc/kvm/emulate.c
--- a/arch/powerpc/kvm/emulate.c
+++ b/arch/powerpc/kvm/emulate.c
@@ -28,62 +28,7 @@
#include asm/time.h
#include asm/byteorder.h
#include asm/kvm_ppc.h
-
-/* Instruction decoding */
-static inline unsigned int get_op(u32 inst)
-{
- return inst 26;
-}
-
-static inline unsigned int get_xop(u32 inst)
-{
- return (inst 1) 0x3ff;
-}
-
-static inline unsigned int get_sprn(u32 inst)
-{
- return ((inst 16) 0x1f) | ((inst 6) 0x3e0);
-}
-
-static inline unsigned int get_dcrn(u32 inst)
-{
- return ((inst 16) 0x1f) | ((inst 6) 0x3e0);
-}
-
-static inline unsigned int get_rt(u32 inst)
-{
- return (inst 21) 0x1f;
-}
-
-static inline unsigned int get_rs(u32 inst)
-{
- return (inst 21) 0x1f;
-}
-
-static inline unsigned int get_ra(u32 inst)
-{
- return (inst 16) 0x1f;
-}
-
-static inline unsigned int get_rb(u32 inst)
-{
- return (inst 11) 0x1f;
-}
-
-static inline unsigned int get_rc(u32 inst)
-{
- return inst 0x1;
-}
-
-static inline unsigned int get_ws(u32 inst)
-{
- return (inst 11) 0x1f;
-}
-
-static inline unsigned int get_d(u32 inst)
-{
- return inst 0x;
-}
+#include asm/disassemble.h
static void kvmppc_emulate_dec(struct kvm_vcpu *vcpu)
{
--
Hollis Blanchard
IBM Linux Technology Center
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 1/2] powerpc: add 16K/64K pages support for the 44x PPC32 architectures.
On Mon, 2008-11-03 at 06:26 -0500, Josh Boyer wrote: On Mon, 03 Nov 2008 11:43:54 +1100 Benjamin Herrenschmidt [EMAIL PROTECTED] wrote: Cropping the size of the memory node. That was simplest to do from the cuboot wrapper at the time. If marking it reserved via a reserve map is more elegant and correct, we could do that. But I will still like to know what about the other way is hairy please. I don't like it :-) Bad feeling ... don't like having a memory node entry that isn't aligned to some large power of two typically. Erm, ok. And does your heebie-geebies extend to people using the mem= parameter in a similar fashion? Nah, not really. It's not that it won't work, I suppose it does, though I would have preferred a way to reserve that memory rather than take it off. In fact, that last page could be used for other things, for example it could be used as a dummy page to point stale DMA to or whatever else. Ben. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: Connecting to PCI command write interrupt on 4xx platforms
I will try to add endpoint support for PCI as well. I would like to have a single PCI node and let the device_type attribute decide if we are running in hostbridge or endpoint mode. Don't use device_type. Do the same we do for PCI-E (whatever it is, I don't have the source code at hand right now). Cheers, Ben. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] gianfar: Omit TBI auto-negotiation based on device tree
On Nov 3, 2008, at 12:55 PM, Nate Case wrote: On Thu, 2008-10-30 at 18:07 -0700, Trent Piepho wrote: But more relevant to your serdes problem, I also have a patch that prevents restarting serdes auto-negotiation if the serdes link is already up. My SGMII PHY will auto-negotiate, but it takes about 3 seconds. Avoiding an unnecessary 3 second auto-negotiation when the gianfar device is opened lets me cut my power-on to DHCP completion time in half. I wonder if this would also fix your problem, without needing to add the extra workaround? I just verified that your patch solves my problem without the need for my workaround. So at this point, it looks like we can drop this patch (Omit TBI auto-negotiation based on device tree). I tested when booting the kernel in U-Boot both via both TFTP and flash (I was worried that your patch may only fix things for the TFTP boot case, but that wasn't the case fortunately). Thanks for the patch! Ok, marked Nate's patch as superseded in patchworks. - k ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [RFC] a little disassembly infrastructure
Hollis Blanchard writes: Hi, I wrote this patch for KVM [1], but now that I look closer it seems like there might be some overlapping functionality. Looks OK - Acked-by: Paul Mackerras [EMAIL PROTECTED] subject to you writing a suitable patch description. :) Paul. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] workaround for mpc52xx erratum #364 (serial may not be reset in break state)
Grant Likely wrote: On Mon, Nov 3, 2008 at 12:32 PM, René Bürgel [EMAIL PROTECTED] wrote: Hi This patch is a workaround for bug #364 found in the MPC52xx processor. The errata document can be found under http://www.freescale.com/files/32bit/doc/errata/MPC5200E.pdf?fpsp=1WT_TYPE=ErrataWT_VENDOR=FREESCALEWT_FILE_FORMAT=pdfWT_ASSET=Documentation This is an MPC5200 errata. It doesn't exist on the MPC5200B. The bugfix code should be enabled at runtime only if running on the original MPC5200. You can use the value of the compatible property to determine whether or not to enable it. I would hope not since the Efika uses mpc5200-psc and mpc5200-serial as it's compatible properties (this is from before mpc5200-psc-uart was defined), which would enable this bugfix across the board. Until we have a decent update for the device tree here (it's starting to cause some real trouble lately when people update stuff like this and want to compare) the best way to check for the MPC5200 or MPC5200B is to look at the PVR - you don't need the device tree for this, at all. Sometime this week I am going to go through the 5200b device tree in the kernel source and make sure efika.forth follows it as best as I can, and then make a release.. that won't fix anything for people who don't run the script, however. Optionally you can further reduce impact by checking if CONFIG_PPC_MPC5200_BUGFIX is defined. I would much prefer this. -- Matt Sealey [EMAIL PROTECTED] Genesi, Manager, Developer Relations ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] workaround for mpc52xx erratum #364 (serial may not be reset in break state)
On Mon, Nov 03, 2008 at 03:57:09PM -0600, Matt Sealey wrote: Optionally you can further reduce impact by checking if CONFIG_PPC_MPC5200_BUGFIX is defined. I would much prefer this. I submitted a patch to enable pipelining on a MPC5200B recently. It was disabled because of a bug in the MPC5200. The first version of this patch used MPC5200_BUGFIX and it was mentioned, that some people might want to run the same kernel on both kind of processors. So, the patch that went mainline checks for the PVR. Maybe we should stick to this here, too? All the best, Wolfram Sang -- 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: [PATCH] workaround for mpc52xx erratum #364 (serial may not be reset in break state)
On Mon, Nov 3, 2008 at 3:15 PM, Wolfram Sang [EMAIL PROTECTED] wrote: On Mon, Nov 03, 2008 at 03:57:09PM -0600, Matt Sealey wrote: Optionally you can further reduce impact by checking if CONFIG_PPC_MPC5200_BUGFIX is defined. I would much prefer this. I submitted a patch to enable pipelining on a MPC5200B recently. It was disabled because of a bug in the MPC5200. The first version of this patch used MPC5200_BUGFIX and it was mentioned, that some people might want to run the same kernel on both kind of processors. So, the patch that went mainline checks for the PVR. Maybe we should stick to this here, too? Of the two solutions: 1. Run-time selection must be done. 2. Compile-time removal of the bug fix path can also be done to lessen runtime impact for kernels never run on older chips My view is that #1 is non-negotiable. #2 is a nice to have, but if it doesn't incur any cost when disabled at runtime then I don't care. 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
Passing I2C platform_data from device tree to i2c driver
Is there a plan for providing a way to set pdata for an I2C chip in a way that could be shared across all OF platforms? For example, the pca953x I2C GPIO driver requires that pdata != NULL so it can get the gpio_base field. It can also take in a default 'invert' value to initialize a chip register with. Currently, there's no obvious way to get this to work on PowerPC without hardcoding things in the arch/powerpc/platforms/*.c file. On ARM platforms, they currently handle this by declaring I2C_BOARD_INFO() in their board-specific files. For OF platforms, I think the obvious choice would be to specify platform data in the device tree. We already register I2C devices automatically as found in the device tree (see drivers/of/of_i2c.c), but this registration method does not provide any way to set platform_data. Of course, I could put some code in my board specific file to parse the device tree properties and set pdata accordingly, but this hardly seems ideal. After all, the device tree bindings - pdata translation itself does not have to be board-specific. Basically, I think we need to have some common code somewhere that does the task of populating platform_data for a specific I2C chip based on a device tree node -- similarly to how we register the I2C devices already. Is anyone working on this? Did anyone have anything else in mind? -- Nate Case [EMAIL PROTECTED] ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: Connecting to PCI command write interrupt on 4xx platforms
On Monday 03 November 2008, Benjamin Herrenschmidt wrote:
I will try to add endpoint support for PCI as well. I would like to have
a single PCI node and let the device_type attribute decide if we are
running in hostbridge or endpoint mode.
Don't use device_type. Do the same we do for PCI-E (whatever it is, I
don't have the source code at hand right now).
It is device_type for PCIe right now, I'm afraid. This was what we agreed
upon. Here a code sniplet from the patch:
/* Check if device_type property is set to pci or pci-endpoint.
* Resulting from this setup this PCIe port will be configured
* as root-complex or as endpoint.
*/
val = of_get_property(port-node, device_type, NULL);
if (!strcmp(val, pci-endpoint)) {
port-endpoint = 1;
} else if (!strcmp(val, pci)) {
port-endpoint = 0;
} else {
printk(KERN_ERR PCIE: missing or incorrect device_type for
%s\n,
np-full_name);
return;
}
Best regards,
Stefan
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: Connecting to PCI command write interrupt on 4xx platforms
On Tue, 2008-11-04 at 06:19 +0100, Stefan Roese wrote:
On Monday 03 November 2008, Benjamin Herrenschmidt wrote:
I will try to add endpoint support for PCI as well. I would like to have
a single PCI node and let the device_type attribute decide if we are
running in hostbridge or endpoint mode.
Don't use device_type. Do the same we do for PCI-E (whatever it is, I
don't have the source code at hand right now).
It is device_type for PCIe right now, I'm afraid. This was what we agreed
upon. Here a code sniplet from the patch:
/* Check if device_type property is set to pci or pci-endpoint.
* Resulting from this setup this PCIe port will be configured
* as root-complex or as endpoint.
*/
val = of_get_property(port-node, device_type, NULL);
if (!strcmp(val, pci-endpoint)) {
port-endpoint = 1;
} else if (!strcmp(val, pci)) {
port-endpoint = 0;
} else {
printk(KERN_ERR PCIE: missing or incorrect device_type for
%s\n,
np-full_name);
return;
}
Allright, that was a bad idea from both of us, David will have my
skin ...
We should try to move toward something like an endpoint property and a
pci-endpoint name instead.
Ben.
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
