mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Bas Vermeulen <bvermeul@blackstar.xs4all.nl>
To: linux-os@analogic.com
Cc: linux-kernel@vger.kernel.org
Subject: Re: NOMMU - How to reserve 1 MB in top of memory in a clean way
Date: Wed, 06 Apr 2005 17:13:10 +0200	[thread overview]
Message-ID: <1112800390.2687.36.camel@laptop.blackstar.nl> (raw)
In-Reply-To: <Pine.LNX.4.61.0504061040420.22273@chaos.analogic.com>

On Wed, 2005-04-06 at 16:53, Richard B. Johnson wrote:
> On Wed, 6 Apr 2005, Catalin Marinas wrote:
> 
> > Bas Vermeulen <bvermeul@blackstar.xs4all.nl> wrote:
> >> I am currently working on the bfinnommu linux port for the BlackFin 533.
> >> I need to grab the top 1 MB of memory so I can give it out to drivers
> >> that need non-cached memory for DMA operations.
> >
> > I did this long time ago (on a 2.4 kernel), trying to avoid a hardware
> > problem. I re-ordered the zones so that ZONE_DMA came after
> > ZONE_NORMAL. Since the DMA memory was quite small (less than 1MB), I
> > also put a "break" before "case ZONE_DMA" in the
> > build_zonelists_node() functions to avoid the allocation fallback.
> >
> > -- 
> > Catalin
> >
> 
> 
> 1 Megabyte of DMA RAM should be available using conventional
> means __get_dma_pages(GFP_KERNEL, 0x100) soon after boot.

The 1 Megabyte of DMA RAM needs to be aligned on 1 MB, since I have to
tell the (software) cache manager to make it uncacheable (and that works
in blocks of 1M or 4M).
I probably could allocate 2M, get the alignment correctly, then free the
pages I don't need/want, and feed that range to the cache manager.
I'm not entirely sure I can do that before the call to free_all_bootmem,
since all pages are reserved before that.

Is there a way to do this directly (eg, just nab the pages I want/need,
and tell the zones not to use them?)

> Or just use mem= on the boot command line. This will tell
> the kernel the extent of memory to use. Any RAM after that
> is available. Your driver can access kernel variable, "num_physpages"
> to find the last page it is supposed to use. Some kernel versions
> actually touch the next page so, to be safe, your code can
> use:
>     mem = (num_physpages * PAGE_SIZE) + PAGE_SIZE;
> ... for the first available free RAM.

That's my backup plan, but I'd prefer to do it properly in kernel memory
space (if at all possible).

> Note that there may be PCI BARS allocated in this address-space if
> you have 4 Gb of RAM. You need to be carefull.

BlackFin doesn't have PCI (and no MMU, so a more limited address space
than 4 GB).

Thanks for the insight so far,

Bas Vermeulen


  parent reply	other threads:[~2005-04-06 15:13 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-04-06  9:50 Bas Vermeulen
2005-04-06 13:26 ` Catalin Marinas
2005-04-06 14:53   ` Richard B. Johnson
2005-04-06 15:05     ` Catalin Marinas
2005-04-06 15:13     ` Bas Vermeulen [this message]
2005-04-06 15:16   ` Bas Vermeulen
2005-04-06 15:56     ` Catalin Marinas

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=1112800390.2687.36.camel@laptop.blackstar.nl \
    --to=bvermeul@blackstar.xs4all.nl \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-os@analogic.com \
    /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

all inboxes | Powered by JetHome®