Re: [PATCH 00/14] Rewrite Tegra PCIe driver

2013-01-28 Thread Bjorn Helgaas
On Wed, Jan 9, 2013 at 1:43 PM, Thierry Reding
 wrote:
> This patch series contains an almost complete rewrite of the Tegra PCIe
> driver. The code is moved to the drivers/pci/host directory and turned
> into a proper platform driver, adding MSI and DT support while at it.
> Other PCI host controller drivers can be added to that directory in an
> attempt to make it easier to factor out common code.
>
> Patches 1 to 4 add generic OF helpers to parse a PCI node's ranges
> property as well as obtain the bus, device and function numbers from a
> node's reg property.
>
> Patch 5 provides an implementation of a cache for I/O mappings. This can
> be used in situations where a large physical memory region needs to be
> ioremap()'ed. On Tegra, the PCIe standard and extended configuration
> spaces can be accessed through a 256 MiB window. Mapping that in one
> chunk is wasteful and may not always work because the vmalloc area may
> not be large enough. The implementation in this patch uses an LRU based
> approach to map a limited amount of pages on an as-needed basis.
>
> Patches 6 and 7 prepare the ARM PCI code to enable PCI host controller
> drivers to load after the init stage, which can happen due to deferred
> probing, and to allow private data to be passed for each controller.
>
> Patches 8 and 9 move some of the Tegra specific code around to allow it
> to be used from outside the arch/arm/mach-tegra directory.
>
> Patch 10 moves the Tegra PCIe controller driver to the drivers/pci/host
> directory and turns it into a proper platform driver. It also adds MSI
> (based on patches by NVIDIA) and DT support.
>
> Patches 11 to 14 add device tree based probing for the TEC, Harmony and
> TrimSlice boards.
>
> Thierry
>
> Andrew Murray (1):
>   of/pci: Provide support for parsing PCI DT ranges property
>
> Thierry Reding (13):
>   of/pci: Add of_pci_get_devfn() function
>   of/pci: Add of_pci_get_bus() function
>   of/pci: Add of_pci_parse_bus_range() function
>   lib: Add I/O map cache implementation
>   ARM: pci: Keep pci_common_init() around after init
>   ARM: pci: Allow passing per-controller private data
>   ARM: tegra: Move tegra_pcie_xclk_clamp() to PMC
>   ARM: tegra: Move pmc.h to include/mach
>   PCI: tegra: Move PCIe driver to drivers/pci/host
>   ARM: tegra: tamonten: Add PCIe support
>   ARM: tegra: tec: Add PCIe support
>   ARM: tegra: harmony: Initialize PCIe from DT
>   ARM: tegra: trimslice: Initialize PCIe from DT
>
>  .../bindings/pci/nvidia,tegra20-pcie.txt   |  115 ++
>  arch/arm/Kconfig   |2 +
>  arch/arm/boot/dts/tegra20-harmony.dts  |   20 +-
>  arch/arm/boot/dts/tegra20-tamonten.dtsi|2 +-
>  arch/arm/boot/dts/tegra20-tec.dts  |  198 +++
>  arch/arm/boot/dts/tegra20-trimslice.dts|   12 +
>  arch/arm/boot/dts/tegra20.dtsi |   45 +
>  arch/arm/include/asm/mach/pci.h|1 +
>  arch/arm/kernel/bios32.c   |9 +-
>  arch/arm/mach-tegra/Kconfig|5 -
>  arch/arm/mach-tegra/Makefile   |3 -
>  arch/arm/mach-tegra/board-dt-tegra20.c |   24 -
>  arch/arm/mach-tegra/board-harmony-pcie.c   |   84 --
>  arch/arm/mach-tegra/board.h|4 +-
>  arch/arm/mach-tegra/common.c   |2 +-
>  arch/arm/mach-tegra/include/mach/pmc.h |   24 +
>  arch/arm/mach-tegra/iomap.h|3 -
>  arch/arm/mach-tegra/pcie.c |  887 -
>  arch/arm/mach-tegra/pmc.c  |   16 +
>  arch/arm/mach-tegra/pmc.h  |   23 -
>  drivers/of/address.c   |   63 +
>  drivers/of/of_pci.c|   78 +-
>  drivers/pci/Kconfig|2 +
>  drivers/pci/Makefile   |3 +
>  drivers/pci/host/Kconfig   |8 +
>  drivers/pci/host/Makefile  |1 +
>  drivers/pci/host/pci-tegra.c   | 1322 
> 
>  include/linux/io.h |   12 +
>  include/linux/of_address.h |9 +
>  include/linux/of_pci.h |3 +
>  lib/ioremap.c  |  266 
>  31 files changed, 2203 insertions(+), 1043 deletions(-)
>  create mode 100644 
> Documentation/devicetree/bindings/pci/nvidia,tegra20-pcie.txt
>  delete mode 100644 arch/arm/mach-tegra/board-harmony-pcie.c
>  create mode 100644 arch/arm/mach-tegra/include/mach/pmc.h
>  delete mode 100644 arch/arm/mach-tegra/pcie.c
>  delete mode 100644 arch/arm/mach-tegra/pmc.h
>  create mode 100644 drivers/pci/host/Kconfig
>  create mode 100644 drivers/pci/host/Makefile
>  create mode 100644 drivers/pci/host/pci-tegra.c

