linuxppc-dev.lists.ozlabs.org archive mirror
 help / color / mirror / Atom feed
From: Benjamin Herrenschmidt <benh@kernel.crashing.org>
To: michael@ellerman.id.au
Cc: Olof Johansson <olof@lixom.net>,
	linuxppc-dev@ozlabs.org, cbe-oss-dev@ozlabs.org
Subject: Re: [PATCH 8/8] Cell IOMMU fixed mapping support
Date: Wed, 30 Jan 2008 08:18:15 +1100	[thread overview]
Message-ID: <1201641495.6815.207.camel@pasglop> (raw)
In-Reply-To: <1201619625.10012.19.camel@concordia>


On Wed, 2008-01-30 at 02:13 +1100, Michael Ellerman wrote:
> On Tue, 2008-01-29 at 09:15 -0600, Olof Johansson wrote:
> > On Wed, Jan 30, 2008 at 01:14:03AM +1100, Michael Ellerman wrote:
> > 
> > > For example a machine with 4GB of memory would end up with the normal
> > > IOMMU window from 0-2GB and the fixed mapping window from 2GB to 6GB. In
> > > this case a 64-bit device wishing to DMA to 1GB would be told to DMA to
> > > 3GB, plus any offset required by firmware. The firmware offset is encoded
> > > in the "dma-ranges" property.
> > 
> > Shouldn't the fixed mapping be between 4G and 8G (and the offset for 1G
> > is at 5G), to account for the MMIO range at 2-4G?
> 
> I don't think so, ie. it works setup like that, but I'm not entirely
> sure why. Presumably the 2-4GB for MMIO is only for cycles heading out
> of the CPU.

No no no... it's because on the PCI segment, it's all offset up
remember ?

Basically, the PCI host bridge on these has 2 interesting windows for
us:

0....2G			-> This goes up to memory @0 (via a couple of 
                           layers)

0x80*....0xF*		-> This goes untranslated to the PLB5 which
  			   drops the top bits and does some other 
                           manipulations, which allows to access, among
                           others the full 32GB of the cell inbound 
                           range.

The MMIO region of 2...4G is on the PCI (outbound from the Cell is yet
another range of addresses with different constraints but that ends up
generating cycles between 2 and 4G on the PCI segment).

If we had set the direct mapped region so that it uses 2G...N on PCI, we
would indeed be toast. But instead, the addresses for direct DMA that we
hand out to devices are in the 0x80* region and go hit the cell
directly, they never match MMIO.

 Ben.
 

  parent reply	other threads:[~2008-01-29 21:18 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-01-29 14:13 [PATCH 1/8] Add set_dma_ops() to match get_dma_ops() Michael Ellerman
2008-01-29 14:13 ` [PATCH 3/8] Split out the logic that allocates struct iommus Michael Ellerman
2008-02-05  0:23   ` Benjamin Herrenschmidt
2008-01-29 14:13 ` [PATCH 2/8] Allocate the hash table under 1G on cell Michael Ellerman
2008-01-29 14:14 ` [PATCH 4/8] Split cell_iommu_setup_hardware() into two parts Michael Ellerman
2008-01-29 14:14 ` [PATCH 6/8] Add support to cell_iommu_setup_page_tables() for multiple windows Michael Ellerman
2008-02-05  0:26   ` Benjamin Herrenschmidt
2008-01-29 14:14 ` [PATCH 5/8] Split out the IOMMU logic from cell_dma_dev_setup() Michael Ellerman
2008-02-05  0:26   ` Benjamin Herrenschmidt
2008-01-29 14:14 ` [PATCH 7/8] Split out the ioid fetching/checking logic Michael Ellerman
2008-02-05  0:27   ` Benjamin Herrenschmidt
2008-01-29 14:14 ` [PATCH 8/8] Cell IOMMU fixed mapping support Michael Ellerman
2008-01-29 15:15   ` Olof Johansson
2008-01-29 15:13     ` Michael Ellerman
2008-01-29 15:50       ` Olof Johansson
2008-01-30  0:54         ` Arnd Bergmann
2008-01-30  0:58           ` Olof Johansson
2008-01-29 21:18       ` Benjamin Herrenschmidt [this message]
2008-01-29 21:36         ` Olof Johansson
2008-01-29 23:56           ` Michael Ellerman
2008-01-30  0:03   ` Michael Ellerman

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=1201641495.6815.207.camel@pasglop \
    --to=benh@kernel.crashing.org \
    --cc=cbe-oss-dev@ozlabs.org \
    --cc=linuxppc-dev@ozlabs.org \
    --cc=michael@ellerman.id.au \
    --cc=olof@lixom.net \
    /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).