Original-Nachricht
Datum: Wed, 08 Jul 2009 16:13:10 +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
At Wed,
Hallo,
On Monday 05 January 2009 16:31:33 Grant Likely wrote:
DMA support is now in mainline, but it is disabled by
default ...
I had problems using ATA DMA on an own MPC5200B board, too. This board
has no problems at all using DMA33 with DENX 2.4.25, with all kinds of
automotive disks from
On Jul 8, 2009, at 11:40 PM, Alan Modra wrote:
On Wed, Jul 08, 2009 at 10:52:59PM -0500, Kumar Gala wrote:
To further verify this if I switch the -me500 to -mspe and build
things
seem to be ok. This further points at some APU section related bug.
Like omitting .PPC.EMB.apuinfo from your
On Wed, Jul 08, 2009 at 03:58:02PM -0500, Kumar Gala wrote:
On Jul 8, 2009, at 2:33 PM, Ira W. Snyder wrote:
On Wed, Jul 08, 2009 at 01:09:39PM -0500, Kumar Gala wrote:
On Jul 8, 2009, at 11:19 AM, Ira W. Snyder wrote:
Add support for the Freescale MPC83xx memory controller to the
On Wed, Jul 08, 2009 at 05:41:39PM -0500, Kumar Gala wrote:
We are seeing an issue w/ld and kernel linking of 32-bit kernels.
The ld from fedora 11 (2.19.51.0.2-17.fc11 20090204) ends not providing
the proper address for _end.
Building stock v2.6.30 w/the mpc85xx_defconfig we get:
Hello Kumar,
I must not understand something going on here. Your proposed code
doesn't work at all on my board. The
/sys/devices/system/edac/mc/mc0/size_mb doesn't come out correctly.
What does it come out as? How much memory do you have in the system?
The attached patch DOES work on my
On Jul 9, 2009, at 11:39 AM, Dale Farnsworth wrote:
On Wed, Jul 08, 2009 at 05:41:39PM -0500, Kumar Gala wrote:
We are seeing an issue w/ld and kernel linking of 32-bit kernels.
The ld from fedora 11 (2.19.51.0.2-17.fc11 20090204) ends not
providing
the proper address for _end.
Building
On Jul 9, 2009, at 1:17 PM, Ira W. Snyder wrote:
On Thu, Jul 09, 2009 at 12:58:53PM -0500, Kumar Gala wrote:
Hello Kumar,
I must not understand something going on here. Your proposed code
doesn't work at all on my board. The
/sys/devices/system/edac/mc/mc0/size_mb doesn't come out correctly.
I haven't seen this before - the '##' in the function name. This is ANCII C?
#define MPC83XX_SPI_TX_BUF(type)\
u32 mpc83xx_spi_tx_buf_##type(struct mpc83xx_spi *mpc83xx_spi) \
{ \
u32 data;
This patch simply adds four eeprom nodes to MPC8548CDS' device tree.
Signed-off-by: Anton Vorontsov avoront...@ru.mvista.com
---
arch/powerpc/boot/dts/mpc8548cds.dts | 20
1 files changed, 20 insertions(+), 0 deletions(-)
diff --git a/arch/powerpc/boot/dts/mpc8548cds.dts
On Thu, Jul 09, 2009 at 12:58:53PM -0500, Kumar Gala wrote:
Hello Kumar,
I must not understand something going on here. Your proposed code
doesn't work at all on my board. The
/sys/devices/system/edac/mc/mc0/size_mb doesn't come out correctly.
What does it come out as? How much memory do
On Thu, Jul 09, 2009 at 01:25:43PM -0500, Kumar Gala wrote:
On Jul 9, 2009, at 1:17 PM, Ira W. Snyder wrote:
On Thu, Jul 09, 2009 at 12:58:53PM -0500, Kumar Gala wrote:
Hello Kumar,
I must not understand something going on here. Your proposed code
doesn't work at all on my board. The
Add support for the Freescale MPC83xx memory controller to the existing
driver for the Freescale MPC85xx memory controller. The only difference
between the two processors are in the CS_BNDS register parsing code, which
has been changed so it will work on both processors.
The L2 cache controller
Quoting Baruch Siach bar...@tkos.co.il:
Hi Mark,
On Thu, Jul 09, 2009 at 02:16:48PM -0400, Mark Bishop wrote:
I haven't seen this before - the '##' in the function name. This
is ANCII C?
Of course. See pp. 90-91 in The C Programming Language second edition.
Wow, thanks. I missed
On Thu, Jul 09, 2009 at 01:14:28PM -0500, Kumar Gala wrote:
On Jul 9, 2009, at 11:39 AM, Dale Farnsworth wrote:
We have found the following workaround to be useful.
Thanks to Andrew Jenner at Code Sourcery.
-Dale
Dale Farnsworth
MontaVista Software
diff --git
On Jul 9, 2009, at 2:35 PM, Ira W. Snyder wrote:
On Thu, Jul 09, 2009 at 01:25:43PM -0500, Kumar Gala wrote:
On Jul 9, 2009, at 1:17 PM, Ira W. Snyder wrote:
On Thu, Jul 09, 2009 at 12:58:53PM -0500, Kumar Gala wrote:
Hello Kumar,
I must not understand something going on here. Your
Hello,
I'm currently trying to implement NAPI for the FEC on the MPC5200 to
solve the well known problem, that network packet storms can cause
interrupt flooding, which may totally block the system. The NAPI
implementation, in principle, is straight forward and works
well under normal and
On Thu, Jul 9, 2009 at 2:33 PM, Wolfgang Grandeggerw...@grandegger.com wrote:
Hello,
I'm currently trying to implement NAPI for the FEC on the MPC5200 to
solve the well known problem, that network packet storms can cause
interrupt flooding, which may totally block the system.
Good to hear
Kumar Gala wrote:
On Jul 8, 2009, at 11:40 PM, Alan Modra wrote:
On Wed, Jul 08, 2009 at 10:52:59PM -0500, Kumar Gala wrote:
To further verify this if I switch the -me500 to -mspe and build things
seem to be ok. This further points at some APU section related bug.
Like omitting
Hi Mark,
On Thu, Jul 09, 2009 at 02:16:48PM -0400, Mark Bishop wrote:
I haven't seen this before - the '##' in the function name. This is ANCII C?
Of course. See pp. 90-91 in The C Programming Language second edition.
#define MPC83XX_SPI_TX_BUF(type) \
u32
phys_to_dma() and dma_to_phys() are used instead of
swiotlb_phys_to_bus() and swiotlb_bus_to_phys().
Signed-off-by: FUJITA Tomonori fujita.tomon...@lab.ntt.co.jp
---
arch/x86/kernel/pci-swiotlb.c | 10 --
1 files changed, 0 insertions(+), 10 deletions(-)
diff --git
is_buffer_dma_capable() was replaced with dma_capable().
is_buffer_dma_capable() tells if a buffer is dma-capable or
not. However, it doesn't take a pointer to struct device so it doesn't
work for POWERPC.
Signed-off-by: FUJITA Tomonori fujita.tomon...@lab.ntt.co.jp
---
phys_to_dma() and dma_to_phys() are used instead of
swiotlb_phys_to_bus() and swiotlb_bus_to_phys().
Signed-off-by: FUJITA Tomonori fujita.tomon...@lab.ntt.co.jp
---
arch/powerpc/kernel/dma-swiotlb.c | 11 ---
1 files changed, 0 insertions(+), 11 deletions(-)
diff --git
dma_capable() eventually replaces is_buffer_dma_capable(), which tells
if a memory area is dma-capable or not. The problem of
is_buffer_dma_capable() is that it doesn't take a pointer to struct
device so it doesn't work for POWERPC.
Signed-off-by: FUJITA Tomonori fujita.tomon...@lab.ntt.co.jp
---
- removes unused (and unnecessary) hooks in swiotlb.
- adds dma_capable() and converts swiotlb to use it. It can be used to
know if a memory area is dma capable or not. I added
is_buffer_dma_capable() for the same purpose long ago but it turned
out that the function doesn't work on POWERPC.
This
dma_capable() eventually replaces is_buffer_dma_capable(), which tells
if a memory area is dma-capable or not. The problem of
is_buffer_dma_capable() is that it doesn't take a pointer to struct
device so it doesn't work for POWERPC.
Signed-off-by: FUJITA Tomonori fujita.tomon...@lab.ntt.co.jp
---
dma_capable() eventually replaces is_buffer_dma_capable(), which tells
if a memory area is dma-capable or not. The problem of
is_buffer_dma_capable() is that it doesn't take a pointer to struct
device so it doesn't work for POWERPC.
Signed-off-by: FUJITA Tomonori fujita.tomon...@lab.ntt.co.jp
---
Signed-off-by: FUJITA Tomonori fujita.tomon...@lab.ntt.co.jp
---
arch/x86/kernel/pci-dma.c |2 +-
arch/x86/kernel/pci-gart_64.c |5 ++---
arch/x86/kernel/pci-nommu.c |2 +-
3 files changed, 4 insertions(+), 5 deletions(-)
diff --git a/arch/x86/kernel/pci-dma.c
Nobody uses swiotlb_alloc().
Signed-off-by: FUJITA Tomonori fujita.tomon...@lab.ntt.co.jp
---
arch/x86/kernel/pci-swiotlb.c |5 -
include/linux/swiotlb.h |2 --
lib/swiotlb.c |8 ++--
3 files changed, 2 insertions(+), 13 deletions(-)
diff --git
Nobody uses swiotlb_alloc_boot().
Signed-off-by: FUJITA Tomonori fujita.tomon...@lab.ntt.co.jp
---
arch/x86/kernel/pci-swiotlb.c |5 -
include/linux/swiotlb.h |2 --
lib/swiotlb.c |7 +--
3 files changed, 1 insertions(+), 13 deletions(-)
diff --git
swiotlb doesn't use swiotlb_arch_address_needs_mapping(); it uses
dma_capalbe(). We can remove unnecessary
swiotlb_arch_address_needs_mapping().
We can remove swiotlb_addr_needs_map() and is_buffer_dma_capable() in
swiotlb_pci_addr_needs_map() too; dma_capable() handles the features
that both
This adds two functions, phys_to_dma() and dma_to_phys() to x86, IA64
and powerpc. swiotlb uses them. phys_to_dma() converts a physical
address to a dma address. dma_to_phys() does the opposite.
Signed-off-by: FUJITA Tomonori fujita.tomon...@lab.ntt.co.jp
---
arch/ia64/include/asm/dma-mapping.h
This converts swiotlb to use dma_capable() instead of
swiotlb_arch_address_needs_mapping() and is_buffer_dma_capable().
Signed-off-by: FUJITA Tomonori fujita.tomon...@lab.ntt.co.jp
---
lib/swiotlb.c | 24 +---
1 files changed, 5 insertions(+), 19 deletions(-)
diff --git
Nobody uses swiotlb_arch_range_needs_mapping().
Signed-off-by: FUJITA Tomonori fujita.tomon...@lab.ntt.co.jp
---
arch/x86/kernel/pci-swiotlb.c |5 -
include/linux/swiotlb.h |2 --
lib/swiotlb.c | 15 ++-
3 files changed, 2 insertions(+), 20
This converts swiotlb to use phys_to_dma and dma_to_phys instead of
swiotlb_phys_to_bus() and swiotlb_bus_to_phys().
swiotlb_phys_to_bus() and swiotlb_bus_to_phys() are not necessary so
this patch also removes them.
Signed-off-by: FUJITA Tomonori fujita.tomon...@lab.ntt.co.jp
---
swiotlb_bus_to_virt is unncessary; we can use swiotlb_bus_to_phys and
phys_to_virt instead.
Signed-off-by: FUJITA Tomonori fujita.tomon...@lab.ntt.co.jp
---
arch/powerpc/kernel/dma-swiotlb.c | 10 --
lib/swiotlb.c | 34 --
2 files
I'm trying to convert POWERPC to use asm-generic/dma-mapping-common.h.
POWERPC needs addr_needs_map() in struct dma_mapping_ops for SWIOTLB
support but I want to avoid add addr_needs_map() in struct
dma_map_ops. IIRC, you guys think it as a temporary solution and
talked about defining something
On Thu, Jul 09, 2009 at 02:31:53PM -0500, Edmar Wienskoski-RA8797 wrote:
Kumar Gala wrote:
On Jul 8, 2009, at 11:40 PM, Alan Modra wrote:
On Wed, Jul 08, 2009 at 10:52:59PM -0500, Kumar Gala wrote:
To further verify this if I switch the -me500 to -mspe and build things
seem to be ok. This
On Thu, Jul 09, 2009 at 02:31:53PM -0500, Edmar Wienskoski-RA8797 wrote:
I understand your arguments, but there is something inconsistent about this.
If I change the script to be:
_end3 = . ;
. = _end3;
. = ALIGN(PAGE_SIZE);
_end = . ;
PROVIDE32 (end = .);
* FUJITA Tomonori fujita.tomon...@lab.ntt.co.jp wrote:
- removes unused (and unnecessary) hooks in swiotlb.
- adds dma_capable() and converts swiotlb to use it. It can be used to
know if a memory area is dma capable or not. I added
is_buffer_dma_capable() for the same purpose long ago but
On Fri, 10 Jul 2009 07:12:36 +0200
Ingo Molnar mi...@elte.hu wrote:
* FUJITA Tomonori fujita.tomon...@lab.ntt.co.jp wrote:
- removes unused (and unnecessary) hooks in swiotlb.
- adds dma_capable() and converts swiotlb to use it. It can be used to
know if a memory area is dma capable
On Mon, 2009-06-01 at 16:32 +0100, Ian Campbell wrote:
This series:
* removes the swiotlb_(arch_)_phys_to_bus and bus_to_phys __weak
hooks, replacing them with an architecture-specific phys_to_dma and
dma_to_phys interface. These are used by both PowerPC and Xen to
provide the correct
42 matches
Mail list logo
