* [PATCH 3/8] [RFC] arm64: dts: renesas: Add R-Car M3-W SiP (2 x 1 GiB) support
From: Geert Uytterhoeven @ 2017-04-19 9:15 UTC (permalink / raw)
To: Simon Horman, Magnus Damm, Kuninori Morimoto, Yoshihiro Shimoda,
Rob Herring, Mark Rutland
Cc: linux-renesas-soc, devicetree, linux-arm-kernel,
Geert Uytterhoeven
In-Reply-To: <1492593351-13835-1-git-send-email-geert+renesas@glider.be>
Add support for the R-Car M3-W System-in-Package (r8j7796), which contains:
- an R-Car M3-W SoC (r8a7796),
- 2 channels of 1 GiB of RAM (2 GiB total),
- HyperFlash (not yet described).
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
---
Questions:
- Should this file be named r8j7796-2g.dtsi instead?
- What's the official name of r8j7796 with 2 x 1 GiB of RAM?
---
arch/arm64/boot/dts/renesas/r8j7796-2x1g.dtsi | 26 ++++++++++++++++++++++++++
1 file changed, 26 insertions(+)
create mode 100644 arch/arm64/boot/dts/renesas/r8j7796-2x1g.dtsi
diff --git a/arch/arm64/boot/dts/renesas/r8j7796-2x1g.dtsi b/arch/arm64/boot/dts/renesas/r8j7796-2x1g.dtsi
new file mode 100644
index 0000000000000000..ba274c132e6dd984
--- /dev/null
+++ b/arch/arm64/boot/dts/renesas/r8j7796-2x1g.dtsi
@@ -0,0 +1,26 @@
+/*
+ * Device Tree Source for the r8a7796 SiP with 2 channels of 1 GiB RAM
+ *
+ * Copyright (C) 2016 Renesas Electronics Corp.
+ *
+ * This file is licensed under the terms of the GNU General Public License
+ * version 2. This program is licensed "as is" without any warranty of any
+ * kind, whether express or implied.
+ */
+
+#include "r8a7796.dtsi"
+
+/ {
+ compatible = "renesas,r8j7796", "renesas,r8a7796";
+
+ memory@48000000 {
+ device_type = "memory";
+ /* first 128MB is reserved for secure area. */
+ reg = <0x0 0x48000000 0x0 0x38000000>;
+ };
+
+ memory@600000000 {
+ device_type = "memory";
+ reg = <0x6 0x00000000 0x0 0x40000000>;
+ };
+};
--
2.7.4
^ permalink raw reply related
* [PATCH 4/8] [RFC] arm64: dts: renesas: Add R-Car M3-W SiP (2 x 2 GiB) support
From: Geert Uytterhoeven @ 2017-04-19 9:15 UTC (permalink / raw)
To: Simon Horman, Magnus Damm, Kuninori Morimoto, Yoshihiro Shimoda,
Rob Herring, Mark Rutland
Cc: linux-renesas-soc, devicetree, linux-arm-kernel,
Geert Uytterhoeven
In-Reply-To: <1492593351-13835-1-git-send-email-geert+renesas@glider.be>
Add support for the R-Car M3-W System-in-Package (r8j7796), which contains:
- an R-Car M3-W SoC (r8a7796),
- 2 channels of 2 GiB of RAM (4 GiB total),
- HyperFlash (not yet described).
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
---
Questions:
- Should this file be named r8j7796-4g.dtsi instead?
- What's the official name of r8j7796 with 2 x 2 GiB of RAM?
---
arch/arm64/boot/dts/renesas/r8j7796-2x2g.dtsi | 26 ++++++++++++++++++++++++++
1 file changed, 26 insertions(+)
create mode 100644 arch/arm64/boot/dts/renesas/r8j7796-2x2g.dtsi
diff --git a/arch/arm64/boot/dts/renesas/r8j7796-2x2g.dtsi b/arch/arm64/boot/dts/renesas/r8j7796-2x2g.dtsi
new file mode 100644
index 0000000000000000..9623bd2b4a914ae3
--- /dev/null
+++ b/arch/arm64/boot/dts/renesas/r8j7796-2x2g.dtsi
@@ -0,0 +1,26 @@
+/*
+ * Device Tree Source for the r8a7796 SiP with 2 channels of 2 GiB RAM
+ *
+ * Copyright (C) 2016 Renesas Electronics Corp.
+ *
+ * This file is licensed under the terms of the GNU General Public License
+ * version 2. This program is licensed "as is" without any warranty of any
+ * kind, whether express or implied.
+ */
+
+#include "r8a7796.dtsi"
+
+/ {
+ compatible = "renesas,r8j7796", "renesas,r8a7796";
+
+ memory@48000000 {
+ device_type = "memory";
+ /* first 128MB is reserved for secure area. */
+ reg = <0x0 0x48000000 0x0 0x78000000>;
+ };
+
+ memory@600000000 {
+ device_type = "memory";
+ reg = <0x6 0x00000000 0x0 0x80000000>;
+ };
+};
--
2.7.4
^ permalink raw reply related
* [PATCH 5/8] [RFC] arm64: dts: renesas: Migrate R-Car H3 Salvator-X to r8j7795-4x1g.dtsi
From: Geert Uytterhoeven @ 2017-04-19 9:15 UTC (permalink / raw)
To: Simon Horman, Magnus Damm, Kuninori Morimoto, Yoshihiro Shimoda,
Rob Herring, Mark Rutland
Cc: linux-renesas-soc-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
Geert Uytterhoeven
In-Reply-To: <1492593351-13835-1-git-send-email-geert+renesas-gXvu3+zWzMSzQB+pC5nmwQ@public.gmane.org>
The Renesas R-Car H3 Salvator-X development board is equipped with an
r8j7795 SiP with 4 GiB of RAM.
Hence migrate from r8a7795.dtsi to r8j7795-4x1g.dtsi.
Signed-off-by: Geert Uytterhoeven <geert+renesas-gXvu3+zWzMSzQB+pC5nmwQ@public.gmane.org>
---
Questions:
- Should this file be renamed to r8j7795-salvator-x.dts?
---
arch/arm64/boot/dts/renesas/r8a7795-salvator-x.dts | 27 +++-------------------
1 file changed, 3 insertions(+), 24 deletions(-)
diff --git a/arch/arm64/boot/dts/renesas/r8a7795-salvator-x.dts b/arch/arm64/boot/dts/renesas/r8a7795-salvator-x.dts
index ff68bac4cd7ed2f5..e5b9409bf2d218d8 100644
--- a/arch/arm64/boot/dts/renesas/r8a7795-salvator-x.dts
+++ b/arch/arm64/boot/dts/renesas/r8a7795-salvator-x.dts
@@ -32,12 +32,12 @@
*/
/dts-v1/;
-#include "r8a7795.dtsi"
+#include "r8j7795-4x1g.dtsi"
#include <dt-bindings/gpio/gpio.h>
/ {
- model = "Renesas Salvator-X board based on r8a7795";
- compatible = "renesas,salvator-x", "renesas,r8a7795";
+ model = "Renesas Salvator-X board based on r8j7795";
+ compatible = "renesas,salvator-x", "renesas,r8j7795", "renesas,r8a7795";
aliases {
serial0 = &scif2;
@@ -50,27 +50,6 @@
stdout-path = "serial0:115200n8";
};
- memory@48000000 {
- device_type = "memory";
- /* first 128MB is reserved for secure area. */
- reg = <0x0 0x48000000 0x0 0x38000000>;
- };
-
- memory@500000000 {
- device_type = "memory";
- reg = <0x5 0x00000000 0x0 0x40000000>;
- };
-
- memory@600000000 {
- device_type = "memory";
- reg = <0x6 0x00000000 0x0 0x40000000>;
- };
-
- memory@700000000 {
- device_type = "memory";
- reg = <0x7 0x00000000 0x0 0x40000000>;
- };
-
x12_clk: x12 {
compatible = "fixed-clock";
#clock-cells = <0>;
--
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/8] [RFC] arm64: dts: renesas: Migrate R-Car M3-W Salvator-X to r8j7796-2x2g.dtsi
From: Geert Uytterhoeven @ 2017-04-19 9:15 UTC (permalink / raw)
To: Simon Horman, Magnus Damm, Kuninori Morimoto, Yoshihiro Shimoda,
Rob Herring, Mark Rutland
Cc: linux-renesas-soc-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
Geert Uytterhoeven
In-Reply-To: <1492593351-13835-1-git-send-email-geert+renesas-gXvu3+zWzMSzQB+pC5nmwQ@public.gmane.org>
The Renesas R-Car M3-W Salvator-X development board is equipped with an
r8j7796 SiP with 4 GiB of RAM.
Hence migrate from r8a7796.dtsi to r8j7796-2x2g.dtsi.
Signed-off-by: Geert Uytterhoeven <geert+renesas-gXvu3+zWzMSzQB+pC5nmwQ@public.gmane.org>
---
Questions:
- Should this file be renamed to r8j7796-salvator-x.dts?
---
arch/arm64/boot/dts/renesas/r8a7796-salvator-x.dts | 17 +++--------------
1 file changed, 3 insertions(+), 14 deletions(-)
diff --git a/arch/arm64/boot/dts/renesas/r8a7796-salvator-x.dts b/arch/arm64/boot/dts/renesas/r8a7796-salvator-x.dts
index 7f0ac6a9d49b8da6..26f5ff938bd2728d 100644
--- a/arch/arm64/boot/dts/renesas/r8a7796-salvator-x.dts
+++ b/arch/arm64/boot/dts/renesas/r8a7796-salvator-x.dts
@@ -9,12 +9,12 @@
*/
/dts-v1/;
-#include "r8a7796.dtsi"
+#include "r8j7796-2x2g.dtsi"
#include <dt-bindings/gpio/gpio.h>
/ {
- model = "Renesas Salvator-X board based on r8a7796";
- compatible = "renesas,salvator-x", "renesas,r8a7796";
+ model = "Renesas Salvator-X board based on r8j7796";
+ compatible = "renesas,salvator-x", "renesas,r8j7796", "renesas,r8a7796";
aliases {
serial0 = &scif2;
@@ -27,17 +27,6 @@
stdout-path = "serial0:115200n8";
};
- memory@48000000 {
- device_type = "memory";
- /* first 128MB is reserved for secure area. */
- reg = <0x0 0x48000000 0x0 0x78000000>;
- };
-
- memory@600000000 {
- device_type = "memory";
- reg = <0x6 0x00000000 0x0 0x80000000>;
- };
-
reg_1p8v: regulator0 {
compatible = "regulator-fixed";
regulator-name = "fixed-1.8V";
--
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 7/8] [RFC] arm64: dts: renesas: Migrate H3ULCB to r8j7795-4x1g.dtsi
From: Geert Uytterhoeven @ 2017-04-19 9:15 UTC (permalink / raw)
To: Simon Horman, Magnus Damm, Kuninori Morimoto, Yoshihiro Shimoda,
Rob Herring, Mark Rutland
Cc: linux-renesas-soc, devicetree, linux-arm-kernel,
Geert Uytterhoeven
In-Reply-To: <1492593351-13835-1-git-send-email-geert+renesas@glider.be>
The Renesas R-Car Starter Kit Premier (H3ULCB) development board is
equipped with an r8j7795 SiP with 4 GiB of RAM.
Hence migrate from r8a7795.dtsi to r8j7795-4x1g.dtsi.
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
---
Questions:
- Should this file be renamed to r8j7795-h3ulcb.dts?
---
arch/arm64/boot/dts/renesas/r8a7795-h3ulcb.dts | 27 +++-----------------------
1 file changed, 3 insertions(+), 24 deletions(-)
diff --git a/arch/arm64/boot/dts/renesas/r8a7795-h3ulcb.dts b/arch/arm64/boot/dts/renesas/r8a7795-h3ulcb.dts
index 3574965e074718d8..fe7eca39490eb1a2 100644
--- a/arch/arm64/boot/dts/renesas/r8a7795-h3ulcb.dts
+++ b/arch/arm64/boot/dts/renesas/r8a7795-h3ulcb.dts
@@ -10,13 +10,13 @@
*/
/dts-v1/;
-#include "r8a7795.dtsi"
+#include "r8j7795-4x1g.dtsi"
#include <dt-bindings/gpio/gpio.h>
#include <dt-bindings/input/input.h>
/ {
- model = "Renesas H3ULCB board based on r8a7795";
- compatible = "renesas,h3ulcb", "renesas,r8a7795";
+ model = "Renesas H3ULCB board based on r8j7795";
+ compatible = "renesas,h3ulcb", "renesas,r8j7795", "renesas,r8a7795";
aliases {
serial0 = &scif2;
@@ -27,27 +27,6 @@
stdout-path = "serial0:115200n8";
};
- memory@48000000 {
- device_type = "memory";
- /* first 128MB is reserved for secure area. */
- reg = <0x0 0x48000000 0x0 0x38000000>;
- };
-
- memory@500000000 {
- device_type = "memory";
- reg = <0x5 0x00000000 0x0 0x40000000>;
- };
-
- memory@600000000 {
- device_type = "memory";
- reg = <0x6 0x00000000 0x0 0x40000000>;
- };
-
- memory@700000000 {
- device_type = "memory";
- reg = <0x7 0x00000000 0x0 0x40000000>;
- };
-
leds {
compatible = "gpio-leds";
--
2.7.4
^ permalink raw reply related
* [PATCH 8/8] [RFC] arm64: dts: renesas: Migrate M3ULCB to r8j7796-2x1g.dtsi
From: Geert Uytterhoeven @ 2017-04-19 9:15 UTC (permalink / raw)
To: Simon Horman, Magnus Damm, Kuninori Morimoto, Yoshihiro Shimoda,
Rob Herring, Mark Rutland
Cc: linux-renesas-soc, devicetree, linux-arm-kernel,
Geert Uytterhoeven
In-Reply-To: <1492593351-13835-1-git-send-email-geert+renesas@glider.be>
The Renesas R-Car Starter Kit Pro (M3ULCB) development board is equipped
with an r8j7796 SiP with 2 GiB of RAM.
Hence migrate from r8a7796.dtsi to r8j7796-2x1g.dtsi.
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
---
Questions:
- Should this file be renamed to r8j7796-m3ulcb.dts?
---
arch/arm64/boot/dts/renesas/r8a7796-m3ulcb.dts | 17 +++--------------
1 file changed, 3 insertions(+), 14 deletions(-)
diff --git a/arch/arm64/boot/dts/renesas/r8a7796-m3ulcb.dts b/arch/arm64/boot/dts/renesas/r8a7796-m3ulcb.dts
index c2a4549d3738f81c..533d03662e98982b 100644
--- a/arch/arm64/boot/dts/renesas/r8a7796-m3ulcb.dts
+++ b/arch/arm64/boot/dts/renesas/r8a7796-m3ulcb.dts
@@ -10,13 +10,13 @@
*/
/dts-v1/;
-#include "r8a7796.dtsi"
+#include "r8j7796-2x1g.dtsi"
#include <dt-bindings/gpio/gpio.h>
#include <dt-bindings/input/input.h>
/ {
- model = "Renesas M3ULCB board based on r8a7796";
- compatible = "renesas,m3ulcb", "renesas,r8a7796";
+ model = "Renesas M3ULCB board based on r8j7796";
+ compatible = "renesas,m3ulcb", "renesas,r8j7796", "renesas,r8a7796";
aliases {
serial0 = &scif2;
@@ -27,17 +27,6 @@
stdout-path = "serial0:115200n8";
};
- memory@48000000 {
- device_type = "memory";
- /* first 128MB is reserved for secure area. */
- reg = <0x0 0x48000000 0x0 0x38000000>;
- };
-
- memory@600000000 {
- device_type = "memory";
- reg = <0x6 0x00000000 0x0 0x40000000>;
- };
-
leds {
compatible = "gpio-leds";
--
2.7.4
^ permalink raw reply related
* Re: [PATCH v13 02/10] dt-bindings: document devicetree bindings for mux-controllers and gpio-mux
From: Philipp Zabel @ 2017-04-19 9:17 UTC (permalink / raw)
To: Peter Rosin
Cc: linux-kernel-u79uwXL29TY76Z2rM5mHXA, Greg Kroah-Hartman,
Mark Rutland, devicetree-u79uwXL29TY76Z2rM5mHXA,
Lars-Peter Clausen, Wolfram Sang,
linux-iio-u79uwXL29TY76Z2rM5mHXA, Jonathan Corbet,
linux-doc-u79uwXL29TY76Z2rM5mHXA, kernel-bIcnvbaLZ9MEGnE8C9+IrQ,
Paul Gortmaker, Rob Herring, linux-i2c-u79uwXL29TY76Z2rM5mHXA,
Peter Meerwald-Stadler, Hartmut Knaack, Colin Ian King,
Andrew Morton, Jonathan Cameron
In-Reply-To: <17135062-e58a-b50e-ac85-5f0f0b73d958-koto5C5qi+TLoDKTGw+V6w@public.gmane.org>
On Tue, 2017-04-18 at 15:36 +0200, Peter Rosin wrote:
> On 2017-04-18 12:06, Philipp Zabel wrote:
> > On Thu, 2017-04-13 at 18:43 +0200, Peter Rosin wrote:
> >> Allow specifying that a single multiplexer controller can be used to
> >> control several parallel multiplexers, thus enabling sharing of the
> >> multiplexer controller by different consumers.
> >>
> >> Add a binding for a first mux controller in the form of a GPIO based mux
> >> controller.
> >>
> >> Acked-by: Jonathan Cameron <jic23-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
> >> Acked-by: Rob Herring <robh-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
> >> Signed-off-by: Peter Rosin <peda-koto5C5qi+TLoDKTGw+V6w@public.gmane.org>
> >> ---
> >> Documentation/devicetree/bindings/mux/gpio-mux.txt | 69 +++++++++
> >> .../devicetree/bindings/mux/mux-controller.txt | 157 +++++++++++++++++++++
> >> MAINTAINERS | 6 +
> >> include/dt-bindings/mux/mux.h | 16 +++
> >> 4 files changed, 248 insertions(+)
> >> create mode 100644 Documentation/devicetree/bindings/mux/gpio-mux.txt
> >> create mode 100644 Documentation/devicetree/bindings/mux/mux-controller.txt
> >> create mode 100644 include/dt-bindings/mux/mux.h
> >>
> >> diff --git a/Documentation/devicetree/bindings/mux/gpio-mux.txt b/Documentation/devicetree/bindings/mux/gpio-mux.txt
> >> new file mode 100644
> >> index 000000000000..b8f746344d80
> >> --- /dev/null
> >> +++ b/Documentation/devicetree/bindings/mux/gpio-mux.txt
> >> @@ -0,0 +1,69 @@
> >> +GPIO-based multiplexer controller bindings
> >> +
> >> +Define what GPIO pins are used to control a multiplexer. Or several
> >> +multiplexers, if the same pins control more than one multiplexer.
> >> +
> >> +Required properties:
> >> +- compatible : "gpio-mux"
> >> +- mux-gpios : list of gpios used to control the multiplexer, least
> >> + significant bit first.
> >> +- #mux-control-cells : <0>
> >> +* Standard mux-controller bindings as decribed in mux-controller.txt
> >> +
> >> +Optional properties:
> >> +- idle-state : if present, the state the mux will have when idle. The
> >> + special state MUX_IDLE_AS_IS is the default.
> >> +
> >> +The multiplexer state is defined as the number represented by the
> >> +multiplexer GPIO pins, where the first pin is the least significant
> >> +bit. An active pin is a binary 1, an inactive pin is a binary 0.
> >> +
> >> +Example:
> >> +
> >> + mux: mux-controller {
> >> + compatible = "gpio-mux";
> >> + #mux-control-cells = <0>;
> >> +
> >> + mux-gpios = <&pioA 0 GPIO_ACTIVE_HIGH>,
> >> + <&pioA 1 GPIO_ACTIVE_HIGH>;
> >> + };
> >> +
> >> + adc-mux {
> >> + compatible = "io-channel-mux";
> >> + io-channels = <&adc 0>;
> >> + io-channel-names = "parent";
> >> +
> >> + mux-controls = <&mux>;
> >> +
> >> + channels = "sync-1", "in", "out", "sync-2";
> >> + };
> >
> > Could you explain in more detail the reasoning behind this split between
> > the mux controller and the actual mux?
> > For SoC internal video bus muxes that are controlled by a register
> > bitfield, it seems a bit strange to have to split them into two device
> > tree nodes.
>
> The background for the split is in the cover letter.
Thanks for explaining anyway, I didn't read past the changelog earlier.
[...]
> > Basically I'm trying to figure out whether a video mux (which has a mux
> > control plus OF-graph bindings to describe its ports and connections)
> > would fit into the same category as an adc-mux or i2c-mux, or whether it
> > would be better to handle them as a specialized form of mux-controller.
>
> I did read some earlier thread about your muxing requirements and I got
> the impression that you also had HW which controlled the mux with
> gpio lines? In that case, the mux subsystem seems like a perfect fit
> with a new syscon/mmio/reg based mux driver (or whatever the name should
> be, I think I'd go with syscon) pretty much as suggested in your RFC
> patches. And then of course reuse the existing gpio-mux driver for the
> other case.
Yes, the requirement on hand is for MMIO controlled SoC internal muxes
for the i.MX6 video capture subsystem, but I'd like to also support GPIO
controlled external muxes to switch between two camera sources on those
boards that have them.
> The video-mux would fit as a mux consumer just like the iio-mux and the
> i2c-mux are mux consumers, with input 0/input 1 being the port that
> would be selected with the mux I guess.
Exactly. An N-input mux would have N+1 ports with port N being the
output.
[...]
> If I got things wrong when I skimmed whatever I came across, and if the
> mmio register is the only mux control option in the stars, it becomes
> less obvious... It's of course still possible to hook into the mux
> subsystem, but the benefit is questionable. And you do get the extra
> device tree node. You could of course also implement a mux driver
> outside of drivers/mux and thus make use of the mux api, but it's tiny
> and any benefit is truly small.
What I wondered mostly is whether it would be a good idea to move the
OF-graph ports into the mux controller node, and let the video capture
device be the consumer of the mux.
But this wouldn't fit well with the clear split between the mux
controller and the actual mux hardware in the mux DT bindings.
regards
Philipp
^ permalink raw reply
* Re: [PATCH] ARM: dts: rockchip: reuse firefly dtsi
From: Heiko Stuebner @ 2017-04-19 9:55 UTC (permalink / raw)
To: Eddie Cai
Cc: robh+dt-DgEjT+Ai2ygdnm+yROfE0A, mark.rutland-5wv7dgnIgG8,
linux-I+IVW8TIWO2tmTQ+vhA3Yw,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-rockchip-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <CAJrj+DPjNnk9n5k4DoxJ0Focm0DOz6362PYtVRZTEkaUFKYX0g-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
Hi Eddie,
Am Mittwoch, 19. April 2017, 08:42:09 CEST schrieb Eddie Cai:
> 2017-04-19 6:20 GMT+08:00 Heiko Stuebner <heiko-4mtYJXux2i+zQB+pC5nmwQ@public.gmane.org>:
> > Hi Eddie,
> >
> > Am Dienstag, 18. April 2017, 20:15:27 CEST schrieb Eddie Cai:
> >> firefly reload is very similar with firefly board, so reuse firefly dtsi
> >>
> >> Signed-off-by: Eddie Cai <eddie.cai.linux-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
> >> ---
> >> arch/arm/boot/dts/rk3288-firefly-reload-core.dtsi | 310 ------------------
> >> arch/arm/boot/dts/rk3288-firefly-reload.dts | 368 ++--------------------
> >
> > I would disagree and remember having a similar discussion when the reload-
> > support was initially submitted. Please keep in mind that the firefly-
> > reload is a som+baseboard combination, so somebody could (or maybe
> > already has) create a completely different baseboard for the som that
> > does not have any similarities with the original firefly.
> > The previous firefly being a real single board.
> >
> > We also don't combine rock2 and firefly and other boards following the
> > general rk3288 design guidelines :-) and the original firefly and reload are
> > very different boards if you look at them.
> OK, i think the real similar part is the core board and firefly. how
> about reuse the
> firefly code in the core board?
I'd really like to keep these separate.
- firefly-rk3288 is one board
- firefly-rk3288-reload is a completely different som+baseboard
That they both have the "firefly" in the name is really more based on the
company being named firefly :-) , but are not an indication that they
are similar boards.
Heiko
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH] ARM: dts: vexpress: fix few unit address format warnings
From: Liviu Dudau @ 2017-04-19 10:07 UTC (permalink / raw)
To: Sudeep Holla
Cc: linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
devicetree-u79uwXL29TY76Z2rM5mHXA, Lorenzo Pieralisi
In-Reply-To: <1492537507-7783-1-git-send-email-sudeep.holla-5wv7dgnIgG8@public.gmane.org>
On Tue, Apr 18, 2017 at 06:45:07PM +0100, Sudeep Holla wrote:
> This patch fixes the following set of warnings on vexpress platforms:
>
> sysreg@010000 simple-bus unit address format error, expected "10000"
> sysctl@020000 simple-bus unit address format error, expected "20000"
> i2c@030000 simple-bus unit address format error, expected "30000"
> aaci@040000 simple-bus unit address format error, expected "40000"
> mmci@050000 simple-bus unit address format error, expected "50000"
> kmi@060000 simple-bus unit address format error, expected "60000"
> kmi@070000 simple-bus unit address format error, expected "70000"
> uart@090000 simple-bus unit address format error, expected "90000"
> uart@0a0000 simple-bus unit address format error, expected "a0000"
> uart@0b0000 simple-bus unit address format error, expected "b0000"
> uart@0c0000 simple-bus unit address format error, expected "c0000"
> wdt@0f0000 simple-bus unit address format error, expected "f0000"
>
> Cc: Liviu Dudau <liviu.dudau-5wv7dgnIgG8@public.gmane.org>
Acked-by: Liviu Dudau <liviu.dudau-5wv7dgnIgG8@public.gmane.org>
> Cc: Lorenzo Pieralisi <lorenzo.pieralisi-5wv7dgnIgG8@public.gmane.org>
> Signed-off-by: Sudeep Holla <sudeep.holla-5wv7dgnIgG8@public.gmane.org>
> ---
> arch/arm/boot/dts/vexpress-v2m-rs1.dtsi | 24 ++++++++++++------------
> arch/arm/boot/dts/vexpress-v2m.dtsi | 24 ++++++++++++------------
> arch/arm/boot/dts/vexpress-v2p-ca15-tc1.dts | 2 +-
> arch/arm/boot/dts/vexpress-v2p-ca15_a7.dts | 18 +++++++++---------
> arch/arm/boot/dts/vexpress-v2p-ca5s.dts | 2 +-
> arch/arm/boot/dts/vexpress-v2p-ca9.dts | 2 +-
> 6 files changed, 36 insertions(+), 36 deletions(-)
>
> Hi,
>
> I observed few warning in linux-next due to the enhanced DTC checks
> introduced with DTC upgrade in linux-next. The patch fixes few warnings
All changes look sensible to me in order to fix the warnings, but I feel like
letting out a minor rant from me: the fact that DTC now complains about leading
zeros in what is usually a numeric field is silly. I find it easier to parse numbers
that have the same width. Also, now the reg property doesn't match the @<number>
part if you grep for it.
Best regards,
Liviu
>
> Regards,
> Sudeep
>
> diff --git a/arch/arm/boot/dts/vexpress-v2m-rs1.dtsi b/arch/arm/boot/dts/vexpress-v2m-rs1.dtsi
> index 3086efacd00e..35714ff6f467 100644
> --- a/arch/arm/boot/dts/vexpress-v2m-rs1.dtsi
> +++ b/arch/arm/boot/dts/vexpress-v2m-rs1.dtsi
> @@ -71,7 +71,7 @@
> #size-cells = <1>;
> ranges = <0 3 0 0x200000>;
>
> - v2m_sysreg: sysreg@010000 {
> + v2m_sysreg: sysreg@10000 {
> compatible = "arm,vexpress-sysreg";
> reg = <0x010000 0x1000>;
>
> @@ -94,7 +94,7 @@
> };
> };
>
> - v2m_sysctl: sysctl@020000 {
> + v2m_sysctl: sysctl@20000 {
> compatible = "arm,sp810", "arm,primecell";
> reg = <0x020000 0x1000>;
> clocks = <&v2m_refclk32khz>, <&v2m_refclk1mhz>, <&smbclk>;
> @@ -106,7 +106,7 @@
> };
>
> /* PCI-E I2C bus */
> - v2m_i2c_pcie: i2c@030000 {
> + v2m_i2c_pcie: i2c@30000 {
> compatible = "arm,versatile-i2c";
> reg = <0x030000 0x1000>;
>
> @@ -119,7 +119,7 @@
> };
> };
>
> - aaci@040000 {
> + aaci@40000 {
> compatible = "arm,pl041", "arm,primecell";
> reg = <0x040000 0x1000>;
> interrupts = <11>;
> @@ -127,7 +127,7 @@
> clock-names = "apb_pclk";
> };
>
> - mmci@050000 {
> + mmci@50000 {
> compatible = "arm,pl180", "arm,primecell";
> reg = <0x050000 0x1000>;
> interrupts = <9 10>;
> @@ -139,7 +139,7 @@
> clock-names = "mclk", "apb_pclk";
> };
>
> - kmi@060000 {
> + kmi@60000 {
> compatible = "arm,pl050", "arm,primecell";
> reg = <0x060000 0x1000>;
> interrupts = <12>;
> @@ -147,7 +147,7 @@
> clock-names = "KMIREFCLK", "apb_pclk";
> };
>
> - kmi@070000 {
> + kmi@70000 {
> compatible = "arm,pl050", "arm,primecell";
> reg = <0x070000 0x1000>;
> interrupts = <13>;
> @@ -155,7 +155,7 @@
> clock-names = "KMIREFCLK", "apb_pclk";
> };
>
> - v2m_serial0: uart@090000 {
> + v2m_serial0: uart@90000 {
> compatible = "arm,pl011", "arm,primecell";
> reg = <0x090000 0x1000>;
> interrupts = <5>;
> @@ -163,7 +163,7 @@
> clock-names = "uartclk", "apb_pclk";
> };
>
> - v2m_serial1: uart@0a0000 {
> + v2m_serial1: uart@a0000 {
> compatible = "arm,pl011", "arm,primecell";
> reg = <0x0a0000 0x1000>;
> interrupts = <6>;
> @@ -171,7 +171,7 @@
> clock-names = "uartclk", "apb_pclk";
> };
>
> - v2m_serial2: uart@0b0000 {
> + v2m_serial2: uart@b0000 {
> compatible = "arm,pl011", "arm,primecell";
> reg = <0x0b0000 0x1000>;
> interrupts = <7>;
> @@ -179,7 +179,7 @@
> clock-names = "uartclk", "apb_pclk";
> };
>
> - v2m_serial3: uart@0c0000 {
> + v2m_serial3: uart@c0000 {
> compatible = "arm,pl011", "arm,primecell";
> reg = <0x0c0000 0x1000>;
> interrupts = <8>;
> @@ -187,7 +187,7 @@
> clock-names = "uartclk", "apb_pclk";
> };
>
> - wdt@0f0000 {
> + wdt@f0000 {
> compatible = "arm,sp805", "arm,primecell";
> reg = <0x0f0000 0x1000>;
> interrupts = <0>;
> diff --git a/arch/arm/boot/dts/vexpress-v2m.dtsi b/arch/arm/boot/dts/vexpress-v2m.dtsi
> index c6393d3f1719..1b6f6393be93 100644
> --- a/arch/arm/boot/dts/vexpress-v2m.dtsi
> +++ b/arch/arm/boot/dts/vexpress-v2m.dtsi
> @@ -70,7 +70,7 @@
> #size-cells = <1>;
> ranges = <0 7 0 0x20000>;
>
> - v2m_sysreg: sysreg@00000 {
> + v2m_sysreg: sysreg@0 {
> compatible = "arm,vexpress-sysreg";
> reg = <0x00000 0x1000>;
>
> @@ -93,7 +93,7 @@
> };
> };
>
> - v2m_sysctl: sysctl@01000 {
> + v2m_sysctl: sysctl@1000 {
> compatible = "arm,sp810", "arm,primecell";
> reg = <0x01000 0x1000>;
> clocks = <&v2m_refclk32khz>, <&v2m_refclk1mhz>, <&smbclk>;
> @@ -105,7 +105,7 @@
> };
>
> /* PCI-E I2C bus */
> - v2m_i2c_pcie: i2c@02000 {
> + v2m_i2c_pcie: i2c@2000 {
> compatible = "arm,versatile-i2c";
> reg = <0x02000 0x1000>;
>
> @@ -118,7 +118,7 @@
> };
> };
>
> - aaci@04000 {
> + aaci@4000 {
> compatible = "arm,pl041", "arm,primecell";
> reg = <0x04000 0x1000>;
> interrupts = <11>;
> @@ -126,7 +126,7 @@
> clock-names = "apb_pclk";
> };
>
> - mmci@05000 {
> + mmci@5000 {
> compatible = "arm,pl180", "arm,primecell";
> reg = <0x05000 0x1000>;
> interrupts = <9 10>;
> @@ -138,7 +138,7 @@
> clock-names = "mclk", "apb_pclk";
> };
>
> - kmi@06000 {
> + kmi@6000 {
> compatible = "arm,pl050", "arm,primecell";
> reg = <0x06000 0x1000>;
> interrupts = <12>;
> @@ -146,7 +146,7 @@
> clock-names = "KMIREFCLK", "apb_pclk";
> };
>
> - kmi@07000 {
> + kmi@7000 {
> compatible = "arm,pl050", "arm,primecell";
> reg = <0x07000 0x1000>;
> interrupts = <13>;
> @@ -154,7 +154,7 @@
> clock-names = "KMIREFCLK", "apb_pclk";
> };
>
> - v2m_serial0: uart@09000 {
> + v2m_serial0: uart@9000 {
> compatible = "arm,pl011", "arm,primecell";
> reg = <0x09000 0x1000>;
> interrupts = <5>;
> @@ -162,7 +162,7 @@
> clock-names = "uartclk", "apb_pclk";
> };
>
> - v2m_serial1: uart@0a000 {
> + v2m_serial1: uart@a000 {
> compatible = "arm,pl011", "arm,primecell";
> reg = <0x0a000 0x1000>;
> interrupts = <6>;
> @@ -170,7 +170,7 @@
> clock-names = "uartclk", "apb_pclk";
> };
>
> - v2m_serial2: uart@0b000 {
> + v2m_serial2: uart@b000 {
> compatible = "arm,pl011", "arm,primecell";
> reg = <0x0b000 0x1000>;
> interrupts = <7>;
> @@ -178,7 +178,7 @@
> clock-names = "uartclk", "apb_pclk";
> };
>
> - v2m_serial3: uart@0c000 {
> + v2m_serial3: uart@c000 {
> compatible = "arm,pl011", "arm,primecell";
> reg = <0x0c000 0x1000>;
> interrupts = <8>;
> @@ -186,7 +186,7 @@
> clock-names = "uartclk", "apb_pclk";
> };
>
> - wdt@0f000 {
> + wdt@f000 {
> compatible = "arm,sp805", "arm,primecell";
> reg = <0x0f000 0x1000>;
> interrupts = <0>;
> diff --git a/arch/arm/boot/dts/vexpress-v2p-ca15-tc1.dts b/arch/arm/boot/dts/vexpress-v2p-ca15-tc1.dts
> index 15f4fd3f4695..0c8de0ca73ee 100644
> --- a/arch/arm/boot/dts/vexpress-v2p-ca15-tc1.dts
> +++ b/arch/arm/boot/dts/vexpress-v2p-ca15-tc1.dts
> @@ -220,7 +220,7 @@
> };
> };
>
> - smb@08000000 {
> + smb@8000000 {
> compatible = "simple-bus";
>
> #address-cells = <2>;
> diff --git a/arch/arm/boot/dts/vexpress-v2p-ca15_a7.dts b/arch/arm/boot/dts/vexpress-v2p-ca15_a7.dts
> index bd107c5a0226..65ecf206388c 100644
> --- a/arch/arm/boot/dts/vexpress-v2p-ca15_a7.dts
> +++ b/arch/arm/boot/dts/vexpress-v2p-ca15_a7.dts
> @@ -385,7 +385,7 @@
> };
> };
>
> - etb@0,20010000 {
> + etb@20010000 {
> compatible = "arm,coresight-etb10", "arm,primecell";
> reg = <0 0x20010000 0 0x1000>;
>
> @@ -399,7 +399,7 @@
> };
> };
>
> - tpiu@0,20030000 {
> + tpiu@20030000 {
> compatible = "arm,coresight-tpiu", "arm,primecell";
> reg = <0 0x20030000 0 0x1000>;
>
> @@ -449,7 +449,7 @@
> };
> };
>
> - funnel@0,20040000 {
> + funnel@20040000 {
> compatible = "arm,coresight-funnel", "arm,primecell";
> reg = <0 0x20040000 0 0x1000>;
>
> @@ -513,7 +513,7 @@
> };
> };
>
> - ptm@0,2201c000 {
> + ptm@2201c000 {
> compatible = "arm,coresight-etm3x", "arm,primecell";
> reg = <0 0x2201c000 0 0x1000>;
>
> @@ -527,7 +527,7 @@
> };
> };
>
> - ptm@0,2201d000 {
> + ptm@2201d000 {
> compatible = "arm,coresight-etm3x", "arm,primecell";
> reg = <0 0x2201d000 0 0x1000>;
>
> @@ -541,7 +541,7 @@
> };
> };
>
> - etm@0,2203c000 {
> + etm@2203c000 {
> compatible = "arm,coresight-etm3x", "arm,primecell";
> reg = <0 0x2203c000 0 0x1000>;
>
> @@ -555,7 +555,7 @@
> };
> };
>
> - etm@0,2203d000 {
> + etm@2203d000 {
> compatible = "arm,coresight-etm3x", "arm,primecell";
> reg = <0 0x2203d000 0 0x1000>;
>
> @@ -569,7 +569,7 @@
> };
> };
>
> - etm@0,2203e000 {
> + etm@2203e000 {
> compatible = "arm,coresight-etm3x", "arm,primecell";
> reg = <0 0x2203e000 0 0x1000>;
>
> @@ -583,7 +583,7 @@
> };
> };
>
> - smb@08000000 {
> + smb@8000000 {
> compatible = "simple-bus";
>
> #address-cells = <2>;
> diff --git a/arch/arm/boot/dts/vexpress-v2p-ca5s.dts b/arch/arm/boot/dts/vexpress-v2p-ca5s.dts
> index 1acecaf4b13d..6e69b8e6c1a7 100644
> --- a/arch/arm/boot/dts/vexpress-v2p-ca5s.dts
> +++ b/arch/arm/boot/dts/vexpress-v2p-ca5s.dts
> @@ -190,7 +190,7 @@
> };
> };
>
> - smb@08000000 {
> + smb@8000000 {
> compatible = "simple-bus";
>
> #address-cells = <2>;
> diff --git a/arch/arm/boot/dts/vexpress-v2p-ca9.dts b/arch/arm/boot/dts/vexpress-v2p-ca9.dts
> index b608a03ee02f..c9305b58afc2 100644
> --- a/arch/arm/boot/dts/vexpress-v2p-ca9.dts
> +++ b/arch/arm/boot/dts/vexpress-v2p-ca9.dts
> @@ -300,7 +300,7 @@
> };
> };
>
> - smb@04000000 {
> + smb@4000000 {
> compatible = "simple-bus";
>
> #address-cells = <2>;
> --
> 2.7.4
>
--
====================
| I would like to |
| fix the world, |
| but they're not |
| giving me the |
\ source code! /
---------------
¯\_(ツ)_/¯
--
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] arm64: dts: juno: fix few unit address format warnings
From: Liviu Dudau @ 2017-04-19 10:08 UTC (permalink / raw)
To: Sudeep Holla
Cc: linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
devicetree-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <1492538279-16405-1-git-send-email-sudeep.holla-5wv7dgnIgG8@public.gmane.org>
On Tue, Apr 18, 2017 at 06:57:58PM +0100, Sudeep Holla wrote:
> This patch fixes the following set of warnings on juno.
>
> smb@08000000 unit name should not have leading 0s
> sysctl@020000 simple-bus unit address format error, expected "20000"
> apbregs@010000 simple-bus unit address format error, expected "10000"
> mmci@050000 simple-bus unit address format error, expected "50000"
> kmi@060000 simple-bus unit address format error, expected "60000"
> kmi@070000 simple-bus unit address format error, expected "70000"
> wdt@0f0000 simple-bus unit address format error, expected "f0000"
>
> Cc: Liviu Dudau <liviu.dudau-5wv7dgnIgG8@public.gmane.org>
Acked-by: Liviu Dudau <liviu.dudau-5wv7dgnIgG8@public.gmane.org>
Thanks!
Liviu
> Signed-off-by: Sudeep Holla <sudeep.holla-5wv7dgnIgG8@public.gmane.org>
> ---
> arch/arm64/boot/dts/arm/juno-base.dtsi | 2 +-
> arch/arm64/boot/dts/arm/juno-motherboard.dtsi | 12 ++++++------
> 2 files changed, 7 insertions(+), 7 deletions(-)
>
> diff --git a/arch/arm64/boot/dts/arm/juno-base.dtsi b/arch/arm64/boot/dts/arm/juno-base.dtsi
> index 8ffaff2043d0..bfe7d683a42e 100644
> --- a/arch/arm64/boot/dts/arm/juno-base.dtsi
> +++ b/arch/arm64/boot/dts/arm/juno-base.dtsi
> @@ -699,7 +699,7 @@
> <0x00000008 0x80000000 0x1 0x80000000>;
> };
>
> - smb@08000000 {
> + smb@8000000 {
> compatible = "simple-bus";
> #address-cells = <2>;
> #size-cells = <1>;
> diff --git a/arch/arm64/boot/dts/arm/juno-motherboard.dtsi b/arch/arm64/boot/dts/arm/juno-motherboard.dtsi
> index 098601657f82..2ac43221ddb6 100644
> --- a/arch/arm64/boot/dts/arm/juno-motherboard.dtsi
> +++ b/arch/arm64/boot/dts/arm/juno-motherboard.dtsi
> @@ -137,7 +137,7 @@
> #size-cells = <1>;
> ranges = <0 3 0 0x200000>;
>
> - v2m_sysctl: sysctl@020000 {
> + v2m_sysctl: sysctl@20000 {
> compatible = "arm,sp810", "arm,primecell";
> reg = <0x020000 0x1000>;
> clocks = <&v2m_refclk32khz>, <&v2m_refclk1mhz>, <&mb_clk24mhz>;
> @@ -148,7 +148,7 @@
> assigned-clock-parents = <&v2m_refclk1mhz>, <&v2m_refclk1mhz>, <&v2m_refclk1mhz>, <&v2m_refclk1mhz>;
> };
>
> - apbregs@010000 {
> + apbregs@10000 {
> compatible = "syscon", "simple-mfd";
> reg = <0x010000 0x1000>;
>
> @@ -216,7 +216,7 @@
> };
> };
>
> - mmci@050000 {
> + mmci@50000 {
> compatible = "arm,pl180", "arm,primecell";
> reg = <0x050000 0x1000>;
> interrupts = <5>;
> @@ -228,7 +228,7 @@
> clock-names = "mclk", "apb_pclk";
> };
>
> - kmi@060000 {
> + kmi@60000 {
> compatible = "arm,pl050", "arm,primecell";
> reg = <0x060000 0x1000>;
> interrupts = <8>;
> @@ -236,7 +236,7 @@
> clock-names = "KMIREFCLK", "apb_pclk";
> };
>
> - kmi@070000 {
> + kmi@70000 {
> compatible = "arm,pl050", "arm,primecell";
> reg = <0x070000 0x1000>;
> interrupts = <8>;
> @@ -244,7 +244,7 @@
> clock-names = "KMIREFCLK", "apb_pclk";
> };
>
> - wdt@0f0000 {
> + wdt@f0000 {
> compatible = "arm,sp805", "arm,primecell";
> reg = <0x0f0000 0x10000>;
> interrupts = <7>;
> --
> 2.7.4
>
--
====================
| I would like to |
| fix the world, |
| but they're not |
| giving me the |
\ source code! /
---------------
¯\_(ツ)_/¯
--
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 1/9] PM / OPP: Allow OPP table to be used for power-domains
From: Viresh Kumar @ 2017-04-19 10:11 UTC (permalink / raw)
To: Sudeep Holla
Cc: Rafael Wysocki, ulf.hansson-QSEj5FYQhm4dnm+yROfE0A, Kevin Hilman,
Viresh Kumar, Nishanth Menon, Stephen Boyd,
linaro-kernel-cunTk1MwBs8s++Sfvej+rw,
linux-pm-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA, Vincent Guittot,
robh+dt-DgEjT+Ai2ygdnm+yROfE0A, lina.iyer-QSEj5FYQhm4dnm+yROfE0A,
rnayak-sgV2jX0FEOL9JmXXK+q4OQ, devicetree-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <95aa4b97-4e1a-13bb-f4d8-982b778012ba-5wv7dgnIgG8@public.gmane.org>
On 18-04-17, 17:01, Sudeep Holla wrote:
> No, may be I was not so clear. I am just referring a power controller
> that provides say 3 different power domains and are indexed 0 - 2.
> The consumer just passes the index along with the phandle for the power
> domain info.
Ahh, I got you now. Will take care of it in next version.
--
viresh
--
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 1/9] PM / OPP: Allow OPP table to be used for power-domains
From: Viresh Kumar @ 2017-04-19 10:12 UTC (permalink / raw)
To: Sudeep Holla
Cc: Rafael Wysocki, ulf.hansson, Kevin Hilman, Viresh Kumar,
Nishanth Menon, Stephen Boyd, linaro-kernel, linux-pm,
linux-kernel, Vincent Guittot, robh+dt, lina.iyer, rnayak,
devicetree
In-Reply-To: <2128c09a-0656-0878-c4e7-c327007021c7@arm.com>
On 18-04-17, 17:03, Sudeep Holla wrote:
> Was it posted externally ? Was there any objections for that approach ?
> IMO that's better approach but if I am late to the party, I would like
> to read through the discussions that happened on it(if any)
Maybe Stephen can tell more about it. AFAIK, there were some offline
discussions around it.
--
viresh
^ permalink raw reply
* Re: [PATCH] of: introduce event tracepoints for dynamic device_node lifecyle
From: Michael Ellerman @ 2017-04-19 10:13 UTC (permalink / raw)
To: Oliver O'Halloran, Rob Herring
Cc: devicetree@vger.kernel.org, linuxppc-dev,
linux-kernel@vger.kernel.org, rostedt-nx8X9YLhiw1AfugRpC6u6w,
Ingo Molnar, Tyrel Datwyler, Nathan Fontenot, Frank Rowand
In-Reply-To: <CAOSf1CH8HgP0rKd0WCp87BADYcEGT5OCoq_yq+f3ZeoyTcXeng-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
Oliver O'Halloran <oohall-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> writes:
> On Wed, Apr 19, 2017 at 2:46 AM, Rob Herring <robh+dt-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org> wrote:
>> On Mon, Apr 17, 2017 at 7:32 PM, Tyrel Datwyler
>> <tyreld-23VcF4HTsmIX0ybBhKVfKdBPR1lH4CV8@public.gmane.org> wrote:
>>> This patch introduces event tracepoints for tracking a device_nodes
>>> reference cycle as well as reconfig notifications generated in response
>>> to node/property manipulations.
>>>
>>> With the recent upstreaming of the refcount API several device_node
>>> underflows and leaks have come to my attention in the pseries (DLPAR) dynamic
>>> logical partitioning code (ie. POWER speak for hotplugging virtual and physcial
>>> resources at runtime such as cpus or IOAs). These tracepoints provide a
>>> easy and quick mechanism for validating the reference counting of
>>> device_nodes during their lifetime.
>>
>> Not really relevant for this patch, but since you are looking at
>> pseries and refcounting, the refcounting largely exists for pseries.
>> It's also hard to get right as this type of fix is fairly common. It's
>> now used for overlays, but we really probably only need to refcount
>> the overlays or changesets as a whole, not at a node level. If you
>> have any thoughts on how a different model of refcounting could work
>> for pseries, I'd like to discuss it.
>
> One idea I've been kicking around is differentiating short and long
> term references to a node.
I actually did this a long time ago, but balked at the size of the patch
to do the conversion. Let me see if I can find it lying around ...
cheers
--
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 v13 02/10] dt-bindings: document devicetree bindings for mux-controllers and gpio-mux
From: Peter Rosin @ 2017-04-19 10:41 UTC (permalink / raw)
To: Philipp Zabel
Cc: linux-kernel, Greg Kroah-Hartman, Mark Rutland, devicetree,
Lars-Peter Clausen, Wolfram Sang, linux-iio, Jonathan Corbet,
linux-doc, kernel, Paul Gortmaker, Rob Herring, linux-i2c,
Peter Meerwald-Stadler, Hartmut Knaack, Colin Ian King,
Andrew Morton, Jonathan Cameron
In-Reply-To: <1492593449.2970.24.camel@pengutronix.de>
On 2017-04-19 11:17, Philipp Zabel wrote:
> On Tue, 2017-04-18 at 15:36 +0200, Peter Rosin wrote:
>> If I got things wrong when I skimmed whatever I came across, and if the
>> mmio register is the only mux control option in the stars, it becomes
>> less obvious... It's of course still possible to hook into the mux
>> subsystem, but the benefit is questionable. And you do get the extra
>> device tree node. You could of course also implement a mux driver
>> outside of drivers/mux and thus make use of the mux api, but it's tiny
>> and any benefit is truly small.
>
> What I wondered mostly is whether it would be a good idea to move the
> OF-graph ports into the mux controller node, and let the video capture
> device be the consumer of the mux.
> But this wouldn't fit well with the clear split between the mux
> controller and the actual mux hardware in the mux DT bindings.
I have tried to do something similar. I think. The current
drivers/i2c/muxes/i2c-mux-gpio.c is a good candidate for the same thing
IIUC.
That dedicated driver and the general purpose i2c mux driver does pretty
much the same thing with these two DT snippets:
Dedicated i2c-mux-gpio DT snippet:
i2c-mux {
compatible = "i2c-mux-gpio";
i2c-parent = <&i2c1>;
mux-gpios = <&gpio1 22 0 &gpio1 23 0>;
#address-cells = <1>;
#size-cells = <0>;
i2c@1 {
...
};
i2c@3 {
...
};
};
General purpose mux DT snippet:
mux: mux-controller {
compatible = "gpio-mux";
#mux-control-cells = <0>;
mux-gpios = <&gpio1 22 0 &gpio1 23 0>;
};
i2c-mux {
compatible = "i2c-mux";
i2c-parent = <&i2c1>;
mux-controls = <&mux>;
#address-cells = <1>;
#size-cells = <0>;
i2c@1 {
...
};
i2c@3 {
...
};
};
I would love to find a way to cleanly get the mux framework to handle
the first DT as well, and thus being able to obsolete the dedicated
i2c-mux-gpio driver. I have not figured out how to accomplish that
without abusing the driver-model to a point that it's not working.
Help with that task is dearly appreciated.
What I have stumbled on, I think, is that two drivers needs to be
instantiated from the same DT node. At the same time, I need the
mux framework to handle the current out-of-node thing with a
phandle as well, so that several mux consumers can share a common
mux controller. My understanding of these matters are apparently not
deep enough...
I think you would like a DT that looks more like the first DT
snippet but still enjoy the flexibility of the mux framework and w/o
implementing a (another) full muxing sub-sub-system like the i2c
sub-system has done. Correct?
Cheers,
peda
^ permalink raw reply
* Re: [PATCH] media: mtk-vcodec: remove informative log
From: Mauro Carvalho Chehab @ 2017-04-19 10:56 UTC (permalink / raw)
To: Tiffany Lin
Cc: Minghsiu Tsai, Hans Verkuil, daniel.thompson, Rob Herring,
Matthias Brugger, Daniel Kurtz, Pawel Osciak, srv_heupstream,
Eddie Huang, Yingjoe Chen, Wu-Cheng Li, devicetree, linux-kernel,
linux-arm-kernel, linux-media, linux-mediatek
In-Reply-To: <1491390599.32502.1.camel@mtksdaap41>
Em Wed, 5 Apr 2017 19:09:59 +0800
Tiffany Lin <tiffany.lin@mediatek.com> escreveu:
> On Wed, 2017-04-05 at 18:54 +0800, Minghsiu Tsai wrote:
> > Driver is stable. Remove DEBUG definition from driver.
> >
> > There are debug message in /var/log/messages if DEBUG is defined,
> > such as:
> > [MTK_V4L2] level=0 fops_vcodec_open(),170: decoder capability 0
> > [MTK_V4L2] level=0 fops_vcodec_open(),177: 16000000.vcodec decoder [0]
> > [MTK_V4L2] level=0 fops_vcodec_release(),200: [0] decoder
> >
> > Signed-off-by: Minghsiu Tsai <minghsiu.tsai@mediatek.com>
> Acked-by:Tiffany Lin <Tiffany.lin@mediatek.com>
>
> > ---
> > drivers/media/platform/mtk-vcodec/mtk_vcodec_util.h | 1 -
> > 1 file changed, 1 deletion(-)
> >
> > diff --git a/drivers/media/platform/mtk-vcodec/mtk_vcodec_util.h b/drivers/media/platform/mtk-vcodec/mtk_vcodec_util.h
> > index 7d55975..1248083 100644
> > --- a/drivers/media/platform/mtk-vcodec/mtk_vcodec_util.h
> > +++ b/drivers/media/platform/mtk-vcodec/mtk_vcodec_util.h
> > @@ -31,7 +31,6 @@ struct mtk_vcodec_mem {
> > extern int mtk_v4l2_dbg_level;
> > extern bool mtk_vcodec_dbg;
> >
> > -#define DEBUG 1
> >
> > #if defined(DEBUG)
> >
After this patch, building the Kernel with W=1 now shows warnings:
drivers/media/platform/mtk-vcodec/mtk_vcodec_dec_pm.c: In function 'mtk_vcodec_dec_pw_on':
drivers/media/platform/mtk-vcodec/mtk_vcodec_dec_pm.c:114:51: warning: suggest braces around empty body in an 'if' statement [-Wempty-body]
mtk_v4l2_err("pm_runtime_get_sync fail %d", ret);
^
I wrote a patch fixing it, as this is really a trivial issue.
Yet, after that, this one still remains:
drivers/media/platform/mtk-vcodec/mtk_vcodec_dec.c: In function 'mtk_vdec_pic_info_update':
drivers/media/platform/mtk-vcodec/mtk_vcodec_dec.c:284:6: warning: variable 'ret' set but not used [-Wunused-but-set-variable]
int ret;
^~~
Shouldn't be mtk_vdec_pic_info_update() returning an error code?
Also, IMHO, at least errors should be shown at dmesg.
Thanks,
Mauro
^ permalink raw reply
* Re: [PATCH v13 02/10] dt-bindings: document devicetree bindings for mux-controllers and gpio-mux
From: Philipp Zabel @ 2017-04-19 11:05 UTC (permalink / raw)
To: Peter Rosin
Cc: linux-kernel, Greg Kroah-Hartman, Mark Rutland, devicetree,
Lars-Peter Clausen, Wolfram Sang, linux-iio, Jonathan Corbet,
linux-doc, kernel, Paul Gortmaker, Rob Herring, linux-i2c,
Peter Meerwald-Stadler, Hartmut Knaack, Colin Ian King,
Andrew Morton, Jonathan Cameron
In-Reply-To: <0cf0254e-0e43-37c3-f14d-eeffa7d7b9ba@axentia.se>
On Wed, 2017-04-19 at 12:41 +0200, Peter Rosin wrote:
> On 2017-04-19 11:17, Philipp Zabel wrote:
> > On Tue, 2017-04-18 at 15:36 +0200, Peter Rosin wrote:
> >> If I got things wrong when I skimmed whatever I came across, and if the
> >> mmio register is the only mux control option in the stars, it becomes
> >> less obvious... It's of course still possible to hook into the mux
> >> subsystem, but the benefit is questionable. And you do get the extra
> >> device tree node. You could of course also implement a mux driver
> >> outside of drivers/mux and thus make use of the mux api, but it's tiny
> >> and any benefit is truly small.
> >
> > What I wondered mostly is whether it would be a good idea to move the
> > OF-graph ports into the mux controller node, and let the video capture
> > device be the consumer of the mux.
> > But this wouldn't fit well with the clear split between the mux
> > controller and the actual mux hardware in the mux DT bindings.
>
> I have tried to do something similar. I think. The current
> drivers/i2c/muxes/i2c-mux-gpio.c is a good candidate for the same thing
> IIUC.
>
> That dedicated driver and the general purpose i2c mux driver does pretty
> much the same thing with these two DT snippets:
>
> Dedicated i2c-mux-gpio DT snippet:
>
> i2c-mux {
> compatible = "i2c-mux-gpio";
> i2c-parent = <&i2c1>;
>
> mux-gpios = <&gpio1 22 0 &gpio1 23 0>;
>
> #address-cells = <1>;
> #size-cells = <0>;
>
> i2c@1 {
> ...
> };
>
> i2c@3 {
> ...
> };
> };
>
> General purpose mux DT snippet:
>
> mux: mux-controller {
> compatible = "gpio-mux";
> #mux-control-cells = <0>;
>
> mux-gpios = <&gpio1 22 0 &gpio1 23 0>;
> };
>
> i2c-mux {
> compatible = "i2c-mux";
> i2c-parent = <&i2c1>;
>
> mux-controls = <&mux>;
>
> #address-cells = <1>;
> #size-cells = <0>;
>
> i2c@1 {
> ...
> };
>
> i2c@3 {
> ...
> };
> };
Yes, replace i2c-mux with video-mux and the i2c@x nodes with port@x
nodes, and this is very close to what I am thinking about.
> I would love to find a way to cleanly get the mux framework to handle
> the first DT as well, and thus being able to obsolete the dedicated
> i2c-mux-gpio driver. I have not figured out how to accomplish that
> without abusing the driver-model to a point that it's not working.
> Help with that task is dearly appreciated.
>
> What I have stumbled on, I think, is that two drivers needs to be
> instantiated from the same DT node. At the same time, I need the
> mux framework to handle the current out-of-node thing with a
> phandle as well, so that several mux consumers can share a common
> mux controller. My understanding of these matters are apparently not
> deep enough...
Not necessarily, if the framework could export a function to create a
gpio/mmio mux_chip on a given device and the gpio-mux and *-mux-gpio
drivers just reuse that.
> I think you would like a DT that looks more like the first DT
> snippet but still enjoy the flexibility of the mux framework and w/o
> implementing a (another) full muxing sub-sub-system like the i2c
> sub-system has done. Correct?
Correct.
regards
Philipp
^ permalink raw reply
* Re: [PATCH v13 02/10] dt-bindings: document devicetree bindings for mux-controllers and gpio-mux
From: Peter Rosin @ 2017-04-19 11:23 UTC (permalink / raw)
To: Philipp Zabel
Cc: linux-kernel-u79uwXL29TY76Z2rM5mHXA, Greg Kroah-Hartman,
Mark Rutland, devicetree-u79uwXL29TY76Z2rM5mHXA,
Lars-Peter Clausen, Wolfram Sang,
linux-iio-u79uwXL29TY76Z2rM5mHXA, Jonathan Corbet,
linux-doc-u79uwXL29TY76Z2rM5mHXA, kernel-bIcnvbaLZ9MEGnE8C9+IrQ,
Paul Gortmaker, Rob Herring, linux-i2c-u79uwXL29TY76Z2rM5mHXA,
Peter Meerwald-Stadler, Hartmut Knaack, Colin Ian King,
Andrew Morton, Jonathan Cameron
In-Reply-To: <1492599958.2970.84.camel-bIcnvbaLZ9MEGnE8C9+IrQ@public.gmane.org>
On 2017-04-19 13:05, Philipp Zabel wrote:
> On Wed, 2017-04-19 at 12:41 +0200, Peter Rosin wrote:
>> On 2017-04-19 11:17, Philipp Zabel wrote:
>>> On Tue, 2017-04-18 at 15:36 +0200, Peter Rosin wrote:
>>>> If I got things wrong when I skimmed whatever I came across, and if the
>>>> mmio register is the only mux control option in the stars, it becomes
>>>> less obvious... It's of course still possible to hook into the mux
>>>> subsystem, but the benefit is questionable. And you do get the extra
>>>> device tree node. You could of course also implement a mux driver
>>>> outside of drivers/mux and thus make use of the mux api, but it's tiny
>>>> and any benefit is truly small.
>>>
>>> What I wondered mostly is whether it would be a good idea to move the
>>> OF-graph ports into the mux controller node, and let the video capture
>>> device be the consumer of the mux.
>>> But this wouldn't fit well with the clear split between the mux
>>> controller and the actual mux hardware in the mux DT bindings.
>>
>> I have tried to do something similar. I think. The current
>> drivers/i2c/muxes/i2c-mux-gpio.c is a good candidate for the same thing
>> IIUC.
>>
>> That dedicated driver and the general purpose i2c mux driver does pretty
>> much the same thing with these two DT snippets:
>>
>> Dedicated i2c-mux-gpio DT snippet:
>>
>> i2c-mux {
>> compatible = "i2c-mux-gpio";
>> i2c-parent = <&i2c1>;
>>
>> mux-gpios = <&gpio1 22 0 &gpio1 23 0>;
>>
>> #address-cells = <1>;
>> #size-cells = <0>;
>>
>> i2c@1 {
>> ...
>> };
>>
>> i2c@3 {
>> ...
>> };
>> };
>>
>> General purpose mux DT snippet:
>>
>> mux: mux-controller {
>> compatible = "gpio-mux";
>> #mux-control-cells = <0>;
>>
>> mux-gpios = <&gpio1 22 0 &gpio1 23 0>;
>> };
>>
>> i2c-mux {
>> compatible = "i2c-mux";
>> i2c-parent = <&i2c1>;
>>
>> mux-controls = <&mux>;
>>
>> #address-cells = <1>;
>> #size-cells = <0>;
>>
>> i2c@1 {
>> ...
>> };
>>
>> i2c@3 {
>> ...
>> };
>> };
>
> Yes, replace i2c-mux with video-mux and the i2c@x nodes with port@x
> nodes, and this is very close to what I am thinking about.
>
>> I would love to find a way to cleanly get the mux framework to handle
>> the first DT as well, and thus being able to obsolete the dedicated
>> i2c-mux-gpio driver. I have not figured out how to accomplish that
>> without abusing the driver-model to a point that it's not working.
>> Help with that task is dearly appreciated.
>>
>> What I have stumbled on, I think, is that two drivers needs to be
>> instantiated from the same DT node. At the same time, I need the
>> mux framework to handle the current out-of-node thing with a
>> phandle as well, so that several mux consumers can share a common
>> mux controller. My understanding of these matters are apparently not
>> deep enough...
>
> Not necessarily, if the framework could export a function to create a
> gpio/mmio mux_chip on a given device and the gpio-mux and *-mux-gpio
> drivers just reuse that.
I've been up that creek. Why should the gpio mux be special cased?
That's not clean, the implication is that all mux consumers need
to handle the gpio case and have a special compatible for that
case etc. Then someone thinks the DT should look equally "clean" for
some i2c based mux, and the weeds start piling up. This is exactly
what we don't want. We want the mux consumer drivers to be totally
agnostic about the fact that they happen to use a gpio mux.
Cheers,
peda
^ permalink raw reply
* Re: [PATCH v2] usb: dwc3: add disable u2mac linestate check quirk
From: wlf @ 2017-04-19 11:32 UTC (permalink / raw)
To: Guenter Roeck
Cc: William Wu, Felipe Balbi, johnyoun-HKixBCOQz3hWk0Htik3J/w,
gregkh-hQyY1W1yCW8ekmWlsbkhG0B+6BGkLq7r, Heiko Stübner,
linux-kernel, linux-usb-u79uwXL29TY76Z2rM5mHXA,
open list:ARM/Rockchip SoC..., devicetree-u79uwXL29TY76Z2rM5mHXA,
Rob Herring, Frank Wang, Tao Huang, Doug Anderson, Brian Norris,
daniel.meng-TNX95d0MmH7DzftRWevZcw
In-Reply-To: <CABXOdTeszyp834fjYpqESqpKkgzt58Qjms=g+5G5U3Mx4y=b+A-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
Dear Guenter，
在 2017年04月19日 13:15, Guenter Roeck 写道:
> On Tue, Apr 18, 2017 at 8:59 PM, wlf <wulf-TNX95d0MmH7DzftRWevZcw@public.gmane.org> wrote:
>> Dear Guenter,
>>
>>
>>
>> 在 2017年04月18日 21:18, Guenter Roeck 写道:
>>> On Mon, Apr 17, 2017 at 10:17 PM, William Wu <william.wu-TNX95d0MmH7DzftRWevZcw@public.gmane.org>
>>> wrote:
>>>> This patch adds a quirk to disable USB 2.0 MAC linestate check
>>>> during HS transmit. Refer the dwc3 databook, we can use it for
>>>> some special platforms if the linestate not reflect the expected
>>>> line state(J) during transmission.
>>>>
>>>> When use this quirk, the controller implements a fixed 40-bit
>>>> TxEndDelay after the packet is given on UTMI and ignores the
>>>> linestate during the transmit of a token (during token-to-token
>>>> and token-to-data IPGAP).
>>>>
>>>> On some rockchip platforms (e.g. rk3399), it requires to disable
>>>> the u2mac linestate check to decrease the SSPLIT token to SETUP
>>>> token inter-packet delay from 566ns to 466ns, and fix the issue
>>>> that FS/LS devices not recognized if inserted through USB 3.0 HUB.
>>>>
>>>> Signed-off-by: William Wu <william.wu-TNX95d0MmH7DzftRWevZcw@public.gmane.org>
>>>> ---
>>>> Changes in v2:
>>>> - fix coding style
>>>>
>>>> Documentation/devicetree/bindings/usb/dwc3.txt | 2 ++
>>>> drivers/usb/dwc3/core.c | 14 ++++++++++----
>>>> drivers/usb/dwc3/core.h | 4 ++++
>>>> 3 files changed, 16 insertions(+), 4 deletions(-)
>>>>
>>>> diff --git a/Documentation/devicetree/bindings/usb/dwc3.txt
>>>> b/Documentation/devicetree/bindings/usb/dwc3.txt
>>>> index f658f39..6a89f0c 100644
>>>> --- a/Documentation/devicetree/bindings/usb/dwc3.txt
>>>> +++ b/Documentation/devicetree/bindings/usb/dwc3.txt
>>>> @@ -45,6 +45,8 @@ Optional properties:
>>>> a free-running PHY clock.
>>>> - snps,dis-del-phy-power-chg-quirk: when set core will change PHY
>>>> power
>>>> from P0 to P1/P2/P3 without delay.
>>>> + - snps,tx-ipgap-linecheck-dis-quirk: when set, disable u2mac linestate
>>>> check
>>>> + during HS transmit.
>>> All other disable-something quirks are named
>>> "snps,dis-something-quirk". Maybe use the same naming convention ?
>> Yes, good idea！ I will fix it with "snps,dis-tx-ipgap-linecheck-quirk" in
>> next patch verison.
>> Thanks:-)
>>>
>>>> - snps,is-utmi-l1-suspend: true when DWC3 asserts output signal
>>>> utmi_l1_suspend_n, false when asserts
>>>> utmi_sleep_n
>>>> - snps,hird-threshold: HIRD threshold
>>>> diff --git a/drivers/usb/dwc3/core.c b/drivers/usb/dwc3/core.c
>>>> index 455d89a..03429c5 100644
>>>> --- a/drivers/usb/dwc3/core.c
>>>> +++ b/drivers/usb/dwc3/core.c
>>>> @@ -796,15 +796,19 @@ static int dwc3_core_init(struct dwc3 *dwc)
>>>> dwc3_writel(dwc->regs, DWC3_GUCTL2, reg);
>>>> }
>>>>
>>>> + reg = dwc3_readl(dwc->regs, DWC3_GUCTL1);
>>>> +
>>> My understanding is that the register was only introduced with dwc3
>>> revision 2.50a. Is it ok to read and write it unconditionally ?
>> Yes, refer to dwc3 databook, the DWC3_GUCTL1 was introduced since 2.50a.
>> Maybe it's better
>> to read and write it only when we know our controller version.
>>
>> Is it good to fix it like the following patch?
>> But this patch has a problem that we need to read and write the register
>> twice if our controller verison > = 2.90a, and need this quirk.
>>
>> --- a/drivers/usb/dwc3/core.c
>> +++ b/drivers/usb/dwc3/core.c
>> @@ -806,6 +806,12 @@ static int dwc3_core_init(struct dwc3 *dwc)
>> dwc3_writel(dwc->regs, DWC3_GUCTL1, reg);
>> }
>>
>> + if (dwc->dis_tx_ipgap_linecheck_quirk) {
>> + reg = dwc3_readl(dwc->regs, DWC3_GUCTL1);
>> + reg |= DWC3_GUCTL1_TX_IPGAP_LINECHECK_DIS;
>> + dwc3_writel(dwc->regs, DWC3_GUCTL1, reg);
>> + }
>> +
>>
> How about this ?
>
> if (dwc->revision >= DWC3_REVISION_250A) {
> reg = dwc3_readl(dwc->regs, DWC3_GUCTL1);
> if (dwc->revision >= DWC3_REVISION_290A)
> reg |= DWC3_GUCTL1_DEV_L1_EXIT_BY_HW;
> if (dwc->dis_tx_ipgap_linecheck_quirk)
> reg |= DWC3_GUCTL1_TX_IPGAP_LINECHECK_DIS;
> dwc3_writel(dwc->regs, DWC3_GUCTL1, reg);
> }
>
> Thanks,
> Guenter
Thanks， looks good to me. I will fix it in patch v2.
>
>> Hi John & Felipe,
>> Could you provide me some suggestion？
>> Thank you！
>>
>>>> /*
>>>> * Enable hardware control of sending remote wakeup in HS when
>>>> * the device is in the L1 state.
>>>> */
>>>> - if (dwc->revision >= DWC3_REVISION_290A) {
>>>> - reg = dwc3_readl(dwc->regs, DWC3_GUCTL1);
>>>> + if (dwc->revision >= DWC3_REVISION_290A)
>>>> reg |= DWC3_GUCTL1_DEV_L1_EXIT_BY_HW;
>>>> - dwc3_writel(dwc->regs, DWC3_GUCTL1, reg);
>>>> - }
>>>> +
>>>> + if (dwc->tx_ipgap_linecheck_dis_quirk)
>>>> + reg |= DWC3_GUCTL1_TX_IPGAP_LINECHECK_DIS;
>>>> +
>>>> + dwc3_writel(dwc->regs, DWC3_GUCTL1, reg);
>>>>
>>>> return 0;
>>>>
>>>> @@ -1023,6 +1027,8 @@ static void dwc3_get_properties(struct dwc3 *dwc)
>>>> "snps,dis-u2-freeclk-exists-quirk");
>>>> dwc->dis_del_phy_power_chg_quirk =
>>>> device_property_read_bool(dev,
>>>> "snps,dis-del-phy-power-chg-quirk");
>>>> + dwc->tx_ipgap_linecheck_dis_quirk =
>>>> device_property_read_bool(dev,
>>>> + "snps,tx-ipgap-linecheck-dis-quirk");
>>>>
>>>> dwc->tx_de_emphasis_quirk = device_property_read_bool(dev,
>>>> "snps,tx_de_emphasis_quirk");
>>>> diff --git a/drivers/usb/dwc3/core.h b/drivers/usb/dwc3/core.h
>>>> index 981c77f..3c2537b 100644
>>>> --- a/drivers/usb/dwc3/core.h
>>>> +++ b/drivers/usb/dwc3/core.h
>>>> @@ -204,6 +204,7 @@
>>>> #define DWC3_GCTL_DSBLCLKGTNG BIT(0)
>>>>
>>>> /* Global User Control 1 Register */
>>>> +#define DWC3_GUCTL1_TX_IPGAP_LINECHECK_DIS BIT(28)
>>>> #define DWC3_GUCTL1_DEV_L1_EXIT_BY_HW BIT(24)
>>>>
>>>> /* Global USB2 PHY Configuration Register */
>>>> @@ -850,6 +851,8 @@ struct dwc3_scratchpad_array {
>>>> * provide a free-running PHY clock.
>>>> * @dis_del_phy_power_chg_quirk: set if we disable delay phy power
>>>> * change quirk.
>>>> + * @tx_ipgap_linecheck_dis_quirk: set if we disable u2mac linestate
>>>> + * check during HS transmit.
>>>> * @tx_de_emphasis_quirk: set if we enable Tx de-emphasis quirk
>>>> * @tx_de_emphasis: Tx de-emphasis value
>>>> * 0 - -6dB de-emphasis
>>>> @@ -1004,6 +1007,7 @@ struct dwc3 {
>>>> unsigned dis_rxdet_inp3_quirk:1;
>>>> unsigned dis_u2_freeclk_exists_quirk:1;
>>>> unsigned dis_del_phy_power_chg_quirk:1;
>>>> + unsigned tx_ipgap_linecheck_dis_quirk:1;
>>>>
>>>> unsigned tx_de_emphasis_quirk:1;
>>>> unsigned tx_de_emphasis:2;
>>>> --
>>>> 2.0.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: [RFC 1/2] dt-bindings: add mmio-based syscon mux controller DT bindings
From: Philipp Zabel @ 2017-04-19 11:47 UTC (permalink / raw)
To: Steve Longerbeam
Cc: Peter Rosin, Rob Herring, Mark Rutland, Sakari Ailus,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
kernel-bIcnvbaLZ9MEGnE8C9+IrQ
In-Reply-To: <d6d32063-5df3-3848-32f5-824c500a8927-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
On Thu, 2017-04-13 at 18:03 -0700, Steve Longerbeam wrote:
>
> On 04/13/2017 08:48 AM, Philipp Zabel wrote:
> > This adds device tree binding documentation for mmio-based syscon
> > multiplexers controlled by a single bitfield in a syscon register
> > range.
>
> Nice! (you beat me to it, I was about to embark on this myself :)
>
> Looks good to me, just some minor comments below.
>
[...]
> > +Define a syscon bitfield to be used to control a multiplexer. The parent
> I think "Define a register bitfield to be used ..." is more clear.
[...]
> > +- compatible : "gpio-mux"
> Er, "mmio-mux"
I'll change those, thanks.
[...]
> > +Example:
> > +
> > + syscon {
> > + compatible = "syscon";
> > +
> > + mux: mux-controller@3 {
> > + compatible = "mmio-mux";
> > + reg = <0x3>;
> > + bit-mask = <0x1>;
> > + bit-shift = <5>;
> > + #mux-control-cells = <0>;
> > + };
> > + };
> > +
> > + video-mux {
>
> I like this as an example consumer of a mmio-mux, but just
> the same some might argue this doesn't really fit here.
I don't think this is a problem, of course assuming that this video-mux
binding will actually come into existence.
regards
Philipp
--
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 1/9] PM / OPP: Allow OPP table to be used for power-domains
From: Viresh Kumar @ 2017-04-19 11:47 UTC (permalink / raw)
To: Sudeep Holla
Cc: Rafael Wysocki, ulf.hansson, Kevin Hilman, Viresh Kumar,
Nishanth Menon, Stephen Boyd, linaro-kernel, linux-pm,
linux-kernel, Vincent Guittot, robh+dt, lina.iyer, rnayak,
devicetree
In-Reply-To: <95aa4b97-4e1a-13bb-f4d8-982b778012ba@arm.com>
On 18-04-17, 17:01, Sudeep Holla wrote:
> Understood. I would incline towards reusing regulators we that's what is
It can be just a regulator, but it can be anything else as well. That
entity may have its own clock/volt/current tunables, etc.
> changed behind the scene. Calling this operating performance point
> is misleading and doesn't align well with existing specs/features.
Yeah, but there are no voltage levels available here and that doesn't
fit as a regulator then.
> Understood. We have exactly same thing with SCPI but it controls both
> frequency and voltage referred as operating points. In general, this OPP
> terminology is used in SCPI/ACPI/SCMI specifications as both frequency
> and voltage control. I am bit worried that this binding might introduce
> confusions on the definitions. But it can be reworded/renamed easily if
> required.
Yeah, so far we have been looking at OPPs as freq-voltage pairs ONLY
and that is changing. I am not sure if it going in the wrong
direction really. Without frequency also it is an operating point for
the domain. Isn't it?
--
viresh
^ permalink raw reply
* Re: [RFC 2/2] mux: mmio-based syscon mux controller
From: Philipp Zabel @ 2017-04-19 11:50 UTC (permalink / raw)
To: Steve Longerbeam
Cc: Peter Rosin, Rob Herring, Mark Rutland, Sakari Ailus,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
kernel-bIcnvbaLZ9MEGnE8C9+IrQ
In-Reply-To: <58fd5844-f24a-37cc-be81-26a716251860-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
On Thu, 2017-04-13 at 18:09 -0700, Steve Longerbeam wrote:
>
> On 04/13/2017 08:48 AM, Philipp Zabel wrote:
> > This adds a driver for mmio-based syscon multiplexers controlled by a
> > single bitfield in a syscon register range.
> >
> > Signed-off-by: Philipp Zabel <p.zabel-bIcnvbaLZ9MEGnE8C9+IrQ@public.gmane.org>
> > ---
> > drivers/mux/Kconfig | 13 +++++
> > drivers/mux/Makefile | 1 +
> > drivers/mux/mux-syscon.c | 130 +++++++++++++++++++++++++++++++++++++++++++++++
> > 3 files changed, 144 insertions(+)
> > create mode 100644 drivers/mux/mux-syscon.c
> >
> > diff --git a/drivers/mux/Kconfig b/drivers/mux/Kconfig
> > index 86668b4d2fc52..a5e6a3b01ac24 100644
> > --- a/drivers/mux/Kconfig
> > +++ b/drivers/mux/Kconfig
> > @@ -43,4 +43,17 @@ config MUX_GPIO
> > To compile the driver as a module, choose M here: the module will
> > be called mux-gpio.
> >
> > +config MUX_SYSCON
>
> my preference would be CONFIG_MUX_MMIO.
>
> > + tristate "MMIO bitfield-controlled Multiplexer"
>
> "MMIO register bitfield-controlled Multiplexer"
>
> The rest looks good to me.
I'll change those. mux-syscon.c should probably be renamed to
mux-mmio.c, too.
regards
Philipp
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [RFC 2/2] mux: mmio-based syscon mux controller
From: Peter Rosin @ 2017-04-19 11:58 UTC (permalink / raw)
To: Philipp Zabel, Steve Longerbeam
Cc: Rob Herring, Mark Rutland, Sakari Ailus,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
kernel-bIcnvbaLZ9MEGnE8C9+IrQ
In-Reply-To: <1492602613.2970.92.camel-bIcnvbaLZ9MEGnE8C9+IrQ@public.gmane.org>
On 2017-04-19 13:50, Philipp Zabel wrote:
> On Thu, 2017-04-13 at 18:09 -0700, Steve Longerbeam wrote:
>>
>> On 04/13/2017 08:48 AM, Philipp Zabel wrote:
>>> This adds a driver for mmio-based syscon multiplexers controlled by a
>>> single bitfield in a syscon register range.
>>>
>>> Signed-off-by: Philipp Zabel <p.zabel-bIcnvbaLZ9MEGnE8C9+IrQ@public.gmane.org>
>>> ---
>>> drivers/mux/Kconfig | 13 +++++
>>> drivers/mux/Makefile | 1 +
>>> drivers/mux/mux-syscon.c | 130 +++++++++++++++++++++++++++++++++++++++++++++++
>>> 3 files changed, 144 insertions(+)
>>> create mode 100644 drivers/mux/mux-syscon.c
>>>
>>> diff --git a/drivers/mux/Kconfig b/drivers/mux/Kconfig
>>> index 86668b4d2fc52..a5e6a3b01ac24 100644
>>> --- a/drivers/mux/Kconfig
>>> +++ b/drivers/mux/Kconfig
>>> @@ -43,4 +43,17 @@ config MUX_GPIO
>>> To compile the driver as a module, choose M here: the module will
>>> be called mux-gpio.
>>>
>>> +config MUX_SYSCON
>>
>> my preference would be CONFIG_MUX_MMIO.
>>
>>> + tristate "MMIO bitfield-controlled Multiplexer"
>>
>> "MMIO register bitfield-controlled Multiplexer"
>>
>> The rest looks good to me.
>
> I'll change those. mux-syscon.c should probably be renamed to
> mux-mmio.c, too.
I think I disagree. But I'm not familiar with syscon so I don't know.
IIUC, syscon uses regmap to do mmio and this driver requires syscon
to get at the regmap, and in the end this driver doesn't know anything
about mmio. All it knows is syscon/regmap. If some warped syscon
thing shows up that wraps something other than mmio in its regmap,
this driver wouldn't care about it. And syscon is something that
is also known in the DT world. Given that, I think everything in this
driver should be named syscon and not mmio.
Or?
Cheers,
peda
--
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 v13 03/10] mux: minimal mux subsystem and gpio-based mux controller
From: Peter Rosin @ 2017-04-19 12:00 UTC (permalink / raw)
To: Philipp Zabel
Cc: linux-kernel-u79uwXL29TY76Z2rM5mHXA, Greg Kroah-Hartman,
Wolfram Sang, Rob Herring, Mark Rutland, Jonathan Cameron,
Hartmut Knaack, Lars-Peter Clausen, Peter Meerwald-Stadler,
Jonathan Corbet, linux-i2c-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-iio-u79uwXL29TY76Z2rM5mHXA,
linux-doc-u79uwXL29TY76Z2rM5mHXA, Andrew Morton, Colin Ian King,
Paul Gortmaker, kernel-bIcnvbaLZ9MEGnE8C9+IrQ
In-Reply-To: <1492592817.2970.14.camel-bIcnvbaLZ9MEGnE8C9+IrQ@public.gmane.org>
On 2017-04-19 11:06, Philipp Zabel wrote:
> On Thu, 2017-04-13 at 18:43 +0200, Peter Rosin wrote:
>> Add a new minimalistic subsystem that handles multiplexer controllers.
>> When multiplexers are used in various places in the kernel, and the
>> same multiplexer controller can be used for several independent things,
>> there should be one place to implement support for said multiplexer
>> controller.
>>
>> A single multiplexer controller can also be used to control several
>> parallel multiplexers, that are in turn used by different subsystems
>> in the kernel, leading to a need to coordinate multiplexer accesses.
>> The multiplexer subsystem handles this coordination.
>>
>> This new mux controller subsystem initially comes with a single backend
>> driver that controls gpio based multiplexers. Even though not needed by
>> this initial driver, the mux controller subsystem is prepared to handle
>> chips with multiple (independent) mux controllers.
>>
>> Reviewed-by: Jonathan Cameron <jic23-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
>> Signed-off-by: Peter Rosin <peda-koto5C5qi+TLoDKTGw+V6w@public.gmane.org>
>> ---
*snip*
>> +int mux_control_select(struct mux_control *mux, int state)
>
> If we let two of these race, ...
The window for this "race" is positively huge. If there are several
mux consumers of a single mux controller, it is self-evident that
if one of them grabs the mux for a long time, the others will suffer.
The design is that the rwsem is reader-locked for the full duration
of a select/deselect operation by the mux consumer.
>> +{
>> + int ret;
>> +
>> + if (down_read_trylock(&mux->lock)) {
>> + if (mux->cached_state == state)
>> + return 0;
>> + /* Sigh, the mux needs updating... */
>> + up_read(&mux->lock);
>
> ... and both decide the mux needs updating ...
>
>> + }
>> +
>> + /* ...or it's just contended. */
>> + down_write(&mux->lock);
>
> ... then the last to get to down_write will just wait here forever (or
> until the first consumer calls mux_control_deselect, which may never
> happen)?
It is vital that the mux consumer call _deselect when it is done with
the mux. Not doing so will surely starve out any other mux consumers.
The whole thing is designed around the fact that mux consumers should
deselect the mux as soon as it's no longer needed.
It's simply not possible to share something as fundamental as a mux
without some cooperation. It's not like suffering mux consumers can
go off and use some other mux, and it's also not possible for a
"competing" mux consumer to just clobber the mux state.
>> +
>> + if (mux->cached_state == state) {
>> + /*
>> + * Hmmm, someone else changed the mux to my liking.
>> + * That makes me wonder how long I waited for nothing?
>> + */
>> + downgrade_write(&mux->lock);
>> + return 0;
>> + }
>> +
>> + ret = mux_control_set(mux, state);
>> + if (ret < 0) {
>> + if (mux->idle_state != MUX_IDLE_AS_IS)
>> + mux_control_set(mux, mux->idle_state);
>> +
>> + up_write(&mux->lock);
>> + return ret;
>> + }
>> +
>> + downgrade_write(&mux->lock);
>> +
>> + return 1;
>> +}
>> +EXPORT_SYMBOL_GPL(mux_control_select);
>
> I wonder if these should be called mux_control_lock/unlock instead,
> which would allow for try_lock and lock_timeout variants.
Maybe, I'm not totally against it. Do others care to opine?
But mux_control_try_select and mux_control_select_timeout does not
look all that bad either. But maybe foo_lock is making it clearer
that a foo_unlock is needed, if you compared it to foo_select and
foo_unselect? I'm probably not the best person to make the call,
as I know all to well what to expect from the functions...
Cheers,
peda
--
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 V5 1/4] arm64: dts: Add basic DT to support Spreadtrum's SP9860G
From: Lyra Zhang @ 2017-04-19 12:09 UTC (permalink / raw)
To: Arnd Bergmann, arm@kernel.org
Cc: robh+dt@kernel.org, Mark Rutland, gregkh@linuxfoundation.org,
Catalin Marinas, Will Deacon, Mathieu Poirier,
Orson Zhai (翟京), linux-kernel@vger.kernel.org,
devicetree@vger.kernel.org, linux-arm-kernel@lists.infradead.org,
Chunyan Zhang
In-Reply-To: <CAAfSe-s-Jbvin0GV6F6W8OM5zp3kSzHO0YLTM3Gt_Qxv_vA6ag@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 20179 bytes --]
Hi Arnd, Olof, Could you please take this patch through arm-soc git if there are no further comments? (The three other patches in this series have been taken by Greg.) Thanks, Chunyan On 27 March 2017 at 15:32, Chunyan Zhang <chunyan.zhang@spreadtrum.com> wrote: > From: Orson Zhai <orson.zhai@spreadtrum.com> > > SC9860G is a 8 cores of A53 SoC with 4G LTE support SoC from Spreadtrum. > > According to regular hierarchy of sprd dts, whale2.dtsi contains SoC > peripherals IP nodes, sc9860.dtsi contains stuff related to ARM core stuff > and sp9860g dts is for the board level. > > Signed-off-by: Orson Zhai <orson.zhai@spreadtrum.com> > Signed-off-by: Chunyan Zhang <chunyan.zhang@spreadtrum.com> > Reviewed-by: Mathieu Poirier <mathieu.poirier@linaro.org> > --- > arch/arm64/boot/dts/sprd/Makefile | 3 +- > arch/arm64/boot/dts/sprd/sc9860.dtsi | 569 ++++++++++++++++++++++++++++++ > arch/arm64/boot/dts/sprd/sp9860g-1h10.dts | 56 +++ > arch/arm64/boot/dts/sprd/whale2.dtsi | 71 ++++ > 4 files changed, 698 insertions(+), 1 deletion(-) > create mode 100644 arch/arm64/boot/dts/sprd/sc9860.dtsi > create mode 100644 arch/arm64/boot/dts/sprd/sp9860g-1h10.dts > create mode 100644 arch/arm64/boot/dts/sprd/whale2.dtsi > > diff --git a/arch/arm64/boot/dts/sprd/Makefile b/arch/arm64/boot/dts/sprd/Makefile > index b658c5e..f0535e6 100644 > --- a/arch/arm64/boot/dts/sprd/Makefile > +++ b/arch/arm64/boot/dts/sprd/Makefile > @@ -1,4 +1,5 @@ > -dtb-$(CONFIG_ARCH_SPRD) += sc9836-openphone.dtb > +dtb-$(CONFIG_ARCH_SPRD) += sc9836-openphone.dtb \ > + sp9860g-1h10.dtb > > always := $(dtb-y) > subdir-y := $(dts-dirs) > diff --git a/arch/arm64/boot/dts/sprd/sc9860.dtsi b/arch/arm64/boot/dts/sprd/sc9860.dtsi > new file mode 100644 > index 0000000..7b7d8ce > --- /dev/null > +++ b/arch/arm64/boot/dts/sprd/sc9860.dtsi > @@ -0,0 +1,569 @@ > +/* > + * Spreadtrum SC9860 SoC > + * > + * Copyright (C) 2016, Spreadtrum Communications Inc. > + * > + * SPDX-License-Identifier: (GPL-2.0+ OR MIT) > + */ > + > +#include <dt-bindings/interrupt-controller/arm-gic.h> > +#include "whale2.dtsi" > + > +/ { > + cpus { > + #address-cells = <2>; > + #size-cells = <0>; > + > + cpu-map { > + cluster0 { > + core0 { > + cpu = <&CPU0>; > + }; > + core1 { > + cpu = <&CPU1>; > + }; > + core2 { > + cpu = <&CPU2>; > + }; > + core3 { > + cpu = <&CPU3>; > + }; > + }; > + > + cluster1 { > + core0 { > + cpu = <&CPU4>; > + }; > + core1 { > + cpu = <&CPU5>; > + }; > + core2 { > + cpu = <&CPU6>; > + }; > + core3 { > + cpu = <&CPU7>; > + }; > + }; > + }; > + > + CPU0: cpu@530000 { > + device_type = "cpu"; > + compatible = "arm,cortex-a53", "arm,armv8"; > + reg = <0x0 0x530000>; > + enable-method = "psci"; > + cpu-idle-states = <&CORE_PD &CLUSTER_PD>; > + }; > + > + CPU1: cpu@530001 { > + device_type = "cpu"; > + compatible = "arm,cortex-a53", "arm,armv8"; > + reg = <0x0 0x530001>; > + enable-method = "psci"; > + cpu-idle-states = <&CORE_PD &CLUSTER_PD>; > + }; > + > + CPU2: cpu@530002 { > + device_type = "cpu"; > + compatible = "arm,cortex-a53", "arm,armv8"; > + reg = <0x0 0x530002>; > + enable-method = "psci"; > + cpu-idle-states = <&CORE_PD &CLUSTER_PD>; > + }; > + > + CPU3: cpu@530003 { > + device_type = "cpu"; > + compatible = "arm,cortex-a53", "arm,armv8"; > + reg = <0x0 0x530003>; > + enable-method = "psci"; > + cpu-idle-states = <&CORE_PD &CLUSTER_PD>; > + }; > + > + CPU4: cpu@530100 { > + device_type = "cpu"; > + compatible = "arm,cortex-a53", "arm,armv8"; > + reg = <0x0 0x530100>; > + enable-method = "psci"; > + cpu-idle-states = <&CORE_PD &CLUSTER_PD>; > + }; > + > + CPU5: cpu@530101 { > + device_type = "cpu"; > + compatible = "arm,cortex-a53", "arm,armv8"; > + reg = <0x0 0x530101>; > + enable-method = "psci"; > + cpu-idle-states = <&CORE_PD &CLUSTER_PD>; > + }; > + > + CPU6: cpu@530102 { > + device_type = "cpu"; > + compatible = "arm,cortex-a53", "arm,armv8"; > + reg = <0x0 0x530102>; > + enable-method = "psci"; > + cpu-idle-states = <&CORE_PD &CLUSTER_PD>; > + }; > + > + CPU7: cpu@530103 { > + device_type = "cpu"; > + compatible = "arm,cortex-a53", "arm,armv8"; > + reg = <0x0 0x530103>; > + enable-method = "psci"; > + cpu-idle-states = <&CORE_PD &CLUSTER_PD>; > + }; > + }; > + > + idle-states{ > + entry-method = "arm,psci"; > + > + CORE_PD: core_pd { > + compatible = "arm,idle-state"; > + entry-latency-us = <1000>; > + exit-latency-us = <700>; > + min-residency-us = <2500>; > + local-timer-stop; > + arm,psci-suspend-param = <0x00010002>; > + }; > + > + CLUSTER_PD: cluster_pd { > + compatible = "arm,idle-state"; > + entry-latency-us = <1000>; > + exit-latency-us = <1000>; > + min-residency-us = <3000>; > + local-timer-stop; > + arm,psci-suspend-param = <0x01010003>; > + }; > + }; > + > + gic: interrupt-controller@12001000 { > + compatible = "arm,gic-400"; > + reg = <0 0x12001000 0 0x1000>, > + <0 0x12002000 0 0x2000>, > + <0 0x12004000 0 0x2000>, > + <0 0x12006000 0 0x2000>; > + #interrupt-cells = <3>; > + interrupt-controller; > + interrupts = <GIC_PPI 9 (GIC_CPU_MASK_SIMPLE(8) > + | IRQ_TYPE_LEVEL_HIGH)>; > + }; > + > + psci { > + compatible = "arm,psci-0.2"; > + method = "smc"; > + }; > + > + timer { > + compatible = "arm,armv8-timer"; > + interrupts = <GIC_PPI 13 (GIC_CPU_MASK_SIMPLE(8) > + | IRQ_TYPE_LEVEL_LOW)>, > + <GIC_PPI 14 (GIC_CPU_MASK_SIMPLE(8) > + | IRQ_TYPE_LEVEL_LOW)>, > + <GIC_PPI 11 (GIC_CPU_MASK_SIMPLE(8) > + | IRQ_TYPE_LEVEL_LOW)>, > + <GIC_PPI 10 (GIC_CPU_MASK_SIMPLE(8) > + | IRQ_TYPE_LEVEL_LOW)>; > + }; > + > + pmu { > + compatible = "arm,cortex-a53-pmu", "arm,armv8-pmuv3"; > + interrupts = <GIC_SPI 122 IRQ_TYPE_LEVEL_HIGH>, > + <GIC_SPI 123 IRQ_TYPE_LEVEL_HIGH>, > + <GIC_SPI 124 IRQ_TYPE_LEVEL_HIGH>, > + <GIC_SPI 125 IRQ_TYPE_LEVEL_HIGH>, > + <GIC_SPI 154 IRQ_TYPE_LEVEL_HIGH>, > + <GIC_SPI 155 IRQ_TYPE_LEVEL_HIGH>, > + <GIC_SPI 156 IRQ_TYPE_LEVEL_HIGH>, > + <GIC_SPI 157 IRQ_TYPE_LEVEL_HIGH>; > + interrupt-affinity = <&CPU0>, > + <&CPU1>, > + <&CPU2>, > + <&CPU3>, > + <&CPU4>, > + <&CPU5>, > + <&CPU6>, > + <&CPU7>; > + }; > + > + soc { > + funnel@10001000 { /* SoC Funnel */ > + compatible = "arm,coresight-funnel", "arm,primecell"; > + reg = <0 0x10001000 0 0x1000>; > + clocks = <&ext_26m>; > + clock-names = "apb_pclk"; > + ports { > + #address-cells = <1>; > + #size-cells = <0>; > + > + port@0 { > + reg = <0>; > + soc_funnel_out_port: endpoint { > + remote-endpoint = <&etb_in>; > + }; > + }; > + > + port@1 { > + reg = <0>; > + soc_funnel_in_port0: endpoint { > + slave-mode; > + remote-endpoint = > + <&main_funnel_out_port>; > + }; > + }; > + > + port@2 { > + reg = <4>; > + soc_funnel_in_port1: endpoint { > + slave-mode; > + remote-endpioint = > + <&stm_out_port>; > + }; > + }; > + }; > + }; > + > + etb@10003000 { > + compatible = "arm,coresight-tmc", "arm,primecell"; > + reg = <0 0x10003000 0 0x1000>; > + clocks = <&ext_26m>; > + clock-names = "apb_pclk"; > + port { > + etb_in: endpoint { > + slave-mode; > + remote-endpoint = > + <&soc_funnel_out_port>; > + }; > + }; > + }; > + > + stm@10006000 { > + compatible = "arm,coresight-stm", "arm,primecell"; > + reg = <0 0x10006000 0 0x1000>, > + <0 0x01000000 0 0x180000>; > + reg-names = "stm-base", "stm-stimulus-base"; > + clocks = <&ext_26m>; > + clock-names = "apb_pclk"; > + port { > + stm_out_port: endpoint { > + remote-endpoint = > + <&soc_funnel_in_port1>; > + }; > + }; > + }; > + > + funnel@11001000 { /* Cluster0 Funnel */ > + compatible = "arm,coresight-funnel", "arm,primecell"; > + reg = <0 0x11001000 0 0x1000>; > + clocks = <&ext_26m>; > + clock-names = "apb_pclk"; > + ports { > + #address-cells = <1>; > + #size-cells = <0>; > + > + port@0 { > + reg = <0>; > + cluster0_funnel_out_port: endpoint { > + remote-endpoint = > + <&cluster0_etf_in>; > + }; > + }; > + > + port@1 { > + reg = <0>; > + cluster0_funnel_in_port0: endpoint { > + slave-mode; > + remote-endpoint = <&etm0_out>; > + }; > + }; > + > + port@2 { > + reg = <1>; > + cluster0_funnel_in_port1: endpoint { > + slave-mode; > + remote-endpoint = <&etm1_out>; > + }; > + }; > + > + port@3 { > + reg = <2>; > + cluster0_funnel_in_port2: endpoint { > + slave-mode; > + remote-endpoint = <&etm2_out>; > + }; > + }; > + > + port@4 { > + reg = <4>; > + cluster0_funnel_in_port3: endpoint { > + slave-mode; > + remote-endpoint = <&etm3_out>; > + }; > + }; > + }; > + }; > + > + funnel@11002000 { /* Cluster1 Funnel */ > + compatible = "arm,coresight-funnel", "arm,primecell"; > + reg = <0 0x11002000 0 0x1000>; > + clocks = <&ext_26m>; > + clock-names = "apb_pclk"; > + ports { > + #address-cells = <1>; > + #size-cells = <0>; > + > + port@0 { > + reg = <0>; > + cluster1_funnel_out_port: endpoint { > + remote-endpoint = > + <&cluster1_etf_in>; > + }; > + }; > + > + port@1 { > + reg = <0>; > + cluster1_funnel_in_port0: endpoint { > + slave-mode; > + remote-endpoint = <&etm4_out>; > + }; > + }; > + > + port@2 { > +
[-- Attachment #2: Type: text/html, Size: 48164 bytes --]
^ permalink raw reply
* [PATCH v3] usb: dwc3: add disable u2mac linestate check quirk
From: William Wu @ 2017-04-19 12:11 UTC (permalink / raw)
To: balbi-DgEjT+Ai2ygdnm+yROfE0A,
gregkh-hQyY1W1yCW8ekmWlsbkhG0B+6BGkLq7r
Cc: huangtao-TNX95d0MmH7DzftRWevZcw,
devicetree-u79uwXL29TY76Z2rM5mHXA, heiko-4mtYJXux2i+zQB+pC5nmwQ,
groeck-hpIqsD4AKlfQT0dZR+AlfA, frank.wang-TNX95d0MmH7DzftRWevZcw,
linux-usb-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
dianders-hpIqsD4AKlfQT0dZR+AlfA,
linux-rockchip-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
robh+dt-DgEjT+Ai2ygdnm+yROfE0A, william.wu-TNX95d0MmH7DzftRWevZcw,
briannorris-hpIqsD4AKlfQT0dZR+AlfA,
John.Youn-HKixBCOQz3hWk0Htik3J/w,
daniel.meng-TNX95d0MmH7DzftRWevZcw
This patch adds a quirk to disable USB 2.0 MAC linestate check
during HS transmit. Refer the dwc3 databook, we can use it for
some special platforms if the linestate not reflect the expected
line state(J) during transmission.
When use this quirk, the controller implements a fixed 40-bit
TxEndDelay after the packet is given on UTMI and ignores the
linestate during the transmit of a token (during token-to-token
and token-to-data IPGAP).
On some rockchip platforms (e.g. rk3399), it requires to disable
the u2mac linestate check to decrease the SSPLIT token to SETUP
token inter-packet delay from 566ns to 466ns, and fix the issue
that FS/LS devices not recognized if inserted through USB 3.0 HUB.
Signed-off-by: William Wu <william.wu-TNX95d0MmH7DzftRWevZcw@public.gmane.org>
---
Changes in v3:
- change quirk name
- only read and write GUCTL1 if dwc3 version >= 2.50a
Changes in v2:
- fix coding style
Documentation/devicetree/bindings/usb/dwc3.txt | 2 ++
drivers/usb/dwc3/core.c | 20 ++++++++++++++------
drivers/usb/dwc3/core.h | 4 ++++
3 files changed, 20 insertions(+), 6 deletions(-)
diff --git a/Documentation/devicetree/bindings/usb/dwc3.txt b/Documentation/devicetree/bindings/usb/dwc3.txt
index f658f39..52fb410 100644
--- a/Documentation/devicetree/bindings/usb/dwc3.txt
+++ b/Documentation/devicetree/bindings/usb/dwc3.txt
@@ -45,6 +45,8 @@ Optional properties:
a free-running PHY clock.
- snps,dis-del-phy-power-chg-quirk: when set core will change PHY power
from P0 to P1/P2/P3 without delay.
+ - snps,dis-tx-ipgap-linecheck-quirk: when set, disable u2mac linestate check
+ during HS transmit.
- snps,is-utmi-l1-suspend: true when DWC3 asserts output signal
utmi_l1_suspend_n, false when asserts utmi_sleep_n
- snps,hird-threshold: HIRD threshold
diff --git a/drivers/usb/dwc3/core.c b/drivers/usb/dwc3/core.c
index 455d89a..9d5a67c 100644
--- a/drivers/usb/dwc3/core.c
+++ b/drivers/usb/dwc3/core.c
@@ -796,13 +796,19 @@ static int dwc3_core_init(struct dwc3 *dwc)
dwc3_writel(dwc->regs, DWC3_GUCTL2, reg);
}
- /*
- * Enable hardware control of sending remote wakeup in HS when
- * the device is in the L1 state.
- */
- if (dwc->revision >= DWC3_REVISION_290A) {
+ if (dwc->revision >= DWC3_REVISION_250A) {
reg = dwc3_readl(dwc->regs, DWC3_GUCTL1);
- reg |= DWC3_GUCTL1_DEV_L1_EXIT_BY_HW;
+
+ /*
+ * Enable hardware control of sending remote wakeup
+ * in HS when the device is in the L1 state.
+ */
+ if (dwc->revision >= DWC3_REVISION_290A)
+ reg |= DWC3_GUCTL1_DEV_L1_EXIT_BY_HW;
+
+ if (dwc->dis_tx_ipgap_linecheck_quirk)
+ reg |= DWC3_GUCTL1_TX_IPGAP_LINECHECK_DIS;
+
dwc3_writel(dwc->regs, DWC3_GUCTL1, reg);
}
@@ -1023,6 +1029,8 @@ static void dwc3_get_properties(struct dwc3 *dwc)
"snps,dis-u2-freeclk-exists-quirk");
dwc->dis_del_phy_power_chg_quirk = device_property_read_bool(dev,
"snps,dis-del-phy-power-chg-quirk");
+ dwc->dis_tx_ipgap_linecheck_quirk = device_property_read_bool(dev,
+ "snps,dis-tx-ipgap-linecheck-quirk");
dwc->tx_de_emphasis_quirk = device_property_read_bool(dev,
"snps,tx_de_emphasis_quirk");
diff --git a/drivers/usb/dwc3/core.h b/drivers/usb/dwc3/core.h
index 981c77f..6f6294d 100644
--- a/drivers/usb/dwc3/core.h
+++ b/drivers/usb/dwc3/core.h
@@ -204,6 +204,7 @@
#define DWC3_GCTL_DSBLCLKGTNG BIT(0)
/* Global User Control 1 Register */
+#define DWC3_GUCTL1_TX_IPGAP_LINECHECK_DIS BIT(28)
#define DWC3_GUCTL1_DEV_L1_EXIT_BY_HW BIT(24)
/* Global USB2 PHY Configuration Register */
@@ -850,6 +851,8 @@ struct dwc3_scratchpad_array {
* provide a free-running PHY clock.
* @dis_del_phy_power_chg_quirk: set if we disable delay phy power
* change quirk.
+ * @dis_tx_ipgap_linecheck_quirk: set if we disable u2mac linestate
+ * check during HS transmit.
* @tx_de_emphasis_quirk: set if we enable Tx de-emphasis quirk
* @tx_de_emphasis: Tx de-emphasis value
* 0 - -6dB de-emphasis
@@ -1004,6 +1007,7 @@ struct dwc3 {
unsigned dis_rxdet_inp3_quirk:1;
unsigned dis_u2_freeclk_exists_quirk:1;
unsigned dis_del_phy_power_chg_quirk:1;
+ unsigned dis_tx_ipgap_linecheck_quirk:1;
unsigned tx_de_emphasis_quirk:1;
unsigned tx_de_emphasis:2;
--
2.0.0
^ permalink raw reply related
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