from:"Gabriele Paoloni"

RE: [PATCH v3 1/6] PCI: designware: remove wrong io_base assignment

2015-11-23 Thread Gabriele Paoloni

Hi Stanimir, Many Thanks for this fix

> -Original Message-
> From: linux-kernel-ow...@vger.kernel.org [mailto:linux-kernel-
> ow...@vger.kernel.org] On Behalf Of Arnd Bergmann
> Sent: 23 November 2015 10:00
> To: Stanimir Varbanov
> Cc: linux-arm-...@vger.kernel.org; linux-ker...@vger.kernel.org; linux-arm-
> ker...@lists.infradead.org; devicetree@vger.kernel.org; linux-
> p...@vger.kernel.org; Bjorn Helgaas; Srinivas Kandagatla; Rob Herring; Rob
> Herring; Mark Rutland; Pawel Moll; Ian Campbell; Jingoo Han; Pratyush Anand;
> Bjorn Andersson
> Subject: Re: [PATCH v3 1/6] PCI: designware: remove wrong io_base assignment
> 
> On Monday 23 November 2015 11:28:58 Stanimir Varbanov wrote:
> > The io_base is used to keep the cpu physical address parsed
> > from ranges dt property. After issue pci_remap_iospace the
> > io_base has been assigned with io->start, which is not correct
> > cause io->start is a PCI bus address.
> >
> > Signed-off-by: Stanimir Varbanov 
> > ---
> >  drivers/pci/host/pcie-designware.c |1 -
> >  1 file changed, 1 deletion(-)
> >
> > diff --git a/drivers/pci/host/pcie-designware.c b/drivers/pci/host/pcie-
> designware.c
> > index 540f077c37ea..02a7452bdf23 100644
> > --- a/drivers/pci/host/pcie-designware.c
> > +++ b/drivers/pci/host/pcie-designware.c
> > @@ -440,7 +440,6 @@ int dw_pcie_host_init(struct pcie_port *pp)
> >  ret, pp->io);
> > continue;
> > }
> > -   pp->io_base = pp->io->start;
> > break;
> > case IORESOURCE_MEM:
> > pp->mem = win->res;
> 
> I was surprised to see such an obvious bug here, as we had spent a lot of
> time trying to get it right. However, it broke only recently and it's
> worth mentioning what commit did it, so

Looking at 
"[PATCH v12 0/8] PCI: hisi: Add PCIe host support for HiSilicon SoC Hip05":

actually the bug came in as patch 3/6 of v11 patchset split

[...]

Change from v11:
- Split 3/6 in v11 to 3/8, 4/8, 5/8 in v12.

[...]

This was not present in v11...sorry about this.

Gab

