LinuxPPC-Dev Archive on lore.kernel.org
 help / color / mirror / Atom feed
* [PATCH 2/3] IB/umem: Add hugetlb flag to struct ib_umem
From: Joachim Fenkes @ 2007-09-13 16:15 UTC (permalink / raw)
  To: LinuxPPC-Dev, LKML, OF-General, Roland Dreier, OF-EWG
  Cc: Stefan Roscher, Christoph Raisch
In-Reply-To: <200709131814.13937.fenkes@de.ibm.com>

During ib_umem_get(), determine whether all pages from the memory region are
hugetlb pages and report this in the "hugetlb" field. Low-level driver can
use this information if they need it.

Signed-off-by: Joachim Fenkes <fenkes@de.ibm.com>
---
 drivers/infiniband/core/umem.c |   20 +++++++++++++++++++-
 include/rdma/ib_umem.h         |    1 +
 2 files changed, 20 insertions(+), 1 deletions(-)

diff --git a/drivers/infiniband/core/umem.c b/drivers/infiniband/core/umem.c
index 664d2fa..2f54e29 100644
--- a/drivers/infiniband/core/umem.c
+++ b/drivers/infiniband/core/umem.c
@@ -37,6 +37,7 @@
 #include <linux/mm.h>
 #include <linux/dma-mapping.h>
 #include <linux/sched.h>
+#include <linux/hugetlb.h>
 
 #include "uverbs.h"
 
