* [PATCH] dt-bindings: net: meson-dwmac: convert to yaml
From: Neil Armstrong @ 2019-08-05 12:25 UTC (permalink / raw)
To: robh+dt
Cc: Neil Armstrong, martin.blumenstingl, devicetree, netdev,
linux-amlogic, linux-arm-kernel, linux-kernel
Now that we have the DT validation in place, let's convert the device tree
bindings for the Synopsys DWMAC Glue for Amlogic SoCs over to a YAML schemas.
Signed-off-by: Neil Armstrong <narmstrong@baylibre.com>
---
Rob,
I keep getting :
.../devicetree/bindings/net/amlogic,meson-dwmac.example.dt.yaml: ethernet@c9410000: reg: [[3376480256, 65536], [3364046144, 8]] is too long
for the example DT
and for the board DT :
../amlogic/meson-gxl-s905x-libretech-cc.dt.yaml: ethernet@c9410000: reg: [[0, 3376480256, 0, 65536, 0, 3364046144, 0, 4]] is too short
../amlogic/meson-gxl-s905x-nexbox-a95x.dt.yaml: soc: ethernet@c9410000:reg:0: [0, 3376480256, 0, 65536, 0, 3364046144, 0, 4] is too long
and I don't know how to get rid of it.
What should I do for reg ?
Neil
.../bindings/net/amlogic,meson-dwmac.yaml | 113 ++++++++++++++++++
.../devicetree/bindings/net/meson-dwmac.txt | 71 -----------
.../devicetree/bindings/net/snps,dwmac.yaml | 5 +
3 files changed, 118 insertions(+), 71 deletions(-)
create mode 100644 Documentation/devicetree/bindings/net/amlogic,meson-dwmac.yaml
delete mode 100644 Documentation/devicetree/bindings/net/meson-dwmac.txt
diff --git a/Documentation/devicetree/bindings/net/amlogic,meson-dwmac.yaml b/Documentation/devicetree/bindings/net/amlogic,meson-dwmac.yaml
new file mode 100644
index 000000000000..ae91aa9d8616
--- /dev/null
+++ b/Documentation/devicetree/bindings/net/amlogic,meson-dwmac.yaml
@@ -0,0 +1,113 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+# Copyright 2019 BayLibre, SAS
+%YAML 1.2
+---
+$id: "http://devicetree.org/schemas/net/amlogic,meson-dwmac.yaml#"
+$schema: "http://devicetree.org/meta-schemas/core.yaml#"
+
+title: Amlogic Meson DWMAC Ethernet controller
+
+maintainers:
+ - Neil Armstrong <narmstrong@baylibre.com>
+ - Martin Blumenstingl <martin.blumenstingl@googlemail.com>
+
+# We need a select here so we don't match all nodes with 'snps,dwmac'
+select:
+ properties:
+ compatible:
+ contains:
+ enum:
+ - amlogic,meson6-dwmac
+ - amlogic,meson8b-dwmac
+ - amlogic,meson8m2-dwmac
+ - amlogic,meson-gxbb-dwmac
+ - amlogic,meson-axg-dwmac
+ required:
+ - compatible
+
+allOf:
+ - $ref: "snps,dwmac.yaml#"
+ - if:
+ properties:
+ compatible:
+ contains:
+ enum:
+ - amlogic,meson8b-dwmac
+ - amlogic,meson8m2-dwmac
+ - amlogic,meson-gxbb-dwmac
+ - amlogic,meson-axg-dwmac
+
+ then:
+ properties:
+ clocks:
+ items:
+ - description: GMAC main clock
+ - description: First parent clock of the internal mux
+ - description: Second parent clock of the internal mux
+
+ clock-names:
+ minItems: 3
+ maxItems: 3
+ items:
+ - const: stmmaceth
+ - const: clkin0
+ - const: clkin1
+
+ amlogic,tx-delay-ns:
+ $ref: /schemas/types.yaml#definitions/uint32
+ description:
+ The internal RGMII TX clock delay (provided by this driver) in
+ nanoseconds. Allowed values are 0ns, 2ns, 4ns, 6ns.
+ When phy-mode is set to "rgmii" then the TX delay should be
+ explicitly configured. When not configured a fallback of 2ns is
+ used. When the phy-mode is set to either "rgmii-id" or "rgmii-txid"
+ the TX clock delay is already provided by the PHY. In that case
+ this property should be set to 0ns (which disables the TX clock
+ delay in the MAC to prevent the clock from going off because both
+ PHY and MAC are adding a delay).
+ Any configuration is ignored when the phy-mode is set to "rmii".
+
+properties:
+ compatible:
+ additionalItems: true
+ maxItems: 3
+ items:
+ - enum:
+ - amlogic,meson6-dwmac
+ - amlogic,meson8b-dwmac
+ - amlogic,meson8m2-dwmac
+ - amlogic,meson-gxbb-dwmac
+ - amlogic,meson-axg-dwmac
+ contains:
+ enum:
+ - snps,dwmac-3.70a
+ - snps,dwmac
+
+ reg:
+ items:
+ - description:
+ The first register range should be the one of the DWMAC controller
+ - description:
+ The second range is is for the Amlogic specific configuration
+ (for example the PRG_ETHERNET register range on Meson8b and newer)
+
+required:
+ - compatible
+ - reg
+ - interrupts
+ - interrupt-names
+ - clocks
+ - clock-names
+ - phy-mode
+
+examples:
+ - |
+ ethmac: ethernet@c9410000 {
+ compatible = "amlogic,meson-gxbb-dwmac", "snps,dwmac";
+ reg = <0xc9410000 0x10000>, <0xc8834540 0x8>;
+ interrupts = <8>;
+ interrupt-names = "macirq";
+ clocks = <&clk_eth>, <&clkc_fclk_div2>, <&clk_mpll2>;
+ clock-names = "stmmaceth", "clkin0", "clkin1";
+ phy-mode = "rgmii";
+ };
diff --git a/Documentation/devicetree/bindings/net/meson-dwmac.txt b/Documentation/devicetree/bindings/net/meson-dwmac.txt
deleted file mode 100644
index 1321bb194ed9..000000000000
--- a/Documentation/devicetree/bindings/net/meson-dwmac.txt
+++ /dev/null
@@ -1,71 +0,0 @@
-* Amlogic Meson DWMAC Ethernet controller
-
-The device inherits all the properties of the dwmac/stmmac devices
-described in the file stmmac.txt in the current directory with the
-following changes.
-
-Required properties on all platforms:
-
-- compatible: Depending on the platform this should be one of:
- - "amlogic,meson6-dwmac"
- - "amlogic,meson8b-dwmac"
- - "amlogic,meson8m2-dwmac"
- - "amlogic,meson-gxbb-dwmac"
- - "amlogic,meson-axg-dwmac"
- Additionally "snps,dwmac" and any applicable more
- detailed version number described in net/stmmac.txt
- should be used.
-
-- reg: The first register range should be the one of the DWMAC
- controller. The second range is is for the Amlogic specific
- configuration (for example the PRG_ETHERNET register range
- on Meson8b and newer)
-
-Required properties on Meson8b, Meson8m2, GXBB and newer:
-- clock-names: Should contain the following:
- - "stmmaceth" - see stmmac.txt
- - "clkin0" - first parent clock of the internal mux
- - "clkin1" - second parent clock of the internal mux
-
-Optional properties on Meson8b, Meson8m2, GXBB and newer:
-- amlogic,tx-delay-ns: The internal RGMII TX clock delay (provided
- by this driver) in nanoseconds. Allowed values
- are: 0ns, 2ns, 4ns, 6ns.
- When phy-mode is set to "rgmii" then the TX
- delay should be explicitly configured. When
- not configured a fallback of 2ns is used.
- When the phy-mode is set to either "rgmii-id"
- or "rgmii-txid" the TX clock delay is already
- provided by the PHY. In that case this
- property should be set to 0ns (which disables
- the TX clock delay in the MAC to prevent the
- clock from going off because both PHY and MAC
- are adding a delay).
- Any configuration is ignored when the phy-mode
- is set to "rmii".
-
-Example for Meson6:
-
- ethmac: ethernet@c9410000 {
- compatible = "amlogic,meson6-dwmac", "snps,dwmac";
- reg = <0xc9410000 0x10000
- 0xc1108108 0x4>;
- interrupts = <0 8 1>;
- interrupt-names = "macirq";
- clocks = <&clk81>;
- clock-names = "stmmaceth";
- }
-
-Example for GXBB:
- ethmac: ethernet@c9410000 {
- compatible = "amlogic,meson-gxbb-dwmac", "snps,dwmac";
- reg = <0x0 0xc9410000 0x0 0x10000>,
- <0x0 0xc8834540 0x0 0x8>;
- interrupts = <0 8 1>;
- interrupt-names = "macirq";
- clocks = <&clkc CLKID_ETH>,
- <&clkc CLKID_FCLK_DIV2>,
- <&clkc CLKID_MPLL2>;
- clock-names = "stmmaceth", "clkin0", "clkin1";
- phy-mode = "rgmii";
- };
diff --git a/Documentation/devicetree/bindings/net/snps,dwmac.yaml b/Documentation/devicetree/bindings/net/snps,dwmac.yaml
index 76fea2be66ac..ff1dc662a4e3 100644
--- a/Documentation/devicetree/bindings/net/snps,dwmac.yaml
+++ b/Documentation/devicetree/bindings/net/snps,dwmac.yaml
@@ -50,6 +50,11 @@ properties:
- allwinner,sun8i-r40-emac
- allwinner,sun8i-v3s-emac
- allwinner,sun50i-a64-emac
+ - amlogic,meson6-dwmac
+ - amlogic,meson8b-dwmac
+ - amlogic,meson8m2-dwmac
+ - amlogic,meson-gxbb-dwmac
+ - amlogic,meson-axg-dwmac
- snps,dwmac
- snps,dwmac-3.50a
- snps,dwmac-3.610
--
2.22.0
^ permalink raw reply related
* [PATCH v2] arm64: dts: rockchip: Add dts for Leez RK3399 P710 SBC
From: Andy Yan @ 2019-08-05 12:40 UTC (permalink / raw)
To: heiko
Cc: robh+dt, devicetree, linux-arm-kernel, linux-rockchip,
linux-kernel, Andy Yan
P710 is a RK3399 based SBC, designed by Leez [0].
Specification
- Rockchip RK3399
- 4/2GB LPDDR4
- TF sd scard slot
- eMMC
- M.2 B-Key for 4G LTE
- AP6256 for WiFi + BT
- Gigabit ethernet
- HDMI out
- 40 pin header
- USB 2.0 x 2
- USB 3.0 x 1
- USB 3.0 Type-C x 1
- TYPE-C Power supply
[0]https://leez.lenovo.com
Signed-off-by: Andy Yan <andyshrk@gmail.com>
---
Changes in v2:
- Add vendor entry for Leez
- Rework the regulator tree
- Fix some pinctrl names
.../devicetree/bindings/arm/rockchip.yaml | 5 +
.../devicetree/bindings/vendor-prefixes.yaml | 2 +
arch/arm64/boot/dts/rockchip/Makefile | 1 +
.../boot/dts/rockchip/rk3399-leez-p710.dts | 645 ++++++++++++++++++
4 files changed, 653 insertions(+)
create mode 100644 arch/arm64/boot/dts/rockchip/rk3399-leez-p710.dts
diff --git a/Documentation/devicetree/bindings/arm/rockchip.yaml b/Documentation/devicetree/bindings/arm/rockchip.yaml
index 34865042f4e4..da9cd947abfa 100644
--- a/Documentation/devicetree/bindings/arm/rockchip.yaml
+++ b/Documentation/devicetree/bindings/arm/rockchip.yaml
@@ -329,6 +329,11 @@ properties:
- khadas,edge-v
- const: rockchip,rk3399
+ - description: Leez RK3399 P710
+ items:
+ - const: leez,p710
+ - const: rockchip,rk3399
+
- description: mqmaker MiQi
items:
- const: mqmaker,miqi
diff --git a/Documentation/devicetree/bindings/vendor-prefixes.yaml b/Documentation/devicetree/bindings/vendor-prefixes.yaml
index 6992bbbbffab..4be4d9c367b9 100644
--- a/Documentation/devicetree/bindings/vendor-prefixes.yaml
+++ b/Documentation/devicetree/bindings/vendor-prefixes.yaml
@@ -503,6 +503,8 @@ patternProperties:
description: Lantiq Semiconductor
"^lattice,.*":
description: Lattice Semiconductor
+ "^leez,.*":
+ description: Leez
"^lego,.*":
description: LEGO Systems A/S
"^lemaker,.*":
diff --git a/arch/arm64/boot/dts/rockchip/Makefile b/arch/arm64/boot/dts/rockchip/Makefile
index daa2c78e22c3..1f18a9392d15 100644
--- a/arch/arm64/boot/dts/rockchip/Makefile
+++ b/arch/arm64/boot/dts/rockchip/Makefile
@@ -20,6 +20,7 @@ dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3399-hugsun-x99.dtb
dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3399-khadas-edge.dtb
dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3399-khadas-edge-captain.dtb
dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3399-khadas-edge-v.dtb
+dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3399-leez-p710.dtb
dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3399-nanopc-t4.dtb
dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3399-nanopi-m4.dtb
dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3399-nanopi-neo4.dtb
diff --git a/arch/arm64/boot/dts/rockchip/rk3399-leez-p710.dts b/arch/arm64/boot/dts/rockchip/rk3399-leez-p710.dts
new file mode 100644
index 000000000000..32baa57b9481
--- /dev/null
+++ b/arch/arm64/boot/dts/rockchip/rk3399-leez-p710.dts
@@ -0,0 +1,645 @@
+// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
+/*
+ * Copyright (c) 2019 Andy Yan <andy.yan@gmail.com>
+ */
+
+/dts-v1/;
+#include <dt-bindings/input/linux-event-codes.h>
+#include <dt-bindings/pwm/pwm.h>
+#include "rk3399.dtsi"
+#include "rk3399-opp.dtsi"
+
+/ {
+ model = "Leez RK3399 P710";
+ compatible = "leez,p710", "rockchip,rk3399";
+
+ chosen {
+ stdout-path = "serial2:1500000n8";
+ };
+
+ clkin_gmac: external-gmac-clock {
+ compatible = "fixed-clock";
+ clock-frequency = <125000000>;
+ clock-output-names = "clkin_gmac";
+ #clock-cells = <0>;
+ };
+
+ sdio_pwrseq: sdio-pwrseq {
+ compatible = "mmc-pwrseq-simple";
+ clocks = <&rk808 1>;
+ clock-names = "ext_clock";
+ pinctrl-names = "default";
+ pinctrl-0 = <&wifi_reg_on_h>;
+ reset-gpios = <&gpio0 RK_PB2 GPIO_ACTIVE_LOW>;
+ };
+
+ dc5v_adp: dc5v-adp {
+ compatible = "regulator-fixed";
+ regulator-name = "dc5v_adapter";
+ regulator-always-on;
+ regulator-boot-on;
+ regulator-min-microvolt = <5000000>;
+ regulator-max-microvolt = <5000000>;
+ };
+
+ vcc5v0_sys: vcc5v0-sys {
+ compatible = "regulator-fixed";
+ regulator-name = "vcc5v0_sys";
+ regulator-always-on;
+ regulator-boot-on;
+ regulator-min-microvolt = <5000000>;
+ regulator-max-microvolt = <5000000>;
+ vin-supply = <&dc5v_adp>;
+ };
+
+ vcc3v3_sys: vcc3v3-sys {
+ compatible = "regulator-fixed";
+ regulator-name = "vcc3v3_sys";
+ regulator-always-on;
+ regulator-boot-on;
+ regulator-min-microvolt = <3300000>;
+ regulator-max-microvolt = <3300000>;
+ vin-supply = <&vcc5v0_sys>;
+ };
+
+ vcc5v0_host0: vcc5v0_host1: vcc5v0-host {
+ compatible = "regulator-fixed";
+ regulator-name = "vcc5v0_host";
+ regulator-boot-on;
+ regulator-always-on;
+ regulator-min-microvolt = <5500000>;
+ regulator-max-microvolt = <5500000>;
+ vin-supply = <&vcc5v0_sys>;
+ };
+
+ vcc5v0_host3: vcc5v0-host3 {
+ compatible = "regulator-fixed";
+ regulator-name = "vcc5v0_host3";
+ enable-active-high;
+ gpio = <&gpio2 RK_PA2 GPIO_ACTIVE_HIGH>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&vcc5v0_host3_en>;
+ regulator-always-on;
+ vin-supply = <&vcc5v0_sys>;
+ };
+
+ vcc3v3_lan: vcc3v3-lan {
+ compatible = "regulator-fixed";
+ regulator-name = "vcc3v3_lan";
+ regulator-always-on;
+ regulator-boot-on;
+ regulator-min-microvolt = <3300000>;
+ regulator-max-microvolt = <3300000>;
+ vim-supply = <&vcc3v3_sys>;
+ };
+
+ vdd_log: vdd-log {
+ compatible = "pwm-regulator";
+ pwms = <&pwm2 0 25000 1>;
+ regulator-name = "vdd_log";
+ regulator-always-on;
+ regulator-boot-on;
+ regulator-min-microvolt = <800000>;
+ regulator-max-microvolt = <1400000>;
+ vin-supply = <&vcc5v0_sys>;
+ };
+};
+
+&cpu_l0 {
+ cpu-supply = <&vdd_cpu_l>;
+};
+
+&cpu_l1 {
+ cpu-supply = <&vdd_cpu_l>;
+};
+
+&cpu_l2 {
+ cpu-supply = <&vdd_cpu_l>;
+};
+
+&cpu_l3 {
+ cpu-supply = <&vdd_cpu_l>;
+};
+
+&cpu_b0 {
+ cpu-supply = <&vdd_cpu_b>;
+};
+
+&cpu_b1 {
+ cpu-supply = <&vdd_cpu_b>;
+};
+
+&emmc_phy {
+ status = "okay";
+};
+
+&gmac {
+ assigned-clocks = <&cru SCLK_RMII_SRC>;
+ assigned-clock-parents = <&clkin_gmac>;
+ clock_in_out = "input";
+ phy-supply = <&vcc3v3_lan>;
+ phy-mode = "rgmii";
+ pinctrl-names = "default";
+ pinctrl-0 = <&rgmii_pins>;
+ snps,reset-gpio = <&gpio3 RK_PB7 GPIO_ACTIVE_LOW>;
+ snps,reset-active-low;
+ snps,reset-delays-us = <0 10000 50000>;
+ tx_delay = <0x28>;
+ rx_delay = <0x11>;
+ status = "okay";
+};
+
+&gpu {
+ mali-supply = <&vdd_gpu>;
+ status = "okay";
+};
+
+&hdmi {
+ ddc-i2c-bus = <&i2c7>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&hdmi_cec>;
+ status = "okay";
+};
+
+&hdmi_sound {
+ status = "okay";
+};
+
+&i2c0 {
+ clock-frequency = <400000>;
+ i2c-scl-rising-time-ns = <168>;
+ i2c-scl-falling-time-ns = <4>;
+ status = "okay";
+
+ rk808: pmic@1b {
+ compatible = "rockchip,rk808";
+ reg = <0x1b>;
+ interrupt-parent = <&gpio1>;
+ interrupts = <21 IRQ_TYPE_LEVEL_LOW>;
+ #clock-cells = <1>;
+ clock-output-names = "xin32k", "rk808-clkout2";
+ pinctrl-names = "default";
+ pinctrl-0 = <&pmic_int_l>;
+ rockchip,system-power-controller;
+ wakeup-source;
+
+ vcc1-supply = <&vcc5v0_sys>;
+ vcc2-supply = <&vcc5v0_sys>;
+ vcc3-supply = <&vcc5v0_sys>;
+ vcc4-supply = <&vcc5v0_sys>;
+ vcc6-supply = <&vcc5v0_sys>;
+ vcc7-supply = <&vcc5v0_sys>;
+ vcc8-supply = <&vcc3v3_sys>;
+ vcc9-supply = <&vcc5v0_sys>;
+ vcc10-supply = <&vcc5v0_sys>;
+ vcc11-supply = <&vcc5v0_sys>;
+ vcc12-supply = <&vcc3v3_sys>;
+ vddio-supply = <&vcc_1v8>;
+
+ regulators {
+ vdd_center: DCDC_REG1 {
+ regulator-name = "vdd_center";
+ regulator-always-on;
+ regulator-boot-on;
+ regulator-min-microvolt = <750000>;
+ regulator-max-microvolt = <1350000>;
+ regulator-ramp-delay = <6001>;
+ regulator-state-mem {
+ regulator-off-in-suspend;
+ };
+ };
+
+ vdd_cpu_l: DCDC_REG2 {
+ regulator-name = "vdd_cpu_l";
+ regulator-always-on;
+ regulator-boot-on;
+ regulator-min-microvolt = <750000>;
+ regulator-max-microvolt = <1350000>;
+ regulator-ramp-delay = <6001>;
+ regulator-state-mem {
+ regulator-off-in-suspend;
+ };
+ };
+
+ vcc_ddr: DCDC_REG3 {
+ regulator-name = "vcc_ddr";
+ regulator-always-on;
+ regulator-boot-on;
+ regulator-state-mem {
+ regulator-on-in-suspend;
+ };
+ };
+
+ vcc_1v8: DCDC_REG4 {
+ regulator-name = "vcc_1v8";
+ regulator-always-on;
+ regulator-boot-on;
+ regulator-min-microvolt = <1800000>;
+ regulator-max-microvolt = <1800000>;
+ regulator-state-mem {
+ regulator-on-in-suspend;
+ regulator-suspend-microvolt = <1800000>;
+ };
+ };
+
+ vcc1v8_dvp: LDO_REG1 {
+ regulator-name = "vcc1v8_dvp";
+ regulator-always-on;
+ regulator-boot-on;
+ regulator-min-microvolt = <1800000>;
+ regulator-max-microvolt = <1800000>;
+ regulator-state-mem {
+ regulator-off-in-suspend;
+ };
+ };
+
+ vcc1v8_hdmi: LDO_REG2 {
+ regulator-name = "vcc1v8_hdmi";
+ regulator-always-on;
+ regulator-boot-on;
+ regulator-min-microvolt = <1800000>;
+ regulator-max-microvolt = <1800000>;
+ regulator-state-mem {
+ regulator-off-in-suspend;
+ };
+ };
+
+ vcca_1v8: LDO_REG3 {
+ regulator-name = "vcca_1v8";
+ regulator-always-on;
+ regulator-boot-on;
+ regulator-min-microvolt = <1800000>;
+ regulator-max-microvolt = <1800000>;
+ regulator-state-mem {
+ regulator-on-in-suspend;
+ regulator-suspend-microvolt = <1800000>;
+ };
+ };
+
+ vccio_sd: LDO_REG4 {
+ regulator-name = "vccio_sd";
+ regulator-always-on;
+ regulator-boot-on;
+ regulator-min-microvolt = <3000000>;
+ regulator-max-microvolt = <3000000>;
+ regulator-state-mem {
+ regulator-on-in-suspend;
+ regulator-suspend-microvolt = <3000000>;
+ };
+ };
+
+ vcca3v0_codec: LDO_REG5 {
+ regulator-name = "vcca3v0_codec";
+ regulator-always-on;
+ regulator-boot-on;
+ regulator-min-microvolt = <3000000>;
+ regulator-max-microvolt = <3000000>;
+ regulator-state-mem {
+ regulator-off-in-suspend;
+ };
+ };
+
+ vcc_1v5: LDO_REG6 {
+ regulator-name = "vcc_1v5";
+ regulator-always-on;
+ regulator-boot-on;
+ regulator-min-microvolt = <1500000>;
+ regulator-max-microvolt = <1500000>;
+ regulator-state-mem {
+ regulator-on-in-suspend;
+ regulator-suspend-microvolt = <1500000>;
+ };
+ };
+
+ vcc0v9_hdmi: LDO_REG7 {
+ regulator-name = "vcc0v9_hdmi";
+ regulator-always-on;
+ regulator-boot-on;
+ regulator-min-microvolt = <900000>;
+ regulator-max-microvolt = <900000>;
+ regulator-state-mem {
+ regulator-off-in-suspend;
+ };
+ };
+
+ vcc_3v0: LDO_REG8 {
+ regulator-name = "vcc_3v0";
+ regulator-always-on;
+ regulator-boot-on;
+ regulator-min-microvolt = <3000000>;
+ regulator-max-microvolt = <3000000>;
+ regulator-state-mem {
+ regulator-on-in-suspend;
+ regulator-suspend-microvolt = <3000000>;
+ };
+ };
+ };
+ };
+
+ vdd_cpu_b: regulator@40 {
+ compatible = "silergy,syr827";
+ reg = <0x40>;
+ fcs,suspend-voltage-selector = <1>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&vsel1_gpio>;
+ regulator-name = "vdd_cpu_b";
+ regulator-min-microvolt = <712500>;
+ regulator-max-microvolt = <1500000>;
+ regulator-ramp-delay = <1000>;
+ regulator-always-on;
+ regulator-boot-on;
+ vin-supply = <&vcc5v0_sys>;
+
+ regulator-state-mem {
+ regulator-off-in-suspend;
+ };
+ };
+
+ vdd_gpu: regulator@41 {
+ compatible = "silergy,syr828";
+ reg = <0x41>;
+ fcs,suspend-voltage-selector = <1>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&vsel2_gpio>;
+ regulator-name = "vdd_gpu";
+ regulator-min-microvolt = <712500>;
+ regulator-max-microvolt = <1500000>;
+ regulator-ramp-delay = <1000>;
+ regulator-always-on;
+ regulator-boot-on;
+ vin-supply = <&vcc5v0_sys>;
+
+ regulator-state-mem {
+ regulator-off-in-suspend;
+ };
+ };
+};
+
+&i2c1 {
+ i2c-scl-rising-time-ns = <300>;
+ i2c-scl-falling-time-ns = <15>;
+ status = "okay";
+};
+
+&i2c3 {
+ i2c-scl-rising-time-ns = <450>;
+ i2c-scl-falling-time-ns = <15>;
+ status = "okay";
+};
+
+&i2c4 {
+ i2c-scl-rising-time-ns = <600>;
+ i2c-scl-falling-time-ns = <20>;
+ status = "okay";
+};
+
+&i2c7 {
+ status = "okay";
+};
+
+&i2s0 {
+ rockchip,playback-channels = <8>;
+ rockchip,capture-channels = <8>;
+ status = "okay";
+};
+
+&i2s1 {
+ rockchip,playback-channels = <2>;
+ rockchip,capture-channels = <2>;
+ status = "okay";
+};
+
+&i2s2 {
+ status = "okay";
+};
+
+&io_domains {
+ status = "okay";
+
+ bt656-supply = <&vcc1v8_dvp>;
+ audio-supply = <&vcc_1v8>;
+ sdmmc-supply = <&vccio_sd>;
+ gpio1830-supply = <&vcc_3v0>;
+};
+
+&pmu_io_domains {
+ status = "okay";
+ pmu1830-supply = <&vcc_3v0>;
+};
+
+&pinctrl {
+ bt {
+ bt_reg_on_h: bt-reg-on-h {
+ rockchip,pins = <0 RK_PB1 RK_FUNC_GPIO &pcfg_pull_none>;
+ };
+
+ bt_host_wake_l: bt-host-wake-l {
+ rockchip,pins = <0 RK_PA4 RK_FUNC_GPIO &pcfg_pull_none>;
+ };
+
+ bt_wake_l: bt-wake-l {
+ rockchip,pins = <2 RK_PD2 RK_FUNC_GPIO &pcfg_pull_none>;
+ };
+ };
+
+ pmic {
+ pmic_int_l: pmic-int-l {
+ rockchip,pins = <1 RK_PC5 RK_FUNC_GPIO &pcfg_pull_up>;
+ };
+
+ vsel1_gpio: vsel1-gpio {
+ rockchip,pins = <1 RK_PC1 RK_FUNC_GPIO &pcfg_pull_down>;
+ };
+
+ vsel2_gpio: vsel2-gpio {
+ rockchip,pins = <1 RK_PB6 RK_FUNC_GPIO &pcfg_pull_down>;
+ };
+ };
+
+ usb2 {
+ vcc5v0_host3_en: vcc5v0-host3-en {
+ rockchip,pins = <2 RK_PA2 RK_FUNC_GPIO &pcfg_pull_none>;
+ };
+ };
+
+ wifi {
+ wifi_reg_on_h: wifi-reg-on-h {
+ rockchip,pins =
+ <0 RK_PB2 RK_FUNC_GPIO &pcfg_pull_none>;
+ };
+
+ wifi_host_wake_l: wifi-host-wake-l {
+ rockchip,pins = <0 RK_PA3 RK_FUNC_GPIO &pcfg_pull_none>;
+ };
+ };
+};
+
+&pwm2 {
+ status = "okay";
+};
+
+&saradc {
+ status = "okay";
+
+ vref-supply = <&vcc_1v8>;
+};
+
+&sdio0 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ bus-width = <4>;
+ clock-frequency = <50000000>;
+ cap-sdio-irq;
+ cap-sd-highspeed;
+ keep-power-in-suspend;
+ mmc-pwrseq = <&sdio_pwrseq>;
+ non-removable;
+ pinctrl-names = "default";
+ pinctrl-0 = <&sdio0_bus4 &sdio0_cmd &sdio0_clk>;
+ sd-uhs-sdr104;
+ status = "okay";
+
+ brcmf: wifi@1 {
+ compatible = "brcm,bcm4329-fmac";
+ reg = <1>;
+ interrupt-parent = <&gpio0>;
+ interrupts = <RK_PA3 GPIO_ACTIVE_HIGH>;
+ interrupt-names = "host-wake";
+ pinctrl-names = "default";
+ pinctrl-0 = <&wifi_host_wake_l>;
+ };
+};
+
+&sdmmc {
+ bus-width = <4>;
+ cap-mmc-highspeed;
+ cap-sd-highspeed;
+ cd-gpios = <&gpio0 RK_PA7 GPIO_ACTIVE_LOW>;
+ disable-wp;
+ max-frequency = <150000000>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&sdmmc_clk &sdmmc_cd &sdmmc_cmd &sdmmc_bus4>;
+ status = "okay";
+};
+
+&sdhci {
+ bus-width = <8>;
+ mmc-hs400-1_8v;
+ mmc-hs400-enhanced-strobe;
+ non-removable;
+ status = "okay";
+};
+
+&tcphy0 {
+ status = "okay";
+};
+
+&tcphy1 {
+ status = "okay";
+};
+
+&tsadc {
+ status = "okay";
+
+ /* tshut mode 0:CRU 1:GPIO */
+ rockchip,hw-tshut-mode = <1>;
+ /* tshut polarity 0:LOW 1:HIGH */
+ rockchip,hw-tshut-polarity = <1>;
+};
+
+&u2phy0 {
+ status = "okay";
+
+ u2phy0_otg: otg-port {
+ status = "okay";
+ };
+
+ u2phy0_host: host-port {
+ phy-supply = <&vcc5v0_host0>;
+ status = "okay";
+ };
+};
+
+&u2phy1 {
+ status = "okay";
+
+ u2phy1_otg: otg-port {
+ status = "okay";
+ };
+
+ u2phy1_host: host-port {
+ phy-supply = <&vcc5v0_host1>;
+ status = "okay";
+ };
+};
+
+&uart0 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&uart0_xfer &uart0_cts &uart0_rts>;
+ status = "okay";
+
+ bluetooth {
+ compatible = "brcm,bcm43438-bt";
+ clocks = <&rk808 1>;
+ clock-names = "ext_clock";
+ device-wakeup-gpios = <&gpio2 RK_PD2 GPIO_ACTIVE_HIGH>;
+ host-wakeup-gpios = <&gpio0 RK_PA4 GPIO_ACTIVE_HIGH>;
+ shutdown-gpios = <&gpio0 RK_PB1 GPIO_ACTIVE_HIGH>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&bt_host_wake_l &bt_wake_l &bt_reg_on_h>;
+ };
+};
+
+&uart2 {
+ status = "okay";
+};
+
+&usb_host0_ehci {
+ status = "okay";
+};
+
+&usb_host0_ohci {
+ status = "okay";
+};
+
+&usb_host1_ehci {
+ status = "okay";
+};
+
+&usb_host1_ohci {
+ status = "okay";
+};
+
+&usbdrd3_0 {
+ status = "okay";
+};
+
+&usbdrd_dwc3_0 {
+ status = "okay";
+ dr_mode = "otg";
+};
+
+&usbdrd3_1 {
+ status = "okay";
+};
+
+&usbdrd_dwc3_1 {
+ status = "okay";
+ dr_mode = "host";
+};
+
+&vopb {
+ status = "okay";
+};
+
+&vopb_mmu {
+ status = "okay";
+};
+
+&vopl {
+ status = "okay";
+};
+
+&vopl_mmu {
+ status = "okay";
+};
--
2.17.1
^ permalink raw reply related
* Re: [PING 2] [PATCH v5 1/7] nfc: pn533: i2c: "pn532" as dt compatible string
From: Johan Hovold @ 2019-08-05 12:42 UTC (permalink / raw)
To: Lars Poeschel
Cc: devicetree, Samuel Ortiz, open list:NFC SUBSYSTEM, open list,
Johan Hovold, netdev
In-Reply-To: <20190403094735.GA19351@lem-wkst-02.lemonage>
On Wed, Apr 03, 2019 at 11:47:35AM +0200, Lars Poeschel wrote:
> Second Ping.
> On Thu, Feb 28, 2019 at 11:48:01AM +0100, Lars Poeschel wrote:
> > A gentle ping on this whole patch series.
> > On Fri, Jan 11, 2019 at 05:18:04PM +0100, Lars Poeschel wrote:
> > > It is favourable to have one unified compatible string for devices that
> > > have multiple interfaces. So this adds simply "pn532" as the devicetree
> > > binding compatible string and makes a note that the old ones are
> > > deprecated.
> > >
> > > Cc: Johan Hovold <johan@kernel.org>
> > > Signed-off-by: Lars Poeschel <poeschel@lemonage.de>
You may want to resend this series to netdev now. David Miller will be
picking up NFC patches directly from there.
Johan
^ permalink raw reply
* Re: [PATCH v2 4/6] arm64: dts: meson: sei510: Add minimal thermal zone
From: guillaume La Roque @ 2019-08-05 12:48 UTC (permalink / raw)
To: Martin Blumenstingl
Cc: daniel.lezcano, khilman, devicetree, linux-amlogic, linux-kernel,
linux-arm-kernel, linux-pm
In-Reply-To: <CAFBinCD-DUEjPgfUEJmHpPjw1ShZy7nemaFBKANmM5M42XBG4Q@mail.gmail.com>
Hi Martin,
On 8/3/19 8:29 PM, Martin Blumenstingl wrote:
> Hi Guillaume,
>
> On Wed, Jul 31, 2019 at 5:36 PM Guillaume La Roque
> <glaroque@baylibre.com> wrote:
>> Add minimal thermal zone for DDR and CPU sensor
> so high DDR (controller?) temperatures will throttle Mali and high PLL
> temperatures will throttle the CPU?
> to get things started I'm fine with this, but I think it should be
> mentioned here
i will add in commit description
>
>> Signed-off-by: Guillaume La Roque <glaroque@baylibre.com>
>> ---
>> .../boot/dts/amlogic/meson-g12a-sei510.dts | 56 +++++++++++++++++++
>> 1 file changed, 56 insertions(+)
>>
>> diff --git a/arch/arm64/boot/dts/amlogic/meson-g12a-sei510.dts b/arch/arm64/boot/dts/amlogic/meson-g12a-sei510.dts
>> index 979449968a5f..2c16a2cba0a3 100644
>> --- a/arch/arm64/boot/dts/amlogic/meson-g12a-sei510.dts
>> +++ b/arch/arm64/boot/dts/amlogic/meson-g12a-sei510.dts
>> @@ -10,6 +10,7 @@
>> #include <dt-bindings/input/input.h>
>> #include <dt-bindings/gpio/meson-g12a-gpio.h>
>> #include <dt-bindings/sound/meson-g12a-tohdmitx.h>
>> +#include <dt-bindings/thermal/thermal.h>
>>
>> / {
>> compatible = "seirobotics,sei510", "amlogic,g12a";
>> @@ -33,6 +34,53 @@
>> ethernet0 = ðmac;
>> };
>>
>> + thermal-zones {
>> + cpu-thermal {
>> + polling-delay = <1000>;
>> + polling-delay-passive = <100>;
>> + thermal-sensors = <&cpu_temp>;
>> +
>> + trips {
>> + cpu_critical: cpu-critical {
>> + temperature = <110000>; /* millicelsius */
>> + hysteresis = <2000>; /* millicelsius */
>> + type = "critical";
>> + };
>> + };
>> +
>> + cooling-maps {
>> + map {
>> + trip = <&cpu_critical>;
>> + cooling-device = <&cpu0 THERMAL_NO_LIMIT THERMAL_NO_LIMIT>,
>> + <&cpu1 THERMAL_NO_LIMIT THERMAL_NO_LIMIT>,
>> + <&cpu2 THERMAL_NO_LIMIT THERMAL_NO_LIMIT>,
>> + <&cpu3 THERMAL_NO_LIMIT THERMAL_NO_LIMIT>;
>> + };
>> + };
>> + };
>> +
>> + ddr-thermal {
>> + polling-delay = <1000>;
>> + polling-delay-passive = <100>;
>> + thermal-sensors = <&ddr_temp>;
>> +
>> + trips {
>> + ddr_critical: ddr-critical {
>> + temperature = <110000>; /* millicelsius */
>> + hysteresis = <2000>; /* millicelsius */
>> + type = "critical";
>> + };
>> + };
>> +
>> + cooling-maps {
>> + map {
>> + trip = <&ddr_critical>;
>> + cooling-device = <&mali THERMAL_NO_LIMIT THERMAL_NO_LIMIT>;
>> + };
>> + };
>> + };
>> + };
>> +
>> mono_dac: audio-codec-0 {
>> compatible = "maxim,max98357a";
>> #sound-dai-cells = <0>;
>> @@ -321,6 +369,7 @@
>> operating-points-v2 = <&cpu_opp_table>;
>> clocks = <&clkc CLKID_CPU_CLK>;
>> clock-latency = <50000>;
>> + #cooling-cells = <2>;
>> };
>>
>> &cpu1 {
>> @@ -328,6 +377,7 @@
>> operating-points-v2 = <&cpu_opp_table>;
>> clocks = <&clkc CLKID_CPU_CLK>;
>> clock-latency = <50000>;
>> + #cooling-cells = <2>;
>> };
>>
>> &cpu2 {
>> @@ -335,6 +385,7 @@
>> operating-points-v2 = <&cpu_opp_table>;
>> clocks = <&clkc CLKID_CPU_CLK>;
>> clock-latency = <50000>;
>> + #cooling-cells = <2>;
>> };
>>
>> &cpu3 {
>> @@ -342,6 +393,7 @@
>> operating-points-v2 = <&cpu_opp_table>;
>> clocks = <&clkc CLKID_CPU_CLK>;
>> clock-latency = <50000>;
>> + #cooling-cells = <2>;
>> };
>>
>> &cvbs_vdac_port {
>> @@ -368,6 +420,10 @@
>> status = "okay";
>> };
>>
>> +&mali {
>> + #cooling-cells = <2>;
>> +};
> is there something device-specific in this patch? I'm wondering
> whether we can move all of this go g12a.dtsi to simplify maintenance
> in the future
this is depending of each board. actually it's same on all
but if a new one have a fan this value should be different or not.
>
>
> Martin
thanks,
Guillaume
^ permalink raw reply
* Re: [PATCH v2 2/6] thermal: amlogic: Add thermal driver to support G12 SoCs
From: guillaume La Roque @ 2019-08-05 12:48 UTC (permalink / raw)
To: Martin Blumenstingl
Cc: daniel.lezcano, khilman, devicetree, linux-amlogic, linux-kernel,
linux-arm-kernel, linux-pm
In-Reply-To: <CAFBinCDGSJABnS1L1ULueyeXZaV38qrxEA0a12gB-uyRC_TvPQ@mail.gmail.com>
Hi Martin,
again thanks for your review.
On 8/3/19 8:24 PM, Martin Blumenstingl wrote:
> Hi Guillaume,
>
> (I still don't have any experience with the thermal framework, so
> below are some general comments)
>
> On Wed, Jul 31, 2019 at 5:36 PM Guillaume La Roque
> <glaroque@baylibre.com> wrote:
> I would add a patch description here:
> "
> Amlogic G12A and G12B SoCs integrate two thermal sensors with the same design.
> One is located close to the DDR (controller?) and the other one is
> located close to the PLLs (between the CPU and GPU).
>
> The calibration data for each of the thermal sensors instance is
> stored in a different location within the AO region.
>
> Implement reading the temperature from each thermal sensor.
>
> The IP block has more functionality, which may be added to this driver
> in the future:
> - reading up to 16 stored temperature samples
it's not working, you can verify it if you check the regmap define in the driver. in fact temp is only write in one register, it's confirmed by amlogic.
> - chip reset when the temperature exceeds a configurable threshold
> - up to four interrupts when the temperature has risen above a
> configurable threshold
> - up to four interrupts when the temperature has fallen below a
> configurable threshold
> "
agreed with you to add description and optional without 16 register part.
>
>> Signed-off-by: Guillaume La Roque <glaroque@baylibre.com>
>> ---
>> drivers/thermal/Kconfig | 11 +
>> drivers/thermal/Makefile | 1 +
>> drivers/thermal/amlogic_thermal.c | 332 ++++++++++++++++++++++++++++++
>> 3 files changed, 344 insertions(+)
>> create mode 100644 drivers/thermal/amlogic_thermal.c
>>
>> diff --git a/drivers/thermal/Kconfig b/drivers/thermal/Kconfig
>> index 9966364a6deb..0f31bb4bc372 100644
>> --- a/drivers/thermal/Kconfig
>> +++ b/drivers/thermal/Kconfig
>> @@ -348,6 +348,17 @@ config MTK_THERMAL
>> Enable this option if you want to have support for thermal management
>> controller present in Mediatek SoCs
>>
>> +config AMLOGIC_THERMAL
> we typically use "MESON" in the Kconfig symbols:
> $ grep -c AMLOGIC .config
> 1
> $ grep -c MESON .config
> 33
>
> I also wonder if we should add G12 or G12A so we don't conflict with
> upcoming thermal sensors with a different design (assuming that this
> will be a thing).
> for example we already have three different USB2 PHY drivers
>
> [...]
i check with Neil and for new family it's better to use Amlogic instead of meson.
i don't add G12 because we already know it's same sensors for SM1 SoC family [0].
>> +/*
>> + * Calculate a temperature value from a temperature code.
>> + * The unit of the temperature is degree Celsius.
> is it really degree Celsius or millicelsius?
good point it's in millicelsius, i will fix all
>
>> + */
>> +static int code_to_temp(struct amlogic_thermal *pdata, int temp_code)
> PREFIX_thermal_code_to_millicelsius?
ok
> [...]
>> +static int amlogic_thermal_enable(struct amlogic_thermal *data)
>> +{
>> + clk_prepare_enable(data->clk);
> no clock error handling?
i will fix
>
>> + regmap_update_bits(data->regmap, TSENSOR_CFG_REG1,
>> + TSENSOR_CFG_REG1_ENABLE, TSENSOR_CFG_REG1_ENABLE);
>> +
>> + return 0;
>> +}
>> +
>> +static int amlogic_thermal_disable(struct amlogic_thermal *data)
>> +{
>> + regmap_update_bits(data->regmap, TSENSOR_CFG_REG1,
>> + TSENSOR_CFG_REG1_ENABLE, 0);
>> + clk_disable(data->clk);
> either clk_disable_unprepare here or use only clk_enable in
> amlogic_thermal_enable and move prepare/unprepare somewhere else
i will align with enable and use clk_disable_unprepare
>
>> +
>> + return 0;
>> +}
>> +
>> +static int amlogic_thermal_get_temp(void *data, int *temp)
>> +{
>> + unsigned int tvalue;
>> + struct amlogic_thermal *pdata = data;
>> +
>> + if (!data)
>> + return -EINVAL;
>> +
>> + regmap_read(pdata->regmap, TSENSOR_STAT0, &tvalue);
>> + *temp = code_to_temp(pdata,
>> + tvalue & TSENSOR_READ_TEMP_MASK);
> maybe simply move the implementation from code_to_temp here?
for the optional function it could be a problem if i move all in code_to_temp.
i prefer to have a function which are just do the conversion.
>
> [...]
>> +static const struct amlogic_thermal_data amlogic_thermal_g12_cpu_param = {
>> + .u_efuse_off = 0x128,
>> + .soc = &amlogic_thermal_g12,
> based on the variable name I expected this to be an enum of some sort.
> I would have expected it to be called calibration_parameters or
> similar to match the explanation in the driver description
> (no need to change it if you prefer it like this, I just want to make
> you aware of this)
ok to rename structure name
>
>> + .regmap_config = &amlogic_thermal_regmap_config_g12,
> if regmap_config is always the same you may also pass it directly to
> devm_regmap_init_mmio
it's the same for now but we don't know if in the future SoCs use same regmap.
>
>> +};
>> +
>> +static const struct amlogic_thermal_data amlogic_thermal_g12_ddr_param = {
>> + .u_efuse_off = 0xF0,
> I believe we use lower-case hex everywhere else
>
> [...]
will fix
>> +static const struct of_device_id of_amlogic_thermal_match[] = {
>> + {
>> + .compatible = "amlogic,g12-ddr-thermal",
>> + .data = &amlogic_thermal_g12_ddr_param,
>> + },
>> + {
>> + .compatible = "amlogic,g12-cpu-thermal",
>> + .data = &amlogic_thermal_g12_cpu_param,
>> + },
>> + { /* end */ }
> other drivers use "sentinel", but personally I have no preference here
>
> [...]
same for me i will do same as other drivers
>> + pdata->tzd = devm_thermal_zone_of_sensor_register
>> + (&pdev->dev,
>> + 0,
>> + pdata,
>> + &amlogic_thermal_ops);
> I believe the opening brace has to go onto the same line as the function name
>
> [...]
will fix
>> + ret = amlogic_thermal_enable(pdata);
>> + if (ret)
>> + clk_unprepare(pdata->clk);
> clk_disable_unprepare, else you'll leave the clock prepared
will fix
>
>> +#ifdef CONFIG_PM_SLEEP
>> +static int amlogic_thermal_suspend(struct device *dev)
>> +{
>> + struct amlogic_thermal *data = dev_get_drvdata(dev);
>> +
>> + return amlogic_thermal_disable(data);
>> +}
>> +
>> +static int amlogic_thermal_resume(struct device *dev)
>> +{
>> + struct amlogic_thermal *data = dev_get_drvdata(dev);
>> +
>> + return amlogic_thermal_enable(data);
>> +}
>> +#endif
> instead of using an #ifdef here annotate the suspend/resume functions
> with __maybe_unused, see [0]
will fix
>
>
> Martin
>
>
> [0] https://lore.kernel.org/patchwork/patch/732981/
[0] https://lore.kernel.org/linux-arm-kernel/20190701104705.18271-1-narmstrong@baylibre.com/
thanks
Guillaume
^ permalink raw reply
* [PATCH 1/2] dt-bindings: pwm: pwm-mediatek: Add documentation for MT8516
From: Fabien Parent @ 2019-08-05 12:58 UTC (permalink / raw)
To: thierry.reding, robh+dt, matthias.bgg
Cc: mark.rutland, linux-pwm, devicetree, linux-kernel,
linux-arm-kernel, linux-mediatek, Fabien Parent
Add the device-tree documentation for the PWM IP on the MediaTek
MT8516 SoCs.
Signed-off-by: Fabien Parent <fparent@baylibre.com>
---
Documentation/devicetree/bindings/pwm/pwm-mediatek.txt | 1 +
1 file changed, 1 insertion(+)
diff --git a/Documentation/devicetree/bindings/pwm/pwm-mediatek.txt b/Documentation/devicetree/bindings/pwm/pwm-mediatek.txt
index 991728cb46cb..9152bf5afe56 100644
--- a/Documentation/devicetree/bindings/pwm/pwm-mediatek.txt
+++ b/Documentation/devicetree/bindings/pwm/pwm-mediatek.txt
@@ -6,6 +6,7 @@ Required properties:
- "mediatek,mt7622-pwm": found on mt7622 SoC.
- "mediatek,mt7623-pwm": found on mt7623 SoC.
- "mediatek,mt7628-pwm": found on mt7628 SoC.
+ - "mediatek,mt8516-pwm": found on mt8516 SoC.
- reg: physical base address and length of the controller's registers.
- #pwm-cells: must be 2. See pwm.txt in this directory for a description of
the cell format.
--
2.23.0.rc1
^ permalink raw reply related
* [PATCH 2/2] pwm: pwm-mediatek: Add MT8516 SoC support
From: Fabien Parent @ 2019-08-05 12:58 UTC (permalink / raw)
To: thierry.reding, robh+dt, matthias.bgg
Cc: mark.rutland, linux-pwm, devicetree, linux-kernel,
linux-arm-kernel, linux-mediatek, Fabien Parent
In-Reply-To: <20190805125848.15751-1-fparent@baylibre.com>
Add the compatible and the platform data to support PWM on the MT8516
SoC.
Signed-off-by: Fabien Parent <fparent@baylibre.com>
---
drivers/pwm/pwm-mediatek.c | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/drivers/pwm/pwm-mediatek.c b/drivers/pwm/pwm-mediatek.c
index eb6674ce995f..6697e30811e7 100644
--- a/drivers/pwm/pwm-mediatek.c
+++ b/drivers/pwm/pwm-mediatek.c
@@ -302,11 +302,18 @@ static const struct mtk_pwm_platform_data mt7628_pwm_data = {
.has_clks = false,
};
+static const struct mtk_pwm_platform_data mt8516_pwm_data = {
+ .num_pwms = 5,
+ .pwm45_fixup = false,
+ .has_clks = true,
+};
+
static const struct of_device_id mtk_pwm_of_match[] = {
{ .compatible = "mediatek,mt2712-pwm", .data = &mt2712_pwm_data },
{ .compatible = "mediatek,mt7622-pwm", .data = &mt7622_pwm_data },
{ .compatible = "mediatek,mt7623-pwm", .data = &mt7623_pwm_data },
{ .compatible = "mediatek,mt7628-pwm", .data = &mt7628_pwm_data },
+ { .compatible = "mediatek,mt8516-pwm", .data = &mt8516_pwm_data },
{ },
};
MODULE_DEVICE_TABLE(of, mtk_pwm_of_match);
--
2.23.0.rc1
^ permalink raw reply related
* [PATCH] dt-bindings: rng: mtk-rng: Add documentation for MT8516
From: Fabien Parent @ 2019-08-05 13:02 UTC (permalink / raw)
To: robh+dt, matthias.bgg
Cc: linux-crypto, devicetree, linux-arm-kernel, linux-mediatek,
linux-kernel, Fabien Parent
This commit adds the device-tree documentation for the RNG IP on the
MediaTek MT8516 SoC.
Signed-off-by: Fabien Parent <fparent@baylibre.com>
---
Documentation/devicetree/bindings/rng/mtk-rng.txt | 1 +
1 file changed, 1 insertion(+)
diff --git a/Documentation/devicetree/bindings/rng/mtk-rng.txt b/Documentation/devicetree/bindings/rng/mtk-rng.txt
index 2bc89f133701..dfdcb5cd2ea8 100644
--- a/Documentation/devicetree/bindings/rng/mtk-rng.txt
+++ b/Documentation/devicetree/bindings/rng/mtk-rng.txt
@@ -6,6 +6,7 @@ Required properties:
"mediatek,mt7622-rng", "mediatek,mt7623-rng" : for MT7622
"mediatek,mt7629-rng", "mediatek,mt7623-rng" : for MT7629
"mediatek,mt7623-rng" : for MT7623
+ "mediatek,mt8516-rng", "mediatek,mt7623-rng" : for MT8516
- clocks : list of clock specifiers, corresponding to
entries in clock-names property;
- clock-names : Should contain "rng" entries;
--
2.23.0.rc1
^ permalink raw reply related
* Re: [PATCH v4 07/10] regulator: mt6358: Add support for MT6358 regulator
From: Mark Brown @ 2019-08-05 13:10 UTC (permalink / raw)
To: Hsin-Hsiung Wang
Cc: Mark Rutland, Alessandro Zummo, Alexandre Belloni, srv_heupstream,
devicetree, Sean Wang, Liam Girdwood, linux-kernel,
Richard Fontana, Rob Herring, linux-mediatek, Allison Randal,
linux-rtc, Matthias Brugger, Thomas Gleixner, Eddie Huang,
Lee Jones, Kate Stewart, linux-arm-kernel
In-Reply-To: <1564982518-32163-8-git-send-email-hsin-hsiung.wang@mediatek.com>
[-- Attachment #1.1: Type: text/plain, Size: 1282 bytes --]
On Mon, Aug 05, 2019 at 01:21:55PM +0800, Hsin-Hsiung Wang wrote:
> +static const u32 vmch_voltages[] = {
> + 2900000, 3000000, 3300000,
> +};
> +static const u32 vemc_voltages[] = {
> + 2900000, 3000000, 3300000,
> +};
Several of these tables appear to be identical.
> +static inline unsigned int mt6358_map_mode(unsigned int mode)
> +{
> + return mode == MT6358_BUCK_MODE_AUTO ?
> + REGULATOR_MODE_NORMAL : REGULATOR_MODE_FAST;
> +}
There is no need for this to be an inline and please write normal
conditional statements to improve legibility. There's other examples in
the driver.
> +static int mt6358_get_buck_voltage_sel(struct regulator_dev *rdev)
> +{
> + int ret, regval;
> + struct mt6358_regulator_info *info = rdev_get_drvdata(rdev);
> +
> + ret = regmap_read(rdev->regmap, info->da_vsel_reg, ®val);
> + if (ret != 0) {
> + dev_info(&rdev->dev,
> + "Failed to get mt6358 Buck %s vsel reg: %d\n",
> + info->desc.name, ret);
dev_err() for errors here and throughout the driver.
> + return ret;
> + }
> +
> + ret = (regval >> info->da_vsel_shift) & info->da_vsel_mask;
> +
> + return ret;
> +}
This looks like a standard get_voltage_sel_regmap()?
> +err_mode:
> + if (ret != 0)
> + return ret;
> +
> + return 0;
Or just return ret unconditionally?
[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
[-- Attachment #2: Type: text/plain, Size: 176 bytes --]
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v4 4/4] edac: Add support for Amazon's Annapurna Labs L2 EDAC
From: Hawa, Hanna @ 2019-08-05 13:14 UTC (permalink / raw)
To: James Morse
Cc: robh+dt, mark.rutland, bp, mchehab, davem, gregkh, linus.walleij,
Jonathan.Cameron, nicolas.ferre, paulmck, dwmw, benh, ronenk,
talel, jonnyc, hanochu, devicetree, linux-kernel, linux-edac
In-Reply-To: <a060cbce-14f3-0592-4998-0a900d3fe6e4@arm.com>
On 8/2/2019 6:11 PM, James Morse wrote:
> Hi Hanna,
>
> On 01/08/2019 14:09, Hanna Hawa wrote:
>> Adds support for Amazon's Annapurna Labs L2 EDAC driver to detect and
>> report L2 errors.
>> diff --git a/drivers/edac/al_l2_edac.c b/drivers/edac/al_l2_edac.c
>> new file mode 100644
>> index 000000000000..6c6d37cf82ab
>> --- /dev/null
>> +++ b/drivers/edac/al_l2_edac.c
>> @@ -0,0 +1,189 @@
>
>> +#include <asm/sysreg.h>
>> +#include <linux/bitfield.h>
>
> #include <linux/cpumask.h> ?
Will be added.
>
>> +#include <linux/of.h>
>> +#include <linux/smp.h>
>
> [...]
>
>> +static void al_l2_edac_l2merrsr(void *arg)
>> +{
>> + struct edac_device_ctl_info *edac_dev = arg;
>> + int cpu, i;
>> + u32 ramid, repeat, other, fatal;
>> + u64 val = read_sysreg_s(ARM_CA57_L2MERRSR_EL1);
>> + char msg[AL_L2_EDAC_MSG_MAX];
>> + int space, count;
>> + char *p;
>> +
>> + if (!(FIELD_GET(ARM_CA57_L2MERRSR_VALID, val)))
>> + return;
>> +
>> + write_sysreg_s(0, ARM_CA57_L2MERRSR_EL1);
>> +
>> + cpu = smp_processor_id();
>> + ramid = FIELD_GET(ARM_CA57_L2MERRSR_RAMID, val);
>> + repeat = FIELD_GET(ARM_CA57_L2MERRSR_REPEAT, val);
>> + other = FIELD_GET(ARM_CA57_L2MERRSR_OTHER, val);
>> + fatal = FIELD_GET(ARM_CA57_L2MERRSR_FATAL, val);
>> +
>> + space = sizeof(msg);
>> + p = msg;
>> + count = scnprintf(p, space, "CPU%d L2 %serror detected", cpu,
>> + (fatal) ? "Fatal " : "");
>> + p += count;
>> + space -= count;
>> +
>> + switch (ramid) {
>> + case ARM_CA57_L2_TAG_RAM:
>> + count = scnprintf(p, space, " RAMID='L2 Tag RAM'");
>> + break;
>> + case ARM_CA57_L2_DATA_RAM:
>> + count = scnprintf(p, space, " RAMID='L2 Data RAM'");
>> + break;
>> + case ARM_CA57_L2_SNOOP_RAM:
>> + count = scnprintf(p, space, " RAMID='L2 Snoop RAM'");
>
> Nit: The TRMs both call this 'L2 Snoop Tag RAM'. Could we include 'tag' in the
> description. 'tag' implies its some kind of metadata, so an uncorrected error here affect
> a now unknown location, its more series than a 'data RAM' error. v8.2 would term this kind
> of error 'uncontained'.
Ack, will be fixed.
>
>
>> + break;
>> + case ARM_CA57_L2_DIRTY_RAM:
>> + count = scnprintf(p, space, " RAMID='L2 Dirty RAM'");
>> + break;
>> + case ARM_CA57_L2_INC_PF_RAM:
>> + count = scnprintf(p, space, " RAMID='L2 internal metadat'");
>
> Nit: metadata
Ack, will be fixed.
>
>> + break;
>> + default:
>> + count = scnprintf(p, space, " RAMID='unknown'");
>> + break;
>> + }
>> +
>> + p += count;
>> + space -= count;
>> +
>> + count = scnprintf(p, space,
>> + " repeat=%d, other=%d (L2MERRSR_EL1=0x%llx)",
>> + repeat, other, val);
>> +
>> + for (i = 0; i < repeat; i++) {
>> + if (fatal)
>> + edac_device_handle_ue(edac_dev, 0, 0, msg);
>> + else
>> + edac_device_handle_ce(edac_dev, 0, 0, msg);
>> + }
>> +}
>
> [...]
>
>> +static int al_l2_edac_probe(struct platform_device *pdev)
>> +{
>> + struct edac_device_ctl_info *edac_dev;
>> + struct al_l2_edac *al_l2;
>> + struct device *dev = &pdev->dev;
>> + int ret, i;
>> +
>> + edac_dev = edac_device_alloc_ctl_info(sizeof(*al_l2),
>> + (char *)dev_name(dev), 1, "L", 1,
>> + 2, NULL, 0,
>> + edac_device_alloc_index());
>> + if (IS_ERR_OR_NULL(edac_dev))
>> + return -ENOMEM;
>> +
>> + al_l2 = edac_dev->pvt_info;
>> + edac_dev->edac_check = al_l2_edac_check;
>> + edac_dev->dev = dev;
>> + edac_dev->mod_name = DRV_NAME;
>> + edac_dev->dev_name = dev_name(dev);
>> + edac_dev->ctl_name = "L2 cache";
>> + platform_set_drvdata(pdev, edac_dev);
>
>> + for_each_online_cpu(i) {
>
> for_each_possible_cpu()?
>
> If you boot with maxcpus= the driver's behaviour changes.
> But you are only parsing information from the DT, so you don't really need the CPUs to be
> online.
Agree, for dt parsing no need the online CPUs, if
for_each_possible_cpu() used then smp_call_function_any() will run only
on the online CPUs in the mask.
Will change to for_each_possible_cpu().
>
>
>> + struct device_node *cpu;
>> + struct device_node *cpu_cache, *l2_cache;
>> +
>> + cpu = of_get_cpu_node(i, NULL);
>
> (of_get_cpu_node() can return NULL, but I don't think it can ever happen like this)
>
>> + cpu_cache = of_find_next_cache_node(cpu);
>> + l2_cache = of_parse_phandle(dev->of_node, "l2-cache", 0);
>> +
>> + if (cpu_cache == l2_cache)
>> + cpumask_set_cpu(i, &al_l2->cluster_cpus);
>
> You need to of_node_put() these device_node pointers once you're done with them.
Will be added.
>
>
>> + }
>> +
>> + if (cpumask_empty(&al_l2->cluster_cpus)) {
>> + dev_err(dev, "CPU mask is empty for this L2 cache\n");
>> + ret = -EINVAL;
>> + goto err;
>> + }
>> +
>> + ret = edac_device_add_device(edac_dev);
>> + if (ret) {
>> + dev_err(dev, "Failed to add L2 edac device\n");
>> + goto err;
>> + }
>> +
>> + return 0;
>> +
>> +err:
>> + edac_device_free_ctl_info(edac_dev);
>> +
>> + return ret;
>> +}
>
> With the of_node_put()ing:
> Reviewed-by: James Morse <james.morse@arm.com>
Thanks for review, will publish v5 with the above fixes.
Thanks,
Hanna
>
>
> Thanks,
>
> James
>
^ permalink raw reply
* Re: [RFC PATCH 1/2] dt-bindings: net: macb: Add new property for PS SGMII only
From: Andrew Lunn @ 2019-08-05 13:20 UTC (permalink / raw)
To: Harini Katakam
Cc: Harini Katakam, Nicolas Ferre, David Miller, Claudiu Beznea,
Rob Herring, Mark Rutland, netdev, linux-kernel, Michal Simek,
devicetree
In-Reply-To: <CAFcVECL6cvCjeo+fn1NDyMDZyZXDrWyhD9djvcVXiLVLiLgGeA@mail.gmail.com>
On Mon, Aug 05, 2019 at 11:45:05AM +0530, Harini Katakam wrote:
> Hi Andrew,
>
> On Sun, Aug 4, 2019 at 8:26 PM Andrew Lunn <andrew@lunn.ch> wrote:
> >
> > On Wed, Jul 31, 2019 at 03:10:32PM +0530, Harini Katakam wrote:
> > > Add a new property to indicate when PS SGMII is used with NO
> > > external PHY on board.
> >
> > Hi Harini
> >
> > What exactly is you use case? Are you connecting to a Ethernet switch?
> > To an SFP cage with a copper module?
>
> Yes, an SFP cage is the common HW target for this patch.
Hi Harini
So you have a copper PHY in the SFP cage. It will talk SGMII
signalling to your PS SGMII. When that signalling is complete i would
expect the MAC to raise an interrupt, just as if the SGMII PHY was
soldered on the board. So i don't see why you need this polling?
Andrew
^ permalink raw reply
* Re: [PATCH v4 1/2] iio: potentiometer: add a driver for Maxim 5432-5435
From: Jonathan Cameron @ 2019-08-05 13:30 UTC (permalink / raw)
To: Martin Kaiser
Cc: Hartmut Knaack, Lars-Peter Clausen, Rob Herring, linux-iio,
devicetree, linux-kernel
In-Reply-To: <20190731140706.2765-1-martin@kaiser.cx>
On Wed, 31 Jul 2019 16:07:05 +0200
Martin Kaiser <martin@kaiser.cx> wrote:
> Add a driver for the Maxim Integrated MAX5432-MAX5435 family of digital
> potentiometers.
>
> These potentiometers are connected via I2C and have 32 wiper
> positions.
>
> Supported functionality
> - set the volatile wiper position
> - read the potentiometer scale
>
> Datasheet:
> https://datasheets.maximintegrated.com/en/ds/MAX5432-MAX5435.pdf
>
> Signed-off-by: Martin Kaiser <martin@kaiser.cx>
Looks good.
Applied to the togreg branch of iio.git and pushed out as testing
for the autobuilders to play with it.
Thanks,
Jonathan
> ---
> changes in v4
> - fix the dt bindings
> - replace ic20 with i2c
> - document the reg property
> - add additionalProperties and required
>
> changes in v3
> - split dt bindings and driver code into separate patches
> - use yaml format for dt bindings
> - fix formatting of parameter lists
>
> changes in v2
> - use MAX5432_ prefix for all defines
> - fix indentation
> - convert void * to unsigned long, not to u32
> (warning from kbuild test robot)
>
> drivers/iio/potentiometer/Kconfig | 11 +++
> drivers/iio/potentiometer/Makefile | 1 +
> drivers/iio/potentiometer/max5432.c | 135 ++++++++++++++++++++++++++++++++++++
> 3 files changed, 147 insertions(+)
> create mode 100644 drivers/iio/potentiometer/max5432.c
>
> diff --git a/drivers/iio/potentiometer/Kconfig b/drivers/iio/potentiometer/Kconfig
> index ebc7c72a5e36..4cac0173db8b 100644
> --- a/drivers/iio/potentiometer/Kconfig
> +++ b/drivers/iio/potentiometer/Kconfig
> @@ -26,6 +26,17 @@ config DS1803
> To compile this driver as a module, choose M here: the
> module will be called ds1803.
>
> +config MAX5432
> + tristate "Maxim MAX5432-MAX5435 Digital Potentiometer driver"
> + depends on I2C
> + help
> + Say yes here to build support for the Maxim
> + MAX5432, MAX5433, MAX5434 and MAX5435 digital
> + potentiometer chips.
> +
> + To compile this driver as a module, choose M here: the
> + module will be called max5432.
> +
> config MAX5481
> tristate "Maxim MAX5481-MAX5484 Digital Potentiometer driver"
> depends on SPI
> diff --git a/drivers/iio/potentiometer/Makefile b/drivers/iio/potentiometer/Makefile
> index 8ff55138cf12..091adf3cdd0b 100644
> --- a/drivers/iio/potentiometer/Makefile
> +++ b/drivers/iio/potentiometer/Makefile
> @@ -6,6 +6,7 @@
> # When adding new entries keep the list in alphabetical order
> obj-$(CONFIG_AD5272) += ad5272.o
> obj-$(CONFIG_DS1803) += ds1803.o
> +obj-$(CONFIG_MAX5432) += max5432.o
> obj-$(CONFIG_MAX5481) += max5481.o
> obj-$(CONFIG_MAX5487) += max5487.o
> obj-$(CONFIG_MCP4018) += mcp4018.o
> diff --git a/drivers/iio/potentiometer/max5432.c b/drivers/iio/potentiometer/max5432.c
> new file mode 100644
> index 000000000000..641b1821fdf6
> --- /dev/null
> +++ b/drivers/iio/potentiometer/max5432.c
> @@ -0,0 +1,135 @@
> +// SPDX-License-Identifier: GPL-2.0-or-later
> +/*
> + * Maxim Integrated MAX5432-MAX5435 digital potentiometer driver
> + * Copyright (C) 2019 Martin Kaiser <martin@kaiser.cx>
> + *
> + * Datasheet:
> + * https://datasheets.maximintegrated.com/en/ds/MAX5432-MAX5435.pdf
> + */
> +
> +#include <linux/i2c.h>
> +#include <linux/iio/iio.h>
> +#include <linux/limits.h>
> +#include <linux/module.h>
> +#include <linux/of.h>
> +#include <linux/of_device.h>
> +
> +/* All chip variants have 32 wiper positions. */
> +#define MAX5432_MAX_POS 31
> +
> +#define MAX5432_OHM_50K (50 * 1000)
> +#define MAX5432_OHM_100K (100 * 1000)
> +
> +/* Update the volatile (currently active) setting. */
> +#define MAX5432_CMD_VREG 0x11
> +
> +struct max5432_data {
> + struct i2c_client *client;
> + unsigned long ohm;
> +};
> +
> +static const struct iio_chan_spec max5432_channels[] = {
> + {
> + .type = IIO_RESISTANCE,
> + .indexed = 1,
> + .output = 1,
> + .channel = 0,
> + .address = MAX5432_CMD_VREG,
> + .info_mask_separate = BIT(IIO_CHAN_INFO_RAW),
> + .info_mask_shared_by_type = BIT(IIO_CHAN_INFO_SCALE),
> + }
> +};
> +
> +static int max5432_read_raw(struct iio_dev *indio_dev,
> + struct iio_chan_spec const *chan,
> + int *val, int *val2, long mask)
> +{
> + struct max5432_data *data = iio_priv(indio_dev);
> +
> + if (mask != IIO_CHAN_INFO_SCALE)
> + return -EINVAL;
> +
> + if (unlikely(data->ohm > INT_MAX))
> + return -ERANGE;
> +
> + *val = data->ohm;
> + *val2 = MAX5432_MAX_POS;
> +
> + return IIO_VAL_FRACTIONAL;
> +}
> +
> +static int max5432_write_raw(struct iio_dev *indio_dev,
> + struct iio_chan_spec const *chan,
> + int val, int val2, long mask)
> +{
> + struct max5432_data *data = iio_priv(indio_dev);
> + u8 data_byte;
> +
> + if (mask != IIO_CHAN_INFO_RAW)
> + return -EINVAL;
> +
> + if (val < 0 || val > MAX5432_MAX_POS)
> + return -EINVAL;
> +
> + if (val2 != 0)
> + return -EINVAL;
> +
> + /* Wiper position is in bits D7-D3. (D2-D0 are don't care bits.) */
> + data_byte = val << 3;
> + return i2c_smbus_write_byte_data(data->client, chan->address,
> + data_byte);
> +}
> +
> +static const struct iio_info max5432_info = {
> + .read_raw = max5432_read_raw,
> + .write_raw = max5432_write_raw,
> +};
> +
> +static int max5432_probe(struct i2c_client *client,
> + const struct i2c_device_id *id)
> +{
> + struct device *dev = &client->dev;
> + struct iio_dev *indio_dev;
> + struct max5432_data *data;
> +
> + indio_dev = devm_iio_device_alloc(dev, sizeof(struct max5432_data));
> + if (!indio_dev)
> + return -ENOMEM;
> +
> + i2c_set_clientdata(client, indio_dev);
> +
> + data = iio_priv(indio_dev);
> + data->client = client;
> + data->ohm = (unsigned long)of_device_get_match_data(dev);
> +
> + indio_dev->dev.parent = dev;
> + indio_dev->info = &max5432_info;
> + indio_dev->channels = max5432_channels;
> + indio_dev->num_channels = ARRAY_SIZE(max5432_channels);
> + indio_dev->name = client->name;
> +
> + return devm_iio_device_register(dev, indio_dev);
> +}
> +
> +static const struct of_device_id max5432_dt_ids[] = {
> + { .compatible = "maxim,max5432", .data = (void *)MAX5432_OHM_50K },
> + { .compatible = "maxim,max5433", .data = (void *)MAX5432_OHM_100K },
> + { .compatible = "maxim,max5434", .data = (void *)MAX5432_OHM_50K },
> + { .compatible = "maxim,max5435", .data = (void *)MAX5432_OHM_100K },
> + { /* sentinel */ }
> +};
> +MODULE_DEVICE_TABLE(of, max5432_dt_ids);
> +
> +static struct i2c_driver max5432_driver = {
> + .driver = {
> + .name = "max5432",
> + .of_match_table = of_match_ptr(max5432_dt_ids),
> + },
> + .probe = max5432_probe,
> +};
> +
> +module_i2c_driver(max5432_driver);
> +
> +MODULE_AUTHOR("Martin Kaiser <martin@kaiser.cx>");
> +MODULE_DESCRIPTION("max5432-max5435 digital potentiometers");
> +MODULE_LICENSE("GPL v2");
^ permalink raw reply
* Re: [PATCH v4 2/2] dt-bindings: iio: potentiometer: add max5432.yaml binding
From: Jonathan Cameron @ 2019-08-05 13:32 UTC (permalink / raw)
To: Rob Herring
Cc: Martin Kaiser, Hartmut Knaack, Lars-Peter Clausen,
open list:IIO SUBSYSTEM AND DRIVERS, devicetree,
linux-kernel@vger.kernel.org
In-Reply-To: <CAL_JsqK9iuxQEh3s2_AgQhSa19Coq7kSFB497KUMQnjQNU+ELw@mail.gmail.com>
On Wed, 31 Jul 2019 10:50:36 -0600
Rob Herring <robh+dt@kernel.org> wrote:
> On Wed, Jul 31, 2019 at 8:07 AM Martin Kaiser <martin@kaiser.cx> wrote:
> >
> > Add a binding for the Maxim Integrated MAX5432-MAX5435 family of digital
> > potentiometers.
> >
> > Signed-off-by: Martin Kaiser <martin@kaiser.cx>
> > ---
> > changes in v4
> > - fix the dt bindings
> > - replace ic20 with i2c
> > - document the reg property
> > - add additionalProperties and required
> >
> > changes in v3
> > - split dt bindings and driver code into separate patches
> > - use yaml format for dt bindings
> > - fix formatting of parameter lists
> >
> > changes in v2
> > - use MAX5432_ prefix for all defines
> > - fix indentation
> > - convert void * to unsigned long, not to u32
> > (warning from kbuild test robot)
> >
> > .../bindings/iio/potentiometer/max5432.yaml | 44 ++++++++++++++++++++++
> > 1 file changed, 44 insertions(+)
> > create mode 100644 Documentation/devicetree/bindings/iio/potentiometer/max5432.yaml
>
> Reviewed-by: Rob Herring <robh@kernel.org>
Applied to the togreg branch of iio.git and pushed out as testing for the
autobuilders to play with it.
Thanks,
Jonathan
^ permalink raw reply
* Re: [PATCH v4 2/2] mmc: Add support for the ASPEED SD controller
From: Adrian Hunter @ 2019-08-05 13:36 UTC (permalink / raw)
To: Andrew Jeffery, linux-mmc
Cc: ulf.hansson, robh+dt, mark.rutland, joel, devicetree,
linux-arm-kernel, linux-aspeed, linux-kernel, ryanchen.aspeed
In-Reply-To: <20190805025155.9020-3-andrew@aj.id.au>
On 5/08/19 5:51 AM, Andrew Jeffery wrote:
> Add a minimal driver for ASPEED's SD controller, which exposes two
> SDHCIs.
>
> The ASPEED design implements a common register set for the SDHCIs, and
> moves some of the standard configuration elements out to this common
> area (e.g. 8-bit mode, and card detect configuration which is not
> currently supported).
>
> The SD controller has a dedicated hardware interrupt that is shared
> between the slots. The common register set exposes information on which
> slot triggered the interrupt; early revisions of the patch introduced an
> irqchip for the register, but reality is it doesn't behave as an
> irqchip, and the result fits awkwardly into the irqchip APIs. Instead
> I've taken the simple approach of using the IRQ as a shared IRQ with
> some minor performance impact for the second slot.
>
> Ryan was the original author of the patch - I've taken his work and
> massaged it to drop the irqchip support and rework the devicetree
> integration. The driver has been smoke tested under qemu against a
> minimal SD controller model and lightly tested on an ast2500-evb.
>
> Signed-off-by: Ryan Chen <ryanchen.aspeed@gmail.com>
> Signed-off-by: Andrew Jeffery <andrew@aj.id.au>
One minor comment otherwise:
Acked-by: Adrian Hunter <adrian.hunter@intel.com>
>
> ---
> v3: No change
> v2:
> * Add AST2600 compatible
> * Drop SDHCI_QUIRK2_CLOCK_DIV_ZERO_BROKEN
> * Ensure slot number is valid
> * Fix build with CONFIG_MODULES
> * Fix module license string
> * Non-PCI devices won't die
> * Rename aspeed_sdc_configure_8bit_mode()
> * Rename aspeed_sdhci_pdata
> * Switch to sdhci_enable_clk()
> * Use PTR_ERR() on the right `struct platform_device *`
> ---
> drivers/mmc/host/Kconfig | 12 ++
> drivers/mmc/host/Makefile | 1 +
> drivers/mmc/host/sdhci-of-aspeed.c | 328 +++++++++++++++++++++++++++++
> 3 files changed, 341 insertions(+)
> create mode 100644 drivers/mmc/host/sdhci-of-aspeed.c
>
> diff --git a/drivers/mmc/host/Kconfig b/drivers/mmc/host/Kconfig
> index 14d89a108edd..0f8a230de2f3 100644
> --- a/drivers/mmc/host/Kconfig
> +++ b/drivers/mmc/host/Kconfig
> @@ -154,6 +154,18 @@ config MMC_SDHCI_OF_ARASAN
>
> If unsure, say N.
>
> +config MMC_SDHCI_OF_ASPEED
> + tristate "SDHCI OF support for the ASPEED SDHCI controller"
> + depends on MMC_SDHCI_PLTFM
> + depends on OF
> + help
> + This selects the ASPEED Secure Digital Host Controller Interface.
> +
> + If you have a controller with this interface, say Y or M here. You
> + also need to enable an appropriate bus interface.
> +
> + If unsure, say N.
> +
> config MMC_SDHCI_OF_AT91
> tristate "SDHCI OF support for the Atmel SDMMC controller"
> depends on MMC_SDHCI_PLTFM
> diff --git a/drivers/mmc/host/Makefile b/drivers/mmc/host/Makefile
> index 73578718f119..390ee162fe71 100644
> --- a/drivers/mmc/host/Makefile
> +++ b/drivers/mmc/host/Makefile
> @@ -84,6 +84,7 @@ obj-$(CONFIG_MMC_SDHCI_ESDHC_IMX) += sdhci-esdhc-imx.o
> obj-$(CONFIG_MMC_SDHCI_DOVE) += sdhci-dove.o
> obj-$(CONFIG_MMC_SDHCI_TEGRA) += sdhci-tegra.o
> obj-$(CONFIG_MMC_SDHCI_OF_ARASAN) += sdhci-of-arasan.o
> +obj-$(CONFIG_MMC_SDHCI_OF_ASPEED) += sdhci-of-aspeed.o
> obj-$(CONFIG_MMC_SDHCI_OF_AT91) += sdhci-of-at91.o
> obj-$(CONFIG_MMC_SDHCI_OF_ESDHC) += sdhci-of-esdhc.o
> obj-$(CONFIG_MMC_SDHCI_OF_HLWD) += sdhci-of-hlwd.o
> diff --git a/drivers/mmc/host/sdhci-of-aspeed.c b/drivers/mmc/host/sdhci-of-aspeed.c
> new file mode 100644
> index 000000000000..d31785ec90d7
> --- /dev/null
> +++ b/drivers/mmc/host/sdhci-of-aspeed.c
> @@ -0,0 +1,328 @@
> +// SPDX-License-Identifier: GPL-2.0-or-later
> +/* Copyright (C) 2019 ASPEED Technology Inc. */
> +/* Copyright (C) 2019 IBM Corp. */
> +
> +#include <linux/clk.h>
> +#include <linux/delay.h>
> +#include <linux/device.h>
> +#include <linux/io.h>
> +#include <linux/mmc/host.h>
> +#include <linux/module.h>
> +#include <linux/of_address.h>
> +#include <linux/of.h>
> +#include <linux/of_platform.h>
> +#include <linux/platform_device.h>
> +#include <linux/spinlock.h>
> +
> +#include "sdhci-pltfm.h"
> +
> +#define ASPEED_SDC_INFO 0x00
> +#define ASPEED_SDC_S1MMC8 BIT(25)
> +#define ASPEED_SDC_S0MMC8 BIT(24)
> +
> +struct aspeed_sdc {
> + struct clk *clk;
> + struct resource *res;
> +
> + spinlock_t lock;
> + void __iomem *regs;
> +};
> +
> +struct aspeed_sdhci {
> + struct aspeed_sdc *parent;
> + u32 width_mask;
> +};
> +
> +static void aspeed_sdc_configure_8bit_mode(struct aspeed_sdc *sdc,
> + struct aspeed_sdhci *sdhci,
> + bool bus8)
> +{
> + u32 info;
> +
> + /* Set/clear 8 bit mode */
> + spin_lock(&sdc->lock);
> + info = readl(sdc->regs + ASPEED_SDC_INFO);
> + if (bus8)
> + info |= sdhci->width_mask;
> + else
> + info &= ~sdhci->width_mask;
> + writel(info, sdc->regs + ASPEED_SDC_INFO);
> + spin_unlock(&sdc->lock);
> +}
> +
> +static void aspeed_sdhci_set_clock(struct sdhci_host *host, unsigned int clock)
> +{
> + int div;
> + u16 clk;
> +
> + if (clock == host->clock)
> + return;
> +
> + sdhci_writew(host, 0, SDHCI_CLOCK_CONTROL);
> +
> + if (clock == 0)
> + goto out;
> +
> + for (div = 1; div < 256; div *= 2) {
> + if ((host->max_clk / div) <= clock)
> + break;
> + }
> + div >>= 1;
> +
> + clk = div << SDHCI_DIVIDER_SHIFT;
> +
> + sdhci_enable_clk(host, clk);
> +
> +out:
> + host->clock = clock;
> +}
> +
> +static void aspeed_sdhci_set_bus_width(struct sdhci_host *host, int width)
> +{
> + struct sdhci_pltfm_host *pltfm_priv;
> + struct aspeed_sdhci *aspeed_sdhci;
> + struct aspeed_sdc *aspeed_sdc;
> + u8 ctrl;
> +
> + pltfm_priv = sdhci_priv(host);
> + aspeed_sdhci = sdhci_pltfm_priv(pltfm_priv);
> + aspeed_sdc = aspeed_sdhci->parent;
> +
> + /* Set/clear 8-bit mode */
> + aspeed_sdc_configure_8bit_mode(aspeed_sdc, aspeed_sdhci,
> + width == MMC_BUS_WIDTH_8);
> +
> + /* Set/clear 1 or 4 bit mode */
> + ctrl = sdhci_readb(host, SDHCI_HOST_CONTROL);
> + if (width == MMC_BUS_WIDTH_4)
> + ctrl |= SDHCI_CTRL_4BITBUS;
> + else
> + ctrl &= ~SDHCI_CTRL_4BITBUS;
> + sdhci_writeb(host, ctrl, SDHCI_HOST_CONTROL);
> +}
> +
> +static const struct sdhci_ops aspeed_sdhci_ops = {
> + .set_clock = aspeed_sdhci_set_clock,
> + .get_max_clock = sdhci_pltfm_clk_get_max_clock,
> + .set_bus_width = aspeed_sdhci_set_bus_width,
> + .get_timeout_clock = sdhci_pltfm_clk_get_max_clock,
> + .reset = sdhci_reset,
> + .set_uhs_signaling = sdhci_set_uhs_signaling,
> +};
> +
> +static const struct sdhci_pltfm_data aspeed_sdhci_pdata = {
> + .ops = &aspeed_sdhci_ops,
> + .quirks = SDHCI_QUIRK_CAP_CLOCK_BASE_BROKEN,
> +};
> +
> +static inline int aspeed_sdhci_calculate_slot(struct aspeed_sdhci *dev,
> + struct resource *res)
> +{
> + resource_size_t delta;
> +
> + if (!res || resource_type(res) != IORESOURCE_MEM)
> + return -EINVAL;
> +
> + if (res->start < dev->parent->res->start)
> + return -EINVAL;
> +
> + delta = res->start - dev->parent->res->start;
> + if (delta & (0x100 - 1))
> + return -EINVAL;
> +
> + return (delta / 0x100) - 1;
> +}
> +
> +static int aspeed_sdhci_probe(struct platform_device *pdev)
> +{
> + struct sdhci_pltfm_host *pltfm_host;
> + struct aspeed_sdhci *dev;
> + struct sdhci_host *host;
> + struct resource *res;
> + int slot;
> + int ret;
> +
> + host = sdhci_pltfm_init(pdev, &aspeed_sdhci_pdata, sizeof(*dev));
> + if (IS_ERR(host))
> + return PTR_ERR(host);
> +
> + pltfm_host = sdhci_priv(host);
> + dev = sdhci_pltfm_priv(pltfm_host);
> + dev->parent = dev_get_drvdata(pdev->dev.parent);
> +
> + res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
> + slot = aspeed_sdhci_calculate_slot(dev, res);
> +
> + if (slot < 0)
> + return slot;
> + else if (slot >= 2)
> + return -EINVAL;
> +
> + dev_info(&pdev->dev, "Configuring for slot %d\n", slot);
> + dev->width_mask = !slot ? ASPEED_SDC_S0MMC8 : ASPEED_SDC_S1MMC8;
> +
> + sdhci_get_of_property(pdev);
> +
> + pltfm_host->clk = devm_clk_get(&pdev->dev, NULL);
> + if (IS_ERR(pltfm_host->clk))
> + return PTR_ERR(pltfm_host->clk);
> +
> + ret = clk_prepare_enable(pltfm_host->clk);
> + if (ret) {
> + dev_err(&pdev->dev, "Unable to enable SDIO clock\n");
> + goto err_pltfm_free;
> + }
> +
> + ret = mmc_of_parse(host->mmc);
> + if (ret)
> + goto err_sdhci_add;
> +
> + ret = sdhci_add_host(host);
> + if (ret)
> + goto err_sdhci_add;
> +
> + return 0;
> +
> +err_sdhci_add:
> + clk_disable_unprepare(pltfm_host->clk);
> +err_pltfm_free:
> + sdhci_pltfm_free(pdev);
> + return ret;
> +}
> +
> +static int aspeed_sdhci_remove(struct platform_device *pdev)
> +{
> + struct sdhci_pltfm_host *pltfm_host;
> + struct sdhci_host *host;
> + int dead = 0;
> +
> + host = platform_get_drvdata(pdev);
> + pltfm_host = sdhci_priv(host);
> +
> + sdhci_remove_host(host, dead);
> +
> + clk_disable_unprepare(pltfm_host->clk);
> +
> + sdhci_pltfm_free(pdev);
> +
> + return 0;
> +}
> +
> +static const struct of_device_id aspeed_sdhci_of_match[] = {
> + { .compatible = "aspeed,ast2400-sdhci", },
> + { .compatible = "aspeed,ast2500-sdhci", },
> + { .compatible = "aspeed,ast2600-sdhci", },
> + { }
> +};
> +
> +static struct platform_driver aspeed_sdhci_driver = {
> + .driver = {
> + .name = "sdhci-aspeed",
> + .of_match_table = aspeed_sdhci_of_match,
> + },
> + .probe = aspeed_sdhci_probe,
> + .remove = aspeed_sdhci_remove,
> +};
> +
> +static int aspeed_sdc_probe(struct platform_device *pdev)
> +
> +{
> + struct device_node *parent, *child;
> + struct aspeed_sdc *sdc;
> + int ret;
> +
> + sdc = devm_kzalloc(&pdev->dev, sizeof(*sdc), GFP_KERNEL);
> + if (!sdc)
> + return -ENOMEM;
> +
> + spin_lock_init(&sdc->lock);
> +
> + sdc->clk = devm_clk_get(&pdev->dev, NULL);
> + if (IS_ERR(sdc->clk))
> + return PTR_ERR(sdc->clk);
> +
> + ret = clk_prepare_enable(sdc->clk);
> + if (ret) {
> + dev_err(&pdev->dev, "Unable to enable SDCLK\n");
> + return ret;
> + }
> +
> + sdc->res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
> + sdc->regs = devm_ioremap_resource(&pdev->dev, sdc->res);
> + if (IS_ERR(sdc->regs)) {
> + ret = PTR_ERR(sdc->regs);
> + goto err_clk;
> + }
> +
> + dev_set_drvdata(&pdev->dev, sdc);
> +
> + parent = pdev->dev.of_node;
> + for_each_available_child_of_node(parent, child) {
> + struct platform_device *cpdev;
> +
> + cpdev = of_platform_device_create(child, NULL, &pdev->dev);
> + if (IS_ERR(cpdev)) {
> + of_node_put(child);
> + ret = PTR_ERR(cpdev);
> + goto err_clk;
> + }
> + }
> +
> + return 0;
> +
> +err_clk:
> + clk_disable_unprepare(sdc->clk);
> + return ret;
> +}
> +
> +static int aspeed_sdc_remove(struct platform_device *pdev)
> +{
> + struct aspeed_sdc *sdc = dev_get_drvdata(&pdev->dev);
> +
> + clk_disable_unprepare(sdc->clk);
> +
> + return 0;
> +}
> +
> +static const struct of_device_id aspeed_sdc_of_match[] = {
> + { .compatible = "aspeed,ast2400-sd-controller", },
> + { .compatible = "aspeed,ast2500-sd-controller", },
> + { .compatible = "aspeed,ast2600-sd-controller", },
> + { }
> +};
> +
> +MODULE_DEVICE_TABLE(of, aspeed_sdc_of_match);
> +
> +static struct platform_driver aspeed_sdc_driver = {
> + .driver = {
> + .name = "sd-controller-aspeed",
> + .pm = &sdhci_pltfm_pmops,
> + .of_match_table = aspeed_sdc_of_match,
> + },
> + .probe = aspeed_sdc_probe,
> + .remove = aspeed_sdc_remove,
> +};
> +
> +static int __init aspeed_sdc_init(void)
> +{
> + int rc;
> +
> + rc = platform_driver_register(&aspeed_sdhci_driver);
> + if (rc < 0)
> + return rc;
> +
> + return platform_driver_register(&aspeed_sdc_driver);
Shouldn't aspeed_sdhci_driver be unregistered here if there was an error.
> +}
> +module_init(aspeed_sdc_init);
> +
> +static void __exit aspeed_sdc_exit(void)
> +{
> + platform_driver_unregister(&aspeed_sdc_driver);
> + platform_driver_unregister(&aspeed_sdhci_driver);
> +}
> +module_exit(aspeed_sdc_exit);
> +
> +MODULE_DESCRIPTION("Driver for the ASPEED SD/SDIO/SDHCI Controllers");
> +MODULE_AUTHOR("Ryan Chen <ryan_chen@aspeedtech.com>");
> +MODULE_AUTHOR("Andrew Jeffery <andrew@aj.id.au>");
> +MODULE_LICENSE("GPL");
>
^ permalink raw reply
* [PATCH 0/3] drm/meson: convert bindings to YAML schemas
From: Neil Armstrong @ 2019-08-05 13:43 UTC (permalink / raw)
To: robh+dt; +Cc: Neil Armstrong, devicetree, dri-devel, linux-amlogic,
linux-kernel
This patchset converts the existing text bindings to YAML schemas.
Those bindings have a lot of texts, thus is interesting to convert.
All have been tested using :
$ make ARCH=arm64 dtbs_check
Issues with the amlogic arm64 DTs has already been identified thanks
to the validation scripts. The DT fixes will be pushed once these yaml
bindings are acked.
Neil Armstrong (3):
dt-bindings: display: amlogic,meson-dw-hdmi: convert to yaml
dt-bindings: display: amlogic,meson-vpu: convert to yaml
MAINTAINERS: Update with Amlogic DRM bindings converted as YAML
.../display/amlogic,meson-dw-hdmi.txt | 119 -------------
.../display/amlogic,meson-dw-hdmi.yaml | 160 ++++++++++++++++++
.../bindings/display/amlogic,meson-vpu.txt | 121 -------------
.../bindings/display/amlogic,meson-vpu.yaml | 153 +++++++++++++++++
MAINTAINERS | 4 +-
5 files changed, 315 insertions(+), 242 deletions(-)
delete mode 100644 Documentation/devicetree/bindings/display/amlogic,meson-dw-hdmi.txt
create mode 100644 Documentation/devicetree/bindings/display/amlogic,meson-dw-hdmi.yaml
delete mode 100644 Documentation/devicetree/bindings/display/amlogic,meson-vpu.txt
create mode 100644 Documentation/devicetree/bindings/display/amlogic,meson-vpu.yaml
--
2.22.0
^ permalink raw reply
* [PATCH 1/3] dt-bindings: display: amlogic, meson-dw-hdmi: convert to yaml
From: Neil Armstrong @ 2019-08-05 13:43 UTC (permalink / raw)
To: robh+dt; +Cc: devicetree, linux-amlogic, linux-kernel, dri-devel,
Neil Armstrong
In-Reply-To: <20190805134319.737-1-narmstrong@baylibre.com>
Now that we have the DT validation in place, let's convert the device tree
bindings for the Amlogic Synopsys DW-HDMI specifics over to YAML schemas.
The original example and usage of clock-names uses a reversed "isfr"
and "iahb" clock-names, the rewritten YAML bindings uses the reversed
instead of fixing the device trees order.
Signed-off-by: Neil Armstrong <narmstrong@baylibre.com>
---
.../display/amlogic,meson-dw-hdmi.txt | 119 -------------
.../display/amlogic,meson-dw-hdmi.yaml | 160 ++++++++++++++++++
2 files changed, 160 insertions(+), 119 deletions(-)
delete mode 100644 Documentation/devicetree/bindings/display/amlogic,meson-dw-hdmi.txt
create mode 100644 Documentation/devicetree/bindings/display/amlogic,meson-dw-hdmi.yaml
diff --git a/Documentation/devicetree/bindings/display/amlogic,meson-dw-hdmi.txt b/Documentation/devicetree/bindings/display/amlogic,meson-dw-hdmi.txt
deleted file mode 100644
index 3a50a7862cf3..000000000000
--- a/Documentation/devicetree/bindings/display/amlogic,meson-dw-hdmi.txt
+++ /dev/null
@@ -1,119 +0,0 @@
-Amlogic specific extensions to the Synopsys Designware HDMI Controller
-======================================================================
-
-The Amlogic Meson Synopsys Designware Integration is composed of :
-- A Synopsys DesignWare HDMI Controller IP
-- A TOP control block controlling the Clocks and PHY
-- A custom HDMI PHY in order to convert video to TMDS signal
- ___________________________________
-| HDMI TOP |<= HPD
-|___________________________________|
-| | |
-| Synopsys HDMI | HDMI PHY |=> TMDS
-| Controller |________________|
-|___________________________________|<=> DDC
-
-The HDMI TOP block only supports HPD sensing.
-The Synopsys HDMI Controller interrupt is routed through the
-TOP Block interrupt.
-Communication to the TOP Block and the Synopsys HDMI Controller is done
-via a pair of dedicated addr+read/write registers.
-The HDMI PHY is configured by registers in the HHI register block.
-
-Pixel data arrives in 4:4:4 format from the VENC block and the VPU HDMI mux
-selects either the ENCI encoder for the 576i or 480i formats or the ENCP
-encoder for all the other formats including interlaced HD formats.
-
-The VENC uses a DVI encoder on top of the ENCI or ENCP encoders to generate
-DVI timings for the HDMI controller.
-
-Amlogic Meson GXBB, GXL and GXM SoCs families embeds the Synopsys DesignWare
-HDMI TX IP version 2.01a with HDCP and I2C & S/PDIF
-audio source interfaces.
-
-Required properties:
-- compatible: value should be different for each SoC family as :
- - GXBB (S905) : "amlogic,meson-gxbb-dw-hdmi"
- - GXL (S905X, S905D) : "amlogic,meson-gxl-dw-hdmi"
- - GXM (S912) : "amlogic,meson-gxm-dw-hdmi"
- followed by the common "amlogic,meson-gx-dw-hdmi"
- - G12A (S905X2, S905Y2, S905D2) : "amlogic,meson-g12a-dw-hdmi"
-- reg: Physical base address and length of the controller's registers.
-- interrupts: The HDMI interrupt number
-- clocks, clock-names : must have the phandles to the HDMI iahb and isfr clocks,
- and the Amlogic Meson venci clocks as described in
- Documentation/devicetree/bindings/clock/clock-bindings.txt,
- the clocks are soc specific, the clock-names should be "iahb", "isfr", "venci"
-- resets, resets-names: must have the phandles to the HDMI apb, glue and phy
- resets as described in :
- Documentation/devicetree/bindings/reset/reset.txt,
- the reset-names should be "hdmitx_apb", "hdmitx", "hdmitx_phy"
-
-Optional properties:
-- hdmi-supply: Optional phandle to an external 5V regulator to power the HDMI
- logic, as described in the file ../regulator/regulator.txt
-
-Required nodes:
-
-The connections to the HDMI ports are modeled using the OF graph
-bindings specified in Documentation/devicetree/bindings/graph.txt.
-
-The following table lists for each supported model the port number
-corresponding to each HDMI output and input.
-
- Port 0 Port 1
------------------------------------------
- S905 (GXBB) VENC Input TMDS Output
- S905X (GXL) VENC Input TMDS Output
- S905D (GXL) VENC Input TMDS Output
- S912 (GXM) VENC Input TMDS Output
- S905X2 (G12A) VENC Input TMDS Output
- S905Y2 (G12A) VENC Input TMDS Output
- S905D2 (G12A) VENC Input TMDS Output
-
-Example:
-
-hdmi-connector {
- compatible = "hdmi-connector";
- type = "a";
-
- port {
- hdmi_connector_in: endpoint {
- remote-endpoint = <&hdmi_tx_tmds_out>;
- };
- };
-};
-
-hdmi_tx: hdmi-tx@c883a000 {
- compatible = "amlogic,meson-gxbb-dw-hdmi", "amlogic,meson-gx-dw-hdmi";
- reg = <0x0 0xc883a000 0x0 0x1c>;
- interrupts = <GIC_SPI 57 IRQ_TYPE_EDGE_RISING>;
- resets = <&reset RESET_HDMITX_CAPB3>,
- <&reset RESET_HDMI_SYSTEM_RESET>,
- <&reset RESET_HDMI_TX>;
- reset-names = "hdmitx_apb", "hdmitx", "hdmitx_phy";
- clocks = <&clkc CLKID_HDMI_PCLK>,
- <&clkc CLKID_CLK81>,
- <&clkc CLKID_GCLK_VENCI_INT0>;
- clock-names = "isfr", "iahb", "venci";
- #address-cells = <1>;
- #size-cells = <0>;
-
- /* VPU VENC Input */
- hdmi_tx_venc_port: port@0 {
- reg = <0>;
-
- hdmi_tx_in: endpoint {
- remote-endpoint = <&hdmi_tx_out>;
- };
- };
-
- /* TMDS Output */
- hdmi_tx_tmds_port: port@1 {
- reg = <1>;
-
- hdmi_tx_tmds_out: endpoint {
- remote-endpoint = <&hdmi_connector_in>;
- };
- };
-};
diff --git a/Documentation/devicetree/bindings/display/amlogic,meson-dw-hdmi.yaml b/Documentation/devicetree/bindings/display/amlogic,meson-dw-hdmi.yaml
new file mode 100644
index 000000000000..1212aa7a624f
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/amlogic,meson-dw-hdmi.yaml
@@ -0,0 +1,160 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+# Copyright 2019 BayLibre, SAS
+%YAML 1.2
+---
+$id: "http://devicetree.org/schemas/display/amlogic,meson-dw-hdmi.yaml#"
+$schema: "http://devicetree.org/meta-schemas/core.yaml#"
+
+title: Amlogic specific extensions to the Synopsys Designware HDMI Controller
+
+maintainers:
+ - Neil Armstrong <narmstrong@baylibre.com>
+
+description: |
+ The Amlogic Meson Synopsys Designware Integration is composed of
+ - A Synopsys DesignWare HDMI Controller IP
+ - A TOP control block controlling the Clocks and PHY
+ - A custom HDMI PHY in order to convert video to TMDS signal
+ ___________________________________
+ | HDMI TOP |<= HPD
+ |___________________________________|
+ | | |
+ | Synopsys HDMI | HDMI PHY |=> TMDS
+ | Controller |________________|
+ |___________________________________|<=> DDC
+
+ The HDMI TOP block only supports HPD sensing.
+ The Synopsys HDMI Controller interrupt is routed through the
+ TOP Block interrupt.
+ Communication to the TOP Block and the Synopsys HDMI Controller is done
+ via a pair of dedicated addr+read/write registers.
+ The HDMI PHY is configured by registers in the HHI register block.
+
+ Pixel data arrives in "4:4:4" format from the VENC block and the VPU HDMI mux
+ selects either the ENCI encoder for the 576i or 480i formats or the ENCP
+ encoder for all the other formats including interlaced HD formats.
+
+ The VENC uses a DVI encoder on top of the ENCI or ENCP encoders to generate
+ DVI timings for the HDMI controller.
+
+ Amlogic Meson GXBB, GXL and GXM SoCs families embeds the Synopsys DesignWare
+ HDMI TX IP version 2.01a with HDCP and I2C & S/PDIF
+ audio source interfaces.
+
+ The following table lists for each supported model the port number
+ corresponding to each HDMI output and input.
+
+ Port 0 Port 1
+ -----------------------------------------
+ S905 (GXBB) VENC Input TMDS Output
+ S905X (GXL) VENC Input TMDS Output
+ S905D (GXL) VENC Input TMDS Output
+ S912 (GXM) VENC Input TMDS Output
+ S905X2 (G12A) VENC Input TMDS Output
+ S905Y2 (G12A) VENC Input TMDS Output
+ S905D2 (G12A) VENC Input TMDS Output
+
+properties:
+ compatible:
+ oneOf:
+ - items:
+ - enum:
+ - amlogic,meson-gxbb-dw-hdmi # GXBB (S905)
+ - amlogic,meson-gxl-dw-hdmi # GXL (S905X, S905D)
+ - amlogic,meson-gxm-dw-hdmi # GXM (S912)
+ - const: amlogic,meson-gx-dw-hdmi
+ - enum:
+ - amlogic,meson-g12a-dw-hdmi # G12A (S905X2, S905Y2, S905D2)
+
+ reg:
+ maxItems: 1
+
+ interrupts:
+ maxItems: 1
+
+ clocks:
+ minItems: 3
+
+ clock-names:
+ items:
+ - const: isfr
+ - const: iahb
+ - const: venci
+
+ resets:
+ minItems: 3
+
+ reset-names:
+ items:
+ - const: hdmitx_apb
+ - const: hdmitx
+ - const: hdmitx_phy
+
+ hdmi-supply:
+ description: phandle to an external 5V regulator to power the HDMI logic
+ allOf:
+ - $ref: /schemas/types.yaml#/definitions/phandle
+
+ port@0:
+ type: object
+ description:
+ A port node modeled using the OF graph
+ bindings specified in Documentation/devicetree/bindings/graph.txt.
+
+ port@1:
+ type: object
+ description:
+ A port node modeled using the OF graph
+ bindings specified in Documentation/devicetree/bindings/graph.txt.
+
+ "#address-cells":
+ const: 1
+
+ "#size-cells":
+ const: 0
+
+required:
+ - compatible
+ - reg
+ - interrupts
+ - clocks
+ - clock-names
+ - resets
+ - reset-names
+ - port@0
+ - port@1
+ - "#address-cells"
+ - "#size-cells"
+
+examples:
+ - |
+ hdmi_tx: hdmi-tx@c883a000 {
+ compatible = "amlogic,meson-gxbb-dw-hdmi", "amlogic,meson-gx-dw-hdmi";
+ reg = <0xc883a000 0x1c>;
+ interrupts = <57>;
+ resets = <&reset_apb>, <&reset_hdmitx>, <&reset_hdmitx_phy>;
+ reset-names = "hdmitx_apb", "hdmitx", "hdmitx_phy";
+ clocks = <&clk_isfr>, <&clk_iahb>, <&clk_venci>;
+ clock-names = "isfr", "iahb", "venci";
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ /* VPU VENC Input */
+ hdmi_tx_venc_port: port@0 {
+ reg = <0>;
+
+ hdmi_tx_in: endpoint {
+ remote-endpoint = <&hdmi_tx_out>;
+ };
+ };
+
+ /* TMDS Output */
+ hdmi_tx_tmds_port: port@1 {
+ reg = <1>;
+
+ hdmi_tx_tmds_out: endpoint {
+ remote-endpoint = <&hdmi_connector_in>;
+ };
+ };
+ };
+
--
2.22.0
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply related
* [PATCH 2/3] dt-bindings: display: amlogic,meson-vpu: convert to yaml
From: Neil Armstrong @ 2019-08-05 13:43 UTC (permalink / raw)
To: robh+dt; +Cc: Neil Armstrong, devicetree, dri-devel, linux-amlogic,
linux-kernel
In-Reply-To: <20190805134319.737-1-narmstrong@baylibre.com>
Now that we have the DT validation in place, let's convert the device tree
bindings for the Amlogic Display Controller over to YAML schemas.
The original example has a leftover "dmc" memory cell, that has been
removed in the yaml rewrite.
Signed-off-by: Neil Armstrong <narmstrong@baylibre.com>
---
.../bindings/display/amlogic,meson-vpu.txt | 121 --------------
.../bindings/display/amlogic,meson-vpu.yaml | 153 ++++++++++++++++++
2 files changed, 153 insertions(+), 121 deletions(-)
delete mode 100644 Documentation/devicetree/bindings/display/amlogic,meson-vpu.txt
create mode 100644 Documentation/devicetree/bindings/display/amlogic,meson-vpu.yaml
diff --git a/Documentation/devicetree/bindings/display/amlogic,meson-vpu.txt b/Documentation/devicetree/bindings/display/amlogic,meson-vpu.txt
deleted file mode 100644
index be40a780501c..000000000000
--- a/Documentation/devicetree/bindings/display/amlogic,meson-vpu.txt
+++ /dev/null
@@ -1,121 +0,0 @@
-Amlogic Meson Display Controller
-================================
-
-The Amlogic Meson Display controller is composed of several components
-that are going to be documented below:
-
-DMC|---------------VPU (Video Processing Unit)----------------|------HHI------|
- | vd1 _______ _____________ _________________ | |
-D |-------| |----| | | | | HDMI PLL |
-D | vd2 | VIU | | Video Post | | Video Encoders |<---|-----VCLK |
-R |-------| |----| Processing | | | | |
- | osd2 | | | |---| Enci ----------|----|-----VDAC------|
-R |-------| CSC |----| Scalers | | Encp ----------|----|----HDMI-TX----|
-A | osd1 | | | Blenders | | Encl ----------|----|---------------|
-M |-------|______|----|____________| |________________| | |
-___|__________________________________________________________|_______________|
-
-
-VIU: Video Input Unit
----------------------
-
-The Video Input Unit is in charge of the pixel scanout from the DDR memory.
-It fetches the frames addresses, stride and parameters from the "Canvas" memory.
-This part is also in charge of the CSC (Colorspace Conversion).
-It can handle 2 OSD Planes and 2 Video Planes.
-
-VPP: Video Post Processing
---------------------------
-
-The Video Post Processing is in charge of the scaling and blending of the
-various planes into a single pixel stream.
-There is a special "pre-blending" used by the video planes with a dedicated
-scaler and a "post-blending" to merge with the OSD Planes.
-The OSD planes also have a dedicated scaler for one of the OSD.
-
-VENC: Video Encoders
---------------------
-
-The VENC is composed of the multiple pixel encoders :
- - ENCI : Interlace Video encoder for CVBS and Interlace HDMI
- - ENCP : Progressive Video Encoder for HDMI
- - ENCL : LCD LVDS Encoder
-The VENC Unit gets a Pixel Clocks (VCLK) from a dedicated HDMI PLL and clock
-tree and provides the scanout clock to the VPP and VIU.
-The ENCI is connected to a single VDAC for Composite Output.
-The ENCI and ENCP are connected to an on-chip HDMI Transceiver.
-
-Device Tree Bindings:
----------------------
-
-VPU: Video Processing Unit
---------------------------
-
-Required properties:
-- compatible: value should be different for each SoC family as :
- - GXBB (S905) : "amlogic,meson-gxbb-vpu"
- - GXL (S905X, S905D) : "amlogic,meson-gxl-vpu"
- - GXM (S912) : "amlogic,meson-gxm-vpu"
- followed by the common "amlogic,meson-gx-vpu"
- - G12A (S905X2, S905Y2, S905D2) : "amlogic,meson-g12a-vpu"
-- reg: base address and size of he following memory-mapped regions :
- - vpu
- - hhi
-- reg-names: should contain the names of the previous memory regions
-- interrupts: should contain the VENC Vsync interrupt number
-- amlogic,canvas: phandle to canvas provider node as described in the file
- ../soc/amlogic/amlogic,canvas.txt
-
-Optional properties:
-- power-domains: Optional phandle to associated power domain as described in
- the file ../power/power_domain.txt
-
-Required nodes:
-
-The connections to the VPU output video ports are modeled using the OF graph
-bindings specified in Documentation/devicetree/bindings/graph.txt.
-
-The following table lists for each supported model the port number
-corresponding to each VPU output.
-
- Port 0 Port 1
------------------------------------------
- S905 (GXBB) CVBS VDAC HDMI-TX
- S905X (GXL) CVBS VDAC HDMI-TX
- S905D (GXL) CVBS VDAC HDMI-TX
- S912 (GXM) CVBS VDAC HDMI-TX
- S905X2 (G12A) CVBS VDAC HDMI-TX
- S905Y2 (G12A) CVBS VDAC HDMI-TX
- S905D2 (G12A) CVBS VDAC HDMI-TX
-
-Example:
-
-tv-connector {
- compatible = "composite-video-connector";
-
- port {
- tv_connector_in: endpoint {
- remote-endpoint = <&cvbs_vdac_out>;
- };
- };
-};
-
-vpu: vpu@d0100000 {
- compatible = "amlogic,meson-gxbb-vpu";
- reg = <0x0 0xd0100000 0x0 0x100000>,
- <0x0 0xc883c000 0x0 0x1000>,
- <0x0 0xc8838000 0x0 0x1000>;
- reg-names = "vpu", "hhi", "dmc";
- interrupts = <GIC_SPI 3 IRQ_TYPE_EDGE_RISING>;
- #address-cells = <1>;
- #size-cells = <0>;
-
- /* CVBS VDAC output port */
- port@0 {
- reg = <0>;
-
- cvbs_vdac_out: endpoint {
- remote-endpoint = <&tv_connector_in>;
- };
- };
-};
diff --git a/Documentation/devicetree/bindings/display/amlogic,meson-vpu.yaml b/Documentation/devicetree/bindings/display/amlogic,meson-vpu.yaml
new file mode 100644
index 000000000000..9eba13031998
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/amlogic,meson-vpu.yaml
@@ -0,0 +1,153 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+# Copyright 2019 BayLibre, SAS
+%YAML 1.2
+---
+$id: "http://devicetree.org/schemas/display/amlogic,meson-vpu.yaml#"
+$schema: "http://devicetree.org/meta-schemas/core.yaml#"
+
+title: Amlogic Meson Display Controller
+
+maintainers:
+ - Neil Armstrong <narmstrong@baylibre.com>
+
+description: |
+ The Amlogic Meson Display controller is composed of several components
+ that are going to be documented below
+
+ DMC|---------------VPU (Video Processing Unit)----------------|------HHI------|
+ | vd1 _______ _____________ _________________ | |
+ D |-------| |----| | | | | HDMI PLL |
+ D | vd2 | VIU | | Video Post | | Video Encoders |<---|-----VCLK |
+ R |-------| |----| Processing | | | | |
+ | osd2 | | | |---| Enci ----------|----|-----VDAC------|
+ R |-------| CSC |----| Scalers | | Encp ----------|----|----HDMI-TX----|
+ A | osd1 | | | Blenders | | Encl ----------|----|---------------|
+ M |-------|______|----|____________| |________________| | |
+ ___|__________________________________________________________|_______________|
+
+
+ VIU: Video Input Unit
+ ---------------------
+
+ The Video Input Unit is in charge of the pixel scanout from the DDR memory.
+ It fetches the frames addresses, stride and parameters from the "Canvas" memory.
+ This part is also in charge of the CSC (Colorspace Conversion).
+ It can handle 2 OSD Planes and 2 Video Planes.
+
+ VPP: Video Post Processing
+ --------------------------
+
+ The Video Post Processing is in charge of the scaling and blending of the
+ various planes into a single pixel stream.
+ There is a special "pre-blending" used by the video planes with a dedicated
+ scaler and a "post-blending" to merge with the OSD Planes.
+ The OSD planes also have a dedicated scaler for one of the OSD.
+
+ VENC: Video Encoders
+ --------------------
+
+ The VENC is composed of the multiple pixel encoders
+ - ENCI : Interlace Video encoder for CVBS and Interlace HDMI
+ - ENCP : Progressive Video Encoder for HDMI
+ - ENCL : LCD LVDS Encoder
+ The VENC Unit gets a Pixel Clocks (VCLK) from a dedicated HDMI PLL and clock
+ tree and provides the scanout clock to the VPP and VIU.
+ The ENCI is connected to a single VDAC for Composite Output.
+ The ENCI and ENCP are connected to an on-chip HDMI Transceiver.
+
+ The following table lists for each supported model the port number
+ corresponding to each VPU output.
+
+ Port 0 Port 1
+ -----------------------------------------
+ S905 (GXBB) CVBS VDAC HDMI-TX
+ S905X (GXL) CVBS VDAC HDMI-TX
+ S905D (GXL) CVBS VDAC HDMI-TX
+ S912 (GXM) CVBS VDAC HDMI-TX
+ S905X2 (G12A) CVBS VDAC HDMI-TX
+ S905Y2 (G12A) CVBS VDAC HDMI-TX
+ S905D2 (G12A) CVBS VDAC HDMI-TX
+
+properties:
+ compatible:
+ oneOf:
+ - items:
+ - enum:
+ - amlogic,meson-gxbb-vpu # GXBB (S905)
+ - amlogic,meson-gxl-vpu # GXL (S905X, S905D)
+ - amlogic,meson-gxm-vpu # GXM (S912)
+ - const: amlogic,meson-gx-vpu
+ - enum:
+ - amlogic,meson-g12a-vpu # G12A (S905X2, S905Y2, S905D2)
+
+ reg:
+ maxItems: 2
+
+ reg-names:
+ items:
+ - const: vpu
+ - const: hhi
+
+ interrupts:
+ maxItems: 1
+
+ power-domains:
+ description: phandle to the associated power domain
+ allOf:
+ - $ref: /schemas/types.yaml#/definitions/phandle
+
+ port@0:
+ type: object
+ description:
+ A port node modeled using the OF graph
+ bindings specified in Documentation/devicetree/bindings/graph.txt.
+
+ port@1:
+ type: object
+ description:
+ A port node modeled using the OF graph
+ bindings specified in Documentation/devicetree/bindings/graph.txt.
+
+ "#address-cells":
+ const: 1
+
+ "#size-cells":
+ const: 0
+
+required:
+ - compatible
+ - reg
+ - interrupts
+ - port@0
+ - port@1
+ - "#address-cells"
+ - "#size-cells"
+
+examples:
+ - |
+ vpu: vpu@d0100000 {
+ compatible = "amlogic,meson-gxbb-vpu", "amlogic,meson-gx-vpu";
+ reg = <0xd0100000 0x100000>, <0xc883c000 0x1000>;
+ reg-names = "vpu", "hhi";
+ interrupts = <3>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ /* CVBS VDAC output port */
+ port@0 {
+ reg = <0>;
+
+ cvbs_vdac_out: endpoint {
+ remote-endpoint = <&tv_connector_in>;
+ };
+ };
+
+ /* HDMI TX output port */
+ port@1 {
+ reg = <1>;
+
+ hdmi_tx_out: endpoint {
+ remote-endpoint = <&hdmi_tx_in>;
+ };
+ };
+ };
--
2.22.0
^ permalink raw reply related
* [PATCH 3/3] MAINTAINERS: Update with Amlogic DRM bindings converted as YAML
From: Neil Armstrong @ 2019-08-05 13:43 UTC (permalink / raw)
To: robh+dt; +Cc: devicetree, linux-amlogic, linux-kernel, dri-devel,
Neil Armstrong
In-Reply-To: <20190805134319.737-1-narmstrong@baylibre.com>
The amlogic,meson-dw-hdmi.txt and amlogic,meson-vpu.txt has been
converted to YAML schemas, update MAINTAINERS to match them again.
Signed-off-by: Neil Armstrong <narmstrong@baylibre.com>
---
MAINTAINERS | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/MAINTAINERS b/MAINTAINERS
index 6426db5198f0..c55c18531cd1 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -5318,8 +5318,8 @@ L: linux-amlogic@lists.infradead.org
W: http://linux-meson.com/
S: Supported
F: drivers/gpu/drm/meson/
-F: Documentation/devicetree/bindings/display/amlogic,meson-vpu.txt
-F: Documentation/devicetree/bindings/display/amlogic,meson-dw-hdmi.txt
+F: Documentation/devicetree/bindings/display/amlogic,meson-vpu.yaml
+F: Documentation/devicetree/bindings/display/amlogic,meson-dw-hdmi.yaml
F: Documentation/gpu/meson.rst
T: git git://anongit.freedesktop.org/drm/drm-misc
--
2.22.0
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply related
* Re: [PATCH v3 4/5] iio: imu: st_lsm6dsx: add support for accel/gyro unit of lsm9sd1
From: Jonathan Cameron @ 2019-08-05 13:44 UTC (permalink / raw)
To: Lorenzo Bianconi
Cc: Martin Kepplinger, lorenzo.bianconi83, knaack.h, lars, pmeerw,
linux-iio, devicetree, linux-kernel
In-Reply-To: <20190728175234.GA7652@lore-desk-wlan.lan>
On Sun, 28 Jul 2019 19:52:34 +0200
Lorenzo Bianconi <lorenzo@kernel.org> wrote:
> > On Sun, 28 Jul 2019 08:04:51 +0200
> > Martin Kepplinger <martin.kepplinger@puri.sm> wrote:
> >
> > > On 27.07.19 19:48, Jonathan Cameron wrote:
> > > > On Thu, 25 Jul 2019 07:31:31 +0200
> > > > Martin Kepplinger <martin.kepplinger@puri.sm> wrote:
> > > >
> > > >> The LSM9DS1's accelerometer / gyroscope unit and it's magnetometer (separately
> > > >> supported in iio/magnetometer/st_magn*) are located on a separate i2c addresses
> > > >> on the bus.
> > > >>
> > > >> For the datasheet, see https://www.st.com/resource/en/datasheet/lsm9ds1.pdf
> > > >>
> > > >> Treat it just like the LSM6* devices and, despite it's name, hook it up
> > > >> to the st_lsm6dsx driver, using it's basic functionality.
> > > >>
> > > >> Signed-off-by: Martin Kepplinger <martin.kepplinger@puri.sm>
> > > > I'm a little confused on this hardware.
> > > >
> > > > How does buffered output work if these are independently clocked?
> > > >
> > > > I took a quick look at the datasheet, and 'suspect' the answer is that
> > > > it runs at the gyro frequencies if both are enable. Is that right?
> > > >
> > >
> > > Thanks for reviewing, Jonathan,
> > >
> > > Correct. It says so in chapter 7.12. But that's a "problem" with all
> > > these imu devices, not specific to this addition right?
> > It's not a problem as such, but there is a related difference in this
> > device to the others supported by this driver.
> >
> > The other parts seem to allow for independent data rate setting, with
> > streaming to the buffer that isn't in 'lock step'. I.e you can get
> >
> > Ax_1, Ay_1, Az_1, Gx_1, Gy_1, Gz_1, Gx_2, Gy_2, Gz_2, Ax_2, Ay_2, Az_2, Gy_3...
>
> correct
>
> >
> > That required us to split them up into two devices and means that, to fuse
> > data from these two source, userspace has to do the harder job of
> > aligning the two datasets.
> >
> > For this device, things are simpler in that you always a 'scan' that goes
> > across both accelerometer and gyroscope channels. That allows us to
> > represent it as a single IIO device with a single buffer.
> >
> > I'm not seeing any reference in the lsm9ds1 to the pattern registers
> > that are used to handle difference in frequency for the other
> > parts by letting us know what is actually present in each data set
> > in the fifo.
> >
> > Now, that doesn't meant we can't still handle them separately given
> > we already do that for other parts.
>
> what about reusing st_lsm6dsx_read_fifo() for lsm6ds0/lsm9ds1 but setting hw->sip to:
> - hw->sip = 1 (acc_sip = 1, gyro_sip = 0) when just the acc is enabled
> - hw->sip = 2 (acc_sip = 1, gyro_sip = 1) when both devices are enabled
>
> I guess it is just a matter of adding a 'bool fixed_pattern' in
> st_lsm6dsx_settings. What do you think?
If I understand this, the intent is still to split it to two separate
IIO devices? I don't really mind if that's the case and it seems like something
similar to what you describe should work for that.
If we go this way, some comments should be added to explain that whilst
we could have handled this as a single IIO device, we have split it to
be more consistent with the other more flexible devices.
Thanks,
Jonathan
>
> Regards,
> Lorenzo
>
> >
> > Anyhow, is my understanding correct?
> >
> > Jonathan
> >
> > >
> > > Sidenote: I thought about renaming things to "lsm6ds0" here just because
> > > of the name and because the registers are (almost) the same as for my
> > > lsm9ds1. But I'm not a fan of blindly doing that without being able to
> > > test. When the current patchset looks good to you, let's keep it that way.
> > >
> > > martin
> >
^ permalink raw reply
* Re: [PATCH v3 02/10] dt-bindings: add missing mt6397 rtc
From: Alexandre Belloni @ 2019-08-05 13:47 UTC (permalink / raw)
To: Frank Wunderlich
Cc: Alessandro Zummo, Allison Randal, David S. Miller, devicetree,
Eddie Huang, Greg Kroah-Hartman, Jonathan Cameron, Kate Stewart,
Lee Jones, linux-arm-kernel, linux-kernel, linux-mediatek,
linux-pm, linux-rtc, Mark Rutland, Matthias Brugger,
Mauro Carvalho Chehab, Nicolas Ferre, Richard Fontana,
Rob Herring
In-Reply-To: <20190729174154.4335-3-frank-w@public-files.de>
On 29/07/2019 19:41:46+0200, Frank Wunderlich wrote:
> From: Josef Friedl <josef.friedl@speed.at>
>
> add missing devicetree-binding document for mt6397 rtc
> in later patch driver is extended with mt6323 chip
>
> changes since v2: splitted rtc-mt6397.txt from first patch
This line should be after the --- marker.
>
> Suggested-By: Alexandre Belloni <alexandre.belloni@bootlin.com>
> Signed-off-by: Frank Wunderlich <frank-w@public-files.de>
Your SoB should appear last.
> Signed-off-by: Josef Friedl <josef.friedl@speed.at>
> ---
> .../devicetree/bindings/rtc/rtc-mt6397.txt | 29 +++++++++++++++++++
> 1 file changed, 29 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/rtc/rtc-mt6397.txt
>
> diff --git a/Documentation/devicetree/bindings/rtc/rtc-mt6397.txt b/Documentation/devicetree/bindings/rtc/rtc-mt6397.txt
> new file mode 100644
> index 000000000000..ebd1cf80dcc8
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/rtc/rtc-mt6397.txt
> @@ -0,0 +1,29 @@
> +Device-Tree bindings for MediaTek PMIC based RTC
> +
> +MediaTek PMIC based RTC is an independent function of MediaTek PMIC that works
> +as a type of multi-function device (MFD). The RTC can be configured and set up
> +with PMIC wrapper bus which is a common resource shared with the other
> +functions found on the same PMIC.
> +
> +For MediaTek PMIC MFD bindings, see:
> +Documentation/devicetree/bindings/mfd/mt6397.txt
> +
> +For MediaTek PMIC wrapper bus bindings, see:
> +Documentation/devicetree/bindings/soc/mediatek/pwrap.txt
> +
> +Required properties:
> +- compatible: Should be one of follows
> + "mediatek,mt6323-rtc": for MT6323 PMIC
> + "mediatek,mt6397-rtc": for MT6397 PMIC
> +
> +Example:
> +
> + pmic {
> + compatible = "mediatek,mt6323";
> +
> + ...
> +
> + rtc {
> + compatible = "mediatek,mt6323-rtc";
> + };
> + };
> --
> 2.17.1
>
--
Alexandre Belloni, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com
^ permalink raw reply
* Re: [PATCH v3 03/10] rtc: mt6397: move some common definitions into rtc.h
From: Alexandre Belloni @ 2019-08-05 13:48 UTC (permalink / raw)
To: Frank Wunderlich
Cc: Alessandro Zummo, Allison Randal, David S. Miller, devicetree,
Eddie Huang, Greg Kroah-Hartman, Jonathan Cameron, Kate Stewart,
Lee Jones, linux-arm-kernel, linux-kernel, linux-mediatek,
linux-pm, linux-rtc, Mark Rutland, Matthias Brugger,
Mauro Carvalho Chehab, Nicolas Ferre, Richard Fontana,
Rob Herring
In-Reply-To: <20190729174154.4335-4-frank-w@public-files.de>
On 29/07/2019 19:41:47+0200, Frank Wunderlich wrote:
> From: Josef Friedl <josef.friedl@speed.at>
>
> move code to separate header-file to reuse definitions later
> in poweroff-driver (drivers/power/reset/mt6323-poweroff.c)
>
> changes since v2: add missing commit-message
The changelog should be after the --- marker.
>
> Suggested-by: Frank Wunderlich <frank-w@public-files.de>
> Signed-off-by: Josef Friedl <josef.friedl@speed.at>
> Signed-off-by: Frank Wunderlich <frank-w@public-files.de>
> ---
> drivers/rtc/rtc-mt6397.c | 55 +-------------------------
> include/linux/mfd/mt6397/rtc.h | 71 ++++++++++++++++++++++++++++++++++
> 2 files changed, 72 insertions(+), 54 deletions(-)
> create mode 100644 include/linux/mfd/mt6397/rtc.h
>
> diff --git a/drivers/rtc/rtc-mt6397.c b/drivers/rtc/rtc-mt6397.c
> index b46ed4dc7015..c08ee5edf865 100644
> --- a/drivers/rtc/rtc-mt6397.c
> +++ b/drivers/rtc/rtc-mt6397.c
> @@ -9,60 +9,7 @@
> #include <linux/module.h>
> #include <linux/regmap.h>
> #include <linux/rtc.h>
> -#include <linux/irqdomain.h>
> -#include <linux/platform_device.h>
> -#include <linux/of_address.h>
> -#include <linux/of_irq.h>
> -#include <linux/io.h>
> -#include <linux/mfd/mt6397/core.h>
> -
> -#define RTC_BBPU 0x0000
> -#define RTC_BBPU_CBUSY BIT(6)
> -
> -#define RTC_WRTGR 0x003c
> -
> -#define RTC_IRQ_STA 0x0002
> -#define RTC_IRQ_STA_AL BIT(0)
> -#define RTC_IRQ_STA_LP BIT(3)
> -
> -#define RTC_IRQ_EN 0x0004
> -#define RTC_IRQ_EN_AL BIT(0)
> -#define RTC_IRQ_EN_ONESHOT BIT(2)
> -#define RTC_IRQ_EN_LP BIT(3)
> -#define RTC_IRQ_EN_ONESHOT_AL (RTC_IRQ_EN_ONESHOT | RTC_IRQ_EN_AL)
> -
> -#define RTC_AL_MASK 0x0008
> -#define RTC_AL_MASK_DOW BIT(4)
> -
> -#define RTC_TC_SEC 0x000a
> -/* Min, Hour, Dom... register offset to RTC_TC_SEC */
> -#define RTC_OFFSET_SEC 0
> -#define RTC_OFFSET_MIN 1
> -#define RTC_OFFSET_HOUR 2
> -#define RTC_OFFSET_DOM 3
> -#define RTC_OFFSET_DOW 4
> -#define RTC_OFFSET_MTH 5
> -#define RTC_OFFSET_YEAR 6
> -#define RTC_OFFSET_COUNT 7
> -
> -#define RTC_AL_SEC 0x0018
> -
> -#define RTC_PDN2 0x002e
> -#define RTC_PDN2_PWRON_ALARM BIT(4)
> -
> -#define RTC_MIN_YEAR 1968
> -#define RTC_BASE_YEAR 1900
> -#define RTC_NUM_YEARS 128
> -#define RTC_MIN_YEAR_OFFSET (RTC_MIN_YEAR - RTC_BASE_YEAR)
> -
> -struct mt6397_rtc {
> - struct device *dev;
> - struct rtc_device *rtc_dev;
> - struct mutex lock;
> - struct regmap *regmap;
> - int irq;
> - u32 addr_base;
> -};
> +#include <linux/mfd/mt6397/rtc.h>
>
> static int mtk_rtc_write_trigger(struct mt6397_rtc *rtc)
> {
> diff --git a/include/linux/mfd/mt6397/rtc.h b/include/linux/mfd/mt6397/rtc.h
> new file mode 100644
> index 000000000000..b702c29e8c74
> --- /dev/null
> +++ b/include/linux/mfd/mt6397/rtc.h
> @@ -0,0 +1,71 @@
> +/* SPDX-License-Identifier: GPL-2.0 */
> +/*
> + * Copyright (C) 2014-2018 MediaTek Inc.
> + *
> + * Author: Tianping.Fang <tianping.fang@mediatek.com>
> + * Sean Wang <sean.wang@mediatek.com>
> + */
> +
> +#ifndef _LINUX_MFD_MT6397_RTC_H_
> +#define _LINUX_MFD_MT6397_RTC_H_
> +
> +#include <linux/jiffies.h>
> +#include <linux/mutex.h>
> +#include <linux/regmap.h>
> +#include <linux/rtc.h>
> +
> +#define RTC_BBPU 0x0000
> +#define RTC_BBPU_CBUSY BIT(6)
> +#define RTC_BBPU_KEY (0x43 << 8)
> +
> +#define RTC_WRTGR 0x003c
> +
> +#define RTC_IRQ_STA 0x0002
> +#define RTC_IRQ_STA_AL BIT(0)
> +#define RTC_IRQ_STA_LP BIT(3)
> +
> +#define RTC_IRQ_EN 0x0004
> +#define RTC_IRQ_EN_AL BIT(0)
> +#define RTC_IRQ_EN_ONESHOT BIT(2)
> +#define RTC_IRQ_EN_LP BIT(3)
> +#define RTC_IRQ_EN_ONESHOT_AL (RTC_IRQ_EN_ONESHOT | RTC_IRQ_EN_AL)
> +
> +#define RTC_AL_MASK 0x0008
> +#define RTC_AL_MASK_DOW BIT(4)
> +
> +#define RTC_TC_SEC 0x000a
> +/* Min, Hour, Dom... register offset to RTC_TC_SEC */
> +#define RTC_OFFSET_SEC 0
> +#define RTC_OFFSET_MIN 1
> +#define RTC_OFFSET_HOUR 2
> +#define RTC_OFFSET_DOM 3
> +#define RTC_OFFSET_DOW 4
> +#define RTC_OFFSET_MTH 5
> +#define RTC_OFFSET_YEAR 6
> +#define RTC_OFFSET_COUNT 7
> +
> +#define RTC_AL_SEC 0x0018
> +
> +#define RTC_PDN2 0x002e
> +#define RTC_PDN2_PWRON_ALARM BIT(4)
> +
> +#define RTC_MIN_YEAR 1968
> +#define RTC_BASE_YEAR 1900
> +#define RTC_NUM_YEARS 128
> +#define RTC_MIN_YEAR_OFFSET (RTC_MIN_YEAR - RTC_BASE_YEAR)
> +
> +#define MTK_RTC_POLL_DELAY_US 10
> +#define MTK_RTC_POLL_TIMEOUT (jiffies_to_usecs(HZ))
> +
> +struct mt6397_rtc {
> + struct device *dev;
> + struct rtc_device *rtc_dev;
> +
> + /* Protect register access from multiple tasks */
> + struct mutex lock;
> + struct regmap *regmap;
> + int irq;
> + u32 addr_base;
> +};
> +
> +#endif /* _LINUX_MFD_MT6397_RTC_H_ */
> --
> 2.17.1
>
--
Alexandre Belloni, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com
^ permalink raw reply
* Re: [PATCH v5 1/5] dt-bindings: interconnect: Add Qualcomm QCS404 DT bindings
From: Georgi Djakov @ 2019-08-05 13:50 UTC (permalink / raw)
To: robh+dt, devicetree
Cc: bjorn.andersson, agross, vkoul, evgreen, daidavid1, linux-pm,
linux-arm-msm
In-Reply-To: <20190723142339.27772-2-georgi.djakov@linaro.org>
On 7/23/19 17:23, Georgi Djakov wrote:
> The Qualcomm QCS404 platform has several buses that could be controlled
> and tuned according to the bandwidth demand.
>
> Reviewed-by: Bjorn Andersson <bjorn.andersson@linaro.org>
> Signed-off-by: Georgi Djakov <georgi.djakov@linaro.org>
> ---
Hi Rob,
Could you please help to review this patch?
Thanks,
Georgi
>
> v5:
> - Make reg and clocks DT properties required.
> - Remove the _clk suffix from clock names.
>
> v4:
> - Add the DT header into this patch.
> - Pick Bjorn's r-b.
>
> v3:
> - Add a reg property and move the interconnect nodes under the "soc" node.
>
> v2:
> - No changes.
>
> .../bindings/interconnect/qcom,qcs404.txt | 45 ++++++++++
> .../dt-bindings/interconnect/qcom,qcs404.h | 88 +++++++++++++++++++
> 2 files changed, 133 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/interconnect/qcom,qcs404.txt
> create mode 100644 include/dt-bindings/interconnect/qcom,qcs404.h
>
> diff --git a/Documentation/devicetree/bindings/interconnect/qcom,qcs404.txt b/Documentation/devicetree/bindings/interconnect/qcom,qcs404.txt
> new file mode 100644
> index 000000000000..c07d89812b73
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/interconnect/qcom,qcs404.txt
> @@ -0,0 +1,45 @@
> +Qualcomm QCS404 Network-On-Chip interconnect driver binding
> +-----------------------------------------------------------
> +
> +Required properties :
> +- compatible : shall contain only one of the following:
> + "qcom,qcs404-bimc"
> + "qcom,qcs404-pcnoc"
> + "qcom,qcs404-snoc"
> +- #interconnect-cells : should contain 1
> +
> +reg : specifies the physical base address and size of registers
> +clocks : list of phandles and specifiers to all interconnect bus clocks
> +clock-names : clock names should include both "bus" and "bus_a"
> +
> +Example:
> +
> +soc {
> + ...
> + bimc: interconnect@400000 {
> + reg = <0x00400000 0x80000>;
> + compatible = "qcom,qcs404-bimc";
> + #interconnect-cells = <1>;
> + clock-names = "bus", "bus_a";
> + clocks = <&rpmcc RPM_SMD_BIMC_CLK>,
> + <&rpmcc RPM_SMD_BIMC_A_CLK>;
> + };
> +
> + pnoc: interconnect@500000 {
> + reg = <0x00500000 0x15080>;
> + compatible = "qcom,qcs404-pcnoc";
> + #interconnect-cells = <1>;
> + clock-names = "bus", "bus_a";
> + clocks = <&rpmcc RPM_SMD_PNOC_CLK>,
> + <&rpmcc RPM_SMD_PNOC_A_CLK>;
> + };
> +
> + snoc: interconnect@580000 {
> + reg = <0x00580000 0x23080>;
> + compatible = "qcom,qcs404-snoc";
> + #interconnect-cells = <1>;
> + clock-names = "bus", "bus_a";
> + clocks = <&rpmcc RPM_SMD_SNOC_CLK>,
> + <&rpmcc RPM_SMD_SNOC_A_CLK>;
> + };
> +};
> diff --git a/include/dt-bindings/interconnect/qcom,qcs404.h b/include/dt-bindings/interconnect/qcom,qcs404.h
> new file mode 100644
> index 000000000000..960f6e39c5f2
> --- /dev/null
> +++ b/include/dt-bindings/interconnect/qcom,qcs404.h
> @@ -0,0 +1,88 @@
> +/* SPDX-License-Identifier: GPL-2.0 */
> +/*
> + * Qualcomm interconnect IDs
> + *
> + * Copyright (c) 2019, Linaro Ltd.
> + * Author: Georgi Djakov <georgi.djakov@linaro.org>
> + */
> +
> +#ifndef __DT_BINDINGS_INTERCONNECT_QCOM_QCS404_H
> +#define __DT_BINDINGS_INTERCONNECT_QCOM_QCS404_H
> +
> +#define MASTER_AMPSS_M0 0
> +#define MASTER_OXILI 1
> +#define MASTER_MDP_PORT0 2
> +#define MASTER_SNOC_BIMC_1 3
> +#define MASTER_TCU_0 4
> +#define SLAVE_EBI_CH0 5
> +#define SLAVE_BIMC_SNOC 6
> +
> +#define MASTER_SPDM 0
> +#define MASTER_BLSP_1 1
> +#define MASTER_BLSP_2 2
> +#define MASTER_XI_USB_HS1 3
> +#define MASTER_CRYPT0 4
> +#define MASTER_SDCC_1 5
> +#define MASTER_SDCC_2 6
> +#define MASTER_SNOC_PCNOC 7
> +#define MASTER_QPIC 8
> +#define PCNOC_INT_0 9
> +#define PCNOC_INT_2 10
> +#define PCNOC_INT_3 11
> +#define PCNOC_S_0 12
> +#define PCNOC_S_1 13
> +#define PCNOC_S_2 14
> +#define PCNOC_S_3 15
> +#define PCNOC_S_4 16
> +#define PCNOC_S_6 17
> +#define PCNOC_S_7 18
> +#define PCNOC_S_8 19
> +#define PCNOC_S_9 20
> +#define PCNOC_S_10 21
> +#define PCNOC_S_11 22
> +#define SLAVE_SPDM 23
> +#define SLAVE_PDM 24
> +#define SLAVE_PRNG 25
> +#define SLAVE_TCSR 26
> +#define SLAVE_SNOC_CFG 27
> +#define SLAVE_MESSAGE_RAM 28
> +#define SLAVE_DISP_SS_CFG 29
> +#define SLAVE_GPU_CFG 30
> +#define SLAVE_BLSP_1 31
> +#define SLAVE_BLSP_2 32
> +#define SLAVE_TLMM_NORTH 33
> +#define SLAVE_PCIE 34
> +#define SLAVE_ETHERNET 35
> +#define SLAVE_TLMM_EAST 36
> +#define SLAVE_TCU 37
> +#define SLAVE_PMIC_ARB 38
> +#define SLAVE_SDCC_1 39
> +#define SLAVE_SDCC_2 40
> +#define SLAVE_TLMM_SOUTH 41
> +#define SLAVE_USB_HS 42
> +#define SLAVE_USB3 43
> +#define SLAVE_CRYPTO_0_CFG 44
> +#define SLAVE_PCNOC_SNOC 45
> +
> +#define MASTER_QDSS_BAM 0
> +#define MASTER_BIMC_SNOC 1
> +#define MASTER_PCNOC_SNOC 2
> +#define MASTER_QDSS_ETR 3
> +#define MASTER_EMAC 4
> +#define MASTER_PCIE 5
> +#define MASTER_USB3 6
> +#define QDSS_INT 7
> +#define SNOC_INT_0 8
> +#define SNOC_INT_1 9
> +#define SNOC_INT_2 10
> +#define SLAVE_KPSS_AHB 11
> +#define SLAVE_WCSS 12
> +#define SLAVE_SNOC_BIMC_1 13
> +#define SLAVE_IMEM 14
> +#define SLAVE_SNOC_PCNOC 15
> +#define SLAVE_QDSS_STM 16
> +#define SLAVE_CATS_0 17
> +#define SLAVE_CATS_1 18
> +#define SLAVE_LPASS 19
> +
> +#endif
>
^ permalink raw reply
* Re: [PATCH v3 05/10] rtc: mt6397: add compatible for mt6323
From: Alexandre Belloni @ 2019-08-05 13:50 UTC (permalink / raw)
To: Frank Wunderlich
Cc: Alessandro Zummo, Allison Randal, David S. Miller, devicetree,
Eddie Huang, Greg Kroah-Hartman, Jonathan Cameron, Kate Stewart,
Lee Jones, linux-arm-kernel, linux-kernel, linux-mediatek,
linux-pm, linux-rtc, Mark Rutland, Matthias Brugger,
Mauro Carvalho Chehab, Nicolas Ferre, Richard Fontana,
Rob Herring
In-Reply-To: <20190729174154.4335-6-frank-w@public-files.de>
On 29/07/2019 19:41:49+0200, Frank Wunderlich wrote:
> From: Josef Friedl <josef.friedl@speed.at>
>
> use mt6397 rtc driver also for mt6323
> compatible needed because of different rtc-base/size see part 7
I still don't think this is a good reason so I would remove that
sentence. Also, it refers to part 7 which is an info that will not be
available when looking at the git history.
>
> changes since v2: splitted this from v2.3 suggested-by Alexandre Belloni
>
Changelog after the --- marker please.
> Signed-off-by: Josef Friedl <josef.friedl@speed.at>
> Signed-off-by: Frank Wunderlich <frank-w@public-files.de>
> ---
> drivers/rtc/rtc-mt6397.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/drivers/rtc/rtc-mt6397.c b/drivers/rtc/rtc-mt6397.c
> index 9370b7fc9f81..21cd9cc8b4c7 100644
> --- a/drivers/rtc/rtc-mt6397.c
> +++ b/drivers/rtc/rtc-mt6397.c
> @@ -325,6 +325,7 @@ static SIMPLE_DEV_PM_OPS(mt6397_pm_ops, mt6397_rtc_suspend,
> mt6397_rtc_resume);
>
> static const struct of_device_id mt6397_rtc_of_match[] = {
> + { .compatible = "mediatek,mt6323-rtc", },
> { .compatible = "mediatek,mt6397-rtc", },
> { }
> };
> --
> 2.17.1
>
--
Alexandre Belloni, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com
^ permalink raw reply
* Re: [PATCH V13 12/12] PCI: tegra: Add Tegra194 PCIe support
From: Lorenzo Pieralisi @ 2019-08-05 14:01 UTC (permalink / raw)
To: Vidya Sagar
Cc: bhelgaas, robh+dt, mark.rutland, thierry.reding, jonathanh,
kishon, catalin.marinas, will.deacon, jingoohan1,
gustavo.pimentel, digetx, mperttunen, linux-pci, devicetree,
linux-tegra, linux-kernel, linux-arm-kernel, kthota, mmaddireddy,
sagar.tv
In-Reply-To: <f09c79fc-c724-5290-d630-cac3fdd7a996@nvidia.com>
On Fri, Aug 02, 2019 at 05:36:43PM +0530, Vidya Sagar wrote:
> On 7/30/2019 9:19 PM, Lorenzo Pieralisi wrote:
> > On Tue, Jul 23, 2019 at 08:14:08PM +0530, Vidya Sagar wrote:
> > > On 7/16/2019 4:52 PM, Lorenzo Pieralisi wrote:
> > > > On Sat, Jul 13, 2019 at 12:34:34PM +0530, Vidya Sagar wrote:
> > > >
> > > > [...]
> > > >
> > > > > > > > > +static int tegra_pcie_bpmp_set_ctrl_state(struct tegra_pcie_dw *pcie,
> > > > > > > > > + bool enable)
> > > > > > > > > +{
> > > > > > > > > + struct mrq_uphy_response resp;
> > > > > > > > > + struct tegra_bpmp_message msg;
> > > > > > > > > + struct mrq_uphy_request req;
> > > > > > > > > + int err;
> > > > > > > > > +
> > > > > > > > > + if (pcie->cid == 5)
> > > > > > > > > + return 0;
> > > > > > > >
> > > > > > > > What's wrong with cid == 5 ? Explain please.
> > > > > > > Controller with ID=5 doesn't need any programming to enable it which is
> > > > > > > done here through calling firmware API.
> > > > > > >
> > > > > > > >
> > > > > > > > > + memset(&req, 0, sizeof(req));
> > > > > > > > > + memset(&resp, 0, sizeof(resp));
> > > > > > > > > +
> > > > > > > > > + req.cmd = CMD_UPHY_PCIE_CONTROLLER_STATE;
> > > > > > > > > + req.controller_state.pcie_controller = pcie->cid;
> > > > > > > > > + req.controller_state.enable = enable;
> > > > > > > > > +
> > > > > > > > > + memset(&msg, 0, sizeof(msg));
> > > > > > > > > + msg.mrq = MRQ_UPHY;
> > > > > > > > > + msg.tx.data = &req;
> > > > > > > > > + msg.tx.size = sizeof(req);
> > > > > > > > > + msg.rx.data = &resp;
> > > > > > > > > + msg.rx.size = sizeof(resp);
> > > > > > > > > +
> > > > > > > > > + if (irqs_disabled())
> > > > > > > >
> > > > > > > > Can you explain to me what this check is meant to achieve please ?
> > > > > > > Firmware interface provides different APIs to be called when there are
> > > > > > > no interrupts enabled in the system (noirq context) and otherwise
> > > > > > > hence checking that situation here and calling appropriate API.
> > > > > >
> > > > > > That's what I am questioning. Being called from {suspend/resume}_noirq()
> > > > > > callbacks (if that's the code path this check caters for) does not mean
> > > > > > irqs_disabled() == true.
> > > > > Agree.
> > > > > Actually, I got a hint of having this check from the following.
> > > > > Both tegra_bpmp_transfer_atomic() and tegra_bpmp_transfer() are indirectly
> > > > > called by APIs registered with .master_xfer() and .master_xfer_atomic() hooks of
> > > > > struct i2c_algorithm and the decision to call which one of these is made using the
> > > > > following check in i2c-core.h file.
> > > > > static inline bool i2c_in_atomic_xfer_mode(void)
> > > > > {
> > > > > return system_state > SYSTEM_RUNNING && irqs_disabled();
> > > > > }
> > > > > I think I should use this condition as is IIUC.
> > > > > Please let me know if there are any concerns with this.
> > > >
> > > > It is not a concern, it is just that I don't understand how this code
> > > > can be called with IRQs disabled, if you can give me an execution path I
> > > > am happy to leave the check there. On top of that, when called from
> > > > suspend NOIRQ context, it is likely to use the blocking API (because
> > > > IRQs aren't disabled at CPU level) behind which there is most certainly
> > > > an IRQ required to wake the thread up and if the IRQ in question was
> > > > disabled in the suspend NOIRQ phase this code is likely to deadlock.
> > > >
> > > > I want to make sure we can justify adding this check, I do not
> > > > want to add it because we think it can be needed when it may not
> > > > be needed at all (and it gets copy and pasted over and over again
> > > > in other drivers).
> > > I had a discussion internally about this and the prescribed usage of these APIs
> > > seem to be that
> > > use tegra_bpmp_transfer() in .probe() and other paths where interrupts are
> > > enabled as this API needs interrupts to be enabled for its working.
> > > Use tegra_bpmp_transfer_atomic() surrounded by local_irq_save()/local_irq_restore()
> > > in other paths where interrupt servicing is disabled.
> >
> > Why tegra_bpmp_transfer_atomic() needs IRQs to be disabled ? And why
> > is it needed in this piece of code where IRQs are _never_ disabled
> > at CPU level ?
> >
> > IRQs are enabled when you call a suspend_noirq() callback, so the
> > blocking API can be used as long as the IRQ descriptor backing
> > the IRQ that will wake-up the blocked call is marked as
> > IRQF_NO_SUSPEND.
> >
> > The problem is not IRQs enabled/disabled at CPU level, the problem is
> > the IRQ descriptor of the IRQ required to handle the blocking BPMP call,
> > mark it as IRQF_NO_SUSPEND and remove the tegra_bpmp_transfer_atomic()
> > call from this code (or please give me a concrete example pinpointing
> > why it is needed).
> Ideally, using tegra_bpmp_transfer() alone in all paths (.probe() as
> well as .resume_noirq()) should have worked as the corresponding IRQ
> is already flagged as IRQF_NO_SUSPEND, but, because of the way BPMP-FW
> driver in kernel making its interface available through
> .resume_early(), tegra_bpmp_transfer() wasn't working as expected and
> I pushed a patch (CC'ing you) at
> http://patchwork.ozlabs.org/patch/1140973/ to make it .resume_noirq()
> from .resume_early(). With that in place, we can just use
> tegra_bpmp_trasnfer(). I'll push a new patch with this change once my
> BPMP-FW driver patch is approved.
Does this leave you with a resume_noirq() callbacks ordering issue to
sort out ?
a.k.a How will you guarantee that the BPMP will resume before the host
bridge ?
Thanks,
Lorenzo
> Thanks,
> Vidya Sagar
> >
> > Thanks,
> > Lorenzo
> >
> > > I'll go ahead and make next patch series with this if this looks fine to you.
> > >
> > > >
> > > > > > Actually, if tegra_bpmp_transfer() requires IRQs to be enabled you may
> > > > > > even end up in a situation where that blocking call does not wake up
> > > > > > because the IRQ in question was disabled in the NOIRQ suspend/resume
> > > > > > phase.
> > > > > >
> > > > > > [...]
> > > > > >
> > > > > > > > > +static int tegra_pcie_dw_probe(struct platform_device *pdev)
> > > > > > > > > +{
> > > > > > > > > + const struct tegra_pcie_soc *data;
> > > > > > > > > + struct device *dev = &pdev->dev;
> > > > > > > > > + struct resource *atu_dma_res;
> > > > > > > > > + struct tegra_pcie_dw *pcie;
> > > > > > > > > + struct resource *dbi_res;
> > > > > > > > > + struct pcie_port *pp;
> > > > > > > > > + struct dw_pcie *pci;
> > > > > > > > > + struct phy **phys;
> > > > > > > > > + char *name;
> > > > > > > > > + int ret;
> > > > > > > > > + u32 i;
> > > > > > > > > +
> > > > > > > > > + pcie = devm_kzalloc(dev, sizeof(*pcie), GFP_KERNEL);
> > > > > > > > > + if (!pcie)
> > > > > > > > > + return -ENOMEM;
> > > > > > > > > +
> > > > > > > > > + pci = &pcie->pci;
> > > > > > > > > + pci->dev = &pdev->dev;
> > > > > > > > > + pci->ops = &tegra_dw_pcie_ops;
> > > > > > > > > + pp = &pci->pp;
> > > > > > > > > + pcie->dev = &pdev->dev;
> > > > > > > > > +
> > > > > > > > > + data = (struct tegra_pcie_soc *)of_device_get_match_data(dev);
> > > > > > > > > + if (!data)
> > > > > > > > > + return -EINVAL;
> > > > > > > > > + pcie->mode = (enum dw_pcie_device_mode)data->mode;
> > > > > > > > > +
> > > > > > > > > + ret = tegra_pcie_dw_parse_dt(pcie);
> > > > > > > > > + if (ret < 0) {
> > > > > > > > > + dev_err(dev, "Failed to parse device tree: %d\n", ret);
> > > > > > > > > + return ret;
> > > > > > > > > + }
> > > > > > > > > +
> > > > > > > > > + pcie->pex_ctl_supply = devm_regulator_get(dev, "vddio-pex-ctl");
> > > > > > > > > + if (IS_ERR(pcie->pex_ctl_supply)) {
> > > > > > > > > + dev_err(dev, "Failed to get regulator: %ld\n",
> > > > > > > > > + PTR_ERR(pcie->pex_ctl_supply));
> > > > > > > > > + return PTR_ERR(pcie->pex_ctl_supply);
> > > > > > > > > + }
> > > > > > > > > +
> > > > > > > > > + pcie->core_clk = devm_clk_get(dev, "core");
> > > > > > > > > + if (IS_ERR(pcie->core_clk)) {
> > > > > > > > > + dev_err(dev, "Failed to get core clock: %ld\n",
> > > > > > > > > + PTR_ERR(pcie->core_clk));
> > > > > > > > > + return PTR_ERR(pcie->core_clk);
> > > > > > > > > + }
> > > > > > > > > +
> > > > > > > > > + pcie->appl_res = platform_get_resource_byname(pdev, IORESOURCE_MEM,
> > > > > > > > > + "appl");
> > > > > > > > > + if (!pcie->appl_res) {
> > > > > > > > > + dev_err(dev, "Failed to find \"appl\" region\n");
> > > > > > > > > + return PTR_ERR(pcie->appl_res);
> > > > > > > > > + }
> > > > > > > > > + pcie->appl_base = devm_ioremap_resource(dev, pcie->appl_res);
> > > > > > > > > + if (IS_ERR(pcie->appl_base))
> > > > > > > > > + return PTR_ERR(pcie->appl_base);
> > > > > > > > > +
> > > > > > > > > + pcie->core_apb_rst = devm_reset_control_get(dev, "apb");
> > > > > > > > > + if (IS_ERR(pcie->core_apb_rst)) {
> > > > > > > > > + dev_err(dev, "Failed to get APB reset: %ld\n",
> > > > > > > > > + PTR_ERR(pcie->core_apb_rst));
> > > > > > > > > + return PTR_ERR(pcie->core_apb_rst);
> > > > > > > > > + }
> > > > > > > > > +
> > > > > > > > > + phys = devm_kcalloc(dev, pcie->phy_count, sizeof(*phys), GFP_KERNEL);
> > > > > > > > > + if (!phys)
> > > > > > > > > + return PTR_ERR(phys);
> > > > > > > > > +
> > > > > > > > > + for (i = 0; i < pcie->phy_count; i++) {
> > > > > > > > > + name = kasprintf(GFP_KERNEL, "p2u-%u", i);
> > > > > > > > > + if (!name) {
> > > > > > > > > + dev_err(dev, "Failed to create P2U string\n");
> > > > > > > > > + return -ENOMEM;
> > > > > > > > > + }
> > > > > > > > > + phys[i] = devm_phy_get(dev, name);
> > > > > > > > > + kfree(name);
> > > > > > > > > + if (IS_ERR(phys[i])) {
> > > > > > > > > + ret = PTR_ERR(phys[i]);
> > > > > > > > > + dev_err(dev, "Failed to get PHY: %d\n", ret);
> > > > > > > > > + return ret;
> > > > > > > > > + }
> > > > > > > > > + }
> > > > > > > > > +
> > > > > > > > > + pcie->phys = phys;
> > > > > > > > > +
> > > > > > > > > + dbi_res = platform_get_resource_byname(pdev, IORESOURCE_MEM, "dbi");
> > > > > > > > > + if (!dbi_res) {
> > > > > > > > > + dev_err(dev, "Failed to find \"dbi\" region\n");
> > > > > > > > > + return PTR_ERR(dbi_res);
> > > > > > > > > + }
> > > > > > > > > + pcie->dbi_res = dbi_res;
> > > > > > > > > +
> > > > > > > > > + pci->dbi_base = devm_ioremap_resource(dev, dbi_res);
> > > > > > > > > + if (IS_ERR(pci->dbi_base))
> > > > > > > > > + return PTR_ERR(pci->dbi_base);
> > > > > > > > > +
> > > > > > > > > + /* Tegra HW locates DBI2 at a fixed offset from DBI */
> > > > > > > > > + pci->dbi_base2 = pci->dbi_base + 0x1000;
> > > > > > > > > +
> > > > > > > > > + atu_dma_res = platform_get_resource_byname(pdev, IORESOURCE_MEM,
> > > > > > > > > + "atu_dma");
> > > > > > > > > + if (!atu_dma_res) {
> > > > > > > > > + dev_err(dev, "Failed to find \"atu_dma\" region\n");
> > > > > > > > > + return PTR_ERR(atu_dma_res);
> > > > > > > > > + }
> > > > > > > > > + pcie->atu_dma_res = atu_dma_res;
> > > > > > > > > + pci->atu_base = devm_ioremap_resource(dev, atu_dma_res);
> > > > > > > > > + if (IS_ERR(pci->atu_base))
> > > > > > > > > + return PTR_ERR(pci->atu_base);
> > > > > > > > > +
> > > > > > > > > + pcie->core_rst = devm_reset_control_get(dev, "core");
> > > > > > > > > + if (IS_ERR(pcie->core_rst)) {
> > > > > > > > > + dev_err(dev, "Failed to get core reset: %ld\n",
> > > > > > > > > + PTR_ERR(pcie->core_rst));
> > > > > > > > > + return PTR_ERR(pcie->core_rst);
> > > > > > > > > + }
> > > > > > > > > +
> > > > > > > > > + pp->irq = platform_get_irq_byname(pdev, "intr");
> > > > > > > > > + if (!pp->irq) {
> > > > > > > > > + dev_err(dev, "Failed to get \"intr\" interrupt\n");
> > > > > > > > > + return -ENODEV;
> > > > > > > > > + }
> > > > > > > > > +
> > > > > > > > > + ret = devm_request_irq(dev, pp->irq, tegra_pcie_irq_handler,
> > > > > > > > > + IRQF_SHARED, "tegra-pcie-intr", pcie);
> > > > > > > > > + if (ret) {
> > > > > > > > > + dev_err(dev, "Failed to request IRQ %d: %d\n", pp->irq, ret);
> > > > > > > > > + return ret;
> > > > > > > > > + }
> > > > > > > > > +
> > > > > > > > > + pcie->bpmp = tegra_bpmp_get(dev);
> > > > > > > > > + if (IS_ERR(pcie->bpmp))
> > > > > > > > > + return PTR_ERR(pcie->bpmp);
> > > > > > > > > +
> > > > > > > > > + platform_set_drvdata(pdev, pcie);
> > > > > > > > > +
> > > > > > > > > + if (pcie->mode == DW_PCIE_RC_TYPE) {
> > > > > > > > > + ret = tegra_pcie_config_rp(pcie);
> > > > > > > > > + if (ret && ret != -ENOMEDIUM)
> > > > > > > > > + goto fail;
> > > > > > > > > + else
> > > > > > > > > + return 0;
> > > > > > > >
> > > > > > > > So if the link is not up we still go ahead and make probe
> > > > > > > > succeed. What for ?
> > > > > > > We may need root port to be available to support hot-plugging of
> > > > > > > endpoint devices, so, we don't fail the probe.
> > > > > >
> > > > > > We need it or we don't. If you do support hotplugging of endpoint
> > > > > > devices point me at the code, otherwise link up failure means
> > > > > > failure to probe.
> > > > > Currently hotplugging of endpoint is not supported, but it is one of
> > > > > the use cases that we may add support for in future.
> > > >
> > > > You should elaborate on this, I do not understand what you mean,
> > > > either the root port(s) supports hotplug or it does not.
> > > >
> > > > > But, why should we fail probe if link up doesn't happen? As such,
> > > > > nothing went wrong in terms of root port initialization right? I
> > > > > checked other DWC based implementations and following are not failing
> > > > > the probe pci-dra7xx.c, pcie-armada8k.c, pcie-artpec6.c, pcie-histb.c,
> > > > > pcie-kirin.c, pcie-spear13xx.c, pci-exynos.c, pci-imx6.c,
> > > > > pci-keystone.c, pci-layerscape.c
> > > > >
> > > > > Although following do fail the probe if link is not up. pcie-qcom.c,
> > > > > pcie-uniphier.c, pci-meson.c
> > > > >
> > > > > So, to me, it looks more like a choice we can make whether to fail the
> > > > > probe or not and in this case we are choosing not to fail.
> > > >
> > > > I disagree. I had an offline chat with Bjorn and whether link-up should
> > > > fail the probe or not depends on whether the root port(s) is hotplug
> > > > capable or not and this in turn relies on the root port "Slot
> > > > implemented" bit in the PCI Express capabilities register.
> > > >
> > > > It is a choice but it should be based on evidence.
> > > >
> > > > Lorenzo
> > > With Bjorn's latest comment on top of this, I think we are good not to fail
> > > the probe here.
> > >
> > > - Vidya Sagar
> > > >
> > >
>
^ permalink raw reply
* Re: [PATCH 16/16] dt-bindings: net: add bindings for ADIN PHY driver
From: Andrew Lunn @ 2019-08-05 14:11 UTC (permalink / raw)
To: Alexandru Ardelean
Cc: netdev, devicetree, linux-kernel, davem, robh+dt, mark.rutland,
f.fainelli, hkallweit1
In-Reply-To: <20190805165453.3989-17-alexandru.ardelean@analog.com>
> + adi,rx-internal-delay:
> + $ref: /schemas/types.yaml#/definitions/uint32
> + description: |
> + RGMII RX Clock Delay used only when PHY operates in RGMII mode (phy-mode
> + is "rgmii-id", "rgmii-rxid", "rgmii-txid") see `dt-bindings/net/adin.h`
> + default value is 0 (which represents 2 ns)
> + enum: [ 0, 1, 2, 6, 7 ]
We want these numbers to be in ns. So the default value would actually
be 2. The driver needs to convert the number in DT to a value to poke
into a PHY register. Please rename the property adi,rx-internal-delay-ns.
> +
> + adi,tx-internal-delay:
> + $ref: /schemas/types.yaml#/definitions/uint32
> + description: |
> + RGMII TX Clock Delay used only when PHY operates in RGMII mode (phy-mode
> + is "rgmii-id", "rgmii-rxid", "rgmii-txid") see `dt-bindings/net/adin.h`
> + default value is 0 (which represents 2 ns)
> + enum: [ 0, 1, 2, 6, 7 ]
Same here.
> +
> + adi,fifo-depth:
> + $ref: /schemas/types.yaml#/definitions/uint32
> + description: |
> + When operating in RMII mode, this option configures the FIFO depth.
> + See `dt-bindings/net/adin.h`.
> + enum: [ 0, 1, 2, 3, 4, 5 ]
Units? You should probably rename this adi,fifo-depth-bits and list
the valid values in bits.
> +
> + adi,eee-enabled:
> + description: |
> + Advertise EEE capabilities on power-up/init (default disabled)
> + type: boolean
It is not the PHY which decides this. The MAC indicates if it is EEE
capable to phylib. phylib looks into the PHY registers to determine if
the PHY supports EEE. phylib will then enable EEE
advertisement. Please remove this, and ensure EEE is disabled by
default.
Andrew
^ 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