Hi Thierry,

Since 

Re: [PATCH 00/14] Rewrite Tegra PCIe driver

2013-01-28 Thread Bjorn Helgaas
On Wed, Jan 9, 2013 at 1:43 PM, Thierry Reding
thierry.red...@avionic-design.de wrote:
 This patch series contains an almost complete rewrite of the Tegra PCIe
 driver. The code is moved to the drivers/pci/host directory and turned
 into a proper platform driver, adding MSI and DT support while at it.
 Other PCI host controller drivers can be added to that directory in an
 attempt to make it easier to factor out common code.

 Patches 1 to 4 add generic OF helpers to parse a PCI node's ranges
 property as well as obtain the bus, device and function numbers from a
 node's reg property.

 Patch 5 provides an implementation of a cache for I/O mappings. This can
 be used in situations where a large physical memory region needs to be
 ioremap()'ed. On Tegra, the PCIe standard and extended configuration
 spaces can be accessed through a 256 MiB window. Mapping that in one
 chunk is wasteful and may not always work because the vmalloc area may
 not be large enough. The implementation in this patch uses an LRU based
 approach to map a limited amount of pages on an as-needed basis.

 Patches 6 and 7 prepare the ARM PCI code to enable PCI host controller
 drivers to load after the init stage, which can happen due to deferred
 probing, and to allow private data to be passed for each controller.

 Patches 8 and 9 move some of the Tegra specific code around to allow it
 to be used from outside the arch/arm/mach-tegra directory.

 Patch 10 moves the Tegra PCIe controller driver to the drivers/pci/host
 directory and turns it into a proper platform driver. It also adds MSI
 (based on patches by NVIDIA) and DT support.

 Patches 11 to 14 add device tree based probing for the TEC, Harmony and
 TrimSlice boards.

 Thierry

 Andrew Murray (1):
   of/pci: Provide support for parsing PCI DT ranges property

 Thierry Reding (13):
   of/pci: Add of_pci_get_devfn() function
   of/pci: Add of_pci_get_bus() function
   of/pci: Add of_pci_parse_bus_range() function
   lib: Add I/O map cache implementation
   ARM: pci: Keep pci_common_init() around after init
   ARM: pci: Allow passing per-controller private data
   ARM: tegra: Move tegra_pcie_xclk_clamp() to PMC
   ARM: tegra: Move pmc.h to include/mach
   PCI: tegra: Move PCIe driver to drivers/pci/host
   ARM: tegra: tamonten: Add PCIe support
   ARM: tegra: tec: Add PCIe support
   ARM: tegra: harmony: Initialize PCIe from DT
   ARM: tegra: trimslice: Initialize PCIe from DT

  .../bindings/pci/nvidia,tegra20-pcie.txt   |  115 ++
  arch/arm/Kconfig   |2 +
  arch/arm/boot/dts/tegra20-harmony.dts  |   20 +-
  arch/arm/boot/dts/tegra20-tamonten.dtsi|2 +-
  arch/arm/boot/dts/tegra20-tec.dts  |  198 +++
  arch/arm/boot/dts/tegra20-trimslice.dts|   12 +
  arch/arm/boot/dts/tegra20.dtsi |   45 +
  arch/arm/include/asm/mach/pci.h|1 +
  arch/arm/kernel/bios32.c   |9 +-
  arch/arm/mach-tegra/Kconfig|5 -
  arch/arm/mach-tegra/Makefile   |3 -
  arch/arm/mach-tegra/board-dt-tegra20.c |   24 -
  arch/arm/mach-tegra/board-harmony-pcie.c   |   84 --
  arch/arm/mach-tegra/board.h|4 +-
  arch/arm/mach-tegra/common.c   |2 +-
  arch/arm/mach-tegra/include/mach/pmc.h |   24 +
  arch/arm/mach-tegra/iomap.h|3 -
  arch/arm/mach-tegra/pcie.c |  887 -
  arch/arm/mach-tegra/pmc.c  |   16 +
  arch/arm/mach-tegra/pmc.h  |   23 -
  drivers/of/address.c   |   63 +
  drivers/of/of_pci.c|   78 +-
  drivers/pci/Kconfig|2 +
  drivers/pci/Makefile   |3 +
  drivers/pci/host/Kconfig   |8 +
  drivers/pci/host/Makefile  |1 +
  drivers/pci/host/pci-tegra.c   | 1322 
 
  include/linux/io.h |   12 +
  include/linux/of_address.h |9 +
  include/linux/of_pci.h |3 +
  lib/ioremap.c  |  266 
  31 files changed, 2203 insertions(+), 1043 deletions(-)
  create mode 100644 
 Documentation/devicetree/bindings/pci/nvidia,tegra20-pcie.txt
  delete mode 100644 arch/arm/mach-tegra/board-harmony-pcie.c
  create mode 100644 arch/arm/mach-tegra/include/mach/pmc.h
  delete mode 100644 arch/arm/mach-tegra/pcie.c
  delete mode 100644 arch/arm/mach-tegra/pmc.h
  create mode 100644 drivers/pci/host/Kconfig
  create mode 100644 drivers/pci/host/Makefile
  create mode 100644 drivers/pci/host/pci-tegra.c