@@ -75,6 +76,7 @@ struct ib_umem *ib_umem_get(struct ib_ucontext *context, unsigned long addr,
 {
 	struct ib_umem *umem;
 	struct page **page_list;
+	struct vm_area_struct **vma_list;
 	struct ib_umem_chunk *chunk;
 	unsigned long locked;
 	unsigned long lock_limit;
@@ -104,6 +106,9 @@ struct ib_umem *ib_umem_get(struct ib_ucontext *context, unsigned long addr,
 	 */
 	umem->writable  = !!(access & ~IB_ACCESS_REMOTE_READ);
 
+	/* We assume the memory is from hugetlb until proved otherwise */
+	umem->hugetlb   = 1;
+
 	INIT_LIST_HEAD(&umem->chunk_list);
 
 	page_list = (struct page **) __get_free_page(GFP_KERNEL);
@@ -112,6 +117,14 @@ struct ib_umem *ib_umem_get(struct ib_ucontext *context, unsigned long addr,
 		return ERR_PTR(-ENOMEM);
 	}
 
+	/*
+	 * if we can't alloc the vma_list, it's not so bad;
+	 * just assume the memory is not hugetlb memory
+	 */
+	vma_list = (struct vm_area_struct **) __get_free_page(GFP_KERNEL);
+	if (!vma_list)
+		umem->hugetlb = 0;
+
 	npages = PAGE_ALIGN(size + umem->offset) >> PAGE_SHIFT;
 
 	down_write(&current->mm->mmap_sem);
@@ -131,7 +144,7 @@ struct ib_umem *ib_umem_get(struct ib_ucontext *context, unsigned long addr,
 		ret = get_user_pages(current, current->mm, cur_base,
 				     min_t(int, npages,
 					   PAGE_SIZE / sizeof (struct page *)),
-				     1, !umem->writable, page_list, NULL);
+				     1, !umem->writable, page_list, vma_list);
 
 		if (ret < 0)
 			goto out;
@@ -152,6 +165,9 @@ struct ib_umem *ib_umem_get(struct ib_ucontext *context, unsigned long addr,
 
 			chunk->nents = min_t(int, ret, IB_UMEM_MAX_PAGE_CHUNK);
 			for (i = 0; i < chunk->nents; ++i) {
+				if (vma_list &&
+				    !is_vm_hugetlb_page(vma_list[i + off]))
+					umem->hugetlb = 0;
 				chunk->page_list[i].page   = page_list[i + off];
 				chunk->page_list[i].offset = 0;
 				chunk->page_list[i].length = PAGE_SIZE;
@@ -186,6 +202,8 @@ out:
 		current->mm->locked_vm = locked;
 
 	up_write(&current->mm->mmap_sem);
+	if (vma_list)
+		free_page((unsigned long) vma_list);
 	free_page((unsigned long) page_list);
 
 	return ret < 0 ? ERR_PTR(ret) : umem;
diff --git a/include/rdma/ib_umem.h b/include/rdma/ib_umem.h
index c533d6c..2229842 100644
--- a/include/rdma/ib_umem.h
+++ b/include/rdma/ib_umem.h
@@ -45,6 +45,7 @@ struct ib_umem {
 	int			offset;
 	int			page_size;
 	int                     writable;
+	int                     hugetlb;
 	struct list_head	chunk_list;
 	struct work_struct	work;
 	struct mm_struct       *mm;
-- 
1.5.2

^ permalink raw reply related

* [PATCH 1/3] IB/ehca: Fix large page HW cap defines
From: Joachim Fenkes @ 2007-09-13 16:14 UTC (permalink / raw)
  To: LinuxPPC-Dev, LKML, OF-General, Roland Dreier, OF-EWG
  Cc: Stefan Roscher, Christoph Raisch
In-Reply-To: <200709131814.13937.fenkes@de.ibm.com>

From: Hoang-Nam Nguyen <hnguyen@de.ibm.com>

Signed-off-by: Joachim Fenkes <fenkes@de.ibm.com>
---
 drivers/infiniband/hw/ehca/ehca_classes.h |    8 ++++----
 1 files changed, 4 insertions(+), 4 deletions(-)

diff --git a/drivers/infiniband/hw/ehca/ehca_classes.h b/drivers/infiniband/hw/ehca/ehca_classes.h
index 206d4eb..c2edd4c 100644
--- a/drivers/infiniband/hw/ehca/ehca_classes.h
+++ b/drivers/infiniband/hw/ehca/ehca_classes.h
@@ -99,10 +99,10 @@ struct ehca_sport {
 	struct ehca_sma_attr saved_attr;
 };
 
-#define HCA_CAP_MR_PGSIZE_4K  1
-#define HCA_CAP_MR_PGSIZE_64K 2
-#define HCA_CAP_MR_PGSIZE_1M  4
-#define HCA_CAP_MR_PGSIZE_16M 8
+#define HCA_CAP_MR_PGSIZE_4K  0x80000000
+#define HCA_CAP_MR_PGSIZE_64K 0x40000000
+#define HCA_CAP_MR_PGSIZE_1M  0x20000000
+#define HCA_CAP_MR_PGSIZE_16M 0x10000000
 
 struct ehca_shca {
 	struct ib_device ib_device;
-- 
1.5.2

^ permalink raw reply related

* [patch 5/7] Use extended crashkernel command line on ppc64
From: Bernhard Walle @ 2007-09-13 16:14 UTC (permalink / raw)
  To: kexec; +Cc: linux-arch, linuxppc-dev, linux-kernel
In-Reply-To: <20070913161428.343951643@strauss.suse.de>

This patch adapts the ppc64 code to use the generic parse_crashkernel()
function introduced in the generic patch of that series.


Signed-off-by: Bernhard Walle <bwalle@suse.de>

---
 arch/powerpc/kernel/machine_kexec.c |   52 ++++++++++++++++++------------------
 1 file changed, 26 insertions(+), 26 deletions(-)

--- a/arch/powerpc/kernel/machine_kexec.c
+++ b/arch/powerpc/kernel/machine_kexec.c
@@ -61,45 +61,39 @@ NORET_TYPE void machine_kexec(struct kim
 	for(;;);
 }
 
-static int __init early_parse_crashk(char *p)
+void __init reserve_crashkernel(void)
 {
-	unsigned long size;
-
-	if (!p)
-		return 1;
-
-	size = memparse(p, &p);
+	unsigned long long crash_size = 0, crash_base;
+	int ret;
 
-	if (*p == '@')
-		crashk_res.start = memparse(p + 1, &p);
-	else
-		crashk_res.start = KDUMP_KERNELBASE;
-
-	crashk_res.end = crashk_res.start + size - 1;
-
-	return 0;
-}
-early_param("crashkernel", early_parse_crashk);
+	/* this is necessary because of lmb_phys_mem_size() */
+	lmb_analyze();
 
-void __init reserve_crashkernel(void)
-{
-	unsigned long size;
+	/* use common parsing */
+	ret = parse_crashkernel(boot_command_line, lmb_phys_mem_size(),
+			&crash_size, &crash_base);
+	if (ret == 0 && crash_size > 0) {
+		if (crash_base == 0)
+			crash_base = KDUMP_KERNELBASE;
+		crashk_res.start = crash_base;
+	} else {
+		/* handle the device tree */
+		crash_size = crashk_res.end - crashk_res.start + 1;
+	}
 
-	if (crashk_res.start == 0)
+	if (crash_size == 0)
 		return;
 
 	/* We might have got these values via the command line or the
 	 * device tree, either way sanitise them now. */
 
-	size = crashk_res.end - crashk_res.start + 1;
-
 	if (crashk_res.start != KDUMP_KERNELBASE)
 		printk("Crash kernel location must be 0x%x\n",
 				KDUMP_KERNELBASE);
 
 	crashk_res.start = KDUMP_KERNELBASE;
-	size = PAGE_ALIGN(size);
-	crashk_res.end = crashk_res.start + size - 1;
+	crash_size = PAGE_ALIGN(crash_size);
+	crashk_res.end = crashk_res.start + crash_size - 1;
 
 	/* Crash kernel trumps memory limit */
 	if (memory_limit && memory_limit <= crashk_res.end) {
@@ -108,7 +102,13 @@ void __init reserve_crashkernel(void)
 				memory_limit);
 	}
 
-	lmb_reserve(crashk_res.start, size);
+	printk(KERN_INFO "Reserving %ldMB of memory at %ldMB "
+			"for crashkernel (System RAM: %ldMB)\n",
+			(unsigned long)(crash_size >> 20),
+			(unsigned long)(crashk_res.start >> 20),
+			(unsigned long)(lmb_phys_mem_size() >> 20));
+
+	lmb_reserve(crashk_res.start, crash_size);
 }
 
 int overlaps_crashkernel(unsigned long start, unsigned long size)

-- 

^ permalink raw reply

* [PATCH 0/3] IB/ehca: MR/MW fixes
From: Joachim Fenkes @ 2007-09-13 16:14 UTC (permalink / raw)
  To: LinuxPPC-Dev, LKML, OF-General, Roland Dreier, OF-EWG
  Cc: Stefan Roscher, Christoph Raisch

This patchset replaces Nam's previous MR/MW patch (posted by me). I split
the #define fixes into a separate patch and moved the "is the memory from
hugetlbfs?" code into ib_umem_get().

[1/3] fixes the page size HW cap defines
[2/3] adds the hugetlb test to ib_umem_get()
[3/3] finally uses the hugetlb flag in ehca_reg_user_mr()

The patches should apply cleanly, in order, on top of my previous 12-patch
set. Please review the changes and apply the patches for 2.6.24 if they are
okay.

Regards,
  Joachim

=2D-=20
Joachim Fenkes =A0-- =A0eHCA Linux Driver Developer and Hardware Tamer
IBM Deutschland Entwicklung GmbH =A0-- =A0Dept. 3627 (I/O Firmware Dev. 2)
Schoenaicher Strasse 220 =A0-- =A071032 Boeblingen =A0-- =A0Germany
eMail: fenkes@de.ibm.com

^ permalink raw reply

* Re: [PATCH 10/10] mpc82xx: Add pq2fads board support.
From: Scott Wood @ 2007-09-13 16:05 UTC (permalink / raw)
  To: Kumar Gala; +Cc: linuxppc-dev
In-Reply-To: <9BC5B02A-4E9D-42DD-90C3-F8C3382F2A96@kernel.crashing.org>

On Thu, Sep 13, 2007 at 01:39:58AM -0500, Kumar Gala wrote:
> >+	CS: chipselect {
> 
> We need to document this in booting-without-of.

OK.

> >+		PIC: interrupt-controller@10c00 {
> >+			#interrupt-cells = <2>;
> >+			interrupt-controller;
> >+			reg = <10c00 80>;
> >+			compatible = "fsl,mpc8280-pic", "fsl,pq2-pic";
> 
> this should also have a "fsl,cpm2-pic" or something of that form.   
> (exact same pic exists on 8560, 85xx+CPM)

OK...  I did it as pq2 rather than cpm2 because IIRC it wasn't described
under the CPM section of the manual, so I didn't know if 85xx CPM2 had
the same thing.

-Scott

^ permalink raw reply

* [PATCH] ucc_geth: fix compilation
From: Anton Vorontsov @ 2007-09-13 15:23 UTC (permalink / raw)
  To: linuxppc-dev; +Cc: netdev
In-Reply-To: <20070912112456.GA15556@localhost.localdomain>

Currently qe_bd_t is used in the macro call -- dma_unmap_single,
which is a no-op on PPC32, thus error is hidden today. Starting
with 2.6.24, macro will be replaced by the empty static function,
and erroneous use of qe_bd_t will trigger compilation error.

Signed-off-by: Anton Vorontsov <avorontsov@ru.mvista.com>
---

Reposting this to include netdev in Cc.

 drivers/net/ucc_geth.c |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/drivers/net/ucc_geth.c b/drivers/net/ucc_geth.c
index 12e01b2..9a38dfe 100644
--- a/drivers/net/ucc_geth.c
+++ b/drivers/net/ucc_geth.c
@@ -2148,7 +2148,7 @@ static void ucc_geth_memclean(struct ucc_geth_private *ugeth)
 		for (j = 0; j < ugeth->ug_info->bdRingLenTx[i]; j++) {
 			if (ugeth->tx_skbuff[i][j]) {
 				dma_unmap_single(NULL,
-						 ((qe_bd_t *)bd)->buf,
+						 ((struct qe_bd *)bd)->buf,
 						 (in_be32((u32 *)bd) &
 						  BD_LENGTH_MASK),
 						 DMA_TO_DEVICE);
-- 
1.5.0.6

^ permalink raw reply related

* Re: [PATCH 1/5] Add Freescale DMA and DMA channel to Documentation/powerpc/booting-without-of.txt file.
From: Kumar Gala @ 2007-09-13 15:11 UTC (permalink / raw)
  To: Scott Wood; +Cc: linuxppc-dev, David Gibson, paulus, Zhang Wei-r63237
In-Reply-To: <20070913145236.GC32043@ld0162-tx32.am.freescale.net>


On Sep 13, 2007, at 9:52 AM, Scott Wood wrote:

> On Thu, Sep 13, 2007 at 04:09:29AM +0200, Segher Boessenkool wrote:
>>>> I have a strange issue here. If I rename 'fsl,dma' to
>>>> 'fsl,mpc8540-dma',
>>>> the 'fsl,mpc8540-dma-channel' will be also regarded as DMA  
>>>> device not
>>>> DMA channel.

Have we closed on what the device-tree parts for this should look  
like?  I'd like to at least get those parts of this patch into my  
tree if possible for 2.6.24.

- k

^ permalink raw reply

* Re: [PATCH 1/5] Add Freescale DMA and DMA channel to Documentation/powerpc/booting-without-of.txt file.
From: Scott Wood @ 2007-09-13 14:52 UTC (permalink / raw)
  To: Segher Boessenkool; +Cc: linuxppc-dev, Zhang Wei-r63237, paulus, David Gibson
In-Reply-To: <fd81b53021e39a13ea65c0a0319aab77@kernel.crashing.org>

On Thu, Sep 13, 2007 at 04:09:29AM +0200, Segher Boessenkool wrote:
> >>I have a strange issue here. If I rename 'fsl,dma' to 
> >>'fsl,mpc8540-dma',
> >>the 'fsl,mpc8540-dma-channel' will be also regarded as DMA device not
> >>DMA channel.
> >
> >What tree are you using?  Commit 
> >804ace8881d211ac448082e871dd312132393049
> >in Paul's git tree should have fixed that.
> 
> Strange, I don't see that commit -- maybe gitweb is broken, or
> maybe the patch was superseded, or maybe it just disappeared?
> It's still shown in patchworks with this commit id fwiw.

I see it here:
http://git.kernel.org/?p=linux/kernel/git/paulus/powerpc.git;a=commit;h=804ace8881d211ac448082e871dd312132393049

-Scott

^ permalink raw reply

* Re: [PATCH 5/5] Add DMA engine driver for Freescale MPC85xxprocessors.
From: Scott Wood @ 2007-09-13 14:49 UTC (permalink / raw)
  To: Zhang Wei-r63237
  Cc: linuxppc-dev, dan.j.williams, shannon.nelson, paulus,
	linux-kernel
In-Reply-To: <46B96294322F7D458F9648B60E15112C85D8A5@zch01exm26.fsl.freescale.net>

On Thu, Sep 13, 2007 at 03:13:06AM -0700, Zhang Wei-r63237 wrote:
> > After dropping the lock, you can no longer assume that your 
> > iterator is
> > still valid; you need to work off of the list head.
> > 
> 
> list_for_each_entry_safe() is used here. I think the safe should be ok.
> :P

Nope.  The safety is against the particular item you're iterating on
being removed; it doesn't protect against the *next* entry being removed
when you drop the lock.

> > Why not use an array of channels?
> 
> The list is used in dma engine core file. And it's possible that there
> are not all channel listed in dts and array.

I'm not sure I understand what you mean by the latter comment...

> > You could have the features be part of the match struct, so 
> > you don't have
> > to do extra strcmps.
> > 
> 
> Can I use the data field of struct of_device_id?

Yes, that's what it's there for. :-)

> > > +static struct of_device_id of_fsl_dma_ids[] = {
> > > +	{ .compatible = "fsl,dma", },
> > > +};
> > 
> > Why do we need to bind to the parent node at all?
> 
> Yes, the MPC83xx should get interrupt source from DMA device register.

You don't need to bind to it for that, though -- just call of_get_parent
from the channel probe.  Though it might be easier to bind to the parent
to ensure that you only register the IRQ once.

-Scott

^ permalink raw reply

* Re: [PATCH 2/9] 8xx: Infrastructure code cleanup.
From: Scott Wood @ 2007-09-13 14:40 UTC (permalink / raw)
  To: galak, linuxppc-dev
In-Reply-To: <20070913071125.GC24281@localhost.localdomain>

On Thu, Sep 13, 2007 at 05:11:25PM +1000, David Gibson wrote:
> > -#define immr_unmap(addr)		iounmap(addr)
> > +#define immr_map(member) (&mpc8xx_immr->member)
> > +#define immr_map_size(member, size) (&mpc8xx_immr->member)
> > +#define immr_unmap(addr) iounmap(addr)
> 
> This looks bogus.  You're replacing the old crap immr_map() functions,
> which ioremap()ed the registers every time, with a much simpler
> version which uses an established-once mapping of the register
> region.  AFAICT, anywah.
> 
> So far, so good - but your immr_unmap() still does an iounmap() which
> is surely wrong - it should now be a no-op, leaving the mpc8xx_immr
> mapping intact.  You probably get away with it by accident, because I
> imagine attempting to unmap an unaligned chunk of the region will just
> fail.

D'oh!  Thanks for pointing that out.

-Scott

^ permalink raw reply

* Re: [PATCH] IB/ehca: Make sure user pages are from hugetlb before using MR large pages
From: Joachim Fenkes @ 2007-09-13 14:27 UTC (permalink / raw)
  To: Roland Dreier
  Cc: OF-EWG, LKML, LinuxPPC-Dev, Christoph Raisch, OF-General,
	Stefan Roscher
In-Reply-To: <adaps0nmbfa.fsf@cisco.com>

Roland Dreier <rdreier@cisco.com> wrote on 13.09.2007 06:33:45:

>  > -#define HCA_CAP_MR_PGSIZE_4K  1
>  > -#define HCA_CAP_MR_PGSIZE_64K 2
>  > -#define HCA_CAP_MR_PGSIZE_1M  4
>  > -#define HCA_CAP_MR_PGSIZE_16M 8
>  > +#define HCA_CAP_MR_PGSIZE_4K  0x80000000
>  > +#define HCA_CAP_MR_PGSIZE_64K 0x40000000
>  > +#define HCA_CAP_MR_PGSIZE_1M  0x20000000
>  > +#define HCA_CAP_MR_PGSIZE_16M 0x10000000
> 
> Not sure I understand what this has to do with things... is this an
> unrelated fix?

Kinda. I can put it into its own patch if you want.
 
> I would suggest extending ib_umem_get() to check the vmas and adding a
> member to struct ib_umem to say whether the memory is entirely covered
> by hugetlb pages or not.

I like that approach - one patch coming right up! =)
 
>  > +      default: /* out of mem */
>  > +         ib_mr = ERR_PTR(-ENOMEM);
>  > +         goto reg_user_mr_exit1;
> 
> It seems like it would be better to just assume the memory is not from
> a hugetlb is ehca_is_mem_hugetlb() fails its memory allocation and
> fall back to the PAGE_SIZE case rather than failing entirely.

If ehca_is_mem_hugetlb() runs out of memory, ehca_reg_mr() is rather 
unlikely to get the memory, but it's worth a try, I'll give you that. I'll 
make the umem patch work that way.

Joachim

^ permalink raw reply

* Re: Informations about mem and proc environment between bootloader and kernel
From: raul.moreno @ 2007-09-13 14:23 UTC (permalink / raw)
  To: fabien boucher
  Cc: linuxppc-embedded-bounces+raul.moreno=telvent.abengoa.com,
	linuxppc-embedded
In-Reply-To: <f8f856500709130705t2109e559v19f0ffac318a4756@mail.gmail.com>

Hello Fabien,

you should download the U-boot sources from sourceforge.net. There is a=

README file there where you can read about porting U-boot.
The porting to a custom board of U-boot is easier when your cpu is incl=
ude,
like in your case (mpc8xx). Basically you have to create a new entry in=

board directory. There you have to insert the initialization code for y=
our
flash, sdram and other devices. You also have to make a file as the one=
s in
/include/configs/ with your configuration board.

It is essential to have correct environment variables when Linux takes =
the
control.
If you use the u-boot command "bootm" in order to boot Linux, the file
where U-Boot transfer the control to Linux is /common/cmd_bootm.c.

Moreover I would recommend you a book which explains many things regard=
ing
porting Linux (and U-boot):
Embedded Linux Primer: A practical, real-world  approach.

Cheers,

Ra=FAl Moreno



Ra=FAl Moreno Beltr=E1n
Telvent Energ=EDa, S. A.
Divisi=F3n de Tecnolog=EDa. Desarrollo Software
Tlfo: 954935670



"fabien boucher" <fabien.fb@gmail.com>
"fabien boucher"
Enviado por:
linuxppc-embedded-bounces+raul.moreno=3Dtelvent.abengoa.com@ozlabs.org
13/09/2007 16:05
                                                                       =
                                                
 Para:   linuxppc-embedded@ozlabs.org                                  =
                                                
                                                                       =
                                                
 cc:                                                                   =
                                                
                                                                       =
                                                
 Asunto: Informations about mem and proc environment between bootloader=
 and     kernel                                 
                                                                       =
                                                





And I need some help for my project (I'm in internship) to port linux o=
n a
custom board.
This board has been developped by the company where i'm doing the inter=
ship
and it's
based on a MPC875 with RAM and Flash chips and several other devices.
Currently the board run with a BSP developped
by the company's developpers, the BSP launch Psos.
This BSP is able to decompress an image and load it in RAM.
I plan to use U-boot to be more able to boot a kernel but as it's not a=

common
board so it's not initialy supported by U-boot. So I have two choices f=
irst
use the BSP with some changes to adapt it for loading the Linux kernel =
or
using U-boot.
I'm looking for informations about the memory and processor environment=

needed by linux to
boot properly for evaluate whether the use of a customize BSP is the
easiest way against
the port of a new board under U-boot. So if someone know where i can fo=
und
those informations
concerning the step between where the boot program have control of the =
cpu
and where Linux
take control.

Thank you,
Fabien
_______________________________________________
Linuxppc-embedded mailing list
Linuxppc-embedded@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-embedded=

^ permalink raw reply

* Re: Flash on ep8248e standard motherboards
From: Ben Warren @ 2007-09-13 14:10 UTC (permalink / raw)
  To: Erik Christiansen; +Cc: linuxppc-embedded
In-Reply-To: <20070913082558.GB8968@dd.nec.com.au>

Erik Christiansen wrote:
> On Tue, Sep 04, 2007 at 12:08:47PM -0600, Alan Bennett wrote:
>   
>> BDI 2000 Config File:
>>   ;  initialize - FLASH BR0 & OR0 (64 Mbyte)
>>   ;*******************************************
>>   WM32    0xf0010100     0xfc001801
>>   WM32     0xf0010104     0xfc0008c2
>>   [FLASH]
>>   CHIPTYPE    MIRRORX16
>>   CHIPSIZE    0x2000000
>>   BUSWIDTH    16
>>     
>
> Having just taken delivery of an ep8248e, I'm surprised that the
> supplied flash config is commented out and erroneous:
>
> [FLASH]
> ;CHIPTYPE    AM29F       ;Flash type (AM29F | AM29BX8 | AM29BX16 | I28BX8 | I28BX16)
> ;CHIPSIZE    0x200000    ;The size of one flash chip in bytes (e.g. AM29F010 = 0x20000)
> ;BUSWIDTH    8           ;The width of the flash memory bus in bits (8 | 16 | 32 | 64)
> ;
>
> Did you start with the Embedded Planet offering, in your current effort
> to create a usable config? Is MIRRORX16 more than a guess?
>
> I've found that my flash chips are "spansion GL256N10FFI02", which
> AFAICT are S29GL256N10FFI02 from AMD, as we used to know them.
> I wonder if S29M32X16 is a likely guess for CHIPTYPE on the card which
> has landed in my lap?
>
>   
MIRRORX16 is the correct type for Spansion GL series NOR flash. AMD spun 
off their flash business a while ago and renamed it Spansion. If you 
look on the datasheet you'll see that Spansion calls the GL technology 
'MirrorBit', and in all likelihood the device has a 16-bit data bus. The 
AMD algorithm may work but the MIRRORX16 definitely will.

regards,
Ben

^ permalink raw reply

* Re: [PATCH 1/2] [POWERPC] Add SCC clock support to cpm2_clk_setup()
From: Kumar Gala @ 2007-09-13 14:16 UTC (permalink / raw)
  To: Laurent Pinchart; +Cc: linuxppc-embedded
In-Reply-To: <200709131553.11853.laurentp@cse-semaphore.com>


On Sep 13, 2007, at 8:53 AM, Laurent Pinchart wrote:

> On Wednesday 11 July 2007 15:17, Laurent Pinchart wrote:
>> cpm2_clk_setup() supports setting FCC clocks only, even though the
>> cpm_clk_target enumeration lists SCC clocks. This patch adds SCC  
>> clock
>> support.
>
> Any chance this patch (and its 2/2 brother) could be committed ?

Have you looked at Scott Wood's cleanup patches.  They seem to do  
some of this.

- k

^ permalink raw reply

* Informations about mem and proc environment between bootloader and kernel
From: fabien boucher @ 2007-09-13 14:05 UTC (permalink / raw)
  To: linuxppc-embedded

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

And I need some help for my project (I'm in internship) to port linux on a
custom board.
This board has been developped by the company where i'm doing the intership
and it's
based on a MPC875 with RAM and Flash chips and several other devices.
Currently the board run with a BSP developped
by the company's developpers, the BSP launch Psos.
This BSP is able to decompress an image and load it in RAM.
I plan to use U-boot to be more able to boot a kernel but as it's not a
common
board so it's not initialy supported by U-boot. So I have two choices first
use the BSP with some changes to adapt it for loading the Linux kernel or
using U-boot.
I'm looking for informations about the memory and processor environment
needed by linux to
boot properly for evaluate whether the use of a customize BSP is the easiest
way against
the port of a new board under U-boot. So if someone know where i can found
those informations
concerning the step between where the boot program have control of the cpu
and where Linux
take control.

Thank you,
Fabien

[-- Attachment #2: Type: text/html, Size: 1130 bytes --]

^ permalink raw reply

* Re: [PATCH 1/2] [POWERPC] Add SCC clock support to cpm2_clk_setup()
From: Laurent Pinchart @ 2007-09-13 13:53 UTC (permalink / raw)
  To: linuxppc-embedded
In-Reply-To: <200707111517.52663.laurent.pinchart@technotrade.biz>

On Wednesday 11 July 2007 15:17, Laurent Pinchart wrote:
> cpm2_clk_setup() supports setting FCC clocks only, even though the
> cpm_clk_target enumeration lists SCC clocks. This patch adds SCC clock
> support.

Any chance this patch (and its 2/2 brother) could be committed ?

Best regards,

=2D-=20
Laurent Pinchart
CSE Semaphore Belgium

Chauss=E9e de Bruxelles, 732A
B-1410 Waterloo
Belgium

T +32 (2) 387 42 59
=46 +32 (2) 387 42 75

^ permalink raw reply

* Re: oftree and external connected devices
From: Olof Johansson @ 2007-09-13 13:29 UTC (permalink / raw)
  To: Juergen Beisert; +Cc: linuxppc-dev
In-Reply-To: <200709131326.27325.jbe@pengutronix.de>

On Thu, Sep 13, 2007 at 01:26:26PM +0200, Juergen Beisert wrote:
> Hi,
> 
> I'm using an MPC5200B based system with various external connected devices to 
> its LocalPlusBus. On other architectures I would register them as platform 
> devices (no chance to autodetect these devices). But on PowerPC architecture?

If it's a special case of something that it's unlikely that you'll reuse
the driver for, I'd say go ahead with a platform driver. There's nothing in the
PPC kernel that stops it from working.

We're just trying to avoid it for common devices that platforms might share,
and instead of describing hardware in the platform devices setup, describe it
in the device tree instead.

So it depends on how much work you want to invest in it, and if you're
planning on ever submitting the driver upstream. If you are, going
with a simple device tree definiton would be best (the kernel side,
to move a platform driver to instead be an of_platform driver is easy,
and can be done afterwards).

> Is the oftree description also intended to describe these kind of external 
> devices, or only SoC's internal devices? If its also intended for external 
> devices, how to do so? Are there any examples? I didn't find anything useful 
> yet.

It can be used to describe on-board or off-board devices alike.


-Olof

^ permalink raw reply

* Re: [PATCH 15/15] Add DEFINE_SPUFS_ATTRIBUTE()
From: Arnd Bergmann @ 2007-09-13 12:17 UTC (permalink / raw)
  To: michael; +Cc: linuxppc-dev, Jeremy Kerr, linux-kernel
In-Reply-To: <1189649141.19087.13.camel@concordia.ozlabs.ibm.com>

On Thursday 13 September 2007, Michael Ellerman wrote:
> Well that'd be nice, but I don't see anywhere that that happens. AFAICT
> the acquire we do in the first coredump callback is the first the SPU
> contexts know about their PPE process dying. And spufs is still live, so
> I think we definitely need to grab the mutex, or we might race with
> userspace accessing spufs files.

Right, I was only thinking about the dumping process itself, but there
may be other processes that still have files open for that context.

	Arnd <><

^ permalink raw reply

* oftree and external connected devices
From: Juergen Beisert @ 2007-09-13 11:26 UTC (permalink / raw)
  To: linuxppc-dev

Hi,

I'm using an MPC5200B based system with various external connected devices =
to=20
its LocalPlusBus. On other architectures I would register them as platform=
=20
devices (no chance to autodetect these devices). But on PowerPC architectur=
e?

Is the oftree description also intended to describe these kind of external=
=20
devices, or only SoC's internal devices? If its also intended for external=
=20
devices, how to do so? Are there any examples? I didn't find anything usefu=
l=20
yet.

Juergen
=2D-=20
Dipl.-Ing. Juergen Beisert | http://www.pengutronix.de
=A0Pengutronix - Linux Solutions for Science and Industry
=A0   Handelsregister: Amtsgericht Hildesheim, HRA 2686
=A0 =A0 =A0    Vertretung Sued/Muenchen, Germany
   Phone: +49-8766-939 228 |  Fax: +49-5121-206917-9

^ permalink raw reply

* Re: Define termios_1 functions for powerpc, s390, avr32 and frv
From: Andrew Morton @ 2007-09-13 10:55 UTC (permalink / raw)
  To: Paul Mundt
  Cc: Michael Neuling, hskinnemoen, Jan Dittmer, heiko.carstens,
	linux-kernel, linuxppc-dev, Mackerras, Alan Cox, Paul,
	Linus Torvalds, davem
In-Reply-To: <20070913095346.GA28194@linux-sh.org>

On Thu, 13 Sep 2007 18:53:46 +0900 Paul Mundt <lethal@linux-sh.org> wrote:

> On Thu, Sep 13, 2007 at 05:22:36PM +1000, Michael Neuling wrote:
> > > > Commit f629307c857c030d5a3dd777fee37c8bb395e171 introduced uses of
> > > > kernel_termios_to_user_termios_1 and user_termios_to_kernel_termios_1
> > > > on all architectures.  However, powerpc, s390, avr32 and frv don't
> > > > currently define those functions since their termios struct didn't
> > > > need to be changed when the arbitrary baud rate stuff was added, and
> > > > thus the kernel won't currently build on those architectures.
> > > 
> > > alpha, parisc, sh, sparc{64,}, xtensa are still broken with this error...
> > 
> > They need to include <asm-generic/termios.h> in asm-<arch>/termios.h
> > like in powerpc.
> > 
> > Alternatively tonyb's patch should fix them.  Could also do that?
> > 
> Is there a consensus for this? It's a bit annoying to have this stuff
> broken this late in 2.6.23. If Tony's patch gets applied, then this stuff
> will work itself out. Otherwise everything has to be patched for
> asm-generic/termios.h. In which case.. here's the patch to define them on
> sh and sh64.

I think we need to go with Tony's patch.  sparc32 and sparc64 are
presently broken too, and the patch which converts sparc to use the
new interfaces introduces a few build errors.


From: Tony Breeds <tony@bakeyournoodle.com>

Add Guards around TIOCSLCKTRMIOS and TIOCGLCKTRMIOS.

Signed-off-by: Tony Breeds <tony@bakeyournoodle.com>
Cc: Alan Cox <alan@lxorguk.ukuu.org.uk>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Paul Mackerras <paulus@samba.org>
Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Cc: Heiko Carstens <heiko.carstens@de.ibm.com>
Cc: "David S. Miller" <davem@davemloft.net>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
---

 drivers/char/tty_ioctl.c |   14 ++++++++++++++
 1 file changed, 14 insertions(+)

diff -puN drivers/char/tty_ioctl.c~sparc64-and-others-fix-tty_ioctlc-build drivers/char/tty_ioctl.c
--- a/drivers/char/tty_ioctl.c~sparc64-and-others-fix-tty_ioctlc-build
+++ a/drivers/char/tty_ioctl.c
@@ -795,6 +795,19 @@ int n_tty_ioctl(struct tty_struct * tty,
 			if (L_ICANON(tty))
 				retval = inq_canon(tty);
 			return put_user(retval, (unsigned int __user *) arg);
+#ifndef TCGETS2
+		case TIOCGLCKTRMIOS:
+			if (kernel_termios_to_user_termios((struct termios __user *)arg, real_tty->termios_locked))
+				return -EFAULT;
+			return 0;
+
+		case TIOCSLCKTRMIOS:
+			if (!capable(CAP_SYS_ADMIN))
+				return -EPERM;
+			if (user_termios_to_kernel_termios(real_tty->termios_locked, (struct termios __user *) arg))
+				return -EFAULT;
+			return 0;
+#else
 		case TIOCGLCKTRMIOS:
 			if (kernel_termios_to_user_termios_1((struct termios __user *)arg, real_tty->termios_locked))
 				return -EFAULT;
@@ -806,6 +819,7 @@ int n_tty_ioctl(struct tty_struct * tty,
 			if (user_termios_to_kernel_termios_1(real_tty->termios_locked, (struct termios __user *) arg))
 				return -EFAULT;
 			return 0;
+#endif
 
 		case TIOCPKT:
 		{
_

^ permalink raw reply

* Re: Define termios_1 functions for powerpc, s390, avr32 and frv
From: Paul Mundt @ 2007-09-13  9:53 UTC (permalink / raw)
  To: Michael Neuling
  Cc: hskinnemoen, Jan Dittmer, heiko.carstens, linux-kernel,
	linuxppc-dev, Paul Mackerras, Alan Cox, akpm, Linus Torvalds,
	davem
In-Reply-To: <5058.1189668156@neuling.org>

On Thu, Sep 13, 2007 at 05:22:36PM +1000, Michael Neuling wrote:
> > > Commit f629307c857c030d5a3dd777fee37c8bb395e171 introduced uses of
> > > kernel_termios_to_user_termios_1 and user_termios_to_kernel_termios_1
> > > on all architectures.  However, powerpc, s390, avr32 and frv don't
> > > currently define those functions since their termios struct didn't
> > > need to be changed when the arbitrary baud rate stuff was added, and
> > > thus the kernel won't currently build on those architectures.
> > 
> > alpha, parisc, sh, sparc{64,}, xtensa are still broken with this error...
> 
> They need to include <asm-generic/termios.h> in asm-<arch>/termios.h
> like in powerpc.
> 
> Alternatively tonyb's patch should fix them.  Could also do that?
> 
Is there a consensus for this? It's a bit annoying to have this stuff
broken this late in 2.6.23. If Tony's patch gets applied, then this stuff
will work itself out. Otherwise everything has to be patched for
asm-generic/termios.h. In which case.. here's the patch to define them on
sh and sh64.

Signed-off-by: Paul Mundt <lethal@linux-sh.org>

--

 include/asm-sh/termios.h   |   34 +---------------------------------
 include/asm-sh64/termios.h |   34 +---------------------------------
 2 files changed, 2 insertions(+), 66 deletions(-)

diff --git a/include/asm-sh/termios.h b/include/asm-sh/termios.h
index e7c8f86..c57f74e 100644
--- a/include/asm-sh/termios.h
+++ b/include/asm-sh/termios.h
@@ -49,39 +49,7 @@ struct termio {
 */
 #define INIT_C_CC "\003\034\177\025\004\0\1\0\021\023\032\0\022\017\027\026\0"
 
-/*
- * Translate a "termio" structure into a "termios". Ugh.
- */
-#define SET_LOW_TERMIOS_BITS(termios, termio, x) { \
-	unsigned short __tmp; \
-	get_user(__tmp,&(termio)->x); \
-	*(unsigned short *) &(termios)->x = __tmp; \
-}
-
-#define user_termio_to_kernel_termios(termios, termio) \
-({ \
-	SET_LOW_TERMIOS_BITS(termios, termio, c_iflag); \
-	SET_LOW_TERMIOS_BITS(termios, termio, c_oflag); \
-	SET_LOW_TERMIOS_BITS(termios, termio, c_cflag); \
-	SET_LOW_TERMIOS_BITS(termios, termio, c_lflag); \
-	copy_from_user((termios)->c_cc, (termio)->c_cc, NCC); \
-})
-
-/*
- * Translate a "termios" structure into a "termio". Ugh.
- */
-#define kernel_termios_to_user_termio(termio, termios) \
-({ \
-	put_user((termios)->c_iflag, &(termio)->c_iflag); \
-	put_user((termios)->c_oflag, &(termio)->c_oflag); \
-	put_user((termios)->c_cflag, &(termio)->c_cflag); \
-	put_user((termios)->c_lflag, &(termio)->c_lflag); \
-	put_user((termios)->c_line,  &(termio)->c_line); \
-	copy_to_user((termio)->c_cc, (termios)->c_cc, NCC); \
-})
-
-#define user_termios_to_kernel_termios(k, u) copy_from_user(k, u, sizeof(struct termios))
-#define kernel_termios_to_user_termios(u, k) copy_to_user(u, k, sizeof(struct termios))
+#include <asm-generic/termios.h>
 
 #endif	/* __KERNEL__ */
 
diff --git a/include/asm-sh64/termios.h b/include/asm-sh64/termios.h
index dc44e6e..b61ce95 100644
--- a/include/asm-sh64/termios.h
+++ b/include/asm-sh64/termios.h
@@ -60,39 +60,7 @@ struct termio {
 */
 #define INIT_C_CC "\003\034\177\025\004\0\1\0\021\023\032\0\022\017\027\026\0"
 
-/*
- * Translate a "termio" structure into a "termios". Ugh.
- */
-#define SET_LOW_TERMIOS_BITS(termios, termio, x) { \
-	unsigned short __tmp; \
-	get_user(__tmp,&(termio)->x); \
-	*(unsigned short *) &(termios)->x = __tmp; \
-}
-
-#define user_termio_to_kernel_termios(termios, termio) \
-({ \
-	SET_LOW_TERMIOS_BITS(termios, termio, c_iflag); \
-	SET_LOW_TERMIOS_BITS(termios, termio, c_oflag); \
-	SET_LOW_TERMIOS_BITS(termios, termio, c_cflag); \
-	SET_LOW_TERMIOS_BITS(termios, termio, c_lflag); \
-	copy_from_user((termios)->c_cc, (termio)->c_cc, NCC); \
-})
-
-/*
- * Translate a "termios" structure into a "termio". Ugh.
- */
-#define kernel_termios_to_user_termio(termio, termios) \
-({ \
-	put_user((termios)->c_iflag, &(termio)->c_iflag); \
-	put_user((termios)->c_oflag, &(termio)->c_oflag); \
-	put_user((termios)->c_cflag, &(termio)->c_cflag); \
-	put_user((termios)->c_lflag, &(termio)->c_lflag); \
-	put_user((termios)->c_line,  &(termio)->c_line); \
-	copy_to_user((termio)->c_cc, (termios)->c_cc, NCC); \
-})
-
-#define user_termios_to_kernel_termios(k, u) copy_from_user(k, u, sizeof(struct termios))
-#define kernel_termios_to_user_termios(u, k) copy_to_user(u, k, sizeof(struct termios))
+#include <asm-generic/termios.h>
 
 #endif	/* __KERNEL__ */
 

^ permalink raw reply related

* RE: [PATCH 5/5] Add DMA engine driver for Freescale MPC85xxprocessors.
From: Zhang Wei-r63237 @ 2007-09-13 10:13 UTC (permalink / raw)
  To: Wood Scott-B07421, dan.j.williams
  Cc: linuxppc-dev, shannon.nelson, paulus, linux-kernel
In-Reply-To: <20070907223553.GA18599@freescale.com>

Hi,=20

> > +static void fsl_dma_set_src(dma_addr_t addr,
> > +				struct dma_async_tx_descriptor=20
> *tx, int index)
> > +{
>=20
> What is index supposed to mean?  It's not used, or documented=20
> anywhere than
> I can see.

I've also got more document here. Hi, Dan, could you give me some
explanation about this API? :)

>=20
> > +		else {
> > +			/* Run the link descriptor callback function */
> > +			if (desc->async_tx.callback) {
> > +			=09
> spin_unlock_irqrestore(&fsl_chan->desc_lock,
> > +								flags);
> > +				dev_dbg(fsl_chan->device->dev,
> > +					"link descriptor %p=20
> callback\n", desc);
> > +				desc->async_tx.callback(
> > +					=09
> desc->async_tx.callback_param);
> > +			=09
> spin_lock_irqsave(&fsl_chan->desc_lock, flags);
>=20
> After dropping the lock, you can no longer assume that your=20
> iterator is
> still valid; you need to work off of the list head.
>=20

list_for_each_entry_safe() is used here. I think the safe should be ok.
:P

> > +	/* Find the first un-transfer desciptor */
> > +	for (ld_node =3D fsl_chan->ld_queue.next;
> > +		(ld_node !=3D &fsl_chan->ld_queue)
> > +			&& (DMA_SUCCESS =3D=3D dma_async_is_complete(
> > +				=09
> to_fsl_desc(ld_node)->async_tx.cookie,
> > +					fsl_chan->completed_cookie,
> > +					fsl_chan->common.cookie));
> > +		ld_node =3D ld_node->next);
>=20
> Call fsl_dma_is_complete directly, don't waste time going through the
> virtual call.
>=20
> And you have a recursive lock usage here; fsl_dma_is_complete calls
> fsl_chan_ld_cleanup, which acquires desc_lock, but you=20
> already have it.
>=20
> Couldn't you just call fsl_chan_ld_cleanup, and then check=20
> what's at the
> head of the list?
>=20

I'll split interrupt and poll here.

> > +static irqreturn_t fsl_dma_do_interrupt(int irq, void *data)
> > +{
> > +	struct fsl_dma_device *fdev =3D (struct fsl_dma_device *)data;
> > +	struct fsl_dma_chan *fsl_chan =3D NULL;
> > +	u32 gsr;
> > +	int ch_nr;
> > +	struct dma_chan *int_chan;
> > +
> > +	gsr =3D (fdev->feature & FSL_DMA_BIG_ENDIAN) ?=20
> in_be32(fdev->reg_base)
> > +			: in_le32(fdev->reg_base);
> > +	ch_nr =3D (32 - ffs(gsr)) / 8;
> > +
> > +	list_for_each_entry(int_chan, &fdev->common.channels,=20
> device_node)
> > +		if (to_fsl_chan(int_chan)->id =3D=3D ch_nr)
> > +			fsl_chan =3D to_fsl_chan(int_chan);
>=20
> Why not use an array of channels?

The list is used in dma engine core file. And it's possible that there
are not all channel listed in dts and array.

> > +
> > +	return fsl_chan ? fsl_dma_chan_do_interrupt(irq,=20
> fsl_chan) : IRQ_NONE;
> > +
> > +}
> > +
> > +static void dma_do_tasklet(unsigned long unused)
> > +{
> > +	struct fsl_desc_sw *desc, *_desc;
> > +	unsigned long flags;
> > +
> > +	spin_lock_irqsave(&recy_ln_lock, flags);
> > +	list_for_each_entry_safe(desc, _desc, &recy_ln_chain, node) {
> > +		struct fsl_dma_chan *fsl_chan =3D
> > +				=09
> to_fsl_chan(desc->async_tx.chan);
> > +		/* Run the link descriptor callback function */
> > +		if (desc->async_tx.callback) {
> > +			spin_unlock_irqrestore(&recy_ln_lock, flags);
> > +			dev_dbg(fsl_chan->device->dev,
> > +				"dma_tasklet: link descriptor=20
> %p callback\n",
> > +				desc);
> > +			desc->async_tx.callback(
> > +					desc->async_tx.callback_param);
> > +			spin_lock_irqsave(&recy_ln_lock, flags);
> > +		}
> > +		/* Recycle it! */
> > +		list_del(&desc->node);
>=20
> You should remove it from the list before dropping the lock,=20
> as otherwise
> something else could come along and remove it again.

All right!

>=20
> > +	if (strcmp(match->compatible, "fsl,mpc8540-dma-channel") =3D=3D 0)
> > +		new_fsl_chan->feature =3D FSL_DMA_IP_86XX |=20
> FSL_DMA_BIG_ENDIAN;
>=20
> Shouldn't it be 85XX, to be consistent?
>=20
> > +	else if (strcmp(match->compatible,=20
> "fsl,mpc8349-dma-channel") =3D=3D 0)
> > +		new_fsl_chan->feature =3D FSL_DMA_IP_83XX |=20
> FSL_DMA_LITTLE_ENDIAN;
>=20
> You could have the features be part of the match struct, so=20
> you don't have
> to do extra strcmps.
>=20

Can I use the data field of struct of_device_id?

>=20
> > +static struct of_device_id of_fsl_dma_ids[] =3D {
> > +	{ .compatible =3D "fsl,dma", },
> > +};
>=20
> Why do we need to bind to the parent node at all?

Yes, the MPC83xx should get interrupt source from DMA device register.

>=20
> > +/* There is no asm instructions for 64 bits reverse loads=20
> and stores */
> > +static u64 in_le64(const u64 __iomem *addr)
> > +{
> > +	return le64_to_cpu(in_be64(addr));
> > +}
> > +
> > +static void out_le64(u64 __iomem *addr, u64 val)
> > +{
> > +	out_be64(addr, cpu_to_le64(val));
> > +}
> > +#endif
>=20
> You can use asm instructions for this, as such:

Aha, they are just copied from io.h.

>=20
> static u64 in_le64(const u64 __iomem *addr)
> {
> 	return ((u64)in_le32((u32 *)addr + 1) << 32) |=20
> (in_le32((u32 *)addr));
> }
>=20
>=20
> static void out_le64(u64 __iomem *addr, u64 val)
> {
> 	out_le32((u32 *)addr, (u32)val);
> 	out_le32((u32 *)addr + 1, val >> 32);
> }
>=20

And I agree with your other comments.

Thanks a lot!
- zw

^ permalink raw reply

* Re: [PATCH 00/10] x86: Reduce Memory Usage and Inter-Node message traffic (v3)
From: Andi Kleen @ 2007-09-13  9:53 UTC (permalink / raw)
  To: travis
  Cc: linux-mm, linux-kernel, linuxppc-dev, sparclinux, Andrew Morton,
	Christoph Lameter
In-Reply-To: <20070912015644.927677070@sgi.com>

On Wednesday 12 September 2007 03:56, travis@sgi.com wrote:
> Note:
>
> This patch consolidates all the previous patches regarding
> the conversion of static arrays sized by NR_CPUS into per_cpu
> data arrays and is referenced against 2.6.23-rc6 .


Looks good to me from the x86 side. I'll leave it to Andrew to
handle for now though because it touches too many files
outside x86.

-Andi

^ permalink raw reply

* Re: [PATCH] IB/ehca: Make sure user pages are from hugetlb before using MR large pages
From: Christoph Raisch @ 2007-09-13  9:49 UTC (permalink / raw)
  To: Roland Dreier
  Cc: Joachim Fenkes, OF-EWG, LKML, LinuxPPC-Dev, Hoang-Nam Nguyen,
	OF-General, Stefan Roscher
In-Reply-To: <adaps0nmbfa.fsf@cisco.com>

Roland Dreier wrote on 13.09.2007 06:33:45:

>
> Also if someone runs a kernel with 64K pages on a machine where they
> end up being simulated from 4K pages, do you have the same issue with
> the hypervisor ganging together non-contiguous pages?
With todays hypervisor and todays pagesizes and todays MMUs
we don't have this problem if eHCA is enabled.

It is difficult to make predictions about the future,
but that's not specific to driver development. ;-)

>
>  - R.

 - Christoph R.

^ permalink raw reply

* Re: Flash on ep8248e standard motherboards
From: Erik Christiansen @ 2007-09-13  8:25 UTC (permalink / raw)
  To: linuxppc-embedded
In-Reply-To: <bfa0697f0709041108u2c6b719dj600cb2eb25b66a4a@mail.gmail.com>

On Tue, Sep 04, 2007 at 12:08:47PM -0600, Alan Bennett wrote:
> BDI 2000 Config File:
>   ;  initialize - FLASH BR0 & OR0 (64 Mbyte)
>   ;*******************************************
>   WM32    0xf0010100     0xfc001801
>   WM32     0xf0010104     0xfc0008c2
>   [FLASH]
>   CHIPTYPE    MIRRORX16
>   CHIPSIZE    0x2000000
>   BUSWIDTH    16

Having just taken delivery of an ep8248e, I'm surprised that the
supplied flash config is commented out and erroneous:

[FLASH]
;CHIPTYPE    AM29F       ;Flash type (AM29F | AM29BX8 | AM29BX16 | I28BX8 | I28BX16)
;CHIPSIZE    0x200000    ;The size of one flash chip in bytes (e.g. AM29F010 = 0x20000)
;BUSWIDTH    8           ;The width of the flash memory bus in bits (8 | 16 | 32 | 64)
;

Did you start with the Embedded Planet offering, in your current effort
to create a usable config? Is MIRRORX16 more than a guess?

I've found that my flash chips are "spansion GL256N10FFI02", which
AFAICT are S29GL256N10FFI02 from AMD, as we used to know them.
I wonder if S29M32X16 is a likely guess for CHIPTYPE on the card which
has landed in my lap?

Maybe the most important question is: Will a wrong algorithm choice let
the magic smoke out?

Erik
(With just one toenail on the road, so far.)

^ permalink raw reply


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