* [PATCH 1/2] PCI: Add new PCIe Fabric End Node flag, PCI_DEV_FLAGS_NO_RELAXED_ORDERING
From: Alexander Duyck @ 2017-05-02 18:10 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170502165329.GB26406@linux.intel.com>
On Tue, May 2, 2017 at 9:53 AM, Raj, Ashok <ashok.raj@intel.com> wrote:
> On Tue, May 02, 2017 at 09:39:34AM -0700, Alexander Duyck wrote:
>> On Mon, May 1, 2017 at 4:13 PM, Casey Leedom <leedom@chelsio.com> wrote:
>> > The new flag PCI_DEV_FLAGS_NO_RELAXED_ORDERING indicates that the Relaxed
>> > Ordering Attribute should not be used on Transaction Layer Packets destined
>> > for the PCIe End Node so flagged. Initially flagged this way are Intel
>> > E5-26xx Root Complex Ports which suffer from a Flow Control Credit
>> > Performance Problem and AMD A1100 ARM ("SEATTLE") Root Complex Ports which
>> > don't obey PCIe 3.0 ordering rules which can lead to Data Corruption.
>>
>> So this is a good first step though might I suggest one other change.
>>
>> We may want to add logic to the core PCIe code that clears the "Enable
>> Relaxed Ordering" bit in the device control register for all devices
>> hanging off of this root complex. Assuming the devices conform to the
>> PCIe spec doing that should disable relaxed ordering in a device
>> agnostic way that then enables us at a driver level to just enable the
>> feature always without having to perform any checks for your flag. We
>> could probably do that as a part of probing the PCIe interfaces
>> hanging off of these devices.
>
> I suppose you don't want to turn off RO completely on the device. When
> traffic is targetted to mmio for peer to peer reasons RO has performance
> upside. The specific issue with these root ports indicate limitation using
> RO for traffic targetting coherent memory.
Actually my main concern here is virtualization. If I take the PCIe
function and direct assign it I have no way of seeing the root complex
flag as it is now virtualized away. In the meantime the guest now has
the ability to enable the function and sees nothing that says you
can't enable relaxed ordering which in turn ends up potentially
causing data corruption on the system. I want relaxed ordering
disabled before I even consider assigning it to the guest on the
systems where this would be an issue.
I prefer to err on the side of caution with this. Enabling Relaxed
Ordering is technically a performance enhancement, so we function but
not as well as we would like, while having it enabled when there are
issues can lead to data corruption. I would weigh the risk of data
corruption the thing to be avoided and of much higher priority than
enabling improved performance. As such I say we should default the
relaxed ordering attribute to off in general and look at
"white-listing" it in for various architectures and/or chipsets that
support/need it rather than having it enabled by default and trying to
switch it off after the fact when we find some new issue.
So for example, in the case of x86 it seems like there are multiple
root complexes that have issues, and the gains for enabling it with
standard DMA to host memory are small. As such we may want to default
it to off via the architecture specific PCIe code and then look at
having "white-list" cases where we enable it for things like
peer-to-peer accesses. In the case of SPARC we could look at
defaulting it to on, and only "black-list" any cases where there might
be issues since SPARC relies on this in a significant way for
performance. In the case of ARM and other architectures it is a bit of
a toss-up. I would say we could just default it to on for now and
"black-list" anything that doesn't work, or we could go the other way
like I suggested for x86. It all depends on what the ARM community
would want to agree on for this. I would say unless it makes a
significant difference like it does in the case of SPARC we are
probably better off just defaulting it to off.
- Alex
^ permalink raw reply
* [PATCH] arm: pmu: Get PMU working when the A53 is run in 32 bit mode
From: Marc Zyngier @ 2017-05-02 17:53 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <e32b1d89-b349-5a45-565a-19463032adbc@gmail.com>
On Tue, May 02 2017 at 6:37:40 pm BST, Florian Fainelli <f.fainelli@gmail.com> wrote:
> On 05/02/2017 09:50 AM, Marc Zyngier wrote:
>> On Tue, May 02 2017 at 4:51:55 pm BST, Florian Fainelli <f.fainelli@gmail.com> wrote:
>>> Hi Mark,
>>>
>>> On 05/02/2017 07:17 AM, Marc Zyngier wrote:
>>>> Hi Al,
>>>>
>>>> On 02/05/17 15:01, Al Cooper wrote:
>>>>> From: Al Cooper <al.cooper@broadcom.com>
>>>>>
>>>>> When the A53 is run in A15 (32 bit) mode, the registers used to
>>>>> access the counters are A15 style registers, but the actual
>>>>> counters are the A53 counters not A15 counters. This patch will
>>>>> select a PMU counters map for the A53 if the device tree pmu
>>>>> "compatible" property includes "arm,cortex-a53-pmu".
>>>>
>>>> I wasn't aware of an "A15 mode"! Is there an ARM3 mode, while we're at
>>>> it? ;-)
>>>
>>> This is referring to how our Device Tree and kernel end-up "viewing" the
>>> PMU (based on provided compatible strings) but this probably should be
>>> omitted for clarity.
>>
>> That's certainly wrong from both an architectural and implementation
>> PoV. Although there is some level of compatibility between the ARMv7 and
>> ARMv8 PMU architectures, they are distinct beasts.
>
> Yes, we are well aware of that, which is why I don't think it's even
> relevant to this discussion here because it's a known implementation
> issue on our end.
>
>>
>>>>
>>>> More seriously, you seem to take the problem from the wrong end. If you
>>>> have an ARMv8 core, you should use the PMUv3 driver (because that is
>>>> what your A53 has), and not the ARMv7 PMU.
>>>>
>>>> To that affect, I've posted this[1] a while ago. Can you please give it
>>>> a go?
>>>
>>> That seems to be the right direction, however don't you also need to
>>> possibly expose other PMU types as well? Cortex-A53 and Cortex-A57 PMUs
>>> (and possibly more) for instance because there are additional counters
>>> that can be defined specifically for those, e.g: LL = L2 cache on A53,
>>> see [1].
>>
>> That's pretty much orthogonal. Once we have a common driver for PMUv3 on
>> both 32 and 64bit, adding implementation-specific events can be done for
>> both architecture.
>
> My comment was not so much about the PMU-specific events, but about the
> fact that if you make changes to the PMUv3 between 32-bit and 64-bit
> kernels, we might as well bring all other PMU models that have a
> potential for being shared between 32-bit and 64-bit in one go.
I'm only concerned about the CPU PMU so far, as my main goal is
virtualization (and I have no desire to expose any other form of PMU to
a guest). Non-CPU PMUs should be mostly architecture agnostic already,
and thus pretty easy to enable.
Thanks,
M.
--
Jazz is not dead, it just smell funny.
^ permalink raw reply
* [PATCH v2] ARM: dts: imx: add Gateworks Ventana GW5600 support
From: Tim Harvey @ 2017-05-02 17:39 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1492197481-16638-1-git-send-email-tharvey@gateworks.com>
The Gateworks Ventana GW5600 is a media-centric single-board computer based on
the NXP IMX6 SoC with the following features:
* PoE (emulated 802.3af)
* IMX6 DualLite Soc (supports IMX6S,IMX6DL,IMX6Q)
* 1GiB DDR3 DRAM (supports up to 4GiB)
* 8GB eMMC
* 1x microSD connector
* Gateworks System Controller:
- hardware watchdog
- hardware monitor
- pushbutton controller
- EEPROM storage
- power control
* 1x bi-color USER LED
* 1x front-panel pushbutton
* 1x front-panel GbE
* 2x front panel USB 2.0
* 1x front panel USB OTG
* 1x SIM socket
* 1x miniPCIe socket with SATA (mSATA)
* 1x miniPCIe socket with USB 2.0 (Modem)
* 1x miniPCIe socket with PCIe, USB 2.0, and SIM
* RS232/RS485 serial
- 2x RS232 UARTs (off-board connector)
- 1x RS485 (loading option)
* 4x digital I/O signals (PWM/I2C/GPIO/5V/3.3V options)
* 1x analog input (0 to 5V)
* 1x CAN (loading option)
* off-board LVDS:
- I2C
- 12V
- LED driver (4x 330mA strings)
- matrix keypad controller (8row x 10col)
- I2S
- dual-channel LVDS
- PWM
* off-board video input:
- 16bit parallel / MIPI (IPU1_CSI0)
* GPS (loading option)
* Analog Video Input (CVBS) 3 inputs (1 active at a time)
* Analog Audio Input/Output (2ch Line level, optional MIC/HP drivers)
* HDMI out
* JTAG programmable
* Inertial Module
Signed-off-by: Tim Harvey <tharvey@gateworks.com>
---
v2:
- use hyphen instead of underscore in node names
- indicate address in memory node name
- drop leading zero's in unit-addresses
- dropped unnecessary container node in iomux
- sort iomux pinctrl nodes alphabetically
- remove extra newlines in pinctrl defines
- use MATRIX_KEY() macro and event codes from input bindings
- removed unused fixed-clock
Signed-off-by: Tim Harvey <tharvey@gateworks.com>
---
arch/arm/boot/dts/Makefile | 2 +
arch/arm/boot/dts/imx6dl-gw560x.dts | 55 +++
arch/arm/boot/dts/imx6q-gw560x.dts | 59 +++
arch/arm/boot/dts/imx6qdl-gw560x.dtsi | 749 ++++++++++++++++++++++++++++++++++
4 files changed, 865 insertions(+)
create mode 100644 arch/arm/boot/dts/imx6dl-gw560x.dts
create mode 100644 arch/arm/boot/dts/imx6q-gw560x.dts
create mode 100644 arch/arm/boot/dts/imx6qdl-gw560x.dtsi
diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index 8774143..0ffe732 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -352,6 +352,7 @@ dtb-$(CONFIG_SOC_IMX6Q) += \
imx6dl-gw551x.dtb \
imx6dl-gw552x.dtb \
imx6dl-gw553x.dtb \
+ imx6dl-gw560x.dtb \
imx6dl-gw5903.dtb \
imx6dl-gw5904.dtb \
imx6dl-hummingboard.dtb \
@@ -397,6 +398,7 @@ dtb-$(CONFIG_SOC_IMX6Q) += \
imx6q-gw551x.dtb \
imx6q-gw552x.dtb \
imx6q-gw553x.dtb \
+ imx6q-gw560x.dtb \
imx6q-gw5903.dtb \
imx6q-gw5904.dtb \
imx6q-h100.dtb \
diff --git a/arch/arm/boot/dts/imx6dl-gw560x.dts b/arch/arm/boot/dts/imx6dl-gw560x.dts
new file mode 100644
index 0000000..21bdfaf
--- /dev/null
+++ b/arch/arm/boot/dts/imx6dl-gw560x.dts
@@ -0,0 +1,55 @@
+/*
+ * Copyright 2017 Gateworks Corporation
+ *
+ * This file is dual-licensed: you can use it either under the terms
+ * of the GPL or the X11 license, at your option. Note that this dual
+ * licensing only applies to this file, and not this project as a
+ * whole.
+ *
+ * a) This file is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation; either version 2 of
+ * the License, or (at your option) any later version.
+ *
+ * This file is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public
+ * License along with this file; if not, write to the Free
+ * Software Foundation, Inc., 51 Franklin St, Fifth Floor, Boston,
+ * MA 02110-1301 USA
+ *
+ * Or, alternatively,
+ *
+ * b) Permission is hereby granted, free of charge, to any person
+ * obtaining a copy of this software and associated documentation
+ * files (the "Software"), to deal in the Software without
+ * restriction, including without limitation the rights to use,
+ * copy, modify, merge, publish, distribute, sublicense, and/or
+ * sell copies of the Software, and to permit persons to whom the
+ * Software is furnished to do so, subject to the following
+ * conditions:
+ *
+ * The above copyright notice and this permission notice shall be
+ * included in all copies or substantial portions of the Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
+ * EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES
+ * OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
+ * NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT
+ * HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY,
+ * WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
+ * OTHER DEALINGS IN THE SOFTWARE.
+ */
+
+/dts-v1/;
+#include "imx6dl.dtsi"
+#include "imx6qdl-gw560x.dtsi"
+
+/ {
+ model = "Gateworks Ventana i.MX6 DualLite/Solo GW560X";
+ compatible = "gw,imx6dl-gw560x", "gw,ventana", "fsl,imx6dl";
+};
diff --git a/arch/arm/boot/dts/imx6q-gw560x.dts b/arch/arm/boot/dts/imx6q-gw560x.dts
new file mode 100644
index 0000000..735f2bb
--- /dev/null
+++ b/arch/arm/boot/dts/imx6q-gw560x.dts
@@ -0,0 +1,59 @@
+/*
+ * Copyright 2017 Gateworks Corporation
+ *
+ * This file is dual-licensed: you can use it either under the terms
+ * of the GPL or the X11 license, at your option. Note that this dual
+ * licensing only applies to this file, and not this project as a
+ * whole.
+ *
+ * a) This file is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation; either version 2 of
+ * the License, or (at your option) any later version.
+ *
+ * This file is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public
+ * License along with this file; if not, write to the Free
+ * Software Foundation, Inc., 51 Franklin St, Fifth Floor, Boston,
+ * MA 02110-1301 USA
+ *
+ * Or, alternatively,
+ *
+ * b) Permission is hereby granted, free of charge, to any person
+ * obtaining a copy of this software and associated documentation
+ * files (the "Software"), to deal in the Software without
+ * restriction, including without limitation the rights to use,
+ * copy, modify, merge, publish, distribute, sublicense, and/or
+ * sell copies of the Software, and to permit persons to whom the
+ * Software is furnished to do so, subject to the following
+ * conditions:
+ *
+ * The above copyright notice and this permission notice shall be
+ * included in all copies or substantial portions of the Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
+ * EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES
+ * OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
+ * NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT
+ * HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY,
+ * WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
+ * OTHER DEALINGS IN THE SOFTWARE.
+ */
+
+/dts-v1/;
+#include "imx6q.dtsi"
+#include "imx6qdl-gw560x.dtsi"
+
+/ {
+ model = "Gateworks Ventana i.MX6 Dual/Quad GW560X";
+ compatible = "gw,imx6q-gw560x", "gw,ventana", "fsl,imx6q";
+};
+
+&sata {
+ status = "okay";
+};
diff --git a/arch/arm/boot/dts/imx6qdl-gw560x.dtsi b/arch/arm/boot/dts/imx6qdl-gw560x.dtsi
new file mode 100644
index 0000000..d894dde
--- /dev/null
+++ b/arch/arm/boot/dts/imx6qdl-gw560x.dtsi
@@ -0,0 +1,749 @@
+/*
+ * Copyright 2017 Gateworks Corporation
+ *
+ * This file is dual-licensed: you can use it either under the terms
+ * of the GPL or the X11 license, at your option. Note that this dual
+ * licensing only applies to this file, and not this project as a
+ * whole.
+ *
+ * a) This file is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation; either version 2 of
+ * the License, or (at your option) any later version.
+ *
+ * This file is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public
+ * License along with this file; if not, write to the Free
+ * Software Foundation, Inc., 51 Franklin St, Fifth Floor, Boston,
+ * MA 02110-1301 USA
+ *
+ * Or, alternatively,
+ *
+ * b) Permission is hereby granted, free of charge, to any person
+ * obtaining a copy of this software and associated documentation
+ * files (the "Software"), to deal in the Software without
+ * restriction, including without limitation the rights to use,
+ * copy, modify, merge, publish, distribute, sublicense, and/or
+ * sell copies of the Software, and to permit persons to whom the
+ * Software is furnished to do so, subject to the following
+ * conditions:
+ *
+ * The above copyright notice and this permission notice shall be
+ * included in all copies or substantial portions of the Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
+ * EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES
+ * OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
+ * NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT
+ * HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY,
+ * WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
+ * OTHER DEALINGS IN THE SOFTWARE.
+ */
+
+#include <dt-bindings/gpio/gpio.h>
+#include <dt-bindings/input/input.h>
+
+/ {
+ /* these are used by bootloader for disabling nodes */
+ aliases {
+ led0 = &led0;
+ led1 = &led1;
+ led2 = &led2;
+ ssi0 = &ssi1;
+ usb0 = &usbh1;
+ usb1 = &usbotg;
+ };
+
+ chosen {
+ stdout-path = &uart2;
+ };
+
+ backlight-display {
+ compatible = "pwm-backlight";
+ pwms = <&pwm4 0 5000000>;
+ brightness-levels = <
+ 0 1 2 3 4 5 6 7 8 9
+ 10 11 12 13 14 15 16 17 18 19
+ 20 21 22 23 24 25 26 27 28 29
+ 30 31 32 33 34 35 36 37 38 39
+ 40 41 42 43 44 45 46 47 48 49
+ 50 51 52 53 54 55 56 57 58 59
+ 60 61 62 63 64 65 66 67 68 69
+ 70 71 72 73 74 75 76 77 78 79
+ 80 81 82 83 84 85 86 87 88 89
+ 90 91 92 93 94 95 96 97 98 99
+ 100
+ >;
+ default-brightness-level = <100>;
+ };
+
+ backlight-keypad {
+ compatible = "gpio-backlight";
+ gpios = <&gpio4 30 GPIO_ACTIVE_HIGH>;
+ default-on;
+ };
+
+ leds {
+ compatible = "gpio-leds";
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_gpio_leds>;
+
+ led0: user1 {
+ label = "user1";
+ gpios = <&gpio4 6 GPIO_ACTIVE_HIGH>; /* MX6_PANLEDG */
+ default-state = "on";
+ linux,default-trigger = "heartbeat";
+ };
+
+ led1: user2 {
+ label = "user2";
+ gpios = <&gpio4 7 GPIO_ACTIVE_HIGH>; /* MX6_PANLEDR */
+ default-state = "off";
+ };
+
+ led2: user3 {
+ label = "user3";
+ gpios = <&gpio4 15 GPIO_ACTIVE_LOW>; /* MX6_LOCLED# */
+ default-state = "off";
+ };
+ };
+
+ memory at 10000000 {
+ reg = <0x10000000 0x40000000>;
+ };
+
+ pps {
+ compatible = "pps-gpio";
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_pps>;
+ gpios = <&gpio1 26 GPIO_ACTIVE_HIGH>;
+ };
+
+ reg_2p5v: regulator-2p5v {
+ compatible = "regulator-fixed";
+ regulator-name = "2P5V";
+ regulator-min-microvolt = <2500000>;
+ regulator-max-microvolt = <2500000>;
+ regulator-always-on;
+ };
+
+ reg_3p3v: regulator-3p3v {
+ compatible = "regulator-fixed";
+ regulator-name = "3P3V";
+ regulator-min-microvolt = <3300000>;
+ regulator-max-microvolt = <3300000>;
+ regulator-always-on;
+ };
+
+ reg_5p0v: regulator-5p0v {
+ compatible = "regulator-fixed";
+ regulator-name = "5P0V";
+ regulator-min-microvolt = <5000000>;
+ regulator-max-microvolt = <5000000>;
+ regulator-always-on;
+ };
+
+ reg_12p0v: regulator-12p0v {
+ compatible = "regulator-fixed";
+ regulator-name = "12P0V";
+ regulator-min-microvolt = <12000000>;
+ regulator-max-microvolt = <12000000>;
+ gpio = <&gpio4 25 GPIO_ACTIVE_HIGH>;
+ enable-active-high;
+ };
+
+ reg_1p4v: regulator-vddsoc {
+ compatible = "regulator-fixed";
+ regulator-name = "vdd_soc";
+ regulator-min-microvolt = <1400000>;
+ regulator-max-microvolt = <1400000>;
+ regulator-always-on;
+ };
+
+ reg_usb_h1_vbus: regulator-usb-h1-vbus {
+ compatible = "regulator-fixed";
+ regulator-name = "usb_h1_vbus";
+ regulator-min-microvolt = <5000000>;
+ regulator-max-microvolt = <5000000>;
+ regulator-always-on;
+ };
+
+ reg_usb_otg_vbus: regulator-usb-otg-vbus {
+ compatible = "regulator-fixed";
+ regulator-name = "usb_otg_vbus";
+ regulator-min-microvolt = <5000000>;
+ regulator-max-microvolt = <5000000>;
+ gpio = <&gpio3 22 GPIO_ACTIVE_HIGH>;
+ enable-active-high;
+ };
+
+ sound {
+ compatible = "fsl,imx6q-ventana-sgtl5000",
+ "fsl,imx-audio-sgtl5000";
+ model = "sgtl5000-audio";
+ ssi-controller = <&ssi1>;
+ audio-codec = <&sgtl5000>;
+ audio-routing =
+ "MIC_IN", "Mic Jack",
+ "Mic Jack", "Mic Bias",
+ "Headphone Jack", "HP_OUT";
+ mux-int-port = <1>;
+ mux-ext-port = <4>;
+ };
+};
+
+&audmux {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_audmux>;
+ status = "okay";
+};
+
+&ecspi3 {
+ cs-gpios = <&gpio4 24 GPIO_ACTIVE_HIGH>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_ecspi3>;
+ status = "okay";
+};
+
+&can1 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_flexcan>;
+ status = "okay";
+};
+
+&clks {
+ assigned-clocks = <&clks IMX6QDL_CLK_LDB_DI0_SEL>,
+ <&clks IMX6QDL_CLK_LDB_DI1_SEL>;
+ assigned-clock-parents = <&clks IMX6QDL_CLK_PLL3_USB_OTG>,
+ <&clks IMX6QDL_CLK_PLL3_USB_OTG>;
+};
+
+&fec {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_enet>;
+ phy-mode = "rgmii-id";
+ phy-reset-gpios = <&gpio1 30 GPIO_ACTIVE_LOW>;
+ status = "okay";
+};
+
+&hdmi {
+ ddc-i2c-bus = <&i2c3>;
+ status = "okay";
+};
+
+&i2c1 {
+ clock-frequency = <100000>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_i2c1>;
+ status = "okay";
+
+ eeprom1: eeprom at 50 {
+ compatible = "atmel,24c02";
+ reg = <0x50>;
+ pagesize = <16>;
+ };
+
+ eeprom2: eeprom at 51 {
+ compatible = "atmel,24c02";
+ reg = <0x51>;
+ pagesize = <16>;
+ };
+
+ eeprom3: eeprom at 52 {
+ compatible = "atmel,24c02";
+ reg = <0x52>;
+ pagesize = <16>;
+ };
+
+ eeprom4: eeprom at 53 {
+ compatible = "atmel,24c02";
+ reg = <0x53>;
+ pagesize = <16>;
+ };
+
+ pca9555: gpio at 23 {
+ compatible = "nxp,pca9555";
+ reg = <0x23>;
+ gpio-controller;
+ #gpio-cells = <2>;
+ };
+
+ ds1672: rtc at 68 {
+ compatible = "dallas,ds1672";
+ reg = <0x68>;
+ };
+};
+
+&i2c2 {
+ clock-frequency = <100000>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_i2c2>;
+ status = "okay";
+
+ sgtl5000: codec at a {
+ compatible = "fsl,sgtl5000";
+ reg = <0x0a>;
+ clocks = <&clks IMX6QDL_CLK_CKO>;
+ VDDA-supply = <®_1p8v>;
+ VDDIO-supply = <®_3p3v>;
+ };
+
+ tca8418: keypad at 34 {
+ compatible = "ti,tca8418";
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_keypad>;
+ reg = <0x34>;
+ interrupt-parent = <&gpio5>;
+ interrupts = <11 IRQ_TYPE_EDGE_FALLING>;
+ linux,keymap = < MATRIX_KEY(0x00, 0x01, BTN_0)
+ MATRIX_KEY(0x00, 0x00, BTN_1)
+ MATRIX_KEY(0x01, 0x01, BTN_2)
+ MATRIX_KEY(0x01, 0x00, BTN_3)
+ MATRIX_KEY(0x02, 0x00, BTN_4)
+ MATRIX_KEY(0x00, 0x03, BTN_5)
+ MATRIX_KEY(0x00, 0x02, BTN_6)
+ MATRIX_KEY(0x01, 0x03, BTN_7)
+ MATRIX_KEY(0x01, 0x02, BTN_8)
+ MATRIX_KEY(0x02, 0x02, BTN_9)
+ >;
+ keypad,num-rows = <4>;
+ keypad,num-columns = <4>;
+ };
+
+ ltc3676: pmic at 3c {
+ compatible = "lltc,ltc3676";
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_pmic>;
+ reg = <0x3c>;
+ interrupt-parent = <&gpio1>;
+ interrupts = <8 IRQ_TYPE_EDGE_FALLING>;
+
+ regulators {
+ /* VDD_DDR (1+R1/R2 = 2.105) */
+ reg_vdd_ddr: sw2 {
+ regulator-name = "vddddr";
+ regulator-min-microvolt = <868310>;
+ regulator-max-microvolt = <1684000>;
+ lltc,fb-voltage-divider = <221000 200000>;
+ regulator-ramp-delay = <7000>;
+ regulator-boot-on;
+ regulator-always-on;
+ };
+
+ /* VDD_ARM (1+R1/R2 = 1.931) */
+ reg_vdd_arm: sw3 {
+ regulator-name = "vddarm";
+ regulator-min-microvolt = <796551>;
+ regulator-max-microvolt = <1544827>;
+ lltc,fb-voltage-divider = <243000 261000>;
+ regulator-ramp-delay = <7000>;
+ regulator-boot-on;
+ regulator-always-on;
+ linux,phandle = <®_vdd_arm>;
+ };
+
+ /* VDD_1P8 (1+R1/R2 = 2.505): GPS/VideoIn/ENET-PHY */
+ reg_1p8v: sw4 {
+ regulator-name = "vdd1p8";
+ regulator-min-microvolt = <1033310>;
+ regulator-max-microvolt = <2004000>;
+ lltc,fb-voltage-divider = <301000 200000>;
+ regulator-ramp-delay = <7000>;
+ regulator-boot-on;
+ regulator-always-on;
+ };
+
+ /* VDD_1P0 (1+R1/R2 = 1.39): PCIe/ENET-PHY */
+ reg_1p0v: ldo2 {
+ regulator-name = "vdd1p0";
+ regulator-min-microvolt = <950000>;
+ regulator-max-microvolt = <1050000>;
+ lltc,fb-voltage-divider = <78700 200000>;
+ regulator-boot-on;
+ regulator-always-on;
+ };
+
+ /* VDD_AUD_1P8: Audio codec */
+ reg_aud_1p8v: ldo3 {
+ regulator-name = "vdd1p8a";
+ regulator-min-microvolt = <1800000>;
+ regulator-max-microvolt = <1800000>;
+ regulator-boot-on;
+ };
+
+ /* VDD_HIGH (1+R1/R2 = 4.17) */
+ reg_3p0v: ldo4 {
+ regulator-name = "vdd3p0";
+ regulator-min-microvolt = <3023250>;
+ regulator-max-microvolt = <3023250>;
+ lltc,fb-voltage-divider = <634000 200000>;
+ regulator-boot-on;
+ regulator-always-on;
+ };
+ };
+ };
+};
+
+&i2c3 {
+ clock-frequency = <100000>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_i2c3>;
+ status = "okay";
+
+ egalax_ts: touchscreen at 4 {
+ compatible = "eeti,egalax_ts";
+ reg = <0x04>;
+ interrupt-parent = <&gpio5>;
+ interrupts = <12 IRQ_TYPE_EDGE_FALLING>;
+ wakeup-gpios = <&gpio5 13 GPIO_ACTIVE_LOW>;
+ };
+};
+
+&ldb {
+ fsl,dual-channel;
+ status = "okay";
+
+ lvds-channel at 0 {
+ fsl,data-mapping = "spwg";
+ fsl,data-width = <18>;
+ status = "okay";
+
+ display-timings {
+ native-mode = <&timing0>;
+ timing0: hsd100pxn1 {
+ clock-frequency = <65000000>;
+ hactive = <1024>;
+ vactive = <768>;
+ hback-porch = <220>;
+ hfront-porch = <40>;
+ vback-porch = <21>;
+ vfront-porch = <7>;
+ hsync-len = <60>;
+ vsync-len = <10>;
+ };
+ };
+ };
+};
+
+&pcie {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_pcie>;
+ reset-gpio = <&gpio4 31 GPIO_ACTIVE_LOW>;
+ status = "okay";
+};
+
+&pwm2 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_pwm2>; /* MX6_DIO1 */
+ status = "disabled";
+};
+
+&pwm3 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_pwm3>; /* MX6_DIO2 */
+ status = "disabled";
+};
+
+&pwm4 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_pwm4>;
+ status = "okay";
+};
+
+&ssi1 {
+ status = "okay";
+};
+
+&uart1 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_uart1>;
+ uart-has-rtscts;
+ rts-gpios = <&gpio7 1 GPIO_ACTIVE_HIGH>;
+ status = "okay";
+};
+
+&uart2 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_uart2>;
+ status = "okay";
+};
+
+&uart5 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_uart5>;
+ status = "okay";
+};
+
+&usbotg {
+ vbus-supply = <®_usb_otg_vbus>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_usbotg>;
+ disable-over-current;
+ status = "okay";
+};
+
+&usbh1 {
+ vbus-supply = <®_usb_h1_vbus>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_usbh1>;
+ status = "okay";
+};
+
+&usdhc2 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_usdhc2>;
+ bus-width = <8>;
+ vmmc-supply = <®_3p3v>;
+ non-removable;
+ status = "okay";
+};
+
+&usdhc3 {
+ pinctrl-names = "default", "state_100mhz", "state_200mhz";
+ pinctrl-0 = <&pinctrl_usdhc3>;
+ pinctrl-1 = <&pinctrl_usdhc3_100mhz>;
+ pinctrl-2 = <&pinctrl_usdhc3_200mhz>;
+ cd-gpios = <&gpio7 0 GPIO_ACTIVE_HIGH>;
+ vmmc-supply = <®_3p3v>;
+ status = "okay";
+};
+
+&wdog1 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_wdog>;
+ fsl,ext-reset-output;
+};
+
+&iomuxc {
+ pinctrl_audmux: audmuxgrp {
+ fsl,pins = <
+ /* AUD4 */
+ MX6QDL_PAD_DISP0_DAT20__AUD4_TXC 0x130b0
+ MX6QDL_PAD_DISP0_DAT21__AUD4_TXD 0x110b0
+ MX6QDL_PAD_DISP0_DAT22__AUD4_TXFS 0x130b0
+ MX6QDL_PAD_DISP0_DAT23__AUD4_RXD 0x130b0
+ MX6QDL_PAD_GPIO_0__CCM_CLKO1 0x130b0 /* AUD4_MCK */
+ /* AUD6 */
+ MX6QDL_PAD_DI0_PIN2__AUD6_TXD 0x130b0
+ MX6QDL_PAD_DI0_PIN3__AUD6_TXFS 0x130b0
+ MX6QDL_PAD_DI0_PIN4__AUD6_RXD 0x130b0
+ MX6QDL_PAD_DI0_PIN15__AUD6_TXC 0x130b0
+ >;
+ };
+
+ pinctrl_ecspi3: escpi3grp {
+ fsl,pins = <
+ MX6QDL_PAD_DISP0_DAT0__ECSPI3_SCLK 0x100b1
+ MX6QDL_PAD_DISP0_DAT1__ECSPI3_MOSI 0x100b1
+ MX6QDL_PAD_DISP0_DAT2__ECSPI3_MISO 0x100b1
+ MX6QDL_PAD_DISP0_DAT3__GPIO4_IO24 0x100b1
+ >;
+ };
+
+ pinctrl_enet: enetgrp {
+ fsl,pins = <
+ MX6QDL_PAD_RGMII_RXC__RGMII_RXC 0x1b030
+ MX6QDL_PAD_RGMII_RD0__RGMII_RD0 0x1b030
+ MX6QDL_PAD_RGMII_RD1__RGMII_RD1 0x1b030
+ MX6QDL_PAD_RGMII_RD2__RGMII_RD2 0x1b030
+ MX6QDL_PAD_RGMII_RD3__RGMII_RD3 0x1b030
+ MX6QDL_PAD_RGMII_RX_CTL__RGMII_RX_CTL 0x1b030
+ MX6QDL_PAD_RGMII_TXC__RGMII_TXC 0x1b030
+ MX6QDL_PAD_RGMII_TD0__RGMII_TD0 0x1b030
+ MX6QDL_PAD_RGMII_TD1__RGMII_TD1 0x1b030
+ MX6QDL_PAD_RGMII_TD2__RGMII_TD2 0x1b030
+ MX6QDL_PAD_RGMII_TD3__RGMII_TD3 0x1b030
+ MX6QDL_PAD_RGMII_TX_CTL__RGMII_TX_CTL 0x1b030
+ MX6QDL_PAD_ENET_REF_CLK__ENET_TX_CLK 0x1b0b0
+ MX6QDL_PAD_ENET_MDIO__ENET_MDIO 0x1b0b0
+ MX6QDL_PAD_ENET_MDC__ENET_MDC 0x1b0b0
+ MX6QDL_PAD_GPIO_16__ENET_REF_CLK 0x4001b0a8
+ MX6QDL_PAD_ENET_TXD0__GPIO1_IO30 0x4001b0b0 /* PHY_RST# */
+ >;
+ };
+
+ pinctrl_flexcan: flexcangrp {
+ fsl,pins = <
+ MX6QDL_PAD_KEY_ROW2__FLEXCAN1_RX 0x1b0b1
+ MX6QDL_PAD_KEY_COL2__FLEXCAN1_TX 0x1b0b1
+ MX6QDL_PAD_GPIO_2__GPIO1_IO02 0x4001b0b0 /* CAN_STBY */
+ >;
+ };
+
+ pinctrl_gpio_leds: gpioledsgrp {
+ fsl,pins = <
+ MX6QDL_PAD_KEY_COL0__GPIO4_IO06 0x1b0b0
+ MX6QDL_PAD_KEY_ROW0__GPIO4_IO07 0x1b0b0
+ MX6QDL_PAD_KEY_ROW4__GPIO4_IO15 0x1b0b0
+ >;
+ };
+
+ pinctrl_i2c1: i2c1grp {
+ fsl,pins = <
+ MX6QDL_PAD_EIM_D21__I2C1_SCL 0x4001b8b1
+ MX6QDL_PAD_EIM_D28__I2C1_SDA 0x4001b8b1
+ >;
+ };
+
+ pinctrl_i2c2: i2c2grp {
+ fsl,pins = <
+ MX6QDL_PAD_KEY_COL3__I2C2_SCL 0x4001b8b1
+ MX6QDL_PAD_KEY_ROW3__I2C2_SDA 0x4001b8b1
+ >;
+ };
+
+ pinctrl_i2c3: i2c3grp {
+ fsl,pins = <
+ MX6QDL_PAD_GPIO_3__I2C3_SCL 0x4001b8b1
+ MX6QDL_PAD_GPIO_6__I2C3_SDA 0x4001b8b1
+ MX6QDL_PAD_GPIO_19__GPIO4_IO05 0x4001b0b0 /* DIOI2C_DIS# */
+ MX6QDL_PAD_DISP0_DAT18__GPIO5_IO12 0x0001b0b0 /* LVDS_TOUCH_IRQ# */
+ MX6QDL_PAD_DISP0_DAT19__GPIO5_IO13 0x0001b0b0 /* LVDS_BACKEN */
+ >;
+ };
+
+ pinctrl_keypad: keypadgrp {
+ fsl,pins = <
+ MX6QDL_PAD_DISP0_DAT17__GPIO5_IO11 0x0001b0b0 /* KEYPAD_IRQ# */
+ MX6QDL_PAD_DISP0_DAT9__GPIO4_IO30 0x0001b0b0 /* KEYPAD_LED_EN */
+ >;
+ };
+
+ pinctrl_pcie: pciegrp {
+ fsl,pins = <
+ MX6QDL_PAD_DISP0_DAT10__GPIO4_IO31 0x1b0b0 /* PCI_RST# */
+ MX6QDL_PAD_GPIO_17__GPIO7_IO12 0x4001b0b0 /* PCIESKT_WDIS# */
+ >;
+ };
+
+ pinctrl_pmic: pmicgrp {
+ fsl,pins = <
+ MX6QDL_PAD_GPIO_8__GPIO1_IO08 0x0001b0b0 /* PMIC_IRQ# */
+ >;
+ };
+
+ pinctrl_pps: ppsgrp {
+ fsl,pins = <
+ MX6QDL_PAD_ENET_RXD1__GPIO1_IO26 0x1b0b1
+ >;
+ };
+
+ pinctrl_pwm2: pwm2grp {
+ fsl,pins = <
+ MX6QDL_PAD_SD1_DAT2__PWM2_OUT 0x1b0b1
+ >;
+ };
+
+ pinctrl_pwm3: pwm3grp {
+ fsl,pins = <
+ MX6QDL_PAD_SD1_DAT1__PWM3_OUT 0x1b0b1
+ >;
+ };
+
+ pinctrl_pwm4: pwm4grp {
+ fsl,pins = <
+ MX6QDL_PAD_SD1_CMD__PWM4_OUT 0x1b0b1
+ >;
+ };
+
+ pinctrl_uart1: uart1grp {
+ fsl,pins = <
+ MX6QDL_PAD_SD3_DAT7__UART1_TX_DATA 0x1b0b1
+ MX6QDL_PAD_SD3_DAT6__UART1_RX_DATA 0x1b0b1
+ MX6QDL_PAD_SD3_DAT4__GPIO7_IO01 0x4001b0b1 /* TEN */
+ >;
+ };
+
+ pinctrl_uart2: uart2grp {
+ fsl,pins = <
+ MX6QDL_PAD_SD4_DAT7__UART2_TX_DATA 0x1b0b1
+ MX6QDL_PAD_SD4_DAT4__UART2_RX_DATA 0x1b0b1
+ >;
+ };
+
+ pinctrl_uart5: uart5grp {
+ fsl,pins = <
+ MX6QDL_PAD_KEY_COL1__UART5_TX_DATA 0x1b0b1
+ MX6QDL_PAD_KEY_ROW1__UART5_RX_DATA 0x1b0b1
+ >;
+ };
+
+ pinctrl_usbh1: usbh1grp {
+ fsl,pins = <
+ MX6QDL_PAD_GPIO_9__GPIO1_IO09 0x4001b0b0 /* USBHUB_RST# */
+ >;
+ };
+
+ pinctrl_usbotg: usbotggrp {
+ fsl,pins = <
+ MX6QDL_PAD_GPIO_1__USB_OTG_ID 0x17059
+ MX6QDL_PAD_EIM_D22__GPIO3_IO22 0x1b0b0 /* PWR_EN */
+ MX6QDL_PAD_KEY_COL4__GPIO4_IO14 0x1b0b0 /* OC */
+ >;
+ };
+
+ pinctrl_usdhc2: usdhc2grp {
+ fsl,pins = <
+ MX6QDL_PAD_SD2_CMD__SD2_CMD 0x170f9
+ MX6QDL_PAD_SD2_CLK__SD2_CLK 0x100f9
+ MX6QDL_PAD_SD2_DAT0__SD2_DATA0 0x170f9
+ MX6QDL_PAD_SD2_DAT1__SD2_DATA1 0x170f9
+ MX6QDL_PAD_SD2_DAT2__SD2_DATA2 0x170f9
+ MX6QDL_PAD_SD2_DAT3__SD2_DATA3 0x170f9
+ MX6QDL_PAD_NANDF_D4__SD2_DATA4 0x170f9
+ MX6QDL_PAD_NANDF_D5__SD2_DATA5 0x170f9
+ MX6QDL_PAD_NANDF_D6__SD2_DATA6 0x170f9
+ MX6QDL_PAD_NANDF_D7__SD2_DATA7 0x170f9
+ >;
+ };
+
+ pinctrl_usdhc3: usdhc3grp {
+ fsl,pins = <
+ MX6QDL_PAD_SD3_CMD__SD3_CMD 0x17059
+ MX6QDL_PAD_SD3_CLK__SD3_CLK 0x10059
+ MX6QDL_PAD_SD3_DAT0__SD3_DATA0 0x17059
+ MX6QDL_PAD_SD3_DAT1__SD3_DATA1 0x17059
+ MX6QDL_PAD_SD3_DAT2__SD3_DATA2 0x17059
+ MX6QDL_PAD_SD3_DAT3__SD3_DATA3 0x17059
+ MX6QDL_PAD_SD3_DAT5__GPIO7_IO00 0x17059 /* CD */
+ MX6QDL_PAD_NANDF_CS1__SD3_VSELECT 0x17059
+ >;
+ };
+
+ pinctrl_usdhc3_100mhz: usdhc3grp100mhz {
+ fsl,pins = <
+ MX6QDL_PAD_SD3_CMD__SD3_CMD 0x170b9
+ MX6QDL_PAD_SD3_CLK__SD3_CLK 0x100b9
+ MX6QDL_PAD_SD3_DAT0__SD3_DATA0 0x170b9
+ MX6QDL_PAD_SD3_DAT1__SD3_DATA1 0x170b9
+ MX6QDL_PAD_SD3_DAT2__SD3_DATA2 0x170b9
+ MX6QDL_PAD_SD3_DAT3__SD3_DATA3 0x170b9
+ MX6QDL_PAD_SD3_DAT5__GPIO7_IO00 0x170b9 /* CD */
+ MX6QDL_PAD_NANDF_CS1__SD3_VSELECT 0x170b9
+ >;
+ };
+
+ pinctrl_usdhc3_200mhz: usdhc3grp200mhz {
+ fsl,pins = <
+ MX6QDL_PAD_SD3_CMD__SD3_CMD 0x170f9
+ MX6QDL_PAD_SD3_CLK__SD3_CLK 0x100f9
+ MX6QDL_PAD_SD3_DAT0__SD3_DATA0 0x170f9
+ MX6QDL_PAD_SD3_DAT1__SD3_DATA1 0x170f9
+ MX6QDL_PAD_SD3_DAT2__SD3_DATA2 0x170f9
+ MX6QDL_PAD_SD3_DAT3__SD3_DATA3 0x170f9
+ MX6QDL_PAD_SD3_DAT5__GPIO7_IO00 0x170f9 /* CD */
+ MX6QDL_PAD_NANDF_CS1__SD3_VSELECT 0x170f9
+ >;
+ };
+
+ pinctrl_wdog: wdoggrp {
+ fsl,pins = <
+ MX6QDL_PAD_DISP0_DAT8__WDOG1_B 0x1b0b0
+ >;
+ };
+};
--
2.7.4
^ permalink raw reply related
* [PATCH] arm: pmu: Get PMU working when the A53 is run in 32 bit mode
From: Florian Fainelli @ 2017-05-02 17:37 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <87h913mcdy.fsf@on-the-bus.cambridge.arm.com>
On 05/02/2017 09:50 AM, Marc Zyngier wrote:
> On Tue, May 02 2017 at 4:51:55 pm BST, Florian Fainelli <f.fainelli@gmail.com> wrote:
>> Hi Mark,
>>
>> On 05/02/2017 07:17 AM, Marc Zyngier wrote:
>>> Hi Al,
>>>
>>> On 02/05/17 15:01, Al Cooper wrote:
>>>> From: Al Cooper <al.cooper@broadcom.com>
>>>>
>>>> When the A53 is run in A15 (32 bit) mode, the registers used to
>>>> access the counters are A15 style registers, but the actual
>>>> counters are the A53 counters not A15 counters. This patch will
>>>> select a PMU counters map for the A53 if the device tree pmu
>>>> "compatible" property includes "arm,cortex-a53-pmu".
>>>
>>> I wasn't aware of an "A15 mode"! Is there an ARM3 mode, while we're at
>>> it? ;-)
>>
>> This is referring to how our Device Tree and kernel end-up "viewing" the
>> PMU (based on provided compatible strings) but this probably should be
>> omitted for clarity.
>
> That's certainly wrong from both an architectural and implementation
> PoV. Although there is some level of compatibility between the ARMv7 and
> ARMv8 PMU architectures, they are distinct beasts.
Yes, we are well aware of that, which is why I don't think it's even
relevant to this discussion here because it's a known implementation
issue on our end.
>
>>>
>>> More seriously, you seem to take the problem from the wrong end. If you
>>> have an ARMv8 core, you should use the PMUv3 driver (because that is
>>> what your A53 has), and not the ARMv7 PMU.
>>>
>>> To that affect, I've posted this[1] a while ago. Can you please give it
>>> a go?
>>
>> That seems to be the right direction, however don't you also need to
>> possibly expose other PMU types as well? Cortex-A53 and Cortex-A57 PMUs
>> (and possibly more) for instance because there are additional counters
>> that can be defined specifically for those, e.g: LL = L2 cache on A53,
>> see [1].
>
> That's pretty much orthogonal. Once we have a common driver for PMUv3 on
> both 32 and 64bit, adding implementation-specific events can be done for
> both architecture.
My comment was not so much about the PMU-specific events, but about the
fact that if you make changes to the PMUv3 between 32-bit and 64-bit
kernels, we might as well bring all other PMU models that have a
potential for being shared between 32-bit and 64-bit in one go.
--
Florian
^ permalink raw reply
* [PATCH] arm64: Fix multiple 'asm-operand-widths' warnings
From: Mark Rutland @ 2017-05-02 17:29 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170501212622.153720-1-mka@chromium.org>
Hi,
On Mon, May 01, 2017 at 02:26:22PM -0700, Matthias Kaehlcke wrote:
> diff --git a/arch/arm64/include/asm/uaccess.h b/arch/arm64/include/asm/uaccess.h
> index 5308d696311b..7db143689694 100644
> --- a/arch/arm64/include/asm/uaccess.h
> +++ b/arch/arm64/include/asm/uaccess.h
> @@ -302,7 +302,7 @@ do { \
> " .previous\n" \
> _ASM_EXTABLE(1b, 3b) \
> : "+r" (err) \
> - : "r" (x), "r" (addr), "i" (-EFAULT))
> + : "r" ((__u64)x), "r" (addr), "i" (-EFAULT))
>
For reference, do you have the warning for this case to hand?
In __put_user_err() we make __pu_val the same type as *ptr, then we
switch on sizeof(*ptr), and pass __pu_val to __put_user_asm(), as x.
For cases 1, 2, and 4, we use "%w" as the register template.
So I can't see why we'd need this cast in __put_user_err().
I must be missing something.
Thanks,
Mark.
^ permalink raw reply
* [PATCH] arm64: Fix multiple 'asm-operand-widths' warnings
From: Matthias Kaehlcke @ 2017-05-02 17:26 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170502102718.GA28132@leverpostej>
Hi Mark,
El Tue, May 02, 2017 at 11:27:18AM +0100 Mark Rutland ha dit:
> On Mon, May 01, 2017 at 02:26:22PM -0700, Matthias Kaehlcke wrote:
> > clang raises 'asm-operand-widths' warnings in inline assembly code when
> > the size of an operand is < 64 bits and the operand width is unspecified.
> > Most warnings are raised in macros, i.e. the datatype of the operand may
> > vary. Forcing the use of an x register through the 'x' operand modifier
> > would silence the warning however it involves the risk that for operands
> > < 64 bits 'unused' bits may be assigned to 64-bit values (more details at
> > http://lists.infradead.org/pipermail/linux-arm-kernel/2017-April/503816.html).
> > Instead we cast the operand to 64 bits, which also forces the use of a
> > x register, but without the unexpected behavior.
> >
> > In gic_write_bpr1() use write_sysreg_s() to write the register. This
> > aligns the functions with others in this header and fixes an
> > 'asm-operand-widths' warning.
> >
> > Signed-off-by: Matthias Kaehlcke <mka@chromium.org>
> > ---
> > arch/arm64/include/asm/arch_gicv3.h | 2 +-
> > arch/arm64/include/asm/barrier.h | 2 +-
> > arch/arm64/include/asm/uaccess.h | 2 +-
> > arch/arm64/kernel/armv8_deprecated.c | 2 +-
> > 4 files changed, 4 insertions(+), 4 deletions(-)
>
> Thanks for putting this together.
>
> Just to check, are these the only instances that you see clang warning
> about?
Yes, these are the only warnings clang raises in my builds (custom and
defconfig).
> There are a number of other cases where we can see similar problems
> (e.g. passing a u8 value to an smp_store_release() on a u32 variable),
> so we need to fix more than the clang warnings.
>
> I'm currently attempting a systematic audit of our inline asm to correct
> all instances, looking at:
>
> git grep -e asm \
> --and --not -e 'include' \
> --and --not -e 'asmlinkage' \
> -- arch/arm64
>
> I hope to have patches shortly, and will keep you informed.
Sounds good!
Thanks
Matthias
^ permalink raw reply
* [PATCH 0/5] KVM/ARM: Fixes for 4.12-rc1
From: Christoffer Dall @ 2017-05-02 17:15 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <c9f36b35-6a46-8ed8-0bb0-9c099f28d834@arm.com>
On Tue, May 02, 2017 at 04:00:49PM +0100, Marc Zyngier wrote:
> On 02/05/17 15:44, Paolo Bonzini wrote:
> >
> >
> > On 02/05/2017 15:30, Marc Zyngier wrote:
> >> Here's a handful of random fixes I've queued locally that didn't have
> >> a chance to make it in 4.11.
> >>
> >> The first two patches avoid stack-protector messing with the HYP code,
> >> as this ends up being a complete disaster.
> >>
> >> The following two patches fix a bug introduced in the new vgic, where
> >> we may queue HW interrupts with the Pending+Active state, which is
> >> illegal.
> >>
> >> The final patch fixes a misinterpretation of the spec, where we
> >> compute the number of APxRn register based on the number of priorities
> >> instead of using the number of preemption levels.
> >>
> >> I've tagged the first 4 patches for stable, given that we're doing
> >> something potentially harmful. The last patch is more of a theoretical
> >> issue at this stage, so probably need for a backport.
> >
> > Would you like me to apply them, or are you looking for reviews and
> > going to send them in a pull request?
> >
> > I can wait a couple days before sending my own pull request to Linus.
>
> Christoffer is in charge of the tree at the moment, so I'll leave it up
> to him to decide. But my guess is that he will send a PR some time
> later, with the rest of the fixes that have been posted lately.
>
Yes, I have some other fixes that I'll send together with these as soon
as -rc1 hits. And I plan on reviewing these.
Thanks,
-Christoffer
^ permalink raw reply
* [RFC/RFT PATCH 03/18] PCI: Introduce pci_scan_root_bus_bridge()
From: Lorenzo Pieralisi @ 2017-05-02 17:15 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAK8P3a0HmrrYBP5em1s4VOY4Tb6=bwOrDDN6K8rPp8OEXtpMtA@mail.gmail.com>
On Fri, Apr 28, 2017 at 02:28:38PM +0200, Arnd Bergmann wrote:
> On Wed, Apr 26, 2017 at 1:17 PM, Lorenzo Pieralisi
> <lorenzo.pieralisi@arm.com> wrote:
> > Current pci_scan_root_bus() interface is made up of two main
> > code paths:
> >
> > - pci_create_root_bus()
> > - pci_scan_child_bus()
> >
> > pci_create_root_bus() is a wrapper function that allows to create
> > a struct pci_host_bridge structure, initialize it with the passed
> > parameters and register it with the kernel.
> >
> > As the struct pci_host_bridge require additional struct members,
> > pci_create_root_bus() parameters list has grown in time, making
> > it unwieldy to add further parameters to it in case the struct
> > pci_host_bridge gains more members fields to augment its functionality.
> >
> > Since PCI core code provides functions to allocate struct
> > pci_host_bridge, instead of forcing the pci_create_root_bus() interface
> > to add new parameters to cater for new struct pci_host_bridge
> > functionality, it is more suitable to add an interface in PCI
> > core code to scan a PCI bus straight from a struct pci_host_bridge
> > created and customized by each specific PCI host controller driver.
> >
> > Add a pci_scan_root_bus_bridge() function to allow PCI host controller
> > drivers to create and initialize struct pci_host_bridge and scan
> > the resulting bus.
> >
> > Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
> > Cc: Arnd Bergmann <arnd@arndb.de>
> > Cc: Bjorn Helgaas <bhelgaas@google.com>
>
> Good idea, yes. To avoid growing the number of interfaces too
> much, should we change the existing users of pci_register_host_bridge
> in host drivers over to this entry point, and make the other one
> local to probe.c then?
Yes, the problem is that there are drivers (ie pcie-iproc.c) that
require the struct pci_bus (created by pci_register_host_bridge())
to fiddle with it to check link status and THEN scan the bus (so
the pci_register_host_bridge() call can't be embedded in the scan
interface - the driver requires struct pci_bus for pci_ops to work
before scanning the bus itself).
I will see how I can accommodate this change because you definitely
have a point.
> > diff --git a/drivers/pci/probe.c b/drivers/pci/probe.c
> > index 7e4ffc4..c7a7f72 100644
> > --- a/drivers/pci/probe.c
> > +++ b/drivers/pci/probe.c
> > @@ -2412,6 +2412,44 @@ void pci_bus_release_busn_res(struct pci_bus *b)
> > res, ret ? "can not be" : "is");
> > }
> >
> > +int pci_scan_root_bus_bridge(struct pci_host_bridge *bridge)
> > +{
> > + struct resource_entry *window;
> > + bool found = false;
> > + struct pci_bus *b;
> > + int max, bus, ret;
> > +
> > + if (!bridge)
> > + return -EINVAL;
> > +
> > + resource_list_for_each_entry(window, &bridge->windows)
> > + if (window->res->flags & IORESOURCE_BUS) {
> > + found = true;
> > + break;
> > + }
> > +
> > + ret = pci_register_host_bridge(bridge);
> > + if (ret < 0)
> > + return ret;
> > +
> > + b = bridge->bus;
> > + bus = bridge->busnr;
> > +
> > + if (!found) {
> > + dev_info(&b->dev,
> > + "No busn resource found for root bus, will use [bus %02x-ff]\n",
> > + bus);
> > + pci_bus_insert_busn_res(b, bus, 255);
> > + }
> > +
> > + max = pci_scan_child_bus(b);
> > +
> > + if (!found)
> > + pci_bus_update_busn_res_end(b, max);
> > +
> > + return 0;
> > +}
> > +
>
> We probably want an EXPORT_SYMBOL() here as well.
Yep, sure.
Thanks for having a look !
Lorenzo
^ permalink raw reply
* [PATCH 1/2] PCI: Add new PCIe Fabric End Node flag, PCI_DEV_FLAGS_NO_RELAXED_ORDERING
From: Raj, Ashok @ 2017-05-02 16:53 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAKgT0UeuW88AHBX14H8xHteeG7vR0AH3apbjOeEDx_6p46x7tA@mail.gmail.com>
On Tue, May 02, 2017 at 09:39:34AM -0700, Alexander Duyck wrote:
> On Mon, May 1, 2017 at 4:13 PM, Casey Leedom <leedom@chelsio.com> wrote:
> > The new flag PCI_DEV_FLAGS_NO_RELAXED_ORDERING indicates that the Relaxed
> > Ordering Attribute should not be used on Transaction Layer Packets destined
> > for the PCIe End Node so flagged. Initially flagged this way are Intel
> > E5-26xx Root Complex Ports which suffer from a Flow Control Credit
> > Performance Problem and AMD A1100 ARM ("SEATTLE") Root Complex Ports which
> > don't obey PCIe 3.0 ordering rules which can lead to Data Corruption.
>
> So this is a good first step though might I suggest one other change.
>
> We may want to add logic to the core PCIe code that clears the "Enable
> Relaxed Ordering" bit in the device control register for all devices
> hanging off of this root complex. Assuming the devices conform to the
> PCIe spec doing that should disable relaxed ordering in a device
> agnostic way that then enables us at a driver level to just enable the
> feature always without having to perform any checks for your flag. We
> could probably do that as a part of probing the PCIe interfaces
> hanging off of these devices.
I suppose you don't want to turn off RO completely on the device. When
traffic is targetted to mmio for peer to peer reasons RO has performance
upside. The specific issue with these root ports indicate limitation using
RO for traffic targetting coherent memory.
>
> > ---
> > drivers/pci/quirks.c | 38 ++++++++++++++++++++++++++++++++++++++
> > include/linux/pci.h | 2 ++
> > 2 files changed, 40 insertions(+)
> >
> > diff --git a/drivers/pci/quirks.c b/drivers/pci/quirks.c
> > index f754453..4ae78b3 100644
> > --- a/drivers/pci/quirks.c
> > +++ b/drivers/pci/quirks.c
> > @@ -3979,6 +3979,44 @@ static void quirk_tw686x_class(struct pci_dev *pdev)
> > quirk_tw686x_class);
> >
> > /*
> > + * Some devices have problems with Transaction Layer Packets with the Relaxed
> > + * Ordering Attribute set. Such devices should mark themselves and other
> > + * Device Drivers should check before sending TLPs with RO set.
> > + */
> > +static void quirk_relaxedordering_disable(struct pci_dev *dev)
> > +{
> > + dev->dev_flags |= PCI_DEV_FLAGS_NO_RELAXED_ORDERING;
> > +}
> > +
> > +/*
> > + * Intel E5-26xx Root Complex has a Flow Control Credit issue which can
> > + * cause performance problems with Upstream Transaction Layer Packets with
> > + * Relaxed Ordering set.
> > + */
> > +DECLARE_PCI_FIXUP_CLASS_EARLY(0x8086, 0x6f02, PCI_CLASS_NOT_DEFINED, 8,
> > + quirk_relaxedordering_disable);
> > +DECLARE_PCI_FIXUP_CLASS_EARLY(0x8086, 0x6f04, PCI_CLASS_NOT_DEFINED, 8,
> > + quirk_relaxedordering_disable);
> > +DECLARE_PCI_FIXUP_CLASS_EARLY(0x8086, 0x6f08, PCI_CLASS_NOT_DEFINED, 8,
> > + quirk_relaxedordering_disable);
> > +
> > +/*
> > + * The AMD ARM A1100 (AKA "SEATTLE") SoC has a bug in its PCIe Root Complex
> > + * where Upstream Transaction Layer Packets with the Relaxed Ordering
> > + * Attribute clear are allowed to bypass earlier TLPs with Relaxed Ordering
> > + * set. This is a violation of the PCIe 3.0 Transaction Ordering Rules
> > + * outlined in Section 2.4.1 (PCI Express(r) Base Specification Revision 3.0
> > + * November 10, 2010). As a result, on this platform we can't use Relaxed
> > + * Ordering for Upstream TLPs.
> > + */
> > +DECLARE_PCI_FIXUP_CLASS_EARLY(0x1022, 0x1a00, PCI_CLASS_NOT_DEFINED, 8,
> > + quirk_relaxedordering_disable);
> > +DECLARE_PCI_FIXUP_CLASS_EARLY(0x1022, 0x1a01, PCI_CLASS_NOT_DEFINED, 8,
> > + quirk_relaxedordering_disable);
> > +DECLARE_PCI_FIXUP_CLASS_EARLY(0x1022, 0x1a02, PCI_CLASS_NOT_DEFINED, 8,
> > + quirk_relaxedordering_disable);
> > +
> > +/*
> > * Per PCIe r3.0, sec 2.2.9, "Completion headers must supply the same
> > * values for the Attribute as were supplied in the header of the
> > * corresponding Request, except as explicitly allowed when IDO is used."
> > diff --git a/include/linux/pci.h b/include/linux/pci.h
> > index eb3da1a..6764f66 100644
> > --- a/include/linux/pci.h
> > +++ b/include/linux/pci.h
> > @@ -178,6 +178,8 @@ enum pci_dev_flags {
> > PCI_DEV_FLAGS_NO_PM_RESET = (__force pci_dev_flags_t) (1 << 7),
> > /* Get VPD from function 0 VPD */
> > PCI_DEV_FLAGS_VPD_REF_F0 = (__force pci_dev_flags_t) (1 << 8),
> > + /* Don't use Relaxed Ordering for TLPs directed at this device */
> > + PCI_DEV_FLAGS_NO_RELAXED_ORDERING = (__force pci_dev_flags_t) (1 << 9),
> > };
> >
> > enum pci_irq_reroute_variant {
> > --
> > 1.9.1
> >
^ permalink raw reply
* [PATCH] arm: pmu: Get PMU working when the A53 is run in 32 bit mode
From: Marc Zyngier @ 2017-05-02 16:50 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <3f44e99a-6ff1-23e5-52d5-59c662fd10c3@gmail.com>
On Tue, May 02 2017 at 4:51:55 pm BST, Florian Fainelli <f.fainelli@gmail.com> wrote:
> Hi Mark,
>
> On 05/02/2017 07:17 AM, Marc Zyngier wrote:
>> Hi Al,
>>
>> On 02/05/17 15:01, Al Cooper wrote:
>>> From: Al Cooper <al.cooper@broadcom.com>
>>>
>>> When the A53 is run in A15 (32 bit) mode, the registers used to
>>> access the counters are A15 style registers, but the actual
>>> counters are the A53 counters not A15 counters. This patch will
>>> select a PMU counters map for the A53 if the device tree pmu
>>> "compatible" property includes "arm,cortex-a53-pmu".
>>
>> I wasn't aware of an "A15 mode"! Is there an ARM3 mode, while we're at
>> it? ;-)
>
> This is referring to how our Device Tree and kernel end-up "viewing" the
> PMU (based on provided compatible strings) but this probably should be
> omitted for clarity.
That's certainly wrong from both an architectural and implementation
PoV. Although there is some level of compatibility between the ARMv7 and
ARMv8 PMU architectures, they are distinct beasts.
>>
>> More seriously, you seem to take the problem from the wrong end. If you
>> have an ARMv8 core, you should use the PMUv3 driver (because that is
>> what your A53 has), and not the ARMv7 PMU.
>>
>> To that affect, I've posted this[1] a while ago. Can you please give it
>> a go?
>
> That seems to be the right direction, however don't you also need to
> possibly expose other PMU types as well? Cortex-A53 and Cortex-A57 PMUs
> (and possibly more) for instance because there are additional counters
> that can be defined specifically for those, e.g: LL = L2 cache on A53,
> see [1].
That's pretty much orthogonal. Once we have a common driver for PMUv3 on
both 32 and 64bit, adding implementation-specific events can be done for
both architecture.
Thanks,
M.
--
Jazz is not dead, it just smell funny.
^ permalink raw reply
* [PATCH 1/1] arm64: Always provide "model name" in /proc/cpuinfo
From: Mark Rutland @ 2017-05-02 16:48 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <15006378-af42-b029-f967-3f7230b64706@gmx.de>
On Tue, May 02, 2017 at 06:28:40PM +0200, Heinrich Schuchardt wrote:
> On 05/02/2017 01:08 PM, Catalin Marinas wrote:
> > On Tue, May 02, 2017 at 12:39:13AM +0200, Heinrich Schuchardt wrote:
> >> There is no need to hide the model name in processes
> >> that are not PER_LINUX32.
> >>
> >> So let us always provide a model name that is easily readable.
> >>
> >> Fixes: e47b020a323d ("arm64: Provide "model name" in /proc/cpuinfo for PER_LINUX32 tasks")
> >> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
> >> ---
> >> arch/arm64/kernel/cpuinfo.c | 5 ++---
> >> 1 file changed, 2 insertions(+), 3 deletions(-)
> >>
> >> diff --git a/arch/arm64/kernel/cpuinfo.c b/arch/arm64/kernel/cpuinfo.c
> >> index b3d5b3e8fbcb..9ad9ddcd2f19 100644
> >> --- a/arch/arm64/kernel/cpuinfo.c
> >> +++ b/arch/arm64/kernel/cpuinfo.c
> >> @@ -118,9 +118,8 @@ static int c_show(struct seq_file *m, void *v)
> >> * "processor". Give glibc what it expects.
> >> */
> >> seq_printf(m, "processor\t: %d\n", i);
> >> - if (compat)
> >> - seq_printf(m, "model name\t: ARMv8 Processor rev %d (%s)\n",
> >> - MIDR_REVISION(midr), COMPAT_ELF_PLATFORM);
> >> + seq_printf(m, "model name\t: ARMv8 Processor rev %d (%s)\n",
> >> + MIDR_REVISION(midr), COMPAT_ELF_PLATFORM);
> >>
> >> seq_printf(m, "BogoMIPS\t: %lu.%02lu\n",
> >> loops_per_jiffy / (500000UL/HZ),
> >
> > Such patch seems to come up regularly:
> >
> > https://patchwork.kernel.org/patch/9303311/
> >
> > (and it usually gets rejected)
> >
> Dear Catalin,
>
> thank you for pointing me to the previous discussion. I understand that
> adding model name in the current form would not provide sufficient
> valuable information.
>
> The real interesting thing in an ARM SOC is to see which CPU is A72,
> A57, A53 or whatever.
This information can be derived from the MIDR fields exposed in
/proc/cpuninfo
e.g.
CPU implementer : 0x41
CPU architecture: 8
CPU variant : 0x1
CPU part : 0xd07
CPU revision : 2
... is a Cortex-A57.
> This information is available from the device tree in the compatible
> property of the individual CPUs
> (/sys/firmware/devicetree/base/cpus/cpu@*/compatible), e.g.
> compatible =3D "arm,cortex-a53", "arm,armv8";
>
> I guess this information is the closest to the model name property on
> other architectures that we can get.
>
> Would exposing this information in /proc/cpuinfo as 'model name' make
> sense to you?
I would disagree with exposing this, as in practice it is wrong in some
DTs, and it's not avaialble on ACPI systems.
We already expose the information necessary to derive the name, given a
lookup table in userspace. We don't have sufficient information to build
this in the kernel in all cases, so I don't think that we should attempt
to do so.
Thanks,
Mark.
^ permalink raw reply
* [PATCH 1/2] PCI: Add new PCIe Fabric End Node flag, PCI_DEV_FLAGS_NO_RELAXED_ORDERING
From: Raj, Ashok @ 2017-05-02 16:44 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <758d0e431c732fe133e7b0e660bde5fc1beccdba.1493678834.git.leedom@chelsio.com>
Hi Casey
On Mon, May 01, 2017 at 04:13:50PM -0700, Casey Leedom wrote:
> The new flag PCI_DEV_FLAGS_NO_RELAXED_ORDERING indicates that the Relaxed
> Ordering Attribute should not be used on Transaction Layer Packets destined
> for the PCIe End Node so flagged. Initially flagged this way are Intel
> E5-26xx Root Complex Ports which suffer from a Flow Control Credit
> Performance Problem and AMD A1100 ARM ("SEATTLE") Root Complex Ports which
> don't obey PCIe 3.0 ordering rules which can lead to Data Corruption.
> ---
> drivers/pci/quirks.c | 38 ++++++++++++++++++++++++++++++++++++++
> include/linux/pci.h | 2 ++
> 2 files changed, 40 insertions(+)
>
> diff --git a/drivers/pci/quirks.c b/drivers/pci/quirks.c
> index f754453..4ae78b3 100644
> --- a/drivers/pci/quirks.c
> +++ b/drivers/pci/quirks.c
> @@ -3979,6 +3979,44 @@ static void quirk_tw686x_class(struct pci_dev *pdev)
> quirk_tw686x_class);
>
> /*
> + * Some devices have problems with Transaction Layer Packets with the Relaxed
> + * Ordering Attribute set. Such devices should mark themselves and other
> + * Device Drivers should check before sending TLPs with RO set.
> + */
> +static void quirk_relaxedordering_disable(struct pci_dev *dev)
> +{
> + dev->dev_flags |= PCI_DEV_FLAGS_NO_RELAXED_ORDERING;
> +}
> +
> +/*
> + * Intel E5-26xx Root Complex has a Flow Control Credit issue which can
> + * cause performance problems with Upstream Transaction Layer Packets with
> + * Relaxed Ordering set.
> + */
> +DECLARE_PCI_FIXUP_CLASS_EARLY(0x8086, 0x6f02, PCI_CLASS_NOT_DEFINED, 8,
> + quirk_relaxedordering_disable);
> +DECLARE_PCI_FIXUP_CLASS_EARLY(0x8086, 0x6f04, PCI_CLASS_NOT_DEFINED, 8,
> + quirk_relaxedordering_disable);
> +DECLARE_PCI_FIXUP_CLASS_EARLY(0x8086, 0x6f08, PCI_CLASS_NOT_DEFINED, 8,
> + quirk_relaxedordering_disable);
> +
You might want to add the RP ID's for both HSX/BDX. Tne entire range
is 2F01H-2F0EH & 6F01H-6F0EH.
Cheers,
Ashok
^ permalink raw reply
* [PATCH 1/1] arm64: Always provide "model name" in /proc/cpuinfo
From: Sudeep Holla @ 2017-05-02 16:43 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <15006378-af42-b029-f967-3f7230b64706@gmx.de>
On 02/05/17 17:28, Heinrich Schuchardt wrote:
[...]
> The real interesting thing in an ARM SOC is to see which CPU is A72,
> A57, A53 or whatever.
>
> This information is available from the device tree in the compatible
> property of the individual CPUs
> (/sys/firmware/devicetree/base/cpus/cpu@*/compatible), e.g.
> compatible =3D "arm,cortex-a53", "arm,armv8";
>
You can refer "CPU part" in /proc/cpuinfo for the above information.
--
Regards,
Sudeep
^ permalink raw reply
* [PATCH 1/2] PCI: Add new PCIe Fabric End Node flag, PCI_DEV_FLAGS_NO_RELAXED_ORDERING
From: Alexander Duyck @ 2017-05-02 16:39 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <758d0e431c732fe133e7b0e660bde5fc1beccdba.1493678834.git.leedom@chelsio.com>
On Mon, May 1, 2017 at 4:13 PM, Casey Leedom <leedom@chelsio.com> wrote:
> The new flag PCI_DEV_FLAGS_NO_RELAXED_ORDERING indicates that the Relaxed
> Ordering Attribute should not be used on Transaction Layer Packets destined
> for the PCIe End Node so flagged. Initially flagged this way are Intel
> E5-26xx Root Complex Ports which suffer from a Flow Control Credit
> Performance Problem and AMD A1100 ARM ("SEATTLE") Root Complex Ports which
> don't obey PCIe 3.0 ordering rules which can lead to Data Corruption.
So this is a good first step though might I suggest one other change.
We may want to add logic to the core PCIe code that clears the "Enable
Relaxed Ordering" bit in the device control register for all devices
hanging off of this root complex. Assuming the devices conform to the
PCIe spec doing that should disable relaxed ordering in a device
agnostic way that then enables us at a driver level to just enable the
feature always without having to perform any checks for your flag. We
could probably do that as a part of probing the PCIe interfaces
hanging off of these devices.
> ---
> drivers/pci/quirks.c | 38 ++++++++++++++++++++++++++++++++++++++
> include/linux/pci.h | 2 ++
> 2 files changed, 40 insertions(+)
>
> diff --git a/drivers/pci/quirks.c b/drivers/pci/quirks.c
> index f754453..4ae78b3 100644
> --- a/drivers/pci/quirks.c
> +++ b/drivers/pci/quirks.c
> @@ -3979,6 +3979,44 @@ static void quirk_tw686x_class(struct pci_dev *pdev)
> quirk_tw686x_class);
>
> /*
> + * Some devices have problems with Transaction Layer Packets with the Relaxed
> + * Ordering Attribute set. Such devices should mark themselves and other
> + * Device Drivers should check before sending TLPs with RO set.
> + */
> +static void quirk_relaxedordering_disable(struct pci_dev *dev)
> +{
> + dev->dev_flags |= PCI_DEV_FLAGS_NO_RELAXED_ORDERING;
> +}
> +
> +/*
> + * Intel E5-26xx Root Complex has a Flow Control Credit issue which can
> + * cause performance problems with Upstream Transaction Layer Packets with
> + * Relaxed Ordering set.
> + */
> +DECLARE_PCI_FIXUP_CLASS_EARLY(0x8086, 0x6f02, PCI_CLASS_NOT_DEFINED, 8,
> + quirk_relaxedordering_disable);
> +DECLARE_PCI_FIXUP_CLASS_EARLY(0x8086, 0x6f04, PCI_CLASS_NOT_DEFINED, 8,
> + quirk_relaxedordering_disable);
> +DECLARE_PCI_FIXUP_CLASS_EARLY(0x8086, 0x6f08, PCI_CLASS_NOT_DEFINED, 8,
> + quirk_relaxedordering_disable);
> +
> +/*
> + * The AMD ARM A1100 (AKA "SEATTLE") SoC has a bug in its PCIe Root Complex
> + * where Upstream Transaction Layer Packets with the Relaxed Ordering
> + * Attribute clear are allowed to bypass earlier TLPs with Relaxed Ordering
> + * set. This is a violation of the PCIe 3.0 Transaction Ordering Rules
> + * outlined in Section 2.4.1 (PCI Express(r) Base Specification Revision 3.0
> + * November 10, 2010). As a result, on this platform we can't use Relaxed
> + * Ordering for Upstream TLPs.
> + */
> +DECLARE_PCI_FIXUP_CLASS_EARLY(0x1022, 0x1a00, PCI_CLASS_NOT_DEFINED, 8,
> + quirk_relaxedordering_disable);
> +DECLARE_PCI_FIXUP_CLASS_EARLY(0x1022, 0x1a01, PCI_CLASS_NOT_DEFINED, 8,
> + quirk_relaxedordering_disable);
> +DECLARE_PCI_FIXUP_CLASS_EARLY(0x1022, 0x1a02, PCI_CLASS_NOT_DEFINED, 8,
> + quirk_relaxedordering_disable);
> +
> +/*
> * Per PCIe r3.0, sec 2.2.9, "Completion headers must supply the same
> * values for the Attribute as were supplied in the header of the
> * corresponding Request, except as explicitly allowed when IDO is used."
> diff --git a/include/linux/pci.h b/include/linux/pci.h
> index eb3da1a..6764f66 100644
> --- a/include/linux/pci.h
> +++ b/include/linux/pci.h
> @@ -178,6 +178,8 @@ enum pci_dev_flags {
> PCI_DEV_FLAGS_NO_PM_RESET = (__force pci_dev_flags_t) (1 << 7),
> /* Get VPD from function 0 VPD */
> PCI_DEV_FLAGS_VPD_REF_F0 = (__force pci_dev_flags_t) (1 << 8),
> + /* Don't use Relaxed Ordering for TLPs directed at this device */
> + PCI_DEV_FLAGS_NO_RELAXED_ORDERING = (__force pci_dev_flags_t) (1 << 9),
> };
>
> enum pci_irq_reroute_variant {
> --
> 1.9.1
>
^ permalink raw reply
* [PATCH v3] arm64: perf: Ignore exclude_hv when kernel is running in HYP
From: Ganapatrao Kulkarni @ 2017-05-02 16:29 UTC (permalink / raw)
To: linux-arm-kernel
commit d98ecdaca296 ("arm64: perf: Count EL2 events if the kernel is
running in HYP") returns -EINVAL when perf system call perf_event_open is
called with exclude_hv != exclude_kernel. This change breaks applications
on VHE enabled ARMv8.1 platforms. The issue was observed with HHVM
application, which calls perf_event_open with exclude_hv = 1 and
exclude_kernel = 0.
There is no separate hypervisor privilege level when VHE is enabled, the
host kernel runs at EL2. So when VHE is enabled, we should ignore
exclude_hv from the application. This behaviour is consistent with PowerPC
where the exclude_hv is ignored when the hypervisor is not present and with
x86 where this flag is ignored.
Signed-off-by: Ganapatrao Kulkarni <ganapatrao.kulkarni@cavium.com>
---
Changelog:
V2/V3:
- Changes as per Will Deacon's suggestions.
V1: Initial patch
arch/arm64/kernel/perf_event.c | 16 +++++++++-------
1 file changed, 9 insertions(+), 7 deletions(-)
diff --git a/arch/arm64/kernel/perf_event.c b/arch/arm64/kernel/perf_event.c
index 57ae9d9..f6748c0 100644
--- a/arch/arm64/kernel/perf_event.c
+++ b/arch/arm64/kernel/perf_event.c
@@ -871,15 +871,17 @@ static int armv8pmu_set_event_filter(struct hw_perf_event *event,
if (attr->exclude_idle)
return -EPERM;
- if (is_kernel_in_hyp_mode() &&
- attr->exclude_kernel != attr->exclude_hv)
- return -EINVAL;
+ if (is_kernel_in_hyp_mode()) {
+ if (!attr->exclude_kernel)
+ config_base |= ARMV8_PMU_INCLUDE_EL2;
+ } else {
+ if (attr->exclude_kernel)
+ config_base |= ARMV8_PMU_EXCLUDE_EL1;
+ if (!attr->exclude_hv)
+ config_base |= ARMV8_PMU_INCLUDE_EL2;
+ }
if (attr->exclude_user)
config_base |= ARMV8_PMU_EXCLUDE_EL0;
- if (!is_kernel_in_hyp_mode() && attr->exclude_kernel)
- config_base |= ARMV8_PMU_EXCLUDE_EL1;
- if (!attr->exclude_hv)
- config_base |= ARMV8_PMU_INCLUDE_EL2;
/*
* Install the filter into config_base as this is used to
--
1.8.1.4
^ permalink raw reply related
* [PATCH 1/1] arm64: Always provide "model name" in /proc/cpuinfo
From: Heinrich Schuchardt @ 2017-05-02 16:28 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170502110827.GA29224@e104818-lin.cambridge.arm.com>
On 05/02/2017 01:08 PM, Catalin Marinas wrote:
> On Tue, May 02, 2017 at 12:39:13AM +0200, Heinrich Schuchardt wrote:
>> There is no need to hide the model name in processes
>> that are not PER_LINUX32.
>>
>> So let us always provide a model name that is easily readable.
>>
>> Fixes: e47b020a323d ("arm64: Provide "model name" in /proc/cpuinfo for PER_LINUX32 tasks")
>> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
>> ---
>> arch/arm64/kernel/cpuinfo.c | 5 ++---
>> 1 file changed, 2 insertions(+), 3 deletions(-)
>>
>> diff --git a/arch/arm64/kernel/cpuinfo.c b/arch/arm64/kernel/cpuinfo.c
>> index b3d5b3e8fbcb..9ad9ddcd2f19 100644
>> --- a/arch/arm64/kernel/cpuinfo.c
>> +++ b/arch/arm64/kernel/cpuinfo.c
>> @@ -118,9 +118,8 @@ static int c_show(struct seq_file *m, void *v)
>> * "processor". Give glibc what it expects.
>> */
>> seq_printf(m, "processor\t: %d\n", i);
>> - if (compat)
>> - seq_printf(m, "model name\t: ARMv8 Processor rev %d (%s)\n",
>> - MIDR_REVISION(midr), COMPAT_ELF_PLATFORM);
>> + seq_printf(m, "model name\t: ARMv8 Processor rev %d (%s)\n",
>> + MIDR_REVISION(midr), COMPAT_ELF_PLATFORM);
>>
>> seq_printf(m, "BogoMIPS\t: %lu.%02lu\n",
>> loops_per_jiffy / (500000UL/HZ),
>
> Such patch seems to come up regularly:
>
> https://patchwork.kernel.org/patch/9303311/
>
> (and it usually gets rejected)
>
Dear Catalin,
thank you for pointing me to the previous discussion. I understand that
adding model name in the current form would not provide sufficient
valuable information.
The real interesting thing in an ARM SOC is to see which CPU is A72,
A57, A53 or whatever.
This information is available from the device tree in the compatible
property of the individual CPUs
(/sys/firmware/devicetree/base/cpus/cpu@*/compatible), e.g.
compatible =3D "arm,cortex-a53", "arm,armv8";
I guess this information is the closest to the model name property on
other architectures that we can get.
Would exposing this information in /proc/cpuinfo as 'model name' make
sense to you?
Best regards
Heinrich
^ permalink raw reply
* [PATCH v4] irqchip/gicv3-its: Avoid memory over allocation for ITEs
From: Marc Zyngier @ 2017-05-02 16:16 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1493562975-14365-1-git-send-email-shankerd@codeaurora.org>
On Sun, Apr 30 2017 at 3:36:15 pm BST, Shanker Donthineni <shankerd@codeaurora.org> wrote:
> We are always allocating extra 255Bytes of memory to handle ITE
> physical address alignment requirement. The kmalloc() satisfies
> the ITE alignment since the ITS driver is requesting a minimum
> size of ITS_ITT_ALIGN bytes.
>
> Let's try to allocate the exact amount of memory that is required
> for ITEs to avoid wastage.
>
> Signed-off-by: Shanker Donthineni <shankerd@codeaurora.org>
> ---
> Changes:
> v2: removed 'Change-Id: Ia8084189833f2081ff13c392deb5070c46a64038' from commit.
> v3: changed from IITE to ITE.
> v3: removed fallback since kmalloc() guarantees the right alignment.
>
> drivers/irqchip/irq-gic-v3-its.c | 6 +++---
> 1 file changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/irqchip/irq-gic-v3-its.c b/drivers/irqchip/irq-gic-v3-its.c
> index 45ea1933..72e56f03 100644
> --- a/drivers/irqchip/irq-gic-v3-its.c
> +++ b/drivers/irqchip/irq-gic-v3-its.c
> @@ -261,7 +261,6 @@ static struct its_collection *its_build_mapd_cmd(struct its_cmd_block *cmd,
> u8 size = ilog2(desc->its_mapd_cmd.dev->nr_ites);
>
> itt_addr = virt_to_phys(desc->its_mapd_cmd.dev->itt);
> - itt_addr = ALIGN(itt_addr, ITS_ITT_ALIGN);
>
> its_encode_cmd(cmd, GITS_CMD_MAPD);
> its_encode_devid(cmd, desc->its_mapd_cmd.dev->device_id);
> @@ -1329,13 +1328,14 @@ static struct its_device *its_create_device(struct its_node *its, u32 dev_id,
> */
> nr_ites = max(2UL, roundup_pow_of_two(nvecs));
> sz = nr_ites * its->ite_size;
> - sz = max(sz, ITS_ITT_ALIGN) + ITS_ITT_ALIGN - 1;
> + sz = max(sz, ITS_ITT_ALIGN);
> itt = kzalloc(sz, GFP_KERNEL);
> lpi_map = its_lpi_alloc_chunks(nvecs, &lpi_base, &nr_lpis);
> if (lpi_map)
> col_map = kzalloc(sizeof(*col_map) * nr_lpis, GFP_KERNEL);
>
> - if (!dev || !itt || !lpi_map || !col_map) {
> + if (!dev || !itt || !lpi_map || !col_map ||
> + !IS_ALIGNED(virt_to_phys(itt), ITS_ITT_ALIGN)) {
> kfree(dev);
> kfree(itt);
> kfree(lpi_map);
I'm confused. Either the alignment is guaranteed (and you should
document why it is so), or it is not, and we need to handle the
non-alignment (instead of failing).
Thanks,
M.
--
Jazz is not dead, it just smell funny.
^ permalink raw reply
* [PATCH] arm: pmu: Get PMU working when the A53 is run in 32 bit mode
From: Florian Fainelli @ 2017-05-02 15:51 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <0f716b0c-b9ac-29d9-2909-50906ad90bd3@arm.com>
Hi Mark,
On 05/02/2017 07:17 AM, Marc Zyngier wrote:
> Hi Al,
>
> On 02/05/17 15:01, Al Cooper wrote:
>> From: Al Cooper <al.cooper@broadcom.com>
>>
>> When the A53 is run in A15 (32 bit) mode, the registers used to
>> access the counters are A15 style registers, but the actual
>> counters are the A53 counters not A15 counters. This patch will
>> select a PMU counters map for the A53 if the device tree pmu
>> "compatible" property includes "arm,cortex-a53-pmu".
>
> I wasn't aware of an "A15 mode"! Is there an ARM3 mode, while we're at
> it? ;-)
This is referring to how our Device Tree and kernel end-up "viewing" the
PMU (based on provided compatible strings) but this probably should be
omitted for clarity.
>
> More seriously, you seem to take the problem from the wrong end. If you
> have an ARMv8 core, you should use the PMUv3 driver (because that is
> what your A53 has), and not the ARMv7 PMU.
>
> To that affect, I've posted this[1] a while ago. Can you please give it
> a go?
That seems to be the right direction, however don't you also need to
possibly expose other PMU types as well? Cortex-A53 and Cortex-A57 PMUs
(and possibly more) for instance because there are additional counters
that can be defined specifically for those, e.g: LL = L2 cache on A53,
see [1].
[1]:
https://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux.git/commit/?h=for-next/core&id=f5337346cd8fe1b105f319b4b7fb06fe25c54480
Thanks!
>
> Thanks,
>
> M.
>
> [1]: https://www.spinics.net/lists/arm-kernel/msg571476.html
>
--
Florian
^ permalink raw reply
* [PATCH v3 1/3] arm64: kvm: support kvmtool to detect RAS extension feature
From: Paolo Bonzini @ 2017-05-02 15:48 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170502075631.GE16940@cbox>
On 02/05/2017 09:56, Christoffer Dall wrote:
> Hi Dongjiu,
>
> Please send a cover letter for patch series with more than a single
> patch.
>
> The subject and description of these patches are also misleading.
> Hopefully this is in no way tied to kvmtool, but to userspace
> generically, for example also to be used by QEMU?
Yes, QEMU already has a similar capability on x86.
Does ARM support background scrubbing of memory to detect errors? If
so, are there any plans to support action-optional SIGBUS on ARM?
Paolo
> On Sun, Apr 30, 2017 at 01:37:55PM +0800, Dongjiu Geng wrote:
>> Handle kvmtool's detection for RAS extension, because sometimes
>> the APP needs to know the CPU's capacity
>
> the APP ?
>
> the CPU's capacity?
>
>>
>> Signed-off-by: Dongjiu Geng <gengdongjiu@huawei.com>
>> ---
>> arch/arm64/kvm/reset.c | 11 +++++++++++
>> include/uapi/linux/kvm.h | 1 +
>> 2 files changed, 12 insertions(+)
>>
>> diff --git a/arch/arm64/kvm/reset.c b/arch/arm64/kvm/reset.c
>> index d9e9697..1004039 100644
>> --- a/arch/arm64/kvm/reset.c
>> +++ b/arch/arm64/kvm/reset.c
>> @@ -64,6 +64,14 @@ static bool cpu_has_32bit_el1(void)
>> return !!(pfr0 & 0x20);
>> }
>>
>> +static bool kvm_arm_support_ras_extension(void)
>> +{
>> + u64 pfr0;
>> +
>> + pfr0 = read_system_reg(SYS_ID_AA64PFR0_EL1);
>> + return !!(pfr0 & 0x10000000);
>> +}
>> +
>> /**
>> * kvm_arch_dev_ioctl_check_extension
>> *
>> @@ -87,6 +95,9 @@ int kvm_arch_dev_ioctl_check_extension(struct kvm *kvm, long ext)
>> case KVM_CAP_ARM_PMU_V3:
>> r = kvm_arm_support_pmu_v3();
>> break;
>> + case KVM_CAP_ARM_RAS_EXTENSION:
>> + r = kvm_arm_support_ras_extension();
>> + break;
>
> You need to document this capability and API in
> Documentation/virtual/kvm/api.txt and explain how this works.
>
>
>
>> case KVM_CAP_SET_GUEST_DEBUG:
>> case KVM_CAP_VCPU_ATTRIBUTES:
>> r = 1;
>> diff --git a/include/uapi/linux/kvm.h b/include/uapi/linux/kvm.h
>> index f51d508..27fe556 100644
>> --- a/include/uapi/linux/kvm.h
>> +++ b/include/uapi/linux/kvm.h
>> @@ -883,6 +883,7 @@ struct kvm_ppc_resize_hpt {
>> #define KVM_CAP_PPC_MMU_RADIX 134
>> #define KVM_CAP_PPC_MMU_HASH_V3 135
>> #define KVM_CAP_IMMEDIATE_EXIT 136
>> +#define KVM_CAP_ARM_RAS_EXTENSION 137
>>
>> #ifdef KVM_CAP_IRQ_ROUTING
>>
>> --
>> 2.10.1
>>
>
> Thanks,
> -Christoffer
>
^ permalink raw reply
* [PATCH v3 3/3] arm/arm64: signal SIBGUS and inject SEA Error
From: James Morse @ 2017-05-02 15:41 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1493530677-4919-3-git-send-email-gengdongjiu@huawei.com>
Hi Dongjiu Geng,
On 30/04/17 06:37, Dongjiu Geng wrote:
> when happen SEA, deliver signal bus and handle the ioctl that
> inject SEA abort to guest, so that guest can handle the SEA error.
> diff --git a/arch/arm/kvm/mmu.c b/arch/arm/kvm/mmu.c
> index 105b6ab..a96594f 100644
> --- a/arch/arm/kvm/mmu.c
> +++ b/arch/arm/kvm/mmu.c
> @@ -20,8 +20,10 @@
> @@ -1238,6 +1240,36 @@ static void coherent_cache_guest_page(struct kvm_vcpu *vcpu, kvm_pfn_t pfn,
> __coherent_cache_guest_page(vcpu, pfn, size);
> }
>
> +static void kvm_send_signal(unsigned long address, bool hugetlb, bool hwpoison)
> +{
> + siginfo_t info;
> +
> + info.si_signo = SIGBUS;
> + info.si_errno = 0;
> + if (hwpoison)
> + info.si_code = BUS_MCEERR_AR;
> + else
> + info.si_code = 0;
> +
> + info.si_addr = (void __user *)address;
> + if (hugetlb)
> + info.si_addr_lsb = PMD_SHIFT;
> + else
> + info.si_addr_lsb = PAGE_SHIFT;
> +
> + send_sig_info(SIGBUS, &info, current);
> +}
> +
Punit reviewed the other version of this patch, this PMD_SHIFT is not the right
thing to do, it needs a more accurate set of calls and shifts as there may be
hugetlbfs pages other than PMD_SIZE.
https://www.spinics.net/lists/arm-kernel/msg568919.html
I haven't posted a new version of that patch because I was still hunting a bug
in the hugepage/hwpoison code, even with Punit's fixes series I see -EFAULT
returned to userspace instead of this hwpoison code being invoked.
Please avoid duplicating functionality between patches, it wastes reviewers
time, especially when we know there are problems with this approach.
> +static void kvm_handle_bad_page(unsigned long address,
> + bool hugetlb, bool hwpoison)
> +{
> + /* handle both hwpoison and other synchronous external Abort */
> + if (hwpoison)
> + kvm_send_signal(address, hugetlb, true);
> + else
> + kvm_send_signal(address, hugetlb, false);
> +}
Why the extra level of indirection? We only want to signal userspace like this
from KVM for hwpoison. Signals for RAS related reasons should come from the bits
of the kernel that decoded the error.
(hwpoison for KVM is a corner case as Qemu's memory effectively has two users,
Qemu and KVM. This isn't the example of how user-space gets signalled.)
> diff --git a/arch/arm64/kvm/guest.c b/arch/arm64/kvm/guest.c
> index b37446a..780e3c4 100644
> --- a/arch/arm64/kvm/guest.c
> +++ b/arch/arm64/kvm/guest.c
> @@ -277,6 +277,13 @@ int kvm_arch_vcpu_ioctl_set_sregs(struct kvm_vcpu *vcpu,
> return -EINVAL;
> }
>
> +int kvm_vcpu_ioctl_sea(struct kvm_vcpu *vcpu)
> +{
> + kvm_inject_dabt(vcpu, kvm_vcpu_get_hfar(vcpu));
> +
> + return 0;
> +}
> diff --git a/include/uapi/linux/kvm.h b/include/uapi/linux/kvm.h
> index bb02909..1d2e2e7 100644
> --- a/include/uapi/linux/kvm.h
> +++ b/include/uapi/linux/kvm.h
> @@ -1306,6 +1306,7 @@ struct kvm_s390_ucas_mapping {
> #define KVM_S390_GET_IRQ_STATE _IOW(KVMIO, 0xb6, struct kvm_s390_irq_state)
> /* Available with KVM_CAP_X86_SMM */
> #define KVM_SMI _IO(KVMIO, 0xb7)
> +#define KVM_ARM_SEA _IO(KVMIO, 0xb8)
>
> #define KVM_DEV_ASSIGN_ENABLE_IOMMU (1 << 0)
> #define KVM_DEV_ASSIGN_PCI_2_3 (1 << 1)
>
Why do we need a userspace API for SEA? It can also be done by using
KVM_{G,S}ET_ONE_REG to change the vcpu registers. The advantage of doing it this
way is you can choose which ESR value to use.
Adding a new API call to do something you could do with an old one doesn't look
right.
Thanks,
James
^ permalink raw reply
* [PATCH v3 2/3] arm64: kvm: inject SError with virtual syndrome
From: James Morse @ 2017-05-02 15:37 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1493530677-4919-2-git-send-email-gengdongjiu@huawei.com>
Hi Dongjiu Geng,
On 30/04/17 06:37, Dongjiu Geng wrote:
> when SError happen, kvm notifies kvmtool to generate GHES table
> to record the error, then kvmtools inject the SError with specified
> virtual syndrome. when switch to guest, a virtual SError will happen with
> this specified syndrome.
GHES records in the HEST (T)able have to be generated before the OS starts as
these are read at boot. Did you mean generate CPER records?
It looks like this is based on the earlier SEI series, please work together and
post a combined series when there are changes. (It also good to summarise the
changes in the cover letter.)
This patch is modifying the world-switch to save/restore VSESR. You should
explain that VSESR is the Virtual SError Syndrome, it becomes the ESR value when
HCR_EL2.VSE injects an SError. This register was added by the RAS Extensions and
needs patching in or guarding.
> diff --git a/arch/arm64/kvm/hyp/switch.c b/arch/arm64/kvm/hyp/switch.c
> index aede165..ded6211 100644
> --- a/arch/arm64/kvm/hyp/switch.c
> +++ b/arch/arm64/kvm/hyp/switch.c
> @@ -86,6 +86,13 @@ static void __hyp_text __activate_traps(struct kvm_vcpu *vcpu)
> isb();
> }
> write_sysreg(val, hcr_el2);
> + /* If virtual System Error or Asynchronous Abort is pending. set
> + * the virtual exception syndrome information
> + */
> + if (cpus_have_cap(ARM64_HAS_RAS_EXTN) &&
Is cpus_have_cap() safe to use at EL2?
This would be the first user, and it accesses cpu_hwcaps. You probably want
something like the static_branch_unlikely()s in the vgic code elsewhere in this
file.
> + (vcpu->arch.hcr_el2 & HCR_VSE))
> + write_sysreg_s(vcpu->arch.fault.vsesr_el2, VSESR_EL2);
> +
I think this would be clearer if you took this out to a helper method called
something like restore_vsesr() and did the if(cap|VSE) stuff there.
(Nit: comment style)
> /* Trap on AArch32 cp15 c15 accesses (EL1 or EL0) */
> write_sysreg(1 << 15, hstr_el2);
> /*
> @@ -139,9 +146,15 @@ static void __hyp_text __deactivate_traps(struct kvm_vcpu *vcpu)
> * the crucial bit is "On taking a vSError interrupt,
> * HCR_EL2.VSE is cleared to 0."
> */
> - if (vcpu->arch.hcr_el2 & HCR_VSE)
> + if (vcpu->arch.hcr_el2 & HCR_VSE) {
> vcpu->arch.hcr_el2 = read_sysreg(hcr_el2);
>
> + if (cpus_have_cap(ARM64_HAS_RAS_EXTN)) {
> + /* set vsesr_el2[24:0] with esr_el2[24:0] */
> + kvm_vcpu_set_vsesr(vcpu, read_sysreg_el2(esr)
> + & VSESR_ELx_IDS_ISS_MASK);
There is no need for KVM to save the VSESR. It is copied to ESR_EL1 when
HCR_EL2.VSE delivers the SError, after this we don't care what the register
value is. When we switch to a guest we should set the value from KVM whenever
the VSE bit is set. We should never read back the value in hardware.
Why read ESR_EL2? This will give you a completely unrelated value. If EL2 takes
an IRQ or a page fault between pending the SError and delivering it, we
overwrite the value set by KVM or user-space with a stray EL2 value.
... I think you expect an SError to arrive at EL2 and have its ESR recorded in
vcpu->arch.fault.vsesr_el2. Some time later KVM decides to inject an SError into
the guest, and this ESR is reused...
We shouldn't do this. Qemu/kvmtool may want to inject a virtual-SError that
never started as a physical-SError. Qemu/kvmtool may choose to notify the guest
of RAS events via another mechanism, or not at all.
KVM should not give the guest an ESR value of its choice. For SError the ESR
describes whether the error is corrected, correctable or fatal. Qemu/kvmtool
must choose this.
I think we need an API that allows Qemu/kvmtool to inject SError into a guest,
but that isn't quite what you have here.
The VSESR value should always come from user space. The only exception are
SErrors that we know weren't due to RAS: for these we should set the VSESR to
zero to keep the existing behaviour.
Thanks,
James
^ permalink raw reply
* [PATCH v3 1/3] arm64: kvm: support kvmtool to detect RAS extension feature
From: James Morse @ 2017-05-02 15:29 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1493530677-4919-1-git-send-email-gengdongjiu@huawei.com>
Hi Dongjiu Geng,
On 30/04/17 06:37, Dongjiu Geng wrote:
> Handle kvmtool's detection for RAS extension, because sometimes
> the APP needs to know the CPU's capacity
> diff --git a/arch/arm64/kvm/reset.c b/arch/arm64/kvm/reset.c
> index d9e9697..1004039 100644
> --- a/arch/arm64/kvm/reset.c
> +++ b/arch/arm64/kvm/reset.c
> @@ -64,6 +64,14 @@ static bool cpu_has_32bit_el1(void)
> return !!(pfr0 & 0x20);
> }
>
> +static bool kvm_arm_support_ras_extension(void)
> +{
> + u64 pfr0;
> +
> + pfr0 = read_system_reg(SYS_ID_AA64PFR0_EL1);
> + return !!(pfr0 & 0x10000000);
> +}
Why are we telling user-space that the CPU has RAS extensions? EL0 can't do
anything with this and the guest EL1 can detect it from the id registers.
Are you using this to decide whether or not to generate a HEST for the guest?
If Qemu/kvmtool supports handling memory-failure notifications from signals you
should always generate a HEST. The GHES notification method could be anything
Qemu can deliver to the guest using the KVM APIs. Notifications from Qemu to the
guest don't depend on the RAS extensions. KVM has APIs for IRQ and SEA (you can
use KVM_SET_ONE_REG).
I think we need a new API for injecting SError for SEI from Qemu/kvmtool, but it
shouldn't be related to the RAS extensions. All v8.0 CPUs have HCR_EL2.VSE, so
we need to know KVM supports this API.
Your later patch adds code to set VSESR to make virtual RAS SErrors work, I
think we need to expose that to user-space.
Thanks,
James
^ permalink raw reply
* [PATCH] Remove ARM errata Workarounds 458693 and 460075
From: Catalin Marinas @ 2017-05-02 15:21 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <e7310f9f-96a3-186a-7e5d-7da902bc76f8@arm.com>
On Tue, May 02, 2017 at 01:27:54PM +0100, Robin Murphy wrote:
> On 18/04/17 16:57, Catalin Marinas wrote:
> > On Sun, Apr 16, 2017 at 09:04:46AM +0100, Russell King - ARM Linux wrote:
> >> On Sat, Apr 15, 2017 at 07:06:06PM -0500, Nisal Menuka wrote:
> >>> According to ARM, these errata exist only in a version of Cortex-A8
> >>> (r2p0) which was never built. Therefore, I believe there are no platforms
> >>> where this workaround should be enabled.
> >>> link :http://infocenter.arm.com/help/index.jsp?topic=
> >>> /com.arm.doc.faqs/ka15634.html
> >>
> >> These were submitted by ARM Ltd back in 2009 - if the silicon was never
> >> built, there would've been no reason to submit them. Maybe Catalin can
> >> shed some light on this, being the commit author who introduced these?
> >
> > We normally try not to submit errata workarounds for revisions that are
> > not going to be built/deployed. It's possible that at the time there
> > were plans for r2p0 to be licensed and built (not just FPGA) but I don't
> > really remember the details. The A8 errata document indeed states that
> > r1p0 and r2p0 are obsolete but this can mean many things (like not
> > available to license).
> >
> > I'll try to see if any of the A8 past product managers know anything
> > about this. In the meantime, I would leave them in (no run-time
> > overhead).
>
> FWIW, I just fired up a RealView PB-A8 board to check, and that reports
> r1p1. True, it's not strictly a real silicon implementation (I think
> it's one of the structured ASIC test chips), but since it was, as far as
> I'm aware, a commercially-available development system, it's not
> impossible that someone may still own and use one of these beasts.
The above errata were specific to r1p0 (not r1p1) and r2p0. Since ARM
Ltd claims there are no products built around these revisions, I'm fine
with removing the workarounds from the kernel (internal testchips/FPGA
don't count as products but I doubt they are still relevant 8 years
later).
--
Catalin
^ permalink raw reply
* [PATCH 0/5] KVM/ARM: Fixes for 4.12-rc1
From: Marc Zyngier @ 2017-05-02 15:00 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <75f031d5-d16e-6311-af44-f2c5af5bded4@redhat.com>
On 02/05/17 15:44, Paolo Bonzini wrote:
>
>
> On 02/05/2017 15:30, Marc Zyngier wrote:
>> Here's a handful of random fixes I've queued locally that didn't have
>> a chance to make it in 4.11.
>>
>> The first two patches avoid stack-protector messing with the HYP code,
>> as this ends up being a complete disaster.
>>
>> The following two patches fix a bug introduced in the new vgic, where
>> we may queue HW interrupts with the Pending+Active state, which is
>> illegal.
>>
>> The final patch fixes a misinterpretation of the spec, where we
>> compute the number of APxRn register based on the number of priorities
>> instead of using the number of preemption levels.
>>
>> I've tagged the first 4 patches for stable, given that we're doing
>> something potentially harmful. The last patch is more of a theoretical
>> issue at this stage, so probably need for a backport.
>
> Would you like me to apply them, or are you looking for reviews and
> going to send them in a pull request?
>
> I can wait a couple days before sending my own pull request to Linus.
Christoffer is in charge of the tree at the moment, so I'll leave it up
to him to decide. But my guess is that he will send a PR some time
later, with the rest of the fixes that have been posted lately.
Thanks,
M.
--
Jazz is not dead. It just smells funny...
^ permalink raw reply
* [PATCH v2 1/9] dt-bindings: display: sun4i: Add component endpoint ID numbering scheme
From: Maxime Ripard @ 2017-05-02 14:54 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170428134841.cc5jrqhunh2rxhog@rob-hp-laptop>
Hi,
On Fri, Apr 28, 2017 at 08:48:41AM -0500, Rob Herring wrote:
> On Fri, Apr 21, 2017 at 04:38:49PM +0800, Chen-Yu Tsai wrote:
> > The Allwinner display pipeline contains many hardware components, some
> > of which can consume data from one of multiple upstream components.
> > The numbering scheme of these components must be encoded into the device
> > tree so the driver can figure out which component out of two or more of
> > the same type it is supposed to use or program.
> >
> > This patch adds the constraint that local endpoint IDs must be the index
> > or number of the remote endpoint's hardware block, for all components
> > in the display pipeline up to the TCONs.
> >
> > Signed-off-by: Chen-Yu Tsai <wens@csie.org>
> > ---
> > Documentation/devicetree/bindings/display/sunxi/sun4i-drm.txt | 10 ++++++++++
> > 1 file changed, 10 insertions(+)
> >
> > diff --git a/Documentation/devicetree/bindings/display/sunxi/sun4i-drm.txt b/Documentation/devicetree/bindings/display/sunxi/sun4i-drm.txt
> > index 57a8d0610062..7acdbf14ae1c 100644
> > --- a/Documentation/devicetree/bindings/display/sunxi/sun4i-drm.txt
> > +++ b/Documentation/devicetree/bindings/display/sunxi/sun4i-drm.txt
> > @@ -4,6 +4,16 @@ Allwinner A10 Display Pipeline
> > The Allwinner A10 Display pipeline is composed of several components
> > that are going to be documented below:
> >
> > +For the input port of all components up to the TCON in the display
> > +pipeline, if there are multiple components, the local endpoint IDs
> > +must correspond to the index of the upstream block. For example, if
> > +the remote endpoint is Frontend 1, then the local endpoint ID must
> > +be 1.
> > +
> > +Conversely, for the output ports of the same group, the remote endpoint
> > +ID must be the index of the local hardware block. If the local backend
> > +is backend 1, then the remote endpoint ID must be 1.
>
> It would be clearer if you just explicitly listed IDs and their
> connections. From how this is worded, it would not work if you had
> connections like this:
>
> DevA 0
> DevA 1
> DevB 0
> DevB 1
>
> These would need to be endpoints 0-3 in TCON, and that doesn't reflect
> the remote devices' index.
Chen-Yu, can you send a patch to rephrase the doc that way?
Thanks,
Maxime
--
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20170502/841b73a4/attachment-0001.sig>
^ 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