From: Liviu Dudau <Liviu.Dudau@arm.com> To: Arnd Bergmann <arnd@arndb.de> Cc: "linux-arm-kernel@lists.infradead.org" <linux-arm-kernel@lists.infradead.org>, Rob Herring <robherring2@gmail.com>, Sinan Kaya <okaya@codeaurora.org>, linaro-kernel <linaro-kernel@lists.linaro.org>, Catalin Marinas <Catalin.Marinas@arm.com>, Device Tree ML <devicetree@vger.kernel.org>, linux-pci <linux-pci@vger.kernel.org>, Jingoo Han <jg1.han@samsung.com>, Will Deacon <Will.Deacon@arm.com>, LKML <linux-kernel@vger.kernel.org>, Grant Likely <grant.likely@secretlab.ca>, Kukjin Kim <kgene.kim@samsung.com>, Tanmay Inamdar <tinamdar@apm.com>, Suravee Suthikulanit <suravee.suthikulpanit@amd.com>, Benjamin Herrenschmidt <benh@kernel.crashing.org>, Bjorn Helgaas <bhelgaas@google.com> Subject: Re: [PATCH v8 4/9] pci: OF: Fix the conversion of IO ranges into IO resources. Date: Tue, 8 Jul 2014 11:03:32 +0100 [thread overview] Message-ID: <20140708100332.GW6501@e106497-lin.cambridge.arm.com> (raw) In-Reply-To: <201407072322.00990.arnd@arndb.de> On Mon, Jul 07, 2014 at 10:22:00PM +0100, Arnd Bergmann wrote: > On Monday 07 July 2014, Liviu Dudau wrote: > > On Sat, Jul 05, 2014 at 09:46:09PM +0100, Arnd Bergmann wrote: > > > On Saturday 05 July 2014 14:25:52 Rob Herring wrote: > > > > On Tue, Jul 1, 2014 at 1:43 PM, Liviu Dudau <Liviu.Dudau@arm.com> wrote: > > > > > The ranges property for a host bridge controller in DT describes > > > > > the mapping between the PCI bus address and the CPU physical address. > > > > > The resources framework however expects that the IO resources start > > > > > at a pseudo "port" address 0 (zero) and have a maximum size of IO_SPACE_LIMIT. > > > > > The conversion from pci ranges to resources failed to take that into account. > > > > > > > > I don't think this change is right. There are 2 resources: the PCI bus > > > > addresses and cpu addresses. This function deals with the cpu > > > > addresses. Returning pci addresses for i/o and cpu addresses for > > > > memory is going to be error prone. We probably need both cpu and pci > > > > resources exposed to host controllers. > > > > > > > > Making the new function only deal with i/o bus resources and naming it > > > > of_pci_range_to_io_resource would be better. > > > > > > I think you are correct that this change by itself is will break existing > > > drivers that rely on the current behavior of of_pci_range_to_resource, > > > but there is also something wrong with the existing implementation: > > > > Either I'm very confused or I've managed to confuse everyone else. The I/O > > resources described using CPU addresses *are* using "pseudo" port based > > addresses (or at least that is my understanding and my reading of the code). > > Can you point me to a function that is expecting the IO resource to have > > the start address at the physical address of the mapped space? > > pci_v3_preinit() in arch/arm/mach-integrator/pci_v3.c for instance takes > the resource returned by of_pci_range_to_resource and programs the > start and size into hardware registers that expect a physical address > as far as I can tell. > > > I was trying to fix exactly this issue, that you cannot use the resource > > structure returned by this function in any call that is expecting an IO > > resource. > > I looked at the other drivers briefly, and I think you indeed fix the Tegra > driver with this but break the integrator driver as mentioned above. > The other callers of of_pci_range_to_resource() are apparently not > impacted as they recalculate the values they get. I would argue that integrator version is having broken assumptions. If it would try to allocate that IO range or request the resource as returned currently by of_pci_range_to_resource (without my patch) it would fail. I know because I did the same thing in my host bridge driver and it failed miserably. That's why I tried to patch it. I will lay out my argument here and people can tell me if I am wrong: PCI IO resources (even if they are memory mapped on certain architectures) need to emulate the x86 world "port" concept. Why do I think this? Because of this structure at the beginning of kernel/resource.c: struct resource ioport_resource = { .name = "PCI IO", .start = 0, .end = IO_SPACE_LIMIT, .flags = IORESOURCE_IO, }; EXPORT_SYMBOL(ioport_resource); The other resource that people seem to confuse it with is the next one in that file: struct resource iomem_resource = { .name = "PCI mem", .start = 0, .end = -1, .flags = IORESOURCE_MEM, }; EXPORT_SYMBOL(iomem_resource); Now, there are architecture that override the .start and .end values, but arm is not one of those, and mach-integrator doesn't change it either. So one can play with the ioport_resource values to move the "port" window wherever he/she wants, but it doesn't change the "port access" way of addressing it. If the IO space is memory mapped, then we use the port number, the io_offset and the PCI_IOBASE to get to the virtual address that, when accessed, will generate the correct addresses on the bus, based on what the host bridge has been configured. This is the current level of my understanding of PCI IO. Now, I believe Rob has switched entirely to using my series in some test that he has run and he hasn't encountered any issues, as long as one remembers in the host bridge driver to add the io_base offset to the .start resource. If not then I need to patch pci_v3.c. Best regards, Liviu > > Arnd > -- ==================== | I would like to | | fix the world, | | but they're not | | giving me the | \ source code! / --------------- ¯\_(ツ)_/¯
WARNING: multiple messages have this Message-ID (diff)
From: Liviu.Dudau@arm.com (Liviu Dudau) To: linux-arm-kernel@lists.infradead.org Subject: [PATCH v8 4/9] pci: OF: Fix the conversion of IO ranges into IO resources. Date: Tue, 8 Jul 2014 11:03:32 +0100 [thread overview] Message-ID: <20140708100332.GW6501@e106497-lin.cambridge.arm.com> (raw) In-Reply-To: <201407072322.00990.arnd@arndb.de> On Mon, Jul 07, 2014 at 10:22:00PM +0100, Arnd Bergmann wrote: > On Monday 07 July 2014, Liviu Dudau wrote: > > On Sat, Jul 05, 2014 at 09:46:09PM +0100, Arnd Bergmann wrote: > > > On Saturday 05 July 2014 14:25:52 Rob Herring wrote: > > > > On Tue, Jul 1, 2014 at 1:43 PM, Liviu Dudau <Liviu.Dudau@arm.com> wrote: > > > > > The ranges property for a host bridge controller in DT describes > > > > > the mapping between the PCI bus address and the CPU physical address. > > > > > The resources framework however expects that the IO resources start > > > > > at a pseudo "port" address 0 (zero) and have a maximum size of IO_SPACE_LIMIT. > > > > > The conversion from pci ranges to resources failed to take that into account. > > > > > > > > I don't think this change is right. There are 2 resources: the PCI bus > > > > addresses and cpu addresses. This function deals with the cpu > > > > addresses. Returning pci addresses for i/o and cpu addresses for > > > > memory is going to be error prone. We probably need both cpu and pci > > > > resources exposed to host controllers. > > > > > > > > Making the new function only deal with i/o bus resources and naming it > > > > of_pci_range_to_io_resource would be better. > > > > > > I think you are correct that this change by itself is will break existing > > > drivers that rely on the current behavior of of_pci_range_to_resource, > > > but there is also something wrong with the existing implementation: > > > > Either I'm very confused or I've managed to confuse everyone else. The I/O > > resources described using CPU addresses *are* using "pseudo" port based > > addresses (or at least that is my understanding and my reading of the code). > > Can you point me to a function that is expecting the IO resource to have > > the start address at the physical address of the mapped space? > > pci_v3_preinit() in arch/arm/mach-integrator/pci_v3.c for instance takes > the resource returned by of_pci_range_to_resource and programs the > start and size into hardware registers that expect a physical address > as far as I can tell. > > > I was trying to fix exactly this issue, that you cannot use the resource > > structure returned by this function in any call that is expecting an IO > > resource. > > I looked at the other drivers briefly, and I think you indeed fix the Tegra > driver with this but break the integrator driver as mentioned above. > The other callers of of_pci_range_to_resource() are apparently not > impacted as they recalculate the values they get. I would argue that integrator version is having broken assumptions. If it would try to allocate that IO range or request the resource as returned currently by of_pci_range_to_resource (without my patch) it would fail. I know because I did the same thing in my host bridge driver and it failed miserably. That's why I tried to patch it. I will lay out my argument here and people can tell me if I am wrong: PCI IO resources (even if they are memory mapped on certain architectures) need to emulate the x86 world "port" concept. Why do I think this? Because of this structure at the beginning of kernel/resource.c: struct resource ioport_resource = { .name = "PCI IO", .start = 0, .end = IO_SPACE_LIMIT, .flags = IORESOURCE_IO, }; EXPORT_SYMBOL(ioport_resource); The other resource that people seem to confuse it with is the next one in that file: struct resource iomem_resource = { .name = "PCI mem", .start = 0, .end = -1, .flags = IORESOURCE_MEM, }; EXPORT_SYMBOL(iomem_resource); Now, there are architecture that override the .start and .end values, but arm is not one of those, and mach-integrator doesn't change it either. So one can play with the ioport_resource values to move the "port" window wherever he/she wants, but it doesn't change the "port access" way of addressing it. If the IO space is memory mapped, then we use the port number, the io_offset and the PCI_IOBASE to get to the virtual address that, when accessed, will generate the correct addresses on the bus, based on what the host bridge has been configured. This is the current level of my understanding of PCI IO. Now, I believe Rob has switched entirely to using my series in some test that he has run and he hasn't encountered any issues, as long as one remembers in the host bridge driver to add the io_base offset to the .start resource. If not then I need to patch pci_v3.c. Best regards, Liviu > > Arnd > -- ==================== | I would like to | | fix the world, | | but they're not | | giving me the | \ source code! / --------------- ?\_(?)_/?
next prev parent reply other threads:[~2014-07-08 10:03 UTC|newest] Thread overview: 218+ messages / expand[flat|nested] mbox.gz Atom feed top 2014-07-01 18:43 [PATCH v8 0/9] Support for creating generic PCI host bridges from DT Liviu Dudau 2014-07-01 18:43 ` Liviu Dudau 2014-07-01 18:43 ` [PATCH v8 1/9] Fix ioport_map() for !CONFIG_GENERIC_IOMAP cases Liviu Dudau 2014-07-01 18:43 ` Liviu Dudau 2014-07-01 18:43 ` Liviu Dudau 2014-07-01 18:43 ` [PATCH v8 2/9] pci: Export find_pci_host_bridge() function Liviu Dudau 2014-07-01 18:43 ` Liviu Dudau 2014-07-01 18:43 ` Liviu Dudau 2014-07-02 18:06 ` Tanmay Inamdar 2014-07-02 18:06 ` Tanmay Inamdar 2014-07-02 19:12 ` Arnd Bergmann 2014-07-02 19:12 ` Arnd Bergmann 2014-07-02 20:43 ` Tanmay Inamdar 2014-07-02 20:43 ` Tanmay Inamdar 2014-07-03 9:53 ` Liviu Dudau 2014-07-03 9:53 ` Liviu Dudau 2014-07-03 10:26 ` Arnd Bergmann 2014-07-03 10:26 ` Arnd Bergmann 2014-07-07 23:27 ` Bjorn Helgaas 2014-07-07 23:27 ` Bjorn Helgaas 2014-07-07 23:27 ` Bjorn Helgaas 2014-07-08 10:42 ` Liviu Dudau 2014-07-08 10:42 ` Liviu Dudau 2014-07-08 10:42 ` Liviu Dudau 2014-07-01 18:43 ` [PATCH v8 3/9] pci: Introduce pci_register_io_range() helper function Liviu Dudau 2014-07-01 18:43 ` Liviu Dudau 2014-07-01 18:43 ` Liviu Dudau 2014-07-01 19:36 ` Arnd Bergmann 2014-07-01 19:36 ` Arnd Bergmann 2014-07-01 20:45 ` Liviu Dudau 2014-07-01 20:45 ` Liviu Dudau 2014-07-02 12:30 ` Arnd Bergmann 2014-07-02 12:30 ` Arnd Bergmann 2014-07-02 14:23 ` Liviu Dudau 2014-07-02 14:23 ` Liviu Dudau 2014-07-02 14:23 ` Liviu Dudau 2014-07-02 14:23 ` Liviu Dudau 2014-07-02 14:58 ` Arnd Bergmann 2014-07-02 14:58 ` Arnd Bergmann 2014-07-02 14:58 ` Arnd Bergmann 2014-07-02 11:22 ` Will Deacon 2014-07-02 11:22 ` Will Deacon 2014-07-02 16:00 ` Liviu Dudau 2014-07-02 16:00 ` Liviu Dudau 2014-07-02 12:38 ` Arnd Bergmann 2014-07-02 12:38 ` Arnd Bergmann 2014-07-02 13:20 ` Liviu Dudau 2014-07-02 13:20 ` Liviu Dudau 2014-07-08 0:14 ` Bjorn Helgaas 2014-07-08 0:14 ` Bjorn Helgaas 2014-07-08 7:00 ` Arnd Bergmann 2014-07-08 7:00 ` Arnd Bergmann 2014-07-08 21:29 ` Bjorn Helgaas 2014-07-08 21:29 ` Bjorn Helgaas 2014-07-08 22:45 ` Liviu Dudau 2014-07-08 22:45 ` Liviu Dudau 2014-07-09 6:32 ` Arnd Bergmann 2014-07-09 6:32 ` Arnd Bergmann 2014-07-09 6:32 ` Arnd Bergmann 2014-07-09 9:13 ` Liviu Dudau 2014-07-09 9:13 ` Liviu Dudau 2014-07-09 6:20 ` Arnd Bergmann 2014-07-09 6:20 ` Arnd Bergmann 2014-07-09 9:14 ` Liviu Dudau 2014-07-09 9:14 ` Liviu Dudau 2014-07-09 15:21 ` Bjorn Helgaas 2014-07-09 15:21 ` Bjorn Helgaas 2014-07-08 10:40 ` Liviu Dudau 2014-07-08 10:40 ` Liviu Dudau 2014-07-08 14:14 ` Arnd Bergmann 2014-07-08 14:14 ` Arnd Bergmann 2014-07-09 8:59 ` Liviu Dudau 2014-07-09 8:59 ` Liviu Dudau 2014-07-01 18:43 ` [PATCH v8 4/9] pci: OF: Fix the conversion of IO ranges into IO resources Liviu Dudau 2014-07-01 18:43 ` Liviu Dudau 2014-07-01 18:43 ` Liviu Dudau 2014-07-05 19:25 ` Rob Herring 2014-07-05 19:25 ` Rob Herring 2014-07-05 19:25 ` Rob Herring 2014-07-05 20:46 ` Arnd Bergmann 2014-07-05 20:46 ` Arnd Bergmann 2014-07-07 11:11 ` Liviu Dudau 2014-07-07 11:11 ` Liviu Dudau 2014-07-07 11:11 ` Liviu Dudau 2014-07-07 21:22 ` Arnd Bergmann 2014-07-07 21:22 ` Arnd Bergmann 2014-07-07 21:22 ` Arnd Bergmann 2014-07-08 10:03 ` Liviu Dudau [this message] 2014-07-08 10:03 ` Liviu Dudau 2014-07-08 10:03 ` Liviu Dudau 2014-07-09 8:31 ` Arnd Bergmann 2014-07-09 8:31 ` Arnd Bergmann 2014-07-09 8:31 ` Arnd Bergmann 2014-07-09 9:27 ` Liviu Dudau 2014-07-09 9:27 ` Liviu Dudau 2014-07-09 9:27 ` Liviu Dudau 2014-07-16 14:35 ` Rob Herring 2014-07-16 14:35 ` Rob Herring 2014-07-16 14:35 ` Rob Herring 2014-07-16 14:47 ` Liviu Dudau 2014-07-16 14:47 ` Liviu Dudau 2014-07-16 14:47 ` Liviu Dudau 2014-07-16 14:47 ` Arnd Bergmann 2014-07-16 14:47 ` Arnd Bergmann 2014-07-16 14:47 ` Arnd Bergmann 2014-07-01 18:43 ` [PATCH v8 5/9] pci: Create pci_host_bridge before its associated bus in pci_create_root_bus Liviu Dudau 2014-07-01 18:43 ` Liviu Dudau 2014-07-01 18:43 ` Liviu Dudau 2014-07-01 18:43 ` [PATCH v8 6/9] pci: Introduce a domain number for pci_host_bridge Liviu Dudau 2014-07-01 18:43 ` Liviu Dudau 2014-07-01 18:43 ` Liviu Dudau 2014-07-08 0:59 ` Bjorn Helgaas 2014-07-08 0:59 ` Bjorn Helgaas 2014-07-08 10:46 ` Liviu Dudau 2014-07-08 10:46 ` Liviu Dudau 2014-07-08 18:41 ` Bjorn Helgaas 2014-07-08 18:41 ` Bjorn Helgaas 2014-07-08 22:48 ` Liviu Dudau 2014-07-08 22:48 ` Liviu Dudau 2014-07-09 15:10 ` Bjorn Helgaas 2014-07-09 15:10 ` Bjorn Helgaas 2014-07-10 9:47 ` Liviu Dudau 2014-07-10 9:47 ` Liviu Dudau 2014-07-10 22:36 ` Bjorn Helgaas 2014-07-10 22:36 ` Bjorn Helgaas 2014-07-11 9:30 ` Liviu Dudau 2014-07-11 9:30 ` Liviu Dudau 2014-07-11 9:30 ` Liviu Dudau 2014-07-11 14:11 ` Catalin Marinas 2014-07-11 14:11 ` Catalin Marinas 2014-07-11 15:08 ` Liviu Dudau 2014-07-11 15:08 ` Liviu Dudau 2014-07-11 16:09 ` Catalin Marinas 2014-07-11 16:09 ` Catalin Marinas 2014-07-11 17:02 ` Bjorn Helgaas 2014-07-11 17:02 ` Bjorn Helgaas 2014-07-11 18:02 ` Catalin Marinas 2014-07-11 18:02 ` Catalin Marinas 2014-07-14 16:39 ` Catalin Marinas 2014-07-14 16:39 ` Catalin Marinas 2014-07-14 16:39 ` Catalin Marinas 2014-07-22 3:15 ` Bjorn Helgaas 2014-07-22 3:15 ` Bjorn Helgaas 2014-07-25 15:42 ` Catalin Marinas 2014-07-25 15:42 ` Catalin Marinas 2014-07-01 18:43 ` [PATCH v8 7/9] pci: of: Parse and map the IRQ when adding the PCI device Liviu Dudau 2014-07-01 18:43 ` Liviu Dudau 2014-07-01 18:43 ` Liviu Dudau 2014-07-02 11:17 ` Will Deacon 2014-07-02 11:17 ` Will Deacon 2014-07-05 19:04 ` Rob Herring 2014-07-05 19:04 ` Rob Herring 2014-07-05 19:04 ` Rob Herring 2014-07-01 18:43 ` [PATCH v8 8/9] pci: Add support for creating a generic host_bridge from device tree Liviu Dudau 2014-07-01 18:43 ` Liviu Dudau 2014-07-01 18:43 ` Liviu Dudau 2014-07-01 20:50 ` [RESEND] " Liviu Dudau 2014-07-01 20:50 ` Liviu Dudau 2014-07-01 20:50 ` Liviu Dudau 2014-07-01 21:04 ` Liviu Dudau 2014-07-01 21:04 ` Liviu Dudau 2014-07-01 21:04 ` Liviu Dudau 2014-07-02 11:22 ` Will Deacon 2014-07-02 11:22 ` Will Deacon 2014-07-02 17:23 ` Liviu Dudau 2014-07-02 17:23 ` Liviu Dudau 2014-07-02 17:23 ` Liviu Dudau 2014-07-02 17:31 ` Will Deacon 2014-07-02 17:31 ` Will Deacon 2014-07-02 19:09 ` Arnd Bergmann 2014-07-02 19:09 ` Arnd Bergmann 2014-07-08 1:01 ` Bjorn Helgaas 2014-07-08 1:01 ` Bjorn Helgaas 2014-07-08 10:29 ` Liviu Dudau 2014-07-08 10:29 ` Liviu Dudau 2014-07-08 21:33 ` Bjorn Helgaas 2014-07-08 21:33 ` Bjorn Helgaas 2014-07-08 22:27 ` Liviu Dudau 2014-07-08 22:27 ` Liviu Dudau 2014-07-08 22:37 ` Bjorn Helgaas 2014-07-08 22:37 ` Bjorn Helgaas 2014-07-08 22:37 ` Bjorn Helgaas 2014-07-08 22:57 ` Liviu Dudau 2014-07-08 22:57 ` Liviu Dudau 2014-07-09 6:47 ` Arnd Bergmann 2014-07-09 6:47 ` Arnd Bergmann 2014-07-11 7:43 ` Jingoo Han 2014-07-11 7:43 ` Jingoo Han 2014-07-11 9:08 ` Liviu Dudau 2014-07-11 9:08 ` Liviu Dudau 2014-07-01 18:43 ` [PATCH v8 9/9] pci: Remap I/O bus resources into CPU space with pci_remap_iospace() Liviu Dudau 2014-07-01 18:43 ` Liviu Dudau 2014-07-14 16:54 ` Catalin Marinas 2014-07-14 16:54 ` Catalin Marinas 2014-07-14 16:56 ` Liviu Dudau 2014-07-14 16:56 ` Liviu Dudau 2014-07-14 18:15 ` Arnd Bergmann 2014-07-14 18:15 ` Arnd Bergmann 2014-07-14 18:15 ` Arnd Bergmann 2014-07-15 0:14 ` Liviu Dudau 2014-07-15 0:14 ` Liviu Dudau 2014-07-15 0:14 ` Liviu Dudau 2014-07-15 9:09 ` Catalin Marinas 2014-07-15 9:09 ` Catalin Marinas 2014-07-15 9:09 ` Catalin Marinas 2014-07-06 15:23 ` [PATCH v8 0/9] Support for creating generic PCI host bridges from DT Rob Herring 2014-07-06 15:23 ` Rob Herring 2014-07-06 15:23 ` Rob Herring 2014-07-07 11:12 ` Liviu Dudau 2014-07-07 11:12 ` Liviu Dudau 2014-07-08 17:18 ` Liviu Dudau 2014-07-08 17:18 ` Liviu Dudau 2014-07-11 0:44 ` Tanmay Inamdar 2014-07-11 0:44 ` Tanmay Inamdar 2014-07-11 7:33 ` Jingoo Han 2014-07-11 7:33 ` Jingoo Han 2014-07-11 9:11 ` Liviu Dudau 2014-07-11 9:11 ` Liviu Dudau
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=20140708100332.GW6501@e106497-lin.cambridge.arm.com \ --to=liviu.dudau@arm.com \ --cc=Catalin.Marinas@arm.com \ --cc=Will.Deacon@arm.com \ --cc=arnd@arndb.de \ --cc=benh@kernel.crashing.org \ --cc=bhelgaas@google.com \ --cc=devicetree@vger.kernel.org \ --cc=grant.likely@secretlab.ca \ --cc=jg1.han@samsung.com \ --cc=kgene.kim@samsung.com \ --cc=linaro-kernel@lists.linaro.org \ --cc=linux-arm-kernel@lists.infradead.org \ --cc=linux-kernel@vger.kernel.org \ --cc=linux-pci@vger.kernel.org \ --cc=okaya@codeaurora.org \ --cc=robherring2@gmail.com \ --cc=suravee.suthikulpanit@amd.com \ --cc=tinamdar@apm.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.