Hi Thierry,

Since the bulk of this series affects ARM, I'm assuming this will 

Re: [PATCH 00/14] Rewrite Tegra PCIe driver

2013-01-10 Thread Thomas Petazzoni
Dear Thierry Reding,

On Thu, 10 Jan 2013 07:55:37 +0100, Thierry Reding wrote:

> The reason is that with the latest bindings the matching of root ports
> to device tree nodes works as-is and nothing else indicates that the
> emulated host bridge is actually required to make any of this work. So
> in order not to introduce unneeded code I've left it out for now. If
> somebody decides that we actually need this host bridge (for standards
> compliance or whatnot) it could easily be added back.

Ok.

> However, before the emulated bridge implementation can be merged I think
> the PCI ID issue needs to be resolved.

Indeed. I am not sure yet how to solve that, though.

> > So, I instantiate one unique emulated Host Bridge, and then one
> > emulated PCI-to-PCI Bridge for each PCIe interface that I have.
> 
> Oh dear, that's even worse than on Tegra. The Marvell hardware doesn't
> even expose the root ports as PCI devices on the bus?

My understanding is that no, it doesn't, but I am still figuring out
many things in this PCIe topic.

> I suppose that in your case it really makes sense because you already
> need the emulated PCI-to-PCI bridges and therefore adding an emulated
> host bridge doesn't add much. As I said, for Tegra everything still
> works without, so I didn't see a reason to add needless code.

