[PATCH] ahci: Store irq number in struct ahci_host_priv
On 27.05.15 10:01:32, Robert Richter wrote:
From: Robert Richter rrich...@cavium.com
The irq number for msix devices is taken from msi_list instead of
pci_dev. Thus, the irq number of a device needs to be stored in struct
ahci_host_priv now. Host controller can be activated then in a
generic way.
Signed-off-by: Robert Richter rrich...@cavium.com
Rebased version onto libata/for-4.2 below. Please apply 1/3 and 3/3
from the original patch set before and after.
Thanks,
-Robert
From b50a5e478b8fce17603a91a5d272bb49527239af Mon Sep 17 00:00:00 2001
From: Robert Richter rrich...@cavium.com
Date: Tue, 12 May 2015 13:57:27 +0200
Subject: [PATCH] ahci: Store irq number in struct ahci_host_priv
The irq number for msix devices is taken from msi_list instead of
pci_dev. Thus, the irq number of a device needs to be stored in struct
ahci_host_priv now. Host controller can be activated then in a
generic way.
Signed-off-by: Robert Richter rrich...@cavium.com
---
drivers/ata/acard-ahci.c | 4 +++-
drivers/ata/ahci.c | 15 ++-
drivers/ata/ahci.h | 4 ++--
drivers/ata/libahci.c | 16 +++-
drivers/ata/libahci_platform.c | 4 +++-
drivers/ata/sata_highbank.c| 3 ++-
6 files changed, 27 insertions(+), 19 deletions(-)
diff --git a/drivers/ata/acard-ahci.c b/drivers/ata/acard-ahci.c
index 12489ce863c4..ed6a30cd681a 100644
--- a/drivers/ata/acard-ahci.c
+++ b/drivers/ata/acard-ahci.c
@@ -433,6 +433,8 @@ static int acard_ahci_init_one(struct pci_dev *pdev, const
struct pci_device_id
hpriv = devm_kzalloc(dev, sizeof(*hpriv), GFP_KERNEL);
if (!hpriv)
return -ENOMEM;
+
+ hpriv-irq = pdev-irq;
hpriv-flags |= (unsigned long)pi.private_data;
if (!(hpriv-flags AHCI_HFLAG_NO_MSI))
@@ -498,7 +500,7 @@ static int acard_ahci_init_one(struct pci_dev *pdev, const
struct pci_device_id
acard_ahci_pci_print_info(host);
pci_set_master(pdev);
- return ahci_host_activate(host, pdev-irq, acard_ahci_sht);
+ return ahci_host_activate(host, acard_ahci_sht);
}
module_pci_driver(acard_ahci_pci_driver);
diff --git a/drivers/ata/ahci.c b/drivers/ata/ahci.c
index 903ceed88aff..c40bb5670e88 100644
--- a/drivers/ata/ahci.c
+++ b/drivers/ata/ahci.c
@@ -1237,20 +1237,25 @@ static int ahci_init_msi(struct pci_dev *pdev, unsigned
int n_ports,
if (nvec 1)
hpriv-flags |= AHCI_HFLAG_MULTI_MSI;
- return nvec;
+ goto out;
single_msi:
+ nvec = 1;
+
rc = pci_enable_msi(pdev);
if (rc 0)
return rc;
+out:
+ hpriv-irq = pdev-irq;
- return 1;
+ return nvec;
}
static int ahci_init_intx(struct pci_dev *pdev, unsigned int n_ports,
struct ahci_host_priv *hpriv)
{
pci_intx(pdev, 1);
+ hpriv-irq = pdev-irq;
return 0;
}
@@ -1428,13 +1433,13 @@ static int ahci_init_one(struct pci_dev *pdev, const
struct pci_device_id *ent)
*/
n_ports = max(ahci_nr_ports(hpriv-cap), fls(hpriv-port_map));
- ahci_init_interrupts(pdev, n_ports, hpriv);
-
host = ata_host_alloc_pinfo(pdev-dev, ppi, n_ports);
if (!host)
return -ENOMEM;
host-private_data = hpriv;
+ ahci_init_interrupts(pdev, n_ports, hpriv);
+
if (!(hpriv-cap HOST_CAP_SSS) || ahci_ignore_sss)
host-flags |= ATA_HOST_PARALLEL_SCAN;
else
@@ -1480,7 +1485,7 @@ static int ahci_init_one(struct pci_dev *pdev, const
struct pci_device_id *ent)
pci_set_master(pdev);
- return ahci_host_activate(host, pdev-irq, ahci_sht);
+ return ahci_host_activate(host, ahci_sht);
}
module_pci_driver(ahci_pci_driver);
diff --git a/drivers/ata/ahci.h b/drivers/ata/ahci.h
index f4429600e2bf..5b8e8a0fab48 100644
--- a/drivers/ata/ahci.h
+++ b/drivers/ata/ahci.h
@@ -343,6 +343,7 @@ struct ahci_host_priv {
struct phy **phys;
unsignednports; /* Number of ports */
void*plat_data; /* Other platform data */
+ unsigned intirq;/* interrupt line */
/*
* Optional ahci_start_engine override, if not set this gets set to the
* default ahci_start_engine during ahci_save_initial_config, this can
@@ -395,8 +396,7 @@ void ahci_set_em_messages(struct ahci_host_priv *hpriv,
struct ata_port_info *pi);
int ahci_reset_em(struct ata_host *host);
void ahci_print_info(struct ata_host *host, const char *scc_s);
-int ahci_host_activate(struct ata_host *host, int irq,
- struct scsi_host_template *sht);
+int ahci_host_activate(struct ata_host *host, struct scsi_host_template *sht);
void ahci_error_handler(struct ata_port *ap);
static inline void __iomem *__ahci_port_base(struct ata_host *host,
diff --git a/drivers/ata/libahci.c b/drivers/ata
[PATCH v3 0/3] AHCI: Add generic MSI-X interrupt support to SATA PCI driver
From: Robert Richter rrich...@cavium.com This patch set adds generic support for MSI-X interrupts to the SATA PCI driver. The first 2 patches rework the code, one splits msi and intx code into separate functions, the other changes interrupt initialization to store the irq number in the ahci data structure (struct ahci_host_priv). Both changes are needed to implement MSI-X support in the last 3rd patch. v3: * store irq number in struct ahci_host_priv * change initialization order from msix-msi-intx to msi-msix-intx * improve comments in ahci_init_msix() * improve error message in ahci_init_msix() * do not enable MSI-X if MSI is actively disabled for the device v2: * determine irq vector from pci_dev-msi_list Robert Richter (3): ahci: Move interrupt enablement code to separate functions ahci: Store irq number in struct ahci_host_priv AHCI: Add generic MSI-X interrupt support to SATA PCI driver drivers/ata/acard-ahci.c | 4 +- drivers/ata/ahci.c | 138 - drivers/ata/ahci.h | 4 +- drivers/ata/libahci.c | 25 +++- drivers/ata/libahci_platform.c | 4 +- drivers/ata/sata_highbank.c| 3 +- 6 files changed, 143 insertions(+), 35 deletions(-) -- 2.1.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 http://www.tux.org/lkml/
[PATCH v3 1/3] ahci: Move interrupt enablement code to separate functions
From: Robert Richter rrich...@cavium.com
This patch refactors ahci_init_interrupts() and moves code to separate
functions for msi and intx. Needed since we add msix initialization in
a later patch. The initialization for msix is done after msi but
before intx.
Signed-off-by: Robert Richter rrich...@cavium.com
---
drivers/ata/ahci.c | 36 +++-
1 file changed, 27 insertions(+), 9 deletions(-)
diff --git a/drivers/ata/ahci.c b/drivers/ata/ahci.c
index 33bb06e006c9..c8aedd836dc9 100644
--- a/drivers/ata/ahci.c
+++ b/drivers/ata/ahci.c
@@ -1201,17 +1201,17 @@ static inline void ahci_gtf_filter_workaround(struct
ata_host *host)
{}
#endif
-static int ahci_init_interrupts(struct pci_dev *pdev, unsigned int n_ports,
- struct ahci_host_priv *hpriv)
+static int ahci_init_msi(struct pci_dev *pdev, unsigned int n_ports,
+ struct ahci_host_priv *hpriv)
{
int rc, nvec;
if (hpriv-flags AHCI_HFLAG_NO_MSI)
- goto intx;
+ return -ENODEV;
nvec = pci_msi_vec_count(pdev);
if (nvec 0)
- goto intx;
+ return nvec;
/*
* If number of MSIs is less than number of ports then Sharing Last
@@ -1224,8 +1224,8 @@ static int ahci_init_interrupts(struct pci_dev *pdev,
unsigned int n_ports,
rc = pci_enable_msi_exact(pdev, nvec);
if (rc == -ENOSPC)
goto single_msi;
- else if (rc 0)
- goto intx;
+ if (rc 0)
+ return rc;
/* fallback to single MSI mode if the controller enforced MRSM mode */
if (readl(hpriv-mmio + HOST_CTL) HOST_MRSM) {
@@ -1240,15 +1240,33 @@ static int ahci_init_interrupts(struct pci_dev *pdev,
unsigned int n_ports,
return nvec;
single_msi:
- if (pci_enable_msi(pdev))
- goto intx;
+ rc = pci_enable_msi(pdev);
+ if (rc 0)
+ return rc;
+
return 1;
+}
-intx:
+static int ahci_init_intx(struct pci_dev *pdev, unsigned int n_ports,
+ struct ahci_host_priv *hpriv)
+{
pci_intx(pdev, 1);
+
return 0;
}
+static int ahci_init_interrupts(struct pci_dev *pdev, unsigned int n_ports,
+ struct ahci_host_priv *hpriv)
+{
+ int nvec;
+
+ nvec = ahci_init_msi(pdev, n_ports, hpriv);
+ if (nvec = 0)
+ return nvec;
+
+ return ahci_init_intx(pdev, n_ports, hpriv);
+}
+
static int ahci_init_one(struct pci_dev *pdev, const struct pci_device_id *ent)
{
unsigned int board_id = ent-driver_data;
--
2.1.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 http://www.tux.org/lkml/
[PATCH v3 2/3] ahci: Store irq number in struct ahci_host_priv
From: Robert Richter rrich...@cavium.com
The irq number for msix devices is taken from msi_list instead of
pci_dev. Thus, the irq number of a device needs to be stored in struct
ahci_host_priv now. Host controller can be activated then in a
generic way.
Signed-off-by: Robert Richter rrich...@cavium.com
---
drivers/ata/acard-ahci.c | 4 +++-
drivers/ata/ahci.c | 15 ++-
drivers/ata/ahci.h | 4 ++--
drivers/ata/libahci.c | 25 ++---
drivers/ata/libahci_platform.c | 4 +++-
drivers/ata/sata_highbank.c| 3 ++-
6 files changed, 30 insertions(+), 25 deletions(-)
diff --git a/drivers/ata/acard-ahci.c b/drivers/ata/acard-ahci.c
index c962886d7e71..c67fce2a4cbf 100644
--- a/drivers/ata/acard-ahci.c
+++ b/drivers/ata/acard-ahci.c
@@ -433,6 +433,8 @@ static int acard_ahci_init_one(struct pci_dev *pdev, const
struct pci_device_id
hpriv = devm_kzalloc(dev, sizeof(*hpriv), GFP_KERNEL);
if (!hpriv)
return -ENOMEM;
+
+ hpriv-irq = pdev-irq;
hpriv-flags |= (unsigned long)pi.private_data;
if (!(hpriv-flags AHCI_HFLAG_NO_MSI))
@@ -498,7 +500,7 @@ static int acard_ahci_init_one(struct pci_dev *pdev, const
struct pci_device_id
acard_ahci_pci_print_info(host);
pci_set_master(pdev);
- return ahci_host_activate(host, pdev-irq, acard_ahci_sht);
+ return ahci_host_activate(host, acard_ahci_sht);
}
module_pci_driver(acard_ahci_pci_driver);
diff --git a/drivers/ata/ahci.c b/drivers/ata/ahci.c
index c8aedd836dc9..8cdc9ebbbc43 100644
--- a/drivers/ata/ahci.c
+++ b/drivers/ata/ahci.c
@@ -1237,20 +1237,25 @@ static int ahci_init_msi(struct pci_dev *pdev, unsigned
int n_ports,
if (nvec 1)
hpriv-flags |= AHCI_HFLAG_MULTI_MSI;
- return nvec;
+ goto out;
single_msi:
+ nvec = 1;
+
rc = pci_enable_msi(pdev);
if (rc 0)
return rc;
+out:
+ hpriv-irq = pdev-irq;
- return 1;
+ return nvec;
}
static int ahci_init_intx(struct pci_dev *pdev, unsigned int n_ports,
struct ahci_host_priv *hpriv)
{
pci_intx(pdev, 1);
+ hpriv-irq = pdev-irq;
return 0;
}
@@ -1428,13 +1433,13 @@ static int ahci_init_one(struct pci_dev *pdev, const
struct pci_device_id *ent)
*/
n_ports = max(ahci_nr_ports(hpriv-cap), fls(hpriv-port_map));
- ahci_init_interrupts(pdev, n_ports, hpriv);
-
host = ata_host_alloc_pinfo(pdev-dev, ppi, n_ports);
if (!host)
return -ENOMEM;
host-private_data = hpriv;
+ ahci_init_interrupts(pdev, n_ports, hpriv);
+
if (!(hpriv-cap HOST_CAP_SSS) || ahci_ignore_sss)
host-flags |= ATA_HOST_PARALLEL_SCAN;
else
@@ -1480,7 +1485,7 @@ static int ahci_init_one(struct pci_dev *pdev, const
struct pci_device_id *ent)
pci_set_master(pdev);
- return ahci_host_activate(host, pdev-irq, ahci_sht);
+ return ahci_host_activate(host, ahci_sht);
}
module_pci_driver(ahci_pci_driver);
diff --git a/drivers/ata/ahci.h b/drivers/ata/ahci.h
index 71262e08648e..f219507b1fbc 100644
--- a/drivers/ata/ahci.h
+++ b/drivers/ata/ahci.h
@@ -341,6 +341,7 @@ struct ahci_host_priv {
struct phy **phys;
unsignednports; /* Number of ports */
void*plat_data; /* Other platform data */
+ unsigned intirq;/* interrupt line */
/*
* Optional ahci_start_engine override, if not set this gets set to the
* default ahci_start_engine during ahci_save_initial_config, this can
@@ -393,8 +394,7 @@ void ahci_set_em_messages(struct ahci_host_priv *hpriv,
struct ata_port_info *pi);
int ahci_reset_em(struct ata_host *host);
void ahci_print_info(struct ata_host *host, const char *scc_s);
-int ahci_host_activate(struct ata_host *host, int irq,
- struct scsi_host_template *sht);
+int ahci_host_activate(struct ata_host *host, struct scsi_host_template *sht);
void ahci_error_handler(struct ata_port *ap);
static inline void __iomem *__ahci_port_base(struct ata_host *host,
diff --git a/drivers/ata/libahci.c b/drivers/ata/libahci.c
index 61a9c07e0dff..022da7ce77fb 100644
--- a/drivers/ata/libahci.c
+++ b/drivers/ata/libahci.c
@@ -2298,7 +2298,7 @@ static int ahci_port_start(struct ata_port *ap)
/*
* Switch to per-port locking in case each port has its own MSI vector.
*/
- if ((hpriv-flags AHCI_HFLAG_MULTI_MSI)) {
+ if (hpriv-flags AHCI_HFLAG_MULTI_MSI) {
spin_lock_init(pp-lock);
ap-lock = pp-lock;
}
@@ -2426,7 +2426,10 @@ static int ahci_host_activate_multi_irqs(struct ata_host
*host, int irq,
rc = ata_host_start(host);
if (rc)
return rc
[PATCH v3 3/3] AHCI: Add generic MSI-X interrupt support to SATA PCI driver
From: Robert Richter rrich...@cavium.com
This patch adds generic support for MSI-X interrupts to the SATA PCI
driver. MSI-X support is needed for host controller that only have
MSI-X support implemented, such as the controller on Cavium's ThunderX
SoC. Only support for single interrupts is added, multiple per-port
MSI-X interrupts are not yet implemented.
The new implementation still initializes MSIs first. Only if that
fails, the code tries to enable MSI-X. If that fails too, setup is
continued with intx interrupts.
To not break other chips by this generic code change, there are the
following precautions:
* Interrupt ranges are not enabled at all.
* Only single interrupt mode is enabled for msix cap devices. These
devices require a single port only or a total number of int entries
less than the total number of ports. In this case only one
interrupt will be enabled.
* During the discussion with Tejun we agreed to change the init
sequence from msix-msi-intx to msi-msix-intx. Thus, if a device
offers msi and init does not fail, the msix init code will not be
executed. This is equivalent to current code.
With this, the code only setups single mode msix as a last resort if
msi fails. No interrupt range is enabled at all. Only one interrupt
will be enabled.
v3:
* store irq number in struct ahci_host_priv
* change initialization order from msix-msi-intx to msi-msix-intx
* improve comments in ahci_init_msix()
* improve error message in ahci_init_msix()
* do not enable MSI-X if MSI is actively disabled for the device
v2:
* determine irq vector from pci_dev-msi_list
Based on a patch from Sunil Goutham sgout...@cavium.com.
Signed-off-by: Robert Richter rrich...@cavium.com
---
drivers/ata/ahci.c | 87 +-
1 file changed, 86 insertions(+), 1 deletion(-)
diff --git a/drivers/ata/ahci.c b/drivers/ata/ahci.c
index 8cdc9ebbbc43..8245f75be6b6 100644
--- a/drivers/ata/ahci.c
+++ b/drivers/ata/ahci.c
@@ -42,6 +42,7 @@
#include linux/device.h
#include linux/dmi.h
#include linux/gfp.h
+#include linux/msi.h
#include scsi/scsi_host.h
#include scsi/scsi_cmnd.h
#include linux/libata.h
@@ -52,6 +53,7 @@
enum {
AHCI_PCI_BAR_STA2X11= 0,
+ AHCI_PCI_BAR_CAVIUM = 0,
AHCI_PCI_BAR_ENMOTUS= 2,
AHCI_PCI_BAR_STANDARD = 5,
};
@@ -499,6 +501,9 @@ static const struct pci_device_id ahci_pci_tbl[] = {
/* Enmotus */
{ PCI_DEVICE(0x1c44, 0x8000), board_ahci },
+ /* Cavium */
+ { PCI_DEVICE(0x177d, 0xa01c), .driver_data = board_ahci },
+
/* Generic, PCI class code for AHCI */
{ PCI_ANY_ID, PCI_ANY_ID, PCI_ANY_ID, PCI_ANY_ID,
PCI_CLASS_STORAGE_SATA_AHCI, 0xff, board_ahci },
@@ -1201,6 +1206,80 @@ static inline void ahci_gtf_filter_workaround(struct
ata_host *host)
{}
#endif
+static struct msi_desc *msix_get_desc(struct pci_dev *dev, u16 entry)
+{
+ struct msi_desc *desc;
+
+ list_for_each_entry(desc, dev-msi_list, list) {
+ if (desc-msi_attrib.entry_nr == entry)
+ return desc;
+ }
+
+ return NULL;
+}
+
+static int ahci_init_msix(struct pci_dev *pdev, unsigned int n_ports,
+ struct ahci_host_priv *hpriv)
+{
+ struct msi_desc *desc;
+ int rc, nvec;
+ struct msix_entry entry = {};
+
+ /* Do not init MSI-X if MSI is disabled for the device */
+ if (hpriv-flags AHCI_HFLAG_NO_MSI)
+ return -ENODEV;
+
+ nvec = pci_msix_vec_count(pdev);
+ if (nvec 0)
+ return nvec;
+
+ if (!nvec) {
+ rc = -ENODEV;
+ goto fail;
+ }
+
+ /*
+* Per-port msix interrupts are not supported. Assume single
+* port interrupts for:
+*
+* n_ports == 1, or
+* nvec n_ports.
+*
+* We also need to check for n_ports != 0 which is implicitly
+* covered here since nvec 0.
+*/
+ if (n_ports != 1 nvec = n_ports) {
+ rc = -ENOSYS;
+ goto fail;
+ }
+
+ /*
+* There can exist more than one vector (e.g. for error
+* detection or hdd hotplug). Then the first vector is used,
+* all others are ignored. Only enable the first entry here
+* (entry.entry = 0).
+*/
+ rc = pci_enable_msix_exact(pdev, entry, 1);
+ if (rc 0)
+ goto fail;
+
+ desc = msix_get_desc(pdev, 0); /* first entry */
+ if (!desc) {
+ rc = -EINVAL;
+ goto fail;
+ }
+
+ hpriv-irq = desc-irq;
+
+ return 1;
+fail:
+ dev_err(pdev-dev,
+ failed to enable MSI-X with error %d, # of vectors: %d\n,
+ rc, nvec);
+
+ return rc;
+}
+
static int ahci_init_msi(struct pci_dev *pdev, unsigned int n_ports,
struct ahci_host_priv *hpriv
Re: [PATCH 4/4] arm64: gicv3: its: Increase FORCE_MAX_ZONEORDER for Cavium ThunderX
On 21.05.15 09:35:47, Marc Zyngier wrote: > On 20/05/15 17:48, Catalin Marinas wrote: > > On Wed, May 20, 2015 at 02:31:59PM +0200, Robert Richter wrote: > >> On 20.05.15 13:22:13, Marc Zyngier wrote: > >>> On Tue, 12 May 2015 18:24:16 +0100 > >>> Will Deacon wrote: > >>>> On Tue, May 12, 2015 at 05:20:49PM +0100, Robert Richter wrote: > >>>>> On 12.05.15 13:30:57, Will Deacon wrote: > >> > >>>>> For allocation of 16MB cont. phys mem of a defconfig kernel (4KB > >>>>> default pagesize) I see this different approaches: > >>>> > >>>> 16MB sounds like an awful lot. Is this because you have tonnes of MSIs or > >>>> a sparse DeviceID space or both? > >>> > >>> That's probably due to the sparseness of the DeviceID space. With some > >>> form of bridge number encoded on top of the BFD number, the device > >>> table is enormous, and I don't see a nice way to avoid it... > >> > >> Right. At the momement out of 21 bits (16MB) we currently have 2 spare > >> bits, which reduces the actually size used to 4MB. Though, for the > >> current cpu model we can reduce it at least to 8MB total. > >> > >> I will come up with an additional patch setting this to 8MB. > >> > >> As said before, I also write on a patch to use CMA. > > > > Can we not reserve a chunk of memory and pass the information to the > > kernel via DT (/memreserve/ and a new GIC-specific binding)? > > That would have to be done on a per-table basis then. And how would that > work with ACPI? I don't think the ACPI ITS table specifies anything in > that respect. > > We're just facing the horrible reality that linear tables are not very > well suited to sparse addressing. Nobody copied the VAX MMU model for a > reason... until now. We could still fall back to mem alloc if the DT or ACPI does not provide a base address for the table. For know I would prefer to just implement mem allocation with CMA. -Robert -- 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 4/4] arm64: gicv3: its: Increase FORCE_MAX_ZONEORDER for Cavium ThunderX
On 21.05.15 09:35:47, Marc Zyngier wrote: On 20/05/15 17:48, Catalin Marinas wrote: On Wed, May 20, 2015 at 02:31:59PM +0200, Robert Richter wrote: On 20.05.15 13:22:13, Marc Zyngier wrote: On Tue, 12 May 2015 18:24:16 +0100 Will Deacon will.dea...@arm.com wrote: On Tue, May 12, 2015 at 05:20:49PM +0100, Robert Richter wrote: On 12.05.15 13:30:57, Will Deacon wrote: For allocation of 16MB cont. phys mem of a defconfig kernel (4KB default pagesize) I see this different approaches: 16MB sounds like an awful lot. Is this because you have tonnes of MSIs or a sparse DeviceID space or both? That's probably due to the sparseness of the DeviceID space. With some form of bridge number encoded on top of the BFD number, the device table is enormous, and I don't see a nice way to avoid it... Right. At the momement out of 21 bits (16MB) we currently have 2 spare bits, which reduces the actually size used to 4MB. Though, for the current cpu model we can reduce it at least to 8MB total. I will come up with an additional patch setting this to 8MB. As said before, I also write on a patch to use CMA. Can we not reserve a chunk of memory and pass the information to the kernel via DT (/memreserve/ and a new GIC-specific binding)? That would have to be done on a per-table basis then. And how would that work with ACPI? I don't think the ACPI ITS table specifies anything in that respect. We're just facing the horrible reality that linear tables are not very well suited to sparse addressing. Nobody copied the VAX MMU model for a reason... until now. We could still fall back to mem alloc if the DT or ACPI does not provide a base address for the table. For know I would prefer to just implement mem allocation with CMA. -Robert -- 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 1/4] arm64: gicv3: its: Encode domain number in PCI stream id
Mark, thanks for review, also of the other patches of this series. See below On 20.05.15 13:11:38, Marc Zyngier wrote: > > - dev_alias->dev_id = alias; > > + dev_alias->dev_id = (pci_domain_nr(pdev->bus) << 16) | alias; > This feels very scary. We're now assuming that the domain number will > always be presented to the doorbell. What guarantee do we have that > this is always the case, irrespective of the platform? > > Also, domains have no PCI reality, they are a Linux thing. And they can > be "randomly" assigned, unless you force the domain in DT with a > linux,pci-domain property. This looks even more wrong, specially > considering ACPI. The main problem here is that device ids (32 bits) are system specific. Since we have more than one PCI root complex we need the upper 16 bits in the devid for mapping. Using pci_domain_nr for this fits our needs for now and shouldn't affect systems with a single RC only as the domain nr is zero then. The domain number is incremented during initialization beginnig with zero and the order of it is fixed since it is taken from DT or ACPI tables. So we have full controll of it. I don't see issues here. > It really feels like we need a way to describe how the BDF numbering is > augmented. We also need to guarantee that we get the actual bridge > number, as opposed to the domain number. But true, the obove is just intermediate. In the end we need some sort of handler that is setup during cpu initialization that registers a callback for the gic to determine the device id of that paricular system. -Robert -- 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 4/4] arm64: gicv3: its: Increase FORCE_MAX_ZONEORDER for Cavium ThunderX
On 20.05.15 13:22:13, Marc Zyngier wrote: > On Tue, 12 May 2015 18:24:16 +0100 > Will Deacon wrote: > > On Tue, May 12, 2015 at 05:20:49PM +0100, Robert Richter wrote: > > > On 12.05.15 13:30:57, Will Deacon wrote: > > > For allocation of 16MB cont. phys mem of a defconfig kernel (4KB > > > default pagesize) I see this different approaches: > > > > 16MB sounds like an awful lot. Is this because you have tonnes of MSIs or > > a sparse DeviceID space or both? > > That's probably due to the sparseness of the DeviceID space. With some > form of bridge number encoded on top of the BFD number, the device > table is enormous, and I don't see a nice way to avoid it... Right. At the momement out of 21 bits (16MB) we currently have 2 spare bits, which reduces the actually size used to 4MB. Though, for the current cpu model we can reduce it at least to 8MB total. I will come up with an additional patch setting this to 8MB. As said before, I also write on a patch to use CMA. Thanks, -Robert -- 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 4/4] arm64: gicv3: its: Increase FORCE_MAX_ZONEORDER for Cavium ThunderX
On 20.05.15 13:22:13, Marc Zyngier wrote: On Tue, 12 May 2015 18:24:16 +0100 Will Deacon will.dea...@arm.com wrote: On Tue, May 12, 2015 at 05:20:49PM +0100, Robert Richter wrote: On 12.05.15 13:30:57, Will Deacon wrote: For allocation of 16MB cont. phys mem of a defconfig kernel (4KB default pagesize) I see this different approaches: 16MB sounds like an awful lot. Is this because you have tonnes of MSIs or a sparse DeviceID space or both? That's probably due to the sparseness of the DeviceID space. With some form of bridge number encoded on top of the BFD number, the device table is enormous, and I don't see a nice way to avoid it... Right. At the momement out of 21 bits (16MB) we currently have 2 spare bits, which reduces the actually size used to 4MB. Though, for the current cpu model we can reduce it at least to 8MB total. I will come up with an additional patch setting this to 8MB. As said before, I also write on a patch to use CMA. Thanks, -Robert -- 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 1/4] arm64: gicv3: its: Encode domain number in PCI stream id
Mark, thanks for review, also of the other patches of this series. See below On 20.05.15 13:11:38, Marc Zyngier wrote: - dev_alias-dev_id = alias; + dev_alias-dev_id = (pci_domain_nr(pdev-bus) 16) | alias; This feels very scary. We're now assuming that the domain number will always be presented to the doorbell. What guarantee do we have that this is always the case, irrespective of the platform? Also, domains have no PCI reality, they are a Linux thing. And they can be randomly assigned, unless you force the domain in DT with a linux,pci-domain property. This looks even more wrong, specially considering ACPI. The main problem here is that device ids (32 bits) are system specific. Since we have more than one PCI root complex we need the upper 16 bits in the devid for mapping. Using pci_domain_nr for this fits our needs for now and shouldn't affect systems with a single RC only as the domain nr is zero then. The domain number is incremented during initialization beginnig with zero and the order of it is fixed since it is taken from DT or ACPI tables. So we have full controll of it. I don't see issues here. It really feels like we need a way to describe how the BDF numbering is augmented. We also need to guarantee that we get the actual bridge number, as opposed to the domain number. But true, the obove is just intermediate. In the end we need some sort of handler that is setup during cpu initialization that registers a callback for the gic to determine the device id of that paricular system. -Robert -- 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 v2] AHCI: Add generic MSI-X interrupt support to SATA PCI driver
On 17.05.15 08:33:32, Alexander Gordeev wrote: > You enable MSI-X for a single chip, but introduce a change to the > generic AHCI code. > > In general MSI-X case, what makes you believe that IRQ vectors are > assigned continuously? > > (Interface ahci_host_activate() kinda expects a contiguous vector > range, but MSI-X does not guarantee that at all). That's the reason why I only enable single interrupt mode which our hardware supports. To not break other chips by this generic code change, there are the following precautions: * Interrupt ranges are not enabled at all. * Only single interrupt mode is enabled for msix cap devices. These devices require a single port only or a total number of int entries less than the total number of ports. In this case only one interrupt will be enabled. * During the discussion with Tejun we agreed to change the init sequence from msix-msi-intx to msi-msix-intx. Thus, if a device offers msi and init does not fail, the msix init code will not be executed. This is equivalent to current code. With this, the code only setups single mode msix as a last resort if msi fails. No interrupt range is enabled at all. Only one interrupt will be enabled. Considering all this I think your concerns are addressed. Also, the code can be easily extended for other devices and thus should be generic from the beginning. -Robert -- 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 v2] AHCI: Add generic MSI-X interrupt support to SATA PCI driver
On 17.05.15 08:33:32, Alexander Gordeev wrote: You enable MSI-X for a single chip, but introduce a change to the generic AHCI code. In general MSI-X case, what makes you believe that IRQ vectors are assigned continuously? (Interface ahci_host_activate() kinda expects a contiguous vector range, but MSI-X does not guarantee that at all). That's the reason why I only enable single interrupt mode which our hardware supports. To not break other chips by this generic code change, there are the following precautions: * Interrupt ranges are not enabled at all. * Only single interrupt mode is enabled for msix cap devices. These devices require a single port only or a total number of int entries less than the total number of ports. In this case only one interrupt will be enabled. * During the discussion with Tejun we agreed to change the init sequence from msix-msi-intx to msi-msix-intx. Thus, if a device offers msi and init does not fail, the msix init code will not be executed. This is equivalent to current code. With this, the code only setups single mode msix as a last resort if msi fails. No interrupt range is enabled at all. Only one interrupt will be enabled. Considering all this I think your concerns are addressed. Also, the code can be easily extended for other devices and thus should be generic from the beginning. -Robert -- 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 v2] AHCI: Add generic MSI-X interrupt support to SATA PCI driver
On 13.05.15 13:46:40, Tejun Heo wrote: > Hello, Robert. > > On Wed, May 13, 2015 at 07:28:28PM +0200, Robert Richter wrote: > > > > This looks not very useful to do. Since irq is used only a single > > > > time, there is no reason to store it in the host's data structure. It > > > > > > Doesn't really matter tho. > > > > Since ahci_host_activate() is EXPORT_SYMBOL_GPL I really have concerns > > changing the i/f. But I will send you a patch for this. > > It doesn't matter. Please go ahead and change it. Ok, np. > > > Let's start with why we're doing this in the first place. > > > > Right, the sata controller is connected to a pci ecam controller, both > > are on an SoC together with the processor. There are no external pci > > ports for the connection of external devices. Since all pci devices on > > the chip support msi-x, the controller is only capable to handle this > > and not INTx nor MSI. So for enabling of the sata hc we need msix > > support. > > I see. If you can get hold of an ahci controller which actually can > do multi-irq msix, it'd be the best. If not, let's make it super > clear that this is a special case and use it as the last resort (which > also clers up the warning issue). This sounds good. The device actually supports multi-irq msix, a single mode interrupt + additional interrupts for error or hotplug handling. But I don't have hardware for a per-port msix host controller. So I will move msix after msi then and mark it as a special case if msi is not supported. I don't want to move it after intx since this is the fallback if nothing else works, there is no explicit check for intx, I even don't know if that is possible at all. Thanks, -Robert -- 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 v2] AHCI: Add generic MSI-X interrupt support to SATA PCI driver
Tejun, On 13.05.15 10:39:06, Tejun Heo wrote: > On Tue, May 12, 2015 at 01:46:47PM +0200, Robert Richter wrote: > > I don't think this is worth the effort as all internal and external > > drivers need to be changed basically from: > > > > ahci_host_activate(host, irq, _sht); > > > > to: > > > > host->irq = irq; > > ahci_host_activate(host, _sht); > > > > This looks not very useful to do. Since irq is used only a single > > time, there is no reason to store it in the host's data structure. It > > Doesn't really matter tho. Since ahci_host_activate() is EXPORT_SYMBOL_GPL I really have concerns changing the i/f. But I will send you a patch for this. > > also makes the interface more error prone since host->irq might not be > > setup. Apart from that there is an abi change. > > But large part of @host needs to be initialized before activation. I > don't think moving irq to that pool changes much if anything. > > > I agree that we will need the implemention of host->ports[i]->irq for > > the case there irqs are no longer in sequential order as this might be > > the case for per-port msi-x interrupts. But this is not the focus of > > my implementation and as long there is no hardware for this available, > > it wouldn't make sense to implement this at all. > > Why are we doing msix at all? I don't get it. See below. > > So how to proceed? I could send you patches that implement host->irq > > for a single per-host interrupt, and also one that reworks multi-port > > interrupts to use host->ports[i]->irq. But I don't see any benefit > > here. That said, I would better keep my patch here as it is. That do > > you think? > > Let's start with why we're doing this in the first place. Right, the sata controller is connected to a pci ecam controller, both are on an SoC together with the processor. There are no external pci ports for the connection of external devices. Since all pci devices on the chip support msi-x, the controller is only capable to handle this and not INTx nor MSI. So for enabling of the sata hc we need msix support. -Robert -- 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 v2] AHCI: Add generic MSI-X interrupt support to SATA PCI driver
Tejun, On 13.05.15 10:39:06, Tejun Heo wrote: On Tue, May 12, 2015 at 01:46:47PM +0200, Robert Richter wrote: I don't think this is worth the effort as all internal and external drivers need to be changed basically from: ahci_host_activate(host, irq, ahci_sht); to: host-irq = irq; ahci_host_activate(host, ahci_sht); This looks not very useful to do. Since irq is used only a single time, there is no reason to store it in the host's data structure. It Doesn't really matter tho. Since ahci_host_activate() is EXPORT_SYMBOL_GPL I really have concerns changing the i/f. But I will send you a patch for this. also makes the interface more error prone since host-irq might not be setup. Apart from that there is an abi change. But large part of @host needs to be initialized before activation. I don't think moving irq to that pool changes much if anything. I agree that we will need the implemention of host-ports[i]-irq for the case there irqs are no longer in sequential order as this might be the case for per-port msi-x interrupts. But this is not the focus of my implementation and as long there is no hardware for this available, it wouldn't make sense to implement this at all. Why are we doing msix at all? I don't get it. See below. So how to proceed? I could send you patches that implement host-irq for a single per-host interrupt, and also one that reworks multi-port interrupts to use host-ports[i]-irq. But I don't see any benefit here. That said, I would better keep my patch here as it is. That do you think? Let's start with why we're doing this in the first place. Right, the sata controller is connected to a pci ecam controller, both are on an SoC together with the processor. There are no external pci ports for the connection of external devices. Since all pci devices on the chip support msi-x, the controller is only capable to handle this and not INTx nor MSI. So for enabling of the sata hc we need msix support. -Robert -- 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 v2] AHCI: Add generic MSI-X interrupt support to SATA PCI driver
On 13.05.15 13:46:40, Tejun Heo wrote: Hello, Robert. On Wed, May 13, 2015 at 07:28:28PM +0200, Robert Richter wrote: This looks not very useful to do. Since irq is used only a single time, there is no reason to store it in the host's data structure. It Doesn't really matter tho. Since ahci_host_activate() is EXPORT_SYMBOL_GPL I really have concerns changing the i/f. But I will send you a patch for this. It doesn't matter. Please go ahead and change it. Ok, np. Let's start with why we're doing this in the first place. Right, the sata controller is connected to a pci ecam controller, both are on an SoC together with the processor. There are no external pci ports for the connection of external devices. Since all pci devices on the chip support msi-x, the controller is only capable to handle this and not INTx nor MSI. So for enabling of the sata hc we need msix support. I see. If you can get hold of an ahci controller which actually can do multi-irq msix, it'd be the best. If not, let's make it super clear that this is a special case and use it as the last resort (which also clers up the warning issue). This sounds good. The device actually supports multi-irq msix, a single mode interrupt + additional interrupts for error or hotplug handling. But I don't have hardware for a per-port msix host controller. So I will move msix after msi then and mark it as a special case if msi is not supported. I don't want to move it after intx since this is the fallback if nothing else works, there is no explicit check for intx, I even don't know if that is possible at all. Thanks, -Robert -- 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 4/4] arm64: gicv3: its: Increase FORCE_MAX_ZONEORDER for Cavium ThunderX
On 12.05.15 18:24:16, Will Deacon wrote: > On Tue, May 12, 2015 at 05:20:49PM +0100, Robert Richter wrote: > > For allocation of 16MB cont. phys mem of a defconfig kernel (4KB > > default pagesize) I see this different approaches: > > 16MB sounds like an awful lot. Is this because you have tonnes of MSIs or > a sparse DeviceID space or both? > > > * set FORCE_MAX_ZONEORDER to 13 as default, > > > > * set FORCE_MAX_ZONEORDER to 13 if ARM_GIC_V3 is set, > > > > * set FORCE_MAX_ZONEORDER to 13 if ARCH_THUNDER is set (this patch), > > I'm not hugely fond of these suggestions, as there's still no guarantee > that such a huge allocation is going to succeed and we end up bumping > MAX_ORDER for all platforms in defconfig if we enable THUNDER there. I actually was expecting this... > > * use hugepages if enabled (defconfig has the following options > >enable: CGROUP_HUGETLB, TRANSPARENT_HUGEPAGE, HUGETLBFS, this might > >work with current default kernel without changing defconfig > >options), > > I don't think hugepages help with DMA. > > > * use devicetree to reserve mem for gicv3 (need to check ACPI). I am quite a bit concerned letting firmware handle this. But if that would solve it, fine. > Using a carveout like this might be the best bet. I assume the memory used > by the ITS can never be reclaimed by the syste (and therefore there's no > issue with wastage)? > > > Do you see any direction? > > Dunno, does CMA also require the MAX_ORDER bump? Looks promising at the first glance. Will look into it. Thanks, -Robert -- 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 4/4] arm64: gicv3: its: Increase FORCE_MAX_ZONEORDER for Cavium ThunderX
Will, On 12.05.15 13:30:57, Will Deacon wrote: > On Mon, May 11, 2015 at 10:14:38AM +0100, Robert Richter wrote: > > On 05.05.15 11:53:29, Will Deacon wrote: > > > On Sun, May 03, 2015 at 09:49:32PM +0100, Robert Richter wrote: > > > > From: Radha Mohan Chintakuntla > > > > > > > > In case of ARCH_THUNDER, there is a need to allocate the GICv3 ITS table > > > > which is bigger than the allowed max order. So we are forcing it only in > > > > case of 4KB page size. > > > > > > Does this problem disappear if the ITS driver uses dma_alloc_coherent > > > instead? That would also allow us to remove the __flush_dcache_area abuse > > > from the driver. > > > > __get_free_pages() is also used internally in dma_alloc_coherent(). > > > > There is another case if the device brings dma mem with it. I am not > > sure if it would be possible to assign some phys memory via devicetree > > to the interrupt controller and then assign that range for its table > > allocation. > > > > Another option would be to allocate a hugepage. This would require > > setting up hugepages during boottime. I need to figure out whether > > that could work. For allocation of 16MB cont. phys mem of a defconfig kernel (4KB default pagesize) I see this different approaches: * set FORCE_MAX_ZONEORDER to 13 as default, * set FORCE_MAX_ZONEORDER to 13 if ARM_GIC_V3 is set, * set FORCE_MAX_ZONEORDER to 13 if ARCH_THUNDER is set (this patch), * use hugepages if enabled (defconfig has the following options enable: CGROUP_HUGETLB, TRANSPARENT_HUGEPAGE, HUGETLBFS, this might work with current default kernel without changing defconfig options), * use devicetree to reserve mem for gicv3 (need to check ACPI). Do you see any direction? > > What about on the remaining 3 patches? > > Marc would be the best guy to review those, but he's on holiday for a couple > of weeks at the moment. Thanks for the note and your comments. -Robert -- 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 v2] AHCI: Add generic MSI-X interrupt support to SATA PCI driver
Tejun,
On 11.05.15 19:18:10, Robert Richter wrote:
> > > +static int ahci_init_interrupts(struct pci_dev *pdev, unsigned int
> > > n_ports,
> > > + struct ahci_host_priv *hpriv)
> > > +{
> > > + struct msi_desc *desc;
> > > +
> > > + __ahci_init_interrupts(pdev, n_ports, hpriv);
> > > +
> > > + if (!pdev->msix_enabled)
> > > + return pdev->irq;
> > > +
> > > + desc = msix_get_desc(pdev, 0); /* first entry */
> > > + if (!desc)
> > > + return -ENODEV;
> > > +
> > > + return desc->irq;
> > > +}
> >
> > Can we please do this properly? We should be able to move port priv
> > allocation to host allocaotion time and add and use pp->irq instead,
> > right?
>
> I started working implementing this.
>
> Will send an updated patch set once finished.
A couple of questions here.
If we store the irq for each port separate in host->ports[i]->irq,
then there are duplicates for !AHCI_HFLAG_MULTI_MSI. We can not
iterate over all ports then to initialize the interrupt. Instead we
need to check for !AHCI_HFLAG_MULTI_MSI and store in that case the irq
in host->irq. This would avoid initializing duplicates and makes
host->ports[i]->irq only useful for multi-msi. Right now multi-msi
uses a base irq + index to register all irqs. This makes
host->ports[i]->irq obsolete at all.
Now, adding host->irq would change the function interface of
ahci_host_activate() to:
int ahci_host_activate(struct ata_host *host, struct scsi_host_template *sht);
I don't think this is worth the effort as all internal and external
drivers need to be changed basically from:
ahci_host_activate(host, irq, _sht);
to:
host->irq = irq;
ahci_host_activate(host, _sht);
This looks not very useful to do. Since irq is used only a single
time, there is no reason to store it in the host's data structure. It
also makes the interface more error prone since host->irq might not be
setup. Apart from that there is an abi change.
I agree that we will need the implemention of host->ports[i]->irq for
the case there irqs are no longer in sequential order as this might be
the case for per-port msi-x interrupts. But this is not the focus of
my implementation and as long there is no hardware for this available,
it wouldn't make sense to implement this at all.
So how to proceed? I could send you patches that implement host->irq
for a single per-host interrupt, and also one that reworks multi-port
interrupts to use host->ports[i]->irq. But I don't see any benefit
here. That said, I would better keep my patch here as it is. That do
you think?
Thanks,
-Robert
--
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 4/4] arm64: gicv3: its: Increase FORCE_MAX_ZONEORDER for Cavium ThunderX
On 12.05.15 18:24:16, Will Deacon wrote: On Tue, May 12, 2015 at 05:20:49PM +0100, Robert Richter wrote: For allocation of 16MB cont. phys mem of a defconfig kernel (4KB default pagesize) I see this different approaches: 16MB sounds like an awful lot. Is this because you have tonnes of MSIs or a sparse DeviceID space or both? * set FORCE_MAX_ZONEORDER to 13 as default, * set FORCE_MAX_ZONEORDER to 13 if ARM_GIC_V3 is set, * set FORCE_MAX_ZONEORDER to 13 if ARCH_THUNDER is set (this patch), I'm not hugely fond of these suggestions, as there's still no guarantee that such a huge allocation is going to succeed and we end up bumping MAX_ORDER for all platforms in defconfig if we enable THUNDER there. I actually was expecting this... * use hugepages if enabled (defconfig has the following options enable: CGROUP_HUGETLB, TRANSPARENT_HUGEPAGE, HUGETLBFS, this might work with current default kernel without changing defconfig options), I don't think hugepages help with DMA. * use devicetree to reserve mem for gicv3 (need to check ACPI). I am quite a bit concerned letting firmware handle this. But if that would solve it, fine. Using a carveout like this might be the best bet. I assume the memory used by the ITS can never be reclaimed by the syste (and therefore there's no issue with wastage)? Do you see any direction? Dunno, does CMA also require the MAX_ORDER bump? Looks promising at the first glance. Will look into it. Thanks, -Robert -- 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 4/4] arm64: gicv3: its: Increase FORCE_MAX_ZONEORDER for Cavium ThunderX
Will, On 12.05.15 13:30:57, Will Deacon wrote: On Mon, May 11, 2015 at 10:14:38AM +0100, Robert Richter wrote: On 05.05.15 11:53:29, Will Deacon wrote: On Sun, May 03, 2015 at 09:49:32PM +0100, Robert Richter wrote: From: Radha Mohan Chintakuntla rchintakun...@cavium.com In case of ARCH_THUNDER, there is a need to allocate the GICv3 ITS table which is bigger than the allowed max order. So we are forcing it only in case of 4KB page size. Does this problem disappear if the ITS driver uses dma_alloc_coherent instead? That would also allow us to remove the __flush_dcache_area abuse from the driver. __get_free_pages() is also used internally in dma_alloc_coherent(). There is another case if the device brings dma mem with it. I am not sure if it would be possible to assign some phys memory via devicetree to the interrupt controller and then assign that range for its table allocation. Another option would be to allocate a hugepage. This would require setting up hugepages during boottime. I need to figure out whether that could work. For allocation of 16MB cont. phys mem of a defconfig kernel (4KB default pagesize) I see this different approaches: * set FORCE_MAX_ZONEORDER to 13 as default, * set FORCE_MAX_ZONEORDER to 13 if ARM_GIC_V3 is set, * set FORCE_MAX_ZONEORDER to 13 if ARCH_THUNDER is set (this patch), * use hugepages if enabled (defconfig has the following options enable: CGROUP_HUGETLB, TRANSPARENT_HUGEPAGE, HUGETLBFS, this might work with current default kernel without changing defconfig options), * use devicetree to reserve mem for gicv3 (need to check ACPI). Do you see any direction? What about on the remaining 3 patches? Marc would be the best guy to review those, but he's on holiday for a couple of weeks at the moment. Thanks for the note and your comments. -Robert -- 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 v2] AHCI: Add generic MSI-X interrupt support to SATA PCI driver
Tejun,
On 11.05.15 19:18:10, Robert Richter wrote:
+static int ahci_init_interrupts(struct pci_dev *pdev, unsigned int
n_ports,
+ struct ahci_host_priv *hpriv)
+{
+ struct msi_desc *desc;
+
+ __ahci_init_interrupts(pdev, n_ports, hpriv);
+
+ if (!pdev-msix_enabled)
+ return pdev-irq;
+
+ desc = msix_get_desc(pdev, 0); /* first entry */
+ if (!desc)
+ return -ENODEV;
+
+ return desc-irq;
+}
Can we please do this properly? We should be able to move port priv
allocation to host allocaotion time and add and use pp-irq instead,
right?
I started working implementing this.
Will send an updated patch set once finished.
A couple of questions here.
If we store the irq for each port separate in host-ports[i]-irq,
then there are duplicates for !AHCI_HFLAG_MULTI_MSI. We can not
iterate over all ports then to initialize the interrupt. Instead we
need to check for !AHCI_HFLAG_MULTI_MSI and store in that case the irq
in host-irq. This would avoid initializing duplicates and makes
host-ports[i]-irq only useful for multi-msi. Right now multi-msi
uses a base irq + index to register all irqs. This makes
host-ports[i]-irq obsolete at all.
Now, adding host-irq would change the function interface of
ahci_host_activate() to:
int ahci_host_activate(struct ata_host *host, struct scsi_host_template *sht);
I don't think this is worth the effort as all internal and external
drivers need to be changed basically from:
ahci_host_activate(host, irq, ahci_sht);
to:
host-irq = irq;
ahci_host_activate(host, ahci_sht);
This looks not very useful to do. Since irq is used only a single
time, there is no reason to store it in the host's data structure. It
also makes the interface more error prone since host-irq might not be
setup. Apart from that there is an abi change.
I agree that we will need the implemention of host-ports[i]-irq for
the case there irqs are no longer in sequential order as this might be
the case for per-port msi-x interrupts. But this is not the focus of
my implementation and as long there is no hardware for this available,
it wouldn't make sense to implement this at all.
So how to proceed? I could send you patches that implement host-irq
for a single per-host interrupt, and also one that reworks multi-port
interrupts to use host-ports[i]-irq. But I don't see any benefit
here. That said, I would better keep my patch here as it is. That do
you think?
Thanks,
-Robert
--
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 v2] AHCI: Add generic MSI-X interrupt support to SATA PCI driver
Tejun,
thanks for your review and answer.
On 04.05.15 12:06:52, Tejun Heo wrote:
> > This patch also enables AHCI for Cavium Thunder SoCs that uses MSI-X.
>
> Please don't mix these two changes in the same patch.
I will split the patch.
> > + /* per-port msix interrupts are not supported */
> > + if (n_ports > 1 && nvec >= n_ports)
> > + return -ENOSYS;
>
> Hmm... can you please elaborate why the condition isn't nvec > 1?
I slightly changed the check and added a comment that explains that's
going on in the function. This is the new version:
static int ahci_init_msix(struct pci_dev *pdev, unsigned int n_ports,
struct ahci_host_priv *hpriv)
{
int rc, nvec;
struct msix_entry entry = {};
/* check if msix is supported */
nvec = pci_msix_vec_count(pdev);
if (nvec <= 0)
return 0;
/*
* Per-port msix interrupts are not supported. Assume single
* port interrupts for:
*
* n_ports == 1, or
* nvec < n_ports.
*
* We also need to check for n_ports != 0 which is implicitly
* covered here since nvec > 0.
*/
if (n_ports != 1 && nvec >= n_ports)
return -ENOSYS;
/*
* There can exist more than one vector (e.g. for error
* detection or hdd hotplug). Then the first vector is used,
* all others are ignored. Only enable the first entry here
* (entry.entry = 0).
*/
rc = pci_enable_msix_exact(pdev, , 1);
if (rc < 0)
return rc;
return 1;
}
Note that the check changed to n_ports != 1 to also cover the case
n_ports == 0 which should return -ENOSYS.
> Also, shouldn't we be printing a warning message here explaining why
> probing is failing?
I didn't want to print a warning in case -ENOSYS for backward
compatability. Only if msi-x code fails there is a message, see
__ahci_init_interrupts(). In any other case the behaviour is as
before, thus no message is printed.
> > +
> > + /* only enable the first entry (entry.entry = 0) */
> > + rc = pci_enable_msix_exact(pdev, , 1);
>
> So, enabling the first msix works if nvec > 1 && nvec < n_ports but
> not if nvec >= n_ports?
For n_ports > 1 && nvec >= n_ports we need to assume per-port
interrupts. There are enough vectors for all ports then.
> > + if (rc < 0)
> > + return rc;
> > +
> > + return 1;
> > +}
> > +
> > +static int __ahci_init_interrupts(struct pci_dev *pdev, unsigned int
> > n_ports,
> > + struct ahci_host_priv *hpriv)
> > {
> > int rc, nvec;
> >
> > + nvec = ahci_init_msix(pdev, n_ports, hpriv);
> > + if (nvec > 0)
> > + return nvec;
> > +
> > + if (nvec && nvec != -ENOSYS)
> > + dev_err(>dev, "failed to enable MSI-X: %d", nvec);
> > +
> > if (hpriv->flags & AHCI_HFLAG_NO_MSI)
> > goto intx;
> >
> > @@ -1250,6 +1285,35 @@ static int ahci_init_interrupts(struct pci_dev
> > *pdev, unsigned int n_ports,
> > return 0;
> > }
> >
> > +static struct msi_desc *msix_get_desc(struct pci_dev *dev, u16 entry)
> > +{
> > + struct msi_desc *desc;
> > +
> > + list_for_each_entry(desc, >msi_list, list) {
> > + if (desc->msi_attrib.entry_nr == entry)
> > + return desc;
> > + }
> > +
> > + return NULL;
> > +}
> > +
> > +static int ahci_init_interrupts(struct pci_dev *pdev, unsigned int n_ports,
> > + struct ahci_host_priv *hpriv)
> > +{
> > + struct msi_desc *desc;
> > +
> > + __ahci_init_interrupts(pdev, n_ports, hpriv);
> > +
> > + if (!pdev->msix_enabled)
> > + return pdev->irq;
> > +
> > + desc = msix_get_desc(pdev, 0); /* first entry */
> > + if (!desc)
> > + return -ENODEV;
> > +
> > + return desc->irq;
> > +}
>
> Can we please do this properly? We should be able to move port priv
> allocation to host allocaotion time and add and use pp->irq instead,
> right?
I started working implementing this.
Will send an updated patch set once finished.
Thanks,
-Robert
--
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 4/4] arm64: gicv3: its: Increase FORCE_MAX_ZONEORDER for Cavium ThunderX
On 05.05.15 11:53:29, Will Deacon wrote: > On Sun, May 03, 2015 at 09:49:32PM +0100, Robert Richter wrote: > > From: Radha Mohan Chintakuntla > > > > In case of ARCH_THUNDER, there is a need to allocate the GICv3 ITS table > > which is bigger than the allowed max order. So we are forcing it only in > > case of 4KB page size. > > Does this problem disappear if the ITS driver uses dma_alloc_coherent > instead? That would also allow us to remove the __flush_dcache_area abuse > from the driver. __get_free_pages() is also used internally in dma_alloc_coherent(). There is another case if the device brings dma mem with it. I am not sure if it would be possible to assign some phys memory via devicetree to the interrupt controller and then assign that range for its table allocation. Another option would be to allocate a hugepage. This would require setting up hugepages during boottime. I need to figure out whether that could work. What about on the remaining 3 patches? Thanks, -Robert -- 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 4/4] arm64: gicv3: its: Increase FORCE_MAX_ZONEORDER for Cavium ThunderX
On 05.05.15 11:53:29, Will Deacon wrote: On Sun, May 03, 2015 at 09:49:32PM +0100, Robert Richter wrote: From: Radha Mohan Chintakuntla rchintakun...@cavium.com In case of ARCH_THUNDER, there is a need to allocate the GICv3 ITS table which is bigger than the allowed max order. So we are forcing it only in case of 4KB page size. Does this problem disappear if the ITS driver uses dma_alloc_coherent instead? That would also allow us to remove the __flush_dcache_area abuse from the driver. __get_free_pages() is also used internally in dma_alloc_coherent(). There is another case if the device brings dma mem with it. I am not sure if it would be possible to assign some phys memory via devicetree to the interrupt controller and then assign that range for its table allocation. Another option would be to allocate a hugepage. This would require setting up hugepages during boottime. I need to figure out whether that could work. What about on the remaining 3 patches? Thanks, -Robert -- 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 v2] AHCI: Add generic MSI-X interrupt support to SATA PCI driver
Tejun,
thanks for your review and answer.
On 04.05.15 12:06:52, Tejun Heo wrote:
This patch also enables AHCI for Cavium Thunder SoCs that uses MSI-X.
Please don't mix these two changes in the same patch.
I will split the patch.
+ /* per-port msix interrupts are not supported */
+ if (n_ports 1 nvec = n_ports)
+ return -ENOSYS;
Hmm... can you please elaborate why the condition isn't nvec 1?
I slightly changed the check and added a comment that explains that's
going on in the function. This is the new version:
static int ahci_init_msix(struct pci_dev *pdev, unsigned int n_ports,
struct ahci_host_priv *hpriv)
{
int rc, nvec;
struct msix_entry entry = {};
/* check if msix is supported */
nvec = pci_msix_vec_count(pdev);
if (nvec = 0)
return 0;
/*
* Per-port msix interrupts are not supported. Assume single
* port interrupts for:
*
* n_ports == 1, or
* nvec n_ports.
*
* We also need to check for n_ports != 0 which is implicitly
* covered here since nvec 0.
*/
if (n_ports != 1 nvec = n_ports)
return -ENOSYS;
/*
* There can exist more than one vector (e.g. for error
* detection or hdd hotplug). Then the first vector is used,
* all others are ignored. Only enable the first entry here
* (entry.entry = 0).
*/
rc = pci_enable_msix_exact(pdev, entry, 1);
if (rc 0)
return rc;
return 1;
}
Note that the check changed to n_ports != 1 to also cover the case
n_ports == 0 which should return -ENOSYS.
Also, shouldn't we be printing a warning message here explaining why
probing is failing?
I didn't want to print a warning in case -ENOSYS for backward
compatability. Only if msi-x code fails there is a message, see
__ahci_init_interrupts(). In any other case the behaviour is as
before, thus no message is printed.
+
+ /* only enable the first entry (entry.entry = 0) */
+ rc = pci_enable_msix_exact(pdev, entry, 1);
So, enabling the first msix works if nvec 1 nvec n_ports but
not if nvec = n_ports?
For n_ports 1 nvec = n_ports we need to assume per-port
interrupts. There are enough vectors for all ports then.
+ if (rc 0)
+ return rc;
+
+ return 1;
+}
+
+static int __ahci_init_interrupts(struct pci_dev *pdev, unsigned int
n_ports,
+ struct ahci_host_priv *hpriv)
{
int rc, nvec;
+ nvec = ahci_init_msix(pdev, n_ports, hpriv);
+ if (nvec 0)
+ return nvec;
+
+ if (nvec nvec != -ENOSYS)
+ dev_err(pdev-dev, failed to enable MSI-X: %d, nvec);
+
if (hpriv-flags AHCI_HFLAG_NO_MSI)
goto intx;
@@ -1250,6 +1285,35 @@ static int ahci_init_interrupts(struct pci_dev
*pdev, unsigned int n_ports,
return 0;
}
+static struct msi_desc *msix_get_desc(struct pci_dev *dev, u16 entry)
+{
+ struct msi_desc *desc;
+
+ list_for_each_entry(desc, dev-msi_list, list) {
+ if (desc-msi_attrib.entry_nr == entry)
+ return desc;
+ }
+
+ return NULL;
+}
+
+static int ahci_init_interrupts(struct pci_dev *pdev, unsigned int n_ports,
+ struct ahci_host_priv *hpriv)
+{
+ struct msi_desc *desc;
+
+ __ahci_init_interrupts(pdev, n_ports, hpriv);
+
+ if (!pdev-msix_enabled)
+ return pdev-irq;
+
+ desc = msix_get_desc(pdev, 0); /* first entry */
+ if (!desc)
+ return -ENODEV;
+
+ return desc-irq;
+}
Can we please do this properly? We should be able to move port priv
allocation to host allocaotion time and add and use pp-irq instead,
right?
I started working implementing this.
Will send an updated patch set once finished.
Thanks,
-Robert
--
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 v2] AHCI: Add generic MSI-X interrupt support to SATA PCI driver
From: Robert Richter
This patch adds generic support for MSI-X interrupts to the SATA PCI
driver. Only single interrupt support is implemented. Thus, per-port
interrupts can not yet be enabled.
The driver now checks the device for the existence of MSI-X and tries
to enable the interrupt. Otherwise, if a device is not MSI-X capable,
the initialization is skipped and MSI or intx interrupts are
configured.
This patch also enables AHCI for Cavium Thunder SoCs that uses MSI-X.
v2:
* determine irq vector from pci_dev->msi_list
Based on a patch from Sunil Goutham .
Signed-off-by: Robert Richter
---
arch/arm64/Kconfig | 1 +
drivers/ata/ahci.c | 79 ++
2 files changed, 75 insertions(+), 5 deletions(-)
diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
index b1f9a20a3677..2d95bbc0557e 100644
--- a/arch/arm64/Kconfig
+++ b/arch/arm64/Kconfig
@@ -157,6 +157,7 @@ config ARCH_THUNDER
bool "Cavium Inc. Thunder SoC Family"
help
This enables support for Cavium's Thunder Family of SoCs.
+ select SATA_AHCI
config ARCH_VEXPRESS
bool "ARMv8 software model (Versatile Express)"
diff --git a/drivers/ata/ahci.c b/drivers/ata/ahci.c
index 49f1e6890587..36c88f6d8490 100644
--- a/drivers/ata/ahci.c
+++ b/drivers/ata/ahci.c
@@ -42,6 +42,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -52,6 +53,7 @@
enum {
AHCI_PCI_BAR_STA2X11= 0,
+ AHCI_PCI_BAR_CAVIUM = 0,
AHCI_PCI_BAR_ENMOTUS= 2,
AHCI_PCI_BAR_STANDARD = 5,
};
@@ -500,6 +502,9 @@ static const struct pci_device_id ahci_pci_tbl[] = {
/* Enmotus */
{ PCI_DEVICE(0x1c44, 0x8000), board_ahci },
+ /* Cavium */
+ { PCI_DEVICE(0x177d, 0xa01c), .driver_data = board_ahci },
+
/* Generic, PCI class code for AHCI */
{ PCI_ANY_ID, PCI_ANY_ID, PCI_ANY_ID, PCI_ANY_ID,
PCI_CLASS_STORAGE_SATA_AHCI, 0xff, board_ahci },
@@ -1202,11 +1207,41 @@ static inline void ahci_gtf_filter_workaround(struct
ata_host *host)
{}
#endif
-static int ahci_init_interrupts(struct pci_dev *pdev, unsigned int n_ports,
- struct ahci_host_priv *hpriv)
+static int ahci_init_msix(struct pci_dev *pdev, unsigned int n_ports,
+ struct ahci_host_priv *hpriv)
+{
+ int rc, nvec;
+ struct msix_entry entry = {};
+
+ /* check if msix is supported */
+ nvec = pci_msix_vec_count(pdev);
+ if (nvec <= 0)
+ return 0;
+
+ /* per-port msix interrupts are not supported */
+ if (n_ports > 1 && nvec >= n_ports)
+ return -ENOSYS;
+
+ /* only enable the first entry (entry.entry = 0) */
+ rc = pci_enable_msix_exact(pdev, , 1);
+ if (rc < 0)
+ return rc;
+
+ return 1;
+}
+
+static int __ahci_init_interrupts(struct pci_dev *pdev, unsigned int n_ports,
+ struct ahci_host_priv *hpriv)
{
int rc, nvec;
+ nvec = ahci_init_msix(pdev, n_ports, hpriv);
+ if (nvec > 0)
+ return nvec;
+
+ if (nvec && nvec != -ENOSYS)
+ dev_err(>dev, "failed to enable MSI-X: %d", nvec);
+
if (hpriv->flags & AHCI_HFLAG_NO_MSI)
goto intx;
@@ -1250,6 +1285,35 @@ static int ahci_init_interrupts(struct pci_dev *pdev,
unsigned int n_ports,
return 0;
}
+static struct msi_desc *msix_get_desc(struct pci_dev *dev, u16 entry)
+{
+ struct msi_desc *desc;
+
+ list_for_each_entry(desc, >msi_list, list) {
+ if (desc->msi_attrib.entry_nr == entry)
+ return desc;
+ }
+
+ return NULL;
+}
+
+static int ahci_init_interrupts(struct pci_dev *pdev, unsigned int n_ports,
+ struct ahci_host_priv *hpriv)
+{
+ struct msi_desc *desc;
+
+ __ahci_init_interrupts(pdev, n_ports, hpriv);
+
+ if (!pdev->msix_enabled)
+ return pdev->irq;
+
+ desc = msix_get_desc(pdev, 0); /* first entry */
+ if (!desc)
+ return -ENODEV;
+
+ return desc->irq;
+}
+
static int ahci_init_one(struct pci_dev *pdev, const struct pci_device_id *ent)
{
unsigned int board_id = ent->driver_data;
@@ -1260,6 +1324,7 @@ static int ahci_init_one(struct pci_dev *pdev, const
struct pci_device_id *ent)
struct ata_host *host;
int n_ports, i, rc;
int ahci_pci_bar = AHCI_PCI_BAR_STANDARD;
+ int irq;
VPRINTK("ENTER\n");
@@ -1285,11 +1350,13 @@ static int ahci_init_one(struct pci_dev *pdev, const
struct pci_device_id *ent)
dev_info(>dev,
"PDC42819 can only drive SATA devices with this
driver\n");
- /* Both Connext and Enmotus devices use non-
[PATCH v2] AHCI: Add generic MSI-X interrupt support to SATA PCI driver
From: Robert Richter rrich...@cavium.com
This patch adds generic support for MSI-X interrupts to the SATA PCI
driver. Only single interrupt support is implemented. Thus, per-port
interrupts can not yet be enabled.
The driver now checks the device for the existence of MSI-X and tries
to enable the interrupt. Otherwise, if a device is not MSI-X capable,
the initialization is skipped and MSI or intx interrupts are
configured.
This patch also enables AHCI for Cavium Thunder SoCs that uses MSI-X.
v2:
* determine irq vector from pci_dev-msi_list
Based on a patch from Sunil Goutham sgout...@cavium.com.
Signed-off-by: Robert Richter rrich...@cavium.com
---
arch/arm64/Kconfig | 1 +
drivers/ata/ahci.c | 79 ++
2 files changed, 75 insertions(+), 5 deletions(-)
diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
index b1f9a20a3677..2d95bbc0557e 100644
--- a/arch/arm64/Kconfig
+++ b/arch/arm64/Kconfig
@@ -157,6 +157,7 @@ config ARCH_THUNDER
bool Cavium Inc. Thunder SoC Family
help
This enables support for Cavium's Thunder Family of SoCs.
+ select SATA_AHCI
config ARCH_VEXPRESS
bool ARMv8 software model (Versatile Express)
diff --git a/drivers/ata/ahci.c b/drivers/ata/ahci.c
index 49f1e6890587..36c88f6d8490 100644
--- a/drivers/ata/ahci.c
+++ b/drivers/ata/ahci.c
@@ -42,6 +42,7 @@
#include linux/device.h
#include linux/dmi.h
#include linux/gfp.h
+#include linux/msi.h
#include scsi/scsi_host.h
#include scsi/scsi_cmnd.h
#include linux/libata.h
@@ -52,6 +53,7 @@
enum {
AHCI_PCI_BAR_STA2X11= 0,
+ AHCI_PCI_BAR_CAVIUM = 0,
AHCI_PCI_BAR_ENMOTUS= 2,
AHCI_PCI_BAR_STANDARD = 5,
};
@@ -500,6 +502,9 @@ static const struct pci_device_id ahci_pci_tbl[] = {
/* Enmotus */
{ PCI_DEVICE(0x1c44, 0x8000), board_ahci },
+ /* Cavium */
+ { PCI_DEVICE(0x177d, 0xa01c), .driver_data = board_ahci },
+
/* Generic, PCI class code for AHCI */
{ PCI_ANY_ID, PCI_ANY_ID, PCI_ANY_ID, PCI_ANY_ID,
PCI_CLASS_STORAGE_SATA_AHCI, 0xff, board_ahci },
@@ -1202,11 +1207,41 @@ static inline void ahci_gtf_filter_workaround(struct
ata_host *host)
{}
#endif
-static int ahci_init_interrupts(struct pci_dev *pdev, unsigned int n_ports,
- struct ahci_host_priv *hpriv)
+static int ahci_init_msix(struct pci_dev *pdev, unsigned int n_ports,
+ struct ahci_host_priv *hpriv)
+{
+ int rc, nvec;
+ struct msix_entry entry = {};
+
+ /* check if msix is supported */
+ nvec = pci_msix_vec_count(pdev);
+ if (nvec = 0)
+ return 0;
+
+ /* per-port msix interrupts are not supported */
+ if (n_ports 1 nvec = n_ports)
+ return -ENOSYS;
+
+ /* only enable the first entry (entry.entry = 0) */
+ rc = pci_enable_msix_exact(pdev, entry, 1);
+ if (rc 0)
+ return rc;
+
+ return 1;
+}
+
+static int __ahci_init_interrupts(struct pci_dev *pdev, unsigned int n_ports,
+ struct ahci_host_priv *hpriv)
{
int rc, nvec;
+ nvec = ahci_init_msix(pdev, n_ports, hpriv);
+ if (nvec 0)
+ return nvec;
+
+ if (nvec nvec != -ENOSYS)
+ dev_err(pdev-dev, failed to enable MSI-X: %d, nvec);
+
if (hpriv-flags AHCI_HFLAG_NO_MSI)
goto intx;
@@ -1250,6 +1285,35 @@ static int ahci_init_interrupts(struct pci_dev *pdev,
unsigned int n_ports,
return 0;
}
+static struct msi_desc *msix_get_desc(struct pci_dev *dev, u16 entry)
+{
+ struct msi_desc *desc;
+
+ list_for_each_entry(desc, dev-msi_list, list) {
+ if (desc-msi_attrib.entry_nr == entry)
+ return desc;
+ }
+
+ return NULL;
+}
+
+static int ahci_init_interrupts(struct pci_dev *pdev, unsigned int n_ports,
+ struct ahci_host_priv *hpriv)
+{
+ struct msi_desc *desc;
+
+ __ahci_init_interrupts(pdev, n_ports, hpriv);
+
+ if (!pdev-msix_enabled)
+ return pdev-irq;
+
+ desc = msix_get_desc(pdev, 0); /* first entry */
+ if (!desc)
+ return -ENODEV;
+
+ return desc-irq;
+}
+
static int ahci_init_one(struct pci_dev *pdev, const struct pci_device_id *ent)
{
unsigned int board_id = ent-driver_data;
@@ -1260,6 +1324,7 @@ static int ahci_init_one(struct pci_dev *pdev, const
struct pci_device_id *ent)
struct ata_host *host;
int n_ports, i, rc;
int ahci_pci_bar = AHCI_PCI_BAR_STANDARD;
+ int irq;
VPRINTK(ENTER\n);
@@ -1285,11 +1350,13 @@ static int ahci_init_one(struct pci_dev *pdev, const
struct pci_device_id *ent)
dev_info(pdev-dev,
PDC42819 can only drive SATA devices with this
driver\n);
- /* Both Connext
[PATCH 2/4] arm64: gicv3: its: Add range check for number of allocated pages
From: Robert Richter
The number of pages for the its table may exceed the maximum of 256.
Adding a range check and limitting the number to its maximum.
Based on a patch from Tirumalesh Chalamarla .
Signed-off-by: Robert Richter
---
drivers/irqchip/irq-gic-v3-its.c | 11 ++-
include/linux/irqchip/arm-gic-v3.h | 1 +
2 files changed, 11 insertions(+), 1 deletion(-)
diff --git a/drivers/irqchip/irq-gic-v3-its.c b/drivers/irqchip/irq-gic-v3-its.c
index e30b4de04c6c..a2619a1d5bb3 100644
--- a/drivers/irqchip/irq-gic-v3-its.c
+++ b/drivers/irqchip/irq-gic-v3-its.c
@@ -810,6 +810,7 @@ static int its_alloc_tables(struct its_node *its)
u64 entry_size = GITS_BASER_ENTRY_SIZE(val);
int order = get_order(psz);
int alloc_size;
+ int alloc_pages;
u64 tmp;
void *base;
@@ -837,6 +838,14 @@ static int its_alloc_tables(struct its_node *its)
}
alloc_size = (1 << order) * PAGE_SIZE;
+ alloc_pages = (alloc_size / psz);
+ if (alloc_pages > GITS_BASER_PAGES_MAX) {
+ alloc_pages = GITS_BASER_PAGES_MAX;
+ order = get_order(GITS_BASER_PAGES_MAX * psz);
+ pr_warn("%s: Device Table too large, reduce its page
order to %u (%u pages)\n",
+ its->msi_chip.of_node->full_name, order,
alloc_pages);
+ }
+
base = (void *)__get_free_pages(GFP_KERNEL | __GFP_ZERO, order);
if (!base) {
err = -ENOMEM;
@@ -865,7 +874,7 @@ static int its_alloc_tables(struct its_node *its)
break;
}
- val |= (alloc_size / psz) - 1;
+ val |= alloc_pages - 1;
writeq_relaxed(val, its->base + GITS_BASER + i * 8);
tmp = readq_relaxed(its->base + GITS_BASER + i * 8);
diff --git a/include/linux/irqchip/arm-gic-v3.h
b/include/linux/irqchip/arm-gic-v3.h
index ffbc034c8810..f28da189c4aa 100644
--- a/include/linux/irqchip/arm-gic-v3.h
+++ b/include/linux/irqchip/arm-gic-v3.h
@@ -229,6 +229,7 @@
#define GITS_BASER_PAGE_SIZE_16K (1UL << GITS_BASER_PAGE_SIZE_SHIFT)
#define GITS_BASER_PAGE_SIZE_64K (2UL << GITS_BASER_PAGE_SIZE_SHIFT)
#define GITS_BASER_PAGE_SIZE_MASK (3UL << GITS_BASER_PAGE_SIZE_SHIFT)
+#define GITS_BASER_PAGES_MAX 256
#define GITS_BASER_TYPE_NONE 0
#define GITS_BASER_TYPE_DEVICE 1
--
2.1.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 http://www.tux.org/lkml/
[PATCH 4/4] arm64: gicv3: its: Increase FORCE_MAX_ZONEORDER for Cavium ThunderX
From: Radha Mohan Chintakuntla In case of ARCH_THUNDER, there is a need to allocate the GICv3 ITS table which is bigger than the allowed max order. So we are forcing it only in case of 4KB page size. Signed-off-by: Radha Mohan Chintakuntla Signed-off-by: Robert Richter --- arch/arm64/Kconfig | 1 + 1 file changed, 1 insertion(+) diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig index 1b8e97331ffb..c519f3777453 100644 --- a/arch/arm64/Kconfig +++ b/arch/arm64/Kconfig @@ -542,6 +542,7 @@ config XEN config FORCE_MAX_ZONEORDER int default "14" if (ARM64_64K_PAGES && TRANSPARENT_HUGEPAGE) + default "13" if (ARCH_THUNDER && !ARM64_64K_PAGES) default "11" menuconfig ARMV8_DEPRECATED -- 2.1.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 http://www.tux.org/lkml/
[PATCH 3/4] arm64: gicv3: its: Read typer register outside the loop
From: Robert Richter
No need to read the typer register in the loop. Values do not change.
Signed-off-by: Robert Richter
---
drivers/irqchip/irq-gic-v3-its.c | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
diff --git a/drivers/irqchip/irq-gic-v3-its.c b/drivers/irqchip/irq-gic-v3-its.c
index a2619a1d5bb3..916c4724c771 100644
--- a/drivers/irqchip/irq-gic-v3-its.c
+++ b/drivers/irqchip/irq-gic-v3-its.c
@@ -803,6 +803,8 @@ static int its_alloc_tables(struct its_node *its)
int psz = SZ_64K;
u64 shr = GITS_BASER_InnerShareable;
u64 cache = GITS_BASER_WaWb;
+ u64 typer = readq_relaxed(its->base + GITS_TYPER);
+ u32 ids = GITS_TYPER_DEVBITS(typer);
for (i = 0; i < GITS_BASER_NR_REGS; i++) {
u64 val = readq_relaxed(its->base + GITS_BASER + i * 8);
@@ -826,9 +828,6 @@ static int its_alloc_tables(struct its_node *its)
* For other tables, only allocate a single page.
*/
if (type == GITS_BASER_TYPE_DEVICE) {
- u64 typer = readq_relaxed(its->base + GITS_TYPER);
- u32 ids = GITS_TYPER_DEVBITS(typer);
-
order = get_order((1UL << ids) * entry_size);
if (order >= MAX_ORDER) {
order = MAX_ORDER - 1;
--
2.1.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 http://www.tux.org/lkml/
[PATCH 1/4] arm64: gicv3: its: Encode domain number in PCI stream id
From: Tirumalesh Chalamarla
PCI stream ids need to consider pci bridge number to be unique on the
system. Using only bus and devfn can't do the trick in systems that
have multiple pci bridges.
Signed-off-by: Tirumalesh Chalamarla
Signed-off-by: Robert Richter
---
drivers/irqchip/irq-gic-v3-its.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/irqchip/irq-gic-v3-its.c b/drivers/irqchip/irq-gic-v3-its.c
index 9687f8afebff..e30b4de04c6c 100644
--- a/drivers/irqchip/irq-gic-v3-its.c
+++ b/drivers/irqchip/irq-gic-v3-its.c
@@ -1186,7 +1186,7 @@ static int its_get_pci_alias(struct pci_dev *pdev, u16
alias, void *data)
{
struct its_pci_alias *dev_alias = data;
- dev_alias->dev_id = alias;
+ dev_alias->dev_id = (pci_domain_nr(pdev->bus) << 16) | alias;
if (pdev != dev_alias->pdev)
dev_alias->count += its_pci_msi_vec_count(dev_alias->pdev);
--
2.1.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 http://www.tux.org/lkml/
[PATCH 0/4] arm64: gicv3: its: Fixes and updates for ThunderX
From: Robert Richter This patch series adds fixes and updates for ThunderX. Patches are unrelated each other and can be applied individually. Radha Mohan Chintakuntla (1): arm64: gicv3: its: Increase FORCE_MAX_ZONEORDER for Cavium ThunderX Robert Richter (2): arm64: gicv3: its: Add range check for number of allocated pages arm64: gicv3: its: Read typer register outside the loop Tirumalesh Chalamarla (1): arm64: gicv3: its: Encode domain number in PCI stream id arch/arm64/Kconfig | 1 + drivers/irqchip/irq-gic-v3-its.c | 18 +- include/linux/irqchip/arm-gic-v3.h | 1 + 3 files changed, 15 insertions(+), 5 deletions(-) -- 2.1.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 http://www.tux.org/lkml/
[PATCH 1/4] arm64: gicv3: its: Encode domain number in PCI stream id
From: Tirumalesh Chalamarla tchalama...@cavium.com
PCI stream ids need to consider pci bridge number to be unique on the
system. Using only bus and devfn can't do the trick in systems that
have multiple pci bridges.
Signed-off-by: Tirumalesh Chalamarla tchalama...@cavium.com
Signed-off-by: Robert Richter rrich...@cavium.com
---
drivers/irqchip/irq-gic-v3-its.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/irqchip/irq-gic-v3-its.c b/drivers/irqchip/irq-gic-v3-its.c
index 9687f8afebff..e30b4de04c6c 100644
--- a/drivers/irqchip/irq-gic-v3-its.c
+++ b/drivers/irqchip/irq-gic-v3-its.c
@@ -1186,7 +1186,7 @@ static int its_get_pci_alias(struct pci_dev *pdev, u16
alias, void *data)
{
struct its_pci_alias *dev_alias = data;
- dev_alias-dev_id = alias;
+ dev_alias-dev_id = (pci_domain_nr(pdev-bus) 16) | alias;
if (pdev != dev_alias-pdev)
dev_alias-count += its_pci_msi_vec_count(dev_alias-pdev);
--
2.1.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 http://www.tux.org/lkml/
[PATCH 2/4] arm64: gicv3: its: Add range check for number of allocated pages
From: Robert Richter rrich...@cavium.com
The number of pages for the its table may exceed the maximum of 256.
Adding a range check and limitting the number to its maximum.
Based on a patch from Tirumalesh Chalamarla tchalama...@cavium.com.
Signed-off-by: Robert Richter rrich...@cavium.com
---
drivers/irqchip/irq-gic-v3-its.c | 11 ++-
include/linux/irqchip/arm-gic-v3.h | 1 +
2 files changed, 11 insertions(+), 1 deletion(-)
diff --git a/drivers/irqchip/irq-gic-v3-its.c b/drivers/irqchip/irq-gic-v3-its.c
index e30b4de04c6c..a2619a1d5bb3 100644
--- a/drivers/irqchip/irq-gic-v3-its.c
+++ b/drivers/irqchip/irq-gic-v3-its.c
@@ -810,6 +810,7 @@ static int its_alloc_tables(struct its_node *its)
u64 entry_size = GITS_BASER_ENTRY_SIZE(val);
int order = get_order(psz);
int alloc_size;
+ int alloc_pages;
u64 tmp;
void *base;
@@ -837,6 +838,14 @@ static int its_alloc_tables(struct its_node *its)
}
alloc_size = (1 order) * PAGE_SIZE;
+ alloc_pages = (alloc_size / psz);
+ if (alloc_pages GITS_BASER_PAGES_MAX) {
+ alloc_pages = GITS_BASER_PAGES_MAX;
+ order = get_order(GITS_BASER_PAGES_MAX * psz);
+ pr_warn(%s: Device Table too large, reduce its page
order to %u (%u pages)\n,
+ its-msi_chip.of_node-full_name, order,
alloc_pages);
+ }
+
base = (void *)__get_free_pages(GFP_KERNEL | __GFP_ZERO, order);
if (!base) {
err = -ENOMEM;
@@ -865,7 +874,7 @@ static int its_alloc_tables(struct its_node *its)
break;
}
- val |= (alloc_size / psz) - 1;
+ val |= alloc_pages - 1;
writeq_relaxed(val, its-base + GITS_BASER + i * 8);
tmp = readq_relaxed(its-base + GITS_BASER + i * 8);
diff --git a/include/linux/irqchip/arm-gic-v3.h
b/include/linux/irqchip/arm-gic-v3.h
index ffbc034c8810..f28da189c4aa 100644
--- a/include/linux/irqchip/arm-gic-v3.h
+++ b/include/linux/irqchip/arm-gic-v3.h
@@ -229,6 +229,7 @@
#define GITS_BASER_PAGE_SIZE_16K (1UL GITS_BASER_PAGE_SIZE_SHIFT)
#define GITS_BASER_PAGE_SIZE_64K (2UL GITS_BASER_PAGE_SIZE_SHIFT)
#define GITS_BASER_PAGE_SIZE_MASK (3UL GITS_BASER_PAGE_SIZE_SHIFT)
+#define GITS_BASER_PAGES_MAX 256
#define GITS_BASER_TYPE_NONE 0
#define GITS_BASER_TYPE_DEVICE 1
--
2.1.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 http://www.tux.org/lkml/
[PATCH 4/4] arm64: gicv3: its: Increase FORCE_MAX_ZONEORDER for Cavium ThunderX
From: Radha Mohan Chintakuntla rchintakun...@cavium.com In case of ARCH_THUNDER, there is a need to allocate the GICv3 ITS table which is bigger than the allowed max order. So we are forcing it only in case of 4KB page size. Signed-off-by: Radha Mohan Chintakuntla rchintakun...@cavium.com Signed-off-by: Robert Richter rrich...@cavium.com --- arch/arm64/Kconfig | 1 + 1 file changed, 1 insertion(+) diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig index 1b8e97331ffb..c519f3777453 100644 --- a/arch/arm64/Kconfig +++ b/arch/arm64/Kconfig @@ -542,6 +542,7 @@ config XEN config FORCE_MAX_ZONEORDER int default 14 if (ARM64_64K_PAGES TRANSPARENT_HUGEPAGE) + default 13 if (ARCH_THUNDER !ARM64_64K_PAGES) default 11 menuconfig ARMV8_DEPRECATED -- 2.1.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 http://www.tux.org/lkml/
[PATCH 3/4] arm64: gicv3: its: Read typer register outside the loop
From: Robert Richter rrich...@cavium.com
No need to read the typer register in the loop. Values do not change.
Signed-off-by: Robert Richter rrich...@cavium.com
---
drivers/irqchip/irq-gic-v3-its.c | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
diff --git a/drivers/irqchip/irq-gic-v3-its.c b/drivers/irqchip/irq-gic-v3-its.c
index a2619a1d5bb3..916c4724c771 100644
--- a/drivers/irqchip/irq-gic-v3-its.c
+++ b/drivers/irqchip/irq-gic-v3-its.c
@@ -803,6 +803,8 @@ static int its_alloc_tables(struct its_node *its)
int psz = SZ_64K;
u64 shr = GITS_BASER_InnerShareable;
u64 cache = GITS_BASER_WaWb;
+ u64 typer = readq_relaxed(its-base + GITS_TYPER);
+ u32 ids = GITS_TYPER_DEVBITS(typer);
for (i = 0; i GITS_BASER_NR_REGS; i++) {
u64 val = readq_relaxed(its-base + GITS_BASER + i * 8);
@@ -826,9 +828,6 @@ static int its_alloc_tables(struct its_node *its)
* For other tables, only allocate a single page.
*/
if (type == GITS_BASER_TYPE_DEVICE) {
- u64 typer = readq_relaxed(its-base + GITS_TYPER);
- u32 ids = GITS_TYPER_DEVBITS(typer);
-
order = get_order((1UL ids) * entry_size);
if (order = MAX_ORDER) {
order = MAX_ORDER - 1;
--
2.1.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 http://www.tux.org/lkml/
[PATCH 0/4] arm64: gicv3: its: Fixes and updates for ThunderX
From: Robert Richter rrich...@cavium.com This patch series adds fixes and updates for ThunderX. Patches are unrelated each other and can be applied individually. Radha Mohan Chintakuntla (1): arm64: gicv3: its: Increase FORCE_MAX_ZONEORDER for Cavium ThunderX Robert Richter (2): arm64: gicv3: its: Add range check for number of allocated pages arm64: gicv3: its: Read typer register outside the loop Tirumalesh Chalamarla (1): arm64: gicv3: its: Encode domain number in PCI stream id arch/arm64/Kconfig | 1 + drivers/irqchip/irq-gic-v3-its.c | 18 +- include/linux/irqchip/arm-gic-v3.h | 1 + 3 files changed, 15 insertions(+), 5 deletions(-) -- 2.1.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 http://www.tux.org/lkml/
Re: [PATCH] x86: Drop 32-bit support ... finally.
On 01.04.15 10:56:00, Robert Richter wrote: > (cc'ing Andi) > > > On Wed, Apr 01, 2015 at 10:15:58AM +0200, Borislav Petkov wrote: > > > From: Borislav Petkov > > > > > > Today, April 1st 2015, marks almost 15 years since the introduction of > > > the 64-bit extensions to the x86 architecture. And frankly, 15 years was > > > a graceful period enough for people to move to 64-bit. Therefore, today, > > > I'm removing 32-bit support from x86 Linux. And it was about friggin' > > > time... > > No, I vaguely remember booting the first 64 bit cpu (on real hw) for > the 2002-2003 time frame. I need to check my memories on a more exact > date, but you guys from Suse should know better. So 15 years are not Looks like Feb 7 2002, assuming this is genuine: http://www.theinquirer.net/inquirer/news/1049122/amd-microsoft-hammer-memo-leaked Not sure about Linux first booting 64 bit. -Robert > yet over and I really would like to wait at least until then. Another > question is if 64-bit simulators take into account here. > > Though, I assume a discussion on this topic will at least take 1-2 > years, so it's good to start with it now. Also, I really would like to > finally switch off and retire my K7 which still runs some regression > tests (will need to check the actual used kernel version). It was a > good time, but now I realize it's somehow over. Considering this and > apart from my concerns above: > > Acked-by: Robert Richter > > -Robert -- 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] x86: Drop 32-bit support ... finally.
(cc'ing Andi) > On Wed, Apr 01, 2015 at 10:15:58AM +0200, Borislav Petkov wrote: > > From: Borislav Petkov > > > > Today, April 1st 2015, marks almost 15 years since the introduction of > > the 64-bit extensions to the x86 architecture. And frankly, 15 years was > > a graceful period enough for people to move to 64-bit. Therefore, today, > > I'm removing 32-bit support from x86 Linux. And it was about friggin' > > time... No, I vaguely remember booting the first 64 bit cpu (on real hw) for the 2002-2003 time frame. I need to check my memories on a more exact date, but you guys from Suse should know better. So 15 years are not yet over and I really would like to wait at least until then. Another question is if 64-bit simulators take into account here. Though, I assume a discussion on this topic will at least take 1-2 years, so it's good to start with it now. Also, I really would like to finally switch off and retire my K7 which still runs some regression tests (will need to check the actual used kernel version). It was a good time, but now I realize it's somehow over. Considering this and apart from my concerns above: Acked-by: Robert Richter -Robert -- 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] x86: Drop 32-bit support ... finally.
(cc'ing Andi) On Wed, Apr 01, 2015 at 10:15:58AM +0200, Borislav Petkov wrote: From: Borislav Petkov b...@suse.de Today, April 1st 2015, marks almost 15 years since the introduction of the 64-bit extensions to the x86 architecture. And frankly, 15 years was a graceful period enough for people to move to 64-bit. Therefore, today, I'm removing 32-bit support from x86 Linux. And it was about friggin' time... No, I vaguely remember booting the first 64 bit cpu (on real hw) for the 2002-2003 time frame. I need to check my memories on a more exact date, but you guys from Suse should know better. So 15 years are not yet over and I really would like to wait at least until then. Another question is if 64-bit simulators take into account here. Though, I assume a discussion on this topic will at least take 1-2 years, so it's good to start with it now. Also, I really would like to finally switch off and retire my K7 which still runs some regression tests (will need to check the actual used kernel version). It was a good time, but now I realize it's somehow over. Considering this and apart from my concerns above: Acked-by: Robert Richter r...@kernel.org -Robert -- 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] x86: Drop 32-bit support ... finally.
On 01.04.15 10:56:00, Robert Richter wrote: (cc'ing Andi) On Wed, Apr 01, 2015 at 10:15:58AM +0200, Borislav Petkov wrote: From: Borislav Petkov b...@suse.de Today, April 1st 2015, marks almost 15 years since the introduction of the 64-bit extensions to the x86 architecture. And frankly, 15 years was a graceful period enough for people to move to 64-bit. Therefore, today, I'm removing 32-bit support from x86 Linux. And it was about friggin' time... No, I vaguely remember booting the first 64 bit cpu (on real hw) for the 2002-2003 time frame. I need to check my memories on a more exact date, but you guys from Suse should know better. So 15 years are not Looks like Feb 7 2002, assuming this is genuine: http://www.theinquirer.net/inquirer/news/1049122/amd-microsoft-hammer-memo-leaked Not sure about Linux first booting 64 bit. -Robert yet over and I really would like to wait at least until then. Another question is if 64-bit simulators take into account here. Though, I assume a discussion on this topic will at least take 1-2 years, so it's good to start with it now. Also, I really would like to finally switch off and retire my K7 which still runs some regression tests (will need to check the actual used kernel version). It was a good time, but now I realize it's somehow over. Considering this and apart from my concerns above: Acked-by: Robert Richter r...@kernel.org -Robert -- 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 v8 00/21] Introduce ACPI for ARM64 based on ACPI 5.1
On 13.02.15 10:48:18, Hanjun Guo wrote: > On 2015年02月12日 18:02, Robert Richter wrote: > >On 02.02.15 20:45:28, Hanjun Guo wrote: > >>This is the v8 of ACPI core patches for ARM64 based on ACPI 5.1, there are > >>some updates since v7: > >> > >> - Add two more documantation to explain why we need ACPI in ARM64 servers > >>by Grant, and recommendations and prohibitions on the use of the > >> numerous > >>ACPI tables and objects by Al Stone. > >> > >> - Add two patches which is need to map acpi tables after > >> acpi_gbl_permanent_mmap > >>is set > >> > >> - Add another patch "dt / chosen: Add linux,uefi-stub-generated-dtb > >> property" > >>to address that if firmware providing no dtb, we can try ACPI > >> configuration data > >>even if no "acpi=force" is passed in early parameters. (I think ACPI > >> for XEN and > >>kexec need consider sperately as disscussed, correct me if I'm wrong). > >> > >> - Add CC in the patch to the subsystem maintainers and modify the subject > >>of the patch to explicitly show the subsystem touched by this patch set, > >>please help us to review and ack them if they make sense, thanks. > >> > >> - Add Tested-by from Qualcomm and Redhat; > >> > >> - Make ACPI depends on PCI suggested by Catalin; > >> > >> - Clean up SMP init function as Lorenzo suggested, remove physical > >>CPU hot-plug code in the patch; > >> > >> - Address some comments from Marc and explicitly state that will > >>implment statcked irqdomain and GIC init framework when GICv3 and > >>ITS, GICv2m are implemented; > >> > >> - Rebased on top of 3.19-rc7. > > > >Patches tested on Cavium ThunderX. For the whole series: > > > > Tested-by: Robert Richter > > Acked-by: Robert Richter > > Hi Robert, thank you very much. > > I'm going to send out v9 to address some of the comments, I think > your Acked-by still apply if no objection from you :) Right, unless you hear from me. ;) -Robert -- 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 v8 00/21] Introduce ACPI for ARM64 based on ACPI 5.1
On 13.02.15 10:48:18, Hanjun Guo wrote: On 2015年02月12日 18:02, Robert Richter wrote: On 02.02.15 20:45:28, Hanjun Guo wrote: This is the v8 of ACPI core patches for ARM64 based on ACPI 5.1, there are some updates since v7: - Add two more documantation to explain why we need ACPI in ARM64 servers by Grant, and recommendations and prohibitions on the use of the numerous ACPI tables and objects by Al Stone. - Add two patches which is need to map acpi tables after acpi_gbl_permanent_mmap is set - Add another patch dt / chosen: Add linux,uefi-stub-generated-dtb property to address that if firmware providing no dtb, we can try ACPI configuration data even if no acpi=force is passed in early parameters. (I think ACPI for XEN and kexec need consider sperately as disscussed, correct me if I'm wrong). - Add CC in the patch to the subsystem maintainers and modify the subject of the patch to explicitly show the subsystem touched by this patch set, please help us to review and ack them if they make sense, thanks. - Add Tested-by from Qualcomm and Redhat; - Make ACPI depends on PCI suggested by Catalin; - Clean up SMP init function as Lorenzo suggested, remove physical CPU hot-plug code in the patch; - Address some comments from Marc and explicitly state that will implment statcked irqdomain and GIC init framework when GICv3 and ITS, GICv2m are implemented; - Rebased on top of 3.19-rc7. Patches tested on Cavium ThunderX. For the whole series: Tested-by: Robert Richter rrich...@cavium.com Acked-by: Robert Richter rrich...@cavium.com Hi Robert, thank you very much. I'm going to send out v9 to address some of the comments, I think your Acked-by still apply if no objection from you :) Right, unless you hear from me. ;) -Robert -- 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 v8 00/21] Introduce ACPI for ARM64 based on ACPI 5.1
On 02.02.15 20:45:28, Hanjun Guo wrote: > This is the v8 of ACPI core patches for ARM64 based on ACPI 5.1, there are > some updates since v7: > > - Add two more documantation to explain why we need ACPI in ARM64 servers >by Grant, and recommendations and prohibitions on the use of the numerous >ACPI tables and objects by Al Stone. > > - Add two patches which is need to map acpi tables after > acpi_gbl_permanent_mmap >is set > > - Add another patch "dt / chosen: Add linux,uefi-stub-generated-dtb property" >to address that if firmware providing no dtb, we can try ACPI > configuration data >even if no "acpi=force" is passed in early parameters. (I think ACPI for > XEN and >kexec need consider sperately as disscussed, correct me if I'm wrong). > > - Add CC in the patch to the subsystem maintainers and modify the subject >of the patch to explicitly show the subsystem touched by this patch set, >please help us to review and ack them if they make sense, thanks. > > - Add Tested-by from Qualcomm and Redhat; > > - Make ACPI depends on PCI suggested by Catalin; > > - Clean up SMP init function as Lorenzo suggested, remove physical >CPU hot-plug code in the patch; > > - Address some comments from Marc and explicitly state that will >implment statcked irqdomain and GIC init framework when GICv3 and >ITS, GICv2m are implemented; > > - Rebased on top of 3.19-rc7. Patches tested on Cavium ThunderX. For the whole series: Tested-by: Robert Richter Acked-by: Robert Richter Please apply. Thanks, -Robert -- 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 v8 00/21] Introduce ACPI for ARM64 based on ACPI 5.1
On 02.02.15 20:45:28, Hanjun Guo wrote: This is the v8 of ACPI core patches for ARM64 based on ACPI 5.1, there are some updates since v7: - Add two more documantation to explain why we need ACPI in ARM64 servers by Grant, and recommendations and prohibitions on the use of the numerous ACPI tables and objects by Al Stone. - Add two patches which is need to map acpi tables after acpi_gbl_permanent_mmap is set - Add another patch dt / chosen: Add linux,uefi-stub-generated-dtb property to address that if firmware providing no dtb, we can try ACPI configuration data even if no acpi=force is passed in early parameters. (I think ACPI for XEN and kexec need consider sperately as disscussed, correct me if I'm wrong). - Add CC in the patch to the subsystem maintainers and modify the subject of the patch to explicitly show the subsystem touched by this patch set, please help us to review and ack them if they make sense, thanks. - Add Tested-by from Qualcomm and Redhat; - Make ACPI depends on PCI suggested by Catalin; - Clean up SMP init function as Lorenzo suggested, remove physical CPU hot-plug code in the patch; - Address some comments from Marc and explicitly state that will implment statcked irqdomain and GIC init framework when GICv3 and ITS, GICv2m are implemented; - Rebased on top of 3.19-rc7. Patches tested on Cavium ThunderX. For the whole series: Tested-by: Robert Richter rrich...@cavium.com Acked-by: Robert Richter rrich...@cavium.com Please apply. Thanks, -Robert -- 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] AHCI: Add generic MSI-X interrupt support to SATA PCI driver
On 10.11.14 22:51:44, Jiang Liu wrote: > On 2014/11/10 13:30, Robert Richter wrote: > > From: Sunil Goutham > > + /* only enable the first entry (entry.entry = 0) */ > > + rc = pci_enable_msix_exact(pdev, , 1); > > + if (rc < 0) > > + return rc; > > + > > + pdev->irq = entry.vector; > You can't overwrite pci_dev->irq for MSI-X, it's no way to > recover original irq for INTx after unbinding ahci driver. Instead, > you may access msi_desc->irq when requesting irq. Right, I have a version now that determines the irq vector from pdev->msi_list. -Robert -- 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] AHCI: Add generic MSI-X interrupt support to SATA PCI driver
On 10.11.14 22:51:44, Jiang Liu wrote: On 2014/11/10 13:30, Robert Richter wrote: From: Sunil Goutham sgout...@cavium.com + /* only enable the first entry (entry.entry = 0) */ + rc = pci_enable_msix_exact(pdev, entry, 1); + if (rc 0) + return rc; + + pdev-irq = entry.vector; You can't overwrite pci_dev-irq for MSI-X, it's no way to recover original irq for INTx after unbinding ahci driver. Instead, you may access msi_desc-irq when requesting irq. Right, I have a version now that determines the irq vector from pdev-msi_list. -Robert -- 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] AHCI: Add generic MSI-X interrupt support to SATA PCI driver
From: Sunil Goutham
This patch adds generic support for MSI-X interrupts to the SATA PCI
driver. Only single interrupt support is implemented. Thus, per-port
interrupts can not yet be enabled.
The driver now checks the device for the existence of MSI-X and tries
to enable the interrupt. Otherwise, if a device is not MSI-X capable,
the initialization is skipped and MSI or intx interrupts are
configured.
This patch also enables AHCI for Cavium Thunder SoCs that uses MSI-X.
Signed-off-by: Sunil Goutham
Signed-off-by: Robert Richter
---
arch/arm64/Kconfig | 1 +
drivers/ata/ahci.c | 40 +++-
2 files changed, 40 insertions(+), 1 deletion(-)
diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
index ac9afde76dea..55970474d3ae 100644
--- a/arch/arm64/Kconfig
+++ b/arch/arm64/Kconfig
@@ -145,6 +145,7 @@ config ARCH_THUNDER
bool "Cavium Inc. Thunder SoC Family"
help
This enables support for Cavium's Thunder Family of SoCs.
+ select SATA_AHCI
config ARCH_VEXPRESS
bool "ARMv8 software model (Versatile Express)"
diff --git a/drivers/ata/ahci.c b/drivers/ata/ahci.c
index 5f039f191067..8e43ccb72c95 100644
--- a/drivers/ata/ahci.c
+++ b/drivers/ata/ahci.c
@@ -52,6 +52,7 @@
enum {
AHCI_PCI_BAR_STA2X11= 0,
+ AHCI_PCI_BAR_CAVIUM = 0,
AHCI_PCI_BAR_ENMOTUS= 2,
AHCI_PCI_BAR_STANDARD = 5,
};
@@ -483,6 +484,9 @@ static const struct pci_device_id ahci_pci_tbl[] = {
/* Enmotus */
{ PCI_DEVICE(0x1c44, 0x8000), board_ahci },
+ /* Cavium */
+ { PCI_DEVICE(0x177d, 0xa01c), .driver_data = board_ahci },
+
/* Generic, PCI class code for AHCI */
{ PCI_ANY_ID, PCI_ANY_ID, PCI_ANY_ID, PCI_ANY_ID,
PCI_CLASS_STORAGE_SATA_AHCI, 0xff, board_ahci },
@@ -1188,11 +1192,43 @@ static inline void ahci_gtf_filter_workaround(struct
ata_host *host)
{}
#endif
+static int ahci_init_msix(struct pci_dev *pdev, unsigned int n_ports,
+ struct ahci_host_priv *hpriv)
+{
+ int rc, nvec;
+ struct msix_entry entry = {};
+
+ /* check if msix is supported */
+ nvec = pci_msix_vec_count(pdev);
+ if (nvec <= 0)
+ return 0;
+
+ /* per-port msix interrupts are not supported */
+ if (n_ports > 1 && nvec >= n_ports)
+ return -ENOSYS;
+
+ /* only enable the first entry (entry.entry = 0) */
+ rc = pci_enable_msix_exact(pdev, , 1);
+ if (rc < 0)
+ return rc;
+
+ pdev->irq = entry.vector;
+
+ return 1;
+}
+
static int ahci_init_interrupts(struct pci_dev *pdev, unsigned int n_ports,
struct ahci_host_priv *hpriv)
{
int rc, nvec;
+ nvec = ahci_init_msix(pdev, n_ports, hpriv);
+ if (nvec > 0)
+ return nvec;
+
+ if (nvec && nvec != -ENOSYS)
+ dev_err(>dev, "failed to enable MSI-X: %d", nvec);
+
if (hpriv->flags & AHCI_HFLAG_NO_MSI)
goto intx;
@@ -1271,11 +1307,13 @@ static int ahci_init_one(struct pci_dev *pdev, const
struct pci_device_id *ent)
dev_info(>dev,
"PDC42819 can only drive SATA devices with this
driver\n");
- /* Both Connext and Enmotus devices use non-standard BARs */
+ /* Some devices use non-standard BARs */
if (pdev->vendor == PCI_VENDOR_ID_STMICRO && pdev->device == 0xCC06)
ahci_pci_bar = AHCI_PCI_BAR_STA2X11;
else if (pdev->vendor == 0x1c44 && pdev->device == 0x8000)
ahci_pci_bar = AHCI_PCI_BAR_ENMOTUS;
+ else if (pdev->vendor == 0x177d && pdev->device == 0xa01c)
+ ahci_pci_bar = AHCI_PCI_BAR_CAVIUM;
/*
* The JMicron chip 361/363 contains one SATA controller and one
--
2.1.3
--
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] AHCI: Add generic MSI-X interrupt support to SATA PCI driver
From: Sunil Goutham sgout...@cavium.com
This patch adds generic support for MSI-X interrupts to the SATA PCI
driver. Only single interrupt support is implemented. Thus, per-port
interrupts can not yet be enabled.
The driver now checks the device for the existence of MSI-X and tries
to enable the interrupt. Otherwise, if a device is not MSI-X capable,
the initialization is skipped and MSI or intx interrupts are
configured.
This patch also enables AHCI for Cavium Thunder SoCs that uses MSI-X.
Signed-off-by: Sunil Goutham sgout...@cavium.com
Signed-off-by: Robert Richter rrich...@cavium.com
---
arch/arm64/Kconfig | 1 +
drivers/ata/ahci.c | 40 +++-
2 files changed, 40 insertions(+), 1 deletion(-)
diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
index ac9afde76dea..55970474d3ae 100644
--- a/arch/arm64/Kconfig
+++ b/arch/arm64/Kconfig
@@ -145,6 +145,7 @@ config ARCH_THUNDER
bool Cavium Inc. Thunder SoC Family
help
This enables support for Cavium's Thunder Family of SoCs.
+ select SATA_AHCI
config ARCH_VEXPRESS
bool ARMv8 software model (Versatile Express)
diff --git a/drivers/ata/ahci.c b/drivers/ata/ahci.c
index 5f039f191067..8e43ccb72c95 100644
--- a/drivers/ata/ahci.c
+++ b/drivers/ata/ahci.c
@@ -52,6 +52,7 @@
enum {
AHCI_PCI_BAR_STA2X11= 0,
+ AHCI_PCI_BAR_CAVIUM = 0,
AHCI_PCI_BAR_ENMOTUS= 2,
AHCI_PCI_BAR_STANDARD = 5,
};
@@ -483,6 +484,9 @@ static const struct pci_device_id ahci_pci_tbl[] = {
/* Enmotus */
{ PCI_DEVICE(0x1c44, 0x8000), board_ahci },
+ /* Cavium */
+ { PCI_DEVICE(0x177d, 0xa01c), .driver_data = board_ahci },
+
/* Generic, PCI class code for AHCI */
{ PCI_ANY_ID, PCI_ANY_ID, PCI_ANY_ID, PCI_ANY_ID,
PCI_CLASS_STORAGE_SATA_AHCI, 0xff, board_ahci },
@@ -1188,11 +1192,43 @@ static inline void ahci_gtf_filter_workaround(struct
ata_host *host)
{}
#endif
+static int ahci_init_msix(struct pci_dev *pdev, unsigned int n_ports,
+ struct ahci_host_priv *hpriv)
+{
+ int rc, nvec;
+ struct msix_entry entry = {};
+
+ /* check if msix is supported */
+ nvec = pci_msix_vec_count(pdev);
+ if (nvec = 0)
+ return 0;
+
+ /* per-port msix interrupts are not supported */
+ if (n_ports 1 nvec = n_ports)
+ return -ENOSYS;
+
+ /* only enable the first entry (entry.entry = 0) */
+ rc = pci_enable_msix_exact(pdev, entry, 1);
+ if (rc 0)
+ return rc;
+
+ pdev-irq = entry.vector;
+
+ return 1;
+}
+
static int ahci_init_interrupts(struct pci_dev *pdev, unsigned int n_ports,
struct ahci_host_priv *hpriv)
{
int rc, nvec;
+ nvec = ahci_init_msix(pdev, n_ports, hpriv);
+ if (nvec 0)
+ return nvec;
+
+ if (nvec nvec != -ENOSYS)
+ dev_err(pdev-dev, failed to enable MSI-X: %d, nvec);
+
if (hpriv-flags AHCI_HFLAG_NO_MSI)
goto intx;
@@ -1271,11 +1307,13 @@ static int ahci_init_one(struct pci_dev *pdev, const
struct pci_device_id *ent)
dev_info(pdev-dev,
PDC42819 can only drive SATA devices with this
driver\n);
- /* Both Connext and Enmotus devices use non-standard BARs */
+ /* Some devices use non-standard BARs */
if (pdev-vendor == PCI_VENDOR_ID_STMICRO pdev-device == 0xCC06)
ahci_pci_bar = AHCI_PCI_BAR_STA2X11;
else if (pdev-vendor == 0x1c44 pdev-device == 0x8000)
ahci_pci_bar = AHCI_PCI_BAR_ENMOTUS;
+ else if (pdev-vendor == 0x177d pdev-device == 0xa01c)
+ ahci_pci_bar = AHCI_PCI_BAR_CAVIUM;
/*
* The JMicron chip 361/363 contains one SATA controller and one
--
2.1.3
--
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: [GIT PULL] dts, kbuild: Implement support for dtb vendor subdirs
On 03.11.14 20:47:17, Olof Johansson wrote: > > > Robert Richter (6): > > > dts, arm64: Add dtbs_install make target > > > dts, kbuild: Factor out dtbs install rules to Makefile.dtbinst > > > dts, arm/arm64: Remove dtbs build rules in sub-makes > > > dts, kbuild: Implement support for dtb vendor subdirs > > > dts, arm64: Move dts files to vendor subdirs > > > dts, arm: Remove $(MACHINE) variable from dtbs make recipes > > > > please pull this series for inclusion into v3.19 from: > > > > git://git.kernel.org/pub/scm/linux/kernel/git/rric/linux.git > > dts-subdirs-for-arm-soc-v3.19 > > > > I have updated and rebased the patches to v3.18-rc1. No changes except > > conflict resolution of patch 5/6. > > Pulled, and I added the description from 0/6 as the merge text -- feel free to > add it to the tag if you do something like this in the future. Thanks for pulling and the hint on the tag description (I was wondering what to put in there). -Robert -- 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: [GIT PULL] dts, kbuild: Implement support for dtb vendor subdirs
On 03.11.14 20:47:17, Olof Johansson wrote: Robert Richter (6): dts, arm64: Add dtbs_install make target dts, kbuild: Factor out dtbs install rules to Makefile.dtbinst dts, arm/arm64: Remove dtbs build rules in sub-makes dts, kbuild: Implement support for dtb vendor subdirs dts, arm64: Move dts files to vendor subdirs dts, arm: Remove $(MACHINE) variable from dtbs make recipes please pull this series for inclusion into v3.19 from: git://git.kernel.org/pub/scm/linux/kernel/git/rric/linux.git dts-subdirs-for-arm-soc-v3.19 I have updated and rebased the patches to v3.18-rc1. No changes except conflict resolution of patch 5/6. Pulled, and I added the description from 0/6 as the merge text -- feel free to add it to the tag if you do something like this in the future. Thanks for pulling and the hint on the tag description (I was wondering what to put in there). -Robert -- 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] VNIC: Adding support for Cavium ThunderX network controller
On 03.11.14 10:16:51, Stephen Hemminger wrote: > On Fri, 31 Oct 2014 22:44:11 +0530 > Sunil Kovvuri wrote: > > > On Fri, Oct 31, 2014 at 8:24 AM, Stephen Hemminger > > wrote: > > > On Thu, 30 Oct 2014 17:54:34 +0100 > > > Robert Richter wrote: > > > > > >> +#ifdef VNIC_RSS_SUPPORT > > >> +static int rss_config = RSS_IP_HASH_ENA | RSS_TCP_HASH_ENA | > > >> RSS_UDP_HASH_ENA; > > >> +module_param(rss_config, int, S_IRUGO); > > >> +MODULE_PARM_DESC(rss_config, > > >> + "RSS hash config [bits 8:0] (Bit0:L2 extended, 1:IP, > > >> 2:TCP, 3:TCP SYN, 4:UDP, 5:L4 extended, 6:ROCE 7:L3 bi-directional, 8:L4 > > >> bi-directional)"); > > >> +#endif > > > > > > This should managed be via ethtool ETHTOOL_GRXFH rather than a module > > > parameter. > > Thanks, i will add setting hash options via ETHTOOL_SRXFH as well. > > The idea here is to have a choice of hash while module load (through > > module params) and if it needs to be changed runtime then > > via Ethtool. > > > > Sunil. > > Network developers do not like vendor unique module parameters. > Anything device specific doesn't work in a generic distro environment. Do you accept unique module parameters in parallel to ethtool support or should this be removed? -Robert -- 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] VNIC: Adding support for Cavium ThunderX network controller
On 03.11.14 10:16:51, Stephen Hemminger wrote: On Fri, 31 Oct 2014 22:44:11 +0530 Sunil Kovvuri sunil.kovv...@gmail.com wrote: On Fri, Oct 31, 2014 at 8:24 AM, Stephen Hemminger step...@networkplumber.org wrote: On Thu, 30 Oct 2014 17:54:34 +0100 Robert Richter r...@kernel.org wrote: +#ifdef VNIC_RSS_SUPPORT +static int rss_config = RSS_IP_HASH_ENA | RSS_TCP_HASH_ENA | RSS_UDP_HASH_ENA; +module_param(rss_config, int, S_IRUGO); +MODULE_PARM_DESC(rss_config, + RSS hash config [bits 8:0] (Bit0:L2 extended, 1:IP, 2:TCP, 3:TCP SYN, 4:UDP, 5:L4 extended, 6:ROCE 7:L3 bi-directional, 8:L4 bi-directional)); +#endif This should managed be via ethtool ETHTOOL_GRXFH rather than a module parameter. Thanks, i will add setting hash options via ETHTOOL_SRXFH as well. The idea here is to have a choice of hash while module load (through module params) and if it needs to be changed runtime then via Ethtool. Sunil. Network developers do not like vendor unique module parameters. Anything device specific doesn't work in a generic distro environment. Do you accept unique module parameters in parallel to ethtool support or should this be removed? -Robert -- 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] VNIC: Adding support for Cavium ThunderX network controller
On 30.10.14 19:45:13, Stephen Hemminger wrote: > On Thu, 30 Oct 2014 17:54:34 +0100 > Robert Richter wrote: > > > diff --git a/include/linux/pci_ids.h b/include/linux/pci_ids.h > > index 1fa99a301817..80bd3336691e 100644 > > --- a/include/linux/pci_ids.h > > +++ b/include/linux/pci_ids.h > > @@ -2324,6 +2324,8 @@ > > #define PCI_DEVICE_ID_ALTIMA_AC91000x03ea > > #define PCI_DEVICE_ID_ALTIMA_AC10030x03eb > > > > +#define PCI_VENDOR_ID_CAVIUM 0x177d > > I don't think PCI folks want this updated with every id anymore. This is just the vendor id, the device id is part of the driver. Since there will be multiple drivers I put the vendor id here. -Robert -- 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] VNIC: Adding support for Cavium ThunderX network controller
On 30.10.14 19:45:13, Stephen Hemminger wrote: On Thu, 30 Oct 2014 17:54:34 +0100 Robert Richter r...@kernel.org wrote: diff --git a/include/linux/pci_ids.h b/include/linux/pci_ids.h index 1fa99a301817..80bd3336691e 100644 --- a/include/linux/pci_ids.h +++ b/include/linux/pci_ids.h @@ -2324,6 +2324,8 @@ #define PCI_DEVICE_ID_ALTIMA_AC91000x03ea #define PCI_DEVICE_ID_ALTIMA_AC10030x03eb +#define PCI_VENDOR_ID_CAVIUM 0x177d I don't think PCI folks want this updated with every id anymore. This is just the vendor id, the device id is part of the driver. Since there will be multiple drivers I put the vendor id here. -Robert -- 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: [GIT PULL] dts, kbuild: Implement support for dtb vendor subdirs
Arnd, On 21.10.14 20:15:04, Robert Richter wrote: > please pull this series for inclusion into v3.19 from: > > git://git.kernel.org/pub/scm/linux/kernel/git/rric/linux.git > dts-subdirs-for-arm-soc-v3.19 > > I have updated and rebased the patches to v3.18-rc1. No changes except > conflict resolution of patch 5/6. have you had the chance to look at this? Thanks, -Robert -- 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: [GIT PULL] dts, kbuild: Implement support for dtb vendor subdirs
Arnd, On 21.10.14 20:15:04, Robert Richter wrote: please pull this series for inclusion into v3.19 from: git://git.kernel.org/pub/scm/linux/kernel/git/rric/linux.git dts-subdirs-for-arm-soc-v3.19 I have updated and rebased the patches to v3.18-rc1. No changes except conflict resolution of patch 5/6. have you had the chance to look at this? Thanks, -Robert -- 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/
[GIT PULL] dts, kbuild: Implement support for dtb vendor subdirs
Arnd,
On 05.09.14 08:48:06, Robert Richter wrote:
> From: Robert Richter
>
> For arm64 we want to put dts files into vendor's subdirectories from
> the beginning. This patch set implements this. As this is a generic
> kbuild implementation, vendor subdirs will be also available for
> arch/arm and other architectures. The subdirectory tree is also
> reflected in the install path.
>
> A new makefile variable dts-dirs is introduced to point to dts
> subdirs. This variable is used by kbuild for building and installation
> of dtb files.
>
> A dts Makefile looks now as follows:
>
>
> dtb-$(CONFIG_...) += some_file_1.dtb
> dtb-$(CONFIG_...) += some_file_2.dtb
>
> dts-dirs += dir_vendor_a
> dts-dirs += dir_vendor_b
>
> # come always afterwards:
> always := $(dtb-y)
> subdir-y := $(dts-dirs)
> clean-files:= *.dtb
>
>
> This patches also introduces the dtbs_install make target for
> arm64. Install rules are moved to Makefile.dtbinst using the same
> style and calling convention like for modinst and fwinst.
>
> Robert Richter (6):
> dts, arm64: Add dtbs_install make target
> dts, kbuild: Factor out dtbs install rules to Makefile.dtbinst
> dts, arm/arm64: Remove dtbs build rules in sub-makes
> dts, kbuild: Implement support for dtb vendor subdirs
> dts, arm64: Move dts files to vendor subdirs
> dts, arm: Remove $(MACHINE) variable from dtbs make recipes
please pull this series for inclusion into v3.19 from:
git://git.kernel.org/pub/scm/linux/kernel/git/rric/linux.git
dts-subdirs-for-arm-soc-v3.19
I have updated and rebased the patches to v3.18-rc1. No changes except
conflict resolution of patch 5/6.
Thanks,
-Robert
The following changes since commit f114040e3ea6e07372334ade75d1ee0775c355e1:
Linux 3.18-rc1 (2014-10-19 18:08:38 -0700)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/rric/linux.git
dts-subdirs-for-arm-soc-v3.19
for you to fetch changes up to 6f889d8ba125693778e05f0166b963cf08fed930:
dts, arm: Remove $(MACHINE) variable from dtbs make recipes (2014-10-21
18:07:00 +0200)
dts, kbuild: Implement support for dtb vendor subdirs
Robert Richter (6):
dts, arm64: Add dtbs_install make target
dts, kbuild: Factor out dtbs install rules to Makefile.dtbinst
dts, arm/arm64: Remove dtbs build rules in sub-makes
dts, kbuild: Implement support for dtb vendor subdirs
dts, arm64: Move dts files to vendor subdirs
dts, arm: Remove $(MACHINE) variable from dtbs make recipes
arch/arm/Makefile | 8 +++-
arch/arm/boot/dts/Makefile | 12 +
arch/arm64/Makefile| 10 -
arch/arm64/boot/dts/Makefile | 15 +++
arch/arm64/boot/dts/apm/Makefile | 5 +++
arch/arm64/boot/dts/{ => apm}/apm-mustang.dts | 0
arch/arm64/boot/dts/{ => apm}/apm-storm.dtsi | 0
arch/arm64/boot/dts/arm/Makefile | 6 +++
arch/arm64/boot/dts/{ => arm}/foundation-v8.dts| 0
arch/arm64/boot/dts/{ => arm}/rtsm_ve-aemv8a.dts | 0
.../boot/dts/{ => arm}/rtsm_ve-motherboard.dtsi| 0
arch/arm64/boot/dts/cavium/Makefile| 5 +++
arch/arm64/boot/dts/{ => cavium}/thunder-88xx.dts | 0
arch/arm64/boot/dts/{ => cavium}/thunder-88xx.dtsi | 0
scripts/Kbuild.include | 6 +++
scripts/Makefile.dtbinst | 51 ++
scripts/Makefile.lib | 12 -
17 files changed, 95 insertions(+), 35 deletions(-)
create mode 100644 arch/arm64/boot/dts/apm/Makefile
rename arch/arm64/boot/dts/{ => apm}/apm-mustang.dts (100%)
rename arch/arm64/boot/dts/{ => apm}/apm-storm.dtsi (100%)
create mode 100644 arch/arm64/boot/dts/arm/Makefile
rename arch/arm64/boot/dts/{ => arm}/foundation-v8.dts (100%)
rename arch/arm64/boot/dts/{ => arm}/rtsm_ve-aemv8a.dts (100%)
rename arch/arm64/boot/dts/{ => arm}/rtsm_ve-motherboard.dtsi (100%)
create mode 100644 arch/arm64/boot/dts/cavium/Makefile
rename arch/arm64/boot/dts/{ => cavium}/thunder-88xx.dts (100%)
rename arch/arm64/boot/dts/{ => cavium}/thunder-88xx.dtsi (100%)
create mode 100644 scripts/Makefile.dtbinst
--
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/
[GIT PULL] dts, kbuild: Implement support for dtb vendor subdirs
Arnd,
On 05.09.14 08:48:06, Robert Richter wrote:
From: Robert Richter rrich...@cavium.com
For arm64 we want to put dts files into vendor's subdirectories from
the beginning. This patch set implements this. As this is a generic
kbuild implementation, vendor subdirs will be also available for
arch/arm and other architectures. The subdirectory tree is also
reflected in the install path.
A new makefile variable dts-dirs is introduced to point to dts
subdirs. This variable is used by kbuild for building and installation
of dtb files.
A dts Makefile looks now as follows:
dtb-$(CONFIG_...) += some_file_1.dtb
dtb-$(CONFIG_...) += some_file_2.dtb
dts-dirs += dir_vendor_a
dts-dirs += dir_vendor_b
# come always afterwards:
always := $(dtb-y)
subdir-y := $(dts-dirs)
clean-files:= *.dtb
This patches also introduces the dtbs_install make target for
arm64. Install rules are moved to Makefile.dtbinst using the same
style and calling convention like for modinst and fwinst.
Robert Richter (6):
dts, arm64: Add dtbs_install make target
dts, kbuild: Factor out dtbs install rules to Makefile.dtbinst
dts, arm/arm64: Remove dtbs build rules in sub-makes
dts, kbuild: Implement support for dtb vendor subdirs
dts, arm64: Move dts files to vendor subdirs
dts, arm: Remove $(MACHINE) variable from dtbs make recipes
please pull this series for inclusion into v3.19 from:
git://git.kernel.org/pub/scm/linux/kernel/git/rric/linux.git
dts-subdirs-for-arm-soc-v3.19
I have updated and rebased the patches to v3.18-rc1. No changes except
conflict resolution of patch 5/6.
Thanks,
-Robert
The following changes since commit f114040e3ea6e07372334ade75d1ee0775c355e1:
Linux 3.18-rc1 (2014-10-19 18:08:38 -0700)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/rric/linux.git
dts-subdirs-for-arm-soc-v3.19
for you to fetch changes up to 6f889d8ba125693778e05f0166b963cf08fed930:
dts, arm: Remove $(MACHINE) variable from dtbs make recipes (2014-10-21
18:07:00 +0200)
dts, kbuild: Implement support for dtb vendor subdirs
Robert Richter (6):
dts, arm64: Add dtbs_install make target
dts, kbuild: Factor out dtbs install rules to Makefile.dtbinst
dts, arm/arm64: Remove dtbs build rules in sub-makes
dts, kbuild: Implement support for dtb vendor subdirs
dts, arm64: Move dts files to vendor subdirs
dts, arm: Remove $(MACHINE) variable from dtbs make recipes
arch/arm/Makefile | 8 +++-
arch/arm/boot/dts/Makefile | 12 +
arch/arm64/Makefile| 10 -
arch/arm64/boot/dts/Makefile | 15 +++
arch/arm64/boot/dts/apm/Makefile | 5 +++
arch/arm64/boot/dts/{ = apm}/apm-mustang.dts | 0
arch/arm64/boot/dts/{ = apm}/apm-storm.dtsi | 0
arch/arm64/boot/dts/arm/Makefile | 6 +++
arch/arm64/boot/dts/{ = arm}/foundation-v8.dts| 0
arch/arm64/boot/dts/{ = arm}/rtsm_ve-aemv8a.dts | 0
.../boot/dts/{ = arm}/rtsm_ve-motherboard.dtsi| 0
arch/arm64/boot/dts/cavium/Makefile| 5 +++
arch/arm64/boot/dts/{ = cavium}/thunder-88xx.dts | 0
arch/arm64/boot/dts/{ = cavium}/thunder-88xx.dtsi | 0
scripts/Kbuild.include | 6 +++
scripts/Makefile.dtbinst | 51 ++
scripts/Makefile.lib | 12 -
17 files changed, 95 insertions(+), 35 deletions(-)
create mode 100644 arch/arm64/boot/dts/apm/Makefile
rename arch/arm64/boot/dts/{ = apm}/apm-mustang.dts (100%)
rename arch/arm64/boot/dts/{ = apm}/apm-storm.dtsi (100%)
create mode 100644 arch/arm64/boot/dts/arm/Makefile
rename arch/arm64/boot/dts/{ = arm}/foundation-v8.dts (100%)
rename arch/arm64/boot/dts/{ = arm}/rtsm_ve-aemv8a.dts (100%)
rename arch/arm64/boot/dts/{ = arm}/rtsm_ve-motherboard.dtsi (100%)
create mode 100644 arch/arm64/boot/dts/cavium/Makefile
rename arch/arm64/boot/dts/{ = cavium}/thunder-88xx.dts (100%)
rename arch/arm64/boot/dts/{ = cavium}/thunder-88xx.dtsi (100%)
create mode 100644 scripts/Makefile.dtbinst
--
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: [GIT PULL] dts, kbuild: Implement support for dtb vendor subdirs
On 20.10.14 19:26:32, Abhilash Kesavan wrote: > >> > > > > Robert Richter (6): > >> > > > > dts, arm64: Add dtbs_install make target > >> > > > > dts, kbuild: Factor out dtbs install rules to Makefile.dtbinst > >> > > > > dts, arm/arm64: Remove dtbs build rules in sub-makes > >> > > > > dts, kbuild: Implement support for dtb vendor subdirs > >> > > > > dts, arm64: Move dts files to vendor subdirs > >> > > > > dts, arm: Remove $(MACHINE) variable from dtbs make recipes > > you may want to pull from here alternatively. > > I have been using your patchset as the base for my new arm64 SoC > support (http://www.spinics.net/lists/linux-samsung-soc/msg37047.html). > Are you planning to rebase and send this again as some of the patches > did not apply cleanly for me on linux-next. Yes, I will rebase it and resend the pull request this week. -Robert -- 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: [GIT PULL] dts, kbuild: Implement support for dtb vendor subdirs
On 20.10.14 19:26:32, Abhilash Kesavan wrote: Robert Richter (6): dts, arm64: Add dtbs_install make target dts, kbuild: Factor out dtbs install rules to Makefile.dtbinst dts, arm/arm64: Remove dtbs build rules in sub-makes dts, kbuild: Implement support for dtb vendor subdirs dts, arm64: Move dts files to vendor subdirs dts, arm: Remove $(MACHINE) variable from dtbs make recipes you may want to pull from here alternatively. I have been using your patchset as the base for my new arm64 SoC support (http://www.spinics.net/lists/linux-samsung-soc/msg37047.html). Are you planning to rebase and send this again as some of the patches did not apply cleanly for me on linux-next. Yes, I will rebase it and resend the pull request this week. -Robert -- 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 3/6] pci, thunder: Add PCIe host controller devicetree bindings
On 08.10.14 17:44:32, Liviu Dudau wrote: > On Wed, Oct 08, 2014 at 09:49:27AM +0100, Robert Richter wrote: > > On 07.10.14 16:01:49, Liviu Dudau wrote: > > I am quite confused a bit on which is the latest code base now. I was > > looking into Bjorn's pci/host-generic and there is a different > > implemetation: > > This differs also from v13. Please check. > I'm not sure what you are looking at. Commit 41e5c0f81d3e does look like > my v13. Not sure why you are still seeing this v11 version. Right, my bad. Sorry for the noise. -Robert -- 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 3/6] pci, thunder: Add PCIe host controller devicetree bindings
On 08.10.14 17:44:32, Liviu Dudau wrote: On Wed, Oct 08, 2014 at 09:49:27AM +0100, Robert Richter wrote: On 07.10.14 16:01:49, Liviu Dudau wrote: I am quite confused a bit on which is the latest code base now. I was looking into Bjorn's pci/host-generic and there is a different implemetation: This differs also from v13. Please check. I'm not sure what you are looking at. Commit 41e5c0f81d3e does look like my v13. Not sure why you are still seeing this v11 version. Right, my bad. Sorry for the noise. -Robert -- 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 v13 00/12] Support for creating generic PCI host bridges from DT
On 08.10.14 10:13:21, Liviu Dudau wrote: > On Wed, Oct 08, 2014 at 08:44:28AM +0100, Robert Richter wrote: > > I assume pci/host-generic is the latest now with this issue fixed as > > the commit date is 2014-10-01 past you message above, right? So is it > > ok to rebase our host controller driver onto pci/host-generic or will > > there be further updates or any other branch that is newer? > > You can rebase either on top of Bjorn's next branch or use linux-next. Hope to > see it in v3.18 soon. Thanks Liviu. So I will use pci/host-generic which is what is in pci/next: d1e6dc91b532 arm64: Add architectural support for PCI -Robert -- 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 3/6] pci, thunder: Add PCIe host controller devicetree bindings
On 07.10.14 16:01:49, Liviu Dudau wrote:
> On Tue, Oct 07, 2014 at 03:27:44PM +0100, Robert Richter wrote:
> > On 24.09.14 18:06:04, Arnd Bergmann wrote:
> > > > + compatible = "cavium,thunder-pcie";
> > > > + device_type = "pci";
> > > > + msi-parent = <>;
> > > > + bus-range = <0 255>;
> > > > + #size-cells = <2>;
> > > > + #address-cells = <3>;
> > > > + reg = <0x8480 0x 0 0x1000>; /*
> > > > Configuration space */
> > > > + ranges = <0x0300 0x8010 0x 0x8010
> > > > 0x 0x70 0x>, /* mem ranges */
> > > > + <0x0300 0x8300 0x 0x8300 0x
> > > > 0x80 0x>,
> > > > + <0x0300 0x87e0 0x 0x87e0 0x
> > > > 0x01 0x>;
> > > > +};
> > >
> > > If you claim the entire 0-255 bus range, I think you should also
> > > specify a domain, otherwise it's not predictable which domain you
> > > get.
> >
> > Liviu's code assigns a unique id to the domain if missing, see
> > of_pci_get_domain_nr(). So I don't think we need to add a "pci-domain"
> > property here.
>
> Not anymore! That function is gone in v12 onwards. What is in -next has
> a new function called of_get_pci_domain_nr() (slight name change) but
> that only gets the value set in the "linux,pci-domain" property of the
> device node. It is the choice of the host bridge driver to use that
> function or to use pci_get_new_domain_nr() which *does* generate an
> unique id every time it gets called.
I am quite confused a bit on which is the latest code base now. I was
looking into Bjorn's pci/host-generic and there is a different
implemetation:
/**
* This function will try to obtain the host bridge domain number by
* using of_alias_get_id() call with "pci-domain" as a stem. If that
* fails, a local allocator will be used. The local allocator can
* be requested to return a new domain_nr if the information is missing
* from the device tree.
*
* @node: device tree node with the domain information
* @allocate_if_missing: if DT lacks information about the domain nr,
* allocate a new number.
*
* Returns the associated domain number from DT, or a new domain number
* if DT information is missing and @allocate_if_missing is true. If
* @allocate_if_missing is false then the last allocated domain number
* will be returned.
*/
int of_pci_get_domain_nr(struct device_node *node, bool allocate_if_missing)
{
int domain;
domain = atomic_read(_domain_nr);
if (domain == -1) {
/* first run, get max defined domain nr in device tree */
domain = of_get_max_pci_domain_nr();
/* then set the start value for allocator to be max + 1 */
atomic_set(_domain_nr, domain + 1);
}
domain = of_alias_get_id(node, "pci-domain");
if (domain == -ENODEV) {
domain = atomic_read(_domain_nr);
if (allocate_if_missing)
atomic_inc(_domain_nr);
}
return domain;
}
EXPORT_SYMBOL_GPL(of_pci_get_domain_nr);
This differs also from v13. Please check.
It would be good to have a stable code base to work with, so I would
prefer incremental patches on top of Bjorn's pci/host-generic.
> > Liviu's DT implementation that assigns a unique number differs a bit
> > from ACPI which states: "If _SEG [aka domain number] does not exist,
> > OSPM assumes that all PCI bus segments are in PCI Segment Group 0."
> >
> > Maybe of_pci_get_domain_nr() should be similar to ACPI. If there are
> > multiple root bridges, the "pci-domain" property could be forced
> > instead.
>
> Indeed. But the enforcing is left as an exercise to the host bridge
> implementor for the moment.
Right, can be added later.
Thanks,
-Robert
--
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 v13 00/12] Support for creating generic PCI host bridges from DT
Liviu, Bjorn, On 30.09.14 17:54:31, Liviu Dudau wrote: > On Tue, Sep 30, 2014 at 05:18:05PM +0100, Bjorn Helgaas wrote: > > OK, I rebuilt pci/host-generic from scratch. It consists of your v13 > > patches + Arnd's build fix for pci_pio_to_address() in !CONFIG_OF configs. > > Something went wrong with the integration, patch 02 adds another definition > of > of_pci_range_to_resource() before it is moved out of the header file for some > reason. I assume pci/host-generic is the latest now with this issue fixed as the commit date is 2014-10-01 past you message above, right? So is it ok to rebase our host controller driver onto pci/host-generic or will there be further updates or any other branch that is newer? Thanks, -Robert -- 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 v13 00/12] Support for creating generic PCI host bridges from DT
Liviu, Bjorn, On 30.09.14 17:54:31, Liviu Dudau wrote: On Tue, Sep 30, 2014 at 05:18:05PM +0100, Bjorn Helgaas wrote: OK, I rebuilt pci/host-generic from scratch. It consists of your v13 patches + Arnd's build fix for pci_pio_to_address() in !CONFIG_OF configs. Something went wrong with the integration, patch 02 adds another definition of of_pci_range_to_resource() before it is moved out of the header file for some reason. I assume pci/host-generic is the latest now with this issue fixed as the commit date is 2014-10-01 past you message above, right? So is it ok to rebase our host controller driver onto pci/host-generic or will there be further updates or any other branch that is newer? Thanks, -Robert -- 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 3/6] pci, thunder: Add PCIe host controller devicetree bindings
On 07.10.14 16:01:49, Liviu Dudau wrote:
On Tue, Oct 07, 2014 at 03:27:44PM +0100, Robert Richter wrote:
On 24.09.14 18:06:04, Arnd Bergmann wrote:
+ compatible = cavium,thunder-pcie;
+ device_type = pci;
+ msi-parent = its;
+ bus-range = 0 255;
+ #size-cells = 2;
+ #address-cells = 3;
+ reg = 0x8480 0x 0 0x1000; /*
Configuration space */
+ ranges = 0x0300 0x8010 0x 0x8010
0x 0x70 0x, /* mem ranges */
+ 0x0300 0x8300 0x 0x8300 0x
0x80 0x,
+ 0x0300 0x87e0 0x 0x87e0 0x
0x01 0x;
+};
If you claim the entire 0-255 bus range, I think you should also
specify a domain, otherwise it's not predictable which domain you
get.
Liviu's code assigns a unique id to the domain if missing, see
of_pci_get_domain_nr(). So I don't think we need to add a pci-domain
property here.
Not anymore! That function is gone in v12 onwards. What is in -next has
a new function called of_get_pci_domain_nr() (slight name change) but
that only gets the value set in the linux,pci-domain property of the
device node. It is the choice of the host bridge driver to use that
function or to use pci_get_new_domain_nr() which *does* generate an
unique id every time it gets called.
I am quite confused a bit on which is the latest code base now. I was
looking into Bjorn's pci/host-generic and there is a different
implemetation:
/**
* This function will try to obtain the host bridge domain number by
* using of_alias_get_id() call with pci-domain as a stem. If that
* fails, a local allocator will be used. The local allocator can
* be requested to return a new domain_nr if the information is missing
* from the device tree.
*
* @node: device tree node with the domain information
* @allocate_if_missing: if DT lacks information about the domain nr,
* allocate a new number.
*
* Returns the associated domain number from DT, or a new domain number
* if DT information is missing and @allocate_if_missing is true. If
* @allocate_if_missing is false then the last allocated domain number
* will be returned.
*/
int of_pci_get_domain_nr(struct device_node *node, bool allocate_if_missing)
{
int domain;
domain = atomic_read(of_domain_nr);
if (domain == -1) {
/* first run, get max defined domain nr in device tree */
domain = of_get_max_pci_domain_nr();
/* then set the start value for allocator to be max + 1 */
atomic_set(of_domain_nr, domain + 1);
}
domain = of_alias_get_id(node, pci-domain);
if (domain == -ENODEV) {
domain = atomic_read(of_domain_nr);
if (allocate_if_missing)
atomic_inc(of_domain_nr);
}
return domain;
}
EXPORT_SYMBOL_GPL(of_pci_get_domain_nr);
This differs also from v13. Please check.
It would be good to have a stable code base to work with, so I would
prefer incremental patches on top of Bjorn's pci/host-generic.
Liviu's DT implementation that assigns a unique number differs a bit
from ACPI which states: If _SEG [aka domain number] does not exist,
OSPM assumes that all PCI bus segments are in PCI Segment Group 0.
Maybe of_pci_get_domain_nr() should be similar to ACPI. If there are
multiple root bridges, the pci-domain property could be forced
instead.
Indeed. But the enforcing is left as an exercise to the host bridge
implementor for the moment.
Right, can be added later.
Thanks,
-Robert
--
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 v13 00/12] Support for creating generic PCI host bridges from DT
On 08.10.14 10:13:21, Liviu Dudau wrote: On Wed, Oct 08, 2014 at 08:44:28AM +0100, Robert Richter wrote: I assume pci/host-generic is the latest now with this issue fixed as the commit date is 2014-10-01 past you message above, right? So is it ok to rebase our host controller driver onto pci/host-generic or will there be further updates or any other branch that is newer? You can rebase either on top of Bjorn's next branch or use linux-next. Hope to see it in v3.18 soon. Thanks Liviu. So I will use pci/host-generic which is what is in pci/next: d1e6dc91b532 arm64: Add architectural support for PCI -Robert -- 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 3/6] pci, thunder: Add PCIe host controller devicetree bindings
On 24.09.14 18:06:04, Arnd Bergmann wrote: > > + compatible = "cavium,thunder-pcie"; > > + device_type = "pci"; > > + msi-parent = <>; > > + bus-range = <0 255>; > > + #size-cells = <2>; > > + #address-cells = <3>; > > + reg = <0x8480 0x 0 0x1000>; /* Configuration > > space */ > > + ranges = <0x0300 0x8010 0x 0x8010 0x > > 0x70 0x>, /* mem ranges */ > > + <0x0300 0x8300 0x 0x8300 0x > > 0x80 0x>, > > + <0x0300 0x87e0 0x 0x87e0 0x > > 0x01 0x>; > > +}; > > If you claim the entire 0-255 bus range, I think you should also > specify a domain, otherwise it's not predictable which domain you > get. Liviu's code assigns a unique id to the domain if missing, see of_pci_get_domain_nr(). So I don't think we need to add a "pci-domain" property here. Liviu's DT implementation that assigns a unique number differs a bit from ACPI which states: "If _SEG [aka domain number] does not exist, OSPM assumes that all PCI bus segments are in PCI Segment Group 0." Maybe of_pci_get_domain_nr() should be similar to ACPI. If there are multiple root bridges, the "pci-domain" property could be forced instead. -Robert -- 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 3/6] pci, thunder: Add PCIe host controller devicetree bindings
On 24.09.14 18:06:04, Arnd Bergmann wrote: + compatible = cavium,thunder-pcie; + device_type = pci; + msi-parent = its; + bus-range = 0 255; + #size-cells = 2; + #address-cells = 3; + reg = 0x8480 0x 0 0x1000; /* Configuration space */ + ranges = 0x0300 0x8010 0x 0x8010 0x 0x70 0x, /* mem ranges */ + 0x0300 0x8300 0x 0x8300 0x 0x80 0x, + 0x0300 0x87e0 0x 0x87e0 0x 0x01 0x; +}; If you claim the entire 0-255 bus range, I think you should also specify a domain, otherwise it's not predictable which domain you get. Liviu's code assigns a unique id to the domain if missing, see of_pci_get_domain_nr(). So I don't think we need to add a pci-domain property here. Liviu's DT implementation that assigns a unique number differs a bit from ACPI which states: If _SEG [aka domain number] does not exist, OSPM assumes that all PCI bus segments are in PCI Segment Group 0. Maybe of_pci_get_domain_nr() should be similar to ACPI. If there are multiple root bridges, the pci-domain property could be forced instead. -Robert -- 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: perf & rasd integration plan
On 30.09.14 10:24:16, Arnaldo Carvalho de Melo wrote: > Em Tue, Sep 30, 2014 at 11:06:21AM +0200, Jean Pihet escreveu: > > The plan is to move the small and generic functions first: util, > > xyarray, cpumap, thread_map etc; then evlist, evsel, trace-event, > > trace-event-parse; and finally integrate rasd into the tools/ dir. > > > > Any thought? Can evlist, evsel etc. be moved at once? > > > > Patches should come soon, when time allows. > > Why don't you add it to tools/rasd/ and in tools/rasd/Makefile you just > go on and add tools/perf/util/evlist.o et all to be linked directly, as > a first step. > > Then, as a second step, we can create a tools/lib/perf/evlist.c having > what is currently used by both tools/perf/ and tools/rasd/, i.e. what is > proven to be useful for something other than perf. It would be good to have tools/lib/perf or so with some base implementation to setup and connect to perf buffers. This is useful for tools not only in tools/. The rasd would be a good reference for this regardless if it is in tools/ or not. I am not sure whether and when rasd will be moved there. > As the need arises, we go on moving things into tools/lib/perf/evlist.c > et all from wherever it appeared first, be it from tools/rasd/, > tools/perf/util/evlist.c or anywhere else. > > Initial rule being that once it is used by multiple tools living in > tools/, then it deserves a place in tools/lib/perf/. So this wouldn't quite work well as it excludes tools not in tools/. -Robert > > Ditto for other stuff currently living in tools/perf/util/. -- 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: [GIT PULL] arm64, thunder: Enable Cavium Thunder SoC Family
Arnd, On 02.10.14 17:44:48, Arnd Bergmann wrote: > On Thursday 02 October 2014 16:44:52 Robert Richter wrote: > > The following changes since commit 9e82bf014195d6f0054982c463575cdce24292be: > > > > Linux 3.17-rc5 (2014-09-14 17:50:12 -0700) > > > > are available in the git repository at: > > > > git://git.kernel.org/pub/scm/linux/kernel/git/rric/linux.git > > tags/for-arm-soc-v3.18 > > > > for you to fetch changes up to 1200e87a26b6b4fe1f473267c83515117e08ee39: > > > > arm64, defconfig: Enable Cavium Thunder SoC in defconfig (2014-09-23 > > 15:10:55 +0200) > > > > > > Enablement patches for Cavium Thunder SoC Family. The patches add > > devicetree and Kconfig support and then add Thunder to the defconfig. > > I've pulled them into a new next/arm64 branch in the arm-soc tree, > but noticed that you had based them on top of -rc5. If you have no > strong reasons to pick a newer -rc, it's better to base on top of > -rc1, to save us trouble with backmerges. > > I ended up rebasing to -rc1, since you gave the option to apply the > patches directly. thanks for applying the patches. Ok, I think a reason to update to -rc5 was a conflict in another patch of my patch stack unrelated to this series. Wasn't aware of backmerging conflicts you might get and will avoid unnecessary updates in the future. > I originally missed the patches because they were not sent to > a...@kernel.org but only to our personal addresses. Please include > the a...@kernel.org address whenever you want patches or pull requests > to get applied (as opposed to reviewed). We are not really taking > new code for arm-soc any more, but this one was first submitted > for inclusion a while back, so I'm making an exception. Will use a...@kernel.org in next requests. > Finally, I also wanted to pull your "dts, kbuild: Implement support > for dtb vendor subdirs", but that clearly conflicts with this series, > and I decided not to pull that and take this one instead. I was hoping one or the other patch set would have applied earlier, then I could have rebased them. Anyway, will do this now and let you know after the merge window closed. > I'm guessing we'd see conflicts with other patches in linux-next, > so I'd rather not do the merge any more now, we can take that one > for 3.19. Fine with me. -Robert -- 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: [GIT PULL] arm64, thunder: Enable Cavium Thunder SoC Family
Arnd, On 02.10.14 17:44:48, Arnd Bergmann wrote: On Thursday 02 October 2014 16:44:52 Robert Richter wrote: The following changes since commit 9e82bf014195d6f0054982c463575cdce24292be: Linux 3.17-rc5 (2014-09-14 17:50:12 -0700) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/rric/linux.git tags/for-arm-soc-v3.18 for you to fetch changes up to 1200e87a26b6b4fe1f473267c83515117e08ee39: arm64, defconfig: Enable Cavium Thunder SoC in defconfig (2014-09-23 15:10:55 +0200) Enablement patches for Cavium Thunder SoC Family. The patches add devicetree and Kconfig support and then add Thunder to the defconfig. I've pulled them into a new next/arm64 branch in the arm-soc tree, but noticed that you had based them on top of -rc5. If you have no strong reasons to pick a newer -rc, it's better to base on top of -rc1, to save us trouble with backmerges. I ended up rebasing to -rc1, since you gave the option to apply the patches directly. thanks for applying the patches. Ok, I think a reason to update to -rc5 was a conflict in another patch of my patch stack unrelated to this series. Wasn't aware of backmerging conflicts you might get and will avoid unnecessary updates in the future. I originally missed the patches because they were not sent to a...@kernel.org but only to our personal addresses. Please include the a...@kernel.org address whenever you want patches or pull requests to get applied (as opposed to reviewed). We are not really taking new code for arm-soc any more, but this one was first submitted for inclusion a while back, so I'm making an exception. Will use a...@kernel.org in next requests. Finally, I also wanted to pull your dts, kbuild: Implement support for dtb vendor subdirs, but that clearly conflicts with this series, and I decided not to pull that and take this one instead. I was hoping one or the other patch set would have applied earlier, then I could have rebased them. Anyway, will do this now and let you know after the merge window closed. I'm guessing we'd see conflicts with other patches in linux-next, so I'd rather not do the merge any more now, we can take that one for 3.19. Fine with me. -Robert -- 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: perf rasd integration plan
On 30.09.14 10:24:16, Arnaldo Carvalho de Melo wrote: Em Tue, Sep 30, 2014 at 11:06:21AM +0200, Jean Pihet escreveu: The plan is to move the small and generic functions first: util, xyarray, cpumap, thread_map etc; then evlist, evsel, trace-event, trace-event-parse; and finally integrate rasd into the tools/ dir. Any thought? Can evlist, evsel etc. be moved at once? Patches should come soon, when time allows. Why don't you add it to tools/rasd/ and in tools/rasd/Makefile you just go on and add tools/perf/util/evlist.o et all to be linked directly, as a first step. Then, as a second step, we can create a tools/lib/perf/evlist.c having what is currently used by both tools/perf/ and tools/rasd/, i.e. what is proven to be useful for something other than perf. It would be good to have tools/lib/perf or so with some base implementation to setup and connect to perf buffers. This is useful for tools not only in tools/. The rasd would be a good reference for this regardless if it is in tools/ or not. I am not sure whether and when rasd will be moved there. As the need arises, we go on moving things into tools/lib/perf/evlist.c et all from wherever it appeared first, be it from tools/rasd/, tools/perf/util/evlist.c or anywhere else. Initial rule being that once it is used by multiple tools living in tools/, then it deserves a place in tools/lib/perf/. So this wouldn't quite work well as it excludes tools not in tools/. -Robert Ditto for other stuff currently living in tools/perf/util/. -- 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/
[GIT PULL] dts, kbuild: Implement support for dtb vendor subdirs
On 23.09.14 13:26:19, Robert Richter wrote:
> On 19.09.14 15:08:56, Catalin Marinas wrote:
> > On Fri, Sep 19, 2014 at 01:30:56PM +0100, Robert Richter wrote:
> > > On 16.09.14 20:49:18, Andrew Bresticker wrote:
> > > > > Robert Richter (6):
> > > > > dts, arm64: Add dtbs_install make target
> > > > > dts, kbuild: Factor out dtbs install rules to Makefile.dtbinst
> > > > > dts, arm/arm64: Remove dtbs build rules in sub-makes
> > > > > dts, kbuild: Implement support for dtb vendor subdirs
> > > > > dts, arm64: Move dts files to vendor subdirs
> > > > > dts, arm: Remove $(MACHINE) variable from dtbs make recipes
> > > >
> > > > I've tested this for arm64 and by adding a vendor sub-directory
> > > > locally for arm. This series is also the base for my MIPS DT vendor
> > > > sub-directory series
> > > > (http://www.linux-mips.org/archives/linux-mips/2014-09/msg00217.html).
> > > > So, for the entire series,
> > > >
> > > > Tested-by: Andrew Bresticker
> > >
> > > Andrew, thanks for testing and great this also works on mips.
> > >
> > > Anyone willing to take the patches for 3.18? Are any further acks
> > > needed?
> >
> > For the arm64 bits in this series:
> >
> > Acked-by: Catalin Marinas
> >
> > I think the patches can be merged via arm-soc.
>
> Olof,
>
> please apply the patches.
Olof, Arnd,
you may want to pull from here alternatively.
Thanks,
-Robert
The following changes since commit a497c3ba1d97fc69c1e78e7b96435ba8c2cb42ee:
Linux 3.16-rc2 (2014-06-21 19:02:54 -1000)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/rric/linux.git
tags/dts-subdirs-for-arm-soc-v3.18
for you to fetch changes up to 87bdf4d8625e50d99b56aa2590a2261049a5fd48:
dts, arm: Remove $(MACHINE) variable from dtbs make recipes (2014-09-03
21:46:49 +0200)
dts, kbuild: Implement support for dtb vendor subdirs
Robert Richter (6):
dts, arm64: Add dtbs_install make target
dts, kbuild: Factor out dtbs install rules to Makefile.dtbinst
dts, arm/arm64: Remove dtbs build rules in sub-makes
dts, kbuild: Implement support for dtb vendor subdirs
dts, arm64: Move dts files to vendor subdirs
dts, arm: Remove $(MACHINE) variable from dtbs make recipes
arch/arm/Makefile | 8 +++-
arch/arm/boot/dts/Makefile | 12 +-
arch/arm64/Makefile| 10 -
arch/arm64/boot/dts/Makefile | 13 +++---
arch/arm64/boot/dts/apm/Makefile | 5 +++
arch/arm64/boot/dts/{ => apm}/apm-mustang.dts | 0
arch/arm64/boot/dts/{ => apm}/apm-storm.dtsi | 0
arch/arm64/boot/dts/arm/Makefile | 6 +++
arch/arm64/boot/dts/{ => arm}/foundation-v8.dts| 0
arch/arm64/boot/dts/{ => arm}/rtsm_ve-aemv8a.dts | 0
.../boot/dts/{ => arm}/rtsm_ve-motherboard.dtsi| 0
scripts/Kbuild.include | 6 +++
scripts/Makefile.dtbinst | 50 ++
scripts/Makefile.lib | 12 --
14 files changed, 88 insertions(+), 34 deletions(-)
create mode 100644 arch/arm64/boot/dts/apm/Makefile
rename arch/arm64/boot/dts/{ => apm}/apm-mustang.dts (100%)
rename arch/arm64/boot/dts/{ => apm}/apm-storm.dtsi (100%)
create mode 100644 arch/arm64/boot/dts/arm/Makefile
rename arch/arm64/boot/dts/{ => arm}/foundation-v8.dts (100%)
rename arch/arm64/boot/dts/{ => arm}/rtsm_ve-aemv8a.dts (100%)
rename arch/arm64/boot/dts/{ => arm}/rtsm_ve-motherboard.dtsi (100%)
create mode 100644 scripts/Makefile.dtbinst
--
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/
[GIT PULL] arm64, thunder: Enable Cavium Thunder SoC Family
([GIT PULL] in the subject) On 02.10.14 09:29:38, Robert Richter wrote: > On 23.09.14 16:14:29, Robert Richter wrote: > > On 23.09.14 12:21:05, Catalin Marinas wrote: > > > On Tue, Sep 23, 2014 at 11:46:41AM +0100, Will Deacon wrote: > > > > On Tue, Sep 23, 2014 at 11:41:22AM +0100, Robert Richter wrote: > > > > > On 12.09.14 19:49:43, Robert Richter wrote: > > > > > > From: Robert Richter > > > > > > > > > > > > This initial patches enable Cavium Thunder SoC Family. The patches > > > > > > add > > > > > > devicetree and Kconfig support and then add Thunder to the > > > > > > defconfig. > > > > > > > > > > > > The Thunder system needs more enablement patches for subsystems and > > > > > > devices, this includes network, ahci, gicv3/gicv3-its, pci, smmu, > > > > > > kvm. > > > > > > We will send separate patch sets for these. All of them base on this > > > > > > initial patches. > > > > > > > > > > > > I sent a separate patch set independently that introduces support > > > > > > for > > > > > > dts vendor subdirs. After both patch sets have been applied I will > > > > > > send a patch in addition that moves the dts file into a > > > > > > subdirectory. > > > > > > > > > > > > I sent another separate patch that sets NR_CPUS to 64 per default. > > > > > > > > > > > > The first patch introduces dts files without having a Kconfig option > > > > > > for the soc (ARCH_THUNDER). However, this is introduced in patch 3 > > > > > > and > > > > > > added to defconfig in patch 4 as this is my preferred solution. If > > > > > > there is still resistance having an ARCH_THUNDER option, just drop > > > > > > them. > > > > > > > > > > > > Patches are available here: > > > > > > > > > > > > git://git.kernel.org/pub/scm/linux/kernel/git/rric/linux.git > > > > > > thunder/init > > > > > > > > > > it would be good if these patches could be applied. > > > > > > > > Catalin's handling the 3.18 merge window, but this looks like arm-soc > > > > material anyway and should go via Olof/Arnd. > > > > > > Yes. Olof said he's cherry-picking arm64 SoC patches (or Robert could > > > send him a pull request). > > > > just in case you want to pull, please pull from: > > > > git://git.kernel.org/pub/scm/linux/kernel/git/rric/linux.git > > tags/for-arm-soc-v3.18 Olof, Arnd, please pull or apply. Thanks, -Robert The following changes since commit 9e82bf014195d6f0054982c463575cdce24292be: Linux 3.17-rc5 (2014-09-14 17:50:12 -0700) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/rric/linux.git tags/for-arm-soc-v3.18 for you to fetch changes up to 1200e87a26b6b4fe1f473267c83515117e08ee39: arm64, defconfig: Enable Cavium Thunder SoC in defconfig (2014-09-23 15:10:55 +0200) Enablement patches for Cavium Thunder SoC Family. The patches add devicetree and Kconfig support and then add Thunder to the defconfig. Radha Mohan Chintakuntla (3): arm64, thunder: Add initial dts for Cavium Thunder SoC arm64, thunder: Document devicetree bindings for Cavium Thunder SoC arm64, thunder: Add Kconfig option for Cavium Thunder SoC Family Robert Richter (1): arm64, defconfig: Enable Cavium Thunder SoC in defconfig Documentation/devicetree/bindings/arm/cavium-thunder.txt | 10 Documentation/devicetree/bindings/arm/cpus.txt | 1 + arch/arm64/Kconfig | 5 ++ arch/arm64/boot/dts/Makefile | 1 + arch/arm64/boot/dts/thunder-88xx.dts | 67 + arch/arm64/boot/dts/thunder-88xx.dtsi| 401 +++ arch/arm64/configs/defconfig | 1 + 7 files changed, 486 insertions(+) create mode 100644 Documentation/devicetree/bindings/arm/cavium-thunder.txt create mode 100644 arch/arm64/boot/dts/thunder-88xx.dts create mode 100644 arch/arm64/boot/dts/thunder-88xx.dtsi -- 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 v3 0/4] arm64, thunder: Enable Cavium Thunder SoC Family
On 23.09.14 16:14:29, Robert Richter wrote: > On 23.09.14 12:21:05, Catalin Marinas wrote: > > On Tue, Sep 23, 2014 at 11:46:41AM +0100, Will Deacon wrote: > > > On Tue, Sep 23, 2014 at 11:41:22AM +0100, Robert Richter wrote: > > > > On 12.09.14 19:49:43, Robert Richter wrote: > > > > > From: Robert Richter > > > > > > > > > > This initial patches enable Cavium Thunder SoC Family. The patches add > > > > > devicetree and Kconfig support and then add Thunder to the defconfig. > > > > > > > > > > The Thunder system needs more enablement patches for subsystems and > > > > > devices, this includes network, ahci, gicv3/gicv3-its, pci, smmu, kvm. > > > > > We will send separate patch sets for these. All of them base on this > > > > > initial patches. > > > > > > > > > > I sent a separate patch set independently that introduces support for > > > > > dts vendor subdirs. After both patch sets have been applied I will > > > > > send a patch in addition that moves the dts file into a subdirectory. > > > > > > > > > > I sent another separate patch that sets NR_CPUS to 64 per default. > > > > > > > > > > The first patch introduces dts files without having a Kconfig option > > > > > for the soc (ARCH_THUNDER). However, this is introduced in patch 3 and > > > > > added to defconfig in patch 4 as this is my preferred solution. If > > > > > there is still resistance having an ARCH_THUNDER option, just drop > > > > > them. > > > > > > > > > > Patches are available here: > > > > > > > > > > git://git.kernel.org/pub/scm/linux/kernel/git/rric/linux.git > > > > > thunder/init > > > > > > > > it would be good if these patches could be applied. > > > > > > Catalin's handling the 3.18 merge window, but this looks like arm-soc > > > material anyway and should go via Olof/Arnd. > > > > Yes. Olof said he's cherry-picking arm64 SoC patches (or Robert could > > send him a pull request). > > just in case you want to pull, please pull from: > > git://git.kernel.org/pub/scm/linux/kernel/git/rric/linux.git > tags/for-arm-soc-v3.18 Olof, Arnd, please pull or apply. Thanks, -Robert -- 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 v3 0/4] arm64, thunder: Enable Cavium Thunder SoC Family
On 23.09.14 16:14:29, Robert Richter wrote: On 23.09.14 12:21:05, Catalin Marinas wrote: On Tue, Sep 23, 2014 at 11:46:41AM +0100, Will Deacon wrote: On Tue, Sep 23, 2014 at 11:41:22AM +0100, Robert Richter wrote: On 12.09.14 19:49:43, Robert Richter wrote: From: Robert Richter rrich...@cavium.com This initial patches enable Cavium Thunder SoC Family. The patches add devicetree and Kconfig support and then add Thunder to the defconfig. The Thunder system needs more enablement patches for subsystems and devices, this includes network, ahci, gicv3/gicv3-its, pci, smmu, kvm. We will send separate patch sets for these. All of them base on this initial patches. I sent a separate patch set independently that introduces support for dts vendor subdirs. After both patch sets have been applied I will send a patch in addition that moves the dts file into a subdirectory. I sent another separate patch that sets NR_CPUS to 64 per default. The first patch introduces dts files without having a Kconfig option for the soc (ARCH_THUNDER). However, this is introduced in patch 3 and added to defconfig in patch 4 as this is my preferred solution. If there is still resistance having an ARCH_THUNDER option, just drop them. Patches are available here: git://git.kernel.org/pub/scm/linux/kernel/git/rric/linux.git thunder/init it would be good if these patches could be applied. Catalin's handling the 3.18 merge window, but this looks like arm-soc material anyway and should go via Olof/Arnd. Yes. Olof said he's cherry-picking arm64 SoC patches (or Robert could send him a pull request). just in case you want to pull, please pull from: git://git.kernel.org/pub/scm/linux/kernel/git/rric/linux.git tags/for-arm-soc-v3.18 Olof, Arnd, please pull or apply. Thanks, -Robert -- 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/
[GIT PULL] arm64, thunder: Enable Cavium Thunder SoC Family
([GIT PULL] in the subject) On 02.10.14 09:29:38, Robert Richter wrote: On 23.09.14 16:14:29, Robert Richter wrote: On 23.09.14 12:21:05, Catalin Marinas wrote: On Tue, Sep 23, 2014 at 11:46:41AM +0100, Will Deacon wrote: On Tue, Sep 23, 2014 at 11:41:22AM +0100, Robert Richter wrote: On 12.09.14 19:49:43, Robert Richter wrote: From: Robert Richter rrich...@cavium.com This initial patches enable Cavium Thunder SoC Family. The patches add devicetree and Kconfig support and then add Thunder to the defconfig. The Thunder system needs more enablement patches for subsystems and devices, this includes network, ahci, gicv3/gicv3-its, pci, smmu, kvm. We will send separate patch sets for these. All of them base on this initial patches. I sent a separate patch set independently that introduces support for dts vendor subdirs. After both patch sets have been applied I will send a patch in addition that moves the dts file into a subdirectory. I sent another separate patch that sets NR_CPUS to 64 per default. The first patch introduces dts files without having a Kconfig option for the soc (ARCH_THUNDER). However, this is introduced in patch 3 and added to defconfig in patch 4 as this is my preferred solution. If there is still resistance having an ARCH_THUNDER option, just drop them. Patches are available here: git://git.kernel.org/pub/scm/linux/kernel/git/rric/linux.git thunder/init it would be good if these patches could be applied. Catalin's handling the 3.18 merge window, but this looks like arm-soc material anyway and should go via Olof/Arnd. Yes. Olof said he's cherry-picking arm64 SoC patches (or Robert could send him a pull request). just in case you want to pull, please pull from: git://git.kernel.org/pub/scm/linux/kernel/git/rric/linux.git tags/for-arm-soc-v3.18 Olof, Arnd, please pull or apply. Thanks, -Robert The following changes since commit 9e82bf014195d6f0054982c463575cdce24292be: Linux 3.17-rc5 (2014-09-14 17:50:12 -0700) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/rric/linux.git tags/for-arm-soc-v3.18 for you to fetch changes up to 1200e87a26b6b4fe1f473267c83515117e08ee39: arm64, defconfig: Enable Cavium Thunder SoC in defconfig (2014-09-23 15:10:55 +0200) Enablement patches for Cavium Thunder SoC Family. The patches add devicetree and Kconfig support and then add Thunder to the defconfig. Radha Mohan Chintakuntla (3): arm64, thunder: Add initial dts for Cavium Thunder SoC arm64, thunder: Document devicetree bindings for Cavium Thunder SoC arm64, thunder: Add Kconfig option for Cavium Thunder SoC Family Robert Richter (1): arm64, defconfig: Enable Cavium Thunder SoC in defconfig Documentation/devicetree/bindings/arm/cavium-thunder.txt | 10 Documentation/devicetree/bindings/arm/cpus.txt | 1 + arch/arm64/Kconfig | 5 ++ arch/arm64/boot/dts/Makefile | 1 + arch/arm64/boot/dts/thunder-88xx.dts | 67 + arch/arm64/boot/dts/thunder-88xx.dtsi| 401 +++ arch/arm64/configs/defconfig | 1 + 7 files changed, 486 insertions(+) create mode 100644 Documentation/devicetree/bindings/arm/cavium-thunder.txt create mode 100644 arch/arm64/boot/dts/thunder-88xx.dts create mode 100644 arch/arm64/boot/dts/thunder-88xx.dtsi -- 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/
[GIT PULL] dts, kbuild: Implement support for dtb vendor subdirs
On 23.09.14 13:26:19, Robert Richter wrote:
On 19.09.14 15:08:56, Catalin Marinas wrote:
On Fri, Sep 19, 2014 at 01:30:56PM +0100, Robert Richter wrote:
On 16.09.14 20:49:18, Andrew Bresticker wrote:
Robert Richter (6):
dts, arm64: Add dtbs_install make target
dts, kbuild: Factor out dtbs install rules to Makefile.dtbinst
dts, arm/arm64: Remove dtbs build rules in sub-makes
dts, kbuild: Implement support for dtb vendor subdirs
dts, arm64: Move dts files to vendor subdirs
dts, arm: Remove $(MACHINE) variable from dtbs make recipes
I've tested this for arm64 and by adding a vendor sub-directory
locally for arm. This series is also the base for my MIPS DT vendor
sub-directory series
(http://www.linux-mips.org/archives/linux-mips/2014-09/msg00217.html).
So, for the entire series,
Tested-by: Andrew Bresticker abres...@chromium.org
Andrew, thanks for testing and great this also works on mips.
Anyone willing to take the patches for 3.18? Are any further acks
needed?
For the arm64 bits in this series:
Acked-by: Catalin Marinas catalin.mari...@arm.com
I think the patches can be merged via arm-soc.
Olof,
please apply the patches.
Olof, Arnd,
you may want to pull from here alternatively.
Thanks,
-Robert
The following changes since commit a497c3ba1d97fc69c1e78e7b96435ba8c2cb42ee:
Linux 3.16-rc2 (2014-06-21 19:02:54 -1000)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/rric/linux.git
tags/dts-subdirs-for-arm-soc-v3.18
for you to fetch changes up to 87bdf4d8625e50d99b56aa2590a2261049a5fd48:
dts, arm: Remove $(MACHINE) variable from dtbs make recipes (2014-09-03
21:46:49 +0200)
dts, kbuild: Implement support for dtb vendor subdirs
Robert Richter (6):
dts, arm64: Add dtbs_install make target
dts, kbuild: Factor out dtbs install rules to Makefile.dtbinst
dts, arm/arm64: Remove dtbs build rules in sub-makes
dts, kbuild: Implement support for dtb vendor subdirs
dts, arm64: Move dts files to vendor subdirs
dts, arm: Remove $(MACHINE) variable from dtbs make recipes
arch/arm/Makefile | 8 +++-
arch/arm/boot/dts/Makefile | 12 +-
arch/arm64/Makefile| 10 -
arch/arm64/boot/dts/Makefile | 13 +++---
arch/arm64/boot/dts/apm/Makefile | 5 +++
arch/arm64/boot/dts/{ = apm}/apm-mustang.dts | 0
arch/arm64/boot/dts/{ = apm}/apm-storm.dtsi | 0
arch/arm64/boot/dts/arm/Makefile | 6 +++
arch/arm64/boot/dts/{ = arm}/foundation-v8.dts| 0
arch/arm64/boot/dts/{ = arm}/rtsm_ve-aemv8a.dts | 0
.../boot/dts/{ = arm}/rtsm_ve-motherboard.dtsi| 0
scripts/Kbuild.include | 6 +++
scripts/Makefile.dtbinst | 50 ++
scripts/Makefile.lib | 12 --
14 files changed, 88 insertions(+), 34 deletions(-)
create mode 100644 arch/arm64/boot/dts/apm/Makefile
rename arch/arm64/boot/dts/{ = apm}/apm-mustang.dts (100%)
rename arch/arm64/boot/dts/{ = apm}/apm-storm.dtsi (100%)
create mode 100644 arch/arm64/boot/dts/arm/Makefile
rename arch/arm64/boot/dts/{ = arm}/foundation-v8.dts (100%)
rename arch/arm64/boot/dts/{ = arm}/rtsm_ve-aemv8a.dts (100%)
rename arch/arm64/boot/dts/{ = arm}/rtsm_ve-motherboard.dtsi (100%)
create mode 100644 scripts/Makefile.dtbinst
--
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 5/6] arm64, defconfig: Enable PCI
On 24.09.14 18:14:11, Arnd Bergmann wrote: > On Wednesday 24 September 2014 17:37:47 Robert Richter wrote: > > config PCI > > bool "PCI support" > > + default y > > help > > This feature enables support for PCIe bus system. If you say Y > > here, the kernel will include drivers and infrastructure code > > to support PCIe bus devices. > > > > +config PCI_MSI > > + def_bool PCI > > + > > config PCI_DOMAINS > > def_bool PCI > > There is already a PCI_MSI symbol in drivers/pci/Kconfig. Just select that > from the PCI symbol above rather than defining a second one. The intention is not to have a second definition, instead this should enable the default value just for arm64. Thus I put it to arch/arm64/Kconfig. Otherwise it would be enabled per default on all archs. We could have used select in config ARM64, but I tried to avoid using select due to the dependency issue and instead implement this with default-y/depends-on. Doing so it can be manually disabled too. -Robert -- 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 0/6] pci, thunder: Add Cavium Thunder PCIe host controller
From: Robert Richter This patches add support for the Cavium Thunder PCIe host controller. Patches base on following branches: git://git.kernel.org/pub/scm/linux/kernel/git/helgaas/pci pci/liviu-generic-v11 git://linux-arm.org/linux-ld for-upstream/pci_arm64_v11 Additionally a fix is required for liviu-generic-v11 to allow the generation of mem-mapped pci ranges: https://lkml.org/lkml/2014/9/22/150 It also requires Marc's gicv3-its support to work. The first patch introduces the host controller driver. Patch 2 to 4 are DT changes including documentation. Patch 5 and 6 enable PCI support for arm64 defconfig. Robert Richter (2): arm64, defconfig: Enable PCI pci, thunder: Enable Cavium Thunder PCIe host controller Sunil Goutham (3): pci, thunder: Add support for Thunder PCIe host controller pci, thunder: Add PCIe host controller devicetree bindings pci, thunder: Document PCIe host controller devicetree bindings Tirumalesh Chalamarla (1): GICv3: Add ITS entry to THUNDER dts .../devicetree/bindings/pci/cavium,thunder-pci.txt | 32 +++ arch/arm64/Kconfig | 15 ++ arch/arm64/boot/dts/thunder-88xx.dtsi | 58 + drivers/pci/host/Kconfig | 8 + drivers/pci/host/Makefile | 1 + drivers/pci/host/pcie-thunder.c| 246 + include/linux/pci_ids.h| 2 + 7 files changed, 362 insertions(+) create mode 100644 Documentation/devicetree/bindings/pci/cavium,thunder-pci.txt create mode 100644 drivers/pci/host/pcie-thunder.c -- 2.1.0 -- 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 4/6] pci, thunder: Document PCIe host controller devicetree bindings
From: Sunil Goutham
This patch adds documentation for the devicetree bindings used by the
Thunder PCI host controller.
Signed-off-by: Sunil Goutham
Signed-off-by: Robert Richter
---
.../devicetree/bindings/pci/cavium,thunder-pci.txt | 32 ++
1 file changed, 32 insertions(+)
create mode 100644 Documentation/devicetree/bindings/pci/cavium,thunder-pci.txt
diff --git a/Documentation/devicetree/bindings/pci/cavium,thunder-pci.txt
b/Documentation/devicetree/bindings/pci/cavium,thunder-pci.txt
new file mode 100644
index ..c8ff3d2e8630
--- /dev/null
+++ b/Documentation/devicetree/bindings/pci/cavium,thunder-pci.txt
@@ -0,0 +1,32 @@
+* Cavium Thunder PCIe interface
+
+Required properties:
+- compatible: should contain "cavium,thunder-pcie" to identify the core.
+- device_type: set to "pci"
+- #address-cells: set to <3>
+- #size-cells: set to <2>
+- #stream-id-cells: set to <1>
+- bus-range: PCI bus numbers covered
+- reg: base address and length of the pcie configuration space.
+- ranges: ranges for the PCI memory regions.
+- msi-parent: Link to the hardware entity that serves as the Message
+ Signaled Interrupt controller for this PCI controller.
+
+Example:
+
+SoC specific DT Entry:
+
+ pcie0: pcie0@0x8480 {
+ compatible = "cavium,thunder-pcie";
+ device_type = "pci";
+ msi-parent = <>;
+ bus-range = <0 255>;
+ #size-cells = <2>;
+ #address-cells = <3>;
+ #stream-id-cells = <1>;
+ reg = <0x8480 0x 0 0x1000>; /* Configuration space
*/
+ ranges = <0x0300 0x8010 0x 0x8010 0x 0x70
0x>, /* mem */
+ <0x0300 0x8300 0x 0x8300 0x 0x80
0x>,
+ <0x0300 0x87e0 0x 0x87e0 0x 0x01
0x>;
+ };
+
--
2.1.0
--
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 1/6] pci, thunder: Add support for Thunder PCIe host controller
From: Sunil Goutham
This patch adds support for PCI host controller of Cavium Thunder
SoCs.
Signed-off-by: Sunil Goutham
Signed-off-by: Robert Richter
---
drivers/pci/host/Kconfig| 8 ++
drivers/pci/host/Makefile | 1 +
drivers/pci/host/pcie-thunder.c | 246
include/linux/pci_ids.h | 2 +
4 files changed, 257 insertions(+)
create mode 100644 drivers/pci/host/pcie-thunder.c
diff --git a/drivers/pci/host/Kconfig b/drivers/pci/host/Kconfig
index 90f5ccacce4b..269c3ff786bc 100644
--- a/drivers/pci/host/Kconfig
+++ b/drivers/pci/host/Kconfig
@@ -63,4 +63,12 @@ config PCIE_SPEAR13XX
help
Say Y here if you want PCIe support on SPEAr13XX SoCs.
+config PCI_THUNDER
+ bool "Thunder PCIe host controller"
+ depends on ARM64 || COMPILE_TEST
+ depends on OF_PCI
+ depends on PCI_MSI
+ help
+ Say Y here if you want internal PCI support on Thunder SoC.
+
endmenu
diff --git a/drivers/pci/host/Makefile b/drivers/pci/host/Makefile
index d0e88f114ff9..fd8041da1719 100644
--- a/drivers/pci/host/Makefile
+++ b/drivers/pci/host/Makefile
@@ -8,3 +8,4 @@ obj-$(CONFIG_PCI_RCAR_GEN2) += pci-rcar-gen2.o
obj-$(CONFIG_PCI_RCAR_GEN2_PCIE) += pcie-rcar.o
obj-$(CONFIG_PCI_HOST_GENERIC) += pci-host-generic.o
obj-$(CONFIG_PCIE_SPEAR13XX) += pcie-spear13xx.o
+obj-$(CONFIG_PCI_THUNDER) += pcie-thunder.o
diff --git a/drivers/pci/host/pcie-thunder.c b/drivers/pci/host/pcie-thunder.c
new file mode 100644
index ..947fad3b1980
--- /dev/null
+++ b/drivers/pci/host/pcie-thunder.c
@@ -0,0 +1,246 @@
+/*
+ * PCIe host controller driver for Cavium Thunder SOC
+ *
+ * Copyright (C) 2014, Cavium Inc.
+ *
+ * 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.
+ */
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#define PCI_DEVICE_ID_THUNDER_BRIDGE 0xa002
+
+#define THUNDER_PCIE_BUS_SHIFT 20
+#define THUNDER_PCIE_DEV_SHIFT 15
+#define THUNDER_PCIE_FUNC_SHIFT12
+
+struct thunder_pcie {
+ struct device_node *node;
+ struct device *dev;
+ void __iomem*cfg_base;
+ struct msi_chip *msi;
+};
+
+/*
+ * This bridge is just for the sake of supporting ARI for
+ * downstream devices. No resources are attached to it.
+ * Copy upstream root bus resources to bridge which aide in
+ * resource claiming for downstream devices
+ */
+static void pci_bridge_resource_fixup(struct pci_dev *dev)
+{
+ struct pci_bus *bus;
+ int resno;
+
+ bus = dev->subordinate;
+ for (resno = 0; resno < PCI_BRIDGE_RESOURCE_NUM; resno++) {
+ bus->resource[resno] = pci_bus_resource_n(bus->parent,
+ PCI_BRIDGE_RESOURCE_NUM + resno);
+ }
+
+ for (resno = PCI_BRIDGE_RESOURCES;
+ resno <= PCI_BRIDGE_RESOURCE_END; resno++) {
+ dev->resource[resno].start = dev->resource[resno].end = 0;
+ dev->resource[resno].flags = 0;
+ }
+}
+DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_CAVIUM, PCI_DEVICE_ID_THUNDER_BRIDGE,
+ pci_bridge_resource_fixup);
+
+/*
+ * All PCIe devices in Thunder have fixed resources, shouldn't be reassigned.
+ * Also claim the device's valid resources to set 'res->parent' hierarchy.
+ */
+static void pci_dev_resource_fixup(struct pci_dev *dev)
+{
+ struct resource *res;
+ int resno;
+
+ for (resno = 0; resno < PCI_NUM_RESOURCES; resno++)
+ dev->resource[resno].flags |= IORESOURCE_PCI_FIXED;
+
+ for (resno = 0; resno < PCI_BRIDGE_RESOURCES; resno++) {
+ res = >resource[resno];
+ if (res->parent || !(res->flags & IORESOURCE_MEM))
+ continue;
+ pci_claim_resource(dev, resno);
+ }
+}
+DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_CAVIUM, PCI_ANY_ID,
+ pci_dev_resource_fixup);
+
+static void __iomem *thunder_pcie_cfg_base(struct thunder_pcie *pcie,
+unsigned int bus, unsigned int devfn)
+{
+ return pcie->cfg_base + ((bus << THUNDER_PCIE_BUS_SHIFT)
+ | (PCI_SLOT(devfn) << THUNDER_PCIE_DEV_SHIFT)
+ | (PCI_FUNC(devfn) << THUNDER_PCIE_FUNC_SHIFT));
+}
+
+static int thunder_pcie_read_config(struct pci_bus *bus, unsigned int devfn,
+ int reg, int size, u32 *val)
+{
+ struct thunder_pcie *pcie = bus->sysdata;
+ void __iomem *addr;
+ unsigned int busnr = bus->number;
+
+ if (busnr > 255 || devfn > 255 || reg > 4095)
+ return PCIBIOS_DEVICE_NOT_
[PATCH 2/6] GICv3: Add ITS entry to THUNDER dts
From: Tirumalesh Chalamarla
The PCIe host controller uses MSIs provided by GICv3 ITS. Enable it on
Thunder SoCs by adding an entry to DT.
Signed-off-by: Tirumalesh Chalamarla
Signed-off-by: Robert Richter
---
arch/arm64/boot/dts/thunder-88xx.dtsi | 9 +
1 file changed, 9 insertions(+)
diff --git a/arch/arm64/boot/dts/thunder-88xx.dtsi
b/arch/arm64/boot/dts/thunder-88xx.dtsi
index d8c0bdc51882..9cb7cf94284a 100644
--- a/arch/arm64/boot/dts/thunder-88xx.dtsi
+++ b/arch/arm64/boot/dts/thunder-88xx.dtsi
@@ -376,10 +376,19 @@
gic0: interrupt-controller@8010, {
compatible = "arm,gic-v3";
#interrupt-cells = <3>;
+ #address-cells = <2>;
+ #size-cells = <2>;
+ ranges;
interrupt-controller;
reg = <0x8010 0x 0x0 0x01>, /* GICD */
<0x8010 0x8000 0x0 0x60>; /* GICR */
interrupts = <1 9 0xf04>;
+
+ its: gic-its@8010,0002 {
+ compatible = "arm,gic-v3-its";
+ msi-controller;
+ reg = <0x8010 0x2 0x0 0x20>;
+ };
};
uaa0: serial@87e0,2400 {
--
2.1.0
--
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 6/6] pci, thunder: Enable Cavium Thunder PCIe host controller
From: Robert Richter Enable Cavium Thunder PCIe host controller driver. IOV is enabled per default if drivers with IOV support are enabled. IOV can be disabled. Signed-off-by: Robert Richter --- arch/arm64/Kconfig | 11 +++ 1 file changed, 11 insertions(+) diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig index 9e1ef5a7..bd9724e5c8a1 100644 --- a/arch/arm64/Kconfig +++ b/arch/arm64/Kconfig @@ -172,6 +172,14 @@ config PCI config PCI_MSI def_bool PCI +config NO_PCI_IOV + def_bool PCI + depends on !PCI_THUNDER + +config PCI_IOV + def_bool PCI + depends on !NO_PCI_IOV + config PCI_DOMAINS def_bool PCI @@ -185,6 +193,9 @@ source "drivers/pci/Kconfig" source "drivers/pci/pcie/Kconfig" source "drivers/pci/hotplug/Kconfig" +config PCI_THUNDER + def_bool PCI + endmenu menu "Kernel Features" -- 2.1.0 -- 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 3/6] pci, thunder: Add PCIe host controller devicetree bindings
From: Sunil Goutham
This patch adds the PCIe host controller entry for Cavium Thunder SoCs
to the devicetree. There are 4 internal PCI controllers available.
Signed-off-by: Sunil Goutham
Signed-off-by: Robert Richter
---
arch/arm64/boot/dts/thunder-88xx.dtsi | 49 +++
1 file changed, 49 insertions(+)
diff --git a/arch/arm64/boot/dts/thunder-88xx.dtsi
b/arch/arm64/boot/dts/thunder-88xx.dtsi
index 9cb7cf94284a..0b433b0e7af4 100644
--- a/arch/arm64/boot/dts/thunder-88xx.dtsi
+++ b/arch/arm64/boot/dts/thunder-88xx.dtsi
@@ -407,4 +407,53 @@
clock-names = "apb_pclk";
};
};
+
+ pcie0@0x8480, {
+ compatible = "cavium,thunder-pcie";
+ device_type = "pci";
+ msi-parent = <>;
+ bus-range = <0 255>;
+ #size-cells = <2>;
+ #address-cells = <3>;
+ reg = <0x8480 0x 0 0x1000>; /* Configuration space
*/
+ ranges = <0x0300 0x8010 0x 0x8010 0x 0x70
0x>, /* mem ranges */
+ <0x0300 0x8300 0x 0x8300 0x 0x80
0x>,
+ <0x0300 0x87e0 0x 0x87e0 0x 0x01
0x>;
+};
+
+ pcie1@0x8490, {
+ compatible = "cavium,thunder-pcie";
+ device_type = "pci";
+ msi-parent = <>;
+ bus-range = <0 255>;
+ #size-cells = <2>;
+ #address-cells = <3>;
+ reg = <0x8490 0x 0 0x1000>; /* Configuration space
*/
+ ranges = <0x0300 0x8310 0x 0x8310 0x 0x00
0x1000>, /* mem ranges */
+ <0x0300 0x8100 0x 0x8100 0x 0x80
0x>;
+};
+
+ pcie2@0x84a0, {
+ compatible = "cavium,thunder-pcie";
+ device_type = "pci";
+ msi-parent = <>;
+ bus-range = <0 255>;
+ #size-cells = <2>;
+ #address-cells = <3>;
+ reg = <0x84a0 0x 0 0x1000>; /* Configuration space
*/
+ ranges = <0x0300 0x8320 0x 0x8320 0x 0x00
0x1000>, /* mem ranges */
+ <0x0300 0x8430 0x 0x8430 0x 0x01
0x>;
+};
+
+ pcie3@0x84b0, {
+ compatible = "cavium,thunder-pcie";
+ device_type = "pci";
+ msi-parent = <>;
+ bus-range = <0 255>;
+ #size-cells = <2>;
+ #address-cells = <3>;
+ reg = <0x84b0 0x 0 0x1000>; /* Configuration space
*/
+ ranges = <0x0300 0x8330 0x 0x8330 0x 0x00
0x1000>, /* mem ranges */
+ <0x0300 0x8180 0x 0x8180 0x 0x80
0x>;
+};
};
--
2.1.0
--
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 5/6] arm64, defconfig: Enable PCI
From: Robert Richter Enable the PCI subsystem in defconfig. There will be more and more systems with pci support, so default enable it. This also implicitly enables the MSI feature. Signed-off-by: Robert Richter --- arch/arm64/Kconfig | 4 1 file changed, 4 insertions(+) diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig index ca3f7e9afd4d..9e1ef5a7 100644 --- a/arch/arm64/Kconfig +++ b/arch/arm64/Kconfig @@ -163,11 +163,15 @@ config ARM_AMBA config PCI bool "PCI support" + default y help This feature enables support for PCIe bus system. If you say Y here, the kernel will include drivers and infrastructure code to support PCIe bus devices. +config PCI_MSI + def_bool PCI + config PCI_DOMAINS def_bool PCI -- 2.1.0 -- 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 v12 05/12] PCI: OF: Fix the conversion of IO ranges into IO resources.
On 23.09.14 19:16:19, Bjorn Helgaas wrote: > You probably saw the subsequent [pci:pci/host-generic 10/13] > drivers/of/of_pci.c:202:3: error: implicit declaration of function > 'of_pci_range_to_resource' error. > > I looked at that a bit, but gave up. Apparently drivers/of/of_pci.c > can be compiled with CONFIG_PCI=y but CONFIG_OF_ADDRESS not set.. This is due to the !SPARC dependency in drivers/of/Kconfig: config OF_ADDRESS def_bool y depends on !SPARC select OF_ADDRESS_PCI if PCI Error above occurs with ARCH=sparc. -Robert -- 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 v12 05/12] PCI: OF: Fix the conversion of IO ranges into IO resources.
On 23.09.14 19:16:19, Bjorn Helgaas wrote: You probably saw the subsequent [pci:pci/host-generic 10/13] drivers/of/of_pci.c:202:3: error: implicit declaration of function 'of_pci_range_to_resource' error. I looked at that a bit, but gave up. Apparently drivers/of/of_pci.c can be compiled with CONFIG_PCI=y but CONFIG_OF_ADDRESS not set.. This is due to the !SPARC dependency in drivers/of/Kconfig: config OF_ADDRESS def_bool y depends on !SPARC select OF_ADDRESS_PCI if PCI Error above occurs with ARCH=sparc. -Robert -- 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 5/6] arm64, defconfig: Enable PCI
From: Robert Richter rrich...@cavium.com Enable the PCI subsystem in defconfig. There will be more and more systems with pci support, so default enable it. This also implicitly enables the MSI feature. Signed-off-by: Robert Richter rrich...@cavium.com --- arch/arm64/Kconfig | 4 1 file changed, 4 insertions(+) diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig index ca3f7e9afd4d..9e1ef5a7 100644 --- a/arch/arm64/Kconfig +++ b/arch/arm64/Kconfig @@ -163,11 +163,15 @@ config ARM_AMBA config PCI bool PCI support + default y help This feature enables support for PCIe bus system. If you say Y here, the kernel will include drivers and infrastructure code to support PCIe bus devices. +config PCI_MSI + def_bool PCI + config PCI_DOMAINS def_bool PCI -- 2.1.0 -- 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 3/6] pci, thunder: Add PCIe host controller devicetree bindings
From: Sunil Goutham sgout...@cavium.com
This patch adds the PCIe host controller entry for Cavium Thunder SoCs
to the devicetree. There are 4 internal PCI controllers available.
Signed-off-by: Sunil Goutham sgout...@cavium.com
Signed-off-by: Robert Richter rrich...@cavium.com
---
arch/arm64/boot/dts/thunder-88xx.dtsi | 49 +++
1 file changed, 49 insertions(+)
diff --git a/arch/arm64/boot/dts/thunder-88xx.dtsi
b/arch/arm64/boot/dts/thunder-88xx.dtsi
index 9cb7cf94284a..0b433b0e7af4 100644
--- a/arch/arm64/boot/dts/thunder-88xx.dtsi
+++ b/arch/arm64/boot/dts/thunder-88xx.dtsi
@@ -407,4 +407,53 @@
clock-names = apb_pclk;
};
};
+
+ pcie0@0x8480, {
+ compatible = cavium,thunder-pcie;
+ device_type = pci;
+ msi-parent = its;
+ bus-range = 0 255;
+ #size-cells = 2;
+ #address-cells = 3;
+ reg = 0x8480 0x 0 0x1000; /* Configuration space
*/
+ ranges = 0x0300 0x8010 0x 0x8010 0x 0x70
0x, /* mem ranges */
+ 0x0300 0x8300 0x 0x8300 0x 0x80
0x,
+ 0x0300 0x87e0 0x 0x87e0 0x 0x01
0x;
+};
+
+ pcie1@0x8490, {
+ compatible = cavium,thunder-pcie;
+ device_type = pci;
+ msi-parent = its;
+ bus-range = 0 255;
+ #size-cells = 2;
+ #address-cells = 3;
+ reg = 0x8490 0x 0 0x1000; /* Configuration space
*/
+ ranges = 0x0300 0x8310 0x 0x8310 0x 0x00
0x1000, /* mem ranges */
+ 0x0300 0x8100 0x 0x8100 0x 0x80
0x;
+};
+
+ pcie2@0x84a0, {
+ compatible = cavium,thunder-pcie;
+ device_type = pci;
+ msi-parent = its;
+ bus-range = 0 255;
+ #size-cells = 2;
+ #address-cells = 3;
+ reg = 0x84a0 0x 0 0x1000; /* Configuration space
*/
+ ranges = 0x0300 0x8320 0x 0x8320 0x 0x00
0x1000, /* mem ranges */
+ 0x0300 0x8430 0x 0x8430 0x 0x01
0x;
+};
+
+ pcie3@0x84b0, {
+ compatible = cavium,thunder-pcie;
+ device_type = pci;
+ msi-parent = its;
+ bus-range = 0 255;
+ #size-cells = 2;
+ #address-cells = 3;
+ reg = 0x84b0 0x 0 0x1000; /* Configuration space
*/
+ ranges = 0x0300 0x8330 0x 0x8330 0x 0x00
0x1000, /* mem ranges */
+ 0x0300 0x8180 0x 0x8180 0x 0x80
0x;
+};
};
--
2.1.0
--
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 2/6] GICv3: Add ITS entry to THUNDER dts
From: Tirumalesh Chalamarla tchalama...@cavium.com
The PCIe host controller uses MSIs provided by GICv3 ITS. Enable it on
Thunder SoCs by adding an entry to DT.
Signed-off-by: Tirumalesh Chalamarla tchalama...@cavium.com
Signed-off-by: Robert Richter rrich...@cavium.com
---
arch/arm64/boot/dts/thunder-88xx.dtsi | 9 +
1 file changed, 9 insertions(+)
diff --git a/arch/arm64/boot/dts/thunder-88xx.dtsi
b/arch/arm64/boot/dts/thunder-88xx.dtsi
index d8c0bdc51882..9cb7cf94284a 100644
--- a/arch/arm64/boot/dts/thunder-88xx.dtsi
+++ b/arch/arm64/boot/dts/thunder-88xx.dtsi
@@ -376,10 +376,19 @@
gic0: interrupt-controller@8010, {
compatible = arm,gic-v3;
#interrupt-cells = 3;
+ #address-cells = 2;
+ #size-cells = 2;
+ ranges;
interrupt-controller;
reg = 0x8010 0x 0x0 0x01, /* GICD */
0x8010 0x8000 0x0 0x60; /* GICR */
interrupts = 1 9 0xf04;
+
+ its: gic-its@8010,0002 {
+ compatible = arm,gic-v3-its;
+ msi-controller;
+ reg = 0x8010 0x2 0x0 0x20;
+ };
};
uaa0: serial@87e0,2400 {
--
2.1.0
--
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 6/6] pci, thunder: Enable Cavium Thunder PCIe host controller
From: Robert Richter rrich...@cavium.com Enable Cavium Thunder PCIe host controller driver. IOV is enabled per default if drivers with IOV support are enabled. IOV can be disabled. Signed-off-by: Robert Richter rrich...@cavium.com --- arch/arm64/Kconfig | 11 +++ 1 file changed, 11 insertions(+) diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig index 9e1ef5a7..bd9724e5c8a1 100644 --- a/arch/arm64/Kconfig +++ b/arch/arm64/Kconfig @@ -172,6 +172,14 @@ config PCI config PCI_MSI def_bool PCI +config NO_PCI_IOV + def_bool PCI + depends on !PCI_THUNDER + +config PCI_IOV + def_bool PCI + depends on !NO_PCI_IOV + config PCI_DOMAINS def_bool PCI @@ -185,6 +193,9 @@ source drivers/pci/Kconfig source drivers/pci/pcie/Kconfig source drivers/pci/hotplug/Kconfig +config PCI_THUNDER + def_bool PCI + endmenu menu Kernel Features -- 2.1.0 -- 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 4/6] pci, thunder: Document PCIe host controller devicetree bindings
From: Sunil Goutham sgout...@cavium.com
This patch adds documentation for the devicetree bindings used by the
Thunder PCI host controller.
Signed-off-by: Sunil Goutham sgout...@cavium.com
Signed-off-by: Robert Richter rrich...@cavium.com
---
.../devicetree/bindings/pci/cavium,thunder-pci.txt | 32 ++
1 file changed, 32 insertions(+)
create mode 100644 Documentation/devicetree/bindings/pci/cavium,thunder-pci.txt
diff --git a/Documentation/devicetree/bindings/pci/cavium,thunder-pci.txt
b/Documentation/devicetree/bindings/pci/cavium,thunder-pci.txt
new file mode 100644
index ..c8ff3d2e8630
--- /dev/null
+++ b/Documentation/devicetree/bindings/pci/cavium,thunder-pci.txt
@@ -0,0 +1,32 @@
+* Cavium Thunder PCIe interface
+
+Required properties:
+- compatible: should contain cavium,thunder-pcie to identify the core.
+- device_type: set to pci
+- #address-cells: set to 3
+- #size-cells: set to 2
+- #stream-id-cells: set to 1
+- bus-range: PCI bus numbers covered
+- reg: base address and length of the pcie configuration space.
+- ranges: ranges for the PCI memory regions.
+- msi-parent: Link to the hardware entity that serves as the Message
+ Signaled Interrupt controller for this PCI controller.
+
+Example:
+
+SoC specific DT Entry:
+
+ pcie0: pcie0@0x8480 {
+ compatible = cavium,thunder-pcie;
+ device_type = pci;
+ msi-parent = its;
+ bus-range = 0 255;
+ #size-cells = 2;
+ #address-cells = 3;
+ #stream-id-cells = 1;
+ reg = 0x8480 0x 0 0x1000; /* Configuration space
*/
+ ranges = 0x0300 0x8010 0x 0x8010 0x 0x70
0x, /* mem */
+ 0x0300 0x8300 0x 0x8300 0x 0x80
0x,
+ 0x0300 0x87e0 0x 0x87e0 0x 0x01
0x;
+ };
+
--
2.1.0
--
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 1/6] pci, thunder: Add support for Thunder PCIe host controller
From: Sunil Goutham sgout...@cavium.com
This patch adds support for PCI host controller of Cavium Thunder
SoCs.
Signed-off-by: Sunil Goutham sgout...@cavium.com
Signed-off-by: Robert Richter rrich...@cavium.com
---
drivers/pci/host/Kconfig| 8 ++
drivers/pci/host/Makefile | 1 +
drivers/pci/host/pcie-thunder.c | 246
include/linux/pci_ids.h | 2 +
4 files changed, 257 insertions(+)
create mode 100644 drivers/pci/host/pcie-thunder.c
diff --git a/drivers/pci/host/Kconfig b/drivers/pci/host/Kconfig
index 90f5ccacce4b..269c3ff786bc 100644
--- a/drivers/pci/host/Kconfig
+++ b/drivers/pci/host/Kconfig
@@ -63,4 +63,12 @@ config PCIE_SPEAR13XX
help
Say Y here if you want PCIe support on SPEAr13XX SoCs.
+config PCI_THUNDER
+ bool Thunder PCIe host controller
+ depends on ARM64 || COMPILE_TEST
+ depends on OF_PCI
+ depends on PCI_MSI
+ help
+ Say Y here if you want internal PCI support on Thunder SoC.
+
endmenu
diff --git a/drivers/pci/host/Makefile b/drivers/pci/host/Makefile
index d0e88f114ff9..fd8041da1719 100644
--- a/drivers/pci/host/Makefile
+++ b/drivers/pci/host/Makefile
@@ -8,3 +8,4 @@ obj-$(CONFIG_PCI_RCAR_GEN2) += pci-rcar-gen2.o
obj-$(CONFIG_PCI_RCAR_GEN2_PCIE) += pcie-rcar.o
obj-$(CONFIG_PCI_HOST_GENERIC) += pci-host-generic.o
obj-$(CONFIG_PCIE_SPEAR13XX) += pcie-spear13xx.o
+obj-$(CONFIG_PCI_THUNDER) += pcie-thunder.o
diff --git a/drivers/pci/host/pcie-thunder.c b/drivers/pci/host/pcie-thunder.c
new file mode 100644
index ..947fad3b1980
--- /dev/null
+++ b/drivers/pci/host/pcie-thunder.c
@@ -0,0 +1,246 @@
+/*
+ * PCIe host controller driver for Cavium Thunder SOC
+ *
+ * Copyright (C) 2014, Cavium Inc.
+ *
+ * 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.
+ */
+#include linux/kernel.h
+#include linux/module.h
+#include linux/interrupt.h
+#include linux/of_irq.h
+#include linux/of_pci.h
+#include linux/pci.h
+#include linux/platform_device.h
+#include linux/msi.h
+
+#define PCI_DEVICE_ID_THUNDER_BRIDGE 0xa002
+
+#define THUNDER_PCIE_BUS_SHIFT 20
+#define THUNDER_PCIE_DEV_SHIFT 15
+#define THUNDER_PCIE_FUNC_SHIFT12
+
+struct thunder_pcie {
+ struct device_node *node;
+ struct device *dev;
+ void __iomem*cfg_base;
+ struct msi_chip *msi;
+};
+
+/*
+ * This bridge is just for the sake of supporting ARI for
+ * downstream devices. No resources are attached to it.
+ * Copy upstream root bus resources to bridge which aide in
+ * resource claiming for downstream devices
+ */
+static void pci_bridge_resource_fixup(struct pci_dev *dev)
+{
+ struct pci_bus *bus;
+ int resno;
+
+ bus = dev-subordinate;
+ for (resno = 0; resno PCI_BRIDGE_RESOURCE_NUM; resno++) {
+ bus-resource[resno] = pci_bus_resource_n(bus-parent,
+ PCI_BRIDGE_RESOURCE_NUM + resno);
+ }
+
+ for (resno = PCI_BRIDGE_RESOURCES;
+ resno = PCI_BRIDGE_RESOURCE_END; resno++) {
+ dev-resource[resno].start = dev-resource[resno].end = 0;
+ dev-resource[resno].flags = 0;
+ }
+}
+DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_CAVIUM, PCI_DEVICE_ID_THUNDER_BRIDGE,
+ pci_bridge_resource_fixup);
+
+/*
+ * All PCIe devices in Thunder have fixed resources, shouldn't be reassigned.
+ * Also claim the device's valid resources to set 'res-parent' hierarchy.
+ */
+static void pci_dev_resource_fixup(struct pci_dev *dev)
+{
+ struct resource *res;
+ int resno;
+
+ for (resno = 0; resno PCI_NUM_RESOURCES; resno++)
+ dev-resource[resno].flags |= IORESOURCE_PCI_FIXED;
+
+ for (resno = 0; resno PCI_BRIDGE_RESOURCES; resno++) {
+ res = dev-resource[resno];
+ if (res-parent || !(res-flags IORESOURCE_MEM))
+ continue;
+ pci_claim_resource(dev, resno);
+ }
+}
+DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_CAVIUM, PCI_ANY_ID,
+ pci_dev_resource_fixup);
+
+static void __iomem *thunder_pcie_cfg_base(struct thunder_pcie *pcie,
+unsigned int bus, unsigned int devfn)
+{
+ return pcie-cfg_base + ((bus THUNDER_PCIE_BUS_SHIFT)
+ | (PCI_SLOT(devfn) THUNDER_PCIE_DEV_SHIFT)
+ | (PCI_FUNC(devfn) THUNDER_PCIE_FUNC_SHIFT));
+}
+
+static int thunder_pcie_read_config(struct pci_bus *bus, unsigned int devfn,
+ int reg, int size, u32 *val)
+{
+ struct thunder_pcie *pcie = bus-sysdata;
+ void __iomem *addr;
+ unsigned int busnr = bus-number;
+
+ if (busnr 255 || devfn 255
[PATCH 0/6] pci, thunder: Add Cavium Thunder PCIe host controller
From: Robert Richter rrich...@cavium.com This patches add support for the Cavium Thunder PCIe host controller. Patches base on following branches: git://git.kernel.org/pub/scm/linux/kernel/git/helgaas/pci pci/liviu-generic-v11 git://linux-arm.org/linux-ld for-upstream/pci_arm64_v11 Additionally a fix is required for liviu-generic-v11 to allow the generation of mem-mapped pci ranges: https://lkml.org/lkml/2014/9/22/150 It also requires Marc's gicv3-its support to work. The first patch introduces the host controller driver. Patch 2 to 4 are DT changes including documentation. Patch 5 and 6 enable PCI support for arm64 defconfig. Robert Richter (2): arm64, defconfig: Enable PCI pci, thunder: Enable Cavium Thunder PCIe host controller Sunil Goutham (3): pci, thunder: Add support for Thunder PCIe host controller pci, thunder: Add PCIe host controller devicetree bindings pci, thunder: Document PCIe host controller devicetree bindings Tirumalesh Chalamarla (1): GICv3: Add ITS entry to THUNDER dts .../devicetree/bindings/pci/cavium,thunder-pci.txt | 32 +++ arch/arm64/Kconfig | 15 ++ arch/arm64/boot/dts/thunder-88xx.dtsi | 58 + drivers/pci/host/Kconfig | 8 + drivers/pci/host/Makefile | 1 + drivers/pci/host/pcie-thunder.c| 246 + include/linux/pci_ids.h| 2 + 7 files changed, 362 insertions(+) create mode 100644 Documentation/devicetree/bindings/pci/cavium,thunder-pci.txt create mode 100644 drivers/pci/host/pcie-thunder.c -- 2.1.0 -- 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/
