From: Arnd Bergmann <arnd@arndb.de> To: Ezequiel Garcia <ezequiel.garcia@free-electrons.com> Cc: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>, Andrew Lunn <andrew@lunn.ch>, Jason Cooper <jason@lakedaemon.net>, devicetree-discuss@lists.ozlabs.org, Grant Likely <grant.likely@secretlab.ca>, Jason Gunthorpe <jgunthorpe@obsidianresearch.com>, Maen Suleiman <maen@marvell.com>, Lior Amsalem <alior@marvell.com>, Gregory Clement <gregory.clement@free-electrons.com>, linux-arm-kernel@lists.infradead.org, Sebastian Hesselbarth <sebastian.hesselbarth@gmail.com> Subject: Re: [PATCH v6 00/21] MBus DT binding: PCIe strikes back Date: Sat, 6 Jul 2013 00:40:26 +0200 [thread overview] Message-ID: <201307060040.27208.arnd@arndb.de> (raw) In-Reply-To: <1373060372-32357-1-git-send-email-ezequiel.garcia@free-electrons.com> On Friday 05 July 2013, Ezequiel Garcia wrote: > See the previous version of this patchset for further context: > > http://www.mail-archive.com/devicetree-discuss@lists.ozlabs.org/msg35753.html > > This new proposal is an attempt to address some issues raised about the PCIe > 'fake' windows mapping present in the previous version. > > Instead of defining a 'fake' MBUS_ID(0xf0, 0x02) region for the whole > PCIe memory and IO space, we use real target ID and attribute for the windows. Hi Ezequiel, This looks really nice, and I is getting very close to where I think it needs to be headed. I'll have to do a more thorough review, but for now there is only one detail that I think you should change (we can argue about that): > pcie-controller { > compatible = "marvell,armada-xp-pcie"; > status = "okay"; > device_type = "pci"; > > #address-cells = <3>; > #size-cells = <2>; > > ranges = > <0x82000000 0 0x40000 MBUS_ID(0xf0, 0x01) 0x40000 0 0x00002000 /* Port 0.0 registers */ > 0x82000000 0 0x42000 MBUS_ID(0xf0, 0x01) 0x42000 0 0x00002000 /* Port 2.0 registers */ > 0x82000000 0 0x44000 MBUS_ID(0xf0, 0x01) 0x44000 0 0x00002000 /* Port 0.1 registers */ > 0x82000000 0 0x48000 MBUS_ID(0xf0, 0x01) 0x48000 0 0x00002000 /* Port 0.2 registers */ > 0x82000000 0 0x4c000 MBUS_ID(0xf0, 0x01) 0x4c000 0 0x00002000 /* Port 0.3 registers */ > 0x82000800 0 0xe0000000 MBUS_ID(0x04, 0xe8) 0xe0000000 0 0x08000000 /* Port 0.0 MEM */ > 0x81000800 0 0 MBUS_ID(0x04, 0xe0) 0xe8000000 0 0x00100000 /* Port 0.0 IO */>; >From all I can tell, this is a correct representation of the translation windows. The one change you made from what I suggested (either intentionally or because I didn't make myself clear enough) is that you keep encoding the aperture in the ranges property of the pcie node. 0x82000800 0 0xe0000000 MBUS_ID(0x04, 0xe8) 0xe0000000 0 0x08000000 /* Port 0.0 MEM */ ^^^^ ^^^^ ^^^ This describes the intended setting of the aperture in the mbus, not the translation that is performed by the pcie-controller as I suggested. That would look like 0x82000800 0 0 MBUS_ID(0x04, 0xe8) 0 1 0 /* Port 0.0 MEM */ iow the first 4GB of the 0x82000800 memory space get translated to 4GB at MBUS_ID(0x04, 0xe8), and the aperture is applied by translating a small section of that into host mmio space. The advantage of your approach is that you can keep the existing code that extracts the aperture (0xe0000000-0xe8000000) from the pcie-controller node, and you don't have to find out the aperture from separate DT property or from looking at the remaining available address space in mbus. The disadvantage is that you have mbus policy spread out between the ranges properties of the mbus node and the pcie node, rather than having the pcie-controller node just describe the hardware capabilities. This is actually more of a problem for the I/O space, which is still not correctly represented: 0x81000800 0 0 MBUS_ID(0x04, 0xe0) 0xe8000000 0 0x00100000 is not what the hardware does, the hardware probably has something like 0x81000800 0 0 MBUS_ID(0x04, 0xe0) 0 1 0 i.e. the PIO registers are at the start of the 4GB MBUS window and you want them to get mapped at 0xe8000000, but that is no business of the PCIe node. Since the addresses for I/O space are fixed (unlike memory space, which is sized dynamically per port), it would be straightforward to put the mappings into the mbus node: MBUS_ID(0x04, 0xe0) 0x00000 0xe8000000 0x10000 MBUS_ID(0x04, 0xe1) 0x10000 0xe8010000 0x10000 MBUS_ID(0x04, 0xe2) 0x20000 0xe8020000 0x10000 Unfortunately, the number of mapping windows in mbus is very limited on Armada XP, so you'd run out of windows too fast by mapping them all at boot time. The options here are to either put them into the ranges property anyway but get the mbus driver to not map them by default, or to encode the policy in a different way. Note that the physical addresses do not actually have to be contiguous any more now, so one option would be for mbus to just fill the holes whenever the pcie driver needs an I/O space window, but there we get close to the "fully dynamic" model again. Arnd
WARNING: multiple messages have this Message-ID (diff)
From: arnd@arndb.de (Arnd Bergmann) To: linux-arm-kernel@lists.infradead.org Subject: [PATCH v6 00/21] MBus DT binding: PCIe strikes back Date: Sat, 6 Jul 2013 00:40:26 +0200 [thread overview] Message-ID: <201307060040.27208.arnd@arndb.de> (raw) In-Reply-To: <1373060372-32357-1-git-send-email-ezequiel.garcia@free-electrons.com> On Friday 05 July 2013, Ezequiel Garcia wrote: > See the previous version of this patchset for further context: > > http://www.mail-archive.com/devicetree-discuss at lists.ozlabs.org/msg35753.html > > This new proposal is an attempt to address some issues raised about the PCIe > 'fake' windows mapping present in the previous version. > > Instead of defining a 'fake' MBUS_ID(0xf0, 0x02) region for the whole > PCIe memory and IO space, we use real target ID and attribute for the windows. Hi Ezequiel, This looks really nice, and I is getting very close to where I think it needs to be headed. I'll have to do a more thorough review, but for now there is only one detail that I think you should change (we can argue about that): > pcie-controller { > compatible = "marvell,armada-xp-pcie"; > status = "okay"; > device_type = "pci"; > > #address-cells = <3>; > #size-cells = <2>; > > ranges = > <0x82000000 0 0x40000 MBUS_ID(0xf0, 0x01) 0x40000 0 0x00002000 /* Port 0.0 registers */ > 0x82000000 0 0x42000 MBUS_ID(0xf0, 0x01) 0x42000 0 0x00002000 /* Port 2.0 registers */ > 0x82000000 0 0x44000 MBUS_ID(0xf0, 0x01) 0x44000 0 0x00002000 /* Port 0.1 registers */ > 0x82000000 0 0x48000 MBUS_ID(0xf0, 0x01) 0x48000 0 0x00002000 /* Port 0.2 registers */ > 0x82000000 0 0x4c000 MBUS_ID(0xf0, 0x01) 0x4c000 0 0x00002000 /* Port 0.3 registers */ > 0x82000800 0 0xe0000000 MBUS_ID(0x04, 0xe8) 0xe0000000 0 0x08000000 /* Port 0.0 MEM */ > 0x81000800 0 0 MBUS_ID(0x04, 0xe0) 0xe8000000 0 0x00100000 /* Port 0.0 IO */>; >From all I can tell, this is a correct representation of the translation windows. The one change you made from what I suggested (either intentionally or because I didn't make myself clear enough) is that you keep encoding the aperture in the ranges property of the pcie node. 0x82000800 0 0xe0000000 MBUS_ID(0x04, 0xe8) 0xe0000000 0 0x08000000 /* Port 0.0 MEM */ ^^^^ ^^^^ ^^^ This describes the intended setting of the aperture in the mbus, not the translation that is performed by the pcie-controller as I suggested. That would look like 0x82000800 0 0 MBUS_ID(0x04, 0xe8) 0 1 0 /* Port 0.0 MEM */ iow the first 4GB of the 0x82000800 memory space get translated to 4GB at MBUS_ID(0x04, 0xe8), and the aperture is applied by translating a small section of that into host mmio space. The advantage of your approach is that you can keep the existing code that extracts the aperture (0xe0000000-0xe8000000) from the pcie-controller node, and you don't have to find out the aperture from separate DT property or from looking at the remaining available address space in mbus. The disadvantage is that you have mbus policy spread out between the ranges properties of the mbus node and the pcie node, rather than having the pcie-controller node just describe the hardware capabilities. This is actually more of a problem for the I/O space, which is still not correctly represented: 0x81000800 0 0 MBUS_ID(0x04, 0xe0) 0xe8000000 0 0x00100000 is not what the hardware does, the hardware probably has something like 0x81000800 0 0 MBUS_ID(0x04, 0xe0) 0 1 0 i.e. the PIO registers are at the start of the 4GB MBUS window and you want them to get mapped at 0xe8000000, but that is no business of the PCIe node. Since the addresses for I/O space are fixed (unlike memory space, which is sized dynamically per port), it would be straightforward to put the mappings into the mbus node: MBUS_ID(0x04, 0xe0) 0x00000 0xe8000000 0x10000 MBUS_ID(0x04, 0xe1) 0x10000 0xe8010000 0x10000 MBUS_ID(0x04, 0xe2) 0x20000 0xe8020000 0x10000 Unfortunately, the number of mapping windows in mbus is very limited on Armada XP, so you'd run out of windows too fast by mapping them all at boot time. The options here are to either put them into the ranges property anyway but get the mbus driver to not map them by default, or to encode the policy in a different way. Note that the physical addresses do not actually have to be contiguous any more now, so one option would be for mbus to just fill the holes whenever the pcie driver needs an I/O space window, but there we get close to the "fully dynamic" model again. Arnd
next prev parent reply other threads:[~2013-07-05 22:40 UTC|newest] Thread overview: 60+ messages / expand[flat|nested] mbox.gz Atom feed top 2013-07-05 21:39 [PATCH v6 00/21] MBus DT binding: PCIe strikes back Ezequiel Garcia 2013-07-05 21:39 ` Ezequiel Garcia [not found] ` <1373060372-32357-1-git-send-email-ezequiel.garcia-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org> 2013-07-05 21:39 ` [PATCH v6 01/21] memory: mvebu-devbus: Remove address decoding window workaround Ezequiel Garcia 2013-07-05 21:39 ` Ezequiel Garcia 2013-07-05 21:39 ` [PATCH v6 02/21] bus: mvebu-mbus: Add new API for window creation Ezequiel Garcia 2013-07-05 21:39 ` Ezequiel Garcia 2013-07-05 21:39 ` [PATCH v6 03/21] ARM: kirkwood: Move to ID based MBus " Ezequiel Garcia 2013-07-05 21:39 ` Ezequiel Garcia 2013-07-05 21:39 ` [PATCH v6 04/21] ARM: mv78xx0: Move to ID based " Ezequiel Garcia 2013-07-05 21:39 ` Ezequiel Garcia 2013-07-05 21:39 ` [PATCH v6 05/21] ARM: orion5x: " Ezequiel Garcia 2013-07-05 21:39 ` Ezequiel Garcia 2013-07-05 21:39 ` [PATCH v6 06/21] ARM: dove: " Ezequiel Garcia 2013-07-05 21:39 ` Ezequiel Garcia 2013-07-05 21:39 ` [PATCH v6 07/21] bus: mvebu-mbus: Factor out initialization details Ezequiel Garcia 2013-07-05 21:39 ` Ezequiel Garcia 2013-07-05 21:39 ` [PATCH v6 08/21] bus: mvebu-mbus: Introduce device tree binding Ezequiel Garcia 2013-07-05 21:39 ` Ezequiel Garcia 2013-07-05 21:39 ` [PATCH v6 09/21] bus: mvebu-mbus: Add static window allocation to the binding Ezequiel Garcia 2013-07-05 21:39 ` Ezequiel Garcia 2013-07-05 21:39 ` [PATCH v6 10/21] pci: mvebu: Adapt to the new device tree layout Ezequiel Garcia 2013-07-05 21:39 ` Ezequiel Garcia 2013-07-05 21:39 ` [PATCH v6 11/21] bus: mvebu-mbus: Remove the no longer used name-based API Ezequiel Garcia 2013-07-05 21:39 ` Ezequiel Garcia 2013-07-05 21:39 ` [PATCH v6 12/21] bus: mvebu-mbus: Remove name -> target, attribute mapping tables Ezequiel Garcia 2013-07-05 21:39 ` Ezequiel Garcia 2013-07-05 21:39 ` [PATCH v6 13/21] bus: mvebu-mbus: Update main description Ezequiel Garcia 2013-07-05 21:39 ` Ezequiel Garcia 2013-07-05 21:39 ` [PATCH v6 14/21] bus: mvebu-mbus: Factorize Armada 370/XP data structures Ezequiel Garcia 2013-07-05 21:39 ` Ezequiel Garcia 2013-07-05 21:39 ` [PATCH v6 15/21] ARM: mvebu: Remove the harcoded BootROM window allocation Ezequiel Garcia 2013-07-05 21:39 ` Ezequiel Garcia 2013-07-05 21:39 ` [PATCH v6 16/21] ARM: mvebu: Initialize MBus using the DT binding Ezequiel Garcia 2013-07-05 21:39 ` Ezequiel Garcia 2013-07-05 21:39 ` [PATCH v6 17/21] ARM: mvebu: Use the preprocessor on Armada 370/XP device tree files Ezequiel Garcia 2013-07-05 21:39 ` Ezequiel Garcia 2013-07-05 21:39 ` [PATCH v6 18/21] ARM: mvebu: Add MBus to Armada 370/XP device tree Ezequiel Garcia 2013-07-05 21:39 ` Ezequiel Garcia 2013-07-05 21:39 ` [PATCH v6 19/21] ARM: mvebu: Add BootROM " Ezequiel Garcia 2013-07-05 21:39 ` Ezequiel Garcia 2013-07-05 21:39 ` [PATCH v6 20/21] ARM: mvebu: Relocate Armada 370/XP DeviceBus device tree nodes Ezequiel Garcia 2013-07-05 21:39 ` Ezequiel Garcia 2013-07-05 21:39 ` [PATCH v6 21/21] ARM: mvebu: Relocate Armada 370/XP PCIe " Ezequiel Garcia 2013-07-05 21:39 ` Ezequiel Garcia 2013-07-05 22:08 ` [PATCH v6 00/21] MBus DT binding: PCIe strikes back Jason Gunthorpe 2013-07-05 22:08 ` Jason Gunthorpe [not found] ` <20130705220820.GA11787-ePGOBjL8dl3ta4EC/59zMFaTQe2KTcn/@public.gmane.org> 2013-07-05 22:37 ` Thomas Petazzoni 2013-07-05 22:37 ` Thomas Petazzoni 2013-07-05 22:54 ` Arnd Bergmann 2013-07-05 22:54 ` Arnd Bergmann 2013-07-05 23:35 ` Thomas Petazzoni 2013-07-05 23:35 ` Thomas Petazzoni 2013-07-05 23:38 ` Arnd Bergmann 2013-07-05 23:38 ` Arnd Bergmann [not found] ` <201307060138.36191.arnd-r2nGTMty4D4@public.gmane.org> 2013-07-08 16:42 ` Jason Gunthorpe 2013-07-08 16:42 ` Jason Gunthorpe [not found] ` <20130708164225.GA26618-ePGOBjL8dl3ta4EC/59zMFaTQe2KTcn/@public.gmane.org> 2013-07-08 19:52 ` Ezequiel Garcia 2013-07-08 19:52 ` Ezequiel Garcia 2013-07-05 22:40 ` Arnd Bergmann [this message] 2013-07-05 22:40 ` Arnd Bergmann
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=201307060040.27208.arnd@arndb.de \ --to=arnd@arndb.de \ --cc=alior@marvell.com \ --cc=andrew@lunn.ch \ --cc=devicetree-discuss@lists.ozlabs.org \ --cc=ezequiel.garcia@free-electrons.com \ --cc=grant.likely@secretlab.ca \ --cc=gregory.clement@free-electrons.com \ --cc=jason@lakedaemon.net \ --cc=jgunthorpe@obsidianresearch.com \ --cc=linux-arm-kernel@lists.infradead.org \ --cc=maen@marvell.com \ --cc=sebastian.hesselbarth@gmail.com \ --cc=thomas.petazzoni@free-electrons.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: linkBe 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.