linuxppc-dev.lists.ozlabs.org archive mirror
 help / color / mirror / Atom feed
From: Adrian Cox <adrian@humboldt.co.uk>
To: Dan Malek <dan@embeddededge.com>
Cc: linuxppc-dev@lists.linuxppc.org
Subject: Re: [PATCH] Allow small areas in io_block_mapping
Date: Fri, 16 Nov 2001 16:39:51 +0000	[thread overview]
Message-ID: <3BF54157.6070605@humboldt.co.uk> (raw)
In-Reply-To: 3BF53B55.90900@embeddededge.com


Dan Malek wrote:


> Hmmmm....Is io_block_mapping() supposed to be a replacement for ioremap()?
> If so, it doesn't do anything I want.  What you are asking for is already
> done by ioremap.  If someone has already wired BATs, you get them, and
> if not then single PTEs will be allocated.  In this case, just don't
> allocate
> BATs for I/O in the space you want individual pages when you do the board
> initialization, and call ioremap().


I hadn't realised that ioremap could be used before vmalloc was working,
but on examining the code, it looks like it can. So I may just change my
code to use ioremap.

In defense of the patch I would like to say that the extra test is in
the spirit of the existing tests within io_block_mapping(), and if this
doesn't go in then a comment describing the intention and limits of the
interface would be a useful addition to <include/asm-ppc/io.h>.


> I think we still need to define a better set of functions here.  I want to:
>
>     1.) Control the virt->phys mapping when necessary by forcing both
>         virtual and physical addresses (kind like io_block_mapping now)
>
>     2.) Cover a very large space with a single BAT or large page entry
>
>     3.) Have an ioremap()-like function that will use the physical address
>         to either match in 1 or 2 above, or allocate single PTEs if
>         no match.
>
> The functions used to set up 1 and 2 above are performed very early during
> memory management initialization and are not subject to change once we
> start using these mapped spaces.


That's pretty well what I need here.

--
Adrian Cox   http://www.humboldt.co.uk/


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

  reply	other threads:[~2001-11-16 16:39 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2001-11-16 15:21 [PATCH] Allow small areas in io_block_mapping Adrian Cox
2001-11-16 16:14 ` Dan Malek
2001-11-16 16:39   ` Adrian Cox [this message]
2001-11-16 16:57     ` Dan Malek

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=3BF54157.6070605@humboldt.co.uk \
    --to=adrian@humboldt.co.uk \
    --cc=dan@embeddededge.com \
    --cc=linuxppc-dev@lists.linuxppc.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).