* Re: [PATCH V4 1/9] PM / OPP: Allow OPP table to be used for power-domains
From: Viresh Kumar @ 2017-04-10 9:50 UTC (permalink / raw)
To: Rob Herring, Kevin Hilman
Cc: Rafael Wysocki, ulf.hansson, Viresh Kumar, Nishanth Menon,
Stephen Boyd, linaro-kernel, linux-pm, linux-kernel,
Vincent Guittot, lina.iyer, rnayak, devicetree
In-Reply-To: <20170410092515.GF24555@vireshk-i7>
Fixing Kevin's email id :(
On 10-04-17, 14:55, Viresh Kumar wrote:
> On 24-03-17, 10:44, Rob Herring wrote:
> > On Mon, Mar 20, 2017 at 03:02:13PM +0530, Viresh Kumar wrote:
> > > Power-domains need to express their active states in DT and what's
> > > better than OPP table for that.
> > >
> > > This patch allows power-domains to reuse OPP tables to express their
> > > active states. The "opp-hz" property isn't a required property anymore
> > > as power-domains may not always use them.
> >
> > Then maybe you shouldn't be trying to make OPP table work here. At that
> > point you just need a table of voltage(s) per performance state?
>
> Because that's what Kevin strongly recommended in the previous
> versions.
>
> @Kevin: Would you like to reply here ?
>
> > > Add a new property "domain-performance-state", which will contain
> > > positive integer values to represent performance levels of the
> > > power-domains as described in this patch.
> >
> > Why not reference the OPP entries from the domain:
> >
> > performance-states = <&opp1>, <&opp2>;
>
> Because that would require additional code in the OPP core to parse
> these then. Right now it is quite straight forward with the bindings I
> presented.
>
> > Just thinking out loud, not saying that is what you should do. The
> > continual evolution of power (management) domain, idle state, and OPP
> > bindings is getting tiring.
>
> I agree :)
--
viresh
^ permalink raw reply
* Re: [PATCH V4 1/9] PM / OPP: Allow OPP table to be used for power-domains
From: Viresh Kumar @ 2017-04-10 9:25 UTC (permalink / raw)
To: Rob Herring
Cc: Rafael Wysocki, ulf.hansson, Kevin Hilman, Viresh Kumar,
Nishanth Menon, Stephen Boyd, linaro-kernel, linux-pm,
linux-kernel, Vincent Guittot, lina.iyer, rnayak, devicetree
In-Reply-To: <20170324154451.ljszby3mhc4rlgnw@rob-hp-laptop>
On 24-03-17, 10:44, Rob Herring wrote:
> On Mon, Mar 20, 2017 at 03:02:13PM +0530, Viresh Kumar wrote:
> > Power-domains need to express their active states in DT and what's
> > better than OPP table for that.
> >
> > This patch allows power-domains to reuse OPP tables to express their
> > active states. The "opp-hz" property isn't a required property anymore
> > as power-domains may not always use them.
>
> Then maybe you shouldn't be trying to make OPP table work here. At that
> point you just need a table of voltage(s) per performance state?
Because that's what Kevin strongly recommended in the previous
versions.
@Kevin: Would you like to reply here ?
> > Add a new property "domain-performance-state", which will contain
> > positive integer values to represent performance levels of the
> > power-domains as described in this patch.
>
> Why not reference the OPP entries from the domain:
>
> performance-states = <&opp1>, <&opp2>;
Because that would require additional code in the OPP core to parse
these then. Right now it is quite straight forward with the bindings I
presented.
> Just thinking out loud, not saying that is what you should do. The
> continual evolution of power (management) domain, idle state, and OPP
> bindings is getting tiring.
I agree :)
--
viresh
^ permalink raw reply
* Re: [PATCH v2 5/8] v4l: Switch from V4L2 OF not V4L2 fwnode API
From: Mika Westerberg @ 2017-04-10 9:21 UTC (permalink / raw)
To: Sakari Ailus
Cc: Laurent Pinchart, Sakari Ailus, linux-media, linux-acpi,
devicetree
In-Reply-To: <20170407225515.GM4192@valkosipuli.retiisi.org.uk>
On Sat, Apr 08, 2017 at 01:55:15AM +0300, Sakari Ailus wrote:
> > My ACPI knowledge is limited, but don't ACPI nodes have 4 character names that
> > can be combined in a string to create a full path ?
>
> There is something, yes, but the ACPI framework currently has no such
> functionality. I believe it could be implemented though. Cc Mika.
All ACPI node names are 32-bit integers and those are combined to form a
path, like \_SB.PCI0.I2C0 and so on. A single ACPI node name cannot be
larger than 4 chars, though.
^ permalink raw reply
* [PATCH V2] PM / OPP: Use - instead of @ for DT entries
From: Viresh Kumar @ 2017-04-10 9:21 UTC (permalink / raw)
To: Rafael Wysocki, Chanwoo Choi, MyungJoo Ham, Kyungmin Park,
Kukjin Kim, Krzysztof Kozlowski, Javier Martinez Canillas,
Viresh Kumar, Nishanth Menon, Stephen Boyd, Benoît Cousson,
Tony Lindgren, Rob Herring, Mark Rutland, Daniel Mack,
Haojian Zhuang, Robert Jarzmik, Maxime Ripard, Chen-Yu Tsai,
Masahiro Yamada
Cc: devicetree, linaro-kernel, Vincent Guittot, linux-pm,
Viresh Kumar, linux-kernel, linux-samsung-soc, linux-omap,
linux-arm-kernel
Compiling the DT file with W=1, DTC warns like follows:
Warning (unit_address_vs_reg): Node /opp_table0/opp@1000000000 has a
unit name, but no reg property
Fix this by replacing '@' with '-' as the OPP nodes will never have a
"reg" property.
Reported-by: Krzysztof Kozlowski <krzk@kernel.org>
Reported-by: Masahiro Yamada <yamada.masahiro@socionext.com>
Suggested-by: Mark Rutland <mark.rutland@arm.com>
Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
Acked-by: Maxime Ripard <maxime.ripard@free-electrons.com> (sunxi)
Reviewed-by: Chanwoo Choi <cw00.choi@samsung.com>
Reviewed-by: Krzysztof Kozlowski <krzk@kernel.org>
---
V2:
- Added more *-by tags.
- Included TI DT and example files as well.
.../devicetree/bindings/cpufreq/ti-cpufreq.txt | 20 +++----
.../devicetree/bindings/devfreq/exynos-bus.txt | 46 +++++++--------
Documentation/devicetree/bindings/opp/opp.txt | 38 ++++++-------
arch/arm/boot/dts/am4372.dtsi | 10 ++--
arch/arm/boot/dts/exynos3250.dtsi | 46 +++++++--------
arch/arm/boot/dts/exynos4210.dtsi | 32 +++++------
arch/arm/boot/dts/exynos4412-prime.dtsi | 4 +-
arch/arm/boot/dts/exynos4412.dtsi | 66 +++++++++++-----------
arch/arm/boot/dts/exynos5420.dtsi | 40 ++++++-------
arch/arm/boot/dts/exynos5800.dtsi | 56 +++++++++---------
arch/arm/boot/dts/pxa25x.dtsi | 8 +--
arch/arm/boot/dts/pxa27x.dtsi | 14 ++---
arch/arm/boot/dts/sun8i-a33.dtsi | 8 +--
arch/arm/boot/dts/uniphier-pro5.dtsi | 32 +++++------
arch/arm/boot/dts/uniphier-pxs2.dtsi | 16 +++---
arch/arm64/boot/dts/exynos/exynos5433-bus.dtsi | 48 ++++++++--------
arch/arm64/boot/dts/exynos/exynos5433.dtsi | 50 ++++++++--------
arch/arm64/boot/dts/socionext/uniphier-ld11.dtsi | 14 ++---
arch/arm64/boot/dts/socionext/uniphier-ld20.dtsi | 32 +++++------
arch/arm64/boot/dts/zte/zx296718.dtsi | 10 ++--
20 files changed, 295 insertions(+), 295 deletions(-)
diff --git a/Documentation/devicetree/bindings/cpufreq/ti-cpufreq.txt b/Documentation/devicetree/bindings/cpufreq/ti-cpufreq.txt
index ba0e15ad5bd9..0c38e4b8fc51 100644
--- a/Documentation/devicetree/bindings/cpufreq/ti-cpufreq.txt
+++ b/Documentation/devicetree/bindings/cpufreq/ti-cpufreq.txt
@@ -63,64 +63,64 @@ cpu0_opp_table: opp-table {
* because they can not be enabled simultaneously on a
* single SoC.
*/
- opp50@300000000 {
+ opp50-300000000 {
opp-hz = /bits/ 64 <300000000>;
opp-microvolt = <950000 931000 969000>;
opp-supported-hw = <0x06 0x0010>;
opp-suspend;
};
- opp100@275000000 {
+ opp100-275000000 {
opp-hz = /bits/ 64 <275000000>;
opp-microvolt = <1100000 1078000 1122000>;
opp-supported-hw = <0x01 0x00FF>;
opp-suspend;
};
- opp100@300000000 {
+ opp100-300000000 {
opp-hz = /bits/ 64 <300000000>;
opp-microvolt = <1100000 1078000 1122000>;
opp-supported-hw = <0x06 0x0020>;
opp-suspend;
};
- opp100@500000000 {
+ opp100-500000000 {
opp-hz = /bits/ 64 <500000000>;
opp-microvolt = <1100000 1078000 1122000>;
opp-supported-hw = <0x01 0xFFFF>;
};
- opp100@600000000 {
+ opp100-600000000 {
opp-hz = /bits/ 64 <600000000>;
opp-microvolt = <1100000 1078000 1122000>;
opp-supported-hw = <0x06 0x0040>;
};
- opp120@600000000 {
+ opp120-600000000 {
opp-hz = /bits/ 64 <600000000>;
opp-microvolt = <1200000 1176000 1224000>;
opp-supported-hw = <0x01 0xFFFF>;
};
- opp120@720000000 {
+ opp120-720000000 {
opp-hz = /bits/ 64 <720000000>;
opp-microvolt = <1200000 1176000 1224000>;
opp-supported-hw = <0x06 0x0080>;
};
- oppturbo@720000000 {
+ oppturbo-720000000 {
opp-hz = /bits/ 64 <720000000>;
opp-microvolt = <1260000 1234800 1285200>;
opp-supported-hw = <0x01 0xFFFF>;
};
- oppturbo@800000000 {
+ oppturbo-800000000 {
opp-hz = /bits/ 64 <800000000>;
opp-microvolt = <1260000 1234800 1285200>;
opp-supported-hw = <0x06 0x0100>;
};
- oppnitro@1000000000 {
+ oppnitro-1000000000 {
opp-hz = /bits/ 64 <1000000000>;
opp-microvolt = <1325000 1298500 1351500>;
opp-supported-hw = <0x04 0x0200>;
diff --git a/Documentation/devicetree/bindings/devfreq/exynos-bus.txt b/Documentation/devicetree/bindings/devfreq/exynos-bus.txt
index d085ef90d27c..f8e946471a58 100644
--- a/Documentation/devicetree/bindings/devfreq/exynos-bus.txt
+++ b/Documentation/devicetree/bindings/devfreq/exynos-bus.txt
@@ -202,23 +202,23 @@ is able to support the bus frequency for all Exynos SoCs.
compatible = "operating-points-v2";
opp-shared;
- opp@50000000 {
+ opp-50000000 {
opp-hz = /bits/ 64 <50000000>;
opp-microvolt = <800000>;
};
- opp@100000000 {
+ opp-100000000 {
opp-hz = /bits/ 64 <100000000>;
opp-microvolt = <800000>;
};
- opp@134000000 {
+ opp-134000000 {
opp-hz = /bits/ 64 <134000000>;
opp-microvolt = <800000>;
};
- opp@200000000 {
+ opp-200000000 {
opp-hz = /bits/ 64 <200000000>;
opp-microvolt = <825000>;
};
- opp@400000000 {
+ opp-400000000 {
opp-hz = /bits/ 64 <400000000>;
opp-microvolt = <875000>;
};
@@ -292,23 +292,23 @@ is able to support the bus frequency for all Exynos SoCs.
compatible = "operating-points-v2";
opp-shared;
- opp@50000000 {
+ opp-50000000 {
opp-hz = /bits/ 64 <50000000>;
opp-microvolt = <900000>;
};
- opp@80000000 {
+ opp-80000000 {
opp-hz = /bits/ 64 <80000000>;
opp-microvolt = <900000>;
};
- opp@100000000 {
+ opp-100000000 {
opp-hz = /bits/ 64 <100000000>;
opp-microvolt = <1000000>;
};
- opp@134000000 {
+ opp-134000000 {
opp-hz = /bits/ 64 <134000000>;
opp-microvolt = <1000000>;
};
- opp@200000000 {
+ opp-200000000 {
opp-hz = /bits/ 64 <200000000>;
opp-microvolt = <1000000>;
};
@@ -318,19 +318,19 @@ is able to support the bus frequency for all Exynos SoCs.
compatible = "operating-points-v2";
opp-shared;
- opp@50000000 {
+ opp-50000000 {
opp-hz = /bits/ 64 <50000000>;
};
- opp@80000000 {
+ opp-80000000 {
opp-hz = /bits/ 64 <80000000>;
};
- opp@100000000 {
+ opp-100000000 {
opp-hz = /bits/ 64 <100000000>;
};
- opp@200000000 {
+ opp-200000000 {
opp-hz = /bits/ 64 <200000000>;
};
- opp@400000000 {
+ opp-400000000 {
opp-hz = /bits/ 64 <400000000>;
};
};
@@ -339,19 +339,19 @@ is able to support the bus frequency for all Exynos SoCs.
compatible = "operating-points-v2";
opp-shared;
- opp@50000000 {
+ opp-50000000 {
opp-hz = /bits/ 64 <50000000>;
};
- opp@80000000 {
+ opp-80000000 {
opp-hz = /bits/ 64 <80000000>;
};
- opp@100000000 {
+ opp-100000000 {
opp-hz = /bits/ 64 <100000000>;
};
- opp@200000000 {
+ opp-200000000 {
opp-hz = /bits/ 64 <200000000>;
};
- opp@300000000 {
+ opp-300000000 {
opp-hz = /bits/ 64 <300000000>;
};
};
@@ -360,13 +360,13 @@ is able to support the bus frequency for all Exynos SoCs.
compatible = "operating-points-v2";
opp-shared;
- opp@50000000 {
+ opp-50000000 {
opp-hz = /bits/ 64 <50000000>;
};
- opp@80000000 {
+ opp-80000000 {
opp-hz = /bits/ 64 <80000000>;
};
- opp@100000000 {
+ opp-100000000 {
opp-hz = /bits/ 64 <100000000>;
};
};
diff --git a/Documentation/devicetree/bindings/opp/opp.txt b/Documentation/devicetree/bindings/opp/opp.txt
index 63725498bd20..e36d261b9ba6 100644
--- a/Documentation/devicetree/bindings/opp/opp.txt
+++ b/Documentation/devicetree/bindings/opp/opp.txt
@@ -186,20 +186,20 @@ Example 1: Single cluster Dual-core ARM cortex A9, switch DVFS states together.
compatible = "operating-points-v2";
opp-shared;
- opp@1000000000 {
+ opp-1000000000 {
opp-hz = /bits/ 64 <1000000000>;
opp-microvolt = <975000 970000 985000>;
opp-microamp = <70000>;
clock-latency-ns = <300000>;
opp-suspend;
};
- opp@1100000000 {
+ opp-1100000000 {
opp-hz = /bits/ 64 <1100000000>;
opp-microvolt = <1000000 980000 1010000>;
opp-microamp = <80000>;
clock-latency-ns = <310000>;
};
- opp@1200000000 {
+ opp-1200000000 {
opp-hz = /bits/ 64 <1200000000>;
opp-microvolt = <1025000>;
clock-latency-ns = <290000>;
@@ -265,20 +265,20 @@ independently.
* independently.
*/
- opp@1000000000 {
+ opp-1000000000 {
opp-hz = /bits/ 64 <1000000000>;
opp-microvolt = <975000 970000 985000>;
opp-microamp = <70000>;
clock-latency-ns = <300000>;
opp-suspend;
};
- opp@1100000000 {
+ opp-1100000000 {
opp-hz = /bits/ 64 <1100000000>;
opp-microvolt = <1000000 980000 1010000>;
opp-microamp = <80000>;
clock-latency-ns = <310000>;
};
- opp@1200000000 {
+ opp-1200000000 {
opp-hz = /bits/ 64 <1200000000>;
opp-microvolt = <1025000>;
opp-microamp = <90000;
@@ -341,20 +341,20 @@ DVFS state together.
compatible = "operating-points-v2";
opp-shared;
- opp@1000000000 {
+ opp-1000000000 {
opp-hz = /bits/ 64 <1000000000>;
opp-microvolt = <975000 970000 985000>;
opp-microamp = <70000>;
clock-latency-ns = <300000>;
opp-suspend;
};
- opp@1100000000 {
+ opp-1100000000 {
opp-hz = /bits/ 64 <1100000000>;
opp-microvolt = <1000000 980000 1010000>;
opp-microamp = <80000>;
clock-latency-ns = <310000>;
};
- opp@1200000000 {
+ opp-1200000000 {
opp-hz = /bits/ 64 <1200000000>;
opp-microvolt = <1025000>;
opp-microamp = <90000>;
@@ -367,20 +367,20 @@ DVFS state together.
compatible = "operating-points-v2";
opp-shared;
- opp@1300000000 {
+ opp-1300000000 {
opp-hz = /bits/ 64 <1300000000>;
opp-microvolt = <1050000 1045000 1055000>;
opp-microamp = <95000>;
clock-latency-ns = <400000>;
opp-suspend;
};
- opp@1400000000 {
+ opp-1400000000 {
opp-hz = /bits/ 64 <1400000000>;
opp-microvolt = <1075000>;
opp-microamp = <100000>;
clock-latency-ns = <400000>;
};
- opp@1500000000 {
+ opp-1500000000 {
opp-hz = /bits/ 64 <1500000000>;
opp-microvolt = <1100000 1010000 1110000>;
opp-microamp = <95000>;
@@ -409,7 +409,7 @@ Example 4: Handling multiple regulators
compatible = "operating-points-v2";
opp-shared;
- opp@1000000000 {
+ opp-1000000000 {
opp-hz = /bits/ 64 <1000000000>;
opp-microvolt = <970000>, /* Supply 0 */
<960000>, /* Supply 1 */
@@ -422,7 +422,7 @@ Example 4: Handling multiple regulators
/* OR */
- opp@1000000000 {
+ opp-1000000000 {
opp-hz = /bits/ 64 <1000000000>;
opp-microvolt = <975000 970000 985000>, /* Supply 0 */
<965000 960000 975000>, /* Supply 1 */
@@ -435,7 +435,7 @@ Example 4: Handling multiple regulators
/* OR */
- opp@1000000000 {
+ opp-1000000000 {
opp-hz = /bits/ 64 <1000000000>;
opp-microvolt = <975000 970000 985000>, /* Supply 0 */
<965000 960000 975000>, /* Supply 1 */
@@ -467,7 +467,7 @@ Example 5: opp-supported-hw
status = "okay";
opp-shared;
- opp@600000000 {
+ opp-600000000 {
/*
* Supports all substrate and process versions for 0xF
* cuts, i.e. only first four cuts.
@@ -478,7 +478,7 @@ Example 5: opp-supported-hw
...
};
- opp@800000000 {
+ opp-800000000 {
/*
* Supports:
* - cuts: only one, 6th cut (represented by 6th bit).
@@ -510,7 +510,7 @@ Example 5: opp-supported-hw
compatible = "operating-points-v2";
opp-shared;
- opp@1000000000 {
+ opp-1000000000 {
opp-hz = /bits/ 64 <1000000000>;
opp-microvolt-slow = <915000 900000 925000>;
opp-microvolt-fast = <975000 970000 985000>;
@@ -518,7 +518,7 @@ Example 5: opp-supported-hw
opp-microamp-fast = <71000>;
};
- opp@1200000000 {
+ opp-1200000000 {
opp-hz = /bits/ 64 <1200000000>;
opp-microvolt-slow = <915000 900000 925000>, /* Supply vcc0 */
<925000 910000 935000>; /* Supply vcc1 */
diff --git a/arch/arm/boot/dts/am4372.dtsi b/arch/arm/boot/dts/am4372.dtsi
index 97fcaf415de1..1532ffe1de63 100644
--- a/arch/arm/boot/dts/am4372.dtsi
+++ b/arch/arm/boot/dts/am4372.dtsi
@@ -60,32 +60,32 @@
cpu0_opp_table: opp_table0 {
compatible = "operating-points-v2";
- opp50@300000000 {
+ opp50-300000000 {
opp-hz = /bits/ 64 <300000000>;
opp-microvolt = <950000 931000 969000>;
opp-supported-hw = <0xFF 0x01>;
opp-suspend;
};
- opp100@600000000 {
+ opp100-600000000 {
opp-hz = /bits/ 64 <600000000>;
opp-microvolt = <1100000 1078000 1122000>;
opp-supported-hw = <0xFF 0x04>;
};
- opp120@720000000 {
+ opp120-720000000 {
opp-hz = /bits/ 64 <720000000>;
opp-microvolt = <1200000 1176000 1224000>;
opp-supported-hw = <0xFF 0x08>;
};
- oppturbo@800000000 {
+ oppturbo-800000000 {
opp-hz = /bits/ 64 <800000000>;
opp-microvolt = <1260000 1234800 1285200>;
opp-supported-hw = <0xFF 0x10>;
};
- oppnitro@1000000000 {
+ oppnitro-1000000000 {
opp-hz = /bits/ 64 <1000000000>;
opp-microvolt = <1325000 1298500 1351500>;
opp-supported-hw = <0xFF 0x20>;
diff --git a/arch/arm/boot/dts/exynos3250.dtsi b/arch/arm/boot/dts/exynos3250.dtsi
index 9c28ef4508e0..590ee442d0ae 100644
--- a/arch/arm/boot/dts/exynos3250.dtsi
+++ b/arch/arm/boot/dts/exynos3250.dtsi
@@ -745,23 +745,23 @@
compatible = "operating-points-v2";
opp-shared;
- opp@50000000 {
+ opp-50000000 {
opp-hz = /bits/ 64 <50000000>;
opp-microvolt = <800000>;
};
- opp@100000000 {
+ opp-100000000 {
opp-hz = /bits/ 64 <100000000>;
opp-microvolt = <800000>;
};
- opp@134000000 {
+ opp-134000000 {
opp-hz = /bits/ 64 <134000000>;
opp-microvolt = <800000>;
};
- opp@200000000 {
+ opp-200000000 {
opp-hz = /bits/ 64 <200000000>;
opp-microvolt = <825000>;
};
- opp@400000000 {
+ opp-400000000 {
opp-hz = /bits/ 64 <400000000>;
opp-microvolt = <875000>;
};
@@ -835,23 +835,23 @@
compatible = "operating-points-v2";
opp-shared;
- opp@50000000 {
+ opp-50000000 {
opp-hz = /bits/ 64 <50000000>;
opp-microvolt = <900000>;
};
- opp@80000000 {
+ opp-80000000 {
opp-hz = /bits/ 64 <80000000>;
opp-microvolt = <900000>;
};
- opp@100000000 {
+ opp-100000000 {
opp-hz = /bits/ 64 <100000000>;
opp-microvolt = <1000000>;
};
- opp@134000000 {
+ opp-134000000 {
opp-hz = /bits/ 64 <134000000>;
opp-microvolt = <1000000>;
};
- opp@200000000 {
+ opp-200000000 {
opp-hz = /bits/ 64 <200000000>;
opp-microvolt = <1000000>;
};
@@ -861,19 +861,19 @@
compatible = "operating-points-v2";
opp-shared;
- opp@50000000 {
+ opp-50000000 {
opp-hz = /bits/ 64 <50000000>;
};
- opp@80000000 {
+ opp-80000000 {
opp-hz = /bits/ 64 <80000000>;
};
- opp@100000000 {
+ opp-100000000 {
opp-hz = /bits/ 64 <100000000>;
};
- opp@200000000 {
+ opp-200000000 {
opp-hz = /bits/ 64 <200000000>;
};
- opp@400000000 {
+ opp-400000000 {
opp-hz = /bits/ 64 <400000000>;
};
};
@@ -882,19 +882,19 @@
compatible = "operating-points-v2";
opp-shared;
- opp@50000000 {
+ opp-50000000 {
opp-hz = /bits/ 64 <50000000>;
};
- opp@80000000 {
+ opp-80000000 {
opp-hz = /bits/ 64 <80000000>;
};
- opp@100000000 {
+ opp-100000000 {
opp-hz = /bits/ 64 <100000000>;
};
- opp@200000000 {
+ opp-200000000 {
opp-hz = /bits/ 64 <200000000>;
};
- opp@300000000 {
+ opp-300000000 {
opp-hz = /bits/ 64 <300000000>;
};
};
@@ -903,13 +903,13 @@
compatible = "operating-points-v2";
opp-shared;
- opp@50000000 {
+ opp-50000000 {
opp-hz = /bits/ 64 <50000000>;
};
- opp@80000000 {
+ opp-80000000 {
opp-hz = /bits/ 64 <80000000>;
};
- opp@100000000 {
+ opp-100000000 {
opp-hz = /bits/ 64 <100000000>;
};
};
diff --git a/arch/arm/boot/dts/exynos4210.dtsi b/arch/arm/boot/dts/exynos4210.dtsi
index f9408188f97f..3678d5b44d80 100644
--- a/arch/arm/boot/dts/exynos4210.dtsi
+++ b/arch/arm/boot/dts/exynos4210.dtsi
@@ -335,15 +335,15 @@
compatible = "operating-points-v2";
opp-shared;
- opp@134000000 {
+ opp-134000000 {
opp-hz = /bits/ 64 <134000000>;
opp-microvolt = <1025000>;
};
- opp@267000000 {
+ opp-267000000 {
opp-hz = /bits/ 64 <267000000>;
opp-microvolt = <1050000>;
};
- opp@400000000 {
+ opp-400000000 {
opp-hz = /bits/ 64 <400000000>;
opp-microvolt = <1150000>;
};
@@ -353,13 +353,13 @@
compatible = "operating-points-v2";
opp-shared;
- opp@134000000 {
+ opp-134000000 {
opp-hz = /bits/ 64 <134000000>;
};
- opp@160000000 {
+ opp-160000000 {
opp-hz = /bits/ 64 <160000000>;
};
- opp@200000000 {
+ opp-200000000 {
opp-hz = /bits/ 64 <200000000>;
};
};
@@ -368,10 +368,10 @@
compatible = "operating-points-v2";
opp-shared;
- opp@5000000 {
+ opp-5000000 {
opp-hz = /bits/ 64 <5000000>;
};
- opp@100000000 {
+ opp-100000000 {
opp-hz = /bits/ 64 <100000000>;
};
};
@@ -380,10 +380,10 @@
compatible = "operating-points-v2";
opp-shared;
- opp@10000000 {
+ opp-10000000 {
opp-hz = /bits/ 64 <10000000>;
};
- opp@134000000 {
+ opp-134000000 {
opp-hz = /bits/ 64 <134000000>;
};
};
@@ -392,13 +392,13 @@
compatible = "operating-points-v2";
opp-shared;
- opp@100000000 {
+ opp-100000000 {
opp-hz = /bits/ 64 <100000000>;
};
- opp@134000000 {
+ opp-134000000 {
opp-hz = /bits/ 64 <134000000>;
};
- opp@160000000 {
+ opp-160000000 {
opp-hz = /bits/ 64 <160000000>;
};
};
@@ -407,13 +407,13 @@
compatible = "operating-points-v2";
opp-shared;
- opp@100000000 {
+ opp-100000000 {
opp-hz = /bits/ 64 <100000000>;
};
- opp@160000000 {
+ opp-160000000 {
opp-hz = /bits/ 64 <160000000>;
};
- opp@200000000 {
+ opp-200000000 {
opp-hz = /bits/ 64 <200000000>;
};
};
diff --git a/arch/arm/boot/dts/exynos4412-prime.dtsi b/arch/arm/boot/dts/exynos4412-prime.dtsi
index e75bc170c89c..a67bd953d754 100644
--- a/arch/arm/boot/dts/exynos4412-prime.dtsi
+++ b/arch/arm/boot/dts/exynos4412-prime.dtsi
@@ -20,12 +20,12 @@
};
&cpu0_opp_table {
- opp@1600000000 {
+ opp-1600000000 {
opp-hz = /bits/ 64 <1600000000>;
opp-microvolt = <1350000>;
clock-latency-ns = <200000>;
};
- opp@1704000000 {
+ opp-1704000000 {
opp-hz = /bits/ 64 <1704000000>;
opp-microvolt = <1350000>;
clock-latency-ns = <200000>;
diff --git a/arch/arm/boot/dts/exynos4412.dtsi b/arch/arm/boot/dts/exynos4412.dtsi
index 235bbb69ad7c..ce240d0198b3 100644
--- a/arch/arm/boot/dts/exynos4412.dtsi
+++ b/arch/arm/boot/dts/exynos4412.dtsi
@@ -76,73 +76,73 @@
compatible = "operating-points-v2";
opp-shared;
- opp@200000000 {
+ opp-200000000 {
opp-hz = /bits/ 64 <200000000>;
opp-microvolt = <900000>;
clock-latency-ns = <200000>;
};
- opp@300000000 {
+ opp-300000000 {
opp-hz = /bits/ 64 <300000000>;
opp-microvolt = <900000>;
clock-latency-ns = <200000>;
};
- opp@400000000 {
+ opp-400000000 {
opp-hz = /bits/ 64 <400000000>;
opp-microvolt = <925000>;
clock-latency-ns = <200000>;
};
- opp@500000000 {
+ opp-500000000 {
opp-hz = /bits/ 64 <500000000>;
opp-microvolt = <950000>;
clock-latency-ns = <200000>;
};
- opp@600000000 {
+ opp-600000000 {
opp-hz = /bits/ 64 <600000000>;
opp-microvolt = <975000>;
clock-latency-ns = <200000>;
};
- opp@700000000 {
+ opp-700000000 {
opp-hz = /bits/ 64 <700000000>;
opp-microvolt = <987500>;
clock-latency-ns = <200000>;
};
- opp@800000000 {
+ opp-800000000 {
opp-hz = /bits/ 64 <800000000>;
opp-microvolt = <1000000>;
clock-latency-ns = <200000>;
opp-suspend;
};
- opp@900000000 {
+ opp-900000000 {
opp-hz = /bits/ 64 <900000000>;
opp-microvolt = <1037500>;
clock-latency-ns = <200000>;
};
- opp@1000000000 {
+ opp-1000000000 {
opp-hz = /bits/ 64 <1000000000>;
opp-microvolt = <1087500>;
clock-latency-ns = <200000>;
};
- opp@1100000000 {
+ opp-1100000000 {
opp-hz = /bits/ 64 <1100000000>;
opp-microvolt = <1137500>;
clock-latency-ns = <200000>;
};
- opp@1200000000 {
+ opp-1200000000 {
opp-hz = /bits/ 64 <1200000000>;
opp-microvolt = <1187500>;
clock-latency-ns = <200000>;
};
- opp@1300000000 {
+ opp-1300000000 {
opp-hz = /bits/ 64 <1300000000>;
opp-microvolt = <1250000>;
clock-latency-ns = <200000>;
};
- opp@1400000000 {
+ opp-1400000000 {
opp-hz = /bits/ 64 <1400000000>;
opp-microvolt = <1287500>;
clock-latency-ns = <200000>;
};
- cpu0_opp_1500: opp@1500000000 {
+ cpu0_opp_1500: opp-1500000000 {
opp-hz = /bits/ 64 <1500000000>;
opp-microvolt = <1350000>;
clock-latency-ns = <200000>;
@@ -433,23 +433,23 @@
compatible = "operating-points-v2";
opp-shared;
- opp@100000000 {
+ opp-100000000 {
opp-hz = /bits/ 64 <100000000>;
opp-microvolt = <900000>;
};
- opp@134000000 {
+ opp-134000000 {
opp-hz = /bits/ 64 <134000000>;
opp-microvolt = <900000>;
};
- opp@160000000 {
+ opp-160000000 {
opp-hz = /bits/ 64 <160000000>;
opp-microvolt = <900000>;
};
- opp@267000000 {
+ opp-267000000 {
opp-hz = /bits/ 64 <267000000>;
opp-microvolt = <950000>;
};
- opp@400000000 {
+ opp-400000000 {
opp-hz = /bits/ 64 <400000000>;
opp-microvolt = <1050000>;
};
@@ -459,16 +459,16 @@
compatible = "operating-points-v2";
opp-shared;
- opp@100000000 {
+ opp-100000000 {
opp-hz = /bits/ 64 <100000000>;
};
- opp@134000000 {
+ opp-134000000 {
opp-hz = /bits/ 64 <134000000>;
};
- opp@160000000 {
+ opp-160000000 {
opp-hz = /bits/ 64 <160000000>;
};
- opp@267000000 {
+ opp-267000000 {
opp-hz = /bits/ 64 <267000000>;
};
};
@@ -525,19 +525,19 @@
compatible = "operating-points-v2";
opp-shared;
- opp@100000000 {
+ opp-100000000 {
opp-hz = /bits/ 64 <100000000>;
opp-microvolt = <900000>;
};
- opp@134000000 {
+ opp-134000000 {
opp-hz = /bits/ 64 <134000000>;
opp-microvolt = <925000>;
};
- opp@160000000 {
+ opp-160000000 {
opp-hz = /bits/ 64 <160000000>;
opp-microvolt = <950000>;
};
- opp@200000000 {
+ opp-200000000 {
opp-hz = /bits/ 64 <200000000>;
opp-microvolt = <1000000>;
};
@@ -547,10 +547,10 @@
compatible = "operating-points-v2";
opp-shared;
- opp@160000000 {
+ opp-160000000 {
opp-hz = /bits/ 64 <160000000>;
};
- opp@200000000 {
+ opp-200000000 {
opp-hz = /bits/ 64 <200000000>;
};
};
@@ -559,10 +559,10 @@
compatible = "operating-points-v2";
opp-shared;
- opp@100000000 {
+ opp-100000000 {
opp-hz = /bits/ 64 <100000000>;
};
- opp@134000000 {
+ opp-134000000 {
opp-hz = /bits/ 64 <134000000>;
};
};
@@ -571,10 +571,10 @@
compatible = "operating-points-v2";
opp-shared;
- opp@50000000 {
+ opp-50000000 {
opp-hz = /bits/ 64 <50000000>;
};
- opp@100000000 {
+ opp-100000000 {
opp-hz = /bits/ 64 <100000000>;
};
};
diff --git a/arch/arm/boot/dts/exynos5420.dtsi b/arch/arm/boot/dts/exynos5420.dtsi
index 7dc9dc82afd8..5cd6c7389d51 100644
--- a/arch/arm/boot/dts/exynos5420.dtsi
+++ b/arch/arm/boot/dts/exynos5420.dtsi
@@ -49,62 +49,62 @@
cluster_a15_opp_table: opp_table0 {
compatible = "operating-points-v2";
opp-shared;
- opp@1800000000 {
+ opp-1800000000 {
opp-hz = /bits/ 64 <1800000000>;
opp-microvolt = <1250000>;
clock-latency-ns = <140000>;
};
- opp@1700000000 {
+ opp-1700000000 {
opp-hz = /bits/ 64 <1700000000>;
opp-microvolt = <1212500>;
clock-latency-ns = <140000>;
};
- opp@1600000000 {
+ opp-1600000000 {
opp-hz = /bits/ 64 <1600000000>;
opp-microvolt = <1175000>;
clock-latency-ns = <140000>;
};
- opp@1500000000 {
+ opp-1500000000 {
opp-hz = /bits/ 64 <1500000000>;
opp-microvolt = <1137500>;
clock-latency-ns = <140000>;
};
- opp@1400000000 {
+ opp-1400000000 {
opp-hz = /bits/ 64 <1400000000>;
opp-microvolt = <1112500>;
clock-latency-ns = <140000>;
};
- opp@1300000000 {
+ opp-1300000000 {
opp-hz = /bits/ 64 <1300000000>;
opp-microvolt = <1062500>;
clock-latency-ns = <140000>;
};
- opp@1200000000 {
+ opp-1200000000 {
opp-hz = /bits/ 64 <1200000000>;
opp-microvolt = <1037500>;
clock-latency-ns = <140000>;
};
- opp@1100000000 {
+ opp-1100000000 {
opp-hz = /bits/ 64 <1100000000>;
opp-microvolt = <1012500>;
clock-latency-ns = <140000>;
};
- opp@1000000000 {
+ opp-1000000000 {
opp-hz = /bits/ 64 <1000000000>;
opp-microvolt = < 987500>;
clock-latency-ns = <140000>;
};
- opp@900000000 {
+ opp-900000000 {
opp-hz = /bits/ 64 <900000000>;
opp-microvolt = < 962500>;
clock-latency-ns = <140000>;
};
- opp@800000000 {
+ opp-800000000 {
opp-hz = /bits/ 64 <800000000>;
opp-microvolt = < 937500>;
clock-latency-ns = <140000>;
};
- opp@700000000 {
+ opp-700000000 {
opp-hz = /bits/ 64 <700000000>;
opp-microvolt = < 912500>;
clock-latency-ns = <140000>;
@@ -114,42 +114,42 @@
cluster_a7_opp_table: opp_table1 {
compatible = "operating-points-v2";
opp-shared;
- opp@1300000000 {
+ opp-1300000000 {
opp-hz = /bits/ 64 <1300000000>;
opp-microvolt = <1275000>;
clock-latency-ns = <140000>;
};
- opp@1200000000 {
+ opp-1200000000 {
opp-hz = /bits/ 64 <1200000000>;
opp-microvolt = <1212500>;
clock-latency-ns = <140000>;
};
- opp@1100000000 {
+ opp-1100000000 {
opp-hz = /bits/ 64 <1100000000>;
opp-microvolt = <1162500>;
clock-latency-ns = <140000>;
};
- opp@1000000000 {
+ opp-1000000000 {
opp-hz = /bits/ 64 <1000000000>;
opp-microvolt = <1112500>;
clock-latency-ns = <140000>;
};
- opp@900000000 {
+ opp-900000000 {
opp-hz = /bits/ 64 <900000000>;
opp-microvolt = <1062500>;
clock-latency-ns = <140000>;
};
- opp@800000000 {
+ opp-800000000 {
opp-hz = /bits/ 64 <800000000>;
opp-microvolt = <1025000>;
clock-latency-ns = <140000>;
};
- opp@700000000 {
+ opp-700000000 {
opp-hz = /bits/ 64 <700000000>;
opp-microvolt = <975000>;
clock-latency-ns = <140000>;
};
- opp@600000000 {
+ opp-600000000 {
opp-hz = /bits/ 64 <600000000>;
opp-microvolt = <937500>;
clock-latency-ns = <140000>;
diff --git a/arch/arm/boot/dts/exynos5800.dtsi b/arch/arm/boot/dts/exynos5800.dtsi
index 8213016803e5..9ddb6bacac5a 100644
--- a/arch/arm/boot/dts/exynos5800.dtsi
+++ b/arch/arm/boot/dts/exynos5800.dtsi
@@ -24,60 +24,60 @@
};
&cluster_a15_opp_table {
- opp@1700000000 {
+ opp-1700000000 {
opp-microvolt = <1250000>;
};
- opp@1600000000 {
+ opp-1600000000 {
opp-microvolt = <1250000>;
};
- opp@1500000000 {
+ opp-1500000000 {
opp-microvolt = <1100000>;
};
- opp@1400000000 {
+ opp-1400000000 {
opp-microvolt = <1100000>;
};
- opp@1300000000 {
+ opp-1300000000 {
opp-microvolt = <1100000>;
};
- opp@1200000000 {
+ opp-1200000000 {
opp-microvolt = <1000000>;
};
- opp@1100000000 {
+ opp-1100000000 {
opp-microvolt = <1000000>;
};
- opp@1000000000 {
+ opp-1000000000 {
opp-microvolt = <1000000>;
};
- opp@900000000 {
+ opp-900000000 {
opp-microvolt = <1000000>;
};
- opp@800000000 {
+ opp-800000000 {
opp-microvolt = <900000>;
};
- opp@700000000 {
+ opp-700000000 {
opp-microvolt = <900000>;
};
- opp@600000000 {
+ opp-600000000 {
opp-hz = /bits/ 64 <600000000>;
opp-microvolt = <900000>;
clock-latency-ns = <140000>;
};
- opp@500000000 {
+ opp-500000000 {
opp-hz = /bits/ 64 <500000000>;
opp-microvolt = <900000>;
clock-latency-ns = <140000>;
};
- opp@400000000 {
+ opp-400000000 {
opp-hz = /bits/ 64 <400000000>;
opp-microvolt = <900000>;
clock-latency-ns = <140000>;
};
- opp@300000000 {
+ opp-300000000 {
opp-hz = /bits/ 64 <300000000>;
opp-microvolt = <900000>;
clock-latency-ns = <140000>;
};
- opp@200000000 {
+ opp-200000000 {
opp-hz = /bits/ 64 <200000000>;
opp-microvolt = <900000>;
clock-latency-ns = <140000>;
@@ -85,46 +85,46 @@
};
&cluster_a7_opp_table {
- opp@1300000000 {
+ opp-1300000000 {
opp-microvolt = <1250000>;
};
- opp@1200000000 {
+ opp-1200000000 {
opp-microvolt = <1250000>;
};
- opp@1100000000 {
+ opp-1100000000 {
opp-microvolt = <1250000>;
};
- opp@1000000000 {
+ opp-1000000000 {
opp-microvolt = <1100000>;
};
- opp@900000000 {
+ opp-900000000 {
opp-microvolt = <1100000>;
};
- opp@800000000 {
+ opp-800000000 {
opp-microvolt = <1100000>;
};
- opp@700000000 {
+ opp-700000000 {
opp-microvolt = <1000000>;
};
- opp@600000000 {
+ opp-600000000 {
opp-microvolt = <1000000>;
};
- opp@500000000 {
+ opp-500000000 {
opp-hz = /bits/ 64 <500000000>;
opp-microvolt = <1000000>;
clock-latency-ns = <140000>;
};
- opp@400000000 {
+ opp-400000000 {
opp-hz = /bits/ 64 <400000000>;
opp-microvolt = <1000000>;
clock-latency-ns = <140000>;
};
- opp@300000000 {
+ opp-300000000 {
opp-hz = /bits/ 64 <300000000>;
opp-microvolt = <900000>;
clock-latency-ns = <140000>;
};
- opp@200000000 {
+ opp-200000000 {
opp-hz = /bits/ 64 <200000000>;
opp-microvolt = <900000>;
clock-latency-ns = <140000>;
diff --git a/arch/arm/boot/dts/pxa25x.dtsi b/arch/arm/boot/dts/pxa25x.dtsi
index f9f4726396a0..95d59be97213 100644
--- a/arch/arm/boot/dts/pxa25x.dtsi
+++ b/arch/arm/boot/dts/pxa25x.dtsi
@@ -93,22 +93,22 @@
pxa250_opp_table: opp_table0 {
compatible = "operating-points-v2";
- opp@99532800 {
+ opp-99532800 {
opp-hz = /bits/ 64 <99532800>;
opp-microvolt = <1000000 950000 1650000>;
clock-latency-ns = <20>;
};
- opp@199065600 {
+ opp-199065600 {
opp-hz = /bits/ 64 <199065600>;
opp-microvolt = <1000000 950000 1650000>;
clock-latency-ns = <20>;
};
- opp@298598400 {
+ opp-298598400 {
opp-hz = /bits/ 64 <298598400>;
opp-microvolt = <1100000 1045000 1650000>;
clock-latency-ns = <20>;
};
- opp@398131200 {
+ opp-398131200 {
opp-hz = /bits/ 64 <398131200>;
opp-microvolt = <1300000 1235000 1650000>;
clock-latency-ns = <20>;
diff --git a/arch/arm/boot/dts/pxa27x.dtsi b/arch/arm/boot/dts/pxa27x.dtsi
index e0fab48ba6fa..5f1d6da02a4c 100644
--- a/arch/arm/boot/dts/pxa27x.dtsi
+++ b/arch/arm/boot/dts/pxa27x.dtsi
@@ -141,37 +141,37 @@
pxa270_opp_table: opp_table0 {
compatible = "operating-points-v2";
- opp@104000000 {
+ opp-104000000 {
opp-hz = /bits/ 64 <104000000>;
opp-microvolt = <900000 900000 1705000>;
clock-latency-ns = <20>;
};
- opp@156000000 {
+ opp-156000000 {
opp-hz = /bits/ 64 <156000000>;
opp-microvolt = <1000000 1000000 1705000>;
clock-latency-ns = <20>;
};
- opp@208000000 {
+ opp-208000000 {
opp-hz = /bits/ 64 <208000000>;
opp-microvolt = <1180000 1180000 1705000>;
clock-latency-ns = <20>;
};
- opp@312000000 {
+ opp-312000000 {
opp-hz = /bits/ 64 <312000000>;
opp-microvolt = <1250000 1250000 1705000>;
clock-latency-ns = <20>;
};
- opp@416000000 {
+ opp-416000000 {
opp-hz = /bits/ 64 <416000000>;
opp-microvolt = <1350000 1350000 1705000>;
clock-latency-ns = <20>;
};
- opp@520000000 {
+ opp-520000000 {
opp-hz = /bits/ 64 <520000000>;
opp-microvolt = <1450000 1450000 1705000>;
clock-latency-ns = <20>;
};
- opp@624000000 {
+ opp-624000000 {
opp-hz = /bits/ 64 <624000000>;
opp-microvolt = <1550000 1550000 1705000>;
clock-latency-ns = <20>;
diff --git a/arch/arm/boot/dts/sun8i-a33.dtsi b/arch/arm/boot/dts/sun8i-a33.dtsi
index 0467fb365bfc..7c7f8d8abfa0 100644
--- a/arch/arm/boot/dts/sun8i-a33.dtsi
+++ b/arch/arm/boot/dts/sun8i-a33.dtsi
@@ -49,25 +49,25 @@
compatible = "operating-points-v2";
opp-shared;
- opp@648000000 {
+ opp-648000000 {
opp-hz = /bits/ 64 <648000000>;
opp-microvolt = <1040000>;
clock-latency-ns = <244144>; /* 8 32k periods */
};
- opp@816000000 {
+ opp-816000000 {
opp-hz = /bits/ 64 <816000000>;
opp-microvolt = <1100000>;
clock-latency-ns = <244144>; /* 8 32k periods */
};
- opp@1008000000 {
+ opp-1008000000 {
opp-hz = /bits/ 64 <1008000000>;
opp-microvolt = <1200000>;
clock-latency-ns = <244144>; /* 8 32k periods */
};
- opp@1200000000 {
+ opp-1200000000 {
opp-hz = /bits/ 64 <1200000000>;
opp-microvolt = <1320000>;
clock-latency-ns = <244144>; /* 8 32k periods */
diff --git a/arch/arm/boot/dts/uniphier-pro5.dtsi b/arch/arm/boot/dts/uniphier-pro5.dtsi
index dbc5e5333163..22ef2842be3a 100644
--- a/arch/arm/boot/dts/uniphier-pro5.dtsi
+++ b/arch/arm/boot/dts/uniphier-pro5.dtsi
@@ -77,67 +77,67 @@
compatible = "operating-points-v2";
opp-shared;
- opp@100000000 {
+ opp-100000000 {
opp-hz = /bits/ 64 <100000000>;
clock-latency-ns = <300>;
};
- opp@116667000 {
+ opp-116667000 {
opp-hz = /bits/ 64 <116667000>;
clock-latency-ns = <300>;
};
- opp@150000000 {
+ opp-150000000 {
opp-hz = /bits/ 64 <150000000>;
clock-latency-ns = <300>;
};
- opp@175000000 {
+ opp-175000000 {
opp-hz = /bits/ 64 <175000000>;
clock-latency-ns = <300>;
};
- opp@200000000 {
+ opp-200000000 {
opp-hz = /bits/ 64 <200000000>;
clock-latency-ns = <300>;
};
- opp@233334000 {
+ opp-233334000 {
opp-hz = /bits/ 64 <233334000>;
clock-latency-ns = <300>;
};
- opp@300000000 {
+ opp-300000000 {
opp-hz = /bits/ 64 <300000000>;
clock-latency-ns = <300>;
};
- opp@350000000 {
+ opp-350000000 {
opp-hz = /bits/ 64 <350000000>;
clock-latency-ns = <300>;
};
- opp@400000000 {
+ opp-400000000 {
opp-hz = /bits/ 64 <400000000>;
clock-latency-ns = <300>;
};
- opp@466667000 {
+ opp-466667000 {
opp-hz = /bits/ 64 <466667000>;
clock-latency-ns = <300>;
};
- opp@600000000 {
+ opp-600000000 {
opp-hz = /bits/ 64 <600000000>;
clock-latency-ns = <300>;
};
- opp@700000000 {
+ opp-700000000 {
opp-hz = /bits/ 64 <700000000>;
clock-latency-ns = <300>;
};
- opp@800000000 {
+ opp-800000000 {
opp-hz = /bits/ 64 <800000000>;
clock-latency-ns = <300>;
};
- opp@933334000 {
+ opp-933334000 {
opp-hz = /bits/ 64 <933334000>;
clock-latency-ns = <300>;
};
- opp@1200000000 {
+ opp-1200000000 {
opp-hz = /bits/ 64 <1200000000>;
clock-latency-ns = <300>;
};
- opp@1400000000 {
+ opp-1400000000 {
opp-hz = /bits/ 64 <1400000000>;
clock-latency-ns = <300>;
};
diff --git a/arch/arm/boot/dts/uniphier-pxs2.dtsi b/arch/arm/boot/dts/uniphier-pxs2.dtsi
index e9e031d63c1a..acaaa2187843 100644
--- a/arch/arm/boot/dts/uniphier-pxs2.dtsi
+++ b/arch/arm/boot/dts/uniphier-pxs2.dtsi
@@ -97,35 +97,35 @@
compatible = "operating-points-v2";
opp-shared;
- opp@100000000 {
+ opp-100000000 {
opp-hz = /bits/ 64 <100000000>;
clock-latency-ns = <300>;
};
- opp@150000000 {
+ opp-150000000 {
opp-hz = /bits/ 64 <150000000>;
clock-latency-ns = <300>;
};
- opp@200000000 {
+ opp-200000000 {
opp-hz = /bits/ 64 <200000000>;
clock-latency-ns = <300>;
};
- opp@300000000 {
+ opp-300000000 {
opp-hz = /bits/ 64 <300000000>;
clock-latency-ns = <300>;
};
- opp@400000000 {
+ opp-400000000 {
opp-hz = /bits/ 64 <400000000>;
clock-latency-ns = <300>;
};
- opp@600000000 {
+ opp-600000000 {
opp-hz = /bits/ 64 <600000000>;
clock-latency-ns = <300>;
};
- opp@800000000 {
+ opp-800000000 {
opp-hz = /bits/ 64 <800000000>;
clock-latency-ns = <300>;
};
- opp@1200000000 {
+ opp-1200000000 {
opp-hz = /bits/ 64 <1200000000>;
clock-latency-ns = <300>;
};
diff --git a/arch/arm64/boot/dts/exynos/exynos5433-bus.dtsi b/arch/arm64/boot/dts/exynos/exynos5433-bus.dtsi
index c42dc39c3223..ec11343dc528 100644
--- a/arch/arm64/boot/dts/exynos/exynos5433-bus.dtsi
+++ b/arch/arm64/boot/dts/exynos/exynos5433-bus.dtsi
@@ -94,27 +94,27 @@
compatible = "operating-points-v2";
opp-shared;
- opp@400000000 {
+ opp-400000000 {
opp-hz = /bits/ 64 <400000000>;
opp-microvolt = <1075000>;
};
- opp@267000000 {
+ opp-267000000 {
opp-hz = /bits/ 64 <267000000>;
opp-microvolt = <1000000>;
};
- opp@200000000 {
+ opp-200000000 {
opp-hz = /bits/ 64 <200000000>;
opp-microvolt = <975000>;
};
- opp@160000000 {
+ opp-160000000 {
opp-hz = /bits/ 64 <160000000>;
opp-microvolt = <962500>;
};
- opp@134000000 {
+ opp-134000000 {
opp-hz = /bits/ 64 <134000000>;
opp-microvolt = <950000>;
};
- opp@100000000 {
+ opp-100000000 {
opp-hz = /bits/ 64 <100000000>;
opp-microvolt = <937500>;
};
@@ -123,19 +123,19 @@
bus_g2d_266_opp_table: opp_table3 {
compatible = "operating-points-v2";
- opp@267000000 {
+ opp-267000000 {
opp-hz = /bits/ 64 <267000000>;
};
- opp@200000000 {
+ opp-200000000 {
opp-hz = /bits/ 64 <200000000>;
};
- opp@160000000 {
+ opp-160000000 {
opp-hz = /bits/ 64 <160000000>;
};
- opp@134000000 {
+ opp-134000000 {
opp-hz = /bits/ 64 <134000000>;
};
- opp@100000000 {
+ opp-100000000 {
opp-hz = /bits/ 64 <100000000>;
};
};
@@ -143,13 +143,13 @@
bus_gscl_opp_table: opp_table4 {
compatible = "operating-points-v2";
- opp@333000000 {
+ opp-333000000 {
opp-hz = /bits/ 64 <333000000>;
};
- opp@222000000 {
+ opp-222000000 {
opp-hz = /bits/ 64 <222000000>;
};
- opp@166500000 {
+ opp-166500000 {
opp-hz = /bits/ 64 <166500000>;
};
};
@@ -158,22 +158,22 @@
compatible = "operating-points-v2";
opp-shared;
- opp@400000000 {
+ opp-400000000 {
opp-hz = /bits/ 64 <400000000>;
};
- opp@267000000 {
+ opp-267000000 {
opp-hz = /bits/ 64 <267000000>;
};
- opp@200000000 {
+ opp-200000000 {
opp-hz = /bits/ 64 <200000000>;
};
- opp@160000000 {
+ opp-160000000 {
opp-hz = /bits/ 64 <160000000>;
};
- opp@134000000 {
+ opp-134000000 {
opp-hz = /bits/ 64 <134000000>;
};
- opp@100000000 {
+ opp-100000000 {
opp-hz = /bits/ 64 <100000000>;
};
};
@@ -181,16 +181,16 @@
bus_noc2_opp_table: opp_table6 {
compatible = "operating-points-v2";
- opp@400000000 {
+ opp-400000000 {
opp-hz = /bits/ 64 <400000000>;
};
- opp@200000000 {
+ opp-200000000 {
opp-hz = /bits/ 64 <200000000>;
};
- opp@134000000 {
+ opp-134000000 {
opp-hz = /bits/ 64 <134000000>;
};
- opp@100000000 {
+ opp-100000000 {
opp-hz = /bits/ 64 <100000000>;
};
};
diff --git a/arch/arm64/boot/dts/exynos/exynos5433.dtsi b/arch/arm64/boot/dts/exynos/exynos5433.dtsi
index 16072c1c3ed3..727f36abf3d4 100644
--- a/arch/arm64/boot/dts/exynos/exynos5433.dtsi
+++ b/arch/arm64/boot/dts/exynos/exynos5433.dtsi
@@ -119,43 +119,43 @@
compatible = "operating-points-v2";
opp-shared;
- opp@400000000 {
+ opp-400000000 {
opp-hz = /bits/ 64 <400000000>;
opp-microvolt = <900000>;
};
- opp@500000000 {
+ opp-500000000 {
opp-hz = /bits/ 64 <500000000>;
opp-microvolt = <925000>;
};
- opp@600000000 {
+ opp-600000000 {
opp-hz = /bits/ 64 <600000000>;
opp-microvolt = <950000>;
};
- opp@700000000 {
+ opp-700000000 {
opp-hz = /bits/ 64 <700000000>;
opp-microvolt = <975000>;
};
- opp@800000000 {
+ opp-800000000 {
opp-hz = /bits/ 64 <800000000>;
opp-microvolt = <1000000>;
};
- opp@900000000 {
+ opp-900000000 {
opp-hz = /bits/ 64 <900000000>;
opp-microvolt = <1050000>;
};
- opp@1000000000 {
+ opp-1000000000 {
opp-hz = /bits/ 64 <1000000000>;
opp-microvolt = <1075000>;
};
- opp@1100000000 {
+ opp-1100000000 {
opp-hz = /bits/ 64 <1100000000>;
opp-microvolt = <1112500>;
};
- opp@1200000000 {
+ opp-1200000000 {
opp-hz = /bits/ 64 <1200000000>;
opp-microvolt = <1112500>;
};
- opp@1300000000 {
+ opp-1300000000 {
opp-hz = /bits/ 64 <1300000000>;
opp-microvolt = <1150000>;
};
@@ -165,63 +165,63 @@
compatible = "operating-points-v2";
opp-shared;
- opp@500000000 {
+ opp-500000000 {
opp-hz = /bits/ 64 <500000000>;
opp-microvolt = <900000>;
};
- opp@600000000 {
+ opp-600000000 {
opp-hz = /bits/ 64 <600000000>;
opp-microvolt = <900000>;
};
- opp@700000000 {
+ opp-700000000 {
opp-hz = /bits/ 64 <700000000>;
opp-microvolt = <912500>;
};
- opp@800000000 {
+ opp-800000000 {
opp-hz = /bits/ 64 <800000000>;
opp-microvolt = <912500>;
};
- opp@900000000 {
+ opp-900000000 {
opp-hz = /bits/ 64 <900000000>;
opp-microvolt = <937500>;
};
- opp@1000000000 {
+ opp-1000000000 {
opp-hz = /bits/ 64 <1000000000>;
opp-microvolt = <975000>;
};
- opp@1100000000 {
+ opp-1100000000 {
opp-hz = /bits/ 64 <1100000000>;
opp-microvolt = <1012500>;
};
- opp@1200000000 {
+ opp-1200000000 {
opp-hz = /bits/ 64 <1200000000>;
opp-microvolt = <1037500>;
};
- opp@1300000000 {
+ opp-1300000000 {
opp-hz = /bits/ 64 <1300000000>;
opp-microvolt = <1062500>;
};
- opp@1400000000 {
+ opp-1400000000 {
opp-hz = /bits/ 64 <1400000000>;
opp-microvolt = <1087500>;
};
- opp@1500000000 {
+ opp-1500000000 {
opp-hz = /bits/ 64 <1500000000>;
opp-microvolt = <1125000>;
};
- opp@1600000000 {
+ opp-1600000000 {
opp-hz = /bits/ 64 <1600000000>;
opp-microvolt = <1137500>;
};
- opp@1700000000 {
+ opp-1700000000 {
opp-hz = /bits/ 64 <1700000000>;
opp-microvolt = <1175000>;
};
- opp@1800000000 {
+ opp-1800000000 {
opp-hz = /bits/ 64 <1800000000>;
opp-microvolt = <1212500>;
};
- opp@1900000000 {
+ opp-1900000000 {
opp-hz = /bits/ 64 <1900000000>;
opp-microvolt = <1262500>;
};
diff --git a/arch/arm64/boot/dts/socionext/uniphier-ld11.dtsi b/arch/arm64/boot/dts/socionext/uniphier-ld11.dtsi
index da881f5b6ed4..0f2bee028ab0 100644
--- a/arch/arm64/boot/dts/socionext/uniphier-ld11.dtsi
+++ b/arch/arm64/boot/dts/socionext/uniphier-ld11.dtsi
@@ -89,31 +89,31 @@
compatible = "operating-points-v2";
opp-shared;
- opp@245000000 {
+ opp-245000000 {
opp-hz = /bits/ 64 <245000000>;
clock-latency-ns = <300>;
};
- opp@250000000 {
+ opp-250000000 {
opp-hz = /bits/ 64 <250000000>;
clock-latency-ns = <300>;
};
- opp@490000000 {
+ opp-490000000 {
opp-hz = /bits/ 64 <490000000>;
clock-latency-ns = <300>;
};
- opp@500000000 {
+ opp-500000000 {
opp-hz = /bits/ 64 <500000000>;
clock-latency-ns = <300>;
};
- opp@653334000 {
+ opp-653334000 {
opp-hz = /bits/ 64 <653334000>;
clock-latency-ns = <300>;
};
- opp@666667000 {
+ opp-666667000 {
opp-hz = /bits/ 64 <666667000>;
clock-latency-ns = <300>;
};
- opp@980000000 {
+ opp-980000000 {
opp-hz = /bits/ 64 <980000000>;
clock-latency-ns = <300>;
};
diff --git a/arch/arm64/boot/dts/socionext/uniphier-ld20.dtsi b/arch/arm64/boot/dts/socionext/uniphier-ld20.dtsi
index a6b3a70dae83..19f782408d54 100644
--- a/arch/arm64/boot/dts/socionext/uniphier-ld20.dtsi
+++ b/arch/arm64/boot/dts/socionext/uniphier-ld20.dtsi
@@ -116,35 +116,35 @@
compatible = "operating-points-v2";
opp-shared;
- opp@250000000 {
+ opp-250000000 {
opp-hz = /bits/ 64 <250000000>;
clock-latency-ns = <300>;
};
- opp@275000000 {
+ opp-275000000 {
opp-hz = /bits/ 64 <275000000>;
clock-latency-ns = <300>;
};
- opp@500000000 {
+ opp-500000000 {
opp-hz = /bits/ 64 <500000000>;
clock-latency-ns = <300>;
};
- opp@550000000 {
+ opp-550000000 {
opp-hz = /bits/ 64 <550000000>;
clock-latency-ns = <300>;
};
- opp@666667000 {
+ opp-666667000 {
opp-hz = /bits/ 64 <666667000>;
clock-latency-ns = <300>;
};
- opp@733334000 {
+ opp-733334000 {
opp-hz = /bits/ 64 <733334000>;
clock-latency-ns = <300>;
};
- opp@1000000000 {
+ opp-1000000000 {
opp-hz = /bits/ 64 <1000000000>;
clock-latency-ns = <300>;
};
- opp@1100000000 {
+ opp-1100000000 {
opp-hz = /bits/ 64 <1100000000>;
clock-latency-ns = <300>;
};
@@ -154,35 +154,35 @@
compatible = "operating-points-v2";
opp-shared;
- opp@250000000 {
+ opp-250000000 {
opp-hz = /bits/ 64 <250000000>;
clock-latency-ns = <300>;
};
- opp@275000000 {
+ opp-275000000 {
opp-hz = /bits/ 64 <275000000>;
clock-latency-ns = <300>;
};
- opp@500000000 {
+ opp-500000000 {
opp-hz = /bits/ 64 <500000000>;
clock-latency-ns = <300>;
};
- opp@550000000 {
+ opp-550000000 {
opp-hz = /bits/ 64 <550000000>;
clock-latency-ns = <300>;
};
- opp@666667000 {
+ opp-666667000 {
opp-hz = /bits/ 64 <666667000>;
clock-latency-ns = <300>;
};
- opp@733334000 {
+ opp-733334000 {
opp-hz = /bits/ 64 <733334000>;
clock-latency-ns = <300>;
};
- opp@1000000000 {
+ opp-1000000000 {
opp-hz = /bits/ 64 <1000000000>;
clock-latency-ns = <300>;
};
- opp@1100000000 {
+ opp-1100000000 {
opp-hz = /bits/ 64 <1100000000>;
clock-latency-ns = <300>;
};
diff --git a/arch/arm64/boot/dts/zte/zx296718.dtsi b/arch/arm64/boot/dts/zte/zx296718.dtsi
index b850b2cd0adc..2c7dc69987df 100644
--- a/arch/arm64/boot/dts/zte/zx296718.dtsi
+++ b/arch/arm64/boot/dts/zte/zx296718.dtsi
@@ -118,27 +118,27 @@
compatible = "operating-points-v2";
opp-shared;
- opp@500000000 {
+ opp-500000000 {
opp-hz = /bits/ 64 <500000000>;
clock-latency-ns = <500000>;
};
- opp@648000000 {
+ opp-648000000 {
opp-hz = /bits/ 64 <648000000>;
clock-latency-ns = <500000>;
};
- opp@800000000 {
+ opp-800000000 {
opp-hz = /bits/ 64 <800000000>;
clock-latency-ns = <500000>;
};
- opp@1000000000 {
+ opp-1000000000 {
opp-hz = /bits/ 64 <1000000000>;
clock-latency-ns = <500000>;
};
- opp@1188000000 {
+ opp-1188000000 {
opp-hz = /bits/ 64 <1188000000>;
clock-latency-ns = <500000>;
};
--
2.12.0.432.g71c3a4f4ba37
^ permalink raw reply related
* Re: [RESEND PATCH v4] iio: adc: add support for X-Powers AXP20X and AXP22X PMICs ADCs
From: Quentin Schulz @ 2017-04-10 9:18 UTC (permalink / raw)
To: sre-DgEjT+Ai2ygdnm+yROfE0A, robh+dt-DgEjT+Ai2ygdnm+yROfE0A,
mark.rutland-5wv7dgnIgG8, wens-jdAy2FN1RRM,
linux-I+IVW8TIWO2tmTQ+vhA3Yw,
maxime.ripard-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8,
jic23-DgEjT+Ai2ygdnm+yROfE0A, knaack.h-Mmb7MZpHnFY,
lars-Qo5EllUWu/uELgA04lAiVw, pmeerw-jW+XmwGofnusTnJN9+BGXg,
lee.jones-QSEj5FYQhm4dnm+yROfE0A, icenowy-ymACFijhrKM
Cc: thomas.petazzoni-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-pm-u79uwXL29TY76Z2rM5mHXA, linux-iio-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-sunxi-/JYPxA39Uh5TLH3MbocFFw,
liam-RYWXG+zxWwBdeoIcmNTgJF6hYfS7NtTn,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r
In-Reply-To: <20170404063441.7656-1-quentin.schulz-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org>
Hi Lee,
Just to make sure you didn't miss that patch (can't find it in
for-mfd-next and for-mfd-next-next).
Thanks,
Quentin
On 04/04/2017 08:34, Quentin Schulz wrote:
> The X-Powers AXP20X and AXP22X PMICs have multiple ADCs. They expose the
> battery voltage, battery charge and discharge currents, AC-in and VBUS
> voltages and currents, 2 GPIOs muxable in ADC mode and PMIC temperature.
>
> This adds support for most of AXP20X and AXP22X ADCs.
>
> Signed-off-by: Quentin Schulz <quentin.schulz-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org>
> Acked-by: Maxime Ripard <maxime.ripard-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org>
> Acked-by: Chen-Yu Tsai <wens-jdAy2FN1RRM@public.gmane.org>
> Reviewed-by: Jonathan Cameron <jic23-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
> ---
>
> Lee, could you merge this through the mfd tree please?
> => https://lkml.org/lkml/2017/3/22/47
>
> v4:
> - added missing space at the beginning of a comment,
> - tidied axp20x_adc_offset_voltage and axp20x_write_raw to use switch case
> instead of if conditions,
> - added MODULE_DEVICE_TABLE for axp20x_adc_id_match for module autoloading,
> - merged two lines in axp20x_remove,
>
> v3:
> - moved from switch to if condition in axp20x_adc_raw and
> axp22x_adc_raw,
> - removed DT support as DT node has been dropped,
> - use of platform_device_id
> - correctly defined the name of the iio device (name used to probe the
> driver),
> - added goto for errors in probe,
> - added iio_map_array_unregister to the remove function,
>
> v2:
> - removed unused defines,
> - changed BIT(x) to 1 << x when describing bits purpose for which 2 <<
> x or 3 << x exists, to be consistent,
> - changed ADC rate defines to macro formulas,
> - reordered IIO channels, now different measures (current/voltage) of
> the same part of the PMIC (e.g. battery), have the same IIO channel in
> their respective IIO type. When a part of the PMIC have only one
> measure, a number is jumped,
> - left IIO channel mapping in DT to use iio_map structure,
> - removed indexing of ADC internal temperature,
> - removed unused iio_dev structure in axp20x_adc_iio,
> - added a structure for data specific to AXP20X or AXP22X PMICs instead
> of using an ID and an if condition when needing to separate the
> behaviour of both,
> - added a comment on batt_chrg_i really being on 12bits rather than
> what the Chinese datasheets say (13 bits),
> - corrected the offset for AXP22X PMIC temperature,
> - set the ADC rate to a value (100Hz) shared by the AXP20X and AXP22X,
> - created macro formulas to compute the ADC rate for each,
> - added a condition on presence of ADC_EN2 reg before setting/resetting
> it,
> - switched from devm_iio_device_unregister to the non-devm function
> because of the need for a remove function,
> - removed some dead code,
>
> drivers/iio/adc/Kconfig | 10 +
> drivers/iio/adc/Makefile | 1 +
> drivers/iio/adc/axp20x_adc.c | 617 +++++++++++++++++++++++++++++++++++++++++++
> 3 files changed, 628 insertions(+)
> create mode 100644 drivers/iio/adc/axp20x_adc.c
>
> diff --git a/drivers/iio/adc/Kconfig b/drivers/iio/adc/Kconfig
> index d777a97..d15e1bd 100644
> --- a/drivers/iio/adc/Kconfig
> +++ b/drivers/iio/adc/Kconfig
> @@ -154,6 +154,16 @@ config AT91_SAMA5D2_ADC
> To compile this driver as a module, choose M here: the module will be
> called at91-sama5d2_adc.
>
> +config AXP20X_ADC
> + tristate "X-Powers AXP20X and AXP22X ADC driver"
> + depends on MFD_AXP20X
> + help
> + Say yes here to have support for X-Powers power management IC (PMIC)
> + AXP20X and AXP22X ADC devices.
> +
> + To compile this driver as a module, choose M here: the module will be
> + called axp20x_adc.
> +
> config AXP288_ADC
> tristate "X-Powers AXP288 ADC driver"
> depends on MFD_AXP20X
> diff --git a/drivers/iio/adc/Makefile b/drivers/iio/adc/Makefile
> index b11bb57..17899b5 100644
> --- a/drivers/iio/adc/Makefile
> +++ b/drivers/iio/adc/Makefile
> @@ -16,6 +16,7 @@ obj-$(CONFIG_AD7887) += ad7887.o
> obj-$(CONFIG_AD799X) += ad799x.o
> obj-$(CONFIG_AT91_ADC) += at91_adc.o
> obj-$(CONFIG_AT91_SAMA5D2_ADC) += at91-sama5d2_adc.o
> +obj-$(CONFIG_AXP20X_ADC) += axp20x_adc.o
> obj-$(CONFIG_AXP288_ADC) += axp288_adc.o
> obj-$(CONFIG_BCM_IPROC_ADC) += bcm_iproc_adc.o
> obj-$(CONFIG_BERLIN2_ADC) += berlin2-adc.o
> diff --git a/drivers/iio/adc/axp20x_adc.c b/drivers/iio/adc/axp20x_adc.c
> new file mode 100644
> index 0000000..11e1771
> --- /dev/null
> +++ b/drivers/iio/adc/axp20x_adc.c
> @@ -0,0 +1,617 @@
> +/* ADC driver for AXP20X and AXP22X PMICs
> + *
> + * Copyright (c) 2016 Free Electrons NextThing Co.
> + * Quentin Schulz <quentin.schulz-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org>
> + *
> + * This program is free software; you can redistribute it and/or modify it under
> + * the terms of the GNU General Public License version 2 as published by the
> + * Free Software Foundation.
> + */
> +
> +#include <linux/completion.h>
> +#include <linux/interrupt.h>
> +#include <linux/io.h>
> +#include <linux/module.h>
> +#include <linux/of.h>
> +#include <linux/of_device.h>
> +#include <linux/platform_device.h>
> +#include <linux/pm_runtime.h>
> +#include <linux/regmap.h>
> +#include <linux/thermal.h>
> +
> +#include <linux/iio/iio.h>
> +#include <linux/iio/driver.h>
> +#include <linux/iio/machine.h>
> +#include <linux/mfd/axp20x.h>
> +
> +#define AXP20X_ADC_EN1_MASK GENMASK(7, 0)
> +
> +#define AXP20X_ADC_EN2_MASK (GENMASK(3, 2) | BIT(7))
> +#define AXP22X_ADC_EN1_MASK (GENMASK(7, 5) | BIT(0))
> +
> +#define AXP20X_GPIO10_IN_RANGE_GPIO0 BIT(0)
> +#define AXP20X_GPIO10_IN_RANGE_GPIO1 BIT(1)
> +#define AXP20X_GPIO10_IN_RANGE_GPIO0_VAL(x) ((x) & BIT(0))
> +#define AXP20X_GPIO10_IN_RANGE_GPIO1_VAL(x) (((x) & BIT(0)) << 1)
> +
> +#define AXP20X_ADC_RATE_MASK GENMASK(7, 6)
> +#define AXP20X_ADC_RATE_HZ(x) ((ilog2((x) / 25) << 6) & AXP20X_ADC_RATE_MASK)
> +#define AXP22X_ADC_RATE_HZ(x) ((ilog2((x) / 100) << 6) & AXP20X_ADC_RATE_MASK)
> +
> +#define AXP20X_ADC_CHANNEL(_channel, _name, _type, _reg) \
> + { \
> + .type = _type, \
> + .indexed = 1, \
> + .channel = _channel, \
> + .address = _reg, \
> + .info_mask_separate = BIT(IIO_CHAN_INFO_RAW) | \
> + BIT(IIO_CHAN_INFO_SCALE), \
> + .datasheet_name = _name, \
> + }
> +
> +#define AXP20X_ADC_CHANNEL_OFFSET(_channel, _name, _type, _reg) \
> + { \
> + .type = _type, \
> + .indexed = 1, \
> + .channel = _channel, \
> + .address = _reg, \
> + .info_mask_separate = BIT(IIO_CHAN_INFO_RAW) | \
> + BIT(IIO_CHAN_INFO_SCALE) |\
> + BIT(IIO_CHAN_INFO_OFFSET),\
> + .datasheet_name = _name, \
> + }
> +
> +struct axp_data;
> +
> +struct axp20x_adc_iio {
> + struct regmap *regmap;
> + struct axp_data *data;
> +};
> +
> +enum axp20x_adc_channel_v {
> + AXP20X_ACIN_V = 0,
> + AXP20X_VBUS_V,
> + AXP20X_TS_IN,
> + AXP20X_GPIO0_V,
> + AXP20X_GPIO1_V,
> + AXP20X_IPSOUT_V,
> + AXP20X_BATT_V,
> +};
> +
> +enum axp20x_adc_channel_i {
> + AXP20X_ACIN_I = 0,
> + AXP20X_VBUS_I,
> + AXP20X_BATT_CHRG_I,
> + AXP20X_BATT_DISCHRG_I,
> +};
> +
> +enum axp22x_adc_channel_v {
> + AXP22X_TS_IN = 0,
> + AXP22X_BATT_V,
> +};
> +
> +enum axp22x_adc_channel_i {
> + AXP22X_BATT_CHRG_I = 1,
> + AXP22X_BATT_DISCHRG_I,
> +};
> +
> +static struct iio_map axp20x_maps[] = {
> + {
> + .consumer_dev_name = "axp20x-usb-power-supply",
> + .consumer_channel = "vbus_v",
> + .adc_channel_label = "vbus_v",
> + }, {
> + .consumer_dev_name = "axp20x-usb-power-supply",
> + .consumer_channel = "vbus_i",
> + .adc_channel_label = "vbus_i",
> + }, {
> + .consumer_dev_name = "axp20x-ac-power-supply",
> + .consumer_channel = "acin_v",
> + .adc_channel_label = "acin_v",
> + }, {
> + .consumer_dev_name = "axp20x-ac-power-supply",
> + .consumer_channel = "acin_i",
> + .adc_channel_label = "acin_i",
> + }, {
> + .consumer_dev_name = "axp20x-battery-power-supply",
> + .consumer_channel = "batt_v",
> + .adc_channel_label = "batt_v",
> + }, {
> + .consumer_dev_name = "axp20x-battery-power-supply",
> + .consumer_channel = "batt_chrg_i",
> + .adc_channel_label = "batt_chrg_i",
> + }, {
> + .consumer_dev_name = "axp20x-battery-power-supply",
> + .consumer_channel = "batt_dischrg_i",
> + .adc_channel_label = "batt_dischrg_i",
> + }, { /* sentinel */ }
> +};
> +
> +static struct iio_map axp22x_maps[] = {
> + {
> + .consumer_dev_name = "axp20x-battery-power-supply",
> + .consumer_channel = "batt_v",
> + .adc_channel_label = "batt_v",
> + }, {
> + .consumer_dev_name = "axp20x-battery-power-supply",
> + .consumer_channel = "batt_chrg_i",
> + .adc_channel_label = "batt_chrg_i",
> + }, {
> + .consumer_dev_name = "axp20x-battery-power-supply",
> + .consumer_channel = "batt_dischrg_i",
> + .adc_channel_label = "batt_dischrg_i",
> + }, { /* sentinel */ }
> +};
> +
> +/*
> + * Channels are mapped by physical system. Their channels share the same index.
> + * i.e. acin_i is in_current0_raw and acin_v is in_voltage0_raw.
> + * The only exception is for the battery. batt_v will be in_voltage6_raw and
> + * charge current in_current6_raw and discharge current will be in_current7_raw.
> + */
> +static const struct iio_chan_spec axp20x_adc_channels[] = {
> + AXP20X_ADC_CHANNEL(AXP20X_ACIN_V, "acin_v", IIO_VOLTAGE,
> + AXP20X_ACIN_V_ADC_H),
> + AXP20X_ADC_CHANNEL(AXP20X_ACIN_I, "acin_i", IIO_CURRENT,
> + AXP20X_ACIN_I_ADC_H),
> + AXP20X_ADC_CHANNEL(AXP20X_VBUS_V, "vbus_v", IIO_VOLTAGE,
> + AXP20X_VBUS_V_ADC_H),
> + AXP20X_ADC_CHANNEL(AXP20X_VBUS_I, "vbus_i", IIO_CURRENT,
> + AXP20X_VBUS_I_ADC_H),
> + {
> + .type = IIO_TEMP,
> + .address = AXP20X_TEMP_ADC_H,
> + .info_mask_separate = BIT(IIO_CHAN_INFO_RAW) |
> + BIT(IIO_CHAN_INFO_SCALE) |
> + BIT(IIO_CHAN_INFO_OFFSET),
> + .datasheet_name = "pmic_temp",
> + },
> + AXP20X_ADC_CHANNEL_OFFSET(AXP20X_GPIO0_V, "gpio0_v", IIO_VOLTAGE,
> + AXP20X_GPIO0_V_ADC_H),
> + AXP20X_ADC_CHANNEL_OFFSET(AXP20X_GPIO1_V, "gpio1_v", IIO_VOLTAGE,
> + AXP20X_GPIO1_V_ADC_H),
> + AXP20X_ADC_CHANNEL(AXP20X_IPSOUT_V, "ipsout_v", IIO_VOLTAGE,
> + AXP20X_IPSOUT_V_HIGH_H),
> + AXP20X_ADC_CHANNEL(AXP20X_BATT_V, "batt_v", IIO_VOLTAGE,
> + AXP20X_BATT_V_H),
> + AXP20X_ADC_CHANNEL(AXP20X_BATT_CHRG_I, "batt_chrg_i", IIO_CURRENT,
> + AXP20X_BATT_CHRG_I_H),
> + AXP20X_ADC_CHANNEL(AXP20X_BATT_DISCHRG_I, "batt_dischrg_i", IIO_CURRENT,
> + AXP20X_BATT_DISCHRG_I_H),
> +};
> +
> +static const struct iio_chan_spec axp22x_adc_channels[] = {
> + {
> + .type = IIO_TEMP,
> + .address = AXP22X_PMIC_TEMP_H,
> + .info_mask_separate = BIT(IIO_CHAN_INFO_RAW) |
> + BIT(IIO_CHAN_INFO_SCALE) |
> + BIT(IIO_CHAN_INFO_OFFSET),
> + .datasheet_name = "pmic_temp",
> + },
> + AXP20X_ADC_CHANNEL(AXP22X_BATT_V, "batt_v", IIO_VOLTAGE,
> + AXP20X_BATT_V_H),
> + AXP20X_ADC_CHANNEL(AXP22X_BATT_CHRG_I, "batt_chrg_i", IIO_CURRENT,
> + AXP20X_BATT_CHRG_I_H),
> + AXP20X_ADC_CHANNEL(AXP22X_BATT_DISCHRG_I, "batt_dischrg_i", IIO_CURRENT,
> + AXP20X_BATT_DISCHRG_I_H),
> +};
> +
> +static int axp20x_adc_raw(struct iio_dev *indio_dev,
> + struct iio_chan_spec const *chan, int *val)
> +{
> + struct axp20x_adc_iio *info = iio_priv(indio_dev);
> + int size = 12;
> +
> + /*
> + * N.B.: Unlike the Chinese datasheets tell, the charging current is
> + * stored on 12 bits, not 13 bits. Only discharging current is on 13
> + * bits.
> + */
> + if (chan->type == IIO_CURRENT && chan->channel == AXP20X_BATT_DISCHRG_I)
> + size = 13;
> + else
> + size = 12;
> +
> + *val = axp20x_read_variable_width(info->regmap, chan->address, size);
> + if (*val < 0)
> + return *val;
> +
> + return IIO_VAL_INT;
> +}
> +
> +static int axp22x_adc_raw(struct iio_dev *indio_dev,
> + struct iio_chan_spec const *chan, int *val)
> +{
> + struct axp20x_adc_iio *info = iio_priv(indio_dev);
> + int size;
> +
> + /*
> + * N.B.: Unlike the Chinese datasheets tell, the charging current is
> + * stored on 12 bits, not 13 bits. Only discharging current is on 13
> + * bits.
> + */
> + if (chan->type == IIO_CURRENT && chan->channel == AXP22X_BATT_DISCHRG_I)
> + size = 13;
> + else
> + size = 12;
> +
> + *val = axp20x_read_variable_width(info->regmap, chan->address, size);
> + if (*val < 0)
> + return *val;
> +
> + return IIO_VAL_INT;
> +}
> +
> +static int axp20x_adc_scale_voltage(int channel, int *val, int *val2)
> +{
> + switch (channel) {
> + case AXP20X_ACIN_V:
> + case AXP20X_VBUS_V:
> + *val = 1;
> + *val2 = 700000;
> + return IIO_VAL_INT_PLUS_MICRO;
> +
> + case AXP20X_GPIO0_V:
> + case AXP20X_GPIO1_V:
> + *val = 0;
> + *val2 = 500000;
> + return IIO_VAL_INT_PLUS_MICRO;
> +
> + case AXP20X_BATT_V:
> + *val = 1;
> + *val2 = 100000;
> + return IIO_VAL_INT_PLUS_MICRO;
> +
> + case AXP20X_IPSOUT_V:
> + *val = 1;
> + *val2 = 400000;
> + return IIO_VAL_INT_PLUS_MICRO;
> +
> + default:
> + return -EINVAL;
> + }
> +}
> +
> +static int axp20x_adc_scale_current(int channel, int *val, int *val2)
> +{
> + switch (channel) {
> + case AXP20X_ACIN_I:
> + *val = 0;
> + *val2 = 625000;
> + return IIO_VAL_INT_PLUS_MICRO;
> +
> + case AXP20X_VBUS_I:
> + *val = 0;
> + *val2 = 375000;
> + return IIO_VAL_INT_PLUS_MICRO;
> +
> + case AXP20X_BATT_DISCHRG_I:
> + case AXP20X_BATT_CHRG_I:
> + *val = 0;
> + *val2 = 500000;
> + return IIO_VAL_INT_PLUS_MICRO;
> +
> + default:
> + return -EINVAL;
> + }
> +}
> +
> +static int axp20x_adc_scale(struct iio_chan_spec const *chan, int *val,
> + int *val2)
> +{
> + switch (chan->type) {
> + case IIO_VOLTAGE:
> + return axp20x_adc_scale_voltage(chan->channel, val, val2);
> +
> + case IIO_CURRENT:
> + return axp20x_adc_scale_current(chan->channel, val, val2);
> +
> + case IIO_TEMP:
> + *val = 100;
> + return IIO_VAL_INT;
> +
> + default:
> + return -EINVAL;
> + }
> +}
> +
> +static int axp22x_adc_scale(struct iio_chan_spec const *chan, int *val,
> + int *val2)
> +{
> + switch (chan->type) {
> + case IIO_VOLTAGE:
> + if (chan->channel != AXP22X_BATT_V)
> + return -EINVAL;
> +
> + *val = 1;
> + *val2 = 100000;
> + return IIO_VAL_INT_PLUS_MICRO;
> +
> + case IIO_CURRENT:
> + *val = 0;
> + *val2 = 500000;
> + return IIO_VAL_INT_PLUS_MICRO;
> +
> + case IIO_TEMP:
> + *val = 100;
> + return IIO_VAL_INT;
> +
> + default:
> + return -EINVAL;
> + }
> +}
> +
> +static int axp20x_adc_offset_voltage(struct iio_dev *indio_dev, int channel,
> + int *val)
> +{
> + struct axp20x_adc_iio *info = iio_priv(indio_dev);
> + int ret;
> +
> + ret = regmap_read(info->regmap, AXP20X_GPIO10_IN_RANGE, val);
> + if (ret < 0)
> + return ret;
> +
> + switch (channel) {
> + case AXP20X_GPIO0_V:
> + *val &= AXP20X_GPIO10_IN_RANGE_GPIO0;
> + break;
> +
> + case AXP20X_GPIO1_V:
> + *val &= AXP20X_GPIO10_IN_RANGE_GPIO1;
> + break;
> +
> + default:
> + return -EINVAL;
> + }
> +
> + *val = !!(*val) * 700000;
> +
> + return IIO_VAL_INT;
> +}
> +
> +static int axp20x_adc_offset(struct iio_dev *indio_dev,
> + struct iio_chan_spec const *chan, int *val)
> +{
> + switch (chan->type) {
> + case IIO_VOLTAGE:
> + return axp20x_adc_offset_voltage(indio_dev, chan->channel, val);
> +
> + case IIO_TEMP:
> + *val = -1447;
> + return IIO_VAL_INT;
> +
> + default:
> + return -EINVAL;
> + }
> +}
> +
> +static int axp20x_read_raw(struct iio_dev *indio_dev,
> + struct iio_chan_spec const *chan, int *val,
> + int *val2, long mask)
> +{
> + switch (mask) {
> + case IIO_CHAN_INFO_OFFSET:
> + return axp20x_adc_offset(indio_dev, chan, val);
> +
> + case IIO_CHAN_INFO_SCALE:
> + return axp20x_adc_scale(chan, val, val2);
> +
> + case IIO_CHAN_INFO_RAW:
> + return axp20x_adc_raw(indio_dev, chan, val);
> +
> + default:
> + return -EINVAL;
> + }
> +}
> +
> +static int axp22x_read_raw(struct iio_dev *indio_dev,
> + struct iio_chan_spec const *chan, int *val,
> + int *val2, long mask)
> +{
> + switch (mask) {
> + case IIO_CHAN_INFO_OFFSET:
> + *val = -2677;
> + return IIO_VAL_INT;
> +
> + case IIO_CHAN_INFO_SCALE:
> + return axp22x_adc_scale(chan, val, val2);
> +
> + case IIO_CHAN_INFO_RAW:
> + return axp22x_adc_raw(indio_dev, chan, val);
> +
> + default:
> + return -EINVAL;
> + }
> +}
> +
> +static int axp20x_write_raw(struct iio_dev *indio_dev,
> + struct iio_chan_spec const *chan, int val, int val2,
> + long mask)
> +{
> + struct axp20x_adc_iio *info = iio_priv(indio_dev);
> + unsigned int reg, regval;
> +
> + /*
> + * The AXP20X PMIC allows the user to choose between 0V and 0.7V offsets
> + * for (independently) GPIO0 and GPIO1 when in ADC mode.
> + */
> + if (mask != IIO_CHAN_INFO_OFFSET)
> + return -EINVAL;
> +
> + if (val != 0 && val != 700000)
> + return -EINVAL;
> +
> + switch (chan->channel) {
> + case AXP20X_GPIO0_V:
> + reg = AXP20X_GPIO10_IN_RANGE_GPIO0;
> + regval = AXP20X_GPIO10_IN_RANGE_GPIO0_VAL(!!val);
> + break;
> +
> + case AXP20X_GPIO1_V:
> + reg = AXP20X_GPIO10_IN_RANGE_GPIO1;
> + regval = AXP20X_GPIO10_IN_RANGE_GPIO1_VAL(!!val);
> + break;
> +
> + default:
> + return -EINVAL;
> + }
> +
> + return regmap_update_bits(info->regmap, AXP20X_GPIO10_IN_RANGE, reg,
> + regval);
> +}
> +
> +static const struct iio_info axp20x_adc_iio_info = {
> + .read_raw = axp20x_read_raw,
> + .write_raw = axp20x_write_raw,
> + .driver_module = THIS_MODULE,
> +};
> +
> +static const struct iio_info axp22x_adc_iio_info = {
> + .read_raw = axp22x_read_raw,
> + .driver_module = THIS_MODULE,
> +};
> +
> +static int axp20x_adc_rate(int rate)
> +{
> + return AXP20X_ADC_RATE_HZ(rate);
> +}
> +
> +static int axp22x_adc_rate(int rate)
> +{
> + return AXP22X_ADC_RATE_HZ(rate);
> +}
> +
> +struct axp_data {
> + const struct iio_info *iio_info;
> + int num_channels;
> + struct iio_chan_spec const *channels;
> + unsigned long adc_en1_mask;
> + int (*adc_rate)(int rate);
> + bool adc_en2;
> + struct iio_map *maps;
> +};
> +
> +static const struct axp_data axp20x_data = {
> + .iio_info = &axp20x_adc_iio_info,
> + .num_channels = ARRAY_SIZE(axp20x_adc_channels),
> + .channels = axp20x_adc_channels,
> + .adc_en1_mask = AXP20X_ADC_EN1_MASK,
> + .adc_rate = axp20x_adc_rate,
> + .adc_en2 = true,
> + .maps = axp20x_maps,
> +};
> +
> +static const struct axp_data axp22x_data = {
> + .iio_info = &axp22x_adc_iio_info,
> + .num_channels = ARRAY_SIZE(axp22x_adc_channels),
> + .channels = axp22x_adc_channels,
> + .adc_en1_mask = AXP22X_ADC_EN1_MASK,
> + .adc_rate = axp22x_adc_rate,
> + .adc_en2 = false,
> + .maps = axp22x_maps,
> +};
> +
> +static const struct platform_device_id axp20x_adc_id_match[] = {
> + { .name = "axp20x-adc", .driver_data = (kernel_ulong_t)&axp20x_data, },
> + { .name = "axp22x-adc", .driver_data = (kernel_ulong_t)&axp22x_data, },
> + { /* sentinel */ },
> +};
> +MODULE_DEVICE_TABLE(platform, axp20x_adc_id_match);
> +
> +static int axp20x_probe(struct platform_device *pdev)
> +{
> + struct axp20x_adc_iio *info;
> + struct iio_dev *indio_dev;
> + struct axp20x_dev *axp20x_dev;
> + int ret;
> +
> + axp20x_dev = dev_get_drvdata(pdev->dev.parent);
> +
> + indio_dev = devm_iio_device_alloc(&pdev->dev, sizeof(*info));
> + if (!indio_dev)
> + return -ENOMEM;
> +
> + info = iio_priv(indio_dev);
> + platform_set_drvdata(pdev, indio_dev);
> +
> + info->regmap = axp20x_dev->regmap;
> + indio_dev->dev.parent = &pdev->dev;
> + indio_dev->dev.of_node = pdev->dev.of_node;
> + indio_dev->modes = INDIO_DIRECT_MODE;
> +
> + info->data = (struct axp_data *)platform_get_device_id(pdev)->driver_data;
> +
> + indio_dev->name = platform_get_device_id(pdev)->name;
> + indio_dev->info = info->data->iio_info;
> + indio_dev->num_channels = info->data->num_channels;
> + indio_dev->channels = info->data->channels;
> +
> + /* Enable the ADCs on IP */
> + regmap_write(info->regmap, AXP20X_ADC_EN1, info->data->adc_en1_mask);
> +
> + if (info->data->adc_en2)
> + /* Enable GPIO0/1 and internal temperature ADCs */
> + regmap_update_bits(info->regmap, AXP20X_ADC_EN2,
> + AXP20X_ADC_EN2_MASK, AXP20X_ADC_EN2_MASK);
> +
> + /* Configure ADCs rate */
> + regmap_update_bits(info->regmap, AXP20X_ADC_RATE, AXP20X_ADC_RATE_MASK,
> + info->data->adc_rate(100));
> +
> + ret = iio_map_array_register(indio_dev, info->data->maps);
> + if (ret < 0) {
> + dev_err(&pdev->dev, "failed to register IIO maps: %d\n", ret);
> + goto fail_map;
> + }
> +
> + ret = iio_device_register(indio_dev);
> + if (ret < 0) {
> + dev_err(&pdev->dev, "could not register the device\n");
> + goto fail_register;
> + }
> +
> + return 0;
> +
> +fail_register:
> + iio_map_array_unregister(indio_dev);
> +
> +fail_map:
> + regmap_write(info->regmap, AXP20X_ADC_EN1, 0);
> +
> + if (info->data->adc_en2)
> + regmap_write(info->regmap, AXP20X_ADC_EN2, 0);
> +
> + return ret;
> +}
> +
> +static int axp20x_remove(struct platform_device *pdev)
> +{
> + struct iio_dev *indio_dev = platform_get_drvdata(pdev);
> + struct axp20x_adc_iio *info = iio_priv(indio_dev);
> +
> + iio_device_unregister(indio_dev);
> + iio_map_array_unregister(indio_dev);
> +
> + regmap_write(info->regmap, AXP20X_ADC_EN1, 0);
> +
> + if (info->data->adc_en2)
> + regmap_write(info->regmap, AXP20X_ADC_EN2, 0);
> +
> + return 0;
> +}
> +
> +static struct platform_driver axp20x_adc_driver = {
> + .driver = {
> + .name = "axp20x-adc",
> + },
> + .id_table = axp20x_adc_id_match,
> + .probe = axp20x_probe,
> + .remove = axp20x_remove,
> +};
> +
> +module_platform_driver(axp20x_adc_driver);
> +
> +MODULE_DESCRIPTION("ADC driver for AXP20X and AXP22X PMICs");
> +MODULE_AUTHOR("Quentin Schulz <quentin.schulz-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org>");
> +MODULE_LICENSE("GPL");
>
--
Quentin Schulz, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
^ permalink raw reply
* [PATCH] ARM: mxs: add support for I2SE Duckbill 2 boards
From: Michael Heimpold @ 2017-04-10 9:08 UTC (permalink / raw)
To: shawnguo
Cc: mark.rutland, devicetree, stefan.wahren, robh+dt,
Michael Heimpold, Michael Heimpold, kernel, fabio.estevam,
frowand.list, linux-arm-kernel
In-Reply-To: <20170410082400.GA1872@dragon>
The Duckbill devices are small, pen-drive sized boards based on
NXP's i.MX28 SoC. While the initial variants (Duckbill series)
were equipped with a micro SD card slot only, the latest generation
(Duckbill 2 series) have an additional internal eMMC onboard.
To distinguish between both generations, a new device tree
compatible string was introduced. To get the MAC address fixup
applied, we need to check for this new string here, too.
Signed-off-by: Michael Heimpold <michael.heimpold@i2se.com>
---
arch/arm/mach-mxs/mach-mxs.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/arch/arm/mach-mxs/mach-mxs.c b/arch/arm/mach-mxs/mach-mxs.c
index e4f2108..1c6062d 100644
--- a/arch/arm/mach-mxs/mach-mxs.c
+++ b/arch/arm/mach-mxs/mach-mxs.c
@@ -419,7 +419,8 @@ static void __init mxs_machine_init(void)
crystalfontz_init();
else if (of_machine_is_compatible("eukrea,mbmx283lc"))
eukrea_mbmx283lc_init();
- else if (of_machine_is_compatible("i2se,duckbill"))
+ else if (of_machine_is_compatible("i2se,duckbill") ||
+ of_machine_is_compatible("i2se,duckbill-2"))
duckbill_init();
else if (of_machine_is_compatible("msr,m28cu3"))
m28cu3_init();
--
2.6.1
^ permalink raw reply related
* Re: [PATCH v2 2/2] mtd: spi-nor: add driver for STM32 quad spi flash controller
From: Ludovic BARRE @ 2017-04-10 9:08 UTC (permalink / raw)
To: Marek Vasut, Cyrille Pitchen
Cc: David Woodhouse, Brian Norris, Boris Brezillon,
Richard Weinberger, Alexandre Torgue, Rob Herring,
linux-mtd-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <5ec38e39-661d-8a83-4168-b9f3d986bcd1-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
On 04/07/2017 01:55 AM, Marek Vasut wrote:
> On 03/31/2017 07:02 PM, Ludovic Barre wrote:
>> From: Ludovic Barre <ludovic.barre-qxv4g6HH51o@public.gmane.org>
>>
>> The quadspi is a specialized communication interface targeting single,
>> dual or quad SPI Flash memories.
>>
>> It can operate in any of the following modes:
>> -indirect mode: all the operations are performed using the quadspi
>> registers
>> -read memory-mapped mode: the external Flash memory is mapped to the
>> microcontroller address space and is seen by the system as if it was
>> an internal memory
>>
>> Signed-off-by: Ludovic Barre <ludovic.barre-qxv4g6HH51o@public.gmane.org>
>> ---
>> drivers/mtd/spi-nor/Kconfig | 7 +
>> drivers/mtd/spi-nor/Makefile | 1 +
>> drivers/mtd/spi-nor/stm32-quadspi.c | 690 ++++++++++++++++++++++++++++++++++++
>> 3 files changed, 698 insertions(+)
>> create mode 100644 drivers/mtd/spi-nor/stm32-quadspi.c
>>
> [...]
>
>> +struct stm32_qspi_flash {
>> + struct spi_nor nor;
>> + u32 cs;
>> + u32 fsize;
>> + u32 presc;
>> + struct stm32_qspi *qspi;
>> +};
> [...]
>
>> +struct stm32_qspi_cmd {
>> + struct {
>> + u8 addr_width;
>> + u8 dummy;
>> + u8 data;
>> + } conf;
> Is there any benefit in having this structure here or could you just
> make the struct stm32_qspi_cmd flat ?
no benefit, it was just to regroup, so I can do a flat structure
>
>> + u8 opcode;
>> + u32 framemode;
>> + u32 qspimode;
>> + u32 addr;
>> + size_t len;
>> + void *buf;
>> +};
> [...]
>
>> +static ssize_t stm32_qspi_read(struct spi_nor *nor, loff_t from, size_t len,
>> + u_char *buf)
>> +{
>> + struct stm32_qspi_flash *flash = nor->priv;
>> + struct stm32_qspi *qspi = flash->qspi;
>> + struct stm32_qspi_cmd cmd;
>> + int err;
>> +
>> + dev_dbg(qspi->dev, "read(%#.2x): buf:%p from:%#.8x len:%#x\n",
>> + nor->read_opcode, buf, (u32)from, len);
>> +
>> + memset(&cmd, 0, sizeof(cmd));
>> + cmd.opcode = nor->read_opcode;
>> + cmd.conf.addr_width = nor->addr_width;
>> + cmd.addr = (u32)from;
> loff_t (from) can be 64bit ... how do we handle this ?
I'm surprise by the question,
the SPI NOR device uses 3 Bytes or 4 bytes address mode.
So, the stm32 qspi controller has a 32 bit register for NOR address.
On the other hand the framework and other drivers used this variable
(from) like
a 32 bits.
>
>> + cmd.conf.data = 1;
>> + cmd.conf.dummy = nor->read_dummy;
>> + cmd.len = len;
>> + cmd.buf = buf;
>> + cmd.qspimode = qspi->read_mode;
>> +
>> + stm32_qspi_set_framemode(nor, &cmd, true);
>> + err = stm32_qspi_send(flash, &cmd);
>> +
>> + return err ? err : len;
>> +}
> [...]
>
>> +static irqreturn_t stm32_qspi_irq(int irq, void *dev_id)
>> +{
>> + struct stm32_qspi *qspi = (struct stm32_qspi *)dev_id;
>> + u32 cr, sr, fcr = 0;
>> +
>> + cr = readl_relaxed(qspi->io_base + QUADSPI_CR);
>> + sr = readl_relaxed(qspi->io_base + QUADSPI_SR);
>> +
>> + if ((cr & CR_TCIE) && (sr & SR_TCF)) {
>> + /* tx complete */
>> + fcr |= FCR_CTCF;
>> + complete(&qspi->cmd_completion);
>> + } else {
>> + dev_info(qspi->dev, "spurious interrupt\n");
> You probably want to ratelimit this one ...
yes it's better if there is an issue.
>
>> + }
>> +
>> + writel_relaxed(fcr, qspi->io_base + QUADSPI_FCR);
>> +
>> + return IRQ_HANDLED;
>> +}
>> +
>> +static int stm32_qspi_prep(struct spi_nor *nor, enum spi_nor_ops ops)
>> +{
>> + struct stm32_qspi_flash *flash = nor->priv;
>> + struct stm32_qspi *qspi = flash->qspi;
>> +
>> + mutex_lock(&qspi->lock);
>> + return 0;
>> +}
>> +
>> +static void stm32_qspi_unprep(struct spi_nor *nor, enum spi_nor_ops ops)
>> +{
>> + struct stm32_qspi_flash *flash = nor->priv;
>> + struct stm32_qspi *qspi = flash->qspi;
>> +
>> + mutex_unlock(&qspi->lock);
>> +}
>> +
>> +static int stm32_qspi_flash_setup(struct stm32_qspi *qspi,
>> + struct device_node *np)
>> +{
>> + u32 width, flash_read, presc, cs_num, max_rate = 0;
>> + struct stm32_qspi_flash *flash;
>> + struct mtd_info *mtd;
>> + int ret;
>> +
>> + of_property_read_u32(np, "reg", &cs_num);
>> + if (cs_num >= STM32_MAX_NORCHIP)
>> + return -EINVAL;
>> +
>> + of_property_read_u32(np, "spi-max-frequency", &max_rate);
>> + if (!max_rate)
>> + return -EINVAL;
>> +
>> + presc = DIV_ROUND_UP(qspi->clk_rate, max_rate) - 1;
>> +
>> + if (of_property_read_u32(np, "spi-rx-bus-width", &width))
>> + width = 1;
>> +
>> + if (width == 4)
>> + flash_read = SPI_NOR_QUAD;
>> + else if (width == 2)
>> + flash_read = SPI_NOR_DUAL;
>> + else if (width == 1)
>> + flash_read = SPI_NOR_NORMAL;
>> + else
>> + return -EINVAL;
>> +
>> + flash = &qspi->flash[cs_num];
>> + flash->qspi = qspi;
>> + flash->cs = cs_num;
>> + flash->presc = presc;
>> +
>> + flash->nor.dev = qspi->dev;
>> + spi_nor_set_flash_node(&flash->nor, np);
>> + flash->nor.priv = flash;
>> + mtd = &flash->nor.mtd;
>> + mtd->priv = &flash->nor;
>> +
>> + flash->nor.read = stm32_qspi_read;
>> + flash->nor.write = stm32_qspi_write;
>> + flash->nor.erase = stm32_qspi_erase;
>> + flash->nor.read_reg = stm32_qspi_read_reg;
>> + flash->nor.write_reg = stm32_qspi_write_reg;
>> + flash->nor.prepare = stm32_qspi_prep;
>> + flash->nor.unprepare = stm32_qspi_unprep;
>> +
>> + writel_relaxed(LPTR_DFT_TIMEOUT, qspi->io_base + QUADSPI_LPTR);
>> +
>> + writel_relaxed(CR_PRESC(presc) | CR_FTHRES(3) | CR_TCEN | CR_SSHIFT
>> + | CR_EN, qspi->io_base + QUADSPI_CR);
>> +
>> + /*
>> + * in stm32 qspi controller, QUADSPI_DCR register has a fsize field
>> + * which define the size of nor flash.
>> + * if fsize is NULL, the controller can't sent spi-nor command.
>> + * set a temporary value just to discover the nor flash with
>> + * "spi_nor_scan". After, the right value (mtd->size) can be set.
>> + */
> Is 25 the smallest value ? Use a macro for this ...
25 is an arbitrary choice, I will define a smallest value
>
>> + flash->fsize = 25;
>> +
>> + ret = spi_nor_scan(&flash->nor, NULL, flash_read);
>> + if (ret) {
>> + dev_err(qspi->dev, "device scan failed\n");
>> + return ret;
>> + }
>> +
>> + /* number of bytes in Flash memory = 2^[FSIZE+1] */
>> + flash->fsize = __fls(mtd->size) - 1;
>> +
>> + writel_relaxed(DCR_CSHT(1), qspi->io_base + QUADSPI_DCR);
>> +
>> + ret = mtd_device_register(mtd, NULL, 0);
>> + if (ret) {
>> + dev_err(qspi->dev, "mtd device parse failed\n");
>> + return ret;
>> + }
>> +
>> + dev_dbg(qspi->dev, "read mm:%s cs:%d bus:%d\n",
>> + qspi->read_mode == CCR_FMODE_MM ? "yes" : "no", cs_num, width);
>> +
>> + return 0;
>> +}
> [...]
>
--
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: dts: at91: sama5d3_xplained: not all ADC channels are available
From: Nicolas Ferre @ 2017-04-10 9:04 UTC (permalink / raw)
To: Ludovic Desroches,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA
Cc: alexandre.belloni-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8,
Eugen.Hristev-UWL1GkI3JZL3oGB3hsPCZA, # 3 . 16+
In-Reply-To: <20170410082517.19628-2-ludovic.desroches-UWL1GkI3JZL3oGB3hsPCZA@public.gmane.org>
Le 10/04/2017 à 10:25, Ludovic Desroches a écrit :
> Remove ADC channels that are not available by default on the sama5d3_xplained
> board (resistor not populated) in order to not create confusion.
>
> Signed-off-by: Ludovic Desroches <ludovic.desroches-UWL1GkI3JZL3oGB3hsPCZA@public.gmane.org>
> Cc: <stable-u79uwXL29TY76Z2rM5mHXA@public.gmane.org> # 3.16+
Acked-by: Nicolas Ferre <nicolas.ferre-UWL1GkI3JZL3oGB3hsPCZA@public.gmane.org>
> ---
> arch/arm/boot/dts/at91-sama5d3_xplained.dts | 4 +---
> 1 file changed, 1 insertion(+), 3 deletions(-)
>
> diff --git a/arch/arm/boot/dts/at91-sama5d3_xplained.dts b/arch/arm/boot/dts/at91-sama5d3_xplained.dts
> index 7a0fa1a..5a53fcf 100644
> --- a/arch/arm/boot/dts/at91-sama5d3_xplained.dts
> +++ b/arch/arm/boot/dts/at91-sama5d3_xplained.dts
> @@ -163,9 +163,9 @@
>
> adc0: adc@f8018000 {
> atmel,adc-vref = <3300>;
> + atmel,adc-channels-used = <0xfe>;
> pinctrl-0 = <
> &pinctrl_adc0_adtrg
> - &pinctrl_adc0_ad0
> &pinctrl_adc0_ad1
> &pinctrl_adc0_ad2
> &pinctrl_adc0_ad3
> @@ -173,8 +173,6 @@
> &pinctrl_adc0_ad5
> &pinctrl_adc0_ad6
> &pinctrl_adc0_ad7
> - &pinctrl_adc0_ad8
> - &pinctrl_adc0_ad9
> >;
> status = "okay";
> };
>
--
Nicolas Ferre
--
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 1/2] ARM: dts: at91: sama5d3_xplained: fix ADC vref
From: Nicolas Ferre @ 2017-04-10 9:04 UTC (permalink / raw)
To: Ludovic Desroches, linux-arm-kernel, devicetree, linux-kernel
Cc: alexandre.belloni, Eugen.Hristev, # 3 . 16+
In-Reply-To: <20170410082517.19628-1-ludovic.desroches@microchip.com>
Le 10/04/2017 à 10:25, Ludovic Desroches a écrit :
> The voltage reference for the ADC is not 3V but 3.3V since it is connected to
> VDDANA.
>
> Signed-off-by: Ludovic Desroches <ludovic.desroches@microchip.com>
> Cc: <stable@vger.kernel.org> # 3.16+
Acked-by: Nicolas Ferre <nicolas.ferre@microchip.com>
> ---
> arch/arm/boot/dts/at91-sama5d3_xplained.dts | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/arch/arm/boot/dts/at91-sama5d3_xplained.dts b/arch/arm/boot/dts/at91-sama5d3_xplained.dts
> index c51fc65..7a0fa1a 100644
> --- a/arch/arm/boot/dts/at91-sama5d3_xplained.dts
> +++ b/arch/arm/boot/dts/at91-sama5d3_xplained.dts
> @@ -162,6 +162,7 @@
> };
>
> adc0: adc@f8018000 {
> + atmel,adc-vref = <3300>;
> pinctrl-0 = <
> &pinctrl_adc0_adtrg
> &pinctrl_adc0_ad0
>
--
Nicolas Ferre
^ permalink raw reply
* Re: [PATCH v3 0/8] Add support for DCMI camera interface of STMicroelectronics STM32 SoC series
From: Hans Verkuil @ 2017-04-10 8:55 UTC (permalink / raw)
To: Hugues Fruchet, Rob Herring, Mark Rutland, Maxime Coquelin,
Alexandre Torgue, Mauro Carvalho Chehab
Cc: devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-media-u79uwXL29TY76Z2rM5mHXA, Benjamin Gaignard,
Yannick Fertre
In-Reply-To: <1491320678-17246-1-git-send-email-hugues.fruchet-qxv4g6HH51o@public.gmane.org>
On 04/04/2017 05:44 PM, Hugues Fruchet wrote:
> This patchset introduces a basic support for Digital Camera Memory Interface
> (DCMI) of STMicroelectronics STM32 SoC series.
>
> This first basic support implements RGB565 & YUV frame grabbing.
> Cropping and JPEG support will be added later on.
>
> This has been tested on STM324x9I-EVAL evaluation board embedding
> an OV2640 camera sensor.
>
> This driver depends on:
> - [PATCHv6 00/14] atmel-isi/ov7670/ov2640: convert to standalone drivers http://www.spinics.net/lists/linux-media/msg113480.html
>
> ===========
> = history =
> ===========
> version 3:
> - stm32-dcmi: Add "Reviewed-by: Hans Verkuil <hans.verkuil-FYB4Gu1CFyUAvxtiuMwx3w@public.gmane.org>"
> - dt-bindings: Fix remarks from Rob Herring:
> http://www.mail-archive.com/linux-media-u79uwXL29TY76Z2rM5mHXA@public.gmane.org/msg110956.html
>
> version 2:
> - Fix a Kbuild warning in probe:
> http://www.mail-archive.com/linux-media-u79uwXL29TY76Z2rM5mHXA@public.gmane.org/msg110678.html
> - Fix a warning in dcmi_queue_setup()
> - dt-bindings: warn on sensor signals level inversion in board example
> - Typos fixing
>
> version 1:
> - Initial submission
>
> ===================
> = v4l2-compliance =
> ===================
> Below is the v4l2-compliance report for this current version of the DCMI camera interface.
> v4l2-compliance has been built from v4l-utils-1.12.3.
Please test with 'v4l2-compliance -s -f' as well and mail me the output of
that test.
Once you have the Acks for the DT/bindings patches just let me know and I'll
make a pull request.
Regards,
Hans
>
> v4l2-compliance SHA : f5f45e17ee98a0ebad7836ade2b34ceec909d751
>
> Driver Info:
> Driver name : stm32-dcmi
> Card type : STM32 Digital Camera Memory Int
> Bus info : platform:dcmi
> Driver version: 4.11.0
> Capabilities : 0x85200001
> Video Capture
> Read/Write
> Streaming
> Extended Pix Format
> Device Capabilities
> Device Caps : 0x05200001
> Video Capture
> Read/Write
> Streaming
> Extended Pix Format
>
> Compliance test for device /dev/video0 (not using libv4l2):
>
> Required ioctls:
> test VIDIOC_QUERYCAP: OK
>
> Allow for multiple opens:
> test second video open: OK
> test VIDIOC_QUERYCAP: OK
> test VIDIOC_G/S_PRIORITY: OK
> test for unlimited opens: OK
>
> Debug ioctls:
> test VIDIOC_DBG_G/S_REGISTER: OK (Not Supported)
> test VIDIOC_LOG_STATUS: OK
>
> Input ioctls:
> test VIDIOC_G/S_TUNER/ENUM_FREQ_BANDS: OK (Not Supported)
> test VIDIOC_G/S_FREQUENCY: OK (Not Supported)
> test VIDIOC_S_HW_FREQ_SEEK: OK (Not Supported)
> test VIDIOC_ENUMAUDIO: OK (Not Supported)
> test VIDIOC_G/S/ENUMINPUT: OK
> test VIDIOC_G/S_AUDIO: OK (Not Supported)
> Inputs: 1 Audio Inputs: 0 Tuners: 0
>
> Output ioctls:
> test VIDIOC_G/S_MODULATOR: OK (Not Supported)
> test VIDIOC_G/S_FREQUENCY: OK (Not Supported)
> test VIDIOC_ENUMAUDOUT: OK (Not Supported)
> test VIDIOC_G/S/ENUMOUTPUT: OK (Not Supported)
> test VIDIOC_G/S_AUDOUT: OK (Not Supported)
> Outputs: 0 Audio Outputs: 0 Modulators: 0
>
> Input/Output configuration ioctls:
> test VIDIOC_ENUM/G/S/QUERY_STD: OK (Not Supported)
> test VIDIOC_ENUM/G/S/QUERY_DV_TIMINGS: OK (Not Supported)
> test VIDIOC_DV_TIMINGS_CAP: OK (Not Supported)
> test VIDIOC_G/S_EDID: OK (Not Supported)
>
> Test input 0:
>
> Control ioctls:
> test VIDIOC_QUERY_EXT_CTRL/QUERYMENU: OK
> test VIDIOC_QUERYCTRL: OK
> test VIDIOC_G/S_CTRL: OK
> test VIDIOC_G/S/TRY_EXT_CTRLS: OK
> test VIDIOC_(UN)SUBSCRIBE_EVENT/DQEVENT: OK
> test VIDIOC_G/S_JPEGCOMP: OK (Not Supported)
> Standard Controls: 3 Private Controls: 0
>
> Format ioctls:
> test VIDIOC_ENUM_FMT/FRAMESIZES/FRAMEINTERVALS: OK
> test VIDIOC_G/S_PARM: OK (Not Supported)
> test VIDIOC_G_FBUF: OK (Not Supported)
> test VIDIOC_G_FMT: OK
> test VIDIOC_TRY_FMT: OK
> test VIDIOC_S_FMT: OK
> test VIDIOC_G_SLICED_VBI_CAP: OK (Not Supported)
> test Cropping: OK (Not Supported)
> test Composing: OK (Not Supported)
> test Scaling: OK
>
> Codec ioctls:
> test VIDIOC_(TRY_)ENCODER_CMD: OK (Not Supported)
> test VIDIOC_G_ENC_INDEX: OK (Not Supported)
> test VIDIOC_(TRY_)DECODER_CMD: OK (Not Supported)
>
> Buffer ioctls:
> test VIDIOC_REQBUFS/CREATE_BUFS/QUERYBUF: OK
> test VIDIOC_EXPBUF: OK
>
> Test input 0:
>
> Streaming ioctls:
> test read/write: OK
> test MMAP: OK
> test USERPTR: OK (Not Supported)
> test DMABUF: Cannot test, specify --expbuf-device
>
>
> Total: 46, Succeeded: 46, Failed: 0, Warnings: 0
>
> Hugues Fruchet (8):
> dt-bindings: Document STM32 DCMI bindings
> [media] stm32-dcmi: STM32 DCMI camera interface driver
> ARM: dts: stm32: Enable DCMI support on STM32F429 MCU
> ARM: dts: stm32: Enable DCMI camera interface on STM32F429-EVAL board
> ARM: dts: stm32: Enable STMPE1600 gpio expander of STM32F429-EVAL
> board
> ARM: dts: stm32: Enable OV2640 camera support of STM32F429-EVAL board
> ARM: configs: stm32: STMPE1600 GPIO expander
> ARM: configs: stm32: DCMI + OV2640 camera support
>
> .../devicetree/bindings/media/st,stm32-dcmi.txt | 46 +
> arch/arm/boot/dts/stm32429i-eval.dts | 56 +
> arch/arm/boot/dts/stm32f429.dtsi | 37 +
> arch/arm/configs/stm32_defconfig | 9 +
> drivers/media/platform/Kconfig | 12 +
> drivers/media/platform/Makefile | 2 +
> drivers/media/platform/stm32/Makefile | 1 +
> drivers/media/platform/stm32/stm32-dcmi.c | 1419 ++++++++++++++++++++
> 8 files changed, 1582 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/media/st,stm32-dcmi.txt
> create mode 100644 drivers/media/platform/stm32/Makefile
> create mode 100644 drivers/media/platform/stm32/stm32-dcmi.c
>
--
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 v4 2/3] Broadcom USB DRD Phy driver for Northstar2
From: Kishon Vijay Abraham I @ 2017-04-10 8:37 UTC (permalink / raw)
To: Raviteja Garimella
Cc: Rob Herring, Mark Rutland, Ray Jui, Scott Branden, Jon Mason,
Catalin Marinas, Will Deacon, devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA, BCM Kernel Feedback,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r
In-Reply-To: <CAEHZuqM7YUxtN9F+5qqZ6HHBqLP0DuwotQv9ZyaN5UtrsN7j5A-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
Hi,
On Wednesday 05 April 2017 07:40 PM, Raviteja Garimella wrote:
> Hi Kishon,
>
> On Wed, Apr 5, 2017 at 7:04 PM, Kishon Vijay Abraham I <kishon-l0cyMroinI0@public.gmane.org> wrote:
>> Hi Ravi,
>>
>> On Wednesday 05 April 2017 06:30 PM, Raviteja Garimella wrote:
>>> Hi Kishon,
>>>
>>> On Wed, Apr 5, 2017 at 4:30 PM, Kishon Vijay Abraham I <kishon-l0cyMroinI0@public.gmane.org> wrote:
>>>> Hi,
>>>>
>>>> On Tuesday 28 March 2017 05:57 PM, Raviteja Garimella wrote:
>>>>> This is driver for USB DRD Phy used in Broadcom's Northstar2
>>>>> SoC. The phy can be configured to be in Device mode or Host
>>>>> mode based on the type of cable connected to the port. The
>>>>> driver registers to extcon framework to get appropriate
>>>>> connect events for Host/Device cables connect/disconnect
>>>>> states based on VBUS and ID interrupts.
>>>>
>>>> $patch should be phy: phy-bcm-ns2-usbdrd: USB DRD Phy driver for Broadcoms
>>>> Northstar2.
>>>>
>>>
>>> Will do.
>>>
>>>> Sorry for not letting you know this earlier. But I feel the design of the
>>>> driver should be changed. Extcon shouldn't be used here. The extcon
>>>> notifications should be sent to the consumer driver and the consumer driver
>>>> should be responsible for invoking the phy ops.
>>>>
>>>
>>> The consumer drivers here would be a UDC driver (USB device
>>> controller), EHCI and OHCI host controller drivers.
>>> I was already suggested in UDC driver review to deal with extcon in Phy driver.
>>>
>>> This phy connects to 2 host controllers, and one device controller.
>>> That's the design in Broadcom Northstar2
>>> platform. The values of the VBUS and ID pins of this port are
>>> determined based on the type of the cable (device cable
>>> or host cable). And. phy has to be configured accordingly.
>>>
>>>> The phy ops being invoked during extcon events doesn't look right.
>>>
>>> Could you please elaborate on the concern, so that we can think of
>>> mitigating those issues in this driver?
>>> Since we are dealing with phy init/shutdown in this driver itself, are
>>> you okay with moving the extcon handling code
>>> out of phy ops ?
>>
>> yeah, For e.g., ns2_drd_phy_init is part of phy_ops and is being invoked from
>> extcon events too. Can a phy which is initialized by a phy consumer (say your
>> UDC invokes phy_init) can be shutdown by an extcon event?
>>
>> Maybe a clear explanation of when phy_ops here will be invoked and when it will
>> set using extcon events might help.
>>
>
> Say, we have a USB pendrive which is connected to the DRD port through
> a host cable.
> Now the PHY will be initialized to be in host mode.
> When the pendrive is unplugged, and we now connect the NS2 device to
> some linux PC,
> now the PHY has to be shutdown, and re-initialized to be in Device mode.
>
> On unplug event, it is set neither to Host nor Device mode (basically
> shutdown). Next time which ever cable is connected, the PHY is
> initialized to the respective
> mode.
>
> Please let me know if it's fine to do these initializations outside
> phy ops, because those will
> be irrelevant for phy consumers (the controllers) as it's anyways
> dealt in the phy driver through
> extcon.
Yes. We shouldn't add phy_ops just for the sake of it. I think this should be
made as a purely extcon driver (though there are a couple of bits that looks
like initializing PHY) and keep it in drivers/extcon.
Thanks
Kishon
--
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 9/9] arm, arm64, drivers: add a prefix to drivers arch_topology interfaces
From: Catalin Marinas @ 2017-04-10 8:32 UTC (permalink / raw)
To: Juri Lelli
Cc: linux-kernel-u79uwXL29TY76Z2rM5mHXA, mark.rutland-5wv7dgnIgG8,
devicetree-u79uwXL29TY76Z2rM5mHXA, lorenzo.pieralisi-5wv7dgnIgG8,
vincent.guittot-QSEj5FYQhm4dnm+yROfE0A,
linux-pm-u79uwXL29TY76Z2rM5mHXA, peterz-wEGCiKHe2LqWVfeAwA7xHQ,
broonie-DgEjT+Ai2ygdnm+yROfE0A, will.deacon-5wv7dgnIgG8,
gregkh-hQyY1W1yCW8ekmWlsbkhG0B+6BGkLq7r,
dietmar.eggemann-5wv7dgnIgG8, robh+dt-DgEjT+Ai2ygdnm+yROfE0A,
sudeep.holla-5wv7dgnIgG8, linux-lFZ/pmaqli7XmaaqVzeoHQ,
morten.rasmussen-5wv7dgnIgG8,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r
In-Reply-To: <20170327131825.32134-10-juri.lelli-5wv7dgnIgG8@public.gmane.org>
On Mon, Mar 27, 2017 at 02:18:25PM +0100, Juri Lelli wrote:
> Now that some functions that deal with arch topology information live
> under drivers, there is a clash of naming that might create confusion.
>
> Tidy things up by creating a drivers namespace for interfaces used by
> arch code; achieve this by prepending a 'atd_' (arch topology driver)
> prefix to driver interfaces.
>
> Signed-off-by: Juri Lelli <juri.lelli-5wv7dgnIgG8@public.gmane.org>
> ---
> arch/arm/kernel/topology.c | 8 ++++----
> arch/arm64/kernel/topology.c | 4 ++--
> drivers/base/arch_topology.c | 20 ++++++++++----------
> include/linux/arch_topology.h | 8 ++++----
> 4 files changed, 20 insertions(+), 20 deletions(-)
Acked-by: Catalin Marinas <catalin.marinas-5wv7dgnIgG8@public.gmane.org>
--
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 8/9] arm,arm64,drivers: move externs in a new header file
From: Catalin Marinas @ 2017-04-10 8:31 UTC (permalink / raw)
To: Juri Lelli
Cc: linux-kernel-u79uwXL29TY76Z2rM5mHXA, mark.rutland-5wv7dgnIgG8,
devicetree-u79uwXL29TY76Z2rM5mHXA, lorenzo.pieralisi-5wv7dgnIgG8,
vincent.guittot-QSEj5FYQhm4dnm+yROfE0A,
linux-pm-u79uwXL29TY76Z2rM5mHXA, peterz-wEGCiKHe2LqWVfeAwA7xHQ,
broonie-DgEjT+Ai2ygdnm+yROfE0A, will.deacon-5wv7dgnIgG8,
gregkh-hQyY1W1yCW8ekmWlsbkhG0B+6BGkLq7r,
dietmar.eggemann-5wv7dgnIgG8, robh+dt-DgEjT+Ai2ygdnm+yROfE0A,
sudeep.holla-5wv7dgnIgG8, linux-lFZ/pmaqli7XmaaqVzeoHQ,
morten.rasmussen-5wv7dgnIgG8,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r
In-Reply-To: <20170327131825.32134-9-juri.lelli-5wv7dgnIgG8@public.gmane.org>
On Mon, Mar 27, 2017 at 02:18:24PM +0100, Juri Lelli wrote:
> Create a new header file (include/linux/arch_topology.h) and put there
> declarations of interfaces used by arm, arm64 and drivers code.
>
> Signed-off-by: Juri Lelli <juri.lelli-5wv7dgnIgG8@public.gmane.org>
> ---
> arch/arm/kernel/topology.c | 7 +------
> arch/arm64/kernel/topology.c | 4 +---
> drivers/base/arch_topology.c | 1 +
> include/linux/arch_topology.h | 17 +++++++++++++++++
> 4 files changed, 20 insertions(+), 9 deletions(-)
> create mode 100644 include/linux/arch_topology.h
Acked-by: Catalin Marinas <catalin.marinas-5wv7dgnIgG8@public.gmane.org>
--
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 7/9] arm,arm64,drivers: reduce scope of cap_parsing_failed
From: Catalin Marinas @ 2017-04-10 8:31 UTC (permalink / raw)
To: Juri Lelli
Cc: linux-kernel, mark.rutland, devicetree, lorenzo.pieralisi,
vincent.guittot, linux-pm, peterz, broonie, will.deacon, gregkh,
dietmar.eggemann, robh+dt, sudeep.holla, linux, morten.rasmussen,
linux-arm-kernel
In-Reply-To: <20170327131825.32134-8-juri.lelli@arm.com>
On Mon, Mar 27, 2017 at 02:18:23PM +0100, Juri Lelli wrote:
> Reduce the scope of cap_parsing_failed (making it static in
> drivers/base/arch_topology.c) by slightly changing {arm,arm64} DT
> parsing code.
>
> For arm checking for !cap_parsing_failed before calling normalize_
> cpu_capacity() is superfluous, as returning an error from parse_
> cpu_capacity() (above) means cap_from _dt is set to false.
>
> For arm64 we can simply check if raw_capacity points to something,
> which is not if capacity parsing has failed.
>
> Suggested-by: Morten Rasmussen <morten.rasmussen@arm.com>
> Signed-off-by: Juri Lelli <juri.lelli@arm.com>
> ---
> arch/arm/kernel/topology.c | 3 +--
> arch/arm64/kernel/topology.c | 5 +----
> drivers/base/arch_topology.c | 4 ++--
> 3 files changed, 4 insertions(+), 8 deletions(-)
Acked-by: Catalin Marinas <catalin.marinas@arm.com>
^ permalink raw reply
* Re: [PATCH v4 2/3] Broadcom USB DRD Phy driver for Northstar2
From: Raviteja Garimella @ 2017-04-10 8:30 UTC (permalink / raw)
To: Kishon Vijay Abraham I
Cc: Rob Herring, Mark Rutland, Ray Jui, Scott Branden, Jon Mason,
Catalin Marinas, Will Deacon, devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA, BCM Kernel Feedback,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r
In-Reply-To: <a78f6948-0900-56f9-dc0c-5b161c470847-l0cyMroinI0@public.gmane.org>
Hi
On Mon, Apr 10, 2017 at 1:57 PM, Kishon Vijay Abraham I <kishon-l0cyMroinI0@public.gmane.org> wrote:
> Hi,
>
> On Monday 10 April 2017 12:57 PM, Raviteja Garimella wrote:
>> Hi,
>>
>> On Mon, Apr 10, 2017 at 10:55 AM, Kishon Vijay Abraham I <kishon-l0cyMroinI0@public.gmane.org> wrote:
>>> Hi,
>>>
>>> On Wednesday 05 April 2017 07:40 PM, Raviteja Garimella wrote:
>>>> Hi Kishon,
>>>>
>>>> On Wed, Apr 5, 2017 at 7:04 PM, Kishon Vijay Abraham I <kishon-l0cyMroinI0@public.gmane.org> wrote:
>>>>> Hi Ravi,
>>>>>
>>>>> On Wednesday 05 April 2017 06:30 PM, Raviteja Garimella wrote:
>>>>>> Hi Kishon,
>>>>>>
>>>>>> On Wed, Apr 5, 2017 at 4:30 PM, Kishon Vijay Abraham I <kishon-l0cyMroinI0@public.gmane.org> wrote:
>>>>>>> Hi,
>>>>>>>
>>>>>>> On Tuesday 28 March 2017 05:57 PM, Raviteja Garimella wrote:
>>>>>>>> This is driver for USB DRD Phy used in Broadcom's Northstar2
>>>>>>>> SoC. The phy can be configured to be in Device mode or Host
>>>>>>>> mode based on the type of cable connected to the port. The
>>>>>>>> driver registers to extcon framework to get appropriate
>>>>>>>> connect events for Host/Device cables connect/disconnect
>>>>>>>> states based on VBUS and ID interrupts.
>>>>>>>
>>>>>>> $patch should be phy: phy-bcm-ns2-usbdrd: USB DRD Phy driver for Broadcoms
>>>>>>> Northstar2.
>>>>>>>
>>>>>>
>>>>>> Will do.
>>>>>>
>>>>>>> Sorry for not letting you know this earlier. But I feel the design of the
>>>>>>> driver should be changed. Extcon shouldn't be used here. The extcon
>>>>>>> notifications should be sent to the consumer driver and the consumer driver
>>>>>>> should be responsible for invoking the phy ops.
>>>>>>>
>>>>>>
>>>>>> The consumer drivers here would be a UDC driver (USB device
>>>>>> controller), EHCI and OHCI host controller drivers.
>>>>>> I was already suggested in UDC driver review to deal with extcon in Phy driver.
>>>>>>
>>>>>> This phy connects to 2 host controllers, and one device controller.
>>>>>> That's the design in Broadcom Northstar2
>>>>>> platform. The values of the VBUS and ID pins of this port are
>>>>>> determined based on the type of the cable (device cable
>>>>>> or host cable). And. phy has to be configured accordingly.
>>>>>>
>>>>>>> The phy ops being invoked during extcon events doesn't look right.
>>>>>>
>>>>>> Could you please elaborate on the concern, so that we can think of
>>>>>> mitigating those issues in this driver?
>>>>>> Since we are dealing with phy init/shutdown in this driver itself, are
>>>>>> you okay with moving the extcon handling code
>>>>>> out of phy ops ?
>>>>>
>>>>> yeah, For e.g., ns2_drd_phy_init is part of phy_ops and is being invoked from
>>>>> extcon events too. Can a phy which is initialized by a phy consumer (say your
>>>>> UDC invokes phy_init) can be shutdown by an extcon event?
>>>>>
>>>>> Maybe a clear explanation of when phy_ops here will be invoked and when it will
>>>>> set using extcon events might help.
>>>>>
>>>>
>>>> Say, we have a USB pendrive which is connected to the DRD port through
>>>> a host cable.
>>>> Now the PHY will be initialized to be in host mode.
>>>> When the pendrive is unplugged, and we now connect the NS2 device to
>>>> some linux PC,
>>>> now the PHY has to be shutdown, and re-initialized to be in Device mode.
>>>>
>>>> On unplug event, it is set neither to Host nor Device mode (basically
>>>> shutdown). Next time which ever cable is connected, the PHY is
>>>> initialized to the respective
>>>> mode.
>>>>
>>>> Please let me know if it's fine to do these initializations outside
>>>> phy ops, because those will
>>>> be irrelevant for phy consumers (the controllers) as it's anyways
>>>> dealt in the phy driver through
>>>> extcon.
>>>
>>> How does the consumer get to know whether they have to operate in host mode or
>>> device mode?
>>>
>> In NS2, we have host controllers and device controller (not OTG/other
>> that can switch
>> between host and device mode). It's only phy that can be in host/device mode.
>> Since both Host Controllers and Device Controller are connected to the same PHY,
>> it is based on the extcon logic (the type of cable connected) that PHY
>> will be in one
>> of the modes host/device and the respective controller will operate.
>
> So at a point of time either the host controller or the device controller will
> be active? and the PHY decides which of them should be active? Is that right?
>
Yes
Thanks,
Ravi
> Thanks
> Kishon
--
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 v4 2/3] Broadcom USB DRD Phy driver for Northstar2
From: Kishon Vijay Abraham I @ 2017-04-10 8:27 UTC (permalink / raw)
To: Raviteja Garimella
Cc: Rob Herring, Mark Rutland, Ray Jui, Scott Branden, Jon Mason,
Catalin Marinas, Will Deacon, devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA, BCM Kernel Feedback,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r
In-Reply-To: <CAEHZuqMJU=ZLL2xsbtpHLC6SU4uzNBpZmPPADs-g7=OXJyCbBQ-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
Hi,
On Monday 10 April 2017 12:57 PM, Raviteja Garimella wrote:
> Hi,
>
> On Mon, Apr 10, 2017 at 10:55 AM, Kishon Vijay Abraham I <kishon-l0cyMroinI0@public.gmane.org> wrote:
>> Hi,
>>
>> On Wednesday 05 April 2017 07:40 PM, Raviteja Garimella wrote:
>>> Hi Kishon,
>>>
>>> On Wed, Apr 5, 2017 at 7:04 PM, Kishon Vijay Abraham I <kishon-l0cyMroinI0@public.gmane.org> wrote:
>>>> Hi Ravi,
>>>>
>>>> On Wednesday 05 April 2017 06:30 PM, Raviteja Garimella wrote:
>>>>> Hi Kishon,
>>>>>
>>>>> On Wed, Apr 5, 2017 at 4:30 PM, Kishon Vijay Abraham I <kishon-l0cyMroinI0@public.gmane.org> wrote:
>>>>>> Hi,
>>>>>>
>>>>>> On Tuesday 28 March 2017 05:57 PM, Raviteja Garimella wrote:
>>>>>>> This is driver for USB DRD Phy used in Broadcom's Northstar2
>>>>>>> SoC. The phy can be configured to be in Device mode or Host
>>>>>>> mode based on the type of cable connected to the port. The
>>>>>>> driver registers to extcon framework to get appropriate
>>>>>>> connect events for Host/Device cables connect/disconnect
>>>>>>> states based on VBUS and ID interrupts.
>>>>>>
>>>>>> $patch should be phy: phy-bcm-ns2-usbdrd: USB DRD Phy driver for Broadcoms
>>>>>> Northstar2.
>>>>>>
>>>>>
>>>>> Will do.
>>>>>
>>>>>> Sorry for not letting you know this earlier. But I feel the design of the
>>>>>> driver should be changed. Extcon shouldn't be used here. The extcon
>>>>>> notifications should be sent to the consumer driver and the consumer driver
>>>>>> should be responsible for invoking the phy ops.
>>>>>>
>>>>>
>>>>> The consumer drivers here would be a UDC driver (USB device
>>>>> controller), EHCI and OHCI host controller drivers.
>>>>> I was already suggested in UDC driver review to deal with extcon in Phy driver.
>>>>>
>>>>> This phy connects to 2 host controllers, and one device controller.
>>>>> That's the design in Broadcom Northstar2
>>>>> platform. The values of the VBUS and ID pins of this port are
>>>>> determined based on the type of the cable (device cable
>>>>> or host cable). And. phy has to be configured accordingly.
>>>>>
>>>>>> The phy ops being invoked during extcon events doesn't look right.
>>>>>
>>>>> Could you please elaborate on the concern, so that we can think of
>>>>> mitigating those issues in this driver?
>>>>> Since we are dealing with phy init/shutdown in this driver itself, are
>>>>> you okay with moving the extcon handling code
>>>>> out of phy ops ?
>>>>
>>>> yeah, For e.g., ns2_drd_phy_init is part of phy_ops and is being invoked from
>>>> extcon events too. Can a phy which is initialized by a phy consumer (say your
>>>> UDC invokes phy_init) can be shutdown by an extcon event?
>>>>
>>>> Maybe a clear explanation of when phy_ops here will be invoked and when it will
>>>> set using extcon events might help.
>>>>
>>>
>>> Say, we have a USB pendrive which is connected to the DRD port through
>>> a host cable.
>>> Now the PHY will be initialized to be in host mode.
>>> When the pendrive is unplugged, and we now connect the NS2 device to
>>> some linux PC,
>>> now the PHY has to be shutdown, and re-initialized to be in Device mode.
>>>
>>> On unplug event, it is set neither to Host nor Device mode (basically
>>> shutdown). Next time which ever cable is connected, the PHY is
>>> initialized to the respective
>>> mode.
>>>
>>> Please let me know if it's fine to do these initializations outside
>>> phy ops, because those will
>>> be irrelevant for phy consumers (the controllers) as it's anyways
>>> dealt in the phy driver through
>>> extcon.
>>
>> How does the consumer get to know whether they have to operate in host mode or
>> device mode?
>>
> In NS2, we have host controllers and device controller (not OTG/other
> that can switch
> between host and device mode). It's only phy that can be in host/device mode.
> Since both Host Controllers and Device Controller are connected to the same PHY,
> it is based on the extcon logic (the type of cable connected) that PHY
> will be in one
> of the modes host/device and the respective controller will operate.
So at a point of time either the host controller or the device controller will
be active? and the PHY decides which of them should be active? Is that right?
Thanks
Kishon
--
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 2/2] ARM: dts: at91: sama5d3_xplained: not all ADC channels are available
From: Ludovic Desroches @ 2017-04-10 8:25 UTC (permalink / raw)
To: linux-arm-kernel, devicetree, linux-kernel
Cc: nicolas.ferre, alexandre.belloni, Eugen.Hristev,
Ludovic Desroches, # 3 . 16+
In-Reply-To: <20170410082517.19628-1-ludovic.desroches@microchip.com>
Remove ADC channels that are not available by default on the sama5d3_xplained
board (resistor not populated) in order to not create confusion.
Signed-off-by: Ludovic Desroches <ludovic.desroches@microchip.com>
Cc: <stable@vger.kernel.org> # 3.16+
---
arch/arm/boot/dts/at91-sama5d3_xplained.dts | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/arch/arm/boot/dts/at91-sama5d3_xplained.dts b/arch/arm/boot/dts/at91-sama5d3_xplained.dts
index 7a0fa1a..5a53fcf 100644
--- a/arch/arm/boot/dts/at91-sama5d3_xplained.dts
+++ b/arch/arm/boot/dts/at91-sama5d3_xplained.dts
@@ -163,9 +163,9 @@
adc0: adc@f8018000 {
atmel,adc-vref = <3300>;
+ atmel,adc-channels-used = <0xfe>;
pinctrl-0 = <
&pinctrl_adc0_adtrg
- &pinctrl_adc0_ad0
&pinctrl_adc0_ad1
&pinctrl_adc0_ad2
&pinctrl_adc0_ad3
@@ -173,8 +173,6 @@
&pinctrl_adc0_ad5
&pinctrl_adc0_ad6
&pinctrl_adc0_ad7
- &pinctrl_adc0_ad8
- &pinctrl_adc0_ad9
>;
status = "okay";
};
--
2.9.0
^ permalink raw reply related
* [PATCH 1/2] ARM: dts: at91: sama5d3_xplained: fix ADC vref
From: Ludovic Desroches @ 2017-04-10 8:25 UTC (permalink / raw)
To: linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA
Cc: nicolas.ferre-UWL1GkI3JZL3oGB3hsPCZA,
alexandre.belloni-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8,
Eugen.Hristev-UWL1GkI3JZL3oGB3hsPCZA, Ludovic Desroches,
# 3 . 16+
The voltage reference for the ADC is not 3V but 3.3V since it is connected to
VDDANA.
Signed-off-by: Ludovic Desroches <ludovic.desroches-UWL1GkI3JZL3oGB3hsPCZA@public.gmane.org>
Cc: <stable-u79uwXL29TY76Z2rM5mHXA@public.gmane.org> # 3.16+
---
arch/arm/boot/dts/at91-sama5d3_xplained.dts | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arm/boot/dts/at91-sama5d3_xplained.dts b/arch/arm/boot/dts/at91-sama5d3_xplained.dts
index c51fc65..7a0fa1a 100644
--- a/arch/arm/boot/dts/at91-sama5d3_xplained.dts
+++ b/arch/arm/boot/dts/at91-sama5d3_xplained.dts
@@ -162,6 +162,7 @@
};
adc0: adc@f8018000 {
+ atmel,adc-vref = <3300>;
pinctrl-0 = <
&pinctrl_adc0_adtrg
&pinctrl_adc0_ad0
--
2.9.0
--
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 related
* Re: [PATCH v4 6/9] ARM: dts: add support for I2SE Duckbill 2 boards
From: Shawn Guo @ 2017-04-10 8:24 UTC (permalink / raw)
To: Michael Heimpold
Cc: kernel-bIcnvbaLZ9MEGnE8C9+IrQ, robh+dt-DgEjT+Ai2ygdnm+yROfE0A,
mark.rutland-5wv7dgnIgG8,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
devicetree-u79uwXL29TY76Z2rM5mHXA, stefan.wahren-eS4NqCHxEME,
fabio.estevam-3arQi8VN3Tc, frowand.list-Re5JQEeQqe8AvxtiuMwx3w,
Michael Heimpold
In-Reply-To: <1486626169-20022-7-git-send-email-michael.heimpold-eS4NqCHxEME@public.gmane.org>
On Thu, Feb 09, 2017 at 08:42:46AM +0100, Michael Heimpold wrote:
> From: Michael Heimpold <mhei-Z/Lg1yOAjpkb1SvskN2V4Q@public.gmane.org>
>
> This machine is an USB pen drive sized development board,
> based on NXP's i.MX28 CPU. In contrast to the previous
> model "Duckbill", the "Duckbill 2" series has internal
> eMMC storage.
>
> Signed-off-by: Michael Heimpold <mhei-Z/Lg1yOAjpkb1SvskN2V4Q@public.gmane.org>
> Cc: Stefan Wahren <stefan.wahren-eS4NqCHxEME@public.gmane.org>
> ---
> arch/arm/boot/dts/Makefile | 1 +
> arch/arm/boot/dts/imx28-duckbill-2.dts | 183 +++++++++++++++++++++++++++++++++
> arch/arm/mach-mxs/mach-mxs.c | 3 +-
I'm preparing pull request for 4.12 merge window, and found this.
C file change shouldn't be mixed in DTS patch, so I dropped it. Please
submit C code change in a separate patch.
Shawn
> 3 files changed, 186 insertions(+), 1 deletion(-)
> create mode 100644 arch/arm/boot/dts/imx28-duckbill-2.dts
--
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: [v3, 0/7] Add SD UHS-I and eMMC HS200 support for eSDHC
From: Y.B. Lu @ 2017-04-10 8:20 UTC (permalink / raw)
To: linux-mmc-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org,
ulf.hansson-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org,
Adrian Hunter, Rob Herring, Mark Rutland, Catalin Marinas,
Will Deacon
Cc: Xiaobo Xie
In-Reply-To: <1490600982-5410-1-git-send-email-yangbo.lu@nxp.com>
Hi Andrian and Uffe,
Do you have any comments on MMC patches?
Could you help to merge the mmc patches if there is no changes requested?
Regarding to the dts patches, I have some more platforms to support.
So I'd like to drop them currently, and send them all to arm mailing list for reviewing.
Thanks a lot.
Best regards,
Yangbo Lu
> -----Original Message-----
> From: Y.B. Lu
> Sent: Thursday, April 06, 2017 4:02 PM
> To: Y.B. Lu; linux-mmc-u79uwXL29TY76Z2rM5mHXA@public.gmane.org; devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org;
> linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org; ulf.hansson-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org; Adrian
> Hunter; Rob Herring; Mark Rutland; Catalin Marinas; Will Deacon
> Cc: Xiaobo Xie
> Subject: RE: [v3, 0/7] Add SD UHS-I and eMMC HS200 support for eSDHC
>
> Hi all,
>
> Any comments? Thanks.
>
>
> Best regards,
> Yangbo Lu
>
> > -----Original Message-----
> > From: Yangbo Lu [mailto:yangbo.lu-3arQi8VN3Tc@public.gmane.org]
> > Sent: Monday, March 27, 2017 3:50 PM
> > To: linux-mmc-u79uwXL29TY76Z2rM5mHXA@public.gmane.org; devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org; linux-arm-
> > kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org; ulf.hansson-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org; Adrian Hunter; Rob
> > Herring; Mark Rutland; Catalin Marinas; Will Deacon
> > Cc: Xiaobo Xie; Y.B. Lu
> > Subject: [v3, 0/7] Add SD UHS-I and eMMC HS200 support for eSDHC
> >
> > It's complicated to support SD UHS-I and eMMC HS200 for eSDHC because
> > there're many differences between eSDHC and SD/eMMC spec. Several
> > differences as below must be considered:
> > 1. Peripheral clock must be used instead of platform clock.
> > - eSDHC could select peripheral clock or platform clock as its
> clock
> > source. According to RM, UHS-I/HS200 must use peripheral clock
> > since
> > it supports higher frequency than platform clock.
> > - Patch 1 and patch 6 is to support this.
> > 2. Signal voltage switching requires a control circuit out of eSDHC.
> > - eSDHC supports signal voltage switch from 3.3v to 1.8v by
> > eSDHC_PROCTL[VOLT_SEL] bit. This bit changes the value of output
> > signal SDHC_VS, and there must be a control circuit out of eSDHC
> > to change the signal voltage according to SDHC_VS output signal.
> > - Patch 2 is to support this.
> > 3. eSDHC uses tuning block for tuning procedure.
> > - Tuning clock control register must be configured before tuning.
> > - Patch 3 is to support this.
> > 4. Delay is needed between tuning cycles for HS200 tuning.
> > - Once a patch removed mdelay between tuning cycles.
> > But eSDHC needs it.
> > - Patch 4 and patch 5 is to support this.
> > 5. UHS-I/HS200 modes could be enabled in dts node.
> > - Patch 7 is to support this.
> >
> > Please review and merge these patches on mmc git tree if no changes
> > are required.
> >
> > Adrian Hunter (1):
> > mmc: sdhci: Control the delay between tuning commands
> >
> > Yangbo Lu (6):
> > mmc: sdhci-of-esdhc: add peripheral clock support
> > mmc: sdhci-of-esdhc: add support for signal voltage switch
> > mmc: sdhci-of-esdhc: add tuning support
> > mmc: sdhci-of-esdhc: add delay between tuning cycles
> > arm64: dts: ls1046a: add clocks property and compatible for eSDHC
> node
> > arm64: dts: ls1046ardb: add MMC HS200/UHS-1 modes support
> >
> > arch/arm64/boot/dts/freescale/fsl-ls1046a-rdb.dts | 8 ++
> > arch/arm64/boot/dts/freescale/fsl-ls1046a.dtsi | 3 +-
> > drivers/mmc/host/sdhci-esdhc.h | 7 +
> > drivers/mmc/host/sdhci-of-esdhc.c | 165
> > +++++++++++++++++++++-
> > drivers/mmc/host/sdhci.c | 11 +-
> > drivers/mmc/host/sdhci.h | 2 +
> > 6 files changed, 190 insertions(+), 6 deletions(-)
> >
> > --
> > 2.1.0.27.g96db324
--
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 5/9] arm, arm64: factorize common cpu capacity default code
From: Catalin Marinas @ 2017-04-10 8:18 UTC (permalink / raw)
To: Juri Lelli
Cc: linux-kernel, mark.rutland, devicetree, lorenzo.pieralisi,
vincent.guittot, linux-pm, peterz, broonie, will.deacon, gregkh,
dietmar.eggemann, Russell King, robh+dt, sudeep.holla, linux,
morten.rasmussen, linux-arm-kernel
In-Reply-To: <20170327131825.32134-6-juri.lelli@arm.com>
On Mon, Mar 27, 2017 at 02:18:21PM +0100, Juri Lelli wrote:
> arm and arm64 share lot of code relative to parsing CPU capacity
> information from DT, using that information for appropriate scaling and
> exposing a sysfs interface for chaging such values at runtime.
>
> Factorize such code in a common place (driver/base/arch_topology.c) in
> preparation for further additions.
>
> Suggested-by: Will Deacon <will.deacon@arm.com>
> Suggested-by: Mark Rutland <mark.rutland@arm.com>
> Suggested-by: Catalin Marinas <catalin.marinas@arm.com>
> Cc: Russell King <linux@armlinux.org.uk>
> Cc: Catalin Marinas <catalin.marinas@arm.com>
> Cc: Will Deacon <will.deacon@arm.com>
> Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
> Signed-off-by: Juri Lelli <juri.lelli@arm.com>
> ---
>
> Changes from v2:
> - make capacity_scale and raw_capacity static
> - added SPDX header
> - improved indent
> - misc. whitespaces/newlines fixes
>
> Changes from v1:
> - keep the original GPLv2 header
> ---
> arch/arm/Kconfig | 1 +
> arch/arm/kernel/topology.c | 213 ++-----------------------------------
> arch/arm64/Kconfig | 1 +
> arch/arm64/kernel/topology.c | 219 +--------------------------------------
> drivers/base/Kconfig | 8 ++
> drivers/base/Makefile | 1 +
> drivers/base/arch_topology.c | 242 +++++++++++++++++++++++++++++++++++++++++++
For arm64:
Acked-by: Catalin Marinas <catalin.marinas@arm.com>
^ permalink raw reply
* [PATCH net-next v2] bindings: net: stmmac: add missing note about LPI interrupt
From: Niklas Cassel @ 2017-04-10 7:43 UTC (permalink / raw)
To: Rob Herring, Mark Rutland, David S. Miller, Joao Pinto,
Alexandre TORGUE, Giuseppe CAVALLARO, Thierry Reding,
Eric Engestrom
Cc: Niklas Cassel, netdev-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA
From: Niklas Cassel <niklas.cassel-VrBV9hrLPhE@public.gmane.org>
The hardware has a LPI interrupt.
There is already code in the stmmac driver to parse and handle the
interrupt. However, this information was missing from the DT binding.
Signed-off-by: Niklas Cassel <niklas.cassel-VrBV9hrLPhE@public.gmane.org>
---
Documentation/devicetree/bindings/net/stmmac.txt | 8 ++++----
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/Documentation/devicetree/bindings/net/stmmac.txt b/Documentation/devicetree/bindings/net/stmmac.txt
index f652b0c384ce..84e4cbfd3b0f 100644
--- a/Documentation/devicetree/bindings/net/stmmac.txt
+++ b/Documentation/devicetree/bindings/net/stmmac.txt
@@ -8,8 +8,8 @@ Required properties:
that services interrupts for this device
- interrupts: Should contain the STMMAC interrupts
- interrupt-names: Should contain the interrupt names "macirq"
- "eth_wake_irq" if this interrupt is supported in the "interrupts"
- property
+ "eth_wake_irq" if this interrupt is supported in the "interrupts" property
+ "eth_lpi" if this interrupt is supported in the "interrupts" property
- phy-mode: See ethernet.txt file in the same directory.
- snps,reset-gpio gpio number for phy reset.
- snps,reset-active-low boolean flag to indicate if phy reset is active low.
@@ -152,8 +152,8 @@ Examples:
compatible = "st,spear600-gmac";
reg = <0xe0800000 0x8000>;
interrupt-parent = <&vic1>;
- interrupts = <24 23>;
- interrupt-names = "macirq", "eth_wake_irq";
+ interrupts = <24 23 22>;
+ interrupt-names = "macirq", "eth_wake_irq", "eth_lpi";
mac-address = [000000000000]; /* Filled in by U-Boot */
max-frame-size = <3800>;
phy-mode = "gmii";
--
2.11.0
--
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 related
* Re: [PATCH net-next] bindings: net: stmmac: add missing note about LPI interrupt
From: Niklas Cassel @ 2017-04-10 7:43 UTC (permalink / raw)
To: Sergei Shtylyov, Rob Herring, Mark Rutland, David S. Miller,
Joao Pinto, Alexandre TORGUE, Giuseppe CAVALLARO, Thierry Reding,
Eric Engestrom
Cc: netdev, devicetree, linux-kernel
In-Reply-To: <c1e78674-64d1-0e51-3ca4-48d8500a3528@cogentembedded.com>
On 04/07/2017 06:48 PM, Sergei Shtylyov wrote:
> Hello!
>
> On 04/07/2017 05:30 PM, Niklas Cassel wrote:
>
>> From: Niklas Cassel <niklas.cassel@axis.com>
>>
>> The hardware has a LPI interrupt.
>> There is already code in the stmmac driver to parse and handle the
>> interrupt. However, this information was missing from the DT binding.
>>
>> Signed-off-by: Niklas Cassel <niklas.cassel@axis.com>
>> ---
>> Documentation/devicetree/bindings/net/stmmac.txt | 8 ++++----
>> 1 file changed, 4 insertions(+), 4 deletions(-)
>>
>> diff --git a/Documentation/devicetree/bindings/net/stmmac.txt b/Documentation/devicetree/bindings/net/stmmac.txt
>> index f652b0c384ce..8977abc266ac 100644
>> --- a/Documentation/devicetree/bindings/net/stmmac.txt
>> +++ b/Documentation/devicetree/bindings/net/stmmac.txt
>> @@ -8,8 +8,8 @@ Required properties:
>> that services interrupts for this device
>> - interrupts: Should contain the STMMAC interrupts
>> - interrupt-names: Should contain the interrupt names "macirq"
>> - "eth_wake_irq" if this interrupt is supported in the "interrupts"
>> - property
>> + "eth_wake_irq" if this interrupt is supported in the "interrupts property
>
> Missed closing quote?
Thanks for pointing it out.
Will send a v2.
>
>> + "eth_lpi" if this interrupt is supported in the "interrupts" property
>> - phy-mode: See ethernet.txt file in the same directory.
>> - snps,reset-gpio gpio number for phy reset.
>> - snps,reset-active-low boolean flag to indicate if phy reset is active low.
> [...]
>
> MBR, Sergei
>
^ permalink raw reply
* Re: [PATCH v4 2/3] Broadcom USB DRD Phy driver for Northstar2
From: Raviteja Garimella @ 2017-04-10 7:27 UTC (permalink / raw)
To: Kishon Vijay Abraham I
Cc: Rob Herring, Mark Rutland, Ray Jui, Scott Branden, Jon Mason,
Catalin Marinas, Will Deacon, devicetree, linux-kernel,
BCM Kernel Feedback, linux-arm-kernel
In-Reply-To: <9fbef986-721c-05aa-28a1-4c49016fe2ca@ti.com>
Hi,
On Mon, Apr 10, 2017 at 10:55 AM, Kishon Vijay Abraham I <kishon@ti.com> wrote:
> Hi,
>
> On Wednesday 05 April 2017 07:40 PM, Raviteja Garimella wrote:
>> Hi Kishon,
>>
>> On Wed, Apr 5, 2017 at 7:04 PM, Kishon Vijay Abraham I <kishon@ti.com> wrote:
>>> Hi Ravi,
>>>
>>> On Wednesday 05 April 2017 06:30 PM, Raviteja Garimella wrote:
>>>> Hi Kishon,
>>>>
>>>> On Wed, Apr 5, 2017 at 4:30 PM, Kishon Vijay Abraham I <kishon@ti.com> wrote:
>>>>> Hi,
>>>>>
>>>>> On Tuesday 28 March 2017 05:57 PM, Raviteja Garimella wrote:
>>>>>> This is driver for USB DRD Phy used in Broadcom's Northstar2
>>>>>> SoC. The phy can be configured to be in Device mode or Host
>>>>>> mode based on the type of cable connected to the port. The
>>>>>> driver registers to extcon framework to get appropriate
>>>>>> connect events for Host/Device cables connect/disconnect
>>>>>> states based on VBUS and ID interrupts.
>>>>>
>>>>> $patch should be phy: phy-bcm-ns2-usbdrd: USB DRD Phy driver for Broadcoms
>>>>> Northstar2.
>>>>>
>>>>
>>>> Will do.
>>>>
>>>>> Sorry for not letting you know this earlier. But I feel the design of the
>>>>> driver should be changed. Extcon shouldn't be used here. The extcon
>>>>> notifications should be sent to the consumer driver and the consumer driver
>>>>> should be responsible for invoking the phy ops.
>>>>>
>>>>
>>>> The consumer drivers here would be a UDC driver (USB device
>>>> controller), EHCI and OHCI host controller drivers.
>>>> I was already suggested in UDC driver review to deal with extcon in Phy driver.
>>>>
>>>> This phy connects to 2 host controllers, and one device controller.
>>>> That's the design in Broadcom Northstar2
>>>> platform. The values of the VBUS and ID pins of this port are
>>>> determined based on the type of the cable (device cable
>>>> or host cable). And. phy has to be configured accordingly.
>>>>
>>>>> The phy ops being invoked during extcon events doesn't look right.
>>>>
>>>> Could you please elaborate on the concern, so that we can think of
>>>> mitigating those issues in this driver?
>>>> Since we are dealing with phy init/shutdown in this driver itself, are
>>>> you okay with moving the extcon handling code
>>>> out of phy ops ?
>>>
>>> yeah, For e.g., ns2_drd_phy_init is part of phy_ops and is being invoked from
>>> extcon events too. Can a phy which is initialized by a phy consumer (say your
>>> UDC invokes phy_init) can be shutdown by an extcon event?
>>>
>>> Maybe a clear explanation of when phy_ops here will be invoked and when it will
>>> set using extcon events might help.
>>>
>>
>> Say, we have a USB pendrive which is connected to the DRD port through
>> a host cable.
>> Now the PHY will be initialized to be in host mode.
>> When the pendrive is unplugged, and we now connect the NS2 device to
>> some linux PC,
>> now the PHY has to be shutdown, and re-initialized to be in Device mode.
>>
>> On unplug event, it is set neither to Host nor Device mode (basically
>> shutdown). Next time which ever cable is connected, the PHY is
>> initialized to the respective
>> mode.
>>
>> Please let me know if it's fine to do these initializations outside
>> phy ops, because those will
>> be irrelevant for phy consumers (the controllers) as it's anyways
>> dealt in the phy driver through
>> extcon.
>
> How does the consumer get to know whether they have to operate in host mode or
> device mode?
>
In NS2, we have host controllers and device controller (not OTG/other
that can switch
between host and device mode). It's only phy that can be in host/device mode.
Since both Host Controllers and Device Controller are connected to the same PHY,
it is based on the extcon logic (the type of cable connected) that PHY
will be in one
of the modes host/device and the respective controller will operate.
> Thanks
> Kishon
^ permalink raw reply
* Re: [PATCH] ARM: dts: stm32f7: add STM32f769I & stm32f746 discovery board support
From: Alexandre Torgue @ 2017-04-10 7:23 UTC (permalink / raw)
To: Vikas Manocha, patrice.chotard-qxv4g6HH51o
Cc: open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
moderated list:ARM PORT, open list, Mark Rutland, Maxime Coquelin,
Rob Herring, Russell King
In-Reply-To: <1491613929-11485-1-git-send-email-vikas.manocha-qxv4g6HH51o@public.gmane.org>
Hi
On 04/08/2017 03:12 AM, Vikas Manocha wrote:
> Stm32f769I & stm32f746 are MCUs of stm32f7 family. Here are the major
> spces of the two boards:
>
> stm32f769I discovery board:
> - Cortex-M7 core @216MHz
> - 2MB mcu internal flash
> - 512KB internal sram
> - 16MB sdram memory
> - 64MB qspi flash memory
> - 4 inch wvga LCD-TFT Display
>
> stm32f746 discovery board:
> - Cortex-M7 core @216MHz
> - 1MB mcu internal flash
> - 320KB internal sram
> - 8MB sdram memory
> - 16MB qspi flash memory
> - 4.3 inch 480x272 LCD-TFT display
>
> Signed-off-by: Vikas Manocha <vikas.manocha-qxv4g6HH51o@public.gmane.org>
> ---
> arch/arm/boot/dts/Makefile | 2 +
> arch/arm/boot/dts/stm32f746-disco.dts | 101 ++++++++++++++++++++++++++++++++++
> arch/arm/boot/dts/stm32f746.dtsi | 2 +-
> arch/arm/boot/dts/stm32f769-disco.dts | 101 ++++++++++++++++++++++++++++++++++
> 4 files changed, 205 insertions(+), 1 deletion(-)
> create mode 100644 arch/arm/boot/dts/stm32f746-disco.dts
> create mode 100644 arch/arm/boot/dts/stm32f769-disco.dts
>
> diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
> index 0118084..a119f74 100644
> --- a/arch/arm/boot/dts/Makefile
> +++ b/arch/arm/boot/dts/Makefile
> @@ -763,6 +763,8 @@ dtb-$(CONFIG_ARCH_STI) += \
> dtb-$(CONFIG_ARCH_STM32)+= \
> stm32f429-disco.dtb \
> stm32f469-disco.dtb \
> + stm32f746-disco.dtb \
> + stm32f769-disco.dtb \
> stm32429i-eval.dtb \
> stm32746g-eval.dtb
> dtb-$(CONFIG_MACH_SUN4I) += \
> diff --git a/arch/arm/boot/dts/stm32f746-disco.dts b/arch/arm/boot/dts/stm32f746-disco.dts
> new file mode 100644
> index 0000000..c0e313f
> --- /dev/null
> +++ b/arch/arm/boot/dts/stm32f746-disco.dts
> @@ -0,0 +1,101 @@
> +/*
> + * Copyright 2017 - Vikas MANOCHA <vikas.manocha-qxv4g6HH51o@public.gmane.org>
> + *
> + * This file is dual-licensed: you can use it either under the terms
> + * of the GPL or the X11 license, at your option. Note that this dual
> + * licensing only applies to this file, and not this project as a
> + * whole.
> + *
> + * a) This file is free software; you can redistribute it and/or
> + * modify it under the terms of the GNU General Public License as
> + * published by the Free Software Foundation; either version 2 of the
> + * License, or (at your option) any later version.
> + *
> + * This file is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
> + * GNU General Public License for more details.
> + *
> + * Or, alternatively,
> + *
> + * b) Permission is hereby granted, free of charge, to any person
> + * obtaining a copy of this software and associated documentation
> + * files (the "Software"), to deal in the Software without
> + * restriction, including without limitation the rights to use,
> + * copy, modify, merge, publish, distribute, sublicense, and/or
> + * sell copies of the Software, and to permit persons to whom the
> + * Software is furnished to do so, subject to the following
> + * conditions:
> + *
> + * The above copyright notice and this permission notice shall be
> + * included in all copies or substantial portions of the Software.
> + *
> + * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
> + * EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES
> + * OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
> + * NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT
> + * HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY,
> + * WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
> + * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
> + * OTHER DEALINGS IN THE SOFTWARE.
> + */
> +
> +/dts-v1/;
> +#include "stm32f746.dtsi"
> +#include <dt-bindings/input/input.h>
> +
> +/ {
> + model = "STMicroelectronics STM32F746-DISCO board";
> + compatible = "st,stm32f746-disco", "st,stm32f746";
> +
> + chosen {
> + bootargs = "root=/dev/ram";
> + stdout-path = "serial0:115200n8";
> + };
> +
> + memory {
> + reg = <0xC0000000 0x800000>;
> + };
> +
> + aliases {
> + serial0 = &usart1;
> + };
> +
> +};
> +
> +&clk_hse {
> + clock-frequency = <25000000>;
> +};
> +
> +&pinctrl {
Pin muxing is not defined in board file. Please move it into SOC dtsi file.
> + usart1_pins: usart1@0 {
> + pins1 {
> + pinmux = <STM32F746_PA9_FUNC_USART1_TX>;
> + bias-disable;
> + drive-push-pull;
> + slew-rate = <2>;
> + };
> + pins2 {
> + pinmux = <STM32F746_PB7_FUNC_USART1_RX>;
> + bias-disable;
> + };
> + };
> +
> + qspi_pins: qspi@0 {
> + pins {
> + pinmux = <STM32F746_PB2_FUNC_QUADSPI_CLK>,
> + <STM32F746_PB6_FUNC_QUADSPI_BK1_NCS>,
> + <STM32F746_PD11_FUNC_QUADSPI_BK1_IO0>,
> + <STM32F746_PD12_FUNC_QUADSPI_BK1_IO1>,
> + <STM32F746_PD13_FUNC_QUADSPI_BK1_IO3>,
> + <STM32F746_PE2_FUNC_QUADSPI_BK1_IO2>;
> + slew-rate = <2>;
> + };
> + };
> +};
> +
> +&usart1 {
> + pinctrl-0 = <&usart1_pins>;
> + pinctrl-names = "default";
> + status = "okay";
> +};
> diff --git a/arch/arm/boot/dts/stm32f746.dtsi b/arch/arm/boot/dts/stm32f746.dtsi
> index f321ffe..826700f 100644
> --- a/arch/arm/boot/dts/stm32f746.dtsi
> +++ b/arch/arm/boot/dts/stm32f746.dtsi
> @@ -178,7 +178,7 @@
> interrupts = <1>, <2>, <3>, <6>, <7>, <8>, <9>, <10>, <23>, <40>, <41>, <42>, <62>, <76>;
> };
>
> - pin-controller {
> + pinctrl: pin-controller {
> #address-cells = <1>;
> #size-cells = <1>;
> compatible = "st,stm32f746-pinctrl";
> diff --git a/arch/arm/boot/dts/stm32f769-disco.dts b/arch/arm/boot/dts/stm32f769-disco.dts
> new file mode 100644
> index 0000000..5f8558e
> --- /dev/null
> +++ b/arch/arm/boot/dts/stm32f769-disco.dts
> @@ -0,0 +1,101 @@
> +/*
> + * Copyright 2017 - Vikas MANOCHA <vikas.manocha-qxv4g6HH51o@public.gmane.org>
> + *
> + * This file is dual-licensed: you can use it either under the terms
> + * of the GPL or the X11 license, at your option. Note that this dual
> + * licensing only applies to this file, and not this project as a
> + * whole.
> + *
> + * a) This file is free software; you can redistribute it and/or
> + * modify it under the terms of the GNU General Public License as
> + * published by the Free Software Foundation; either version 2 of the
> + * License, or (at your option) any later version.
> + *
> + * This file is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
> + * GNU General Public License for more details.
> + *
> + * Or, alternatively,
> + *
> + * b) Permission is hereby granted, free of charge, to any person
> + * obtaining a copy of this software and associated documentation
> + * files (the "Software"), to deal in the Software without
> + * restriction, including without limitation the rights to use,
> + * copy, modify, merge, publish, distribute, sublicense, and/or
> + * sell copies of the Software, and to permit persons to whom the
> + * Software is furnished to do so, subject to the following
> + * conditions:
> + *
> + * The above copyright notice and this permission notice shall be
> + * included in all copies or substantial portions of the Software.
> + *
> + * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
> + * EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES
> + * OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
> + * NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT
> + * HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY,
> + * WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
> + * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
> + * OTHER DEALINGS IN THE SOFTWARE.
> + */
> +
> +/dts-v1/;
> +#include "stm32f746.dtsi"
> +#include <dt-bindings/input/input.h>
> +
> +/ {
> + model = "STMicroelectronics STM32F769-DISCO board";
> + compatible = "st,stm32f769-disco", "st,stm32f7";
> +
> + chosen {
> + bootargs = "root=/dev/ram";
> + stdout-path = "serial0:115200n8";
> + };
> +
> + memory {
> + reg = <0xC0000000 0x1000000>;
> + };
> +
> + aliases {
> + serial0 = &usart1;
> + };
> +
> +};
> +
> +&clk_hse {
> + clock-frequency = <25000000>;
> +};
> +
> +&pinctrl {
same.
> + usart1_pins: usart1@0 {
> + pins1 {
> + pinmux = <STM32F746_PA9_FUNC_USART1_TX>;
> + bias-disable;
> + drive-push-pull;
> + slew-rate = <2>;
> + };
> + pins2 {
> + pinmux = <STM32F746_PA10_FUNC_USART1_RX>;
> + bias-disable;
> + };
> + };
> +
> + qspi_pins: qspi@0 {
> + pins {
> + pinmux = <STM32F746_PB2_FUNC_QUADSPI_CLK>,
> + <STM32F746_PB6_FUNC_QUADSPI_BK1_NCS>,
> + <STM32F746_PC9_FUNC_QUADSPI_BK1_IO0>,
> + <STM32F746_PC10_FUNC_QUADSPI_BK1_IO1>,
> + <STM32F746_PD13_FUNC_QUADSPI_BK1_IO3>,
> + <STM32F746_PE2_FUNC_QUADSPI_BK1_IO2>;
> + slew-rate = <2>;
> + };
> + };
> +};
> +
> +&usart1 {
> + pinctrl-0 = <&usart1_pins>;
> + pinctrl-names = "default";
> + status = "okay";
> +};
>
--
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