* [PATCH 1/2] dt-bindings: arm, gic: Fix binding example for a virt-capable GIC
From: Marc Zyngier @ 2017-01-18 10:53 UTC (permalink / raw)
To: linux-kernel, devicetree, linux-arm-kernel
Cc: Mark Rutland, Heiko Stuebner, Tony Lindgren, arm, Magnus Damm,
Russell King, Krzysztof Kozlowski, Javier Martinez Canillas,
Chen-Yu Tsai, Kukjin Kim, Tsahee Zidenberg, Jason Cooper,
Simon Horman, Santosh Shilimkar, Matthias Brugger,
Thomas Gleixner, Sascha Hauer, Antoine Tenart, Rob Herring,
Benoît Cousson, Fabio Estevam, Maxime Ripard, Shawn Guo
In-Reply-To: <1484736811-24002-1-git-send-email-marc.zyngier@arm.com>
The joys of copy/paste: the example of a virtualization capable GIC
in the DT binding was wrong, and propagated to dozens of platforms.
Oh well. Let's fix the source of the crap before tackling individual
offenders.
Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
---
Documentation/devicetree/bindings/interrupt-controller/arm,gic.txt | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/Documentation/devicetree/bindings/interrupt-controller/arm,gic.txt b/Documentation/devicetree/bindings/interrupt-controller/arm,gic.txt
index 5393e2a..a3d51ed 100644
--- a/Documentation/devicetree/bindings/interrupt-controller/arm,gic.txt
+++ b/Documentation/devicetree/bindings/interrupt-controller/arm,gic.txt
@@ -107,11 +107,11 @@ Required properties:
Example:
interrupt-controller@2c001000 {
- compatible = "arm,cortex-a15-gic";
+ compatible = "arm,gic-400";
#interrupt-cells = <3>;
interrupt-controller;
reg = <0x2c001000 0x1000>,
- <0x2c002000 0x1000>,
+ <0x2c002000 0x2000>,
<0x2c004000 0x2000>,
<0x2c006000 0x2000>;
interrupts = <1 9 0xf04>;
--
2.1.4
^ permalink raw reply related
* [PATCH 0/2] ARM: DTS: Fix broken GICv2 register maps
From: Marc Zyngier @ 2017-01-18 10:53 UTC (permalink / raw)
To: linux-kernel, devicetree, linux-arm-kernel
Cc: Mark Rutland, Heiko Stuebner, Tony Lindgren, arm, Magnus Damm,
Russell King, Krzysztof Kozlowski, Javier Martinez Canillas,
Chen-Yu Tsai, Kukjin Kim, Tsahee Zidenberg, Jason Cooper,
Simon Horman, Santosh Shilimkar, Matthias Brugger,
Thomas Gleixner, Sascha Hauer, Antoine Tenart, Rob Herring,
Benoît Cousson, Fabio Estevam, Maxime Ripard, Shawn Guo
For a GICv2 (which happens to be virtualization capable), the
architecture mandates the following regions:
GICD: 4kB
GICC: 8kB
GICH: 8kB
GICV: 8kB
Unfortunately, I made a mistake in one of the examples contained in
the DT binding document, and everyone duplicated that same mistake all
over the map.
This small series fixes the DT binding, and hopefully updates all the
offending DTs to be compliant with the architecture.
Marc Zyngier (2):
dt-bindings: arm,gic: Fix binding example for a virt-capable GIC
ARM: DTS: Fix register map for virt-capable GIC
Documentation/devicetree/bindings/interrupt-controller/arm,gic.txt | 4 ++--
arch/arm/boot/dts/alpine.dtsi | 2 +-
arch/arm/boot/dts/axm55xx.dtsi | 2 +-
arch/arm/boot/dts/dra7.dtsi | 2 +-
arch/arm/boot/dts/ecx-2000.dts | 2 +-
arch/arm/boot/dts/exynos3250.dtsi | 2 +-
arch/arm/boot/dts/exynos5.dtsi | 2 +-
arch/arm/boot/dts/exynos5260.dtsi | 2 +-
arch/arm/boot/dts/exynos5440.dtsi | 2 +-
arch/arm/boot/dts/imx6ul.dtsi | 4 ++--
arch/arm/boot/dts/keystone-k2g.dtsi | 2 +-
arch/arm/boot/dts/keystone.dtsi | 2 +-
arch/arm/boot/dts/ls1021a.dtsi | 4 ++--
arch/arm/boot/dts/mt2701.dtsi | 2 +-
arch/arm/boot/dts/mt6580.dtsi | 2 +-
arch/arm/boot/dts/mt6589.dtsi | 2 +-
arch/arm/boot/dts/mt7623.dtsi | 2 +-
arch/arm/boot/dts/mt8127.dtsi | 2 +-
arch/arm/boot/dts/mt8135.dtsi | 2 +-
arch/arm/boot/dts/omap5.dtsi | 2 +-
arch/arm/boot/dts/r8a73a4.dtsi | 2 +-
arch/arm/boot/dts/r8a7743.dtsi | 2 +-
arch/arm/boot/dts/r8a7745.dtsi | 2 +-
arch/arm/boot/dts/r8a7790.dtsi | 2 +-
arch/arm/boot/dts/r8a7791.dtsi | 2 +-
arch/arm/boot/dts/r8a7792.dtsi | 2 +-
arch/arm/boot/dts/r8a7793.dtsi | 2 +-
arch/arm/boot/dts/r8a7794.dtsi | 2 +-
arch/arm/boot/dts/rk1108.dtsi | 2 +-
arch/arm/boot/dts/rk3036.dtsi | 2 +-
arch/arm/boot/dts/rk322x.dtsi | 2 +-
arch/arm/boot/dts/rk3288.dtsi | 2 +-
arch/arm/boot/dts/sun6i-a31.dtsi | 2 +-
arch/arm/boot/dts/sun7i-a20.dtsi | 4 ++--
arch/arm/boot/dts/sun8i-a23-a33.dtsi | 2 +-
arch/arm/boot/dts/sun8i-a83t.dtsi | 2 +-
arch/arm/boot/dts/sun8i-h3.dtsi | 2 +-
arch/arm/boot/dts/sun9i-a80.dtsi | 2 +-
38 files changed, 42 insertions(+), 42 deletions(-)
--
2.1.4
^ permalink raw reply
* [PATCH 3/3] dt-bindings: amlogic: Add WeTek boards
From: Neil Armstrong @ 2017-01-18 10:50 UTC (permalink / raw)
To: khilman, carlo
Cc: linux-amlogic, devicetree, linux-kernel, linux-arm-kernel,
Neil Armstrong
In-Reply-To: <1484736642-5451-1-git-send-email-narmstrong@baylibre.com>
Signed-off-by: Neil Armstrong <narmstrong@baylibre.com>
---
Documentation/devicetree/bindings/arm/amlogic.txt | 2 ++
1 file changed, 2 insertions(+)
diff --git a/Documentation/devicetree/bindings/arm/amlogic.txt b/Documentation/devicetree/bindings/arm/amlogic.txt
index 9b2b41a..c246cd2 100644
--- a/Documentation/devicetree/bindings/arm/amlogic.txt
+++ b/Documentation/devicetree/bindings/arm/amlogic.txt
@@ -40,6 +40,8 @@ Board compatible values:
- "hardkernel,odroid-c2" (Meson gxbb)
- "amlogic,p200" (Meson gxbb)
- "amlogic,p201" (Meson gxbb)
+ - "wetek,hub" (Meson gxbb)
+ - "wetek,play2" (Meson gxbb)
- "amlogic,p212" (Meson gxl s905x)
- "amlogic,p230" (Meson gxl s905d)
- "amlogic,p231" (Meson gxl s905d)
--
1.9.1
^ permalink raw reply related
* [PATCH 2/3] ARM64: dts: meson-gxbb: Add support for WeTek Hub and Play
From: Neil Armstrong @ 2017-01-18 10:50 UTC (permalink / raw)
To: khilman, carlo
Cc: Neil Armstrong, linux-amlogic, linux-arm-kernel, linux-kernel,
devicetree
In-Reply-To: <1484736642-5451-1-git-send-email-narmstrong@baylibre.com>
Adds support for the WeTek Hub and Play2 boards.
The Hub is an extremely small IPTv Set-Top-Box and the Play2 is a more
traditionnal Satellite or Terrestrial and IPTv Set-Top-Box.
Both are based on the p200 Reference Design and out-of-tree support is
based on OpenELEC kernel at [1].
[1] https://github.com/wetek-enigma/linux-amlogic
Signed-off-by: Neil Armstrong <narmstrong@baylibre.com>
---
arch/arm64/boot/dts/amlogic/Makefile | 2 +
.../boot/dts/amlogic/meson-gxbb-wetek-hub.dts | 66 +++++++++++++++
.../boot/dts/amlogic/meson-gxbb-wetek-play2.dts | 94 ++++++++++++++++++++++
3 files changed, 162 insertions(+)
create mode 100644 arch/arm64/boot/dts/amlogic/meson-gxbb-wetek-hub.dts
create mode 100644 arch/arm64/boot/dts/amlogic/meson-gxbb-wetek-play2.dts
diff --git a/arch/arm64/boot/dts/amlogic/Makefile b/arch/arm64/boot/dts/amlogic/Makefile
index 0d7bfbf..cc2e2dd 100644
--- a/arch/arm64/boot/dts/amlogic/Makefile
+++ b/arch/arm64/boot/dts/amlogic/Makefile
@@ -5,6 +5,8 @@ dtb-$(CONFIG_ARCH_MESON) += meson-gxbb-p201.dtb
dtb-$(CONFIG_ARCH_MESON) += meson-gxbb-vega-s95-pro.dtb
dtb-$(CONFIG_ARCH_MESON) += meson-gxbb-vega-s95-meta.dtb
dtb-$(CONFIG_ARCH_MESON) += meson-gxbb-vega-s95-telos.dtb
+dtb-$(CONFIG_ARCH_MESON) += meson-gxbb-wetek-hub.dtb
+dtb-$(CONFIG_ARCH_MESON) += meson-gxbb-wetek-play2.dtb
dtb-$(CONFIG_ARCH_MESON) += meson-gxl-s905x-p212.dtb
dtb-$(CONFIG_ARCH_MESON) += meson-gxl-s905d-p230.dtb
dtb-$(CONFIG_ARCH_MESON) += meson-gxl-s905d-p231.dtb
diff --git a/arch/arm64/boot/dts/amlogic/meson-gxbb-wetek-hub.dts b/arch/arm64/boot/dts/amlogic/meson-gxbb-wetek-hub.dts
new file mode 100644
index 0000000..56f8559
--- /dev/null
+++ b/arch/arm64/boot/dts/amlogic/meson-gxbb-wetek-hub.dts
@@ -0,0 +1,66 @@
+/*
+ * Copyright (c) 2016 BayLibre, Inc.
+ * Author: Neil Armstrong <narmstrong@baylibre.com>
+ *
+ * This file is dual-licensed: you can use it either under the terms
+ * of the GPL or the X11 license, at your option. Note that this dual
+ * licensing only applies to this file, and not this project as a
+ * whole.
+ *
+ * a) This library is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation; either version 2 of the
+ * License, or (at your option) any later version.
+ *
+ * This library is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * Or, alternatively,
+ *
+ * b) Permission is hereby granted, free of charge, to any person
+ * obtaining a copy of this software and associated documentation
+ * files (the "Software"), to deal in the Software without
+ * restriction, including without limitation the rights to use,
+ * copy, modify, merge, publish, distribute, sublicense, and/or
+ * sell copies of the Software, and to permit persons to whom the
+ * Software is furnished to do so, subject to the following
+ * conditions:
+ *
+ * The above copyright notice and this permission notice shall be
+ * included in all copies or substantial portions of the Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
+ * EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES
+ * OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
+ * NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT
+ * HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY,
+ * WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
+ * OTHER DEALINGS IN THE SOFTWARE.
+ */
+
+/dts-v1/;
+
+#include "meson-gxbb-p20x.dtsi"
+
+/ {
+ compatible = "wetek,hub", "amlogic,meson-gxbb";
+ model = "WeTek Hub";
+
+ leds {
+ compatible = "gpio-leds";
+
+ system {
+ label = "wetek-play:system-status";
+ gpios = <&gpio_ao GPIOAO_13 GPIO_ACTIVE_HIGH>;
+ default-state = "on";
+ panic-indicator;
+ };
+ };
+
+ cvbs-connector {
+ status = "disabled";
+ };
+};
diff --git a/arch/arm64/boot/dts/amlogic/meson-gxbb-wetek-play2.dts b/arch/arm64/boot/dts/amlogic/meson-gxbb-wetek-play2.dts
new file mode 100644
index 0000000..ea79fdd
--- /dev/null
+++ b/arch/arm64/boot/dts/amlogic/meson-gxbb-wetek-play2.dts
@@ -0,0 +1,94 @@
+/*
+ * Copyright (c) 2016 BayLibre, Inc.
+ * Author: Neil Armstrong <narmstrong@baylibre.com>
+ *
+ * This file is dual-licensed: you can use it either under the terms
+ * of the GPL or the X11 license, at your option. Note that this dual
+ * licensing only applies to this file, and not this project as a
+ * whole.
+ *
+ * a) This library is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation; either version 2 of the
+ * License, or (at your option) any later version.
+ *
+ * This library is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * Or, alternatively,
+ *
+ * b) Permission is hereby granted, free of charge, to any person
+ * obtaining a copy of this software and associated documentation
+ * files (the "Software"), to deal in the Software without
+ * restriction, including without limitation the rights to use,
+ * copy, modify, merge, publish, distribute, sublicense, and/or
+ * sell copies of the Software, and to permit persons to whom the
+ * Software is furnished to do so, subject to the following
+ * conditions:
+ *
+ * The above copyright notice and this permission notice shall be
+ * included in all copies or substantial portions of the Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
+ * EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES
+ * OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
+ * NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT
+ * HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY,
+ * WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
+ * OTHER DEALINGS IN THE SOFTWARE.
+ */
+
+/dts-v1/;
+
+#include "meson-gxbb-p20x.dtsi"
+#include <dt-bindings/input/input.h>
+
+/ {
+ compatible = "wetek,play2", "amlogic,meson-gxbb";
+ model = "WeTek Play 2";
+
+ leds {
+ compatible = "gpio-leds";
+
+ system {
+ label = "wetek-play:system-status";
+ gpios = <&gpio_ao GPIOAO_13 GPIO_ACTIVE_HIGH>;
+ default-state = "on";
+ panic-indicator;
+ };
+
+ wifi {
+ label = "wetek-play:wifi-status";
+ gpios = <&gpio GPIODV_26 GPIO_ACTIVE_HIGH>;
+ default-state = "off";
+ };
+
+ ethernet {
+ label = "wetek-play:ethernet-status";
+ gpios = <&gpio GPIODV_27 GPIO_ACTIVE_HIGH>;
+ default-state = "off";
+ };
+ };
+
+ gpio-keys-polled {
+ compatible = "gpio-keys-polled";
+ #address-cells = <1>;
+ #size-cells = <0>;
+ poll-interval = <100>;
+
+ button@0 {
+ label = "reset";
+ linux,code = <KEY_RESTART>;
+ gpios = <&gpio_ao GPIOAO_3 GPIO_ACTIVE_LOW>;
+ };
+ };
+};
+
+&i2c_A {
+ status = "okay";
+ pinctrl-0 = <&i2c_a_pins>;
+ pinctrl-names = "default";
+};
--
1.9.1
^ permalink raw reply related
* [PATCH 1/3] dt-bindings: vendor-prefix: Add wetek vendor prefix
From: Neil Armstrong @ 2017-01-18 10:50 UTC (permalink / raw)
To: khilman, carlo
Cc: linux-amlogic, devicetree, linux-kernel, linux-arm-kernel,
Neil Armstrong
In-Reply-To: <1484736642-5451-1-git-send-email-narmstrong@baylibre.com>
Add prefix for WeTek Electronics, limited, a company producing multimedia
Set-Top-Boxes and supporting KODI and OpenELEC distributions.
Signed-off-by: Neil Armstrong <narmstrong@baylibre.com>
---
Documentation/devicetree/bindings/vendor-prefixes.txt | 1 +
1 file changed, 1 insertion(+)
diff --git a/Documentation/devicetree/bindings/vendor-prefixes.txt b/Documentation/devicetree/bindings/vendor-prefixes.txt
index 16d3b5e..0c16d85 100644
--- a/Documentation/devicetree/bindings/vendor-prefixes.txt
+++ b/Documentation/devicetree/bindings/vendor-prefixes.txt
@@ -320,6 +320,7 @@ virtio Virtual I/O Device Specification, developed by the OASIS consortium
vivante Vivante Corporation
voipac Voipac Technologies s.r.o.
wd Western Digital Corp.
+wetek WeTek Electronics, limited.
wexler Wexler
winbond Winbond Electronics corp.
wlf Wolfson Microelectronics
--
1.9.1
^ permalink raw reply related
* [PATCH 0/3] ARM64: meson-gxbb: Add WeTek Boards
From: Neil Armstrong @ 2017-01-18 10:50 UTC (permalink / raw)
To: khilman, carlo
Cc: linux-amlogic, devicetree, linux-kernel, linux-arm-kernel,
Neil Armstrong
This serie adds support for the WeTek Hub and Play2 boards.
The Hub is an extremely small IPTv Set-Top-Box and the Play2 is a more
traditionnal Satellite or Terrestrial and IPTv Set-Top-Box.
Both are based on the p200 Reference Design and out-of-tree support is
based on OpenELEC kernel at [1].
[1] https://github.com/wetek-enigma/linux-amlogic
Neil Armstrong (3):
dt-bindings: vendor-prefix: Add wetek vendor prefix
ARM64: dts: meson-gxbb: Add support for WeTek Hub and Play
dt-bindings: amlogic: Add WeTek boards
Documentation/devicetree/bindings/arm/amlogic.txt | 2 +
.../devicetree/bindings/vendor-prefixes.txt | 1 +
arch/arm64/boot/dts/amlogic/Makefile | 2 +
.../boot/dts/amlogic/meson-gxbb-wetek-hub.dts | 66 +++++++++++++++
.../boot/dts/amlogic/meson-gxbb-wetek-play2.dts | 94 ++++++++++++++++++++++
5 files changed, 165 insertions(+)
create mode 100644 arch/arm64/boot/dts/amlogic/meson-gxbb-wetek-hub.dts
create mode 100644 arch/arm64/boot/dts/amlogic/meson-gxbb-wetek-play2.dts
--
1.9.1
^ permalink raw reply
* [PATCH] regulator: qcom-smd: Add PM8994 regulator support
From: Bjorn Andersson @ 2017-01-18 10:46 UTC (permalink / raw)
To: Liam Girdwood, Mark Brown, Rob Herring, Mark Rutland
Cc: linux-kernel, devicetree, linux-arm-msm, Jeremy McNicoll
From: Rajendra Nayak <rnayak@codeaurora.org>
This patch adds support for the PM8994 regulators found on msm8992,
msm8994 and msm8996 platforms.
Signed-off-by: Rajendra Nayak <rnayak@codeaurora.org>
[bjorn: Add DT binding doc and vdd_lvs1_2 supply]
Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
---
.../bindings/regulator/qcom,smd-rpm-regulator.txt | 56 +++++++++++
drivers/regulator/qcom_smd-regulator.c | 102 +++++++++++++++++++++
2 files changed, 158 insertions(+)
diff --git a/Documentation/devicetree/bindings/regulator/qcom,smd-rpm-regulator.txt b/Documentation/devicetree/bindings/regulator/qcom,smd-rpm-regulator.txt
index 1f8d6f84b657..4e3dfb5b5f16 100644
--- a/Documentation/devicetree/bindings/regulator/qcom,smd-rpm-regulator.txt
+++ b/Documentation/devicetree/bindings/regulator/qcom,smd-rpm-regulator.txt
@@ -22,6 +22,7 @@ Regulator nodes are identified by their compatible:
"qcom,rpm-pm8841-regulators"
"qcom,rpm-pm8916-regulators"
"qcom,rpm-pm8941-regulators"
+ "qcom,rpm-pm8994-regulators"
"qcom,rpm-pma8084-regulators"
- vdd_s1-supply:
@@ -80,6 +81,56 @@ Regulator nodes are identified by their compatible:
- vdd_s10-supply:
- vdd_s11-supply:
- vdd_s12-supply:
+- vdd_l1-supply:
+- vdd_l2_l26_l28-supply:
+- vdd_l3_l11-supply:
+- vdd_l4_l27_l31-supply:
+- vdd_l5_l7-supply:
+- vdd_l6_l12_l32-supply:
+- vdd_l5_l7-supply:
+- vdd_l8_l16_l30-supply:
+- vdd_l9_l10_l18_l22-supply:
+- vdd_l9_l10_l18_l22-supply:
+- vdd_l3_l11-supply:
+- vdd_l6_l12_l32-supply:
+- vdd_l13_l19_l23_l24-supply:
+- vdd_l14_l15-supply:
+- vdd_l14_l15-supply:
+- vdd_l8_l16_l30-supply:
+- vdd_l17_l29-supply:
+- vdd_l9_l10_l18_l22-supply:
+- vdd_l13_l19_l23_l24-supply:
+- vdd_l20_l21-supply:
+- vdd_l20_l21-supply:
+- vdd_l9_l10_l18_l22-supply:
+- vdd_l13_l19_l23_l24-supply:
+- vdd_l13_l19_l23_l24-supply:
+- vdd_l25-supply:
+- vdd_l2_l26_l28-supply:
+- vdd_l4_l27_l31-supply:
+- vdd_l2_l26_l28-supply:
+- vdd_l17_l29-supply:
+- vdd_l8_l16_l30-supply:
+- vdd_l4_l27_l31-supply:
+- vdd_l6_l12_l32-supply:
+- vdd_lvs1_2-supply:
+ Usage: optional (pm8994 only)
+ Value type: <phandle>
+ Definition: reference to regulator supplying the input pin, as
+ described in the data sheet
+
+- vdd_s1-supply:
+- vdd_s2-supply:
+- vdd_s3-supply:
+- vdd_s4-supply:
+- vdd_s5-supply:
+- vdd_s6-supply:
+- vdd_s7-supply:
+- vdd_s8-supply:
+- vdd_s9-supply:
+- vdd_s10-supply:
+- vdd_s11-supply:
+- vdd_s12-supply:
- vdd_l1_l11-supply:
- vdd_l2_l3_l4_l27-supply:
- vdd_l5_l7-supply:
@@ -113,6 +164,11 @@ pm8941:
l14, l15, l16, l17, l18, l19, l20, l21, l22, l23, l24, lvs1, lvs2,
lvs3, 5vs1, 5vs2
+pm8994:
+ s1, s2, s3, s4, s5, s6, s7, s8, s9, s10, s11, s12, l1, l2, l3, l4, l5,
+ l6, l7, l8, l9, l10, l11, l12, l13, l14, l15, l16, l17, l18, l19, l20,
+ l21, l22, l23, l24, l25, l26, l27, l28, l29, l30, l31, l32, lvs1, lvs2
+
pma8084:
s1, s2, s3, s4, s5, s6, s7, s8, s9, s10, s11, s12, l1, l2, l3, l4, l5,
l6, l7, l8, l9, l10, l11, l12, l13, l14, l15, l16, l17, l18, l19, l20,
diff --git a/drivers/regulator/qcom_smd-regulator.c b/drivers/regulator/qcom_smd-regulator.c
index 8ed46a9a55c8..f35994a2a5be 100644
--- a/drivers/regulator/qcom_smd-regulator.c
+++ b/drivers/regulator/qcom_smd-regulator.c
@@ -305,6 +305,56 @@ static const struct regulator_desc pm8916_buck_hvo_smps = {
.ops = &rpm_smps_ldo_ops,
};
+static const struct regulator_desc pm8994_hfsmps = {
+ .linear_ranges = (struct regulator_linear_range[]) {
+ REGULATOR_LINEAR_RANGE( 375000, 0, 95, 12500),
+ REGULATOR_LINEAR_RANGE(1550000, 96, 158, 25000),
+ },
+ .n_linear_ranges = 2,
+ .n_voltages = 159,
+ .ops = &rpm_smps_ldo_ops,
+};
+
+static const struct regulator_desc pm8994_ftsmps = {
+ .linear_ranges = (struct regulator_linear_range[]) {
+ REGULATOR_LINEAR_RANGE(350000, 0, 199, 5000),
+ REGULATOR_LINEAR_RANGE(700000, 200, 349, 10000),
+ },
+ .n_linear_ranges = 2,
+ .n_voltages = 350,
+ .ops = &rpm_smps_ldo_ops,
+};
+
+static const struct regulator_desc pm8994_nldo = {
+ .linear_ranges = (struct regulator_linear_range[]) {
+ REGULATOR_LINEAR_RANGE(750000, 0, 63, 12500),
+ },
+ .n_linear_ranges = 1,
+ .n_voltages = 64,
+ .ops = &rpm_smps_ldo_ops,
+};
+
+static const struct regulator_desc pm8994_pldo = {
+ .linear_ranges = (struct regulator_linear_range[]) {
+ REGULATOR_LINEAR_RANGE( 750000, 0, 63, 12500),
+ REGULATOR_LINEAR_RANGE(1550000, 64, 126, 25000),
+ REGULATOR_LINEAR_RANGE(3100000, 127, 163, 50000),
+ },
+ .n_linear_ranges = 3,
+ .n_voltages = 164,
+ .ops = &rpm_smps_ldo_ops,
+};
+
+static const struct regulator_desc pm8994_switch = {
+ .ops = &rpm_switch_ops,
+};
+
+static const struct regulator_desc pm8994_lnldo = {
+ .fixed_uV = 1740000,
+ .n_voltages = 1,
+ .ops = &rpm_smps_ldo_ops_fixed,
+};
+
struct rpm_regulator_data {
const char *name;
u32 type;
@@ -443,10 +493,62 @@ static const struct rpm_regulator_data rpm_pma8084_regulators[] = {
{}
};
+static const struct rpm_regulator_data rpm_pm8994_regulators[] = {
+ { "s1", QCOM_SMD_RPM_SMPA, 1, &pm8994_ftsmps, "vdd_s1" },
+ { "s2", QCOM_SMD_RPM_SMPA, 2, &pm8994_ftsmps, "vdd_s2" },
+ { "s3", QCOM_SMD_RPM_SMPA, 3, &pm8994_hfsmps, "vdd_s3" },
+ { "s4", QCOM_SMD_RPM_SMPA, 4, &pm8994_hfsmps, "vdd_s4" },
+ { "s5", QCOM_SMD_RPM_SMPA, 5, &pm8994_hfsmps, "vdd_s5" },
+ { "s6", QCOM_SMD_RPM_SMPA, 6, &pm8994_ftsmps, "vdd_s6" },
+ { "s7", QCOM_SMD_RPM_SMPA, 7, &pm8994_hfsmps, "vdd_s7" },
+ { "s8", QCOM_SMD_RPM_SMPA, 8, &pm8994_ftsmps, "vdd_s8" },
+ { "s9", QCOM_SMD_RPM_SMPA, 9, &pm8994_ftsmps, "vdd_s9" },
+ { "s10", QCOM_SMD_RPM_SMPA, 10, &pm8994_ftsmps, "vdd_s10" },
+ { "s11", QCOM_SMD_RPM_SMPA, 11, &pm8994_ftsmps, "vdd_s11" },
+ { "s12", QCOM_SMD_RPM_SMPA, 12, &pm8994_ftsmps, "vdd_s12" },
+ { "l1", QCOM_SMD_RPM_LDOA, 1, &pm8994_nldo, "vdd_l1" },
+ { "l2", QCOM_SMD_RPM_LDOA, 2, &pm8994_nldo, "vdd_l2_l26_l28" },
+ { "l3", QCOM_SMD_RPM_LDOA, 3, &pm8994_nldo, "vdd_l3_l11" },
+ { "l4", QCOM_SMD_RPM_LDOA, 4, &pm8994_nldo, "vdd_l4_l27_l31" },
+ { "l5", QCOM_SMD_RPM_LDOA, 5, &pm8994_lnldo, "vdd_l5_l7" },
+ { "l6", QCOM_SMD_RPM_LDOA, 6, &pm8994_pldo, "vdd_l6_l12_l32" },
+ { "l7", QCOM_SMD_RPM_LDOA, 7, &pm8994_lnldo, "vdd_l5_l7" },
+ { "l8", QCOM_SMD_RPM_LDOA, 8, &pm8994_pldo, "vdd_l8_l16_l30" },
+ { "l9", QCOM_SMD_RPM_LDOA, 9, &pm8994_pldo, "vdd_l9_l10_l18_l22" },
+ { "l10", QCOM_SMD_RPM_LDOA, 10, &pm8994_pldo, "vdd_l9_l10_l18_l22" },
+ { "l11", QCOM_SMD_RPM_LDOA, 11, &pm8994_nldo, "vdd_l3_l11" },
+ { "l12", QCOM_SMD_RPM_LDOA, 12, &pm8994_pldo, "vdd_l6_l12_l32" },
+ { "l13", QCOM_SMD_RPM_LDOA, 13, &pm8994_pldo, "vdd_l13_l19_l23_l24" },
+ { "l14", QCOM_SMD_RPM_LDOA, 14, &pm8994_pldo, "vdd_l14_l15" },
+ { "l15", QCOM_SMD_RPM_LDOA, 15, &pm8994_pldo, "vdd_l14_l15" },
+ { "l16", QCOM_SMD_RPM_LDOA, 16, &pm8994_pldo, "vdd_l8_l16_l30" },
+ { "l17", QCOM_SMD_RPM_LDOA, 17, &pm8994_pldo, "vdd_l17_l29" },
+ { "l18", QCOM_SMD_RPM_LDOA, 18, &pm8994_pldo, "vdd_l9_l10_l18_l22" },
+ { "l19", QCOM_SMD_RPM_LDOA, 19, &pm8994_pldo, "vdd_l13_l19_l23_l24" },
+ { "l20", QCOM_SMD_RPM_LDOA, 20, &pm8994_pldo, "vdd_l20_l21" },
+ { "l21", QCOM_SMD_RPM_LDOA, 21, &pm8994_pldo, "vdd_l20_l21" },
+ { "l22", QCOM_SMD_RPM_LDOA, 22, &pm8994_pldo, "vdd_l9_l10_l18_l22" },
+ { "l23", QCOM_SMD_RPM_LDOA, 23, &pm8994_pldo, "vdd_l13_l19_l23_l24" },
+ { "l24", QCOM_SMD_RPM_LDOA, 24, &pm8994_pldo, "vdd_l13_l19_l23_l24" },
+ { "l25", QCOM_SMD_RPM_LDOA, 25, &pm8994_pldo, "vdd_l25" },
+ { "l26", QCOM_SMD_RPM_LDOA, 26, &pm8994_nldo, "vdd_l2_l26_l28" },
+ { "l27", QCOM_SMD_RPM_LDOA, 27, &pm8994_nldo, "vdd_l4_l27_l31" },
+ { "l28", QCOM_SMD_RPM_LDOA, 28, &pm8994_nldo, "vdd_l2_l26_l28" },
+ { "l29", QCOM_SMD_RPM_LDOA, 29, &pm8994_pldo, "vdd_l17_l29" },
+ { "l30", QCOM_SMD_RPM_LDOA, 30, &pm8994_pldo, "vdd_l8_l16_l30" },
+ { "l31", QCOM_SMD_RPM_LDOA, 31, &pm8994_nldo, "vdd_l4_l27_l31" },
+ { "l32", QCOM_SMD_RPM_LDOA, 32, &pm8994_pldo, "vdd_l6_l12_l32" },
+ { "lvs1", QCOM_SMD_RPM_VSA, 1, &pm8994_switch, "vdd_lvs1_2" },
+ { "lvs2", QCOM_SMD_RPM_VSA, 2, &pm8994_switch, "vdd_lvs1_2" },
+
+ {}
+};
+
static const struct of_device_id rpm_of_match[] = {
{ .compatible = "qcom,rpm-pm8841-regulators", .data = &rpm_pm8841_regulators },
{ .compatible = "qcom,rpm-pm8916-regulators", .data = &rpm_pm8916_regulators },
{ .compatible = "qcom,rpm-pm8941-regulators", .data = &rpm_pm8941_regulators },
+ { .compatible = "qcom,rpm-pm8994-regulators", .data = &rpm_pm8994_regulators },
{ .compatible = "qcom,rpm-pma8084-regulators", .data = &rpm_pma8084_regulators },
{}
};
--
2.11.0
^ permalink raw reply related
* Re: [PATCH v2 1/3] dt/bindings: da8xx-usb: Add binding for the CPPI 4.1 DMA controller
From: Sergei Shtylyov @ 2017-01-18 10:37 UTC (permalink / raw)
To: Sekhar Nori, Alexandre Bailon, vinod.koul-ral2JQCrhuEAvxtiuMwx3w,
robh+dt-DgEjT+Ai2ygdnm+yROfE0A
Cc: dmaengine-u79uwXL29TY76Z2rM5mHXA, khilman-rdvid1DuHRBWk0Htik3J/w,
ptitiano-rdvid1DuHRBWk0Htik3J/w, tony-4v6yS6AI5VpBDgjK7y7TUQ,
linux-omap-u79uwXL29TY76Z2rM5mHXA, b-liu-l0cyMroinI0,
devicetree-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <69908f47-1920-b3f8-a307-2c9cb93c2c26-l0cyMroinI0@public.gmane.org>
On 1/18/2017 1:21 PM, Sekhar Nori wrote:
>>>>> DT binding for the TI DA8xx/OMAP-L1x/AM17xx/AM18xx cppi41 dma
>>>>> controller.
>>>>>
>>>>> Signed-off-by: Alexandre Bailon <abailon-rdvid1DuHRBWk0Htik3J/w@public.gmane.org>
>>>>> ---
>>>>> .../devicetree/bindings/usb/da8xx-usb.txt | 42
>>>>> ++++++++++++++++++++++
>>>>> 1 file changed, 42 insertions(+)
>>>>>
>>>>> diff --git a/Documentation/devicetree/bindings/usb/da8xx-usb.txt
>>>>> b/Documentation/devicetree/bindings/usb/da8xx-usb.txt
>>>>> index ccb844a..aed3169 100644
>>>>> --- a/Documentation/devicetree/bindings/usb/da8xx-usb.txt
>>>>> +++ b/Documentation/devicetree/bindings/usb/da8xx-usb.txt
>>>>> @@ -18,10 +18,26 @@ Required properties:
>>>>>
>>>>> - phy-names: Should be "usb-phy"
>>>>>
>>>>> + - dmas: specifies the dma channels
>>>>> +
>>>>> + - dma-names: specifies the names of the channels. Use "rxN" for
>>>>> receive
>>>>> + and "txN" for transmit endpoints. N specifies the endpoint number.
>>>>> +
>>>>> Optional properties:
>>>>> ~~~~~~~~~~~~~~~~~~~~
>>>>> - vbus-supply: Phandle to a regulator providing the USB bus power.
>>>>>
>>>>> +DMA
>>>>> +~~~
>>>>> +- compatible: ti,da8xx-cppi41
>>>>
>>>> Almost missed this -- wildcards in this property are forbidden.
>>>> We should use "ti,da830-cppi41" as a least common denominator.
>>>
>>> Documentation/devicetree/bindings/submitting-patches.txt states:
>>>
>>> "
>>> 5) The wildcard "<chip>" may be used in compatible strings, as in
>>> the following example:
>>>
>>> - compatible: Must contain '"nvidia,<chip>-pcie",
>>> "nvidia,tegra20-pcie"' where <chip> is tegra30, tegra132, ...
>>> "
>>>
>>> I take this to mean that using wildcards to denote an SoC family on
>>> which the same IP is present is okay to do.> With that understanding, I
>>> think using ti,da8xx-cppi41 is fine too.
>>
>> It doesn't really follow. I repeat, x's are not allowed.
>
> Can you clarify here? If x's are indeed not allowed,
I have no idea where you got that they are allowed.
> then I think the
> document is being ambiguous about what constitutes "The wildcard "<chip>""
There 's no ambiguity because the wildcard is the word "<chip>" itself,
not anything other. Even if "<chip>" is used in the bindings, its possible
values should be documented anyway.
> Thanks,
> Sekhar
MBR, Sergei
--
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 3/4] pinctrl: samsung: Remove support for Exynos4415 (SoC not supported anymore)
From: Linus Walleij @ 2017-01-18 10:37 UTC (permalink / raw)
To: Krzysztof Kozlowski
Cc: Mark Rutland, devicetree@vger.kernel.org, linux-samsung-soc,
Javier Martinez Canillas, Seung-Woo Kim, Michael Turquette,
Stephen Boyd, Tomasz Figa, open list:DRM PANEL DRIVERS,
linux-kernel@vger.kernel.org, Chanwoo Choi, Kyungmin Park,
Rob Herring, Kukjin Kim, Sylwester Nawrocki,
linux-gpio@vger.kernel.org, linux-clk,
linux-arm-kernel@lists.infradead.org
In-Reply-To: <20170114123642.15581-4-krzk@kernel.org>
On Sat, Jan 14, 2017 at 1:36 PM, Krzysztof Kozlowski <krzk@kernel.org> wrote:
> Support for Exynos4415 is going away because there are no internal nor
> external users.
>
> Since commit 46dcf0ff0de3 ("ARM: dts: exynos: Remove exynos4415.dtsi"),
> the platform cannot be instantiated so remove also the drivers.
>
> Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org>
It can certainly be instantiated (from old DTBs...) but has
no DTS upstream. But I get what you mean.
Patch applied, if someone is unhappy they can always start
sending reverts.
Yours,
Linus Walleij
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply
* Re: [PATCH 3/5] ARM64: dts: meson-gxbb-p20x: add reset for the ethernet PHY
From: Jerome Brunet @ 2017-01-18 10:36 UTC (permalink / raw)
To: Martin Blumenstingl
Cc: linux-amlogic-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
khilman-rdvid1DuHRBWk0Htik3J/w, carlo-KA+7E9HrN00dnm+yROfE0A,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
devicetree-u79uwXL29TY76Z2rM5mHXA, will.deacon-5wv7dgnIgG8,
catalin.marinas-5wv7dgnIgG8, mark.rutland-5wv7dgnIgG8,
robh+dt-DgEjT+Ai2ygdnm+yROfE0A
In-Reply-To: <CAFBinCBfJ4b1a1Bqn7kJHyj79i8UJnjJh00u3NvARzJPuUmrNA-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
On Tue, 2017-01-17 at 22:26 +0100, Martin Blumenstingl wrote:
> On Tue, Jan 17, 2017 at 8:22 PM, Jerome Brunet <jbrunet-rdvid1DuHRBWk0Htik3J/w@public.gmane.org>
> wrote:
> >
> > On Sat, 2016-12-03 at 00:47 +0100, Martin Blumenstingl wrote:
> > >
> > > This resets the ethernet PHY during boot to get the PHY into a
> > > "clean"
> > > state. While here also specify the phy-handle of the ethmac node
> > > to
> > > make the PHY configuration similar to the one we have on GXL
> > > devices.
> > >
> > > Signed-off-by: Martin Blumenstingl <martin.blumenstingl@googlemai
> > > l.co
> > > m>
> > > Tested-by: Neil Armstrong <narmstrong-rdvid1DuHRBWk0Htik3J/w@public.gmane.org>
> > > ---
> > > arch/arm64/boot/dts/amlogic/meson-gxbb-p20x.dtsi | 15
> > > +++++++++++++++
> > > 1 file changed, 15 insertions(+)
> > >
> > > diff --git a/arch/arm64/boot/dts/amlogic/meson-gxbb-p20x.dtsi
> > > b/arch/arm64/boot/dts/amlogic/meson-gxbb-p20x.dtsi
> > > index 203be28..2abc553 100644
> > > --- a/arch/arm64/boot/dts/amlogic/meson-gxbb-p20x.dtsi
> > > +++ b/arch/arm64/boot/dts/amlogic/meson-gxbb-p20x.dtsi
> > > @@ -134,10 +134,25 @@
> > > pinctrl-names = "default";
> > > };
> > >
> > > +&mdio0 {
> > > + ethernet_phy0: ethernet-phy@0 {
> > > + compatible = "ethernet-phy-ieee802.3-c22";
> > > + reg = <0>;
> >
> > Sorry for the late reply.
> > I just tried on the p200 and this patch (serie) breaks the network
> > on
> > it. The PHY is not detected anymore.
> >
> > From the KSZ9031 Datasheet : "PHY Address 0h is supported as the
> > unique
> > PHY address only; it is not supported as the broadcast PHY address
> > [...]"
> >
> > So we can't just use the broadcast address here:
> > reg should be <3>.
> OK, I'll fix that in a follow-up. as mentioned in the other thread:
> can you confirm that the PHY ID is 0x00221620?
That's right.
> It seems that I also broke meson-gxbb-nexbox-a95x.dts with that
> series
> (no idea why that slipped through): according to the photos from
> Neil's wiki [0] this seems to use an IC+ 10/100 ethernet PHY
> (probably
> an IP101A)
IP101GR from what I can see on the board.
>
> >
> > >
> > > + };
> > > +};
> > > +
> > > ðmac {
> > > status = "okay";
> > > pinctrl-0 = <ð_rgmii_pins>;
> > > pinctrl-names = "default";
> > > +
> > > + phy-handle = <ðernet_phy0>;
> > > +
> > > + snps,reset-gpio = <&gpio GPIOZ_14 0>;
> > > + snps,reset-delays-us = <0 10000 1000000>;
> > > + snps,reset-active-low;
> > > +
> > > + phy-mode = "rgmii";
> >
> > We can't define this in p20x. actually the p201 uses an rmii.
> > I have not idea about gpio reset, or the phy address for the p201.
> >
> > I suppose it would be better to move this to meson-gxbb_p200.dts
> >
> > I don't know if anybody has a p201, but until we can confirm a
> > working
> > Ethernet configuration, we should probably drop it for the p201
> >
> > Of course the problem was already there before this patch ...
> indeed, that seems to be a problem.
> the GXBB Nexbox A95x I mentioned above is based on the p201 board.
> Amlogic's .dts also toggles GPIOZ_14 for it: [1]
> chances are high that it also features an IP101A PHY (this is pure
> speculation though).
Agreed, chances are high it'll be this way.
>
> I propose four patches to fix all this situation:
> - add the GPIOZ_14 reset and an ethernet_phy0 (with reg = <0>) to
> meson-gxbb-nexbox-a95x.dts
> - add the ethernet_phy0 node with reg = <0> (and ideally I also want
> to include the KSZ9031 PHY ID) to meson-gxbb-p200.dtsi along with
> phy-mode = "rgmii"
you mean with reg = <3> ?
> - add the ethernet_phy0 node with reg = <0> (without any PHY ID as we
> don't know which one is used) to meson-gxbb-p201.dtsi along with
> phy-mode = "rgmii"
> - remove "phy-mode" and ethernet_phy0 from meson-gxbb-p20x.dtsi and
> add a comment that both, the RGMII and the RMII PHY have GPIOZ_14
> connected to their reset line
I'm not too sure about these last 2 points. As you mentioned, we are
only speculating regarding the p201. I would prefer to avoid putting
things we are not sure about in the DT (as much as possible).
We could disable the ethernet for p201:
1) if nobody complains, situation remains unchanged, ethernet is not
working on that board
2) if someone complains, then we will be able to some facts from
him/her, and get it working properly.
After all, that's not a regression. With what we had in the meson-gxbb-
p20x.dtsi so far, ethernet never worked on that board.
>
> does that make sense?
>
>
> Regards,
> Martin
>
>
> [0] https://github.com/superna9999/linux/wiki/Boards#nexbox-a95x-s905
> [1] https://github.com/khadas/linux/blob/Vim/arch/arm64/boot/dts/amlo
> gic/gxbb_p201.dts#L186
--
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 2/2] ARM64: dts: meson-gx: add the missing uart_AO_B
From: Linus Walleij @ 2017-01-18 10:22 UTC (permalink / raw)
To: Martin Blumenstingl
Cc: Mark Rutland, devicetree@vger.kernel.org, Kevin Hilman,
Will Deacon, linux-gpio@vger.kernel.org, Rob Herring,
Catalin Marinas, Carlo Caione, open list:ARM/Amlogic Meson...,
linux-arm-kernel@lists.infradead.org
In-Reply-To: <20170115222029.8271-3-martin.blumenstingl@googlemail.com>
On Sun, Jan 15, 2017 at 11:20 PM, Martin Blumenstingl
<martin.blumenstingl@googlemail.com> wrote:
> This adds the missing node for the uart_AO_B port to the meson-gx.dtsi
> (as this is supported by GXBB, GXL and GXM) along with the required
> pinctrl pins. This is required as some boards are using it (the boards
> from the Khadas VIM series for example have it exposed on the pin
> headers).
>
> Signed-off-by: Martin Blumenstingl <martin.blumenstingl@googlemail.com>
Acked-by: Linus Walleij <linus.walleij@linaro.org>
Please funnel this through the apropriate ARM SoC-feed tree.
Yours,
Linus Walleij
^ permalink raw reply
* Re: [PATCH 1/2] pinctrl: meson: fix uart_ao_b for GXBB and GXL/GXM
From: Linus Walleij @ 2017-01-18 10:21 UTC (permalink / raw)
To: Martin Blumenstingl
Cc: open list:ARM/Amlogic Meson...,
linux-gpio-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, Kevin Hilman,
devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org,
Carlo Caione, Will Deacon, Catalin Marinas, Mark Rutland,
Rob Herring
In-Reply-To: <20170115222029.8271-2-martin.blumenstingl-gM/Ye1E23mwN+BqQ9rBEUg@public.gmane.org>
On Sun, Jan 15, 2017 at 11:20 PM, Martin Blumenstingl
<martin.blumenstingl-gM/Ye1E23mwN+BqQ9rBEUg@public.gmane.org> wrote:
> The GXBB and GXL/GXM pinctrl drivers had a configuration which conflicts
> with uart_ao_a. According to the GXBB ("S905") datasheet the AO UART
> functions are:
> - GPIOAO_0: Func1 = UART_TX_AO_A (bit 12), Func2 = UART_TX_AO_B (bit 26)
> - GPIOAO_1: Func1 = UART_RX_AO_A (bit 11), Func2 = UART_RX_AO_B (bit 25)
> - GPIOAO_4: Func2 = UART_TX_AO_B (bit 24)
> - GPIOAO_5: Func2 = UART_RX_AO_B (bit 25)
>
> The existing definition for uart_AO_A already uses GPIOAO_0 and GPIOAO_1.
> The old definition of uart_AO_B however was broken, as it used GPIOAO_0
> for TX (which would be fine) and two pins (GPIOAO_1 and GPIOAO_5) for RX
> (which does not make any sense).
>
> This fixes the uart_AO_B configuration by moving it to GPIOAO_4 and
> GPIOAO_5 (it would be possible to use GPIOAO_0 and GPIOAO_1 in theory,
> but all existing hardware uses uart_AO_A there).
> The fix for GXBB and GXL/GXM is identical since it seems that these
> specific pins are identical on both SoC variants.
>
> Signed-off-by: Martin Blumenstingl <martin.blumenstingl-gM/Ye1E23mwN+BqQ9rBEUg@public.gmane.org>
Patch applied for fixes.
Yours,
Linus Walleij
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH v2 1/3] dt/bindings: da8xx-usb: Add binding for the CPPI 4.1 DMA controller
From: Sekhar Nori @ 2017-01-18 10:21 UTC (permalink / raw)
To: Sergei Shtylyov, Alexandre Bailon,
vinod.koul-ral2JQCrhuEAvxtiuMwx3w, robh+dt-DgEjT+Ai2ygdnm+yROfE0A
Cc: dmaengine-u79uwXL29TY76Z2rM5mHXA, khilman-rdvid1DuHRBWk0Htik3J/w,
ptitiano-rdvid1DuHRBWk0Htik3J/w, tony-4v6yS6AI5VpBDgjK7y7TUQ,
linux-omap-u79uwXL29TY76Z2rM5mHXA, b-liu-l0cyMroinI0,
devicetree-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <d544f4f2-9303-8d68-0350-af9c53ff19aa-M4DtvfQ/ZS1MRgGoP+s0PdBPR1lH4CV8@public.gmane.org>
Hi Rob,
On Wednesday 18 January 2017 03:00 PM, Sergei Shtylyov wrote:
> Hello!
>
> On 1/18/2017 11:33 AM, Sekhar Nori wrote:
>
>>>> DT binding for the TI DA8xx/OMAP-L1x/AM17xx/AM18xx cppi41 dma
>>>> controller.
>>>>
>>>> Signed-off-by: Alexandre Bailon <abailon-rdvid1DuHRBWk0Htik3J/w@public.gmane.org>
>>>> ---
>>>> .../devicetree/bindings/usb/da8xx-usb.txt | 42
>>>> ++++++++++++++++++++++
>>>> 1 file changed, 42 insertions(+)
>>>>
>>>> diff --git a/Documentation/devicetree/bindings/usb/da8xx-usb.txt
>>>> b/Documentation/devicetree/bindings/usb/da8xx-usb.txt
>>>> index ccb844a..aed3169 100644
>>>> --- a/Documentation/devicetree/bindings/usb/da8xx-usb.txt
>>>> +++ b/Documentation/devicetree/bindings/usb/da8xx-usb.txt
>>>> @@ -18,10 +18,26 @@ Required properties:
>>>>
>>>> - phy-names: Should be "usb-phy"
>>>>
>>>> + - dmas: specifies the dma channels
>>>> +
>>>> + - dma-names: specifies the names of the channels. Use "rxN" for
>>>> receive
>>>> + and "txN" for transmit endpoints. N specifies the endpoint number.
>>>> +
>>>> Optional properties:
>>>> ~~~~~~~~~~~~~~~~~~~~
>>>> - vbus-supply: Phandle to a regulator providing the USB bus power.
>>>>
>>>> +DMA
>>>> +~~~
>>>> +- compatible: ti,da8xx-cppi41
>>>
>>> Almost missed this -- wildcards in this property are forbidden.
>>> We should use "ti,da830-cppi41" as a least common denominator.
>>
>> Documentation/devicetree/bindings/submitting-patches.txt states:
>>
>> "
>> 5) The wildcard "<chip>" may be used in compatible strings, as in
>> the following example:
>>
>> - compatible: Must contain '"nvidia,<chip>-pcie",
>> "nvidia,tegra20-pcie"' where <chip> is tegra30, tegra132, ...
>> "
>>
>> I take this to mean that using wildcards to denote an SoC family on
>> which the same IP is present is okay to do.> With that understanding, I
>> think using ti,da8xx-cppi41 is fine too.
>
> It doesn't really follow. I repeat, x's are not allowed.
Can you clarify here? If x's are indeed not allowed, then I think the
document is being ambiguous about what constitutes "The wildcard "<chip>""
Thanks,
Sekhar
--
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 02/13] pinctrl-jz4740: add a pinctrl driver for the Ingenic jz4740 SoC
From: Linus Walleij @ 2017-01-18 10:16 UTC (permalink / raw)
To: Paul Cercueil
Cc: Rob Herring, Mark Rutland, Ralf Baechle, Ulf Hansson,
Boris Brezillon, Thierry Reding, Bartlomiej Zolnierkiewicz,
Maarten ter Huurne, Lars-Peter Clausen, Paul Burton,
linux-gpio@vger.kernel.org, devicetree@vger.kernel.org,
linux-kernel@vger.kernel.org, Linux MIPS,
linux-mmc@vger.kernel.org, linux-mtd@lists.infradead.org, linux-p
In-Reply-To: <20170117231421.16310-3-paul@crapouillou.net>
n Wed, Jan 18, 2017 at 12:14 AM, Paul Cercueil <paul@crapouillou.net> wrote:
> From: Paul Burton <paul.burton@imgtec.com>
>
> This driver handles pin configuration, pin muxing, and GPIOs of the
> jz4740 SoC from Ingenic.
>
> It is separated into two files:
> - pinctrl-ingenic.c, which contains the core functions that can be
> shared across all Ingenic SoCs,
> - pinctrl-jz4740.c, which contains the jz4740-pinctrl driver.
>
> The reason behind separating some functions out of the jz4740-pinctrl
> driver, is that the pin/GPIO controllers of the Ingenic SoCs are
> extremely similar across SoC versions, except that some have the
> registers shuffled around. Making a distinct separation will permit the
> reuse of large parts of the driver to support the other SoCs from
> Ingenic.
>
> Signed-off-by: Paul Cercueil <paul@crapouillou.net>
> diff --git a/drivers/pinctrl/ingenic/Kconfig b/drivers/pinctrl/ingenic/Kconfig
> new file mode 100644
> index 000000000000..9923ce127183
> --- /dev/null
> +++ b/drivers/pinctrl/ingenic/Kconfig
> @@ -0,0 +1,14 @@
> +#
> +# Ingenic SoCs pin control drivers
> +#
> +config PINCTRL_INGENIC
> + bool
> + select PINMUX
> + select GPIOLIB_IRQCHIP
> + select GENERIC_PINCONF
I like it already when it looks like that :D
> +#include <linux/compiler.h>
> +#include <linux/gpio.h>
For drivers, just
#include <linux/gpio/driver.h>
> +struct ingenic_gpio_chip {
> + char name[3];
> + unsigned int idx;
> + void __iomem *base;
> + struct gpio_chip gc;
> + struct irq_chip irq_chip;
> + struct ingenic_pinctrl *pinctrl;
> + const struct ingenic_pinctrl_ops *ops;
> + uint32_t pull_ups;
> + uint32_t pull_downs;
> + unsigned int irq;
> + struct pinctrl_gpio_range grange;
Usually we add GPIO ranges from the device tree for device tree
drivers, look at the syntax in:
Documentation/devicetree/bindings/gpio/gpio.txt
git grep gpio-ranges arch/arm/boot/dts/
gives you a few examples.
> +#define gc_to_jzgc(gpiochip) \
> + container_of(gpiochip, struct ingenic_gpio_chip, gc)
Unless you must have this, please switch to using
struct ingenic_gpio_chip *jzgc = gpiochip_get_data(gc);
and use [devm_]gpiochip_add_data() in the probe so
you can get the data from the gpiochip directly.
> +static void ingenic_gpio_set(struct gpio_chip *gc,
> + unsigned int offset, int value)
> +{
> + struct ingenic_gpio_chip *jzgc = gc_to_jzgc(gc);
> +
> + jzgc->ops->gpio_set_value(jzgc->base, offset, value);
> +}
struct ingenic_gpio_chip *jzgc = gpiochip_get_data(gc);
etc everywhere.
> +static void ingenic_gpio_irq_ack(struct irq_data *irqd)
> +{
> + struct gpio_chip *gc = irq_data_get_irq_chip_data(irqd);
> + struct ingenic_gpio_chip *jzgc = gc_to_jzgc(gc);
> + unsigned int high;
> + int irq = irqd->hwirq;
> +
> + if (irqd_get_trigger_type(irqd) == IRQ_TYPE_EDGE_BOTH) {
> + /*
> + * Switch to an interrupt for the opposite edge to the one that
> + * triggered the interrupt being ACKed.
> + */
> + high = jzgc->ops->gpio_get_value(jzgc->base, irq);
> + if (high)
> + jzgc->ops->irq_set_type(jzgc->base, irq,
> + IRQ_TYPE_EDGE_FALLING);
> + else
> + jzgc->ops->irq_set_type(jzgc->base, irq,
> + IRQ_TYPE_EDGE_RISING);
Neat hack. This is often how you have to do it indeed.
> +static int ingenic_gpio_irq_set_type(struct irq_data *irqd, unsigned int type)
> +{
> + struct gpio_chip *gc = irq_data_get_irq_chip_data(irqd);
> + struct ingenic_gpio_chip *jzgc = gc_to_jzgc(gc);
> +
> + switch (type) {
> + case IRQ_TYPE_EDGE_BOTH:
> + case IRQ_TYPE_EDGE_RISING:
> + case IRQ_TYPE_EDGE_FALLING:
> + case IRQ_TYPE_LEVEL_HIGH:
> + case IRQ_TYPE_LEVEL_LOW:
> + break;
> + default:
> + pr_err("unsupported external interrupt type\n");
Should you set the irq handlet to handle_bad_irq() in this case?
That's what I usually do.
> + return -EINVAL;
> + }
> +
> + if (type & IRQ_TYPE_EDGE_BOTH)
> + irq_set_handler_locked(irqd, handle_edge_irq);
> + else
> + irq_set_handler_locked(irqd, handle_level_irq);
Nice.
> + jzgc->ops->irq_set_type(jzgc->base, irqd->hwirq, type);
Getting a bit of feeling that it's a bit much indirection vtable
business going on here, but depends on the series as a whole.
> +static int ingenic_gpio_irq_set_wake(struct irq_data *irqd, unsigned int on)
> +{
> + struct gpio_chip *gc = irq_data_get_irq_chip_data(irqd);
> + struct ingenic_gpio_chip *jzgc = gc_to_jzgc(gc);
> +
> + return irq_set_irq_wake(jzgc->irq, on);
> +}
I'm uncertain with these. Allright I guess, I'm just too bad at understanding
wakeup IRQs.
> +static void ingenic_gpio_irq_handler(struct irq_desc *desc)
> +{
> + struct gpio_chip *gc = irq_desc_get_handler_data(desc);
> + struct ingenic_gpio_chip *jzgc = gc_to_jzgc(gc);
> + struct irq_chip *irq_chip = irq_data_get_irq_chip(&desc->irq_data);
> + unsigned long flag, i;
> +
> + chained_irq_enter(irq_chip, desc);
> + flag = jzgc->ops->irq_read(jzgc->base);
> +
> + for_each_set_bit(i, &flag, 32)
> + generic_handle_irq(irq_linear_revmap(gc->irqdomain, i));
> + chained_irq_exit(irq_chip, desc);
> +}
Clean & nice.
> +static int ingenic_pinctrl_dt_node_to_map(
> + struct pinctrl_dev *pctldev, struct device_node *np,
> + struct pinctrl_map **map, unsigned int *num_maps)
> +{
> + struct ingenic_pinctrl *jzpc = pinctrl_dev_get_drvdata(pctldev);
> + struct ingenic_pinctrl_func *func;
> + struct ingenic_pinctrl_group *group;
> + struct pinctrl_map *new_map;
> + unsigned int map_num, i;
> +
> + group = find_group_by_of_node(jzpc, np);
> + if (!group)
> + return -EINVAL;
> +
> + func = find_func_by_of_node(jzpc, of_get_parent(np));
> + if (!func)
> + return -EINVAL;
> +
> + map_num = 1 + group->num_pins;
> + new_map = devm_kzalloc(jzpc->dev,
> + sizeof(*new_map) * map_num, GFP_KERNEL);
> + if (!new_map)
> + return -ENOMEM;
> +
> + new_map[0].type = PIN_MAP_TYPE_MUX_GROUP;
> + new_map[0].data.mux.function = func->name;
> + new_map[0].data.mux.group = group->name;
> +
> + for (i = 0; i < group->num_pins; i++) {
> + new_map[i + 1].type = PIN_MAP_TYPE_CONFIGS_PIN;
> + new_map[i + 1].data.configs.group_or_pin =
> + jzpc->pdesc[group->pins[i].idx].name;
> + new_map[i + 1].data.configs.configs = group->pins[i].configs;
> + new_map[i + 1].data.configs.num_configs =
> + group->pins[i].num_configs;
> + }
> +
> + *map = new_map;
> + *num_maps = map_num;
> + return 0;
> +}
This may change due to DT bindings reviews. I would prefer if you use
generic functions.
> +static int ingenic_pinctrl_parse_dt_gpio(struct ingenic_pinctrl *jzpc,
> + struct ingenic_gpio_chip *jzgc, struct device_node *np)
Naming here: parse or probe or init. This function is certainly not just
parsing the DT. init() or probe() is better.
> + jzgc->gc.base = jzpc->base + (jzgc->idx * PINS_PER_GPIO_PORT);
No. No hard-coded GPIO bases on new GPIO driver.
Set this to -1 so it uses dynamic allocation of GPIO numbers.
> + if (of_property_read_u32_index(np, "ingenic,pull-ups", 0,
> + &jzgc->pull_ups))
> + jzgc->pull_ups = 0;
> + if (of_property_read_u32_index(np, "ingenic,pull-downs", 0,
> + &jzgc->pull_downs))
> + jzgc->pull_downs = 0;
> +
> + if (jzgc->pull_ups & jzgc->pull_downs) {
> + dev_err(jzpc->dev, "GPIO port %c has overlapping pull ups & pull downs\n",
> + 'A' + jzgc->idx);
> + return -EINVAL;
> + }
These bindings look suspicious. But I will review them in the binding
document.
> +static int ingenic_pinctrl_parse_dt_pincfg(struct ingenic_pinctrl *jzpc,
> + struct ingenic_pinctrl_pin *pin, phandle cfg_handle)
> +{
> + struct device_node *cfg_node;
> + int err;
> +
> + cfg_node = of_find_node_by_phandle(cfg_handle);
> + if (!cfg_node)
> + return -EINVAL;
> +
> + err = pinconf_generic_parse_dt_config(cfg_node, NULL,
> + &pin->configs, &pin->num_configs);
> + if (err)
> + return err;
> +
> + err = devm_add_action(jzpc->dev, (void (*)(void *))kfree, pin->configs);
That looks very clever.
But when we have pinctrl_utils_free_map() and other helpers already
this free:ing looks like some reinvented wheel.
Can we create something that free:s the maps from
pinctrl_utils_reserve_map() in a similar way and use that?
Just thinking aloud.
> +static int ingenic_pinctrl_parse_dt_func(struct ingenic_pinctrl *jzpc,
> + struct device_node *np, unsigned int *ifunc,
> + unsigned int *igroup)
> +{
> + struct ingenic_pinctrl_func *func;
> + struct ingenic_pinctrl_group *grp;
> + struct device_node *group_node, *gpio_node;
> + struct gpio_chip *gpio_chip;
> + phandle gpio_handle, cfg_handle;
> + struct property *pp;
> + __be32 *plist;
> + unsigned int i, j;
> + int err;
> + const unsigned int vals_per_pin = 4;
> +
> + func = &jzpc->funcs[(*ifunc)++];
> + func->of_node = np;
> + func->name = np->name;
> +
> + func->num_groups = of_get_child_count(np);
> + func->groups = devm_kzalloc(jzpc->dev, sizeof(*func->groups) *
> + func->num_groups, GFP_KERNEL);
> + func->group_names = devm_kzalloc(jzpc->dev,
> + sizeof(*func->group_names) * func->num_groups,
> + GFP_KERNEL);
> + if (!func->groups || !func->group_names)
> + return -ENOMEM;
> +
> + i = 0;
> + for_each_child_of_node(np, group_node) {
> + pp = of_find_property(group_node, "ingenic,pins", NULL);
> + if (!pp)
> + return -EINVAL;
> + if ((pp->length / sizeof(__be32)) % vals_per_pin)
> + return -EINVAL;
> +
> + grp = &jzpc->groups[(*igroup)++];
> + grp->of_node = group_node;
> + grp->name = group_node->name;
> + grp->num_pins = (pp->length / sizeof(__be32)) / vals_per_pin;
> + grp->pins = devm_kzalloc(jzpc->dev, sizeof(*grp->pins) *
> + grp->num_pins, GFP_KERNEL);
> + grp->pin_indices = devm_kzalloc(jzpc->dev,
> + sizeof(*grp->pin_indices) * grp->num_pins,
> + GFP_KERNEL);
> + if (!grp->pins)
> + return -EINVAL;
> +
> + plist = pp->value;
> + for (j = 0; j < grp->num_pins; j++) {
> + gpio_handle = be32_to_cpup(plist++);
> + grp->pins[j].idx = be32_to_cpup(plist++);
> + grp->pins[j].func = be32_to_cpup(plist++);
> + cfg_handle = be32_to_cpup(plist++);
> +
> + gpio_node = of_find_node_by_phandle(gpio_handle);
> + if (!gpio_node)
> + return -EINVAL;
> +
> + gpio_chip = gpiochip_find(gpio_node,
> + find_gpio_chip_by_of_node);
> + if (!gpio_chip)
> + return -EINVAL;
> +
> + grp->pins[j].gpio_chip = gc_to_jzgc(gpio_chip);
> +
> + err = ingenic_pinctrl_parse_dt_pincfg(jzpc,
> + &grp->pins[j], cfg_handle);
> + if (err)
> + return err;
> +
> + grp->pins[j].idx += grp->pins[j].gpio_chip->idx *
> + PINS_PER_GPIO_PORT;
> + grp->pin_indices[j] = grp->pins[j].idx;
> + }
> +
> + func->groups[i] = grp;
> + func->group_names[i] = grp->name;
> + i++;
> + }
> +
> + return 0;
> +}
Tony Lindgren has added generic function and group parsing for drivers
that keep functions and groups in the device tree. This code is committed
and available in the pinctrl git tree.
Look at commits:
commit c7059c5ac70aea194b07b2d811df433eb0ca81b5
pinctrl: core: Add generic pinctrl functions for managing groups
commit a76edc89b100e4fefb2a5c00cd8cd557437659e7
pinctrl: core: Add generic pinctrl functions for managing groups
commit caeb774ea3b1bc25dc2f24681c27543aba6ca7ae
pinctrl: single: Use generic pinctrl helpers for managing groups
commit 571aec4df5b72a80f80d1e524da8fbd7ff525c98
pinctrl: single: Use generic pinmux helpers for managing functions
commit 3fd6d6ad73af90522321451a2d10b0a8967d47d1
pinctrl: imx: use generic pinmux helpers for managing functions
So two drivers already switch to generic code handling this.
Please investigate and try out the above.
> +int ingenic_pinctrl_probe(struct platform_device *pdev,
> + const struct ingenic_pinctrl_ops *ops)
> +{
> + struct device *dev = &pdev->dev;
> + struct ingenic_pinctrl *jzpc;
> + struct ingenic_gpio_chip *jzgc;
> + struct pinctrl_desc *pctl_desc;
> + struct device_node *np, *chips_node, *functions_node;
> + unsigned int i, j;
> + int err;
> +
> + if (!dev->of_node) {
> + dev_err(dev, "device tree node not found\n");
> + return -ENODEV;
> + }
I think this check is not necessary since you only probe from device tree.
We usually skip it these days.
> + jzpc->base = 0;
> + of_property_read_u32(dev->of_node, "base", &jzpc->base);
If this is the Linux GPIO number base then NACK, we don't define
Linux-specific things in the device tree.
Please use dynamic allocation of GPIO base anyways, as stated
above.
> + chips_node = of_find_node_by_name(dev->of_node, "gpio-chips");
This looks like a very dubious new DT bindings. Will review in that
document.
> + jzpc->num_gpio_chips = of_get_available_child_count(chips_node);
> + if (!jzpc->num_gpio_chips) {
> + dev_err(dev, "No GPIO chips found\n");
> + return -EINVAL;
> + }
Usually it is better to create one device per gpiochip.
> + /* register pinctrl GPIO ranges */
> + for (i = 0; i < jzpc->num_gpio_chips; i++) {
> + jzgc = &jzpc->gpio_chips[i];
> +
> + jzgc->grange.name = jzgc->name;
> + jzgc->grange.id = jzgc->idx;
> + jzgc->grange.pin_base = jzgc->idx * PINS_PER_GPIO_PORT;
> + jzgc->grange.base = jzgc->gc.base;
> + jzgc->grange.npins = jzgc->gc.ngpio;
> + jzgc->grange.gc = &jzgc->gc;
> + pinctrl_add_gpio_range(jzpc->pctl, &jzgc->grange);
> + }
I strongly recommend defining the GPIO ranges in the device tree
and if not possible, to add the GPIO range from the gpiochip
side and not the pinctrl side.
> +struct ingenic_pinctrl_ops {
> + unsigned int nb_functions;
> +
> + void (*set_function)(void __iomem *base,
> + unsigned int offset, unsigned int function);
> + void (*set_gpio)(void __iomem *base, unsigned int offset, bool output);
> + int (*get_bias)(void __iomem *base, unsigned int offset);
> + void (*set_bias)(void __iomem *base, unsigned int offset, bool enable);
> + void (*gpio_set_value)(void __iomem *base,
> + unsigned int offset, int value);
> + int (*gpio_get_value)(void __iomem *base, unsigned int offset);
> + u32 (*irq_read)(void __iomem *base);
> + void (*irq_mask)(void __iomem *base, unsigned int irq, bool mask);
> + void (*irq_ack)(void __iomem *base, unsigned int irq);
> + void (*irq_set_type)(void __iomem *base,
> + unsigned int irq, unsigned int type);
> +};
This is a *lot* of vtable indirections. Are you sure this is a good
idea?
> +static void jz4740_set_gpio(void __iomem *base,
> + unsigned int offset, bool output)
> +{
> + writel(1 << offset, base + GPIO_FUNCC);
> + writel(1 << offset, base + GPIO_SELECTC);
> + writel(1 << offset, base + GPIO_TRIGC);
> +
> + if (output)
> + writel(1 << offset, base + GPIO_DIRS);
> + else
> + writel(1 << offset, base + GPIO_DIRC);
> +}
Replace all (1 << offset) things with:
#include <linux/bitops.h>
BIT(offset)
Simple and clean.
> +static int jz4740_get_bias(void __iomem *base, unsigned int offset)
> +{
> + return !((readl(base + GPIO_PULL_DIS) >> offset) & 0x1);
> +}
Similarly:
return !((readl(base + GPIO_PULL_DIR) & BIT(offset));
Follow these patterns everywhere.
> +static int jz4740_gpio_get_value(void __iomem *base, unsigned int offset)
> +{
> + return (readl(base + GPIO_DATA) >> offset) & 0x1;
> +}
return !!(readl(base + GPIO_DATA) & BIT(offset));
Yours,
Linus Walleij
^ permalink raw reply
* Re: [PATCH v7 4/8] PWM: add PWM driver for STM32 plaftorm
From: Thierry Reding @ 2017-01-18 10:16 UTC (permalink / raw)
To: Benjamin Gaignard
Cc: lee.jones, robh+dt, mark.rutland, alexandre.torgue, devicetree,
linux-kernel, linux-pwm, jic23, knaack.h, lars, pmeerw, linux-iio,
linux-arm-kernel, fabrice.gasnier, gerald.baeza, arnaud.pouliquen,
linus.walleij, linaro-kernel, Benjamin Gaignard
In-Reply-To: <1483608344-9012-5-git-send-email-benjamin.gaignard@st.com>
[-- Attachment #1: Type: text/plain, Size: 823 bytes --]
On Thu, Jan 05, 2017 at 10:25:40AM +0100, Benjamin Gaignard wrote:
[...]
> diff --git a/drivers/pwm/Kconfig b/drivers/pwm/Kconfig
> index f92dd41..88035c0 100644
> --- a/drivers/pwm/Kconfig
> +++ b/drivers/pwm/Kconfig
> @@ -397,6 +397,15 @@ config PWM_STI
> To compile this driver as a module, choose M here: the module
> will be called pwm-sti.
>
> +config PWM_STM32
> + tristate "STMicroelectronics STM32 PWM"
> + depends on (ARCH_STM32 && OF && MFD_STM32_TIMERS) || COMPILE_TEST
One other thing: is the dependency on ARCH_STM32 and OF necessary here?
ARCH_STM32 and OF are both pulled in by MFD_STM32_TIMERS. The dependency
is probably fine for MFD_STM32_TIMERS, though even there && OF seems too
much, since it's already pulled in via ARCH_STM32 -> ARM_SINGLE_ARMV7M
-> USE_OF.
Thierry
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply
* [PATCH 1/1] ARM: dts: imx6dl: fix GPIO4 range
From: Sébastien Szymanski @ 2017-01-18 10:09 UTC (permalink / raw)
To: linux-arm-kernel
Cc: Mark Rutland, devicetree, Russell King, linux-kernel, Rob Herring,
Sascha Hauer, Fabio Estevam, Julien Boibessot, Shawn Guo
GPIO4_11 is on pin 152(MX6DL_PAD_KEY_ROW2) and not on pin
151(MX6DL_PAD_KEY_ROW1).
I found the error while booting a mainline kernel on APF6S SoM and
noticed the following message:
[ 2.609337] imx6dl-pinctrl 20e0000.iomuxc: pin MX6DL_PAD_KEY_ROW1
already requested by 20a8000.gpio:105; cannot claim for 20a8000.gpio:107
[ 2.621884] imx6dl-pinctrl 20e0000.iomuxc: pin-151 (20a8000.gpio:107)
status -22
[ 2.629303] spi_imx 2008000.ecspi: Can't get CS GPIO 107
With this patch, the message is gone and spi_imx driver probes correctly.
Fixes: bb728d662bed ("ARM: dts: add gpio-ranges property to iMX GPIO
controllers")
Signed-off-by: Sébastien Szymanski <sebastien.szymanski@armadeus.com>
---
arch/arm/boot/dts/imx6dl.dtsi | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/imx6dl.dtsi b/arch/arm/boot/dts/imx6dl.dtsi
index 1ade195..7aa120f 100644
--- a/arch/arm/boot/dts/imx6dl.dtsi
+++ b/arch/arm/boot/dts/imx6dl.dtsi
@@ -137,7 +137,7 @@
&gpio4 {
gpio-ranges = <&iomuxc 5 136 1>, <&iomuxc 6 145 1>, <&iomuxc 7 150 1>,
<&iomuxc 8 146 1>, <&iomuxc 9 151 1>, <&iomuxc 10 147 1>,
- <&iomuxc 11 151 1>, <&iomuxc 12 148 1>, <&iomuxc 13 153 1>,
+ <&iomuxc 11 152 1>, <&iomuxc 12 148 1>, <&iomuxc 13 153 1>,
<&iomuxc 14 149 1>, <&iomuxc 15 154 1>, <&iomuxc 16 39 7>,
<&iomuxc 23 56 1>, <&iomuxc 24 61 7>, <&iomuxc 31 46 1>;
};
--
2.7.3
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* Re: [PATCH v7 4/8] PWM: add PWM driver for STM32 plaftorm
From: Thierry Reding @ 2017-01-18 10:08 UTC (permalink / raw)
To: Benjamin Gaignard
Cc: lee.jones-QSEj5FYQhm4dnm+yROfE0A, robh+dt-DgEjT+Ai2ygdnm+yROfE0A,
mark.rutland-5wv7dgnIgG8, alexandre.torgue-qxv4g6HH51o,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-pwm-u79uwXL29TY76Z2rM5mHXA, jic23-DgEjT+Ai2ygdnm+yROfE0A,
knaack.h-Mmb7MZpHnFY, lars-Qo5EllUWu/uELgA04lAiVw,
pmeerw-jW+XmwGofnusTnJN9+BGXg, linux-iio-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
fabrice.gasnier-qxv4g6HH51o, gerald.baeza-qxv4g6HH51o,
arnaud.pouliquen-qxv4g6HH51o,
linus.walleij-QSEj5FYQhm4dnm+yROfE0A,
linaro-kernel-cunTk1MwBs8s++Sfvej+rw, Benjamin Gaignard
In-Reply-To: <1483608344-9012-5-git-send-email-benjamin.gaignard-qxv4g6HH51o@public.gmane.org>
[-- Attachment #1: Type: text/plain, Size: 14986 bytes --]
On Thu, Jan 05, 2017 at 10:25:40AM +0100, Benjamin Gaignard wrote:
> This driver adds support for PWM driver on STM32 platform.
> The SoC have multiple instances of the hardware IP and each
> of them could have small differences: number of channels,
> complementary output, auto reload register size...
>
> version 6:
> - change st,breakinput parameter to make it usuable for stm32f7 too.
>
> version 4:
> - detect at probe time hardware capabilities
> - fix comments done on v2 and v3
> - use PWM atomic ops
>
> version 2:
> - only keep one comptatible
> - use DT parameters to discover hardware block configuration
>
> Signed-off-by: Benjamin Gaignard <benjamin.gaignard-qxv4g6HH51o@public.gmane.org>
> ---
> drivers/pwm/Kconfig | 9 +
> drivers/pwm/Makefile | 1 +
> drivers/pwm/pwm-stm32.c | 434 ++++++++++++++++++++++++++++++++++++++++++++++++
> 3 files changed, 444 insertions(+)
> create mode 100644 drivers/pwm/pwm-stm32.c
>
> diff --git a/drivers/pwm/Kconfig b/drivers/pwm/Kconfig
> index f92dd41..88035c0 100644
> --- a/drivers/pwm/Kconfig
> +++ b/drivers/pwm/Kconfig
> @@ -397,6 +397,15 @@ config PWM_STI
> To compile this driver as a module, choose M here: the module
> will be called pwm-sti.
>
> +config PWM_STM32
> + tristate "STMicroelectronics STM32 PWM"
> + depends on (ARCH_STM32 && OF && MFD_STM32_TIMERS) || COMPILE_TEST
> + help
> + Generic PWM framework driver for STM32 SoCs.
> +
> + To compile this driver as a module, choose M here: the module
> + will be called pwm-stm32.
> +
> config PWM_STMPE
> bool "STMPE expander PWM export"
> depends on MFD_STMPE
> diff --git a/drivers/pwm/Makefile b/drivers/pwm/Makefile
> index a48bdb5..346a83b 100644
> --- a/drivers/pwm/Makefile
> +++ b/drivers/pwm/Makefile
> @@ -38,6 +38,7 @@ obj-$(CONFIG_PWM_ROCKCHIP) += pwm-rockchip.o
> obj-$(CONFIG_PWM_SAMSUNG) += pwm-samsung.o
> obj-$(CONFIG_PWM_SPEAR) += pwm-spear.o
> obj-$(CONFIG_PWM_STI) += pwm-sti.o
> +obj-$(CONFIG_PWM_STM32) += pwm-stm32.o
> obj-$(CONFIG_PWM_STMPE) += pwm-stmpe.o
> obj-$(CONFIG_PWM_SUN4I) += pwm-sun4i.o
> obj-$(CONFIG_PWM_TEGRA) += pwm-tegra.o
> diff --git a/drivers/pwm/pwm-stm32.c b/drivers/pwm/pwm-stm32.c
> new file mode 100644
> index 0000000..fcf0a78
> --- /dev/null
> +++ b/drivers/pwm/pwm-stm32.c
> @@ -0,0 +1,434 @@
> +/*
> + * Copyright (C) STMicroelectronics 2016
> + *
> + * Author: Gerald Baeza <gerald.baeza-qxv4g6HH51o@public.gmane.org>
> + *
> + * License terms: GNU General Public License (GPL), version 2
> + *
> + * Inspired by timer-stm32.c from Maxime Coquelin
> + * pwm-atmel.c from Bo Shen
> + */
> +
> +#include <linux/mfd/stm32-timers.h>
> +#include <linux/module.h>
> +#include <linux/platform_device.h>
> +#include <linux/pwm.h>
> +#include <linux/of.h>
Can you please sort these alphabetically?
> +
> +#define CCMR_CHANNEL_SHIFT 8
> +#define CCMR_CHANNEL_MASK 0xFF
> +#define MAX_BREAKINPUT 2
Okay, this answers my question regarding the st,breakinput property. I
still think it'd be good to have this in the binding documentation just
to avoid having to look at implementation to find out.
> +
> +struct stm32_pwm {
> + struct pwm_chip chip;
> + struct device *dev;
> + struct clk *clk;
> + struct regmap *regmap;
> + unsigned int caps;
This seems completely unused?
> + unsigned int npwm;
It's somewhat redundant to have this here, since the same information is
already contained in struct pwm_chip.npwm.
Since you use this primarily for detection, how about you make the
stm32_pwm_detect_channels() function return the value and store it in a
local variable in ->probe()? That might be useful also because you
need to check the return value of regmap_update_bits() which technically
could fail.
> + u32 max_arr;
> + bool have_complementary_output;
> +};
> +
> +struct stm32_breakinput {
> + u32 index;
> + u32 level;
> + u32 filter;
> +};
> +
> +static inline struct stm32_pwm *to_stm32_pwm_dev(struct pwm_chip *chip)
> +{
> + return container_of(chip, struct stm32_pwm, chip);
> +}
> +
> +static u32 active_channels(struct stm32_pwm *dev)
> +{
> + u32 ccer;
> +
> + regmap_read(dev->regmap, TIM_CCER, &ccer);
> +
> + return ccer & TIM_CCER_CCXE;
> +}
This looks like something that you could track in software, but this is
probably fine, too. Again, technically regmap_read() could fail, so you
might want to consider adding some code to handle it. In practice it
probably won't, so maybe you don't.
> +
> +static int write_ccrx(struct stm32_pwm *dev, struct pwm_device *pwm,
> + u32 value)
> +{
> + switch (pwm->hwpwm) {
> + case 0:
> + return regmap_write(dev->regmap, TIM_CCR1, value);
> + case 1:
> + return regmap_write(dev->regmap, TIM_CCR2, value);
> + case 2:
> + return regmap_write(dev->regmap, TIM_CCR3, value);
> + case 3:
> + return regmap_write(dev->regmap, TIM_CCR4, value);
> + }
> + return -EINVAL;
> +}
> +
> +static int stm32_pwm_config(struct pwm_chip *chip, struct pwm_device *pwm,
> + int duty_ns, int period_ns)
> +{
> + struct stm32_pwm *priv = to_stm32_pwm_dev(chip);
> + unsigned long long prd, div, dty;
> + unsigned int prescaler = 0;
> + u32 ccmr, mask, shift;
> +
> + /* Period and prescaler values depends on clock rate */
> + div = (unsigned long long)clk_get_rate(priv->clk) * period_ns;
> +
> + do_div(div, NSEC_PER_SEC);
> + prd = div;
> +
> + while (div > priv->max_arr) {
> + prescaler++;
> + div = prd;
> + do_div(div, (prescaler + 1));
Nit: there's no need for the parentheses here.
> + }
> +
> + prd = div;
> +
> + if (prescaler > MAX_TIM_PSC) {
> + dev_err(chip->dev, "prescaler exceeds the maximum value\n");
> + return -EINVAL;
> + }
> +
> + /*
> + * All channels share the same prescaler and counter so when two
> + * channels are active at the same we can't change them
Nit: "at the same time"?
> + */
> + if (active_channels(priv) & ~(1 << pwm->hwpwm * 4)) {
> + u32 psc, arr;
> +
> + regmap_read(priv->regmap, TIM_PSC, &psc);
> + regmap_read(priv->regmap, TIM_ARR, &arr);
> +
> + if ((psc != prescaler) || (arr != prd - 1))
> + return -EBUSY;
> + }
> +
> + regmap_write(priv->regmap, TIM_PSC, prescaler);
> + regmap_write(priv->regmap, TIM_ARR, prd - 1);
> + regmap_update_bits(priv->regmap, TIM_CR1, TIM_CR1_ARPE, TIM_CR1_ARPE);
> +
> + /* Calculate the duty cycles */
> + dty = prd * duty_ns;
> + do_div(dty, period_ns);
> +
> + write_ccrx(priv, pwm, dty);
> +
> + /* Configure output mode */
> + shift = (pwm->hwpwm & 0x1) * CCMR_CHANNEL_SHIFT;
> + ccmr = (TIM_CCMR_PE | TIM_CCMR_M1) << shift;
> + mask = CCMR_CHANNEL_MASK << shift;
> +
> + if (pwm->hwpwm < 2)
> + regmap_update_bits(priv->regmap, TIM_CCMR1, mask, ccmr);
> + else
> + regmap_update_bits(priv->regmap, TIM_CCMR2, mask, ccmr);
> +
> + regmap_update_bits(priv->regmap, TIM_BDTR,
> + TIM_BDTR_MOE | TIM_BDTR_AOE,
> + TIM_BDTR_MOE | TIM_BDTR_AOE);
> +
> + return 0;
> +}
> +
> +static int stm32_pwm_set_polarity(struct pwm_chip *chip, struct pwm_device *pwm,
> + enum pwm_polarity polarity)
> +{
> + u32 mask;
> + struct stm32_pwm *priv = to_stm32_pwm_dev(chip);
> +
> + mask = TIM_CCER_CC1P << (pwm->hwpwm * 4);
> + if (priv->have_complementary_output)
> + mask |= TIM_CCER_CC1NP << (pwm->hwpwm * 4);
> +
> + regmap_update_bits(priv->regmap, TIM_CCER, mask,
> + polarity == PWM_POLARITY_NORMAL ? 0 : mask);
> +
> + return 0;
> +}
> +
> +static int stm32_pwm_enable(struct pwm_chip *chip, struct pwm_device *pwm)
> +{
> + u32 mask;
> + struct stm32_pwm *priv = to_stm32_pwm_dev(chip);
> +
> + clk_enable(priv->clk);
This can fail, so its return value should be checked. Also, I don't see
a clk_prepare() anywhere. Is that something that maybe the MFD driver
should be doing? It currently isn't.
> +
> + /* Enable channel */
> + mask = TIM_CCER_CC1E << (pwm->hwpwm * 4);
> + if (priv->have_complementary_output)
> + mask |= TIM_CCER_CC1NE << (pwm->hwpwm * 4);
> +
> + regmap_update_bits(priv->regmap, TIM_CCER, mask, mask);
> +
> + /* Make sure that registers are updated */
> + regmap_update_bits(priv->regmap, TIM_EGR, TIM_EGR_UG, TIM_EGR_UG);
> +
> + /* Enable controller */
> + regmap_update_bits(priv->regmap, TIM_CR1, TIM_CR1_CEN, TIM_CR1_CEN);
> +
> + return 0;
> +}
> +
> +static void stm32_pwm_disable(struct pwm_chip *chip, struct pwm_device *pwm)
> +{
> + u32 mask;
> + struct stm32_pwm *priv = to_stm32_pwm_dev(chip);
> +
> + /* Disable channel */
> + mask = TIM_CCER_CC1E << (pwm->hwpwm * 4);
> + if (priv->have_complementary_output)
> + mask |= TIM_CCER_CC1NE << (pwm->hwpwm * 4);
> +
> + regmap_update_bits(priv->regmap, TIM_CCER, mask, 0);
> +
> + /* When all channels are disabled, we can disable the controller */
> + if (!active_channels(priv))
> + regmap_update_bits(priv->regmap, TIM_CR1, TIM_CR1_CEN, 0);
> +
> + clk_disable(priv->clk);
> +}
> +
> +static int stm32_pwm_apply(struct pwm_chip *chip, struct pwm_device *pwm,
> + struct pwm_state *state)
> +{
> + struct pwm_state curstate;
> + bool enabled;
> + int ret;
> +
> + pwm_get_state(pwm, &curstate);
> + enabled = curstate.enabled;
There should be no need to do this in drivers. pwm_get_state() is for
PWM API users. Drivers can directly dereference pwm->state.
> +
> + if (enabled && !state->enabled) {
> + stm32_pwm_disable(chip, pwm);
> + return 0;
> + }
> +
> + if (state->polarity != curstate.polarity && enabled)
> + stm32_pwm_set_polarity(chip, pwm, state->polarity);
So that's kind of a violation of atomic API semantics. The above means
that if you have a PWM in the following state:
enabled: no
polarity: normal
and want to set this:
enabled: yes
polarity: inversed
then you will ignore the new polarity setting. What's the reason for
"&& enabled) in the conditional above?
> +
> + ret = stm32_pwm_config(chip, pwm, state->duty_cycle, state->period);
> + if (ret)
> + return ret;
> +
> + if (!enabled && state->enabled)
> + ret = stm32_pwm_enable(chip, pwm);
> +
> + return ret;
> +}
Would it be possible to merge stm32_pwm_disable(), stm32_pwm_enable(),
stm32_pwm_set_polarity() and stm32_pwm_config() into stm32_pwm_apply()?
Part of the reason for the atomic API was to make it easier to write
these drivers, but your implementation effectively copies what the
transitional helpers do.
It might not make a difference technically in your case, but I think
it'd make the implementation more compact and set a better example for
future reference.
> +
> +static const struct pwm_ops stm32pwm_ops = {
> + .owner = THIS_MODULE,
> + .apply = stm32_pwm_apply,
> +};
> +
> +static int stm32_pwm_set_breakinput(struct stm32_pwm *priv,
> + int level, int filter)
> +{
> + u32 bdtr = TIM_BDTR_BKE;
> +
> + if (level)
> + bdtr |= TIM_BDTR_BKP;
> +
> + bdtr |= (filter & TIM_BDTR_BKF_MASK) << TIM_BDTR_BKF_SHIFT;
> +
> + regmap_update_bits(priv->regmap,
> + TIM_BDTR, TIM_BDTR_BKE | TIM_BDTR_BKP | TIM_BDTR_BKF,
> + bdtr);
> +
> + regmap_read(priv->regmap, TIM_BDTR, &bdtr);
> +
> + return (bdtr & TIM_BDTR_BKE) ? 0 : -EINVAL;
> +}
> +
> +static int stm32_pwm_set_breakinput2(struct stm32_pwm *priv,
> + int level, int filter)
> +{
> + u32 bdtr = TIM_BDTR_BK2E;
> +
> + if (level)
> + bdtr |= TIM_BDTR_BK2P;
> +
> + bdtr |= (filter & TIM_BDTR_BKF_MASK) << TIM_BDTR_BK2F_SHIFT;
> +
> + regmap_update_bits(priv->regmap,
> + TIM_BDTR, TIM_BDTR_BK2E |
> + TIM_BDTR_BK2P |
> + TIM_BDTR_BK2F,
> + bdtr);
> +
> + regmap_read(priv->regmap, TIM_BDTR, &bdtr);
> +
> + return (bdtr & TIM_BDTR_BK2E) ? 0 : -EINVAL;
> +}
As far as I can tell the only difference here is the various bit
positions. Can you collapse the above two functions and add a new
parameter to unify some code?
> +
> +static int stm32_pwm_apply_breakinputs(struct stm32_pwm *priv,
> + struct device_node *np)
> +{
> + struct stm32_breakinput breakinput[MAX_BREAKINPUT];
> + int nb, ret, i, array_size;
> +
> + nb = of_property_count_elems_of_size(np, "st,breakinput",
> + sizeof(struct stm32_breakinput));
> +
> + /*
> + * Because "st,breakinput" parameter is optional do not make probe
> + * failed if it doesn't exist.
> + */
> + if (nb <= 0)
> + return 0;
> +
> + if (nb > MAX_BREAKINPUT)
> + return -EINVAL;
> +
> + array_size = nb * sizeof(struct stm32_breakinput) / sizeof(u32);
> + ret = of_property_read_u32_array(np, "st,breakinput",
> + &breakinput[0].index, array_size);
Maybe (u32 *)breakinput? That would make it more resilient against
changes in ordering of fields in the struct. Granted, that's not likely
to change, but I think it's a good idea in general to write code in a
way that's safe in a more general case. That way if somebody ever were
to copy from your code and then decide to reorder fields in their code
things wouldn't fall apart.
> + if (ret)
> + return ret;
> +
> + for (i = 0; i < nb && !ret; i++) {
> + switch (breakinput[i].index) {
> + case 0:
> + {
> + ret = stm32_pwm_set_breakinput(priv,
> + breakinput[i].level,
> + breakinput[i].filter);
> + break;
> + }
Curly braces are unnecessary here.
> + case 1:
> + {
> + ret = stm32_pwm_set_breakinput2(priv,
> + breakinput[i].level,
> + breakinput[i].filter);
> +
> + break;
> + }
> + default:
> + {
> + ret = -EINVAL;
> + break;
> + }
> + }
> + }
> +
> + return ret;
> +}
> +
> +static void stm32_pwm_detect_complementary(struct stm32_pwm *priv)
> +{
> + u32 ccer;
> +
> + /*
> + * If complementary bit doesn't exist writing 1 will have no
> + * effect so we can detect it.
> + */
> + regmap_update_bits(priv->regmap,
> + TIM_CCER, TIM_CCER_CC1NE, TIM_CCER_CC1NE);
> + regmap_read(priv->regmap, TIM_CCER, &ccer);
> + regmap_update_bits(priv->regmap, TIM_CCER, TIM_CCER_CCXE, 0);
This is strange: why are we disabling outputs here? Shouldn't the last
line here undo the first instead?
> +
> + priv->have_complementary_output = (ccer != 0);
> +}
> +
> +static void stm32_pwm_detect_channels(struct stm32_pwm *priv)
> +{
> + u32 ccer;
> +
> + /*
> + * If channels enable bits don't exist writing 1 will have no
> + * effect so we can detect and count them.
> + */
> + regmap_update_bits(priv->regmap,
> + TIM_CCER, TIM_CCER_CCXE, TIM_CCER_CCXE);
> + regmap_read(priv->regmap, TIM_CCER, &ccer);
> + regmap_update_bits(priv->regmap, TIM_CCER, TIM_CCER_CCXE, 0);
Does this have the potential to glitch? I suspect that the clock may not
be on at this point and therefore no PWM outputs will be generated, but
is that guaranteed to always be the case?
Thierry
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply
* [PATCH] arm64: dts: hisilicon: add dtsi file for Hisilicon Hi3660 SOC
From: Wang Xiaoyin @ 2017-01-18 10:04 UTC (permalink / raw)
To: xuwei5, robh+dt, mark.rutland, catalin.marinas, will.deacon,
linux-arm-kernel, devicetree, linux-kernel
Cc: hw.wangxiaoyin, chenya99
This patch adds pinctrl dtsi file
Signed-off-by: Wang Xiaoyin <hw.wangxiaoyin@hisilicon.com>
---
arch/arm64/boot/dts/hisilicon/hi3660-hikey960.dts | 3 +-
.../arm64/boot/dts/hisilicon/hikey960-pinctrl.dtsi | 292 +++++++++++++++++++++
2 files changed, 293 insertions(+), 2 deletions(-)
create mode 100644 arch/arm64/boot/dts/hisilicon/hikey960-pinctrl.dtsi
diff --git a/arch/arm64/boot/dts/hisilicon/hi3660-hikey960.dts b/arch/arm64/boot/dts/hisilicon/hi3660-hikey960.dts
index 9a1d36aa84ce..de21ebfa4bd8 100644
--- a/arch/arm64/boot/dts/hisilicon/hi3660-hikey960.dts
+++ b/arch/arm64/boot/dts/hisilicon/hi3660-hikey960.dts
@@ -8,8 +8,7 @@
/dts-v1/;
#include "hi3660.dtsi"
-/*#include "hi3660-ion.dtsi"*/
-/*#include "hikey960-pinctrl.dtsi"*/
+#include "hikey960-pinctrl.dtsi"
/ {
model = "HiKey960";
diff --git a/arch/arm64/boot/dts/hisilicon/hikey960-pinctrl.dtsi b/arch/arm64/boot/dts/hisilicon/hikey960-pinctrl.dtsi
new file mode 100644
index 000000000000..98a0b78289b6
--- /dev/null
+++ b/arch/arm64/boot/dts/hisilicon/hikey960-pinctrl.dtsi
@@ -0,0 +1,292 @@
+/*
+ * pinctrl dts fils for Hislicon HiKey960 development board
+ *
+ */
+
+#include <dt-bindings/pinctrl/hisi.h>
+
+/ {
+ soc {
+ /* [IOMG_000, IOMG_123] */
+ range: gpio-range {
+ #pinctrl-single,gpio-range-cells = <3>;
+ };
+ pmx0: pinmux@e896c000 {
+ compatible = "pinctrl-single";
+ reg = <0x0 0xe896c000 0x0 0x1f0>;
+ #pinctrl-cells = <1>;
+ #gpio-range-cells = <0x3>;
+ pinctrl-single,register-width = <0x20>;
+ pinctrl-single,function-mask = <0x7>;
+ /* pin base, nr pins & gpio function */
+ pinctrl-single,gpio-range = <
+ &range 0 7 0
+ &range 8 116 0>;
+
+ isp0_pmx_func: isp0_pmx_func {
+ pinctrl-single,pins = <
+ 0x058 MUX_M1 /* ISP_CLK0 */
+ 0x064 MUX_M1 /* ISP_SCL0 */
+ 0x068 MUX_M1 /* ISP_SDA0 */
+ >;
+ };
+
+ isp1_pmx_func: isp1_pmx_func {
+ pinctrl-single,pins = <
+ 0x05c MUX_M1 /* ISP_CLK1 */
+ 0x06c MUX_M1 /* ISP_SCL1 */
+ 0x070 MUX_M1 /* ISP_SDA1 */
+ >;
+ };
+
+ i2c3_pmx_func: i2c3_pmx_func {
+ pinctrl-single,pins = <
+ 0x02c MUX_M1 /* I2C3_SCL */
+ 0x030 MUX_M1 /* I2C3_SDA */
+ >;
+ };
+
+ i2c4_pmx_func: i2c4_pmx_func {
+ pinctrl-single,pins = <
+ 0x090 MUX_M1 /* I2C4_SCL */
+ 0x094 MUX_M1 /* I2C4_SDA */
+ >;
+ };
+
+ pcie_perstn_pmx_func: pcie_perstn_pmx_func {
+ pinctrl-single,pins = <
+ 0x15c MUX_M1 /* PCIE_PERST_N */
+ >;
+ };
+
+ usbhub5734_pmx_func: usbhub5734_pmx_func {
+ pinctrl-single,pins = <
+ 0x11c MUX_M0 /* GPIO_073 */
+ 0x120 MUX_M0 /* GPIO_074 */
+ >;
+ };
+
+ spi1_pmx_func: spi1_pmx_func {
+ pinctrl-single,pins = <
+ 0x034 MUX_M1 /* SPI1_CLK */
+ 0x038 MUX_M1 /* SPI1_DI */
+ 0x03c MUX_M1 /* SPI1_DO */
+ 0x040 MUX_M1 /* SPI1_CS_N */
+ >;
+ };
+
+ uart0_pmx_func: uart0_pmx_func {
+ pinctrl-single,pins = <
+ 0x0cc MUX_M2 /* UART0_RXD */
+ 0x0d0 MUX_M2 /* UART0_TXD */
+ 0x0d4 MUX_M2 /* UART0_RXD_M */
+ 0x0d8 MUX_M2 /* UART0_TXD_M */
+ >;
+ };
+
+ uart1_pmx_func: uart1_pmx_func {
+ pinctrl-single,pins = <
+ 0x0b0 MUX_M2 /* UART1_CTS_N */
+ 0x0b4 MUX_M2 /* UART1_RTS_N */
+ 0x0a8 MUX_M2 /* UART1_RXD */
+ 0x0ac MUX_M2 /* UART1_TXD */
+ >;
+ };
+
+ uart2_pmx_func: uart2_pmx_func {
+ pinctrl-single,pins = <
+ 0x0bc MUX_M2 /* UART2_CTS_N */
+ 0x0c0 MUX_M2 /* UART2_RTS_N */
+ 0x0c8 MUX_M2 /* UART2_RXD */
+ 0x0c4 MUX_M2 /* UART2_TXD */
+ >;
+ };
+
+ uart3_pmx_func: uart3_pmx_func {
+ pinctrl-single,pins = <
+ 0x0dc MUX_M1 /* UART3_CTS_N */
+ 0x0e0 MUX_M1 /* UART3_RTS_N */
+ 0x0e4 MUX_M1 /* UART3_RXD */
+ 0x0e8 MUX_M1 /* UART3_TXD */
+ >;
+ };
+
+ uart4_pmx_func: uart4_pmx_func {
+ pinctrl-single,pins = <
+ 0x0ec MUX_M1 /* UART4_CTS_N */
+ 0x0f0 MUX_M1 /* UART4_RTS_N */
+ 0x0f4 MUX_M1 /* UART4_RXD */
+ 0x0f8 MUX_M1 /* UART4_TXD */
+ >;
+ };
+
+ uart5_pmx_func: uart5_pmx_func {
+ pinctrl-single,pins = <
+ 0x0c4 MUX_M3 /* UART5_CTS_N */
+ 0x0c8 MUX_M3 /* UART5_RTS_N */
+ 0x0bc MUX_M3 /* UART5_RXD */
+ 0x0c0 MUX_M3 /* UART5_TXD */
+ >;
+ };
+
+ uart6_pmx_func: uart6_pmx_func {
+ pinctrl-single,pins = <
+ 0x0cc MUX_M1 /* UART6_CTS_N */
+ 0x0d0 MUX_M1 /* UART6_RTS_N */
+ 0x0d4 MUX_M1 /* UART6_RXD */
+ 0x0d8 MUX_M1 /* UART6_TXD */
+ >;
+ };
+ };
+
+ /* [IOMG_MMC0_000, IOMG_MMC0_005] */
+ pmx1: pinmux@ff37e000 {
+ compatible = "pinctrl-single";
+ reg = <0x0 0xff37e000 0x0 0x18>;
+ #gpio-range-cells = <0x3>;
+ #pinctrl-cells = <1>;
+ pinctrl-single,register-width = <0x20>;
+ pinctrl-single,function-mask = <0x7>;
+ /* pin base, nr pins & gpio function */
+ pinctrl-single,gpio-range = <&range 0 6 0>;
+
+ sdcard_pmx_func: sdcard_pmx_func {
+ pinctrl-single,pins = <
+ 0x000 MUX_M1 /* SD_CLK */
+ 0x004 MUX_M1 /* SD_CMD */
+ 0x008 MUX_M1 /* SD_DATA0 */
+ 0x00c MUX_M1 /* SD_DATA1 */
+ 0x010 MUX_M1 /* SD_DATA2 */
+ 0x014 MUX_M1 /* SD_DATA3 */
+ >;
+ };
+ };
+
+ /* [IOMG_FIX_000, IOMG_FIX_011] */
+ pmx2: pinmux@ff3b6000 {
+ compatible = "pinctrl-single";
+ reg = <0x0 0xff3b6000 0x0 0x30>;
+ #pinctrl-cells = <1>;
+ #gpio-range-cells = <0x3>;
+ pinctrl-single,register-width = <0x20>;
+ pinctrl-single,function-mask = <0x7>;
+ /* pin base, nr pins & gpio function */
+ pinctrl-single,gpio-range = <&range 0 12 0>;
+
+ spi3_pmx_func: spi3_pmx_func {
+ pinctrl-single,pins = <
+ 0x008 MUX_M1 /* SPI3_CLK */
+ 0x00c MUX_M1 /* SPI3_DI */
+ 0x010 MUX_M1 /* SPI3_DO */
+ 0x014 MUX_M1 /* SPI3_CS0_N */
+ >;
+ };
+ };
+
+ /* [IOMG_MMC1_000, IOMG_MMC1_005] */
+ pmx3: pinmux@ff3fd000 {
+ compatible = "pinctrl-single";
+ reg = <0x0 0xff3fd000 0x0 0x18>;
+ #pinctrl-cells = <1>;
+ #gpio-range-cells = <0x3>;
+ pinctrl-single,register-width = <0x20>;
+ pinctrl-single,function-mask = <0x7>;
+ /* pin base, nr pins & gpio function */
+ pinctrl-single,gpio-range = <&range 0 6 0>;
+
+ sdio_pmx_func: sdio_pmx_func {
+ pinctrl-single,pins = <
+ 0x000 MUX_M1 /* SDIO_CLK */
+ 0x004 MUX_M1 /* SDIO_CMD */
+ 0x008 MUX_M1 /* SDIO_DATA0 */
+ 0x00c MUX_M1 /* SDIO_DATA1 */
+ 0x010 MUX_M1 /* SDIO_DATA2 */
+ 0x014 MUX_M1 /* SDIO_DATA3 */
+ >;
+ };
+ };
+
+ /* [IOMG_AO_000, IOMG_AO_041] */
+ pmx4: pinmux@fff11000 {
+ compatible = "pinctrl-single";
+ reg = <0x0 0xfff11000 0x0 0xa8>;
+ #pinctrl-cells = <1>;
+ #gpio-range-cells = <0x3>;
+ pinctrl-single,register-width = <0x20>;
+ pinctrl-single,function-mask = <0x7>;
+ /* pin base in node, nr pins & gpio function */
+ pinctrl-single,gpio-range = <&range 0 42 0>;
+
+ i2s2_pmx_func: i2s2_pmx_func {
+ pinctrl-single,pins = <
+ 0x044 MUX_M1 /* I2S2_DI */
+ 0x048 MUX_M1 /* I2S2_DO */
+ 0x04c MUX_M1 /* I2S2_XCLK */
+ 0x050 MUX_M1 /* I2S2_XFS */
+ >;
+ };
+
+ slimbus_pmx_func: slimbus_pmx_func {
+ pinctrl-single,pins = <
+ 0x02c MUX_M1 /* SLIMBUS_CLK */
+ 0x030 MUX_M1 /* SLIMBUS_DATA */
+ >;
+ };
+
+ i2c0_pmx_func: i2c0_pmx_func {
+ pinctrl-single,pins = <
+ 0x014 MUX_M1 /* I2C0_SCL */
+ 0x018 MUX_M1 /* I2C0_SDA */
+ >;
+ };
+
+ i2c1_pmx_func: i2c1_pmx_func {
+ pinctrl-single,pins = <
+ 0x01c MUX_M1 /* I2C1_SCL */
+ 0x020 MUX_M1 /* I2C1_SDA */
+ >;
+ };
+
+ i2c2_pmx_func: i2c2_pmx_func {
+ pinctrl-single,pins = <
+ 0x024 MUX_M1 /* I2C2_SCL */
+ 0x028 MUX_M1 /* I2C2_SDA */
+ >;
+ };
+
+ i2c7_pmx_func: i2c7_pmx_func {
+ pinctrl-single,pins = <
+ 0x024 MUX_M3 /* I2C7_SCL */
+ 0x028 MUX_M3 /* I2C7_SDA */
+ >;
+ };
+
+ spi2_pmx_func: spi2_pmx_func {
+ pinctrl-single,pins = <
+ 0x08c MUX_M1 /* SPI2_CLK */
+ 0x090 MUX_M1 /* SPI2_DI */
+ 0x094 MUX_M1 /* SPI2_DO */
+ 0x098 MUX_M1 /* SPI2_CS0_N */
+ >;
+ };
+
+ spi4_pmx_func: spi4_pmx_func {
+ pinctrl-single,pins = <
+ 0x08c MUX_M4 /* SPI4_CLK */
+ 0x090 MUX_M4 /* SPI4_DI */
+ 0x094 MUX_M4 /* SPI4_DO */
+ 0x098 MUX_M4 /* SPI4_CS0_N */
+ >;
+ };
+
+ i2s0_pmx_func: i2s0_pmx_func {
+ pinctrl-single,pins = <
+ 0x034 MUX_M1 /* I2S0_DI */
+ 0x038 MUX_M1 /* I2S0_DO */
+ 0x03c MUX_M1 /* I2S0_XCLK */
+ 0x040 MUX_M1 /* I2S0_XFS */
+ >;
+ };
+ };
+ };
+};
--
2.11.0-rc2
^ permalink raw reply related
* [PATCH 02/11] [media] s5p-mfc: Adding initial support for MFC v10.10
From: Smitha T Murthy @ 2017-01-18 10:02 UTC (permalink / raw)
To: linux-arm-kernel, linux-media, linux-kernel
Cc: devicetree, a.hajda, pankaj.dubey, kamil, krzk, jtp.park,
kyungmin.park, Rob Herring, s.nawrocki, Smitha T Murthy, mchehab,
m.szyprowski
In-Reply-To: <1484733729-25371-1-git-send-email-smitha.t@samsung.com>
Adding the support for MFC v10.10, with new register file and
necessary hw control, decoder, encoder and structural changes.
CC: Rob Herring <robh+dt@kernel.org>
CC: devicetree@vger.kernel.org
Signed-off-by: Smitha T Murthy <smitha.t@samsung.com>
---
.../devicetree/bindings/media/s5p-mfc.txt | 1 +
drivers/media/platform/s5p-mfc/regs-mfc-v10.h | 36 ++++++++++++++++
drivers/media/platform/s5p-mfc/s5p_mfc.c | 30 +++++++++++++
drivers/media/platform/s5p-mfc/s5p_mfc_common.h | 4 +-
drivers/media/platform/s5p-mfc/s5p_mfc_ctrl.c | 4 ++
drivers/media/platform/s5p-mfc/s5p_mfc_dec.c | 44 +++++++++++---------
drivers/media/platform/s5p-mfc/s5p_mfc_enc.c | 21 +++++----
drivers/media/platform/s5p-mfc/s5p_mfc_opr_v6.c | 9 +++-
drivers/media/platform/s5p-mfc/s5p_mfc_opr_v6.h | 2 +
9 files changed, 118 insertions(+), 33 deletions(-)
create mode 100644 drivers/media/platform/s5p-mfc/regs-mfc-v10.h
diff --git a/Documentation/devicetree/bindings/media/s5p-mfc.txt b/Documentation/devicetree/bindings/media/s5p-mfc.txt
index 2c90128..b70c613 100644
--- a/Documentation/devicetree/bindings/media/s5p-mfc.txt
+++ b/Documentation/devicetree/bindings/media/s5p-mfc.txt
@@ -13,6 +13,7 @@ Required properties:
(c) "samsung,mfc-v7" for MFC v7 present in Exynos5420 SoC
(d) "samsung,mfc-v8" for MFC v8 present in Exynos5800 SoC
(e) "samsung,exynos5433-mfc" for MFC v8 present in Exynos5433 SoC
+ (f) "samsung,mfc-v10" for MFC v10 present in a variant of Exynos7 SoC
- reg : Physical base address of the IP registers and length of memory
mapped region.
diff --git a/drivers/media/platform/s5p-mfc/regs-mfc-v10.h b/drivers/media/platform/s5p-mfc/regs-mfc-v10.h
new file mode 100644
index 0000000..bd671a5
--- /dev/null
+++ b/drivers/media/platform/s5p-mfc/regs-mfc-v10.h
@@ -0,0 +1,36 @@
+/*
+ * Register definition file for Samsung MFC V10.x Interface (FIMV) driver
+ *
+ * Copyright (c) 2017 Samsung Electronics Co., Ltd.
+ * http://www.samsung.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.
+ */
+
+#ifndef _REGS_MFC_V10_H
+#define _REGS_MFC_V10_H
+
+#include <linux/sizes.h>
+#include "regs-mfc-v8.h"
+
+/* MFCv10 register definitions*/
+#define S5P_FIMV_MFC_CLOCK_OFF_V10 0x7120
+#define S5P_FIMV_MFC_STATE_V10 0x7124
+
+/* MFCv10 Context buffer sizes */
+#define MFC_CTX_BUF_SIZE_V10 (30 * SZ_1K) /* 30KB */
+#define MFC_H264_DEC_CTX_BUF_SIZE_V10 (2 * SZ_1M) /* 2MB */
+#define MFC_OTHER_DEC_CTX_BUF_SIZE_V10 (20 * SZ_1K) /* 20KB */
+#define MFC_H264_ENC_CTX_BUF_SIZE_V10 (100 * SZ_1K) /* 100KB */
+#define MFC_OTHER_ENC_CTX_BUF_SIZE_V10 (15 * SZ_1K) /* 15KB */
+
+/* MFCv10 variant defines */
+#define MAX_FW_SIZE_V10 (SZ_1M) /* 1MB */
+#define MAX_CPB_SIZE_V10 (3 * SZ_1M) /* 3MB */
+#define MFC_VERSION_V10 0xA0
+#define MFC_NUM_PORTS_V10 1
+
+#endif /*_REGS_MFC_V10_H*/
+
diff --git a/drivers/media/platform/s5p-mfc/s5p_mfc.c b/drivers/media/platform/s5p-mfc/s5p_mfc.c
index bb0a588..a043cce 100644
--- a/drivers/media/platform/s5p-mfc/s5p_mfc.c
+++ b/drivers/media/platform/s5p-mfc/s5p_mfc.c
@@ -1542,6 +1542,33 @@ static int s5p_mfc_resume(struct device *dev)
.num_clocks = 3,
};
+static struct s5p_mfc_buf_size_v6 mfc_buf_size_v10 = {
+ .dev_ctx = MFC_CTX_BUF_SIZE_V10,
+ .h264_dec_ctx = MFC_H264_DEC_CTX_BUF_SIZE_V10,
+ .other_dec_ctx = MFC_OTHER_DEC_CTX_BUF_SIZE_V10,
+ .h264_enc_ctx = MFC_H264_ENC_CTX_BUF_SIZE_V10,
+ .other_enc_ctx = MFC_OTHER_ENC_CTX_BUF_SIZE_V10,
+};
+
+static struct s5p_mfc_buf_size buf_size_v10 = {
+ .fw = MAX_FW_SIZE_V10,
+ .cpb = MAX_CPB_SIZE_V10,
+ .priv = &mfc_buf_size_v10,
+};
+
+static struct s5p_mfc_buf_align mfc_buf_align_v10 = {
+ .base = 0,
+};
+
+static struct s5p_mfc_variant mfc_drvdata_v10 = {
+ .version = MFC_VERSION_V10,
+ .version_bit = MFC_V10_BIT,
+ .port_num = MFC_NUM_PORTS_V10,
+ .buf_size = &buf_size_v10,
+ .buf_align = &mfc_buf_align_v10,
+ .fw_name[0] = "s5p-mfc-v10.fw",
+};
+
static const struct of_device_id exynos_mfc_match[] = {
{
.compatible = "samsung,mfc-v5",
@@ -1558,6 +1585,9 @@ static int s5p_mfc_resume(struct device *dev)
}, {
.compatible = "samsung,exynos5433-mfc",
.data = &mfc_drvdata_v8_5433,
+ }, {
+ .compatible = "samsung,mfc-v10",
+ .data = &mfc_drvdata_v10,
},
{},
};
diff --git a/drivers/media/platform/s5p-mfc/s5p_mfc_common.h b/drivers/media/platform/s5p-mfc/s5p_mfc_common.h
index b45d18c..1941c63 100644
--- a/drivers/media/platform/s5p-mfc/s5p_mfc_common.h
+++ b/drivers/media/platform/s5p-mfc/s5p_mfc_common.h
@@ -23,7 +23,7 @@
#include <media/v4l2-ioctl.h>
#include <media/videobuf2-v4l2.h>
#include "regs-mfc.h"
-#include "regs-mfc-v8.h"
+#include "regs-mfc-v10.h"
#define S5P_MFC_NAME "s5p-mfc"
@@ -723,11 +723,13 @@ struct mfc_control {
#define IS_MFCV6_PLUS(dev) (dev->variant->version >= 0x60 ? 1 : 0)
#define IS_MFCV7_PLUS(dev) (dev->variant->version >= 0x70 ? 1 : 0)
#define IS_MFCV8_PLUS(dev) (dev->variant->version >= 0x80 ? 1 : 0)
+#define IS_MFCV10(dev) (dev->variant->version >= 0xA0 ? 1 : 0)
#define MFC_V5_BIT BIT(0)
#define MFC_V6_BIT BIT(1)
#define MFC_V7_BIT BIT(2)
#define MFC_V8_BIT BIT(3)
+#define MFC_V10_BIT BIT(5)
#endif /* S5P_MFC_COMMON_H_ */
diff --git a/drivers/media/platform/s5p-mfc/s5p_mfc_ctrl.c b/drivers/media/platform/s5p-mfc/s5p_mfc_ctrl.c
index 484af6b..0ded23c 100644
--- a/drivers/media/platform/s5p-mfc/s5p_mfc_ctrl.c
+++ b/drivers/media/platform/s5p-mfc/s5p_mfc_ctrl.c
@@ -267,6 +267,10 @@ int s5p_mfc_init_hw(struct s5p_mfc_dev *dev)
}
else
mfc_write(dev, 0x3ff, S5P_FIMV_SW_RESET);
+
+ if (IS_MFCV10(dev))
+ mfc_write(dev, 0x0, S5P_FIMV_MFC_CLOCK_OFF_V10);
+
mfc_debug(2, "Will now wait for completion of firmware transfer\n");
if (s5p_mfc_wait_for_done_dev(dev, S5P_MFC_R2H_CMD_FW_STATUS_RET)) {
mfc_err("Failed to load firmware\n");
diff --git a/drivers/media/platform/s5p-mfc/s5p_mfc_dec.c b/drivers/media/platform/s5p-mfc/s5p_mfc_dec.c
index 0ec2928..784b28e 100644
--- a/drivers/media/platform/s5p-mfc/s5p_mfc_dec.c
+++ b/drivers/media/platform/s5p-mfc/s5p_mfc_dec.c
@@ -54,7 +54,8 @@
.codec_mode = S5P_MFC_CODEC_NONE,
.type = MFC_FMT_RAW,
.num_planes = 2,
- .versions = MFC_V6_BIT | MFC_V7_BIT | MFC_V8_BIT,
+ .versions = MFC_V6_BIT | MFC_V7_BIT | MFC_V8_BIT |
+ MFC_V10_BIT,
},
{
.name = "4:2:0 2 Planes Y/CrCb",
@@ -62,7 +63,8 @@
.codec_mode = S5P_MFC_CODEC_NONE,
.type = MFC_FMT_RAW,
.num_planes = 2,
- .versions = MFC_V6_BIT | MFC_V7_BIT | MFC_V8_BIT,
+ .versions = MFC_V6_BIT | MFC_V7_BIT | MFC_V8_BIT |
+ MFC_V10_BIT,
},
{
.name = "H264 Encoded Stream",
@@ -70,8 +72,8 @@
.codec_mode = S5P_MFC_CODEC_H264_DEC,
.type = MFC_FMT_DEC,
.num_planes = 1,
- .versions = MFC_V5_BIT | MFC_V6_BIT | MFC_V7_BIT |
- MFC_V8_BIT,
+ .versions = MFC_V5_BIT | MFC_V6_BIT |
+ MFC_V7_BIT | MFC_V8_BIT | MFC_V10_BIT,
},
{
.name = "H264/MVC Encoded Stream",
@@ -79,7 +81,8 @@
.codec_mode = S5P_MFC_CODEC_H264_MVC_DEC,
.type = MFC_FMT_DEC,
.num_planes = 1,
- .versions = MFC_V6_BIT | MFC_V7_BIT | MFC_V8_BIT,
+ .versions = MFC_V6_BIT | MFC_V7_BIT | MFC_V8_BIT |
+ MFC_V10_BIT,
},
{
.name = "H263 Encoded Stream",
@@ -87,8 +90,8 @@
.codec_mode = S5P_MFC_CODEC_H263_DEC,
.type = MFC_FMT_DEC,
.num_planes = 1,
- .versions = MFC_V5_BIT | MFC_V6_BIT | MFC_V7_BIT |
- MFC_V8_BIT,
+ .versions = MFC_V5_BIT | MFC_V6_BIT |
+ MFC_V7_BIT | MFC_V8_BIT | MFC_V10_BIT,
},
{
.name = "MPEG1 Encoded Stream",
@@ -96,8 +99,8 @@
.codec_mode = S5P_MFC_CODEC_MPEG2_DEC,
.type = MFC_FMT_DEC,
.num_planes = 1,
- .versions = MFC_V5_BIT | MFC_V6_BIT | MFC_V7_BIT |
- MFC_V8_BIT,
+ .versions = MFC_V5_BIT | MFC_V6_BIT |
+ MFC_V7_BIT | MFC_V8_BIT | MFC_V10_BIT,
},
{
.name = "MPEG2 Encoded Stream",
@@ -105,8 +108,8 @@
.codec_mode = S5P_MFC_CODEC_MPEG2_DEC,
.type = MFC_FMT_DEC,
.num_planes = 1,
- .versions = MFC_V5_BIT | MFC_V6_BIT | MFC_V7_BIT |
- MFC_V8_BIT,
+ .versions = MFC_V5_BIT | MFC_V6_BIT |
+ MFC_V7_BIT | MFC_V8_BIT | MFC_V10_BIT,
},
{
.name = "MPEG4 Encoded Stream",
@@ -114,8 +117,8 @@
.codec_mode = S5P_MFC_CODEC_MPEG4_DEC,
.type = MFC_FMT_DEC,
.num_planes = 1,
- .versions = MFC_V5_BIT | MFC_V6_BIT | MFC_V7_BIT |
- MFC_V8_BIT,
+ .versions = MFC_V5_BIT | MFC_V6_BIT |
+ MFC_V7_BIT | MFC_V8_BIT | MFC_V10_BIT,
},
{
.name = "XviD Encoded Stream",
@@ -123,8 +126,8 @@
.codec_mode = S5P_MFC_CODEC_MPEG4_DEC,
.type = MFC_FMT_DEC,
.num_planes = 1,
- .versions = MFC_V5_BIT | MFC_V6_BIT | MFC_V7_BIT |
- MFC_V8_BIT,
+ .versions = MFC_V5_BIT | MFC_V6_BIT |
+ MFC_V7_BIT | MFC_V8_BIT | MFC_V10_BIT,
},
{
.name = "VC1 Encoded Stream",
@@ -132,8 +135,8 @@
.codec_mode = S5P_MFC_CODEC_VC1_DEC,
.type = MFC_FMT_DEC,
.num_planes = 1,
- .versions = MFC_V5_BIT | MFC_V6_BIT | MFC_V7_BIT |
- MFC_V8_BIT,
+ .versions = MFC_V5_BIT | MFC_V6_BIT |
+ MFC_V7_BIT | MFC_V8_BIT | MFC_V10_BIT,
},
{
.name = "VC1 RCV Encoded Stream",
@@ -141,8 +144,8 @@
.codec_mode = S5P_MFC_CODEC_VC1RCV_DEC,
.type = MFC_FMT_DEC,
.num_planes = 1,
- .versions = MFC_V5_BIT | MFC_V6_BIT | MFC_V7_BIT |
- MFC_V8_BIT,
+ .versions = MFC_V5_BIT | MFC_V6_BIT |
+ MFC_V7_BIT | MFC_V8_BIT | MFC_V10_BIT,
},
{
.name = "VP8 Encoded Stream",
@@ -150,7 +153,8 @@
.codec_mode = S5P_MFC_CODEC_VP8_DEC,
.type = MFC_FMT_DEC,
.num_planes = 1,
- .versions = MFC_V6_BIT | MFC_V7_BIT | MFC_V8_BIT,
+ .versions = MFC_V6_BIT | MFC_V7_BIT | MFC_V8_BIT |
+ MFC_V10_BIT,
},
};
diff --git a/drivers/media/platform/s5p-mfc/s5p_mfc_enc.c b/drivers/media/platform/s5p-mfc/s5p_mfc_enc.c
index e39d9e0..9042378 100644
--- a/drivers/media/platform/s5p-mfc/s5p_mfc_enc.c
+++ b/drivers/media/platform/s5p-mfc/s5p_mfc_enc.c
@@ -57,8 +57,8 @@
.codec_mode = S5P_MFC_CODEC_NONE,
.type = MFC_FMT_RAW,
.num_planes = 2,
- .versions = MFC_V5_BIT | MFC_V6_BIT | MFC_V7_BIT |
- MFC_V8_BIT,
+ .versions = MFC_V5_BIT | MFC_V6_BIT |
+ MFC_V7_BIT | MFC_V8_BIT | MFC_V10_BIT,
},
{
.name = "4:2:0 2 Planes Y/CrCb",
@@ -66,7 +66,8 @@
.codec_mode = S5P_MFC_CODEC_NONE,
.type = MFC_FMT_RAW,
.num_planes = 2,
- .versions = MFC_V6_BIT | MFC_V7_BIT | MFC_V8_BIT,
+ .versions = MFC_V6_BIT | MFC_V7_BIT | MFC_V8_BIT |
+ MFC_V10_BIT,
},
{
.name = "H264 Encoded Stream",
@@ -74,8 +75,8 @@
.codec_mode = S5P_MFC_CODEC_H264_ENC,
.type = MFC_FMT_ENC,
.num_planes = 1,
- .versions = MFC_V5_BIT | MFC_V6_BIT | MFC_V7_BIT |
- MFC_V8_BIT,
+ .versions = MFC_V5_BIT | MFC_V6_BIT |
+ MFC_V7_BIT | MFC_V8_BIT | MFC_V10_BIT,
},
{
.name = "MPEG4 Encoded Stream",
@@ -83,8 +84,8 @@
.codec_mode = S5P_MFC_CODEC_MPEG4_ENC,
.type = MFC_FMT_ENC,
.num_planes = 1,
- .versions = MFC_V5_BIT | MFC_V6_BIT | MFC_V7_BIT |
- MFC_V8_BIT,
+ .versions = MFC_V5_BIT | MFC_V6_BIT |
+ MFC_V7_BIT | MFC_V8_BIT | MFC_V10_BIT,
},
{
.name = "H263 Encoded Stream",
@@ -92,8 +93,8 @@
.codec_mode = S5P_MFC_CODEC_H263_ENC,
.type = MFC_FMT_ENC,
.num_planes = 1,
- .versions = MFC_V5_BIT | MFC_V6_BIT | MFC_V7_BIT |
- MFC_V8_BIT,
+ .versions = MFC_V5_BIT | MFC_V6_BIT |
+ MFC_V7_BIT | MFC_V8_BIT | MFC_V10_BIT,
},
{
.name = "VP8 Encoded Stream",
@@ -101,7 +102,7 @@
.codec_mode = S5P_MFC_CODEC_VP8_ENC,
.type = MFC_FMT_ENC,
.num_planes = 1,
- .versions = MFC_V7_BIT | MFC_V8_BIT,
+ .versions = MFC_V7_BIT | MFC_V8_BIT | MFC_V10_BIT,
},
};
diff --git a/drivers/media/platform/s5p-mfc/s5p_mfc_opr_v6.c b/drivers/media/platform/s5p-mfc/s5p_mfc_opr_v6.c
index 0572521..63dce5a 100644
--- a/drivers/media/platform/s5p-mfc/s5p_mfc_opr_v6.c
+++ b/drivers/media/platform/s5p-mfc/s5p_mfc_opr_v6.c
@@ -358,6 +358,7 @@ static int calc_plane(int width, int height)
static void s5p_mfc_dec_calc_dpb_size_v6(struct s5p_mfc_ctx *ctx)
{
+ struct s5p_mfc_dev *dev = ctx->dev;
ctx->buf_width = ALIGN(ctx->img_width, S5P_FIMV_NV12MT_HALIGN_V6);
ctx->buf_height = ALIGN(ctx->img_height, S5P_FIMV_NV12MT_VALIGN_V6);
mfc_debug(2, "SEQ Done: Movie dimensions %dx%d,\n"
@@ -374,8 +375,12 @@ static void s5p_mfc_dec_calc_dpb_size_v6(struct s5p_mfc_ctx *ctx)
if (ctx->codec_mode == S5P_MFC_CODEC_H264_DEC ||
ctx->codec_mode == S5P_MFC_CODEC_H264_MVC_DEC) {
- ctx->mv_size = S5P_MFC_DEC_MV_SIZE_V6(ctx->img_width,
- ctx->img_height);
+ if (IS_MFCV10(dev))
+ ctx->mv_size = S5P_MFC_DEC_MV_SIZE_V10(ctx->img_width,
+ ctx->img_height);
+ else
+ ctx->mv_size = S5P_MFC_DEC_MV_SIZE_V6(ctx->img_width,
+ ctx->img_height);
ctx->mv_size = ALIGN(ctx->mv_size, 16);
} else {
ctx->mv_size = 0;
diff --git a/drivers/media/platform/s5p-mfc/s5p_mfc_opr_v6.h b/drivers/media/platform/s5p-mfc/s5p_mfc_opr_v6.h
index 16a7b1d..fcc2368 100644
--- a/drivers/media/platform/s5p-mfc/s5p_mfc_opr_v6.h
+++ b/drivers/media/platform/s5p-mfc/s5p_mfc_opr_v6.h
@@ -24,6 +24,8 @@
#define MB_HEIGHT(y_size) DIV_ROUND_UP(y_size, 16)
#define S5P_MFC_DEC_MV_SIZE_V6(x, y) (MB_WIDTH(x) * \
(((MB_HEIGHT(y)+1)/2)*2) * 64 + 128)
+#define S5P_MFC_DEC_MV_SIZE_V10(x, y) (MB_WIDTH(x) * \
+ (((MB_HEIGHT(y)+1)/2)*2) * 64 + 512)
/* Definition */
#define ENC_MULTI_SLICE_MB_MAX ((1 << 30) - 1)
--
1.7.2.3
^ permalink raw reply related
* Re: [PATCH] ARM: davinci: da850-evm: fix read access to SPI flash
From: Sekhar Nori @ 2017-01-18 9:58 UTC (permalink / raw)
To: Kevin Hilman, Fabien Parent
Cc: mark.rutland, devicetree, robh+dt, linux-kernel, linux-arm-kernel
In-Reply-To: <m237gh2ozw.fsf@baylibre.com>
On Wednesday 18 January 2017 05:55 AM, Kevin Hilman wrote:
> Fabien Parent <fparent@baylibre.com> writes:
>
>> Read access to the SPI flash are broken on da850-evm, i.e. the data
>> read is not what is actually programmed on the flash.
>> According to the datasheet for the M25P64 part present on the da850-evm,
>> if the SPI frequency is higher than 20MHz then the READ command is not
>> usable anymore and only the FAST_READ command can be used to read data.
>>
>> This commit specifies in the DTS that we should use FAST_READ command
>> instead of the READ command.
>>
>> Signed-off-by: Fabien Parent <fparent@baylibre.com>
>
> Tested on da850-evm on top of v4.10-rc3. This gets the DT boot
> functionatliy in line with the legacy (board-file) boot.
>
> Tested-by: Kevin Hilman <khilman@baylibre.com>
Applied with Kevin's Tested-by and also marked for stable. Sending pull
request for v4.10-rc shortly.
Thanks,
Sekhar
^ permalink raw reply
* Re: [PATCH v7 3/8] PWM: add pwm-stm32 DT bindings
From: Benjamin Gaignard @ 2017-01-18 9:42 UTC (permalink / raw)
To: Thierry Reding
Cc: Lee Jones, robh+dt, Mark Rutland, Alexandre Torgue, devicetree,
Linux Kernel Mailing List, Linux PWM List, Jonathan Cameron,
Hartmut Knaack, Lars-Peter Clausen, Peter Meerwald-Stadler,
linux-iio, linux-arm-kernel, Fabrice Gasnier, Gerald Baeza,
Arnaud Pouliquen, Linus Walleij, Linaro Kernel Mailman List,
Benjamin Gaignard
In-Reply-To: <20170118092021.GE18989@ulmo.ba.sec>
2017-01-18 10:20 GMT+01:00 Thierry Reding <thierry.reding@gmail.com>:
> On Thu, Jan 05, 2017 at 10:25:39AM +0100, Benjamin Gaignard wrote:
>> Define bindings for pwm-stm32
>>
>> version 6:
>> - change st,breakinput parameter format to make it usuable on stm32f7 too.
>>
>> version 2:
>> - use parameters instead of compatible of handle the hardware configuration
>>
>> Signed-off-by: Benjamin Gaignard <benjamin.gaignard@st.com>
>> ---
>> .../devicetree/bindings/pwm/pwm-stm32.txt | 33 ++++++++++++++++++++++
>> 1 file changed, 33 insertions(+)
>> create mode 100644 Documentation/devicetree/bindings/pwm/pwm-stm32.txt
>>
>> diff --git a/Documentation/devicetree/bindings/pwm/pwm-stm32.txt b/Documentation/devicetree/bindings/pwm/pwm-stm32.txt
>> new file mode 100644
>> index 0000000..866f222
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/pwm/pwm-stm32.txt
>> @@ -0,0 +1,33 @@
>> +STMicroelectronics STM32 Timers PWM bindings
>> +
>> +Must be a sub-node of an STM32 Timers device tree node.
>> +See ../mfd/stm32-timers.txt for details about the parent node.
>> +
>> +Required parameters:
>> +- compatible: Must be "st,stm32-pwm".
>> +- pinctrl-names: Set to "default".
>> +- pinctrl-0: List of phandles pointing to pin configuration nodes for PWM module.
>> + For Pinctrl properties see ../pinctrl/pinctrl-bindings.txt
>> +
>> +Optional parameters:
>> +- st,breakinput: Arrays of three u32 <index level filter> to describe break input configurations.
>> + "index" indicates on which break input the configuration should be applied.
>
> It might be useful to specify what the valid values are for the break
> input index.
It could 0 and 1, I will add this information.
>
> Also, u32 is kind of a Linuxism, perhaps "Arrays of three cells"? Also,
> does this mean there can be multiple entries? Such as 6 cells for two
> configurations? What's the maximum number of such configurations?
>
> If it's possible to specify multiple configurations, maybe a slightly
> clearer wording would be: "One or more <index level filter> triplets to
> describe..."
>
You can have one configuration per index so I will rephrase it like that:
One or two <index level filter> to describe break input configurations.
"index" indicates on which break input (0 or 1 ) the configuration
should be applied.
>> + "level" gives the active level (0=low or 1=high) for this configuration.
>
> So how does this work exactly? "level" specifies the output level if the
> filter value is matched?
No it specify on which input level the break event is generated
>
>> + "filter" gives the filtering value to be applied.
>
> Is this a single value at which "level" will be applied? Or is it an
> upper/lower bound that can be used to restrict the output to "level" if
> the signal goes beyond/below a certain threshold?
Very very basically filter is more a debounce value set on the signal
to avoid glitches.
The goal of break input feature is to stop PWM generation in hardware
errors failure case.
For a more completed description you can read "using break input
function" (starting page 645) in this doc:
http://www.st.com/content/ccc/resource/technical/document/reference_manual/c5/cf/ef/52/c0/f1/4b/fa/DM00124865.pdf/files/DM00124865.pdf/jcr:content/translations/en.DM00124865.pdf
>
> Maybe an example would clarify this. Or perhaps a reference to a manual
> where a more in-depth description of this functionality can be found.
>
> Thierry
--
Benjamin Gaignard
Graphic Study Group
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
^ permalink raw reply
* [RESEND PATCH 2/2] arm: dts: mt2701: Add i2c device node
From: Jun Gao @ 2017-01-18 9:41 UTC (permalink / raw)
To: Wolfram Sang, Matthias Brugger
Cc: srv_heupstream, devicetree, linux-i2c, linux-arm-kernel,
linux-kernel, linux-mediatek, Jun Gao
In-Reply-To: <1484732461-13594-1-git-send-email-jun.gao@mediatek.com>
From: Jun Gao <jun.gao@mediatek.com>
Add i2c device node for MT2701.
Signed-off-by: Jun Gao <jun.gao@mediatek.com>
---
arch/arm/boot/dts/mt2701-evb.dts | 44 ++++++++++++++++++++++++++++++++++++++
arch/arm/boot/dts/mt2701.dtsi | 42 ++++++++++++++++++++++++++++++++++++
2 files changed, 86 insertions(+)
diff --git a/arch/arm/boot/dts/mt2701-evb.dts b/arch/arm/boot/dts/mt2701-evb.dts
index 082ca88..a908e94 100644
--- a/arch/arm/boot/dts/mt2701-evb.dts
+++ b/arch/arm/boot/dts/mt2701-evb.dts
@@ -24,6 +24,50 @@
};
};
+&i2c0 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&i2c0_pins_a>;
+ status = "okay";
+};
+
+&i2c1 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&i2c1_pins_a>;
+ status = "okay";
+};
+
+&i2c2 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&i2c2_pins_a>;
+ status = "okay";
+};
+
+&pio {
+ i2c0_pins_a: i2c0@0 {
+ pins1 {
+ pinmux = <MT2701_PIN_75_SDA0__FUNC_SDA0>,
+ <MT2701_PIN_76_SCL0__FUNC_SCL0>;
+ bias-disable;
+ };
+ };
+
+ i2c1_pins_a: i2c1@0 {
+ pins1 {
+ pinmux = <MT2701_PIN_57_SDA1__FUNC_SDA1>,
+ <MT2701_PIN_58_SCL1__FUNC_SCL1>;
+ bias-disable;
+ };
+ };
+
+ i2c2_pins_a: i2c2@0 {
+ pins1 {
+ pinmux = <MT2701_PIN_77_SDA2__FUNC_SDA2>,
+ <MT2701_PIN_78_SCL2__FUNC_SCL2>;
+ bias-disable;
+ };
+ };
+};
+
&uart0 {
status = "okay";
};
diff --git a/arch/arm/boot/dts/mt2701.dtsi b/arch/arm/boot/dts/mt2701.dtsi
index bdf8954..0d1539f 100644
--- a/arch/arm/boot/dts/mt2701.dtsi
+++ b/arch/arm/boot/dts/mt2701.dtsi
@@ -227,6 +227,48 @@
status = "disabled";
};
+ i2c0: i2c@11007000 {
+ compatible = "mediatek,mt2701-i2c",
+ "mediatek,mt6577-i2c";
+ reg = <0 0x11007000 0 0x70>,
+ <0 0x11000200 0 0x80>;
+ interrupts = <GIC_SPI 44 IRQ_TYPE_LEVEL_LOW>;
+ clock-div = <16>;
+ clocks = <&pericfg CLK_PERI_I2C0>, <&pericfg CLK_PERI_AP_DMA>;
+ clock-names = "main", "dma";
+ #address-cells = <1>;
+ #size-cells = <0>;
+ status = "disabled";
+ };
+
+ i2c1: i2c@11008000 {
+ compatible = "mediatek,mt2701-i2c",
+ "mediatek,mt6577-i2c";
+ reg = <0 0x11008000 0 0x70>,
+ <0 0x11000280 0 0x80>;
+ interrupts = <GIC_SPI 45 IRQ_TYPE_LEVEL_LOW>;
+ clock-div = <16>;
+ clocks = <&pericfg CLK_PERI_I2C1>, <&pericfg CLK_PERI_AP_DMA>;
+ clock-names = "main", "dma";
+ #address-cells = <1>;
+ #size-cells = <0>;
+ status = "disabled";
+ };
+
+ i2c2: i2c@11009000 {
+ compatible = "mediatek,mt2701-i2c",
+ "mediatek,mt6577-i2c";
+ reg = <0 0x11009000 0 0x70>,
+ <0 0x11000300 0 0x80>;
+ interrupts = <GIC_SPI 46 IRQ_TYPE_LEVEL_LOW>;
+ clock-div = <16>;
+ clocks = <&pericfg CLK_PERI_I2C2>, <&pericfg CLK_PERI_AP_DMA>;
+ clock-names = "main", "dma";
+ #address-cells = <1>;
+ #size-cells = <0>;
+ status = "disabled";
+ };
+
mmsys: syscon@14000000 {
compatible = "mediatek,mt2701-mmsys", "syscon";
reg = <0 0x14000000 0 0x1000>;
--
1.7.9.5
^ permalink raw reply related
* [RESEND PATCH 1/2] Documentation: devicetree: Add i2c binding for mediatek MT2701 Soc Platform
From: Jun Gao @ 2017-01-18 9:41 UTC (permalink / raw)
To: Wolfram Sang, Matthias Brugger
Cc: devicetree, srv_heupstream, Jun Gao, linux-kernel, linux-mediatek,
linux-i2c, linux-arm-kernel
In-Reply-To: <1484732461-13594-1-git-send-email-jun.gao@mediatek.com>
From: Jun Gao <jun.gao@mediatek.com>
This add i2c DT binding to i2c-mt6577.txt for MT2701.
Signed-off-by: Jun Gao <jun.gao@mediatek.com>
---
.../devicetree/bindings/i2c/i2c-mt6577.txt | 11 ++++++-----
1 file changed, 6 insertions(+), 5 deletions(-)
diff --git a/Documentation/devicetree/bindings/i2c/i2c-mt6577.txt b/Documentation/devicetree/bindings/i2c/i2c-mt6577.txt
index 0ce6fa3..ef22ecf 100644
--- a/Documentation/devicetree/bindings/i2c/i2c-mt6577.txt
+++ b/Documentation/devicetree/bindings/i2c/i2c-mt6577.txt
@@ -4,11 +4,12 @@ The Mediatek's I2C controller is used to interface with I2C devices.
Required properties:
- compatible: value should be either of the following.
- (a) "mediatek,mt6577-i2c", for i2c compatible with mt6577 i2c.
- (b) "mediatek,mt6589-i2c", for i2c compatible with mt6589 i2c.
- (c) "mediatek,mt8127-i2c", for i2c compatible with mt8127 i2c.
- (d) "mediatek,mt8135-i2c", for i2c compatible with mt8135 i2c.
- (e) "mediatek,mt8173-i2c", for i2c compatible with mt8173 i2c.
+ "mediatek,mt2701-i2c", for i2c compatible with mt2701 i2c.
+ "mediatek,mt6577-i2c", for i2c compatible with mt6577 i2c.
+ "mediatek,mt6589-i2c", for i2c compatible with mt6589 i2c.
+ "mediatek,mt8127-i2c", for i2c compatible with mt8127 i2c.
+ "mediatek,mt8135-i2c", for i2c compatible with mt8135 i2c.
+ "mediatek,mt8173-i2c", for i2c compatible with mt8173 i2c.
- reg: physical base address of the controller and dma base, length of memory
mapped region.
- interrupts: interrupt number to the cpu.
--
1.7.9.5
^ permalink raw reply related
* [RESEND PATCH 0/2] Add i2c DT binding and device node for Mediatek MT2701 Soc
From: Jun Gao @ 2017-01-18 9:40 UTC (permalink / raw)
To: Wolfram Sang, Matthias Brugger
Cc: devicetree, srv_heupstream, linux-kernel, linux-mediatek,
linux-i2c, linux-arm-kernel
This patch series based on v4.10-rc2, include MT2701 i2c DT binding and device node.
Dependent on "Add clock and power domain DT nodes for Mediatek MT2701"[1].
[1] http://lists.infradead.org/pipermail/linux-mediatek/2016-December/007637.html
Jun Gao (2):
Documentation: devicetree: Add i2c binding for mediatek MT2701 Soc
Platform
arm: dts: mt2701: Add i2c device node
.../devicetree/bindings/i2c/i2c-mt6577.txt | 11 ++---
arch/arm/boot/dts/mt2701-evb.dts | 44 ++++++++++++++++++++
arch/arm/boot/dts/mt2701.dtsi | 42 +++++++++++++++++++
3 files changed, 92 insertions(+), 5 deletions(-)
--
1.7.9.5
^ permalink raw reply
* Re: [PATCH v2 12/14] ARM: dts: da850: add pinmux settings for the SATA controller
From: Sekhar Nori @ 2017-01-18 9:39 UTC (permalink / raw)
To: Bartosz Golaszewski, Kevin Hilman, Patrick Titiano,
Michael Turquette, Tejun Heo, Rob Herring, Mark Rutland,
Russell King, David Lechner
Cc: linux-ide, devicetree, linux-kernel, linux-arm-kernel
In-Reply-To: <1484655976-25382-13-git-send-email-bgolaszewski@baylibre.com>
Hi Bartosz,
On Tuesday 17 January 2017 05:56 PM, Bartosz Golaszewski wrote:
> Add pinmux sub-nodes for all muxed SATA pins.
>
> Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>
Since these are all unused at this time, we should drop adding them
until a time someone really needs these.
Thanks,
Sekhar
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox