From: Arnd Bergmann <arnd@arndb.de>
To: linux-arm-kernel@lists.infradead.org
Cc: Phil.Edworthy@renesas.com, Simon Horman <horms@verge.net.au>,
linux-sh@vger.kernel.org, linux-pci@vger.kernel.org,
Magnus Damm <magnus.damm@gmail.com>,
Valentine Barshak <valentine.barshak@cogentembedded.com>,
Ben Dooks <ben.dooks@codethink.co.uk>,
Bjorn Helgaas <bhelgaas@google.com>
Subject: Re: [PATCH v5 6/9] ARM: shmobile: Add PCIe device tree nodes for R8A7790
Date: Wed, 26 Mar 2014 11:34:18 +0100 [thread overview]
Message-ID: <5768554.vihmtytclA@wuerfel> (raw)
In-Reply-To: <OF61E4A09E.4D57F668-ON80257CA7.0035A569-80257CA7.00367A70@eu.necel.com>
On Wednesday 26 March 2014 09:55:04 Phil.Edworthy@renesas.com wrote:
> Hi Arnd,
>
> On: 25/03/2014 18:42, Arnd wrote:
> > Subject: Re: [PATCH v5 6/9] ARM: shmobile: Add PCIe device tree nodes
> for R8A7790
> >
> > On Tuesday 25 March 2014 16:56:41 Phil Edworthy wrote:
> > > + /* Map all possible DDR as inbound ranges */
> > > + dma-ranges = <0x42000000 0 0x40000000 0 0x40000000 0
> 0x80000000
> > > + 0x43000000 1 0x80000000 1 0x80000000 0
> 0x80000000>;
> >
> > Typo: 0x43000000 should be 0x42000000 I guess.
> I used 0x43000000 as this is a 64-bit type. The OF PCI range code
> currently treats both 32 and 64-bit types the same way, but I thought it
> would be good to set this in case we ever need to use it.
Ah, I forgot about the space identifier. It looks correct then, but
it seems a little strange to use a 32-bit identifier in one case
and a 64-bit one in the other.
> > Since you control the mapping, I wonder if you could also do this as
> >
> > dma-ranges = <0x42000000 0 0x00000000 0 0x40000000 0
> 0x80000000
> > 0x43000000 0 0x80000000 1 0x80000000 0
> 0x80000000>;
> >
> > i.e. map all the RAM into PCI bus addresses below the 32-bit boundary.
> > This would be really nice from the perspective that now all PCI
> > devices could access all of RAM without using an IOMMU or the
> > relying on 64-bit master capability.
> >
> > The downside of this is that you'd probably need a custom dma_map_ops
> > wrapper.
> Since the OF PCi range code treats both 32 and 64-bit types the same way,
> my PCIe driver only creates 64-bit mappings. In addition, the PCIe
> controller has to use a 64-bit mapping for anything over 2GiB. Based on
> this, I think it's sensible to leave the mappings as 1-to-1.
I'm not following, sorry. What is the hardware requirement in the
controller?
Arnd
WARNING: multiple messages have this Message-ID (diff)
From: Arnd Bergmann <arnd@arndb.de>
To: linux-arm-kernel@lists.infradead.org
Subject: Re: [PATCH v5 6/9] ARM: shmobile: Add PCIe device tree nodes for R8A7790
Date: Wed, 26 Mar 2014 10:34:18 +0000 [thread overview]
Message-ID: <5768554.vihmtytclA@wuerfel> (raw)
In-Reply-To: <OF61E4A09E.4D57F668-ON80257CA7.0035A569-80257CA7.00367A70@eu.necel.com>
On Wednesday 26 March 2014 09:55:04 Phil.Edworthy@renesas.com wrote:
> Hi Arnd,
>
> On: 25/03/2014 18:42, Arnd wrote:
> > Subject: Re: [PATCH v5 6/9] ARM: shmobile: Add PCIe device tree nodes
> for R8A7790
> >
> > On Tuesday 25 March 2014 16:56:41 Phil Edworthy wrote:
> > > + /* Map all possible DDR as inbound ranges */
> > > + dma-ranges = <0x42000000 0 0x40000000 0 0x40000000 0
> 0x80000000
> > > + 0x43000000 1 0x80000000 1 0x80000000 0
> 0x80000000>;
> >
> > Typo: 0x43000000 should be 0x42000000 I guess.
> I used 0x43000000 as this is a 64-bit type. The OF PCI range code
> currently treats both 32 and 64-bit types the same way, but I thought it
> would be good to set this in case we ever need to use it.
Ah, I forgot about the space identifier. It looks correct then, but
it seems a little strange to use a 32-bit identifier in one case
and a 64-bit one in the other.
> > Since you control the mapping, I wonder if you could also do this as
> >
> > dma-ranges = <0x42000000 0 0x00000000 0 0x40000000 0
> 0x80000000
> > 0x43000000 0 0x80000000 1 0x80000000 0
> 0x80000000>;
> >
> > i.e. map all the RAM into PCI bus addresses below the 32-bit boundary.
> > This would be really nice from the perspective that now all PCI
> > devices could access all of RAM without using an IOMMU or the
> > relying on 64-bit master capability.
> >
> > The downside of this is that you'd probably need a custom dma_map_ops
> > wrapper.
> Since the OF PCi range code treats both 32 and 64-bit types the same way,
> my PCIe driver only creates 64-bit mappings. In addition, the PCIe
> controller has to use a 64-bit mapping for anything over 2GiB. Based on
> this, I think it's sensible to leave the mappings as 1-to-1.
I'm not following, sorry. What is the hardware requirement in the
controller?
Arnd
WARNING: multiple messages have this Message-ID (diff)
From: arnd@arndb.de (Arnd Bergmann)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH v5 6/9] ARM: shmobile: Add PCIe device tree nodes for R8A7790
Date: Wed, 26 Mar 2014 11:34:18 +0100 [thread overview]
Message-ID: <5768554.vihmtytclA@wuerfel> (raw)
In-Reply-To: <OF61E4A09E.4D57F668-ON80257CA7.0035A569-80257CA7.00367A70@eu.necel.com>
On Wednesday 26 March 2014 09:55:04 Phil.Edworthy at renesas.com wrote:
> Hi Arnd,
>
> On: 25/03/2014 18:42, Arnd wrote:
> > Subject: Re: [PATCH v5 6/9] ARM: shmobile: Add PCIe device tree nodes
> for R8A7790
> >
> > On Tuesday 25 March 2014 16:56:41 Phil Edworthy wrote:
> > > + /* Map all possible DDR as inbound ranges */
> > > + dma-ranges = <0x42000000 0 0x40000000 0 0x40000000 0
> 0x80000000
> > > + 0x43000000 1 0x80000000 1 0x80000000 0
> 0x80000000>;
> >
> > Typo: 0x43000000 should be 0x42000000 I guess.
> I used 0x43000000 as this is a 64-bit type. The OF PCI range code
> currently treats both 32 and 64-bit types the same way, but I thought it
> would be good to set this in case we ever need to use it.
Ah, I forgot about the space identifier. It looks correct then, but
it seems a little strange to use a 32-bit identifier in one case
and a 64-bit one in the other.
> > Since you control the mapping, I wonder if you could also do this as
> >
> > dma-ranges = <0x42000000 0 0x00000000 0 0x40000000 0
> 0x80000000
> > 0x43000000 0 0x80000000 1 0x80000000 0
> 0x80000000>;
> >
> > i.e. map all the RAM into PCI bus addresses below the 32-bit boundary.
> > This would be really nice from the perspective that now all PCI
> > devices could access all of RAM without using an IOMMU or the
> > relying on 64-bit master capability.
> >
> > The downside of this is that you'd probably need a custom dma_map_ops
> > wrapper.
> Since the OF PCi range code treats both 32 and 64-bit types the same way,
> my PCIe driver only creates 64-bit mappings. In addition, the PCIe
> controller has to use a 64-bit mapping for anything over 2GiB. Based on
> this, I think it's sensible to leave the mappings as 1-to-1.
I'm not following, sorry. What is the hardware requirement in the
controller?
Arnd
next prev parent reply other threads:[~2014-03-26 10:34 UTC|newest]
Thread overview: 88+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-03-25 16:56 [PATCH v5 0/9] R-Car Gen2 PCIe host driver Phil Edworthy
2014-03-25 16:56 ` Phil Edworthy
2014-03-25 16:56 ` Phil Edworthy
2014-03-25 16:56 ` [PATCH v5 1/9] PCI: host: rcar: Add Renesas R-Car PCIe driver Phil Edworthy
2014-03-25 16:56 ` Phil Edworthy
2014-03-25 16:56 ` Phil Edworthy
2014-03-25 16:56 ` [PATCH v5 2/9] PCI: host: rcar: Add MSI support Phil Edworthy
2014-03-25 16:56 ` Phil Edworthy
2014-03-25 16:56 ` Phil Edworthy
2014-03-25 17:04 ` Ben Dooks
2014-03-25 17:04 ` Ben Dooks
2014-03-25 17:04 ` Ben Dooks
2014-03-26 10:12 ` Phil.Edworthy
2014-03-26 10:12 ` Phil.Edworthy at renesas.com
2014-03-26 10:12 ` Phil.Edworthy
2014-03-25 16:56 ` [PATCH v5 3/9] ARM: shmobile: r8a7790: Add PCIe clock device tree nodes Phil Edworthy
2014-03-25 16:56 ` Phil Edworthy
2014-03-25 16:56 ` Phil Edworthy
2014-03-25 16:56 ` [PATCH v5 4/9] ARM: shmobile: r8a7791: " Phil Edworthy
2014-03-25 16:56 ` Phil Edworthy
2014-03-25 16:56 ` Phil Edworthy
2014-03-25 16:56 ` [PATCH v5 5/9] dt-bindings: pci: rcar pcie device tree bindings Phil Edworthy
2014-03-25 16:56 ` Phil Edworthy
2014-03-25 16:56 ` Phil Edworthy
2014-03-25 16:56 ` Phil Edworthy
2014-03-25 19:22 ` Sergei Shtylyov
2014-03-25 20:22 ` Sergei Shtylyov
2014-03-25 20:22 ` Sergei Shtylyov
2014-03-26 9:12 ` Phil.Edworthy
2014-03-26 9:12 ` Phil.Edworthy at renesas.com
2014-03-26 9:12 ` Phil.Edworthy
2014-03-25 16:56 ` [PATCH v5 6/9] ARM: shmobile: Add PCIe device tree nodes for R8A7790 Phil Edworthy
2014-03-25 16:56 ` Phil Edworthy
2014-03-25 16:56 ` Phil Edworthy
2014-03-25 18:42 ` Arnd Bergmann
2014-03-25 18:42 ` Arnd Bergmann
2014-03-25 18:42 ` Arnd Bergmann
2014-03-26 9:55 ` Phil.Edworthy
2014-03-26 9:55 ` Phil.Edworthy at renesas.com
2014-03-26 9:55 ` Phil.Edworthy
2014-03-26 10:34 ` Arnd Bergmann [this message]
2014-03-26 10:34 ` Arnd Bergmann
2014-03-26 10:34 ` Arnd Bergmann
2014-03-26 11:01 ` Phil.Edworthy
2014-03-26 11:01 ` Phil.Edworthy at renesas.com
2014-03-26 11:01 ` Phil.Edworthy
2014-03-26 11:14 ` Arnd Bergmann
2014-03-26 11:14 ` Arnd Bergmann
2014-03-26 11:14 ` Arnd Bergmann
2014-03-26 11:34 ` Phil.Edworthy
2014-03-26 11:34 ` Phil.Edworthy at renesas.com
2014-03-26 11:34 ` Phil.Edworthy
2014-03-26 11:52 ` Arnd Bergmann
2014-03-26 11:52 ` Arnd Bergmann
2014-03-26 11:52 ` Arnd Bergmann
2014-03-26 11:56 ` Phil.Edworthy
2014-03-26 11:56 ` Phil.Edworthy at renesas.com
2014-03-26 11:56 ` Phil.Edworthy
2014-03-25 21:03 ` Simon Horman
2014-03-25 21:03 ` Simon Horman
2014-03-25 21:03 ` Simon Horman
2014-03-26 8:54 ` Phil.Edworthy
2014-03-26 8:54 ` Phil.Edworthy at renesas.com
2014-03-26 8:54 ` Phil.Edworthy
2014-03-25 16:56 ` [PATCH v5 7/9] ARM: shmobile: Add PCIe device tree nodes for R8A7791 Koelsch board Phil Edworthy
2014-03-25 16:56 ` Phil Edworthy
2014-03-25 16:56 ` Phil Edworthy
2014-03-25 21:00 ` Simon Horman
2014-03-25 21:00 ` Simon Horman
2014-03-25 21:00 ` Simon Horman
2014-03-25 16:56 ` [PATCH v5 8/9] ARM: koelsch: Add PCIe to defconfig Phil Edworthy
2014-03-25 16:56 ` Phil Edworthy
2014-03-25 16:56 ` Phil Edworthy
2014-03-25 20:57 ` Simon Horman
2014-03-25 20:57 ` Simon Horman
2014-03-25 20:57 ` Simon Horman
2014-03-25 16:56 ` [PATCH v5 9/9] ARM: koelsch: Add HAVE_ARM_ARCH_TIMER " Phil Edworthy
2014-03-25 16:56 ` Phil Edworthy
2014-03-25 16:56 ` Phil Edworthy
2014-03-25 21:02 ` Simon Horman
2014-03-25 21:02 ` Simon Horman
2014-03-25 21:02 ` Simon Horman
2014-03-26 5:39 ` Magnus Damm
2014-03-26 5:39 ` Magnus Damm
2014-03-26 5:39 ` Magnus Damm
2014-03-26 8:50 ` Phil.Edworthy
2014-03-26 8:50 ` Phil.Edworthy at renesas.com
2014-03-26 8:50 ` Phil.Edworthy
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=5768554.vihmtytclA@wuerfel \
--to=arnd@arndb.de \
--cc=Phil.Edworthy@renesas.com \
--cc=ben.dooks@codethink.co.uk \
--cc=bhelgaas@google.com \
--cc=horms@verge.net.au \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-pci@vger.kernel.org \
--cc=linux-sh@vger.kernel.org \
--cc=magnus.damm@gmail.com \
--cc=valentine.barshak@cogentembedded.com \
/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.