All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Jörn Engel" <joern@wohnheim.fh-wedel.de>
To: Chris Elston <chris.elston@radstone.co.uk>
Cc: linuxppc-embedded@ozlabs.org
Subject: Re: MTD Mapping driver - out of vmalloc space
Date: Fri, 15 Apr 2005 07:45:23 +0200	[thread overview]
Message-ID: <20050415054523.GC32689@wohnheim.fh-wedel.de> (raw)
In-Reply-To: <F38DEABE0E171746B133C1ABBD142D9703691B00@radmail.Radstone.Local>

On Tue, 12 April 2005 11:07:38 +0100, Chris Elston wrote:
> 
> Thanks for everyone's input on this, I've moved the kernel virtual
> base address to 0xa0000000, and it works fine now.  
> 
> I'm still not convinced that this is a future proof solution 
> though.  What happens when I get a board with 512MB Flash 1GB SDRAM?
> I can push the top of the SDRAM out to the high mem area, but I'll 
> have to encroach further into user space to map the Flash.  There's
> no good reason that the whole of the Flash need be mapped at the same
> time. (Perhaps performance?)

Definitely performance.  At the end of the day, you need a bigger
namespace of some sorts.  Possible solutions are:

o a 64bit machine,
o a 4GiB/4GiB kernel/user split and
o a PPC440 with 36bit addressing and some hardware and ioremap tricks
  to move flash above the 32bit limit.

The 4/4 split also costs some performance.  It doesn't violate the
'flash read must be atomic' requirement, though.

Jörn

-- 
...one more straw can't possibly matter...
-- Kirby Bakken

  reply	other threads:[~2005-04-15  5:45 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-04-12 10:07 MTD Mapping driver - out of vmalloc space Chris Elston
2005-04-15  5:45 ` Jörn Engel [this message]
  -- strict thread matches above, loose matches on Subject: below --
2005-04-08 14:42 Chris Elston
2005-04-08 17:51 ` Ho Lee
2005-04-08 18:39   ` Matt Porter
2005-04-08 18:39   ` Mark A. Greer
2005-04-08 18:48   ` Eugene Surovegin

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=20050415054523.GC32689@wohnheim.fh-wedel.de \
    --to=joern@wohnheim.fh-wedel.de \
    --cc=chris.elston@radstone.co.uk \
    --cc=linuxppc-embedded@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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.