Ok, thanks!

Thomas
-- 
Thomas Petazzoni, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: [PATCH 00/14] Rewrite Tegra PCIe driver

2013-01-10 Thread Thomas Petazzoni
Dear Thierry Reding,

On Thu, 10 Jan 2013 07:55:37 +0100, Thierry Reding wrote:

 The reason is that with the latest bindings the matching of root ports
 to device tree nodes works as-is and nothing else indicates that the
 emulated host bridge is actually required to make any of this work. So
 in order not to introduce unneeded code I've left it out for now. If
 somebody decides that we actually need this host bridge (for standards
 compliance or whatnot) it could easily be added back.

Ok.

 However, before the emulated bridge implementation can be merged I think
 the PCI ID issue needs to be resolved.

Indeed. I am not sure yet how to solve that, though.

  So, I instantiate one unique emulated Host Bridge, and then one
  emulated PCI-to-PCI Bridge for each PCIe interface that I have.
 
 Oh dear, that's even worse than on Tegra. The Marvell hardware doesn't
 even expose the root ports as PCI devices on the bus?

My understanding is that no, it doesn't, but I am still figuring out
many things in this PCIe topic.

 I suppose that in your case it really makes sense because you already
 need the emulated PCI-to-PCI bridges and therefore adding an emulated
 host bridge doesn't add much. As I said, for Tegra everything still
 works without, so I didn't see a reason to add needless code.

Ok, thanks!

Thomas
-- 
Thomas Petazzoni, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: [PATCH 00/14] Rewrite Tegra PCIe driver

2013-01-09 Thread Thierry Reding
On Wed, Jan 09, 2013 at 10:25:17PM +0100, Thomas Petazzoni wrote:
> Dear Thierry Reding,
> 
> On Wed,  9 Jan 2013 21:43:00 +0100, Thierry Reding wrote:
> > This patch series contains an almost complete rewrite of the Tegra PCIe
> > driver. The code is moved to the drivers/pci/host directory and turned
> > into a proper platform driver, adding MSI and DT support while at it.
> > Other PCI host controller drivers can be added to that directory in an
> > attempt to make it easier to factor out common code.
> 
> Thanks!
> 
> I have started basing the Marvell PCIe code on some of your earlier
> versions. But apparently in this final version, you no longer have the
> emulated Host bridge. Why so?

The reason is that with the latest bindings the matching of root ports
to device tree nodes works as-is and nothing else indicates that the
emulated host bridge is actually required to make any of this work. So
in order not to introduce unneeded code I've left it out for now. If
somebody decides that we actually need this host bridge (for standards
compliance or whatnot) it could easily be added back.

However, before the emulated bridge implementation can be merged I think
the PCI ID issue needs to be resolved.

> For the Marvell PCIe code, I've used your emulated Host bridge, and
> added an emulated PCI-to-PCI bridge implementation, in order to get the
> following hierarchy:
> 
>  + Host Bridge
>+ PCI-to-PCI bridge
>  + PCI Device
>+ PCI-to-PCI bridge
>  + PCI device
> 
> So, I instantiate one unique emulated Host Bridge, and then one
> emulated PCI-to-PCI Bridge for each PCIe interface that I have.

Oh dear, that's even worse than on Tegra. The Marvell hardware doesn't
even expose the root ports as PCI devices on the bus?

> The nice thing about that is that I can then read the configuration
> space of the PCI-to-PCI bridge to find out how much I/O space and
> memory space is needed for the device connected to this interface, and
> at which address is has been mapped. This greatly helps my "address
> decoding" problem, and removes the ad-hoc virtual space allocator I had
> written.
> 
> Is there a reason for having given up on this idea? Is there still a
> hope for a different PCIe implementation to use this idea?

I suppose that in your case it really makes sense because you already
need the emulated PCI-to-PCI bridges and therefore adding an emulated
host bridge doesn't add much. As I said, for Tegra everything still
works without, so I didn't see a reason to add needless code.

