* [PATCH v6 11/19] dt-bindings: usb: dwc3: Add interrupt-names property support
From: Serge Semin @ 2020-12-10 9:09 UTC (permalink / raw)
To: Mathias Nyman, Felipe Balbi, Krzysztof Kozlowski,
Greg Kroah-Hartman, Rob Herring, Chunfeng Yun
Cc: Neil Armstrong, linux-kernel, Pavel Parkhomenko, Rob Herring,
Kevin Hilman, Ahmad Zainie, Andy Gross, linux-snps-arc,
devicetree, Martin Blumenstingl, Lad Prabhakar, Alexey Malahov,
Bjorn Andersson, linux-arm-kernel, Roger Quadros,
Yoshihiro Shimoda, linux-usb, linux-mips, Serge Semin,
Serge Semin, Manu Gautam, linuxppc-dev
In-Reply-To: <20201210090944.16283-1-Sergey.Semin@baikalelectronics.ru>
The controller driver supports two types of DWC USB3 devices: with a
common interrupt lane and with individual interrupts for each mode. Add
support for both these cases to the DWC USB3 DT schema.
Signed-off-by: Serge Semin <Sergey.Semin@baikalelectronics.ru>
Reviewed-by: Rob Herring <robh@kernel.org>
---
Changelog v2:
- Grammar fix: "s/both of these cases support/support for both these cases"
- Drop quotes from around the string constants.
Changelog v4:
- Discard the block scalar style modifier "|" from the interrupts property
description.
---
Documentation/devicetree/bindings/usb/snps,dwc3.yaml | 11 +++++++++++
1 file changed, 11 insertions(+)
diff --git a/Documentation/devicetree/bindings/usb/snps,dwc3.yaml b/Documentation/devicetree/bindings/usb/snps,dwc3.yaml
index 57caca8339ae..87a92e313d24 100644
--- a/Documentation/devicetree/bindings/usb/snps,dwc3.yaml
+++ b/Documentation/devicetree/bindings/usb/snps,dwc3.yaml
@@ -34,8 +34,19 @@ properties:
const: snps,dwc3
interrupts:
+ description:
+ It's either a single common DWC3 interrupt (dwc_usb3) or individual
+ interrupts for the host, gadget and DRD modes.
+ minItems: 1
+ maxItems: 3
+
+ interrupt-names:
minItems: 1
maxItems: 3
+ oneOf:
+ - const: dwc_usb3
+ - items:
+ enum: [host, peripheral, otg]
clocks:
description:
--
2.29.2
^ permalink raw reply related
* [PATCH v6 13/19] dt-bindings: usb: dwc3: Add Tx De-emphasis constraints
From: Serge Semin @ 2020-12-10 9:09 UTC (permalink / raw)
To: Mathias Nyman, Felipe Balbi, Krzysztof Kozlowski,
Greg Kroah-Hartman, Rob Herring, Chunfeng Yun
Cc: Neil Armstrong, linux-kernel, Pavel Parkhomenko, Rob Herring,
Kevin Hilman, Ahmad Zainie, Andy Gross, linux-snps-arc,
devicetree, Martin Blumenstingl, Lad Prabhakar, Alexey Malahov,
Bjorn Andersson, linux-arm-kernel, Roger Quadros,
Yoshihiro Shimoda, linux-usb, linux-mips, Serge Semin,
Serge Semin, Manu Gautam, linuxppc-dev
In-Reply-To: <20201210090944.16283-1-Sergey.Semin@baikalelectronics.ru>
In accordance with the driver comments the PIPE3 de-emphasis can be tuned
to be either -6dB, -2.5dB or disabled. Let's add the de-emphasis
property constraints so the DT schema would make sure the controller DT
node is equipped with correct value.
Signed-off-by: Serge Semin <Sergey.Semin@baikalelectronics.ru>
Reviewed-by: Rob Herring <robh@kernel.org>
---
Changelog v2:
- Grammar fix: "s/tunned/tuned"
- Grammar fix: remove redundant "or" conjunction.
---
Documentation/devicetree/bindings/usb/snps,dwc3.yaml | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/Documentation/devicetree/bindings/usb/snps,dwc3.yaml b/Documentation/devicetree/bindings/usb/snps,dwc3.yaml
index 6253bc5fb18e..e01a9a93d74a 100644
--- a/Documentation/devicetree/bindings/usb/snps,dwc3.yaml
+++ b/Documentation/devicetree/bindings/usb/snps,dwc3.yaml
@@ -156,6 +156,10 @@ properties:
The value driven to the PHY is controlled by the LTSSM during USB3
Compliance mode.
$ref: /schemas/types.yaml#/definitions/uint8
+ enum:
+ - 0 # -6dB de-emphasis
+ - 1 # -3.5dB de-emphasis
+ - 2 # No de-emphasis
snps,dis_u3_susphy_quirk:
description: When set core will disable USB3 suspend phy
--
2.29.2
^ permalink raw reply related
* [PATCH v6 14/19] dt-bindings: usb: dwc3: Add Frame Length Adj constraints
From: Serge Semin @ 2020-12-10 9:09 UTC (permalink / raw)
To: Mathias Nyman, Felipe Balbi, Krzysztof Kozlowski,
Greg Kroah-Hartman, Rob Herring, Chunfeng Yun
Cc: Neil Armstrong, linux-kernel, Pavel Parkhomenko, Rob Herring,
Kevin Hilman, Ahmad Zainie, Andy Gross, linux-snps-arc,
devicetree, Martin Blumenstingl, Lad Prabhakar, Alexey Malahov,
Bjorn Andersson, linux-arm-kernel, Roger Quadros,
Yoshihiro Shimoda, linux-usb, linux-mips, Serge Semin,
Serge Semin, Manu Gautam, linuxppc-dev
In-Reply-To: <20201210090944.16283-1-Sergey.Semin@baikalelectronics.ru>
In accordance with the IP core databook the
snps,quirk-frame-length-adjustment property can be set within [0, 0x3F].
Let's make sure the DT schema applies a correct constraints on the
property.
Signed-off-by: Serge Semin <Sergey.Semin@baikalelectronics.ru>
Reviewed-by: Rob Herring <robh@kernel.org>
---
Documentation/devicetree/bindings/usb/snps,dwc3.yaml | 2 ++
1 file changed, 2 insertions(+)
diff --git a/Documentation/devicetree/bindings/usb/snps,dwc3.yaml b/Documentation/devicetree/bindings/usb/snps,dwc3.yaml
index e01a9a93d74a..2247da77eac1 100644
--- a/Documentation/devicetree/bindings/usb/snps,dwc3.yaml
+++ b/Documentation/devicetree/bindings/usb/snps,dwc3.yaml
@@ -243,6 +243,8 @@ properties:
length adjustment when the fladj_30mhz_sdbnd signal is invalid or
incorrect.
$ref: /schemas/types.yaml#/definitions/uint32
+ minimum: 0
+ maximum: 0x3f
snps,rx-thr-num-pkt-prd:
description:
--
2.29.2
^ permalink raw reply related
* [PATCH v6 15/19] dt-bindings: usb: meson-g12a-usb: Fix FL-adj property value
From: Serge Semin @ 2020-12-10 9:09 UTC (permalink / raw)
To: Mathias Nyman, Felipe Balbi, Krzysztof Kozlowski,
Greg Kroah-Hartman, Rob Herring, Chunfeng Yun, Kevin Hilman,
Neil Armstrong, Jerome Brunet, Martin Blumenstingl
Cc: devicetree, Ahmad Zainie, linux-mips, Rob Herring, linux-snps-arc,
Yoshihiro Shimoda, linux-usb, linux-kernel, Lad Prabhakar,
Serge Semin, Bjorn Andersson, Serge Semin, Manu Gautam,
Andy Gross, Pavel Parkhomenko, linux-amlogic, Alexey Malahov,
linuxppc-dev, linux-arm-kernel, Roger Quadros
In-Reply-To: <20201210090944.16283-1-Sergey.Semin@baikalelectronics.ru>
An empty snps,quirk-frame-length-adjustment won't cause any change
performed by the driver. Moreover the DT schema validation will fail,
since it expects the property being assigned with some value. So set
fix the example by setting a valid FL-adj value in accordance with
Neil Armstrong comment.
Link: https://lore.kernel.org/linux-usb/20201010224121.12672-16-Sergey.Semin@baikalelectronics.ru/
Signed-off-by: Serge Semin <Sergey.Semin@baikalelectronics.ru>
Acked-by: Neil Armstrong <narmstrong@baylibre.com>
Reviewed-by: Rob Herring <robh@kernel.org>
Reviewed-by: Martin Blumenstingl <martin.blumenstingl@googlemail.com>
---
Note the same problem is in the DT source file
arch/arm64/boot/dts/amlogic/meson-g12-common.dtsi .
---
.../devicetree/bindings/usb/amlogic,meson-g12a-usb-ctrl.yaml | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/Documentation/devicetree/bindings/usb/amlogic,meson-g12a-usb-ctrl.yaml b/Documentation/devicetree/bindings/usb/amlogic,meson-g12a-usb-ctrl.yaml
index c0058332b967..1eda16dd4ee0 100644
--- a/Documentation/devicetree/bindings/usb/amlogic,meson-g12a-usb-ctrl.yaml
+++ b/Documentation/devicetree/bindings/usb/amlogic,meson-g12a-usb-ctrl.yaml
@@ -229,6 +229,6 @@ examples:
interrupts = <30>;
dr_mode = "host";
snps,dis_u2_susphy_quirk;
- snps,quirk-frame-length-adjustment;
+ snps,quirk-frame-length-adjustment = <0x20>;
};
};
--
2.29.2
^ permalink raw reply related
* [PATCH v6 16/19] dt-bindings: usb: meson-g12a-usb: Validate DWC2/DWC3 sub-nodes
From: Serge Semin @ 2020-12-10 9:09 UTC (permalink / raw)
To: Mathias Nyman, Felipe Balbi, Krzysztof Kozlowski,
Greg Kroah-Hartman, Rob Herring, Chunfeng Yun, Kevin Hilman,
Neil Armstrong, Jerome Brunet, Martin Blumenstingl
Cc: devicetree, Ahmad Zainie, linux-mips, Rob Herring, linux-snps-arc,
Yoshihiro Shimoda, linux-usb, linux-kernel, Lad Prabhakar,
Serge Semin, Bjorn Andersson, Serge Semin, Manu Gautam,
Andy Gross, Pavel Parkhomenko, linux-amlogic, Alexey Malahov,
linuxppc-dev, linux-arm-kernel, Roger Quadros
In-Reply-To: <20201210090944.16283-1-Sergey.Semin@baikalelectronics.ru>
Amlogic G12A USB DT sub-nodes are supposed to be compatible with the
generic DWC USB2 and USB3 devices. Since now we've got DT schemas for
both of the later IP cores let's make sure that the Amlogic G12A USB
DT nodes are fully evaluated including the DWC sub-nodes.
Signed-off-by: Serge Semin <Sergey.Semin@baikalelectronics.ru>
Reviewed-by: Neil Armstrong <narmstrong@baylibre.com>
Reviewed-by: Rob Herring <robh@kernel.org>
Reviewed-by: Martin Blumenstingl <martin.blumenstingl@googlemail.com>
---
Changelog v2:
- Use "oneOf: [dwc2.yaml#, snps,dwc3.yaml#]" instead of the bulky "if:
properties: compatibe: ..." statement.
---
.../devicetree/bindings/usb/amlogic,meson-g12a-usb-ctrl.yaml | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/Documentation/devicetree/bindings/usb/amlogic,meson-g12a-usb-ctrl.yaml b/Documentation/devicetree/bindings/usb/amlogic,meson-g12a-usb-ctrl.yaml
index 1eda16dd4ee0..e349fa5de606 100644
--- a/Documentation/devicetree/bindings/usb/amlogic,meson-g12a-usb-ctrl.yaml
+++ b/Documentation/devicetree/bindings/usb/amlogic,meson-g12a-usb-ctrl.yaml
@@ -79,7 +79,9 @@ properties:
patternProperties:
"^usb@[0-9a-f]+$":
- type: object
+ oneOf:
+ - $ref: dwc2.yaml#
+ - $ref: snps,dwc3.yaml#
additionalProperties: false
--
2.29.2
^ permalink raw reply related
* [PATCH v6 17/19] dt-bindings: usb: keystone-dwc3: Validate DWC3 sub-node
From: Serge Semin @ 2020-12-10 9:09 UTC (permalink / raw)
To: Mathias Nyman, Felipe Balbi, Krzysztof Kozlowski,
Greg Kroah-Hartman, Rob Herring, Chunfeng Yun, Roger Quadros
Cc: devicetree, linux-snps-arc, linux-mips, Neil Armstrong,
Martin Blumenstingl, Kevin Hilman, Yoshihiro Shimoda, linux-usb,
linux-kernel, Lad Prabhakar, Serge Semin, Bjorn Andersson,
Serge Semin, Manu Gautam, Andy Gross, Pavel Parkhomenko,
Alexey Malahov, linuxppc-dev, Rob Herring, linux-arm-kernel,
Ahmad Zainie
In-Reply-To: <20201210090944.16283-1-Sergey.Semin@baikalelectronics.ru>
TI Keystone DWC3 compatible DT node is supposed to have a DWC USB3
compatible sub-node to describe a fully functioning USB interface.
Since DWC USB3 has now got a DT schema describing its DT node, let's make
sure the TI Keystone DWC3 sub-node passes validation against it.
Signed-off-by: Serge Semin <Sergey.Semin@baikalelectronics.ru>
Reviewed-by: Rob Herring <robh@kernel.org>
---
Changelog v2:
- Grammar fix: "s/it'/its"
---
Documentation/devicetree/bindings/usb/ti,keystone-dwc3.yaml | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/Documentation/devicetree/bindings/usb/ti,keystone-dwc3.yaml b/Documentation/devicetree/bindings/usb/ti,keystone-dwc3.yaml
index c1b19fc5d0a2..ca7fbe3ed22e 100644
--- a/Documentation/devicetree/bindings/usb/ti,keystone-dwc3.yaml
+++ b/Documentation/devicetree/bindings/usb/ti,keystone-dwc3.yaml
@@ -64,9 +64,7 @@ properties:
patternProperties:
"usb@[a-f0-9]+$":
- type: object
- description: This is the node representing the DWC3 controller instance
- Documentation/devicetree/bindings/usb/dwc3.txt
+ $ref: snps,dwc3.yaml#
required:
- compatible
--
2.29.2
^ permalink raw reply related
* [PATCH v6 18/19] dt-bindings: usb: qcom,dwc3: Validate DWC3 sub-node
From: Serge Semin @ 2020-12-10 9:09 UTC (permalink / raw)
To: Mathias Nyman, Felipe Balbi, Krzysztof Kozlowski,
Greg Kroah-Hartman, Rob Herring, Chunfeng Yun, Andy Gross,
Bjorn Andersson, Manu Gautam
Cc: devicetree, linux-snps-arc, linux-mips, Neil Armstrong,
Martin Blumenstingl, Kevin Hilman, Yoshihiro Shimoda, linux-usb,
linux-kernel, Lad Prabhakar, Serge Semin, Alexey Malahov,
Serge Semin, Pavel Parkhomenko, linux-arm-msm, Ahmad Zainie,
linuxppc-dev, Rob Herring, linux-arm-kernel, Roger Quadros
In-Reply-To: <20201210090944.16283-1-Sergey.Semin@baikalelectronics.ru>
Qualcomm msm8996/sc7180/sdm845 DWC3 compatible DT nodes are supposed to
have a DWC USB3 compatible sub-node to describe a fully functioning USB
interface. Let's use the available DWC USB3 DT schema to validate the
Qualcomm DWC3 sub-nodes.
Note since the generic DWC USB3 DT node is supposed to be named as generic
USB HCD ("^usb(@.*)?") one we have to accordingly fix the sub-nodes name
regexp and fix the DT node example.
Signed-off-by: Serge Semin <Sergey.Semin@baikalelectronics.ru>
Reviewed-by: Rob Herring <robh@kernel.org>
---
Changelog v2:
- Discard the "^dwc3@[0-9a-f]+$" nodes from being acceptable as sub-nodes.
---
Documentation/devicetree/bindings/usb/qcom,dwc3.yaml | 9 +++------
1 file changed, 3 insertions(+), 6 deletions(-)
diff --git a/Documentation/devicetree/bindings/usb/qcom,dwc3.yaml b/Documentation/devicetree/bindings/usb/qcom,dwc3.yaml
index 2cf525d21e05..b336662e838c 100644
--- a/Documentation/devicetree/bindings/usb/qcom,dwc3.yaml
+++ b/Documentation/devicetree/bindings/usb/qcom,dwc3.yaml
@@ -103,11 +103,8 @@ properties:
# Required child node:
patternProperties:
- "^dwc3@[0-9a-f]+$":
- type: object
- description:
- A child node must exist to represent the core DWC3 IP block
- The content of the node is defined in dwc3.txt.
+ "^usb@[0-9a-f]+$":
+ $ref: snps,dwc3.yaml#
required:
- compatible
@@ -162,7 +159,7 @@ examples:
resets = <&gcc GCC_USB30_PRIM_BCR>;
- dwc3@a600000 {
+ usb@a600000 {
compatible = "snps,dwc3";
reg = <0 0x0a600000 0 0xcd00>;
interrupts = <GIC_SPI 133 IRQ_TYPE_LEVEL_HIGH>;
--
2.29.2
^ permalink raw reply related
* [PATCH v6 19/19] dt-bindings: usb: intel, keembay-dwc3: Validate DWC3 sub-node
From: Serge Semin @ 2020-12-10 9:09 UTC (permalink / raw)
To: Mathias Nyman, Felipe Balbi, Krzysztof Kozlowski,
Greg Kroah-Hartman, Rob Herring, Chunfeng Yun, Ahmad Zainie
Cc: devicetree, linux-snps-arc, linux-mips, Neil Armstrong,
Martin Blumenstingl, Kevin Hilman, Yoshihiro Shimoda, linux-usb,
linux-kernel, Lad Prabhakar, Serge Semin, Bjorn Andersson,
Serge Semin, Manu Gautam, Andy Gross, Pavel Parkhomenko,
Alexey Malahov, linuxppc-dev, Rob Herring, linux-arm-kernel,
Roger Quadros
In-Reply-To: <20201210090944.16283-1-Sergey.Semin@baikalelectronics.ru>
Intel Keem Bay DWC3 compatible DT nodes are supposed to have a DWC USB3
compatible sub-node to describe a fully functioning USB interface. Let's
use the available DWC USB3 DT schema to validate the Intel Keem Bay DWC3
sub-nodes.
Note since the generic DWC USB3 DT node is supposed to be named as generic
USB HCD ("^usb(@.*)?") one we have to accordingly fix the sub-nodes name
regexp and fix the DT node example.
Signed-off-by: Serge Semin <Sergey.Semin@baikalelectronics.ru>
Acked-by: Wan Ahmad Zainie <wan.ahmad.zainie.wan.mohamad@intel.com>
Reviewed-by: Rob Herring <robh@kernel.org>
---
Changelog v5:
- This is a new patch created for the new Intel Keem Bay bindings file,
which has been added just recently.
Changelog v6:
- Fix typo in the commit log: Qualcomm sub-node should be called as Intel
Keem Bay sub-node
---
.../devicetree/bindings/usb/intel,keembay-dwc3.yaml | 9 +++------
1 file changed, 3 insertions(+), 6 deletions(-)
diff --git a/Documentation/devicetree/bindings/usb/intel,keembay-dwc3.yaml b/Documentation/devicetree/bindings/usb/intel,keembay-dwc3.yaml
index dd32c10ce6c7..43b91ab62004 100644
--- a/Documentation/devicetree/bindings/usb/intel,keembay-dwc3.yaml
+++ b/Documentation/devicetree/bindings/usb/intel,keembay-dwc3.yaml
@@ -34,11 +34,8 @@ properties:
# Required child node:
patternProperties:
- "^dwc3@[0-9a-f]+$":
- type: object
- description:
- A child node must exist to represent the core DWC3 IP block.
- The content of the node is defined in dwc3.txt.
+ "^usb@[0-9a-f]+$":
+ $ref: snps,dwc3.yaml#
required:
- compatible
@@ -68,7 +65,7 @@ examples:
#address-cells = <1>;
#size-cells = <1>;
- dwc3@34000000 {
+ usb@34000000 {
compatible = "snps,dwc3";
reg = <0x34000000 0x10000>;
interrupts = <GIC_SPI 91 IRQ_TYPE_LEVEL_HIGH>;
--
2.29.2
^ permalink raw reply related
* [PATCH RESEND v4 00/10] dt-bindings: usb: Harmonize xHCI/EHCI/OHCI/DWC3 nodes name
From: Serge Semin @ 2020-12-10 9:17 UTC (permalink / raw)
To: Felipe Balbi, Krzysztof Kozlowski, Florian Fainelli, Rob Herring,
Greg Kroah-Hartman
Cc: Andrew Lunn, Amelie Delaunay, Tony Lindgren, Patrice Chotard,
Paul Cercueil, Paul Mackerras, linux-stm32, Alexandre Torgue,
Khuong Dinh, linux-samsung-soc, Gregory Clement, Rafal Milecki,
Alexey Brodkin, Wei Xu, Chen-Yu Tsai, Andy Gross,
bcm-kernel-feedback-list, linux-arm-msm, linux-snps-arc,
Sebastian Hesselbarth, devicetree, Jason Cooper, linux-omap,
Hauke Mehrtens, linuxppc-dev, Maxime Ripard, Vladimir Zapolskiy,
Jun Li, Santosh Shilimkar, Matthias Brugger, Bjorn Andersson,
linux-arm-kernel, Maxime Coquelin, Thomas Bogendoerfer,
linux-mips, Vineet Gupta, linux-usb, linux-kernel, Serge Semin,
Li Yang, Serge Semin, Kukjin Kim, Benoit Cousson, linux-mediatek,
Shawn Guo
As the subject states this series is an attempt to harmonize the xHCI,
EHCI, OHCI and DWC USB3 DT nodes with the DT schema introduced in the
framework of the patchset [1].
Firstly as Krzysztof suggested we've deprecated a support of DWC USB3
controllers with "synopsys,"-vendor prefix compatible string in favor of
the ones with valid "snps,"-prefix. It's done in all the DTS files,
which have been unfortunate to define such nodes.
Secondly we suggest to fix the snps,quirk-frame-length-adjustment property
declaration in the Amlogic meson-g12-common.dtsi DTS file, since it has
been erroneously declared as boolean while having uint32 type. Neil said
it was ok to init that property with 0x20 value.
Thirdly the main part of the patchset concern fixing the xHCI, EHCI/OHCI
and DWC USB3 DT nodes name as in accordance with their DT schema the
corresponding node name is suppose to comply with the Generic USB HCD DT
schema, which requires the USB nodes to have the name acceptable by the
regexp: "^usb(@.*)?". Such requirement had been applicable even before we
introduced the new DT schema in [1], but as we can see it hasn't been
strictly implemented for a lot the DTS files. Since DT schema is now
available the automated DTS validation shall make sure that the rule isn't
violated.
Note most of these patches have been a part of the last three patches of
[1]. But since there is no way to have them merged in in a combined
manner, I had to move them to the dedicated series and split them up so to
be accepted by the corresponding subsystem maintainers one-by-one.
[1] Link: https://lore.kernel.org/linux-usb/20201014101402.18271-1-Sergey.Semin@baikalelectronics.ru/
Changelog v1:
- As Krzysztof suggested I've created a script which checked whether the
node names had been also updated in all the depended dts files. As a
result I found two more files which should have been also modified:
arch/arc/boot/dts/{axc003.dtsi,axc003_idu.dtsi}
- Correct the USB DWC3 nodes name found in
arch/arm64/boot/dts/apm/{apm-storm.dtsi,apm-shadowcat.dtsi} too.
Link: https://lore.kernel.org/linux-usb/20201020115959.2658-1-Sergey.Semin@baikalelectronics.ru
Changelog v2:
- Drop the patch:
[PATCH 01/29] usb: dwc3: Discard synopsys,dwc3 compatibility string
and get back the one which marks the "synopsys,dwc3" compatible string
as deprecated into the DT schema related series.
- Drop the patches:
[PATCH 03/29] arm: dts: am437x: Correct DWC USB3 compatible string
[PATCH 04/29] arm: dts: exynos: Correct DWC USB3 compatible string
[PATCH 07/29] arm: dts: bcm53x: Harmonize EHCI/OHCI DT nodes name
[PATCH 08/29] arm: dts: stm32: Harmonize EHCI/OHCI DT nodes name
[PATCH 16/29] arm: dts: bcm5301x: Harmonize xHCI DT nodes name
[PATCH 19/29] arm: dts: exynos: Harmonize DWC USB3 DT nodes name
[PATCH 21/29] arm: dts: ls1021a: Harmonize DWC USB3 DT nodes name
[PATCH 22/29] arm: dts: omap5: Harmonize DWC USB3 DT nodes name
[PATCH 24/29] arm64: dts: allwinner: h6: Harmonize DWC USB3 DT nodes name
[PATCH 26/29] arm64: dts: exynos: Harmonize DWC USB3 DT nodes name
[PATCH 27/29] arm64: dts: layerscape: Harmonize DWC USB3 DT nodes name
since they have been applied to the corresponding maintainers repos.
- Fix drivers/usb/dwc3/dwc3-qcom.c to be looking for the "usb@"-prefixed
sub-node and falling back to the "dwc3@"-prefixed one on failure.
Link: https://lore.kernel.org/linux-usb/20201111091552.15593-1-Sergey.Semin@baikalelectronics.ru
Changelog v3:
- Drop the patches:
[PATCH v2 04/18] arm: dts: hisi-x5hd2: Harmonize EHCI/OHCI DT nodes name
[PATCH v2 06/18] arm64: dts: hisi: Harmonize EHCI/OHCI DT nodes name
[PATCH v2 07/18] mips: dts: jz47x: Harmonize EHCI/OHCI DT nodes name
[PATCH v2 08/18] mips: dts: sead3: Harmonize EHCI/OHCI DT nodes name
[PATCH v2 09/18] mips: dts: ralink: mt7628a: Harmonize EHCI/OHCI DT nodes name
[PATCH v2 11/18] arm64: dts: marvell: cp11x: Harmonize xHCI DT nodes name
[PATCH v2 12/18] arm: dts: marvell: armada-375: Harmonize DWC USB3 DT nodes name
[PATCH v2 16/18] arm64: dts: hi3660: Harmonize DWC USB3 DT nodes name
since they have been applied to the corresponding maintainers repos.
Link: https://lore.kernel.org/linux-usb/20201205155621.3045-1-Sergey.Semin@baikalelectronics.ru
Changelog v4:
- Just resend.
Cc: Vineet Gupta <vgupta@synopsys.com>
Cc: Rafal Milecki <zajec5@gmail.com>
Cc: Wei Xu <xuwei5@hisilicon.com>
Cc: Thomas Bogendoerfer <tsbogend@alpha.franken.de>
Cc: Michael Ellerman <mpe@ellerman.id.au>
Cc: Jason Cooper <jason@lakedaemon.net>
Cc: Santosh Shilimkar <ssantosh@kernel.org>
Cc: Shawn Guo <shawnguo@kernel.org>
Cc: Benoit Cousson <bcousson@baylibre.com>
Cc: Patrice Chotard <patrice.chotard@st.com>
Cc: Maxime Ripard <mripard@kernel.org>
Cc: Khuong Dinh <khuong@os.amperecomputing.com>
Cc: Andy Gross <agross@kernel.org>
Cc: Alexey Brodkin <abrodkin@synopsys.com>
Cc: Hauke Mehrtens <hauke@hauke-m.de>
Cc: Maxime Coquelin <mcoquelin.stm32@gmail.com>
Cc: Alexandre Torgue <alexandre.torgue@st.com>
Cc: Amelie Delaunay <amelie.delaunay@st.com>
Cc: Vladimir Zapolskiy <vz@mleia.com>
Cc: Paul Cercueil <paul@crapouillou.net>
Cc: Matthias Brugger <matthias.bgg@gmail.com>
Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Cc: Paul Mackerras <paulus@samba.org>
Cc: Andrew Lunn <andrew@lunn.ch>
Cc: Gregory Clement <gregory.clement@bootlin.com>
Cc: Sebastian Hesselbarth <sebastian.hesselbarth@gmail.com>
Cc: Kukjin Kim <kgene@kernel.org>
Cc: Li Yang <leoyang.li@nxp.com>
Cc: Tony Lindgren <tony@atomide.com>
Cc: Chen-Yu Tsai <wens@csie.org>
Cc: Bjorn Andersson <bjorn.andersson@linaro.org>
Cc: Jun Li <lijun.kernel@gmail.com>
Cc: linux-snps-arc@lists.infradead.org
Cc: bcm-kernel-feedback-list@broadcom.com
Cc: linux-stm32@st-md-mailman.stormreply.com
Cc: linux-arm-kernel@lists.infradead.org
Cc: linux-mips@vger.kernel.org
Cc: linux-mediatek@lists.infradead.org
Cc: linuxppc-dev@lists.ozlabs.org
Cc: linux-samsung-soc@vger.kernel.org
Cc: linux-omap@vger.kernel.org
Cc: linux-arm-msm@vger.kernel.org
Cc: devicetree@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Serge Semin (10):
arm: dts: keystone: Correct DWC USB3 compatible string
arm64: dts: amlogic: meson-g12: Set FL-adj property value
arc: dts: Harmonize EHCI/OHCI DT nodes name
arm: dts: lpc18xx: Harmonize EHCI/OHCI DT nodes name
powerpc: dts: akebono: Harmonize EHCI/OHCI DT nodes name
arm: dts: keystone: Harmonize DWC USB3 DT nodes name
arm: dts: stih407-family: Harmonize DWC USB3 DT nodes name
arm64: dts: apm: Harmonize DWC USB3 DT nodes name
usb: dwc3: qcom: Detect DWC3 DT-nodes with "usb"-prefixed names
arm64: dts: qcom: Harmonize DWC USB3 DT nodes name
arch/arc/boot/dts/axc003.dtsi | 4 ++--
arch/arc/boot/dts/axc003_idu.dtsi | 4 ++--
arch/arc/boot/dts/axs10x_mb.dtsi | 4 ++--
arch/arc/boot/dts/hsdk.dts | 4 ++--
arch/arc/boot/dts/vdk_axs10x_mb.dtsi | 2 +-
arch/arm/boot/dts/keystone-k2e.dtsi | 6 +++---
arch/arm/boot/dts/keystone.dtsi | 4 ++--
arch/arm/boot/dts/lpc18xx.dtsi | 4 ++--
arch/arm/boot/dts/stih407-family.dtsi | 2 +-
arch/arm64/boot/dts/amlogic/meson-g12-common.dtsi | 2 +-
arch/arm64/boot/dts/apm/apm-shadowcat.dtsi | 4 ++--
arch/arm64/boot/dts/apm/apm-storm.dtsi | 6 +++---
arch/arm64/boot/dts/qcom/apq8096-db820c.dtsi | 4 ++--
arch/arm64/boot/dts/qcom/ipq8074.dtsi | 4 ++--
arch/arm64/boot/dts/qcom/msm8996.dtsi | 4 ++--
arch/arm64/boot/dts/qcom/msm8998.dtsi | 2 +-
arch/arm64/boot/dts/qcom/qcs404-evb.dtsi | 2 +-
arch/arm64/boot/dts/qcom/qcs404.dtsi | 4 ++--
arch/arm64/boot/dts/qcom/sc7180.dtsi | 2 +-
arch/arm64/boot/dts/qcom/sdm845.dtsi | 4 ++--
arch/arm64/boot/dts/qcom/sm8150.dtsi | 2 +-
arch/powerpc/boot/dts/akebono.dts | 6 +++---
drivers/usb/dwc3/dwc3-qcom.c | 3 ++-
23 files changed, 42 insertions(+), 41 deletions(-)
--
2.29.2
^ permalink raw reply
* [PATCH v4 05/10] powerpc: dts: akebono: Harmonize EHCI/OHCI DT nodes name
From: Serge Semin @ 2020-12-10 9:17 UTC (permalink / raw)
To: Felipe Balbi, Krzysztof Kozlowski, Florian Fainelli, Rob Herring,
Greg Kroah-Hartman, Michael Ellerman, Benjamin Herrenschmidt,
Paul Mackerras
Cc: devicetree, linux-usb, linux-kernel, Serge Semin, Serge Semin,
linuxppc-dev
In-Reply-To: <20201210091756.18057-1-Sergey.Semin@baikalelectronics.ru>
In accordance with the Generic EHCI/OHCI bindings the corresponding node
name is suppose to comply with the Generic USB HCD DT schema, which
requires the USB nodes to have the name acceptable by the regexp:
"^usb(@.*)?" . Make sure the "generic-ehci" and "generic-ohci"-compatible
nodes are correctly named.
Signed-off-by: Serge Semin <Sergey.Semin@baikalelectronics.ru>
Acked-by: Krzysztof Kozlowski <krzk@kernel.org>
---
arch/powerpc/boot/dts/akebono.dts | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/arch/powerpc/boot/dts/akebono.dts b/arch/powerpc/boot/dts/akebono.dts
index df18f8dc4642..343326c30380 100644
--- a/arch/powerpc/boot/dts/akebono.dts
+++ b/arch/powerpc/boot/dts/akebono.dts
@@ -126,7 +126,7 @@ SATA0: sata@30000010000 {
interrupts = <93 2>;
};
- EHCI0: ehci@30010000000 {
+ EHCI0: usb@30010000000 {
compatible = "ibm,476gtr-ehci", "generic-ehci";
reg = <0x300 0x10000000 0x0 0x10000>;
interrupt-parent = <&MPIC>;
@@ -140,14 +140,14 @@ SD0: sd@30000000000 {
interrupt-parent = <&MPIC>;
};
- OHCI0: ohci@30010010000 {
+ OHCI0: usb@30010010000 {
compatible = "ibm,476gtr-ohci", "generic-ohci";
reg = <0x300 0x10010000 0x0 0x10000>;
interrupt-parent = <&MPIC>;
interrupts = <89 1>;
};
- OHCI1: ohci@30010020000 {
+ OHCI1: usb@30010020000 {
compatible = "ibm,476gtr-ohci", "generic-ohci";
reg = <0x300 0x10020000 0x0 0x10000>;
interrupt-parent = <&MPIC>;
--
2.29.2
^ permalink raw reply related
* Re: [PATCH 00/13] powerpc/xive: misc cleanups
From: Cédric Le Goater @ 2020-12-10 9:59 UTC (permalink / raw)
To: linuxppc-dev
In-Reply-To: <20201208151124.1329942-1-clg@kaod.org>
On 12/8/20 4:11 PM, Cédric Le Goater wrote:
> Hello,
>
> The most important change is the removal of support of OPAL flags
> required for P9 DD1. It provides a good cleanup of some complex
> routines.
>
> The series also includes a change on how the pages donated to the XIVE
> IC are allocated in Linux. The flags are changed to make sure that
> these pages can not be reclaimed.
This issue (checkstop) only occurred a once or twice on a P9 Mihawk
with 1TB of RAM and 1TB of swap. It's hard to reproduce. It seems
we have a fix but I misunderstood some parts of the kernel page
allocation scheme and, so, I am not entirely the root issue is
well analyzed. This patch can wait until I grab a larger system
with 2TB.
I will send a v2. Greg had some valuable comments on extra
cleanups.
Thanks,
C.
^ permalink raw reply
* Re: [PATCH] drivers: usb: gadget: prefer pr_*() functions over raw printk()
From: Enrico Weigelt, metux IT consult @ 2020-12-10 9:56 UTC (permalink / raw)
To: Laurent Pinchart, Enrico Weigelt, metux IT consult
Cc: balbi, linux-usb, linuxppc-dev, linux-kernel, leoyang.li
In-Reply-To: <X9C0vOLZOnLZoPR8@pendragon.ideasonboard.com>
On 09.12.20 12:27, Laurent Pinchart wrote:
Hi,
>>> I wonder if this shouldn't be dropped instead, commented-out code isn't
>>> very useful.
>>
>> Indeed. Shall I send a separate patch for that ?
>
> Yes, that would make sense.
Okay, I'm currently doing a more in-depth rework. I'll send another
patch queue later.
Since I don't own the corresponding devices, I can't do much testing
(just build tests and careful review), so I need some help w/ that.
> As most of the files touched by this patch are device drivers, dev_*()
> functions should be used instead of pr_*() where possible. I'd recommend
> a first patch that converts to dev_*(), and then a second patch that
> converts the remaining printk()s, if any, to pr_*() in the contexts
> where no struct device is available or can easily be made available.
I'm now splitting it into per-driver patches. They're getting a bit
bigger, since I'm also replacing some debug macros, etc. In some cases
I'm introducing new helpers for not having to write long expressions
to get the actual dev ptr, adding some prefixes (eg. per usb endpoint
logging, ...).
--mtx
--
---
Hinweis: unverschlüsselte E-Mails können leicht abgehört und manipuliert
werden ! Für eine vertrauliche Kommunikation senden Sie bitte ihren
GPG/PGP-Schlüssel zu.
---
Enrico Weigelt, metux IT consult
Free software and Linux embedded engineering
info@metux.net -- +49-151-27565287
^ permalink raw reply
* [PATCH v3 1/5] powerpc/smp: Parse ibm, thread-groups with multiple properties
From: Gautham R. Shenoy @ 2020-12-10 10:38 UTC (permalink / raw)
To: Srikar Dronamraju, Anton Blanchard, Vaidyanathan Srinivasan,
Michael Ellerman, Michael Neuling, Nicholas Piggin, Nathan Lynch,
Peter Zijlstra, Valentin Schneider
Cc: Gautham R. Shenoy, linuxppc-dev, linux-kernel
In-Reply-To: <1607596739-32439-1-git-send-email-ego@linux.vnet.ibm.com>
From: "Gautham R. Shenoy" <ego@linux.vnet.ibm.com>
The "ibm,thread-groups" device-tree property is an array that is used
to indicate if groups of threads within a core share certain
properties. It provides details of which property is being shared by
which groups of threads. This array can encode information about
multiple properties being shared by different thread-groups within the
core.
Example: Suppose,
"ibm,thread-groups" = [1,2,4,8,10,12,14,9,11,13,15,2,2,4,8,10,12,14,9,11,13,15]
This can be decomposed up into two consecutive arrays:
a) [1,2,4,8,10,12,14,9,11,13,15]
b) [2,2,4,8,10,12,14,9,11,13,15]
where in,
a) provides information of Property "1" being shared by "2" groups,
each with "4" threads each. The "ibm,ppc-interrupt-server#s" of the
first group is {8,10,12,14} and the "ibm,ppc-interrupt-server#s" of
the second group is {9,11,13,15}. Property "1" is indicative of
the thread in the group sharing L1 cache, translation cache and
Instruction Data flow.
b) provides information of Property "2" being shared by "2" groups,
each group with "4" threads. The "ibm,ppc-interrupt-server#s" of
the first group is {8,10,12,14} and the
"ibm,ppc-interrupt-server#s" of the second group is
{9,11,13,15}. Property "2" indicates that the threads in each group
share the L2-cache.
The existing code assumes that the "ibm,thread-groups" encodes
information about only one property. Hence even on platforms which
encode information about multiple properties being shared by the
corresponding groups of threads, the current code will only pick the
first one. (In the above example, it will only consider
[1,2,4,8,10,12,14,9,11,13,15] but not [2,2,4,8,10,12,14,9,11,13,15]).
This patch extends the parsing support on platforms which encode
information about multiple properties being shared by the
corresponding groups of threads.
Signed-off-by: Gautham R. Shenoy <ego@linux.vnet.ibm.com>
---
arch/powerpc/kernel/smp.c | 174 ++++++++++++++++++++++++++++++----------------
1 file changed, 113 insertions(+), 61 deletions(-)
diff --git a/arch/powerpc/kernel/smp.c b/arch/powerpc/kernel/smp.c
index 8c2857c..88d88ad 100644
--- a/arch/powerpc/kernel/smp.c
+++ b/arch/powerpc/kernel/smp.c
@@ -106,6 +106,15 @@ struct thread_groups {
unsigned int thread_list[MAX_THREAD_LIST_SIZE];
};
+/* Maximum number of properties that groups of threads within a core can share */
+#define MAX_THREAD_GROUP_PROPERTIES 1
+
+struct thread_groups_list {
+ unsigned int nr_properties;
+ struct thread_groups property_tgs[MAX_THREAD_GROUP_PROPERTIES];
+};
+
+static struct thread_groups_list tgl[NR_CPUS] __initdata;
/*
* On big-cores system, cpu_l1_cache_map for each CPU corresponds to
* the set its siblings that share the L1-cache.
@@ -695,81 +704,98 @@ static void or_cpumasks_related(int i, int j, struct cpumask *(*srcmask)(int),
/*
* parse_thread_groups: Parses the "ibm,thread-groups" device tree
* property for the CPU device node @dn and stores
- * the parsed output in the thread_groups
- * structure @tg if the ibm,thread-groups[0]
- * matches @property.
+ * the parsed output in the thread_groups_list
+ * structure @tglp.
*
* @dn: The device node of the CPU device.
- * @tg: Pointer to a thread group structure into which the parsed
+ * @tglp: Pointer to a thread group list structure into which the parsed
* output of "ibm,thread-groups" is stored.
- * @property: The property of the thread-group that the caller is
- * interested in.
*
* ibm,thread-groups[0..N-1] array defines which group of threads in
* the CPU-device node can be grouped together based on the property.
*
- * ibm,thread-groups[0] tells us the property based on which the
+ * This array can represent thread groupings for multiple properties.
+ *
+ * ibm,thread-groups[i + 0] tells us the property based on which the
* threads are being grouped together. If this value is 1, it implies
* that the threads in the same group share L1, translation cache.
*
- * ibm,thread-groups[1] tells us how many such thread groups exist.
+ * ibm,thread-groups[i+1] tells us how many such thread groups exist for the
+ * property ibm,thread-groups[i]
*
- * ibm,thread-groups[2] tells us the number of threads in each such
+ * ibm,thread-groups[i+2] tells us the number of threads in each such
* group.
+ * Suppose k = (ibm,thread-groups[i+1] * ibm,thread-groups[i+2]), then,
*
- * ibm,thread-groups[3..N-1] is the list of threads identified by
+ * ibm,thread-groups[i+3..i+k+2] (is the list of threads identified by
* "ibm,ppc-interrupt-server#s" arranged as per their membership in
* the grouping.
*
- * Example: If ibm,thread-groups = [1,2,4,5,6,7,8,9,10,11,12] it
- * implies that there are 2 groups of 4 threads each, where each group
- * of threads share L1, translation cache.
+ * Example:
+ * If "ibm,thread-groups" = [1,2,4,8,10,12,14,9,11,13,15,2,2,4,8,10,12,14,9,11,13,15]
+ * This can be decomposed up into two consecutive arrays:
+ * a) [1,2,4,8,10,12,14,9,11,13,15]
+ * b) [2,2,4,8,10,12,14,9,11,13,15]
+ *
+ * where in,
+ *
+ * a) provides information of Property "1" being shared by "2" groups,
+ * each with "4" threads each. The "ibm,ppc-interrupt-server#s" of
+ * the first group is {8,10,12,14} and the
+ * "ibm,ppc-interrupt-server#s" of the second group is
+ * {9,11,13,15}. Property "1" is indicative of the thread in the
+ * group sharing L1 cache, translation cache and Instruction Data
+ * flow.
*
- * The "ibm,ppc-interrupt-server#s" of the first group is {5,6,7,8}
- * and the "ibm,ppc-interrupt-server#s" of the second group is {9, 10,
- * 11, 12} structure
+ * b) provides information of Property "2" being shared by "2" groups,
+ * each group with "4" threads. The "ibm,ppc-interrupt-server#s" of
+ * the first group is {8,10,12,14} and the
+ * "ibm,ppc-interrupt-server#s" of the second group is
+ * {9,11,13,15}. Property "2" indicates that the threads in each
+ * group share the L2-cache.
*
* Returns 0 on success, -EINVAL if the property does not exist,
* -ENODATA if property does not have a value, and -EOVERFLOW if the
* property data isn't large enough.
*/
static int parse_thread_groups(struct device_node *dn,
- struct thread_groups *tg,
- unsigned int property)
+ struct thread_groups_list *tglp)
{
- int i;
- u32 thread_group_array[3 + MAX_THREAD_LIST_SIZE];
- u32 *thread_list;
+ unsigned int property_idx = 0;
+ u32 *thread_group_array;
size_t total_threads;
- int ret;
+ int ret = 0, count;
+ u32 *thread_list;
+ int i = 0;
+ count = of_property_count_u32_elems(dn, "ibm,thread-groups");
+ thread_group_array = kcalloc(count, sizeof(u32), GFP_KERNEL);
ret = of_property_read_u32_array(dn, "ibm,thread-groups",
- thread_group_array, 3);
+ thread_group_array, count);
if (ret)
- return ret;
-
- tg->property = thread_group_array[0];
- tg->nr_groups = thread_group_array[1];
- tg->threads_per_group = thread_group_array[2];
- if (tg->property != property ||
- tg->nr_groups < 1 ||
- tg->threads_per_group < 1)
- return -ENODATA;
+ goto out_free;
- total_threads = tg->nr_groups * tg->threads_per_group;
+ while (i < count && property_idx < MAX_THREAD_GROUP_PROPERTIES) {
+ int j;
+ struct thread_groups *tg = &tglp->property_tgs[property_idx++];
- ret = of_property_read_u32_array(dn, "ibm,thread-groups",
- thread_group_array,
- 3 + total_threads);
- if (ret)
- return ret;
+ tg->property = thread_group_array[i];
+ tg->nr_groups = thread_group_array[i + 1];
+ tg->threads_per_group = thread_group_array[i + 2];
+ total_threads = tg->nr_groups * tg->threads_per_group;
- thread_list = &thread_group_array[3];
+ thread_list = &thread_group_array[i + 3];
- for (i = 0 ; i < total_threads; i++)
- tg->thread_list[i] = thread_list[i];
+ for (j = 0; j < total_threads; j++)
+ tg->thread_list[j] = thread_list[j];
+ i = i + 3 + total_threads;
+ }
- return 0;
+ tglp->nr_properties = property_idx;
+
+out_free:
+ kfree(thread_group_array);
+ return ret;
}
/*
@@ -805,50 +831,76 @@ static int get_cpu_thread_group_start(int cpu, struct thread_groups *tg)
return -1;
}
+static struct thread_groups *__init get_thread_groups(int cpu,
+ int group_property,
+ int *err)
+{
+ struct device_node *dn = of_get_cpu_node(cpu, NULL);
+ struct thread_groups_list *cpu_tgl = &tgl[cpu];
+ struct thread_groups *tg = NULL;
+ int i;
+ *err = 0;
+
+ if (!dn) {
+ *err = -ENODATA;
+ return NULL;
+ }
+
+ if (!cpu_tgl->nr_properties) {
+ *err = parse_thread_groups(dn, cpu_tgl);
+ if (*err)
+ goto out;
+ }
+
+ for (i = 0; i < cpu_tgl->nr_properties; i++) {
+ if (cpu_tgl->property_tgs[i].property == group_property) {
+ tg = &cpu_tgl->property_tgs[i];
+ break;
+ }
+ }
+
+ if (!tg)
+ *err = -EINVAL;
+out:
+ of_node_put(dn);
+ return tg;
+}
+
static int init_cpu_l1_cache_map(int cpu)
{
- struct device_node *dn = of_get_cpu_node(cpu, NULL);
- struct thread_groups tg = {.property = 0,
- .nr_groups = 0,
- .threads_per_group = 0};
int first_thread = cpu_first_thread_sibling(cpu);
int i, cpu_group_start = -1, err = 0;
+ struct thread_groups *tg = NULL;
- if (!dn)
- return -ENODATA;
-
- err = parse_thread_groups(dn, &tg, THREAD_GROUP_SHARE_L1);
- if (err)
- goto out;
+ tg = get_thread_groups(cpu, THREAD_GROUP_SHARE_L1,
+ &err);
+ if (!tg)
+ return err;
- cpu_group_start = get_cpu_thread_group_start(cpu, &tg);
+ cpu_group_start = get_cpu_thread_group_start(cpu, tg);
if (unlikely(cpu_group_start == -1)) {
WARN_ON_ONCE(1);
- err = -ENODATA;
- goto out;
+ return -ENODATA;
}
zalloc_cpumask_var_node(&per_cpu(cpu_l1_cache_map, cpu),
GFP_KERNEL, cpu_to_node(cpu));
for (i = first_thread; i < first_thread + threads_per_core; i++) {
- int i_group_start = get_cpu_thread_group_start(i, &tg);
+ int i_group_start = get_cpu_thread_group_start(i, tg);
if (unlikely(i_group_start == -1)) {
WARN_ON_ONCE(1);
- err = -ENODATA;
- goto out;
+ return -ENODATA;
}
if (i_group_start == cpu_group_start)
cpumask_set_cpu(i, per_cpu(cpu_l1_cache_map, cpu));
}
-out:
- of_node_put(dn);
- return err;
+ return 0;
}
static bool shared_caches;
--
1.9.4
^ permalink raw reply related
* [PATCH v3 5/5] powerpc/cacheinfo: Print correct cache-sibling map/list for L2 cache
From: Gautham R. Shenoy @ 2020-12-10 10:38 UTC (permalink / raw)
To: Srikar Dronamraju, Anton Blanchard, Vaidyanathan Srinivasan,
Michael Ellerman, Michael Neuling, Nicholas Piggin, Nathan Lynch,
Peter Zijlstra, Valentin Schneider
Cc: Gautham R. Shenoy, linuxppc-dev, linux-kernel
In-Reply-To: <1607596739-32439-1-git-send-email-ego@linux.vnet.ibm.com>
From: "Gautham R. Shenoy" <ego@linux.vnet.ibm.com>
On POWER platforms where only some groups of threads within a core
share the L2-cache (indicated by the ibm,thread-groups device-tree
property), we currently print the incorrect shared_cpu_map/list for
L2-cache in the sysfs.
This patch reports the correct shared_cpu_map/list on such platforms.
Example:
On a platform with "ibm,thread-groups" set to
00000001 00000002 00000004 00000000
00000002 00000004 00000006 00000001
00000003 00000005 00000007 00000002
00000002 00000004 00000000 00000002
00000004 00000006 00000001 00000003
00000005 00000007
This indicates that threads {0,2,4,6} in the core share the L2-cache
and threads {1,3,5,7} in the core share the L2 cache.
However, without the patch, the shared_cpu_map/list for L2 for CPUs 0,
1 is reported in the sysfs as follows:
/sys/devices/system/cpu/cpu0/cache/index2/shared_cpu_list:0-7
/sys/devices/system/cpu/cpu0/cache/index2/shared_cpu_map:000000,000000ff
/sys/devices/system/cpu/cpu1/cache/index2/shared_cpu_list:0-7
/sys/devices/system/cpu/cpu1/cache/index2/shared_cpu_map:000000,000000ff
With the patch, the shared_cpu_map/list for L2 cache for CPUs 0, 1 is
correctly reported as follows:
/sys/devices/system/cpu/cpu0/cache/index2/shared_cpu_list:0,2,4,6
/sys/devices/system/cpu/cpu0/cache/index2/shared_cpu_map:000000,00000055
/sys/devices/system/cpu/cpu1/cache/index2/shared_cpu_list:1,3,5,7
/sys/devices/system/cpu/cpu1/cache/index2/shared_cpu_map:000000,000000aa
This patch also defines cpu_l2_cache_mask() for !CONFIG_SMP case.
Signed-off-by: Gautham R. Shenoy <ego@linux.vnet.ibm.com>
---
arch/powerpc/include/asm/smp.h | 4 ++++
arch/powerpc/kernel/cacheinfo.c | 30 ++++++++++++++++++++----------
2 files changed, 24 insertions(+), 10 deletions(-)
diff --git a/arch/powerpc/include/asm/smp.h b/arch/powerpc/include/asm/smp.h
index 035459c..c4e2d53 100644
--- a/arch/powerpc/include/asm/smp.h
+++ b/arch/powerpc/include/asm/smp.h
@@ -201,6 +201,10 @@ static inline const struct cpumask *cpu_smallcore_mask(int cpu)
return cpumask_of(cpu);
}
+static inline const struct cpumask *cpu_l2_cache_mask(int cpu)
+{
+ return cpumask_of(cpu);
+}
#endif /* CONFIG_SMP */
#ifdef CONFIG_PPC64
diff --git a/arch/powerpc/kernel/cacheinfo.c b/arch/powerpc/kernel/cacheinfo.c
index 65ab9fc..6f903e9a 100644
--- a/arch/powerpc/kernel/cacheinfo.c
+++ b/arch/powerpc/kernel/cacheinfo.c
@@ -655,11 +655,27 @@ static unsigned int index_dir_to_cpu(struct cache_index_dir *index)
* On big-core systems, each core has two groups of CPUs each of which
* has its own L1-cache. The thread-siblings which share l1-cache with
* @cpu can be obtained via cpu_smallcore_mask().
+ *
+ * On some big-core systems, the L2 cache is shared only between some
+ * groups of siblings. This is already parsed and encoded in
+ * cpu_l2_cache_mask().
+ *
+ * TODO: cache_lookup_or_instantiate() needs to be made aware of the
+ * "ibm,thread-groups" property so that cache->shared_cpu_map
+ * reflects the correct siblings on platforms that have this
+ * device-tree property. This helper function is only a stop-gap
+ * solution so that we report the correct siblings to the
+ * userspace via sysfs.
*/
-static const struct cpumask *get_big_core_shared_cpu_map(int cpu, struct cache *cache)
+static const struct cpumask *get_shared_cpu_map(struct cache_index_dir *index, struct cache *cache)
{
- if (cache->level == 1)
- return cpu_smallcore_mask(cpu);
+ if (has_big_cores) {
+ int cpu = index_dir_to_cpu(index);
+ if (cache->level == 1)
+ return cpu_smallcore_mask(cpu);
+ if (cache->level == 2 && thread_group_shares_l2)
+ return cpu_l2_cache_mask(cpu);
+ }
return &cache->shared_cpu_map;
}
@@ -670,17 +686,11 @@ static const struct cpumask *get_big_core_shared_cpu_map(int cpu, struct cache *
struct cache_index_dir *index;
struct cache *cache;
const struct cpumask *mask;
- int cpu;
index = kobj_to_cache_index_dir(k);
cache = index->cache;
- if (has_big_cores) {
- cpu = index_dir_to_cpu(index);
- mask = get_big_core_shared_cpu_map(cpu, cache);
- } else {
- mask = &cache->shared_cpu_map;
- }
+ mask = get_shared_cpu_map(index, cache);
return cpumap_print_to_pagebuf(list, buf, mask);
}
--
1.9.4
^ permalink raw reply related
* [PATCH v3 4/5] powerpc/smp: Add support detecting thread-groups sharing L2 cache
From: Gautham R. Shenoy @ 2020-12-10 10:38 UTC (permalink / raw)
To: Srikar Dronamraju, Anton Blanchard, Vaidyanathan Srinivasan,
Michael Ellerman, Michael Neuling, Nicholas Piggin, Nathan Lynch,
Peter Zijlstra, Valentin Schneider
Cc: Gautham R. Shenoy, linuxppc-dev, linux-kernel
In-Reply-To: <1607596739-32439-1-git-send-email-ego@linux.vnet.ibm.com>
From: "Gautham R. Shenoy" <ego@linux.vnet.ibm.com>
On POWER systems, groups of threads within a core sharing the L2-cache
can be indicated by the "ibm,thread-groups" property array with the
identifier "2".
This patch adds support for detecting this, and when present, populate
the populating the cpu_l2_cache_mask of every CPU to the core-siblings
which share L2 with the CPU as specified in the by the
"ibm,thread-groups" property array.
On a platform with the following "ibm,thread-group" configuration
00000001 00000002 00000004 00000000
00000002 00000004 00000006 00000001
00000003 00000005 00000007 00000002
00000002 00000004 00000000 00000002
00000004 00000006 00000001 00000003
00000005 00000007
Without this patch, the sched-domain hierarchy for CPUs 0,1 would be
CPU0 attaching sched-domain(s):
domain-0: span=0,2,4,6 level=SMT
domain-1: span=0-7 level=CACHE
domain-2: span=0-15,24-39,48-55 level=MC
domain-3: span=0-55 level=DIE
CPU1 attaching sched-domain(s):
domain-0: span=1,3,5,7 level=SMT
domain-1: span=0-7 level=CACHE
domain-2: span=0-15,24-39,48-55 level=MC
domain-3: span=0-55 level=DIE
The CACHE domain at 0-7 is incorrect since the ibm,thread-groups
sub-array
[00000002 00000002 00000004
00000000 00000002 00000004 00000006
00000001 00000003 00000005 00000007]
indicates that L2 (Property "2") is shared only between the threads of a single
group. There are "2" groups of threads where each group contains "4"
threads each. The groups being {0,2,4,6} and {1,3,5,7}.
With this patch, the sched-domain hierarchy for CPUs 0,1 would be
CPU0 attaching sched-domain(s):
domain-0: span=0,2,4,6 level=SMT
domain-1: span=0-15,24-39,48-55 level=MC
domain-2: span=0-55 level=DIE
CPU1 attaching sched-domain(s):
domain-0: span=1,3,5,7 level=SMT
domain-1: span=0-15,24-39,48-55 level=MC
domain-2: span=0-55 level=DIE
The CACHE domain with span=0,2,4,6 for CPU 0 (span=1,3,5,7 for CPU 1
resp.) gets degenerated into the SMT domain. Furthermore, the
last-level-cache domain gets correctly set to the SMT sched-domain.
Signed-off-by: Gautham R. Shenoy <ego@linux.vnet.ibm.com>
---
arch/powerpc/include/asm/smp.h | 2 ++
arch/powerpc/kernel/smp.c | 58 ++++++++++++++++++++++++++++++++++++++----
2 files changed, 55 insertions(+), 5 deletions(-)
diff --git a/arch/powerpc/include/asm/smp.h b/arch/powerpc/include/asm/smp.h
index b2035b2..035459c 100644
--- a/arch/powerpc/include/asm/smp.h
+++ b/arch/powerpc/include/asm/smp.h
@@ -134,6 +134,7 @@ static inline struct cpumask *cpu_smallcore_mask(int cpu)
extern int cpu_to_core_id(int cpu);
extern bool has_big_cores;
+extern bool thread_group_shares_l2;
#define cpu_smt_mask cpu_smt_mask
#ifdef CONFIG_SCHED_SMT
@@ -187,6 +188,7 @@ static inline const struct cpumask *cpu_smt_mask(int cpu)
/* for UP */
#define hard_smp_processor_id() get_hard_smp_processor_id(0)
#define smp_setup_cpu_maps()
+#define thread_group_shares_l2 0
static inline void inhibit_secondary_onlining(void) {}
static inline void uninhibit_secondary_onlining(void) {}
static inline const struct cpumask *cpu_sibling_mask(int cpu)
diff --git a/arch/powerpc/kernel/smp.c b/arch/powerpc/kernel/smp.c
index 9078b5b5..2b9b1bb 100644
--- a/arch/powerpc/kernel/smp.c
+++ b/arch/powerpc/kernel/smp.c
@@ -76,6 +76,7 @@
struct task_struct *secondary_current;
bool has_big_cores;
bool coregroup_enabled;
+bool thread_group_shares_l2;
DEFINE_PER_CPU(cpumask_var_t, cpu_sibling_map);
DEFINE_PER_CPU(cpumask_var_t, cpu_smallcore_map);
@@ -99,6 +100,7 @@ enum {
#define MAX_THREAD_LIST_SIZE 8
#define THREAD_GROUP_SHARE_L1 1
+#define THREAD_GROUP_SHARE_L2 2
struct thread_groups {
unsigned int property;
unsigned int nr_groups;
@@ -107,7 +109,7 @@ struct thread_groups {
};
/* Maximum number of properties that groups of threads within a core can share */
-#define MAX_THREAD_GROUP_PROPERTIES 1
+#define MAX_THREAD_GROUP_PROPERTIES 2
struct thread_groups_list {
unsigned int nr_properties;
@@ -121,6 +123,13 @@ struct thread_groups_list {
*/
DEFINE_PER_CPU(cpumask_var_t, thread_group_l1_cache_map);
+/*
+ * On some big-cores system, thread_group_l2_cache_map for each CPU
+ * corresponds to the set its siblings within the core that share the
+ * L2-cache.
+ */
+DEFINE_PER_CPU(cpumask_var_t, thread_group_l2_cache_map);
+
/* SMP operations for this machine */
struct smp_ops_t *smp_ops;
@@ -718,7 +727,9 @@ static void or_cpumasks_related(int i, int j, struct cpumask *(*srcmask)(int),
*
* ibm,thread-groups[i + 0] tells us the property based on which the
* threads are being grouped together. If this value is 1, it implies
- * that the threads in the same group share L1, translation cache.
+ * that the threads in the same group share L1, translation cache. If
+ * the value is 2, it implies that the threads in the same group share
+ * the same L2 cache.
*
* ibm,thread-groups[i+1] tells us how many such thread groups exist for the
* property ibm,thread-groups[i]
@@ -872,9 +883,10 @@ static int __init init_thread_group_cache_map(int cpu, int cache_property)
int first_thread = cpu_first_thread_sibling(cpu);
int i, cpu_group_start = -1, err = 0;
struct thread_groups *tg = NULL;
- cpumask_var_t *mask;
+ cpumask_var_t *mask = NULL;
- if (cache_property != THREAD_GROUP_SHARE_L1)
+ if (cache_property != THREAD_GROUP_SHARE_L1 &&
+ cache_property != THREAD_GROUP_SHARE_L2)
return -EINVAL;
tg = get_thread_groups(cpu, cache_property, &err);
@@ -888,7 +900,11 @@ static int __init init_thread_group_cache_map(int cpu, int cache_property)
return -ENODATA;
}
- mask = &per_cpu(thread_group_l1_cache_map, cpu);
+ if (cache_property == THREAD_GROUP_SHARE_L1)
+ mask = &per_cpu(thread_group_l1_cache_map, cpu);
+ else if (cache_property == THREAD_GROUP_SHARE_L2)
+ mask = &per_cpu(thread_group_l2_cache_map, cpu);
+
zalloc_cpumask_var_node(mask, GFP_KERNEL, cpu_to_node(cpu));
for (i = first_thread; i < first_thread + threads_per_core; i++) {
@@ -990,6 +1006,16 @@ static int init_big_cores(void)
}
has_big_cores = true;
+
+ for_each_possible_cpu(cpu) {
+ int err = init_thread_group_cache_map(cpu, THREAD_GROUP_SHARE_L2);
+
+ if (err)
+ return err;
+ }
+
+ thread_group_shares_l2 = true;
+ pr_debug("L2 cache only shared by the threads in the small core\n");
return 0;
}
@@ -1304,6 +1330,28 @@ static bool update_mask_by_l2(int cpu, cpumask_var_t *mask)
if (has_big_cores)
submask_fn = cpu_smallcore_mask;
+ /*
+ * If the threads in a thread-group share L2 cache, then the
+ * L2-mask can be obtained from thread_group_l2_cache_map.
+ */
+ if (thread_group_shares_l2) {
+ cpumask_set_cpu(cpu, cpu_l2_cache_mask(cpu));
+
+ for_each_cpu(i, per_cpu(thread_group_l2_cache_map, cpu)) {
+ if (cpu_online(i))
+ set_cpus_related(i, cpu, cpu_l2_cache_mask);
+ }
+
+ /* Verify that L1-cache siblings are a subset of L2 cache-siblings */
+ if (!cpumask_equal(submask_fn(cpu), cpu_l2_cache_mask(cpu)) &&
+ !cpumask_subset(submask_fn(cpu), cpu_l2_cache_mask(cpu))) {
+ pr_warn_once("CPU %d : Inconsistent L1 and L2 cache siblings\n",
+ cpu);
+ }
+
+ return true;
+ }
+
l2_cache = cpu_to_l2cache(cpu);
if (!l2_cache || !*mask) {
/* Assume only core siblings share cache with this CPU */
--
1.9.4
^ permalink raw reply related
* [PATCH v3 3/5] powerpc/smp: Rename init_thread_group_l1_cache_map() to make it generic
From: Gautham R. Shenoy @ 2020-12-10 10:38 UTC (permalink / raw)
To: Srikar Dronamraju, Anton Blanchard, Vaidyanathan Srinivasan,
Michael Ellerman, Michael Neuling, Nicholas Piggin, Nathan Lynch,
Peter Zijlstra, Valentin Schneider
Cc: Gautham R. Shenoy, linuxppc-dev, linux-kernel
In-Reply-To: <1607596739-32439-1-git-send-email-ego@linux.vnet.ibm.com>
From: "Gautham R. Shenoy" <ego@linux.vnet.ibm.com>
init_thread_group_l1_cache_map() initializes the per-cpu cpumask
thread_group_l1_cache_map with the core-siblings which share L1 cache
with the CPU. Make this function generic to the cache-property (L1 or
L2) and update a suitable mask. This is a preparatory patch for the
next patch where we will introduce discovery of thread-groups that
share L2-cache.
No functional change.
Signed-off-by: Gautham R. Shenoy <ego@linux.vnet.ibm.com>
---
arch/powerpc/kernel/smp.c | 17 ++++++++++-------
1 file changed, 10 insertions(+), 7 deletions(-)
diff --git a/arch/powerpc/kernel/smp.c b/arch/powerpc/kernel/smp.c
index f3290d5..9078b5b5 100644
--- a/arch/powerpc/kernel/smp.c
+++ b/arch/powerpc/kernel/smp.c
@@ -866,15 +866,18 @@ static struct thread_groups *__init get_thread_groups(int cpu,
return tg;
}
-static int init_thread_group_l1_cache_map(int cpu)
+static int __init init_thread_group_cache_map(int cpu, int cache_property)
{
int first_thread = cpu_first_thread_sibling(cpu);
int i, cpu_group_start = -1, err = 0;
struct thread_groups *tg = NULL;
+ cpumask_var_t *mask;
- tg = get_thread_groups(cpu, THREAD_GROUP_SHARE_L1,
- &err);
+ if (cache_property != THREAD_GROUP_SHARE_L1)
+ return -EINVAL;
+
+ tg = get_thread_groups(cpu, cache_property, &err);
if (!tg)
return err;
@@ -885,8 +888,8 @@ static int init_thread_group_l1_cache_map(int cpu)
return -ENODATA;
}
- zalloc_cpumask_var_node(&per_cpu(thread_group_l1_cache_map, cpu),
- GFP_KERNEL, cpu_to_node(cpu));
+ mask = &per_cpu(thread_group_l1_cache_map, cpu);
+ zalloc_cpumask_var_node(mask, GFP_KERNEL, cpu_to_node(cpu));
for (i = first_thread; i < first_thread + threads_per_core; i++) {
int i_group_start = get_cpu_thread_group_start(i, tg);
@@ -897,7 +900,7 @@ static int init_thread_group_l1_cache_map(int cpu)
}
if (i_group_start == cpu_group_start)
- cpumask_set_cpu(i, per_cpu(thread_group_l1_cache_map, cpu));
+ cpumask_set_cpu(i, *mask);
}
return 0;
@@ -976,7 +979,7 @@ static int init_big_cores(void)
int cpu;
for_each_possible_cpu(cpu) {
- int err = init_thread_group_l1_cache_map(cpu);
+ int err = init_thread_group_cache_map(cpu, THREAD_GROUP_SHARE_L1);
if (err)
return err;
--
1.9.4
^ permalink raw reply related
* [PATCH v3 2/5] powerpc/smp: Rename cpu_l1_cache_map as thread_group_l1_cache_map
From: Gautham R. Shenoy @ 2020-12-10 10:38 UTC (permalink / raw)
To: Srikar Dronamraju, Anton Blanchard, Vaidyanathan Srinivasan,
Michael Ellerman, Michael Neuling, Nicholas Piggin, Nathan Lynch,
Peter Zijlstra, Valentin Schneider
Cc: Gautham R. Shenoy, linuxppc-dev, linux-kernel
In-Reply-To: <1607596739-32439-1-git-send-email-ego@linux.vnet.ibm.com>
From: "Gautham R. Shenoy" <ego@linux.vnet.ibm.com>
On platforms which have the "ibm,thread-groups" property, the per-cpu
variable cpu_l1_cache_map keeps a track of which group of threads
within the same core share the L1 cache, Instruction and Data flow.
This patch renames the variable to "thread_group_l1_cache_map" to make
it consistent with a subsequent patch which will introduce
thread_group_l2_cache_map.
This patch introduces no functional change.
Signed-off-by: Gautham R. Shenoy <ego@linux.vnet.ibm.com>
---
arch/powerpc/kernel/smp.c | 14 +++++++-------
1 file changed, 7 insertions(+), 7 deletions(-)
diff --git a/arch/powerpc/kernel/smp.c b/arch/powerpc/kernel/smp.c
index 88d88ad..f3290d5 100644
--- a/arch/powerpc/kernel/smp.c
+++ b/arch/powerpc/kernel/smp.c
@@ -116,10 +116,10 @@ struct thread_groups_list {
static struct thread_groups_list tgl[NR_CPUS] __initdata;
/*
- * On big-cores system, cpu_l1_cache_map for each CPU corresponds to
+ * On big-cores system, thread_group_l1_cache_map for each CPU corresponds to
* the set its siblings that share the L1-cache.
*/
-DEFINE_PER_CPU(cpumask_var_t, cpu_l1_cache_map);
+DEFINE_PER_CPU(cpumask_var_t, thread_group_l1_cache_map);
/* SMP operations for this machine */
struct smp_ops_t *smp_ops;
@@ -866,7 +866,7 @@ static struct thread_groups *__init get_thread_groups(int cpu,
return tg;
}
-static int init_cpu_l1_cache_map(int cpu)
+static int init_thread_group_l1_cache_map(int cpu)
{
int first_thread = cpu_first_thread_sibling(cpu);
@@ -885,7 +885,7 @@ static int init_cpu_l1_cache_map(int cpu)
return -ENODATA;
}
- zalloc_cpumask_var_node(&per_cpu(cpu_l1_cache_map, cpu),
+ zalloc_cpumask_var_node(&per_cpu(thread_group_l1_cache_map, cpu),
GFP_KERNEL, cpu_to_node(cpu));
for (i = first_thread; i < first_thread + threads_per_core; i++) {
@@ -897,7 +897,7 @@ static int init_cpu_l1_cache_map(int cpu)
}
if (i_group_start == cpu_group_start)
- cpumask_set_cpu(i, per_cpu(cpu_l1_cache_map, cpu));
+ cpumask_set_cpu(i, per_cpu(thread_group_l1_cache_map, cpu));
}
return 0;
@@ -976,7 +976,7 @@ static int init_big_cores(void)
int cpu;
for_each_possible_cpu(cpu) {
- int err = init_cpu_l1_cache_map(cpu);
+ int err = init_thread_group_l1_cache_map(cpu);
if (err)
return err;
@@ -1372,7 +1372,7 @@ static inline void add_cpu_to_smallcore_masks(int cpu)
cpumask_set_cpu(cpu, cpu_smallcore_mask(cpu));
- for_each_cpu(i, per_cpu(cpu_l1_cache_map, cpu)) {
+ for_each_cpu(i, per_cpu(thread_group_l1_cache_map, cpu)) {
if (cpu_online(i))
set_cpus_related(i, cpu, cpu_smallcore_mask);
}
--
1.9.4
^ permalink raw reply related
* [PATCH v3 0/5] Extend Parsing "ibm, thread-groups" for Shared-L2 information
From: Gautham R. Shenoy @ 2020-12-10 10:38 UTC (permalink / raw)
To: Srikar Dronamraju, Anton Blanchard, Vaidyanathan Srinivasan,
Michael Ellerman, Michael Neuling, Nicholas Piggin, Nathan Lynch,
Peter Zijlstra, Valentin Schneider
Cc: Gautham R. Shenoy, linuxppc-dev, linux-kernel
From: "Gautham R. Shenoy" <ego@linux.vnet.ibm.com>
Hi,
This is the v2 of the patchset to extend parsing of "ibm,thread-groups" property
to discover the Shared-L2 cache information.
The previous versions can be found here :
v2 : https://lore.kernel.org/linuxppc-dev/1607533700-5546-1-git-send-email-ego@linux.vnet.ibm.com/T/#m043ea15d3832658527fca94765202b9cbefd330d
v1 : https://lore.kernel.org/linuxppc-dev/1607057327-29822-1-git-send-email-ego@linux.vnet.ibm.com/T/#m0fabffa1ea1a2807b362f25c849bb19415216520
Changes form v2-->v3:
* Fixed the build errors reported by the Kernel Test Robot for Patches 4 and 5.
Changes from v1-->v2:
Incorporate the review comments from Srikar and
fix a build error on !PPC64 configs reported by the kernel bot.
* Split Patch 1 into three patches
* First patch ensure that parse_thread_groups() is made generic to
support more than one property.
* Second patch renames cpu_l1_cache_map as
thread_group_l1_cache_map for consistency. No functional impact.
* The third patch makes init_thread_group_l1_cache_map()
generic. No functional impact.
* Patch 2 (Now patch 4): Incorporates the review comments from Srikar simplifying
the changes to update_mask_by_l2()
* Patch 3 (Now patch 5): Fix a build errors for 32-bit configs
reported by the kernel build bot.
Description of the Patchset
===========================
The "ibm,thread-groups" device-tree property is an array that is used
to indicate if groups of threads within a core share certain
properties. It provides details of which property is being shared by
which groups of threads. This array can encode information about
multiple properties being shared by different thread-groups within the
core.
Example: Suppose,
"ibm,thread-groups" = [1,2,4,8,10,12,14,9,11,13,15,2,2,4,8,10,12,14,9,11,13,15]
This can be decomposed up into two consecutive arrays:
a) [1,2,4,8,10,12,14,9,11,13,15]
b) [2,2,4,8,10,12,14,9,11,13,15]
where in,
a) provides information of Property "1" being shared by "2" groups,
each with "4" threads each. The "ibm,ppc-interrupt-server#s" of the
first group is {8,10,12,14} and the "ibm,ppc-interrupt-server#s" of
the second group is {9,11,13,15}. Property "1" is indicative of
the thread in the group sharing L1 cache, translation cache and
Instruction Data flow.
b) provides information of Property "2" being shared by "2" groups,
each group with "4" threads. The "ibm,ppc-interrupt-server#s" of
the first group is {8,10,12,14} and the
"ibm,ppc-interrupt-server#s" of the second group is
{9,11,13,15}. Property "2" indicates that the threads in each group
share the L2-cache.
The existing code assumes that the "ibm,thread-groups" encodes
information about only one property. Hence even on platforms which
encode information about multiple properties being shared by the
corresponding groups of threads, the current code will only pick the
first one. (In the above example, it will only consider
[1,2,4,8,10,12,14,9,11,13,15] but not [2,2,4,8,10,12,14,9,11,13,15]).
Furthermore, currently on platforms where groups of threads share L2
cache, we incorrectly create an extra CACHE level sched-domain that
maps to all the threads of the core.
For example, if "ibm,thread-groups" is
00000001 00000002 00000004 00000000
00000002 00000004 00000006 00000001
00000003 00000005 00000007 00000002
00000002 00000004 00000000 00000002
00000004 00000006 00000001 00000003
00000005 00000007
then, the sub-array
[00000002 00000002 00000004
00000000 00000002 00000004 00000006
00000001 00000003 00000005 00000007]
indicates that L2 (Property "2") is shared only between the threads of a single
group. There are "2" groups of threads where each group contains "4"
threads each. The groups being {0,2,4,6} and {1,3,5,7}.
However, the sched-domain hierarchy for CPUs 0,1 is
CPU0 attaching sched-domain(s):
domain-0: span=0,2,4,6 level=SMT
domain-1: span=0-7 level=CACHE
domain-2: span=0-15,24-39,48-55 level=MC
domain-3: span=0-55 level=DIE
CPU1 attaching sched-domain(s):
domain-0: span=1,3,5,7 level=SMT
domain-1: span=0-7 level=CACHE
domain-2: span=0-15,24-39,48-55 level=MC
domain-3: span=0-55 level=DIE
where the CACHE domain reports that L2 is shared across the entire
core which is incorrect on such platforms.
This patchset remedies these issues by extending the parsing support
for "ibm,thread-groups" to discover information about multiple
properties being shared by the corresponding groups of threads. In
particular we cano now detect if the groups of threads within a core
share the L2-cache. On such platforms, we populate the populating the
cpu_l2_cache_mask of every CPU to the core-siblings which share L2
with the CPU as specified in the by the "ibm,thread-groups" property
array.
With the patchset, the sched-domain hierarchy is correctly
reported. For eg for CPUs 0,1, with the patchset
CPU0 attaching sched-domain(s):
domain-0: span=0,2,4,6 level=SMT
domain-1: span=0-15,24-39,48-55 level=MC
domain-2: span=0-55 level=DIE
CPU1 attaching sched-domain(s):
domain-0: span=1,3,5,7 level=SMT
domain-1: span=0-15,24-39,48-55 level=MC
domain-2: span=0-55 level=DIE
The CACHE domain with span=0,2,4,6 for CPU 0 (span=1,3,5,7 for CPU 1
resp.) gets degenerated into the SMT domain. Furthermore, the
last-level-cache domain gets correctly set to the SMT sched-domain.
Testing
==========
With the producer-consumer
testcase(https://github.com/gautshen/misc/tree/master/producer_consumer)
where in the producer thread performs writes to 4096 random locations,
and the consumer thread subsequently reads from those 4096 random
location. We measure the time taken by the consumer to finish the 4096
reads (called an iteration of the consumer). Thus lower the value,
better is the result.
The best case occurs when the producer and consumer are affined to the
same L2 cache domain (Eg: CPU0, CPU2). On the platform with the
thread-groups sharing L2,
|-----------------------------------------------|
| Without Patch |
|-----------|-----------|-----------------------|
| Producer | Consumer | Avg time per Consumer |
| Affinity | Affinity | Iteration |
|-----------|-----------|-----------------------|
| CPU0 | CPU2 | 235us |
|-----------|-----------|-----------------------|
|Not affined|Not affined| 347us |
|-----------------------------------------------|
We see that out-of-box, the average time per consumer iteration is
higher since the tasks can be placed anywhere within the core without
them being in the L2 domain.
|-----------------------------------------------|
| With Patch |
|-----------|-----------|-----------------------|
| Producer | Consumer | Avg time per Consumer |
| Affinity | Affinity | Iteration |
|-----------|-----------|-----------------------|
| CPU0 | CPU2 | 235us |
|-----------|-----------|-----------------------|
|Not affined|Not affined| 236us |
|-----------------------------------------------|
With the patch, since the L2 domain is correctly identified, the
scheduler does the right thing by co-locating the producer and
consumer on the same L2 domain, thereby yielding the out-of-box
performance matching the best case.
Finally, this patchset reports the correct shared_cpu_map/list in the
sysfs for L2 cache on such platforms. With the patchset for CPUs0, 1,
for L2 cache we see the correct shared_cpu_map/list
/sys/devices/system/cpu/cpu0/cache/index2/shared_cpu_list:0,2,4,6
/sys/devices/system/cpu/cpu0/cache/index2/shared_cpu_map:000000,00000055
/sys/devices/system/cpu/cpu1/cache/index2/shared_cpu_list:1,3,5,7
/sys/devices/system/cpu/cpu1/cache/index2/shared_cpu_map:000000,000000aa
The patchset has been tested on older platforms which encode only the
L1 sharing information via "ibm,thread-groups" and there is no
regression found.
Gautham R. Shenoy (5):
powerpc/smp: Parse ibm,thread-groups with multiple properties
powerpc/smp: Rename cpu_l1_cache_map as thread_group_l1_cache_map
powerpc/smp: Rename init_thread_group_l1_cache_map() to make it
generic
powerpc/smp: Add support detecting thread-groups sharing L2 cache
powerpc/cacheinfo: Print correct cache-sibling map/list for L2 cache
arch/powerpc/include/asm/smp.h | 6 +
arch/powerpc/kernel/cacheinfo.c | 30 +++--
arch/powerpc/kernel/smp.c | 241 ++++++++++++++++++++++++++++------------
3 files changed, 198 insertions(+), 79 deletions(-)
--
1.9.4
^ permalink raw reply
* Re: [PATCH kernel v2] powerpc/powernv/npu: Do not attempt NPU2 setup on POWER8NVL NPU
From: Michael Ellerman @ 2020-12-10 11:29 UTC (permalink / raw)
To: Alexey Kardashevskiy, linuxppc-dev
Cc: Leonardo Augusto Guimarães Garcia, kvm-ppc, stable,
David Gibson
In-Reply-To: <20201122073828.15446-1-aik@ozlabs.ru>
On Sun, 22 Nov 2020 18:38:28 +1100, Alexey Kardashevskiy wrote:
> We execute certain NPU2 setup code (such as mapping an LPID to a device
> in NPU2) unconditionally if an Nvlink bridge is detected. However this
> cannot succeed on POWER8NVL machines and errors appear in dmesg. This is
> harmless as skiboot returns an error and the only place we check it is
> vfio-pci but that code does not get called on P8+ either.
>
> This adds a check if pnv_npu2_xxx helpers are called on a machine with
> NPU2 which initializes pnv_phb::npu in pnv_npu2_init();
> pnv_phb::npu==NULL on POWER8/NVL (Naples).
>
> [...]
Applied to powerpc/next.
[1/1] powerpc/powernv/npu: Do not attempt NPU2 setup on POWER8NVL NPU
https://git.kernel.org/powerpc/c/b1198a88230f2ce50c271e22b82a8b8610b2eea9
cheers
^ permalink raw reply
* Re: [PATCH kernel v3] powerpc/pci: Remove LSI mappings on device teardown
From: Michael Ellerman @ 2020-12-10 11:29 UTC (permalink / raw)
To: Alexey Kardashevskiy, linuxppc-dev
Cc: Frederic Barrat, Oliver O'Halloran, Cédric Le Goater
In-Reply-To: <20201202005222.5477-1-aik@ozlabs.ru>
On Wed, 2 Dec 2020 11:52:22 +1100, Alexey Kardashevskiy wrote:
> When a passthrough IO adapter is removed from a pseries machine using hash
> MMU and the XIVE interrupt mode, the POWER hypervisor expects the guest OS
> to clear all page table entries related to the adapter. If some are still
> present, the RTAS call which isolates the PCI slot returns error 9001
> "valid outstanding translations" and the removal of the IO adapter fails.
> This is because when the PHBs are scanned, Linux maps automatically the
> INTx interrupts in the Linux interrupt number space but these are never
> removed.
>
> [...]
Applied to powerpc/next.
[1/1] powerpc/pci: Remove LSI mappings on device teardown
https://git.kernel.org/powerpc/c/450be4960a0fb89b931a6bb3c3f0bb538ac4c03c
cheers
^ permalink raw reply
* Re: [PATCH] powerpc/book3s64/kuap: Improve error reporting with KUAP
From: Michael Ellerman @ 2020-12-10 11:29 UTC (permalink / raw)
To: mpe, linuxppc-dev, Aneesh Kumar K.V
In-Reply-To: <20201208031539.84878-1-aneesh.kumar@linux.ibm.com>
On Tue, 8 Dec 2020 08:45:39 +0530, Aneesh Kumar K.V wrote:
> This partially reverts commit eb232b162446 ("powerpc/book3s64/kuap: Improve
> error reporting with KUAP") and update the fault handler to print
>
> [ 55.022514] Kernel attempted to access user page (7e6725b70000) - exploit attempt? (uid: 0)
> [ 55.022528] BUG: Unable to handle kernel data access on read at 0x7e6725b70000
> [ 55.022533] Faulting instruction address: 0xc000000000e8b9bc
> [ 55.022540] Oops: Kernel access of bad area, sig: 11 [#1]
> ....
>
> [...]
Applied to powerpc/next.
[1/1] powerpc/book3s64/kuap: Improve error reporting with KUAP
https://git.kernel.org/powerpc/c/eb232b1624462752dc916d9015b31ecdac0a01f1
cheers
^ permalink raw reply
* Re: [PATCH v7 00/22] Kernel userspace access/execution prevention with hash translation
From: Michael Ellerman @ 2020-12-10 11:29 UTC (permalink / raw)
To: mpe, linuxppc-dev, Aneesh Kumar K.V
In-Reply-To: <20201127044424.40686-1-aneesh.kumar@linux.ibm.com>
On Fri, 27 Nov 2020 10:14:02 +0530, Aneesh Kumar K.V wrote:
> This patch series implements KUAP and KUEP with hash translation mode using
> memory keys. The kernel now uses memory protection key 3 to control access
> to the kernel. Kernel page table entries are now configured with key 3.
> Access to locations configured with any other key value is denied when in
> kernel mode (MSR_PR=0). This includes userspace which is by default configured
> with key 0.
>
> [...]
Patches 1-20, 22 applied to powerpc/next.
[01/22] powerpc: Add new macro to handle NESTED_IFCLR
https://git.kernel.org/powerpc/c/c3d35ddd1ec874690a4e8da5a18497256f1ffa9a
[02/22] KVM: PPC: BOOK3S: PR: Ignore UAMOR SPR
https://git.kernel.org/powerpc/c/9f378b9f007cc94beadea40df83cc62a76975c6f
[03/22] powerpc/book3s64/kuap/kuep: Add PPC_PKEY config on book3s64
https://git.kernel.org/powerpc/c/227ae625522c65c4535cabe407f47abc058585ed
[04/22] powerpc/book3s64/kuap/kuep: Move uamor setup to pkey init
https://git.kernel.org/powerpc/c/39df17bc20059c84ddc6f91831fce2e2cc79a6f3
[05/22] powerpc/book3s64/kuap: Move KUAP related function outside radix
https://git.kernel.org/powerpc/c/3b47b7549ead0719e94022c6742199333c7c8d9f
[06/22] powerpc/book3s64/kuep: Move KUEP related function outside radix
https://git.kernel.org/powerpc/c/57b7505aa8ba13eb18ffabeb689ac64343c53aaa
[07/22] powerpc/book3s64/kuap: Rename MMU_FTR_RADIX_KUAP and MMU_FTR_KUEP
https://git.kernel.org/powerpc/c/d5b810b5c938e73fd21b2b05ef6a79837eeaa305
[08/22] powerpc/book3s64/kuap: Use Key 3 for kernel mapping with hash translation
https://git.kernel.org/powerpc/c/d94b827e89dc3f92cd871d10f4992a6bd3c861e5
[09/22] powerpc/exec: Set thread.regs early during exec
https://git.kernel.org/powerpc/c/d7df77e89039623ededf0ece7b4358f7c9ecbaae
[10/22] powerpc/book3s64/pkeys: Store/restore userspace AMR/IAMR correctly on entry and exit from kernel
https://git.kernel.org/powerpc/c/8e560921b58cbc18e192f0ac273d307a37a144f9
[11/22] powerpc/book3s64/pkeys: Inherit correctly on fork.
https://git.kernel.org/powerpc/c/f643fcab74c005ddfdda68c69909f03bde766ff1
[12/22] powerpc/book3s64/pkeys: Reset userspace AMR correctly on exec
https://git.kernel.org/powerpc/c/d5fa30e6993ffcdd1859d8dab1a07a6f6c6e7c3f
[13/22] powerpc/ptrace-view: Use pt_regs values instead of thread_struct based one.
https://git.kernel.org/powerpc/c/edc541ecaae73d498a49b9ca82bc66255d9e0720
[14/22] powerpc/book3s64/pkeys: Don't update SPRN_AMR when in kernel mode.
https://git.kernel.org/powerpc/c/48a8ab4eeb8271f2a0e2ca3cf80844a59acca153
[15/22] powerpc/book3s64/kuap: Restrict access to userspace based on userspace AMR
https://git.kernel.org/powerpc/c/4d6c551e9f548f7675a01eff229d09ab41162a25
[16/22] powerpc/book3s64/kuap: Improve error reporting with KUAP
https://git.kernel.org/powerpc/c/eb232b1624462752dc916d9015b31ecdac0a01f1
[17/22] powerpc/book3s64/kuap: Use Key 3 to implement KUAP with hash translation.
https://git.kernel.org/powerpc/c/fa46c2fa6ffbedab3a3cbcbde1292468979e830b
[18/22] powerpc/book3s64/kuep: Use Key 3 to implement KUEP with hash translation.
https://git.kernel.org/powerpc/c/292f86c4c683a1064aff7210348da088c1573ee0
[19/22] powerpc/book3s64/hash/kuap: Enable kuap on hash
https://git.kernel.org/powerpc/c/b2ff33a10c8b3e9d260c57df38b5cd3765a0b785
[20/22] powerpc/book3s64/hash/kuep: Enable KUEP on hash
https://git.kernel.org/powerpc/c/c91435d95c49f4053b05ba03b41dd7ed0fbd6c71
[22/22] powerpc/book3s64/pkeys: Optimize KUAP and KUEP feature disabled case
https://git.kernel.org/powerpc/c/ec0f9b98f7d01b15c804e77e12a515ffc56d7309
cheers
^ permalink raw reply
* Re: [PATCH] powerpc/perf: Invoke per-CPU variable access with disabled interrupts
From: Michael Ellerman @ 2020-12-10 11:29 UTC (permalink / raw)
To: mpe, Athira Rajeev; +Cc: bigeasy, maddy, linuxppc-dev
In-Reply-To: <1606814880-1720-1-git-send-email-atrajeev@linux.vnet.ibm.com>
On Tue, 1 Dec 2020 04:28:00 -0500, Athira Rajeev wrote:
> The power_pmu_event_init() callback access per-cpu variable
> (cpu_hw_events) to check for event constraints and Branch Stack
> (BHRB). Current usage is to disable preemption when accessing the
> per-cpu variable, but this does not prevent timer callback from
> interrupting event_init. Fix this by using 'local_irq_save/restore'
> to make sure the code path is invoked with disabled interrupts.
>
> [...]
Applied to powerpc/next.
[1/1] powerpc/perf: Invoke per-CPU variable access with disabled interrupts
https://git.kernel.org/powerpc/c/f66de7ac4849eb42a7b18e26b8ee49e08130fd27
cheers
^ permalink raw reply
* Re: [PATCH V2 0/7] powerpc/perf: Fixes for power10 PMU
From: Michael Ellerman @ 2020-12-10 11:29 UTC (permalink / raw)
To: mpe, Athira Rajeev; +Cc: maddy, linuxppc-dev
In-Reply-To: <1606409684-1589-1-git-send-email-atrajeev@linux.vnet.ibm.com>
On Thu, 26 Nov 2020 11:54:37 -0500, Athira Rajeev wrote:
> Patchset contains PMU fixes for power10.
>
> This patchset contains 7 patches.
> Patch1 includes fix to update event code with radix_scope_qual
> bit in power10.
> Patch2 and Patch3 updates the event group constraints for L2/L3
> and threshold events in power10.
> Patch4, patch5 and patch6 includes the event code changes for
> l2/l3 events and some of the generic events.
> Patch7 adds fixes for PMCCEXT bit in power10.
>
> [...]
Applied to powerpc/next.
[1/7] powerpc/perf: Fix to update radix_scope_qual in power10
https://git.kernel.org/powerpc/c/d3afd28cd2f35b2a1046b76e0cf010b684da2e84
[2/7] powerpc/perf: Update the PMU group constraints for l2l3 events in power10
https://git.kernel.org/powerpc/c/e924be7b0b0d1f37d0509c854a92c7a71e3cdfe7
[3/7] powerpc/perf: Fix the PMU group constraints for threshold events in power10
https://git.kernel.org/powerpc/c/0263bbb377af0c2d38bc8b2ad2ff147e240094de
[4/7] powerpc/perf: Add generic and cache event list for power10 DD1
https://git.kernel.org/powerpc/c/c0e3985790251b307b7b71b687ed0128741b3f34
[5/7] powerpc/perf: Fix to update generic event codes for power10
https://git.kernel.org/powerpc/c/1f12316394e3b241e70ed620ca846002c8ace3ec
[6/7] powerpc/perf: Fix to update cache events with l2l3 events in power10
https://git.kernel.org/powerpc/c/9a8ee52634235993273c43ef67669d8168497dd7
[7/7] powerpc/perf: MMCR0 control for PMU registers under PMCC=00
https://git.kernel.org/powerpc/c/91668ab7db4bcfae332e561df1de2401f3f18553
cheers
^ permalink raw reply
* Re: [PATCH V2] powerpc/perf: Fix crash with is_sier_available when pmu is not set
From: Michael Ellerman @ 2020-12-10 11:29 UTC (permalink / raw)
To: mpe, Athira Rajeev; +Cc: sachinp, maddy, linuxppc-dev
In-Reply-To: <1606185640-1720-1-git-send-email-atrajeev@linux.vnet.ibm.com>
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 1628 bytes --]
On Mon, 23 Nov 2020 21:40:40 -0500, Athira Rajeev wrote:
> On systems without any specific PMU driver support registered, running
> 'perf record' with —intr-regs will crash ( perf record -I <workload> ).
>
> The relevant portion from crash logs and Call Trace:
>
> Unable to handle kernel paging request for data at address 0x00000068
> Faulting instruction address: 0xc00000000013eb18
> Oops: Kernel access of bad area, sig: 11 [#1]
> CPU: 2 PID: 13435 Comm: kill Kdump: loaded Not tainted 4.18.0-193.el8.ppc64le #1
> NIP: c00000000013eb18 LR: c000000000139f2c CTR: c000000000393d80
> REGS: c0000004a07ab4f0 TRAP: 0300 Not tainted (4.18.0-193.el8.ppc64le)
> NIP [c00000000013eb18] is_sier_available+0x18/0x30
> LR [c000000000139f2c] perf_reg_value+0x6c/0xb0
> Call Trace:
> [c0000004a07ab770] [c0000004a07ab7c8] 0xc0000004a07ab7c8 (unreliable)
> [c0000004a07ab7a0] [c0000000003aa77c] perf_output_sample+0x60c/0xac0
> [c0000004a07ab840] [c0000000003ab3f0] perf_event_output_forward+0x70/0xb0
> [c0000004a07ab8c0] [c00000000039e208] __perf_event_overflow+0x88/0x1a0
> [c0000004a07ab910] [c00000000039e42c] perf_swevent_hrtimer+0x10c/0x1d0
> [c0000004a07abc50] [c000000000228b9c] __hrtimer_run_queues+0x17c/0x480
> [c0000004a07abcf0] [c00000000022aaf4] hrtimer_interrupt+0x144/0x520
> [c0000004a07abdd0] [c00000000002a864] timer_interrupt+0x104/0x2f0
> [c0000004a07abe30] [c0000000000091c4] decrementer_common+0x114/0x120
>
> [...]
Applied to powerpc/next.
[1/1] powerpc/perf: Fix crash with is_sier_available when pmu is not set
https://git.kernel.org/powerpc/c/f75e7d73bdf73f07b0701a6d21c111ef5d9021dd
cheers
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox