date:20080430


On Tue, 2008-04-29 at 17:06 -0600, Grant Likely wrote:
 From: Grant Likely [EMAIL PROTECTED]
 
 Various improvements for configuring the MPC5200 MII link from the
 device tree:
 * Look for 'current-speed' property for fixed speed MII links

Not that I have looked, but why can't you use the fixed-link property?

   Jocke
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev

[RFC] [PATCH 1/5] [POWERPC] dma: implement new dma_map_attrs() interfaces

Update powerpc to use the new dma_*map*_attrs() interfaces. In doing so
update struct dma_mapping_ops to accept a struct dma_attrs and propagate
these changes through to all users of the code (generic IOMMU and the
64bit DMA code, and the iseries and ps3 platform code).

The old dma_*map_*() interfaces are reimplemented as calls to the
corresponding new interfaces.

Signed-off-by: Mark Nelson [EMAIL PROTECTED]
---
 arch/powerpc/Kconfig|1 
 arch/powerpc/kernel/dma_64.c|   34 ++---
 arch/powerpc/kernel/ibmebus.c   |   12 ++-
 arch/powerpc/kernel/iommu.c |   11 +--
 arch/powerpc/platforms/iseries/iommu.c  |4 -
 arch/powerpc/platforms/ps3/system-bus.c |   17 ++--
 include/asm-powerpc/dma-mapping.h   |  116 +++-
 include/asm-powerpc/iommu.h |   12 ++-
 8 files changed, 144 insertions(+), 63 deletions(-)

Index: upstream/arch/powerpc/Kconfig
===
--- upstream.orig/arch/powerpc/Kconfig
+++ upstream/arch/powerpc/Kconfig
@@ -110,6 +110,7 @@ config PPC
select HAVE_KPROBES
select HAVE_KRETPROBES
select HAVE_LMB
+   select HAVE_DMA_ATTRS
 
 config EARLY_PRINTK
bool
Index: upstream/arch/powerpc/kernel/dma_64.c
===
--- upstream.orig/arch/powerpc/kernel/dma_64.c
+++ upstream/arch/powerpc/kernel/dma_64.c
@@ -50,32 +50,38 @@ static void dma_iommu_free_coherent(stru
  */
 static dma_addr_t dma_iommu_map_single(struct device *dev, void *vaddr,
   size_t size,
-  enum dma_data_direction direction)
+  enum dma_data_direction direction,
+  struct dma_attrs *attrs)
 {
return iommu_map_single(dev, dev-archdata.dma_data, vaddr, size,
-   device_to_mask(dev), direction);
+   device_to_mask(dev), direction, attrs);
 }
 
 
 static void dma_iommu_unmap_single(struct device *dev, dma_addr_t dma_handle,
   size_t size,
-  enum dma_data_direction direction)
+  enum dma_data_direction direction,
+  struct dma_attrs *attrs)
 {
-   iommu_unmap_single(dev-archdata.dma_data, dma_handle, size, direction);
+   iommu_unmap_single(dev-archdata.dma_data, dma_handle, size, direction,
+  attrs);
 }
 
 
 static int dma_iommu_map_sg(struct device *dev, struct scatterlist *sglist,
-   int nelems, enum dma_data_direction direction)
+   int nelems, enum dma_data_direction direction,
+   struct dma_attrs *attrs)
 {
return iommu_map_sg(dev, dev-archdata.dma_data, sglist, nelems,
-   device_to_mask(dev), direction);
+   device_to_mask(dev), direction, attrs);
 }
 
 static void dma_iommu_unmap_sg(struct device *dev, struct scatterlist *sglist,
-   int nelems, enum dma_data_direction direction)
+   int nelems, enum dma_data_direction direction,
+   struct dma_attrs *attrs)
 {
-   iommu_unmap_sg(dev-archdata.dma_data, sglist, nelems, direction);
+   iommu_unmap_sg(dev-archdata.dma_data, sglist, nelems, direction,
+  attrs);
 }
 
 /* We support DMA to/from any memory page via the iommu */
