Re: [PATCH 5/6] swiotlb: Make swiotlb bookkeeping functions visible in the header file.

[Albert Herranz <albert_herranz@yahoo.es>]

Hi,

On 05/18/2010 05:28 AM, FUJITA Tomonori wrote:
>> The whole series work fine on the Wii 32-bit PowerPC platform (used to implement the MEM2 DMA facility needed by its EHCI controller).
>>
>> Tested-by: Albert Herranz <albert_herranz@yahoo.es>
> 
> I know that you decrease the swiotlb size from 64MB (default) to 1MB,
> however, pre-allocating 1MB is too wasteful to Wii?
> 

Every single KB counts on the Wii. It has just 24MB of MEM1 and 64MB of MEM2 (discontiguous memory ranges).
I'm using 1MB for the SWIOTLB for now, but of course that can be further tweaked down.

> Wii's EHCI controller connects to storage devices? If not, what you
> need is the facility to do bouncing with dynamically allocated memory
> such as the network stack, the block layer and
> arm/arm/common/dmabounce.c
> 

The two external USB ports in the Wii are part of an embedded EHCI controller (with its two OHCI companion controllers). You can connect whatever USB device you want to them.

I posted (in the past) a patch series [1] in which I made the dmabounce code in the ARM architecture tree available to other architectures, and used that to implement the needed bouncing infrastructure.
But I was told then by Russell to use swiotlb instead [2].

Either if dmabounce or swiotlb is used, what's needed in the end is a way to allocate coherent buffers from a specific part of memory (MEM2) and to bounce buffers to/from MEM2 as needed.
This is currently solved by using struct dma_map_ops + swiotlb as a bounce buffer implementation, placing the swiotlb area in MEM2.
Coherent memory is allocated from a dedicated pool of MEM2 (currently using the generic per-device dma coherent allocator).

Cheers,
Albert

[1] http://marc.info/?l=linux-usb&m=126736610418835
[2] http://marc.info/?l=linux-usb&m=126736687519788