Devicetree
 help / color / mirror / Atom feed
* [PATCH 9/9] ARM: dts: dra7: Add an empty chosen node to top level DTSI
From: Javier Martinez Canillas @ 2016-12-19 14:44 UTC (permalink / raw)
  To: linux-kernel
  Cc: Mark Rutland, devicetree, Tony Lindgren, Russell King,
	Javier Martinez Canillas, Rob Herring, Benoît Cousson,
	Pali Rohar, linux-omap, linux-arm-kernel
In-Reply-To: <1482158681-4530-1-git-send-email-javier@osg.samsung.com>

Commit 55871eb6e2cc ("ARM: dts: dra7: Remove skeleton.dtsi usage")
removed the skeleton.dtsi usage since we want to get rid of it.

But this can cause issues when booting a kernel with a boot-loader
that doesn't create a chosen node if this isn't present in the DTB
since the decompressor relies on a pre-existing chosen node to be
available to insert the command line and merge other ATAGS info.

Fixes: 55871eb6e2cc ("ARM: dts: dra7: Remove skeleton.dtsi usage")
Reported-by: Pali Rohar <pali.rohar@gmail.com>
Signed-off-by: Javier Martinez Canillas <javier@osg.samsung.com>

---

 arch/arm/boot/dts/dra7.dtsi | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/arm/boot/dts/dra7.dtsi b/arch/arm/boot/dts/dra7.dtsi
index addb7530cfbe..1faf24acd521 100644
--- a/arch/arm/boot/dts/dra7.dtsi
+++ b/arch/arm/boot/dts/dra7.dtsi
@@ -18,6 +18,7 @@
 
 	compatible = "ti,dra7xx";
 	interrupt-parent = <&crossbar_mpu>;
