From: "Gerhard Pircher" <gerhard_pircher@gmx•net>
To: Benjamin Herrenschmidt <benh@kernel•crashing.org>
Cc: linuxppc-dev@ozlabs•org, debian-powerpc@lists•debian.org
Subject: Re: Unmapping pages from the linear addressing without HIGHMEM support
Date: Fri, 10 Mar 2006 10:09:57 +0100 (MET) [thread overview]
Message-ID: <22544.1141981797@www088.gmx.net> (raw)
In-Reply-To: 1141942301.3603.12.camel@localhost.localdomain
> --- Ursprüngliche Nachricht ---
> Von: Benjamin Herrenschmidt <benh@kernel•crashing.org>
> An: Gerhard Pircher <gerhard_pircher@gmx•net>
> Kopie: linuxppc-dev@ozlabs•org, debian-powerpc@lists•debian.org
> Betreff: Re: Unmapping pages from the linear addressing without
> HIGHMEM support
> Datum: Fri, 10 Mar 2006 09:11:41 +1100
>
> On Thu, 2006-03-09 at 14:51 +0100, Gerhard Pircher wrote:
> > Hi,
> >
> > I'm trying to implement non-coherent DMA for PPC desktop systems (like
> > the AmigaOne with G3/G4 CPU). For this I want to use the code in
> > arch/ppc/kernel/dma-mapping.c. The DMA memory allocation function
> > implemented in this file allocates pages with alloc_pages() and maps
> > them to its own linear address space, but without unmapping the
> > allocated pages from the kernel linear addressing. Due to this the
> > pages are mapped twice, which results in a conflict between the
> > different WIMG settings of the pages.
> >
> > Is there an API that can be used to unmap the allocated pages from the
> > kernel linear addressing? I thought about using kunmap() and
> > flush_all_zero_pkmaps(), but I'm not sure if this is the right approach
> > and HIGHMEM doesn't work on the AmigaOne too (the highmem base is
> > occupied by the PCI/ISA I/O space!). Wouldn't it be possible to just
> > clear the valid (V) bit of the PTE and do a TLB cache flush?
>
> The main problem is that the mappings may be covered by a BAT and thus
> pages may not be unmappable individually...
>
> What I would suggest is that your dig in the low level RAM mapping code
> and limit it at boot to RAM minus a pool of the size you want.
That would mean I cannot reuse the code in dma-mapping.c, right? Killing the
BAT mappings or limiting the memory size covered by the BATs seems to be
fairly easy, but I guess I have to setup my own page table for the reserved
DMA memory area and implement my own alloc_pages() function!?
Thanks!
Gerhard
--
Echte DSL-Flatrate dauerhaft für 0,- Euro*!
"Feel free" mit GMX DSL! http://www.gmx.net/de/go/dsl
next prev parent reply other threads:[~2006-03-10 9:09 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-03-09 13:51 Unmapping pages from the linear addressing without HIGHMEM support Gerhard Pircher
2006-03-09 22:11 ` Benjamin Herrenschmidt
2006-03-10 9:09 ` Gerhard Pircher [this message]
2006-03-10 12:59 ` Dan Malek
2006-03-10 23:12 ` Benjamin Herrenschmidt
2006-03-10 23:13 ` Benjamin Herrenschmidt
2006-03-11 13:28 ` Gerhard Pircher
2006-03-12 0:07 ` Benjamin Herrenschmidt
[not found] <31042.1141997321@www088.gmx.net>
2006-03-10 13:31 ` Gerhard Pircher
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=22544.1141981797@www088.gmx.net \
--to=gerhard_pircher@gmx$(echo .)net \
--cc=benh@kernel$(echo .)crashing.org \
--cc=debian-powerpc@lists$(echo .)debian.org \
--cc=linuxppc-dev@ozlabs$(echo .)org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
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