Re: [RFC PATCH 1/3] pci: APM X-Gene PCIe controller driver
On Tue, Jan 7, 2014 at 1:27 AM, Arnd Bergmann wrote:
> On Tuesday 07 January 2014, Tanmay Inamdar wrote:
>> > Also, the implementation is wrong since the I/O port range already needs
>> > to be ioremapped in order for inb/outb to work. There is already a
>> > generic implementation of this in include/asm-generic/iomap.h, which
>> > correctly calls ioport_map. Make sure that arm64 uses this implementation
>> > and provides an ioport_map() function like
>> >
>> > static inline void __iomem *ioport_map(unsigned long port, unsigned int nr)
>> > {
>> > return PCI_IOBASE + port;
>> > }
>>
>> For X-Gene, IO regions are memory mapped IO regions. So I am not sure
>> if 'ioport_map'
>> would work.
>
> It should. In fact all ARM and ARM64 platforms I have seen (and most powerpc
> ones) have their IO region memory mapped. The way we handle this in Linux
> is to map the IO space to a fixed virtual address at the time the host
> controller is initialized, and all accesses to an IO port translate to
> a access in this virtual address. See the inb()/outb() implementation on
> arm and arm64, as well as the arm pci_ioremap_io() function for more
> details.
>
Yes. arm64 has to support pci_ioremap_io and pci_iomap in order to
support IO regions. Thanks.
>> >> +static void xgene_pcie_setup_lanes(struct xgene_pcie_port *port)
>> >> +{
>> >> + void *csr_base = port->csr_base;
>> >> + u32 val;
>> >> +
>> > ...
>> >> +static void xgene_pcie_setup_link(struct xgene_pcie_port *port)
>> >> +{
>> >> + void *csr_base = port->csr_base;
>> >> + u32 val;
>> >> +
>> >
>> > Don't these belong into the PHY driver? Can the setup be done in the
>> > firmware instead so we don't have to bother with it in Linux?
>> > Presumably you already need PCI support at boot time already if
>> > you want to boot from a PCI device.
>>
>> They do look like phy setup functions but they are part of PCIe core
>> register space.
>
> Ok.
>
>> >> +static void xgene_pcie_config_pims(void *csr_base, u32 addr,
>> >> +u64 pim, resource_size_t size)
>> >> +{
>> >> + u32 val;
>> >> +
>> >> + xgene_pcie_out32(csr_base + addr, lower_32_bits(pim));
>> >> + val = upper_32_bits(pim) | EN_COHERENCY;
>> >> + xgene_pcie_out32(csr_base + addr + 0x04, val);
>> >> + xgene_pcie_out32(csr_base + addr + 0x08, 0x0);
>> >> + xgene_pcie_out32(csr_base + addr + 0x0c, 0x0);
>> >> + val = lower_32_bits(size);
>> >> + xgene_pcie_out32(csr_base + addr + 0x10, val);
>> >> + val = upper_32_bits(size);
>> >> + xgene_pcie_out32(csr_base + addr + 0x14, val);
>> >> +}
>> >
>> > I suspect this is for programming the inbound translation window for
>> > DMA transactions (maybe add a comment?), and the second 64-bit word is
>> > for the bus-side address. Are you sure you want a translation starting
>> > at zero, rather than an identity-mapping like this?
>>
>> Actually it is an unused sub-region. I will remove setting to 0. It
>> defaults to 0 anyways.
>
> Is it always an identity-mapping then?
>
Yes.
>> >> +struct device_node *pcibios_get_phb_of_node(struct pci_bus *bus)
>> >> +{
>> >> + struct xgene_pcie_port *port = xgene_pcie_bus_to_port(bus);
>> >> +
>> >> + return of_node_get(port->node);
>> >> +}
>> >
>> > Another pointless wrapper to remove.
>>
>> If I remove this, then we get a failure while parsing irqs
>> "pci :00:00.0: of_irq_parse_pci() failed with rc=-22"
>
> I mean it would be just as easy to open-code the function in the
> callers, and more readable.
>
>> >> +static int xgene_pcie_populate_inbound_regions(struct xgene_pcie_port
>> >> *port)
>> >> +{
>> >> + struct resource *msi_res = >res[XGENE_MSI];
>> >> + phys_addr_t ddr_size = memblock_phys_mem_size();
>> >> + phys_addr_t ddr_base = memblock_start_of_DRAM();
>> >
>> > This looks fragile. What about discontiguous memory? It's probably better
>> > to
>> > leave this setup to the firmware, which already has to do it.
>>
>> Idea is to map whole RAM. The memory controller in X-Gene does not
>> allow holes or discontinuity in RAM.
>
> There might be holes in the memory map for other reasons, e.g. some part of
> memory could be reserved for use by a particular piece of software.
> There is actually a definition for a "dma-ranges" property that is normally
> use to communicate this information, i.e. which bus addresses for DMA
> translate into which parent bus (or memory) addresses. I think it would
> be more logical to use that property.
Yes. You are right. We will get more flexibility with this.
>
> Arnd
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC PATCH 1/3] pci: APM X-Gene PCIe controller driver
On Tue, Jan 7, 2014 at 1:27 AM, Arnd Bergmann a...@arndb.de wrote:
On Tuesday 07 January 2014, Tanmay Inamdar wrote:
Also, the implementation is wrong since the I/O port range already needs
to be ioremapped in order for inb/outb to work. There is already a
generic implementation of this in include/asm-generic/iomap.h, which
correctly calls ioport_map. Make sure that arm64 uses this implementation
and provides an ioport_map() function like
static inline void __iomem *ioport_map(unsigned long port, unsigned int nr)
{
return PCI_IOBASE + port;
}
For X-Gene, IO regions are memory mapped IO regions. So I am not sure
if 'ioport_map'
would work.
It should. In fact all ARM and ARM64 platforms I have seen (and most powerpc
ones) have their IO region memory mapped. The way we handle this in Linux
is to map the IO space to a fixed virtual address at the time the host
controller is initialized, and all accesses to an IO port translate to
a access in this virtual address. See the inb()/outb() implementation on
arm and arm64, as well as the arm pci_ioremap_io() function for more
details.
Yes. arm64 has to support pci_ioremap_io and pci_iomap in order to
support IO regions. Thanks.
+static void xgene_pcie_setup_lanes(struct xgene_pcie_port *port)
+{
+ void *csr_base = port-csr_base;
+ u32 val;
+
...
+static void xgene_pcie_setup_link(struct xgene_pcie_port *port)
+{
+ void *csr_base = port-csr_base;
+ u32 val;
+
Don't these belong into the PHY driver? Can the setup be done in the
firmware instead so we don't have to bother with it in Linux?
Presumably you already need PCI support at boot time already if
you want to boot from a PCI device.
They do look like phy setup functions but they are part of PCIe core
register space.
Ok.
+static void xgene_pcie_config_pims(void *csr_base, u32 addr,
+u64 pim, resource_size_t size)
+{
+ u32 val;
+
+ xgene_pcie_out32(csr_base + addr, lower_32_bits(pim));
+ val = upper_32_bits(pim) | EN_COHERENCY;
+ xgene_pcie_out32(csr_base + addr + 0x04, val);
+ xgene_pcie_out32(csr_base + addr + 0x08, 0x0);
+ xgene_pcie_out32(csr_base + addr + 0x0c, 0x0);
+ val = lower_32_bits(size);
+ xgene_pcie_out32(csr_base + addr + 0x10, val);
+ val = upper_32_bits(size);
+ xgene_pcie_out32(csr_base + addr + 0x14, val);
+}
I suspect this is for programming the inbound translation window for
DMA transactions (maybe add a comment?), and the second 64-bit word is
for the bus-side address. Are you sure you want a translation starting
at zero, rather than an identity-mapping like this?
Actually it is an unused sub-region. I will remove setting to 0. It
defaults to 0 anyways.
Is it always an identity-mapping then?
Yes.
+struct device_node *pcibios_get_phb_of_node(struct pci_bus *bus)
+{
+ struct xgene_pcie_port *port = xgene_pcie_bus_to_port(bus);
+
+ return of_node_get(port-node);
+}
Another pointless wrapper to remove.
If I remove this, then we get a failure while parsing irqs
pci :00:00.0: of_irq_parse_pci() failed with rc=-22
I mean it would be just as easy to open-code the function in the
callers, and more readable.
+static int xgene_pcie_populate_inbound_regions(struct xgene_pcie_port
*port)
+{
+ struct resource *msi_res = port-res[XGENE_MSI];
+ phys_addr_t ddr_size = memblock_phys_mem_size();
+ phys_addr_t ddr_base = memblock_start_of_DRAM();
This looks fragile. What about discontiguous memory? It's probably better
to
leave this setup to the firmware, which already has to do it.
Idea is to map whole RAM. The memory controller in X-Gene does not
allow holes or discontinuity in RAM.
There might be holes in the memory map for other reasons, e.g. some part of
memory could be reserved for use by a particular piece of software.
There is actually a definition for a dma-ranges property that is normally
use to communicate this information, i.e. which bus addresses for DMA
translate into which parent bus (or memory) addresses. I think it would
be more logical to use that property.
Yes. You are right. We will get more flexibility with this.
Arnd
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC PATCH 1/3] pci: APM X-Gene PCIe controller driver
On Tuesday 07 January 2014, Tanmay Inamdar wrote:
> > Also, the implementation is wrong since the I/O port range already needs
> > to be ioremapped in order for inb/outb to work. There is already a
> > generic implementation of this in include/asm-generic/iomap.h, which
> > correctly calls ioport_map. Make sure that arm64 uses this implementation
> > and provides an ioport_map() function like
> >
> > static inline void __iomem *ioport_map(unsigned long port, unsigned int nr)
> > {
> > return PCI_IOBASE + port;
> > }
>
> For X-Gene, IO regions are memory mapped IO regions. So I am not sure
> if 'ioport_map'
> would work.
It should. In fact all ARM and ARM64 platforms I have seen (and most powerpc
ones) have their IO region memory mapped. The way we handle this in Linux
is to map the IO space to a fixed virtual address at the time the host
controller is initialized, and all accesses to an IO port translate to
a access in this virtual address. See the inb()/outb() implementation on
arm and arm64, as well as the arm pci_ioremap_io() function for more
details.
> >> +static void xgene_pcie_setup_lanes(struct xgene_pcie_port *port)
> >> +{
> >> + void *csr_base = port->csr_base;
> >> + u32 val;
> >> +
> > ...
> >> +static void xgene_pcie_setup_link(struct xgene_pcie_port *port)
> >> +{
> >> + void *csr_base = port->csr_base;
> >> + u32 val;
> >> +
> >
> > Don't these belong into the PHY driver? Can the setup be done in the
> > firmware instead so we don't have to bother with it in Linux?
> > Presumably you already need PCI support at boot time already if
> > you want to boot from a PCI device.
>
> They do look like phy setup functions but they are part of PCIe core
> register space.
Ok.
> >> +static void xgene_pcie_config_pims(void *csr_base, u32 addr,
> >> +u64 pim, resource_size_t size)
> >> +{
> >> + u32 val;
> >> +
> >> + xgene_pcie_out32(csr_base + addr, lower_32_bits(pim));
> >> + val = upper_32_bits(pim) | EN_COHERENCY;
> >> + xgene_pcie_out32(csr_base + addr + 0x04, val);
> >> + xgene_pcie_out32(csr_base + addr + 0x08, 0x0);
> >> + xgene_pcie_out32(csr_base + addr + 0x0c, 0x0);
> >> + val = lower_32_bits(size);
> >> + xgene_pcie_out32(csr_base + addr + 0x10, val);
> >> + val = upper_32_bits(size);
> >> + xgene_pcie_out32(csr_base + addr + 0x14, val);
> >> +}
> >
> > I suspect this is for programming the inbound translation window for
> > DMA transactions (maybe add a comment?), and the second 64-bit word is
> > for the bus-side address. Are you sure you want a translation starting
> > at zero, rather than an identity-mapping like this?
>
> Actually it is an unused sub-region. I will remove setting to 0. It
> defaults to 0 anyways.
Is it always an identity-mapping then?
> >> +struct device_node *pcibios_get_phb_of_node(struct pci_bus *bus)
> >> +{
> >> + struct xgene_pcie_port *port = xgene_pcie_bus_to_port(bus);
> >> +
> >> + return of_node_get(port->node);
> >> +}
> >
> > Another pointless wrapper to remove.
>
> If I remove this, then we get a failure while parsing irqs
> "pci :00:00.0: of_irq_parse_pci() failed with rc=-22"
I mean it would be just as easy to open-code the function in the
callers, and more readable.
> >> +static int xgene_pcie_populate_inbound_regions(struct xgene_pcie_port
> >> *port)
> >> +{
> >> + struct resource *msi_res = >res[XGENE_MSI];
> >> + phys_addr_t ddr_size = memblock_phys_mem_size();
> >> + phys_addr_t ddr_base = memblock_start_of_DRAM();
> >
> > This looks fragile. What about discontiguous memory? It's probably better to
> > leave this setup to the firmware, which already has to do it.
>
> Idea is to map whole RAM. The memory controller in X-Gene does not
> allow holes or discontinuity in RAM.
There might be holes in the memory map for other reasons, e.g. some part of
memory could be reserved for use by a particular piece of software.
There is actually a definition for a "dma-ranges" property that is normally
use to communicate this information, i.e. which bus addresses for DMA
translate into which parent bus (or memory) addresses. I think it would
be more logical to use that property.
Arnd
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC PATCH 1/3] pci: APM X-Gene PCIe controller driver
On Tuesday 07 January 2014, Tanmay Inamdar wrote:
Also, the implementation is wrong since the I/O port range already needs
to be ioremapped in order for inb/outb to work. There is already a
generic implementation of this in include/asm-generic/iomap.h, which
correctly calls ioport_map. Make sure that arm64 uses this implementation
and provides an ioport_map() function like
static inline void __iomem *ioport_map(unsigned long port, unsigned int nr)
{
return PCI_IOBASE + port;
}
For X-Gene, IO regions are memory mapped IO regions. So I am not sure
if 'ioport_map'
would work.
It should. In fact all ARM and ARM64 platforms I have seen (and most powerpc
ones) have their IO region memory mapped. The way we handle this in Linux
is to map the IO space to a fixed virtual address at the time the host
controller is initialized, and all accesses to an IO port translate to
a access in this virtual address. See the inb()/outb() implementation on
arm and arm64, as well as the arm pci_ioremap_io() function for more
details.
+static void xgene_pcie_setup_lanes(struct xgene_pcie_port *port)
+{
+ void *csr_base = port-csr_base;
+ u32 val;
+
...
+static void xgene_pcie_setup_link(struct xgene_pcie_port *port)
+{
+ void *csr_base = port-csr_base;
+ u32 val;
+
Don't these belong into the PHY driver? Can the setup be done in the
firmware instead so we don't have to bother with it in Linux?
Presumably you already need PCI support at boot time already if
you want to boot from a PCI device.
They do look like phy setup functions but they are part of PCIe core
register space.
Ok.
+static void xgene_pcie_config_pims(void *csr_base, u32 addr,
+u64 pim, resource_size_t size)
+{
+ u32 val;
+
+ xgene_pcie_out32(csr_base + addr, lower_32_bits(pim));
+ val = upper_32_bits(pim) | EN_COHERENCY;
+ xgene_pcie_out32(csr_base + addr + 0x04, val);
+ xgene_pcie_out32(csr_base + addr + 0x08, 0x0);
+ xgene_pcie_out32(csr_base + addr + 0x0c, 0x0);
+ val = lower_32_bits(size);
+ xgene_pcie_out32(csr_base + addr + 0x10, val);
+ val = upper_32_bits(size);
+ xgene_pcie_out32(csr_base + addr + 0x14, val);
+}
I suspect this is for programming the inbound translation window for
DMA transactions (maybe add a comment?), and the second 64-bit word is
for the bus-side address. Are you sure you want a translation starting
at zero, rather than an identity-mapping like this?
Actually it is an unused sub-region. I will remove setting to 0. It
defaults to 0 anyways.
Is it always an identity-mapping then?
+struct device_node *pcibios_get_phb_of_node(struct pci_bus *bus)
+{
+ struct xgene_pcie_port *port = xgene_pcie_bus_to_port(bus);
+
+ return of_node_get(port-node);
+}
Another pointless wrapper to remove.
If I remove this, then we get a failure while parsing irqs
pci :00:00.0: of_irq_parse_pci() failed with rc=-22
I mean it would be just as easy to open-code the function in the
callers, and more readable.
+static int xgene_pcie_populate_inbound_regions(struct xgene_pcie_port
*port)
+{
+ struct resource *msi_res = port-res[XGENE_MSI];
+ phys_addr_t ddr_size = memblock_phys_mem_size();
+ phys_addr_t ddr_base = memblock_start_of_DRAM();
This looks fragile. What about discontiguous memory? It's probably better to
leave this setup to the firmware, which already has to do it.
Idea is to map whole RAM. The memory controller in X-Gene does not
allow holes or discontinuity in RAM.
There might be holes in the memory map for other reasons, e.g. some part of
memory could be reserved for use by a particular piece of software.
There is actually a definition for a dma-ranges property that is normally
use to communicate this information, i.e. which bus addresses for DMA
translate into which parent bus (or memory) addresses. I think it would
be more logical to use that property.
Arnd
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC PATCH 1/3] pci: APM X-Gene PCIe controller driver
On Tuesday, January 07, 2014 11:45 AM, Tanmay Inamdar wrote: > On Sun, Jan 5, 2014 at 5:47 PM, Jingoo Han wrote: > > On Monday, December 23, 2013 5:02 PM, Tanmay Inamdar wrote: > >> > >> This patch adds the AppliedMicro X-gene SOC PCIe controller driver. > >> APM X-Gene PCIe controller supports maximum upto 8 lanes and > >> GEN3 speed. X-Gene has maximum 5 PCIe ports supported. > > > > (+cc Jason Gunthorpe, Arnd Bergmann) > > > > Hi Tanmay Inamdar, > > > > I added some minor comments. :-) > > > >> > >> Signed-off-by: Tanmay Inamdar > >> --- > >> drivers/pci/host/Kconfig |5 + > >> drivers/pci/host/Makefile |1 + > >> drivers/pci/host/pcie-xgene.c | 1017 > >> + > > > > Would you change the file name to 'pci-xgene.c'? > > Now, all PCI host drivers are using the prefix 'pci-', not 'pcie-'. > > I guess designware is an exception. There is > "drivers/pci/host/pcie-designware.c" (+cc Thierry Reding, Pratyush Anand, Mohit KUMAR) Now, the current naming rule is "PCI-" prefix as below. - Samsung Exynos: "pci"-exynos.c - Freescale i.MX6: "pci"-imx6.c - Marvell: pci-mvebu.c - Nvidia Tegra: pci-tegra.c - Renesas R-Car: pci-rcar-gen2.c According to the Thierry Reding's comment, "I think we should keep these sorted alphabetically. Also Tegra and Marvell are PCIe controllers but they still use the pci- prefix instead of pcie-. Perhaps it'd be good to keep consistency here? I initially chose pci- because from a software point of view it doesn't matter all that much whether it's PCI or PCIe and because the drivers are part of the PCI subsystem. However if Exynos now uses the pcie- prefix it makes it look like Tegra and Marvell are plain old PCI." (https://groups.google.com/forum/#!msg/linux.kernel/qtimJoNSc3w/_1aayHaG54YJ) However, "pcie-designware.c" is common layer driver for other SoC PCI host drivers that use Synopsys Designware PCI IP. Thus, currently it is shared by other SoC PCI host drivers such as pci-exynos.c, and pci-imx6.c. Also, ST PCI driver will use pcie-designware.c as common layer. Originally, "pci"-designware.c was used. However, Pratyush Anand suggested "pci"-designware.c can be renamed to "pcie"-designware.c, because Synopsys PCI IP and Synopsys PCI Express IP are different. So, currently "pcie"-designware.c is used. So, if there is no special reason, "pci-" prefix can be used. Thank you. Best regards, Jingoo Han -- 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: [RFC PATCH 1/3] pci: APM X-Gene PCIe controller driver
On Sun, Jan 5, 2014 at 5:47 PM, Jingoo Han wrote:
> On Monday, December 23, 2013 5:02 PM, Tanmay Inamdar wrote:
>>
>> This patch adds the AppliedMicro X-gene SOC PCIe controller driver.
>> APM X-Gene PCIe controller supports maximum upto 8 lanes and
>> GEN3 speed. X-Gene has maximum 5 PCIe ports supported.
>
> (+cc Jason Gunthorpe, Arnd Bergmann)
>
> Hi Tanmay Inamdar,
>
> I added some minor comments. :-)
>
>>
>> Signed-off-by: Tanmay Inamdar
>> ---
>> drivers/pci/host/Kconfig |5 +
>> drivers/pci/host/Makefile |1 +
>> drivers/pci/host/pcie-xgene.c | 1017
>> +
>
> Would you change the file name to 'pci-xgene.c'?
> Now, all PCI host drivers are using the prefix 'pci-', not 'pcie-'.
I guess designware is an exception. There is
"drivers/pci/host/pcie-designware.c"
>
> [.]
>
>> +#include
>> +#include
>> +#include
>> +#include
>> +#include
>> +#include
>> +#include
>> +#include
>> +#include
>> +#include
>> +#include
>> +#include
>> +#include
>
> Would you re-order these headers alphabetically?
> It enhances the readability.
ok.
>
> [.]
>
>> +static int xgene_pcie_parse_map_ranges(struct xgene_pcie_port *port)
>> +{
>> + struct device_node *np = port->node;
>> + struct of_pci_range range;
>> + struct of_pci_range_parser parser;
>> + struct device *dev = port->dev;
>> + u32 cfg_map_done = 0;
>> + int ret;
>> +
>> + if (of_pci_range_parser_init(, np)) {
>> + dev_err(dev, "missing ranges property\n");
>> + return -EINVAL;
>> + }
>> +
>> + /* Get the I/O, memory, config ranges from DT */
>> + for_each_of_pci_range(, ) {
>> + struct resource *res = NULL;
>> + u64 restype = range.flags & IORESOURCE_TYPE_BITS;
>> + u64 end = range.cpu_addr + range.size - 1;
>> + dev_dbg(port->dev, "0x%08x 0x%016llx..0x%016llx ->
>> 0x%016llx\n",
>> + range.flags, range.cpu_addr, end, range.pci_addr);
>> +
>> + switch (restype) {
>> + case IORESOURCE_IO:
>> + res = >res[XGENE_IO];
>> + of_pci_range_to_resource(, np, res);
>> + xgene_pcie_setup_ob_reg(port->csr_base, OMR1BARL,
>> + XGENE_IO, res);
>> + break;
>> + case IORESOURCE_MEM:
>> + res = >res[XGENE_MEM];
>> + of_pci_range_to_resource(, np, res);
>> + xgene_pcie_setup_ob_reg(port->csr_base, OMR2BARL,
>> + XGENE_MEM, res);
>> + break;
>> + case 0:
>> + if (!cfg_map_done) {
>> + /* config region */
>> + if (port->type == PTYPE_ROOT_PORT) {
>> + ret = xgene_pcie_map_cfg(port, );
>> + if (ret)
>> + return ret;
>> + }
>> + cfg_map_done = 1;
>> + } else {
>> + /* msi region */
>> + res = >res[XGENE_MSI];
>> + of_pci_range_to_resource(, np, res);
>
> As Jason Gunthorpe said, the DT 'range' property should not
> handle MSI. Please refer to other PCI host drivers such as
> pci-mvebu.c, pci-tegra.c and pcie-designware.c.
Right. I will remove MSI from ranges.
>
> Currently, 'struct msi_chip', ' struct irq_domain' are used
> for implementing MSI feature.
>
> Best regards,
> Jingoo Han
>
--
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: [RFC PATCH 1/3] pci: APM X-Gene PCIe controller driver
Thanks for your comments. Please see some inline replies.
On Fri, Jan 3, 2014 at 4:07 AM, Arnd Bergmann wrote:
> On Monday 23 December 2013, Tanmay Inamdar wrote:
>> This patch adds the AppliedMicro X-gene SOC PCIe controller driver.
>> APM X-Gene PCIe controller supports maximum upto 8 lanes and
>> GEN3 speed. X-Gene has maximum 5 PCIe ports supported.
>>
>> Signed-off-by: Tanmay Inamdar
>> ---
>> drivers/pci/host/Kconfig |5 +
>> drivers/pci/host/Makefile |1 +
>> drivers/pci/host/pcie-xgene.c | 1017
>> +
>> 3 files changed, 1023 insertions(+)
>> create mode 100644 drivers/pci/host/pcie-xgene.c
>>
>> diff --git a/drivers/pci/host/Kconfig b/drivers/pci/host/Kconfig
>> index 47d46c6..6d8fcbc 100644
>> --- a/drivers/pci/host/Kconfig
>> +++ b/drivers/pci/host/Kconfig
>> @@ -33,4 +33,9 @@ config PCI_RCAR_GEN2
>> There are 3 internal PCI controllers available with a single
>> built-in EHCI/OHCI host controller present on each one.
>>
>> +config PCI_XGENE
>> + bool "X-Gene PCIe controller"
>> + depends on ARCH_XGENE
>> + depends on OF
>
> Please add a help text here.
ok
>
>> +#ifdef CONFIG_ARM64
>> +#include
>> +#else
>> +#include
>> +#endif
>
> What is !ARM64 case? Is this for PowerPC or ARM? Since you depend on
> ARCH_XGENE in Kconfig I guess neither case can actually happen,
> so you can remove the #ifdef.
ok
>
>> +#define CFG_CONSTANTS_31_00 0x2000
>> +#define CFG_CONSTANTS_63_32 0x2004
>> +#define CFG_CONSTANTS_159_1280x2010
>> +#define CFG_CONSTANTS_415_384 0x2030
>
> These macros do not seem helpful. If you don't have meaningful register
> names, just don't provide any and address the registers by index.
ok
>
>> +#define ENABLE_L1S_POWER_MGMT_SET(dst, src) (((dst) & ~0x0200) | \
>> + (((u32)(src) << 0x19) & \
>> + 0x0200))
>
> Makes this an inline function, or open-code it in the caller if there
> is only one.
>
ok
>> +#ifdef CONFIG_64BIT
>> +#define pci_io_offset(s) (s & 0xff)
>> +#else
>> +#define pci_io_offset(s) (s & 0x)
>> +#endif /* CONFIG_64BIT */
>
> Why is this needed? The I/O space can never be over 0x,
> or in practice 0x. My best guess is that you have a bug in the
> function parsing your ranges property, or in the property value.
I will recheck the logic.
>
>> +static inline struct xgene_pcie_port *
>> +xgene_pcie_sys_to_port(struct pci_sys_data *sys)
>> +{
>> + return (struct xgene_pcie_port *)sys->private_data;
>> +}
>
> You shouldn't need the cast, or the accessor function, since private_data
> is already a void pointer.
got it.
>
>> +/* IO ports are memory mapped */
>> +void __iomem *__pci_ioport_map(struct pci_dev *dev, unsigned long port,
>> +unsigned int nr)
>> +{
>> + return devm_ioremap_nocache(>dev, port, nr);
>> +}
>
> This can't be in the host driver, since you can have only one instance
> of the function in the system, but you probably want multiple host
> drivers in a multiplatform kernel on ARM64.
You are right. It will fail multiplatform kernel.
>
> Also, the implementation is wrong since the I/O port range already needs
> to be ioremapped in order for inb/outb to work. There is already a
> generic implementation of this in include/asm-generic/iomap.h, which
> correctly calls ioport_map. Make sure that arm64 uses this implementation
> and provides an ioport_map() function like
>
> static inline void __iomem *ioport_map(unsigned long port, unsigned int nr)
> {
> return PCI_IOBASE + port;
> }
For X-Gene, IO regions are memory mapped IO regions. So I am not sure
if 'ioport_map'
would work.
>
>> +/* PCIE Out/In to CSR */
>> +static inline void xgene_pcie_out32(void *addr, u32 val)
>> +{
>> + pr_debug("pcie csr wr: 0x%llx 0x%08x\n", (phys_addr_t)addr, val);
>> + writel(val, addr);
>> +}
>> +
>> +static inline void xgene_pcie_in32(void *addr, u32 *val)
>> +{
>> + *val = readl(addr);
>> + pr_debug("pcie csr rd: 0x%llx 0x%08x\n", (phys_addr_t)addr, *val);
>> +}
>
> These add no value, just remove them. If your code is so buggy that
> you need to print every register access to the debug log, we don't
> want it ;-)
Yep. I will remove it.
>
>> +static inline void xgene_pcie_cfg_out16(void *addr, u16 val)
>> +{
>> + phys_addr_t temp_addr = (phys_addr_t) addr & ~0x3;
>> + u32 val32 = readl((void *)temp_addr);
>> +
>> + switch ((phys_addr_t) addr & 0x3) {
>> + case 2:
>> + val32 &= ~0x;
>> + val32 |= (u32) val << 16;
>> + break;
>> + case 0:
>> + default:
>> + val32 &= ~0x;
>> + val32 |= val;
>> + break;
>> + }
>> + writel(val32, (void *)temp_addr);
>> +}
>
> Isn't there a generic version of this? If not, should
Re: [RFC PATCH 1/3] pci: APM X-Gene PCIe controller driver
Thanks for your comments. Please see some inline replies.
On Fri, Jan 3, 2014 at 4:07 AM, Arnd Bergmann a...@arndb.de wrote:
On Monday 23 December 2013, Tanmay Inamdar wrote:
This patch adds the AppliedMicro X-gene SOC PCIe controller driver.
APM X-Gene PCIe controller supports maximum upto 8 lanes and
GEN3 speed. X-Gene has maximum 5 PCIe ports supported.
Signed-off-by: Tanmay Inamdar tinam...@apm.com
---
drivers/pci/host/Kconfig |5 +
drivers/pci/host/Makefile |1 +
drivers/pci/host/pcie-xgene.c | 1017
+
3 files changed, 1023 insertions(+)
create mode 100644 drivers/pci/host/pcie-xgene.c
diff --git a/drivers/pci/host/Kconfig b/drivers/pci/host/Kconfig
index 47d46c6..6d8fcbc 100644
--- a/drivers/pci/host/Kconfig
+++ b/drivers/pci/host/Kconfig
@@ -33,4 +33,9 @@ config PCI_RCAR_GEN2
There are 3 internal PCI controllers available with a single
built-in EHCI/OHCI host controller present on each one.
+config PCI_XGENE
+ bool X-Gene PCIe controller
+ depends on ARCH_XGENE
+ depends on OF
Please add a help text here.
ok
+#ifdef CONFIG_ARM64
+#include asm/pcibios.h
+#else
+#include asm/mach/pci.h
+#endif
What is !ARM64 case? Is this for PowerPC or ARM? Since you depend on
ARCH_XGENE in Kconfig I guess neither case can actually happen,
so you can remove the #ifdef.
ok
+#define CFG_CONSTANTS_31_00 0x2000
+#define CFG_CONSTANTS_63_32 0x2004
+#define CFG_CONSTANTS_159_1280x2010
+#define CFG_CONSTANTS_415_384 0x2030
These macros do not seem helpful. If you don't have meaningful register
names, just don't provide any and address the registers by index.
ok
+#define ENABLE_L1S_POWER_MGMT_SET(dst, src) (((dst) ~0x0200) | \
+ (((u32)(src) 0x19) \
+ 0x0200))
Makes this an inline function, or open-code it in the caller if there
is only one.
ok
+#ifdef CONFIG_64BIT
+#define pci_io_offset(s) (s 0xff)
+#else
+#define pci_io_offset(s) (s 0x)
+#endif /* CONFIG_64BIT */
Why is this needed? The I/O space can never be over 0x,
or in practice 0x. My best guess is that you have a bug in the
function parsing your ranges property, or in the property value.
I will recheck the logic.
+static inline struct xgene_pcie_port *
+xgene_pcie_sys_to_port(struct pci_sys_data *sys)
+{
+ return (struct xgene_pcie_port *)sys-private_data;
+}
You shouldn't need the cast, or the accessor function, since private_data
is already a void pointer.
got it.
+/* IO ports are memory mapped */
+void __iomem *__pci_ioport_map(struct pci_dev *dev, unsigned long port,
+unsigned int nr)
+{
+ return devm_ioremap_nocache(dev-dev, port, nr);
+}
This can't be in the host driver, since you can have only one instance
of the function in the system, but you probably want multiple host
drivers in a multiplatform kernel on ARM64.
You are right. It will fail multiplatform kernel.
Also, the implementation is wrong since the I/O port range already needs
to be ioremapped in order for inb/outb to work. There is already a
generic implementation of this in include/asm-generic/iomap.h, which
correctly calls ioport_map. Make sure that arm64 uses this implementation
and provides an ioport_map() function like
static inline void __iomem *ioport_map(unsigned long port, unsigned int nr)
{
return PCI_IOBASE + port;
}
For X-Gene, IO regions are memory mapped IO regions. So I am not sure
if 'ioport_map'
would work.
+/* PCIE Out/In to CSR */
+static inline void xgene_pcie_out32(void *addr, u32 val)
+{
+ pr_debug(pcie csr wr: 0x%llx 0x%08x\n, (phys_addr_t)addr, val);
+ writel(val, addr);
+}
+
+static inline void xgene_pcie_in32(void *addr, u32 *val)
+{
+ *val = readl(addr);
+ pr_debug(pcie csr rd: 0x%llx 0x%08x\n, (phys_addr_t)addr, *val);
+}
These add no value, just remove them. If your code is so buggy that
you need to print every register access to the debug log, we don't
want it ;-)
Yep. I will remove it.
+static inline void xgene_pcie_cfg_out16(void *addr, u16 val)
+{
+ phys_addr_t temp_addr = (phys_addr_t) addr ~0x3;
+ u32 val32 = readl((void *)temp_addr);
+
+ switch ((phys_addr_t) addr 0x3) {
+ case 2:
+ val32 = ~0x;
+ val32 |= (u32) val 16;
+ break;
+ case 0:
+ default:
+ val32 = ~0x;
+ val32 |= val;
+ break;
+ }
+ writel(val32, (void *)temp_addr);
+}
Isn't there a generic version of this? If not, should there be one?
Maybe Bjorn can comment.
Also, all the typecasts are wrong. Please think about what types
you really want and fix them.
ok
+static void
Re: [RFC PATCH 1/3] pci: APM X-Gene PCIe controller driver
On Sun, Jan 5, 2014 at 5:47 PM, Jingoo Han jg1@samsung.com wrote:
On Monday, December 23, 2013 5:02 PM, Tanmay Inamdar wrote:
This patch adds the AppliedMicro X-gene SOC PCIe controller driver.
APM X-Gene PCIe controller supports maximum upto 8 lanes and
GEN3 speed. X-Gene has maximum 5 PCIe ports supported.
(+cc Jason Gunthorpe, Arnd Bergmann)
Hi Tanmay Inamdar,
I added some minor comments. :-)
Signed-off-by: Tanmay Inamdar tinam...@apm.com
---
drivers/pci/host/Kconfig |5 +
drivers/pci/host/Makefile |1 +
drivers/pci/host/pcie-xgene.c | 1017
+
Would you change the file name to 'pci-xgene.c'?
Now, all PCI host drivers are using the prefix 'pci-', not 'pcie-'.
I guess designware is an exception. There is
drivers/pci/host/pcie-designware.c
[.]
+#include linux/module.h
+#include linux/delay.h
+#include linux/pci.h
+#include linux/slab.h
+#include linux/memblock.h
+#include linux/io.h
+#include linux/platform_device.h
+#include linux/of.h
+#include linux/of_address.h
+#include linux/of_irq.h
+#include linux/of_pci.h
+#include linux/jiffies.h
+#include linux/clk-private.h
Would you re-order these headers alphabetically?
It enhances the readability.
ok.
[.]
+static int xgene_pcie_parse_map_ranges(struct xgene_pcie_port *port)
+{
+ struct device_node *np = port-node;
+ struct of_pci_range range;
+ struct of_pci_range_parser parser;
+ struct device *dev = port-dev;
+ u32 cfg_map_done = 0;
+ int ret;
+
+ if (of_pci_range_parser_init(parser, np)) {
+ dev_err(dev, missing ranges property\n);
+ return -EINVAL;
+ }
+
+ /* Get the I/O, memory, config ranges from DT */
+ for_each_of_pci_range(parser, range) {
+ struct resource *res = NULL;
+ u64 restype = range.flags IORESOURCE_TYPE_BITS;
+ u64 end = range.cpu_addr + range.size - 1;
+ dev_dbg(port-dev, 0x%08x 0x%016llx..0x%016llx -
0x%016llx\n,
+ range.flags, range.cpu_addr, end, range.pci_addr);
+
+ switch (restype) {
+ case IORESOURCE_IO:
+ res = port-res[XGENE_IO];
+ of_pci_range_to_resource(range, np, res);
+ xgene_pcie_setup_ob_reg(port-csr_base, OMR1BARL,
+ XGENE_IO, res);
+ break;
+ case IORESOURCE_MEM:
+ res = port-res[XGENE_MEM];
+ of_pci_range_to_resource(range, np, res);
+ xgene_pcie_setup_ob_reg(port-csr_base, OMR2BARL,
+ XGENE_MEM, res);
+ break;
+ case 0:
+ if (!cfg_map_done) {
+ /* config region */
+ if (port-type == PTYPE_ROOT_PORT) {
+ ret = xgene_pcie_map_cfg(port, range);
+ if (ret)
+ return ret;
+ }
+ cfg_map_done = 1;
+ } else {
+ /* msi region */
+ res = port-res[XGENE_MSI];
+ of_pci_range_to_resource(range, np, res);
As Jason Gunthorpe said, the DT 'range' property should not
handle MSI. Please refer to other PCI host drivers such as
pci-mvebu.c, pci-tegra.c and pcie-designware.c.
Right. I will remove MSI from ranges.
Currently, 'struct msi_chip', ' struct irq_domain' are used
for implementing MSI feature.
Best regards,
Jingoo Han
--
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: [RFC PATCH 1/3] pci: APM X-Gene PCIe controller driver
On Tuesday, January 07, 2014 11:45 AM, Tanmay Inamdar wrote: On Sun, Jan 5, 2014 at 5:47 PM, Jingoo Han jg1@samsung.com wrote: On Monday, December 23, 2013 5:02 PM, Tanmay Inamdar wrote: This patch adds the AppliedMicro X-gene SOC PCIe controller driver. APM X-Gene PCIe controller supports maximum upto 8 lanes and GEN3 speed. X-Gene has maximum 5 PCIe ports supported. (+cc Jason Gunthorpe, Arnd Bergmann) Hi Tanmay Inamdar, I added some minor comments. :-) Signed-off-by: Tanmay Inamdar tinam...@apm.com --- drivers/pci/host/Kconfig |5 + drivers/pci/host/Makefile |1 + drivers/pci/host/pcie-xgene.c | 1017 + Would you change the file name to 'pci-xgene.c'? Now, all PCI host drivers are using the prefix 'pci-', not 'pcie-'. I guess designware is an exception. There is drivers/pci/host/pcie-designware.c (+cc Thierry Reding, Pratyush Anand, Mohit KUMAR) Now, the current naming rule is PCI- prefix as below. - Samsung Exynos: pci-exynos.c - Freescale i.MX6: pci-imx6.c - Marvell: pci-mvebu.c - Nvidia Tegra: pci-tegra.c - Renesas R-Car: pci-rcar-gen2.c According to the Thierry Reding's comment, I think we should keep these sorted alphabetically. Also Tegra and Marvell are PCIe controllers but they still use the pci- prefix instead of pcie-. Perhaps it'd be good to keep consistency here? I initially chose pci- because from a software point of view it doesn't matter all that much whether it's PCI or PCIe and because the drivers are part of the PCI subsystem. However if Exynos now uses the pcie- prefix it makes it look like Tegra and Marvell are plain old PCI. (https://groups.google.com/forum/#!msg/linux.kernel/qtimJoNSc3w/_1aayHaG54YJ) However, pcie-designware.c is common layer driver for other SoC PCI host drivers that use Synopsys Designware PCI IP. Thus, currently it is shared by other SoC PCI host drivers such as pci-exynos.c, and pci-imx6.c. Also, ST PCI driver will use pcie-designware.c as common layer. Originally, pci-designware.c was used. However, Pratyush Anand suggested pci-designware.c can be renamed to pcie-designware.c, because Synopsys PCI IP and Synopsys PCI Express IP are different. So, currently pcie-designware.c is used. So, if there is no special reason, pci- prefix can be used. Thank you. Best regards, Jingoo Han -- 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: [RFC PATCH 1/3] pci: APM X-Gene PCIe controller driver
On Monday, December 23, 2013 5:02 PM, Tanmay Inamdar wrote:
>
> This patch adds the AppliedMicro X-gene SOC PCIe controller driver.
> APM X-Gene PCIe controller supports maximum upto 8 lanes and
> GEN3 speed. X-Gene has maximum 5 PCIe ports supported.
(+cc Jason Gunthorpe, Arnd Bergmann)
Hi Tanmay Inamdar,
I added some minor comments. :-)
>
> Signed-off-by: Tanmay Inamdar
> ---
> drivers/pci/host/Kconfig |5 +
> drivers/pci/host/Makefile |1 +
> drivers/pci/host/pcie-xgene.c | 1017
> +
Would you change the file name to 'pci-xgene.c'?
Now, all PCI host drivers are using the prefix 'pci-', not 'pcie-'.
[.]
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
Would you re-order these headers alphabetically?
It enhances the readability.
[.]
> +static int xgene_pcie_parse_map_ranges(struct xgene_pcie_port *port)
> +{
> + struct device_node *np = port->node;
> + struct of_pci_range range;
> + struct of_pci_range_parser parser;
> + struct device *dev = port->dev;
> + u32 cfg_map_done = 0;
> + int ret;
> +
> + if (of_pci_range_parser_init(, np)) {
> + dev_err(dev, "missing ranges property\n");
> + return -EINVAL;
> + }
> +
> + /* Get the I/O, memory, config ranges from DT */
> + for_each_of_pci_range(, ) {
> + struct resource *res = NULL;
> + u64 restype = range.flags & IORESOURCE_TYPE_BITS;
> + u64 end = range.cpu_addr + range.size - 1;
> + dev_dbg(port->dev, "0x%08x 0x%016llx..0x%016llx -> 0x%016llx\n",
> + range.flags, range.cpu_addr, end, range.pci_addr);
> +
> + switch (restype) {
> + case IORESOURCE_IO:
> + res = >res[XGENE_IO];
> + of_pci_range_to_resource(, np, res);
> + xgene_pcie_setup_ob_reg(port->csr_base, OMR1BARL,
> + XGENE_IO, res);
> + break;
> + case IORESOURCE_MEM:
> + res = >res[XGENE_MEM];
> + of_pci_range_to_resource(, np, res);
> + xgene_pcie_setup_ob_reg(port->csr_base, OMR2BARL,
> + XGENE_MEM, res);
> + break;
> + case 0:
> + if (!cfg_map_done) {
> + /* config region */
> + if (port->type == PTYPE_ROOT_PORT) {
> + ret = xgene_pcie_map_cfg(port, );
> + if (ret)
> + return ret;
> + }
> + cfg_map_done = 1;
> + } else {
> + /* msi region */
> + res = >res[XGENE_MSI];
> + of_pci_range_to_resource(, np, res);
As Jason Gunthorpe said, the DT 'range' property should not
handle MSI. Please refer to other PCI host drivers such as
pci-mvebu.c, pci-tegra.c and pcie-designware.c.
Currently, 'struct msi_chip', ' struct irq_domain' are used
for implementing MSI feature.
Best regards,
Jingoo Han
--
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: [RFC PATCH 1/3] pci: APM X-Gene PCIe controller driver
On Monday, December 23, 2013 5:02 PM, Tanmay Inamdar wrote:
This patch adds the AppliedMicro X-gene SOC PCIe controller driver.
APM X-Gene PCIe controller supports maximum upto 8 lanes and
GEN3 speed. X-Gene has maximum 5 PCIe ports supported.
(+cc Jason Gunthorpe, Arnd Bergmann)
Hi Tanmay Inamdar,
I added some minor comments. :-)
Signed-off-by: Tanmay Inamdar tinam...@apm.com
---
drivers/pci/host/Kconfig |5 +
drivers/pci/host/Makefile |1 +
drivers/pci/host/pcie-xgene.c | 1017
+
Would you change the file name to 'pci-xgene.c'?
Now, all PCI host drivers are using the prefix 'pci-', not 'pcie-'.
[.]
+#include linux/module.h
+#include linux/delay.h
+#include linux/pci.h
+#include linux/slab.h
+#include linux/memblock.h
+#include linux/io.h
+#include linux/platform_device.h
+#include linux/of.h
+#include linux/of_address.h
+#include linux/of_irq.h
+#include linux/of_pci.h
+#include linux/jiffies.h
+#include linux/clk-private.h
Would you re-order these headers alphabetically?
It enhances the readability.
[.]
+static int xgene_pcie_parse_map_ranges(struct xgene_pcie_port *port)
+{
+ struct device_node *np = port-node;
+ struct of_pci_range range;
+ struct of_pci_range_parser parser;
+ struct device *dev = port-dev;
+ u32 cfg_map_done = 0;
+ int ret;
+
+ if (of_pci_range_parser_init(parser, np)) {
+ dev_err(dev, missing ranges property\n);
+ return -EINVAL;
+ }
+
+ /* Get the I/O, memory, config ranges from DT */
+ for_each_of_pci_range(parser, range) {
+ struct resource *res = NULL;
+ u64 restype = range.flags IORESOURCE_TYPE_BITS;
+ u64 end = range.cpu_addr + range.size - 1;
+ dev_dbg(port-dev, 0x%08x 0x%016llx..0x%016llx - 0x%016llx\n,
+ range.flags, range.cpu_addr, end, range.pci_addr);
+
+ switch (restype) {
+ case IORESOURCE_IO:
+ res = port-res[XGENE_IO];
+ of_pci_range_to_resource(range, np, res);
+ xgene_pcie_setup_ob_reg(port-csr_base, OMR1BARL,
+ XGENE_IO, res);
+ break;
+ case IORESOURCE_MEM:
+ res = port-res[XGENE_MEM];
+ of_pci_range_to_resource(range, np, res);
+ xgene_pcie_setup_ob_reg(port-csr_base, OMR2BARL,
+ XGENE_MEM, res);
+ break;
+ case 0:
+ if (!cfg_map_done) {
+ /* config region */
+ if (port-type == PTYPE_ROOT_PORT) {
+ ret = xgene_pcie_map_cfg(port, range);
+ if (ret)
+ return ret;
+ }
+ cfg_map_done = 1;
+ } else {
+ /* msi region */
+ res = port-res[XGENE_MSI];
+ of_pci_range_to_resource(range, np, res);
As Jason Gunthorpe said, the DT 'range' property should not
handle MSI. Please refer to other PCI host drivers such as
pci-mvebu.c, pci-tegra.c and pcie-designware.c.
Currently, 'struct msi_chip', ' struct irq_domain' are used
for implementing MSI feature.
Best regards,
Jingoo Han
--
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: [RFC PATCH 1/3] pci: APM X-Gene PCIe controller driver
On Monday 23 December 2013, Tanmay Inamdar wrote:
> This patch adds the AppliedMicro X-gene SOC PCIe controller driver.
> APM X-Gene PCIe controller supports maximum upto 8 lanes and
> GEN3 speed. X-Gene has maximum 5 PCIe ports supported.
>
> Signed-off-by: Tanmay Inamdar
> ---
> drivers/pci/host/Kconfig |5 +
> drivers/pci/host/Makefile |1 +
> drivers/pci/host/pcie-xgene.c | 1017
> +
> 3 files changed, 1023 insertions(+)
> create mode 100644 drivers/pci/host/pcie-xgene.c
>
> diff --git a/drivers/pci/host/Kconfig b/drivers/pci/host/Kconfig
> index 47d46c6..6d8fcbc 100644
> --- a/drivers/pci/host/Kconfig
> +++ b/drivers/pci/host/Kconfig
> @@ -33,4 +33,9 @@ config PCI_RCAR_GEN2
> There are 3 internal PCI controllers available with a single
> built-in EHCI/OHCI host controller present on each one.
>
> +config PCI_XGENE
> + bool "X-Gene PCIe controller"
> + depends on ARCH_XGENE
> + depends on OF
Please add a help text here.
> +#ifdef CONFIG_ARM64
> +#include
> +#else
> +#include
> +#endif
What is !ARM64 case? Is this for PowerPC or ARM? Since you depend on
ARCH_XGENE in Kconfig I guess neither case can actually happen,
so you can remove the #ifdef.
> +#define CFG_CONSTANTS_31_00 0x2000
> +#define CFG_CONSTANTS_63_32 0x2004
> +#define CFG_CONSTANTS_159_1280x2010
> +#define CFG_CONSTANTS_415_384 0x2030
These macros do not seem helpful. If you don't have meaningful register
names, just don't provide any and address the registers by index.
> +#define ENABLE_L1S_POWER_MGMT_SET(dst, src) (((dst) & ~0x0200) | \
> + (((u32)(src) << 0x19) & \
> + 0x0200))
Makes this an inline function, or open-code it in the caller if there
is only one.
> +#ifdef CONFIG_64BIT
> +#define pci_io_offset(s) (s & 0xff)
> +#else
> +#define pci_io_offset(s) (s & 0x)
> +#endif /* CONFIG_64BIT */
Why is this needed? The I/O space can never be over 0x,
or in practice 0x. My best guess is that you have a bug in the
function parsing your ranges property, or in the property value.
> +static inline struct xgene_pcie_port *
> +xgene_pcie_sys_to_port(struct pci_sys_data *sys)
> +{
> + return (struct xgene_pcie_port *)sys->private_data;
> +}
You shouldn't need the cast, or the accessor function, since private_data
is already a void pointer.
> +/* IO ports are memory mapped */
> +void __iomem *__pci_ioport_map(struct pci_dev *dev, unsigned long port,
> +unsigned int nr)
> +{
> + return devm_ioremap_nocache(>dev, port, nr);
> +}
This can't be in the host driver, since you can have only one instance
of the function in the system, but you probably want multiple host
drivers in a multiplatform kernel on ARM64.
Also, the implementation is wrong since the I/O port range already needs
to be ioremapped in order for inb/outb to work. There is already a
generic implementation of this in include/asm-generic/iomap.h, which
correctly calls ioport_map. Make sure that arm64 uses this implementation
and provides an ioport_map() function like
static inline void __iomem *ioport_map(unsigned long port, unsigned int nr)
{
return PCI_IOBASE + port;
}
> +/* PCIE Out/In to CSR */
> +static inline void xgene_pcie_out32(void *addr, u32 val)
> +{
> + pr_debug("pcie csr wr: 0x%llx 0x%08x\n", (phys_addr_t)addr, val);
> + writel(val, addr);
> +}
> +
> +static inline void xgene_pcie_in32(void *addr, u32 *val)
> +{
> + *val = readl(addr);
> + pr_debug("pcie csr rd: 0x%llx 0x%08x\n", (phys_addr_t)addr, *val);
> +}
These add no value, just remove them. If your code is so buggy that
you need to print every register access to the debug log, we don't
want it ;-)
> +static inline void xgene_pcie_cfg_out16(void *addr, u16 val)
> +{
> + phys_addr_t temp_addr = (phys_addr_t) addr & ~0x3;
> + u32 val32 = readl((void *)temp_addr);
> +
> + switch ((phys_addr_t) addr & 0x3) {
> + case 2:
> + val32 &= ~0x;
> + val32 |= (u32) val << 16;
> + break;
> + case 0:
> + default:
> + val32 &= ~0x;
> + val32 |= val;
> + break;
> + }
> + writel(val32, (void *)temp_addr);
> +}
Isn't there a generic version of this? If not, should there be one?
Maybe Bjorn can comment.
Also, all the typecasts are wrong. Please think about what types
you really want and fix them.
> +static void xgene_pcie_set_rtdid_reg(struct pci_bus *bus, uint devfn)
> +{
> + struct xgene_pcie_port *port = xgene_pcie_bus_to_port(bus);
> + unsigned int b, d, f;
> + u32 rtdid_val = 0;
> +
> + b = bus->number;
> + d = PCI_SLOT(devfn);
> + f = PCI_FUNC(devfn);
> +
> + if (bus->number == port->first_busno)
> + rtdid_val = (b
Re: [RFC PATCH 1/3] pci: APM X-Gene PCIe controller driver
On Monday 23 December 2013, Tanmay Inamdar wrote:
This patch adds the AppliedMicro X-gene SOC PCIe controller driver.
APM X-Gene PCIe controller supports maximum upto 8 lanes and
GEN3 speed. X-Gene has maximum 5 PCIe ports supported.
Signed-off-by: Tanmay Inamdar tinam...@apm.com
---
drivers/pci/host/Kconfig |5 +
drivers/pci/host/Makefile |1 +
drivers/pci/host/pcie-xgene.c | 1017
+
3 files changed, 1023 insertions(+)
create mode 100644 drivers/pci/host/pcie-xgene.c
diff --git a/drivers/pci/host/Kconfig b/drivers/pci/host/Kconfig
index 47d46c6..6d8fcbc 100644
--- a/drivers/pci/host/Kconfig
+++ b/drivers/pci/host/Kconfig
@@ -33,4 +33,9 @@ config PCI_RCAR_GEN2
There are 3 internal PCI controllers available with a single
built-in EHCI/OHCI host controller present on each one.
+config PCI_XGENE
+ bool X-Gene PCIe controller
+ depends on ARCH_XGENE
+ depends on OF
Please add a help text here.
+#ifdef CONFIG_ARM64
+#include asm/pcibios.h
+#else
+#include asm/mach/pci.h
+#endif
What is !ARM64 case? Is this for PowerPC or ARM? Since you depend on
ARCH_XGENE in Kconfig I guess neither case can actually happen,
so you can remove the #ifdef.
+#define CFG_CONSTANTS_31_00 0x2000
+#define CFG_CONSTANTS_63_32 0x2004
+#define CFG_CONSTANTS_159_1280x2010
+#define CFG_CONSTANTS_415_384 0x2030
These macros do not seem helpful. If you don't have meaningful register
names, just don't provide any and address the registers by index.
+#define ENABLE_L1S_POWER_MGMT_SET(dst, src) (((dst) ~0x0200) | \
+ (((u32)(src) 0x19) \
+ 0x0200))
Makes this an inline function, or open-code it in the caller if there
is only one.
+#ifdef CONFIG_64BIT
+#define pci_io_offset(s) (s 0xff)
+#else
+#define pci_io_offset(s) (s 0x)
+#endif /* CONFIG_64BIT */
Why is this needed? The I/O space can never be over 0x,
or in practice 0x. My best guess is that you have a bug in the
function parsing your ranges property, or in the property value.
+static inline struct xgene_pcie_port *
+xgene_pcie_sys_to_port(struct pci_sys_data *sys)
+{
+ return (struct xgene_pcie_port *)sys-private_data;
+}
You shouldn't need the cast, or the accessor function, since private_data
is already a void pointer.
+/* IO ports are memory mapped */
+void __iomem *__pci_ioport_map(struct pci_dev *dev, unsigned long port,
+unsigned int nr)
+{
+ return devm_ioremap_nocache(dev-dev, port, nr);
+}
This can't be in the host driver, since you can have only one instance
of the function in the system, but you probably want multiple host
drivers in a multiplatform kernel on ARM64.
Also, the implementation is wrong since the I/O port range already needs
to be ioremapped in order for inb/outb to work. There is already a
generic implementation of this in include/asm-generic/iomap.h, which
correctly calls ioport_map. Make sure that arm64 uses this implementation
and provides an ioport_map() function like
static inline void __iomem *ioport_map(unsigned long port, unsigned int nr)
{
return PCI_IOBASE + port;
}
+/* PCIE Out/In to CSR */
+static inline void xgene_pcie_out32(void *addr, u32 val)
+{
+ pr_debug(pcie csr wr: 0x%llx 0x%08x\n, (phys_addr_t)addr, val);
+ writel(val, addr);
+}
+
+static inline void xgene_pcie_in32(void *addr, u32 *val)
+{
+ *val = readl(addr);
+ pr_debug(pcie csr rd: 0x%llx 0x%08x\n, (phys_addr_t)addr, *val);
+}
These add no value, just remove them. If your code is so buggy that
you need to print every register access to the debug log, we don't
want it ;-)
+static inline void xgene_pcie_cfg_out16(void *addr, u16 val)
+{
+ phys_addr_t temp_addr = (phys_addr_t) addr ~0x3;
+ u32 val32 = readl((void *)temp_addr);
+
+ switch ((phys_addr_t) addr 0x3) {
+ case 2:
+ val32 = ~0x;
+ val32 |= (u32) val 16;
+ break;
+ case 0:
+ default:
+ val32 = ~0x;
+ val32 |= val;
+ break;
+ }
+ writel(val32, (void *)temp_addr);
+}
Isn't there a generic version of this? If not, should there be one?
Maybe Bjorn can comment.
Also, all the typecasts are wrong. Please think about what types
you really want and fix them.
+static void xgene_pcie_set_rtdid_reg(struct pci_bus *bus, uint devfn)
+{
+ struct xgene_pcie_port *port = xgene_pcie_bus_to_port(bus);
+ unsigned int b, d, f;
+ u32 rtdid_val = 0;
+
+ b = bus-number;
+ d = PCI_SLOT(devfn);
+ f = PCI_FUNC(devfn);
+
+ if (bus-number == port-first_busno)
+ rtdid_val = (b 24) | (d 19) | (f 16);
+ else if (bus-number =
Re: [RFC PATCH 1/3] pci: APM X-Gene PCIe controller driver
On Mon, Dec 23, 2013 at 1:02 AM, Tanmay Inamdar wrote: > This patch adds the AppliedMicro X-gene SOC PCIe controller driver. > APM X-Gene PCIe controller supports maximum upto 8 lanes and > GEN3 speed. X-Gene has maximum 5 PCIe ports supported. > > Signed-off-by: Tanmay Inamdar Since Jason requested "lspci" output, I'm waiting for him to review these before applying them. Also, please include a MAINTAINERS update showing who should approve future changes to this file. Bjorn > --- > drivers/pci/host/Kconfig |5 + > drivers/pci/host/Makefile |1 + > drivers/pci/host/pcie-xgene.c | 1017 > + > 3 files changed, 1023 insertions(+) > create mode 100644 drivers/pci/host/pcie-xgene.c > > diff --git a/drivers/pci/host/Kconfig b/drivers/pci/host/Kconfig > index 47d46c6..6d8fcbc 100644 > --- a/drivers/pci/host/Kconfig > +++ b/drivers/pci/host/Kconfig > @@ -33,4 +33,9 @@ config PCI_RCAR_GEN2 > There are 3 internal PCI controllers available with a single > built-in EHCI/OHCI host controller present on each one. > > +config PCI_XGENE > + bool "X-Gene PCIe controller" > + depends on ARCH_XGENE > + depends on OF > + > endmenu > diff --git a/drivers/pci/host/Makefile b/drivers/pci/host/Makefile > index 13fb333..a0bdfa7 100644 > --- a/drivers/pci/host/Makefile > +++ b/drivers/pci/host/Makefile > @@ -4,3 +4,4 @@ obj-$(CONFIG_PCI_IMX6) += pci-imx6.o > obj-$(CONFIG_PCI_MVEBU) += pci-mvebu.o > obj-$(CONFIG_PCI_TEGRA) += pci-tegra.o > obj-$(CONFIG_PCI_RCAR_GEN2) += pci-rcar-gen2.o > +obj-$(CONFIG_PCI_XGENE) += pcie-xgene.o > diff --git a/drivers/pci/host/pcie-xgene.c b/drivers/pci/host/pcie-xgene.c > new file mode 100644 > index 000..c9403c3 > --- /dev/null > +++ b/drivers/pci/host/pcie-xgene.c > @@ -0,0 +1,1017 @@ > +/** > + * APM X-Gene PCIe Driver > + * > + * Copyright (c) 2013 Applied Micro Circuits Corporation. > + * > + * Author: Tanmay Inamdar . > + * > + * This program is free software; you can redistribute it and/or modify it > + * under the terms of the GNU General Public License as published by the > + * Free Software Foundation; either version 2 of the License, or (at your > + * option) any later version. > + * > + * This program is distributed in the hope that it will be useful, > + * but WITHOUT ANY WARRANTY; without even the implied warranty of > + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the > + * GNU General Public License for more details. > + * > + */ > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#ifdef CONFIG_ARM64 > +#include > +#else > +#include > +#endif > + > +#define PCIECORE_LTSSM 0x4c > +#define PCIECORE_CTLANDSTATUS 0x50 > +#define PIPE_PHY_RATE_RD(src) ((0xc000 & (u32)(src)) >> 0xe) > +#define INTXSTATUSMASK 0x6c > +#define PIM1_1L0x80 > +#define IBAR2 0x98 > +#define IR2MSK 0x9c > +#define PIM2_1L0xa0 > +#define OMR1BARL 0x100 > +#define OMR2BARL 0x118 > +#define CFGBARL0x154 > +#define CFGBARH0x158 > +#define CFGCTL 0x15c > +#define RTDID 0x160 > +#define CFG_CONSTANTS_31_000x2000 > +#define CFG_CONSTANTS_63_320x2004 > +#define CFG_CONSTANTS_159_128 0x2010 > +#define CFG_CONSTANTS_415_384 0x2030 > +#define ENABLE_L1S_POWER_MGMT_SET(dst, src) (((dst) & ~0x0200) | \ > + (((u32)(src) << 0x19) & \ > + 0x0200)) > +#define CFG_CONSTANTS_479_448 0x2038 > +#define CFG_8G_CONSTANTS_31_0 0x2100 > +#define MGMT_US_PORT_TX_PRESET_SET(dst, src)(((dst) & ~0xf00)| \ > + (((u32)(src) << 0x8) & 0xf00)) > +#define MGMT_DS_PORT_TX_PRESET_SET(dst, src)(((dst) & ~0xf) | \ > + (((u32)(src)) & 0xf)) > + > +#define CFG_8G_CONSTANTS_159_1280x2110 > +#define EQ_UPDN_POST_STEP_SET(dst, src)(((dst) & ~0x30) | \ > + (((u32)(src) << 0x4) & \ > + 0x30)) > +#define CFG_8G_CONSTANTS_287_2560x2120 > +#define CFG_8G_CONSTANTS_319_2880x2124 > +#define CFG_8G_CONSTANTS_351_3200x2128 > +#define CFG_8G_CONSTANTS_383_3520x212c > +#define EQ_PRE_CURSOR_LANE0_SET(dst, src) (((dst) & ~0xff) | \ > + (((u32)(src)) & 0xff)) > +#define EQ_PRE_CURSOR_LANE1_SET(dst, src) (((dst) & ~0x00ff) | \ > +
Re: [RFC PATCH 1/3] pci: APM X-Gene PCIe controller driver
On Mon, Dec 23, 2013 at 1:02 AM, Tanmay Inamdar tinam...@apm.com wrote: This patch adds the AppliedMicro X-gene SOC PCIe controller driver. APM X-Gene PCIe controller supports maximum upto 8 lanes and GEN3 speed. X-Gene has maximum 5 PCIe ports supported. Signed-off-by: Tanmay Inamdar tinam...@apm.com Since Jason requested lspci output, I'm waiting for him to review these before applying them. Also, please include a MAINTAINERS update showing who should approve future changes to this file. Bjorn --- drivers/pci/host/Kconfig |5 + drivers/pci/host/Makefile |1 + drivers/pci/host/pcie-xgene.c | 1017 + 3 files changed, 1023 insertions(+) create mode 100644 drivers/pci/host/pcie-xgene.c diff --git a/drivers/pci/host/Kconfig b/drivers/pci/host/Kconfig index 47d46c6..6d8fcbc 100644 --- a/drivers/pci/host/Kconfig +++ b/drivers/pci/host/Kconfig @@ -33,4 +33,9 @@ config PCI_RCAR_GEN2 There are 3 internal PCI controllers available with a single built-in EHCI/OHCI host controller present on each one. +config PCI_XGENE + bool X-Gene PCIe controller + depends on ARCH_XGENE + depends on OF + endmenu diff --git a/drivers/pci/host/Makefile b/drivers/pci/host/Makefile index 13fb333..a0bdfa7 100644 --- a/drivers/pci/host/Makefile +++ b/drivers/pci/host/Makefile @@ -4,3 +4,4 @@ obj-$(CONFIG_PCI_IMX6) += pci-imx6.o obj-$(CONFIG_PCI_MVEBU) += pci-mvebu.o obj-$(CONFIG_PCI_TEGRA) += pci-tegra.o obj-$(CONFIG_PCI_RCAR_GEN2) += pci-rcar-gen2.o +obj-$(CONFIG_PCI_XGENE) += pcie-xgene.o diff --git a/drivers/pci/host/pcie-xgene.c b/drivers/pci/host/pcie-xgene.c new file mode 100644 index 000..c9403c3 --- /dev/null +++ b/drivers/pci/host/pcie-xgene.c @@ -0,0 +1,1017 @@ +/** + * APM X-Gene PCIe Driver + * + * Copyright (c) 2013 Applied Micro Circuits Corporation. + * + * Author: Tanmay Inamdar tinam...@apm.com. + * + * This program is free software; you can redistribute it and/or modify it + * under the terms of the GNU General Public License as published by the + * Free Software Foundation; either version 2 of the License, or (at your + * option) any later version. + * + * This program is distributed in the hope that it will be useful, + * but WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the + * GNU General Public License for more details. + * + */ +#include linux/module.h +#include linux/delay.h +#include linux/pci.h +#include linux/slab.h +#include linux/memblock.h +#include linux/io.h +#include linux/platform_device.h +#include linux/of.h +#include linux/of_address.h +#include linux/of_irq.h +#include linux/of_pci.h +#include linux/jiffies.h +#include linux/clk-private.h +#ifdef CONFIG_ARM64 +#include asm/pcibios.h +#else +#include asm/mach/pci.h +#endif + +#define PCIECORE_LTSSM 0x4c +#define PCIECORE_CTLANDSTATUS 0x50 +#define PIPE_PHY_RATE_RD(src) ((0xc000 (u32)(src)) 0xe) +#define INTXSTATUSMASK 0x6c +#define PIM1_1L0x80 +#define IBAR2 0x98 +#define IR2MSK 0x9c +#define PIM2_1L0xa0 +#define OMR1BARL 0x100 +#define OMR2BARL 0x118 +#define CFGBARL0x154 +#define CFGBARH0x158 +#define CFGCTL 0x15c +#define RTDID 0x160 +#define CFG_CONSTANTS_31_000x2000 +#define CFG_CONSTANTS_63_320x2004 +#define CFG_CONSTANTS_159_128 0x2010 +#define CFG_CONSTANTS_415_384 0x2030 +#define ENABLE_L1S_POWER_MGMT_SET(dst, src) (((dst) ~0x0200) | \ + (((u32)(src) 0x19) \ + 0x0200)) +#define CFG_CONSTANTS_479_448 0x2038 +#define CFG_8G_CONSTANTS_31_0 0x2100 +#define MGMT_US_PORT_TX_PRESET_SET(dst, src)(((dst) ~0xf00)| \ + (((u32)(src) 0x8) 0xf00)) +#define MGMT_DS_PORT_TX_PRESET_SET(dst, src)(((dst) ~0xf) | \ + (((u32)(src)) 0xf)) + +#define CFG_8G_CONSTANTS_159_1280x2110 +#define EQ_UPDN_POST_STEP_SET(dst, src)(((dst) ~0x30) | \ + (((u32)(src) 0x4) \ + 0x30)) +#define CFG_8G_CONSTANTS_287_2560x2120 +#define CFG_8G_CONSTANTS_319_2880x2124 +#define CFG_8G_CONSTANTS_351_3200x2128 +#define CFG_8G_CONSTANTS_383_3520x212c +#define EQ_PRE_CURSOR_LANE0_SET(dst, src) (((dst) ~0xff) | \ +
[RFC PATCH 1/3] pci: APM X-Gene PCIe controller driver
This patch adds the AppliedMicro X-gene SOC PCIe controller driver. APM X-Gene PCIe controller supports maximum upto 8 lanes and GEN3 speed. X-Gene has maximum 5 PCIe ports supported. Signed-off-by: Tanmay Inamdar --- drivers/pci/host/Kconfig |5 + drivers/pci/host/Makefile |1 + drivers/pci/host/pcie-xgene.c | 1017 + 3 files changed, 1023 insertions(+) create mode 100644 drivers/pci/host/pcie-xgene.c diff --git a/drivers/pci/host/Kconfig b/drivers/pci/host/Kconfig index 47d46c6..6d8fcbc 100644 --- a/drivers/pci/host/Kconfig +++ b/drivers/pci/host/Kconfig @@ -33,4 +33,9 @@ config PCI_RCAR_GEN2 There are 3 internal PCI controllers available with a single built-in EHCI/OHCI host controller present on each one. +config PCI_XGENE + bool "X-Gene PCIe controller" + depends on ARCH_XGENE + depends on OF + endmenu diff --git a/drivers/pci/host/Makefile b/drivers/pci/host/Makefile index 13fb333..a0bdfa7 100644 --- a/drivers/pci/host/Makefile +++ b/drivers/pci/host/Makefile @@ -4,3 +4,4 @@ obj-$(CONFIG_PCI_IMX6) += pci-imx6.o obj-$(CONFIG_PCI_MVEBU) += pci-mvebu.o obj-$(CONFIG_PCI_TEGRA) += pci-tegra.o obj-$(CONFIG_PCI_RCAR_GEN2) += pci-rcar-gen2.o +obj-$(CONFIG_PCI_XGENE) += pcie-xgene.o diff --git a/drivers/pci/host/pcie-xgene.c b/drivers/pci/host/pcie-xgene.c new file mode 100644 index 000..c9403c3 --- /dev/null +++ b/drivers/pci/host/pcie-xgene.c @@ -0,0 +1,1017 @@ +/** + * APM X-Gene PCIe Driver + * + * Copyright (c) 2013 Applied Micro Circuits Corporation. + * + * Author: Tanmay Inamdar . + * + * This program is free software; you can redistribute it and/or modify it + * under the terms of the GNU General Public License as published by the + * Free Software Foundation; either version 2 of the License, or (at your + * option) any later version. + * + * This program is distributed in the hope that it will be useful, + * but WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the + * GNU General Public License for more details. + * + */ +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#ifdef CONFIG_ARM64 +#include +#else +#include +#endif + +#define PCIECORE_LTSSM 0x4c +#define PCIECORE_CTLANDSTATUS 0x50 +#define PIPE_PHY_RATE_RD(src) ((0xc000 & (u32)(src)) >> 0xe) +#define INTXSTATUSMASK 0x6c +#define PIM1_1L0x80 +#define IBAR2 0x98 +#define IR2MSK 0x9c +#define PIM2_1L0xa0 +#define OMR1BARL 0x100 +#define OMR2BARL 0x118 +#define CFGBARL0x154 +#define CFGBARH0x158 +#define CFGCTL 0x15c +#define RTDID 0x160 +#define CFG_CONSTANTS_31_000x2000 +#define CFG_CONSTANTS_63_320x2004 +#define CFG_CONSTANTS_159_128 0x2010 +#define CFG_CONSTANTS_415_384 0x2030 +#define ENABLE_L1S_POWER_MGMT_SET(dst, src) (((dst) & ~0x0200) | \ + (((u32)(src) << 0x19) & \ + 0x0200)) +#define CFG_CONSTANTS_479_448 0x2038 +#define CFG_8G_CONSTANTS_31_0 0x2100 +#define MGMT_US_PORT_TX_PRESET_SET(dst, src)(((dst) & ~0xf00)| \ + (((u32)(src) << 0x8) & 0xf00)) +#define MGMT_DS_PORT_TX_PRESET_SET(dst, src)(((dst) & ~0xf) | \ + (((u32)(src)) & 0xf)) + +#define CFG_8G_CONSTANTS_159_1280x2110 +#define EQ_UPDN_POST_STEP_SET(dst, src)(((dst) & ~0x30) | \ + (((u32)(src) << 0x4) & \ + 0x30)) +#define CFG_8G_CONSTANTS_287_2560x2120 +#define CFG_8G_CONSTANTS_319_2880x2124 +#define CFG_8G_CONSTANTS_351_3200x2128 +#define CFG_8G_CONSTANTS_383_3520x212c +#define EQ_PRE_CURSOR_LANE0_SET(dst, src) (((dst) & ~0xff) | \ + (((u32)(src)) & 0xff)) +#define EQ_PRE_CURSOR_LANE1_SET(dst, src) (((dst) & ~0x00ff) | \ + (((u32)(src) << 0x10) & \ + 0x00ff)) + +#define CFG_CONTROL_63_32 0x2204 +#define CFG_CONTROL_95_64 0x2208 +#define CFG_CONTROL_191_1600x2214 +#define PCIE_STATUS_31_0 0x2600 +#define MEM_RAM_SHUTDOWN0xd070 +#define BLOCK_MEM_RDY 0xd074 + +#define PCI_PRIMARY_BUS_MASK 0x00ff +#define REVISION_ID_MASK
[RFC PATCH 1/3] pci: APM X-Gene PCIe controller driver
This patch adds the AppliedMicro X-gene SOC PCIe controller driver. APM X-Gene PCIe controller supports maximum upto 8 lanes and GEN3 speed. X-Gene has maximum 5 PCIe ports supported. Signed-off-by: Tanmay Inamdar tinam...@apm.com --- drivers/pci/host/Kconfig |5 + drivers/pci/host/Makefile |1 + drivers/pci/host/pcie-xgene.c | 1017 + 3 files changed, 1023 insertions(+) create mode 100644 drivers/pci/host/pcie-xgene.c diff --git a/drivers/pci/host/Kconfig b/drivers/pci/host/Kconfig index 47d46c6..6d8fcbc 100644 --- a/drivers/pci/host/Kconfig +++ b/drivers/pci/host/Kconfig @@ -33,4 +33,9 @@ config PCI_RCAR_GEN2 There are 3 internal PCI controllers available with a single built-in EHCI/OHCI host controller present on each one. +config PCI_XGENE + bool X-Gene PCIe controller + depends on ARCH_XGENE + depends on OF + endmenu diff --git a/drivers/pci/host/Makefile b/drivers/pci/host/Makefile index 13fb333..a0bdfa7 100644 --- a/drivers/pci/host/Makefile +++ b/drivers/pci/host/Makefile @@ -4,3 +4,4 @@ obj-$(CONFIG_PCI_IMX6) += pci-imx6.o obj-$(CONFIG_PCI_MVEBU) += pci-mvebu.o obj-$(CONFIG_PCI_TEGRA) += pci-tegra.o obj-$(CONFIG_PCI_RCAR_GEN2) += pci-rcar-gen2.o +obj-$(CONFIG_PCI_XGENE) += pcie-xgene.o diff --git a/drivers/pci/host/pcie-xgene.c b/drivers/pci/host/pcie-xgene.c new file mode 100644 index 000..c9403c3 --- /dev/null +++ b/drivers/pci/host/pcie-xgene.c @@ -0,0 +1,1017 @@ +/** + * APM X-Gene PCIe Driver + * + * Copyright (c) 2013 Applied Micro Circuits Corporation. + * + * Author: Tanmay Inamdar tinam...@apm.com. + * + * This program is free software; you can redistribute it and/or modify it + * under the terms of the GNU General Public License as published by the + * Free Software Foundation; either version 2 of the License, or (at your + * option) any later version. + * + * This program is distributed in the hope that it will be useful, + * but WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the + * GNU General Public License for more details. + * + */ +#include linux/module.h +#include linux/delay.h +#include linux/pci.h +#include linux/slab.h +#include linux/memblock.h +#include linux/io.h +#include linux/platform_device.h +#include linux/of.h +#include linux/of_address.h +#include linux/of_irq.h +#include linux/of_pci.h +#include linux/jiffies.h +#include linux/clk-private.h +#ifdef CONFIG_ARM64 +#include asm/pcibios.h +#else +#include asm/mach/pci.h +#endif + +#define PCIECORE_LTSSM 0x4c +#define PCIECORE_CTLANDSTATUS 0x50 +#define PIPE_PHY_RATE_RD(src) ((0xc000 (u32)(src)) 0xe) +#define INTXSTATUSMASK 0x6c +#define PIM1_1L0x80 +#define IBAR2 0x98 +#define IR2MSK 0x9c +#define PIM2_1L0xa0 +#define OMR1BARL 0x100 +#define OMR2BARL 0x118 +#define CFGBARL0x154 +#define CFGBARH0x158 +#define CFGCTL 0x15c +#define RTDID 0x160 +#define CFG_CONSTANTS_31_000x2000 +#define CFG_CONSTANTS_63_320x2004 +#define CFG_CONSTANTS_159_128 0x2010 +#define CFG_CONSTANTS_415_384 0x2030 +#define ENABLE_L1S_POWER_MGMT_SET(dst, src) (((dst) ~0x0200) | \ + (((u32)(src) 0x19) \ + 0x0200)) +#define CFG_CONSTANTS_479_448 0x2038 +#define CFG_8G_CONSTANTS_31_0 0x2100 +#define MGMT_US_PORT_TX_PRESET_SET(dst, src)(((dst) ~0xf00)| \ + (((u32)(src) 0x8) 0xf00)) +#define MGMT_DS_PORT_TX_PRESET_SET(dst, src)(((dst) ~0xf) | \ + (((u32)(src)) 0xf)) + +#define CFG_8G_CONSTANTS_159_1280x2110 +#define EQ_UPDN_POST_STEP_SET(dst, src)(((dst) ~0x30) | \ + (((u32)(src) 0x4) \ + 0x30)) +#define CFG_8G_CONSTANTS_287_2560x2120 +#define CFG_8G_CONSTANTS_319_2880x2124 +#define CFG_8G_CONSTANTS_351_3200x2128 +#define CFG_8G_CONSTANTS_383_3520x212c +#define EQ_PRE_CURSOR_LANE0_SET(dst, src) (((dst) ~0xff) | \ + (((u32)(src)) 0xff)) +#define EQ_PRE_CURSOR_LANE1_SET(dst, src) (((dst) ~0x00ff) | \ + (((u32)(src) 0x10) \ + 0x00ff)) + +#define CFG_CONTROL_63_32 0x2204 +#define CFG_CONTROL_95_64 0x2208 +#define CFG_CONTROL_191_1600x2214
