LinuxPPC-Dev Archive on lore.kernel.org
 help / color / mirror / Atom feed
* dtc: Make -I dtb mode use fill_fullpaths()
From: David Gibson @ 2008-02-29  5:51 UTC (permalink / raw)
  To: Jon Loeliger; +Cc: linuxppc-dev

At present -I dts and -I fs modes both use the fill_fullpaths() helper
function to fill in the fullpath and basenamelen fields of struct
node, which are useful in later parts of the code.  -I dtb mode,
however, fills these in itself.

This patch simplifies flattree.c by making -I dtb mode use
fill_fullpaths() like the others.

Signed-off-by: David Gibson <david@gibson.dropbear.id.au>

Index: dtc/flattree.c
===================================================================
--- dtc.orig/flattree.c	2008-02-29 13:38:15.000000000 +1100
+++ dtc/flattree.c	2008-02-29 16:46:02.000000000 +1100
@@ -704,59 +704,37 @@ static struct reserve_info *flat_read_me
 
 static char *nodename_from_path(const char *ppath, const char *cpath)
 {
-	const char *lslash;
 	int plen;
 
-	lslash = strrchr(cpath, '/');
-	if (! lslash)
-		return NULL;
+	plen = strlen(ppath);
 
-	plen = lslash - cpath;
+	if (!strneq(ppath, cpath, plen))
+		die("Path \"%s\" is not valid as a child of \"%s\"\n",
+		    cpath, ppath);
 
-	if (streq(cpath, "/") && streq(ppath, ""))
-		return "";
+	/* root node is a special case */
+	if (!streq(ppath, "/"))
+		plen++;
 
-	if ((plen == 0) && streq(ppath, "/"))
-		return strdup(lslash+1);
-
-	if (! strneq(ppath, cpath, plen))
-		return NULL;
-
-	return strdup(lslash+1);
-}
-
-static int find_basenamelen(const char *name)
-{
-	const char *atpos = strchr(name, '@');
-
-	if (atpos)
-		return atpos - name;
-	else
-		return strlen(name);
+	return strdup(cpath + plen);
 }
 
 static struct node *unflatten_tree(struct inbuf *dtbuf,
 				   struct inbuf *strbuf,
-				   const char *parent_path, int flags)
+				   const char *parent_flatname, int flags)
 {
 	struct node *node;
+	char *flatname;
 	u32 val;
 
 	node = build_node(NULL, NULL);
 
-	if (flags & FTF_FULLPATH) {
-		node->fullpath = flat_read_string(dtbuf);
-		node->name = nodename_from_path(parent_path, node->fullpath);
-
-		if (! node->name)
-			die("Path \"%s\" is not valid as a child of \"%s\"\n",
-			    node->fullpath, parent_path);
-	} else {
-		node->name = flat_read_string(dtbuf);
-		node->fullpath = join_path(parent_path, node->name);
-	}
+	flatname = flat_read_string(dtbuf);
 
-	node->basenamelen = find_basenamelen(node->name);
+	if (flags & FTF_FULLPATH)
+		node->name = nodename_from_path(parent_flatname, flatname);
+	else
+		node->name = flatname;
 
 	do {
 		struct property *prop;
@@ -773,8 +751,7 @@ static struct node *unflatten_tree(struc
 			break;
 
 		case FDT_BEGIN_NODE:
-			child = unflatten_tree(dtbuf,strbuf, node->fullpath,
-					       flags);
+			child = unflatten_tree(dtbuf,strbuf, flatname, flags);
 			add_child(node, child);
 			break;
 
Index: dtc/dtc.c
===================================================================
--- dtc.orig/dtc.c	2008-02-28 12:55:04.000000000 +1100
+++ dtc/dtc.c	2008-02-29 16:16:07.000000000 +1100
@@ -55,7 +55,7 @@ char *join_path(const char *path, const 
 	return str;
 }
 
-void fill_fullpaths(struct node *tree, const char *prefix)
+static void fill_fullpaths(struct node *tree, const char *prefix)
 {
 	struct node *child;
 	const char *unit;
@@ -208,6 +208,7 @@ int main(int argc, char *argv[])
 	if (! bi || ! bi->dt || bi->error)
 		die("Couldn't read input tree\n");
 
+	fill_fullpaths(bi->dt, "");
 	process_checks(force, bi);
 
 	if (streq(outname, "-")) {
Index: dtc/dtc.h
===================================================================
--- dtc.orig/dtc.h	2008-02-28 17:02:38.000000000 +1100
+++ dtc/dtc.h	2008-02-29 16:16:07.000000000 +1100
@@ -264,6 +264,5 @@ struct boot_info *dt_from_fs(const char 
 /* misc */
 
 char *join_path(const char *path, const char *name);
-void fill_fullpaths(struct node *tree, const char *prefix);
 
 #endif /* _DTC_H */
Index: dtc/fstree.c
===================================================================
--- dtc.orig/fstree.c	2008-02-28 12:55:04.000000000 +1100
+++ dtc/fstree.c	2008-02-29 16:16:07.000000000 +1100
@@ -87,8 +87,6 @@ struct boot_info *dt_from_fs(const char 
 	tree = read_fstree(dirname);
 	tree = name_node(tree, "", NULL);
 
-	fill_fullpaths(tree, "");
-
 	return build_boot_info(NULL, tree);
 }
 
Index: dtc/treesource.c
===================================================================
--- dtc.orig/treesource.c	2008-02-28 17:02:36.000000000 +1100
+++ dtc/treesource.c	2008-02-29 16:16:07.000000000 +1100
@@ -37,8 +37,6 @@ struct boot_info *dt_from_source(const c
 	if (yyparse() != 0)
 		return NULL;
 
-	fill_fullpaths(the_boot_info->dt, "");
-
 	the_boot_info->error = treesource_error;
 	return the_boot_info;
 }

-- 
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: [PATCH 1/2] firewire: endianess fix
From: Benjamin Herrenschmidt @ 2008-02-29  6:00 UTC (permalink / raw)
  To: Jarod Wilson
  Cc: Kristian Hoegsberg, linux-kernel, linuxppc-dev, Stefan Richter,
	sparclinux, linux1394-devel, Sam Ravnborg, Harvey Harrison
In-Reply-To: <47C79CB1.6050104@redhat.com>


> Still no luck finding one here. The person I was thinking of has a 
> Lombard, which has no firewire. I did get ahold of a 667MHz Titanium, 
> but its got an Agere FW323. Pretty sure my old man actually has a Pismo, 
> but its about a 3000 mile drive over to my folks house. The search 
> continues... I wonder how many people still actually 1) have a machine 
> with this controller, 2) are running Linux on it and 3) use firewire 
> devices with it. Both of you, please speak up, we're trying to help you! 
> (if only out of morbid curiosity to see this mythical goofy controller).

First gen titanium (400/500 Mhz models) might... Paulus has one at home
I think, I'll chase that up here.

Cheers,
Ben.

^ permalink raw reply

* Re: [Cbe-oss-dev] Please pull 'for-2.6.25' branch of cell tree
From: Michael Ellerman @ 2008-02-29  6:13 UTC (permalink / raw)
  To: Arnd Bergmann; +Cc: linuxppc-dev, paulus, cbe-oss-dev
In-Reply-To: <200802290612.56728.arnd@arndb.de>

[-- Attachment #1: Type: text/plain, Size: 885 bytes --]

On Fri, 2008-02-29 at 06:12 +0100, Arnd Bergmann wrote:
> Hi Paul,
> 
> Please pull from:
> 
>  master.kernel.org:/pub/scm/linux/kernel/git/arnd/cell-2.6.git for-2.6.25
> 
> To pick up a few small fixes for the cell platform. Most of it is a follow-up
> to the IOMMU rework that got merged in 2.6.25-rc1 and caused problems on
> machines with large amounts of memory.

Sorry, I have updated versions of the IOMMU patches to send. Arnd is
away for the weekend, so Paul if you just want to cherry pick the other
fixes that might work. I'll send the updated IOMMU patches momentarily.

Apologies for the churn.

cheers

-- 
Michael Ellerman
OzLabs, IBM Australia Development Lab

wwweb: http://michael.ellerman.id.au
phone: +61 2 6212 1183 (tie line 70 21183)

We do not inherit the earth from our ancestors,
we borrow it from our children. - S.M.A.R.T Person

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

^ permalink raw reply

* Re: undefined references to __udivdi3 on powerpc
From: Adrian Bunk @ 2008-02-29  6:56 UTC (permalink / raw)
  To: Olaf Hering; +Cc: linuxppc-dev, linux-kernel
In-Reply-To: <20080228133718.GA8383@aepfle.de>

On Thu, Feb 28, 2008 at 02:37:18PM +0100, Olaf Hering wrote:
> 
> While debugging __divdi3 calls in drivers/crypto/hifn_795x.c (due to the
> ndelay() delay call with a s64), I found even more breakage of that
> sort. This is after a allnoconfig with ARCH=powerpc in 2.6.25-rc3,
> plus CONFIG_MODULES=y and CONFIG_CRYPTO_DEV_HIFN_795X=y:
> 
>   LD      .tmp_vmlinux1
>   kernel/built-in.o: In function `update_xtime_cache':
>   (.text+0x221a0): undefined reference to `__umoddi3'
>   kernel/built-in.o: In function `update_xtime_cache':
>   (.text+0x221c0): undefined reference to `__udivdi3'
>   kernel/built-in.o: In function `getnstimeofday':
>   (.text+0x22330): undefined reference to `__umoddi3'
>   kernel/built-in.o: In function `getnstimeofday':
>   (.text+0x22350): undefined reference to `__udivdi3'
>   kernel/built-in.o: In function `timekeeping_resume':
>   timekeeping.c:(.text+0x226a0): undefined reference to `__udivdi3'
>   timekeeping.c:(.text+0x22778): undefined reference to `__umoddi3'
>   timekeeping.c:(.text+0x22798): undefined reference to `__udivdi3'
>   kernel/built-in.o: In function `update_wall_time':
>   (.text+0x22c7c): undefined reference to `__umoddi3'
>   kernel/built-in.o: In function `update_wall_time':
>   (.text+0x22c9c): undefined reference to `__udivdi3'
>   kernel/built-in.o: In function `update_wall_time':
>   (.text+0x230f8): undefined reference to `__umoddi3'
>   kernel/built-in.o: In function `update_wall_time':
>   (.text+0x23118): undefined reference to `__udivdi3'
>   kernel/built-in.o: In function `do_settimeofday':
>   (.text+0x23520): undefined reference to `__udivdi3'
>   kernel/built-in.o: In function `timekeeping_init':
>   (.init.text+0x1870): undefined reference to `__udivdi3'
>   make[1]: *** [.tmp_vmlinux1] Error 1
> 
> But its not a regression, 2.6.24 allnoconfig does not link either on
> powerpc32. 
>...

You didn't mention your gcc version, but you should only get these 
errors when using the not yet released gcc 4.3.

And this issue is known for at about half a year.

> Olaf

cu
Adrian

-- 

       "Is there not promise of rain?" Ling Tan asked suddenly out
        of the darkness. There had been need of rain for many days.
       "Only a promise," Lao Er said.
                                       Pearl S. Buck - Dragon Seed

^ permalink raw reply

* [PATCH 1/8] Clearup cell IOMMU fixed mapping terminology
From: Michael Ellerman @ 2008-02-29  7:33 UTC (permalink / raw)
  To: linuxppc-dev

It's called the fixed mapping, not the static mapping.

Signed-off-by: Michael Ellerman <michael@ellerman.id.au>
---
 arch/powerpc/platforms/cell/iommu.c |    8 ++++----
 1 files changed, 4 insertions(+), 4 deletions(-)

diff --git a/arch/powerpc/platforms/cell/iommu.c b/arch/powerpc/platforms/cell/iommu.c
index edab631..bbe8389 100644
--- a/arch/powerpc/platforms/cell/iommu.c
+++ b/arch/powerpc/platforms/cell/iommu.c
@@ -549,7 +549,7 @@ static void cell_dma_dev_setup_iommu(struct device *dev)
 	archdata->dma_data = &window->table;
 }
 
-static void cell_dma_dev_setup_static(struct device *dev);
+static void cell_dma_dev_setup_fixed(struct device *dev);
 
 static void cell_dma_dev_setup(struct device *dev)
 {
@@ -557,7 +557,7 @@ static void cell_dma_dev_setup(struct device *dev)
 
 	/* Order is important here, these are not mutually exclusive */
 	if (get_dma_ops(dev) == &dma_iommu_fixed_ops)
-		cell_dma_dev_setup_static(dev);
+		cell_dma_dev_setup_fixed(dev);
 	else if (get_pci_dma_ops() == &dma_iommu_ops)
 		cell_dma_dev_setup_iommu(dev);
 	else if (get_pci_dma_ops() == &dma_direct_ops)
@@ -858,7 +858,7 @@ static int dma_set_mask_and_switch(struct device *dev, u64 dma_mask)
 	return 0;
 }
 
-static void cell_dma_dev_setup_static(struct device *dev)
+static void cell_dma_dev_setup_fixed(struct device *dev)
 {
 	struct dev_archdata *archdata = &dev->archdata;
 	u64 addr;
@@ -894,7 +894,7 @@ static void cell_iommu_setup_fixed_ptab(struct cbe_iommu *iommu,
 	for (i = fbase; i < fbase + fsize; i++, uaddr += IOMMU_PAGE_SIZE) {
 		/* Don't touch the dynamic region */
 		if (i >= dbase && i < (dbase + dsize)) {
-			pr_debug("iommu: static/dynamic overlap, skipping\n");
+			pr_debug("iommu: fixed/dynamic overlap, skipping\n");
 			continue;
 		}
 		io_pte[i] = base_pte | (__pa(uaddr) & IOPTE_RPN_Mask);
-- 
1.5.2.rc1.1884.g59b20

^ permalink raw reply related

* [PATCH 2/8] Use it_offset not pte_offset in cell IOMMU code
From: Michael Ellerman @ 2008-02-29  7:33 UTC (permalink / raw)
  To: linuxppc-dev
In-Reply-To: <fdd3edc0f2f3d2d6cade5cd695b8080d0da95a7f.1204270367.git.michael@ellerman.id.au>

The cell IOMMU tce build and free routines use pte_offset to convert
the index passed from the generic IOMMU code into a page table offset.

This takes into account the SPIDER_DMA_OFFSET which sets the top bit
of every DMA address.

However it doesn't cater for the IOMMU window starting at a non-zero
address, as the base of the window is not incorporated into pte_offset
at all.

As it turns out tbl->it_offset already contains the value we need, it
takes into account the base of the window and also pte_offset. So use
it instead!

Signed-off-by: Michael Ellerman <michael@ellerman.id.au>
---
 arch/powerpc/platforms/cell/iommu.c |    4 ++--
 1 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/arch/powerpc/platforms/cell/iommu.c b/arch/powerpc/platforms/cell/iommu.c
index bbe8389..4e75919 100644
--- a/arch/powerpc/platforms/cell/iommu.c
+++ b/arch/powerpc/platforms/cell/iommu.c
@@ -200,7 +200,7 @@ static void tce_build_cell(struct iommu_table *tbl, long index, long npages,
 		(window->ioid & IOPTE_IOID_Mask);
 #endif
 
-	io_pte = (unsigned long *)tbl->it_base + (index - window->pte_offset);
+	io_pte = (unsigned long *)tbl->it_base + (index - tbl->it_offset);
 
 	for (i = 0; i < npages; i++, uaddr += IOMMU_PAGE_SIZE)
 		io_pte[i] = base_pte | (__pa(uaddr) & IOPTE_RPN_Mask);
@@ -232,7 +232,7 @@ static void tce_free_cell(struct iommu_table *tbl, long index, long npages)
 		| (window->ioid & IOPTE_IOID_Mask);
 #endif
 
-	io_pte = (unsigned long *)tbl->it_base + (index - window->pte_offset);
+	io_pte = (unsigned long *)tbl->it_base + (index - tbl->it_offset);
 
 	for (i = 0; i < npages; i++)
 		io_pte[i] = pte;
-- 
1.5.2.rc1.1884.g59b20

^ permalink raw reply related

* [PATCH 3/8] Remove unused pte_offset variable
From: Michael Ellerman @ 2008-02-29  7:33 UTC (permalink / raw)
  To: linuxppc-dev
In-Reply-To: <fdd3edc0f2f3d2d6cade5cd695b8080d0da95a7f.1204270367.git.michael@ellerman.id.au>

The cell IOMMU code no longer needs to save the pte_offset variable
separately, it is incorporated into tbl->it_offset.

Signed-off-by: Michael Ellerman <michael@ellerman.id.au>
---
 arch/powerpc/platforms/cell/iommu.c |    5 +----
 1 files changed, 1 insertions(+), 4 deletions(-)

diff --git a/arch/powerpc/platforms/cell/iommu.c b/arch/powerpc/platforms/cell/iommu.c
index 4e75919..555d264 100644
--- a/arch/powerpc/platforms/cell/iommu.c
+++ b/arch/powerpc/platforms/cell/iommu.c
@@ -123,7 +123,6 @@ struct iommu_window {
 	struct cbe_iommu *iommu;
 	unsigned long offset;
 	unsigned long size;
-	unsigned long pte_offset;
 	unsigned int ioid;
 	struct iommu_table table;
 };
@@ -475,13 +474,11 @@ cell_iommu_setup_window(struct cbe_iommu *iommu, struct device_node *np,
 	window->size = size;
 	window->ioid = ioid;
 	window->iommu = iommu;
-	window->pte_offset = pte_offset;
 
 	window->table.it_blocksize = 16;
 	window->table.it_base = (unsigned long)iommu->ptab;
 	window->table.it_index = iommu->nid;
-	window->table.it_offset = (offset >> IOMMU_PAGE_SHIFT) +
-		window->pte_offset;
+	window->table.it_offset = (offset >> IOMMU_PAGE_SHIFT) + pte_offset;
 	window->table.it_size = size >> IOMMU_PAGE_SHIFT;
 
 	iommu_init_table(&window->table, iommu->nid);
-- 
1.5.2.rc1.1884.g59b20

^ permalink raw reply related

* [PATCH 4/8] Move allocation of cell IOMMU pad page
From: Michael Ellerman @ 2008-02-29  7:33 UTC (permalink / raw)
  To: linuxppc-dev
In-Reply-To: <fdd3edc0f2f3d2d6cade5cd695b8080d0da95a7f.1204270367.git.michael@ellerman.id.au>

There's no need to allocate the pad page unless we're going to actually
use it - so move the allocation to where we know we're going to use it.

Signed-off-by: Michael Ellerman <michael@ellerman.id.au>
---
 arch/powerpc/platforms/cell/iommu.c |   12 ++++++------
 1 files changed, 6 insertions(+), 6 deletions(-)

diff --git a/arch/powerpc/platforms/cell/iommu.c b/arch/powerpc/platforms/cell/iommu.c
index 555d264..8e57e1a 100644
--- a/arch/powerpc/platforms/cell/iommu.c
+++ b/arch/powerpc/platforms/cell/iommu.c
@@ -344,12 +344,6 @@ static void cell_iommu_setup_page_tables(struct cbe_iommu *iommu,
 	iommu->ptab = page_address(page);
 	memset(iommu->ptab, 0, ptab_size);
 
-	/* allocate a bogus page for the end of each mapping */
-	page = alloc_pages_node(iommu->nid, GFP_KERNEL, 0);
-	BUG_ON(!page);
-	iommu->pad_page = page_address(page);
-	clear_page(iommu->pad_page);
-
 	/* number of pages needed for a page table */
 	n_pte_pages = (pages_per_segment *
 		       sizeof(unsigned long)) >> IOMMU_PAGE_SHIFT;
@@ -463,6 +457,7 @@ cell_iommu_setup_window(struct cbe_iommu *iommu, struct device_node *np,
 			unsigned long pte_offset)
 {
 	struct iommu_window *window;
+	struct page *page;
 	u32 ioid;
 
 	ioid = cell_iommu_get_ioid(np);
@@ -501,6 +496,11 @@ cell_iommu_setup_window(struct cbe_iommu *iommu, struct device_node *np,
 	 * This code also assumes that we have a window that starts at 0,
 	 * which is the case on all spider based blades.
 	 */
+	page = alloc_pages_node(iommu->nid, GFP_KERNEL, 0);
+	BUG_ON(!page);
+	iommu->pad_page = page_address(page);
+	clear_page(iommu->pad_page);
+
 	__set_bit(0, window->table.it_map);
 	tce_build_cell(&window->table, window->table.it_offset, 1,
 		       (unsigned long)iommu->pad_page, DMA_TO_DEVICE);
-- 
1.5.2.rc1.1884.g59b20

^ permalink raw reply related

* [PATCH 5/8] Split setup of IOMMU stab and ptab, allocate dynamic/fixed ptabs separately
From: Michael Ellerman @ 2008-02-29  7:33 UTC (permalink / raw)
  To: linuxppc-dev
In-Reply-To: <fdd3edc0f2f3d2d6cade5cd695b8080d0da95a7f.1204270367.git.michael@ellerman.id.au>

Currently the cell IOMMU code allocates the entire IOMMU page table in a
contiguous chunk. This is nice and tidy, but for machines with larger
amounts of RAM the page table allocation can fail due to it simply being
too large.

So split the segment table and page table setup routine, and arrange to
have the dynamic and fixed page tables allocated separately.

Signed-off-by: Michael Ellerman <michael@ellerman.id.au>
---
 arch/powerpc/platforms/cell/iommu.c |   69 ++++++++++++++++++++++-------------
 1 files changed, 43 insertions(+), 26 deletions(-)

diff --git a/arch/powerpc/platforms/cell/iommu.c b/arch/powerpc/platforms/cell/iommu.c
index 8e57e1a..187a723 100644
--- a/arch/powerpc/platforms/cell/iommu.c
+++ b/arch/powerpc/platforms/cell/iommu.c
@@ -306,50 +306,54 @@ static int cell_iommu_find_ioc(int nid, unsigned long *base)
 	return -ENODEV;
 }
 
-static void cell_iommu_setup_page_tables(struct cbe_iommu *iommu,
+static void cell_iommu_setup_stab(struct cbe_iommu *iommu,
 				unsigned long dbase, unsigned long dsize,
 				unsigned long fbase, unsigned long fsize)
 {
 	struct page *page;
-	int i;
-	unsigned long reg, segments, pages_per_segment, ptab_size, stab_size,
-		      n_pte_pages, base;
-
-	base = dbase;
-	if (fsize != 0)
-		base = min(fbase, dbase);
+	unsigned long segments, stab_size;
 
 	segments = max(dbase + dsize, fbase + fsize) >> IO_SEGMENT_SHIFT;
-	pages_per_segment = 1ull << IO_PAGENO_BITS;
 
-	pr_debug("%s: iommu[%d]: segments: %lu, pages per segment: %lu\n",
-			__FUNCTION__, iommu->nid, segments, pages_per_segment);
+	pr_debug("%s: iommu[%d]: segments: %lu\n",
+			__FUNCTION__, iommu->nid, segments);
 
 	/* set up the segment table */
 	stab_size = segments * sizeof(unsigned long);
 	page = alloc_pages_node(iommu->nid, GFP_KERNEL, get_order(stab_size));
 	BUG_ON(!page);
 	iommu->stab = page_address(page);
-	clear_page(iommu->stab);
+	memset(iommu->stab, 0, stab_size);
+}
+
+static unsigned long *cell_iommu_alloc_ptab(struct cbe_iommu *iommu,
+		unsigned long base, unsigned long size, unsigned long gap_base,
+		unsigned long gap_size)
+{
+	struct page *page;
+	int i;
+	unsigned long reg, segments, pages_per_segment, ptab_size,
+		      n_pte_pages, start_seg, *ptab;
+
+	start_seg = base >> IO_SEGMENT_SHIFT;
+	segments  = size >> IO_SEGMENT_SHIFT;
+	pages_per_segment = 1ull << IO_PAGENO_BITS;
 
-	/* ... and the page tables. Since these are contiguous, we can treat
-	 * the page tables as one array of ptes, like pSeries does.
-	 */
 	ptab_size = segments * pages_per_segment * sizeof(unsigned long);
 	pr_debug("%s: iommu[%d]: ptab_size: %lu, order: %d\n", __FUNCTION__,
 			iommu->nid, ptab_size, get_order(ptab_size));
 	page = alloc_pages_node(iommu->nid, GFP_KERNEL, get_order(ptab_size));
 	BUG_ON(!page);
 
-	iommu->ptab = page_address(page);
-	memset(iommu->ptab, 0, ptab_size);
+	ptab = page_address(page);
+	memset(ptab, 0, ptab_size);
 
 	/* number of pages needed for a page table */
 	n_pte_pages = (pages_per_segment *
 		       sizeof(unsigned long)) >> IOMMU_PAGE_SHIFT;
 
 	pr_debug("%s: iommu[%d]: stab at %p, ptab at %p, n_pte_pages: %lu\n",
-			__FUNCTION__, iommu->nid, iommu->stab, iommu->ptab,
+			__FUNCTION__, iommu->nid, iommu->stab, ptab,
 			n_pte_pages);
 
 	/* initialise the STEs */
@@ -364,12 +368,21 @@ static void cell_iommu_setup_page_tables(struct cbe_iommu *iommu,
 		__unknown_page_size_error();
 	}
 
+	gap_base = gap_base >> IO_SEGMENT_SHIFT;
+	gap_size = gap_size >> IO_SEGMENT_SHIFT;
+
 	pr_debug("Setting up IOMMU stab:\n");
-	for (i = base >> IO_SEGMENT_SHIFT; i < segments; i++) {
-		iommu->stab[i] = reg |
-			(__pa(iommu->ptab) + n_pte_pages * IOMMU_PAGE_SIZE * i);
+	for (i = start_seg; i < (start_seg + segments); i++) {
+		if (i >= gap_base && i < (gap_base + gap_size)) {
+			pr_debug("\toverlap at %d, skipping\n", i);
+			continue;
+		}
+		iommu->stab[i] = reg | (__pa(ptab) + n_pte_pages *
+					IOMMU_PAGE_SIZE * (i - start_seg));
 		pr_debug("\t[%d] 0x%016lx\n", i, iommu->stab[i]);
 	}
+
+	return ptab;
 }
 
 static void cell_iommu_enable_hardware(struct cbe_iommu *iommu)
@@ -416,7 +429,8 @@ static void cell_iommu_enable_hardware(struct cbe_iommu *iommu)
 static void cell_iommu_setup_hardware(struct cbe_iommu *iommu,
 	unsigned long base, unsigned long size)
 {
-	cell_iommu_setup_page_tables(iommu, base, size, 0, 0);
+	cell_iommu_setup_stab(iommu, base, size, 0, 0);
+	iommu->ptab = cell_iommu_alloc_ptab(iommu, base, size, 0, 0);
 	cell_iommu_enable_hardware(iommu);
 }
 
@@ -870,8 +884,10 @@ static void cell_iommu_setup_fixed_ptab(struct cbe_iommu *iommu,
 	struct device_node *np, unsigned long dbase, unsigned long dsize,
 	unsigned long fbase, unsigned long fsize)
 {
-	unsigned long base_pte, uaddr, *io_pte;
 	int i;
+	unsigned long base_pte, uaddr, *io_pte, *ptab;
+
+	ptab = cell_iommu_alloc_ptab(iommu, fbase, fsize, dbase, dsize);
 
 	dma_iommu_fixed_base = fbase;
 
@@ -883,7 +899,7 @@ static void cell_iommu_setup_fixed_ptab(struct cbe_iommu *iommu,
 
 	pr_debug("iommu: mapping 0x%lx pages from 0x%lx\n", fsize, fbase);
 
-	io_pte = iommu->ptab;
+	io_pte = ptab;
 	base_pte = IOPTE_PP_W | IOPTE_PP_R | IOPTE_M | IOPTE_SO_RW
 		    | (cell_iommu_get_ioid(np) & IOPTE_IOID_Mask);
 
@@ -894,7 +910,7 @@ static void cell_iommu_setup_fixed_ptab(struct cbe_iommu *iommu,
 			pr_debug("iommu: fixed/dynamic overlap, skipping\n");
 			continue;
 		}
-		io_pte[i] = base_pte | (__pa(uaddr) & IOPTE_RPN_Mask);
+		io_pte[i - fbase] = base_pte | (__pa(uaddr) & IOPTE_RPN_Mask);
 	}
 
 	mb();
@@ -992,7 +1008,8 @@ static int __init cell_iommu_fixed_mapping_init(void)
 			"fixed window 0x%lx-0x%lx\n", iommu->nid, dbase,
 			 dbase + dsize, fbase, fbase + fsize);
 
-		cell_iommu_setup_page_tables(iommu, dbase, dsize, fbase, fsize);
+		cell_iommu_setup_stab(iommu, dbase, dsize, fbase, fsize);
+		iommu->ptab = cell_iommu_alloc_ptab(iommu, dbase, dsize, 0, 0);
 		cell_iommu_setup_fixed_ptab(iommu, np, dbase, dsize,
 					     fbase, fsize);
 		cell_iommu_enable_hardware(iommu);
-- 
1.5.2.rc1.1884.g59b20

^ permalink raw reply related

* [PATCH 6/8] Cell IOMMU: n_pte_pages is in 4K page units, not IOMMU_PAGE_SIZE
From: Michael Ellerman @ 2008-02-29  7:33 UTC (permalink / raw)
  To: linuxppc-dev
In-Reply-To: <fdd3edc0f2f3d2d6cade5cd695b8080d0da95a7f.1204270367.git.michael@ellerman.id.au>

We use n_pte_pages to calculate the stride through the page tables, but
we also use it to set the NPPT value in the segment table entry. That is
defined as the number of 4K pages per segment, so we should calculate
it as such regardless of the IOMMU page size.

Signed-off-by: Michael Ellerman <michael@ellerman.id.au>
---
 arch/powerpc/platforms/cell/iommu.c |    9 ++++-----
 1 files changed, 4 insertions(+), 5 deletions(-)

diff --git a/arch/powerpc/platforms/cell/iommu.c b/arch/powerpc/platforms/cell/iommu.c
index 187a723..7a861cb 100644
--- a/arch/powerpc/platforms/cell/iommu.c
+++ b/arch/powerpc/platforms/cell/iommu.c
@@ -348,9 +348,8 @@ static unsigned long *cell_iommu_alloc_ptab(struct cbe_iommu *iommu,
 	ptab = page_address(page);
 	memset(ptab, 0, ptab_size);
 
-	/* number of pages needed for a page table */
-	n_pte_pages = (pages_per_segment *
-		       sizeof(unsigned long)) >> IOMMU_PAGE_SHIFT;
+	/* number of 4K pages needed for a page table */
+	n_pte_pages = (pages_per_segment * sizeof(unsigned long)) >> 12;
 
 	pr_debug("%s: iommu[%d]: stab at %p, ptab at %p, n_pte_pages: %lu\n",
 			__FUNCTION__, iommu->nid, iommu->stab, ptab,
@@ -377,8 +376,8 @@ static unsigned long *cell_iommu_alloc_ptab(struct cbe_iommu *iommu,
 			pr_debug("\toverlap at %d, skipping\n", i);
 			continue;
 		}
-		iommu->stab[i] = reg | (__pa(ptab) + n_pte_pages *
-					IOMMU_PAGE_SIZE * (i - start_seg));
+		iommu->stab[i] = reg | (__pa(ptab) + (n_pte_pages << 12) *
+					(i - start_seg));
 		pr_debug("\t[%d] 0x%016lx\n", i, iommu->stab[i]);
 	}
 
-- 
1.5.2.rc1.1884.g59b20

^ permalink raw reply related

* [PATCH 7/8] Allow for different IOMMU page sizes in cell IOMMU code
From: Michael Ellerman @ 2008-02-29  7:33 UTC (permalink / raw)
  To: linuxppc-dev
In-Reply-To: <fdd3edc0f2f3d2d6cade5cd695b8080d0da95a7f.1204270367.git.michael@ellerman.id.au>

Make some preliminary changes to cell_iommu_alloc_ptab() to allow it to
take the page size as a parameter rather than assuming IOMMU_PAGE_SIZE.

Signed-off-by: Michael Ellerman <michael@ellerman.id.au>
---
 arch/powerpc/platforms/cell/iommu.c |   31 ++++++++++++++++++-------------
 1 files changed, 18 insertions(+), 13 deletions(-)

diff --git a/arch/powerpc/platforms/cell/iommu.c b/arch/powerpc/platforms/cell/iommu.c
index 7a861cb..b0e347e 100644
--- a/arch/powerpc/platforms/cell/iommu.c
+++ b/arch/powerpc/platforms/cell/iommu.c
@@ -113,7 +113,7 @@
 
 /* IOMMU sizing */
 #define IO_SEGMENT_SHIFT	28
-#define IO_PAGENO_BITS		(IO_SEGMENT_SHIFT - IOMMU_PAGE_SHIFT)
+#define IO_PAGENO_BITS(shift)	(IO_SEGMENT_SHIFT - (shift))
 
 /* The high bit needs to be set on every DMA address */
 #define SPIDER_DMA_OFFSET	0x80000000ul
@@ -328,7 +328,7 @@ static void cell_iommu_setup_stab(struct cbe_iommu *iommu,
 
 static unsigned long *cell_iommu_alloc_ptab(struct cbe_iommu *iommu,
 		unsigned long base, unsigned long size, unsigned long gap_base,
-		unsigned long gap_size)
+		unsigned long gap_size, unsigned long page_shift)
 {
 	struct page *page;
 	int i;
@@ -337,7 +337,10 @@ static unsigned long *cell_iommu_alloc_ptab(struct cbe_iommu *iommu,
 
 	start_seg = base >> IO_SEGMENT_SHIFT;
 	segments  = size >> IO_SEGMENT_SHIFT;
-	pages_per_segment = 1ull << IO_PAGENO_BITS;
+	pages_per_segment = 1ull << IO_PAGENO_BITS(page_shift);
+	/* PTEs for each segment must start on a 4K bounday */
+	pages_per_segment = max(pages_per_segment,
+				(1 << 12) / sizeof(unsigned long));
 
 	ptab_size = segments * pages_per_segment * sizeof(unsigned long);
 	pr_debug("%s: iommu[%d]: ptab_size: %lu, order: %d\n", __FUNCTION__,
@@ -358,13 +361,12 @@ static unsigned long *cell_iommu_alloc_ptab(struct cbe_iommu *iommu,
 	/* initialise the STEs */
 	reg = IOSTE_V | ((n_pte_pages - 1) << 5);
 
-	if (IOMMU_PAGE_SIZE == 0x1000)
-		reg |= IOSTE_PS_4K;
-	else if (IOMMU_PAGE_SIZE == 0x10000)
-		reg |= IOSTE_PS_64K;
-	else {
-		extern void __unknown_page_size_error(void);
-		__unknown_page_size_error();
+	switch (page_shift) {
+	case 12: reg |= IOSTE_PS_4K;  break;
+	case 16: reg |= IOSTE_PS_64K; break;
+	case 20: reg |= IOSTE_PS_1M;  break;
+	case 24: reg |= IOSTE_PS_16M; break;
+	default: BUG();
 	}
 
 	gap_base = gap_base >> IO_SEGMENT_SHIFT;
@@ -429,7 +431,8 @@ static void cell_iommu_setup_hardware(struct cbe_iommu *iommu,
 	unsigned long base, unsigned long size)
 {
 	cell_iommu_setup_stab(iommu, base, size, 0, 0);
-	iommu->ptab = cell_iommu_alloc_ptab(iommu, base, size, 0, 0);
+	iommu->ptab = cell_iommu_alloc_ptab(iommu, base, size, 0, 0,
+					    IOMMU_PAGE_SHIFT);
 	cell_iommu_enable_hardware(iommu);
 }
 
@@ -886,7 +889,8 @@ static void cell_iommu_setup_fixed_ptab(struct cbe_iommu *iommu,
 	int i;
 	unsigned long base_pte, uaddr, *io_pte, *ptab;
 
-	ptab = cell_iommu_alloc_ptab(iommu, fbase, fsize, dbase, dsize);
+	ptab = cell_iommu_alloc_ptab(iommu, fbase, fsize, dbase, dsize,
+				     IOMMU_PAGE_SHIFT);
 
 	dma_iommu_fixed_base = fbase;
 
@@ -1008,7 +1012,8 @@ static int __init cell_iommu_fixed_mapping_init(void)
 			 dbase + dsize, fbase, fbase + fsize);
 
 		cell_iommu_setup_stab(iommu, dbase, dsize, fbase, fsize);
-		iommu->ptab = cell_iommu_alloc_ptab(iommu, dbase, dsize, 0, 0);
+		iommu->ptab = cell_iommu_alloc_ptab(iommu, dbase, dsize, 0, 0,
+						    IOMMU_PAGE_SHIFT);
 		cell_iommu_setup_fixed_ptab(iommu, np, dbase, dsize,
 					     fbase, fsize);
 		cell_iommu_enable_hardware(iommu);
-- 
1.5.2.rc1.1884.g59b20

^ permalink raw reply related

* [PATCH 8/8] Convert the cell IOMMU fixed mapping to 16M IOMMU pages
From: Michael Ellerman @ 2008-02-29  7:33 UTC (permalink / raw)
  To: linuxppc-dev
In-Reply-To: <fdd3edc0f2f3d2d6cade5cd695b8080d0da95a7f.1204270367.git.michael@ellerman.id.au>

The only tricky part is we need to adjust the PTE insertion loop to
cater for holes in the page table. The PTEs for each segment start on
a 4K boundary, so with 16M pages we have 16 PTEs per segment and then
a gap to the next 4K page boundary.

It might be possible to allocate the PTEs for each segment separately,
saving the memory currently filling the gaps. However we'd need to
check that's OK with the hardware, and that it actually saves memory.

Signed-off-by: Michael Ellerman <michael@ellerman.id.au>
---
 arch/powerpc/platforms/cell/iommu.c |   37 ++++++++++++++++++++--------------
 1 files changed, 22 insertions(+), 15 deletions(-)

diff --git a/arch/powerpc/platforms/cell/iommu.c b/arch/powerpc/platforms/cell/iommu.c
index b0e347e..20ea0e1 100644
--- a/arch/powerpc/platforms/cell/iommu.c
+++ b/arch/powerpc/platforms/cell/iommu.c
@@ -882,38 +882,45 @@ static void cell_dma_dev_setup_fixed(struct device *dev)
 	dev_dbg(dev, "iommu: fixed addr = %lx\n", addr);
 }
 
+static void insert_16M_pte(unsigned long addr, unsigned long *ptab,
+			   unsigned long base_pte)
+{
+	unsigned long segment, offset;
+
+	segment = addr >> IO_SEGMENT_SHIFT;
+	offset = (addr >> 24) - (segment << IO_PAGENO_BITS(24));
+	ptab = ptab + (segment * (1 << 12) / sizeof(unsigned long));
+
+	pr_debug("iommu: addr %lx ptab %p segment %lx offset %lx\n",
+		  addr, ptab, segment, offset);
+
+	ptab[offset] = base_pte | (__pa(addr) & IOPTE_RPN_Mask);
+}
+
 static void cell_iommu_setup_fixed_ptab(struct cbe_iommu *iommu,
 	struct device_node *np, unsigned long dbase, unsigned long dsize,
 	unsigned long fbase, unsigned long fsize)
 {
-	int i;
-	unsigned long base_pte, uaddr, *io_pte, *ptab;
+	unsigned long base_pte, uaddr, ioaddr, *ptab;
 
-	ptab = cell_iommu_alloc_ptab(iommu, fbase, fsize, dbase, dsize,
-				     IOMMU_PAGE_SHIFT);
+	ptab = cell_iommu_alloc_ptab(iommu, fbase, fsize, dbase, dsize, 24);
 
 	dma_iommu_fixed_base = fbase;
 
-	/* convert from bytes into page table indices */
-	dbase = dbase >> IOMMU_PAGE_SHIFT;
-	dsize = dsize >> IOMMU_PAGE_SHIFT;
-	fbase = fbase >> IOMMU_PAGE_SHIFT;
-	fsize = fsize >> IOMMU_PAGE_SHIFT;
-
 	pr_debug("iommu: mapping 0x%lx pages from 0x%lx\n", fsize, fbase);
 
-	io_pte = ptab;
 	base_pte = IOPTE_PP_W | IOPTE_PP_R | IOPTE_M | IOPTE_SO_RW
 		    | (cell_iommu_get_ioid(np) & IOPTE_IOID_Mask);
 
-	uaddr = 0;
-	for (i = fbase; i < fbase + fsize; i++, uaddr += IOMMU_PAGE_SIZE) {
+	for (uaddr = 0; uaddr < fsize; uaddr += (1 << 24)) {
 		/* Don't touch the dynamic region */
-		if (i >= dbase && i < (dbase + dsize)) {
+		ioaddr = uaddr + fbase;
+		if (ioaddr >= dbase && ioaddr < (dbase + dsize)) {
 			pr_debug("iommu: fixed/dynamic overlap, skipping\n");
 			continue;
 		}
-		io_pte[i - fbase] = base_pte | (__pa(uaddr) & IOPTE_RPN_Mask);
+
+		insert_16M_pte(uaddr, ptab, base_pte);
 	}
 
 	mb();
-- 
1.5.2.rc1.1884.g59b20

^ permalink raw reply related

* Re: [dtc] breaking out libfdt from dtc so other progs can use it
From: Geert Uytterhoeven @ 2008-02-29  8:35 UTC (permalink / raw)
  To: Josh Boyer; +Cc: linuxppc-dev, David Gibson
In-Reply-To: <20080228125940.78f7f2b6@vader.jdub.homelinux.org>

[-- Attachment #1: Type: TEXT/PLAIN, Size: 1543 bytes --]

On Thu, 28 Feb 2008, Josh Boyer wrote:
> On Thu, 28 Feb 2008 10:30:44 -0600
> Jerone Young <jyoung5@us.ibm.com> wrote:
> > If it where broken out of dtc it would be easier to pickup and pull
> > fixes from it. Even package it so programs can easily build it
> > standalone.
> 
> That's akin to saying libcrypto should be broken out to be completely
> standalone from openssl.  That doesn't make sense either.

Thanks, your openssl example triggered me posting this reply ;-)

I think people are confusing source and binary packages.

E.g. on Debian, the openssl source package is used to build 3 binary packages:
openssl, libssl0.9.8, and libssl-dev. Hence to install applications that use
libssl, you don't have to install all 3, just libssl0.9.8.

But this doesn't mean libssl is separate from openssl source-wise: both are
build from the same source package.

So the single source package dtc could be packaged as 2 binary packages: dtc
and libfdt.

With kind regards,

Geert Uytterhoeven
Software Architect

Sony Network and Software Technology Center Europe
The Corporate Village · Da Vincilaan 7-D1 · B-1935 Zaventem · Belgium

Phone:    +32 (0)2 700 8453
Fax:      +32 (0)2 700 8622
E-mail:   Geert.Uytterhoeven@sonycom.com
Internet: http://www.sony-europe.com/

Sony Network and Software Technology Center Europe
A division of Sony Service Centre (Europe) N.V.
Registered office: Technologielaan 7 · B-1840 Londerzeel · Belgium
VAT BE 0413.825.160 · RPR Brussels
Fortis Bank Zaventem · Swift GEBABEBB08A · IBAN BE39001382358619

^ permalink raw reply

* MPC8641D PCI-Express error
From: Marco Stornelli @ 2008-02-29  8:50 UTC (permalink / raw)
  To: LinuxPPC-Embedded

Hi,

I have some news about my problem. When the system makes the boot
(kernel 2.6.24) I see these messages:

...........
PCI: Probing PCI hardware
PCI: 0000:00:00.0: class b20 doesn't match header type 01. Ignoring class.
PCI: Transparent bridge - 0000:00:00.0
PCI: Transparent bridge - 0000:01:00.0
PCI: 0001:03:00.0: class b20 doesn't match header type 01. Ignoring class.
PCI: Transparent bridge - 0001:03:00.0
PCI: Cannot allocate resource region 0 of device 0000:02:1f.0
PCI: Cannot allocate resource region 1 of device 0000:02:1f.0
PCI: Cannot allocate resource region 2 of device 0000:02:1f.0
PCI: Cannot allocate resource region 3 of device 0000:02:1f.0
PCI: Cannot allocate resource region 4 of device 0000:02:1f.0
PCI: Cannot allocate resource region 0 of device 0000:02:1f.1
PCI: Cannot allocate resource region 1 of device 0000:02:1f.1
PCI: Cannot allocate resource region 2 of device 0000:02:1f.1
PCI: Cannot allocate resource region 3 of device 0000:02:1f.1
PCI: Cannot allocate resource region 4 of device 0000:02:1f.1
PCI: Cannot allocate resource region 0 of device 0001:04:00.0
PCI: Cannot allocate resource region 1 of device 0001:04:00.0
PCI: Error while updating region 0000:02:1f.1/0 (00001419 != 00001411)
PCI: Error while updating region 0000:02:1f.1/2 (00001439 != 00001431)
PCI: Error while updating region 0000:02:1f.1/3 (00001435 != 00001431)

..............

where the device 0001:04:00.0 is my ML555 Virtex5 evaluation board. The
lspci output is:

0000:02:1f.0 Class 0101: Unknown device 10b9:5229 (rev c8) (prog-if 8f
[Master SecP SecO PriP PriO])
        Subsystem: Unknown device 10b9:5229
        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, Cache Line Size: 32 bytes
        Interrupt: pin A routed to IRQ 14
        Region 0: I/O ports at 1400 [size=8]
        Region 1: I/O ports at 1408 [size=4]
        Region 2: I/O ports at 1410 [size=8]
        Region 3: I/O ports at 140c [size=4]
        Region 4: I/O ports at 1420 [size=16]
        Capabilities: [60] 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-
        Capabilities: [80] Message Signalled Interrupts: Mask- 64bit-
Queue=0/0 Enable-
                Address: 00000000  Data: 0000




0000:02:1f.1 Class 0101: Unknown device 10b9:5288 (rev 10) (prog-if 01
[PriO])
        Subsystem: Unknown device 10b9:5288
        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, Cache Line Size: 32 bytes
        Interrupt: pin A routed to IRQ 5
        Region 0: I/O ports at 1418 [size=8]
        Region 1: I/O ports at 1430 [size=4]
        Region 2: I/O ports at 1438 [size=8]
        Region 3: I/O ports at 1434 [size=4]
        Region 4: I/O ports at 1440 [size=16]
        Region 5: Memory at 80006000 (32-bit, non-prefetchable) [size=1K]
        Capabilities: [60] 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-
        Capabilities: [70] Message Signalled Interrupts: Mask- 64bit+
Queue=0/0 Enable-
                Address: 0000000000000000  Data: 0000






0001:04:00.0 Class 0500: Unknown device 10ee:0007
        Subsystem: Unknown device 14d0:6601
        Control: I/O- Mem- BusMaster- SpecCycle- MemWINV- VGASnoop-
ParErr- Stepping- SERR- FastB2B-
        Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort-
<TAbort- <MAbort- >SERR- <PERR-
        Interrupt: pin A routed to IRQ 19
        Region 0: Memory at a0000000 (32-bit, non-prefetchable)
[disabled] [size=1M]
        Region 1: Memory at a0100000 (32-bit, non-prefetchable)
[disabled] [size=1M]
        Capabilities: [40] Power Management version 3
                Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA
PME(D0-,D1-,D2-,D3hot-,D3cold-)
                Status: D0 PME-Enable- DSel=0 DScale=0 PME-
        Capabilities: [48] Message Signalled Interrupts: Mask+ 64bit+
Queue=0/0 Enable-
                Address: 0000000000000000  Data: 0000
                Masking: 00000000  Pending: 00000000
        Capabilities: [60] Express Endpoint IRQ 0
                Device: Supported: MaxPayload 256 bytes, PhantFunc 1,
ExtTag+
                Device: Latency L0s unlimited, L1 unlimited
                Device: AtnBtn- AtnInd- PwrInd-
                Device: Errors: Correctable- Non-Fatal- Fatal- Unsupported-
                Device: RlxdOrd+ ExtTag- PhantFunc- AuxPwr- NoSnoop+
                Device: MaxPayload 128 bytes, MaxReadReq 512 bytes
                Link: Supported Speed 2.5Gb/s, Width x4, ASPM L0s L1, Port 0
                Link: Latency L0s unlimited, L1 unlimited
                Link: ASPM Disabled RCB 64 bytes CommClk- ExtSynch-
                Link: Speed 2.5Gb/s, Width x4
        Capabilities: [100] Device Serial Number 35-0a-00-01-01-00-00-00

(The last device appears disabled because the driver isn't still
loaded). Are  these prints a normal behaviour? Because I read in the
function which prints this messages (alloc_resource in
arch/powerpc/kernel/pci_32.c) this comment:

/* We'll assign a new address later */

Is there some bug in the kernel? Any suggestions? Please help me.

Thanks.

Marco

^ permalink raw reply

* Re: [PATCH 1/2] firewire: endianess fix
From: Paul Mackerras @ 2008-02-29 11:26 UTC (permalink / raw)
  To: Jarod Wilson
  Cc: Kristian Hoegsberg, linux-kernel, linuxppc-dev, Stefan Richter,
	sparclinux, linux1394-devel, Sam Ravnborg, Harvey Harrison
In-Reply-To: <47C79CB1.6050104@redhat.com>

Jarod Wilson writes:

> Still no luck finding one here. The person I was thinking of has a 
> Lombard, which has no firewire. I did get ahold of a 667MHz Titanium, 
> but its got an Agere FW323. Pretty sure my old man actually has a Pismo, 
> but its about a 3000 mile drive over to my folks house. The search 
> continues... I wonder how many people still actually 1) have a machine 
> with this controller, 2) are running Linux on it and 3) use firewire 
> devices with it. Both of you, please speak up, we're trying to help you! 
> (if only out of morbid curiosity to see this mythical goofy controller).

I have a first-generation titanium powerbook that has this controller
(assuming we're talking about vendor/device id = 0x106b / 0x18), and
yes I run Linux (only) on it and use firewire disks. :)

Paul.

^ permalink raw reply

* Re: [PATCH 1/2] firewire: endianess fix
From: Stefan Richter @ 2008-02-29 11:52 UTC (permalink / raw)
  To: Paul Mackerras
  Cc: Kristian Hoegsberg, linux-kernel, linuxppc-dev, sparclinux,
	Jarod Wilson, linux1394-devel, Sam Ravnborg, Harvey Harrison
In-Reply-To: <18375.60394.166769.540668@cargo.ozlabs.ibm.com>

Paul Mackerras wrote:
> Jarod Wilson writes:
>> I wonder how many people still actually 1) have a machine 
>> with this controller, 2) are running Linux on it and 3) use firewire 
>> devices with it. Both of you, please speak up, we're trying to help you! 
>> (if only out of morbid curiosity to see this mythical goofy controller).
> 
> I have a first-generation titanium powerbook that has this controller
> (assuming we're talking about vendor/device id = 0x106b / 0x18), and
> yes I run Linux (only) on it and use firewire disks. :)

I actually have a TiBook 400 myself, but so far without Linux, and its 
FireWire PHY is dead.  But I can use CardBus FireWire cards on it to do 
basic testing on a big endian PC, and I can test the selfID 
byte-swapping by the PHY-less onboard controller.

I now started a Fedora 8 live CD (self-test says the medium is 
corrupt... need to burn another one) and dmesg says:
firewire_ohci: Added fw-ohci device 0002:24:0e.0, OHCI version 1.0
firewire_ohci: recursive bus reset detected, discarding self ids
[...]

The second line looks like this is indeed one of those which needs the 
header byte-swap workaround which ohci1394 has but firewire-ohci hasn't yet.

On the weekend I'm going to attempt to put Linux on this PowerBook, at last.
-- 
Stefan Richter
-=====-==--- --=- ===-=
http://arcgraph.de/sr/

^ permalink raw reply

* Re: [dtc] breaking out libfdt from dtc so other progs can use it
From: Josh Boyer @ 2008-02-29 14:09 UTC (permalink / raw)
  To: Geert Uytterhoeven; +Cc: linuxppc-dev, David Gibson
In-Reply-To: <Pine.LNX.4.64.0802290930020.25557@vixen.sonytel.be>

On Fri, 29 Feb 2008 09:35:48 +0100 (CET)
Geert Uytterhoeven <Geert.Uytterhoeven@sonycom.com> wrote:

> On Thu, 28 Feb 2008, Josh Boyer wrote:
> > On Thu, 28 Feb 2008 10:30:44 -0600
> > Jerone Young <jyoung5@us.ibm.com> wrote:
> > > If it where broken out of dtc it would be easier to pickup and pull
> > > fixes from it. Even package it so programs can easily build it
> > > standalone.
> > 
> > That's akin to saying libcrypto should be broken out to be completely
> > standalone from openssl.  That doesn't make sense either.
> 
> Thanks, your openssl example triggered me posting this reply ;-)
> 
> I think people are confusing source and binary packages.
> 
> E.g. on Debian, the openssl source package is used to build 3 binary packages:
> openssl, libssl0.9.8, and libssl-dev. Hence to install applications that use
> libssl, you don't have to install all 3, just libssl0.9.8.
> 
> But this doesn't mean libssl is separate from openssl source-wise: both are
> build from the same source package.
> 
> So the single source package dtc could be packaged as 2 binary packages: dtc
> and libfdt.

Yes, that's certainly possible for the various distros.  For Fedora
we'd have to get an exception for a static library, or convert it to a
shared one.  Other distros might not have that restriction.

josh

^ permalink raw reply

* Re: [PATCH] [POWERPC] Fix zImage-dtb.initrd build error
From: Grant Likely @ 2008-02-29 14:33 UTC (permalink / raw)
  To: Geert.Uytterhoeven, linuxppc-dev; +Cc: miltonm, paulus, Hiroaki_Fuse
In-Reply-To: <20080221185651.6893.78700.stgit@trillian.secretlab.ca>

Any comments on this patch?  It needs to go in for .25, but I haven't
gotten any Acks on it.

Cheers,
g.

On Thu, Feb 21, 2008 at 11:57 AM, Grant Likely
<grant.likely@secretlab.ca> wrote:
> From: Grant Likely <grant.likely@secretlab.ca>
>
>  The pattern substitution rules were failing when used with zImage-dtb
>  targets.  if zImage-dtb.initrd was selected, the pattern substitution
>  would generate "zImage.initrd-dtb" instead of "zImage-dtb.initrd" which
>  caused the build to fail.
>
>  This patch renames zImage-dtb to dtbImage to avoid the problem entirely.
>  By not using the zImage prefix then is no potential for namespace
>  collisions.
>
>  Signed-off-by: Grant Likely <grant.likely@secretlab.ca>
>
>  ---
>  Note to reviewers.  Please consider this change carefully.  I saw two
>  options for fixing this bug;
>  1) rework the pattern substitution to handle zImage-dtb correctly
>  2) avoid using the zImage prefix
>
>  I chose option 2 because it avoids increasing the complexity of the
>  pattern substitution code for generating initrd names.  However, doing
>  so will have an impact on distributors because it changes the name of
>  the generated image.  If this is a problem for anyone, or if you have
>  a better name suggestion than "dtbImage", then please speak up.
>
>  Cheers,
>  g.
>  ---
>
>   arch/powerpc/Makefile      |    2 +-
>   arch/powerpc/boot/Makefile |   18 ++++++++++--------
>   2 files changed, 11 insertions(+), 9 deletions(-)
>
>  diff --git a/arch/powerpc/Makefile b/arch/powerpc/Makefile
>  index 1c6ce35..ab5cfe8 100644
>  --- a/arch/powerpc/Makefile
>  +++ b/arch/powerpc/Makefile
>  @@ -155,7 +155,7 @@ all: zImage
>
>   CPPFLAGS_vmlinux.lds   := -Upowerpc
>
>  -BOOT_TARGETS = zImage zImage.initrd uImage treeImage.% cuImage.%
>  +BOOT_TARGETS = zImage zImage.initrd uImage zImage% dtbImage% treeImage.% cuImage.%
>
>   PHONY += $(BOOT_TARGETS)
>
>  diff --git a/arch/powerpc/boot/Makefile b/arch/powerpc/boot/Makefile
>  index 63d07cc..d57a67d 100644
>  --- a/arch/powerpc/boot/Makefile
>  +++ b/arch/powerpc/boot/Makefile
>  @@ -186,7 +186,7 @@ quiet_cmd_wrap      = WRAP    $@
>   image-$(CONFIG_PPC_PSERIES)            += zImage.pseries
>   image-$(CONFIG_PPC_MAPLE)              += zImage.pseries
>   image-$(CONFIG_PPC_IBM_CELL_BLADE)     += zImage.pseries
>  -image-$(CONFIG_PPC_PS3)                        += zImage-dtb.ps3
>  +image-$(CONFIG_PPC_PS3)                        += dtbImage.ps3
>   image-$(CONFIG_PPC_CELLEB)             += zImage.pseries
>   image-$(CONFIG_PPC_CHRP)               += zImage.chrp
>   image-$(CONFIG_PPC_EFIKA)              += zImage.chrp
>  @@ -205,7 +205,7 @@ image-$(CONFIG_DEFAULT_UIMAGE)              += uImage
>   #
>
>   # Board ports in arch/powerpc/platform/40x/Kconfig
>  -image-$(CONFIG_EP405)                  += zImage-dtb.ep405
>  +image-$(CONFIG_EP405)                  += dtbImage.ep405
>   image-$(CONFIG_WALNUT)                 += treeImage.walnut
>
>   # Board ports in arch/powerpc/platform/44x/Kconfig
>  @@ -220,9 +220,9 @@ image-$(CONFIG_WARP)                        += cuImage.warp
>   # Board ports in arch/powerpc/platform/8xx/Kconfig
>   image-$(CONFIG_PPC_MPC86XADS)          += cuImage.mpc866ads
>   image-$(CONFIG_PPC_MPC885ADS)          += cuImage.mpc885ads
>  -image-$(CONFIG_PPC_EP88XC)             += zImage-dtb.ep88xc
>  +image-$(CONFIG_PPC_EP88XC)             += dtbImage.ep88xc
>   image-$(CONFIG_PPC_ADDER875)           += cuImage.adder875-uboot \
>  -                                          zImage-dtb.adder875-redboot
>  +                                          dtbImage.adder875-redboot
>
>   # Board ports in arch/powerpc/platform/52xx/Kconfig
>   image-$(CONFIG_PPC_LITE5200)           += cuImage.lite5200 cuImage.lite5200b
>  @@ -230,7 +230,7 @@ image-$(CONFIG_PPC_LITE5200)                += cuImage.lite5200 cuImage.lite5200b
>   # Board ports in arch/powerpc/platform/82xx/Kconfig
>   image-$(CONFIG_MPC8272_ADS)            += cuImage.mpc8272ads
>   image-$(CONFIG_PQ2FADS)                        += cuImage.pq2fads
>  -image-$(CONFIG_EP8248E)                        += zImage-dtb.ep8248e
>  +image-$(CONFIG_EP8248E)                        += dtbImage.ep8248e
>
>   # Board ports in arch/powerpc/platform/83xx/Kconfig
>   image-$(CONFIG_MPC832x_MDS)            += cuImage.mpc832x_mds
>  @@ -268,7 +268,8 @@ endif
>
>   initrd-  := $(patsubst zImage%, zImage.initrd%, $(image-n) $(image-))
>   initrd-y := $(patsubst zImage%, zImage.initrd%, \
>  -               $(patsubst treeImage%, treeImage.initrd%, $(image-y)))
>  +               $(patsubst dtbImage%, dtbImage.initrd%, \
>  +               $(patsubst treeImage%, treeImage.initrd%, $(image-y))))
>   initrd-y := $(filter-out $(image-y), $(initrd-y))
>   targets        += $(image-y) $(initrd-y)
>
>  @@ -283,10 +284,11 @@ $(obj)/zImage.initrd.%: vmlinux $(wrapperbits)
>   $(obj)/zImage.%: vmlinux $(wrapperbits)
>         $(call if_changed,wrap,$*)
>
>  -$(obj)/zImage-dtb.initrd.%: vmlinux $(wrapperbits) $(dtstree)/%.dts
>  +# dtbImage% - a dtbImage is a zImage with an embedded device tree blob
>  +$(obj)/dtbImage.initrd.%: vmlinux $(wrapperbits) $(dtstree)/%.dts
>         $(call if_changed,wrap,$*,$(dtstree)/$*.dts,,$(obj)/ramdisk.image.gz)
>
>  -$(obj)/zImage-dtb.%: vmlinux $(wrapperbits) $(dtstree)/%.dts
>  +$(obj)/dtbImage.%: vmlinux $(wrapperbits) $(dtstree)/%.dts
>         $(call if_changed,wrap,$*,$(dtstree)/$*.dts)
>
>   # This cannot be in the root of $(src) as the zImage rule always adds a $(obj)
>
>



-- 
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.

^ permalink raw reply

* Re: [PATCH v2 3/5] [POWERPC] Add Canyonlands DTS
From: Josh Boyer @ 2008-02-29 15:11 UTC (permalink / raw)
  To: Stefan Roese; +Cc: linuxppc-dev
In-Reply-To: <1203800881-13837-1-git-send-email-sr@denx.de>

On Sat, 23 Feb 2008 22:08:01 +0100
Stefan Roese <sr@denx.de> wrote:

> Signed-off-by: Stefan Roese <sr@denx.de>
> ---
> And now the I2C device-types are removed. Sorry for the mail-flood.
> 
>  arch/powerpc/boot/dts/canyonlands.dts |  393 +++++++++++++++++++++++++++++++++
>  1 files changed, 393 insertions(+), 0 deletions(-)
>  create mode 100644 arch/powerpc/boot/dts/canyonlands.dts
> 
> diff --git a/arch/powerpc/boot/dts/canyonlands.dts b/arch/powerpc/boot/dts/canyonlands.dts
> new file mode 100644
> index 0000000..2aee74c
> --- /dev/null
> +++ b/arch/powerpc/boot/dts/canyonlands.dts

[snip]

> +		MAL0: mcmal {
> +			compatible = "ibm,mcmal-460ex", "ibm,mcmal2";
> +			dcr-reg = <180 62>;
> +			num-tx-chans = <2>;
> +			num-rx-chans = <10>;
> +			#address-cells = <0>;
> +			#size-cells = <0>;
> +			interrupt-parent = <&UIC2>;
> +			interrupts = <	/*TXEOB*/ 6 4
> +					/*RXEOB*/ 7 4
> +					/*SERR*/  3 4

This is odd.  I have MAL SERR listed twice in the spec I have.  This
assignment is there, and there's also one to UIC1 IRQ 0.  Error in my
spec, or are both actually tied to the same interrupt line?

> +					/*TXDE*/  4 4
> +					/*RXDE*/  5 4>;
> +		};

> +			UART0: serial@ef600300 {
> +				device_type = "serial";
> +				compatible = "ns16550";
> +				reg = <ef600300 8>;
> +				virtual-reg = <ef600300>;
> +				clock-frequency = <0>; /* Filled in by U-Boot */
> +				current-speed = <0>; /* Filled in by U-Boot */
> +				interrupt-parent = <&UIC1>;
> +				interrupts = <1 4>;

Should this be <2 4> or is the spec I have wrong?

josh

^ permalink raw reply

* Re: [PATCH 1/2] firewire: endianess fix
From: Jarod Wilson @ 2008-02-29 15:34 UTC (permalink / raw)
  To: Paul Mackerras
  Cc: Kristian Hoegsberg, linux-kernel, linuxppc-dev, Stefan Richter,
	sparclinux, linux1394-devel, Sam Ravnborg, Harvey Harrison
In-Reply-To: <18375.60394.166769.540668@cargo.ozlabs.ibm.com>

On Friday 29 February 2008 06:26:34 am Paul Mackerras wrote:
> Jarod Wilson writes:
> > Still no luck finding one here. The person I was thinking of has a
> > Lombard, which has no firewire. I did get ahold of a 667MHz Titanium,
> > but its got an Agere FW323. Pretty sure my old man actually has a Pismo,
> > but its about a 3000 mile drive over to my folks house. The search
> > continues... I wonder how many people still actually 1) have a machine
> > with this controller, 2) are running Linux on it and 3) use firewire
> > devices with it. Both of you, please speak up, we're trying to help you!
> > (if only out of morbid curiosity to see this mythical goofy controller).
>
> I have a first-generation titanium powerbook that has this controller
> (assuming we're talking about vendor/device id = 0x106b / 0x18), and
> yes I run Linux (only) on it and use firewire disks. :)

Yup, seems that's the one. Sounds like we had another one hiding in plain site 
in Stefan's hands too, the thing just was meeting criterion #2. ;)


-- 
Jarod Wilson
jwilson@redhat.com

^ permalink raw reply

* Re: [PATCH v2 3/5] [POWERPC] Add Canyonlands DTS
From: Stefan Roese @ 2008-02-29 15:36 UTC (permalink / raw)
  To: Josh Boyer; +Cc: linuxppc-dev
In-Reply-To: <20080229091120.1611ec56@zod.rchland.ibm.com>

On Friday 29 February 2008, Josh Boyer wrote:
> On Sat, 23 Feb 2008 22:08:01 +0100
>
> Stefan Roese <sr@denx.de> wrote:
> > Signed-off-by: Stefan Roese <sr@denx.de>
> > ---
> > And now the I2C device-types are removed. Sorry for the mail-flood.
> >
> >  arch/powerpc/boot/dts/canyonlands.dts |  393
> > +++++++++++++++++++++++++++++++++ 1 files changed, 393 insertions(+), 0
> > deletions(-)
> >  create mode 100644 arch/powerpc/boot/dts/canyonlands.dts
> >
> > diff --git a/arch/powerpc/boot/dts/canyonlands.dts
> > b/arch/powerpc/boot/dts/canyonlands.dts new file mode 100644
> > index 0000000..2aee74c
> > --- /dev/null
> > +++ b/arch/powerpc/boot/dts/canyonlands.dts
>
> [snip]
>
> > +		MAL0: mcmal {
> > +			compatible = "ibm,mcmal-460ex", "ibm,mcmal2";
> > +			dcr-reg = <180 62>;
> > +			num-tx-chans = <2>;
> > +			num-rx-chans = <10>;
> > +			#address-cells = <0>;
> > +			#size-cells = <0>;
> > +			interrupt-parent = <&UIC2>;
> > +			interrupts = <	/*TXEOB*/ 6 4
> > +					/*RXEOB*/ 7 4
> > +					/*SERR*/  3 4
>
> This is odd.  I have MAL SERR listed twice in the spec I have.  This
> assignment is there, and there's also one to UIC1 IRQ 0.  Error in my
> spec, or are both actually tied to the same interrupt line?

Must be an error in the preliminary spec. I have the engineering docs from 
AMCC and here UIC1 IRQ0 is the external IRQ 2, which is used for PCI. So this 
is still wrong in the current dts version. I'll send an updated version 
probably tomorrow.

> > +					/*TXDE*/  4 4
> > +					/*RXDE*/  5 4>;
> > +		};
> >
> > +			UART0: serial@ef600300 {
> > +				device_type = "serial";
> > +				compatible = "ns16550";
> > +				reg = <ef600300 8>;
> > +				virtual-reg = <ef600300>;
> > +				clock-frequency = <0>; /* Filled in by U-Boot */
> > +				current-speed = <0>; /* Filled in by U-Boot */
> > +				interrupt-parent = <&UIC1>;
> > +				interrupts = <1 4>;
>
> Should this be <2 4> or is the spec I have wrong?

Again, your documentation is incorrect. Took me 1/2 a day to figure this out 
myself.

Best regards,
Stefan

^ permalink raw reply

* Re: [PATCH v2 3/5] [POWERPC] Add Canyonlands DTS
From: Josh Boyer @ 2008-02-29 15:43 UTC (permalink / raw)
  To: Stefan Roese; +Cc: linuxppc-dev
In-Reply-To: <200802291636.29759.sr@denx.de>

On Fri, 29 Feb 2008 16:36:29 +0100
Stefan Roese <sr@denx.de> wrote:

> On Friday 29 February 2008, Josh Boyer wrote:
> > On Sat, 23 Feb 2008 22:08:01 +0100
> >
> > Stefan Roese <sr@denx.de> wrote:
> > > Signed-off-by: Stefan Roese <sr@denx.de>
> > > ---
> > > And now the I2C device-types are removed. Sorry for the mail-flood.
> > >
> > >  arch/powerpc/boot/dts/canyonlands.dts |  393
> > > +++++++++++++++++++++++++++++++++ 1 files changed, 393 insertions(+), 0
> > > deletions(-)
> > >  create mode 100644 arch/powerpc/boot/dts/canyonlands.dts
> > >
> > > diff --git a/arch/powerpc/boot/dts/canyonlands.dts
> > > b/arch/powerpc/boot/dts/canyonlands.dts new file mode 100644
> > > index 0000000..2aee74c
> > > --- /dev/null
> > > +++ b/arch/powerpc/boot/dts/canyonlands.dts
> >
> > [snip]
> >
> > > +		MAL0: mcmal {
> > > +			compatible = "ibm,mcmal-460ex", "ibm,mcmal2";
> > > +			dcr-reg = <180 62>;
> > > +			num-tx-chans = <2>;
> > > +			num-rx-chans = <10>;
> > > +			#address-cells = <0>;
> > > +			#size-cells = <0>;
> > > +			interrupt-parent = <&UIC2>;
> > > +			interrupts = <	/*TXEOB*/ 6 4
> > > +					/*RXEOB*/ 7 4
> > > +					/*SERR*/  3 4
> >
> > This is odd.  I have MAL SERR listed twice in the spec I have.  This
> > assignment is there, and there's also one to UIC1 IRQ 0.  Error in my
> > spec, or are both actually tied to the same interrupt line?
> 
> Must be an error in the preliminary spec. I have the engineering docs from 
> AMCC and here UIC1 IRQ0 is the external IRQ 2, which is used for PCI. So this 
> is still wrong in the current dts version. I'll send an updated version 
> probably tomorrow.

OK.  That doesn't surprise me actually.

> > > +					/*TXDE*/  4 4
> > > +					/*RXDE*/  5 4>;
> > > +		};
> > >
> > > +			UART0: serial@ef600300 {
> > > +				device_type = "serial";
> > > +				compatible = "ns16550";
> > > +				reg = <ef600300 8>;
> > > +				virtual-reg = <ef600300>;
> > > +				clock-frequency = <0>; /* Filled in by U-Boot */
> > > +				current-speed = <0>; /* Filled in by U-Boot */
> > > +				interrupt-parent = <&UIC1>;
> > > +				interrupts = <1 4>;
> >
> > Should this be <2 4> or is the spec I have wrong?
> 
> Again, your documentation is incorrect. Took me 1/2 a day to figure this out 
> myself.

I sort of figured that was the case.  I didn't expect you to have sent
out patches that don't have a working console :).

josh

^ permalink raw reply

* Re: [RFC 08/10] um: dyn/uml.lds.S cleanup - use PAGE_SIZE macro
From: Jeff Dike @ 2008-02-29 15:43 UTC (permalink / raw)
  To: gorcunov
  Cc: chris, linux-m68k, linux-m32r, takata, linux-kernel, linuxppc-dev,
	paulus, geert, sam, rth
In-Reply-To: <20080227210004.189002678@gmail.com>

On Wed, Feb 27, 2008 at 11:58:39PM +0300, gorcunov@gmail.com wrote:
> This patch includes page.h header into liker scripts that
> allow us to use PAGE_SIZE macro instead of numeric constant.
> 
> To be able to include page.h into linker scripts page.h is
> needed for some modification - i.e. we need to use __ASSEMBLY__
> and _AC macro
> 
> Signed-off-by: Cyrill Gorcunov <gorcunov@gmail.com>

Needed some fixing, but it's OK.  I'll forward it on.

       	    	    	Jeff

-- 
Work email - jdike at linux dot intel dot com

^ permalink raw reply

* [PATCH] add strncmp to PowerPC
From: Steven Rostedt @ 2008-02-29 16:04 UTC (permalink / raw)
  To: paulus, linuxppc-dev; +Cc: LKML


strncmp is defined in assembly for bootup, but it is not defined in the
normal running kernel. This patch takes the strncmp code from the bootup
and copies it to the kernel proper.

Signed-off-by: Steven Rostedt <srostedt@redhat.com>
---
 arch/powerpc/kernel/ppc_ksyms.c |    1 +
 arch/powerpc/lib/string.S       |   12 ++++++++++++
 include/asm-powerpc/string.h    |    2 ++
 3 files changed, 15 insertions(+)

Index: linux-sched-devel.git/arch/powerpc/kernel/ppc_ksyms.c
===================================================================
--- linux-sched-devel.git.orig/arch/powerpc/kernel/ppc_ksyms.c	2008-02-27 14:01:38.000000000 -0800
+++ linux-sched-devel.git/arch/powerpc/kernel/ppc_ksyms.c	2008-02-29 07:24:22.000000000 -0800
@@ -78,6 +78,7 @@ EXPORT_SYMBOL(strncpy);
 EXPORT_SYMBOL(strcat);
 EXPORT_SYMBOL(strlen);
 EXPORT_SYMBOL(strcmp);
+EXPORT_SYMBOL(strncmp);
 
 EXPORT_SYMBOL(csum_partial);
 EXPORT_SYMBOL(csum_partial_copy_generic);
Index: linux-sched-devel.git/arch/powerpc/lib/string.S
===================================================================
--- linux-sched-devel.git.orig/arch/powerpc/lib/string.S	2008-02-27 14:01:38.000000000 -0800
+++ linux-sched-devel.git/arch/powerpc/lib/string.S	2008-02-29 07:24:22.000000000 -0800
@@ -75,6 +75,18 @@ _GLOBAL(strcmp)
 	beq	1b
 	blr
 
+_GLOBAL(strncmp)
+	mtctr	r5
+	addi	r5,r3,-1
+	addi	r4,r4,-1
+1:	lbzu	r3,1(r5)
+	cmpwi	1,r3,0
+	lbzu	r0,1(r4)
+	subf.	r3,r0,r3
+	beqlr	1
+	bdnzt	eq,1b
+	blr
+
 _GLOBAL(strlen)
 	addi	r4,r3,-1
 1:	lbzu	r0,1(r4)
Index: linux-sched-devel.git/include/asm-powerpc/string.h
===================================================================
--- linux-sched-devel.git.orig/include/asm-powerpc/string.h	2008-02-27 14:01:58.000000000 -0800
+++ linux-sched-devel.git/include/asm-powerpc/string.h	2008-02-29 07:24:22.000000000 -0800
@@ -7,6 +7,7 @@
 #define __HAVE_ARCH_STRNCPY
 #define __HAVE_ARCH_STRLEN
 #define __HAVE_ARCH_STRCMP
+#define __HAVE_ARCH_STRNCMP
 #define __HAVE_ARCH_STRCAT
 #define __HAVE_ARCH_MEMSET
 #define __HAVE_ARCH_MEMCPY
@@ -18,6 +19,7 @@ extern char * strcpy(char *,const char *
 extern char * strncpy(char *,const char *, __kernel_size_t);
 extern __kernel_size_t strlen(const char *);
 extern int strcmp(const char *,const char *);
+extern int strncmp(const char *,const char *,__kernel_size_t);
 extern char * strcat(char *, const char *);
 extern void * memset(void *,int,__kernel_size_t);
 extern void * memcpy(void *,const void *,__kernel_size_t);

^ permalink raw reply

* [PATCH v3 3/5] [POWERPC] Add Canyonlands DTS
From: Stefan Roese @ 2008-02-29 16:25 UTC (permalink / raw)
  To: linuxppc-dev

This dts version has the following changes to the previous one:

- Remove linux,network-index from EMAC device nodes
- Fix spelling in IIC1 node
- Assign correct PCI interrupt (external IRQ2 is mapped to UIC1-0)

Signed-off-by: Stefan Roese <sr@denx.de>
---

 arch/powerpc/boot/dts/canyonlands.dts |  396 +++++++++++++++++++++++++++++++++
 1 files changed, 391 insertions(+), 0 deletions(-)
 create mode 100644 arch/powerpc/boot/dts/canyonlands.dts

diff --git a/arch/powerpc/boot/dts/canyonlands.dts b/arch/powerpc/boot/dts/canyonlands.dts
new file mode 100644
index 0000000..c50b67e
--- /dev/null
+++ b/arch/powerpc/boot/dts/canyonlands.dts
@@ -0,0 +1,391 @@
+/*
+ * Device Tree Source for AMCC Canyonlands (460EX)
+ *
+ * Copyright 2008 DENX Software Engineering, Stefan Roese <sr@denx.de>
+ *
+ * This file is licensed under the terms of the GNU General Public
+ * License version 2.  This program is licensed "as is" without
+ * any warranty of any kind, whether express or implied.
+ */
+
+/ {
+	#address-cells = <2>;
+	#size-cells = <1>;
+	model = "amcc,canyonlands";
+	compatible = "amcc,canyonlands";
+	dcr-parent = <&/cpus/cpu@0>;
+
+	aliases {
+		ethernet0 = &EMAC0;
+		ethernet1 = &EMAC1;
+		serial0 = &UART0;
+		serial1 = &UART1;
+	};
+
+	cpus {
+		#address-cells = <1>;
+		#size-cells = <0>;
+
+		cpu@0 {
+			device_type = "cpu";
+			model = "PowerPC,460EX";
+			reg = <0>;
+			clock-frequency = <0>; /* Filled in by U-Boot */
+			timebase-frequency = <0>; /* Filled in by U-Boot */
+			i-cache-line-size = <20>;
+			d-cache-line-size = <20>;
+			i-cache-size = <8000>;
+			d-cache-size = <8000>;
+			dcr-controller;
+			dcr-access-method = "native";
+		};
+	};
+
+	memory {
+		device_type = "memory";
+		reg = <0 0 0>; /* Filled in by U-Boot */
+	};
+
+	UIC0: interrupt-controller0 {
+		compatible = "ibm,uic-460ex","ibm,uic";
+		interrupt-controller;
+		cell-index = <0>;
+		dcr-reg = <0c0 009>;
+		#address-cells = <0>;
+		#size-cells = <0>;
+		#interrupt-cells = <2>;
+	};
+
+	UIC1: interrupt-controller1 {
+		compatible = "ibm,uic-460ex","ibm,uic";
+		interrupt-controller;
+		cell-index = <1>;
+		dcr-reg = <0d0 009>;
+		#address-cells = <0>;
+		#size-cells = <0>;
+		#interrupt-cells = <2>;
+		interrupts = <1e 4 1f 4>; /* cascade */
+		interrupt-parent = <&UIC0>;
+	};
+
+	UIC2: interrupt-controller2 {
+		compatible = "ibm,uic-460ex","ibm,uic";
+		interrupt-controller;
+		cell-index = <2>;
+		dcr-reg = <0e0 009>;
+		#address-cells = <0>;
+		#size-cells = <0>;
+		#interrupt-cells = <2>;
+		interrupts = <a 4 b 4>; /* cascade */
+		interrupt-parent = <&UIC0>;
+	};
+
+	UIC3: interrupt-controller3 {
+		compatible = "ibm,uic-460ex","ibm,uic";
+		interrupt-controller;
+		cell-index = <3>;
+		dcr-reg = <0f0 009>;
+		#address-cells = <0>;
+		#size-cells = <0>;
+		#interrupt-cells = <2>;
+		interrupts = <10 4 11 4>; /* cascade */
+		interrupt-parent = <&UIC0>;
+	};
+
+	SDR0: sdr {
+		compatible = "ibm,sdr-460ex";
+		dcr-reg = <00e 002>;
+	};
+
+	CPR0: cpr {
+		compatible = "ibm,cpr-460ex";
+		dcr-reg = <00c 002>;
+	};
+
+	plb {
+		compatible = "ibm,plb-460ex", "ibm,plb4";
+		#address-cells = <2>;
+		#size-cells = <1>;
+		ranges;
+		clock-frequency = <0>; /* Filled in by U-Boot */
+
+		SDRAM0: sdram {
+			compatible = "ibm,sdram-460ex", "ibm,sdram-405gp";
+			dcr-reg = <010 2>;
+		};
+
+		MAL0: mcmal {
+			compatible = "ibm,mcmal-460ex", "ibm,mcmal2";
+			dcr-reg = <180 62>;
+			num-tx-chans = <2>;
+			num-rx-chans = <10>;
+			#address-cells = <0>;
+			#size-cells = <0>;
+			interrupt-parent = <&UIC2>;
+			interrupts = <	/*TXEOB*/ 6 4
+					/*RXEOB*/ 7 4
+					/*SERR*/  3 4
+					/*TXDE*/  4 4
+					/*RXDE*/  5 4>;
+		};
+
+		POB0: opb {
+			compatible = "ibm,opb-460ex", "ibm,opb";
+			#address-cells = <1>;
+			#size-cells = <1>;
+			ranges = <b0000000 4 b0000000 50000000>;
+			clock-frequency = <0>; /* Filled in by U-Boot */
+
+			EBC0: ebc {
+				compatible = "ibm,ebc-460ex", "ibm,ebc";
+				dcr-reg = <012 2>;
+				#address-cells = <2>;
+				#size-cells = <1>;
+				clock-frequency = <0>; /* Filled in by U-Boot */
+				interrupts = <6 4>;
+				interrupt-parent = <&UIC1>;
+			};
+
+			UART0: serial@ef600300 {
+				device_type = "serial";
+				compatible = "ns16550";
+				reg = <ef600300 8>;
+				virtual-reg = <ef600300>;
+				clock-frequency = <0>; /* Filled in by U-Boot */
+				current-speed = <0>; /* Filled in by U-Boot */
+				interrupt-parent = <&UIC1>;
+				interrupts = <1 4>;
+			};
+
+			UART1: serial@ef600400 {
+				device_type = "serial";
+				compatible = "ns16550";
+				reg = <ef600400 8>;
+				virtual-reg = <ef600400>;
+				clock-frequency = <0>; /* Filled in by U-Boot */
+				current-speed = <0>; /* Filled in by U-Boot */
+				interrupt-parent = <&UIC0>;
+				interrupts = <1 4>;
+			};
+
+			UART2: serial@ef600500 {
+				device_type = "serial";
+				compatible = "ns16550";
+				reg = <ef600500 8>;
+				virtual-reg = <ef600500>;
+				clock-frequency = <0>; /* Filled in by U-Boot */
+				current-speed = <0>; /* Filled in by U-Boot */
+				interrupt-parent = <&UIC1>;
+				interrupts = <1d 4>;
+			};
+
+			UART3: serial@ef600600 {
+				device_type = "serial";
+				compatible = "ns16550";
+				reg = <ef600600 8>;
+				virtual-reg = <ef600600>;
+				clock-frequency = <0>; /* Filled in by U-Boot */
+				current-speed = <0>; /* Filled in by U-Boot */
+				interrupt-parent = <&UIC1>;
+				interrupts = <1e 4>;
+			};
+
+			IIC0: i2c@ef600700 {
+				compatible = "ibm,iic-460ex", "ibm,iic";
+				reg = <ef600700 14>;
+				interrupt-parent = <&UIC0>;
+				interrupts = <2 4>;
+			};
+
+			IIC1: i2c@ef600800 {
+				compatible = "ibm,iic-460ex", "ibm,iic";
+				reg = <ef600800 14>;
+				interrupt-parent = <&UIC0>;
+				interrupts = <3 4>;
+			};
+
+			ZMII0: emac-zmii@ef600d00 {
+				compatible = "ibm,zmii-460ex", "ibm,zmii";
+				reg = <ef600d00 c>;
+			};
+
+			RGMII0: emac-rgmii@ef601500 {
+				compatible = "ibm,rgmii-460ex", "ibm,rgmii";
+				reg = <ef601500 8>;
+				has-mdio;
+			};
+
+			EMAC0: ethernet@ef600e00 {
+				device_type = "network";
+				compatible = "ibm,emac-460ex", "ibm,emac4";
+				interrupt-parent = <&EMAC0>;
+				interrupts = <0 1>;
+				#interrupt-cells = <1>;
+				#address-cells = <0>;
+				#size-cells = <0>;
+				interrupt-map = </*Status*/ 0 &UIC2 10 4
+						 /*Wake*/   1 &UIC2 14 4>;
+				reg = <ef600e00 70>;
+				local-mac-address = [000000000000]; /* Filled in by U-Boot */
+				mal-device = <&MAL0>;
+				mal-tx-channel = <0>;
+				mal-rx-channel = <0>;
+				cell-index = <0>;
+				max-frame-size = <2328>;
+				rx-fifo-size = <1000>;
+				tx-fifo-size = <800>;
+				phy-mode = "rgmii";
+				phy-map = <00000000>;
+				zmii-device = <&ZMII0>;
+				zmii-channel = <0>;
+				rgmii-device = <&RGMII0>;
+				rgmii-channel = <0>;
+				has-inverted-stacr-oc;
+				has-new-stacr-staopc;
+			};
+
+			EMAC1: ethernet@ef600f00 {
+				device_type = "network";
+				compatible = "ibm,emac-460ex", "ibm,emac4";
+				interrupt-parent = <&EMAC1>;
+				interrupts = <0 1>;
+				#interrupt-cells = <1>;
+				#address-cells = <0>;
+				#size-cells = <0>;
+				interrupt-map = </*Status*/ 0 &UIC2 11 4
+						 /*Wake*/   1 &UIC2 15 4>;
+				reg = <ef600f00 70>;
+				local-mac-address = [000000000000]; /* Filled in by U-Boot */
+				mal-device = <&MAL0>;
+				mal-tx-channel = <1>;
+				mal-rx-channel = <8>;
+				cell-index = <1>;
+				max-frame-size = <2328>;
+				rx-fifo-size = <1000>;
+				tx-fifo-size = <800>;
+				phy-mode = "rgmii";
+				phy-map = <00000000>;
+				zmii-device = <&ZMII0>;
+				zmii-channel = <1>;
+				rgmii-device = <&RGMII0>;
+				rgmii-channel = <1>;
+				has-inverted-stacr-oc;
+				has-new-stacr-staopc;
+			};
+		};
+
+		PCIX0: pci@c0ec00000 {
+			device_type = "pci";
+			#interrupt-cells = <1>;
+			#size-cells = <2>;
+			#address-cells = <3>;
+			compatible = "ibm,plb-pcix-460ex", "ibm,plb-pcix";
+			primary;
+			large-inbound-windows;
+			enable-msi-hole;
+			reg = <c 0ec00000   8	/* Config space access */
+			       0 0 0		/* no IACK cycles */
+			       c 0ed00000   4   /* Special cycles */
+			       c 0ec80000 100	/* Internal registers */
+			       c 0ec80100  fc>;	/* Internal messaging registers */
+
+			/* Outbound ranges, one memory and one IO,
+			 * later cannot be changed
+			 */
+			ranges = <02000000 0 80000000 0000000d 80000000 0 80000000
+				  01000000 0 00000000 0000000c 08000000 0 00010000>;
+
+			/* Inbound 2GB range starting at 0 */
+			dma-ranges = <42000000 0 0 0 0 0 80000000>;
+
+			/* This drives busses 0 to 0x3f */
+			bus-range = <0 3f>;
+
+			/* All PCI interrupts are routed to ext IRQ 2 -> UIC1-0 */
+			interrupt-map-mask = <0000 0 0 0>;
+			interrupt-map = < 0000 0 0 0 &UIC1 0 8 >;
+		};
+
+		PCIE0: pciex@d00000000 {
+			device_type = "pci";
+			#interrupt-cells = <1>;
+			#size-cells = <2>;
+			#address-cells = <3>;
+			compatible = "ibm,plb-pciex-460ex", "ibm,plb-pciex";
+			primary;
+			port = <0>; /* port number */
+			reg = <d 00000000 20000000	/* Config space access */
+			       c 08010000 00001000>;	/* Registers */
+			dcr-reg = <100 020>;
+			sdr-base = <300>;
+
+			/* Outbound ranges, one memory and one IO,
+			 * later cannot be changed
+			 */
+			ranges = <02000000 0 80000000 0000000e 00000000 0 80000000
+				  01000000 0 00000000 0000000f 80000000 0 00010000>;
+
+			/* Inbound 2GB range starting at 0 */
+			dma-ranges = <42000000 0 0 0 0 0 80000000>;
+
+			/* This drives busses 40 to 0x7f */
+			bus-range = <40 7f>;
+
+			/* Legacy interrupts (note the weird polarity, the bridge seems
+			 * to invert PCIe legacy interrupts).
+			 * We are de-swizzling here because the numbers are actually for
+			 * port of the root complex virtual P2P bridge. But I want
+			 * to avoid putting a node for it in the tree, so the numbers
+			 * below are basically de-swizzled numbers.
+			 * The real slot is on idsel 0, so the swizzling is 1:1
+			 */
+			interrupt-map-mask = <0000 0 0 7>;
+			interrupt-map = <
+				0000 0 0 1 &UIC3 c 4 /* swizzled int A */
+				0000 0 0 2 &UIC3 d 4 /* swizzled int B */
+				0000 0 0 3 &UIC3 e 4 /* swizzled int C */
+				0000 0 0 4 &UIC3 f 4 /* swizzled int D */>;
+		};
+
+		PCIE1: pciex@d20000000 {
+			device_type = "pci";
+			#interrupt-cells = <1>;
+			#size-cells = <2>;
+			#address-cells = <3>;
+			compatible = "ibm,plb-pciex-460ex", "ibm,plb-pciex";
+			primary;
+			port = <1>; /* port number */
+			reg = <d 20000000 20000000	/* Config space access */
+			       c 08011000 00001000>;	/* Registers */
+			dcr-reg = <120 020>;
+			sdr-base = <340>;
+
+			/* Outbound ranges, one memory and one IO,
+			 * later cannot be changed
+			 */
+			ranges = <02000000 0 80000000 0000000e 80000000 0 80000000
+				  01000000 0 00000000 0000000f 80010000 0 00010000>;
+
+			/* Inbound 2GB range starting at 0 */
+			dma-ranges = <42000000 0 0 0 0 0 80000000>;
+
+			/* This drives busses 80 to 0xbf */
+			bus-range = <80 bf>;
+
+			/* Legacy interrupts (note the weird polarity, the bridge seems
+			 * to invert PCIe legacy interrupts).
+			 * We are de-swizzling here because the numbers are actually for
+			 * port of the root complex virtual P2P bridge. But I want
+			 * to avoid putting a node for it in the tree, so the numbers
+			 * below are basically de-swizzled numbers.
+			 * The real slot is on idsel 0, so the swizzling is 1:1
+			 */
+			interrupt-map-mask = <0000 0 0 7>;
+			interrupt-map = <
+				0000 0 0 1 &UIC3 10 4 /* swizzled int A */
+				0000 0 0 2 &UIC3 11 4 /* swizzled int B */
+				0000 0 0 3 &UIC3 12 4 /* swizzled int C */
+				0000 0 0 4 &UIC3 13 4 /* swizzled int D */>;
+		};
+	};
+};
-- 
1.5.4.3

^ permalink raw reply related


This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox