All of lore.kernel.org
 help / color / mirror / Atom feed
From: Felix Radensky <felix@allot.com>
To: Matt Porter <mporter@kernel.crashing.org>
Cc: linuxppc-embedded@ozlabs.org
Subject: Re: 405GPr ioremap problem
Date: Wed, 10 Nov 2004 20:37:16 +0200	[thread overview]
Message-ID: <41925FDC.1060308@allot.com> (raw)
In-Reply-To: <20041109111707.A14471@home.com>

[-- Attachment #1: Type: text/plain, Size: 1794 bytes --]

Hi, Matt

Thanks a lot for replying, your help is very much
appreciated. I've followed your suggestion and now
ioremap works as expected. I've removed ivocation
of m4xx_map_io() replacing it by normal ioremaps
for serial ports, RTC and ethernet adapter.

It would be great to see this stuff cleaned up in 2.6.

Felix.


Matt Porter wrote:

>On Tue, Nov 09, 2004 at 07:27:09PM +0200, Felix Radensky wrote:
>  
>
>>Hi, folks
>>
>>I have a 405GPr based board with 512M of RAM.
>>My kernel is 2.4.17 from Monta Vista Linux 2.1.
>>I'm  trying to reserve 64M on boot using mem=448M
>>and map it later by
>>
>>ioremap(__pa(high_memory), 64*(1<<20));
>>
>>This worked fine when system had 256M of RAM,
>>but now ioremap fails. If I understand the kernel
>>code correctly, by adding more RAM I've reduced
>>the vmalloc/ioremap space. I can also see that this
>>space is reduced dramatically on boot by mappings
>>done in arch/ppc/kernel/ppc4xx_setup.c:m4xx_map_io()
>>
>>Is there any way to fix problem ? Is it necessary to have
>>a 1:1 virtual to physical mappings as its done in m4xx_map_io()
>>or maybe higher virtual addresses can be used, thus
>>allowing to save some precious ioremap space.
>>    
>>
>
>This is exactly why the PPC44x ports don't use io_block_map()...
>it can interfere with dynamic mappings.  It is not necessary to
>have 1:1 virtual to physical mappings nor is it necessary to
>have m4xx_map_io() at all. One can use ioremap() to map any
>space and let the kernel place things intelligently. In order
>to use serial console you'll have to use early_serial_setup()
>after you've ioremapped the UART...once you've removed the
>io_block_map() call. Look at other ports to see how this is
>done.
>
>Someday I might get down my list to cleaning up 40x stuff in 2.6.
>
>-Matt
>
>  
>

[-- Attachment #2: Type: text/html, Size: 2214 bytes --]

      reply	other threads:[~2004-11-10 20:24 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2004-11-09 17:27 405GPr ioremap problem Felix Radensky
2004-11-09 18:17 ` Matt Porter
2004-11-10 18:37   ` Felix Radensky [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=41925FDC.1060308@allot.com \
    --to=felix@allot.com \
    --cc=linuxppc-embedded@ozlabs.org \
    --cc=mporter@kernel.crashing.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.