linuxppc-dev.lists.ozlabs.org archive mirror
 help / color / mirror / Atom feed
From: Benjamin Herrenschmidt <benh@kernel.crashing.org>
To: Gerhard Pircher <gerhard_pircher@gmx.net>
Cc: linuxppc-dev@ozlabs.org, debian-powerpc@lists.debian.org
Subject: Re: AmigaOne 2.6.x Linux kernel port
Date: Sat, 03 Dec 2005 08:56:30 +1100	[thread overview]
Message-ID: <1133560590.6100.75.camel@gaston> (raw)
In-Reply-To: <4885.1133513163@www38.gmx.net>

On Fri, 2005-12-02 at 09:46 +0100, Gerhard Pircher wrote:
> > --- Ursprüngliche Nachricht ---
> > Von: Benjamin Herrenschmidt <benh@kernel.crashing.org>
> > An: Gerhard Pircher <gerhard_pircher@gmx.net>
> > Kopie: linuxppc-dev list <linuxppc-dev@ozlabs.org>,
> > debian-powerpc@lists.debian.org
> > 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.

Ben.

      reply	other threads:[~2005-12-02 22:03 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <1133403468.5248.28.camel@gaston>
     [not found] ` <21714.1133476127@www44.gmx.net>
2005-12-01 23:58   ` AmigaOne 2.6.x Linux kernel port Benjamin Herrenschmidt
2005-12-02  8:46     ` Gerhard Pircher
2005-12-02 21:56       ` Benjamin Herrenschmidt [this message]

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=1133560590.6100.75.camel@gaston \
    --to=benh@kernel.crashing.org \
    --cc=debian-powerpc@lists.debian.org \
    --cc=gerhard_pircher@gmx.net \
    --cc=linuxppc-dev@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).