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
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
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
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
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
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
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
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
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
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:
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
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
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
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
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.
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
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
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
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
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
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)
> >
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
22 matches
Mail list logo