* Re: [PATCHv2 2/2] drm/panel: simple: Add support for Winstar WF35LTIACD
From: Richard Genoud @ 2017-03-27 9:43 UTC (permalink / raw)
To: Rob Herring
Cc: Thierry Reding, Mark Rutland,
dri-devel-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW,
devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
In-Reply-To: <20170324155821.2xjginqluhjnrr2x@rob-hp-laptop>
2017-03-24 16:58 GMT+01:00 Rob Herring <robh-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>:
> On Mon, Mar 20, 2017 at 02:32:22PM +0100, Richard Genoud wrote:
>> This adds support for the Winstar Display Co. WF35LTIACD 3.5" QVGA TFT
>> LCD panel, which can be supported by the simple panel driver.
>>
>> Signed-off-by: Richard Genoud <richard.genoud-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
>> ---
>>
>> Changes since v1:
>> Add power-supply property and an example in documentation
>>
>> .../bindings/display/panel/winstar,wf35ltiacd | 53 ++++++++++++++++++++++
>> drivers/gpu/drm/panel/panel-simple.c | 28 ++++++++++++
>> 2 files changed, 81 insertions(+)
>> create mode 100644 Documentation/devicetree/bindings/display/panel/winstar,wf35ltiacd
>>
>> diff --git a/Documentation/devicetree/bindings/display/panel/winstar,wf35ltiacd b/Documentation/devicetree/bindings/display/panel/winstar,wf35ltiacd
>> new file mode 100644
>> index 000000000000..9ff59b868b28
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/display/panel/winstar,wf35ltiacd
>> @@ -0,0 +1,53 @@
>> +Winstar Display Corporation 3.5" QVGA (320x240) TFT LCD panel
>> +
>> +Required properties:
>> +- compatible: should be "winstar,wf35ltiacd"
>> +- power-supply: regulator to provide the VCC supply voltage (3.3 volts)
>> +
>> +This binding is compatible with the simple-panel binding, which is specified
>> +in simple-panel.txt in this directory.
>> +
>> +Example:
>> + backlight: backlight {
>> + compatible = "pwm-backlight";
>> + pwms = <&hlcdc_pwm 0 50000 PWM_POLARITY_INVERTED>;
>> + brightness-levels = <0 31 63 95 127 159 191 223 255>;
>> + default-brightness-level = <191>;
>> + power-supply = <&bl_reg>;
>> + status = "okay";
>
> Drop status from examples.
>
>> + };
>> +
>> + bl_reg: backlight_regulator {
>> + compatible = "regulator-fixed";
>> + regulator-name = "backlight-power-supply";
>> + regulator-min-microvolt = <5000000>;
>> + regulator-max-microvolt = <5000000>;
>> + status = "okay";
>> + };
>> +
>> + panel: panel {
>> + compatible = "winstar,wf35ltiacd", "simple-panel";
>> + backlight = <&backlight>;
>> + power-supply = <&panel_reg>;
>> + #address-cells = <1>;
>> + #size-cells = <0>;
>> + status = "okay";
>> +
>> + port@0 {
>> + #address-cells = <1>;
>> + #size-cells = <0>;
>> +
>> + panel_input: endpoint@0 {
>> + reg = <0>;
>
> You don't need reg and unit-addresses for these.
>
> With that,
>
> Acked-by: Rob Herring <robh-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
>
Ok, I'll resend the patch with reg and unit-addresses removed.
Thanks !
>> + remote-endpoint = <&hlcdc_panel_output>;
>> + };
>> + };
>> + };
>> +
>> + panel_reg: panel_regulator {
>> + compatible = "regulator-fixed";
>> + regulator-name = "panel-power-supply";
>> + regulator-min-microvolt = <3300000>;
>> + regulator-max-microvolt = <3300000>;
>> + status = "okay";
>> + };
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* [PATCH v4 5/6] arm64: dts: rockchip: add dts file for RK3328
From: cl-TNX95d0MmH7DzftRWevZcw @ 2017-03-27 9:40 UTC (permalink / raw)
To: heiko-4mtYJXux2i+zQB+pC5nmwQ
Cc: robh+dt-DgEjT+Ai2ygdnm+yROfE0A, mark.rutland-5wv7dgnIgG8,
zhengxing-TNX95d0MmH7DzftRWevZcw, andy.yan-TNX95d0MmH7DzftRWevZcw,
jay.xu-TNX95d0MmH7DzftRWevZcw,
matthias.bgg-Re5JQEeQqe8AvxtiuMwx3w,
paweljarosz3691-Re5JQEeQqe8AvxtiuMwx3w,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-rockchip-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-kernel-u79uwXL29TY76Z2rM5mHXA, wsa-z923LK4zBo2bacvFa/9K2g,
linux-i2c-u79uwXL29TY76Z2rM5mHXA, jic23-DgEjT+Ai2ygdnm+yROfE0A,
knaack.h-Mmb7MZpHnFY, lars-Qo5EllUWu/uELgA04lAiVw,
pmeerw-jW+XmwGofnusTnJN9+BGXg, wxt-TNX95d0MmH7DzftRWevZcw,
david.wu-TNX95d0MmH7DzftRWevZcw, linux-iio-u79uwXL29TY76Z2rM5mHXA,
shawn.lin-TNX95d0MmH7DzftRWevZcw,
akpm-de/tnXTf+JLsfHDXvbKv3WD2FQJk+8+b,
dianders-F7+t8E8rja9g9hUCZPvPmw,
yamada.masahiro-uWyLwvC0a2jby3iVrkZq2A,
catalin.marinas-5wv7dgnIgG8, will.deacon-5wv7dgnIgG8,
afaerber-l3A5Bk7waGM, shawnguo-DgEjT+Ai2ygdnm+yROfE0A,
khilman-rdvid1DuHRBWk0Htik3J/w, arnd-r2nGTMty4D4,
fabio.estevam-3arQi8VN3Tc, zhangqing-TNX95d0MmH7DzftRWevZcw,
kever.yang-TNX95d0MmH7DzftRWevZcw
In-Reply-To: <1490607650-18650-1-git-send-email-cl-TNX95d0MmH7DzftRWevZcw@public.gmane.org>
From: Liang Chen <cl-TNX95d0MmH7DzftRWevZcw@public.gmane.org>
This patch add rk3328-evb.dts for RK3328 evaluation board.
Tested on RK3328 evb.
Signed-off-by: Liang Chen <cl-TNX95d0MmH7DzftRWevZcw@public.gmane.org>
---
arch/arm64/boot/dts/rockchip/Makefile | 1 +
arch/arm64/boot/dts/rockchip/rk3328-evb.dts | 57 +++++++++++++++++++++++++++++
2 files changed, 58 insertions(+)
create mode 100644 arch/arm64/boot/dts/rockchip/rk3328-evb.dts
diff --git a/arch/arm64/boot/dts/rockchip/Makefile b/arch/arm64/boot/dts/rockchip/Makefile
index 3a86289..d09ea3c 100644
--- a/arch/arm64/boot/dts/rockchip/Makefile
+++ b/arch/arm64/boot/dts/rockchip/Makefile
@@ -1,3 +1,4 @@
+dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3328-evb.dtb
dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3368-evb-act8846.dtb
dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3368-geekbox.dtb
dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3368-orion-r68-meta.dtb
diff --git a/arch/arm64/boot/dts/rockchip/rk3328-evb.dts b/arch/arm64/boot/dts/rockchip/rk3328-evb.dts
new file mode 100644
index 0000000..cf27239
--- /dev/null
+++ b/arch/arm64/boot/dts/rockchip/rk3328-evb.dts
@@ -0,0 +1,57 @@
+/*
+ * Copyright (c) 2017 Fuzhou Rockchip Electronics Co., Ltd
+ *
+ * This file is dual-licensed: you can use it either under the terms
+ * of the GPL or the X11 license, at your option. Note that this dual
+ * licensing only applies to this file, and not this project as a
+ * whole.
+ *
+ * a) This library is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation; either version 2 of the
+ * License, or (at your option) any later version.
+ *
+ * This library is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * Or, alternatively,
+ *
+ * b) Permission is hereby granted, free of charge, to any person
+ * obtaining a copy of this software and associated documentation
+ * files (the "Software"), to deal in the Software without
+ * restriction, including without limitation the rights to use,
+ * copy, modify, merge, publish, distribute, sublicense, and/or
+ * sell copies of the Software, and to permit persons to whom the
+ * Software is furnished to do so, subject to the following
+ * conditions:
+ *
+ * The above copyright notice and this permission notice shall be
+ * included in all copies or substantial portions of the Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
+ * EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES
+ * OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
+ * NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT
+ * HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY,
+ * WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
+ * OTHER DEALINGS IN THE SOFTWARE.
+ */
+
+/dts-v1/;
+#include "rk3328.dtsi"
+
+/ {
+ model = "Rockchip RK3328 EVB";
+ compatible = "rockchip,rk3328-evb", "rockchip,rk3328";
+
+ chosen {
+ stdout-path = "serial2:1500000n8";
+ };
+};
+
+&uart2 {
+ status = "okay";
+};
--
1.9.1
^ permalink raw reply related
* [PATCH v4 4/6] arm64: dts: rockchip: add core dtsi file for RK3328 SoCs
From: cl @ 2017-03-27 9:40 UTC (permalink / raw)
To: heiko
Cc: robh+dt, mark.rutland, zhengxing, andy.yan, jay.xu, matthias.bgg,
paweljarosz3691, devicetree, linux-arm-kernel, linux-rockchip,
linux-kernel, wsa, linux-i2c, jic23, knaack.h, lars, pmeerw, wxt,
david.wu, linux-iio, shawn.lin, akpm, dianders, yamada.masahiro,
catalin.marinas, will.deacon, afaerber, shawnguo, khilman, arnd,
fabio.estevam, zhangqing, kever.yang
In-Reply-To: <1490607650-18650-1-git-send-email-cl@rock-chips.com>
From: Liang Chen <cl@rock-chips.com>
This patch adds core dtsi file for Rockchip RK3328 SoCs.
Signed-off-by: Liang Chen <cl@rock-chips.com>
---
arch/arm64/boot/dts/rockchip/rk3328.dtsi | 1275 ++++++++++++++++++++++++++++++
1 file changed, 1275 insertions(+)
create mode 100644 arch/arm64/boot/dts/rockchip/rk3328.dtsi
diff --git a/arch/arm64/boot/dts/rockchip/rk3328.dtsi b/arch/arm64/boot/dts/rockchip/rk3328.dtsi
new file mode 100644
index 0000000..ddc95c8
--- /dev/null
+++ b/arch/arm64/boot/dts/rockchip/rk3328.dtsi
@@ -0,0 +1,1275 @@
+/*
+ * Copyright (c) 2017 Fuzhou Rockchip Electronics Co., Ltd
+ *
+ * This file is dual-licensed: you can use it either under the terms
+ * of the GPL or the X11 license, at your option. Note that this dual
+ * licensing only applies to this file, and not this project as a
+ * whole.
+ *
+ * a) This library is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation; either version 2 of the
+ * License, or (at your option) any later version.
+ *
+ * This library is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * Or, alternatively,
+ *
+ * b) Permission is hereby granted, free of charge, to any person
+ * obtaining a copy of this software and associated documentation
+ * files (the "Software"), to deal in the Software without
+ * restriction, including without limitation the rights to use,
+ * copy, modify, merge, publish, distribute, sublicense, and/or
+ * sell copies of the Software, and to permit persons to whom the
+ * Software is furnished to do so, subject to the following
+ * conditions:
+ *
+ * The above copyright notice and this permission notice shall be
+ * included in all copies or substantial portions of the Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
+ * EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES
+ * OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
+ * NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT
+ * HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY,
+ * WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
+ * OTHER DEALINGS IN THE SOFTWARE.
+ */
+
+#include <dt-bindings/clock/rk3328-cru.h>
+#include <dt-bindings/gpio/gpio.h>
+#include <dt-bindings/interrupt-controller/arm-gic.h>
+#include <dt-bindings/interrupt-controller/irq.h>
+#include <dt-bindings/pinctrl/rockchip.h>
+#include <dt-bindings/soc/rockchip,boot-mode.h>
+#include <dt-bindings/power/rk3328-power.h>
+
+/ {
+ compatible = "rockchip,rk3328";
+
+ interrupt-parent = <&gic>;
+ #address-cells = <2>;
+ #size-cells = <2>;
+
+ aliases {
+ serial0 = &uart0;
+ serial1 = &uart1;
+ serial2 = &uart2;
+ i2c0 = &i2c0;
+ i2c1 = &i2c1;
+ i2c2 = &i2c2;
+ i2c3 = &i2c3;
+ };
+
+ cpus {
+ #address-cells = <2>;
+ #size-cells = <0>;
+
+ cpu0: cpu@0 {
+ device_type = "cpu";
+ compatible = "arm,cortex-a53", "arm,armv8";
+ reg = <0x0 0x0>;
+ enable-method = "psci";
+ next-level-cache = <&l2>;
+ clocks = <&cru ARMCLK>;
+ };
+ cpu1: cpu@1 {
+ device_type = "cpu";
+ compatible = "arm,cortex-a53", "arm,armv8";
+ reg = <0x0 0x1>;
+ enable-method = "psci";
+ next-level-cache = <&l2>;
+ clocks = <&cru ARMCLK>;
+ };
+ cpu2: cpu@2 {
+ device_type = "cpu";
+ compatible = "arm,cortex-a53", "arm,armv8";
+ reg = <0x0 0x2>;
+ enable-method = "psci";
+ next-level-cache = <&l2>;
+ clocks = <&cru ARMCLK>;
+ };
+ cpu3: cpu@3 {
+ device_type = "cpu";
+ compatible = "arm,cortex-a53", "arm,armv8";
+ reg = <0x0 0x3>;
+ enable-method = "psci";
+ next-level-cache = <&l2>;
+ clocks = <&cru ARMCLK>;
+ };
+
+ l2: l2-cache0 {
+ compatible = "cache";
+ };
+ };
+
+ amba {
+ compatible = "simple-bus";
+ #address-cells = <2>;
+ #size-cells = <2>;
+ ranges;
+
+ dmac: dmac@ff1f0000 {
+ compatible = "arm,pl330", "arm,primecell";
+ reg = <0x0 0xff1f0000 0x0 0x4000>;
+ interrupts = <GIC_SPI 0 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 1 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&cru ACLK_DMAC>;
+ clock-names = "apb_pclk";
+ #dma-cells = <1>;
+ };
+ };
+
+ arm-pmu {
+ compatible = "arm,cortex-a53-pmu";
+ interrupts = <GIC_SPI 100 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 101 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 102 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 103 IRQ_TYPE_LEVEL_HIGH>;
+ interrupt-affinity = <&cpu0>, <&cpu1>, <&cpu2>, <&cpu3>;
+ };
+
+ psci {
+ compatible = "arm,psci-1.0", "arm,psci-0.2";
+ method = "smc";
+ };
+
+ timer {
+ compatible = "arm,armv8-timer";
+ interrupts = <GIC_PPI 13 (GIC_CPU_MASK_SIMPLE(4) | IRQ_TYPE_LEVEL_LOW)>,
+ <GIC_PPI 14 (GIC_CPU_MASK_SIMPLE(4) | IRQ_TYPE_LEVEL_LOW)>,
+ <GIC_PPI 11 (GIC_CPU_MASK_SIMPLE(4) | IRQ_TYPE_LEVEL_LOW)>,
+ <GIC_PPI 10 (GIC_CPU_MASK_SIMPLE(4) | IRQ_TYPE_LEVEL_LOW)>;
+ };
+
+ xin24m: xin24m {
+ compatible = "fixed-clock";
+ #clock-cells = <0>;
+ clock-frequency = <24000000>;
+ clock-output-names = "xin24m";
+ };
+
+ grf: syscon@ff100000 {
+ compatible = "rockchip,rk3328-grf", "syscon", "simple-mfd";
+ reg = <0x0 0xff100000 0x0 0x1000>;
+ #address-cells = <1>;
+ #size-cells = <1>;
+
+ power: power-controller {
+ compatible = "rockchip,rk3328-power-controller";
+ #power-domain-cells = <1>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ status = "disabled";
+
+ pd_hevc@RK3328_PD_HEVC {
+ reg = <RK3328_PD_HEVC>;
+ };
+ pd_video@RK3328_PD_VIDEO {
+ reg = <RK3328_PD_VIDEO>;
+ };
+ pd_vpu@RK3328_PD_VPU {
+ reg = <RK3328_PD_VPU>;
+ };
+ };
+
+ reboot-mode {
+ compatible = "syscon-reboot-mode";
+ offset = <0x5c8>;
+ mode-normal = <BOOT_NORMAL>;
+ mode-recovery = <BOOT_RECOVERY>;
+ mode-bootloader = <BOOT_FASTBOOT>;
+ mode-loader = <BOOT_BL_DOWNLOAD>;
+ };
+
+ };
+
+ uart0: serial@ff110000 {
+ compatible = "rockchip,rk3328-uart", "snps,dw-apb-uart";
+ reg = <0x0 0xff110000 0x0 0x100>;
+ interrupts = <GIC_SPI 55 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&cru SCLK_UART0>, <&cru PCLK_UART0>;
+ clock-names = "baudclk", "apb_pclk";
+ reg-shift = <2>;
+ reg-io-width = <4>;
+ dmas = <&dmac 2>, <&dmac 3>;
+ #dma-cells = <2>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&uart0_xfer &uart0_cts &uart0_rts>;
+ status = "disabled";
+ };
+
+ uart1: serial@ff120000 {
+ compatible = "rockchip,rk3328-uart", "snps,dw-apb-uart";
+ reg = <0x0 0xff120000 0x0 0x100>;
+ interrupts = <GIC_SPI 56 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&cru SCLK_UART1>, <&cru PCLK_UART1>;
+ clock-names = "sclk_uart", "pclk_uart";
+ reg-shift = <2>;
+ reg-io-width = <4>;
+ dmas = <&dmac 4>, <&dmac 5>;
+ #dma-cells = <2>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&uart1_xfer &uart1_cts &uart1_rts>;
+ status = "disabled";
+ };
+
+ uart2: serial@ff130000 {
+ compatible = "rockchip,rk3328-uart", "snps,dw-apb-uart";
+ reg = <0x0 0xff130000 0x0 0x100>;
+ interrupts = <GIC_SPI 57 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&cru SCLK_UART2>, <&cru PCLK_UART2>;
+ clock-names = "baudclk", "apb_pclk";
+ reg-shift = <2>;
+ reg-io-width = <4>;
+ dmas = <&dmac 6>, <&dmac 7>;
+ #dma-cells = <2>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&uart2m1_xfer>;
+ status = "disabled";
+ };
+
+ i2c0: i2c@ff150000 {
+ compatible = "rockchip,rk3328-i2c", "rockchip,rk3399-i2c";
+ reg = <0x0 0xff150000 0x0 0x1000>;
+ interrupts = <GIC_SPI 36 IRQ_TYPE_LEVEL_HIGH>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ clocks = <&cru SCLK_I2C0>, <&cru PCLK_I2C0>;
+ clock-names = "i2c", "pclk";
+ pinctrl-names = "default";
+ pinctrl-0 = <&i2c0_xfer>;
+ status = "disabled";
+ };
+
+ i2c1: i2c@ff160000 {
+ compatible = "rockchip,rk3328-i2c", "rockchip,rk3399-i2c";
+ reg = <0x0 0xff160000 0x0 0x1000>;
+ interrupts = <GIC_SPI 37 IRQ_TYPE_LEVEL_HIGH>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ clocks = <&cru SCLK_I2C1>, <&cru PCLK_I2C1>;
+ clock-names = "i2c", "pclk";
+ pinctrl-names = "default";
+ pinctrl-0 = <&i2c1_xfer>;
+ status = "disabled";
+ };
+
+ i2c2: i2c@ff170000 {
+ compatible = "rockchip,rk3328-i2c", "rockchip,rk3399-i2c";
+ reg = <0x0 0xff170000 0x0 0x1000>;
+ interrupts = <GIC_SPI 38 IRQ_TYPE_LEVEL_HIGH>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ clocks = <&cru SCLK_I2C2>, <&cru PCLK_I2C2>;
+ clock-names = "i2c", "pclk";
+ pinctrl-names = "default";
+ pinctrl-0 = <&i2c2_xfer>;
+ status = "disabled";
+ };
+
+ i2c3: i2c@ff180000 {
+ compatible = "rockchip,rk3328-i2c", "rockchip,rk3399-i2c";
+ reg = <0x0 0xff180000 0x0 0x1000>;
+ interrupts = <GIC_SPI 39 IRQ_TYPE_LEVEL_HIGH>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ clocks = <&cru SCLK_I2C3>, <&cru PCLK_I2C3>;
+ clock-names = "i2c", "pclk";
+ pinctrl-names = "default";
+ pinctrl-0 = <&i2c3_xfer>;
+ status = "disabled";
+ };
+
+ spi0: spi@ff190000 {
+ compatible = "rockchip,rk3328-spi", "rockchip,rk3066-spi";
+ reg = <0x0 0xff190000 0x0 0x1000>;
+ interrupts = <GIC_SPI 49 IRQ_TYPE_LEVEL_HIGH>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ clocks = <&cru SCLK_SPI>, <&cru PCLK_SPI>;
+ clock-names = "spiclk", "apb_pclk";
+ dmas = <&dmac 8>, <&dmac 9>;
+ #dma-cells = <2>;
+ dma-names = "tx", "rx";
+ pinctrl-names = "default";
+ pinctrl-0 = <&spi0m2_clk &spi0m2_tx &spi0m2_rx &spi0m2_cs0>;
+ status = "disabled";
+ };
+
+ wdt: watchdog@ff1a0000 {
+ compatible = "snps,dw-wdt";
+ reg = <0x0 0xff1a0000 0x0 0x100>;
+ interrupts = <GIC_SPI 40 IRQ_TYPE_LEVEL_HIGH>;
+ };
+
+ saradc: saradc@ff280000 {
+ compatible = "rockchip,rk3328-saradc", "rockchip,rk3399-saradc";
+ reg = <0x0 0xff280000 0x0 0x100>;
+ interrupts = <GIC_SPI 80 IRQ_TYPE_LEVEL_HIGH>;
+ #io-channel-cells = <1>;
+ clocks = <&cru SCLK_SARADC>, <&cru PCLK_SARADC>;
+ clock-names = "saradc", "apb_pclk";
+ resets = <&cru SRST_SARADC_P>;
+ reset-names = "saradc-apb";
+ status = "disabled";
+ };
+
+ cru: clock-controller@ff440000 {
+ compatible = "rockchip,rk3328-cru", "rockchip,cru", "syscon";
+ reg = <0x0 0xff440000 0x0 0x1000>;
+ rockchip,grf = <&grf>;
+ #clock-cells = <1>;
+ #reset-cells = <1>;
+ assigned-clocks =
+ /*
+ * Cpll init freq is 1200MHz, is too high.
+ * we need set cpll child clk div first,
+ * and then set cpll freq.
+ */
+ <&cru DCLK_LCDC>, <&cru SCLK_PDM>,
+ <&cru SCLK_RTC32K>, <&cru SCLK_UART0>,
+ <&cru SCLK_UART1>, <&cru SCLK_UART2>,
+ <&cru ACLK_BUS_PRE>, <&cru ACLK_PERI_PRE>,
+ <&cru ACLK_VIO_PRE>, <&cru ACLK_RGA_PRE>,
+ <&cru ACLK_VOP_PRE>, <&cru ACLK_RKVDEC_PRE>,
+ <&cru ACLK_RKVENC>, <&cru ACLK_VPU_PRE>,
+ <&cru SCLK_VDEC_CABAC>, <&cru SCLK_VDEC_CORE>,
+ <&cru SCLK_VENC_CORE>, <&cru SCLK_VENC_DSP>,
+ <&cru SCLK_SDIO>, <&cru SCLK_TSP>,
+ <&cru SCLK_WIFI>, <&cru ARMCLK>,
+ <&cru PLL_GPLL>, <&cru PLL_CPLL>,
+ <&cru ACLK_BUS_PRE>, <&cru HCLK_BUS_PRE>,
+ <&cru PCLK_BUS_PRE>, <&cru ACLK_PERI_PRE>,
+ <&cru HCLK_PERI>, <&cru PCLK_PERI>,
+ <&cru SCLK_RTC32K>;
+ assigned-clock-parents =
+ <&cru HDMIPHY>, <&cru PLL_APLL>,
+ <&cru PLL_GPLL>, <&xin24m>,
+ <&xin24m>, <&xin24m>;
+ assigned-clock-rates =
+ <0>, <61440000>,
+ <0>, <24000000>,
+ <24000000>, <24000000>,
+ <15000000>, <15000000>,
+ <100000000>, <100000000>,
+ <100000000>, <100000000>,
+ <50000000>, <100000000>,
+ <100000000>, <100000000>,
+ <50000000>, <50000000>,
+ <50000000>, <50000000>,
+ <24000000>, <600000000>,
+ <491520000>, <1200000000>,
+ <150000000>, <75000000>,
+ <75000000>, <150000000>,
+ <75000000>, <75000000>,
+ <32768>;
+ };
+
+ gmac2io: ethernet@ff540000 {
+ compatible = "rockchip,rk3328-gmac";
+ reg = <0x0 0xff540000 0x0 0x10000>;
+ rockchip,grf = <&grf>;
+ interrupts = <GIC_SPI 24 IRQ_TYPE_LEVEL_HIGH>;
+ interrupt-names = "macirq";
+ clocks = <&cru SCLK_MAC2IO>, <&cru SCLK_MAC2IO_RX>,
+ <&cru SCLK_MAC2IO_TX>, <&cru SCLK_MAC2IO_REF>,
+ <&cru SCLK_MAC2IO_REFOUT>, <&cru ACLK_MAC2IO>,
+ <&cru PCLK_MAC2IO>;
+ clock-names = "stmmaceth", "mac_clk_rx",
+ "mac_clk_tx", "clk_mac_ref",
+ "clk_mac_refout", "aclk_mac",
+ "pclk_mac";
+ resets = <&cru SRST_GMAC2IO_A>;
+ reset-names = "stmmaceth";
+ status = "disabled";
+ };
+
+ gic: interrupt-controller@ff811000 {
+ compatible = "arm,gic-400";
+ #interrupt-cells = <3>;
+ #address-cells = <0>;
+ interrupt-controller;
+ reg = <0x0 0xff811000 0 0x1000>,
+ <0x0 0xff812000 0 0x2000>,
+ <0x0 0xff814000 0 0x2000>,
+ <0x0 0xff816000 0 0x2000>;
+ interrupts = <GIC_PPI 9
+ (GIC_CPU_MASK_SIMPLE(4) | IRQ_TYPE_LEVEL_HIGH)>;
+ };
+
+ pinctrl: pinctrl {
+ compatible = "rockchip,rk3328-pinctrl";
+ rockchip,grf = <&grf>;
+ #address-cells = <2>;
+ #size-cells = <2>;
+ ranges;
+
+ gpio0: gpio0@ff210000 {
+ compatible = "rockchip,gpio-bank";
+ reg = <0x0 0xff210000 0x0 0x100>;
+ interrupts = <GIC_SPI 51 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&cru PCLK_GPIO0>;
+
+ gpio-controller;
+ #gpio-cells = <2>;
+
+ interrupt-controller;
+ #interrupt-cells = <2>;
+ };
+
+ gpio1: gpio1@ff220000 {
+ compatible = "rockchip,gpio-bank";
+ reg = <0x0 0xff220000 0x0 0x100>;
+ interrupts = <GIC_SPI 52 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&cru PCLK_GPIO1>;
+
+ gpio-controller;
+ #gpio-cells = <2>;
+
+ interrupt-controller;
+ #interrupt-cells = <2>;
+ };
+
+ gpio2: gpio2@ff230000 {
+ compatible = "rockchip,gpio-bank";
+ reg = <0x0 0xff230000 0x0 0x100>;
+ interrupts = <GIC_SPI 53 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&cru PCLK_GPIO2>;
+
+ gpio-controller;
+ #gpio-cells = <2>;
+
+ interrupt-controller;
+ #interrupt-cells = <2>;
+ };
+
+ gpio3: gpio3@ff240000 {
+ compatible = "rockchip,gpio-bank";
+ reg = <0x0 0xff240000 0x0 0x100>;
+ interrupts = <GIC_SPI 54 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&cru PCLK_GPIO3>;
+
+ gpio-controller;
+ #gpio-cells = <2>;
+
+ interrupt-controller;
+ #interrupt-cells = <2>;
+ };
+
+ pcfg_pull_up: pcfg-pull-up {
+ bias-pull-up;
+ };
+
+ pcfg_pull_down: pcfg-pull-down {
+ bias-pull-down;
+ };
+
+ pcfg_pull_none: pcfg-pull-none {
+ bias-disable;
+ };
+
+ pcfg_pull_none_2ma: pcfg-pull-none-2ma {
+ bias-disable;
+ drive-strength = <2>;
+ };
+
+ pcfg_pull_up_2ma: pcfg-pull-up-2ma {
+ bias-pull-up;
+ drive-strength = <2>;
+ };
+
+ pcfg_pull_up_4ma: pcfg-pull-up-4ma {
+ bias-pull-up;
+ drive-strength = <4>;
+ };
+
+ pcfg_pull_none_4ma: pcfg-pull-none-4ma {
+ bias-disable;
+ drive-strength = <4>;
+ };
+
+ pcfg_pull_down_4ma: pcfg-pull-down-4ma {
+ bias-pull-down;
+ drive-strength = <4>;
+ };
+
+ pcfg_pull_none_8ma: pcfg-pull-none-8ma {
+ bias-disable;
+ drive-strength = <8>;
+ };
+
+ pcfg_pull_up_8ma: pcfg-pull-up-8ma {
+ bias-pull-up;
+ drive-strength = <8>;
+ };
+
+ pcfg_pull_none_12ma: pcfg-pull-none-12ma {
+ bias-disable;
+ drive-strength = <12>;
+ };
+
+ pcfg_pull_up_12ma: pcfg-pull-up-12ma {
+ bias-pull-up;
+ drive-strength = <12>;
+ };
+
+ pcfg_output_high: pcfg-output-high {
+ output-high;
+ };
+
+ pcfg_output_low: pcfg-output-low {
+ output-low;
+ };
+
+ pcfg_input_high: pcfg-input-high {
+ bias-pull-up;
+ input-enable;
+ };
+
+ pcfg_input: pcfg-input {
+ input-enable;
+ };
+
+ i2c0 {
+ i2c0_xfer: i2c0-xfer {
+ rockchip,pins = <2 RK_PD0 1 &pcfg_pull_none>,
+ <2 RK_PD1 1 &pcfg_pull_none>;
+ };
+ };
+
+ i2c1 {
+ i2c1_xfer: i2c1-xfer {
+ rockchip,pins = <2 RK_PA4 2 &pcfg_pull_none>,
+ <2 RK_PA5 2 &pcfg_pull_none>;
+ };
+ };
+
+ i2c2 {
+ i2c2_xfer: i2c2-xfer {
+ rockchip,pins = <2 RK_PB5 1 &pcfg_pull_none>,
+ <2 RK_PB6 1 &pcfg_pull_none>;
+ };
+ };
+
+ i2c3 {
+ i2c3_xfer: i2c3-xfer {
+ rockchip,pins = <0 RK_PA5 2 &pcfg_pull_none>,
+ <0 RK_PA6 2 &pcfg_pull_none>;
+ };
+ i2c3_gpio: i2c3-gpio {
+ rockchip,pins =
+ <0 RK_PA5 RK_FUNC_GPIO &pcfg_pull_none>,
+ <0 RK_PA6 RK_FUNC_GPIO &pcfg_pull_none>;
+ };
+ };
+
+ hdmi_i2c {
+ hdmii2c_xfer: hdmii2c-xfer {
+ rockchip,pins = <0 RK_PA5 1 &pcfg_pull_none>,
+ <0 RK_PA6 1 &pcfg_pull_none>;
+ };
+ };
+
+ tsadc {
+ otp_gpio: otp-gpio {
+ rockchip,pins =
+ <2 RK_PB5 RK_FUNC_GPIO &pcfg_pull_none>;
+ };
+
+ otp_out: otp-out {
+ rockchip,pins = <2 RK_PB5 1 &pcfg_pull_none>;
+ };
+ };
+
+ uart0 {
+ uart0_xfer: uart0-xfer {
+ rockchip,pins = <1 RK_PB1 1 &pcfg_pull_up>,
+ <1 RK_PB0 1 &pcfg_pull_none>;
+ };
+
+ uart0_cts: uart0-cts {
+ rockchip,pins = <1 RK_PB3 1 &pcfg_pull_none>;
+ };
+
+ uart0_rts: uart0-rts {
+ rockchip,pins = <1 RK_PB2 1 &pcfg_pull_none>;
+ };
+
+ uart0_rts_gpio: uart0-rts-gpio {
+ rockchip,pins =
+ <1 RK_PB2 RK_FUNC_GPIO &pcfg_pull_none>;
+ };
+ };
+
+ uart1 {
+ uart1_xfer: uart1-xfer {
+ rockchip,pins = <3 RK_PA4 4 &pcfg_pull_up>,
+ <3 RK_PA6 4 &pcfg_pull_none>;
+ };
+
+ uart1_cts: uart1-cts {
+ rockchip,pins = <3 RK_PA7 4 &pcfg_pull_none>;
+ };
+
+ uart1_rts: uart1-rts {
+ rockchip,pins = <3 RK_PA5 4 &pcfg_pull_none>;
+ };
+
+ uart1_rts_gpio: uart1-rts-gpio {
+ rockchip,pins =
+ <3 RK_PA5 RK_FUNC_GPIO &pcfg_pull_none>;
+ };
+ };
+
+ uart2-0 {
+ uart2m0_xfer: uart2m0-xfer {
+ rockchip,pins = <1 RK_PA0 2 &pcfg_pull_up>,
+ <1 RK_PA1 2 &pcfg_pull_none>;
+ };
+ };
+
+ uart2-1 {
+ uart2m1_xfer: uart2m1-xfer {
+ rockchip,pins = <2 RK_PA0 1 &pcfg_pull_up>,
+ <2 RK_PA1 1 &pcfg_pull_none>;
+ };
+ };
+
+ spi0-0 {
+ spi0m0_clk: spi0m0-clk {
+ rockchip,pins = <2 RK_PB0 1 &pcfg_pull_up>;
+ };
+
+ spi0m0_cs0: spi0m0-cs0 {
+ rockchip,pins = <2 RK_PB3 1 &pcfg_pull_up>;
+ };
+
+ spi0m0_tx: spi0m0-tx {
+ rockchip,pins = <2 RK_PB1 1 &pcfg_pull_up>;
+ };
+
+ spi0m0_rx: spi0m0-rx {
+ rockchip,pins = <2 RK_PB2 1 &pcfg_pull_up>;
+ };
+
+ spi0m0_cs1: spi0m0-cs1 {
+ rockchip,pins = <2 RK_PB4 1 &pcfg_pull_up>;
+ };
+ };
+
+ spi0-1 {
+ spi0m1_clk: spi0m1-clk {
+ rockchip,pins = <3 RK_PC7 2 &pcfg_pull_up>;
+ };
+
+ spi0m1_cs0: spi0m1-cs0 {
+ rockchip,pins = <3 RK_PD2 2 &pcfg_pull_up>;
+ };
+
+ spi0m1_tx: spi0m1-tx {
+ rockchip,pins = <3 RK_PD1 2 &pcfg_pull_up>;
+ };
+
+ spi0m1_rx: spi0m1-rx {
+ rockchip,pins = <3 RK_PD0 2 &pcfg_pull_up>;
+ };
+
+ spi0m1_cs1: spi0m1-cs1 {
+ rockchip,pins = <3 RK_PD3 2 &pcfg_pull_up>;
+ };
+ };
+
+ spi0-2 {
+ spi0m2_clk: spi0m2-clk {
+ rockchip,pins = <3 RK_PA0 4 &pcfg_pull_up>;
+ };
+
+ spi0m2_cs0: spi0m2-cs0 {
+ rockchip,pins = <3 RK_PB0 3 &pcfg_pull_up>;
+ };
+
+ spi0m2_tx: spi0m2-tx {
+ rockchip,pins = <3 RK_PA1 4 &pcfg_pull_up>;
+ };
+
+ spi0m2_rx: spi0m2-rx {
+ rockchip,pins = <3 RK_PA2 4 &pcfg_pull_up>;
+ };
+ };
+
+ i2s1 {
+ i2s1_mclk: i2s1-mclk {
+ rockchip,pins = <2 RK_PB7 1 &pcfg_pull_none>;
+ };
+
+ i2s1_sclk: i2s1-sclk {
+ rockchip,pins = <2 RK_PC2 1 &pcfg_pull_none>;
+ };
+
+ i2s1_lrckrx: i2s1-lrckrx {
+ rockchip,pins = <2 RK_PC0 1 &pcfg_pull_none>;
+ };
+
+ i2s1_lrcktx: i2s1-lrcktx {
+ rockchip,pins = <2 RK_PC1 1 &pcfg_pull_none>;
+ };
+
+ i2s1_sdi: i2s1-sdi {
+ rockchip,pins = <2 RK_PC3 1 &pcfg_pull_none>;
+ };
+
+ i2s1_sdo: i2s1-sdo {
+ rockchip,pins = <2 RK_PC7 1 &pcfg_pull_none>;
+ };
+
+ i2s1_sdio1: i2s1-sdio1 {
+ rockchip,pins = <2 RK_PC4 1 &pcfg_pull_none>;
+ };
+
+ i2s1_sdio2: i2s1-sdio2 {
+ rockchip,pins = <2 RK_PC5 1 &pcfg_pull_none>;
+ };
+
+ i2s1_sdio3: i2s1-sdio3 {
+ rockchip,pins = <2 RK_PC6 1 &pcfg_pull_none>;
+ };
+
+ i2s1_sleep: i2s1-sleep {
+ rockchip,pins =
+ <2 RK_PB7 RK_FUNC_GPIO &pcfg_input_high>,
+ <2 RK_PC0 RK_FUNC_GPIO &pcfg_input_high>,
+ <2 RK_PC1 RK_FUNC_GPIO &pcfg_input_high>,
+ <2 RK_PC2 RK_FUNC_GPIO &pcfg_input_high>,
+ <2 RK_PC3 RK_FUNC_GPIO &pcfg_input_high>,
+ <2 RK_PC4 RK_FUNC_GPIO &pcfg_input_high>,
+ <2 RK_PC5 RK_FUNC_GPIO &pcfg_input_high>,
+ <2 RK_PC6 RK_FUNC_GPIO &pcfg_input_high>,
+ <2 RK_PC7 RK_FUNC_GPIO &pcfg_input_high>;
+ };
+ };
+
+ i2s2-0 {
+ i2s2m0_mclk: i2s2m0-mclk {
+ rockchip,pins = <1 RK_PC5 1 &pcfg_pull_none>;
+ };
+
+ i2s2m0_sclk: i2s2m0-sclk {
+ rockchip,pins = <1 RK_PC6 1 &pcfg_pull_none>;
+ };
+
+ i2s2m0_lrckrx: i2s2m0-lrckrx {
+ rockchip,pins = <1 RK_PD2 1 &pcfg_pull_none>;
+ };
+
+ i2s2m0_lrcktx: i2s2m0-lrcktx {
+ rockchip,pins = <1 RK_PC7 1 &pcfg_pull_none>;
+ };
+
+ i2s2m0_sdi: i2s2m0-sdi {
+ rockchip,pins = <1 RK_PD0 1 &pcfg_pull_none>;
+ };
+
+ i2s2m0_sdo: i2s2m0-sdo {
+ rockchip,pins = <1 RK_PD1 1 &pcfg_pull_none>;
+ };
+
+ i2s2m0_sleep: i2s2m0-sleep {
+ rockchip,pins =
+ <1 RK_PC5 RK_FUNC_GPIO &pcfg_input_high>,
+ <1 RK_PC6 RK_FUNC_GPIO &pcfg_input_high>,
+ <1 RK_PD2 RK_FUNC_GPIO &pcfg_input_high>,
+ <1 RK_PC7 RK_FUNC_GPIO &pcfg_input_high>,
+ <1 RK_PD0 RK_FUNC_GPIO &pcfg_input_high>,
+ <1 RK_PD1 RK_FUNC_GPIO &pcfg_input_high>;
+ };
+ };
+
+ i2s2-1 {
+ i2s2m1_mclk: i2s2m1-mclk {
+ rockchip,pins = <1 RK_PC5 1 &pcfg_pull_none>;
+ };
+
+ i2s2m1_sclk: i2s2m1-sclk {
+ rockchip,pins = <3 RK_PA0 6 &pcfg_pull_none>;
+ };
+
+ i2s2m1_lrckrx: i2sm1-lrckrx {
+ rockchip,pins = <3 RK_PB0 6 &pcfg_pull_none>;
+ };
+
+ i2s2m1_lrcktx: i2s2m1-lrcktx {
+ rockchip,pins = <3 RK_PB0 4 &pcfg_pull_none>;
+ };
+
+ i2s2m1_sdi: i2s2m1-sdi {
+ rockchip,pins = <3 RK_PA2 6 &pcfg_pull_none>;
+ };
+
+ i2s2m1_sdo: i2s2m1-sdo {
+ rockchip,pins = <3 RK_PA1 6 &pcfg_pull_none>;
+ };
+
+ i2s2m1_sleep: i2s2m1-sleep {
+ rockchip,pins =
+ <1 RK_PC5 RK_FUNC_GPIO &pcfg_input_high>,
+ <3 RK_PA0 RK_FUNC_GPIO &pcfg_input_high>,
+ <3 RK_PB0 RK_FUNC_GPIO &pcfg_input_high>,
+ <3 RK_PA2 RK_FUNC_GPIO &pcfg_input_high>,
+ <3 RK_PA1 RK_FUNC_GPIO &pcfg_input_high>;
+ };
+ };
+
+ spdif-0 {
+ spdifm0_tx: spdifm0-tx {
+ rockchip,pins = <0 RK_PD3 1 &pcfg_pull_none>;
+ };
+ };
+
+ spdif-1 {
+ spdifm1_tx: spdifm1-tx {
+ rockchip,pins = <2 RK_PC1 2 &pcfg_pull_none>;
+ };
+ };
+
+ spdif-2 {
+ spdifm2_tx: spdifm2-tx {
+ rockchip,pins = <0 RK_PA2 2 &pcfg_pull_none>;
+ };
+ };
+
+ sdmmc0-0 {
+ sdmmc0m0_pwren: sdmmc0m0-pwren {
+ rockchip,pins = <2 RK_PA7 1 &pcfg_pull_up_4ma>;
+ };
+
+ sdmmc0m0_gpio: sdmmc0m0-gpio {
+ rockchip,pins =
+ <2 RK_PA7 RK_FUNC_GPIO &pcfg_pull_up_4ma>;
+ };
+ };
+
+ sdmmc0-1 {
+ sdmmc0m1_pwren: sdmmc0m1-pwren {
+ rockchip,pins =
+ <0 RK_PD6 3 &pcfg_pull_up_4ma>;
+ };
+
+ sdmmc0m1_gpio: sdmmc0m1-gpio {
+ rockchip,pins =
+ <0 RK_PD6 RK_FUNC_GPIO &pcfg_pull_up_4ma>;
+ };
+ };
+
+ sdmmc0 {
+ sdmmc0_clk: sdmmc0-clk {
+ rockchip,pins =
+ <1 RK_PA6 1 &pcfg_pull_none_4ma>;
+ };
+
+ sdmmc0_cmd: sdmmc0-cmd {
+ rockchip,pins = <1 RK_PA4 1 &pcfg_pull_up_4ma>;
+ };
+
+ sdmmc0_dectn: sdmmc0-dectn {
+ rockchip,pins = <1 RK_PA5 1 &pcfg_pull_up_4ma>;
+ };
+
+ sdmmc0_wrprt: sdmmc0-wrprt {
+ rockchip,pins = <1 RK_PA7 1 &pcfg_pull_up_4ma>;
+ };
+
+ sdmmc0_bus1: sdmmc0-bus1 {
+ rockchip,pins = <1 RK_PA0 1 &pcfg_pull_up_4ma>;
+ };
+
+ sdmmc0_bus4: sdmmc0-bus4 {
+ rockchip,pins = <1 RK_PA0 1 &pcfg_pull_up_4ma>,
+ <1 RK_PA1 1 &pcfg_pull_up_4ma>,
+ <1 RK_PA2 1 &pcfg_pull_up_4ma>,
+ <1 RK_PA3 1 &pcfg_pull_up_4ma>;
+ };
+
+ sdmmc0_gpio: sdmmc0-gpio {
+ rockchip,pins =
+ <1 RK_PA6 RK_FUNC_GPIO &pcfg_pull_up_4ma>,
+ <1 RK_PA4 RK_FUNC_GPIO &pcfg_pull_up_4ma>,
+ <1 RK_PA5 RK_FUNC_GPIO &pcfg_pull_up_4ma>,
+ <1 RK_PA7 RK_FUNC_GPIO &pcfg_pull_up_4ma>,
+ <1 RK_PA3 RK_FUNC_GPIO &pcfg_pull_up_4ma>,
+ <1 RK_PA2 RK_FUNC_GPIO &pcfg_pull_up_4ma>,
+ <1 RK_PA1 RK_FUNC_GPIO &pcfg_pull_up_4ma>,
+ <1 RK_PA0 RK_FUNC_GPIO &pcfg_pull_up_4ma>;
+ };
+ };
+
+ sdmmc0ext {
+ sdmmc0ext_clk: sdmmc0ext-clk {
+ rockchip,pins =
+ <3 RK_PA2 3 &pcfg_pull_none_4ma>;
+ };
+
+ sdmmc0ext_cmd: sdmmc0ext-cmd {
+ rockchip,pins = <3 RK_PA0 3 &pcfg_pull_up_4ma>;
+ };
+
+ sdmmc0ext_wrprt: sdmmc0ext-wrprt {
+ rockchip,pins = <3 RK_PA3 3 &pcfg_pull_up_4ma>;
+ };
+
+ sdmmc0ext_dectn: sdmmc0ext-dectn {
+ rockchip,pins = <3 RK_PA1 3 &pcfg_pull_up_4ma>;
+ };
+
+ sdmmc0ext_bus1: sdmmc0ext-bus1 {
+ rockchip,pins = <3 RK_PA4 3 &pcfg_pull_up_4ma>;
+ };
+
+ sdmmc0ext_bus4: sdmmc0ext-bus4 {
+ rockchip,pins =
+ <3 RK_PA4 3 &pcfg_pull_up_4ma>,
+ <3 RK_PA5 3 &pcfg_pull_up_4ma>,
+ <3 RK_PA6 3 &pcfg_pull_up_4ma>,
+ <3 RK_PA7 3 &pcfg_pull_up_4ma>;
+ };
+
+ sdmmc0ext_gpio: sdmmc0ext-gpio {
+ rockchip,pins =
+ <3 RK_PA0 RK_FUNC_GPIO &pcfg_pull_up_4ma>,
+ <3 RK_PA1 RK_FUNC_GPIO &pcfg_pull_up_4ma>,
+ <3 RK_PA2 RK_FUNC_GPIO &pcfg_pull_up_4ma>,
+ <3 RK_PA3 RK_FUNC_GPIO &pcfg_pull_up_4ma>,
+ <3 RK_PA4 RK_FUNC_GPIO &pcfg_pull_up_4ma>,
+ <3 RK_PA5 RK_FUNC_GPIO &pcfg_pull_up_4ma>,
+ <3 RK_PA6 RK_FUNC_GPIO &pcfg_pull_up_4ma>,
+ <3 RK_PA7 RK_FUNC_GPIO &pcfg_pull_up_4ma>;
+ };
+ };
+
+ sdmmc1 {
+ sdmmc1_clk: sdmmc1-clk {
+ rockchip,pins =
+ <1 RK_PB4 1 &pcfg_pull_none_8ma>;
+ };
+
+ sdmmc1_cmd: sdmmc1-cmd {
+ rockchip,pins = <1 RK_PB5 1 &pcfg_pull_up_8ma>;
+ };
+
+ sdmmc1_pwren: sdmmc1-pwren {
+ rockchip,pins = <1 RK_PC2 1 &pcfg_pull_up_8ma>;
+ };
+
+ sdmmc1_wrprt: sdmmc1-wrprt {
+ rockchip,pins = <1 RK_PC4 1 &pcfg_pull_up_8ma>;
+ };
+
+ sdmmc1_dectn: sdmmc1-dectn {
+ rockchip,pins = <1 RK_PC3 1 &pcfg_pull_up_8ma>;
+ };
+
+ sdmmc1_bus1: sdmmc1-bus1 {
+ rockchip,pins = <1 RK_PB6 1 &pcfg_pull_up_8ma>;
+ };
+
+ sdmmc1_bus4: sdmmc1-bus4 {
+ rockchip,pins = <1 RK_PB4 1 &pcfg_pull_up_8ma>,
+ <1 RK_PB5 1 &pcfg_pull_up_8ma>,
+ <1 RK_PC0 1 &pcfg_pull_up_8ma>,
+ <1 RK_PC1 1 &pcfg_pull_up_8ma>;
+ };
+
+ sdmmc1_gpio: sdmmc1-gpio {
+ rockchip,pins =
+ <1 RK_PB4 RK_FUNC_GPIO &pcfg_pull_up_4ma>,
+ <1 RK_PB5 RK_FUNC_GPIO &pcfg_pull_up_4ma>,
+ <1 RK_PB6 RK_FUNC_GPIO &pcfg_pull_up_4ma>,
+ <1 RK_PB7 RK_FUNC_GPIO &pcfg_pull_up_4ma>,
+ <1 RK_PC0 RK_FUNC_GPIO &pcfg_pull_up_4ma>,
+ <1 RK_PC1 RK_FUNC_GPIO &pcfg_pull_up_4ma>,
+ <1 RK_PC2 RK_FUNC_GPIO &pcfg_pull_up_4ma>,
+ <1 RK_PC3 RK_FUNC_GPIO &pcfg_pull_up_4ma>,
+ <1 RK_PC4 RK_FUNC_GPIO &pcfg_pull_up_4ma>;
+ };
+ };
+
+ emmc {
+ emmc_clk: emmc-clk {
+ rockchip,pins =
+ <3 RK_PC5 2 &pcfg_pull_none_12ma>;
+ };
+
+ emmc_cmd: emmc-cmd {
+ rockchip,pins =
+ <3 RK_PC3 2 &pcfg_pull_up_12ma>;
+ };
+
+ emmc_pwren: emmc-pwren {
+ rockchip,pins = <3 RK_PC6 2 &pcfg_pull_none>;
+ };
+
+ emmc_rstnout: emmc-rstnout {
+ rockchip,pins = <3 RK_PC4 2 &pcfg_pull_none>;
+ };
+
+ emmc_bus1: emmc-bus1 {
+ rockchip,pins =
+ <0 RK_PA7 2 &pcfg_pull_up_12ma>;
+ };
+
+ emmc_bus4: emmc-bus4 {
+ rockchip,pins =
+ <0 RK_PA7 2 &pcfg_pull_up_12ma>,
+ <2 RK_PD4 2 &pcfg_pull_up_12ma>,
+ <2 RK_PD5 2 &pcfg_pull_up_12ma>,
+ <2 RK_PD6 2 &pcfg_pull_up_12ma>;
+ };
+
+ emmc_bus8: emmc-bus8 {
+ rockchip,pins =
+ <0 RK_PA7 2 &pcfg_pull_up_12ma>,
+ <2 RK_PD4 2 &pcfg_pull_up_12ma>,
+ <2 RK_PD5 2 &pcfg_pull_up_12ma>,
+ <2 RK_PD6 2 &pcfg_pull_up_12ma>,
+ <2 RK_PD7 2 &pcfg_pull_up_12ma>,
+ <3 RK_PC0 2 &pcfg_pull_up_12ma>,
+ <3 RK_PC1 2 &pcfg_pull_up_12ma>,
+ <3 RK_PC2 2 &pcfg_pull_up_12ma>;
+ };
+ };
+
+ pwm0 {
+ pwm0_pin: pwm0-pin {
+ rockchip,pins = <2 RK_PA4 1 &pcfg_pull_none>;
+ };
+ };
+
+ pwm1 {
+ pwm1_pin: pwm1-pin {
+ rockchip,pins = <2 RK_PA5 1 &pcfg_pull_none>;
+ };
+ };
+
+ pwm2 {
+ pwm2_pin: pwm2-pin {
+ rockchip,pins = <2 RK_PA6 1 &pcfg_pull_none>;
+ };
+ };
+
+ pwmir {
+ pwmir_pin: pwmir-pin {
+ rockchip,pins = <2 RK_PA2 1 &pcfg_pull_none>;
+ };
+ };
+
+ gmac-1 {
+ rgmiim1_pins: rgmiim1-pins {
+ rockchip,pins =
+ /* mac_txclk */
+ <1 RK_PB4 2 &pcfg_pull_none_12ma>,
+ /* mac_rxclk */
+ <1 RK_PB5 2 &pcfg_pull_none_2ma>,
+ /* mac_mdio */
+ <1 RK_PC3 2 &pcfg_pull_none_2ma>,
+ /* mac_txen */
+ <1 RK_PD1 2 &pcfg_pull_none_12ma>,
+ /* mac_clk */
+ <1 RK_PC5 2 &pcfg_pull_none_2ma>,
+ /* mac_rxdv */
+ <1 RK_PC6 2 &pcfg_pull_none_2ma>,
+ /* mac_mdc */
+ <1 RK_PC7 2 &pcfg_pull_none_2ma>,
+ /* mac_rxd1 */
+ <1 RK_PB2 2 &pcfg_pull_none_2ma>,
+ /* mac_rxd0 */
+ <1 RK_PB3 2 &pcfg_pull_none_2ma>,
+ /* mac_txd1 */
+ <1 RK_PB0 2 &pcfg_pull_none_12ma>,
+ /* mac_txd0 */
+ <1 RK_PB1 2 &pcfg_pull_none_12ma>,
+ /* mac_rxd3 */
+ <1 RK_PB6 2 &pcfg_pull_none_2ma>,
+ /* mac_rxd2 */
+ <1 RK_PB7 2 &pcfg_pull_none_2ma>,
+ /* mac_txd3 */
+ <1 RK_PC0 2 &pcfg_pull_none_12ma>,
+ /* mac_txd2 */
+ <1 RK_PC1 2 &pcfg_pull_none_12ma>,
+
+ /* mac_txclk */
+ <0 RK_PB0 1 &pcfg_pull_none>,
+ /* mac_txen */
+ <0 RK_PB4 1 &pcfg_pull_none>,
+ /* mac_clk */
+ <0 RK_PD0 1 &pcfg_pull_none>,
+ /* mac_txd1 */
+ <0 RK_PC0 1 &pcfg_pull_none>,
+ /* mac_txd0 */
+ <0 RK_PC1 1 &pcfg_pull_none>,
+ /* mac_txd3 */
+ <0 RK_PC7 1 &pcfg_pull_none>,
+ /* mac_txd2 */
+ <0 RK_PC6 1 &pcfg_pull_none>;
+ };
+
+ rmiim1_pins: rmiim1-pins {
+ rockchip,pins =
+ /* mac_mdio */
+ <1 RK_PC3 2 &pcfg_pull_none_2ma>,
+ /* mac_txen */
+ <1 RK_PD1 2 &pcfg_pull_none_12ma>,
+ /* mac_clk */
+ <1 RK_PC5 2 &pcfg_pull_none_2ma>,
+ /* mac_rxer */
+ <1 RK_PD0 2 &pcfg_pull_none_2ma>,
+ /* mac_rxdv */
+ <1 RK_PC6 2 &pcfg_pull_none_2ma>,
+ /* mac_mdc */
+ <1 RK_PC7 2 &pcfg_pull_none_2ma>,
+ /* mac_rxd1 */
+ <1 RK_PB2 2 &pcfg_pull_none_2ma>,
+ /* mac_rxd0 */
+ <1 RK_PB3 2 &pcfg_pull_none_2ma>,
+ /* mac_txd1 */
+ <1 RK_PB0 2 &pcfg_pull_none_12ma>,
+ /* mac_txd0 */
+ <1 RK_PB1 2 &pcfg_pull_none_12ma>,
+
+ /* mac_mdio */
+ <0 RK_PB3 1 &pcfg_pull_none>,
+ /* mac_txen */
+ <0 RK_PB4 1 &pcfg_pull_none>,
+ /* mac_clk */
+ <0 RK_PD0 1 &pcfg_pull_none>,
+ /* mac_mdc */
+ <0 RK_PC3 1 &pcfg_pull_none>,
+ /* mac_txd1 */
+ <0 RK_PC0 1 &pcfg_pull_none>,
+ /* mac_txd0 */
+ <0 RK_PC1 1 &pcfg_pull_none>;
+ };
+ };
+
+ gmac2phy {
+ fephyled_speed100: fephyled-speed100 {
+ rockchip,pins = <0 RK_PD7 1 &pcfg_pull_none>;
+ };
+
+ fephyled_speed10: fephyled-speed10 {
+ rockchip,pins = <0 RK_PD6 1 &pcfg_pull_none>;
+ };
+
+ fephyled_duplex: fephyled-duplex {
+ rockchip,pins = <0 RK_PD6 2 &pcfg_pull_none>;
+ };
+
+ fephyled_rxm0: fephyled-rxm0 {
+ rockchip,pins = <0 RK_PD5 1 &pcfg_pull_none>;
+ };
+
+ fephyled_txm0: fephyled-txm0 {
+ rockchip,pins = <0 RK_PD5 2 &pcfg_pull_none>;
+ };
+
+ fephyled_linkm0: fephyled-linkm0 {
+ rockchip,pins = <0 RK_PD4 1 &pcfg_pull_none>;
+ };
+
+ fephyled_rxm1: fephyled-rxm1 {
+ rockchip,pins = <2 RK_PD1 2 &pcfg_pull_none>;
+ };
+
+ fephyled_txm1: fephyled-txm1 {
+ rockchip,pins = <2 RK_PD1 3 &pcfg_pull_none>;
+ };
+
+ fephyled_linkm1: fephyled-linkm1 {
+ rockchip,pins = <2 RK_PD0 2 &pcfg_pull_none>;
+ };
+ };
+
+ tsadc_pin {
+ tsadc_int: tsadc-int {
+ rockchip,pins = <2 RK_PB5 2 &pcfg_pull_none>;
+ };
+ tsadc_gpio: tsadc-gpio {
+ rockchip,pins =
+ <2 RK_PB5 RK_FUNC_GPIO &pcfg_pull_none>;
+ };
+ };
+
+ hdmi_pin {
+ hdmi_cec: hdmi-cec {
+ rockchip,pins = <0 RK_PA3 1 &pcfg_pull_none>;
+ };
+
+ hdmi_hpd: hdmi-hpd {
+ rockchip,pins = <0 RK_PA4 1 &pcfg_pull_down>;
+ };
+ };
+
+ cif-0 {
+ dvp_d2d9_m0:dvp-d2d9-m0 {
+ rockchip,pins =
+ /* cif_d0 */
+ <3 RK_PA4 2 &pcfg_pull_none>,
+ /* cif_d1 */
+ <3 RK_PA5 2 &pcfg_pull_none>,
+ /* cif_d2 */
+ <3 RK_PA6 2 &pcfg_pull_none>,
+ /* cif_d3 */
+ <3 RK_PA7 2 &pcfg_pull_none>,
+ /* cif_d4 */
+ <3 RK_PB0 2 &pcfg_pull_none>,
+ /* cif_d5m0 */
+ <3 RK_PB1 2 &pcfg_pull_none>,
+ /* cif_d6m0 */
+ <3 RK_PB2 2 &pcfg_pull_none>,
+ /* cif_d7m0 */
+ <3 RK_PB3 2 &pcfg_pull_none>,
+ /* cif_href */
+ <3 RK_PA1 2 &pcfg_pull_none>,
+ /* cif_vsync */
+ <3 RK_PA0 2 &pcfg_pull_none>,
+ /* cif_clkoutm0 */
+ <3 RK_PA3 2 &pcfg_pull_none>,
+ /* cif_clkin */
+ <3 RK_PA2 2 &pcfg_pull_none>;
+ };
+ };
+
+ cif-1 {
+ dvp_d2d9_m1:dvp-d2d9-m1 {
+ rockchip,pins =
+ /* cif_d0 */
+ <3 RK_PA4 2 &pcfg_pull_none>,
+ /* cif_d1 */
+ <3 RK_PA5 2 &pcfg_pull_none>,
+ /* cif_d2 */
+ <3 RK_PA6 2 &pcfg_pull_none>,
+ /* cif_d3 */
+ <3 RK_PA7 2 &pcfg_pull_none>,
+ /* cif_d4 */
+ <3 RK_PB0 2 &pcfg_pull_none>,
+ /* cif_d5m1 */
+ <2 RK_PC0 4 &pcfg_pull_none>,
+ /* cif_d6m1 */
+ <2 RK_PC1 4 &pcfg_pull_none>,
+ /* cif_d7m1 */
+ <2 RK_PC2 4 &pcfg_pull_none>,
+ /* cif_href */
+ <3 RK_PA1 2 &pcfg_pull_none>,
+ /* cif_vsync */
+ <3 RK_PA0 2 &pcfg_pull_none>,
+ /* cif_clkoutm1 */
+ <2 RK_PB7 4 &pcfg_pull_none>,
+ /* cif_clkin */
+ <3 RK_PA2 2 &pcfg_pull_none>;
+ };
+ };
+ };
+};
--
1.9.1
^ permalink raw reply related
* [PATCH v4 3/6] dt-bindings: soc: rockchip: grf: add support for rk3328
From: cl-TNX95d0MmH7DzftRWevZcw @ 2017-03-27 9:40 UTC (permalink / raw)
To: heiko-4mtYJXux2i+zQB+pC5nmwQ
Cc: mark.rutland-5wv7dgnIgG8, wsa-z923LK4zBo2bacvFa/9K2g,
linux-iio-u79uwXL29TY76Z2rM5mHXA, catalin.marinas-5wv7dgnIgG8,
shawn.lin-TNX95d0MmH7DzftRWevZcw, will.deacon-5wv7dgnIgG8,
kever.yang-TNX95d0MmH7DzftRWevZcw,
dianders-F7+t8E8rja9g9hUCZPvPmw,
yamada.masahiro-uWyLwvC0a2jby3iVrkZq2A,
tony.xie-TNX95d0MmH7DzftRWevZcw, linux-i2c-u79uwXL29TY76Z2rM5mHXA,
pmeerw-jW+XmwGofnusTnJN9+BGXg, lars-Qo5EllUWu/uELgA04lAiVw,
zhengxing-TNX95d0MmH7DzftRWevZcw, khilman-rdvid1DuHRBWk0Htik3J/w,
linux-rockchip-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
jay.xu-TNX95d0MmH7DzftRWevZcw, Liang Chen,
wxt-TNX95d0MmH7DzftRWevZcw, huangtao-TNX95d0MmH7DzftRWevZcw,
devicetree-u79uwXL29TY76Z2rM5mHXA,
zhangqing-TNX95d0MmH7DzftRWevZcw,
paweljarosz3691-Re5JQEeQqe8AvxtiuMwx3w, arnd-r2nGTMty4D4,
yhx-TNX95d0MmH7DzftRWevZcw, knaack.h-Mmb7MZpHnFY,
robh+dt-DgEjT+Ai2ygdnm+yROfE0A,
matthias.bgg-Re5JQEeQqe8AvxtiuMwx3w,
rocky.hao-TNX95d0MmH7DzftRWevZcw,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
david.wu-TNX95d0MmH7DzftRWevZcw, fabio.estevam-3arQi8VN3Tc,
andy.yan-TNX95d0MmH7DzftRWevZcw,
akpm-de/tnXTf+JLsfHDXvbKv3WD2FQJk+8+b,
shawnguo-DgEjT+Ai2ygdnm+yROfE0A
In-Reply-To: <1490607650-18650-1-git-send-email-cl-TNX95d0MmH7DzftRWevZcw@public.gmane.org>
From: Liang Chen <cl-TNX95d0MmH7DzftRWevZcw@public.gmane.org>
Signed-off-by: Liang Chen <cl-TNX95d0MmH7DzftRWevZcw@public.gmane.org>
Acked-by: Rob Herring <robh-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
---
Documentation/devicetree/bindings/soc/rockchip/grf.txt | 1 +
1 file changed, 1 insertion(+)
diff --git a/Documentation/devicetree/bindings/soc/rockchip/grf.txt b/Documentation/devicetree/bindings/soc/rockchip/grf.txt
index a0685c2..de8b983 100644
--- a/Documentation/devicetree/bindings/soc/rockchip/grf.txt
+++ b/Documentation/devicetree/bindings/soc/rockchip/grf.txt
@@ -16,6 +16,7 @@ Required Properties:
- "rockchip,rk3188-grf", "syscon": for rk3188
- "rockchip,rk3228-grf", "syscon": for rk3228
- "rockchip,rk3288-grf", "syscon": for rk3288
+ - "rockchip,rk3328-grf", "syscon": for rk3328
- "rockchip,rk3368-grf", "syscon": for rk3368
- "rockchip,rk3399-grf", "syscon": for rk3399
- compatible: PMUGRF should be one of the following:
--
1.9.1
^ permalink raw reply related
* Re: [PATCH v5 3/7] regulator: rk808: Add regulator driver for RK805
From: Mark Brown @ 2017-03-27 9:40 UTC (permalink / raw)
To: Elaine Zhang
Cc: huangtao-TNX95d0MmH7DzftRWevZcw, mark.rutland-5wv7dgnIgG8,
devicetree-u79uwXL29TY76Z2rM5mHXA, xxx-TNX95d0MmH7DzftRWevZcw,
lgirdwood-Re5JQEeQqe8AvxtiuMwx3w,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-rockchip-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
robh+dt-DgEjT+Ai2ygdnm+yROfE0A, w.egorov-guT5V/WYfQezQB+pC5nmwQ,
lee.jones-QSEj5FYQhm4dnm+yROfE0A, chenjh-TNX95d0MmH7DzftRWevZcw
In-Reply-To: <1490595705-28844-4-git-send-email-zhangqing-TNX95d0MmH7DzftRWevZcw@public.gmane.org>
[-- Attachment #1.1: Type: text/plain, Size: 351 bytes --]
On Mon, Mar 27, 2017 at 02:21:41PM +0800, Elaine Zhang wrote:
> Add support for the rk805 regulator. The regulator module consists
> of 4 DCDCs, 3 LDOs.
>
> The output voltages are configurable and are meant to supply power
> to the main processor and other components.
Acked-by: Mark Brown <broonie-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
[-- Attachment #2: Type: text/plain, Size: 200 bytes --]
_______________________________________________
Linux-rockchip mailing list
Linux-rockchip-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org
http://lists.infradead.org/mailman/listinfo/linux-rockchip
^ permalink raw reply
* [PATCH v4 1/6] dt-bindings: iio: rockchip-saradc: add support for rk3328
From: cl @ 2017-03-27 9:40 UTC (permalink / raw)
To: heiko
Cc: mark.rutland, wsa, linux-iio, catalin.marinas, shawn.lin,
will.deacon, kever.yang, dianders, yamada.masahiro, tony.xie,
linux-i2c, pmeerw, lars, zhengxing, khilman, linux-rockchip,
jay.xu, Liang Chen, wxt, huangtao, devicetree, zhangqing,
paweljarosz3691, arnd, yhx, knaack.h, robh+dt, matthias.bgg,
rocky.hao, linux-arm-kernel, linux-kernel, david.wu,
fabio.estevam, andy.yan, akpm, shawnguo
In-Reply-To: <1490607650-18650-1-git-send-email-cl@rock-chips.com>
From: Liang Chen <cl@rock-chips.com>
The rk3328 saradc is the same as rk3399.
Signed-off-by: Liang Chen <cl@rock-chips.com>
Reviewed-by: Heiko Stuebner <heiko@sntech.de>
Acked-by: Rob Herring <robh@kernel.org>
---
Documentation/devicetree/bindings/iio/adc/rockchip-saradc.txt | 1 +
1 file changed, 1 insertion(+)
diff --git a/Documentation/devicetree/bindings/iio/adc/rockchip-saradc.txt b/Documentation/devicetree/bindings/iio/adc/rockchip-saradc.txt
index 205593f..e0a9b9d 100644
--- a/Documentation/devicetree/bindings/iio/adc/rockchip-saradc.txt
+++ b/Documentation/devicetree/bindings/iio/adc/rockchip-saradc.txt
@@ -4,6 +4,7 @@ Required properties:
- compatible: should be "rockchip,<name>-saradc" or "rockchip,rk3066-tsadc"
- "rockchip,saradc": for rk3188, rk3288
- "rockchip,rk3066-tsadc": for rk3036
+ - "rockchip,rk3328-saradc", "rockchip,rk3399-saradc": for rk3328
- "rockchip,rk3399-saradc": for rk3399
- reg: physical base address of the controller and length of memory mapped
--
1.9.1
^ permalink raw reply related
* [PATCH v4 0/6] initialize dtsi file and dts file for RK3328 SoCs
From: cl @ 2017-03-27 9:40 UTC (permalink / raw)
To: heiko
Cc: mark.rutland, wsa, linux-iio, catalin.marinas, shawn.lin,
will.deacon, kever.yang, dianders, yamada.masahiro, tony.xie,
linux-i2c, pmeerw, lars, zhengxing, khilman, linux-rockchip,
jay.xu, Liang Chen, wxt, huangtao, devicetree, zhangqing,
paweljarosz3691, arnd, yhx, knaack.h, robh+dt, matthias.bgg,
rocky.hao, linux-arm-kernel, linux-kernel, david.wu,
fabio.estevam, andy.yan, akpm, shawnguo
From: Liang Chen <cl@rock-chips.com>
Changes in v4:
Remove some assigned-clocks as they should be inited in their
respective device nodes.
Changes in v3:
Adjust some descriptions in dtsi.
Changes in v2:
Remove RK_FUNC_* in dtsi as it dose not help understand things better.
Adjust the order of description in dt-bindings.
v1:
These patchs depend on pinctrl patchs as below:
https://patchwork.kernel.org/patch/9566427/
https://patchwork.kernel.org/patch/9566425/
https://patchwork.kernel.org/patch/9566431/
Liang Chen (6):
dt-bindings: iio: rockchip-saradc: add support for rk3328
dt-bindings: i2c: rk3x: add support for rk3328
dt-bindings: soc: rockchip: grf: add support for rk3328
arm64: dts: rockchip: add core dtsi file for RK3328 SoCs
arm64: dts: rockchip: add dts file for RK3328
dt-bindings: document rockchip rk3328-evb board
Documentation/devicetree/bindings/arm/rockchip.txt | 4 +
Documentation/devicetree/bindings/i2c/i2c-rk3x.txt | 1 +
.../bindings/iio/adc/rockchip-saradc.txt | 1 +
.../devicetree/bindings/soc/rockchip/grf.txt | 1 +
arch/arm64/boot/dts/rockchip/Makefile | 1 +
arch/arm64/boot/dts/rockchip/rk3328-evb.dts | 57 +
arch/arm64/boot/dts/rockchip/rk3328.dtsi | 1275 ++++++++++++++++++++
7 files changed, 1340 insertions(+)
create mode 100644 arch/arm64/boot/dts/rockchip/rk3328-evb.dts
create mode 100644 arch/arm64/boot/dts/rockchip/rk3328.dtsi
--
1.9.1
^ permalink raw reply
* Re: [PATCH v2 3/7] pinctrl: armada-37xx: Add pin controller support for Armada 37xx
From: Linus Walleij @ 2017-03-27 9:26 UTC (permalink / raw)
To: Gregory CLEMENT
Cc: Thomas Petazzoni, Andrew Lunn, Jason Cooper,
devicetree@vger.kernel.org, linux-kernel@vger.kernel.org,
Nadav Haklai, linux-gpio@vger.kernel.org, Rob Herring,
Neta Zur Hershkovits, Victor Gu, Hua Jing, Marcin Wojtas,
Wilson Ding, linux-arm-kernel@lists.infradead.org,
Sebastian Hesselbarth
In-Reply-To: <087ef357fa23193d135d37ec2206a5798d27aab5.1490120798.git-series.gregory.clement@free-electrons.com>
On Tue, Mar 21, 2017 at 7:28 PM, Gregory CLEMENT
<gregory.clement@free-electrons.com> wrote:
> The Armada 37xx SoC come with 2 pin controllers: one on the south
> bridge (managing 28 pins) and one on the north bridge (managing 36 pins).
>
> At the hardware level the controller configure the pins by group and not
> pin by pin. This constraint is reflected in the design of the driver:
> only the group related functions are implemented.
Interesting!
> +static int armada_37xx_pmx_direction_input(struct armada_37xx_pinctrl *info,
> + unsigned int offset)
> +{
> + unsigned int reg = OUTPUT_EN;
> + unsigned int mask;
> +
> + if (offset >= GPIO_PER_REG) {
> + offset -= GPIO_PER_REG;
> + reg += sizeof(u32);
> + }
> + mask = BIT(offset);
> +
> + return regmap_update_bits(info->regmap, reg, mask, 0);
> +}
> +
> +
> +
A bit of excess whitespace, OK nitpicking.
Then this stuff:
> +static int armada_37xx_add_function(struct armada_37xx_pmx_func *funcs,
> + int *funcsize, const char *name)
> +{
> + int i = 0;
> +
> + if (*funcsize <= 0)
> + return -EOVERFLOW;
> +
> + while (funcs->ngroups) {
> + /* function already there */
> + if (strcmp(funcs->name, name) == 0) {
> + funcs->ngroups++;
> +
> + return -EEXIST;
> + }
> + funcs++;
> + i++;
> + }
> +
> + /* append new unique function */
> + funcs->name = name;
> + funcs->ngroups = 1;
> + (*funcsize)--;
> +
> + return 0;
> +}
> +
> +static int armada_37xx_fill_group(struct armada_37xx_pinctrl *info, int base)
> +{
> + int n, num = 0, funcsize = info->data->nr_pins;
> +
> + for (n = 0; n < info->ngroups; n++) {
> + struct armada_37xx_pin_group *grp = &info->groups[n];
> + int i, j, f;
> +
> + grp->pins = devm_kzalloc(info->dev,
> + (grp->npins + grp->extra_npins) *
> + sizeof(*grp->pins), GFP_KERNEL);
> + if (!grp->pins)
> + return -ENOMEM;
> +
> + for (i = 0; i < grp->npins; i++)
> + grp->pins[i] = grp->start_pin + base + i;
> +
> + for (j = 0; j < grp->extra_npins; j++)
> + grp->pins[i+j] = grp->extra_pin + base + j;
> +
> + for (f = 0; f < NB_FUNCS; f++) {
> + int ret;
> + /* check for unique functions and count groups */
> + ret = armada_37xx_add_function(info->funcs, &funcsize,
> + grp->funcs[f]);
> + if (ret == -EOVERFLOW)
> + dev_err(info->dev,
> + "More functions than pins(%d)\n",
> + info->data->nr_pins);
> + if (ret < 0)
> + continue;
> + num++;
> + }
> + }
> +
> + info->nfuncs = num;
> +
> + return 0;
> +}
> +
> +static int armada_37xx_fill_func(struct armada_37xx_pinctrl *info)
> +{
> + struct armada_37xx_pmx_func *funcs = info->funcs;
> + int n;
> +
> + for (n = 0; n < info->nfuncs; n++) {
> + const char *name = funcs[n].name;
> + const char **groups;
> + int g;
> +
> + funcs[n].groups = devm_kzalloc(info->dev, funcs[n].ngroups *
> + sizeof(*(funcs[n].groups)),
> + GFP_KERNEL);
> + if (!funcs[n].groups)
> + return -ENOMEM;
> +
> + groups = funcs[n].groups;
> +
> + for (g = 0; g < info->ngroups; g++) {
> + struct armada_37xx_pin_group *gp = &info->groups[g];
> + int f;
> +
> + for (f = 0; f < NB_FUNCS; f++) {
> + if (strcmp(gp->funcs[f], name) == 0) {
> + *groups = gp->name;
> + groups++;
> + }
> + }
> + }
> + }
> + return 0;
> +}
I would be happy if you add kerneldoc to these functions and explain
what they do. Because I don't get it. I guess they are filling in the data
structures but yeah. Hard to follow.
> + match = of_match_node(armada_37xx_pinctrl_of_match, np);
> + info->data = (struct armada_37xx_pin_data *)match->data;
Use of_device_get_match_data()
> +static struct platform_driver armada_37xx_pinctrl_driver = {
> + .driver = {
> + .name = "armada-37xx-pinctrl",
> + .of_match_table = armada_37xx_pinctrl_of_match,
> + },
> + .probe = armada_37xx_pinctrl_probe,
> +};
> +
> +builtin_platform_driver(armada_37xx_pinctrl_driver);
It almost looks like your could use builting_platform_driver_probe() actually,
and tag the costly initfunctions with __init so they get dicarded after probe.
Yours,
Linus Walleij
^ permalink raw reply
* Re: [PATCH v2 1/7] pinctrl: dt-bindings: Add documentation for Armada 37xx pin controllers
From: Linus Walleij @ 2017-03-27 9:18 UTC (permalink / raw)
To: Gregory CLEMENT
Cc: Thomas Petazzoni, Andrew Lunn, Jason Cooper,
devicetree@vger.kernel.org, linux-kernel@vger.kernel.org,
Nadav Haklai, linux-gpio@vger.kernel.org, Rob Herring,
Neta Zur Hershkovits, Victor Gu, Hua Jing, Marcin Wojtas,
Wilson Ding, linux-arm-kernel@lists.infradead.org,
Sebastian Hesselbarth
In-Reply-To: <2dc869315a1b6bcc6d7eedd67b9ea8c0483b9789.1490120798.git-series.gregory.clement@free-electrons.com>
On Tue, Mar 21, 2017 at 7:28 PM, Gregory CLEMENT
<gregory.clement@free-electrons.com> wrote:
> Document the device tree binding for the pin controllers found on the
> Armada 37xx SoCs.
>
> Update the binding documention of the xtal clk which is a subnode of this
> syscon node.
>
> Signed-off-by: Gregory CLEMENT <gregory.clement@free-electrons.com>
These look all right to me, but let's see what the DT people say.
This business with a subnode named "gpio-controller" that the code is
checking for is not in the bindings or examples, is this part of the old
Armada bindings?
Yours,
Linus Walleij
^ permalink raw reply
* Re: [PATCH v2 5/7] pinctrl: aramda-37xx: Add irqchip support
From: Linus Walleij @ 2017-03-27 9:15 UTC (permalink / raw)
To: Gregory CLEMENT
Cc: Thomas Petazzoni, Andrew Lunn, Jason Cooper,
devicetree@vger.kernel.org, linux-kernel@vger.kernel.org,
Nadav Haklai, linux-gpio@vger.kernel.org, Rob Herring,
Neta Zur Hershkovits, Victor Gu, Hua Jing, Marcin Wojtas,
Wilson Ding, linux-arm-kernel@lists.infradead.org,
Sebastian Hesselbarth
In-Reply-To: <0e60fccd7913b83ee53d2921ce8f297927e8b6f3.1490120798.git-series.gregory.clement@free-electrons.com>
On Tue, Mar 21, 2017 at 7:28 PM, Gregory CLEMENT
<gregory.clement@free-electrons.com> wrote:
> The Armada 37xx SoCs can handle interrupt through GPIO. However it can
> only manage the edge ones.
>
> The way the interrupt are managed are classical so we can use the generic
> interrupt chip model.
>
> The only unusual "feature" is that many interrupts are connected to the
> parent interrupt controller. But we do not take advantage of this and use
> the chained irq with all of them.
>
> Signed-off-by: Gregory CLEMENT <gregory.clement@free-electrons.com>
You need something in your Kconfig
doing select GPIOLIB_IRQCHIP unless there is
something I miss here.
> +#define IRQ_EN 0x0
> +#define IRQ_POL 0x08
> +#define IRQ_STATUS 0x10
This just cries out to me that there is a register 0x0c
and I bet it handles edges vs levels so you could also implement
level IRQs. Am I right?
> - aramda_37xx_update_reg(®, offset);
> + armada_37xx_update_reg(®, offset);
(...)
> - aramda_37xx_update_reg(®, offset);
> + armada_37xx_update_reg(®, offset);
These spelling fixes, do not do them in this patch, fix the first
patch adding them
instead. It's super-confusing. Applies everywhere.
> +static void armada_37xx_irq_handler(struct irq_desc *desc)
> +{
> + struct gpio_chip *gc = irq_desc_get_handler_data(desc);
> + struct irq_chip *chip = irq_desc_get_chip(desc);
> + struct armada_37xx_pinctrl *info = gpiochip_get_data(gc);
> + struct irq_domain *d = gc->irqdomain;
> + int i;
> +
> + chained_irq_enter(chip, desc);
> + for (i = 0; i <= d->revmap_size / GPIO_PER_REG; i++) {
> + u32 status;
> + unsigned long flags;
> +
> + spin_lock_irqsave(&info->irq_lock, flags);
> + status = readl_relaxed(info->base + IRQ_STATUS + 4 * i);
> + /* Manage only the interrupt that was enabled */
> + status &= readl_relaxed(info->base + IRQ_EN + 4 * i);
> + spin_unlock_irqrestore(&info->irq_lock, flags);
> + while (status) {
> + u32 hwirq = ffs(status) - 1;
> + u32 virq = irq_linear_revmap(d, hwirq +
> + i * GPIO_PER_REG);
Use irq_find_mapping() instead please.
> + generic_handle_irq(virq);
> + status &= ~(1 << hwirq);
Why not status &= ~BIT(hwirq);
> + }
> + }
> + chained_irq_exit(chip, desc);
Apart from that nice, it re-reads status on every iteration which is
good.
> +static int armada_37xx_irqchip_register(struct platform_device *pdev,
> + struct armada_37xx_pinctrl *info)
> +{
> + struct device_node *np = info->dev->of_node;
> + int nrirqs = info->data->nr_pins;
> + struct gpio_chip *gc = &info->gpio_chip;
> + struct irq_chip *irqchip = &info->irq_chip;
> + struct resource res;
> + int ret, i, nr_irq_parent;
> +
> + for_each_child_of_node(info->dev->of_node, np) {
> + if (of_find_property(np, "gpio-controller", NULL)) {
> + ret = 0;
> + break;
> + }
> + };
Now there is this thing again looping over the nodes.
> + if (ret)
> + return ret;
ret may be used uninitialized here, if you loop over all nodes
and do not find any "gpio-controller".
The static code checks will just scream about this.
(Please fix in the other patch as well if present there.)
> + nr_irq_parent = of_irq_count(np);
> + spin_lock_init(&info->irq_lock);
> +
> + if (!nr_irq_parent) {
> + dev_err(&pdev->dev, "Invalid or no IRQ\n");
> + return 0;
> + }
What if it is > 1? That doesn't seem to work but will pass this
check silently.
> + ret = gpiochip_irqchip_add(gc, irqchip, 0,
> + handle_level_irq, IRQ_TYPE_NONE);
If you also set up the handler in .set_type() you can assign
handle_bad_irq() here and let .set_type set the right handler
as e.g. drivers/gpio/gpio-pl061.c.
> + for (i = 0; i < nrirqs; i++) {
> + struct irq_data *d = irq_get_irq_data(gc->irq_base + i);
> +
> + d->mask = 1 << (i % GPIO_PER_REG);
> + }
What is this? It looks like a big hack. At least put in a fat
comment about what is going on and why.
> + for (i = 0; i < nr_irq_parent; i++) {
> + int irq = irq_of_parse_and_map(np, i);
I think gpiochip_irqchip_add() will do this for you already,
as it calls irq_create_mapping() for all offsets which will call
irq_of_parse_and_map() am I right?
> +
> + if (irq < 0)
> + continue;
> +
> + gpiochip_set_chained_irqchip(gc, irqchip, irq,
> + armada_37xx_irq_handler);
> + }
So only this statement for each IRQ should be all right.
I think this driver needs a bit of tinkering and refining.
Yours,
Linus Walleij
^ permalink raw reply
* Re: [PATCH v2 1/5] dt-bindings: update device tree binding for Allwinner PRCM CCUs
From: Icenowy Zheng @ 2017-03-27 9:11 UTC (permalink / raw)
To: Maxime Ripard
Cc: Icenowy Zheng, Rob Herring, linux-kernel, linux-arm-kernel,
linux-sunxi, devicetree, Chen-Yu Tsai
2017年3月26日 21:10于 Maxime Ripard <maxime.ripard@free-electrons.com>写道：
>
> On Thu, Mar 23, 2017 at 07:17:03AM +0800, Icenowy Zheng wrote:
> >
> >
> > 23.03.2017, 04:09, "Maxime Ripard" <maxime.ripard@free-electrons.com>:
> > > On Wed, Mar 22, 2017 at 02:22:22AM +0800, Icenowy Zheng wrote:
> > >> 21.03.2017, 15:41, "Maxime Ripard" <maxime.ripard@free-electrons.com>:
> > >> > On Thu, Mar 16, 2017 at 01:28:04AM +0800, Icenowy Zheng wrote:
> > >> >> Many Allwinner SoCs after A31 have a CCU in PRCM block.
> > >> >>
> > >> >> Give the ones on H3 and A64 compatible strings.
> > >> >>
> > >> >> Signed-off-by: Icenowy Zheng <icenowy@aosc.xyz>
> > >> >> ---
> > >> >> Changes in v2:
> > >> >> - Add iosc for R_CCU's on H3/A64. (A31, A23 and A33 seem to have different
> > >> >> clock for mux 3 of ar100 clk. Investgations are needed for them.)
> > >> >>
> > >> >> Documentation/devicetree/bindings/clock/sunxi-ccu.txt | 18 +++++++++++++++++-
> > >> >> 1 file changed, 17 insertions(+), 1 deletion(-)
> > >> >>
> > >> >> diff --git a/Documentation/devicetree/bindings/clock/sunxi-ccu.txt b/Documentation/devicetree/bindings/clock/sunxi-ccu.txt
> > >> >> index 68512aa398a9..4a4addff595d 100644
> > >> >> --- a/Documentation/devicetree/bindings/clock/sunxi-ccu.txt
> > >> >> +++ b/Documentation/devicetree/bindings/clock/sunxi-ccu.txt
> > >> >> @@ -7,9 +7,11 @@ Required properties :
> > >> >> - "allwinner,sun8i-a23-ccu"
> > >> >> - "allwinner,sun8i-a33-ccu"
> > >> >> - "allwinner,sun8i-h3-ccu"
> > >> >> + - "allwinner,sun8i-h3-r-ccu"
> > >> >> - "allwinner,sun8i-v3s-ccu"
> > >> >> - "allwinner,sun9i-a80-ccu"
> > >> >> - "allwinner,sun50i-a64-ccu"
> > >> >> + - "allwinner,sun50i-a64-r-ccu"
> > >> >> - "allwinner,sun50i-h5-ccu"
> > >> >>
> > >> >> - reg: Must contain the registers base address and length
> > >> >> @@ -20,7 +22,11 @@ Required properties :
> > >> >> - #clock-cells : must contain 1
> > >> >> - #reset-cells : must contain 1
> > >> >>
> > >> >> -Example:
> > >> >> +For the PRCM CCUs on H3/A64, one more clock is needed:
> > >> >> +- "iosc": another frequency oscillator used for CPUS (usually at 32000Hz,
> > >> >> + not the same with losc)
> > >> >
> > >> > This is called the internal oscillator in the datasheet, it would
> > >> > probably make more sense to call it that way in the documentation too.
> > >> >
> > >> > This oscillator seems to be clocked at 16MHz, so we should represent
> > >> > it as such.
> > >> >
> > >> > And I'm wondering, are you *sure* that it's fed directly from the
> > >> > internal oscillator, or goes through the registers in the RTC, with
> > >> > the 32 divider and 16 prescaler by default that makes it at roughly
> > >> > the same rate (31.25kHz).
> > >>
> > >> In fact I know nothing about it -- I only represented the code in BSP
> > >> clock driver.
> > >>
> > >> The mux value 3 varies from SoC to SoC. For A64/H5 it's 32000,
> > >> for A33 it's 667000 (seems to be directly the internal OSC, as the
> > >> user manual says the internal OSC is 600~700kHz; but it's named
> > >> cpuosc rather than iosc in A33 BSP clock driver); for A80 it's even
> > >> PLL_AUDIO.
> > >
> > > Where are you getting those info from?
> > >
> > > As far as I know, the A33 PRCM takes the hosc, losc, pll6 and CPU
> > > (internal) oscillator:
> > > https://github.com/allwinner-zh/linux-3.4-sunxi/blob/master/drivers/clk/sunxi/clk-sun8iw5.c#L508
> > >
> > > The H3 takes the hosc and losc:
> > > https://github.com/allwinner-zh/linux-3.4-sunxi/blob/master/drivers/clk/sunxi/clk-sun8iw7.c#L379
> > >
> > > The A80 takes the hosc and losc:
> > > https://github.com/allwinner-zh/linux-3.4-sunxi/blob/master/drivers/clk/sunxi/clk-sun9iw1.c#L281
> > >
> > > The A64 takes the hosc, losc, pll-periph0 and the iosc, which indeed
> > > seems to be fed from the internal oscillator with the divider in the
> > > RTC:
> > > https://github.com/longsleep/linux-pine64/blob/lichee-dev-v3.10.65-bsp2.0/arch/arm64/boot/dts/sun50iw1p1-clk.dtsi#L19
> > > https://github.com/longsleep/linux-pine64/blob/lichee-dev-v3.10.65-bsp2.0/drivers/clk/sunxi/clk-sun50iw1.c#L603
> >
> > But then in sunxi_init_clocks function, the iosc clock is initialized
> > as a fixed clock with 32000Hz.
> >
> > The clock node in BSP device tree have a compatible of
> > allwinner,fixed-clock, but not fixed-clock, which makes it not able
> > to be really probed.
>
> That clock is registered:
> https://github.com/longsleep/linux-pine64/blob/lichee-dev-v3.10.65-bsp2.0/drivers/clk/sunxi/clk-sun50iw1.c#L1193
>
Oh yes, but conflicts exist between the iosc registered in clk-sun50iw1.c and described in sun50iw1p1-clk.dtsi . The former is 32000, and the latter is 16000000.
What should we do then?
(Maybe it will be better to temporarily ignore this mux, as it's difficult to finally find out this correct mux...)
> Maxime
>
> --
> Maxime Ripard, Free Electrons
> Embedded Linux and Kernel engineering
> http://free-electrons.com
^ permalink raw reply
* Re: [PATCH v2 1/5] dt-bindings: update device tree binding for Allwinner PRCM CCUs
From: Icenowy Zheng @ 2017-03-27 9:11 UTC (permalink / raw)
To: Maxime Ripard
Cc: Icenowy Zheng, Rob Herring, linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-sunxi-/JYPxA39Uh5TLH3MbocFFw,
devicetree-u79uwXL29TY76Z2rM5mHXA, Chen-Yu Tsai
2017年3月26日 21:10于 Maxime Ripard <maxime.ripard-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org>写道：
>
> On Thu, Mar 23, 2017 at 07:17:03AM +0800, Icenowy Zheng wrote:
> >
> >
> > 23.03.2017, 04:09, "Maxime Ripard" <maxime.ripard-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org>:
> > > On Wed, Mar 22, 2017 at 02:22:22AM +0800, Icenowy Zheng wrote:
> > >> 21.03.2017, 15:41, "Maxime Ripard" <maxime.ripard@free-electrons.com>:
> > >> > On Thu, Mar 16, 2017 at 01:28:04AM +0800, Icenowy Zheng wrote:
> > >> >> Many Allwinner SoCs after A31 have a CCU in PRCM block.
> > >> >>
> > >> >> Give the ones on H3 and A64 compatible strings.
> > >> >>
> > >> >> Signed-off-by: Icenowy Zheng <icenowy-ymACFijhrKM@public.gmane.org>
> > >> >> ---
> > >> >> Changes in v2:
> > >> >> - Add iosc for R_CCU's on H3/A64. (A31, A23 and A33 seem to have different
> > >> >> clock for mux 3 of ar100 clk. Investgations are needed for them.)
> > >> >>
> > >> >> Documentation/devicetree/bindings/clock/sunxi-ccu.txt | 18 +++++++++++++++++-
> > >> >> 1 file changed, 17 insertions(+), 1 deletion(-)
> > >> >>
> > >> >> diff --git a/Documentation/devicetree/bindings/clock/sunxi-ccu.txt b/Documentation/devicetree/bindings/clock/sunxi-ccu.txt
> > >> >> index 68512aa398a9..4a4addff595d 100644
> > >> >> --- a/Documentation/devicetree/bindings/clock/sunxi-ccu.txt
> > >> >> +++ b/Documentation/devicetree/bindings/clock/sunxi-ccu.txt
> > >> >> @@ -7,9 +7,11 @@ Required properties :
> > >> >> - "allwinner,sun8i-a23-ccu"
> > >> >> - "allwinner,sun8i-a33-ccu"
> > >> >> - "allwinner,sun8i-h3-ccu"
> > >> >> + - "allwinner,sun8i-h3-r-ccu"
> > >> >> - "allwinner,sun8i-v3s-ccu"
> > >> >> - "allwinner,sun9i-a80-ccu"
> > >> >> - "allwinner,sun50i-a64-ccu"
> > >> >> + - "allwinner,sun50i-a64-r-ccu"
> > >> >> - "allwinner,sun50i-h5-ccu"
> > >> >>
> > >> >> - reg: Must contain the registers base address and length
> > >> >> @@ -20,7 +22,11 @@ Required properties :
> > >> >> - #clock-cells : must contain 1
> > >> >> - #reset-cells : must contain 1
> > >> >>
> > >> >> -Example:
> > >> >> +For the PRCM CCUs on H3/A64, one more clock is needed:
> > >> >> +- "iosc": another frequency oscillator used for CPUS (usually at 32000Hz,
> > >> >> + not the same with losc)
> > >> >
> > >> > This is called the internal oscillator in the datasheet, it would
> > >> > probably make more sense to call it that way in the documentation too.
> > >> >
> > >> > This oscillator seems to be clocked at 16MHz, so we should represent
> > >> > it as such.
> > >> >
> > >> > And I'm wondering, are you *sure* that it's fed directly from the
> > >> > internal oscillator, or goes through the registers in the RTC, with
> > >> > the 32 divider and 16 prescaler by default that makes it at roughly
> > >> > the same rate (31.25kHz).
> > >>
> > >> In fact I know nothing about it -- I only represented the code in BSP
> > >> clock driver.
> > >>
> > >> The mux value 3 varies from SoC to SoC. For A64/H5 it's 32000,
> > >> for A33 it's 667000 (seems to be directly the internal OSC, as the
> > >> user manual says the internal OSC is 600~700kHz; but it's named
> > >> cpuosc rather than iosc in A33 BSP clock driver); for A80 it's even
> > >> PLL_AUDIO.
> > >
> > > Where are you getting those info from?
> > >
> > > As far as I know, the A33 PRCM takes the hosc, losc, pll6 and CPU
> > > (internal) oscillator:
> > > https://github.com/allwinner-zh/linux-3.4-sunxi/blob/master/drivers/clk/sunxi/clk-sun8iw5.c#L508
> > >
> > > The H3 takes the hosc and losc:
> > > https://github.com/allwinner-zh/linux-3.4-sunxi/blob/master/drivers/clk/sunxi/clk-sun8iw7.c#L379
> > >
> > > The A80 takes the hosc and losc:
> > > https://github.com/allwinner-zh/linux-3.4-sunxi/blob/master/drivers/clk/sunxi/clk-sun9iw1.c#L281
> > >
> > > The A64 takes the hosc, losc, pll-periph0 and the iosc, which indeed
> > > seems to be fed from the internal oscillator with the divider in the
> > > RTC:
> > > https://github.com/longsleep/linux-pine64/blob/lichee-dev-v3.10.65-bsp2.0/arch/arm64/boot/dts/sun50iw1p1-clk.dtsi#L19
> > > https://github.com/longsleep/linux-pine64/blob/lichee-dev-v3.10.65-bsp2.0/drivers/clk/sunxi/clk-sun50iw1.c#L603
> >
> > But then in sunxi_init_clocks function, the iosc clock is initialized
> > as a fixed clock with 32000Hz.
> >
> > The clock node in BSP device tree have a compatible of
> > allwinner,fixed-clock, but not fixed-clock, which makes it not able
> > to be really probed.
>
> That clock is registered:
> https://github.com/longsleep/linux-pine64/blob/lichee-dev-v3.10.65-bsp2.0/drivers/clk/sunxi/clk-sun50iw1.c#L1193
>
Oh yes, but conflicts exist between the iosc registered in clk-sun50iw1.c and described in sun50iw1p1-clk.dtsi . The former is 32000, and the latter is 16000000.
What should we do then?
(Maybe it will be better to temporarily ignore this mux, as it's difficult to finally find out this correct mux...)
> Maxime
>
> --
> Maxime Ripard, Free Electrons
> Embedded Linux and Kernel engineering
> http://free-electrons.com
--
You received this message because you are subscribed to the Google Groups "linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org
For more options, visit https://groups.google.com/d/optout.
^ permalink raw reply
* Re: [PATCH v2 4/7] pinctrl: armada-37xx: Add gpio support
From: Linus Walleij @ 2017-03-27 8:57 UTC (permalink / raw)
To: Gregory CLEMENT
Cc: Thomas Petazzoni, Andrew Lunn, Jason Cooper,
devicetree@vger.kernel.org, linux-kernel@vger.kernel.org,
Nadav Haklai, linux-gpio@vger.kernel.org, Rob Herring,
Neta Zur Hershkovits, Victor Gu, Hua Jing, Marcin Wojtas,
Wilson Ding, linux-arm-kernel@lists.infradead.org,
Sebastian Hesselbarth
In-Reply-To: <913cf9807c7c351bb7dabac9b3336431dac060e5.1490120798.git-series.gregory.clement@free-electrons.com>
On Tue, Mar 21, 2017 at 7:28 PM, Gregory CLEMENT
<gregory.clement@free-electrons.com> wrote:
You should add something to your Kconfig including:
select GPIOLIB
select OF_GPIO
or so... or depends on. You certainly need them.
> +static int armada_37xx_gpiochip_register(struct platform_device *pdev,
> + struct armada_37xx_pinctrl *info)
> +{
> + struct device_node *np;
> + struct gpio_chip *gc;
> + int ret = -ENODEV;
> +
> + for_each_child_of_node(info->dev->of_node, np) {
> + if (of_find_property(np, "gpio-controller", NULL)) {
> + ret = 0;
> + break;
> + }
> + };
OK so several GPIO chips as subnodes, why not one device per
chip? Or have we discussed this before? It seems a bit weird,
apparently there is just one node with a gpio-controller, as you're
just adding one pin range.
What happens if there would be two gpio-controllers? The second
is just ignored without error?
> + ret = gpiochip_add_data(gc, info);
> + if (ret)
> + return ret;
Can't you use devm_gpiochip_add_data()?
> + ret = gpiochip_add_pin_range(&info->gpio_chip, dev_name(dev), 0,
> + pinbase, info->data->nr_pins);
> + if (ret)
> + return ret;
Why can't you put the range(s) into the device tree?
We already have code in drivers/gpio/gpiolib-of.c to do this
for you. And generic range definition bindings.
Yours,
Linus Walleij
^ permalink raw reply
* Re: [PATCH v2 1/2] dts: arm64: add LS1043A DPAA support
From: Shawn Guo @ 2017-03-27 8:55 UTC (permalink / raw)
To: Madalin-Cristian Bucur
Cc: mark.rutland@arm.com, devicetree@vger.kernel.org,
catalin.marinas@arm.com, Roy Pledge, will.deacon@arm.com,
linux-kernel@vger.kernel.org, Russell King - ARM Linux,
robh+dt@kernel.org, Kumar Gala,
linux-arm-kernel@lists.infradead.org
In-Reply-To: <HE1PR04MB1129DA747FC5B7B977CADF43EC330@HE1PR04MB1129.eurprd04.prod.outlook.com>
On Mon, Mar 27, 2017 at 08:11:33AM +0000, Madalin-Cristian Bucur wrote:
> Complex it is, mirroring the IP, but messy it is a word I would not use.
Well, just my personal opinion.
Shawn
^ permalink raw reply
* Re: [PATCH v3 0/4] iio: adc: Maxim max9611 driver
From: Geert Uytterhoeven @ 2017-03-27 8:53 UTC (permalink / raw)
To: Jacopo Mondi
Cc: Wolfram Sang, Magnus Damm, Laurent Pinchart, Jonathan Cameron,
Hartmut Knaack, Lars-Peter Clausen, Peter Meerwald, Rob Herring,
Mark Rutland, linux-iio-u79uwXL29TY76Z2rM5mHXA, Linux-Renesas,
devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
In-Reply-To: <1490369323-13866-1-git-send-email-jacopo+renesas-AW8dsiIh9cEdnm+yROfE0A@public.gmane.org>
Hi Jacopo,
On Fri, Mar 24, 2017 at 4:28 PM, Jacopo Mondi <jacopo+renesas-AW8dsiIh9cEdnm+yROfE0A@public.gmane.org> wrote:
> output reported from iio_info tool:
> iio:device0: max9611_vdd
> 6 channels found:
> temp: (input)
> 2 channel-specific attributes found:
> attr 0: scale value: 0.480076812
> attr 1: raw value: 59
According to Documentation/ABI/testing/sysfs-bus-iio, temperature units after
application of scale and offset are milli degrees Celsius, so your scale value
should be 480.076812.
BTW, mine runs 3 degrees cooler, but it's located in the coldest room in my
house ;-)
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert-Td1EMuHUCqxL1ZNQvxDV9g@public.gmane.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
--
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/RFC v2 1/2] arm64: dts: r8a7795: Add support for R-Car H3 ES2.0
From: Laurent Pinchart @ 2017-03-27 8:48 UTC (permalink / raw)
To: Geert Uytterhoeven
Cc: Simon Horman, Magnus Damm, Yoshihiro Shimoda, Kuninori Morimoto,
Wolfram Sang, Rob Herring, Mark Rutland, linux-renesas-soc,
devicetree, linux-arm-kernel
In-Reply-To: <1490362665-4422-2-git-send-email-geert+renesas@glider.be>
Hi Geert,
Thank you for the patch.
On Friday 24 Mar 2017 14:37:44 Geert Uytterhoeven wrote:
> Update r8a7795.dtsi so it corresponds to R-Car H3 ES2.0 or later:
> - The following devices no longer exist on ES2.0, and are thus removed:
> fcpf2, fcpvd3, fcpvi2, fdp1-2, usb3-if1, vspd3, vspi2.
> - The DU <-> VSPD topology is different on ES2.0, hence remove the
> "vsps" property from the DU node until the driver can handle this.
I think I'll need a different compatible string between ES1.x and ES2 for the
DU. It could make sense to move the whole DU node to *-es1.dtsi. We can decide
about that later when I'll have a DU driver prototype ready.
> Move support for the ES1.x revision of the R-Car H3 SoC into a
> separate file. To avoid duplication, r8a7795-es1.dtsi includes
> r8a7795.dtsi, add adds/removes/overrides device nodes and properties
> where needed.
>
> Switch r8a7795-salvator-x.dts and r8a7795-h3ulcb.dts from r8a7795.dtsi
> to r8a7795-es1.dtsi to preserve compatibility.
>
> Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
> ---
> While currently r8a7795-es1.dtsi only adds device nodes, removal of
> devices nodes and properties can be implemented using the /delete-node/
> and /delete-property/ keywords, as shown below:
>
> &soc {
> /delete-node/ <name>@<addr>;
> };
>
> &<name> {
> /delete-property/ <prop>;
> };
>
> v2:
> - Use a separate file for ES1.x instead of for ES2.0, so r8a7795.dtsi
> always corresponds to the latest SoC revision,
> - Add a dash between SoC part number and revision, for compatibility
> with the BSP,
> - Enhance the hardware description from basic support to everything
> already supported on ES1.x (except for DU due VSP),
> - Let r8a7795-es1.dtsi include r8a7795.dtsi.
> ---
> arch/arm64/boot/dts/renesas/r8a7795-es1.dtsi | 83 +++++++++++++++++++
> arch/arm64/boot/dts/renesas/r8a7795-h3ulcb.dts | 4 +-
> arch/arm64/boot/dts/renesas/r8a7795-salvator-x.dts | 4 +-
> arch/arm64/boot/dts/renesas/r8a7795.dtsi | 70 +-----------------
> 4 files changed, 88 insertions(+), 73 deletions(-)
> create mode 100644 arch/arm64/boot/dts/renesas/r8a7795-es1.dtsi
>
> diff --git a/arch/arm64/boot/dts/renesas/r8a7795-es1.dtsi
> b/arch/arm64/boot/dts/renesas/r8a7795-es1.dtsi new file mode 100644
> index 0000000000000000..f1646334899f08ce
> --- /dev/null
> +++ b/arch/arm64/boot/dts/renesas/r8a7795-es1.dtsi
> @@ -0,0 +1,83 @@
> +/*
> + * Device Tree Source for the r8a7795 ES1.x SoC
> + *
> + * 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"
> +
> +&soc {
> + xhci1: usb@ee0400000 {
> + compatible = "renesas,xhci-r8a7795", "renesas,rcar-gen3-xhci";
> + reg = <0 0xee040000 0 0xc00>;
> + interrupts = <GIC_SPI 98 IRQ_TYPE_LEVEL_HIGH>;
> + clocks = <&cpg CPG_MOD 327>;
> + power-domains = <&sysc R8A7795_PD_ALWAYS_ON>;
> + resets = <&cpg 327>;
> + status = "disabled";
> + };
> +
> + fcpf2: fcp@fe952000 {
> + compatible = "renesas,fcpf";
> + reg = <0 0xfe952000 0 0x200>;
> + clocks = <&cpg CPG_MOD 613>;
> + power-domains = <&sysc R8A7795_PD_A3VP>;
> + resets = <&cpg 613>;
> + };
> +
> + vspi2: vsp@fe9c0000 {
> + compatible = "renesas,vsp2";
> + reg = <0 0xfe9c0000 0 0x8000>;
> + interrupts = <GIC_SPI 446 IRQ_TYPE_LEVEL_HIGH>;
> + clocks = <&cpg CPG_MOD 629>;
> + power-domains = <&sysc R8A7795_PD_A3VP>;
> + resets = <&cpg 629>;
> +
> + renesas,fcp = <&fcpvi2>;
> + };
> +
> + fcpvi2: fcp@fe9cf000 {
> + compatible = "renesas,fcpv";
> + reg = <0 0xfe9cf000 0 0x200>;
> + clocks = <&cpg CPG_MOD 609>;
> + power-domains = <&sysc R8A7795_PD_A3VP>;
> + resets = <&cpg 609>;
> + };
> +
> + vspd3: vsp@fea38000 {
> + compatible = "renesas,vsp2";
> + reg = <0 0xfea38000 0 0x4000>;
> + interrupts = <GIC_SPI 469 IRQ_TYPE_LEVEL_HIGH>;
> + clocks = <&cpg CPG_MOD 620>;
> + power-domains = <&sysc R8A7795_PD_ALWAYS_ON>;
> + resets = <&cpg 620>;
> +
> + renesas,fcp = <&fcpvd3>;
> + };
> +
> + fcpvd3: fcp@fea3f000 {
> + compatible = "renesas,fcpv";
> + reg = <0 0xfea3f000 0 0x200>;
> + clocks = <&cpg CPG_MOD 600>;
> + power-domains = <&sysc R8A7795_PD_ALWAYS_ON>;
> + resets = <&cpg 600>;
> + };
> +
> + fdp1@fe948000 {
> + compatible = "renesas,fdp1";
> + reg = <0 0xfe948000 0 0x2400>;
> + interrupts = <GIC_SPI 264 IRQ_TYPE_LEVEL_HIGH>;
> + clocks = <&cpg CPG_MOD 117>;
> + power-domains = <&sysc R8A7795_PD_A3VP>;
> + resets = <&cpg 117>;
> + renesas,fcp = <&fcpf2>;
> + };
> +};
> +
> +&du {
> + vsps = <&vspd0 &vspd1 &vspd2 &vspd3>;
> +};
> diff --git a/arch/arm64/boot/dts/renesas/r8a7795-h3ulcb.dts
> b/arch/arm64/boot/dts/renesas/r8a7795-h3ulcb.dts index
> ab352159de6572c9..60a1f4356b4b15c7 100644
> --- a/arch/arm64/boot/dts/renesas/r8a7795-h3ulcb.dts
> +++ b/arch/arm64/boot/dts/renesas/r8a7795-h3ulcb.dts
> @@ -10,12 +10,12 @@
> */
>
> /dts-v1/;
> -#include "r8a7795.dtsi"
> +#include "r8a7795-es1.dtsi"
> #include <dt-bindings/gpio/gpio.h>
> #include <dt-bindings/input/input.h>
>
> / {
> - model = "Renesas H3ULCB board based on r8a7795";
> + model = "Renesas H3ULCB board based on r8a7795 ES1.x";
> compatible = "renesas,h3ulcb", "renesas,r8a7795";
>
> aliases {
> diff --git a/arch/arm64/boot/dts/renesas/r8a7795-salvator-x.dts
> b/arch/arm64/boot/dts/renesas/r8a7795-salvator-x.dts index
> f25241921067dcef..7758b479dd98d2e9 100644
> --- a/arch/arm64/boot/dts/renesas/r8a7795-salvator-x.dts
> +++ b/arch/arm64/boot/dts/renesas/r8a7795-salvator-x.dts
> @@ -32,11 +32,11 @@
> */
>
> /dts-v1/;
> -#include "r8a7795.dtsi"
> +#include "r8a7795-es1.dtsi"
> #include <dt-bindings/gpio/gpio.h>
>
> / {
> - model = "Renesas Salvator-X board based on r8a7795";
> + model = "Renesas Salvator-X board based on r8a7795 ES1.x";
> compatible = "renesas,salvator-x", "renesas,r8a7795";
>
> aliases {
> diff --git a/arch/arm64/boot/dts/renesas/r8a7795.dtsi
> b/arch/arm64/boot/dts/renesas/r8a7795.dtsi index
> e99d6443b3e493a4..e1caa4e14593a299 100644
> --- a/arch/arm64/boot/dts/renesas/r8a7795.dtsi
> +++ b/arch/arm64/boot/dts/renesas/r8a7795.dtsi
> @@ -182,7 +182,7 @@
> clock-frequency = <0>;
> };
>
> - soc {
> + soc: soc {
> compatible = "simple-bus";
> interrupt-parent = <&gic>;
>
> @@ -1274,16 +1274,6 @@
> status = "disabled";
> };
>
> - xhci1: usb@ee0400000 {
> - compatible = "renesas,xhci-r8a7795", "renesas,rcar-
gen3-xhci";
> - reg = <0 0xee040000 0 0xc00>;
> - interrupts = <GIC_SPI 98 IRQ_TYPE_LEVEL_HIGH>;
> - clocks = <&cpg CPG_MOD 327>;
> - power-domains = <&sysc R8A7795_PD_ALWAYS_ON>;
> - resets = <&cpg 327>;
> - status = "disabled";
> - };
> -
> usb_dmac0: dma-controller@e65a0000 {
> compatible = "renesas,r8a7795-usb-dmac",
> "renesas,usb-dmac";
> @@ -1568,14 +1558,6 @@
> resets = <&cpg 614>;
> };
>
> - fcpf2: fcp@fe952000 {
> - compatible = "renesas,fcpf";
> - reg = <0 0xfe952000 0 0x200>;
> - clocks = <&cpg CPG_MOD 613>;
> - power-domains = <&sysc R8A7795_PD_A3VP>;
> - resets = <&cpg 613>;
> - };
> -
> vspbd: vsp@fe960000 {
> compatible = "renesas,vsp2";
> reg = <0 0xfe960000 0 0x8000>;
> @@ -1633,25 +1615,6 @@
> resets = <&cpg 610>;
> };
>
> - vspi2: vsp@fe9c0000 {
> - compatible = "renesas,vsp2";
> - reg = <0 0xfe9c0000 0 0x8000>;
> - interrupts = <GIC_SPI 446 IRQ_TYPE_LEVEL_HIGH>;
> - clocks = <&cpg CPG_MOD 629>;
> - power-domains = <&sysc R8A7795_PD_A3VP>;
> - resets = <&cpg 629>;
> -
> - renesas,fcp = <&fcpvi2>;
> - };
> -
> - fcpvi2: fcp@fe9cf000 {
> - compatible = "renesas,fcpv";
> - reg = <0 0xfe9cf000 0 0x200>;
> - clocks = <&cpg CPG_MOD 609>;
> - power-domains = <&sysc R8A7795_PD_A3VP>;
> - resets = <&cpg 609>;
> - };
> -
> vspd0: vsp@fea20000 {
> compatible = "renesas,vsp2";
> reg = <0 0xfea20000 0 0x4000>;
> @@ -1709,25 +1672,6 @@
> resets = <&cpg 601>;
> };
>
> - vspd3: vsp@fea38000 {
> - compatible = "renesas,vsp2";
> - reg = <0 0xfea38000 0 0x4000>;
> - interrupts = <GIC_SPI 469 IRQ_TYPE_LEVEL_HIGH>;
> - clocks = <&cpg CPG_MOD 620>;
> - power-domains = <&sysc R8A7795_PD_ALWAYS_ON>;
> - resets = <&cpg 620>;
> -
> - renesas,fcp = <&fcpvd3>;
> - };
> -
> - fcpvd3: fcp@fea3f000 {
> - compatible = "renesas,fcpv";
> - reg = <0 0xfea3f000 0 0x200>;
> - clocks = <&cpg CPG_MOD 600>;
> - power-domains = <&sysc R8A7795_PD_ALWAYS_ON>;
> - resets = <&cpg 600>;
> - };
> -
> fdp1@fe940000 {
> compatible = "renesas,fdp1";
> reg = <0 0xfe940000 0 0x2400>;
> @@ -1748,16 +1692,6 @@
> renesas,fcp = <&fcpf1>;
> };
>
> - fdp1@fe948000 {
> - compatible = "renesas,fdp1";
> - reg = <0 0xfe948000 0 0x2400>;
> - interrupts = <GIC_SPI 264 IRQ_TYPE_LEVEL_HIGH>;
> - clocks = <&cpg CPG_MOD 117>;
> - power-domains = <&sysc R8A7795_PD_A3VP>;
> - resets = <&cpg 117>;
> - renesas,fcp = <&fcpf2>;
> - };
> -
> du: display@feb00000 {
> compatible = "renesas,du-r8a7795";
> reg = <0 0xfeb00000 0 0x80000>,
> @@ -1775,8 +1709,6 @@
> clock-names = "du.0", "du.1", "du.2", "du.3",
"lvds.0";
> status = "disabled";
>
> - vsps = <&vspd0 &vspd1 &vspd2 &vspd3>;
> -
> ports {
> #address-cells = <1>;
> #size-cells = <0>;
--
Regards,
Laurent Pinchart
^ permalink raw reply
* RE: [PATCH v2 1/2] dts: arm64: add LS1043A DPAA support
From: Madalin-Cristian Bucur @ 2017-03-27 8:11 UTC (permalink / raw)
To: Shawn Guo, devicetree@vger.kernel.org, robh+dt@kernel.org,
mark.rutland@arm.com, Roy Pledge, will.deacon@arm.com,
catalin.marinas@arm.com
Cc: Kumar Gala, linux-kernel@vger.kernel.org,
linux-arm-kernel@lists.infradead.org, Russell King - ARM Linux
In-Reply-To: <20170327075546.GR30608@dragon>
> -----Original Message-----
> From: Shawn Guo [mailto:shawnguo@kernel.org]
> Sent: Monday, March 27, 2017 10:56 AM
> Subject: Re: [PATCH v2 1/2] dts: arm64: add LS1043A DPAA support
>
> On Mon, Mar 27, 2017 at 07:03:40AM +0000, Madalin-Cristian Bucur wrote:
> > > > > > + fman@1a00000 {
> > > > > > + enet0: ethernet@e0000 {
> > > > > > + };
> > > > > > +
> > > > > > + enet1: ethernet@e2000 {
> > > > > > + };
> > > > > > +
> > > > > > + enet2: ethernet@e4000 {
> > > > > > + };
> > > > > > +
> > > > > > + enet3: ethernet@e6000 {
> > > > > > + };
> > > > > > +
> > > > > > + enet4: ethernet@e8000 {
> > > > > > + };
> > > > > > +
> > > > > > + enet5: ethernet@ea000 {
> > > > > > + };
> > > > > > +
> > > > > > + enet6: ethernet@f0000 {
> > > > > > + };
> > > > > > + };
> > > > >
> > > > > I do not quite understand why these nodes are empty.
> > > >
> > > > These nodes provide the aliases (and custom SoC mapping) for the
> > > > FMan ports that are used on this particular SoC. The particular
> > > > node details are found in the port dtsi file thus no information
> > > > is required here. Given the fact that the numbering and actual
> > > > ports that are in use can vary between SoCs, the aliases cannot
> > > > be included in the port dtsi nor in the FMan dtsi.
> > >
> > > Do not completely follow. What do you mean by 'port dtsi file'?
> Maybe
> > > I should wait for you new patches with better commit log and comments
> to
> > > understand these odd empty nodes.
> >
> > The DPAA IP can have a certain number of ports. Out of those, a certain
> > SoC can use all or only a subset, with diverse decisions on actual
> numbering
> > of the used ports. Next, when using the SoC on a particular board, some
> > ports will be used, some will not. The file hierarchy relates to this
> > hierarchy - you have individual port files that are included by the
> > SoC dtsi which in turn is included by the board dts. These nodes do not
> > need any new content as all the node details are provided by the port
> > dtsi files. The information they provide is the alias used for each
> port.
>
> My impression is that such hierarchy mapping is not really necessary and
> only makes the device tree source messy and hard to follow. I do not
> like it.
Hi Shawn, I respect your opinion on this, I'm sure it is the result of an
extensive experience dealing with less complicated devices. Before breaking
a construct that to date has served the DPAA users well I'd like to hear
more thoughts on this topic.
> >
> > > >
> > > > > > +};
> > > > > > diff --git a/arch/arm64/boot/dts/freescale/fsl-ls1043a-qds.dts
> > > > > b/arch/arm64/boot/dts/freescale/fsl-ls1043a-qds.dts
> > > > > > index 0989d63..ee66bb2 100644
> > > > > > --- a/arch/arm64/boot/dts/freescale/fsl-ls1043a-qds.dts
> > > > > > +++ b/arch/arm64/boot/dts/freescale/fsl-ls1043a-qds.dts
> > > > > > @@ -181,3 +181,5 @@
> > > > > > reg = <0>;
> > > > > > };
> > > > > > };
> > > > > > +
> > > > > > +/include/ "fsl-ls1043-post.dtsi"
> > > > >
> > > > > Move it to header of the file.
> > > >
> > > > This is to be included at the end, to make sure the references are
> > > > met and to allow overrides if needed.
> > >
> > > What is broken if you move the include to header?
> >
> > Not much besides the structure we've always used for our SoCs device
> > trees. The file is called "-post.dtsi" because here is the place any
> > required overrides can be made, if needed. Moving to the top renders
> > having this separate file useless.
>
> That's great, and let's kill it then.
>
> >
> > > >
> > > > > > diff --git a/arch/arm64/boot/dts/freescale/fsl-ls1043a-rdb.dts
> > > > > b/arch/arm64/boot/dts/freescale/fsl-ls1043a-rdb.dts
> > > > > > index c37110b..d94f003 100644
> > > > > > --- a/arch/arm64/boot/dts/freescale/fsl-ls1043a-rdb.dts
> > > > > > +++ b/arch/arm64/boot/dts/freescale/fsl-ls1043a-rdb.dts
> > > > > > @@ -139,3 +139,78 @@
> > > > > > &duart1 {
> > > > > > status = "okay";
> > > > > > };
> > > > > > +
> > > > > > +/include/ "fsl-ls1043-post.dtsi"
> > > > > > +
> > > > >
> > > > > Ditto
> > > > >
> > > > > > +&soc {
> > > > > > + fman@1a00000 {
> > > > > > + ethernet@e0000 {
> > > > >
> > > > > You defined enet0 label. Why don't you use it?
> > > > >
> > > >
> > > > The enet0 label is used by u-boot for fix-ups, providing the
> > > > actual offset here makes it easier to follow.
> > >
> > > You will not need to construct the node hierarchy with label. And
> > > alias/label name is more easier to follow than offset.
> > >
> > > Shawn
> >
> > When I said easier to follow I was referring to someone creating a
> > new device tree for his custom board, not someone reading the device
> > tree. If you have the board and SoC reference manuals in your hands
> > and you are writing a new board device tree, having the offset here
> > makes things easier. The benefit of having one less indentation level
> > is lesser than that.
>
> The while complex and messy file hierarchy makes users' life harder,
> both the ones reading the device tree and the ones creating board device
> tree. I would suggest you go the opposite, making the device tree
> simple and easy for users by allowing data duplication. In arm/arm64
> device tree world, we do not consider DT data reusing/sharing among
> different SoCs that much.
>
> Shawn
Complex it is, mirroring the IP, but messy it is a word I would not use.
Regards,
Madalin
^ permalink raw reply
* RE: [v2, 4/7] mmc: sdhci: add a quirk to restore delay in tuning
From: Y.B. Lu @ 2017-03-27 8:05 UTC (permalink / raw)
To: Adrian Hunter, linux-mmc@vger.kernel.org, ulf.hansson@linaro.org,
Rob Herring, Mark Rutland, Catalin Marinas, Will Deacon
Cc: devicetree@vger.kernel.org, linux-arm-kernel@lists.infradead.org,
Xiaobo Xie
In-Reply-To: <878da006-5b83-a9d9-6136-07d8f07ea65f@intel.com>
Hi Adrian,
Thanks a lot for your suggestion.
I have sent out the new version patch-set.
Please help to review :)
Best regards,
Yangbo Lu
> -----Original Message-----
> From: Adrian Hunter [mailto:adrian.hunter@intel.com]
> Sent: Thursday, March 23, 2017 3:04 PM
> To: Y.B. Lu; linux-mmc@vger.kernel.org; ulf.hansson@linaro.org; Rob
> Herring; Mark Rutland; Catalin Marinas; Will Deacon
> Cc: devicetree@vger.kernel.org; linux-arm-kernel@lists.infradead.org;
> Xiaobo Xie
> Subject: Re: [v2, 4/7] mmc: sdhci: add a quirk to restore delay in tuning
>
> On 03/03/17 10:18, Yangbo Lu wrote:
> > There was a mdelay between tuning cycles which is removed since eMMC
> > spec didn't require that. However it's observed that eSDHC needed this
> > delay for HS200 successful tuning. Maybe it's also needed for some
> > other controllers. This patch is to add a quirk to fix it.
> >
> > Fixes: 197160d52e85 ("mmc: sdhci: remove mdelay in eMMC tuning")
> > Signed-off-by: Yangbo Lu <yangbo.lu@nxp.com>
> > ---
>
> I would prefer to do something like this:
>
> ---
> From: Adrian Hunter <adrian.hunter@intel.com>
> Date: Thu, 23 Mar 2017 08:54:06 +0200
> Subject: [PATCH] mmc: sdhci: Control the delay between tuning commands
>
> The delay between tuning commands for SD cards is not part of the
> specification. A driver that needs it probably needs it for eMMC too,
> whereas most drivers would probably like to set it to 0. Make it a host
> member (host->tuning_delay) that defaults to the existing behaviour.
> Drivers can set it to zero to eliminate the delay, or set it to a
> positive value to always have a delay.
>
> Signed-off-by: Adrian Hunter <adrian.hunter@intel.com>
> ---
> drivers/mmc/host/sdhci.c | 11 ++++++++--- drivers/mmc/host/sdhci.h | 1
> +
> 2 files changed, 9 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/mmc/host/sdhci.c b/drivers/mmc/host/sdhci.c index
> a33102fc800b..2fc33485df1d 100644
> --- a/drivers/mmc/host/sdhci.c
> +++ b/drivers/mmc/host/sdhci.c
> @@ -2100,9 +2100,9 @@ static void __sdhci_execute_tuning(struct
> sdhci_host *host, u32 opcode)
> break;
> }
>
> - /* eMMC spec does not require a delay between tuning cycles
> */
> - if (opcode == MMC_SEND_TUNING_BLOCK)
> - mdelay(1);
> + /* Spec does not require a delay between tuning cycles */
> + if (host->tuning_delay > 0)
> + mdelay(host->tuning_delay);
> }
>
> pr_info("%s: Tuning failed, falling back to fixed sampling clock\n",
> @@ -2164,6 +2164,9 @@ int sdhci_execute_tuning(struct mmc_host *mmc, u32
> opcode)
>
> host->mmc->retune_period = tuning_count;
>
> + if (host->tuning_delay < 0)
> + host->tuning_delay = opcode == MMC_SEND_TUNING_BLOCK;
> +
> sdhci_start_tuning(host);
>
> __sdhci_execute_tuning(host, opcode);
> @@ -3108,6 +3111,8 @@ struct sdhci_host *sdhci_alloc_host(struct device
> *dev,
> host->cqe_ier = SDHCI_CQE_INT_MASK;
> host->cqe_err_ier = SDHCI_CQE_INT_ERR_MASK;
>
> + host->tuning_delay = -1;
> +
> return host;
> }
>
> diff --git a/drivers/mmc/host/sdhci.h b/drivers/mmc/host/sdhci.h index
> 35b41da0a636..b0f416fc9548 100644
> --- a/drivers/mmc/host/sdhci.h
> +++ b/drivers/mmc/host/sdhci.h
> @@ -538,6 +538,7 @@ struct sdhci_host {
> #define SDHCI_TUNING_MODE_1 0
> #define SDHCI_TUNING_MODE_2 1
> #define SDHCI_TUNING_MODE_3 2
> + int tuning_delay; /* Delay (ms) between tuning
> commands */
>
> unsigned long private[0] ____cacheline_aligned; };
> --
> 1.9.1
>
>
^ permalink raw reply
* [PATCH 1/5 v2] iio: xoadc: augment DT bindings a bit
From: Linus Walleij @ 2017-03-27 7:58 UTC (permalink / raw)
To: Jonathan Cameron, linux-iio-u79uwXL29TY76Z2rM5mHXA
Cc: Linus Walleij, devicetree-u79uwXL29TY76Z2rM5mHXA, Rob Herring
In order to accommodate in a logical manner for the premuxed channels
in PM8921 and the similarly addressed channels in later PMICs, we
need a twocell arrangement with premux and analog mux setting as
a tuple to uniquely identify a hardware channel.
These bindings are not yet in use, so it should be fine to augment
them before we actually start using it in drivers and device trees.
This scheme came out of lengthy discussions and reverse-engineering
and reading of the few information sources we have.
Cc: devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
Cc: Rob Herring <robh+dt-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
Suggested-by: Björn Andersson <bjorn.andersson-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
Signed-off-by: Linus Walleij <linus.walleij-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
---
ChangeLog v1->v2:
- Name nodes with <01 02> in a foo@0102 pattern.
- Minor spelling nits.
- Delete flimsy leftover docs from an interrim development path.
---
.../bindings/iio/adc/qcom,pm8xxx-xoadc.txt | 104 +++++++++++----------
1 file changed, 56 insertions(+), 48 deletions(-)
diff --git a/Documentation/devicetree/bindings/iio/adc/qcom,pm8xxx-xoadc.txt b/Documentation/devicetree/bindings/iio/adc/qcom,pm8xxx-xoadc.txt
index 53cd146d8096..ade545487ce6 100644
--- a/Documentation/devicetree/bindings/iio/adc/qcom,pm8xxx-xoadc.txt
+++ b/Documentation/devicetree/bindings/iio/adc/qcom,pm8xxx-xoadc.txt
@@ -19,32 +19,42 @@ Required properties:
with PMIC variant but is typically something like 2.2 or 1.8V.
The following required properties are standard for IO channels, see
-iio-bindings.txt for more details:
+iio-bindings.txt for more details, but noitice that this particular
+ADC has a special adressing scheme that require two cells for
+identifying each ADC channel:
-- #address-cells: should be set to <1>
+- #address-cells: should be set to <2>, the first cell is the
+ prescaler (on PM8058) or premux (on PM8921) with two valid bits
+ so legal values are 0x00, 0x01 or 0x02. The second cell
+ is the main analog mux setting (0x00..0x0f). The combination
+ of prescaler/premux and analog mux uniquely addresses a hardware
+ channel on all systems.
- #size-cells: should be set to <0>
-- #io-channel-cells: should be set to <1>
+- #io-channel-cells: should be set to <2>, again the cells are
+ precaler or premux followed by the analog muxing line.
- interrupts: should refer to the parent PMIC interrupt controller
and reference the proper ADC interrupt.
Required subnodes:
-The ADC channels are configured as subnodes of the ADC. Since some of
-them are used for calibrating the ADC, these nodes are compulsory:
+The ADC channels are configured as subnodes of the ADC.
-adc-channel@c {
- reg = <0x0c>;
+Since some of them are used for calibrating the ADC, these nodes are
+compulsory:
+
+adc-channel@000c {
+ reg = <0x00 0x0c>;
};
-adc-channel@d {
- reg = <0x0d>;
+adc-channel@000d {
+ reg = <0x00 0x0d>;
};
-adc-channel@f {
- reg = <0x0f>;
+adc-channel@000f {
+ reg = <0x00 0x0f>;
};
These three nodes are used for absolute and ratiometric calibration
@@ -52,13 +62,13 @@ and only need to have these reg values: they are by hardware definition
1:1 ratio converters that sample 625, 1250 and 0 milliV and create
an interpolation calibration for all other ADCs.
-Optional subnodes: any channels other than channel 0x0c, 0x0d and
-0x0f are optional.
+Optional subnodes: any channels other than channels [0x00 0x0c],
+[0x00 0x0d] and [0x00 0x0f] are optional.
Required channel node properties:
- reg: should contain the hardware channel number in the range
- 0 .. 0x0f (4 bits). The hardware only supports 16 channels.
+ 0 .. 0xff (8 bits).
Optional channel node properties:
@@ -94,56 +104,54 @@ Example:
xoadc: xoadc@197 {
compatible = "qcom,pm8058-adc";
reg = <0x197>;
- interrupt-parent = <&pm8058>;
- interrupts = <76 1>;
- #address-cells = <1>;
+ interrupts-extended = <&pm8058 76 IRQ_TYPE_EDGE_RISING>;
+ #address-cells = <2>;
#size-cells = <0>;
- #io-channel-cells = <1>;
+ #io-channel-cells = <2>;
- vcoin: adc-channel@0 {
- reg = <0x00>;
+ vcoin: adc-channel@0000 {
+ reg = <0x00 0x00>;
};
- vbat: adc-channel@1 {
- reg = <0x01>;
+ vbat: adc-channel@0001 {
+ reg = <0x00 0x01>;
};
- dcin: adc-channel@2 {
- reg = <0x02>;
+ dcin: adc-channel@0002 {
+ reg = <0x00 0x02>;
};
- ichg: adc-channel@3 {
- reg = <0x03>;
+ ichg: adc-channel@0030 {
+ reg = <0x00 0x03>;
};
- vph_pwr: adc-channel@4 {
- reg = <0x04>;
+ vph_pwr: adc-channel@0004 {
+ reg = <0x00 0x04>;
};
- usb_vbus: adc-channel@a {
- reg = <0x0a>;
+ usb_vbus: adc-channel@000a {
+ reg = <0x00 0x0a>;
};
- die_temp: adc-channel@b {
- reg = <0x0b>;
+ die_temp: adc-channel@000b {
+ reg = <0x00 0x0b>;
};
- ref_625mv: adc-channel@c {
- reg = <0x0c>;
+ ref_625mv: adc-channel@000c {
+ reg = <0x00 0x0c>;
};
- ref_1250mv: adc-channel@d {
- reg = <0x0d>;
+ ref_1250mv: adc-channel@000d {
+ reg = <0x00 0x0d>;
};
- ref_325mv: adc-channel@e {
- reg = <0x0e>;
+ ref_325mv: adc-channel@000e {
+ reg = <0x00 0x0e>;
};
- ref_muxoff: adc-channel@f {
- reg = <0x0f>;
+ ref_muxoff: adc-channel@000f {
+ reg = <0x00 0x0f>;
};
};
-
/* IIO client node */
iio-hwmon {
compatible = "iio-hwmon";
- io-channels = <&xoadc 0x01>, /* Battery */
- <&xoadc 0x02>, /* DC in (charger) */
- <&xoadc 0x04>, /* VPH the main system voltage */
- <&xoadc 0x0b>, /* Die temperature */
- <&xoadc 0x0c>, /* Reference voltage 1.25V */
- <&xoadc 0x0d>, /* Reference voltage 0.625V */
- <&xoadc 0x0e>; /* Reference voltage 0.325V */
+ io-channels = <&xoadc 0x00 0x01>, /* Battery */
+ <&xoadc 0x00 0x02>, /* DC in (charger) */
+ <&xoadc 0x00 0x04>, /* VPH the main system voltage */
+ <&xoadc 0x00 0x0b>, /* Die temperature */
+ <&xoadc 0x00 0x0c>, /* Reference voltage 1.25V */
+ <&xoadc 0x00 0x0d>, /* Reference voltage 0.625V */
+ <&xoadc 0x00 0x0e>; /* Reference voltage 0.325V */
};
--
2.9.3
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply related
* Re: [PATCH 1/5] iio: xoadc: augment DT bindings a bit
From: Linus Walleij @ 2017-03-27 7:56 UTC (permalink / raw)
To: Bjorn Andersson
Cc: Jonathan Cameron,
linux-iio-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
In-Reply-To: <20170326045717.GB70446-iTMlPVAvTYNoL7IsjepNBwq4bfNCki47rNQQ6b5fDX0@public.gmane.org>
On Sun, Mar 26, 2017 at 6:57 AM, Bjorn Andersson
<bjorn.andersson-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org> wrote:
> On Sat 18 Mar 06:33 PDT 2017, Linus Walleij wrote:
>
>> +adc-channel@0c {
>
> Shouldn't the @ be followed by the value of the first cell in "reg"?
> (Which will collide if we name them all "adc-channel").
I don't think we have a rule about these other than that they should
be unique. I renamed them so that it is unique using the combined
premux+amux number:
>> + reg = <0x00 0x0c>;
So this becomes
adc-channel@000c {
reg = <0x00 0x0c>;
};
>> + On PM8058 the hardware only supports 16 channels, but we get the same
>> + channels repeating with its input divided down by 1 or 3. Channels 00,
>> + 10, 20, ... f0 are the raw values, 04, 14, 24 .. f4 are "unity" channels
>> + divided by 1, and 08, 18, 28 .. f8 are channels divided by 3. Bits 0
>> + and 1 of the channel index should always be 0.
>> +
>> + On PM8921 the hardware supports more than 16 channels through a complex
>> + routing matrix using a premux, so 00, 10, 20 .. f0 are the basic raw
>> + channels while another set of channels appear for 04, 14, 24 .. f4,
>> + and again some of the same channels appear again divided down by 3
>> + in 08, 18, 28 .. f8. Again bits 0 and 1 of the channel index should
>> + always be 0.
>
> While I believe documenting this is a good thing I do not think it adds
> value to this binding document (other than showing Rob the absurdness of
> the addressing scheme). Please consider moving it to the driver (haven't
> checked how you commented it yet) and drop it from here.
Dropped it.
I'm sending this modified version as v2.
Yours,
Linus Walleij
--
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 v2 1/2] dts: arm64: add LS1043A DPAA support
From: Shawn Guo @ 2017-03-27 7:55 UTC (permalink / raw)
To: Madalin-Cristian Bucur
Cc: mark.rutland@arm.com, devicetree@vger.kernel.org,
catalin.marinas@arm.com, Roy Pledge, will.deacon@arm.com,
linux-kernel@vger.kernel.org, Russell King - ARM Linux,
robh+dt@kernel.org, Kumar Gala,
linux-arm-kernel@lists.infradead.org
In-Reply-To: <HE1PR04MB1129A2CA69EB29CD45DBCD17EC330@HE1PR04MB1129.eurprd04.prod.outlook.com>
On Mon, Mar 27, 2017 at 07:03:40AM +0000, Madalin-Cristian Bucur wrote:
> > > > > + fman@1a00000 {
> > > > > + enet0: ethernet@e0000 {
> > > > > + };
> > > > > +
> > > > > + enet1: ethernet@e2000 {
> > > > > + };
> > > > > +
> > > > > + enet2: ethernet@e4000 {
> > > > > + };
> > > > > +
> > > > > + enet3: ethernet@e6000 {
> > > > > + };
> > > > > +
> > > > > + enet4: ethernet@e8000 {
> > > > > + };
> > > > > +
> > > > > + enet5: ethernet@ea000 {
> > > > > + };
> > > > > +
> > > > > + enet6: ethernet@f0000 {
> > > > > + };
> > > > > + };
> > > >
> > > > I do not quite understand why these nodes are empty.
> > >
> > > These nodes provide the aliases (and custom SoC mapping) for the
> > > FMan ports that are used on this particular SoC. The particular
> > > node details are found in the port dtsi file thus no information
> > > is required here. Given the fact that the numbering and actual
> > > ports that are in use can vary between SoCs, the aliases cannot
> > > be included in the port dtsi nor in the FMan dtsi.
> >
> > Do not completely follow. What do you mean by 'port dtsi file'? Maybe
> > I should wait for you new patches with better commit log and comments to
> > understand these odd empty nodes.
>
> The DPAA IP can have a certain number of ports. Out of those, a certain
> SoC can use all or only a subset, with diverse decisions on actual numbering
> of the used ports. Next, when using the SoC on a particular board, some
> ports will be used, some will not. The file hierarchy relates to this
> hierarchy - you have individual port files that are included by the
> SoC dtsi which in turn is included by the board dts. These nodes do not
> need any new content as all the node details are provided by the port
> dtsi files. The information they provide is the alias used for each port.
My impression is that such hierarchy mapping is not really necessary and
only makes the device tree source messy and hard to follow. I do not
like it.
>
> > >
> > > > > +};
> > > > > diff --git a/arch/arm64/boot/dts/freescale/fsl-ls1043a-qds.dts
> > > > b/arch/arm64/boot/dts/freescale/fsl-ls1043a-qds.dts
> > > > > index 0989d63..ee66bb2 100644
> > > > > --- a/arch/arm64/boot/dts/freescale/fsl-ls1043a-qds.dts
> > > > > +++ b/arch/arm64/boot/dts/freescale/fsl-ls1043a-qds.dts
> > > > > @@ -181,3 +181,5 @@
> > > > > reg = <0>;
> > > > > };
> > > > > };
> > > > > +
> > > > > +/include/ "fsl-ls1043-post.dtsi"
> > > >
> > > > Move it to header of the file.
> > >
> > > This is to be included at the end, to make sure the references are
> > > met and to allow overrides if needed.
> >
> > What is broken if you move the include to header?
>
> Not much besides the structure we've always used for our SoCs device
> trees. The file is called "-post.dtsi" because here is the place any
> required overrides can be made, if needed. Moving to the top renders
> having this separate file useless.
That's great, and let's kill it then.
>
> > >
> > > > > diff --git a/arch/arm64/boot/dts/freescale/fsl-ls1043a-rdb.dts
> > > > b/arch/arm64/boot/dts/freescale/fsl-ls1043a-rdb.dts
> > > > > index c37110b..d94f003 100644
> > > > > --- a/arch/arm64/boot/dts/freescale/fsl-ls1043a-rdb.dts
> > > > > +++ b/arch/arm64/boot/dts/freescale/fsl-ls1043a-rdb.dts
> > > > > @@ -139,3 +139,78 @@
> > > > > &duart1 {
> > > > > status = "okay";
> > > > > };
> > > > > +
> > > > > +/include/ "fsl-ls1043-post.dtsi"
> > > > > +
> > > >
> > > > Ditto
> > > >
> > > > > +&soc {
> > > > > + fman@1a00000 {
> > > > > + ethernet@e0000 {
> > > >
> > > > You defined enet0 label. Why don't you use it?
> > > >
> > >
> > > The enet0 label is used by u-boot for fix-ups, providing the
> > > actual offset here makes it easier to follow.
> >
> > You will not need to construct the node hierarchy with label. And
> > alias/label name is more easier to follow than offset.
> >
> > Shawn
>
> When I said easier to follow I was referring to someone creating a
> new device tree for his custom board, not someone reading the device
> tree. If you have the board and SoC reference manuals in your hands
> and you are writing a new board device tree, having the offset here
> makes things easier. The benefit of having one less indentation level
> is lesser than that.
The while complex and messy file hierarchy makes users' life harder,
both the ones reading the device tree and the ones creating board device
tree. I would suggest you go the opposite, making the device tree
simple and easy for users by allowing data duplication. In arm/arm64
device tree world, we do not consider DT data reusing/sharing among
different SoCs that much.
Shawn
^ permalink raw reply
* Re: [PATCH v2 1/6] clk: sunxi-ng: Add sun4i/sun7i CCU driver
From: Maxime Ripard @ 2017-03-27 7:54 UTC (permalink / raw)
To: Priit Laes
Cc: linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-clk-u79uwXL29TY76Z2rM5mHXA,
linux-sunxi-/JYPxA39Uh5TLH3MbocFFw, Icenowy Zheng, Russell King,
Chen-Yu Tsai, Mark Rutland, Rob Herring, Stephen Boyd,
Michael Turquette, Philipp Zabel
In-Reply-To: <ac8c4dab4f160ec605d52120517774bf1de87c2e.1490545262.git-series.plaes-q/aMd4JkU83YtjvyW6yDsg@public.gmane.org>
[-- Attachment #1: Type: text/plain, Size: 5099 bytes --]
Hi,
Thanks a lot for working on this.
On Sun, Mar 26, 2017 at 08:20:16PM +0300, Priit Laes wrote:
> Introduce a clock controller driver for sun4i A10 and sun7i A20
> series SoCs.
>
> Signed-off-by: Priit Laes <plaes-q/aMd4JkU83YtjvyW6yDsg@public.gmane.org>
> ---
> drivers/clk/sunxi-ng/Kconfig | 13 +-
> drivers/clk/sunxi-ng/Makefile | 1 +-
> drivers/clk/sunxi-ng/ccu-sunxi-a10-a20.c | 1532 ++++++++++++++++++-
> drivers/clk/sunxi-ng/ccu-sunxi-a10-a20.h | 59 +-
> include/dt-bindings/clock/sunxi-a10-a20-ccu.h | 208 ++-
> include/dt-bindings/reset/sunxi-a10-a20-ccu.h | 66 +-
I'm not too fond of those sunxi-<all the SoCs supported>. We're not
doing that for any other driver, I don't really know why this has
became a trend lately.
You can call them ccu-sun4i-a10.h, and it will work just fine.
> +/* Not documented on A10 */
> +static SUNXI_CCU_GATE(pll_periph_sata_clk, "pll-periph-sata", "pll-periph",
> + 0x028, BIT(14), 0);
The rate doesn't come from pll-periph directly, does it?
> +#define SUN4I_AHB_REG 0x054
> +static struct ccu_mux cpu_clk = {
> + .mux = {
> + .shift = 16,
> + .width = 2,
> + .fixed_predivs = cpu_predivs,
> + .n_predivs = ARRAY_SIZE(cpu_predivs),
> + },
> + .common = {
> + .reg = 0x054,
Why did you define this one, even though you don't seem to be using it
anywhere?
> +static const char *const ahb_parents[] = { "axi", "pll-periph",
> + "pll-periph-2x" };
> +static const struct ccu_mux_fixed_prediv ahb_predivs[] = {
> + { .index = 2, .div = 2, },
> +};
This seems to be only true for the A20, and not the A10.
Are you sure here? The pll-periph-2x seem to be only used in the MBUS
clock in our current code.
And then, using pll-periph-2x, and then dividing it by 2 just gives us
pll-periph, which is also our previous parent :)
> +/* Undocumented on A10 */
> +static SUNXI_CCU_PHASE(mmc0_output_clk, "mmc0_output", "mmc0",
> + 0x088, 8, 3, 0);
> +/* Undocumented on A10 */
> +static SUNXI_CCU_PHASE(mmc0_sample_clk, "mmc0_sample", "mmc0",
> + 0x088, 20, 3, 0);
The A10 doesn't have them.
> +/* TODO: Check whether A10 actually supports osc32k as 4th parent? */
> +static const char *const ir_parents_sun4i[] = { "hosc", "pll-periph",
> + "pll-ddr-other" };
What does the BSP say about this?
> +/* Undocumented on A10 */
> +static SUNXI_CCU_MUX_WITH_GATE(spdif_clk, "spdif", audio_parents,
> + 0x0c0, 16, 2, BIT(31), CLK_SET_RATE_PARENT);
This doesn't seem to exist at all on the A10
> +/*
> + * TODO: SATA clock also supports external clock as parent via BIT(24)
> + * The external clock is probably an optional crystal or oscillator
> + * that can be connected to the SATA-CLKM / SATA-CLKP pins.
> + */
> +static SUNXI_CCU_GATE(sata_clk, "sata", "pll-periph-sata",
> + 0x0c8, BIT(31), 0);
The rate won't be good here either. This is supposed to be 100MHz.
> +static const char *const csi_isp_parents[] = { "pll-video0", "pll-ve",
> + "pll-ddr-other", "pll-sata" };
> +
> +static SUNXI_CCU_M_WITH_MUX_GATE(csi_isp_clk, "csi-isp",
> + csi_isp_parents,
> + 0x120, 0, 4, 24, 2, BIT(31), 0);
We've been calling it sclk in the other SoC iirc. Any particular
reason to call it differently?
> +static const char *const out_parents[] = { "hosc", "osc32k", "hosc" };
> +static SUNXI_CCU_MP_WITH_MUX_GATE(out_a_clk, "out-a", out_parents,
> + 0x1f0, 8, 5, 20, 2, 24, 2, BIT(31), 0);
> +static SUNXI_CCU_MP_WITH_MUX_GATE(out_b_clk, "out-b", out_parents,
> + 0x1f4, 8, 5, 20, 2, 24, 2, BIT(31), 0);
There's a fixed pre-divider on the first hosc of 750.
> +static void init_clocks(void __iomem *reg)
> +{
> + u32 val;
> +
> + /* Force the PLL-Audio-1x divider to 4 */
> + val = readl(reg + SUN4I_PLL_AUDIO_REG);
> + val &= ~GENMASK(19, 16);
> + writel(val | (3 << 16), reg + SUN4I_PLL_AUDIO_REG);
> +
> + /* Use PLL6 as parent for AHB */
> + val = readl(reg + SUN4I_AHB_REG);
> + val &= ~GENMASK(7, 6);
> + writel(val | (2 << 6), reg + SUN4I_AHB_REG);
Keeping some kind of comment similar to what was in the DT would be
great, otherwise we lose *why* we need to do so.
> +}
> +
> +static void __init sun4i_a10_ccu_setup(struct device_node *node)
> +{
> + void __iomem *reg;
> +
> + reg = of_io_request_and_map(node, 0, of_node_full_name(node));
> + if (IS_ERR(reg)) {
> + pr_err("%s: Could not map the clock registers\n",
> + of_node_full_name(node));
> + return;
> + }
> +
> + init_clocks(reg);
> +
> + sunxi_ccu_probe(node, reg, &sun4i_a10_ccu_desc);
Can't you move the request_and_map / probe in the common function?
> +#ifndef _DT_BINDINGS_CLK_SUNXI_A10_A20_H_
> +#define _DT_BINDINGS_CLK_SUNXI_A10_A20_H_
> +
> +#define CLK_HOSC 1
> +#define CLK_PLL_PERIPH_SATA 16
That one looks suspicious. I don't see why we would need the PLL,
while we have a perfectly functional SATA clock below. Have you tried
gating the bit31 of the register 0xc8 to see if it has any impact?
Thanks!
Maxime
--
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
^ permalink raw reply
* [v3, 7/7] arm64: dts: ls1046ardb: add MMC HS200/UHS-1 modes support
From: Yangbo Lu @ 2017-03-27 7:49 UTC (permalink / raw)
To: linux-mmc, devicetree, linux-arm-kernel, ulf.hansson,
Adrian Hunter, Rob Herring, Mark Rutland, Catalin Marinas,
Will Deacon
Cc: Xiaobo Xie, Yangbo Lu
In-Reply-To: <1490600982-5410-1-git-send-email-yangbo.lu@nxp.com>
Add HS200/UHS-1 properties in eSDHC node to support these
speed modes in driver.
Signed-off-by: Yangbo Lu <yangbo.lu@nxp.com>
---
Changes for v2:
- None
Changes for v3:
- None
---
arch/arm64/boot/dts/freescale/fsl-ls1046a-rdb.dts | 8 ++++++++
1 file changed, 8 insertions(+)
diff --git a/arch/arm64/boot/dts/freescale/fsl-ls1046a-rdb.dts b/arch/arm64/boot/dts/freescale/fsl-ls1046a-rdb.dts
index d1ccc00..08528c2 100644
--- a/arch/arm64/boot/dts/freescale/fsl-ls1046a-rdb.dts
+++ b/arch/arm64/boot/dts/freescale/fsl-ls1046a-rdb.dts
@@ -64,6 +64,14 @@
};
};
+&esdhc {
+ mmc-hs200-1_8v;
+ sd-uhs-sdr104;
+ sd-uhs-sdr50;
+ sd-uhs-sdr25;
+ sd-uhs-sdr12;
+};
+
&duart0 {
status = "okay";
};
--
2.1.0.27.g96db324
^ permalink raw reply related
* [v3, 6/7] arm64: dts: ls1046a: add clocks property and compatible for eSDHC node
From: Yangbo Lu @ 2017-03-27 7:49 UTC (permalink / raw)
To: linux-mmc-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
ulf.hansson-QSEj5FYQhm4dnm+yROfE0A, Adrian Hunter, Rob Herring,
Mark Rutland, Catalin Marinas, Will Deacon
Cc: Xiaobo Xie, Yangbo Lu
In-Reply-To: <1490600982-5410-1-git-send-email-yangbo.lu-3arQi8VN3Tc@public.gmane.org>
The eSDHC could select peripheral clock or platform clock as clock source.
In default, we use platform clock. This patch is to add clocks property
describing peripheral clock for eSDHC node. The driver could use common clk
APIs to get peripheral clock. Also add a compatible for ls1046a eSDHC node.
Signed-off-by: Yangbo Lu <yangbo.lu-3arQi8VN3Tc@public.gmane.org>
---
Changes for v2:
- None
Changes for v3:
- None
---
arch/arm64/boot/dts/freescale/fsl-ls1046a.dtsi | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/arch/arm64/boot/dts/freescale/fsl-ls1046a.dtsi b/arch/arm64/boot/dts/freescale/fsl-ls1046a.dtsi
index 4a164b8..141a513 100644
--- a/arch/arm64/boot/dts/freescale/fsl-ls1046a.dtsi
+++ b/arch/arm64/boot/dts/freescale/fsl-ls1046a.dtsi
@@ -209,10 +209,11 @@
};
esdhc: esdhc@1560000 {
- compatible = "fsl,esdhc";
+ compatible = "fsl,ls1046a-esdhc", "fsl,esdhc";
reg = <0x0 0x1560000 0x0 0x10000>;
interrupts = <GIC_SPI 62 IRQ_TYPE_LEVEL_HIGH>;
clock-frequency = <0>;
+ clocks = <&clockgen 2 1>;
voltage-ranges = <1800 1800 3300 3300>;
sdhci,auto-cmd12;
big-endian;
--
2.1.0.27.g96db324
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply related
* [v3, 5/7] mmc: sdhci-of-esdhc: add delay between tuning cycles
From: Yangbo Lu @ 2017-03-27 7:49 UTC (permalink / raw)
To: linux-mmc, devicetree, linux-arm-kernel, ulf.hansson,
Adrian Hunter, Rob Herring, Mark Rutland, Catalin Marinas,
Will Deacon
Cc: Xiaobo Xie, Yangbo Lu
In-Reply-To: <1490600982-5410-1-git-send-email-yangbo.lu@nxp.com>
It's observed that eSDHC needed delay between tuning cycles for
HS200 successful tuning. This patch is to set 1ms delay for that.
Signed-off-by: Yangbo Lu <yangbo.lu@nxp.com>
---
Changes for v2:
- None
Changes for v3:
- Used a host member for tuning delay instead of a quirk.
---
drivers/mmc/host/sdhci-of-esdhc.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/mmc/host/sdhci-of-esdhc.c b/drivers/mmc/host/sdhci-of-esdhc.c
index 8c8e147..0754ef4 100644
--- a/drivers/mmc/host/sdhci-of-esdhc.c
+++ b/drivers/mmc/host/sdhci-of-esdhc.c
@@ -807,6 +807,7 @@ static int sdhci_esdhc_probe(struct platform_device *pdev)
host->mmc_host_ops.start_signal_voltage_switch =
esdhc_signal_voltage_switch;
host->mmc_host_ops.execute_tuning = esdhc_execute_tuning;
+ host->tuning_delay = 1;
esdhc_init(pdev, host);
--
2.1.0.27.g96db324
^ 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