* Re: [PATCH 3/3] ARM: sun8i: a83t: Rename pinmux setting names
From: Chen-Yu Tsai @ 2017-04-21 3:30 UTC (permalink / raw)
To: Chen-Yu Tsai
Cc: Maxime Ripard, devicetree, linux-arm-kernel, linux-kernel,
linux-sunxi
In-Reply-To: <20170418042205.27894-4-wens-jdAy2FN1RRM@public.gmane.org>
On Tue, Apr 18, 2017 at 12:22 PM, Chen-Yu Tsai <wens-jdAy2FN1RRM@public.gmane.org> wrote:
> The pinmux setting nodes all have an address element in their node
> names, however the pinctrl node does not have #address-cells.
>
> Rename the existing pinmux setting nodes and labels in sun8i-a83t.dtsi,
> dropping identifiers for functions that only have one possible setting,
> and using the pingroup name if the function is identically available on
> different pingroups.
>
> Signed-off-by: Chen-Yu Tsai <wens-jdAy2FN1RRM@public.gmane.org>
> ---
> arch/arm/boot/dts/sun8i-a83t-allwinner-h8homlet-v2.dts | 2 +-
> arch/arm/boot/dts/sun8i-a83t-cubietruck-plus.dts | 2 +-
> arch/arm/boot/dts/sun8i-a83t.dtsi | 10 +++++-----
> 3 files changed, 7 insertions(+), 7 deletions(-)
>
[...]
> diff --git a/arch/arm/boot/dts/sun8i-a83t.dtsi b/arch/arm/boot/dts/sun8i-a83t.dtsi
> index 82cb87f21b96..87b99338716b 100644
> --- a/arch/arm/boot/dts/sun8i-a83t.dtsi
> +++ b/arch/arm/boot/dts/sun8i-a83t.dtsi
> @@ -174,7 +174,7 @@
> #interrupt-cells = <3>;
> #gpio-cells = <3>;
>
> - mmc0_pins_a: mmc0@0 {
> + mmc0_pins: mmc0_pins {
> pins = "PF0", "PF1", "PF2",
> "PF3", "PF4", "PF5";
> function = "mmc0";
> @@ -182,13 +182,13 @@
> bias-pull-up;
> };
>
> - uart0_pins_a: uart0@0 {
> - pins = "PF2", "PF4";
> + uart0_pb_pins: uart0_pb_pins {
Duh... Forgot to use hyphens instead of underscores in the node names.
I'll send a patch for you to squash in.
ChenYu
> + pins = "PB9", "PB10";
> function = "uart0";
> };
>
> - uart0_pins_b: uart0@1 {
> - pins = "PB9", "PB10";
> + uart0_pf_pins: uart0_pf_pins {
> + pins = "PF2", "PF4";
> function = "uart0";
> };
> };
> --
> 2.11.0
>
^ permalink raw reply
* [PATCH V5 1/4] arm64: dts: Add basic DT to support Spreadtrum's SP9860G
From: Chunyan Zhang @ 2017-04-21 3:47 UTC (permalink / raw)
To: arm
Cc: devicetree, orson.zhai, mathieu.poirier, zhang.lyra, linux-kernel,
chunyan.zhang, linux-arm-kernel
In-Reply-To: <20170419142425.GB12105@localhost>
From: Orson Zhai <orson.zhai@spreadtrum.com>
SC9860G is a 8 cores of A53 SoC with 4G LTE support SoC from Spreadtrum.
According to regular hierarchy of sprd dts, whale2.dtsi contains SoC
peripherals IP nodes, sc9860.dtsi contains stuff related to ARM core stuff
and sp9860g dts is for the board level.
Signed-off-by: Orson Zhai <orson.zhai@spreadtrum.com>
Signed-off-by: Chunyan Zhang <chunyan.zhang@spreadtrum.com>
Reviewed-by: Mathieu Poirier <mathieu.poirier@linaro.org>
---
arch/arm64/boot/dts/sprd/Makefile | 3 +-
arch/arm64/boot/dts/sprd/sc9860.dtsi | 569 ++++++++++++++++++++++++++++++
arch/arm64/boot/dts/sprd/sp9860g-1h10.dts | 56 +++
arch/arm64/boot/dts/sprd/whale2.dtsi | 71 ++++
4 files changed, 698 insertions(+), 1 deletion(-)
create mode 100644 arch/arm64/boot/dts/sprd/sc9860.dtsi
create mode 100644 arch/arm64/boot/dts/sprd/sp9860g-1h10.dts
create mode 100644 arch/arm64/boot/dts/sprd/whale2.dtsi
diff --git a/arch/arm64/boot/dts/sprd/Makefile b/arch/arm64/boot/dts/sprd/Makefile
index b658c5e..f0535e6 100644
--- a/arch/arm64/boot/dts/sprd/Makefile
+++ b/arch/arm64/boot/dts/sprd/Makefile
@@ -1,4 +1,5 @@
-dtb-$(CONFIG_ARCH_SPRD) += sc9836-openphone.dtb
+dtb-$(CONFIG_ARCH_SPRD) += sc9836-openphone.dtb \
+ sp9860g-1h10.dtb
always := $(dtb-y)
subdir-y := $(dts-dirs)
diff --git a/arch/arm64/boot/dts/sprd/sc9860.dtsi b/arch/arm64/boot/dts/sprd/sc9860.dtsi
new file mode 100644
index 0000000..7b7d8ce
--- /dev/null
+++ b/arch/arm64/boot/dts/sprd/sc9860.dtsi
@@ -0,0 +1,569 @@
+/*
+ * Spreadtrum SC9860 SoC
+ *
+ * Copyright (C) 2016, Spreadtrum Communications Inc.
+ *
+ * SPDX-License-Identifier: (GPL-2.0+ OR MIT)
+ */
+
+#include <dt-bindings/interrupt-controller/arm-gic.h>
+#include "whale2.dtsi"
+
+/ {
+ cpus {
+ #address-cells = <2>;
+ #size-cells = <0>;
+
+ cpu-map {
+ cluster0 {
+ core0 {
+ cpu = <&CPU0>;
+ };
+ core1 {
+ cpu = <&CPU1>;
+ };
+ core2 {
+ cpu = <&CPU2>;
+ };
+ core3 {
+ cpu = <&CPU3>;
+ };
+ };
+
+ cluster1 {
+ core0 {
+ cpu = <&CPU4>;
+ };
+ core1 {
+ cpu = <&CPU5>;
+ };
+ core2 {
+ cpu = <&CPU6>;
+ };
+ core3 {
+ cpu = <&CPU7>;
+ };
+ };
+ };
+
+ CPU0: cpu@530000 {
+ device_type = "cpu";
+ compatible = "arm,cortex-a53", "arm,armv8";
+ reg = <0x0 0x530000>;
+ enable-method = "psci";
+ cpu-idle-states = <&CORE_PD &CLUSTER_PD>;
+ };
+
+ CPU1: cpu@530001 {
+ device_type = "cpu";
+ compatible = "arm,cortex-a53", "arm,armv8";
+ reg = <0x0 0x530001>;
+ enable-method = "psci";
+ cpu-idle-states = <&CORE_PD &CLUSTER_PD>;
+ };
+
+ CPU2: cpu@530002 {
+ device_type = "cpu";
+ compatible = "arm,cortex-a53", "arm,armv8";
+ reg = <0x0 0x530002>;
+ enable-method = "psci";
+ cpu-idle-states = <&CORE_PD &CLUSTER_PD>;
+ };
+
+ CPU3: cpu@530003 {
+ device_type = "cpu";
+ compatible = "arm,cortex-a53", "arm,armv8";
+ reg = <0x0 0x530003>;
+ enable-method = "psci";
+ cpu-idle-states = <&CORE_PD &CLUSTER_PD>;
+ };
+
+ CPU4: cpu@530100 {
+ device_type = "cpu";
+ compatible = "arm,cortex-a53", "arm,armv8";
+ reg = <0x0 0x530100>;
+ enable-method = "psci";
+ cpu-idle-states = <&CORE_PD &CLUSTER_PD>;
+ };
+
+ CPU5: cpu@530101 {
+ device_type = "cpu";
+ compatible = "arm,cortex-a53", "arm,armv8";
+ reg = <0x0 0x530101>;
+ enable-method = "psci";
+ cpu-idle-states = <&CORE_PD &CLUSTER_PD>;
+ };
+
+ CPU6: cpu@530102 {
+ device_type = "cpu";
+ compatible = "arm,cortex-a53", "arm,armv8";
+ reg = <0x0 0x530102>;
+ enable-method = "psci";
+ cpu-idle-states = <&CORE_PD &CLUSTER_PD>;
+ };
+
+ CPU7: cpu@530103 {
+ device_type = "cpu";
+ compatible = "arm,cortex-a53", "arm,armv8";
+ reg = <0x0 0x530103>;
+ enable-method = "psci";
+ cpu-idle-states = <&CORE_PD &CLUSTER_PD>;
+ };
+ };
+
+ idle-states{
+ entry-method = "arm,psci";
+
+ CORE_PD: core_pd {
+ compatible = "arm,idle-state";
+ entry-latency-us = <1000>;
+ exit-latency-us = <700>;
+ min-residency-us = <2500>;
+ local-timer-stop;
+ arm,psci-suspend-param = <0x00010002>;
+ };
+
+ CLUSTER_PD: cluster_pd {
+ compatible = "arm,idle-state";
+ entry-latency-us = <1000>;
+ exit-latency-us = <1000>;
+ min-residency-us = <3000>;
+ local-timer-stop;
+ arm,psci-suspend-param = <0x01010003>;
+ };
+ };
+
+ gic: interrupt-controller@12001000 {
+ compatible = "arm,gic-400";
+ reg = <0 0x12001000 0 0x1000>,
+ <0 0x12002000 0 0x2000>,
+ <0 0x12004000 0 0x2000>,
+ <0 0x12006000 0 0x2000>;
+ #interrupt-cells = <3>;
+ interrupt-controller;
+ interrupts = <GIC_PPI 9 (GIC_CPU_MASK_SIMPLE(8)
+ | IRQ_TYPE_LEVEL_HIGH)>;
+ };
+
+ psci {
+ compatible = "arm,psci-0.2";
+ method = "smc";
+ };
+
+ timer {
+ compatible = "arm,armv8-timer";
+ interrupts = <GIC_PPI 13 (GIC_CPU_MASK_SIMPLE(8)
+ | IRQ_TYPE_LEVEL_LOW)>,
+ <GIC_PPI 14 (GIC_CPU_MASK_SIMPLE(8)
+ | IRQ_TYPE_LEVEL_LOW)>,
+ <GIC_PPI 11 (GIC_CPU_MASK_SIMPLE(8)
+ | IRQ_TYPE_LEVEL_LOW)>,
+ <GIC_PPI 10 (GIC_CPU_MASK_SIMPLE(8)
+ | IRQ_TYPE_LEVEL_LOW)>;
+ };
+
+ pmu {
+ compatible = "arm,cortex-a53-pmu", "arm,armv8-pmuv3";
+ interrupts = <GIC_SPI 122 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 123 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 124 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 125 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 154 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 155 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 156 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 157 IRQ_TYPE_LEVEL_HIGH>;
+ interrupt-affinity = <&CPU0>,
+ <&CPU1>,
+ <&CPU2>,
+ <&CPU3>,
+ <&CPU4>,
+ <&CPU5>,
+ <&CPU6>,
+ <&CPU7>;
+ };
+
+ soc {
+ funnel@10001000 { /* SoC Funnel */
+ compatible = "arm,coresight-funnel", "arm,primecell";
+ reg = <0 0x10001000 0 0x1000>;
+ clocks = <&ext_26m>;
+ clock-names = "apb_pclk";
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port@0 {
+ reg = <0>;
+ soc_funnel_out_port: endpoint {
+ remote-endpoint = <&etb_in>;
+ };
+ };
+
+ port@1 {
+ reg = <0>;
+ soc_funnel_in_port0: endpoint {
+ slave-mode;
+ remote-endpoint =
+ <&main_funnel_out_port>;
+ };
+ };
+
+ port@2 {
+ reg = <4>;
+ soc_funnel_in_port1: endpoint {
+ slave-mode;
+ remote-endpioint =
+ <&stm_out_port>;
+ };
+ };
+ };
+ };
+
+ etb@10003000 {
+ compatible = "arm,coresight-tmc", "arm,primecell";
+ reg = <0 0x10003000 0 0x1000>;
+ clocks = <&ext_26m>;
+ clock-names = "apb_pclk";
+ port {
+ etb_in: endpoint {
+ slave-mode;
+ remote-endpoint =
+ <&soc_funnel_out_port>;
+ };
+ };
+ };
+
+ stm@10006000 {
+ compatible = "arm,coresight-stm", "arm,primecell";
+ reg = <0 0x10006000 0 0x1000>,
+ <0 0x01000000 0 0x180000>;
+ reg-names = "stm-base", "stm-stimulus-base";
+ clocks = <&ext_26m>;
+ clock-names = "apb_pclk";
+ port {
+ stm_out_port: endpoint {
+ remote-endpoint =
+ <&soc_funnel_in_port1>;
+ };
+ };
+ };
+
+ funnel@11001000 { /* Cluster0 Funnel */
+ compatible = "arm,coresight-funnel", "arm,primecell";
+ reg = <0 0x11001000 0 0x1000>;
+ clocks = <&ext_26m>;
+ clock-names = "apb_pclk";
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port@0 {
+ reg = <0>;
+ cluster0_funnel_out_port: endpoint {
+ remote-endpoint =
+ <&cluster0_etf_in>;
+ };
+ };
+
+ port@1 {
+ reg = <0>;
+ cluster0_funnel_in_port0: endpoint {
+ slave-mode;
+ remote-endpoint = <&etm0_out>;
+ };
+ };
+
+ port@2 {
+ reg = <1>;
+ cluster0_funnel_in_port1: endpoint {
+ slave-mode;
+ remote-endpoint = <&etm1_out>;
+ };
+ };
+
+ port@3 {
+ reg = <2>;
+ cluster0_funnel_in_port2: endpoint {
+ slave-mode;
+ remote-endpoint = <&etm2_out>;
+ };
+ };
+
+ port@4 {
+ reg = <4>;
+ cluster0_funnel_in_port3: endpoint {
+ slave-mode;
+ remote-endpoint = <&etm3_out>;
+ };
+ };
+ };
+ };
+
+ funnel@11002000 { /* Cluster1 Funnel */
+ compatible = "arm,coresight-funnel", "arm,primecell";
+ reg = <0 0x11002000 0 0x1000>;
+ clocks = <&ext_26m>;
+ clock-names = "apb_pclk";
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port@0 {
+ reg = <0>;
+ cluster1_funnel_out_port: endpoint {
+ remote-endpoint =
+ <&cluster1_etf_in>;
+ };
+ };
+
+ port@1 {
+ reg = <0>;
+ cluster1_funnel_in_port0: endpoint {
+ slave-mode;
+ remote-endpoint = <&etm4_out>;
+ };
+ };
+
+ port@2 {
+ reg = <1>;
+ cluster1_funnel_in_port1: endpoint {
+ slave-mode;
+ remote-endpoint = <&etm5_out>;
+ };
+ };
+
+ port@3 {
+ reg = <2>;
+ cluster1_funnel_in_port2: endpoint {
+ slave-mode;
+ remote-endpoint = <&etm6_out>;
+ };
+ };
+
+ port@4 {
+ reg = <3>;
+ cluster1_funnel_in_port3: endpoint {
+ slave-mode;
+ remote-endpoint = <&etm7_out>;
+ };
+ };
+ };
+ };
+
+ etf@11003000 { /* ETF on Cluster0 */
+ compatible = "arm,coresight-tmc", "arm,primecell";
+ reg = <0 0x11003000 0 0x1000>;
+ clocks = <&ext_26m>;
+ clock-names = "apb_pclk";
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port@0 {
+ reg = <0>;
+ cluster0_etf_out: endpoint {
+ remote-endpoint =
+ <&main_funnel_in_port0>;
+ };
+ };
+
+ port@1 {
+ reg = <0>;
+ cluster0_etf_in: endpoint {
+ slave-mode;
+ remote-endpoint =
+ <&cluster0_funnel_out_port>;
+ };
+ };
+ };
+ };
+
+ etf@11004000 { /* ETF on Cluster1 */
+ compatible = "arm,coresight-tmc", "arm,primecell";
+ reg = <0 0x11004000 0 0x1000>;
+ clocks = <&ext_26m>;
+ clock-names = "apb_pclk";
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port@0 {
+ reg = <0>;
+ cluster1_etf_out: endpoint {
+ remote-endpoint =
+ <&main_funnel_in_port1>;
+ };
+ };
+
+ port@1 {
+ reg = <0>;
+ cluster1_etf_in: endpoint {
+ slave-mode;
+ remote-endpoint =
+ <&cluster1_funnel_out_port>;
+ };
+ };
+ };
+ };
+
+ funnel@11005000 { /* Main Funnel */
+ compatible = "arm,coresight-funnel", "arm,primecell";
+ reg = <0 0x11005000 0 0x1000>;
+ clocks = <&ext_26m>;
+ clock-names = "apb_pclk";
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port@0 {
+ reg = <0>;
+ main_funnel_out_port: endpoint {
+ remote-endpoint =
+ <&soc_funnel_in_port0>;
+ };
+ };
+
+ port@1 {
+ reg = <0>;
+ main_funnel_in_port0: endpoint {
+ slave-mode;
+ remote-endpoint =
+ <&cluster0_etf_out>;
+ };
+ };
+
+ port@2 {
+ reg = <1>;
+ main_funnel_in_port1: endpoint {
+ slave-mode;
+ remote-endpoint =
+ <&cluster1_etf_out>;
+ };
+ };
+ };
+ };
+
+ etm@11440000 {
+ compatible = "arm,coresight-etm4x", "arm,primecell";
+ reg = <0 0x11440000 0 0x1000>;
+ cpu = <&CPU0>;
+ clocks = <&ext_26m>;
+ clock-names = "apb_pclk";
+
+ port {
+ etm0_out: endpoint {
+ remote-endpoint =
+ <&cluster0_funnel_in_port0>;
+ };
+ };
+ };
+
+ etm@11540000 {
+ compatible = "arm,coresight-etm4x", "arm,primecell";
+ reg = <0 0x11540000 0 0x1000>;
+ cpu = <&CPU1>;
+ clocks = <&ext_26m>;
+ clock-names = "apb_pclk";
+
+ port {
+ etm1_out: endpoint {
+ remote-endpoint =
+ <&cluster0_funnel_in_port1>;
+ };
+ };
+ };
+
+ etm@11640000 {
+ compatible = "arm,coresight-etm4x", "arm,primecell";
+ reg = <0 0x11640000 0 0x1000>;
+ cpu = <&CPU2>;
+ clocks = <&ext_26m>;
+ clock-names = "apb_pclk";
+
+ port {
+ etm2_out: endpoint {
+ remote-endpoint =
+ <&cluster0_funnel_in_port2>;
+ };
+ };
+ };
+
+ etm@11740000 {
+ compatible = "arm,coresight-etm4x", "arm,primecell";
+ reg = <0 0x11740000 0 0x1000>;
+ cpu = <&CPU3>;
+ clocks = <&ext_26m>;
+ clock-names = "apb_pclk";
+
+ port {
+ etm3_out: endpoint {
+ remote-endpoint =
+ <&cluster0_funnel_in_port3>;
+ };
+ };
+ };
+
+ etm@11840000 {
+ compatible = "arm,coresight-etm4x", "arm,primecell";
+ reg = <0 0x11840000 0 0x1000>;
+ cpu = <&CPU4>;
+ clocks = <&ext_26m>;
+ clock-names = "apb_pclk";
+
+ port {
+ etm4_out: endpoint {
+ remote-endpoint =
+ <&cluster1_funnel_in_port0>;
+ };
+ };
+ };
+
+ etm@11940000 {
+ compatible = "arm,coresight-etm4x", "arm,primecell";
+ reg = <0 0x11940000 0 0x1000>;
+ cpu = <&CPU5>;
+ clocks = <&ext_26m>;
+ clock-names = "apb_pclk";
+
+ port {
+ etm5_out: endpoint {
+ remote-endpoint =
+ <&cluster1_funnel_in_port1>;
+ };
+ };
+ };
+
+ etm@11a40000 {
+ compatible = "arm,coresight-etm4x", "arm,primecell";
+ reg = <0 0x11a40000 0 0x1000>;
+ cpu = <&CPU6>;
+ clocks = <&ext_26m>;
+ clock-names = "apb_pclk";
+
+ port {
+ etm6_out: endpoint {
+ remote-endpoint =
+ <&cluster1_funnel_in_port2>;
+ };
+ };
+ };
+
+ etm@11b40000 {
+ compatible = "arm,coresight-etm4x", "arm,primecell";
+ reg = <0 0x11b40000 0 0x1000>;
+ cpu = <&CPU7>;
+ clocks = <&ext_26m>;
+ clock-names = "apb_pclk";
+
+ port {
+ etm7_out: endpoint {
+ remote-endpoint =
+ <&cluster1_funnel_in_port3>;
+ };
+ };
+ };
+ };
+};
diff --git a/arch/arm64/boot/dts/sprd/sp9860g-1h10.dts b/arch/arm64/boot/dts/sprd/sp9860g-1h10.dts
new file mode 100644
index 0000000..ae0b28c
--- /dev/null
+++ b/arch/arm64/boot/dts/sprd/sp9860g-1h10.dts
@@ -0,0 +1,56 @@
+/*
+ * Spreadtrum SP9860g board
+ *
+ * Copyright (C) 2017, Spreadtrum Communications Inc.
+ *
+ * SPDX-License-Identifier: (GPL-2.0+ OR MIT)
+ */
+
+/dts-v1/;
+
+#include "sc9860.dtsi"
+
+/ {
+ model = "Spreadtrum SP9860G 3GFHD Board";
+
+ compatible = "sprd,sp9860g-1h10", "sprd,sc9860";
+
+ aliases {
+ serial0 = &uart0; /* for Bluetooth */
+ serial1 = &uart1; /* UART console */
+ serial2 = &uart2; /* Reserved */
+ serial3 = &uart3; /* for GPS */
+ };
+
+ memory{
+ device_type = "memory";
+ reg = <0x0 0x80000000 0 0x60000000>,
+ <0x1 0x80000000 0 0x60000000>;
+ };
+
+ chosen {
+ stdout-path = "serial1:115200n8";
+ };
+
+ reserved-memory {
+ #address-cells = <2>;
+ #size-cells = <2>;
+ ranges;
+ };
+};
+
+&uart0 {
+ status = "okay";
+};
+
+&uart1 {
+ status = "okay";
+};
+
+&uart2 {
+ status = "okay";
+};
+
+&uart3 {
+ status = "okay";
+};
diff --git a/arch/arm64/boot/dts/sprd/whale2.dtsi b/arch/arm64/boot/dts/sprd/whale2.dtsi
new file mode 100644
index 0000000..7c217c5
--- /dev/null
+++ b/arch/arm64/boot/dts/sprd/whale2.dtsi
@@ -0,0 +1,71 @@
+/*
+ * Spreadtrum Whale2 platform peripherals
+ *
+ * Copyright (C) 2016, Spreadtrum Communications Inc.
+ *
+ * SPDX-License-Identifier: (GPL-2.0+ OR MIT)
+ */
+
+/ {
+ interrupt-parent = <&gic>;
+ #address-cells = <2>;
+ #size-cells = <2>;
+
+ soc: soc {
+ compatible = "simple-bus";
+ #address-cells = <2>;
+ #size-cells = <2>;
+ ranges;
+
+ ap-apb {
+ compatible = "simple-bus";
+ #address-cells = <1>;
+ #size-cells = <1>;
+ ranges = <0 0x0 0x70000000 0x10000000>;
+
+ uart0: serial@0 {
+ compatible = "sprd,sc9860-uart",
+ "sprd,sc9836-uart";
+ reg = <0x0 0x100>;
+ interrupts = <GIC_SPI 2 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&ext_26m>;
+ status = "disabled";
+ };
+
+ uart1: serial@100000 {
+ compatible = "sprd,sc9860-uart",
+ "sprd,sc9836-uart";
+ reg = <0x100000 0x100>;
+ interrupts = <GIC_SPI 3 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&ext_26m>;
+ status = "disabled";
+ };
+
+ uart2: serial@200000 {
+ compatible = "sprd,sc9860-uart",
+ "sprd,sc9836-uart";
+ reg = <0x200000 0x100>;
+ interrupts = <GIC_SPI 4 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&ext_26m>;
+ status = "disabled";
+ };
+
+ uart3: serial@300000 {
+ compatible = "sprd,sc9860-uart",
+ "sprd,sc9836-uart";
+ reg = <0x300000 0x100>;
+ interrupts = <GIC_SPI 5 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&ext_26m>;
+ status = "disabled";
+ };
+ };
+
+ };
+
+ ext_26m: ext-26m {
+ compatible = "fixed-clock";
+ #clock-cells = <0>;
+ clock-frequency = <26000000>;
+ clock-output-names = "ext_26m";
+ };
+};
--
2.7.4
^ permalink raw reply related
* Re: [PATCH v6 1/6] dt-bindings: power: supply: add AXP20X/AXP22X battery DT binding
From: Chen-Yu Tsai @ 2017-04-21 3:51 UTC (permalink / raw)
To: Quentin Schulz
Cc: Rob Herring, Sebastian Reichel, Mark Rutland, Chen-Yu Tsai,
Russell King, Maxime Ripard, open list:THERMAL, linux-sunxi,
Icenowy Zheng, Liam Breck, devicetree, linux-kernel,
linux-arm-kernel
In-Reply-To: <20170420155820.tzvvwqnl2ze63jel@rob-hp-laptop>
On Thu, Apr 20, 2017 at 11:58 PM, Rob Herring <robh-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org> wrote:
> On Tue, Apr 18, 2017 at 09:34:16AM +0200, Quentin Schulz wrote:
>> The X-Powers AXP20X and AXP22X PMICs can have a battery as power supply.
>>
>> This patch adds the DT binding documentation for the battery power
>> supply which gets various data from the PMIC, such as the battery status
>> (charging, discharging, full, dead), current max limit, current current,
>> battery capacity (in percentage), voltage max and min limits, current
>> voltage and battery capacity (in Ah).
>>
>> Signed-off-by: Quentin Schulz <quentin.schulz-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org>
>> Acked-by: Chen-Yu Tsai <wens-jdAy2FN1RRM@public.gmane.org>
>> Acked-by: Maxime Ripard <maxime.ripard-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org>
>> ---
>> v6:
>> - removed mention to monitored-battery, will be sent when the battery
>> framework has been merged,
>>
>> v5:
>> - removed DT property example from monitored-battery,
>>
>> v4:
>> - added monitored-battery optional property,
>> - added example with battery,
>>
>> v3:
>> - removed constant charge current property, now should use the WIP
>> battery framework,
>>
>> v2:
>> - changed DT node name from ac_power_supply to ac-power-supply,
>> - removed io-channels and io-channel-names from DT (the IIO mapping is
>> done in the IIO ADC driver now),
>> - added x-powers,constant-charge-current property to set the maximal
>> default constant current charge of the battery,
>>
>> .../bindings/power/supply/axp20x_battery.txt | 20 ++++++++++++++++++++
>> 1 file changed, 20 insertions(+)
>> create mode 100644 Documentation/devicetree/bindings/power/supply/axp20x_battery.txt
>
> Acked-by: Rob Herring <robh-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
Acked-by: Chen-Yu Tsai <wens-jdAy2FN1RRM@public.gmane.org>
^ permalink raw reply
* Re: [PATCH 1/3] dt-bindings: mt8173: Fix mdp device tree
From: Minghsiu Tsai @ 2017-04-21 4:06 UTC (permalink / raw)
To: Rob Herring
Cc: Hans Verkuil, daniel.thompson, Mauro Carvalho Chehab,
Matthias Brugger, Daniel Kurtz, Pawel Osciak, Houlong Wei,
srv_heupstream, Eddie Huang, Yingjoe Chen, Wu-Cheng Li,
devicetree, linux-kernel, linux-arm-kernel, linux-media,
linux-mediatek
In-Reply-To: <20170419213540.4vigeed3mx24ie4e@rob-hp-laptop>
On Wed, 2017-04-19 at 16:35 -0500, Rob Herring wrote:
> On Thu, Apr 13, 2017 at 03:33:05PM +0800, Minghsiu Tsai wrote:
> > If the mdp_* nodes are under an mdp sub-node, their corresponding
> > platform device does not automatically get its iommu assigned properly.
> >
> > Fix this by moving the mdp component nodes up a level such that they are
> > siblings of mdp and all other SoC subsystems. This also simplifies the
> > device tree.
>
> It may simplify the DT, but it also breaks compatibility with old DT.
> Not sure if that's a problem on Mediatek platforms, but please be
> explicit here that you are breaking compatibility and why that is okay.
>
I will add the following description for more information.
"
Although it fixes iommu assignment issue, it also break compatibility
with old device tree, so driver patch[1] is needed to iterate over
sibling mdp device nodes, not child ones, to keep driver work properly.
In mtk_mdp_probe()
Old: for_each_child_of_node(dev->of_node, node)
New: for_each_child_of_node(dev->of_node->parent, node)
[1]https://patchwork.kernel.org/patch/9678833/
"
> >
> > Signed-off-by: Daniel Kurtz <djkurtz@chromium.org>
> > Signed-off-by: Minghsiu Tsai <minghsiu.tsai@mediatek.com>
>
> Should this have Daniel as the author?
This patch is provided by Daniel, so I keep he is the author.
I just split his patch into two parts. One is dts only, and the other is
for driver. I also provide another patch to modify dts bindings
according to this patch.
>
> >
> > ---
> > Documentation/devicetree/bindings/media/mediatek-mdp.txt | 12 +++---------
> > 1 file changed, 3 insertions(+), 9 deletions(-)
> >
> > diff --git a/Documentation/devicetree/bindings/media/mediatek-mdp.txt b/Documentation/devicetree/bindings/media/mediatek-mdp.txt
> > index 4182063..0d03e3a 100644
> > --- a/Documentation/devicetree/bindings/media/mediatek-mdp.txt
> > +++ b/Documentation/devicetree/bindings/media/mediatek-mdp.txt
> > @@ -2,7 +2,7 @@
> >
> > Media Data Path is used for scaling and color space conversion.
> >
> > -Required properties (controller (parent) node):
> > +Required properties (controller node):
> > - compatible: "mediatek,mt8173-mdp"
> > - mediatek,vpu: the node of video processor unit, see
> > Documentation/devicetree/bindings/media/mediatek-vpu.txt for details.
> > @@ -32,21 +32,16 @@ Required properties (DMA function blocks, child node):
> > for details.
> >
> > Example:
> > -mdp {
> > - compatible = "mediatek,mt8173-mdp";
> > - #address-cells = <2>;
> > - #size-cells = <2>;
> > - ranges;
> > - mediatek,vpu = <&vpu>;
> > -
> > mdp_rdma0: rdma@14001000 {
> > compatible = "mediatek,mt8173-mdp-rdma";
> > + "mediatek,mt8173-mdp";
> > reg = <0 0x14001000 0 0x1000>;
> > clocks = <&mmsys CLK_MM_MDP_RDMA0>,
> > <&mmsys CLK_MM_MUTEX_32K>;
> > power-domains = <&scpsys MT8173_POWER_DOMAIN_MM>;
> > iommus = <&iommu M4U_PORT_MDP_RDMA0>;
> > mediatek,larb = <&larb0>;
> > + mediatek,vpu = <&vpu>;
> > };
> >
> > mdp_rdma1: rdma@14002000 {
> > @@ -106,4 +101,3 @@ mdp {
> > iommus = <&iommu M4U_PORT_MDP_WROT1>;
> > mediatek,larb = <&larb4>;
> > };
> > -};
> > --
> > 1.9.1
> >
^ permalink raw reply
* [PATCH 08/13] OF/PCI: Add IORESOURCE_MEM_64 for 64-bit resource
From: Yinghai Lu @ 2017-04-21 5:04 UTC (permalink / raw)
To: Bjorn Helgaas, David Miller, Benjamin Herrenschmidt
Cc: Wei Yang, Khalid Aziz, linux-pci, linux-kernel, Yinghai Lu,
Grant Likely, Rob Herring, devicetree
In-Reply-To: <20170421050500.13957-1-yinghai@kernel.org>
For device resource PREF bit setting under bridge 64-bit pref resource,
we need to make sure only set PREF for 64bit resource.
This patch set IORESOUCE_MEM_64 for 64bit resource during OF device
resource flags parsing.
Link: https://bugzilla.kernel.org/show_bug.cgi?id=96261
Link: https://bugzilla.kernel.org/show_bug.cgi?id=96241
Signed-off-by: Yinghai Lu <yinghai@kernel.org>
Cc: Grant Likely <grant.likely@linaro.org>
Cc: Rob Herring <robh+dt@kernel.org>
Cc: devicetree@vger.kernel.org
Tested-by: Khalid Aziz <khalid.aziz@oracle.com>
---
drivers/of/address.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/of/address.c b/drivers/of/address.c
index 02b2903..d1bb76c 100644
--- a/drivers/of/address.c
+++ b/drivers/of/address.c
@@ -131,9 +131,11 @@ static unsigned int of_bus_pci_get_flags(const __be32 *addr)
flags |= IORESOURCE_IO;
break;
case 0x02: /* 32 bits */
- case 0x03: /* 64 bits */
flags |= IORESOURCE_MEM;
break;
+ case 0x03: /* 64 bits */
+ flags |= IORESOURCE_MEM | IORESOURCE_MEM_64;
+ break;
}
if (w & 0x40000000)
flags |= IORESOURCE_PREFETCH;
--
2.9.3
^ permalink raw reply related
* Re: [PATCH net-next v3] bindings: net: stmmac: add missing note about LPI interrupt
From: Giuseppe CAVALLARO @ 2017-04-21 5:26 UTC (permalink / raw)
To: Niklas Cassel, Rob Herring, Mark Rutland, David S. Miller,
Joao Pinto, Niklas Cassel, Alexandre TORGUE, Thierry Reding,
Eric Engestrom
Cc: netdev-u79uwXL29TY76Z2rM5mHXA, devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <20170418123955.21335-1-niklass-VrBV9hrLPhE@public.gmane.org>
On 4/18/2017 2:39 PM, Niklas Cassel wrote:
> From: Niklas Cassel <niklas.cassel-VrBV9hrLPhE@public.gmane.org>
>
> The hardware has a LPI interrupt.
> There is already code in the stmmac driver to parse and handle the
> interrupt. However, this information was missing from the DT binding.
>
> At the same time, improve the description of the existing interrupts.
>
> Signed-off-by: Niklas Cassel <niklas.cassel-VrBV9hrLPhE@public.gmane.org>
> ---
> Documentation/devicetree/bindings/net/stmmac.txt | 13 ++++++++-----
> 1 file changed, 8 insertions(+), 5 deletions(-)
>
> diff --git a/Documentation/devicetree/bindings/net/stmmac.txt b/Documentation/devicetree/bindings/net/stmmac.txt
> index f652b0c384ce..c3a7be6615c5 100644
> --- a/Documentation/devicetree/bindings/net/stmmac.txt
> +++ b/Documentation/devicetree/bindings/net/stmmac.txt
> @@ -7,9 +7,12 @@ Required properties:
> - interrupt-parent: Should be the phandle for the interrupt controller
> that services interrupts for this device
> - interrupts: Should contain the STMMAC interrupts
> -- interrupt-names: Should contain the interrupt names "macirq"
> - "eth_wake_irq" if this interrupt is supported in the "interrupts"
> - property
> +- interrupt-names: Should contain a list of interrupt names corresponding to
> + the interrupts in the interrupts property, if available.
> + Valid interrupt names are:
> + - "macirq" (combined signal for various interrupt events)
> + - "eth_wake_irq" (the interrupt to manage the remote wake-up packet detection)
> + - "eth_lpi" (the interrupt that occurs when Tx or Rx enters/exits LPI state)
> - phy-mode: See ethernet.txt file in the same directory.
> - snps,reset-gpio gpio number for phy reset.
> - snps,reset-active-low boolean flag to indicate if phy reset is active low.
> @@ -152,8 +155,8 @@ Examples:
> compatible = "st,spear600-gmac";
> reg = <0xe0800000 0x8000>;
> interrupt-parent = <&vic1>;
> - interrupts = <24 23>;
> - interrupt-names = "macirq", "eth_wake_irq";
> + interrupts = <24 23 22>;
> + interrupt-names = "macirq", "eth_wake_irq", "eth_lpi";
> mac-address = [000000000000]; /* Filled in by U-Boot */
> max-frame-size = <3800>;
> phy-mode = "gmii";
Acked-by: Giuseppe Cavallaro <peppe.cavallaro-qxv4g6HH51o@public.gmane.org>
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH V5 3/7] ARM: exynos: Use - instead of @ for DT OPP entries
From: Viresh Kumar @ 2017-04-21 5:27 UTC (permalink / raw)
To: Krzysztof Kozlowski
Cc: arm, Chanwoo Choi, MyungJoo Ham, Kyungmin Park, Kukjin Kim,
Javier Martinez Canillas, Rob Herring, Mark Rutland,
linaro-kernel, linux-arm-kernel, linux-pm, Rafael Wysocki,
Masahiro Yamada, Rob Herring, linux-samsung-soc, devicetree,
linux-kernel
In-Reply-To: <20170420160930.halyszjunt4q2634@kozik-lap>
On 20-04-17, 18:09, Krzysztof Kozlowski wrote:
> On Thu, Apr 20, 2017 at 04:25:07PM +0530, Viresh Kumar wrote:
> > Compiling the DT file with W=1, DTC warns like follows:
> >
> > Warning (unit_address_vs_reg): Node /opp_table0/opp@1000000000 has a
> > unit name, but no reg property
> >
> > Fix this by replacing '@' with '-' as the OPP nodes will never have a
> > "reg" property.
> >
> > Reported-by: Krzysztof Kozlowski <krzk@kernel.org>
> > Reported-by: Masahiro Yamada <yamada.masahiro@socionext.com>
> > Suggested-by: Mark Rutland <mark.rutland@arm.com>
> > Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
> > Reviewed-by: Chanwoo Choi <cw00.choi@samsung.com>
> > Reviewed-by: Krzysztof Kozlowski <krzk@kernel.org>
> > Acked-by: Rob Herring <robh@kernel.org>
> > ---
> > .../devicetree/bindings/devfreq/exynos-bus.txt | 46 +++++++--------
> > arch/arm/boot/dts/exynos3250.dtsi | 46 +++++++--------
> > arch/arm/boot/dts/exynos4210.dtsi | 32 +++++------
> > arch/arm/boot/dts/exynos4412-prime.dtsi | 4 +-
> > arch/arm/boot/dts/exynos4412.dtsi | 66 +++++++++++-----------
> > arch/arm/boot/dts/exynos5420.dtsi | 40 ++++++-------
> > arch/arm/boot/dts/exynos5800.dtsi | 56 +++++++++---------
> > arch/arm64/boot/dts/exynos/exynos5433-bus.dtsi | 48 ++++++++--------
> > arch/arm64/boot/dts/exynos/exynos5433.dtsi | 50 ++++++++--------
> > 9 files changed, 194 insertions(+), 194 deletions(-)
>
>
> Thanks, split ARM64 from ARM and applied (for v4.12). arm-soc keeps DTS
> separated between ARM architectures. Technically this should require a
> resend but we had way too many resends for this simple patch.
Bah! Will make sure to send separate patches from now on. Thanks.
--
viresh
^ permalink raw reply
* Re: [PATCH V5 4/7] ARM: pxa: Use - instead of @ for DT OPP entries
From: Viresh Kumar @ 2017-04-21 5:30 UTC (permalink / raw)
To: Robert Jarzmik
Cc: arm, Daniel Mack, Haojian Zhuang, Rob Herring, Mark Rutland,
linaro-kernel, linux-arm-kernel, linux-pm, Rafael Wysocki,
Krzysztof Kozlowski, Masahiro Yamada, Rob Herring, devicetree,
linux-kernel
In-Reply-To: <87a87a7s66.fsf@belgarion.home>
On 20-04-17, 22:14, Robert Jarzmik wrote:
> Viresh Kumar <viresh.kumar@linaro.org> writes:
>
> > Compiling the DT file with W=1, DTC warns like follows:
> >
> > Warning (unit_address_vs_reg): Node /opp_table0/opp@1000000000 has a
> > unit name, but no reg property
> >
> > Fix this by replacing '@' with '-' as the OPP nodes will never have a
> > "reg" property.
> >
> > Reported-by: Krzysztof Kozlowski <krzk@kernel.org>
> > Reported-by: Masahiro Yamada <yamada.masahiro@socionext.com>
> > Suggested-by: Mark Rutland <mark.rutland@arm.com>
> > Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
> > Acked-by: Rob Herring <robh@kernel.org>
> Acked-by: Robert Jarzmik <robert.jarzmik@free.fr>
Thanks. But I need you to pick it up for your pull request for arm-soc.
--
viresh
^ permalink raw reply
* Re: [PATCH 2/8] [RFC] arm64: dts: renesas: Add R-Car H3 SiP (4 x 1 GiB) support
From: Niklas Söderlund @ 2017-04-21 5:42 UTC (permalink / raw)
To: Geert Uytterhoeven
Cc: Simon Horman, Magnus Damm, Kuninori Morimoto, Yoshihiro Shimoda,
Rob Herring, Mark Rutland, linux-renesas-soc, devicetree,
linux-arm-kernel
In-Reply-To: <1492593351-13835-3-git-send-email-geert+renesas@glider.be>
Hi Geert,
Thanks for your work.
On 2017-04-19 11:15:45 +0200, Geert Uytterhoeven wrote:
> Add support for the R-Car H3 System-in-Package (r8j7795), which contains:
> - an R-Car H3 SoC (r8a7795),
> - 4 channels of 1 GiB of RAM (4 GiB total),
> - HyperFlash (not yet described).
>
> Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
> ---
> Questions:
> - Should this file be named r8j7795-4g.dtsi instead?
> - Do other versions (different memory configuration) of r8j7795 exist?
> If yes, how are they named?
> ---
> arch/arm64/boot/dts/renesas/r8j7795-4x1g.dtsi | 36 +++++++++++++++++++++++++++
> 1 file changed, 36 insertions(+)
> create mode 100644 arch/arm64/boot/dts/renesas/r8j7795-4x1g.dtsi
>
> diff --git a/arch/arm64/boot/dts/renesas/r8j7795-4x1g.dtsi b/arch/arm64/boot/dts/renesas/r8j7795-4x1g.dtsi
> new file mode 100644
> index 0000000000000000..02e0ff4a60c53704
> --- /dev/null
> +++ b/arch/arm64/boot/dts/renesas/r8j7795-4x1g.dtsi
> @@ -0,0 +1,36 @@
> +/*
> + * Device Tree Source for the r8j7795 SiP with 4 channels of 1 GiB RAM
> + *
> + * Copyright (C) 2015 Renesas Electronics Corp.
2017 right? If so same comment for patches 3 and 4.
> + *
> + * This file is licensed under the terms of the GNU General Public License
> + * version 2. This program is licensed "as is" without any warranty of any
> + * kind, whether express or implied.
> + */
> +
> +#include "r8a7795.dtsi"
> +
> +/ {
> + compatible = "renesas,r8j7795", "renesas,r8a7795";
> +
> + memory@48000000 {
> + device_type = "memory";
> + /* first 128MB is reserved for secure area. */
> + reg = <0x0 0x48000000 0x0 0x38000000>;
> + };
> +
> + memory@500000000 {
> + device_type = "memory";
> + reg = <0x5 0x00000000 0 0x40000000>;
> + };
> +
> + memory@600000000 {
> + device_type = "memory";
> + reg = <0x6 0x00000000 0 0x40000000>;
> + };
> +
> + memory@700000000 {
> + device_type = "memory";
> + reg = <0x7 0x00000000 0 0x40000000>;
> + };
> +};
> --
> 2.7.4
>
--
Regards,
Niklas Söderlund
^ permalink raw reply
* Re: [PATCH 2/8] [RFC] arm64: dts: renesas: Add R-Car H3 SiP (4 x 1 GiB) support
From: Geert Uytterhoeven @ 2017-04-21 7:04 UTC (permalink / raw)
To: Niklas Söderlund
Cc: Geert Uytterhoeven, Simon Horman, Magnus Damm, Kuninori Morimoto,
Yoshihiro Shimoda, Rob Herring, Mark Rutland, Linux-Renesas,
devicetree@vger.kernel.org, linux-arm-kernel@lists.infradead.org
In-Reply-To: <20170421054201.GR28868@bigcity.dyn.berto.se>
Hi Niklas,
On Fri, Apr 21, 2017 at 7:42 AM, Niklas Söderlund
<niklas.soderlund@ragnatech.se> wrote:
>> --- /dev/null
>> +++ b/arch/arm64/boot/dts/renesas/r8j7795-4x1g.dtsi
>> @@ -0,0 +1,36 @@
>> +/*
>> + * Device Tree Source for the r8j7795 SiP with 4 channels of 1 GiB RAM
>> + *
>> + * Copyright (C) 2015 Renesas Electronics Corp.
>
> 2017 right? If so same comment for patches 3 and 4.
As I just moved statements from an existing file, I retained the original
copyright information.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply
* Re: [PATCH V5 5/7] ARM: sun8i: Use - instead of @ for DT OPP entries
From: Maxime Ripard @ 2017-04-21 7:35 UTC (permalink / raw)
To: Viresh Kumar
Cc: arm, Rob Herring, Mark Rutland, Chen-Yu Tsai, linaro-kernel,
linux-arm-kernel, linux-pm, Rafael Wysocki, Krzysztof Kozlowski,
Masahiro Yamada, Rob Herring, devicetree, linux-kernel
In-Reply-To: <2eb4a6e227f7edfb51ebf3723d5df7e652c703b4.1492685450.git.viresh.kumar@linaro.org>
[-- Attachment #1: Type: text/plain, Size: 797 bytes --]
On Thu, Apr 20, 2017 at 04:25:09PM +0530, Viresh Kumar wrote:
> Compiling the DT file with W=1, DTC warns like follows:
>
> Warning (unit_address_vs_reg): Node /opp_table0/opp@1000000000 has a
> unit name, but no reg property
>
> Fix this by replacing '@' with '-' as the OPP nodes will never have a
> "reg" property.
>
> Reported-by: Krzysztof Kozlowski <krzk@kernel.org>
> Reported-by: Masahiro Yamada <yamada.masahiro@socionext.com>
> Suggested-by: Mark Rutland <mark.rutland@arm.com>
> Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
> Acked-by: Maxime Ripard <maxime.ripard@free-electrons.com>
> Acked-by: Rob Herring <robh@kernel.org>
Applied, thanks!
Maxime
--
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 801 bytes --]
^ permalink raw reply
* Re: [PATCH v6 0/6] add support for AXP20X and AXP22X battery power supply driver
From: Maxime Ripard @ 2017-04-21 7:43 UTC (permalink / raw)
To: Quentin Schulz
Cc: sre-DgEjT+Ai2ygdnm+yROfE0A, robh+dt-DgEjT+Ai2ygdnm+yROfE0A,
mark.rutland-5wv7dgnIgG8, wens-jdAy2FN1RRM,
linux-I+IVW8TIWO2tmTQ+vhA3Yw, linux-pm-u79uwXL29TY76Z2rM5mHXA,
linux-sunxi-/JYPxA39Uh5TLH3MbocFFw, icenowy-ymACFijhrKM,
liam-RYWXG+zxWwBdeoIcmNTgJF6hYfS7NtTn,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r
In-Reply-To: <20170418073421.31351-1-quentin.schulz-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org>
[-- Attachment #1: Type: text/plain, Size: 6108 bytes --]
On Tue, Apr 18, 2017 at 09:34:15AM +0200, Quentin Schulz wrote:
> This is a series for AXP20X and AXP22X battery power supply without the
> support for changing constant charge current from the DT. The patches for
> supporting the constant charge current from DT are ready and will be sent
> once the battery framework required to make this work has been merged.
>
> v6:
> - removed mention to fixed battery in DT-binding documentation,
>
> Quote from v4 cover letter:
>
> The X-Powers AXP20X and AXP22X PMICs have multiple ADCs. They expose
> information and data of the various power supplies they support such as
> ACIN, battery and VBUS. For example, they expose the current battery
> voltage, charge or discharge, as well as ACIN and VBUS current voltages
> and currents, internal PMIC temperature and ADC on 2 different GPIOs
> when in the right mode (for the AXP209 only).
>
> The ACIN power supply driver is added by this patch. The AXP20X and
> AXP22X can both read the status and the "usability" of the power supply
> but only the AXP209 will be able to tell the current current and voltage
> of the power supply by reading ADC channels. It is simply not supported
> by the AXP22X PMICs.
>
> The battery power supply driver is also added by this patch. The AXP20X
> and AXP22X share most of their behaviour but have slight variations. The
> allowed target voltages for battery charging are not the same, the
> AXP22X PMIC are able to tell if the battery percentage computed by the
> PMIC is trustworthy and they have different formulas for computing max
> current for battery power supply. The driver is able to give the current
> voltage and current of the battery (be it charging or discharging), the
> maximal and minimal voltage and maximal current allowed for the battery,
> whether the battery is present and usable and its capacity. It will get
> the battery current current and voltage by reading the ADC channels. The
> PMIC allows maximal voltages (4.36V for AXP20X and 4.22V and 4.24V for
> AXP22X) that should not be used with Lithium-based batteries and since
> this PMIC is supposed to be used with Lithium-based batteries, they have
> been disabled. The values returned by the ADC driver are multipled by
> 1000 to scale from the mV returned by the ADC to the uV expected by the
> power supply framework.
>
> This series of patch adds DT bindings for ACIN power supply, ADC and
> battery power supply drivers for AXP20X and AXP22X PMICs and their
> documentation. It also enables the supported power supplies for the
> Nextthing Co. CHIP and Sinlinx SinA33 boards.
>
> The different drivers are also added to the MFD cells of the AXP20X and
> AXP22X cells and the writeable and volatile regs updated to work with
> the newly added drivers.
>
> This series of patch is based on a previous upstreaming attempt done by
> Bruno Prémont few months ago. It differs in three points: the ADC
> driver does not tell the battery temperature (TS_IN) as I do not have a
> board to test it with, it does not tell the instantaneous battery power
> as it returns crazy values for me and finally no support for OCV curves
> for the battery.
>
> You can test these patches from this repo and branch:
> https://github.com/QSchulz/linux/tree/axp2xx_adc_batt_ac_v4
>
> v4:
> - added the ability to set maximum constant charge current from sysfs,
> - added a warning when setting a higher than current maximum constant charge
> current,
> - set default to minimum possible value for current and maximum constant charge
> current when no battery DT is present or invalid battery DT,
> - fixed a forgotten custom formula to compute maximum constant charge current
> for AXP22X,
> - automatically lower the current constant charge current when it is higher
> than the maximum constant charge current about to be set,
>
> v3:
> - Removed DT property for constant charge current in favor of the WIP
> battery framework as requested by Sebastian Reichel,
> - Using a simple if condition instead of a switch in the ADC driver,
> - Fixed error handling in ADC driver's probe,
> - Fixed missing call to iio_map_array_unregister in the ADC driver's
> remove,
> - Removed ADC driver's DT node and documentation,
> - Merged IIO channel mapping patches into the original ADC driver
> patch,
> - Removed `adding V-OFF to writeable reg' patch as it's already in
> writeable reg range,
>
> v2:
> - Some registers' name have been changed to better reflect their
> purpose,
> - Make VBUS power supply driver use IIO channels when AXP ADC driver is
> enabled, but fall back on previous behavior when disabled. This is made
> to avoid the ADC driver overwritting registers for VBUS power supply
> ADC when removed,
> - Removed useless adding of data registers to volatile registers,
> - Reordered IIO channels, now grouped by same part of the PMIC (e.g.
> voltage and current of the battery have the same index in different
> IIO types),
> - Added structures for specific data instead of matching on IDs,
> - Switched from DT IIO channels mapping to iio_map structures IIO
> channels mapping,
>
> Quentin
>
> Quentin Schulz (6):
> dt-bindings: power: supply: add AXP20X/AXP22X battery DT binding
> power: supply: add battery driver for AXP20X and AXP22X PMICs
> ARM: dtsi: axp209: add battery power supply subnode
> ARM: dtsi: axp22x: add battery power supply subnode
> ARM: dts: sun8i: sina33: enable battery power supply subnode
> ARM: sun5i: chip: enable battery power supply subnode
Applied the last 4 patches.
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.
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 801 bytes --]
^ permalink raw reply
* [PATCH 1/2 v3 resend] video: fbdev: imxfb: support AUS mode
From: Martin Kaiser @ 2017-04-21 7:45 UTC (permalink / raw)
To: linux-fbdev-u79uwXL29TY76Z2rM5mHXA
Cc: Bartlomiej Zolnierkiewicz, Sascha Hauer,
linux-kernel-u79uwXL29TY76Z2rM5mHXA, Rob Herring, Mark Rutland,
devicetree-u79uwXL29TY76Z2rM5mHXA, Martin Kaiser
In-Reply-To: <1488193030-13064-1-git-send-email-martin-XxZfDwE/svGeZLLa646FqQ@public.gmane.org>
Some displays require setting AUS mode in the LDCD AUS Mode Control
Register to work with the imxfb driver. Like the value of the Panel
Configuration Register, the AUS mode setting depends on the display
mode.
Allow setting AUS mode from the device tree by adding a boolean
property. Make this property optional to keep the DT ABI stable.
AUS mode can be set only on imx21 and compatible chipsets.
Signed-off-by: Martin Kaiser <martin-XxZfDwE/svGeZLLa646FqQ@public.gmane.org>
---
re-sending v3, rebased against current linux-next
it seems this got lost along the way, there was a bit of confusion
whether to split this in two patches or not
v3:
use a boolean DT property instead of the register value
separate patches for DT binding and code changes
v2:
re-sending DT bindings and code changes as one patch
drivers/video/fbdev/imxfb.c | 17 +++++++++++++++++
include/linux/platform_data/video-imxfb.h | 1 +
2 files changed, 18 insertions(+)
diff --git a/drivers/video/fbdev/imxfb.c b/drivers/video/fbdev/imxfb.c
index 1b0faad..463fbf2 100644
--- a/drivers/video/fbdev/imxfb.c
+++ b/drivers/video/fbdev/imxfb.c
@@ -117,6 +117,9 @@
#define IMXFB_LSCR1_DEFAULT 0x00120300
+#define LCDC_LAUSCR 0x80
+#define LAUSCR_AUS_MODE (1<<31)
+
/* Used fb-mode. Can be set on kernel command line, therefore file-static. */
static const char *fb_mode;
@@ -158,6 +161,7 @@ struct imxfb_info {
dma_addr_t dbar2;
u_int pcr;
+ u_int lauscr;
u_int pwmr;
u_int lscr1;
u_int dmacr;
@@ -422,6 +426,11 @@ static int imxfb_check_var(struct fb_var_screeninfo *var, struct fb_info *info)
pcr |= imxfb_mode->pcr & ~(0x3f | (7 << 25));
fbi->pcr = pcr;
+ /*
+ * The LCDC AUS Mode Control Register does not exist on imx1.
+ */
+ if (!is_imx1_fb(fbi) && imxfb_mode->aus_mode)
+ fbi->lauscr = LAUSCR_AUS_MODE;
/*
* Copy the RGB parameters for this display
@@ -638,6 +647,9 @@ static int imxfb_activate_var(struct fb_var_screeninfo *var, struct fb_info *inf
if (fbi->dmacr)
writel(fbi->dmacr, fbi->regs + LCDC_DMACR);
+ if (fbi->lauscr)
+ writel(fbi->lauscr, fbi->regs + LCDC_LAUSCR);
+
return 0;
}
@@ -734,6 +746,11 @@ static int imxfb_of_read_mode(struct device *dev, struct device_node *np,
imxfb_mode->bpp = bpp;
imxfb_mode->pcr = pcr;
+ /*
+ * fsl,aus_mode is optional
+ */
+ imxfb_mode->aus_mode = of_property_read_bool(np, "fsl,aus_mode");
+
return 0;
}
diff --git a/include/linux/platform_data/video-imxfb.h b/include/linux/platform_data/video-imxfb.h
index a5c0a71..cf9348b 100644
--- a/include/linux/platform_data/video-imxfb.h
+++ b/include/linux/platform_data/video-imxfb.h
@@ -50,6 +50,7 @@
struct imx_fb_videomode {
struct fb_videomode mode;
u32 pcr;
+ bool aus_mode;
unsigned char bpp;
};
--
2.1.4
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply related
* [PATCH 2/2 v3 resend] dt-bindings: display: imx: entry for AUS mode
From: Martin Kaiser @ 2017-04-21 7:45 UTC (permalink / raw)
To: linux-fbdev
Cc: Bartlomiej Zolnierkiewicz, Sascha Hauer, linux-kernel,
Rob Herring, Mark Rutland, devicetree, Martin Kaiser
In-Reply-To: <1492760753-8374-1-git-send-email-martin@kaiser.cx>
Allow setting the AUS mode for a display from the device tree.
Use an optional boolean property. AUS mode can be set only on imx21
and compatible chipsets.
Signed-off-by: Martin Kaiser <martin@kaiser.cx>
Acked-by: Rob Herring <robh@kernel.org>
---
re-sending v3, rebased against current linux-next
it seems this got lost along the way, there was a bit of confusion
whether to split this in two patches or not
v3:
use a boolean DT property instead of the register value
separate patches for DT binding and code changes
v2:
re-sending DT bindings and code changes as one patch
Documentation/devicetree/bindings/display/imx/fsl,imx-fb.txt | 2 ++
1 file changed, 2 insertions(+)
diff --git a/Documentation/devicetree/bindings/display/imx/fsl,imx-fb.txt b/Documentation/devicetree/bindings/display/imx/fsl,imx-fb.txt
index 7a5c0e2..cacae0e 100644
--- a/Documentation/devicetree/bindings/display/imx/fsl,imx-fb.txt
+++ b/Documentation/devicetree/bindings/display/imx/fsl,imx-fb.txt
@@ -13,6 +13,8 @@ Required nodes:
Additional, the display node has to define properties:
- bits-per-pixel: Bits per pixel
- fsl,pcr: LCDC PCR value
+ A display node may optionally define
+ - fsl,aus_mode: boolean to enable AUS mode (only for imx21)
Optional properties:
- lcd-supply: Regulator for LCD supply voltage.
--
2.1.4
^ permalink raw reply related
* Re: [PATCH] media: mtk-vcodec: remove informative log
From: Tiffany Lin @ 2017-04-21 8:04 UTC (permalink / raw)
To: Mauro Carvalho Chehab
Cc: devicetree, daniel.thompson, Minghsiu Tsai, srv_heupstream,
Wu-Cheng Li, linux-mediatek, linux-kernel, Daniel Kurtz,
Rob Herring, Hans Verkuil, linux-arm-kernel, Matthias Brugger,
Yingjoe Chen, Eddie Huang, Pawel Osciak, linux-media
In-Reply-To: <20170419075643.0a04af21@vento.lan>
On Wed, 2017-04-19 at 07:56 -0300, Mauro Carvalho Chehab wrote:
> Em Wed, 5 Apr 2017 19:09:59 +0800
> Tiffany Lin <tiffany.lin@mediatek.com> escreveu:
>
> > On Wed, 2017-04-05 at 18:54 +0800, Minghsiu Tsai wrote:
> > > Driver is stable. Remove DEBUG definition from driver.
> > >
> > > There are debug message in /var/log/messages if DEBUG is defined,
> > > such as:
> > > [MTK_V4L2] level=0 fops_vcodec_open(),170: decoder capability 0
> > > [MTK_V4L2] level=0 fops_vcodec_open(),177: 16000000.vcodec decoder [0]
> > > [MTK_V4L2] level=0 fops_vcodec_release(),200: [0] decoder
> > >
> > > Signed-off-by: Minghsiu Tsai <minghsiu.tsai@mediatek.com>
> > Acked-by:Tiffany Lin <Tiffany.lin@mediatek.com>
> >
> > > ---
> > > drivers/media/platform/mtk-vcodec/mtk_vcodec_util.h | 1 -
> > > 1 file changed, 1 deletion(-)
> > >
> > > diff --git a/drivers/media/platform/mtk-vcodec/mtk_vcodec_util.h b/drivers/media/platform/mtk-vcodec/mtk_vcodec_util.h
> > > index 7d55975..1248083 100644
> > > --- a/drivers/media/platform/mtk-vcodec/mtk_vcodec_util.h
> > > +++ b/drivers/media/platform/mtk-vcodec/mtk_vcodec_util.h
> > > @@ -31,7 +31,6 @@ struct mtk_vcodec_mem {
> > > extern int mtk_v4l2_dbg_level;
> > > extern bool mtk_vcodec_dbg;
> > >
> > > -#define DEBUG 1
> > >
> > > #if defined(DEBUG)
> > >
>
> After this patch, building the Kernel with W=1 now shows warnings:
>
> drivers/media/platform/mtk-vcodec/mtk_vcodec_dec_pm.c: In function 'mtk_vcodec_dec_pw_on':
> drivers/media/platform/mtk-vcodec/mtk_vcodec_dec_pm.c:114:51: warning: suggest braces around empty body in an 'if' statement [-Wempty-body]
> mtk_v4l2_err("pm_runtime_get_sync fail %d", ret);
> ^
>
> I wrote a patch fixing it, as this is really a trivial issue.
>
> Yet, after that, this one still remains:
>
>
> drivers/media/platform/mtk-vcodec/mtk_vcodec_dec.c: In function 'mtk_vdec_pic_info_update':
> drivers/media/platform/mtk-vcodec/mtk_vcodec_dec.c:284:6: warning: variable 'ret' set but not used [-Wunused-but-set-variable]
> int ret;
> ^~~
>
>
> Shouldn't be mtk_vdec_pic_info_update() returning an error code?
>
>
> Also, IMHO, at least errors should be shown at dmesg.
>
Got it. We will upstream patch to fix warning and add dmesg when error.
best regards,
Tiffany
> Thanks,
> Mauro
^ permalink raw reply
* Re: [PATCH v4 06/11] drm/sun4i: add support for Allwinner DE2 mixers
From: icenowy-h8G6r0blFSE @ 2017-04-21 8:18 UTC (permalink / raw)
To: linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r, Maxime Ripard
Cc: devicetree-u79uwXL29TY76Z2rM5mHXA, Jernej Skrabec, David Airlie,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
dri-devel-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW,
linux-sunxi-/JYPxA39Uh5TLH3MbocFFw, Rob Herring, Chen-Yu Tsai,
linux-clk-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <20170420083707.wdtrdlxpvocpzc7g@lukather>
于 2017年4月20日 GMT+08:00 下午4:37:07, Maxime Ripard
<maxime.ripard-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org> 写到:
> On Tue, Apr 18, 2017 at 06:47:56PM +0800, Icenowy Zheng wrote:
>> >> + /* Get the physical address of the buffer in memory */
>> >> + gem = drm_fb_cma_get_gem_obj(fb, 0);
>> >> +
>> >> + DRM_DEBUG_DRIVER("Using GEM @ %pad\n", &gem->paddr);
>> >> +
>> >> + /* Compute the start of the displayed memory */
>> >> + bpp = fb->format->cpp[0];
>> >> + paddr = gem->paddr + fb->offsets[0];
>> >> + paddr += (state->src_x >> 16) * bpp;
>> >> + paddr += (state->src_y >> 16) * fb->pitches[0];
>> >> +
>> >> + DRM_DEBUG_DRIVER("Setting buffer address to %pad\n", &paddr);
>> >> +
>> >> + paddr_u32 = (uint32_t) paddr;
>> >
>> >How does that work on 64-bits systems ?
>>
>> The hardware is not designed to work on 64-bit systems.
>>
>> Even 64-bit A64/H5 has also 3GiB memory limit.
>
> That's a fragile assumption.
Yes, it's only the basical reason.
>
>> The address cell in mixer hardware is also only 32-bit.
>>
>> So we should just keep the force conversion here. If we then really
>> met 4GiB-capable AW SoC without changing DE2, I think we should have
>> other way to limit CMA pool inside 4GiB.
>
> The register name looks like this is only the lower 32 bits that you
> can set here, and that there is another register for the upper 32 bits
> of that address somewhere.
Maybe... but no one can verify this as their's no currently any user
which has 4GiB+ DRAM.
I think we should keep this until Allwinner really made a 4GiB-capable
hardware.
>
> In that case, please use the lower_32_bits and upper_32_bits helper,
> and don't cast it that way.
>
> If it isn't the case, you should set the DMA mask (through
> dma_set_mask) so that we only allocate memory that can be accessed by
> this device.
How to do it?
>
> Maxime
--
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
* [PATCH v2 0/9] drm/sun4i: Support multiple display pipelines
From: Chen-Yu Tsai @ 2017-04-21 8:38 UTC (permalink / raw)
To: Maxime Ripard, David Airlie, Rob Herring, Mark Rutland
Cc: Chen-Yu Tsai, dri-devel-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-sunxi-/JYPxA39Uh5TLH3MbocFFw
Hi,
This is v2 of the series previously named "drm/sun4i: Support two
display pipelines". As the name change suggests, the driver now
supports any number of pipelines, though the hardware only has
2 or 3.
Changes since v1:
- Add component endpoint ID numbering scheme to device tree binding.
- Use lists to keep references to registered backends and tcons.
- Save pointer to device node for backends.
- Traverse the device tree of_graph starting from the tcons, going
up towards the inputs, and matching the device nodes with the
device nodes of registered backends, to find the one linked with
the tcon the search started from.
- Copy the ID for the tcon from its upstream backend, instead of
trying, and possibly failing, to figure it out from the device
tree.
- Split out hunk dropping trailing 0 from a backend error message.
Patch 1 adds the component endpoint ID numbering scheme to the
device tree binding. New in v2.
Patch 2 adds lists to track registered display backends and TCONs,
instead of just one pointer per component type. Previously added
arrays of pointers in v1.
Patch 3 drops the trailing 0 from one of the backend's bind error
messages. This was previously part of the patch "drm/sun4i: Support
two display pipelines".
Patch 4 adds a function to fetch a backend's ID from the device tree.
Unchanged.
Patch 5 adds a device node field to the backend data structure and
saves a reference to the underlying device node of the backend.
New in v2.
Patch 6 makes the tcon driver find its upstream backend by traversing
the of_graph and matching device nodes against the device nodes of
registered backends.
New in v2.
Patch 7 makes the tcon driver use the ID from its associated backend.
New in v2. This is not immediately used in this series, but will be
used in similar fashion for downstream encoders to figure out IDs and
muxing
Patch 8 adds device nodes for sun6i's second display pipeline.
Unchanged.
Patch 9 enables sun6i's tcon0 by default.
Unchanged.
With this series, the sun4i drm driver now supports registering multiple
display pipelines. However the driver does not guard against setups the
hardware does not support, such as driving 2 encoders with incompatible
dot clocks from the same source clock. Muxing of downstream encoders is
not supported either, as we have no drivers for hardware that uses them.
The WiP HDMI driver will be the first.
While this series enables the second display pipeline, there's no
usable output at the moment. For the A31, the second TCON's panel
interface uses the same pins as the Ethernet controller. However
Ethernet is used on most boards.
Regards
ChenYu
Chen-Yu Tsai (9):
dt-bindings: display: sun4i: Add component endpoint ID numbering
scheme
drm/sun4i: Use lists to track registered display backends and TCONs
drm/sun4i: backend: Drop trailing 0 from backend in error message
drm/sun4i: backend: Fetch backend ID from device tree
drm/sun4i: backend: Save pointer to device tree node
drm/sun4i: tcon: Find matching display backend by device node matching
drm/sun4i: tcon: Copy ID from associated backend
ARM: dts: sun6i: Add second display pipeline device nodes
ARM: dts: sun6i: Enable tcon0 by default
.../bindings/display/sunxi/sun4i-drm.txt | 10 ++
arch/arm/boot/dts/sun6i-a31-hummingbird.dts | 1 -
arch/arm/boot/dts/sun6i-a31.dtsi | 169 ++++++++++++++++++++-
drivers/gpu/drm/sun4i/sun4i_backend.c | 53 ++++++-
drivers/gpu/drm/sun4i/sun4i_backend.h | 8 +
drivers/gpu/drm/sun4i/sun4i_drv.c | 2 +
drivers/gpu/drm/sun4i/sun4i_drv.h | 4 +-
drivers/gpu/drm/sun4i/sun4i_tcon.c | 62 +++++++-
drivers/gpu/drm/sun4i/sun4i_tcon.h | 6 +
9 files changed, 307 insertions(+), 8 deletions(-)
--
2.11.0
^ permalink raw reply
* [PATCH v2 1/9] dt-bindings: display: sun4i: Add component endpoint ID numbering scheme
From: Chen-Yu Tsai @ 2017-04-21 8:38 UTC (permalink / raw)
To: Maxime Ripard, David Airlie, Rob Herring, Mark Rutland
Cc: Chen-Yu Tsai, dri-devel-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-sunxi-/JYPxA39Uh5TLH3MbocFFw
In-Reply-To: <20170421083857.29636-1-wens-jdAy2FN1RRM@public.gmane.org>
The Allwinner display pipeline contains many hardware components, some
of which can consume data from one of multiple upstream components.
The numbering scheme of these components must be encoded into the device
tree so the driver can figure out which component out of two or more of
the same type it is supposed to use or program.
This patch adds the constraint that local endpoint IDs must be the index
or number of the remote endpoint's hardware block, for all components
in the display pipeline up to the TCONs.
Signed-off-by: Chen-Yu Tsai <wens-jdAy2FN1RRM@public.gmane.org>
---
Documentation/devicetree/bindings/display/sunxi/sun4i-drm.txt | 10 ++++++++++
1 file changed, 10 insertions(+)
diff --git a/Documentation/devicetree/bindings/display/sunxi/sun4i-drm.txt b/Documentation/devicetree/bindings/display/sunxi/sun4i-drm.txt
index 57a8d0610062..7acdbf14ae1c 100644
--- a/Documentation/devicetree/bindings/display/sunxi/sun4i-drm.txt
+++ b/Documentation/devicetree/bindings/display/sunxi/sun4i-drm.txt
@@ -4,6 +4,16 @@ Allwinner A10 Display Pipeline
The Allwinner A10 Display pipeline is composed of several components
that are going to be documented below:
+For the input port of all components up to the TCON in the display
+pipeline, if there are multiple components, the local endpoint IDs
+must correspond to the index of the upstream block. For example, if
+the remote endpoint is Frontend 1, then the local endpoint ID must
+be 1.
+
+Conversely, for the output ports of the same group, the remote endpoint
+ID must be the index of the local hardware block. If the local backend
+is backend 1, then the remote endpoint ID must be 1.
+
TV Encoder
----------
--
2.11.0
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply related
* [PATCH v2 2/9] drm/sun4i: Use lists to track registered display backends and TCONs
From: Chen-Yu Tsai @ 2017-04-21 8:38 UTC (permalink / raw)
To: Maxime Ripard, David Airlie, Rob Herring, Mark Rutland
Cc: Chen-Yu Tsai, dri-devel-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-sunxi-/JYPxA39Uh5TLH3MbocFFw
In-Reply-To: <20170421083857.29636-1-wens-jdAy2FN1RRM@public.gmane.org>
To support multiple display pipelines, we need to keep track of the
multiple display backends and TCONs registered with the driver.
Switch to lists to track registered components. Components are only
appended to their respective lists if the bind process was successful.
The TCON bind function now defers if a backend was not registered.
Signed-off-by: Chen-Yu Tsai <wens-jdAy2FN1RRM@public.gmane.org>
---
drivers/gpu/drm/sun4i/sun4i_backend.c | 6 +++++-
drivers/gpu/drm/sun4i/sun4i_backend.h | 4 ++++
drivers/gpu/drm/sun4i/sun4i_drv.c | 2 ++
drivers/gpu/drm/sun4i/sun4i_drv.h | 4 +++-
drivers/gpu/drm/sun4i/sun4i_tcon.c | 14 ++++++++++++--
drivers/gpu/drm/sun4i/sun4i_tcon.h | 4 ++++
6 files changed, 30 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/sun4i/sun4i_backend.c b/drivers/gpu/drm/sun4i/sun4i_backend.c
index d660741ba475..95a77c6a9161 100644
--- a/drivers/gpu/drm/sun4i/sun4i_backend.c
+++ b/drivers/gpu/drm/sun4i/sun4i_backend.c
@@ -19,6 +19,7 @@
#include <drm/drm_plane_helper.h>
#include <linux/component.h>
+#include <linux/list.h>
#include <linux/reset.h>
#include "sun4i_backend.h"
@@ -310,7 +311,6 @@ static int sun4i_backend_bind(struct device *dev, struct device *master,
if (!backend)
return -ENOMEM;
dev_set_drvdata(dev, backend);
- drv->backend = backend;
res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
regs = devm_ioremap_resource(dev, res);
@@ -369,6 +369,8 @@ static int sun4i_backend_bind(struct device *dev, struct device *master,
}
}
+ list_add_tail(&backend->list, &drv->backend_list);
+
/* Reset the registers */
for (i = 0x800; i < 0x1000; i += 4)
regmap_write(backend->regs, i, 0);
@@ -400,6 +402,8 @@ static void sun4i_backend_unbind(struct device *dev, struct device *master,
{
struct sun4i_backend *backend = dev_get_drvdata(dev);
+ list_del(&backend->list);
+
if (of_device_is_compatible(dev->of_node,
"allwinner,sun8i-a33-display-backend"))
sun4i_backend_free_sat(dev);
diff --git a/drivers/gpu/drm/sun4i/sun4i_backend.h b/drivers/gpu/drm/sun4i/sun4i_backend.h
index 83e63cc702b4..9c8287309c65 100644
--- a/drivers/gpu/drm/sun4i/sun4i_backend.h
+++ b/drivers/gpu/drm/sun4i/sun4i_backend.h
@@ -14,6 +14,7 @@
#define _SUN4I_BACKEND_H_
#include <linux/clk.h>
+#include <linux/list.h>
#include <linux/regmap.h>
#include <linux/reset.h>
@@ -149,6 +150,9 @@ struct sun4i_backend {
struct clk *sat_clk;
struct reset_control *sat_reset;
+
+ /* Backend list management */
+ struct list_head list;
};
void sun4i_backend_apply_color_correction(struct sun4i_backend *backend);
diff --git a/drivers/gpu/drm/sun4i/sun4i_drv.c b/drivers/gpu/drm/sun4i/sun4i_drv.c
index 767bbadcc85d..89c51fd6e9af 100644
--- a/drivers/gpu/drm/sun4i/sun4i_drv.c
+++ b/drivers/gpu/drm/sun4i/sun4i_drv.c
@@ -101,6 +101,8 @@ static int sun4i_drv_bind(struct device *dev)
goto free_drm;
}
drm->dev_private = drv;
+ INIT_LIST_HEAD(&drv->backend_list);
+ INIT_LIST_HEAD(&drv->tcon_list);
ret = of_reserved_mem_device_init(dev);
if (ret && ret != -ENODEV) {
diff --git a/drivers/gpu/drm/sun4i/sun4i_drv.h b/drivers/gpu/drm/sun4i/sun4i_drv.h
index 5df50126ff52..835bdb5cc0c2 100644
--- a/drivers/gpu/drm/sun4i/sun4i_drv.h
+++ b/drivers/gpu/drm/sun4i/sun4i_drv.h
@@ -14,10 +14,12 @@
#define _SUN4I_DRV_H_
#include <linux/clk.h>
+#include <linux/list.h>
#include <linux/regmap.h>
struct sun4i_drv {
- struct sun4i_backend *backend;
+ struct list_head backend_list;
+ struct list_head tcon_list;
struct sun4i_tcon *tcon;
struct drm_fbdev_cma *fbdev;
diff --git a/drivers/gpu/drm/sun4i/sun4i_tcon.c b/drivers/gpu/drm/sun4i/sun4i_tcon.c
index 3ced0b1cef6e..52f37ef9a050 100644
--- a/drivers/gpu/drm/sun4i/sun4i_tcon.c
+++ b/drivers/gpu/drm/sun4i/sun4i_tcon.c
@@ -26,6 +26,7 @@
#include <linux/regmap.h>
#include <linux/reset.h>
+#include "sun4i_backend.h"
#include "sun4i_crtc.h"
#include "sun4i_dotclock.h"
#include "sun4i_drv.h"
@@ -476,14 +477,18 @@ static int sun4i_tcon_bind(struct device *dev, struct device *master,
{
struct drm_device *drm = data;
struct sun4i_drv *drv = drm->dev_private;
+ struct sun4i_backend *backend;
struct sun4i_tcon *tcon;
int ret;
+ /* Wait for a backend to be registered */
+ if (list_empty(&drv->backend_list))
+ return -EPROBE_DEFER;
+
tcon = devm_kzalloc(dev, sizeof(*tcon), GFP_KERNEL);
if (!tcon)
return -ENOMEM;
dev_set_drvdata(dev, tcon);
- drv->tcon = tcon;
tcon->drm = drm;
tcon->dev = dev;
tcon->quirks = of_device_get_match_data(dev);
@@ -528,7 +533,9 @@ static int sun4i_tcon_bind(struct device *dev, struct device *master,
goto err_free_dotclock;
}
- tcon->crtc = sun4i_crtc_init(drm, drv->backend, tcon);
+ backend = list_first_entry(&drv->backend_list,
+ struct sun4i_backend, list);
+ tcon->crtc = sun4i_crtc_init(drm, backend, tcon);
if (IS_ERR(tcon->crtc)) {
dev_err(dev, "Couldn't create our CRTC\n");
ret = PTR_ERR(tcon->crtc);
@@ -539,6 +546,8 @@ static int sun4i_tcon_bind(struct device *dev, struct device *master,
if (ret < 0)
goto err_free_clocks;
+ list_add_tail(&tcon->list, &drv->tcon_list);
+
return 0;
err_free_dotclock:
@@ -555,6 +564,7 @@ static void sun4i_tcon_unbind(struct device *dev, struct device *master,
{
struct sun4i_tcon *tcon = dev_get_drvdata(dev);
+ list_del(&tcon->list);
sun4i_dclk_free(tcon);
sun4i_tcon_free_clocks(tcon);
}
diff --git a/drivers/gpu/drm/sun4i/sun4i_tcon.h b/drivers/gpu/drm/sun4i/sun4i_tcon.h
index f636343a935d..1bda4d183eec 100644
--- a/drivers/gpu/drm/sun4i/sun4i_tcon.h
+++ b/drivers/gpu/drm/sun4i/sun4i_tcon.h
@@ -17,6 +17,7 @@
#include <drm/drm_crtc.h>
#include <linux/kernel.h>
+#include <linux/list.h>
#include <linux/reset.h>
#define SUN4I_TCON_GCTL_REG 0x0
@@ -172,6 +173,9 @@ struct sun4i_tcon {
/* Associated crtc */
struct sun4i_crtc *crtc;
+
+ /* TCON list management */
+ struct list_head list;
};
struct drm_bridge *sun4i_tcon_find_bridge(struct device_node *node);
--
2.11.0
^ permalink raw reply related
* [PATCH v2 3/9] drm/sun4i: backend: Drop trailing 0 from backend in error message
From: Chen-Yu Tsai @ 2017-04-21 8:38 UTC (permalink / raw)
To: Maxime Ripard, David Airlie, Rob Herring, Mark Rutland
Cc: Chen-Yu Tsai, dri-devel-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-sunxi-/JYPxA39Uh5TLH3MbocFFw
In-Reply-To: <20170421083857.29636-1-wens-jdAy2FN1RRM@public.gmane.org>
Now that we support multiple instances of backends, the trailing 0
implying only one backend no longer makes sense.
Signed-off-by: Chen-Yu Tsai <wens-jdAy2FN1RRM@public.gmane.org>
---
drivers/gpu/drm/sun4i/sun4i_backend.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/sun4i/sun4i_backend.c b/drivers/gpu/drm/sun4i/sun4i_backend.c
index 95a77c6a9161..e17e20036aa3 100644
--- a/drivers/gpu/drm/sun4i/sun4i_backend.c
+++ b/drivers/gpu/drm/sun4i/sun4i_backend.c
@@ -320,7 +320,7 @@ static int sun4i_backend_bind(struct device *dev, struct device *master,
backend->regs = devm_regmap_init_mmio(dev, regs,
&sun4i_backend_regmap_config);
if (IS_ERR(backend->regs)) {
- dev_err(dev, "Couldn't create the backend0 regmap\n");
+ dev_err(dev, "Couldn't create the backend regmap\n");
return PTR_ERR(backend->regs);
}
--
2.11.0
^ permalink raw reply related
* [PATCH v2 4/9] drm/sun4i: backend: Fetch backend ID from device tree
From: Chen-Yu Tsai @ 2017-04-21 8:38 UTC (permalink / raw)
To: Maxime Ripard, David Airlie, Rob Herring, Mark Rutland
Cc: Chen-Yu Tsai, dri-devel-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-sunxi-/JYPxA39Uh5TLH3MbocFFw
In-Reply-To: <20170421083857.29636-1-wens-jdAy2FN1RRM@public.gmane.org>
Some Allwinner SoCs have 2 display pipelines, as in 2 of each
components, including the frontend, backend, TCON, and any other
extras.
As the backend and TCON are always paired together and form the CRTC,
we need to know which backend or TCON we are currently probing, so we
can pair them when initializing the CRTC.
This patch figures out the backend's ID from the device tree and stores
it in the backend's data structure. It does this by looking at the "reg"
property of any remote endpoints connected to the backend's input port.
Signed-off-by: Chen-Yu Tsai <wens-jdAy2FN1RRM@public.gmane.org>
---
drivers/gpu/drm/sun4i/sun4i_backend.c | 44 +++++++++++++++++++++++++++++++++++
drivers/gpu/drm/sun4i/sun4i_backend.h | 2 ++
2 files changed, 46 insertions(+)
diff --git a/drivers/gpu/drm/sun4i/sun4i_backend.c b/drivers/gpu/drm/sun4i/sun4i_backend.c
index e17e20036aa3..0b4222312e49 100644
--- a/drivers/gpu/drm/sun4i/sun4i_backend.c
+++ b/drivers/gpu/drm/sun4i/sun4i_backend.c
@@ -20,6 +20,7 @@
#include <linux/component.h>
#include <linux/list.h>
+#include <linux/of_graph.h>
#include <linux/reset.h>
#include "sun4i_backend.h"
@@ -289,6 +290,45 @@ static int sun4i_backend_free_sat(struct device *dev) {
return 0;
}
+/*
+ * The display backend can take video output from the display frontend, or
+ * the display enhancement unit on the A80, as input for one it its layers.
+ * This relationship within the display pipeline is encoded in the device
+ * tree with of_graph, and we use it here to figure out which backend, if
+ * there are 2 or more, we are currently probing. The number would be in
+ * the "reg" property of the upstream output port endpoint.
+ */
+static int sun4i_backend_of_get_id(struct device_node *node)
+{
+ struct device_node *port, *ep;
+ int ret = -EINVAL;
+
+ /* input is port 0 */
+ port = of_graph_get_port_by_id(node, 0);
+ if (!port)
+ return -EINVAL;
+
+ /* try finding an upstream endpoint */
+ for_each_available_child_of_node(port, ep) {
+ struct device_node *remote;
+ u32 reg;
+
+ remote = of_parse_phandle(ep, "remote-endpoint", 0);
+ if (!remote)
+ continue;
+
+ ret = of_property_read_u32(remote, "reg", ®);
+ if (ret)
+ continue;
+
+ ret = reg;
+ }
+
+ of_node_put(port);
+
+ return ret;
+}
+
static struct regmap_config sun4i_backend_regmap_config = {
.reg_bits = 32,
.val_bits = 32,
@@ -312,6 +352,10 @@ static int sun4i_backend_bind(struct device *dev, struct device *master,
return -ENOMEM;
dev_set_drvdata(dev, backend);
+ backend->id = sun4i_backend_of_get_id(dev->of_node);
+ if (backend->id < 0)
+ return backend->id;
+
res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
regs = devm_ioremap_resource(dev, res);
if (IS_ERR(regs))
diff --git a/drivers/gpu/drm/sun4i/sun4i_backend.h b/drivers/gpu/drm/sun4i/sun4i_backend.h
index 9c8287309c65..45b7fc110590 100644
--- a/drivers/gpu/drm/sun4i/sun4i_backend.h
+++ b/drivers/gpu/drm/sun4i/sun4i_backend.h
@@ -151,6 +151,8 @@ struct sun4i_backend {
struct clk *sat_clk;
struct reset_control *sat_reset;
+ int id;
+
/* Backend list management */
struct list_head list;
};
--
2.11.0
^ permalink raw reply related
* [PATCH v2 5/9] drm/sun4i: backend: Save pointer to device tree node
From: Chen-Yu Tsai @ 2017-04-21 8:38 UTC (permalink / raw)
To: Maxime Ripard, David Airlie, Rob Herring, Mark Rutland
Cc: Chen-Yu Tsai, dri-devel-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-sunxi-/JYPxA39Uh5TLH3MbocFFw
In-Reply-To: <20170421083857.29636-1-wens-jdAy2FN1RRM@public.gmane.org>
Save a pointer to the backend's underlying device tree node in its
data structure. This will be used later for downstream tcons to find
and match their respective upstream backends.
Signed-off-by: Chen-Yu Tsai <wens-jdAy2FN1RRM@public.gmane.org>
---
drivers/gpu/drm/sun4i/sun4i_backend.c | 1 +
drivers/gpu/drm/sun4i/sun4i_backend.h | 2 ++
2 files changed, 3 insertions(+)
diff --git a/drivers/gpu/drm/sun4i/sun4i_backend.c b/drivers/gpu/drm/sun4i/sun4i_backend.c
index 0b4222312e49..e9eca057ff35 100644
--- a/drivers/gpu/drm/sun4i/sun4i_backend.c
+++ b/drivers/gpu/drm/sun4i/sun4i_backend.c
@@ -352,6 +352,7 @@ static int sun4i_backend_bind(struct device *dev, struct device *master,
return -ENOMEM;
dev_set_drvdata(dev, backend);
+ backend->node = dev->of_node;
backend->id = sun4i_backend_of_get_id(dev->of_node);
if (backend->id < 0)
return backend->id;
diff --git a/drivers/gpu/drm/sun4i/sun4i_backend.h b/drivers/gpu/drm/sun4i/sun4i_backend.h
index 45b7fc110590..6327a2985fe6 100644
--- a/drivers/gpu/drm/sun4i/sun4i_backend.h
+++ b/drivers/gpu/drm/sun4i/sun4i_backend.h
@@ -15,6 +15,7 @@
#include <linux/clk.h>
#include <linux/list.h>
+#include <linux/of.h>
#include <linux/regmap.h>
#include <linux/reset.h>
@@ -140,6 +141,7 @@
#define SUN4I_BACKEND_PIPE_OFF(p) (0x5000 + (0x400 * (p)))
struct sun4i_backend {
+ struct device_node *node;
struct regmap *regs;
struct reset_control *reset;
--
2.11.0
^ permalink raw reply related
* [PATCH v2 6/9] drm/sun4i: tcon: Find matching display backend by device node matching
From: Chen-Yu Tsai @ 2017-04-21 8:38 UTC (permalink / raw)
To: Maxime Ripard, David Airlie, Rob Herring, Mark Rutland
Cc: Chen-Yu Tsai, dri-devel-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-sunxi-/JYPxA39Uh5TLH3MbocFFw
In-Reply-To: <20170421083857.29636-1-wens-jdAy2FN1RRM@public.gmane.org>
With Allwinner's Display Engine 1.0, each TCON's input is tied to a
specific display backend, and the 2 comprise what is known as a crtc
in DRM KMS land: The layer, framebuffer, and compositing functions are
provided by the backend, while the TCON provides the display timing
signals and vblank interrupts. This 1 to 1 relationship is represented
in the device tree. On some systems there is an intermediate DRC
component.
Pointers to both matching components must be provided when initializing
the crtc. As the backend is always registered before the associated
tcon, we can recursively search upwards through the of_graph to find
the matching backend.
Signed-off-by: Chen-Yu Tsai <wens-jdAy2FN1RRM@public.gmane.org>
---
drivers/gpu/drm/sun4i/sun4i_tcon.c | 55 +++++++++++++++++++++++++++++++++++---
1 file changed, 51 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/sun4i/sun4i_tcon.c b/drivers/gpu/drm/sun4i/sun4i_tcon.c
index 52f37ef9a050..4409e7b6c74d 100644
--- a/drivers/gpu/drm/sun4i/sun4i_tcon.c
+++ b/drivers/gpu/drm/sun4i/sun4i_tcon.c
@@ -472,6 +472,53 @@ struct drm_bridge *sun4i_tcon_find_bridge(struct device_node *node)
return of_drm_find_bridge(remote) ?: ERR_PTR(-EPROBE_DEFER);
}
+/*
+ * On SoCs with the old display pipeline design (Display Engine 1.0),
+ * the TCON is always tied to just one backend. Hence we can traverse
+ * the of_graph upwards to find the backend our tcon is connected to,
+ * and take its ID as our own.
+ *
+ * We can either identify backends from their compatible strings, which
+ * means maintaining a large list of them. Or, since the backend is
+ * registered and binded before the TCON, we can just go through the
+ * list of registered backends and compare the device node.
+ */
+static struct sun4i_backend *sun4i_tcon_find_backend(struct sun4i_drv *drv,
+ struct device_node *node)
+{
+ struct device_node *port, *ep, *remote;
+ struct sun4i_backend *backend;
+
+ port = of_graph_get_port_by_id(node, 0);
+ if (!port)
+ return ERR_PTR(-EINVAL);
+
+ for_each_available_child_of_node(port, ep) {
+ remote = of_graph_get_remote_port_parent(ep);
+ if (!remote)
+ continue;
+
+ /* does this node match any registered backends? */
+ list_for_each_entry(backend, &drv->backend_list, list) {
+ if (remote == backend->node) {
+ of_node_put(remote);
+ of_node_put(port);
+ return backend;
+ }
+ }
+
+ /* keep looking through upstream ports */
+ backend = sun4i_tcon_find_backend(drv, remote);
+ if (!IS_ERR(backend)) {
+ of_node_put(remote);
+ of_node_put(port);
+ return backend;
+ }
+ }
+
+ return ERR_PTR(-EINVAL);
+}
+
static int sun4i_tcon_bind(struct device *dev, struct device *master,
void *data)
{
@@ -481,9 +528,11 @@ static int sun4i_tcon_bind(struct device *dev, struct device *master,
struct sun4i_tcon *tcon;
int ret;
- /* Wait for a backend to be registered */
- if (list_empty(&drv->backend_list))
+ backend = sun4i_tcon_find_backend(drv, dev->of_node);
+ if (IS_ERR(backend)) {
+ dev_err(dev, "Couldn't find matching backend\n");
return -EPROBE_DEFER;
+ }
tcon = devm_kzalloc(dev, sizeof(*tcon), GFP_KERNEL);
if (!tcon)
@@ -533,8 +582,6 @@ static int sun4i_tcon_bind(struct device *dev, struct device *master,
goto err_free_dotclock;
}
- backend = list_first_entry(&drv->backend_list,
- struct sun4i_backend, list);
tcon->crtc = sun4i_crtc_init(drm, backend, tcon);
if (IS_ERR(tcon->crtc)) {
dev_err(dev, "Couldn't create our CRTC\n");
--
2.11.0
^ permalink raw reply related
* [PATCH v2 7/9] drm/sun4i: tcon: Copy ID from associated backend
From: Chen-Yu Tsai @ 2017-04-21 8:38 UTC (permalink / raw)
To: Maxime Ripard, David Airlie, Rob Herring, Mark Rutland
Cc: Chen-Yu Tsai, dri-devel-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-sunxi-/JYPxA39Uh5TLH3MbocFFw
In-Reply-To: <20170421083857.29636-1-wens-jdAy2FN1RRM@public.gmane.org>
The tcons and backends have a one-to-one relationship. Their IDs,
or indexes in the documentation, are also the same.
Copy the ID from the associated backend and save it in the tcon
structure. This will later be used when we add support for the
output data path muxes.
Signed-off-by: Chen-Yu Tsai <wens-jdAy2FN1RRM@public.gmane.org>
---
drivers/gpu/drm/sun4i/sun4i_tcon.c | 1 +
drivers/gpu/drm/sun4i/sun4i_tcon.h | 2 ++
2 files changed, 3 insertions(+)
diff --git a/drivers/gpu/drm/sun4i/sun4i_tcon.c b/drivers/gpu/drm/sun4i/sun4i_tcon.c
index 4409e7b6c74d..8301389c411d 100644
--- a/drivers/gpu/drm/sun4i/sun4i_tcon.c
+++ b/drivers/gpu/drm/sun4i/sun4i_tcon.c
@@ -540,6 +540,7 @@ static int sun4i_tcon_bind(struct device *dev, struct device *master,
dev_set_drvdata(dev, tcon);
tcon->drm = drm;
tcon->dev = dev;
+ tcon->id = backend->id;
tcon->quirks = of_device_get_match_data(dev);
tcon->lcd_rst = devm_reset_control_get(dev, "lcd");
diff --git a/drivers/gpu/drm/sun4i/sun4i_tcon.h b/drivers/gpu/drm/sun4i/sun4i_tcon.h
index 1bda4d183eec..d37e1e2ed60e 100644
--- a/drivers/gpu/drm/sun4i/sun4i_tcon.h
+++ b/drivers/gpu/drm/sun4i/sun4i_tcon.h
@@ -174,6 +174,8 @@ struct sun4i_tcon {
/* Associated crtc */
struct sun4i_crtc *crtc;
+ int id;
+
/* TCON list management */
struct list_head list;
};
--
2.11.0
^ permalink raw reply related
* [PATCH v2 8/9] ARM: dts: sun6i: Add second display pipeline device nodes
From: Chen-Yu Tsai @ 2017-04-21 8:38 UTC (permalink / raw)
To: Maxime Ripard, David Airlie, Rob Herring, Mark Rutland
Cc: Chen-Yu Tsai, dri-devel-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-sunxi-/JYPxA39Uh5TLH3MbocFFw
In-Reply-To: <20170421083857.29636-1-wens-jdAy2FN1RRM@public.gmane.org>
The Allwinner A31/A31s SoCs have 2 display pipelines, as in 2 display
frontends, backends, and tcons each. The relationship between the
backends and tcons are 1:1, but the frontends can feed either backend.
Add device nodes and of graph nodes describing this relationship.
Signed-off-by: Chen-Yu Tsai <wens-jdAy2FN1RRM@public.gmane.org>
---
arch/arm/boot/dts/sun6i-a31.dtsi | 168 ++++++++++++++++++++++++++++++++++++++-
1 file changed, 167 insertions(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/sun6i-a31.dtsi b/arch/arm/boot/dts/sun6i-a31.dtsi
index 9c999d3788f6..dfcf64515d7f 100644
--- a/arch/arm/boot/dts/sun6i-a31.dtsi
+++ b/arch/arm/boot/dts/sun6i-a31.dtsi
@@ -232,7 +232,7 @@
de: display-engine {
compatible = "allwinner,sun6i-a31-display-engine";
- allwinner,pipelines = <&fe0>;
+ allwinner,pipelines = <&fe0>, <&fe1>;
status = "disabled";
};
@@ -289,6 +289,43 @@
};
};
+ tcon1: lcd-controller@01c0d000 {
+ compatible = "allwinner,sun6i-a31-tcon";
+ reg = <0x01c0d000 0x1000>;
+ interrupts = <GIC_SPI 87 IRQ_TYPE_LEVEL_HIGH>;
+ resets = <&ccu RST_AHB1_LCD1>;
+ reset-names = "lcd";
+ clocks = <&ccu CLK_AHB1_LCD1>,
+ <&ccu CLK_LCD1_CH0>,
+ <&ccu CLK_LCD1_CH1>;
+ clock-names = "ahb",
+ "tcon-ch0",
+ "tcon-ch1";
+ clock-output-names = "tcon1-pixel-clock";
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ tcon1_in: port@0 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <0>;
+
+ tcon1_in_drc1: endpoint@0 {
+ reg = <0>;
+ remote-endpoint = <&drc1_out_tcon1>;
+ };
+ };
+
+ tcon1_out: port@1 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <1>;
+ };
+ };
+ };
+
mmc0: mmc@01c0f000 {
compatible = "allwinner,sun7i-a20-mmc";
reg = <0x01c0f000 0x1000>;
@@ -896,6 +933,130 @@
reg = <0>;
remote-endpoint = <&be0_in_fe0>;
};
+
+ fe0_out_be1: endpoint@1 {
+ reg = <1>;
+ remote-endpoint = <&be1_in_fe0>;
+ };
+ };
+ };
+ };
+
+ fe1: display-frontend@01e20000 {
+ compatible = "allwinner,sun6i-a31-display-frontend";
+ reg = <0x01e20000 0x20000>;
+ interrupts = <GIC_SPI 94 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&ccu CLK_AHB1_FE1>, <&ccu CLK_FE1>,
+ <&ccu CLK_DRAM_FE1>;
+ clock-names = "ahb", "mod",
+ "ram";
+ resets = <&ccu RST_AHB1_FE1>;
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ fe1_out: port@1 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <1>;
+
+ fe1_out_be0: endpoint@0 {
+ reg = <0>;
+ remote-endpoint = <&be0_in_fe1>;
+ };
+
+ fe1_out_be1: endpoint@1 {
+ reg = <1>;
+ remote-endpoint = <&be1_in_fe1>;
+ };
+ };
+ };
+ };
+
+ be1: display-backend@01e40000 {
+ compatible = "allwinner,sun6i-a31-display-backend";
+ reg = <0x01e40000 0x10000>;
+ interrupts = <GIC_SPI 96 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&ccu CLK_AHB1_BE1>, <&ccu CLK_BE1>,
+ <&ccu CLK_DRAM_BE1>;
+ clock-names = "ahb", "mod",
+ "ram";
+ resets = <&ccu RST_AHB1_BE1>;
+
+ assigned-clocks = <&ccu CLK_BE1>;
+ assigned-clock-rates = <300000000>;
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ be1_in: port@0 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <0>;
+
+ be1_in_fe0: endpoint@0 {
+ reg = <0>;
+ remote-endpoint = <&fe0_out_be1>;
+ };
+
+ be1_in_fe1: endpoint@1 {
+ reg = <1>;
+ remote-endpoint = <&fe1_out_be1>;
+ };
+ };
+
+ be1_out: port@1 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <1>;
+
+ be1_out_drc1: endpoint@0 {
+ reg = <0>;
+ remote-endpoint = <&drc1_in_be1>;
+ };
+ };
+ };
+ };
+
+ drc1: drc@01e50000 {
+ compatible = "allwinner,sun6i-a31-drc";
+ reg = <0x01e50000 0x10000>;
+ interrupts = <GIC_SPI 91 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&ccu CLK_AHB1_DRC1>, <&ccu CLK_IEP_DRC1>,
+ <&ccu CLK_DRAM_DRC1>;
+ clock-names = "ahb", "mod",
+ "ram";
+ resets = <&ccu RST_AHB1_DRC1>;
+
+ assigned-clocks = <&ccu CLK_IEP_DRC1>;
+ assigned-clock-rates = <300000000>;
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ drc1_in: port@0 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <0>;
+
+ drc1_in_be1: endpoint@0 {
+ reg = <0>;
+ remote-endpoint = <&be1_out_drc1>;
+ };
+ };
+
+ drc1_out: port@1 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <1>;
+
+ drc1_out_tcon1: endpoint@0 {
+ reg = <0>;
+ remote-endpoint = <&tcon1_in_drc1>;
+ };
};
};
};
@@ -926,6 +1087,11 @@
reg = <0>;
remote-endpoint = <&fe0_out_be0>;
};
+
+ be0_in_fe1: endpoint@1 {
+ reg = <1>;
+ remote-endpoint = <&fe1_out_be0>;
+ };
};
be0_out: port@1 {
--
2.11.0
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox