date:20090623

Hi all,

Turning on SWIOTLB selects or enables PPC_NEED_DMA_SYNC_OPS, which means
we get the non empty versions of dma_sync_* in asm/dma-mapping.h

On my pseries machine the dma_ops have no such routines and we die with
a null pointer - this patch gets it booting, is there a more elegant way
to do it?

cheers

diff --git a/arch/powerpc/include/asm/dma-mapping.h 
b/arch/powerpc/include/asm/dma-mapping.h
index 3d9e887..b44aaab 100644
--- a/arch/powerpc/include/asm/dma-mapping.h
+++ b/arch/powerpc/include/asm/dma-mapping.h
@@ -309,7 +309,9 @@ static inline void dma_sync_single_for_cpu(struct device 
*dev,
struct dma_mapping_ops *dma_ops = get_dma_ops(dev);
 
BUG_ON(!dma_ops);
-   dma_ops-sync_single_range_for_cpu(dev, dma_handle, 0,
+
+   if (dma_ops-sync_single_range_for_cpu)
+   dma_ops-sync_single_range_for_cpu(dev, dma_handle, 0,
   size, direction);
 }
 
@@ -320,7 +322,9 @@ static inline void dma_sync_single_for_device(struct device 
*dev,
struct dma_mapping_ops *dma_ops = get_dma_ops(dev);
 
BUG_ON(!dma_ops);
-   dma_ops-sync_single_range_for_device(dev, dma_handle,
+
+   if (dma_ops-sync_single_range_for_device)
+   dma_ops-sync_single_range_for_device(dev, dma_handle,
  0, size, direction);
 }
 
@@ -331,7 +335,9 @@ static inline void dma_sync_sg_for_cpu(struct device *dev,
struct dma_mapping_ops *dma_ops = get_dma_ops(dev);
 
BUG_ON(!dma_ops);
-   dma_ops-sync_sg_for_cpu(dev, sgl, nents, direction);
+
+   if (dma_ops-sync_sg_for_cpu)
+   dma_ops-sync_sg_for_cpu(dev, sgl, nents, direction);
 }
 
 static inline void dma_sync_sg_for_device(struct device *dev,
@@ -341,7 +347,9 @@ static inline void dma_sync_sg_for_device(struct device 
*dev,
struct dma_mapping_ops *dma_ops = get_dma_ops(dev);
 
BUG_ON(!dma_ops);
-   dma_ops-sync_sg_for_device(dev, sgl, nents, direction);
+
+   if (dma_ops-sync_sg_for_device)
+   dma_ops-sync_sg_for_device(dev, sgl, nents, direction);
 }
 
 static inline void dma_sync_single_range_for_cpu(struct device *dev,
@@ -351,7 +359,9 @@ static inline void dma_sync_single_range_for_cpu(struct 
device *dev,
struct dma_mapping_ops *dma_ops = get_dma_ops(dev);
 
BUG_ON(!dma_ops);
-   dma_ops-sync_single_range_for_cpu(dev, dma_handle,
+
+   if (dma_ops-sync_single_range_for_cpu)
+   dma_ops-sync_single_range_for_cpu(dev, dma_handle,
   offset, size, direction);
 }
 
@@ -362,7 +372,9 @@ static inline void dma_sync_single_range_for_device(struct 
device *dev,
struct dma_mapping_ops *dma_ops = get_dma_ops(dev);
 
BUG_ON(!dma_ops);
-   dma_ops-sync_single_range_for_device(dev, dma_handle, offset,
+
+   if (dma_ops-sync_single_range_for_device)
+   dma_ops-sync_single_range_for_device(dev, dma_handle, offset,
  size, direction);
 }
 #else /* CONFIG_PPC_NEED_DMA_SYNC_OPS */
-- 
1.6.2.1



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

Re: [PATCH] spufs: remove redundant test on unsigned

2009-06-23 Thread Jeremy Kerr

Roel,

 Unsigned `len' cannot be less than 0.

 Signed-off-by: Roel Kluin roel.kl...@gmail.com

Thanks for the patch. However, we have a patch from Christoph Hellwig 
pending that will rework the sputrace code:

 http://patchwork.ozlabs.org/patch/28641/

It's currently queued in benh's tree, should be up soon.

Cheers,


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

Re: Swiotlb breaks pseries

On Tue, 2009-06-23 at 19:13 +1000, Michael Ellerman wrote:
 Hi all,
 
 Turning on SWIOTLB selects or enables PPC_NEED_DMA_SYNC_OPS, which means
 we get the non empty versions of dma_sync_* in asm/dma-mapping.h
 
 On my pseries machine the dma_ops have no such routines and we die with
 a null pointer - this patch gets it booting, is there a more elegant way
 to do it?

No that's the best way (checking for NULL in the inlines), avoids
calling through a function pointer when not needed, since this can
be a fairly hot path, especially with networking.

Cheers,
Ben.

 cheers
 
 diff --git a/arch/powerpc/include/asm/dma-mapping.h 
 b/arch/powerpc/include/asm/dma-mapping.h
 index 3d9e887..b44aaab 100644
 --- a/arch/powerpc/include/asm/dma-mapping.h
 +++ b/arch/powerpc/include/asm/dma-mapping.h
 @@ -309,7 +309,9 @@ static inline void dma_sync_single_for_cpu(struct device 
 *dev,
   struct dma_mapping_ops *dma_ops = get_dma_ops(dev);
  
   BUG_ON(!dma_ops);
 - dma_ops-sync_single_range_for_cpu(dev, dma_handle, 0,
 +
 + if (dma_ops-sync_single_range_for_cpu)
 + dma_ops-sync_single_range_for_cpu(dev, dma_handle, 0,
  size, direction);
  }
  
 @@ -320,7 +322,9 @@ static inline void dma_sync_single_for_device(struct 
 device *dev,
   struct dma_mapping_ops *dma_ops = get_dma_ops(dev);
  
   BUG_ON(!dma_ops);
 - dma_ops-sync_single_range_for_device(dev, dma_handle,
 +
 + if (dma_ops-sync_single_range_for_device)
 + dma_ops-sync_single_range_for_device(dev, dma_handle,
 0, size, direction);
  }
  
 @@ -331,7 +335,9 @@ static inline void dma_sync_sg_for_cpu(struct device *dev,
   struct dma_mapping_ops *dma_ops = get_dma_ops(dev);
  
   BUG_ON(!dma_ops);
 - dma_ops-sync_sg_for_cpu(dev, sgl, nents, direction);
 +
 + if (dma_ops-sync_sg_for_cpu)
 + dma_ops-sync_sg_for_cpu(dev, sgl, nents, direction);
  }
  
  static inline void dma_sync_sg_for_device(struct device *dev,
 @@ -341,7 +347,9 @@ static inline void dma_sync_sg_for_device(struct device 
 *dev,
   struct dma_mapping_ops *dma_ops = get_dma_ops(dev);
  
   BUG_ON(!dma_ops);
 - dma_ops-sync_sg_for_device(dev, sgl, nents, direction);
 +
 + if (dma_ops-sync_sg_for_device)
 + dma_ops-sync_sg_for_device(dev, sgl, nents, direction);
  }
  
  static inline void dma_sync_single_range_for_cpu(struct device *dev,
 @@ -351,7 +359,9 @@ static inline void dma_sync_single_range_for_cpu(struct 
 device *dev,
   struct dma_mapping_ops *dma_ops = get_dma_ops(dev);
  
   BUG_ON(!dma_ops);
 - dma_ops-sync_single_range_for_cpu(dev, dma_handle,
 +
 + if (dma_ops-sync_single_range_for_cpu)
 + dma_ops-sync_single_range_for_cpu(dev, dma_handle,
  offset, size, direction);
  }
  
 @@ -362,7 +372,9 @@ static inline void 
 dma_sync_single_range_for_device(struct device *dev,
   struct dma_mapping_ops *dma_ops = get_dma_ops(dev);
  
   BUG_ON(!dma_ops);
 - dma_ops-sync_single_range_for_device(dev, dma_handle, offset,
 +
 + if (dma_ops-sync_single_range_for_device)
 + dma_ops-sync_single_range_for_device(dev, dma_handle, offset,
 size, direction);
  }
  #else /* CONFIG_PPC_NEED_DMA_SYNC_OPS */

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

Re: [PATCH v2] powerpc: 85xx: Add PHY fixup to socrates board code

2009-06-23 Thread Anatolij Gustschin

Kumar Gala wrote:
 
 On Apr 21, 2009, at 6:24 PM, Anatolij Gustschin wrote:
 
 Kumar Gala wrote:

 On Apr 21, 2009, at 4:54 PM, Kumar Gala wrote:


 On Apr 21, 2009, at 12:19 PM, Anatolij Gustschin wrote:

 If the firmware missed to initialize the PHY correctly,
 Linux may hang up on socrates while eth0/eth1 interface
 startup (caused by continuous unacknowledged PHY interrupt).

 This patch adds PHY fixup to socrates platform code to
 ensure the PHY is pre-initialized correctly. It is needed
 to be compatible with older firmware.

 Signed-off-by: Anatolij Gustschin ag...@denx.de
 ---
 Changes since first version:
use macros instead of register numbers as
suggested by Anton

 Kumar, could you please consider this patch for
 inclusion into 2.6.30? Thanks!

 Sorry.  I dont think this is board specific and should at a minimum be
 done in m88e1011_config_init in drivers/net/phy/marvell.c.  Not sure
 how 88E1011 differs from 88E, but I'm wondering if you really want
 to set config_init for m88e1011 to m88e_config_init

 - k

 I got confused by the #'s.. I think we should have a struct in marvell.c
 for m88e1121 which I'm guessing is the PHY you are using.

 yes, m88e1121 is correct. In 2.6.30-rc2 there is already a m88e1121
 struct in marvell_drivers[] in drivers/net/phy/marvell.c.
 The reason I'm not doing the m88e1121 pre-init stuff in config_init
 is as follows:

 m88e1121 is a multi-PHY device with two PHY ports and each port
 could signal an interrupt. This PHY device can be pin-strapped to use
 shared interrupt pin for both PHY ports (as used on socrates board).
 PHY specific config_init will be called e.g. while eth0 startup in
 phy_attach() which is called from phy_connect() in
 drivers/net/phy/phy_device.c.
 phy_connect() then calls phy_start_interrupts() which registers the
 interrupt handler and enables the interrupts for the PHY-port config_init
 is called for. Now interrupts can be cleared/acknowledged for this
 PHY-port (eth0 interface), but interrupts from the another PHY-port
 can not be acknowledged as eth1 was not brought up yet.

 Placing this fixup in drivers/net/phy/marvell.c as in config_init
 callback
 could be done, but this will add more overhead as the fixup routine have
 to do more work:

 acquire 'struct mii_bus' pointer and walk through all registered PHYs
 searching for the PHY which use the same interrupt, then getting
 the address of this PHY on the bus and disable and clear PHY irqs
 by writing/reading to/from this PHY, (but only in the case it was
 not already brought up and has interrupts enabled!) e.g.:

 struct mii_bus *bus = phydev-bus;
 int addr;

 for (addr = 0; addr  PHY_MAX_ADDR; addr++) {
 struct phy_device *phy = bus-phy_map[addr];

 if (addr != phydev-addr  bus-irq[addr] == phydev-irq 
 (phy-phy_id  0x0ff0) == 0x01410cb0 
 !(phy-interrupts  PHY_INTERRUPT_ENABLED)) {

 int imask = phy_read(phy, MII_M1011_IMASK);

 if (imask) {
 phy_write(phy, 0x12, 0); /* disable */
 phy_read(phy, 0x13); /* clear */
 }
 }
 }

 All this to allow support for multiple m88e1121 devices.
 Otherwise, after registering first phy interrupt handler
 and enabling interrupt pending irq on other PHY port or
 other PHY device will lock up the board.

 The fixup in this patch will only be done while mdio bus scan
 before registering a PHY device.
 
 Did we ever resolve this?

No. I think newer U-Boot should be used instead of fixing this
in Linux PHY driver or board specific code. The problem is fixed
in U-Boot v2009.01.

Anatolij

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

Re: [PATCH v3 2/2] fsldma: Add DMA_SLAVE support

2009-06-23 Thread Li Yang

On Tue, Jun 23, 2009 at 5:20 AM, Dan Williamsdan.j.willi...@intel.com wrote:
 On Fri, 2009-06-19 at 12:31 -0700, Ira Snyder wrote:
 Use the DMA_SLAVE capability of the DMAEngine API to copy/from a
 scatterlist into an arbitrary list of hardware address/length pairs.

 This allows a single DMA transaction to copy data from several different
 devices into a scatterlist at the same time.

 This also adds support to enable some controller-specific features such as
 external start and external pause for a DMA transaction.

 Signed-off-by: Ira W. Snyder i...@ovro.caltech.edu
 ---

 This patch depends on the fsldma: split apart external pause and
 request count features patch.

 After discussion with Dan Williams, this is the third version of the
 DMA_SLAVE API for the Freescale DMA controller. I've tested it heavily
 with both drivers I have written against this API, an FPGA programmer
 and an FPGA data grabber.

 Kumar, Dan asked me to add you to the CC list, so you can have a look at
 this patch before he adds it to his tree.

 The other two small patches I posted earlier are very helpful in testing
 this functionality. They make the fsldma driver leave the BWC (bandwidth
 control) bits alone on the 83xx controller, as well as making the
 external start feature available on 83xx.


 Kumar, Leo,

 Can I get your acked-by's for the current state of async_tx.git/next?  I
 just pushed out Ira's latest so it may take a moment to mirror out.

Acked-by: Li Yang le...@freescale.com

However, the addition of arch/powerpc/include/asm/fsldma.h still needs
the ack from Kumar.  It doesn't seem to be a common practice though.

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

Re: [PATCH v3 2/2] fsldma: Add DMA_SLAVE support



On Jun 23, 2009, at 5:18 AM, Li Yang wrote:

On Tue, Jun 23, 2009 at 5:20 AM, Dan  
Williamsdan.j.willi...@intel.com wrote:

On Fri, 2009-06-19 at 12:31 -0700, Ira Snyder wrote:

Use the DMA_SLAVE capability of the DMAEngine API to copy/from a
scatterlist into an arbitrary list of hardware address/length pairs.

This allows a single DMA transaction to copy data from several  
different

devices into a scatterlist at the same time.

This also adds support to enable some controller-specific features  
such as

external start and external pause for a DMA transaction.

Signed-off-by: Ira W. Snyder i...@ovro.caltech.edu
---

This patch depends on the fsldma: split apart external pause and
request count features patch.

After discussion with Dan Williams, this is the third version of the
DMA_SLAVE API for the Freescale DMA controller. I've tested it  
heavily
with both drivers I have written against this API, an FPGA  
programmer

and an FPGA data grabber.

Kumar, Dan asked me to add you to the CC list, so you can have a  
look at

this patch before he adds it to his tree.

The other two small patches I posted earlier are very helpful in  
testing
this functionality. They make the fsldma driver leave the BWC  
(bandwidth

control) bits alone on the 83xx controller, as well as making the
external start feature available on 83xx.



Kumar, Leo,

Can I get your acked-by's for the current state of async_tx.git/ 
next?  I

just pushed out Ira's latest so it may take a moment to mirror out.


Acked-by: Li Yang le...@freescale.com

However, the addition of arch/powerpc/include/asm/fsldma.h still needs
the ack from Kumar.  It doesn't seem to be a common practice though.


hmm, why are we moving fsldma.h?

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

Re: [PATCH] powerpc/85xx: Make eSDHC 1-bit only transfer mode default for MPC8569E-MDS



On Jun 18, 2009, at 6:37 PM, Anton Vorontsov wrote:


For yet unknown reason 4-bit mode doesn't work on MPC8569E-MDS boards,
so make 1-bit mode default. When we resolve the issue, u-boot will
remove sdhci,1-bit-only property from the device tree, while SDHCI
will still work with older u-boots.

Signed-off-by: Anton Vorontsov avoront...@ru.mvista.com
---
arch/powerpc/boot/dts/mpc8569mds.dts |1 +
1 files changed, 1 insertions(+), 0 deletions(-)


applied to next

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

Re: [PATCH 4/4] powerpc/85xx: remove duplicated #include



On Jun 20, 2009, at 6:16 AM, Huang Weiyi wrote:

Remove duplicated #include in arch/powerpc/platforms/85xx/ 
xes_mpc85xx.c.


Signed-off-by: Huang Weiyi weiyi.hu...@gmail.com
---
arch/powerpc/platforms/85xx/xes_mpc85xx.c |1 -
1 files changed, 0 insertions(+), 1 deletions(-)



applied to next

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

Please pull from 'next' branch for 2.6.31

Please pull from 'next' branch of

master.kernel.org:/pub/scm/linux/kernel/git/galak/powerpc.git next

to receive the following updates:

 Documentation/powerpc/booting-without-of.txt | 1168 ---
 Documentation/powerpc/dts-bindings/4xx/emac.txt  |  148 ++
 Documentation/powerpc/dts-bindings/gpio/gpio.txt |   50
 Documentation/powerpc/dts-bindings/gpio/mdio.txt |   19
 Documentation/powerpc/dts-bindings/marvell.txt   |  521 ++
 Documentation/powerpc/dts-bindings/phy.txt   |   25
 Documentation/powerpc/dts-bindings/spi-bus.txt   |   57 +
 Documentation/powerpc/dts-bindings/usb-ehci.txt  |   25
 Documentation/powerpc/dts-bindings/xilinx.txt|  295 +
 arch/powerpc/boot/dts/mpc8569mds.dts |1
 arch/powerpc/include/asm/cpm1.h  |2
 arch/powerpc/platforms/85xx/mpc85xx_mds.c|1
 arch/powerpc/platforms/85xx/smp.c|9
 arch/powerpc/platforms/85xx/socrates.c   |6
 arch/powerpc/platforms/85xx/xes_mpc85xx.c|1
 arch/powerpc/sysdev/qe_lib/qe.c  |9
 16 files changed, 1157 insertions(+), 1180 deletions(-)

Anton Vorontsov (1):
  powerpc/85xx: Make eSDHC 1-bit only transfer mode default for MPC8569E-MDS

Huang Weiyi (1):
  powerpc/85xx: remove duplicated #include

Kumar Gala (4):
  powerpc/cpm1: Remove IMAP_ADDR
  powerpc/85xx: Stop using ppc_md.init on socrates
  powerpc/85xx: Fix issue found by lockdep trace in smp_85xx_kick_cpu
  powerpc: Refactor device tree binding

Randy Vinson (1):
  powerpc/85xx: Fix FSL RapidIO probing on MDS boards

Timur Tabi (1):
  powerpc/qe: add polling timeout to qe_issue_cmd()

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

Re: [PATCH v3 2/2] fsldma: Add DMA_SLAVE support

2009-06-23 Thread Dan Williams


Kumar Gala wrote:

Kumar, Leo,

Can I get your acked-by's for the current state of async_tx.git/ 
next?  I

just pushed out Ira's latest so it may take a moment to mirror out.

Acked-by: Li Yang le...@freescale.com

However, the addition of arch/powerpc/include/asm/fsldma.h still needs
the ack from Kumar.  It doesn't seem to be a common practice though.


hmm, why are we moving fsldma.h?


There are now two fsldma.h files.

drivers/dma/fsldma.h: no changes, houses the private driver 
implementation details.


arch/powerpc/include/asm/fsldma.h: adds some helper routines and 
definitions for the DMA_SLAVE capability of the driver.  It defines an 
interface for other drivers to use fsldma to initiate device-to-memory 
dma.  Any drivers that use the interface will depend on CONFIG_FSL_DMA 
hence placing this public header under arch/powerpc/include.


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

Re: [PATCH v4] powerpc/5200: Add mpc5200-spi (non-PSC) device driver

2009-06-23 Thread Kári Davíðsson


Lowered my SPI clock down to 1MHz (from 50MHz (in steps of 10MHz).
At 1Mhz the driver stops starving the rest of the kernel.

What is interesting is that due to the low duty cycle of the SPI port
the transfer rate at 1MHz and 50Mhz is almost the same.

I suggest that the driver simply limits max frequency to 1Mhz.

This (very limited) SPI pherperial does not handle any more anyways.

rg
kd


Grant Likely wrote:

On Tue, Jun 23, 2009 at 8:40 AM, Kári Davíðssonkari.davids...@marel.com wrote:

Hi,

I have been testing this driver a little bit (on 2.6.29.3)

What happens for me is that the driver starves the system while sending
data over the SPI interface.

I think the problem is in the function (interrupt handler)
mpc52xx_spi_irq() that calls the function mpc52xx_spi_fsm_process()
which again is an loop that iterates over the whole data to be sent.


Hmmm, the state machine is supposed to yield after each byte sent, but
on fast transfers I could see it becoming ready to run again
immediately.

Unfortunately it is not an easy problem.  The SPI device can only
handle 1 byte at a time.  Maybe it would be better for CPU fairness if
all the work was done in a thread.  I didn't originally because I
didn't want to introduce a huge amount of scheduling overhead every
time a byte was transfered, and I wanted to keep transfers fast.  I
need to think about this some more.

g.


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

Re: [PATCH v4] powerpc/5200: Add mpc5200-spi (non-PSC) device driver

2009-06-23 Thread Grant Likely

On Tue, Jun 23, 2009 at 10:31 AM, Kári
Davíðssonkari.davids...@marel.com wrote:
 Lowered my SPI clock down to 1MHz (from 50MHz (in steps of 10MHz).
 At 1Mhz the driver stops starving the rest of the kernel.

 What is interesting is that due to the low duty cycle of the SPI port
 the transfer rate at 1MHz and 50Mhz is almost the same.

 I suggest that the driver simply limits max frequency to 1Mhz.

Sounds good to me.  Thanks for the testing!

 This (very limited) SPI pherperial does not handle any more anyways.

indeed.

g.


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

Re: [PATCH v2] fbdev: work around old compiler bug

2009-06-23 Thread Kyle McMartin

On Tue, Jun 23, 2009 at 03:44:28PM +1000, Stephen Rothwell wrote:
 When building with a 4.1.x compiler on powerpc64 (at least) we get
 this error:
 
 drivers/video/logo/logo_linux_mono.c:81: error: logo_linux_mono causes a 
 section type conflict
 
 This was introduced by commit ae52bb2384f721562f15f719de1acb8e934733cb
 (fbdev: move logo externs to header file).  This is a partial revert
 of that commit sufficient to not hit the compiler bug.
 

We're seeing similar issues with 4.3 on parisc (the case I saw today was
in fs/nfs/nfsroot.c...) Any ideas on the actual culprit or is it just
gcc being unfriendly?

regards, Kyle
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: [PATCH] powerpc/ps3: Use pr_devel() in ps3/mm.c

2009-06-23 Thread Geoff Levand

On 06/22/2009 06:56 PM, Michael Ellerman wrote:
 The non-debug case in ps3/mm.c uses pr_debug(), so that the compiler
 still does type checks etc. and doesn't complain about unused
 variables in the non-debug case.
 
 However with DEBUG=n and CONFIG_DYNAMIC_DEBUG=y there's still code
 generated for those pr_debugs().
 
 Signed-off-by: Michael Ellerman mich...@ellerman.id.au
 ---
  arch/powerpc/platforms/ps3/mm.c |2 +-
  1 files changed, 1 insertions(+), 1 deletions(-)

Looks good, thanks.  I put it on the todo list to go through
the the remaining PS3 code to check for the same.

Acked-by: Geoff Levand geoffrey.lev...@am.sony.com

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

Re: [ewg] Re: [PATCH 2.6.31 try 2] ehca: Tolerate dynamic memory operations and huge pages

2009-06-23 Thread Roland Dreier

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

Re: [PATCH v2] fbdev: work around old compiler bug

2009-06-23 Thread Sam Ravnborg

On Tue, Jun 23, 2009 at 12:45:05PM -0400, Kyle McMartin wrote:
 On Tue, Jun 23, 2009 at 03:44:28PM +1000, Stephen Rothwell wrote:
  When building with a 4.1.x compiler on powerpc64 (at least) we get
  this error:
  
  drivers/video/logo/logo_linux_mono.c:81: error: logo_linux_mono causes a 
  section type conflict
  
  This was introduced by commit ae52bb2384f721562f15f719de1acb8e934733cb
  (fbdev: move logo externs to header file).  This is a partial revert
  of that commit sufficient to not hit the compiler bug.
  
 
 We're seeing similar issues with 4.3 on parisc (the case I saw today was
 in fs/nfs/nfsroot.c...) Any ideas on the actual culprit or is it just
 gcc being unfriendly?

Al analysed this some time ago.
When we say something is const then _sometimes_ gcc annotate the
section as const(*) - sometimes not.
So if we have two variables/functions annotated __*const and
gcc decides to annotate the section const only in one case
we get a section type conflict.

(*) it is named something else I do not recall at the moment
in linker language.

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

Re: ALSA fixes for non-coherent ppc32 again

2009-06-23 Thread Gerhard Pircher


 Original-Nachricht 
 Datum: Tue, 23 Jun 2009 10:55:54 +0200
 Von: Gerhard Pircher gerhard_pirc...@gmx.net
 An: Takashi Iwai ti...@suse.de, b...@kernel.crashing.org
 CC: linuxppc-...@ozlabs.org
 Betreff: Re: ALSA fixes for non-coherent ppc32 again

 
  Original-Nachricht 
  Datum: Mon, 22 Jun 2009 09:12:35 +0200
  Von: Takashi Iwai ti...@suse.de
  An: Benjamin Herrenschmidt b...@kernel.crashing.org
  CC: Gerhard Pircher gerhard_pirc...@gmx.net, linuxppc-...@ozlabs.org
  Betreff: Re: ALSA fixes for non-coherent ppc32 again
 
  But, it'd be helpful if someone can test the patches above beforehand,
  of course :)
 Okay, I checked out your test/dma-fix branch and reformatted your
 dma_mmap_coherent for powerpc patch (
 http://www.nabble.com/-PATCH-0-3--ALSA-fixes-for-non-coherent-ppc32-to17980027.html#a17980027
  ) to
 adapt it for dma_mapping_ops (please take a look at the patch below).
 I also had to change def_bool n to def_bool y for SND_NONCOHERENT_DMA
 to actually enable it.
 
 Unfortunately the build process stops with these error messages here
 (but compiles fine, if SND_COHERENT_DMA is not selected):
 
   CC [M]  sound/core/memalloc.o
   CC [M]  sound/core/sgbuf.o
 sound/core/sgbuf.c: In function ‘snd_free_sgbuf_pages’:
 sound/core/sgbuf.c:46: error: dereferencing pointer to incomplete type
 sound/core/sgbuf.c:47: error: dereferencing pointer to incomplete type
 sound/core/sgbuf.c:48: error: dereferencing pointer to incomplete type
 sound/core/sgbuf.c:50: error: dereferencing pointer to incomplete type
 sound/core/sgbuf.c:51: error: dereferencing pointer to incomplete type
 sound/core/sgbuf.c:52: error: dereferencing pointer to incomplete type
 sound/core/sgbuf.c:56: error: dereferencing pointer to incomplete type
 sound/core/sgbuf.c:57: error: dereferencing pointer to incomplete type
 sound/core/sgbuf.c: In function ‘snd_malloc_sgbuf_pages’:
 sound/core/sgbuf.c:78: error: dereferencing pointer to incomplete type
 sound/core/sgbuf.c:81: error: dereferencing pointer to incomplete type
 sound/core/sgbuf.c:82: error: implicit declaration of function
 ‘snd_sgbuf_aligned_pages’
 sound/core/sgbuf.c:83: error: dereferencing pointer to incomplete type
 sound/core/sgbuf.c:84: error: dereferencing pointer to incomplete type
 sound/core/sgbuf.c:84: error: dereferencing pointer to incomplete type
 sound/core/sgbuf.c:87: error: dereferencing pointer to incomplete type
 sound/core/sgbuf.c:88: error: dereferencing pointer to incomplete type
 sound/core/sgbuf.c:91: error: dereferencing pointer to incomplete type
 sound/core/sgbuf.c:103: error: dereferencing pointer to incomplete type
 sound/core/sgbuf.c:107: error: dereferencing pointer to incomplete type
 sound/core/sgbuf.c:112: error: dereferencing pointer to incomplete type
 sound/core/sgbuf.c:113: error: dereferencing pointer to incomplete type
 sound/core/sgbuf.c:115: error: dereferencing pointer to incomplete type
 sound/core/sgbuf.c:116: error: increment of pointer to unknown structure
 sound/core/sgbuf.c:116: error: arithmetic on pointer to an incomplete type
 sound/core/sgbuf.c:121: error: dereferencing pointer to incomplete type
 sound/core/sgbuf.c:127: error: dereferencing pointer to incomplete type
 sound/core/sgbuf.c:128: error: dereferencing pointer to incomplete type
 sound/core/sgbuf.c:128: error: dereferencing pointer to incomplete type
 sound/core/sgbuf.c:132: error: dereferencing pointer to incomplete type
 
 I also tried to compile it with the orginal dma_mmap_coherent for
 powerpc patch, but that doesn't make a difference.
 
 As the next step I applied the reformatted dma_mmap_coherent patch and
 the following patches from your test/dma-fix branch to a 2.6.30-rc8
 branch:
 - ALSA: Remove old DMA-mmap code from arm/devdma.c
 - ALSA: Fix SG-buffer DMA with non-coherent architectures
 - ALSA: Fix mapping of DMA buffers
 
 This one compiled fine, but ALSA didn't work. No kernel oops, just the
 sound of silence. :)
Okay, that's wrong. I somehow messed up the .config file. It doesn't
compile, too.

Gerhard

-- 
GRATIS für alle GMX-Mitglieder: Die maxdome Movie-FLAT!
Jetzt freischalten unter http://portal.gmx.net/de/go/maxdome01
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: sym scsi driver problem with 2.6.26 or newer debian kernel on p610 (fwd)

 I tried on a POWER3 box I have here IBM,7044-170 and things work fine
 here with current upstream. (I suspect a much smaller machine).
 
 I will really need an actual bisection here... In the meantime, I'll see
 if I can get my hand on one of these machines here.

Ok so I think we may have found it... looks like
CONFIG_MPIC_BROKEN_REGREAD is what breaks it which is enabled by PA-Semi
support in the .config.

Can you verify that disabling PA-Semi support removes that option from
your .config and that once removed, it works again ?

We don't know yet -why- it breaks it, still investigating.

Cheers,
Ben.

 Cheers,
 Ben.
 
  Cheers,
  Ben.
  
   Thanks: blackluck
   
   Laszlo Fekete wrote:
Hello!
   
I'm sorry about the annoyances, but I'd welcome all ideas, suggestions 
to see what needs to be done or should be tested for the solution.
   
Thank you very much!
   
Guennadi Liakhovetski wrote:
Ok, first attempt to forward this to scsi was wrong, as pointed out 
by Matthew Wilcox this does indeed look like an interrupt problem - 
no interrupts drom SCSI, IDE, keyboar. Might be a known problem, I 
guess. In any case, I think, the OP would be grateful for any hints.
   
Thanks
Guennadi
---
Guennadi Liakhovetski, Ph.D.
Freelance Open-Source Software Developer
http://www.open-technology.de/
   
-- Forwarded message --
Date: Sat, 13 Jun 2009 16:22:07 +0200
From: Laszlo Fekete blackl...@ktk.bme.hu
To: debian-powe...@lists.debian.org
Subject: sym scsi driver problem with 2.6.26 or newer debian kernel 
on p610
Resent-Date: Sat, 13 Jun 2009 14:29:55 + (UTC)
Resent-From: debian-powe...@lists.debian.org
   
This is a multi-part message in MIME format.

   
Hello!
   
   
   
   
   
Pls help me with sym scsi driver problem.
   
   
   
I have Ibm P610 (and tested it on P630 and P640 too), installed debian
   
etch and upgraded to lenny.
   
   
   
But with 2.6.26 or newer kernel it's not booting, it's hang on sym scsi
   
bus scan.
   
   
   
   
   
Whats the problem with it, or how can I fix this?
   
   
   
   
   
I attach the output from minicom with 2.6.29, 2.6.26, and the working
   
2.6.24 kernel booting.
   
   
   
   
   
Thank you very much!
   
   
  
   
   
   
   ___
   Linuxppc-dev mailing list
   Linuxppc-dev@lists.ozlabs.org
   https://lists.ozlabs.org/listinfo/linuxppc-dev
  
  ___
  Linuxppc-dev mailing list
  Linuxppc-dev@lists.ozlabs.org
  https://lists.ozlabs.org/listinfo/linuxppc-dev
 
 ___
 Linuxppc-dev mailing list
 Linuxppc-dev@lists.ozlabs.org
 https://lists.ozlabs.org/listinfo/linuxppc-dev

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

Re: [Question] m25p80 driver versus spi clock rate

2009-06-23 Thread David Brownell

On Tuesday 23 June 2009, Steven A. Falco wrote:
 m25p80 spi0.0: invalid bits-per-word (0)
 
 This message comes from spi_ppc4xx_setupxfer.  I believe your patch
 is doing what you intended (i.e. forcing an initial call to
 spi_ppc4xx_setupxfer), but it exposes an OF / SPI linkage problem.
 
 Namely, of_register_spi_devices does not support a bits-per-word
 property, so bits-per-word is zero.

Bits-per-word == 0 must be interpreted as == 8.

Simple bug in the ppc4xx code.  It currently rejects
values other than 8.

Speaking of spi_ppc4xx issues ... I still have an oldish
copy in my review queue, it needs something like the
appended patch.  (Plus something to accept bpw == 0.)
Is there a newer version?

- Dave


--- a/drivers/spi/spi_ppc4xx.c
+++ b/drivers/spi/spi_ppc4xx.c
@@ -61,9 +61,6 @@
 /* RxD ready */
 #define SPI_PPC4XX_SR_RBR  (0x80  7)
 
-/* the spi-mode bits understood by this driver: */
-#define MODEBITS   (SPI_CPHA | SPI_CPOL | SPI_CS_HIGH | SPI_LSB_FIRST)
-
 /* clock settings (SCP and CI) for various SPI modes */
 #define SPI_CLK_MODE0  SPI_PPC4XX_MODE_SCP
 #define SPI_CLK_MODE1  0
@@ -198,9 +195,6 @@ static int spi_ppc4xx_setup(struct spi_d
struct spi_ppc4xx_cs *cs = spi-controller_state;
int init = 0;
 
-   if (!spi-bits_per_word)
-   spi-bits_per_word = 8;
-
if (spi-bits_per_word != 8) {
dev_err(spi-dev, invalid bits-per-word (%d)\n,
spi-bits_per_word);
@@ -212,12 +206,6 @@ static int spi_ppc4xx_setup(struct spi_d
return -EINVAL;
}
 
-   if (spi-mode  ~MODEBITS) {
-   dev_dbg(spi-dev, setup: unsupported mode bits %x\n,
-   spi-mode  ~MODEBITS);
-   return -EINVAL;
-   }
-
if (cs == NULL) {
cs = kzalloc(sizeof *cs, GFP_KERNEL);
if (!cs)
@@ -268,10 +256,6 @@ static int spi_ppc4xx_setup(struct spi_d
}
}
 
-   dev_dbg(spi-dev, %s: mode %d, %u bpw, %d hz\n,
-   __func__, spi-mode, spi-bits_per_word,
-   spi-max_speed_hz);
-
return 0;
 }
 
@@ -442,6 +426,9 @@ static int __init spi_ppc4xx_of_probe(st
}
}
 
+   /* the spi-mode bits understood by this driver: */
+   master-modebits = SPI_CPHA | SPI_CPOL | SPI_CS_HIGH | SPI_LSB_FIRST;
+
/* Setup the state for the bitbang driver */
bbp = hw-bitbang;
bbp-master = hw-master;

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

Re: sym scsi driver problem with 2.6.26 or newer debian kernel on p610 (fwd)

On Wed, 2009-06-24 at 07:57 +1000, Benjamin Herrenschmidt wrote:
  I tried on a POWER3 box I have here IBM,7044-170 and things work fine
  here with current upstream. (I suspect a much smaller machine).
  
  I will really need an actual bisection here... In the meantime, I'll see
  if I can get my hand on one of these machines here.
 
 Ok so I think we may have found it... looks like
 CONFIG_MPIC_BROKEN_REGREAD is what breaks it which is enabled by PA-Semi
 support in the .config.
 
 Can you verify that disabling PA-Semi support removes that option from
 your .config and that once removed, it works again ?
 
 We don't know yet -why- it breaks it, still investigating.

Do the following patch also fix it ?

Index: linux-work/arch/powerpc/sysdev/mpic.c
===
--- linux-work.orig/arch/powerpc/sysdev/mpic.c  2009-06-24 09:24:51.0 
+1000
+++ linux-work/arch/powerpc/sysdev/mpic.c   2009-06-24 09:26:45.0 
+1000
@@ -230,14 +230,16 @@ static inline u32 _mpic_irq_read(struct 
 {
unsigned intisu = src_no  mpic-isu_shift;
unsigned intidx = src_no  mpic-isu_mask;
+   unsigned intval;
 
+   val = _mpic_read(mpic-reg_type, mpic-isus[isu],
+reg + (idx * MPIC_INFO(IRQ_STRIDE)));  
 #ifdef CONFIG_MPIC_BROKEN_REGREAD
if (reg == 0)
-   return mpic-isu_reg0_shadow[idx];
-   else
+   val = (val  (MPIC_VECPRI_MASK | MPIC_VECPRI_ACTIVITY)) |
+   mpic-isu_reg0_shadow[idx];
 #endif
-   return _mpic_read(mpic-reg_type, mpic-isus[isu],
- reg + (idx * MPIC_INFO(IRQ_STRIDE)));
+   return val;
 }
 
 static inline void _mpic_irq_write(struct mpic *mpic, unsigned int src_no,
@@ -251,7 +253,8 @@ static inline void _mpic_irq_write(struc
 
 #ifdef CONFIG_MPIC_BROKEN_REGREAD
if (reg == 0)
-   mpic-isu_reg0_shadow[idx] = value;
+   mpic-isu_reg0_shadow[idx] =
+   value  ~(MPIC_VECPRI_MASK | MPIC_VECPRI_ACTIVITY);
 #endif
 }
 


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

Re: [PATCH] Do not inline putprops function

On Tue, 2009-06-23 at 09:56 -0400, Neil Horman wrote:
 On Tue, Jun 23, 2009 at 06:25:34PM +0530, M. Mohan Kumar wrote:
  On Wed, Jun 17, 2009 at 10:40:07AM -0400, Neil Horman wrote:
   
send objdump of fs2dt.o with and without this assignment.

   That would be a fine thing to do, and I'd be happy to compare them.  My 
   though
   regarding the comparison of the device tree on a good and bad run was 
   meant to
   expidite what change in the assembly we'd be looking for.  If its the 
   kdump
   kernel boot thats hanging, Its likely hanging on something in the device 
   tree,
   as thats whats being manipulated by this code.  So I figure that 
   understanding
   whats changed there will point us toward what change in the assembly 
   might be
   responsible for the hang.  The assmebly's going to be signficantly 
   different
   (lots of optimization might be lost from no longer inlining a function), 
   so
   anything that helps us narrow down whats changed will be good
  
  I am attaching the objdumps of fs2dt with and without dt_len.
  
 Well it definately looks like removing that variable had some code changes.
 It'll take some time to match it up to source, but Most interesting I think is
 the variance in putprops around address f34.  Looks like its doing some string
 maniuplation in a reversed order, using a huge offset.  Might be worthwhile to
 check to see if theres any string overruns in this code.

Yeah I still suspect it's just a bug in the code that's being exposed
now.

Mohan, can you try running it under valgrind?

cheers


signature.asc
Description: This is a digitally signed message part
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: [PATCH] powerpc/ps3: Use pr_devel() in ps3/mm.c

On Tue, 2009-06-23 at 09:53 -0700, Geoff Levand wrote:
 On 06/22/2009 06:56 PM, Michael Ellerman wrote:
  The non-debug case in ps3/mm.c uses pr_debug(), so that the compiler
  still does type checks etc. and doesn't complain about unused
  variables in the non-debug case.
  
  However with DEBUG=n and CONFIG_DYNAMIC_DEBUG=y there's still code
  generated for those pr_debugs().
  
  Signed-off-by: Michael Ellerman mich...@ellerman.id.au
  ---
   arch/powerpc/platforms/ps3/mm.c |2 +-
   1 files changed, 1 insertions(+), 1 deletions(-)
 
 Looks good, thanks.  I put it on the todo list to go through
 the the remaining PS3 code to check for the same.

Cool, I've been slowly going through as I have time but I'll leave ps3
to you. I see ~270 uses in 9 files.

There are places where being able to dynamically enable the debug is
useful, but there are plenty where it's not also.

cheers


signature.asc
Description: This is a digitally signed message part
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: How the kernel printk works before do console_setup.

2009-06-23 Thread Tim Bird

Johnny Hung wrote:
Hi All:
I have a powerpc arch platform. The default console is ttyS1 not
ttyS0 in the platform. My question is how the kernel print debug
message
like DBG before parse kernel command line and do console_setup
function. The command line passed to kernel about console info is
console=ttyS1.
So kernel can not print anything before parse cmd line and initial
console but the result is against. Anyone point me or give me a clue
is appreciate.

Before the console is set up, the printk data is formatted
and put into the kernel log buffer, but not sent to any console.
Any messages printk'ed before that are buffered but do not
appear. When the console is initialized, then all buffered
messages are sent to the console, and subsequent printks cause
the message to go to the log buffer, but then immediately
get sent from there to the console.

Under certain conditions you can examine the log buffer of
a kernel that failed to initialize it's console, after a
warm reset of the machine, using the firmware memory dump
command.

See
http://elinux.org/Kernel_Debugging_Tips#Accessing_the_printk_buffer_after_a_silent_hang_on_boot
for some tips on accessing the log buffer of a previous boot.

Note also, that if the serial console does not come up,
but the kernel successfully boots, and you can get a network
login on the machine, you can always print out the kernel log
buffer messages using 'dmesg' at a user-space shell prompt.

Hope this helps!
-- Tim

=
Tim Bird
Architecture Group Chair, CE Linux Forum
Senior Staff Engineer, Sony Corporation of America
=

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

Re: [PATCH] powerpc/mpic: Fix mapping of DCR based MPIC variants

2009-06-23 Thread Akira Tsukamoto

Hi Benjamin,

On Tue, 23 Jun 2009 12:47:59 +1000, 
Benjamin Herrenschmidt b...@kernel.crashing.org mentioned: 
 Commit 31207dab7d2e63795eb15823947bd2f7025b08e2
 Fix incorrect allocation of interrupt rev-map
 introduced a regression crashing on boot on machines using
 a DCR based MPIC, such as the Cell blades.
 
 The reason is that the irq host data structure is initialized
 much later as a result of that patch, causing our calls to
 mpic_map() do be done before we have a host setup.
 
 Unfortunately, this breaks _mpic_map_dcr() which uses the
 mpic-irqhost to get to the device node.
 
 This fixes it by, instead, passing the device node explicitely
 to mpic_map().
 
 Signed-off-by: Benjamin Herrenschmidt b...@kernel.crashing.org
 ---
 
  arch/powerpc/sysdev/mpic.c |   29 -
  1 file changed, 16 insertions(+), 13 deletions(-)

I confirmed that the boot failure on IBM Cell Blades QS21/22 are fixed 
with this patch.

Acked-by: Akira Tsukamoto aki...@rd.scei.sony.co.jp

-- 
Akira Tsukamoto
Sony Computer Entertainment Inc. 
Architecture Lab.
Japan

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

Re: sym scsi driver problem with 2.6.26 or newer debian kernel on p610 (fwd)

On Wed, 2009-06-24 at 09:29 +1000, Benjamin Herrenschmidt wrote:
 On Wed, 2009-06-24 at 07:57 +1000, Benjamin Herrenschmidt wrote:
   I tried on a POWER3 box I have here IBM,7044-170 and things work fine
   here with current upstream. (I suspect a much smaller machine).
   
   I will really need an actual bisection here... In the meantime, I'll see
   if I can get my hand on one of these machines here.
  
  Ok so I think we may have found it... looks like
  CONFIG_MPIC_BROKEN_REGREAD is what breaks it which is enabled by PA-Semi
  support in the .config.
  
  Can you verify that disabling PA-Semi support removes that option from
  your .config and that once removed, it works again ?
  
  We don't know yet -why- it breaks it, still investigating.
 
 Do the following patch also fix it ?

Doesn't fix my machine :/

cheers



signature.asc
Description: This is a digitally signed message part
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: sym scsi driver problem with 2.6.26 or newer debian kernel on p610 (fwd)