> 
> Fixes: 0021d22b73d6 ("PCI: designware: Use of_pci_get_host_bridge_resources()
> to parse DT")
> Reviewed-by: Arnd Bergmann 
> 
> The bug is present in 4.4-rc1 and we should get your fix merged into 4.4
> as well, while all the other patches in your series are presumably for 4.5.
> 
>   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/
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

RE: [PATCH v13 0/6] PCI: hisi: Add PCIe host support for HiSilicon SoC Hip05

2015-11-02 Thread Gabriele Paoloni

Hi Bjorn

I see this patchset merged into your next branch.

Can you confirm?

Many Thanks

Gab

> -Original Message-
> From: Wangzhou (B)
> Sent: Thursday, October 29, 2015 9:41 AM
> To: Bjorn Helgaas; jingooh...@gmail.com; pratyush.an...@gmail.com; Arnd
> Bergmann; rmk+ker...@arm.linux.org.uk; thomas.petazzoni@free-
> electrons.com; Gabriele Paoloni; lorenzo.pieral...@arm.com;
> james.mo...@arm.com; liviu.du...@arm.com; ja...@lakedaemon.net;
> r...@kernel.org; gabriel.fernan...@linaro.org;
> minghuan.l...@freescale.com
> Cc: linux-...@vger.kernel.org; linux-arm-ker...@lists.infradead.org;
> devicetree@vger.kernel.org; linux-ker...@vger.kernel.org; zhangjukuo;
> qiuzhenfa; liudongdong (C); qiujiang; xuwei (O); Liguozhu (Kenneth);
> Wangzhou (B)
> Subject: [PATCH v13 0/6] PCI: hisi: Add PCIe host support for HiSilicon
> SoC Hip05
> 
> This patchset adds PCIe host support for HiSilicon SoC Hip05. The PCIe
> hosts
> use PCIe IP core from Synopsys, So this driver is based on designware
> PCIe driver.
> 
> Hip05 is an ARMv8 architecture SoC. It should be able to use ARM64 PCIe
> API in
> designware PCIe driver. So this patch also adds ARM64 support for
> designware
> pcie.
> 
> This patchset is based on v4.3-rc1.
> 
> Change from v12:
> - Reorder patchset as suggestion by Bjorn.
> - Add Rob's Acked-by for DT binding.
> - Merge HiSilicon PCIe driver, DT binding document and maintainer
> update into
>   one patch.
> 
> Change from v11:
> - Split 3/6 in v11 to 3/8, 4/8, 5/8 in v12.
> - Add print in pcie-hisi.c to indicate read/write hardware defect.
> - Modify macro in 1/8 pointed by Bjorn.
> 
> Change from v10:
> - Remove MSI related setting and VMID/ASID table setting, they will be
>   implemented in BIOS.
> - Use module_platform_driver to init pcie-hisi.c
> - Add necessary comments.
> 
> Change from v9:
> - Use syscon to get subctrl base address.
> - 5/6 is based on [PATCH v3 0/2] arm64: Support Hisilicon Hip05-D02
> board
>   from Ding Tianhong
> - Add hisi_pcie_cfg_read in pcie-hisi.c to match
>   [PATCH v6 0/3] PCI: designware: change dw_pcie_cfg_write() and
> dw_pcie_cfg_read()
>   from Gabriele.
> 
> Change from v8:
> - Rebase on v4.3-rc1.
> - Add Tested-by from Gabriel and Minghuan.
> - Remove ITS domain parsing in msi_host_init in pcie-hisi.c, no need
> this as PCI
>   core does related job. Add ITS base address parsing in msi_host_init.
> - Change vmid/asid table configuration, previous configuration was
> wrong.
> - Add wr_own_conf callback in pcie-hisi.c.
> - Use subsys_initcall to init hisi PCIe.
> 
> Change from v7:
> - Remove pp->root_bus_nr = 0 in dra7xx, exynos, imx6, keystone,
> layerscape,
>   spear13xx. Pass pp->busn->start to pci_create_root_bus as root bus
> number.
> - Remove bus-range parsing in pcie-hisi.c.
> 
> Change from v6:
> - Add Pratyush's Acked-by for 1/6 and 2/6.
> - Add James' Tested-by for 3/6.
> 
> Change from v5:
> - Merge 1/6 in this series, discussion about this can be found in [1]
> 
> Change from v4:
> - Change the author of 1/5 to Gabriele.
> - Modify problems in 3/5 pointed by Bjorn.
> - Modify spelling problems in 4/5.
> 
> Change from v3:
> - Change 1/5 to what Gabriele suggested.
> - Use win->__res.start to get *_mod_base in 2/5, this fix a bug in v3
> series.
> 
> Change from v2:
> - Move struct pci_dev *dev and struct pci_sys_data *sys in
>   pcibios_align_resource in 1/5.
> - Add Gabriele's codes in 2/5 which delete unnecessary information
> parse and
>   use of_pci_get_host_bridge_resources for both ARM32 and ARM64.
> - Add maintainer patch 5/5.
> 
> Change from RFC v1:
> - Add 1/4 patch by Arnd which removes align_resource callback in ARM
>   pcibios_align_resource.
> - Change head file in pcie-designware from asm/hardirq.h to
> linux/hardirq.h.
> - Set pp->root_bus_nr = 0 in dra7xx, exynos, imx6, keystone, layerscape,
>   spear13xx.
> - Remove unnecessary parentheses of some macros in pcie-hisi.
> - Use macro to replace some magic values.
> - Merge two loops together and add some comments about it in
> context_config
>   function in pcie-hisi.
> - Modify some value of items in pcie node example in binding document.
> 
> Change from RFC:
> - delete dw_pcie_setup, dw_pcie_scan_bus, dw_pcie_map_irq and struct
> hw_pci,
>   merge related operations into dw_pcie_host_init.
> 
> Link of v12:
> - https://lkml.org/lkml/2015/10/26/196
> Link of v11:
> - https://lkml.org/lkml/2015/10/16/228
> Link of v10:
> - http://www.spinics.net/lists/linux-pci/msg45490.html
> Link of v9:
> - http://www.spinics.net/lists/linux-pci/msg44545.html
> Link of v8:
>

RE: [PATCH v11 1/6] PCI: designware: move calculation of bus addresses to DRA7xx

2015-10-22 Thread Gabriele Paoloni

> -Original Message-
> From: linux-pci-ow...@vger.kernel.org [mailto:linux-pci-
> ow...@vger.kernel.org] On Behalf Of Bjorn Helgaas
> Sent: Thursday, October 22, 2015 5:36 PM
> To: Gabriele Paoloni
> Cc: Wangzhou (B); Bjorn Helgaas; jingooh...@gmail.com;
> pratyush.an...@gmail.com; Arnd Bergmann; li...@arm.linux.org.uk;
> thomas.petazz...@free-electrons.com; lorenzo.pieral...@arm.com;
> james.mo...@arm.com; liviu.du...@arm.com; ja...@lakedaemon.net;
> r...@kernel.org; gabriel.fernan...@linaro.org;
> minghuan.l...@freescale.com; linux-...@vger.kernel.org; linux-arm-
> ker...@lists.infradead.org; devicetree@vger.kernel.org; linux-
> ker...@vger.kernel.org; zhangjukuo; qiuzhenfa; liudongdong (C);
> qiujiang; xuwei (O); Liguozhu (Kenneth)
> Subject: Re: [PATCH v11 1/6] PCI: designware: move calculation of bus
> addresses to DRA7xx
> 
> Hi Gabriele,
> 
> On Thu, Oct 22, 2015 at 07:21:41AM +, Gabriele Paoloni wrote:
> > > -Original Message-
> > > From: Bjorn Helgaas [mailto:helg...@kernel.org]
> 
> > > >  #definePCIECTRL_DRA7XX_CONF_PHY_CS 0x010C
> > > >  #defineLINK_UP BIT(16)
> > > > +#defineCPU_TO_BUS_ADDR 
> > > > 0x0FFF
> > >
> > > "CPU_TO_BUS_ADDR" is a very generic name.  Since you do have DRA7XX
> in
> > > other #defines and static symbols in this file, maybe it could be
> DRA7XX to
> > > make it obvious that it only applies here?
> >
> > Ok will change to DRA7XX_CPU_TO_BUS_ADRR in v12
> > ..
> 
> > > > +   if (pp->io_mod_base)
> > > > +   pp->io_mod_base &= CPU_TO_BUS_ADDR;
> > >
> > > These are equivalent to
> > >
> > >   pp->io_mod_base &= CPU_TO_BUS_ADDR;
> > >
> > > (You don't need to test whether they're zero first.)
> >
> > Yes agreed, will change in v12
> > ...
> 
> > > > cfg_res = platform_get_resource_byname(pdev, IORESOURCE_MEM,
> "config");
> > > > @@ -415,8 +411,7 @@ int dw_pcie_host_init(struct pcie_port *pp)
> > > > pp->io_base = range.cpu_addr;
> > > >
> > > > /* Find the untranslated IO space address */
> > > > -   pp->io_mod_base = of_read_number(parser.range -
> > > > -parser.np + 
> > > > na, ns);
> > > > +   pp->io_mod_base = range.cpu_addr;
> > >
> > > So apparently
> > >
> > >   "of_read_number() == range.cpu_addr & CPU_TO_BUS_ADDR" on DRA7xx
> > >   "of_read_number() == range.cpu_addr" everywhere else?
> >
> > Yes correct
> >
> > > Is that right?  Is that a valid assumption, i.e., are we assuming
> > > anything about DTs in the field that we shouldn't?
> >
> > Before I wrote a patch that was generic to accommodate intermediate
> level
> > of translation between PCI_addr -> BUS_addr -> CPU_addr
> >
> > http://lists.infradead.org/pipermail/linux-arm-kernel/2015-
> July/360922.html
> >
> > After discussion we agreed to solve it with a bitmask rather than
> adding
> > a field to of_pci_range to make it generic.
> > The bitmask only applies to DRA7xx
> 
> I haven't gotten all the way through this series yet, but don't bother
> with
> a v12 just for these minor changes.  I can easily fix them up when
> applying
> it.

Great Many Thanks for this!

Gab

> 
> Bjorn
> --
> 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
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

RE: [PATCH v11 1/6] PCI: designware: move calculation of bus addresses to DRA7xx

2015-10-22 Thread Gabriele Paoloni

> -Original Message-
> From: Bjorn Helgaas [mailto:helg...@kernel.org]
> Sent: 21 October 2015 23:15
> To: Wangzhou (B)
> Cc: Bjorn Helgaas; jingooh...@gmail.com; pratyush.an...@gmail.com; Arnd
> Bergmann; li...@arm.linux.org.uk; thomas.petazz...@free-electrons.com;
> Gabriele Paoloni; lorenzo.pieral...@arm.com; james.mo...@arm.com;
> liviu.du...@arm.com; ja...@lakedaemon.net; r...@kernel.org;
> gabriel.fernan...@linaro.org; minghuan.l...@freescale.com; linux-
> p...@vger.kernel.org; linux-arm-ker...@lists.infradead.org;
> devicetree@vger.kernel.org; linux-ker...@vger.kernel.org; zhangjukuo;
> qiuzhenfa; liudongdong (C); qiujiang; xuwei (O); Liguozhu (Kenneth)
> Subject: Re: [PATCH v11 1/6] PCI: designware: move calculation of bus
> addresses to DRA7xx
> 
> Hi Zhou & Gabriele,

Hi Bjorn, thanks for reviewing

> 
> On Fri, Oct 16, 2015 at 06:23:36PM +0800, Zhou Wang wrote:
> > From: gabriele paoloni 
> >
> > Commit f4c55c5a3f7f ("PCI: designware: Program ATU with untranslated
> > address") added the calculation of PCI BUS addresses in designware,
> > storing them in new fields added in "struct pcie_port". This
> > calculation is done for every designware user even if is only
> > applicable to DRA7xx.
> > This patch moves the calculation of the bus addresses to the DRA7xx
> > driver and is needed to allow the rework of designware to use
> > the new DT parsing API.
> >
> > Signed-off-by: Gabriele Paoloni 
> > Signed-off-by: Zhou Wang 
> > Acked-by: Pratyush Anand 
> > ---
> >  drivers/pci/host/pci-dra7xx.c  | 13 +
> >  drivers/pci/host/pcie-designware.c | 15 ---
> >  2 files changed, 17 insertions(+), 11 deletions(-)
> >
> > diff --git a/drivers/pci/host/pci-dra7xx.c b/drivers/pci/host/pci-dra7xx.c
> > index 199e29a..ebdffa0 100644
> > --- a/drivers/pci/host/pci-dra7xx.c
> > +++ b/drivers/pci/host/pci-dra7xx.c
> > @@ -62,6 +62,7 @@
> >
> >  #definePCIECTRL_DRA7XX_CONF_PHY_CS 0x010C
> >  #defineLINK_UP BIT(16)
> > +#defineCPU_TO_BUS_ADDR 0x0FFF
> 
> "CPU_TO_BUS_ADDR" is a very generic name.  Since you do have DRA7XX in
> other #defines and static symbols in this file, maybe it could be DRA7XX to
> make it obvious that it only applies here?

Ok will change to DRA7XX_CPU_TO_BUS_ADRR in v12

> 
> >
> >  struct dra7xx_pcie {
> > void __iomem*base;
> > @@ -151,6 +152,18 @@ static void dra7xx_pcie_enable_interrupts(struct
> pcie_port *pp)
> >  static void dra7xx_pcie_host_init(struct pcie_port *pp)
> >  {
> > dw_pcie_setup_rc(pp);
> > +
> > +   if (pp->io_mod_base)
> > +   pp->io_mod_base &= CPU_TO_BUS_ADDR;
> 
> These are equivalent to
> 
>   pp->io_mod_base &= CPU_TO_BUS_ADDR;
> 
> (You don't need to test whether they're zero first.)
> 

Yes agreed, will change in v12

> > +
> > +   if (pp->mem_mod_base)
> > +   pp->mem_mod_base &= CPU_TO_BUS_ADDR;
> > +
> > +   if (pp->cfg0_mod_base) {
> > +   pp->cfg0_mod_base &= CPU_TO_BUS_ADDR;
> > +   pp->cfg1_mod_base &= CPU_TO_BUS_ADDR;
> > +   }
> > +
> > dra7xx_pcie_establish_link(pp);
> > if (IS_ENABLED(CONFIG_PCI_MSI))
> > dw_pcie_msi_init(pp);
> > diff --git a/drivers/pci/host/pcie-designware.c b/drivers/pci/host/pcie-
> designware.c
> > index 52aa6e3..75338a6 100644
> > --- a/drivers/pci/host/pcie-designware.c
> > +++ b/drivers/pci/host/pcie-designware.c
> > @@ -365,14 +365,10 @@ int dw_pcie_host_init(struct pcie_port *pp)
> > struct of_pci_range range;
> > struct of_pci_range_parser parser;
> > struct resource *cfg_res;
> > -   u32 val, na, ns;
> > +   u32 val, ns;
> > const __be32 *addrp;
> > int i, index, ret;
> >
> > -   /* Find the address cell size and the number of cells in order to get
> > -* the untranslated address.
> > -*/
> > -   of_property_read_u32(np, "#address-cells", &na);
> > ns = of_n_size_cells(np);
> >
> > cfg_res = platform_get_resource_byname(pdev, IORESOURCE_MEM, "config");
> > @@ -415,8 +411,7 @@ int dw_pcie_host_init(struct pcie_port *pp)
> > pp->io_base = range.cpu_addr;
> >
> > /* Find the untranslated IO space address */
> > -   pp->io_mod_base = of_read_number(parser.range -
> &

RE: [PATCH v10 4/6] PCI: hisi: Add PCIe host support for HiSilicon SoC Hip05

2015-10-14 Thread Gabriele Paoloni



> -Original Message-
> From: Arnd Bergmann [mailto:a...@arndb.de]
> Sent: Wednesday, October 14, 2015 10:42 AM
> To: Gabriele Paoloni
> Cc: Wangzhou (B); Bjorn Helgaas; Bjorn Helgaas; jingooh...@gmail.com;
> pratyush.an...@gmail.com; li...@arm.linux.org.uk;
> thomas.petazz...@free-electrons.com; lorenzo.pieral...@arm.com;
> james.mo...@arm.com; liviu.du...@arm.com; ja...@lakedaemon.net;
> r...@kernel.org; gabriel.fernan...@linaro.org;
> minghuan.l...@freescale.com; linux-...@vger.kernel.org; linux-arm-
> ker...@lists.infradead.org; devicetree@vger.kernel.org; linux-
> ker...@vger.kernel.org; zhangjukuo; qiuzhenfa; liudongdong (C);
> qiujiang; xuwei (O); Liguozhu (Kenneth); Wangkefeng (Kevin); Rob
> Herring
> Subject: Re: [PATCH v10 4/6] PCI: hisi: Add PCIe host support for
> HiSilicon SoC Hip05
> 
> On Wednesday 14 October 2015 09:31:48 Gabriele Paoloni wrote:
> > >
> > > > To me it sounds more appropriate to adopt subsys_initcall() for
> all
> > > the
> > > > PCI Host Bridge controllers rather than having them as loadable
> > > modules...
> > > >
> > > > What is your view?
> > >
> > > subsys_initcall() sounds odd because it's a driver rather than a
> > > subsystem,
> > > but I realize that most of the other levels don't fit any better.
> >
> > Yes well I was seeing for example the vgaarb
> > http://lxr.free-electrons.com/source/drivers/gpu/vga/vgaarb.c#L1357
> >
> > That in the init is calling pci_get_subsys()
> >
> > So I was wondering that the PCI devices may not be registered unless
> > we also init the PCI host bridge through subsys_initcall()...
> 
> I think this should work as is: the code first looks for devices
> that are already there and then registers a notifier for devices
> that show up later. This is meant to work for both devices that
> are hotplugged at a later point as well as PCI buses that are
> already there but not yet probed.
> 
> > But then maybe is the vgaarb to be buggy...
> 
> Possible. It may well be that the code is only tested on x86,
> which always probes its PCI very early.
> 
> > > As I said, it's not really a choice we have to make in the source
> code,
> > > we can use subsys_initcall together with module_exit(), or we can
> > > create a helper macro that is similar to module_platform_driver()
> > > specifically for PCI that uses a particular initcall level.
> >
> > Ok got it. But I guess this needs to be thought and applied to all
> > the PCI host bridge controllers...
> >
> > So maybe for this driver I can use module_platform_driver_probe()
> > and then we can see...
> 
> Sounds good. Let's focus on getting the driver merged first and
> then follow up with a patch to get this right for all PCI hosts.

Ok good let's do like this then

will change in v11

Again Many Thanks

Gab

> 
>   Arnd
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

RE: [PATCH v10 4/6] PCI: hisi: Add PCIe host support for HiSilicon SoC Hip05

2015-10-14 Thread Gabriele Paoloni



> -Original Message-
> From: Arnd Bergmann [mailto:a...@arndb.de]
> Sent: Wednesday, October 14, 2015 10:04 AM
> To: Gabriele Paoloni
> Cc: Wangzhou (B); Bjorn Helgaas; Bjorn Helgaas; jingooh...@gmail.com;
> pratyush.an...@gmail.com; li...@arm.linux.org.uk;
> thomas.petazz...@free-electrons.com; lorenzo.pieral...@arm.com;
> james.mo...@arm.com; liviu.du...@arm.com; ja...@lakedaemon.net;
> r...@kernel.org; gabriel.fernan...@linaro.org;
> minghuan.l...@freescale.com; linux-...@vger.kernel.org; linux-arm-
> ker...@lists.infradead.org; devicetree@vger.kernel.org; linux-
> ker...@vger.kernel.org; zhangjukuo; qiuzhenfa; liudongdong (C);
> qiujiang; xuwei (O); Liguozhu (Kenneth); Wangkefeng (Kevin); Rob
> Herring
> Subject: Re: [PATCH v10 4/6] PCI: hisi: Add PCIe host support for
> HiSilicon SoC Hip05
> 
> On Wednesday 14 October 2015 08:34:43 Gabriele Paoloni wrote:
> > > -Original Message-
> > > From: Arnd Bergmann [mailto:a...@arndb.de]
> > > Sent: Tuesday, October 13, 2015 12:19 PM
> > > To: Gabriele Paoloni
> > > Cc: Wangzhou (B); Bjorn Helgaas; Bjorn Helgaas;
> jingooh...@gmail.com;
> > > pratyush.an...@gmail.com; li...@arm.linux.org.uk;
> > > thomas.petazz...@free-electrons.com; lorenzo.pieral...@arm.com;
> > > james.mo...@arm.com; liviu.du...@arm.com; ja...@lakedaemon.net;
> > > r...@kernel.org; gabriel.fernan...@linaro.org;
> > > minghuan.l...@freescale.com; linux-...@vger.kernel.org; linux-arm-
> > > ker...@lists.infradead.org; devicetree@vger.kernel.org; linux-
> > > ker...@vger.kernel.org; zhangjukuo; qiuzhenfa; liudongdong (C);
> > > qiujiang; xuwei (O); Liguozhu (Kenneth); Wangkefeng (Kevin); Rob
> > > Herring
> > > Subject: Re: [PATCH v10 4/6] PCI: hisi: Add PCIe host support for
> > > HiSilicon SoC Hip05
> > >
> > > On Tuesday 13 October 2015 06:58:42 Gabriele Paoloni wrote:
> > > >
> > > > > >> +
> > > > > >> +static int __init hisi_pcie_init(void)
> > > > > >> +{
> > > > > >> +  return platform_driver_probe(&hisi_pcie_driver,
> > > hisi_pcie_probe);
> > > > > >> +}
> > > > > >> +subsys_initcall(hisi_pcie_init);
> > > > > >
> > > > > > Can you use module_platform_driver() or
> > > module_platform_driver_probe()
> > > > > > here instead of the subsys_initcall()?  No, I don't really
> know
> > > what
> > > > > > the difference between module_platform_driver() and
> > > > > > module_platform_driver_probe() is, sorry
> > >
> > > module_platform_driver_probe() will only call the probe function
> once
> > > (and fail in case of -EPROBE_DEFER), while module_platform_driver()
> > > installs the platform driver in a way that the device can be bound
> > > and unbound at any point.
> > >
> > > > > In fact, I used module_platform_driver_probe in previous
> version,
> > > but
> > > > > A PCIe VGA card of HiSilicon will use Hip05 PCIe host, so we
> > > modified
> > > > > module_platform_driver_probe to subsys_initcall which will be
> > > called
> > > > > before module_platform_driver_probe.
> > > > >
> > > > > We will upstream the driver of above PCIe VGA card soon.
> > >
> > > I don't see a reason why a VGA driver would need the PCI host to be
> > > probed this early, unless it is the only usable console in the
> system.
> > >
> > > > Hi Bjorn, firstly many thanks for looking at this.
> > > >
> > > > About this last bit the reason why we use subsys_initcall() is
> that
> > > > our host bridge is embedded in the SoC and as such is not hot-
> > > pluggable
> > > > for instance see:
> > > > http://lxr.free-electrons.com/source/Documentation/driver-
> > > model/platform.txt#L59
> > >
> > > We should still be able to build the driver as a loadable module,
> > > even if you don't do that on your own kernels.
> >
> > Hi Arnd, I don't see the point of having loadable KOs for platform
> > devices that are integrated into SoCs (like PCIe Host Controllers...)
> 
> Mainly we want as many drivers as possible to be loadable modules,
> and there is no reason why PCI needs to be different from other
> subsystems here.

Ok I see now. Thanks

> 
> > > This doesn't mean that it has to be module_platform_driver,
> > > subsys_initc

RE: [PATCH v10 4/6] PCI: hisi: Add PCIe host support for HiSilicon SoC Hip05

2015-10-14 Thread Gabriele Paoloni



> -Original Message-
> From: Arnd Bergmann [mailto:a...@arndb.de]
> Sent: Tuesday, October 13, 2015 12:19 PM
> To: Gabriele Paoloni
> Cc: Wangzhou (B); Bjorn Helgaas; Bjorn Helgaas; jingooh...@gmail.com;
> pratyush.an...@gmail.com; li...@arm.linux.org.uk;
> thomas.petazz...@free-electrons.com; lorenzo.pieral...@arm.com;
> james.mo...@arm.com; liviu.du...@arm.com; ja...@lakedaemon.net;
> r...@kernel.org; gabriel.fernan...@linaro.org;
> minghuan.l...@freescale.com; linux-...@vger.kernel.org; linux-arm-
> ker...@lists.infradead.org; devicetree@vger.kernel.org; linux-
> ker...@vger.kernel.org; zhangjukuo; qiuzhenfa; liudongdong (C);
> qiujiang; xuwei (O); Liguozhu (Kenneth); Wangkefeng (Kevin); Rob
> Herring
> Subject: Re: [PATCH v10 4/6] PCI: hisi: Add PCIe host support for
> HiSilicon SoC Hip05
> 
> On Tuesday 13 October 2015 06:58:42 Gabriele Paoloni wrote:
> >
> > > >> +
> > > >> +static int __init hisi_pcie_init(void)
> > > >> +{
> > > >> +  return platform_driver_probe(&hisi_pcie_driver,
> hisi_pcie_probe);
> > > >> +}
> > > >> +subsys_initcall(hisi_pcie_init);
> > > >
> > > > Can you use module_platform_driver() or
> module_platform_driver_probe()
> > > > here instead of the subsys_initcall()?  No, I don't really know
> what
> > > > the difference between module_platform_driver() and
> > > > module_platform_driver_probe() is, sorry :)
> 
> module_platform_driver_probe() will only call the probe function once
> (and fail in case of -EPROBE_DEFER), while module_platform_driver()
> installs the platform driver in a way that the device can be bound
> and unbound at any point.
> 
> > > In fact, I used module_platform_driver_probe in previous version,
> but
> > > A PCIe VGA card of HiSilicon will use Hip05 PCIe host, so we
> modified
> > > module_platform_driver_probe to subsys_initcall which will be
> called
> > > before module_platform_driver_probe.
> > >
> > > We will upstream the driver of above PCIe VGA card soon.
> 
> I don't see a reason why a VGA driver would need the PCI host to be
> probed this early, unless it is the only usable console in the system.
> 
> > Hi Bjorn, firstly many thanks for looking at this.
> >
> > About this last bit the reason why we use subsys_initcall() is that
> > our host bridge is embedded in the SoC and as such is not hot-
> pluggable
> > for instance see:
> > http://lxr.free-electrons.com/source/Documentation/driver-
> model/platform.txt#L59
> 
> We should still be able to build the driver as a loadable module,
> even if you don't do that on your own kernels.

Hi Arnd, I don't see the point of having loadable KOs for platform
devices that are integrated into SoCs (like PCIe Host Controllers...)

> 
> This doesn't mean that it has to be module_platform_driver,
> subsys_initcall
> will also work in a loadable module, it just won't be as early. However,
> we should try to come up with a consistent approach for all PCI host
> drivers,
> I don't see any reason for hisi to be different from the others here.

To me it sounds more appropriate to adopt subsys_initcall() for all the
PCI Host Bridge controllers rather than having them as loadable modules...

What is your view?

Thanks

Gab

> 
> > Our approach is also used by Exynos:
> > http://lxr.free-electrons.com/source/drivers/pci/host/pci-
> exynos.c#L644
> 
> Maybe we should change that too.
> 
>   Arnd
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

RE: [PATCH v10 4/6] PCI: hisi: Add PCIe host support for HiSilicon SoC Hip05

2015-10-13 Thread Gabriele Paoloni



> -Original Message-
> From: Arnd Bergmann [mailto:a...@arndb.de]
> Sent: Tuesday, October 13, 2015 12:12 PM
> To: Bjorn Helgaas
> Cc: Wangzhou (B); Bjorn Helgaas; jingooh...@gmail.com;
> pratyush.an...@gmail.com; li...@arm.linux.org.uk;
> thomas.petazz...@free-electrons.com; Gabriele Paoloni;
> lorenzo.pieral...@arm.com; james.mo...@arm.com; liviu.du...@arm.com;
> ja...@lakedaemon.net; r...@kernel.org; gabriel.fernan...@linaro.org;
> minghuan.l...@freescale.com; linux-...@vger.kernel.org; linux-arm-
> ker...@lists.infradead.org; devicetree@vger.kernel.org; linux-
> ker...@vger.kernel.org; zhangjukuo; qiuzhenfa; liudongdong (C);
> qiujiang; xuwei (O); Liguozhu (Kenneth); Wangkefeng (Kevin); Rob
> Herring
> Subject: Re: [PATCH v10 4/6] PCI: hisi: Add PCIe host support for
> HiSilicon SoC Hip05
> 
> On Monday 12 October 2015 16:35:45 Bjorn Helgaas wrote:
> >
> > > +{
> > > + u64 addr;
> > > + struct device_node *msi_node;
> > > + struct resource res;
> > > + struct device_node *np = pp->dev->of_node;
> > > + struct hisi_pcie *pcie = to_hisi_pcie(pp);
> > > +
> > > + msi_node = of_parse_phandle(np, "msi-parent", 0);
> > > + if (!msi_node) {
> > > + dev_err(pp->dev, "failed to find msi-parent\n");
> > > + return -EINVAL;
> > > + }
> > > + of_address_to_resource(msi_node, 0, &res);
> >
> > Does this use the "msi-parent" node in the same way as other drivers
> > do?  I'm sure there must be other places where we extract struct
> > resource information from an "msi-parent" node, but I don't see them.
> >
> > I'm trying to verify that this isn't some kind of incompatible
> > extension of the "msi-parent" property.  I cc'd Arnd and Rob (DT
> > experts).
> 
> This is not ok, what this does is that it relies on a particular
> implementation of the MSI controller and directly accesses its
> registers.

Hi Arnd, thanks for reviewing.

What we do is to retrieve the msi-parent physical address and we store it
in our internal PCIe register locations...

So we do not operate directly on the msi controller registers...

So I wonder if the current implementation is Ok to retrieve the
msi-parent address

Thanks

Gab


> 
> Instead, it should reference only the msi irq domain and let the
> driver for the MSI controller access the registers. Otherwise this
> code has to be rewritten once the same PCI host code appears in
> a machine that has a real GICv2m or GICv3.
> 
>   Arnd
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

RE: [PATCH v10 4/6] PCI: hisi: Add PCIe host support for HiSilicon SoC Hip05

2015-10-12 Thread Gabriele Paoloni


> >> +
> >> +static int __init hisi_pcie_init(void)
> >> +{
> >> +  return platform_driver_probe(&hisi_pcie_driver, hisi_pcie_probe);
> >> +}
> >> +subsys_initcall(hisi_pcie_init);
> >
> > Can you use module_platform_driver() or module_platform_driver_probe()
> > here instead of the subsys_initcall()?  No, I don't really know what
> > the difference between module_platform_driver() and
> > module_platform_driver_probe() is, sorry :)
> 
> In fact, I used module_platform_driver_probe in previous version, but
> A PCIe VGA card of HiSilicon will use Hip05 PCIe host, so we modified
> module_platform_driver_probe to subsys_initcall which will be called
> before module_platform_driver_probe.
> 
> We will upstream the driver of above PCIe VGA card soon.
> 
> Many thanks for your reviewing,
> Zhou

Hi Bjorn, firstly many thanks for looking at this.

About this last bit the reason why we use subsys_initcall() is that
our host bridge is embedded in the SoC and as such is not hot-pluggable
for instance see:
http://lxr.free-electrons.com/source/Documentation/driver-model/platform.txt#L59

Our approach is also used by Exynos:
http://lxr.free-electrons.com/source/drivers/pci/host/pci-exynos.c#L644

Cheers

Gab

> 
> >
> > Bjorn
> >
> > .
> >
> 

--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

RE: [PATCH v8 0/6] PCI: hisi: Add PCIe host support for HiSilicon SoC Hip05

2015-09-07 Thread Gabriele Paoloni

Hi Bjorn and all

Do you have any comment on this patchset? I think we should be close to a final 
one...

Thanks and Regards

Gab

> -Original Message-
> From: Wangzhou (B)
> Sent: 25 August 2015 10:59
> To: Bjorn Helgaas; jingooh...@gmail.com; pratyush.an...@gmail.com; Arnd
> Bergmann; li...@arm.linux.org.uk; thomas.petazz...@free-electrons.com;
> Gabriele Paoloni; lorenzo.pieral...@arm.com; james.mo...@arm.com;
> liviu.du...@arm.com; ja...@lakedaemon.net; r...@kernel.org
> Cc: linux-...@vger.kernel.org; linux-arm-ker...@lists.infradead.org;
> devicetree@vger.kernel.org; zhangjukuo; qiuzhenfa; liudongdong (C); qiujiang;
> xuwei (O); Liguozhu (Kenneth); Wangzhou (B)
> Subject: [PATCH v8 0/6] PCI: hisi: Add PCIe host support for HiSilicon SoC
> Hip05
> 
> This patchset adds PCIe host support for HiSilicon SoC Hip05. The PCIe hosts
> use PCIe IP core from Synopsys, So this driver is base on designware PCIe
> driver.
> 
> Hip05 is an ARMv8 architecture SoC. It should be able to use ARM64 PCIe API in
> designeware PCIe driver. So this patch also adds ARM64 support for designware
> pcie.
> 
> This patchset is based on v4.2-rc1.
> 
> Change from v7:
> - Remove pp->root_bus_nr = 0 in dra7xx, exynos, imx6, keystone, layerscape,
>   spear13xx. Pass pp->busn->start to pci_create_root_bus as root bus number.
> - Remove bus-range parsing in pcie-hisi.c.
> 
> Change from v6:
> - Add Pratyush's Acked-by for 1/6 and 2/6.
> - Add James' Tested-by for 3/6.
> 
> Change from v5:
> - Merge 1/6 in this series, discussion about this can be found in [1]
> 
> Change from v4:
> - Change the author of 1/5 to Gabriele.
> - Modify problems in 3/5 pointed by Bjorn.
> - Modify spelling problems in 4/5.
> 
> Change from v3:
> - Change 1/5 to what Gabriele suggested.
> - Use win->__res.start to get *_mod_base in 2/5, this fix a bug in v3 series.
> 
> Change from v2:
> - Move struct pci_dev *dev and struct pci_sys_data *sys in
>   pcibios_align_resource in 1/5.
> - Add Gabriele's codes in 2/5 which delete unnecessary information parse and
>   use of_pci_get_host_bridge_resources for both ARM32 and ARM64.
> - Add maintainer patch 5/5.
> 
> Change from RFC v1:
> - Add 1/4 patch by Arnd which removes align_resource callback in ARM
>   pcibios_align_resource.
> - Change head file in pcie-designware from asm/hardirq.h to linux/hardirq.h.
> - Set pp->root_bus_nr = 0 in dra7xx, exynos, imx6, keystone, layerscape,
>   spear13xx.
> - Remove unnecessary parentheses of some macros in pcie-hisi.
> - Use macro to replace some magic values.
> - Merge two loops together and add some comments about it in context_config
>   function in pcie-hisi.
> - Modify some value of items in pcie node example in binding document.
> 
> Change from RFC:
> - delete dw_pcie_setup, dw_pcie_scan_bus, dw_pcie_map_irq and struct hw_pci,
>   merge related operations into dw_pcie_host_init.
> 
> Link of v7:
> - http://www.spinics.net/lists/devicetree/msg90690.html
> Link of v6:
> - http://www.spinics.net/lists/linux-pci/msg43669.html
> Link of v5:
> - http://www.spinics.net/lists/devicetree/msg87959.html
> Link of v4:
> - http://www.spinics.net/lists/arm-kernel/msg433050.html
> Link of v3:
> - http://www.spinics.net/lists/linux-pci/msg42539.html
> Link of v2:
> - http://www.spinics.net/lists/linux-pci/msg41844.html
> Link of RFC v1:
> - http://www.spinics.net/lists/linux-pci/msg41305.html
> Link of RFC:
> - http://www.spinics.net/lists/linux-pci/msg40434.html
> 
> [1] http://lists.infradead.org/pipermail/linux-arm-kernel/2015-
> July/359741.html
> 
> 
> Zhou Wang (4):
>   PCI: designware: Add ARM64 support
>   PCI: hisi: Add PCIe host support for HiSilicon SoC Hip05
>   Documentation: DT: Add HiSilicon PCIe host binding
>   MAINTAINERS: Add pcie-hisi maintainer
> 
> gabriele paoloni (2):
>   PCI: designware: move calculation of bus addresses to DRA7xx
>   ARM/PCI: remove align_resource in pci_sys_data
> 
>  .../devicetree/bindings/pci/hisilicon-pcie.txt |  46 
>  MAINTAINERS|   7 +
>  arch/arm/include/asm/mach/pci.h|   5 -
>  arch/arm/kernel/bios32.c   |  12 +-
>  drivers/pci/host/Kconfig   |   8 +
>  drivers/pci/host/Makefile  |   1 +
>  drivers/pci/host/pci-dra7xx.c  |  13 ++
>  drivers/pci/host/pci-keystone-dw.c |   2 +-
>  drivers/pci/host/pcie-designware.c | 237 +++-
>  drivers/pci/host/pcie-designware.h |  14 +-
>  drivers/pci/host/pcie-hisi.c   | 247
> +
>  11 files changed, 413 insertions(+), 179 deletions(-)
>  create mode 100644 Documentation/devicetree/bindings/pci/hisilicon-pcie.txt
>  create mode 100644 drivers/pci/host/pcie-hisi.c
> 
> --
> 1.9.1

RE: [PATCH v8 3/6] PCI: designware: Add ARM64 support

2015-08-27 Thread Gabriele Paoloni

> -Original Message-
> From: linux-pci-ow...@vger.kernel.org [mailto:linux-pci-ow...@vger.kernel.org]
> On Behalf Of Gabriel Fernandez
> Sent: 27 August 2015 13:57
> To: Wangzhou (B)
> Cc: Bjorn Helgaas; jingooh...@gmail.com; pratyush.an...@gmail.com; Arnd
> Bergmann; Russell King; thomas.petazz...@free-electrons.com; Gabriele Paoloni;
> lorenzo.pieral...@arm.com; james.mo...@arm.com; Liviu Dudau;
> ja...@lakedaemon.net; r...@kernel.org; devicetree@vger.kernel.org; linux-
> p...@vger.kernel.org; xuwei (O); qiuzhenfa; liudongdong (C); zhangjukuo;
> Liguozhu (Kenneth); qiujiang; linux-arm-ker...@lists.infradead.org
> Subject: Re: [PATCH v8 3/6] PCI: designware: Add ARM64 support
> 
> Hi Zhou,
> 
> You can add my Tested-by: Gabriel Fernandez 
> 
> I tested your patchset with a STMicroelectronics PCIe controller.
> This controller is based on designware PCIe driver and works on ARM32.
> 
> Please find my patchset here:
> http://www.spinics.net/lists/kernel/msg2064266.html
> 
> Best Regards.
> 
> Gabriel.

Many Thanks for this Gabriel

Cheers
Gab

> 
> On 25 August 2015 at 11:58, Zhou Wang  wrote:
> > This patch tries to unify ARM32 and ARM64 PCIe in designware driver. Delete
> > function dw_pcie_setup, dw_pcie_scan_bus, dw_pcie_map_irq and struct hw_pci,
> > move related operations to dw_pcie_host_init.
> >
> > This patch also try to use of_pci_get_host_bridge_resources for ARM32 and
> ARM64
> > according to the suggestion for Gabriele[1]
> >
> > Finally this patch reverts commit f4c55c5a3f7f "PCI: designware: Program ATU
> > with untranslated address" based on 1/6 in this series. we delete *_mod_base
> in
> > pcie-designware. This was discussed in [2]
> >
> > I have compiled the driver with multi_v7_defconfig. However, I don't have
> > ARM32 PCIe related board to do test. It will be appreciated if someone could
> > help to test it.
> >
> > Signed-off-by: Zhou Wang 
> > Signed-off-by: Gabriele Paoloni 
> > Signed-off-by: Arnd Bergmann 
> > Tested-By: James Morse 
> >
> > [1] http://www.spinics.net/lists/linux-pci/msg42194.html
> > [2] http://www.spinics.net/lists/arm-kernel/msg436779.html
> > ---
> >  drivers/pci/host/pci-dra7xx.c  |  14 +--
> >  drivers/pci/host/pci-keystone-dw.c |   2 +-
> >  drivers/pci/host/pcie-designware.c | 230 +-
> ---
> >  drivers/pci/host/pcie-designware.h |  14 +--
> >  4 files changed, 90 insertions(+), 170 deletions(-)
> >
> > diff --git a/drivers/pci/host/pci-dra7xx.c b/drivers/pci/host/pci-dra7xx.c
> > index 18ae7ff..ac401be 100644
> > --- a/drivers/pci/host/pci-dra7xx.c
> > +++ b/drivers/pci/host/pci-dra7xx.c
> > @@ -141,15 +141,15 @@ static void dra7xx_pcie_host_init(struct pcie_port 
> > *pp)
> >  {
> > dw_pcie_setup_rc(pp);
> >
> > -   if (pp->io_mod_base)
> > -   pp->io_mod_base &= CPU_TO_BUS_ADDR;
> > +   if (pp->io_base)
> > +   pp->io_base &= CPU_TO_BUS_ADDR;
> >
> > -   if (pp->mem_mod_base)
> > -   pp->mem_mod_base &= CPU_TO_BUS_ADDR;
> > +   if (pp->mem_base)
> > +   pp->mem_base &= CPU_TO_BUS_ADDR;
> >
> > -   if (pp->cfg0_mod_base) {
> > -   pp->cfg0_mod_base &= CPU_TO_BUS_ADDR;
> > -   pp->cfg1_mod_base &= CPU_TO_BUS_ADDR;
> > +   if (pp->cfg0_base) {
> > +   pp->cfg0_base &= CPU_TO_BUS_ADDR;
> > +   pp->cfg1_base &= CPU_TO_BUS_ADDR;
> > }
> >
> > dra7xx_pcie_establish_link(pp);
> > diff --git a/drivers/pci/host/pci-keystone-dw.c b/drivers/pci/host/pci-
> keystone-dw.c
> > index f34892e..b1e4135 100644
> > --- a/drivers/pci/host/pci-keystone-dw.c
> > +++ b/drivers/pci/host/pci-keystone-dw.c
> > @@ -327,7 +327,7 @@ static void ks_dw_pcie_clear_dbi_mode(void __iomem
> *reg_virt)
> >  void ks_dw_pcie_setup_rc_app_regs(struct keystone_pcie *ks_pcie)
> >  {
> > struct pcie_port *pp = &ks_pcie->pp;
> > -   u32 start = pp->mem.start, end = pp->mem.end;
> > +   u32 start = pp->mem->start, end = pp->mem->end;
> > int i, tr_size;
> >
> > /* Disable BARs for inbound access */
> > diff --git a/drivers/pci/host/pcie-designware.c b/drivers/pci/host/pcie-
> designware.c
> > index c5d407c..e2d1898 100644
> > --- a/drivers/pci/host/pcie-designware.c
> > +++ b/drivers/pci/host/pcie-designware.c
> >

RE: [PATCH v7 3/6] PCI: designware: Add ARM64 support

2015-08-24 Thread Gabriele Paoloni



> -Original Message-
> From: Wangzhou (B)
> Sent: Monday, August 24, 2015 7:26 AM
> To: Gabriele Paoloni
> Cc: Liviu Dudau; Lucas Stach; Bjorn Helgaas; jingooh...@gmail.com;
> Pratyush Anand; Arnd Bergmann; li...@arm.linux.org.uk;
> thomas.petazz...@free-electrons.com; Lorenzo Pieralisi; James Morse;
> ja...@lakedaemon.net; r...@kernel.org; linux-...@vger.kernel.org;
> linux-arm-ker...@lists.infradead.org; devicetree@vger.kernel.org;
> Yuanzhichang; Zhudacai; zhangjukuo; qiuzhenfa; liudongdong (C);
> qiujiang; xuwei (O); Liguozhu (Kenneth)
> Subject: Re: [PATCH v7 3/6] PCI: designware: Add ARM64 support
> 
> On 2015/8/21 22:19, Gabriele Paoloni wrote:
> > Hi Liviu
> >
> > Many Thanks for reviewing
> >
> >> -Original Message-
> >> From: linux-pci-ow...@vger.kernel.org [mailto:linux-pci-
> >> ow...@vger.kernel.org] On Behalf Of Liviu Dudau
> >> Sent: Friday, August 21, 2015 2:43 PM
> >> To: Gabriele Paoloni
> >> Cc: Lucas Stach; Wangzhou (B); Bjorn Helgaas; jingooh...@gmail.com;
> >> Pratyush Anand; Arnd Bergmann; li...@arm.linux.org.uk;
> >> thomas.petazz...@free-electrons.com; Lorenzo Pieralisi; James Morse;
> >> ja...@lakedaemon.net; r...@kernel.org; linux-...@vger.kernel.org;
> >> linux-arm-ker...@lists.infradead.org; devicetree@vger.kernel.org;
> >> Yuanzhichang; Zhudacai; zhangjukuo; qiuzhenfa; liudongdong (C);
> >> qiujiang; xuwei (O); Liguozhu (Kenneth)
> >> Subject: Re: [PATCH v7 3/6] PCI: designware: Add ARM64 support
> >>
> >> On Thu, Aug 20, 2015 at 12:10:24PM +0100, Gabriele Paoloni wrote:
> >>> Hi Lucas
> >>>
> >>> Again many thanks for explaining and for your time.
> >>>
> >>> I got your point now and I have dug a bit better in the PCI_DOMAINS
> >> code.
> >>>
> >>> However I have a question...see inline below
> >>>
> >>>> -Original Message-
> >>>> From: Lucas Stach [mailto:l.st...@pengutronix.de]
> >>>> Sent: Thursday, August 20, 2015 9:27 AM
> >>>> To: Gabriele Paoloni
> >>>> Cc: Wangzhou (B); Bjorn Helgaas; jingooh...@gmail.com; Pratyush
> >> Anand;
> >>>> Arnd Bergmann; li...@arm.linux.org.uk; thomas.petazzoni@free-
> >>>> electrons.com; lorenzo.pieral...@arm.com; james.mo...@arm.com;
> >>>> liviu.du...@arm.com; ja...@lakedaemon.net; r...@kernel.org; linux-
> >>>> p...@vger.kernel.org; linux-arm-ker...@lists.infradead.org;
> >>>> devicetree@vger.kernel.org; Yuanzhichang; Zhudacai; zhangjukuo;
> >>>> qiuzhenfa; liudongdong (C); qiujiang; xuwei (O); Liguozhu (Kenneth)
> >>>> Subject: Re: [PATCH v7 3/6] PCI: designware: Add ARM64 support
> >>>>
> >>>> Hi Gab,
> >>>>
> >>>> Am Mittwoch, den 19.08.2015, 16:34 + schrieb Gabriele Paoloni:
> >>>>> Hi Lucas
> >>>>>
> >>>>> First of all many thanks for the quick reply, really appreciated
> >>>>>
> >>>>>> -Original Message-
> >>>>>> From: Lucas Stach [mailto:l.st...@pengutronix.de]
> >>>>>> Sent: Wednesday, August 19, 2015 4:37 PM
> >>>>>> To: Gabriele Paoloni
> >>>>>> Cc: Wangzhou (B); Bjorn Helgaas; jingooh...@gmail.com; Pratyush
> >>>> Anand;
> >>>>>> Arnd Bergmann; li...@arm.linux.org.uk; thomas.petazzoni@free-
> >>>>>> electrons.com; lorenzo.pieral...@arm.com; james.mo...@arm.com;
> >>>>>> liviu.du...@arm.com; ja...@lakedaemon.net; r...@kernel.org;
> >> linux-
> >>>>>> p...@vger.kernel.org; linux-arm-ker...@lists.infradead.org;
> >>>>>> devicetree@vger.kernel.org; Yuanzhichang; Zhudacai; zhangjukuo;
> >>>>>> qiuzhenfa; liudongdong (C); qiujiang; xuwei (O); Liguozhu
> >> (Kenneth)
> >>>>>> Subject: Re: [PATCH v7 3/6] PCI: designware: Add ARM64 support
> >>>>>>
> >>>>>> Hi Gab,
> >>>>>>
> >>>>>> Am Mittwoch, den 19.08.2015, 15:16 + schrieb Gabriele
> >> Paoloni:
> >>>>>>> Hi Lucas
> >>>>>>>
> >>>>>>> I have rewritten the patch to take into account multiple
> >>>> controllers.
> >>>>>>>
> >>>>>>> As you can see now there is a static var in
> >> dw_pcie_host_init()
> &g

RE: [PATCH v7 3/6] PCI: designware: Add ARM64 support

2015-08-21 Thread Gabriele Paoloni

Hi Liviu

Many Thanks for reviewing

> -Original Message-
> From: linux-pci-ow...@vger.kernel.org [mailto:linux-pci-
> ow...@vger.kernel.org] On Behalf Of Liviu Dudau
> Sent: Friday, August 21, 2015 2:43 PM
> To: Gabriele Paoloni
> Cc: Lucas Stach; Wangzhou (B); Bjorn Helgaas; jingooh...@gmail.com;
> Pratyush Anand; Arnd Bergmann; li...@arm.linux.org.uk;
> thomas.petazz...@free-electrons.com; Lorenzo Pieralisi; James Morse;
> ja...@lakedaemon.net; r...@kernel.org; linux-...@vger.kernel.org;
> linux-arm-ker...@lists.infradead.org; devicetree@vger.kernel.org;
> Yuanzhichang; Zhudacai; zhangjukuo; qiuzhenfa; liudongdong (C);
> qiujiang; xuwei (O); Liguozhu (Kenneth)
> Subject: Re: [PATCH v7 3/6] PCI: designware: Add ARM64 support
> 
> On Thu, Aug 20, 2015 at 12:10:24PM +0100, Gabriele Paoloni wrote:
> > Hi Lucas
> >
> > Again many thanks for explaining and for your time.
> >
> > I got your point now and I have dug a bit better in the PCI_DOMAINS
> code.
> >
> > However I have a question...see inline below
> >
> > > -Original Message-
> > > From: Lucas Stach [mailto:l.st...@pengutronix.de]
> > > Sent: Thursday, August 20, 2015 9:27 AM
> > > To: Gabriele Paoloni
> > > Cc: Wangzhou (B); Bjorn Helgaas; jingooh...@gmail.com; Pratyush
> Anand;
> > > Arnd Bergmann; li...@arm.linux.org.uk; thomas.petazzoni@free-
> > > electrons.com; lorenzo.pieral...@arm.com; james.mo...@arm.com;
> > > liviu.du...@arm.com; ja...@lakedaemon.net; r...@kernel.org; linux-
> > > p...@vger.kernel.org; linux-arm-ker...@lists.infradead.org;
> > > devicetree@vger.kernel.org; Yuanzhichang; Zhudacai; zhangjukuo;
> > > qiuzhenfa; liudongdong (C); qiujiang; xuwei (O); Liguozhu (Kenneth)
> > > Subject: Re: [PATCH v7 3/6] PCI: designware: Add ARM64 support
> > >
> > > Hi Gab,
> > >
> > > Am Mittwoch, den 19.08.2015, 16:34 + schrieb Gabriele Paoloni:
> > > > Hi Lucas
> > > >
> > > > First of all many thanks for the quick reply, really appreciated
> > > >
> > > > > -Original Message-
> > > > > From: Lucas Stach [mailto:l.st...@pengutronix.de]
> > > > > Sent: Wednesday, August 19, 2015 4:37 PM
> > > > > To: Gabriele Paoloni
> > > > > Cc: Wangzhou (B); Bjorn Helgaas; jingooh...@gmail.com; Pratyush
> > > Anand;
> > > > > Arnd Bergmann; li...@arm.linux.org.uk; thomas.petazzoni@free-
> > > > > electrons.com; lorenzo.pieral...@arm.com; james.mo...@arm.com;
> > > > > liviu.du...@arm.com; ja...@lakedaemon.net; r...@kernel.org;
> linux-
> > > > > p...@vger.kernel.org; linux-arm-ker...@lists.infradead.org;
> > > > > devicetree@vger.kernel.org; Yuanzhichang; Zhudacai; zhangjukuo;
> > > > > qiuzhenfa; liudongdong (C); qiujiang; xuwei (O); Liguozhu
> (Kenneth)
> > > > > Subject: Re: [PATCH v7 3/6] PCI: designware: Add ARM64 support
> > > > >
> > > > > Hi Gab,
> > > > >
> > > > > Am Mittwoch, den 19.08.2015, 15:16 + schrieb Gabriele
> Paoloni:
> > > > > > Hi Lucas
> > > > > >
> > > > > > I have rewritten the patch to take into account multiple
> > > controllers.
> > > > > >
> > > > > > As you can see now there is a static var in
> dw_pcie_host_init()
> > > that
> > > > > tracks
> > > > > > the bus numbers used.
> > > > >
> > > > > This is wrong. The DT specifies the valid bus number range. You
> can
> > > not
> > > > > just assign the next free bus number to the root bus.
> > > >
> > > > I think this is what is being done in
> > > > http://lxr.free-
> electrons.com/source/arch/arm/kernel/bios32.c#L495
> > > > and currently designware assigns the root bus number in
> > > > http://lxr.free-electrons.com/source/drivers/pci/host/pcie-
> > > designware.c#L730
> > > >
> > > You found the right spot. It works a bit different than I remember,
> but
> > > is less broken than your current code. :)
> > >
> > > It actually assigns the next instance a root bus number behind the
> > > current instances bus range. Please note the difference to your
> code
> > > which assigns the next free bus number, which may still lay within
> the
> > > current instances bus range.
> 
> Hi Gabriele,
> 
> >
> > Mmmm here I have done a mistake: in the

RE: [PATCH v7 3/6] PCI: designware: Add ARM64 support

2015-08-20 Thread Gabriele Paoloni

Hi Lucas

Again many thanks for explaining and for your time.

I got your point now and I have dug a bit better in the PCI_DOMAINS code.

However I have a question...see inline below

> -Original Message-
> From: Lucas Stach [mailto:l.st...@pengutronix.de]
> Sent: Thursday, August 20, 2015 9:27 AM
> To: Gabriele Paoloni
> Cc: Wangzhou (B); Bjorn Helgaas; jingooh...@gmail.com; Pratyush Anand;
> Arnd Bergmann; li...@arm.linux.org.uk; thomas.petazzoni@free-
> electrons.com; lorenzo.pieral...@arm.com; james.mo...@arm.com;
> liviu.du...@arm.com; ja...@lakedaemon.net; r...@kernel.org; linux-
> p...@vger.kernel.org; linux-arm-ker...@lists.infradead.org;
> devicetree@vger.kernel.org; Yuanzhichang; Zhudacai; zhangjukuo;
> qiuzhenfa; liudongdong (C); qiujiang; xuwei (O); Liguozhu (Kenneth)
> Subject: Re: [PATCH v7 3/6] PCI: designware: Add ARM64 support
> 
> Hi Gab,
> 
> Am Mittwoch, den 19.08.2015, 16:34 + schrieb Gabriele Paoloni:
> > Hi Lucas
> >
> > First of all many thanks for the quick reply, really appreciated
> >
> > > -Original Message-
> > > From: Lucas Stach [mailto:l.st...@pengutronix.de]
> > > Sent: Wednesday, August 19, 2015 4:37 PM
> > > To: Gabriele Paoloni
> > > Cc: Wangzhou (B); Bjorn Helgaas; jingooh...@gmail.com; Pratyush
> Anand;
> > > Arnd Bergmann; li...@arm.linux.org.uk; thomas.petazzoni@free-
> > > electrons.com; lorenzo.pieral...@arm.com; james.mo...@arm.com;
> > > liviu.du...@arm.com; ja...@lakedaemon.net; r...@kernel.org; linux-
> > > p...@vger.kernel.org; linux-arm-ker...@lists.infradead.org;
> > > devicetree@vger.kernel.org; Yuanzhichang; Zhudacai; zhangjukuo;
> > > qiuzhenfa; liudongdong (C); qiujiang; xuwei (O); Liguozhu (Kenneth)
> > > Subject: Re: [PATCH v7 3/6] PCI: designware: Add ARM64 support
> > >
> > > Hi Gab,
> > >
> > > Am Mittwoch, den 19.08.2015, 15:16 + schrieb Gabriele Paoloni:
> > > > Hi Lucas
> > > >
> > > > I have rewritten the patch to take into account multiple
> controllers.
> > > >
> > > > As you can see now there is a static var in dw_pcie_host_init()
> that
> > > tracks
> > > > the bus numbers used.
> > >
> > > This is wrong. The DT specifies the valid bus number range. You can
> not
> > > just assign the next free bus number to the root bus.
> >
> > I think this is what is being done in
> > http://lxr.free-electrons.com/source/arch/arm/kernel/bios32.c#L495
> > and currently designware assigns the root bus number in
> > http://lxr.free-electrons.com/source/drivers/pci/host/pcie-
> designware.c#L730
> >
> You found the right spot. It works a bit different than I remember, but
> is less broken than your current code. :)
> 
> It actually assigns the next instance a root bus number behind the
> current instances bus range. Please note the difference to your code
> which assigns the next free bus number, which may still lay within the
> current instances bus range.

Mmmm here I have done a mistake: in the current designware the number of hw
controllers is always 1
http://lxr.free-electrons.com/source/drivers/pci/host/pcie-designware.c#L510
So the loop in bios32.c does not work on multiple PCIe ports...
However your comment about PCI_DOMAINS enlightened my mind and now I see
that when CONFIG_PCI_DOMAINS is defined we have the domains numbers
(tracked by __domain_nr).
So (correct me if I am wrong) if we have 2 PCIe ports that do not specify
the "bus-range" property, both root ports will enumerate starting from 
root_bus_nr = 0 and everything will still work ok.

So if my assumption is correct, I do not see why the orginal patch from Wang 
Zhou is wrong. 
The only point can be that assigning pp->root_bus_nr = 0 is not required 
as pp memory is kzalloc'ed (an therefore init to zero).


> 
> >
> > In general I agree with you but if you look at all the current
> drivers
> > based on designware none of them define the "bus-range" dtb property.
> > Therefore doing as you say would break the current driver when we
> have
> > multiple controllers...am I right?
> >
> The current _code_ works fine for multiple controllers. It's just that
> you must define the bus range property in the DTB if you want to enable
> multiple instances of one controller and support a kernel without PCI
> domains support. As all current implementations have only a single
> instance of the controller per SoC, or depend on PCI domain support,
> it's totally fine for them to not define the bus ranges property, as
> it's an optional property and it is well defined how thing

RE: [PATCH v7 3/6] PCI: designware: Add ARM64 support

2015-08-19 Thread Gabriele Paoloni

Hi Lucas

First of all many thanks for the quick reply, really appreciated

> -Original Message-
> From: Lucas Stach [mailto:l.st...@pengutronix.de]
> Sent: Wednesday, August 19, 2015 4:37 PM
> To: Gabriele Paoloni
> Cc: Wangzhou (B); Bjorn Helgaas; jingooh...@gmail.com; Pratyush Anand;
> Arnd Bergmann; li...@arm.linux.org.uk; thomas.petazzoni@free-
> electrons.com; lorenzo.pieral...@arm.com; james.mo...@arm.com;
> liviu.du...@arm.com; ja...@lakedaemon.net; r...@kernel.org; linux-
> p...@vger.kernel.org; linux-arm-ker...@lists.infradead.org;
> devicetree@vger.kernel.org; Yuanzhichang; Zhudacai; zhangjukuo;
> qiuzhenfa; liudongdong (C); qiujiang; xuwei (O); Liguozhu (Kenneth)
> Subject: Re: [PATCH v7 3/6] PCI: designware: Add ARM64 support
> 
> Hi Gab,
> 
> Am Mittwoch, den 19.08.2015, 15:16 + schrieb Gabriele Paoloni:
> > Hi Lucas
> >
> > I have rewritten the patch to take into account multiple controllers.
> >
> > As you can see now there is a static var in dw_pcie_host_init() that
> tracks
> > the bus numbers used.
> 
> This is wrong. The DT specifies the valid bus number range. You can not
> just assign the next free bus number to the root bus.

I think this is what is being done in
http://lxr.free-electrons.com/source/arch/arm/kernel/bios32.c#L495
and currently designware assigns the root bus number in
http://lxr.free-electrons.com/source/drivers/pci/host/pcie-designware.c#L730


In general I agree with you but if you look at all the current drivers 
based on designware none of them define the "bus-range" dtb property.
Therefore doing as you say would break the current driver when we have
multiple controllers...am I right?

If that is the case in order to fix this in the way you say I would need
to assign "bus-range" for all the PCIe drivers with multiple controllers:
in this case I would split the default range evenly (that is, if we have 
two controllers I would define "bus-range"  0-127 and 128-255)

If you think this solution is ok I can go for it. My only doubt was about
touching other vendors DTBs


> 
> It is perfectly valid to have a bus range of 0x00-0x10 assigned to one
> instance and 0x50-0xff to the next instance. Additional with PCIe
> hotplug you may not use the full range of the bus numbers on one
> instance at the first scan, but only later populate more buses when
> more
> bridges are added to the tree.
> 
> > Drivers that do not specify the bus range in the DTB set pp-
> >root_bus_nr = DW_ROOT_NR_UNDEFINED.
> > Designware will check if the flag is set and will use the automatic
> bus range
> > assignment.
> 
> No, please lets get rid of this assignment altogether. The glue drivers
> have no business in assigning the bus range. Please remove the
> pp->root_bus_nr assignment from all the glue drivers.
> 
> "bus range" is a generic DW PCIe property, so just parse the root bus
> number from the DT, it is handled the same way for all the DW based
> PCIe
> drivers. The bindings specifies that if the bus range property is
> missing the range is 0x00-0xff, so you can default to 0 as the root bus
> number in that case.
> 
> Also I would think this conversion warrants a patch on its own and
> should not be mixed in the ARM64 support patch.
> 
> Regards,
> Lucas
> 
> > Instead if the driver assigns pp->root_bus_nr according to the dtb,
> designwware
> > will use the value passed in by the driver.
> > Below the relevant section:
> >
> >
> > +   static int root_bus_nr = 0;
> > ...
> > +   mutex_lock(&root_bus_nr_mux);
> > +
> > +   if (pp->root_bus_nr != DW_ROOT_NR_UNDEFINED)
> > +   root_bus_nr = pp->root_bus_nr;
> > +
> > +   bus = pci_create_root_bus(pp->dev, root_bus_nr, &dw_pcie_ops,
> > +     pp, &res);
> > +   if (!bus) {
> > +   mutex_unlock(&root_bus_nr_mux);
> > +   return -ENOMEM;
> > +   }
> > +
> > +   root_bus_nr += bus->busn_res.end + 1;
> > +   mutex_unlock(&root_bus_nr_mux);
> >
> > Please let me know what you think...
> >
> > Many Thanks
> >
> > Gab
> > --
> >
> > From: gabriele paoloni 
> >
> > This patch tries to unify ARM32 and ARM64 PCIe in designware driver.
> Delete
> > function dw_pcie_setup, dw_pcie_scan_bus, dw_pcie_map_irq and struct
> hw_pci,
> > move related operations to dw_pcie_host_init.
> > Also set pp->root_bus_nr = DW_ROOT_NR_UNDEFINED in all the drivers
> that
> > are based on designware to flag that the drivers do not read the bus
> > ranges from DT.
> > This patch also adds

RE: [PATCH v7 3/6] PCI: designware: Add ARM64 support

2015-08-19 Thread Gabriele Paoloni

Hi Lucas

I have rewritten the patch to take into account multiple controllers.

As you can see now there is a static var in dw_pcie_host_init() that tracks
the bus numbers used.
Drivers that do not specify the bus range in the DTB set pp->root_bus_nr = 
DW_ROOT_NR_UNDEFINED.
Designware will check if the flag is set and will use the automatic bus range
assignment.
Instead if the driver assigns pp->root_bus_nr according to the dtb, designwware
will use the value passed in by the driver.
Below the relevant section:


+   static int root_bus_nr = 0;
...
+   mutex_lock(&root_bus_nr_mux);
+
+   if (pp->root_bus_nr != DW_ROOT_NR_UNDEFINED)
+   root_bus_nr = pp->root_bus_nr;
+
+   bus = pci_create_root_bus(pp->dev, root_bus_nr, &dw_pcie_ops,
+ pp, &res);
+   if (!bus) {
+   mutex_unlock(&root_bus_nr_mux);
+   return -ENOMEM;
+   }
+
+   root_bus_nr += bus->busn_res.end + 1;
+   mutex_unlock(&root_bus_nr_mux);

Please let me know what you think...

Many Thanks

Gab
--

From: gabriele paoloni 

This patch tries to unify ARM32 and ARM64 PCIe in designware driver. Delete
function dw_pcie_setup, dw_pcie_scan_bus, dw_pcie_map_irq and struct hw_pci,
move related operations to dw_pcie_host_init.
Also set pp->root_bus_nr = DW_ROOT_NR_UNDEFINED in all the drivers that
are based on designware to flag that the drivers do not read the bus
ranges from DT.
This patch also adds handling of multiple PCI domains in designware.
if the PCI host bridge driver does not specify a root bus number, in case
of multiple domains, designware will automatillay set the next domain root
bus number to the last bus number used in the last domain + 1.

This patch also try to use of_pci_get_host_bridge_resources for ARM32 and
ARM64 according to the suggestion for Gabriele[1]

This patch is based on Gabriele's patch about of_pci_range fix[2]

Finally this patch reverts commit f4c55c5a3f7f "PCI: designware:
Program ATU with untranslated address". This was discussed in [3]

I have compiled the driver with multi_v7_defconfig. However, I don't have
ARM32 PCIe related board to do test. It will be appreciated if someone could
help to test it.

Signed-off-by: Zhou Wang 
Signed-off-by: Arnd Bergmann 
Signed-off-by: Gabriele Paoloni 

[1] http://www.spinics.net/lists/linux-pci/msg42194.html
[2] https://patchwork.ozlabs.org/patch/495018/
[3] http://www.spinics.net/lists/arm-kernel/msg436779.html
---
 drivers/pci/host/pci-dra7xx.c  |  15 +--
 drivers/pci/host/pci-exynos.c  |   2 +-
 drivers/pci/host/pci-imx6.c|   2 +-
 drivers/pci/host/pci-keystone-dw.c |   2 +-
 drivers/pci/host/pci-keystone.c|   2 +-
 drivers/pci/host/pci-layerscape.c  |   2 +-
 drivers/pci/host/pcie-designware.c | 247 ++---
 drivers/pci/host/pcie-designware.h |  15 +--
 drivers/pci/host/pcie-spear13xx.c  |   2 +-
 9 files changed, 110 insertions(+), 179 deletions(-)

diff --git a/drivers/pci/host/pci-dra7xx.c b/drivers/pci/host/pci-dra7xx.c
index 5678b57..8d598fb 100644
--- a/drivers/pci/host/pci-dra7xx.c
+++ b/drivers/pci/host/pci-dra7xx.c
@@ -141,15 +141,15 @@ static void dra7xx_pcie_host_init(struct pcie_port *pp)
 {
dw_pcie_setup_rc(pp);
 
-   if (pp->io_mod_base)
-   pp->io_mod_base &= CPU_TO_BUS_ADDR;
+   if (pp->io_base)
+   pp->io_base &= CPU_TO_BUS_ADDR;
 
-   if (pp->mem_mod_base)
-   pp->mem_mod_base &= CPU_TO_BUS_ADDR;
+   if (pp->mem_base)
+   pp->mem_base &= CPU_TO_BUS_ADDR;
 
-   if (pp->cfg0_mod_base) {
-   pp->cfg0_mod_base &= CPU_TO_BUS_ADDR;
-   pp->cfg1_mod_base &= CPU_TO_BUS_ADDR;
+   if (pp->cfg0_base) {
+   pp->cfg0_base &= CPU_TO_BUS_ADDR;
+   pp->cfg1_base &= CPU_TO_BUS_ADDR;
}
 
dra7xx_pcie_establish_link(pp);
@@ -288,6 +288,7 @@ static int __init dra7xx_add_pcie_port(struct dra7xx_pcie 
*dra7xx,
 
pp = &dra7xx->pp;
pp->dev = dev;
+   pp->root_bus_nr = DW_ROOT_NR_UNDEFINED;
pp->ops = &dra7xx_pcie_host_ops;
 
pp->irq = platform_get_irq(pdev, 1);
diff --git a/drivers/pci/host/pci-exynos.c b/drivers/pci/host/pci-exynos.c
index f9f468d..ed03a8f 100644
--- a/drivers/pci/host/pci-exynos.c
+++ b/drivers/pci/host/pci-exynos.c
@@ -530,7 +530,7 @@ static int __init exynos_add_pcie_port(struct pcie_port *pp,
}
}
 
-   pp->root_bus_nr = -1;
+   pp->root_bus_nr = DW_ROOT_NR_UNDEFINED;
pp->ops = &exynos_pcie_host_ops;
 
ret = dw_pcie_host_init(pp);
diff --git a/drivers/pci/host/pci-imx6.c b/drivers/pci/host/pci-imx6.c
index 233a196..0efac85 100644
--- a/drivers/pci/host/pci-imx6.c
+++ b/drivers/pci/host/pci-imx6.c
@@ -551,7 +551

RE: [PATCH v6 3/6] PCI: designware: Add ARM64 support

2015-08-14 Thread Gabriele Paoloni

> 
> I've tested this whole series on an ARM32 PCIe board:'Freescale i.MX6
> Quad
> SABRE Lite Board' with an Intel wireless card on v4.2-rc6.
> 
> I can rescan the bus, load firmware, list nearby APs, and even get MSIs
> coming from the card.
> 
> Tested-By: James Morse 
> 
> 
> Thanks,
> 
> James

Many Thanks for this James!

Gab
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

RE: [PATCH v6 0/6] PCI: hisi: Add PCIe host support for HiSilicon SoC Hip05

2015-08-11 Thread Gabriele Paoloni

Hi Bjorn and all

Any comment on this patchset?

Thanks

Gab

> -Original Message-
> From: Wangzhou (B)
> Sent: Friday, August 07, 2015 7:01 AM
> To: Wangzhou (B)
> Cc: Bjorn Helgaas; Jingoo Han; Pratyush Anand; Arnd Bergmann;
> li...@arm.linux.org.uk; thomas.petazz...@free-electrons.com; Gabriele
> Paoloni; lorenzo.pieral...@arm.com; James Morse; liviu.du...@arm.com;
> Jason Cooper; r...@kernel.org; linux-...@vger.kernel.org; linux-arm-
> ker...@lists.infradead.org; devicetree@vger.kernel.org; Yuanzhichang;
> Zhudacai; zhangjukuo; qiuzhenfa; liudongdong (C); qiujiang;
> Kangfenglong; xuwei (O); Liguozhu (Kenneth)
> Subject: Re: [PATCH v6 0/6] PCI: hisi: Add PCIe host support for
> HiSilicon SoC Hip05
> 
> [+cc jingooh...@gmail.com]
> 
> On 2015/8/6 16:09, Zhou Wang wrote:
> > This patchset adds PCIe host support for HiSilicon SoC Hip05. The
> PCIe hosts
> > use PCIe IP core from Synopsys, So this driver is base on designware
> PCIe driver.
> >
> > Hip05 is an ARMv8 architecture SoC. It should be able to use ARM64
> PCIe API in
> > designeware PCIe driver. So this patch also adds ARM64 support for
> designware
> > pcie.
> >
> > This patchset is based on v4.2-rc1.
> >
> > Change from v5:
> > - Merge 1/6 in this series, discussion about this can be found in [1]
> >
> > Change from v4:
> > - Change the author of 1/5 to Gabriele.
> > - Modify problems in 3/5 pointed by Bjorn.
> > - Modify spelling problems in 4/5.
> >
> > Change from v3:
> > - Change 1/5 to what Gabriele suggested.
> > - Use win->__res.start to get *_mod_base in 2/5, this fix a bug in v3
> series.
> >
> > Change from v2:
> > - Move struct pci_dev *dev and struct pci_sys_data *sys in
> >   pcibios_align_resource in 1/5.
> > - Add Gabriele's codes in 2/5 which delete unnecessary information
> parse and
> >   use of_pci_get_host_bridge_resources for both ARM32 and ARM64.
> > - Add maintainer patch 5/5.
> >
> > Change from RFC v1:
> > - Add 1/4 patch by Arnd which removes align_resource callback in ARM
> >   pcibios_align_resource.
> > - Change head file in pcie-designware from asm/hardirq.h to
> linux/hardirq.h.
> > - Set pp->root_bus_nr = 0 in dra7xx, exynos, imx6, keystone,
> layerscape,
> >   spear13xx.
> > - Remove unnecessary parentheses of some macros in pcie-hisi.
> > - Use macro to replace some magic values.
> > - Merge two loops together and add some comments about it in
> context_config
> >   function in pcie-hisi.
> > - Modify some value of items in pcie node example in binding document.
> >
> > Change from RFC:
> > - delete dw_pcie_setup, dw_pcie_scan_bus, dw_pcie_map_irq and struct
> hw_pci,
> >   merge related operations into dw_pcie_host_init.
> >
> > Link of v5:
> > - http://www.spinics.net/lists/devicetree/msg87959.html
> > Link of v4:
> > - http://www.spinics.net/lists/arm-kernel/msg433050.html
> > Link of v3:
> > - http://www.spinics.net/lists/linux-pci/msg42539.html
> > Link of v2:
> > - http://www.spinics.net/lists/linux-pci/msg41844.html
> > Link of RFC v1:
> > - http://www.spinics.net/lists/linux-pci/msg41305.html
> > Link of RFC:
> > - http://www.spinics.net/lists/linux-pci/msg40434.html
> >
> > [1] http://lists.infradead.org/pipermail/linux-arm-kernel/2015-
> July/359741.html
> >
> > Zhou Wang (4):
> >   PCI: designware: Add ARM64 support
> >   PCI: hisi: Add PCIe host support for HiSilicon SoC Hip05
> >   Documentation: DT: Add HiSilicon PCIe host binding
> >   MAINTAINERS: Add pcie-hisi maintainer
> >
> > gabriele paoloni (2):
> >   PCI: designware: move calculation of bus addresses to DRA7xx
> >   ARM/PCI: remove align_resource in pci_sys_data
> >
> >  .../devicetree/bindings/pci/hisilicon-pcie.txt |  46 
> >  MAINTAINERS|   7 +
> >  arch/arm/include/asm/mach/pci.h|   5 -
> >  arch/arm/kernel/bios32.c   |  12 +-
> >  drivers/pci/host/Kconfig   |   8 +
> >  drivers/pci/host/Makefile  |   1 +
> >  drivers/pci/host/pci-dra7xx.c  |  14 ++
> >  drivers/pci/host/pci-exynos.c  |   2 +-
> >  drivers/pci/host/pci-imx6.c|   2 +-
> >  drivers/pci/host/pci-keystone-dw.c |   2 +-
> >  drivers/pci/host/pci-keystone.c|   2 +-
> >  drivers/pci/host/pci-layerscape.c  |   2 +-
> >  drivers/pci/h

RE: [PATCH v6] PCI: Store PCIe bus address in struct of_pci_range

2015-08-06 Thread Gabriele Paoloni

Hi all

This patch has now been moved in "[PATCH v6 1/6] PCI: designware: move 
calculation of bus addresses to DRA7xx"

commit "f4c55c5a3f7f (PCI: designware: Program ATU with untranslated address)" 
has been reverted in
"[PATCH v6 3/6] PCI: designware: Add ARM64 support"

Gab

> -Original Message-
> From: linux-pci-ow...@vger.kernel.org [mailto:linux-pci-
> ow...@vger.kernel.org] On Behalf Of Gabriele Paoloni
> Sent: Tuesday, August 04, 2015 11:12 AM
> To: Jingoo Han
> Cc: Rob Herring; Kishon Vijay Abraham I; Bjorn Helgaas; a...@arndb.de;
> lorenzo.pieral...@arm.com; Wangzhou (B); robh...@kernel.org;
> james.mo...@arm.com; liviu.du...@arm.com; linux-...@vger.kernel.org;
> linux-arm-ker...@lists.infradead.org; devicetree@vger.kernel.org;
> Yuanzhichang; Zhudacai; zhangjukuo; qiuzhenfa; Liguozhu (Kenneth);
> Pratyush Anand; Arnd Bergmann
> Subject: RE: [PATCH v6] PCI: Store PCIe bus address in struct
> of_pci_range
> 
> 
> 
> > -Original Message-
> > From: Jingoo Han [mailto:jingooh...@gmail.com]
> > Sent: Tuesday, August 04, 2015 5:20 AM
> > To: Gabriele Paoloni
> > Cc: Rob Herring; Kishon Vijay Abraham I; Bjorn Helgaas; a...@arndb.de;
> > lorenzo.pieral...@arm.com; Wangzhou (B); robh...@kernel.org;
> > james.mo...@arm.com; liviu.du...@arm.com; linux-...@vger.kernel.org;
> > linux-arm-ker...@lists.infradead.org; devicetree@vger.kernel.org;
> > Yuanzhichang; Zhudacai; zhangjukuo; qiuzhenfa; Liguozhu (Kenneth);
> > Pratyush Anand; Arnd Bergmann; jingooh...@gmail.com
> > Subject: Re: [PATCH v6] PCI: Store PCIe bus address in struct
> > of_pci_range
> >
> > On 2015. 8. 3., at PM 8:18, Gabriele Paoloni
> >  wrote:
> > >
> > > Rob, Kishon what about the following solution?
> > >
> > > ---
> > > drivers/pci/host/pci-dra7xx.c  | 12 
> > > drivers/pci/host/pcie-designware.c |  9 +++--
> >
> > Hi Paoloni,
> >
> > OK, it looks good.
> > I want you to revert the following patch.
> >
> > commit "f4c55c5a3f7f (PCI: designware: Program ATU with untranslated
> > address)"
> >
> > Would you remove all '*_mode_base's?
> 
> Hi Jingoo Han,
> 
> If I reverted the commit, in order to get designware working, dra7
> should mask directly the CPU addresses stored in pp->cfg0_base,
> pp->cfg1_base, pp->mem_base and pp->io_base.
> 
> The masking would happen at this point:
> http://lxr.free-electrons.com/source/drivers/pci/host/pcie-
> designware.c#L493
> 
> Now:
> - I see that pp->cfg<0/1>_base are used in devm_ioremap before that
>   point and nowhere else, so they should be ok.
> - pp->mem_base is used in dw_pcie_setup_rc(); dw_pcie_setup_rc() is
> called
>   in dra7xx_pcie_host_init()...so here I should move the masking after
>   dw_pcie_setup() retuned, but I think it should be ok
> - pp->io_base is used in pci_ioremap_io() in dw_pcie_setup(). Now
> currently
>   in designware this is called by pci_bios_init_hw(); this is after the
>   maskingso here we would have a the wrong value passed
> 
> Said that if you look at "[PATCH v5 2/5] PCI: designware: Add ARM64
> support",
> that is the patchset where this patch is needed, you can see that
> dw_pcie_setup() is removed and pp->io_base is used in
> pci_remap_iospace() before
> the masking would happen in dra7xx_pcie_host_init()...so for this
> patchset we
> should be good to revert the commit.
> 
> I propose to add a new patch in the patchset "[PATCH v5 0/5] PCI: hisi:
> Add PCIe
> host support for HiSilicon SoC Hip05" as the one I just posted in this
> thread (this would not revert the commit but just moves the masking to
> dra7xx)
> 
> I would revert the commit in "[PATCH v5 2/5] PCI: designware: Add ARM64
> support"
> together with the rest of designware rework.
> 
> So we would have always a working version of designware...
> 
> Are you ok with this?
> 
> >
> > Best regards,
> > Jingoo Han
> >
> > > 2 files changed, 15 insertions(+), 6 deletions(-)
> > >
> > > diff --git a/drivers/pci/host/pci-dra7xx.c b/drivers/pci/host/pci-
> > dra7xx.c
> > > index 80db09e..bb2635f 100644
> > > --- a/drivers/pci/host/pci-dra7xx.c
> > > +++ b/drivers/pci/host/pci-dra7xx.c
> > > @@ -61,6 +61,7 @@
> > >
> > > #definePCIECTRL_DRA7XX_CONF_PHY_CS0x010C
> > > #defineLINK_UPBIT(16)
> > > +#define CPU_TO_BUS_ADDR 0x0FFF
> > >
> > > struct dra7xx_pcie {
>

RE: [PATCH v5 2/5] PCI: designware: Add ARM64 support

2015-08-04 Thread Gabriele Paoloni

> -Original Message-
> From: James Morse [mailto:james.mo...@arm.com]
> Sent: Tuesday, August 04, 2015 11:40 AM
> To: Gabriele Paoloni; Wangzhou (B)
> Cc: Bjorn Helgaas; Jingoo Han; Pratyush Anand; Arnd Bergmann; Lorenzo
> Pieralisi; Liviu Dudau; thomas.petazz...@free-electrons.com; Jason
> Cooper; r...@kernel.org; linux-...@vger.kernel.org; linux-arm-
> ker...@lists.infradead.org; devicetree@vger.kernel.org; Yuanzhichang;
> Zhudacai; zhangjukuo; qiuzhenfa; liudongdong (C); qiujiang;
> Kangfenglong; Liguozhu (Kenneth)
> Subject: Re: [PATCH v5 2/5] PCI: designware: Add ARM64 support
> 
> On 04/08/15 11:23, Gabriele Paoloni wrote:
> > Hi James
> >
> > Please see "[PATCH v6] PCI: Store PCIe bus address in struct
> of_pci_range"
> >
> > I think if you apply this patch your problem should be solved...
> >
> > If you follow the discussion you see that this patch is going to be
> part
> > of the next designware patchset...
> 
> Yes I just spotted that series after continuing through my email
> backlog.
> 
> > Wang Zhou said "You need apply Gabriele's patch before applying this
> patch."
> > but he didn't specify which one and obviously this patch should have
> been part
> > of the patch-set
> 
> I assumed he meant your patch 1 in the same series, (given the reply
> was to
> patch 2).
> 
> With the '[PATCH v6] PCI: Store PCIe bus address in struct
> of_pci_range'
> applied before patches and 1 and 2 of this series - pcie on the
> 'Freescale i.MX6 Quad SABRE Lite Board' works fine.
> 
> I can rescan the bus, load firmware, list nearby APs, and even get MSIs
> coming from the card.

This is Great NEWS! Thanks a Lot!

> 
> Tested-by: James Morse 
> 
> 
> 
> James
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

RE: [PATCH v5 2/5] PCI: designware: Add ARM64 support

2015-08-04 Thread Gabriele Paoloni

Hi James

Please see "[PATCH v6] PCI: Store PCIe bus address in struct of_pci_range"

I think if you apply this patch your problem should be solved...

If you follow the discussion you see that this patch is going to be part 
of the next designware patchset...

Wang Zhou said "You need apply Gabriele's patch before applying this patch."
but he didn't specify which one and obviously this patch should have been part
of the patch-set

Sorry for the confusion 

Gab

> -Original Message-
> From: James Morse [mailto:james.mo...@arm.com]
> Sent: Tuesday, August 04, 2015 10:35 AM
> To: Wangzhou (B)
> Cc: Bjorn Helgaas; Jingoo Han; Pratyush Anand; Arnd Bergmann; Gabriele
> Paoloni; Lorenzo Pieralisi; Liviu Dudau; thomas.petazzoni@free-
> electrons.com; Jason Cooper; r...@kernel.org; linux-...@vger.kernel.org;
> linux-arm-ker...@lists.infradead.org; devicetree@vger.kernel.org;
> Yuanzhichang; Zhudacai; zhangjukuo; qiuzhenfa; liudongdong (C);
> qiujiang; Kangfenglong; Liguozhu (Kenneth)
> Subject: Re: [PATCH v5 2/5] PCI: designware: Add ARM64 support
> 
> On 28/07/15 07:21, Zhou Wang wrote:
> > On 2015/7/25 11:21, Zhou Wang wrote:
> >> This patch tries to unify ARM32 and ARM64 PCIe in designware driver.
> Delete
> >> function dw_pcie_setup, dw_pcie_scan_bus, dw_pcie_map_irq and struct
> hw_pci,
> >> move related operations to dw_pcie_host_init. Also set pp-
> >root_bus_nr = 0 in
> >> each PCIe host driver which is based on pcie-designware. This patch
> also try
> >> to use of_pci_get_host_bridge_resources for ARM32 and ARM64
> according to the
> >> suggestion for Gabriele[1]
> >>
> >> This patch is based on Gabriele's patch about of_pci_range fix[2]
> >>
> >> I have compiled the driver with multi_v7_defconfig. However, I don't
> have
> >> ARM32 PCIe related board to do test. It will be appreciated if
> someone could
> >> help to test it.
> >>
> >
> > Hi James,
> >
> > If you have time, could you help to test this patch on i.MX 6Quad
> board?
> > You need apply Gabriele's patch before applying this patch.
> >
> > It will be very appreciate and helpful if we can get test result from
> you.
> 
> Applying patches 1 and 2, from v5, onto 4.2-rc5, I still get the same
> problem as before: config cycles to enumerate the second bus aren't
> working. (good news - I have a workaround)
> 
> Output from dmesg below, the lines 'dw_pcie_cfg_read(0xf018, 0x0,
> 0x4,
> =0x8878086)' were added by me, 0x8878086 is the intel wireless card
> attached to the board.
> 
> From v4.2-rc5:
> ---
> ---
> imx6q-pcie 1ffc000.pcie: PCI host bridge to bus :00
> pci_bus :00: root bus resource [io 0x1000-0x]
> pci_bus :00: root bus resource [mem 0x0100-0x01ef]
> pci_bus :00: root bus resource [bus 00-ff]
> pci :00:00.0: [16c3:abcd] type 01 class 0x060400
> pci :00:00.0: reg 0x10: [mem 0x-0x000f]
> pci :00:00.0: reg 0x38: [mem 0x-0x pref]
> pci :00:00.0: IOMMU is currently not supported for PCI
> pci :00:00.0: supports D1
> pci :00:00.0: PME# supported from D0 D1 D3hot D3cold
> PCI: bus0: Fast back to back transfers disabled
> dw_pcie_cfg_read(0xf018, 0x0, 0x4, =0x8878086)
> pci :01:00.0: [8086:0887] type 00 class 0x028000
> dw_pcie_cfg_read(0xf018, 0x0, 0x4, =0x8878086)
> pci :01:00.0: reg 0x10: [mem 0x-0x1fff 64bit]
> pci :01:00.0: IOMMU is currently not supported for PCI
> pci :01:00.0: PME# supported from D0 D3hot D3cold
> PCI: bus1: Fast back to back transfers disabled
> pci_bus :01: busn_res: [bus 01-ff] end is updated to 01
> pci :00:00.0: BAR 0: assigned [mem 0x0100-0x010f]
> pci :00:00.0: BAR 8: assigned [mem 0x0110-0x011f]
> pci :00:00.0: BAR 6: assigned [mem 0x0120-0x0120 pref
> ]
> pci :01:00.0: BAR 0: assigned [mem 0x0110-0x01101fff 64bi
> t]
> pci :00:00.0: PCI bridge to [bus 01]
> pci :00:00.0:bridge window [mem 0x0110-0x011f]
> pcieport :00:00.0: Signaling PME through PCIe PME interrupt
> pci :01:00.0: Signaling PME through PCIe PME interrupt
> pcie_pme :00:00.0:pcie01: service driver pcie_pme loaded
> ---
> ---
> 
> And then with your two patches:
> ---
> ---
> PCI host bridge /soc/pcie@0x0100 ranges:
> No bus range found for /soc/pcie@0x0100, using [bus 00-ff]

RE: [PATCH v6] PCI: Store PCIe bus address in struct of_pci_range

2015-08-04 Thread Gabriele Paoloni



> -Original Message-
> From: Jingoo Han [mailto:jingooh...@gmail.com]
> Sent: Tuesday, August 04, 2015 5:20 AM
> To: Gabriele Paoloni
> Cc: Rob Herring; Kishon Vijay Abraham I; Bjorn Helgaas; a...@arndb.de;
> lorenzo.pieral...@arm.com; Wangzhou (B); robh...@kernel.org;
> james.mo...@arm.com; liviu.du...@arm.com; linux-...@vger.kernel.org;
> linux-arm-ker...@lists.infradead.org; devicetree@vger.kernel.org;
> Yuanzhichang; Zhudacai; zhangjukuo; qiuzhenfa; Liguozhu (Kenneth);
> Pratyush Anand; Arnd Bergmann; jingooh...@gmail.com
> Subject: Re: [PATCH v6] PCI: Store PCIe bus address in struct
> of_pci_range
> 
> On 2015. 8. 3., at PM 8:18, Gabriele Paoloni
>  wrote:
> >
> > Rob, Kishon what about the following solution?
> >
> > ---
> > drivers/pci/host/pci-dra7xx.c  | 12 
> > drivers/pci/host/pcie-designware.c |  9 +++--
> 
> Hi Paoloni,
> 
> OK, it looks good.
> I want you to revert the following patch.
> 
> commit "f4c55c5a3f7f (PCI: designware: Program ATU with untranslated
> address)"
> 
> Would you remove all '*_mode_base's?

Hi Jingoo Han,

If I reverted the commit, in order to get designware working, dra7 
should mask directly the CPU addresses stored in pp->cfg0_base, 
pp->cfg1_base, pp->mem_base and pp->io_base.

The masking would happen at this point: 
http://lxr.free-electrons.com/source/drivers/pci/host/pcie-designware.c#L493

Now:
- I see that pp->cfg<0/1>_base are used in devm_ioremap before that 
  point and nowhere else, so they should be ok.
- pp->mem_base is used in dw_pcie_setup_rc(); dw_pcie_setup_rc() is called
  in dra7xx_pcie_host_init()...so here I should move the masking after
  dw_pcie_setup() retuned, but I think it should be ok
- pp->io_base is used in pci_ioremap_io() in dw_pcie_setup(). Now currently
  in designware this is called by pci_bios_init_hw(); this is after the 
  maskingso here we would have a the wrong value passed

Said that if you look at "[PATCH v5 2/5] PCI: designware: Add ARM64 support",
that is the patchset where this patch is needed, you can see that 
dw_pcie_setup() is removed and pp->io_base is used in pci_remap_iospace() 
before 
the masking would happen in dra7xx_pcie_host_init()...so for this patchset we 
should be good to revert the commit.

I propose to add a new patch in the patchset "[PATCH v5 0/5] PCI: hisi: Add 
PCIe 
host support for HiSilicon SoC Hip05" as the one I just posted in this 
thread (this would not revert the commit but just moves the masking to dra7xx)

I would revert the commit in "[PATCH v5 2/5] PCI: designware: Add ARM64 support"
together with the rest of designware rework. 

So we would have always a working version of designware...

Are you ok with this?

> 
> Best regards,
> Jingoo Han
> 
> > 2 files changed, 15 insertions(+), 6 deletions(-)
> >
> > diff --git a/drivers/pci/host/pci-dra7xx.c b/drivers/pci/host/pci-
> dra7xx.c
> > index 80db09e..bb2635f 100644
> > --- a/drivers/pci/host/pci-dra7xx.c
> > +++ b/drivers/pci/host/pci-dra7xx.c
> > @@ -61,6 +61,7 @@
> >
> > #definePCIECTRL_DRA7XX_CONF_PHY_CS0x010C
> > #defineLINK_UPBIT(16)
> > +#define CPU_TO_BUS_ADDR 0x0FFF
> >
> > struct dra7xx_pcie {
> >void __iomem*base;
> > @@ -138,6 +139,17 @@ static void dra7xx_pcie_enable_interrupts(struct
> pcie_port *pp)
> >
> > static void dra7xx_pcie_host_init(struct pcie_port *pp)
> > {
> > +if (pp->io_mod_base)
> > +pp->io_mod_base &= CPU_TO_BUS_ADDR;
> > +
> > +if (pp->mem_mod_base)
> > +pp->mem_mod_base &= CPU_TO_BUS_ADDR;
> > +
> > +if (pp->cfg0_mod_base) {
> > +pp->cfg0_mod_base &= CPU_TO_BUS_ADDR;
> > +pp->cfg1_mod_base &= CPU_TO_BUS_ADDR;
> > +}
> > +
> >dw_pcie_setup_rc(pp);
> >dra7xx_pcie_establish_link(pp);
> >if (IS_ENABLED(CONFIG_PCI_MSI))
> > diff --git a/drivers/pci/host/pcie-designware.c
> b/drivers/pci/host/pcie-designware.c
> > index 69486be..06c682b 100644
> > --- a/drivers/pci/host/pcie-designware.c
> > +++ b/drivers/pci/host/pcie-designware.c
> > @@ -416,8 +416,7 @@ int dw_pcie_host_init(struct pcie_port *pp)
> >pp->io_base = range.cpu_addr;
> >
> >/* Find the untranslated IO space address */
> > -pp->io_mod_base = of_read_number(parser.range -
> > - parser.np + na, ns);
> > +pp->io_mod_base = range.cpu_addr;;
> >}
> >if (restype == IORESOURCE_MEM

RE: [PATCH v6] PCI: Store PCIe bus address in struct of_pci_range

2015-08-03 Thread Gabriele Paoloni

Rob, Kishon what about the following solution?

---
 drivers/pci/host/pci-dra7xx.c  | 12 
 drivers/pci/host/pcie-designware.c |  9 +++--
 2 files changed, 15 insertions(+), 6 deletions(-)

diff --git a/drivers/pci/host/pci-dra7xx.c b/drivers/pci/host/pci-dra7xx.c
index 80db09e..bb2635f 100644
--- a/drivers/pci/host/pci-dra7xx.c
+++ b/drivers/pci/host/pci-dra7xx.c
@@ -61,6 +61,7 @@
 
 #definePCIECTRL_DRA7XX_CONF_PHY_CS 0x010C
 #defineLINK_UP BIT(16)
+#define CPU_TO_BUS_ADDR 0x0FFF
 
 struct dra7xx_pcie {
void __iomem*base;
@@ -138,6 +139,17 @@ static void dra7xx_pcie_enable_interrupts(struct pcie_port 
*pp)
 
 static void dra7xx_pcie_host_init(struct pcie_port *pp)
 {
+   if (pp->io_mod_base)
+   pp->io_mod_base &= CPU_TO_BUS_ADDR;
+
+   if (pp->mem_mod_base)
+   pp->mem_mod_base &= CPU_TO_BUS_ADDR;
+
+   if (pp->cfg0_mod_base) {
+   pp->cfg0_mod_base &= CPU_TO_BUS_ADDR;
+   pp->cfg1_mod_base &= CPU_TO_BUS_ADDR;
+   }
+
dw_pcie_setup_rc(pp);
dra7xx_pcie_establish_link(pp);
if (IS_ENABLED(CONFIG_PCI_MSI))
diff --git a/drivers/pci/host/pcie-designware.c 
b/drivers/pci/host/pcie-designware.c
index 69486be..06c682b 100644
--- a/drivers/pci/host/pcie-designware.c
+++ b/drivers/pci/host/pcie-designware.c
@@ -416,8 +416,7 @@ int dw_pcie_host_init(struct pcie_port *pp)
pp->io_base = range.cpu_addr;
 
/* Find the untranslated IO space address */
-   pp->io_mod_base = of_read_number(parser.range -
-parser.np + na, ns);
+   pp->io_mod_base = range.cpu_addr;;
}
if (restype == IORESOURCE_MEM) {
of_pci_range_to_resource(&range, np, &pp->mem);
@@ -426,8 +425,7 @@ int dw_pcie_host_init(struct pcie_port *pp)
pp->mem_bus_addr = range.pci_addr;
 
/* Find the untranslated MEM space address */
-   pp->mem_mod_base = of_read_number(parser.range -
- parser.np + na, ns);
+   pp->mem_mod_base = range.cpu_addr;
}
if (restype == 0) {
of_pci_range_to_resource(&range, np, &pp->cfg);
@@ -437,8 +435,7 @@ int dw_pcie_host_init(struct pcie_port *pp)
pp->cfg1_base = pp->cfg.start + pp->cfg0_size;
 
/* Find the untranslated configuration space address */
-   pp->cfg0_mod_base = of_read_number(parser.range -
-  parser.np + na, ns);
+   pp->cfg0_mod_base = range.cpu_addr;
pp->cfg1_mod_base = pp->cfg0_mod_base +
pp->cfg0_size;
}
-- 
1.9.1


> -Original Message-
> From: linux-pci-ow...@vger.kernel.org [mailto:linux-pci-
> ow...@vger.kernel.org] On Behalf Of Rob Herring
> Sent: Friday, July 31, 2015 5:53 PM
> To: Kishon Vijay Abraham I
> Cc: Gabriele Paoloni; Bjorn Helgaas; a...@arndb.de;
> lorenzo.pieral...@arm.com; Wangzhou (B); robh...@kernel.org;
> james.mo...@arm.com; liviu.du...@arm.com; linux-...@vger.kernel.org;
> linux-arm-ker...@lists.infradead.org; devicetree@vger.kernel.org;
> Yuanzhichang; Zhudacai; zhangjukuo; qiuzhenfa; Liguozhu (Kenneth);
> Jingoo Han; Pratyush Anand; Arnd Bergmann
> Subject: Re: [PATCH v6] PCI: Store PCIe bus address in struct
> of_pci_range
> 
> On Fri, Jul 31, 2015 at 9:57 AM, Kishon Vijay Abraham I 
> wrote:
> > +Arnd
> >
> > Hi,
> >
> > On Friday 31 July 2015 07:55 PM, Gabriele Paoloni wrote:
> >> [+cc Kishon]
> >>
> >>> -Original Message-
> >>> From: linux-pci-ow...@vger.kernel.org [mailto:linux-pci-
> >>> ow...@vger.kernel.org] On Behalf Of Rob Herring
> >>> Sent: Thursday, July 30, 2015 9:42 PM
> >>> To: Gabriele Paoloni
> >>> Cc: Bjorn Helgaas; a...@arndb.de; lorenzo.pieral...@arm.com;
> Wangzhou
> >>> (B); robh...@kernel.org; james.mo...@arm.com; liviu.du...@arm.com;
> >>> linux-...@vger.kernel.org; linux-arm-ker...@lists.infradead.org;
> >>> devicetree@vger.kernel.org; Yuanzhichang; Zhudacai; zhangjukuo;
> >>> qiuzhenfa; Liguozhu (Kenneth); Jingoo Han; Pratyush Anand
> >>> Subject: Re: [PATCH v6] PCI: Store PCIe bus address in struct
> >>> of_pci_range
> >>>
> >>> On Thu, Jul

RE: [PATCH v6] PCI: Store PCIe bus address in struct of_pci_range

2015-07-31 Thread Gabriele Paoloni



> -Original Message-
> From: Kishon Vijay Abraham I [mailto:kis...@ti.com]
> Sent: Friday, July 31, 2015 3:57 PM
> To: Gabriele Paoloni; Rob Herring
> Cc: Bjorn Helgaas; a...@arndb.de; lorenzo.pieral...@arm.com; Wangzhou
> (B); robh...@kernel.org; james.mo...@arm.com; liviu.du...@arm.com;
> linux-...@vger.kernel.org; linux-arm-ker...@lists.infradead.org;
> devicetree@vger.kernel.org; Yuanzhichang; Zhudacai; zhangjukuo;
> qiuzhenfa; Liguozhu (Kenneth); Jingoo Han; Pratyush Anand; Arnd
> Bergmann; Arnd Bergmann
> Subject: Re: [PATCH v6] PCI: Store PCIe bus address in struct
> of_pci_range
> 
> +Arnd
> 
> Hi,
> 
> On Friday 31 July 2015 07:55 PM, Gabriele Paoloni wrote:
> > [+cc Kishon]
> >
> >> -Original Message-
> >> From: linux-pci-ow...@vger.kernel.org [mailto:linux-pci-
> >> ow...@vger.kernel.org] On Behalf Of Rob Herring
> >> Sent: Thursday, July 30, 2015 9:42 PM
> >> To: Gabriele Paoloni
> >> Cc: Bjorn Helgaas; a...@arndb.de; lorenzo.pieral...@arm.com;
> Wangzhou
> >> (B); robh...@kernel.org; james.mo...@arm.com; liviu.du...@arm.com;
> >> linux-...@vger.kernel.org; linux-arm-ker...@lists.infradead.org;
> >> devicetree@vger.kernel.org; Yuanzhichang; Zhudacai; zhangjukuo;
> >> qiuzhenfa; Liguozhu (Kenneth); Jingoo Han; Pratyush Anand
> >> Subject: Re: [PATCH v6] PCI: Store PCIe bus address in struct
> >> of_pci_range
> >>
> >> On Thu, Jul 30, 2015 at 12:34 PM, Gabriele Paoloni
> >>  wrote:
> >>>> -Original Message-
> >>>> From: Bjorn Helgaas [mailto:bhelg...@google.com]
> >>>> Sent: 30 July 2015 18:15
> >>>> On Thu, Jul 30, 2015 at 04:50:55PM +, Gabriele Paoloni wrote:
> >>>>>> -Original Message-
> >>>>>> From: linux-pci-ow...@vger.kernel.org [mailto:linux-pci-
> >>>>>> ow...@vger.kernel.org] On Behalf Of Bjorn Helgaas
> >>>>>> Sent: Thursday, July 30, 2015 5:15 PM
> >>>>>> On Thu, Jul 30, 2015 at 01:52:13PM +, Gabriele Paoloni wrote:
> >>
> >> [...]
> >>
> >>>>>>> I don’t think we should rely on [CPU] addresses...what if the
> >>>>>> intermediate
> >>>>>>> translation layer changes the lower significant bits of the
> >> "bus
> >>>>>> address"
> >>>>>>> to translate into a cpu address?
> >>>>>>
> >>>>>> Is it really a possiblity that the lower bits could be changed?
> >>>>>
> >>>>> I've checked all the current deignware users DTs except "pci-
> >>>> layerscape"
> >>>>> that I could not find:
> >>>>> spear1310.dtsi
> >>>>> spear1340.dtsi
> >>>>> dra7.dtsi
> >>>>> imx6qdl.dtsi
> >>>>> imx6sx.dtsi
> >>>>> keystone.dtsi
> >>>>> exynos5440.dtsi
> >>>>>
> >>>>> None of them modifies the lower bits. To be more precise the only
> >> guy
> >>>>> that provides another translation layer is "dra7.dtsi":
> >>>>> axi0
> >>>>> http://lxr.free-
> >> electrons.com/source/arch/arm/boot/dts/dra7.dtsi#L207
> >>>>>
> >>>>> axi1
> >>>>> http://lxr.free-
> >> electrons.com/source/arch/arm/boot/dts/dra7.dtsi#L241
> >>>>>
> >>>>> For this case masking the top 4bits (bits28 to 31) should make
> the
> >> job.
> >>
> >> IMO, we should just fix this case. After further study, I don't
> think
> >> this is a DW issue, but rather an SOC integration issue.
> >>
> >> I believe you can just fixup the address in the pp->ops->host_init
> hook.
> >>
> >
> > Yes I guess that I could just assign pp->(*)_mod_base to the CPU
> address
> > in DW and mask it out in dra7xx_pcie_host_init()...
> >
> > Kishon, would you be ok with that?
> 
> Initially I was using *base-mask* property from dt. Me and Arnd (cc'ed)
> had
> this discussion [1] before we decided the current approach. It'll be
> good to
> check with Arnd too.
> 
> [1] ->  http://lists.infradead.org/pipermail/linux-arm-kernel/2014-
> May/253528.html


In this patch you use the mask into designwareinstead the approach 
proposed by Rob means to have the mask declared in the dra7 driver and
you modified the pp members in dra7xx_pcie_host_init by masking them...

BTW good to have Arnd opinion too..
> 
> Thanks
> Kishon

RE: [PATCH v6] PCI: Store PCIe bus address in struct of_pci_range

2015-07-31 Thread Gabriele Paoloni

[+cc Kishon]

> -Original Message-
> From: linux-pci-ow...@vger.kernel.org [mailto:linux-pci-
> ow...@vger.kernel.org] On Behalf Of Rob Herring
> Sent: Thursday, July 30, 2015 9:42 PM
> To: Gabriele Paoloni
> Cc: Bjorn Helgaas; a...@arndb.de; lorenzo.pieral...@arm.com; Wangzhou
> (B); robh...@kernel.org; james.mo...@arm.com; liviu.du...@arm.com;
> linux-...@vger.kernel.org; linux-arm-ker...@lists.infradead.org;
> devicetree@vger.kernel.org; Yuanzhichang; Zhudacai; zhangjukuo;
> qiuzhenfa; Liguozhu (Kenneth); Jingoo Han; Pratyush Anand
> Subject: Re: [PATCH v6] PCI: Store PCIe bus address in struct
> of_pci_range
> 
> On Thu, Jul 30, 2015 at 12:34 PM, Gabriele Paoloni
>  wrote:
> >> -Original Message-
> >> From: Bjorn Helgaas [mailto:bhelg...@google.com]
> >> Sent: 30 July 2015 18:15
> >> On Thu, Jul 30, 2015 at 04:50:55PM +, Gabriele Paoloni wrote:
> >> > > -Original Message-
> >> > > From: linux-pci-ow...@vger.kernel.org [mailto:linux-pci-
> >> > > ow...@vger.kernel.org] On Behalf Of Bjorn Helgaas
> >> > > Sent: Thursday, July 30, 2015 5:15 PM
> >> > > On Thu, Jul 30, 2015 at 01:52:13PM +, Gabriele Paoloni wrote:
> 
> [...]
> 
> >> > > > I don’t think we should rely on [CPU] addresses...what if the
> >> > > intermediate
> >> > > > translation layer changes the lower significant bits of the
> "bus
> >> > > address"
> >> > > > to translate into a cpu address?
> >> > >
> >> > > Is it really a possiblity that the lower bits could be changed?
> >> >
> >> > I've checked all the current deignware users DTs except "pci-
> >> layerscape"
> >> > that I could not find:
> >> > spear1310.dtsi
> >> > spear1340.dtsi
> >> > dra7.dtsi
> >> > imx6qdl.dtsi
> >> > imx6sx.dtsi
> >> > keystone.dtsi
> >> > exynos5440.dtsi
> >> >
> >> > None of them modifies the lower bits. To be more precise the only
> guy
> >> > that provides another translation layer is "dra7.dtsi":
> >> > axi0
> >> > http://lxr.free-
> electrons.com/source/arch/arm/boot/dts/dra7.dtsi#L207
> >> >
> >> > axi1
> >> > http://lxr.free-
> electrons.com/source/arch/arm/boot/dts/dra7.dtsi#L241
> >> >
> >> > For this case masking the top 4bits (bits28 to 31) should make the
> job.
> 
> IMO, we should just fix this case. After further study, I don't think
> this is a DW issue, but rather an SOC integration issue.
> 
> I believe you can just fixup the address in the pp->ops->host_init hook.
> 

Yes I guess that I could just assign pp->(*)_mod_base to the CPU address 
in DW and mask it out in dra7xx_pcie_host_init()...

Kishon, would you be ok with that? 


> In looking at this, I'm curious why only 2 ATU viewports are used by
> default as this causes switching on config accesses. Probably some
> configuration only has 2 viewports. This would not even work on SMP
> systems! Memory and i/o accesses do not have any lock. A config access
> on one core will temporarily disable the i/o or memory viewport which
> will cause an abort, dropped, or garbage data on an i/o or memory
> access from another core. You would have to be accessing cfg space on
> a bus other than the root bus, so maybe no one is doing that.
> 
> >> >
> >> > Speaking in general terms so far I've always seen linear mappings
> >> > that differ by bitmask offset, however linear does not mean that
> you
> >> > cannot affect the lower bits: e.g. <0x0> to <0x0 + size> can map
> to
> >> > <0xcafe to 0xcafe + size>, but I guess that for HW design
> >> reasons
> >> > it is much easier to remap directly using a bitmask...but I was
> not
> >> sure
> >> > and I didn't think about the problems that can arise with ACPI.
> 
> For higher speed buses, the h/w designs are not going to be doing
> complicated translations in order to meet timing requirements. At the
> top level only the highest order bits are going to be looked at. For
> downstream segments, the high order bits may get dropped to simplify
> routing. If an IP block has full address bits in this case, they could
> either be tied to 0 or tied off to the correct address. Either is
> reasonable, so I'm sure there is h/w doing both. That doesn't mean h/w
> designers haven't done something crazy, too.
> 
> >&g

RE: [PATCH v5 1/5] ARM/PCI: remove align_resource in pci_sys_data

2015-07-31 Thread Gabriele Paoloni

Hi Rob, Thanks for reviewing

> -Original Message-
> From: robherri...@gmail.com [mailto:robherri...@gmail.com] On Behalf Of Rob
> Herring
> Sent: 30 July 2015 23:48
> To: Lorenzo Pieralisi; Russell King - ARM Linux; Wangzhou (B)
> Cc: Bjorn Helgaas; Jingoo Han; Pratyush Anand; Arnd Bergmann; Gabriele 
> Paoloni;
> James Morse; Liviu Dudau; thomas.petazz...@free-electrons.com; Jason Cooper;
> linux-...@vger.kernel.org; linux-arm-ker...@lists.infradead.org;
> devicetree@vger.kernel.org; Yuanzhichang; Zhudacai; zhangjukuo; qiuzhenfa;
> liudongdong (C); qiujiang; Kangfenglong; Liguozhu (Kenneth)
> Subject: Re: [PATCH v5 1/5] ARM/PCI: remove align_resource in pci_sys_data
> 
> On Tue, Jul 28, 2015 at 12:44 PM, Lorenzo Pieralisi
>  wrote:
> > [CC'ing RMK]
> >
> > On Tue, Jul 28, 2015 at 08:17:18AM +0100, Zhou Wang wrote:
> >> On 2015/7/25 11:21, Zhou Wang wrote:
> >> > From: Gabriele Paoloni 
> >> >
> >> > This patch is needed in order to unify the PCIe designware framework for
> ARM and
> >> > ARM64 architectures. In the PCIe designware unification process we are
> calling
> >> > pci_create_root_bus() passing a "sysdata" parameter that is the same for
> both
> >> > ARM and ARM64 and is of type "struct pcie_port*". In the ARM case this
> will
> >> > cause a problem with the function pcibios_align_resource(); in fact this
> will
> >> > cast "dev->sysdata" to "struct pci_sys_data*", whereas designware had
> passed a
> >> > "struct pcie_port*" pointer.
> >> >
> >> > This patch solves the issue by removing "align_resource" from
> "pci_sys_data"
> >> > struct and defining a static global function pointer in "bios32.c"
> >> >
> >> > Signed-off-by: Gabriele Paoloni 
> >>
> >> Hi Arnd and Rob,
> >>
> >> What is your opinion about this patch? Gabriele adds a global pointer in
> bios32.c
> >> to store align_resource, so we could remove sys->align_resource in
> pcibios_align_resource.
> >>
> >> As Lorenzo mentioned in v4 series, this is a temporary solution before
> moving
> >> align_resource to host bridge structure.
> >>
> >> Any comments welcome.
> >
> > The align_resource() pointer is just used in drivers/pci/host/pci-mvebu.c,
> > I would like the pci-mvebu.c maintainers to comment on this and test it, I
> > do not expect it to create any issue and might be a temporary solution to
> > make progress on ARM/ARM64 consolidation, it is a blocking point.
> >
> > It would be good if Russell can have a look too, I do not see what
> > issue this can trigger given that is just used in:
> 
> It's Russell's call on this if you want to touch bios32.c...
> 
> >
> > drivers/pci/host/pci-mvebu.c
> >
> > and a global pointer (not saying it is elegant, but it should work)
> > might be ok.
> >
> > So yes, comments very welcome.
> 
> I may be wrong, but I don't think even mvebu needs this as part of
> pcibios_align_resource. pcibios_align_resource is called for every
> device, but all mvebu should care about is the alignment of the root
> bus BARs (and corresponding MBus windows) which can be handled in
> probe. I can't see how regions within there matter. But that is just
> my 10 minute look at it.

I think Thomas Petazzoni should answer this...right?  

> 
> If not, then I think align_resource should be a common per host
> function ptr. In other words, think about how to provide a default
> implementation of pcibios_align_resource. They almost all look the
> same to me with the same I/O 0x3xx address handling.

pcibios_align_resource already provides the default alignment job.
Are you suggesting to replace pcibios_align_resources implementation
with a stub and move the alignment job somewhere else...?

> 
> Rob
N�r��yb�X��ǧv�^�)޺{.n�+���z��z��z)w*jg����ݢj/���z�ޖ��2�ޙ&�)ߡ�a�����G���h��j:+v���w��٥

RE: [PATCH v6] PCI: Store PCIe bus address in struct of_pci_range

2015-07-30 Thread Gabriele Paoloni



> -Original Message-
> From: Bjorn Helgaas [mailto:bhelg...@google.com]
> Sent: 30 July 2015 18:15
> To: Gabriele Paoloni
> Cc: Rob Herring; a...@arndb.de; lorenzo.pieral...@arm.com; Wangzhou (B);
> robh...@kernel.org; james.mo...@arm.com; liviu.du...@arm.com; linux-
> p...@vger.kernel.org; linux-arm-ker...@lists.infradead.org;
> devicetree@vger.kernel.org; Yuanzhichang; Zhudacai; zhangjukuo;
> qiuzhenfa; Liguozhu (Kenneth); Jingoo Han; Pratyush Anand
> Subject: Re: [PATCH v6] PCI: Store PCIe bus address in struct
> of_pci_range
> 
> [+cc Jingoo, Pratyush]
> 
> On Thu, Jul 30, 2015 at 04:50:55PM +, Gabriele Paoloni wrote:
> > > -Original Message-
> > > From: linux-pci-ow...@vger.kernel.org [mailto:linux-pci-
> > > ow...@vger.kernel.org] On Behalf Of Bjorn Helgaas
> > > Sent: Thursday, July 30, 2015 5:15 PM
> > > To: Gabriele Paoloni
> > > Cc: Rob Herring; a...@arndb.de; lorenzo.pieral...@arm.com; Wangzhou
> (B);
> > > robh...@kernel.org; james.mo...@arm.com; liviu.du...@arm.com; linux-
> > > p...@vger.kernel.org; linux-arm-ker...@lists.infradead.org;
> > > devicetree@vger.kernel.org; Yuanzhichang; Zhudacai; zhangjukuo;
> > > qiuzhenfa; Liguozhu (Kenneth)
> > > Subject: Re: [PATCH v6] PCI: Store PCIe bus address in struct
> > > of_pci_range
> > >
> > > On Thu, Jul 30, 2015 at 01:52:13PM +, Gabriele Paoloni wrote:
> > > >
> > > >
> > > > > -Original Message-
> > > > > From: linux-pci-ow...@vger.kernel.org [mailto:linux-pci-
> > > > > ow...@vger.kernel.org] On Behalf Of Rob Herring
> > > > > Sent: Thursday, July 30, 2015 2:43 PM
> > > > > To: Gabriele Paoloni
> > > > > Cc: Bjorn Helgaas; a...@arndb.de; lorenzo.pieral...@arm.com;
> > > Wangzhou
> > > > > (B); robh...@kernel.org; james.mo...@arm.com;
> liviu.du...@arm.com;
> > > > > linux-...@vger.kernel.org; linux-arm-ker...@lists.infradead.org;
> > > > > devicetree@vger.kernel.org; Yuanzhichang; Zhudacai; zhangjukuo;
> > > > > qiuzhenfa; Liguozhu (Kenneth)
> > > > > Subject: Re: [PATCH v6] PCI: Store PCIe bus address in struct
> > > > > of_pci_range
> > > > >
> > > > > On Wed, Jul 29, 2015 at 2:44 PM, Gabriele Paoloni
> > > > >  wrote:
> > > > > > Hi Bjorn
> > > > > >
> > > > > > Many Thanks for your reply
> > > > > >
> > > > > > I have commented back inline with resolutions from my side.
> > > > > >
> > > > > > If you're ok with them I'll send it out a new version in the
> > > > > appropriate patchset
> > > > > >
> > > > > > Cheers
> > > > > >
> > > > > > Gab
> > > > > >
> > > > > >> -Original Message-
> > > > > >> From: Bjorn Helgaas [mailto:bhelg...@google.com]
> > > > > >> Sent: Wednesday, July 29, 2015 6:21 PM
> > > > > >> To: Gabriele Paoloni
> > > > > >> Cc: a...@arndb.de; lorenzo.pieral...@arm.com; Wangzhou (B);
> > > > > >> robh...@kernel.org; james.mo...@arm.com; liviu.du...@arm.com;
> > > linux-
> > > > > >> p...@vger.kernel.org; linux-arm-ker...@lists.infradead.org;
> > > > > >> devicetree@vger.kernel.org; Yuanzhichang; Zhudacai;
> zhangjukuo;
> > > > > >> qiuzhenfa; Liguozhu (Kenneth)
> > > > > >> Subject: Re: [PATCH v6] PCI: Store PCIe bus address in struct
> > > > > >> of_pci_range
> > > > > >>
> > > > > >> Hi Gabriele,
> > > > > >>
> > > > > >> As far as I can tell, this is not specific to PCIe, so please
> > > use
> > > > > "PCI"
> > > > > >> in
> > > > > >> the subject as a generic term that includes both PCI and PCIe.
> > > > > >
> > > > > > sure agreed
> > > > > >
> > > > > >>
> > > > > >> On Mon, Jul 27, 2015 at 11:17:03PM +0800, Gabriele Paoloni
> wrote:
> > > > > >> > From: gabriele paoloni 
> > > > > >> >
> > > > > >> > This patch is needed port PCIe designware to new DT
> > > parsing
> > > > > API
> > > > > >> >

RE: [PATCH v6] PCI: Store PCIe bus address in struct of_pci_range

2015-07-30 Thread Gabriele Paoloni



> -Original Message-
> From: linux-pci-ow...@vger.kernel.org [mailto:linux-pci-
> ow...@vger.kernel.org] On Behalf Of Bjorn Helgaas
> Sent: Thursday, July 30, 2015 5:15 PM
> To: Gabriele Paoloni
> Cc: Rob Herring; a...@arndb.de; lorenzo.pieral...@arm.com; Wangzhou (B);
> robh...@kernel.org; james.mo...@arm.com; liviu.du...@arm.com; linux-
> p...@vger.kernel.org; linux-arm-ker...@lists.infradead.org;
> devicetree@vger.kernel.org; Yuanzhichang; Zhudacai; zhangjukuo;
> qiuzhenfa; Liguozhu (Kenneth)
> Subject: Re: [PATCH v6] PCI: Store PCIe bus address in struct
> of_pci_range
> 
> On Thu, Jul 30, 2015 at 01:52:13PM +, Gabriele Paoloni wrote:
> >
> >
> > > -Original Message-
> > > From: linux-pci-ow...@vger.kernel.org [mailto:linux-pci-
> > > ow...@vger.kernel.org] On Behalf Of Rob Herring
> > > Sent: Thursday, July 30, 2015 2:43 PM
> > > To: Gabriele Paoloni
> > > Cc: Bjorn Helgaas; a...@arndb.de; lorenzo.pieral...@arm.com;
> Wangzhou
> > > (B); robh...@kernel.org; james.mo...@arm.com; liviu.du...@arm.com;
> > > linux-...@vger.kernel.org; linux-arm-ker...@lists.infradead.org;
> > > devicetree@vger.kernel.org; Yuanzhichang; Zhudacai; zhangjukuo;
> > > qiuzhenfa; Liguozhu (Kenneth)
> > > Subject: Re: [PATCH v6] PCI: Store PCIe bus address in struct
> > > of_pci_range
> > >
> > > On Wed, Jul 29, 2015 at 2:44 PM, Gabriele Paoloni
> > >  wrote:
> > > > Hi Bjorn
> > > >
> > > > Many Thanks for your reply
> > > >
> > > > I have commented back inline with resolutions from my side.
> > > >
> > > > If you're ok with them I'll send it out a new version in the
> > > appropriate patchset
> > > >
> > > > Cheers
> > > >
> > > > Gab
> > > >
> > > >> -Original Message-
> > > >> From: Bjorn Helgaas [mailto:bhelg...@google.com]
> > > >> Sent: Wednesday, July 29, 2015 6:21 PM
> > > >> To: Gabriele Paoloni
> > > >> Cc: a...@arndb.de; lorenzo.pieral...@arm.com; Wangzhou (B);
> > > >> robh...@kernel.org; james.mo...@arm.com; liviu.du...@arm.com;
> linux-
> > > >> p...@vger.kernel.org; linux-arm-ker...@lists.infradead.org;
> > > >> devicetree@vger.kernel.org; Yuanzhichang; Zhudacai; zhangjukuo;
> > > >> qiuzhenfa; Liguozhu (Kenneth)
> > > >> Subject: Re: [PATCH v6] PCI: Store PCIe bus address in struct
> > > >> of_pci_range
> > > >>
> > > >> Hi Gabriele,
> > > >>
> > > >> As far as I can tell, this is not specific to PCIe, so please
> use
> > > "PCI"
> > > >> in
> > > >> the subject as a generic term that includes both PCI and PCIe.
> > > >
> > > > sure agreed
> > > >
> > > >>
> > > >> On Mon, Jul 27, 2015 at 11:17:03PM +0800, Gabriele Paoloni wrote:
> > > >> > From: gabriele paoloni 
> > > >> >
> > > >> > This patch is needed port PCIe designware to new DT
> parsing
> > > API
> > > >> > As discussed in
> > > >> > http://lists.infradead.org/pipermail/linux-arm-
> kernel/2015-
> > > >> January/317743.html
> > > >> > in designware we have a problem as the PCI addresses in
> the
> > > PCIe
> > > >> controller
> > > >> > address space are required in order to perform correct HW
> > > >> operation.
> > > >> >
> > > >> > In order to solve this problem commit f4c55c5a3 "PCI:
> > > designware:
> > > >> > Program ATU with untranslated address" added code to read
> the
> > > >> PCIe
> > > >>
> > > >> Conventional reference is 12-char SHA1, like this:
> > > >>
> > > >>   f4c55c5a3f7f ("PCI: designware: Program ATU with untranslated
> > > >> address")
> > > >
> > > > Agreed, will change this
> > > >
> > > >>
> > > >> > controller start address directly from the DT ranges.
> > > >> >
> > > >> > In the new DT parsing API
> of_pci_get_host_bridge_resources()
> > > >> hides the
> > > >> > DT parser from the host controller drivers, so it is not
> > > possible
> > > &g

RE: [PATCH v6] PCI: Store PCIe bus address in struct of_pci_range

2015-07-30 Thread Gabriele Paoloni



> -Original Message-
> From: linux-pci-ow...@vger.kernel.org [mailto:linux-pci-
> ow...@vger.kernel.org] On Behalf Of Gabriele Paoloni
> Sent: Thursday, July 30, 2015 2:52 PM
> To: Rob Herring
> Cc: Bjorn Helgaas; a...@arndb.de; lorenzo.pieral...@arm.com; Wangzhou
> (B); robh...@kernel.org; james.mo...@arm.com; liviu.du...@arm.com;
> linux-...@vger.kernel.org; linux-arm-ker...@lists.infradead.org;
> devicetree@vger.kernel.org; Yuanzhichang; Zhudacai; zhangjukuo;
> qiuzhenfa; Liguozhu (Kenneth)
> Subject: RE: [PATCH v6] PCI: Store PCIe bus address in struct
> of_pci_range
> 
> 
> 
> > -Original Message-
> > From: linux-pci-ow...@vger.kernel.org [mailto:linux-pci-
> > ow...@vger.kernel.org] On Behalf Of Rob Herring
> > Sent: Thursday, July 30, 2015 2:43 PM
> > To: Gabriele Paoloni
> > Cc: Bjorn Helgaas; a...@arndb.de; lorenzo.pieral...@arm.com; Wangzhou
> > (B); robh...@kernel.org; james.mo...@arm.com; liviu.du...@arm.com;
> > linux-...@vger.kernel.org; linux-arm-ker...@lists.infradead.org;
> > devicetree@vger.kernel.org; Yuanzhichang; Zhudacai; zhangjukuo;
> > qiuzhenfa; Liguozhu (Kenneth)
> > Subject: Re: [PATCH v6] PCI: Store PCIe bus address in struct
> > of_pci_range
> >
> > On Wed, Jul 29, 2015 at 2:44 PM, Gabriele Paoloni
> >  wrote:
> > > Hi Bjorn
> > >
> > > Many Thanks for your reply
> > >
> > > I have commented back inline with resolutions from my side.
> > >
> > > If you're ok with them I'll send it out a new version in the
> > appropriate patchset
> > >
> > > Cheers
> > >
> > > Gab
> > >
> > >> -Original Message-
> > >> From: Bjorn Helgaas [mailto:bhelg...@google.com]
> > >> Sent: Wednesday, July 29, 2015 6:21 PM
> > >> To: Gabriele Paoloni
> > >> Cc: a...@arndb.de; lorenzo.pieral...@arm.com; Wangzhou (B);
> > >> robh...@kernel.org; james.mo...@arm.com; liviu.du...@arm.com;
> linux-
> > >> p...@vger.kernel.org; linux-arm-ker...@lists.infradead.org;
> > >> devicetree@vger.kernel.org; Yuanzhichang; Zhudacai; zhangjukuo;
> > >> qiuzhenfa; Liguozhu (Kenneth)
> > >> Subject: Re: [PATCH v6] PCI: Store PCIe bus address in struct
> > >> of_pci_range
> > >>
> > >> Hi Gabriele,
> > >>
> > >> As far as I can tell, this is not specific to PCIe, so please use
> > "PCI"
> > >> in
> > >> the subject as a generic term that includes both PCI and PCIe.
> > >
> > > sure agreed
> > >
> > >>
> > >> On Mon, Jul 27, 2015 at 11:17:03PM +0800, Gabriele Paoloni wrote:
> > >> > From: gabriele paoloni 
> > >> >
> > >> > This patch is needed port PCIe designware to new DT parsing
> > API
> > >> > As discussed in
> > >> > http://lists.infradead.org/pipermail/linux-arm-kernel/2015-
> > >> January/317743.html
> > >> > in designware we have a problem as the PCI addresses in the
> > PCIe
> > >> controller
> > >> > address space are required in order to perform correct HW
> > >> operation.
> > >> >
> > >> > In order to solve this problem commit f4c55c5a3 "PCI:
> > designware:
> > >> > Program ATU with untranslated address" added code to read
> the
> > >> PCIe
> > >>
> > >> Conventional reference is 12-char SHA1, like this:
> > >>
> > >>   f4c55c5a3f7f ("PCI: designware: Program ATU with untranslated
> > >> address")
> > >
> > > Agreed, will change this
> > >
> > >>
> > >> > controller start address directly from the DT ranges.
> > >> >
> > >> > In the new DT parsing API of_pci_get_host_bridge_resources()
> > >> hides the
> > >> > DT parser from the host controller drivers, so it is not
> > possible
> > >> > for drivers to parse values directly from the DT.
> > >> >
> > >> > In http://www.spinics.net/lists/linux-pci/msg42540.html we
> > >> already tried
> > >> > to use the new DT parsing API but there is a bug (obviously)
> > in
> > >> setting
> > >> > the <*>_mod_base addresses
> > >> > Applying this patch we can easily set "<*>_mod_base = win-
> > >> >__

RE: [PATCH v6] PCI: Store PCIe bus address in struct of_pci_range

2015-07-30 Thread Gabriele Paoloni



> -Original Message-
> From: linux-pci-ow...@vger.kernel.org [mailto:linux-pci-
> ow...@vger.kernel.org] On Behalf Of Rob Herring
> Sent: Thursday, July 30, 2015 2:43 PM
> To: Gabriele Paoloni
> Cc: Bjorn Helgaas; a...@arndb.de; lorenzo.pieral...@arm.com; Wangzhou
> (B); robh...@kernel.org; james.mo...@arm.com; liviu.du...@arm.com;
> linux-...@vger.kernel.org; linux-arm-ker...@lists.infradead.org;
> devicetree@vger.kernel.org; Yuanzhichang; Zhudacai; zhangjukuo;
> qiuzhenfa; Liguozhu (Kenneth)
> Subject: Re: [PATCH v6] PCI: Store PCIe bus address in struct
> of_pci_range
> 
> On Wed, Jul 29, 2015 at 2:44 PM, Gabriele Paoloni
>  wrote:
> > Hi Bjorn
> >
> > Many Thanks for your reply
> >
> > I have commented back inline with resolutions from my side.
> >
> > If you're ok with them I'll send it out a new version in the
> appropriate patchset
> >
> > Cheers
> >
> > Gab
> >
> >> -----Original Message-
> >> From: Bjorn Helgaas [mailto:bhelg...@google.com]
> >> Sent: Wednesday, July 29, 2015 6:21 PM
> >> To: Gabriele Paoloni
> >> Cc: a...@arndb.de; lorenzo.pieral...@arm.com; Wangzhou (B);
> >> robh...@kernel.org; james.mo...@arm.com; liviu.du...@arm.com; linux-
> >> p...@vger.kernel.org; linux-arm-ker...@lists.infradead.org;
> >> devicetree@vger.kernel.org; Yuanzhichang; Zhudacai; zhangjukuo;
> >> qiuzhenfa; Liguozhu (Kenneth)
> >> Subject: Re: [PATCH v6] PCI: Store PCIe bus address in struct
> >> of_pci_range
> >>
> >> Hi Gabriele,
> >>
> >> As far as I can tell, this is not specific to PCIe, so please use
> "PCI"
> >> in
> >> the subject as a generic term that includes both PCI and PCIe.
> >
> > sure agreed
> >
> >>
> >> On Mon, Jul 27, 2015 at 11:17:03PM +0800, Gabriele Paoloni wrote:
> >> > From: gabriele paoloni 
> >> >
> >> > This patch is needed port PCIe designware to new DT parsing
> API
> >> > As discussed in
> >> > http://lists.infradead.org/pipermail/linux-arm-kernel/2015-
> >> January/317743.html
> >> > in designware we have a problem as the PCI addresses in the
> PCIe
> >> controller
> >> > address space are required in order to perform correct HW
> >> operation.
> >> >
> >> > In order to solve this problem commit f4c55c5a3 "PCI:
> designware:
> >> > Program ATU with untranslated address" added code to read the
> >> PCIe
> >>
> >> Conventional reference is 12-char SHA1, like this:
> >>
> >>   f4c55c5a3f7f ("PCI: designware: Program ATU with untranslated
> >> address")
> >
> > Agreed, will change this
> >
> >>
> >> > controller start address directly from the DT ranges.
> >> >
> >> > In the new DT parsing API of_pci_get_host_bridge_resources()
> >> hides the
> >> > DT parser from the host controller drivers, so it is not
> possible
> >> > for drivers to parse values directly from the DT.
> >> >
> >> > In http://www.spinics.net/lists/linux-pci/msg42540.html we
> >> already tried
> >> > to use the new DT parsing API but there is a bug (obviously)
> in
> >> setting
> >> > the <*>_mod_base addresses
> >> > Applying this patch we can easily set "<*>_mod_base = win-
> >> >__res.start"
> >>
> >> By itself, this patch adds something.  It would help me understand
> it
> >> if
> >> the *user* of this new something were in the same patch series.
> >
> > the user is: "[PATCH v5 2/5] PCI: designware: Add ARM64 support"
> > I will ask Zhou Wang to include this patch in his patchset
> >
> >
> >>
> >> > This patch adds a new field in "struct of_pci_range" to store
> the
> >> > pci bus start address; it fills the field in
> >> of_pci_range_parser_one();
> >> > in of_pci_get_host_bridge_resources() it retrieves the
> resource
> >> entry
> >> > after it is created and added to the resource list and uses
> >> > entry->__res.start to store the pci controller address
> >>
> >> struct of_pci_range is starting to get confusing to non-OF folks
> like
> >> me.
> >> It now contains:
> >>
> >>   u32 pci_space;
> >>   u

RE: [PATCH v6] PCI: Store PCIe bus address in struct of_pci_range

2015-07-30 Thread Gabriele Paoloni

> -Original Message-
> From: Bjorn Helgaas [mailto:bhelg...@google.com]
> Sent: Wednesday, July 29, 2015 10:47 PM
> To: Gabriele Paoloni
> Cc: a...@arndb.de; lorenzo.pieral...@arm.com; Wangzhou (B);
> robh...@kernel.org; james.mo...@arm.com; liviu.du...@arm.com; linux-
> p...@vger.kernel.org; linux-arm-ker...@lists.infradead.org;
> devicetree@vger.kernel.org; Yuanzhichang; Zhudacai; zhangjukuo;
> qiuzhenfa; Liguozhu (Kenneth); Andrew Murray
> Subject: Re: [PATCH v6] PCI: Store PCIe bus address in struct
> of_pci_range
> 
> [+cc Andrew]
> 
> On Wed, Jul 29, 2015 at 07:44:18PM +, Gabriele Paoloni wrote:
> > > -Original Message-
> > > From: Bjorn Helgaas [mailto:bhelg...@google.com]
> > > Sent: Wednesday, July 29, 2015 6:21 PM
> > > To: Gabriele Paoloni
> 
> > > On Mon, Jul 27, 2015 at 11:17:03PM +0800, Gabriele Paoloni wrote:
> > > > From: gabriele paoloni 
> 
> > > > This patch adds a new field in "struct of_pci_range" to store
> the
> > > > pci bus start address; it fills the field in
> > > of_pci_range_parser_one();
> > > > in of_pci_get_host_bridge_resources() it retrieves the
> resource
> > > entry
> > > > after it is created and added to the resource list and uses
> > > > entry->__res.start to store the pci controller address
> > >
> > > struct of_pci_range is starting to get confusing to non-OF folks
> like
> > > me.
> > > It now contains:
> > >
> > >   u32 pci_space;
> > >   u64 pci_addr;
> > >   u64 cpu_addr;
> > >   u64 bus_addr;
> > >
> > > Can you explain what all these things mean, and maybe even add one-
> line
> > > comments to the structure?
> 
> > > pci_space: The only uses I see are to determine whether to print
> > > "Prefetch".  I don't see any real functionality that uses this.
> >
> > Looking at the code I agree. it's seems to be used only in powerpc
> > and microblaze to print out.
> > However from my understanding pci_space is the phys.hi field of the
> > ranges property: it defines the properties of the address space
> associated
> > to the PCI address. if you're curious you can find a nice and quick
> to read
> > "guide" in http://devicetree.org/MPC5200:PCI
> 
> I think pci_space should be removed and the users should test
> "range.flags & IORESOURCE_PREFETCH" instead.  That's already set by
> of_bus_pci_get_flags().  This is separate from your current patch, of
> course.

Ok so I'll do nothing in my patch about this; maybe I can propose a separate
patch for this, but I cannot test it (I've got no microblaze and powerpc 
neither)

> 
> 29b635c00f3e ("of/pci: Provide support for parsing PCI DT ranges
> property") added struct of_pci_range, and even at the time,
> of_bus_pci_get_flags() set IORESOURCE_PREFETCH in of_pci_range.flags.
> 
> 654837e8fe8d ("powerpc/pci: Use of_pci_range_parser helper in
> pci_process_bridge_OF_ranges") converted powerpc to use
> of_pci_range_parser() instead of parsing manually.  It converted other
> references to look at struct of_pci_range.flags; I'm not sure why it
> didn't do that for the prefetch bit.
> 
> I copied Andrew in case there's some subtlety here.
> 
> > > pci_addr: I assume this is a PCI bus address, like what you would
> see
> > > if
> > > you put an analyzer on the bus/link.  This address could go in a
> BAR.
> >
> > Yes, this is the PCI start address of the range: phys.mid + phys.low
> in the
> > guide mentioned above
> >
> > > cpu_addr: I assume this is a CPU physical address, like what you
> would
> > > see
> > > in /proc/iomem and what you would pass to ioremap().
> >
> > Yes correct
> >
> > > bus_addr: ?
> >
> > According to the guide above, this is the address into which the
> pci_address
> > get translated to and that is passed to the root complex. Between the
> root
> > complex and the CPU there can be intermediate translation layers:
> 
> I can't quite parse this, but I do understand how a host bridge can
> translate CPU physical addresses to a different range of PCI bus
> addresses.  What I don't understand is the difference between
> "pci_addr"
> and the "bus_addr" you're adding.

For example see:
http://lxr.free-electrons.com/source/arch/arm/boot/dts/imx6qdl.dtsi#L148

ranges = <0x0800 0 0x01f0 0x01f0 0 0x0008   /* configuration 
space *

RE: [PATCH v6] PCI: Store PCIe bus address in struct of_pci_range

2015-07-29 Thread Gabriele Paoloni

Hi Bjorn

Many Thanks for your reply

I have commented back inline with resolutions from my side.

If you're ok with them I'll send it out a new version in the appropriate 
patchset

Cheers

Gab

> -Original Message-
> From: Bjorn Helgaas [mailto:bhelg...@google.com]
> Sent: Wednesday, July 29, 2015 6:21 PM
> To: Gabriele Paoloni
> Cc: a...@arndb.de; lorenzo.pieral...@arm.com; Wangzhou (B);
> robh...@kernel.org; james.mo...@arm.com; liviu.du...@arm.com; linux-
> p...@vger.kernel.org; linux-arm-ker...@lists.infradead.org;
> devicetree@vger.kernel.org; Yuanzhichang; Zhudacai; zhangjukuo;
> qiuzhenfa; Liguozhu (Kenneth)
> Subject: Re: [PATCH v6] PCI: Store PCIe bus address in struct
> of_pci_range
> 
> Hi Gabriele,
> 
> As far as I can tell, this is not specific to PCIe, so please use "PCI"
> in
> the subject as a generic term that includes both PCI and PCIe.

sure agreed

> 
> On Mon, Jul 27, 2015 at 11:17:03PM +0800, Gabriele Paoloni wrote:
> > From: gabriele paoloni 
> >
> > This patch is needed port PCIe designware to new DT parsing API
> > As discussed in
> > http://lists.infradead.org/pipermail/linux-arm-kernel/2015-
> January/317743.html
> > in designware we have a problem as the PCI addresses in the PCIe
> controller
> > address space are required in order to perform correct HW
> operation.
> >
> > In order to solve this problem commit f4c55c5a3 "PCI: designware:
> > Program ATU with untranslated address" added code to read the
> PCIe
> 
> Conventional reference is 12-char SHA1, like this:
> 
>   f4c55c5a3f7f ("PCI: designware: Program ATU with untranslated
> address")

Agreed, will change this

> 
> > controller start address directly from the DT ranges.
> >
> > In the new DT parsing API of_pci_get_host_bridge_resources()
> hides the
> > DT parser from the host controller drivers, so it is not possible
> > for drivers to parse values directly from the DT.
> >
> > In http://www.spinics.net/lists/linux-pci/msg42540.html we
> already tried
> > to use the new DT parsing API but there is a bug (obviously) in
> setting
> > the <*>_mod_base addresses
> > Applying this patch we can easily set "<*>_mod_base = win-
> >__res.start"
> 
> By itself, this patch adds something.  It would help me understand it
> if
> the *user* of this new something were in the same patch series.

the user is: "[PATCH v5 2/5] PCI: designware: Add ARM64 support"
I will ask Zhou Wang to include this patch in his patchset


> 
> > This patch adds a new field in "struct of_pci_range" to store the
> > pci bus start address; it fills the field in
> of_pci_range_parser_one();
> > in of_pci_get_host_bridge_resources() it retrieves the resource
> entry
> > after it is created and added to the resource list and uses
> > entry->__res.start to store the pci controller address
> 
> struct of_pci_range is starting to get confusing to non-OF folks like
> me.
> It now contains:
> 
>   u32 pci_space;
>   u64 pci_addr;
>   u64 cpu_addr;
>   u64 bus_addr;
> 
> Can you explain what all these things mean, and maybe even add one-line
> comments to the structure?

sure I can add comments inline in the code

> 
> pci_space: The only uses I see are to determine whether to print
> "Prefetch".  I don't see any real functionality that uses this.

Looking at the code I agree. it's seems to be used only in powerpc 
and microblaze to print out.
However from my understanding pci_space is the phys.hi field of the 
ranges property: it defines the properties of the address space associated
to the PCI address. if you're curious you can find a nice and quick to read
"guide" in http://devicetree.org/MPC5200:PCI

> 
> pci_addr: I assume this is a PCI bus address, like what you would see
> if
> you put an analyzer on the bus/link.  This address could go in a BAR.

Yes, this is the PCI start address of the range: phys.mid + phys.low in the
guide mentioned above

> 
> cpu_addr: I assume this is a CPU physical address, like what you would
> see
> in /proc/iomem and what you would pass to ioremap().

Yes correct

> 
> bus_addr: ?
> 

According to the guide above, this is the address into which the pci_address 
get translated to and that is passed to the root complex. Between the root 
complex and the CPU there can be intermediate translation layers: see that to 
get pci_address we call "of_translate_address"; this will apply all the 
translation layers (ranges in the DT) that it finds till it comes to the root 
no

RE: [PATCH v6] PCI: Store PCIe bus address in struct of_pci_range

2015-07-29 Thread Gabriele Paoloni

Hi Bjorn

Liviu and Rob already acked, do you think it is ok to merge this?

Cheers

Gab

> -Original Message-
> From: Gabriele Paoloni
> Sent: Monday, July 27, 2015 4:17 PM
> To: Gabriele Paoloni; a...@arndb.de; lorenzo.pieral...@arm.com;
> Wangzhou (B); bhelg...@google.com; robh...@kernel.org;
> james.mo...@arm.com; liviu.du...@arm.com
> Cc: linux-...@vger.kernel.org; linux-arm-ker...@lists.infradead.org;
> devicetree@vger.kernel.org; Yuanzhichang; Zhudacai; zhangjukuo;
> qiuzhenfa; Liguozhu (Kenneth)
> Subject: [PATCH v6] PCI: Store PCIe bus address in struct of_pci_range
> 
> From: gabriele paoloni 
> 
> This patch is needed port PCIe designware to new DT parsing API
> As discussed in
> http://lists.infradead.org/pipermail/linux-arm-kernel/2015-
> January/317743.html
> in designware we have a problem as the PCI addresses in the PCIe
> controller
> address space are required in order to perform correct HW operation.
> 
> In order to solve this problem commit f4c55c5a3 "PCI: designware:
> Program ATU with untranslated address" added code to read the PCIe
> controller start address directly from the DT ranges.
> 
> In the new DT parsing API of_pci_get_host_bridge_resources() hides
> the
> DT parser from the host controller drivers, so it is not possible
> for drivers to parse values directly from the DT.
> 
> In http://www.spinics.net/lists/linux-pci/msg42540.html we already
> tried
> to use the new DT parsing API but there is a bug (obviously) in
> setting
> the <*>_mod_base addresses
> Applying this patch we can easily set "<*>_mod_base = win-
> >__res.start"
> 
> This patch adds a new field in "struct of_pci_range" to store the
> pci bus start address; it fills the field in
> of_pci_range_parser_one();
> in of_pci_get_host_bridge_resources() it retrieves the resource
> entry
> after it is created and added to the resource list and uses
> entry->__res.start to store the pci controller address
> 
> the patch is based on 4.2-rc1
> 
> Signed-off-by: Gabriele Paoloni 
> Acked-by: Liviu Dudau 
> Acked-by: Rob Herring 
> ---
>  drivers/of/address.c   | 2 ++
>  drivers/of/of_pci.c| 4 
>  include/linux/of_address.h | 1 +
>  3 files changed, 7 insertions(+)
> 
> diff --git a/drivers/of/address.c b/drivers/of/address.c
> index 8bfda6a..23a5793 100644
> --- a/drivers/of/address.c
> +++ b/drivers/of/address.c
> @@ -253,6 +253,7 @@ struct of_pci_range *of_pci_range_parser_one(struct
> of_pci_range_parser *parser,
>   struct of_pci_range *range)
>  {
>   const int na = 3, ns = 2;
> + const int p_ns = of_n_size_cells(parser->node);
> 
>   if (!range)
>   return NULL;
> @@ -265,6 +266,7 @@ struct of_pci_range *of_pci_range_parser_one(struct
> of_pci_range_parser *parser,
>   range->pci_addr = of_read_number(parser->range + 1, ns);
>   range->cpu_addr = of_translate_address(parser->node,
>   parser->range + na);
> + range->bus_addr = of_read_number(parser->range + na, p_ns);
>   range->size = of_read_number(parser->range + parser->pna + na,
> ns);
> 
>   parser->range += parser->np;
> diff --git a/drivers/of/of_pci.c b/drivers/of/of_pci.c
> index 5751dc5..fe57030 100644
> --- a/drivers/of/of_pci.c
> +++ b/drivers/of/of_pci.c
> @@ -198,6 +198,7 @@ int of_pci_get_host_bridge_resources(struct
> device_node *dev,
> 
>   pr_debug("Parsing ranges property...\n");
>   for_each_of_pci_range(&parser, &range) {
> + struct resource_entry *entry;
>   /* Read next ranges element */
>   if ((range.flags & IORESOURCE_TYPE_BITS) == IORESOURCE_IO)
>   snprintf(range_type, 4, " IO");
> @@ -240,6 +241,9 @@ int of_pci_get_host_bridge_resources(struct
> device_node *dev,
>   }
> 
>   pci_add_resource_offset(resources, res, res->start -
> range.pci_addr);
> + entry = list_last_entry(resources, struct resource_entry,
> node);
> + /* we are using __res for storing the PCI controller
> address */
> + entry->__res.start = range.bus_addr;
>   }
> 
>   return 0;
> diff --git a/include/linux/of_address.h b/include/linux/of_address.h
> index d88e81b..865f96e 100644
> --- a/include/linux/of_address.h
> +++ b/include/linux/of_address.h
> @@ -16,6 +16,7 @@ struct of_pci_range {
>   u32 pci_space;
>   u64 pci_addr;
>   u64 cpu_addr;
> + u64 bus_addr;
>   u64 size;
>   u32 flags;
>  };
> --
> 1.9.1

RE: [PATCH v5] PCI: Store PCIe bus address in struct of_pci_range

2015-07-27 Thread Gabriele Paoloni


> -Original Message-
> From: Gabriele Paoloni
> Sent: Monday, July 27, 2015 11:45 AM
> To: Gabriele Paoloni; a...@arndb.de; lorenzo.pieral...@arm.com;
> Wangzhou (B); bhelg...@google.com; robh...@kernel.org;
> james.mo...@arm.com; liviu.du...@arm.com
> Cc: linux-...@vger.kernel.org; linux-arm-ker...@lists.infradead.org;
> devicetree@vger.kernel.org; Yuanzhichang; Zhudacai; zhangjukuo;
> qiuzhenfa; Liguozhu (Kenneth)
> Subject: [PATCH v5] PCI: Store PCIe bus address in struct of_pci_range
> 
> From: gabriele paoloni 
> 
> This patch is needed port PCIe designware to new DT parsing API
> As discussed in
> http://lists.infradead.org/pipermail/linux-arm-kernel/2015-
> January/317743.html
> in designware we have a problem as the PCI addresses in the PCIe
> controller
> address space are required in order to perform correct HW operation.
> 
> In order to solve this problem commit f4c55c5a3 "PCI: designware:
> Program ATU with untranslated address" added code to read the PCIe
> controller start address directly from the DT ranges.
> 
> In the new DT parsing API of_pci_get_host_bridge_resources() hides
> the
> DT parser from the host controller drivers, so it is not possible
> for drivers to parse values directly from the DT.
> 
> In http://www.spinics.net/lists/linux-pci/msg42540.html we already
> tried
> to use the new DT parsing API but there is a bug (obviously) in
> setting
> the <*>_mod_base addresses
> Applying this patch we can easily set "<*>_mod_base = win-
> >__res.start"
> 
> This patch adds a new field in "struct of_pci_range" to store the
> pci bus start address; it fills the field in
> of_pci_range_parser_one();
> in of_pci_get_host_bridge_resources() it retrieves the resource
> entry
> after it is created and added to the resource list and uses
> entry->__res.start to store the pci controller address
> 
> the patch is based on 4.2-rc1
> 
> Signed-off-by: Gabriele Paoloni 
> Acked-by: Liviu Dudai 

Fixed Liviu's surname in v6, sorry I messed up amending the commit

> Acked-by: Rob Herring 
> ---
>  drivers/of/address.c   | 2 ++
>  drivers/of/of_pci.c| 4 
>  include/linux/of_address.h | 1 +
>  3 files changed, 7 insertions(+)
> 
> diff --git a/drivers/of/address.c b/drivers/of/address.c
> index 8bfda6a..23a5793 100644
> --- a/drivers/of/address.c
> +++ b/drivers/of/address.c
> @@ -253,6 +253,7 @@ struct of_pci_range *of_pci_range_parser_one(struct
> of_pci_range_parser *parser,
>   struct of_pci_range *range)
>  {
>   const int na = 3, ns = 2;
> + const int p_ns = of_n_size_cells(parser->node);
> 
>   if (!range)
>   return NULL;
> @@ -265,6 +266,7 @@ struct of_pci_range *of_pci_range_parser_one(struct
> of_pci_range_parser *parser,
>   range->pci_addr = of_read_number(parser->range + 1, ns);
>   range->cpu_addr = of_translate_address(parser->node,
>   parser->range + na);
> + range->bus_addr = of_read_number(parser->range + na, p_ns);
>   range->size = of_read_number(parser->range + parser->pna + na,
> ns);
> 
>   parser->range += parser->np;
> diff --git a/drivers/of/of_pci.c b/drivers/of/of_pci.c
> index 5751dc5..fe57030 100644
> --- a/drivers/of/of_pci.c
> +++ b/drivers/of/of_pci.c
> @@ -198,6 +198,7 @@ int of_pci_get_host_bridge_resources(struct
> device_node *dev,
> 
>   pr_debug("Parsing ranges property...\n");
>   for_each_of_pci_range(&parser, &range) {
> + struct resource_entry *entry;
>   /* Read next ranges element */
>   if ((range.flags & IORESOURCE_TYPE_BITS) == IORESOURCE_IO)
>   snprintf(range_type, 4, " IO");
> @@ -240,6 +241,9 @@ int of_pci_get_host_bridge_resources(struct
> device_node *dev,
>   }
> 
>   pci_add_resource_offset(resources, res, res->start -
> range.pci_addr);
> + entry = list_last_entry(resources, struct resource_entry,
> node);
> + /* we are using __res for storing the PCI controller
> address */
> + entry->__res.start = range.bus_addr;
>   }
> 
>   return 0;
> diff --git a/include/linux/of_address.h b/include/linux/of_address.h
> index d88e81b..865f96e 100644
> --- a/include/linux/of_address.h
> +++ b/include/linux/of_address.h
> @@ -16,6 +16,7 @@ struct of_pci_range {
>   u32 pci_space;
>   u64 pci_addr;
>   u64 cpu_addr;
> + u64 bus_addr;
>   u64 size;
>   u32 flags;
>  };
> --
> 1.9.1

N�Р骒r��yb�X�肚�v�^�)藓{.n�+���z��z谵z)��骅w*jg�报�茛j/�赇z罐���2���ㄨ��&�)摺�a囤���G���h��j:+v���w��佶

[PATCH v6] PCI: Store PCIe bus address in struct of_pci_range

2015-07-27 Thread Gabriele Paoloni

From: gabriele paoloni 

This patch is needed port PCIe designware to new DT parsing API
As discussed in

http://lists.infradead.org/pipermail/linux-arm-kernel/2015-January/317743.html
in designware we have a problem as the PCI addresses in the PCIe controller
address space are required in order to perform correct HW operation.

In order to solve this problem commit f4c55c5a3 "PCI: designware:
Program ATU with untranslated address" added code to read the PCIe
controller start address directly from the DT ranges.

In the new DT parsing API of_pci_get_host_bridge_resources() hides the
DT parser from the host controller drivers, so it is not possible
for drivers to parse values directly from the DT.

In http://www.spinics.net/lists/linux-pci/msg42540.html we already tried
to use the new DT parsing API but there is a bug (obviously) in setting
the <*>_mod_base addresses
Applying this patch we can easily set "<*>_mod_base = win->__res.start"

This patch adds a new field in "struct of_pci_range" to store the
pci bus start address; it fills the field in of_pci_range_parser_one();
in of_pci_get_host_bridge_resources() it retrieves the resource entry
after it is created and added to the resource list and uses
entry->__res.start to store the pci controller address

the patch is based on 4.2-rc1

Signed-off-by: Gabriele Paoloni 
Acked-by: Liviu Dudau 
Acked-by: Rob Herring 
---
 drivers/of/address.c   | 2 ++
 drivers/of/of_pci.c| 4 
 include/linux/of_address.h | 1 +
 3 files changed, 7 insertions(+)

diff --git a/drivers/of/address.c b/drivers/of/address.c
index 8bfda6a..23a5793 100644
--- a/drivers/of/address.c
+++ b/drivers/of/address.c
@@ -253,6 +253,7 @@ struct of_pci_range *of_pci_range_parser_one(struct 
of_pci_range_parser *parser,
struct of_pci_range *range)
 {
const int na = 3, ns = 2;
+   const int p_ns = of_n_size_cells(parser->node);
 
if (!range)
return NULL;
@@ -265,6 +266,7 @@ struct of_pci_range *of_pci_range_parser_one(struct 
of_pci_range_parser *parser,
range->pci_addr = of_read_number(parser->range + 1, ns);
range->cpu_addr = of_translate_address(parser->node,
parser->range + na);
+   range->bus_addr = of_read_number(parser->range + na, p_ns);
range->size = of_read_number(parser->range + parser->pna + na, ns);
 
parser->range += parser->np;
diff --git a/drivers/of/of_pci.c b/drivers/of/of_pci.c
index 5751dc5..fe57030 100644
--- a/drivers/of/of_pci.c
+++ b/drivers/of/of_pci.c
@@ -198,6 +198,7 @@ int of_pci_get_host_bridge_resources(struct device_node 
*dev,
 
pr_debug("Parsing ranges property...\n");
for_each_of_pci_range(&parser, &range) {
+   struct resource_entry *entry;
/* Read next ranges element */
if ((range.flags & IORESOURCE_TYPE_BITS) == IORESOURCE_IO)
snprintf(range_type, 4, " IO");
@@ -240,6 +241,9 @@ int of_pci_get_host_bridge_resources(struct device_node 
*dev,
}
 
pci_add_resource_offset(resources, res, res->start - 
range.pci_addr);
+   entry = list_last_entry(resources, struct resource_entry, node);
+   /* we are using __res for storing the PCI controller address */
+   entry->__res.start = range.bus_addr;
}
 
return 0;
diff --git a/include/linux/of_address.h b/include/linux/of_address.h
index d88e81b..865f96e 100644
--- a/include/linux/of_address.h
+++ b/include/linux/of_address.h
@@ -16,6 +16,7 @@ struct of_pci_range {
u32 pci_space;
u64 pci_addr;
u64 cpu_addr;
+   u64 bus_addr;
u64 size;
u32 flags;
 };
-- 
1.9.1

--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

RE: [PATCH v4] PCI: Store PCIe bus address in struct of_pci_range

2015-07-27 Thread Gabriele Paoloni

Sent "[PATCH v5] PCI: Store PCIe bus address in struct of_pci_range" with Rob 
Herring ack

> -Original Message-
> From: Gabriele Paoloni
> Sent: Wednesday, July 22, 2015 3:22 PM
> To: Gabriele Paoloni; a...@arndb.de; lorenzo.pieral...@arm.com;
> Wangzhou (B); bhelg...@google.com; robh...@kernel.org;
> james.mo...@arm.com; liviu.du...@arm.com
> Cc: linux-...@vger.kernel.org; linux-arm-ker...@lists.infradead.org;
> devicetree@vger.kernel.org; Yuanzhichang; Zhudacai; zhangjukuo;
> qiuzhenfa; Liguozhu (Kenneth)
> Subject: [PATCH v4] PCI: Store PCIe bus address in struct of_pci_range
> 
> From: gabriele paoloni 
> 
> This patch is needed port PCIe designware to new DT parsing API
> As discussed in
> http://lists.infradead.org/pipermail/linux-arm-kernel/2015-
> January/317743.html
> in designware we have a problem as the PCI addresses in the PCIe
> controller
> address space are required in order to perform correct HW operation.
> 
> In order to solve this problem commit
> f4c55c5a3 "PCI: designware: Program ATU with untranslated address"
> added code to read the PCIe controller start address directly from
> the
> DT ranges.
> 
> In the new DT parsing API of_pci_get_host_bridge_resources() hides
> the
> DT parser from the host controller drivers, so it is not possible
> for drivers to parse values directly from the DT.
> 
> In http://www.spinics.net/lists/linux-pci/msg42540.html we already
> tried
> to use the new DT parsing API but there is a bug (obviously) in
> setting
> the <*>_mod_base addresses
> Applying this patch we can easily set "<*>_mod_base = win-
> >__res.start"
> 
> This patch adds a new field in "struct of_pci_range" to store the
> pci bus start address; it fills the field in
> of_pci_range_parser_one();
> in of_pci_get_host_bridge_resources() it retrieves the resource
> entry
> after it is created and added to the resource list and uses
> entry->__res.start to store the pci controller address
> 
> the patch is based on 4.2-rc1
> 
> Signed-off-by: Gabriele Paoloni 
> Acked-by: Liviu Dudau 
> ---
>  drivers/of/address.c   | 2 ++
>  drivers/of/of_pci.c| 4 
>  include/linux/of_address.h | 1 +
>  3 files changed, 7 insertions(+)
> 
> diff --git a/drivers/of/address.c b/drivers/of/address.c
> index 8bfda6a..23a5793 100644
> --- a/drivers/of/address.c
> +++ b/drivers/of/address.c
> @@ -253,6 +253,7 @@ struct of_pci_range *of_pci_range_parser_one(struct
> of_pci_range_parser *parser,
>   struct of_pci_range *range)
>  {
>   const int na = 3, ns = 2;
> + const int p_ns = of_n_size_cells(parser->node);
> 
>   if (!range)
>   return NULL;
> @@ -265,6 +266,7 @@ struct of_pci_range *of_pci_range_parser_one(struct
> of_pci_range_parser *parser,
>   range->pci_addr = of_read_number(parser->range + 1, ns);
>   range->cpu_addr = of_translate_address(parser->node,
>   parser->range + na);
> + range->bus_addr = of_read_number(parser->range + na, p_ns);
>   range->size = of_read_number(parser->range + parser->pna + na,
> ns);
> 
>   parser->range += parser->np;
> diff --git a/drivers/of/of_pci.c b/drivers/of/of_pci.c
> index 5751dc5..fe57030 100644
> --- a/drivers/of/of_pci.c
> +++ b/drivers/of/of_pci.c
> @@ -198,6 +198,7 @@ int of_pci_get_host_bridge_resources(struct
> device_node *dev,
> 
>   pr_debug("Parsing ranges property...\n");
>   for_each_of_pci_range(&parser, &range) {
> + struct resource_entry *entry;
>   /* Read next ranges element */
>   if ((range.flags & IORESOURCE_TYPE_BITS) == IORESOURCE_IO)
>   snprintf(range_type, 4, " IO");
> @@ -240,6 +241,9 @@ int of_pci_get_host_bridge_resources(struct
> device_node *dev,
>   }
> 
>   pci_add_resource_offset(resources, res, res->start -
> range.pci_addr);
> + entry = list_last_entry(resources, struct resource_entry,
> node);
> + /* we are using __res for storing the PCI controller
> address */
> + entry->__res.start = range.bus_addr;
>   }
> 
>   return 0;
> diff --git a/include/linux/of_address.h b/include/linux/of_address.h
> index d88e81b..865f96e 100644
> --- a/include/linux/of_address.h
> +++ b/include/linux/of_address.h
> @@ -16,6 +16,7 @@ struct of_pci_range {
>   u32 pci_space;
>   u64 pci_addr;
>   u64 cpu_addr;
> + u64 bus_addr;
>   u64 size;
>   u32 flags;
>  };
> --
> 1.9.1

[PATCH v5] PCI: Store PCIe bus address in struct of_pci_range

2015-07-27 Thread Gabriele Paoloni

From: gabriele paoloni 

This patch is needed port PCIe designware to new DT parsing API
As discussed in

http://lists.infradead.org/pipermail/linux-arm-kernel/2015-January/317743.html
in designware we have a problem as the PCI addresses in the PCIe controller
address space are required in order to perform correct HW operation.

In order to solve this problem commit f4c55c5a3 "PCI: designware:
Program ATU with untranslated address" added code to read the PCIe
controller start address directly from the DT ranges.

In the new DT parsing API of_pci_get_host_bridge_resources() hides the
DT parser from the host controller drivers, so it is not possible
for drivers to parse values directly from the DT.

In http://www.spinics.net/lists/linux-pci/msg42540.html we already tried
to use the new DT parsing API but there is a bug (obviously) in setting
the <*>_mod_base addresses
Applying this patch we can easily set "<*>_mod_base = win->__res.start"

This patch adds a new field in "struct of_pci_range" to store the
pci bus start address; it fills the field in of_pci_range_parser_one();
in of_pci_get_host_bridge_resources() it retrieves the resource entry
after it is created and added to the resource list and uses
entry->__res.start to store the pci controller address

the patch is based on 4.2-rc1

Signed-off-by: Gabriele Paoloni 
Acked-by: Liviu Dudai 
Acked-by: Rob Herring 
---
 drivers/of/address.c   | 2 ++
 drivers/of/of_pci.c| 4 
 include/linux/of_address.h | 1 +
 3 files changed, 7 insertions(+)

diff --git a/drivers/of/address.c b/drivers/of/address.c
index 8bfda6a..23a5793 100644
--- a/drivers/of/address.c
+++ b/drivers/of/address.c
@@ -253,6 +253,7 @@ struct of_pci_range *of_pci_range_parser_one(struct 
of_pci_range_parser *parser,
struct of_pci_range *range)
 {
const int na = 3, ns = 2;
+   const int p_ns = of_n_size_cells(parser->node);
 
if (!range)
return NULL;
@@ -265,6 +266,7 @@ struct of_pci_range *of_pci_range_parser_one(struct 
of_pci_range_parser *parser,
range->pci_addr = of_read_number(parser->range + 1, ns);
range->cpu_addr = of_translate_address(parser->node,
parser->range + na);
+   range->bus_addr = of_read_number(parser->range + na, p_ns);
range->size = of_read_number(parser->range + parser->pna + na, ns);
 
parser->range += parser->np;
diff --git a/drivers/of/of_pci.c b/drivers/of/of_pci.c
index 5751dc5..fe57030 100644
--- a/drivers/of/of_pci.c
+++ b/drivers/of/of_pci.c
@@ -198,6 +198,7 @@ int of_pci_get_host_bridge_resources(struct device_node 
*dev,
 
pr_debug("Parsing ranges property...\n");
for_each_of_pci_range(&parser, &range) {
+   struct resource_entry *entry;
/* Read next ranges element */
if ((range.flags & IORESOURCE_TYPE_BITS) == IORESOURCE_IO)
snprintf(range_type, 4, " IO");
@@ -240,6 +241,9 @@ int of_pci_get_host_bridge_resources(struct device_node 
*dev,
}
 
pci_add_resource_offset(resources, res, res->start - 
range.pci_addr);
+   entry = list_last_entry(resources, struct resource_entry, node);
+   /* we are using __res for storing the PCI controller address */
+   entry->__res.start = range.bus_addr;
}
 
return 0;
diff --git a/include/linux/of_address.h b/include/linux/of_address.h
index d88e81b..865f96e 100644
--- a/include/linux/of_address.h
+++ b/include/linux/of_address.h
@@ -16,6 +16,7 @@ struct of_pci_range {
u32 pci_space;
u64 pci_addr;
u64 cpu_addr;
+   u64 bus_addr;
u64 size;
u32 flags;
 };
-- 
1.9.1

--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v4] PCI: Store PCIe bus address in struct of_pci_range

2015-07-22 Thread Gabriele Paoloni

From: gabriele paoloni 

This patch is needed port PCIe designware to new DT parsing API
As discussed in

http://lists.infradead.org/pipermail/linux-arm-kernel/2015-January/317743.html
in designware we have a problem as the PCI addresses in the PCIe controller
address space are required in order to perform correct HW operation.

In order to solve this problem commit
f4c55c5a3 "PCI: designware: Program ATU with untranslated address"
added code to read the PCIe controller start address directly from the
DT ranges.

In the new DT parsing API of_pci_get_host_bridge_resources() hides the
DT parser from the host controller drivers, so it is not possible
for drivers to parse values directly from the DT.

In http://www.spinics.net/lists/linux-pci/msg42540.html we already tried
to use the new DT parsing API but there is a bug (obviously) in setting
the <*>_mod_base addresses
Applying this patch we can easily set "<*>_mod_base = win->__res.start"

This patch adds a new field in "struct of_pci_range" to store the
pci bus start address; it fills the field in of_pci_range_parser_one();
in of_pci_get_host_bridge_resources() it retrieves the resource entry
after it is created and added to the resource list and uses
entry->__res.start to store the pci controller address

the patch is based on 4.2-rc1

Signed-off-by: Gabriele Paoloni 
Acked-by: Liviu Dudau 
---
 drivers/of/address.c   | 2 ++
 drivers/of/of_pci.c| 4 
 include/linux/of_address.h | 1 +
 3 files changed, 7 insertions(+)

diff --git a/drivers/of/address.c b/drivers/of/address.c
index 8bfda6a..23a5793 100644
--- a/drivers/of/address.c
+++ b/drivers/of/address.c
@@ -253,6 +253,7 @@ struct of_pci_range *of_pci_range_parser_one(struct 
of_pci_range_parser *parser,
struct of_pci_range *range)
 {
const int na = 3, ns = 2;
+   const int p_ns = of_n_size_cells(parser->node);
 
if (!range)
return NULL;
@@ -265,6 +266,7 @@ struct of_pci_range *of_pci_range_parser_one(struct 
of_pci_range_parser *parser,
range->pci_addr = of_read_number(parser->range + 1, ns);
range->cpu_addr = of_translate_address(parser->node,
parser->range + na);
+   range->bus_addr = of_read_number(parser->range + na, p_ns);
range->size = of_read_number(parser->range + parser->pna + na, ns);
 
parser->range += parser->np;
diff --git a/drivers/of/of_pci.c b/drivers/of/of_pci.c
index 5751dc5..fe57030 100644
--- a/drivers/of/of_pci.c
+++ b/drivers/of/of_pci.c
@@ -198,6 +198,7 @@ int of_pci_get_host_bridge_resources(struct device_node 
*dev,
 
pr_debug("Parsing ranges property...\n");
for_each_of_pci_range(&parser, &range) {
+   struct resource_entry *entry;
/* Read next ranges element */
if ((range.flags & IORESOURCE_TYPE_BITS) == IORESOURCE_IO)
snprintf(range_type, 4, " IO");
@@ -240,6 +241,9 @@ int of_pci_get_host_bridge_resources(struct device_node 
*dev,
}
 
pci_add_resource_offset(resources, res, res->start - 
range.pci_addr);
+   entry = list_last_entry(resources, struct resource_entry, node);
+   /* we are using __res for storing the PCI controller address */
+   entry->__res.start = range.bus_addr;
}
 
return 0;
diff --git a/include/linux/of_address.h b/include/linux/of_address.h
index d88e81b..865f96e 100644
--- a/include/linux/of_address.h
+++ b/include/linux/of_address.h
@@ -16,6 +16,7 @@ struct of_pci_range {
u32 pci_space;
u64 pci_addr;
u64 cpu_addr;
+   u64 bus_addr;
u64 size;
u32 flags;
 };
-- 
1.9.1

--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

RE: [PATCH v3] PCI: Store PCIe bus address in struct of_pci_range

2015-07-22 Thread Gabriele Paoloni

> -Original Message-
> From: Gabriele Paoloni
> Sent: Wednesday, July 22, 2015 3:17 PM
> To: Gabriele Paoloni; a...@arndb.de; lorenzo.pieral...@arm.com;
> Wangzhou (B); bhelg...@google.com; robh...@kernel.org;
> james.mo...@arm.com; liviu.du...@arm.com
> Cc: linux-...@vger.kernel.org; linux-arm-ker...@lists.infradead.org;
> devicetree@vger.kernel.org; Yuanzhichang; Zhudacai; zhangjukuo;
> qiuzhenfa; Liguozhu (Kenneth)
> Subject: [PATCH v3] PCI: Store PCIe bus address in struct of_pci_range
> 
> From: gabriele paoloni 
> 
> This patch is needed port PCIe designware to new DT parsing API
> As discussed in
> http://lists.infradead.org/pipermail/linux-arm-kernel/2015-
> January/317743.html
> in designware we have a problem as the PCI addresses in the PCIe
> controller
> address space are required in order to perform correct HW operation.
> 
> In order to solve this problem commit
> f4c55c5a3 "PCI: designware: Program ATU with untranslated address"
> added code to read the PCIe controller start address directly from
> the
> DT ranges.
> 
> In the new DT parsing API of_pci_get_host_bridge_resources() hides
> the
> DT parser from the host controller drivers, so it is not possible
> for drivers to parse values directly from the DT.
> 
> In http://www.spinics.net/lists/linux-pci/msg42540.html we already
> tried
> to use the new DT parsing API but there is a bug (obviously) in
> setting
> the <*>_mod_base addresses
> Applying this patch we can easily set "<*>_mod_base = win-
> >__res.start"
> 
> This patch adds a new field in "struct of_pci_range" to store the
> pci bus start address; it fills the field in
> of_pci_range_parser_one();
> in of_pci_get_host_bridge_resources() it retrieves the resource
> entry
> after it is created and added to the resource list and uses
> entry->__res.start to store the pci controller address
> 
> the patch is based on 4.2-rc1
> 
> Signed-off-by: Gabriele Paoloni 
> Acked-by: Liviu Dudai 
Sorry, I just realized I've put a typo in Liviu's surname, I am going to send v4
> ---
>  drivers/of/address.c   | 2 ++
>  drivers/of/of_pci.c| 4 
>  include/linux/of_address.h | 1 +
>  3 files changed, 7 insertions(+)
> 
> diff --git a/drivers/of/address.c b/drivers/of/address.c
> index 8bfda6a..23a5793 100644
> --- a/drivers/of/address.c
> +++ b/drivers/of/address.c
> @@ -253,6 +253,7 @@ struct of_pci_range *of_pci_range_parser_one(struct
> of_pci_range_parser *parser,
>   struct of_pci_range *range)
>  {
>   const int na = 3, ns = 2;
> + const int p_ns = of_n_size_cells(parser->node);
> 
>   if (!range)
>   return NULL;
> @@ -265,6 +266,7 @@ struct of_pci_range *of_pci_range_parser_one(struct
> of_pci_range_parser *parser,
>   range->pci_addr = of_read_number(parser->range + 1, ns);
>   range->cpu_addr = of_translate_address(parser->node,
>   parser->range + na);
> + range->bus_addr = of_read_number(parser->range + na, p_ns);
>   range->size = of_read_number(parser->range + parser->pna + na,
> ns);
> 
>   parser->range += parser->np;
> diff --git a/drivers/of/of_pci.c b/drivers/of/of_pci.c
> index 5751dc5..fe57030 100644
> --- a/drivers/of/of_pci.c
> +++ b/drivers/of/of_pci.c
> @@ -198,6 +198,7 @@ int of_pci_get_host_bridge_resources(struct
> device_node *dev,
> 
>   pr_debug("Parsing ranges property...\n");
>   for_each_of_pci_range(&parser, &range) {
> + struct resource_entry *entry;
>   /* Read next ranges element */
>   if ((range.flags & IORESOURCE_TYPE_BITS) == IORESOURCE_IO)
>   snprintf(range_type, 4, " IO");
> @@ -240,6 +241,9 @@ int of_pci_get_host_bridge_resources(struct
> device_node *dev,
>   }
> 
>   pci_add_resource_offset(resources, res, res->start -
> range.pci_addr);
> + entry = list_last_entry(resources, struct resource_entry,
> node);
> + /* we are using __res for storing the PCI controller
> address */
> + entry->__res.start = range.bus_addr;
>   }
> 
>   return 0;
> diff --git a/include/linux/of_address.h b/include/linux/of_address.h
> index d88e81b..865f96e 100644
> --- a/include/linux/of_address.h
> +++ b/include/linux/of_address.h
> @@ -16,6 +16,7 @@ struct of_pci_range {
>   u32 pci_space;
>   u64 pci_addr;
>   u64 cpu_addr;
> + u64 bus_addr;
>   u64 size;
>   u32 flags;
>  };
> --
> 1.9.1

N�Р骒r��yb�X�肚�v�^�)藓{.n�+���z��z谵z)��骅w*jg�报�茛j/�赇z罐���2���ㄨ��&�)摺�a囤���G���h��j:+v���w��佶

[PATCH v3] PCI: Store PCIe bus address in struct of_pci_range

2015-07-22 Thread Gabriele Paoloni

From: gabriele paoloni 

This patch is needed port PCIe designware to new DT parsing API
As discussed in

http://lists.infradead.org/pipermail/linux-arm-kernel/2015-January/317743.html
in designware we have a problem as the PCI addresses in the PCIe controller
address space are required in order to perform correct HW operation.

In order to solve this problem commit
f4c55c5a3 "PCI: designware: Program ATU with untranslated address"
added code to read the PCIe controller start address directly from the
DT ranges.

In the new DT parsing API of_pci_get_host_bridge_resources() hides the
DT parser from the host controller drivers, so it is not possible
for drivers to parse values directly from the DT.

In http://www.spinics.net/lists/linux-pci/msg42540.html we already tried
to use the new DT parsing API but there is a bug (obviously) in setting
the <*>_mod_base addresses
Applying this patch we can easily set "<*>_mod_base = win->__res.start"

This patch adds a new field in "struct of_pci_range" to store the
pci bus start address; it fills the field in of_pci_range_parser_one();
in of_pci_get_host_bridge_resources() it retrieves the resource entry
after it is created and added to the resource list and uses
entry->__res.start to store the pci controller address

the patch is based on 4.2-rc1

Signed-off-by: Gabriele Paoloni 
Acked-by: Liviu Dudai 
---
 drivers/of/address.c   | 2 ++
 drivers/of/of_pci.c| 4 
 include/linux/of_address.h | 1 +
 3 files changed, 7 insertions(+)

diff --git a/drivers/of/address.c b/drivers/of/address.c
index 8bfda6a..23a5793 100644
--- a/drivers/of/address.c
+++ b/drivers/of/address.c
@@ -253,6 +253,7 @@ struct of_pci_range *of_pci_range_parser_one(struct 
of_pci_range_parser *parser,
struct of_pci_range *range)
 {
const int na = 3, ns = 2;
+   const int p_ns = of_n_size_cells(parser->node);
 
if (!range)
return NULL;
@@ -265,6 +266,7 @@ struct of_pci_range *of_pci_range_parser_one(struct 
of_pci_range_parser *parser,
range->pci_addr = of_read_number(parser->range + 1, ns);
range->cpu_addr = of_translate_address(parser->node,
parser->range + na);
+   range->bus_addr = of_read_number(parser->range + na, p_ns);
range->size = of_read_number(parser->range + parser->pna + na, ns);
 
parser->range += parser->np;
diff --git a/drivers/of/of_pci.c b/drivers/of/of_pci.c
index 5751dc5..fe57030 100644
--- a/drivers/of/of_pci.c
+++ b/drivers/of/of_pci.c
@@ -198,6 +198,7 @@ int of_pci_get_host_bridge_resources(struct device_node 
*dev,
 
pr_debug("Parsing ranges property...\n");
for_each_of_pci_range(&parser, &range) {
+   struct resource_entry *entry;
/* Read next ranges element */
if ((range.flags & IORESOURCE_TYPE_BITS) == IORESOURCE_IO)
snprintf(range_type, 4, " IO");
@@ -240,6 +241,9 @@ int of_pci_get_host_bridge_resources(struct device_node 
*dev,
}
 
pci_add_resource_offset(resources, res, res->start - 
range.pci_addr);
+   entry = list_last_entry(resources, struct resource_entry, node);
+   /* we are using __res for storing the PCI controller address */
+   entry->__res.start = range.bus_addr;
}
 
return 0;
diff --git a/include/linux/of_address.h b/include/linux/of_address.h
index d88e81b..865f96e 100644
--- a/include/linux/of_address.h
+++ b/include/linux/of_address.h
@@ -16,6 +16,7 @@ struct of_pci_range {
u32 pci_space;
u64 pci_addr;
u64 cpu_addr;
+   u64 bus_addr;
u64 size;
u32 flags;
 };
-- 
1.9.1

--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

RE: [PATCH v2] PCI: Store PCIe bus address in struct of_pci_range

2015-07-22 Thread Gabriele Paoloni

Many Thanks Liviu

I am going to send out v3 base on your suggestions

> -Original Message-
> From: linux-pci-ow...@vger.kernel.org [mailto:linux-pci-
> ow...@vger.kernel.org] On Behalf Of Liviu Dudau
> Sent: Wednesday, July 22, 2015 11:46 AM
> To: Gabriele Paoloni
> Cc: a...@arndb.de; Lorenzo Pieralisi; Wangzhou (B); bhelg...@google.com;
> robh...@kernel.org; James Morse; linux-...@vger.kernel.org; linux-arm-
> ker...@lists.infradead.org; devicetree@vger.kernel.org; Yuanzhichang;
> Zhudacai; zhangjukuo; qiuzhenfa; Liguozhu (Kenneth)
> Subject: Re: [PATCH v2] PCI: Store PCIe bus address in struct
> of_pci_range
> 
> Hi Gabriele,
> 
> On Tue, Jul 14, 2015 at 11:46:39AM +0100, Gabriele Paoloni wrote:
> > From: gabriele paoloni 
> >
> > This patch is needed port PCIe designware to new DT parsing API
> > As discussed in
> > http://lists.infradead.org/pipermail/linux-arm-kernel/2015-
> January/317743.html
> > in designware we have a problem as the PCI addresses in the PCIe
> controller
> > address space are required in order to perform correct HW
> operation.
> >
> > In order to solve this problem commit
> > f4c55c5a3 "PCI: designware: Program ATU with untranslated
> address"
> > added code to read the PCIe controller start address directly
> from the
> > DT ranges.
> >
> > In the new DT parsing API of_pci_get_host_bridge_resources()
> hides the
> > DT parser from the host controller drivers, so it is not possible
> > for drivers to parse values directly from the DT.
> >
> > In http://www.spinics.net/lists/linux-pci/msg42540.html we
> already tried
> > to use the new DT parsing API but there is a bug (obviously) in
> setting
> > the <*>_mod_base addresses
> > Applying this patch we can easily set "<*>_mod_base = win-
> >__res.start"
> >
> > This patch adds a new field in "struct of_pci_range" to store the
> > pci bus start address; it fills the field in
> of_pci_range_parser_one();
> > in of_pci_get_host_bridge_resources() it retrieves the resource
> entry
> > after it is created and added to the resource list and uses
> > entry->__res.start to store the pci controller address
> >
> > the patch is based on 4.2-rc1
> >
> > Signed-off-by: Gabriele Paoloni 
> > ---
> >  drivers/of/address.c   | 2 ++
> >  drivers/of/of_pci.c| 4 
> >  include/linux/of_address.h | 1 +
> >  3 files changed, 7 insertions(+)
> >
> > diff --git a/drivers/of/address.c b/drivers/of/address.c
> > index 8bfda6a..23a5793 100644
> > --- a/drivers/of/address.c
> > +++ b/drivers/of/address.c
> > @@ -253,6 +253,7 @@ struct of_pci_range
> *of_pci_range_parser_one(struct of_pci_range_parser *parser,
> > struct of_pci_range *range)
> >  {
> > const int na = 3, ns = 2;
> > +   const int p_ns = of_n_size_cells(parser->node);
> >
> > if (!range)
> > return NULL;
> > @@ -265,6 +266,7 @@ struct of_pci_range
> *of_pci_range_parser_one(struct of_pci_range_parser *parser,
> > range->pci_addr = of_read_number(parser->range + 1, ns);
> > range->cpu_addr = of_translate_address(parser->node,
> > parser->range + na);
> > +   range->bus_addr = of_read_number(parser->range + na, p_ns);
> > range->size = of_read_number(parser->range + parser->pna + na,
> ns);
> >
> > parser->range += parser->np;
> > diff --git a/drivers/of/of_pci.c b/drivers/of/of_pci.c
> > index 5751dc5..b171d02 100644
> > --- a/drivers/of/of_pci.c
> > +++ b/drivers/of/of_pci.c
> > @@ -198,6 +198,7 @@ int of_pci_get_host_bridge_resources(struct
> device_node *dev,
> >
> > pr_debug("Parsing ranges property...\n");
> > for_each_of_pci_range(&parser, &range) {
> > +   struct resource_entry *entry;
> > /* Read next ranges element */
> > if ((range.flags & IORESOURCE_TYPE_BITS) == IORESOURCE_IO)
> > snprintf(range_type, 4, " IO");
> > @@ -240,6 +241,9 @@ int of_pci_get_host_bridge_resources(struct
> device_node *dev,
> > }
> >
> > pci_add_resource_offset(resources, res, res->start -
> range.pci_addr);
> > +   entry = list_last_entry(resources, struct resource_entry,
> node);
> > +   /*we are using __res for storing the PCI c

RE: [PATCH v2] PCI: Store PCIe bus address in struct of_pci_range

2015-07-22 Thread Gabriele Paoloni

Any comment on this patch?

This is needed by "[PATCH v4 2/5] PCI: designware: Add ARM64 support"

Thanks

Gab

> -Original Message-
> From: Gabriele Paoloni
> Sent: Tuesday, July 14, 2015 11:47 AM
> To: Gabriele Paoloni; a...@arndb.de; lorenzo.pieral...@arm.com;
> Wangzhou (B); bhelg...@google.com; robh...@kernel.org;
> james.mo...@arm.com; liviu.du...@arm.com
> Cc: linux-...@vger.kernel.org; linux-arm-ker...@lists.infradead.org;
> devicetree@vger.kernel.org; Yuanzhichang; Zhudacai; zhangjukuo;
> qiuzhenfa; Liguozhu (Kenneth)
> Subject: [PATCH v2] PCI: Store PCIe bus address in struct of_pci_range
> 
> From: gabriele paoloni 
> 
> This patch is needed port PCIe designware to new DT parsing API
> As discussed in
> http://lists.infradead.org/pipermail/linux-arm-kernel/2015-
> January/317743.html
> in designware we have a problem as the PCI addresses in the PCIe
> controller
> address space are required in order to perform correct HW operation.
> 
> In order to solve this problem commit
> f4c55c5a3 "PCI: designware: Program ATU with untranslated address"
> added code to read the PCIe controller start address directly from
> the
> DT ranges.
> 
> In the new DT parsing API of_pci_get_host_bridge_resources() hides
> the
> DT parser from the host controller drivers, so it is not possible
> for drivers to parse values directly from the DT.
> 
> In http://www.spinics.net/lists/linux-pci/msg42540.html we already
> tried
> to use the new DT parsing API but there is a bug (obviously) in
> setting
> the <*>_mod_base addresses
> Applying this patch we can easily set "<*>_mod_base = win-
> >__res.start"
> 
> This patch adds a new field in "struct of_pci_range" to store the
> pci bus start address; it fills the field in
> of_pci_range_parser_one();
> in of_pci_get_host_bridge_resources() it retrieves the resource
> entry
> after it is created and added to the resource list and uses
> entry->__res.start to store the pci controller address
> 
> the patch is based on 4.2-rc1
> 
> Signed-off-by: Gabriele Paoloni 
> ---
>  drivers/of/address.c   | 2 ++
>  drivers/of/of_pci.c| 4 
>  include/linux/of_address.h | 1 +
>  3 files changed, 7 insertions(+)
> 
> diff --git a/drivers/of/address.c b/drivers/of/address.c
> index 8bfda6a..23a5793 100644
> --- a/drivers/of/address.c
> +++ b/drivers/of/address.c
> @@ -253,6 +253,7 @@ struct of_pci_range *of_pci_range_parser_one(struct
> of_pci_range_parser *parser,
>   struct of_pci_range *range)
>  {
>   const int na = 3, ns = 2;
> + const int p_ns = of_n_size_cells(parser->node);
> 
>   if (!range)
>   return NULL;
> @@ -265,6 +266,7 @@ struct of_pci_range *of_pci_range_parser_one(struct
> of_pci_range_parser *parser,
>   range->pci_addr = of_read_number(parser->range + 1, ns);
>   range->cpu_addr = of_translate_address(parser->node,
>   parser->range + na);
> + range->bus_addr = of_read_number(parser->range + na, p_ns);
>   range->size = of_read_number(parser->range + parser->pna + na,
> ns);
> 
>   parser->range += parser->np;
> diff --git a/drivers/of/of_pci.c b/drivers/of/of_pci.c
> index 5751dc5..b171d02 100644
> --- a/drivers/of/of_pci.c
> +++ b/drivers/of/of_pci.c
> @@ -198,6 +198,7 @@ int of_pci_get_host_bridge_resources(struct
> device_node *dev,
> 
>   pr_debug("Parsing ranges property...\n");
>   for_each_of_pci_range(&parser, &range) {
> + struct resource_entry *entry;
>   /* Read next ranges element */
>   if ((range.flags & IORESOURCE_TYPE_BITS) == IORESOURCE_IO)
>   snprintf(range_type, 4, " IO");
> @@ -240,6 +241,9 @@ int of_pci_get_host_bridge_resources(struct
> device_node *dev,
>   }
> 
>   pci_add_resource_offset(resources, res, res->start -
> range.pci_addr);
> + entry = list_last_entry(resources, struct resource_entry,
> node);
> + /*we are using __res for storing the PCI controller
> address*/
> + entry->__res.start = range.bus_addr;
>   }
> 
>   return 0;
> diff --git a/include/linux/of_address.h b/include/linux/of_address.h
> index d88e81b..865f96e 100644
> --- a/include/linux/of_address.h
> +++ b/include/linux/of_address.h
> @@ -16,6 +16,7 @@ struct of_pci_range {
>   u32 pci_space;
>   u64 pci_addr;
>   u64 cpu_addr;
> + u64 bus_addr;
>   u64 size;
>   u32 flags;
>  };
> --
> 1.9.1

RE: [PATCH v2 2/4] PCI: designware: Add ARM64 support

2015-07-17 Thread Gabriele Paoloni

> -Original Message-
> From: Lorenzo Pieralisi [mailto:lorenzo.pieral...@arm.com]
> Sent: Monday, July 13, 2015 3:18 PM
> To: Wangzhou (B)
> Cc: Gabriele Paoloni; James Morse; Bjorn Helgaas; Jingoo Han; Pratyush
> Anand; Arnd Bergmann; fabrice.gasn...@st.com; Liviu Dudau; linux-
> p...@vger.kernel.org; linux-arm-ker...@lists.infradead.org;
> devicetree@vger.kernel.org; Yuanzhichang; Zhudacai; zhangjukuo;
> qiuzhenfa; Liguozhu (Kenneth)
> Subject: Re: [PATCH v2 2/4] PCI: designware: Add ARM64 support
> 
> On Mon, Jul 13, 2015 at 12:45:52PM +0100, Zhou Wang wrote:
> > On 2015/7/13 18:58, Lorenzo Pieralisi wrote:
> > > On Tue, Jun 16, 2015 at 03:14:21PM +0100, Gabriele Paoloni wrote:
> > >
> > > [...]
> > >
> > >>>> +   bus = pci_create_root_bus(pp->dev, pp->root_bus_nr,
> &dw_pcie_ops,
> > >>>> + pp, &res);
> > >
> > > I think you can't do that on ARM 32-bit platforms. They rely on
> pci_sys_data
> > > in pcibios_msi_controller and pcibios_align_resource, if you do not
> > > pass a pci_sys_data struct in the sysdata pointer this can't work
> and
> > > unless you get lucky it will explode.
> > >
> > > We have to remove pci_sys_data dependency on ARM, then this
> approach
> > > will work.
> > >
> > > Thanks,
> > > Lorenzo
> > >
> >
> > Hi Lorenzo,
> >
> > For pcibios_align_resource, 1/4 can be used to solve this problem.
> > For pcibios_msi_controller, bus->msi can be set in pcie-designware,
> then
> > we can get msi controller by dev->bus->msi in pci_msi_controller.
> 
> Yes, 1/4 solves the problem I know, but that's a bit hackish, it would
> be better if we can create the host bridge and pass it to
> create_root_bus, that's what Yijing was doing but I am not sure
> if that's still the plan given his latest series here.
> 
> https://patchwork.ozlabs.org/project/linux-pci/list/?submitter=15928

I have submitted a new patch for this:
http://lists.infradead.org/pipermail/linux-arm-kernel/2015-July/357431.html

> 
> I've just posted a patch for pcibios_msi_controller removal, I did
> not notice that it was something already put forward by Arnd, anyway
> those are the last two steps required, let's get them merged.
> 
> https://patchwork.ozlabs.org/patch/494498/
> 
> Lorenzo
> 
> > And the latest series is v3 version
> > "[PATCH v3 0/5] PCI: hisi: Add PCIe host support for Hisilicon Soc
> Hip05"
> >
> > Best regards,
> > Zhou
> >
> > >>>> +   if (!bus)
> > >>>> +   return -ENOMEM;
> > >>>> +
> > >>>> +#ifdef CONFIG_GENERIC_MSI_IRQ_DOMAIN
> > >>>> +   bus->msi = container_of(&pp->irq_domain, struct
> msi_controller,
> > >>> domain);
> > >>>> +#else
> > >>>> +   bus->msi = &dw_pcie_msi_chip;
> > >>>>  #endif
> > >>>>
> > >>>> -   dw_pci.nr_controllers = 1;
> > >>>> -   dw_pci.private_data = (void **)&pp;
> > >>>> +   pci_scan_child_bus(bus);
> > >>>> +   if (pp->ops->scan_bus)
> > >>>> +   pp->ops->scan_bus(pp);
> > >>>>
> > >>>> -   pci_common_init_dev(pp->dev, &dw_pci);
> > >>>> +#ifdef CONFIG_ARM
> > >>>> +   /* support old dtbs that incorrectly describe IRQs */
> > >>>> +   pci_fixup_irqs(pci_common_swizzle, of_irq_parse_and_map_pci);
> > >>>> +#endif
> > >>>> +
> > >>>> +   pci_assign_unassigned_bus_resources(bus);
> > >>>> +   pci_bus_add_devices(bus);
> > >>>>
> > >>>> return 0;
> > >>>>  }
> > >>>> @@ -653,7 +665,7 @@ static int dw_pcie_valid_config(struct
> pcie_port
> > >>> *pp,
> > >>>>  static int dw_pcie_rd_conf(struct pci_bus *bus, u32 devfn, int
> where,
> > >>>> int size, u32 *val)
> > >>>>  {
> > >>>> -   struct pcie_port *pp = sys_to_pcie(bus->sysdata);
> > >>>> +   struct pcie_port *pp = bus->sysdata;
> > >>>> int ret;
> > >>>>
> > >>>> if (dw_pcie_valid_config(pp, bus, PCI_SLOT(devfn)) == 0) {
> > >>>> @@ -677,7 +689,7 @@ static int dw_pcie_rd_conf(struct pci_bus
> *bus,

RE: [PATCH v3 1/5] ARM/PCI: remove align_resource callback in pcibios_align_resource

2015-07-17 Thread Gabriele Paoloni

The following patch is maybe a better solution

Gab

---
This patch is needed in order to unify the PCIe designware
framework for ARM and ARM64 architectures.
In the PCIe designware unification process we are calling
pci_create_root_bus() passing a "sysdata" parameter
that is the same for both ARM and ARM64 and is of type
"struct pcie_port*". In the ARM case this will cause
a problem with the function pcibios_align_resource();
in fact this will cast "dev->sysdata" to "struct pci_sys_data*",
whereas designware had passed a "struct pcie_port*" pointer.

This patch solves the issue by removing "align_resource" from
"pci_sys_data" struct and defining a static global function pointer
in "bios32.c"

Signed-off-by: Gabriele Paoloni 
---
 arch/arm/include/asm/mach/pci.h |  5 -
 arch/arm/kernel/bios32.c| 12 
 2 files changed, 8 insertions(+), 9 deletions(-)

diff --git a/arch/arm/include/asm/mach/pci.h b/arch/arm/include/asm/mach/pci.h
index 28b9bb3..8a4e4de 100644
--- a/arch/arm/include/asm/mach/pci.h
+++ b/arch/arm/include/asm/mach/pci.h
@@ -58,11 +58,6 @@ struct pci_sys_data {
/* IRQ mapping  
*/
int (*map_irq)(const struct pci_dev *, u8, u8);
/* Resource alignement requirements 
*/
-   resource_size_t (*align_resource)(struct pci_dev *dev,
- const struct resource *res,
- resource_size_t start,
- resource_size_t size,
- resource_size_t align);
void*private_data;  /* platform controller private data 
*/
 };
 
diff --git a/arch/arm/kernel/bios32.c b/arch/arm/kernel/bios32.c
index fc1..4cdc64d 100644
--- a/arch/arm/kernel/bios32.c
+++ b/arch/arm/kernel/bios32.c
@@ -17,6 +17,11 @@
 #include 
 
 static int debug_pci;
+static resource_size_t (*align_resource)(struct pci_dev *dev,
+ const struct resource *res,
+ resource_size_t start,
+ resource_size_t size,
+ resource_size_t align) = NULL;
 
 #ifdef CONFIG_PCI_MSI
 struct msi_controller *pcibios_msi_controller(struct pci_dev *dev)
@@ -468,7 +473,7 @@ static void pcibios_init_hw(struct device *parent, struct 
hw_pci *hw,
sys->busnr   = busnr;
sys->swizzle = hw->swizzle;
sys->map_irq = hw->map_irq;
-   sys->align_resource = hw->align_resource;
+   align_resource = hw->align_resource;
INIT_LIST_HEAD(&sys->resources);
 
if (hw->private_data)
@@ -589,7 +594,6 @@ resource_size_t pcibios_align_resource(void *data, const 
struct resource *res,
resource_size_t size, resource_size_t align)
 {
struct pci_dev *dev = data;
-   struct pci_sys_data *sys = dev->sysdata;
resource_size_t start = res->start;
 
if (res->flags & IORESOURCE_IO && start & 0x300)
@@ -597,8 +601,8 @@ resource_size_t pcibios_align_resource(void *data, const 
struct resource *res,
 
start = (start + align - 1) & ~(align - 1);
 
-   if (sys->align_resource)
-   return sys->align_resource(dev, res, start, size, align);
+   if (align_resource)
+   return align_resource(dev, res, start, size, align);
 
return start;
 }
-- 
1.9.1

> -Original Message-
> From: linux-pci-ow...@vger.kernel.org [mailto:linux-pci-
> ow...@vger.kernel.org] On Behalf Of Liviu Dudau
> Sent: Tuesday, July 07, 2015 10:22 AM
> To: Wangzhou (B)
> Cc: Bjorn Helgaas; Jingoo Han; Pratyush Anand; Arnd Bergmann; Gabriele
> Paoloni; James Morse; linux-...@vger.kernel.org; linux-arm-
> ker...@lists.infradead.org; devicetree@vger.kernel.org; Yuanzhichang;
> Zhudacai; zhangjukuo; qiuzhenfa; Liguozhu (Kenneth)
> Subject: Re: [PATCH v3 1/5] ARM/PCI: remove align_resource callback in
> pcibios_align_resource
> 
> On Tue, Jul 07, 2015 at 06:44:01AM +0100, Zhou Wang wrote:
> > On 2015/7/3 1:50, Liviu Dudau wrote:
> > > On Wed, Jul 01, 2015 at 10:43:33AM +0100, Zhou Wang wrote:
> > >> This patch had added by Arnd Bergmann during last reviewing of v1
> patchset[1].
> > >>
> > >> PCI core codes call pcibios_align_resource(). In ARM specific one,
> it will
> > >> dereference pci_sys_data and call sys->align_resource. If we try
> to unify ARM
> > >> and ARM64 PCIe API in pcie-designware. it will bring kernel crash
> when run into
> > >> this dereferencing.
> > >>
> > >> However, in ARM there is only pci-mvebu whic

[PATCH v2] PCI: Store PCIe bus address in struct of_pci_range

2015-07-14 Thread Gabriele Paoloni

From: gabriele paoloni 

This patch is needed port PCIe designware to new DT parsing API
As discussed in

http://lists.infradead.org/pipermail/linux-arm-kernel/2015-January/317743.html
in designware we have a problem as the PCI addresses in the PCIe controller
address space are required in order to perform correct HW operation.

In order to solve this problem commit
f4c55c5a3 "PCI: designware: Program ATU with untranslated address"
added code to read the PCIe controller start address directly from the
DT ranges.

In the new DT parsing API of_pci_get_host_bridge_resources() hides the
DT parser from the host controller drivers, so it is not possible
for drivers to parse values directly from the DT.

In http://www.spinics.net/lists/linux-pci/msg42540.html we already tried
to use the new DT parsing API but there is a bug (obviously) in setting
the <*>_mod_base addresses
Applying this patch we can easily set "<*>_mod_base = win->__res.start"

This patch adds a new field in "struct of_pci_range" to store the
pci bus start address; it fills the field in of_pci_range_parser_one();
in of_pci_get_host_bridge_resources() it retrieves the resource entry
after it is created and added to the resource list and uses
entry->__res.start to store the pci controller address

the patch is based on 4.2-rc1

Signed-off-by: Gabriele Paoloni 
---
 drivers/of/address.c   | 2 ++
 drivers/of/of_pci.c| 4 
 include/linux/of_address.h | 1 +
 3 files changed, 7 insertions(+)

diff --git a/drivers/of/address.c b/drivers/of/address.c
index 8bfda6a..23a5793 100644
--- a/drivers/of/address.c
+++ b/drivers/of/address.c
@@ -253,6 +253,7 @@ struct of_pci_range *of_pci_range_parser_one(struct 
of_pci_range_parser *parser,
struct of_pci_range *range)
 {
const int na = 3, ns = 2;
+   const int p_ns = of_n_size_cells(parser->node);
 
if (!range)
return NULL;
@@ -265,6 +266,7 @@ struct of_pci_range *of_pci_range_parser_one(struct 
of_pci_range_parser *parser,
range->pci_addr = of_read_number(parser->range + 1, ns);
range->cpu_addr = of_translate_address(parser->node,
parser->range + na);
+   range->bus_addr = of_read_number(parser->range + na, p_ns);
range->size = of_read_number(parser->range + parser->pna + na, ns);
 
parser->range += parser->np;
diff --git a/drivers/of/of_pci.c b/drivers/of/of_pci.c
index 5751dc5..b171d02 100644
--- a/drivers/of/of_pci.c
+++ b/drivers/of/of_pci.c
@@ -198,6 +198,7 @@ int of_pci_get_host_bridge_resources(struct device_node 
*dev,
 
pr_debug("Parsing ranges property...\n");
for_each_of_pci_range(&parser, &range) {
+   struct resource_entry *entry;
/* Read next ranges element */
if ((range.flags & IORESOURCE_TYPE_BITS) == IORESOURCE_IO)
snprintf(range_type, 4, " IO");
@@ -240,6 +241,9 @@ int of_pci_get_host_bridge_resources(struct device_node 
*dev,
}
 
pci_add_resource_offset(resources, res, res->start - 
range.pci_addr);
+   entry = list_last_entry(resources, struct resource_entry, node);
+   /*we are using __res for storing the PCI controller address*/
+   entry->__res.start = range.bus_addr;
}
 
return 0;
diff --git a/include/linux/of_address.h b/include/linux/of_address.h
index d88e81b..865f96e 100644
--- a/include/linux/of_address.h
+++ b/include/linux/of_address.h
@@ -16,6 +16,7 @@ struct of_pci_range {
u32 pci_space;
u64 pci_addr;
u64 cpu_addr;
+   u64 bus_addr;
u64 size;
u32 flags;
 };
-- 
1.9.1

--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

RE: [PATCH] Store PCIe controllers address in struct of_pci_range

2015-07-13 Thread Gabriele Paoloni

Sorry I just realized I forgot to reply to the last item

Gab

> -Original Message-
> From: Gabriele Paoloni
> Sent: Monday, July 13, 2015 12:07 PM
> To: 'Rob Herring'
> Cc: Arnd Bergmann; Lorenzo Pieralisi; Wangzhou (B); Bjorn Helgaas; Rob
> Herring; james.mo...@arm.com; Liviu Dudau; linux-...@vger.kernel.org;
> linux-arm-ker...@lists.infradead.org; devicetree@vger.kernel.org;
> Yuanzhichang; Zhudacai; zhangjukuo; qiuzhenfa; Liguozhu (Kenneth)
> Subject: RE: [PATCH] Store PCIe controllers address in struct
> of_pci_range
> 
> Hi Rob
> 
> Many Thanks for your review
> 
> > -Original Message-
> > From: Rob Herring [mailto:robherri...@gmail.com]
> > Sent: Friday, July 10, 2015 8:56 PM
> > To: Gabriele Paoloni
> > Cc: Arnd Bergmann; Lorenzo Pieralisi; Wangzhou (B); Bjorn Helgaas;
> Rob
> > Herring; james.mo...@arm.com; Liviu Dudau; linux-...@vger.kernel.org;
> > linux-arm-ker...@lists.infradead.org; devicetree@vger.kernel.org;
> > Yuanzhichang; Zhudacai; zhangjukuo; qiuzhenfa; Liguozhu (Kenneth)
> > Subject: Re: [PATCH] Store PCIe controllers address in struct
> > of_pci_range
> >
> > On Fri, Jul 10, 2015 at 3:48 AM, Gabriele Paoloni
> >  wrote:
> > > From: gabriele paoloni 
> > >
> > > This patch is needed port PCIe designware to new DT parsing API
> > > As discussed in
> > > http://lists.infradead.org/pipermail/linux-arm-kernel/2015-
> > January/317743.html
> > > in designware we have a problem as the PCI addresses in the PCIe
> > controller
> > > address space are required in order to perform correct HW operation.
> > >
> > > In order to solve this problem commit
> > > f4c55c5a3f7f68c06cc559ed7af8b2d017cbb0a7 "PCI: designware:
> >
> > Please abbreviate hashs to 12 characters.
> 
> Sure, will do.
> 
> >
> > > Program ATU with untranslated address" added code to read the PCIe
> > > controller start address directly from the DT ranges.
> > >
> > > In the new DT parsing API of_pci_get_host_bridge_resources() hides
> > the
> > > DT parser from the host controller drivers, so it is not possible
> > > for drivers to parse values directly from the DT.
> > >
> > > In http://www.spinics.net/lists/linux-pci/msg42540.html we already
> > tried
> > > to use the new DT parsing API but there is a bug (obviously) in
> > setting
> > > the <*>_mod_base addresses
> > > Applying this patch we can easily set "<*>_mod_base = win-
> > >__res.start"
> > >
> > > This patch adds a new field in "struct of_pci_range" to store the
> > > pci controller start address; it fills the field in
> > of_pci_range_parser_one();
> > > in of_pci_get_host_bridge_resources() it retrieve the resource
> entry
> > > after it is created and added to the resource list and uses
> > > entry->__res.start to store the pci controller address
> > >
> > > the patch is based on 4.2-rc1
> > >
> > > Signed-off-by: Gabriele Paoloni 
> > > ---
> > >  drivers/of/address.c   | 1 +
> > >  drivers/of/of_pci.c| 4 
> > >  drivers/pci/host/pcie-designware.c | 9 +++--
> > >  include/linux/of_address.h | 1 +
> > >  4 files changed, 9 insertions(+), 6 deletions(-)
> > >
> > > diff --git a/drivers/of/address.c b/drivers/of/address.c
> > > index 8bfda6a..52f9321 100644
> > > --- a/drivers/of/address.c
> > > +++ b/drivers/of/address.c
> > > @@ -265,6 +265,7 @@ struct of_pci_range
> > *of_pci_range_parser_one(struct of_pci_range_parser *parser,
> > > range->pci_addr = of_read_number(parser->range + 1, ns);
> > > range->cpu_addr = of_translate_address(parser->node,
> > > parser->range + na);
> > > +   range->pci_ctrl_addr = of_read_number(parser->range + na,
> ns) ;
> >
> > This is wrong as the correct size to read is not "ns", but the parent
> > bus #size-cells value.
> 
> Ok I will replace "ns" with "of_n_size_cells(parser->node)"
> 
> >
> > I think "bus_addr" would be a better name. It is not the PCI
> > controller's address (i.e. what is in reg prop). No "pci" because it
> > has nothing to do with PCI bus addresses.
> 
> Ok I will change the name
> 
> >
> > In general, this seems fragile as the dt address ranges/translation

RE: [PATCH] Store PCIe controllers address in struct of_pci_range

2015-07-13 Thread Gabriele Paoloni

Hi Rob

Many Thanks for your review

> -Original Message-
> From: Rob Herring [mailto:robherri...@gmail.com]
> Sent: Friday, July 10, 2015 8:56 PM
> To: Gabriele Paoloni
> Cc: Arnd Bergmann; Lorenzo Pieralisi; Wangzhou (B); Bjorn Helgaas; Rob
> Herring; james.mo...@arm.com; Liviu Dudau; linux-...@vger.kernel.org;
> linux-arm-ker...@lists.infradead.org; devicetree@vger.kernel.org;
> Yuanzhichang; Zhudacai; zhangjukuo; qiuzhenfa; Liguozhu (Kenneth)
> Subject: Re: [PATCH] Store PCIe controllers address in struct
> of_pci_range
> 
> On Fri, Jul 10, 2015 at 3:48 AM, Gabriele Paoloni
>  wrote:
> > From: gabriele paoloni 
> >
> > This patch is needed port PCIe designware to new DT parsing API
> > As discussed in
> > http://lists.infradead.org/pipermail/linux-arm-kernel/2015-
> January/317743.html
> > in designware we have a problem as the PCI addresses in the PCIe
> controller
> > address space are required in order to perform correct HW operation.
> >
> > In order to solve this problem commit
> > f4c55c5a3f7f68c06cc559ed7af8b2d017cbb0a7 "PCI: designware:
> 
> Please abbreviate hashs to 12 characters.

Sure, will do.

> 
> > Program ATU with untranslated address" added code to read the PCIe
> > controller start address directly from the DT ranges.
> >
> > In the new DT parsing API of_pci_get_host_bridge_resources() hides
> the
> > DT parser from the host controller drivers, so it is not possible
> > for drivers to parse values directly from the DT.
> >
> > In http://www.spinics.net/lists/linux-pci/msg42540.html we already
> tried
> > to use the new DT parsing API but there is a bug (obviously) in
> setting
> > the <*>_mod_base addresses
> > Applying this patch we can easily set "<*>_mod_base = win-
> >__res.start"
> >
> > This patch adds a new field in "struct of_pci_range" to store the
> > pci controller start address; it fills the field in
> of_pci_range_parser_one();
> > in of_pci_get_host_bridge_resources() it retrieve the resource entry
> > after it is created and added to the resource list and uses
> > entry->__res.start to store the pci controller address
> >
> > the patch is based on 4.2-rc1
> >
> > Signed-off-by: Gabriele Paoloni 
> > ---
> >  drivers/of/address.c   | 1 +
> >  drivers/of/of_pci.c| 4 
> >  drivers/pci/host/pcie-designware.c | 9 +++--
> >  include/linux/of_address.h | 1 +
> >  4 files changed, 9 insertions(+), 6 deletions(-)
> >
> > diff --git a/drivers/of/address.c b/drivers/of/address.c
> > index 8bfda6a..52f9321 100644
> > --- a/drivers/of/address.c
> > +++ b/drivers/of/address.c
> > @@ -265,6 +265,7 @@ struct of_pci_range
> *of_pci_range_parser_one(struct of_pci_range_parser *parser,
> > range->pci_addr = of_read_number(parser->range + 1, ns);
> > range->cpu_addr = of_translate_address(parser->node,
> > parser->range + na);
> > +   range->pci_ctrl_addr = of_read_number(parser->range + na, ns) ;
> 
> This is wrong as the correct size to read is not "ns", but the parent
> bus #size-cells value.

Ok I will replace "ns" with "of_n_size_cells(parser->node)" 

> 
> I think "bus_addr" would be a better name. It is not the PCI
> controller's address (i.e. what is in reg prop). No "pci" because it
> has nothing to do with PCI bus addresses.

Ok I will change the name 

> 
> In general, this seems fragile as the dt address ranges/translation
> may not align with the h/w ranges. For example, what if you have 2
> levels of translations and you happen to need it translated with just
> 1 level of translation. That said, I don't really have a better
> suggestion and I guess we can deal with that case if needed later.

Ok so, we'll leave it like this for now

> 
> > range->size = of_read_number(parser->range + parser->pna + na,
> ns);
> >
> > parser->range += parser->np;
> > diff --git a/drivers/of/of_pci.c b/drivers/of/of_pci.c
> > index 5751dc5..2ccc749 100644
> > --- a/drivers/of/of_pci.c
> > +++ b/drivers/of/of_pci.c
> > @@ -198,6 +198,7 @@ int of_pci_get_host_bridge_resources(struct
> device_node *dev,
> >
> > pr_debug("Parsing ranges property...\n");
> > for_each_of_pci_range(&parser, &range) {
> > +   struct resource_entry *entry;
> > /* Read next ranges element */
> > if (

RE: [PATCH v3 2/5] PCI: designware: Add ARM64 support

2015-07-10 Thread Gabriele Paoloni

I have just sent this patch "[PATCH] Store PCIe controllers address in struct 
of_pci_range".

It would be needed by "pcie_designware.c" to retrieve the PCI controller 
addresses from "win->__res.start".

So we do not need to retrieve info from the DT parser anymore and we can use 
the new PCI DT parsing API

This problem was already discussed in this thread:
http://lists.infradead.org/pipermail/linux-arm-kernel/2015-January/317743.html


> -Original Message-
> From: Wangzhou (B)
> Sent: Tuesday, July 07, 2015 4:44 AM
> To: James Morse
> Cc: Gabriele Paoloni; Bjorn Helgaas; Jingoo Han; Pratyush Anand; Arnd
> Bergmann; Liviu Dudau; kis...@ti.com; x...@kosagi.com; m-
> kariche...@ti.com; minghuan.l...@freescale.com; linux-
> p...@vger.kernel.org; linux-arm-ker...@lists.infradead.org;
> devicetree@vger.kernel.org; Yuanzhichang; Zhudacai; zhangjukuo;
> qiuzhenfa; Liguozhu (Kenneth)
> Subject: Re: [PATCH v3 2/5] PCI: designware: Add ARM64 support
> 
> On 2015/7/1 22:26, James Morse wrote:
> > Zhou Wang wrote:
> >> I tested this patch on D02 board of Hisilicon. It works well.
> >> I have compiled the driver with multi_v7_defconfig. However, I don't
> >> have
> >> ARM32 PCIe related board to do test. It will be appreciated if
> someone
> >> could
> >> help to test it.
> >>
> >> Signed-off-by: Zhou Wang 
> >> Signed-off-by: Arnd Bergmann 
> >> Signed-off-by: Gabriele Paoloni 
> >> Tested-by: Fabrice Gasnier 
> >> Tested-by: James Morse 
> >
> > Tests on this new series, using the same i.MX 6Quad board, are not
> working.
> >
> > The network card is no longer detected, and I get a lockup when
> removing
> > the root bridge and rescanning.
> >
> > Partial dmesg output below. Significantly, the lines:
> >> [0.152128] PCI host bridge /soc/pcie@0x0100 ranges:
> >> [0.152142]   No bus range found for /soc/pcie@0x0100, using
> [bus
> > 00-ff]
> > are new.
> >
> > Both series are applied to v4.1, use the same .config file, and the
> same dtb.
> > I will investigate further.
> >
> > (Re-testing v2 works, so this isn't an interim hardware failure)
> >
> > Thanks,
> >
> > James
> >
> 
> Hi James,
> 
> There are something wrong with v3 patch.
> 
> pp->io_mod_base = of_read_number(parser_range_end -
>   of_n_addr_cells(np) - 5 + na, ns);
> pp->mem_mod_base = of_read_number(parser_range_end -
>   of_n_addr_cells(np) - 5 + na, ns);
> pp->cfg0_mod_base = of_read_number(parser_range_end -
>   of_n_addr_cells(np) - 5 + na, ns);
> are wrong.
> 
> The ranges item in your dts is:
> ranges = <0x800 0x0 0x1f0 0x1f0 0x0 0x8
> 0x8100 0x0 0x0  0x1f8 0x0 0x1
> 0x8200 0x0 0x100 0x100 0x0 0xf0>;
> parser_range_end points to the end of ranges(0xf0) directly. In v2
> patch,
> of_read_number is of_read_number(parser.range - parser.np + na, ns);
> parser.range
> points to the end of each line in ranges item.
> 
> When I did test on D02 board with intel82599 card, I set ranges item as:
> ranges = <0x0300 0 0xb000 0x220 0x 0 0xf00>;
> It is just one line. In this case, parser_range_end is same with
> parser.range.
> That is why it happened to work well on D02 board.
> 
> very sorry to bother you about this problem.
> 
> Thanks,
> Zhou
> 
> >
> >
> > root@localhost:~# dmesg | grep -i pci
> > [0.126184] PCI: CLS 0 bytes, default 64
> > [0.152128] PCI host bridge /soc/pcie@0x0100 ranges:
> > [0.152142]   No bus range found for /soc/pcie@0x0100, using
> [bus 00-ff]
> > [0.154183] imx6q-pcie 1ffc000.pcie: PCI host bridge to bus
> :00
> > [0.154201] pci_bus :00: root bus resource [bus 00-ff]
> > [0.154215] pci_bus :00: root bus resource [???
> > 0x01f0-0x01f7 flags 0x0]
> > [0.154228] pci_bus :00: root bus resource [io  0x-0x]
> > [0.154270] pci_bus :00: root bus resource [mem 0x0100-
> 0x01ef]
> > [0.154306] pci :00:00.0: [16c3:abcd] type 01 class 0x060400
> > [0.154333] pci :00:00.0: reg 0x10: [mem 0x-0x000f]
> > [0.154352] pci :00:00.0: reg 0x38: [mem 0x-0x
> pref]
> > [0.154377] pci :00:00.0: IOMMU is currently not supported for
> PCI
> > [0.154429] pci :00:00.0: supports D1
> > [0.154440] pci :00:00.0: PME# supported from D0 D1 D3hot
> D3cold
> > [

[PATCH] Store PCIe controllers address in struct of_pci_range

2015-07-10 Thread Gabriele Paoloni

From: gabriele paoloni 

This patch is needed port PCIe designware to new DT parsing API
As discussed in
http://lists.infradead.org/pipermail/linux-arm-kernel/2015-January/317743.html
in designware we have a problem as the PCI addresses in the PCIe controller
address space are required in order to perform correct HW operation.

In order to solve this problem commit
f4c55c5a3f7f68c06cc559ed7af8b2d017cbb0a7 "PCI: designware:
Program ATU with untranslated address" added code to read the PCIe
controller start address directly from the DT ranges.

In the new DT parsing API of_pci_get_host_bridge_resources() hides the
DT parser from the host controller drivers, so it is not possible
for drivers to parse values directly from the DT.

In http://www.spinics.net/lists/linux-pci/msg42540.html we already tried
to use the new DT parsing API but there is a bug (obviously) in setting
the <*>_mod_base addresses
Applying this patch we can easily set "<*>_mod_base = win->__res.start"

This patch adds a new field in "struct of_pci_range" to store the
pci controller start address; it fills the field in of_pci_range_parser_one();
in of_pci_get_host_bridge_resources() it retrieve the resource entry
after it is created and added to the resource list and uses
entry->__res.start to store the pci controller address

the patch is based on 4.2-rc1

Signed-off-by: Gabriele Paoloni 
---
 drivers/of/address.c   | 1 +
 drivers/of/of_pci.c| 4 
 drivers/pci/host/pcie-designware.c | 9 +++--
 include/linux/of_address.h | 1 +
 4 files changed, 9 insertions(+), 6 deletions(-)

diff --git a/drivers/of/address.c b/drivers/of/address.c
index 8bfda6a..52f9321 100644
--- a/drivers/of/address.c
+++ b/drivers/of/address.c
@@ -265,6 +265,7 @@ struct of_pci_range *of_pci_range_parser_one(struct 
of_pci_range_parser *parser,
range->pci_addr = of_read_number(parser->range + 1, ns);
range->cpu_addr = of_translate_address(parser->node,
parser->range + na);
+   range->pci_ctrl_addr = of_read_number(parser->range + na, ns);
range->size = of_read_number(parser->range + parser->pna + na, ns);
 
parser->range += parser->np;
diff --git a/drivers/of/of_pci.c b/drivers/of/of_pci.c
index 5751dc5..2ccc749 100644
--- a/drivers/of/of_pci.c
+++ b/drivers/of/of_pci.c
@@ -198,6 +198,7 @@ int of_pci_get_host_bridge_resources(struct device_node 
*dev,
 
pr_debug("Parsing ranges property...\n");
for_each_of_pci_range(&parser, &range) {
+   struct resource_entry *entry;
/* Read next ranges element */
if ((range.flags & IORESOURCE_TYPE_BITS) == IORESOURCE_IO)
snprintf(range_type, 4, " IO");
@@ -240,6 +241,9 @@ int of_pci_get_host_bridge_resources(struct device_node 
*dev,
}
 
pci_add_resource_offset(resources, res, res->start - 
range.pci_addr);
+   entry = list_last_entry(resources, struct resource_entry, node);
+   /*we are using __res for storing the PCI controller address*/
+   entry->__res.start = range.pci_ctrl_addr;
}
 
return 0;
diff --git a/drivers/pci/host/pcie-designware.c 
b/drivers/pci/host/pcie-designware.c
index 69486be..106dae6 100644
--- a/drivers/pci/host/pcie-designware.c
+++ b/drivers/pci/host/pcie-designware.c
@@ -416,8 +416,7 @@ int dw_pcie_host_init(struct pcie_port *pp)
pp->io_base = range.cpu_addr;
 
/* Find the untranslated IO space address */
-   pp->io_mod_base = of_read_number(parser.range -
-parser.np + na, ns);
+   pp->io_mod_base = range.pci_ctrl_addr;
}
if (restype == IORESOURCE_MEM) {
of_pci_range_to_resource(&range, np, &pp->mem);
@@ -426,8 +425,7 @@ int dw_pcie_host_init(struct pcie_port *pp)
pp->mem_bus_addr = range.pci_addr;
 
/* Find the untranslated MEM space address */
-   pp->mem_mod_base = of_read_number(parser.range -
- parser.np + na, ns);
+   pp->mem_mod_base = range.pci_ctrl_addr;
}
if (restype == 0) {
of_pci_range_to_resource(&range, np, &pp->cfg);
@@ -437,8 +435,7 @@ int dw_pcie_host_init(struct pcie_port *pp)
pp->cfg1_base = pp->cfg.start + pp->cfg0_size;
 
/* Find the untranslated configuration space address */
-   pp->cfg0_mod_base = of_read_number(parser.range -
-

RE: [PATCH v3 2/5] PCI: designware: Add ARM64 support

2015-07-02 Thread Gabriele Paoloni



> -Original Message-
> From: linux-pci-ow...@vger.kernel.org [mailto:linux-pci-
> ow...@vger.kernel.org] On Behalf Of James Morse
> Sent: 01 July 2015 18:33
> To: Gabriele Paoloni; Wangzhou (B); Bjorn Helgaas; Jingoo Han; Pratyush
> Anand; Arnd Bergmann; Liviu Dudau; kis...@ti.com; x...@kosagi.com; m-
> kariche...@ti.com; minghuan.l...@freescale.com
> Cc: linux-...@vger.kernel.org; linux-arm-ker...@lists.infradead.org;
> devicetree@vger.kernel.org; Yuanzhichang; Zhudacai; zhangjukuo;
> qiuzhenfa; Liguozhu (Kenneth)
> Subject: Re: [PATCH v3 2/5] PCI: designware: Add ARM64 support
> 
> Gabriele Paoloni wrote:
> >> Both series are applied to v4.1, use the same .config file, and the
> >> same dtb.
> >> I will investigate further.
> >>
> >> (Re-testing v2 works, so this isn't an interim hardware failure)
> >
> > This is a bit weird
> >
> > Patch 2/5 is the only one that affect platforms different from
> Hisilicon
> >
> > The only difference between V3 patch[2/5] and v2 patch[2/4] is
> 
> Between v3:2/5 and your replacement for v2:2/4, which arrived after I
> had
> tested the v2 series. As the patch has been replaced with a different
> one -
> neither 'tested-by' is true any more.

Sorry I misread your previous email

> 
> It looks like the BAR containing the bridge window is not being assigned,
> so no devices on bus 1 are discovered.

Can you confirm the dtsi you are using..."imx6qdl.dtsi" ?

Thanks

Gab

> 
> I will send the full v2 and v3 dmesg output separately.
> 
> 
> Thanks,
> 
> James
> 
> --
> 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

RE: [PATCH v3 2/5] PCI: designware: Add ARM64 support

2015-07-01 Thread Gabriele Paoloni

> -Original Message-
> From: linux-pci-ow...@vger.kernel.org [mailto:linux-pci-
> ow...@vger.kernel.org] On Behalf Of James Morse
> Sent: Wednesday, July 01, 2015 3:27 PM
> To: Gabriele Paoloni; Wangzhou (B); Bjorn Helgaas; Jingoo Han; Pratyush
> Anand; Arnd Bergmann; Liviu Dudau; kis...@ti.com; x...@kosagi.com; m-
> kariche...@ti.com; minghuan.l...@freescale.com
> Cc: linux-...@vger.kernel.org; linux-arm-ker...@lists.infradead.org;
> devicetree@vger.kernel.org; Yuanzhichang; Zhudacai; zhangjukuo;
> qiuzhenfa; Liguozhu (Kenneth)
> Subject: Re: [PATCH v3 2/5] PCI: designware: Add ARM64 support
> 
> Zhou Wang wrote:
> > I tested this patch on D02 board of Hisilicon. It works well.
> > I have compiled the driver with multi_v7_defconfig. However, I don't
> > have
> > ARM32 PCIe related board to do test. It will be appreciated if
> someone
> > could
> > help to test it.
> >
> > Signed-off-by: Zhou Wang 
> > Signed-off-by: Arnd Bergmann 
> > Signed-off-by: Gabriele Paoloni 
> > Tested-by: Fabrice Gasnier 
> > Tested-by: James Morse 
> 
> Tests on this new series, using the same i.MX 6Quad board, are not
> working.
> 
> The network card is no longer detected, and I get a lockup when
> removing
> the root bridge and rescanning.
> 
> Partial dmesg output below. Significantly, the lines:
> > [0.152128] PCI host bridge /soc/pcie@0x0100 ranges:
> > [0.152142]   No bus range found for /soc/pcie@0x0100, using
> [bus
> 00-ff]
> are new.
> 
> Both series are applied to v4.1, use the same .config file, and the
> same dtb.
> I will investigate further.
> 
> (Re-testing v2 works, so this isn't an interim hardware failure)

This is a bit weird

Patch 2/5 is the only one that affect platforms different from Hisilicon

The only difference between V3 patch[2/5] and v2 patch[2/4] is

*
diff --git a/drivers/pci/host/pci-keystone-dw.c 
b/drivers/pci/host/pci-keystone-dw.c
index f34892e..b1e4135 100644
--- a/drivers/pci/host/pci-keystone-dw.c
+++ b/drivers/pci/host/pci-keystone-dw.c
@@ -327,7 +327,7 @@ static void ks_dw_pcie_clear_dbi_mode(void __iomem 
*reg_virt)
 void ks_dw_pcie_setup_rc_app_regs(struct keystone_pcie *ks_pcie)
 {
struct pcie_port *pp = &ks_pcie->pp;
-   u32 start = pp->mem.start, end = pp->mem.end;
+   u32 start = pp->mem->start, end = pp->mem->end;
int i, tr_size;
 
/* Disable BARs for inbound access */
**
That is present in v3 but not in v2. And it should affect keystone onlyso 
using patch v3 on the same branch where you applied patch v2 I would expect the 
same results...

> 
> Thanks,
> 
> James
> 
> 
> 
> root@localhost:~# dmesg | grep -i pci
> [0.126184] PCI: CLS 0 bytes, default 64
> [0.152128] PCI host bridge /soc/pcie@0x0100 ranges:
> [0.152142]   No bus range found for /soc/pcie@0x0100, using
> [bus 00-ff]
> [0.154183] imx6q-pcie 1ffc000.pcie: PCI host bridge to bus :00
> [0.154201] pci_bus :00: root bus resource [bus 00-ff]
> [0.154215] pci_bus :00: root bus resource [???
> 0x01f0-0x01f7 flags 0x0]
> [0.154228] pci_bus :00: root bus resource [io  0x-0x]
> [0.154270] pci_bus :00: root bus resource [mem 0x0100-
> 0x01ef]
> [0.154306] pci :00:00.0: [16c3:abcd] type 01 class 0x060400
> [0.154333] pci :00:00.0: reg 0x10: [mem 0x-0x000f]
> [0.154352] pci :00:00.0: reg 0x38: [mem 0x-0x
> pref]
> [0.154377] pci :00:00.0: IOMMU is currently not supported for
> PCI
> [0.154429] pci :00:00.0: supports D1
> [0.154440] pci :00:00.0: PME# supported from D0 D1 D3hot D3cold
> [0.154683] PCI: bus0: Fast back to back transfers disabled
> [0.154806] PCI: bus1: Fast back to back transfers enabled
> [0.154884] pci :00:00.0: BAR 0: assigned [mem 0x0100-
> 0x010f]
> [0.154903] pci :00:00.0: BAR 6: assigned [mem 0x0110-
> 0x0110
> pref]
> [0.154917] pci :00:00.0: PCI bridge to [bus 01]
> [0.155145] pcieport :00:00.0: Signaling PME through PCIe PME
> interrupt
> [0.155161] pcie_pme :00:00.0:pcie01: service driver pcie_pme
> loaded
> [0.155279] aer :00:00.0:pcie02: service driver aer loaded
> [1.188840] ehci-pci: EHCI PCI platform driver
> [1.232518] ohci-pci: OHCI PCI platform driver
> 
> --
> 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
N�Р骒r��yb�X�肚�v�^�)藓{.n�+���z��z谵z)��骅w*jg�报�茛j/�赇z罐���2���ㄨ��&�)摺�a囤���G���h��j:+v���w��佶

RE: [PATCH v3 2/5] PCI: designware: Add ARM64 support

2015-07-01 Thread Gabriele Paoloni

Adding to the recipients list the authors of the drivers that depend on 
Synopsys Designware and that are not included

Respectively:
pci-dra7xx Kishon Vijay Abraham I 
pci-imx6 Sean Cross 
pci-keystone Murali Karicheri 
pci-layerscape Minghuan Lian 

Driver Authors already included:
pci-exynos Jingoo Han 
pcie-spear13xx Pratyush Anand 

Cheers

Gab

> -Original Message-
> From: Wangzhou (B)
> Sent: Wednesday, July 01, 2015 10:44 AM
> To: Bjorn Helgaas; Jingoo Han; Pratyush Anand; Arnd Bergmann; Gabriele
> Paoloni; James Morse; Liviu Dudau
> Cc: linux-...@vger.kernel.org; linux-arm-ker...@lists.infradead.org;
> devicetree@vger.kernel.org; Yuanzhichang; Zhudacai; zhangjukuo;
> qiuzhenfa; Liguozhu (Kenneth); Wangzhou (B)
> Subject: [PATCH v3 2/5] PCI: designware: Add ARM64 support
> 
> This patch tries to unify ARM32 and ARM64 PCIe in designware driver.
> Delete
> function dw_pcie_setup, dw_pcie_scan_bus, dw_pcie_map_irq and struct
> hw_pci,
> move related operations to dw_pcie_host_init. Also set pp->root_bus_nr
> = 0 in
> each PCIe host driver which is based on pcie-designware. This patch
> also try
> to use of_pci_get_host_bridge_resources for ARM32 and ARM64 according
> to the
> suggestion for Gabriele[1]
> 
> I tested this patch on D02 board of Hisilicon. It works well.
> I have compiled the driver with multi_v7_defconfig. However, I don't
> have
> ARM32 PCIe related board to do test. It will be appreciated if someone
> could
> help to test it.
> 
> Signed-off-by: Zhou Wang 
> Signed-off-by: Arnd Bergmann 
> Signed-off-by: Gabriele Paoloni 
> Tested-by: Fabrice Gasnier 
> Tested-by: James Morse 
> 
> [1] http://www.spinics.net/lists/linux-pci/msg42194.html
> ---
>  drivers/pci/host/pci-dra7xx.c  |   1 +
>  drivers/pci/host/pci-exynos.c  |   2 +-
>  drivers/pci/host/pci-imx6.c|   2 +-
>  drivers/pci/host/pci-keystone-dw.c |   2 +-
>  drivers/pci/host/pci-keystone.c|   2 +-
>  drivers/pci/host/pci-layerscape.c  |   2 +-
>  drivers/pci/host/pcie-designware.c | 242 +++--
> 
>  drivers/pci/host/pcie-designware.h |  10 +-
>  drivers/pci/host/pcie-spear13xx.c  |   2 +-
>  9 files changed, 110 insertions(+), 155 deletions(-)
> 
> diff --git a/drivers/pci/host/pci-dra7xx.c b/drivers/pci/host/pci-
> dra7xx.c
> index 2d57e19..5c8b6ab 100644
> --- a/drivers/pci/host/pci-dra7xx.c
> +++ b/drivers/pci/host/pci-dra7xx.c
> @@ -280,6 +280,7 @@ static int __init dra7xx_add_pcie_port(struct
> dra7xx_pcie *dra7xx,
> 
>   pp = &dra7xx->pp;
>   pp->dev = dev;
> + pp->root_bus_nr = 0;
>   pp->ops = &dra7xx_pcie_host_ops;
> 
>   pp->irq = platform_get_irq(pdev, 1);
> diff --git a/drivers/pci/host/pci-exynos.c b/drivers/pci/host/pci-
> exynos.c
> index c139237..4b6db6c 100644
> --- a/drivers/pci/host/pci-exynos.c
> +++ b/drivers/pci/host/pci-exynos.c
> @@ -534,7 +534,7 @@ static int __init exynos_add_pcie_port(struct
> pcie_port *pp,
>   }
>   }
> 
> - pp->root_bus_nr = -1;
> + pp->root_bus_nr = 0;
>   pp->ops = &exynos_pcie_host_ops;
> 
>   ret = dw_pcie_host_init(pp);
> diff --git a/drivers/pci/host/pci-imx6.c b/drivers/pci/host/pci-imx6.c
> index fdb9536..c4a80c5 100644
> --- a/drivers/pci/host/pci-imx6.c
> +++ b/drivers/pci/host/pci-imx6.c
> @@ -541,7 +541,7 @@ static int __init imx6_add_pcie_port(struct
> pcie_port *pp,
>   }
>   }
> 
> - pp->root_bus_nr = -1;
> + pp->root_bus_nr = 0;
>   pp->ops = &imx6_pcie_host_ops;
> 
>   ret = dw_pcie_host_init(pp);
> diff --git a/drivers/pci/host/pci-keystone-dw.c b/drivers/pci/host/pci-
> keystone-dw.c
> index f34892e..b1e4135 100644
> --- a/drivers/pci/host/pci-keystone-dw.c
> +++ b/drivers/pci/host/pci-keystone-dw.c
> @@ -327,7 +327,7 @@ static void ks_dw_pcie_clear_dbi_mode(void __iomem
> *reg_virt)
>  void ks_dw_pcie_setup_rc_app_regs(struct keystone_pcie *ks_pcie)
>  {
>   struct pcie_port *pp = &ks_pcie->pp;
> - u32 start = pp->mem.start, end = pp->mem.end;
> + u32 start = pp->mem->start, end = pp->mem->end;
>   int i, tr_size;
> 
>   /* Disable BARs for inbound access */
> diff --git a/drivers/pci/host/pci-keystone.c b/drivers/pci/host/pci-
> keystone.c
> index 75333b0..df91f5e 100644
> --- a/drivers/pci/host/pci-keystone.c
> +++ b/drivers/pci/host/pci-keystone.c
> @@ -312,7 +312,7 @@ static int __init ks_add_pcie_port(struct
> keystone_pcie *ks_pcie,
>   return ret;
>   }
> 
> - pp->root_bus_nr = -1;
> + pp->root_bus_nr = 0;
>

RE: [PATCH v2 2/4] PCI: designware: Add ARM64 support

2015-06-16 Thread Gabriele Paoloni


> -Original Message-
> From: Wangzhou (B)
> Sent: Tuesday, June 16, 2015 12:30 PM
> To: Gabriele Paoloni
> Cc: Lorenzo Pieralisi; James Morse; Bjorn Helgaas; Jingoo Han; Pratyush
> Anand; Arnd Bergmann; fabrice.gasn...@st.com; Liviu Dudau; linux-
> p...@vger.kernel.org; linux-arm-ker...@lists.infradead.org;
> devicetree@vger.kernel.org; Yuanzhichang; Zhudacai; zhangjukuo;
> qiuzhenfa; Liguozhu (Kenneth)
> Subject: Re: [PATCH v2 2/4] PCI: designware: Add ARM64 support
> 
> On 2015/6/11 22:32, Gabriele Paoloni wrote:
> > Hi Zhou Wang
> >
> > I apologize, I made a mistake as I didn't rebase the patch on the
> latest Kernel (where I was convinced I did), my bad.
> >
> > The patch below is based on v4.1-rc7
> >
> > It passes checkpatch and compiles OK
> >
> > Cheers
> >
> > Gab
> >
> 
> Hi Gab,
> 
> I will try to merge your patch into next version, please help to
> review :)
>

Sure I will :)

Thanks

Gab
 
> Many thanks for your patch.
> Zhou
> 
> > ---
> > ---
> > This patch is a rework of
> > "[PATCH v2 2/4] PCI: designware: Add ARM64 support" from Zhou Wang.
> >
> > The intention is to complete the unification between ARM and
> > ARM64 now that the dependency on arch/arm/kernel/bios32.c is gone.
> >
> > I have also included the rework asked by James Morse:
> > io_base declared as resource_size_t
> >
> > It compiles fine on ARCH arm and arm64 on Linux 4.1-rc7.
> >
> > It needs to be tested.
> >
> > Signed-off-by: Gabriele Paoloni 
> >
> > ---
> >  drivers/pci/host/pci-dra7xx.c  |   1 +
> >  drivers/pci/host/pci-exynos.c  |   2 +-
> >  drivers/pci/host/pci-imx6.c|   2 +-
> >  drivers/pci/host/pci-keystone.c|   2 +-
> >  drivers/pci/host/pci-layerscape.c  |   2 +-
> >  drivers/pci/host/pcie-designware.c | 242 +++
> --
> >  drivers/pci/host/pcie-designware.h |  10 +-
> >  drivers/pci/host/pcie-spear13xx.c  |   2 +-
> >  8 files changed, 109 insertions(+), 154 deletions(-)
> >
> > diff --git a/drivers/pci/host/pci-dra7xx.c b/drivers/pci/host/pci-
> dra7xx.c
> > index 2d57e19..5c8b6ab 100644
> > --- a/drivers/pci/host/pci-dra7xx.c
> > +++ b/drivers/pci/host/pci-dra7xx.c
> > @@ -280,6 +280,7 @@ static int __init dra7xx_add_pcie_port(struct
> dra7xx_pcie *dra7xx,
> >
> > pp = &dra7xx->pp;
> > pp->dev = dev;
> > +   pp->root_bus_nr = 0;
> > pp->ops = &dra7xx_pcie_host_ops;
> >
> > pp->irq = platform_get_irq(pdev, 1);
> > diff --git a/drivers/pci/host/pci-exynos.c b/drivers/pci/host/pci-
> exynos.c
> > index c139237..4b6db6c 100644
> > --- a/drivers/pci/host/pci-exynos.c
> > +++ b/drivers/pci/host/pci-exynos.c
> > @@ -534,7 +534,7 @@ static int __init exynos_add_pcie_port(struct
> pcie_port *pp,
> > }
> > }
> >
> > -   pp->root_bus_nr = -1;
> > +   pp->root_bus_nr = 0;
> > pp->ops = &exynos_pcie_host_ops;
> >
> > ret = dw_pcie_host_init(pp);
> > diff --git a/drivers/pci/host/pci-imx6.c b/drivers/pci/host/pci-
> imx6.c
> > index fdb9536..c4a80c5 100644
> > --- a/drivers/pci/host/pci-imx6.c
> > +++ b/drivers/pci/host/pci-imx6.c
> > @@ -541,7 +541,7 @@ static int __init imx6_add_pcie_port(struct
> pcie_port *pp,
> > }
> > }
> >
> > -   pp->root_bus_nr = -1;
> > +   pp->root_bus_nr = 0;
> > pp->ops = &imx6_pcie_host_ops;
> >
> > ret = dw_pcie_host_init(pp);
> > diff --git a/drivers/pci/host/pci-keystone.c b/drivers/pci/host/pci-
> keystone.c
> > index 75333b0..df91f5e 100644
> > --- a/drivers/pci/host/pci-keystone.c
> > +++ b/drivers/pci/host/pci-keystone.c
> > @@ -312,7 +312,7 @@ static int __init ks_add_pcie_port(struct
> keystone_pcie *ks_pcie,
> > return ret;
> > }
> >
> > -   pp->root_bus_nr = -1;
> > +   pp->root_bus_nr = 0;
> > pp->ops = &keystone_pcie_host_ops;
> > ret = ks_dw_pcie_host_init(ks_pcie, ks_pcie->msi_intc_np);
> > if (ret) {
> > diff --git a/drivers/pci/host/pci-layerscape.c
> b/drivers/pci/host/pci-layerscape.c
> > index 4a6e62f..5c7a9c4 100644
> > --- a/drivers/pci/host/pci-layerscape.c
> > +++ b/drivers/pci/host/pci-layerscape.c
> > @@ -101,7 +101,7 @@ static int ls_add_pcie_port(struct ls_pcie *pcie)
> &g

RE: [PATCH v2 2/4] PCI: designware: Add ARM64 support

2015-06-11 Thread Gabriele Paoloni

Hi Zhou Wang

I apologize, I made a mistake as I didn't rebase the patch on the latest Kernel 
(where I was convinced I did), my bad.

The patch below is based on v4.1-rc7

It passes checkpatch and compiles OK

Cheers

Gab

---
---
This patch is a rework of
"[PATCH v2 2/4] PCI: designware: Add ARM64 support" from Zhou Wang.

The intention is to complete the unification between ARM and
ARM64 now that the dependency on arch/arm/kernel/bios32.c is gone.

I have also included the rework asked by James Morse:
io_base declared as resource_size_t

It compiles fine on ARCH arm and arm64 on Linux 4.1-rc7. 

It needs to be tested.

Signed-off-by: Gabriele Paoloni 

---
 drivers/pci/host/pci-dra7xx.c  |   1 +
 drivers/pci/host/pci-exynos.c  |   2 +-
 drivers/pci/host/pci-imx6.c|   2 +-
 drivers/pci/host/pci-keystone.c|   2 +-
 drivers/pci/host/pci-layerscape.c  |   2 +-
 drivers/pci/host/pcie-designware.c | 242 +++--
 drivers/pci/host/pcie-designware.h |  10 +-
 drivers/pci/host/pcie-spear13xx.c  |   2 +-
 8 files changed, 109 insertions(+), 154 deletions(-)

diff --git a/drivers/pci/host/pci-dra7xx.c b/drivers/pci/host/pci-dra7xx.c
index 2d57e19..5c8b6ab 100644
--- a/drivers/pci/host/pci-dra7xx.c
+++ b/drivers/pci/host/pci-dra7xx.c
@@ -280,6 +280,7 @@ static int __init dra7xx_add_pcie_port(struct dra7xx_pcie 
*dra7xx,
 
pp = &dra7xx->pp;
pp->dev = dev;
+   pp->root_bus_nr = 0;
pp->ops = &dra7xx_pcie_host_ops;
 
pp->irq = platform_get_irq(pdev, 1);
diff --git a/drivers/pci/host/pci-exynos.c b/drivers/pci/host/pci-exynos.c
index c139237..4b6db6c 100644
--- a/drivers/pci/host/pci-exynos.c
+++ b/drivers/pci/host/pci-exynos.c
@@ -534,7 +534,7 @@ static int __init exynos_add_pcie_port(struct pcie_port *pp,
}
}
 
-   pp->root_bus_nr = -1;
+   pp->root_bus_nr = 0;
pp->ops = &exynos_pcie_host_ops;
 
ret = dw_pcie_host_init(pp);
diff --git a/drivers/pci/host/pci-imx6.c b/drivers/pci/host/pci-imx6.c
index fdb9536..c4a80c5 100644
--- a/drivers/pci/host/pci-imx6.c
+++ b/drivers/pci/host/pci-imx6.c
@@ -541,7 +541,7 @@ static int __init imx6_add_pcie_port(struct pcie_port *pp,
}
}
 
-   pp->root_bus_nr = -1;
+   pp->root_bus_nr = 0;
pp->ops = &imx6_pcie_host_ops;
 
ret = dw_pcie_host_init(pp);
diff --git a/drivers/pci/host/pci-keystone.c b/drivers/pci/host/pci-keystone.c
index 75333b0..df91f5e 100644
--- a/drivers/pci/host/pci-keystone.c
+++ b/drivers/pci/host/pci-keystone.c
@@ -312,7 +312,7 @@ static int __init ks_add_pcie_port(struct keystone_pcie 
*ks_pcie,
return ret;
}
 
-   pp->root_bus_nr = -1;
+   pp->root_bus_nr = 0;
pp->ops = &keystone_pcie_host_ops;
ret = ks_dw_pcie_host_init(ks_pcie, ks_pcie->msi_intc_np);
if (ret) {
diff --git a/drivers/pci/host/pci-layerscape.c 
b/drivers/pci/host/pci-layerscape.c
index 4a6e62f..5c7a9c4 100644
--- a/drivers/pci/host/pci-layerscape.c
+++ b/drivers/pci/host/pci-layerscape.c
@@ -101,7 +101,7 @@ static int ls_add_pcie_port(struct ls_pcie *pcie)
pp = &pcie->pp;
pp->dev = pcie->dev;
pp->dbi_base = pcie->dbi;
-   pp->root_bus_nr = -1;
+   pp->root_bus_nr = 0;
pp->ops = &ls_pcie_host_ops;
 
ret = dw_pcie_host_init(pp);
diff --git a/drivers/pci/host/pcie-designware.c 
b/drivers/pci/host/pcie-designware.c
index 2e9f84f..844febee 100644
--- a/drivers/pci/host/pcie-designware.c
+++ b/drivers/pci/host/pcie-designware.c
@@ -11,6 +11,7 @@
  * published by the Free Software Foundation.
  */
 
+#include 
 #include 
 #include 
 #include 
@@ -67,16 +68,7 @@
 #define PCIE_ATU_FUNC(x)   (((x) & 0x7) << 16)
 #define PCIE_ATU_UPPER_TARGET  0x91C
 
-static struct hw_pci dw_pci;
-
-static unsigned long global_io_offset;
-
-static inline struct pcie_port *sys_to_pcie(struct pci_sys_data *sys)
-{
-   BUG_ON(!sys->private_data);
-
-   return sys->private_data;
-}
+static struct pci_ops dw_pcie_ops;
 
 int dw_pcie_cfg_read(void __iomem *addr, int where, int size, u32 *val)
 {
@@ -238,7 +230,7 @@ static void dw_pcie_msi_set_irq(struct pcie_port *pp, int 
irq)
 static int assign_irq(int no_irqs, struct msi_desc *desc, int *pos)
 {
int irq, pos0, i;
-   struct pcie_port *pp = sys_to_pcie(desc->dev->bus->sysdata);
+   struct pcie_port *pp = desc->dev->bus->sysdata;
 
pos0 = bitmap_find_free_region(pp->msi_irq_in_use, MAX_MSI_IRQS,
   order_base_2(no_irqs));
@@ -281,7 +273,7 @@ static int dw_msi_setup_irq(struct msi_controller *chip, 
struct pci_dev *pdev,
 {
int irq, pos;
struct msi_msg msg;
-

RE: [PATCH v2 2/4] PCI: designware: Add ARM64 support

2015-06-10 Thread Gabriele Paoloni

Hi Zhou Wang and all

I have worked on a patch that unify ARM and ARM64. As you can see I have 
removed the parser and now I use "of_pci_get_host_bridge_resources" in order to 
retrieve the resources associated to each pci host bridge window.
The resources now are not copied to the designware pcie_port pp, instead they 
are passed by pointer.

This patch is intended to replace entirely "[PATCH v2 2/4]"; so I have also 
included all the changes about the other drivers 

Please find the patch inline below. 

Let me know if you think it is ok.

Regards

Gab




This patch is a rework of
"[PATCH v2 2/4] PCI: designware: Add ARM64 support" from Zhou Wang.

The intention is to complete the unification between ARM and
ARM64 now that the dependency on arch/arm/kernel/bios32.c is gone.

I have also included the rework asked by James Morse: 
io_base declared as resource_size_t

It compiles fine on ARCH arm and arm64.

It needs to be tested.

Signed-off-by: Gabriele Paoloni 


---
 drivers/pci/host/pci-dra7xx.c  |   1 +
 drivers/pci/host/pci-exynos.c  |   2 +-
 drivers/pci/host/pci-imx6.c|   2 +-
 drivers/pci/host/pci-keystone.c|   2 +-
 drivers/pci/host/pci-layerscape.c  |   2 +-
 drivers/pci/host/pcie-designware.c | 242 +++--
 drivers/pci/host/pcie-designware.h |  10 +-
 drivers/pci/host/pcie-spear13xx.c  |   2 +-
 8 files changed, 109 insertions(+), 154 deletions(-)

diff --git a/drivers/pci/host/pci-dra7xx.c b/drivers/pci/host/pci-dra7xx.c 
index 2d57e19..5c8b6ab 100644
--- a/drivers/pci/host/pci-dra7xx.c
+++ b/drivers/pci/host/pci-dra7xx.c
@@ -280,6 +280,7 @@ static int __init dra7xx_add_pcie_port(struct dra7xx_pcie 
*dra7xx,
 
pp = &dra7xx->pp;
pp->dev = dev;
+   pp->root_bus_nr = 0;
pp->ops = &dra7xx_pcie_host_ops;
 
pp->irq = platform_get_irq(pdev, 1);
diff --git a/drivers/pci/host/pci-exynos.c b/drivers/pci/host/pci-exynos.c 
index c139237..4b6db6c 100644
--- a/drivers/pci/host/pci-exynos.c
+++ b/drivers/pci/host/pci-exynos.c
@@ -534,7 +534,7 @@ static int __init exynos_add_pcie_port(struct pcie_port *pp,
}
}
 
-   pp->root_bus_nr = -1;
+   pp->root_bus_nr = 0;
pp->ops = &exynos_pcie_host_ops;
 
ret = dw_pcie_host_init(pp);
diff --git a/drivers/pci/host/pci-imx6.c b/drivers/pci/host/pci-imx6.c index 
fdb9536..c4a80c5 100644
--- a/drivers/pci/host/pci-imx6.c
+++ b/drivers/pci/host/pci-imx6.c
@@ -541,7 +541,7 @@ static int __init imx6_add_pcie_port(struct pcie_port *pp,
}
}
 
-   pp->root_bus_nr = -1;
+   pp->root_bus_nr = 0;
pp->ops = &imx6_pcie_host_ops;
 
ret = dw_pcie_host_init(pp);
diff --git a/drivers/pci/host/pci-keystone.c b/drivers/pci/host/pci-keystone.c 
index 75333b0..df91f5e 100644
--- a/drivers/pci/host/pci-keystone.c
+++ b/drivers/pci/host/pci-keystone.c
@@ -312,7 +312,7 @@ static int __init ks_add_pcie_port(struct keystone_pcie 
*ks_pcie,
return ret;
}
 
-   pp->root_bus_nr = -1;
+   pp->root_bus_nr = 0;
pp->ops = &keystone_pcie_host_ops;
ret = ks_dw_pcie_host_init(ks_pcie, ks_pcie->msi_intc_np);
if (ret) {
diff --git a/drivers/pci/host/pci-layerscape.c 
b/drivers/pci/host/pci-layerscape.c
index 4a6e62f..5c7a9c4 100644
--- a/drivers/pci/host/pci-layerscape.c
+++ b/drivers/pci/host/pci-layerscape.c
@@ -101,7 +101,7 @@ static int ls_add_pcie_port(struct ls_pcie *pcie)
pp = &pcie->pp;
pp->dev = pcie->dev;
pp->dbi_base = pcie->dbi;
-   pp->root_bus_nr = -1;
+   pp->root_bus_nr = 0;
pp->ops = &ls_pcie_host_ops;
 
ret = dw_pcie_host_init(pp);
diff --git a/drivers/pci/host/pcie-designware.c 
b/drivers/pci/host/pcie-designware.c
index 2e9f84f..31b29a5 100644
--- a/drivers/pci/host/pcie-designware.c
+++ b/drivers/pci/host/pcie-designware.c
@@ -11,6 +11,7 @@
  * published by the Free Software Foundation.
  */
 
+#include 
 #include 
 #include 
 #include 
@@ -67,16 +68,7 @@
 #define PCIE_ATU_FUNC(x)   (((x) & 0x7) << 16)
 #define PCIE_ATU_UPPER_TARGET  0x91C
 
-static struct hw_pci dw_pci;
-
-static unsigned long global_io_offset;
-
-static inline struct pcie_port *sys_to_pcie(struct pci_sys_data *sys) -{
-   BUG_ON(!sys->private_data);
-
-   return sys->private_data;
-}
+static struct pci_ops dw_pcie_ops;
 
 int dw_pcie_cfg_read(void __iomem *addr, int where, int size, u32 *val)  { @@ 
-238,7 +230,7 @@ static void dw_pcie_msi_set_irq(struct pcie_port *pp, int irq) 
 static int assign_irq(int no_irqs, struct msi_desc *desc, int *pos)  {
int irq, pos0, i;
-   struct pcie_port *pp = sys_to_pcie(desc->dev->bus->sysdata);
+   struct pcie_port *pp =

55 matches

Mail list logo