* Re: [PATCH 1/3] MSI driver for Freescale 83xx/85xx/86xx cpu
From: Michael Ellerman @ 2008-04-21 6:21 UTC (permalink / raw)
To: Jason Jin; +Cc: linuxppc-dev, kumar.gala
In-Reply-To: <1208597267-30960-1-git-send-email-Jason.jin@freescale.com>
[-- Attachment #1: Type: text/plain, Size: 18413 bytes --]
> This MSI driver can be used on 83xx/85xx/86xx board.
> In this driver, virtual interrupt host and chip were
> setup. There are 256 MSI interrupts in this host, Every 32
> MSI interrupts cascaded to one IPIC/MPIC interrupt.
> The chip was treated as edge sensitive and some necessary
> functions were setup for this chip.
>
> Before using the MSI interrupt, PCI/PCIE device need to
> ask for a MSI interrupt in the 256 MSI interrupts. A 256bit
> bitmap show which MSI interrupt was used, reserve bit in
> the bitmap can be used to force the device use some designate
> MSI interrupt in the 256 MSI interrupts. Sometimes this is useful
> for testing the all the MSI interrupts. The msi-available-ranges
> property in the dts file was used for this purpose.
Hi Jason, some comments inline ...
> diff --git a/arch/powerpc/sysdev/Makefile b/arch/powerpc/sysdev/Makefile
> index 6d386d0..bfd3fe4 100644
> --- a/arch/powerpc/sysdev/Makefile
> +++ b/arch/powerpc/sysdev/Makefile
> @@ -4,6 +4,7 @@ endif
>
> mpic-msi-obj-$(CONFIG_PCI_MSI) += mpic_msi.o mpic_u3msi.o mpic_pasemi_msi.o
> obj-$(CONFIG_MPIC) += mpic.o $(mpic-msi-obj-y)
> +obj-$(CONFIG_PCI_MSI) += fsl_msi.o
Do we really always want to build this if we have MSI? Might it depend
on something else as well? CONFIG_FSL_PCI maybe?
> diff --git a/arch/powerpc/sysdev/fsl_msi.c b/arch/powerpc/sysdev/fsl_msi.c
> new file mode 100644
> index 0000000..e8132cf
> --- /dev/null
> +++ b/arch/powerpc/sysdev/fsl_msi.c
> @@ -0,0 +1,457 @@
> +/*
> + * Copyright (C) 2007-2008 Freescale Semiconductor, Inc. All rights reserved.
> + *
> + * Author: Tony Li <tony.li@freescale.com>
> + * Jason Jin <Jason.jin@freescale.com>
> + *
> + * This program is free software; you can redistribute it and/or
> + * modify it under the terms of the GNU General Public License
> + * as published by the Free Software Foundation; version 2 of the
> + * License.
> + *
> + */
> +
> +#include <linux/irq.h>
> +#include <linux/bootmem.h>
> +#include <linux/bitmap.h>
> +#include <linux/msi.h>
> +#include <asm/prom.h>
> +#include <asm/hw_irq.h>
> +#include <linux/pci.h>
> +#include <asm/ppc-pci.h>
> +#include <linux/of_platform.h>
> +
> +#include <sysdev/fsl_soc.h>
> +#include "fsl_msi.h"
People consider it good style to have the linux includes before the
asm includes.
> +#ifdef DEBUG
> +#define pr_debug(fmt...) printk(fmt)
> +#else
> +#define pr_debug(fmt...)
> +#endif
Please don't do this, just use pr_debug(). In fact I don't see where you
do use it :)
> +/* A bit ugly, can we get this from the pci_dev somehow? */
> +static struct fsl_msi *fsl_msi;
I recognise that comment :) The answer is "no" we can't (easily) get
this from the pci_dev.
> +static inline u32 fsl_msi_read(u32 __iomem *base,
> + unsigned int reg)
This would fit in 80 chars wouldn't it?
> +{
> + return in_be32(base + (reg >> 2));
> +}
> +
> +static inline void fsl_msi_write(u32 __iomem *base,
> + unsigned int reg, u32 value)
> +{
> + out_be32(base + (reg >> 2), value);
> +}
> +
> +#define fsl_msi_irq_to_hw(virq) ((unsigned int)irq_map[virq].hwirq)
I can't see where this is used, you probably don't need it.
> +/*
> + * We do not need this actually. The MSIR register has been read once
> + * in the cascade interrupt. So, this MSI interrupt has been acked
> +*/
> +static void fsl_msi_end_irq(unsigned int virq)
> +{
> +}
I guess the generic code assumes you have an ack, bummer.
> +static struct irq_chip fsl_msi_chip = {
> + .mask = mask_msi_irq,
> + .unmask = unmask_msi_irq,
> + .ack = fsl_msi_end_irq,
> + .typename = " FSL-MSI ",
I'd rather you didn't try and pad the name by hand, if we want /proc/interrupts
to look pretty we should do that in show_interrupts().
> +static int fsl_msi_host_match(struct irq_host *h, struct device_node *node)
> +{
> + struct fsl_msi *msi = h->host_data;
> +
> + /* Exact match, unless node is NULL */
> + return msi->of_node == NULL || msi->of_node == node;
> +}
Do you really want the MSI to be the default irq host?
> +static int fsl_msi_host_map(struct irq_host *h, unsigned int virq,
> + irq_hw_number_t hw)
> +{
> + struct fsl_msi *msi = h->host_data;
> + struct irq_chip *chip = msi->hc_irq;
> +
> + set_irq_chip_data(virq, msi);
You don't seem to use chip_data anywhere?
> + get_irq_desc(virq)->status |= IRQ_TYPE_EDGE_FALLING;
> +
> + set_irq_chip_and_handler(virq, chip, handle_edge_irq);
> +
> + return 0;
> +}
> +
> +static struct irq_host_ops fsl_msi_host_ops = {
> + .match = fsl_msi_host_match,
> + .map = fsl_msi_host_map,
> +};
> +
> +irq_hw_number_t fsl_msi_alloc_hwirqs(struct fsl_msi *msi, int num)
> +{
> + unsigned long flags;
> + int offset, order = get_count_order(num);
> +
> + spin_lock_irqsave(&msi->bitmap_lock, flags);
> +
> + offset = bitmap_find_free_region(msi->fsl_msi_bitmap,
> + NR_MSI_IRQS, order);
> +
> + spin_unlock_irqrestore(&msi->bitmap_lock, flags);
> +
> + pr_debug("%s: allocated 0x%x (2^%d) at offset 0x%x\n",
> + __func__, num, order, offset);
> +
> + return offset;
> +}
> +
> +void fsl_msi_free_hwirqs(struct fsl_msi *msi, int offset, int num)
> +{
> + unsigned long flags;
> + int order = get_count_order(num);
> +
> + pr_debug("%s: freeing 0x%x (2^%d) at offset 0x%x\n",
> + __func__, num, order, offset);
> +
> + spin_lock_irqsave(&msi->bitmap_lock, flags);
> + bitmap_release_region(msi->fsl_msi_bitmap, offset, order);
> + spin_unlock_irqrestore(&msi->bitmap_lock, flags);
> +}
> +
> +static int fsl_msi_reserve_dt_hwirqs(struct fsl_msi *msi)
> +{
> + int i, len;
> + const u32 *p;
> +
> + p = of_get_property(msi->of_node, "msi-available-ranges", &len);
> + if (!p) {
> + pr_debug("fsl_msi: no msi-available-ranges property found \
> + on %s\n", msi->of_node->full_name);
> + return -ENODEV;
> + }
> +
> + if (len & 0x8 != 0) {
> + printk(KERN_WARNING "fsl_msi: Malformed msi-available-ranges "
> + "property on %s\n", msi->of_node->full_name);
> + return -EINVAL;
> + }
Do you really want a bitwise and with 0x8?
> +
> + bitmap_allocate_region(msi->fsl_msi_bitmap, 0,
> + get_count_order(msi->irq_count));
> +
> + /* Format is: (<u32 start> <u32 count>)+ */
> + len /= sizeof(u32);
> + len /= 2;
> + for (i = 0; i < len; i++, p += 2)
> + fsl_msi_free_hwirqs(msi, *p, *(p + 1));
> +
> + return 0;
> +}
We could share a bunch of that code with mpic_msi.c, but that's not your
job - I'll look at doing a patch once this goes in.
> +static int fsl_msi_init_allocator(struct fsl_msi *msi)
> +{
> + int rc, size;
> +
> + size = BITS_TO_LONGS(NR_MSI_IRQS) * sizeof(long);
> +
> + msi->fsl_msi_bitmap = kmalloc(size, GFP_KERNEL);
> +
> + if (msi->fsl_msi_bitmap == NULL) {
> + pr_debug("%s: ENOMEM allocating allocator bitmap!\n",
> + __func__);
> + return -ENOMEM;
> + }
> + memset(msi->fsl_msi_bitmap, 0, size);
Use kzalloc() and you can lose the memset.
> + rc = fsl_msi_reserve_dt_hwirqs(msi);
This routine is badly named (my fault), it really frees the available
MSI ranges.
> + if (rc)
> + goto out_free;
> +
> + return 0;
> +out_free:
> + if (mem_init_done)
> + kfree(msi->fsl_msi_bitmap);
You don't need to test mem_init_done, this is running at initcall time
which is way later than mem_init.
> + msi->fsl_msi_bitmap = NULL;
> + return rc;
> +
> +}
> +
> +static int fsl_msi_check_device(struct pci_dev *pdev, int nvec, int type)
> +{
> + if (type == PCI_CAP_ID_MSIX)
> + pr_debug("fslmsi: MSI-X untested, trying anyway.\n");
> +
> + return 0;
> +}
> +
> +static void fsl_teardown_msi_irqs(struct pci_dev *pdev)
> +{
> + struct msi_desc *entry;
> + struct fsl_msi *msi = fsl_msi;
> +
> + list_for_each_entry(entry, &pdev->msi_list, list) {
> + if (entry->irq == NO_IRQ)
> + continue;
> + set_irq_msi(entry->irq, NULL);
> + fsl_msi_free_hwirqs(msi, virq_to_hw(entry->irq), 1);
> + irq_dispose_mapping(entry->irq);
> + }
> +
> + return;
> +}
> +
> +static void fsl_compose_msi_msg(struct pci_dev *pdev, int hwirq,
> + struct msi_msg *msg)
> +{
> + unsigned int srs;
> + unsigned int ibs;
> + struct fsl_msi *msi = fsl_msi;
> +
> + srs = hwirq / INT_PER_MSIR;
> + ibs = hwirq % INT_PER_MSIR;
> +
> + msg->address_lo = msi->msi_addr_lo;
> + msg->address_hi = msi->msi_addr_hi;
> + msg->data = (srs << 5) | (ibs & 0x1F);
Is the 5 and 0x1F independent of the INT_PER_MSIR value? Given the
current values isn't this a no-op, or am I missing something?
> + pr_debug("%s: allocated srs: %d, ibs: %d\n",
> + __func__, srs, ibs);
> +}
> +
> +static int fsl_setup_msi_irqs(struct pci_dev *pdev, int nvec, int type)
> +{
> + irq_hw_number_t hwirq;
> + int rc;
> + unsigned int virq;
> + struct msi_desc *entry;
> + struct msi_msg msg;
> + struct fsl_msi *msi = fsl_msi;
A couple of places you put this into a local called "msi" which is not the
greatest name in the world IMHO :)
> + list_for_each_entry(entry, &pdev->msi_list, list) {
> + hwirq = fsl_msi_alloc_hwirqs(msi, 1);
> + if (hwirq < 0) {
> + rc = hwirq;
> + pr_debug("%s: fail allocating msi interrupt\n",
> + __func__);
> + goto out_free;
> + }
> +
> + virq = irq_create_mapping(msi->irqhost, hwirq);
> +
> + if (virq == NO_IRQ) {
> + pr_debug("%s: fail mapping hwirq 0x%lx\n",
> + __func__, hwirq);
> + fsl_msi_free_hwirqs(msi, hwirq, 1);
> + rc = -ENOSPC;
> + goto out_free;
> + }
> + set_irq_msi(virq, entry);
> +
> + fsl_compose_msi_msg(pdev, hwirq, &msg);
> + write_msi_msg(virq, &msg);
> + }
> + return 0;
> +
> +out_free:
> + fsl_teardown_msi_irqs(pdev);
You don't need to call teardown, the generic code does that for you.
> + return rc;
> +}
> +
> +void fsl_msi_cascade(unsigned int irq, struct irq_desc *desc)
> +{
> + unsigned int cascade_irq;
> + struct fsl_msi *msi = fsl_msi;
> + int msir_index = -1;
> + int i;
> + u32 msir_value = 0;
> + u32 intr_index;
> + u32 have_shift = 0;
> +
> + spin_lock(&desc->lock);
> + if ((msi->feature & FSL_PIC_IP_MASK) == FSL_PIC_IP_IPIC) {
> + if (desc->chip->mask_ack)
> + desc->chip->mask_ack(irq);
> + else {
> + desc->chip->mask(irq);
> + desc->chip->ack(irq);
> + }
> + }
> +
> + if (unlikely(desc->status & IRQ_INPROGRESS))
> + goto unlock;
> +
> + for (i = 0; i < NR_MSIR; i++)
> + if (irq == msi->msir[i]) {
> + msir_index = i;
> + break;
> + }
This is a bit ugly :) Because you get the *msi from fsl_msi (above), you could
store the msir_index in the handler_data (with set_irq_data), and save doing
this loop.
> + if (i >= NR_MSIR)
> + cascade_irq = NO_IRQ;
> +
> + desc->status |= IRQ_INPROGRESS;
> + switch (fsl_msi->feature & FSL_PIC_IP_MASK) {
> + case FSL_PIC_IP_MPIC:
> + msir_value = fsl_msi_read(msi->msi_regs, msir_index * 0x10);
> + break;
> + case FSL_PIC_IP_IPIC:
> + msir_value = fsl_msi_read(msi->msi_regs, msir_index * 0x4);
> + break;
> + }
> +
> + while (msir_value) {
> + intr_index = ffs(msir_value) - 1;
> +
> + cascade_irq = irq_linear_revmap(msi->irqhost,
> + (msir_index * INT_PER_MSIR + intr_index + have_shift));
> +
> + if (cascade_irq != NO_IRQ)
> + generic_handle_irq(cascade_irq);
> + have_shift += (intr_index + 1);
> + msir_value = (msir_value >> (intr_index + 1));
> + }
It took me a while to grok all the shifting and so on here, I don't know if
there's a cleaner way to do it.
> + desc->status &= ~IRQ_INPROGRESS;
> +
> + switch (fsl_msi->feature & FSL_PIC_IP_MASK) {
> + case FSL_PIC_IP_MPIC:
> + desc->chip->eoi(irq);
> + break;
> + case FSL_PIC_IP_IPIC:
> + if (!(desc->status & IRQ_DISABLED) && desc->chip->unmask)
> + desc->chip->unmask(irq);
Missing indent.
> + break;
> + }
> +unlock:
> + spin_unlock(&desc->lock);
> +}
> +
> +static int __devinit fsl_of_msi_probe(struct of_device *dev,
> + const struct of_device_id *match)
> +{
> + struct fsl_msi *msi;
> + struct resource res;
> + int err, i, count;
> + int rc;
> + int virt_msir;
> + const u32 *p;
> + struct fsl_msi_data *tmp_data;
> +
> + printk(KERN_INFO "Setting up fsl msi support\n");
KERN_DEBUG would do here IMHO, users don't usually need to see it.
> + msi = kzalloc(sizeof(struct fsl_msi), GFP_KERNEL);
> + if (!msi) {
> + dev_err(&dev->dev, "No memory for MSI structure\n");
> + err = -ENOMEM;
> + goto error_out;
> + }
> +
> + msi->of_node = dev->node;
> +
> + msi->irqhost = irq_alloc_host(of_node_get(dev->node),
> + IRQ_HOST_MAP_LINEAR,
> + NR_MSI_IRQS, &fsl_msi_host_ops, 0);
> + if (msi->irqhost == NULL) {
> + dev_err(&dev->dev, "No memory for MSI irqhost\n");
> + err = -ENOMEM;
You need an of_node_put(dev->node) in the error case here.
> + goto error_out;
> + }
> +
> + /*Get the MSI reg base */
Missing space after /*
> + err = of_address_to_resource(dev->node, 0, &res);
> + if (err) {
> + dev_err(&dev->dev, "Can't get %s property 'reg'\n",
> + dev->node->full_name);
That's a little misleading, aren't there's lots of reasons
of_address_to_resource() might fail?
> + goto error_out;
> + }
> +
> + msi->msi_regs = ioremap(res.start, res.end - res.start + 1);
ioremap() can fail.
> + tmp_data = (struct fsl_msi_data *)match->data;
> +
> + msi->feature = tmp_data->fsl_pic_ip;
> +
> + msi->irqhost->host_data = msi;
> + msi->hc_irq = &fsl_msi_chip;
Any reason this needs to be a variable, isn't it always &fsl_msi_chip?
> + msi->msi_addr_hi = 0x0;
> + msi->msi_addr_lo = res.start + tmp_data->msiir_offset;
> +
> + msi->irq_count = NR_MSI_IRQS;
Ditto.
> + p = of_get_property(dev->node, "interrupts", &count);
> + if (!p) {
> + dev_err(&dev->dev, "no msi-interrupts property found on %s\n",
> + dev->node->full_name);
> + err = -ENODEV;
> + goto error_out;
> + }
> + if (count % 8 != 0) {
> + dev_err(&dev->dev, "Malformed msi-interrupts property on %s\n",
> + dev->node->full_name);
Messages don't match the code, "interrupts" vs "msi-interrupts".
> + err = -EINVAL;
> + goto error_out;
> + }
> +
> + count /= sizeof(u32);
> + for (i = 0; i < count / 2; i++) {
> + if (i > NR_MSIR)
> + break;
> + virt_msir = irq_of_parse_and_map(dev->node, i);
> + if (virt_msir != NO_IRQ) {
> + set_irq_data(virt_msir, msi);
> + set_irq_chained_handler(virt_msir, fsl_msi_cascade);
> + msi->msir[i] = virt_msir;
> + } else
> + msi->msir[i] = NO_IRQ;
> + }
> +
> + rc = fsl_msi_init_allocator(msi);
> + if (rc) {
> + dev_err(&dev->dev, "Error allocating MSI bitmap\n");
If you hit this then the error case needs to get rid of all the irq mappings
you created just above (which it doesn't). It would be simpler if you just move
this call above the for loop, then you don't need to worry about it.
> + goto error_out;
> + }
> +
> + fsl_msi = msi;
> +
> + WARN_ON(ppc_md.setup_msi_irqs);
> + ppc_md.setup_msi_irqs = fsl_setup_msi_irqs;
> + ppc_md.teardown_msi_irqs = fsl_teardown_msi_irqs;
> + ppc_md.msi_check_device = fsl_msi_check_device;
> + return 0;
> +error_out:
> + if (msi)
> + kfree(msi);
kfree(NULL) is fine.
> + return err;
> +}
> +
> +static const struct fsl_msi_data mpic_msi_feature = {FSL_PIC_IP_MPIC, 0x140};
> +static const struct fsl_msi_data ipic_msi_feature = {FSL_PIC_IP_IPIC, 0x38};
> +
> +static const struct of_device_id fsl_of_msi_ids[] = {
> + {
> + .compatible = "fsl,MPIC-MSI",
> + .data = (void *)&mpic_msi_feature,
> + },
> + {
> + .compatible = "fsl,IPIC-MSI",
> + .data = (void *)&ipic_msi_feature,
> + },
> + {}
> +};
> +
> +static struct of_platform_driver fsl_of_msi_driver = {
> + .name = "fsl-of-msi",
> + .match_table = fsl_of_msi_ids,
> + .probe = fsl_of_msi_probe,
> +};
> +
> +static __init int fsl_of_msi_init(void)
> +{
> + return of_register_platform_driver(&fsl_of_msi_driver);
> +}
> +
> +subsys_initcall(fsl_of_msi_init);
> diff --git a/arch/powerpc/sysdev/fsl_msi.h b/arch/powerpc/sysdev/fsl_msi.h
> new file mode 100644
> index 0000000..7eef9ec
> --- /dev/null
> +++ b/arch/powerpc/sysdev/fsl_msi.h
> @@ -0,0 +1,40 @@
> +#ifndef _ASM_POWERPC_MSI_H
> +#define _ASM_POWERPC_MSI_H
Include guards don't match the filename, should be _POWERPC_SYSDEV_FSL_MSI_H
> +#define NR_MSIR 8
> +#define INT_PER_MSIR 32
> +#define NR_MSI_IRQS (NR_MSIR * INT_PER_MSIR)
> +
> +#define FSL_PIC_IP_MASK 0x0000000F
> +#define FSL_PIC_IP_MPIC 0x00000001
> +#define FSL_PIC_IP_IPIC 0x00000002
> +
> +struct fsl_msi {
> + /* Device node of the MSI interrupt*/
> + struct device_node *of_node;
> +
> + struct irq_host *irqhost;
> + struct irq_chip *hc_irq;
> +
> + unsigned long cascade_irq;
> + unsigned int msir[NR_MSIR];
> +
> + u32 msi_addr_lo;
> + u32 msi_addr_hi;
> + void __iomem *msi_regs;
> + u32 irq_count;
> + u32 feature;
> +
> + spinlock_t fsl_msi_lock;
Unused?
> + unsigned long *fsl_msi_bitmap;
Do we need fsl_msi in the name?
> + spinlock_t bitmap_lock;
> + const char *name;
Unused?
> +};
> +
> +struct fsl_msi_data {
> + u32 fsl_pic_ip;
> + u32 msiir_offset;
> +};
> +
> +#endif /* _ASM_POWERPC_MSI_H */
> +
> diff --git a/arch/powerpc/sysdev/fsl_pci.c b/arch/powerpc/sysdev/fsl_pci.c
> index bf13c21..fede767 100644
> --- a/arch/powerpc/sysdev/fsl_pci.c
> +++ b/arch/powerpc/sysdev/fsl_pci.c
> @@ -106,6 +106,16 @@ void __init setup_pci_cmd(struct pci_controller *hose)
> }
> }
>
> +#ifdef CONFIG_PCI_MSI
> +void __init setup_pci_pcsrbar(struct pci_controller *hose)
> +{
> + phys_addr_t immr_base;
> +
> + immr_base = get_immrbase();
> + early_write_config_dword(hose, 0, 0, PCI_BASE_ADDRESS_0, immr_base);
> +}
> +#endif
Up to you, but I prefer an empty static inline here which saves an #ifdef
at the call site.
> static int fsl_pcie_bus_fixup;
>
> static void __init quirk_fsl_pcie_header(struct pci_dev *dev)
> @@ -211,6 +221,10 @@ int __init fsl_add_bridge(struct device_node *dev, int is_primary)
> /* Setup PEX window registers */
> setup_pci_atmu(hose, &rsrc);
>
> + /*Setup PEXCSRBAR */
> +#ifdef CONFIG_PCI_MSI
> + setup_pci_pcsrbar(hose);
> +#endif
> return 0;
> }
cheers
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* DMA on AMCC ppc440epx
From: Leonid @ 2008-04-21 4:55 UTC (permalink / raw)
To: Linuxppc-embedded
Hi:
Is anybody using DMA on this AMCC CPU and if anybody knows where I can
get some sample working code or HOWTO documentation or anything?
I never used DMA on AMCC CPUs but have heard there are some problems but
I am not sure.
Thanks,
Leonid.
^ permalink raw reply
* RE: [PATCH 1/2] [v3][POWERPC] refactor dcr code
From: Stephen Neuendorffer @ 2008-04-21 3:56 UTC (permalink / raw)
To: Josh Boyer; +Cc: linuxppc-dev
In-Reply-To: <20080419093500.752c1930@zod.rchland.ibm.com>
[-- Attachment #1: Type: text/plain, Size: 1036 bytes --]
> > +void dcr_unmap_generic(dcr_host_t host, unsigned int dcr_c)
> > +{
> > + if (host.type == NATIVE)
> > + dcr_unmap_native(host.host.native, dcr_c);
> > + else
> > + dcr_unmap_mmio(host.host.mmio, dcr_c);
>
> What happens if host.type == INVALID? Same question for the other
> accessors in dcr_*_generic.
I guess looking back on it, I assumed that MAP_OK would return 0, meaning that behavior was undefined,
but I agree it's probably safer to have some error reporting there... There starts to become a speed tradeoff
at some point, which would make function pointers more attractive. If the ioremap does fail, or the
dcr-access-method can't be determined, then dcr_unmap_mmio would probably SEGV anyway, although that's
not something I'd really want to rely on. I'll put an error case in there.
> > +enum host_type_t {MMIO, NATIVE, INVALID};
>
> Should these be DCR_HOST_MMIO, DCR_HOST_NATIVE, DCR_HOST_INVALID?
>
> I worry about the generic nature of the names.
Also seems reasonable,
Steve
[-- Attachment #2: Type: text/html, Size: 1748 bytes --]
^ permalink raw reply
* Help! mpc8247 porting kernel 2.6.25 problem.
From: 张世乐 @ 2008-04-21 3:06 UTC (permalink / raw)
To: Linuxppc-embedded
Hi All,
I encounter a problem when porting kernel 2.6.25 to a mpc8247 platform board.
after run command line: bootm 300000 - 600000
the output of u-boot like this:
[snip]
Uncompressing Kernel Image ... OK
Booting using the fdt at 0x600000
[nothing output and hanging here]
I use the led on the board to trace the kernel fund it stop in the function
setup_common_caches in arch/powerpc/kernel/cpu_setup_6xx.S
Can you give me some ideas?
Thanks!
^ permalink raw reply
* Re: [PATCH 2.6.26?] Raise the upper limit of NR_CPUS.
From: Benjamin Herrenschmidt @ 2008-04-21 2:03 UTC (permalink / raw)
To: Tony Breeds; +Cc: LinuxPPC-dev, Paul Mackerras
In-Reply-To: <20080418053349.GE20457@bakeyournoodle.com>
On Fri, 2008-04-18 at 15:33 +1000, Tony Breeds wrote:
> As the pacas are statically initialised increasing NR_CPUS beyond 128,
> means that any additional pacas will be empty ... which is bad.
>
> This patch adds the required functionality to fill in any excess pacas
> at runtime.
>
> Signed-off-by: Tony Breeds <tony@bakeyournoodle.com>
> ---
> I know it's late, but can this be considered for 2.6.26?
NAK.
You must NEVER manipulate kernel globals from prom_init.c. The fact that
prom_init is linked with the kernel is an "accident" which may change.
Your scheme would break among others with kexec or non-OF bootloaders
Ben.
^ permalink raw reply
* Re: [PATCH 2.6.26?] Raise the upper limit of NR_CPUS.
From: Tony Breeds @ 2008-04-21 1:41 UTC (permalink / raw)
To: Michael Ellerman; +Cc: LinuxPPC-dev, Paul Mackerras
In-Reply-To: <1208514829.8424.0.camel@concordia>
On Fri, Apr 18, 2008 at 08:33:44PM +1000, Michael Ellerman wrote:
> What happens on non prom-init platforms?
.... Um yeah they wont work.
I'll try a slightly different approach.
Yours Tony
linux.conf.au http://www.marchsouth.org/
Jan 19 - 24 2009 The Australian Linux Technical Conference!
^ permalink raw reply
* Re: Xilinx PowerPC
From: David H. Lynch Jr. @ 2008-04-20 23:48 UTC (permalink / raw)
To: Grant Likely; +Cc: linuxppc-embedded
In-Reply-To: <fa686aa40804201548o503e9b19p4081cec653a1acd2@mail.gmail.com>
Thanks,
I have alot of work to do on our stuff, I might as well see if I can
move to the powerpc tree at the same time.
BTW is there even the beginings of a non-xilinx lltemac driver out
there ? There were hints on the list, but I have not seen anything.
I would be happy to help advance the ball on anything anyone has
started.
Grant Likely wrote:
> On Sun, Apr 20, 2008 at 2:31 PM, David H. Lynch Jr. <dhlii@dlasys.net> wrote:
>
>> Thanks.
>>
>> I am running linus's 2.6.25-rc9, but I can pull the Xilinx tree or
>> yours - when your server is up.
>>
>> I can not find any Xilinx powerpc configs in arch/powerpc/config
>> Do I just need to do a
>> make ARCH=powerpc menuconfig and create one from scratch ?
>>
>
> That's right; I haven't merged any defconfigs. Roll your own.
>
>
>> Is simpleboot in your tree or the xilinx tree, if can not find it
>> in Linus's ?
>>
>
> If you want to use the "simpleboot" wrapper; then you'll need to pull
> paulus' tree (Linus hasn't yet pulled his tree; but he probably will
> any moment now).
>
> Cheers,
> g.
>
>
--
Dave Lynch DLA Systems
Software Development: Embedded Linux
717.627.3770 dhlii@dlasys.net http://www.dlasys.net
fax: 1.253.369.9244 Cell: 1.717.587.7774
Over 25 years' experience in platforms, languages, and technologies too numerous to list.
"Any intelligent fool can make things bigger and more complex... It takes a touch of genius - and a lot of courage to move in the opposite direction."
Albert Einstein
^ permalink raw reply
* Re: UartLite
From: Grant Likely @ 2008-04-20 23:02 UTC (permalink / raw)
To: David H. Lynch Jr.; +Cc: linuxppc-dev
In-Reply-To: <480BA62D.5020904@dlasys.net>
BTW, you should really be asking these questions on the linuxppc mailing list
On Sun, Apr 20, 2008 at 2:23 PM, David H. Lynch Jr. <dhlii@dlasys.net> wrote:
> I have been looking more and more at the kernel uartlite driver.
> Somewhere along the line while I was not watching PK's driver has
> developed alot stronger resemblance to most normal serial drivers. I am
> seriously thinking of putting some effort into getting it working for
> me, and then pushing my polling patch for interrupt free implimentations.
>
> But I have tripped over several things that trouble me. Though I am not
> a serial driver expert.
>
> The first is that all the Uartlite related definitions tend to create a
> BaseAddress+3 definition.
> This really bothers me, it presumes that the registers are all 4 bytes
> apart - I know that is the norm
> and I have never actually seen a different implimentation, but I do not
> think it is set in stone.
> It also is basically a cleaver trick to get readb/writeb to work without
> adjustment.
> Endian issues tend to give me headaches, but somehow I think there is an
> endian issue in this.
> All the port offsets are defined with the presumption the registers are
> 4 bytes apart.
> Despite the fact that all the offsets masks and bits are needed in
> several files, they are not in a header.
Yes, I'm not a big fan of the +3 either; but it is expedient. I think
the best solution is to encode it into the device tree by adding
optional "reg-stride" and "reg-offset" properties (at least for memory
mapped implementations).
We can define another binding for the DCR version.
> If I can manage to get the thing to work for me,
> Am I going to be stepping on any toes if I make changes to adress my
> concerns above ?
I've got no problem reworking the register accessor functions.
> I really want to migrate all the direct IO to a ulite_in() and
> ulite_out() routine.
> Letting those two routines deal with all the issues of BaseAddress,
> register size, endianness, register shift,
> and even whether access is via DCR - I have seen atleast one
> implimentation that was DCR.
>
> I would like to remove the +3 from all the macro's etc. as it seems to
> me to confuse what is actually going on.
>
> I did a diff merge against my own driver a few days ago and aside from
> these issues, order of functions, some naming issues, the absence of OF
> support in my driver, and the presence of polling in mine, the code now
> very very strongly parallels my code now. So it should not be alot of
> work to merge my code into the standard driver now.
>
> I will be happy to do this - presuming I am not going to be stepping on
> any toes.
> I would be happy to not have to support a separate driver, but the stock
> driver has to work with my hardware.
> It still does not, but I think the code is now close enough for me to
> track down and kill the problem.
Cheers,
g.
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
^ permalink raw reply
* Re: [RFC fs_enet: Convert MII bitbang driver to use GPIO lib
From: Grant Likely @ 2008-04-20 22:42 UTC (permalink / raw)
To: Laurent Pinchart; +Cc: linuxppc-dev, netdev
In-Reply-To: <200804161640.42693.laurentp@cse-semaphore.com>
On Wed, Apr 16, 2008 at 8:40 AM, Laurent Pinchart
<laurentp@cse-semaphore.com> wrote:
> This patch converts the MII bitband driver to use GPIO lib for GPIO access.
> The driver can now handle MDC and MDIO on different GPIO banks.
>
> The patch depends on Anton Vorontsov GPIO lib support scheduled for 2.6.26.
> It is by no means complete, I just would like to get some feedback on the
> approach. I'll resubmit it when the CPM2 GPIO support patches will be
> available in the powerpc git tree.
I agree with Anton; nice rework. This would be useful on other
platforms too. Comment below.
> --- a/Documentation/powerpc/booting-without-of.txt
> +++ b/Documentation/powerpc/booting-without-of.txt
> @@ -2030,21 +2030,19 @@ platforms are moved over to use the flattened-device-tree model.
> fsl,cpm2-mdio-bitbang (reg is port C registers)
>
> Properties for fsl,cpm2-mdio-bitbang:
> - fsl,mdio-pin : pin of port C controlling mdio data
> - fsl,mdc-pin : pin of port C controlling mdio clock
> + gpios : GPIOs controlling mdio clock and mdio data (in that order).
>
> Example:
>
> - mdio@10d40 {
> + mdio {
> device_type = "mdio";
> compatible = "fsl,mpc8272ads-mdio-bitbang",
> "fsl,mpc8272-mdio-bitbang",
> "fsl,cpm2-mdio-bitbang";
I think it would be better for the defined binding to use something
like "virtual,mdio-bitbang" or "gpio-mdio". (I like the first better,
but there is already some precedence with the "gpio-led" driver. I
think there is less chance of namespace conflicts with the first)
Of course; the *driver* could also accept these additional compatible
values for backwards compatibility.
Cheers,
g.
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
^ permalink raw reply
* Re: pci issue - wrong detection of pci ressources
From: Benjamin Herrenschmidt @ 2008-04-20 21:36 UTC (permalink / raw)
To: Christian Ehrhardt; +Cc: Hollis Blanchard, linuxppc-dev
In-Reply-To: <480BA937.7050603@linux.vnet.ibm.com>
> Yes you're right. Early at the pci initialization are errors of the allocation for pi ressources.
> And that are exactly the ressources failing later, so that pci initialization seem to be the reason for my problem.
> Was there any simple solution (e.g. just somehow increase memory reserved for pci) when you came across that issue Johan ?
Hrm... I was expecting to see a lot more output here, make sure you have
"debug" on your command line (or enable early debug output, same
effect).
Cheers,
Ben.
^ permalink raw reply
* Re: pci issue - wrong detection of pci ressources
From: Christian Ehrhardt @ 2008-04-20 20:36 UTC (permalink / raw)
To: benh, Johan Borkhuis; +Cc: linuxppc-dev, Hollis Blanchard
In-Reply-To: <1208566122.6958.425.camel@pasglop>
[-- Attachment #1: Type: text/plain, Size: 6882 bytes --]
Johan Borkhuis wrote:
> Hello Christian,
>
> Christian Ehrhardt wrote:
>> Hi,
>> I tried to use a radeon r200 based graphic card on a sequoia ppc
>> (440epx) board. I wondered about the initialization of radeonfb that
>> failed with
>> __ioremap(): phys addr 0x0 is RAM lr c029cf80
>> radeonfb (0000:00:0a.0): cannot map MMIO
>> radeonfb: probe of 0000:00:0a.0 failed with error -5
>>
[...]
>
> I came across a similar problem, which (ultimately) was caused by a lack
> of memory reserved for PCI. I moved from 2.6.14(ppc) to 2.6.20(powerpc),
> and suddenly some cards stopped working: the BAR registers were not
> initialized, so it was not possible to access the cards.
> Have a look at the boot-time messages, especially the early messages, as
> the PCI subsystem is started very early in the boot process. You could
> also try switching on PCI-debugging, and have a look at the debug
> messages, or add some extra debugging info to the pci-initialization code.
Yes you're right. Early at the pci initialization are errors of the allocation for pi ressources.
And that are exactly the ressources failing later, so that pci initialization seem to be the reason for my problem.
Was there any simple solution (e.g. just somehow increase memory reserved for pci) when you came across that issue Johan ?
With DEBUG in pci-common.c enabled (bad kernel) and a extension showing which functions alloc fails (put a %s for __func__):
PCI host bridge /plb/pci@1ec000000 (primary) ranges:
MEM 0x0000000180000000..0x000000018fffffff -> 0x0000000080000000
IO 0x00000001e8000000..0x00000001e80fffff -> 0x0000000000000000
4xx PCI DMA offset set to 0x00000000
PCI: Probing PCI hardware
PCI: Hiding 4xx host bridge resources 0000:00:00.0
Try to map irq for 0000:00:00.0...
-> got one, spec 2 cells (0x00000003 0x00000008...) on /interrupt-controller2
-> mapped to linux irq 16
Try to map irq for 0000:00:0a.0...
-> got one, spec 2 cells (0x00000003 0x00000008...) on /interrupt-controller2
-> mapped to linux irq 16
Try to map irq for 0000:00:0a.1...
PCI: PHB (bus 0) bridge rsrc 0: 0000000000000000-00000000000fffff [0x100], parent c0363060 (PCI IO)
PCI: PHB (bus 0) bridge rsrc 1: 0000000180000000-000000018fffffff [0x200], parent c0363038 (PCI mem)
PCI: Assigning unassigned resouces...
PCI: pci_assign_resource - Failed to allocate mem resource #6:20000@190000000 for 0000:00:0a.0
PCI: pci_assign_resource - Failed to allocate mem resource #2:10000@190000000 for 0000:00:0a.0
PCI: pci_assign_resource - Failed to allocate mem resource #1:10000@190000000 for 0000:00:0a.1
--
Grüsse / regards,
Christian Ehrhardt
IBM Linux Technology Center, Open Virtualization
########
To be complete for the case we might need it I answer all the other questions:
Benjamin Herrenschmidt wrote:
> On Fri, 2008-04-18 at 14:07 +0200, Christian Ehrhardt wrote:
>> => Region 2 is not detected with our kernel, this later break things
>> like radeonfb initialization.
>
> I'll need some information here:
>
> - Your device-tree (is that the base sequoia one ?)
DTS File is the normal sequoia.dts file in arch/powerpc/boot/dts with the latest change being:
user: Stefan Roese <sr@denx.de>
date: Fri Feb 15 21:35:30 2008 -0600
summary: [POWERPC] 4xx: Remove "i2c" and "xxmii-interface" device_types from dts
> - Enable DEBUG in arch/powerpc/kernel/pci-common.c and pci_32.c
> - Send me the resulting dmesg log
done - full dmesg attached
> - Also include the output of /proc/iomem
/proc/iomem - bad kernel
root@sequoia:~# cat /proc/iomem
e0000300-e000038f : ehci_hcd
180000000-18fffffff : /plb/pci@1ec000000
180000000-187ffffff : 0000:00:0a.0
188000000-18fffffff : 0000:00:0a.1
1ef600300-1ef600307 : serial
1ef600400-1ef600407 : serial
1ef600500-1ef600507 : serial
1ef600600-1ef600607 : serial
1fc000000-1ffffffff : 1fc000000.nor_flash
/proc/iomem - good kernel
root@sequoia:~# cat /proc/iomem
80000000-8fffffff : PCI host bridge
80000000-8000ffff : 0000:00:0a.1
80020000-8003ffff : 0000:00:0a.0
87ff0000-87ffffff : 0000:00:0a.0
87ff0000-87ffffff : radeonfb mmio
88000000-8fffffff : 0000:00:0a.0
88000000-8fffffff : radeonfb framebuffer
d0000000-d0001fff : ndfc-nand.0
e0000100-e000017f : musbhsfc_udc.0
e0000100-e000017f : musbhsfc_udc
e0000300-e00003ff : ppc-soc-ehci.0
e0000400-e00004ff : ppc-soc-ohci.0
fc000000-ffffffff : physmap-flash.0
fc000000-ffffffff : physmap-flash.0
> Actually, there's a bug in radeonfb:
>
> In radeonfb.h, try changing
>
> unsigned long mmio_base_phys;
> unsigned long fb_base_phys;
>
> To
>
> resource_size_t mmio_base_phys;
> resource_size_t fb_base_phys;
This did not fix the issue, as we have seen that it is caused earlier in pci initialization.
But that fix corrects the code if it is useful in my case or not ;-)
########
Sergei Shtylyov wrote:
> Christian Ehrhardt wrote:
>
[...]
>> Bad kernel:
>> 00:0a.0 VGA compatible controller: ATI Technologies Inc RV280 [Radeon
>> 9200 PRO] (rev 01) (prog-if 00 [VGA])
>> Subsystem: PC Partner Limited Unknown device 0250
>> Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop-
>> ParErr- Stepping- SERR- FastB2B-
>> Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium
>> >TAbort- <TAbort- <MAbort- >SERR- <PERR-
>> Latency: 128 (2000ns min)
>> Interrupt: pin A routed to IRQ 16
>> Region 0: Memory at 180000000 (32-bit, prefetchable) [size=128M]
>
> That's beyond 4 GB, seems correct. That should be the address
> assigned by bootloader? BTW, what's your bootloader, U-Boot?
Yes a modified u-boot
>
>> Region 1: I/O ports at 1000 [size=256]
>> Region 2: Memory at <ignored> (32-bit, non-prefetchable)
>
> Hm... what could this mean? Could you post the result of 'lspci -x'?
lspci -xvvv (bad kernel)
00:0a.0 VGA compatible controller: ATI Technologies Inc RV280 [Radeon 9200 PRO] (rev 01) (prog-if 00 [VGA])
Subsystem: PC Partner Limited Unknown device 0250
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B-
Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR-
Latency: 128 (2000ns min)
Interrupt: pin A routed to IRQ 16
Region 0: Memory at 180000000 (32-bit, prefetchable) [size=128M]
Region 1: I/O ports at 1000 [size=256]
Region 2: Memory at <ignored> (32-bit, non-prefetchable)
Capabilities: [50] Power Management version 2
Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-)
Status: D0 PME-Enable- DSel=0 DScale=0 PME-
00: 02 10 60 59 07 00 90 02 01 00 00 03 00 80 80 00
10: 08 00 00 80 01 10 00 00 00 00 00 88 00 00 00 00
20: 00 00 00 00 00 00 00 00 00 00 00 00 4b 17 50 02
30: 00 00 00 00 50 00 00 00 00 00 00 00 43 01 08 00
[-- Attachment #2: pci_resource_alocation_fails.dmesg.txt --]
[-- Type: text/plain, Size: 10968 bytes --]
Using Sequoia machine description
Linux version 2.6.25-rc9-dirty (paelzer@HeliosPrime.boeblingen.de.ibm.com) (gcc version 4.0.0 (DENX ELDK 4.1 4.0.0)) #7 Sun Apr 20 21:14:50 CEST 2008
Found legacy serial port 0 for /plb/opb/serial@ef600300
mem=1ef600300, taddr=1ef600300, irq=0, clk=11059200, speed=115200
Found legacy serial port 1 for /plb/opb/serial@ef600400
mem=1ef600400, taddr=1ef600400, irq=0, clk=11059200, speed=0
Found legacy serial port 2 for /plb/opb/serial@ef600500
mem=1ef600500, taddr=1ef600500, irq=0, clk=4385964, speed=0
Found legacy serial port 3 for /plb/opb/serial@ef600600
mem=1ef600600, taddr=1ef600600, irq=0, clk=4385964, speed=0
console [udbg0] enabled
Entering add_active_range(0, 0, 65536) 0 entries of 256 used
Top of RAM: 0x10000000, Total RAM: 0x10000000
Memory hole size: 0MB
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
On node 0 totalpages: 65536
DMA zone: 512 pages used for memmap
DMA zone: 0 pages reserved
DMA zone: 65024 pages, LIFO batch:15
Normal zone: 0 pages used for memmap
Movable zone: 0 pages used for memmap
Built 1 zonelists in Zone order, mobility grouping on. Total pages: 65024
Kernel command line: console=ttyS0,115200 ip=dhcp nfsroot=192.168.1.2:/home/paelzer/ubuntu_ppc root=/dev/nfs rw
UIC0 (32 IRQ sources) at DCR 0xc0
UIC1 (32 IRQ sources) at DCR 0xd0
UIC2 (32 IRQ sources) at DCR 0xe0
PID hash table entries: 1024 (order: 10, 4096 bytes)
time_init: decrementer frequency = 666.666660 MHz
time_init: processor frequency = 666.666660 MHz
clocksource: timebase mult[600000] shift[22] registered
clockevent: decrementer mult[aaaa] shift[16] cpu[0]
Console: colour dummy device 80x25
Dentry cache hash table entries: 32768 (order: 5, 131072 bytes)
Inode-cache hash table entries: 16384 (order: 4, 65536 bytes)
Memory: 255744k/262144k available (3448k kernel code, 6052k reserved, 152k data, 153k bss, 156k init)
Calibrating delay loop... 1331.20 BogoMIPS (lpj=2662400)
Mount-cache hash table entries: 512
net_namespace: 440 bytes
NET: Registered protocol family 16
PCI host bridge /plb/pci@1ec000000 (primary) ranges:
MEM 0x0000000180000000..0x000000018fffffff -> 0x0000000080000000
IO 0x00000001e8000000..0x00000001e80fffff -> 0x0000000000000000
4xx PCI DMA offset set to 0x00000000
PCI: Probing PCI hardware
PCI: Hiding 4xx host bridge resources 0000:00:00.0
Try to map irq for 0000:00:00.0...
-> got one, spec 2 cells (0x00000003 0x00000008...) on /interrupt-controller2
-> mapped to linux irq 16
Try to map irq for 0000:00:0a.0...
-> got one, spec 2 cells (0x00000003 0x00000008...) on /interrupt-controller2
-> mapped to linux irq 16
Try to map irq for 0000:00:0a.1...
PCI: PHB (bus 0) bridge rsrc 0: 0000000000000000-00000000000fffff [0x100], parent c0363060 (PCI IO)
PCI: PHB (bus 0) bridge rsrc 1: 0000000180000000-000000018fffffff [0x200], parent c0363038 (PCI mem)
PCI: Assigning unassigned resouces...
PCI: pci_assign_resource - Failed to allocate mem resource #6:20000@190000000 for 0000:00:0a.0
PCI: pci_assign_resource - Failed to allocate mem resource #2:10000@190000000 for 0000:00:0a.0
PCI: pci_assign_resource - Failed to allocate mem resource #1:10000@190000000 for 0000:00:0a.1
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
Switched to high resolution mode on CPU 0
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
JFFS2 version 2.2. (NAND) © 2001-2006 Red Hat, Inc.
io scheduler noop registered
io scheduler anticipatory registered (default)
io scheduler deadline registered
io scheduler cfq registered
radeonfb_pci_register BEGIN
radeonfb_pci_register - resource0 0x1 - 0x80000000
radeonfb_pci_register - resource1 0x0 - 0x1000
radeonfb_pci_register - resource2 0x0 - 0x0
radeonfb_pci_register - got pci ressources fb_base_phys 0x1 mmio_base_phys 0x80000000
radeonfb_pci_register - call ioremap for base 0 and size 0
__ioremap(): phys addr 0x0 is RAM lr c029cf88 - mem_init_done 1 highmem@10000000
radeonfb (0000:00:0a.0): cannot map MMIO
radeonfb: probe of 0000:00:0a.0 failed with error -5
Linux agpgart interface v0.103
[drm] Initialized drm 1.1.0 20060810
[drm] Initialized radeon 1.28.0 20060524 on minor 0
Serial: 8250/16550 driver $Revision: 1.90 $ 4 ports, IRQ sharing enabled
serial8250.0: ttyS0 at MMIO 0x1ef600300 (irq = 17) is a 16550A
console handover: boot [udbg0] -> real [ttyS0]
serial8250.0: ttyS1 at MMIO 0x1ef600400 (irq = 18) is a 16550A
serial8250.0: ttyS2 at MMIO 0x1ef600500 (irq = 19) is a 16550A
serial8250.0: ttyS3 at MMIO 0x1ef600600 (irq = 20) is a 16550A
1ef600300.serial: ttyS0 at MMIO 0x1ef600300 (irq = 17) is a 16550A
1ef600400.serial: ttyS1 at MMIO 0x1ef600400 (irq = 18) is a 16550A
1ef600500.serial: ttyS2 at MMIO 0x1ef600500 (irq = 19) is a 16550A
1ef600600.serial: ttyS3 at MMIO 0x1ef600600 (irq = 20) is a 16550A
brd: module loaded
PPC 4xx OCP EMAC driver, version 3.54
MAL v2 /plb/mcmal, 2 TX channels, 2 RX channels
ZMII /plb/opb/emac-zmii@ef600d00 initialized
RGMII /plb/opb/emac-rgmii@ef601000 initialized with MDIO support
/plb/opb/emac-rgmii@ef601000: input 0 in RGMII mode
eth0: EMAC-0 /plb/opb/ethernet@ef600e00, MAC 00:10:ec:00:e2:3e
eth0: found Marvell 88E1111 Ethernet PHY (0x00)
/plb/opb/emac-rgmii@ef601000: input 1 in RGMII mode
eth1: EMAC-1 /plb/opb/ethernet@ef600f00, MAC 00:10:ec:80:e2:3e
eth1: found Marvell 88E1111 Ethernet PHY (0x01)
tun: Universal TUN/TAP device driver, 1.6
tun: (C) 1999-2004 Max Krasnyansky <maxk@qualcomm.com>
Driver 'sd' needs updating - please use bus_type methods
1fc000000.nor_flash: Found 1 x16 devices at 0x0 in 16-bit bank
Amd/Fujitsu Extended Query Table at 0x0040
1fc000000.nor_flash: CFI does not contain boot bank location. Assuming top.
number of CFI chips: 1
cfi_cmdset_0002: Disabling erase-suspend-program due to code brokenness.
RedBoot partition parsing not available
of-flash: probe of 1fc000000.nor_flash failed with error -22
ppc-of-ehci e0000300.ehci: OF EHCI
ppc-of-ehci e0000300.ehci: new USB bus registered, assigned bus number 1
ppc-of-ehci e0000300.ehci: irq 32, io mem 0xe0000300
ppc-of-ehci e0000300.ehci: USB 2.0 started, EHCI 1.00, driver 10 Dec 2004
usb usb1: configuration #1 chosen from 1 choice
hub 1-0:1.0: USB hub found
hub 1-0:1.0: 1 port detected
usb usb1: New USB device found, idVendor=1d6b, idProduct=0002
usb usb1: New USB device strings: Mfr=3, Product=2, SerialNumber=1
usb usb1: Product: OF EHCI
usb usb1: Manufacturer: Linux 2.6.25-rc9-dirty ehci_hcd
usb usb1: SerialNumber: PPC-OF USB
USB Universal Host Controller Interface driver v3.0
Initializing USB Mass Storage driver...
usb 1-1: new high speed USB device using ppc-of-ehci and address 2
usb 1-1: configuration #1 chosen from 1 choice
hub 1-1:1.0: USB hub found
hub 1-1:1.0: 4 ports detected
usb 1-1: New USB device found, idVendor=05e3, idProduct=0608
usb 1-1: New USB device strings: Mfr=0, Product=1, SerialNumber=0
usb 1-1: Product: USB2.0 Hub
usb 1-1.1: new low speed USB device using ppc-of-ehci and address 3
usb 1-1.1: configuration #1 chosen from 1 choice
usb 1-1.1: New USB device found, idVendor=04b3, idProduct=310c
usb 1-1.1: New USB device strings: Mfr=0, Product=2, SerialNumber=0
usb 1-1.1: Product: USB Optical Mouse
usb 1-1.2: new full speed USB device using ppc-of-ehci and address 4
usb 1-1.2: configuration #1 chosen from 1 choice
hub 1-1.2:1.0: USB hub found
hub 1-1.2:1.0: 2 ports detected
usb 1-1.2: New USB device found, idVendor=04b3, idProduct=3022
usb 1-1.2: New USB device strings: Mfr=1, Product=2, SerialNumber=0
usb 1-1.2: Product: IBM Preferred Pro USB Fingerprint Keyboard
usb 1-1.2: Manufacturer: Chicony
usb 1-1.2.1: new full speed USB device using ppc-of-ehci and address 5
usb 1-1.2.1: configuration #1 chosen from 1 choice
usb 1-1.2.1: New USB device found, idVendor=04b3, idProduct=3021
usb 1-1.2.1: New USB device strings: Mfr=1, Product=2, SerialNumber=0
usb 1-1.2.1: Product: IBM Preferred Pro USB Fingerprint Keyboard
usb 1-1.2.1: Manufacturer: Chicony
usb 1-1.2.2: new full speed USB device using ppc-of-ehci and address 6
usb 1-1.2.2: configuration #1 chosen from 1 choice
usb 1-1.2.2: New USB device found, idVendor=0483, idProduct=2016
usb 1-1.2.2: New USB device strings: Mfr=1, Product=2, SerialNumber=0
usb 1-1.2.2: Product: Biometric Coprocessor
usb 1-1.2.2: Manufacturer: STMicroelectronics
usbcore: registered new interface driver usb-storage
USB Mass Storage support registered.
usbcore: registered new interface driver libusual
mice: PS/2 mouse device common for all mice
input: USB Optical Mouse as /class/input/input0
input: USB HID v1.11 Mouse [USB Optical Mouse] on usb-PPC-OF USB-1.1
input: Chicony IBM Preferred Pro USB Fingerprint Keyboard as /class/input/input1
input: USB HID v1.10 Keyboard [Chicony IBM Preferred Pro USB Fingerprint Keyboard] on usb-PPC-OF USB-1.2.1
HID device claimed by neither input, hiddev nor hidraw
usbcore: registered new interface driver usbhid
drivers/hid/usbhid/hid-core.c: v2.6:USB HID core driver
oprofile: using timer interrupt.
Netfilter messages via NETLINK v0.30.
ip_tables: (C) 2000-2006 Netfilter Core Team
TCP cubic registered
NET: Registered protocol family 1
NET: Registered protocol family 17
Bridge firewalling registered
RPC: Registered udp transport module.
RPC: Registered tcp transport module.
drivers/rtc/hctosys.c: unable to open rtc device (rtc0)
eth0: link is up, 100 FDX, pause enabled
eth1: link is up, 100 FDX, pause enabled
Sending DHCP requests ., OK
IP-Config: Got DHCP answer from 192.168.1.2, my address is 192.168.1.3
IP-Config: Complete:
device=eth0, addr=192.168.1.3, mask=255.255.255.0, gw=192.168.1.2,
host=192.168.1.3, domain=local-devnet, nis-domain=(none),
bootserver=192.168.1.2, rootserver=192.168.1.2, rootpath=
Looking up port of RPC 100003/2 on 192.168.1.2
Looking up port of RPC 100005/1 on 192.168.1.2
VFS: Mounted root (nfs filesystem).
Freeing unused kernel memory: 156k init
eth1: link is up, 100 FDX, pause enabled
swapon: swapfile has holes
warning: `avahi-daemon' uses 32-bit capabilities (legacy support in use)
Machine check in kernel mode.
Data Read PLB Error
Machine check in kernel mode.
Data Read PLB Error
Machine check in kernel mode.
Data Read PLB Error
rpcbind: server localhost not responding, timed out
RPC: failed to contact local rpcbind server (errno 5).
rpcbind: server localhost not responding, timed out
RPC: failed to contact local rpcbind server (errno 5).
lockd_up: makesock failed, error=-5
rpcbind: server localhost not responding, timed out
RPC: failed to contact local rpcbind server (errno 5).
^ permalink raw reply
* [PATCH] ptrace: compat_ptrace_request siginfo
From: Roland McGrath @ 2008-04-20 20:10 UTC (permalink / raw)
To: Linus Torvalds, Andrew Morton
Cc: linux-kernel, linuxppc-dev, Paul Mackerras, Anton Blanchard,
Ingo Molnar, Thomas Gleixner
I posted this before, but I hope it can go in now.
It's a prerequisite for some x86 ptrace cleanups I'd like to submit.
For powerpc, it requires this patch that's in Paul's queue:
commit 9c0c44dbd9bc380bee53e2f768c4ad5410b8aae2
Author: Roland McGrath <roland@redhat.com>
Date: Sun Apr 20 08:19:24 2008 +1000
[POWERPC] Define copy_siginfo_from_user32
Note: that change plus the patch below obviates the need for this one:
commit e4cc58944c1e2ce41e3079d4eb60c95e7ce04b2b
Author: Andreas Schwab <schwab@suse.de>
Date: Sun Apr 20 02:25:13 2008 +1000
[POWERPC] Add compat handler for PTRACE_GETSIGINFO
Thanks,
Roland
---
[PATCH] ptrace: compat_ptrace_request siginfo
This adds support for PTRACE_GETSIGINFO and PTRACE_SETSIGINFO in
compat_ptrace_request. It relies on existing arch definitions for
copy_siginfo_to_user32 and copy_siginfo_from_user32.
On powerpc, this fixes a longstanding regression of 32-bit ptrace
calls on 64-bit kernels vs native calls (64-bit calls or 32-bit
kernels). This can be seen in a 32-bit call using PTRACE_GETSIGINFO
to examine e.g. siginfo_t.si_addr from a signal that sets it.
(This was broken as of 2.6.24 and, I presume, many or all prior versions.)
Signed-off-by: Roland McGrath <roland@redhat.com>
---
kernel/ptrace.c | 48 +++++++++++++++++++++++++++++++++++-------------
1 files changed, 35 insertions(+), 13 deletions(-)
diff --git a/kernel/ptrace.c b/kernel/ptrace.c
index fdb34e8..67e392e 100644
--- a/kernel/ptrace.c
+++ b/kernel/ptrace.c
@@ -323,9 +323,8 @@ static int ptrace_setoptions(struct task_struct *child, long data)
return (data & ~PTRACE_O_MASK) ? -EINVAL : 0;
}
-static int ptrace_getsiginfo(struct task_struct *child, siginfo_t __user * data)
+static int ptrace_getsiginfo(struct task_struct *child, siginfo_t *info)
{
- siginfo_t lastinfo;
int error = -ESRCH;
read_lock(&tasklist_lock);
@@ -333,31 +332,25 @@ static int ptrace_getsiginfo(struct task_struct *child, siginfo_t __user * data)
error = -EINVAL;
spin_lock_irq(&child->sighand->siglock);
if (likely(child->last_siginfo != NULL)) {
- lastinfo = *child->last_siginfo;
+ *info = *child->last_siginfo;
error = 0;
}
spin_unlock_irq(&child->sighand->siglock);
}
read_unlock(&tasklist_lock);
- if (!error)
- return copy_siginfo_to_user(data, &lastinfo);
return error;
}
-static int ptrace_setsiginfo(struct task_struct *child, siginfo_t __user * data)
+static int ptrace_setsiginfo(struct task_struct *child, const siginfo_t *info)
{
- siginfo_t newinfo;
int error = -ESRCH;
- if (copy_from_user(&newinfo, data, sizeof (siginfo_t)))
- return -EFAULT;
-
read_lock(&tasklist_lock);
if (likely(child->sighand != NULL)) {
error = -EINVAL;
spin_lock_irq(&child->sighand->siglock);
if (likely(child->last_siginfo != NULL)) {
- *child->last_siginfo = newinfo;
+ *child->last_siginfo = *info;
error = 0;
}
spin_unlock_irq(&child->sighand->siglock);
@@ -424,6 +417,7 @@ int ptrace_request(struct task_struct *child, long request,
long addr, long data)
{
int ret = -EIO;
+ siginfo_t siginfo;
switch (request) {
case PTRACE_PEEKTEXT:
@@ -442,12 +436,22 @@ int ptrace_request(struct task_struct *child, long request,
case PTRACE_GETEVENTMSG:
ret = put_user(child->ptrace_message, (unsigned long __user *) data);
break;
+
case PTRACE_GETSIGINFO:
- ret = ptrace_getsiginfo(child, (siginfo_t __user *) data);
+ ret = ptrace_getsiginfo(child, &siginfo);
+ if (!ret)
+ ret = copy_siginfo_to_user((siginfo_t __user *) data,
+ &siginfo);
break;
+
case PTRACE_SETSIGINFO:
- ret = ptrace_setsiginfo(child, (siginfo_t __user *) data);
+ if (copy_from_user(&siginfo, (siginfo_t __user *) data,
+ sizeof siginfo))
+ ret = -EFAULT;
+ else
+ ret = ptrace_setsiginfo(child, &siginfo);
break;
+
case PTRACE_DETACH: /* detach a process that was attached. */
ret = ptrace_detach(child, data);
break;
@@ -616,6 +620,7 @@ int compat_ptrace_request(struct task_struct *child, compat_long_t request,
{
compat_ulong_t __user *datap = compat_ptr(data);
compat_ulong_t word;
+ siginfo_t siginfo;
int ret;
switch (request) {
@@ -638,6 +643,23 @@ int compat_ptrace_request(struct task_struct *child, compat_long_t request,
ret = put_user((compat_ulong_t) child->ptrace_message, datap);
break;
+ case PTRACE_GETSIGINFO:
+ ret = ptrace_getsiginfo(child, &siginfo);
+ if (!ret)
+ ret = copy_siginfo_to_user32(
+ (struct compat_siginfo __user *) datap,
+ &siginfo);
+ break;
+
+ case PTRACE_SETSIGINFO:
+ memset(&siginfo, 0, sizeof siginfo);
+ if (copy_siginfo_from_user32(
+ &siginfo, (struct compat_siginfo __user *) datap))
+ ret = -EFAULT;
+ else
+ ret = ptrace_setsiginfo(child, &siginfo);
+ break;
+
default:
ret = ptrace_request(child, request, addr, data);
}
^ permalink raw reply related
* git.secretlab.ca doubts
From: rodolfo @ 2008-04-20 14:02 UTC (permalink / raw)
To: Linuxppc embedded, rodolfo__17
Hi,
Did I had to use uartlite.c from "Uartlite: Make console output actually
work." topic in git server instead of driver/serial/uartlite.c in mmy
kernel tree?
and about Makefile from "Linux 2.6.25-rc7 v2.6.25-rc7" topic in git
server, Did I had to replace for my Makefile (2.6.25 from kernel.org) ??
When I have to use the files from git server?
^ permalink raw reply
* Re: removal of arch/ppc in 2.6.27?
From: Marvin @ 2008-04-20 13:43 UTC (permalink / raw)
To: Paul Mackerras; +Cc: linuxppc-dev
In-Reply-To: <18443.13999.770734.826892@cargo.ozlabs.ibm.com>
Hi Paul,
On Sunday 20 April 2008 14:27:27 Paul Mackerras wrote:
> Marvin writes:
> > will this be the end of life for all the PReP's ? I remember a patch
> > posted some month ago, but didn't heard anything since then. Any news? Or
> > just let it die quietly?
>
> No, I'm still planning on getting PReP support over to arch/powerpc,
> but getting time to work on it has been the difficulty.
>
> What sort of PReP do you have?
IBM 7248 (aka Carolina) and Motorola Powerstack II (aka Utah) - currently
running Debian with 2.6.18 kernel.
Marvin
^ permalink raw reply
* Re: removal of arch/ppc in 2.6.27?
From: Gabriel Paubert @ 2008-04-20 12:55 UTC (permalink / raw)
To: Paul Mackerras; +Cc: linuxppc-dev
In-Reply-To: <18443.13999.770734.826892@cargo.ozlabs.ibm.com>
On Sun, Apr 20, 2008 at 10:27:27PM +1000, Paul Mackerras wrote:
> Marvin writes:
>
> > will this be the end of life for all the PReP's ? I remember a patch posted
> > some month ago, but didn't heard anything since then. Any news? Or just let
> > it die quietly?
>
> No, I'm still planning on getting PReP support over to arch/powerpc,
> but getting time to work on it has been the difficulty.
>
> What sort of PReP do you have?
On my side, I have MVME2[467]xx boards. But these are actually PPLUS
board but the residual data and boot methods are so similar to PreP
that they could be merged. The host bridge is flexible (the MVME5100
has the same PHB but a completely different layout set up by the
firmware IIRC). I have local patches in the tree I use (still 2.2)
that make the memory map more CHRP like (to have more PCI memory
space and less I/O space).
The main problem is that I'm short on cycles to work on porting
them to 2.6 (the other is that I'm not sure that it's worth
putting 2.6 on machines with 16MB of RAM, current kernels
with extremely stripped down configs are still much larger
than the ones I run on these boards).
Gabriel
^ permalink raw reply
* Re: removal of arch/ppc in 2.6.27?
From: Paul Mackerras @ 2008-04-20 12:27 UTC (permalink / raw)
To: Marvin; +Cc: linuxppc-dev
In-Reply-To: <200804201314.47311.marvin24@gmx.de>
Marvin writes:
> will this be the end of life for all the PReP's ? I remember a patch posted
> some month ago, but didn't heard anything since then. Any news? Or just let
> it die quietly?
No, I'm still planning on getting PReP support over to arch/powerpc,
but getting time to work on it has been the difficulty.
What sort of PReP do you have?
Paul.
^ permalink raw reply
* Re: removal of arch/ppc in 2.6.27?
From: Marvin @ 2008-04-20 11:14 UTC (permalink / raw)
To: linuxppc-dev
In-Reply-To: <D713F373-AE2A-4341-9C29-EF65B9399B36@kernel.crashing.org>
Hi,
On Saturday 19 April 2008 17:30:10 Kumar Gala wrote:
> This is intended as a reminder that we plan on getting rid of arch/ppc
> this summer. I'm guessing based on kernel release times that will be
> 2.6.27. That would mean 2.6.26 will be the last kernel to support
> arch/ppc.
>
> If people have boards that like ported over please let us know and
> work with us to port this over to arch/powerpc.
>
> Here is a list based on arch/ppc/platforms. Its not intended to be
> complete but a general idea of what's left in arch/ppc.
>
> PPC_PREP e6xx
will this be the end of life for all the PReP's ? I remember a patch posted
some month ago, but didn't heard anything since then. Any news? Or just let
it die quietly?
Marvin
^ permalink raw reply
* Please pull powerpc.git master branch
From: Paul Mackerras @ 2008-04-20 11:03 UTC (permalink / raw)
To: torvalds; +Cc: linuxppc-dev, akpm, linux-kernel
Linus,
Please do:
git pull \
git://git.kernel.org/pub/scm/linux/kernel/git/paulus/powerpc.git master
to get a powerpc update.
Thanks,
Paul.
Documentation/kernel-parameters.txt | 2
Documentation/powerpc/booting-without-of.txt | 622 +++++++++++++-
Documentation/powerpc/phyp-assisted-dump.txt | 127 +++
arch/powerpc/Kconfig | 82 +-
arch/powerpc/Kconfig.debug | 2
arch/powerpc/Makefile | 12
arch/powerpc/boot/Makefile | 40 +
arch/powerpc/boot/bamboo.c | 3
arch/powerpc/boot/cpm-serial.c | 117 ++-
arch/powerpc/boot/cuboot-pq2.c | 27 -
arch/powerpc/boot/cuboot-rainier.c | 3
arch/powerpc/boot/cuboot-sequoia.c | 3
arch/powerpc/boot/cuboot-taishan.c | 3
arch/powerpc/boot/cuboot-warp.c | 2
arch/powerpc/boot/cuboot-yosemite.c | 44 +
arch/powerpc/boot/devtree.c | 20
arch/powerpc/boot/dts/bamboo.dts | 2
arch/powerpc/boot/dts/canyonlands.dts | 402 +++++++++
arch/powerpc/boot/dts/ebony.dts | 2
arch/powerpc/boot/dts/ep8248e.dts | 5
arch/powerpc/boot/dts/ep88xc.dts | 73 +-
arch/powerpc/boot/dts/glacier.dts | 467 ++++++++++
arch/powerpc/boot/dts/haleakala.dts | 4
arch/powerpc/boot/dts/katmai.dts | 2
arch/powerpc/boot/dts/kilauea.dts | 4
arch/powerpc/boot/dts/ksi8560.dts | 267 ++++++
arch/powerpc/boot/dts/kuroboxHD.dts | 83 +-
arch/powerpc/boot/dts/kuroboxHG.dts | 83 +-
arch/powerpc/boot/dts/makalu.dts | 4
arch/powerpc/boot/dts/mpc7448hpc2.dts | 97 +-
arch/powerpc/boot/dts/mpc8272ads.dts | 132 ++-
arch/powerpc/boot/dts/mpc832x_mds.dts | 7
arch/powerpc/boot/dts/mpc832x_rdb.dts | 4
arch/powerpc/boot/dts/mpc836x_mds.dts | 4
arch/powerpc/boot/dts/mpc8540ads.dts | 173 ++--
arch/powerpc/boot/dts/mpc8541cds.dts | 161 ++--
arch/powerpc/boot/dts/mpc8544ds.dts | 299 ++++---
arch/powerpc/boot/dts/mpc8548cds.dts | 289 +++---
arch/powerpc/boot/dts/mpc8555cds.dts | 161 ++--
arch/powerpc/boot/dts/mpc8560ads.dts | 209 ++---
arch/powerpc/boot/dts/mpc8568mds.dts | 291 +++----
arch/powerpc/boot/dts/mpc8572ds.dts | 383 ++++-----
arch/powerpc/boot/dts/mpc8641_hpcn.dts | 2
arch/powerpc/boot/dts/mpc866ads.dts | 58 +
arch/powerpc/boot/dts/mpc885ads.dts | 77 +-
arch/powerpc/boot/dts/pq2fads.dts | 126 +--
arch/powerpc/boot/dts/prpmc2800.dts | 336 ++++----
arch/powerpc/boot/dts/rainier.dts | 6
arch/powerpc/boot/dts/sbc8641d.dts | 352 ++++++++
arch/powerpc/boot/dts/sequoia.dts | 6
arch/powerpc/boot/dts/taishan.dts | 31 +
arch/powerpc/boot/dts/walnut.dts | 1
arch/powerpc/boot/dts/warp.dts | 1
arch/powerpc/boot/dts/yosemite.dts | 304 +++++++
arch/powerpc/boot/ebony.c | 3
arch/powerpc/boot/libfdt-wrapper.c | 2
arch/powerpc/boot/mpc52xx-psc.c | 9
arch/powerpc/boot/mpsc.c | 2
arch/powerpc/boot/mv64x60.c | 4
arch/powerpc/boot/mv64x60_i2c.c | 2
arch/powerpc/boot/ns16550.c | 10
arch/powerpc/boot/ops.h | 1
arch/powerpc/boot/prpmc2800.c | 23 -
arch/powerpc/boot/ps3-head.S | 25 -
arch/powerpc/boot/ps3.c | 23 -
arch/powerpc/boot/serial.c | 2
arch/powerpc/boot/simpleboot.c | 84 ++
arch/powerpc/boot/treeboot-walnut.c | 2
arch/powerpc/boot/virtex405-head.S | 30 +
arch/powerpc/boot/wrapper | 32 -
arch/powerpc/configs/40x/ep405_defconfig | 0
arch/powerpc/configs/40x/kilauea_defconfig | 0
arch/powerpc/configs/40x/makalu_defconfig | 0
arch/powerpc/configs/40x/walnut_defconfig | 0
arch/powerpc/configs/44x/bamboo_defconfig | 0
arch/powerpc/configs/44x/canyonlands_defconfig | 138 ---
arch/powerpc/configs/44x/ebony_defconfig | 0
arch/powerpc/configs/44x/katmai_defconfig | 0
arch/powerpc/configs/44x/rainier_defconfig | 0
arch/powerpc/configs/44x/sequoia_defconfig | 0
arch/powerpc/configs/44x/taishan_defconfig | 0
arch/powerpc/configs/44x/warp_defconfig | 0
arch/powerpc/configs/83xx/mpc8313_rdb_defconfig | 8
arch/powerpc/configs/83xx/mpc8315_rdb_defconfig | 0
arch/powerpc/configs/83xx/mpc832x_mds_defconfig | 0
arch/powerpc/configs/83xx/mpc832x_rdb_defconfig | 0
arch/powerpc/configs/83xx/mpc834x_itx_defconfig | 0
arch/powerpc/configs/83xx/mpc834x_itxgp_defconfig | 0
arch/powerpc/configs/83xx/mpc834x_mds_defconfig | 0
arch/powerpc/configs/83xx/mpc836x_mds_defconfig | 0
arch/powerpc/configs/83xx/mpc837x_mds_defconfig | 0
arch/powerpc/configs/83xx/mpc837x_rdb_defconfig | 0
arch/powerpc/configs/83xx/sbc834x_defconfig | 0
arch/powerpc/configs/85xx/ksi8560_defconfig | 250 +++---
arch/powerpc/configs/85xx/mpc8540_ads_defconfig | 0
arch/powerpc/configs/85xx/mpc8544_ds_defconfig | 17
arch/powerpc/configs/85xx/mpc8560_ads_defconfig | 0
arch/powerpc/configs/85xx/mpc8568mds_defconfig | 0
arch/powerpc/configs/85xx/mpc8572_ds_defconfig | 0
arch/powerpc/configs/85xx/mpc85xx_cds_defconfig | 0
arch/powerpc/configs/85xx/sbc8548_defconfig | 0
arch/powerpc/configs/85xx/sbc8560_defconfig | 0
arch/powerpc/configs/85xx/stx_gp3_defconfig | 0
arch/powerpc/configs/85xx/tqm8540_defconfig | 0
arch/powerpc/configs/85xx/tqm8541_defconfig | 0
arch/powerpc/configs/85xx/tqm8555_defconfig | 0
arch/powerpc/configs/85xx/tqm8560_defconfig | 0
arch/powerpc/configs/chrp32_defconfig | 7
arch/powerpc/configs/g5_defconfig | 7
arch/powerpc/configs/iseries_defconfig | 7
arch/powerpc/configs/maple_defconfig | 131 +++
arch/powerpc/configs/mpc83xx_defconfig | 164 ++++
arch/powerpc/configs/pmac32_defconfig | 7
arch/powerpc/configs/ppc40x_defconfig | 31 -
arch/powerpc/configs/ppc44x_defconfig | 14
arch/powerpc/configs/ppc64_defconfig | 8
arch/powerpc/configs/pseries_defconfig | 8
arch/powerpc/configs/sbc8641d_defconfig | 937 +++++++++++----------
arch/powerpc/kernel/Makefile | 1
arch/powerpc/kernel/asm-offsets.c | 10
arch/powerpc/kernel/btext.c | 3
arch/powerpc/kernel/cpu_setup_44x.S | 5
arch/powerpc/kernel/cputable.c | 28 +
arch/powerpc/kernel/crash.c | 3
arch/powerpc/kernel/crash_dump.c | 3
arch/powerpc/kernel/entry_32.S | 30 -
arch/powerpc/kernel/entry_64.S | 30 +
arch/powerpc/kernel/head_32.S | 22
arch/powerpc/kernel/head_44x.S | 4
arch/powerpc/kernel/head_64.S | 69 +-
arch/powerpc/kernel/head_booke.h | 33 -
arch/powerpc/kernel/head_fsl_booke.S | 44 +
arch/powerpc/kernel/ibmebus.c | 12
arch/powerpc/kernel/iommu.c | 4
arch/powerpc/kernel/irq.c | 18
arch/powerpc/kernel/isa-bridge.c | 6
arch/powerpc/kernel/lparcfg.c | 12
arch/powerpc/kernel/machine_kexec.c | 3
arch/powerpc/kernel/paca.c | 34 -
arch/powerpc/kernel/ppc32.h | 2
arch/powerpc/kernel/ppc_ksyms.c | 7
arch/powerpc/kernel/process.c | 33 -
arch/powerpc/kernel/prom.c | 120 ++-
arch/powerpc/kernel/prom_init.c | 8
arch/powerpc/kernel/ptrace32.c | 27 +
arch/powerpc/kernel/rtas.c | 4
arch/powerpc/kernel/rtas_flash.c | 2
arch/powerpc/kernel/rtas_pci.c | 29 -
arch/powerpc/kernel/setup-common.c | 11
arch/powerpc/kernel/setup_32.c | 14
arch/powerpc/kernel/setup_64.c | 8
arch/powerpc/kernel/signal_32.c | 19
arch/powerpc/kernel/stacktrace.c | 47 +
arch/powerpc/kernel/sys_ppc32.c | 5
arch/powerpc/kernel/vdso.c | 3
arch/powerpc/kernel/vio.c | 10
arch/powerpc/kernel/vmlinux.lds.S | 51 +
arch/powerpc/lib/rheap.c | 4
arch/powerpc/lib/string.S | 14
arch/powerpc/math-emu/fabs.c | 2
arch/powerpc/math-emu/fadd.c | 2
arch/powerpc/math-emu/fadds.c | 2
arch/powerpc/math-emu/fcmpo.c | 2
arch/powerpc/math-emu/fcmpu.c | 2
arch/powerpc/math-emu/fctiw.c | 2
arch/powerpc/math-emu/fctiwz.c | 2
arch/powerpc/math-emu/fdiv.c | 6
arch/powerpc/math-emu/fdivs.c | 6
arch/powerpc/math-emu/fmadd.c | 2
arch/powerpc/math-emu/fmadds.c | 2
arch/powerpc/math-emu/fmr.c | 2
arch/powerpc/math-emu/fmsub.c | 2
arch/powerpc/math-emu/fmsubs.c | 2
arch/powerpc/math-emu/fmul.c | 2
arch/powerpc/math-emu/fmuls.c | 2
arch/powerpc/math-emu/fnabs.c | 2
arch/powerpc/math-emu/fneg.c | 2
arch/powerpc/math-emu/fnmadd.c | 2
arch/powerpc/math-emu/fnmadds.c | 2
arch/powerpc/math-emu/fnmsub.c | 2
arch/powerpc/math-emu/fnmsubs.c | 2
arch/powerpc/math-emu/fres.c | 2
arch/powerpc/math-emu/frsp.c | 2
arch/powerpc/math-emu/frsqrte.c | 2
arch/powerpc/math-emu/fsel.c | 2
arch/powerpc/math-emu/fsqrt.c | 2
arch/powerpc/math-emu/fsqrts.c | 2
arch/powerpc/math-emu/fsub.c | 2
arch/powerpc/math-emu/fsubs.c | 2
arch/powerpc/math-emu/lfd.c | 2
arch/powerpc/math-emu/lfs.c | 2
arch/powerpc/math-emu/mcrfs.c | 4
arch/powerpc/math-emu/mffs.c | 2
arch/powerpc/math-emu/mtfsb0.c | 2
arch/powerpc/math-emu/mtfsb1.c | 2
arch/powerpc/math-emu/mtfsf.c | 2
arch/powerpc/math-emu/mtfsfi.c | 2
arch/powerpc/math-emu/stfd.c | 2
arch/powerpc/math-emu/stfiwx.c | 2
arch/powerpc/math-emu/stfs.c | 2
arch/powerpc/mm/40x_mmu.c | 2
arch/powerpc/mm/44x_mmu.c | 2
arch/powerpc/mm/Makefile | 2
arch/powerpc/mm/fsl_booke_mmu.c | 48 -
arch/powerpc/mm/hash_utils_64.c | 32 +
arch/powerpc/mm/init_32.c | 27 -
arch/powerpc/mm/init_64.c | 7
arch/powerpc/mm/lmb.c | 357 --------
arch/powerpc/mm/mem.c | 21
arch/powerpc/mm/mmu_decl.h | 4
arch/powerpc/mm/numa.c | 3
arch/powerpc/mm/pgtable_32.c | 5
arch/powerpc/mm/ppc_mmu_32.c | 15
arch/powerpc/mm/stab.c | 4
arch/powerpc/oprofile/cell/spu_task_sync.c | 12
arch/powerpc/oprofile/cell/vma_map.c | 10
arch/powerpc/oprofile/op_model_cell.c | 14
arch/powerpc/platforms/40x/ep405.c | 2
arch/powerpc/platforms/40x/kilauea.c | 4
arch/powerpc/platforms/40x/makalu.c | 2
arch/powerpc/platforms/40x/virtex.c | 2
arch/powerpc/platforms/40x/walnut.c | 4
arch/powerpc/platforms/44x/44x.h | 1
arch/powerpc/platforms/44x/Kconfig | 27 +
arch/powerpc/platforms/44x/Makefile | 4
arch/powerpc/platforms/44x/bamboo.c | 15
arch/powerpc/platforms/44x/canyonlands.c | 63 +
arch/powerpc/platforms/44x/ebony.c | 5
arch/powerpc/platforms/44x/idle.c | 67 ++
arch/powerpc/platforms/44x/katmai.c | 5
arch/powerpc/platforms/44x/misc_44x.S | 11
arch/powerpc/platforms/44x/rainier.c | 4
arch/powerpc/platforms/44x/sequoia.c | 4
arch/powerpc/platforms/44x/taishan.c | 5
arch/powerpc/platforms/44x/warp-nand.c | 3
arch/powerpc/platforms/44x/warp.c | 6
arch/powerpc/platforms/52xx/lite5200.c | 4
arch/powerpc/platforms/82xx/Kconfig | 3
arch/powerpc/platforms/83xx/mpc837x_rdb.c | 1
arch/powerpc/platforms/83xx/mpc83xx.h | 2
arch/powerpc/platforms/83xx/usb.c | 12
arch/powerpc/platforms/85xx/Kconfig | 13
arch/powerpc/platforms/85xx/Makefile | 1
arch/powerpc/platforms/85xx/ksi8560.c | 257 ++++++
arch/powerpc/platforms/85xx/mpc85xx_ads.c | 2
arch/powerpc/platforms/85xx/mpc85xx_ds.c | 15
arch/powerpc/platforms/86xx/Kconfig | 8
arch/powerpc/platforms/86xx/Makefile | 1
arch/powerpc/platforms/86xx/mpc8610_hpcd.c | 4
arch/powerpc/platforms/86xx/mpc86xx_hpcn.c | 14
arch/powerpc/platforms/86xx/sbc8641d.c | 164 ++++
arch/powerpc/platforms/8xx/Kconfig | 4
arch/powerpc/platforms/8xx/m8xx_setup.c | 7
arch/powerpc/platforms/Kconfig | 8
arch/powerpc/platforms/Kconfig.cputype | 2
arch/powerpc/platforms/cell/iommu.c | 10
arch/powerpc/platforms/cell/pervasive.c | 2
arch/powerpc/platforms/cell/ras.c | 10
arch/powerpc/platforms/cell/spu_base.c | 8
arch/powerpc/platforms/cell/spu_callbacks.c | 2
arch/powerpc/platforms/cell/spu_manage.c | 8
arch/powerpc/platforms/cell/spufs/coredump.c | 8
arch/powerpc/platforms/cell/spufs/file.c | 8
arch/powerpc/platforms/cell/spufs/run.c | 14
arch/powerpc/platforms/cell/spufs/switch.c | 2
arch/powerpc/platforms/celleb/beat.c | 17
arch/powerpc/platforms/celleb/beat.h | 4
arch/powerpc/platforms/celleb/beat_wrapper.h | 3
arch/powerpc/platforms/celleb/htab.c | 7
arch/powerpc/platforms/celleb/interrupt.c | 26 -
arch/powerpc/platforms/celleb/scc_epci.c | 8
arch/powerpc/platforms/celleb/scc_sio.c | 4
arch/powerpc/platforms/celleb/spu_priv1.c | 3
arch/powerpc/platforms/celleb/udbg_beat.c | 5
arch/powerpc/platforms/embedded6xx/mpc7448_hpc2.c | 10
arch/powerpc/platforms/embedded6xx/prpmc2800.c | 4
arch/powerpc/platforms/iseries/exception.S | 12
arch/powerpc/platforms/iseries/ipl_parms.h | 2
arch/powerpc/platforms/iseries/lpardata.c | 121 ++-
arch/powerpc/platforms/iseries/naca.h | 2
arch/powerpc/platforms/iseries/pci.c | 3
arch/powerpc/platforms/iseries/release_data.h | 2
arch/powerpc/platforms/iseries/spcomm_area.h | 2
arch/powerpc/platforms/iseries/vpd_areas.h | 4
arch/powerpc/platforms/maple/pci.c | 47 -
arch/powerpc/platforms/maple/setup.c | 4
arch/powerpc/platforms/pasemi/dma_lib.c | 144 +++
arch/powerpc/platforms/pasemi/iommu.c | 19
arch/powerpc/platforms/powermac/setup.c | 2
arch/powerpc/platforms/ps3/device-init.c | 78 +-
arch/powerpc/platforms/ps3/htab.c | 3
arch/powerpc/platforms/ps3/interrupt.c | 2
arch/powerpc/platforms/ps3/mm.c | 3
arch/powerpc/platforms/ps3/os-area.c | 3
arch/powerpc/platforms/ps3/setup.c | 14
arch/powerpc/platforms/ps3/spu.c | 7
arch/powerpc/platforms/pseries/Makefile | 1
arch/powerpc/platforms/pseries/eeh.c | 5
arch/powerpc/platforms/pseries/lpar.c | 25 -
arch/powerpc/platforms/pseries/pci_dlpar.c | 2
arch/powerpc/platforms/pseries/phyp_dump.c | 507 +++++++++++
arch/powerpc/platforms/pseries/pseries.h | 2
arch/powerpc/platforms/pseries/reconfig.c | 12
arch/powerpc/platforms/pseries/scanlog.c | 37 -
arch/powerpc/platforms/pseries/setup.c | 105 +-
arch/powerpc/platforms/pseries/xics.c | 87 --
arch/powerpc/platforms/pseries/xics.h | 3
arch/powerpc/sysdev/Makefile | 2
arch/powerpc/sysdev/cpm1.c | 114 ---
arch/powerpc/sysdev/cpm2.c | 105 --
arch/powerpc/sysdev/cpm_common.c | 3
arch/powerpc/sysdev/dart_iommu.c | 2
arch/powerpc/sysdev/fsl_lbc.c | 129 +++
arch/powerpc/sysdev/fsl_soc.c | 611 +-------------
arch/powerpc/sysdev/fsl_soc.h | 1
arch/powerpc/sysdev/mpic.c | 41 -
arch/powerpc/sysdev/mv64x60_dev.c | 78 +-
arch/powerpc/sysdev/mv64x60_pci.c | 6
arch/powerpc/sysdev/mv64x60_pic.c | 4
arch/powerpc/sysdev/mv64x60_udbg.c | 2
arch/powerpc/sysdev/ppc4xx_pci.c | 133 +++
arch/powerpc/sysdev/ppc4xx_pci.h | 59 +
arch/powerpc/sysdev/ppc4xx_soc.c | 200 ++++
arch/powerpc/sysdev/qe_lib/qe.c | 13
arch/powerpc/sysdev/qe_lib/qe_io.c | 7
arch/powerpc/sysdev/qe_lib/ucc_fast.c | 32 -
arch/powerpc/sysdev/qe_lib/ucc_slow.c | 18
arch/powerpc/sysdev/rtc_cmos_setup.c | 2
arch/powerpc/sysdev/tsi108_dev.c | 4
arch/powerpc/sysdev/tsi108_pci.c | 4
arch/powerpc/xmon/xmon.c | 24 -
arch/ppc/8xx_io/commproc.c | 2
arch/ppc/8xx_io/fec.c | 4
arch/ppc/kernel/head.S | 17
arch/ppc/mm/init.c | 1
arch/ppc/platforms/radstone_ppc7d.c | 8
arch/ppc/syslib/mpc52xx_setup.c | 2
arch/sparc64/Kconfig | 1
drivers/block/viodasd.c | 2
drivers/char/hvc_beat.c | 4
drivers/char/xilinx_hwicap/buffer_icap.c | 22
drivers/char/xilinx_hwicap/buffer_icap.h | 5
drivers/char/xilinx_hwicap/fifo_icap.c | 31 +
drivers/char/xilinx_hwicap/fifo_icap.h | 1
drivers/char/xilinx_hwicap/xilinx_hwicap.c | 63 +
drivers/char/xilinx_hwicap/xilinx_hwicap.h | 24 +
drivers/mtd/nand/fsl_elbc_nand.c | 219 -----
drivers/net/Makefile | 3
drivers/net/iseries_veth.c | 3
drivers/net/pasemi_mac.c | 355 +++++++-
drivers/net/pasemi_mac.h | 35 +
drivers/net/pasemi_mac_ethtool.c | 159 ++++
drivers/net/ps3_gelic_net.c | 81 ++
drivers/net/ps3_gelic_net.h | 20
drivers/net/ucc_geth.c | 8
drivers/net/ucc_geth_mii.c | 11
drivers/of/Kconfig | 12
drivers/of/Makefile | 2
drivers/of/base.c | 26 +
drivers/of/gpio.c | 242 +++++
drivers/of/of_i2c.c | 115 +++
drivers/ps3/ps3-sys-manager.c | 74 +-
drivers/ps3/sys-manager-core.c | 16
drivers/serial/cpm_uart/cpm_uart.h | 3
drivers/serial/cpm_uart/cpm_uart_core.c | 19
drivers/serial/cpm_uart/cpm_uart_cpm1.c | 14
drivers/serial/cpm_uart/cpm_uart_cpm2.c | 52 +
drivers/serial/of_serial.c | 4
drivers/serial/ucc_uart.c | 16
include/asm-powerpc/Kbuild | 2
include/asm-powerpc/abs_addr.h | 3
include/asm-powerpc/bitops.h | 32 -
include/asm-powerpc/cpm.h | 14
include/asm-powerpc/cpm1.h | 13
include/asm-powerpc/cpm2.h | 11
include/asm-powerpc/cputhreads.h | 2
include/asm-powerpc/dcr-native.h | 17
include/asm-powerpc/dcr-regs.h | 78 ++
include/asm-powerpc/exception.h | 6
include/asm-powerpc/fsl_lbc.h | 311 +++++++
include/asm-powerpc/gpio.h | 56 +
include/asm-powerpc/hw_irq.h | 13
include/asm-powerpc/immap_qe.h | 3
include/asm-powerpc/irqflags.h | 37 +
include/asm-powerpc/iseries/alpaca.h | 31 +
include/asm-powerpc/iseries/it_lp_reg_save.h | 85 --
include/asm-powerpc/lmb.h | 82 --
include/asm-powerpc/machdep.h | 5
include/asm-powerpc/macio.h | 2
include/asm-powerpc/mmu-40x.h | 2
include/asm-powerpc/mmu-44x.h | 2
include/asm-powerpc/mmu-8xx.h | 2
include/asm-powerpc/mmu-fsl-booke.h | 6
include/asm-powerpc/mmu-hash32.h | 2
include/asm-powerpc/mmu-hash64.h | 3
include/asm-powerpc/paca.h | 12
include/asm-powerpc/page.h | 1
include/asm-powerpc/page_32.h | 2
include/asm-powerpc/pasemi_dma.h | 77 ++
include/asm-powerpc/pci-bridge.h | 4
include/asm-powerpc/pgtable-ppc32.h | 8
include/asm-powerpc/phyp_dump.h | 47 +
include/asm-powerpc/pmi.h | 2
include/asm-powerpc/ppc4xx.h | 18
include/asm-powerpc/ps3.h | 7
include/asm-powerpc/ptrace.h | 9
include/asm-powerpc/qe.h | 12
include/asm-powerpc/rwsem.h | 35 +
include/asm-powerpc/sparsemem.h | 1
include/asm-powerpc/spinlock.h | 1
include/asm-powerpc/string.h | 2
include/asm-powerpc/system.h | 1
include/asm-powerpc/types.h | 7
include/asm-sparc64/lmb.h | 10
include/linux/lmb.h | 85 ++
include/linux/of.h | 1
include/linux/of_gpio.h | 69 ++
include/linux/of_i2c.h | 24 +
lib/Kconfig | 3
lib/Makefile | 2
lib/lmb.c | 428 ++++++++++
421 files changed, 11370 insertions(+), 5221 deletions(-)
create mode 100644 Documentation/powerpc/phyp-assisted-dump.txt
create mode 100644 arch/powerpc/boot/cuboot-yosemite.c
create mode 100644 arch/powerpc/boot/dts/canyonlands.dts
create mode 100644 arch/powerpc/boot/dts/glacier.dts
create mode 100644 arch/powerpc/boot/dts/ksi8560.dts
create mode 100644 arch/powerpc/boot/dts/sbc8641d.dts
create mode 100644 arch/powerpc/boot/dts/yosemite.dts
create mode 100644 arch/powerpc/boot/simpleboot.c
create mode 100644 arch/powerpc/boot/virtex405-head.S
rename arch/powerpc/configs/{ep405_defconfig => 40x/ep405_defconfig} (100%)
rename arch/powerpc/configs/{kilauea_defconfig => 40x/kilauea_defconfig} (100%)
rename arch/powerpc/configs/{makalu_defconfig => 40x/makalu_defconfig} (100%)
copy arch/powerpc/configs/{walnut_defconfig => 40x/walnut_defconfig} (100%)
rename arch/powerpc/configs/{bamboo_defconfig => 44x/bamboo_defconfig} (100%)
copy arch/powerpc/configs/{taishan_defconfig => 44x/canyonlands_defconfig} (82%)
rename arch/powerpc/configs/{ebony_defconfig => 44x/ebony_defconfig} (100%)
rename arch/powerpc/configs/{katmai_defconfig => 44x/katmai_defconfig} (100%)
rename arch/powerpc/configs/{rainier_defconfig => 44x/rainier_defconfig} (100%)
rename arch/powerpc/configs/{sequoia_defconfig => 44x/sequoia_defconfig} (100%)
rename arch/powerpc/configs/{taishan_defconfig => 44x/taishan_defconfig} (100%)
rename arch/powerpc/configs/{warp_defconfig => 44x/warp_defconfig} (100%)
rename arch/powerpc/configs/{mpc8313_rdb_defconfig => 83xx/mpc8313_rdb_defconfig} (99%)
rename arch/powerpc/configs/{mpc8315_rdb_defconfig => 83xx/mpc8315_rdb_defconfig} (100%)
rename arch/powerpc/configs/{mpc832x_mds_defconfig => 83xx/mpc832x_mds_defconfig} (100%)
rename arch/powerpc/configs/{mpc832x_rdb_defconfig => 83xx/mpc832x_rdb_defconfig} (100%)
rename arch/powerpc/configs/{mpc834x_itx_defconfig => 83xx/mpc834x_itx_defconfig} (100%)
rename arch/powerpc/configs/{mpc834x_itxgp_defconfig => 83xx/mpc834x_itxgp_defconfig} (100%)
rename arch/powerpc/configs/{mpc834x_mds_defconfig => 83xx/mpc834x_mds_defconfig} (100%)
rename arch/powerpc/configs/{mpc836x_mds_defconfig => 83xx/mpc836x_mds_defconfig} (100%)
rename arch/powerpc/configs/{mpc837x_mds_defconfig => 83xx/mpc837x_mds_defconfig} (100%)
rename arch/powerpc/configs/{mpc837x_rdb_defconfig => 83xx/mpc837x_rdb_defconfig} (100%)
rename arch/powerpc/configs/{sbc834x_defconfig => 83xx/sbc834x_defconfig} (100%)
copy arch/powerpc/configs/{mpc8560_ads_defconfig => 85xx/ksi8560_defconfig} (85%)
rename arch/powerpc/configs/{mpc8540_ads_defconfig => 85xx/mpc8540_ads_defconfig} (100%)
rename arch/powerpc/configs/{mpc8544_ds_defconfig => 85xx/mpc8544_ds_defconfig} (99%)
rename arch/powerpc/configs/{mpc8560_ads_defconfig => 85xx/mpc8560_ads_defconfig} (100%)
rename arch/powerpc/configs/{mpc8568mds_defconfig => 85xx/mpc8568mds_defconfig} (100%)
rename arch/powerpc/configs/{mpc8572_ds_defconfig => 85xx/mpc8572_ds_defconfig} (100%)
rename arch/powerpc/configs/{mpc85xx_cds_defconfig => 85xx/mpc85xx_cds_defconfig} (100%)
rename arch/powerpc/configs/{sbc8548_defconfig => 85xx/sbc8548_defconfig} (100%)
rename arch/powerpc/configs/{sbc8560_defconfig => 85xx/sbc8560_defconfig} (100%)
copy arch/powerpc/configs/{stx_gp3_defconfig => 85xx/stx_gp3_defconfig} (100%)
rename arch/powerpc/configs/{tqm8540_defconfig => 85xx/tqm8540_defconfig} (100%)
rename arch/powerpc/configs/{tqm8541_defconfig => 85xx/tqm8541_defconfig} (100%)
rename arch/powerpc/configs/{tqm8555_defconfig => 85xx/tqm8555_defconfig} (100%)
rename arch/powerpc/configs/{tqm8560_defconfig => 85xx/tqm8560_defconfig} (100%)
rename arch/powerpc/configs/{walnut_defconfig => ppc40x_defconfig} (97%)
rename arch/powerpc/configs/{stx_gp3_defconfig => sbc8641d_defconfig} (61%)
create mode 100644 arch/powerpc/kernel/stacktrace.c
delete mode 100644 arch/powerpc/mm/lmb.c
create mode 100644 arch/powerpc/platforms/44x/canyonlands.c
create mode 100644 arch/powerpc/platforms/44x/idle.c
create mode 100644 arch/powerpc/platforms/85xx/ksi8560.c
create mode 100644 arch/powerpc/platforms/86xx/sbc8641d.c
create mode 100644 arch/powerpc/platforms/pseries/phyp_dump.c
create mode 100644 arch/powerpc/sysdev/fsl_lbc.c
create mode 100644 arch/powerpc/sysdev/ppc4xx_soc.c
create mode 100644 drivers/net/pasemi_mac_ethtool.c
create mode 100644 drivers/of/gpio.c
create mode 100644 drivers/of/of_i2c.c
create mode 100644 include/asm-powerpc/fsl_lbc.h
create mode 100644 include/asm-powerpc/gpio.h
create mode 100644 include/asm-powerpc/iseries/alpaca.h
delete mode 100644 include/asm-powerpc/iseries/it_lp_reg_save.h
create mode 100644 include/asm-powerpc/phyp_dump.h
create mode 100644 include/asm-powerpc/ppc4xx.h
create mode 100644 include/asm-sparc64/lmb.h
create mode 100644 include/linux/lmb.h
create mode 100644 include/linux/of_gpio.h
create mode 100644 include/linux/of_i2c.h
create mode 100644 lib/lmb.c
Adrian Bunk (1):
[POWERPC] Add MODULE_LICENSE to powerpc/sysdev/rtc_cmos_setup.c
Alexander van Heukelum (1):
[POWERPC] Use asm-generic/bitops/find.h in bitops.h
Alexandr Smirnov (4):
[POWERPC] 85xx: Emerson KSI8560 base support
[POWERPC] 85xx: Emerson KSI8560 bootwrapper
[POWERPC] 85xx: Emerson KSI8560 default config
[POWERPC] 85xx: Emerson KSI8560 device tree
Andreas Schwab (1):
[POWERPC] Add compat handler for PTRACE_GETSIGINFO
Anton Vorontsov (12):
[POWERPC] 8xx: Timebase frequency should not depend on bus-frequency
[POWERPC] OF helpers for the GPIO API
[POWERPC] Implement support for the GPIO LIB API
[POWERPC] QE: UCC nodes cleanup
[POWERPC] fsl_elbc_nand: factor out localbus defines
[POWERPC] fsl_lbc: implement few UPM routines
[POWERPC] QE: implement qe_muram_offset
[POWERPC] QE: immap_qe.h should include asm/io.h
[POWERPC] QE: export qe_get_brg_clk()
[POWERPC] QE: fix sparse warnings
[POWERPC] 83xx: mpc837x_rdb: add simple-bus compatible matching
[POWERPC] 83xx: mpc8315 - fix USB UTMI Host setup
Badari Pulavarty (2):
[POWERPC] Add code for removing HPTEs for parts of the linear mapping
[POWERPC] Add error return from htab_remove_mapping()
Becky Bruce (1):
[LMB]: Make lmb support large physical addressing
Benjamin Herrenschmidt (7):
[POWERPC] Fix thinko in cpu_thread_mask_to_cores()
[POWERPC] Initialize paca->current earlier
[POWERPC] Fixup softirq preempt count
[POWERPC] properly declare onstack completion in iseries veth
[POWERPC] Fix device-tree locking vs. interrupts
[POWERPC] Move stackframe definitions to common header
[POWERPC] irqtrace support for 64-bit powerpc
Christoph Hellwig (1):
[POWERPC] Stacktrace support for lockdep
Dale Farnsworth (6):
[POWERPC] Remove dead code at KernelAltiVec
[POWERPC] prpmc2800: Fix frequencies in prpmc2800.dts
[POWERPC] mv64x60: Remove device tree absolute path references
[POWERPC] mv643xx_eth: Prepare to support multiple silicon blocks
[POWERPC] Document the mv64x60 device tree bindings
[POWERPC] prpmc2800 needs a dtbImage
David Gibson (1):
[POWERPC] Start removing linux,network-index in favour of aliases
David S. Miller (3):
[LIB]: Make PowerPC LMB code generic so sparc64 can use it too.
[LMB]: Fix bug in __lmb_alloc_base().
[LMB] Add lmb_alloc_nid()
David Woodhouse (1):
[POWERPC] Efika: Really, don't pretend to be CHRP
Geert Uytterhoeven (4):
[POWERPC] PS3: Save power in busy loops on halt
[POWERPC] move_device_tree() should be __init
[POWERPC] arch_add_memory() cannot be __devinit
[POWERPC] PS3: Split device setup for static vs. dynamic devices
Geoff Levand (2):
[POWERPC] PS3: Bootwrapper improvements
[POWERPC] PS3: Sys-manager Wake-on-LAN support
Gerhard Stenzel (1):
[POWERPC] spufs: fix incorrect file descriptors in SPU coredump note names
Grant Likely (2):
[POWERPC] add target for building .dtb files
[POWERPC] bootwrapper: Add a firmware-independent simpleboot target.
Haiying Wang (1):
[POWERPC] 85xx: Fix the size of qe muram for MPC8568E
Harvey Harrison (2):
[POWERPC] Replace remaining __FUNCTION__ occurrences
[POWERPC] ppc: Replace remaining __FUNCTION__ occurrences
Ionut Nicu (1):
[POWERPC] Fix kernel panic in arch_arm_kprobe
Ishizaki Kou (2):
[POWERPC] celleb: Coding style cleanup
[POWERPC] hvcbeat: Fix buffer manipulation
Jeremy Kerr (3):
[POWERPC] spufs: add newline to signal{1,2}_type files
[POWERPC] spufs: reacquire LS pointer in spu_process_callback
[POWERPC] spufs: save MFC command channel before purging MFC queue
Jerone Young (1):
[POWERPC] 4xx: Add idle wait support for 44x platforms
Jochen Friedrich (2):
[POWERPC] i2c: OF helpers for the i2c API
[POWERPC] i2c: Fix build breakage introduced by OF helpers
Johannes Berg (1):
[POWERPC] mpic: Make sparse happy
Johannes Weiner (2):
[POWERPC] Remove redundant display of free swap space in show_mem()
[POWERPC] ppc: Remove redundant display of free swap space in show_mem()
Josh Boyer (7):
[POWERPC] 4xx: Add AMCC 440EP Yosemite DTS
[POWERPC] 4xx: Add platform support for the AMCC Yosemite board
[POWERPC] 4xx: Add bootwrapper for AMCC Yosemite board
[POWERPC] 4xx: Add Canyonlands and Yosemite to multi-board defconfig
[POWERPC] Add of_device_is_available function
[POWERPC] 4xx: Reorganize 4xx defconfigs
[POWERPC] 4xx: Add ppc40x_defconfig
Julia Lawall (2):
[POWERPC] Use FIELD_SIZEOF in arch/ppc
[POWERPC] Use FIELD_SIZEOF in drivers/block/viodasd.c
Kumar Gala (23):
[LMB]: Fix initial lmb add region with a non-zero base
[LMB]: Fix lmb_add_region if region should be added at the head
[POWERPC] Remove Kconfig option BOOT_LOAD
[POWERPC] Provide access to arch/powerpc include path on ppc64
[POWERPC] Remove and replace uses of PPC_MEMSTART with memstart_addr
[POWERPC] Introduce lowmem_end_addr to distinguish from total_lowmem
[POWERPC] 85xx: Cleanup TLB initialization
[POWERPC] Use lowmem_end_addr to limit lmb allocations on ppc32
[POWERPC] Rename __initial_memory_limit to __initial_memory_limit_addr
[POWERPC] Clean up some linker and symbol usage
[POWERPC] Move phys_addr_t definition into asm/types.h
[POWERPC] Update linker script to properly set physical addresses
[POWERPC] bootwrapper: Use physical address in PHDR for uImage
[POWERPC] Cleanup pgtable-ppc32.h
[POWERPC] Remove unused machine call outs
[POWERPC] Rework Book-E debug exception handling
[POWERPC] 83xx/85xx: Reorganize defconfigs
[POWERPC] Make Book-E debug handling SMP safe
[POWERPC] 83xx: Enable FCM NAND and OF partitions in defconfig
[POWERPC] 85xx: Fix compile warning
[POWERPC] 85xx: Convert dts to v1 syntax
[POWERPC] 85xx: minor .dts cleanups
[POWERPC] fsl: Convert dts to v1 syntax
Laurent Pinchart (6):
[POWERPC] cpm_uart: Allocate DPRAM memory for SMC ports on CPM2-based platforms.
[POWERPC] Add bootwrapper function to get virtual reg from the device tree.
[POWERPC] cpm-serial: Relocate CPM buffer descriptors and SMC parameter ram.
[POWERPC] ep8248e: Reference SMC parameter RAM base in the device tree.
[POWERPC] CPM2: Reset the CPM when early debugging is not enabled.
[POWERPC] CPM: Move opcodes common to CPM1 and CPM2 to include/asm-powerpc/cpm.h
Manish Ahuja (11):
[POWERPC] pseries: phyp dump: Documentation
[POWERPC] pseries: phyp dump: Reserve and release memory
[POWERPC] pseries: phyp dump: Use sysfs to release reserved mem
[POWERPC] pseries: phyp dump: Register dump area
[POWERPC] pseries: phyp dump: Debugging print routines
[POWERPC] pseries: phyp dump: Invalidate and print dump areas
[POWERPC] pseries: phyp dump: Tracking memory range freed
[POWERPC] pseries: phyp dump: Add Kconfig file option
[POWERPC] pseries: phyp dump: Disable phyp-dump through boot-var
[POWERPC] pseries: phyp dump: Inform kdump when phyp-dump is loaded
[POWERPC] pseries/phyp dump: Reserve a variable amount of space at boot
Marian Balakowicz (1):
[POWERPC] Add 'model: ...' line to common show_cpuinfo()
Mark A. Greer (3):
[POWERPC] prpmc2800: Convert DTS to v1 and add labels
[POWERPC] mv64x60: Fix FDT compatible names: mv64x60 => mv64360
[POWERPC] prpmc2800: Clean up dts properties
Masakazu Mokuno (1):
[POWERPC] PS3: Gelic network driver Wake-on-LAN support
Michael Ellerman (6):
[POWERPC] Move prototype for find_udbg_vterm() into a header file
[POWERPC] Always add preferred consoles in platforms/pseries/lpar.c
[POWERPC] Move xics_setup_8259_cascade() into platforms/pseries/setup.c
[POWERPC] Turn xics_setup_8259_cascade() into a generic pseries_setup_i8259_cascade()
[POWERPC] Use pseries_setup_i8259_cascade() in pseries_mpic_init_IRQ()
[POWERPC] Simplify xics direct/lpar irq_host setup
Nate Case (1):
pasemi_mac: Netpoll support
Nathan Lynch (5):
[POWERPC] maple: Use platform name in define_machine()
[POWERPC] maple: Kill fixup_maple_ide
[POWERPC] maple: Enable ipr driver in defconfig
[POWERPC] scanlog_init cleanup and minor fixes
[POWERPC] Convert pci and eeh code to of_device_is_available
Olof Johansson (9):
pasemi_mac: Move RX/TX section enablement to dma_lib
[POWERPC] pasemi: Add flag management functions to dma_lib
[POWERPC] pasemi: Add function engine management functions to dma_lib
pasemi_mac: jumbo frame support
pasemi_mac: Enable GSO by default
pasemi_mac: basic ethtool support
pasemi_mac: Jumbo frame bugfixes
[POWERPC] pasemi: Minor iommu cleanup
[POWERPC] Remove unused __max_memory variable
Paul Gortmaker (5):
[POWERPC] 86xx: Add support for Wind River SBC8641D board
[POWERPC] 86xx: Add defconfig for Wind River SBC8641D board
[POWERPC] 86xx: Add device tree source for Wind River SBC8641D
[POWERPC] 86xx: mark functions static, other minor cleanups
[POWERPC] 86xx: mpc86xx_hpcn - Temporarily accept old dts node identifier.
Paul Mackerras (5):
[POWERPC] Fix handling of unrecoverable SLB miss interrupts
[LMB] Fix some whitespace and other formatting issues, use pr_debug
[LMB] Restructure allocation loops to avoid unsigned underflow
[POWERPC] Optimize fls64() on 64-bit processors
[POWERPC] Fix compile breakage for 64-bit UP configs
Robert Brose (1):
[POWERPC] Add kernel parameter to set l3cr for MPC745x
Robert P. J. Day (2):
[POWERPC] Move a.out.h to header-y since it doesn't check __KERNEL__
[POWERPC] Use __SPIN_LOCK_UNLOCKED macro in mpc52xx_set_psc_clkdiv
Roel Kluin (2):
[POWERPC] PS3: Fix unlikely typo in ps3_get_irq
[POWERPC] Replace logical-AND by bit-AND in pci_process_ISA_OF_ranges()
Roland McGrath (3):
[POWERPC] Don't touch PT_DTRACE in exec
[POWERPC] powerpc32: Remove asm-offsets ptrace cruft
[POWERPC] Define copy_siginfo_from_user32
S.
^ permalink raw reply
* Re: [PATCH] [POWERPC KVM] Kconfig fixes
From: Avi Kivity @ 2008-04-20 7:35 UTC (permalink / raw)
To: Hollis Blanchard; +Cc: kvm-devel, kvm-ppc-devel, linuxppc-dev
In-Reply-To: <a607ae1a7c8c4d674678.1208447016@localhost.localdomain>
Hollis Blanchard wrote:
> 1 file changed, 5 insertions(+), 6 deletions(-)
> arch/powerpc/kvm/Kconfig | 11 +++++------
>
>
> Don't allow building as a module (asm-offsets dependencies).
>
> Also, automatically select KVM_BOOKE_HOST until we better separate the guest
> and host layers.
>
>
Applied, thanks.
--
Do not meddle in the internals of kernels, for they are subtle and quick to panic.
^ permalink raw reply
* mpc8349, gb ethernet, bridging
From: R. Ebersole (VTI - new) @ 2008-04-20 5:36 UTC (permalink / raw)
To: linuxppc-embedded
Hi.
We are having some issues regarding bridging the 2 ethernet ports of an
mpc8349, and are
trying to determine what is going on.
We are attempting to daisy-chain several mpc8349-based boards via the 2
ethernet ports
on each 8349. When we enable bridging for the units, we (sometimes)
start seeing the following
on one of the interior bridge's (mostly on the root bridge) console(s):
NETDEV WATCHDOG: eth1 : transmit timed out
We then see the bridge output messages that indicate that is is going
through a topology
state change.
This situation keeps recurring.
At some point, the message from the bridge that it is entering a
disabled state for port #2
(eth1) is followed by garbage (actually, it appears to be some pointers
and/or memory
addresses printed out), and the system hangs.
We are using NAPI and the skbuff-recycling for the gianfar driver.
We use ring(s) of 32 buffers.
The gianfar's watchdog is set to 1Hz (once a seond ?)
We are not sure if/how affect things:
Port #1 of the 'root' bridge is attached directly to our LAN
Port #1 of the 'root' bridge runs at 10 Mbs
Port #2 of the 'root' bridge runs at 1Gbs
All other ports in the chain are 1Gbs
We are using CAT-5 cables for all connections
We have an application on each bridge in the chain that periodically
sends several hundred bytes
'up the chain', towards its head (ie, towards our LAN). This
application is typically running
when the issue is seen.
Setting the bridge's forwarding delay to 0 and hellotime to 6,000
helped, but did
not solve the issue.
???
--
Sometimes I feel like a red shirt in the Star Trek episode of life.
--
This message contains confidential information and is intended only for the
individual named. If you are not the intended recipient you should not
disseminate, distribute or copy this e-mail. Please notify the sender
immediately by e-mail if you have received this e-mail by mistake and delete
this e-mail from your system.
^ permalink raw reply
* Re: removal of arch/ppc in 2.6.27?
From: Dwayne Fontenot @ 2008-04-20 0:39 UTC (permalink / raw)
To: linuxppc-embedded
In-Reply-To: <D713F373-AE2A-4341-9C29-EF65B9399B36@kernel.crashing.org>
Kumar Gala <galak <at> kernel.crashing.org> writes:
>
> This is intended as a reminder that we plan on getting rid of arch/ppc
> this summer. I'm guessing based on kernel release times that will be
> 2.6.27. That would mean 2.6.26 will be the last kernel to support
> arch/ppc.
>
> If people have boards that like ported over please let us know and
> work with us to port this over to arch/powerpc.
>
> Here is a list based on arch/ppc/platforms. Its not intended to be
> complete but a general idea of what's left in arch/ppc.
>
...
> MVME5100 e6xx
I would very much like to see mvme5100 move to powerpc.
I'll help any way I can including trying to port it myself.
Is it significant that in arch/powerpc/platforms/prep/Kconfig
PPC_PREP depends on BROKEN ?
What are the implications of that?
Thanks,
Dwayne
^ permalink raw reply
* [PATCH] powerpc copy_siginfo_from_user32
From: Roland McGrath @ 2008-04-19 22:19 UTC (permalink / raw)
To: Paul Mackerras, Anton Blanchard; +Cc: linuxppc-dev
Hi. I posted this before, but I don't see it in any of your powerpc.git
trees. Can you push this upstream ASAP? It would make life easier for me
trying to merge some more generic changes (that would break powerpc builds
without this going in first).
Thanks,
Roland
---
[PATCH] powerpc copy_siginfo_from_user32
Define the copy_siginfo_from_user32 entry point for powerpc, so
that generic CONFIG_COMPAT code can call it. We already had the
code rolled into compat_sys_rt_sigqueueinfo, this just moves it
out into the canonical function that other arch's define.
Signed-off-by: Roland McGrath <roland@redhat.com>
---
arch/powerpc/kernel/signal_32.c | 19 ++++++++++++++++---
1 files changed, 16 insertions(+), 3 deletions(-)
diff --git a/arch/powerpc/kernel/signal_32.c b/arch/powerpc/kernel/signal_32.c
index d840bc7..ad69434 100644
--- a/arch/powerpc/kernel/signal_32.c
+++ b/arch/powerpc/kernel/signal_32.c
@@ -621,6 +621,18 @@ int copy_siginfo_to_user32(struct compat_siginfo __user *d, siginfo_t *s)
#define copy_siginfo_to_user copy_siginfo_to_user32
+int copy_siginfo_from_user32(siginfo_t *to, struct compat_siginfo __user *from)
+{
+ memset(to, 0, sizeof *to);
+
+ if (copy_from_user(to, from, 3*sizeof(int)) ||
+ copy_from_user(to->_sifields._pad,
+ from->_sifields._pad, SI_PAD_SIZE32))
+ return -EFAULT;
+
+ return 0;
+}
+
/*
* Note: it is necessary to treat pid and sig as unsigned ints, with the
* corresponding cast to a signed int to insure that the proper conversion
@@ -634,9 +646,10 @@ long compat_sys_rt_sigqueueinfo(u32 pid, u32 sig, compat_siginfo_t __user *uinfo
int ret;
mm_segment_t old_fs = get_fs();
- if (copy_from_user (&info, uinfo, 3*sizeof(int)) ||
- copy_from_user (info._sifields._pad, uinfo->_sifields._pad, SI_PAD_SIZE32))
- return -EFAULT;
+ ret = copy_siginfo_from_user32(&info, uinfo);
+ if (unlikely(ret))
+ return ret;
+
set_fs (KERNEL_DS);
/* The __user pointer cast is valid becasuse of the set_fs() */
ret = sys_rt_sigqueueinfo((int)pid, (int)sig, (siginfo_t __user *) &info);
^ permalink raw reply related
* Re: removal of arch/ppc in 2.6.27?
From: Chuck Meade @ 2008-04-19 20:43 UTC (permalink / raw)
To: linuxppc-dev
In-Reply-To: <D713F373-AE2A-4341-9C29-EF65B9399B36@kernel.crashing.org>
> This is intended as a reminder that we plan on getting rid of arch/ppc
> this summer. I'm guessing based on kernel release times that will be
> 2.6.27. That would mean 2.6.26 will be the last kernel to support
> arch/ppc.
>
> If people have boards that like ported over please let us know and
> work with us to port this over to arch/powerpc.
>
> Here is a list based on arch/ppc/platforms. Its not intended to be
> complete but a general idea of what's left in arch/ppc.
It would be nice to see the mbx860 get forward-ported. I just have not
had any time to get to it.
Chuck
^ permalink raw reply
* Re: [PATCH] [POWERPC] mpc5200: Switch mpc5200 dts files to dts-v1 format
From: Matt Sealey @ 2008-04-19 18:49 UTC (permalink / raw)
To: Robert Schwebel; +Cc: linuxppc-dev, m8, Sascha Hauer, Wolfram Sang
In-Reply-To: <20080419133658.GJ13814@pengutronix.de>
I wholeheartedly agree, although the difference between gpt and timer
and pic vs interrupt-controller (actually interrupt-controller is meant
to be a property of the interrupt controller, not a device type.. weird)
was chosen because they did not conflict with what might be considered
"standard device_types" with real OF (Forth, CIS) interfaces like read,
write, ping, world-peace etc.
However since Linux doesn't care about the interface provided by the
firmware and only reads the tree, and real OF interfaces MIGHT need
to be provided by these items on real OF firmwares, I don't see why
they should not be used.
A problem arises; how do you decide when you name something after what
it is rather than the documentation acronym? What does the 5200B CDM
turn into? The XLB arbiter module? What about the rest of the SIU?
There really needs to be a standards committee for this, that has good
experience with device trees and BSPs, and can work with the device
vendors and board manufacturers (Freescale for example) directly, with
them on the committee, who can give the docs a run though before any
board ever hits the streets...
--
Matt Sealey <matt@genesi-usa.com>
Genesi, Manager, Developer Relations
Robert Schwebel wrote:
> On Fri, Apr 18, 2008 at 09:10:04AM -0700, Grant Likely wrote:
>> Update dts files to current format
>
> Is it somehow possible that this device tree stuff is *not* changed over
> and over again and break everything out there? When people have not even
> agreed on basic things like decimal vs. hex numbers, the whole idea
> should be developed out-of-tree, then stabilize and *then* be submitted
> to the Linux mainline.
>
> Is it also really necessary to change like "gpt" vs. "timer" and "pic"
> vs. "interrupt-controller" all the time? If you compare the last
> mainline kernels, each one got a fundamental change in the naming, each
> time breaking anyone who doesn't have his stuff in the mainline yet.
>
> Sorry, but this is simply annoying, and the whole "the only thing we
> have to do is to define it once and be done then" is crap.
>
> Robert
^ permalink raw reply
* Re: [PATCH] [PPC] Remove mpc8272 ads board from arch/ppc
From: Grant Likely @ 2008-04-19 18:14 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-dev
In-Reply-To: <Pine.LNX.4.64.0804191051420.20132@blarg.am.freescale.net>
On Sat, Apr 19, 2008 at 9:52 AM, Kumar Gala <galak@kernel.crashing.org> wrote:
> We have a board port in arch/powerpc so we dont need this one anymore.
>
> Signed-off-by: Kumar Gala <galak@kernel.crashing.org>
Personally, I'd rather not do the piecemeal removal of board ports
from arch/ppc. We've only got one release left anyway. Removing them
just generates more churn and has the risk of causing other side
effects.
Cheers,
g.
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox