Re: AmigaOne 2.6.x Linux kernel port
On Fri, 2005-12-02 at 09:46 +0100, Gerhard Pircher wrote:
> > --- Ursprüngliche Nachricht ---
> > Von: Benjamin Herrenschmidt <firstname.lastname@example.org>
> > An: Gerhard Pircher <email@example.com>
> > Kopie: linuxppc-dev list <firstname.lastname@example.org>,
> > email@example.com
> > Betreff: Re: AmigaOne 2.6.x Linux kernel port
> > Datum: Fri, 02 Dec 2005 10:58:55 +1100
> > (I'm moving this to the linuxppc-dev list)
> > Well, you need consistent alloc functions to really provide you with
> > non-cached memory. Fushing is not enough. Flushing is fine for dma_map
> > etc..., not for consistent alloc.
> > So in theory, you should be able to re-use the existing consistent
> > allocation functions, except that the current implementation has
> > "issues":
> Well, as far as I could understand the code, you need to define a start and
> end address for the consistent memory, but as all the memory is managed by
> the kernel, it's not possible to do this (I hope that I don't write nonsense
> here ;-) ).
Nah, those are virtual addresses, they are defined in .config, the
default ones might just work.
> > I understand this is probably done to keep the TLB miss handler for the
> > kernel mapping as fast as possible. Unfortunately, it's also incorrect
> > if your processor is capable of any kind of prefetching accross a 4k
> > boundary.
> Well, the processor is a normal G3/G4 desktop CPU...
I know and that's a problem.
> Okay, I think reserving memory outside of the BAT mapping, is the approach
> that is used in the arch/ppc/kernel/dma-mapping.c file. There you should
> define a consistent memory area (by it's start and end address), which is
> used for non-coherent DMA memory allocations, right? But as that isn't
> possible on the AmigaOne, we have to go the hard way.
No. This area is only used for virtual space allocation. Actual physical
pages are picked up anywhere using the page allocator.
> Well, after all the performance of the AmigaOne isn't that good (but
> acceptable) due to the ArticiaS northbridge, but I think it's more important
> to fix the real problem than doing a lot of workarounds. I'm going to study
> now the processor docs, otherwise I won't understand not even a single bit
> of the kernel code. :-)
The real problem is the northbridge being crap.