@@ -148,19 +154,22 @@ static void dma_direct_free_coherent(str
 
 static dma_addr_t dma_direct_map_single(struct device *dev, void *ptr,
size_t size,
-   enum dma_data_direction direction)
+   enum dma_data_direction direction,
+   struct dma_attrs *attrs)
 {
return virt_to_abs(ptr) + get_dma_direct_offset(dev);
 }
 
 static void dma_direct_unmap_single(struct device *dev, dma_addr_t dma_addr,
size_t size,
-   enum dma_data_direction direction)
+   enum dma_data_direction direction,
+   struct dma_attrs *attrs)
 {
 }
 
 static int dma_direct_map_sg(struct device *dev, struct scatterlist *sgl,
-int nents, enum dma_data_direction direction)
+int nents, enum dma_data_direction direction,
+struct dma_attrs *attrs)
 {
struct scatterlist *sg;
int i;
@@ -174,7 +183,8 @@ static int dma_direct_map_sg(struct devi
 }
 
 static void dma_direct_unmap_sg(struct device *dev, struct scatterlist *sg,
-   int nents, enum dma_data_direction direction)
+

[RFC] [PATCH 2/5] [POWERPC] dma: use the struct dma_attrs in iommu code

Update iommu_alloc() to take the struct dma_attrs and pass them on to
tce_build(). This change propagates down to the tce_build functions of
all the platforms.

Signed-off-by: Mark Nelson [EMAIL PROTECTED]
---
 arch/powerpc/kernel/iommu.c|   13 -
 arch/powerpc/platforms/cell/iommu.c|5 +++--
 arch/powerpc/platforms/iseries/iommu.c |3 ++-
 arch/powerpc/platforms/pasemi/iommu.c  |3 ++-
 arch/powerpc/platforms/pseries/iommu.c |   13 -
 arch/powerpc/sysdev/dart_iommu.c   |3 ++-
 include/asm-powerpc/machdep.h  |3 ++-
 7 files changed, 27 insertions(+), 16 deletions(-)

Index: upstream/arch/powerpc/kernel/iommu.c
===
--- upstream.orig/arch/powerpc/kernel/iommu.c
+++ upstream/arch/powerpc/kernel/iommu.c
@@ -186,7 +186,8 @@ static unsigned long iommu_range_alloc(s
 static dma_addr_t iommu_alloc(struct device *dev, struct iommu_table *tbl,
  void *page, unsigned int npages,
  enum dma_data_direction direction,
- unsigned long mask, unsigned int align_order)
+ unsigned long mask, unsigned int align_order,
+ struct dma_attrs *attrs)
 {
unsigned long entry, flags;
dma_addr_t ret = DMA_ERROR_CODE;
@@ -205,7 +206,7 @@ static dma_addr_t iommu_alloc(struct dev
 
/* Put the TCEs in the HW table */
ppc_md.tce_build(tbl, entry, npages, (unsigned long)page  
IOMMU_PAGE_MASK,
-direction);
+direction, attrs);
 
 
/* Flush/invalidate TLB caches if necessary */
@@ -336,7 +337,8 @@ int iommu_map_sg(struct device *dev, str
npages, entry, dma_addr);
 
/* Insert into HW table */
-   ppc_md.tce_build(tbl, entry, npages, vaddr  IOMMU_PAGE_MASK, 
direction);
+   ppc_md.tce_build(tbl, entry, npages, vaddr  IOMMU_PAGE_MASK,
+direction, attrs);
 
/* If we are in an open segment, try merging */
if (segstart != s) {
@@ -573,7 +575,8 @@ dma_addr_t iommu_map_single(struct devic
align = PAGE_SHIFT - IOMMU_PAGE_SHIFT;
 
dma_handle = iommu_alloc(dev, tbl, vaddr, npages, direction,
-mask  IOMMU_PAGE_SHIFT, align);
+mask  IOMMU_PAGE_SHIFT, align,
+attrs);
if (dma_handle == DMA_ERROR_CODE) {
if (printk_ratelimit())  {
printk(KERN_INFO iommu_alloc failed, 
@@ -642,7 +645,7 @@ void *iommu_alloc_coherent(struct device
nio_pages = size  IOMMU_PAGE_SHIFT;
io_order = get_iommu_order(size);
mapping = iommu_alloc(dev, tbl, ret, nio_pages, DMA_BIDIRECTIONAL,
- mask  IOMMU_PAGE_SHIFT, io_order);
+ mask  IOMMU_PAGE_SHIFT, io_order, NULL);
if (mapping == DMA_ERROR_CODE) {
free_pages((unsigned long)ret, order);
return NULL;
Index: upstream/arch/powerpc/platforms/cell/iommu.c
===
--- upstream.orig/arch/powerpc/platforms/cell/iommu.c
+++ upstream/arch/powerpc/platforms/cell/iommu.c
@@ -173,7 +173,8 @@ static void invalidate_tce_cache(struct 
 }
 
 static void tce_build_cell(struct iommu_table *tbl, long index, long npages,
-   unsigned long uaddr, enum dma_data_direction direction)
+   unsigned long uaddr, enum dma_data_direction direction,
+   struct dma_attrs *attrs)
 {
int i;
unsigned long *io_pte, base_pte;
@@ -519,7 +520,7 @@ cell_iommu_setup_window(struct cbe_iommu
 
__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);
+  (unsigned long)iommu-pad_page, DMA_TO_DEVICE, NULL);
window-table.it_hint = window-table.it_blocksize;
 
return window;
Index: upstream/arch/powerpc/platforms/iseries/iommu.c
===
--- upstream.orig/arch/powerpc/platforms/iseries/iommu.c
+++ upstream/arch/powerpc/platforms/iseries/iommu.c
@@ -42,7 +42,8 @@
 #include asm/iseries/iommu.h
 
 static void tce_build_iSeries(struct iommu_table *tbl, long index, long npages,
-   unsigned long uaddr, enum dma_data_direction direction)
+   unsigned long uaddr, enum dma_data_direction direction,
+   struct dma_attrs *attrs)
 {
u64 rc;
u64 tce, rpn;
Index: upstream/arch/powerpc/platforms/pasemi/iommu.c
===
---

[RFC] [PATCH 4/5] [POWERPC] Move device_to_mask() to dma-mapping.h

Move device_to_mask() to dma-mapping.h because we need to use it from
outside dma_64.c in a later patch.

Signed-off-by: Mark Nelson [EMAIL PROTECTED]
---
 arch/powerpc/kernel/dma_64.c  |9 -
 include/asm-powerpc/dma-mapping.h |9 +
 2 files changed, 9 insertions(+), 9 deletions(-)

Index: upstream/arch/powerpc/kernel/dma_64.c
===
--- upstream.orig/arch/powerpc/kernel/dma_64.c
+++ upstream/arch/powerpc/kernel/dma_64.c
@@ -15,15 +15,6 @@
  * Generic iommu implementation
  */
 
-static inline unsigned long device_to_mask(struct device *dev)
-{
-   if (dev-dma_mask  *dev-dma_mask)
-   return *dev-dma_mask;
-   /* Assume devices without mask can take 32 bit addresses */
-   return 0xul;
-}
-
-
 /* Allocates a contiguous real buffer and creates mappings over it.
  * Returns the virtual address of the buffer and sets dma_handle
  * to the dma address (mapping) of the first page.
Index: upstream/include/asm-powerpc/dma-mapping.h
===
--- upstream.orig/include/asm-powerpc/dma-mapping.h
+++ upstream/include/asm-powerpc/dma-mapping.h
@@ -45,6 +45,15 @@ extern void __dma_sync_page(struct page 
 #endif /* ! CONFIG_NOT_COHERENT_CACHE */
 
 #ifdef CONFIG_PPC64
+
+static inline unsigned long device_to_mask(struct device *dev)
+{
+   if (dev-dma_mask  *dev-dma_mask)
+   return *dev-dma_mask;
+   /* Assume devices without mask can take 32 bit addresses */
+   return 0xul;
+}
+
 /*
  * DMA operations are abstracted for G5 vs. i/pSeries, PCI vs. VIO
  */

-- 
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev

[RFC] [PATCH 0/5] [POWERPC] Implement dma_map_attrs() and DMA_ATTR_WEAK_ORDERING and use on Cell

-- 
Was Re: [PATCH] [POWERPC] Add struct iommu_table argument to iommu_map_sg()

Here's the patch series that follows on from the patch:
Add struct iommu_table argument to iommu_map_sg()

Thanks!

Mark.
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev

[RFC] [PATCH 5/5] [POWERPC] Add DMA_ATTR_WEAK_ORDERING dma attribute and use in Cell IOMMU code

Introduce a new dma attriblue DMA_ATTR_WEAK_ORDERING to use weak ordering
on DMA mappings in the Cell processor. Add the code to the Cell's IOMMU
implementation to use this code.

Dynamic mappings can be weakly or strongly ordered on an individual basis
but the fixed mapping has to be either completely strong or completely weak.
This is currently decided by a kernel boot option (pass iommu_fixed=weak
for a weakly ordered fixed linear mapping, strongly ordered is the default).

Signed-off-by: Mark Nelson [EMAIL PROTECTED]
---
 Documentation/DMA-attributes.txt|9 ++
 arch/powerpc/platforms/cell/iommu.c |  113 ++--
 include/linux/dma-attrs.h   |1 
 3 files changed, 118 insertions(+), 5 deletions(-)

Index: upstream/arch/powerpc/platforms/cell/iommu.c
===
--- upstream.orig/arch/powerpc/platforms/cell/iommu.c
+++ upstream/arch/powerpc/platforms/cell/iommu.c
@@ -199,6 +199,8 @@ static void tce_build_cell(struct iommu_
base_pte = IOPTE_PP_W | IOPTE_PP_R | IOPTE_M | IOPTE_SO_RW |
(window-ioid  IOPTE_IOID_Mask);
 #endif
+   if (unlikely(dma_get_attr(DMA_ATTR_WEAK_ORDERING, attrs)))
+   base_pte = ~IOPTE_SO_RW;
 
io_pte = (unsigned long *)tbl-it_base + (index - tbl-it_offset);
 
@@ -539,7 +541,9 @@ static struct cbe_iommu *cell_iommu_for_
 static unsigned long cell_dma_direct_offset;
 
 static unsigned long dma_iommu_fixed_base;
-struct dma_mapping_ops dma_iommu_fixed_ops;
+
+/* iommu_fixed_is_weak is set if booted with iommu_fixed=weak */
+static int iommu_fixed_is_weak;
 
 static struct iommu_table *cell_get_iommu_table(struct device *dev)
 {
@@ -563,6 +567,98 @@ static struct iommu_table *cell_get_iomm
return window-table;
 }
 
+/* A coherent allocation implies strong ordering */
+
+static void *dma_fixed_alloc_coherent(struct device *dev, size_t size,
+ dma_addr_t *dma_handle, gfp_t flag)
+{
+   if (iommu_fixed_is_weak)
+   return iommu_alloc_coherent(dev, cell_get_iommu_table(dev),
+   size, dma_handle,
+   device_to_mask(dev), flag,
+   dev-archdata.numa_node);
+   else
+   return dma_direct_ops.alloc_coherent(dev, size, dma_handle,
+flag);
+}
+
+static void dma_fixed_free_coherent(struct device *dev, size_t size,
+   void *vaddr, dma_addr_t dma_handle)
+{
+   if (iommu_fixed_is_weak)
+   iommu_free_coherent(cell_get_iommu_table(dev), size, vaddr,
+   dma_handle);
+   else
+   dma_direct_ops.free_coherent(dev, size, vaddr, dma_handle);
+}
+
+static dma_addr_t dma_fixed_map_single(struct device *dev, void *ptr,
+  size_t size,
+  enum dma_data_direction direction,
+  struct dma_attrs *attrs)
+{
+   if (iommu_fixed_is_weak == dma_get_attr(DMA_ATTR_WEAK_ORDERING, attrs))
+   return dma_direct_ops.map_single(dev, ptr, size, direction,
+attrs);
+   else
+   return iommu_map_single(dev, cell_get_iommu_table(dev), ptr,
+   size, device_to_mask(dev), direction,
+   attrs);
+}
+
+static void dma_fixed_unmap_single(struct device *dev, dma_addr_t dma_addr,
+  size_t size,
+  enum dma_data_direction direction,
+  struct dma_attrs *attrs)
+{
+   if (iommu_fixed_is_weak == dma_get_attr(DMA_ATTR_WEAK_ORDERING, attrs))
+   dma_direct_ops.unmap_single(dev, dma_addr, size, direction,
+   attrs);
+   else
+   iommu_unmap_single(cell_get_iommu_table(dev), dma_addr, size,
+  direction, attrs);
+}
+
+static int dma_fixed_map_sg(struct device *dev, struct scatterlist *sg,
+  int nents, enum dma_data_direction direction,
+  struct dma_attrs *attrs)
+{
+   if (iommu_fixed_is_weak == dma_get_attr(DMA_ATTR_WEAK_ORDERING, attrs))
+   return dma_direct_ops.map_sg(dev, sg, nents, direction, attrs);
+   else
+   return iommu_map_sg(dev, cell_get_iommu_table(dev), sg, nents,
+   device_to_mask(dev), direction, attrs);
+}
+
+static void dma_fixed_unmap_sg(struct device *dev, struct scatterlist *sg,
+  int nents, enum dma_data_direction direction,
+  struct dma_attrs *attrs)
+{
+   if (iommu_fixed_is_weak ==

[RFC] [PATCH 3/5] [POWERPC] Make cell_dma_dev_setup_iommu() return the iommu table

Make cell_dma_dev_setup_iommu() return a pointer to the struct iommu_table
(or NULL if no table can be found) rather than putting this pointer into
dev-archdata.dma_data (let the caller do that), and rename this function
to cell_get_iommu_table() to reflect this change.

This will allow us to get the iommu table for a device that doesn't have
the table in the archdata.

Signed-off-by: Mark Nelson [EMAIL PROTECTED]
---
 arch/powerpc/platforms/cell/iommu.c |8 
 1 file changed, 4 insertions(+), 4 deletions(-)

Index: upstream/arch/powerpc/platforms/cell/iommu.c
===
--- upstream.orig/arch/powerpc/platforms/cell/iommu.c
+++ upstream/arch/powerpc/platforms/cell/iommu.c
@@ -541,7 +541,7 @@ static unsigned long cell_dma_direct_off
 static unsigned long dma_iommu_fixed_base;
 struct dma_mapping_ops dma_iommu_fixed_ops;
 
-static void cell_dma_dev_setup_iommu(struct device *dev)
+static struct iommu_table *cell_get_iommu_table(struct device *dev)
 {
struct iommu_window *window;
struct cbe_iommu *iommu;
@@ -556,11 +556,11 @@ static void cell_dma_dev_setup_iommu(str
printk(KERN_ERR iommu: missing iommu for %s (node %d)\n,
   archdata-of_node ? archdata-of_node-full_name : ?,
   archdata-numa_node);
-   return;
+   return NULL;
}
window = list_entry(iommu-windows.next, struct iommu_window, list);
 
-   archdata-dma_data = window-table;
+   return window-table;
 }
 
 static void cell_dma_dev_setup_fixed(struct device *dev);
@@ -573,7 +573,7 @@ static void cell_dma_dev_setup(struct de
if (get_dma_ops(dev) == dma_iommu_fixed_ops)
cell_dma_dev_setup_fixed(dev);
else if (get_pci_dma_ops() == dma_iommu_ops)
-   cell_dma_dev_setup_iommu(dev);
+   archdata-dma_data = cell_get_iommu_table(dev);
else if (get_pci_dma_ops() == dma_direct_ops)
archdata-dma_data = (void *)cell_dma_direct_offset;
else

-- 
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev

Re: [PATCH] [POWERPC] convert transfer_to_handler into a macro



On Apr 29, 2008, at 10:24 PM, Paul Mackerras wrote:

Kumar Gala writes:


Wouldn't it be better and safer to have the exception prolog for
critical interrupts save SRR0/1 in the stack frame, and have the
prolog for machine checks save SRR0/1 and CSRR0/1 likewise?


If we do this I guess we can use SRR0/1 regardless of which level we
came from.


That's the idea.  I actually thought the booke exception prologs
already did that, but it seems I'm wrong.

What sort of things do you expect critical and machine-check handlers
to be needing to do?


It varies on the parts but remember critical level can be anything  
from watchdog, critical input (equivalent of external input, but at  
the critical level), and debug.  So there is a pretty wide set of  
possibility.


- k
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev

Re: [PATCH] [POWERPC] convert transfer_to_handler into a macro

2008-04-30 Thread Franca, Jose (NSN - PT/Portugal - MiniMD)



On Apr 30, 2008, at 1:32 AM, Benjamin Herrenschmidt wrote:


On Tue, 2008-04-29 at 18:52 -0500, Kumar Gala wrote:

On Apr 29, 2008, at 4:28 PM, Paul Mackerras wrote:

Kumar Gala writes:


We need to have unique transfer_to_handler paths for each exception
level
that is supported.  We need to use the proper xSRR0/1 depending on
which
exception level the interrupt was from.  The macro conversion  
lets up

templatize this code path.


It seems to me that this implies you are assuming that you will  
never

ever get a synchronous normal interrupt such as a TLB miss while you
are in a critical or machine check handler.


Grr.. one more thing to fix :)


Wouldn't it be better and safer to have the exception prolog for
critical interrupts save SRR0/1 in the stack frame, and have the
prolog for machine checks save SRR0/1 and CSRR0/1 likewise?


If we do this I guess we can use SRR0/1 regardless of which level we
came from.


Also consider saving/restoring MAS


got that.  Does 40x/44x have anything similar we need to save/restore?
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev

Re: MPC83xx Power Management support

2008-04-30 Thread Guennadi Liakhovetski

On Wed, 30 Apr 2008, Perrine MARTIGNONI wrote:

Please, in the future direct your questions to the respective mailing 
list, thanks. Added to cc.

 Hello,
 
 Currently, I try to use the Power Management patches and I have some issues.
 
 With which version of linux the patches are written  ?
 I try on linux-2.6.23 and there are some rejects.

The patches are against a recent powerpc git tree snapshot.

Thanks
Guennadi
---
Guennadi Liakhovetski
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev

RE: SKB corruption on heavy traffic

Hello!

Thank you for replying!
It't quite dificult to say if the problem exists without our changes, 
since the all software is dependent on this changes so to work with the 
hardware. I can't answer to that right now on that, but I forgot to add one 
thing: we have ring buffer full problems on our fcc_enet driver from time to 
time. So, I think the problem could be on linux configurations (related to hw) 
because there is a lot of posts on the web related to problems similar to this 
(none of them has really solved the bottom problem). 

Regards,
Filipe 

-Original Message-
From: ext Scott Wood [mailto:[EMAIL PROTECTED] 
Sent: terça-feira, 29 de Abril de 2008 20:15
To: Franca, Jose (NSN - PT/Portugal - MiniMD)
Cc: linuxppc-dev@ozlabs.org; [EMAIL PROTECTED]
Subject: Re: SKB corruption on heavy traffic

On Tue, Apr 29, 2008 at 07:39:07PM +0100, Franca, Jose (NSN - PT/Portugal - 
MiniMD) wrote:
   We are developing a MPC8247 based telecom board (512MB), using
 linux 2.4 with some proprietary changes on IP stack and we are facing
 some problems when we have heavy traffic on our Ethernet interfaces...

Do you see these problems without the proprietary changes, and with a
current kernel?

-Scott
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev

Re: [PATCH 6/6] [POWERPC] booting-without-of: add FHCI USB, FSL MCU, FSL UPM and GPIO LEDs bindings

2008-04-30 Thread Wolfgang Grandegger

Hi Anton,

Anton Vorontsov wrote:
 This patch adds few bindings for the new drivers to be submitted through
 appropriate maintainers.
 
 Signed-off-by: Anton Vorontsov [EMAIL PROTECTED]
 ---
  Documentation/powerpc/booting-without-of.txt |  125 
 ++
  1 files changed, 125 insertions(+), 0 deletions(-)
 
 diff --git a/Documentation/powerpc/booting-without-of.txt 
 b/Documentation/powerpc/booting-without-of.txt
 index 4fefc44..6564e0a 100644
 --- a/Documentation/powerpc/booting-without-of.txt
 +++ b/Documentation/powerpc/booting-without-of.txt
 @@ -61,6 +61,10 @@ Table of Contents
r) Freescale Display Interface Unit
s) Freescale on board FPGA
t) Freescale General-purpose Timers Module
 +  u) Freescale QUICC Engine USB Controller
 +  v) LEDs on GPIOs
 +  w) Freescale MCU with MPC8349E-mITX compatible firmware
 +  x) Freescale Localbus UPM programmed to work with NAND flash
  
VII - Marvell Discovery mv64[345]6x System Controller chips
  1) The /system-controller node
 @@ -2916,6 +2920,127 @@ platforms are moved over to use the 
 flattened-device-tree model.
   clock-frequency = 0;
  };
  
 +u) Freescale QUICC Engine USB Controller
 +
 +Required properties:
 +  - compatible : should be fsl,chip-qe-usb, fsl,mpc8323-qe-usb;
 +  - reg : the first two cells should contain gtm registers location and
 +length, the next two two cells should contain PRAM location and
 +length.
 +  - interrupts : should contain USB interrupt.
 +  - interrupt-parent : interrupt source phandle.
 +  - fsl,fullspeed-clock : specifies the full speed USB clock source in
 +clknum or brgnum format.
 +  - fsl,lowspeed-clock : specifies the low speed USB clock source in
 +clknum or brgnum format.
 +  - fsl,usb-mode : should be host.
 +  - linux,hub-power-budget : optional, USB power budget for the root hub
 +in mA.
 +  - gpios : should specify GPIOs in this order: USBOE, USBTP, USBTN, 
 USBRP,
 +USBRN, SPEED (optional), and POWER (optional).
 +
 +Example:
 +
 + [EMAIL PROTECTED] {
 + compatible = fsl,mpc8360-qe-usb, fsl,mpc8323-qe-usb;
 + reg = 0x6c0 0x40 0x8b00 0x100;
 + interrupts = 11;
 + interrupt-parent = qeic;
 + fsl,fullspeed-clock = clk21;
 + fsl,usb-mode = host;
 + gpios = qe_pio_b  2 0 /* USBOE */
 +  qe_pio_b  3 0 /* USBTP */
 +  qe_pio_b  8 0 /* USBTN */
 +  qe_pio_b  9 0 /* USBRP */
 +  qe_pio_b 11 0 /* USBRN */
 +  qe_pio_e 20 0 /* SPEED */
 +  qe_pio_e 21 0 /* POWER */;
 + };
 +
 +v) LEDs on GPIOs
 +
 +Required properties:
 +  - compatible : should be linux,gpio-led.
 +  - linux,name : LED name.
 +  - linux,active-low : property should be present if LED wired as
 +active-low.
 +  - linux,default-trigger : Linux default trigger for this LED.
 +  - linux,brightness : default brightness.
 +  - gpios : should specify LED GPIO.
 +
 +Example:
 +
 + [EMAIL PROTECTED] {
 + compatible = linux,gpio-led;
 + linux,name = pwr;
 + linux,brightness = 1;
 + linux,active-low;
 + gpios = mcu_pio 0;
 + };
 +
 + [EMAIL PROTECTED] {
 + compatible = linux,gpio-led;
 + linux,name = hdd;
 + linux,default-trigger = ide-disk;
 + linux,active-low;
 + gpios = mcu_pio 1;
 + };
 +
 +w) Freescale MCU with MPC8349E-mITX compatible firmware
 +
 +Required properties:
 +  - compatible : fsl,mcu-chip-board, fsl,mcu-mpc8349emitx;
 +  - reg : should specify I2C address (0x0a).
 +  - #address-cells : should be 0.
 +  - #size-cells : should be 0.
 +  - #gpio-cells : should be 2.
 +  - gpio-controller : should be present;
 +
 +Example:
 +
 + mcu_pio: [EMAIL PROTECTED] {
 + #address-cells = 0;
 + #size-cells = 0;
 + #gpio-cells = 2;
 + compatible = fsl,mc9s08qg8-mpc8349emitx,
 +  fsl,mcu-mpc8349emitx;
 + reg = 0x0a;
 + gpio-controller;
 + };
 +
 +x) Freescale Localbus UPM programmed to work with NAND flash
 +
 +  Required properties:
 +  - #address-cells : should be 0;
 +  - #size-cells : should be 0;
 +  - compatible : fsl,upm-nand.
 +  - reg : should specify localbus chip select and size used for the chip.
 +  - fsl,upm-addr-offset : UPM pattern offset for the address latch.
 +  - fsl,upm-cmd-offset : UPM pattern offset for the command latch.
 +  - gpios : may specify optional GPIO connected to the Ready-Not-Busy 
 pin.
 +
 +  Example:
 +
 + [EMAIL PROTECTED],0 {
 + #address-cells = 0;
 + #size-cells = 0;
 +

FW: SKB corruption on heavy traffic

2008-04-30 Thread Franca, Jose (NSN - PT/Portugal - MiniMD)

From our latest debugs we found that the problem occurs mainly on skbuff code. 
After some variable time kfree or kalloc result in kernel oops.

-Original Message-
From: Franca, Jose (NSN - PT/Portugal - MiniMD) 
Sent: quarta-feira, 30 de Abril de 2008 9:44
To: 'ext Scott Wood'
Cc: 
Subject: RE: SKB corruption on heavy traffic

Hello!

Thank you for replying!
It't quite dificult to say if the problem exists without our changes, 
since the all software is dependent on this changes so to work with the 
hardware. I can't answer to that right now on that, but I forgot to add one 
thing: we have ring buffer full problems on our fcc_enet driver from time to 
time. So, I think the problem could be on linux configurations (related to hw) 
because there is a lot of posts on the web related to problems similar to this 
(none of them has really solved the bottom problem). 

Regards,
Filipe 

-Original Message-
From: ext Scott Wood [mailto:[EMAIL PROTECTED] 
Sent: terça-feira, 29 de Abril de 2008 20:15
To: Franca, Jose (NSN - PT/Portugal - MiniMD)
Cc: linuxppc-dev@ozlabs.org; [EMAIL PROTECTED]
Subject: Re: SKB corruption on heavy traffic

On Tue, Apr 29, 2008 at 07:39:07PM +0100, Franca, Jose (NSN - PT/Portugal - 
MiniMD) wrote:
   We are developing a MPC8247 based telecom board (512MB), using
 linux 2.4 with some proprietary changes on IP stack and we are facing
 some problems when we have heavy traffic on our Ethernet interfaces...

Do you see these problems without the proprietary changes, and with a
current kernel?

-Scott
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev

[PATCH] [POWERPC] Move to runtime allocated exception stacks

For the additonal exception levels (critical, debug, machine check) on
40x/book-e we were using static allocations of the stack in the
associated head.S.

Move to a runtime allocation to make the code a bit easier to read as
we mimic how we handle IRQ stacks.  Its also a bit easier to setup the
stack with a dummy thread_info in C code.

Signed-off-by: Kumar Gala [EMAIL PROTECTED]
---

Josh, can you test this on 40x and 44x.  (make sure gdb single step still
functions).

This is the first in a sequence of patches towards fixing up the exception
level stack functionality.  I'm posting them in pieces to get review and
make it easier to bisect if the patches introduce issues in the future.

- k

 arch/powerpc/kernel/head_40x.S   |   14 ++
 arch/powerpc/kernel/head_44x.S   |9 -
 arch/powerpc/kernel/head_booke.h |   27 ++-
 arch/powerpc/kernel/head_fsl_booke.S |9 -
 arch/powerpc/kernel/irq.c|   33 +
 arch/powerpc/kernel/setup_32.c   |   24 
 include/asm-powerpc/irq.h|   13 +
 7 files changed, 82 insertions(+), 47 deletions(-)

diff --git a/arch/powerpc/kernel/head_40x.S b/arch/powerpc/kernel/head_40x.S
index 8552e67..ca75eaf 100644
--- a/arch/powerpc/kernel/head_40x.S
+++ b/arch/powerpc/kernel/head_40x.S
@@ -148,8 +148,8 @@ _ENTRY(crit_r11)
mfcrr10;/* save CR in r10 for now  */\
mfspr   r11,SPRN_SRR3;  /* check whether user or kernel*/\
andi.   r11,r11,MSR_PR;  \
-   lis r11,[EMAIL PROTECTED];   \
-   ori r11,r11,[EMAIL PROTECTED];   \
+   lis r11,[EMAIL PROTECTED];   \
+   lwz r11,[EMAIL PROTECTED](r11); 
 \
beq 1f;  \
/* COMING FROM USER MODE */  \
mfspr   r11,SPRN_SPRG3; /* if from user, start at top of   */\
@@ -996,16 +996,6 @@ empty_zero_page:
 swapper_pg_dir:
.space  PGD_TABLE_SIZE

-
-/* Stack for handling critical exceptions from kernel mode */
-   .section .bss
-.align 12
-exception_stack_bottom:
-   .space  4096
-critical_stack_top:
-   .globl  exception_stack_top
-exception_stack_top:
-
 /* Room for two PTE pointers, usually the kernel and current user pointers
  * to their respective root page table.
  */
diff --git a/arch/powerpc/kernel/head_44x.S b/arch/powerpc/kernel/head_44x.S
index b84ec6a..2041248 100644
--- a/arch/powerpc/kernel/head_44x.S
+++ b/arch/powerpc/kernel/head_44x.S
@@ -730,15 +730,6 @@ empty_zero_page:
 swapper_pg_dir:
.space  PGD_TABLE_SIZE

-/* Reserved 4k for the critical exception stack  4k for the machine
- * check stack per CPU for kernel mode exceptions */
-   .section .bss
-.align 12
-exception_stack_bottom:
-   .space  BOOKE_EXCEPTION_STACK_SIZE
-   .globl  exception_stack_top
-exception_stack_top:
-
 /*
  * Room for two PTE pointers, usually the kernel and current user pointers
  * to their respective root page table.
diff --git a/arch/powerpc/kernel/head_booke.h b/arch/powerpc/kernel/head_booke.h
index aefafc6..d647e05 100644
--- a/arch/powerpc/kernel/head_booke.h
+++ b/arch/powerpc/kernel/head_booke.h
@@ -43,9 +43,7 @@
SAVE_2GPRS(7, r11)

 /* To handle the additional exception priority levels on 40x and Book-E
- * processors we allocate a 4k stack per additional priority level. The various
- * head_xxx.S files allocate space (exception_stack_top) for each priority's
- * stack times the number of CPUs
+ * processors we allocate a stack per additional priority level.
  *
  * On 40x critical is the only additional level
  * On 44x/e500 we have critical and machine check
@@ -61,36 +59,31 @@
  * going to critical or their own debug level we aren't currently
  * providing configurations that micro-optimize space usage.
  */
-#ifdef CONFIG_44x
-#define NUM_EXCEPTION_LVLS 2
-#else
-#define NUM_EXCEPTION_LVLS 3
-#endif
-#define BOOKE_EXCEPTION_STACK_SIZE (4096 * NUM_EXCEPTION_LVLS)

 /* CRIT_SPRG only used in critical exception handling */
 #define CRIT_SPRG  SPRN_SPRG2
 /* MCHECK_SPRG only used in machine check exception handling */
 #define MCHECK_SPRGSPRN_SPRG6W

-#define MCHECK_STACK_TOP   (exception_stack_top - 4096)
-#define CRIT_STACK_TOP (exception_stack_top)
+#define MCHECK_STACK_TOP   mcheckirq_ctx
+#define CRIT_STACK_TOP critirq_ctx

 /* only on e200 for now */
-#define DEBUG_STACK_TOP(exception_stack_top - 8192)
+#define DEBUG_STACK_TOPdbgirq_ctx
 #define DEBUG_SPRG SPRN_SPRG6W

 #ifdef CONFIG_SMP
 #define BOOKE_LOAD_EXC_LEVEL_STACK(level)

[PATCH] [POWERPC] Rework EXC_LEVEL_EXCEPTION_PROLOG code

* Cleanup the code a bit my allocating an INT_FRAME on our exception
  stack there by make references go from GPR11-INT_FRAME_SIZE(r8) to
  just GPR(r8)
* simplify {lvl}_transfer_to_handler code by moving the copying of the
  temp registers we use if we come from user space into the PROLOG
* If the exception came from kernel mode copy thread_info flags,
  preempt, and task pointer from the process thread_info.

Signed-off-by: Kumar Gala [EMAIL PROTECTED]
---

I'm not sure if the copying of TI_FLAGS, TI_PREEMPT, and TI_TASK
are really needed.  I'm a bit concerned what to do if we get a
CriticalInput while in kernel mode and the handler causes a reschedule.

 arch/powerpc/kernel/entry_32.S   |   13 --
 arch/powerpc/kernel/head_booke.h |   47 -
 2 files changed, 30 insertions(+), 30 deletions(-)

diff --git a/arch/powerpc/kernel/entry_32.S b/arch/powerpc/kernel/entry_32.S
index 0c8614d..816dd54 100644
--- a/arch/powerpc/kernel/entry_32.S
+++ b/arch/powerpc/kernel/entry_32.S
@@ -44,29 +44,16 @@
 #endif

 #ifdef CONFIG_BOOKE
-#include head_booke.h
-#define TRANSFER_TO_HANDLER_EXC_LEVEL(exc_level)   \
-   mtspr   exc_level##_SPRG,r8;\
-   BOOKE_LOAD_EXC_LEVEL_STACK(exc_level);  \
-   lwz r0,GPR10-INT_FRAME_SIZE(r8);\
-   stw r0,GPR10(r11);  \
-   lwz r0,GPR11-INT_FRAME_SIZE(r8);\
-   stw r0,GPR11(r11);  \
-   mfspr   r8,exc_level##_SPRG
-
.globl  mcheck_transfer_to_handler
 mcheck_transfer_to_handler:
-   TRANSFER_TO_HANDLER_EXC_LEVEL(MCHECK)
b   transfer_to_handler_full

.globl  debug_transfer_to_handler
 debug_transfer_to_handler:
-   TRANSFER_TO_HANDLER_EXC_LEVEL(DEBUG)
b   transfer_to_handler_full

.globl  crit_transfer_to_handler
 crit_transfer_to_handler:
-   TRANSFER_TO_HANDLER_EXC_LEVEL(CRIT)
/* fall through */
 #endif

diff --git a/arch/powerpc/kernel/head_booke.h b/arch/powerpc/kernel/head_booke.h
index d647e05..78baec5 100644
--- a/arch/powerpc/kernel/head_booke.h
+++ b/arch/powerpc/kernel/head_booke.h
@@ -78,12 +78,12 @@
slwir8,r8,2;\
addis   r8,r8,[EMAIL PROTECTED];\
lwz r8,[EMAIL PROTECTED](r8);   \
-   addir8,r8,THREAD_SIZE;
+   addir8,r8,THREAD_SIZE-INT_FRAME_SIZE;
 #else
 #define BOOKE_LOAD_EXC_LEVEL_STACK(level)  \
lis r8,[EMAIL PROTECTED];   \
lwz r8,[EMAIL PROTECTED](r8);   \
-   addir8,r8,THREAD_SIZE;
+   addir8,r8,THREAD_SIZE-INT_FRAME_SIZE;
 #endif

 /*
@@ -97,22 +97,35 @@
 #define EXC_LEVEL_EXCEPTION_PROLOG(exc_level, exc_level_srr0, exc_level_srr1) \
mtspr   exc_level##_SPRG,r8; \
BOOKE_LOAD_EXC_LEVEL_STACK(exc_level);/* r8 points to the exc_level 
stack*/ \
-   stw r10,GPR10-INT_FRAME_SIZE(r8);\
-   stw r11,GPR11-INT_FRAME_SIZE(r8);\
+   stw r9,GPR9(r8);/* save various registers  */\
+   stw r10,GPR10(r8);   \
+   stw r11,GPR11(r8);   \
+   mfspr   r11,SPRN_SPRG3; /* if from user, start at top of   */\
+   lwz r11,THREAD_INFO-THREAD(r11); /* this thread's kernel stack */\
+   addir11,r11,THREAD_SIZE-INT_FRAME_SIZE; /* Alloc exception frm */\
mfcrr10;/* save CR in r10 for now  */\
-   mfspr   r11,exc_level_srr1; /* check whether user or kernel*/\
-   andi.   r11,r11,MSR_PR;  \
-   mr  r11,r8;  \
-   mfspr   r8,exc_level##_SPRG; \
+   mfspr   r9,exc_level_srr1;  /* check whether user or kernel*/\
+   andi.   r9,r9,MSR_PR;\
beq 1f;  \
/* COMING FROM USER MODE */  \
-   mfspr   r11,SPRN_SPRG3; /* if from user, start at top of   */\
-   lwz r11,THREAD_INFO-THREAD(r11); /* this thread's kernel stack */\
-   addir11,r11,THREAD_SIZE; \
-1: subir11,r11,INT_FRAME_SIZE; /* Allocate an exception frame */\
+   lwz r9,GPR9(r8);/* copy regs from exception stack  */\
+   stw r9,GPR9(r11);\
+   lwz r9,GPR10(r8);\
+   stw r9,GPR10(r11);   \
+

[git pull] Please pull powerpc.git master branch

2008-04-30 Thread Paul Mackerras

Linus,

Please do:

git pull \
git://git.kernel.org/pub/scm/linux/kernel/git/paulus/powerpc.git master

once more.  There are a bunch of updates for the embedded MPC5200
based platforms, some spufs updates for Cell, and two bug fixes from
Michael Ellerman.

Sorry about missing the diffstat last time.

Thanks,
Paul.

 .../powerpc/mpc52xx-device-tree-bindings.txt   |   12 
 arch/powerpc/boot/dts/cm5200.dts   |   98 +-
 arch/powerpc/boot/dts/lite5200.dts |  132 +-
 arch/powerpc/boot/dts/lite5200b.dts|  146 +-
 arch/powerpc/boot/dts/motionpro.dts|  118 +-
 arch/powerpc/boot/dts/pcm030.dts   |  363 ++
 arch/powerpc/boot/dts/tqm5200.dts  |   80 +
 arch/powerpc/configs/52xx/cm5200_defconfig | 1099 ++
 arch/powerpc/configs/52xx/lite5200b_defconfig  | 1049 +
 arch/powerpc/configs/52xx/motionpro_defconfig  | 1107 ++
 arch/powerpc/configs/52xx/pcm030_defconfig | 1115 ++
 arch/powerpc/configs/52xx/tqm5200_defconfig| 1214 
 arch/powerpc/kernel/machine_kexec.c|   12 
 arch/powerpc/kernel/setup_64.c |9 
 arch/powerpc/platforms/52xx/Kconfig|6 
 arch/powerpc/platforms/52xx/Makefile   |2 
 arch/powerpc/platforms/52xx/mpc5200_simple.c   |1 
 arch/powerpc/platforms/52xx/mpc52xx_gpio.c |  465 
 arch/powerpc/platforms/52xx/mpc52xx_pic.c  |   38 +
 arch/powerpc/platforms/cell/spufs/.gitignore   |2 
 arch/powerpc/platforms/cell/spufs/context.c|4 
 arch/powerpc/platforms/cell/spufs/file.c   |  166 +++
 arch/powerpc/platforms/cell/spufs/run.c|2 
 arch/powerpc/platforms/cell/spufs/sched.c  |4 
 arch/powerpc/platforms/cell/spufs/spufs.h  |   33 +
 arch/powerpc/platforms/cell/spufs/sputrace.c   |   36 -
 drivers/net/fec_mpc52xx.c  |   23 
 drivers/serial/mpc52xx_uart.c  |2 
 28 files changed, 7009 insertions(+), 329 deletions(-)
 create mode 100644 arch/powerpc/boot/dts/pcm030.dts
 create mode 100644 arch/powerpc/configs/52xx/cm5200_defconfig
 create mode 100644 arch/powerpc/configs/52xx/lite5200b_defconfig
 create mode 100644 arch/powerpc/configs/52xx/motionpro_defconfig
 create mode 100644 arch/powerpc/configs/52xx/pcm030_defconfig
 create mode 100644 arch/powerpc/configs/52xx/tqm5200_defconfig
 create mode 100644 arch/powerpc/platforms/52xx/mpc52xx_gpio.c
 create mode 100644 arch/powerpc/platforms/cell/spufs/.gitignore

Bartlomiej Sieka (1):
  [POWERPC] mpc5200: defconfigs for CM5200, Lite5200B, Motion-PRO and 
TQM5200

Christoph Hellwig (1):
  [POWERPC] spufs: add context switch notification log

Grant Likely (2):
  [POWERPC] mpc5200: Fix unterminated of_device_id table
  [POWERPC] mpc5200: Switch mpc5200 dts files to dts-v1 format

Julio M. Merino Vidal (4):
  [POWERPC] spufs: add sputrace marker parameter names
  [POWERPC] spufs: add marker for destroy_spu_context
  [POWERPC] spufs: fix marker name for find_victim
  [POWERPC] spufs: trace spu_acquire_saved events

Kumar Gala (1):
  [POWERPC] spufs: add .gitignore for spu_save_dump.h  spu_restore_dump.h

Michael Ellerman (2):
  [POWERPC] Make emergency stack safe for current_thread_info() use
  [POWERPC] Fix crashkernel= handling when no crashkernel= specified

Sascha Hauer (2):
  [POWERPC] mpc5200: add interrupt type function
  [POWERPC] mpc5200: Fix FEC error handling on FIFO errors

[EMAIL PROTECTED] (2):
  [POWERPC] mpc5200: add gpiolib support for mpc5200
  [POWERPC] mpc5200: add Phytec pcm030 board support

___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev

[PATCH] [POWERPC] 40x/Book-E: Save/restore volatile exception registers

On machines with more than one exception level any system register that
might be modified by the normal exception level needs to be saved and
restored on taking a higher level exception.  We already are saving
and restoring ESR and DEAR.

For critical level add SRR0/1.
For debug level add CSRR0/1 and SRR0/1.
For machine check level add DSRR0/1, CSRR0/1, and SRR0/1.

On FSL Book-E parts we always save/restore the MAS registers for critical,
debug, and machine check level exceptions.

Signed-off-by: Kumar Gala [EMAIL PROTECTED]
---

I'm not sure if I got the 40x restore right.  I'm also a bit concerned
about the path that returns via user_exc_return and uses SRR0/1.  I think
this is ok because we have to ensure no SRR0/1 level exceptions occur at
this point already.

- k

 arch/powerpc/kernel/asm-offsets.c |   20 +
 arch/powerpc/kernel/entry_32.S|   85 -
 arch/powerpc/kernel/head_40x.S|4 ++
 arch/powerpc/kernel/head_booke.h  |   24 ++-
 4 files changed, 129 insertions(+), 4 deletions(-)

diff --git a/arch/powerpc/kernel/asm-offsets.c 
b/arch/powerpc/kernel/asm-offsets.c
index af1d2c8..0d1a36e 100644
--- a/arch/powerpc/kernel/asm-offsets.c
+++ b/arch/powerpc/kernel/asm-offsets.c
@@ -51,6 +51,10 @@
 #include asm/iseries/alpaca.h
 #endif

+#if defined(CONFIG_BOOKE) || defined(CONFIG_40x)
+#include head_booke.h
+#endif
+
 #define DEFINE(sym, val) \
asm volatile(\n- #sym  %0  #val : : i (val))

@@ -246,6 +250,22 @@ int main(void)
DEFINE(_SRR1, STACK_FRAME_OVERHEAD+sizeof(struct pt_regs)+8);
 #endif /* CONFIG_PPC64 */

+#if defined(CONFIG_BOOKE) || defined(CONFIG_40x)
+   DEFINE(EXC_LVL_SIZE, STACK_EXC_LVL_FRAME_SIZE);
+   DEFINE(MAS0, STACK_INT_FRAME_SIZE+offsetof(struct exception_regs, 
mas0));
+   DEFINE(MAS1, STACK_INT_FRAME_SIZE+offsetof(struct exception_regs, 
mas1));
+   DEFINE(MAS2, STACK_INT_FRAME_SIZE+offsetof(struct exception_regs, 
mas2));
+   DEFINE(MAS3, STACK_INT_FRAME_SIZE+offsetof(struct exception_regs, 
mas3));
+   DEFINE(MAS6, STACK_INT_FRAME_SIZE+offsetof(struct exception_regs, 
mas6));
+   DEFINE(MAS7, STACK_INT_FRAME_SIZE+offsetof(struct exception_regs, 
mas7));
+   DEFINE(_SRR0, STACK_INT_FRAME_SIZE+offsetof(struct exception_regs, 
srr0));
+   DEFINE(_SRR1, STACK_INT_FRAME_SIZE+offsetof(struct exception_regs, 
srr1));
+   DEFINE(_CSRR0, STACK_INT_FRAME_SIZE+offsetof(struct exception_regs, 
csrr0));
+   DEFINE(_CSRR1, STACK_INT_FRAME_SIZE+offsetof(struct exception_regs, 
csrr1));
+   DEFINE(_DSRR0, STACK_INT_FRAME_SIZE+offsetof(struct exception_regs, 
dsrr0));
+   DEFINE(_DSRR1, STACK_INT_FRAME_SIZE+offsetof(struct exception_regs, 
dsrr1));
+#endif
+
DEFINE(CLONE_VM, CLONE_VM);
DEFINE(CLONE_UNTRACED, CLONE_UNTRACED);

diff --git a/arch/powerpc/kernel/entry_32.S b/arch/powerpc/kernel/entry_32.S
index 816dd54..ab86ab9 100644
--- a/arch/powerpc/kernel/entry_32.S
+++ b/arch/powerpc/kernel/entry_32.S
@@ -46,14 +46,42 @@
 #ifdef CONFIG_BOOKE
.globl  mcheck_transfer_to_handler
 mcheck_transfer_to_handler:
-   b   transfer_to_handler_full
+   mfspr   r0,SPRN_DSRR0
+   stw r0,_DSRR0(r11)
+   mfspr   r0,SPRN_DSRR1
+   stw r0,_DSRR1(r11)
+   /* fall through */

.globl  debug_transfer_to_handler
 debug_transfer_to_handler:
-   b   transfer_to_handler_full
+   mfspr   r0,SPRN_CSRR0
+   stw r0,_CSRR0(r11)
+   mfspr   r0,SPRN_CSRR1
+   stw r0,_CSRR1(r11)
+   /* fall through */

.globl  crit_transfer_to_handler
 crit_transfer_to_handler:
+#ifdef CONFIG_FSL_BOOKE
+   mfspr   r0,SPRN_MAS0
+   stw r0,MAS0(r11)
+   mfspr   r0,SPRN_MAS1
+   stw r0,MAS1(r11)
+   mfspr   r0,SPRN_MAS2
+   stw r0,MAS2(r11)
+   mfspr   r0,SPRN_MAS3
+   stw r0,MAS3(r11)
+   mfspr   r0,SPRN_MAS6
+   stw r0,MAS6(r11)
+#ifdef CONFIG_PHYS_64BIT
+   mfspr   r0,SPRN_MAS7
+   stw r0,MAS7(r11)
+#endif /* CONFIG_PHYS_64BIT */
+#endif /* CONFIG_FSL_BOOKE */
+   mfspr   r0,SPRN_SRR0
+   stw r0,_SRR0(r11)
+   mfspr   r0,SPRN_SRR1
+   stw r0,_SRR1(r11)
/* fall through */
 #endif

@@ -64,6 +92,10 @@ crit_transfer_to_handler:
stw r0,GPR10(r11)
lwz r0,[EMAIL PROTECTED](0)
stw r0,GPR11(r11)
+   mfspr   r0,SPRN_SRR0
+   stw r0,[EMAIL PROTECTED](0)
+   mfspr   r0,SPRN_SRR1
+   stw r0,[EMAIL PROTECTED](0)
/* fall through */
 #endif

@@ -846,17 +878,66 @@ exc_exit_restart_end:
exc_lvl_rfi;\
b   .;  /* prevent prefetch past exc_lvl_rfi */

+#defineRESTORE_xSRR(exc_lvl_srr0, exc_lvl_srr1)
\
+   lwz r9,_##exc_lvl_srr0(r1); \
+   lwz r10,_##exc_lvl_srr1(r1);\

Re: [PATCH 1/7] Implement arch disable/enable irq hooks.

2008-04-30 Thread Guennadi Liakhovetski

On Tue, 29 Apr 2008, Paul Mackerras wrote:

 Scott Wood writes:
 
  On Fri, Apr 25, 2008 at 02:57:24PM +0200, Guennadi Liakhovetski wrote:
   is there any specific reason, why out of these 7 patches only the first 
   one made it into the mainline? AFAICS, there has been only one comment, 
   suggesting to replace printk with dev_err on two occasions in one of 
   the patches...
  
  A while ago Paul said on IRC he'd prefer to do the TLF_SLEEPING hack more
  like the soft IRQ disabling that 64-bit uses.  I haven't yet had a chance
  to look into it, so the patch collects dust, despite the current
  implementation of TLF_SLEEPING working just fine.
 
 I have taken a closer look at the TLF_SLEEPING patch and crystallized
 my thoughts about it a bit:
 
 1. Too many ifdefs - it's only a few instructions extra, so if we're
 going to have the TLF_SLEEPING stuff we might as well have it
 unconditionally.
 
 2. It seems convoluted to me to go through transfer_to_handler_cont
 and ret_from_except when we could just get out directly through
 fast_exception_return, given that we are not calling a handler.  The
 only thing to watch out for there is that r7 and r8 haven't been
 modified (or have been restored if they have).
 
 3. The style in all the assembly code is not to have spaces after
 commas separating instruction operands.
 
 The untested patch below is what I was thinking of.  If you'd like to
 try it out, I'd be interested to hear how it goes.

The patch (with the _TLF_SLEEPING fix you mentioned in a later email) 
works for me. Shall I submit it From: you or would you prefer to post 
it yourself? But, I guess, you have to put your S-o-b under it yourself, 
don't you?

Thanks
Guennadi
---
Guennadi Liakhovetski
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev

Re: [PATCH 6/6] [POWERPC] booting-without-of: add FHCI USB, FSL MCU, FSL UPM and GPIO LEDs bindings

2008-04-30 Thread Franca, Jose (NSN - PT/Portugal - MiniMD)

On Wed, Apr 30, 2008 at 10:36:54AM +0200, Wolfgang Grandegger wrote:
 Hi Anton,
[...]
  +   [EMAIL PROTECTED],0 {
  +   #address-cells = 0;
  +   #size-cells = 0;
  +   compatible = fsl,upm-nand;
  +   reg = 1 0 1;
  +   fsl,upm-addr-offset = 16;
  +   fsl,upm-cmd-offset = 8;
  +   gpios = qe_pio_e 18 0;
  +
  +   flash {
  +   #address-cells = 1;
  +   #size-cells = 1;
  +   compatible = stmicro,NAND512W3A2BN6E;
  +
  +   [EMAIL PROTECTED] {
  +   ...
  +   };
  +   };
  +   };
 
 Where can I find the code for that binding? fsl_upm_nand.c from
 http://patchwork.ozlabs.org/linuxppc/patch?q=upmid=17306 does not parse
 OF partitions. Are there any plans to push the fsl_upm_nand driver
 upstream?

David already pushed UPM NAND driver upstream, but true, it was an old
version, i.e. without approved bindings. I'll send the update (inlining
here) if/when these bindings will be applied to the powerpc tree.

- - - -
From: Anton Vorontsov [EMAIL PROTECTED]
Subject: [NAND] update FSL UPM NAND driver for the new OF bindings

- get rid of fsl,wait-pattern and fsl,wait-write. I think this isn't
  chip-specific, and we should always do waits. I saw one board that
  didn't need fsl,wait-pattern, but I assume it was exception that
  proves general rule;
- get rid of chip-delay. Today there are no users for this, and if
  anyone really need this they should push the OF bindings beforehand;
- Now flash chips should be child nodes of the FSL UPM nand controller;
- Implement OF partition parsing.

Signed-off-by: not yet.
---
 drivers/mtd/nand/fsl_upm.c |   62 +++-
 1 files changed, 38 insertions(+), 24 deletions(-)

diff --git a/drivers/mtd/nand/fsl_upm.c b/drivers/mtd/nand/fsl_upm.c
index 1ebfd87..f91c950 100644
--- a/drivers/mtd/nand/fsl_upm.c
+++ b/drivers/mtd/nand/fsl_upm.c
@@ -36,9 +36,6 @@ struct fsl_upm_nand {
uint8_t upm_cmd_offset;
void __iomem *io_base;
int rnb_gpio;
-   const uint32_t *wait_pattern;
-   const uint32_t *wait_write;
-   int chip_delay;
 };
 
 #define to_fsl_upm_nand(mtd) container_of(mtd, struct fsl_upm_nand, mtd)
@@ -89,8 +86,7 @@ static void fun_cmd_ctrl(struct mtd_info *mtd, int cmd, 
unsigned int ctrl)
 
fsl_upm_run_pattern(fun-upm, fun-io_base, cmd);
 
-   if (fun-wait_pattern)
-   fun_wait_rnb(fun);
+   fun_wait_rnb(fun);
 }
 
 static uint8_t fun_read_byte(struct mtd_info *mtd)
@@ -116,14 +112,16 @@ static void fun_write_buf(struct mtd_info *mtd, const 
uint8_t *buf, int len)
 
for (i = 0; i  len; i++) {
out_8(fun-chip.IO_ADDR_W, buf[i]);
-   if (fun-wait_write)
-   fun_wait_rnb(fun);
+   fun_wait_rnb(fun);
}
 }
 
