* PCIe host controller without IO port access. @ 2014-11-02 23:37 ` Hauke Mehrtens 0 siblings, 0 replies; 10+ messages in thread From: Hauke Mehrtens @ 2014-11-02 23:37 UTC (permalink / raw) To: linux-arm-kernel@lists.infradead.org, linux-pci Hi, I am currently writing a driver for a PCIe host controller which does not support IO port access. My plan was to only provide IORESOURCE_MEM to pci_sys_data->resources, but then it allocates some generic IORESOURCE_IO memory in arch/arm/kernel/bios32.c:pcibios_init_resources(). This will work for the fist PCIe controller, but when the second controller gets registered I am getting this: "unable to allocate I/O port region (-16)". Is there an example for an arm driver for a PCIe controller which does not support IO port access? Should I change arch/arm/kernel/bios32.c in a way so that it would ignore the io port mem? Hauke ^ permalink raw reply [flat|nested] 10+ messages in thread
* PCIe host controller without IO port access. @ 2014-11-02 23:37 ` Hauke Mehrtens 0 siblings, 0 replies; 10+ messages in thread From: Hauke Mehrtens @ 2014-11-02 23:37 UTC (permalink / raw) To: linux-arm-kernel Hi, I am currently writing a driver for a PCIe host controller which does not support IO port access. My plan was to only provide IORESOURCE_MEM to pci_sys_data->resources, but then it allocates some generic IORESOURCE_IO memory in arch/arm/kernel/bios32.c:pcibios_init_resources(). This will work for the fist PCIe controller, but when the second controller gets registered I am getting this: "unable to allocate I/O port region (-16)". Is there an example for an arm driver for a PCIe controller which does not support IO port access? Should I change arch/arm/kernel/bios32.c in a way so that it would ignore the io port mem? Hauke ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: PCIe host controller without IO port access. 2014-11-02 23:37 ` Hauke Mehrtens @ 2014-11-03 17:41 ` Bjorn Helgaas -1 siblings, 0 replies; 10+ messages in thread From: Bjorn Helgaas @ 2014-11-03 17:41 UTC (permalink / raw) To: Hauke Mehrtens Cc: linux-arm-kernel@lists.infradead.org, linux-pci@vger.kernel.org, Rob Herring, Arnd Bergmann [+cc Rob (author of 3c5d1699887b), Arnd] On Sun, Nov 2, 2014 at 4:37 PM, Hauke Mehrtens <hauke@hauke-m.de> wrote: > Hi, > > I am currently writing a driver for a PCIe host controller which does > not support IO port access. > > My plan was to only provide IORESOURCE_MEM to pci_sys_data->resources, > but then it allocates some generic IORESOURCE_IO memory in > arch/arm/kernel/bios32.c:pcibios_init_resources(). This will work for > the fist PCIe controller, but when the second controller gets registered > I am getting this: "unable to allocate I/O port region (-16)". > > Is there an example for an arm driver for a PCIe controller which does > not support IO port access? > > Should I change arch/arm/kernel/bios32.c in a way so that it would > ignore the io port mem? I think this is a case of "all current platforms support an I/O space, so we'll set it up in the ARM PCI core." But I/O space is not (as far as I know) a required feature of PCI host bridges on ARM, so I suspect you should change arch/arm/kernel/bios32.c in some way to accomodate controllers with no I/O port space at all. Bjorn ^ permalink raw reply [flat|nested] 10+ messages in thread
* PCIe host controller without IO port access. @ 2014-11-03 17:41 ` Bjorn Helgaas 0 siblings, 0 replies; 10+ messages in thread From: Bjorn Helgaas @ 2014-11-03 17:41 UTC (permalink / raw) To: linux-arm-kernel [+cc Rob (author of 3c5d1699887b), Arnd] On Sun, Nov 2, 2014 at 4:37 PM, Hauke Mehrtens <hauke@hauke-m.de> wrote: > Hi, > > I am currently writing a driver for a PCIe host controller which does > not support IO port access. > > My plan was to only provide IORESOURCE_MEM to pci_sys_data->resources, > but then it allocates some generic IORESOURCE_IO memory in > arch/arm/kernel/bios32.c:pcibios_init_resources(). This will work for > the fist PCIe controller, but when the second controller gets registered > I am getting this: "unable to allocate I/O port region (-16)". > > Is there an example for an arm driver for a PCIe controller which does > not support IO port access? > > Should I change arch/arm/kernel/bios32.c in a way so that it would > ignore the io port mem? I think this is a case of "all current platforms support an I/O space, so we'll set it up in the ARM PCI core." But I/O space is not (as far as I know) a required feature of PCI host bridges on ARM, so I suspect you should change arch/arm/kernel/bios32.c in some way to accomodate controllers with no I/O port space at all. Bjorn ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: PCIe host controller without IO port access. 2014-11-03 17:41 ` Bjorn Helgaas @ 2014-11-03 22:00 ` Rob Herring -1 siblings, 0 replies; 10+ messages in thread From: Rob Herring @ 2014-11-03 22:00 UTC (permalink / raw) To: Bjorn Helgaas Cc: Hauke Mehrtens, linux-arm-kernel@lists.infradead.org, linux-pci@vger.kernel.org, Arnd Bergmann On Mon, Nov 3, 2014 at 11:41 AM, Bjorn Helgaas <bhelgaas@google.com> wrote: > [+cc Rob (author of 3c5d1699887b), Arnd] > > On Sun, Nov 2, 2014 at 4:37 PM, Hauke Mehrtens <hauke@hauke-m.de> wrote: >> Hi, >> >> I am currently writing a driver for a PCIe host controller which does >> not support IO port access. >> >> My plan was to only provide IORESOURCE_MEM to pci_sys_data->resources, >> but then it allocates some generic IORESOURCE_IO memory in >> arch/arm/kernel/bios32.c:pcibios_init_resources(). This will work for >> the fist PCIe controller, but when the second controller gets registered >> I am getting this: "unable to allocate I/O port region (-16)". >> >> Is there an example for an arm driver for a PCIe controller which does >> not support IO port access? >> >> Should I change arch/arm/kernel/bios32.c in a way so that it would >> ignore the io port mem? > > I think this is a case of "all current platforms support an I/O space, > so we'll set it up in the ARM PCI core." But I/O space is not (as far > as I know) a required feature of PCI host bridges on ARM, so I suspect > you should change arch/arm/kernel/bios32.c in some way to accomodate > controllers with no I/O port space at all. I guess we could ignore the error on request_resource or define a way to flag no i/o space. However, any new driver should be using all the new generic infrastructure. I think this code path should not even be called in that case. Rob ^ permalink raw reply [flat|nested] 10+ messages in thread
* PCIe host controller without IO port access. @ 2014-11-03 22:00 ` Rob Herring 0 siblings, 0 replies; 10+ messages in thread From: Rob Herring @ 2014-11-03 22:00 UTC (permalink / raw) To: linux-arm-kernel On Mon, Nov 3, 2014 at 11:41 AM, Bjorn Helgaas <bhelgaas@google.com> wrote: > [+cc Rob (author of 3c5d1699887b), Arnd] > > On Sun, Nov 2, 2014 at 4:37 PM, Hauke Mehrtens <hauke@hauke-m.de> wrote: >> Hi, >> >> I am currently writing a driver for a PCIe host controller which does >> not support IO port access. >> >> My plan was to only provide IORESOURCE_MEM to pci_sys_data->resources, >> but then it allocates some generic IORESOURCE_IO memory in >> arch/arm/kernel/bios32.c:pcibios_init_resources(). This will work for >> the fist PCIe controller, but when the second controller gets registered >> I am getting this: "unable to allocate I/O port region (-16)". >> >> Is there an example for an arm driver for a PCIe controller which does >> not support IO port access? >> >> Should I change arch/arm/kernel/bios32.c in a way so that it would >> ignore the io port mem? > > I think this is a case of "all current platforms support an I/O space, > so we'll set it up in the ARM PCI core." But I/O space is not (as far > as I know) a required feature of PCI host bridges on ARM, so I suspect > you should change arch/arm/kernel/bios32.c in some way to accomodate > controllers with no I/O port space at all. I guess we could ignore the error on request_resource or define a way to flag no i/o space. However, any new driver should be using all the new generic infrastructure. I think this code path should not even be called in that case. Rob ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: PCIe host controller without IO port access. 2014-11-03 22:00 ` Rob Herring @ 2014-11-03 23:08 ` Hauke Mehrtens -1 siblings, 0 replies; 10+ messages in thread From: Hauke Mehrtens @ 2014-11-03 23:08 UTC (permalink / raw) To: Rob Herring, Bjorn Helgaas Cc: linux-arm-kernel@lists.infradead.org, linux-pci@vger.kernel.org, Arnd Bergmann On 11/03/2014 11:00 PM, Rob Herring wrote: > On Mon, Nov 3, 2014 at 11:41 AM, Bjorn Helgaas <bhelgaas@google.com> wrote: >> [+cc Rob (author of 3c5d1699887b), Arnd] >> >> On Sun, Nov 2, 2014 at 4:37 PM, Hauke Mehrtens <hauke@hauke-m.de> wrote: >>> Hi, >>> >>> I am currently writing a driver for a PCIe host controller which does >>> not support IO port access. >>> >>> My plan was to only provide IORESOURCE_MEM to pci_sys_data->resources, >>> but then it allocates some generic IORESOURCE_IO memory in >>> arch/arm/kernel/bios32.c:pcibios_init_resources(). This will work for >>> the fist PCIe controller, but when the second controller gets registered >>> I am getting this: "unable to allocate I/O port region (-16)". >>> >>> Is there an example for an arm driver for a PCIe controller which does >>> not support IO port access? >>> >>> Should I change arch/arm/kernel/bios32.c in a way so that it would >>> ignore the io port mem? >> >> I think this is a case of "all current platforms support an I/O space, >> so we'll set it up in the ARM PCI core." But I/O space is not (as far >> as I know) a required feature of PCI host bridges on ARM, so I suspect >> you should change arch/arm/kernel/bios32.c in some way to accomodate >> controllers with no I/O port space at all. > > I guess we could ignore the error on request_resource or define a way > to flag no i/o space. However, any new driver should be using all the > new generic infrastructure. I think this code path should not even be > called in that case. Is there an example on how to use the new generic infrastructure? I used drivers/pci/host/pci-host-generic.c as a reference for my driver and thought it is using the recent infrastructure. I am working on a BCM5310X SoC and it has a PCIe controller without I/O port. As far as I know it is only intended to connect some Broadcom Wifi cards to the SoC. There are also some MIPS based router SoCs without I/O port support from other vendors. Hauke ^ permalink raw reply [flat|nested] 10+ messages in thread
* PCIe host controller without IO port access. @ 2014-11-03 23:08 ` Hauke Mehrtens 0 siblings, 0 replies; 10+ messages in thread From: Hauke Mehrtens @ 2014-11-03 23:08 UTC (permalink / raw) To: linux-arm-kernel On 11/03/2014 11:00 PM, Rob Herring wrote: > On Mon, Nov 3, 2014 at 11:41 AM, Bjorn Helgaas <bhelgaas@google.com> wrote: >> [+cc Rob (author of 3c5d1699887b), Arnd] >> >> On Sun, Nov 2, 2014 at 4:37 PM, Hauke Mehrtens <hauke@hauke-m.de> wrote: >>> Hi, >>> >>> I am currently writing a driver for a PCIe host controller which does >>> not support IO port access. >>> >>> My plan was to only provide IORESOURCE_MEM to pci_sys_data->resources, >>> but then it allocates some generic IORESOURCE_IO memory in >>> arch/arm/kernel/bios32.c:pcibios_init_resources(). This will work for >>> the fist PCIe controller, but when the second controller gets registered >>> I am getting this: "unable to allocate I/O port region (-16)". >>> >>> Is there an example for an arm driver for a PCIe controller which does >>> not support IO port access? >>> >>> Should I change arch/arm/kernel/bios32.c in a way so that it would >>> ignore the io port mem? >> >> I think this is a case of "all current platforms support an I/O space, >> so we'll set it up in the ARM PCI core." But I/O space is not (as far >> as I know) a required feature of PCI host bridges on ARM, so I suspect >> you should change arch/arm/kernel/bios32.c in some way to accomodate >> controllers with no I/O port space at all. > > I guess we could ignore the error on request_resource or define a way > to flag no i/o space. However, any new driver should be using all the > new generic infrastructure. I think this code path should not even be > called in that case. Is there an example on how to use the new generic infrastructure? I used drivers/pci/host/pci-host-generic.c as a reference for my driver and thought it is using the recent infrastructure. I am working on a BCM5310X SoC and it has a PCIe controller without I/O port. As far as I know it is only intended to connect some Broadcom Wifi cards to the SoC. There are also some MIPS based router SoCs without I/O port support from other vendors. Hauke ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: PCIe host controller without IO port access. 2014-11-03 23:08 ` Hauke Mehrtens @ 2014-11-04 10:19 ` Arnd Bergmann -1 siblings, 0 replies; 10+ messages in thread From: Arnd Bergmann @ 2014-11-04 10:19 UTC (permalink / raw) To: linux-arm-kernel Cc: Hauke Mehrtens, Rob Herring, Bjorn Helgaas, linux-pci@vger.kernel.org On Tuesday 04 November 2014 00:08:51 Hauke Mehrtens wrote: > On 11/03/2014 11:00 PM, Rob Herring wrote: > > On Mon, Nov 3, 2014 at 11:41 AM, Bjorn Helgaas <bhelgaas@google.com> wrote: > >> [+cc Rob (author of 3c5d1699887b), Arnd] > >> > >> On Sun, Nov 2, 2014 at 4:37 PM, Hauke Mehrtens <hauke@hauke-m.de> wrote: > >>> Hi, > >>> > >>> I am currently writing a driver for a PCIe host controller which does > >>> not support IO port access. > >>> > >>> My plan was to only provide IORESOURCE_MEM to pci_sys_data->resources, > >>> but then it allocates some generic IORESOURCE_IO memory in > >>> arch/arm/kernel/bios32.c:pcibios_init_resources(). This will work for > >>> the fist PCIe controller, but when the second controller gets registered > >>> I am getting this: "unable to allocate I/O port region (-16)". > >>> > >>> Is there an example for an arm driver for a PCIe controller which does > >>> not support IO port access? > >>> > >>> Should I change arch/arm/kernel/bios32.c in a way so that it would > >>> ignore the io port mem? > >> > >> I think this is a case of "all current platforms support an I/O space, > >> so we'll set it up in the ARM PCI core." But I/O space is not (as far > >> as I know) a required feature of PCI host bridges on ARM, so I suspect > >> you should change arch/arm/kernel/bios32.c in some way to accomodate > >> controllers with no I/O port space at all. > > > > I guess we could ignore the error on request_resource or define a way > > to flag no i/o space. However, any new driver should be using all the > > new generic infrastructure. I think this code path should not even be > > called in that case. For all I can tell this is a bug that was introduced by your 3c5d1699887 ("ARM: move PCI i/o resource setup into common code") (yes, I reviewed and merged it), which will work fine in one any of these cases - the PCI host driver adds an IORESOURCE_IO entry to its resources for each host it registers - there is only one PCI domain, so "busnr" is a unique value. > Is there an example on how to use the new generic infrastructure? I used > drivers/pci/host/pci-host-generic.c as a reference for my driver and > thought it is using the recent infrastructure. We're not there yet unfortunately, but it's getting close and with Lorenzo's latest patches we might be able to do it in 3.19. Using the common code for this will also make it much easier to have a shared implementation that works on both arm32 and mips, as well as arm64 if you ever need that. > I am working on a BCM5310X SoC and it has a PCIe controller without I/O > port. As far as I know it is only intended to connect some Broadcom Wifi > cards to the SoC. There are also some MIPS based router SoCs without I/O > port support from other vendors. It's definitely supposed to work without I/O space. I think you could work around this issue if you just add an empty I/O window for the host in sys->resources. I'm currently unsure what the correct fix would be for the ARM code, but as it's not currently causing problems for others, we might just keep it the way it is for now and migrate all controllers for DT based systems over to the generic implementation first. Arnd ^ permalink raw reply [flat|nested] 10+ messages in thread
* PCIe host controller without IO port access. @ 2014-11-04 10:19 ` Arnd Bergmann 0 siblings, 0 replies; 10+ messages in thread From: Arnd Bergmann @ 2014-11-04 10:19 UTC (permalink / raw) To: linux-arm-kernel On Tuesday 04 November 2014 00:08:51 Hauke Mehrtens wrote: > On 11/03/2014 11:00 PM, Rob Herring wrote: > > On Mon, Nov 3, 2014 at 11:41 AM, Bjorn Helgaas <bhelgaas@google.com> wrote: > >> [+cc Rob (author of 3c5d1699887b), Arnd] > >> > >> On Sun, Nov 2, 2014 at 4:37 PM, Hauke Mehrtens <hauke@hauke-m.de> wrote: > >>> Hi, > >>> > >>> I am currently writing a driver for a PCIe host controller which does > >>> not support IO port access. > >>> > >>> My plan was to only provide IORESOURCE_MEM to pci_sys_data->resources, > >>> but then it allocates some generic IORESOURCE_IO memory in > >>> arch/arm/kernel/bios32.c:pcibios_init_resources(). This will work for > >>> the fist PCIe controller, but when the second controller gets registered > >>> I am getting this: "unable to allocate I/O port region (-16)". > >>> > >>> Is there an example for an arm driver for a PCIe controller which does > >>> not support IO port access? > >>> > >>> Should I change arch/arm/kernel/bios32.c in a way so that it would > >>> ignore the io port mem? > >> > >> I think this is a case of "all current platforms support an I/O space, > >> so we'll set it up in the ARM PCI core." But I/O space is not (as far > >> as I know) a required feature of PCI host bridges on ARM, so I suspect > >> you should change arch/arm/kernel/bios32.c in some way to accomodate > >> controllers with no I/O port space at all. > > > > I guess we could ignore the error on request_resource or define a way > > to flag no i/o space. However, any new driver should be using all the > > new generic infrastructure. I think this code path should not even be > > called in that case. For all I can tell this is a bug that was introduced by your 3c5d1699887 ("ARM: move PCI i/o resource setup into common code") (yes, I reviewed and merged it), which will work fine in one any of these cases - the PCI host driver adds an IORESOURCE_IO entry to its resources for each host it registers - there is only one PCI domain, so "busnr" is a unique value. > Is there an example on how to use the new generic infrastructure? I used > drivers/pci/host/pci-host-generic.c as a reference for my driver and > thought it is using the recent infrastructure. We're not there yet unfortunately, but it's getting close and with Lorenzo's latest patches we might be able to do it in 3.19. Using the common code for this will also make it much easier to have a shared implementation that works on both arm32 and mips, as well as arm64 if you ever need that. > I am working on a BCM5310X SoC and it has a PCIe controller without I/O > port. As far as I know it is only intended to connect some Broadcom Wifi > cards to the SoC. There are also some MIPS based router SoCs without I/O > port support from other vendors. It's definitely supposed to work without I/O space. I think you could work around this issue if you just add an empty I/O window for the host in sys->resources. I'm currently unsure what the correct fix would be for the ARM code, but as it's not currently causing problems for others, we might just keep it the way it is for now and migrate all controllers for DT based systems over to the generic implementation first. Arnd ^ permalink raw reply [flat|nested] 10+ messages in thread
end of thread, other threads:[~2014-11-04 10:20 UTC | newest] Thread overview: 10+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2014-11-02 23:37 PCIe host controller without IO port access Hauke Mehrtens 2014-11-02 23:37 ` Hauke Mehrtens 2014-11-03 17:41 ` Bjorn Helgaas 2014-11-03 17:41 ` Bjorn Helgaas 2014-11-03 22:00 ` Rob Herring 2014-11-03 22:00 ` Rob Herring 2014-11-03 23:08 ` Hauke Mehrtens 2014-11-03 23:08 ` Hauke Mehrtens 2014-11-04 10:19 ` Arnd Bergmann 2014-11-04 10:19 ` Arnd Bergmann
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.