Re: [PATCH v7 0/3] Add support for PCI in AArch64
On Wed, May 21, 2014 at 12:34:21PM +0100, Liviu Dudau wrote:
> On Wed, May 21, 2014 at 04:45:29PM +0530, Sunil Kovvuri wrote:
> > Hi Liviu,
> >
> > Sorry for the trouble.
> > I got why 'res->parent' is not set in my case.
> > Basically my SR-IOV device has fixed resources, so resources will not
> > be allocated/assigned and hence parent resource is not set.
> > I will move the resource claiming to host controller driver as a fixup
> > so that parent resource hierarchy is set.
> >
> > Thanks for the support.
>
> Glad you worked out the cause for the problem. I will still at to my list of
> ToDo things to investigate resource parenting with my patchset.
We recently fixed some things in this area on mvebu. It is important
to ensure that the aperature in the host driver has a proper resource
associated with it, or the PCI core won't create sub resources.
commit 2613ba480fb7b40c67eea36d03c9946977828623
Author: Jason Gunthorpe
Date: Wed Feb 12 15:57:08 2014 -0700
PCI: mvebu: Call request_resource() on the apertures
It is typical for host drivers to request a resource for the aperture; once
this is done the PCI core will properly populate resources for all BARs in
the system.
With this patch cat /proc/iomem will now show:
e000-efff : PCI MEM
e000-e00f : PCI Bus :01
e000-e001 : :01:00.0
Tested on Kirkwood.
Signed-off-by: Arnd Bergmann
Signed-off-by: Jason Gunthorpe
Signed-off-by: Bjorn Helgaas
Acked-by: Jason Cooper
diff --git a/drivers/pci/host/pci-mvebu.c b/drivers/pci/host/pci-mvebu.c
index 05e352889868..d3d1cfd51e09 100644
--- a/drivers/pci/host/pci-mvebu.c
+++ b/drivers/pci/host/pci-mvebu.c
@@ -101,7 +101,9 @@ struct mvebu_pcie {
struct mvebu_pcie_port *ports;
struct msi_chip *msi;
struct resource io;
+ char io_name[30];
struct resource realio;
+ char mem_name[30];
struct resource mem;
struct resource busn;
int nports;
@@ -672,10 +674,30 @@ static int mvebu_pcie_setup(int nr, struct pci_sys_data
*sys)
{
struct mvebu_pcie *pcie = sys_to_pcie(sys);
int i;
+ int domain = 0;
- if (resource_size(>realio) != 0)
+#ifdef CONFIG_PCI_DOMAINS
+ domain = sys->domain;
+#endif
+
+ snprintf(pcie->mem_name, sizeof(pcie->mem_name), "PCI MEM %04x",
+domain);
+ pcie->mem.name = pcie->mem_name;
+
+ snprintf(pcie->io_name, sizeof(pcie->io_name), "PCI I/O %04x", domain);
+ pcie->realio.name = pcie->io_name;
+
+ if (request_resource(_resource, >mem))
+ return 0;
+
+ if (resource_size(>realio) != 0) {
+ if (request_resource(_resource, >realio)) {
+ release_resource(>mem);
+ return 0;
+ }
pci_add_resource_offset(>resources, >realio,
sys->io_offset);
+ }
pci_add_resource_offset(>resources, >mem, sys->mem_offset);
pci_add_resource(>resources, >busn);
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v7 0/3] Add support for PCI in AArch64
On Wed, May 21, 2014 at 04:45:29PM +0530, Sunil Kovvuri wrote:
> Hi Liviu,
>
> Sorry for the trouble.
> I got why 'res->parent' is not set in my case.
> Basically my SR-IOV device has fixed resources, so resources will not
> be allocated/assigned and hence parent resource is not set.
> I will move the resource claiming to host controller driver as a fixup
> so that parent resource hierarchy is set.
>
> Thanks for the support.
Glad you worked out the cause for the problem. I will still at to my list of
ToDo things to investigate resource parenting with my patchset.
Best regards,
Liviu
>
> Regards,
> Sunil.
>
>
> On Fri, May 16, 2014 at 11:12 PM, Sunil Kovvuri
> wrote:
> > Hi Liviu,
> >
> > Issue may not be only with SR-IOV resources.
> >
> > I am not an expert with Linux PCI core. But i am trying to understand
> > how even for a non SR-IOV capable device's resource, gets a parent
> > associated with it.
> >
> > When a PCI device driver calls pci_enable_device() which inturn calls
> > 'arch/arm64/kernel/pci.c' pcibios_enable_device() which uses Linux PCI core
> > API 'pci_enable_resources'. This API checks 'res->parent' for all
> > valid resources
> > before enabling them, otherwise it fails.
> > if (!r->parent) {
> > dev_err(>dev, "device not available "
> > "(can't reserve %pR)\n", r);
> > return -EINVAL;
> > }
> >
> > Can you please let me know where this hierarchy is being set for
> > 'pcibios_enable_resources' to work.
> >
> > I could only find request_resource() API which sets the parent and
> > pci_claim_resource() uses this.
> >
> > Thanks,
> > Sunil.
> >
> > On Fri, May 16, 2014 at 6:54 PM, Liviu Dudau wrote:
> >> Hi Sunil,
> >>
> >> On Fri, May 16, 2014 at 11:33:04AM +0100, Sunil Kovvuri wrote:
> >>> Hi Liviu,
> >>>
> >>> I am using your ARM64 PCIe patches to write a PCIe host controller
> >>> driver for our SOC. I am facing an issue with SR-IOV capable device.
> >>>
> >>> Consider an PCI Express endpoint connected to a PCI Express
> >>> Root Port. The PCI Express endpoint provides PCI-SIG SR-IOV
> >>> capabilities with a single physical function and a large number
> >>> of virtual functions. The Root Port contains a pci-pci bridge in
> >>> between it and the SR-IOV device.
> >>>
> >>> When the SR-IOV capable device's driver tries to enable sriov
> >>> (pci_enable_sriov()) it fails to create/add PCI device for each
> >>> virtual function reporting "not enough MMIO resources for SR-IOV".
> >>>
> >>> In sriov_enable() (drivers/pci/iov.c)
> >>>
> >>> 296for (i = 0; i < PCI_SRIOV_NUM_BARS; i++) {
> >>> 297 bars |= (1 << (i + PCI_IOV_RESOURCES));
> >>> 298 res = dev->resource + PCI_IOV_RESOURCES + i;
> >>> 299 if (res->parent)
> >>> 300 nres++;
> >>> 301 }
> >>> 302 if (nres != iov->nres) {
> >>> 303 dev_err(>dev, "not enough MMIO resources for
> >>> SR-IOV\n");
> >>> 304 return -ENOMEM;
> >>> 305 }
> >>>
> >>> Here its checking if physical function's IOV resource has a parent or not.
> >>> Which is pci-pci bridge in this case. Otherwise it doesn't consider
> >>> that resource.
> >>>
> >>> Added below api to your patch.
> >>> This will try to claim a resource while creating a PCI device which
> >>> inturn sets 'res->parent'.
> >>>
> >>> Let me know if this is okay.
> >>>
> >>> diff --git a/arch/arm64/kernel/pci.c b/arch/arm64/kernel/pci.c
> >>> index 9f29c9a..fbfb48f 100644
> >>> --- a/arch/arm64/kernel/pci.c
> >>> +++ b/arch/arm64/kernel/pci.c
> >>> @@ -125,6 +125,21 @@ resource_size_t pcibios_align_resource(void
> >>> *data, const struct resource *res,
> >>> return res->start;
> >>> }
> >>>
> >>> +int pcibios_add_device(struct pci_dev *pdev)
> >>> +{
> >>> +unsigned int i, type_mask = IORESOURCE_IO | IORESOURCE_MEM;
> >>> +struct resource *res;
> >>> +
> >>> +for (i = 0; i < PCI_NUM_RESOURCES; i++) {
> >>> +res = >resource[i];
> >>> +if (res->parent || !(res->flags & type_mask))
> >>> +continue;
> >>> +pci_claim_resource(pdev, i);
> >>> +}
> >>> +
> >>>
> >>
> >> I would like not to have to add your patch in this file as I am trying to
> >> remove it entirely. I don't have an SR-IOV capable device in my setup so
> >> I am not able to debug your problem, but could you have a go and try to
> >> figure out why the SR-IOV resources do not get a parent associated with
> >> when they get created?
> >>
> >> Many thanks,
> >> Liviu
> >>
> >>
> >> --
> >>
> >> | I would like to |
> >> | fix the world, |
> >> | but they're not |
> >> | giving me the |
> >> \ source code! /
> >> ---
> >> ¯\_(ツ)_/¯
> >>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-pci" in
> the
Re: [PATCH v7 0/3] Add support for PCI in AArch64
Hi Liviu,
Sorry for the trouble.
I got why 'res->parent' is not set in my case.
Basically my SR-IOV device has fixed resources, so resources will not
be allocated/assigned and hence parent resource is not set.
I will move the resource claiming to host controller driver as a fixup
so that parent resource hierarchy is set.
Thanks for the support.
Regards,
Sunil.
On Fri, May 16, 2014 at 11:12 PM, Sunil Kovvuri wrote:
> Hi Liviu,
>
> Issue may not be only with SR-IOV resources.
>
> I am not an expert with Linux PCI core. But i am trying to understand
> how even for a non SR-IOV capable device's resource, gets a parent
> associated with it.
>
> When a PCI device driver calls pci_enable_device() which inturn calls
> 'arch/arm64/kernel/pci.c' pcibios_enable_device() which uses Linux PCI core
> API 'pci_enable_resources'. This API checks 'res->parent' for all
> valid resources
> before enabling them, otherwise it fails.
> if (!r->parent) {
> dev_err(>dev, "device not available "
> "(can't reserve %pR)\n", r);
> return -EINVAL;
> }
>
> Can you please let me know where this hierarchy is being set for
> 'pcibios_enable_resources' to work.
>
> I could only find request_resource() API which sets the parent and
> pci_claim_resource() uses this.
>
> Thanks,
> Sunil.
>
> On Fri, May 16, 2014 at 6:54 PM, Liviu Dudau wrote:
>> Hi Sunil,
>>
>> On Fri, May 16, 2014 at 11:33:04AM +0100, Sunil Kovvuri wrote:
>>> Hi Liviu,
>>>
>>> I am using your ARM64 PCIe patches to write a PCIe host controller
>>> driver for our SOC. I am facing an issue with SR-IOV capable device.
>>>
>>> Consider an PCI Express endpoint connected to a PCI Express
>>> Root Port. The PCI Express endpoint provides PCI-SIG SR-IOV
>>> capabilities with a single physical function and a large number
>>> of virtual functions. The Root Port contains a pci-pci bridge in
>>> between it and the SR-IOV device.
>>>
>>> When the SR-IOV capable device's driver tries to enable sriov
>>> (pci_enable_sriov()) it fails to create/add PCI device for each
>>> virtual function reporting "not enough MMIO resources for SR-IOV".
>>>
>>> In sriov_enable() (drivers/pci/iov.c)
>>>
>>> 296for (i = 0; i < PCI_SRIOV_NUM_BARS; i++) {
>>> 297 bars |= (1 << (i + PCI_IOV_RESOURCES));
>>> 298 res = dev->resource + PCI_IOV_RESOURCES + i;
>>> 299 if (res->parent)
>>> 300 nres++;
>>> 301 }
>>> 302 if (nres != iov->nres) {
>>> 303 dev_err(>dev, "not enough MMIO resources for
>>> SR-IOV\n");
>>> 304 return -ENOMEM;
>>> 305 }
>>>
>>> Here its checking if physical function's IOV resource has a parent or not.
>>> Which is pci-pci bridge in this case. Otherwise it doesn't consider
>>> that resource.
>>>
>>> Added below api to your patch.
>>> This will try to claim a resource while creating a PCI device which
>>> inturn sets 'res->parent'.
>>>
>>> Let me know if this is okay.
>>>
>>> diff --git a/arch/arm64/kernel/pci.c b/arch/arm64/kernel/pci.c
>>> index 9f29c9a..fbfb48f 100644
>>> --- a/arch/arm64/kernel/pci.c
>>> +++ b/arch/arm64/kernel/pci.c
>>> @@ -125,6 +125,21 @@ resource_size_t pcibios_align_resource(void
>>> *data, const struct resource *res,
>>> return res->start;
>>> }
>>>
>>> +int pcibios_add_device(struct pci_dev *pdev)
>>> +{
>>> +unsigned int i, type_mask = IORESOURCE_IO | IORESOURCE_MEM;
>>> +struct resource *res;
>>> +
>>> +for (i = 0; i < PCI_NUM_RESOURCES; i++) {
>>> +res = >resource[i];
>>> +if (res->parent || !(res->flags & type_mask))
>>> +continue;
>>> +pci_claim_resource(pdev, i);
>>> +}
>>> +
>>>
>>
>> I would like not to have to add your patch in this file as I am trying to
>> remove it entirely. I don't have an SR-IOV capable device in my setup so
>> I am not able to debug your problem, but could you have a go and try to
>> figure out why the SR-IOV resources do not get a parent associated with
>> when they get created?
>>
>> Many thanks,
>> Liviu
>>
>>
>> --
>>
>> | I would like to |
>> | fix the world, |
>> | but they're not |
>> | giving me the |
>> \ source code! /
>> ---
>> ¯\_(ツ)_/¯
>>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v7 0/3] Add support for PCI in AArch64
Hi Liviu,
Sorry for the trouble.
I got why 'res-parent' is not set in my case.
Basically my SR-IOV device has fixed resources, so resources will not
be allocated/assigned and hence parent resource is not set.
I will move the resource claiming to host controller driver as a fixup
so that parent resource hierarchy is set.
Thanks for the support.
Regards,
Sunil.
On Fri, May 16, 2014 at 11:12 PM, Sunil Kovvuri sunil.kovv...@gmail.com wrote:
Hi Liviu,
Issue may not be only with SR-IOV resources.
I am not an expert with Linux PCI core. But i am trying to understand
how even for a non SR-IOV capable device's resource, gets a parent
associated with it.
When a PCI device driver calls pci_enable_device() which inturn calls
'arch/arm64/kernel/pci.c' pcibios_enable_device() which uses Linux PCI core
API 'pci_enable_resources'. This API checks 'res-parent' for all
valid resources
before enabling them, otherwise it fails.
if (!r-parent) {
dev_err(dev-dev, device not available
(can't reserve %pR)\n, r);
return -EINVAL;
}
Can you please let me know where this hierarchy is being set for
'pcibios_enable_resources' to work.
I could only find request_resource() API which sets the parent and
pci_claim_resource() uses this.
Thanks,
Sunil.
On Fri, May 16, 2014 at 6:54 PM, Liviu Dudau liviu.du...@arm.com wrote:
Hi Sunil,
On Fri, May 16, 2014 at 11:33:04AM +0100, Sunil Kovvuri wrote:
Hi Liviu,
I am using your ARM64 PCIe patches to write a PCIe host controller
driver for our SOC. I am facing an issue with SR-IOV capable device.
Consider an PCI Express endpoint connected to a PCI Express
Root Port. The PCI Express endpoint provides PCI-SIG SR-IOV
capabilities with a single physical function and a large number
of virtual functions. The Root Port contains a pci-pci bridge in
between it and the SR-IOV device.
When the SR-IOV capable device's driver tries to enable sriov
(pci_enable_sriov()) it fails to create/add PCI device for each
virtual function reporting not enough MMIO resources for SR-IOV.
In sriov_enable() (drivers/pci/iov.c)
296for (i = 0; i PCI_SRIOV_NUM_BARS; i++) {
297 bars |= (1 (i + PCI_IOV_RESOURCES));
298 res = dev-resource + PCI_IOV_RESOURCES + i;
299 if (res-parent)
300 nres++;
301 }
302 if (nres != iov-nres) {
303 dev_err(dev-dev, not enough MMIO resources for
SR-IOV\n);
304 return -ENOMEM;
305 }
Here its checking if physical function's IOV resource has a parent or not.
Which is pci-pci bridge in this case. Otherwise it doesn't consider
that resource.
Added below api to your patch.
This will try to claim a resource while creating a PCI device which
inturn sets 'res-parent'.
Let me know if this is okay.
diff --git a/arch/arm64/kernel/pci.c b/arch/arm64/kernel/pci.c
index 9f29c9a..fbfb48f 100644
--- a/arch/arm64/kernel/pci.c
+++ b/arch/arm64/kernel/pci.c
@@ -125,6 +125,21 @@ resource_size_t pcibios_align_resource(void
*data, const struct resource *res,
return res-start;
}
+int pcibios_add_device(struct pci_dev *pdev)
+{
+unsigned int i, type_mask = IORESOURCE_IO | IORESOURCE_MEM;
+struct resource *res;
+
+for (i = 0; i PCI_NUM_RESOURCES; i++) {
+res = pdev-resource[i];
+if (res-parent || !(res-flags type_mask))
+continue;
+pci_claim_resource(pdev, i);
+}
+
I would like not to have to add your patch in this file as I am trying to
remove it entirely. I don't have an SR-IOV capable device in my setup so
I am not able to debug your problem, but could you have a go and try to
figure out why the SR-IOV resources do not get a parent associated with
when they get created?
Many thanks,
Liviu
--
| I would like to |
| fix the world, |
| but they're not |
| giving me the |
\ source code! /
---
¯\_(ツ)_/¯
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v7 0/3] Add support for PCI in AArch64
On Wed, May 21, 2014 at 04:45:29PM +0530, Sunil Kovvuri wrote:
Hi Liviu,
Sorry for the trouble.
I got why 'res-parent' is not set in my case.
Basically my SR-IOV device has fixed resources, so resources will not
be allocated/assigned and hence parent resource is not set.
I will move the resource claiming to host controller driver as a fixup
so that parent resource hierarchy is set.
Thanks for the support.
Glad you worked out the cause for the problem. I will still at to my list of
ToDo things to investigate resource parenting with my patchset.
Best regards,
Liviu
Regards,
Sunil.
On Fri, May 16, 2014 at 11:12 PM, Sunil Kovvuri sunil.kovv...@gmail.com
wrote:
Hi Liviu,
Issue may not be only with SR-IOV resources.
I am not an expert with Linux PCI core. But i am trying to understand
how even for a non SR-IOV capable device's resource, gets a parent
associated with it.
When a PCI device driver calls pci_enable_device() which inturn calls
'arch/arm64/kernel/pci.c' pcibios_enable_device() which uses Linux PCI core
API 'pci_enable_resources'. This API checks 'res-parent' for all
valid resources
before enabling them, otherwise it fails.
if (!r-parent) {
dev_err(dev-dev, device not available
(can't reserve %pR)\n, r);
return -EINVAL;
}
Can you please let me know where this hierarchy is being set for
'pcibios_enable_resources' to work.
I could only find request_resource() API which sets the parent and
pci_claim_resource() uses this.
Thanks,
Sunil.
On Fri, May 16, 2014 at 6:54 PM, Liviu Dudau liviu.du...@arm.com wrote:
Hi Sunil,
On Fri, May 16, 2014 at 11:33:04AM +0100, Sunil Kovvuri wrote:
Hi Liviu,
I am using your ARM64 PCIe patches to write a PCIe host controller
driver for our SOC. I am facing an issue with SR-IOV capable device.
Consider an PCI Express endpoint connected to a PCI Express
Root Port. The PCI Express endpoint provides PCI-SIG SR-IOV
capabilities with a single physical function and a large number
of virtual functions. The Root Port contains a pci-pci bridge in
between it and the SR-IOV device.
When the SR-IOV capable device's driver tries to enable sriov
(pci_enable_sriov()) it fails to create/add PCI device for each
virtual function reporting not enough MMIO resources for SR-IOV.
In sriov_enable() (drivers/pci/iov.c)
296for (i = 0; i PCI_SRIOV_NUM_BARS; i++) {
297 bars |= (1 (i + PCI_IOV_RESOURCES));
298 res = dev-resource + PCI_IOV_RESOURCES + i;
299 if (res-parent)
300 nres++;
301 }
302 if (nres != iov-nres) {
303 dev_err(dev-dev, not enough MMIO resources for
SR-IOV\n);
304 return -ENOMEM;
305 }
Here its checking if physical function's IOV resource has a parent or not.
Which is pci-pci bridge in this case. Otherwise it doesn't consider
that resource.
Added below api to your patch.
This will try to claim a resource while creating a PCI device which
inturn sets 'res-parent'.
Let me know if this is okay.
diff --git a/arch/arm64/kernel/pci.c b/arch/arm64/kernel/pci.c
index 9f29c9a..fbfb48f 100644
--- a/arch/arm64/kernel/pci.c
+++ b/arch/arm64/kernel/pci.c
@@ -125,6 +125,21 @@ resource_size_t pcibios_align_resource(void
*data, const struct resource *res,
return res-start;
}
+int pcibios_add_device(struct pci_dev *pdev)
+{
+unsigned int i, type_mask = IORESOURCE_IO | IORESOURCE_MEM;
+struct resource *res;
+
+for (i = 0; i PCI_NUM_RESOURCES; i++) {
+res = pdev-resource[i];
+if (res-parent || !(res-flags type_mask))
+continue;
+pci_claim_resource(pdev, i);
+}
+
I would like not to have to add your patch in this file as I am trying to
remove it entirely. I don't have an SR-IOV capable device in my setup so
I am not able to debug your problem, but could you have a go and try to
figure out why the SR-IOV resources do not get a parent associated with
when they get created?
Many thanks,
Liviu
--
| I would like to |
| fix the world, |
| but they're not |
| giving me the |
\ source code! /
---
¯\_(ツ)_/¯
--
To unsubscribe from this list: send the line unsubscribe linux-pci in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
--
---
.oooO
( )
\ ( Oooo.
\_) ( )
) /
(_/
One small step
for me ...
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to
Re: [PATCH v7 0/3] Add support for PCI in AArch64
On Wed, May 21, 2014 at 12:34:21PM +0100, Liviu Dudau wrote:
On Wed, May 21, 2014 at 04:45:29PM +0530, Sunil Kovvuri wrote:
Hi Liviu,
Sorry for the trouble.
I got why 'res-parent' is not set in my case.
Basically my SR-IOV device has fixed resources, so resources will not
be allocated/assigned and hence parent resource is not set.
I will move the resource claiming to host controller driver as a fixup
so that parent resource hierarchy is set.
Thanks for the support.
Glad you worked out the cause for the problem. I will still at to my list of
ToDo things to investigate resource parenting with my patchset.
We recently fixed some things in this area on mvebu. It is important
to ensure that the aperature in the host driver has a proper resource
associated with it, or the PCI core won't create sub resources.
commit 2613ba480fb7b40c67eea36d03c9946977828623
Author: Jason Gunthorpe jguntho...@obsidianresearch.com
Date: Wed Feb 12 15:57:08 2014 -0700
PCI: mvebu: Call request_resource() on the apertures
It is typical for host drivers to request a resource for the aperture; once
this is done the PCI core will properly populate resources for all BARs in
the system.
With this patch cat /proc/iomem will now show:
e000-efff : PCI MEM
e000-e00f : PCI Bus :01
e000-e001 : :01:00.0
Tested on Kirkwood.
Signed-off-by: Arnd Bergmann a...@arndb.de
Signed-off-by: Jason Gunthorpe jguntho...@obsidianresearch.com
Signed-off-by: Bjorn Helgaas bhelg...@google.com
Acked-by: Jason Cooper ja...@lakedaemon.net
diff --git a/drivers/pci/host/pci-mvebu.c b/drivers/pci/host/pci-mvebu.c
index 05e352889868..d3d1cfd51e09 100644
--- a/drivers/pci/host/pci-mvebu.c
+++ b/drivers/pci/host/pci-mvebu.c
@@ -101,7 +101,9 @@ struct mvebu_pcie {
struct mvebu_pcie_port *ports;
struct msi_chip *msi;
struct resource io;
+ char io_name[30];
struct resource realio;
+ char mem_name[30];
struct resource mem;
struct resource busn;
int nports;
@@ -672,10 +674,30 @@ static int mvebu_pcie_setup(int nr, struct pci_sys_data
*sys)
{
struct mvebu_pcie *pcie = sys_to_pcie(sys);
int i;
+ int domain = 0;
- if (resource_size(pcie-realio) != 0)
+#ifdef CONFIG_PCI_DOMAINS
+ domain = sys-domain;
+#endif
+
+ snprintf(pcie-mem_name, sizeof(pcie-mem_name), PCI MEM %04x,
+domain);
+ pcie-mem.name = pcie-mem_name;
+
+ snprintf(pcie-io_name, sizeof(pcie-io_name), PCI I/O %04x, domain);
+ pcie-realio.name = pcie-io_name;
+
+ if (request_resource(iomem_resource, pcie-mem))
+ return 0;
+
+ if (resource_size(pcie-realio) != 0) {
+ if (request_resource(ioport_resource, pcie-realio)) {
+ release_resource(pcie-mem);
+ return 0;
+ }
pci_add_resource_offset(sys-resources, pcie-realio,
sys-io_offset);
+ }
pci_add_resource_offset(sys-resources, pcie-mem, sys-mem_offset);
pci_add_resource(sys-resources, pcie-busn);
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v7 0/3] Add support for PCI in AArch64
On Tue, May 20, 2014 at 2:14 PM, Arnd Bergmann wrote:
> On Tuesday 20 May 2014 09:52:33 Sunil Kovvuri wrote:
>> >> In sriov_enable() (drivers/pci/iov.c)
>> >>
>> >> 296for (i = 0; i < PCI_SRIOV_NUM_BARS; i++) {
>> >> 297 bars |= (1 << (i + PCI_IOV_RESOURCES));
>> >> 298 res = dev->resource + PCI_IOV_RESOURCES + i;
>> >> 299 if (res->parent)
>> >> 300 nres++;
>> >> 301 }
>> >> 302 if (nres != iov->nres) {
>> >> 303 dev_err(>dev, "not enough MMIO resources for
>> >> SR-IOV\n");
>> >> 304 return -ENOMEM;
>> >> 305 }
>> >>
>> >> Here its checking if physical function's IOV resource has a parent or not.
>> >> Which is pci-pci bridge in this case. Otherwise it doesn't consider
>> >> that resource.
>> >>
>> >> Added below api to your patch.
>> >> This will try to claim a resource while creating a PCI device which
>> >> inturn sets 'res->parent'.
>> >
>> > This looks like the wrong approach. The PCI host controller should
>> > really have been registered with the root 'iomem_resource' during
>> > the probe of the host controller.
>> >
>> I didn't get this, if a SR-IOV device is connected to a PCI-PCI bridge
>> and inturn bridge connected to root port. Then the parent bus is not root,
>> but the bridge. The issue is either hierarchy should not be checked for
>> SR-IOV resources or someone should set the hierarchy (i.e parent resources).
>
> Ah, I misunderstood the problem, I thought the PCI core was complaining
> about lack of space in the resources, not about a lack of BARs.
>
> It seems there is code like yours in a couple of architectures, but they
> only claim the resources of bridges, not the actual devices as you
> seem to be doing. Can you check if the x86 version of
> pcibios_allocate_bus_resources() does the trick for you? Maybe we can
> turn that into a generic helper.
>
Thanks for the suggestion. Will try that once.
FYI, IA64 architecture does claim resources for devices as well.
arch/ia64/pci/pci.c 'pcibios_fixup_device_resources()'
Thanks,
Sunil.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v7 0/3] Add support for PCI in AArch64
On Tuesday 20 May 2014 09:52:33 Sunil Kovvuri wrote:
> >> In sriov_enable() (drivers/pci/iov.c)
> >>
> >> 296for (i = 0; i < PCI_SRIOV_NUM_BARS; i++) {
> >> 297 bars |= (1 << (i + PCI_IOV_RESOURCES));
> >> 298 res = dev->resource + PCI_IOV_RESOURCES + i;
> >> 299 if (res->parent)
> >> 300 nres++;
> >> 301 }
> >> 302 if (nres != iov->nres) {
> >> 303 dev_err(>dev, "not enough MMIO resources for
> >> SR-IOV\n");
> >> 304 return -ENOMEM;
> >> 305 }
> >>
> >> Here its checking if physical function's IOV resource has a parent or not.
> >> Which is pci-pci bridge in this case. Otherwise it doesn't consider
> >> that resource.
> >>
> >> Added below api to your patch.
> >> This will try to claim a resource while creating a PCI device which
> >> inturn sets 'res->parent'.
> >
> > This looks like the wrong approach. The PCI host controller should
> > really have been registered with the root 'iomem_resource' during
> > the probe of the host controller.
> >
> I didn't get this, if a SR-IOV device is connected to a PCI-PCI bridge
> and inturn bridge connected to root port. Then the parent bus is not root,
> but the bridge. The issue is either hierarchy should not be checked for
> SR-IOV resources or someone should set the hierarchy (i.e parent resources).
Ah, I misunderstood the problem, I thought the PCI core was complaining
about lack of space in the resources, not about a lack of BARs.
It seems there is code like yours in a couple of architectures, but they
only claim the resources of bridges, not the actual devices as you
seem to be doing. Can you check if the x86 version of
pcibios_allocate_bus_resources() does the trick for you? Maybe we can
turn that into a generic helper.
Arnd
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v7 0/3] Add support for PCI in AArch64
On Tuesday 20 May 2014 09:52:33 Sunil Kovvuri wrote:
In sriov_enable() (drivers/pci/iov.c)
296for (i = 0; i PCI_SRIOV_NUM_BARS; i++) {
297 bars |= (1 (i + PCI_IOV_RESOURCES));
298 res = dev-resource + PCI_IOV_RESOURCES + i;
299 if (res-parent)
300 nres++;
301 }
302 if (nres != iov-nres) {
303 dev_err(dev-dev, not enough MMIO resources for
SR-IOV\n);
304 return -ENOMEM;
305 }
Here its checking if physical function's IOV resource has a parent or not.
Which is pci-pci bridge in this case. Otherwise it doesn't consider
that resource.
Added below api to your patch.
This will try to claim a resource while creating a PCI device which
inturn sets 'res-parent'.
This looks like the wrong approach. The PCI host controller should
really have been registered with the root 'iomem_resource' during
the probe of the host controller.
I didn't get this, if a SR-IOV device is connected to a PCI-PCI bridge
and inturn bridge connected to root port. Then the parent bus is not root,
but the bridge. The issue is either hierarchy should not be checked for
SR-IOV resources or someone should set the hierarchy (i.e parent resources).
Ah, I misunderstood the problem, I thought the PCI core was complaining
about lack of space in the resources, not about a lack of BARs.
It seems there is code like yours in a couple of architectures, but they
only claim the resources of bridges, not the actual devices as you
seem to be doing. Can you check if the x86 version of
pcibios_allocate_bus_resources() does the trick for you? Maybe we can
turn that into a generic helper.
Arnd
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v7 0/3] Add support for PCI in AArch64
On Tue, May 20, 2014 at 2:14 PM, Arnd Bergmann a...@arndb.de wrote:
On Tuesday 20 May 2014 09:52:33 Sunil Kovvuri wrote:
In sriov_enable() (drivers/pci/iov.c)
296for (i = 0; i PCI_SRIOV_NUM_BARS; i++) {
297 bars |= (1 (i + PCI_IOV_RESOURCES));
298 res = dev-resource + PCI_IOV_RESOURCES + i;
299 if (res-parent)
300 nres++;
301 }
302 if (nres != iov-nres) {
303 dev_err(dev-dev, not enough MMIO resources for
SR-IOV\n);
304 return -ENOMEM;
305 }
Here its checking if physical function's IOV resource has a parent or not.
Which is pci-pci bridge in this case. Otherwise it doesn't consider
that resource.
Added below api to your patch.
This will try to claim a resource while creating a PCI device which
inturn sets 'res-parent'.
This looks like the wrong approach. The PCI host controller should
really have been registered with the root 'iomem_resource' during
the probe of the host controller.
I didn't get this, if a SR-IOV device is connected to a PCI-PCI bridge
and inturn bridge connected to root port. Then the parent bus is not root,
but the bridge. The issue is either hierarchy should not be checked for
SR-IOV resources or someone should set the hierarchy (i.e parent resources).
Ah, I misunderstood the problem, I thought the PCI core was complaining
about lack of space in the resources, not about a lack of BARs.
It seems there is code like yours in a couple of architectures, but they
only claim the resources of bridges, not the actual devices as you
seem to be doing. Can you check if the x86 version of
pcibios_allocate_bus_resources() does the trick for you? Maybe we can
turn that into a generic helper.
Thanks for the suggestion. Will try that once.
FYI, IA64 architecture does claim resources for devices as well.
arch/ia64/pci/pci.c 'pcibios_fixup_device_resources()'
Thanks,
Sunil.
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v7 0/3] Add support for PCI in AArch64
On Mon, May 19, 2014 at 6:31 PM, Arnd Bergmann wrote:
> On Friday 16 May 2014 16:03:04 Sunil Kovvuri wrote:
>> When the SR-IOV capable device's driver tries to enable sriov
>> (pci_enable_sriov()) it fails to create/add PCI device for each
>> virtual function reporting "not enough MMIO resources for SR-IOV".
>
> I assume you have checked that there is indeed enough MMIO space
> available, right?
>
Yes, i have checked for enough MMIO space multiple times.
>> In sriov_enable() (drivers/pci/iov.c)
>>
>> 296for (i = 0; i < PCI_SRIOV_NUM_BARS; i++) {
>> 297 bars |= (1 << (i + PCI_IOV_RESOURCES));
>> 298 res = dev->resource + PCI_IOV_RESOURCES + i;
>> 299 if (res->parent)
>> 300 nres++;
>> 301 }
>> 302 if (nres != iov->nres) {
>> 303 dev_err(>dev, "not enough MMIO resources for
>> SR-IOV\n");
>> 304 return -ENOMEM;
>> 305 }
>>
>> Here its checking if physical function's IOV resource has a parent or not.
>> Which is pci-pci bridge in this case. Otherwise it doesn't consider
>> that resource.
>>
>> Added below api to your patch.
>> This will try to claim a resource while creating a PCI device which
>> inturn sets 'res->parent'.
>
> This looks like the wrong approach. The PCI host controller should
> really have been registered with the root 'iomem_resource' during
> the probe of the host controller.
>
> Arnd
I didn't get this, if a SR-IOV device is connected to a PCI-PCI bridge
and inturn bridge connected to root port. Then the parent bus is not root,
but the bridge. The issue is either hierarchy should not be checked for
SR-IOV resources or someone should set the hierarchy (i.e parent resources).
Regards,
Sunil.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v7 0/3] Add support for PCI in AArch64
On Friday 16 May 2014 16:03:04 Sunil Kovvuri wrote:
> When the SR-IOV capable device's driver tries to enable sriov
> (pci_enable_sriov()) it fails to create/add PCI device for each
> virtual function reporting "not enough MMIO resources for SR-IOV".
I assume you have checked that there is indeed enough MMIO space
available, right?
> In sriov_enable() (drivers/pci/iov.c)
>
> 296for (i = 0; i < PCI_SRIOV_NUM_BARS; i++) {
> 297 bars |= (1 << (i + PCI_IOV_RESOURCES));
> 298 res = dev->resource + PCI_IOV_RESOURCES + i;
> 299 if (res->parent)
> 300 nres++;
> 301 }
> 302 if (nres != iov->nres) {
> 303 dev_err(>dev, "not enough MMIO resources for
> SR-IOV\n");
> 304 return -ENOMEM;
> 305 }
>
> Here its checking if physical function's IOV resource has a parent or not.
> Which is pci-pci bridge in this case. Otherwise it doesn't consider
> that resource.
>
> Added below api to your patch.
> This will try to claim a resource while creating a PCI device which
> inturn sets 'res->parent'.
This looks like the wrong approach. The PCI host controller should
really have been registered with the root 'iomem_resource' during
the probe of the host controller.
Arnd
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v7 0/3] Add support for PCI in AArch64
On Mon, May 19, 2014 at 6:31 PM, Arnd Bergmann a...@arndb.de wrote:
On Friday 16 May 2014 16:03:04 Sunil Kovvuri wrote:
When the SR-IOV capable device's driver tries to enable sriov
(pci_enable_sriov()) it fails to create/add PCI device for each
virtual function reporting not enough MMIO resources for SR-IOV.
I assume you have checked that there is indeed enough MMIO space
available, right?
Yes, i have checked for enough MMIO space multiple times.
In sriov_enable() (drivers/pci/iov.c)
296for (i = 0; i PCI_SRIOV_NUM_BARS; i++) {
297 bars |= (1 (i + PCI_IOV_RESOURCES));
298 res = dev-resource + PCI_IOV_RESOURCES + i;
299 if (res-parent)
300 nres++;
301 }
302 if (nres != iov-nres) {
303 dev_err(dev-dev, not enough MMIO resources for
SR-IOV\n);
304 return -ENOMEM;
305 }
Here its checking if physical function's IOV resource has a parent or not.
Which is pci-pci bridge in this case. Otherwise it doesn't consider
that resource.
Added below api to your patch.
This will try to claim a resource while creating a PCI device which
inturn sets 'res-parent'.
This looks like the wrong approach. The PCI host controller should
really have been registered with the root 'iomem_resource' during
the probe of the host controller.
Arnd
I didn't get this, if a SR-IOV device is connected to a PCI-PCI bridge
and inturn bridge connected to root port. Then the parent bus is not root,
but the bridge. The issue is either hierarchy should not be checked for
SR-IOV resources or someone should set the hierarchy (i.e parent resources).
Regards,
Sunil.
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v7 0/3] Add support for PCI in AArch64
On Friday 16 May 2014 16:03:04 Sunil Kovvuri wrote:
When the SR-IOV capable device's driver tries to enable sriov
(pci_enable_sriov()) it fails to create/add PCI device for each
virtual function reporting not enough MMIO resources for SR-IOV.
I assume you have checked that there is indeed enough MMIO space
available, right?
In sriov_enable() (drivers/pci/iov.c)
296for (i = 0; i PCI_SRIOV_NUM_BARS; i++) {
297 bars |= (1 (i + PCI_IOV_RESOURCES));
298 res = dev-resource + PCI_IOV_RESOURCES + i;
299 if (res-parent)
300 nres++;
301 }
302 if (nres != iov-nres) {
303 dev_err(dev-dev, not enough MMIO resources for
SR-IOV\n);
304 return -ENOMEM;
305 }
Here its checking if physical function's IOV resource has a parent or not.
Which is pci-pci bridge in this case. Otherwise it doesn't consider
that resource.
Added below api to your patch.
This will try to claim a resource while creating a PCI device which
inturn sets 'res-parent'.
This looks like the wrong approach. The PCI host controller should
really have been registered with the root 'iomem_resource' during
the probe of the host controller.
Arnd
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v7 0/3] Add support for PCI in AArch64
Hi Liviu,
Issue may not be only with SR-IOV resources.
I am not an expert with Linux PCI core. But i am trying to understand
how even for a non SR-IOV capable device's resource, gets a parent
associated with it.
When a PCI device driver calls pci_enable_device() which inturn calls
'arch/arm64/kernel/pci.c' pcibios_enable_device() which uses Linux PCI core
API 'pci_enable_resources'. This API checks 'res->parent' for all
valid resources
before enabling them, otherwise it fails.
if (!r->parent) {
dev_err(>dev, "device not available "
"(can't reserve %pR)\n", r);
return -EINVAL;
}
Can you please let me know where this hierarchy is being set for
'pcibios_enable_resources' to work.
I could only find request_resource() API which sets the parent and
pci_claim_resource() uses this.
Thanks,
Sunil.
On Fri, May 16, 2014 at 6:54 PM, Liviu Dudau wrote:
> Hi Sunil,
>
> On Fri, May 16, 2014 at 11:33:04AM +0100, Sunil Kovvuri wrote:
>> Hi Liviu,
>>
>> I am using your ARM64 PCIe patches to write a PCIe host controller
>> driver for our SOC. I am facing an issue with SR-IOV capable device.
>>
>> Consider an PCI Express endpoint connected to a PCI Express
>> Root Port. The PCI Express endpoint provides PCI-SIG SR-IOV
>> capabilities with a single physical function and a large number
>> of virtual functions. The Root Port contains a pci-pci bridge in
>> between it and the SR-IOV device.
>>
>> When the SR-IOV capable device's driver tries to enable sriov
>> (pci_enable_sriov()) it fails to create/add PCI device for each
>> virtual function reporting "not enough MMIO resources for SR-IOV".
>>
>> In sriov_enable() (drivers/pci/iov.c)
>>
>> 296for (i = 0; i < PCI_SRIOV_NUM_BARS; i++) {
>> 297 bars |= (1 << (i + PCI_IOV_RESOURCES));
>> 298 res = dev->resource + PCI_IOV_RESOURCES + i;
>> 299 if (res->parent)
>> 300 nres++;
>> 301 }
>> 302 if (nres != iov->nres) {
>> 303 dev_err(>dev, "not enough MMIO resources for
>> SR-IOV\n");
>> 304 return -ENOMEM;
>> 305 }
>>
>> Here its checking if physical function's IOV resource has a parent or not.
>> Which is pci-pci bridge in this case. Otherwise it doesn't consider
>> that resource.
>>
>> Added below api to your patch.
>> This will try to claim a resource while creating a PCI device which
>> inturn sets 'res->parent'.
>>
>> Let me know if this is okay.
>>
>> diff --git a/arch/arm64/kernel/pci.c b/arch/arm64/kernel/pci.c
>> index 9f29c9a..fbfb48f 100644
>> --- a/arch/arm64/kernel/pci.c
>> +++ b/arch/arm64/kernel/pci.c
>> @@ -125,6 +125,21 @@ resource_size_t pcibios_align_resource(void
>> *data, const struct resource *res,
>> return res->start;
>> }
>>
>> +int pcibios_add_device(struct pci_dev *pdev)
>> +{
>> +unsigned int i, type_mask = IORESOURCE_IO | IORESOURCE_MEM;
>> +struct resource *res;
>> +
>> +for (i = 0; i < PCI_NUM_RESOURCES; i++) {
>> +res = >resource[i];
>> +if (res->parent || !(res->flags & type_mask))
>> +continue;
>> +pci_claim_resource(pdev, i);
>> +}
>> +
>>
>
> I would like not to have to add your patch in this file as I am trying to
> remove it entirely. I don't have an SR-IOV capable device in my setup so
> I am not able to debug your problem, but could you have a go and try to
> figure out why the SR-IOV resources do not get a parent associated with
> when they get created?
>
> Many thanks,
> Liviu
>
>
> --
>
> | I would like to |
> | fix the world, |
> | but they're not |
> | giving me the |
> \ source code! /
> ---
> ¯\_(ツ)_/¯
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v7 0/3] Add support for PCI in AArch64
Hi Sunil,
On Fri, May 16, 2014 at 11:33:04AM +0100, Sunil Kovvuri wrote:
> Hi Liviu,
>
> I am using your ARM64 PCIe patches to write a PCIe host controller
> driver for our SOC. I am facing an issue with SR-IOV capable device.
>
> Consider an PCI Express endpoint connected to a PCI Express
> Root Port. The PCI Express endpoint provides PCI-SIG SR-IOV
> capabilities with a single physical function and a large number
> of virtual functions. The Root Port contains a pci-pci bridge in
> between it and the SR-IOV device.
>
> When the SR-IOV capable device's driver tries to enable sriov
> (pci_enable_sriov()) it fails to create/add PCI device for each
> virtual function reporting "not enough MMIO resources for SR-IOV".
>
> In sriov_enable() (drivers/pci/iov.c)
>
> 296for (i = 0; i < PCI_SRIOV_NUM_BARS; i++) {
> 297 bars |= (1 << (i + PCI_IOV_RESOURCES));
> 298 res = dev->resource + PCI_IOV_RESOURCES + i;
> 299 if (res->parent)
> 300 nres++;
> 301 }
> 302 if (nres != iov->nres) {
> 303 dev_err(>dev, "not enough MMIO resources for
> SR-IOV\n");
> 304 return -ENOMEM;
> 305 }
>
> Here its checking if physical function's IOV resource has a parent or not.
> Which is pci-pci bridge in this case. Otherwise it doesn't consider
> that resource.
>
> Added below api to your patch.
> This will try to claim a resource while creating a PCI device which
> inturn sets 'res->parent'.
>
> Let me know if this is okay.
>
> diff --git a/arch/arm64/kernel/pci.c b/arch/arm64/kernel/pci.c
> index 9f29c9a..fbfb48f 100644
> --- a/arch/arm64/kernel/pci.c
> +++ b/arch/arm64/kernel/pci.c
> @@ -125,6 +125,21 @@ resource_size_t pcibios_align_resource(void
> *data, const struct resource *res,
> return res->start;
> }
>
> +int pcibios_add_device(struct pci_dev *pdev)
> +{
> +unsigned int i, type_mask = IORESOURCE_IO | IORESOURCE_MEM;
> +struct resource *res;
> +
> +for (i = 0; i < PCI_NUM_RESOURCES; i++) {
> +res = >resource[i];
> +if (res->parent || !(res->flags & type_mask))
> +continue;
> +pci_claim_resource(pdev, i);
> +}
> +
>
I would like not to have to add your patch in this file as I am trying to
remove it entirely. I don't have an SR-IOV capable device in my setup so
I am not able to debug your problem, but could you have a go and try to
figure out why the SR-IOV resources do not get a parent associated with
when they get created?
Many thanks,
Liviu
--
| I would like to |
| fix the world, |
| but they're not |
| giving me the |
\ source code! /
---
¯\_(ツ)_/¯
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v7 0/3] Add support for PCI in AArch64
Hi Liviu,
I am using your ARM64 PCIe patches to write a PCIe host controller
driver for our SOC. I am facing an issue with SR-IOV capable device.
Consider an PCI Express endpoint connected to a PCI Express
Root Port. The PCI Express endpoint provides PCI-SIG SR-IOV
capabilities with a single physical function and a large number
of virtual functions. The Root Port contains a pci-pci bridge in
between it and the SR-IOV device.
When the SR-IOV capable device's driver tries to enable sriov
(pci_enable_sriov()) it fails to create/add PCI device for each
virtual function reporting "not enough MMIO resources for SR-IOV".
In sriov_enable() (drivers/pci/iov.c)
296for (i = 0; i < PCI_SRIOV_NUM_BARS; i++) {
297 bars |= (1 << (i + PCI_IOV_RESOURCES));
298 res = dev->resource + PCI_IOV_RESOURCES + i;
299 if (res->parent)
300 nres++;
301 }
302 if (nres != iov->nres) {
303 dev_err(>dev, "not enough MMIO resources for
SR-IOV\n");
304 return -ENOMEM;
305 }
Here its checking if physical function's IOV resource has a parent or not.
Which is pci-pci bridge in this case. Otherwise it doesn't consider
that resource.
Added below api to your patch.
This will try to claim a resource while creating a PCI device which
inturn sets 'res->parent'.
Let me know if this is okay.
diff --git a/arch/arm64/kernel/pci.c b/arch/arm64/kernel/pci.c
index 9f29c9a..fbfb48f 100644
--- a/arch/arm64/kernel/pci.c
+++ b/arch/arm64/kernel/pci.c
@@ -125,6 +125,21 @@ resource_size_t pcibios_align_resource(void
*data, const struct resource *res,
return res->start;
}
+int pcibios_add_device(struct pci_dev *pdev)
+{
+unsigned int i, type_mask = IORESOURCE_IO | IORESOURCE_MEM;
+struct resource *res;
+
+for (i = 0; i < PCI_NUM_RESOURCES; i++) {
+res = >resource[i];
+if (res->parent || !(res->flags & type_mask))
+continue;
+pci_claim_resource(pdev, i);
+}
+
On Fri, Mar 14, 2014 at 9:04 PM, Liviu Dudau wrote:
> Hi,
>
> This patch adds support for PCI to AArch64. It is based on my v7 patch
> that adds support for creating generic host bridge structure from
> device tree. With that in place, I was able to boot a platform that
> has PCIe host bridge support and use a PCIe network card.
>
> I have dropped the RFC tag from the subject as I now have the ambitious goal
> of trying to get it mainlined.
>
> Changes from v6:
> - Guard the pci_domain_nr() inline implementation with #ifdef CONFIG_PCI as
> to avoid conflict with default empty version present in
> include/linux/pci.h.
> Thanks to Jingoo Han for catching this.
>
> Changes from v5:
> - Removed pcibios_fixup_bridge_ranges() as the week default version is fine.
> - Removed the ALIGN() call in pcibios_align_resource()
> - Stopped exporting pcibios_align_resource()
>
> Changes from v4:
> - Fixed the pci_domain_nr() implementation for arm64. Now we use
> find_pci_host_bride() to find the host bridge before we retrieve
> the domain number.
>
> Changes from v3:
> - Added Acks accumulated so far ;)
> - Still carrying Catalin's patch for moving the PCI_IO_BASE until it
> lands in linux-next or mainline, in order to ease applying the series
>
> Changes from v2:
> - Implement an arch specific version of pci_register_io_range() and
> pci_address_to_pio().
> - Return 1 from pci_proc_domain().
>
> Changes from v1:
> - Added Catalin's patch for moving the PCI_IO_BASE location and extend
> its size to 16MB
> - Integrated Arnd's version of pci_ioremap_io that uses a bitmap for
> keeping track of assigned IO space and returns an io_offset. At the
> moment the code is added in arch/arm64 but it can be moved in drivers/pci.
> - Added a fix for the generic ioport_map() function when
> !CONFIG_GENERIC_IOMAP
> as suggested by Arnd.
>
> v6 thread here: https://lkml.org/lkml/2014/3/5/41
> v5 thread here: https://lkml.org/lkml/2014/3/4/307
> v4 thread here: https://lkml.org/lkml/2014/3/3/298
> v3 thread here: https://lkml.org/lkml/2014/2/28/211
> v2 thread here: https://lkml.org/lkml/2014/2/27/255
> v1 thread here: https://lkml.org/lkml/2014/2/3/389
>
>
> The API used is different from the one used by ARM architecture. There is
> no pci_common_init_dev() function and no hw_pci structure, as that is no
> longer needed. Once the last signature is added to the legal agreement, I
> will post the host bridge driver code that I am using. Meanwhile, here
> is an example of what the probe function looks like, posted as an example:
>
> static int myhostbridge_probe(struct platform_device *pdev)
> {
> int err;
> struct device_node *dev;
> struct pci_host_bridge *bridge;
> struct myhostbridge_port *pp;
> resource_size_t lastbus;
>
> dev = pdev->dev.of_node;
>
>
Re: [PATCH v7 0/3] Add support for PCI in AArch64
Hi Liviu,
I am using your ARM64 PCIe patches to write a PCIe host controller
driver for our SOC. I am facing an issue with SR-IOV capable device.
Consider an PCI Express endpoint connected to a PCI Express
Root Port. The PCI Express endpoint provides PCI-SIG SR-IOV
capabilities with a single physical function and a large number
of virtual functions. The Root Port contains a pci-pci bridge in
between it and the SR-IOV device.
When the SR-IOV capable device's driver tries to enable sriov
(pci_enable_sriov()) it fails to create/add PCI device for each
virtual function reporting not enough MMIO resources for SR-IOV.
In sriov_enable() (drivers/pci/iov.c)
296for (i = 0; i PCI_SRIOV_NUM_BARS; i++) {
297 bars |= (1 (i + PCI_IOV_RESOURCES));
298 res = dev-resource + PCI_IOV_RESOURCES + i;
299 if (res-parent)
300 nres++;
301 }
302 if (nres != iov-nres) {
303 dev_err(dev-dev, not enough MMIO resources for
SR-IOV\n);
304 return -ENOMEM;
305 }
Here its checking if physical function's IOV resource has a parent or not.
Which is pci-pci bridge in this case. Otherwise it doesn't consider
that resource.
Added below api to your patch.
This will try to claim a resource while creating a PCI device which
inturn sets 'res-parent'.
Let me know if this is okay.
diff --git a/arch/arm64/kernel/pci.c b/arch/arm64/kernel/pci.c
index 9f29c9a..fbfb48f 100644
--- a/arch/arm64/kernel/pci.c
+++ b/arch/arm64/kernel/pci.c
@@ -125,6 +125,21 @@ resource_size_t pcibios_align_resource(void
*data, const struct resource *res,
return res-start;
}
+int pcibios_add_device(struct pci_dev *pdev)
+{
+unsigned int i, type_mask = IORESOURCE_IO | IORESOURCE_MEM;
+struct resource *res;
+
+for (i = 0; i PCI_NUM_RESOURCES; i++) {
+res = pdev-resource[i];
+if (res-parent || !(res-flags type_mask))
+continue;
+pci_claim_resource(pdev, i);
+}
+
On Fri, Mar 14, 2014 at 9:04 PM, Liviu Dudau liviu.du...@arm.com wrote:
Hi,
This patch adds support for PCI to AArch64. It is based on my v7 patch
that adds support for creating generic host bridge structure from
device tree. With that in place, I was able to boot a platform that
has PCIe host bridge support and use a PCIe network card.
I have dropped the RFC tag from the subject as I now have the ambitious goal
of trying to get it mainlined.
Changes from v6:
- Guard the pci_domain_nr() inline implementation with #ifdef CONFIG_PCI as
to avoid conflict with default empty version present in
include/linux/pci.h.
Thanks to Jingoo Han for catching this.
Changes from v5:
- Removed pcibios_fixup_bridge_ranges() as the week default version is fine.
- Removed the ALIGN() call in pcibios_align_resource()
- Stopped exporting pcibios_align_resource()
Changes from v4:
- Fixed the pci_domain_nr() implementation for arm64. Now we use
find_pci_host_bride() to find the host bridge before we retrieve
the domain number.
Changes from v3:
- Added Acks accumulated so far ;)
- Still carrying Catalin's patch for moving the PCI_IO_BASE until it
lands in linux-next or mainline, in order to ease applying the series
Changes from v2:
- Implement an arch specific version of pci_register_io_range() and
pci_address_to_pio().
- Return 1 from pci_proc_domain().
Changes from v1:
- Added Catalin's patch for moving the PCI_IO_BASE location and extend
its size to 16MB
- Integrated Arnd's version of pci_ioremap_io that uses a bitmap for
keeping track of assigned IO space and returns an io_offset. At the
moment the code is added in arch/arm64 but it can be moved in drivers/pci.
- Added a fix for the generic ioport_map() function when
!CONFIG_GENERIC_IOMAP
as suggested by Arnd.
v6 thread here: https://lkml.org/lkml/2014/3/5/41
v5 thread here: https://lkml.org/lkml/2014/3/4/307
v4 thread here: https://lkml.org/lkml/2014/3/3/298
v3 thread here: https://lkml.org/lkml/2014/2/28/211
v2 thread here: https://lkml.org/lkml/2014/2/27/255
v1 thread here: https://lkml.org/lkml/2014/2/3/389
The API used is different from the one used by ARM architecture. There is
no pci_common_init_dev() function and no hw_pci structure, as that is no
longer needed. Once the last signature is added to the legal agreement, I
will post the host bridge driver code that I am using. Meanwhile, here
is an example of what the probe function looks like, posted as an example:
static int myhostbridge_probe(struct platform_device *pdev)
{
int err;
struct device_node *dev;
struct pci_host_bridge *bridge;
struct myhostbridge_port *pp;
resource_size_t lastbus;
dev = pdev-dev.of_node;
if (!of_device_is_available(dev)) {
Re: [PATCH v7 0/3] Add support for PCI in AArch64
Hi Sunil,
On Fri, May 16, 2014 at 11:33:04AM +0100, Sunil Kovvuri wrote:
Hi Liviu,
I am using your ARM64 PCIe patches to write a PCIe host controller
driver for our SOC. I am facing an issue with SR-IOV capable device.
Consider an PCI Express endpoint connected to a PCI Express
Root Port. The PCI Express endpoint provides PCI-SIG SR-IOV
capabilities with a single physical function and a large number
of virtual functions. The Root Port contains a pci-pci bridge in
between it and the SR-IOV device.
When the SR-IOV capable device's driver tries to enable sriov
(pci_enable_sriov()) it fails to create/add PCI device for each
virtual function reporting not enough MMIO resources for SR-IOV.
In sriov_enable() (drivers/pci/iov.c)
296for (i = 0; i PCI_SRIOV_NUM_BARS; i++) {
297 bars |= (1 (i + PCI_IOV_RESOURCES));
298 res = dev-resource + PCI_IOV_RESOURCES + i;
299 if (res-parent)
300 nres++;
301 }
302 if (nres != iov-nres) {
303 dev_err(dev-dev, not enough MMIO resources for
SR-IOV\n);
304 return -ENOMEM;
305 }
Here its checking if physical function's IOV resource has a parent or not.
Which is pci-pci bridge in this case. Otherwise it doesn't consider
that resource.
Added below api to your patch.
This will try to claim a resource while creating a PCI device which
inturn sets 'res-parent'.
Let me know if this is okay.
diff --git a/arch/arm64/kernel/pci.c b/arch/arm64/kernel/pci.c
index 9f29c9a..fbfb48f 100644
--- a/arch/arm64/kernel/pci.c
+++ b/arch/arm64/kernel/pci.c
@@ -125,6 +125,21 @@ resource_size_t pcibios_align_resource(void
*data, const struct resource *res,
return res-start;
}
+int pcibios_add_device(struct pci_dev *pdev)
+{
+unsigned int i, type_mask = IORESOURCE_IO | IORESOURCE_MEM;
+struct resource *res;
+
+for (i = 0; i PCI_NUM_RESOURCES; i++) {
+res = pdev-resource[i];
+if (res-parent || !(res-flags type_mask))
+continue;
+pci_claim_resource(pdev, i);
+}
+
I would like not to have to add your patch in this file as I am trying to
remove it entirely. I don't have an SR-IOV capable device in my setup so
I am not able to debug your problem, but could you have a go and try to
figure out why the SR-IOV resources do not get a parent associated with
when they get created?
Many thanks,
Liviu
--
| I would like to |
| fix the world, |
| but they're not |
| giving me the |
\ source code! /
---
¯\_(ツ)_/¯
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v7 0/3] Add support for PCI in AArch64
Hi Liviu,
Issue may not be only with SR-IOV resources.
I am not an expert with Linux PCI core. But i am trying to understand
how even for a non SR-IOV capable device's resource, gets a parent
associated with it.
When a PCI device driver calls pci_enable_device() which inturn calls
'arch/arm64/kernel/pci.c' pcibios_enable_device() which uses Linux PCI core
API 'pci_enable_resources'. This API checks 'res-parent' for all
valid resources
before enabling them, otherwise it fails.
if (!r-parent) {
dev_err(dev-dev, device not available
(can't reserve %pR)\n, r);
return -EINVAL;
}
Can you please let me know where this hierarchy is being set for
'pcibios_enable_resources' to work.
I could only find request_resource() API which sets the parent and
pci_claim_resource() uses this.
Thanks,
Sunil.
On Fri, May 16, 2014 at 6:54 PM, Liviu Dudau liviu.du...@arm.com wrote:
Hi Sunil,
On Fri, May 16, 2014 at 11:33:04AM +0100, Sunil Kovvuri wrote:
Hi Liviu,
I am using your ARM64 PCIe patches to write a PCIe host controller
driver for our SOC. I am facing an issue with SR-IOV capable device.
Consider an PCI Express endpoint connected to a PCI Express
Root Port. The PCI Express endpoint provides PCI-SIG SR-IOV
capabilities with a single physical function and a large number
of virtual functions. The Root Port contains a pci-pci bridge in
between it and the SR-IOV device.
When the SR-IOV capable device's driver tries to enable sriov
(pci_enable_sriov()) it fails to create/add PCI device for each
virtual function reporting not enough MMIO resources for SR-IOV.
In sriov_enable() (drivers/pci/iov.c)
296for (i = 0; i PCI_SRIOV_NUM_BARS; i++) {
297 bars |= (1 (i + PCI_IOV_RESOURCES));
298 res = dev-resource + PCI_IOV_RESOURCES + i;
299 if (res-parent)
300 nres++;
301 }
302 if (nres != iov-nres) {
303 dev_err(dev-dev, not enough MMIO resources for
SR-IOV\n);
304 return -ENOMEM;
305 }
Here its checking if physical function's IOV resource has a parent or not.
Which is pci-pci bridge in this case. Otherwise it doesn't consider
that resource.
Added below api to your patch.
This will try to claim a resource while creating a PCI device which
inturn sets 'res-parent'.
Let me know if this is okay.
diff --git a/arch/arm64/kernel/pci.c b/arch/arm64/kernel/pci.c
index 9f29c9a..fbfb48f 100644
--- a/arch/arm64/kernel/pci.c
+++ b/arch/arm64/kernel/pci.c
@@ -125,6 +125,21 @@ resource_size_t pcibios_align_resource(void
*data, const struct resource *res,
return res-start;
}
+int pcibios_add_device(struct pci_dev *pdev)
+{
+unsigned int i, type_mask = IORESOURCE_IO | IORESOURCE_MEM;
+struct resource *res;
+
+for (i = 0; i PCI_NUM_RESOURCES; i++) {
+res = pdev-resource[i];
+if (res-parent || !(res-flags type_mask))
+continue;
+pci_claim_resource(pdev, i);
+}
+
I would like not to have to add your patch in this file as I am trying to
remove it entirely. I don't have an SR-IOV capable device in my setup so
I am not able to debug your problem, but could you have a go and try to
figure out why the SR-IOV resources do not get a parent associated with
when they get created?
Many thanks,
Liviu
--
| I would like to |
| fix the world, |
| but they're not |
| giving me the |
\ source code! /
---
¯\_(ツ)_/¯
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v7 0/3] Add support for PCI in AArch64
On 24 April 2014 02:02, Tanmay Inamdar wrote:
> Hello Sandeepa,
>
> On Tue, Apr 22, 2014 at 4:50 AM, Sandeepa Prabhu
> wrote:
>> On 22 April 2014 15:41, Liviu Dudau wrote:
>>> On Tue, Apr 22, 2014 at 09:58:28AM +0100, Sandeepa Prabhu wrote:
On 14 March 2014 21:04, Liviu Dudau wrote:
> Hi,
>
> This patch adds support for PCI to AArch64. It is based on my v7 patch
> that adds support for creating generic host bridge structure from
> device tree. With that in place, I was able to boot a platform that
> has PCIe host bridge support and use a PCIe network card.
Hi Liviu,
Are these patches (including your other patchset for device tree host
bridge support ) available on a public git repo I can checkout from?
>>>
>>> Yes, I have pushed them into git://linux-arm.org/linux-ld.git
>> Thanks Liviu,
>> Just to understand, is the X-gene PCIe
>> (https://lwn.net/Articles/589733/) verified using the same patchset?
>
> Yes. V5 version of X-Gene PCIe patches have verified Liviu's patchset
> on X-Gene platform.
Thanks Tanmay!
>
>>
>> ~Sandeepa
>>>
>>> Best regards,
>>> Liviu
>>>
Thanks,
~Sandeepa
>
> I have dropped the RFC tag from the subject as I now have the ambitious
> goal
> of trying to get it mainlined.
>
> Changes from v6:
> - Guard the pci_domain_nr() inline implementation with #ifdef
> CONFIG_PCI as
> to avoid conflict with default empty version present in
> include/linux/pci.h.
> Thanks to Jingoo Han for catching this.
>
> Changes from v5:
> - Removed pcibios_fixup_bridge_ranges() as the week default version is
> fine.
> - Removed the ALIGN() call in pcibios_align_resource()
> - Stopped exporting pcibios_align_resource()
>
> Changes from v4:
> - Fixed the pci_domain_nr() implementation for arm64. Now we use
> find_pci_host_bride() to find the host bridge before we retrieve
> the domain number.
>
> Changes from v3:
> - Added Acks accumulated so far ;)
> - Still carrying Catalin's patch for moving the PCI_IO_BASE until it
> lands in linux-next or mainline, in order to ease applying the series
>
> Changes from v2:
> - Implement an arch specific version of pci_register_io_range() and
> pci_address_to_pio().
> - Return 1 from pci_proc_domain().
>
> Changes from v1:
> - Added Catalin's patch for moving the PCI_IO_BASE location and extend
> its size to 16MB
> - Integrated Arnd's version of pci_ioremap_io that uses a bitmap for
> keeping track of assigned IO space and returns an io_offset. At the
> moment the code is added in arch/arm64 but it can be moved in
> drivers/pci.
> - Added a fix for the generic ioport_map() function when
> !CONFIG_GENERIC_IOMAP
> as suggested by Arnd.
>
> v6 thread here: https://lkml.org/lkml/2014/3/5/41
> v5 thread here: https://lkml.org/lkml/2014/3/4/307
> v4 thread here: https://lkml.org/lkml/2014/3/3/298
> v3 thread here: https://lkml.org/lkml/2014/2/28/211
> v2 thread here: https://lkml.org/lkml/2014/2/27/255
> v1 thread here: https://lkml.org/lkml/2014/2/3/389
>
>
> The API used is different from the one used by ARM architecture. There is
> no pci_common_init_dev() function and no hw_pci structure, as that is no
> longer needed. Once the last signature is added to the legal agreement, I
> will post the host bridge driver code that I am using. Meanwhile, here
> is an example of what the probe function looks like, posted as an
> example:
>
> static int myhostbridge_probe(struct platform_device *pdev)
> {
> int err;
> struct device_node *dev;
> struct pci_host_bridge *bridge;
> struct myhostbridge_port *pp;
> resource_size_t lastbus;
>
> dev = pdev->dev.of_node;
>
> if (!of_device_is_available(dev)) {
> pr_warn("%s: disabled\n", dev->full_name);
> return -ENODEV;
> }
>
> pp = kzalloc(sizeof(struct myhostbridge_port), GFP_KERNEL);
> if (!pp)
> return -ENOMEM;
>
> bridge = of_create_pci_host_bridge(>dev,
> _ops, pp);
> if (IS_ERR(bridge)) {
> err = PTR_ERR(bridge);
> goto bridge_create_fail;
> }
>
> err = myhostbridge_setup(bridge->bus);
> if (err)
> goto bridge_setup_fail;
>
> /* We always enable PCI domains and we keep domain 0 backward
> * compatible in /proc for video cards
> */
> pci_add_flags(PCI_ENABLE_PROC_DOMAINS);
>
Re: [PATCH v7 0/3] Add support for PCI in AArch64
Hello Sandeepa,
On Tue, Apr 22, 2014 at 4:50 AM, Sandeepa Prabhu
wrote:
> On 22 April 2014 15:41, Liviu Dudau wrote:
>> On Tue, Apr 22, 2014 at 09:58:28AM +0100, Sandeepa Prabhu wrote:
>>> On 14 March 2014 21:04, Liviu Dudau wrote:
>>> > Hi,
>>> >
>>> > This patch adds support for PCI to AArch64. It is based on my v7 patch
>>> > that adds support for creating generic host bridge structure from
>>> > device tree. With that in place, I was able to boot a platform that
>>> > has PCIe host bridge support and use a PCIe network card.
>>> Hi Liviu,
>>>
>>> Are these patches (including your other patchset for device tree host
>>> bridge support ) available on a public git repo I can checkout from?
>>
>> Yes, I have pushed them into git://linux-arm.org/linux-ld.git
> Thanks Liviu,
> Just to understand, is the X-gene PCIe
> (https://lwn.net/Articles/589733/) verified using the same patchset?
Yes. V5 version of X-Gene PCIe patches have verified Liviu's patchset
on X-Gene platform.
>
> ~Sandeepa
>>
>> Best regards,
>> Liviu
>>
>>>
>>> Thanks,
>>> ~Sandeepa
>>>
>>> >
>>> > I have dropped the RFC tag from the subject as I now have the ambitious
>>> > goal
>>> > of trying to get it mainlined.
>>> >
>>> > Changes from v6:
>>> > - Guard the pci_domain_nr() inline implementation with #ifdef
>>> > CONFIG_PCI as
>>> > to avoid conflict with default empty version present in
>>> > include/linux/pci.h.
>>> > Thanks to Jingoo Han for catching this.
>>> >
>>> > Changes from v5:
>>> > - Removed pcibios_fixup_bridge_ranges() as the week default version is
>>> > fine.
>>> > - Removed the ALIGN() call in pcibios_align_resource()
>>> > - Stopped exporting pcibios_align_resource()
>>> >
>>> > Changes from v4:
>>> > - Fixed the pci_domain_nr() implementation for arm64. Now we use
>>> > find_pci_host_bride() to find the host bridge before we retrieve
>>> > the domain number.
>>> >
>>> > Changes from v3:
>>> > - Added Acks accumulated so far ;)
>>> > - Still carrying Catalin's patch for moving the PCI_IO_BASE until it
>>> > lands in linux-next or mainline, in order to ease applying the series
>>> >
>>> > Changes from v2:
>>> > - Implement an arch specific version of pci_register_io_range() and
>>> > pci_address_to_pio().
>>> > - Return 1 from pci_proc_domain().
>>> >
>>> > Changes from v1:
>>> > - Added Catalin's patch for moving the PCI_IO_BASE location and extend
>>> > its size to 16MB
>>> > - Integrated Arnd's version of pci_ioremap_io that uses a bitmap for
>>> > keeping track of assigned IO space and returns an io_offset. At the
>>> > moment the code is added in arch/arm64 but it can be moved in
>>> > drivers/pci.
>>> > - Added a fix for the generic ioport_map() function when
>>> > !CONFIG_GENERIC_IOMAP
>>> > as suggested by Arnd.
>>> >
>>> > v6 thread here: https://lkml.org/lkml/2014/3/5/41
>>> > v5 thread here: https://lkml.org/lkml/2014/3/4/307
>>> > v4 thread here: https://lkml.org/lkml/2014/3/3/298
>>> > v3 thread here: https://lkml.org/lkml/2014/2/28/211
>>> > v2 thread here: https://lkml.org/lkml/2014/2/27/255
>>> > v1 thread here: https://lkml.org/lkml/2014/2/3/389
>>> >
>>> >
>>> > The API used is different from the one used by ARM architecture. There is
>>> > no pci_common_init_dev() function and no hw_pci structure, as that is no
>>> > longer needed. Once the last signature is added to the legal agreement, I
>>> > will post the host bridge driver code that I am using. Meanwhile, here
>>> > is an example of what the probe function looks like, posted as an example:
>>> >
>>> > static int myhostbridge_probe(struct platform_device *pdev)
>>> > {
>>> > int err;
>>> > struct device_node *dev;
>>> > struct pci_host_bridge *bridge;
>>> > struct myhostbridge_port *pp;
>>> > resource_size_t lastbus;
>>> >
>>> > dev = pdev->dev.of_node;
>>> >
>>> > if (!of_device_is_available(dev)) {
>>> > pr_warn("%s: disabled\n", dev->full_name);
>>> > return -ENODEV;
>>> > }
>>> >
>>> > pp = kzalloc(sizeof(struct myhostbridge_port), GFP_KERNEL);
>>> > if (!pp)
>>> > return -ENOMEM;
>>> >
>>> > bridge = of_create_pci_host_bridge(>dev, _ops,
>>> > pp);
>>> > if (IS_ERR(bridge)) {
>>> > err = PTR_ERR(bridge);
>>> > goto bridge_create_fail;
>>> > }
>>> >
>>> > err = myhostbridge_setup(bridge->bus);
>>> > if (err)
>>> > goto bridge_setup_fail;
>>> >
>>> > /* We always enable PCI domains and we keep domain 0 backward
>>> > * compatible in /proc for video cards
>>> > */
>>> > pci_add_flags(PCI_ENABLE_PROC_DOMAINS);
>>> > pci_add_flags(PCI_REASSIGN_ALL_BUS | PCI_REASSIGN_ALL_RSRC);
>>> >
>>> > lastbus = pci_scan_child_bus(bridge->bus);
>>> > pci_bus_update_busn_res_end(bridge->bus, lastbus);
>>> >
>>> >
Re: [PATCH v7 0/3] Add support for PCI in AArch64
Hello Sandeepa,
On Tue, Apr 22, 2014 at 4:50 AM, Sandeepa Prabhu
sandeepa.pra...@linaro.org wrote:
On 22 April 2014 15:41, Liviu Dudau liviu.du...@arm.com wrote:
On Tue, Apr 22, 2014 at 09:58:28AM +0100, Sandeepa Prabhu wrote:
On 14 March 2014 21:04, Liviu Dudau liviu.du...@arm.com wrote:
Hi,
This patch adds support for PCI to AArch64. It is based on my v7 patch
that adds support for creating generic host bridge structure from
device tree. With that in place, I was able to boot a platform that
has PCIe host bridge support and use a PCIe network card.
Hi Liviu,
Are these patches (including your other patchset for device tree host
bridge support ) available on a public git repo I can checkout from?
Yes, I have pushed them into git://linux-arm.org/linux-ld.git
Thanks Liviu,
Just to understand, is the X-gene PCIe
(https://lwn.net/Articles/589733/) verified using the same patchset?
Yes. V5 version of X-Gene PCIe patches have verified Liviu's patchset
on X-Gene platform.
~Sandeepa
Best regards,
Liviu
Thanks,
~Sandeepa
I have dropped the RFC tag from the subject as I now have the ambitious
goal
of trying to get it mainlined.
Changes from v6:
- Guard the pci_domain_nr() inline implementation with #ifdef
CONFIG_PCI as
to avoid conflict with default empty version present in
include/linux/pci.h.
Thanks to Jingoo Han for catching this.
Changes from v5:
- Removed pcibios_fixup_bridge_ranges() as the week default version is
fine.
- Removed the ALIGN() call in pcibios_align_resource()
- Stopped exporting pcibios_align_resource()
Changes from v4:
- Fixed the pci_domain_nr() implementation for arm64. Now we use
find_pci_host_bride() to find the host bridge before we retrieve
the domain number.
Changes from v3:
- Added Acks accumulated so far ;)
- Still carrying Catalin's patch for moving the PCI_IO_BASE until it
lands in linux-next or mainline, in order to ease applying the series
Changes from v2:
- Implement an arch specific version of pci_register_io_range() and
pci_address_to_pio().
- Return 1 from pci_proc_domain().
Changes from v1:
- Added Catalin's patch for moving the PCI_IO_BASE location and extend
its size to 16MB
- Integrated Arnd's version of pci_ioremap_io that uses a bitmap for
keeping track of assigned IO space and returns an io_offset. At the
moment the code is added in arch/arm64 but it can be moved in
drivers/pci.
- Added a fix for the generic ioport_map() function when
!CONFIG_GENERIC_IOMAP
as suggested by Arnd.
v6 thread here: https://lkml.org/lkml/2014/3/5/41
v5 thread here: https://lkml.org/lkml/2014/3/4/307
v4 thread here: https://lkml.org/lkml/2014/3/3/298
v3 thread here: https://lkml.org/lkml/2014/2/28/211
v2 thread here: https://lkml.org/lkml/2014/2/27/255
v1 thread here: https://lkml.org/lkml/2014/2/3/389
The API used is different from the one used by ARM architecture. There is
no pci_common_init_dev() function and no hw_pci structure, as that is no
longer needed. Once the last signature is added to the legal agreement, I
will post the host bridge driver code that I am using. Meanwhile, here
is an example of what the probe function looks like, posted as an example:
static int myhostbridge_probe(struct platform_device *pdev)
{
int err;
struct device_node *dev;
struct pci_host_bridge *bridge;
struct myhostbridge_port *pp;
resource_size_t lastbus;
dev = pdev-dev.of_node;
if (!of_device_is_available(dev)) {
pr_warn(%s: disabled\n, dev-full_name);
return -ENODEV;
}
pp = kzalloc(sizeof(struct myhostbridge_port), GFP_KERNEL);
if (!pp)
return -ENOMEM;
bridge = of_create_pci_host_bridge(pdev-dev, myhostbridge_ops,
pp);
if (IS_ERR(bridge)) {
err = PTR_ERR(bridge);
goto bridge_create_fail;
}
err = myhostbridge_setup(bridge-bus);
if (err)
goto bridge_setup_fail;
/* We always enable PCI domains and we keep domain 0 backward
* compatible in /proc for video cards
*/
pci_add_flags(PCI_ENABLE_PROC_DOMAINS);
pci_add_flags(PCI_REASSIGN_ALL_BUS | PCI_REASSIGN_ALL_RSRC);
lastbus = pci_scan_child_bus(bridge-bus);
pci_bus_update_busn_res_end(bridge-bus, lastbus);
pci_assign_unassigned_bus_resources(bridge-bus);
pci_bus_add_devices(bridge-bus);
return 0;
bridge_setup_fail:
put_device(bridge-dev);
device_unregister(bridge-dev);
bridge_create_fail:
kfree(pp);
return err;
}
Best regards,
Liviu
Catalin Marinas (1):
arm64: Extend the PCI I/O space to 16MB
Re: [PATCH v7 0/3] Add support for PCI in AArch64
On 24 April 2014 02:02, Tanmay Inamdar tinam...@apm.com wrote:
Hello Sandeepa,
On Tue, Apr 22, 2014 at 4:50 AM, Sandeepa Prabhu
sandeepa.pra...@linaro.org wrote:
On 22 April 2014 15:41, Liviu Dudau liviu.du...@arm.com wrote:
On Tue, Apr 22, 2014 at 09:58:28AM +0100, Sandeepa Prabhu wrote:
On 14 March 2014 21:04, Liviu Dudau liviu.du...@arm.com wrote:
Hi,
This patch adds support for PCI to AArch64. It is based on my v7 patch
that adds support for creating generic host bridge structure from
device tree. With that in place, I was able to boot a platform that
has PCIe host bridge support and use a PCIe network card.
Hi Liviu,
Are these patches (including your other patchset for device tree host
bridge support ) available on a public git repo I can checkout from?
Yes, I have pushed them into git://linux-arm.org/linux-ld.git
Thanks Liviu,
Just to understand, is the X-gene PCIe
(https://lwn.net/Articles/589733/) verified using the same patchset?
Yes. V5 version of X-Gene PCIe patches have verified Liviu's patchset
on X-Gene platform.
Thanks Tanmay!
~Sandeepa
Best regards,
Liviu
Thanks,
~Sandeepa
I have dropped the RFC tag from the subject as I now have the ambitious
goal
of trying to get it mainlined.
Changes from v6:
- Guard the pci_domain_nr() inline implementation with #ifdef
CONFIG_PCI as
to avoid conflict with default empty version present in
include/linux/pci.h.
Thanks to Jingoo Han for catching this.
Changes from v5:
- Removed pcibios_fixup_bridge_ranges() as the week default version is
fine.
- Removed the ALIGN() call in pcibios_align_resource()
- Stopped exporting pcibios_align_resource()
Changes from v4:
- Fixed the pci_domain_nr() implementation for arm64. Now we use
find_pci_host_bride() to find the host bridge before we retrieve
the domain number.
Changes from v3:
- Added Acks accumulated so far ;)
- Still carrying Catalin's patch for moving the PCI_IO_BASE until it
lands in linux-next or mainline, in order to ease applying the series
Changes from v2:
- Implement an arch specific version of pci_register_io_range() and
pci_address_to_pio().
- Return 1 from pci_proc_domain().
Changes from v1:
- Added Catalin's patch for moving the PCI_IO_BASE location and extend
its size to 16MB
- Integrated Arnd's version of pci_ioremap_io that uses a bitmap for
keeping track of assigned IO space and returns an io_offset. At the
moment the code is added in arch/arm64 but it can be moved in
drivers/pci.
- Added a fix for the generic ioport_map() function when
!CONFIG_GENERIC_IOMAP
as suggested by Arnd.
v6 thread here: https://lkml.org/lkml/2014/3/5/41
v5 thread here: https://lkml.org/lkml/2014/3/4/307
v4 thread here: https://lkml.org/lkml/2014/3/3/298
v3 thread here: https://lkml.org/lkml/2014/2/28/211
v2 thread here: https://lkml.org/lkml/2014/2/27/255
v1 thread here: https://lkml.org/lkml/2014/2/3/389
The API used is different from the one used by ARM architecture. There is
no pci_common_init_dev() function and no hw_pci structure, as that is no
longer needed. Once the last signature is added to the legal agreement, I
will post the host bridge driver code that I am using. Meanwhile, here
is an example of what the probe function looks like, posted as an
example:
static int myhostbridge_probe(struct platform_device *pdev)
{
int err;
struct device_node *dev;
struct pci_host_bridge *bridge;
struct myhostbridge_port *pp;
resource_size_t lastbus;
dev = pdev-dev.of_node;
if (!of_device_is_available(dev)) {
pr_warn(%s: disabled\n, dev-full_name);
return -ENODEV;
}
pp = kzalloc(sizeof(struct myhostbridge_port), GFP_KERNEL);
if (!pp)
return -ENOMEM;
bridge = of_create_pci_host_bridge(pdev-dev,
myhostbridge_ops, pp);
if (IS_ERR(bridge)) {
err = PTR_ERR(bridge);
goto bridge_create_fail;
}
err = myhostbridge_setup(bridge-bus);
if (err)
goto bridge_setup_fail;
/* We always enable PCI domains and we keep domain 0 backward
* compatible in /proc for video cards
*/
pci_add_flags(PCI_ENABLE_PROC_DOMAINS);
pci_add_flags(PCI_REASSIGN_ALL_BUS | PCI_REASSIGN_ALL_RSRC);
lastbus = pci_scan_child_bus(bridge-bus);
pci_bus_update_busn_res_end(bridge-bus, lastbus);
pci_assign_unassigned_bus_resources(bridge-bus);
pci_bus_add_devices(bridge-bus);
return 0;
bridge_setup_fail:
put_device(bridge-dev);
device_unregister(bridge-dev);
bridge_create_fail:
kfree(pp);
return err;
}
Best regards,
Re: [PATCH v7 0/3] Add support for PCI in AArch64
On Tue, Apr 22, 2014 at 12:50:40PM +0100, Sandeepa Prabhu wrote:
> On 22 April 2014 15:41, Liviu Dudau wrote:
> > On Tue, Apr 22, 2014 at 09:58:28AM +0100, Sandeepa Prabhu wrote:
> >> On 14 March 2014 21:04, Liviu Dudau wrote:
> >> > Hi,
> >> >
> >> > This patch adds support for PCI to AArch64. It is based on my v7 patch
> >> > that adds support for creating generic host bridge structure from
> >> > device tree. With that in place, I was able to boot a platform that
> >> > has PCIe host bridge support and use a PCIe network card.
> >> Hi Liviu,
> >>
> >> Are these patches (including your other patchset for device tree host
> >> bridge support ) available on a public git repo I can checkout from?
> >
> > Yes, I have pushed them into git://linux-arm.org/linux-ld.git
> Thanks Liviu,
> Just to understand, is the X-gene PCIe
> (https://lwn.net/Articles/589733/) verified using the same patchset?
Tanmay can confirm, but I belive so.
Best regards,
Liviu
>
> ~Sandeepa
> >
> > Best regards,
> > Liviu
> >
> >>
> >> Thanks,
> >> ~Sandeepa
> >>
> >> >
> >> > I have dropped the RFC tag from the subject as I now have the ambitious
> >> > goal
> >> > of trying to get it mainlined.
> >> >
> >> > Changes from v6:
> >> > - Guard the pci_domain_nr() inline implementation with #ifdef
> >> > CONFIG_PCI as
> >> > to avoid conflict with default empty version present in
> >> > include/linux/pci.h.
> >> > Thanks to Jingoo Han for catching this.
> >> >
> >> > Changes from v5:
> >> > - Removed pcibios_fixup_bridge_ranges() as the week default version is
> >> > fine.
> >> > - Removed the ALIGN() call in pcibios_align_resource()
> >> > - Stopped exporting pcibios_align_resource()
> >> >
> >> > Changes from v4:
> >> > - Fixed the pci_domain_nr() implementation for arm64. Now we use
> >> > find_pci_host_bride() to find the host bridge before we retrieve
> >> > the domain number.
> >> >
> >> > Changes from v3:
> >> > - Added Acks accumulated so far ;)
> >> > - Still carrying Catalin's patch for moving the PCI_IO_BASE until it
> >> > lands in linux-next or mainline, in order to ease applying the series
> >> >
> >> > Changes from v2:
> >> > - Implement an arch specific version of pci_register_io_range() and
> >> > pci_address_to_pio().
> >> > - Return 1 from pci_proc_domain().
> >> >
> >> > Changes from v1:
> >> > - Added Catalin's patch for moving the PCI_IO_BASE location and extend
> >> > its size to 16MB
> >> > - Integrated Arnd's version of pci_ioremap_io that uses a bitmap for
> >> > keeping track of assigned IO space and returns an io_offset. At the
> >> > moment the code is added in arch/arm64 but it can be moved in
> >> > drivers/pci.
> >> > - Added a fix for the generic ioport_map() function when
> >> > !CONFIG_GENERIC_IOMAP
> >> > as suggested by Arnd.
> >> >
> >> > v6 thread here: https://lkml.org/lkml/2014/3/5/41
> >> > v5 thread here: https://lkml.org/lkml/2014/3/4/307
> >> > v4 thread here: https://lkml.org/lkml/2014/3/3/298
> >> > v3 thread here: https://lkml.org/lkml/2014/2/28/211
> >> > v2 thread here: https://lkml.org/lkml/2014/2/27/255
> >> > v1 thread here: https://lkml.org/lkml/2014/2/3/389
> >> >
> >> >
> >> > The API used is different from the one used by ARM architecture. There is
> >> > no pci_common_init_dev() function and no hw_pci structure, as that is no
> >> > longer needed. Once the last signature is added to the legal agreement, I
> >> > will post the host bridge driver code that I am using. Meanwhile, here
> >> > is an example of what the probe function looks like, posted as an
> >> > example:
> >> >
> >> > static int myhostbridge_probe(struct platform_device *pdev)
> >> > {
> >> > int err;
> >> > struct device_node *dev;
> >> > struct pci_host_bridge *bridge;
> >> > struct myhostbridge_port *pp;
> >> > resource_size_t lastbus;
> >> >
> >> > dev = pdev->dev.of_node;
> >> >
> >> > if (!of_device_is_available(dev)) {
> >> > pr_warn("%s: disabled\n", dev->full_name);
> >> > return -ENODEV;
> >> > }
> >> >
> >> > pp = kzalloc(sizeof(struct myhostbridge_port), GFP_KERNEL);
> >> > if (!pp)
> >> > return -ENOMEM;
> >> >
> >> > bridge = of_create_pci_host_bridge(>dev,
> >> > _ops, pp);
> >> > if (IS_ERR(bridge)) {
> >> > err = PTR_ERR(bridge);
> >> > goto bridge_create_fail;
> >> > }
> >> >
> >> > err = myhostbridge_setup(bridge->bus);
> >> > if (err)
> >> > goto bridge_setup_fail;
> >> >
> >> > /* We always enable PCI domains and we keep domain 0 backward
> >> > * compatible in /proc for video cards
> >> > */
> >> > pci_add_flags(PCI_ENABLE_PROC_DOMAINS);
> >> > pci_add_flags(PCI_REASSIGN_ALL_BUS | PCI_REASSIGN_ALL_RSRC);
> >> >
> >> > lastbus =
Re: [PATCH v7 0/3] Add support for PCI in AArch64
On 22 April 2014 15:41, Liviu Dudau wrote:
> On Tue, Apr 22, 2014 at 09:58:28AM +0100, Sandeepa Prabhu wrote:
>> On 14 March 2014 21:04, Liviu Dudau wrote:
>> > Hi,
>> >
>> > This patch adds support for PCI to AArch64. It is based on my v7 patch
>> > that adds support for creating generic host bridge structure from
>> > device tree. With that in place, I was able to boot a platform that
>> > has PCIe host bridge support and use a PCIe network card.
>> Hi Liviu,
>>
>> Are these patches (including your other patchset for device tree host
>> bridge support ) available on a public git repo I can checkout from?
>
> Yes, I have pushed them into git://linux-arm.org/linux-ld.git
Thanks Liviu,
Just to understand, is the X-gene PCIe
(https://lwn.net/Articles/589733/) verified using the same patchset?
~Sandeepa
>
> Best regards,
> Liviu
>
>>
>> Thanks,
>> ~Sandeepa
>>
>> >
>> > I have dropped the RFC tag from the subject as I now have the ambitious
>> > goal
>> > of trying to get it mainlined.
>> >
>> > Changes from v6:
>> > - Guard the pci_domain_nr() inline implementation with #ifdef CONFIG_PCI
>> > as
>> > to avoid conflict with default empty version present in
>> > include/linux/pci.h.
>> > Thanks to Jingoo Han for catching this.
>> >
>> > Changes from v5:
>> > - Removed pcibios_fixup_bridge_ranges() as the week default version is
>> > fine.
>> > - Removed the ALIGN() call in pcibios_align_resource()
>> > - Stopped exporting pcibios_align_resource()
>> >
>> > Changes from v4:
>> > - Fixed the pci_domain_nr() implementation for arm64. Now we use
>> > find_pci_host_bride() to find the host bridge before we retrieve
>> > the domain number.
>> >
>> > Changes from v3:
>> > - Added Acks accumulated so far ;)
>> > - Still carrying Catalin's patch for moving the PCI_IO_BASE until it
>> > lands in linux-next or mainline, in order to ease applying the series
>> >
>> > Changes from v2:
>> > - Implement an arch specific version of pci_register_io_range() and
>> > pci_address_to_pio().
>> > - Return 1 from pci_proc_domain().
>> >
>> > Changes from v1:
>> > - Added Catalin's patch for moving the PCI_IO_BASE location and extend
>> > its size to 16MB
>> > - Integrated Arnd's version of pci_ioremap_io that uses a bitmap for
>> > keeping track of assigned IO space and returns an io_offset. At the
>> > moment the code is added in arch/arm64 but it can be moved in
>> > drivers/pci.
>> > - Added a fix for the generic ioport_map() function when
>> > !CONFIG_GENERIC_IOMAP
>> > as suggested by Arnd.
>> >
>> > v6 thread here: https://lkml.org/lkml/2014/3/5/41
>> > v5 thread here: https://lkml.org/lkml/2014/3/4/307
>> > v4 thread here: https://lkml.org/lkml/2014/3/3/298
>> > v3 thread here: https://lkml.org/lkml/2014/2/28/211
>> > v2 thread here: https://lkml.org/lkml/2014/2/27/255
>> > v1 thread here: https://lkml.org/lkml/2014/2/3/389
>> >
>> >
>> > The API used is different from the one used by ARM architecture. There is
>> > no pci_common_init_dev() function and no hw_pci structure, as that is no
>> > longer needed. Once the last signature is added to the legal agreement, I
>> > will post the host bridge driver code that I am using. Meanwhile, here
>> > is an example of what the probe function looks like, posted as an example:
>> >
>> > static int myhostbridge_probe(struct platform_device *pdev)
>> > {
>> > int err;
>> > struct device_node *dev;
>> > struct pci_host_bridge *bridge;
>> > struct myhostbridge_port *pp;
>> > resource_size_t lastbus;
>> >
>> > dev = pdev->dev.of_node;
>> >
>> > if (!of_device_is_available(dev)) {
>> > pr_warn("%s: disabled\n", dev->full_name);
>> > return -ENODEV;
>> > }
>> >
>> > pp = kzalloc(sizeof(struct myhostbridge_port), GFP_KERNEL);
>> > if (!pp)
>> > return -ENOMEM;
>> >
>> > bridge = of_create_pci_host_bridge(>dev, _ops,
>> > pp);
>> > if (IS_ERR(bridge)) {
>> > err = PTR_ERR(bridge);
>> > goto bridge_create_fail;
>> > }
>> >
>> > err = myhostbridge_setup(bridge->bus);
>> > if (err)
>> > goto bridge_setup_fail;
>> >
>> > /* We always enable PCI domains and we keep domain 0 backward
>> > * compatible in /proc for video cards
>> > */
>> > pci_add_flags(PCI_ENABLE_PROC_DOMAINS);
>> > pci_add_flags(PCI_REASSIGN_ALL_BUS | PCI_REASSIGN_ALL_RSRC);
>> >
>> > lastbus = pci_scan_child_bus(bridge->bus);
>> > pci_bus_update_busn_res_end(bridge->bus, lastbus);
>> >
>> > pci_assign_unassigned_bus_resources(bridge->bus);
>> >
>> > pci_bus_add_devices(bridge->bus);
>> >
>> > return 0;
>> >
>> > bridge_setup_fail:
>> > put_device(>dev);
>> > device_unregister(>dev);
>> > bridge_create_fail:
>> > kfree(pp);
>> >
Re: [PATCH v7 0/3] Add support for PCI in AArch64
On Tue, Apr 22, 2014 at 09:58:28AM +0100, Sandeepa Prabhu wrote:
> On 14 March 2014 21:04, Liviu Dudau wrote:
> > Hi,
> >
> > This patch adds support for PCI to AArch64. It is based on my v7 patch
> > that adds support for creating generic host bridge structure from
> > device tree. With that in place, I was able to boot a platform that
> > has PCIe host bridge support and use a PCIe network card.
> Hi Liviu,
>
> Are these patches (including your other patchset for device tree host
> bridge support ) available on a public git repo I can checkout from?
Yes, I have pushed them into git://linux-arm.org/linux-ld.git
Best regards,
Liviu
>
> Thanks,
> ~Sandeepa
>
> >
> > I have dropped the RFC tag from the subject as I now have the ambitious goal
> > of trying to get it mainlined.
> >
> > Changes from v6:
> > - Guard the pci_domain_nr() inline implementation with #ifdef CONFIG_PCI
> > as
> > to avoid conflict with default empty version present in
> > include/linux/pci.h.
> > Thanks to Jingoo Han for catching this.
> >
> > Changes from v5:
> > - Removed pcibios_fixup_bridge_ranges() as the week default version is
> > fine.
> > - Removed the ALIGN() call in pcibios_align_resource()
> > - Stopped exporting pcibios_align_resource()
> >
> > Changes from v4:
> > - Fixed the pci_domain_nr() implementation for arm64. Now we use
> > find_pci_host_bride() to find the host bridge before we retrieve
> > the domain number.
> >
> > Changes from v3:
> > - Added Acks accumulated so far ;)
> > - Still carrying Catalin's patch for moving the PCI_IO_BASE until it
> > lands in linux-next or mainline, in order to ease applying the series
> >
> > Changes from v2:
> > - Implement an arch specific version of pci_register_io_range() and
> > pci_address_to_pio().
> > - Return 1 from pci_proc_domain().
> >
> > Changes from v1:
> > - Added Catalin's patch for moving the PCI_IO_BASE location and extend
> > its size to 16MB
> > - Integrated Arnd's version of pci_ioremap_io that uses a bitmap for
> > keeping track of assigned IO space and returns an io_offset. At the
> > moment the code is added in arch/arm64 but it can be moved in
> > drivers/pci.
> > - Added a fix for the generic ioport_map() function when
> > !CONFIG_GENERIC_IOMAP
> > as suggested by Arnd.
> >
> > v6 thread here: https://lkml.org/lkml/2014/3/5/41
> > v5 thread here: https://lkml.org/lkml/2014/3/4/307
> > v4 thread here: https://lkml.org/lkml/2014/3/3/298
> > v3 thread here: https://lkml.org/lkml/2014/2/28/211
> > v2 thread here: https://lkml.org/lkml/2014/2/27/255
> > v1 thread here: https://lkml.org/lkml/2014/2/3/389
> >
> >
> > The API used is different from the one used by ARM architecture. There is
> > no pci_common_init_dev() function and no hw_pci structure, as that is no
> > longer needed. Once the last signature is added to the legal agreement, I
> > will post the host bridge driver code that I am using. Meanwhile, here
> > is an example of what the probe function looks like, posted as an example:
> >
> > static int myhostbridge_probe(struct platform_device *pdev)
> > {
> > int err;
> > struct device_node *dev;
> > struct pci_host_bridge *bridge;
> > struct myhostbridge_port *pp;
> > resource_size_t lastbus;
> >
> > dev = pdev->dev.of_node;
> >
> > if (!of_device_is_available(dev)) {
> > pr_warn("%s: disabled\n", dev->full_name);
> > return -ENODEV;
> > }
> >
> > pp = kzalloc(sizeof(struct myhostbridge_port), GFP_KERNEL);
> > if (!pp)
> > return -ENOMEM;
> >
> > bridge = of_create_pci_host_bridge(>dev, _ops,
> > pp);
> > if (IS_ERR(bridge)) {
> > err = PTR_ERR(bridge);
> > goto bridge_create_fail;
> > }
> >
> > err = myhostbridge_setup(bridge->bus);
> > if (err)
> > goto bridge_setup_fail;
> >
> > /* We always enable PCI domains and we keep domain 0 backward
> > * compatible in /proc for video cards
> > */
> > pci_add_flags(PCI_ENABLE_PROC_DOMAINS);
> > pci_add_flags(PCI_REASSIGN_ALL_BUS | PCI_REASSIGN_ALL_RSRC);
> >
> > lastbus = pci_scan_child_bus(bridge->bus);
> > pci_bus_update_busn_res_end(bridge->bus, lastbus);
> >
> > pci_assign_unassigned_bus_resources(bridge->bus);
> >
> > pci_bus_add_devices(bridge->bus);
> >
> > return 0;
> >
> > bridge_setup_fail:
> > put_device(>dev);
> > device_unregister(>dev);
> > bridge_create_fail:
> > kfree(pp);
> > return err;
> > }
> >
> > Best regards,
> > Liviu
> >
> >
> > Catalin Marinas (1):
> > arm64: Extend the PCI I/O space to 16MB
> >
> > Liviu Dudau (2):
> > Fix ioport_map() for !CONFIG_GENERIC_IOMAP cases.
> > arm64: Add architecture support for PCI
> >
> > Documentation/arm64/memory.txt | 16 +--
> >
Re: [PATCH v7 0/3] Add support for PCI in AArch64
On 14 March 2014 21:04, Liviu Dudau wrote:
> Hi,
>
> This patch adds support for PCI to AArch64. It is based on my v7 patch
> that adds support for creating generic host bridge structure from
> device tree. With that in place, I was able to boot a platform that
> has PCIe host bridge support and use a PCIe network card.
Hi Liviu,
Are these patches (including your other patchset for device tree host
bridge support ) available on a public git repo I can checkout from?
Thanks,
~Sandeepa
>
> I have dropped the RFC tag from the subject as I now have the ambitious goal
> of trying to get it mainlined.
>
> Changes from v6:
> - Guard the pci_domain_nr() inline implementation with #ifdef CONFIG_PCI as
> to avoid conflict with default empty version present in
> include/linux/pci.h.
> Thanks to Jingoo Han for catching this.
>
> Changes from v5:
> - Removed pcibios_fixup_bridge_ranges() as the week default version is fine.
> - Removed the ALIGN() call in pcibios_align_resource()
> - Stopped exporting pcibios_align_resource()
>
> Changes from v4:
> - Fixed the pci_domain_nr() implementation for arm64. Now we use
> find_pci_host_bride() to find the host bridge before we retrieve
> the domain number.
>
> Changes from v3:
> - Added Acks accumulated so far ;)
> - Still carrying Catalin's patch for moving the PCI_IO_BASE until it
> lands in linux-next or mainline, in order to ease applying the series
>
> Changes from v2:
> - Implement an arch specific version of pci_register_io_range() and
> pci_address_to_pio().
> - Return 1 from pci_proc_domain().
>
> Changes from v1:
> - Added Catalin's patch for moving the PCI_IO_BASE location and extend
> its size to 16MB
> - Integrated Arnd's version of pci_ioremap_io that uses a bitmap for
> keeping track of assigned IO space and returns an io_offset. At the
> moment the code is added in arch/arm64 but it can be moved in drivers/pci.
> - Added a fix for the generic ioport_map() function when
> !CONFIG_GENERIC_IOMAP
> as suggested by Arnd.
>
> v6 thread here: https://lkml.org/lkml/2014/3/5/41
> v5 thread here: https://lkml.org/lkml/2014/3/4/307
> v4 thread here: https://lkml.org/lkml/2014/3/3/298
> v3 thread here: https://lkml.org/lkml/2014/2/28/211
> v2 thread here: https://lkml.org/lkml/2014/2/27/255
> v1 thread here: https://lkml.org/lkml/2014/2/3/389
>
>
> The API used is different from the one used by ARM architecture. There is
> no pci_common_init_dev() function and no hw_pci structure, as that is no
> longer needed. Once the last signature is added to the legal agreement, I
> will post the host bridge driver code that I am using. Meanwhile, here
> is an example of what the probe function looks like, posted as an example:
>
> static int myhostbridge_probe(struct platform_device *pdev)
> {
> int err;
> struct device_node *dev;
> struct pci_host_bridge *bridge;
> struct myhostbridge_port *pp;
> resource_size_t lastbus;
>
> dev = pdev->dev.of_node;
>
> if (!of_device_is_available(dev)) {
> pr_warn("%s: disabled\n", dev->full_name);
> return -ENODEV;
> }
>
> pp = kzalloc(sizeof(struct myhostbridge_port), GFP_KERNEL);
> if (!pp)
> return -ENOMEM;
>
> bridge = of_create_pci_host_bridge(>dev, _ops, pp);
> if (IS_ERR(bridge)) {
> err = PTR_ERR(bridge);
> goto bridge_create_fail;
> }
>
> err = myhostbridge_setup(bridge->bus);
> if (err)
> goto bridge_setup_fail;
>
> /* We always enable PCI domains and we keep domain 0 backward
> * compatible in /proc for video cards
> */
> pci_add_flags(PCI_ENABLE_PROC_DOMAINS);
> pci_add_flags(PCI_REASSIGN_ALL_BUS | PCI_REASSIGN_ALL_RSRC);
>
> lastbus = pci_scan_child_bus(bridge->bus);
> pci_bus_update_busn_res_end(bridge->bus, lastbus);
>
> pci_assign_unassigned_bus_resources(bridge->bus);
>
> pci_bus_add_devices(bridge->bus);
>
> return 0;
>
> bridge_setup_fail:
> put_device(>dev);
> device_unregister(>dev);
> bridge_create_fail:
> kfree(pp);
> return err;
> }
>
> Best regards,
> Liviu
>
>
> Catalin Marinas (1):
> arm64: Extend the PCI I/O space to 16MB
>
> Liviu Dudau (2):
> Fix ioport_map() for !CONFIG_GENERIC_IOMAP cases.
> arm64: Add architecture support for PCI
>
> Documentation/arm64/memory.txt | 16 +--
> arch/arm64/Kconfig | 19 +++-
> arch/arm64/include/asm/Kbuild | 1 +
> arch/arm64/include/asm/io.h| 5 +-
> arch/arm64/include/asm/pci.h | 51 +
> arch/arm64/kernel/Makefile | 1 +
> arch/arm64/kernel/pci.c| 173 +++
> include/asm-generic/io.h | 2 +-
> 8 files changed, 258 insertions(+), 10 deletions(-)
> create mode 100644 arch/arm64/include/asm/pci.h
>
Re: [PATCH v7 0/3] Add support for PCI in AArch64
On 14 March 2014 21:04, Liviu Dudau liviu.du...@arm.com wrote:
Hi,
This patch adds support for PCI to AArch64. It is based on my v7 patch
that adds support for creating generic host bridge structure from
device tree. With that in place, I was able to boot a platform that
has PCIe host bridge support and use a PCIe network card.
Hi Liviu,
Are these patches (including your other patchset for device tree host
bridge support ) available on a public git repo I can checkout from?
Thanks,
~Sandeepa
I have dropped the RFC tag from the subject as I now have the ambitious goal
of trying to get it mainlined.
Changes from v6:
- Guard the pci_domain_nr() inline implementation with #ifdef CONFIG_PCI as
to avoid conflict with default empty version present in
include/linux/pci.h.
Thanks to Jingoo Han for catching this.
Changes from v5:
- Removed pcibios_fixup_bridge_ranges() as the week default version is fine.
- Removed the ALIGN() call in pcibios_align_resource()
- Stopped exporting pcibios_align_resource()
Changes from v4:
- Fixed the pci_domain_nr() implementation for arm64. Now we use
find_pci_host_bride() to find the host bridge before we retrieve
the domain number.
Changes from v3:
- Added Acks accumulated so far ;)
- Still carrying Catalin's patch for moving the PCI_IO_BASE until it
lands in linux-next or mainline, in order to ease applying the series
Changes from v2:
- Implement an arch specific version of pci_register_io_range() and
pci_address_to_pio().
- Return 1 from pci_proc_domain().
Changes from v1:
- Added Catalin's patch for moving the PCI_IO_BASE location and extend
its size to 16MB
- Integrated Arnd's version of pci_ioremap_io that uses a bitmap for
keeping track of assigned IO space and returns an io_offset. At the
moment the code is added in arch/arm64 but it can be moved in drivers/pci.
- Added a fix for the generic ioport_map() function when
!CONFIG_GENERIC_IOMAP
as suggested by Arnd.
v6 thread here: https://lkml.org/lkml/2014/3/5/41
v5 thread here: https://lkml.org/lkml/2014/3/4/307
v4 thread here: https://lkml.org/lkml/2014/3/3/298
v3 thread here: https://lkml.org/lkml/2014/2/28/211
v2 thread here: https://lkml.org/lkml/2014/2/27/255
v1 thread here: https://lkml.org/lkml/2014/2/3/389
The API used is different from the one used by ARM architecture. There is
no pci_common_init_dev() function and no hw_pci structure, as that is no
longer needed. Once the last signature is added to the legal agreement, I
will post the host bridge driver code that I am using. Meanwhile, here
is an example of what the probe function looks like, posted as an example:
static int myhostbridge_probe(struct platform_device *pdev)
{
int err;
struct device_node *dev;
struct pci_host_bridge *bridge;
struct myhostbridge_port *pp;
resource_size_t lastbus;
dev = pdev-dev.of_node;
if (!of_device_is_available(dev)) {
pr_warn(%s: disabled\n, dev-full_name);
return -ENODEV;
}
pp = kzalloc(sizeof(struct myhostbridge_port), GFP_KERNEL);
if (!pp)
return -ENOMEM;
bridge = of_create_pci_host_bridge(pdev-dev, myhostbridge_ops, pp);
if (IS_ERR(bridge)) {
err = PTR_ERR(bridge);
goto bridge_create_fail;
}
err = myhostbridge_setup(bridge-bus);
if (err)
goto bridge_setup_fail;
/* We always enable PCI domains and we keep domain 0 backward
* compatible in /proc for video cards
*/
pci_add_flags(PCI_ENABLE_PROC_DOMAINS);
pci_add_flags(PCI_REASSIGN_ALL_BUS | PCI_REASSIGN_ALL_RSRC);
lastbus = pci_scan_child_bus(bridge-bus);
pci_bus_update_busn_res_end(bridge-bus, lastbus);
pci_assign_unassigned_bus_resources(bridge-bus);
pci_bus_add_devices(bridge-bus);
return 0;
bridge_setup_fail:
put_device(bridge-dev);
device_unregister(bridge-dev);
bridge_create_fail:
kfree(pp);
return err;
}
Best regards,
Liviu
Catalin Marinas (1):
arm64: Extend the PCI I/O space to 16MB
Liviu Dudau (2):
Fix ioport_map() for !CONFIG_GENERIC_IOMAP cases.
arm64: Add architecture support for PCI
Documentation/arm64/memory.txt | 16 +--
arch/arm64/Kconfig | 19 +++-
arch/arm64/include/asm/Kbuild | 1 +
arch/arm64/include/asm/io.h| 5 +-
arch/arm64/include/asm/pci.h | 51 +
arch/arm64/kernel/Makefile | 1 +
arch/arm64/kernel/pci.c| 173 +++
include/asm-generic/io.h | 2 +-
8 files changed, 258 insertions(+), 10 deletions(-)
create mode 100644 arch/arm64/include/asm/pci.h
create mode 100644 arch/arm64/kernel/pci.c
--
1.9.0
Re: [PATCH v7 0/3] Add support for PCI in AArch64
On Tue, Apr 22, 2014 at 09:58:28AM +0100, Sandeepa Prabhu wrote:
On 14 March 2014 21:04, Liviu Dudau liviu.du...@arm.com wrote:
Hi,
This patch adds support for PCI to AArch64. It is based on my v7 patch
that adds support for creating generic host bridge structure from
device tree. With that in place, I was able to boot a platform that
has PCIe host bridge support and use a PCIe network card.
Hi Liviu,
Are these patches (including your other patchset for device tree host
bridge support ) available on a public git repo I can checkout from?
Yes, I have pushed them into git://linux-arm.org/linux-ld.git
Best regards,
Liviu
Thanks,
~Sandeepa
I have dropped the RFC tag from the subject as I now have the ambitious goal
of trying to get it mainlined.
Changes from v6:
- Guard the pci_domain_nr() inline implementation with #ifdef CONFIG_PCI
as
to avoid conflict with default empty version present in
include/linux/pci.h.
Thanks to Jingoo Han for catching this.
Changes from v5:
- Removed pcibios_fixup_bridge_ranges() as the week default version is
fine.
- Removed the ALIGN() call in pcibios_align_resource()
- Stopped exporting pcibios_align_resource()
Changes from v4:
- Fixed the pci_domain_nr() implementation for arm64. Now we use
find_pci_host_bride() to find the host bridge before we retrieve
the domain number.
Changes from v3:
- Added Acks accumulated so far ;)
- Still carrying Catalin's patch for moving the PCI_IO_BASE until it
lands in linux-next or mainline, in order to ease applying the series
Changes from v2:
- Implement an arch specific version of pci_register_io_range() and
pci_address_to_pio().
- Return 1 from pci_proc_domain().
Changes from v1:
- Added Catalin's patch for moving the PCI_IO_BASE location and extend
its size to 16MB
- Integrated Arnd's version of pci_ioremap_io that uses a bitmap for
keeping track of assigned IO space and returns an io_offset. At the
moment the code is added in arch/arm64 but it can be moved in
drivers/pci.
- Added a fix for the generic ioport_map() function when
!CONFIG_GENERIC_IOMAP
as suggested by Arnd.
v6 thread here: https://lkml.org/lkml/2014/3/5/41
v5 thread here: https://lkml.org/lkml/2014/3/4/307
v4 thread here: https://lkml.org/lkml/2014/3/3/298
v3 thread here: https://lkml.org/lkml/2014/2/28/211
v2 thread here: https://lkml.org/lkml/2014/2/27/255
v1 thread here: https://lkml.org/lkml/2014/2/3/389
The API used is different from the one used by ARM architecture. There is
no pci_common_init_dev() function and no hw_pci structure, as that is no
longer needed. Once the last signature is added to the legal agreement, I
will post the host bridge driver code that I am using. Meanwhile, here
is an example of what the probe function looks like, posted as an example:
static int myhostbridge_probe(struct platform_device *pdev)
{
int err;
struct device_node *dev;
struct pci_host_bridge *bridge;
struct myhostbridge_port *pp;
resource_size_t lastbus;
dev = pdev-dev.of_node;
if (!of_device_is_available(dev)) {
pr_warn(%s: disabled\n, dev-full_name);
return -ENODEV;
}
pp = kzalloc(sizeof(struct myhostbridge_port), GFP_KERNEL);
if (!pp)
return -ENOMEM;
bridge = of_create_pci_host_bridge(pdev-dev, myhostbridge_ops,
pp);
if (IS_ERR(bridge)) {
err = PTR_ERR(bridge);
goto bridge_create_fail;
}
err = myhostbridge_setup(bridge-bus);
if (err)
goto bridge_setup_fail;
/* We always enable PCI domains and we keep domain 0 backward
* compatible in /proc for video cards
*/
pci_add_flags(PCI_ENABLE_PROC_DOMAINS);
pci_add_flags(PCI_REASSIGN_ALL_BUS | PCI_REASSIGN_ALL_RSRC);
lastbus = pci_scan_child_bus(bridge-bus);
pci_bus_update_busn_res_end(bridge-bus, lastbus);
pci_assign_unassigned_bus_resources(bridge-bus);
pci_bus_add_devices(bridge-bus);
return 0;
bridge_setup_fail:
put_device(bridge-dev);
device_unregister(bridge-dev);
bridge_create_fail:
kfree(pp);
return err;
}
Best regards,
Liviu
Catalin Marinas (1):
arm64: Extend the PCI I/O space to 16MB
Liviu Dudau (2):
Fix ioport_map() for !CONFIG_GENERIC_IOMAP cases.
arm64: Add architecture support for PCI
Documentation/arm64/memory.txt | 16 +--
arch/arm64/Kconfig | 19 +++-
arch/arm64/include/asm/Kbuild | 1 +
arch/arm64/include/asm/io.h| 5 +-
arch/arm64/include/asm/pci.h | 51 +
arch/arm64/kernel/Makefile | 1 +
Re: [PATCH v7 0/3] Add support for PCI in AArch64
On 22 April 2014 15:41, Liviu Dudau liviu.du...@arm.com wrote:
On Tue, Apr 22, 2014 at 09:58:28AM +0100, Sandeepa Prabhu wrote:
On 14 March 2014 21:04, Liviu Dudau liviu.du...@arm.com wrote:
Hi,
This patch adds support for PCI to AArch64. It is based on my v7 patch
that adds support for creating generic host bridge structure from
device tree. With that in place, I was able to boot a platform that
has PCIe host bridge support and use a PCIe network card.
Hi Liviu,
Are these patches (including your other patchset for device tree host
bridge support ) available on a public git repo I can checkout from?
Yes, I have pushed them into git://linux-arm.org/linux-ld.git
Thanks Liviu,
Just to understand, is the X-gene PCIe
(https://lwn.net/Articles/589733/) verified using the same patchset?
~Sandeepa
Best regards,
Liviu
Thanks,
~Sandeepa
I have dropped the RFC tag from the subject as I now have the ambitious
goal
of trying to get it mainlined.
Changes from v6:
- Guard the pci_domain_nr() inline implementation with #ifdef CONFIG_PCI
as
to avoid conflict with default empty version present in
include/linux/pci.h.
Thanks to Jingoo Han for catching this.
Changes from v5:
- Removed pcibios_fixup_bridge_ranges() as the week default version is
fine.
- Removed the ALIGN() call in pcibios_align_resource()
- Stopped exporting pcibios_align_resource()
Changes from v4:
- Fixed the pci_domain_nr() implementation for arm64. Now we use
find_pci_host_bride() to find the host bridge before we retrieve
the domain number.
Changes from v3:
- Added Acks accumulated so far ;)
- Still carrying Catalin's patch for moving the PCI_IO_BASE until it
lands in linux-next or mainline, in order to ease applying the series
Changes from v2:
- Implement an arch specific version of pci_register_io_range() and
pci_address_to_pio().
- Return 1 from pci_proc_domain().
Changes from v1:
- Added Catalin's patch for moving the PCI_IO_BASE location and extend
its size to 16MB
- Integrated Arnd's version of pci_ioremap_io that uses a bitmap for
keeping track of assigned IO space and returns an io_offset. At the
moment the code is added in arch/arm64 but it can be moved in
drivers/pci.
- Added a fix for the generic ioport_map() function when
!CONFIG_GENERIC_IOMAP
as suggested by Arnd.
v6 thread here: https://lkml.org/lkml/2014/3/5/41
v5 thread here: https://lkml.org/lkml/2014/3/4/307
v4 thread here: https://lkml.org/lkml/2014/3/3/298
v3 thread here: https://lkml.org/lkml/2014/2/28/211
v2 thread here: https://lkml.org/lkml/2014/2/27/255
v1 thread here: https://lkml.org/lkml/2014/2/3/389
The API used is different from the one used by ARM architecture. There is
no pci_common_init_dev() function and no hw_pci structure, as that is no
longer needed. Once the last signature is added to the legal agreement, I
will post the host bridge driver code that I am using. Meanwhile, here
is an example of what the probe function looks like, posted as an example:
static int myhostbridge_probe(struct platform_device *pdev)
{
int err;
struct device_node *dev;
struct pci_host_bridge *bridge;
struct myhostbridge_port *pp;
resource_size_t lastbus;
dev = pdev-dev.of_node;
if (!of_device_is_available(dev)) {
pr_warn(%s: disabled\n, dev-full_name);
return -ENODEV;
}
pp = kzalloc(sizeof(struct myhostbridge_port), GFP_KERNEL);
if (!pp)
return -ENOMEM;
bridge = of_create_pci_host_bridge(pdev-dev, myhostbridge_ops,
pp);
if (IS_ERR(bridge)) {
err = PTR_ERR(bridge);
goto bridge_create_fail;
}
err = myhostbridge_setup(bridge-bus);
if (err)
goto bridge_setup_fail;
/* We always enable PCI domains and we keep domain 0 backward
* compatible in /proc for video cards
*/
pci_add_flags(PCI_ENABLE_PROC_DOMAINS);
pci_add_flags(PCI_REASSIGN_ALL_BUS | PCI_REASSIGN_ALL_RSRC);
lastbus = pci_scan_child_bus(bridge-bus);
pci_bus_update_busn_res_end(bridge-bus, lastbus);
pci_assign_unassigned_bus_resources(bridge-bus);
pci_bus_add_devices(bridge-bus);
return 0;
bridge_setup_fail:
put_device(bridge-dev);
device_unregister(bridge-dev);
bridge_create_fail:
kfree(pp);
return err;
}
Best regards,
Liviu
Catalin Marinas (1):
arm64: Extend the PCI I/O space to 16MB
Liviu Dudau (2):
Fix ioport_map() for !CONFIG_GENERIC_IOMAP cases.
arm64: Add architecture support for PCI
Documentation/arm64/memory.txt | 16 +--
arch/arm64/Kconfig | 19
Re: [PATCH v7 0/3] Add support for PCI in AArch64
On Tue, Apr 22, 2014 at 12:50:40PM +0100, Sandeepa Prabhu wrote:
On 22 April 2014 15:41, Liviu Dudau liviu.du...@arm.com wrote:
On Tue, Apr 22, 2014 at 09:58:28AM +0100, Sandeepa Prabhu wrote:
On 14 March 2014 21:04, Liviu Dudau liviu.du...@arm.com wrote:
Hi,
This patch adds support for PCI to AArch64. It is based on my v7 patch
that adds support for creating generic host bridge structure from
device tree. With that in place, I was able to boot a platform that
has PCIe host bridge support and use a PCIe network card.
Hi Liviu,
Are these patches (including your other patchset for device tree host
bridge support ) available on a public git repo I can checkout from?
Yes, I have pushed them into git://linux-arm.org/linux-ld.git
Thanks Liviu,
Just to understand, is the X-gene PCIe
(https://lwn.net/Articles/589733/) verified using the same patchset?
Tanmay can confirm, but I belive so.
Best regards,
Liviu
~Sandeepa
Best regards,
Liviu
Thanks,
~Sandeepa
I have dropped the RFC tag from the subject as I now have the ambitious
goal
of trying to get it mainlined.
Changes from v6:
- Guard the pci_domain_nr() inline implementation with #ifdef
CONFIG_PCI as
to avoid conflict with default empty version present in
include/linux/pci.h.
Thanks to Jingoo Han for catching this.
Changes from v5:
- Removed pcibios_fixup_bridge_ranges() as the week default version is
fine.
- Removed the ALIGN() call in pcibios_align_resource()
- Stopped exporting pcibios_align_resource()
Changes from v4:
- Fixed the pci_domain_nr() implementation for arm64. Now we use
find_pci_host_bride() to find the host bridge before we retrieve
the domain number.
Changes from v3:
- Added Acks accumulated so far ;)
- Still carrying Catalin's patch for moving the PCI_IO_BASE until it
lands in linux-next or mainline, in order to ease applying the series
Changes from v2:
- Implement an arch specific version of pci_register_io_range() and
pci_address_to_pio().
- Return 1 from pci_proc_domain().
Changes from v1:
- Added Catalin's patch for moving the PCI_IO_BASE location and extend
its size to 16MB
- Integrated Arnd's version of pci_ioremap_io that uses a bitmap for
keeping track of assigned IO space and returns an io_offset. At the
moment the code is added in arch/arm64 but it can be moved in
drivers/pci.
- Added a fix for the generic ioport_map() function when
!CONFIG_GENERIC_IOMAP
as suggested by Arnd.
v6 thread here: https://lkml.org/lkml/2014/3/5/41
v5 thread here: https://lkml.org/lkml/2014/3/4/307
v4 thread here: https://lkml.org/lkml/2014/3/3/298
v3 thread here: https://lkml.org/lkml/2014/2/28/211
v2 thread here: https://lkml.org/lkml/2014/2/27/255
v1 thread here: https://lkml.org/lkml/2014/2/3/389
The API used is different from the one used by ARM architecture. There is
no pci_common_init_dev() function and no hw_pci structure, as that is no
longer needed. Once the last signature is added to the legal agreement, I
will post the host bridge driver code that I am using. Meanwhile, here
is an example of what the probe function looks like, posted as an
example:
static int myhostbridge_probe(struct platform_device *pdev)
{
int err;
struct device_node *dev;
struct pci_host_bridge *bridge;
struct myhostbridge_port *pp;
resource_size_t lastbus;
dev = pdev-dev.of_node;
if (!of_device_is_available(dev)) {
pr_warn(%s: disabled\n, dev-full_name);
return -ENODEV;
}
pp = kzalloc(sizeof(struct myhostbridge_port), GFP_KERNEL);
if (!pp)
return -ENOMEM;
bridge = of_create_pci_host_bridge(pdev-dev,
myhostbridge_ops, pp);
if (IS_ERR(bridge)) {
err = PTR_ERR(bridge);
goto bridge_create_fail;
}
err = myhostbridge_setup(bridge-bus);
if (err)
goto bridge_setup_fail;
/* We always enable PCI domains and we keep domain 0 backward
* compatible in /proc for video cards
*/
pci_add_flags(PCI_ENABLE_PROC_DOMAINS);
pci_add_flags(PCI_REASSIGN_ALL_BUS | PCI_REASSIGN_ALL_RSRC);
lastbus = pci_scan_child_bus(bridge-bus);
pci_bus_update_busn_res_end(bridge-bus, lastbus);
pci_assign_unassigned_bus_resources(bridge-bus);
pci_bus_add_devices(bridge-bus);
return 0;
bridge_setup_fail:
put_device(bridge-dev);
device_unregister(bridge-dev);
bridge_create_fail:
kfree(pp);
return err;
}
Best regards,
Liviu