Thierry


pgpb8owggtbnV.pgp
Description: PGP signature


Re: [PATCH 00/14] Rewrite Tegra PCIe driver

2013-01-09 Thread Thomas Petazzoni
Dear Thierry Reding,

On Wed,  9 Jan 2013 21:43:00 +0100, Thierry Reding wrote:
> This patch series contains an almost complete rewrite of the Tegra PCIe
> driver. The code is moved to the drivers/pci/host directory and turned
> into a proper platform driver, adding MSI and DT support while at it.
> Other PCI host controller drivers can be added to that directory in an
> attempt to make it easier to factor out common code.

Thanks!

I have started basing the Marvell PCIe code on some of your earlier
versions. But apparently in this final version, you no longer have the
emulated Host bridge. Why so?

For the Marvell PCIe code, I've used your emulated Host bridge, and
added an emulated PCI-to-PCI bridge implementation, in order to get the
following hierarchy:

 + Host Bridge
   + PCI-to-PCI bridge
 + PCI Device
   + PCI-to-PCI bridge
 + PCI device

So, I instantiate one unique emulated Host Bridge, and then one
emulated PCI-to-PCI Bridge for each PCIe interface that I have.

The nice thing about that is that I can then read the configuration
space of the PCI-to-PCI bridge to find out how much I/O space and
memory space is needed for the device connected to this interface, and
at which address is has been mapped. This greatly helps my "address
decoding" problem, and removes the ad-hoc virtual space allocator I had
written.

Is there a reason for having given up on this idea? Is there still a
hope for a different PCIe implementation to use this idea?

Thanks,

Thomas
-- 
Thomas Petazzoni, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com
--
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/


[PATCH 00/14] Rewrite Tegra PCIe driver

2013-01-09 Thread Thierry Reding
This patch series contains an almost complete rewrite of the Tegra PCIe
driver. The code is moved to the drivers/pci/host directory and turned
into a proper platform driver, adding MSI and DT support while at it.
Other PCI host controller drivers can be added to that directory in an
attempt to make it easier to factor out common code.

Patches 1 to 4 add generic OF helpers to parse a PCI node's ranges
property as well as obtain the bus, device and function numbers from a
node's reg property.

Patch 5 provides an implementation of a cache for I/O mappings. This can
be used in situations where a large physical memory region needs to be
ioremap()'ed. On Tegra, the PCIe standard and extended configuration
spaces can be accessed through a 256 MiB window. Mapping that in one
chunk is wasteful and may not always work because the vmalloc area may
not be large enough. The implementation in this patch uses an LRU based
approach to map a limited amount of pages on an as-needed basis.

Patches 6 and 7 prepare the ARM PCI code to enable PCI host controller
drivers to load after the init stage, which can happen due to deferred
probing, and to allow private data to be passed for each controller.

Patches 8 and 9 move some of the Tegra specific code around to allow it
to be used from outside the arch/arm/mach-tegra directory.

Patch 10 moves the Tegra PCIe controller driver to the drivers/pci/host
directory and turns it into a proper platform driver. It also adds MSI
(based on patches by NVIDIA) and DT support.

Patches 11 to 14 add device tree based probing for the TEC, Harmony and
TrimSlice boards.

Thierry

Andrew Murray (1):
  of/pci: Provide support for parsing PCI DT ranges property

