From: Hauke Mehrtens <hauke@hauke-m.de>
To: Rob Herring <robh@kernel.org>, Bjorn Helgaas <bhelgaas@google.com>
Cc: "linux-arm-kernel@lists.infradead.org"
<linux-arm-kernel@lists.infradead.org>,
"linux-pci@vger.kernel.org" <linux-pci@vger.kernel.org>,
Arnd Bergmann <arnd@arndb.de>
Subject: Re: PCIe host controller without IO port access.
Date: Tue, 04 Nov 2014 00:08:51 +0100 [thread overview]
Message-ID: <54580B03.1090700@hauke-m.de> (raw)
In-Reply-To: <CAL_JsqK0737hND4C0pkNXYwyuecm8K2k=LUMNDZvqdkg=H52NA@mail.gmail.com>
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
WARNING: multiple messages have this Message-ID (diff)
From: hauke@hauke-m.de (Hauke Mehrtens)
To: linux-arm-kernel@lists.infradead.org
Subject: PCIe host controller without IO port access.
Date: Tue, 04 Nov 2014 00:08:51 +0100 [thread overview]
Message-ID: <54580B03.1090700@hauke-m.de> (raw)
In-Reply-To: <CAL_JsqK0737hND4C0pkNXYwyuecm8K2k=LUMNDZvqdkg=H52NA@mail.gmail.com>
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
next prev parent reply other threads:[~2014-11-03 23:08 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
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 [this message]
2014-11-03 23:08 ` Hauke Mehrtens
2014-11-04 10:19 ` Arnd Bergmann
2014-11-04 10:19 ` 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=54580B03.1090700@hauke-m.de \
--to=hauke@hauke-m.de \
--cc=arnd@arndb.de \
--cc=bhelgaas@google.com \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-pci@vger.kernel.org \
--cc=robh@kernel.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.