From: Scott Wood <scottwood@freescale.com>
To: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Cc: Xie Shaohui-B21989 <B21989@freescale.com>,
Zang Roy-R61911 <r61911@freescale.com>,
Timur Tabi <timur@tabi.org>,
"tiejun.chen" <tiejun.chen@windriver.com>,
Fleming Andy-AFLEMING <afleming@freescale.com>,
Bhushan Bharat-R65777 <R65777@freescale.com>,
"linuxppc-dev@lists.ozlabs.org" <linuxppc-dev@lists.ozlabs.org>
Subject: Re: FSL 64-bit DMA window question
Date: Fri, 7 Jun 2013 18:29:31 -0500 [thread overview]
Message-ID: <1370647771.6813.19@snotra> (raw)
In-Reply-To: <1370644793.3766.423.camel@pasglop> (from benh@kernel.crashing.org on Fri Jun 7 17:39:53 2013)
On 06/07/2013 05:39:53 PM, Benjamin Herrenschmidt wrote:
> On Fri, 2013-06-07 at 17:34 -0500, Scott Wood wrote:
> > > You also need to account for other on-chip MMIOs no ? Or do you =20
> never
> > > intend to let PCI devices hit them ?
> >
> > I don't think we normally need that (other than MSIs, which have a
> > special window under 4G)... The question is whether it's better to =20
> let
> > odd use cases work without having to manually move the DMA window, =20
> at
> > the cost of decreased out-of-the-box performance with common PCIe =20
> cards.
>=20
> Sorry, I didn't parse what the tradeoff is here...
I just meant that a PCIe device targeting something other than RAM, =20
CCSR (it's not just MSIs that are mapped through the special window), =20
or another PCIe is a rather unusual case -- not something that you'd =20
see by just plugging in an ordinary PCIe card. The tradeoff is that if =20
we accommodate this strange use case, boards like the radeon would need =20
to use swiotlb (once we fix the > versus >=3D bug) unless the user tweaks =20
the DMA window.
It may be best to stick with the default that makes everything work, =20
even if a broken PCIe card ends up being a bit slower out of the box, =20
even if the PCIe-to-MMIO use case is weird and would require custom =20
setup anyway. OTOH, did we ever care about 32-bit DMA being able to =20
access MMIO?
> Putting the inbound window above memory seems like a reasonable =20
> option then
> (at least as a default that the board can override).
>=20
> I sincerely hope those radeons are the only remaining things with =20
> that sort of
> limitation but you never know ... it's all x86 fault of course for =20
> never having
> used high DMA windows :-)
Hmm... Why are we using this special window at all? Can't we just have =20
one large identity mapping starting at zero, with the MSI window =20
presumably taking precedence? The manual is a bit vague on whether =20
inbound windows can overlap with priority... in EP mode it says it =20
does, and the RC section is silent. Do we currently ever overlap =20
PCICSRBAR with a real window?
-Scott=
next prev parent reply other threads:[~2013-06-07 23:29 UTC|newest]
Thread overview: 78+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-05-16 4:47 SATA FSL and upstreaming Benjamin Herrenschmidt
2013-05-16 5:45 ` Benjamin Herrenschmidt
2013-05-16 5:55 ` tiejun.chen
2013-05-16 6:06 ` Benjamin Herrenschmidt
2013-05-16 5:59 ` Zang Roy-R61911
2013-05-16 6:01 ` Bhushan Bharat-R65777
2013-05-16 6:05 ` Zang Roy-R61911
2013-05-16 6:09 ` Benjamin Herrenschmidt
2013-05-16 6:17 ` tiejun.chen
2013-05-16 6:20 ` Zang Roy-R61911
2013-05-16 6:25 ` tiejun.chen
2013-05-16 7:20 ` Zang Roy-R61911
2013-05-16 6:26 ` Benjamin Herrenschmidt
2013-05-16 6:21 ` Benjamin Herrenschmidt
2013-05-16 6:35 ` tiejun.chen
2013-05-16 6:37 ` Zang Roy-R61911
2013-05-16 6:40 ` Benjamin Herrenschmidt
2013-05-16 6:43 ` tiejun.chen
2013-05-16 6:48 ` Bhushan Bharat-R65777
2013-05-16 6:49 ` Zang Roy-R61911
2013-05-16 6:53 ` Benjamin Herrenschmidt
2013-05-16 6:56 ` tiejun.chen
2013-05-16 7:01 ` Zang Roy-R61911
2013-05-16 7:05 ` Benjamin Herrenschmidt
2013-05-16 7:13 ` Bhushan Bharat-R65777
2013-05-16 7:26 ` Benjamin Herrenschmidt
2013-05-16 7:20 ` Xie Shaohui-B21989
2013-05-16 7:25 ` Bhushan Bharat-R65777
2013-05-16 6:59 ` Benjamin Herrenschmidt
2013-05-16 7:17 ` Zang Roy-R61911
2013-05-16 6:52 ` Benjamin Herrenschmidt
2013-05-16 14:56 ` Timur Tabi
2013-06-07 3:52 ` Benjamin Herrenschmidt
2013-06-07 4:39 ` Benjamin Herrenschmidt
2013-06-07 4:45 ` Zang Roy-R61911
2013-06-07 4:47 ` Benjamin Herrenschmidt
2013-06-07 4:50 ` Zang Roy-R61911
2013-06-07 7:41 ` fsqrt Benjamin Herrenschmidt
2013-06-07 7:45 ` fsqrt Zang Roy-R61911
2013-06-07 8:53 ` fsqrt Benjamin Herrenschmidt
2013-06-07 8:59 ` fsqrt Benjamin Herrenschmidt
2013-06-07 10:48 ` fsqrt David Laight
2013-06-07 12:14 ` fsqrt Benjamin Herrenschmidt
2013-06-07 19:19 ` fsqrt Kumar Gala
2013-06-07 23:23 ` fsqrt Benjamin Herrenschmidt
2013-06-07 23:25 ` fsqrt Benjamin Herrenschmidt
2013-06-07 23:30 ` fsqrt Benjamin Herrenschmidt
2013-06-08 0:20 ` fsqrt Dan Malek
2013-06-08 0:34 ` fsqrt Benjamin Herrenschmidt
2013-06-08 1:13 ` fsqrt Dan Malek
2013-06-08 4:31 ` fsqrt Benjamin Herrenschmidt
2013-06-09 6:32 ` fsqrt Benjamin Herrenschmidt
2013-06-07 7:46 ` fsqrt tiejun.chen
2013-06-07 8:53 ` fsqrt Benjamin Herrenschmidt
2013-06-07 9:02 ` fsqrt tiejun.chen
2013-06-07 12:07 ` fsqrt Benjamin Herrenschmidt
2013-06-07 7:05 ` FSL 64-bit DMA window question Benjamin Herrenschmidt
2013-06-07 7:58 ` Zang Roy-R61911
2013-06-07 8:55 ` Benjamin Herrenschmidt
2013-06-07 9:44 ` Zang Roy-R61911
2013-06-07 12:09 ` Benjamin Herrenschmidt
[not found] ` <1370642488.6813.15@snotra>
2013-06-07 22:02 ` Scott Wood
2013-06-07 22:09 ` Benjamin Herrenschmidt
2013-06-07 22:34 ` Scott Wood
2013-06-07 22:39 ` Benjamin Herrenschmidt
2013-06-07 23:29 ` Scott Wood [this message]
2013-06-07 23:33 ` Benjamin Herrenschmidt
2013-06-07 12:09 ` SATA FSL and upstreaming Timur Tabi
2013-05-16 6:17 ` Zang Roy-R61911
2013-05-16 6:23 ` Benjamin Herrenschmidt
2013-05-16 6:33 ` Bhushan Bharat-R65777
2013-05-16 6:34 ` Benjamin Herrenschmidt
2013-05-16 6:35 ` Zang Roy-R61911
2013-05-16 6:37 ` Benjamin Herrenschmidt
2013-05-16 6:41 ` tiejun.chen
2013-05-16 6:48 ` Zang Roy-R61911
2013-05-16 6:24 ` Xie Shaohui-B21989
2013-05-16 6:31 ` Benjamin Herrenschmidt
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=1370647771.6813.19@snotra \
--to=scottwood@freescale.com \
--cc=B21989@freescale.com \
--cc=R65777@freescale.com \
--cc=afleming@freescale.com \
--cc=benh@kernel.crashing.org \
--cc=linuxppc-dev@lists.ozlabs.org \
--cc=r61911@freescale.com \
--cc=tiejun.chen@windriver.com \
--cc=timur@tabi.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.