Thierry Reding (13):
  of/pci: Add of_pci_get_devfn() function
  of/pci: Add of_pci_get_bus() function
  of/pci: Add of_pci_parse_bus_range() function
  lib: Add I/O map cache implementation
  ARM: pci: Keep pci_common_init() around after init
  ARM: pci: Allow passing per-controller private data
  ARM: tegra: Move tegra_pcie_xclk_clamp() to PMC
  ARM: tegra: Move pmc.h to include/mach
  PCI: tegra: Move PCIe driver to drivers/pci/host
  ARM: tegra: tamonten: Add PCIe support
  ARM: tegra: tec: Add PCIe support
  ARM: tegra: harmony: Initialize PCIe from DT
  ARM: tegra: trimslice: Initialize PCIe from DT

 .../bindings/pci/nvidia,tegra20-pcie.txt   |  115 ++
 arch/arm/Kconfig   |2 +
 arch/arm/boot/dts/tegra20-harmony.dts  |   20 +-
 arch/arm/boot/dts/tegra20-tamonten.dtsi|2 +-
 arch/arm/boot/dts/tegra20-tec.dts  |  198 +++
 arch/arm/boot/dts/tegra20-trimslice.dts|   12 +
 arch/arm/boot/dts/tegra20.dtsi |   45 +
 arch/arm/include/asm/mach/pci.h|1 +
 arch/arm/kernel/bios32.c   |9 +-
 arch/arm/mach-tegra/Kconfig|5 -
 arch/arm/mach-tegra/Makefile   |3 -
 arch/arm/mach-tegra/board-dt-tegra20.c |   24 -
 arch/arm/mach-tegra/board-harmony-pcie.c   |   84 --
 arch/arm/mach-tegra/board.h|4 +-
 arch/arm/mach-tegra/common.c   |2 +-
 arch/arm/mach-tegra/include/mach/pmc.h |   24 +
 arch/arm/mach-tegra/iomap.h|3 -
 arch/arm/mach-tegra/pcie.c |  887 -
 arch/arm/mach-tegra/pmc.c  |   16 +
 arch/arm/mach-tegra/pmc.h  |   23 -
 drivers/of/address.c   |   63 +
 drivers/of/of_pci.c|   78 +-
 drivers/pci/Kconfig|2 +
 drivers/pci/Makefile   |3 +
 drivers/pci/host/Kconfig   |8 +
 drivers/pci/host/Makefile  |1 +
 drivers/pci/host/pci-tegra.c   | 1322 
 include/linux/io.h |   12 +
 include/linux/of_address.h |9 +
 include/linux/of_pci.h |3 +
 lib/ioremap.c  |  266 
 31 files changed, 2203 insertions(+), 1043 deletions(-)
 create mode 100644 
Documentation/devicetree/bindings/pci/nvidia,tegra20-pcie.txt
 delete mode 100644 arch/arm/mach-tegra/board-harmony-pcie.c
 create mode 100644 arch/arm/mach-tegra/include/mach/pmc.h
 delete mode 100644 arch/arm/mach-tegra/pcie.c
 delete mode 100644 arch/arm/mach-tegra/pmc.h
 create mode 100644 drivers/pci/host/Kconfig
 create mode 100644 drivers/pci/host/Makefile
 create mode 100644 drivers/pci/host/pci-tegra.c

-- 
1.8.1

--
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  

[PATCH 00/14] Rewrite Tegra PCIe driver

2013-01-09 Thread Thierry Reding
This patch series contains an almost complete rewrite of the Tegra PCIe
driver. The code is moved to the drivers/pci/host directory and turned
into a proper platform driver, adding MSI and DT support while at it.
Other PCI host controller drivers can be added to that directory in an
attempt to make it easier to factor out common code.

Patches 1 to 4 add generic OF helpers to parse a PCI node's ranges
property as well as obtain the bus, device and function numbers from a
node's reg property.

Patch 5 provides an implementation of a cache for I/O mappings. This can
be used in situations where a large physical memory region needs to be
ioremap()'ed. On Tegra, the PCIe standard and extended configuration
spaces can be accessed through a 256 MiB window. Mapping that in one
chunk is wasteful and may not always work because the vmalloc area may
not be large enough. The implementation in this patch uses an LRU based
approach to map a limited amount of pages on an as-needed basis.

Patches 6 and 7 prepare the ARM PCI code to enable PCI host controller
drivers to load after the init stage, which can happen due to deferred
probing, and to allow private data to be passed for each controller.

