* [PATCH V6 2/6] dt-bindings: qcom: clocks: Add msm8994 clock bindings
From: Jeremy McNicoll @ 2016-11-04 20:56 UTC (permalink / raw)
To: linux-arm-msm-u79uwXL29TY76Z2rM5mHXA,
linux-soc-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA
Cc: robh-DgEjT+Ai2ygdnm+yROfE0A, andy.gross-QSEj5FYQhm4dnm+yROfE0A,
sboyd-sgV2jX0FEOL9JmXXK+q4OQ, mail-LJ92rlH3Dns, arnd-r2nGTMty4D4,
bjorn.andersson-QSEj5FYQhm4dnm+yROfE0A, mark.rutland-5wv7dgnIgG8,
michael.scott-QSEj5FYQhm4dnm+yROfE0A,
jeremymc-H+wXaHxf7aLQT0dZR+AlfA
In-Reply-To: <1478292996-29559-1-git-send-email-jeremymc-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
Signed-off-by: Jeremy McNicoll <jeremymc-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
---
.../devicetree/bindings/clock/qcom,gcc.txt | 1 +
include/dt-bindings/clock/qcom,gcc-msm8994.h | 145 +++++++++++++++++++++
2 files changed, 146 insertions(+)
create mode 100644 include/dt-bindings/clock/qcom,gcc-msm8994.h
diff --git a/Documentation/devicetree/bindings/clock/qcom,gcc.txt b/Documentation/devicetree/bindings/clock/qcom,gcc.txt
index 3cf4421..5b4dfc1 100644
--- a/Documentation/devicetree/bindings/clock/qcom,gcc.txt
+++ b/Documentation/devicetree/bindings/clock/qcom,gcc.txt
@@ -14,6 +14,7 @@ Required properties :
"qcom,gcc-msm8974"
"qcom,gcc-msm8974pro"
"qcom,gcc-msm8974pro-ac"
+ "qcom,gcc-msm8994"
"qcom,gcc-msm8996"
"qcom,gcc-mdm9615"
diff --git a/include/dt-bindings/clock/qcom,gcc-msm8994.h b/include/dt-bindings/clock/qcom,gcc-msm8994.h
new file mode 100644
index 0000000..0ae494b
--- /dev/null
+++ b/include/dt-bindings/clock/qcom,gcc-msm8994.h
@@ -0,0 +1,145 @@
+/*
+ * Copyright (c) 2016, The Linux Foundation. All rights reserved.
+ *
+ * This software is licensed under the terms of the GNU General Public
+ * License version 2, as published by the Free Software Foundation, and
+ * may be copied, distributed, and modified under those terms.
+ *
+ * This program 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.
+ */
+
+
+#ifndef _DT_BINDINGS_CLK_MSM_GCC_8994_H
+#define _DT_BINDINGS_CLK_MSM_GCC_8994_H
+
+#define GPLL0_EARLY 0
+#define GPLL0 1
+#define GPLL4_EARLY 2
+#define GPLL4 3
+#define UFS_AXI_CLK_SRC 4
+#define USB30_MASTER_CLK_SRC 5
+#define BLSP1_QUP1_I2C_APPS_CLK_SRC 6
+#define BLSP1_QUP1_SPI_APPS_CLK_SRC 7
+#define BLSP1_QUP2_I2C_APPS_CLK_SRC 8
+#define BLSP1_QUP2_SPI_APPS_CLK_SRC 9
+#define BLSP1_QUP3_I2C_APPS_CLK_SRC 10
+#define BLSP1_QUP3_SPI_APPS_CLK_SRC 11
+#define BLSP1_QUP4_I2C_APPS_CLK_SRC 12
+#define BLSP1_QUP4_SPI_APPS_CLK_SRC 13
+#define BLSP1_QUP5_I2C_APPS_CLK_SRC 14
+#define BLSP1_QUP5_SPI_APPS_CLK_SRC 15
+#define BLSP1_QUP6_I2C_APPS_CLK_SRC 16
+#define BLSP1_QUP6_SPI_APPS_CLK_SRC 17
+#define BLSP1_UART1_APPS_CLK_SRC 18
+#define BLSP1_UART2_APPS_CLK_SRC 19
+#define BLSP1_UART3_APPS_CLK_SRC 20
+#define BLSP1_UART4_APPS_CLK_SRC 21
+#define BLSP1_UART5_APPS_CLK_SRC 22
+#define BLSP1_UART6_APPS_CLK_SRC 23
+#define BLSP2_QUP1_I2C_APPS_CLK_SRC 24
+#define BLSP2_QUP1_SPI_APPS_CLK_SRC 25
+#define BLSP2_QUP2_I2C_APPS_CLK_SRC 26
+#define BLSP2_QUP2_SPI_APPS_CLK_SRC 27
+#define BLSP2_QUP3_I2C_APPS_CLK_SRC 28
+#define BLSP2_QUP3_SPI_APPS_CLK_SRC 29
+#define BLSP2_QUP4_I2C_APPS_CLK_SRC 30
+#define BLSP2_QUP4_SPI_APPS_CLK_SRC 31
+#define BLSP2_QUP5_I2C_APPS_CLK_SRC 32
+#define BLSP2_QUP5_SPI_APPS_CLK_SRC 33
+#define BLSP2_QUP6_I2C_APPS_CLK_SRC 34
+#define BLSP2_QUP6_SPI_APPS_CLK_SRC 35
+#define BLSP2_UART1_APPS_CLK_SRC 36
+#define BLSP2_UART2_APPS_CLK_SRC 37
+#define BLSP2_UART3_APPS_CLK_SRC 38
+#define BLSP2_UART4_APPS_CLK_SRC 39
+#define BLSP2_UART5_APPS_CLK_SRC 40
+#define BLSP2_UART6_APPS_CLK_SRC 41
+#define GP1_CLK_SRC 42
+#define GP2_CLK_SRC 43
+#define GP3_CLK_SRC 44
+#define PCIE_0_AUX_CLK_SRC 45
+#define PCIE_0_PIPE_CLK_SRC 46
+#define PCIE_1_AUX_CLK_SRC 47
+#define PCIE_1_PIPE_CLK_SRC 48
+#define PDM2_CLK_SRC 49
+#define SDCC1_APPS_CLK_SRC 50
+#define SDCC2_APPS_CLK_SRC 51
+#define SDCC3_APPS_CLK_SRC 52
+#define SDCC4_APPS_CLK_SRC 53
+#define TSIF_REF_CLK_SRC 54
+#define USB30_MOCK_UTMI_CLK_SRC 55
+#define USB3_PHY_AUX_CLK_SRC 56
+#define USB_HS_SYSTEM_CLK_SRC 57
+#define GCC_BLSP1_AHB_CLK 58
+#define GCC_BLSP1_QUP1_I2C_APPS_CLK 59
+#define GCC_BLSP1_QUP1_SPI_APPS_CLK 60
+#define GCC_BLSP1_QUP2_I2C_APPS_CLK 61
+#define GCC_BLSP1_QUP2_SPI_APPS_CLK 62
+#define GCC_BLSP1_QUP3_I2C_APPS_CLK 63
+#define GCC_BLSP1_QUP3_SPI_APPS_CLK 64
+#define GCC_BLSP1_QUP4_I2C_APPS_CLK 65
+#define GCC_BLSP1_QUP4_SPI_APPS_CLK 66
+#define GCC_BLSP1_QUP5_I2C_APPS_CLK 67
+#define GCC_BLSP1_QUP5_SPI_APPS_CLK 68
+#define GCC_BLSP1_QUP6_I2C_APPS_CLK 69
+#define GCC_BLSP1_QUP6_SPI_APPS_CLK 70
+#define GCC_BLSP1_UART1_APPS_CLK 71
+#define GCC_BLSP1_UART2_APPS_CLK 72
+#define GCC_BLSP1_UART3_APPS_CLK 73
+#define GCC_BLSP1_UART4_APPS_CLK 74
+#define GCC_BLSP1_UART5_APPS_CLK 75
+#define GCC_BLSP1_UART6_APPS_CLK 76
+#define GCC_BLSP2_AHB_CLK 77
+#define GCC_BLSP2_QUP1_I2C_APPS_CLK 78
+#define GCC_BLSP2_QUP1_SPI_APPS_CLK 79
+#define GCC_BLSP2_QUP2_I2C_APPS_CLK 80
+#define GCC_BLSP2_QUP2_SPI_APPS_CLK 81
+#define GCC_BLSP2_QUP3_I2C_APPS_CLK 82
+#define GCC_BLSP2_QUP3_SPI_APPS_CLK 83
+#define GCC_BLSP2_QUP4_I2C_APPS_CLK 84
+#define GCC_BLSP2_QUP4_SPI_APPS_CLK 85
+#define GCC_BLSP2_QUP5_I2C_APPS_CLK 86
+#define GCC_BLSP2_QUP5_SPI_APPS_CLK 87
+#define GCC_BLSP2_QUP6_I2C_APPS_CLK 88
+#define GCC_BLSP2_QUP6_SPI_APPS_CLK 89
+#define GCC_BLSP2_UART1_APPS_CLK 90
+#define GCC_BLSP2_UART2_APPS_CLK 91
+#define GCC_BLSP2_UART3_APPS_CLK 92
+#define GCC_BLSP2_UART4_APPS_CLK 93
+#define GCC_BLSP2_UART5_APPS_CLK 94
+#define GCC_BLSP2_UART6_APPS_CLK 95
+#define GCC_GP1_CLK 96
+#define GCC_GP2_CLK 97
+#define GCC_GP3_CLK 98
+#define GCC_PCIE_0_AUX_CLK 99
+#define GCC_PCIE_0_PIPE_CLK 100
+#define GCC_PCIE_1_AUX_CLK 101
+#define GCC_PCIE_1_PIPE_CLK 102
+#define GCC_PDM2_CLK 103
+#define GCC_SDCC1_APPS_CLK 104
+#define GCC_SDCC2_APPS_CLK 105
+#define GCC_SDCC3_APPS_CLK 106
+#define GCC_SDCC4_APPS_CLK 107
+#define GCC_SYS_NOC_UFS_AXI_CLK 108
+#define GCC_SYS_NOC_USB3_AXI_CLK 109
+#define GCC_TSIF_REF_CLK 110
+#define GCC_UFS_AXI_CLK 111
+#define GCC_UFS_RX_CFG_CLK 112
+#define GCC_UFS_TX_CFG_CLK 113
+#define GCC_USB30_MASTER_CLK 114
+#define GCC_USB30_MOCK_UTMI_CLK 115
+#define GCC_USB3_PHY_AUX_CLK 116
+#define GCC_USB_HS_SYSTEM_CLK 117
+
+/* Indexes for GDSCs */
+#define BIMC_GDSC 0
+#define VENUS_GDSC 1
+#define MDSS_GDSC 2
+#define JPEG_GDSC 3
+#define VFE_GDSC 4
+#define OXILI_GDSC 5
+
+#endif
--
2.9.2
--
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 V6 1/6] arm64: dts: msm8992 SoC and LG Bullhead (Nexus 5X) support
From: Jeremy McNicoll @ 2016-11-04 20:56 UTC (permalink / raw)
To: linux-arm-msm, linux-soc, devicetree
Cc: robh, andy.gross, sboyd, mail, arnd, bjorn.andersson,
mark.rutland, michael.scott, jeremymc
In-Reply-To: <1478292996-29559-1-git-send-email-jeremymc@redhat.com>
From: Jeremy McNicoll <jmcnicol@redhat.com>
Initial device tree support for Qualcomm MSM8992 SoC and
LG Bullhead / Google Nexus 5X support.
Signed-off-by: Jeremy McNicoll <jeremymc@redhat.com>
---
arch/arm64/boot/dts/qcom/Makefile | 6 +-
.../boot/dts/qcom/msm8992-bullhead-rev-101.dts | 41 +++++
arch/arm64/boot/dts/qcom/msm8992-pins.dtsi | 38 +++++
arch/arm64/boot/dts/qcom/msm8992.dtsi | 184 +++++++++++++++++++++
4 files changed, 267 insertions(+), 2 deletions(-)
create mode 100644 arch/arm64/boot/dts/qcom/msm8992-bullhead-rev-101.dts
create mode 100644 arch/arm64/boot/dts/qcom/msm8992-pins.dtsi
create mode 100644 arch/arm64/boot/dts/qcom/msm8992.dtsi
diff --git a/arch/arm64/boot/dts/qcom/Makefile b/arch/arm64/boot/dts/qcom/Makefile
index 5dd05de..439e40e 100644
--- a/arch/arm64/boot/dts/qcom/Makefile
+++ b/arch/arm64/boot/dts/qcom/Makefile
@@ -1,6 +1,8 @@
-dtb-$(CONFIG_ARCH_QCOM) += apq8016-sbc.dtb msm8916-mtp.dtb
-dtb-$(CONFIG_ARCH_QCOM) += msm8996-mtp.dtb
+dtb-$(CONFIG_ARCH_QCOM) += apq8016-sbc.dtb
dtb-$(CONFIG_ARCH_QCOM) += apq8096-db820c.dtb
+dtb-$(CONFIG_ARCH_QCOM) += msm8916-mtp.dtb
+dtb-$(CONFIG_ARCH_QCOM) += msm8992-bullhead-rev-101.dtb
+dtb-$(CONFIG_ARCH_QCOM) += msm8996-mtp.dtb
always := $(dtb-y)
subdir-y := $(dts-dirs)
diff --git a/arch/arm64/boot/dts/qcom/msm8992-bullhead-rev-101.dts b/arch/arm64/boot/dts/qcom/msm8992-bullhead-rev-101.dts
new file mode 100644
index 0000000..4542133
--- /dev/null
+++ b/arch/arm64/boot/dts/qcom/msm8992-bullhead-rev-101.dts
@@ -0,0 +1,41 @@
+/* Copyright (c) 2015, LGE Inc. All rights reserved.
+ * Copyright (c) 2016, The Linux Foundation. All rights reserved.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 and
+ * only version 2 as published by the Free Software Foundation.
+ *
+ * This program 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.
+ */
+
+/dts-v1/;
+
+#include "msm8992.dtsi"
+
+/ {
+ model = "LG Nexus 5X";
+ compatible = "lg,bullhead", "qcom,msm8992";
+ /* required for bootloader to select correct board */
+ qcom,board-id = <0xb64 0>;
+ qcom,pmic-id = <0x10009 0x1000A 0x0 0x0>;
+
+ aliases {
+ serial0 = &blsp1_uart2;
+ };
+
+ chosen {
+ stdout-path = "serial0:115200n8";
+ };
+
+ soc {
+ serial@f991e000 {
+ status = "okay";
+ pinctrl-names = "default", "sleep";
+ pinctrl-0 = <&blsp1_uart2_default>;
+ pinctrl-1 = <&blsp1_uart2_sleep>;
+ };
+ };
+};
diff --git a/arch/arm64/boot/dts/qcom/msm8992-pins.dtsi b/arch/arm64/boot/dts/qcom/msm8992-pins.dtsi
new file mode 100644
index 0000000..d2a26f0
--- /dev/null
+++ b/arch/arm64/boot/dts/qcom/msm8992-pins.dtsi
@@ -0,0 +1,38 @@
+/*
+ * Copyright (c) 2013-2015, The Linux Foundation. All rights reserved.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 and
+ * only version 2 as published by the Free Software Foundation.
+ *
+ * This program 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.
+ */
+
+&msmgpio {
+ blsp1_uart2_default: blsp1_uart2_default {
+ pinmux {
+ function = "blsp_uart2";
+ pins = "gpio4", "gpio5";
+ };
+ pinconf {
+ pins = "gpio4", "gpio5";
+ drive-strength = <16>;
+ bias-disable;
+ };
+ };
+
+ blsp1_uart2_sleep: blsp1_uart2_sleep {
+ pinmux {
+ function = "gpio";
+ pins = "gpio4", "gpio5";
+ };
+ pinconf {
+ pins = "gpio4", "gpio5";
+ drive-strength = <2>;
+ bias-pull-down;
+ };
+ };
+};
diff --git a/arch/arm64/boot/dts/qcom/msm8992.dtsi b/arch/arm64/boot/dts/qcom/msm8992.dtsi
new file mode 100644
index 0000000..44b2d37
--- /dev/null
+++ b/arch/arm64/boot/dts/qcom/msm8992.dtsi
@@ -0,0 +1,184 @@
+/* Copyright (c) 2013-2016, The Linux Foundation. All rights reserved.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 and
+ * only version 2 as published by the Free Software Foundation.
+ *
+ * This program 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.
+ */
+
+#include <dt-bindings/interrupt-controller/arm-gic.h>
+#include <dt-bindings/clock/qcom,gcc-msm8994.h>
+
+/ {
+ model = "Qualcomm Technologies, Inc. MSM 8992";
+ compatible = "qcom,msm8992";
+ // msm-id needed by bootloader for selecting correct blob
+ qcom,msm-id = <251 0>, <252 0>;
+ interrupt-parent = <&intc>;
+
+ #address-cells = <2>;
+ #size-cells = <2>;
+
+ chosen { };
+
+ cpus {
+ #address-cells = <2>;
+ #size-cells = <0>;
+ cpu-map {
+ cluster0 {
+ core0 {
+ cpu = <&CPU0>;
+ };
+ };
+ };
+
+ CPU0: cpu@0 {
+ device_type = "cpu";
+ compatible = "arm,cortex-a53", "arm,armv8";
+ reg = <0x0 0x0>;
+ next-level-cache = <&L2_0>;
+ L2_0: l2-cache {
+ compatible = "cache";
+ cache-level = <2>;
+ };
+ };
+ };
+
+ timer {
+ compatible = "arm,armv8-timer";
+ interrupts = <GIC_PPI 2 (GIC_CPU_MASK_SIMPLE(4) | IRQ_TYPE_LEVEL_LOW)>,
+ <GIC_PPI 3 (GIC_CPU_MASK_SIMPLE(4) | IRQ_TYPE_LEVEL_LOW)>,
+ <GIC_PPI 4 (GIC_CPU_MASK_SIMPLE(4) | IRQ_TYPE_LEVEL_LOW)>,
+ <GIC_PPI 1 (GIC_CPU_MASK_SIMPLE(4) | IRQ_TYPE_LEVEL_LOW)>;
+ };
+
+ xo_board: xo_board {
+ compatible = "fixed-clock";
+ #clock-cells = <0>;
+ clock-frequency = <19200000>;
+ };
+
+ sleep_clk: sleep_clk {
+ compatible = "fixed-clock";
+ #clock-cells = <0>;
+ clock-frequency = <32768>;
+ };
+
+ soc {
+ #address-cells = <1>;
+ #size-cells = <1>;
+ ranges = <0 0 0 0xffffffff>;
+ compatible = "simple-bus";
+
+ intc: interrupt-controller@f9000000 {
+ compatible = "qcom,msm-qgic2";
+ interrupt-controller;
+ #interrupt-cells = <3>;
+ reg = <0xf9000000 0x1000>,
+ <0xf9002000 0x1000>;
+ };
+
+ timer@f9020000 {
+ #address-cells = <1>;
+ #size-cells = <1>;
+ ranges;
+ compatible = "arm,armv7-timer-mem";
+ reg = <0xf9020000 0x1000>;
+
+ frame@f9021000 {
+ frame-number = <0>;
+ interrupts = <GIC_SPI 9 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 8 IRQ_TYPE_LEVEL_HIGH>;
+ reg = <0xf9021000 0x1000>,
+ <0xf9022000 0x1000>;
+ };
+
+ frame@f9023000 {
+ frame-number = <1>;
+ interrupts = <GIC_SPI 10 IRQ_TYPE_LEVEL_HIGH>;
+ reg = <0xf9023000 0x1000>;
+ status = "disabled";
+ };
+
+ frame@f9024000 {
+ frame-number = <2>;
+ interrupts = <GIC_SPI 11 IRQ_TYPE_LEVEL_HIGH>;
+ reg = <0xf9024000 0x1000>;
+ status = "disabled";
+ };
+
+ frame@f9025000 {
+ frame-number = <3>;
+ interrupts = <GIC_SPI 12 IRQ_TYPE_LEVEL_HIGH>;
+ reg = <0xf9025000 0x1000>;
+ status = "disabled";
+ };
+
+ frame@f9026000 {
+ frame-number = <4>;
+ interrupts = <GIC_SPI 13 IRQ_TYPE_LEVEL_HIGH>;
+ reg = <0xf9026000 0x1000>;
+ status = "disabled";
+ };
+
+ frame@f9027000 {
+ frame-number = <5>;
+ interrupts = <GIC_SPI 14 IRQ_TYPE_LEVEL_HIGH>;
+ reg = <0xf9027000 0x1000>;
+ status = "disabled";
+ };
+
+ frame@f9028000 {
+ frame-number = <6>;
+ interrupts = <GIC_SPI 15 IRQ_TYPE_LEVEL_HIGH>;
+ reg = <0xf9028000 0x1000>;
+ status = "disabled";
+ };
+ };
+
+ restart@fc4ab000 {
+ compatible = "qcom,pshold";
+ reg = <0xfc4ab000 0x4>;
+ };
+
+ msmgpio: pinctrl@fd510000 {
+ compatible = "qcom,msm8994-pinctrl";
+ reg = <0xfd510000 0x4000>;
+ interrupts = <GIC_SPI 208 IRQ_TYPE_LEVEL_HIGH>;
+ gpio-controller;
+ #gpio-cells = <2>;
+ interrupt-controller;
+ #interrupt-cells = <2>;
+ };
+
+ blsp1_uart2: serial@f991e000 {
+ compatible = "qcom,msm-uartdm-v1.4", "qcom,msm-uartdm";
+ reg = <0xf991e000 0x1000>;
+ interrupts = <GIC_SPI 108 IRQ_TYPE_LEVEL_LOW>;
+ status = "disabled";
+ clock-names = "core", "iface";
+ clocks = <&clock_gcc GCC_BLSP1_UART2_APPS_CLK>,
+ <&clock_gcc GCC_BLSP1_AHB_CLK>;
+ };
+
+ clock_gcc: clock-controller@fc400000 {
+ compatible = "qcom,gcc-msm8994";
+ #clock-cells = <1>;
+ #reset-cells = <1>;
+ #power-domain-cells = <1>;
+ reg = <0xfc400000 0x2000>;
+ };
+ };
+
+ memory {
+ device_type = "memory";
+ reg = <0 0 0 0>; // bootloader will update
+ };
+};
+
+
+#include "msm8992-pins.dtsi"
--
2.9.2
^ permalink raw reply related
* [PATCH V6 0/6] msm8992/msm8994: Google Nexus 5X/6P initial board support
From: Jeremy McNicoll @ 2016-11-04 20:56 UTC (permalink / raw)
To: linux-arm-msm, linux-soc, devicetree
Cc: robh, andy.gross, sboyd, mail, arnd, bjorn.andersson,
mark.rutland, michael.scott, jeremymc
This series provides basic support for the Nexus 5X / 6P with the goal of
getting as much of the phone running a mainline kernel. (wishful thinking...)
Ideally we will be able to leverage most / significant portion of the great
work being done by Linaro mainlining effort. A selection of various
bits 'n pieces will be leveraged and re-used. If nothing else, this provides
yet another platform to break / test / re-verify the MSM code base as it gets
mainlined.
-RFC in the subject was dropped when sending V5 so too was the V5 part as I
wasn't sure if one needs to drop the V[x] part when dropping the RFC part. ;-(
Here is V6 which based on feedback and discussion with folks at LPC it is
now ready to be merged.
V1:
[http://lists.infradead.org/pipermail/linux-arm-kernel/2016-July/442069.html]
V2:
[http://www.spinics.net/lists/linux-soc/msg01059.html]
V3:
[http://www.spinics.net/lists/linux-soc/msg01089.html]
V4:
[http://www.spinics.net/lists/linux-arm-msm/msg23849.html]
V5:
[ http://www.spinics.net/lists/devicetree/msg147476.html ]
V5->V6:
- tested on the Nexus 5X and 6P using V4 of Michael Scotts pin ctrl code.
- using V5 of the 8994 pin ctrl driver from here: https://patchwork.kernel.org/patch/9405773/
- clock controller name and compatible string updates, moved under soc
- removed clock-output-names in DTS’s
- v2 references in GCC deleted as V1 hardware never shipped therefor its
not needed
- model and compatible strings updated for both 5X and 6P
- minor label update / removal for ‘soc’
- removal of the 8994 - v2 DTS file as its the only version that has shipped.
- global clock for 8994 / 8992: format hex to lower case
As explicitly stated in V1 this is just a starting point and the plan is to
continue adding updating support for more peripherals / components. Ideally
this starting point will allow others to help in the forward porting effort.
Again, thank you everyone for your feedback thus far it is greatly appreciated.
Bastian Köcher (2):
msm8994 clocks: global clock support for msm8994 SOC.
arm64: dts: msm8994 SoC and Huawei Angler (Nexus 6P) support
Jeremy McNicoll (4):
arm64: dts: msm8992 SoC and LG Bullhead (Nexus 5X) support
dt-bindings: qcom: clocks: Add msm8994 clock bindings
dt-bindings: qcom: Add msm899(2/4) bindings
arm64: configs: enable configs for msm899(2/4) basic support
Documentation/devicetree/bindings/arm/qcom.txt | 2 +
.../devicetree/bindings/clock/qcom,gcc.txt | 1 +
arch/arm64/boot/dts/qcom/Makefile | 7 +-
.../boot/dts/qcom/msm8992-bullhead-rev-101.dts | 41 +
arch/arm64/boot/dts/qcom/msm8992-pins.dtsi | 38 +
arch/arm64/boot/dts/qcom/msm8992.dtsi | 184 ++
.../arm64/boot/dts/qcom/msm8994-angler-rev-101.dts | 40 +
arch/arm64/boot/dts/qcom/msm8994-pins.dtsi | 38 +
arch/arm64/boot/dts/qcom/msm8994.dtsi | 216 ++
arch/arm64/configs/defconfig | 2 +
drivers/clk/qcom/Kconfig | 7 +
drivers/clk/qcom/Makefile | 1 +
drivers/clk/qcom/gcc-msm8994.c | 2301 ++++++++++++++++++++
include/dt-bindings/clock/qcom,gcc-msm8994.h | 145 ++
14 files changed, 3021 insertions(+), 2 deletions(-)
create mode 100644 arch/arm64/boot/dts/qcom/msm8992-bullhead-rev-101.dts
create mode 100644 arch/arm64/boot/dts/qcom/msm8992-pins.dtsi
create mode 100644 arch/arm64/boot/dts/qcom/msm8992.dtsi
create mode 100644 arch/arm64/boot/dts/qcom/msm8994-angler-rev-101.dts
create mode 100644 arch/arm64/boot/dts/qcom/msm8994-pins.dtsi
create mode 100644 arch/arm64/boot/dts/qcom/msm8994.dtsi
create mode 100644 drivers/clk/qcom/gcc-msm8994.c
create mode 100644 include/dt-bindings/clock/qcom,gcc-msm8994.h
--
2.9.2
^ permalink raw reply
* Re: [PATCH v5 02/23] of: device: Export of_device_{get_modalias, uvent_modalias} to modules
From: Stephen Boyd @ 2016-11-04 20:51 UTC (permalink / raw)
To: Peter Chen, robh
Cc: Chen-Yu Tsai, Felipe Balbi, Arnd Bergmann, Neil Armstrong,
linux-arm-msm, linux-usb, linux-kernel, Bjorn Andersson,
devicetree, Peter Chen, Andy Gross, linux-arm-kernel
In-Reply-To: <20161025011632.GA23876@b29397-desktop>
Quoting Peter Chen (2016-10-24 18:16:32)
> On Mon, Oct 24, 2016 at 12:48:24PM -0700, Stephen Boyd wrote:
> > Quoting Chen-Yu Tsai (2016-10-24 05:19:05)
> > > Hi,
> > >
> > > On Tue, Oct 18, 2016 at 9:56 AM, Stephen Boyd <stephen.boyd@linaro.org> wrote:
> > > > The ULPI bus can be built as a module, and it will soon be
> > > > calling these functions when it supports probing devices from DT.
> > > > Export them so they can be used by the ULPI module.
> > > >
> > > > Acked-by: Rob Herring <robh@kernel.org>
> > > > Cc: <devicetree@vger.kernel.org>
> > > > Signed-off-by: Stephen Boyd <stephen.boyd@linaro.org>
> > > > ---
> > > > drivers/of/device.c | 2 ++
> > > > 1 file changed, 2 insertions(+)
> > > >
> > > > diff --git a/drivers/of/device.c b/drivers/of/device.c
> > > > index 8a22a253a830..6719ab35b62e 100644
> > > > --- a/drivers/of/device.c
> > > > +++ b/drivers/of/device.c
> > > > @@ -225,6 +225,7 @@ ssize_t of_device_get_modalias(struct device *dev, char *str, ssize_t len)
> > > >
> > > > return tsize;
> > > > }
> > > > +EXPORT_SYMBOL_GPL(of_device_get_modalias);
> > > >
> > > > int of_device_request_module(struct device *dev)
> > > > {
> > > > @@ -290,6 +291,7 @@ void of_device_uevent(struct device *dev, struct kobj_uevent_env *env)
> > > > }
> > > > mutex_unlock(&of_mutex);
> > > > }
> > > > +EXPORT_SYMBOL_GPL(of_device_uevent_modalias);
> > >
> > > This is trailing the wrong function.
> > >
> >
> > Good catch. Must have been some bad rebase.
> >
> > Peter, can you fix it while applying or should I resend this patch?
> >
>
> But, this is device tree patch. I can only get chipidea part and other
> USB patches if Greg agrees.
>
Were you expecting Rob to take the drivers/of/* patches? Sorry I thought
Rob acked them so they could go through usb with the other changes.
^ permalink raw reply
* Re: [PATCH] ARM: dts: imx6: Add imx-weim parameters to dtsi's
From: Fabio Estevam @ 2016-11-04 20:48 UTC (permalink / raw)
To: Joshua Clayton
Cc: Shawn Guo, Sascha Hauer, Fabio Estevam, Rob Herring, Mark Rutland,
Russell King,
moderated list:ARM/FREESCALE IMX / MXC ARM ARCHITECTURE,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
open list
In-Reply-To: <1478044305-5666-1-git-send-email-stillcompiling-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
On Tue, Nov 1, 2016 at 9:51 PM, Joshua Clayton <stillcompiling-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
> imx-weim should always set address-cells to 2,
> and size_cells to 1.
> On imx6, fsl,weim-cs-gpr will always be &gpr
>
> Set these common parameters in the dtsi file,
> rather than in a downstream dts.
>
> Signed-off-by: Joshua Clayton <stillcompiling-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Reviewed-by: Fabio Estevam <fabio.estevam-3arQi8VN3Tc@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 v2 2/5] ARM: bus: da8xx-mstpri: new driver
From: Kevin Hilman @ 2016-11-04 20:42 UTC (permalink / raw)
To: Bartosz Golaszewski
Cc: Mark Rutland, linux-devicetree, Tomi Valkeinen, Michael Turquette,
Sekhar Nori, Russell King, linux-drm, LKML, Peter Ujfalusi,
Rob Herring, Jyri Sarha, Frank Rowand, arm-soc, Laurent Pinchart
In-Reply-To: <1477925138-23457-3-git-send-email-bgolaszewski@baylibre.com>
Bartosz Golaszewski <bgolaszewski@baylibre.com> writes:
> Create the driver for the da8xx master peripheral priority
> configuration and implement support for writing to the three
> Master Priority registers on da850 SoCs.
>
> Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>
Reviewed-by: Kevin Hilman <khilman@baylibre.com>
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply
* Re: [PATCH v2 1/5] ARM: memory: da8xx-ddrctl: new driver
From: Kevin Hilman @ 2016-11-04 20:41 UTC (permalink / raw)
To: Bartosz Golaszewski
Cc: Mark Rutland, linux-devicetree, Tomi Valkeinen, Michael Turquette,
Sekhar Nori, Russell King, linux-drm, LKML, Peter Ujfalusi,
Rob Herring, Jyri Sarha, Frank Rowand, arm-soc, Laurent Pinchart
In-Reply-To: <1477925138-23457-2-git-send-email-bgolaszewski@baylibre.com>
Bartosz Golaszewski <bgolaszewski@baylibre.com> writes:
> Create a new driver for the da8xx DDR2/mDDR controller and implement
> support for writing to the Peripheral Bus Burst Priority Register.
>
> Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>
Reviewed-by: Kevin Hilman <khilman@baylibre.com>
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply
* Applied "ASoC: sun4i-codec: Add support for A31 Line Out playback" to the asoc tree
From: Mark Brown @ 2016-11-04 20:40 UTC (permalink / raw)
To: Chen-Yu Tsai; +Cc: Maxime Ripard, Mark Brown, Liam Girdwood
In-Reply-To: <20161103075556.29018-9-wens@csie.org>
The patch
ASoC: sun4i-codec: Add support for A31 Line Out playback
has been applied to the asoc tree at
git://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git
All being well this means that it will be integrated into the linux-next
tree (usually sometime in the next 24 hours) and sent to Linus during
the next merge window (or sooner if it is a bug fix), however if
problems are discovered then the patch may be dropped or reverted.
You may get further e-mails resulting from automated or manual testing
and review of the tree, please engage with people reporting problems and
send followup patches addressing any issues that are reported if needed.
If any updates are required or you are submitting further changes they
should be sent as incremental updates against current git, existing
patches will not be replaced.
Please add any relevant lists and maintainers to the CCs when replying
to this mail.
Thanks,
Mark
>From 0f909f98d7cbabc3641a45da9c6891444b929a92 Mon Sep 17 00:00:00 2001
From: Chen-Yu Tsai <wens@csie.org>
Date: Thu, 3 Nov 2016 15:55:50 +0800
Subject: [PATCH] ASoC: sun4i-codec: Add support for A31 Line Out playback
The A31 integrated codec has a second "Line Out" output which does not
include an integrated amplifier in its path. This path does have a
separate volume control.
This patch adds support for the playback path from the DAC to the Line
Out pins.
Signed-off-by: Chen-Yu Tsai <wens@csie.org>
Acked-by: Maxime Ripard <maxime.ripard@free-electrons.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
---
sound/soc/sunxi/sun4i-codec.c | 39 +++++++++++++++++++++++++++++++++++++++
1 file changed, 39 insertions(+)
diff --git a/sound/soc/sunxi/sun4i-codec.c b/sound/soc/sunxi/sun4i-codec.c
index 72a84f76aa57..a10251f4932e 100644
--- a/sound/soc/sunxi/sun4i-codec.c
+++ b/sound/soc/sunxi/sun4i-codec.c
@@ -794,11 +794,31 @@ static const struct snd_kcontrol_new sun6i_codec_hp_src[] = {
sun6i_codec_hp_src_enum),
};
+/* line out controls */
+static const char * const sun6i_codec_lineout_src_enum_text[] = {
+ "Stereo", "Mono Differential",
+};
+
+static SOC_ENUM_DOUBLE_DECL(sun6i_codec_lineout_src_enum,
+ SUN6I_CODEC_MIC_CTRL,
+ SUN6I_CODEC_MIC_CTRL_LINEOUTLSRC,
+ SUN6I_CODEC_MIC_CTRL_LINEOUTRSRC,
+ sun6i_codec_lineout_src_enum_text);
+
+static const struct snd_kcontrol_new sun6i_codec_lineout_src[] = {
+ SOC_DAPM_ENUM("Line Out Source Playback Route",
+ sun6i_codec_lineout_src_enum),
+};
+
/* volume / mute controls */
static const DECLARE_TLV_DB_SCALE(sun6i_codec_dvol_scale, -7308, 116, 0);
static const DECLARE_TLV_DB_SCALE(sun6i_codec_hp_vol_scale, -6300, 100, 1);
static const DECLARE_TLV_DB_SCALE(sun6i_codec_out_mixer_pregain_scale,
-450, 150, 0);
+static const DECLARE_TLV_DB_RANGE(sun6i_codec_lineout_vol_scale,
+ 0, 1, TLV_DB_SCALE_ITEM(TLV_DB_GAIN_MUTE, 0, 1),
+ 2, 31, TLV_DB_SCALE_ITEM(-4350, 150, 0),
+);
static const struct snd_kcontrol_new sun6i_codec_codec_widgets[] = {
SOC_SINGLE_TLV("DAC Playback Volume", SUN4I_CODEC_DAC_DPC,
@@ -808,10 +828,18 @@ static const struct snd_kcontrol_new sun6i_codec_codec_widgets[] = {
SUN6I_CODEC_OM_DACA_CTRL,
SUN6I_CODEC_OM_DACA_CTRL_HPVOL, 0x3f, 0,
sun6i_codec_hp_vol_scale),
+ SOC_SINGLE_TLV("Line Out Playback Volume",
+ SUN6I_CODEC_MIC_CTRL,
+ SUN6I_CODEC_MIC_CTRL_LINEOUTVC, 0x1f, 0,
+ sun6i_codec_lineout_vol_scale),
SOC_DOUBLE("Headphone Playback Switch",
SUN6I_CODEC_OM_DACA_CTRL,
SUN6I_CODEC_OM_DACA_CTRL_LHPPAMUTE,
SUN6I_CODEC_OM_DACA_CTRL_RHPPAMUTE, 1, 0),
+ SOC_DOUBLE("Line Out Playback Switch",
+ SUN6I_CODEC_MIC_CTRL,
+ SUN6I_CODEC_MIC_CTRL_LINEOUTLEN,
+ SUN6I_CODEC_MIC_CTRL_LINEOUTREN, 1, 0),
/* Mixer pre-gains */
SOC_SINGLE_TLV("Line In Playback Volume",
SUN6I_CODEC_OM_PA_CTRL, SUN6I_CODEC_OM_PA_CTRL_LINEING,
@@ -853,6 +881,11 @@ static const struct snd_soc_dapm_widget sun6i_codec_codec_dapm_widgets[] = {
SND_SOC_DAPM_REG(snd_soc_dapm_supply, "HPCOM", SUN6I_CODEC_OM_PA_CTRL,
SUN6I_CODEC_OM_PA_CTRL_HPCOM_CTL, 0x3, 0x3, 0),
SND_SOC_DAPM_OUTPUT("HP"),
+
+ /* Line Out path */
+ SND_SOC_DAPM_MUX("Line Out Source Playback Route",
+ SND_SOC_NOPM, 0, 0, sun6i_codec_lineout_src),
+ SND_SOC_DAPM_OUTPUT("LINEOUT"),
};
static const struct snd_soc_dapm_route sun6i_codec_codec_dapm_routes[] = {
@@ -878,6 +911,12 @@ static const struct snd_soc_dapm_route sun6i_codec_codec_dapm_routes[] = {
{ "Headphone Amp", NULL, "Headphone Source Playback Route" },
{ "HP", NULL, "Headphone Amp" },
{ "HPCOM", NULL, "HPCOM Protection" },
+
+ /* Line Out Routes */
+ { "Line Out Source Playback Route", "Stereo", "Left Mixer" },
+ { "Line Out Source Playback Route", "Stereo", "Right Mixer" },
+ { "Line Out Source Playback Route", "Mono Differential", "Left Mixer" },
+ { "LINEOUT", NULL, "Line Out Source Playback Route" },
};
static struct snd_soc_codec_driver sun6i_codec_codec = {
--
2.10.1
^ permalink raw reply related
* Applied "ASoC: sun4i-codec: Add support for A31 analog microphone inputs" to the asoc tree
From: Mark Brown @ 2016-11-04 20:40 UTC (permalink / raw)
To: Chen-Yu Tsai; +Cc: Mark Brown, Liam Girdwood
In-Reply-To: <20161103075556.29018-10-wens-jdAy2FN1RRM@public.gmane.org>
The patch
ASoC: sun4i-codec: Add support for A31 analog microphone inputs
has been applied to the asoc tree at
git://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git
All being well this means that it will be integrated into the linux-next
tree (usually sometime in the next 24 hours) and sent to Linus during
the next merge window (or sooner if it is a bug fix), however if
problems are discovered then the patch may be dropped or reverted.
You may get further e-mails resulting from automated or manual testing
and review of the tree, please engage with people reporting problems and
send followup patches addressing any issues that are reported if needed.
If any updates are required or you are submitting further changes they
should be sent as incremental updates against current git, existing
patches will not be replaced.
Please add any relevant lists and maintainers to the CCs when replying
to this mail.
Thanks,
Mark
>From ecd5cdb4fd818b1cec55863d5de3683dad1c2f53 Mon Sep 17 00:00:00 2001
From: Chen-Yu Tsai <wens-jdAy2FN1RRM@public.gmane.org>
Date: Thu, 3 Nov 2016 15:55:51 +0800
Subject: [PATCH] ASoC: sun4i-codec: Add support for A31 analog microphone
inputs
The A31 internal codec has 3 microphone outputs, of which MIC2 and MIC3
are muxed internally. The resulting two microphone inputs have separate
gain controls and mixer inputs.
The codec also has 2 microphone bias pins. HBIAS is specifically for the
headphone jack, which also supports headphone detection and control
buttons. These extra functions are not supported yet. The other, MBIAS,
is for all other analog microphones.
There is also mention of digital microphone support, but documentation
is scarce, and no hardware with it is available.
Signed-off-by: Chen-Yu Tsai <wens-jdAy2FN1RRM@public.gmane.org>
Signed-off-by: Mark Brown <broonie-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
---
sound/soc/sunxi/sun4i-codec.c | 70 +++++++++++++++++++++++++++++++++++++++++++
1 file changed, 70 insertions(+)
diff --git a/sound/soc/sunxi/sun4i-codec.c b/sound/soc/sunxi/sun4i-codec.c
index a10251f4932e..f55718fe7c5b 100644
--- a/sound/soc/sunxi/sun4i-codec.c
+++ b/sound/soc/sunxi/sun4i-codec.c
@@ -776,6 +776,14 @@ static const struct snd_kcontrol_new sun6i_codec_mixer_controls[] = {
SUN6I_CODEC_OM_DACA_CTRL,
SUN6I_CODEC_OM_DACA_CTRL_LMIX_LINEINL,
SUN6I_CODEC_OM_DACA_CTRL_RMIX_LINEINR, 1, 0),
+ SOC_DAPM_DOUBLE("Mic1 Playback Switch",
+ SUN6I_CODEC_OM_DACA_CTRL,
+ SUN6I_CODEC_OM_DACA_CTRL_LMIX_MIC1,
+ SUN6I_CODEC_OM_DACA_CTRL_RMIX_MIC1, 1, 0),
+ SOC_DAPM_DOUBLE("Mic2 Playback Switch",
+ SUN6I_CODEC_OM_DACA_CTRL,
+ SUN6I_CODEC_OM_DACA_CTRL_LMIX_MIC2,
+ SUN6I_CODEC_OM_DACA_CTRL_RMIX_MIC2, 1, 0),
};
/* headphone controls */
@@ -794,6 +802,21 @@ static const struct snd_kcontrol_new sun6i_codec_hp_src[] = {
sun6i_codec_hp_src_enum),
};
+/* microphone controls */
+static const char * const sun6i_codec_mic2_src_enum_text[] = {
+ "Mic2", "Mic3",
+};
+
+static SOC_ENUM_SINGLE_DECL(sun6i_codec_mic2_src_enum,
+ SUN6I_CODEC_MIC_CTRL,
+ SUN6I_CODEC_MIC_CTRL_MIC2SLT,
+ sun6i_codec_mic2_src_enum_text);
+
+static const struct snd_kcontrol_new sun6i_codec_mic2_src[] = {
+ SOC_DAPM_ENUM("Mic2 Amplifier Source Route",
+ sun6i_codec_mic2_src_enum),
+};
+
/* line out controls */
static const char * const sun6i_codec_lineout_src_enum_text[] = {
"Stereo", "Mono Differential",
@@ -819,6 +842,10 @@ static const DECLARE_TLV_DB_RANGE(sun6i_codec_lineout_vol_scale,
0, 1, TLV_DB_SCALE_ITEM(TLV_DB_GAIN_MUTE, 0, 1),
2, 31, TLV_DB_SCALE_ITEM(-4350, 150, 0),
);
+static const DECLARE_TLV_DB_RANGE(sun6i_codec_mic_gain_scale,
+ 0, 0, TLV_DB_SCALE_ITEM(0, 0, 0),
+ 1, 7, TLV_DB_SCALE_ITEM(2400, 300, 0),
+);
static const struct snd_kcontrol_new sun6i_codec_codec_widgets[] = {
SOC_SINGLE_TLV("DAC Playback Volume", SUN4I_CODEC_DAC_DPC,
@@ -844,9 +871,42 @@ static const struct snd_kcontrol_new sun6i_codec_codec_widgets[] = {
SOC_SINGLE_TLV("Line In Playback Volume",
SUN6I_CODEC_OM_PA_CTRL, SUN6I_CODEC_OM_PA_CTRL_LINEING,
0x7, 0, sun6i_codec_out_mixer_pregain_scale),
+ SOC_SINGLE_TLV("Mic1 Playback Volume",
+ SUN6I_CODEC_OM_PA_CTRL, SUN6I_CODEC_OM_PA_CTRL_MIC1G,
+ 0x7, 0, sun6i_codec_out_mixer_pregain_scale),
+ SOC_SINGLE_TLV("Mic2 Playback Volume",
+ SUN6I_CODEC_OM_PA_CTRL, SUN6I_CODEC_OM_PA_CTRL_MIC2G,
+ 0x7, 0, sun6i_codec_out_mixer_pregain_scale),
+
+ /* Microphone Amp boost gains */
+ SOC_SINGLE_TLV("Mic1 Boost Volume", SUN6I_CODEC_MIC_CTRL,
+ SUN6I_CODEC_MIC_CTRL_MIC1BOOST, 0x7, 0,
+ sun6i_codec_mic_gain_scale),
+ SOC_SINGLE_TLV("Mic2 Boost Volume", SUN6I_CODEC_MIC_CTRL,
+ SUN6I_CODEC_MIC_CTRL_MIC2BOOST, 0x7, 0,
+ sun6i_codec_mic_gain_scale),
};
static const struct snd_soc_dapm_widget sun6i_codec_codec_dapm_widgets[] = {
+ /* Microphone inputs */
+ SND_SOC_DAPM_INPUT("MIC1"),
+ SND_SOC_DAPM_INPUT("MIC2"),
+ SND_SOC_DAPM_INPUT("MIC3"),
+
+ /* Microphone Bias */
+ SND_SOC_DAPM_SUPPLY("HBIAS", SUN6I_CODEC_MIC_CTRL,
+ SUN6I_CODEC_MIC_CTRL_HBIASEN, 0, NULL, 0),
+ SND_SOC_DAPM_SUPPLY("MBIAS", SUN6I_CODEC_MIC_CTRL,
+ SUN6I_CODEC_MIC_CTRL_MBIASEN, 0, NULL, 0),
+
+ /* Mic input path */
+ SND_SOC_DAPM_MUX("Mic2 Amplifier Source Route",
+ SND_SOC_NOPM, 0, 0, sun6i_codec_mic2_src),
+ SND_SOC_DAPM_PGA("Mic1 Amplifier", SUN6I_CODEC_MIC_CTRL,
+ SUN6I_CODEC_MIC_CTRL_MIC1AMPEN, 0, NULL, 0),
+ SND_SOC_DAPM_PGA("Mic2 Amplifier", SUN6I_CODEC_MIC_CTRL,
+ SUN6I_CODEC_MIC_CTRL_MIC2AMPEN, 0, NULL, 0),
+
/* Line In */
SND_SOC_DAPM_INPUT("LINEIN"),
@@ -893,15 +953,25 @@ static const struct snd_soc_dapm_route sun6i_codec_codec_dapm_routes[] = {
{ "Left DAC", NULL, "DAC Enable" },
{ "Right DAC", NULL, "DAC Enable" },
+ /* Microphone Routes */
+ { "Mic1 Amplifier", NULL, "MIC1"},
+ { "Mic2 Amplifier Source Route", "Mic2", "MIC2" },
+ { "Mic2 Amplifier Source Route", "Mic3", "MIC3" },
+ { "Mic2 Amplifier", NULL, "Mic2 Amplifier Source Route"},
+
/* Left Mixer Routes */
{ "Left Mixer", "DAC Playback Switch", "Left DAC" },
{ "Left Mixer", "DAC Reversed Playback Switch", "Right DAC" },
{ "Left Mixer", "Line In Playback Switch", "LINEIN" },
+ { "Left Mixer", "Mic1 Playback Switch", "Mic1 Amplifier" },
+ { "Left Mixer", "Mic2 Playback Switch", "Mic2 Amplifier" },
/* Right Mixer Routes */
{ "Right Mixer", "DAC Playback Switch", "Right DAC" },
{ "Right Mixer", "DAC Reversed Playback Switch", "Left DAC" },
{ "Right Mixer", "Line In Playback Switch", "LINEIN" },
+ { "Right Mixer", "Mic1 Playback Switch", "Mic1 Amplifier" },
+ { "Right Mixer", "Mic2 Playback Switch", "Mic2 Amplifier" },
/* Headphone Routes */
{ "Headphone Source Playback Route", "DAC", "Left DAC" },
--
2.10.1
^ permalink raw reply related
* Applied "ASoC: sun4i-codec: Add support for A31 board level audio routing" to the asoc tree
From: Mark Brown @ 2016-11-04 20:39 UTC (permalink / raw)
To: Chen-Yu Tsai; +Cc: Maxime Ripard, Mark Brown, Liam Girdwood
In-Reply-To: <20161103075556.29018-12-wens-jdAy2FN1RRM@public.gmane.org>
The patch
ASoC: sun4i-codec: Add support for A31 board level audio routing
has been applied to the asoc tree at
git://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git
All being well this means that it will be integrated into the linux-next
tree (usually sometime in the next 24 hours) and sent to Linus during
the next merge window (or sooner if it is a bug fix), however if
problems are discovered then the patch may be dropped or reverted.
You may get further e-mails resulting from automated or manual testing
and review of the tree, please engage with people reporting problems and
send followup patches addressing any issues that are reported if needed.
If any updates are required or you are submitting further changes they
should be sent as incremental updates against current git, existing
patches will not be replaced.
Please add any relevant lists and maintainers to the CCs when replying
to this mail.
Thanks,
Mark
>From 300a18d13f7eaec789e79dc45bce026e098b45da Mon Sep 17 00:00:00 2001
From: Chen-Yu Tsai <wens-jdAy2FN1RRM@public.gmane.org>
Date: Thu, 3 Nov 2016 15:55:53 +0800
Subject: [PATCH] ASoC: sun4i-codec: Add support for A31 board level audio
routing
The A31 SoC's codec has various inputs, outputs and microphone bias
supplies. These can be routed on the board in different ways, such as:
- HPCOM may be connected to have the headphone DC coupled.
- Microphones all use the MBIAS main microphone supply or one mic may
use the HBIAS supply, which supports headset detection and buttons.
- Line Out may be routed to an audio jack, or an onboard speaker amp
with power controls.
Add support for specifying the audio routes in the device tree.
Signed-off-by: Chen-Yu Tsai <wens-jdAy2FN1RRM@public.gmane.org>
Acked-by: Maxime Ripard <maxime.ripard-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org>
Signed-off-by: Mark Brown <broonie-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
---
.../devicetree/bindings/sound/sun4i-codec.txt | 33 ++++++++++++++++++++++
sound/soc/sunxi/sun4i-codec.c | 21 ++++++++++++--
2 files changed, 52 insertions(+), 2 deletions(-)
diff --git a/Documentation/devicetree/bindings/sound/sun4i-codec.txt b/Documentation/devicetree/bindings/sound/sun4i-codec.txt
index bf480e9683a3..d91a95377f49 100644
--- a/Documentation/devicetree/bindings/sound/sun4i-codec.txt
+++ b/Documentation/devicetree/bindings/sound/sun4i-codec.txt
@@ -22,6 +22,31 @@ Optional properties:
Required properties for the following compatibles:
- "allwinner,sun6i-a31-codec"
- resets: phandle to the reset control for this device
+- allwinner,audio-routing: A list of the connections between audio components.
+ Each entry is a pair of strings, the first being the
+ connection's sink, the second being the connection's
+ source. Valid names include:
+
+ Audio pins on the SoC:
+ "HP"
+ "HPCOM"
+ "LINEIN"
+ "LINEOUT"
+ "MIC1"
+ "MIC2"
+ "MIC3"
+
+ Microphone biases from the SoC:
+ "HBIAS"
+ "MBIAS"
+
+ Board connectors:
+ "Headphone"
+ "Headset Mic"
+ "Line In"
+ "Line Out"
+ "Mic"
+ "Speaker"
Example:
codec: codec@01c22c00 {
@@ -45,4 +70,12 @@ codec: codec@01c22c00 {
resets = <&ccu RST_APB1_CODEC>;
dmas = <&dma 15>, <&dma 15>;
dma-names = "rx", "tx";
+ allwinner,audio-routing =
+ "Headphone", "HP",
+ "Speaker", "LINEOUT",
+ "LINEIN", "Line In",
+ "MIC1", "MBIAS",
+ "MIC1", "Mic",
+ "MIC2", "HBIAS",
+ "MIC2", "Headset Mic";
};
diff --git a/sound/soc/sunxi/sun4i-codec.c b/sound/soc/sunxi/sun4i-codec.c
index f55718fe7c5b..1934db29b2b5 100644
--- a/sound/soc/sunxi/sun4i-codec.c
+++ b/sound/soc/sunxi/sun4i-codec.c
@@ -1104,9 +1104,19 @@ static struct snd_soc_card *sun4i_codec_create_card(struct device *dev)
return card;
};
+static const struct snd_soc_dapm_widget sun6i_codec_card_dapm_widgets[] = {
+ SND_SOC_DAPM_HP("Headphone", NULL),
+ SND_SOC_DAPM_LINE("Line In", NULL),
+ SND_SOC_DAPM_LINE("Line Out", NULL),
+ SND_SOC_DAPM_MIC("Headset Mic", NULL),
+ SND_SOC_DAPM_MIC("Mic", NULL),
+ SND_SOC_DAPM_SPK("Speaker", sun4i_codec_spk_event),
+};
+
static struct snd_soc_card *sun6i_codec_create_card(struct device *dev)
{
struct snd_soc_card *card;
+ int ret;
card = devm_kzalloc(dev, sizeof(*card), GFP_KERNEL);
if (!card)
@@ -1116,8 +1126,15 @@ static struct snd_soc_card *sun6i_codec_create_card(struct device *dev)
if (!card->dai_link)
return ERR_PTR(-ENOMEM);
- card->dev = dev;
- card->name = "A31 Audio Codec";
+ card->dev = dev;
+ card->name = "A31 Audio Codec";
+ card->dapm_widgets = sun6i_codec_card_dapm_widgets;
+ card->num_dapm_widgets = ARRAY_SIZE(sun6i_codec_card_dapm_widgets);
+ card->fully_routed = true;
+
+ ret = snd_soc_of_parse_audio_routing(card, "allwinner,audio-routing");
+ if (ret)
+ dev_warn(dev, "failed to parse audio-routing: %d\n", ret);
return card;
};
--
2.10.1
^ permalink raw reply related
* Re: [PATCH 14/17] ASoC: add simple-graph-card document
From: Mark Brown @ 2016-11-04 20:33 UTC (permalink / raw)
To: Kuninori Morimoto
Cc: Rob Herring, Linux-ALSA, Liam Girdwood, Simon, Laurent, Guennadi,
Grant Likely, Frank Rowand, Linux-DT, Linux-Kernel
In-Reply-To: <8760o9b9xm.wl%kuninori.morimoto.gx-zM6kxYcvzFBBDgjK7y7TUQ@public.gmane.org>
[-- Attachment #1: Type: text/plain, Size: 827 bytes --]
On Mon, Oct 31, 2016 at 01:19:58AM +0000, Kuninori Morimoto wrote:
> +This Simple-Graph-Card should be located as CPU driver's port[s].
> +And then, CPU driver need to probe it by itself.
This document really needs quite a bit of fleshing out but I'm not sure
that should be a blocker for the series as a whole especially given that
English is not your native language - we can build out later. I think
based on what I'm understanding here I like what I'm seeing. It'd be
good to get some confirmation from the people with more of_graph
knowledge that this is a good usage.
One thing I'm not 100% clear on here is why it has to be a CPU DAI (I'm
guessing just one of them though the above says ports as an option?)
that creates the card? Is there a concrete reason for that or is it
just being defined as good pracctice?
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 455 bytes --]
^ permalink raw reply
* Re: [PATCH 05/17] ASoC: soc-core: snd_soc_get_dai_name() become non static
From: Mark Brown @ 2016-11-04 20:24 UTC (permalink / raw)
To: Kuninori Morimoto
Cc: Rob Herring, Linux-ALSA, Liam Girdwood, Simon, Laurent, Guennadi,
Grant Likely, Frank Rowand, Linux-DT, Linux-Kernel
In-Reply-To: <87ins9ba2c.wl%kuninori.morimoto.gx-zM6kxYcvzFBBDgjK7y7TUQ@public.gmane.org>
[-- Attachment #1: Type: text/plain, Size: 587 bytes --]
On Mon, Oct 31, 2016 at 01:17:09AM +0000, Kuninori Morimoto wrote:
> From: Kuninori Morimoto <kuninori.morimoto.gx-zM6kxYcvzFBBDgjK7y7TUQ@public.gmane.org>
>
> snd_soc_get_dai_name() is used from snd_soc_of_get_dai_name(),
> and it is assuming that DT is using "sound-dai" / "#sound-dai-cells".
> But graph base DT is using "remote-endpoint". This patch makes
> snd_soc_get_dai_name() non static for graph support.
I was going to apply these first few patches but unless I'm missing
something they don't seem to apply against current code - can you please
check and resend?
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 455 bytes --]
^ permalink raw reply
* Re: [PATCH 5/6] arm64: dts: msm8994 SoC and Huawei Angler (Nexus 6P) support
From: Stephen Boyd @ 2016-11-04 20:12 UTC (permalink / raw)
To: Andy Gross
Cc: Jeremy McNicoll, Jeremy McNicoll,
linux-arm-msm-u79uwXL29TY76Z2rM5mHXA,
linux-soc-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA, robh-DgEjT+Ai2ygdnm+yROfE0A,
arnd-r2nGTMty4D4, bjorn.andersson-QSEj5FYQhm4dnm+yROfE0A,
mark.rutland-5wv7dgnIgG8, michael.scott-QSEj5FYQhm4dnm+yROfE0A,
Bastian Köcher
In-Reply-To: <20161103224422.GB5135@hector>
On 11/03, Andy Gross wrote:
> On Thu, Nov 03, 2016 at 03:42:36PM -0700, Stephen Boyd wrote:
> > On 11/03/2016 03:32 PM, Andy Gross wrote:
> > >> On 2016-10-27 5:06 PM, Stephen Boyd wrote:
> > >>> Please replace this with something more specific for the actual
> > >>> board. Preferably with the board manufacturer vendor prefix and
> > >>> some sort of string for the board.
> > > Something like?
> > >
> > > "huawei,nexus-6P", "qcom,msm8994"
> >
> > Sure, except completely remove qcom,msm8994 from there.
>
> Hmmm ok. I just briefly looked at one of the sony boards and used that as an
> example. So there shouldn't be any link to the underlying soc in the compat?
Two people asked the same question. I don't see how having the
SoC in the root compatible string does anything. Of course,
having it there doesn't hurt anything either so I don't really
care. And it may help if we want to test for SoC compatibility at
some point.
Of course, we have an SoC node, so I'd think we would put the SoC
model number into that node's compatible string. In the ePAPR it
looks like they have compatible = “fsl,mpc8572ds”, which is a
board/platform. The "SoC" on there is an mpc8572e.
In practice, there doesn't seem to be any consistency here and it
feels like everything is vague on purpose with regards to
compatible strings, so either way is fine for me.
--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
--
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: device tree verification tools
From: Grant Likely @ 2016-11-04 20:07 UTC (permalink / raw)
To: Frank Rowand
Cc: Julia Lawall, Matt Porter, Behan Webster, Rob Herring,
David Gibson, Pantelis Antoniou,
devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
devicetree-spec-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <581CE982.60605-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
On Fri, Nov 4, 2016 at 2:03 PM, Frank Rowand <frowand.list-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
> On 07/26/16 13:43, Julia Lawall wrote:
>> I saw that there will be a microconference on device trees at Linux
>> Plumbers. Unfortunately, I won't be able to attend, due to another event
>> at the same time, but I was wondering what is the status of verification
>> tools for device tree specifications?
>>
>> thanks,
>> julia
>>
>
> Hi Julia,
>
> Grant Likely is breathing new life into the verification effort.
Hey Julia,
The status is: there are no verification tools for dt. :-)
I'm /hoping/ to fix that. I've started experimenting with a grammar
for DT schema and writing a schema validation tool, but this isn't my
domain of expertise. I could certainly use your insight. You can see
some of what I've been playing with in this git tree:
https://github.com/glikely/dtgendoc
It is little more than prototype code, and nothing has been formalized
yet. I'm open to taking other approaches.
Cheers,
g.
>
> -Frank
^ permalink raw reply
* Re: device tree verification tools
From: Frank Rowand @ 2016-11-04 20:03 UTC (permalink / raw)
To: Julia Lawall, mporter-OWPKS81ov/FWk0Htik3J/w,
behanw-k/hB3zQhLwledRVtV/plodBPR1lH4CV8,
robh+dt-DgEjT+Ai2ygdnm+yROfE0A,
david-xT8FGy+AXnRB3Ne2BGzF6laj5H9X9Tb+,
pantelis.antoniou-OWPKS81ov/FWk0Htik3J/w
Cc: devicetree-u79uwXL29TY76Z2rM5mHXA,
devicetree-spec-u79uwXL29TY76Z2rM5mHXA, Grant Likely
In-Reply-To: <alpine.DEB.2.10.1607262241240.3426@hadrien>
On 07/26/16 13:43, Julia Lawall wrote:
> I saw that there will be a microconference on device trees at Linux
> Plumbers. Unfortunately, I won't be able to attend, due to another event
> at the same time, but I was wondering what is the status of verification
> tools for device tree specifications?
>
> thanks,
> julia
>
Hi Julia,
Grant Likely is breathing new life into the verification effort.
-Frank
^ permalink raw reply
* Re: [PATCH 2/5] drivers: gpio: Add support for multiple IPs
From: Grygorii Strashko @ 2016-11-04 19:59 UTC (permalink / raw)
To: Linus Walleij, Keerthy
Cc: Roger Quadros, Alexandre Courbot, Lokesh Vutla, Rob Herring,
linux-gpio-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, Linux-OMAP
In-Reply-To: <CACRpkdZmuc__QL6b7Jvb8xL5Bm+PD2X60NtiugrnH7iAO=-tLQ-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
On 11/04/2016 09:28 AM, Linus Walleij wrote:
> On Thu, Oct 27, 2016 at 10:07 AM, Keerthy <j-keerthy-l0cyMroinI0@public.gmane.org> wrote:
>> On Thursday 27 October 2016 01:23 PM, Roger Quadros wrote:
>>> On 27/10/16 06:42, Keerthy wrote:
>>>> On Sunday 23 October 2016 04:02 PM, Linus Walleij wrote:
>>>>> On Wed, Oct 19, 2016 at 7:33 AM, Keerthy <j-keerthy-l0cyMroinI0@public.gmane.org> wrote:
>>>>>> From: Lokesh Vutla <lokeshvutla-l0cyMroinI0@public.gmane.org>
>
>>>> In case of k2g. There are 2 big GPIO modules GPIO0 and GPIO1.
>>>> GPIO0 comprises of 144 GPIOs
>>>> and GPIO1 has about 68 GPIOs. Wanted feedback from you on how this is
>>>> being modeled.
>>>>
>>>> I am creating a controller for every 32 GPIOs under the big module each
>>>> containing a gpio_chip. Each 32 GPIOs chip has 2 banks of 16 GPIOs each.
>>>> Each 16 GPIO bank has an interrupt.
>>>>
>>>> Is this modeling fine or do you think creating one chip with 144 pins and
>>>> another with 68 pins is a better way?
>>>
>>>
>>> If GPIO0 has 144 GPIOs, why don't we model it as a gpiochip with 144
>>> GPIOs?
>>> What is the benefit of partitioning it into gpiochips of 32 GPIOs each?
>>
>> 144 GPIOs where in 16 GPIOs form a bank. So about 9 banks with one interrupt
>> each. So split it into gpiochips with 32 GPIOs each handling 2 Interrupts.
>
> I'm a bit confused.
>
> This sounds like you should either have one gpio_chip per interrupt
> (if that fits with how the device tree looks) or one big gpio_chip for
> all the lines.
yep. This HW confuses a bit :(, So, there are few links on TRMs/DM and
my brief overview:
Keystone k2g (66AK2G02) http://www.ti.com/lit/ug/spruhy8d/spruhy8d.pdf
Keystone k2hk/e/l http://www.ti.com/lit/ug/sprugv1/sprugv1.pdf
omap-l138 http://www.ti.com/lit/ug/spruh77c/spruh77c.pdf
Each GPIO IP is implemented as GPIO controller which has some set of
common registers (minimum BINTEN) and up to 16 (?) gpio banks - 16 pins per bank.
SoC may contain more than one GPIO controllers.
GPIO banks groped by two in 32 bit registers, so overall registers structure:
common 0h GPIO_PID Peripheral Identification Register
common 8h GPIO_BINTEN Interrupt Per-Bank Enable Register
banks0&1 10h GPIO_DIR01 Direction 0 and 1 Register
14h GPIO_OUT_DATA01 Output Data 0 and 1 Register
18h GPIO_SET_DATA01 Set Data 0 and 1 Register
1Ch GPIO_CLR_DATA01 Clear Data 0 and 1 Register
20h GPIO_IN_DATA01 Input Data 0 and 1
24h GPIO_SET_RIS_TRIG01 Set Rising Edge Interrupt 0 and 1
28h GPIO_CLR_RIS_TRIG01 Clear Rising Edge Interrupt 0 and 1
2Ch GPIO_SET_FAL_TRIG01 Set Falling Edge Interrupt 0 and 1
30h GPIO_CLR_FAL_TRIG01 Clear Falling Edge Interrupt 0 and 1
34h GPIO_INTSTAT01 GPIO Interrupt status 0 and 1 Register
banks2&3 38h DIR23 GPIO Banks 2 and 3 Direction Register
...
IRQ handling can be done in two ways - depending on SoC - which can be combined
on some SoCs (not supported by current driver)
1) Direct IRQs - each GPIO pin has separate IRQ line assigned in Main IRQ controller (example k2hk/e/l)
2) banked IRQs - each bank (16 pins) has one assigned IRQ. So, two IRQs per banksX&Y register set.
>
> The DT model sort of mandates how the interrupts should be mapped
> at this point, and as far as I can tell from the binding the example looks
> like so:
>
> gpio: gpio@1e26000 {
> compatible = "ti,dm6441-gpio";
> gpio-controller;
> #gpio-cells = <2>;
> reg = <0x226000 0x1000>;
> interrupt-parent = <&intc>;
> interrupts = <42 IRQ_TYPE_EDGE_BOTH 43 IRQ_TYPE_EDGE_BOTH
> 44 IRQ_TYPE_EDGE_BOTH 45 IRQ_TYPE_EDGE_BOTH
> 46 IRQ_TYPE_EDGE_BOTH 47 IRQ_TYPE_EDGE_BOTH
> 48 IRQ_TYPE_EDGE_BOTH 49 IRQ_TYPE_EDGE_BOTH
> 50 IRQ_TYPE_EDGE_BOTH>;
> ti,ngpio = <144>;
> ti,davinci-gpio-unbanked = <0>;
> interrupt-controller;
> #interrupt-cells = <2>;
> };
Above, DT bindings models Davinci GPIO IP as monolithic GPIO controller
with N gpio pins, but internally separate GPIO chips are created for each
banksX&Y register set (32 pins, 2 banked irq -or- 32 direct irqs).
Translation from linear GPIO numbering to the proper internal GPIO chip is done
using chip.of_xlate().
>
> So I don't see any reason to split this up in subchips internally in
> Linux?
>
--
regards,
-grygorii
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH v4 00/23] soc: renesas: Add R-Car RST driver for obtaining mode pin state
From: Stephen Boyd @ 2016-11-04 19:49 UTC (permalink / raw)
To: Geert Uytterhoeven
Cc: devicetree@vger.kernel.org, Arnd Bergmann, Kevin Hilman,
Michael Turquette, Magnus Damm, linux-kernel@vger.kernel.org,
Linux-Renesas, Simon Horman, Philipp Zabel, Olof Johansson,
linux-arm-kernel@lists.infradead.org
In-Reply-To: <CAMuHMdXOW4Ubafu=x9pCw_W-MtLGe3N974dbfHCH5TJuUAeYrQ@mail.gmail.com>
On 11/02, Geert Uytterhoeven wrote:
> On Tue, Nov 1, 2016 at 12:25 AM, Stephen Boyd <sboyd@codeaurora.org> wrote:
> >
> > Would the pull requests for clk also have dts changes at the base
> > of the tree? Perhaps clk side can just ack the clk patches and
>
> Yes they would: this is moving functionality from platform code to DT.
> Without the DT updates, it will break bisection (except for R-Car Gen2,
> where we have fallback code to handle old DTBs).
>
> > then have it all routed through arm-soc? The only worry I have is
> > if we need to make some sort of change in clk side that conflicts
> > with these changes. I don't usually like taking dts changes
> > through clk tree, so I'd like to avoid that if possible.
>
> Everything could go through arm-soc only with your Acked-by.
> However, there are new clock drivers pending on this series.
> Either they have to go through arm-soc, too, or this series would
> be pulled into the clk tree with these new clock drivers.
>
> > Part E could happen anytime after everything else happens, so
> > that doesn't seem like a concern.
>
> Part E can indeed by postponed.
> But if parts A-D are applied together, there's no reason to postpone part E.
>
> > Part C could also be made to
> > only call into the new reset drivers if the reset dts nodes are
> > present? If that's done then we could merge clk patches anytime
> > and remove the dead code and the node search at some later time
> > when everything has settled?
>
> That would require adding more backwards compatibility code for
> old DTBs, even for platform where we're not interested in maintaining
> that. In addition, Part C depends on the header file for the reset driver
> to compile the clock driver, even if you would add some DT detection,
> and on the reset driver to link. So I'm afraid this is not feasible.
>
TL;DR: Sounds fine, I'll be on the lookout for the PR.
Longer version: Let me step back a bit and actually think about
this longer than 2 minutes. From what I see
rcar_rst_read_mode_pins() already returns -ENODEV if the nodes
aren't present. Great.
So clk tree could be given a pull for the clk patches, part C, on
top of part A, the reset driver. If the rcar_rst_read_mode_pins()
returns failure because the node is missing, we fall back to the
old style of doing things. Some drivers already do that anyway,
so this looks to be replacing things like
if (rcar_rst_read_mode_pins())
return;
with
if (rcar_rst_read_mode_pins() != -ENODEV)
return;
Then in arm-soc tree, the dts patches are merged. That causes us
to do some duplicate work reading the pins twice in mach-shmobile
and in the new reset driver. That's duplicate/wasteful, but it
works. Finally, everything is merged together into a tagged
release. The mach-shmobile changes can happen anytime after that
(part D). Again we're left with dead code in the clk driver (part
E) until the dependency merges, but that's ok. Once part D merges
we can get rid of the dead code in part E and any backwards
compatibility we don't want to maintain.
In summary, it's all feasible to do this and most people wouldn't
have had to know about the dependency chain but it's not fast by
any means. Instead we merge everything in one shot and get it
over with now.
--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
^ permalink raw reply
* Re: [PATCH] Revert "console: don't prefer first registered if DT specifies stdout-path"
From: Andrew Morton @ 2016-11-04 19:39 UTC (permalink / raw)
To: Hans de Goede
Cc: Linus Torvalds, Paul Burton, Rob Herring, Frank Rowand,
Thorsten Leemhuis, Greg Kroah-Hartman, Tejun Heo,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <20161104121135.4780-2-hdegoede-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
On Fri, 4 Nov 2016 13:11:35 +0100 Hans de Goede <hdegoede-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org> wrote:
> This reverts commit 05fd007e4629 ("console: don't prefer first registered
> if DT specifies stdout-path").
>
> The reverted commit changes existing behavior on which many ARM boards
> rely. Many ARM small-board-computers, like e.g. the Raspberry Pi have
> both a video output and a serial console. Depending on whether the user
> is using the device as a more regular computer; or as a headless device
> we need to have the console on either one or the other.
>
> Many users rely on the kernel behavior of the console being present on
> both outputs, before the reverted commit the console setup with no
> console= kernel arguments on an ARM board which sets stdout-path in dt
> would look like this:
>
> [root@localhost ~]# cat /proc/consoles
> ttyS0 -W- (EC p a) 4:64
> tty0 -WU (E p ) 4:1
>
> Where as after the reverted commit, it looks like this:
>
> [root@localhost ~]# cat /proc/consoles
> ttyS0 -W- (EC p a) 4:64
>
> This commit reverts commit 05fd007e4629 ("console: don't prefer first
> registered if DT specifies stdout-path") restoring the original behavior.
>
> Signed-off-by: Hans de Goede <hdegoede-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
I've added cc:stable-u79uwXL29TY76Z2rM5mHXA@public.gmane.org to my copy of this.
--
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
* Issue with dt_to_config with dts files that include headers from dt-bindings
From: Peter Robinson @ 2016-11-04 19:19 UTC (permalink / raw)
To: Rob Herring, Frank Rowand, devicetree-u79uwXL29TY76Z2rM5mHXA,
gaurav.minocha.os-Re5JQEeQqe8AvxtiuMwx3w
Hi Gaurav, Rob and Frank,
I've just discovered the dt_to_config script (awesome thanks!) but it
errors out when a dts(i) includes a header file from dt-bindings. EG
./scripts/dtc/dt_to_config arch/arm/boot/dts/am335x-boneblack.dts
In file included from arch/arm/boot/dts/am335x-boneblack.dts:10:0:
arch/arm/boot/dts/am33xx.dtsi:11:35: error: no include path in which
to search for dt-bindings/gpio/gpio.h
#include <dt-bindings/gpio/gpio.h>
^
arch/arm/boot/dts/am33xx.dtsi:12:40: error: no include path in which
to search for dt-bindings/pinctrl/am33xx.h
#include <dt-bindings/pinctrl/am33xx.h>
^
arch/arm/boot/dts/am335x-boneblack.dts:12:41: error: no include path
in which to search for dt-bindings/display/tda998x.h
#include <dt-bindings/display/tda998x.h>
^
Error: arch/arm/boot/dts/am335x-bone-common.dtsi:33.23-24 syntax error
FATAL ERROR: Unable to parse input tree
Regards,
Peter
--
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 v3 2/6] arm64: arch_timer: Introduce a generic erratum handing mechanism for fsl-a008585
From: Will Deacon @ 2016-11-04 18:55 UTC (permalink / raw)
To: Scott Wood
Cc: Ding Tianhong, catalin.marinas-5wv7dgnIgG8,
marc.zyngier-5wv7dgnIgG8, mark.rutland-5wv7dgnIgG8,
devicetree-u79uwXL29TY76Z2rM5mHXA,
shawnguo-DgEjT+Ai2ygdnm+yROfE0A, stuart.yoder-3arQi8VN3Tc,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linuxarm-hv44wF8Li93QT0dZR+AlfA,
hanjun.guo-QSEj5FYQhm4dnm+yROfE0A
In-Reply-To: <20161104182050.GA1651-fOR+EgIDQEHk1uMJSBkQmQ@public.gmane.org>
On Fri, Nov 04, 2016 at 01:20:50PM -0500, Scott Wood wrote:
> On Fri, Nov 04, 2016 at 09:06:30PM +0800, Ding Tianhong wrote:
> > The workaround for hisilicon,161601 will check the return value of the system counter
> > by different way, in order to distinguish with the fsl-a008585 workaround, introduce
> > a new generic erratum handing mechanism for fsl-a008585 and rename some functions.
> >
> > v2: Introducing a new generic erratum handling mechanism for fsl erratum a008585.
> >
> > v3: Introducing the erratum_workaround_set_sne generic function for fsl erratum a008585
> > and make the #define __fsl_a008585_read_reg to be private to the .c file instead of
> > being globally visible. After discussion with Marc and Will, a consensus decision was
> > made to remove the commandline parameter for enabling fsl,erratum-a008585 erratum,
> > and make some generic name more specific, export timer_unstable_counter_workaround
> > for module access.
>
> The command line paramter was added at Marc's request to provide a way of
> enbaling the workaround in a KVM guest, until API is added to allow QEMU to
> discover the need to set the property in the guest device tree. Is there an
> alternative?
Yes -- generate the device-tree property to indicate that there's an issue.
Will
--
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 v3 2/6] arm64: arch_timer: Introduce a generic erratum handing mechanism for fsl-a008585
From: Scott Wood @ 2016-11-04 18:20 UTC (permalink / raw)
To: Ding Tianhong
Cc: catalin.marinas-5wv7dgnIgG8, will.deacon-5wv7dgnIgG8,
marc.zyngier-5wv7dgnIgG8, mark.rutland-5wv7dgnIgG8,
devicetree-u79uwXL29TY76Z2rM5mHXA,
shawnguo-DgEjT+Ai2ygdnm+yROfE0A, stuart.yoder-3arQi8VN3Tc,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linuxarm-hv44wF8Li93QT0dZR+AlfA,
hanjun.guo-QSEj5FYQhm4dnm+yROfE0A
In-Reply-To: <1478264794-14652-2-git-send-email-dingtianhong-hv44wF8Li93QT0dZR+AlfA@public.gmane.org>
On Fri, Nov 04, 2016 at 09:06:30PM +0800, Ding Tianhong wrote:
> The workaround for hisilicon,161601 will check the return value of the system counter
> by different way, in order to distinguish with the fsl-a008585 workaround, introduce
> a new generic erratum handing mechanism for fsl-a008585 and rename some functions.
>
> v2: Introducing a new generic erratum handling mechanism for fsl erratum a008585.
>
> v3: Introducing the erratum_workaround_set_sne generic function for fsl erratum a008585
> and make the #define __fsl_a008585_read_reg to be private to the .c file instead of
> being globally visible. After discussion with Marc and Will, a consensus decision was
> made to remove the commandline parameter for enabling fsl,erratum-a008585 erratum,
> and make some generic name more specific, export timer_unstable_counter_workaround
> for module access.
The command line paramter was added at Marc's request to provide a way of
enbaling the workaround in a KVM guest, until API is added to allow QEMU to
discover the need to set the property in the guest device tree. Is there an
alternative?
-Scott
--
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 v3 2/2] reset: Add the TI SCI reset driver
From: Andrew F. Davis @ 2016-11-04 17:42 UTC (permalink / raw)
To: Nishanth Menon, Tero Kristo, Santosh Shilimkar, Philipp Zabel,
Rob Herring, Mark Rutland, Suman Anna
Cc: linux-arm-kernel, devicetree, linux-kernel, Andrew F . Davis
In-Reply-To: <20161104174240.9688-1-afd@ti.com>
Some TI Keystone family of SoCs contain a system controller (like the
Power Management Micro Controller (PMMC) on K2G SoCs) that manage the
low-level device control (like clocks, resets etc) for the various
hardware modules present on the SoC. These device control operations
are provided to the host processor OS through a communication protocol
called the TI System Control Interface (TI SCI) protocol.
This patch adds a reset driver that communicates to the system
controller over the TI SCI protocol for performing reset management
of various devices present on the SoC. Various reset functionalities
are achieved by the means of different TI SCI device operations
provided by the TI SCI framework.
Signed-off-by: Andrew F. Davis <afd@ti.com>
[s-anna@ti.com: documentation changes, revised commit message]
Signed-off-by: Suman Anna <s-anna@ti.com>
Signed-off-by: Nishanth Menon <nm@ti.com>
---
MAINTAINERS | 1 +
drivers/reset/Kconfig | 9 ++
drivers/reset/Makefile | 1 +
drivers/reset/reset-ti-sci.c | 272 +++++++++++++++++++++++++++++++++++++++++++
4 files changed, 283 insertions(+)
create mode 100644 drivers/reset/reset-ti-sci.c
diff --git a/MAINTAINERS b/MAINTAINERS
index accf991..b93d91a 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -11901,6 +11901,7 @@ F: include/dt-bindings/clock/k2g.h
F: drivers/clk/keystone/sci-clk.c
F: Documentation/devicetree/bindings/reset/ti,sci-reset.txt
F: include/dt-bindings/reset/k2g.h
+F: drivers/reset/reset-ti-sci.c
THANKO'S RAREMONO AM/FM/SW RADIO RECEIVER USB DRIVER
M: Hans Verkuil <hverkuil@xs4all.nl>
diff --git a/drivers/reset/Kconfig b/drivers/reset/Kconfig
index 06d9fa2..4c21c9d 100644
--- a/drivers/reset/Kconfig
+++ b/drivers/reset/Kconfig
@@ -66,6 +66,15 @@ config RESET_SUNXI
help
This enables the reset driver for Allwinner SoCs.
+config RESET_TI_SCI
+ tristate "TI System Control Interface (TI-SCI) reset driver"
+ depends on RESET_CONTROLLER
+ depends on TI_SCI_PROTOCOL
+ help
+ This enables the reset driver support over TI System Control Interface
+ available on some new TI's SoCs. If you wish to use reset resources
+ managed by the TI System Controller, say Y here. Otherwise, say N.
+
config TI_SYSCON_RESET
tristate "TI SYSCON Reset Driver"
depends on HAS_IOMEM
diff --git a/drivers/reset/Makefile b/drivers/reset/Makefile
index bbe7026..36321f2 100644
--- a/drivers/reset/Makefile
+++ b/drivers/reset/Makefile
@@ -10,6 +10,7 @@ obj-$(CONFIG_RESET_PISTACHIO) += reset-pistachio.o
obj-$(CONFIG_RESET_SOCFPGA) += reset-socfpga.o
obj-$(CONFIG_RESET_STM32) += reset-stm32.o
obj-$(CONFIG_RESET_SUNXI) += reset-sunxi.o
+obj-$(CONFIG_RESET_TI_SCI) += reset-ti-sci.o
obj-$(CONFIG_TI_SYSCON_RESET) += reset-ti-syscon.o
obj-$(CONFIG_RESET_UNIPHIER) += reset-uniphier.o
obj-$(CONFIG_RESET_ZYNQ) += reset-zynq.o
diff --git a/drivers/reset/reset-ti-sci.c b/drivers/reset/reset-ti-sci.c
new file mode 100644
index 0000000..9ac8499
--- /dev/null
+++ b/drivers/reset/reset-ti-sci.c
@@ -0,0 +1,272 @@
+/*
+ * Texas Instrument's System Control Interface (TI-SCI) reset driver
+ *
+ * Copyright (C) 2015-2016 Texas Instruments Incorporated - http://www.ti.com/
+ * Andrew F. Davis <afd@ti.com>
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ *
+ * This program is distributed "as is" WITHOUT ANY WARRANTY of any
+ * kind, whether express or implied; without even the implied warranty
+ * of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ */
+
+#include <linux/idr.h>
+#include <linux/module.h>
+#include <linux/mutex.h>
+#include <linux/of.h>
+#include <linux/platform_device.h>
+#include <linux/reset-controller.h>
+#include <linux/soc/ti/ti_sci_protocol.h>
+
+/**
+ * struct ti_sci_reset_control - reset control structure
+ * @dev_id: SoC-specific device identifier
+ * @reset_mask: reset mask to use for toggling reset
+ * @lock: synchronize reset_mask read-modify-writes
+ */
+struct ti_sci_reset_control {
+ u32 dev_id;
+ u32 reset_mask;
+ struct mutex lock;
+};
+
+/**
+ * struct ti_sci_reset_data - reset controller information structure
+ * @rcdev: reset controller entity
+ * @dev: reset controller device pointer
+ * @sci: TI SCI handle used for communication with system controller
+ * @idr: idr structure for mapping ids to reset control structures
+ */
+struct ti_sci_reset_data {
+ struct reset_controller_dev rcdev;
+ struct device *dev;
+ const struct ti_sci_handle *sci;
+ struct idr idr;
+};
+
+#define to_ti_sci_reset_data(p) \
+ container_of((p), struct ti_sci_reset_data, rcdev)
+
+/**
+ * ti_sci_reset_set() - program a device's reset
+ * @rcdev: reset controller entity
+ * @id: ID of the reset to toggle
+ * @assert: boolean flag to indicate assert or deassert
+ *
+ * This is a common internal function used to assert or deassert a device's
+ * reset using the TI SCI protocol. The device's reset is asserted if the
+ * @assert argument is true, or deasserted if @assert argument is false.
+ * The mechanism itself is a read-modify-write procedure, the current device
+ * reset register is read using a TI SCI device operation, the new value is
+ * set or un-set using the reset's mask, and the new reset value written by
+ * using another TI SCI device operation.
+ *
+ * Return: 0 for successful request, else a corresponding error value
+ */
+static int ti_sci_reset_set(struct reset_controller_dev *rcdev,
+ unsigned long id, bool assert)
+{
+ struct ti_sci_reset_data *data = to_ti_sci_reset_data(rcdev);
+ const struct ti_sci_handle *sci = data->sci;
+ const struct ti_sci_dev_ops *dev_ops = &sci->ops.dev_ops;
+ struct ti_sci_reset_control *control;
+ u32 reset_state;
+ int ret;
+
+ control = idr_find(&data->idr, id);
+ if (!control)
+ return -EINVAL;
+
+ mutex_lock(&control->lock);
+
+ ret = dev_ops->get_device_resets(sci, control->dev_id,
+ &reset_state);
+ if (ret)
+ goto out;
+
+ if (assert)
+ reset_state |= control->reset_mask;
+ else
+ reset_state &= ~control->reset_mask;
+
+ ret = dev_ops->set_device_resets(sci, control->dev_id,
+ reset_state);
+out:
+ mutex_unlock(&control->lock);
+
+ return ret;
+}
+
+/**
+ * ti_sci_reset_assert() - assert device reset
+ * @rcdev: reset controller entity
+ * @id: ID of the reset to be asserted
+ *
+ * This function implements the reset driver op to assert a device's reset
+ * using the TI SCI protocol. This invokes the function ti_sci_reset_set()
+ * with the corresponding parameters as passed in, but with the @assert
+ * argument set to true for asserting the reset.
+ *
+ * Return: 0 for successful request, else a corresponding error value
+ */
+static int ti_sci_reset_assert(struct reset_controller_dev *rcdev,
+ unsigned long id)
+{
+ return ti_sci_reset_set(rcdev, id, true);
+}
+
+/**
+ * ti_sci_reset_deassert() - deassert device reset
+ * @rcdev: reset controller entity
+ * @id: ID of the reset to be deasserted
+ *
+ * This function implements the reset driver op to deassert a device's reset
+ * using the TI SCI protocol. This invokes the function ti_sci_reset_set()
+ * with the corresponding parameters as passed in, but with the @assert
+ * argument set to false for deasserting the reset.
+ *
+ * Return: 0 for successful request, else a corresponding error value
+ */
+static int ti_sci_reset_deassert(struct reset_controller_dev *rcdev,
+ unsigned long id)
+{
+ return ti_sci_reset_set(rcdev, id, false);
+}
+
+/**
+ * ti_sci_reset_status() - check device reset status
+ * @rcdev: reset controller entity
+ * @id: ID of reset to be checked
+ *
+ * This function implements the reset driver op to return the status of a
+ * device's reset using the TI SCI protocol. The reset register value is read
+ * by invoking the TI SCI device operation .get_device_resets(), and the
+ * status of the specific reset is extracted and returned using this reset's
+ * reset mask.
+ *
+ * Return: 0 if reset is deasserted, or a non-zero value if reset is asserted
+ */
+static int ti_sci_reset_status(struct reset_controller_dev *rcdev,
+ unsigned long id)
+{
+ struct ti_sci_reset_data *data = to_ti_sci_reset_data(rcdev);
+ const struct ti_sci_handle *sci = data->sci;
+ const struct ti_sci_dev_ops *dev_ops = &sci->ops.dev_ops;
+ struct ti_sci_reset_control *control;
+ u32 reset_state;
+ int ret;
+
+ control = idr_find(&data->idr, id);
+ if (!control)
+ return -EINVAL;
+
+ ret = dev_ops->get_device_resets(sci, control->dev_id,
+ &reset_state);
+ if (ret)
+ return ret;
+
+ return reset_state & control->reset_mask;
+}
+
+static struct reset_control_ops ti_sci_reset_ops = {
+ .assert = ti_sci_reset_assert,
+ .deassert = ti_sci_reset_deassert,
+ .status = ti_sci_reset_status,
+};
+
+/**
+ * ti_sci_reset_of_xlate() - translate a set of OF arguments to a reset ID
+ * @rcdev: reset controller entity
+ * @reset_spec: OF reset argument specifier
+ *
+ * This function performs the translation of the reset argument specifier
+ * values defined in a reset consumer device node. The function allocates a
+ * reset control structure for that device reset, and will be used by the
+ * driver for performing any reset functions on that reset. An idr structure
+ * is allocated and used to map to the reset control structure. This idr
+ * is used by the driver to do reset lookups.
+ *
+ * Return: 0 for successful request, else a corresponding error value
+ */
+static int ti_sci_reset_of_xlate(struct reset_controller_dev *rcdev,
+ const struct of_phandle_args *reset_spec)
+{
+ struct ti_sci_reset_data *data = to_ti_sci_reset_data(rcdev);
+ struct ti_sci_reset_control *control;
+
+ if (WARN_ON(reset_spec->args_count != rcdev->of_reset_n_cells))
+ return -EINVAL;
+
+ control = devm_kzalloc(data->dev, sizeof(*control), GFP_KERNEL);
+ if (!control)
+ return -ENOMEM;
+
+ control->dev_id = reset_spec->args[0];
+ control->reset_mask = reset_spec->args[1];
+ mutex_init(&control->lock);
+
+ return idr_alloc(&data->idr, control, 0, 0, GFP_KERNEL);
+}
+
+static const struct of_device_id ti_sci_reset_of_match[] = {
+ { .compatible = "ti,sci-reset", },
+ { /* sentinel */ },
+};
+MODULE_DEVICE_TABLE(of, ti_sci_reset_of_match);
+
+static int ti_sci_reset_probe(struct platform_device *pdev)
+{
+ struct ti_sci_reset_data *data;
+
+ if (!pdev->dev.of_node)
+ return -ENODEV;
+
+ data = devm_kzalloc(&pdev->dev, sizeof(*data), GFP_KERNEL);
+ if (!data)
+ return -ENOMEM;
+
+ data->sci = devm_ti_sci_get_handle(&pdev->dev);
+ if (IS_ERR(data->sci))
+ return PTR_ERR(data->sci);
+
+ data->rcdev.ops = &ti_sci_reset_ops;
+ data->rcdev.owner = THIS_MODULE;
+ data->rcdev.of_node = pdev->dev.of_node;
+ data->rcdev.of_reset_n_cells = 2;
+ data->rcdev.of_xlate = ti_sci_reset_of_xlate;
+ data->dev = &pdev->dev;
+ idr_init(&data->idr);
+
+ platform_set_drvdata(pdev, data);
+
+ return reset_controller_register(&data->rcdev);
+}
+
+static int ti_sci_reset_remove(struct platform_device *pdev)
+{
+ struct ti_sci_reset_data *data = platform_get_drvdata(pdev);
+
+ reset_controller_unregister(&data->rcdev);
+
+ idr_destroy(&data->idr);
+
+ return 0;
+}
+
+static struct platform_driver ti_sci_reset_driver = {
+ .probe = ti_sci_reset_probe,
+ .remove = ti_sci_reset_remove,
+ .driver = {
+ .name = "ti-sci-reset",
+ .of_match_table = ti_sci_reset_of_match,
+ },
+};
+module_platform_driver(ti_sci_reset_driver);
+
+MODULE_AUTHOR("Andrew F. Davis <afd@ti.com>");
+MODULE_DESCRIPTION("TI System Control Interface (TI SCI) Reset driver");
+MODULE_LICENSE("GPL v2");
--
2.10.1
^ permalink raw reply related
* [PATCH v3 1/2] Documentation: dt: reset: Add TI SCI reset binding
From: Andrew F. Davis @ 2016-11-04 17:42 UTC (permalink / raw)
To: Nishanth Menon, Tero Kristo, Santosh Shilimkar, Philipp Zabel,
Rob Herring, Mark Rutland, Suman Anna
Cc: linux-arm-kernel, devicetree, linux-kernel, Andrew F . Davis
In-Reply-To: <20161104174240.9688-1-afd@ti.com>
Add TI SCI reset controller binding. This describes the DT binding
details for a reset controller node providing reset management services
to hardware blocks (reset consumers) using the Texas Instrument's System
Control Interface (TI SCI) protocol to communicate to a system controller
block present on the SoC.
Signed-off-by: Andrew F. Davis <afd@ti.com>
[s-anna@ti.com: revise the binding format]
Signed-off-by: Suman Anna <s-anna@ti.com>
Signed-off-by: Nishanth Menon <nm@ti.com>
---
.../devicetree/bindings/reset/ti,sci-reset.txt | 65 ++++++++++++++++++++++
MAINTAINERS | 2 +
include/dt-bindings/reset/k2g.h | 22 ++++++++
3 files changed, 89 insertions(+)
create mode 100644 Documentation/devicetree/bindings/reset/ti,sci-reset.txt
create mode 100644 include/dt-bindings/reset/k2g.h
diff --git a/Documentation/devicetree/bindings/reset/ti,sci-reset.txt b/Documentation/devicetree/bindings/reset/ti,sci-reset.txt
new file mode 100644
index 0000000..cb00679
--- /dev/null
+++ b/Documentation/devicetree/bindings/reset/ti,sci-reset.txt
@@ -0,0 +1,65 @@
+Texas Instruments System Control Interface (TI-SCI) Reset Controller
+=====================================================================
+
+Some TI SoCs contain a system controller (like the Power Management Micro
+Controller (PMMC) on Keystone K2G SoC) that are responsible for controlling
+the state of the various hardware modules present on the SoC. Communication
+between the host processor running an OS and the system controller happens
+through a protocol called TI System Control Interface (TI-SCI protocol).
+For TI SCI details, please refer to the document,
+Documentation/devicetree/bindings/arm/keystone/ti,sci.txt
+
+TI-SCI Reset Controller Node
+============================
+This reset controller node uses the TI SCI protocol to perform the reset
+management of various hardware modules present on the SoC.
+
+Required properties:
+--------------------
+ - compatible : Should be "ti,sci-reset"
+ - #reset-cells : Should be 2. Please see the reset consumer node below for
+ usage details.
+
+TI-SCI Reset Consumer Nodes
+===========================
+Each of the reset consumer nodes should have the following properties,
+in addition to their own properties.
+
+Required properties:
+--------------------
+ - resets : A phandle and reset specifier pair, one pair for each reset
+ signal that affects the device, or that the device manages.
+ The phandle should point to the TI-SCI reset controller node,
+ and the reset specifier should have 2 cell-values. The first
+ cell should contain the device ID, the values of which are
+ specified in the <dt-bindings/genpd/<soc>.h> include file.
+ The second cell should contain the reset mask value used by
+ system controller, the values of which are specified in the
+ include file <dt-bindings/reset/<soc>.h>, where <soc> is the
+ name of the SoC involved, for example 'k2g'.
+
+Please also refer to Documentation/devicetree/bindings/reset/reset.txt for
+common reset controller usage by consumers.
+
+Example:
+--------
+The following example demonstrates both a TI-SCI reset controller node and a
+consumer (a DSP device) on the K2G SoC.
+
+#include <dt-bindings/genpd/k2g.h>
+#include <dt-bindings/reset/k2g.h>
+
+pmmc: pmmc {
+ compatible = "ti,k2g-sci";
+
+ k2g_reset: k2g_reset {
+ compatible = "ti,sci-reset";
+ #reset-cells = <2>;
+ };
+};
+
+dsp0: dsp0 {
+ ...
+ resets = <&k2g_reset K2G_DEV_CGEM0 K2G_DEV_CGEM0_DSP0_RESET>;
+ ...
+};
diff --git a/MAINTAINERS b/MAINTAINERS
index 6e93976..accf991 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -11899,6 +11899,8 @@ F: drivers/soc/ti/ti_sci_pm_domains.c
F: Documentation/devicetree/bindings/clock/ti,sci-clk.txt
F: include/dt-bindings/clock/k2g.h
F: drivers/clk/keystone/sci-clk.c
+F: Documentation/devicetree/bindings/reset/ti,sci-reset.txt
+F: include/dt-bindings/reset/k2g.h
THANKO'S RAREMONO AM/FM/SW RADIO RECEIVER USB DRIVER
M: Hans Verkuil <hverkuil@xs4all.nl>
diff --git a/include/dt-bindings/reset/k2g.h b/include/dt-bindings/reset/k2g.h
new file mode 100644
index 0000000..00e2a9b
--- /dev/null
+++ b/include/dt-bindings/reset/k2g.h
@@ -0,0 +1,22 @@
+/*
+ * TI K2G SoC reset definitions
+ *
+ * Copyright (C) 2015-2016 Texas Instruments Incorporated - http://www.ti.com/
+ *
+ * This program 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 program 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.
+ */
+
+#ifndef __DT_BINDINGS_RESET_K2G_H__
+#define __DT_BINDINGS_RESET_K2G_H__
+
+#define K2G_DEV_CGEM0_DSP0_RESET 0x1
+
+#endif
--
2.10.1
^ permalink raw reply related
* [PATCH v3 0/2] Add TI SCI Reset Driver
From: Andrew F. Davis @ 2016-11-04 17:42 UTC (permalink / raw)
To: Nishanth Menon, Tero Kristo, Santosh Shilimkar, Philipp Zabel,
Rob Herring, Mark Rutland, Suman Anna
Cc: linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA, Andrew F . Davis
Hello all,
This series adds a reset controller driver that uses the TI SCI
protocol to manage resets.
The TI SCI protocol is used to communicate with power management
controllers used by some SoCs. These controllers manage the various
power domains, clocks, and resets available on a SoC.
This series is based on drivers for TI SCI and the first two controlled
elements above, these series can be found here:
TI-SCI: http://www.spinics.net/lists/arm-kernel/msg536851.html
PM Domains: http://www.spinics.net/lists/devicetree/msg146621.html
Clocks: https://www.spinics.net/lists/linux-clk/msg12785.html
Thanks,
Andrew
Changes from v2:
- Merged DT binding patch and reset header patch
- Added locking for reset bit mask
Changes from v1:
- Revised dt binding
- CC Linux ARM list
Andrew F. Davis (2):
Documentation: dt: reset: Add TI SCI reset binding
reset: Add the TI SCI reset driver
.../devicetree/bindings/reset/ti,sci-reset.txt | 65 +++++
MAINTAINERS | 3 +
drivers/reset/Kconfig | 9 +
drivers/reset/Makefile | 1 +
drivers/reset/reset-ti-sci.c | 272 +++++++++++++++++++++
include/dt-bindings/reset/k2g.h | 22 ++
6 files changed, 372 insertions(+)
create mode 100644 Documentation/devicetree/bindings/reset/ti,sci-reset.txt
create mode 100644 drivers/reset/reset-ti-sci.c
create mode 100644 include/dt-bindings/reset/k2g.h
--
2.10.1
--
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 2/2] regulator: pwm: Add ramp delay for exponential voltage transition
From: Laxman Dewangan @ 2016-11-04 17:37 UTC (permalink / raw)
To: broonie, robh+dt, mark.rutland
Cc: linux-kernel, devicetree, Laxman Dewangan, Douglas Anderson,
Aleksandr Frid
In-Reply-To: <1478281075-3498-1-git-send-email-ldewangan@nvidia.com>
Some PWM regulator has the exponential transition in voltage change as
opposite to fixed slew-rate linear transition on other regulators.
For such PWM regulators, voltage transition is same for all voltage
change.
Add support for handling the voltage transition ramp time when voltage
transition is exponential.
Signed-off-by: Laxman Dewangan <ldewangan@nvidia.com>
CC: Douglas Anderson <dianders@chromium.org>
CC: Aleksandr Frid <afrid@nvidia.com>
---
This patch is continuation of discussion on patch
regulator: pwm: Fix regulator ramp delay for continuous mode
https://patchwork.kernel.org/patch/9216857/
where is it discussed to have separate property for PWM which has
exponential voltage transition.
---
drivers/regulator/pwm-regulator.c | 18 ++++++++++++++++++
1 file changed, 18 insertions(+)
diff --git a/drivers/regulator/pwm-regulator.c b/drivers/regulator/pwm-regulator.c
index 1b88e0e1..f990b86 100644
--- a/drivers/regulator/pwm-regulator.c
+++ b/drivers/regulator/pwm-regulator.c
@@ -47,6 +47,9 @@ struct pwm_regulator_data {
/* Enable GPIO */
struct gpio_desc *enb_gpio;
+
+ /* Voltage ramp time */
+ u32 voltage_ramp_time;
};
struct pwm_voltages {
@@ -233,6 +236,14 @@ static int pwm_regulator_set_voltage(struct regulator_dev *rdev,
return 0;
}
+static int pwm_regulator_set_voltage_time_sel(struct regulator_dev *rdev,
+ int old_uV, int new_uV)
+{
+ struct pwm_regulator_data *drvdata = rdev_get_drvdata(rdev);
+
+ return drvdata->voltage_ramp_time;
+}
+
static struct regulator_ops pwm_regulator_voltage_table_ops = {
.set_voltage_sel = pwm_regulator_set_voltage_sel,
.get_voltage_sel = pwm_regulator_get_voltage_sel,
@@ -305,6 +316,13 @@ static int pwm_regulator_init_continuous(struct platform_device *pdev,
memcpy(&drvdata->ops, &pwm_regulator_voltage_continuous_ops,
sizeof(drvdata->ops));
+
+ if (!of_property_read_u32(pdev->dev.of_node,
+ "pwm-regulator-voltage-ramp-time-us",
+ &drvdata->voltage_ramp_time))
+ drvdata->ops.set_voltage_time =
+ pwm_regulator_set_voltage_time_sel;
+
drvdata->desc.ops = &drvdata->ops;
drvdata->desc.continuous_voltage_range = true;
--
2.1.4
^ 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