* [PATCH 2/5 v2] clk: qcom: Elaborate on "active" clocks in the RPM clock bindings
From: Linus Walleij @ 2017-04-19 9:13 UTC (permalink / raw)
To: Michael Turquette, Stephen Boyd
Cc: linux-clk, linux-arm-msm, Linus Walleij, devicetree
In-Reply-To: <20170419091326.11226-1-linus.walleij@linaro.org>
The concept of "active" clocks is just explained in a bried comment in the
device driver, let's explain it a bit more in the device tree bindings
so everyone understands this.
Cc: devicetree@vger.kernel.org
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
---
ChangeLog v1->v2:
- Reword slighty in accordance with Stephens feedback.
---
Documentation/devicetree/bindings/clock/qcom,rpmcc.txt | 8 ++++++++
1 file changed, 8 insertions(+)
diff --git a/Documentation/devicetree/bindings/clock/qcom,rpmcc.txt b/Documentation/devicetree/bindings/clock/qcom,rpmcc.txt
index d470a0187035..833a89f06ae0 100644
--- a/Documentation/devicetree/bindings/clock/qcom,rpmcc.txt
+++ b/Documentation/devicetree/bindings/clock/qcom,rpmcc.txt
@@ -18,6 +18,14 @@ Required properties :
- #clock-cells : shall contain 1
+The clock enumerators are defined in <dt-bindings/clock/qcom,rpmcc.h>
+and come in pairs: FOO_CLK followed by FOO_A_CLK. The latter clock
+is an "active" clock, which means that the consumer only care that the
+clock is available when the apps CPU subsystem is active, i.e. not
+suspended or in deep idle. If it is important that the clock keeps running
+during system suspend, you need to specify the non-active clock, the one
+not containing *_A_* in the enumerator name.
+
Example:
smd {
compatible = "qcom,smd";
--
2.9.3
^ permalink raw reply related
* [PATCH 4/5 v2] clk: qcom: Update DT bindings for MSM8660 LCC
From: Linus Walleij @ 2017-04-19 9:13 UTC (permalink / raw)
To: Michael Turquette, Stephen Boyd
Cc: linux-clk, linux-arm-msm, Linus Walleij, devicetree
In-Reply-To: <20170419091326.11226-1-linus.walleij@linaro.org>
This adds the right compatible string and header for the
MSM8660 LCC and some new defines to the dt-bindings header.
Take this opportunity to spell out the acronym LPASS for
Low-power Audio Subsystem.
Cc: devicetree@vger.kernel.org
Acked-by: Rob Herring <robh@kernel.org>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
---
ChangeLog v1->v2:
- Add Rob's ACK.
---
.../devicetree/bindings/clock/qcom,lcc.txt | 5 +--
include/dt-bindings/clock/qcom,lcc-msm8660.h | 40 ++++++++++++++++++++++
2 files changed, 43 insertions(+), 2 deletions(-)
create mode 100644 include/dt-bindings/clock/qcom,lcc-msm8660.h
diff --git a/Documentation/devicetree/bindings/clock/qcom,lcc.txt b/Documentation/devicetree/bindings/clock/qcom,lcc.txt
index a3c78aa88038..4de51df37f1a 100644
--- a/Documentation/devicetree/bindings/clock/qcom,lcc.txt
+++ b/Documentation/devicetree/bindings/clock/qcom,lcc.txt
@@ -1,10 +1,11 @@
-Qualcomm LPASS Clock & Reset Controller Binding
-------------------------------------------------
+Qualcomm Low-power Audio Subsystem (LPASS) Clock & Reset Controller Binding
+---------------------------------------------------------------------------
Required properties :
- compatible : shall contain only one of the following:
"qcom,lcc-msm8960"
+ "qcom,lcc-msm8660"
"qcom,lcc-apq8064"
"qcom,lcc-ipq8064"
"qcom,lcc-mdm9615"
diff --git a/include/dt-bindings/clock/qcom,lcc-msm8660.h b/include/dt-bindings/clock/qcom,lcc-msm8660.h
new file mode 100644
index 000000000000..7cddcbd6b1ee
--- /dev/null
+++ b/include/dt-bindings/clock/qcom,lcc-msm8660.h
@@ -0,0 +1,40 @@
+/*
+ * Copyright (c) 2017 Linus Walleij <linus.walleij@linaro.org>
+ * Qualcomm MSM8660 Low-power Audio Subsystem (LPASS) Clock Controller
+ * devicetree definitions
+ */
+
+#ifndef _DT_BINDINGS_CLK_LCC_MSM8660_H
+#define _DT_BINDINGS_CLK_LCC_MSM8660_H
+
+#define LPA_PLL0 0
+#define MI2S_OSR_SRC 1
+#define MI2S_OSR_CLK 2
+#define MI2S_DIV_CLK 3
+#define MI2S_BIT_DIV_CLK 4
+#define MI2S_BIT_CLK 5
+#define CODEC_I2S_MIC_OSR_SRC 6
+#define CODEC_I2S_MIC_OSR_CLK 7
+#define CODEC_I2S_MIC_DIV_CLK 8
+#define CODEC_I2S_MIC_BIT_DIV_CLK 9
+#define CODEC_I2S_MIC_BIT_CLK 10
+#define SPARE_I2S_MIC_OSR_SRC 11
+#define SPARE_I2S_MIC_OSR_CLK 12
+#define SPARE_I2S_MIC_DIV_CLK 13
+#define SPARE_I2S_MIC_BIT_DIV_CLK 14
+#define SPARE_I2S_MIC_BIT_CLK 15
+#define CODEC_I2S_SPKR_OSR_SRC 16
+#define CODEC_I2S_SPKR_OSR_CLK 17
+#define CODEC_I2S_SPKR_DIV_CLK 18
+#define CODEC_I2S_SPKR_BIT_DIV_CLK 19
+#define CODEC_I2S_SPKR_BIT_CLK 20
+#define SPARE_I2S_SPKR_OSR_SRC 21
+#define SPARE_I2S_SPKR_OSR_CLK 22
+#define SPARE_I2S_SPKR_DIV_CLK 23
+#define SPARE_I2S_SPKR_BIT_DIV_CLK 24
+#define SPARE_I2S_SPKR_BIT_CLK 25
+#define PCM_SRC 26
+#define PCM_CLK_OUT 27
+#define PCM_CLK 28
+
+#endif
--
2.9.3
^ permalink raw reply related
* [PATCH 0/8] arm64: dts: renesas: Break out R-Car H3 and M3-W SiP
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
Hi all,
Renesas R-Car H3 and M3-W are available as SoC (r8a779[56]) or SiP
(r8j779[56]). The latter is an integrated package
("System-in-Package"), containing an SoC, RAM, and HyperFlash.
This patch series adds DT bindings for the SiPs, breaks out hardware
descriptions for the SiPs into separate .dtsi files, and migrates the
board-specific DTSes from the SoC-specific to the SiP-specific .dtsi
files.
The motivations for this are:
- Provide a better description of the hardware hierarchy,
- Share more DTS fragments (not that visible due to boilerplate and
limited number of boards),
- Some quirks may be SiP-specific.
I believe this is the case for the limitation of RAVB Ethernet to
10/100 Mbps on H3 ES1.0.
Questions (reiterated in the individual patches):
- Do we need more compatible values, for different configurations?
At least r8j7796 is available with either 2 GiB or 4 GiB of RAM,
possibly using RAM parts from different vendors.
- How are the different SiP versions named officially?
- How should the .dtsi files be named?
- Should the board-specific files be renamed from <soc>-<board>.dts to
<sip>-<board>.dts?
Probably not, as this would inconvenience downstream developers even
more than the H3 ES1.x rename, and <soc> is not that incorrect.
DTB changes have been inspected using scripts/dtc/dtx_diff.
This has been tested on Salvator-X (both H3 and M3-W).
Thanks for your comments!
Geert Uytterhoeven (8):
[RFC] dt-bindings: renesas: Document R-Car H3 and M3-W SiP DT bindings
[RFC] arm64: dts: renesas: Add R-Car H3 SiP (4 x 1 GiB) support
[RFC] arm64: dts: renesas: Add R-Car M3-W SiP (2 x 1 GiB) support
[RFC] arm64: dts: renesas: Add R-Car M3-W SiP (2 x 2 GiB) support
[RFC] arm64: dts: renesas: Migrate R-Car H3 Salvator-X to
r8j7795-4x1g.dtsi
[RFC] arm64: dts: renesas: Migrate R-Car M3-W Salvator-X to
r8j7796-2x2g.dtsi
[RFC] arm64: dts: renesas: Migrate H3ULCB to r8j7795-4x1g.dtsi
[RFC] arm64: dts: renesas: Migrate M3ULCB to r8j7796-2x1g.dtsi
Documentation/devicetree/bindings/arm/shmobile.txt | 16 +++++++---
arch/arm64/boot/dts/renesas/r8a7795-h3ulcb.dts | 27 ++--------------
arch/arm64/boot/dts/renesas/r8a7795-salvator-x.dts | 27 ++--------------
arch/arm64/boot/dts/renesas/r8a7796-m3ulcb.dts | 17 ++--------
arch/arm64/boot/dts/renesas/r8a7796-salvator-x.dts | 17 ++--------
arch/arm64/boot/dts/renesas/r8j7795-4x1g.dtsi | 36 ++++++++++++++++++++++
arch/arm64/boot/dts/renesas/r8j7796-2x1g.dtsi | 26 ++++++++++++++++
arch/arm64/boot/dts/renesas/r8j7796-2x2g.dtsi | 26 ++++++++++++++++
8 files changed, 112 insertions(+), 80 deletions(-)
create mode 100644 arch/arm64/boot/dts/renesas/r8j7795-4x1g.dtsi
create mode 100644 arch/arm64/boot/dts/renesas/r8j7796-2x1g.dtsi
create mode 100644 arch/arm64/boot/dts/renesas/r8j7796-2x2g.dtsi
--
2.7.4
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply
* [PATCH 1/8] [RFC] dt-bindings: renesas: Document R-Car H3 and M3-W SiP DT bindings
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>
Document the SiP ("System-in-Package") versions of the R-Car H3 and M3-W
SoCs, which contain an R-Car H3 or M3-W SoC, RAM, and HyperFlash.
Add their compatible values to all boards equipped with R-Car Gen3 SiPs.
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
---
Questions:
- Do we need more compatible values, for different configurations?
At least r8j7796 is available with either 2 GiB or 4 GiB of RAM,
possibly using RAM parts from different vendors.
---
Documentation/devicetree/bindings/arm/shmobile.txt | 16 ++++++++++++----
1 file changed, 12 insertions(+), 4 deletions(-)
diff --git a/Documentation/devicetree/bindings/arm/shmobile.txt b/Documentation/devicetree/bindings/arm/shmobile.txt
index 170fe0562c637eab..8ca3f64fec21d8b0 100644
--- a/Documentation/devicetree/bindings/arm/shmobile.txt
+++ b/Documentation/devicetree/bindings/arm/shmobile.txt
@@ -41,6 +41,14 @@ SoCs:
compatible = "renesas,r8a7796"
+SiPs:
+
+ - R-Car H3 SiP (R8J77950)
+ compatible = "renesas,r8j7795", "renesas,r8a7795"
+ - R-Car M3-W SiP (R8J77960)
+ compatible = "renesas,r8j7796", "renesas,r8a7796"
+
+
Boards:
- Alt (RTP0RC7794SEB00010S)
@@ -58,7 +66,7 @@ Boards:
- Gose (RTP0RC7793SEB00010S)
compatible = "renesas,gose", "renesas,r8a7793"
- H3ULCB (R-Car Starter Kit Premier, RTP0RC7795SKB00010S)
- compatible = "renesas,h3ulcb", "renesas,r8a7795";
+ compatible = "renesas,h3ulcb", "renesas,r8j7795", "renesas,r8a7795";
- Henninger
compatible = "renesas,henninger", "renesas,r8a7791"
- Koelsch (RTP0RC7791SEB00010S)
@@ -70,7 +78,7 @@ Boards:
- Lager (RTP0RC7790SEB00010S)
compatible = "renesas,lager", "renesas,r8a7790"
- M3ULCB (R-Car Starter Kit Pro, RTP0RC7796SKB00010S)
- compatible = "renesas,m3ulcb", "renesas,r8a7796";
+ compatible = "renesas,m3ulcb", "renesas,r8j7796", "renesas,r8a7796";
- Marzen (R0P7779A00010S)
compatible = "renesas,marzen", "renesas,r8a7779"
- Porter (M2-LCDP)
@@ -78,9 +86,9 @@ Boards:
- RSKRZA1 (YR0K77210C000BE)
compatible = "renesas,rskrza1", "renesas,r7s72100"
- Salvator-X (RTP0RC7795SIPB0010S)
- compatible = "renesas,salvator-x", "renesas,r8a7795";
+ compatible = "renesas,salvator-x", "renesas,r8j7795", "renesas,r8a7795";
- Salvator-X (RTP0RC7796SIPB0011S)
- compatible = "renesas,salvator-x", "renesas,r8a7796";
+ compatible = "renesas,salvator-x", "renesas,r8j7796", "renesas,r8a7796";
- SILK (RTP0RC7794LCB00011S)
compatible = "renesas,silk", "renesas,r8a7794"
- SK-RZG1E (YR8A77450S000BE)
--
2.7.4
^ permalink raw reply related
* [PATCH 2/8] [RFC] arm64: dts: renesas: Add R-Car H3 SiP (4 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-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>
Add support for the R-Car H3 System-in-Package (r8j7795), which contains:
- an R-Car H3 SoC (r8a7795),
- 4 channels of 1 GiB of RAM (4 GiB total),
- HyperFlash (not yet described).
Signed-off-by: Geert Uytterhoeven <geert+renesas-gXvu3+zWzMSzQB+pC5nmwQ@public.gmane.org>
---
Questions:
- Should this file be named r8j7795-4g.dtsi instead?
- Do other versions (different memory configuration) of r8j7795 exist?
If yes, how are they named?
---
arch/arm64/boot/dts/renesas/r8j7795-4x1g.dtsi | 36 +++++++++++++++++++++++++++
1 file changed, 36 insertions(+)
create mode 100644 arch/arm64/boot/dts/renesas/r8j7795-4x1g.dtsi
diff --git a/arch/arm64/boot/dts/renesas/r8j7795-4x1g.dtsi b/arch/arm64/boot/dts/renesas/r8j7795-4x1g.dtsi
new file mode 100644
index 0000000000000000..02e0ff4a60c53704
--- /dev/null
+++ b/arch/arm64/boot/dts/renesas/r8j7795-4x1g.dtsi
@@ -0,0 +1,36 @@
+/*
+ * Device Tree Source for the r8j7795 SiP with 4 channels of 1 GiB RAM
+ *
+ * Copyright (C) 2015 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 "r8a7795.dtsi"
+
+/ {
+ compatible = "renesas,r8j7795", "renesas,r8a7795";
+
+ 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 0 0x40000000>;
+ };
+
+ memory@600000000 {
+ device_type = "memory";
+ reg = <0x6 0x00000000 0 0x40000000>;
+ };
+
+ memory@700000000 {
+ device_type = "memory";
+ reg = <0x7 0x00000000 0 0x40000000>;
+ };
+};
--
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 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
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