* [PATCH v4 01/12] PCI: pci-bridge-emul: Re-arrange register tests
2022-02-22 15:50 [PATCH v4 00/12] PCI: mvebu: subsystem ids, AER and INTx Pali Rohár
@ 2022-02-22 15:50 ` Pali Rohár
2022-02-22 15:50 ` [PATCH v4 02/12] PCI: pci-bridge-emul: Add support for PCIe extended capabilities Pali Rohár
` (11 subsequent siblings)
12 siblings, 0 replies; 26+ messages in thread
From: Pali Rohár @ 2022-02-22 15:50 UTC (permalink / raw)
To: Lorenzo Pieralisi, Bjorn Helgaas, Rob Herring, Thomas Petazzoni,
Krzysztof Wilczyński, Marek Behún, Russell King
Cc: linux-pci, linux-kernel, linux-arm-kernel
From: Russell King <rmk+kernel@armlinux.org.uk>
Re-arrange the tests for which sets of registers are being accessed so that
it is easier to add further regions later. No functional change.
Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk>
[pali: Fix reading old value in pci_bridge_emul_conf_write]
Signed-off-by: Pali Rohár <pali@kernel.org>
Signed-off-by: Marek Behún <kabel@kernel.org>
---
drivers/pci/pci-bridge-emul.c | 61 ++++++++++++++++++-----------------
1 file changed, 31 insertions(+), 30 deletions(-)
diff --git a/drivers/pci/pci-bridge-emul.c b/drivers/pci/pci-bridge-emul.c
index a16f9e30099e..a956408834d6 100644
--- a/drivers/pci/pci-bridge-emul.c
+++ b/drivers/pci/pci-bridge-emul.c
@@ -422,25 +422,25 @@ int pci_bridge_emul_conf_read(struct pci_bridge_emul *bridge, int where,
__le32 *cfgspace;
const struct pci_bridge_reg_behavior *behavior;
- if (bridge->has_pcie && reg >= PCI_CAP_PCIE_END) {
- *value = 0;
- return PCIBIOS_SUCCESSFUL;
- }
-
- if (!bridge->has_pcie && reg >= PCI_BRIDGE_CONF_END) {
+ if (reg < PCI_BRIDGE_CONF_END) {
+ /* Emulated PCI space */
+ read_op = bridge->ops->read_base;
+ cfgspace = (__le32 *) &bridge->conf;
+ behavior = bridge->pci_regs_behavior;
+ } else if (!bridge->has_pcie) {
+ /* PCIe space is not implemented, and no PCI capabilities */
*value = 0;
return PCIBIOS_SUCCESSFUL;
- }
-
- if (bridge->has_pcie && reg >= PCI_CAP_PCIE_START) {
+ } else if (reg < PCI_CAP_PCIE_END) {
+ /* Our emulated PCIe capability */
reg -= PCI_CAP_PCIE_START;
read_op = bridge->ops->read_pcie;
cfgspace = (__le32 *) &bridge->pcie_conf;
behavior = bridge->pcie_cap_regs_behavior;
} else {
- read_op = bridge->ops->read_base;
- cfgspace = (__le32 *) &bridge->conf;
- behavior = bridge->pci_regs_behavior;
+ /* Beyond our PCIe space */
+ *value = 0;
+ return PCIBIOS_SUCCESSFUL;
}
if (read_op)
@@ -484,11 +484,27 @@ int pci_bridge_emul_conf_write(struct pci_bridge_emul *bridge, int where,
__le32 *cfgspace;
const struct pci_bridge_reg_behavior *behavior;
- if (bridge->has_pcie && reg >= PCI_CAP_PCIE_END)
- return PCIBIOS_SUCCESSFUL;
+ ret = pci_bridge_emul_conf_read(bridge, reg, 4, &old);
+ if (ret != PCIBIOS_SUCCESSFUL)
+ return ret;
- if (!bridge->has_pcie && reg >= PCI_BRIDGE_CONF_END)
+ if (reg < PCI_BRIDGE_CONF_END) {
+ /* Emulated PCI space */
+ write_op = bridge->ops->write_base;
+ cfgspace = (__le32 *) &bridge->conf;
+ behavior = bridge->pci_regs_behavior;
+ } else if (!bridge->has_pcie) {
+ /* PCIe space is not implemented, and no PCI capabilities */
return PCIBIOS_SUCCESSFUL;
+ } else if (reg < PCI_CAP_PCIE_END) {
+ /* Our emulated PCIe capability */
+ reg -= PCI_CAP_PCIE_START;
+ write_op = bridge->ops->write_pcie;
+ cfgspace = (__le32 *) &bridge->pcie_conf;
+ behavior = bridge->pcie_cap_regs_behavior;
+ } else {
+ return PCIBIOS_SUCCESSFUL;
+ }
shift = (where & 0x3) * 8;
@@ -501,21 +517,6 @@ int pci_bridge_emul_conf_write(struct pci_bridge_emul *bridge, int where,
else
return PCIBIOS_BAD_REGISTER_NUMBER;
- ret = pci_bridge_emul_conf_read(bridge, reg, 4, &old);
- if (ret != PCIBIOS_SUCCESSFUL)
- return ret;
-
- if (bridge->has_pcie && reg >= PCI_CAP_PCIE_START) {
- reg -= PCI_CAP_PCIE_START;
- write_op = bridge->ops->write_pcie;
- cfgspace = (__le32 *) &bridge->pcie_conf;
- behavior = bridge->pcie_cap_regs_behavior;
- } else {
- write_op = bridge->ops->write_base;
- cfgspace = (__le32 *) &bridge->conf;
- behavior = bridge->pci_regs_behavior;
- }
-
/* Keep all bits, except the RW bits */
new = old & (~mask | ~behavior[reg / 4].rw);
--
2.20.1
^ permalink raw reply related [flat|nested] 26+ messages in thread* [PATCH v4 02/12] PCI: pci-bridge-emul: Add support for PCIe extended capabilities
2022-02-22 15:50 [PATCH v4 00/12] PCI: mvebu: subsystem ids, AER and INTx Pali Rohár
2022-02-22 15:50 ` [PATCH v4 01/12] PCI: pci-bridge-emul: Re-arrange register tests Pali Rohár
@ 2022-02-22 15:50 ` Pali Rohár
2022-02-22 15:50 ` [PATCH v4 03/12] PCI: pci-bridge-emul: Add support for PCI Bridge Subsystem Vendor ID capability Pali Rohár
` (10 subsequent siblings)
12 siblings, 0 replies; 26+ messages in thread
From: Pali Rohár @ 2022-02-22 15:50 UTC (permalink / raw)
To: Lorenzo Pieralisi, Bjorn Helgaas, Rob Herring, Thomas Petazzoni,
Krzysztof Wilczyński, Marek Behún, Russell King
Cc: linux-pci, linux-kernel, linux-arm-kernel
From: Russell King <rmk+kernel@armlinux.org.uk>
Add support for PCIe extended capabilities, which we just redirect to the
emulating driver.
Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk>
[pali: Fix writing new value with W1C bits]
Signed-off-by: Pali Rohár <pali@kernel.org>
Signed-off-by: Marek Behún <kabel@kernel.org>
---
drivers/pci/pci-bridge-emul.c | 77 +++++++++++++++++++++++------------
drivers/pci/pci-bridge-emul.h | 15 +++++++
2 files changed, 67 insertions(+), 25 deletions(-)
diff --git a/drivers/pci/pci-bridge-emul.c b/drivers/pci/pci-bridge-emul.c
index a956408834d6..c4b9837006ff 100644
--- a/drivers/pci/pci-bridge-emul.c
+++ b/drivers/pci/pci-bridge-emul.c
@@ -437,10 +437,16 @@ int pci_bridge_emul_conf_read(struct pci_bridge_emul *bridge, int where,
read_op = bridge->ops->read_pcie;
cfgspace = (__le32 *) &bridge->pcie_conf;
behavior = bridge->pcie_cap_regs_behavior;
- } else {
- /* Beyond our PCIe space */
+ } else if (reg < PCI_CFG_SPACE_SIZE) {
+ /* Rest of PCI space not implemented */
*value = 0;
return PCIBIOS_SUCCESSFUL;
+ } else {
+ /* PCIe extended capability space */
+ reg -= PCI_CFG_SPACE_SIZE;
+ read_op = bridge->ops->read_ext;
+ cfgspace = NULL;
+ behavior = NULL;
}
if (read_op)
@@ -448,15 +454,20 @@ int pci_bridge_emul_conf_read(struct pci_bridge_emul *bridge, int where,
else
ret = PCI_BRIDGE_EMUL_NOT_HANDLED;
- if (ret == PCI_BRIDGE_EMUL_NOT_HANDLED)
- *value = le32_to_cpu(cfgspace[reg / 4]);
+ if (ret == PCI_BRIDGE_EMUL_NOT_HANDLED) {
+ if (cfgspace)
+ *value = le32_to_cpu(cfgspace[reg / 4]);
+ else
+ *value = 0;
+ }
/*
* Make sure we never return any reserved bit with a value
* different from 0.
*/
- *value &= behavior[reg / 4].ro | behavior[reg / 4].rw |
- behavior[reg / 4].w1c;
+ if (behavior)
+ *value &= behavior[reg / 4].ro | behavior[reg / 4].rw |
+ behavior[reg / 4].w1c;
if (size == 1)
*value = (*value >> (8 * (where & 3))) & 0xff;
@@ -502,8 +513,15 @@ int pci_bridge_emul_conf_write(struct pci_bridge_emul *bridge, int where,
write_op = bridge->ops->write_pcie;
cfgspace = (__le32 *) &bridge->pcie_conf;
behavior = bridge->pcie_cap_regs_behavior;
- } else {
+ } else if (reg < PCI_CFG_SPACE_SIZE) {
+ /* Rest of PCI space not implemented */
return PCIBIOS_SUCCESSFUL;
+ } else {
+ /* PCIe extended capability space */
+ reg -= PCI_CFG_SPACE_SIZE;
+ write_op = bridge->ops->write_ext;
+ cfgspace = NULL;
+ behavior = NULL;
}
shift = (where & 0x3) * 8;
@@ -517,29 +535,38 @@ int pci_bridge_emul_conf_write(struct pci_bridge_emul *bridge, int where,
else
return PCIBIOS_BAD_REGISTER_NUMBER;
- /* Keep all bits, except the RW bits */
- new = old & (~mask | ~behavior[reg / 4].rw);
+ if (behavior) {
+ /* Keep all bits, except the RW bits */
+ new = old & (~mask | ~behavior[reg / 4].rw);
- /* Update the value of the RW bits */
- new |= (value << shift) & (behavior[reg / 4].rw & mask);
+ /* Update the value of the RW bits */
+ new |= (value << shift) & (behavior[reg / 4].rw & mask);
- /* Clear the W1C bits */
- new &= ~((value << shift) & (behavior[reg / 4].w1c & mask));
+ /* Clear the W1C bits */
+ new &= ~((value << shift) & (behavior[reg / 4].w1c & mask));
+ } else {
+ new = old & ~mask;
+ new |= (value << shift) & mask;
+ }
- /* Save the new value with the cleared W1C bits into the cfgspace */
- cfgspace[reg / 4] = cpu_to_le32(new);
+ if (cfgspace) {
+ /* Save the new value with the cleared W1C bits into the cfgspace */
+ cfgspace[reg / 4] = cpu_to_le32(new);
+ }
- /*
- * Clear the W1C bits not specified by the write mask, so that the
- * write_op() does not clear them.
- */
- new &= ~(behavior[reg / 4].w1c & ~mask);
+ if (behavior) {
+ /*
+ * Clear the W1C bits not specified by the write mask, so that the
+ * write_op() does not clear them.
+ */
+ new &= ~(behavior[reg / 4].w1c & ~mask);
- /*
- * Set the W1C bits specified by the write mask, so that write_op()
- * knows about that they are to be cleared.
- */
- new |= (value << shift) & (behavior[reg / 4].w1c & mask);
+ /*
+ * Set the W1C bits specified by the write mask, so that write_op()
+ * knows about that they are to be cleared.
+ */
+ new |= (value << shift) & (behavior[reg / 4].w1c & mask);
+ }
if (write_op)
write_op(bridge, reg, old, new, mask);
diff --git a/drivers/pci/pci-bridge-emul.h b/drivers/pci/pci-bridge-emul.h
index 4953274cac18..6b5f75b2ad02 100644
--- a/drivers/pci/pci-bridge-emul.h
+++ b/drivers/pci/pci-bridge-emul.h
@@ -90,6 +90,14 @@ struct pci_bridge_emul_ops {
*/
pci_bridge_emul_read_status_t (*read_pcie)(struct pci_bridge_emul *bridge,
int reg, u32 *value);
+
+ /*
+ * Same as ->read_base(), except it is for reading from the
+ * PCIe extended capability configuration space.
+ */
+ pci_bridge_emul_read_status_t (*read_ext)(struct pci_bridge_emul *bridge,
+ int reg, u32 *value);
+
/*
* Called when writing to the regular PCI bridge configuration
* space. old is the current value, new is the new value being
@@ -105,6 +113,13 @@ struct pci_bridge_emul_ops {
*/
void (*write_pcie)(struct pci_bridge_emul *bridge, int reg,
u32 old, u32 new, u32 mask);
+
+ /*
+ * Same as ->write_base(), except it is for writing from the
+ * PCIe extended capability configuration space.
+ */
+ void (*write_ext)(struct pci_bridge_emul *bridge, int reg,
+ u32 old, u32 new, u32 mask);
};
struct pci_bridge_reg_behavior;
--
2.20.1
^ permalink raw reply related [flat|nested] 26+ messages in thread* [PATCH v4 03/12] PCI: pci-bridge-emul: Add support for PCI Bridge Subsystem Vendor ID capability
2022-02-22 15:50 [PATCH v4 00/12] PCI: mvebu: subsystem ids, AER and INTx Pali Rohár
2022-02-22 15:50 ` [PATCH v4 01/12] PCI: pci-bridge-emul: Re-arrange register tests Pali Rohár
2022-02-22 15:50 ` [PATCH v4 02/12] PCI: pci-bridge-emul: Add support for PCIe extended capabilities Pali Rohár
@ 2022-02-22 15:50 ` Pali Rohár
2022-02-22 15:50 ` [PATCH v4 04/12] dt-bindings: PCI: mvebu: Add num-lanes property Pali Rohár
` (9 subsequent siblings)
12 siblings, 0 replies; 26+ messages in thread
From: Pali Rohár @ 2022-02-22 15:50 UTC (permalink / raw)
To: Lorenzo Pieralisi, Bjorn Helgaas, Rob Herring, Thomas Petazzoni,
Krzysztof Wilczyński, Marek Behún, Russell King
Cc: linux-pci, linux-kernel, linux-arm-kernel
This is read-only capability in PCI config space. Put it between base PCI
capability and base PCI Express capability.
Driver just have to specify subsystem_vendor_id and subsystem_id fields in
emulated bridge structure and pci-bridge-emul takes care of correctly
compose PCI Bridge Subsystem Vendor ID capability.
Signed-off-by: Pali Rohár <pali@kernel.org>
---
drivers/pci/pci-bridge-emul.c | 69 +++++++++++++++++++++++++----------
drivers/pci/pci-bridge-emul.h | 2 +
2 files changed, 51 insertions(+), 20 deletions(-)
diff --git a/drivers/pci/pci-bridge-emul.c b/drivers/pci/pci-bridge-emul.c
index c4b9837006ff..a5b662cc89d0 100644
--- a/drivers/pci/pci-bridge-emul.c
+++ b/drivers/pci/pci-bridge-emul.c
@@ -21,8 +21,11 @@
#include "pci-bridge-emul.h"
#define PCI_BRIDGE_CONF_END PCI_STD_HEADER_SIZEOF
+#define PCI_CAP_SSID_SIZEOF (PCI_SSVID_DEVICE_ID + 2)
+#define PCI_CAP_SSID_START PCI_BRIDGE_CONF_END
+#define PCI_CAP_SSID_END (PCI_CAP_SSID_START + PCI_CAP_SSID_SIZEOF)
#define PCI_CAP_PCIE_SIZEOF (PCI_EXP_SLTSTA2 + 2)
-#define PCI_CAP_PCIE_START PCI_BRIDGE_CONF_END
+#define PCI_CAP_PCIE_START PCI_CAP_SSID_END
#define PCI_CAP_PCIE_END (PCI_CAP_PCIE_START + PCI_CAP_PCIE_SIZEOF)
/**
@@ -315,6 +318,25 @@ struct pci_bridge_reg_behavior pcie_cap_regs_behavior[PCI_CAP_PCIE_SIZEOF / 4] =
},
};
+static pci_bridge_emul_read_status_t
+pci_bridge_emul_read_ssid(struct pci_bridge_emul *bridge, int reg, u32 *value)
+{
+ switch (reg) {
+ case PCI_CAP_LIST_ID:
+ *value = PCI_CAP_ID_SSVID |
+ (bridge->has_pcie ? (PCI_CAP_PCIE_START << 8) : 0);
+ return PCI_BRIDGE_EMUL_HANDLED;
+
+ case PCI_SSVID_VENDOR_ID:
+ *value = bridge->subsystem_vendor_id |
+ (bridge->subsystem_id << 16);
+ return PCI_BRIDGE_EMUL_HANDLED;
+
+ default:
+ return PCI_BRIDGE_EMUL_NOT_HANDLED;
+ }
+}
+
/*
* Initialize a pci_bridge_emul structure to represent a fake PCI
* bridge configuration space. The caller needs to have initialized
@@ -341,9 +363,17 @@ int pci_bridge_emul_init(struct pci_bridge_emul *bridge,
if (!bridge->pci_regs_behavior)
return -ENOMEM;
- if (bridge->has_pcie) {
+ if (bridge->subsystem_vendor_id)
+ bridge->conf.capabilities_pointer = PCI_CAP_SSID_START;
+ else if (bridge->has_pcie)
bridge->conf.capabilities_pointer = PCI_CAP_PCIE_START;
+ else
+ bridge->conf.capabilities_pointer = 0;
+
+ if (bridge->conf.capabilities_pointer)
bridge->conf.status |= cpu_to_le16(PCI_STATUS_CAP_LIST);
+
+ if (bridge->has_pcie) {
bridge->pcie_conf.cap_id = PCI_CAP_ID_EXP;
bridge->pcie_conf.cap |= cpu_to_le16(PCI_EXP_TYPE_ROOT_PORT << 4);
bridge->pcie_cap_regs_behavior =
@@ -427,26 +457,28 @@ int pci_bridge_emul_conf_read(struct pci_bridge_emul *bridge, int where,
read_op = bridge->ops->read_base;
cfgspace = (__le32 *) &bridge->conf;
behavior = bridge->pci_regs_behavior;
- } else if (!bridge->has_pcie) {
- /* PCIe space is not implemented, and no PCI capabilities */
- *value = 0;
- return PCIBIOS_SUCCESSFUL;
- } else if (reg < PCI_CAP_PCIE_END) {
+ } else if (reg >= PCI_CAP_SSID_START && reg < PCI_CAP_SSID_END && bridge->subsystem_vendor_id) {
+ /* Emulated PCI Bridge Subsystem Vendor ID capability */
+ reg -= PCI_CAP_SSID_START;
+ read_op = pci_bridge_emul_read_ssid;
+ cfgspace = NULL;
+ behavior = NULL;
+ } else if (reg >= PCI_CAP_PCIE_START && reg < PCI_CAP_PCIE_END && bridge->has_pcie) {
/* Our emulated PCIe capability */
reg -= PCI_CAP_PCIE_START;
read_op = bridge->ops->read_pcie;
cfgspace = (__le32 *) &bridge->pcie_conf;
behavior = bridge->pcie_cap_regs_behavior;
- } else if (reg < PCI_CFG_SPACE_SIZE) {
- /* Rest of PCI space not implemented */
- *value = 0;
- return PCIBIOS_SUCCESSFUL;
- } else {
+ } else if (reg >= PCI_CFG_SPACE_SIZE && bridge->has_pcie) {
/* PCIe extended capability space */
reg -= PCI_CFG_SPACE_SIZE;
read_op = bridge->ops->read_ext;
cfgspace = NULL;
behavior = NULL;
+ } else {
+ /* Not implemented */
+ *value = 0;
+ return PCIBIOS_SUCCESSFUL;
}
if (read_op)
@@ -504,24 +536,21 @@ int pci_bridge_emul_conf_write(struct pci_bridge_emul *bridge, int where,
write_op = bridge->ops->write_base;
cfgspace = (__le32 *) &bridge->conf;
behavior = bridge->pci_regs_behavior;
- } else if (!bridge->has_pcie) {
- /* PCIe space is not implemented, and no PCI capabilities */
- return PCIBIOS_SUCCESSFUL;
- } else if (reg < PCI_CAP_PCIE_END) {
+ } else if (reg >= PCI_CAP_PCIE_START && reg < PCI_CAP_PCIE_END && bridge->has_pcie) {
/* Our emulated PCIe capability */
reg -= PCI_CAP_PCIE_START;
write_op = bridge->ops->write_pcie;
cfgspace = (__le32 *) &bridge->pcie_conf;
behavior = bridge->pcie_cap_regs_behavior;
- } else if (reg < PCI_CFG_SPACE_SIZE) {
- /* Rest of PCI space not implemented */
- return PCIBIOS_SUCCESSFUL;
- } else {
+ } else if (reg >= PCI_CFG_SPACE_SIZE && bridge->has_pcie) {
/* PCIe extended capability space */
reg -= PCI_CFG_SPACE_SIZE;
write_op = bridge->ops->write_ext;
cfgspace = NULL;
behavior = NULL;
+ } else {
+ /* Not implemented */
+ return PCIBIOS_SUCCESSFUL;
}
shift = (where & 0x3) * 8;
diff --git a/drivers/pci/pci-bridge-emul.h b/drivers/pci/pci-bridge-emul.h
index 6b5f75b2ad02..71392b67471d 100644
--- a/drivers/pci/pci-bridge-emul.h
+++ b/drivers/pci/pci-bridge-emul.h
@@ -132,6 +132,8 @@ struct pci_bridge_emul {
struct pci_bridge_reg_behavior *pcie_cap_regs_behavior;
void *data;
bool has_pcie;
+ u16 subsystem_vendor_id;
+ u16 subsystem_id;
};
enum {
--
2.20.1
^ permalink raw reply related [flat|nested] 26+ messages in thread* [PATCH v4 04/12] dt-bindings: PCI: mvebu: Add num-lanes property
2022-02-22 15:50 [PATCH v4 00/12] PCI: mvebu: subsystem ids, AER and INTx Pali Rohár
` (2 preceding siblings ...)
2022-02-22 15:50 ` [PATCH v4 03/12] PCI: pci-bridge-emul: Add support for PCI Bridge Subsystem Vendor ID capability Pali Rohár
@ 2022-02-22 15:50 ` Pali Rohár
2022-02-25 0:02 ` Bjorn Helgaas
2022-02-22 15:50 ` [PATCH v4 05/12] PCI: mvebu: Correctly configure x1/x4 mode Pali Rohár
` (8 subsequent siblings)
12 siblings, 1 reply; 26+ messages in thread
From: Pali Rohár @ 2022-02-22 15:50 UTC (permalink / raw)
To: Lorenzo Pieralisi, Bjorn Helgaas, Rob Herring, Thomas Petazzoni,
Krzysztof Wilczyński, Marek Behún, Russell King
Cc: linux-pci, linux-kernel, linux-arm-kernel
Controller driver needs to correctly configure PCIe link if it contains 1
or 4 SerDes PCIe lanes. Therefore add a new 'num-lanes' DT property for
mvebu PCIe controller. Property 'num-lanes' seems to be de-facto standard
way how number of lanes is specified in other PCIe controllers.
Signed-off-by: Pali Rohár <pali@kernel.org>
Acked-by: Rob Herring <robh@kernel.org>
---
Documentation/devicetree/bindings/pci/mvebu-pci.txt | 11 +++++++++++
1 file changed, 11 insertions(+)
diff --git a/Documentation/devicetree/bindings/pci/mvebu-pci.txt b/Documentation/devicetree/bindings/pci/mvebu-pci.txt
index 6173af6885f8..24225852bce0 100644
--- a/Documentation/devicetree/bindings/pci/mvebu-pci.txt
+++ b/Documentation/devicetree/bindings/pci/mvebu-pci.txt
@@ -77,6 +77,7 @@ and the following optional properties:
- marvell,pcie-lane: the physical PCIe lane number, for ports having
multiple lanes. If this property is not found, we assume that the
value is 0.
+- num-lanes: number of SerDes PCIe lanes for this link (1 or 4)
- reset-gpios: optional GPIO to PERST#
- reset-delay-us: delay in us to wait after reset de-assertion, if not
specified will default to 100ms, as required by the PCIe specification.
@@ -141,6 +142,7 @@ pcie-controller {
interrupt-map = <0 0 0 0 &mpic 58>;
marvell,pcie-port = <0>;
marvell,pcie-lane = <0>;
+ num-lanes = <1>;
/* low-active PERST# reset on GPIO 25 */
reset-gpios = <&gpio0 25 1>;
/* wait 20ms for device settle after reset deassertion */
@@ -161,6 +163,7 @@ pcie-controller {
interrupt-map = <0 0 0 0 &mpic 59>;
marvell,pcie-port = <0>;
marvell,pcie-lane = <1>;
+ num-lanes = <1>;
clocks = <&gateclk 6>;
};
@@ -177,6 +180,7 @@ pcie-controller {
interrupt-map = <0 0 0 0 &mpic 60>;
marvell,pcie-port = <0>;
marvell,pcie-lane = <2>;
+ num-lanes = <1>;
clocks = <&gateclk 7>;
};
@@ -193,6 +197,7 @@ pcie-controller {
interrupt-map = <0 0 0 0 &mpic 61>;
marvell,pcie-port = <0>;
marvell,pcie-lane = <3>;
+ num-lanes = <1>;
clocks = <&gateclk 8>;
};
@@ -209,6 +214,7 @@ pcie-controller {
interrupt-map = <0 0 0 0 &mpic 62>;
marvell,pcie-port = <1>;
marvell,pcie-lane = <0>;
+ num-lanes = <1>;
clocks = <&gateclk 9>;
};
@@ -225,6 +231,7 @@ pcie-controller {
interrupt-map = <0 0 0 0 &mpic 63>;
marvell,pcie-port = <1>;
marvell,pcie-lane = <1>;
+ num-lanes = <1>;
clocks = <&gateclk 10>;
};
@@ -241,6 +248,7 @@ pcie-controller {
interrupt-map = <0 0 0 0 &mpic 64>;
marvell,pcie-port = <1>;
marvell,pcie-lane = <2>;
+ num-lanes = <1>;
clocks = <&gateclk 11>;
};
@@ -257,6 +265,7 @@ pcie-controller {
interrupt-map = <0 0 0 0 &mpic 65>;
marvell,pcie-port = <1>;
marvell,pcie-lane = <3>;
+ num-lanes = <1>;
clocks = <&gateclk 12>;
};
@@ -273,6 +282,7 @@ pcie-controller {
interrupt-map = <0 0 0 0 &mpic 99>;
marvell,pcie-port = <2>;
marvell,pcie-lane = <0>;
+ num-lanes = <1>;
clocks = <&gateclk 26>;
};
@@ -289,6 +299,7 @@ pcie-controller {
interrupt-map = <0 0 0 0 &mpic 103>;
marvell,pcie-port = <3>;
marvell,pcie-lane = <0>;
+ num-lanes = <1>;
clocks = <&gateclk 27>;
};
};
--
2.20.1
^ permalink raw reply related [flat|nested] 26+ messages in thread* Re: [PATCH v4 04/12] dt-bindings: PCI: mvebu: Add num-lanes property
2022-02-22 15:50 ` [PATCH v4 04/12] dt-bindings: PCI: mvebu: Add num-lanes property Pali Rohár
@ 2022-02-25 0:02 ` Bjorn Helgaas
2022-02-25 12:58 ` Pali Rohár
0 siblings, 1 reply; 26+ messages in thread
From: Bjorn Helgaas @ 2022-02-25 0:02 UTC (permalink / raw)
To: Pali Rohár
Cc: Lorenzo Pieralisi, Bjorn Helgaas, Rob Herring, Thomas Petazzoni,
Krzysztof Wilczyński, Marek Behún, Russell King,
linux-pci, linux-kernel, linux-arm-kernel
On Tue, Feb 22, 2022 at 04:50:22PM +0100, Pali Rohár wrote:
> Controller driver needs to correctly configure PCIe link if it contains 1
> or 4 SerDes PCIe lanes. Therefore add a new 'num-lanes' DT property for
> mvebu PCIe controller. Property 'num-lanes' seems to be de-facto standard
> way how number of lanes is specified in other PCIe controllers.
>
> Signed-off-by: Pali Rohár <pali@kernel.org>
> Acked-by: Rob Herring <robh@kernel.org>
> ---
> Documentation/devicetree/bindings/pci/mvebu-pci.txt | 11 +++++++++++
> 1 file changed, 11 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/pci/mvebu-pci.txt b/Documentation/devicetree/bindings/pci/mvebu-pci.txt
> index 6173af6885f8..24225852bce0 100644
> --- a/Documentation/devicetree/bindings/pci/mvebu-pci.txt
> +++ b/Documentation/devicetree/bindings/pci/mvebu-pci.txt
> @@ -77,6 +77,7 @@ and the following optional properties:
> - marvell,pcie-lane: the physical PCIe lane number, for ports having
> multiple lanes. If this property is not found, we assume that the
> value is 0.
> +- num-lanes: number of SerDes PCIe lanes for this link (1 or 4)
> - reset-gpios: optional GPIO to PERST#
> - reset-delay-us: delay in us to wait after reset de-assertion, if not
> specified will default to 100ms, as required by the PCIe specification.
> @@ -141,6 +142,7 @@ pcie-controller {
> interrupt-map = <0 0 0 0 &mpic 58>;
> marvell,pcie-port = <0>;
> marvell,pcie-lane = <0>;
> + num-lanes = <1>;
Is this patch really necessary? AFAICS, the related driver change
only sets "port->is_x4 = true" when "num-lanes = <4>", and in all
other cases it defaults to a Max Link Width of 1:
lnkcap |= (port->is_x4 ? 4 : 1) << 4;
I don't see the point of adding a value that we don't validate or do
anything with. E.g., I don't see an error message that would catch
"num-lanes = <3>".
Bjorn
^ permalink raw reply [flat|nested] 26+ messages in thread* Re: [PATCH v4 04/12] dt-bindings: PCI: mvebu: Add num-lanes property
2022-02-25 0:02 ` Bjorn Helgaas
@ 2022-02-25 12:58 ` Pali Rohár
2022-02-25 17:12 ` Bjorn Helgaas
0 siblings, 1 reply; 26+ messages in thread
From: Pali Rohár @ 2022-02-25 12:58 UTC (permalink / raw)
To: Bjorn Helgaas
Cc: Lorenzo Pieralisi, Bjorn Helgaas, Rob Herring, Thomas Petazzoni,
Krzysztof Wilczyński, Marek Behún, Russell King,
linux-pci, linux-kernel, linux-arm-kernel
On Thursday 24 February 2022 18:02:26 Bjorn Helgaas wrote:
> On Tue, Feb 22, 2022 at 04:50:22PM +0100, Pali Rohár wrote:
> > Controller driver needs to correctly configure PCIe link if it contains 1
> > or 4 SerDes PCIe lanes. Therefore add a new 'num-lanes' DT property for
> > mvebu PCIe controller. Property 'num-lanes' seems to be de-facto standard
> > way how number of lanes is specified in other PCIe controllers.
> >
> > Signed-off-by: Pali Rohár <pali@kernel.org>
> > Acked-by: Rob Herring <robh@kernel.org>
> > ---
> > Documentation/devicetree/bindings/pci/mvebu-pci.txt | 11 +++++++++++
> > 1 file changed, 11 insertions(+)
> >
> > diff --git a/Documentation/devicetree/bindings/pci/mvebu-pci.txt b/Documentation/devicetree/bindings/pci/mvebu-pci.txt
> > index 6173af6885f8..24225852bce0 100644
> > --- a/Documentation/devicetree/bindings/pci/mvebu-pci.txt
> > +++ b/Documentation/devicetree/bindings/pci/mvebu-pci.txt
> > @@ -77,6 +77,7 @@ and the following optional properties:
> > - marvell,pcie-lane: the physical PCIe lane number, for ports having
> > multiple lanes. If this property is not found, we assume that the
> > value is 0.
> > +- num-lanes: number of SerDes PCIe lanes for this link (1 or 4)
> > - reset-gpios: optional GPIO to PERST#
> > - reset-delay-us: delay in us to wait after reset de-assertion, if not
> > specified will default to 100ms, as required by the PCIe specification.
> > @@ -141,6 +142,7 @@ pcie-controller {
> > interrupt-map = <0 0 0 0 &mpic 58>;
> > marvell,pcie-port = <0>;
> > marvell,pcie-lane = <0>;
> > + num-lanes = <1>;
>
> Is this patch really necessary?
This is just documentation patch. And I think that documentation is
always important.
> AFAICS, the related driver change
> only sets "port->is_x4 = true" when "num-lanes = <4>", and in all
> other cases it defaults to a Max Link Width of 1:
>
> lnkcap |= (port->is_x4 ? 4 : 1) << 4;
Yes!
And this registers configures number of lanes in HW.
> I don't see the point of adding a value that we don't validate or do
> anything with. E.g., I don't see an error message that would catch
> "num-lanes = <3>".
>
> Bjorn
In past I was told that kernel should not do validation of DT properties
and it is job of some DT schema validation. That is why I did not added
code into kernel which show error message when value different than 1
and 4 is specified in DT.
But issue here is that there is no DT schema for pci-mvebu as above
.txt file was not converted to YAML schema yet. This is something which
should be improved...
^ permalink raw reply [flat|nested] 26+ messages in thread* Re: [PATCH v4 04/12] dt-bindings: PCI: mvebu: Add num-lanes property
2022-02-25 12:58 ` Pali Rohár
@ 2022-02-25 17:12 ` Bjorn Helgaas
0 siblings, 0 replies; 26+ messages in thread
From: Bjorn Helgaas @ 2022-02-25 17:12 UTC (permalink / raw)
To: Pali Rohár
Cc: Lorenzo Pieralisi, Bjorn Helgaas, Rob Herring, Thomas Petazzoni,
Krzysztof Wilczyński, Marek Behún, Russell King,
linux-pci, linux-kernel, linux-arm-kernel
On Fri, Feb 25, 2022 at 01:58:10PM +0100, Pali Rohár wrote:
> On Thursday 24 February 2022 18:02:26 Bjorn Helgaas wrote:
> > On Tue, Feb 22, 2022 at 04:50:22PM +0100, Pali Rohár wrote:
> > > Controller driver needs to correctly configure PCIe link if it contains 1
> > > or 4 SerDes PCIe lanes. Therefore add a new 'num-lanes' DT property for
> > > mvebu PCIe controller. Property 'num-lanes' seems to be de-facto standard
> > > way how number of lanes is specified in other PCIe controllers.
> > >
> > > Signed-off-by: Pali Rohár <pali@kernel.org>
> > > Acked-by: Rob Herring <robh@kernel.org>
> > > ---
> > > Documentation/devicetree/bindings/pci/mvebu-pci.txt | 11 +++++++++++
> > > 1 file changed, 11 insertions(+)
> > >
> > > diff --git a/Documentation/devicetree/bindings/pci/mvebu-pci.txt b/Documentation/devicetree/bindings/pci/mvebu-pci.txt
> > > index 6173af6885f8..24225852bce0 100644
> > > --- a/Documentation/devicetree/bindings/pci/mvebu-pci.txt
> > > +++ b/Documentation/devicetree/bindings/pci/mvebu-pci.txt
> > > @@ -77,6 +77,7 @@ and the following optional properties:
> > > - marvell,pcie-lane: the physical PCIe lane number, for ports having
> > > multiple lanes. If this property is not found, we assume that the
> > > value is 0.
> > > +- num-lanes: number of SerDes PCIe lanes for this link (1 or 4)
> > > - reset-gpios: optional GPIO to PERST#
> > > - reset-delay-us: delay in us to wait after reset de-assertion, if not
> > > specified will default to 100ms, as required by the PCIe specification.
> > > @@ -141,6 +142,7 @@ pcie-controller {
> > > interrupt-map = <0 0 0 0 &mpic 58>;
> > > marvell,pcie-port = <0>;
> > > marvell,pcie-lane = <0>;
> > > + num-lanes = <1>;
> >
> > Is this patch really necessary?
>
> This is just documentation patch. And I think that documentation is
> always important.
>
> > AFAICS, the related driver change
> > only sets "port->is_x4 = true" when "num-lanes = <4>", and in all
> > other cases it defaults to a Max Link Width of 1:
> >
> > lnkcap |= (port->is_x4 ? 4 : 1) << 4;
>
> Yes!
>
> And this registers configures number of lanes in HW.
>
> > I don't see the point of adding a value that we don't validate or do
> > anything with. E.g., I don't see an error message that would catch
> > "num-lanes = <3>".
> >
> > Bjorn
>
> In past I was told that kernel should not do validation of DT properties
> and it is job of some DT schema validation. That is why I did not added
> code into kernel which show error message when value different than 1
> and 4 is specified in DT.
>
> But issue here is that there is no DT schema for pci-mvebu as above
> .txt file was not converted to YAML schema yet. This is something which
> should be improved...
I'm OK with this patch as-is, especially since Rob acked it.
Bjorn
^ permalink raw reply [flat|nested] 26+ messages in thread
* [PATCH v4 05/12] PCI: mvebu: Correctly configure x1/x4 mode
2022-02-22 15:50 [PATCH v4 00/12] PCI: mvebu: subsystem ids, AER and INTx Pali Rohár
` (3 preceding siblings ...)
2022-02-22 15:50 ` [PATCH v4 04/12] dt-bindings: PCI: mvebu: Add num-lanes property Pali Rohár
@ 2022-02-22 15:50 ` Pali Rohár
2022-02-25 0:08 ` Bjorn Helgaas
2022-02-22 15:50 ` [PATCH v4 06/12] PCI: mvebu: Add support for PCI Bridge Subsystem Vendor ID on emulated bridge Pali Rohár
` (7 subsequent siblings)
12 siblings, 1 reply; 26+ messages in thread
From: Pali Rohár @ 2022-02-22 15:50 UTC (permalink / raw)
To: Lorenzo Pieralisi, Bjorn Helgaas, Rob Herring, Thomas Petazzoni,
Krzysztof Wilczyński, Marek Behún, Russell King
Cc: linux-pci, linux-kernel, linux-arm-kernel
If x1/x4 mode is not set correctly then link with endpoint card is not
established.
Use DTS property 'num-lanes' to deteriminate x1/x4 mode.
Signed-off-by: Pali Rohár <pali@kernel.org>
---
drivers/pci/controller/pci-mvebu.c | 19 ++++++++++++++++++-
1 file changed, 18 insertions(+), 1 deletion(-)
diff --git a/drivers/pci/controller/pci-mvebu.c b/drivers/pci/controller/pci-mvebu.c
index 357f0f41f68e..d0a75c3b78c3 100644
--- a/drivers/pci/controller/pci-mvebu.c
+++ b/drivers/pci/controller/pci-mvebu.c
@@ -93,6 +93,7 @@ struct mvebu_pcie_port {
void __iomem *base;
u32 port;
u32 lane;
+ bool is_x4;
int devfn;
unsigned int mem_target;
unsigned int mem_attr;
@@ -233,13 +234,25 @@ static void mvebu_pcie_setup_wins(struct mvebu_pcie_port *port)
static void mvebu_pcie_setup_hw(struct mvebu_pcie_port *port)
{
- u32 ctrl, cmd, dev_rev, mask;
+ u32 ctrl, lnkcap, cmd, dev_rev, mask;
/* Setup PCIe controller to Root Complex mode. */
ctrl = mvebu_readl(port, PCIE_CTRL_OFF);
ctrl |= PCIE_CTRL_RC_MODE;
mvebu_writel(port, ctrl, PCIE_CTRL_OFF);
+ /*
+ * Set Maximum Link Width to X1 or X4 in Root Port's PCIe Link
+ * Capability register. This register is defined by PCIe specification
+ * as read-only but this mvebu controller has it as read-write and must
+ * be set to number of SerDes PCIe lanes (1 or 4). If this register is
+ * not set correctly then link with endpoint card is not established.
+ */
+ lnkcap = mvebu_readl(port, PCIE_CAP_PCIEXP + PCI_EXP_LNKCAP);
+ lnkcap &= ~PCI_EXP_LNKCAP_MLW;
+ lnkcap |= (port->is_x4 ? 4 : 1) << 4;
+ mvebu_writel(port, lnkcap, PCIE_CAP_PCIEXP + PCI_EXP_LNKCAP);
+
/* Disable Root Bridge I/O space, memory space and bus mastering. */
cmd = mvebu_readl(port, PCIE_CMD_OFF);
cmd &= ~(PCI_COMMAND_IO | PCI_COMMAND_MEMORY | PCI_COMMAND_MASTER);
@@ -982,6 +995,7 @@ static int mvebu_pcie_parse_port(struct mvebu_pcie *pcie,
struct device *dev = &pcie->pdev->dev;
enum of_gpio_flags flags;
int reset_gpio, ret;
+ u32 num_lanes;
port->pcie = pcie;
@@ -994,6 +1008,9 @@ static int mvebu_pcie_parse_port(struct mvebu_pcie *pcie,
if (of_property_read_u32(child, "marvell,pcie-lane", &port->lane))
port->lane = 0;
+ if (!of_property_read_u32(child, "num-lanes", &num_lanes) && num_lanes == 4)
+ port->is_x4 = true;
+
port->name = devm_kasprintf(dev, GFP_KERNEL, "pcie%d.%d", port->port,
port->lane);
if (!port->name) {
--
2.20.1
^ permalink raw reply related [flat|nested] 26+ messages in thread* Re: [PATCH v4 05/12] PCI: mvebu: Correctly configure x1/x4 mode
2022-02-22 15:50 ` [PATCH v4 05/12] PCI: mvebu: Correctly configure x1/x4 mode Pali Rohár
@ 2022-02-25 0:08 ` Bjorn Helgaas
2022-02-25 13:04 ` Pali Rohár
0 siblings, 1 reply; 26+ messages in thread
From: Bjorn Helgaas @ 2022-02-25 0:08 UTC (permalink / raw)
To: Pali Rohár
Cc: Lorenzo Pieralisi, Bjorn Helgaas, Rob Herring, Thomas Petazzoni,
Krzysztof Wilczyński, Marek Behún, Russell King,
linux-pci, linux-kernel, linux-arm-kernel
On Tue, Feb 22, 2022 at 04:50:23PM +0100, Pali Rohár wrote:
> If x1/x4 mode is not set correctly then link with endpoint card is not
> established.
>
> Use DTS property 'num-lanes' to deteriminate x1/x4 mode.
I know this is already merged, but if tweaking for any other reason,
s/deteriminate/determine/
> + * Set Maximum Link Width to X1 or X4 in Root Port's PCIe Link
> + * Capability register. This register is defined by PCIe specification
> + * as read-only but this mvebu controller has it as read-write and must
> + * be set to number of SerDes PCIe lanes (1 or 4). If this register is
> + * not set correctly then link with endpoint card is not established.
True, everything in Link Capability is RO or HwInit, but that's for
the architected access via config space. I think a device-specific
mechanism like this is fair game as long as you do it before anybody
can read it via config space.
> + */
> + lnkcap = mvebu_readl(port, PCIE_CAP_PCIEXP + PCI_EXP_LNKCAP);
> + lnkcap &= ~PCI_EXP_LNKCAP_MLW;
> + lnkcap |= (port->is_x4 ? 4 : 1) << 4;
> + mvebu_writel(port, lnkcap, PCIE_CAP_PCIEXP + PCI_EXP_LNKCAP);
^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: [PATCH v4 05/12] PCI: mvebu: Correctly configure x1/x4 mode
2022-02-25 0:08 ` Bjorn Helgaas
@ 2022-02-25 13:04 ` Pali Rohár
0 siblings, 0 replies; 26+ messages in thread
From: Pali Rohár @ 2022-02-25 13:04 UTC (permalink / raw)
To: Bjorn Helgaas
Cc: Lorenzo Pieralisi, Bjorn Helgaas, Rob Herring, Thomas Petazzoni,
Krzysztof Wilczyński, Marek Behún, Russell King,
linux-pci, linux-kernel, linux-arm-kernel
On Thursday 24 February 2022 18:08:00 Bjorn Helgaas wrote:
> On Tue, Feb 22, 2022 at 04:50:23PM +0100, Pali Rohár wrote:
> > If x1/x4 mode is not set correctly then link with endpoint card is not
> > established.
> >
> > Use DTS property 'num-lanes' to deteriminate x1/x4 mode.
>
> I know this is already merged, but if tweaking for any other reason,
> s/deteriminate/determine/
>
> > + * Set Maximum Link Width to X1 or X4 in Root Port's PCIe Link
> > + * Capability register. This register is defined by PCIe specification
> > + * as read-only but this mvebu controller has it as read-write and must
> > + * be set to number of SerDes PCIe lanes (1 or 4). If this register is
> > + * not set correctly then link with endpoint card is not established.
>
> True, everything in Link Capability is RO or HwInit, but that's for
> the architected access via config space. I think a device-specific
> mechanism like this is fair game as long as you do it before anybody
> can read it via config space.
Maybe I was not clear and explicit in above comment, but this register
sets number of PCIe lanes which HW will use. Armada PCIe controllers
supports only x1 and x4. Sometimes default HW value is 4 for x1 HW and
sometimes default value for x4 HW is 1. First case cause that link never
comes up (HW is trying to setup 4 lanes but in reality there is only
one, so link training never finish) and second case cause degraded
performance (x4 link is established only in x1 mode as HW is via this
register instructed to ignores other 3 lanes).
So basically HW designers misused this Link Capability register for
configuring PCIe Link of PCIe Root Port.
> > + */
> > + lnkcap = mvebu_readl(port, PCIE_CAP_PCIEXP + PCI_EXP_LNKCAP);
> > + lnkcap &= ~PCI_EXP_LNKCAP_MLW;
> > + lnkcap |= (port->is_x4 ? 4 : 1) << 4;
> > + mvebu_writel(port, lnkcap, PCIE_CAP_PCIEXP + PCI_EXP_LNKCAP);
^ permalink raw reply [flat|nested] 26+ messages in thread
* [PATCH v4 06/12] PCI: mvebu: Add support for PCI Bridge Subsystem Vendor ID on emulated bridge
2022-02-22 15:50 [PATCH v4 00/12] PCI: mvebu: subsystem ids, AER and INTx Pali Rohár
` (4 preceding siblings ...)
2022-02-22 15:50 ` [PATCH v4 05/12] PCI: mvebu: Correctly configure x1/x4 mode Pali Rohár
@ 2022-02-22 15:50 ` Pali Rohár
2022-02-22 15:50 ` [PATCH v4 07/12] PCI: mvebu: Add support for Advanced Error Reporting registers " Pali Rohár
` (6 subsequent siblings)
12 siblings, 0 replies; 26+ messages in thread
From: Pali Rohár @ 2022-02-22 15:50 UTC (permalink / raw)
To: Lorenzo Pieralisi, Bjorn Helgaas, Rob Herring, Thomas Petazzoni,
Krzysztof Wilczyński, Marek Behún, Russell King
Cc: linux-pci, linux-kernel, linux-arm-kernel
Register with Subsystem Device/Vendor ID is at offset 0x2c. Export is via
emulated bridge.
After this change Subsystem ID is visible in lspci output at line:
Capabilities: [40] Subsystem
Signed-off-by: Pali Rohár <pali@kernel.org>
---
drivers/pci/controller/pci-mvebu.c | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/drivers/pci/controller/pci-mvebu.c b/drivers/pci/controller/pci-mvebu.c
index d0a75c3b78c3..566d8382afe6 100644
--- a/drivers/pci/controller/pci-mvebu.c
+++ b/drivers/pci/controller/pci-mvebu.c
@@ -32,6 +32,7 @@
#define PCIE_DEV_REV_OFF 0x0008
#define PCIE_BAR_LO_OFF(n) (0x0010 + ((n) << 3))
#define PCIE_BAR_HI_OFF(n) (0x0014 + ((n) << 3))
+#define PCIE_SSDEV_ID_OFF 0x002c
#define PCIE_CAP_PCIEXP 0x0060
#define PCIE_HEADER_LOG_4_OFF 0x0128
#define PCIE_BAR_CTRL_OFF(n) (0x1804 + (((n) - 1) * 4))
@@ -731,6 +732,7 @@ static int mvebu_pci_bridge_emul_init(struct mvebu_pcie_port *port)
struct pci_bridge_emul *bridge = &port->bridge;
u32 dev_id = mvebu_readl(port, PCIE_DEV_ID_OFF);
u32 dev_rev = mvebu_readl(port, PCIE_DEV_REV_OFF);
+ u32 ssdev_id = mvebu_readl(port, PCIE_SSDEV_ID_OFF);
u32 pcie_cap = mvebu_readl(port, PCIE_CAP_PCIEXP);
u8 pcie_cap_ver = ((pcie_cap >> 16) & PCI_EXP_FLAGS_VERS);
@@ -752,6 +754,8 @@ static int mvebu_pci_bridge_emul_init(struct mvebu_pcie_port *port)
*/
bridge->pcie_conf.cap = cpu_to_le16(pcie_cap_ver);
+ bridge->subsystem_vendor_id = ssdev_id & 0xffff;
+ bridge->subsystem_id = ssdev_id >> 16;
bridge->has_pcie = true;
bridge->data = port;
bridge->ops = &mvebu_pci_bridge_emul_ops;
--
2.20.1
^ permalink raw reply related [flat|nested] 26+ messages in thread* [PATCH v4 07/12] PCI: mvebu: Add support for Advanced Error Reporting registers on emulated bridge
2022-02-22 15:50 [PATCH v4 00/12] PCI: mvebu: subsystem ids, AER and INTx Pali Rohár
` (5 preceding siblings ...)
2022-02-22 15:50 ` [PATCH v4 06/12] PCI: mvebu: Add support for PCI Bridge Subsystem Vendor ID on emulated bridge Pali Rohár
@ 2022-02-22 15:50 ` Pali Rohár
2022-02-22 15:50 ` [PATCH v4 08/12] PCI: mvebu: Use child_ops API Pali Rohár
` (5 subsequent siblings)
12 siblings, 0 replies; 26+ messages in thread
From: Pali Rohár @ 2022-02-22 15:50 UTC (permalink / raw)
To: Lorenzo Pieralisi, Bjorn Helgaas, Rob Herring, Thomas Petazzoni,
Krzysztof Wilczyński, Marek Behún, Russell King
Cc: linux-pci, linux-kernel, linux-arm-kernel
AER registers start at mvebu offset 0x0100. Registers PCI_ERR_ROOT_COMMAND,
PCI_ERR_ROOT_STATUS and PCI_ERR_ROOT_ERR_SRC are not supported on pre-XP
hardware and returns zeros.
Note that AER interrupt is not supported yet as mvebu emulated bridge does
not implement interrupts support at all yet.
Also remove custom macro PCIE_HEADER_LOG_4_OFF as it is unused and
correctly this register should be referenced via standard macros with
offset, e.g. as: PCIE_CAP_PCIERR_OFF + PCI_ERR_HEADER_LOG + 4.
Signed-off-by: Pali Rohár <pali@kernel.org>
---
drivers/pci/controller/pci-mvebu.c | 67 +++++++++++++++++++++++++++++-
1 file changed, 66 insertions(+), 1 deletion(-)
diff --git a/drivers/pci/controller/pci-mvebu.c b/drivers/pci/controller/pci-mvebu.c
index 566d8382afe6..1cf5c02499cd 100644
--- a/drivers/pci/controller/pci-mvebu.c
+++ b/drivers/pci/controller/pci-mvebu.c
@@ -34,7 +34,7 @@
#define PCIE_BAR_HI_OFF(n) (0x0014 + ((n) << 3))
#define PCIE_SSDEV_ID_OFF 0x002c
#define PCIE_CAP_PCIEXP 0x0060
-#define PCIE_HEADER_LOG_4_OFF 0x0128
+#define PCIE_CAP_PCIERR_OFF 0x0100
#define PCIE_BAR_CTRL_OFF(n) (0x1804 + (((n) - 1) * 4))
#define PCIE_WIN04_CTRL_OFF(n) (0x1820 + ((n) << 4))
#define PCIE_WIN04_BASE_OFF(n) (0x1824 + ((n) << 4))
@@ -603,6 +603,37 @@ mvebu_pci_bridge_emul_pcie_conf_read(struct pci_bridge_emul *bridge,
return PCI_BRIDGE_EMUL_HANDLED;
}
+static pci_bridge_emul_read_status_t
+mvebu_pci_bridge_emul_ext_conf_read(struct pci_bridge_emul *bridge,
+ int reg, u32 *value)
+{
+ struct mvebu_pcie_port *port = bridge->data;
+
+ switch (reg) {
+ case 0:
+ case PCI_ERR_UNCOR_STATUS:
+ case PCI_ERR_UNCOR_MASK:
+ case PCI_ERR_UNCOR_SEVER:
+ case PCI_ERR_COR_STATUS:
+ case PCI_ERR_COR_MASK:
+ case PCI_ERR_CAP:
+ case PCI_ERR_HEADER_LOG+0:
+ case PCI_ERR_HEADER_LOG+4:
+ case PCI_ERR_HEADER_LOG+8:
+ case PCI_ERR_HEADER_LOG+12:
+ case PCI_ERR_ROOT_COMMAND:
+ case PCI_ERR_ROOT_STATUS:
+ case PCI_ERR_ROOT_ERR_SRC:
+ *value = mvebu_readl(port, PCIE_CAP_PCIERR_OFF + reg);
+ break;
+
+ default:
+ return PCI_BRIDGE_EMUL_NOT_HANDLED;
+ }
+
+ return PCI_BRIDGE_EMUL_HANDLED;
+}
+
static void
mvebu_pci_bridge_emul_base_conf_write(struct pci_bridge_emul *bridge,
int reg, u32 old, u32 new, u32 mask)
@@ -715,11 +746,45 @@ mvebu_pci_bridge_emul_pcie_conf_write(struct pci_bridge_emul *bridge,
}
}
+static void
+mvebu_pci_bridge_emul_ext_conf_write(struct pci_bridge_emul *bridge,
+ int reg, u32 old, u32 new, u32 mask)
+{
+ struct mvebu_pcie_port *port = bridge->data;
+
+ switch (reg) {
+ /* These are W1C registers, so clear other bits */
+ case PCI_ERR_UNCOR_STATUS:
+ case PCI_ERR_COR_STATUS:
+ case PCI_ERR_ROOT_STATUS:
+ new &= mask;
+ fallthrough;
+
+ case PCI_ERR_UNCOR_MASK:
+ case PCI_ERR_UNCOR_SEVER:
+ case PCI_ERR_COR_MASK:
+ case PCI_ERR_CAP:
+ case PCI_ERR_HEADER_LOG+0:
+ case PCI_ERR_HEADER_LOG+4:
+ case PCI_ERR_HEADER_LOG+8:
+ case PCI_ERR_HEADER_LOG+12:
+ case PCI_ERR_ROOT_COMMAND:
+ case PCI_ERR_ROOT_ERR_SRC:
+ mvebu_writel(port, new, PCIE_CAP_PCIERR_OFF + reg);
+ break;
+
+ default:
+ break;
+ }
+}
+
static const struct pci_bridge_emul_ops mvebu_pci_bridge_emul_ops = {
.read_base = mvebu_pci_bridge_emul_base_conf_read,
.write_base = mvebu_pci_bridge_emul_base_conf_write,
.read_pcie = mvebu_pci_bridge_emul_pcie_conf_read,
.write_pcie = mvebu_pci_bridge_emul_pcie_conf_write,
+ .read_ext = mvebu_pci_bridge_emul_ext_conf_read,
+ .write_ext = mvebu_pci_bridge_emul_ext_conf_write,
};
/*
--
2.20.1
^ permalink raw reply related [flat|nested] 26+ messages in thread* [PATCH v4 08/12] PCI: mvebu: Use child_ops API
2022-02-22 15:50 [PATCH v4 00/12] PCI: mvebu: subsystem ids, AER and INTx Pali Rohár
` (6 preceding siblings ...)
2022-02-22 15:50 ` [PATCH v4 07/12] PCI: mvebu: Add support for Advanced Error Reporting registers " Pali Rohár
@ 2022-02-22 15:50 ` Pali Rohár
2022-02-22 15:50 ` [PATCH v4 09/12] dt-bindings: PCI: mvebu: Update information about intx interrupts Pali Rohár
` (4 subsequent siblings)
12 siblings, 0 replies; 26+ messages in thread
From: Pali Rohár @ 2022-02-22 15:50 UTC (permalink / raw)
To: Lorenzo Pieralisi, Bjorn Helgaas, Rob Herring, Thomas Petazzoni,
Krzysztof Wilczyński, Marek Behún, Russell King
Cc: linux-pci, linux-kernel, linux-arm-kernel
Split struct pci_ops between ops and child_ops. Member ops is used for
accessing PCIe Root Ports via pci-bridge-emul.c driver and child_ops for
accessing real PCIe cards.
There is no need to mix these two struct pci_ops into one as PCI core code
already provides separate callbacks via bridge->ops and bridge->child_ops.
Signed-off-by: Pali Rohár <pali@kernel.org>
---
drivers/pci/controller/pci-mvebu.c | 77 ++++++++++++++++--------------
1 file changed, 40 insertions(+), 37 deletions(-)
diff --git a/drivers/pci/controller/pci-mvebu.c b/drivers/pci/controller/pci-mvebu.c
index 1cf5c02499cd..1ae7718a2e3e 100644
--- a/drivers/pci/controller/pci-mvebu.c
+++ b/drivers/pci/controller/pci-mvebu.c
@@ -294,11 +294,25 @@ static void mvebu_pcie_setup_hw(struct mvebu_pcie_port *port)
mvebu_writel(port, mask, PCIE_MASK_OFF);
}
-static int mvebu_pcie_hw_rd_conf(struct mvebu_pcie_port *port,
- struct pci_bus *bus,
- u32 devfn, int where, int size, u32 *val)
+static struct mvebu_pcie_port *mvebu_pcie_find_port(struct mvebu_pcie *pcie,
+ struct pci_bus *bus,
+ int devfn);
+
+static int mvebu_pcie_child_rd_conf(struct pci_bus *bus, u32 devfn, int where,
+ int size, u32 *val)
{
- void __iomem *conf_data = port->base + PCIE_CONF_DATA_OFF;
+ struct mvebu_pcie *pcie = bus->sysdata;
+ struct mvebu_pcie_port *port;
+ void __iomem *conf_data;
+
+ port = mvebu_pcie_find_port(pcie, bus, devfn);
+ if (!port)
+ return PCIBIOS_DEVICE_NOT_FOUND;
+
+ if (!mvebu_pcie_link_up(port))
+ return PCIBIOS_DEVICE_NOT_FOUND;
+
+ conf_data = port->base + PCIE_CONF_DATA_OFF;
mvebu_writel(port, PCIE_CONF_ADDR(bus->number, devfn, where),
PCIE_CONF_ADDR_OFF);
@@ -314,18 +328,27 @@ static int mvebu_pcie_hw_rd_conf(struct mvebu_pcie_port *port,
*val = readl_relaxed(conf_data);
break;
default:
- *val = 0xffffffff;
return PCIBIOS_BAD_REGISTER_NUMBER;
}
return PCIBIOS_SUCCESSFUL;
}
-static int mvebu_pcie_hw_wr_conf(struct mvebu_pcie_port *port,
- struct pci_bus *bus,
- u32 devfn, int where, int size, u32 val)
+static int mvebu_pcie_child_wr_conf(struct pci_bus *bus, u32 devfn,
+ int where, int size, u32 val)
{
- void __iomem *conf_data = port->base + PCIE_CONF_DATA_OFF;
+ struct mvebu_pcie *pcie = bus->sysdata;
+ struct mvebu_pcie_port *port;
+ void __iomem *conf_data;
+
+ port = mvebu_pcie_find_port(pcie, bus, devfn);
+ if (!port)
+ return PCIBIOS_DEVICE_NOT_FOUND;
+
+ if (!mvebu_pcie_link_up(port))
+ return PCIBIOS_DEVICE_NOT_FOUND;
+
+ conf_data = port->base + PCIE_CONF_DATA_OFF;
mvebu_writel(port, PCIE_CONF_ADDR(bus->number, devfn, where),
PCIE_CONF_ADDR_OFF);
@@ -347,6 +370,11 @@ static int mvebu_pcie_hw_wr_conf(struct mvebu_pcie_port *port,
return PCIBIOS_SUCCESSFUL;
}
+static struct pci_ops mvebu_pcie_child_ops = {
+ .read = mvebu_pcie_child_rd_conf,
+ .write = mvebu_pcie_child_wr_conf,
+};
+
/*
* Remove windows, starting from the largest ones to the smallest
* ones.
@@ -862,25 +890,12 @@ static int mvebu_pcie_wr_conf(struct pci_bus *bus, u32 devfn,
{
struct mvebu_pcie *pcie = bus->sysdata;
struct mvebu_pcie_port *port;
- int ret;
port = mvebu_pcie_find_port(pcie, bus, devfn);
if (!port)
return PCIBIOS_DEVICE_NOT_FOUND;
- /* Access the emulated PCI-to-PCI bridge */
- if (bus->number == 0)
- return pci_bridge_emul_conf_write(&port->bridge, where,
- size, val);
-
- if (!mvebu_pcie_link_up(port))
- return PCIBIOS_DEVICE_NOT_FOUND;
-
- /* Access the real PCIe interface */
- ret = mvebu_pcie_hw_wr_conf(port, bus, devfn,
- where, size, val);
-
- return ret;
+ return pci_bridge_emul_conf_write(&port->bridge, where, size, val);
}
/* PCI configuration space read function */
@@ -889,25 +904,12 @@ static int mvebu_pcie_rd_conf(struct pci_bus *bus, u32 devfn, int where,
{
struct mvebu_pcie *pcie = bus->sysdata;
struct mvebu_pcie_port *port;
- int ret;
port = mvebu_pcie_find_port(pcie, bus, devfn);
if (!port)
return PCIBIOS_DEVICE_NOT_FOUND;
- /* Access the emulated PCI-to-PCI bridge */
- if (bus->number == 0)
- return pci_bridge_emul_conf_read(&port->bridge, where,
- size, val);
-
- if (!mvebu_pcie_link_up(port))
- return PCIBIOS_DEVICE_NOT_FOUND;
-
- /* Access the real PCIe interface */
- ret = mvebu_pcie_hw_rd_conf(port, bus, devfn,
- where, size, val);
-
- return ret;
+ return pci_bridge_emul_conf_read(&port->bridge, where, size, val);
}
static struct pci_ops mvebu_pcie_ops = {
@@ -1416,6 +1418,7 @@ static int mvebu_pcie_probe(struct platform_device *pdev)
bridge->sysdata = pcie;
bridge->ops = &mvebu_pcie_ops;
+ bridge->child_ops = &mvebu_pcie_child_ops;
bridge->align_resource = mvebu_pcie_align_resource;
bridge->map_irq = mvebu_pcie_map_irq;
--
2.20.1
^ permalink raw reply related [flat|nested] 26+ messages in thread* [PATCH v4 09/12] dt-bindings: PCI: mvebu: Update information about intx interrupts
2022-02-22 15:50 [PATCH v4 00/12] PCI: mvebu: subsystem ids, AER and INTx Pali Rohár
` (7 preceding siblings ...)
2022-02-22 15:50 ` [PATCH v4 08/12] PCI: mvebu: Use child_ops API Pali Rohár
@ 2022-02-22 15:50 ` Pali Rohár
2022-02-22 15:50 ` [PATCH v4 10/12] PCI: mvebu: Fix macro names and comments about legacy interrupts Pali Rohár
` (3 subsequent siblings)
12 siblings, 0 replies; 26+ messages in thread
From: Pali Rohár @ 2022-02-22 15:50 UTC (permalink / raw)
To: Lorenzo Pieralisi, Bjorn Helgaas, Rob Herring, Thomas Petazzoni,
Krzysztof Wilczyński, Marek Behún, Russell King
Cc: linux-pci, linux-kernel, linux-arm-kernel
Signed-off-by: Pali Rohár <pali@kernel.org>
Acked-by: Rob Herring <robh@kernel.org>
---
Documentation/devicetree/bindings/pci/mvebu-pci.txt | 5 +++++
1 file changed, 5 insertions(+)
diff --git a/Documentation/devicetree/bindings/pci/mvebu-pci.txt b/Documentation/devicetree/bindings/pci/mvebu-pci.txt
index 24225852bce0..6d022a9d36ee 100644
--- a/Documentation/devicetree/bindings/pci/mvebu-pci.txt
+++ b/Documentation/devicetree/bindings/pci/mvebu-pci.txt
@@ -81,6 +81,11 @@ and the following optional properties:
- reset-gpios: optional GPIO to PERST#
- reset-delay-us: delay in us to wait after reset de-assertion, if not
specified will default to 100ms, as required by the PCIe specification.
+- interrupt-names: list of interrupt names, supported are:
+ - "intx" - interrupt line triggered by one of the legacy interrupt
+- interrupts or interrupts-extended: List of the interrupt sources which
+ corresponding to the "interrupt-names". If non-empty then also additional
+ 'interrupt-controller' subnode must be defined.
Example:
--
2.20.1
^ permalink raw reply related [flat|nested] 26+ messages in thread* [PATCH v4 10/12] PCI: mvebu: Fix macro names and comments about legacy interrupts
2022-02-22 15:50 [PATCH v4 00/12] PCI: mvebu: subsystem ids, AER and INTx Pali Rohár
` (8 preceding siblings ...)
2022-02-22 15:50 ` [PATCH v4 09/12] dt-bindings: PCI: mvebu: Update information about intx interrupts Pali Rohár
@ 2022-02-22 15:50 ` Pali Rohár
2022-02-22 15:50 ` [PATCH v4 11/12] PCI: mvebu: Implement support for legacy INTx interrupts Pali Rohár
` (2 subsequent siblings)
12 siblings, 0 replies; 26+ messages in thread
From: Pali Rohár @ 2022-02-22 15:50 UTC (permalink / raw)
To: Lorenzo Pieralisi, Bjorn Helgaas, Rob Herring, Thomas Petazzoni,
Krzysztof Wilczyński, Marek Behún, Russell King
Cc: linux-pci, linux-kernel, linux-arm-kernel
Register 0x1910 unmasks interrupts and legacy INTx interrupts are unmasked
because driver does not support individual masking yet.
Signed-off-by: Pali Rohár <pali@kernel.org>
---
drivers/pci/controller/pci-mvebu.c | 26 ++++++++++++++++++--------
1 file changed, 18 insertions(+), 8 deletions(-)
diff --git a/drivers/pci/controller/pci-mvebu.c b/drivers/pci/controller/pci-mvebu.c
index 1ae7718a2e3e..d096289035bc 100644
--- a/drivers/pci/controller/pci-mvebu.c
+++ b/drivers/pci/controller/pci-mvebu.c
@@ -54,9 +54,10 @@
PCIE_CONF_ADDR_EN)
#define PCIE_CONF_DATA_OFF 0x18fc
#define PCIE_INT_CAUSE_OFF 0x1900
+#define PCIE_INT_UNMASK_OFF 0x1910
+#define PCIE_INT_INTX(i) BIT(24+i)
#define PCIE_INT_PM_PME BIT(28)
-#define PCIE_MASK_OFF 0x1910
-#define PCIE_MASK_ENABLE_INTS 0x0f000000
+#define PCIE_INT_ALL_MASK GENMASK(31, 0)
#define PCIE_CTRL_OFF 0x1a00
#define PCIE_CTRL_X1_MODE 0x0001
#define PCIE_CTRL_RC_MODE BIT(1)
@@ -235,7 +236,7 @@ static void mvebu_pcie_setup_wins(struct mvebu_pcie_port *port)
static void mvebu_pcie_setup_hw(struct mvebu_pcie_port *port)
{
- u32 ctrl, lnkcap, cmd, dev_rev, mask;
+ u32 ctrl, lnkcap, cmd, dev_rev, unmask;
/* Setup PCIe controller to Root Complex mode. */
ctrl = mvebu_readl(port, PCIE_CTRL_OFF);
@@ -288,10 +289,19 @@ static void mvebu_pcie_setup_hw(struct mvebu_pcie_port *port)
/* Point PCIe unit MBUS decode windows to DRAM space. */
mvebu_pcie_setup_wins(port);
- /* Enable interrupt lines A-D. */
- mask = mvebu_readl(port, PCIE_MASK_OFF);
- mask |= PCIE_MASK_ENABLE_INTS;
- mvebu_writel(port, mask, PCIE_MASK_OFF);
+ /*
+ * Unmask all legacy INTx interrupts as driver does not provide a way
+ * for masking and unmasking of individual legacy INTx interrupts.
+ * Legacy INTx are reported via one shared GIC source and therefore
+ * kernel cannot distinguish which individual legacy INTx was triggered.
+ * These interrupts are shared, so it should not cause any issue. Just
+ * performance penalty as every PCIe interrupt handler needs to be
+ * called when some interrupt is triggered.
+ */
+ unmask = mvebu_readl(port, PCIE_INT_UNMASK_OFF);
+ unmask |= PCIE_INT_INTX(0) | PCIE_INT_INTX(1) |
+ PCIE_INT_INTX(2) | PCIE_INT_INTX(3);
+ mvebu_writel(port, unmask, PCIE_INT_UNMASK_OFF);
}
static struct mvebu_pcie_port *mvebu_pcie_find_port(struct mvebu_pcie *pcie,
@@ -1450,7 +1460,7 @@ static int mvebu_pcie_remove(struct platform_device *pdev)
mvebu_writel(port, cmd, PCIE_CMD_OFF);
/* Mask all interrupt sources. */
- mvebu_writel(port, 0, PCIE_MASK_OFF);
+ mvebu_writel(port, ~PCIE_INT_ALL_MASK, PCIE_INT_UNMASK_OFF);
/* Free config space for emulated root bridge. */
pci_bridge_emul_cleanup(&port->bridge);
--
2.20.1
^ permalink raw reply related [flat|nested] 26+ messages in thread* [PATCH v4 11/12] PCI: mvebu: Implement support for legacy INTx interrupts
2022-02-22 15:50 [PATCH v4 00/12] PCI: mvebu: subsystem ids, AER and INTx Pali Rohár
` (9 preceding siblings ...)
2022-02-22 15:50 ` [PATCH v4 10/12] PCI: mvebu: Fix macro names and comments about legacy interrupts Pali Rohár
@ 2022-02-22 15:50 ` Pali Rohár
2022-02-25 0:26 ` Bjorn Helgaas
2022-02-22 15:50 ` [PATCH v4 12/12] ARM: dts: armada-385.dtsi: Add definitions for PCIe " Pali Rohár
2022-02-22 16:06 ` (subset) [PATCH v4 00/12] PCI: mvebu: subsystem ids, AER and INTx Lorenzo Pieralisi
12 siblings, 1 reply; 26+ messages in thread
From: Pali Rohár @ 2022-02-22 15:50 UTC (permalink / raw)
To: Lorenzo Pieralisi, Bjorn Helgaas, Rob Herring, Thomas Petazzoni,
Krzysztof Wilczyński, Marek Behún, Russell King
Cc: linux-pci, linux-kernel, linux-arm-kernel
This adds support for legacy INTx interrupts received from other PCIe
devices and which are reported by a new INTx irq chip.
With this change, kernel can distinguish between INTA, INTB, INTC and INTD
interrupts.
Note that for this support, device tree files has to be properly adjusted
to provide "interrupts" or "interrupts-extended" property with intx
interrupt source, "interrupt-names" property with "intx" string and also
'interrupt-controller' subnode must be defined.
If device tree files do not provide these nodes then driver would work as
before.
Signed-off-by: Pali Rohár <pali@kernel.org>
---
drivers/pci/controller/pci-mvebu.c | 159 +++++++++++++++++++++++++++++
1 file changed, 159 insertions(+)
diff --git a/drivers/pci/controller/pci-mvebu.c b/drivers/pci/controller/pci-mvebu.c
index d096289035bc..a75d2b9196f9 100644
--- a/drivers/pci/controller/pci-mvebu.c
+++ b/drivers/pci/controller/pci-mvebu.c
@@ -111,6 +111,9 @@ struct mvebu_pcie_port {
struct mvebu_pcie_window iowin;
u32 saved_pcie_stat;
struct resource regs;
+ struct irq_domain *intx_irq_domain;
+ raw_spinlock_t irq_lock;
+ int intx_irq;
};
static inline void mvebu_writel(struct mvebu_pcie_port *port, u32 val, u32 reg)
@@ -289,7 +292,18 @@ static void mvebu_pcie_setup_hw(struct mvebu_pcie_port *port)
/* Point PCIe unit MBUS decode windows to DRAM space. */
mvebu_pcie_setup_wins(port);
+ /* Mask all interrupt sources. */
+ mvebu_writel(port, ~PCIE_INT_ALL_MASK, PCIE_INT_UNMASK_OFF);
+
+ /* Clear all interrupt causes. */
+ mvebu_writel(port, ~PCIE_INT_ALL_MASK, PCIE_INT_CAUSE_OFF);
+
+ /* Check if "intx" interrupt was specified in DT. */
+ if (port->intx_irq > 0)
+ return;
+
/*
+ * Fallback code when "intx" interrupt was not specified in DT:
* Unmask all legacy INTx interrupts as driver does not provide a way
* for masking and unmasking of individual legacy INTx interrupts.
* Legacy INTx are reported via one shared GIC source and therefore
@@ -927,6 +941,108 @@ static struct pci_ops mvebu_pcie_ops = {
.write = mvebu_pcie_wr_conf,
};
+static void mvebu_pcie_intx_irq_mask(struct irq_data *d)
+{
+ struct mvebu_pcie_port *port = d->domain->host_data;
+ irq_hw_number_t hwirq = irqd_to_hwirq(d);
+ unsigned long flags;
+ u32 unmask;
+
+ raw_spin_lock_irqsave(&port->irq_lock, flags);
+ unmask = mvebu_readl(port, PCIE_INT_UNMASK_OFF);
+ unmask &= ~PCIE_INT_INTX(hwirq);
+ mvebu_writel(port, unmask, PCIE_INT_UNMASK_OFF);
+ raw_spin_unlock_irqrestore(&port->irq_lock, flags);
+}
+
+static void mvebu_pcie_intx_irq_unmask(struct irq_data *d)
+{
+ struct mvebu_pcie_port *port = d->domain->host_data;
+ irq_hw_number_t hwirq = irqd_to_hwirq(d);
+ unsigned long flags;
+ u32 unmask;
+
+ raw_spin_lock_irqsave(&port->irq_lock, flags);
+ unmask = mvebu_readl(port, PCIE_INT_UNMASK_OFF);
+ unmask |= PCIE_INT_INTX(hwirq);
+ mvebu_writel(port, unmask, PCIE_INT_UNMASK_OFF);
+ raw_spin_unlock_irqrestore(&port->irq_lock, flags);
+}
+
+static struct irq_chip intx_irq_chip = {
+ .name = "mvebu-INTx",
+ .irq_mask = mvebu_pcie_intx_irq_mask,
+ .irq_unmask = mvebu_pcie_intx_irq_unmask,
+};
+
+static int mvebu_pcie_intx_irq_map(struct irq_domain *h,
+ unsigned int virq, irq_hw_number_t hwirq)
+{
+ struct mvebu_pcie_port *port = h->host_data;
+
+ irq_set_status_flags(virq, IRQ_LEVEL);
+ irq_set_chip_and_handler(virq, &intx_irq_chip, handle_level_irq);
+ irq_set_chip_data(virq, port);
+
+ return 0;
+}
+
+static const struct irq_domain_ops mvebu_pcie_intx_irq_domain_ops = {
+ .map = mvebu_pcie_intx_irq_map,
+ .xlate = irq_domain_xlate_onecell,
+};
+
+static int mvebu_pcie_init_irq_domain(struct mvebu_pcie_port *port)
+{
+ struct device *dev = &port->pcie->pdev->dev;
+ struct device_node *pcie_intc_node;
+
+ raw_spin_lock_init(&port->irq_lock);
+
+ pcie_intc_node = of_get_next_child(port->dn, NULL);
+ if (!pcie_intc_node) {
+ dev_err(dev, "No PCIe Intc node found for %s\n", port->name);
+ return -ENODEV;
+ }
+
+ port->intx_irq_domain = irq_domain_add_linear(pcie_intc_node, PCI_NUM_INTX,
+ &mvebu_pcie_intx_irq_domain_ops,
+ port);
+ of_node_put(pcie_intc_node);
+ if (!port->intx_irq_domain) {
+ dev_err(dev, "Failed to get INTx IRQ domain for %s\n", port->name);
+ return -ENOMEM;
+ }
+
+ return 0;
+}
+
+static void mvebu_pcie_irq_handler(struct irq_desc *desc)
+{
+ struct mvebu_pcie_port *port = irq_desc_get_handler_data(desc);
+ struct irq_chip *chip = irq_desc_get_chip(desc);
+ struct device *dev = &port->pcie->pdev->dev;
+ u32 cause, unmask, status;
+ int i;
+
+ chained_irq_enter(chip, desc);
+
+ cause = mvebu_readl(port, PCIE_INT_CAUSE_OFF);
+ unmask = mvebu_readl(port, PCIE_INT_UNMASK_OFF);
+ status = cause & unmask;
+
+ /* Process legacy INTx interrupts */
+ for (i = 0; i < PCI_NUM_INTX; i++) {
+ if (!(status & PCIE_INT_INTX(i)))
+ continue;
+
+ if (generic_handle_domain_irq(port->intx_irq_domain, i) == -EINVAL)
+ dev_err_ratelimited(dev, "unexpected INT%c IRQ\n", (char)i+'A');
+ }
+
+ chained_irq_exit(chip, desc);
+}
+
static int mvebu_pcie_map_irq(const struct pci_dev *dev, u8 slot, u8 pin)
{
/* Interrupt support on mvebu emulated bridges is not implemented yet */
@@ -1124,6 +1240,21 @@ static int mvebu_pcie_parse_port(struct mvebu_pcie *pcie,
port->io_attr = -1;
}
+ /*
+ * Old DT bindings do not contain "intx" interrupt
+ * so do not fail probing driver when interrupt does not exist.
+ */
+ port->intx_irq = of_irq_get_byname(child, "intx");
+ if (port->intx_irq == -EPROBE_DEFER) {
+ ret = port->intx_irq;
+ goto err;
+ }
+ if (port->intx_irq <= 0) {
+ dev_warn(dev, "%s: legacy INTx interrupts cannot be masked individually, "
+ "%pOF does not contain intx interrupt\n",
+ port->name, child);
+ }
+
reset_gpio = of_get_named_gpio_flags(child, "reset-gpios", 0, &flags);
if (reset_gpio == -EPROBE_DEFER) {
ret = reset_gpio;
@@ -1320,6 +1451,7 @@ static int mvebu_pcie_probe(struct platform_device *pdev)
for (i = 0; i < pcie->nports; i++) {
struct mvebu_pcie_port *port = &pcie->ports[i];
+ int irq = port->intx_irq;
child = port->dn;
if (!child)
@@ -1347,6 +1479,22 @@ static int mvebu_pcie_probe(struct platform_device *pdev)
continue;
}
+ if (irq > 0) {
+ ret = mvebu_pcie_init_irq_domain(port);
+ if (ret) {
+ dev_err(dev, "%s: cannot init irq domain\n",
+ port->name);
+ pci_bridge_emul_cleanup(&port->bridge);
+ devm_iounmap(dev, port->base);
+ port->base = NULL;
+ mvebu_pcie_powerdown(port);
+ continue;
+ }
+ irq_set_chained_handler_and_data(irq,
+ mvebu_pcie_irq_handler,
+ port);
+ }
+
/*
* PCIe topology exported by mvebu hw is quite complicated. In
* reality has something like N fully independent host bridges
@@ -1450,6 +1598,7 @@ static int mvebu_pcie_remove(struct platform_device *pdev)
for (i = 0; i < pcie->nports; i++) {
struct mvebu_pcie_port *port = &pcie->ports[i];
+ int irq = port->intx_irq;
if (!port->base)
continue;
@@ -1462,6 +1611,16 @@ static int mvebu_pcie_remove(struct platform_device *pdev)
/* Mask all interrupt sources. */
mvebu_writel(port, ~PCIE_INT_ALL_MASK, PCIE_INT_UNMASK_OFF);
+ /* Clear all interrupt causes. */
+ mvebu_writel(port, ~PCIE_INT_ALL_MASK, PCIE_INT_CAUSE_OFF);
+
+ if (irq > 0)
+ irq_set_chained_handler_and_data(irq, NULL, NULL);
+
+ /* Remove IRQ domains. */
+ if (port->intx_irq_domain)
+ irq_domain_remove(port->intx_irq_domain);
+
/* Free config space for emulated root bridge. */
pci_bridge_emul_cleanup(&port->bridge);
--
2.20.1
^ permalink raw reply related [flat|nested] 26+ messages in thread* Re: [PATCH v4 11/12] PCI: mvebu: Implement support for legacy INTx interrupts
2022-02-22 15:50 ` [PATCH v4 11/12] PCI: mvebu: Implement support for legacy INTx interrupts Pali Rohár
@ 2022-02-25 0:26 ` Bjorn Helgaas
0 siblings, 0 replies; 26+ messages in thread
From: Bjorn Helgaas @ 2022-02-25 0:26 UTC (permalink / raw)
To: Pali Rohár
Cc: Lorenzo Pieralisi, Bjorn Helgaas, Rob Herring, Thomas Petazzoni,
Krzysztof Wilczyński, Marek Behún, Russell King,
linux-pci, linux-kernel, linux-arm-kernel
On Tue, Feb 22, 2022 at 04:50:29PM +0100, Pali Rohár wrote:
> This adds support for legacy INTx interrupts received from other PCIe
> devices and which are reported by a new INTx irq chip.
> ...
> + port->intx_irq_domain = irq_domain_add_linear(pcie_intc_node, PCI_NUM_INTX,
> + &mvebu_pcie_intx_irq_domain_ops,
> + port);
Already merged, so no need to change this, but in the future, can you
wrap to fit in 80 columns like the rest of the file?
> + if (port->intx_irq <= 0) {
> + dev_warn(dev, "%s: legacy INTx interrupts cannot be masked individually, "
> + "%pOF does not contain intx interrupt\n",
This is one exception: generally I think quoted strings, especially in
log messages users might see, should be joined no matter how long it
makes the line so they are easier to grep for.
^ permalink raw reply [flat|nested] 26+ messages in thread
* [PATCH v4 12/12] ARM: dts: armada-385.dtsi: Add definitions for PCIe legacy INTx interrupts
2022-02-22 15:50 [PATCH v4 00/12] PCI: mvebu: subsystem ids, AER and INTx Pali Rohár
` (10 preceding siblings ...)
2022-02-22 15:50 ` [PATCH v4 11/12] PCI: mvebu: Implement support for legacy INTx interrupts Pali Rohár
@ 2022-02-22 15:50 ` Pali Rohár
2022-02-22 16:06 ` (subset) [PATCH v4 00/12] PCI: mvebu: subsystem ids, AER and INTx Lorenzo Pieralisi
12 siblings, 0 replies; 26+ messages in thread
From: Pali Rohár @ 2022-02-22 15:50 UTC (permalink / raw)
To: Lorenzo Pieralisi, Bjorn Helgaas, Rob Herring, Thomas Petazzoni,
Krzysztof Wilczyński, Marek Behún, Russell King
Cc: linux-pci, linux-kernel, linux-arm-kernel
With this change legacy INTA, INTB, INTC and INTD interrupts are reported
separately and not mixed into one Linux virq source anymore.
Signed-off-by: Pali Rohár <pali@kernel.org>
Acked-by: Gregory CLEMENT <gregory.clement@bootlin.com>
Tested-by: Luis Mendes <luis.p.mendes@gmail.com>
---
arch/arm/boot/dts/armada-385.dtsi | 52 ++++++++++++++++++++++++++-----
1 file changed, 44 insertions(+), 8 deletions(-)
diff --git a/arch/arm/boot/dts/armada-385.dtsi b/arch/arm/boot/dts/armada-385.dtsi
index f0022d10c715..83392b92dae2 100644
--- a/arch/arm/boot/dts/armada-385.dtsi
+++ b/arch/arm/boot/dts/armada-385.dtsi
@@ -69,16 +69,25 @@
reg = <0x0800 0 0 0 0>;
#address-cells = <3>;
#size-cells = <2>;
+ interrupt-names = "intx";
+ interrupts-extended = <&gic GIC_SPI 29 IRQ_TYPE_LEVEL_HIGH>;
#interrupt-cells = <1>;
ranges = <0x82000000 0 0 0x82000000 0x1 0 1 0
0x81000000 0 0 0x81000000 0x1 0 1 0>;
bus-range = <0x00 0xff>;
- interrupt-map-mask = <0 0 0 0>;
- interrupt-map = <0 0 0 0 &gic GIC_SPI 29 IRQ_TYPE_LEVEL_HIGH>;
+ interrupt-map-mask = <0 0 0 7>;
+ interrupt-map = <0 0 0 1 &pcie1_intc 0>,
+ <0 0 0 2 &pcie1_intc 1>,
+ <0 0 0 3 &pcie1_intc 2>,
+ <0 0 0 4 &pcie1_intc 3>;
marvell,pcie-port = <0>;
marvell,pcie-lane = <0>;
clocks = <&gateclk 8>;
status = "disabled";
+ pcie1_intc: interrupt-controller {
+ interrupt-controller;
+ #interrupt-cells = <1>;
+ };
};
/* x1 port */
@@ -88,16 +97,25 @@
reg = <0x1000 0 0 0 0>;
#address-cells = <3>;
#size-cells = <2>;
+ interrupt-names = "intx";
+ interrupts-extended = <&gic GIC_SPI 33 IRQ_TYPE_LEVEL_HIGH>;
#interrupt-cells = <1>;
ranges = <0x82000000 0 0 0x82000000 0x2 0 1 0
0x81000000 0 0 0x81000000 0x2 0 1 0>;
bus-range = <0x00 0xff>;
- interrupt-map-mask = <0 0 0 0>;
- interrupt-map = <0 0 0 0 &gic GIC_SPI 33 IRQ_TYPE_LEVEL_HIGH>;
+ interrupt-map-mask = <0 0 0 7>;
+ interrupt-map = <0 0 0 1 &pcie2_intc 0>,
+ <0 0 0 2 &pcie2_intc 1>,
+ <0 0 0 3 &pcie2_intc 2>,
+ <0 0 0 4 &pcie2_intc 3>;
marvell,pcie-port = <1>;
marvell,pcie-lane = <0>;
clocks = <&gateclk 5>;
status = "disabled";
+ pcie2_intc: interrupt-controller {
+ interrupt-controller;
+ #interrupt-cells = <1>;
+ };
};
/* x1 port */
@@ -107,16 +125,25 @@
reg = <0x1800 0 0 0 0>;
#address-cells = <3>;
#size-cells = <2>;
+ interrupt-names = "intx";
+ interrupts-extended = <&gic GIC_SPI 70 IRQ_TYPE_LEVEL_HIGH>;
#interrupt-cells = <1>;
ranges = <0x82000000 0 0 0x82000000 0x3 0 1 0
0x81000000 0 0 0x81000000 0x3 0 1 0>;
bus-range = <0x00 0xff>;
- interrupt-map-mask = <0 0 0 0>;
- interrupt-map = <0 0 0 0 &gic GIC_SPI 70 IRQ_TYPE_LEVEL_HIGH>;
+ interrupt-map-mask = <0 0 0 7>;
+ interrupt-map = <0 0 0 1 &pcie3_intc 0>,
+ <0 0 0 2 &pcie3_intc 1>,
+ <0 0 0 3 &pcie3_intc 2>,
+ <0 0 0 4 &pcie3_intc 3>;
marvell,pcie-port = <2>;
marvell,pcie-lane = <0>;
clocks = <&gateclk 6>;
status = "disabled";
+ pcie3_intc: interrupt-controller {
+ interrupt-controller;
+ #interrupt-cells = <1>;
+ };
};
/*
@@ -129,16 +156,25 @@
reg = <0x2000 0 0 0 0>;
#address-cells = <3>;
#size-cells = <2>;
+ interrupt-names = "intx";
+ interrupts-extended = <&gic GIC_SPI 71 IRQ_TYPE_LEVEL_HIGH>;
#interrupt-cells = <1>;
ranges = <0x82000000 0 0 0x82000000 0x4 0 1 0
0x81000000 0 0 0x81000000 0x4 0 1 0>;
bus-range = <0x00 0xff>;
- interrupt-map-mask = <0 0 0 0>;
- interrupt-map = <0 0 0 0 &gic GIC_SPI 71 IRQ_TYPE_LEVEL_HIGH>;
+ interrupt-map-mask = <0 0 0 7>;
+ interrupt-map = <0 0 0 1 &pcie4_intc 0>,
+ <0 0 0 2 &pcie4_intc 1>,
+ <0 0 0 3 &pcie4_intc 2>,
+ <0 0 0 4 &pcie4_intc 3>;
marvell,pcie-port = <3>;
marvell,pcie-lane = <0>;
clocks = <&gateclk 7>;
status = "disabled";
+ pcie4_intc: interrupt-controller {
+ interrupt-controller;
+ #interrupt-cells = <1>;
+ };
};
};
};
--
2.20.1
^ permalink raw reply related [flat|nested] 26+ messages in thread* Re: (subset) [PATCH v4 00/12] PCI: mvebu: subsystem ids, AER and INTx
2022-02-22 15:50 [PATCH v4 00/12] PCI: mvebu: subsystem ids, AER and INTx Pali Rohár
` (11 preceding siblings ...)
2022-02-22 15:50 ` [PATCH v4 12/12] ARM: dts: armada-385.dtsi: Add definitions for PCIe " Pali Rohár
@ 2022-02-22 16:06 ` Lorenzo Pieralisi
2022-02-22 16:11 ` Pali Rohár
12 siblings, 1 reply; 26+ messages in thread
From: Lorenzo Pieralisi @ 2022-02-22 16:06 UTC (permalink / raw)
To: Russell King, Bjorn Helgaas, Thomas Petazzoni, Marek Behún,
Krzysztof Wilczyński, Pali Rohár, Rob Herring
Cc: Lorenzo Pieralisi, linux-pci, linux-kernel, linux-arm-kernel
On Tue, 22 Feb 2022 16:50:18 +0100, Pali Rohár wrote:
> This patch series extends pci-bridge-emul.c driver to emulate PCI Subsystem
> Vendor ID capability and PCIe extended capabilities. And then implement
> in pci-mvebu.c driver support for PCI Subsystem Vendor IDs, PCIe AER
> registers, support for legacy INTx interrupts, configuration for X1/X4
> mode and usage of new PCI child_ops API.
>
> Changes in v4:
> * rebased on c3bd7dc553eea5a3595ca3aa0adee9bf83622a1f
>
> [...]
I can't apply dts changes, patch 12 should go via the arm-soc tree.
Applied the others to pci/mvebu, thanks.
[01/12] PCI: pci-bridge-emul: Re-arrange register tests
https://git.kernel.org/lpieralisi/pci/c/c453bf6f9b
[02/12] PCI: pci-bridge-emul: Add support for PCIe extended capabilities
https://git.kernel.org/lpieralisi/pci/c/c0bd419732
[03/12] PCI: pci-bridge-emul: Add support for PCI Bridge Subsystem Vendor ID capability
https://git.kernel.org/lpieralisi/pci/c/3767a90242
[04/12] dt-bindings: PCI: mvebu: Add num-lanes property
https://git.kernel.org/lpieralisi/pci/c/26b982ca83
[05/12] PCI: mvebu: Correctly configure x1/x4 mode
https://git.kernel.org/lpieralisi/pci/c/2a81dd9fd9
[06/12] PCI: mvebu: Add support for PCI Bridge Subsystem Vendor ID on emulated bridge
https://git.kernel.org/lpieralisi/pci/c/e3e13c9135
[07/12] PCI: mvebu: Add support for Advanced Error Reporting registers on emulated bridge
https://git.kernel.org/lpieralisi/pci/c/2b6ee04c0a
[08/12] PCI: mvebu: Use child_ops API
https://git.kernel.org/lpieralisi/pci/c/c099c2a761
[09/12] dt-bindings: PCI: mvebu: Update information about intx interrupts
https://git.kernel.org/lpieralisi/pci/c/0124989220
[10/12] PCI: mvebu: Fix macro names and comments about legacy interrupts
https://git.kernel.org/lpieralisi/pci/c/d00ea94e62
[11/12] PCI: mvebu: Implement support for legacy INTx interrupts
https://git.kernel.org/lpieralisi/pci/c/ec07526264
Thanks,
Lorenzo
^ permalink raw reply [flat|nested] 26+ messages in thread* Re: (subset) [PATCH v4 00/12] PCI: mvebu: subsystem ids, AER and INTx
2022-02-22 16:06 ` (subset) [PATCH v4 00/12] PCI: mvebu: subsystem ids, AER and INTx Lorenzo Pieralisi
@ 2022-02-22 16:11 ` Pali Rohár
2022-02-22 16:15 ` Lorenzo Pieralisi
0 siblings, 1 reply; 26+ messages in thread
From: Pali Rohár @ 2022-02-22 16:11 UTC (permalink / raw)
To: Lorenzo Pieralisi
Cc: Russell King, Bjorn Helgaas, Thomas Petazzoni, Marek Behún,
Krzysztof Wilczyński, Rob Herring, linux-pci, linux-kernel,
linux-arm-kernel
On Tuesday 22 February 2022 16:06:20 Lorenzo Pieralisi wrote:
> On Tue, 22 Feb 2022 16:50:18 +0100, Pali Rohár wrote:
> > This patch series extends pci-bridge-emul.c driver to emulate PCI Subsystem
> > Vendor ID capability and PCIe extended capabilities. And then implement
> > in pci-mvebu.c driver support for PCI Subsystem Vendor IDs, PCIe AER
> > registers, support for legacy INTx interrupts, configuration for X1/X4
> > mode and usage of new PCI child_ops API.
> >
> > Changes in v4:
> > * rebased on c3bd7dc553eea5a3595ca3aa0adee9bf83622a1f
> >
> > [...]
>
> I can't apply dts changes, patch 12 should go via the arm-soc tree.
Gregory already wrote about this dts change:
https://lore.kernel.org/linux-pci/87tud1jwpr.fsf@BL-laptop/
"So the easier is to let merge it through the PCI subsystem with the
other patches from this series."
Are there any issues with applying this dts change via pci tree?
> Applied the others to pci/mvebu, thanks.
>
> [01/12] PCI: pci-bridge-emul: Re-arrange register tests
> https://git.kernel.org/lpieralisi/pci/c/c453bf6f9b
> [02/12] PCI: pci-bridge-emul: Add support for PCIe extended capabilities
> https://git.kernel.org/lpieralisi/pci/c/c0bd419732
> [03/12] PCI: pci-bridge-emul: Add support for PCI Bridge Subsystem Vendor ID capability
> https://git.kernel.org/lpieralisi/pci/c/3767a90242
> [04/12] dt-bindings: PCI: mvebu: Add num-lanes property
> https://git.kernel.org/lpieralisi/pci/c/26b982ca83
> [05/12] PCI: mvebu: Correctly configure x1/x4 mode
> https://git.kernel.org/lpieralisi/pci/c/2a81dd9fd9
> [06/12] PCI: mvebu: Add support for PCI Bridge Subsystem Vendor ID on emulated bridge
> https://git.kernel.org/lpieralisi/pci/c/e3e13c9135
> [07/12] PCI: mvebu: Add support for Advanced Error Reporting registers on emulated bridge
> https://git.kernel.org/lpieralisi/pci/c/2b6ee04c0a
> [08/12] PCI: mvebu: Use child_ops API
> https://git.kernel.org/lpieralisi/pci/c/c099c2a761
> [09/12] dt-bindings: PCI: mvebu: Update information about intx interrupts
> https://git.kernel.org/lpieralisi/pci/c/0124989220
> [10/12] PCI: mvebu: Fix macro names and comments about legacy interrupts
> https://git.kernel.org/lpieralisi/pci/c/d00ea94e62
> [11/12] PCI: mvebu: Implement support for legacy INTx interrupts
> https://git.kernel.org/lpieralisi/pci/c/ec07526264
>
> Thanks,
> Lorenzo
^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: (subset) [PATCH v4 00/12] PCI: mvebu: subsystem ids, AER and INTx
2022-02-22 16:11 ` Pali Rohár
@ 2022-02-22 16:15 ` Lorenzo Pieralisi
2022-02-22 16:18 ` Pali Rohár
0 siblings, 1 reply; 26+ messages in thread
From: Lorenzo Pieralisi @ 2022-02-22 16:15 UTC (permalink / raw)
To: Pali Rohár
Cc: Russell King, Bjorn Helgaas, Thomas Petazzoni, Marek Behún,
Krzysztof Wilczyński, Rob Herring, linux-pci, linux-kernel,
linux-arm-kernel
On Tue, Feb 22, 2022 at 05:11:43PM +0100, Pali Rohár wrote:
> On Tuesday 22 February 2022 16:06:20 Lorenzo Pieralisi wrote:
> > On Tue, 22 Feb 2022 16:50:18 +0100, Pali Rohár wrote:
> > > This patch series extends pci-bridge-emul.c driver to emulate PCI Subsystem
> > > Vendor ID capability and PCIe extended capabilities. And then implement
> > > in pci-mvebu.c driver support for PCI Subsystem Vendor IDs, PCIe AER
> > > registers, support for legacy INTx interrupts, configuration for X1/X4
> > > mode and usage of new PCI child_ops API.
> > >
> > > Changes in v4:
> > > * rebased on c3bd7dc553eea5a3595ca3aa0adee9bf83622a1f
> > >
> > > [...]
> >
> > I can't apply dts changes, patch 12 should go via the arm-soc tree.
>
> Gregory already wrote about this dts change:
> https://lore.kernel.org/linux-pci/87tud1jwpr.fsf@BL-laptop/
> "So the easier is to let merge it through the PCI subsystem with the
> other patches from this series."
>
> Are there any issues with applying this dts change via pci tree?
I don't usually take dts changes through the PCI tree since they
can conflict with arm-soc, that's the issue - dts changes should
be managed by platform maintainers.
Thanks,
Lorenzo
> > Applied the others to pci/mvebu, thanks.
> >
> > [01/12] PCI: pci-bridge-emul: Re-arrange register tests
> > https://git.kernel.org/lpieralisi/pci/c/c453bf6f9b
> > [02/12] PCI: pci-bridge-emul: Add support for PCIe extended capabilities
> > https://git.kernel.org/lpieralisi/pci/c/c0bd419732
> > [03/12] PCI: pci-bridge-emul: Add support for PCI Bridge Subsystem Vendor ID capability
> > https://git.kernel.org/lpieralisi/pci/c/3767a90242
> > [04/12] dt-bindings: PCI: mvebu: Add num-lanes property
> > https://git.kernel.org/lpieralisi/pci/c/26b982ca83
> > [05/12] PCI: mvebu: Correctly configure x1/x4 mode
> > https://git.kernel.org/lpieralisi/pci/c/2a81dd9fd9
> > [06/12] PCI: mvebu: Add support for PCI Bridge Subsystem Vendor ID on emulated bridge
> > https://git.kernel.org/lpieralisi/pci/c/e3e13c9135
> > [07/12] PCI: mvebu: Add support for Advanced Error Reporting registers on emulated bridge
> > https://git.kernel.org/lpieralisi/pci/c/2b6ee04c0a
> > [08/12] PCI: mvebu: Use child_ops API
> > https://git.kernel.org/lpieralisi/pci/c/c099c2a761
> > [09/12] dt-bindings: PCI: mvebu: Update information about intx interrupts
> > https://git.kernel.org/lpieralisi/pci/c/0124989220
> > [10/12] PCI: mvebu: Fix macro names and comments about legacy interrupts
> > https://git.kernel.org/lpieralisi/pci/c/d00ea94e62
> > [11/12] PCI: mvebu: Implement support for legacy INTx interrupts
> > https://git.kernel.org/lpieralisi/pci/c/ec07526264
> >
> > Thanks,
> > Lorenzo
^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: (subset) [PATCH v4 00/12] PCI: mvebu: subsystem ids, AER and INTx
2022-02-22 16:15 ` Lorenzo Pieralisi
@ 2022-02-22 16:18 ` Pali Rohár
2022-02-28 16:11 ` Gregory CLEMENT
0 siblings, 1 reply; 26+ messages in thread
From: Pali Rohár @ 2022-02-22 16:18 UTC (permalink / raw)
To: Gregory CLEMENT
Cc: Lorenzo Pieralisi, Russell King, Bjorn Helgaas, Thomas Petazzoni,
Marek Behún, Krzysztof Wilczyński, Rob Herring,
linux-pci, linux-kernel, linux-arm-kernel
+ Gregory
On Tuesday 22 February 2022 16:15:39 Lorenzo Pieralisi wrote:
> On Tue, Feb 22, 2022 at 05:11:43PM +0100, Pali Rohár wrote:
> > On Tuesday 22 February 2022 16:06:20 Lorenzo Pieralisi wrote:
> > > On Tue, 22 Feb 2022 16:50:18 +0100, Pali Rohár wrote:
> > > > This patch series extends pci-bridge-emul.c driver to emulate PCI Subsystem
> > > > Vendor ID capability and PCIe extended capabilities. And then implement
> > > > in pci-mvebu.c driver support for PCI Subsystem Vendor IDs, PCIe AER
> > > > registers, support for legacy INTx interrupts, configuration for X1/X4
> > > > mode and usage of new PCI child_ops API.
> > > >
> > > > Changes in v4:
> > > > * rebased on c3bd7dc553eea5a3595ca3aa0adee9bf83622a1f
> > > >
> > > > [...]
> > >
> > > I can't apply dts changes, patch 12 should go via the arm-soc tree.
> >
> > Gregory already wrote about this dts change:
> > https://lore.kernel.org/linux-pci/87tud1jwpr.fsf@BL-laptop/
> > "So the easier is to let merge it through the PCI subsystem with the
> > other patches from this series."
> >
> > Are there any issues with applying this dts change via pci tree?
>
> I don't usually take dts changes through the PCI tree since they
> can conflict with arm-soc, that's the issue - dts changes should
> be managed by platform maintainers.
Gregory, could you please take patch 12/12?
https://lore.kernel.org/linux-pci/20220222155030.988-13-pali@kernel.org/
You have already Acked-by (see above previous link)
> Thanks,
> Lorenzo
>
> > > Applied the others to pci/mvebu, thanks.
> > >
> > > [01/12] PCI: pci-bridge-emul: Re-arrange register tests
> > > https://git.kernel.org/lpieralisi/pci/c/c453bf6f9b
> > > [02/12] PCI: pci-bridge-emul: Add support for PCIe extended capabilities
> > > https://git.kernel.org/lpieralisi/pci/c/c0bd419732
> > > [03/12] PCI: pci-bridge-emul: Add support for PCI Bridge Subsystem Vendor ID capability
> > > https://git.kernel.org/lpieralisi/pci/c/3767a90242
> > > [04/12] dt-bindings: PCI: mvebu: Add num-lanes property
> > > https://git.kernel.org/lpieralisi/pci/c/26b982ca83
> > > [05/12] PCI: mvebu: Correctly configure x1/x4 mode
> > > https://git.kernel.org/lpieralisi/pci/c/2a81dd9fd9
> > > [06/12] PCI: mvebu: Add support for PCI Bridge Subsystem Vendor ID on emulated bridge
> > > https://git.kernel.org/lpieralisi/pci/c/e3e13c9135
> > > [07/12] PCI: mvebu: Add support for Advanced Error Reporting registers on emulated bridge
> > > https://git.kernel.org/lpieralisi/pci/c/2b6ee04c0a
> > > [08/12] PCI: mvebu: Use child_ops API
> > > https://git.kernel.org/lpieralisi/pci/c/c099c2a761
> > > [09/12] dt-bindings: PCI: mvebu: Update information about intx interrupts
> > > https://git.kernel.org/lpieralisi/pci/c/0124989220
> > > [10/12] PCI: mvebu: Fix macro names and comments about legacy interrupts
> > > https://git.kernel.org/lpieralisi/pci/c/d00ea94e62
> > > [11/12] PCI: mvebu: Implement support for legacy INTx interrupts
> > > https://git.kernel.org/lpieralisi/pci/c/ec07526264
> > >
> > > Thanks,
> > > Lorenzo
^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: (subset) [PATCH v4 00/12] PCI: mvebu: subsystem ids, AER and INTx
2022-02-22 16:18 ` Pali Rohár
@ 2022-02-28 16:11 ` Gregory CLEMENT
2022-02-28 17:03 ` Rob Herring
0 siblings, 1 reply; 26+ messages in thread
From: Gregory CLEMENT @ 2022-02-28 16:11 UTC (permalink / raw)
To: Pali Rohár
Cc: Lorenzo Pieralisi, Russell King, Bjorn Helgaas, Thomas Petazzoni,
Marek Behún, Krzysztof Wilczyński, Rob Herring,
linux-pci, linux-kernel, linux-arm-kernel
Hello,
> + Gregory
>
> On Tuesday 22 February 2022 16:15:39 Lorenzo Pieralisi wrote:
>> On Tue, Feb 22, 2022 at 05:11:43PM +0100, Pali Rohár wrote:
>> > On Tuesday 22 February 2022 16:06:20 Lorenzo Pieralisi wrote:
>> > > On Tue, 22 Feb 2022 16:50:18 +0100, Pali Rohár wrote:
>> > > > This patch series extends pci-bridge-emul.c driver to emulate PCI Subsystem
>> > > > Vendor ID capability and PCIe extended capabilities. And then implement
>> > > > in pci-mvebu.c driver support for PCI Subsystem Vendor IDs, PCIe AER
>> > > > registers, support for legacy INTx interrupts, configuration for X1/X4
>> > > > mode and usage of new PCI child_ops API.
>> > > >
>> > > > Changes in v4:
>> > > > * rebased on c3bd7dc553eea5a3595ca3aa0adee9bf83622a1f
>> > > >
>> > > > [...]
>> > >
>> > > I can't apply dts changes, patch 12 should go via the arm-soc tree.
>> >
>> > Gregory already wrote about this dts change:
>> > https://lore.kernel.org/linux-pci/87tud1jwpr.fsf@BL-laptop/
>> > "So the easier is to let merge it through the PCI subsystem with the
>> > other patches from this series."
>> >
>> > Are there any issues with applying this dts change via pci tree?
>>
>> I don't usually take dts changes through the PCI tree since they
>> can conflict with arm-soc, that's the issue - dts changes should
>> be managed by platform maintainers.
>
> Gregory, could you please take patch 12/12?
> https://lore.kernel.org/linux-pci/20220222155030.988-13-pali@kernel.org/
> You have already Acked-by (see above previous link)
Applied on mvebu/dt
let's hope the PCI branch will be merged before the ARM branch.
Thanks,
Gregory
>
>> Thanks,
>> Lorenzo
>>
>> > > Applied the others to pci/mvebu, thanks.
>> > >
>> > > [01/12] PCI: pci-bridge-emul: Re-arrange register tests
>> > > https://git.kernel.org/lpieralisi/pci/c/c453bf6f9b
>> > > [02/12] PCI: pci-bridge-emul: Add support for PCIe extended capabilities
>> > > https://git.kernel.org/lpieralisi/pci/c/c0bd419732
>> > > [03/12] PCI: pci-bridge-emul: Add support for PCI Bridge Subsystem Vendor ID capability
>> > > https://git.kernel.org/lpieralisi/pci/c/3767a90242
>> > > [04/12] dt-bindings: PCI: mvebu: Add num-lanes property
>> > > https://git.kernel.org/lpieralisi/pci/c/26b982ca83
>> > > [05/12] PCI: mvebu: Correctly configure x1/x4 mode
>> > > https://git.kernel.org/lpieralisi/pci/c/2a81dd9fd9
>> > > [06/12] PCI: mvebu: Add support for PCI Bridge Subsystem Vendor ID on emulated bridge
>> > > https://git.kernel.org/lpieralisi/pci/c/e3e13c9135
>> > > [07/12] PCI: mvebu: Add support for Advanced Error Reporting registers on emulated bridge
>> > > https://git.kernel.org/lpieralisi/pci/c/2b6ee04c0a
>> > > [08/12] PCI: mvebu: Use child_ops API
>> > > https://git.kernel.org/lpieralisi/pci/c/c099c2a761
>> > > [09/12] dt-bindings: PCI: mvebu: Update information about intx interrupts
>> > > https://git.kernel.org/lpieralisi/pci/c/0124989220
>> > > [10/12] PCI: mvebu: Fix macro names and comments about legacy interrupts
>> > > https://git.kernel.org/lpieralisi/pci/c/d00ea94e62
>> > > [11/12] PCI: mvebu: Implement support for legacy INTx interrupts
>> > > https://git.kernel.org/lpieralisi/pci/c/ec07526264
>> > >
>> > > Thanks,
>> > > Lorenzo
--
Gregory Clement, Bootlin
Embedded Linux and Kernel engineering
http://bootlin.com
^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: (subset) [PATCH v4 00/12] PCI: mvebu: subsystem ids, AER and INTx
2022-02-28 16:11 ` Gregory CLEMENT
@ 2022-02-28 17:03 ` Rob Herring
2022-03-01 13:47 ` Gregory CLEMENT
0 siblings, 1 reply; 26+ messages in thread
From: Rob Herring @ 2022-02-28 17:03 UTC (permalink / raw)
To: Gregory CLEMENT
Cc: Pali Rohár, Lorenzo Pieralisi, Russell King, Bjorn Helgaas,
Thomas Petazzoni, Marek Behún, Krzysztof Wilczyński,
PCI, linux-kernel, linux-arm-kernel
On Mon, Feb 28, 2022 at 10:11 AM Gregory CLEMENT
<gregory.clement@bootlin.com> wrote:
>
> Hello,
>
> > + Gregory
> >
> > On Tuesday 22 February 2022 16:15:39 Lorenzo Pieralisi wrote:
> >> On Tue, Feb 22, 2022 at 05:11:43PM +0100, Pali Rohár wrote:
> >> > On Tuesday 22 February 2022 16:06:20 Lorenzo Pieralisi wrote:
> >> > > On Tue, 22 Feb 2022 16:50:18 +0100, Pali Rohár wrote:
> >> > > > This patch series extends pci-bridge-emul.c driver to emulate PCI Subsystem
> >> > > > Vendor ID capability and PCIe extended capabilities. And then implement
> >> > > > in pci-mvebu.c driver support for PCI Subsystem Vendor IDs, PCIe AER
> >> > > > registers, support for legacy INTx interrupts, configuration for X1/X4
> >> > > > mode and usage of new PCI child_ops API.
> >> > > >
> >> > > > Changes in v4:
> >> > > > * rebased on c3bd7dc553eea5a3595ca3aa0adee9bf83622a1f
> >> > > >
> >> > > > [...]
> >> > >
> >> > > I can't apply dts changes, patch 12 should go via the arm-soc tree.
> >> >
> >> > Gregory already wrote about this dts change:
> >> > https://lore.kernel.org/linux-pci/87tud1jwpr.fsf@BL-laptop/
> >> > "So the easier is to let merge it through the PCI subsystem with the
> >> > other patches from this series."
> >> >
> >> > Are there any issues with applying this dts change via pci tree?
> >>
> >> I don't usually take dts changes through the PCI tree since they
> >> can conflict with arm-soc, that's the issue - dts changes should
> >> be managed by platform maintainers.
> >
> > Gregory, could you please take patch 12/12?
> > https://lore.kernel.org/linux-pci/20220222155030.988-13-pali@kernel.org/
> > You have already Acked-by (see above previous link)
>
>
> Applied on mvebu/dt
>
> let's hope the PCI branch will be merged before the ARM branch.
Why does that matter? AIUI, legacy interrupts didn't work before and
you need both dt and kernel to enable. Or am I misled by the commit
messages?
Rob
^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: (subset) [PATCH v4 00/12] PCI: mvebu: subsystem ids, AER and INTx
2022-02-28 17:03 ` Rob Herring
@ 2022-03-01 13:47 ` Gregory CLEMENT
0 siblings, 0 replies; 26+ messages in thread
From: Gregory CLEMENT @ 2022-03-01 13:47 UTC (permalink / raw)
To: Rob Herring
Cc: Pali Rohár, Lorenzo Pieralisi, Russell King, Bjorn Helgaas,
Thomas Petazzoni, Marek Behún, Krzysztof Wilczyński,
PCI, linux-kernel, linux-arm-kernel
Hello Rob,
> On Mon, Feb 28, 2022 at 10:11 AM Gregory CLEMENT
> <gregory.clement@bootlin.com> wrote:
>>
>> Hello,
>>
>> > + Gregory
>> >
>> > On Tuesday 22 February 2022 16:15:39 Lorenzo Pieralisi wrote:
>> >> On Tue, Feb 22, 2022 at 05:11:43PM +0100, Pali Rohár wrote:
>> >> > On Tuesday 22 February 2022 16:06:20 Lorenzo Pieralisi wrote:
>> >> > > On Tue, 22 Feb 2022 16:50:18 +0100, Pali Rohár wrote:
>> >> > > > This patch series extends pci-bridge-emul.c driver to emulate PCI Subsystem
>> >> > > > Vendor ID capability and PCIe extended capabilities. And then implement
>> >> > > > in pci-mvebu.c driver support for PCI Subsystem Vendor IDs, PCIe AER
>> >> > > > registers, support for legacy INTx interrupts, configuration for X1/X4
>> >> > > > mode and usage of new PCI child_ops API.
>> >> > > >
>> >> > > > Changes in v4:
>> >> > > > * rebased on c3bd7dc553eea5a3595ca3aa0adee9bf83622a1f
>> >> > > >
>> >> > > > [...]
>> >> > >
>> >> > > I can't apply dts changes, patch 12 should go via the arm-soc tree.
>> >> >
>> >> > Gregory already wrote about this dts change:
>> >> > https://lore.kernel.org/linux-pci/87tud1jwpr.fsf@BL-laptop/
>> >> > "So the easier is to let merge it through the PCI subsystem with the
>> >> > other patches from this series."
>> >> >
>> >> > Are there any issues with applying this dts change via pci tree?
>> >>
>> >> I don't usually take dts changes through the PCI tree since they
>> >> can conflict with arm-soc, that's the issue - dts changes should
>> >> be managed by platform maintainers.
>> >
>> > Gregory, could you please take patch 12/12?
>> > https://lore.kernel.org/linux-pci/20220222155030.988-13-pali@kernel.org/
>> > You have already Acked-by (see above previous link)
>>
>>
>> Applied on mvebu/dt
>>
>> let's hope the PCI branch will be merged before the ARM branch.
>
> Why does that matter? AIUI, legacy interrupts didn't work before and
> you need both dt and kernel to enable. Or am I misled by the commit
> messages?
Indeed I went too fast, so all should be fine.
Gregory
>
> Rob
--
Gregory Clement, Bootlin
Embedded Linux and Kernel engineering
http://bootlin.com
^ permalink raw reply [flat|nested] 26+ messages in thread