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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Tue, 18 May 2010 18:52:17 +0200
From:	Albert Herranz <albert_herranz@...oo.es>
To:	FUJITA Tomonori <fujita.tomonori@....ntt.co.jp>
CC:	konrad.wilk@...cle.com, Ian.Campbell@...citrix.com,
	jeremy@...p.org, linux-kernel@...r.kernel.org, chrisw@...s-sol.org,
	iommu@...ts.linux-foundation.org, dwmw2@...radead.org,
	linux@....linux.org.uk
Subject: Re: [PATCH 5/6] swiotlb: Make swiotlb bookkeeping functions visible
 in the header file.

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@...oo.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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/