All of lore.kernel.org
 help / color / mirror / Atom feed
From: Gary Thomas <gary@mlbassoc.com>
To: ppc339@vtnet.ca
Cc: linuxppc-dev@lists.linuxppc.org
Subject: Re: address translation
Date: 15 May 2003 05:46:20 -0600	[thread overview]
Message-ID: <1052999180.1568.129.camel@hermes> (raw)
In-Reply-To: <200305150729.36436.ppc339@vtnet.ca>


On Thu, 2003-05-15 at 05:29, Trevor Woerner wrote:
> I want to setup a mapping so that when anything tries to read/write the
> 16 bytes at 0x1f0 - 0x1ff the actual physical memory that gets accessed
> is 0xf7000000 - 0xf700000f.
>
> I can't figure out what I need to call to get this done.
>
> ioremap() is the exact opposite of what I want.
>
> remap_page_range() comes very close but aligns everything to the page
> boundary. In other words, after I do the mapping with either 0x1f0 or
> 0x0 as the virtual address, accessing 0x1f0 gives me 0xf70001f0 instead
> of 0xf7000000. I don't want *page* translation, I need
> *address-for-address* translation (if such a thing is possible). I
> tried setting the physical address to 0xf7000000 - 0x1f0 but that
> didn't work (I didn't think it would :-)
>
> I think resetting _IO_BASE is just another page translation trick.
>
> I also tried using io_block_mapping(), which I use in my platform io
> setup routine, but the MMU crashed with one of those '###A' reports.
>

The memory management on the PowerPC does not have this capability.

I'd suggest rethinking how you are looking at this problem.
  * What is it that wants access to this specific range of physical
    memory in such a way?
Perhaps a specialized device driver would be a better choice.

--
Gary Thomas <gary@mlbassoc.com>
MLB Associates


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

  reply	other threads:[~2003-05-15 11:46 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2003-05-15 11:29 address translation Trevor Woerner
2003-05-15 11:46 ` Gary Thomas [this message]
2003-05-16  3:13   ` Trevor Woerner
2003-05-15 12:13 ` Magnus Damm
2003-05-16  3:14   ` Trevor Woerner
2003-05-15 14:05 ` Benjamin Herrenschmidt
2003-05-16  4:02   ` Trevor Woerner
2003-05-16  8:35     ` Geert Uytterhoeven
2003-05-16  9:00     ` Benjamin Herrenschmidt
  -- strict thread matches above, loose matches on Subject: below --
2005-04-12 10:47 mani kandan
2005-04-12 12:25 ` Henrik Nordstrom
2003-05-15  3:50 Trevor Woerner
2000-11-22 21:39 Address translation Keir Fraser
2000-11-23  0:49 ` Pavel Machek
2000-11-23 20:23 ` Andreas Bombe
2000-11-23 21:04   ` Bjorn Wesen
2000-11-24 23:28     ` Andreas Bombe
2000-11-21 14:41 Rubén Gallardo Fructuoso
2000-11-21 17:20 ` Jeff Dike

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=1052999180.1568.129.camel@hermes \
    --to=gary@mlbassoc.com \
    --cc=linuxppc-dev@lists.linuxppc.org \
    --cc=ppc339@vtnet.ca \
    /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.