Patches 8 and 9 move some of the Tegra specific code around to allow it
to be used from outside the arch/arm/mach-tegra directory.

Patch 10 moves the Tegra PCIe controller driver to the drivers/pci/host
directory and turns it into a proper platform driver. It also adds MSI
(based on patches by NVIDIA) and DT support.

Patches 11 to 14 add device tree based probing for the TEC, Harmony and
TrimSlice boards.

Thierry

Andrew Murray (1):
  of/pci: Provide support for parsing PCI DT ranges property

Thierry Reding (13):
  of/pci: Add of_pci_get_devfn() function
  of/pci: Add of_pci_get_bus() function
  of/pci: Add of_pci_parse_bus_range() function
  lib: Add I/O map cache implementation
  ARM: pci: Keep pci_common_init() around after init
  ARM: pci: Allow passing per-controller private data
  ARM: tegra: Move tegra_pcie_xclk_clamp() to PMC
  ARM: tegra: Move pmc.h to include/mach
  PCI: tegra: Move PCIe driver to drivers/pci/host
  ARM: tegra: tamonten: Add PCIe support
  ARM: tegra: tec: Add PCIe support
  ARM: tegra: harmony: Initialize PCIe from DT
  ARM: tegra: trimslice: Initialize PCIe from DT

 .../bindings/pci/nvidia,tegra20-pcie.txt   |  115 ++
 arch/arm/Kconfig   |2 +
 arch/arm/boot/dts/tegra20-harmony.dts  |   20 +-
 arch/arm/boot/dts/tegra20-tamonten.dtsi|2 +-
 arch/arm/boot/dts/tegra20-tec.dts  |  198 +++
 arch/arm/boot/dts/tegra20-trimslice.dts|   12 +
 arch/arm/boot/dts/tegra20.dtsi |   45 +
 arch/arm/include/asm/mach/pci.h|1 +
 arch/arm/kernel/bios32.c   |9 +-
 arch/arm/mach-tegra/Kconfig|5 -
 arch/arm/mach-tegra/Makefile   |3 -
 arch/arm/mach-tegra/board-dt-tegra20.c |   24 -
 arch/arm/mach-tegra/board-harmony-pcie.c   |   84 --
 arch/arm/mach-tegra/board.h|4 +-
 arch/arm/mach-tegra/common.c   |2 +-
 arch/arm/mach-tegra/include/mach/pmc.h |   24 +
 arch/arm/mach-tegra/iomap.h|3 -
 arch/arm/mach-tegra/pcie.c |  887 -
 arch/arm/mach-tegra/pmc.c  |   16 +
 arch/arm/mach-tegra/pmc.h  |   23 -
 drivers/of/address.c   |   63 +
 drivers/of/of_pci.c|   78 +-
 drivers/pci/Kconfig|2 +
 drivers/pci/Makefile   |3 +
 drivers/pci/host/Kconfig   |8 +
 drivers/pci/host/Makefile  |1 +
 drivers/pci/host/pci-tegra.c   | 1322 
 include/linux/io.h |   12 +
 include/linux/of_address.h |9 +
 include/linux/of_pci.h |3 +
 lib/ioremap.c  |  266 
 31 files changed, 2203 insertions(+), 1043 deletions(-)
 create mode 100644 
Documentation/devicetree/bindings/pci/nvidia,tegra20-pcie.txt
 delete mode 100644 arch/arm/mach-tegra/board-harmony-pcie.c
 create mode 100644 arch/arm/mach-tegra/include/mach/pmc.h
 delete mode 100644 arch/arm/mach-tegra/pcie.c
 delete mode 100644 arch/arm/mach-tegra/pmc.h
 create mode 100644 drivers/pci/host/Kconfig
 create mode 100644 drivers/pci/host/Makefile
 create mode 100644 drivers/pci/host/pci-tegra.c

-- 
1.8.1

--
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  

Re: [PATCH 00/14] Rewrite Tegra PCIe driver

