Re: [MPC5200] problem running FEC and ATA

2008-01-20 Thread Mehlan, Markus (Ritter Elektronik)
Hello all, i have the same problem with the fec driver. See my posting at http://ozlabs.org/pipermail/linuxppc-embedded/2008-January/029466.html Arnon, have you already fixed the FEC problem? Thanks and regards, Markus. ___ Linuxppc-dev mailing list Li

[PATCH] Make IOMMU code safe for > 132 GB of memory

2008-01-20 Thread Michael Ellerman
Currently the IOMMU code allocates one page for the segment table, that isn't safe if we have more than 132 GB of RAM. Signed-off-by: Michael Ellerman <[EMAIL PROTECTED]> --- arch/powerpc/platforms/cell/iommu.c |7 --- 1 files changed, 4 insertions(+), 3 deletions(-) diff --git a/arch/po

Re: [PATCH 7/7] Remove bogus comment in dma_direct_alloc_coherent()

2008-01-20 Thread Benjamin Herrenschmidt
On Mon, 2008-01-21 at 16:42 +1100, Michael Ellerman wrote: > Since commit c80d9133e99de1af607314107910a2a1645efb17 (Make direct DMA use > node local allocations) went in this comment makes no sense. > > Signed-off-by: Michael Ellerman <[EMAIL PROTECTED]> Acked-by: Benjamin Herrenschmidt <[EMAIL

Re: [PATCH 6/7] Remove the global dma_direct_offset

2008-01-20 Thread Benjamin Herrenschmidt
On Mon, 2008-01-21 at 16:42 +1100, Michael Ellerman wrote: > We no longer need the global dma_direct_offset, update the comment to > reflect the new reality. > > Signed-off-by: Michael Ellerman <[EMAIL PROTECTED]> Acked-by: Benjamin Herrenschmidt <[EMAIL PROTECTED]> > --- > arch/powerpc/kernel

Re: [PATCH 5/7] Have celleb use its own dma_direct_offset variable

2008-01-20 Thread Benjamin Herrenschmidt
On Mon, 2008-01-21 at 16:42 +1100, Michael Ellerman wrote: > Rather than using the global variable, have celleb use its own variable to > store the direct DMA offset. > > Signed-off-by: Michael Ellerman <[EMAIL PROTECTED]> Acked-by: Benjamin Herrenschmidt <[EMAIL PROTECTED]> > --- > arch/power

Re: [PATCH 4/7] Have cell use its own dma_direct_offset variable

2008-01-20 Thread Benjamin Herrenschmidt
On Mon, 2008-01-21 at 16:42 +1100, Michael Ellerman wrote: > Rather than using the global variable, have cell use its own variable to > store the direct DMA offset. > > Signed-off-by: Michael Ellerman <[EMAIL PROTECTED]> Acked-by: Benjamin Herrenschmidt <[EMAIL PROTECTED]> > --- > arch/powerpc

Re: [PATCH 4/7] Have cell use its own dma_direct_offset variable

2008-01-20 Thread Benjamin Herrenschmidt
On Mon, 2008-01-21 at 16:42 +1100, Michael Ellerman wrote: > Rather than using the global variable, have cell use its own variable to > store the direct DMA offset. > > Signed-off-by: Michael Ellerman <[EMAIL PROTECTED]> > --- > arch/powerpc/platforms/cell/iommu.c | 12 +++- > 1 files

Re: [PATCH 3/7] Use archdata.dma_data in dma_direct_ops and add the offset

2008-01-20 Thread Benjamin Herrenschmidt
On Mon, 2008-01-21 at 16:42 +1100, Michael Ellerman wrote: > Now that all platforms using dma_direct_offset setup the archdata.dma_data > correctly, we can change the dma_direct_ops to retrieve the offset from > the dma_data, rather than directly from the global. > > While we're here, change the

Re: [PATCH 2/7] Add celleb_dma_dev_setup()

2008-01-20 Thread Benjamin Herrenschmidt
On Mon, 2008-01-21 at 16:42 +1100, Michael Ellerman wrote: > Celleb always uses dma_direct_ops, and sets dma_direct_offset, so it too > should set dma_data to dma_direct_offset. > > Currently there's no pci_dma_dev_setup() routine for Celleb so add one. > > Signed-off-by: Michael Ellerman <[EMAI

Re: [PATCH 1/7] Set archdata.dma_data for direct DMA in cell_dma_dev_setup()

2008-01-20 Thread Benjamin Herrenschmidt
On Mon, 2008-01-21 at 16:42 +1100, Michael Ellerman wrote: > Store the direct_dma_offset in each device's dma_data in the case > where we're using the direct DMA ops. > > We need to make sure we setup the ppc_md.pci_dma_dev_setup() callback > if we're using a non-zero offset. > > Signed-off-by:

[PATCH 7/7] Remove bogus comment in dma_direct_alloc_coherent()

2008-01-20 Thread Michael Ellerman
Since commit c80d9133e99de1af607314107910a2a1645efb17 (Make direct DMA use node local allocations) went in this comment makes no sense. Signed-off-by: Michael Ellerman <[EMAIL PROTECTED]> --- arch/powerpc/kernel/dma_64.c |1 - 1 files changed, 0 insertions(+), 1 deletions(-) diff --git a/arc

[PATCH 6/7] Remove the global dma_direct_offset

2008-01-20 Thread Michael Ellerman
We no longer need the global dma_direct_offset, update the comment to reflect the new reality. Signed-off-by: Michael Ellerman <[EMAIL PROTECTED]> --- arch/powerpc/kernel/dma_64.c |7 --- include/asm-powerpc/dma-mapping.h |2 -- 2 files changed, 4 insertions(+), 5 deletions(-) d

[PATCH 5/7] Have celleb use its own dma_direct_offset variable

2008-01-20 Thread Michael Ellerman
Rather than using the global variable, have celleb use its own variable to store the direct DMA offset. Signed-off-by: Michael Ellerman <[EMAIL PROTECTED]> --- arch/powerpc/platforms/celleb/iommu.c |6 -- 1 files changed, 4 insertions(+), 2 deletions(-) diff --git a/arch/powerpc/platform

[PATCH 4/7] Have cell use its own dma_direct_offset variable

2008-01-20 Thread Michael Ellerman
Rather than using the global variable, have cell use its own variable to store the direct DMA offset. Signed-off-by: Michael Ellerman <[EMAIL PROTECTED]> --- arch/powerpc/platforms/cell/iommu.c | 12 +++- 1 files changed, 7 insertions(+), 5 deletions(-) diff --git a/arch/powerpc/platfo

[PATCH 3/7] Use archdata.dma_data in dma_direct_ops and add the offset

2008-01-20 Thread Michael Ellerman
Now that all platforms using dma_direct_offset setup the archdata.dma_data correctly, we can change the dma_direct_ops to retrieve the offset from the dma_data, rather than directly from the global. While we're here, change the way the offset is used - instead of or'ing it into the value, add it.

[PATCH 2/7] Add celleb_dma_dev_setup()

2008-01-20 Thread Michael Ellerman
Celleb always uses dma_direct_ops, and sets dma_direct_offset, so it too should set dma_data to dma_direct_offset. Currently there's no pci_dma_dev_setup() routine for Celleb so add one. Signed-off-by: Michael Ellerman <[EMAIL PROTECTED]> --- arch/powerpc/platforms/celleb/iommu.c | 14

[PATCH 1/7] Set archdata.dma_data for direct DMA in cell_dma_dev_setup()

2008-01-20 Thread Michael Ellerman
Store the direct_dma_offset in each device's dma_data in the case where we're using the direct DMA ops. We need to make sure we setup the ppc_md.pci_dma_dev_setup() callback if we're using a non-zero offset. Signed-off-by: Michael Ellerman <[EMAIL PROTECTED]> --- arch/powerpc/platforms/cell/iomm

Re: [PATCH] [POWERPC] Always hookup PHB IO resource even when empty

2008-01-20 Thread Michael Ellerman
On Mon, 2008-01-21 at 11:32 +1100, Benjamin Herrenschmidt wrote: > We must always hookup the pci_bus resource 0 to the PHB io_resource even > if the later is empty (the bus has no IO support). Otherwise, some other > code will end up hooking it up to something bogus and the resource tree > will end

[PATCH] [POWERPC] Always hookup PHB IO resource even when empty

2008-01-20 Thread Benjamin Herrenschmidt
We must always hookup the pci_bus resource 0 to the PHB io_resource even if the later is empty (the bus has no IO support). Otherwise, some other code will end up hooking it up to something bogus and the resource tree will end up being broken. This fixes boot on QS20 Cell blades where the IDE driv

Re: [i2c] [PATCH 19 3/5] Clean up error returns

2008-01-20 Thread Jon Smirl
Here' s a version with the compares to zero switched to NO_IRQ. If I understand how NO_IRQ works it is the correct change. My understanding is that under ppc IRQ zero was legal and NO_IRQ was -1. But then the whole kernel switched to NO_IRQ = zero. Powerpc updated to NO_IRQ=0 and used virtual IRQs

Re: [i2c] [PATCH 19 3/5] Clean up error returns

2008-01-20 Thread Jon Smirl
On 1/20/08, Jean Delvare <[EMAIL PROTECTED]> wrote: > > @@ -381,7 +385,7 @@ static int fsl_i2c_remove(struct platform_device *pdev) > > i2c_del_adapter(&i2c->adap); > > platform_set_drvdata(pdev, NULL); > > > > - if (i2c->irq != 0) > > + if (i2c->irq != NO_IRQ) > >

Re: [i2c] [PATCH 19 3/5] Clean up error returns

2008-01-20 Thread Jean Delvare
Hi Jon, On Fri, 11 Jan 2008 21:47:43 -0500, Jon Smirl wrote: > Return errors that were being ignored in the mpc-i2c driver This wording is a bit excessive. The errors were not being ignored, only the error code was replaced with a less informative -1. Still, that's a good fix, although totally un