Re: [PATCH v2] MAINTAINERS: Add DesignWare, i.MX6, Armada, R-Car PCI host maintainers
Dear Bjorn Helgaas, On Thu, 12 Dec 2013 13:46:10 -0700, Bjorn Helgaas wrote: [+cc Thomas] On Wed, Dec 11, 2013 at 11:32:37AM -0700, Bjorn Helgaas wrote: If this looks reasonable, I'll merge it via the PCI tree for v3.13. OK, here's another try. I'm not actually trying to nominate anybody; I just tried to write down the list we came up with in an earlier discussion [1]. I'd like confirmation from the following people that they approve of being listed here: Richard Zhu (IMX6) Thomas Petazzoni (MVEBU) Magnus Damm (R-CAR) I think everybody else listed has already said they approve. [1] http://lkml.kernel.org/r/CAErSpo5tN==4nsv2u3sube_l4vswn4p7tn+ltrc172qj1vh...@mail.gmail.com MAINTAINERS: Add DesignWare, i.MX6, Armada, R-Car PCI host maintainers From: Bjorn Helgaas bhelg...@google.com Add entries for PCI host controller drivers in drivers/pci/host/. Signed-off-by: Mohit Kumar mohit.ku...@st.com (DesignWare) Signed-off-by: Pratyush Anand pratyush.an...@st.com (DesignWare) Signed-off-by: Bjorn Helgaas bhelg...@google.com Acked-by: Simon Horman horms+rene...@verge.net.au (R-CAR) Acked-by: Jason Cooper ja...@lakedaemon.net (MVEBU) Acked-by: Jingoo Han jg1@samsung.com Acked-by: Thierry Reding tred...@nvidia.com --- MAINTAINERS | 34 ++ 1 file changed, 34 insertions(+) diff --git a/MAINTAINERS b/MAINTAINERS index 8285ed4676b6..1c5dc36ec522 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -6449,19 +6449,53 @@ F:drivers/pci/ F: include/linux/pci* F: arch/x86/pci/ +PCI DRIVER FOR IMX6 +M: Richard Zhu r65...@freescale.com +M: Shawn Guo shawn@linaro.org +L: linux-...@vger.kernel.org +L: linux-arm-ker...@lists.infradead.org (moderated for non-subscribers) +S: Maintained +F: drivers/pci/host/*imx6* + +PCI DRIVER FOR MVEBU (Marvell Armada 370 and Armada XP SOC support) +M: Thomas Petazzoni thomas.petazz...@free-electrons.com +M: Jason Cooper ja...@lakedaemon.net +L: linux-...@vger.kernel.org +L: linux-arm-ker...@lists.infradead.org (moderated for non-subscribers) +S: Maintained +F: drivers/pci/host/*mvebu* Acked-by: Thomas Petazzoni thomas.petazz...@free-electrons.com Thanks for doing this! Best regards, Thomas -- Thomas Petazzoni, CTO, Free Electrons Embedded Linux, Kernel and Android engineering http://free-electrons.com -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc 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 0/4] PCIe support for Samsung Exynos5440 SoC
Dear Arnd Bergmann, On Fri, 21 Jun 2013 09:31:58 +0200, Arnd Bergmann wrote: Bjorn, are you still considering to merge this for 3.11 or have you closed your tree for the merge window? I think it would be good to get it in. Note that the of/pci changes needed for this driver are merged through the arm-soc tree, with the of maintainers ACKs. They are already in arm-soc for-next, through Jason Cooper's tree. 4e23d3f505e8acfeac7cc33d4113fbb5a25c3090 of/pci: Add of_pci_parse_bus_range() function 45ab9702fb47d18dca116b3a0509efa19fbcb27a of/pci: Add of_pci_get_devfn() function 29b635c00f3ebcdaf7a52c4948f6d948ad3757d3 of/pci: Provide support for parsing PCI DT ranges property Also, it depends on the Marvell PCIe driver (but to a lesser extent), which is the one that creates the drivers/pci/host/Kconfig and drivers/pci/host/Makefile. 45361a4fe4464180815157654aabbd2afb4848ad pci: PCIe driver for Marvell Armada 370/XP systems I am by far not an expert on how to solve merge strategies and so on, but to avoid conflicts at Linus's level while merging the arm-soc and pci trees, it would be better if this Samsung PCIe driver could go through arm-soc (with Bjorn ACK, of course), so that Arnd/Olof can make sure the ordering is correct with regard to the of/pci changes and the mvebu/pci driver. I'll let you discuss that with Jason Cooper. Best regards, 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-samsung-soc 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 3/3] ARM: dts: Add pcie controller node for Samsung EXYNOS5440 SoC
Dear Jingoo Han,
On Thu, 20 Jun 2013 16:12:24 +0900, Jingoo Han wrote:
- pinctrl {
+ pin_ctrl: pinctrl {
compatible = samsung,exynos5440-pinctrl;
I know I'm nitpicking, but isn't this change completely unrelated to
PCIe support?
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-samsung-soc 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 3/3] ARM: dts: Add pcie controller node for Samsung EXYNOS5440 SoC
Dear Jingoo Han,
On Thu, 20 Jun 2013 16:57:32 +0900, Jingoo Han wrote:
- pinctrl {
+ pin_ctrl: pinctrl {
compatible = samsung,exynos5440-pinctrl;
I know I'm nitpicking, but isn't this change completely unrelated to
PCIe support?
This change is related to PCIe support.
Without this, I cannot use gpio binding.
This change was guided by Thomas Abraham (Author of Samsung pinctrl).
Also, it was confirmed by Kukjin Kim (Maintainer of Samsung SoC).
Thank you for your caring. :)
I mean, the change is fine for sure, but it should maybe part of a
separate patch as it is more a fix than really the introduction of the
PCIe controller node, as the patch title suggests. This would also for
example allow this fix to be merged right now (for 3.11), regardless of
what happens for the rest of your PCIe patches.
Best regards,
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-samsung-soc 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 1/3] of/pci: Unify pci_process_bridge_OF_ranges from Microblaze and PowerPC
Michal, Ben,
Would you have some time to look at this patch and give your comments
and/or ACK ? Since it touches the PowerPC and Microblaze core code, we
need your agreement to merge this code, and quite a bit of code pending
for 3.10 depends on this patch.
Rob, alternatively, could we imagine doing a different version of the
'of/pci: Provide support for parsing PCI DT ranges property' that
introduces the new API only, leaving the PowerPC and Microblaze rework
as follow-up efforts, so that all the PCIe drivers that depend on this
patch can get in for 3.10 ? I'd find it pretty sad if the Marvell PCIe
driver that has been worked on since 4+ months does not get into 3.10
just because this patch cannot be merged.
Thanks!
Thomas
On Thu, 11 Apr 2013 16:26:07 +0100, Andrew Murray wrote:
The pci_process_bridge_OF_ranges function, used to parse the ranges
property of a PCI host device, is found in both Microblaze and PowerPC
architectures. These implementations are nearly identical. This patch
moves this common code to a common place.
Signed-off-by: Andrew Murray andrew.mur...@arm.com
Signed-off-by: Liviu Dudau liviu.du...@arm.com
Reviewed-by: Rob Herring rob.herr...@calxeda.com
Tested-by: Thomas Petazzoni thomas.petazz...@free-electrons.com
---
arch/microblaze/include/asm/pci-bridge.h |5 +-
arch/microblaze/pci/pci-common.c | 192
arch/powerpc/include/asm/pci-bridge.h|5 +-
arch/powerpc/kernel/pci-common.c | 192
drivers/of/of_pci.c | 200
++
include/linux/of_pci.h |4 +
6 files changed, 206 insertions(+), 392 deletions(-)
diff --git a/arch/microblaze/include/asm/pci-bridge.h
b/arch/microblaze/include/asm/pci-bridge.h
index cb5d397..5783cd6 100644
--- a/arch/microblaze/include/asm/pci-bridge.h
+++ b/arch/microblaze/include/asm/pci-bridge.h
@@ -10,6 +10,7 @@
#include linux/pci.h
#include linux/list.h
#include linux/ioport.h
+#include linux/of_pci.h
struct device_node;
@@ -132,10 +133,6 @@ extern void setup_indirect_pci(struct pci_controller
*hose,
extern struct pci_controller *pci_find_hose_for_OF_device(
struct device_node *node);
-/* Fill up host controller resources from the OF node */
-extern void pci_process_bridge_OF_ranges(struct pci_controller *hose,
- struct device_node *dev, int primary);
-
/* Allocate free a PCI host bridge structure */
extern struct pci_controller *pcibios_alloc_controller(struct device_node
*dev);
extern void pcibios_free_controller(struct pci_controller *phb);
diff --git a/arch/microblaze/pci/pci-common.c
b/arch/microblaze/pci/pci-common.c
index 9ea521e..2735ad9 100644
--- a/arch/microblaze/pci/pci-common.c
+++ b/arch/microblaze/pci/pci-common.c
@@ -622,198 +622,6 @@ void pci_resource_to_user(const struct pci_dev *dev,
int bar,
*end = rsrc-end - offset;
}
-/**
- * pci_process_bridge_OF_ranges - Parse PCI bridge resources from device tree
- * @hose: newly allocated pci_controller to be setup
- * @dev: device node of the host bridge
- * @primary: set if primary bus (32 bits only, soon to be deprecated)
- *
- * This function will parse the ranges property of a PCI host bridge device
- * node and setup the resource mapping of a pci controller based on its
- * content.
- *
- * Life would be boring if it wasn't for a few issues that we have to deal
- * with here:
- *
- * - We can only cope with one IO space range and up to 3 Memory space
- * ranges. However, some machines (thanks Apple !) tend to split their
- * space into lots of small contiguous ranges. So we have to coalesce.
- *
- * - We can only cope with all memory ranges having the same offset
- * between CPU addresses and PCI addresses. Unfortunately, some bridges
- * are setup for a large 1:1 mapping along with a small window which
- * maps PCI address 0 to some arbitrary high address of the CPU space in
- * order to give access to the ISA memory hole.
- * The way out of here that I've chosen for now is to always set the
- * offset based on the first resource found, then override it if we
- * have a different offset and the previous was set by an ISA hole.
- *
- * - Some busses have IO space not starting at 0, which causes trouble with
- * the way we do our IO resource renumbering. The code somewhat deals
with
- * it for 64 bits but I would expect problems on 32 bits.
- *
- * - Some 32 bits platforms such as 4xx can have physical space larger than
- * 32 bits so we need to use 64 bits values for the parsing
- */
-void pci_process_bridge_OF_ranges(struct pci_controller *hose,
- struct device_node *dev, int primary)
-{
- const u32 *ranges;
- int rlen;
- int pna = of_n_addr_cells(dev);
- int np = pna
Re: [PATCH v5 1/3] of/pci: Unify pci_process_bridge_OF_ranges from Microblaze and PowerPC
Ben, Michal, On Wed, 10 Apr 2013 08:13:54 -0500, Rob Herring wrote: Adding Ben H and Michal... On 04/10/2013 02:29 AM, Andrew Murray wrote: The pci_process_bridge_OF_ranges function, used to parse the ranges property of a PCI host device, is found in both Microblaze and PowerPC architectures. These implementations are nearly identical. This patch moves this common code to a common place. Signed-off-by: Andrew Murray andrew.mur...@arm.com Signed-off-by: Liviu Dudau liviu.du...@arm.com One comment below. Otherwise, Reviewed-by: Rob Herring rob.herr...@calxeda.com You need also need acks from Ben and Michal. Ben, Michal, could you review/test this patch from Andrew Murray? I need it as a dependency of [PATCH v5 2/3] of/pci: Provide support for parsing PCI DT ranges property, which itself is used by the Marvell PCIe driver I'm hoping to get merged in 3.10. Thanks a lot for your feedback, 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-samsung-soc 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 1/3] of/pci: Unify pci_process_bridge_OF_ranges from Microblaze and PowerPC
Dear Andrew Murray, On Wed, 10 Apr 2013 08:29:26 +0100, Andrew Murray wrote: diff --git a/include/linux/of_pci.h b/include/linux/of_pci.h index bb115de..6852481 100644 --- a/include/linux/of_pci.h +++ b/include/linux/of_pci.h @@ -11,4 +11,7 @@ struct device_node; struct device_node *of_pci_find_child_device(struct device_node *parent, unsigned int devfn); +void pci_process_bridge_OF_ranges(struct pci_controller *hose, + struct device_node *dev, int primary); + #endif In this file, 'struct pci_controller' is not defined anywhere, and not in any header file that is included. So I get a warning at compile time when linux/of_pci.h is included, but nothing has defined 'struct pci_controller' beforehand. So I think this file should carry a change like: +struct pci_controller; In my version of the patch I added it, see: diff --git a/include/linux/of_pci.h b/include/linux/of_pci.h index bb115de..e56182f 100644 --- a/include/linux/of_pci.h +++ b/include/linux/of_pci.h @@ -4,6 +4,7 @@ #include linux/pci.h struct pci_dev; +struct pci_controller; struct of_irq; int of_irq_map_pci(const struct pci_dev *pdev, struct of_irq *out_irq); @@ -11,4 +12,7 @@ struct device_node; struct device_node *of_pci_find_child_device(struct device_node *parent, unsigned int devfn); +void pci_process_bridge_OF_ranges(struct pci_controller *hose, + struct device_node *dev, int primary); + #endif But otherwise, for PATCH 1/3 and 2/3, Tested-by: Thomas Petazzoni thomas.petazz...@free-electrons.com 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-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/6] of/pci: Provide support for parsing PCI DT ranges property
On Sat, 23 Mar 2013 10:41:56 +, Russell King - ARM Linux wrote:
Please look at how IORESOURCE_* stuff is defined:
#define IORESOURCE_TYPE_BITS0x1f00 /* Resource type */
#define IORESOURCE_IO 0x0100 /* PCI/ISA I/O ports */
#define IORESOURCE_MEM 0x0200
#define IORESOURCE_REG 0x0300 /* Register offsets */
#define IORESOURCE_IRQ 0x0400
#define IORESOURCE_DMA 0x0800
#define IORESOURCE_BUS 0x1000
Notice that it's not an array of bits.
So this should be:
if ((iter.flags IORESOURCE_TYPE_BITS) == IORESOURCE_IO) {
What I've done for the Marvell PCIe driver is:
+ for_each_of_pci_range(iter, np) {
+ unsigned long restype = iter.flags IORESOURCE_TYPE_BITS;
+ if (restype == IORESOURCE_IO) {
[...]
+ if (restype == IORESOURCE_MEM) {
[...]
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-samsung-soc in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/2] ARM: EXYNOS: Add PCIe driver support
Dear Thomas Abraham, On Mon, 4 Mar 2013 16:01:59 +0530, Thomas Abraham wrote: On 4 March 2013 15:52, Jingoo Han jg1@samsung.com wrote: Exynos5440 has two PCIe controllers which can be used as Root Complex. This driver supports the PCIe controllers as Root Complex mode. Signed-off-by: Surendranath Gurivireddy Balla suren.re...@samsung.com Signed-off-by: Siva Reddy Kallam siva.kal...@samsung.com Signed-off-by: Jingoo Han jg1@samsung.com --- .../devicetree/bindings/pci/exynos-pcie.txt| 58 ++ arch/arm/Kconfig |2 + arch/arm/mach-exynos/Kconfig |8 + arch/arm/mach-exynos/Makefile |2 + arch/arm/mach-exynos/include/mach/pcie.h | 146 +++ arch/arm/mach-exynos/pcie.c| 1009 Is there any reason to place this code in arch/arm/...? As you know, there is a constant effort to relocate as much code as possible from arch/arm/mach-exynos. So there must be a strong justification for keeping this code in arch/arm/mach-exynos. Indeed. Thierry Reding (doing the Tegra PCIe driver) and myself (doing the Marvell PCIe driver) are putting our drivers in drivers/pci/host/, in agreement with the PCI maintainers. 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-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
