* [PATCH 6/9] dt-bindings: clock: Convert i.MX27 clock to json-schema
From: Anson Huang @ 2020-05-28 7:27 UTC (permalink / raw)
To: mturquette, sboyd, robh+dt, shawnguo, s.hauer, kernel, festevam,
shc_work, s.trumtrar, linux-clk, devicetree, linux-arm-kernel,
linux-kernel
Cc: Linux-imx
In-Reply-To: <1590650879-18288-1-git-send-email-Anson.Huang@nxp.com>
Convert the i.MX27 clock binding to DT schema format using json-schema.
Signed-off-by: Anson Huang <Anson.Huang@nxp.com>
---
.../devicetree/bindings/clock/imx27-clock.txt | 27 -----------
.../devicetree/bindings/clock/imx27-clock.yaml | 53 ++++++++++++++++++++++
2 files changed, 53 insertions(+), 27 deletions(-)
delete mode 100644 Documentation/devicetree/bindings/clock/imx27-clock.txt
create mode 100644 Documentation/devicetree/bindings/clock/imx27-clock.yaml
diff --git a/Documentation/devicetree/bindings/clock/imx27-clock.txt b/Documentation/devicetree/bindings/clock/imx27-clock.txt
deleted file mode 100644
index 4c95c04..0000000
--- a/Documentation/devicetree/bindings/clock/imx27-clock.txt
+++ /dev/null
@@ -1,27 +0,0 @@
-* Clock bindings for Freescale i.MX27
-
-Required properties:
-- compatible: Should be "fsl,imx27-ccm"
-- reg: Address and length of the register set
-- interrupts: Should contain CCM interrupt
-- #clock-cells: Should be <1>
-
-The clock consumer should specify the desired clock by having the clock
-ID in its "clocks" phandle cell. See include/dt-bindings/clock/imx27-clock.h
-for the full list of i.MX27 clock IDs.
-
-Examples:
- clks: ccm@10027000{
- compatible = "fsl,imx27-ccm";
- reg = <0x10027000 0x1000>;
- #clock-cells = <1>;
- };
-
- uart1: serial@1000a000 {
- compatible = "fsl,imx27-uart", "fsl,imx21-uart";
- reg = <0x1000a000 0x1000>;
- interrupts = <20>;
- clocks = <&clks IMX27_CLK_UART1_IPG_GATE>,
- <&clks IMX27_CLK_PER1_GATE>;
- clock-names = "ipg", "per";
- };
diff --git a/Documentation/devicetree/bindings/clock/imx27-clock.yaml b/Documentation/devicetree/bindings/clock/imx27-clock.yaml
new file mode 100644
index 0000000..2d69807
--- /dev/null
+++ b/Documentation/devicetree/bindings/clock/imx27-clock.yaml
@@ -0,0 +1,53 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/clock/imx27-clock.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Clock bindings for Freescale i.MX27
+
+maintainers:
+ - Fabio Estevam <fabio.estevam@freescale.com>
+
+description: |
+ The clock consumer should specify the desired clock by having the clock
+ ID in its "clocks" phandle cell. See include/dt-bindings/clock/imx27-clock.h
+ for the full list of i.MX27 clock IDs.
+
+properties:
+ compatible:
+ const: fsl,imx27-ccm
+
+ reg:
+ maxItems: 1
+
+ interrupts:
+ maxItems: 1
+
+ '#clock-cells':
+ const: 1
+
+required:
+ - compatible
+ - reg
+ - '#clock-cells'
+
+examples:
+ - |
+ #include <dt-bindings/clock/imx27-clock.h>
+
+ clock-controller@10027000 {
+ compatible = "fsl,imx27-ccm";
+ reg = <0x10027000 0x1000>;
+ interrupts = <31>;
+ #clock-cells = <1>;
+ };
+
+ serial@1000a000 {
+ compatible = "fsl,imx27-uart", "fsl,imx21-uart";
+ reg = <0x1000a000 0x1000>;
+ interrupts = <20>;
+ clocks = <&clks IMX27_CLK_UART1_IPG_GATE>,
+ <&clks IMX27_CLK_PER1_GATE>;
+ clock-names = "ipg", "per";
+ };
--
2.7.4
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH 5/9] dt-bindings: clock: Convert i.MX23 clock to json-schema
From: Anson Huang @ 2020-05-28 7:27 UTC (permalink / raw)
To: mturquette, sboyd, robh+dt, shawnguo, s.hauer, kernel, festevam,
shc_work, s.trumtrar, linux-clk, devicetree, linux-arm-kernel,
linux-kernel
Cc: Linux-imx
In-Reply-To: <1590650879-18288-1-git-send-email-Anson.Huang@nxp.com>
Convert the i.MX23 clock binding to DT schema format using json-schema.
Signed-off-by: Anson Huang <Anson.Huang@nxp.com>
---
.../devicetree/bindings/clock/imx23-clock.txt | 70 -----------------
.../devicetree/bindings/clock/imx23-clock.yaml | 90 ++++++++++++++++++++++
2 files changed, 90 insertions(+), 70 deletions(-)
delete mode 100644 Documentation/devicetree/bindings/clock/imx23-clock.txt
create mode 100644 Documentation/devicetree/bindings/clock/imx23-clock.yaml
diff --git a/Documentation/devicetree/bindings/clock/imx23-clock.txt b/Documentation/devicetree/bindings/clock/imx23-clock.txt
deleted file mode 100644
index 8385348..0000000
--- a/Documentation/devicetree/bindings/clock/imx23-clock.txt
+++ /dev/null
@@ -1,70 +0,0 @@
-* Clock bindings for Freescale i.MX23
-
-Required properties:
-- compatible: Should be "fsl,imx23-clkctrl"
-- reg: Address and length of the register set
-- #clock-cells: Should be <1>
-
-The clock consumer should specify the desired clock by having the clock
-ID in its "clocks" phandle cell. The following is a full list of i.MX23
-clocks and IDs.
-
- Clock ID
- ------------------
- ref_xtal 0
- pll 1
- ref_cpu 2
- ref_emi 3
- ref_pix 4
- ref_io 5
- saif_sel 6
- lcdif_sel 7
- gpmi_sel 8
- ssp_sel 9
- emi_sel 10
- cpu 11
- etm_sel 12
- cpu_pll 13
- cpu_xtal 14
- hbus 15
- xbus 16
- lcdif_div 17
- ssp_div 18
- gpmi_div 19
- emi_pll 20
- emi_xtal 21
- etm_div 22
- saif_div 23
- clk32k_div 24
- rtc 25
- adc 26
- spdif_div 27
- clk32k 28
- dri 29
- pwm 30
- filt 31
- uart 32
- ssp 33
- gpmi 34
- spdif 35
- emi 36
- saif 37
- lcdif 38
- etm 39
- usb 40
- usb_phy 41
-
-Examples:
-
-clks: clkctrl@80040000 {
- compatible = "fsl,imx23-clkctrl";
- reg = <0x80040000 0x2000>;
- #clock-cells = <1>;
-};
-
-auart0: serial@8006c000 {
- compatible = "fsl,imx23-auart";
- reg = <0x8006c000 0x2000>;
- interrupts = <24 25 23>;
- clocks = <&clks 32>;
-};
diff --git a/Documentation/devicetree/bindings/clock/imx23-clock.yaml b/Documentation/devicetree/bindings/clock/imx23-clock.yaml
new file mode 100644
index 0000000..0fd21f1
--- /dev/null
+++ b/Documentation/devicetree/bindings/clock/imx23-clock.yaml
@@ -0,0 +1,90 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/clock/imx23-clock.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Clock bindings for Freescale i.MX23
+
+maintainers:
+ - Shawn Guo <shawn.guo@linaro.org>
+
+description: |
+ The clock consumer should specify the desired clock by having the clock
+ ID in its "clocks" phandle cell. The following is a full list of i.MX23
+ clocks and IDs.
+
+ Clock ID
+ ------------------
+ ref_xtal 0
+ pll 1
+ ref_cpu 2
+ ref_emi 3
+ ref_pix 4
+ ref_io 5
+ saif_sel 6
+ lcdif_sel 7
+ gpmi_sel 8
+ ssp_sel 9
+ emi_sel 10
+ cpu 11
+ etm_sel 12
+ cpu_pll 13
+ cpu_xtal 14
+ hbus 15
+ xbus 16
+ lcdif_div 17
+ ssp_div 18
+ gpmi_div 19
+ emi_pll 20
+ emi_xtal 21
+ etm_div 22
+ saif_div 23
+ clk32k_div 24
+ rtc 25
+ adc 26
+ spdif_div 27
+ clk32k 28
+ dri 29
+ pwm 30
+ filt 31
+ uart 32
+ ssp 33
+ gpmi 34
+ spdif 35
+ emi 36
+ saif 37
+ lcdif 38
+ etm 39
+ usb 40
+ usb_phy 41
+
+properties:
+ compatible:
+ const: fsl,imx23-clkctrl
+
+ reg:
+ maxItems: 1
+
+ '#clock-cells':
+ const: 1
+
+required:
+ - compatible
+ - reg
+ - '#clock-cells'
+
+examples:
+ - |
+ clock-controller@80040000 {
+ compatible = "fsl,imx23-clkctrl";
+ reg = <0x80040000 0x2000>;
+ #clock-cells = <1>;
+ };
+
+ serial@8006c000 {
+ compatible = "fsl,imx23-auart";
+ reg = <0x8006c000 0x2000>;
+ interrupts = <24 25 23>;
+ clocks = <&clks 32>;
+ };
--
2.7.4
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH 7/9] dt-bindings: clock: Convert i.MX25 clock to json-schema
From: Anson Huang @ 2020-05-28 7:27 UTC (permalink / raw)
To: mturquette, sboyd, robh+dt, shawnguo, s.hauer, kernel, festevam,
shc_work, s.trumtrar, linux-clk, devicetree, linux-arm-kernel,
linux-kernel
Cc: Linux-imx
In-Reply-To: <1590650879-18288-1-git-send-email-Anson.Huang@nxp.com>
Convert the i.MX25 clock binding to DT schema format using json-schema.
Signed-off-by: Anson Huang <Anson.Huang@nxp.com>
---
.../devicetree/bindings/clock/imx25-clock.txt | 160 ------------------
.../devicetree/bindings/clock/imx25-clock.yaml | 184 +++++++++++++++++++++
2 files changed, 184 insertions(+), 160 deletions(-)
delete mode 100644 Documentation/devicetree/bindings/clock/imx25-clock.txt
create mode 100644 Documentation/devicetree/bindings/clock/imx25-clock.yaml
diff --git a/Documentation/devicetree/bindings/clock/imx25-clock.txt b/Documentation/devicetree/bindings/clock/imx25-clock.txt
deleted file mode 100644
index f8135ea..0000000
--- a/Documentation/devicetree/bindings/clock/imx25-clock.txt
+++ /dev/null
@@ -1,160 +0,0 @@
-* Clock bindings for Freescale i.MX25
-
-Required properties:
-- compatible: Should be "fsl,imx25-ccm"
-- reg: Address and length of the register set
-- interrupts: Should contain CCM interrupt
-- #clock-cells: Should be <1>
-
-The clock consumer should specify the desired clock by having the clock
-ID in its "clocks" phandle cell. The following is a full list of i.MX25
-clocks and IDs.
-
- Clock ID
- ---------------------------
- dummy 0
- osc 1
- mpll 2
- upll 3
- mpll_cpu_3_4 4
- cpu_sel 5
- cpu 6
- ahb 7
- usb_div 8
- ipg 9
- per0_sel 10
- per1_sel 11
- per2_sel 12
- per3_sel 13
- per4_sel 14
- per5_sel 15
- per6_sel 16
- per7_sel 17
- per8_sel 18
- per9_sel 19
- per10_sel 20
- per11_sel 21
- per12_sel 22
- per13_sel 23
- per14_sel 24
- per15_sel 25
- per0 26
- per1 27
- per2 28
- per3 29
- per4 30
- per5 31
- per6 32
- per7 33
- per8 34
- per9 35
- per10 36
- per11 37
- per12 38
- per13 39
- per14 40
- per15 41
- csi_ipg_per 42
- epit_ipg_per 43
- esai_ipg_per 44
- esdhc1_ipg_per 45
- esdhc2_ipg_per 46
- gpt_ipg_per 47
- i2c_ipg_per 48
- lcdc_ipg_per 49
- nfc_ipg_per 50
- owire_ipg_per 51
- pwm_ipg_per 52
- sim1_ipg_per 53
- sim2_ipg_per 54
- ssi1_ipg_per 55
- ssi2_ipg_per 56
- uart_ipg_per 57
- ata_ahb 58
- reserved 59
- csi_ahb 60
- emi_ahb 61
- esai_ahb 62
- esdhc1_ahb 63
- esdhc2_ahb 64
- fec_ahb 65
- lcdc_ahb 66
- rtic_ahb 67
- sdma_ahb 68
- slcdc_ahb 69
- usbotg_ahb 70
- reserved 71
- reserved 72
- reserved 73
- reserved 74
- can1_ipg 75
- can2_ipg 76
- csi_ipg 77
- cspi1_ipg 78
- cspi2_ipg 79
- cspi3_ipg 80
- dryice_ipg 81
- ect_ipg 82
- epit1_ipg 83
- epit2_ipg 84
- reserved 85
- esdhc1_ipg 86
- esdhc2_ipg 87
- fec_ipg 88
- reserved 89
- reserved 90
- reserved 91
- gpt1_ipg 92
- gpt2_ipg 93
- gpt3_ipg 94
- gpt4_ipg 95
- reserved 96
- reserved 97
- reserved 98
- iim_ipg 99
- reserved 100
- reserved 101
- kpp_ipg 102
- lcdc_ipg 103
- reserved 104
- pwm1_ipg 105
- pwm2_ipg 106
- pwm3_ipg 107
- pwm4_ipg 108
- rngb_ipg 109
- reserved 110
- scc_ipg 111
- sdma_ipg 112
- sim1_ipg 113
- sim2_ipg 114
- slcdc_ipg 115
- spba_ipg 116
- ssi1_ipg 117
- ssi2_ipg 118
- tsc_ipg 119
- uart1_ipg 120
- uart2_ipg 121
- uart3_ipg 122
- uart4_ipg 123
- uart5_ipg 124
- reserved 125
- wdt_ipg 126
- cko_div 127
- cko_sel 128
- cko 129
-
-Examples:
-
-clks: ccm@53f80000 {
- compatible = "fsl,imx25-ccm";
- reg = <0x53f80000 0x4000>;
- interrupts = <31>;
-};
-
-uart1: serial@43f90000 {
- compatible = "fsl,imx25-uart", "fsl,imx21-uart";
- reg = <0x43f90000 0x4000>;
- interrupts = <45>;
- clocks = <&clks 79>, <&clks 50>;
- clock-names = "ipg", "per";
-};
diff --git a/Documentation/devicetree/bindings/clock/imx25-clock.yaml b/Documentation/devicetree/bindings/clock/imx25-clock.yaml
new file mode 100644
index 0000000..d25c537
--- /dev/null
+++ b/Documentation/devicetree/bindings/clock/imx25-clock.yaml
@@ -0,0 +1,184 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/clock/imx25-clock.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Clock bindings for Freescale i.MX25
+
+maintainers:
+ - Sascha Hauer <s.hauer@pengutronix.de>
+
+description: |
+ The clock consumer should specify the desired clock by having the clock
+ ID in its "clocks" phandle cell. The following is a full list of i.MX25
+ clocks and IDs.
+
+ Clock ID
+ --------------------------
+ dummy 0
+ osc 1
+ mpll 2
+ upll 3
+ mpll_cpu_3_4 4
+ cpu_sel 5
+ cpu 6
+ ahb 7
+ usb_div 8
+ ipg 9
+ per0_sel 10
+ per1_sel 11
+ per2_sel 12
+ per3_sel 13
+ per4_sel 14
+ per5_sel 15
+ per6_sel 16
+ per7_sel 17
+ per8_sel 18
+ per9_sel 19
+ per10_sel 20
+ per11_sel 21
+ per12_sel 22
+ per13_sel 23
+ per14_sel 24
+ per15_sel 25
+ per0 26
+ per1 27
+ per2 28
+ per3 29
+ per4 30
+ per5 31
+ per6 32
+ per7 33
+ per8 34
+ per9 35
+ per10 36
+ per11 37
+ per12 38
+ per13 39
+ per14 40
+ per15 41
+ csi_ipg_per 42
+ epit_ipg_per 43
+ esai_ipg_per 44
+ esdhc1_ipg_per 45
+ esdhc2_ipg_per 46
+ gpt_ipg_per 47
+ i2c_ipg_per 48
+ lcdc_ipg_per 49
+ nfc_ipg_per 50
+ owire_ipg_per 51
+ pwm_ipg_per 52
+ sim1_ipg_per 53
+ sim2_ipg_per 54
+ ssi1_ipg_per 55
+ ssi2_ipg_per 56
+ uart_ipg_per 57
+ ata_ahb 58
+ reserved 59
+ csi_ahb 60
+ emi_ahb 61
+ esai_ahb 62
+ esdhc1_ahb 63
+ esdhc2_ahb 64
+ fec_ahb 65
+ lcdc_ahb 66
+ rtic_ahb 67
+ sdma_ahb 68
+ slcdc_ahb 69
+ usbotg_ahb 70
+ reserved 71
+ reserved 72
+ reserved 73
+ reserved 74
+ can1_ipg 75
+ can2_ipg 76
+ csi_ipg 77
+ cspi1_ipg 78
+ cspi2_ipg 79
+ cspi3_ipg 80
+ dryice_ipg 81
+ ect_ipg 82
+ epit1_ipg 83
+ epit2_ipg 84
+ reserved 85
+ esdhc1_ipg 86
+ esdhc2_ipg 87
+ fec_ipg 88
+ reserved 89
+ reserved 90
+ reserved 91
+ gpt1_ipg 92
+ gpt2_ipg 93
+ gpt3_ipg 94
+ gpt4_ipg 95
+ reserved 96
+ reserved 97
+ reserved 98
+ iim_ipg 99
+ reserved 100
+ reserved 101
+ kpp_ipg 102
+ lcdc_ipg 103
+ reserved 104
+ pwm1_ipg 105
+ pwm2_ipg 106
+ pwm3_ipg 107
+ pwm4_ipg 108
+ rngb_ipg 109
+ reserved 110
+ scc_ipg 111
+ sdma_ipg 112
+ sim1_ipg 113
+ sim2_ipg 114
+ slcdc_ipg 115
+ spba_ipg 116
+ ssi1_ipg 117
+ ssi2_ipg 118
+ tsc_ipg 119
+ uart1_ipg 120
+ uart2_ipg 121
+ uart3_ipg 122
+ uart4_ipg 123
+ uart5_ipg 124
+ reserved 125
+ wdt_ipg 126
+ cko_div 127
+ cko_sel 128
+ cko 129
+
+properties:
+ compatible:
+ const: fsl,imx25-ccm
+
+ reg:
+ maxItems: 1
+
+ interrupts:
+ maxItems: 1
+
+ '#clock-cells':
+ const: 1
+
+required:
+ - compatible
+ - reg
+ - interrupts
+ - '#clock-cells'
+
+examples:
+ - |
+ clock-controller@53f80000 {
+ compatible = "fsl,imx25-ccm";
+ reg = <0x53f80000 0x4000>;
+ interrupts = <31>;
+ #clock-cells = <1>;
+ };
+
+ serial@43f90000 {
+ compatible = "fsl,imx25-uart", "fsl,imx21-uart";
+ reg = <0x43f90000 0x4000>;
+ interrupts = <45>;
+ clocks = <&clks 79>, <&clks 50>;
+ clock-names = "ipg", "per";
+ };
--
2.7.4
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH 9/9] dt-bindings: clock: Convert i.MX1 clock to json-schema
From: Anson Huang @ 2020-05-28 7:27 UTC (permalink / raw)
To: mturquette, sboyd, robh+dt, shawnguo, s.hauer, kernel, festevam,
shc_work, s.trumtrar, linux-clk, devicetree, linux-arm-kernel,
linux-kernel
Cc: Linux-imx
In-Reply-To: <1590650879-18288-1-git-send-email-Anson.Huang@nxp.com>
Convert the i.MX1 clock binding to DT schema format using json-schema.
Signed-off-by: Anson Huang <Anson.Huang@nxp.com>
---
.../devicetree/bindings/clock/imx1-clock.txt | 26 ------------
.../devicetree/bindings/clock/imx1-clock.yaml | 49 ++++++++++++++++++++++
2 files changed, 49 insertions(+), 26 deletions(-)
delete mode 100644 Documentation/devicetree/bindings/clock/imx1-clock.txt
create mode 100644 Documentation/devicetree/bindings/clock/imx1-clock.yaml
diff --git a/Documentation/devicetree/bindings/clock/imx1-clock.txt b/Documentation/devicetree/bindings/clock/imx1-clock.txt
deleted file mode 100644
index 9823baf..0000000
--- a/Documentation/devicetree/bindings/clock/imx1-clock.txt
+++ /dev/null
@@ -1,26 +0,0 @@
-* Clock bindings for Freescale i.MX1 CPUs
-
-Required properties:
-- compatible: Should be "fsl,imx1-ccm".
-- reg: Address and length of the register set.
-- #clock-cells: Should be <1>.
-
-The clock consumer should specify the desired clock by having the clock
-ID in its "clocks" phandle cell. See include/dt-bindings/clock/imx1-clock.h
-for the full list of i.MX1 clock IDs.
-
-Examples:
- clks: ccm@21b000 {
- #clock-cells = <1>;
- compatible = "fsl,imx1-ccm";
- reg = <0x0021b000 0x1000>;
- };
-
- pwm: pwm@208000 {
- #pwm-cells = <2>;
- compatible = "fsl,imx1-pwm";
- reg = <0x00208000 0x1000>;
- interrupts = <34>;
- clocks = <&clks IMX1_CLK_DUMMY>, <&clks IMX1_CLK_PER1>;
- clock-names = "ipg", "per";
- };
diff --git a/Documentation/devicetree/bindings/clock/imx1-clock.yaml b/Documentation/devicetree/bindings/clock/imx1-clock.yaml
new file mode 100644
index 0000000..06a0ff9
--- /dev/null
+++ b/Documentation/devicetree/bindings/clock/imx1-clock.yaml
@@ -0,0 +1,49 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/clock/imx1-clock.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Clock bindings for Freescale i.MX1 CPUs
+
+maintainers:
+ - Alexander Shiyan <shc_work@mail.ru>
+
+description: |
+ The clock consumer should specify the desired clock by having the clock
+ ID in its "clocks" phandle cell. See include/dt-bindings/clock/imx1-clock.h
+ for the full list of i.MX1 clock IDs.
+
+properties:
+ compatible:
+ const: fsl,imx1-ccm
+
+ reg:
+ maxItems: 1
+
+ '#clock-cells':
+ const: 1
+
+required:
+ - compatible
+ - reg
+ - '#clock-cells'
+
+examples:
+ - |
+ #include <dt-bindings/clock/imx1-clock.h>
+
+ clock-controller@21b000 {
+ #clock-cells = <1>;
+ compatible = "fsl,imx1-ccm";
+ reg = <0x0021b000 0x1000>;
+ };
+
+ pwm@208000 {
+ #pwm-cells = <2>;
+ compatible = "fsl,imx1-pwm";
+ reg = <0x00208000 0x1000>;
+ interrupts = <34>;
+ clocks = <&clks IMX1_CLK_DUMMY>, <&clks IMX1_CLK_PER1>;
+ clock-names = "ipg", "per";
+ };
--
2.7.4
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH 8/9] dt-bindings: clock: Convert i.MX21 clock to json-schema
From: Anson Huang @ 2020-05-28 7:27 UTC (permalink / raw)
To: mturquette, sboyd, robh+dt, shawnguo, s.hauer, kernel, festevam,
shc_work, s.trumtrar, linux-clk, devicetree, linux-arm-kernel,
linux-kernel
Cc: Linux-imx
In-Reply-To: <1590650879-18288-1-git-send-email-Anson.Huang@nxp.com>
Convert the i.MX21 clock binding to DT schema format using json-schema,
can NOT find any CCM interrupt info from reference manual and DT file,
so interrupts property is removed from original binding doc.
Signed-off-by: Anson Huang <Anson.Huang@nxp.com>
---
.../devicetree/bindings/clock/imx21-clock.txt | 27 ------------
.../devicetree/bindings/clock/imx21-clock.yaml | 49 ++++++++++++++++++++++
2 files changed, 49 insertions(+), 27 deletions(-)
delete mode 100644 Documentation/devicetree/bindings/clock/imx21-clock.txt
create mode 100644 Documentation/devicetree/bindings/clock/imx21-clock.yaml
diff --git a/Documentation/devicetree/bindings/clock/imx21-clock.txt b/Documentation/devicetree/bindings/clock/imx21-clock.txt
deleted file mode 100644
index 806f63d..0000000
--- a/Documentation/devicetree/bindings/clock/imx21-clock.txt
+++ /dev/null
@@ -1,27 +0,0 @@
-* Clock bindings for Freescale i.MX21
-
-Required properties:
-- compatible : Should be "fsl,imx21-ccm".
-- reg : Address and length of the register set.
-- interrupts : Should contain CCM interrupt.
-- #clock-cells: Should be <1>.
-
-The clock consumer should specify the desired clock by having the clock
-ID in its "clocks" phandle cell. See include/dt-bindings/clock/imx21-clock.h
-for the full list of i.MX21 clock IDs.
-
-Examples:
- clks: ccm@10027000{
- compatible = "fsl,imx21-ccm";
- reg = <0x10027000 0x800>;
- #clock-cells = <1>;
- };
-
- uart1: serial@1000a000 {
- compatible = "fsl,imx21-uart";
- reg = <0x1000a000 0x1000>;
- interrupts = <20>;
- clocks = <&clks IMX21_CLK_UART1_IPG_GATE>,
- <&clks IMX21_CLK_PER1>;
- clock-names = "ipg", "per";
- };
diff --git a/Documentation/devicetree/bindings/clock/imx21-clock.yaml b/Documentation/devicetree/bindings/clock/imx21-clock.yaml
new file mode 100644
index 0000000..cee9b00
--- /dev/null
+++ b/Documentation/devicetree/bindings/clock/imx21-clock.yaml
@@ -0,0 +1,49 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/clock/imx21-clock.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Clock bindings for Freescale i.MX21
+
+maintainers:
+ - Alexander Shiyan <shc_work@mail.ru>
+
+description: |
+ The clock consumer should specify the desired clock by having the clock
+ ID in its "clocks" phandle cell. See include/dt-bindings/clock/imx21-clock.h
+ for the full list of i.MX21 clock IDs.
+
+properties:
+ compatible:
+ const: fsl,imx21-ccm
+
+ reg:
+ maxItems: 1
+
+ '#clock-cells':
+ const: 1
+
+required:
+ - compatible
+ - reg
+ - '#clock-cells'
+
+examples:
+ - |
+ #include <dt-bindings/clock/imx21-clock.h>
+
+ clock-controller@10027000 {
+ compatible = "fsl,imx21-ccm";
+ reg = <0x10027000 0x800>;
+ #clock-cells = <1>;
+ };
+
+ serial@1000a000 {
+ compatible = "fsl,imx21-uart";
+ reg = <0x1000a000 0x1000>;
+ interrupts = <20>;
+ clocks = <&clks IMX21_CLK_UART1_IPG_GATE>,
+ <&clks IMX21_CLK_PER1>;
+ clock-names = "ipg", "per";
+ };
--
2.7.4
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH 0/3] STM32 update uart4 pin configuration for low power
From: Erwan Le Ray @ 2020-05-28 7:38 UTC (permalink / raw)
To: Maxime Coquelin, Alexandre Torgue, Rob Herring, Mark Rutland
Cc: devicetree, linux-kernel, linux-arm-kernel, Fabrice Gasnier,
linux-stm32, Erwan Le Ray
Update uart4 pin configuration for low power in pinctrl, and for ed/ev
and dkx boards.
Erwan Le Ray (3):
ARM: dts: stm32: update uart4 pin configuration for low power on
stm32mp157
ARM: dts: stm32: Update pin states for uart4 on stm32mp157c-ed1
ARM: dts: stm32: Update UART4 pin states on stm32mp15xx-dkx
arch/arm/boot/dts/stm32mp15-pinctrl.dtsi | 17 +++++++++++++++++
arch/arm/boot/dts/stm32mp157c-ed1.dts | 4 +++-
arch/arm/boot/dts/stm32mp15xx-dkx.dtsi | 4 +++-
3 files changed, 23 insertions(+), 2 deletions(-)
--
2.17.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH 3/3] ARM: dts: stm32: Update UART4 pin states on stm32mp15xx-dkx
From: Erwan Le Ray @ 2020-05-28 7:38 UTC (permalink / raw)
To: Maxime Coquelin, Alexandre Torgue, Rob Herring, Mark Rutland
Cc: devicetree, linux-kernel, linux-arm-kernel, Fabrice Gasnier,
linux-stm32, Erwan Le Ray
In-Reply-To: <20200528073853.24759-1-erwan.leray@st.com>
Add sleep and idle states to uart4 pin configuration.
Signed-off-by: Erwan Le Ray <erwan.leray@st.com>
diff --git a/arch/arm/boot/dts/stm32mp15xx-dkx.dtsi b/arch/arm/boot/dts/stm32mp15xx-dkx.dtsi
index 70db923a45f7..e5fdbc149bf4 100644
--- a/arch/arm/boot/dts/stm32mp15xx-dkx.dtsi
+++ b/arch/arm/boot/dts/stm32mp15xx-dkx.dtsi
@@ -584,8 +584,10 @@
};
&uart4 {
- pinctrl-names = "default";
+ pinctrl-names = "default", "sleep", "idle";
pinctrl-0 = <&uart4_pins_a>;
+ pinctrl-1 = <&uart4_sleep_pins_a>;
+ pinctrl-2 = <&uart4_idle_pins_a>;
status = "okay";
};
--
2.17.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH 1/3] ARM: dts: stm32: update uart4 pin configuration for low power on stm32mp157
From: Erwan Le Ray @ 2020-05-28 7:38 UTC (permalink / raw)
To: Maxime Coquelin, Alexandre Torgue, Rob Herring, Mark Rutland
Cc: devicetree, linux-kernel, linux-arm-kernel, Bich Hemon,
Fabrice Gasnier, linux-stm32, Erwan Le Ray
In-Reply-To: <20200528073853.24759-1-erwan.leray@st.com>
Sleep pin configuration is refined for low power modes:
- "sleep" (no wakeup & console suspend enabled): put pins in analog state
to optimize power
- "idle" (wakeup capability): keep Rx pin in alternate function
Signed-off-by: Bich Hemon <bich.hemon@st.com>
Signed-off-by: Erwan Le Ray <erwan.leray@st.com>
diff --git a/arch/arm/boot/dts/stm32mp15-pinctrl.dtsi b/arch/arm/boot/dts/stm32mp15-pinctrl.dtsi
index 7eb858732d6d..7cf535dc05f5 100644
--- a/arch/arm/boot/dts/stm32mp15-pinctrl.dtsi
+++ b/arch/arm/boot/dts/stm32mp15-pinctrl.dtsi
@@ -1648,6 +1648,23 @@
};
};
+ uart4_idle_pins_a: uart4-idle-0 {
+ pins1 {
+ pinmux = <STM32_PINMUX('G', 11, ANALOG)>; /* UART4_TX */
+ };
+ pins2 {
+ pinmux = <STM32_PINMUX('B', 2, AF8)>; /* UART4_RX */
+ bias-disable;
+ };
+ };
+
+ uart4_sleep_pins_a: uart4-sleep-0 {
+ pins {
+ pinmux = <STM32_PINMUX('G', 11, ANALOG)>, /* UART4_TX */
+ <STM32_PINMUX('B', 2, ANALOG)>; /* UART4_RX */
+ };
+ };
+
uart4_pins_b: uart4-1 {
pins1 {
pinmux = <STM32_PINMUX('D', 1, AF8)>; /* UART4_TX */
--
2.17.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH 2/3] ARM: dts: stm32: Update pin states for uart4 on stm32mp157c-ed1
From: Erwan Le Ray @ 2020-05-28 7:38 UTC (permalink / raw)
To: Maxime Coquelin, Alexandre Torgue, Rob Herring, Mark Rutland
Cc: devicetree, linux-kernel, linux-arm-kernel, Fabrice Gasnier,
linux-stm32, Erwan Le Ray
In-Reply-To: <20200528073853.24759-1-erwan.leray@st.com>
Add sleep and idle states to uart4 pin configuration.
Signed-off-by: Erwan Le Ray <erwan.leray@st.com>
diff --git a/arch/arm/boot/dts/stm32mp157c-ed1.dts b/arch/arm/boot/dts/stm32mp157c-ed1.dts
index 32ccd50b4144..ca109dc18238 100644
--- a/arch/arm/boot/dts/stm32mp157c-ed1.dts
+++ b/arch/arm/boot/dts/stm32mp157c-ed1.dts
@@ -353,8 +353,10 @@
};
&uart4 {
- pinctrl-names = "default";
+ pinctrl-names = "default", "sleep", "idle";
pinctrl-0 = <&uart4_pins_a>;
+ pinctrl-1 = <&uart4_sleep_pins_a>;
+ pinctrl-2 = <&uart4_idle_pins_a>;
status = "okay";
};
--
2.17.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH 0/2] STM32 Fix uart nodes in stm32mp15-pinctrl
From: Erwan Le Ray @ 2020-05-28 7:40 UTC (permalink / raw)
To: Maxime Coquelin, Alexandre Torgue, Rob Herring, Mark Rutland
Cc: devicetree, linux-kernel, linux-arm-kernel, Fabrice Gasnier,
linux-stm32, Erwan Le Ray
Fix uart nodes ordering and uart7_pins_a comments in stm32mp15-pinctrl.
Erwan Le Ray (2):
ARM: dts: stm32: fix uart nodes ordering in stm32mp15-pinctrl
ARM: dts: stm32: fix uart7_pins_a comments in stm32mp15-pinctrl
arch/arm/boot/dts/stm32mp15-pinctrl.dtsi | 130 +++++++++++------------
1 file changed, 65 insertions(+), 65 deletions(-)
--
2.17.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH 1/2] ARM: dts: stm32: fix uart nodes ordering in stm32mp15-pinctrl
From: Erwan Le Ray @ 2020-05-28 7:40 UTC (permalink / raw)
To: Maxime Coquelin, Alexandre Torgue, Rob Herring, Mark Rutland
Cc: devicetree, linux-kernel, linux-arm-kernel, Fabrice Gasnier,
linux-stm32, Erwan Le Ray
In-Reply-To: <20200528074003.24875-1-erwan.leray@st.com>
Fix usart and uart nodes ordering. Several usart nodes didn't respect
expecting ordering.
Fixes: 077e0638fc83 ("ARM: dts: stm32: Add alternate pinmux for USART2 pins on stm32mp15")
Signed-off-by: Erwan Le Ray <erwan.leray@st.com>
diff --git a/arch/arm/boot/dts/stm32mp15-pinctrl.dtsi b/arch/arm/boot/dts/stm32mp15-pinctrl.dtsi
index 7cf535dc05f5..5ff1323236e1 100644
--- a/arch/arm/boot/dts/stm32mp15-pinctrl.dtsi
+++ b/arch/arm/boot/dts/stm32mp15-pinctrl.dtsi
@@ -1574,67 +1574,6 @@
};
};
- usart2_pins_a: usart2-0 {
- pins1 {
- pinmux = <STM32_PINMUX('F', 5, AF7)>, /* USART2_TX */
- <STM32_PINMUX('D', 4, AF7)>; /* USART2_RTS */
- bias-disable;
- drive-push-pull;
- slew-rate = <0>;
- };
- pins2 {
- pinmux = <STM32_PINMUX('D', 6, AF7)>, /* USART2_RX */
- <STM32_PINMUX('D', 3, AF7)>; /* USART2_CTS_NSS */
- bias-disable;
- };
- };
-
- usart2_sleep_pins_a: usart2-sleep-0 {
- pins {
- pinmux = <STM32_PINMUX('F', 5, ANALOG)>, /* USART2_TX */
- <STM32_PINMUX('D', 4, ANALOG)>, /* USART2_RTS */
- <STM32_PINMUX('D', 6, ANALOG)>, /* USART2_RX */
- <STM32_PINMUX('D', 3, ANALOG)>; /* USART2_CTS_NSS */
- };
- };
-
- usart2_pins_b: usart2-1 {
- pins1 {
- pinmux = <STM32_PINMUX('F', 5, AF7)>, /* USART2_TX */
- <STM32_PINMUX('A', 1, AF7)>; /* USART2_RTS */
- bias-disable;
- drive-push-pull;
- slew-rate = <0>;
- };
- pins2 {
- pinmux = <STM32_PINMUX('F', 4, AF7)>, /* USART2_RX */
- <STM32_PINMUX('E', 15, AF7)>; /* USART2_CTS_NSS */
- bias-disable;
- };
- };
-
- usart2_sleep_pins_b: usart2-sleep-1 {
- pins {
- pinmux = <STM32_PINMUX('F', 5, ANALOG)>, /* USART2_TX */
- <STM32_PINMUX('A', 1, ANALOG)>, /* USART2_RTS */
- <STM32_PINMUX('F', 4, ANALOG)>, /* USART2_RX */
- <STM32_PINMUX('E', 15, ANALOG)>; /* USART2_CTS_NSS */
- };
- };
-
- usart3_pins_a: usart3-0 {
- pins1 {
- pinmux = <STM32_PINMUX('B', 10, AF7)>; /* USART3_TX */
- bias-disable;
- drive-push-pull;
- slew-rate = <0>;
- };
- pins2 {
- pinmux = <STM32_PINMUX('B', 12, AF8)>; /* USART3_RX */
- bias-disable;
- };
- };
-
uart4_pins_a: uart4-0 {
pins1 {
pinmux = <STM32_PINMUX('G', 11, AF6)>; /* UART4_TX */
@@ -1732,6 +1671,67 @@
};
};
+ usart2_pins_a: usart2-0 {
+ pins1 {
+ pinmux = <STM32_PINMUX('F', 5, AF7)>, /* USART2_TX */
+ <STM32_PINMUX('D', 4, AF7)>; /* USART2_RTS */
+ bias-disable;
+ drive-push-pull;
+ slew-rate = <0>;
+ };
+ pins2 {
+ pinmux = <STM32_PINMUX('D', 6, AF7)>, /* USART2_RX */
+ <STM32_PINMUX('D', 3, AF7)>; /* USART2_CTS_NSS */
+ bias-disable;
+ };
+ };
+
+ usart2_sleep_pins_a: usart2-sleep-0 {
+ pins {
+ pinmux = <STM32_PINMUX('F', 5, ANALOG)>, /* USART2_TX */
+ <STM32_PINMUX('D', 4, ANALOG)>, /* USART2_RTS */
+ <STM32_PINMUX('D', 6, ANALOG)>, /* USART2_RX */
+ <STM32_PINMUX('D', 3, ANALOG)>; /* USART2_CTS_NSS */
+ };
+ };
+
+ usart2_pins_b: usart2-1 {
+ pins1 {
+ pinmux = <STM32_PINMUX('F', 5, AF7)>, /* USART2_TX */
+ <STM32_PINMUX('A', 1, AF7)>; /* USART2_RTS */
+ bias-disable;
+ drive-push-pull;
+ slew-rate = <0>;
+ };
+ pins2 {
+ pinmux = <STM32_PINMUX('F', 4, AF7)>, /* USART2_RX */
+ <STM32_PINMUX('E', 15, AF7)>; /* USART2_CTS_NSS */
+ bias-disable;
+ };
+ };
+
+ usart2_sleep_pins_b: usart2-sleep-1 {
+ pins {
+ pinmux = <STM32_PINMUX('F', 5, ANALOG)>, /* USART2_TX */
+ <STM32_PINMUX('A', 1, ANALOG)>, /* USART2_RTS */
+ <STM32_PINMUX('F', 4, ANALOG)>, /* USART2_RX */
+ <STM32_PINMUX('E', 15, ANALOG)>; /* USART2_CTS_NSS */
+ };
+ };
+
+ usart3_pins_a: usart3-0 {
+ pins1 {
+ pinmux = <STM32_PINMUX('B', 10, AF7)>; /* USART3_TX */
+ bias-disable;
+ drive-push-pull;
+ slew-rate = <0>;
+ };
+ pins2 {
+ pinmux = <STM32_PINMUX('B', 12, AF8)>; /* USART3_RX */
+ bias-disable;
+ };
+ };
+
usbotg_hs_pins_a: usbotg-hs-0 {
pins {
pinmux = <STM32_PINMUX('A', 10, ANALOG)>; /* OTG_ID */
--
2.17.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH 2/2] ARM: dts: stm32: fix uart7_pins_a comments in stm32mp15-pinctrl
From: Erwan Le Ray @ 2020-05-28 7:40 UTC (permalink / raw)
To: Maxime Coquelin, Alexandre Torgue, Rob Herring, Mark Rutland
Cc: devicetree, linux-kernel, linux-arm-kernel, Fabrice Gasnier,
linux-stm32, Erwan Le Ray
In-Reply-To: <20200528074003.24875-1-erwan.leray@st.com>
Fix uart7_pins_a comments to indicate UART7 pins instead of UART4 pins.
Fixes: bf4b5f379fed ("ARM: dts: stm32: Add missing pinctrl definitions for STM32MP157")
Signed-off-by: Erwan Le Ray <erwan.leray@st.com>
diff --git a/arch/arm/boot/dts/stm32mp15-pinctrl.dtsi b/arch/arm/boot/dts/stm32mp15-pinctrl.dtsi
index 5ff1323236e1..fb98a66977fe 100644
--- a/arch/arm/boot/dts/stm32mp15-pinctrl.dtsi
+++ b/arch/arm/boot/dts/stm32mp15-pinctrl.dtsi
@@ -1632,15 +1632,15 @@
uart7_pins_a: uart7-0 {
pins1 {
- pinmux = <STM32_PINMUX('E', 8, AF7)>; /* UART4_TX */
+ pinmux = <STM32_PINMUX('E', 8, AF7)>; /* UART7_TX */
bias-disable;
drive-push-pull;
slew-rate = <0>;
};
pins2 {
- pinmux = <STM32_PINMUX('E', 7, AF7)>, /* UART4_RX */
- <STM32_PINMUX('E', 10, AF7)>, /* UART4_CTS */
- <STM32_PINMUX('E', 9, AF7)>; /* UART4_RTS */
+ pinmux = <STM32_PINMUX('E', 7, AF7)>, /* UART7_RX */
+ <STM32_PINMUX('E', 10, AF7)>, /* UART7_CTS */
+ <STM32_PINMUX('E', 9, AF7)>; /* UART7_RTS */
bias-disable;
};
};
--
2.17.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH 0/5] STM32 add usart nodes support
From: Erwan Le Ray @ 2020-05-28 7:40 UTC (permalink / raw)
To: Maxime Coquelin, Alexandre Torgue, Rob Herring, Mark Rutland
Cc: devicetree, linux-kernel, linux-arm-kernel, Fabrice Gasnier,
linux-stm32, Erwan Le Ray
Add the support of uart instances available on STM32MP157 boards:
- usart3 on stm32mp157c-ev1, stm32mp157a-dk1, and stm32mp157c-dk2
- uart7 on stm32mp157a-dk1 and stm32mp157c-dk2
- usart2 on stm32mp157c-dk2
The aliases are following this order.
Erwan Le Ray (5):
ARM: dts: stm32: add usart2, usart3 and uart7 pins in
stm32mp15-pinctrl
ARM: dts: stm32: add usart3 node to stm32mp15xx-dkx boards
ARM: dts: stm32: add usart3 node to stm32mp157c-ev1
ARM: dts: stm32: add uart7 support to stm32mp15xx-dkx boards
ARM: dts: stm32: add usart2 node to stm32mp157c-dk2
arch/arm/boot/dts/stm32mp15-pinctrl.dtsi | 138 +++++++++++++++++++++++
arch/arm/boot/dts/stm32mp157a-dk1.dts | 2 +
arch/arm/boot/dts/stm32mp157c-dk2.dts | 11 ++
arch/arm/boot/dts/stm32mp157c-ev1.dts | 10 ++
arch/arm/boot/dts/stm32mp15xx-dkx.dtsi | 17 +++
5 files changed, 178 insertions(+)
--
2.17.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH 3/5] ARM: dts: stm32: add usart3 node to stm32mp157c-ev1
From: Erwan Le Ray @ 2020-05-28 7:40 UTC (permalink / raw)
To: Maxime Coquelin, Alexandre Torgue, Rob Herring, Mark Rutland
Cc: devicetree, linux-kernel, linux-arm-kernel, Fabrice Gasnier,
linux-stm32, Erwan Le Ray
In-Reply-To: <20200528074029.24962-1-erwan.leray@st.com>
Adds the usart3 node to stm32mp157c-ev1 board. usart3 pins are connected to
GPIO Expansion connector. usart3 is disabled by default.
Signed-off-by: Erwan Le Ray <erwan.leray@st.com>
diff --git a/arch/arm/boot/dts/stm32mp157c-ev1.dts b/arch/arm/boot/dts/stm32mp157c-ev1.dts
index b19056557ef0..e56dde8d20f8 100644
--- a/arch/arm/boot/dts/stm32mp157c-ev1.dts
+++ b/arch/arm/boot/dts/stm32mp157c-ev1.dts
@@ -19,6 +19,7 @@
aliases {
serial0 = &uart4;
+ serial1 = &usart3;
ethernet0 = ðernet0;
};
@@ -341,6 +342,15 @@
};
};
+&usart3 {
+ pinctrl-names = "default", "sleep", "idle";
+ pinctrl-0 = <&usart3_pins_b>;
+ pinctrl-1 = <&usart3_sleep_pins_b>;
+ pinctrl-2 = <&usart3_idle_pins_b>;
+ uart-has-rtscts;
+ status = "disabled";
+};
+
&usbh_ehci {
phys = <&usbphyc_port0>;
status = "okay";
--
2.17.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH 2/5] ARM: dts: stm32: add usart3 node to stm32mp15xx-dkx boards
From: Erwan Le Ray @ 2020-05-28 7:40 UTC (permalink / raw)
To: Maxime Coquelin, Alexandre Torgue, Rob Herring, Mark Rutland
Cc: devicetree, linux-kernel, linux-arm-kernel, Fabrice Gasnier,
linux-stm32, Erwan Le Ray
In-Reply-To: <20200528074029.24962-1-erwan.leray@st.com>
Adds usart3 node to stm32mp15xx-dkx and usart3 alias to stm32mp157a-dk1
and stm32mp157c-dk2 boards. usart3 pins are connected to GPIO Expansion
connector. usart3 is disabled by default.
Signed-off-by: Erwan Le Ray <erwan.leray@st.com>
diff --git a/arch/arm/boot/dts/stm32mp157a-dk1.dts b/arch/arm/boot/dts/stm32mp157a-dk1.dts
index d03d4cd2606a..65ee61b7667a 100644
--- a/arch/arm/boot/dts/stm32mp157a-dk1.dts
+++ b/arch/arm/boot/dts/stm32mp157a-dk1.dts
@@ -18,6 +18,7 @@
aliases {
ethernet0 = ðernet0;
serial0 = &uart4;
+ serial1 = &usart3;
};
chosen {
diff --git a/arch/arm/boot/dts/stm32mp157c-dk2.dts b/arch/arm/boot/dts/stm32mp157c-dk2.dts
index 9a8a26710ac1..fb690a817e28 100644
--- a/arch/arm/boot/dts/stm32mp157c-dk2.dts
+++ b/arch/arm/boot/dts/stm32mp157c-dk2.dts
@@ -19,6 +19,7 @@
aliases {
ethernet0 = ðernet0;
serial0 = &uart4;
+ serial1 = &usart3;
};
chosen {
diff --git a/arch/arm/boot/dts/stm32mp15xx-dkx.dtsi b/arch/arm/boot/dts/stm32mp15xx-dkx.dtsi
index e5fdbc149bf4..243aa4b2063d 100644
--- a/arch/arm/boot/dts/stm32mp15xx-dkx.dtsi
+++ b/arch/arm/boot/dts/stm32mp15xx-dkx.dtsi
@@ -591,6 +591,15 @@
status = "okay";
};
+&usart3 {
+ pinctrl-names = "default", "sleep", "idle";
+ pinctrl-0 = <&usart3_pins_c>;
+ pinctrl-1 = <&usart3_sleep_pins_c>;
+ pinctrl-2 = <&usart3_idle_pins_c>;
+ uart-has-rtscts;
+ status = "disabled";
+};
+
&usbh_ehci {
phys = <&usbphyc_port0>;
status = "okay";
--
2.17.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH 1/5] ARM: dts: stm32: add usart2, usart3 and uart7 pins in stm32mp15-pinctrl
From: Erwan Le Ray @ 2020-05-28 7:40 UTC (permalink / raw)
To: Maxime Coquelin, Alexandre Torgue, Rob Herring, Mark Rutland
Cc: devicetree, linux-kernel, linux-arm-kernel, Fabrice Gasnier,
linux-stm32, Erwan Le Ray
In-Reply-To: <20200528074029.24962-1-erwan.leray@st.com>
Adds usart2_pins_c, usart3_pins_b, usart3_pins_c and uart7_pins_c pins
configurations in stm32mp15-pinctrl.
- usart2_pins_c pins are connected to Bluetooth chip on dk2 board.
- usart3_pins_b pins are connected to GPIO expansion connector on evx board.
- usart3_pins_c pins are connected to GPIO expansion connector on dkx board.
- uart7_pins_c pins are connected to Arduino Uno connector on dkx board.
Signed-off-by: Erwan Le Ray <erwan.leray@st.com>
diff --git a/arch/arm/boot/dts/stm32mp15-pinctrl.dtsi b/arch/arm/boot/dts/stm32mp15-pinctrl.dtsi
index fb98a66977fe..99e399e4e4c3 100644
--- a/arch/arm/boot/dts/stm32mp15-pinctrl.dtsi
+++ b/arch/arm/boot/dts/stm32mp15-pinctrl.dtsi
@@ -1658,6 +1658,36 @@
};
};
+ uart7_pins_c: uart7-1 {
+ pins1 {
+ pinmux = <STM32_PINMUX('E', 8, AF7)>; /* USART7_TX */
+ bias-disable;
+ drive-push-pull;
+ slew-rate = <0>;
+ };
+ pins2 {
+ pinmux = <STM32_PINMUX('E', 7, AF7)>; /* USART7_RX */
+ bias-disable;
+ };
+ };
+
+ uart7_idle_pins_c: uart7-idle-1 {
+ pins1 {
+ pinmux = <STM32_PINMUX('E', 8, ANALOG)>; /* USART7_TX */
+ };
+ pins2 {
+ pinmux = <STM32_PINMUX('E', 7, AF7)>; /* USART7_RX */
+ bias-disable;
+ };
+ };
+
+ uart7_sleep_pins_c: uart7-sleep-1 {
+ pins {
+ pinmux = <STM32_PINMUX('E', 8, ANALOG)>, /* USART7_TX */
+ <STM32_PINMUX('E', 7, ANALOG)>; /* USART7_RX */
+ };
+ };
+
uart8_pins_a: uart8-0 {
pins1 {
pinmux = <STM32_PINMUX('E', 1, AF8)>; /* UART8_TX */
@@ -1719,6 +1749,42 @@
};
};
+ usart2_pins_c: usart2-0 {
+ pins1 {
+ pinmux = <STM32_PINMUX('D', 5, AF7)>, /* USART2_TX */
+ <STM32_PINMUX('D', 4, AF7)>; /* USART2_RTS */
+ bias-disable;
+ drive-push-pull;
+ slew-rate = <3>;
+ };
+ pins2 {
+ pinmux = <STM32_PINMUX('D', 6, AF7)>, /* USART2_RX */
+ <STM32_PINMUX('D', 3, AF7)>; /* USART2_CTS_NSS */
+ bias-disable;
+ };
+ };
+
+ usart2_idle_pins_c: usart2-idle-0 {
+ pins1 {
+ pinmux = <STM32_PINMUX('D', 5, ANALOG)>, /* USART2_TX */
+ <STM32_PINMUX('D', 4, ANALOG)>, /* USART2_RTS */
+ <STM32_PINMUX('D', 3, ANALOG)>; /* USART2_CTS_NSS */
+ };
+ pins2 {
+ pinmux = <STM32_PINMUX('D', 6, AF7)>; /* USART2_RX */
+ bias-disable;
+ };
+ };
+
+ usart2_sleep_pins_c: usart2-sleep-0 {
+ pins {
+ pinmux = <STM32_PINMUX('D', 5, ANALOG)>, /* USART2_TX */
+ <STM32_PINMUX('D', 4, ANALOG)>, /* USART2_RTS */
+ <STM32_PINMUX('D', 6, ANALOG)>, /* USART2_RX */
+ <STM32_PINMUX('D', 3, ANALOG)>; /* USART2_CTS_NSS */
+ };
+ };
+
usart3_pins_a: usart3-0 {
pins1 {
pinmux = <STM32_PINMUX('B', 10, AF7)>; /* USART3_TX */
@@ -1732,6 +1798,78 @@
};
};
+ usart3_pins_b: usart3-0 {
+ pins1 {
+ pinmux = <STM32_PINMUX('B', 10, AF7)>, /* USART3_TX */
+ <STM32_PINMUX('G', 8, AF8)>; /* USART3_RTS */
+ bias-disable;
+ drive-push-pull;
+ slew-rate = <0>;
+ };
+ pins2 {
+ pinmux = <STM32_PINMUX('B', 12, AF8)>, /* USART3_RX */
+ <STM32_PINMUX('I', 10, AF8)>; /* USART3_CTS_NSS */
+ bias-disable;
+ };
+ };
+
+ usart3_idle_pins_b: usart3-idle-0 {
+ pins1 {
+ pinmux = <STM32_PINMUX('B', 10, ANALOG)>, /* USART3_TX */
+ <STM32_PINMUX('G', 8, ANALOG)>, /* USART3_RTS */
+ <STM32_PINMUX('I', 10, ANALOG)>; /* USART3_CTS_NSS */
+ };
+ pins2 {
+ pinmux = <STM32_PINMUX('B', 12, AF8)>; /* USART3_RX */
+ bias-disable;
+ };
+ };
+
+ usart3_sleep_pins_b: usart3-sleep-0 {
+ pins {
+ pinmux = <STM32_PINMUX('B', 10, ANALOG)>, /* USART3_TX */
+ <STM32_PINMUX('G', 8, ANALOG)>, /* USART3_RTS */
+ <STM32_PINMUX('I', 10, ANALOG)>, /* USART3_CTS_NSS */
+ <STM32_PINMUX('B', 12, ANALOG)>; /* USART3_RX */
+ };
+ };
+
+ usart3_pins_c: usart3-1 {
+ pins1 {
+ pinmux = <STM32_PINMUX('B', 10, AF7)>, /* USART3_TX */
+ <STM32_PINMUX('G', 8, AF8)>; /* USART3_RTS */
+ bias-disable;
+ drive-push-pull;
+ slew-rate = <0>;
+ };
+ pins2 {
+ pinmux = <STM32_PINMUX('B', 12, AF8)>, /* USART3_RX */
+ <STM32_PINMUX('B', 13, AF7)>; /* USART3_CTS_NSS */
+ bias-disable;
+ };
+ };
+
+ usart3_idle_pins_c: usart3-idle-1 {
+ pins1 {
+ pinmux = <STM32_PINMUX('B', 10, ANALOG)>, /* USART3_TX */
+ <STM32_PINMUX('G', 8, ANALOG)>, /* USART3_RTS */
+ <STM32_PINMUX('B', 13, ANALOG)>; /* USART3_CTS_NSS */
+ };
+ pins2 {
+ pinmux = <STM32_PINMUX('B', 12, AF8)>; /* USART3_RX */
+ bias-disable;
+ };
+ };
+
+ usart3_sleep_pins_c: usart3-sleep-1 {
+ pins {
+ pinmux = <STM32_PINMUX('B', 10, ANALOG)>, /* USART3_TX */
+ <STM32_PINMUX('G', 8, ANALOG)>, /* USART3_RTS */
+ <STM32_PINMUX('B', 13, ANALOG)>, /* USART3_CTS_NSS */
+ <STM32_PINMUX('B', 12, ANALOG)>; /* USART3_RX */
+ };
+ };
+
usbotg_hs_pins_a: usbotg-hs-0 {
pins {
pinmux = <STM32_PINMUX('A', 10, ANALOG)>; /* OTG_ID */
--
2.17.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH 5/5] ARM: dts: stm32: add usart2 node to stm32mp157c-dk2
From: Erwan Le Ray @ 2020-05-28 7:40 UTC (permalink / raw)
To: Maxime Coquelin, Alexandre Torgue, Rob Herring, Mark Rutland
Cc: devicetree, linux-kernel, linux-arm-kernel, Fabrice Gasnier,
linux-stm32, Erwan Le Ray
In-Reply-To: <20200528074029.24962-1-erwan.leray@st.com>
Adds the usart2 node to stm32mp157c-dk2 board. usart2 pins are connected
to Bluetooth component. usart2 is disabled by default.
Signed-off-by: Erwan Le Ray <erwan.leray@st.com>
diff --git a/arch/arm/boot/dts/stm32mp157c-dk2.dts b/arch/arm/boot/dts/stm32mp157c-dk2.dts
index ffbae4a8753d..045636555ddd 100644
--- a/arch/arm/boot/dts/stm32mp157c-dk2.dts
+++ b/arch/arm/boot/dts/stm32mp157c-dk2.dts
@@ -21,6 +21,7 @@
serial0 = &uart4;
serial1 = &usart3;
serial2 = &uart7;
+ serial3 = &usart2;
};
chosen {
@@ -86,3 +87,11 @@
};
};
};
+
+&usart2 {
+ pinctrl-names = "default", "sleep", "idle";
+ pinctrl-0 = <&usart2_pins_c>;
+ pinctrl-1 = <&usart2_sleep_pins_c>;
+ pinctrl-2 = <&usart2_idle_pins_c>;
+ status = "disabled";
+};
--
2.17.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH 4/5] ARM: dts: stm32: add uart7 support to stm32mp15xx-dkx boards
From: Erwan Le Ray @ 2020-05-28 7:40 UTC (permalink / raw)
To: Maxime Coquelin, Alexandre Torgue, Rob Herring, Mark Rutland
Cc: devicetree, linux-kernel, linux-arm-kernel, Fabrice Gasnier,
linux-stm32, Erwan Le Ray
In-Reply-To: <20200528074029.24962-1-erwan.leray@st.com>
Adds uart7 node to stm32mp15xx-dkx and uart7 alias to stm32mp157a-dk1 and
stm32mp157c-dk2 boards. uart7 pins are connected to Arduino connector.
uart7 is disabled by default.
Signed-off-by: Erwan Le Ray <erwan.leray@st.com>
diff --git a/arch/arm/boot/dts/stm32mp157a-dk1.dts b/arch/arm/boot/dts/stm32mp157a-dk1.dts
index 65ee61b7667a..4c8be9c8eb20 100644
--- a/arch/arm/boot/dts/stm32mp157a-dk1.dts
+++ b/arch/arm/boot/dts/stm32mp157a-dk1.dts
@@ -19,6 +19,7 @@
ethernet0 = ðernet0;
serial0 = &uart4;
serial1 = &usart3;
+ serial2 = &uart7;
};
chosen {
diff --git a/arch/arm/boot/dts/stm32mp157c-dk2.dts b/arch/arm/boot/dts/stm32mp157c-dk2.dts
index fb690a817e28..ffbae4a8753d 100644
--- a/arch/arm/boot/dts/stm32mp157c-dk2.dts
+++ b/arch/arm/boot/dts/stm32mp157c-dk2.dts
@@ -20,6 +20,7 @@
ethernet0 = ðernet0;
serial0 = &uart4;
serial1 = &usart3;
+ serial2 = &uart7;
};
chosen {
diff --git a/arch/arm/boot/dts/stm32mp15xx-dkx.dtsi b/arch/arm/boot/dts/stm32mp15xx-dkx.dtsi
index 243aa4b2063d..cfbe3e2afef2 100644
--- a/arch/arm/boot/dts/stm32mp15xx-dkx.dtsi
+++ b/arch/arm/boot/dts/stm32mp15xx-dkx.dtsi
@@ -591,6 +591,14 @@
status = "okay";
};
+&uart7 {
+ pinctrl-names = "default", "sleep", "idle";
+ pinctrl-0 = <&uart7_pins_c>;
+ pinctrl-1 = <&uart7_sleep_pins_c>;
+ pinctrl-2 = <&uart7_idle_pins_c>;
+ status = "disabled";
+};
+
&usart3 {
pinctrl-names = "default", "sleep", "idle";
pinctrl-0 = <&usart3_pins_c>;
--
2.17.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* Re: [RFC PATCH] iommu/arm-smmu: Add module parameter to set msi iova address
From: Auger Eric @ 2020-05-28 7:43 UTC (permalink / raw)
To: Jean-Philippe Brucker, Srinath Mannam
Cc: Will Deacon, Joerg Roedel, iommu, Linux Kernel Mailing List,
Alex Williamson, BCM Kernel Feedback, Robin Murphy, Linux ARM
In-Reply-To: <20200528072308.GA414784@myrica>
Hi,
On 5/28/20 9:23 AM, Jean-Philippe Brucker wrote:
> On Thu, May 28, 2020 at 10:45:14AM +0530, Srinath Mannam wrote:
>> On Wed, May 27, 2020 at 11:00 PM Robin Murphy <robin.murphy@arm.com> wrote:
>>>
>> Thanks Robin for your quick response.
>>> On 2020-05-27 17:03, Srinath Mannam wrote:
>>>> This patch gives the provision to change default value of MSI IOVA base
>>>> to platform's suitable IOVA using module parameter. The present
>>>> hardcoded MSI IOVA base may not be the accessible IOVA ranges of platform.
>>>
>>> That in itself doesn't seem entirely unreasonable; IIRC the current
>>> address is just an arbitrary choice to fit nicely into Qemu's memory
>>> map, and there was always the possibility that it wouldn't suit everything.
>>>
>>>> Since commit aadad097cd46 ("iommu/dma: Reserve IOVA for PCIe inaccessible
>>>> DMA address"), inaccessible IOVA address ranges parsed from dma-ranges
>>>> property are reserved.
>
> I don't understand why we only reserve the PCIe windows for DMA domains.
> Shouldn't VFIO also prevent userspace from mapping them?
VFIO prevents userspace from DMA mapping iovas within reserved regions:
9b77e5c79840 vfio/type1: check dma map request is within a valid iova range
but it does not prevent the SW MSI region chosen by the kernel from
colliding with other reserved regions (esp. PCIe host bridge windows).
If they were
> part of the common reserved regions then we could have VFIO choose a
> SW_MSI region among the remaining free space.
As Robin said this was the initial chosen approach
[PATCH 10/10] vfio: allow the user to register reserved iova range for
MSI mapping
https://patchwork.kernel.org/patch/8121641/
Some additional background about why the static SW MSI region chosen by
the kernel was later chosen:
Summary of LPC guest MSI discussion in Santa Fe (was: Re: [RFC 0/8] KVM
PCIe/MSI passthrough on ARM/ARM64 (Alt II))
https://lists.linuxfoundation.org/pipermail/iommu/2016-November/019060.html
Thanks
Eric
It would just need a
> different way of asking the IOMMU driver if a SW_MSI is needed, for
> example with a domain attribute.
>
> Thanks,
> Jean
>
>>>
>>> That, however, doesn't seem to fit here; iommu-dma maps MSI doorbells
>>> dynamically, so they aren't affected by reserved regions any more than
>>> regular DMA pages are. In fact, it explicitly ignores the software MSI
>>> region, since as the comment says, it *is* the software that manages those.
>> Yes you are right, we don't see any issues with kernel drivers(PCI EP) because
>> MSI IOVA allocated dynamically by honouring reserved regions same as DMA pages.
>>>
>>> The MSI_IOVA_BASE region exists for VFIO, precisely because in that case
>>> the kernel *doesn't* control the address space, but still needs some way
>>> to steal a bit of it for MSIs that the guest doesn't necessarily know
>>> about, and give userspace a fighting chance of knowing what it's taken.
>>> I think at the time we discussed the idea of adding something to the
>>> VFIO uapi such that userspace could move this around if it wanted or
>>> needed to, but decided we could live without that initially. Perhaps now
>>> the time has come?
>> Yes, we see issues only with user-space drivers(DPDK) in which MSI_IOVA_BASE
>> region is considered to map MSI registers. This patch helps us to fix the issue.
>>
>> Thanks,
>> Srinath.
>>>
>>> Robin.
>>>
>>>> If any platform has the limitaion to access default MSI IOVA, then it can
>>>> be changed using "arm-smmu.msi_iova_base=0xa0000000" command line argument.
>>>>
>>>> Signed-off-by: Srinath Mannam <srinath.mannam@broadcom.com>
>>>> ---
>>>> drivers/iommu/arm-smmu.c | 5 ++++-
>>>> 1 file changed, 4 insertions(+), 1 deletion(-)
>>>>
>>>> diff --git a/drivers/iommu/arm-smmu.c b/drivers/iommu/arm-smmu.c
>>>> index 4f1a350..5e59c9d 100644
>>>> --- a/drivers/iommu/arm-smmu.c
>>>> +++ b/drivers/iommu/arm-smmu.c
>>>> @@ -72,6 +72,9 @@ static bool disable_bypass =
>>>> module_param(disable_bypass, bool, S_IRUGO);
>>>> MODULE_PARM_DESC(disable_bypass,
>>>> "Disable bypass streams such that incoming transactions from devices that are not attached to an iommu domain will report an abort back to the device and will not be allowed to pass through the SMMU.");
>>>> +static unsigned long msi_iova_base = MSI_IOVA_BASE;
>>>> +module_param(msi_iova_base, ulong, S_IRUGO);
>>>> +MODULE_PARM_DESC(msi_iova_base, "msi iova base address.");
>>>>
>>>> struct arm_smmu_s2cr {
>>>> struct iommu_group *group;
>>>> @@ -1566,7 +1569,7 @@ static void arm_smmu_get_resv_regions(struct device *dev,
>>>> struct iommu_resv_region *region;
>>>> int prot = IOMMU_WRITE | IOMMU_NOEXEC | IOMMU_MMIO;
>>>>
>>>> - region = iommu_alloc_resv_region(MSI_IOVA_BASE, MSI_IOVA_LENGTH,
>>>> + region = iommu_alloc_resv_region(msi_iova_base, MSI_IOVA_LENGTH,
>>>> prot, IOMMU_RESV_SW_MSI);
>>>> if (!region)
>>>> return;
>>>>
>
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH] mt76: mt7615: Use kmemdup in mt7615_queue_key_update()
From: YueHaibing @ 2020-05-28 7:48 UTC (permalink / raw)
To: Felix Fietkau, Lorenzo Bianconi, Ryder Lee, Kalle Valo,
Jakub Kicinski, Matthias Brugger, Sean Wang
Cc: YueHaibing, kernel-janitors, linux-wireless, linux-mediatek,
netdev, linux-arm-kernel
Use kmemdup rather than duplicating its implementation
Signed-off-by: YueHaibing <yuehaibing@huawei.com>
---
drivers/net/wireless/mediatek/mt76/mt7615/main.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/net/wireless/mediatek/mt76/mt7615/main.c b/drivers/net/wireless/mediatek/mt76/mt7615/main.c
index 2e9e9d3519d7..c32f06c85f0f 100644
--- a/drivers/net/wireless/mediatek/mt76/mt7615/main.c
+++ b/drivers/net/wireless/mediatek/mt76/mt7615/main.c
@@ -289,12 +289,11 @@ mt7615_queue_key_update(struct mt7615_dev *dev, enum set_key_cmd cmd,
wd->type = MT7615_WTBL_KEY_DESC;
wd->sta = msta;
- wd->key.key = kzalloc(key->keylen, GFP_KERNEL);
+ wd->key.key = kmemdup(key->key, key->keylen, GFP_KERNEL);
if (!wd->key.key) {
kfree(wd);
return -ENOMEM;
}
- memcpy(wd->key.key, key->key, key->keylen);
wd->key.cipher = key->cipher;
wd->key.keyidx = key->keyidx;
wd->key.keylen = key->keylen;
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* Re: [PATCH V3] arm64/cpufeature: Add get_arm64_ftr_reg_nowarn()
From: Anshuman Khandual @ 2020-05-28 7:46 UTC (permalink / raw)
To: Will Deacon, linux-arm-kernel
Cc: mark.rutland, catalin.marinas, Mark Brown, linux-kernel,
suzuki.poulose
In-Reply-To: <159057996975.77588.7036217455816555869.b4-ty@kernel.org>
On 05/27/2020 05:55 PM, Will Deacon wrote:
> On Wed, 27 May 2020 15:34:36 +0530, Anshuman Khandual wrote:
>> There is no way to proceed when requested register could not be searched in
>> arm64_ftr_reg[]. Requesting for a non present register would be an error as
>> well. Hence lets just WARN_ON() when search fails in get_arm64_ftr_reg()
>> rather than checking for return value and doing a BUG_ON() instead in some
>> individual callers. But there are also caller instances that dont error out
>> when register search fails. Add a new helper get_arm64_ftr_reg_nowarn() for
>> such cases.
>
> Applied to arm64 (for-next/cpufeature), thanks!
>
> [1/1] arm64/cpufeature: Add get_arm64_ftr_reg_nowarn()
> https://git.kernel.org/arm64/c/3577dd37c703
Thanks Will, for changing the comment per Catalin.
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH 09/12] devfreq: add mediatek cci devfreq
From: Chanwoo Choi @ 2020-05-28 8:00 UTC (permalink / raw)
To: Andrew-sh.Cheng, MyungJoo Ham, Kyungmin Park, Rob Herring,
Mark Rutland, Matthias Brugger, Rafael J . Wysocki, Viresh Kumar,
Nishanth Menon, Stephen Boyd, Liam Girdwood, Mark Brown
Cc: devicetree, srv_heupstream, linux-pm, linux-kernel,
linux-mediatek, linux-arm-kernel
In-Reply-To: <c39e4f30-805a-78c4-b1c4-e55a03e2408e@samsung.com>
Hi Andrew-sh.Cheng,
On 5/28/20 4:35 PM, Chanwoo Choi wrote:
> Hi Andrew-sh.Cheng,
>
> On 5/20/20 12:43 PM, Andrew-sh.Cheng wrote:
>> This adds a devfreq driver for the Cache Coherent Interconnect (CCI)
>> of the Mediatek MT8183.
>>
>> On the MT8183 the CCI is supplied by the same regulator as the LITTLE
>> cores. The driver is notified when the regulator voltage changes
>> (driven by cpufreq) and adjusts the CCI frequency to the maximum
>> possible value.
I understood that the mt8183-cci.c and mt8183 cpufreq driver (ARM_MEDIATEK_CPUFREQ)
shared the same regulator. So, when mt8183 cpufreq driver
changes the CPU frequency and voltage, the mt8183-cci.c
changes the CCI frequency according to the new mt8183 frequency
with passive governor.
I think that mt8183-cci.c don't need to change the voltage
because already mt8183 cpufreq changed the voltage of shared regulator.
Why do you change the voltage in this driver?
>>
>> Signed-off-by: Andrew-sh.Cheng <andrew-sh.cheng@mediatek.com>
>> ---
>> drivers/devfreq/Kconfig | 10 ++
>> drivers/devfreq/Makefile | 1 +
>> drivers/devfreq/mt8183-cci-devfreq.c | 206 +++++++++++++++++++++++++++++++++++
>
> The mt8183-cci.c is enough for driver name.
>
>> 3 files changed, 217 insertions(+)
>> create mode 100644 drivers/devfreq/mt8183-cci-devfreq.c
>>
>> diff --git a/drivers/devfreq/Kconfig b/drivers/devfreq/Kconfig
>> index d9067950af6a..4ed7116271ee 100644
>> --- a/drivers/devfreq/Kconfig
>> +++ b/drivers/devfreq/Kconfig
>> @@ -103,6 +103,16 @@ config ARM_IMX8M_DDRC_DEVFREQ
>> This adds the DEVFREQ driver for the i.MX8M DDR Controller. It allows
>> adjusting DRAM frequency.
>>
>> +config ARM_MT8183_CCI_DEVFREQ
>> + tristate "MT8183 CCI DEVFREQ Driver"
>> + depends on ARM_MEDIATEK_CPUFREQ
>> + help
>> + This adds a devfreq driver for Cache Coherent Interconnect
>> + of Mediatek MT8183, which is shared the same regulator
>> + with cpu cluster.
>> + It can track buck voltage and update a proper cci frequency.
>
> s/cci/CCI
>
>> + Use notification to get regulator status.
>> +
>> config ARM_TEGRA_DEVFREQ
>> tristate "NVIDIA Tegra30/114/124/210 DEVFREQ Driver"
>> depends on ARCH_TEGRA_3x_SOC || ARCH_TEGRA_114_SOC || \
>> diff --git a/drivers/devfreq/Makefile b/drivers/devfreq/Makefile
>> index 3eb4d5e6635c..5b1b670c954d 100644
>> --- a/drivers/devfreq/Makefile
>> +++ b/drivers/devfreq/Makefile
>> @@ -10,6 +10,7 @@ obj-$(CONFIG_DEVFREQ_GOV_PASSIVE) += governor_passive.o
>> # DEVFREQ Drivers
>> obj-$(CONFIG_ARM_EXYNOS_BUS_DEVFREQ) += exynos-bus.o
>> obj-$(CONFIG_ARM_IMX8M_DDRC_DEVFREQ) += imx8m-ddrc.o
>> +obj-$(CONFIG_ARM_MT8183_CCI_DEVFREQ) += mt8183-cci-devfreq.o
>> obj-$(CONFIG_ARM_RK3399_DMC_DEVFREQ) += rk3399_dmc.o
>> obj-$(CONFIG_ARM_TEGRA_DEVFREQ) += tegra30-devfreq.o
>> obj-$(CONFIG_ARM_TEGRA20_DEVFREQ) += tegra20-devfreq.o
>> diff --git a/drivers/devfreq/mt8183-cci-devfreq.c b/drivers/devfreq/mt8183-cci-devfreq.c
>> new file mode 100644
>> index 000000000000..cd7929a83bf8
>> --- /dev/null
>> +++ b/drivers/devfreq/mt8183-cci-devfreq.c
>> @@ -0,0 +1,206 @@
>> +// SPDX-License-Identifier: GPL-2.0
>> +/*
>> + * Copyright (c) 2019 MediaTek Inc.
>
> s/2019/2020
>
>> +
>> + * Author: Andrew-sh.Cheng <andrew-sh.cheng@mediatek.com>
>> + */
>> +
>> +#include <linux/clk.h>
>> +#include <linux/devfreq.h>
>> +#include <linux/module.h>
>> +#include <linux/of.h>
>> +#include <linux/platform_device.h>
>> +#include <linux/regulator/consumer.h>
>> +#include <linux/time.h>
>> +
>> +#include "governor.h"
>
> It is not needed. Please remove it.
>
>> +
>> +#define MAX_VOLT_LIMIT (1150000)
>> +
>> +struct cci_devfreq {
>> + struct devfreq *devfreq;
>> + struct regulator *proc_reg;
>
> 'proc' means the 'processor'?
> Instead of 'proc_reg', you better to use 'cpu_reg'.
>
>> + struct clk *cci_clk;
>> + int old_vproc;
>> + unsigned long old_freq;
>> +};
>> +
>> +static int mtk_cci_set_voltage(struct cci_devfreq *cci_df, int vproc)
>> +{
>> + int ret;
>> +
>> + ret = regulator_set_voltage(cci_df->proc_reg, vproc,
>> + MAX_VOLT_LIMIT);
>> + if (!ret)
>> + cci_df->old_vproc = vproc;
>> + return ret;
>> +}
>> +
>> +static int mtk_cci_devfreq_target(struct device *dev, unsigned long *freq,
>> + u32 flags)
>> +{
>> + int ret;
>> + struct cci_devfreq *cci_df = dev_get_drvdata(dev);
>> + struct dev_pm_opp *opp;
>> + unsigned long opp_rate, opp_voltage, old_voltage;
>> +
>> + if (!cci_df)
>> + return -EINVAL;
>> +
>> + if (cci_df->old_freq == *freq)
>> + return 0;
>> +
>> + opp_rate = *freq;
>> + opp = dev_pm_opp_find_freq_floor(dev, &opp_rate);
>> + opp_voltage = dev_pm_opp_get_voltage(opp);
>> + dev_pm_opp_put(opp);
>
>
> You can use the helper function for getting the rate
> with devfreq_recommended_opp(). You can refer the following code
> in drivers/devfreq/exynos-bus.c
>
> opp = devfreq_recommended_opp(dev, freq, flags);
> if (IS_ERR(opp)) {
> dev_err(dev, "failed to get recommended opp instance\n");
> return PTR_ERR(opp);
> }
> dev_pm_opp_put(opp);
>
>> +
>> + old_voltage = cci_df->old_vproc;
>> + if (old_voltage == 0)
>> + old_voltage = regulator_get_voltage(cci_df->proc_reg);
>> +
>> + // scale up: set voltage first then freq
>> + if (opp_voltage > old_voltage) {
>> + ret = mtk_cci_set_voltage(cci_df, opp_voltage);
>> + if (ret) {
>> + pr_err("cci: failed to scale up voltage\n");
>> + return ret;
>> + }
>> + }
>> +
>> + ret = clk_set_rate(cci_df->cci_clk, *freq);
>> + if (ret) {
>> + pr_err("%s: failed cci to set rate: %d\n", __func__,
>> + ret);
>> + mtk_cci_set_voltage(cci_df, old_voltage);
>> + return ret;
>> + }
>> +
>> + // scale down: set freq first then voltage
>> + if (opp_voltage < old_voltage) {
>> + ret = mtk_cci_set_voltage(cci_df, opp_voltage);
>> + if (ret) {
>> + pr_err("cci: failed to scale down voltage\n");
>> + clk_set_rate(cci_df->cci_clk, cci_df->old_freq);
>> + return ret;
>> + }
>> + }
>
>
> I recommend that dev_pm_opp_set_rate() and dev_pm_opp_set_regulator()
> instead of 'clk_set_rate' and 'regulator_set_voltage'.
> In the dev_pm_opp_set_rate(), handle the these sequence.
> You can refer the merged patch[1].
>
> [1] commit 4294a779bd8dff6c65e7e85ffe7a1ea236e92a68
> - PM / devfreq: exynos-bus: Convert to use dev_pm_opp_set_rate()
>
>
>> +
>> + cci_df->old_freq = *freq;
>> +
>> + return 0;
>> +}
>> +
>> +static struct devfreq_dev_profile cci_devfreq_profile = {
>> + .target = mtk_cci_devfreq_target,
>
> Need to add '.exit' for calling dev_pm_opp_of_remove_table().
> You can refer the merged devfreq patches like exynos_bus.c, imx-bus.c.
>
>> +};
>> +
>> +static int mtk_cci_devfreq_probe(struct platform_device *pdev)
>> +{
>> + struct device *cci_dev = &pdev->dev;
>> + struct cci_devfreq *cci_df;
>> + struct devfreq_passive_data *passive_data;
>> + int ret;
>> +
>> + cci_df = devm_kzalloc(cci_dev, sizeof(*cci_df), GFP_KERNEL);
>> + if (!cci_df)
>> + return -ENOMEM;
>> +
>> + cci_df->cci_clk = devm_clk_get(cci_dev, "cci_clock");
>> + ret = PTR_ERR_OR_ZERO(cci_df->cci_clk);
>> + if (ret) {
>> + if (ret != -EPROBE_DEFER)
>> + dev_err(cci_dev, "failed to get clock for CCI: %d\n",
>> + ret);
>> + return ret;
>> + }
>> + cci_df->proc_reg = devm_regulator_get_optional(cci_dev, "proc");
>> + ret = PTR_ERR_OR_ZERO(cci_df->proc_reg);
>> + if (ret) {
>> + if (ret != -EPROBE_DEFER)
>> + dev_err(cci_dev, "failed to get regulator for CCI: %d\n",
>> + ret);
>> + return ret;
>> + }
>
> I recommend that use dev_pm_opp_set_regulators.
> You can refer the merged patch[1].
>
> [1] commit 4294a779bd8dff6c65e7e85ffe7a1ea236e92a68
> - PM / devfreq: exynos-bus: Convert to use dev_pm_opp_set_rate()
>
>
>> + ret = regulator_enable(cci_df->proc_reg);
>> + if (ret) {
>> + pr_warn("enable buck for cci fail\n");
>
> Use dev_err instead of 'pr_warn'.
>
>> + return ret;
>> + }
>> +
>> + ret = dev_pm_opp_of_add_table(cci_dev);
>> + if (ret) {
>> + dev_err(cci_dev, "Fail to init CCI OPP table: %d\n", ret);
>
> How about changing the error log as following
> because in this driver, use the 'failed to' sentence for error handling?
>
> failed to get OPP table for CCI:L %d
>
>> + return ret;
>> + }
>> +
>> + platform_set_drvdata(pdev, cci_df);
>> +
>> + passive_data = devm_kzalloc(cci_dev, sizeof(*passive_data), GFP_KERNEL);
>> + if (!passive_data)
>> + return -ENOMEM;
>
> On this error case, you have to call dev_pm_opp_of_remove_table().
> You better to make the 'err_opp' jump lable and then add 'goto err_opp'.
>
>> +
>> + passive_data->parent_type = CPUFREQ_PARENT_DEV;
>> +
>> + cci_df->devfreq = devm_devfreq_add_device(cci_dev,
>> + &cci_devfreq_profile,
>> + DEVFREQ_GOV_PASSIVE,
>> + passive_data);
>> + if (IS_ERR(cci_df->devfreq)) {
>> + ret = PTR_ERR(cci_df->devfreq);
>> + dev_err(cci_dev, "cannot create cci devfreq device:%d\n", ret);
>> + dev_pm_opp_of_remove_table(cci_dev);
>
> Instead of direct call, use 'goto err_opp'.
>
>> + return ret;
>> + }
>> +
>> + return 0;
>> +}
>> +
>> +static int mtk_cci_devfreq_remove(struct platform_device *pdev)
>> +{
>> + struct device *cci_dev = &pdev->dev;
>> + struct cci_devfreq *cci_df;
>> + struct notifier_block *opp_nb;
>> +
>> + cci_df = platform_get_drvdata(pdev);
>> + opp_nb = &cci_df->opp_nb;
>> +
>> + dev_pm_opp_unregister_notifier(cci_dev, opp_nb);
>
> This patch doesn't call the dev_pm_opp_register_notifier.
> Please remove it.
>
>> + devm_devfreq_remove_device(cci_dev, cci_df->devfreq);
>
> Don't need to call this function because you used devm_devfreq_add_device().
>
>> + dev_pm_opp_of_remove_table(cci_dev)> + regulator_disable(cci_df->proc_reg);
>> +
>> + return 0;
>> +}
>> +
>> +static const __maybe_unused struct of_device_id
>> + mediatek_cci_devfreq_of_match[] = {
>
> Make it on one line and remove '__maybe_unused' keyword.
> - mediatek_cci_devfreq_of_match-> mediatek_cci_of_match
>
>> + { .compatible = "mediatek,mt8183-cci" },
>> + { },
>> +};
>> +MODULE_DEVICE_TABLE(of, mediatek_cci_devfreq_of_match);
>
> ditto.
>
>> +
>> +static struct platform_driver cci_devfreq_driver = {
>> + .probe = mtk_cci_devfreq_probe,
>> + .remove = mtk_cci_devfreq_remove,
>> + .driver = {
>> + .name = "mediatek-cci-devfreq",
>> + .of_match_table = of_match_ptr(mediatek_cci_devfreq_of_match),
>
> ditto.
>
>> + },
>> +};
>> +
>> +static int __init mtk_cci_devfreq_init(void)
>> +{
>> + return platform_driver_register(&cci_devfreq_driver);
>> +}
>> +module_init(mtk_cci_devfreq_init)
>> +
>> +static void __exit mtk_cci_devfreq_exit(void)
>> +{
>> + platform_driver_unregister(&cci_devfreq_driver);
>> +}
>> +module_exit(mtk_cci_devfreq_exit)
>
> Use 'module_platform_driver' instead of module_init and module_exit.
>
>> +
>> +MODULE_DESCRIPTION("Mediatek CCI devfreq driver");
>> +MODULE_AUTHOR("Andrew-sh.Cheng <andrew-sh.cheng@mediatek.com>");
>> +MODULE_LICENSE("GPL v2");
>>
>
>
--
Best Regards,
Chanwoo Choi
Samsung Electronics
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH][V3] arm64: perf: Get the wrong PC value in REGS_ABI_32 mode
From: Will Deacon @ 2020-05-28 7:54 UTC (permalink / raw)
To: Jiping Ma
Cc: Mark Rutland, zhe.he, bruce.ashfield, yue.tao, will.deacon,
linux-kernel, paul.gortmaker, catalin.marinas, linux-arm-kernel
In-Reply-To: <cd66a2e4-c953-8b09-b775-d982bb1be47a@windriver.com>
On Thu, May 28, 2020 at 09:06:07AM +0800, Jiping Ma wrote:
> On 05/27/2020 11:19 PM, Mark Rutland wrote:
> > On Wed, May 27, 2020 at 09:33:00AM +0800, Jiping Ma wrote:
> > > On 05/26/2020 06:26 PM, Mark Rutland wrote:
> > > > On Mon, May 11, 2020 at 10:52:07AM +0800, Jiping Ma wrote:
> > > This modification can not fix our issue, we need
> > > perf_reg_abi(current) == PERF_SAMPLE_REGS_ABI_32 to judge if it is 32-bit
> > > task or not,
> > > then return the correct PC value.
> > I must be missing something here.
> >
> > The core code perf_reg_abi(task) is called with the task being sampled,
> > and the regs are from the task being sampled. For a userspace sample for
> > a compat task, compat_user_mode(regs) should be equivalent to the
> > is_compat_thread(task_thread_info(task)) check.
> >
> > What am I missing?
> This issue caused by PC value is not correct. regs are sampled in function
> perf_output_sample_regs, that call perf_reg_value(regs, bit) to get PC
> value.
> PC value is regs[15] in perf_reg_value() function. it should be regs[32].
>
> perf_output_sample_regs(struct perf_output_handle *handle,
> struct pt_regs *regs, u64 mask)
> {
> int bit;
> DECLARE_BITMAP(_mask, 64);
>
> bitmap_from_u64(_mask, mask);
> for_each_set_bit(bit, _mask, sizeof(mask) * BITS_PER_BYTE) {
> u64 val;
>
> val = perf_reg_value(regs, bit);
> perf_output_put(handle, val);
> }
> }
Yes, but Mark's point is that checking 'compat_user_mode(regs)' should be
exactly the same as checking 'perf_reg_abi(current) == PERF_SAMPLE_REGS_ABI_32'.
Are you saying that's not the case? If so, please can you provide an example
of when they are different?
Leaving that aside for a second, I also think it's reasonable to question
whether this whole interface is busted or not. I looked at it last night but
struggled to work out what it's supposed to do. Consider these three
scenarios, all under an arm64 kernel:
1. 64-bit perf + 64-bit application being profiled
2. 64-bit perf + 32-bit application being profiled
3. 32-bit perf + 32-bit application being profiled
It looks like the current code is a bodge to try to handle both (2) and
(3) at the same time:
- In case (3), userspace only asks about registers 0-15
- In case (2), we fudge the higher registers so that 64-bit SP and LR
hold the 32-bit values as a bodge to allow a 64-bit dwarf unwinder
to unwind the stack
So the idea behind the patch looks fine because case (3) is expecting the PC
in register 15 and instead gets 0, but the temptation is to clean this up so
that cases (2) and (3) report the same data to userspace (along the lines of
Mark's patch), namely only the first 16 registers with the PC moved down. We
can only do that if the unwinder is happy, which it might be if it only ever
looks up dwarf register numbers based on the unwind tables in the binary.
Somebody would need to dig into that. Otherwise, if it generates unconditional
references to things like register 30 to grab the link register, then we're
stuck with the bodge and need to special-case the PC.
Thoughts?
Will
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH 1/2] drm/mxsfb: Call drm_crtc_vblank_on/off
From: Stefan Agner @ 2020-05-28 7:56 UTC (permalink / raw)
To: Daniel Vetter, laurent.pinchart
Cc: Marek Vasut, Fabio Estevam, Daniel Vetter,
Intel Graphics Development, DRI Development, NXP Linux Team,
Pengutronix Kernel Team, Daniel Vetter, Shawn Guo, Sascha Hauer,
linux-arm-kernel
In-Reply-To: <20200528054643.GQ206103@phenom.ffwll.local>
Hi Daniel,
On 2020-05-28 07:46, Daniel Vetter wrote:
> On Wed, May 27, 2020 at 11:47:56AM +0200, Daniel Vetter wrote:
>> mxsfb has vblank support, is atomic, but doesn't call
>> drm_crtc_vblank_on/off as it should. Not good.
>>
>> With my next patch to add the drm_crtc_vblank_reset to helpers this
>> means not even the very first crtc enabling will vblanks work anymore,
>> since they'll just stay off forever.
>>
>> Since mxsfb doesn't have any vblank waits of its own in the
>> enable/disable flow, nor an enable/disable_vblank callback we can do
>> the on/off as the first respectively last operation, and it should all
>> work.
>>
>> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
>> Cc: Marek Vasut <marex@denx.de>
>> Cc: Stefan Agner <stefan@agner.ch>
>> Cc: Shawn Guo <shawnguo@kernel.org>
>> Cc: Sascha Hauer <s.hauer@pengutronix.de>
>> Cc: Pengutronix Kernel Team <kernel@pengutronix.de>
>> Cc: Fabio Estevam <festevam@gmail.com>
>> Cc: NXP Linux Team <linux-imx@nxp.com>
>> Cc: linux-arm-kernel@lists.infradead.org
>
> Ping for some ack/review on this one here, it's holding up the subsystem
> wide fix in patch 2.
Sorry for the delay.
I guess that has the same effect as patch 14 in Laurent's patchset would
have:
https://lore.kernel.org/dri-devel/20200309195216.31042-15-laurent.pinchart@ideasonboard.com/
But should be rather trivial to rebase. So until Laurent's patchset is
ready, we can go with this fix.
Acked-by: Stefan Agner <stefan@agner.ch>
--
Stefan
>
> Thanks, Daniel
>
>> ---
>> drivers/gpu/drm/mxsfb/mxsfb_drv.c | 2 ++
>> 1 file changed, 2 insertions(+)
>>
>> diff --git a/drivers/gpu/drm/mxsfb/mxsfb_drv.c b/drivers/gpu/drm/mxsfb/mxsfb_drv.c
>> index 497cf443a9af..1891cd6deb2f 100644
>> --- a/drivers/gpu/drm/mxsfb/mxsfb_drv.c
>> +++ b/drivers/gpu/drm/mxsfb/mxsfb_drv.c
>> @@ -124,6 +124,7 @@ static void mxsfb_pipe_enable(struct drm_simple_display_pipe *pipe,
>> drm_panel_prepare(mxsfb->panel);
>> mxsfb_crtc_enable(mxsfb);
>> drm_panel_enable(mxsfb->panel);
>> + drm_crtc_vblank_on(&pipe->crtc);
>> }
>>
>> static void mxsfb_pipe_disable(struct drm_simple_display_pipe *pipe)
>> @@ -133,6 +134,7 @@ static void mxsfb_pipe_disable(struct drm_simple_display_pipe *pipe)
>> struct drm_crtc *crtc = &pipe->crtc;
>> struct drm_pending_vblank_event *event;
>>
>> + drm_crtc_vblank_off(&pipe->crtc);
>> drm_panel_disable(mxsfb->panel);
>> mxsfb_crtc_disable(mxsfb);
>> drm_panel_unprepare(mxsfb->panel);
>> --
>> 2.26.2
>>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH] arm64: vdso32: force vdso32 to be compiled as -marm
From: Peter Smith @ 2020-05-28 8:05 UTC (permalink / raw)
To: Nick Desaulniers, Robin Murphy
Cc: Naohiro Aota, Stephen Boyd, Arnd Bergmann, Catalin Marinas,
Masahiro Yamada, LKML, david.spickett@linaro.org, Manoj Gupta,
Kristof Beyls, Luis Lozano, Nathan Chancellor, Vincenzo Frascino,
Will Deacon, Victor Campos, Linux ARM
In-Reply-To: <CAKwvOd=Zxm9TDPNd4Qvn6Ru==FLasiP1xWXMM7ji08VWRjBu2g@mail.gmail.com>
> From: Nick Desaulniers <ndesaulniers@google.com>
> Sent: 27 May 2020 21:31
> To: Robin Murphy
> Cc: Catalin Marinas; Will Deacon; Naohiro Aota; Stephen Boyd; Masahiro Yamada; LKML; Manoj Gupta; Luis Lozano; Nathan Chancellor; Vincenzo Frascino; Linux ARM; Kristof Beyls; Victor Campos; david.spickett@linaro.org; Arnd Bergmann; Peter Smith
> Subject: Re: [PATCH] arm64: vdso32: force vdso32 to be compiled as -marm
>
> On Wed, May 27, 2020 at 1:14 PM Nick Desaulniers
> <ndesaulniers@google.com> wrote:
> >
> > On Wed, May 27, 2020 at 12:28 PM Robin Murphy <robin.murphy@arm.com> wrote:
> > >
> > > On 2020-05-27 18:55, Nick Desaulniers wrote:
> > > > On Wed, May 27, 2020 at 6:45 AM Robin Murphy <robin.murphy@arm.com> wrote:
> > > >>
> > > >> On 2020-05-26 18:31, Nick Desaulniers wrote:
> > > >>> Custom toolchains that modify the default target to -mthumb cannot
> > > >>> compile the arm64 compat vdso32, as
> > > >>> arch/arm64/include/asm/vdso/compat_gettimeofday.h
> > > >>> contains assembly that's invalid in -mthumb. Force the use of -marm,
> > > >>> always.
> > > >>
> > > >> FWIW, this seems suspicious - the only assembly instructions I see there
> > > >> are SWI(SVC), MRRC, and a MOV, all of which exist in Thumb for the
> > > >> -march=armv7a baseline that we set.
> > > >>
> > > >> On a hunch, I've just bodged "VDSO_CFLAGS += -mthumb" into my tree and
> > > >> built a Thumb VDSO quite happily with Ubuntu 19.04's
> > > >> gcc-arm-linux-gnueabihf. What was the actual failure you saw?
> > > >
> > > > From the link in the commit message: `write to reserved register 'R7'`
> > > > https://godbolt.org/z/zwr7iZ
> > > > IIUC r7 is reserved for the frame pointer in THUMB?
> > >
> > > It can be, if you choose to build with frame pointers and the common
> > > frame pointer ABI for Thumb code that uses r7. However it can also be
> > > for other things like the syscall number in the Arm syscall ABI too.
> >
> > Ah, right, with -fomit-frame-pointer, this error also goes away. Not
> > sure if we prefer either:
> > - build the compat vdso as -marm always or
> > - disable frame pointers for the vdso (does this have unwinding implications?)
> > - other?
> >
> > > I
> > > take it Clang has decided that writing syscall wrappers with minimal
> > > inline asm is not a thing people deserve to do without arbitrary other
> > > restrictions?
> >
> > Was the intent not obvious? We would have gotten away with it, too, if
> > wasn't for you meddling kids and your stupid dog! /s
> > https://www.youtube.com/watch?v=hXUqwuzcGeU
> > Anyways, this seems to explain more the intentions:
> > https://reviews.llvm.org/D76848#1945810
> > + Victor, Kristof (ARM)
>
> And maybe some other useful data points regarding warning on use of r7
> and frame pointers.
> https://github.com/ClangBuiltLinux/linux/issues/701#issuecomment-591325758
> https://bugs.llvm.org/show_bug.cgi?id=45826
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94986
>
> + Peter (ARM)
> + David, Arnd (Linaro)
> --
> Thanks,
> ~Nick Desaulniers
Hello Nick,
The AAPCS has only recently (28th January 2020) been updated with a
specification of the frame pointer and frame chain.
My understanding is that neither gcc nor clang implement this part yet.
Historically the frame pointer in Thumb has not been defined in the
AAPCS with implementations falling back to historic definitions of
fp = r7 in Thumb and fp = r11 in Arm. The use of different frame
pointer registers in Arm and Thumb state makes it difficult to
construct a frame chain with interworking. My understanding of the
AAPCS is that it has been changed to make the frame pointer r11 on
both Arm and Thumb to make unwinding possible, at the expense of r11
being harder to access from 16-bit Thumb instructions. There are 4
levels of conformance with respect to construction of frame records
and frame chain as it is likely some platforms will want to persist
with r7.
An implementation of the latest version of the AAPCS would permit
a frame pointer and use of r7 as a reserved register. Although as
you'll need to support older compilers this may not be an option.
I suggest using Arm if you need a frame pointer, and disable the
frame pointer if you want/need to use Thumb. My understanding is that
runtime unwinding using the frame pointer in Thumb is already difficult
due to Arm and Thumb functions using different registers for the frame
pointer.
Hope this helps
Peter
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ 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