PCI: mvebu: subsystem ids, AER and INTx
Subsystems (4)
Pali Rohár
maintainerv4 cover PCI: mvebu: subsystem ids, AER and INTx
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
Changes in v3:
* add Marek's Reviewed-by for first two patches
* split comments from "PCI: mvebu: Implement support for legacy INTx interrupts" patch into separate patch
Changes in v2:
* use static structures for INTx interrupts
* remove INTx domain after unregistering INTx handler
Pali Rohár (10):
PCI: pci-bridge-emul: Add support for PCI Bridge Subsystem Vendor ID
capability
dt-bindings: PCI: mvebu: Add num-lanes property
PCI: mvebu: Correctly configure x1/x4 mode
PCI: mvebu: Add support for PCI Bridge Subsystem Vendor ID on emulated
bridge
PCI: mvebu: Add support for Advanced Error Reporting registers on
emulated bridge
PCI: mvebu: Use child_ops API
dt-bindings: PCI: mvebu: Update information about intx interrupts
PCI: mvebu: Fix macro names and comments about legacy interrupts
PCI: mvebu: Implement support for legacy INTx interrupts
ARM: dts: armada-385.dtsi: Add definitions for PCIe legacy INTx
interrupts
Russell King (2):
PCI: pci-bridge-emul: Re-arrange register tests
PCI: pci-bridge-emul: Add support for PCIe extended capabilities
.../devicetree/bindings/pci/mvebu-pci.txt | 16 + arch/arm/boot/dts/armada-385.dtsi | 52 ++- drivers/pci/controller/pci-mvebu.c | 350 +++++++++++++++--- drivers/pci/pci-bridge-emul.c | 167 ++++++--- drivers/pci/pci-bridge-emul.h | 17 + 5 files changed, 493 insertions(+), 109 deletions(-)
Signature · 1 line
2.20.1
Pali Rohár
maintainerPATCH v4 1/12 PCI: pci-bridge-emul: Re-arrange register tests
From: Russell King <[email protected]>
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.
--- drivers/pci/pci-bridge-emul.c | 61 ++++++++++++++++++----------------- 1 file changed, 31 insertions(+), 30 deletions(-)
drivers/pci/pci-bridge-emul.c +31 -30
@@ -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);
Signature · 1 line
2.20.1
Pali Rohár
maintainerPATCH v4 2/12 PCI: pci-bridge-emul: Add support for PCIe extended capabilities
In reply to Pali RohárFrom: Russell King <[email protected]>
Add support for PCIe extended capabilities, which we just redirect to the emulating driver.
--- drivers/pci/pci-bridge-emul.c | 77 +++++++++++++++++++++++------------ drivers/pci/pci-bridge-emul.h | 15 +++++++ 2 files changed, 67 insertions(+), 25 deletions(-)
drivers/pci/pci-bridge-emul.c +52 -25
@@ -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);
drivers/pci/pci-bridge-emul.h +15 -0
@@ -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 ;
Signature · 1 line
2.20.1
Pali Rohár
maintainerPATCH v4 3/12 PCI: pci-bridge-emul: Add support for PCI Bridge Subsystem Vendor ID capability
In reply to Pali RohárThis 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.
--- drivers/pci/pci-bridge-emul.c | 69 +++++++++++++++++++++++++---------- drivers/pci/pci-bridge-emul.h | 2 + 2 files changed, 51 insertions(+), 20 deletions(-)
drivers/pci/pci-bridge-emul.c +49 -20
@@ -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 ;
drivers/pci/pci-bridge-emul.h +2 -0
@@ -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 {
Signature · 1 line
2.20.1
Pali Rohár
maintainerPATCH v4 4/12 dt-bindings: PCI: mvebu: Add num-lanes property
In reply to Pali RohárController 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.
--- Documentation/devicetree/bindings/pci/mvebu-pci.txt | 11 +++++++++++ 1 file changed, 11 insertions(+)
Documentation/devicetree/bindings/pci/mvebu-pci.txt +11 -0
@@ -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>; }; };
Signature · 1 line
2.20.1
Re: [PATCH v4 04/12] dt-bindings: PCI: mvebu: Add num-lanes property
Quoted 24 lines · Pali Rohár
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 <[email protected]>Acked-by Rob Herring <[email protected]>--- Documentation/devicetree/bindings/pci/mvebu-pci.txt | 11 +++++++++++ 1 file changed, 11 insertions(+)Documentation/devicetree/bindings/pci/mvebu-pci.txt +1
-0@@ -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.
Documentation/devicetree/bindings/pci/mvebu-pci.txt pcie-controller { · line 145
Quoted 4 lines
Documentation/devicetree/bindings/pci/mvebu-pci.txt +1
-0@@ -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
Pali Rohár
maintainerRe: [PATCH v4 04/12] dt-bindings: PCI: mvebu: Add num-lanes property
Quoted 23 lines · On Thursday 24 February 2022 18:02:26 Bjorn Helgaas wrote:
Quoted 22 lines · Pali Rohár
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 <[email protected]>Acked-by Rob Herring <[email protected]>--- Documentation/devicetree/bindings/pci/mvebu-pci.txt | 11 +++++++++++ 1 file changed, 11 insertions(+)Documentation/devicetree/bindings/pci/mvebu-pci.txt +1
-0@@ -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
Quoted 8 lines
Documentation/devicetree/bindings/pci/mvebu-pci.txt pcie-controller { · line 145
Quoted 6 lines
Documentation/devicetree/bindings/pci/mvebu-pci.txt +1
-0specified 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.
Quoted 5 lines
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.
Quoted 5 lines
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...
Re: [PATCH v4 04/12] dt-bindings: PCI: mvebu: Add num-lanes property
Quoted 52 lines · Pali Rohár
Quoted 23 lines · On Thursday 24 February 2022 18:02:26 Bjorn Helgaas wrote:
Quoted 22 lines · Pali Rohár
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 <[email protected]>Acked-by Rob Herring <[email protected]>--- Documentation/devicetree/bindings/pci/mvebu-pci.txt | 11 +++++++++++ 1 file changed, 11 insertions(+)Documentation/devicetree/bindings/pci/mvebu-pci.txt +1
-0@@ -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 notQuoted 8 lines
Documentation/devicetree/bindings/pci/mvebu-pci.txt pcie-controller { · line 145
Quoted 6 lines
Documentation/devicetree/bindings/pci/mvebu-pci.txt +1
-0specified 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.
Quoted 5 lines
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.
Quoted 5 lines
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
Quoted 8 lines
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
Pali Rohár
maintainerPATCH v4 5/12 PCI: mvebu: Correctly configure x1/x4 mode
In reply to Pali RohárIf 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.
--- drivers/pci/controller/pci-mvebu.c | 19 ++++++++++++++++++- 1 file changed, 18 insertions(+), 1 deletion(-)
drivers/pci/controller/pci-mvebu.c +18 -1
@@ -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) {
Signature · 1 line
2.20.1
Re: [PATCH v4 05/12] PCI: mvebu: Correctly configure x1/x4 mode
Quoted 4 lines · Pali Rohár
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/
drivers/pci/controller/pci-mvebu.c static void mvebu_pcie_setup_wins(struct mvebu_pcie_port *port) · line 249
Quoted 5 lines
drivers/pci/controller/pci-mvebu.c +5
-0+* 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.
Quoted 5 lines
drivers/pci/controller/pci-mvebu.c +5
-0+*/ + 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 );
Pali Rohár
maintainerRe: [PATCH v4 05/12] PCI: mvebu: Correctly configure x1/x4 mode
Quoted 9 lines · On Thursday 24 February 2022 18:08:00 Bjorn Helgaas wrote:
Quoted 4 lines · Pali Rohár
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/
Quoted 10 lines
drivers/pci/controller/pci-mvebu.c static void mvebu_pcie_setup_wins(struct mvebu_pcie_port *port) · line 249
Quoted 5 lines
drivers/pci/controller/pci-mvebu.c +5
-0+* 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.
Quoted 5 lines
Quoted 5 lines
drivers/pci/controller/pci-mvebu.c +5
-0+*/ + 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 );
Pali Rohár
maintainerPATCH v4 6/12 PCI: mvebu: Add support for PCI Bridge Subsystem Vendor ID on emulated bridge
In reply to Pali RohárRegister 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
--- drivers/pci/controller/pci-mvebu.c | 4 ++++ 1 file changed, 4 insertions(+)
drivers/pci/controller/pci-mvebu.c +4 -0
@@ -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;
Signature · 1 line
2.20.1
Pali Rohár
maintainerPATCH v4 7/12 PCI: mvebu: Add support for Advanced Error Reporting registers on emulated bridge
In reply to Pali RohárAER 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.
--- drivers/pci/controller/pci-mvebu.c | 67 +++++++++++++++++++++++++++++- 1 file changed, 66 insertions(+), 1 deletion(-)
drivers/pci/controller/pci-mvebu.c +66 -1
@@ -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, };/*
Signature · 1 line
2.20.1
Pali Rohár
maintainerPATCH v4 8/12 PCI: mvebu: Use child_ops API
In reply to Pali RohárSplit 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.
--- drivers/pci/controller/pci-mvebu.c | 77 ++++++++++++++++-------------- 1 file changed, 40 insertions(+), 37 deletions(-)
drivers/pci/controller/pci-mvebu.c +40 -37
@@ -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;
Signature · 1 line
2.20.1
Pali Rohár
maintainerPATCH v4 9/12 dt-bindings: PCI: mvebu: Update information about intx interrupts
In reply to Pali Rohár--- Documentation/devicetree/bindings/pci/mvebu-pci.txt | 5 +++++ 1 file changed, 5 insertions(+)
Documentation/devicetree/bindings/pci/mvebu-pci.txt +5 -0
@@ -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:
Signature · 1 line
2.20.1
Pali Rohár
maintainerPATCH v4 10/12 PCI: mvebu: Fix macro names and comments about legacy interrupts
In reply to Pali RohárRegister 0x1910 unmasks interrupts and legacy INTx interrupts are unmasked because driver does not support individual masking yet.
--- drivers/pci/controller/pci-mvebu.c | 26 ++++++++++++++++++-------- 1 file changed, 18 insertions(+), 8 deletions(-)
drivers/pci/controller/pci-mvebu.c +18 -8
@@ -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);
Signature · 1 line
2.20.1
Pali Rohár
maintainerPATCH v4 11/12 PCI: mvebu: Implement support for legacy INTx interrupts
In reply to Pali RohárThis 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.
--- drivers/pci/controller/pci-mvebu.c | 159 +++++++++++++++++++++++++++++ 1 file changed, 159 insertions(+)
drivers/pci/controller/pci-mvebu.c +159 -0
@@ -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);
Signature · 1 line
2.20.1
Re: [PATCH v4 11/12] PCI: mvebu: Implement support for legacy INTx interrupts
drivers/pci/controller/pci-mvebu.c static struct pci_ops mvebu_pcie_ops = { · line 1010
Quoted 7 lines · Pali Rohár
This adds support for legacy INTx interrupts received from other PCIe devices and which are reported by a new INTx irq chip.
...drivers/pci/controller/pci-mvebu.c +3
-0+ 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?
drivers/pci/controller/pci-mvebu.c static int mvebu_pcie_parse_port(struct mvebu_pcie *pcie, · line 1254
Quoted 3 lines
drivers/pci/controller/pci-mvebu.c +3
-0+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.
Pali Rohár
maintainerPATCH v4 12/12 ARM: dts: armada-385.dtsi: Add definitions for PCIe legacy INTx interrupts
In reply to Pali RohárWith this change legacy INTA, INTB, INTC and INTD interrupts are reported separately and not mixed into one Linux virq source anymore.
--- arch/arm/boot/dts/armada-385.dtsi | 52 ++++++++++++++++++++++++++----- 1 file changed, 44 insertions(+), 8 deletions(-)
arch/arm/boot/dts/armada-385.dtsi +44 -8
@@ -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>; + }; }; }; };
Signature · 1 line
2.20.1
Re: (subset) [PATCH v4 00/12] PCI: mvebu: subsystem ids, AER and INTx
In reply to Pali RohárQuoted 10 lines · Pali Rohár
This patch series extends
pci-bridge-emul.cdriver to emulate PCI Subsystem Vendor ID capability and PCIe extended capabilities. And then implement inpci-mvebu.cdriver support for PCI Subsystem Vendor IDs, PCIe AER registers, support for legacy INTx interrupts, configuration for X1/X4 mode and usage of new PCIchild_opsAPI.Changes in v4:
* rebased onc3bd7dc553eea5a3595ca3aa0adee9bf83622a1f[...]
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
Pali Rohár
maintainerRe: (subset) [PATCH v4 00/12] PCI: mvebu: subsystem ids, AER and INTx
Quoted 7 lines · On Tuesday 22 February 2022 16:06:20 Lorenzo Pieralisi wrote:
Quoted 6 lines · Pali Rohár
This patch series extends
pci-bridge-emul.cdriver to emulate PCI Subsystem Vendor ID capability and PCIe extended capabilities. And then implement inpci-mvebu.cdriver support for PCI Subsystem Vendor IDs, PCIe AER registers, support for legacy INTx interrupts, configuration for X1/X4 mode and usage of new PCIchild_opsAPI.
Quoted 6 lines
Quoted 4 lines
Changes in v4:
* rebased onc3bd7dc553eea5a3595ca3aa0adee9bf83622a1f[...]
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?
Quoted 27 lines
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/ec07526264Thanks,
Lorenzo
Re: (subset) [PATCH v4 00/12] PCI: mvebu: subsystem ids, AER and INTx
Quoted 13 lines · Pali Rohár
Quoted 12 lines · On Tuesday 22 February 2022 16:06:20 Lorenzo Pieralisi wrote:
Quoted 10 lines · Pali Rohár
This patch series extends
pci-bridge-emul.cdriver to emulate PCI Subsystem Vendor ID capability and PCIe extended capabilities. And then implement inpci-mvebu.cdriver support for PCI Subsystem Vendor IDs, PCIe AER registers, support for legacy INTx interrupts, configuration for X1/X4 mode and usage of new PCIchild_opsAPI.Changes in v4:
* rebased onc3bd7dc553eea5a3595ca3aa0adee9bf83622a1f[...]
Quoted 8 lines
Quoted 1 line
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
Quoted 27 lines
Quoted 27 lines
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/ec07526264Thanks,
Lorenzo
Pali Rohár
maintainerRe: (subset) [PATCH v4 00/12] PCI: mvebu: subsystem ids, AER and INTx
+ Gregory
Quoted 21 lines · On Tuesday 22 February 2022 16:15:39 Lorenzo Pieralisi wrote:
Quoted 20 lines · Pali Rohár
Quoted 7 lines · On Tuesday 22 February 2022 16:06:20 Lorenzo Pieralisi wrote:
Quoted 6 lines · Pali Rohár
This patch series extends
pci-bridge-emul.cdriver to emulate PCI Subsystem Vendor ID capability and PCIe extended capabilities. And then implement inpci-mvebu.cdriver support for PCI Subsystem Vendor IDs, PCIe AER registers, support for legacy INTx interrupts, configuration for X1/X4 mode and usage of new PCIchild_opsAPI.Quoted 6 lines
Quoted 4 lines
Changes in v4:
* rebased onc3bd7dc553eea5a3595ca3aa0adee9bf83622a1f[...]
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."
Quoted 5 lines
Quoted 1 line
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/[email protected]/
You have already Acked-by (see above previous link)
Quoted 30 lines
Thanks,
LorenzoQuoted 27 lines
Quoted 27 lines
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/ec07526264Thanks,
Lorenzo
Re: (subset) [PATCH v4 00/12] PCI: mvebu: subsystem ids, AER and INTx
Hello,
Quoted 26 lines
+ Gregory
Quoted 23 lines · On Tuesday 22 February 2022 16:15:39 Lorenzo Pieralisi wrote:
Quoted 21 lines · Pali Rohár
Quoted 7 lines · On Tuesday 22 February 2022 16:06:20 Lorenzo Pieralisi wrote:
Quoted 6 lines · Pali Rohár
This patch series extends
pci-bridge-emul.cdriver to emulate PCI Subsystem Vendor ID capability and PCIe extended capabilities. And then implement inpci-mvebu.cdriver support for PCI Subsystem Vendor IDs, PCIe AER registers, support for legacy INTx interrupts, configuration for X1/X4 mode and usage of new PCIchild_opsAPI.Quoted 6 lines
Quoted 4 lines
Changes in v4:
* rebased onc3bd7dc553eea5a3595ca3aa0adee9bf83622a1f[...]
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?
Quoted 7 lines
Quoted 3 lines
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/[email protected]/
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
Quoted 31 lines
Quoted 31 lines
Thanks,
LorenzoQuoted 27 lines
Quoted 27 lines
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/ec07526264Thanks,
Lorenzo
Signature · 3 lines
Gregory Clement, Bootlin Embedded Linux and Kernel engineering http://bootlin.com
Re: (subset) [PATCH v4 00/12] PCI: mvebu: subsystem ids, AER and INTx
Quoted 33 lines · Gregory CLEMENT
Hello,
Quoted 30 lines
+ Gregory
Quoted 26 lines · On Tuesday 22 February 2022 16:15:39 Lorenzo Pieralisi wrote:
Quoted 13 lines · Pali Rohár
Quoted 12 lines · On Tuesday 22 February 2022 16:06:20 Lorenzo Pieralisi wrote:
Quoted 10 lines · Pali Rohár
This patch series extends
pci-bridge-emul.cdriver to emulate PCI Subsystem Vendor ID capability and PCIe extended capabilities. And then implement inpci-mvebu.cdriver support for PCI Subsystem Vendor IDs, PCIe AER registers, support for legacy INTx interrupts, configuration for X1/X4 mode and usage of new PCIchild_opsAPI.Changes in v4:
* rebased onc3bd7dc553eea5a3595ca3aa0adee9bf83622a1f[...]
Quoted 8 lines
Quoted 1 line
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.
Quoted 8 lines
Quoted 3 lines
Gregory, could you please take patch 12/12?
https://lore.kernel.org/linux-pci/[email protected]/
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
Re: (subset) [PATCH v4 00/12] PCI: mvebu: subsystem ids, AER and INTx
Hello Rob,
Quoted 40 lines
Quoted 38 lines · Gregory CLEMENT
Hello,
Quoted 33 lines
+ Gregory
Quoted 21 lines · On Tuesday 22 February 2022 16:15:39 Lorenzo Pieralisi wrote:
Quoted 20 lines · Pali Rohár
Quoted 7 lines · On Tuesday 22 February 2022 16:06:20 Lorenzo Pieralisi wrote:
Quoted 6 lines · Pali Rohár
This patch series extends
pci-bridge-emul.cdriver to emulate PCI Subsystem Vendor ID capability and PCIe extended capabilities. And then implement inpci-mvebu.cdriver support for PCI Subsystem Vendor IDs, PCIe AER registers, support for legacy INTx interrupts, configuration for X1/X4 mode and usage of new PCIchild_opsAPI.Quoted 6 lines
Quoted 4 lines
Changes in v4:
* rebased onc3bd7dc553eea5a3595ca3aa0adee9bf83622a1f[...]
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."Quoted 5 lines
Quoted 1 line
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/[email protected]/
You have already Acked-by (see above previous link)
Quoted 7 lines
Quoted 3 lines
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
Quoted 2 lines
Rob
Signature · 3 lines
Gregory Clement, Bootlin Embedded Linux and Kernel engineering http://bootlin.com