* [PATCH v3 3/4] ARM: dts: pxa: add pxa27x cpu operating points
From: Robert Jarzmik @ 2016-10-31 19:54 UTC (permalink / raw)
To: Daniel Mack, Haojian Zhuang, Robert Jarzmik, Rob Herring,
Mark Rutland, Rafael J Wysocki, Viresh Kumar
Cc: linux-arm-kernel, devicetree, linux-kernel, linux-pm
In-Reply-To: <1477943696-23477-1-git-send-email-robert.jarzmik@free.fr>
Add the relevant data taken from the PXA27x Electrical, Mechanical, and
Thermal Specfication. This will be input data for cpufreq-dt driver.
Signed-off-by: Robert Jarzmik <robert.jarzmik@free.fr>
---
Since v2: opp definition amended as per Viresh's comment
---
arch/arm/boot/dts/pxa27x.dtsi | 40 ++++++++++++++++++++++++++++++++++++++++
1 file changed, 40 insertions(+)
diff --git a/arch/arm/boot/dts/pxa27x.dtsi b/arch/arm/boot/dts/pxa27x.dtsi
index 9e73dc6b3ed3..e0fab48ba6fa 100644
--- a/arch/arm/boot/dts/pxa27x.dtsi
+++ b/arch/arm/boot/dts/pxa27x.dtsi
@@ -137,4 +137,44 @@
clocks = <&clks CLK_OSTIMER>;
status = "okay";
};
+
+ pxa270_opp_table: opp_table0 {
+ compatible = "operating-points-v2";
+
+ opp@104000000 {
+ opp-hz = /bits/ 64 <104000000>;
+ opp-microvolt = <900000 900000 1705000>;
+ clock-latency-ns = <20>;
+ };
+ opp@156000000 {
+ opp-hz = /bits/ 64 <156000000>;
+ opp-microvolt = <1000000 1000000 1705000>;
+ clock-latency-ns = <20>;
+ };
+ opp@208000000 {
+ opp-hz = /bits/ 64 <208000000>;
+ opp-microvolt = <1180000 1180000 1705000>;
+ clock-latency-ns = <20>;
+ };
+ opp@312000000 {
+ opp-hz = /bits/ 64 <312000000>;
+ opp-microvolt = <1250000 1250000 1705000>;
+ clock-latency-ns = <20>;
+ };
+ opp@416000000 {
+ opp-hz = /bits/ 64 <416000000>;
+ opp-microvolt = <1350000 1350000 1705000>;
+ clock-latency-ns = <20>;
+ };
+ opp@520000000 {
+ opp-hz = /bits/ 64 <520000000>;
+ opp-microvolt = <1450000 1450000 1705000>;
+ clock-latency-ns = <20>;
+ };
+ opp@624000000 {
+ opp-hz = /bits/ 64 <624000000>;
+ opp-microvolt = <1550000 1550000 1705000>;
+ clock-latency-ns = <20>;
+ };
+ };
};
--
2.1.4
^ permalink raw reply related
* [PATCH v3 2/4] ARM: dts: pxa: add pxa25x cpu operating points
From: Robert Jarzmik @ 2016-10-31 19:54 UTC (permalink / raw)
To: Daniel Mack, Haojian Zhuang, Robert Jarzmik, Rob Herring,
Mark Rutland, Rafael J Wysocki, Viresh Kumar
Cc: linux-arm-kernel, devicetree, linux-kernel, linux-pm
In-Reply-To: <1477943696-23477-1-git-send-email-robert.jarzmik@free.fr>
Add the relevant data taken from the PXA 25x Electrical, Mechanical, and
Thermal Specfication. This will be input data for cpufreq-dt driver.
Signed-off-by: Robert Jarzmik <robert.jarzmik@free.fr>
---
Since v2: opp definition amended as per Viresh's comment
---
arch/arm/boot/dts/pxa25x.dtsi | 25 +++++++++++++++++++++++++
1 file changed, 25 insertions(+)
diff --git a/arch/arm/boot/dts/pxa25x.dtsi b/arch/arm/boot/dts/pxa25x.dtsi
index 0d1e012178c4..f9f4726396a0 100644
--- a/arch/arm/boot/dts/pxa25x.dtsi
+++ b/arch/arm/boot/dts/pxa25x.dtsi
@@ -89,4 +89,29 @@
clocks = <&clktimer>;
status = "okay";
};
+
+ pxa250_opp_table: opp_table0 {
+ compatible = "operating-points-v2";
+
+ opp@99532800 {
+ opp-hz = /bits/ 64 <99532800>;
+ opp-microvolt = <1000000 950000 1650000>;
+ clock-latency-ns = <20>;
+ };
+ opp@199065600 {
+ opp-hz = /bits/ 64 <199065600>;
+ opp-microvolt = <1000000 950000 1650000>;
+ clock-latency-ns = <20>;
+ };
+ opp@298598400 {
+ opp-hz = /bits/ 64 <298598400>;
+ opp-microvolt = <1100000 1045000 1650000>;
+ clock-latency-ns = <20>;
+ };
+ opp@398131200 {
+ opp-hz = /bits/ 64 <398131200>;
+ opp-microvolt = <1300000 1235000 1650000>;
+ clock-latency-ns = <20>;
+ };
+ };
};
--
2.1.4
^ permalink raw reply related
* [PATCH v3 1/4] cpufreq: pxa: use generic platdev driver for device-tree
From: Robert Jarzmik @ 2016-10-31 19:54 UTC (permalink / raw)
To: Daniel Mack, Haojian Zhuang, Robert Jarzmik, Rob Herring,
Mark Rutland, Rafael J Wysocki, Viresh Kumar
Cc: linux-arm-kernel, devicetree, linux-kernel, linux-pm
In-Reply-To: <1477943696-23477-1-git-send-email-robert.jarzmik@free.fr>
For device-tree based pxa25x and pxa27x platforms, cpufreq-dt driver is
doing the job as well as pxa2xx-cpufreq, so add these platforms to the
compatibility list.
This won't work for legacy non device-tree platforms where
pxa2xx-cpufreq is still required.
Signed-off-by: Robert Jarzmik <robert.jarzmik@free.fr>
---
drivers/cpufreq/cpufreq-dt-platdev.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/cpufreq/cpufreq-dt-platdev.c b/drivers/cpufreq/cpufreq-dt-platdev.c
index 71267626456b..bc683d6feca8 100644
--- a/drivers/cpufreq/cpufreq-dt-platdev.c
+++ b/drivers/cpufreq/cpufreq-dt-platdev.c
@@ -34,6 +34,8 @@ static const struct of_device_id machines[] __initconst = {
{ .compatible = "fsl,imx7d", },
{ .compatible = "marvell,berlin", },
+ { .compatible = "marvell,pxa250", },
+ { .compatible = "marvell,pxa270", },
{ .compatible = "samsung,exynos3250", },
{ .compatible = "samsung,exynos4210", },
--
2.1.4
^ permalink raw reply related
* [PATCH v3 0/4] PXA cpufreq conversion to clock API
From: Robert Jarzmik @ 2016-10-31 19:54 UTC (permalink / raw)
To: Daniel Mack, Haojian Zhuang, Robert Jarzmik, Rob Herring,
Mark Rutland, Rafael J Wysocki, Viresh Kumar
Cc: linux-arm-kernel, devicetree, linux-kernel, linux-pm
Hi,
This serie is a preparation to shift the cpufreq of pxa2xx platforms to clocks
API, next iteration.
The first 3 patches are review and merge material :
- patch 1/4 for Viresh and Rafael
- patches 2/4 and 3/4 for me
The 4th on is for review but not merge, as the clock changes must be fully
reviewed and go in first as a prequisite
Since previous iteration, 2 and 3 were amended per Viresh's suggestion.
Robert Jarzmik (4):
cpufreq: pxa: use generic platdev driver for device-tree
ARM: dts: pxa: add pxa25x cpu operating points
ARM: dts: pxa: add pxa27x cpu operating points
cpufreq: pxa: convert to clock API
arch/arm/boot/dts/pxa25x.dtsi | 25 +++++
arch/arm/boot/dts/pxa27x.dtsi | 40 ++++++++
drivers/cpufreq/cpufreq-dt-platdev.c | 2 +
drivers/cpufreq/pxa2xx-cpufreq.c | 191 +++++++----------------------------
4 files changed, 106 insertions(+), 152 deletions(-)
--
2.1.4
^ permalink raw reply
* [PATCH v6 2/7] ARM: dts: r8a7743: add SYS-DMAC support
From: Sergei Shtylyov @ 2016-10-31 19:54 UTC (permalink / raw)
To: horms-/R6kz+dDXgpPR4JQBCEnsQ,
linux-renesas-soc-u79uwXL29TY76Z2rM5mHXA,
robh+dt-DgEjT+Ai2ygdnm+yROfE0A, mark.rutland-5wv7dgnIgG8,
devicetree-u79uwXL29TY76Z2rM5mHXA
Cc: magnus.damm-Re5JQEeQqe8AvxtiuMwx3w, linux-lFZ/pmaqli7XmaaqVzeoHQ,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r
In-Reply-To: <1746536.qobnGdHRfV-gHKXc3Y1Z8zGSmamagVegGFoWSdPRAKMAL8bYrjMMd8@public.gmane.org>
Describe SYS-DMAC0/1 in the R8A7743 device tree.
Based on the original (and large) patch by Dmitry Shifrin
<dmitry.shifrin-M4DtvfQ/ZS1MRgGoP+s0PdBPR1lH4CV8@public.gmane.org>.
Signed-off-by: Sergei Shtylyov <sergei.shtylyov-M4DtvfQ/ZS1MRgGoP+s0PdBPR1lH4CV8@public.gmane.org>
Reviewed-by: Geert Uytterhoeven <geert+renesas-gXvu3+zWzMSzQB+pC5nmwQ@public.gmane.org>
---
Changes in version 6:
- refreshed the patch.
Changes in version 5:
- refreshed the patch.
Changes in version 4:
- refreshed the patch.
Changes in version 3:
- resolved a reject;
- updated the "clocks" properties for the CPG/MSSR driver.
Changes in version 2:
- added Geert's tag.
arch/arm/boot/dts/r8a7743.dtsi | 64 +++++++++++++++++++++++++++++++++++++++++
1 file changed, 64 insertions(+)
Index: renesas/arch/arm/boot/dts/r8a7743.dtsi
===================================================================
--- renesas.orig/arch/arm/boot/dts/r8a7743.dtsi
+++ renesas/arch/arm/boot/dts/r8a7743.dtsi
@@ -93,6 +93,70 @@
compatible = "renesas,r8a7743-rst";
reg = <0 0xe6160000 0 0x100>;
};
+
+ dmac0: dma-controller@e6700000 {
+ compatible = "renesas,dmac-r8a7743",
+ "renesas,rcar-dmac";
+ reg = <0 0xe6700000 0 0x20000>;
+ interrupts = <GIC_SPI 197 IRQ_TYPE_LEVEL_HIGH
+ GIC_SPI 200 IRQ_TYPE_LEVEL_HIGH
+ GIC_SPI 201 IRQ_TYPE_LEVEL_HIGH
+ GIC_SPI 202 IRQ_TYPE_LEVEL_HIGH
+ GIC_SPI 203 IRQ_TYPE_LEVEL_HIGH
+ GIC_SPI 204 IRQ_TYPE_LEVEL_HIGH
+ GIC_SPI 205 IRQ_TYPE_LEVEL_HIGH
+ GIC_SPI 206 IRQ_TYPE_LEVEL_HIGH
+ GIC_SPI 207 IRQ_TYPE_LEVEL_HIGH
+ GIC_SPI 208 IRQ_TYPE_LEVEL_HIGH
+ GIC_SPI 209 IRQ_TYPE_LEVEL_HIGH
+ GIC_SPI 210 IRQ_TYPE_LEVEL_HIGH
+ GIC_SPI 211 IRQ_TYPE_LEVEL_HIGH
+ GIC_SPI 212 IRQ_TYPE_LEVEL_HIGH
+ GIC_SPI 213 IRQ_TYPE_LEVEL_HIGH
+ GIC_SPI 214 IRQ_TYPE_LEVEL_HIGH>;
+ interrupt-names = "error",
+ "ch0", "ch1", "ch2", "ch3",
+ "ch4", "ch5", "ch6", "ch7",
+ "ch8", "ch9", "ch10", "ch11",
+ "ch12", "ch13", "ch14";
+ clocks = <&cpg CPG_MOD 219>;
+ clock-names = "fck";
+ power-domains = <&sysc R8A7743_PD_ALWAYS_ON>;
+ #dma-cells = <1>;
+ dma-channels = <15>;
+ };
+
+ dmac1: dma-controller@e6720000 {
+ compatible = "renesas,dmac-r8a7743",
+ "renesas,rcar-dmac";
+ reg = <0 0xe6720000 0 0x20000>;
+ interrupts = <GIC_SPI 220 IRQ_TYPE_LEVEL_HIGH
+ GIC_SPI 216 IRQ_TYPE_LEVEL_HIGH
+ GIC_SPI 217 IRQ_TYPE_LEVEL_HIGH
+ GIC_SPI 218 IRQ_TYPE_LEVEL_HIGH
+ GIC_SPI 219 IRQ_TYPE_LEVEL_HIGH
+ GIC_SPI 308 IRQ_TYPE_LEVEL_HIGH
+ GIC_SPI 309 IRQ_TYPE_LEVEL_HIGH
+ GIC_SPI 310 IRQ_TYPE_LEVEL_HIGH
+ GIC_SPI 311 IRQ_TYPE_LEVEL_HIGH
+ GIC_SPI 312 IRQ_TYPE_LEVEL_HIGH
+ GIC_SPI 313 IRQ_TYPE_LEVEL_HIGH
+ GIC_SPI 314 IRQ_TYPE_LEVEL_HIGH
+ GIC_SPI 315 IRQ_TYPE_LEVEL_HIGH
+ GIC_SPI 316 IRQ_TYPE_LEVEL_HIGH
+ GIC_SPI 317 IRQ_TYPE_LEVEL_HIGH
+ GIC_SPI 318 IRQ_TYPE_LEVEL_HIGH>;
+ interrupt-names = "error",
+ "ch0", "ch1", "ch2", "ch3",
+ "ch4", "ch5", "ch6", "ch7",
+ "ch8", "ch9", "ch10", "ch11",
+ "ch12", "ch13", "ch14";
+ clocks = <&cpg CPG_MOD 218>;
+ clock-names = "fck";
+ power-domains = <&sysc R8A7743_PD_ALWAYS_ON>;
+ #dma-cells = <1>;
+ dma-channels = <15>;
+ };
};
/* External root clock */
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* [PATCH v6 1/7] ARM: dts: r8a7743: initial SoC device tree
From: Sergei Shtylyov @ 2016-10-31 19:54 UTC (permalink / raw)
To: horms, linux-renesas-soc, robh+dt, mark.rutland, devicetree
Cc: magnus.damm, linux, linux-arm-kernel
In-Reply-To: <1746536.qobnGdHRfV@wasted.cogentembedded.com>
The initial R8A7743 SoC device tree including CPU0, GIC, timer, SYSC, RST,
CPG, and the required clock descriptions.
Based on the original (and large) patch by Dmitry Shifrin
<dmitry.shifrin@cogentembedded.com>.
Signed-off-by: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>
Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
---
Changes in version 6:
- corrected the "reg" prop of the RST node;
- removed leading zero from the SYSC "reg" property's cell;
- fixed the typo in "overriden".
Changes in version 5:
- added the RST device node, updated the patch description accordingly.
Changes in version 4:
- removed the CPU1 node, updated the patch description accordingly;
- reformatted the "interrupts" props of the GIC/timer device nodes;
- added Geert's tag.
Changes in version 3:
- changed the R8A7743 clock header #include;
- replaced the multiple clock nodes with the single CPG node, updated the
"clocks" property in the CPU0 node, updated the patch description.
Changes in version 2:
- added the IRQC and Ether clocks.
arch/arm/boot/dts/r8a7743.dtsi | 120 +++++++++++++++++++++++++++++++++++++++++
1 file changed, 120 insertions(+)
Index: renesas/arch/arm/boot/dts/r8a7743.dtsi
===================================================================
--- /dev/null
+++ renesas/arch/arm/boot/dts/r8a7743.dtsi
@@ -0,0 +1,120 @@
+/*
+ * Device Tree Source for the r8a7743 SoC
+ *
+ * Copyright (C) 2016 Cogent Embedded Inc.
+ *
+ * This file is licensed under the terms of the GNU General Public License
+ * version 2. This program is licensed "as is" without any warranty of any
+ * kind, whether express or implied.
+ */
+
+#include <dt-bindings/interrupt-controller/irq.h>
+#include <dt-bindings/interrupt-controller/arm-gic.h>
+#include <dt-bindings/clock/r8a7743-cpg-mssr.h>
+#include <dt-bindings/power/r8a7743-sysc.h>
+
+/ {
+ compatible = "renesas,r8a7743";
+ #address-cells = <2>;
+ #size-cells = <2>;
+
+ cpus {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ cpu0: cpu@0 {
+ device_type = "cpu";
+ compatible = "arm,cortex-a15";
+ reg = <0>;
+ clock-frequency = <1500000000>;
+ clocks = <&cpg CPG_CORE R8A7743_CLK_Z>;
+ power-domains = <&sysc R8A7743_PD_CA15_CPU0>;
+ next-level-cache = <&L2_CA15>;
+ };
+
+ L2_CA15: cache-controller@0 {
+ compatible = "cache";
+ reg = <0>;
+ cache-unified;
+ cache-level = <2>;
+ power-domains = <&sysc R8A7743_PD_CA15_SCU>;
+ };
+ };
+
+ soc {
+ compatible = "simple-bus";
+ interrupt-parent = <&gic>;
+
+ #address-cells = <2>;
+ #size-cells = <2>;
+ ranges;
+
+ gic: interrupt-controller@f1001000 {
+ compatible = "arm,gic-400";
+ #interrupt-cells = <3>;
+ #address-cells = <0>;
+ interrupt-controller;
+ reg = <0 0xf1001000 0 0x1000>,
+ <0 0xf1002000 0 0x1000>,
+ <0 0xf1004000 0 0x2000>,
+ <0 0xf1006000 0 0x2000>;
+ interrupts = <GIC_PPI 9 (GIC_CPU_MASK_SIMPLE(2) |
+ IRQ_TYPE_LEVEL_HIGH)>;
+ };
+
+ timer {
+ compatible = "arm,armv7-timer";
+ interrupts = <GIC_PPI 13 (GIC_CPU_MASK_SIMPLE(2) |
+ IRQ_TYPE_LEVEL_LOW)>,
+ <GIC_PPI 14 (GIC_CPU_MASK_SIMPLE(2) |
+ IRQ_TYPE_LEVEL_LOW)>,
+ <GIC_PPI 11 (GIC_CPU_MASK_SIMPLE(2) |
+ IRQ_TYPE_LEVEL_LOW)>,
+ <GIC_PPI 10 (GIC_CPU_MASK_SIMPLE(2) |
+ IRQ_TYPE_LEVEL_LOW)>;
+ };
+
+ cpg: clock-controller@e6150000 {
+ compatible = "renesas,r8a7743-cpg-mssr";
+ reg = <0 0xe6150000 0 0x1000>;
+ clocks = <&extal_clk>, <&usb_extal_clk>;
+ clock-names = "extal", "usb_extal";
+ #clock-cells = <2>;
+ #power-domain-cells = <0>;
+ };
+
+ sysc: system-controller@e6180000 {
+ compatible = "renesas,r8a7743-sysc";
+ reg = <0 0xe6180000 0 0x200>;
+ #power-domain-cells = <1>;
+ };
+
+ rst: reset-controller@e6160000 {
+ compatible = "renesas,r8a7743-rst";
+ reg = <0 0xe6160000 0 0x100>;
+ };
+ };
+
+ /* External root clock */
+ extal_clk: extal {
+ compatible = "fixed-clock";
+ #clock-cells = <0>;
+ /* This value must be overridden by the board. */
+ clock-frequency = <0>;
+ };
+
+ /* External USB clock - can be overridden by the board */
+ usb_extal_clk: usb_extal {
+ compatible = "fixed-clock";
+ #clock-cells = <0>;
+ clock-frequency = <48000000>;
+ };
+
+ /* External SCIF clock */
+ scif_clk: scif {
+ compatible = "fixed-clock";
+ #clock-cells = <0>;
+ /* This value must be overridden by the board. */
+ clock-frequency = <0>;
+ };
+};
^ permalink raw reply
* [PATCH v6 0/7] Add R8A7743/SK-RZG1M board support
From: Sergei Shtylyov @ 2016-10-31 19:52 UTC (permalink / raw)
To: horms, linux-renesas-soc, robh+dt, mark.rutland, devicetree
Cc: magnus.damm, linux, linux-arm-kernel
Hello.
Here's the set of 7 patches against Simon Horman's 'renesas.git' repo's
'renesas-devel-20161031-v4.9-rc3' tag. I'm adding the device tree support for
the R8A7743-based SK-RZG1M board. The SoC is close to R8A7791 and the board
seems identical to the R8A7791/Porter board. The device tree patches depend on
the R8A7743 CPG/MSSR driver series in order to compile and work. Already merged
patches from this series won't be re-posted.
[1/7] ARM: dts: r8a7743: initial SoC device tree
[2/7] ARM: dts: r8a7743: add SYS-DMAC support
[3/7] ARM: dts: r8a7743: add [H]SCIF{A|B} support
[4/7] ARM: dts: r8a7743: add Ether support
[5/7] ARM: dts: r8a7743: add IRQC support
[6/7] ARM: dts: sk-rzg1m: initial device tree
[7/7] ARM: dts: sk-rzg1m: add Ether support
WBR, Sergei
^ permalink raw reply
* Re: [PATCH] dt-bindings: video: exynos7-decon: Remove obsolete samsung,power-domain property
From: Krzysztof Kozlowski @ 2016-10-31 19:21 UTC (permalink / raw)
To: Rob Herring
Cc: Krzysztof Kozlowski, Inki Dae, Joonyoung Shim, Seung-Woo Kim,
Kyungmin Park, David Airlie, Kukjin Kim, Javier Martinez Canillas,
dri-devel-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-samsung-soc-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <20161030204124.wwvv2qfshj7lvggx@rob-hp-laptop>
On Sun, Oct 30, 2016 at 03:41:24PM -0500, Rob Herring wrote:
> On Fri, Oct 21, 2016 at 05:05:54PM +0300, Krzysztof Kozlowski wrote:
> > The samsung,power-domain property is obsolete since commit 0da658704136
> > ("ARM: dts: convert to generic power domain bindings for exynos DT").
> > Replace it with generic one.
> >
> > Signed-off-by: Krzysztof Kozlowski <krzk-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
> > ---
> > Documentation/devicetree/bindings/display/exynos/exynos7-decon.txt | 2 +-
> > 1 file changed, 1 insertion(+), 1 deletion(-)
>
> You didn't send this To me, so I assume someone else is applying it.
>
> Acked-by: Rob Herring <robh-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
Thanks for the ack. I assumed it will go through the Exynos DRM
subsystem maintainer.
Dear Inki Dae,
Could you pick it up or share your comments?
Best regards,
Krzysztof
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [RFC PATCH v2 1/5] net: mdio-mux-mmioreg: Add support for 16bit and 32bit register sizes
From: Andrew Lunn @ 2016-10-31 18:59 UTC (permalink / raw)
To: Neil Armstrong
Cc: f.fainelli, khilman, carlo, netdev, linux-amlogic,
linux-arm-kernel, linux-kernel, devicetree
In-Reply-To: <1477932987-27871-2-git-send-email-narmstrong@baylibre.com>
On Mon, Oct 31, 2016 at 05:56:23PM +0100, Neil Armstrong wrote:
> In order to support PHY switching on Amlogic GXL SoCs, add support for
> 16bit and 32bit registers sizes.
>
> Signed-off-by: Neil Armstrong <narmstrong@baylibre.com>
Nice.
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Andrew
^ permalink raw reply
* Re: [PATCH] ARM: DT: stm32: move dma translation to board files
From: Radosław Pietrzyk @ 2016-10-31 18:58 UTC (permalink / raw)
To: Bruno Herrera
Cc: Alexandre Torgue, mark.rutland, devicetree, Arnd Bergmann, linux,
>, >, Maxime Coquelin, Lee Jones, linux-arm-kernel
In-Reply-To: <CAF3+Tqdz+92yxuSwZHdQ01d-G-bBNtzayKyP2-_On2APvFyLNA@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 11046 bytes --]
I think wlcore driver searches dma-ranges in its parent that's why sdio
node needs it.
2016-10-31 17:41 GMT+01:00 Bruno Herrera <bruherrera@gmail.com>:
> On Mon, Oct 31, 2016 at 12:14 PM, Radosław Pietrzyk
> <radoslaw.pietrzyk@gmail.com> wrote:
> > This is weird because dma ddresses are recalculated using parent's
> > dma-ranges property and soc already has it so there should be absolutely
> no
> > problem.
>
> These are my DTS and DTSI file.
> >
> > 2016-10-31 11:27 GMT+01:00 Bruno Herrera <bruherrera@gmail.com>:
> >>
> >> On Fri, Oct 28, 2016 at 5:09 AM, Radosław Pietrzyk
> >> <radoslaw.pietrzyk@gmail.com> wrote:
> >> > Have you defined your sdio node within soc node ?
> >>
> >> It is in the SOC node of the DSTI file.
> >>
> >> >
> >> > 2016-10-27 14:57 GMT+02:00 Bruno Herrera <bruherrera@gmail.com>:
> >> >>
> >> >> Hi Alex,
> >> >>
> >> >> On Thu, Oct 27, 2016 at 10:21 AM, Alexandre Torgue
> >> >> <alexandre.torgue@st.com> wrote:
> >> >> > Hi Bruno,
> >> >> >
> >> >> >
> >> >> > On 10/27/2016 12:43 PM, Bruno Herrera wrote:
> >> >> >>
> >> >> >> Hi Alex,
> >> >> >>
> >> >> >> On Wed, Oct 26, 2016 at 7:09 AM, Alexandre Torgue
> >> >> >> <alexandre.torgue@st.com> wrote:
> >> >> >>>
> >> >> >>> Hi Bruno,
> >> >> >>>
> >> >> >>> On 10/25/2016 11:06 PM, Bruno Herrera wrote:
> >> >> >>>>
> >> >> >>>>
> >> >> >>>> Hi Alexandre,
> >> >> >>>>
> >> >> >>>>>
> >> >> >>>>> stm32f469-disco and stm32f429-eval boards use SDRAM start
> address
> >> >> >>>>> remapping
> >> >> >>>>> (to @0) to boost performances. A DMA translation through
> >> >> >>>>> "dma-ranges"
> >> >> >>>>> property was needed for other masters than the M4 CPU.
> >> >> >>>>> stm32f429-disco doesn't use remapping so doesn't need this DMA
> >> >> >>>>> translation.
> >> >> >>>>> This patches moves this DMA translation definition from
> stm32f429
> >> >> >>>>> soc
> >> >> >>>>> file
> >> >> >>>>> to board files.
> >> >> >>>>>
> >> >> >>>>> Signed-off-by: Alexandre TORGUE <alexandre.torgue@st.com>
> >> >> >>>>>
> >> >> >>>>> diff --git a/arch/arm/boot/dts/stm32429i-eval.dts
> >> >> >>>>> b/arch/arm/boot/dts/stm32429i-eval.dts
> >> >> >>>>> index 13c7cd2..a763c15 100644
> >> >> >>>>> --- a/arch/arm/boot/dts/stm32429i-eval.dts
> >> >> >>>>> +++ b/arch/arm/boot/dts/stm32429i-eval.dts
> >> >> >>>>> @@ -82,6 +82,10 @@
> >> >> >>>>> };
> >> >> >>>>> };
> >> >> >>>>>
> >> >> >>>>> + soc {
> >> >> >>>>> + dma-ranges = <0xc0000000 0x0 0x10000000>;
> >> >> >>>>> + };
> >> >> >>>>> +
> >> >> >>>>> usbotg_hs_phy: usbphy {
> >> >> >>>>> #phy-cells = <0>;
> >> >> >>>>> compatible = "usb-nop-xceiv";
> >> >> >>>>
> >> >> >>>>
> >> >> >>>>
> >> >> >>>> Shouldn't also the peripheral dma-ranges property move to board
> >> >> >>>> specific
> >> >> >>>> too?
> >> >> >>>> I had this patch for while but I didn't had the time to submit:
> >> >> >>>
> >> >> >>>
> >> >> >>>
> >> >> >>> Well spot I forgot it. Actually, discussing with Arnd ysterday on
> >> >> >>> IIRC,
> >> >> >>> empty dma-ranges is not needed. Can you test on your side by
> >> >> >>> removing
> >> >> >>> dma-ranges in usb node please ?
> >> >> >>
> >> >> >> Unfortunately will take a time for me to set up this environment
> on
> >> >> >> the STM32F4-EVAL board.
> >> >> >> And on the discovery boards we dont have this scenario. That was
> the
> >> >> >> main reason I did not submit the patch right away.
> >> >> >> My conclusion and I might be wrong but is based on the my tests
> with
> >> >> >> SDIO device at STM32F469I-DISCO board.
> >> >> >>
> >> >> >> I started this issue as discussion at ST Forum but Maxime gave me
> >> >> >> the
> >> >> >> hint.
> >> >> >>
> >> >> >>
> >> >> >>
> >> >> >>
> >> >> >> https://my.st.com/public/STe2ecommunities/mcu/Lists/
> cortex_mx_stm32/Flat.aspx?RootFolder=https%3a%2f%2fmy%2est%2ecom%2fpublic%
> 2fSTe2ecommunities%2fmcu%2fLists%2fcortex_mx_stm32%
> 2fDMA2%20and%20SYSCFG_MEMRMP%20relationship&FolderCTID=
> 0x01200200770978C69A1141439FE559EB459D7580009C4E14902C3CDE46
> A77F0FFD06506F5B¤tviews=44
> >> >> >>
> >> >> >>> I will push a v2 by removing empty dma-ranges if tests are ok in
> >> >> >>> your
> >> >> >>> side.
> >> >> >>
> >> >> >>
> >> >> >> From my understating/conclusion is: when empty
> property(dma-ranges)
> >> >> >> is
> >> >> >> the device node, the mapping will be taken in consideration when
> >> >> >> using
> >> >> >> DMA otherwise the mapping is ignored.
> >> >> >> And in the SDIO case it is needed for DEV->MEM(SDRAM) and
> >> >> >> MEM(SDRAM)->DEV. If it is not the case for the devices in question
> >> >> >> so
> >> >> >> I suppose it can work without the property.
> >> >> >
> >> >> >
> >> >> > For sure translation has to be done but I'm not sure that an empty
> >> >> > "dma-ranges" is needed in device node to activate it. For Ethernet
> >> >> > empty
> >> >> > "dma-ranges" is not needed. I will try with usb.
> >> >>
> >> >> In the case of SDIO it is needed. As example this is my working SDIO
> >> >> node:
> >> >>
> >> >> sdio: sdio@40012c00 {
> >> >> compatible = "arm,pl18x", "arm,primecell";
> >> >> arm,primecell-periphid = <0x00480181>;
> >> >> reg = <0x40012c00 0x400>;
> >> >> dmas = <&dma2 6 4 0x10400 0x3>, /* Logical - DevToMem */
> >> >> <&dma2 3 4 0x10400 0x3>; /* Logical - MemToDev */
> >> >> dma-names = "rx", "tx";
> >> >> clocks = <&rcc 0 171>;
> >> >> clock-names = "apb_pclk";
> >> >> interrupts = <49>;
> >> >> status = "disabled";
> >> >> };
> >> >>
> >> >> &sdio {
> >> >> status = "okay";
> >> >> vmmc-supply = <&wlan_en>;
> >> >> bus-width = <4>;
> >> >> max-frequency = <24000000>;
> >> >> pinctrl-names = "default";
> >> >> pinctrl-0 = <&sdio_pins>;
> >> >> ti,non-removable;
> >> >> ti,needs-special-hs-handling;
> >> >> dma-ranges;
> >> >> cap-power-off-card;
> >> >> keep-power-in-suspend;
> >> >>
> >> >> #address-cells = <1>;
> >> >> #size-cells = <0>;
> >> >> wlcore: wlcore@0 {
> >> >> compatible = "ti,wl1835";
> >> >> reg = <2>;
> >> >> interrupt-parent = <&gpioa>;
> >> >> interrupts = <8 IRQ_TYPE_EDGE_RISING>;
> >> >> };
> >> >> };
> >> >>
> >> >> >
> >> >> > alex
> >> >> >
> >> >> >
> >> >> >>
> >> >> >>>
> >> >> >>> Thanks in advance
> >> >> >>> Alex
> >> >> >>>
> >> >> >>>
> >> >> >>>>
> >> >> >>>> Author: Bruno Herrera <bruherrera@gmail.com>
> >> >> >>>> Date: Sun Oct 16 14:50:00 2016 -0200
> >> >> >>>>
> >> >> >>>> ARM: DT: STM32: Use dma-ranges property per board not at
> dtsi
> >> >> >>>> file
> >> >> >>>>
> >> >> >>>> diff --git a/arch/arm/boot/dts/stm32429i-eval.dts
> >> >> >>>> b/arch/arm/boot/dts/stm32429i-eval.dts
> >> >> >>>> index 6bfc595..2a22a82 100644
> >> >> >>>> --- a/arch/arm/boot/dts/stm32429i-eval.dts
> >> >> >>>> +++ b/arch/arm/boot/dts/stm32429i-eval.dts
> >> >> >>>> @@ -52,6 +52,10 @@
> >> >> >>>> model = "STMicroelectronics STM32429i-EVAL board";
> >> >> >>>> compatible = "st,stm32429i-eval", "st,stm32f429";
> >> >> >>>>
> >> >> >>>> + soc {
> >> >> >>>> + dma-ranges = <0xC0000000 0x0 0x10000000>;
> >> >> >>>> + };
> >> >> >>>> +
> >> >> >>>> chosen {
> >> >> >>>> bootargs = "root=/dev/ram rdinit=/linuxrc";
> >> >> >>>> stdout-path = "serial0:115200n8";
> >> >> >>>> @@ -96,6 +100,7 @@
> >> >> >>>>
> >> >> >>>> ðernet0 {
> >> >> >>>> status = "okay";
> >> >> >>>> + dma-ranges;
> >> >> >>>> pinctrl-0 = <ðernet0_mii>;
> >> >> >>>> pinctrl-names = "default";
> >> >> >>>> phy-mode = "mii-id";
> >> >> >>>> @@ -116,6 +121,7 @@
> >> >> >>>> };
> >> >> >>>>
> >> >> >>>> &usbotg_hs {
> >> >> >>>> + dma-ranges;
> >> >> >>>> dr_mode = "host";
> >> >> >>>> phys = <&usbotg_hs_phy>;
> >> >> >>>> phy-names = "usb2-phy";
> >> >> >>>> diff --git a/arch/arm/boot/dts/stm32f429.dtsi
> >> >> >>>> b/arch/arm/boot/dts/stm32f429.dtsi
> >> >> >>>> index 7d624a2..697a133 100644
> >> >> >>>> --- a/arch/arm/boot/dts/stm32f429.dtsi
> >> >> >>>> +++ b/arch/arm/boot/dts/stm32f429.dtsi
> >> >> >>>> @@ -59,7 +59,6 @@
> >> >> >>>> };
> >> >> >>>>
> >> >> >>>> soc {
> >> >> >>>> - dma-ranges = <0xc0000000 0x0 0x10000000>;
> >> >> >>>>
> >> >> >>>> timer2: timer@40000000 {
> >> >> >>>> compatible = "st,stm32-timer";
> >> >> >>>> @@ -472,13 +471,11 @@
> >> >> >>>> st,syscon = <&syscfg 0x4>;
> >> >> >>>> snps,pbl = <8>;
> >> >> >>>> snps,mixed-burst;
> >> >> >>>> - dma-ranges;
> >> >> >>>> status = "disabled";
> >> >> >>>> };
> >> >> >>>>
> >> >> >>>> usbotg_hs: usb@40040000 {
> >> >> >>>> compatible = "snps,dwc2";
> >> >> >>>> - dma-ranges;
> >> >> >>>> reg = <0x40040000 0x40000>;
> >> >> >>>> interrupts = <77>;
> >> >> >>>> clocks = <&rcc 0 29>;
> >> >> >>>>
> >> >> >>>>
> >> >> >>>>> diff --git a/arch/arm/boot/dts/stm32f429.dtsi
> >> >> >>>>> b/arch/arm/boot/dts/stm32f429.dtsi
> >> >> >>>>> index 0596d60..3a1cfdd 100644
> >> >> >>>>> --- a/arch/arm/boot/dts/stm32f429.dtsi
> >> >> >>>>> +++ b/arch/arm/boot/dts/stm32f429.dtsi
> >> >> >>>>> @@ -59,8 +59,6 @@
> >> >> >>>>> };
> >> >> >>>>>
> >> >> >>>>> soc {
> >> >> >>>>> - dma-ranges = <0xc0000000 0x0 0x10000000>;
> >> >> >>>>> -
> >> >> >>>>> timer2: timer@40000000 {
> >> >> >>>>> compatible = "st,stm32-timer";
> >> >> >>>>> reg = <0x40000000 0x400>;
> >> >> >>>>> diff --git a/arch/arm/boot/dts/stm32f469-disco.dts
> >> >> >>>>> b/arch/arm/boot/dts/stm32f469-disco.dts
> >> >> >>>>> index 9e73656..c2213c0 100644
> >> >> >>>>> --- a/arch/arm/boot/dts/stm32f469-disco.dts
> >> >> >>>>> +++ b/arch/arm/boot/dts/stm32f469-disco.dts
> >> >> >>>>> @@ -64,6 +64,10 @@
> >> >> >>>>> aliases {
> >> >> >>>>> serial0 = &usart3;
> >> >> >>>>> };
> >> >> >>>>> +
> >> >> >>>>> + soc {
> >> >> >>>>> + dma-ranges = <0xc0000000 0x0 0x10000000>;
> >> >> >>>>> + };
> >> >> >>>>> };
> >> >> >>>>>
> >> >> >>>>> &clk_hse {
> >> >> >>>>> --
> >> >> >>>>
> >> >> >>>>
> >> >> >>>>
> >> >> >>>>
> >> >> >>>> Br.,
> >> >> >>>> Bruno
> >> >> >>>>
> >> >> >>>
> >> >> >
> >> >>
> >> >> _______________________________________________
> >> >> linux-arm-kernel mailing list
> >> >> linux-arm-kernel@lists.infradead.org
> >> >> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
> >> >
> >> >
> >
> >
>
[-- Attachment #2: Type: text/html, Size: 19849 bytes --]
^ permalink raw reply
* Re: [PATCH] pinctrl: meson: Add GXL pinctrl definitions
From: Kevin Hilman @ 2016-10-31 18:29 UTC (permalink / raw)
To: Neil Armstrong
Cc: linus.walleij, carlo, linux-gpio, linux-amlogic, linux-arm-kernel,
linux-kernel, devicetree
In-Reply-To: <1477931531-27120-1-git-send-email-narmstrong@baylibre.com>
Neil Armstrong <narmstrong@baylibre.com> writes:
> Add support for the Amlogic Meson GXL SoC, this is a partially complete
> definition only based on the Amlogic Vendor tree.
>
> This definition differs a lot from the GXBB and needs a separate entry.
>
> Acked-by: Rob Herring <robh@kernel.org>
> Signed-off-by: Neil Armstrong <narmstrong@baylibre.com>
Acked-by: Kevin Hilman <khilman@baylibre.com>
^ permalink raw reply
* Re: [PATCH v12 RESEND 0/4] generic TEE subsystem
From: Andrew F. Davis @ 2016-10-31 18:24 UTC (permalink / raw)
To: Jens Wiklander
Cc: valentin.manea, devicetree, javier, emmanuel.michel,
Arnd Bergmann, Nishanth Menon, Greg Kroah-Hartman, broonie,
Will Deacon, linux-kernel, jean-michel.delorme, Jason Gunthorpe,
vlad.babchuk, Rob Herring, Al Viro, Mark Rutland, Michal Simek,
linux-arm-kernel
In-Reply-To: <20161029094641.GA23362@ermac>
On 10/29/2016 04:46 AM, Jens Wiklander wrote:
> On Fri, Oct 28, 2016 at 10:43:24AM -0500, Andrew F. Davis wrote:
>> On 10/28/2016 05:19 AM, Jens Wiklander wrote:
>>> Hi,
>>>
>>> This patch set introduces a generic TEE subsystem. The TEE subsystem will
>>> contain drivers for various TEE implementations. A TEE (Trusted Execution
>>> Environment) is a trusted OS running in some secure environment, for
>>> example, TrustZone on ARM CPUs, or a separate secure co-processor etc.
>>>
>>> Regarding use cases, TrustZone has traditionally been used for
>>> offloading secure tasks to the secure world. Examples include:
>>> - Secure key handling where the OS may or may not have direct access to key
>>> material.
>>> - E-commerce and payment technologies. Credentials, credit card numbers etc
>>> could be stored in a more secure environment.
>>> - Trusted User Interface (TUI) to ensure that no-one can snoop PIN-codes
>>> etc.
>>> - Secure boot to ensure that loaded binaries haven’t been tampered with.
>>> It’s not strictly needed for secure boot, but you could enhance security
>>> by leveraging a TEE during boot.
>>> - Digital Rights Management (DRM), the studios provides content with
>>> different resolution depending on the security of the device. Higher
>>> security means higher resolution.
>>>
>>> A TEE could also be used in existing and new technologies. For example IMA
>>> (Integrity Measurement Architecture) which has been in the kernel for quite
>>> a while. Today you can enhance security by using a TPM-chip to sign the IMA
>>> measurement list. This is something that you also could do by leveraging a
>>> TEE.
>>>
>>> Another example could be in 2-factor authentication which is becoming
>>> increasingly more important. FIDO (https://fidoalliance.org) for example
>>> are using public key cryptography in their 2-factor authentication standard
>>> (U2F). With FIDO, a private and public key pair will be generated for every
>>> site you visit and the private key should never leave the local device.
>>> This is an example where you could use secure storage in a TEE for the
>>> private key.
>>>
>>> Today you will find a quite a few different out of tree implementations of
>>> TEE drivers which tends to fragment the TEE ecosystem and development. We
>>> think it would be a good idea to have a generic TEE driver integrated in
>>> the kernel which would serve as a base for several different TEE solutions,
>>> no matter if they are on-chip like TrustZone or if they are on a separate
>>> crypto co-processor.
>>>
>>> To develop this TEE subsystem we have been using the open source TEE called
>>> OP-TEE (https://github.com/OP-TEE/optee_os) and therefore this would be the
>>> first TEE solution supported by this new subsystem. OP-TEE is a
>>> GlobalPlatform compliant TEE, however this TEE subsystem is not limited to
>>> only GlobalPlatform TEEs, instead we have tried to design it so that it
>>> should work with other TEE solutions also.
>>>
>>
>> The above is my biggest concern with this whole subsystem, to me it
>> still feels very OPTEE specific. As much as I would love to believe
>> OPTEE will be the end-all TEE, I'm sure we soon will start to see wider
>> use of vendor TEEs (like TI's own legacy Trustzone thing we are hoping
>> to depreciate with OPTEE moving forward), possibly Google's Trusty TEE,
>> and whatever Intel/AMD are cooking up for x86.
>
> I'd rather say that it's slightly GlobalPlatform specific, but a bit
> more flexible.
>
>>
>> As we all know when things are upstreamed we lose the ability to make
>> radical changes easily, especially to full subsystems. What happens when
>> this framework, built with only one existing TEE, built by the one
>> existing TEE's devs, is not as flexible as we need when other TEEs start
>> rolling out?
>
> Initially the TEE subsystem was much more flexible and was criticized
> for that.
>
That's rather strange, I haven't been following this from the start so I
will just take your word that this is where the community wants this
subsystem to go.
>>
>> Do we see this as a chicken and egg situation, or is there any harm
>> beyond the pains of supporting an out-of-tree driver for a while, to
>> wait until we have at least one other TEE to add to this subsystem
>> before merging?
>
> This proposal is the bare minimum to have something useful. On top of
> this there's more things we'd like to add, for example an in-kernel API
> for accessing the TEE and secure buffer handling. The way we're dealing
> with shared memory need to be improved to better support multiple guests
> communicating with one TEE.
>
> What we can do now with the subsystem now is somewhat limited by the
> fact that we're trying to upstream it and want to do that it in
> manageable increments.
>
Fair enough.
For now this series is being used in our production SDKs so it has at
least some basic testing from us, so for the whole series:
Tested-by: Andrew F. Davis <afd@ti.com>
> Thanks,
> Jens
>
>>
>> This may also help with the perceived lack of reviewers for this series.
>>
>> Thanks,
>> Andrew
>>
>>> "tee: generic TEE subsystem" brings in the generic TEE subsystem which
>>> helps when writing a driver for a specific TEE, for example, OP-TEE.
>>>
>>> "tee: add OP-TEE driver" is an OP-TEE driver which uses the subsystem to do
>>> its work.
>>>
>>> This patch set has been prepared in cooperation with Javier González who
>>> proposed "Generic TrustZone Driver in Linux Kernel" patches 28 Nov 2014,
>>> https://lwn.net/Articles/623380/ . We've since then changed the scope to
>>> TEE instead of TrustZone.
>>>
>>> We have discussed the design on tee-dev@lists.linaro.org (archive at
>>> https://lists.linaro.org/pipermail/tee-dev/) with people from other
>>> companies, including Valentin Manea <valentin.manea@huawei.com>,
>>> Emmanuel MICHEL <emmanuel.michel@st.com>,
>>> Jean-michel DELORME <jean-michel.delorme@st.com>,
>>> and Joakim Bech <joakim.bech@linaro.org>. Our main concern has been to
>>> agree on something that is generic enough to support many different
>>> TEEs while still keeping the interface together.
>>>
>>> v12-resend:
>>> * Rebased on v4.9-rc2
>>>
>>> v12:
>>> * Rebased on v4.8-rc5
>>> * Addressed review comments from Andrew F. Davis
>>> * Removed Acked-by: Andreas Dannenberg <dannenberg@ti.com> as the
>>> mail bounces
>>> * Bugfix possible null dereference in error cleanup path of
>>> optee_probe().
>>> * Bugfix optee_from_msg_param() when calculating offset of memref
>>> into a shared memory object
>>>
>>> v11:
>>> * Rebased on v4.8-rc3
>>> * Addressed review comments from Nishanth Menon
>>> * Made the TEE framework available as a loadable module.
>>> * Reviewed-by: Javier González <javier@javigon.com>
>>> * Zeroes shared memory on allocation to avoid information leakage
>>> * Links shared memory objects to context to avoid stealing of shared memory
>>> object from an unrelated process
>>> * Allow RPC interruption if supplicant is unavailable
>>>
>>> v10:
>>> * Rebased on v4.7-rc1
>>> * Addressed private review comments from Nishanth Menon
>>> * Optee driver only accepts one supplicant process on the privileged device
>>> * Optee driver avoids long delayed releases of shm objects
>>> * Added more comments on functions and structs
>>>
>>> v9:
>>> * Rebased on v4.6-rc1
>>> * Acked-by: Andreas Dannenberg <dannenberg@ti.com>
>>> * Addressed comments from Al Viro how file descriptors are passed to
>>> user space
>>> * Addressed comments from Randy Dunlap on documentation
>>> * Changed license for include/uapi/linux/tee.h
>>>
>>> v8:
>>> * Rebased on v4.5-rc3
>>> * dt/bindings: add bindings for optee
>>> Acked-by: Rob Herring <robh@kernel.org>
>>> * Fixes build error for X86
>>> * Fixes spell error in "dt/bindings: add bindings for optee"
>>>
>>> v7:
>>> * Rebased on v4.5-rc2
>>> * Moved the ARM SMC Calling Convention support into a separate patch
>>> set, which is now merged
>>>
>>> v6:
>>> * Rebased on v4.3-rc7
>>> * Changed smccc interface to let the compiler marshal most of the
>>> parameters
>>> * Added ARCH64 capability for smccc interface
>>> * Changed the PSCI firmware calls (both arm and arm64) to use the new
>>> generic smccc interface instead instead of own assembly functions.
>>> * Move optee DT bindings to below arm/firmware
>>> * Defines method for OP-TEE driver to call secure world in DT, smc or hvc
>>> * Exposes implementation id of a TEE driver in sysfs
>>> to easily spawn corresponding tee-supplicant when device is ready
>>> * Update OP-TEE Message Protocol to better cope with fragmented physical
>>> memory
>>> * Read time directly from OP-TEE driver instead of forwarding the RPC
>>> request to tee-supplicant
>>>
>>> v5:
>>> * Replaced kref reference counting for the device with a size_t instead as
>>> the counter is always protected by a mutex
>>>
>>> v4:
>>> * Rebased on 4.1
>>> * Redesigned the synchronization around entry exit of normal SMC
>>> * Replaced rwsem on the driver instance with kref and completion since
>>> rwsem wasn't intended to be used in this way
>>> * Expanded the TEE_IOCTL_PARAM_ATTR_TYPE_MASK to make room for
>>> future additional parameter types
>>> * Documents TEE subsystem and OP-TEE driver
>>> * Replaced TEE_IOC_CMD with TEE_IOC_OPEN_SESSION, TEE_IOC_INVOKE,
>>> TEE_IOC_CANCEL and TEE_IOC_CLOSE_SESSION
>>> * DT bindings in a separate patch
>>> * Assembly parts moved to arch/arm and arch/arm64 respectively, in a
>>> separate patch
>>> * Redefined/clarified the meaning of OPTEE_SMC_SHM_CACHED
>>> * Removed CMA usage to limit the scope of the patch set
>>>
>>> v3:
>>> * Rebased on 4.1-rc3 (dma_buf_export() API change)
>>> * A couple of small sparse fixes
>>> * Documents bindings for OP-TEE driver
>>> * Updated MAINTAINERS
>>>
>>> v2:
>>> * Replaced the stubbed OP-TEE driver with a real OP-TEE driver
>>> * Removed most APIs not needed by OP-TEE in current state
>>> * Update Documentation/ioctl/ioctl-number.txt with correct path to tee.h
>>> * Rename tee_shm_pool_alloc_cma() to tee_shm_pool_alloc()
>>> * Moved tee.h into include/uapi/linux/
>>> * Redefined tee.h IOCTL macros to be directly based on _IOR and friends
>>> * Removed version info on the API to user space, a data blob which
>>> can contain an UUID is left for user space to be able to tell which
>>> protocol to use in TEE_IOC_CMD
>>> * Changed user space exposed structures to only have types with __ prefix
>>> * Dropped THIS_MODULE from tee_fops
>>> * Reworked how the driver is registered and ref counted:
>>> - moved from using an embedded struct miscdevice to an embedded struct
>>> device.
>>> - uses an struct rw_semaphore as synchronization for driver detachment
>>> - uses alloc/register pattern from TPM
>>>
>>> Thanks,
>>> Jens
>>>
>>> Jens Wiklander (4):
>>> dt/bindings: add bindings for optee
>>> tee: generic TEE subsystem
>>> tee: add OP-TEE driver
>>> Documentation: tee subsystem and op-tee driver
>>>
>>> Documentation/00-INDEX | 2 +
>>> .../bindings/arm/firmware/linaro,optee-tz.txt | 31 +
>>> .../devicetree/bindings/vendor-prefixes.txt | 1 +
>>> Documentation/ioctl/ioctl-number.txt | 1 +
>>> Documentation/tee.txt | 118 +++
>>> MAINTAINERS | 13 +
>>> drivers/Kconfig | 2 +
>>> drivers/Makefile | 1 +
>>> drivers/tee/Kconfig | 18 +
>>> drivers/tee/Makefile | 5 +
>>> drivers/tee/optee/Kconfig | 7 +
>>> drivers/tee/optee/Makefile | 5 +
>>> drivers/tee/optee/call.c | 435 ++++++++++
>>> drivers/tee/optee/core.c | 598 ++++++++++++++
>>> drivers/tee/optee/optee_msg.h | 435 ++++++++++
>>> drivers/tee/optee/optee_private.h | 185 +++++
>>> drivers/tee/optee/optee_smc.h | 446 ++++++++++
>>> drivers/tee/optee/rpc.c | 404 +++++++++
>>> drivers/tee/optee/supp.c | 273 +++++++
>>> drivers/tee/tee_core.c | 901 +++++++++++++++++++++
>>> drivers/tee/tee_private.h | 129 +++
>>> drivers/tee/tee_shm.c | 357 ++++++++
>>> drivers/tee/tee_shm_pool.c | 158 ++++
>>> include/linux/tee_drv.h | 278 +++++++
>>> include/uapi/linux/tee.h | 403 +++++++++
>>> 25 files changed, 5206 insertions(+)
>>> create mode 100644 Documentation/devicetree/bindings/arm/firmware/linaro,optee-tz.txt
>>> create mode 100644 Documentation/tee.txt
>>> create mode 100644 drivers/tee/Kconfig
>>> create mode 100644 drivers/tee/Makefile
>>> create mode 100644 drivers/tee/optee/Kconfig
>>> create mode 100644 drivers/tee/optee/Makefile
>>> create mode 100644 drivers/tee/optee/call.c
>>> create mode 100644 drivers/tee/optee/core.c
>>> create mode 100644 drivers/tee/optee/optee_msg.h
>>> create mode 100644 drivers/tee/optee/optee_private.h
>>> create mode 100644 drivers/tee/optee/optee_smc.h
>>> create mode 100644 drivers/tee/optee/rpc.c
>>> create mode 100644 drivers/tee/optee/supp.c
>>> create mode 100644 drivers/tee/tee_core.c
>>> create mode 100644 drivers/tee/tee_private.h
>>> create mode 100644 drivers/tee/tee_shm.c
>>> create mode 100644 drivers/tee/tee_shm_pool.c
>>> create mode 100644 include/linux/tee_drv.h
>>> create mode 100644 include/uapi/linux/tee.h
>>>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [RFC PATCH 01/13] pinctrl: meson: Add GXL pinctrl definitions
From: Kevin Hilman @ 2016-10-31 18:23 UTC (permalink / raw)
To: Neil Armstrong
Cc: Linus Walleij, Carlo Caione, linux-gpio@vger.kernel.org,
devicetree@vger.kernel.org, linux-arm-kernel@lists.infradead.org,
open list:ARM/Amlogic Meson..., linux-kernel@vger.kernel.org,
netdev@vger.kernel.org
In-Reply-To: <b80010f7-196a-abeb-e4a2-5009f3b7f13b-rdvid1DuHRBWk0Htik3J/w@public.gmane.org>
Neil Armstrong <narmstrong-rdvid1DuHRBWk0Htik3J/w@public.gmane.org> writes:
> On 10/24/2016 03:03 AM, Linus Walleij wrote:
>> On Fri, Oct 21, 2016 at 4:40 PM, Neil Armstrong <narmstrong-rdvid1DuHRBWk0Htik3J/w@public.gmane.org> wrote:
>>
>>> Add support for the Amlogic Meson GXL SoC, this is a partially complete
>>> definition only based on the Amlogic Vendor tree.
>>>
>>> This definition differs a lot from the GXBB and needs a separate entry.
>>>
>>> Signed-off-by: Neil Armstrong <narmstrong-rdvid1DuHRBWk0Htik3J/w@public.gmane.org>
>>
>> Looks good to me. Tell me when I may apply it, it looks orthogonal
>> to the rest of the patches.
>>
>> Yours,
>> Linus Walleij
>>
>
> Hi Linus,
>
> I'm ok to have it applied as soon as possible, but I can send a clean non-rfc patch if needed.
>
Acked-by: Kevin Hilman <khilman-rdvid1DuHRBWk0Htik3J/w@public.gmane.org>
I was hoping to have a bit clearer info from the vendor, but based on
vendor BSP, I think we have most of the info, and can do the minor
fixups if/when we get detailed documentation.
Kevin
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH 2/2] ARM: bus: da8xx-mstpri: new driver
From: Kevin Hilman @ 2016-10-31 18:22 UTC (permalink / raw)
To: Sekhar Nori
Cc: Bartosz Golaszewski, Rob Herring, Michael Turquette, Frank Rowand,
Mark Rutland, Peter Ujfalusi, Russell King, LKML, arm-soc,
linux-drm, linux-devicetree, Jyri Sarha, Tomi Valkeinen,
David Airlie, Laurent Pinchart
In-Reply-To: <0d5d1e41-b8e6-5d60-6da1-5b6ddd9bc07e-l0cyMroinI0@public.gmane.org>
Sekhar Nori <nsekhar-l0cyMroinI0@public.gmane.org> writes:
> On Monday 31 October 2016 03:24 PM, Bartosz Golaszewski wrote:
>> 2016-10-31 10:52 GMT+01:00 Sekhar Nori <nsekhar-l0cyMroinI0@public.gmane.org>:
>>> Hi Bartosz,
>>>
>>> On Monday 31 October 2016 03:10 PM, Bartosz Golaszewski wrote:
>>>> 2016-10-31 5:30 GMT+01:00 Rob Herring <robh-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>:
>>>>> On Wed, Oct 26, 2016 at 07:35:55PM +0200, Bartosz Golaszewski wrote:
>>>>>> Create the driver for the da8xx master peripheral priority
>>>>>> configuration and implement support for writing to the three
>>>>>> Master Priority registers on da850 SoCs.
>>>>>>
>>>>>> Signed-off-by: Bartosz Golaszewski <bgolaszewski-rdvid1DuHRBWk0Htik3J/w@public.gmane.org>
>>>>>> ---
>>>>>> .../devicetree/bindings/bus/ti,da850-mstpri.txt | 20 ++
>>>>>> drivers/bus/Kconfig | 9 +
>>>>>> drivers/bus/Makefile | 2 +
>>>>>> drivers/bus/da8xx-mstpri.c | 266 +++++++++++++++++++++
>>>>>> 4 files changed, 297 insertions(+)
>>>>>> create mode 100644 Documentation/devicetree/bindings/bus/ti,da850-mstpri.txt
>>>>>> create mode 100644 drivers/bus/da8xx-mstpri.c
>>>>>>
>>>>>> diff --git a/Documentation/devicetree/bindings/bus/ti,da850-mstpri.txt b/Documentation/devicetree/bindings/bus/ti,da850-mstpri.txt
>>>>>> new file mode 100644
>>>>>> index 0000000..225af09
>>>>>> --- /dev/null
>>>>>> +++ b/Documentation/devicetree/bindings/bus/ti,da850-mstpri.txt
>>>>>> @@ -0,0 +1,20 @@
>>>>>> +* Device tree bindings for Texas Instruments da8xx master peripheral
>>>>>> + priority driver
>>>>>> +
>>>>>> +DA8XX SoCs feature a set of registers allowing to change the priority of all
>>>>>> +peripherals classified as masters.
>>>>>> +
>>>>>> +Documentation:
>>>>>> +OMAP-L138 (DA850) - http://www.ti.com/lit/ug/spruh82c/spruh82c.pdf
>>>>>> +
>>>>>> +Required properties:
>>>>>> +
>>>>>> +- compatible: "ti,da850-mstpri", "syscon" - for da850 based boards
>>>>>
>>>>> Drop syscon. Doesn't look like it is needed and the example doesn't
>>>>> match.
>>>>
>>>> Hi Rob,
>>>>
>>>> it is needed: syscon_regmap_lookup_by_compatible() fails without it. I
>>>> fixed the example instead.
>>>
>>> Why are master priority registers under syscon? This driver should be
>>> the only entity touching them. So do we need an MFD driver?
>>>
>>
>> It should, but syscfg0 registers are mapped all over the place. I
>
> Not sure what you mean by this. Yes, the sysconfig module has many
> functionalities. But the registers for a given functionality are all
> grouped together AFAICS (except CHIPCFGn, see below).
>
> Pinmux registers are part of syscfg module, but don't use syscon.
>
> In the work going on for OHCI support, chipcfg registers are being put
> under a syscon node. But that makes sense, I think, because chipcfg
> registers are catering to really diverse functionality like PLL and EDMA
> related stuff being placed in the same register - CHIPCFG0.
>
>> thought it would be safer to put them under syscon and Kevin agreed.
>
> Before using syscon for the whole syscfg space, I think we need some
> analysis as to where the likely races are going to be.
I'm OK with that for now. It makes the most sense to use sycon only for
the register (ranges) that will actually be shared.
Kevin
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCHv2 1/4] dt-bindings: mfd: Add Altera Arria10 SR Monitor
From: Rob Herring @ 2016-10-31 18:22 UTC (permalink / raw)
To: Thor Thayer
Cc: Lee Jones, Mark Rutland, Dinh Nguyen, Russell King, Arnd Bergmann,
Greg Kroah-Hartman, David Miller, Geert Uytterhoeven,
devicetree@vger.kernel.org, linux-kernel@vger.kernel.org,
linux-arm-kernel@lists.infradead.org
In-Reply-To: <895cf1ec-929a-8c41-c74a-948efcb89222@opensource.altera.com>
On Mon, Oct 31, 2016 at 10:28 AM, Thor Thayer
<tthayer@opensource.altera.com> wrote:
> Hi Rob,
>
> On 10/31/2016 12:36 AM, Rob Herring wrote:
>>
>> On Thu, Oct 27, 2016 at 03:00:23PM -0500, tthayer@opensource.altera.com
>> wrote:
>>>
>>> From: Thor Thayer <tthayer@opensource.altera.com>
>>>
>>> Add the Arria10 DevKit System Resource Chip register and state
>>> monitoring module to the MFD.
>>>
>>> Signed-off-by: Thor Thayer <tthayer@opensource.altera.com>
>>> ---
>>> Note: This needs to be applied to the bindings document that
>>> was Acked & Applied but didn't reach the for-next branch.
>>> See https://patchwork.ozlabs.org/patch/629397/
>>> ---
>>> v2 Change compatible string -mon to -monitor for clarity
>>> ---
>>> Documentation/devicetree/bindings/mfd/altera-a10sr.txt | 9 +++++++++
>>> 1 file changed, 9 insertions(+)
>>>
>>> diff --git a/Documentation/devicetree/bindings/mfd/altera-a10sr.txt
>>> b/Documentation/devicetree/bindings/mfd/altera-a10sr.txt
>>> index ea151f2..c47be28 100644
>>> --- a/Documentation/devicetree/bindings/mfd/altera-a10sr.txt
>>> +++ b/Documentation/devicetree/bindings/mfd/altera-a10sr.txt
>>> @@ -18,6 +18,7 @@ The A10SR consists of these sub-devices:
>>> Device Description
>>> ------ ----------
>>> a10sr_gpio GPIO Controller
>>
>>
>> This should be just "gpio" BTW.
>
>
> I reason I preprend a10sr_ is to distinguish this GPIO from the other GPIOs
> when binding to our LEDs (see below). I think the LEDs need a unique node
> name (unless I'm not understanding something).
You are confusing DTS labels and node names. Labels are global and
just convenience for the DTS source only instead of using full paths
(and can be anything you want). The node name is local to the level it
is at.
> A less important reason I use a10sr_gpio on the node name is that I can cat
> the /sys/class/gpio/gpioxxx/label and see that it is associated with the
> a10sr instead of one of our other general GPIOs. Is there a better way to
> distinguish these?
label should come from the label property I think. This is one of the
problems with the GPIO sysfs interface and why it is being replaced
with the char dev interface.
Rob
>
>>
>>> +a10sr_monitor Register and State Monitoring
>>
>>
>> s/_/-/ or maybe just "monitor". Not really a generic node name to use
>> for this.
>>
>
> The reason I use _ for the node name is that the DTC fails if I reference a
> node name with "-" but works OK for "_". For instance, I get an error if the
> LEDs reference "a10sr-gpio" but "a10sr_gpio" compiles ok.
Again, I'm talking node names. You are talking labels. And yes, DTS
labels can't use '-'.
Rob
^ permalink raw reply
* Re: [PATCH] clk: cdce925: add support for CDCE913, CDCE937, and CDCE949
From: Stephen Boyd @ 2016-10-31 18:15 UTC (permalink / raw)
To: Akinobu Mita
Cc: linux-clk-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA, Mike Looijmans,
Michael Turquette
In-Reply-To: <1477848637-5151-1-git-send-email-akinobu.mita-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
On 10/31, Akinobu Mita wrote:
> @@ -582,13 +615,19 @@ static int cdce925_probe(struct i2c_client *client,
> struct clk_cdce925_chip *data;
> struct device_node *node = client->dev.of_node;
> const char *parent_name;
> - const char *pll_clk_name[NUMBER_OF_PLLS] = {NULL,};
> + const char *pll_clk_name[MAX_NUMBER_OF_PLLS] = {NULL,};
> struct clk_init_data init;
> u32 value;
> int i;
> int err;
> struct device_node *np_output;
> char child_name[6];
> + struct regmap_config cdce925_regmap_config = {
Maybe just call this config because it's a local variable now.
> + .name = "configuration0",
> + .reg_bits = 8,
> + .val_bits = 8,
> + .cache_type = REGCACHE_RBTREE,
> + };
>
> dev_dbg(&client->dev, "%s\n", __func__);
> data = devm_kzalloc(&client->dev, sizeof(*data), GFP_KERNEL);
> @@ -596,6 +635,9 @@ static int cdce925_probe(struct i2c_client *client,
> return -ENOMEM;
>
> data->i2c_client = client;
> + data->chip_info = &clk_cdce925_chip_info_tbl[id->driver_data];
> + cdce925_regmap_config.max_register = CDCE925_OFFSET_PLL +
> + data->chip_info->num_plls * 0x10 - 1;
> data->regmap = devm_regmap_init(&client->dev, ®map_cdce925_bus,
> &client->dev, &cdce925_regmap_config);
> if (IS_ERR(data->regmap)) {
> @@ -728,13 +780,19 @@ static int cdce925_probe(struct i2c_client *client,
> }
>
> static const struct i2c_device_id cdce925_id[] = {
> - { "cdce925", 0 },
> + { "cdce913", CDCE913 },
> + { "cdce925", CDCE925 },
> + { "cdce937", CDCE937 },
> + { "cdce949", CDCE949 },
> { }
> };
> MODULE_DEVICE_TABLE(i2c, cdce925_id);
>
> static const struct of_device_id clk_cdce925_of_match[] = {
> + { .compatible = "ti,cdce913" },
> { .compatible = "ti,cdce925" },
> + { .compatible = "ti,cdce937" },
> + { .compatible = "ti,cdce949" },
Doesn't this need to be updated to point to the correct enum
values?
> { },
--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH v3 3/3] clocksource: Add clockevent support to NPS400 driver
From: Thomas Gleixner @ 2016-10-31 18:12 UTC (permalink / raw)
To: Noam Camus
Cc: robh+dt-DgEjT+Ai2ygdnm+yROfE0A, mark.rutland-5wv7dgnIgG8,
daniel.lezcano-QSEj5FYQhm4dnm+yROfE0A,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <1477899468-5494-4-git-send-email-noamca-VPRAkNaXOzVWk0Htik3J/w@public.gmane.org>
On Mon, 31 Oct 2016, Noam Camus wrote:
>
> -static unsigned long nps_timer_rate;
> +static unsigned long nps_timer1_freq;
This should be either in the previous patch or seperate.
> static int nps_get_timer_clk(struct device_node *node,
> unsigned long *timer_freq,
> struct clk *clk)
> @@ -87,10 +87,10 @@ static int __init nps_setup_clocksource(struct device_node *node)
> nps_host_reg((cluster << NPS_CLUSTER_OFFSET),
> NPS_MSU_BLKID, NPS_MSU_TICK_LOW);
>
> - nps_get_timer_clk(node, &nps_timer_rate, clk);
> + nps_get_timer_clk(node, &nps_timer1_freq, clk);
>
> - ret = clocksource_mmio_init(nps_msu_reg_low_addr, "EZnps-tick",
> - nps_timer_rate, 301, 32, nps_clksrc_read);
> + ret = clocksource_mmio_init(nps_msu_reg_low_addr, "nps-tick",
> + nps_timer1_freq, 301, 32, nps_clksrc_read);
> if (ret) {
> pr_err("Couldn't register clock source.\n");
> clk_disable_unprepare(clk);
> @@ -101,3 +101,215 @@ static int __init nps_setup_clocksource(struct device_node *node)
>
> CLOCKSOURCE_OF_DECLARE(ezchip_nps400_clksrc, "ezchip,nps400-timer",
> nps_setup_clocksource);
> +CLOCKSOURCE_OF_DECLARE(ezchip_nps400_clk_src, "ezchip,nps400-timer1",
> + nps_setup_clocksource);
What's the point of this change?
> +/*
> + * Arm the timer to interrupt after @cycles
> + */
> +static void nps_clkevent_timer_event_setup(unsigned int cycles)
> +{
> + write_aux_reg(NPS_REG_TIMER0_LIMIT, cycles);
> + write_aux_reg(NPS_REG_TIMER0_CNT, 0); /* start from 0 */
Please do not use tail comments. They break the reading flow.
> +
> + write_aux_reg(NPS_REG_TIMER0_CTRL, TIMER0_CTRL_IE | TIMER0_CTRL_NH);
> +}
> +
> +static void nps_clkevent_rm_thread(bool remove_thread)
I have a hard time to understand why a remove_thread function needs a
remove_thread boolean argument. Commenting things like this would be more
helpful than commenting the obvious.
> +{
> + unsigned int cflags;
> + unsigned int enabled_threads;
> + unsigned long flags;
> + int thread;
> +
> + local_irq_save(flags);
That's pointless. Both call sites have interrupts disabled.
> + hw_schd_save(&cflags);
> +
> + enabled_threads = read_aux_reg(AUX_REG_TIMER0_TSI);
> +
> + /* remove thread from TSI1 */
> + if (remove_thread) {
> + thread = read_aux_reg(CTOP_AUX_THREAD_ID);
> + enabled_threads &= ~(1 << thread);
> + write_aux_reg(AUX_REG_TIMER0_TSI, enabled_threads);
> + }
> +
> + /* Re-arm the timer if needed */
> + if (!enabled_threads)
> + write_aux_reg(NPS_REG_TIMER0_CTRL, TIMER0_CTRL_NH);
> + else
> + write_aux_reg(NPS_REG_TIMER0_CTRL,
> + TIMER0_CTRL_IE | TIMER0_CTRL_NH);
> +
> + hw_schd_restore(cflags);
> + local_irq_restore(flags);
> +}
> +
> +static void nps_clkevent_add_thread(bool set_event)
> +{
> + int thread;
> + unsigned int cflags, enabled_threads;
> + unsigned long flags;
> +
> + local_irq_save(flags);
Ditto.
> + hw_schd_save(&cflags);
> +
> + /* add thread to TSI1 */
> + thread = read_aux_reg(CTOP_AUX_THREAD_ID);
> + enabled_threads = read_aux_reg(AUX_REG_TIMER0_TSI);
> + enabled_threads |= (1 << thread);
> + write_aux_reg(AUX_REG_TIMER0_TSI, enabled_threads);
> +
> + /* set next timer event */
> + if (set_event)
> + write_aux_reg(NPS_REG_TIMER0_CTRL,
> + TIMER0_CTRL_IE | TIMER0_CTRL_NH);
> +
> + hw_schd_restore(cflags);
> + local_irq_restore(flags);
> +}
> +
> +static int nps_clkevent_set_next_event(unsigned long delta,
> + struct clock_event_device *dev)
> +{
> + struct irq_desc *desc = irq_to_desc(nps_timer0_irq);
> + struct irq_chip *chip = irq_data_get_irq_chip(&desc->irq_data);
> +
> + nps_clkevent_add_thread(true);
> + chip->irq_unmask(&desc->irq_data);
Oh no. You are not supposed to fiddle in the guts of the interrupts from a
random driver. Can you please explain what you are trying to do and why the
existing interfaces are not sufficient?
> +/*
> + * Whenever anyone tries to change modes, we just mask interrupts
> + * and wait for the next event to get set.
> + */
> +static int nps_clkevent_timer_shutdown(struct clock_event_device *dev)
> +{
> + struct irq_desc *desc = irq_to_desc(nps_timer0_irq);
> + struct irq_chip *chip = irq_data_get_irq_chip(&desc->irq_data);
> +
> + chip->irq_mask(&desc->irq_data);
> +
> + return 0;
> +}
> +
> +static int nps_clkevent_set_periodic(struct clock_event_device *dev)
> +{
> + nps_clkevent_add_thread(false);
> + if (read_aux_reg(CTOP_AUX_THREAD_ID) == 0)
> + nps_clkevent_timer_event_setup(nps_timer0_freq / HZ);
So how is that enabling interrupts again?
> +
> + return 0;
> +}
> +
> +static DEFINE_PER_CPU(struct clock_event_device, nps_clockevent_device) = {
> + .name = "NPS Timer0",
> + .features = CLOCK_EVT_FEAT_ONESHOT |
> + CLOCK_EVT_FEAT_PERIODIC,
> + .rating = 300,
> + .set_next_event = nps_clkevent_set_next_event,
> + .set_state_periodic = nps_clkevent_set_periodic,
> + .set_state_oneshot = nps_clkevent_set_oneshot,
> + .set_state_oneshot_stopped = nps_clkevent_timer_shutdown,
> + .set_state_shutdown = nps_clkevent_timer_shutdown,
> + .tick_resume = nps_clkevent_timer_shutdown,
> +};
> +
> +static irqreturn_t timer_irq_handler(int irq, void *dev_id)
> +{
> + /*
> + * Note that generic IRQ core could have passed @evt for @dev_id if
> + * irq_set_chip_and_handler() asked for handle_percpu_devid_irq()
And why are you not doing that?
> + */
> + struct clock_event_device *evt = this_cpu_ptr(&nps_clockevent_device);
> + int irq_reenable = clockevent_state_periodic(evt);
> +
> + nps_clkevent_rm_thread(!irq_reenable);
> +
> + evt->event_handler(evt);
> +
> + return IRQ_HANDLED;
> +}
> +
> +static int nps_timer_starting_cpu(unsigned int cpu)
> +{
> + struct clock_event_device *evt = this_cpu_ptr(&nps_clockevent_device);
> +
> + evt->cpumask = cpumask_of(smp_processor_id());
> +
> + clockevents_config_and_register(evt, nps_timer0_freq, 0, ULONG_MAX);
> + enable_percpu_irq(nps_timer0_irq, 0);
And at the same time you still use the percpu infrastructure ....
> + return 0;
> +}
> +
> +static int nps_timer_dying_cpu(unsigned int cpu)
> +{
> + disable_percpu_irq(nps_timer0_irq);
> + return 0;
> +}
> +
> +static int __init nps_setup_clockevent(struct device_node *node)
> +{
> + struct clock_event_device *evt = this_cpu_ptr(&nps_clockevent_device);
> + struct clk *clk;
> + int ret;
> +
> + nps_timer0_irq = irq_of_parse_and_map(node, 0);
> + if (nps_timer0_irq <= 0) {
> + pr_err("clockevent: missing irq");
> + return -EINVAL;
> + }
> +
> + nps_get_timer_clk(node, &nps_timer0_freq, clk);
> +
> + /* Needs apriori irq_set_percpu_devid() done in intc map function */
> + ret = request_percpu_irq(nps_timer0_irq, timer_irq_handler,
> + "Timer0 (per-cpu-tick)", evt);
This is wrong. the dev_id argument wants to be a __per_cpu pointer. So it
should be &nps_clockevent_device and not a pointer to the cpu local one.
> + if (ret) {
> + pr_err("Couldn't request irq\n");
> + clk_disable_unprepare(clk);
> + return ret;
> + }
> +
> + ret = cpuhp_setup_state(CPUHP_AP_NPS_TIMER_STARTING,
> + "AP_NPS_TIMER_STARTING",
Please make this "clockevents/nps:starting"
> + nps_timer_starting_cpu,
> + nps_timer_dying_cpu);
> + if (ret) {
> + pr_err("Failed to setup hotplug state");
> + clk_disable_unprepare(clk);
You leave the irq requested....
Thanks,
tglx
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH] ARM: BCM5301X: Add back handler ignoring external imprecise aborts
From: Scott Branden @ 2016-10-31 18:08 UTC (permalink / raw)
To: Rafał Miłecki, Florian Fainelli, linux-arm-kernel
Cc: Arnd Bergmann, Bjorn Helgaas, Lucas Stach, Hauke Mehrtens,
Jon Mason, Mark Rutland, Ray Jui, Scott Branden,
bcm-kernel-feedback-list, devicetree, linux-pci,
Rafał Miłecki
In-Reply-To: <20161029111229.26875-1-zajec5@gmail.com>
Hi Rafal,
On 16-10-29 04:12 AM, Rafał Miłecki wrote:
> From: Rafał Miłecki <rafal@milecki.pl>
>
> Since early BCM5301X days we got abort handler that was removed by
> commit 937b12306ea79 ("ARM: BCM5301X: remove workaround imprecise abort
> fault handler"). It assumed we need to deal only with pending aborts
> left by the bootloader. Unfortunately this isn't true for BCM5301X.
>
> When probing PCI config space (device enumeration) it is expected to
> have master aborts on the PCI bus. Most bridges don't forward (or they
> allow disabling it) these errors onto the AXI/AMBA bus but not the
> Northstar (BCM5301X) one.
Should we only add this workaround code if CONFIG_PCI is on then?
>
> iProc PCIe controller on Northstar seems to be some older one, without
> a control register for errors forwarding. It means we need to workaround
> this at platform level. All newer platforms are not affected by this
> issue.
>
> Signed-off-by: Rafał Miłecki <rafal@milecki.pl>
> ---
> arch/arm/mach-bcm/bcm_5301x.c | 28 ++++++++++++++++++++++++++++
> 1 file changed, 28 insertions(+)
>
> diff --git a/arch/arm/mach-bcm/bcm_5301x.c b/arch/arm/mach-bcm/bcm_5301x.c
> index c8830a2..fe067f6 100644
> --- a/arch/arm/mach-bcm/bcm_5301x.c
> +++ b/arch/arm/mach-bcm/bcm_5301x.c
> @@ -9,14 +9,42 @@
> #include <asm/hardware/cache-l2x0.h>
>
> #include <asm/mach/arch.h>
> +#include <asm/siginfo.h>
> +#include <asm/signal.h>
> +
> +#define FSR_EXTERNAL (1 << 12)
> +#define FSR_READ (0 << 10)
> +#define FSR_IMPRECISE 0x0406
>
> static const char *const bcm5301x_dt_compat[] __initconst = {
> "brcm,bcm4708",
> NULL,
> };
>
> +static int bcm5301x_abort_handler(unsigned long addr, unsigned int fsr,
> + struct pt_regs *regs)
> +{
> + /*
> + * We want to ignore aborts forwarded from the PCIe bus that are
> + * expected and shouldn't really be passed by the PCIe controller.
> + * The biggest disadvantage is the same FSR code may be reported when
> + * reading non-existing APB register and we shouldn't ignore that.
> + */
> + if (fsr == (FSR_EXTERNAL | FSR_READ | FSR_IMPRECISE))
> + return 0;
> +
> + return 1;
> +}
> +
> +static void __init bcm5301x_init_early(void)
> +{
> + hook_fault_code(16 + 6, bcm5301x_abort_handler, SIGBUS, BUS_OBJERR,
> + "imprecise external abort");
> +}
> +
> DT_MACHINE_START(BCM5301X, "BCM5301X")
> .l2c_aux_val = 0,
> .l2c_aux_mask = ~0,
> .dt_compat = bcm5301x_dt_compat,
> + .init_early = bcm5301x_init_early,
> MACHINE_END
>
Regards,
Scott
^ permalink raw reply
* Re: [PATCH v14 1/4] clk: mediatek: Add MT2701 clock support
From: Stephen Boyd @ 2016-10-31 18:06 UTC (permalink / raw)
To: James Liao
Cc: Erin Lo, Matthias Brugger, Mike Turquette, Rob Herring,
Arnd Bergmann, Sascha Hauer, Daniel Kurtz, Philipp Zabel,
devicetree, linux-arm-kernel, linux-kernel, linux-mediatek,
linux-clk, srv_heupstream, ms.chen, robert.chou, Shunli Wang
In-Reply-To: <1477896558.5376.13.camel@mtksdaap41>
On 10/31, James Liao wrote:
> On Thu, 2016-10-27 at 18:17 -0700, Stephen Boyd wrote:
> > On 10/21, Erin Lo wrote:
> > > @@ -244,3 +256,31 @@ void mtk_clk_register_composites(const struct mtk_composite *mcs,
> > > clk_data->clks[mc->id] = clk;
> > > }
> > > }
> > > +
> > > +void mtk_clk_register_dividers(const struct mtk_clk_divider *mcds,
> > > + int num, void __iomem *base, spinlock_t *lock,
> > > + struct clk_onecell_data *clk_data)
> > > +{
> > > + struct clk *clk;
> > > + int i;
> > > +
> > > + for (i = 0; i < num; i++) {
> > > + const struct mtk_clk_divider *mcd = &mcds[i];
> > > +
> > > + if (clk_data && !IS_ERR_OR_NULL(clk_data->clks[mcd->id]))
> >
> > NULL is a valid clk. IS_ERR_OR_NULL is usually wrong.
>
> Why NULL is a valid clk?
Perhaps at some point we'll want to return a NULL pointer to
clk_get() callers so that they can handle things like optional
clocks easily without having any storage requirements. I don't
know if we'll ever do that, but that's just a possibility.
>
> clk_data is designed for multiple initialization from different clock
> types, such as infra_clk_data in clk-mt2701.c. So it will ignore valid
> clocks to avoid duplicated clock registration. Here I assume a clock
> pointer with error code or NULL to be an invalid (not initialized)
> clock.
>
Ok. Would it be possible to initialize the array with all error
pointers? That would make things less error prone, but it
probably doesn't matter at all anyway because this is done during
registration time. IS_ERR_OR_NULL makes me take a second look
each time, because it's usually wrong.
--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
^ permalink raw reply
* Re: [PATCH V2 2/2] ARM: dts: bcm283x: fix typo in mailbox address
From: Eric Anholt @ 2016-10-31 18:06 UTC (permalink / raw)
To: Mark Rutland, Rob Herring, Stephen Warren
Cc: devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-rpi-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
afaerber-l3A5Bk7waGM, Stefan Wahren
In-Reply-To: <1477848139-32267-1-git-send-email-stefan.wahren-eS4NqCHxEME@public.gmane.org>
[-- Attachment #1: Type: text/plain, Size: 439 bytes --]
Stefan Wahren <stefan.wahren-eS4NqCHxEME@public.gmane.org> writes:
> The address of the mailbox node in the bcm283x.dtsi also has a typo.
> So fix it accordingly.
>
> Signed-off-by: Stefan Wahren <stefan.wahren-eS4NqCHxEME@public.gmane.org>
> Reviewed-by: Andreas Färber <afaerber-l3A5Bk7waGM@public.gmane.org>
> Fixes: 05b682b7a3b2 ("ARM: bcm2835: dt: Add the mailbox to the device tree")
Pulled to bcm2835-dt-next. Thanks!
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 800 bytes --]
^ permalink raw reply
* Re: [PATCH v2 3/3] clocksource: Add clockevent support to NPS400 driver
From: Vineet Gupta @ 2016-10-31 17:51 UTC (permalink / raw)
To: Noam Camus, Daniel Lezcano
Cc: robh+dt@kernel.org, mark.rutland@arm.com, tglx@linutronix.de,
devicetree@vger.kernel.org, linux-kernel@vger.kernel.org
In-Reply-To: <DB6PR0501MB2518720A0F95ACBBBCB1CB27AAAE0@DB6PR0501MB2518.eurprd05.prod.outlook.com>
Hi Daniel,
On 10/31/2016 10:03 AM, Noam Camus wrote:
>> Oops, wait. Here, arch/arc/kernel/time.c should be moved in drivers/clocksource and consolidated with this driver.
>> >Very likely, CPUHP_AP_ARC_TIMER_STARTING can be used for all ARC timers.
> Indeed the ARC timer driver served as my inspiration but due to HW threads handling they are not the same.
> Moving drivers from arch/arc to driver/clocksource is not my call (Vineet Gupta is the maintainer of ARC)
> And I think they quiet differ now so consolidation gain is not obvious.
Sorry this was on my todo list at low priority. Anyways took a quick look at it now.
The problem is timer code overlaps pure driver land and ARC specific code. e.g.
CONFIG_ARC_HAS_RTC clocksource needs to check whether hardware exists or not. We
currently conveniently check that from cpuinfo populated at boot time. Now either
I need to export that info as a function (which should be done anyways) - but then
define stub for !ARC. Either that or duplicate the detection code here (orig copy
in arc setup.c)
So doing this exercise cleanly would mean exporting much of
arch/arc/include/asm/{arcregs.h, mcip.h} out of ARC into include/soc/arc/*. Isn't
this kind of going back to include/asm-<arch>/* days ?
Honestly I do want to move the driver in the right place but not sure how to do
this cleanly.
Thoughts ?
-Vineet
^ permalink raw reply
* Re: [PATCH v3 2/3] clocksource: update "fn" at CLOCKSOURCE_OF_DECLARE() of nps400 timer
From: Thomas Gleixner @ 2016-10-31 17:39 UTC (permalink / raw)
To: Noam Camus
Cc: robh+dt, mark.rutland, daniel.lezcano, devicetree, linux-kernel
In-Reply-To: <1477899468-5494-3-git-send-email-noamca@mellanox.com>
On Mon, 31 Oct 2016, Noam Camus wrote:
>
> static unsigned long nps_timer_rate;
> +static int nps_get_timer_clk(struct device_node *node,
Please don't glue variables and functions together w/o a new line. That's
horrible to read.
> +static int __init nps_setup_clocksource(struct device_node *node)
> {
> int ret, cluster;
> + struct clk *clk;
>
> for (cluster = 0; cluster < NPS_CLUSTER_NUM; cluster++)
> nps_msu_reg_low_addr[cluster] =
> nps_host_reg((cluster << NPS_CLUSTER_OFFSET),
> NPS_MSU_BLKID, NPS_MSU_TICK_LOW);
>
> - ret = clk_prepare_enable(clk);
> - if (ret) {
> - pr_err("Couldn't enable parent clock\n");
> - return ret;
> - }
> -
> - nps_timer_rate = clk_get_rate(clk);
> + nps_get_timer_clk(node, &nps_timer_rate, clk);
Why are you ignoring the return code? It was handled before your change ...
Thanks,
tglx
^ permalink raw reply
* Re: [PATCH v6] mwifiex: parse device tree node for PCIe
From: Rajat Jain @ 2016-10-31 17:09 UTC (permalink / raw)
To: Rob Herring
Cc: Rajat Jain, linux-wireless-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA, Xinming Hu, Amitkumar Karwar,
Brian Norris, Kalle Valo
In-Reply-To: <20161030204131.pwfjqekpwd6nr3gb@rob-hp-laptop>
On Sun, Oct 30, 2016 at 1:41 PM, Rob Herring <robh-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org> wrote:
> On Fri, Oct 21, 2016 at 02:21:09PM -0700, Rajat Jain wrote:
>> From: Xinming Hu <huxm-eYqpPyKDWXRBDgjK7y7TUQ@public.gmane.org>
>>
>> This patch derives device tree node from pcie bus layer framework, and
>> fixes a minor memory leak in mwifiex_pcie_probe() (in failure path).
>> Device tree bindings file has been renamed(marvell-sd8xxx.txt ->
>> marvell-8xxx.txt) to accommodate PCIe changes.
>>
>> Signed-off-by: Xinming Hu <huxm-eYqpPyKDWXRBDgjK7y7TUQ@public.gmane.org>
>> Signed-off-by: Amitkumar Karwar <akarwar-eYqpPyKDWXRBDgjK7y7TUQ@public.gmane.org>
>> Signed-off-by: Rajat Jain <rajatja-hpIqsD4AKlfQT0dZR+AlfA@public.gmane.org>
>> Reviewed-by: Brian Norris <briannorris-F7+t8E8rja9g9hUCZPvPmw@public.gmane.org>
>> ---
>> v2: Included vendor and product IDs in compatible strings for PCIe
>> chipsets(Rob Herring)
>> v3: Patch is created using -M option so that it will only include diff of
>> original and renamed files(Rob Herring)
>> Resend v3: Resending the patch because I missed to include device tree mailing
>> while sending v3.
>> v4: Fix error handling, also move-on even if no device tree node is present.
>> v5: Update commit log to include memory leak, return -EINVAL instead of -1.
>> v6: Remove an unnecessary error print, fix typo in commit log
>>
>> .../{marvell-sd8xxx.txt => marvell-8xxx.txt} | 8 +++--
>> drivers/net/wireless/marvell/mwifiex/pcie.c | 36 +++++++++++++++++++---
>> drivers/net/wireless/marvell/mwifiex/sta_cmd.c | 3 +-
>> 3 files changed, 39 insertions(+), 8 deletions(-)
>> rename Documentation/devicetree/bindings/net/wireless/{marvell-sd8xxx.txt => marvell-8xxx.txt} (91%)
>>
>> diff --git a/Documentation/devicetree/bindings/net/wireless/marvell-sd8xxx.txt b/Documentation/devicetree/bindings/net/wireless/marvell-8xxx.txt
>> similarity index 91%
>> rename from Documentation/devicetree/bindings/net/wireless/marvell-sd8xxx.txt
>> rename to Documentation/devicetree/bindings/net/wireless/marvell-8xxx.txt
>> index c421aba..dfe5f8e 100644
>> --- a/Documentation/devicetree/bindings/net/wireless/marvell-sd8xxx.txt
>> +++ b/Documentation/devicetree/bindings/net/wireless/marvell-8xxx.txt
>> @@ -1,8 +1,8 @@
>> -Marvell 8897/8997 (sd8897/sd8997) SDIO devices
>> +Marvell 8897/8997 (sd8897/sd8997/pcie8997) SDIO/PCIE devices
>> ------
>>
>> -This node provides properties for controlling the marvell sdio wireless device.
>> -The node is expected to be specified as a child node to the SDIO controller that
>> +This node provides properties for controlling the marvell sdio/pcie wireless device.
>
> s/marvell/Marvell/
> s/sdio\/pcie/SDIO\/PCIE/
>
>> +The node is expected to be specified as a child node to the SDIO/PCIE controller that
>> connects the device to the system.
>>
>> Required properties:
>> @@ -10,6 +10,8 @@ Required properties:
>> - compatible : should be one of the following:
>> * "marvell,sd8897"
>> * "marvell,sd8997"
>> + * "pci11ab,2b42"
>> + * "pci1b4b,2b42"
>
Hi Rob,
> I think I already said this, but you have the vendor and product IDs
> reversed.
Actually Marvell has 2 vendor IDs assigned to it. In include/linux/pci_ids.h:
#define PCI_VENDOR_ID_MARVELL 0x11ab
#define PCI_VENDOR_ID_MARVELL_EXT 0x1b4b
So in this case the compatible property describes a single product ID,
with both possible vendor IDs.
Thanks,
Rajat
>
> Rob
^ permalink raw reply
* Re: [PATCH v2 5/7] [media] ir-lirc-codec: don't wait any transmitting time for tx only devices
From: Sean Young @ 2016-10-31 17:05 UTC (permalink / raw)
To: David Härdeman
Cc: Andi Shyti, Mauro Carvalho Chehab, Rob Herring, Mark Rutland,
linux-media, devicetree, linux-kernel, Andi Shyti
In-Reply-To: <7e2f88ed83c4044c30bc03aaea9f09e1@hardeman.nu>
Hi David, Andi,
On Mon, Oct 31, 2016 at 02:31:52PM +0000, David Härdeman wrote:
> October 27, 2016 4:36 PM, "Sean Young" <sean@mess.org> wrote:
> > Since we have to be able to switch between waiting and not waiting,
> > we need some sort of ABI for this. I think this warrants a new ioctl;
> > I'm not sure how else it can be done. I'll be sending out a patch
> > shortly.
>
> Hi Sean,
>
> have you considered using a module param for the LIRC bridge module instead? As far as I understand it, this is an issue which is entirely internal to LIRC, and it's also not something which really needs to be changed on a per-device level (either you have a modern LIRC daemon or you don't, and all drivers should behave the same, no?).
I still don't see how any of this would change anything for the ir-spi case:
since it uses sync spi transfer, it's going to block anyway.
> Another advantage is that the parameter would then go away if and when the lirc bridge ever goes away (yes, I can still dream, can't I?).
The suggested ioctl is unique to lirc too and would disappear if the
lirc ABI goes away. With a module parameter you would change the lirc ABI
into an incompatible one. Not sure that is what module parameters should
be used for.
Andi, it would be good to know what the use-case for the original change is.
Thanks
Sean
^ permalink raw reply
* Re: [PATCH v4 2/2] fpga: Add support for Lattice iCE40 FPGAs
From: Moritz Fischer @ 2016-10-31 17:04 UTC (permalink / raw)
To: Joel Holdsworth
Cc: Rob Herring, Alan Tull, Devicetree List,
Linux Kernel Mailing List, linux-spi-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <f3c6dac1-bf10-c945-3e8a-9146e07253fd-IJEoVVyKhCJXvIrf17iDB/XRex20P6io@public.gmane.org>
On Mon, Oct 31, 2016 at 9:58 AM, Joel Holdsworth
<joel-IJEoVVyKhCJXvIrf17iDB/XRex20P6io@public.gmane.org> wrote:
> Hi Rob,
>
> Thanks for taking the time review the patches.
>
>>> .../bindings/fpga/lattice-ice40-fpga-mgr.txt | 23 +++
>>
>>
>> It's preferred that bindings are a separate patch.
>
>
> Can you just clarify a little? I'm happy to split the patch up, but I don't
> understand how it could work without the bindings. For example, in
> ice40_fpga_probe, I have to get the GPIOs with devm_gpiod_get for the driver
> to work.
>
> Maybe I'm missing something. Or do you just mean the documentation?
In general, the bindings go in a separate patch, that goes *before*
the code that uses it.
That way you're guaranteed it's there if you apply the series in order.
So [1/2] would be your bindings (ice40-fpga-mgr.txt) and [2/2] would
be your driver.
>
>
>>
>> -gpios is preferred.
>>
>> Please state direction and polarity.
>
>
> Thanks, I'll fix that up.
>
>>
>>> +- creset_b-gpio: GPIO connected to CRESET_B pin. Note that
>>> CRESET_B is
>>
>>
>> Don't use '_'. In this case, I'd just do cresetb-gpios.
>
>
> So the pin is called CRESET_B in the datasheet. I think the _B refers to the
> active-low polarity of the line.
>
> So I would think it should be creset-b-gpios or creset-gpios. I'm not so
> convinced cresetb-gpios is ideal, but it's a minor point.
>
>>
>>> + treated as an active-low output because the
>>> signal is
>>> + treated as an enable signal, rather than a reset.
>>> This
>>
>>
>> Though for enable signals, enable-gpios is fairly standard even if that
>> deviates from the pin name.
>
>
> I would think that would just confuse the user, unless they dig out the
> binding docs. The FPGA doesn't have an enable pin, and it's not at all
> obvious that a "reset" pin means "enable" in this driver.
That's why you have the binding docs ;-)
Cheers,
Moritz
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ 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