2013-01-09 Thread Thomas Petazzoni
Dear Thierry Reding,

On Wed,  9 Jan 2013 21:43:00 +0100, Thierry Reding wrote:
 This patch series contains an almost complete rewrite of the Tegra PCIe
 driver. The code is moved to the drivers/pci/host directory and turned
 into a proper platform driver, adding MSI and DT support while at it.
 Other PCI host controller drivers can be added to that directory in an
 attempt to make it easier to factor out common code.

Thanks!

I have started basing the Marvell PCIe code on some of your earlier
versions. But apparently in this final version, you no longer have the
emulated Host bridge. Why so?

For the Marvell PCIe code, I've used your emulated Host bridge, and
added an emulated PCI-to-PCI bridge implementation, in order to get the
following hierarchy:

 + Host Bridge
   + PCI-to-PCI bridge
 + PCI Device
   + PCI-to-PCI bridge
 + PCI device

So, I instantiate one unique emulated Host Bridge, and then one
emulated PCI-to-PCI Bridge for each PCIe interface that I have.

The nice thing about that is that I can then read the configuration
space of the PCI-to-PCI bridge to find out how much I/O space and
memory space is needed for the device connected to this interface, and
at which address is has been mapped. This greatly helps my address
decoding problem, and removes the ad-hoc virtual space allocator I had
written.

Is there a reason for having given up on this idea? Is there still a
hope for a different PCIe implementation to use this idea?

Thanks,

Thomas
-- 
Thomas Petazzoni, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: [PATCH 00/14] Rewrite Tegra PCIe driver

2013-01-09 Thread Thierry Reding
On Wed, Jan 09, 2013 at 10:25:17PM +0100, Thomas Petazzoni wrote:
 Dear Thierry Reding,
 
 On Wed,  9 Jan 2013 21:43:00 +0100, Thierry Reding wrote:
  This patch series contains an almost complete rewrite of the Tegra PCIe
  driver. The code is moved to the drivers/pci/host directory and turned
  into a proper platform driver, adding MSI and DT support while at it.
  Other PCI host controller drivers can be added to that directory in an
  attempt to make it easier to factor out common code.
 
 Thanks!
 
 I have started basing the Marvell PCIe code on some of your earlier
 versions. But apparently in this final version, you no longer have the
 emulated Host bridge. Why so?

The reason is that with the latest bindings the matching of root ports
to device tree nodes works as-is and nothing else indicates that the
emulated host bridge is actually required to make any of this work. So
in order not to introduce unneeded code I've left it out for now. If
somebody decides that we actually need this host bridge (for standards
compliance or whatnot) it could easily be added back.

However, before the emulated bridge implementation can be merged I think
the PCI ID issue needs to be resolved.

 For the Marvell PCIe code, I've used your emulated Host bridge, and
 added an emulated PCI-to-PCI bridge implementation, in order to get the
 following hierarchy:
 
  + Host Bridge
+ PCI-to-PCI bridge
  + PCI Device
+ PCI-to-PCI bridge
  + PCI device
 
 So, I instantiate one unique emulated Host Bridge, and then one
 emulated PCI-to-PCI Bridge for each PCIe interface that I have.

Oh dear, that's even worse than on Tegra. The Marvell hardware doesn't
even expose the root ports as PCI devices on the bus?

 The nice thing about that is that I can then read the configuration
 space of the PCI-to-PCI bridge to find out how much I/O space and
 memory space is needed for the device connected to this interface, and
 at which address is has been mapped. This greatly helps my address
 decoding problem, and removes the ad-hoc virtual space allocator I had
 written.
 
 Is there a reason for having given up on this idea? Is there still a
 hope for a different PCIe implementation to use this idea?

I suppose that in your case it really makes sense because you already
need the emulated PCI-to-PCI bridges and therefore adding an emulated
host bridge doesn't add much. As I said, for Tegra everything still
works without, so I didn't see a reason to add needless code.

Thierry


pgpb8owggtbnV.pgp
Description: PGP signature