Re: [PATCH 5/6] swiotlb: Make swiotlb bookkeeping functionsvisible in the header file.
From: FUJITA Tomonori
Date: Tue May 18 2010 - 23:35:26 EST
On Tue, 18 May 2010 18:52:17 +0200
Albert Herranz <albert_herranz@xxxxxxxx> wrote:
> 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@xxxxxxxx>
> >
> > 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.
You can decrease the swiotlb memory however you can't fix the root
problems of swiotlb:
- it needs pre-allocated memory
- it can't handle the out-of-pre-allocated memory situation.
> > 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 mean that Wii doesn't boot on the root device on the USB controller,
right?
> 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].
I think that we need to modify swiotlb for embedded archs. Otherwise,
I don't think that swiotlb can replace arm's dmabounce.
Ok, I'll implement something like that.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/