All of lore.kernel.org
 help / color / mirror / Atom feed
From: Albert Herranz <albert_herranz@yahoo.es>
To: Russell King - ARM Linux <linux@arm.linux.org.uk>
Cc: linux-usb@vger.kernel.org, linuxppc-dev@lists.ozlabs.org,
	linux-arm-kernel@lists.infradead.org
Subject: Re: [RFC PATCH v2 4/9] add generic dmabounce support
Date: Sun, 28 Feb 2010 17:37:06 +0100	[thread overview]
Message-ID: <4B8A9BB2.3080202@yahoo.es> (raw)
In-Reply-To: <20100228142046.GA16745@n2100.arm.linux.org.uk>

Russell King - ARM Linux wrote:
> On Sun, Feb 28, 2010 at 03:07:57PM +0100, Albert Herranz wrote:
>> This patch makes part of the ARM dmabounce code available to other
>> architectures as a generic API.
> 
> There is already a generic dma bounce implementation - it's called
> swiotlb - lib/swiotlb.c.  We should eventually switch the ARM
> dmabounce stuff over to that instead of keeping dmabounce around.
> 
> The only problem I forsee is that on ARM, we have devices which can
> only address the least significant N bits of RAM, but there may be
> an offset on the base address of RAM on the bus which isn't included
> in these N bits.
> 
> Even more fun is where we have a DMA controller which can address
> N bits of RAM, except for bit M which must be zero... (where N > M).
> 

In the Wii we have several limitations:
- it is a NOT_COHERENT_CACHE platform
- write accesses to coherent memory from the main processor must be done always in 32-bit chunks
- some devices can only reliably perform DMA to/from a specific region of memory (the second block of RAM, 64MB at 0x10000000, called MEM2)

So if swiotlb is the way to go I can try to adapt it to take into account these cases:
- it should allocate the io_tlb_start and io_tlb_overflow_buffer areas from MEM2 (add allocation/freeing hooks for these areas?)
- it should copy data from coherent memory in 32-bit chunks (add copy to/from coherent hooks?)
- it should decide to bounce buffers sitting in MEM1 (add a dma_needs_bounce() hook?)

Thanks,
Albert

WARNING: multiple messages have this Message-ID (diff)
From: albert_herranz@yahoo.es (Albert Herranz)
To: linux-arm-kernel@lists.infradead.org
Subject: [RFC PATCH v2 4/9] add generic dmabounce support
Date: Sun, 28 Feb 2010 17:37:06 +0100	[thread overview]
Message-ID: <4B8A9BB2.3080202@yahoo.es> (raw)
In-Reply-To: <20100228142046.GA16745@n2100.arm.linux.org.uk>

Russell King - ARM Linux wrote:
> On Sun, Feb 28, 2010 at 03:07:57PM +0100, Albert Herranz wrote:
>> This patch makes part of the ARM dmabounce code available to other
>> architectures as a generic API.
> 
> There is already a generic dma bounce implementation - it's called
> swiotlb - lib/swiotlb.c.  We should eventually switch the ARM
> dmabounce stuff over to that instead of keeping dmabounce around.
> 
> The only problem I forsee is that on ARM, we have devices which can
> only address the least significant N bits of RAM, but there may be
> an offset on the base address of RAM on the bus which isn't included
> in these N bits.
> 
> Even more fun is where we have a DMA controller which can address
> N bits of RAM, except for bit M which must be zero... (where N > M).
> 

In the Wii we have several limitations:
- it is a NOT_COHERENT_CACHE platform
- write accesses to coherent memory from the main processor must be done always in 32-bit chunks
- some devices can only reliably perform DMA to/from a specific region of memory (the second block of RAM, 64MB at 0x10000000, called MEM2)

So if swiotlb is the way to go I can try to adapt it to take into account these cases:
- it should allocate the io_tlb_start and io_tlb_overflow_buffer areas from MEM2 (add allocation/freeing hooks for these areas?)
- it should copy data from coherent memory in 32-bit chunks (add copy to/from coherent hooks?)
- it should decide to bounce buffers sitting in MEM1 (add a dma_needs_bounce() hook?)

Thanks,
Albert

  reply	other threads:[~2010-02-28 16:37 UTC|newest]

Thread overview: 42+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-02-28 14:07 [RFC PATCH v2 0/9] wii: add usb 2.0 support Albert Herranz
2010-02-28 14:07 ` Albert Herranz
2010-02-28 14:07 ` [RFC PATCH v2 1/9] powerpc: add per-device dma coherent support Albert Herranz
2010-02-28 14:07   ` Albert Herranz
2010-02-28 14:07 ` [RFC PATCH v2 2/9] wii: have generic dma coherent Albert Herranz
2010-02-28 14:07   ` Albert Herranz
2010-02-28 14:07 ` [RFC PATCH v2 3/9] dma-coherent: fix bitmap access races Albert Herranz
2010-02-28 14:07   ` Albert Herranz
2010-02-28 14:07 ` [RFC PATCH v2 4/9] add generic dmabounce support Albert Herranz
2010-02-28 14:07   ` Albert Herranz
2010-02-28 14:20   ` Russell King - ARM Linux
2010-02-28 14:20     ` Russell King - ARM Linux
2010-02-28 16:37     ` Albert Herranz [this message]
2010-02-28 16:37       ` Albert Herranz
2010-02-28 14:07 ` [RFC PATCH v2 5/9] arm: use " Albert Herranz
2010-02-28 14:07   ` Albert Herranz
2010-02-28 14:07 ` [RFC PATCH v2 6/9] powerpc: add optional per-device " Albert Herranz
2010-02-28 14:07   ` Albert Herranz
2010-02-28 14:08 ` [RFC PATCH v2 7/9] wii: add mem2 dma mapping ops Albert Herranz
2010-02-28 14:08   ` Albert Herranz
2010-02-28 14:08 ` [RFC PATCH v2 8/9] USB: add HCD_NO_COHERENT_MEM host controller driver flag Albert Herranz
2010-02-28 14:08   ` Albert Herranz
2010-03-01 14:49   ` Alan Stern
2010-03-01 14:49     ` Alan Stern
2010-03-01 18:38     ` Albert Herranz
2010-03-01 18:38       ` Albert Herranz
2010-03-01 19:23       ` Alan Stern
2010-03-01 19:23         ` Alan Stern
2010-03-01 20:11         ` Albert Herranz
2010-03-01 20:11           ` Albert Herranz
2010-03-01 20:45           ` Alan Stern
2010-03-01 20:45             ` Alan Stern
2010-03-01 22:55             ` Albert Herranz
2010-03-01 22:55               ` Albert Herranz
2010-03-02 15:50               ` Alan Stern
2010-03-02 15:50                 ` Alan Stern
2010-03-02 17:02                 ` Albert Herranz
2010-03-02 17:02                   ` Albert Herranz
2010-03-02 17:43                   ` Alan Stern
2010-03-02 17:43                     ` Alan Stern
2010-02-28 14:08 ` [RFC PATCH v2 9/9] wii: hollywood ehci controller support Albert Herranz
2010-02-28 14:08   ` Albert Herranz

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4B8A9BB2.3080202@yahoo.es \
    --to=albert_herranz@yahoo.es \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-usb@vger.kernel.org \
    --cc=linux@arm.linux.org.uk \
    --cc=linuxppc-dev@lists.ozlabs.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.