From: James Bottomley <James.Bottomley@SteelEye.com>
To: "David S. Miller" <davem@redhat.com>
Cc: linux-arch@vger.kernel.org
Subject: Re: Accessing memory remote across the bus in the same way as local memory
Date: 18 Jun 2004 18:43:31 -0500 [thread overview]
Message-ID: <1087602212.2078.218.camel@mulgrave> (raw)
In-Reply-To: <20040618163243.26d9fcb3.davem@redhat.com>
On Fri, 2004-06-18 at 18:32, David S. Miller wrote:
> There are three issues:
Oh, yes, I know this isn't easy, it would be an absolute pig on parisc
too because we use absloute instruction accesses currently to MMIO
space...if we start remapping pieces we end up with cache aliasing
issues.
But what I'm more concerned about is is there a basic show stopper that
would prevent a platform from doing this?
> 1) How to form the physical address (for a PCI device we have PCI device
> pointer and resource, stuff like that, we just need a translator
> interface or similar to pass that info in)
That's really something the DMA API does well today. I think as part of
the implementation, we'd just have the device register the area and its
own internal address for it.
> 2) Whether such accesses are legal. On Sparc64 one device cannot DMA
> to/from the MMIO of a device behind a _DIFFERENT_ PCI controller.
Yes, this one could be tricky: no using the memory you obtained for DMA
to or from anything other than this one device.
> 3) Some logic to get page table non-cacheable bits set etc. since this
> is to non-memory space.
This would be up to the platform piece of the API to sort out, I think.
I'm not anywhere close to proposing this, I'm just exploring the
possibility at the moment. I'm still arguing "no" in the DMA API
thread...
James
next prev parent reply other threads:[~2004-06-18 23:43 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-06-18 23:26 Accessing memory remote across the bus in the same way as local memory James Bottomley
2004-06-18 23:32 ` David S. Miller
2004-06-18 23:43 ` James Bottomley [this message]
2004-06-19 4:05 ` Paul Mackerras
2004-06-19 14:02 ` James Bottomley
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=1087602212.2078.218.camel@mulgrave \
--to=james.bottomley@steeleye.com \
--cc=davem@redhat.com \
--cc=linux-arch@vger.kernel.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