Device Tree
Hello, I have a question about Device Tree. Is Device Tree found only only on Linux Powerpc ? Thanks Sébastien ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: Device Tree
Hello. Sébastien Chrétien wrote: Hello, I have a question about Device Tree. Is Device Tree found only only on Linux Powerpc ? Not only Linux as it's a part of Open Firmware which is also used at least on SPARC. WBR, Sergei ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: Device Tree
Hello. Sébastien Chrétien wrote: I have a question about Device Tree. Is Device Tree found only only on Linux Powerpc ? Not only Linux as it's a part of Open Firmware which is also used at least on SPARC. WBR, Sergei ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: Device Tree
On Mon, 2008-09-29 at 08:24 +0200, Sébastien Chrétien wrote: Hello, I have a question about Device Tree. Is Device Tree found only only on Linux Powerpc ? Sparc also uses open firmware and shares some of the device-tree handling code with powerpc in linux. Other operating systems on those platforms also use it (AIX, Solaris, MacOS, ...) I think the proposed new Xilinx microblaze architecture also uses it, and at least on x86, the OLPC has an Open Firmware implementation though it doesn't use the device-tree the way we do currently on powerpc and sparc and has its own interface to the firmware. Ben. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: Fix PCI in Holly device tree
Signed-off-by: David Gibson [EMAIL PROTECTED] Acked-by: Josh Boyer [EMAIL PROTECTED] Paul, I can include this in my 'next' branch if you aren't opposed. I'll have another set of patches going in there today/tomorrow. Er... on second thought, this actually fixes a regression on Holly. So I'll amend my offer to put it in my 'next' branch to be contingent on you not wanting to get it into 2.6.27 this late. I've picked it up, I need to check a thing or two and I'll send patches for .27 to Linus tomorrow (Paulus is on vacation for a week). With a bit of luck he won't have closed .27 before that :-) Cheers Ben. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: take in count O_NONBLOCK flag for rtas log
rtas_log_read() doesn't check file flags for O_NONBLOCK and blocks
non-blocking reader of /proc/ppc64/rtas/error_log if there's no data
available. Patch makes sure that non-blocking reader will never
blocks.
Also rtas_log_read() returns now with ENODATA to prevent suspending of
process in wait_event_interruptible() when logging facility was
switched off and log is already empty.
Acked-by: David Howells [EMAIL PROTECTED]
Signed-off-by: Vitaly Mayatskikh [EMAIL PROTECTED]
diff --git a/arch/powerpc/platforms/pseries/rtasd.c
b/arch/powerpc/platforms/pseries/rtasd.c
index c9ffd8c..4f76e3b 100644
--- a/arch/powerpc/platforms/pseries/rtasd.c
+++ b/arch/powerpc/platforms/pseries/rtasd.c
@@ -295,19 +295,29 @@ static ssize_t rtas_log_read(struct file * file, char
__user * buf,
if (!tmp)
return -ENOMEM;
-
spin_lock_irqsave(rtasd_log_lock, s);
/* if it's 0, then we know we got the last one (the one in NVRAM) */
- if (rtas_log_size == 0 logging_enabled)
- nvram_clear_error_log();
- spin_unlock_irqrestore(rtasd_log_lock, s);
+ while (rtas_log_size == 0) {
+ if (file-f_flags O_NONBLOCK) {
+ spin_unlock_irqrestore(rtasd_log_lock, s);
+ error = -EAGAIN;
+ goto out;
+ }
+ if (!logging_enabled) {
+ spin_unlock_irqrestore(rtasd_log_lock, s);
+ error = -ENODATA;
+ goto out;
+ }
+ nvram_clear_error_log();
- error = wait_event_interruptible(rtas_log_wait, rtas_log_size);
- if (error)
- goto out;
+ spin_unlock_irqrestore(rtasd_log_lock, s);
+ error = wait_event_interruptible(rtas_log_wait, rtas_log_size);
+ if (error)
+ goto out;
+ spin_lock_irqsave(rtasd_log_lock, s);
+ }
- spin_lock_irqsave(rtasd_log_lock, s);
offset = rtas_error_log_buffer_max * (rtas_log_start LOG_NUMBER_MASK);
memcpy(tmp, rtas_log_buf[offset], count);
--
wbr, Vitaly
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH] powerpc: Correct USB support for GE Fanuc SBC610
Support for the SBC610 VPX Single Board Computer from GE Fanuc (PowerPC
MPC8641D).
Fixup to correctly reconfigure USB, provided by an NEC uPD720101, after
device is reset. This requires a set of chip specific registers in the
devices configuration space to be correctly written, enabling all ports
and switching the device to use an external 48-MHz Oscillator.
Signed-off-by: Martyn Welch [EMAIL PROTECTED]
---
arch/powerpc/platforms/86xx/gef_sbc610.c | 17 +
1 files changed, 17 insertions(+), 0 deletions(-)
diff --git a/arch/powerpc/platforms/86xx/gef_sbc610.c
b/arch/powerpc/platforms/86xx/gef_sbc610.c
index 3543a9e..605678c 100644
--- a/arch/powerpc/platforms/86xx/gef_sbc610.c
+++ b/arch/powerpc/platforms/86xx/gef_sbc610.c
@@ -12,6 +12,8 @@
*
* Based on: mpc86xx_hpcn.c (MPC86xx HPCN board specific routines)
* Copyright 2006 Freescale Semiconductor Inc.
+ *
+ * NEC fixup adapted from arch/mips/pci/fixup-lm2e.c
*/
#include linux/stddef.h
@@ -83,6 +85,21 @@ static void gef_sbc610_show_cpuinfo(struct seq_file *m)
seq_printf(m, Memory\t\t: %d MB\n, memsize / (1024 * 1024));
}
+static void __init gef_sbc610_nec_fixup(struct pci_dev *pdev)
+{
+ unsigned int val;
+
+ printk(KERN_INFO Running NEC uPD720101 Fixup\n);
+
+ /* Ensure ports 1, 2, 3, 4 5 are enabled */
+ pci_read_config_dword(pdev, 0xe0, val);
+ pci_write_config_dword(pdev, 0xe0, (val ~7) | 0x5);
+
+ /* System clock is 48-MHz Oscillator and EHCI Enabled. */
+ pci_write_config_dword(pdev, 0xe4, 1 5);
+}
+DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_NEC, PCI_DEVICE_ID_NEC_USB,
+ gef_sbc610_nec_fixup);
/*
* Called very early, device-tree isn't unflattened
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: Please pull from 'dma' branch
On Sep 24, 2008, at 4:54 PM, Kumar Gala wrote: Please pull from 'dma' branch of (forgot linuxppc-dev on first go around) master.kernel.org:/pub/scm/linux/kernel/git/galak/powerpc.git dma to receive the following updates: arch/powerpc/include/asm/device.h |3 arch/powerpc/include/asm/dma-mapping.h | 187 + arch/powerpc/include/asm/machdep.h |5 arch/powerpc/include/asm/pci.h | 14 +- arch/powerpc/include/asm/types.h|2 arch/powerpc/kernel/Makefile|4 arch/powerpc/kernel/dma-iommu.c | 103 arch/powerpc/kernel/dma.c | 127 arch/powerpc/kernel/dma_64.c| 200 arch/powerpc/kernel/of_device.c |2 arch/powerpc/kernel/pci-common.c| 48 +++ arch/powerpc/kernel/pci_32.c|7 + arch/powerpc/kernel/pci_64.c| 49 --- arch/powerpc/kernel/vio.c |2 arch/powerpc/platforms/cell/iommu.c |6 arch/powerpc/platforms/ps3/system-bus.c |2 16 files changed, 366 insertions(+), 395 deletions(-) Becky Bruce (5): powerpc: Rename dma_64.c to dma.c powerpc: Move iommu dma ops from dma.c to dma-iommu.c powerpc: Drop archdata numa_node powerpc: Merge 32 and 64-bit dma code powerpc: Make dma_addr_t a u64 if CONFIG_PHYS_64BIT is set Paul, poke.. - k ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH] pata_of_platform: fix no irq handling
When no irq specified the pata_of_platform fills the irq_res with -1, which is wrong to do for two reasons: 1. By definition, 'no irq' should be IRQ 0, not some negative integer; 2. pata_platform checks for irq_res.start 0, but since irq_res.start is unsigned type, the check will be true for `-1'. Reported-by: Steven A. Falco [EMAIL PROTECTED] Signed-off-by: Anton Vorontsov [EMAIL PROTECTED] --- On Mon, Sep 29, 2008 at 12:19:14AM -0400, Jeff Garzik wrote: Anton Vorontsov wrote: On Thu, Sep 25, 2008 at 06:40:59PM +0800, Li Yang wrote: On Thu, Sep 25, 2008 at 4:54 PM, Wang Jian [EMAIL PROTECTED] wrote: The alternative fix can be. This one is better as 0 is defined as 'invalid irq' for all architectures. Added linux-ide and Anton to cc. Thanks for the correct Cc. I've sent a patch to fix the issue more than a month ago. http://www.mail-archive.com/linuxppc-dev@ozlabs.org/msg22851.html Jeff, could you apply the patch? Can you resend, I don't seem to have it... Here it is. Thanks, drivers/ata/pata_of_platform.c |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/drivers/ata/pata_of_platform.c b/drivers/ata/pata_of_platform.c index 408da30..1f18ad9 100644 --- a/drivers/ata/pata_of_platform.c +++ b/drivers/ata/pata_of_platform.c @@ -52,7 +52,7 @@ static int __devinit pata_of_platform_probe(struct of_device *ofdev, ret = of_irq_to_resource(dn, 0, irq_res); if (ret == NO_IRQ) - irq_res.start = irq_res.end = -1; + irq_res.start = irq_res.end = 0; else irq_res.flags = 0; -- 1.5.6.3 ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [RFC][PATCH] Demultiplexing SIGTRAP signal -v2
Roland McGrath wrote: I certainly have no objection in principle. I doubt that any x86 userland apps expect certain si_code values for SIGTRAP now, since the existing values are not of any real use. (Signal handlers get the thread.trap_no and thread.error_code values from hardware to guess from, and debuggers via ptrace get the hardware %db6 value to guess from.) I do have a few comments. If you're doing it, I think you should do the do_int3 case too, so every machine-generated SIGTRAP has a meaningful si_code value. Roland Thanks for your comments. I'm inclined to consolidate the si_code logic there, and just pass it the hardware bits or let it get them from the thread_struct (trap_nr, error_code, debugreg6). That sounds like a good idea. Let me go through code and get back to you. Thanks Srinivasa DS ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 1/2] Drop redundant machine type print in show_cpuinfo
On Sep 24, 2008, at 4:53 PM, Becky Bruce wrote: For many of the embedded boards, model and Machine are printing the same thing; remove the redundant code and allow the generic show_cpuinfo to print the model information. Signed-off-by: Becky Bruce [EMAIL PROTECTED] --- arch/powerpc/platforms/85xx/mpc85xx_ads.c |1 - arch/powerpc/platforms/85xx/sbc8560.c |1 - arch/powerpc/platforms/86xx/gef_sbc610.c |8 arch/powerpc/platforms/86xx/mpc86xx_hpcn.c|8 arch/powerpc/platforms/86xx/sbc8641d.c|8 arch/powerpc/platforms/embedded6xx/mpc7448_hpc2.c |1 - 6 files changed, 0 insertions(+), 27 deletions(-) Do any of the board maintainers have issue with this change? Martyn, Paul? I'm fine w/it for the FSL ones. - k ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH] powerpc/fsl_soc: remove mpc83xx_wdt code
mpc83xx_wdt is the OF driver now, so we don't need fsl_soc constructor.
Signed-off-by: Anton Vorontsov [EMAIL PROTECTED]
---
Just resending the following patch:
http://ozlabs.org/pipermail/linuxppc-dev/2008-May/056253.html
arch/powerpc/sysdev/fsl_soc.c | 47 -
1 files changed, 0 insertions(+), 47 deletions(-)
diff --git a/arch/powerpc/sysdev/fsl_soc.c b/arch/powerpc/sysdev/fsl_soc.c
index 214388e..eeb0700 100644
--- a/arch/powerpc/sysdev/fsl_soc.c
+++ b/arch/powerpc/sysdev/fsl_soc.c
@@ -412,53 +412,6 @@ err:
arch_initcall(gfar_of_init);
-
-#ifdef CONFIG_PPC_83xx
-static int __init mpc83xx_wdt_init(void)
-{
- struct resource r;
- struct device_node *np;
- struct platform_device *dev;
- u32 freq = fsl_get_sys_freq();
- int ret;
-
- np = of_find_compatible_node(NULL, watchdog, mpc83xx_wdt);
-
- if (!np) {
- ret = -ENODEV;
- goto nodev;
- }
-
- memset(r, 0, sizeof(r));
-
- ret = of_address_to_resource(np, 0, r);
- if (ret)
- goto err;
-
- dev = platform_device_register_simple(mpc83xx_wdt, 0, r, 1);
- if (IS_ERR(dev)) {
- ret = PTR_ERR(dev);
- goto err;
- }
-
- ret = platform_device_add_data(dev, freq, sizeof(freq));
- if (ret)
- goto unreg;
-
- of_node_put(np);
- return 0;
-
-unreg:
- platform_device_unregister(dev);
-err:
- of_node_put(np);
-nodev:
- return ret;
-}
-
-arch_initcall(mpc83xx_wdt_init);
-#endif
-
static enum fsl_usb2_phy_modes determine_usb_phy(const char *phy_type)
{
if (!phy_type)
--
1.5.6.3
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
RE: [PATCH 1/2] Drop redundant machine type print in show_cpuinfo
Kumar Gala wrote: On Sep 24, 2008, at 4:53 PM, Becky Bruce wrote: For many of the embedded boards, model and Machine are printing the same thing; remove the redundant code and allow the generic show_cpuinfo to print the model information. Signed-off-by: Becky Bruce [EMAIL PROTECTED] --- arch/powerpc/platforms/85xx/mpc85xx_ads.c |1 - arch/powerpc/platforms/85xx/sbc8560.c |1 - arch/powerpc/platforms/86xx/gef_sbc610.c |8 arch/powerpc/platforms/86xx/mpc86xx_hpcn.c|8 arch/powerpc/platforms/86xx/sbc8641d.c|8 arch/powerpc/platforms/embedded6xx/mpc7448_hpc2.c |1 - 6 files changed, 0 insertions(+), 27 deletions(-) Do any of the board maintainers have issue with this change? Martyn, Paul? I'm fine w/it for the FSL ones. - k No problem here. Martyn -- Martyn Welch MEng MPhil MIET Principal Software Engineer GE Fanuc Intelligent Platforms Tove Valley Business Park, Towcester, Northants, NN12 6PF, United Kingdom Telephone: +44 (0) 1327 359444 Direct Dial: +44 (0) 1327 322748 Fax: +44 (0) 1327 322800 email: [EMAIL PROTECTED] web: www.gefanuc.com GE Fanuc Intelligent Platforms Ltd, registered in England and Wales (3828642) at 100 Barbirolli Square, Manchester, M2 3AB, VAT GB 729 849 476 GE Fanuc Intelligent Platforms Confidential and Proprietary. If you have received this message in error please notify us immediately and permanently remove it from your system and destroy any printed hardcopies. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 1/2] Drop redundant machine type print in show_cpuinfo
On Wed, Sep 24, 2008 at 5:53 PM, Becky Bruce [EMAIL PROTECTED] wrote: For many of the embedded boards, model and Machine are printing the same thing; remove the redundant code and allow the generic show_cpuinfo to print the model information. Sounds good to me. Thanks for changing the sbc boards as well. Signed-off-by: Becky Bruce [EMAIL PROTECTED] Acked-by: Paul Gortmaker [EMAIL PROTECTED] --- arch/powerpc/platforms/85xx/mpc85xx_ads.c |1 - arch/powerpc/platforms/85xx/sbc8560.c |1 - arch/powerpc/platforms/86xx/gef_sbc610.c |8 arch/powerpc/platforms/86xx/mpc86xx_hpcn.c|8 arch/powerpc/platforms/86xx/sbc8641d.c|8 arch/powerpc/platforms/embedded6xx/mpc7448_hpc2.c |1 - 6 files changed, 0 insertions(+), 27 deletions(-) ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: USB support on mpc5200 broken
On Sun, Sep 28, 2008 at 11:43 PM, David Gibson
[EMAIL PROTECTED] wrote:
On Sun, Sep 28, 2008 at 08:30:56PM -0500, Matt Sealey wrote:
Benjamin Herrenschmidt wrote:
On Wed, 2008-09-24 at 21:09 -0400, Jon Smirl wrote:
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.
This doesn't look to me like a very reliable way to determine bigendian.
You mean it's not reliable to expect people device-trees not to
suck ? :-)
Alas, this is true :(.
Efika has this:
compatible = fsl,mpc5200b-ohci,fsl,mpc5200-ohci;
That completely describes the hardware. Isn't that what a device tree
is supposed to do?
If we really need a big endian flag, should it be an attribute?
[EMAIL PROTECTED] {
compatible = fsl,mpc5200b-ohci,fsl,mpc5200-ohci;
ohci-be;
reg = 0x1000 0xff;
interrupts = 0x2 0x6 0x0;
interrupt-parent = mpc5200_pic;
};
Shouldn't the driver already know it is being used on a BE machine?
It's reasonable to expect that device-trees do not get updated with the
kernel for certain platforms (it does not fit into most quality assurance
schedules to reflash every user's firmware every time they want to move up
one revision to another, given the kernel release schedule of every 3-4
months) and when updating the search for compatible entries it should
take into account these platforms.
This, of course, is exactly why I *don't* recommend embedded platforms
move to including the device tree in the flashed firmware. Keeping
the device tree in the bootwrapper means that it *is* updated with the
kernel and we don't have to mess around with as much backwards
compatibility junk.
How do I adjust my build to put the DTB into a wrapper? I'm based on
the pcm030 makefile and it assumes the DTB is built externally.
Can u-boot handle the wrapped DTB? I'm using a pointer to kernel and
one to DTB when booting from u-boot.
--
Jon Smirl
[EMAIL PROTECTED]
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 1/2] Drop redundant machine type print in show_cpuinfo
On Wed, 24 Sep 2008 16:53:34 -0500 Becky Bruce [EMAIL PROTECTED] wrote: For many of the embedded boards, model and Machine are printing the same thing; remove the redundant code and allow the generic show_cpuinfo to print the model information. No prob. Signed-off-by: Becky Bruce [EMAIL PROTECTED] Acked-by: Martyn Welch [EMAIL PROTECTED] --- arch/powerpc/platforms/85xx/mpc85xx_ads.c |1 - arch/powerpc/platforms/85xx/sbc8560.c |1 - arch/powerpc/platforms/86xx/gef_sbc610.c |8 arch/powerpc/platforms/86xx/mpc86xx_hpcn.c|8 arch/powerpc/platforms/86xx/sbc8641d.c|8 arch/powerpc/platforms/embedded6xx/mpc7448_hpc2.c |1 - 6 files changed, 0 insertions(+), 27 deletions(-) -- Martyn Welch MEng MPhil MIET (Principal Software Engineer) T:+44(0)1327322748 GE Fanuc Intelligent Platforms Ltd,|Registered in England and Wales Tove Valley Business Park, Towcester, |(3828642) at 100 Barbirolli Square, Northants, NN12 6PF, UK T:+44(0)1327359444 |Manchester,M2 3AB VAT:GB 729849476 ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: USB support on mpc5200 broken
Jon == Jon Smirl [EMAIL PROTECTED] writes: Hi, Jon How do I adjust my build to put the DTB into a wrapper? I'm Jon based on the pcm030 makefile and it assumes the DTB is built Jon externally. Jon Can u-boot handle the wrapped DTB? I'm using a pointer to kernel Jon and one to DTB when booting from u-boot. See my recent (nacked by Wolfgang, but sane in principle) patch for uImage.platform support: http://patchwork.ozlabs.org/patch/589/ -- Bye, Peter Korsgaard ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] powerpc/fsl_soc: remove mpc83xx_wdt code
On Sep 29, 2008, at 8:56 AM, Anton Vorontsov wrote: mpc83xx_wdt is the OF driver now, so we don't need fsl_soc constructor. Signed-off-by: Anton Vorontsov [EMAIL PROTECTED] --- Just resending the following patch: http://ozlabs.org/pipermail/linuxppc-dev/2008-May/056253.html arch/powerpc/sysdev/fsl_soc.c | 47 - 1 files changed, 0 insertions(+), 47 deletions(-) applied. - k ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 1/2] Drop redundant machine type print in show_cpuinfo
On Sep 24, 2008, at 4:53 PM, Becky Bruce wrote: For many of the embedded boards, model and Machine are printing the same thing; remove the redundant code and allow the generic show_cpuinfo to print the model information. Signed-off-by: Becky Bruce [EMAIL PROTECTED] --- arch/powerpc/platforms/85xx/mpc85xx_ads.c |1 - arch/powerpc/platforms/85xx/sbc8560.c |1 - arch/powerpc/platforms/86xx/gef_sbc610.c |8 arch/powerpc/platforms/86xx/mpc86xx_hpcn.c|8 arch/powerpc/platforms/86xx/sbc8641d.c|8 arch/powerpc/platforms/embedded6xx/mpc7448_hpc2.c |1 - 6 files changed, 0 insertions(+), 27 deletions(-) applied. - k ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 1/2] Drop redundant machine type print in show_cpuinfo
On Sep 24, 2008, at 4:53 PM, Becky Bruce wrote: For many of the embedded boards, model and Machine are printing the same thing; remove the redundant code and allow the generic show_cpuinfo to print the model information. Signed-off-by: Becky Bruce [EMAIL PROTECTED] --- arch/powerpc/platforms/85xx/mpc85xx_ads.c |1 - arch/powerpc/platforms/85xx/sbc8560.c |1 - arch/powerpc/platforms/86xx/gef_sbc610.c |8 arch/powerpc/platforms/86xx/mpc86xx_hpcn.c|8 arch/powerpc/platforms/86xx/sbc8641d.c|8 arch/powerpc/platforms/embedded6xx/mpc7448_hpc2.c |1 - 6 files changed, 0 insertions(+), 27 deletions(-) applied - k ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] powerpc: Correct USB support for GE Fanuc SBC610
On Sep 29, 2008, at 7:35 AM, Martyn Welch wrote: Support for the SBC610 VPX Single Board Computer from GE Fanuc (PowerPC MPC8641D). Fixup to correctly reconfigure USB, provided by an NEC uPD720101, after device is reset. This requires a set of chip specific registers in the devices configuration space to be correctly written, enabling all ports and switching the device to use an external 48-MHz Oscillator. Signed-off-by: Martyn Welch [EMAIL PROTECTED] --- arch/powerpc/platforms/86xx/gef_sbc610.c | 17 + 1 files changed, 17 insertions(+), 0 deletions(-) applied - k ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: USB support on mpc5200 broken
On Mon, Sep 29, 2008 at 10:22 AM, Peter Korsgaard [EMAIL PROTECTED] wrote: Jon == Jon Smirl [EMAIL PROTECTED] writes: Hi, Jon How do I adjust my build to put the DTB into a wrapper? I'm Jon based on the pcm030 makefile and it assumes the DTB is built Jon externally. Jon Can u-boot handle the wrapped DTB? I'm using a pointer to kernel Jon and one to DTB when booting from u-boot. See my recent (nacked by Wolfgang, but sane in principle) patch for uImage.platform support: http://patchwork.ozlabs.org/patch/589/ So I should wait for the version that uses FIT images. -- Bye, Peter Korsgaard -- Jon Smirl [EMAIL PROTECTED] ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: Please pull from 'dma' branch
On Mon, Sep 29, 2008 at 08:12:11AM -0500, Kumar Gala wrote: On Sep 24, 2008, at 4:54 PM, Kumar Gala wrote: Please pull from 'dma' branch of (forgot linuxppc-dev on first go around) master.kernel.org:/pub/scm/linux/kernel/git/galak/powerpc.git dma to receive the following updates: arch/powerpc/include/asm/device.h |3 arch/powerpc/include/asm/dma-mapping.h | 187 + arch/powerpc/include/asm/machdep.h |5 arch/powerpc/include/asm/pci.h | 14 +- arch/powerpc/include/asm/types.h|2 arch/powerpc/kernel/Makefile|4 arch/powerpc/kernel/dma-iommu.c | 103 arch/powerpc/kernel/dma.c | 127 arch/powerpc/kernel/dma_64.c| 200 arch/powerpc/kernel/of_device.c |2 arch/powerpc/kernel/pci-common.c| 48 +++ arch/powerpc/kernel/pci_32.c|7 + arch/powerpc/kernel/pci_64.c| 49 --- arch/powerpc/kernel/vio.c |2 arch/powerpc/platforms/cell/iommu.c |6 arch/powerpc/platforms/ps3/system-bus.c |2 16 files changed, 366 insertions(+), 395 deletions(-) Becky Bruce (5): powerpc: Rename dma_64.c to dma.c powerpc: Move iommu dma ops from dma.c to dma-iommu.c powerpc: Drop archdata numa_node powerpc: Merge 32 and 64-bit dma code powerpc: Make dma_addr_t a u64 if CONFIG_PHYS_64BIT is set Paul, poke.. Vacation for a week. I guess we're supposed to poke benh now. Or wait a week. josh ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
8349emitx Board : PCI issues
Hi,I have some issues with the 8349emitx board.I achieved to run the board with the supplied LTIB cd, witch builds linux2.6.13.the board is working well.I downloaded the lasted ltib ( frombitshrine.org) and the lasted kernel2.6.26.The last kernel seems supporting this board except with the sata chip.Attached to this mail, you will find a txt file containing 3 linux boot logs.- the 2.6.26 boot log witch hangs at sata disks inits- the 2.6.13 boot log witch works and- the 2.6.26 boot log with option libata.dma=0. ( this is the only way to have the board booting,I tried all other libata options without success ).the "host bus error" means that the issue is on the PCI bus. Now I'm out of ideas.This behaviour has been confirm by FS.Does someone have any hint ?RegardsOlivier --- Boot linux 2.6.26 Using MPC834x ITX machine description Linux version 2.6.26 ([EMAIL PROTECTED]) (gcc version 4.2.1 (Sourcery G++ Lite 4.2-82)) #35 Tue Jul 29 16:55:34 CEST 2008 Found initrd at 0xcf829000:0xcff74b4a Found MPC83xx PCI host bridge at 0xe0008500. Firmware bus number: 0-0 PCI host bridge /[EMAIL PROTECTED] (primary) ranges: MEM 0x8000..0x8fff - 0x8000 Prefetch MEM 0x9000..0x9fff - 0x9000 IO 0xe200..0xe2ff - 0x Found MPC83xx PCI host bridge at 0xe0008600. Firmware bus number: 0-0 PCI host bridge /[EMAIL PROTECTED] ranges: MEM 0xa000..0xafff - 0xa000 Prefetch MEM 0xb000..0xbfff - 0xb000 IO 0xe300..0xe3ff - 0x Zone PFN ranges: DMA 0 -65536 Normal 65536 -65536 Movable zone start PFN for each node early_node_map[1] active PFN ranges 0:0 -65536 Built 1 zonelists in Zone order, mobility grouping on. Total pages: 65024 Kernel command line: root=/dev/ram ramdisk_size=8 rw ip=192.168.0.20:192.168.0.42:192.168.1.254:255.255.255.0:PowerQUICC:eth0:off console=ttyS1,115200 md=0,/dev/sda,/dev/sdb,/dev/sdc,/dev/sdd md: Will configure md0 (super-block) from /dev/sda,/dev/sdb,/dev/sdc,/dev/sdd, below. IPIC (128 IRQ sources) at fbffc700 PID hash table entries: 1024 (order: 10, 4096 bytes) clocksource: timebase mult[3c1] shift[22] registered Dentry cache hash table entries: 32768 (order: 5, 131072 bytes) Inode-cache hash table entries: 16384 (order: 4, 65536 bytes) Memory: 248440k/262144k available (3356k kernel code, 13384k reserved, 116k data, 100k bss, 168k init) SLUB: Genslabs=12, HWalign=32, Order=0-3, MinObjects=0, CPUs=1, Nodes=1 Mount-cache hash table entries: 512 net_namespace: 192 bytes xor: measuring software checksum speed 8regs : 405.000 MB/sec 8regs_prefetch: 385.000 MB/sec 32regs: 485.000 MB/sec 32regs_prefetch: 471.000 MB/sec xor: using function: 32regs (485.000 MB/sec) NET: Registered protocol family 16 PCI: Probing PCI hardware SCSI subsystem initialized usbcore: registered new interface driver usbfs usbcore: registered new interface driver hub usbcore: registered new device driver usb NET: Registered protocol family 2 IP route cache hash table entries: 2048 (order: 1, 8192 bytes) TCP established hash table entries: 8192 (order: 4, 65536 bytes) TCP bind hash table entries: 8192 (order: 3, 32768 bytes) TCP: Hash tables configured (established 8192 bind 8192) TCP reno registered NET: Registered protocol family 1 checking if image is initramfs...it isn't (no cpio magic); looks like an initrd Freeing initrd memory: 7470k freed msgmni has been set to 500 async_tx: api initialized (async) io scheduler noop registered io scheduler anticipatory registered (default) io scheduler deadline registered io scheduler cfq registered Serial: 8250/16550 driver $Revision: 1.90 $ 4 ports, IRQ sharing disabled serial8250.0: ttyS0 at MMIO 0xe0004500 (irq = 18) is a 16550A serial8250.0: ttyS1 at MMIO 0xe0004600 (irq = 19) is a 16550A console [ttyS1] enabled brd: module loaded loop: module loaded eth0: Gianfar Ethernet Controller Version 1.2, 08:00:3e:03:01:11 eth0: Running with NAPI enabled eth0: 256/256 RX/TX BD ring size eth1: Gianfar Ethernet Controller Version 1.2, 08:00:3e:03:01:12 eth1: Running with NAPI enabled eth1: 256/256 RX/TX BD ring size Fixed MDIO Bus: probed Driver 'sd' needs updating - please use bus_type methods sata_sil :00:10.0: enabling device ( - 0003) sata_sil :00:10.0: cache line size not set. Driver may not function sata_sil :00:10.0: Applying R_ERR on DMA activate FIS errata fix scsi0 : sata_sil scsi1 : sata_sil scsi2 : sata_sil scsi3 : sata_sil ata1: SATA max UDMA/100 mmio [EMAIL PROTECTED] tf 0x9080 irq 22 ata2: SATA max UDMA/100 mmio [EMAIL PROTECTED] tf 0x90c0 irq 22 ata3: SATA max UDMA/100 mmio [EMAIL PROTECTED] tf 0x9280 irq 22 ata4:
Re: USB support on mpc5200 broken
Jon == Jon Smirl [EMAIL PROTECTED] writes: Hi, Jon Can u-boot handle the wrapped DTB? I'm using a pointer to kernel Jon and one to DTB when booting from u-boot. See my recent (nacked by Wolfgang, but sane in principle) patch for uImage.platform support: http://patchwork.ozlabs.org/patch/589/ Jon So I should wait for the version that uses FIT images. Well, yeah. As I said earlier, I won't have time to work on that right away, so you can either use the patch as is, wait or implement FIT support yourself. -- Bye, Peter Korsgaard ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] sputrace : use marker_synchronize_unregister()
On Mon, Sep 29, 2008 at 11:11:47AM -0400, Mathieu Desnoyers wrote: We need a marker_synchronize_unregister() before the end of exit() to make sure every probe callers have exited the non preemptible section and thus are not executing the probe code anymore. Looks good. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: USB support on mpc5200 broken
On Mon, Sep 29, 2008 at 01:43:29PM +1000, David Gibson wrote: On Sun, Sep 28, 2008 at 08:30:56PM -0500, Matt Sealey wrote: Benjamin Herrenschmidt wrote: On Wed, 2008-09-24 at 21:09 -0400, Jon Smirl wrote: 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. This doesn't look to me like a very reliable way to determine bigendian. You mean it's not reliable to expect people device-trees not to suck ? :-) Alas, this is true :(. It's reasonable to expect that device-trees do not get updated with the kernel for certain platforms (it does not fit into most quality assurance schedules to reflash every user's firmware every time they want to move up one revision to another, given the kernel release schedule of every 3-4 months) and when updating the search for compatible entries it should take into account these platforms. This, of course, is exactly why I *don't* recommend embedded platforms move to including the device tree in the flashed firmware. Keeping the device tree in the bootwrapper means that it *is* updated with the kernel and we don't have to mess around with as much backwards compatibility junk. This completely defeats the purpopse of having a separate device tree though, no ? I mean, we could just as well hardcode the device-tree info in the kernel in this case ? (In embedded cases, the kernel is usyually in the flash as well, so you just upgrade both at the same time :) Friendly, Sven Luther ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH v2] powerpc/math-emu: Use kernel generic math-emu code
On Sep 24, 2008, at 10:00 AM, Kumar Gala wrote: The math emulation code is centered around a set of generic macros that provide the core of the emulation that are shared by the various architectures and other projects (like glibc). Each arch implements its own sfp-machine.h to specific various arch specific details. For historic reasons that are now lost the powerpc math-emu code had its own version of the common headers. This moves us to using the kernel generic version and thus getting fixes when those are updated. Also cleaned up exception/error reporting from the FP emulation functions. Signed-off-by: Kumar Gala [EMAIL PROTECTED] --- With a better commit message, no code changes. - k since no one seems to have any comments on this I'm going to put it into my powerpc-next tree. - k ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: USB support on mpc5200 broken
Sven == Sven Luther [EMAIL PROTECTED] writes: Hi, This, of course, is exactly why I *don't* recommend embedded platforms move to including the device tree in the flashed firmware. Keeping the device tree in the bootwrapper means that it *is* updated with the kernel and we don't have to mess around with as much backwards compatibility junk. Sven This completely defeats the purpopse of having a separate Sven device tree though, no ? I mean, we could just as well hardcode Sven the device-tree info in the kernel in this case ? Well, yes and no. The device tree brings a number of advantages (and a few disadvantages as well), one of those being the potential decoupling of kernel and DT. Even if you don't make use of that feature in a production build you still have the other advantages (E.G. easy compile test of multiple boards, limited repeated-these-are-my-platform-devices code in board files, ...). Sven (In embedded cases, the kernel is usyually in the flash as Sven well, so you just upgrade both at the same time :) Sure, but if you do that you might as well include them in a single uImage because: - They are always in sync - You don't waste flash space (E.G. the DT is very small, but you waste a complete flash sector) With uImage.platform U-Boot can still fix up the tree before booting the kernel, so you don't lose any functionality (E.G. if you enable/disable certain nodes based on what option boards are available). -- Bye, Peter Korsgaard ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Disabling L1 D-cache and side effects
Hi, I had to bring up a PPC based SOC with L1 dcache disabled. I did that and tried to boot Linux using RAMDISK/NFS mount. In RAMDISK I see the file system errors. In case of NFS mount I see error saying failed to load ld.so library. Could you guys please share thoughts what are the different side effects might be causing this. Thanks, Marri From: Tirumala Reddy Marri Sent: Saturday, September 27, 2008 2:37 PM To: linuxppc-dev@ozlabs.org Subject: rootfs mount problem Hi , I am trying to bring up a new SOC. I am seeing the following error. Has any one seen this error before. I am pretty sure RAMDISK is not corrupted. Thanks, Marri --- LOG --- NET: Registered protocol family 17 RPC: Registered udp transport module. RPC: Registered tcp transport module. prepare_namespace line 361 prepare_namespace line 385 RAMDISK: Compressed image found at block 0 invalid compressed format (err=1) EXT3-fs error (device ram0): ext3_check_descriptors: Block bitmap for group 0 not in group (block 14728687)! EXT3-fs: group descriptors corrupted! EXT2-fs error (device ram0): ext2_check_descriptors: Block bitmap for group 0 not in group (block 14728687)! EXT2-fs: group descriptors corrupted! List of all partitions: No filesystem could mount root, tried: ext3 ext2 cramfs Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(1,0) Rebooting in 180 seconds..? U-Boot 1.3.2 (Sep 24 2008 - 14:25:32) --- back trace --- (gdb) bt #0 __delay (loops=80) at include/asm/time.h:97 #1 0xc001f07c in panic (fmt=Variable fmt is not available. ) at kernel/panic.c:115 #2 0xc0248dc4 in mount_block_root (name=0xc020f9f4 /dev/root, flags=32768) at init/do_mounts.c:277 #3 0xc02491b0 in prepare_namespace () at init/do_mounts.c:403 #4 0xc02489a8 in kernel_init (unused=Variable unused is not available. ) at init/main.c:878 #5 0xc000cf08 in kernel_thread () Previous frame inner to this frame (corrupt stack?) (gdb) --- ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
New dma-noncoherent code, looking for comment and people to test
Hi,
I rewrote dma-noncoherent.c and I am looking for people to review and test it
on various platforms that use it to make sure I did not introduce any bug.
The platforms affected by this change are those that define
CONFIG_NOT_COHERENT_CACHE:
ppc44x
walnut
makalu
kilauea
ep405
adder875
ep88xc
taishan
warp
sam440ep
sequoia
bamboo
canyonlands
rainier
katmai
ebony
mpc885_ads
mpc866_ads
ppc40x
c2k (already tested)
prpmc2800
The old code in dma-noncoherent.c uses a memory pool at a hard coded
virtual address set by CONFIG_CONSISTENT_START (typically 0xFF10). If not
set carefully this address can conflict with early ioremap in systems
that enable HIGHMEM, on top of that the code is overly complex because it
needs to have its own memory manager.
This is why I tried to re-implement the code using standard memory
management APIs. The new code does not require the user to set
CONFIG_CONSISTENT_START or CONFIG_CONSISTENT_SIZE, is much smaller and
simplier. It also can allocate as much memory as available in ZONE_DMA
(instead of being limited by CONFIG_CONSISTENT_SIZE).
I also removed the HIGHMEM support in dma_sync since memory allocated for
DMA transfer should always be in ZONE_DMA (ie not in ZONE_HIGHMEM).
Looking forward to any comment about why this code may not work or is not
as good as the original. If you do test this code on your platform, let me
know how it goes ... if no-one object and no bug is found I will submit
this patch in a month or so.
Thanks !
Remi
diff --git a/arch/powerpc/lib/dma-noncoherent.c
b/arch/powerpc/lib/dma-noncoherent.c
index 5d83907..6827ae9 100644
--- a/arch/powerpc/lib/dma-noncoherent.c
+++ b/arch/powerpc/lib/dma-noncoherent.c
@@ -29,143 +29,28 @@
#include linux/types.h
#include linux/highmem.h
#include linux/dma-mapping.h
+#include linux/vmalloc.h
#include asm/tlbflush.h
/*
- * This address range defaults to a value that is safe for all
- * platforms which currently set CONFIG_NOT_COHERENT_CACHE. It
- * can be further configured for specific applications under
- * the Advanced Setup menu. -Matt
- */
-#define CONSISTENT_BASE(CONFIG_CONSISTENT_START)
-#define CONSISTENT_END (CONFIG_CONSISTENT_START + CONFIG_CONSISTENT_SIZE)
-#define CONSISTENT_OFFSET(x) (((unsigned long)(x) - CONSISTENT_BASE)
PAGE_SHIFT)
-
-/*
- * This is the page table (2MB) covering uncached, DMA consistent allocations
- */
-static pte_t *consistent_pte;
-static DEFINE_SPINLOCK(consistent_lock);
-
-/*
- * VM region handling support.
- *
- * This should become something generic, handling VM region allocations for
- * vmalloc and similar (ioremap, module space, etc).
- *
- * I envisage vmalloc()'s supporting vm_struct becoming:
- *
- * struct vm_struct {
- *struct vm_region region;
- *unsigned longflags;
- *struct page **pages;
- *unsigned int nr_pages;
- *unsigned longphys_addr;
- * };
- *
- * get_vm_area() would then call vm_region_alloc with an appropriate
- * struct vm_region head (eg):
- *
- * struct vm_region vmalloc_head = {
- * .vm_list= LIST_HEAD_INIT(vmalloc_head.vm_list),
- * .vm_start = VMALLOC_START,
- * .vm_end = VMALLOC_END,
- * };
- *
- * However, vmalloc_head.vm_start is variable (typically, it is dependent on
- * the amount of RAM found at boot time.) I would imagine that get_vm_area()
- * would have to initialise this each time prior to calling vm_region_alloc().
- */
-struct vm_region {
- struct list_headvm_list;
- unsigned long vm_start;
- unsigned long vm_end;
-};
-
-static struct vm_region consistent_head = {
- .vm_list= LIST_HEAD_INIT(consistent_head.vm_list),
- .vm_start = CONSISTENT_BASE,
- .vm_end = CONSISTENT_END,
-};
-
-static struct vm_region *
-vm_region_alloc(struct vm_region *head, size_t size, gfp_t gfp)
-{
- unsigned long addr = head-vm_start, end = head-vm_end - size;
- unsigned long flags;
- struct vm_region *c, *new;
-
- new = kmalloc(sizeof(struct vm_region), gfp);
- if (!new)
- goto out;
-
- spin_lock_irqsave(consistent_lock, flags);
-
- list_for_each_entry(c, head-vm_list, vm_list) {
- if ((addr + size) addr)
- goto nospc;
- if ((addr + size) = c-vm_start)
- goto found;
- addr = c-vm_end;
- if (addr end)
- goto nospc;
- }
-
- found:
- /*
-* Insert this entry _before_ the one we found.
-*/
- list_add_tail(new-vm_list, c-vm_list);
- new-vm_start = addr;
- new-vm_end = addr + size;
-
- spin_unlock_irqrestore(consistent_lock, flags);
- return new;
-
- nospc:
- spin_unlock_irqrestore(consistent_lock, flags);
- kfree(new);
- out:
- return NULL;
-}
-
-static struct vm_region *vm_region_find(struct vm_region *head, unsigned long
addr)
-{
-
Re: Disabling L1 D-cache and side effects
On Mon, Sep 29, 2008 at 10:05:41AM -0700, Tirumala Reddy Marri wrote: Hi, I had to bring up a PPC based SOC with L1 dcache disabled. I did that and tried to boot Linux using RAMDISK/NFS mount. In RAMDISK I see the file system errors. In case of NFS mount I see error saying failed to load ld.so library. Could you guys please share thoughts what are the different side effects might be causing this. There are a number of things you have to be careful about when you disable caches. Depending on your implementation, you likely can't use lwarx/stwcx, cache ops will not work, etc. Also, are you 100% sure that this is caused only by disabling L1D, and not by any other problems with your silicon? If you're doing early bringup of you'll have a whole lot of debug work in front of you, and this mailing list is probably not the best place to bring your homework. -Olof ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: New dma-noncoherent code, looking for comment and people to test
On Sep 29, 2008, at 12:26 PM, Remi Machet wrote: Hi, I rewrote dma-noncoherent.c and I am looking for people to review and test it on various platforms that use it to make sure I did not introduce any bug. The platforms affected by this change are those that define CONFIG_NOT_COHERENT_CACHE: ppc44x walnut makalu kilauea ep405 adder875 ep88xc taishan warp sam440ep sequoia bamboo canyonlands rainier katmai ebony mpc885_ads mpc866_ads ppc40x c2k (already tested) prpmc2800 The old code in dma-noncoherent.c uses a memory pool at a hard coded virtual address set by CONFIG_CONSISTENT_START (typically 0xFF10). If not set carefully this address can conflict with early ioremap in systems that enable HIGHMEM, on top of that the code is overly complex because it needs to have its own memory manager. This is why I tried to re-implement the code using standard memory management APIs. The new code does not require the user to set CONFIG_CONSISTENT_START or CONFIG_CONSISTENT_SIZE, is much smaller and simplier. It also can allocate as much memory as available in ZONE_DMA (instead of being limited by CONFIG_CONSISTENT_SIZE). I also removed the HIGHMEM support in dma_sync since memory allocated for DMA transfer should always be in ZONE_DMA (ie not in ZONE_HIGHMEM). Looking forward to any comment about why this code may not work or is not as good as the original. If you do test this code on your platform, let me know how it goes ... if no-one object and no bug is found I will submit this patch in a month or so. Thanks ! Remi We really should change this code over to the new dma changes Becky's introduced so we just have a non-coherent set of DMA ops (thus we can do both non-coherent and coherent in the same system). - k ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: New dma-noncoherent code, looking for comment and people to test
I agree. Is someone already working on that or should I do it ? Remi On Mon, 2008-09-29 at 13:03 -0500, Kumar Gala wrote: On Sep 29, 2008, at 12:26 PM, Remi Machet wrote: Hi, I rewrote dma-noncoherent.c and I am looking for people to review and test it on various platforms that use it to make sure I did not introduce any bug. The platforms affected by this change are those that define CONFIG_NOT_COHERENT_CACHE: ppc44x walnut makalu kilauea ep405 adder875 ep88xc taishan warp sam440ep sequoia bamboo canyonlands rainier katmai ebony mpc885_ads mpc866_ads ppc40x c2k (already tested) prpmc2800 The old code in dma-noncoherent.c uses a memory pool at a hard coded virtual address set by CONFIG_CONSISTENT_START (typically 0xFF10). If not set carefully this address can conflict with early ioremap in systems that enable HIGHMEM, on top of that the code is overly complex because it needs to have its own memory manager. This is why I tried to re-implement the code using standard memory management APIs. The new code does not require the user to set CONFIG_CONSISTENT_START or CONFIG_CONSISTENT_SIZE, is much smaller and simplier. It also can allocate as much memory as available in ZONE_DMA (instead of being limited by CONFIG_CONSISTENT_SIZE). I also removed the HIGHMEM support in dma_sync since memory allocated for DMA transfer should always be in ZONE_DMA (ie not in ZONE_HIGHMEM). Looking forward to any comment about why this code may not work or is not as good as the original. If you do test this code on your platform, let me know how it goes ... if no-one object and no bug is found I will submit this patch in a month or so. Thanks ! Remi We really should change this code over to the new dma changes Becky's introduced so we just have a non-coherent set of DMA ops (thus we can do both non-coherent and coherent in the same system). - k ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: New dma-noncoherent code, looking for comment and people to test
On Sep 29, 2008, at 1:22 PM, Remi Machet wrote: I agree. Is someone already working on that or should I do it ? Remi I don't believe anyone is working on it. Also, top posting is frowned about. - k ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH] sputrace : use marker_synchronize_unregister()
We need a marker_synchronize_unregister() before the end of exit() to make sure every probe callers have exited the non preemptible section and thus are not executing the probe code anymore. Signed-off-by: Mathieu Desnoyers [EMAIL PROTECTED] CC: Ingo Molnar [EMAIL PROTECTED] CC: Jeremy Kerr [EMAIL PROTECTED] CC: linuxppc-dev@ozlabs.org CC: Christoph Hellwig [EMAIL PROTECTED] --- arch/powerpc/platforms/cell/spufs/sputrace.c |1 + 1 file changed, 1 insertion(+) Index: linux-2.6-lttng/arch/powerpc/platforms/cell/spufs/sputrace.c === --- linux-2.6-lttng.orig/arch/powerpc/platforms/cell/spufs/sputrace.c 2008-07-31 09:34:58.0 -0400 +++ linux-2.6-lttng/arch/powerpc/platforms/cell/spufs/sputrace.c 2008-07-31 09:35:15.0 -0400 @@ -233,6 +233,7 @@ static void __exit sputrace_exit(void) remove_proc_entry(sputrace, NULL); kfree(sputrace_log); + marker_synchronize_unregister(); } module_init(sputrace_init); -- Mathieu Desnoyers OpenPGP key fingerprint: 8CD5 52C3 8E3C 4140 715F BA06 3F25 A8FE 3BAE 9A68 ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [RFC] powerpc/boot: add kernel,end node to the cuboot target
* Milton Miller | 2008-09-23 20:24:02 [-0500]: If you have any questions about kdump or what needs to happen, please feel free to contact me either by email or on irc (sometimes I use mdm other times the email login as my nick, and when connected I tend to leave it well past the hours I am at the computer). I copied most of the 64bit code to parse the device tree without the pci nodes moved it to 32. The userland *could* work, I'm not sure. My outout is: |load: entry = 0x80053c flags = 0 |nr_segments = 2 |segment[0].buf = 0x1002b8f0 |segment[0].bufsz = 80 |segment[0].mem = (nil) |segment[0].memsz = 1000 |segment[1].buf = 0x4803f008 |segment[1].bufsz = 3a3138 |segment[1].mem = 0x80 |segment[1].memsz = 3b Now. The entry address in image-start is valid and is the entrypoint of the custom cuImage. Custom means that it does not depend any register values passed from u-boot (the original one needs a pointer to bd_t). The only requirement is a valid 1:1 memory mapping. I learned, that I can not disable the MMU on Book-E so I have to create a new temporary mapping in my relocate_new_kernel routine. _start is doing the same thing what I am trying to accomplish: create a new mapping and don't kill the current one and switch over. This is done by disabling all mappings but the current, creating a new mapping with EFN/RPN = 0 and swapping the TS bit in MAS1. This is my current patch which is not really working: diff --git a/arch/powerpc/kernel/misc_32.S b/arch/powerpc/kernel/misc_32.S index 7a6dfbc..49c9c2a 100644 --- a/arch/powerpc/kernel/misc_32.S +++ b/arch/powerpc/kernel/misc_32.S @@ -878,22 +878,142 @@ relocate_new_kernel: /* r4 = reboot_code_buffer */ /* r5 = start_address */ - li r0, 0 + mr r27, r4 + mr r28, r5 + mr r29, r6 + + li r25,0 /* phys kernel start (low) */ + li r24,0 /* CPU number */ + li r23,0 /* phys kernel start (high) */ + + +/* 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 */ +#ifndef CONFIG_E200 + mfspr r7,SPRN_MAS1 + andis. r7,r7,[EMAIL PROTECTED] + bne match_TLB The branch above is taken, so I've found my current mapping + mfspr r7,SPRN_PID1 + slwir7,r7,16 + or r7,r7,r4 + mtspr SPRN_MAS6,r7 + tlbsx 0,r6/* search MSR[IS], SPID=PID1 */ + mfspr r7,SPRN_MAS1 + andis. r7,r7,[EMAIL PROTECTED] + bne match_TLB + mfspr r7, SPRN_PID2 + slwir7,r7,16 + or r7,r7,r4 + mtspr SPRN_MAS6,r7 + tlbsx 0,r6/* Fall through, we had to match */ +#endif +match_TLB: + + 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 */ - /* -* Set Machine Status Register to a known status, -* switch the MMU off and jump to 1: in a single step. -*/ + /* Invalidate TLB0 */ + li r6,0x04 + tlbivax 0,r6 + TLBSYNC + /* Invalidate TLB1 */ + li r6,0x0c + tlbivax 0,r6 + TLBSYNC - mr r8, r0 - ori r8, r8, MSR_RI|MSR_ME - mtspr SPRN_SRR1, r8 - addir8, r4, 1f - relocate_new_kernel - mtspr SPRN_SRR0, r8 - sync +/* 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
Re: USB support on mpc5200 broken
On Mon, Sep 29, 2008 at 10:14:18AM -0400, Jon Smirl wrote: Shouldn't the driver already know it is being used on a BE machine? No. Endianness of the CPU is not necessarily the same as the endianness of device registers. For example, PCI OHCI on a big-endian host. -Scott ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
RE: Disabling L1 D-cache and side effects
Olof, Thanks for the response. Is there a piece of code in Linux which does the Machine check recovery and continue normal execution ? Thanks and Regards, Marri -Original Message- From: Olof Johansson [mailto:[EMAIL PROTECTED] Sent: Monday, September 29, 2008 11:05 AM To: Tirumala Reddy Marri Cc: linuxppc-dev@ozlabs.org Subject: Re: Disabling L1 D-cache and side effects On Mon, Sep 29, 2008 at 10:05:41AM -0700, Tirumala Reddy Marri wrote: Hi, I had to bring up a PPC based SOC with L1 dcache disabled. I did that and tried to boot Linux using RAMDISK/NFS mount. In RAMDISK I see the file system errors. In case of NFS mount I see error saying failed to load ld.so library. Could you guys please share thoughts what are the different side effects might be causing this. There are a number of things you have to be careful about when you disable caches. Depending on your implementation, you likely can't use lwarx/stwcx, cache ops will not work, etc. Also, are you 100% sure that this is caused only by disabling L1D, and not by any other problems with your silicon? If you're doing early bringup of you'll have a whole lot of debug work in front of you, and this mailing list is probably not the best place to bring your homework. -Olof ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: USB support on mpc5200 broken
On Mon, Sep 29, 2008 at 4:18 PM, Scott Wood [EMAIL PROTECTED] wrote: On Mon, Sep 29, 2008 at 10:14:18AM -0400, Jon Smirl wrote: Shouldn't the driver already know it is being used on a BE machine? No. Endianness of the CPU is not necessarily the same as the endianness of device registers. For example, PCI OHCI on a big-endian host. Endianess is encoded in the specific compatible string. compatible = fsl,mpc5200b-ohci,fsl,mpc5200-ohci; This is BE. inside PCI bus section compatible = my-pci-ohci-card This would be LE The specifically loaded driver knows it's endianess. But now you're tell me I need compatible = fsl,mpc5200b-ohci,fsl,mpc5200-ohci, ohci-be But that doesn't work right on the mpc5200. If I remove the mpc5200 specific device driver from my system it will cause the generic ohci-be one to load. And the generic one doesn't work. The mpc5200 ohci device driver should be setting the endianess state into the generic ohci code. -Scott -- Jon Smirl [EMAIL PROTECTED] ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: Disabling L1 D-cache and side effects
On Mon, Sep 29, 2008 at 02:00:06PM -0700, Tirumala Reddy Marri wrote: Olof, Thanks for the response. Is there a piece of code in Linux which does the Machine check recovery and continue normal execution ? Yes, there is. Several pieces, actually. -Olof ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
How to prevent embedded ppc reset deadlock? (MPC83xx/85xx)
Hello all, not Linux related per se*, but I wonder how your board designs deal with the reset circuitry for embedded PowerPC processors (MPC8313E in my case). My requirement is that both a processor-external hard reset and processor-internal hard reset must both reset the boot device NOR FlashROM, so that it does not remain in write mode (if it is). Given those processor pins: PORESET# (input pin to the processor, power on reset) HRESET# (bidirectional pin on the processor, asserted by processor on hard reset such as watchdog) I see many designs (even the Freescale reference designs) where the HRESET# resets some of the board, but not the FlashROM, and where PORESET# resets the FlashROM. This can cause a deadlock in the case where the watchdog resets during writing to FlashROM, as the FlashROM is not reset and remains in write mode, not allowing the processor to boot from it. I am thinking of using this approach: PORESET# - processor -- HRESET# - board reset. Would that work? or why not? Regards, -- Leon * to make this Linux related: suppose MTD is writing new firmware to your NOR FlashROM and then /dev/wdg is not petted due to some programmer bug in the firmware update code. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
RE: Disabling L1 D-cache and side effects
Hi Olof, I see code in arch/powerpc/kernel/traps.c . But only cbe_machine_check_handler() is the only function assigned to ppc_md.machine_check_exception. Which is also not doing any recovery. It just dumps the registers and return 0. Which would cause system Panic. Could you please point me to the which does the Critical error (Machine Check) recovery. BTW I am successful booting the Linux until rootfs is being mounted. It fails to mount the Linux saying that blocks are corrupted in file system. I had to modify lots of initial bring up code to disable D-cache and make sure all TLB's are cache inhibited. Ando also made sure none of the misc_32.S , entry_32.S and head.S makes any references to d-cache. Thanks, Marri -Original Message- From: Olof Johansson [mailto:[EMAIL PROTECTED] Sent: Monday, September 29, 2008 2:14 PM To: Tirumala Reddy Marri Cc: linuxppc-dev@ozlabs.org Subject: Re: Disabling L1 D-cache and side effects On Mon, Sep 29, 2008 at 02:00:06PM -0700, Tirumala Reddy Marri wrote: Olof, Thanks for the response. Is there a piece of code in Linux which does the Machine check recovery and continue normal execution ? Yes, there is. Several pieces, actually. -Olof ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: USB support on mpc5200 broken
On Mon, Sep 29, 2008 at 05:04:22PM -0400, Jon Smirl wrote: On Mon, Sep 29, 2008 at 4:18 PM, Scott Wood [EMAIL PROTECTED] wrote: On Mon, Sep 29, 2008 at 10:14:18AM -0400, Jon Smirl wrote: Shouldn't the driver already know it is being used on a BE machine? No. Endianness of the CPU is not necessarily the same as the endianness of device registers. For example, PCI OHCI on a big-endian host. Endianess is encoded in the specific compatible string. compatible = fsl,mpc5200b-ohci,fsl,mpc5200-ohci; This is BE. inside PCI bus section compatible = my-pci-ohci-card This would be LE The specifically loaded driver knows it's endianess. But now you're tell me I need compatible = fsl,mpc5200b-ohci,fsl,mpc5200-ohci, ohci-be No, we can't do that. You're right about the current data in compatible being sufficient. The kernel needs to deal with what firmware hands it, either by fixups to the device tree data or by teaching the driver what fsl,mpc5200b-ohci means. g. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: How to prevent embedded ppc reset deadlock? (MPC83xx/85xx)
Hello André, On Mon, Sep 29, 2008 at 11:50 PM, André Schwarz [EMAIL PROTECTED] wrote: Leon, you're right. PORESET is just there to prevent the core from running as long as power may be unstable and/or PLLs are out of lock. HRESET is the signal that should reset everything. I did it on my board and it works fine. Understood so far. Since you also have to assert HRESET when you assert PORESET But when I assert PORESET, the processor will assert HRESET itself AFAIK, so why do this? you can wire-or them with a low drop schottky diode. Ooh, analog electronics, long time ago. Let me think: arrow of diode symbol pointing from HRESET# to PORESET#, right, so that PORESET# going low will pull HRESET# low enough, right? Hope this helps. Yes it does, thanks. Regards, Leon. Leon Woestenberg wrote: Hello all, not Linux related per se*, but I wonder how your board designs deal with the reset circuitry for embedded PowerPC processors (MPC8313E in my case). My requirement is that both a processor-external hard reset and processor-internal hard reset must both reset the boot device NOR FlashROM, so that it does not remain in write mode (if it is). Given those processor pins: PORESET# (input pin to the processor, power on reset) HRESET# (bidirectional pin on the processor, asserted by processor on hard reset such as watchdog) I see many designs (even the Freescale reference designs) where the HRESET# resets some of the board, but not the FlashROM, and where PORESET# resets the FlashROM. This can cause a deadlock in the case where the watchdog resets during writing to FlashROM, as the FlashROM is not reset and remains in write mode, not allowing the processor to boot from it. I am thinking of using this approach: PORESET# - processor -- HRESET# - board reset. Would that work? or why not? Regards, MATRIX VISION GmbH, Talstraße 16, DE-71570 Oppenweiler - Registergericht: Amtsgericht Stuttgart, HRB 271090 Geschäftsführer: Gerhard Thullner, Werner Armingeon, Uwe Furtner -- Leon ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] sputrace : use marker_synchronize_unregister()
Mathieu, We need a marker_synchronize_unregister() before the end of exit() to make sure every probe callers have exited the non preemptible section and thus are not executing the probe code anymore. Looks good - added to spufs.git. Cheers, Jeremy ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: USB support on mpc5200 broken
On Mon, Sep 29, 2008 at 05:18:54PM +0200, Sven Luther wrote: On Mon, Sep 29, 2008 at 01:43:29PM +1000, David Gibson wrote: On Sun, Sep 28, 2008 at 08:30:56PM -0500, Matt Sealey wrote: Benjamin Herrenschmidt wrote: On Wed, 2008-09-24 at 21:09 -0400, Jon Smirl wrote: 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. This doesn't look to me like a very reliable way to determine bigendian. You mean it's not reliable to expect people device-trees not to suck ? :-) Alas, this is true :(. It's reasonable to expect that device-trees do not get updated with the kernel for certain platforms (it does not fit into most quality assurance schedules to reflash every user's firmware every time they want to move up one revision to another, given the kernel release schedule of every 3-4 months) and when updating the search for compatible entries it should take into account these platforms. This, of course, is exactly why I *don't* recommend embedded platforms move to including the device tree in the flashed firmware. Keeping the device tree in the bootwrapper means that it *is* updated with the kernel and we don't have to mess around with as much backwards compatibility junk. This completely defeats the purpopse of having a separate device tree though, no ? I mean, we could just as well hardcode the device-tree info in the kernel in this case ? And just what form would hardcoded device info take in the kernel? The *primary* purpose of the device-tree is to have a consistent in-kernel representation of the hardware information. A device-tree was the obvious choice, because OF machines already used it, and it's flexible enough to cover pretty much anything. How the kernel gets a device tree doesn't matter so much - we don't really care if it comes from OF, from some other firmware or if it's built into the kernel or wrapper. Being able to pass in the device tree is a secondary advantage in *some* circumstances - albeit one people seem to have leapt on with unwise enthusiasm, IMO. This approachd also has drawbacks which can override the advantages - specifically that firmware has always been buggy as hell more often than not, so there's absolutely no reason to expect that firmware will get a device tree right. -- 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: USB support on mpc5200 broken
..wasn't the real issue for the device tree to get the firmware right? RB On Mon, Sep 29, 2008 at 8:12 PM, David Gibson [EMAIL PROTECTED] wrote: On Mon, Sep 29, 2008 at 05:18:54PM +0200, Sven Luther wrote: On Mon, Sep 29, 2008 at 01:43:29PM +1000, David Gibson wrote: On Sun, Sep 28, 2008 at 08:30:56PM -0500, Matt Sealey wrote: Benjamin Herrenschmidt wrote: On Wed, 2008-09-24 at 21:09 -0400, Jon Smirl wrote: 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. This doesn't look to me like a very reliable way to determine bigendian. You mean it's not reliable to expect people device-trees not to suck ? :-) Alas, this is true :(. It's reasonable to expect that device-trees do not get updated with the kernel for certain platforms (it does not fit into most quality assurance schedules to reflash every user's firmware every time they want to move up one revision to another, given the kernel release schedule of every 3-4 months) and when updating the search for compatible entries it should take into account these platforms. This, of course, is exactly why I *don't* recommend embedded platforms move to including the device tree in the flashed firmware. Keeping the device tree in the bootwrapper means that it *is* updated with the kernel and we don't have to mess around with as much backwards compatibility junk. This completely defeats the purpopse of having a separate device tree though, no ? I mean, we could just as well hardcode the device-tree info in the kernel in this case ? And just what form would hardcoded device info take in the kernel? The *primary* purpose of the device-tree is to have a consistent in-kernel representation of the hardware information. A device-tree was the obvious choice, because OF machines already used it, and it's flexible enough to cover pretty much anything. How the kernel gets a device tree doesn't matter so much - we don't really care if it comes from OF, from some other firmware or if it's built into the kernel or wrapper. Being able to pass in the device tree is a secondary advantage in *some* circumstances - albeit one people seem to have leapt on with unwise enthusiasm, IMO. This approachd also has drawbacks which can override the advantages - specifically that firmware has always been buggy as hell more often than not, so there's absolutely no reason to expect that firmware will get a device tree right. -- 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 -- http://bbrv.blogspot.com/ ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Please pull 'merge' branch of deputy powerpc.git tree
Hi Linus ! The following changes since commit 94aca1dac6f6d21f4b07e4864baf7768cabcc6e7: Linus Torvalds (1): Linux 2.6.27-rc8 are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/benh/powerpc.git merge Those are two fixes for regressions introduced recently, the first one due to some change in the timer code becoming more sensitive to timer interrupts taken from offlined CPUs and the second is an update to a board device-tree to fix some address translation problems. arch/powerpc/boot/dts/holly.dts | 106 +++--- arch/powerpc/kernel/idle.c |6 +-- 2 files changed, 54 insertions(+), 58 deletions(-) (Oh and please let me know what I screwed up this time :-) commit 61e9916eba35dfb76d38013a5aae9a59cc50877a Author: Johannes Berg [EMAIL PROTECTED] Date: Wed Sep 24 22:56:25 2008 + powerpc: Fix failure to shutdown with CPU hotplug I tracked down the shutdown regression to CPUs not dying when being shut down during power-off. This turns out to be due to the system_state being SYSTEM_POWER_OFF, which this code doesn't take as a valid state for shutting off CPUs in. This has never made sense to me, but when I added hotplug code to implement hibernate I only made it work and did not question the need to check the system_state. Thomas Gleixner helped me dig, but the only thing we found is that it was added with the original commit that added CPU hotplug support. Signed-off-by: Johannes Berg [EMAIL PROTECTED] Acked-by: Joel Schopp [EMAIL PROTECTED] Signed-off-by: Benjamin Herrenschmidt [EMAIL PROTECTED] commit ad611045ce5d059af84a9855b22ca3f7a99d47be Author: David Gibson [EMAIL PROTECTED] Date: Wed Sep 24 16:39:04 2008 + powerpc: Fix PCI in Holly device tree The PCI bridge on the Holly board is incorrectly represented in the device tree. The current device tree node for the PCI bridge sits under the tsi-bridge node. That's not obviously wrong, but the PCI bridge translates some PCI spaces into CPU address ranges which were not translated by the ranges property in tsi-bridge node. We used to get away with this problem because the PCI bridge discovery code was also buggy, assuming incorrectly that PCI host bridge nodes were always directly under the root bus and treating the translated addresses as raw CPU addresses, rather than parent bus addresses. This has since been fixed, thus breaking Holly. This could be fixed by adding extra translations to the tsi-bridge node, but this patch instead moves the Holly PCI bridge out of the tsi-bridge node to the root bus. This makes the tsi-bridge node represent only the built-in IO devices in the bridge, with a more-or-less contiguous address range. This is the same convention used on Freescale SoC chips, where the soc node represents only the IMMR region, and the PCI and other bus bridges are separate nodes under the root bus. Signed-off-by: David Gibson [EMAIL PROTECTED] Acked-by: Josh Boyer [EMAIL PROTECTED] Signed-off-by: Benjamin Herrenschmidt [EMAIL PROTECTED] ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