-static int __devinit fun_chip_init(struct fsl_upm_nand *fun)
+static int __devinit fun_chip_init(struct fsl_upm_nand *fun,
+  const struct device_node *upm_np,
+  const struct resource *io_res)
 {
int ret;
+   struct device_node *flash_np;
 #ifdef CONFIG_MTD_PARTITIONS
static const char *part_types[] = { cmdlinepart, NULL, };
 #endif
@@ -131,7 +129,7 @@ static int __devinit fun_chip_init(struct fsl_upm_nand *fun)
fun-chip.IO_ADDR_R = fun-io_base;
fun-chip.IO_ADDR_W = fun-io_base;
fun-chip.cmd_ctrl = fun_cmd_ctrl;
-   fun-chip.chip_delay = fun-chip_delay;
+   fun-chip.chip_delay = 50;
fun-chip.read_byte = fun_read_byte;
fun-chip.read_buf = fun_read_buf;
fun-chip.write_buf = fun_write_buf;
@@ -143,18 +141,42 @@ static int __devinit fun_chip_init(struct fsl_upm_nand 
*fun)
fun-mtd.priv = fun-chip;
fun-mtd.owner = THIS_MODULE;
 
+   flash_np = of_get_next_child(upm_np, NULL);
+   if (!flash_np)
+   return -ENODEV;
+
+   fun-mtd.name = kasprintf(GFP_KERNEL, %x.%s, io_res-start,
+ flash_np-name);
+   if (!fun-mtd.name) {
+   ret = -ENOMEM;
+   goto err;
+   }
+
ret = nand_scan(fun-mtd, 1);
if (ret)
-   return ret;
-
-   fun-mtd.name = fun-dev-bus_id;
+   goto err;
 
 #ifdef CONFIG_MTD_PARTITIONS
ret = parse_mtd_partitions(fun-mtd, part_types, fun-parts, 0);
+
+#ifdef CONFIG_MTD_OF_PARTS
+   if (ret = 0) {
+   ret = of_mtd_parse_partitions(fun-dev, fun-mtd,
+   flash_np, fun-parts);
+   if (ret  0) {
+   ret = -EINVAL;
+   goto err;
+   }
+   }
+#endif
if (ret  0)
-   return add_mtd_partitions(fun-mtd, fun-parts, ret);
+   ret = add_mtd_partitions(fun-mtd, fun-parts, ret);
+   else
 #endif
-

Re: FW: SKB corruption on heavy traffic

2008-04-30 Thread Gerhard Pircher

Hi,

I think I have the same problem here with all versions of the 2.6.x kernel
series (tested with kernel v2.6.8/14/16/18/25 on a PPC7455 machine with
different PCI network cards by transferring a big file over NFS/SCP). Data
corruption occurs under high load, but I don't get any kernel oops.

regards,

Gerhard

 Original-Nachricht 
 Datum: Wed, 30 Apr 2008 10:07:15 +0100
 Von: Franca, Jose (NSN - PT/Portugal - MiniMD) [EMAIL PROTECTED]
 An: linuxppc-dev@ozlabs.org, [EMAIL PROTECTED]
 Betreff: FW: SKB corruption on heavy traffic

 From our latest debugs we found that the problem occurs mainly on skbuff
 code. After some variable time kfree or kalloc result in kernel oops.
 
 -Original Message-
 From: Franca, Jose (NSN - PT/Portugal - MiniMD) 
 Sent: quarta-feira, 30 de Abril de 2008 9:44
 To: 'ext Scott Wood'
 Cc:   
 Subject: RE: SKB corruption on heavy traffic
 
 Hello!
 
   Thank you for replying!
   It't quite dificult to say if the problem exists without our
 changes, since the all software is dependent on this changes so to work
 with the hardware. I can't answer to that right now on that, but I forgot 
 to add one thing: we have ring buffer full problems on our fcc_enet
 driver from time to time. So, I think the problem could be on linux
 configurations (related to hw) because there is a lot of posts on the web 
 related to problems similar to this (none of them has really solved the
 bottom problem). 
 
 Regards,
 Filipe 
 
 -Original Message-
 From: ext Scott Wood [mailto:[EMAIL PROTECTED] 
 Sent: terça-feira, 29 de Abril de 2008 20:15
 To: Franca, Jose (NSN - PT/Portugal - MiniMD)
 Cc: linuxppc-dev@ozlabs.org; [EMAIL PROTECTED]
 Subject: Re: SKB corruption on heavy traffic
 
 On Tue, Apr 29, 2008 at 07:39:07PM +0100, Franca, Jose (NSN - PT/Portugal
 - MiniMD) wrote:
  We are developing a MPC8247 based telecom board (512MB), using
  linux 2.4 with some proprietary changes on IP stack and we are facing
  some problems when we have heavy traffic on our Ethernet interfaces...
 
 Do you see these problems without the proprietary changes, and with a
 current kernel?
 
 -Scott


-- 
Psst! Geheimtipp: Online Games kostenlos spielen bei den GMX Free Games! 
http://games.entertainment.gmx.net/de/entertainment/games/free
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev

RE: FW: SKB corruption on heavy traffic

Hi!

There was a sugestion to change slab to slub alocation method... I 
don't know quite well yet what is necessary to do this, but it seems that the 
current implementation of slub is more commonly available on 2.6 kernels, not 
in 2.4 that I use :(...
Any guesses or hints on this?


Regards!
Filipe.

-Original Message-
From: ext Gerhard Pircher [mailto:[EMAIL PROTECTED] 
Sent: quarta-feira, 30 de Abril de 2008 13:26
To: Franca, Jose (NSN - PT/Portugal - MiniMD); Scott Wood
Cc: [EMAIL PROTECTED]; linuxppc-dev@ozlabs.org
Subject: Re: FW: SKB corruption on heavy traffic

Hi,

I think I have the same problem here with all versions of the 2.6.x kernel
series (tested with kernel v2.6.8/14/16/18/25 on a PPC7455 machine with
different PCI network cards by transferring a big file over NFS/SCP). Data
corruption occurs under high load, but I don't get any kernel oops.

regards,

Gerhard

 Original-Nachricht 
 Datum: Wed, 30 Apr 2008 10:07:15 +0100
 Von: Franca, Jose (NSN - PT/Portugal - MiniMD) [EMAIL PROTECTED]
 An: linuxppc-dev@ozlabs.org, [EMAIL PROTECTED]
 Betreff: FW: SKB corruption on heavy traffic

 From our latest debugs we found that the problem occurs mainly on skbuff
 code. After some variable time kfree or kalloc result in kernel oops.
 
 -Original Message-
 From: Franca, Jose (NSN - PT/Portugal - MiniMD) 
 Sent: quarta-feira, 30 de Abril de 2008 9:44
 To: 'ext Scott Wood'
 Cc:   
 Subject: RE: SKB corruption on heavy traffic
 
 Hello!
 
   Thank you for replying!
   It't quite dificult to say if the problem exists without our
 changes, since the all software is dependent on this changes so to work
 with the hardware. I can't answer to that right now on that, but I forgot 
 to add one thing: we have ring buffer full problems on our fcc_enet
 driver from time to time. So, I think the problem could be on linux
 configurations (related to hw) because there is a lot of posts on the web 
 related to problems similar to this (none of them has really solved the
 bottom problem). 
 
 Regards,
 Filipe 
 
 -Original Message-
 From: ext Scott Wood [mailto:[EMAIL PROTECTED] 
 Sent: terça-feira, 29 de Abril de 2008 20:15
 To: Franca, Jose (NSN - PT/Portugal - MiniMD)
 Cc: linuxppc-dev@ozlabs.org; [EMAIL PROTECTED]
 Subject: Re: SKB corruption on heavy traffic
 
 On Tue, Apr 29, 2008 at 07:39:07PM +0100, Franca, Jose (NSN - PT/Portugal
 - MiniMD) wrote:
  We are developing a MPC8247 based telecom board (512MB), using
  linux 2.4 with some proprietary changes on IP stack and we are facing
  some problems when we have heavy traffic on our Ethernet interfaces...
 
 Do you see these problems without the proprietary changes, and with a
 current kernel?
 
 -Scott


-- 
Psst! Geheimtipp: Online Games kostenlos spielen bei den GMX Free Games! 
http://games.entertainment.gmx.net/de/entertainment/games/free
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev

Re: [PATCH] [POWERPC] mpc5200: Allow for fixed speed MII configurations

2008-04-30 Thread Grant Likely

On Wed, Apr 30, 2008 at 1:36 AM, Joakim Tjernlund
[EMAIL PROTECTED] wrote:

  On Tue, 2008-04-29 at 17:06 -0600, Grant Likely wrote:
   From: Grant Likely [EMAIL PROTECTED]
  
   Various improvements for configuring the MPC5200 MII link from the
   device tree:
   * Look for 'current-speed' property for fixed speed MII links

  Not that I have looked, but why can't you use the fixed-link property?

fixed-link seems to be a recent invention, whereas current-speed is
better know having already been in use with serial devices.  It seemed
to me to be a better choice, but my opinion can probably be swayed
(arguments welcome).

Cheers,
g.

-- 
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev

Re: EXT_IRQ0 @ MPC834x

2008-04-30 Thread André Schwarz


Issue solved !

IRQ has been requested with IRQF_SHARED.
Obviously this is not neccessary and caused this bogus behaviour.

Don't know if it's a bug or a feature.


Cheers,
André

Andre Schwarz schrieb:

All,

actually I'm having trouble getting the IRQ0 work on a MPC8343 with
2.6.25-rc8.
There's an external PCI device connected to it 


Regarding to the manual IRQ0 is somewhat special and has Vector 48 assigned.

Therefore my dts entry for this device looks like :

interrupt-map = 0x5800 0 0 1 ipic 0x30 0x8
 ... ;

Having a look on virq mapping gives :

mvBL-M7 cat /sys/kernel/debug/powerpc/virq_mapping
virq   hwirqchip namehost name
   16  0xe   IPIC/[EMAIL PROTECTED]/[EMAIL PROTECTED]
   17  0xf   IPIC/[EMAIL PROTECTED]/[EMAIL PROTECTED]
   18  0x9   IPIC/[EMAIL PROTECTED]/[EMAIL PROTECTED]
   20  0x00010   IPIC/[EMAIL PROTECTED]/[EMAIL PROTECTED]
   32  0x00020   IPIC/[EMAIL PROTECTED]/[EMAIL PROTECTED]
   33  0x00021   IPIC/[EMAIL PROTECTED]/[EMAIL PROTECTED]
   34  0x00022   IPIC/[EMAIL PROTECTED]/[EMAIL PROTECTED]
   38  0x00026   IPIC/[EMAIL PROTECTED]/[EMAIL PROTECTED]
   48  0x00030   IPIC/[EMAIL PROTECTED]/[EMAIL PROTECTED]


After loading the device driver (=mvbcdma) the irq shows up correctly.

mvBL-M7 cat /proc/interrupts
   CPU0
 16:603   IPIC   Level i2c-mpc
 17:  8   IPIC   Level i2c-mpc
 18:295   IPIC   Level serial
 20:341   IPIC   Level mpc83xx_spi
 32:  2   IPIC   Level enet_tx
 33:  3   IPIC   Level enet_rx
 34:  0   IPIC   Level enet_error
 38:  0   IPIC   Level ehci_hcd:usb1
 48:  0   IPIC   Level mvbcdma0
BAD:  0


As soon as the device generates an interrupt I get :

irq 48: nobody cared (try booting with the irqpoll option)
handlers:
[d18d66e8] (mvbcdma_irq+0x0/0x180 [mvbcdma])
Disabling IRQ #48


The handler _would_ have returned IRQ_RETVAL(1).
Obviously the handler isn't called at all - but why ?


Using nm on the kernel module gives :

06e8 t mvbcdma_irq

-offset 0x6e8 inside module matches with output regarding handler.


Any help is welcome !


regards,
Andre Schwarz












MATRIX VISION GmbH, Talstraße 16, DE-71570 Oppenweiler  - Registergericht: 
Amtsgericht Stuttgart, HRB 271090
Geschäftsführer: Gerhard Thullner, Werner Armingeon, Uwe Furtner
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev



MATRIX VISION GmbH, Talstraße 16, DE-71570 Oppenweiler  - Registergericht: 
Amtsgericht Stuttgart, HRB 271090
Geschäftsführer: Gerhard Thullner, Werner Armingeon, Uwe Furtner
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev

Re: [PATCH 6/6] [POWERPC] booting-without-of: add FHCI USB, FSL MCU, FSL UPM and GPIO LEDs bindings

2008-04-30 Thread Wolfgang Grandegger

Anton Vorontsov wrote:
 On Wed, Apr 30, 2008 at 10:36:54AM +0200, Wolfgang Grandegger wrote:
 Hi Anton,
 [...]
 +   [EMAIL PROTECTED],0 {
 +   #address-cells = 0;
 +   #size-cells = 0;
 +   compatible = fsl,upm-nand;
 +   reg = 1 0 1;
 +   fsl,upm-addr-offset = 16;
 +   fsl,upm-cmd-offset = 8;
 +   gpios = qe_pio_e 18 0;
 +
 +   flash {
 +   #address-cells = 1;
 +   #size-cells = 1;
 +   compatible = stmicro,NAND512W3A2BN6E;
 +
 +   [EMAIL PROTECTED] {
 +   ...
 +   };
 +   };
 +   };
 Where can I find the code for that binding? fsl_upm_nand.c from
 http://patchwork.ozlabs.org/linuxppc/patch?q=upmid=17306 does not parse
 OF partitions. Are there any plans to push the fsl_upm_nand driver
 upstream?
 
 David already pushed UPM NAND driver upstream, but true, it was an old
 version, i.e. without approved bindings. I'll send the update (inlining
 here) if/when these bindings will be applied to the powerpc tree.

OK, thanks a lot.

 - - - -
 From: Anton Vorontsov [EMAIL PROTECTED]
 Subject: [NAND] update FSL UPM NAND driver for the new OF bindings
 
 - get rid of fsl,wait-pattern and fsl,wait-write. I think this isn't
   chip-specific, and we should always do waits. I saw one board that
   didn't need fsl,wait-pattern, but I assume it was exception that
   proves general rule;
 - get rid of chip-delay. Today there are no users for this, and if
   anyone really need this they should push the OF bindings beforehand;
 - Now flash chips should be child nodes of the FSL UPM nand controller;
 - Implement OF partition parsing.

On what hardware did you test the NAND-UPM driver? Unfortunately, the
TQM8548 does not support the R/B pin and therefore GPIO support is not
needed but a chip delay. Furthermore some asm sync are required when
executing the run pattern:

  static inline int fsl_upm_run_pattern(struct fsl_upm *upm,
void __iomem *io_base, u32 mar)
  {
int ret = 0, i;
unsigned long flags;

spin_lock_irqsave(fsl_lbc_lock, flags);

out_be32(fsl_lbc_regs-mar, mar  (32 - upm-width));

asm(sync; isync; msync);

switch (upm-width) {
case 8:
out_8(io_base, 0x0);
break;
case 16:
out_be16(io_base, 0x0);
break;
case 32:
out_be32(io_base, 0x0);
break;
default:
ret = -EINVAL;
break;
}

asm(sync; isync; msync);

spin_unlock_irqrestore(fsl_lbc_lock, flags);

return ret;
  }


Is this a known problem with the MPC85xx? How do we handle it?

Wolfgang.

___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev

Re: [PATCH] [POWERPC] mpc5200: Allow for fixed speed MII configurations

2008-04-30 Thread Grant Likely

On Wed, Apr 30, 2008 at 7:10 AM, Joakim Tjernlund
[EMAIL PROTECTED] wrote:


  On Wed, 2008-04-30 at 07:07 -0600, Grant Likely wrote:
   On Wed, Apr 30, 2008 at 1:36 AM, Joakim Tjernlund
   [EMAIL PROTECTED] wrote:
   
 On Tue, 2008-04-29 at 17:06 -0600, Grant Likely wrote:
  From: Grant Likely [EMAIL PROTECTED]
 
  Various improvements for configuring the MPC5200 MII link from the
  device tree:
  * Look for 'current-speed' property for fixed speed MII links
   
 Not that I have looked, but why can't you use the fixed-link property?
  
   fixed-link seems to be a recent invention, whereas current-speed is
   better know having already been in use with serial devices.  It seemed
   to me to be a better choice, but my opinion can probably be swayed
   (arguments welcome).

  yes it is fairly new. You get alot more than just speed: Duplex/Pause
  You need these too.

duplex I've got.  pause I don't need.

Cheers,
g.

-- 
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev

Re: [PATCH] [POWERPC] mpc5200: Allow for fixed speed MII configurations


On Wed, 2008-04-30 at 07:07 -0600, Grant Likely wrote:
 On Wed, Apr 30, 2008 at 1:36 AM, Joakim Tjernlund
 [EMAIL PROTECTED] wrote:
 
   On Tue, 2008-04-29 at 17:06 -0600, Grant Likely wrote:
From: Grant Likely [EMAIL PROTECTED]
   
Various improvements for configuring the MPC5200 MII link from the
device tree:
* Look for 'current-speed' property for fixed speed MII links
 
   Not that I have looked, but why can't you use the fixed-link property?
 
 fixed-link seems to be a recent invention, whereas current-speed is
 better know having already been in use with serial devices.  It seemed
 to me to be a better choice, but my opinion can probably be swayed
 (arguments welcome).

yes it is fairly new. You get alot more than just speed: Duplex/Pause
You need these too.

 Jocke
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev

Re: [PATCH 6/6] [POWERPC] booting-without-of: add FHCI USB, FSL MCU, FSL UPM and GPIO LEDs bindings

On Wed, Apr 30, 2008 at 03:19:37PM +0200, Wolfgang Grandegger wrote:
 Anton Vorontsov wrote:
  On Wed, Apr 30, 2008 at 10:36:54AM +0200, Wolfgang Grandegger wrote:
  Hi Anton,
  [...]
  + [EMAIL PROTECTED],0 {
  + #address-cells = 0;
  + #size-cells = 0;
  + compatible = fsl,upm-nand;
  + reg = 1 0 1;
  + fsl,upm-addr-offset = 16;
  + fsl,upm-cmd-offset = 8;
  + gpios = qe_pio_e 18 0;
  +
  + flash {
  + #address-cells = 1;
  + #size-cells = 1;
  + compatible = stmicro,NAND512W3A2BN6E;
  +
  + [EMAIL PROTECTED] {
  + ...
  + };
  + };
  + };
  Where can I find the code for that binding? fsl_upm_nand.c from
  http://patchwork.ozlabs.org/linuxppc/patch?q=upmid=17306 does not parse
  OF partitions. Are there any plans to push the fsl_upm_nand driver
  upstream?
  
  David already pushed UPM NAND driver upstream, but true, it was an old
  version, i.e. without approved bindings. I'll send the update (inlining
  here) if/when these bindings will be applied to the powerpc tree.
 
 OK, thanks a lot.
 
  - - - -
  From: Anton Vorontsov [EMAIL PROTECTED]
  Subject: [NAND] update FSL UPM NAND driver for the new OF bindings
  
  - get rid of fsl,wait-pattern and fsl,wait-write. I think this isn't
chip-specific, and we should always do waits. I saw one board that
didn't need fsl,wait-pattern, but I assume it was exception that
proves general rule;
  - get rid of chip-delay. Today there are no users for this, and if
anyone really need this they should push the OF bindings beforehand;
  - Now flash chips should be child nodes of the FSL UPM nand controller;
  - Implement OF partition parsing.
 
 On what hardware did you test the NAND-UPM driver? Unfortunately, the
 TQM8548 does not support the R/B pin and therefore GPIO support is not
 needed but a chip delay. Furthermore some asm sync are required when
 executing the run pattern:

Too bad you need this. Oh well, you need to discuss property name with
the OF guys, or think out some other way to deliver the chip delay
value.

   static inline int fsl_upm_run_pattern(struct fsl_upm *upm,
 void __iomem *io_base, u32 mar)
   {
 int ret = 0, i;
 unsigned long flags;
 
 spin_lock_irqsave(fsl_lbc_lock, flags);
 
 out_be32(fsl_lbc_regs-mar, mar  (32 - upm-width));
 
 asm(sync; isync; msync);
 
 switch (upm-width) {
 case 8:
 out_8(io_base, 0x0);
 break;
 case 16:
 out_be16(io_base, 0x0);
 break;
 case 32:
 out_be32(io_base, 0x0);
 break;
 default:
 ret = -EINVAL;
 break;
 }
 
 asm(sync; isync; msync);
 
 spin_unlock_irqrestore(fsl_lbc_lock, flags);
 
 return ret;
   }
 
 
 Is this a known problem with the MPC85xx? How do we handle it?

I did test this driver on MPC8555 and MPC8360 UPMs. They didn't need
these syncs.. quite suspicious syncs, I must say. Maybe you should
check TLB setup, for the UPM NAND it should be non-cacheable and
guarded, IIRC.

-- 
Anton Vorontsov
email: [EMAIL PROTECTED]
irc://irc.freenode.net/bd2
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev

Re: [PATCH] [POWERPC] mpc5200: Allow for fixed speed MII configurations


On Wed, 2008-04-30 at 07:26 -0600, Grant Likely wrote:
 On Wed, Apr 30, 2008 at 7:10 AM, Joakim Tjernlund
 [EMAIL PROTECTED] wrote:
 
 
   On Wed, 2008-04-30 at 07:07 -0600, Grant Likely wrote:
On Wed, Apr 30, 2008 at 1:36 AM, Joakim Tjernlund
[EMAIL PROTECTED] wrote:

  On Tue, 2008-04-29 at 17:06 -0600, Grant Likely wrote:
   From: Grant Likely [EMAIL PROTECTED]
  
   Various improvements for configuring the MPC5200 MII link from the
   device tree:
   * Look for 'current-speed' property for fixed speed MII links

  Not that I have looked, but why can't you use the fixed-link property?
   
fixed-link seems to be a recent invention, whereas current-speed is
better know having already been in use with serial devices.  It seemed
to me to be a better choice, but my opinion can probably be swayed
(arguments welcome).
 
   yes it is fairly new. You get alot more than just speed: Duplex/Pause
   You need these too.
 
 duplex I've got.  pause I don't need.

dunno how you speify Half/Full Duplex, but isn't it possible that
someone else wants to use Pause in the future?
Isn't the point that everyone should use fixed-link when it is there
for this purpose?

 Jocke

  Jocke
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev

DPMS for Radeon 9600 in G5

2008-04-30 Thread Kevin Diggs

Anyone one have any suggestions on how to get DPMS working for a Radeon 
9600? Using a DVI cable?


Thanks!

kevin
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev

RE: DPMS for Radeon 9600 in G5

2008-04-30 Thread Sanders, Rob M.

Kevin,
  Have you tried posting to the xorg 
(http://lists.freedesktop.org/mailman/listinfo/xorg) mailing list?  
They helped me fix an issue I was seeing with my Radeon 9600 and G5.  I'm 
running YDL6 with two LCDs hanging
off the back of my Radeon.  

Rob



-Original Message-
From: [EMAIL PROTECTED] on behalf of Kevin Diggs
Sent: Wed 4/30/2008 11:13 AM
To: linuxppc-dev@ozlabs.org
Subject: DPMS for Radeon 9600 in G5
 
Anyone one have any suggestions on how to get DPMS working for a Radeon 
9600? Using a DVI cable?

Thanks!

kevin
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev

___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev

Re: SKB corruption on heavy traffic

On Wed, Apr 30, 2008 at 09:43:33AM +0100, Franca, Jose (NSN - PT/Portugal - 
MiniMD) wrote:
   It't quite dificult to say if the problem exists without our
   changes, since the all software is dependent on this changes so
   to work with the hardware. I can't answer to that right now on
   that, but I forgot to add one thing: we have ring buffer full
   problems on our fcc_enet driver from time to time. So, I think
   the problem could be on linux configurations (related to hw)
   because there is a lot of posts on the web related to problems
   similar to this (none of them has really solved the bottom
   problem).

One thing you could try is to enable slab debugging, rather than your
custom debugging code; this will poison the memory upon free, making it
more likely that whatever is accessing it will crash immediately rather
than just cause corruption.  Or, if you want to mantain the delay, do the
poisoning yourself.

Of course, this won't help if the access is write-only, or if the
corruption is happening via DMA.

When you say you have a full ring buffer, do you mean tx or rx?  Does it
recover gracefully?  Do you think it's caused by something other than
sending data faster than the line can support (tx) or receiving packets
faster than the cpu can handle (rx)?

Are any of the other problem reports from recent, unmodified kernels (2.4
is very old)?

-Scott
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev

Re: [PATCH] [POWERPC] mpc5200: Allow for fixed speed MII configurations

2008-04-30 Thread Franca, Jose (NSN - PT/Portugal - MiniMD)


On Wed, 2008-04-30 at 08:28 -0600, Grant Likely wrote:
 On Wed, Apr 30, 2008 at 8:16 AM, Joakim Tjernlund
 [EMAIL PROTECTED] wrote:
 
 
   On Wed, 2008-04-30 at 07:26 -0600, Grant Likely wrote:
On Wed, Apr 30, 2008 at 7:10 AM, Joakim Tjernlund
[EMAIL PROTECTED] wrote:


  On Wed, 2008-04-30 at 07:07 -0600, Grant Likely wrote:
   On Wed, Apr 30, 2008 at 1:36 AM, Joakim Tjernlund
   [EMAIL PROTECTED] wrote:
   
 On Tue, 2008-04-29 at 17:06 -0600, Grant Likely wrote:
  From: Grant Likely [EMAIL PROTECTED]
 
  Various improvements for configuring the MPC5200 MII link from 
  the
  device tree:
  * Look for 'current-speed' property for fixed speed MII links
   
 Not that I have looked, but why can't you use the fixed-link 
  property?
  
   fixed-link seems to be a recent invention, whereas current-speed is
   better know having already been in use with serial devices.  It 
  seemed
   to me to be a better choice, but my opinion can probably be swayed
   (arguments welcome).

  yes it is fairly new. You get alot more than just speed: Duplex/Pause
  You need these too.
   
duplex I've got.  pause I don't need.
 
   dunno how you speify Half/Full Duplex, but isn't it possible that
   someone else wants to use Pause in the future?
   Isn't the point that everyone should use fixed-link when it is there
   for this purpose?
 
 The format of the data is pretty much entirely device dependent (much
 like interrupt and gpio specifiers are controller dependent).  I see
 any need in trying to define a common format for this data since it is
 entirely local to the device.  ie. there is requirement for this data
 to be in the same format for every device.  Also, by not trying to
 lock it down into a common format it gives future devices freedom to
 specify additional flags and parameters in the data.
 
 so,
 * gianfar:  needs 5 bits of data.
 * 5200 FEC: only needs 2.
 
 As for 'current-speed' vs. 'fixed-link'.  I just think 'current-speed'
 is the better name.  :-)

Then some day someone else needs Pause or need to control Duplex. Then
you end up with several impl. Maybe fixed-link isn't the best 
name, but it is designed for this purpose.

Anyhow, I not going to argue this more. Seems like I am the
only one thinking it would be better to use fixed-link instead so I 
guess I am wrong here.

 Jocke
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev

RE: SKB corruption on heavy traffic

Ok... We will try to enable debug on slab! :)
Ring buffer full occurs on tx in spite of having free bd's in the ring,
it doesn't use them... And it does not recover.
The problems that I refered are from previous kernel versions to ours
(our base of development was 2.4.31) and even on 2.6 kernels.

Filipe

-Original Message-
From: ext Scott Wood [mailto:[EMAIL PROTECTED] 
Sent: quarta-feira, 30 de Abril de 2008 16:01
To: Franca, Jose (NSN - PT/Portugal - MiniMD)
Cc: linuxppc-dev@ozlabs.org; [EMAIL PROTECTED]
Subject: Re: SKB corruption on heavy traffic

On Wed, Apr 30, 2008 at 09:43:33AM +0100, Franca, Jose (NSN -
PT/Portugal - MiniMD) wrote:
   It't quite dificult to say if the problem exists without our
   changes, since the all software is dependent on this changes so
   to work with the hardware. I can't answer to that right now on
   that, but I forgot to add one thing: we have ring buffer full
   problems on our fcc_enet driver from time to time. So, I think
   the problem could be on linux configurations (related to hw)
   because there is a lot of posts on the web related to problems
   similar to this (none of them has really solved the bottom
   problem).

One thing you could try is to enable slab debugging, rather than your
custom debugging code; this will poison the memory upon free, making it
more likely that whatever is accessing it will crash immediately rather
than just cause corruption.  Or, if you want to mantain the delay, do
the
poisoning yourself.

Of course, this won't help if the access is write-only, or if the
corruption is happening via DMA.

When you say you have a full ring buffer, do you mean tx or rx?  Does it
recover gracefully?  Do you think it's caused by something other than
sending data faster than the line can support (tx) or receiving packets
faster than the cpu can handle (rx)?

Are any of the other problem reports from recent, unmodified kernels
(2.4
is very old)?

-Scott
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev

[PATCH] [POWERPC] Xilinx: Fix compile warnings

arch/powerpc/sysdev/xilinx_intc.c: In function âxilinx_intc_initâ:
arch/powerpc/sysdev/xilinx_intc.c:111: warning: format â%08Xâ expects type 
âunsigned intâ, but argument 2 has type âresource_size_tâ
drivers/char/xilinx_hwicap/xilinx_hwicap.c: In function âhwicap_setupâ:
drivers/char/xilinx_hwicap/xilinx_hwicap.c:626: warning: cast to pointer from 
integer of different size
drivers/char/xilinx_hwicap/xilinx_hwicap.c:646: warning: format â%xâ 
expects type âunsigned intâ, but argument 6 has type âresource_size_tâ

Signed-off-by: Kumar Gala [EMAIL PROTECTED]
---
 arch/powerpc/sysdev/xilinx_intc.c  |2 +-
 drivers/char/xilinx_hwicap/xilinx_hwicap.c |6 +++---
 2 files changed, 4 insertions(+), 4 deletions(-)

diff --git a/arch/powerpc/sysdev/xilinx_intc.c 
b/arch/powerpc/sysdev/xilinx_intc.c
index ba8eea2..b7aefd0 100644
--- a/arch/powerpc/sysdev/xilinx_intc.c
+++ b/arch/powerpc/sysdev/xilinx_intc.c
@@ -107,7 +107,7 @@ xilinx_intc_init(struct device_node *np)
}
regs = ioremap(res.start, 32);

-   printk(KERN_INFO Xilinx intc at 0x%08X mapped to 0x%p\n,
+   printk(KERN_INFO Xilinx intc at 0x%08LX mapped to 0x%p\n,
res.start, regs);

/* Setup interrupt controller */
diff --git a/drivers/char/xilinx_hwicap/xilinx_hwicap.c 
b/drivers/char/xilinx_hwicap/xilinx_hwicap.c
index dfe6907..3edf1fc 100644
--- a/drivers/char/xilinx_hwicap/xilinx_hwicap.c
+++ b/drivers/char/xilinx_hwicap/xilinx_hwicap.c
@@ -623,8 +623,8 @@ static int __devinit hwicap_setup(struct device *dev, int 
id,

if (!request_mem_region(drvdata-mem_start,
drvdata-mem_size, DRIVER_NAME)) {
-   dev_err(dev, Couldn't lock memory region at %p\n,
-   (void *)regs_res-start);
+   dev_err(dev, Couldn't lock memory region at %Lx\n,
+   regs_res-start);
retval = -EBUSY;
goto failed1;
}
@@ -643,7 +643,7 @@ static int __devinit hwicap_setup(struct device *dev, int 
id,
mutex_init(drvdata-sem);
drvdata-is_open = 0;

-   dev_info(dev, ioremap %lx to %p with size %x\n,
+   dev_info(dev, ioremap %lx to %p with size %Lx\n,
 (unsigned long int)drvdata-mem_start,
drvdata-base_address, drvdata-mem_size);

-- 
1.5.4.1
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev

Re: [PATCH] [POWERPC] Xilinx: Fix compile warnings

2008-04-30 Thread Stephen Rothwell

Hi Kumar,

On Wed, 30 Apr 2008 10:25:46 -0500 (CDT) Kumar Gala [EMAIL PROTECTED] wrote:

 arch/powerpc/sysdev/xilinx_intc.c: In function âxilinx_intc_initâ:
 arch/powerpc/sysdev/xilinx_intc.c:111: warning: format â%08Xâ expects 
 type âunsigned intâ, but argument 2 has type âresource_size_tâ
 drivers/char/xilinx_hwicap/xilinx_hwicap.c: In function âhwicap_setupâ:
 drivers/char/xilinx_hwicap/xilinx_hwicap.c:626: warning: cast to pointer from 
 integer of different size
 drivers/char/xilinx_hwicap/xilinx_hwicap.c:646: warning: format â%xâ 
 expects type âunsigned intâ, but argument 6 has type âresource_size_tâ

If you compile with LANG=C, you don't get those strange annotations in
your error messages ...

The fix looks good though.
-- 
Cheers,
Stephen Rothwell[EMAIL PROTECTED]
http://www.canb.auug.org.au/~sfr/


pgpgZvO3HERAm.pgp
Description: PGP signature
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev

[PATCH] [POWERPC] devres: Add devm_ioremap_flags()

From: Emil Medve [EMAIL PROTECTED]

We provide an ioremap_flags so provide a coresphonding devm_ioremap_flags.

Signed-off-by: Emil Medve [EMAIL PROTECTED]
Signed-off-by: Kumar Gala [EMAIL PROTECTED]
---

Which tree should this go through, powerpc.git?

 arch/powerpc/lib/Makefile |1 +
 include/asm-powerpc/io.h  |8 +++-
 include/linux/io.h|1 +
 lib/devres.c  |2 +-
 4 files changed, 10 insertions(+), 2 deletions(-)

diff --git a/arch/powerpc/lib/Makefile b/arch/powerpc/lib/Makefile
index 4bb023f..f1d2cdc 100644
--- a/arch/powerpc/lib/Makefile
+++ b/arch/powerpc/lib/Makefile
@@ -23,3 +23,4 @@ obj-$(CONFIG_SMP) += locks.o
 endif

 obj-$(CONFIG_PPC_LIB_RHEAP) += rheap.o
+obj-$(CONFIG_HAS_IOMEM)+= devres.o
diff --git a/include/asm-powerpc/io.h b/include/asm-powerpc/io.h
index afae069..3b8c334 100644
--- a/include/asm-powerpc/io.h
+++ b/include/asm-powerpc/io.h
@@ -2,7 +2,7 @@
 #define _ASM_POWERPC_IO_H
 #ifdef __KERNEL__

-/*
+/*
  * This program is free software; you can redistribute it and/or
  * modify it under the terms of the GNU General Public License
  * as published by the Free Software Foundation; either version
@@ -18,6 +18,9 @@ extern int check_legacy_ioport(unsigned long base_port);
 #define _PNPWRP0xa79
 #define PNPBIOS_BASE   0xf000

+#include linux/device.h
+#include linux/io.h
+
 #include linux/compiler.h
 #include asm/page.h
 #include asm/byteorder.h
@@ -744,6 +747,9 @@ static inline void * bus_to_virt(unsigned long address)

 #define clrsetbits_8(addr, clear, set) clrsetbits(8, addr, clear, set)

+void __iomem *devm_ioremap_flags(struct device *dev, resource_size_t offset,
+size_t size, unsigned long flags);
+
 #endif /* __KERNEL__ */

 #endif /* _ASM_POWERPC_IO_H */
diff --git a/include/linux/io.h b/include/linux/io.h
index 831f57c..7a390cf 100644
--- a/include/linux/io.h
+++ b/include/linux/io.h
@@ -58,6 +58,7 @@ static inline void devm_ioport_unmap(struct device *dev, void 
__iomem *addr)
 }
 #endif

+void devm_ioremap_release(struct device *dev, void *res);
 void __iomem * devm_ioremap(struct device *dev, resource_size_t offset,
unsigned long size);
 void __iomem * devm_ioremap_nocache(struct device *dev, resource_size_t offset,
diff --git a/lib/devres.c b/lib/devres.c
index 26c87c4..72c8909 100644
--- a/lib/devres.c
+++ b/lib/devres.c
@@ -2,7 +2,7 @@
 #include linux/io.h
 #include linux/module.h

-static void devm_ioremap_release(struct device *dev, void *res)
+void devm_ioremap_release(struct device *dev, void *res)
 {
iounmap(*(void __iomem **)res);
 }
-- 
1.5.4.1

___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev

[PATCH v2] [POWERPC] devres: Add devm_ioremap_flags()

From: Emil Medve [EMAIL PROTECTED]

We provide an ioremap_flags so provide a coresphonding devm_ioremap_flags.

Signed-off-by: Emil Medve [EMAIL PROTECTED]
Signed-off-by: Kumar Gala [EMAIL PROTECTED]
---

Forgot to commit the actual implemtation in arch/powerpc/lib/devres.c

Which tree should this go through, powerpc.git?

- k

 arch/powerpc/lib/Makefile |1 +
 arch/powerpc/lib/devres.c |   33 +
 include/asm-powerpc/io.h  |8 +++-
 include/linux/io.h|1 +
 lib/devres.c  |2 +-
 5 files changed, 43 insertions(+), 2 deletions(-)
 create mode 100644 arch/powerpc/lib/devres.c

diff --git a/arch/powerpc/lib/Makefile b/arch/powerpc/lib/Makefile
index 4bb023f..f1d2cdc 100644
--- a/arch/powerpc/lib/Makefile
+++ b/arch/powerpc/lib/Makefile
@@ -23,3 +23,4 @@ obj-$(CONFIG_SMP) += locks.o
 endif

 obj-$(CONFIG_PPC_LIB_RHEAP) += rheap.o
+obj-$(CONFIG_HAS_IOMEM)+= devres.o
diff --git a/arch/powerpc/lib/devres.c b/arch/powerpc/lib/devres.c
new file mode 100644
index 000..b73c64b
--- /dev/null
+++ b/arch/powerpc/lib/devres.c
@@ -0,0 +1,33 @@
+#include linux/device.h  /* devres_*(), devm_ioremap_release() */
+#include linux/io.h  /* ioremap_flags() */
+#include linux/module.h  /* EXPORT_SYMBOL() */
+
+/**
+ * devm_ioremap_flags - Managed ioremap_flags()
+ * @dev: Generic device to remap IO address for
+ * @offset: BUS offset to map
+ * @size: Size of map
+ * @flags: Page flags
+ *
+ * Managed ioremap_flags().  Map is automatically unmapped on driver
+ * detach.
+ */
+void __iomem *devm_ioremap_flags(struct device *dev, resource_size_t offset,
+size_t size, unsigned long flags)
+{
+   void __iomem **ptr, *addr;
+
+   ptr = devres_alloc(devm_ioremap_release, sizeof(*ptr), GFP_KERNEL);
+   if (!ptr)
+   return NULL;
+
+   addr = ioremap_flags(offset, size, flags);
+   if (addr) {
+   *ptr = addr;
+   devres_add(dev, ptr);
+   } else
+   devres_free(ptr);
+
+   return addr;
+}
+EXPORT_SYMBOL(devm_ioremap_flags);
diff --git a/include/asm-powerpc/io.h b/include/asm-powerpc/io.h
index afae069..3b8c334 100644
--- a/include/asm-powerpc/io.h
+++ b/include/asm-powerpc/io.h
@@ -2,7 +2,7 @@
 #define _ASM_POWERPC_IO_H
 #ifdef __KERNEL__

-/*
+/*
  * This program is free software; you can redistribute it and/or
  * modify it under the terms of the GNU General Public License
  * as published by the Free Software Foundation; either version
@@ -18,6 +18,9 @@ extern int check_legacy_ioport(unsigned long base_port);
 #define _PNPWRP0xa79
 #define PNPBIOS_BASE   0xf000

+#include linux/device.h
+#include linux/io.h
+
 #include linux/compiler.h
 #include asm/page.h
 #include asm/byteorder.h
@@ -744,6 +747,9 @@ static inline void * bus_to_virt(unsigned long address)

 #define clrsetbits_8(addr, clear, set) clrsetbits(8, addr, clear, set)

+void __iomem *devm_ioremap_flags(struct device *dev, resource_size_t offset,
+size_t size, unsigned long flags);
+
 #endif /* __KERNEL__ */

 #endif /* _ASM_POWERPC_IO_H */
diff --git a/include/linux/io.h b/include/linux/io.h
index 831f57c..7a390cf 100644
--- a/include/linux/io.h
+++ b/include/linux/io.h
@@ -58,6 +58,7 @@ static inline void devm_ioport_unmap(struct device *dev, void 
__iomem *addr)
 }
 #endif

+void devm_ioremap_release(struct device *dev, void *res);
 void __iomem * devm_ioremap(struct device *dev, resource_size_t offset,
unsigned long size);
 void __iomem * devm_ioremap_nocache(struct device *dev, resource_size_t offset,
diff --git a/lib/devres.c b/lib/devres.c
index 26c87c4..72c8909 100644
--- a/lib/devres.c
+++ b/lib/devres.c
@@ -2,7 +2,7 @@
 #include linux/io.h
 #include linux/module.h

-static void devm_ioremap_release(struct device *dev, void *res)
+void devm_ioremap_release(struct device *dev, void *res)
 {
iounmap(*(void __iomem **)res);
 }
-- 
1.5.4.1

___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev

RE: [PATCH] [POWERPC] Xilinx: Fix compile warnings

2008-04-30 Thread Stephen Neuendorffer

For what it's worth:
Acked-by: Stephen Neuendorffer [EMAIL PROTECTED]

There's one or two other things I've been meaning to clean up, such as the 
section mismatch on hwicap_of_match, too.

Steve

 -Original Message-
 From: [EMAIL PROTECTED] [mailto:linuxppc-dev-
 [EMAIL PROTECTED] On Behalf Of Kumar Gala
 Sent: Wednesday, April 30, 2008 8:26 AM
 To: Josh Boyer
 Cc: linuxppc-dev@ozlabs.org
 Subject: [PATCH] [POWERPC] Xilinx: Fix compile warnings
 
 arch/powerpc/sysdev/xilinx_intc.c: In function â€˜xilinx_intc_initâ€™:
 arch/powerpc/sysdev/xilinx_intc.c:111: warning: format â€˜%08Xâ€™ expects 
 type â€˜unsigned intâ€™,
 but argument 2 has type â€˜resource_size_tâ€™
 drivers/char/xilinx_hwicap/xilinx_hwicap.c: In function â€˜hwicap_setupâ€™:
 drivers/char/xilinx_hwicap/xilinx_hwicap.c:626: warning: cast to pointer from 
 integer of different
 size
 drivers/char/xilinx_hwicap/xilinx_hwicap.c:646: warning: format â€˜%xâ€™ 
 expects type â€˜unsigned
 intâ€™, but argument 6 has type â€˜resource_size_tâ€™
 
 Signed-off-by: Kumar Gala [EMAIL PROTECTED]
 ---
  arch/powerpc/sysdev/xilinx_intc.c  |2 +-
  drivers/char/xilinx_hwicap/xilinx_hwicap.c |6 +++---
  2 files changed, 4 insertions(+), 4 deletions(-)
 
 diff --git a/arch/powerpc/sysdev/xilinx_intc.c 
 b/arch/powerpc/sysdev/xilinx_intc.c
 index ba8eea2..b7aefd0 100644
 --- a/arch/powerpc/sysdev/xilinx_intc.c
 +++ b/arch/powerpc/sysdev/xilinx_intc.c
 @@ -107,7 +107,7 @@ xilinx_intc_init(struct device_node *np)
   }
   regs = ioremap(res.start, 32);
 
 - printk(KERN_INFO Xilinx intc at 0x%08X mapped to 0x%p\n,
 + printk(KERN_INFO Xilinx intc at 0x%08LX mapped to 0x%p\n,
   res.start, regs);
 
   /* Setup interrupt controller */
 diff --git a/drivers/char/xilinx_hwicap/xilinx_hwicap.c 
 b/drivers/char/xilinx_hwicap/xilinx_hwicap.c
 index dfe6907..3edf1fc 100644
 --- a/drivers/char/xilinx_hwicap/xilinx_hwicap.c
 +++ b/drivers/char/xilinx_hwicap/xilinx_hwicap.c
 @@ -623,8 +623,8 @@ static int __devinit hwicap_setup(struct device *dev, int 
 id,
 
   if (!request_mem_region(drvdata-mem_start,
   drvdata-mem_size, DRIVER_NAME)) {
 - dev_err(dev, Couldn't lock memory region at %p\n,
 - (void *)regs_res-start);
 + dev_err(dev, Couldn't lock memory region at %Lx\n,
 + regs_res-start);
   retval = -EBUSY;
   goto failed1;
   }
 @@ -643,7 +643,7 @@ static int __devinit hwicap_setup(struct device *dev, int 
 id,
   mutex_init(drvdata-sem);
   drvdata-is_open = 0;
 
 - dev_info(dev, ioremap %lx to %p with size %x\n,
 + dev_info(dev, ioremap %lx to %p with size %Lx\n,
(unsigned long int)drvdata-mem_start,
   drvdata-base_address, drvdata-mem_size);
 
 --
 1.5.4.1
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev

[PATCH v4] sysdev,mv64x60: MV64x60 device bus

2008-04-30 Thread Remi Machet

For each mv64360 entry in the OpenFirmware database, add the 
registration of an of_bus to take care of devices connected to
the MV64x60 asynchronous devices controller.
This change makes it possible for those devices to be detected by 
drivers that support the of_platform without having a custom call 
for each of them in the board file.

Signed-off-by: Remi Machet ([EMAIL PROTECTED])
---
Changes:
v2: Use the compatible field to detect devices to register (on Dale Farnsworth
suggestion).
v3: Added __initdata to variable of_mv64x60_devices (thanks to Stephen Rothwell 
for pointing that out).
v4: Re-wrote the patch description.

 arch/powerpc/sysdev/mv64x60_dev.c |   10 ++
 1 files changed, 10 insertions(+)

diff --git a/arch/powerpc/sysdev/mv64x60_dev.c 
b/arch/powerpc/sysdev/mv64x60_dev.c
index 41af122..c38695e 100644
--- a/arch/powerpc/sysdev/mv64x60_dev.c
+++ b/arch/powerpc/sysdev/mv64x60_dev.c
@@ -15,6 +15,7 @@
 #include linux/console.h
 #include linux/mv643xx.h
 #include linux/platform_device.h
+#include linux/of_platform.h
 
 #include asm/prom.h
 
@@ -25,6 +26,11 @@
  * PowerPC of_platform_bus_type.  They support platform_bus_type instead.
  */
 
+static struct of_device_id __initdata of_mv64x60_devices[] = {
+   { .compatible = marvell,mv64306-devctrl, },
+   {}
+};
+
 /*
  * Create MPSC platform devices
  */
@@ -482,6 +488,10 @@ static int __init mv64x60_device_setup(void)
of_node_put(np);
}
 
+   /* Now add every node that is on the device bus (type is devicectrl */
+   for_each_compatible_node(np, NULL, marvell,mv64360)
+   of_platform_bus_probe(np, of_mv64x60_devices, NULL);
+
return 0;
 }
 arch_initcall(mv64x60_device_setup);


___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev

Re: [PATCH 1/7] Implement arch disable/enable irq hooks.

On Tue, Apr 29, 2008 at 02:44:30PM +1000, Paul Mackerras wrote:
 3. The style in all the assembly code is not to have spaces after
 commas separating instruction operands.

I'll do that if that's what is prefered, but how did that come about as
the style used?  It's different from what we do in C, and adding the
space helps readability in asm as well...

 The untested patch below is what I was thinking of.  If you'd like to
 try it out, I'd be interested to hear how it goes.

It works for me.

-Scott
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev

Re: [PATCH 6/6] [POWERPC] booting-without-of: add FHCI USB, FSL MCU, FSL UPM and GPIO LEDs bindings

2008-04-30 Thread Wolfgang Grandegger

Anton Vorontsov wrote:
 On Wed, Apr 30, 2008 at 03:19:37PM +0200, Wolfgang Grandegger wrote:
 Anton Vorontsov wrote:
 On Wed, Apr 30, 2008 at 10:36:54AM +0200, Wolfgang Grandegger wrote:
 Hi Anton,
 [...]
 + [EMAIL PROTECTED],0 {
 + #address-cells = 0;
 + #size-cells = 0;
 + compatible = fsl,upm-nand;
 + reg = 1 0 1;
 + fsl,upm-addr-offset = 16;
 + fsl,upm-cmd-offset = 8;
 + gpios = qe_pio_e 18 0;
 +
 + flash {
 + #address-cells = 1;
 + #size-cells = 1;
 + compatible = stmicro,NAND512W3A2BN6E;
 +
 + [EMAIL PROTECTED] {
 + ...
 + };
 + };
 + };
 Where can I find the code for that binding? fsl_upm_nand.c from
 http://patchwork.ozlabs.org/linuxppc/patch?q=upmid=17306 does not parse
 OF partitions. Are there any plans to push the fsl_upm_nand driver
 upstream?
 David already pushed UPM NAND driver upstream, but true, it was an old
 version, i.e. without approved bindings. I'll send the update (inlining
 here) if/when these bindings will be applied to the powerpc tree.
 OK, thanks a lot.

 - - - -
 From: Anton Vorontsov [EMAIL PROTECTED]
 Subject: [NAND] update FSL UPM NAND driver for the new OF bindings

 - get rid of fsl,wait-pattern and fsl,wait-write. I think this isn't
   chip-specific, and we should always do waits. I saw one board that
   didn't need fsl,wait-pattern, but I assume it was exception that
   proves general rule;
 - get rid of chip-delay. Today there are no users for this, and if
   anyone really need this they should push the OF bindings beforehand;
 - Now flash chips should be child nodes of the FSL UPM nand controller;
 - Implement OF partition parsing.
 On what hardware did you test the NAND-UPM driver? Unfortunately, the
 TQM8548 does not support the R/B pin and therefore GPIO support is not
 needed but a chip delay. Furthermore some asm sync are required when
 executing the run pattern:
 
 Too bad you need this. Oh well, you need to discuss property name with
 the OF guys, or think out some other way to deliver the chip delay
 value.

OK.

   static inline int fsl_upm_run_pattern(struct fsl_upm *upm,
 void __iomem *io_base, u32 mar)
   {
 int ret = 0, i;
 unsigned long flags;

 spin_lock_irqsave(fsl_lbc_lock, flags);

 out_be32(fsl_lbc_regs-mar, mar  (32 - upm-width));

 asm(sync; isync; msync);

 switch (upm-width) {
 case 8:
 out_8(io_base, 0x0);
 break;
 case 16:
 out_be16(io_base, 0x0);
 break;
 case 32:
 out_be32(io_base, 0x0);
 break;
 default:
 ret = -EINVAL;
 break;
 }

 asm(sync; isync; msync);

 spin_unlock_irqrestore(fsl_lbc_lock, flags);

 return ret;
   }


 Is this a known problem with the MPC85xx? How do we handle it?
 
 I did test this driver on MPC8555 and MPC8360 UPMs. They didn't need
 these syncs.. quite suspicious syncs, I must say. Maybe you should
 check TLB setup, for the UPM NAND it should be non-cacheable and
 guarded, IIRC.

I have that. Are you sure about the e500 CPUs. I have not seen any
MPC85xx board in U-Boot or Linux BSP using FSL UPM. Sometimes these
magic sync instructions seem to be needed, e.g., in the MPC8548 manual I
find:

  Also, an msync assembly instruction must be executed after each I2C
   register read/write access to guarantee in-order execution.

Can somebody (from freescale?) sched some light on that issue?

TIA.

Wolfgang.


___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev

Re: [PATCH v2] [POWERPC] devres: Add devm_ioremap_flags()

2008-04-30 Thread Andrew Morton

On Wed, 30 Apr 2008 11:08:51 -0500 (CDT)
Kumar Gala [EMAIL PROTECTED] wrote:

 From: Emil Medve [EMAIL PROTECTED]
 
 We provide an ioremap_flags so provide a coresphonding devm_ioremap_flags.
 
 Signed-off-by: Emil Medve [EMAIL PROTECTED]
 Signed-off-by: Kumar Gala [EMAIL PROTECTED]
 ---
 
 Forgot to commit the actual implemtation in arch/powerpc/lib/devres.c
 
 Which tree should this go through, powerpc.git?

I'd say so, yes.

 arch/powerpc/lib/Makefile |1 +
 arch/powerpc/lib/devres.c |   33 +
 include/asm-powerpc/io.h  |8 +++-
 include/linux/io.h|1 +
 lib/devres.c  |2 +-

___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev

Re: [PATCH] docbook: fix fatal rapidio yet again (and more to come)

On Wed, 30 Apr 2008 11:35:00 -0700 Andrew Morton wrote:

 On Tue, 29 Apr 2008 20:10:55 -0700 (PDT)
 Randy.Dunlap [EMAIL PROTECTED] wrote:
 
  From: Randy Dunlap [EMAIL PROTECTED]
  
  Don't refer to file that no longer exists:
  docproc: linux-2.6.25-git14/arch/powerpc/kernel/rio.c: No such file or 
  directory
  
  Signed-off-by: Randy Dunlap [EMAIL PROTECTED]
  ---
   Documentation/DocBook/rapidio.tmpl |1 -
   1 file changed, 1 deletion(-)
  
  --- linux-2.6.25-git14.orig/Documentation/DocBook/rapidio.tmpl
  +++ linux-2.6.25-git14/Documentation/DocBook/rapidio.tmpl
  @@ -133,7 +133,6 @@
   !Idrivers/rapidio/rio-sysfs.c
/sect1
sect1 id=PPC32_supporttitlePPC32 support/title
  -!Iarch/powerpc/kernel/rio.c
   !Earch/powerpc/sysdev/fsl_rio.c
   !Iarch/powerpc/sysdev/fsl_rio.c
/sect1
 
 grumble.
 
 This is a subset of rapidio-fix-docbook-references.patch, but I appear to
 be unable to interest anyone in merging/reviewing/accepting/anything-else
 that quite large set of patches.
 
 Guys, those patches were sent six weeks ago and it now looks like they will
 miss 2.6.26.  This is pretty slack of us.  Help?

There's nothing there that can hurt.  (famous last words)

Just merge it.

---
~Randy
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev

Re: [RFC] [PATCH] vmemmap fixes to use smaller pages

Benjamin Herrenschmidt wrote:
 This patch changes vmemmap to use a different region (region 0xf) of the
 address space whose page size can be dynamically configured at boot.
 
 The problem with the current approach of always using 16M pages is that
 it's not well suited to machines that have small amounts of memory such
 as small partitions on pseries, or PS3's.
 
 In fact, on the PS3, failure to allocate the 16M page backing vmmemmap
 tends to prevent hotplugging the HV's additional memory, thus limiting
 the available memory even more, from my experience down to something
 like 80M total, which makes it really not very useable.
 
 The logic used by my match to choose the vmemmap page size is:
 
  - If 16M pages are available and there's 1G or more RAM at boot, use that 
 size.
  - Else if 64K pages are available, use that
  - Else use 4K pages
 
 I've tested on a POWER6 (16M pages) and on an iSeries POWER3 (4K pages)
 and it seems to work fine.
 
 However, when attempting to test on a PS3, it didn't boot.
 
 In fact, it doesn't boot without my patch with current upstream. 


Yes, this is a know problem I am working on, related to recent
changes in bootmem.  Errors with: 'sparse_early_usemap_alloc: allocation 
failed'.


I tried
 booting 2.6.25 with a ps3_defconfig and that doesn't work neither
 (though at least when doing the later, I do get a black screen  no
 sync, like of ps3fb failed monitor detection, while with current
 upstream, I just get the last kexec messages and nothing happens).


This should work.  You are the first to report a problem with 
2.6.25.  Could you double check your build, and if you still have
trouble, put your vmlinux somewhere I can get it?


 Since the PS3 boot failures are impossible to debug unless your email is
 @sony* and you have the special magic tools, I'll let Geoff try the
 patch out.


OK, I'll try it with the upstream kernel from last week and report
within the next day or so.


-Geoff

___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev

Re: [PATCH] docbook: fix fatal rapidio yet again (and more to come)

2008-04-30 Thread Andrew Morton

On Wed, 30 Apr 2008 14:01:12 -0500
Kumar Gala [EMAIL PROTECTED] wrote:

 
 On Apr 30, 2008, at 1:35 PM, Andrew Morton wrote:
  On Tue, 29 Apr 2008 20:10:55 -0700 (PDT)
  Randy.Dunlap [EMAIL PROTECTED] wrote:
 
  From: Randy Dunlap [EMAIL PROTECTED]
 
  Don't refer to file that no longer exists:
  docproc: linux-2.6.25-git14/arch/powerpc/kernel/rio.c: No such file  
  or directory
 
  Signed-off-by: Randy Dunlap [EMAIL PROTECTED]
  ---
  Documentation/DocBook/rapidio.tmpl |1 -
  1 file changed, 1 deletion(-)
 
  --- linux-2.6.25-git14.orig/Documentation/DocBook/rapidio.tmpl
  +++ linux-2.6.25-git14/Documentation/DocBook/rapidio.tmpl
  @@ -133,7 +133,6 @@
  !Idrivers/rapidio/rio-sysfs.c
   /sect1
   sect1 id=PPC32_supporttitlePPC32 support/title
  -!Iarch/powerpc/kernel/rio.c
  !Earch/powerpc/sysdev/fsl_rio.c
  !Iarch/powerpc/sysdev/fsl_rio.c
   /sect1
 
  grumble.
 
  This is a subset of rapidio-fix-docbook-references.patch, but I  
  appear to
  be unable to interest anyone in merging/reviewing/accepting/anything- 
  else
  that quite large set of patches.
 
  Guys, those patches were sent six weeks ago and it now looks like  
  they will
  miss 2.6.26.  This is pretty slack of us.  Help?
 
 Odd.  I thought Paul had picked up a docbook RapidIO patch from you in  
 the latest merge round.
 

Well it's more than a patch.  The six-week-old patch series is:

rapidio-add-memory-mapping-driver-to-rapidio.patch
rapidio-add-rapidio-space-allocation-bitmap-arithmetic.patch
rapidio-add-fsl-rapidio-controller-memory-ops-functions.patch
rapidio-add-the-rapidio-master-port-maintance-and-doorbell-window-to-space-resources.patch
rapidio-add-rapidio-proc-fs-for-memory-mapping-debugging.patch
rapidio-add-the-memory-mapping-support-in-rionet-driver.patch
rapidio-fix-docbook-references.patch
rapidio-fix-kernel-doc-problems.patch

totalling:

 arch/powerpc/sysdev/fsl_rio.c   |   13 +
 include/linux/rio.h |   10 
 drivers/net/Kconfig |   10 
 drivers/net/rionet.c|  324 ++
 drivers/rapidio/Makefile|1 
 drivers/rapidio/rio.c   |   10 
 drivers/rapidio/sallocator/Kconfig  |9 
 drivers/rapidio/sallocator/Makefile |   12 +
 drivers/rapidio/sallocator/bitmap.c |  384 
 include/linux/rio.h |   10 
 include/linux/rio_drv.h |   41 +++
 16 files changed, 1425 insertions(+), 14 deletions(-)


(seems that I forgot to cc Jeff on the rionet change too).


Oh well.  If nobody puts their hand up in the next 24 hours or so I'll just
send it all in to Linus.

___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev

drivers/net/fec_8xx config problem

2008-04-30 Thread Becky Bruce

I just noticed that the fec_8xx driver is not currently reachable via  
menuconfig because it depends on 8XX instead of 8xx.  It looks like  
this change occurred in commit  
d1c0a65fb597697d1fbce4eadf42b84f70483edc, almost a year ago:


diff --git a/drivers/net/fec_8xx/Kconfig b/drivers/net/fec_8xx/Kconfig
index a84c232..afb34de 100644
--- a/drivers/net/fec_8xx/Kconfig+++ b/drivers/net/fec_8xx/Kconfig
@@ -1,6 +1,6 @@
 config FEC_8XX
tristate Motorola 8xx FEC driver
-   depends on NET_ETHERNET  8xx
+   depends on 8XX
select MII


Since nobody has noticed this problem, I'm wondering if this driver  
is still in (infrequent) use, or if it's been superseded and should  
be removed, or if I'm just completely missing something with respect  
to the use of 8XX instead of 8xx.


I'm happy to submit a patch to correct this, I'm just not sure what  
the right answer is.


Thanks,
Becky



___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev

Re: drivers/net/fec_8xx config problem

2008-04-30 Thread Becky Bruce



On Apr 30, 2008, at 2:20 PM, Scott Wood wrote:

On Wed, Apr 30, 2008 at 02:19:21PM -0500, Becky Bruce wrote:

I just noticed that the fec_8xx driver is not currently reachable via
menuconfig because it depends on 8XX instead of 8xx.

[snip]

Since nobody has noticed this problem, I'm wondering if this driver
is still in (infrequent) use, or if it's been superseded and should
be removed, or if I'm just completely missing something with respect
to the use of 8XX instead of 8xx.


It's been superseded by drivers/net/fs_enet.


Is there any reason we haven't removed it?  If not, I can push a  
patch to yank it.


Cheers,
B

___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev

Re: drivers/net/fec_8xx config problem

On Wed, Apr 30, 2008 at 02:24:19PM -0500, Becky Bruce wrote:
 
 On Apr 30, 2008, at 2:20 PM, Scott Wood wrote:
 On Wed, Apr 30, 2008 at 02:19:21PM -0500, Becky Bruce wrote:
 I just noticed that the fec_8xx driver is not currently reachable via
 menuconfig because it depends on 8XX instead of 8xx.
 [snip]
 Since nobody has noticed this problem, I'm wondering if this driver
 is still in (infrequent) use, or if it's been superseded and should
 be removed, or if I'm just completely missing something with respect
 to the use of 8XX instead of 8xx.
 
 It's been superseded by drivers/net/fs_enet.
 
 Is there any reason we haven't removed it?

To keep arch/ppc/8xx_io company? :-)

 If not, I can push a patch to yank it.

I have no objection.

-Scott
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev

patch devres-support-addresses-greater-than-an-unsigned-long-via-dev_ioremap.patch added to gregkh-2.6 tree

2008-04-30 Thread gregkh


This is a note to let you know that I've just added the patch titled

 Subject: devres: support addresses greater than an unsigned long via 
dev_ioremap

to my gregkh-2.6 tree.  Its filename is

 
devres-support-addresses-greater-than-an-unsigned-long-via-dev_ioremap.patch

This tree can be found at 
http://www.kernel.org/pub/linux/kernel/people/gregkh/gregkh-2.6/patches/


From [EMAIL PROTECTED]  Wed Apr 30 11:27:51 2008
From: Kumar Gala [EMAIL PROTECTED]
Date: Tue, 29 Apr 2008 10:25:48 -0500 (CDT)
Subject: devres: support addresses greater than an unsigned long via dev_ioremap
To: Greg KH [EMAIL PROTECTED]
Cc: Tejun Heo [EMAIL PROTECTED], Jeff Garzik [EMAIL PROTECTED], Andrew 
Morton [EMAIL PROTECTED], linuxppc-dev@ozlabs.org list 
linuxppc-dev@ozlabs.org, lkml Mailing List [EMAIL PROTECTED], Jesse Barnes 
[EMAIL PROTECTED]
Message-ID: [EMAIL PROTECTED]


Use a resource_size_t instead of unsigned long since some arch's are
capable of having ioremap deal with addresses greater than the size of a
unsigned long.

Signed-off-by: Kumar Gala [EMAIL PROTECTED]
Cc: Tejun Heo [EMAIL PROTECTED]
Cc: Jeff Garzik [EMAIL PROTECTED]
Signed-off-by: Greg Kroah-Hartman [EMAIL PROTECTED]

---
 include/linux/io.h |4 ++--
 lib/devres.c   |4 ++--
 2 files changed, 4 insertions(+), 4 deletions(-)

--- a/include/linux/io.h
+++ b/include/linux/io.h
@@ -58,9 +58,9 @@ static inline void devm_ioport_unmap(str
 }
 #endif
 
-void __iomem * devm_ioremap(struct device *dev, unsigned long offset,
+void __iomem * devm_ioremap(struct device *dev, resource_size_t offset,
unsigned long size);
-void __iomem * devm_ioremap_nocache(struct device *dev, unsigned long offset,
+void __iomem * devm_ioremap_nocache(struct device *dev, resource_size_t offset,
unsigned long size);
 void devm_iounmap(struct device *dev, void __iomem *addr);
 int check_signature(const volatile void __iomem *io_addr,
--- a/lib/devres.c
+++ b/lib/devres.c
@@ -20,7 +20,7 @@ static int devm_ioremap_match(struct dev
  *
  * Managed ioremap().  Map is automatically unmapped on driver detach.
  */
-void __iomem *devm_ioremap(struct device *dev, unsigned long offset,
+void __iomem *devm_ioremap(struct device *dev, resource_size_t offset,
   unsigned long size)
 {
void __iomem **ptr, *addr;
@@ -49,7 +49,7 @@ EXPORT_SYMBOL(devm_ioremap);
  * Managed ioremap_nocache().  Map is automatically unmapped on driver
  * detach.
  */
-void __iomem *devm_ioremap_nocache(struct device *dev, unsigned long offset,
+void __iomem *devm_ioremap_nocache(struct device *dev, resource_size_t offset,
   unsigned long size)
 {
void __iomem **ptr, *addr;


Patches currently in gregkh-2.6 which might be from [EMAIL PROTECTED] are

driver-core/devres-support-addresses-greater-than-an-unsigned-long-via-dev_ioremap.patch
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev

[PATCH v2 4/6] [POWERPC] QE: implement support for the GPIO LIB API

This is needed to access QE GPIOs via Linux GPIO API.

Signed-off-by: Anton Vorontsov [EMAIL PROTECTED]
---

Updated per Timur Tabi's comments.

 Documentation/powerpc/booting-without-of.txt |   27 +
 arch/powerpc/sysdev/qe_lib/Kconfig   |9 ++
 arch/powerpc/sysdev/qe_lib/Makefile  |1 +
 arch/powerpc/sysdev/qe_lib/gpio.c|  146 ++
 include/asm-powerpc/qe.h |3 +
 5 files changed, 186 insertions(+), 0 deletions(-)
 create mode 100644 arch/powerpc/sysdev/qe_lib/gpio.c

diff --git a/Documentation/powerpc/booting-without-of.txt 
b/Documentation/powerpc/booting-without-of.txt
index fc7a235..c1044ee 100644
--- a/Documentation/powerpc/booting-without-of.txt
+++ b/Documentation/powerpc/booting-without-of.txt
@@ -1738,6 +1738,33 @@ platforms are moved over to use the 
flattened-device-tree model.
..
};
 
+   Note that par_io nodes are obsolete, and should not be used for
+   the new device trees. Instead, each Par I/O bank should be represented
+   via its own gpio-controller node:
+
+   Required properties:
+   - #gpio-cells : should be 2.
+   - compatible : should be fsl,chip-qe-pario-bank,
+ fsl,mpc8323-qe-pario-bank.
+   - reg : offset to the register set and its length.
+   - gpio-controller : node to identify gpio controllers.
+
+   Example:
+   qe_pio_a: [EMAIL PROTECTED] {
+   #gpio-cells = 2;
+   compatible = fsl,mpc8360-qe-pario-bank,
+fsl,mpc8323-qe-pario-bank;
+   reg = 0x1400 0x18;
+   gpio-controller;
+   };
+
+   qe_pio_e: [EMAIL PROTECTED] {
+   #gpio-cells = 2;
+   compatible = fsl,mpc8360-qe-pario-bank,
+fsl,mpc8323-qe-pario-bank;
+   reg = 0x1460 0x18;
+   gpio-controller;
+   };
 
vi) Pin configuration nodes
 
diff --git a/arch/powerpc/sysdev/qe_lib/Kconfig 
b/arch/powerpc/sysdev/qe_lib/Kconfig
index 76ffbc4..4bb18f5 100644
--- a/arch/powerpc/sysdev/qe_lib/Kconfig
+++ b/arch/powerpc/sysdev/qe_lib/Kconfig
@@ -24,3 +24,12 @@ config QE_USB
bool
help
  QE USB Host Controller support
+
+config QE_GPIO
+   bool QE GPIO support
+   depends on QUICC_ENGINE
+   select GENERIC_GPIO
+   select HAVE_GPIO_LIB
+   help
+ Say Y here if you're going to use hardware that connects to the
+ QE GPIOs.
diff --git a/arch/powerpc/sysdev/qe_lib/Makefile 
b/arch/powerpc/sysdev/qe_lib/Makefile
index e9ff888..f1855c1 100644
--- a/arch/powerpc/sysdev/qe_lib/Makefile
+++ b/arch/powerpc/sysdev/qe_lib/Makefile
@@ -7,3 +7,4 @@ obj-$(CONFIG_UCC)   += ucc.o
 obj-$(CONFIG_UCC_SLOW) += ucc_slow.o
 obj-$(CONFIG_UCC_FAST) += ucc_fast.o
 obj-$(CONFIG_QE_USB)   += usb.o
+obj-$(CONFIG_QE_GPIO)  += gpio.o
diff --git a/arch/powerpc/sysdev/qe_lib/gpio.c 
b/arch/powerpc/sysdev/qe_lib/gpio.c
new file mode 100644
index 000..c712e24
--- /dev/null
+++ b/arch/powerpc/sysdev/qe_lib/gpio.c
@@ -0,0 +1,146 @@
+/*
+ * QUICC Engine GPIOs
+ *
+ * Copyright (c) MontaVista Software, Inc. 2008.
+ *
+ * Author: Anton Vorontsov [EMAIL PROTECTED]
+ *
+ * This program is free software; you can redistribute  it and/or modify it
+ * under  the terms of  the GNU General  Public License as published by the
+ * Free Software Foundation;  either version 2 of the  License, or (at your
+ * option) any later version.
+ */
+
+#include linux/kernel.h
+#include linux/spinlock.h
+#include linux/io.h
+#include linux/of.h
+#include linux/of_gpio.h
+#include linux/gpio.h
+#include asm/qe.h
+
+struct qe_gpio_chip {
+   struct of_mm_gpio_chip mm_gc;
+   spinlock_t lock;
+
+   /* shadowed data register to clear/set bits safely */
+   u32 cpdata;
+};
+
+static inline struct qe_gpio_chip *
+to_qe_gpio_chip(struct of_mm_gpio_chip *mm_gc)
+{
+   return container_of(mm_gc, struct qe_gpio_chip, mm_gc);
+}
+
+static void qe_gpio_save_regs(struct of_mm_gpio_chip *mm_gc)
+{
+   struct qe_gpio_chip *qe_gc = to_qe_gpio_chip(mm_gc);
+   struct qe_pio_regs __iomem *regs = mm_gc-regs;
+
+   qe_gc-cpdata = in_be32(regs-cpdata);
+}
+
+static int qe_gpio_get(struct gpio_chip *gc, unsigned int gpio)
+{
+   struct of_mm_gpio_chip *mm_gc = to_of_mm_gpio_chip(gc);
+   struct qe_pio_regs __iomem *regs = mm_gc-regs;
+   u32 pin_mask = 1  (QE_PIO_PINS - 1 - gpio);
+
+   return in_be32(regs-cpdata)  pin_mask;
+}
+
+static void qe_gpio_set(struct gpio_chip *gc, unsigned int gpio, int val)
+{
+   struct of_mm_gpio_chip *mm_gc = to_of_mm_gpio_chip(gc);
+   struct qe_gpio_chip *qe_gc = to_qe_gpio_chip(mm_gc);
+   struct qe_pio_regs __iomem *regs = mm_gc-regs;
+   unsigned long flags;
+   u32 pin_mask = 1  (QE_PIO_PINS - 1 - gpio);
+
+   spin_lock_irqsave(qe_gc-lock, flags);
+
+   if (val)
+   qe_gc-cpdata |= pin_mask;
+   else
+

Re: [PATCH v2 4/6] [POWERPC] QE: implement support for the GPIO LIB API

2008-04-30 Thread Timur Tabi

Anton Vorontsov wrote:

 +   Example:
 + qe_pio_a: [EMAIL PROTECTED] {
 + #gpio-cells = 2;
 + compatible = fsl,mpc8360-qe-pario-bank,
 +  fsl,mpc8323-qe-pario-bank;

I know this is an example, but would we ever include both compatible strings in
one DTS?  Isn't the norm something like:

fsl,mpc8360-qe-pario-bank, fsl,qe-pario-bank;

I.e. specific version, then generic version?

Otherwise, every time we introduce a new QE part, we'll have to update *every*
QE-enabled device tree *and* the QE gpio driver.

 +static int qe_gpio_get(struct gpio_chip *gc, unsigned int gpio)
 +{
 + struct of_mm_gpio_chip *mm_gc = to_of_mm_gpio_chip(gc);
 + struct qe_pio_regs __iomem *regs = mm_gc-regs;
 + u32 pin_mask = 1  (QE_PIO_PINS - 1 - gpio);
 +
 + return in_be32(regs-cpdata)  pin_mask;
 +}

Return value should be u32, not int.

-- 
Timur Tabi
Linux kernel developer at Freescale
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev

Re: [PATCH] docbook: fix fatal rapidio yet again (and more to come)



On Apr 30, 2008, at 2:12 PM, Andrew Morton wrote:

On Wed, 30 Apr 2008 14:01:12 -0500
Kumar Gala [EMAIL PROTECTED] wrote:



On Apr 30, 2008, at 1:35 PM, Andrew Morton wrote:

On Tue, 29 Apr 2008 20:10:55 -0700 (PDT)
Randy.Dunlap [EMAIL PROTECTED] wrote:


From: Randy Dunlap [EMAIL PROTECTED]

Don't refer to file that no longer exists:
docproc: linux-2.6.25-git14/arch/powerpc/kernel/rio.c: No such file
or directory

Signed-off-by: Randy Dunlap [EMAIL PROTECTED]
---
Documentation/DocBook/rapidio.tmpl |1 -
1 file changed, 1 deletion(-)

--- linux-2.6.25-git14.orig/Documentation/DocBook/rapidio.tmpl
+++ linux-2.6.25-git14/Documentation/DocBook/rapidio.tmpl
@@ -133,7 +133,6 @@
!Idrivers/rapidio/rio-sysfs.c
/sect1
sect1 id=PPC32_supporttitlePPC32 support/title
-!Iarch/powerpc/kernel/rio.c
!Earch/powerpc/sysdev/fsl_rio.c
!Iarch/powerpc/sysdev/fsl_rio.c
/sect1


grumble.

This is a subset of rapidio-fix-docbook-references.patch, but I
appear to
be unable to interest anyone in merging/reviewing/accepting/ 
anything-

else
that quite large set of patches.

Guys, those patches were sent six weeks ago and it now looks like
they will
miss 2.6.26.  This is pretty slack of us.  Help?


Odd.  I thought Paul had picked up a docbook RapidIO patch from you  
in

the latest merge round.



Well it's more than a patch.  The six-week-old patch series is:

rapidio-add-memory-mapping-driver-to-rapidio.patch
rapidio-add-rapidio-space-allocation-bitmap-arithmetic.patch
rapidio-add-fsl-rapidio-controller-memory-ops-functions.patch
rapidio-add-the-rapidio-master-port-maintance-and-doorbell-window-to- 
space-resources.patch

rapidio-add-rapidio-proc-fs-for-memory-mapping-debugging.patch
rapidio-add-the-memory-mapping-support-in-rionet-driver.patch
rapidio-fix-docbook-references.patch
rapidio-fix-kernel-doc-problems.patch

totalling:

arch/powerpc/sysdev/fsl_rio.c   |   13 +
include/linux/rio.h |   10
drivers/net/Kconfig |   10
drivers/net/rionet.c|  324 ++ 


drivers/rapidio/Makefile|1
drivers/rapidio/rio.c   |   10
drivers/rapidio/sallocator/Kconfig  |9
drivers/rapidio/sallocator/Makefile |   12 +
drivers/rapidio/sallocator/bitmap.c |  384 ++ 
++

include/linux/rio.h |   10
include/linux/rio_drv.h |   41 +++
16 files changed, 1425 insertions(+), 14 deletions(-)


(seems that I forgot to cc Jeff on the rionet change too).


Oh well.  If nobody puts their hand up in the next 24 hours or so  
I'll just

send it all in to Linus.


I'm raising my hand.  The memory map driver needs further review.  If  
the Docbook issues can be applied w/o the other patches I suggest we  
go forward with those.


- k
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev

[Cbe-oss-dev] [PATCH] Updated: Reworked Cell OProfile: SPU mutex lock fix

2008-04-30 Thread Carl Love

This is a reworked patch to fix the SPU data storage.  Currently, the 
SPU escape sequences and program counter data is being added directly 
into the kernel buffer without holding the buffer_mutex lock.  This 
patch changes how the data is stored.  A new function,
oprofile_add_value, is added into the oprofile driver to allow adding
generic data to the per cpu buffers.  This enables a series of calls
to the oprofile_add_value to enter the needed SPU escape sequences 
and SPU program data into the kernel buffer via the per cpu buffers
without any additional processing. The oprofile_add_value function is
generic so it could be used by other architecures as well provided
the needed postprocessing was added to opreport.

Finally, this patch backs out the changes previously added to the 
oprofile generic code for handling the architecture specific 
ops.sync_start and ops.sync_stop that allowed the architecture
to skip the per CPU buffer creation.

Signed-off-by: Carl Love [EMAIL PROTECTED]

Index: Cell_kernel_4_15_2008/arch/powerpc/oprofile/cell/pr_util.h
===
--- Cell_kernel_4_15_2008.orig/arch/powerpc/oprofile/cell/pr_util.h
+++ Cell_kernel_4_15_2008/arch/powerpc/oprofile/cell/pr_util.h
@@ -20,11 +20,6 @@
 #include asm/cell-regs.h
 #include asm/spu.h
 
-/* Defines used for sync_start */
-#define SKIP_GENERIC_SYNC 0
-#define SYNC_START_ERROR -1
-#define DO_GENERIC_SYNC 1
-
 struct spu_overlay_info {  /* map of sections within an SPU overlay */
unsigned int vma;   /* SPU virtual memory address from elf */
unsigned int size;  /* size of section from elf */
@@ -85,7 +80,7 @@ void stop_spu_profiling(void);
 int spu_sync_start(void);
 
 /* remove the hooks */
-int spu_sync_stop(void);
+void spu_sync_stop(void);
 
 /* Record SPU program counter samples to the oprofile event buffer. */
 void spu_sync_buffer(int spu_num, unsigned int *samples,
Index: Cell_kernel_4_15_2008/arch/powerpc/oprofile/cell/spu_task_sync.c
===
---
Cell_kernel_4_15_2008.orig/arch/powerpc/oprofile/cell/spu_task_sync.c
+++ Cell_kernel_4_15_2008/arch/powerpc/oprofile/cell/spu_task_sync.c
@@ -31,11 +31,12 @@
 
 #define RELEASE_ALL 
 
-static DEFINE_SPINLOCK(buffer_lock);
+static DEFINE_SPINLOCK(add_value_lock);
 static DEFINE_SPINLOCK(cache_lock);
 static int num_spu_nodes;
 int spu_prof_num_nodes;
 int last_guard_val[MAX_NUMNODES * 8];
+static int spu_ctx_sw_seen[MAX_NUMNODES * 8];
 
 /* Container for caching information about an active SPU task. */
 struct cached_info {
@@ -289,6 +290,7 @@ static int process_context_switch(struct
int retval;
unsigned int offset = 0;
unsigned long spu_cookie = 0, app_dcookie;
+   int cpu_buf;
 
retval = prepare_cached_spu_info(spu, objectId);
if (retval)
@@ -303,17 +305,28 @@ static int process_context_switch(struct
goto out;
}
 
-   /* Record context info in event buffer */
-   spin_lock_irqsave(buffer_lock, flags);
-   add_event_entry(ESCAPE_CODE);
-   add_event_entry(SPU_CTX_SWITCH_CODE);
-   add_event_entry(spu-number);
-   add_event_entry(spu-pid);
-   add_event_entry(spu-tgid);
-   add_event_entry(app_dcookie);
-   add_event_entry(spu_cookie);
-   add_event_entry(offset);
-   spin_unlock_irqrestore(buffer_lock, flags);
+   /* Record context info in event buffer.  Note, there are 4x more
+* SPUs then CPUs.  Map the SPU events/data for a given SPU to
+* the same CPU buffer.  Need to ensure the cntxt switch data and
+* samples stay in order.
+*/
+   cpu_buf = spu-number  2;
+   spin_lock_irqsave(add_value_lock, flags);
+   oprofile_add_value(ESCAPE_CODE, cpu_buf);
+   oprofile_add_value(SPU_CTX_SWITCH_CODE, cpu_buf);
+   oprofile_add_value(spu-number, cpu_buf);
+   oprofile_add_value(spu-pid, cpu_buf);
+   oprofile_add_value(spu-tgid, cpu_buf);
+   oprofile_add_value(app_dcookie, cpu_buf);
+   oprofile_add_value(spu_cookie, cpu_buf);
+   oprofile_add_value(offset, cpu_buf);
+
+   /* Set flag to indicate SPU PC data can now be written out.  If
+* the SPU program counter data is seen before an SPU context
+* record is seen, the postprocessing will fail.
+*/
+   spu_ctx_sw_seen[spu-number] = 1;
+   spin_unlock_irqrestore(add_value_lock, flags);
smp_wmb();  /* insure spu event buffer updates are written */
/* don't want entries intermingled... */
 out:
@@ -333,7 +346,6 @@ static int spu_active_notify(struct noti
unsigned long flags;
struct spu *the_spu = data;
 
-   pr_debug(SPU event notification arrived\n);
if (!val) {
spin_lock_irqsave(cache_lock, flags);
retval = release_cached_info(the_spu-number);
@@ -363,38 +375,38 @@ static int

Re: [PATCH 1/7] Implement arch disable/enable irq hooks.

On Wed, Apr 30, 2008 at 11:01:47PM +0200, Segher Boessenkool wrote:
 3. The style in all the assembly code is not to have spaces after
 commas separating instruction operands.
 
 I'll do that if that's what is prefered, but how did that come about as
 the style used?  It's different from what we do in C,
 
 But this isn't C code, it's assembler code.

Enh.  It's a comma-delineated list in both cases.

 PowerPC assembler code (and most other assembler code) doesn't use
 spaces here usually.

Looking at other arches, it seems pretty evenly split.

 and adding the space helps readability in asm as well...
 
 Many people disagree ;-)

Compressionhelpsreadability?

 Anyway, it's better to keep a consistent style, whatever that style
 is, don't you agree?

Not if it's GNU-style. :-)

-Scott
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev

Re: [RFC] [PATCH] vmemmap fixes to use smaller pages


On Wed, 2008-04-30 at 12:06 -0700, Geoff Levand wrote:
  booting 2.6.25 with a ps3_defconfig and that doesn't work neither
  (though at least when doing the later, I do get a black screen  no
  sync, like of ps3fb failed monitor detection, while with current
  upstream, I just get the last kexec messages and nothing happens).
 
 
 This should work.  You are the first to report a problem with 
 2.6.25.  Could you double check your build, and if you still have
 trouble, put your vmlinux somewhere I can get it?

I'll dbl check today. It could be bad monitor detection...

 OK, I'll try it with the upstream kernel from last week and report
 within the next day or so.

Thanks.

Cheers,
Ben.


___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev

Re: [PATCH] [POWERPC] Set lower flag bits in regs-trap to indicate debug level exception


On Wed, 2008-04-30 at 05:44 -0500, Kumar Gala wrote:
 We use the low bits of regs-trap as flag bits.  We already indicate
 critical and machine check level exceptions via this mechanism.  Extend it
 to indicate debug level exceptions.
 
 Signed-off-by: Kumar Gala [EMAIL PROTECTED]

Ack.


___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev

Re: [PATCH v2] [POWERPC] devres: Add devm_ioremap_flags()


On Wed, 2008-04-30 at 11:08 -0500, Kumar Gala wrote:
 From: Emil Medve [EMAIL PROTECTED]
 
 We provide an ioremap_flags so provide a coresphonding devm_ioremap_flags.
 
 Signed-off-by: Emil Medve [EMAIL PROTECTED]
 Signed-off-by: Kumar Gala [EMAIL PROTECTED]
 ---
 
 Forgot to commit the actual implemtation in arch/powerpc/lib/devres.c
 
 Which tree should this go through, powerpc.git?

Let's call it ioremap_prot instead please. I'm about to change
ioremap_flags to ioremap_prot anyways. Keep the flags/prot argument
unsigned long for now (it can be argued it should be a pgprot but that
hasn't been sorted out completely).

Cheers,
Ben.

 - k
 
  arch/powerpc/lib/Makefile |1 +
  arch/powerpc/lib/devres.c |   33 +
  include/asm-powerpc/io.h  |8 +++-
  include/linux/io.h|1 +
  lib/devres.c  |2 +-
  5 files changed, 43 insertions(+), 2 deletions(-)
  create mode 100644 arch/powerpc/lib/devres.c
 
 diff --git a/arch/powerpc/lib/Makefile b/arch/powerpc/lib/Makefile
 index 4bb023f..f1d2cdc 100644
 --- a/arch/powerpc/lib/Makefile
 +++ b/arch/powerpc/lib/Makefile
 @@ -23,3 +23,4 @@ obj-$(CONFIG_SMP)   += locks.o
  endif
 
  obj-$(CONFIG_PPC_LIB_RHEAP) += rheap.o
 +obj-$(CONFIG_HAS_IOMEM)  += devres.o
 diff --git a/arch/powerpc/lib/devres.c b/arch/powerpc/lib/devres.c
 new file mode 100644
 index 000..b73c64b
 --- /dev/null
 +++ b/arch/powerpc/lib/devres.c
 @@ -0,0 +1,33 @@
 +#include linux/device.h/* devres_*(), devm_ioremap_release() */
 +#include linux/io.h/* ioremap_flags() */
 +#include linux/module.h/* EXPORT_SYMBOL() */
 +
 +/**
 + * devm_ioremap_flags - Managed ioremap_flags()
 + * @dev: Generic device to remap IO address for
 + * @offset: BUS offset to map
 + * @size: Size of map
 + * @flags: Page flags
 + *
 + * Managed ioremap_flags().  Map is automatically unmapped on driver
 + * detach.
 + */
 +void __iomem *devm_ioremap_flags(struct device *dev, resource_size_t offset,
 +  size_t size, unsigned long flags)
 +{
 + void __iomem **ptr, *addr;
 +
 + ptr = devres_alloc(devm_ioremap_release, sizeof(*ptr), GFP_KERNEL);
 + if (!ptr)
 + return NULL;
 +
 + addr = ioremap_flags(offset, size, flags);
 + if (addr) {
 + *ptr = addr;
 + devres_add(dev, ptr);
 + } else
 + devres_free(ptr);
 +
 + return addr;
 +}
 +EXPORT_SYMBOL(devm_ioremap_flags);
 diff --git a/include/asm-powerpc/io.h b/include/asm-powerpc/io.h
 index afae069..3b8c334 100644
 --- a/include/asm-powerpc/io.h
 +++ b/include/asm-powerpc/io.h
 @@ -2,7 +2,7 @@
  #define _ASM_POWERPC_IO_H
  #ifdef __KERNEL__
 
 -/*
 +/*
   * This program is free software; you can redistribute it and/or
   * modify it under the terms of the GNU General Public License
   * as published by the Free Software Foundation; either version
 @@ -18,6 +18,9 @@ extern int check_legacy_ioport(unsigned long base_port);
  #define _PNPWRP  0xa79
  #define PNPBIOS_BASE 0xf000
 
 +#include linux/device.h
 +#include linux/io.h
 +
  #include linux/compiler.h
  #include asm/page.h
  #include asm/byteorder.h
 @@ -744,6 +747,9 @@ static inline void * bus_to_virt(unsigned long address)
 
  #define clrsetbits_8(addr, clear, set) clrsetbits(8, addr, clear, set)
 
 +void __iomem *devm_ioremap_flags(struct device *dev, resource_size_t offset,
 +  size_t size, unsigned long flags);
 +
  #endif /* __KERNEL__ */
 
  #endif /* _ASM_POWERPC_IO_H */
 diff --git a/include/linux/io.h b/include/linux/io.h
 index 831f57c..7a390cf 100644
 --- a/include/linux/io.h
 +++ b/include/linux/io.h
 @@ -58,6 +58,7 @@ static inline void devm_ioport_unmap(struct device *dev, 
 void __iomem *addr)
  }
  #endif
 
 +void devm_ioremap_release(struct device *dev, void *res);
  void __iomem * devm_ioremap(struct device *dev, resource_size_t offset,
   unsigned long size);
  void __iomem * devm_ioremap_nocache(struct device *dev, resource_size_t 
 offset,
 diff --git a/lib/devres.c b/lib/devres.c
 index 26c87c4..72c8909 100644
 --- a/lib/devres.c
 +++ b/lib/devres.c
 @@ -2,7 +2,7 @@
  #include linux/io.h
  #include linux/module.h
 
 -static void devm_ioremap_release(struct device *dev, void *res)
 +void devm_ioremap_release(struct device *dev, void *res)
  {
   iounmap(*(void __iomem **)res);
  }

___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev

Re: [PATCH] [POWERPC] Set lower flag bits in regs-trap to indicate debug level exception



On Apr 30, 2008, at 4:43 PM, Benjamin Herrenschmidt wrote:


On Wed, 2008-04-30 at 05:44 -0500, Kumar Gala wrote:

We use the low bits of regs-trap as flag bits.  We already indicate
critical and machine check level exceptions via this mechanism.   
Extend it

to indicate debug level exceptions.

Signed-off-by: Kumar Gala [EMAIL PROTECTED]


Ack.


that was the easy one :)

- k

___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev

Re: [PATCH v2] [POWERPC] devres: Add devm_ioremap_flags()



On Apr 30, 2008, at 4:42 PM, Benjamin Herrenschmidt wrote:


On Wed, 2008-04-30 at 11:08 -0500, Kumar Gala wrote:

From: Emil Medve [EMAIL PROTECTED]

We provide an ioremap_flags so provide a coresphonding  
devm_ioremap_flags.


Signed-off-by: Emil Medve [EMAIL PROTECTED]
Signed-off-by: Kumar Gala [EMAIL PROTECTED]
---

Forgot to commit the actual implemtation in arch/powerpc/lib/devres.c

Which tree should this go through, powerpc.git?


Let's call it ioremap_prot instead please. I'm about to change
ioremap_flags to ioremap_prot anyways. Keep the flags/prot argument
unsigned long for now (it can be argued it should be a pgprot but that
hasn't been sorted out completely).


No problem.  I've always wondered why ioremap_* aren't better  
specified by generic code.


- k

___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev

Re: [PATCH] [POWERPC] Rework EXC_LEVEL_EXCEPTION_PROLOG code


On Wed, 2008-04-30 at 04:27 -0500, Kumar Gala wrote:
 * Cleanup the code a bit my allocating an INT_FRAME on our exception
   stack there by make references go from GPR11-INT_FRAME_SIZE(r8) to
   just GPR(r8)
^^ 11 ?

 * simplify {lvl}_transfer_to_handler code by moving the copying of the
   temp registers we use if we come from user space into the PROLOG
 * If the exception came from kernel mode copy thread_info flags,
   preempt, and task pointer from the process thread_info.
 
 Signed-off-by: Kumar Gala [EMAIL PROTECTED]
 ---
 
 I'm not sure if the copying of TI_FLAGS, TI_PREEMPT, and TI_TASK
 are really needed.  I'm a bit concerned what to do if we get a
 CriticalInput while in kernel mode and the handler causes a reschedule.

Well, reschedule or signal, either way, you can't handle them on the way
out. Maybe an option there is to set the flag in the normal kernel
stack's thread info and trigger an interrupt asap via the PIT so things
get handled ?

 
 diff --git a/arch/powerpc/kernel/head_booke.h 
 b/arch/powerpc/kernel/head_booke.h
 index d647e05..78baec5 100644
 --- a/arch/powerpc/kernel/head_booke.h
 +++ b/arch/powerpc/kernel/head_booke.h
 @@ -78,12 +78,12 @@
   slwir8,r8,2;\
   addis   r8,r8,[EMAIL PROTECTED];\
   lwz r8,[EMAIL PROTECTED](r8);   \
 - addir8,r8,THREAD_SIZE;
 + addir8,r8,THREAD_SIZE-INT_FRAME_SIZE;
  #else
  #define BOOKE_LOAD_EXC_LEVEL_STACK(level)\
   lis r8,[EMAIL PROTECTED];   \
   lwz r8,[EMAIL PROTECTED](r8);   \
 - addir8,r8,THREAD_SIZE;
 + addir8,r8,THREAD_SIZE-INT_FRAME_SIZE;
  #endif

Nothing specific to your patch, but those level##_STACK_TOP seem to
be pretty badly named if you end up -adding- THREAD_SIZE to actually
get to the stack's top. Do they really contain the stack top or do
they in fact contain the stack base/bottom ?

  /*
 @@ -97,22 +97,35 @@
  #define EXC_LEVEL_EXCEPTION_PROLOG(exc_level, exc_level_srr0, 
 exc_level_srr1) \
   mtspr   exc_level##_SPRG,r8; \
   BOOKE_LOAD_EXC_LEVEL_STACK(exc_level);/* r8 points to the exc_level 
 stack*/ \
 - stw r10,GPR10-INT_FRAME_SIZE(r8);\
 - stw r11,GPR11-INT_FRAME_SIZE(r8);\
 + stw r9,GPR9(r8);/* save various registers  */\
 + stw r10,GPR10(r8);   \
 + stw r11,GPR11(r8);   \
 + mfspr   r11,SPRN_SPRG3; /* if from user, start at top of   */\
 + lwz r11,THREAD_INFO-THREAD(r11); /* this thread's kernel stack */\
 + addir11,r11,THREAD_SIZE-INT_FRAME_SIZE; /* Alloc exception frm */\

So you do the above whether it will actually be needed or not right ?
 
   mfcrr10;/* save CR in r10 for now  */\
 - mfspr   r11,exc_level_srr1; /* check whether user or kernel*/\
 - andi.   r11,r11,MSR_PR;  \
 - mr  r11,r8;  \
 - mfspr   r8,exc_level##_SPRG; \
 + mfspr   r9,exc_level_srr1;  /* check whether user or kernel*/\
 + andi.   r9,r9,MSR_PR;\
   beq 1f;  \
   /* COMING FROM USER MODE */  \
 - mfspr   r11,SPRN_SPRG3; /* if from user, start at top of   */\
 - lwz r11,THREAD_INFO-THREAD(r11); /* this thread's kernel stack */\
 - addir11,r11,THREAD_SIZE; \
 -1:   subir11,r11,INT_FRAME_SIZE; /* Allocate an exception frame */\
 + lwz r9,GPR9(r8);/* copy regs from exception stack  */\
 + stw r9,GPR9(r11);\
 + lwz r9,GPR10(r8);\
 + stw r9,GPR10(r11);   \
 + lwz r9,GPR11(r8);\
 + stw r9,GPR11(r11);   \
 + b   2f;  \

Are we concerned with performances here or not ? Because using the same
reg all along isn't the best ... 

 + /* COMING FROM PRIV MODE */  \
 +1:   lwz r9,TI_FLAGS-THREAD_SIZE(r11);\
 + stw r9,TI_FLAGS-THREAD_SIZE(r8); \
 + lwz r9,TI_PREEMPT-THREAD_SIZE(r11);  \
 + stw r9,TI_PREEMPT-THREAD_SIZE(r8);   \

[PATCH v3] [POWERPC] devres: Add devm_ioremap_prot()

From: Emil Medve [EMAIL PROTECTED]

We provide an ioremap_flags so provide a corresponding devm_ioremap_prot.
The slight name difference is at Ben Herrenschmidt request as he plans
on changing ioremap_flags to ioremap_prot in the future.

Signed-off-by: Emil Medve [EMAIL PROTECTED]
Signed-off-by: Kumar Gala [EMAIL PROTECTED]
---

Renamed at BenH's request to devm_ioremap_prot.

 arch/powerpc/lib/Makefile |1 +
 arch/powerpc/lib/devres.c |   33 +
 include/asm-powerpc/io.h  |8 +++-
 include/linux/io.h|1 +
 lib/devres.c  |2 +-
 5 files changed, 43 insertions(+), 2 deletions(-)
 create mode 100644 arch/powerpc/lib/devres.c

diff --git a/arch/powerpc/lib/Makefile b/arch/powerpc/lib/Makefile
index 4bb023f..f1d2cdc 100644
--- a/arch/powerpc/lib/Makefile
+++ b/arch/powerpc/lib/Makefile
@@ -23,3 +23,4 @@ obj-$(CONFIG_SMP) += locks.o
 endif

 obj-$(CONFIG_PPC_LIB_RHEAP) += rheap.o
+obj-$(CONFIG_HAS_IOMEM)+= devres.o
diff --git a/arch/powerpc/lib/devres.c b/arch/powerpc/lib/devres.c
new file mode 100644
index 000..b290845
--- /dev/null
+++ b/arch/powerpc/lib/devres.c
@@ -0,0 +1,33 @@
+#include linux/device.h  /* devres_*(), devm_ioremap_release() */
+#include linux/io.h  /* ioremap_flags() */
+#include linux/module.h  /* EXPORT_SYMBOL() */
+
+/**
+ * devm_ioremap_prot - Managed ioremap_flags()
+ * @dev: Generic device to remap IO address for
+ * @offset: BUS offset to map
+ * @size: Size of map
+ * @flags: Page flags
+ *
+ * Managed ioremap_prot().  Map is automatically unmapped on driver
+ * detach.
+ */
+void __iomem *devm_ioremap_prot(struct device *dev, resource_size_t offset,
+size_t size, unsigned long flags)
+{
+   void __iomem **ptr, *addr;
+
+   ptr = devres_alloc(devm_ioremap_release, sizeof(*ptr), GFP_KERNEL);
+   if (!ptr)
+   return NULL;
+
+   addr = ioremap_flags(offset, size, flags);
+   if (addr) {
+   *ptr = addr;
+   devres_add(dev, ptr);
+   } else
+   devres_free(ptr);
+
+   return addr;
+}
+EXPORT_SYMBOL(devm_ioremap_prot);
diff --git a/include/asm-powerpc/io.h b/include/asm-powerpc/io.h
index afae069..e0062d7 100644
--- a/include/asm-powerpc/io.h
+++ b/include/asm-powerpc/io.h
@@ -2,7 +2,7 @@
 #define _ASM_POWERPC_IO_H
 #ifdef __KERNEL__

-/*
+/*
  * This program is free software; you can redistribute it and/or
  * modify it under the terms of the GNU General Public License
  * as published by the Free Software Foundation; either version
@@ -18,6 +18,9 @@ extern int check_legacy_ioport(unsigned long base_port);
 #define _PNPWRP0xa79
 #define PNPBIOS_BASE   0xf000

+#include linux/device.h
+#include linux/io.h
+
 #include linux/compiler.h
 #include asm/page.h
 #include asm/byteorder.h
@@ -744,6 +747,9 @@ static inline void * bus_to_virt(unsigned long address)

 #define clrsetbits_8(addr, clear, set) clrsetbits(8, addr, clear, set)

+void __iomem *devm_ioremap_prot(struct device *dev, resource_size_t offset,
+   size_t size, unsigned long flags);
+
 #endif /* __KERNEL__ */

 #endif /* _ASM_POWERPC_IO_H */
diff --git a/include/linux/io.h b/include/linux/io.h
index 831f57c..7a390cf 100644
--- a/include/linux/io.h
+++ b/include/linux/io.h
@@ -58,6 +58,7 @@ static inline void devm_ioport_unmap(struct device *dev, void 
__iomem *addr)
 }
 #endif

+void devm_ioremap_release(struct device *dev, void *res);
 void __iomem * devm_ioremap(struct device *dev, resource_size_t offset,
unsigned long size);
 void __iomem * devm_ioremap_nocache(struct device *dev, resource_size_t offset,
diff --git a/lib/devres.c b/lib/devres.c
index 26c87c4..72c8909 100644
--- a/lib/devres.c
+++ b/lib/devres.c
@@ -2,7 +2,7 @@
 #include linux/io.h
 #include linux/module.h

-static void devm_ioremap_release(struct device *dev, void *res)
+void devm_ioremap_release(struct device *dev, void *res)
 {
iounmap(*(void __iomem **)res);
 }
-- 
1.5.4.1

___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev

Re: [PATCH] [POWERPC] convert transfer_to_handler into a macro


On Wed, 2008-04-30 at 03:02 -0500, Kumar Gala wrote:
 got that.  Does 40x/44x have anything similar we need to save/restore?

MMUCR I'd say... look at what our tlbie does there...

Ben.


___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev

Re: [PATCH] [POWERPC] convert transfer_to_handler into a macro



On Apr 30, 2008, at 4:59 PM, Benjamin Herrenschmidt wrote:


On Wed, 2008-04-30 at 03:02 -0500, Kumar Gala wrote:
got that.  Does 40x/44x have anything similar we need to save/ 
restore?


MMUCR I'd say... look at what our tlbie does there...


thanks.  Will take a look.  I just plan on overloading MMUCR with MAS0.

- k
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev

Re: [PATCH] docbook: fix fatal rapidio yet again (and more to come)

2008-04-30 Thread Paul Mackerras

Andrew Morton writes:

Odd. I thought Paul had picked up a docbook RapidIO patch from you in
the latest merge round.

Well it's more than a patch. The six-week-old patch series is:

rapidio-add-memory-mapping-driver-to-rapidio.patch
rapidio-add-rapidio-space-allocation-bitmap-arithmetic.patch
rapidio-add-fsl-rapidio-controller-memory-ops-functions.patch
rapidio-add-the-rapidio-master-port-maintance-and-doorbell-window-to-space-resources.patch
rapidio-add-rapidio-proc-fs-for-memory-mapping-debugging.patch
rapidio-add-the-memory-mapping-support-in-rionet-driver.patch
rapidio-fix-docbook-references.patch
rapidio-fix-kernel-doc-problems.patch

What happened is that you (Andrew) sent them on to me pretty much
unexamined. I took a look at them and dropped one of them because it
created a new /proc file. I asked Kumar to look at them and he had
issues with another three of the patches, and dropping those meant
that all the following ones (including the fix-kernel-doc one)
wouldn't apply, so I dropped them too. I applied the rest and sent
them to Linus.

(seems that I forgot to cc Jeff on the rionet change too).

Yeah. I nearly dropped that one too. I probably should have. :)

Oh well. If nobody puts their hand up in the next 24 hours or so I'll just
send it all in to Linus.

Please don't. At this stage I think the best thing is for Kumar to
talk to Zhang Wei (they both work for Freescale, so that should be
possible in theory :) and get him to rework the remaining patches as
required for inclusion in 2.6.27.

Paul.
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev

Re: [spi-devel-general] [PATCH] spi_mpc83xx: test below 0 on unsigned irq in mpc83xx_spi_probe()

2008-04-30 Thread David Brownell

On Wednesday 23 April 2008, Kumar Gala wrote:
 
 On Apr 23, 2008, at 3:19 PM, Roel Kluin wrote:
  mpc83xx_spi-irq is unsigned, so the test fails
 
  Signed-off-by: Roel Kluin [EMAIL PROTECTED]

Any reason to not just make mpc83xx_spi-irq be int,
following normal practice everywhere?  If not, I'll
roll that into the patch from Joakim Tjernlund...

- Dave
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev

Re: [PATCH] [POWERPC] Rework EXC_LEVEL_EXCEPTION_PROLOG code



On Apr 30, 2008, at 4:54 PM, Benjamin Herrenschmidt wrote:


On Wed, 2008-04-30 at 04:27 -0500, Kumar Gala wrote:

* Cleanup the code a bit my allocating an INT_FRAME on our exception
 stack there by make references go from GPR11-INT_FRAME_SIZE(r8) to
 just GPR(r8)

   ^^ 11 ?


r8 is correct for my example.  My point is s/GPR11-INT_FRAME_SIZE/GPR11/

* simplify {lvl}_transfer_to_handler code by moving the copying of  
the

 temp registers we use if we come from user space into the PROLOG
* If the exception came from kernel mode copy thread_info flags,
 preempt, and task pointer from the process thread_info.

Signed-off-by: Kumar Gala [EMAIL PROTECTED]
---

I'm not sure if the copying of TI_FLAGS, TI_PREEMPT, and TI_TASK
are really needed.  I'm a bit concerned what to do if we get a
CriticalInput while in kernel mode and the handler causes a  
reschedule.


Well, reschedule or signal, either way, you can't handle them on the  
way

out. Maybe an option there is to set the flag in the normal kernel
stack's thread info and trigger an interrupt asap via the PIT so  
things

get handled ?


If we don't handle reschedule or signal will we actually not function  
properly?  I assume reschedule isn't an issue, but could we lose a  
signal?


diff --git a/arch/powerpc/kernel/head_booke.h b/arch/powerpc/kernel/ 
head_booke.h

index d647e05..78baec5 100644
--- a/arch/powerpc/kernel/head_booke.h
+++ b/arch/powerpc/kernel/head_booke.h
@@ -78,12 +78,12 @@
slwir8,r8,2;\
addis   r8,r8,[EMAIL PROTECTED];\
lwz r8,[EMAIL PROTECTED](r8);   \
-   addir8,r8,THREAD_SIZE;
+   addir8,r8,THREAD_SIZE-INT_FRAME_SIZE;
#else
#define BOOKE_LOAD_EXC_LEVEL_STACK(level)   \
lis r8,[EMAIL PROTECTED];   \
lwz r8,[EMAIL PROTECTED](r8);   \
-   addir8,r8,THREAD_SIZE;
+   addir8,r8,THREAD_SIZE-INT_FRAME_SIZE;
#endif


Nothing specific to your patch, but those level##_STACK_TOP seem to
be pretty badly named if you end up -adding- THREAD_SIZE to actually
get to the stack's top. Do they really contain the stack top or do
they in fact contain the stack base/bottom ?


That might be stale from how the old code worked.  I can never  
remember what we consider the top and bottom of the stack.  (please  
remind me and I'll fixup the comments and variables).



/*
@@ -97,22 +97,35 @@
#define EXC_LEVEL_EXCEPTION_PROLOG(exc_level, exc_level_srr0,  
exc_level_srr1) \

mtspr   exc_level##_SPRG,r8; \
	BOOKE_LOAD_EXC_LEVEL_STACK(exc_level);/* r8 points to the  
exc_level stack*/ \

-   stw r10,GPR10-INT_FRAME_SIZE(r8);\
-   stw r11,GPR11-INT_FRAME_SIZE(r8);\
+   stw r9,GPR9(r8);/* save various registers  */\
+   stw r10,GPR10(r8);   \
+   stw r11,GPR11(r8);   \
+   mfspr   r11,SPRN_SPRG3; /* if from user, start at top of   */\
+   lwz r11,THREAD_INFO-THREAD(r11); /* this thread's kernel stack */\
+   addir11,r11,THREAD_SIZE-INT_FRAME_SIZE; /* Alloc exception frm */\


So you do the above whether it will actually be needed or not right ?


good point I can move this down.


mfcrr10;/* save CR in r10 for now  */\
-   mfspr   r11,exc_level_srr1; /* check whether user or kernel*/\
-   andi.   r11,r11,MSR_PR;  \
-   mr  r11,r8;  \
-   mfspr   r8,exc_level##_SPRG; \
+   mfspr   r9,exc_level_srr1;  /* check whether user or kernel*/\
+   andi.   r9,r9,MSR_PR;\
beq 1f;  \
/* COMING FROM USER MODE */  \
-   mfspr   r11,SPRN_SPRG3; /* if from user, start at top of   */\
-   lwz r11,THREAD_INFO-THREAD(r11); /* this thread's kernel stack */\
-   addir11,r11,THREAD_SIZE; \
-1:	subi	r11,r11,INT_FRAME_SIZE;	/* Allocate an exception frame  
*/\

+   lwz r9,GPR9(r8);/* copy regs from exception stack  */\
+   stw r9,GPR9(r11);\
+   lwz r9,GPR10(r8);\
+   stw r9,GPR10(r11);   \
+   lwz r9,GPR11(r8);\
+   stw r9,GPR11(r11);   \
+   b   2f;

Re: [PATCH] docbook: fix fatal rapidio yet again (and more to come)



On Apr 30, 2008, at 5:11 PM, Randy Dunlap wrote:

On Thu, 1 May 2008 08:09:24 +1000 Paul Mackerras wrote:


Andrew Morton writes:

Odd.  I thought Paul had picked up a docbook RapidIO patch from  
you in

the latest merge round.



Well it's more than a patch.  The six-week-old patch series is:

rapidio-add-memory-mapping-driver-to-rapidio.patch
rapidio-add-rapidio-space-allocation-bitmap-arithmetic.patch
rapidio-add-fsl-rapidio-controller-memory-ops-functions.patch
rapidio-add-the-rapidio-master-port-maintance-and-doorbell-window- 
to-space-resources.patch

rapidio-add-rapidio-proc-fs-for-memory-mapping-debugging.patch
rapidio-add-the-memory-mapping-support-in-rionet-driver.patch
rapidio-fix-docbook-references.patch
rapidio-fix-kernel-doc-problems.patch


What happened is that you (Andrew) sent them on to me pretty much
unexamined.  I took a look at them and dropped one of them because it
created a new /proc file.  I asked Kumar to look at them and he had
issues with another three of the patches, and dropping those meant
that all the following ones (including the fix-kernel-doc one)
wouldn't apply, so I dropped them too.  I applied the rest and sent
them to Linus.


(seems that I forgot to cc Jeff on the rionet change too).


Yeah.  I nearly dropped that one too.  I probably should have. :)

Oh well.  If nobody puts their hand up in the next 24 hours or so  
I'll just

send it all in to Linus.


Please don't.  At this stage I think the best thing is for Kumar to
talk to Zhang Wei (they both work for Freescale, so that should be
possible in theory :) and get him to rework the remaining patches as
required for inclusion in 2.6.27.


Just to be clear, the docbook changes shouldn't wait for 2.6.27.
There's no need for that.


Can the docbook be respun against linus's tree?

-k
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev

Re: [PATCH] docbook: fix fatal rapidio yet again (and more to come)

Kumar Gala wrote:

On Apr 30, 2008, at 5:11 PM, Randy Dunlap wrote:

On Thu, 1 May 2008 08:09:24 +1000 Paul Mackerras wrote:

Andrew Morton writes:

Odd. I thought Paul had picked up a docbook RapidIO patch from you in
the latest merge round.

Well it's more than a patch. The six-week-old patch series is:

rapidio-add-rapidio-proc-fs-for-memory-mapping-debugging.patch
rapidio-add-the-memory-mapping-support-in-rionet-driver.patch
rapidio-fix-docbook-references.patch
rapidio-fix-kernel-doc-problems.patch

(seems that I forgot to cc Jeff on the rionet change too).

Yeah. I nearly dropped that one too. I probably should have. :)

Oh well. If nobody puts their hand up in the next 24 hours or so
I'll just

send it all in to Linus.

Just to be clear, the docbook changes shouldn't wait for 2.6.27.
There's no need for that.

Can the docbook be respun against linus's tree?

Sure, I'll do that later, hopefully tonight.

--
~Randy
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev

Re: [PATCH] [POWERPC] Rework EXC_LEVEL_EXCEPTION_PROLOG code


On Wed, 2008-04-30 at 17:13 -0500, Kumar Gala wrote:
 
 If we don't handle reschedule or signal will we actually not
 function  
 properly?  I assume reschedule isn't an issue, but could we lose a  
 signal?

Well, you can be in trouble if you lose TIF_SIGPENDING. You don't -have-
to actually take the signal, it will then be done on the next return to
userspace (next timer interrupt, next syscall, ...), but TIF_SIGPENDING
must not be lost. 

  Nothing specific to your patch, but those level##_STACK_TOP seem to
  be pretty badly named if you end up -adding- THREAD_SIZE to actually
  get to the stack's top. Do they really contain the stack top or do
  they in fact contain the stack base/bottom ?
 
 That might be stale from how the old code worked.  I can never  
 remember what we consider the top and bottom of the stack.  (please  
 remind me and I'll fixup the comments and variables).

Well, top is the high address and bottom is the low address in my view
of things :-)

 I thought about that.  The only case its a bit of an issue is for  
 CriticalInput.  I don't see Watchdog, Debug, or MachineCheck as
 being  
 performance critical.  I can use r10 if I save and restored the CR
 or  
 some other register.

You can save CR first yeah and then interleave a bit using 2 registers
(ie. 2 loads, 2 stores, or something like load 1, load 2, store 1, load
3, store 2, etc...)

 just leaving it to C code.  I assume that preempt_count should be
 the  
 same value on entry and exit.  Do think we should set HARDIRQ_OFFSET  
 for debug level exceptions?

Well... I think all those things should run with EE disabled, and thus
be considered as far as linux is concerned, as interrupts. So the C code
should do irq_enter/exit.

 Where should I look for an example of how to convey that information  
 to lockdep?

The irqtrace stuff in the asm would do maybe unless transfer_to_handler
does it already, I have to look at the code with all your patches
applied...

Ben.


___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev

[patch 0/5] PS3 patches for 2.6.26

Paul,

This is a small set of PS3 fixup patches for 2.6.26.

  [patch 1/5] POWERPC: Fix slb.c compile warnings
  [patch 2/5] PS3: Add time include to lpm
  [patch 3/5] PS3: Make ps3_virq_setup and ps3_virq_destroy static
  [patch 4/5] PS3: Remove unsupported wakeup sources
  [patch 5/5] PS3: Update ps3_defconfig

-Geoff


-- 



___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev

[patch 4/5] PS3: Remove unsupported wakeup sources

Other OS wakeup is not supported from the IR controller,
the bluetooth controller nor the RTC.  Remove references
to these in the PS3 sys-manager source.

Signed-off-by: Geoff Levand [EMAIL PROTECTED]
---
 drivers/ps3/ps3-sys-manager.c |7 +--
 1 file changed, 1 insertion(+), 6 deletions(-)

--- a/drivers/ps3/ps3-sys-manager.c
+++ b/drivers/ps3/ps3-sys-manager.c
@@ -184,10 +184,7 @@ enum ps3_sys_manager_next_op {
 
 /**
  * enum ps3_sys_manager_wake_source - Next-op wakeup source (bit position 
mask).
- * @PS3_SM_WAKE_DEFAULT: Disk insert, power button, eject button, IR
- * controller, and bluetooth controller.
- * @PS3_SM_WAKE_RTC:
- * @PS3_SM_WAKE_RTC_ERROR:
+ * @PS3_SM_WAKE_DEFAULT: Disk insert, power button, eject button.
  * @PS3_SM_WAKE_W_O_L: Ether or wireless LAN.
  * @PS3_SM_WAKE_P_O_R: Power on reset.
  *
@@ -200,8 +197,6 @@ enum ps3_sys_manager_next_op {
 enum ps3_sys_manager_wake_source {
/* version 3 */
PS3_SM_WAKE_DEFAULT   = 0,
-   PS3_SM_WAKE_RTC   = 0x0040,
-   PS3_SM_WAKE_RTC_ERROR = 0x0080,
PS3_SM_WAKE_W_O_L = 0x0400,
PS3_SM_WAKE_P_O_R = 0x8000,
 };

-- 



___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev

[patch 5/5] PS3: Update ps3_defconfig

Update ps3_defconfig.

Signed-off-by: Geoff Levand [EMAIL PROTECTED]
---
 arch/powerpc/configs/ps3_defconfig |  132 +++--
 1 file changed, 84 insertions(+), 48 deletions(-)

--- a/arch/powerpc/configs/ps3_defconfig
+++ b/arch/powerpc/configs/ps3_defconfig
@@ -1,7 +1,7 @@
 #
 # Automatically generated make config: don't edit
-# Linux kernel version: 2.6.25-rc6
-# Thu Mar 20 11:07:04 2008
+# Linux kernel version: 2.6.25
+# Mon Apr 28 12:39:10 2008
 #
 CONFIG_PPC64=y
 
@@ -30,6 +30,9 @@ CONFIG_GENERIC_CLOCKEVENTS=y
 CONFIG_GENERIC_HARDIRQS=y
 CONFIG_HAVE_SETUP_PER_CPU_AREA=y
 CONFIG_IRQ_PER_CPU=y
+CONFIG_STACKTRACE_SUPPORT=y
+CONFIG_TRACE_IRQFLAGS_SUPPORT=y
+CONFIG_LOCKDEP_SUPPORT=y
 CONFIG_RWSEM_XCHGADD_ALGORITHM=y
 CONFIG_ARCH_HAS_ILOG2_U32=y
 CONFIG_ARCH_HAS_ILOG2_U64=y
@@ -73,8 +76,6 @@ CONFIG_POSIX_MQUEUE=y
 CONFIG_LOG_BUF_SHIFT=17
 # CONFIG_CGROUPS is not set
 # CONFIG_GROUP_SCHED is not set
-# CONFIG_USER_SCHED is not set
-# CONFIG_CGROUP_SCHED is not set
 CONFIG_SYSFS_DEPRECATED=y
 CONFIG_SYSFS_DEPRECATED_V2=y
 # CONFIG_RELAY is not set
@@ -161,7 +162,6 @@ CONFIG_PPC_MULTIPLATFORM=y
 # CONFIG_PPC_PMAC is not set
 # CONFIG_PPC_MAPLE is not set
 # CONFIG_PPC_PASEMI is not set
-# CONFIG_PPC_CELLEB is not set
 CONFIG_PPC_PS3=y
 
 #
@@ -181,6 +181,7 @@ CONFIG_PS3_LPM=m
 CONFIG_PPC_CELL=y
 # CONFIG_PPC_CELL_NATIVE is not set
 # CONFIG_PPC_IBM_CELL_BLADE is not set
+# CONFIG_PPC_CELLEB is not set
 
 #
 # Cell Broadband Engine options
@@ -205,9 +206,9 @@ CONFIG_SPU_BASE=y
 #
 # Kernel options
 #
-# CONFIG_TICK_ONESHOT is not set
+CONFIG_TICK_ONESHOT=y
 # CONFIG_NO_HZ is not set
-# CONFIG_HIGH_RES_TIMERS is not set
+CONFIG_HIGH_RES_TIMERS=y
 CONFIG_GENERIC_CLOCKEVENTS_BUILD=y
 # CONFIG_HZ_100 is not set
 CONFIG_HZ_250=y
@@ -221,7 +222,6 @@ CONFIG_PREEMPT_NONE=y
 CONFIG_BINFMT_ELF=y
 CONFIG_COMPAT_BINFMT_ELF=y
 CONFIG_BINFMT_MISC=y
-CONFIG_FORCE_MAX_ZONEORDER=13
 # CONFIG_IOMMU_VMERGE is not set
 CONFIG_IOMMU_HELPER=y
 CONFIG_ARCH_ENABLE_MEMORY_HOTPLUG=y
@@ -255,6 +255,7 @@ CONFIG_BOUNCE=y
 CONFIG_ARCH_MEMORY_PROBE=y
 # CONFIG_PPC_HAS_HASH_64K is not set
 # CONFIG_PPC_64K_PAGES is not set
+CONFIG_FORCE_MAX_ZONEORDER=13
 # CONFIG_SCHED_SMT is not set
 CONFIG_PROC_DEVICETREE=y
 # CONFIG_CMDLINE_BOOL is not set
@@ -272,7 +273,9 @@ CONFIG_GENERIC_ISA_DMA=y
 # CONFIG_PCI_SYSCALL is not set
 # CONFIG_ARCH_SUPPORTS_MSI is not set
 # CONFIG_PCCARD is not set
+CONFIG_PAGE_OFFSET=0xc000
 CONFIG_KERNEL_START=0xc000
+CONFIG_PHYSICAL_START=0x
 
 #
 # Networking
@@ -292,7 +295,7 @@ CONFIG_XFRM=y
 # CONFIG_XFRM_STATISTICS is not set
 # CONFIG_NET_KEY is not set
 CONFIG_INET=y
-# CONFIG_IP_MULTICAST is not set
+CONFIG_IP_MULTICAST=y
 # CONFIG_IP_ADVANCED_ROUTER is not set
 CONFIG_IP_FIB_HASH=y
 CONFIG_IP_PNP=y
@@ -301,6 +304,7 @@ CONFIG_IP_PNP_DHCP=y
 # CONFIG_IP_PNP_RARP is not set
 # CONFIG_NET_IPIP is not set
 # CONFIG_NET_IPGRE is not set
+# CONFIG_IP_MROUTE is not set
 # CONFIG_ARPD is not set
 # CONFIG_SYN_COOKIES is not set
 # CONFIG_INET_AH is not set
@@ -332,8 +336,10 @@ CONFIG_INET6_XFRM_MODE_TUNNEL=y
 CONFIG_INET6_XFRM_MODE_BEET=y
 # CONFIG_INET6_XFRM_MODE_ROUTEOPTIMIZATION is not set
 CONFIG_IPV6_SIT=y
+CONFIG_IPV6_NDISC_NODETYPE=y
 # CONFIG_IPV6_TUNNEL is not set
 # CONFIG_IPV6_MULTIPLE_TABLES is not set
+# CONFIG_IPV6_MROUTE is not set
 # CONFIG_NETWORK_SECMARK is not set
 # CONFIG_NETFILTER is not set
 # CONFIG_IP_DCCP is not set
@@ -392,8 +398,6 @@ CONFIG_IEEE80211=m
 CONFIG_IEEE80211_CRYPT_WEP=m
 CONFIG_IEEE80211_CRYPT_CCMP=m
 CONFIG_IEEE80211_CRYPT_TKIP=m
-CONFIG_IEEE80211_SOFTMAC=m
-# CONFIG_IEEE80211_SOFTMAC_DEBUG is not set
 # CONFIG_RFKILL is not set
 # CONFIG_NET_9P is not set
 
@@ -507,6 +511,7 @@ CONFIG_WLAN_80211=y
 # CONFIG_LIBERTAS is not set
 # CONFIG_USB_ZD1201 is not set
 # CONFIG_USB_NET_RNDIS_WLAN is not set
+# CONFIG_IWLWIFI_LEDS is not set
 # CONFIG_HOSTAP is not set
 
 #
@@ -578,6 +583,7 @@ CONFIG_INPUT_JOYSTICK=y
 # CONFIG_JOYSTICK_SPACEBALL is not set
 # CONFIG_JOYSTICK_STINGER is not set
 # CONFIG_JOYSTICK_TWIDJOY is not set
+# CONFIG_JOYSTICK_ZHENHUA is not set
 # CONFIG_JOYSTICK_JOYDUMP is not set
 # CONFIG_JOYSTICK_XPAD is not set
 # CONFIG_INPUT_TABLET is not set
@@ -641,6 +647,7 @@ CONFIG_SSB_POSSIBLE=y
 # Multifunction device drivers
 #
 # CONFIG_MFD_SM501 is not set
+# CONFIG_HTC_PASIC3 is not set
 
 #
 # Multimedia devices
@@ -761,10 +768,6 @@ CONFIG_SND_PS3_DEFAULT_START_DELAY=2000
 # CONFIG_SND_SOC is not set
 
 #
-# SoC Audio support for SuperH
-#
-
-#
 # ALSA SoC audio for Freescale SOCs
 #
 
@@ -849,6 +852,7 @@ CONFIG_USB_STORAGE=m
 # CONFIG_USB_STORAGE_ALAUDA is not set
 # CONFIG_USB_STORAGE_ONETOUCH is not set
 # CONFIG_USB_STORAGE_KARMA is not set
+# CONFIG_USB_STORAGE_CYPRESS_ATACB is not set
 # CONFIG_USB_LIBUSUAL is not set
 
 #
@@ -893,10 +897,6 @@ CONFIG_USB_MON=y
 # CONFIG_EDAC is not set
 # CONFIG_RTC_CLASS is not set
 # CONFIG_DMADEVICES is not set
-
-#
-# Userspace I/O
-#
 # CONFIG_UIO is not set

[patch 3/5] PS3: Make ps3_virq_setup and ps3_virq_destroy static

From: Geert Uytterhoeven [EMAIL PROTECTED]

The routines ps3_virq_setup() and ps3_virq_destroy() are used
in only one file, so make them static.

Signed-off-by: Geert Uytterhoeven [EMAIL PROTECTED]
Signed-off-by: Geoff Levand [EMAIL PROTECTED]
---
 arch/powerpc/platforms/ps3/interrupt.c |6 +++---
 include/asm-powerpc/ps3.h  |3 ---
 2 files changed, 3 insertions(+), 6 deletions(-)

--- a/arch/powerpc/platforms/ps3/interrupt.c
+++ b/arch/powerpc/platforms/ps3/interrupt.c
@@ -167,8 +167,8 @@ static struct irq_chip ps3_irq_chip = {
  * ps3_private data.
  */
 
-int ps3_virq_setup(enum ps3_cpu_binding cpu, unsigned long outlet,
-   unsigned int *virq)
+static int ps3_virq_setup(enum ps3_cpu_binding cpu, unsigned long outlet,
+ unsigned int *virq)
 {
int result;
struct ps3_private *pd;
@@ -217,7 +217,7 @@ fail_create:
  * Clears chip data and calls irq_dispose_mapping() for the virq.
  */
 
-int ps3_virq_destroy(unsigned int virq)
+static int ps3_virq_destroy(unsigned int virq)
 {
const struct ps3_private *pd = get_irq_chip_data(virq);
 
--- a/include/asm-powerpc/ps3.h
+++ b/include/asm-powerpc/ps3.h
@@ -178,9 +178,6 @@ enum ps3_cpu_binding {
PS3_BINDING_CPU_1 = 1,
 };
 
-int ps3_virq_setup(enum ps3_cpu_binding cpu, unsigned long outlet,
-   unsigned int *virq);
-int ps3_virq_destroy(unsigned int virq);
 int ps3_irq_plug_setup(enum ps3_cpu_binding cpu, unsigned long outlet,
unsigned int *virq);
 int ps3_irq_plug_destroy(unsigned int virq);

-- 



___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev

Re: [patch 2.6.25-git] spi_mpc83xx much improved driver

2008-04-30 Thread Andrew Morton

On Wed, 30 Apr 2008 15:37:07 -0700
David Brownell [EMAIL PROTECTED] wrote:

 From: Joakim Tjernlund [EMAIL PROTECTED]
 Date: Fri, 11 Apr 2008 18:57:21 +0200
 Subject: [PATCH] Much improved mpc83xx SPI driver.

 The current driver may cause glitches on SPI CLK line since one must
 disable the SPI controller before changing any HW settings.  Fix this
 by implementing a local spi_transfer function that won't change speed
 and/or word size while CS is active.

 While doing that heavy lifting a few other issues were addressed too:
  - Make word size 16 and 32 work too.
  - Honor bits_per_word and speed_hz in spi transaction.
  - Optimize the common path.

 This also stops using the bitbang framework (except for a few
 constants).

 ...

 +static void mpc83xx_spi_work(struct work_struct *work)
 +{
 + struct mpc83xx_spi *mpc83xx_spi =
 + container_of(work, struct mpc83xx_spi, work);
 +
 + spin_lock_irq(mpc83xx_spi-lock);

irq-safe.

 ...

 + spin_lock(mpc83xx_spi-lock);

not irq-safe.

Deliberate?

___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev

Re: [PATCH v2 4/6] [POWERPC] QE: implement support for the GPIO LIB API

On Wed, Apr 30, 2008 at 02:42:03PM -0500, Timur Tabi wrote:
 Anton Vorontsov wrote:
 
  +   Example:
  +   qe_pio_a: [EMAIL PROTECTED] {
  +   #gpio-cells = 2;
  +   compatible = fsl,mpc8360-qe-pario-bank,
  +fsl,mpc8323-qe-pario-bank;
 
 I know this is an example, but would we ever include both compatible strings 
 in
 one DTS?  Isn't the norm something like:
 
 fsl,mpc8360-qe-pario-bank, fsl,qe-pario-bank;
 
 I.e. specific version, then generic version?

Per Grant Likely's comments, fsl,qe-pario-bank considered as a made up
stuff. MPC8323 is the first QE chip, so every next QE chips should be
compatible.

Though, for fsl,gtm we can't use this, since we really want generic
name.

 Otherwise, every time we introduce a new QE part, we'll have to update *every*
 QE-enabled device tree *and* the QE gpio driver.

Nope. If the the QE is compatible with the previous, just write
fsl,newchip-qe-pario-bank, fsl,mpc8323-qe-pario-bank.

Btw, the same we do for the 8349 compatible PCI.

  +static int qe_gpio_get(struct gpio_chip *gc, unsigned int gpio)
  +{
  +   struct of_mm_gpio_chip *mm_gc = to_of_mm_gpio_chip(gc);
  +   struct qe_pio_regs __iomem *regs = mm_gc-regs;
  +   u32 pin_mask = 1  (QE_PIO_PINS - 1 - gpio);
  +
  +   return in_be32(regs-cpdata)  pin_mask;
  +}
 
 Return value should be u32, not int.

gpio.h disagree

$ cat include/asm-generic/gpio.h  | grep \*get
int (*get)(struct gpio_chip *chip,

-- 
Anton Vorontsov
email: [EMAIL PROTECTED]
irc://irc.freenode.net/bd2
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev

Re: [PATCH v2 4/6] [POWERPC] QE: implement support for the GPIO LIB API

2008-04-30 Thread Timur Tabi

Anton Vorontsov wrote:

 Per Grant Likely's comments, fsl,qe-pario-bank considered as a made up
 stuff. MPC8323 is the first QE chip, so every next QE chips should be
 compatible.

Ok.

 Return value should be u32, not int.
 
 gpio.h disagree
 
 $ cat include/asm-generic/gpio.h  | grep \*get
 int (*get)(struct gpio_chip *chip,
 

In that case, perhaps you should return this:

return in_be32(regs-cpdata)  pin_mask ? 1 : 0;

-- 
Timur Tabi
Linux kernel developer at Freescale
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev

Re: [patch 2.6.25-git] spi_mpc83xx much improved driver

2008-04-30 Thread David Brownell

On Wednesday 30 April 2008, Andrew Morton wrote:
  + spin_lock_irq(mpc83xx_spi-lock);
 
 irq-safe.
 
  ...
 
  + spin_lock(mpc83xx_spi-lock);
 
 not irq-safe.
 
 Deliberate?

That latter one is inside an #if 0/#endif block, so it won't matter.
The #if 0 block bothered me.  Maybe Joakim can remove it.

(By the way, I'd feel safer about this patch if there were an
ack or two from more PPC folk...)



___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev

Re: [PATCH v2 4/6] [POWERPC] QE: implement support for the GPIO LIB API

On Wed, Apr 30, 2008 at 05:50:42PM -0500, Timur Tabi wrote:
 Anton Vorontsov wrote:
 
  Per Grant Likely's comments, fsl,qe-pario-bank considered as a made up
  stuff. MPC8323 is the first QE chip, so every next QE chips should be
  compatible.
 
 Ok.
 
  Return value should be u32, not int.
  
  gpio.h disagree
  
  $ cat include/asm-generic/gpio.h  | grep \*get
  int (*get)(struct gpio_chip *chip,
  
 
 In that case, perhaps you should return this:
 
   return in_be32(regs-cpdata)  pin_mask ? 1 : 0;

What is the problem with returning (int)(u32  u32) value?

You've asked to remove !! stuff and now purposing exactly the
same... :-?

-- 
Anton Vorontsov
email: [EMAIL PROTECTED]
irc://irc.freenode.net/bd2
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev

Re: [PATCH] docbook: fix fatal rapidio yet again (and more to come)

On Thu, 1 May 2008 08:09:24 +1000 Paul Mackerras wrote:

Andrew Morton writes:

Odd. I thought Paul had picked up a docbook RapidIO patch from you in
the latest merge round.

Well it's more than a patch. The six-week-old patch series is:

(seems that I forgot to cc Jeff on the rionet change too).

Yeah. I nearly dropped that one too. I probably should have. :)

Oh well. If nobody puts their hand up in the next 24 hours or so I'll just
send it all in to Linus.

Just to be clear, the docbook changes shouldn't wait for 2.6.27.
There's no need for that.

---
~Randy
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev

Re: [patch 1/5] POWERPC: Fix slb.c compile warnings


On Wed, 2008-04-30 at 15:24 -0700, Geoff Levand wrote:
 Arrange for a syntax check to always be done on the powerpc/mm/slb.c
 DBG() macro by defining it to pr_debug() for non-debug builds. 
 
 Also, fix these related compile warnings:
 
   slb.c:273: warning: format '%04x' expects type 'unsigned int', but argument 
 2 has type 'long unsigned int
   slb.c:274: warning: format '%04x' expects type 'unsigned int', but argument 
 2 has type 'long unsigned int'
 
 Signed-off-by: Geoff Levand [EMAIL PROTECTED]

Acked-by: Benjamin Herrenschmidt [EMAIL PROTECTED]

 ---
  arch/powerpc/mm/slb.c |6 +++---
  1 file changed, 3 insertions(+), 3 deletions(-)
 
 --- a/arch/powerpc/mm/slb.c
 +++ b/arch/powerpc/mm/slb.c
 @@ -30,7 +30,7 @@
  #ifdef DEBUG
  #define DBG(fmt...) udbg_printf(fmt)
  #else
 -#define DBG(fmt...)
 +#define DBG pr_debug
  #endif
  
  extern void slb_allocate_realmode(unsigned long ea);
 @@ -279,8 +279,8 @@ void slb_initialize(void)
   patch_slb_encoding(slb_compare_rr_to_size,
  mmu_slb_size);
  
 - DBG(SLB: linear  LLP = %04x\n, linear_llp);
 - DBG(SLB: io  LLP = %04x\n, io_llp);
 + DBG(SLB: linear  LLP = %04lx\n, linear_llp);
 + DBG(SLB: io  LLP = %04lx\n, io_llp);
   }
  
   get_paca()-stab_rr = SLB_NUM_BOLTED;
 

___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev

mucking with cputable ...

2008-04-30 Thread Kevin Diggs


Hi,

I'm trying to monkey with cputable. It is hanging after printing:

Preparing BATs

on the console (PowerMac 8600 with PowerLogix 750GX card, 2.6.24 YDL 4.0).

	I am guessing I am doing this PTRRELOC() thing wrong? Can someone 
explain what is going on here:


*PTRRELOC(cur_cpu_spec) = the_cpu_spec;

Up above both s and t needed reloccing? This is from identify_cpu(). 
Does this have something to do with data items in different sections 
(i.e. initdata)?


	I also welcome comments on where else the data I'm trying to graft into 
cputable might go (i.e. cpu_freq driver).


Thanks!

kevin
--- cputable-old_c  2008-02-25 18:24:23.0 -0800
+++ cputable-new_c  2008-04-30 14:31:37.0 -0700
@@ -38,11 +38,13 @@
 extern void __setup_cpu_604(unsigned long offset, struct cpu_spec* spec);
 extern void __setup_cpu_750(unsigned long offset, struct cpu_spec* spec);
 extern void __setup_cpu_750cx(unsigned long offset, struct cpu_spec* spec);
 extern void __setup_cpu_750fx(unsigned long offset, struct cpu_spec* spec);
+extern void __setup_cpu_750gx(unsigned long offset, struct cpu_spec* spec);
 extern void __setup_cpu_7400(unsigned long offset, struct cpu_spec* spec);
 extern void __setup_cpu_7410(unsigned long offset, struct cpu_spec* spec);
 extern void __setup_cpu_745x(unsigned long offset, struct cpu_spec* spec);
+
 #endif /* CONFIG_PPC32 */
 #ifdef CONFIG_PPC64
 extern void __setup_cpu_ppc970(unsigned long offset, struct cpu_spec* spec);
 extern void __setup_cpu_ppc970MP(unsigned long offset, struct cpu_spec* spec);
@@ -70,8 +72,25 @@
 PPC_FEATURE_HAS_ALTIVEC_COMP)
 #define COMMON_USER_BOOKE  (PPC_FEATURE_32 | PPC_FEATURE_HAS_MMU | \
 PPC_FEATURE_BOOKE)
 
+#ifdef CONFIG_PPC32
+static struct ppc_misc_750fgx __initdata ppc_misc_750fx={
+   .misc_cp=ppc_misc_cp_750fgx,
+   .min_ratio=2,   /* min bus ratio */
+   .max_ratio=20,  /* max bus ratio */
+   .min_core=40,   /* min core frequency per spec */
+   .max_core=80,   /* max core frequency per spec */
+};
+static struct ppc_misc_750fgx __initdata ppc_misc_750gx={
+   .misc_cp=ppc_misc_cp_750fgx,
+   .min_ratio=2,   /* min bus ratio */
+   .max_ratio=20,  /* max bus ratio */
+   .min_core=50,   /* min core frequency per spec */
+   .max_core=100,  /* max core frequency per spec */
+};
+#endif /* CONFIG_PPC32 */
+
 static struct cpu_spec __initdata cpu_specs[] = {
 #ifdef CONFIG_PPC64
{   /* Power3 */
.pvr_mask   = 0x,
@@ -590,8 +609,9 @@
.icache_bsize   = 32,
.dcache_bsize   = 32,
.num_pmcs   = 4,
.cpu_setup  = __setup_cpu_750,
+   .misc   = (void *) ppc_misc_750fx,
.platform   = ppc750,
},
{   /* 750FX rev 2.0 must disable HID0[DPM] */
.pvr_mask   = 0x,
@@ -602,8 +622,9 @@
.icache_bsize   = 32,
.dcache_bsize   = 32,
.num_pmcs   = 4,
.cpu_setup  = __setup_cpu_750,
+   .misc   = (void *) ppc_misc_750fx,
.platform   = ppc750,
},
{   /* 750FX (All revs except 2.0) */
.pvr_mask   = 0x,
@@ -614,20 +635,48 @@
.icache_bsize   = 32,
.dcache_bsize   = 32,
.num_pmcs   = 4,
.cpu_setup  = __setup_cpu_750fx,
+   .misc   = (void *) ppc_misc_750fx,
.platform   = ppc750,
},
-   {   /* 750GX */
+   {   /* 750GX rev 1.x */
.pvr_mask   = 0x,
.pvr_value  = 0x7002,
.cpu_name   = 750GX,
.cpu_features   = CPU_FTRS_750GX,
.cpu_user_features  = COMMON_USER | PPC_FEATURE_PPC_LE,
.icache_bsize   = 32,
.dcache_bsize   = 32,
.num_pmcs   = 4,
-   .cpu_setup  = __setup_cpu_750fx,
+   .cpu_setup  = __setup_cpu_750gx,
+   .misc   = (void *) ppc_misc_750gx,
+   .platform   = ppc750,
+   },
+   {   /* 750GX (rev 2.3, as used on PowerLogix 750GX upgrade card */
+   .pvr_mask   = 0x,
+   .pvr_value  = 0x00080203,
+   .cpu_name   = 750GX,
+   .cpu_features   = CPU_FTRS_750GX,
+   .cpu_user_features  =

Re: [PATCH 1/7] Implement arch disable/enable irq hooks.

2008-04-30 Thread Paul Mackerras

Guennadi Liakhovetski writes:

 The patch (with the _TLF_SLEEPING fix you mentioned in a later email) 
 works for me.

Great, thanks.

 Shall I submit it From: you or would you prefer to post 
 it yourself? But, I guess, you have to put your S-o-b under it yourself, 
 don't you?

I'll post it as a stand-alone patch with my S-o-b.

Paul.
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev

Re: drivers/net/fec_8xx config problem

2008-04-30 Thread Jan Engelhardt


On Wednesday 2008-04-30 21:23, Scott Wood wrote:
 On Apr 30, 2008, at 2:20 PM, Scott Wood wrote:
 On Wed, Apr 30, 2008 at 02:19:21PM -0500, Becky Bruce wrote:
 I just noticed that the fec_8xx driver is not currently reachable via
 menuconfig because it depends on 8XX instead of 8xx.
 [snip]
 Since nobody has noticed this problem, I'm wondering if this driver
 is still in (infrequent) use, or if it's been superseded and should
 be removed, or if I'm just completely missing something with respect
 to the use of 8XX instead of 8xx.

Blame those developers who had the brilliant idea of using lowercase in
kconfig symbols (these things emit cosmic particles en masse!) :-)

arch/arm/mach-pxa/Kconfig:config PXA3xx
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev

Re: [PATCH v2 4/6] [POWERPC] QE: implement support for the GPIO LIB API

On Wed, Apr 30, 2008 at 06:03:45PM -0500, Timur Tabi wrote:
 Anton Vorontsov wrote:
 
  What is the problem with returning (int)(u32  u32) value?
 
 Technically, a signed int is smaller than an unsigned int, so a value of
 0x8000 won't fit in an 'int'.

They're of the same size. And because of that, we'll not lose
information, so (int)(0x8000U) still != 0, it is just negative.

  You've asked to remove !! stuff and now purposing exactly the
  same... :-?
 
 The !! stuff was because the function was returning a boolean value, so 
 non-zero
 == TRUE.  I don't think the return value from 'get' is a technically a 
 boolean,
 so I'm assuming that the spec says the return value should be 0 or 1, to 
 reflect
 the value of that GPIO pin.

No. The spec indeed says that 0 for low, non-0 for high.

-- 
Anton Vorontsov
email: [EMAIL PROTECTED]
irc://irc.freenode.net/bd2
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev

Re: [PATCH] [POWERPC] Rework EXC_LEVEL_EXCEPTION_PROLOG code



On Apr 30, 2008, at 5:22 PM, Benjamin Herrenschmidt wrote:


On Wed, 2008-04-30 at 17:13 -0500, Kumar Gala wrote:


If we don't handle reschedule or signal will we actually not
function
properly?  I assume reschedule isn't an issue, but could we lose a
signal?


Well, you can be in trouble if you lose TIF_SIGPENDING. You don't - 
have-
to actually take the signal, it will then be done on the next return  
to
userspace (next timer interrupt, next syscall, ...), but  
TIF_SIGPENDING

must not be lost.


Interesting.  It seems like causing a signal from an async interrupt  
from kernel space shouldn't be allowed.  At worse we can store back  
the flags into the real thread_info.



Nothing specific to your patch, but those level##_STACK_TOP seem to
be pretty badly named if you end up -adding- THREAD_SIZE to actually
get to the stack's top. Do they really contain the stack top or do
they in fact contain the stack base/bottom ?


That might be stale from how the old code worked.  I can never
remember what we consider the top and bottom of the stack.  (please
remind me and I'll fixup the comments and variables).


Well, top is the high address and bottom is the low address in my view
of things :-)


yeah, so we are now pointing to stack bottom.  will fix this up.


I thought about that.  The only case its a bit of an issue is for
CriticalInput.  I don't see Watchdog, Debug, or MachineCheck as
being
performance critical.  I can use r10 if I save and restored the CR
or
some other register.


You can save CR first yeah and then interleave a bit using 2 registers
(ie. 2 loads, 2 stores, or something like load 1, load 2, store 1,  
load

3, store 2, etc...)


Ok, will look at that.


just leaving it to C code.  I assume that preempt_count should be
the
same value on entry and exit.  Do think we should set HARDIRQ_OFFSET
for debug level exceptions?


Well... I think all those things should run with EE disabled, and thus
be considered as far as linux is concerned, as interrupts. So the C  
code

should do irq_enter/exit.


I agree we run all these interrupt levels with EE disabled.  Not sure  
I follow what you mean by irq_enter/ext.



Where should I look for an example of how to convey that information
to lockdep?


The irqtrace stuff in the asm would do maybe unless  
transfer_to_handler

does it already, I have to look at the code with all your patches
applied...


ok.

- k
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev

[PATCH] rapidio: fix current kernel-doc notation

From: Randy Dunlap [EMAIL PROTECTED]

Fix current (-git16) missing docbook/kernel-doc notation in RapidIO files.

Warning(linux-2.6.25-git16//include/linux/rio.h:187): No description found for 
parameter 'sys_size'
Warning(linux-2.6.25-git16//include/linux/rio.h:187): No description found for 
parameter 'phy_type'

Warning(linux-2.6.25-git16//arch/powerpc/sysdev/fsl_rio.c:188): No description 
found for parameter 'mport'
Warning(linux-2.6.25-git16//arch/powerpc/sysdev/fsl_rio.c:224): No description 
found for parameter 'mport'
Warning(linux-2.6.25-git16//arch/powerpc/sysdev/fsl_rio.c:245): No description 
found for parameter 'mport'
Warning(linux-2.6.25-git16//arch/powerpc/sysdev/fsl_rio.c:270): No description 
found for parameter 'mport'
Warning(linux-2.6.25-git16//arch/powerpc/sysdev/fsl_rio.c:311): No description 
found for parameter 'mport'
Warning(linux-2.6.25-git16//arch/powerpc/sysdev/fsl_rio.c:996): No description 
found for parameter 'dev'

Signed-off-by: Randy Dunlap [EMAIL PROTECTED]
---
 arch/powerpc/sysdev/fsl_rio.c |9 +++--
 include/linux/rio.h   |2 ++
 2 files changed, 9 insertions(+), 2 deletions(-)

--- linux-2.6.25-git16.orig/include/linux/rio.h
+++ linux-2.6.25-git16/include/linux/rio.h
@@ -161,6 +161,8 @@ enum rio_phy_type {
  * @ops: configuration space functions
  * @id: Port ID, unique among all ports
  * @index: Port index, unique among all port interfaces of the same type
+ * @sys_size: RapidIO common transport system size
+ * @phy_type: RapidIO phy type
  * @name: Port name string
  * @priv: Master port private data
  */
--- linux-2.6.25-git16.orig/arch/powerpc/sysdev/fsl_rio.c
+++ linux-2.6.25-git16/arch/powerpc/sysdev/fsl_rio.c
@@ -176,6 +176,7 @@ struct rio_priv {
 
 /**
  * fsl_rio_doorbell_send - Send a MPC85xx doorbell message
+ * @mport: RapidIO master port info
  * @index: ID of RapidIO interface
  * @destid: Destination ID of target device
  * @data: 16-bit info field of RapidIO doorbell message
@@ -211,6 +212,7 @@ static int fsl_rio_doorbell_send(struct 
 
 /**
  * fsl_local_config_read - Generate a MPC85xx local config space read
+ * @mport: RapidIO master port info
  * @index: ID of RapdiIO interface
  * @offset: Offset into configuration space
  * @len: Length (in bytes) of the maintenance transaction
@@ -232,6 +234,7 @@ static int fsl_local_config_read(struct 
 
 /**
  * fsl_local_config_write - Generate a MPC85xx local config space write
+ * @mport: RapidIO master port info
  * @index: ID of RapdiIO interface
  * @offset: Offset into configuration space
  * @len: Length (in bytes) of the maintenance transaction
@@ -254,6 +257,7 @@ static int fsl_local_config_write(struct
 
 /**
  * fsl_rio_config_read - Generate a MPC85xx read maintenance transaction
+ * @mport: RapidIO master port info
  * @index: ID of RapdiIO interface
  * @destid: Destination ID of transaction
  * @hopcount: Number of hops to target device
@@ -295,6 +299,7 @@ fsl_rio_config_read(struct rio_mport *mp
 
 /**
  * fsl_rio_config_write - Generate a MPC85xx write maintenance transaction
+ * @mport: RapidIO master port info
  * @index: ID of RapdiIO interface
  * @destid: Destination ID of transaction
  * @hopcount: Number of hops to target device
@@ -985,8 +990,8 @@ static inline void fsl_rio_info(struct d
 }
 
 /**
- * fsl_rio_setup - Setup MPC85xx RapidIO interface
- * @fsl_rio_setup - Setup Freescale PowerPC RapidIO interface
+ * fsl_rio_setup - Setup Freescale PowerPC RapidIO interface
+ * @dev: of_device pointer
  *
  * Initializes MPC85xx RapidIO hardware interface, configures
  * master port with system-specific info, and registers the
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev

Re: [PATCH] [POWERPC] Rework EXC_LEVEL_EXCEPTION_PROLOG code


On Wed, 2008-04-30 at 18:28 -0500, Kumar Gala wrote:
  Well, you can be in trouble if you lose TIF_SIGPENDING. You don't - 
  have-
  to actually take the signal, it will then be done on the next
 return  
  to
  userspace (next timer interrupt, next syscall, ...), but  
  TIF_SIGPENDING
  must not be lost.
 
 Interesting.  It seems like causing a signal from an async interrupt  
 from kernel space shouldn't be allowed.  At worse we can store back  
 the flags into the real thread_info.

Why shouldn't it be allowed ? We do store back flags in the real thread
info when doing irqstacks... though I just noticed we don't do that for
softirqs... paulus, isn't there a chance that we may lose a signal
there ? I wouldn't expect softirq's to often send signals to current
thread info (ie, they would use targetted flag sending which means the
SIGPENDING flag will be set in the right thread_info obtained from the
target task struct) but it still sounds safer to copy the flags back
just in case...

 yeah, so we are now pointing to stack bottom.  will fix this up.

Call it base rather than bottom, sounds nicer :-)

 I agree we run all these interrupt levels with EE disabled.  Not
 sure  
 I follow what you mean by irq_enter/ext.

That should do the right thing with preempt_count(), look at do_IRQ().

Ben.


___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev

Re: [PATCH v4] sysdev,mv64x60: MV64x60 device bus

2008-04-30 Thread Stephen Rothwell

Hi Remi,

On Wed, 30 Apr 2008 09:47:16 -0700 Remi Machet [EMAIL PROTECTED] wrote:

 For each mv64360 entry in the OpenFirmware database, add the 
 registration of an of_bus to take care of devices connected to
 the MV64x60 asynchronous devices controller.
 This change makes it possible for those devices to be detected by 
 drivers that support the of_platform without having a custom call 
 for each of them in the board file.
 
 Signed-off-by: Remi Machet ([EMAIL PROTECTED])

You really should use '' and '' to surround your email address.

-- 
Cheers,
Stephen Rothwell[EMAIL PROTECTED]
http://www.canb.auug.org.au/~sfr/


pgp63V3GJNKpZ.pgp
Description: PGP signature
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev

Re: [PATCH] [POWERPC] convert transfer_to_handler into a macro


On Wed, 2008-04-30 at 18:45 -0500, Josh Boyer wrote:
  thanks.  Will take a look.  I just plan on overloading MMUCR with
 MAS0.
 
 Erg.  Why?  Please don't do that.  This is common code and MAS0
 doesn't
 make much sense on 4xx.  It'll be confusing to anyone that isn't aware
 of this change.

Nah, he meant using the slot for MAS0 in the exception frame structure
as to not have to define two different structures I suppose...

 Can we come up with a generic #define that gets used instead?
 
 josh

Ben.


___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev

Re: [PATCH] [POWERPC] convert transfer_to_handler into a macro

2008-04-30 Thread Josh Boyer

On Thu, 01 May 2008 09:53:22 +1000
Benjamin Herrenschmidt [EMAIL PROTECTED] wrote:

 
 On Wed, 2008-04-30 at 18:45 -0500, Josh Boyer wrote:
   thanks.  Will take a look.  I just plan on overloading MMUCR with
  MAS0.
  
  Erg.  Why?  Please don't do that.  This is common code and MAS0
  doesn't
  make much sense on 4xx.  It'll be confusing to anyone that isn't aware
  of this change.
 
 Nah, he meant using the slot for MAS0 in the exception frame structure
 as to not have to define two different structures I suppose...

Ah, ok.  Sorry, still playing catch up on email.  I thought we were
talking about a #define.

josh
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev

Re: [PATCH v4] sysdev,mv64x60: MV64x60 device bus

2008-04-30 Thread Remi Machet

Yes, I am sorry. I will post another patch in a few minutes ...

Remi

On Thu, 2008-05-01 at 09:54 +1000, Stephen Rothwell wrote:
 Hi Remi,
 
 On Wed, 30 Apr 2008 09:47:16 -0700 Remi Machet [EMAIL PROTECTED] wrote:
 
  For each mv64360 entry in the OpenFirmware database, add the 
  registration of an of_bus to take care of devices connected to
  the MV64x60 asynchronous devices controller.
  This change makes it possible for those devices to be detected by 
  drivers that support the of_platform without having a custom call 
  for each of them in the board file.
  
  Signed-off-by: Remi Machet ([EMAIL PROTECTED])
 
 You really should use '' and '' to surround your email address.
 

___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev

Re: [PATCH] [POWERPC] devres: Add devm_ioremap_flags()

2008-04-30 Thread Tejun Heo


Kumar Gala wrote:

From: Emil Medve [EMAIL PROTECTED]

We provide an ioremap_flags so provide a coresphonding devm_ioremap_flags.

Signed-off-by: Emil Medve [EMAIL PROTECTED]
Signed-off-by: Kumar Gala [EMAIL PROTECTED]


Acked-by: Tejun Heo [EMAIL PROTECTED]

--
tejun
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev

[PATCH v5] sysdev,mv64x60: MV64x60 device bus

2008-04-30 Thread Remi Machet

For each mv64360 entry in the OpenFirmware database, add the 
registration of an of_bus to take care of devices connected to
the MV64x60 asynchronous devices controller.
This change makes it possible for those devices to be detected by 
drivers that support the of_platform without having a custom call 
for each of them in the board file.

Signed-off-by: Remi Machet [EMAIL PROTECTED]
---
Changes:
v2: Use the compatible field to detect devices to register (on Dale Farnsworth
suggestion).
v3: Added __initdata to variable of_mv64x60_devices (thanks to Stephen Rothwell 
for pointing that out).
v4: Re-wrote the patch description.
v5: Changed the format of the email address

 arch/powerpc/sysdev/mv64x60_dev.c |   10 ++
 1 files changed, 10 insertions(+)

diff --git a/arch/powerpc/sysdev/mv64x60_dev.c 
b/arch/powerpc/sysdev/mv64x60_dev.c
index 41af122..c38695e 100644
--- a/arch/powerpc/sysdev/mv64x60_dev.c
+++ b/arch/powerpc/sysdev/mv64x60_dev.c
@@ -15,6 +15,7 @@
 #include linux/console.h
 #include linux/mv643xx.h
 #include linux/platform_device.h
+#include linux/of_platform.h
 
 #include asm/prom.h
 
@@ -25,6 +26,11 @@
  * PowerPC of_platform_bus_type.  They support platform_bus_type instead.
  */
 
+static struct of_device_id __initdata of_mv64x60_devices[] = {
+   { .compatible = marvell,mv64306-devctrl, },
+   {}
+};
+
 /*
  * Create MPSC platform devices
  */
@@ -482,6 +488,10 @@ static int __init mv64x60_device_setup(void)
of_node_put(np);
}
 
+   /* Now add every node that is on the device bus */
+   for_each_compatible_node(np, NULL, marvell,mv64360)
+   of_platform_bus_probe(np, of_mv64x60_devices, NULL);
+
return 0;
 }
 arch_initcall(mv64x60_device_setup);


___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev

Re: [PATCH] [POWERPC] convert transfer_to_handler into a macro


On Wed, 2008-04-30 at 19:11 -0500, Josh Boyer wrote:
 
  Nah, he meant using the slot for MAS0 in the exception frame
 structure
  as to not have to define two different structures I suppose...
 
 Ah, ok.  Sorry, still playing catch up on email.  I thought we were
 talking about a #define.

Heh, now that I think about it ... maybe :-) That would be bad indeed.
Kumar ?

Cheers
Ben.

___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev

Re: [PATCH v2] [POWERPC] devres: Add devm_ioremap_flags()

2008-04-30 Thread Stephen Rothwell

On Wed, 30 Apr 2008 11:08:51 -0500 (CDT) Kumar Gala [EMAIL PROTECTED] wrote:

 +++ b/arch/powerpc/lib/devres.c
 @@ -0,0 +1,33 @@
 +#include linux/device.h/* devres_*(), devm_ioremap_release() */
 +#include linux/io.h/* ioremap_flags() */
 +#include linux/module.h/* EXPORT_SYMBOL() */

This file needs a copyright notice and license ...

-- 
Cheers,
Stephen Rothwell[EMAIL PROTECTED]
http://www.canb.auug.org.au/~sfr/


pgpYkxHu6jSfm.pgp
Description: PGP signature
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev

Re: [PATCH v2] [POWERPC] devres: Add devm_ioremap_flags()



On Apr 30, 2008, at 8:18 PM, Stephen Rothwell wrote:
On Wed, 30 Apr 2008 11:08:51 -0500 (CDT) Kumar Gala [EMAIL PROTECTED] 
 wrote:


+++ b/arch/powerpc/lib/devres.c
@@ -0,0 +1,33 @@
+#include linux/device.h/* devres_*(), devm_ioremap_release() */
+#include linux/io.h/* ioremap_flags() */
+#include linux/module.h/* EXPORT_SYMBOL() */


This file needs a copyright notice and license ...


agreed.  will add.

- k
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev

Re: [PATCH] [POWERPC] convert transfer_to_handler into a macro