+	chosen { };
 
 	aliases {
 		i2c0 = &i2c1;
-- 
2.7.4

^ permalink raw reply related
* [PATCH 8/9] ARM: dts: dm816x: Add an empty chosen node to top level DTSI
From: Javier Martinez Canillas @ 2016-12-19 14:44 UTC (permalink / raw)
  To: linux-kernel
  Cc: Mark Rutland, devicetree, Russell King, Javier Martinez Canillas,
	Rob Herring, Pali Rohar, linux-arm-kernel
In-Reply-To: <1482158681-4530-1-git-send-email-javier@osg.samsung.com>

Commit 06bfb9c19957 ("ARM: dts: dm816x: Remove skeleton.dtsi usage")
removed the skeleton.dtsi usage since we want to get rid of it.

But this can cause issues when booting a kernel with a boot-loader
that doesn't create a chosen node if this isn't present in the DTB
since the decompressor relies on a pre-existing chosen node to be
available to insert the command line and merge other ATAGS info.

Fixes: 06bfb9c19957 ("ARM: dts: dm816x: Remove skeleton.dtsi usage")
Reported-by: Pali Rohar <pali.rohar@gmail.com>
Signed-off-by: Javier Martinez Canillas <javier@osg.samsung.com>
---

 arch/arm/boot/dts/dm816x.dtsi | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/arm/boot/dts/dm816x.dtsi b/arch/arm/boot/dts/dm816x.dtsi
index 61dd2f6b02bc..6db652ae9bd5 100644
--- a/arch/arm/boot/dts/dm816x.dtsi
+++ b/arch/arm/boot/dts/dm816x.dtsi
@@ -12,6 +12,7 @@
 	interrupt-parent = <&intc>;
 	#address-cells = <1>;
 	#size-cells = <1>;
+	chosen { };
 
 	aliases {
 		i2c0 = &i2c1;
-- 
2.7.4

^ permalink raw reply related
* [PATCH 7/9] ARM: dts: dm814x: Add an empty chosen node to top level DTSI
From: Javier Martinez Canillas @ 2016-12-19 14:44 UTC (permalink / raw)
  To: linux-kernel-u79uwXL29TY76Z2rM5mHXA
  Cc: Pali Rohar, Javier Martinez Canillas,
	devicetree-u79uwXL29TY76Z2rM5mHXA, Rob Herring, Mark Rutland,
	Russell King, linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r
In-Reply-To: <1482158681-4530-1-git-send-email-javier-JPH+aEBZ4P+UEJcrhfAQsw@public.gmane.org>

Commit 76155b378c59 ("ARM: dts: dm814x: Remove skeleton.dtsi usage")
removed the skeleton.dtsi usage since we want to get rid of it.

But this can cause issues when booting a kernel with a boot-loader
that doesn't create a chosen node if this isn't present in the DTB
since the decompressor relies on a pre-existing chosen node to be
available to insert the command line and merge other ATAGS info.

Fixes: 76155b378c59 ("ARM: dts: dm814x: Remove skeleton.dtsi usage")
Reported-by: Pali Rohar <pali.rohar-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Signed-off-by: Javier Martinez Canillas <javier-JPH+aEBZ4P+UEJcrhfAQsw@public.gmane.org>
---

 arch/arm/boot/dts/dm814x.dtsi | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/arm/boot/dts/dm814x.dtsi b/arch/arm/boot/dts/dm814x.dtsi
index 1facc5f12cef..81b8cecb5820 100644
--- a/arch/arm/boot/dts/dm814x.dtsi
+++ b/arch/arm/boot/dts/dm814x.dtsi
@@ -12,6 +12,7 @@
 	interrupt-parent = <&intc>;
 	#address-cells = <1>;
 	#size-cells = <1>;
+	chosen { };
 
 	aliases {
 		i2c0 = &i2c1;
-- 
2.7.4

--
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
* [PATCH 6/9] ARM: dts: am4372: Add an empty chosen node to top level DTSI
From: Javier Martinez Canillas @ 2016-12-19 14:44 UTC (permalink / raw)
  To: linux-kernel
  Cc: Mark Rutland, devicetree, Tony Lindgren, Russell King,
	Javier Martinez Canillas, Rob Herring, Benoît Cousson,
	Pali Rohar, linux-omap, linux-arm-kernel
In-Reply-To: <1482158681-4530-1-git-send-email-javier@osg.samsung.com>

Commit 75813028bbd7 ("ARM: dts: am4372: Remove skeleton.dtsi usage")
removed the skeleton.dtsi usage since we want to get rid of it.

But this can cause issues when booting a kernel with a boot-loader
that doesn't create a chosen node if this isn't present in the DTB
since the decompressor relies on a pre-existing chosen node to be
available to insert the command line and merge other ATAGS info.

Fixes: 75813028bbd7 ("ARM: dts: am4372: Remove skeleton.dtsi usage")
Reported-by: Pali Rohar <pali.rohar@gmail.com>
Signed-off-by: Javier Martinez Canillas <javier@osg.samsung.com>
---

 arch/arm/boot/dts/am4372.dtsi | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/arm/boot/dts/am4372.dtsi b/arch/arm/boot/dts/am4372.dtsi
index ac55f93fc91e..2df9e6050c2f 100644
--- a/arch/arm/boot/dts/am4372.dtsi
+++ b/arch/arm/boot/dts/am4372.dtsi
@@ -16,6 +16,7 @@
 	interrupt-parent = <&wakeupgen>;
 	#address-cells = <1>;
 	#size-cells = <1>;
+	chosen { };
 
 	memory@0 {
 		device_type = "memory";
-- 
2.7.4

^ permalink raw reply related
* [PATCH 5/9] ARM: dts: am33xx: Add an empty chosen node to top level DTSI
From: Javier Martinez Canillas @ 2016-12-19 14:44 UTC (permalink / raw)
  To: linux-kernel
  Cc: Mark Rutland, devicetree, Tony Lindgren, Russell King,
	Javier Martinez Canillas, Rob Herring, Benoît Cousson,
	Pali Rohar, linux-omap, linux-arm-kernel
In-Reply-To: <1482158681-4530-1-git-send-email-javier@osg.samsung.com>

Commit f8bf01611c99 ("ARM: dts: am33xx: Remove skeleton.dtsi usage")
removed the skeleton.dtsi usage since we want to get rid of it.

But this can cause issues when booting a kernel with a boot-loader
that doesn't create a chosen node if this isn't present in the DTB
since the decompressor relies on a pre-existing chosen node to be
available to insert the command line and merge other ATAGS info.

Fixes: f8bf01611c99 ("ARM: dts: am33xx: Remove skeleton.dtsi usage")
Reported-by: Pali Rohar <pali.rohar@gmail.com>
Signed-off-by: Javier Martinez Canillas <javier@osg.samsung.com>
---

 arch/arm/boot/dts/am33xx.dtsi | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/arm/boot/dts/am33xx.dtsi b/arch/arm/boot/dts/am33xx.dtsi
index 64c8aa9057a3..18d72a245e88 100644
--- a/arch/arm/boot/dts/am33xx.dtsi
+++ b/arch/arm/boot/dts/am33xx.dtsi
@@ -16,6 +16,7 @@
 	interrupt-parent = <&intc>;
 	#address-cells = <1>;
 	#size-cells = <1>;
+	chosen { };
 
 	aliases {
 		i2c0 = &i2c0;
-- 
2.7.4

^ permalink raw reply related
* [PATCH 4/9] ARM: dts: omap5: Add an empty chosen node to top level DTSI
From: Javier Martinez Canillas @ 2016-12-19 14:44 UTC (permalink / raw)
  To: linux-kernel
  Cc: Mark Rutland, devicetree, Tony Lindgren, Russell King,
	Javier Martinez Canillas, Rob Herring, Benoît Cousson,
	Pali Rohar, linux-omap, linux-arm-kernel
In-Reply-To: <1482158681-4530-1-git-send-email-javier@osg.samsung.com>

Commit 76a8548ea987 ("ARM: dts: omap5: Remove skeleton.dtsi usage")
removed the skeleton.dtsi usage since we want to get rid of it.

But this can cause issues when booting a kernel with a boot-loader
that doesn't create a chosen node if this isn't present in the DTB
since the decompressor relies on a pre-existing chosen node to be
available to insert the command line and merge other ATAGS info.

Fixes: 76a8548ea987 ("ARM: dts: omap5: Remove skeleton.dtsi usage")
Reported-by: Pali Rohar <pali.rohar@gmail.com>
Signed-off-by: Javier Martinez Canillas <javier@osg.samsung.com>
---

 arch/arm/boot/dts/omap5.dtsi | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/arm/boot/dts/omap5.dtsi b/arch/arm/boot/dts/omap5.dtsi
index 968c67a49dbd..7cd92babc41a 100644
--- a/arch/arm/boot/dts/omap5.dtsi
+++ b/arch/arm/boot/dts/omap5.dtsi
@@ -17,6 +17,7 @@
 
 	compatible = "ti,omap5";
 	interrupt-parent = <&wakeupgen>;
+	chosen { };
 
 	aliases {
 		i2c0 = &i2c1;
-- 
2.7.4

^ permalink raw reply related
* [PATCH 3/9] ARM: dts: omap4: Add an empty chosen node to top level DTSI
From: Javier Martinez Canillas @ 2016-12-19 14:44 UTC (permalink / raw)
  To: linux-kernel
  Cc: Mark Rutland, devicetree, Tony Lindgren, Russell King,
	Javier Martinez Canillas, Rob Herring, Benoît Cousson,
	Pali Rohar, linux-omap, linux-arm-kernel
In-Reply-To: <1482158681-4530-1-git-send-email-javier@osg.samsung.com>

Commit da6269e7e3dd ("ARM: dts: omap4: Remove skeleton.dtsi usage")
removed the skeleton.dtsi usage since we want to get rid of it.

But this can cause issues when booting a kernel with a boot-loader
that doesn't create a chosen node if this isn't present in the DTB
since the decompressor relies on a pre-existing chosen node to be
available to insert the command line and merge other ATAGS info.

Fixes: da6269e7e3dd ("ARM: dts: omap4: Remove skeleton.dtsi usage")
Reported-by: Pali Rohar <pali.rohar@gmail.com>
Signed-off-by: Javier Martinez Canillas <javier@osg.samsung.com>
---

 arch/arm/boot/dts/omap4.dtsi | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/arm/boot/dts/omap4.dtsi b/arch/arm/boot/dts/omap4.dtsi
index 8087456b5fbe..578c53f08309 100644
--- a/arch/arm/boot/dts/omap4.dtsi
+++ b/arch/arm/boot/dts/omap4.dtsi
@@ -15,6 +15,7 @@
 	interrupt-parent = <&wakeupgen>;
 	#address-cells = <1>;
 	#size-cells = <1>;
+	chosen { };
 
 	aliases {
 		i2c0 = &i2c1;
-- 
2.7.4

^ permalink raw reply related
* [PATCH 2/9] ARM: dts: omap3: Add an empty chosen node to top level DTSI
From: Javier Martinez Canillas @ 2016-12-19 14:44 UTC (permalink / raw)
  To: linux-kernel
  Cc: Mark Rutland, devicetree, Tony Lindgren, Russell King,
	Javier Martinez Canillas, Rob Herring, Benoît Cousson,
	Pali Rohar, linux-omap, linux-arm-kernel
In-Reply-To: <1482158681-4530-1-git-send-email-javier@osg.samsung.com>

Commit 008a2ebcd677 ("ARM: dts: omap3: Remove skeleton.dtsi usage")
removed the skeleton.dtsi usage since we want to get rid of it.

But this can cause issues when booting a kernel with a boot-loader
that doesn't create a chosen node if this isn't present in the DTB
since the decompressor relies on a pre-existing chosen node to be
available to insert the command line and merge other ATAGS info.

Fixes: 008a2ebcd677 ("ARM: dts: omap3: Remove skeleton.dtsi usage")
Reported-by: Pali Rohar <pali.rohar@gmail.com>
Signed-off-by: Javier Martinez Canillas <javier@osg.samsung.com>
---

 arch/arm/boot/dts/omap3.dtsi | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/arm/boot/dts/omap3.dtsi b/arch/arm/boot/dts/omap3.dtsi
index ecf5eb584c75..a3ff4933dbc1 100644
--- a/arch/arm/boot/dts/omap3.dtsi
+++ b/arch/arm/boot/dts/omap3.dtsi
@@ -17,6 +17,7 @@
 	interrupt-parent = <&intc>;
 	#address-cells = <1>;
 	#size-cells = <1>;
+	chosen { };
 
 	aliases {
 		i2c0 = &i2c1;
-- 
2.7.4

^ permalink raw reply related
* [PATCH 1/9] ARM: dts: omap2: Add an empty chosen node to top level DTSI
From: Javier Martinez Canillas @ 2016-12-19 14:44 UTC (permalink / raw)
  To: linux-kernel
  Cc: Mark Rutland, devicetree, Tony Lindgren, Russell King,
	Javier Martinez Canillas, Rob Herring, Benoît Cousson,
	Pali Rohar, linux-omap, linux-arm-kernel
In-Reply-To: <1482158681-4530-1-git-send-email-javier@osg.samsung.com>

Commit d1f3156fc8c7 ("ARM: dts: omap2: Remove skeleton.dtsi usage")
removed the skeleton.dtsi usage since we want to get rid of it.

But this can cause issues when booting a kernel with a boot-loader
that doesn't create a chosen node if this isn't present in the DTB
since the decompressor relies on a pre-existing chosen node to be
available to insert the command line and merge other ATAGS info.

Fixes: d1f3156fc8c7 ("ARM: dts: omap2: Remove skeleton.dtsi usage")
Reported-by: Pali Rohar <pali.rohar@gmail.com>
Signed-off-by: Javier Martinez Canillas <javier@osg.samsung.com>
---

 arch/arm/boot/dts/omap2.dtsi | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/arm/boot/dts/omap2.dtsi b/arch/arm/boot/dts/omap2.dtsi
index 4f793a025a72..f1d6de8b3c19 100644
--- a/arch/arm/boot/dts/omap2.dtsi
+++ b/arch/arm/boot/dts/omap2.dtsi
@@ -17,6 +17,7 @@
 	interrupt-parent = <&intc>;
 	#address-cells = <1>;
 	#size-cells = <1>;
+	chosen { };
 
 	aliases {
 		serial0 = &uart1;
-- 
2.7.4

^ permalink raw reply related
* [PATCH 0/9] ARM: omap: Add empty chosen node in SoCs top level DTSI
From: Javier Martinez Canillas @ 2016-12-19 14:44 UTC (permalink / raw)
  To: linux-kernel
  Cc: Mark Rutland, devicetree, Tony Lindgren, Russell King,
	Javier Martinez Canillas, Rob Herring, Benoît Cousson,
	Pali Rohar, linux-omap, linux-arm-kernel

Hello Tony,

As discussed in [0], there's a regression when booting a kernel with a DTB
that doesn't have a pre-existing chosen node. This is usually not an issue
for most boards since u-boot creates an empty chosen node if isn't present
in the DTB.

But it can be an issue for others bootloaders as Pali pointed out with the
N9/900/950 phones and the Nokia Loader (NoLo).

This patch series add chosen nodes in the top level DTSI for all OMAP SoCs.

[0]: http://www.mail-archive.com/linux-kernel@vger.kernel.org/msg1294379.html

Best regards,
Javier


Javier Martinez Canillas (9):
  ARM: dts: omap2: Add an empty chosen node to top level DTSI
  ARM: dts: omap3: Add an empty chosen node to top level DTSI
  ARM: dts: omap4: Add an empty chosen node to top level DTSI
  ARM: dts: omap5: Add an empty chosen node to top level DTSI
  ARM: dts: am33xx: Add an empty chosen node to top level DTSI
  ARM: dts: am4372: Add an empty chosen node to top level DTSI
  ARM: dts: dm814x: Add an empty chosen node to top level DTSI
  ARM: dts: dm816x: Add an empty chosen node to top level DTSI
  ARM: dts: dra7: Add an empty chosen node to top level DTSI

 arch/arm/boot/dts/am33xx.dtsi | 1 +
 arch/arm/boot/dts/am4372.dtsi | 1 +
 arch/arm/boot/dts/dm814x.dtsi | 1 +
 arch/arm/boot/dts/dm816x.dtsi | 1 +
 arch/arm/boot/dts/dra7.dtsi   | 1 +
 arch/arm/boot/dts/omap2.dtsi  | 1 +
 arch/arm/boot/dts/omap3.dtsi  | 1 +
 arch/arm/boot/dts/omap4.dtsi  | 1 +
 arch/arm/boot/dts/omap5.dtsi  | 1 +
 9 files changed, 9 insertions(+)

-- 
2.7.4

^ permalink raw reply
* Re: [PATCH 4/4] arm64: dts: marvell: Add ethernet switch definition for the EXPRESSObin
From: Andrew Lunn @ 2016-12-19 14:44 UTC (permalink / raw)
  To: Romain Perier
  Cc: Mark Rutland, devicetree, Florian Fainelli, Jason Cooper,
	Pawel Moll, Vivien Didelot, netdev, Ian Campbell, Nadav Haklai,
	Rob Herring, Kumar Gala, Gregory Clement, Thomas Petazzoni,
	linux-arm-kernel, Sebastian Hesselbarth
In-Reply-To: <20161219141610.30934-5-romain.perier@free-electrons.com>

> +		mdio {
> +			#address-cells = <1>;
> +			#size-cells = <0>;
> +			reg = <1>;
> +
> +			switch0phy0: switch0phy0@0 {
> +				reg = <0x11>;

Since the reg is 0x11, this should be called switch0phy0@11.  Please
follow the same scheme for the other phys.

       Andrew

^ permalink raw reply
* Re: [PATCH 1/4] net: dsa: mv88e6xxx: Allow mv88e6xxx_smi_init() to be used at address 0x1
From: Andrew Lunn @ 2016-12-19 14:38 UTC (permalink / raw)
  To: Romain Perier, Volodymyr Bendiuga
  Cc: Vivien Didelot, Florian Fainelli, Jason Cooper,
	Sebastian Hesselbarth, Gregory Clement, netdev, devicetree,
	Rob Herring, Ian Campbell, Pawel Moll, Mark Rutland, Kumar Gala,
	linux-arm-kernel, Thomas Petazzoni, Nadav Haklai
In-Reply-To: <20161219141610.30934-2-romain.perier@free-electrons.com>

On Mon, Dec 19, 2016 at 03:16:06PM +0100, Romain Perier wrote:
> Currently, the function mv88e6xxx_smi_init() returns -EINVAL if the bit
> zero of sw_addr is 0x1. However, on some platforms, ethernet switches
> are configured in Multi chip addressing mode and available at MDIO
> address 0x1.

Hi Romain

What branch is this against? net-next?

Please see:

https://www.spinics.net/lists/netdev/msg409156.html

It would be nicer to use Volodymyr, since it has been reviewed. 

Volodymyr, what happened to your version 2? Did David accept it?

	   Andrew

^ permalink raw reply
* Re: [PATCH v2] ARM: dts: sun8i: add opp-v2 table for A33
From: Quentin Schulz @ 2016-12-19 14:30 UTC (permalink / raw)
  To: Icenowy Zheng, Chen-Yu Tsai, Maxime Ripard
  Cc: devicetree, linux-kernel, Hans de Goede, linux-sunxi, linux-clk,
	linux-arm-kernel
In-Reply-To: <11975791482156406@web2g.yandex.ru>

On 19/12/2016 15:06, Icenowy Zheng wrote:
> 
> 
> 19.12.2016, 16:54, "Chen-Yu Tsai" <wens@csie.org>:
>> On Mon, Dec 19, 2016 at 4:46 PM, Maxime Ripard
>> <maxime.ripard@free-electrons.com> wrote:
>>>  On Fri, Dec 16, 2016 at 02:27:54AM +0800, Icenowy Zheng wrote:
>>>>  An operating point table is needed for the cpu frequency adjusting to
>>>>  work.
>>>>
>>>>  The operating point table is converted from the common value in
>>>>  extracted script.fex from many A33 board/tablets.
>>>>
>>>>  Signed-off-by: Icenowy Zheng <icenowy@aosc.xyz>
>>>>  ---
>>>>  Changes since v1:
>>>>  - Fix format problem (blank lines).
>>>>  - Removed the 1.344GHz operating point, as it's overvoltage and overclocked.
>>>>
>>>>  This patch depends on the following patchset:
>>>>
>>>>  http://lists.infradead.org/pipermail/linux-arm-kernel/2016-December/473962.html
>>>>
>>>>  It's the v2 of the [PATCH 4/6] in this patchset.
>>>>
>>>>  I think this operating point table may also apply to A23, as there's no
>>>>  difference except the points over 1.2GHz between A23 and A33's stock dvfs table.
>>>>
>>>>  But as A23 CCU may not have the necessary fixes, I won't add the table to A23
>>>>  now.
>>>>
>>>>  Chen-Yu, could you test the CCU fixes I described in the patchset above on A23,
>>>>  then test this operating points table?
>>>>
>>>>  If it's necessary, you can send out the CCU fixes and add one more patch that
>>>>  moves this opp-v2 table to sun8i-a23-a33.dtsi .
>>>>
>>>>   arch/arm/boot/dts/sun8i-a33.dtsi | 35 +++++++++++++++++++++++++++++++++++
>>>>   1 file changed, 35 insertions(+)
>>>>
>>>>  diff --git a/arch/arm/boot/dts/sun8i-a33.dtsi b/arch/arm/boot/dts/sun8i-a33.dtsi
>>>>  index 504996cbee29..0f5b2af72981 100644
>>>>  --- a/arch/arm/boot/dts/sun8i-a33.dtsi
>>>>  +++ b/arch/arm/boot/dts/sun8i-a33.dtsi
>>>>  @@ -46,7 +46,42 @@
>>>>   #include <dt-bindings/dma/sun4i-a10.h>
>>>>
>>>>   / {
>>>>  + cpu0_opp_table: opp_table0 {
>>>>  + compatible = "operating-points-v2";
>>>>  + opp-shared;
>>>>  +
>>>>  + opp@648000000 {
>>>>  + opp-hz = /bits/ 64 <648000000>;
>>>>  + opp-microvolt = <1040000>;
>>>>  + clock-latency-ns = <244144>; /* 8 32k periods */
>>>>  + };
>>>>  +
>>>>  + opp@816000000 {
>>>>  + opp-hz = /bits/ 64 <816000000>;
>>>>  + opp-microvolt = <1100000>;
>>>>  + clock-latency-ns = <244144>; /* 8 32k periods */
>>>>  + };
>>>>  +
>>>>  + opp@1008000000 {
>>>>  + opp-hz = /bits/ 64 <1008000000>;
>>>>  + opp-microvolt = <1200000>;
>>>>  + clock-latency-ns = <244144>; /* 8 32k periods */
>>>>  + };
>>>>  +
>>>>  + opp@1200000000 {
>>>>  + opp-hz = /bits/ 64 <1200000000>;
>>>>  + opp-microvolt = <1320000>;
>>>>  + clock-latency-ns = <244144>; /* 8 32k periods */
>>>>  + };
>>>>  + };
>>>>  +

Also, there are a lot more operating points for the A33, see:
https://github.com/QSchulz/linux/blob/v4.9-rc4_adc_a31_v7/cpufreq_a33/arch/arm/boot/dts/sun8i-a33.dtsi#L323-L340

They are present in the Allwinner Linux source code and in the fex of
all A33-based boards.

Is there a reason for not adding all opp?

Quentin

-- 
Quentin Schulz, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com

^ permalink raw reply
* Re: [PATCH] ARM: dts: sun8i-q8-common: enable bluetooth on SDIO Wi-Fi
From: Chen-Yu Tsai @ 2016-12-19 14:24 UTC (permalink / raw)
  To: Icenowy Zheng
  Cc: devicetree@vger.kernel.org, linux-kernel, Hans de Goede,
	Chen-Yu Tsai, Maxime Ripard, linux-arm-kernel@lists.infradead.org
In-Reply-To: <11985541482156512@web2g.yandex.ru>

On Mon, Dec 19, 2016 at 10:08 PM, Icenowy Zheng <icenowy@aosc.xyz> wrote:
>
>
> 19.12.2016, 18:09, "Maxime Ripard" <maxime.ripard@free-electrons.com>:
>> On Fri, Dec 16, 2016 at 10:40:00PM +0800, Icenowy Zheng wrote:
>>>  >>  > >  &r_pio {
>>>  >>  > >  wifi_pwrseq_pin_q8: wifi_pwrseq_pin@0 {
>>>  >>  > > - pins = "PL6", "PL7", "PL11";
>>>  >>  > > + pins = "PL6", "PL7", "PL8", "PL11";
>>>  >>  > >  function = "gpio_in";
>>>  >>  > >  bias-pull-up;
>>>  >>  > >  };
>>>  >>  >
>>>  >>  > There's several things wrong here. The first one is that you rely
>>>  >>  > solely on the pinctrl state to maintain a reset line. This is very
>>>  >>  > fragile (especially since the GPIO pinctrl state are likely to go away
>>>  >>  > at some point), but it also means that if your driver wants to recover
>>>  >>  > from that situation at some point, it won't work.
>>>  >>  >
>>>  >>  > The other one is that the bluetooth and wifi chips are two devices in
>>>  >>  > linux, and you assign that pin to the wrong device (wifi).
>>>  >>  >
>>>  >>  > rfkill-gpio is made just for that, so please use it.
>>>  >>
>>>  >>  The GPIO is not for the radio, but for the full Bluetooth part.
>>>  >
>>>  > I know.
>>>  >
>>>  >>  If it's set to 0, then the bluetooth part will reset, and the
>>>  >>  hciattach will fail.
>>>  >
>>>  > Both rfkill-gpio and rfkill-regulator will shutdown when called
>>>  > (either by poking the reset pin or shutting down the regulator), so
>>>  > that definitely seems like an expected behavior to put the device in
>>>  > reset.
>>>  >
>>>  >>  The BSP uses this as a rfkill, and the result is that the bluetooth
>>>  >>  on/off switch do not work properly.
>>>  >
>>>  > Then rfkill needs fixing, but working around it by hoping that the
>>>  > core will probe an entirely different device, and enforcing a default
>>>  > that the rest of the kernel might or might not change is both fragile
>>>  > and wrong.
>>>
>>>  I think a rfkill-gpio here works just like the BSP rfkill...
>>>
>>>  The real problem is that the Realtek UART bluetooth driver is a userspace
>>>  program (a modified hciattach), which is not capable of the GPIO reset...
>>
>> Can't you run rfkill before attaching? What is the problem exactly?
>> It's not in reset for long enough?
>>
>> This seems more and more like an issue in the BT stack you're
>> using. We might consider workarounds in the kernel, but they have to
>> be correct.
>
> One more rfkill interface will be generated for hci0 after hciattach, which can
> be safely toggled block and unblock.
>
> However, if the GPIO is toggled down, the hciattach program will die.
>
> The bluetooth stack I used is fd.o's BlueZ.

I think the bigger issue is that the tty/serial subsystem does not have
power sequencing support. Here we're trying to use rfkill to do that,
but that doesn't seem to be what it was intended for. It might work with
standalone USB bluetooth controllers that don't need any special setup,
since the device will just appear and get registered. But it might not
work so well with UART based adapters that need userspace fiddling with
firmware and hciattach.

And like Icenowy mentioned, the bluetooth stack registers another rfkill
control, which presumable just blocks transmissions.

Regards
ChenYu

>
>>
>> Maxime
>>
>> --
>> Maxime Ripard, Free Electrons
>> Embedded Linux and Kernel engineering
>> http://free-electrons.com

^ permalink raw reply
* Re: [PATCH v2] ARM: dts: sun8i: add opp-v2 table for A33
From: Quentin Schulz @ 2016-12-19 14:18 UTC (permalink / raw)
  To: Icenowy Zheng, Chen-Yu Tsai, Maxime Ripard
  Cc: devicetree, linux-kernel, Hans de Goede, linux-sunxi, linux-clk,
	linux-arm-kernel
In-Reply-To: <11975791482156406@web2g.yandex.ru>

Hi,

On 19/12/2016 15:06, Icenowy Zheng wrote:
> 
> After proper testing of A23 ccu, the operating points can also apply to A23.
> (According to A23 devices' fex)
> 

I disagree. I've looked into using the same operating points for A23 and
A33 for CPUfreq and I came to the conclusion that not all A23-based
boards share the same operating points. You can find the fex files for
the different boards here:
https://github.com/linux-sunxi/sunxi-boards/tree/master/sys_config/a23

After gathering all supported frequencies/voltages for each A23-based
boards, I found that only the following frequencies and voltages are
supported by all A23-based boards:

 - 1008 MHz, 1220 mV
 - 816 MHz, 1120 mV
 - 600 MHz, 1040 mV

Quentin

-- 
Quentin Schulz, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com

^ permalink raw reply
* [PATCH 4/4] arm64: dts: marvell: Add ethernet switch definition for the EXPRESSObin
From: Romain Perier @ 2016-12-19 14:16 UTC (permalink / raw)
  To: Andrew Lunn, Vivien Didelot, Florian Fainelli, Jason Cooper,
	Sebastian Hesselbarth, Gregory Clement
  Cc: Mark Rutland, devicetree, Romain Perier, Pawel Moll, Ian Campbell,
	netdev, Nadav Haklai, Rob Herring, Kumar Gala, Thomas Petazzoni,
	linux-arm-kernel
In-Reply-To: <20161219141610.30934-1-romain.perier@free-electrons.com>

This defines and enables the Marvell ethernet switch MVE886341 on the
Marvell EXPRESSObin board.

Signed-off-by: Romain Perier <romain.perier@free-electrons.com>
---
 .../boot/dts/marvell/armada-3720-espressobin.dts   | 67 ++++++++++++++++++++++
 1 file changed, 67 insertions(+)

diff --git a/arch/arm64/boot/dts/marvell/armada-3720-espressobin.dts b/arch/arm64/boot/dts/marvell/armada-3720-espressobin.dts
index 83178d9..8ba6c0b 100644
--- a/arch/arm64/boot/dts/marvell/armada-3720-espressobin.dts
+++ b/arch/arm64/boot/dts/marvell/armada-3720-espressobin.dts
@@ -80,3 +80,70 @@
 &usb3 {
 	status = "okay";
 };
+
+&mdio {
+	switch0: switch0@0 {
+		compatible = "marvell,mv88e6085";
+		#address-cells = <1>;
+		#size-cells = <0>;
+		reg = <1>;
+
+		dsa,member = <0 0>;
+
+		ports {
+			#address-cells = <1>;
+			#size-cells = <0>;
+
+			port@0 {
+				reg = <0>;
+				label = "cpu";
+				ethernet = <&eth0>;
+			};
+
+			port@1 {
+				reg = <1>;
+				label = "wan";
+				phy-handle = <&switch0phy0>;
+			};
+
+			port@2 {
+				reg = <2>;
+				label = "lan0";
+				phy-handle = <&switch0phy1>;
+			};
+
+			port@3 {
+				reg = <3>;
+				label = "lan1";
+				phy-handle = <&switch0phy2>;
+			};
+
+		};
+
+		mdio {
+			#address-cells = <1>;
+			#size-cells = <0>;
+			reg = <1>;
+
+			switch0phy0: switch0phy0@0 {
+				reg = <0x11>;
+			};
+			switch0phy1: switch0phy1@1 {
+				reg = <0x12>;
+			};
+			switch0phy2: switch0phy2@2 {
+				reg = <0x13>;
+			};
+		};
+	};
+};
+
+&eth0 {
+	phy-mode = "rgmii-id";
+	status = "okay";
+
+	fixed-link {
+		speed = <1000>;
+		full-duplex;
+	};
+};
-- 
2.9.3

^ permalink raw reply related
* [PATCH 3/4] net: dsa: mv88e6xxx: Add support for ethernet switch 88E6341/88E6141
From: Romain Perier @ 2016-12-19 14:16 UTC (permalink / raw)
  To: Andrew Lunn, Vivien Didelot, Florian Fainelli, Jason Cooper,
	Sebastian Hesselbarth, Gregory Clement
  Cc: Mark Rutland, devicetree, Romain Perier, Pawel Moll, Ian Campbell,
	netdev, Nadav Haklai, Rob Herring, Kumar Gala, Thomas Petazzoni,
	linux-arm-kernel
In-Reply-To: <20161219141610.30934-1-romain.perier@free-electrons.com>

The Marvell 88E6341 device is single-chip, 6-port ethernet switch with
four integrated 10/100/1000Mbps ethernet transceivers and one high speed
SerDes interfaces. It is compatible with switches of family 88E6352.

This commit adds basic support for this switch by describing its
capabilities to the driver.

Signed-off-by: Romain Perier <romain.perier@free-electrons.com>
---
 drivers/net/dsa/mv88e6xxx/chip.c      | 14 ++++++++++++++
 drivers/net/dsa/mv88e6xxx/mv88e6xxx.h |  4 +++-
 2 files changed, 17 insertions(+), 1 deletion(-)

diff --git a/drivers/net/dsa/mv88e6xxx/chip.c b/drivers/net/dsa/mv88e6xxx/chip.c
index 76d944e..72ba24b 100644
--- a/drivers/net/dsa/mv88e6xxx/chip.c
+++ b/drivers/net/dsa/mv88e6xxx/chip.c
@@ -4086,6 +4086,20 @@ static const struct mv88e6xxx_info mv88e6xxx_table[] = {
 		.ops = &mv88e6321_ops,
 	},
 
+	[MV88E6341] = {
+		.prod_num = PORT_SWITCH_ID_PROD_NUM_6341,
+		.family = MV88E6XXX_FAMILY_6352,
+		.name = "Marvell 88E6341",
+		.num_databases = 4096,
+		.num_ports = 6,
+		.port_base_addr = 0x10,
+		.global1_addr = 0x1b,
+		.age_time_coeff = 15000,
+		.tag_protocol = DSA_TAG_PROTO_EDSA,
+		.flags = MV88E6XXX_FLAGS_FAMILY_6352,
+		.ops = &mv88e6352_ops,
+	},
+
 	[MV88E6350] = {
 		.prod_num = PORT_SWITCH_ID_PROD_NUM_6350,
 		.family = MV88E6XXX_FAMILY_6351,
diff --git a/drivers/net/dsa/mv88e6xxx/mv88e6xxx.h b/drivers/net/dsa/mv88e6xxx/mv88e6xxx.h
index af54bae..176d6c4 100644
--- a/drivers/net/dsa/mv88e6xxx/mv88e6xxx.h
+++ b/drivers/net/dsa/mv88e6xxx/mv88e6xxx.h
@@ -86,6 +86,7 @@
 #define PORT_SWITCH_ID_PROD_NUM_6097	0x099
 #define PORT_SWITCH_ID_PROD_NUM_6131	0x106
 #define PORT_SWITCH_ID_PROD_NUM_6320	0x115
+#define PORT_SWITCH_ID_PROD_NUM_6341	0x340
 #define PORT_SWITCH_ID_PROD_NUM_6123	0x121
 #define PORT_SWITCH_ID_PROD_NUM_6161	0x161
 #define PORT_SWITCH_ID_PROD_NUM_6165	0x165
@@ -432,6 +433,7 @@ enum mv88e6xxx_model {
 	MV88E6290,
 	MV88E6320,
 	MV88E6321,
+	MV88E6341,
 	MV88E6350,
 	MV88E6351,
 	MV88E6352,
@@ -448,7 +450,7 @@ enum mv88e6xxx_family {
 	MV88E6XXX_FAMILY_6185,	/* 6108 6121 6122 6131 6152 6155 6182 6185 */
 	MV88E6XXX_FAMILY_6320,	/* 6320 6321 */
 	MV88E6XXX_FAMILY_6351,	/* 6171 6175 6350 6351 */
-	MV88E6XXX_FAMILY_6352,	/* 6172 6176 6240 6352 */
+	MV88E6XXX_FAMILY_6352,	/* 6172 6176 6240 6341 6352 */
 	MV88E6XXX_FAMILY_6390,  /* 6190 6190X 6191 6290 6390 6390X */
 };
 
-- 
2.9.3

^ permalink raw reply related
* [PATCH 2/4] net: dsa: mv88e6xxx: Don't forbid MDIO I/Os for PHY addr >= num_of_ports
From: Romain Perier @ 2016-12-19 14:16 UTC (permalink / raw)
  To: Andrew Lunn, Vivien Didelot, Florian Fainelli, Jason Cooper,
	Sebastian Hesselbarth, Gregory Clement
  Cc: netdev, devicetree, Rob Herring, Ian Campbell, Pawel Moll,
	Mark Rutland, Kumar Gala, linux-arm-kernel, Thomas Petazzoni,
	Nadav Haklai, Romain Perier
In-Reply-To: <20161219141610.30934-1-romain.perier@free-electrons.com>

Some Marvell ethernet switches have internal ethernet transceivers with
hardcoded phy addresses. These addresses can be grearer than the number
of ports or its value might be different than the associated port number.
This is for example the case for MV88E6341 that has 6 ports and internal
Port 1 to Port4 PHYs mapped at SMI addresses from 0x11 to 0x14.

This commits fixes the issue by removing the condition in MDIO callbacks.

Signed-off-by: Romain Perier <romain.perier@free-electrons.com>
---
 drivers/net/dsa/mv88e6xxx/chip.c | 6 ------
 1 file changed, 6 deletions(-)

diff --git a/drivers/net/dsa/mv88e6xxx/chip.c b/drivers/net/dsa/mv88e6xxx/chip.c
index b5f0e1e..76d944e 100644
--- a/drivers/net/dsa/mv88e6xxx/chip.c
+++ b/drivers/net/dsa/mv88e6xxx/chip.c
@@ -2881,9 +2881,6 @@ static int mv88e6xxx_mdio_read(struct mii_bus *bus, int phy, int reg)
 	u16 val;
 	int err;
 
-	if (phy >= mv88e6xxx_num_ports(chip))
-		return 0xffff;
-
 	mutex_lock(&chip->reg_lock);
 	err = mv88e6xxx_phy_read(chip, phy, reg, &val);
 	mutex_unlock(&chip->reg_lock);
@@ -2896,9 +2893,6 @@ static int mv88e6xxx_mdio_write(struct mii_bus *bus, int phy, int reg, u16 val)
 	struct mv88e6xxx_chip *chip = bus->priv;
 	int err;
 
-	if (phy >= mv88e6xxx_num_ports(chip))
-		return 0xffff;
-
 	mutex_lock(&chip->reg_lock);
 	err = mv88e6xxx_phy_write(chip, phy, reg, val);
 	mutex_unlock(&chip->reg_lock);
-- 
2.9.3

^ permalink raw reply related
* [PATCH 1/4] net: dsa: mv88e6xxx: Allow mv88e6xxx_smi_init() to be used at address 0x1
From: Romain Perier @ 2016-12-19 14:16 UTC (permalink / raw)
  To: Andrew Lunn, Vivien Didelot, Florian Fainelli, Jason Cooper,
	Sebastian Hesselbarth, Gregory Clement
  Cc: netdev, devicetree, Rob Herring, Ian Campbell, Pawel Moll,
	Mark Rutland, Kumar Gala, linux-arm-kernel, Thomas Petazzoni,
	Nadav Haklai, Romain Perier
In-Reply-To: <20161219141610.30934-1-romain.perier@free-electrons.com>

Currently, the function mv88e6xxx_smi_init() returns -EINVAL if the bit
zero of sw_addr is 0x1. However, on some platforms, ethernet switches
are configured in Multi chip addressing mode and available at MDIO
address 0x1.

Signed-off-by: Romain Perier <romain.perier@free-electrons.com>
---
 drivers/net/dsa/mv88e6xxx/chip.c | 4 ----
 1 file changed, 4 deletions(-)

diff --git a/drivers/net/dsa/mv88e6xxx/chip.c b/drivers/net/dsa/mv88e6xxx/chip.c
index f7222dc..b5f0e1e 100644
--- a/drivers/net/dsa/mv88e6xxx/chip.c
+++ b/drivers/net/dsa/mv88e6xxx/chip.c
@@ -4240,10 +4240,6 @@ static void mv88e6xxx_phy_destroy(struct mv88e6xxx_chip *chip)
 static int mv88e6xxx_smi_init(struct mv88e6xxx_chip *chip,
 			      struct mii_bus *bus, int sw_addr)
 {
-	/* ADDR[0] pin is unavailable externally and considered zero */
-	if (sw_addr & 0x1)
-		return -EINVAL;
-
 	if (sw_addr == 0)
 		chip->smi_ops = &mv88e6xxx_smi_single_chip_ops;
 	else if (mv88e6xxx_has(chip, MV88E6XXX_FLAGS_MULTI_CHIP))
-- 
2.9.3

^ permalink raw reply related
* [PATCH 0/4] Add support for the ethernet switch on the EXPRESSObin
From: Romain Perier @ 2016-12-19 14:16 UTC (permalink / raw)
  To: Andrew Lunn, Vivien Didelot, Florian Fainelli, Jason Cooper,
	Sebastian Hesselbarth, Gregory Clement
  Cc: Mark Rutland, devicetree, Romain Perier, Pawel Moll, Ian Campbell,
	netdev, Nadav Haklai, Rob Herring, Kumar Gala, Thomas Petazzoni,
	linux-arm-kernel

This set of patches adds support for the Marvell ethernet switch 88E6341.
It also add the devicetree definition of thid switch to the DT board.

Romain Perier (4):
  net: dsa: mv88e6xxx: Allow mv88e6xxx_smi_init() to be used at address
    0x1
  net: dsa: mv88e6xxx: Don't forbid MDIO I/Os for PHY addr >=
    num_of_ports
  net: dsa: mv88e6xxx: Add support for ethernet switch 88E6341/88E6141
  arm64: dts: marvell: Add ethernet switch definition for the
    EXPRESSObin

 .../boot/dts/marvell/armada-3720-espressobin.dts   | 67 ++++++++++++++++++++++
 drivers/net/dsa/mv88e6xxx/chip.c                   | 24 ++++----
 drivers/net/dsa/mv88e6xxx/mv88e6xxx.h              |  4 +-
 3 files changed, 84 insertions(+), 11 deletions(-)

-- 
2.9.3

^ permalink raw reply
* Re: [PATCH] ARM: dts: sun8i-q8-common: enable bluetooth on SDIO Wi-Fi
From: Icenowy Zheng @ 2016-12-19 14:08 UTC (permalink / raw)
  To: Maxime Ripard
  Cc: Hans de Goede, Chen-Yu Tsai, linux-kernel,
	linux-arm-kernel@lists.infradead.org, devicetree@vger.kernel.org
In-Reply-To: <20161219100952.bspym36nsehda3za@lukather>



19.12.2016, 18:09, "Maxime Ripard" <maxime.ripard@free-electrons.com>:
> On Fri, Dec 16, 2016 at 10:40:00PM +0800, Icenowy Zheng wrote:
>>  >>  > >  &r_pio {
>>  >>  > >  wifi_pwrseq_pin_q8: wifi_pwrseq_pin@0 {
>>  >>  > > - pins = "PL6", "PL7", "PL11";
>>  >>  > > + pins = "PL6", "PL7", "PL8", "PL11";
>>  >>  > >  function = "gpio_in";
>>  >>  > >  bias-pull-up;
>>  >>  > >  };
>>  >>  >
>>  >>  > There's several things wrong here. The first one is that you rely
>>  >>  > solely on the pinctrl state to maintain a reset line. This is very
>>  >>  > fragile (especially since the GPIO pinctrl state are likely to go away
>>  >>  > at some point), but it also means that if your driver wants to recover
>>  >>  > from that situation at some point, it won't work.
>>  >>  >
>>  >>  > The other one is that the bluetooth and wifi chips are two devices in
>>  >>  > linux, and you assign that pin to the wrong device (wifi).
>>  >>  >
>>  >>  > rfkill-gpio is made just for that, so please use it.
>>  >>
>>  >>  The GPIO is not for the radio, but for the full Bluetooth part.
>>  >
>>  > I know.
>>  >
>>  >>  If it's set to 0, then the bluetooth part will reset, and the
>>  >>  hciattach will fail.
>>  >
>>  > Both rfkill-gpio and rfkill-regulator will shutdown when called
>>  > (either by poking the reset pin or shutting down the regulator), so
>>  > that definitely seems like an expected behavior to put the device in
>>  > reset.
>>  >
>>  >>  The BSP uses this as a rfkill, and the result is that the bluetooth
>>  >>  on/off switch do not work properly.
>>  >
>>  > Then rfkill needs fixing, but working around it by hoping that the
>>  > core will probe an entirely different device, and enforcing a default
>>  > that the rest of the kernel might or might not change is both fragile
>>  > and wrong.
>>
>>  I think a rfkill-gpio here works just like the BSP rfkill...
>>
>>  The real problem is that the Realtek UART bluetooth driver is a userspace
>>  program (a modified hciattach), which is not capable of the GPIO reset...
>
> Can't you run rfkill before attaching? What is the problem exactly?
> It's not in reset for long enough?
>
> This seems more and more like an issue in the BT stack you're
> using. We might consider workarounds in the kernel, but they have to
> be correct.

One more rfkill interface will be generated for hci0 after hciattach, which can
be safely toggled block and unblock.

However, if the GPIO is toggled down, the hciattach program will die.

The bluetooth stack I used is fd.o's BlueZ.

>
> Maxime
>
> --
> Maxime Ripard, Free Electrons
> Embedded Linux and Kernel engineering
> http://free-electrons.com

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

^ permalink raw reply
* Re: [PATCH v2] ARM: dts: sun8i: add opp-v2 table for A33
From: Icenowy Zheng @ 2016-12-19 14:06 UTC (permalink / raw)
  To: Chen-Yu Tsai, Maxime Ripard
  Cc: Hans de Goede, Quentin Schulz, devicetree, linux-arm-kernel,
	linux-kernel, linux-clk, linux-sunxi
In-Reply-To: <CAGb2v65YWntCrFHtSbxhtTWkt+UwkW3xoY-ae26MpH+-ULLXSQ-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>



19.12.2016, 16:54, "Chen-Yu Tsai" <wens-jdAy2FN1RRM@public.gmane.org>:
> On Mon, Dec 19, 2016 at 4:46 PM, Maxime Ripard
> <maxime.ripard-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org> wrote:
>>  On Fri, Dec 16, 2016 at 02:27:54AM +0800, Icenowy Zheng wrote:
>>>  An operating point table is needed for the cpu frequency adjusting to
>>>  work.
>>>
>>>  The operating point table is converted from the common value in
>>>  extracted script.fex from many A33 board/tablets.
>>>
>>>  Signed-off-by: Icenowy Zheng <icenowy-ymACFijhrKM@public.gmane.org>
>>>  ---
>>>  Changes since v1:
>>>  - Fix format problem (blank lines).
>>>  - Removed the 1.344GHz operating point, as it's overvoltage and overclocked.
>>>
>>>  This patch depends on the following patchset:
>>>
>>>  http://lists.infradead.org/pipermail/linux-arm-kernel/2016-December/473962.html
>>>
>>>  It's the v2 of the [PATCH 4/6] in this patchset.
>>>
>>>  I think this operating point table may also apply to A23, as there's no
>>>  difference except the points over 1.2GHz between A23 and A33's stock dvfs table.
>>>
>>>  But as A23 CCU may not have the necessary fixes, I won't add the table to A23
>>>  now.
>>>
>>>  Chen-Yu, could you test the CCU fixes I described in the patchset above on A23,
>>>  then test this operating points table?
>>>
>>>  If it's necessary, you can send out the CCU fixes and add one more patch that
>>>  moves this opp-v2 table to sun8i-a23-a33.dtsi .
>>>
>>>   arch/arm/boot/dts/sun8i-a33.dtsi | 35 +++++++++++++++++++++++++++++++++++
>>>   1 file changed, 35 insertions(+)
>>>
>>>  diff --git a/arch/arm/boot/dts/sun8i-a33.dtsi b/arch/arm/boot/dts/sun8i-a33.dtsi
>>>  index 504996cbee29..0f5b2af72981 100644
>>>  --- a/arch/arm/boot/dts/sun8i-a33.dtsi
>>>  +++ b/arch/arm/boot/dts/sun8i-a33.dtsi
>>>  @@ -46,7 +46,42 @@
>>>   #include <dt-bindings/dma/sun4i-a10.h>
>>>
>>>   / {
>>>  + cpu0_opp_table: opp_table0 {
>>>  + compatible = "operating-points-v2";
>>>  + opp-shared;
>>>  +
>>>  + opp@648000000 {
>>>  + opp-hz = /bits/ 64 <648000000>;
>>>  + opp-microvolt = <1040000>;
>>>  + clock-latency-ns = <244144>; /* 8 32k periods */
>>>  + };
>>>  +
>>>  + opp@816000000 {
>>>  + opp-hz = /bits/ 64 <816000000>;
>>>  + opp-microvolt = <1100000>;
>>>  + clock-latency-ns = <244144>; /* 8 32k periods */
>>>  + };
>>>  +
>>>  + opp@1008000000 {
>>>  + opp-hz = /bits/ 64 <1008000000>;
>>>  + opp-microvolt = <1200000>;
>>>  + clock-latency-ns = <244144>; /* 8 32k periods */
>>>  + };
>>>  +
>>>  + opp@1200000000 {
>>>  + opp-hz = /bits/ 64 <1200000000>;
>>>  + opp-microvolt = <1320000>;
>>>  + clock-latency-ns = <244144>; /* 8 32k periods */
>>>  + };
>>>  + };
>>>  +
>>>        cpus {
>>>  + cpu0: cpu@0 {
>>
>>  There's no need to duplicate the label here. I removed it and applied.
>
> I think using the label to directly reference cpu0 would be better,
> instead of duplicating the cpu@0 block.

After proper testing of A23 ccu, the operating points can also apply to A23.
(According to A23 devices' fex)

>
> ChenYu

-- 
You received this message because you are subscribed to the Google Groups "linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org
For more options, visit https://groups.google.com/d/optout.

^ permalink raw reply
* Re: [PATCH] ARM: dts: Add missing CPU frequencies for Exynos5422/5800
From: Alim Akhtar @ 2016-12-19 13:35 UTC (permalink / raw)
  To: Krzysztof Kozlowski, Doug Anderson
  Cc: Bartlomiej Zolnierkiewicz, Javier Martinez Canillas, Arjun K V,
	Kukjin Kim, Rob Herring, Mark Rutland, Russell King,
	Andreas Faerber, Thomas Abraham, Ben Gamari, linux-samsung-soc,
	linux-arm-kernel@lists.infradead.org, linux-pm@vger.kernel.org,
	devicetree@vger.kernel.org, linux-kernel@vger.kernel.org
In-Reply-To: <20161216073720.GA3489@kozik-lap>

Hi,

On 12/16/2016 01:07 PM, Krzysztof Kozlowski wrote:
> On Thu, Dec 15, 2016 at 04:52:58PM -0800, Doug Anderson wrote:
>>> [ I added Arjun to Cc:, maybe he can help in explaining this issue
>>>    (unfortunately Inderpal's email is no longer working). ]
>>>
>>> Please also note that on Exynos5422/5800 SoCs the same ARM rail
>>> voltage is used for 1.9 GHz & 2.0 GHz OPPs as for the 1.8 GHz one.
>>> IOW if the problem exists it is already present in the mainline
>>> kernel.
>>
>> Interesting.  In the ChromeOS tree I see significantly higher voltages
>> needed...  Note that one might naively look at
>> <https://chromium.googlesource.com/chromiumos/third_party/kernel/+/chromeos-3.8/drivers/cpufreq/exynos5420-cpufreq.c#178>.
>>
>> 1362500, /* L0  2100 */
>> 1312500, /* L1  2000 */
>>
>> ..but, amazingly enough those voltages aren't used at all.  Surprise!
>>
>> I believe that the above numbers are actually not used and the ASV
>> numbers are used instead.  See
>> <https://chromium.googlesource.com/chromiumos/third_party/kernel/+/chromeos-3.8/arch/arm/mach-exynos/include/mach/asv-exynos542x.h#452>
>>
>> { 2100000,
>> 1350000, 1350000, 1350000, 1350000, 1350000,
>> 1337500, 1325000, 1312500, 1300000, 1287500,
>> 1275000, 1262500, 1250000, 1237500 },
>>
>> I believe that interpretation there is: some bins of the CPU can run
>> at 2.1 GHz just fine at 1.25 V but others need up to 1.35V.
>
> That is definitely the case. One could just look at vendors ASV table
> (for 1.9 GHz):
> { 1900000, 1300000, 1287500, 1262500, 1237500, 1225000, 1212500,
>                      1200000, 1187500, 1175000, 1162500, 1150000,
> 		             1137500, 1125000, 1112500, 1112500},
>
> The theoretical difference is up to 1.875V! From my experiments I saw
> BIN1 chips which should be the same... but some working on 1.2V, some on
> 1.225V (@1.9 GHz). I didn't see any requiring higher voltages but that
> does not mean that there aren't such...
>
>> ...so if you're running at 2.1 GHz at 1.25V then perhaps you're just
>> running on a CPU from a nice bin?
>
> Would be nice to see a dump of PKG_ID and AUX_INFO chipid registers
> along with name of tested board. Because the "Tested on XU3" is not
> sufficient.
>
I agree, we should be dumping PKG_ID and other chip info to know on 
which BIN sample this patch is tested on...
As far as Peach-{pit/pi} boards are concerns, this is what I can remember:
1> 5420 (PIT) -> max recommended target frequency is 1800 MHz for A15
2> 5800 (PI)-> max recommended target frequency can go upto 2000 MHz, 
with INT rail locking.
INT rail locking schemes never made to mainline, so to be safer side 
instead of bumping the clock and voltages better to keep it at safer 
range for pit and pi, probably thats why it was kept at 1800MHz.
I am not sure if the same limitation applies to Odroid-XU3 samples.


> Best regards,
> Krzysztof
>
>
>

^ permalink raw reply
* Re: [PATCH/RFC v2 3/7] spi: core: Add support for registering SPI slave controllers
From: Mark Brown @ 2016-12-19 13:28 UTC (permalink / raw)
  To: Geert Uytterhoeven
  Cc: Geert Uytterhoeven, Rob Herring, Mark Rutland, Magnus Damm,
	Wolfram Sang, Hisashi Nakamura, Hiromitsu Yamasaki, linux-spi,
	devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, Linux-Renesas,
	linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
In-Reply-To: <CAMuHMdXJu0-iTFu3KMWXbbgidB63Mxy0oAWmTKKt0UUKuPbprA-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>

[-- Attachment #1: Type: text/plain, Size: 1430 bytes --]

On Mon, Dec 19, 2016 at 11:02:07AM +0100, Geert Uytterhoeven wrote:
> On Thu, Dec 15, 2016 at 6:53 PM, Mark Brown <broonie-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org> wrote:
> > On Mon, Sep 12, 2016 at 10:50:42PM +0200, Geert Uytterhoeven wrote:
> >> TBD:
> >>   - s/spi_master/spi_controller/ where appropriate,
> >>   - Provide wrappers (e.g. "#define spi_master spi_controller" until all
> >>     SPI drivers have been converted),
> >>   - Do we want a separate spi_register_slave() instead?

> > This basically looks fine to me - there's these TBDs so I might be
> > missing things and we probably need some GPIO chip select handling but

> Given the hard real-time requirements of SPI slave, supporting GPIO chip
> select may not be feasible.

It's not unknown for SPI devices to have some minimum time requirement
from chip select to first clock so it's workable and probably something
people will want at some point.  It can always be done later though.

> As I managed to fix the issue with spi_slave_abort() on MSIOF, I think
> the remaining
> obstacle is the DT binding.  Do you have any feedback or other
> suggestions in that area?

> IMHO having the ability to bind to an SPI slave handler either from DT or
> by using the sysfs virtual file is useful to have.

I think it'd be useful to have DT support but really I think the DT
maintainers are going to have more opinions on this than me.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

^ permalink raw reply
* Re: [PATCH 19/21] MIPS memblock: Add print out method of kernel virtual memory layout
From: Serge Semin @ 2016-12-19 13:15 UTC (permalink / raw)
  To: James Hogan
  Cc: Matt Redfearn, ralf, paul.burton, rabinv, alexander.sverdlin,
	robh+dt, frowand.list, Sergey.Semin, linux-mips, devicetree,
	linux-kernel
In-Reply-To: <20161219130236.GJ27950@jhogan-linux.le.imgtec.org>

On Mon, Dec 19, 2016 at 01:02:37PM +0000, James Hogan <james.hogan@imgtec.com> wrote:
> Hi Matt,
> 
> On Mon, Dec 19, 2016 at 12:04:54PM +0000, Matt Redfearn wrote:
> > On 19/12/16 02:07, Serge Semin wrote:
> > > It's useful to have some printed map of the kernel virtual memory,
> > > at least for debugging purpose.
> > >
> > > Signed-off-by: Serge Semin <fancer.lancer@gmail.com>
> > > ---
> 
> > > @@ -106,6 +107,49 @@ static void __init zone_sizes_init(void)
> > >   }
> > >   
> > >   /*
> > > + * Print out kernel memory layout
> > > + */
> > > +#define MLK(b, t) b, t, ((t) - (b)) >> 10
> > > +#define MLM(b, t) b, t, ((t) - (b)) >> 20
> > > +#define MLK_ROUNDUP(b, t) b, t, DIV_ROUND_UP(((t) - (b)), SZ_1K)
> > > +static void __init mem_print_kmap_info(void)
> > > +{
> > > +	pr_notice("Virtual kernel memory layout:\n"
> > > +		  "    lowmem  : 0x%08lx - 0x%08lx   (%4ld MB)\n"
> > > +		  "    vmalloc : 0x%08lx - 0x%08lx   (%4ld MB)\n"
> > > +#ifdef CONFIG_HIGHMEM
> > > +		  "    pkmap   : 0x%08lx - 0x%08lx   (%4ld MB)\n"
> > > +#endif
> > > +		  "    fixmap  : 0x%08lx - 0x%08lx   (%4ld kB)\n"
> > > +		  "      .text : 0x%p" " - 0x%p" "   (%4td kB)\n"
> > > +		  "      .data : 0x%p" " - 0x%p" "   (%4td kB)\n"
> > > +		  "      .init : 0x%p" " - 0x%p" "   (%4td kB)\n",
> > > +		MLM(PAGE_OFFSET, (unsigned long)high_memory),
> > > +		MLM(VMALLOC_START, VMALLOC_END),
> > > +#ifdef CONFIG_HIGHMEM
> > > +		MLM(PKMAP_BASE, (PKMAP_BASE) + (LAST_PKMAP)*(PAGE_SIZE)),
> > > +#endif
> > > +		MLK(FIXADDR_START, FIXADDR_TOP),
> > > +		MLK_ROUNDUP(_text, _etext),
> > > +		MLK_ROUNDUP(_sdata, _edata),
> > > +		MLK_ROUNDUP(__init_begin, __init_end));
> > 
> > Please drop printing the kernel addresses, or at least only do it if 
> > KASLR is not turned on, otherwise you're removing the advantage of 
> > KASLR, that critical kernel addresses cannot be determined easily from 
> > userspace.
> 
> According to Documentation/printk-formats.txt, this is what %pK is for.
> Better to use that instead?
> 
> Cheers
> James
> 

The function is called from the kernel directly, which is privileged
enough to do the printing. So I suppose Matt is right, to hide this
prints out unless debug is enabled.

Thanks,
-Sergey

> > 
> > It may be better to merge the functionality of show_kernel_relocation
> > http://lxr.free-electrons.com/source/arch/mips/kernel/relocate.c#L354
> > into this function, but only print it under the same conditions as 
> > currently, i.e.
> > #if defined(CONFIG_DEBUG_KERNEL) && defined(CONFIG_DEBUG_INFO)
> > http://lxr.free-electrons.com/source/arch/mips/kernel/setup.c#L530
> > 
> > Thanks,
> > Matt

^ permalink raw reply
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox