Unmapping pages from the linear addressing without HIGHMEM support

Unmapping pages from the linear addressing without HIGHMEM support

[Gerhard Pircher]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset="us-ascii", Size: 1048 bytes --]

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?

Any suggestions?

Thanks!

Regards,

Gerhard

-- 
"Feel free" mit GMX FreeMail!
Monat für Monat 10 FreeSMS inklusive! http://www.gmx.net

Re: Unmapping pages from the linear addressing without HIGHMEM support

[Benjamin Herrenschmidt]

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.

Ben.

Re: Unmapping pages from the linear addressing without HIGHMEM support

[Gerhard Pircher]

> --- 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

Re: Unmapping pages from the linear addressing without HIGHMEM support

[Dan Malek]

On Mar 10, 2006, at 4:09 AM, Gerhard Pircher wrote:

> That would mean I cannot reuse the code in dma-mapping.c, right?

Sure you can.  All you need to do is turn of BAT mapping, which
is as easy as using the 'nobats' command line parameter and
all of this code should just work for you.

> ...   but I guess I have to setup my own page table for the reserved
> DMA memory area and implement my own alloc_pages() function!?

No, that's already done for you behind all of these functions.

Thanks.

	-- Dan

Re: Unmapping pages from the linear addressing without HIGHMEM support

[Benjamin Herrenschmidt]

On Fri, 2006-03-10 at 07:59 -0500, Dan Malek wrote:
> On Mar 10, 2006, at 4:09 AM, Gerhard Pircher wrote:
> 
> > That would mean I cannot reuse the code in dma-mapping.c, right?
> 
> Sure you can.  All you need to do is turn of BAT mapping, which
> is as easy as using the 'nobats' command line parameter and
> all of this code should just work for you.

And the kernel will blow up in flames under various funny circumstances
and you'll lose a fair amount of performances.

The 6xx kernel requires at least the IBAT mapping the kernel text. Some
of the exception handling code path can't deal with getting a hash fault
at critical locations (they can mostly deal with data hash misses
nowadays, but the code has to be accessible at all times).

> > ...   but I guess I have to setup my own page table for the reserved
> > DMA memory area and implement my own alloc_pages() function!?
> 
> No, that's already done for you behind all of these functions.
> 
> Thanks.
> 
> 	-- Dan
> 
> 

Re: Unmapping pages from the linear addressing without HIGHMEM support

[Benjamin Herrenschmidt]

> 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!?

No, just limit the size of the BAT mapping and mark some of the top
pages of the address space reserved... That should be enough.

Ben.

Re: Unmapping pages from the linear addressing without HIGHMEM support

[Gerhard Pircher]

> --- 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: Sat, 11 Mar 2006 10:13:30 +1100
> 
> > 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!?
> 
> No, just limit the size of the BAT mapping and mark some of the top
> pages of the address space reserved... That should be enough.
> 
Okay, I will try that first. Marking some of the pages as reserved sounds
like the code you implemented for the uninorth_agp driver with this
"agp_special_page". I guess I still have to modify the code in dma_mapping.c
to use the reserved address space for the consistent memory allocation
(CONSISTENT_BASE, CONSISTENT_END)?

Thanks again!

Gerhard

-- 
"Feel free" mit GMX FreeMail!
Monat für Monat 10 FreeSMS inklusive! http://www.gmx.net

Re: Unmapping pages from the linear addressing without HIGHMEM support

[Benjamin Herrenschmidt]

On Sat, 2006-03-11 at 14:28 +0100, Gerhard Pircher wrote:
> > --- 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: Sat, 11 Mar 2006 10:13:30 +1100
> > 
> > > 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!?
> > 
> > No, just limit the size of the BAT mapping and mark some of the top
> > pages of the address space reserved... That should be enough.
> > 
> Okay, I will try that first. Marking some of the pages as reserved sounds
> like the code you implemented for the uninorth_agp driver with this
> "agp_special_page". I guess I still have to modify the code in dma_mapping.c
> to use the reserved address space for the consistent memory allocation
> (CONSISTENT_BASE, CONSISTENT_END)?

Probably. I'm not sure about that code, I think those
CONSISTENT_BASE/END are only virtual addresses, the code still alocates
real pages below that from anywhere in memory, you may have to change
that, or maybe just 1:1 map that reserved area non-cacheable, and change
dma-mapping.c to not allocate any physical pages but just pick the one
matching the virtual ones it just allocated...;

Ben.

Re: Unmapping pages from the linear addressing without HIGHMEM support

[Gerhard Pircher]

> --- Ursprüngliche Nachricht ---
> Von: Dan Malek <dan@embeddedalley.com>
> An: "Gerhard Pircher" <gerhard_pircher@gmx.net>
> Kopie: debian-powerpc@lists.debian.org, linuxppc-dev@ozlabs.org, Benjamin
> Herrenschmidt <benh@kernel.crashing.org>
> Betreff: Re: Unmapping pages from the linear addressing without
> HIGHMEM support
> Datum: Fri, 10 Mar 2006 07:59:33 -0500
> 
> On Mar 10, 2006, at 4:09 AM, Gerhard Pircher wrote:
> 
> > That would mean I cannot reuse the code in dma-mapping.c, right?
> 
> Sure you can.  All you need to do is turn of BAT mapping, which
> is as easy as using the 'nobats' command line parameter and
> all of this code should just work for you.
Yes, that was the solution I would have used. The other solution is to
reserve a physical memory area for DMA operations that is not mapped by the
BATs (AFAIU nor by any page tables setup by the kernel). Therefore I doubt
that I can simply reuse the dma-mapping.c code for the latter approach!? Do
I mix something up here?

> > ...   but I guess I have to setup my own page table for the reserved
> > DMA memory area and implement my own alloc_pages() function!?
> 
> No, that's already done for you behind all of these functions.
But only, if the whole BAT mapping is killed, right?

Thanks!

Gerhard

-- 
"Feel free" mit GMX FreeMail!
Monat für Monat 10 FreeSMS inklusive! http://www.gmx.net