* [RFC/PATCH 3/9] powerpc: Fix declaration of pcibios_free_controller
From: Benjamin Herrenschmidt @ 2007-11-19 8:25 UTC (permalink / raw)
To: linuxppc-dev
In-Reply-To: <1195460700.350036.781662541765.qpush@grosgo>
pcibios_free_controller() is now available for both 32 and 64 bits
but the header only declares it for 64 bits. This moves the
declaration down next to the pcibios_alloc_controller() one.
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
---
include/asm-powerpc/pci-bridge.h | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
Index: linux-work/include/asm-powerpc/pci-bridge.h
===================================================================
--- linux-work.orig/include/asm-powerpc/pci-bridge.h 2007-11-16 13:44:32.000000000 +1100
+++ linux-work/include/asm-powerpc/pci-bridge.h 2007-11-16 13:46:40.000000000 +1100
@@ -247,7 +247,6 @@ static inline struct pci_controller *pci
return PCI_DN(busdn)->phb;
}
-extern void pcibios_free_controller(struct pci_controller *phb);
extern void isa_bridge_find_early(struct pci_controller *hose);
@@ -283,9 +282,11 @@ extern void
pci_process_bridge_OF_ranges(struct pci_controller *hose,
struct device_node *dev, int primary);
-/* Allocate a new PCI host bridge structure */
+/* Allocate & free a PCI host bridge structure */
extern struct pci_controller *
pcibios_alloc_controller(struct device_node *dev);
+extern void pcibios_free_controller(struct pci_controller *phb);
+
#ifdef CONFIG_PCI
extern unsigned long pci_address_to_pio(phys_addr_t address);
extern int pcibios_vaddr_is_ioport(void __iomem *address);
^ permalink raw reply
* [RFC/PATCH 2/9] powerpc: Merge pci_process_bridge_OF_ranges()
From: Benjamin Herrenschmidt @ 2007-11-19 8:25 UTC (permalink / raw)
To: linuxppc-dev
In-Reply-To: <1195460700.350036.781662541765.qpush@grosgo>
This patch merges the 32 and 64 bits implementations of
pci_process_bridge_OF_ranges(). The new function is cleaner than both
the old ones supports 64 bits ranges on ppc32 which is necessary for
the 4xx port.
It also adds some better (hopefully) output to the kernel log which
should help disagnose problems and makes better use of existing OF
parsing helpers (avoiding a few bugs of both implementations along
the way).
There are still a few unfortunate ifdef's but there is no way around
these for now at least not until some other bits of the PCI code are
made common.
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
---
Tested on a few pSeries, PowerMac G5, and a 32 bits PowerMacs and
a BriQ. Please let me know if it misbehaves anywhere else.
arch/powerpc/kernel/pci-common.c | 176 +++++++++++++++++++++++++++++++++++++++
arch/powerpc/kernel/pci_32.c | 114 -------------------------
arch/powerpc/kernel/pci_64.c | 93 --------------------
include/asm-powerpc/pci-bridge.h | 1
4 files changed, 177 insertions(+), 207 deletions(-)
Index: linux-work/arch/powerpc/kernel/pci-common.c
===================================================================
--- linux-work.orig/arch/powerpc/kernel/pci-common.c 2007-11-13 14:15:43.000000000 +1100
+++ linux-work/arch/powerpc/kernel/pci-common.c 2007-11-13 16:04:06.000000000 +1100
@@ -479,3 +479,179 @@ void pci_resource_to_user(const struct p
*start = rsrc->start - offset;
*end = rsrc->end - offset;
}
+
+/**
+ * pci_process_bridge_OF_ranges - Parse PCI bridge resources from device tree
+ * @hose: newly allocated pci_controller to be setup
+ * @dev: device node of the host bridge
+ * @primary: set if primary bus (32 bits only, soon to be deprecated)
+ *
+ * This function will parse the "ranges" property of a PCI host bridge device
+ * node and setup the resource mapping of a pci controller based on its
+ * content.
+ *
+ * Life would be boring if it wasn't for a few issues that we have to deal
+ * with here:
+ *
+ * - We can only cope with one IO space range and up to 3 Memory space
+ * ranges. However, some machines (thanks Apple !) tend to split their
+ * space into lots of small contiguous ranges. So we have to coalesce.
+ *
+ * - We can only cope with all memory ranges having the same offset
+ * between CPU addresses and PCI addresses. Unfortunately, some bridges
+ * are setup for a large 1:1 mapping along with a small "window" which
+ * maps PCI address 0 to some arbitrary high address of the CPU space in
+ * order to give access to the ISA memory hole.
+ * The way out of here that I've chosen for now is to always set the
+ * offset based on the first resource found, then override it if we
+ * have a different offset and the previous was set by an ISA hole.
+ *
+ * - Some busses have IO space not starting at 0, which causes trouble with
+ * the way we do our IO resource renumbering. The code somewhat deals with
+ * it for 64 bits but I would expect problems on 32 bits.
+ *
+ * - Some 32 bits platforms such as 4xx can have physical space larger than
+ * 32 bits so we need to use 64 bits values for the parsing
+ */
+void __devinit pci_process_bridge_OF_ranges(struct pci_controller *hose,
+ struct device_node *dev,
+ int primary)
+{
+ const u32 *ranges;
+ int rlen;
+ int pna = of_n_addr_cells(dev);
+ int np = pna + 5;
+ int memno = 0, isa_hole = -1;
+ u32 pci_space;
+ unsigned long long pci_addr, cpu_addr, pci_next, cpu_next, size;
+ unsigned long long isa_mb = 0;
+ struct resource *res;
+
+ printk(KERN_INFO "PCI host bridge %s %s ranges:\n",
+ dev->full_name, primary ? "(primary)" : "");
+
+ /* Get ranges property */
+ ranges = of_get_property(dev, "ranges", &rlen);
+ if (ranges == NULL)
+ return;
+
+ /* Parse it */
+ while ((rlen -= np * 4) >= 0) {
+ /* Read next ranges element */
+ pci_space = ranges[0];
+ pci_addr = of_read_number(ranges + 1, 2);
+ cpu_addr = of_translate_address(dev, ranges + 3);
+ size = of_read_number(ranges + pna + 3, 2);
+ ranges += np;
+ if (cpu_addr == OF_BAD_ADDR || size == 0)
+ continue;
+
+ /* Now consume following elements while they are contiguous */
+ for (;rlen >= np * sizeof(u32); ranges += np, rlen -= np * 4) {
+ if (ranges[0] != pci_space)
+ break;
+ pci_next = of_read_number(ranges + 1, 2);
+ cpu_next = of_translate_address(dev, ranges + 3);
+ if (pci_next != pci_addr + size ||
+ cpu_next != cpu_addr + size)
+ break;
+ size += of_read_number(ranges + pna + 3, 2);
+ }
+
+ /* Act based on address space type */
+ res = NULL;
+ switch ((pci_space >> 24) & 0x3) {
+ case 1: /* PCI IO space */
+ printk(KERN_INFO
+ " IO 0x%016llx..0x%016llx -> 0x%016llx\n",
+ cpu_addr, cpu_addr + size - 1, pci_addr);
+
+ /* We support only one IO range */
+ if (hose->pci_io_size) {
+ printk(KERN_WARNING
+ " \\--> Skipped (too many) !\n");
+ continue;
+ }
+#ifdef CONFIG_PPC32
+ /* On 32 bits, limit I/O space to 16MB */
+ if (size > 0x01000000)
+ size = 0x01000000;
+
+ /* 32 bits needs to map IOs here */
+ hose->io_base_virt = ioremap(cpu_addr, size);
+
+ /* Expect trouble if pci_addr is not 0 */
+ if (primary)
+ isa_io_base =
+ (unsigned long)hose->io_base_virt;
+#endif /* CONFIG_PPC32 */
+ /* pci_io_size and io_base_phys always represent IO
+ * space starting at 0 so we factor in pci_addr
+ */
+ hose->pci_io_size = pci_addr + size;
+ hose->io_base_phys = cpu_addr - pci_addr;
+
+ /* Build resource */
+ res = &hose->io_resource;
+ res->flags = IORESOURCE_IO;
+ res->start = pci_addr;
+ break;
+ case 2: /* PCI Memory space */
+ printk(KERN_INFO
+ " MEM 0x%016llx..0x%016llx -> 0x%016llx %s\n",
+ cpu_addr, cpu_addr + size - 1, pci_addr,
+ (pci_space & 0x40000000) ? "Prefetch" : "");
+
+ /* We support only 3 memory ranges */
+ if (memno >= 3) {
+ printk(KERN_WARNING
+ " \\--> Skipped (too many) !\n");
+ continue;
+ }
+ /* Handles ISA memory hole space here */
+ if (pci_addr == 0) {
+ isa_mb = cpu_addr;
+ isa_hole = memno;
+ if (primary || isa_mem_base == 0)
+ isa_mem_base = cpu_addr;
+ }
+
+ /* We get the PCI/Mem offset from the first range or the,
+ * current one if the offset came from an ISA hole.
+ * If they don't match, bugger.
+ */
+ if (memno == 0 ||
+ (isa_hole >= 0 && pci_addr != 0 &&
+ hose->pci_mem_offset == isa_mb))
+ hose->pci_mem_offset = cpu_addr - pci_addr;
+ else if (pci_addr != 0 &&
+ hose->pci_mem_offset != cpu_addr - pci_addr) {
+ printk(KERN_WARNING
+ " \\--> Skipped (offset mismatch) !\n");
+ continue;
+ }
+
+ /* Build resource */
+ res = &hose->mem_resources[memno++];
+ res->flags = IORESOURCE_MEM;
+ if (pci_space & 0x40000000)
+ res->flags |= IORESOURCE_PREFETCH;
+ res->start = cpu_addr;
+ break;
+ }
+ if (res != NULL) {
+ res->name = dev->full_name;
+ res->end = res->start + size - 1;
+ res->parent = NULL;
+ res->sibling = NULL;
+ res->child = NULL;
+ }
+ }
+
+ /* Out of paranoia, let's put the ISA hole last if any */
+ if (isa_hole >= 0 && memno > 0 && isa_hole != (memno-1)) {
+ struct resource tmp = hose->mem_resources[isa_hole];
+ hose->mem_resources[isa_hole] = hose->mem_resources[memno-1];
+ hose->mem_resources[memno-1] = tmp;
+ }
+}
Index: linux-work/arch/powerpc/kernel/pci_32.c
===================================================================
--- linux-work.orig/arch/powerpc/kernel/pci_32.c 2007-11-13 14:16:17.000000000 +1100
+++ linux-work/arch/powerpc/kernel/pci_32.c 2007-11-13 14:16:24.000000000 +1100
@@ -842,120 +842,6 @@ pci_device_from_OF_node(struct device_no
}
EXPORT_SYMBOL(pci_device_from_OF_node);
-void __init
-pci_process_bridge_OF_ranges(struct pci_controller *hose,
- struct device_node *dev, int primary)
-{
- static unsigned int static_lc_ranges[256] __initdata;
- const unsigned int *dt_ranges;
- unsigned int *lc_ranges, *ranges, *prev, size;
- int rlen = 0, orig_rlen;
- int memno = 0;
- struct resource *res;
- int np, na = of_n_addr_cells(dev);
- np = na + 5;
-
- /* First we try to merge ranges to fix a problem with some pmacs
- * that can have more than 3 ranges, fortunately using contiguous
- * addresses -- BenH
- */
- dt_ranges = of_get_property(dev, "ranges", &rlen);
- if (!dt_ranges)
- return;
- /* Sanity check, though hopefully that never happens */
- if (rlen > sizeof(static_lc_ranges)) {
- printk(KERN_WARNING "OF ranges property too large !\n");
- rlen = sizeof(static_lc_ranges);
- }
- lc_ranges = static_lc_ranges;
- memcpy(lc_ranges, dt_ranges, rlen);
- orig_rlen = rlen;
-
- /* Let's work on a copy of the "ranges" property instead of damaging
- * the device-tree image in memory
- */
- ranges = lc_ranges;
- prev = NULL;
- while ((rlen -= np * sizeof(unsigned int)) >= 0) {
- if (prev) {
- if (prev[0] == ranges[0] && prev[1] == ranges[1] &&
- (prev[2] + prev[na+4]) == ranges[2] &&
- (prev[na+2] + prev[na+4]) == ranges[na+2]) {
- prev[na+4] += ranges[na+4];
- ranges[0] = 0;
- ranges += np;
- continue;
- }
- }
- prev = ranges;
- ranges += np;
- }
-
- /*
- * The ranges property is laid out as an array of elements,
- * each of which comprises:
- * cells 0 - 2: a PCI address
- * cells 3 or 3+4: a CPU physical address
- * (size depending on dev->n_addr_cells)
- * cells 4+5 or 5+6: the size of the range
- */
- ranges = lc_ranges;
- rlen = orig_rlen;
- while (ranges && (rlen -= np * sizeof(unsigned int)) >= 0) {
- res = NULL;
- size = ranges[na+4];
- switch ((ranges[0] >> 24) & 0x3) {
- case 1: /* I/O space */
- if (ranges[2] != 0)
- break;
- hose->io_base_phys = ranges[na+2];
- /* limit I/O space to 16MB */
- if (size > 0x01000000)
- size = 0x01000000;
- hose->io_base_virt = ioremap(ranges[na+2], size);
- if (primary)
- isa_io_base = (unsigned long) hose->io_base_virt;
- res = &hose->io_resource;
- res->flags = IORESOURCE_IO;
- res->start = ranges[2];
- DBG("PCI: IO 0x%llx -> 0x%llx\n",
- (u64)res->start, (u64)res->start + size - 1);
- break;
- case 2: /* memory space */
- memno = 0;
- if (ranges[1] == 0 && ranges[2] == 0
- && ranges[na+4] <= (16 << 20)) {
- /* 1st 16MB, i.e. ISA memory area */
- if (primary)
- isa_mem_base = ranges[na+2];
- memno = 1;
- }
- while (memno < 3 && hose->mem_resources[memno].flags)
- ++memno;
- if (memno == 0)
- hose->pci_mem_offset = ranges[na+2] - ranges[2];
- if (memno < 3) {
- res = &hose->mem_resources[memno];
- res->flags = IORESOURCE_MEM;
- if(ranges[0] & 0x40000000)
- res->flags |= IORESOURCE_PREFETCH;
- res->start = ranges[na+2];
- DBG("PCI: MEM[%d] 0x%llx -> 0x%llx\n", memno,
- (u64)res->start, (u64)res->start + size - 1);
- }
- break;
- }
- if (res != NULL) {
- res->name = dev->full_name;
- res->end = res->start + size - 1;
- res->parent = NULL;
- res->sibling = NULL;
- res->child = NULL;
- }
- ranges += np;
- }
-}
-
/* We create the "pci-OF-bus-map" property now so it appears in the
* /proc device tree
*/
Index: linux-work/arch/powerpc/kernel/pci_64.c
===================================================================
--- linux-work.orig/arch/powerpc/kernel/pci_64.c 2007-11-13 14:15:43.000000000 +1100
+++ linux-work/arch/powerpc/kernel/pci_64.c 2007-11-13 14:16:24.000000000 +1100
@@ -592,99 +592,6 @@ int pci_proc_domain(struct pci_bus *bus)
}
}
-void __devinit pci_process_bridge_OF_ranges(struct pci_controller *hose,
- struct device_node *dev, int prim)
-{
- const unsigned int *ranges;
- unsigned int pci_space;
- unsigned long size;
- int rlen = 0;
- int memno = 0;
- struct resource *res;
- int np, na = of_n_addr_cells(dev);
- unsigned long pci_addr, cpu_phys_addr;
-
- np = na + 5;
-
- /* From "PCI Binding to 1275"
- * The ranges property is laid out as an array of elements,
- * each of which comprises:
- * cells 0 - 2: a PCI address
- * cells 3 or 3+4: a CPU physical address
- * (size depending on dev->n_addr_cells)
- * cells 4+5 or 5+6: the size of the range
- */
- ranges = of_get_property(dev, "ranges", &rlen);
- if (ranges == NULL)
- return;
- hose->io_base_phys = 0;
- while ((rlen -= np * sizeof(unsigned int)) >= 0) {
- res = NULL;
- pci_space = ranges[0];
- pci_addr = ((unsigned long)ranges[1] << 32) | ranges[2];
- cpu_phys_addr = of_translate_address(dev, &ranges[3]);
- size = ((unsigned long)ranges[na+3] << 32) | ranges[na+4];
- ranges += np;
- if (size == 0)
- continue;
-
- /* Now consume following elements while they are contiguous */
- while (rlen >= np * sizeof(unsigned int)) {
- unsigned long addr, phys;
-
- if (ranges[0] != pci_space)
- break;
- addr = ((unsigned long)ranges[1] << 32) | ranges[2];
- phys = ranges[3];
- if (na >= 2)
- phys = (phys << 32) | ranges[4];
- if (addr != pci_addr + size ||
- phys != cpu_phys_addr + size)
- break;
-
- size += ((unsigned long)ranges[na+3] << 32)
- | ranges[na+4];
- ranges += np;
- rlen -= np * sizeof(unsigned int);
- }
-
- switch ((pci_space >> 24) & 0x3) {
- case 1: /* I/O space */
- hose->io_base_phys = cpu_phys_addr - pci_addr;
- /* handle from 0 to top of I/O window */
- hose->pci_io_size = pci_addr + size;
-
- res = &hose->io_resource;
- res->flags = IORESOURCE_IO;
- res->start = pci_addr;
- DBG("phb%d: IO 0x%lx -> 0x%lx\n", hose->global_number,
- res->start, res->start + size - 1);
- break;
- case 2: /* memory space */
- memno = 0;
- while (memno < 3 && hose->mem_resources[memno].flags)
- ++memno;
-
- if (memno == 0)
- hose->pci_mem_offset = cpu_phys_addr - pci_addr;
- if (memno < 3) {
- res = &hose->mem_resources[memno];
- res->flags = IORESOURCE_MEM;
- res->start = cpu_phys_addr;
- DBG("phb%d: MEM 0x%lx -> 0x%lx\n", hose->global_number,
- res->start, res->start + size - 1);
- }
- break;
- }
- if (res != NULL) {
- res->name = dev->full_name;
- res->end = res->start + size - 1;
- res->parent = NULL;
- res->sibling = NULL;
- res->child = NULL;
- }
- }
-}
#ifdef CONFIG_HOTPLUG
Index: linux-work/include/asm-powerpc/pci-bridge.h
===================================================================
--- linux-work.orig/include/asm-powerpc/pci-bridge.h 2007-11-13 14:15:43.000000000 +1100
+++ linux-work/include/asm-powerpc/pci-bridge.h 2007-11-13 14:16:24.000000000 +1100
@@ -27,6 +27,7 @@ struct pci_controller {
void __iomem *io_base_virt;
resource_size_t io_base_phys;
+ resource_size_t pci_io_size;
/* Some machines (PReP) have a non 1:1 mapping of
* the PCI memory space in the CPU bus space
^ permalink raw reply
* [RFC/PATCH 1/9] powerpc: Make isa_mem_base common to 32 and 64 bits
From: Benjamin Herrenschmidt @ 2007-11-19 8:25 UTC (permalink / raw)
To: linuxppc-dev
In-Reply-To: <1195460700.350036.781662541765.qpush@grosgo>
This defines isa_mem_base on both 32 and 64 bits (it used to be 32 bits
only). This avoids a few ifdef's in later patches and potentially can
allow support for VGA text mode on 64 bits powerpc.
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
---
Small cleanup pre-requisite for my next patch
arch/powerpc/kernel/pci-common.c | 4 ++++
arch/powerpc/kernel/pci_32.c | 1 -
include/asm-powerpc/io.h | 5 +++--
3 files changed, 7 insertions(+), 3 deletions(-)
Index: linux-work/arch/powerpc/kernel/pci-common.c
===================================================================
--- linux-work.orig/arch/powerpc/kernel/pci-common.c 2007-11-13 14:11:11.000000000 +1100
+++ linux-work/arch/powerpc/kernel/pci-common.c 2007-11-13 14:15:43.000000000 +1100
@@ -52,6 +52,10 @@ int global_phb_number; /* Global phb co
extern struct list_head hose_list;
+/* ISA Memory physical address (or 0 if none) */
+resource_size_t isa_mem_base = 0;
+
+
/*
* pci_controller(phb) initialized common variables.
*/
Index: linux-work/include/asm-powerpc/io.h
===================================================================
--- linux-work.orig/include/asm-powerpc/io.h 2007-11-13 14:12:01.000000000 +1100
+++ linux-work/include/asm-powerpc/io.h 2007-11-13 14:12:48.000000000 +1100
@@ -50,15 +50,16 @@ extern int check_legacy_ioport(unsigned
#define PCI_DRAM_OFFSET pci_dram_offset
#else
#define _IO_BASE pci_io_base
-#define _ISA_MEM_BASE 0
+#define _ISA_MEM_BASE isa_mem_base
#define PCI_DRAM_OFFSET 0
#endif
extern unsigned long isa_io_base;
-extern unsigned long isa_mem_base;
extern unsigned long pci_io_base;
extern unsigned long pci_dram_offset;
+extern resource_size_t isa_mem_base;
+
#if defined(CONFIG_PPC32) && defined(CONFIG_PPC_INDIRECT_IO)
#error CONFIG_PPC_INDIRECT_IO is not yet supported on 32 bits
#endif
Index: linux-work/arch/powerpc/kernel/pci_32.c
===================================================================
--- linux-work.orig/arch/powerpc/kernel/pci_32.c 2007-11-13 14:16:15.000000000 +1100
+++ linux-work/arch/powerpc/kernel/pci_32.c 2007-11-13 14:16:17.000000000 +1100
@@ -32,7 +32,6 @@
#endif
unsigned long isa_io_base = 0;
-unsigned long isa_mem_base = 0;
unsigned long pci_dram_offset = 0;
int pcibios_assign_bus_offset = 1;
^ permalink raw reply
* [RFC/PATCH 0/9] powerpc: 4xx PCI work in progress
From: Benjamin Herrenschmidt @ 2007-11-19 8:25 UTC (permalink / raw)
To: linuxppc-dev
Because a mailing list is the best of backups and I've get something
working allright on ebony right now, I figured I would post my WIP
pile of patch bringing PCI to the 44x arch/powerpc world.
At this stage, only ebony is hooked up, there's a known problem with
the SCSI layer and non-coherent architecture that causes random
corruption for which I'm trying to find a solution, and e1000 has a
problem with resources > 32 bits for which I have a separate patch.
^ permalink raw reply
* Re: [BUG] 2.6.24-rc2-mm1 - kernel bug on nfs v4
From: Torsten Kaiser @ 2007-11-19 7:15 UTC (permalink / raw)
To: Trond Myklebust
Cc: Peter Zijlstra, steved, LKML, Kamalesh Babulal, linuxppc-dev, nfs,
Andrew Morton, Jan Blunck, Ingo Molnar, Balbir Singh
In-Reply-To: <1195413486.7893.16.camel@heimdal.trondhjem.org>
On Nov 18, 2007 8:18 PM, Trond Myklebust <trond.myklebust@fys.uio.no> wrote:
> On Sun, 2007-11-18 at 19:44 +0100, Torsten Kaiser wrote:
> > NFSv2/3 and NFSv4 share the same dentry_iput and so share the same
> > unlink and sillyrename logic.
> > But they do not share nfs_init_server()!
> >
> > I wonder why this doesn't blow up more violently, but only hangs...
> >
> > But as I don't know if it is correct to add the workqueue
> > initialization to nfs4_init_server() or remove the nfs_sb_active /
> > nfs_sb_deactive for the NFSv4 case, I can't offer a patch to fix this.
> >
> > Torsten
>
> I had already fixed that one in my own stack. Attached are the 3 patches
> that I've got. 1 from SteveD, 2 fixes.
>
Moving the init_waitqueue_head() like patch
linux-2.6.24-006-fix_to_fix_sillyrename_bug_on_umount.dif and applying
linux-2.6.24-007-fix_nfs_free_unlinkdata.dif lets my testcase work.
Also lockdep no longer complains about the non-static key.
Torsten
^ permalink raw reply
* [PATCH] 2.6.24-rc2-mm1 powerpc (iseries)- build failure - mm/stab.c
From: Stephen Rothwell @ 2007-11-19 6:44 UTC (permalink / raw)
To: paulus; +Cc: linuxppc-dev, akpm, anton, linux-kernel, Kamalesh Babulal
In-Reply-To: <20071119062611.GA11135@linux.vnet.ibm.com>
From: Kamalesh Babulal <kamalesh@linux.vnet.ibm.com>
The kernel builds fails with following error, with randconfig
CC arch/powerpc/mm/stab.o
arch/powerpc/mm/stab.c: In function ‘stab_initialize’:
arch/powerpc/mm/stab.c:282: error: implicit declaration of function ‘HvCall1’
arch/powerpc/mm/stab.c:282: error: ‘HvCallBaseSetASR’ undeclared (first use in this function)
arch/powerpc/mm/stab.c:282: error: (Each undeclared identifier is reported only once
arch/powerpc/mm/stab.c:282: error: for each function it appears in.)
make[1]: *** [arch/powerpc/mm/stab.o] Error 1
make: *** [arch/powerpc/mm] Error 2
Signed-off-by: Kamalesh Babulal <kamalesh@linux.vnet.ibm.com>
Acked-by: Stephen Rothwell <sfr@canb.auug.org.au>
---
arch/powerpc/mm/stab.c | 1 +
1 files changed, 1 insertions(+), 0 deletions(-)
On Mon, 19 Nov 2007 11:56:11 +0530 Kamalesh Babulal <kamalesh@linux.vnet.ibm.com> wrote:
>
> Resubmitting the patch titled
> powerpc-iseries-build-failure-mm-stabc.patch in the -mm tree.
Paulus, this should be fine for merging like above.
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
diff --git a/arch/powerpc/mm/stab.c b/arch/powerpc/mm/stab.c
index 9e85bda..50448d5 100644
--- a/arch/powerpc/mm/stab.c
+++ b/arch/powerpc/mm/stab.c
@@ -20,6 +20,7 @@
#include <asm/lmb.h>
#include <asm/abs_addr.h>
#include <asm/firmware.h>
+#include <asm/iseries/hv_call.h>
struct stab_entry {
unsigned long esid_data;
--
1.5.3.5
^ permalink raw reply related
* [RFC/PATCH] powerpc: Fix 8xx build breakage due to _tlbie changes
From: Benjamin Herrenschmidt @ 2007-11-19 6:41 UTC (permalink / raw)
To: Josh Boyer, linuxppc-dev
In-Reply-To: <1195454481.61987.176042550045.qpush@grosgo>
My changes to _tlbie to fix 4xx unfortunately broke 8xx build in a
couple of places. This fixes it.
Spotted by Olof Johansson
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
---
arch/powerpc/mm/mem.c | 2 +-
arch/powerpc/mm/mmu_decl.h | 2 +-
arch/ppc/mm/init.c | 2 +-
arch/ppc/mm/mmu_decl.h | 2 +-
4 files changed, 4 insertions(+), 4 deletions(-)
Index: linux-work/arch/powerpc/mm/mem.c
===================================================================
--- linux-work.orig/arch/powerpc/mm/mem.c 2007-11-15 13:59:27.000000000 +1100
+++ linux-work/arch/powerpc/mm/mem.c 2007-11-15 13:59:44.000000000 +1100
@@ -464,7 +464,7 @@ void update_mmu_cache(struct vm_area_str
* we invalidate the TLB here, thus avoiding dcbst
* misbehaviour.
*/
- _tlbie(address);
+ _tlbie(address, 0 /* 8xx doesn't care about PID */);
#endif
if (!PageReserved(page)
&& !test_bit(PG_arch_1, &page->flags)) {
Index: linux-work/arch/ppc/mm/init.c
===================================================================
--- linux-work.orig/arch/ppc/mm/init.c 2007-11-15 14:00:20.000000000 +1100
+++ linux-work/arch/ppc/mm/init.c 2007-11-15 14:00:35.000000000 +1100
@@ -561,7 +561,7 @@ void update_mmu_cache(struct vm_area_str
* That means the zeroed TLB has to be invalidated
* whenever a page miss occurs.
*/
- _tlbie(address);
+ _tlbie(address, 0 /* 8xx doesn't care about PID */);
#endif
if (!PageReserved(page)
&& !test_bit(PG_arch_1, &page->flags)) {
Index: linux-work/arch/powerpc/mm/mmu_decl.h
===================================================================
--- linux-work.orig/arch/powerpc/mm/mmu_decl.h 2007-11-15 14:09:16.000000000 +1100
+++ linux-work/arch/powerpc/mm/mmu_decl.h 2007-11-15 14:14:29.000000000 +1100
@@ -56,7 +56,7 @@ extern unsigned long total_lowmem;
* architectures. -- Dan
*/
#if defined(CONFIG_8xx)
-#define flush_HPTE(X, va, pg) _tlbie(va)
+#define flush_HPTE(X, va, pg) _tlbie(va, 0, /* 8xx doesn't care about PID */)
#define MMU_init_hw() do { } while(0)
#define mmu_mapin_ram() (0UL)
Index: linux-work/arch/ppc/mm/mmu_decl.h
===================================================================
--- linux-work.orig/arch/ppc/mm/mmu_decl.h 2007-11-15 14:08:54.000000000 +1100
+++ linux-work/arch/ppc/mm/mmu_decl.h 2007-11-15 14:14:45.000000000 +1100
@@ -49,7 +49,7 @@ extern unsigned int num_tlbcam_entries;
* architectures. -- Dan
*/
#if defined(CONFIG_8xx)
-#define flush_HPTE(X, va, pg) _tlbie(va)
+#define flush_HPTE(X, va, pg) _tlbie(va, 0 /* 8xx doesn't care about PID */)
#define MMU_init_hw() do { } while(0)
#define mmu_mapin_ram() (0UL)
^ permalink raw reply
* [RFC/PATCH] powerpc: 4xx PCI work in progress
From: Benjamin Herrenschmidt @ 2007-11-19 6:41 UTC (permalink / raw)
To: Josh Boyer, linuxppc-dev
Because a mailing list is the best of backups and I've get something
working allright on ebony right now, I figured I would post my WIP
pile of patch bringing PCI to the 44x arch/powerpc world.
At this stage, only ebony is hooked up, there's a known problem with
the SCSI layer and non-coherent architecture that causes random
corruption for which I'm trying to find a solution, and e1000 has a
problem with resources > 32 bits for which I have a separate patch.
^ permalink raw reply
* [PATCH] powerpc: Fix 8xx build breakage due to _tlbie changes
From: Benjamin Herrenschmidt @ 2007-11-19 6:40 UTC (permalink / raw)
To: Josh Boyer, linuxppc-dev
My changes to _tlbie to fix 4xx unfortunately broke 8xx build in a
couple of places. This fixes it.
Spotted by Olof Johansson
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
---
arch/powerpc/mm/mem.c | 2 +-
arch/powerpc/mm/mmu_decl.h | 2 +-
arch/ppc/mm/init.c | 2 +-
arch/ppc/mm/mmu_decl.h | 2 +-
4 files changed, 4 insertions(+), 4 deletions(-)
Index: linux-work/arch/powerpc/mm/mem.c
===================================================================
--- linux-work.orig/arch/powerpc/mm/mem.c 2007-11-15 13:59:27.000000000 +1100
+++ linux-work/arch/powerpc/mm/mem.c 2007-11-15 13:59:44.000000000 +1100
@@ -464,7 +464,7 @@ void update_mmu_cache(struct vm_area_str
* we invalidate the TLB here, thus avoiding dcbst
* misbehaviour.
*/
- _tlbie(address);
+ _tlbie(address, 0 /* 8xx doesn't care about PID */);
#endif
if (!PageReserved(page)
&& !test_bit(PG_arch_1, &page->flags)) {
Index: linux-work/arch/ppc/mm/init.c
===================================================================
--- linux-work.orig/arch/ppc/mm/init.c 2007-11-15 14:00:20.000000000 +1100
+++ linux-work/arch/ppc/mm/init.c 2007-11-15 14:00:35.000000000 +1100
@@ -561,7 +561,7 @@ void update_mmu_cache(struct vm_area_str
* That means the zeroed TLB has to be invalidated
* whenever a page miss occurs.
*/
- _tlbie(address);
+ _tlbie(address, 0 /* 8xx doesn't care about PID */);
#endif
if (!PageReserved(page)
&& !test_bit(PG_arch_1, &page->flags)) {
Index: linux-work/arch/powerpc/mm/mmu_decl.h
===================================================================
--- linux-work.orig/arch/powerpc/mm/mmu_decl.h 2007-11-15 14:09:16.000000000 +1100
+++ linux-work/arch/powerpc/mm/mmu_decl.h 2007-11-15 14:14:29.000000000 +1100
@@ -56,7 +56,7 @@ extern unsigned long total_lowmem;
* architectures. -- Dan
*/
#if defined(CONFIG_8xx)
-#define flush_HPTE(X, va, pg) _tlbie(va)
+#define flush_HPTE(X, va, pg) _tlbie(va, 0, /* 8xx doesn't care about PID */)
#define MMU_init_hw() do { } while(0)
#define mmu_mapin_ram() (0UL)
Index: linux-work/arch/ppc/mm/mmu_decl.h
===================================================================
--- linux-work.orig/arch/ppc/mm/mmu_decl.h 2007-11-15 14:08:54.000000000 +1100
+++ linux-work/arch/ppc/mm/mmu_decl.h 2007-11-15 14:14:45.000000000 +1100
@@ -49,7 +49,7 @@ extern unsigned int num_tlbcam_entries;
* architectures. -- Dan
*/
#if defined(CONFIG_8xx)
-#define flush_HPTE(X, va, pg) _tlbie(va)
+#define flush_HPTE(X, va, pg) _tlbie(va, 0 /* 8xx doesn't care about PID */)
#define MMU_init_hw() do { } while(0)
#define mmu_mapin_ram() (0UL)
^ permalink raw reply
* libfdt: Abolish fdt_offset_ptr_typed()
From: David Gibson @ 2007-11-19 6:26 UTC (permalink / raw)
To: Jon Loeliger; +Cc: linuxppc-dev
The fdt_offset_ptr_typed() macro seemed like a good idea at the time.
However, it's not actually used all that often, it can silently throw
away const qualifications and it uses a gcc extension (typeof) which
I'd prefer to avoid for portability.
Therefore, this patch gets rid of it (and the fdt_offset_ptr_typed_w()
variant which was never used at all). It also makes a few variables
const in testcases, which always should have been const, but weren't
caught before because of the aforementioned silent discards.
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
Index: dtc/libfdt/libfdt.h
===================================================================
--- dtc.orig/libfdt/libfdt.h 2007-11-19 17:22:28.000000000 +1100
+++ dtc/libfdt/libfdt.h 2007-11-19 17:22:55.000000000 +1100
@@ -128,12 +128,6 @@ static inline void *fdt_offset_ptr_w(voi
return (void *)fdt_offset_ptr(fdt, offset, checklen);
}
-
-#define fdt_offset_ptr_typed(fdt, offset, var) \
- ((typeof(var))(fdt_offset_ptr((fdt), (offset), sizeof(*(var)))))
-#define fdt_offset_ptr_typed_w(fdt, offset, var) \
- ((typeof(var))(fdt_offset_ptr_w((fdt), (offset), sizeof(*(var)))))
-
uint32_t fdt_next_tag(const void *fdt, int offset, int *nextoffset);
/**********************************************************************/
Index: dtc/libfdt/fdt_ro.c
===================================================================
--- dtc.orig/libfdt/fdt_ro.c 2007-11-19 17:22:28.000000000 +1100
+++ dtc/libfdt/fdt_ro.c 2007-11-19 17:22:55.000000000 +1100
@@ -249,7 +249,7 @@ const struct fdt_property *fdt_get_prope
case FDT_PROP:
err = -FDT_ERR_BADSTRUCTURE;
- prop = fdt_offset_ptr_typed(fdt, offset, prop);
+ prop = fdt_offset_ptr(fdt, offset, sizeof(*prop));
if (! prop)
goto fail;
namestroff = fdt32_to_cpu(prop->nameoff);
Index: dtc/tests/root_node.c
===================================================================
--- dtc.orig/tests/root_node.c 2007-11-19 17:22:28.000000000 +1100
+++ dtc/tests/root_node.c 2007-11-19 17:22:55.000000000 +1100
@@ -32,12 +32,12 @@
int main(int argc, char *argv[])
{
void *fdt;
- struct fdt_node_header *nh;
+ const struct fdt_node_header *nh;
test_init(argc, argv);
fdt = load_blob_arg(argc, argv);
- nh = fdt_offset_ptr_typed(fdt, 0, nh);
+ nh = fdt_offset_ptr(fdt, 0, sizeof(*nh));
if (! nh)
FAIL("NULL retrieving root node");
Index: dtc/tests/path_offset.c
===================================================================
--- dtc.orig/tests/path_offset.c 2007-11-19 17:22:28.000000000 +1100
+++ dtc/tests/path_offset.c 2007-11-19 17:22:55.000000000 +1100
@@ -31,7 +31,7 @@
int check_subnode(void *fdt, int parent, const char *name)
{
int offset;
- struct fdt_node_header *nh;
+ const struct fdt_node_header *nh;
uint32_t tag;
verbose_printf("Checking subnode \"%s\" of %d...", name, parent);
@@ -39,7 +39,7 @@ int check_subnode(void *fdt, int parent,
verbose_printf("offset %d...", offset);
if (offset < 0)
FAIL("fdt_subnode_offset(\"%s\"): %s", name, fdt_strerror(offset));
- nh = fdt_offset_ptr_typed(fdt, offset, nh);
+ nh = fdt_offset_ptr(fdt, offset, sizeof(*nh));
verbose_printf("pointer %p\n", nh);
if (! nh)
FAIL("NULL retrieving subnode \"%s\"", name);
Index: dtc/tests/subnode_offset.c
===================================================================
--- dtc.orig/tests/subnode_offset.c 2007-11-19 17:22:28.000000000 +1100
+++ dtc/tests/subnode_offset.c 2007-11-19 17:22:55.000000000 +1100
@@ -31,7 +31,7 @@
int check_subnode(struct fdt_header *fdt, int parent, const char *name)
{
int offset;
- struct fdt_node_header *nh;
+ const struct fdt_node_header *nh;
uint32_t tag;
verbose_printf("Checking subnode \"%s\" of %d...", name, parent);
@@ -39,7 +39,7 @@ int check_subnode(struct fdt_header *fdt
verbose_printf("offset %d...", offset);
if (offset < 0)
FAIL("fdt_subnode_offset(\"%s\"): %s", name, fdt_strerror(offset));
- nh = fdt_offset_ptr_typed(fdt, offset, nh);
+ nh = fdt_offset_ptr(fdt, offset, sizeof(*nh));
verbose_printf("pointer %p\n", nh);
if (! nh)
FAIL("NULL retrieving subnode \"%s\"", name);
Index: dtc/tests/dtbs_equal_ordered.c
===================================================================
--- dtc.orig/tests/dtbs_equal_ordered.c 2007-11-19 17:22:28.000000000 +1100
+++ dtc/tests/dtbs_equal_ordered.c 2007-11-19 17:22:55.000000000 +1100
@@ -93,10 +93,10 @@ void compare_structure(const void *fdt1,
break;
case FDT_PROP:
- prop1 = fdt_offset_ptr_typed(fdt1, offset1, prop1);
+ prop1 = fdt_offset_ptr(fdt1, offset1, sizeof(*prop1));
if (!prop1)
FAIL("Could get fdt1 property at %d", offset1);
- prop2 = fdt_offset_ptr_typed(fdt2, offset2, prop2);
+ prop2 = fdt_offset_ptr(fdt2, offset2, sizeof(*prop2));
if (!prop2)
FAIL("Could get fdt2 property at %d", offset2);
--
David Gibson | I'll have my music baroque, and my code
david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson
^ permalink raw reply
* [PATCH-RESEND] 2.6.24-rc2-mm1 powerpc (iseries)- build failure - mm/stab.c
From: Kamalesh Babulal @ 2007-11-19 6:26 UTC (permalink / raw)
To: Stephen Rothwell
Cc: anton, linux-kernel, Kamalesh Babulal, linuxppc-dev, paulus, akpm
In-Reply-To: <20071119133849.bcfe52c1.sfr@canb.auug.org.au>
Hi Stephen,
Resubmitting the patch titled
powerpc-iseries-build-failure-mm-stabc.patch in the -mm tree.
Signed-off-by: Kamalesh Babulal <kamalesh@linux.vnet.ibm.com>
--
--- linux-2.6.24-rc2/arch/powerpc/mm/stab.c 2007-11-07 03:27:46.000000000 +0530
+++ linux-2.6.24-rc2/arch/powerpc/mm/~stab.c 2007-11-19 19:43:55.000000000 +0530
@@ -20,6 +20,7 @@
#include <asm/lmb.h>
#include <asm/abs_addr.h>
#include <asm/firmware.h>
+#include <asm/iseries/hv_call.h>
struct stab_entry {
unsigned long esid_data;
--
Thanks & Regards,
Kamalesh Babulal,
Linux Technology Center,
IBM, ISTL.
^ permalink raw reply
* [PATCH] [POWERPC] remove redundant declaration of hose_list.
From: Stephen Rothwell @ 2007-11-19 6:17 UTC (permalink / raw)
To: paulus; +Cc: ppc-dev
It is already declared in ppc-pci.h which is included.
Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
---
arch/powerpc/kernel/pci-common.c | 2 --
1 files changed, 0 insertions(+), 2 deletions(-)
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
diff --git a/arch/powerpc/kernel/pci-common.c b/arch/powerpc/kernel/pci-common.c
index 742ff72..15ec71a 100644
--- a/arch/powerpc/kernel/pci-common.c
+++ b/arch/powerpc/kernel/pci-common.c
@@ -50,8 +50,6 @@ static DEFINE_SPINLOCK(hose_spinlock);
/* XXX kill that some day ... */
static int global_phb_number; /* Global phb counter */
-extern struct list_head hose_list;
-
/*
* pci_controller(phb) initialized common variables.
*/
--
1.5.3.5
^ permalink raw reply related
* [PATCH] [POWERPC] iSeries: fix sparse warnings in setup.c
From: Stephen Rothwell @ 2007-11-19 6:10 UTC (permalink / raw)
To: paulus; +Cc: ppc-dev
arch/powerpc/platforms/iseries/setup.c:111:27: warning: constant 0x100000000 is so big it is long
arch/powerpc/platforms/iseries/setup.c:113:23: warning: constant 0x100000000 is so big it is long
arch/powerpc/platforms/iseries/setup.c:117:27: warning: constant 0x000fffffffffffff is so big it is long
arch/powerpc/platforms/iseries/setup.c:127:28: warning: constant 0x100000000 is so big it is long
arch/powerpc/platforms/iseries/setup.c:129:24: warning: constant 0x100000000 is so big it is long
arch/powerpc/platforms/iseries/setup.c:233:5: warning: constant 0x000fffffffffffff is so big it is long
arch/powerpc/platforms/iseries/setup.c:235:5: warning: constant 0x000fffffffffffff is so big it is long
arch/powerpc/platforms/iseries/setup.c:319:6: warning: symbol 'mschunks_alloc' was not declared. Should it be static?
arch/powerpc/platforms/iseries/setup.c:661:6: warning: symbol 'iSeries_early_setup' was not declared. Should it be static?
Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
---
arch/powerpc/platforms/iseries/setup.c | 16 ++++++++--------
arch/powerpc/platforms/iseries/setup.h | 1 +
2 files changed, 9 insertions(+), 8 deletions(-)
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
diff --git a/arch/powerpc/platforms/iseries/setup.c b/arch/powerpc/platforms/iseries/setup.c
index 8a652da..2175a71 100644
--- a/arch/powerpc/platforms/iseries/setup.c
+++ b/arch/powerpc/platforms/iseries/setup.c
@@ -108,13 +108,13 @@ static unsigned long iSeries_process_Condor_mainstore_vpd(
* correctly.
*/
mb_array[0].logicalStart = 0;
- mb_array[0].logicalEnd = 0x100000000;
+ mb_array[0].logicalEnd = 0x100000000UL;
mb_array[0].absStart = 0;
- mb_array[0].absEnd = 0x100000000;
+ mb_array[0].absEnd = 0x100000000UL;
if (holeSize) {
numMemoryBlocks = 2;
- holeStart = holeStart & 0x000fffffffffffff;
+ holeStart = holeStart & 0x000fffffffffffffUL;
holeStart = addr_to_chunk(holeStart);
holeFirstChunk = holeStart;
holeSize = addr_to_chunk(holeSize);
@@ -124,9 +124,9 @@ static unsigned long iSeries_process_Condor_mainstore_vpd(
mb_array[0].logicalEnd = holeFirstChunk;
mb_array[0].absEnd = holeFirstChunk;
mb_array[1].logicalStart = holeFirstChunk;
- mb_array[1].logicalEnd = 0x100000000 - holeSizeChunks;
+ mb_array[1].logicalEnd = 0x100000000UL - holeSizeChunks;
mb_array[1].absStart = holeFirstChunk + holeSizeChunks;
- mb_array[1].absEnd = 0x100000000;
+ mb_array[1].absEnd = 0x100000000UL;
}
return numMemoryBlocks;
}
@@ -230,9 +230,9 @@ static unsigned long iSeries_process_Regatta_mainstore_vpd(
mb_array[i].logicalEnd,
mb_array[i].absStart, mb_array[i].absEnd);
mb_array[i].absStart = addr_to_chunk(mb_array[i].absStart &
- 0x000fffffffffffff);
+ 0x000fffffffffffffUL);
mb_array[i].absEnd = addr_to_chunk(mb_array[i].absEnd &
- 0x000fffffffffffff);
+ 0x000fffffffffffffUL);
mb_array[i].logicalStart =
addr_to_chunk(mb_array[i].logicalStart);
mb_array[i].logicalEnd = addr_to_chunk(mb_array[i].logicalEnd);
@@ -316,7 +316,7 @@ struct mschunks_map mschunks_map = {
};
EXPORT_SYMBOL(mschunks_map);
-void mschunks_alloc(unsigned long num_chunks)
+static void mschunks_alloc(unsigned long num_chunks)
{
klimit = _ALIGN(klimit, sizeof(u32));
mschunks_map.mapping = (u32 *)klimit;
diff --git a/arch/powerpc/platforms/iseries/setup.h b/arch/powerpc/platforms/iseries/setup.h
index 0a47ac5..729754b 100644
--- a/arch/powerpc/platforms/iseries/setup.h
+++ b/arch/powerpc/platforms/iseries/setup.h
@@ -17,6 +17,7 @@
#ifndef __ISERIES_SETUP_H__
#define __ISERIES_SETUP_H__
+extern void *iSeries_early_setup(void);
extern unsigned long iSeries_get_boot_time(void);
extern int iSeries_set_rtc_time(struct rtc_time *tm);
extern void iSeries_get_rtc_time(struct rtc_time *tm);
--
1.5.3.5
^ permalink raw reply related
* [PATCH] [POWERPC] iSeries: declare iSeries_pci_final_fixup in pci.h
From: Stephen Rothwell @ 2007-11-19 6:06 UTC (permalink / raw)
To: paulus; +Cc: ppc-dev
Fixes sparse warning:
arch/powerpc/platforms/iseries/pci.c:169:13: warning: symbol 'iSeries_pci_final_fixup' was not declared. Should it be static?
Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
---
arch/powerpc/platforms/iseries/pci.h | 5 +++++
arch/powerpc/platforms/iseries/setup.c | 6 +-----
2 files changed, 6 insertions(+), 5 deletions(-)
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
diff --git a/arch/powerpc/platforms/iseries/pci.h b/arch/powerpc/platforms/iseries/pci.h
index 33a8489..730986b 100644
--- a/arch/powerpc/platforms/iseries/pci.h
+++ b/arch/powerpc/platforms/iseries/pci.h
@@ -59,5 +59,10 @@ static inline u64 iseries_ds_addr(struct device_node *node)
}
extern void iSeries_Device_Information(struct pci_dev*, int);
+#ifdef CONFIG_PCI
+extern void iSeries_pci_final_fixup(void);
+#else
+static void iSeries_pci_final_fixup(void) { }
+#endif
#endif /* _PLATFORMS_ISERIES_PCI_H */
diff --git a/arch/powerpc/platforms/iseries/setup.c b/arch/powerpc/platforms/iseries/setup.c
index 0877a88..8a652da 100644
--- a/arch/powerpc/platforms/iseries/setup.c
+++ b/arch/powerpc/platforms/iseries/setup.c
@@ -63,6 +63,7 @@
#include "main_store.h"
#include "call_sm.h"
#include "call_hpt.h"
+#include "pci.h"
#ifdef DEBUG
#define DBG(fmt...) udbg_printf(fmt)
@@ -74,11 +75,6 @@
static unsigned long build_iSeries_Memory_Map(void);
static void iseries_shared_idle(void);
static void iseries_dedicated_idle(void);
-#ifdef CONFIG_PCI
-extern void iSeries_pci_final_fixup(void);
-#else
-static void iSeries_pci_final_fixup(void) { }
-#endif
struct MemoryBlock {
--
1.5.3.5
^ permalink raw reply related
* [PATCH] [POWERPC] iSeries: mark two functions __init
From: Stephen Rothwell @ 2007-11-19 6:03 UTC (permalink / raw)
To: paulus; +Cc: ppc-dev
Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
---
arch/powerpc/platforms/iseries/pci.c | 4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
diff --git a/arch/powerpc/platforms/iseries/pci.c b/arch/powerpc/platforms/iseries/pci.c
index da87162..a74d1e1 100644
--- a/arch/powerpc/platforms/iseries/pci.c
+++ b/arch/powerpc/platforms/iseries/pci.c
@@ -87,7 +87,7 @@ static DEFINE_SPINLOCK(iomm_table_lock);
* - CurrentIndex is incremented to keep track of the last entry.
* - Builds the resource entry for allocated BARs.
*/
-static void iomm_table_allocate_entry(struct pci_dev *dev, int bar_num)
+static void __init iomm_table_allocate_entry(struct pci_dev *dev, int bar_num)
{
struct resource *bar_res = &dev->resource[bar_num];
long bar_size = pci_resource_len(dev, bar_num);
@@ -130,7 +130,7 @@ static void iomm_table_allocate_entry(struct pci_dev *dev, int bar_num)
* - Loops through The Bar resources(0 - 5) including the ROM
* is resource(6).
*/
-static void allocate_device_bars(struct pci_dev *dev)
+static void __init allocate_device_bars(struct pci_dev *dev)
{
int bar_num;
--
1.5.3.5
^ permalink raw reply related
* [PATCH] [POWERPC] make global_phb_number static
From: Stephen Rothwell @ 2007-11-19 5:56 UTC (permalink / raw)
To: paulus; +Cc: ppc-dev
Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
---
arch/powerpc/kernel/pci-common.c | 2 +-
include/asm-powerpc/ppc-pci.h | 1 -
2 files changed, 1 insertions(+), 2 deletions(-)
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
diff --git a/arch/powerpc/kernel/pci-common.c b/arch/powerpc/kernel/pci-common.c
index 0d89350..252dd1e 100644
--- a/arch/powerpc/kernel/pci-common.c
+++ b/arch/powerpc/kernel/pci-common.c
@@ -48,7 +48,7 @@
static DEFINE_SPINLOCK(hose_spinlock);
/* XXX kill that some day ... */
-int global_phb_number; /* Global phb counter */
+static int global_phb_number; /* Global phb counter */
/* ISA Memory physical address (or 0 if none) */
resource_size_t isa_mem_base = 0;
diff --git a/include/asm-powerpc/ppc-pci.h b/include/asm-powerpc/ppc-pci.h
index d41645e..854ab71 100644
--- a/include/asm-powerpc/ppc-pci.h
+++ b/include/asm-powerpc/ppc-pci.h
@@ -22,7 +22,6 @@ extern void pci_setup_phb_io_dynamic(struct pci_controller *hose, int primary);
extern struct list_head hose_list;
-extern int global_phb_number;
extern void find_and_init_phbs(void);
--
1.5.3.5
^ permalink raw reply related
* Re: MPC880: i2cer register says tx is done but tx buf descriptor is still ready
From: Ankur Maheshwari @ 2007-11-19 5:52 UTC (permalink / raw)
To: DI BACCO ANTONIO - technolabs; +Cc: linuxppc-embedded
In-Reply-To: <F1F6EC0C8B75034F9E3A79FC85122E8E2649F4@aquib01a>
Hi Antonio,
Check how is your tx_buf is allocated, if its 2.4 kernel , then try
allocating using following function
tx_buf = (u_char *)m8xx_cpm_hostalloc(512);
512 is the size, also dump and check the difference in start address.
I more recommendation, check how your Serial/Network driver has
allocated memory, try using same method.
thanks,
Ankur
DI BACCO ANTONIO - technolabs wrote:
>
> A porting of the driver included in kernel 2.4.
>
> Here is an excerpt of the method to send bytes over the i2c bus:
> ________________________________________________________________________
> i2c->i2c_i2cmr = 0x00; /* Disable I2C interupts */
> i2c->i2c_i2cer = 0xff;
> i2c->i2c_i2mod |= 1; /* Enable */
> i2c->i2c_i2com |= 0x80; /* Begin transmission */
> tmo = jiffies + 1*HZ;
> /* Busy wait, with a timeout */
> while(!(i2c->i2c_i2cer & 0x12 || time_after(jiffies, tmo)));
>
>
> if (signal_pending(current) || !tmo){
> force_close(algo_8xx_data);
> if (!tmo)
> printk("IIC write: timeout!\n");
>
> return -EIO;
> }
>
> if ((tbdf[0]->cbd_sc | tbdf[1]->cbd_sc) & BD_SC_NAK) {
> printk(KERN_INFO "IIC write; no ack\n");
> if (cpm_debug > 0)
> printk("tx0 sc %04x, tx1 sc %04x\n",
> tbdf[0]->cbd_sc,tbdf[1]->cbd_sc);
>
> return 0;
> }
>
> if ((tbdf[0]->cbd_sc | tbdf[1]->cbd_sc) & BD_SC_READY) {
> printk(KERN_INFO "IIC write; complete but tbuf ready\n");
> if (cpm_debug > 0)
> printk("tx0 sc %04x, tx1 sc %04x\n",
> tbdf[0]->cbd_sc,tbdf[1]->cbd_sc);
>
> return 0;
> }
>
>
> -----Original Message-----
> From: Jochen Friedrich [mailto:jochen@scram.de]
> Sent: Sat 17/11/2007 19.32
> To: DI BACCO ANTONIO - technolabs
> Cc: linuxppc-embedded@ozlabs.org
> Subject: Re: MPC880: i2cer register says tx is done but tx buf
> descriptor is still ready
>
> Hi Antonio,
>
> > How could it be possible? It happens during the first i2c transactions
> > and then no more.
> >
>
> What linux version? Which driver?
>
> Thanks,
> Jochen
>
>
> ------------------------------------------------------------------------
>
> _______________________________________________
> Linuxppc-embedded mailing list
> Linuxppc-embedded@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
^ permalink raw reply
* Re: [PATCH v2] [POWERPC] vdso: Fixes for cache block sizes
From: Olof Johansson @ 2007-11-19 4:25 UTC (permalink / raw)
To: Paul Mackerras; +Cc: dwmw2, linuxppc-dev
In-Reply-To: <18241.3066.346441.180033@cargo.ozlabs.ibm.com>
On Mon, Nov 19, 2007 at 03:07:22PM +1100, Paul Mackerras wrote:
> Olof Johansson writes:
>
> > [POWERPC] vdso: Fixes for cache line sizes
> >
> > Current VDSO implementation is hardcoded to 128 byte cache blocks,
> > which are only used on IBM's 64-bit processors.
> >
> > Convert it to get the blocks sizes out of vdso_data instead, similar
> > to how the ppc64 in-kernel cache flush does it.
>
> OK, but you have removed a "crclr cr0*4+so" instruction in a couple of
> places. They are there so that the functions follow the convention
> for system calls, where cr0.SO set on return indicates an error, and
> clear indicates no error. Was there any special reason why you
> removed them? If not, please put them back (after the last cmp or
> dot-form instruction).
Good catch. They must have fallen off when I copied over the in-kernel
versions. I'll repost tomorrow.
Thanks,
-Olof
^ permalink raw reply
* Re: [PATCH v2] [POWERPC] vdso: Fixes for cache block sizes
From: Paul Mackerras @ 2007-11-19 4:07 UTC (permalink / raw)
To: Olof Johansson; +Cc: dwmw2, linuxppc-dev
In-Reply-To: <20071114212823.GA3044@lixom.net>
Olof Johansson writes:
> [POWERPC] vdso: Fixes for cache line sizes
>
> Current VDSO implementation is hardcoded to 128 byte cache blocks,
> which are only used on IBM's 64-bit processors.
>
> Convert it to get the blocks sizes out of vdso_data instead, similar
> to how the ppc64 in-kernel cache flush does it.
OK, but you have removed a "crclr cr0*4+so" instruction in a couple of
places. They are there so that the functions follow the convention
for system calls, where cr0.SO set on return indicates an error, and
clear indicates no error. Was there any special reason why you
removed them? If not, please put them back (after the last cmp or
dot-form instruction).
Paul.
^ permalink raw reply
* Re: [PATCH] 2.6.24-rc2-mm1 powerpc (iseries)- build failure - mm/stab.c
From: Stephen Rothwell @ 2007-11-19 2:38 UTC (permalink / raw)
To: Kamalesh Babulal; +Cc: linuxppc-dev, akpm, anton, paulus, linux-kernel
In-Reply-To: <20071114105410.GA16846@linux.vnet.ibm.com>
[-- Attachment #1: Type: text/plain, Size: 427 bytes --]
Hi Kamalesh,
On Wed, 14 Nov 2007 16:24:10 +0530 Kamalesh Babulal <kamalesh@linux.vnet.ibm.com> wrote:
>
> +#ifdef CONFIG_PPC_ISERIES
> +#include <asm/iseries/hv_call.h>
> +#endif /* CONFIG_PPC_ISERIES */
You should not need the #ifdef and we prefer not to ifdef include unless
necessary. Please resubmit.
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: [PATCH] Fix buglets in mpc5200 FEC code that are corrupting memory.
From: Jon Smirl @ 2007-11-19 1:49 UTC (permalink / raw)
To: Grant Likely; +Cc: PowerPC dev list, Jeff Garzik, Domen Puncer, netdev
In-Reply-To: <fa686aa40711090557u1b6cb29ex388b82efcbad7c18@mail.gmail.com>
On 11/9/07, Grant Likely <grant.likely@secretlab.ca> wrote:
> On 11/9/07, Domen Puncer <domen.puncer@telargo.com> wrote:
> > On 09/11/07 00:31 -0500, Jon Smirl wrote:
> > > This is the reason I couldn't get user space started or connect to my
> > > nfs server. Patch is against current linus git.
> > >
> > > mpc5200 fec driver is corrupting memory. This patch fixes two bugs
> > > where the wrong skb buffer was being referenced.
> > >
> > > Signed-off-by: Jon Smirl <jonsmirl@gmail.com>
> >
> > Acked-by: Domen Puncer <domen.puncer@telargo.com>
>
> Signed-off-by: Grant Likely <grant.likely@secretlab.ca>
>
> Jeff, can you please pick this up for .24?
This is didn't make it into rc3. Without this patch this driver is broken.
>
> Thanks,
> g.
>
> >
> > I can't test it at the moment, but the patch is obviously correct,
> > mapped buffer should be the _same_ as submitted.
> >
> > >
> > > ---
> > >
> > > drivers/net/fec_mpc52xx.c | 4 ++--
> > > 1 files changed, 2 insertions(+), 2 deletions(-)
> > >
> > >
> > > diff --git a/drivers/net/fec_mpc52xx.c b/drivers/net/fec_mpc52xx.c
> > > index a8a0ee2..ddfcc0b 100644
> > > --- a/drivers/net/fec_mpc52xx.c
> > > +++ b/drivers/net/fec_mpc52xx.c
> > > @@ -422,7 +422,7 @@ static irqreturn_t mpc52xx_fec_rx_interrupt(int
> > > irq, void *dev_id)
> > >
> > > rskb =3D bcom_retrieve_buffer(priv->rx_dmatsk, &status,
> > > (struct bcom_bd **)&bd);
> > > - dma_unmap_single(&dev->dev, bd->skb_pa, skb->len, DMA_F=
ROM_DEVICE);
> > > + dma_unmap_single(&dev->dev, bd->skb_pa, rskb->len, DMA_=
FROM_DEVICE);
> > >
> > > /* Test for errors in received frame */
> > > if (status & BCOM_FEC_RX_BD_ERRORS) {
> > > @@ -467,7 +467,7 @@ static irqreturn_t mpc52xx_fec_rx_interrupt(int
> > > irq, void *dev_id)
> > > bcom_prepare_next_buffer(priv->rx_dmatsk);
> > >
> > > bd->status =3D FEC_RX_BUFFER_SIZE;
> > > - bd->skb_pa =3D dma_map_single(&dev->dev, rskb->data,
> > > + bd->skb_pa =3D dma_map_single(&dev->dev, skb->data,
> > > FEC_RX_BUFFER_SIZE, DMA_FROM_DEVICE);
> > >
> > > bcom_submit_next_buffer(priv->rx_dmatsk, skb);
> > >
> > >
> > > --
> > > Jon Smirl
> > > jonsmirl@gmail.com
> >
> > --
> > Domen Puncer | Research & Development
> > .......................................................................=
......................
> > Telargo d.o.o. | Zagreb=9Aka cesta 20 | 2000 Maribor | Slovenia
> > .......................................................................=
......................
> > www.telargo.com
> >
>
>
> --
> Grant Likely, B.Sc., P.Eng.
> Secret Lab Technologies Ltd.
> grant.likely@secretlab.ca
> (403) 399-0195
>
--=20
Jon Smirl
jonsmirl@gmail.com
^ permalink raw reply
* Re: Revisited, audio codec device tree entries.
From: Jon Smirl @ 2007-11-19 0:22 UTC (permalink / raw)
To: Matt Sealey, PowerPC dev list
In-Reply-To: <20071119001209.GD20794@localhost.localdomain>
On 11/18/07, David Gibson <david@gibson.dropbear.id.au> wrote:
> On Sun, Nov 18, 2007 at 11:31:13PM +0000, Matt Sealey wrote:
> > Matt Sealey wrote:
> > > Jon Smirl wrote:
> > >
> > > If you require the codec to be subservient to some "fabric" then I
> > > suggest you make a "sound" node with a compatible entry which is
> > > defined as something specific to your board (digispeaker,audio) and
> > > let your driver pick that up and then switch on the model (rather like
> > > Apple's layout-id) of that device to pick out the specifics of that
> > > fabric. If it needs an audio codec (ac97 or i2s) and a control
> > > interface (i2c or spi) then it knows which ones it is looking for
> > > based on the model.
> >
> > Sigh, I suck, I forgot the example :D
> >
> > And I forgot the rant you guys usually get - for god's sake, why isn't
> > anyone using the "model" property? Do I have to whine about this some
> > more to get your attention, guys? name, device_type, compatible and
> > model are your tools for building device trees and detecting
> > things. That's FOUR unique properties.
> >
> > How come I only see device trees defined using "name", with the same
> > device_type, and "compatible"? This is braindead design.
>
> Gah! For the benefit of others on this list who may be misled.
>
> *Neither* of you correctly understands the device tree, what I've seen
> of *both* your suggested approaches is crap.
I'm awaiting guidance on how to do the device tree. I just want to
figure out some way of getting my drivers loaded. I make no claim to
having any expertise in device tree design.
There are two classes of codecs, ones where control/data is combined
and one where they are separate. Common examples - combined: ac97, hda
- separate i2s + i2c. Then there is this fabric stuff which glues a
generic codec driver into a specific board layout. While a generic
AC97 design may not need a fabric driver, most other designs need it.
If someone were to put an example into the Docmentation file, I'd follow it.
>
> The device tree describes the _hardware_. If you start reasoning
> about how to lay out the device tree based on your driver model,
> you're already wrong.
>
> Matt, the various properties you list do not mean what you think they
> mean.
>
> name - should be named according to the generic names convention.
> It's pretty much arbitrary, meant for human readability of the device
> tree. Drivers should not depend on it (some do, historically, but new
> drivers and trees should not).
>
> device_type - indicates the open firmware method interface for the
> device. Therefore, meaningless in flattened trees. No new driver
> should use this.
>
> compatible - *this* is the one for driver selection. It describes the
> hardware level interface(s) of the device.
>
> model - usually just for debugging / diagnosis / human-readable
> purposes, describes exact model / revision of the hardware. It can be
> used to enable driver quirks / workarounds for when various devices
> are supposed to be compatible (as encoded in 'compatible') but
> aren't, due to hardware bugs. However, you should never aim to use it
> this way in design.
>
> --
> David Gibson | I'll have my music baroque, and my code
> david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_
> | _way_ _around_!
> http://www.ozlabs.org/~dgibson
>
--
Jon Smirl
jonsmirl@gmail.com
^ permalink raw reply
* Re: Revisited, audio codec device tree entries.
From: David Gibson @ 2007-11-19 0:12 UTC (permalink / raw)
To: Matt Sealey; +Cc: PowerPC dev list
In-Reply-To: <4740CB41.8030101@genesi-usa.com>
On Sun, Nov 18, 2007 at 11:31:13PM +0000, Matt Sealey wrote:
> Matt Sealey wrote:
> > Jon Smirl wrote:
> >
> > If you require the codec to be subservient to some "fabric" then I
> > suggest you make a "sound" node with a compatible entry which is
> > defined as something specific to your board (digispeaker,audio) and
> > let your driver pick that up and then switch on the model (rather like
> > Apple's layout-id) of that device to pick out the specifics of that
> > fabric. If it needs an audio codec (ac97 or i2s) and a control
> > interface (i2c or spi) then it knows which ones it is looking for
> > based on the model.
>
> Sigh, I suck, I forgot the example :D
>
> And I forgot the rant you guys usually get - for god's sake, why isn't
> anyone using the "model" property? Do I have to whine about this some
> more to get your attention, guys? name, device_type, compatible and
> model are your tools for building device trees and detecting
> things. That's FOUR unique properties.
>
> How come I only see device trees defined using "name", with the same
> device_type, and "compatible"? This is braindead design.
Gah! For the benefit of others on this list who may be misled.
*Neither* of you correctly understands the device tree, what I've seen
of *both* your suggested approaches is crap.
The device tree describes the _hardware_. If you start reasoning
about how to lay out the device tree based on your driver model,
you're already wrong.
Matt, the various properties you list do not mean what you think they
mean.
name - should be named according to the generic names convention.
It's pretty much arbitrary, meant for human readability of the device
tree. Drivers should not depend on it (some do, historically, but new
drivers and trees should not).
device_type - indicates the open firmware method interface for the
device. Therefore, meaningless in flattened trees. No new driver
should use this.
compatible - *this* is the one for driver selection. It describes the
hardware level interface(s) of the device.
model - usually just for debugging / diagnosis / human-readable
purposes, describes exact model / revision of the hardware. It can be
used to enable driver quirks / workarounds for when various devices
are supposed to be compatible (as encoded in 'compatible') but
aren't, due to hardware bugs. However, you should never aim to use it
this way in design.
--
David Gibson | I'll have my music baroque, and my code
david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson
^ permalink raw reply
* Re: Revisited, audio codec device tree entries.
From: Jon Smirl @ 2007-11-18 23:47 UTC (permalink / raw)
To: Matt Sealey; +Cc: PowerPC dev list
In-Reply-To: <4740CB41.8030101@genesi-usa.com>
On 11/18/07, Matt Sealey <matt@genesi-usa.com> wrote:
> I'd suggest something like this:
>
> sound@0 {
> \\ this is our magic audio fabric
> device_type = "digispeaker,flinger";
>
> \\ it's actually just an i2s pcm codec
> compatible = "mpc5200-psc-i2s";
>
> \\ and this defines the layout Jon picked for the DACs
> \\ just like Apple's layout-id value
> model = "flinger,2"
>
> codec@15 {
> compatible = "TXN,tas5504";
> codec-control = <&codec-control>;
> }
>
> \\ and every i2s driver on the planet will just ignore these
> \\ unless it's one of our boards
> digispeaker,amp-control = <&-control>
> }
This forces a single fabric driver for audio buses that can support
more than one device (like ac97). I can live with that, but is it ok
for the design?
> Then you control the fabric for your boards and get to attach
> whatever the hell you want to those codecs, control interfaces
> and special little tweak features you always wanted.
>
> Be careful cross-referencing devices with each other,
> for instance in your example you made the i2c codec device
> point back to an i2s handle - it's a good idea, but not well
> executed in my opinion as it lacks context.
>
> Isn't the primary concern of an audio codec, to play audio?
>
> Therefore, shouldn't the audio codec point back to it's control
> interface? Also, why give the name as 'i2s-handle'? Surely it
> could be any interface. In reverse, it would be, perhaps, as
> above, i2c-handle, but then what if you change the interface
> type (for instance a bunch of Wolfson codecs can do i2c and
> spi for control). Your property name is obselete, then and
> drivers will need to switch on property names to find out
> which control interface is present.
Others have pointed out that device trees are organized by control
interface. So the codec node should be under i2c and back point to
their data stream. We could use something like codec-data instead of
i2s-handle.
I don't have a strong opinion on how to organize this stuff. I just
need some way to get the ASOC fabric drivers loaded. Actually ASOC
calls them 'machine' drivers, it is Apple's audio code that call them
fabric drivers.
>
> What they should really do, is be told where their control
> interface handle is, then you can look at that handle and
> the device it contains - that device itself will tell you the
> bus type, any devices under it, and any quirky things you
> need to do besides (above, &codec-control etc. would point to
>
> i2c@3d40 {
> codec-control@15 {
> blah
> }
> }
>
> spi@beef {
> codec-control@19 {
> blah
> }
> }
>
> gpio@cafe {
> amp-control@0 {
> compatible = "gpio-bit";
> bit = "1";
> open-drain;
> }
> }
>
> If you couldn't tell it's a device on an i2c bus then you
> are coding your driver badly. And you can have lots of
> codecs, and just back reference which control interface
> they have. I dunno.
>
> Remember, it doesn't matter what NAME you give it, the name
> is for people to read, device_type is what you search for,
> and phandles let you attach specific devices to each other.
> compatible is for when you want to tell people "it acts the
> same as this" and model is to give you the enviable ability
> to define PRECISELY what you are looking at beyond a chip
> name. I'd suggest we use all of them for great justice.
>
> --
> Matt Sealey <matt@genesi-usa.com>
> Genesi, Manager, Developer Relations
>
--
Jon Smirl
jonsmirl@gmail.com
^ permalink raw reply
* Re: Revisited, audio codec device tree entries.
From: Matt Sealey @ 2007-11-18 23:31 UTC (permalink / raw)
To: Jon Smirl; +Cc: PowerPC dev list
In-Reply-To: <4740C0E3.5080704@genesi-usa.com>
Matt Sealey wrote:
> Jon Smirl wrote:
>
> If you require the codec to be subservient to some "fabric" then I
> suggest you make a "sound" node with a compatible entry which is
> defined as something specific to your board (digispeaker,audio) and
> let your driver pick that up and then switch on the model (rather like
> Apple's layout-id) of that device to pick out the specifics of that
> fabric. If it needs an audio codec (ac97 or i2s) and a control
> interface (i2c or spi) then it knows which ones it is looking for
> based on the model.
Sigh, I suck, I forgot the example :D
And I forgot the rant you guys usually get - for god's sake, why isn't
anyone using the "model" property? Do I have to whine about this some
more to get your attention, guys? name, device_type, compatible and
model are your tools for building device trees and detecting
things. That's FOUR unique properties.
How come I only see device trees defined using "name", with the same
device_type, and "compatible"? This is braindead design.
Why is every example device tree I see defining weird little extra
nodes for anything and everything that some driver API exposes? If
you want to expose a grand new kind of driver fabric like ALSA SoC
wants, put your codec in the tree, and give it a model property
with your unique name.
I'd suggest something like this:
sound@0 {
\\ this is our magic audio fabric
device_type = "digispeaker,flinger";
\\ it's actually just an i2s pcm codec
compatible = "mpc5200-psc-i2s";
\\ and this defines the layout Jon picked for the DACs
\\ just like Apple's layout-id value
model = "flinger,2"
codec@15 {
compatible = "TXN,tas5504";
codec-control = <&codec-control>;
}
\\ and every i2s driver on the planet will just ignore these
\\ unless it's one of our boards
digispeaker,amp-control = <&-control>
}
Then you control the fabric for your boards and get to attach
whatever the hell you want to those codecs, control interfaces
and special little tweak features you always wanted.
Be careful cross-referencing devices with each other,
for instance in your example you made the i2c codec device
point back to an i2s handle - it's a good idea, but not well
executed in my opinion as it lacks context.
Isn't the primary concern of an audio codec, to play audio?
Therefore, shouldn't the audio codec point back to it's control
interface? Also, why give the name as 'i2s-handle'? Surely it
could be any interface. In reverse, it would be, perhaps, as
above, i2c-handle, but then what if you change the interface
type (for instance a bunch of Wolfson codecs can do i2c and
spi for control). Your property name is obselete, then and
drivers will need to switch on property names to find out
which control interface is present.
What they should really do, is be told where their control
interface handle is, then you can look at that handle and
the device it contains - that device itself will tell you the
bus type, any devices under it, and any quirky things you
need to do besides (above, &codec-control etc. would point to
i2c@3d40 {
codec-control@15 {
blah
}
}
spi@beef {
codec-control@19 {
blah
}
}
gpio@cafe {
amp-control@0 {
compatible = "gpio-bit";
bit = "1";
open-drain;
}
}
If you couldn't tell it's a device on an i2c bus then you
are coding your driver badly. And you can have lots of
codecs, and just back reference which control interface
they have. I dunno.
Remember, it doesn't matter what NAME you give it, the name
is for people to read, device_type is what you search for,
and phandles let you attach specific devices to each other.
compatible is for when you want to tell people "it acts the
same as this" and model is to give you the enviable ability
to define PRECISELY what you are looking at beyond a chip
name. I'd suggest we use all of them for great justice.
--
Matt Sealey <matt@genesi-usa.com>
Genesi, Manager, Developer Relations
^ 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