* [PATCH v2 5/5] arm64: dts: meson-g12b-gtking-pro: add initial device-tree
From: Christian Hewitt @ 2020-05-18 2:25 UTC (permalink / raw)
To: Rob Herring, Mark Rutland, Kevin Hilman, devicetree,
linux-arm-kernel, linux-amlogic, linux-kernel
Cc: Christian Hewitt
In-Reply-To: <20200518022531.14739-1-christianshewitt@gmail.com>
The Shenzen AZW (Beelink) GT-King Pro is based on the Amlogic W400
reference board with an S922X chip.
- 4GB LPDDR4 RAM
- 64GB eMMC storage
- 10/100/1000 Base-T Ethernet
- AP6356S Wireless (802.11 a/b/g/n/ac, BT 4.1)
- HDMI 2.1 video
- Analogue audio output
- 1x RS232 port
- 2x USB 2.0 port
- 2x USB 3.0 ports
- IR receiver
- 1x micro SD card slot
- 1x Power on/off button
Signed-off-by: Christian Hewitt <christianshewitt@gmail.com>
---
arch/arm64/boot/dts/amlogic/Makefile | 1 +
.../dts/amlogic/meson-g12b-gtking-pro.dts | 125 ++++++++++++++++++
2 files changed, 126 insertions(+)
create mode 100644 arch/arm64/boot/dts/amlogic/meson-g12b-gtking-pro.dts
diff --git a/arch/arm64/boot/dts/amlogic/Makefile b/arch/arm64/boot/dts/amlogic/Makefile
index 66691090b30c..38bb1f6e6ef6 100644
--- a/arch/arm64/boot/dts/amlogic/Makefile
+++ b/arch/arm64/boot/dts/amlogic/Makefile
@@ -5,6 +5,7 @@ dtb-$(CONFIG_ARCH_MESON) += meson-g12a-tanix-tx5max.dtb
dtb-$(CONFIG_ARCH_MESON) += meson-g12a-u200.dtb
dtb-$(CONFIG_ARCH_MESON) += meson-g12a-x96-max.dtb
dtb-$(CONFIG_ARCH_MESON) += meson-g12b-gtking.dtb
+dtb-$(CONFIG_ARCH_MESON) += meson-g12b-gtking-pro.dtb
dtb-$(CONFIG_ARCH_MESON) += meson-g12b-a311d-khadas-vim3.dtb
dtb-$(CONFIG_ARCH_MESON) += meson-g12b-s922x-khadas-vim3.dtb
dtb-$(CONFIG_ARCH_MESON) += meson-g12b-odroid-n2.dtb
diff --git a/arch/arm64/boot/dts/amlogic/meson-g12b-gtking-pro.dts b/arch/arm64/boot/dts/amlogic/meson-g12b-gtking-pro.dts
new file mode 100644
index 000000000000..f0c56a16af3d
--- /dev/null
+++ b/arch/arm64/boot/dts/amlogic/meson-g12b-gtking-pro.dts
@@ -0,0 +1,125 @@
+// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
+/*
+ * Copyright (c) 2019 BayLibre, SAS
+ * Author: Neil Armstrong <narmstrong@baylibre.com>
+ * Copyright (c) 2019 Christian Hewitt <christianshewitt@gmail.com>
+ */
+
+/dts-v1/;
+
+#include "meson-g12b-w400.dtsi"
+#include <dt-bindings/sound/meson-g12a-tohdmitx.h>
+
+/ {
+ compatible = "azw,gtking", "amlogic,g12b";
+ model = "Beelink GT-King Pro";
+
+ gpio-keys-polled {
+ compatible = "gpio-keys-polled";
+ #address-cells = <1>;
+ #size-cells = <0>;
+ poll-interval = <100>;
+
+ power-button {
+ label = "power";
+ linux,code = <KEY_POWER>;
+ gpios = <&gpio_ao GPIOAO_3 GPIO_ACTIVE_HIGH>;
+ };
+ };
+
+ leds {
+ compatible = "gpio-leds";
+
+ white {
+ label = "power:white";
+ gpios = <&gpio_ao GPIOAO_11 GPIO_ACTIVE_HIGH>;
+ default-state = "on";
+ };
+ };
+
+ sound {
+ compatible = "amlogic,axg-sound-card";
+ model = "G12B-GTKING-PRO";
+ audio-aux-devs = <&tdmout_b>;
+ audio-routing = "TDMOUT_B IN 0", "FRDDR_A OUT 1",
+ "TDMOUT_B IN 1", "FRDDR_B OUT 1",
+ "TDMOUT_B IN 2", "FRDDR_C OUT 1",
+ "TDM_B Playback", "TDMOUT_B OUT";
+
+ assigned-clocks = <&clkc CLKID_MPLL2>,
+ <&clkc CLKID_MPLL0>,
+ <&clkc CLKID_MPLL1>;
+ assigned-clock-parents = <0>, <0>, <0>;
+ assigned-clock-rates = <294912000>,
+ <270950400>,
+ <393216000>;
+ status = "okay";
+
+ dai-link-0 {
+ sound-dai = <&frddr_a>;
+ };
+
+ dai-link-1 {
+ sound-dai = <&frddr_b>;
+ };
+
+ dai-link-2 {
+ sound-dai = <&frddr_c>;
+ };
+
+ /* 8ch hdmi interface */
+ dai-link-3 {
+ sound-dai = <&tdmif_b>;
+ dai-format = "i2s";
+ dai-tdm-slot-tx-mask-0 = <1 1>;
+ dai-tdm-slot-tx-mask-1 = <1 1>;
+ dai-tdm-slot-tx-mask-2 = <1 1>;
+ dai-tdm-slot-tx-mask-3 = <1 1>;
+ mclk-fs = <256>;
+
+ codec {
+ sound-dai = <&tohdmitx TOHDMITX_I2S_IN_B>;
+ };
+ };
+
+ dai-link-4 {
+ sound-dai = <&tohdmitx TOHDMITX_I2S_OUT>;
+
+ codec {
+ sound-dai = <&hdmi_tx>;
+ };
+ };
+ };
+};
+
+&arb {
+ status = "okay";
+};
+
+&clkc_audio {
+ status = "okay";
+};
+
+&frddr_a {
+ status = "okay";
+};
+
+&frddr_b {
+ status = "okay";
+};
+
+&frddr_c {
+ status = "okay";
+};
+
+&tdmif_b {
+ status = "okay";
+};
+
+&tdmout_b {
+ status = "okay";
+};
+
+&tohdmitx {
+ status = "okay";
+};
--
2.17.1
^ permalink raw reply related
* [PATCH v2 2/5] dt-bindings: arm: amlogic: add support for the Beelink GT-King
From: Christian Hewitt @ 2020-05-18 2:25 UTC (permalink / raw)
To: Rob Herring, Mark Rutland, Kevin Hilman, devicetree,
linux-arm-kernel, linux-amlogic, linux-kernel
Cc: Christian Hewitt
In-Reply-To: <20200518022531.14739-1-christianshewitt@gmail.com>
The Shenzen AZW (Beelink) GT-King is based on the Amlogic W400 reference
board with an S922X chip.
Acked-by: Rob Herring <robh@kernel.org>
Signed-off-by: Christian Hewitt <christianshewitt@gmail.com>
---
Documentation/devicetree/bindings/arm/amlogic.yaml | 1 +
1 file changed, 1 insertion(+)
diff --git a/Documentation/devicetree/bindings/arm/amlogic.yaml b/Documentation/devicetree/bindings/arm/amlogic.yaml
index 5180a548bd94..25e118b8a97b 100644
--- a/Documentation/devicetree/bindings/arm/amlogic.yaml
+++ b/Documentation/devicetree/bindings/arm/amlogic.yaml
@@ -151,6 +151,7 @@ properties:
- description: Boards with the Amlogic Meson G12B S922X SoC
items:
- enum:
+ - azw,gtking
- hardkernel,odroid-n2
- khadas,vim3
- ugoos,am6
--
2.17.1
^ permalink raw reply related
* [PATCH v2 1/5] arm64: dts: meson: convert ugoos-am6 to common w400 dtsi
From: Christian Hewitt @ 2020-05-18 2:25 UTC (permalink / raw)
To: Rob Herring, Mark Rutland, Kevin Hilman, devicetree,
linux-arm-kernel, linux-amlogic, linux-kernel
Cc: Christian Hewitt
In-Reply-To: <20200518022531.14739-1-christianshewitt@gmail.com>
Convert the Ugoos AM6 dts into meson-g12b-w400.dtsi, and then create
a new AM6 dts that references it. This is in preparation for several
new G12B devices that will share the common w400 dtsi.
Signed-off-by: Christian Hewitt <christianshewitt@gmail.com>
---
.../boot/dts/amlogic/meson-g12b-ugoos-am6.dts | 410 +----------------
.../boot/dts/amlogic/meson-g12b-w400.dtsi | 423 ++++++++++++++++++
2 files changed, 424 insertions(+), 409 deletions(-)
create mode 100644 arch/arm64/boot/dts/amlogic/meson-g12b-w400.dtsi
diff --git a/arch/arm64/boot/dts/amlogic/meson-g12b-ugoos-am6.dts b/arch/arm64/boot/dts/amlogic/meson-g12b-ugoos-am6.dts
index fdaacfd96b97..73637de80c21 100644
--- a/arch/arm64/boot/dts/amlogic/meson-g12b-ugoos-am6.dts
+++ b/arch/arm64/boot/dts/amlogic/meson-g12b-ugoos-am6.dts
@@ -7,42 +7,13 @@
/dts-v1/;
-#include "meson-g12b.dtsi"
-#include "meson-g12b-s922x.dtsi"
-#include <dt-bindings/input/input.h>
-#include <dt-bindings/gpio/meson-g12a-gpio.h>
+#include "meson-g12b-w400.dtsi"
#include <dt-bindings/sound/meson-g12a-tohdmitx.h>
/ {
compatible = "ugoos,am6", "amlogic,s922x", "amlogic,g12b";
model = "Ugoos AM6";
- aliases {
- serial0 = &uart_AO;
- ethernet0 = ðmac;
- };
-
- chosen {
- stdout-path = "serial0:115200n8";
- };
-
- memory@0 {
- device_type = "memory";
- reg = <0x0 0x0 0x0 0x40000000>;
- };
-
- emmc_pwrseq: emmc-pwrseq {
- compatible = "mmc-pwrseq-emmc";
- reset-gpios = <&gpio BOOT_12 GPIO_ACTIVE_LOW>;
- };
-
- sdio_pwrseq: sdio-pwrseq {
- compatible = "mmc-pwrseq-simple";
- reset-gpios = <&gpio GPIOX_6 GPIO_ACTIVE_LOW>;
- clocks = <&wifi32k>;
- clock-names = "ext_clock";
- };
-
spdif_dit: audio-codec-1 {
#sound-dai-cells = <0>;
compatible = "linux,spdif-dit";
@@ -50,154 +21,6 @@
sound-name-prefix = "DIT";
};
- flash_1v8: regulator-flash_1v8 {
- compatible = "regulator-fixed";
- regulator-name = "FLASH_1V8";
- regulator-min-microvolt = <1800000>;
- regulator-max-microvolt = <1800000>;
- vin-supply = <&vcc_3v3>;
- regulator-always-on;
- };
-
- main_12v: regulator-main_12v {
- compatible = "regulator-fixed";
- regulator-name = "12V";
- regulator-min-microvolt = <12000000>;
- regulator-max-microvolt = <12000000>;
- regulator-always-on;
- };
-
- vcc_5v: regulator-vcc_5v {
- compatible = "regulator-fixed";
- regulator-name = "VCC_5V";
- regulator-min-microvolt = <5000000>;
- regulator-max-microvolt = <5000000>;
- vin-supply = <&main_12v>;
-
- gpio = <&gpio GPIOH_8 GPIO_OPEN_DRAIN>;
- enable-active-high;
- };
-
- vcc_1v8: regulator-vcc_1v8 {
- compatible = "regulator-fixed";
- regulator-name = "VCC_1V8";
- regulator-min-microvolt = <1800000>;
- regulator-max-microvolt = <1800000>;
- vin-supply = <&vcc_3v3>;
- regulator-always-on;
- };
-
- vcc_3v3: regulator-vcc_3v3 {
- compatible = "regulator-fixed";
- regulator-name = "VCC_3V3";
- regulator-min-microvolt = <3300000>;
- regulator-max-microvolt = <3300000>;
- vin-supply = <&vddao_3v3>;
- regulator-always-on;
- /* FIXME: actually controlled by VDDCPU_B_EN */
- };
-
- vddcpu_a: regulator-vddcpu-a {
- /*
- * MP1653 Regulator.
- */
- compatible = "pwm-regulator";
-
- regulator-name = "VDDCPU_A";
- regulator-min-microvolt = <721000>;
- regulator-max-microvolt = <1022000>;
-
- vin-supply = <&main_12v>;
-
- pwms = <&pwm_ab 0 1250 0>;
- pwm-dutycycle-range = <100 0>;
-
- regulator-boot-on;
- regulator-always-on;
- };
-
- vddcpu_b: regulator-vddcpu-b {
- /*
- * MP1652 Regulator.
- */
- compatible = "pwm-regulator";
-
- regulator-name = "VDDCPU_B";
- regulator-min-microvolt = <721000>;
- regulator-max-microvolt = <1022000>;
-
- vin-supply = <&main_12v>;
-
- pwms = <&pwm_AO_cd 1 1250 0>;
- pwm-dutycycle-range = <100 0>;
-
- regulator-boot-on;
- regulator-always-on;
- };
-
- usb1_pow: regulator-usb1-pow {
- compatible = "regulator-fixed";
- regulator-name = "USB1_POW";
- regulator-min-microvolt = <5000000>;
- regulator-max-microvolt = <5000000>;
- vin-supply = <&vcc_5v>;
-
- /* connected to SY6280A Power Switch */
- gpio = <&gpio GPIOA_8 GPIO_ACTIVE_HIGH>;
- enable-active-high;
- };
-
- usb_pwr_en: regulator-usb-pwr-en {
- compatible = "regulator-fixed";
- regulator-name = "USB_PWR_EN";
- regulator-min-microvolt = <5000000>;
- regulator-max-microvolt = <5000000>;
- vin-supply = <&vcc_5v>;
-
- /* Connected to USB3 Type-A Port power enable */
- gpio = <&gpio GPIOAO_7 GPIO_ACTIVE_HIGH>;
- enable-active-high;
- };
-
- vddao_1v8: regulator-vddao-1v8 {
- compatible = "regulator-fixed";
- regulator-name = "VDDAO_1V8";
- regulator-min-microvolt = <1800000>;
- regulator-max-microvolt = <1800000>;
- vin-supply = <&vddao_3v3>;
- regulator-always-on;
- };
-
- vddao_3v3: regulator-vddao-3v3 {
- compatible = "regulator-fixed";
- regulator-name = "VDDAO_3V3";
- regulator-min-microvolt = <3300000>;
- regulator-max-microvolt = <3300000>;
- vin-supply = <&main_12v>;
- regulator-always-on;
- };
-
- cvbs-connector {
- compatible = "composite-video-connector";
-
- port {
- cvbs_connector_in: endpoint {
- remote-endpoint = <&cvbs_vdac_out>;
- };
- };
- };
-
- hdmi-connector {
- compatible = "hdmi-connector";
- type = "a";
-
- port {
- hdmi_connector_in: endpoint {
- remote-endpoint = <&hdmi_tx_tmds_out>;
- };
- };
- };
-
sound {
compatible = "amlogic,axg-sound-card";
model = "G12B-UGOOS-AM6";
@@ -277,110 +100,16 @@
};
};
};
-
- wifi32k: wifi32k {
- compatible = "pwm-clock";
- #clock-cells = <0>;
- clock-frequency = <32768>;
- pwms = <&pwm_ef 0 30518 0>; /* PWM_E at 32.768KHz */
- };
};
&arb {
status = "okay";
};
-&cec_AO {
- pinctrl-0 = <&cec_ao_a_h_pins>;
- pinctrl-names = "default";
- status = "disabled";
- hdmi-phandle = <&hdmi_tx>;
-};
-
-&cecb_AO {
- pinctrl-0 = <&cec_ao_b_h_pins>;
- pinctrl-names = "default";
- status = "okay";
- hdmi-phandle = <&hdmi_tx>;
-};
-
&clkc_audio {
status = "okay";
};
-&cpu0 {
- cpu-supply = <&vddcpu_b>;
- operating-points-v2 = <&cpu_opp_table_0>;
- clocks = <&clkc CLKID_CPU_CLK>;
- clock-latency = <50000>;
-};
-
-&cpu1 {
- cpu-supply = <&vddcpu_b>;
- operating-points-v2 = <&cpu_opp_table_0>;
- clocks = <&clkc CLKID_CPU_CLK>;
- clock-latency = <50000>;
-};
-
-&cpu100 {
- cpu-supply = <&vddcpu_a>;
- operating-points-v2 = <&cpub_opp_table_1>;
- clocks = <&clkc CLKID_CPUB_CLK>;
- clock-latency = <50000>;
-};
-
-&cpu101 {
- cpu-supply = <&vddcpu_a>;
- operating-points-v2 = <&cpub_opp_table_1>;
- clocks = <&clkc CLKID_CPUB_CLK>;
- clock-latency = <50000>;
-};
-
-&cpu102 {
- cpu-supply = <&vddcpu_a>;
- operating-points-v2 = <&cpub_opp_table_1>;
- clocks = <&clkc CLKID_CPUB_CLK>;
- clock-latency = <50000>;
-};
-
-&cpu103 {
- cpu-supply = <&vddcpu_a>;
- operating-points-v2 = <&cpub_opp_table_1>;
- clocks = <&clkc CLKID_CPUB_CLK>;
- clock-latency = <50000>;
-};
-
-&cvbs_vdac_port {
- cvbs_vdac_out: endpoint {
- remote-endpoint = <&cvbs_connector_in>;
- };
-};
-
-&ext_mdio {
- external_phy: ethernet-phy@0 {
- /* Realtek RTL8211F (0x001cc916) */
- reg = <0>;
- max-speed = <1000>;
-
- reset-assert-us = <10000>;
- reset-deassert-us = <30000>;
- reset-gpios = <&gpio GPIOZ_15 (GPIO_ACTIVE_LOW | GPIO_OPEN_DRAIN)>;
-
- interrupt-parent = <&gpio_intc>;
- /* MAC_INTR on GPIOZ_14 */
- interrupts = <26 IRQ_TYPE_LEVEL_LOW>;
- };
-};
-
-ðmac {
- pinctrl-0 = <ð_pins>, <ð_rgmii_pins>;
- pinctrl-names = "default";
- status = "okay";
- phy-mode = "rgmii";
- phy-handle = <&external_phy>;
- amlogic,tx-delay-ns = <2>;
-};
-
&frddr_a {
status = "okay";
};
@@ -393,112 +122,10 @@
status = "okay";
};
-&hdmi_tx {
- status = "okay";
- pinctrl-0 = <&hdmitx_hpd_pins>, <&hdmitx_ddc_pins>;
- pinctrl-names = "default";
- hdmi-supply = <&vcc_5v>;
-};
-
-&hdmi_tx_tmds_port {
- hdmi_tx_tmds_out: endpoint {
- remote-endpoint = <&hdmi_connector_in>;
- };
-};
-
&ir {
- status = "okay";
- pinctrl-0 = <&remote_input_ao_pins>;
- pinctrl-names = "default";
linux,rc-map-name = "rc-khadas";
};
-&pwm_ab {
- pinctrl-0 = <&pwm_a_e_pins>;
- pinctrl-names = "default";
- clocks = <&xtal>;
- clock-names = "clkin0";
- status = "okay";
-};
-
-&pwm_AO_cd {
- pinctrl-0 = <&pwm_ao_d_e_pins>;
- pinctrl-names = "default";
- clocks = <&xtal>;
- clock-names = "clkin1";
- status = "okay";
-};
-
-&pwm_ef {
- pinctrl-0 = <&pwm_e_pins>;
- pinctrl-names = "default";
- clocks = <&xtal>;
- clock-names = "clkin0";
- status = "okay";
-};
-
-/* SDIO */
-&sd_emmc_a {
- status = "okay";
- pinctrl-0 = <&sdio_pins>;
- pinctrl-1 = <&sdio_clk_gate_pins>;
- pinctrl-names = "default", "clk-gate";
- #address-cells = <1>;
- #size-cells = <0>;
-
- bus-width = <4>;
- cap-sd-highspeed;
- sd-uhs-sdr50;
- max-frequency = <100000000>;
-
- non-removable;
- disable-wp;
-
- mmc-pwrseq = <&sdio_pwrseq>;
-
- vmmc-supply = <&vddao_3v3>;
- vqmmc-supply = <&vddao_1v8>;
-
- brcmf: wifi@1 {
- reg = <1>;
- compatible = "brcm,bcm4329-fmac";
- };
-};
-
-/* SD card */
-&sd_emmc_b {
- status = "okay";
- pinctrl-0 = <&sdcard_c_pins>;
- pinctrl-1 = <&sdcard_clk_gate_c_pins>;
- pinctrl-names = "default", "clk-gate";
-
- bus-width = <4>;
- cap-sd-highspeed;
- max-frequency = <50000000>;
- disable-wp;
-
- cd-gpios = <&gpio GPIOC_6 GPIO_ACTIVE_LOW>;
- vmmc-supply = <&vddao_3v3>;
- vqmmc-supply = <&vddao_3v3>;
-};
-
-/* eMMC */
-&sd_emmc_c {
- status = "okay";
- pinctrl-0 = <&emmc_ctrl_pins>, <&emmc_data_8b_pins>, <&emmc_ds_pins>;
- pinctrl-1 = <&emmc_clk_gate_pins>;
- pinctrl-names = "default", "clk-gate";
-
- bus-width = <8>;
- cap-mmc-highspeed;
- max-frequency = <100000000>;
- disable-wp;
-
- mmc-pwrseq = <&emmc_pwrseq>;
- vmmc-supply = <&vcc_3v3>;
- vqmmc-supply = <&flash_1v8>;
-};
-
&spdifout {
pinctrl-0 = <&spdif_out_h_pins>;
pinctrl-names = "default";
@@ -520,38 +147,3 @@
&tohdmitx {
status = "okay";
};
-
-&uart_A {
- status = "okay";
- pinctrl-0 = <&uart_a_pins>, <&uart_a_cts_rts_pins>;
- pinctrl-names = "default";
- uart-has-rtscts;
-
- bluetooth {
- compatible = "brcm,bcm43438-bt";
- shutdown-gpios = <&gpio GPIOX_17 GPIO_ACTIVE_HIGH>;
- max-speed = <2000000>;
- clocks = <&wifi32k>;
- clock-names = "lpo";
- };
-};
-
-&uart_AO {
- status = "okay";
- pinctrl-0 = <&uart_ao_a_pins>;
- pinctrl-names = "default";
-};
-
-&usb {
- status = "okay";
- dr_mode = "host";
- vbus-supply = <&usb_pwr_en>;
-};
-
-&usb2_phy0 {
- phy-supply = <&usb1_pow>;
-};
-
-&usb2_phy1 {
- phy-supply = <&usb1_pow>;
-};
diff --git a/arch/arm64/boot/dts/amlogic/meson-g12b-w400.dtsi b/arch/arm64/boot/dts/amlogic/meson-g12b-w400.dtsi
new file mode 100644
index 000000000000..98b70d216a6f
--- /dev/null
+++ b/arch/arm64/boot/dts/amlogic/meson-g12b-w400.dtsi
@@ -0,0 +1,423 @@
+// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
+/*
+ * Copyright (c) 2019 BayLibre, SAS
+ * Author: Neil Armstrong <narmstrong@baylibre.com>
+ * Copyright (c) 2019 Christian Hewitt <christianshewitt@gmail.com>
+ */
+
+/dts-v1/;
+
+#include "meson-g12b.dtsi"
+#include "meson-g12b-s922x.dtsi"
+#include <dt-bindings/input/input.h>
+#include <dt-bindings/gpio/meson-g12a-gpio.h>
+
+/ {
+ aliases {
+ serial0 = &uart_AO;
+ ethernet0 = ðmac;
+ };
+
+ chosen {
+ stdout-path = "serial0:115200n8";
+ };
+
+ memory@0 {
+ device_type = "memory";
+ reg = <0x0 0x0 0x0 0x40000000>;
+ };
+
+ emmc_pwrseq: emmc-pwrseq {
+ compatible = "mmc-pwrseq-emmc";
+ reset-gpios = <&gpio BOOT_12 GPIO_ACTIVE_LOW>;
+ };
+
+ sdio_pwrseq: sdio-pwrseq {
+ compatible = "mmc-pwrseq-simple";
+ reset-gpios = <&gpio GPIOX_6 GPIO_ACTIVE_LOW>;
+ clocks = <&wifi32k>;
+ clock-names = "ext_clock";
+ };
+
+ flash_1v8: regulator-flash_1v8 {
+ compatible = "regulator-fixed";
+ regulator-name = "FLASH_1V8";
+ regulator-min-microvolt = <1800000>;
+ regulator-max-microvolt = <1800000>;
+ vin-supply = <&vcc_3v3>;
+ regulator-always-on;
+ };
+
+ main_12v: regulator-main_12v {
+ compatible = "regulator-fixed";
+ regulator-name = "12V";
+ regulator-min-microvolt = <12000000>;
+ regulator-max-microvolt = <12000000>;
+ regulator-always-on;
+ };
+
+ vcc_5v: regulator-vcc_5v {
+ compatible = "regulator-fixed";
+ regulator-name = "VCC_5V";
+ regulator-min-microvolt = <5000000>;
+ regulator-max-microvolt = <5000000>;
+ vin-supply = <&main_12v>;
+
+ gpio = <&gpio GPIOH_8 GPIO_OPEN_DRAIN>;
+ enable-active-high;
+ };
+
+ vcc_1v8: regulator-vcc_1v8 {
+ compatible = "regulator-fixed";
+ regulator-name = "VCC_1V8";
+ regulator-min-microvolt = <1800000>;
+ regulator-max-microvolt = <1800000>;
+ vin-supply = <&vcc_3v3>;
+ regulator-always-on;
+ };
+
+ vcc_3v3: regulator-vcc_3v3 {
+ compatible = "regulator-fixed";
+ regulator-name = "VCC_3V3";
+ regulator-min-microvolt = <3300000>;
+ regulator-max-microvolt = <3300000>;
+ vin-supply = <&vddao_3v3>;
+ regulator-always-on;
+ /* FIXME: actually controlled by VDDCPU_B_EN */
+ };
+
+ vddcpu_a: regulator-vddcpu-a {
+ /*
+ * MP1653 Regulator.
+ */
+ compatible = "pwm-regulator";
+
+ regulator-name = "VDDCPU_A";
+ regulator-min-microvolt = <721000>;
+ regulator-max-microvolt = <1022000>;
+
+ vin-supply = <&main_12v>;
+
+ pwms = <&pwm_ab 0 1250 0>;
+ pwm-dutycycle-range = <100 0>;
+
+ regulator-boot-on;
+ regulator-always-on;
+ };
+
+ vddcpu_b: regulator-vddcpu-b {
+ /*
+ * MP1652 Regulator.
+ */
+ compatible = "pwm-regulator";
+
+ regulator-name = "VDDCPU_B";
+ regulator-min-microvolt = <721000>;
+ regulator-max-microvolt = <1022000>;
+
+ vin-supply = <&main_12v>;
+
+ pwms = <&pwm_AO_cd 1 1250 0>;
+ pwm-dutycycle-range = <100 0>;
+
+ regulator-boot-on;
+ regulator-always-on;
+ };
+
+ usb1_pow: regulator-usb1-pow {
+ compatible = "regulator-fixed";
+ regulator-name = "USB1_POW";
+ regulator-min-microvolt = <5000000>;
+ regulator-max-microvolt = <5000000>;
+ vin-supply = <&vcc_5v>;
+
+ /* connected to SY6280A Power Switch */
+ gpio = <&gpio GPIOA_8 GPIO_ACTIVE_HIGH>;
+ enable-active-high;
+ };
+
+ usb_pwr_en: regulator-usb-pwr-en {
+ compatible = "regulator-fixed";
+ regulator-name = "USB_PWR_EN";
+ regulator-min-microvolt = <5000000>;
+ regulator-max-microvolt = <5000000>;
+ vin-supply = <&vcc_5v>;
+
+ /* Connected to USB3 Type-A Port power enable */
+ gpio = <&gpio GPIOAO_7 GPIO_ACTIVE_HIGH>;
+ enable-active-high;
+ };
+
+ vddao_1v8: regulator-vddao-1v8 {
+ compatible = "regulator-fixed";
+ regulator-name = "VDDAO_1V8";
+ regulator-min-microvolt = <1800000>;
+ regulator-max-microvolt = <1800000>;
+ vin-supply = <&vddao_3v3>;
+ regulator-always-on;
+ };
+
+ vddao_3v3: regulator-vddao-3v3 {
+ compatible = "regulator-fixed";
+ regulator-name = "VDDAO_3V3";
+ regulator-min-microvolt = <3300000>;
+ regulator-max-microvolt = <3300000>;
+ vin-supply = <&main_12v>;
+ regulator-always-on;
+ };
+
+ cvbs-connector {
+ compatible = "composite-video-connector";
+
+ port {
+ cvbs_connector_in: endpoint {
+ remote-endpoint = <&cvbs_vdac_out>;
+ };
+ };
+ };
+
+ hdmi-connector {
+ compatible = "hdmi-connector";
+ type = "a";
+
+ port {
+ hdmi_connector_in: endpoint {
+ remote-endpoint = <&hdmi_tx_tmds_out>;
+ };
+ };
+ };
+
+ wifi32k: wifi32k {
+ compatible = "pwm-clock";
+ #clock-cells = <0>;
+ clock-frequency = <32768>;
+ pwms = <&pwm_ef 0 30518 0>; /* PWM_E at 32.768KHz */
+ };
+};
+
+&cec_AO {
+ pinctrl-0 = <&cec_ao_a_h_pins>;
+ pinctrl-names = "default";
+ status = "disabled";
+ hdmi-phandle = <&hdmi_tx>;
+};
+
+&cecb_AO {
+ pinctrl-0 = <&cec_ao_b_h_pins>;
+ pinctrl-names = "default";
+ status = "okay";
+ hdmi-phandle = <&hdmi_tx>;
+};
+
+&cpu0 {
+ cpu-supply = <&vddcpu_b>;
+ operating-points-v2 = <&cpu_opp_table_0>;
+ clocks = <&clkc CLKID_CPU_CLK>;
+ clock-latency = <50000>;
+};
+
+&cpu1 {
+ cpu-supply = <&vddcpu_b>;
+ operating-points-v2 = <&cpu_opp_table_0>;
+ clocks = <&clkc CLKID_CPU_CLK>;
+ clock-latency = <50000>;
+};
+
+&cpu100 {
+ cpu-supply = <&vddcpu_a>;
+ operating-points-v2 = <&cpub_opp_table_1>;
+ clocks = <&clkc CLKID_CPUB_CLK>;
+ clock-latency = <50000>;
+};
+
+&cpu101 {
+ cpu-supply = <&vddcpu_a>;
+ operating-points-v2 = <&cpub_opp_table_1>;
+ clocks = <&clkc CLKID_CPUB_CLK>;
+ clock-latency = <50000>;
+};
+
+&cpu102 {
+ cpu-supply = <&vddcpu_a>;
+ operating-points-v2 = <&cpub_opp_table_1>;
+ clocks = <&clkc CLKID_CPUB_CLK>;
+ clock-latency = <50000>;
+};
+
+&cpu103 {
+ cpu-supply = <&vddcpu_a>;
+ operating-points-v2 = <&cpub_opp_table_1>;
+ clocks = <&clkc CLKID_CPUB_CLK>;
+ clock-latency = <50000>;
+};
+
+&cvbs_vdac_port {
+ cvbs_vdac_out: endpoint {
+ remote-endpoint = <&cvbs_connector_in>;
+ };
+};
+
+&ext_mdio {
+ external_phy: ethernet-phy@0 {
+ /* Realtek RTL8211F (0x001cc916) */
+ reg = <0>;
+ max-speed = <1000>;
+
+ reset-assert-us = <10000>;
+ reset-deassert-us = <30000>;
+ reset-gpios = <&gpio GPIOZ_15 (GPIO_ACTIVE_LOW | GPIO_OPEN_DRAIN)>;
+
+ interrupt-parent = <&gpio_intc>;
+ /* MAC_INTR on GPIOZ_14 */
+ interrupts = <26 IRQ_TYPE_LEVEL_LOW>;
+ };
+};
+
+ðmac {
+ pinctrl-0 = <ð_pins>, <ð_rgmii_pins>;
+ pinctrl-names = "default";
+ status = "okay";
+ phy-mode = "rgmii";
+ phy-handle = <&external_phy>;
+ amlogic,tx-delay-ns = <2>;
+};
+
+&hdmi_tx {
+ status = "okay";
+ pinctrl-0 = <&hdmitx_hpd_pins>, <&hdmitx_ddc_pins>;
+ pinctrl-names = "default";
+ hdmi-supply = <&vcc_5v>;
+};
+
+&hdmi_tx_tmds_port {
+ hdmi_tx_tmds_out: endpoint {
+ remote-endpoint = <&hdmi_connector_in>;
+ };
+};
+
+&ir {
+ status = "okay";
+ pinctrl-0 = <&remote_input_ao_pins>;
+ pinctrl-names = "default";
+};
+
+&pwm_ab {
+ pinctrl-0 = <&pwm_a_e_pins>;
+ pinctrl-names = "default";
+ clocks = <&xtal>;
+ clock-names = "clkin0";
+ status = "okay";
+};
+
+&pwm_AO_cd {
+ pinctrl-0 = <&pwm_ao_d_e_pins>;
+ pinctrl-names = "default";
+ clocks = <&xtal>;
+ clock-names = "clkin1";
+ status = "okay";
+};
+
+&pwm_ef {
+ pinctrl-0 = <&pwm_e_pins>;
+ pinctrl-names = "default";
+ clocks = <&xtal>;
+ clock-names = "clkin0";
+ status = "okay";
+};
+
+/* SDIO */
+&sd_emmc_a {
+ status = "okay";
+ pinctrl-0 = <&sdio_pins>;
+ pinctrl-1 = <&sdio_clk_gate_pins>;
+ pinctrl-names = "default", "clk-gate";
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ bus-width = <4>;
+ cap-sd-highspeed;
+ sd-uhs-sdr50;
+ max-frequency = <100000000>;
+
+ non-removable;
+ disable-wp;
+
+ mmc-pwrseq = <&sdio_pwrseq>;
+
+ vmmc-supply = <&vddao_3v3>;
+ vqmmc-supply = <&vddao_1v8>;
+
+ brcmf: wifi@1 {
+ reg = <1>;
+ compatible = "brcm,bcm4329-fmac";
+ };
+};
+
+/* SD card */
+&sd_emmc_b {
+ status = "okay";
+ pinctrl-0 = <&sdcard_c_pins>;
+ pinctrl-1 = <&sdcard_clk_gate_c_pins>;
+ pinctrl-names = "default", "clk-gate";
+
+ bus-width = <4>;
+ cap-sd-highspeed;
+ max-frequency = <50000000>;
+ disable-wp;
+
+ cd-gpios = <&gpio GPIOC_6 GPIO_ACTIVE_LOW>;
+ vmmc-supply = <&vddao_3v3>;
+ vqmmc-supply = <&vddao_3v3>;
+};
+
+/* eMMC */
+&sd_emmc_c {
+ status = "okay";
+ pinctrl-0 = <&emmc_ctrl_pins>, <&emmc_data_8b_pins>, <&emmc_ds_pins>;
+ pinctrl-1 = <&emmc_clk_gate_pins>;
+ pinctrl-names = "default", "clk-gate";
+
+ bus-width = <8>;
+ cap-mmc-highspeed;
+ max-frequency = <100000000>;
+ disable-wp;
+
+ mmc-pwrseq = <&emmc_pwrseq>;
+ vmmc-supply = <&vcc_3v3>;
+ vqmmc-supply = <&flash_1v8>;
+};
+
+&uart_A {
+ status = "okay";
+ pinctrl-0 = <&uart_a_pins>, <&uart_a_cts_rts_pins>;
+ pinctrl-names = "default";
+ uart-has-rtscts;
+
+ bluetooth {
+ compatible = "brcm,bcm43438-bt";
+ shutdown-gpios = <&gpio GPIOX_17 GPIO_ACTIVE_HIGH>;
+ max-speed = <2000000>;
+ clocks = <&wifi32k>;
+ clock-names = "lpo";
+ };
+};
+
+&uart_AO {
+ status = "okay";
+ pinctrl-0 = <&uart_ao_a_pins>;
+ pinctrl-names = "default";
+};
+
+&usb {
+ status = "okay";
+ dr_mode = "host";
+ vbus-supply = <&usb_pwr_en>;
+};
+
+&usb2_phy0 {
+ phy-supply = <&usb1_pow>;
+};
+
+&usb2_phy1 {
+ phy-supply = <&usb1_pow>;
+};
--
2.17.1
^ permalink raw reply related
* [PATCH v2 0/5] arm64: dts: meson: add W400 dtsi and GT-King/Pro devices
From: Christian Hewitt @ 2020-05-18 2:25 UTC (permalink / raw)
To: Rob Herring, Mark Rutland, Kevin Hilman, devicetree,
linux-arm-kernel, linux-amlogic, linux-kernel
Cc: Christian Hewitt
This series combines patch 2 from [1] which converts the existing Ugoos
AM6 device-tree to a common W400 dtsi and dts, and then reworks the
Beelink GT-King/GT-King Pro serries from [2] to use the dtsi, but this
time without the offending common audio dtsi approach. I've carried
forwards acks on bindings from Rob as these did not change.
[1] https://patchwork.kernel.org/patch/11497105/
[2] https://patchwork.kernel.org/project/linux-amlogic/list/?series=273483
Christian Hewitt (4):
arm64: dts: meson: convert ugoos-am6 to common w400 dtsi
dt-bindings: arm: amlogic: add support for the Beelink GT-King
arm64: dts: meson-g12b-gtking: add initial device-tree
arm64: dts: meson-g12b-gtking-pro: add initial device-tree
chewitt (1):
dt-bindings: arm: amlogic: add support for the Beelink GT-King Pro
.../devicetree/bindings/arm/amlogic.yaml | 2 +
arch/arm64/boot/dts/amlogic/Makefile | 2 +
.../dts/amlogic/meson-g12b-gtking-pro.dts | 125 ++++++
.../boot/dts/amlogic/meson-g12b-gtking.dts | 145 ++++++
.../boot/dts/amlogic/meson-g12b-ugoos-am6.dts | 410 +----------------
.../boot/dts/amlogic/meson-g12b-w400.dtsi | 423 ++++++++++++++++++
6 files changed, 698 insertions(+), 409 deletions(-)
create mode 100644 arch/arm64/boot/dts/amlogic/meson-g12b-gtking-pro.dts
create mode 100644 arch/arm64/boot/dts/amlogic/meson-g12b-gtking.dts
create mode 100644 arch/arm64/boot/dts/amlogic/meson-g12b-w400.dtsi
--
2.17.1
^ permalink raw reply
* Re: [PATCH v2 2/2] input: misc: Add support for Azoteq IQS269A
From: Dmitry Torokhov @ 2020-05-18 2:23 UTC (permalink / raw)
To: Jeff LaBundy; +Cc: robh+dt, linux-input, devicetree
In-Reply-To: <1588352982-5117-2-git-send-email-jeff@labundy.com>
Oon Fri, May 01, 2020 at 12:09:42PM -0500, Jeff LaBundy wrote:
> This patch adds support for the Azoteq IQS269A capacitive touch
> controller.
>
> Signed-off-by: Jeff LaBundy <jeff@labundy.com>
Applied, thank you.
--
Dmitry
^ permalink raw reply
* Re: [PATCH v2 1/2] dt-bindings: input: Add bindings for Azoteq IQS269A
From: Dmitry Torokhov @ 2020-05-18 2:22 UTC (permalink / raw)
To: Jeff LaBundy; +Cc: robh+dt, linux-input, devicetree
In-Reply-To: <1588352982-5117-1-git-send-email-jeff@labundy.com>
On Fri, May 01, 2020 at 12:09:41PM -0500, Jeff LaBundy wrote:
> This patch adds device tree bindings for the Azoteq IQS269A
> capacitive touch controller.
>
> Signed-off-by: Jeff LaBundy <jeff@labundy.com>
Applied, thank you.
--
Dmitry
^ permalink raw reply
* [PATCH] dt-bindings: interrupt-controller: Convert imx irqsteer to json-schema
From: Anson Huang @ 2020-05-18 2:10 UTC (permalink / raw)
To: tglx, jason, maz, robh+dt, l.stach, linux-kernel, devicetree; +Cc: Linux-imx
Convert the i.MX IRQSTEER binding to DT schema format using json-schema.
Signed-off-by: Anson Huang <Anson.Huang@nxp.com>
---
.../bindings/interrupt-controller/fsl,irqsteer.txt | 35 ---------
.../interrupt-controller/fsl,irqsteer.yaml | 87 ++++++++++++++++++++++
2 files changed, 87 insertions(+), 35 deletions(-)
delete mode 100644 Documentation/devicetree/bindings/interrupt-controller/fsl,irqsteer.txt
create mode 100644 Documentation/devicetree/bindings/interrupt-controller/fsl,irqsteer.yaml
diff --git a/Documentation/devicetree/bindings/interrupt-controller/fsl,irqsteer.txt b/Documentation/devicetree/bindings/interrupt-controller/fsl,irqsteer.txt
deleted file mode 100644
index 582991c..0000000
--- a/Documentation/devicetree/bindings/interrupt-controller/fsl,irqsteer.txt
+++ /dev/null
@@ -1,35 +0,0 @@
-Freescale IRQSTEER Interrupt multiplexer
-
-Required properties:
-
-- compatible: should be:
- - "fsl,imx8m-irqsteer"
- - "fsl,imx-irqsteer"
-- reg: Physical base address and size of registers.
-- interrupts: Should contain the up to 8 parent interrupt lines used to
- multiplex the input interrupts. They should be specified sequentially
- from output 0 to 7.
-- clocks: Should contain one clock for entry in clock-names
- see Documentation/devicetree/bindings/clock/clock-bindings.txt
-- clock-names:
- - "ipg": main logic clock
-- interrupt-controller: Identifies the node as an interrupt controller.
-- #interrupt-cells: Specifies the number of cells needed to encode an
- interrupt source. The value must be 1.
-- fsl,channel: The output channel that all input IRQs should be steered into.
-- fsl,num-irqs: Number of input interrupts of this channel.
- Should be multiple of 32 input interrupts and up to 512 interrupts.
-
-Example:
-
- interrupt-controller@32e2d000 {
- compatible = "fsl,imx8m-irqsteer", "fsl,imx-irqsteer";
- reg = <0x32e2d000 0x1000>;
- interrupts = <GIC_SPI 18 IRQ_TYPE_LEVEL_HIGH>;
- clocks = <&clk IMX8MQ_CLK_DISP_APB_ROOT>;
- clock-names = "ipg";
- fsl,channel = <0>;
- fsl,num-irqs = <64>;
- interrupt-controller;
- #interrupt-cells = <1>;
- };
diff --git a/Documentation/devicetree/bindings/interrupt-controller/fsl,irqsteer.yaml b/Documentation/devicetree/bindings/interrupt-controller/fsl,irqsteer.yaml
new file mode 100644
index 0000000..a2bc723
--- /dev/null
+++ b/Documentation/devicetree/bindings/interrupt-controller/fsl,irqsteer.yaml
@@ -0,0 +1,87 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/interrupt-controller/fsl,irqsteer.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Freescale IRQSTEER Interrupt multiplexer
+
+maintainers:
+ - Lucas Stach <l.stach@pengutronix.de>
+
+properties:
+ compatible:
+ const: fsl,imx-irqsteer
+
+ reg:
+ maxItems: 1
+
+ interrupts:
+ description: |
+ should contain the up to 8 parent interrupt lines used to multiplex
+ the input interrupts. They should be specified sequentially from
+ output 0 to 7.
+ items:
+ - description: irqsteer channel 0
+ - description: irqsteer channel 1
+ - description: irqsteer channel 2
+ - description: irqsteer channel 3
+ - description: irqsteer channel 4
+ - description: irqsteer channel 5
+ - description: irqsteer channel 6
+ - description: irqsteer channel 7
+ minItems: 1
+ maxItems: 8
+
+ clocks:
+ maxItems: 1
+
+ clock-names:
+ const: ipg
+
+ interrupt-controller: true
+
+ "#interrupt-cells":
+ const: 1
+
+ fsl,channel:
+ $ref: '/schemas/types.yaml#/definitions/uint32'
+ description: |
+ u32 value representing the output channel that all input IRQs should be
+ steered into.
+
+ fsl,num-irqs:
+ $ref: '/schemas/types.yaml#/definitions/uint32'
+ description: |
+ u32 value representing the number of input interrupts of this channel,
+ should be multiple of 32 input interrupts and up to 512 interrupts.
+
+required:
+ - compatible
+ - reg
+ - interrupts
+ - clocks
+ - clock-names
+ - interrupt-controller
+ - "#interrupt-cells"
+ - fsl,channel
+ - fsl,num-irqs
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/clock/imx8mq-clock.h>
+ #include <dt-bindings/interrupt-controller/arm-gic.h>
+
+ interrupt-controller@32e2d000 {
+ compatible = "fsl,imx-irqsteer";
+ reg = <0x32e2d000 0x1000>;
+ interrupts = <GIC_SPI 18 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&clk IMX8MQ_CLK_DISP_APB_ROOT>;
+ clock-names = "ipg";
+ fsl,channel = <0>;
+ fsl,num-irqs = <64>;
+ interrupt-controller;
+ #interrupt-cells = <1>;
+ };
--
2.7.4
^ permalink raw reply related
* [RESEND][V5 PATCH 1/2] dt-bindings: Added device tree binding for max98390
From: Steve Lee @ 2020-05-18 0:49 UTC (permalink / raw)
To: lgirdwood, broonie, robh+dt, alsa-devel, devicetree, linux-kernel
Cc: ryan.lee.maxim, ryans.lee, steves.lee.maxim, Steve Lee
Add documentation for DT binding of max98390 amplifier driver.
Signed-off-by: Steve Lee <steves.lee@maximintegrated.com>
---
Changed since V4:
* No changes.
Changed since V3:
* No changes.
Changed since V2:
* No changes.
Changed since V1:
* Modified sample text in example
.../devicetree/bindings/sound/max98390.txt | 26 +++++++++++++++++++
1 file changed, 26 insertions(+)
create mode 100644 Documentation/devicetree/bindings/sound/max98390.txt
diff --git a/Documentation/devicetree/bindings/sound/max98390.txt b/Documentation/devicetree/bindings/sound/max98390.txt
new file mode 100644
index 000000000000..0ddd4c6ae55e
--- /dev/null
+++ b/Documentation/devicetree/bindings/sound/max98390.txt
@@ -0,0 +1,26 @@
+Maxim Integrated MAX98390 Speaker Amplifier
+
+This device supports I2C.
+
+Required properties:
+
+ - compatible : "maxim,max98390"
+
+ - reg : the I2C address of the device.
+
+Optional properties:
+
+- maxim,temperature_calib
+ u32. The calculated temperature data was measured while doing the calibration. Data : Temp / 100 * 2^12
+
+- maxim,r0_calib
+ u32. This is r0 calibration data which was measured in factory mode.
+
+Example:
+
+codec: max98390@38 {
+ compatible = "maxim,max98390";
+ reg = <0x38>;
+ maxim,temperature_calib = <1024>;
+ maxim,r0_calib = <100232>;
+};
--
2.17.1
^ permalink raw reply related
* Re: [PATCH 2/2] spi: Add Baikal-T1 System Boot SPI Controller driver
From: Serge Semin @ 2020-05-18 0:05 UTC (permalink / raw)
To: Mark Brown
Cc: Serge Semin, Ramil Zaripov, Alexey Malahov, Thomas Bogendoerfer,
Paul Burton, Ralf Baechle, Lee Jones, Miquel Raynal,
Arnd Bergmann, Rob Herring, linux-mips, devicetree, John Garry,
Chuanhong Guo, Andy Shevchenko, Eddie James, Geert Uytterhoeven,
Chris Packham, Tomer Maimon, Masahisa Kojima, Krzysztof Kozlowski,
Florian Fainelli, Jassi Brar, linux-kernel, linux-spi
In-Reply-To: <20200511212506.GA23852@sirena.org.uk>
Mark,
I give up.) I'll try to integrate what I've done here in the generic DW APB SSI
driver framework. Then add some hooks so to support our specific DW APB SSI
controller. The I create a glue-layer for it. My answers to you comments are
below.
On Mon, May 11, 2020 at 10:25:06PM +0100, Mark Brown wrote:
> On Sun, May 10, 2020 at 03:20:39AM +0300, Serge Semin wrote:
> > On Fri, May 08, 2020 at 12:37:51PM +0100, Mark Brown wrote:
>
> > > Your CC list on this series is *very* wide - are you sure that this is
> > > relevant to everyone you're sending things to? Kernel developers often
> > > get a lot of mail meaning that extra mail can become a bit overwhelming
> > > and cause things to get lost in the noise.
>
> > MIPS folks are here since Baikal-T1 is a MIPS-based chip and this patchset
> > is a part of the campaign of integrating the SoC support into the kernel.
> > With Lee and Miquel we discussed the dirmap support in the framework of another
> > patchset. Rob and devicetree-list are CC'ed due to having the bindings tree
> > updated. Then a series of folks who recently submitted the biggest updates into
> > the spi subsystems so might have valuable comments for this driver as well. So
> > yes, I am sure.
>
> I think you've got too many people who've been contributing to the
> subsystem here at least - it looks like you picked up some people who
> recently wrote drivers but haven't been doing a lot of review for
> example for example.
>
> > Anyway ok. I'll fix it. Is it ok to have the C-style comments in the header
> > file?
> > * It isn't included by any assembly so from this point of view C++ style
> > * shall also work there.
>
> The SPDX stuff requires C style comments in headers so yes.
>
> > Secondly the message of that commit states "Devices with chip selects driven
> > via GPIO are not compatible with the spi-mem operations." I find this statement
> > questionable, because for instance this device supports memory operations with
> > GPIO-driven CS. Though in current implementation the driver fallback to using normal
> > push-pull IO mode if GPIO CS is utilized as safer one. But even in this case
> > it's better than splitting the memory operations up into the transfers, which is
> > developed in the spi_mem_exec_op() method.
>
> > So in this matter my question is: how to modify the SPI-mem interface so the
> > SPI-memory operations would also work with GPIO driven CS? Some additional flag
> > might work...
>
> Yes, some flags should work here - the issue was that at least some
> controllers may end up trying to do multiple SPI operations for one
> spi-mem thing which will break if the chip select doesn't get changed to
> correspond with what's going on.
Ok. New SPI flag it is then. It will be something like this:
+ #define SPI_CONTROLLER_FLASH_SS BIT(6)
Then we have to convert spi_set_cs() method to be non-static in the spi.c
to be used in the spi-mem.c to properly select slaves
Then the spi_mem_access_start() and spi_mem_access_stop() of spi-mem.c should be
updated in the following way:
--- spi_mem_access_start()
+++ spi_mem_access_start()
mutex_lock(&ctlr->bus_lock_mutex);
mutex_lock(&ctlr->io_mutex);
+
+ if (ctlr->flags & SPI_CONTROLLER_FLASH_SS)
+ spi_set_cs(mem->spi, true);
return 0;
}
--- spi_mem_access_end()
+++ spi_mem_access_end()
static void spi_mem_access_end(struct spi_mem *mem)
{
struct spi_controller *ctlr = mem->spi->controller;
+
+ if (ctlr->flags & SPI_CONTROLLER_FLASH_SS)
+ spi_set_cs(mem->spi, false);
mutex_unlock(&ctlr->io_mutex);
mutex_unlock(&ctlr->bus_lock_mutex);
---
Method spi_mem_exec_op() shall also make sure that even if GPIO-driven CS is
utilized the normal mem-op is executed. Something like this should do this:
--- spi_mem_exec_op()
+++ spi_mem_exec_op()
if (!spi_mem_internal_supports_op(mem, op))
return -ENOTSUPP;
- if (ctlr->mem_ops && !mem->spi->cs_gpiod) {
+ if (ctlr->mem_ops &&
+ (!mem->spi->cs_gpiod || (ctlr->flags & SPI_CONTROLLER_FLASH_SS))) {
ret = spi_mem_access_start(mem);
if (ret)
return ret;
---
So, what do you think?
>
> > Thirdly what about dirmap operations? If we got a GPIO driven CS then due to
> > lacking any CS manipulation in spi_mem_dirmap_read() method we wouldn't have
> > been able to make the direct mapping working without manual setting the GPIO.
> > So the same question here. How to work this around and justify your requirement?
> > Until the question is answered and we come up with reasonable solution in order
> > to have the SPI-mem/dirmap interface working together with GPIO CS support I have
> > to leave the manual GPIO manipulation.
>
> If the issue with ensuring that chip select is managed appropriately for
> transfers can be resolved then push that stuff up to the framework. If
> not then it's not clear that the open coded version can work well
> with GPIO chip selects either.
See the comment above.
>
> > > > +static void bs_update_cfg(struct bt1_spi *bs, struct spi_transfer *xfer)
> > > > +{
>
> > > This has exactly one caller, perhaps it could just be inlined there? I
> > > think this applies to some of the other internal functions.
>
> > I don't want to inline methods just because they are used in a single place. This
> > might worsen readability and in this case it will. Currently the transfer_one()
> > method is consistent with self-explanatory methods: update config, push-pull
> > bytes/words, check status. This also applies to the rest of the code. I can
> > consider some improvements/optimizations in this matter though, but embedding
> > the functions isn't one of them. Moreover the compiler does the static
> > methods inlining automatically as soon as it sees they are called just once.
>
> One of the things that creating internal APIs like this does is that it
> adds another layer of structure to the driver, making it a bit harder to
> follow that it's following the usual structures of a Linux driver
> (especially noticable here given the open coding). It creates the
> impression of the platform portability layers that people sometimes try
> to build.
Let's stop this discussion.) Since I am going to integrate this patch into the
generic DW APB SSI driver, I will have to follow that driver design anyway. So
most likely I won't implement a new handy abstraction.
>
> > > > +static int bs_check_status(struct bt1_spi *bs)
> > > > +{
>
> > > It's not obvious from the name that this function will busy wait rather
> > > than just reading some status registers.
>
> > What do you suggest then? Renaming? Splitting up? If renaming, then what name do
> > you prefer? Something like bs_check_completion()?
>
> wait_for_completion() or something else that mentions that it will wait
> for completion rather than just looking to see if the operation has
> completed.
Ok. If it will be still applicable.
>
> > > > +static int bs_exec_mem_op(struct spi_mem *mem,
> > > > + const struct spi_mem_op *op)
> > > > +{
>
> > > It's not clear to me that this hardware actually supports spi_mem in
> > > hardware?
>
> > SPI-mem operations are implemented by means of the EEPROM-read and Tx-only
> > modes of the controller.
>
> Sure, but those seem like normal SPI-level things rather than cases
> where the hardware understands that it has a flash attached and is doing
> flash specific things.
No, hardware can't detect whether the flash is attached. This must be defined by
the platform, like based on the DT sub-nodes.
> A very common case for this stuff is that
> controllers have acceleration blocks for read and fall back on normal
> SPI for writes and erases, that sounds like what's going on here.
Well, yeah, they do provide some acceleration. EEPROM-read provides automatic
write-cmd-dummy-data-then-read operations. But in this case the only thing we
have to push into the SPI Tx FIFO is command and dummy bytes. The read operation
will be performed automatically. So the only thing the driver has to do is to
keep up with Rx FIFO data pulling out before it's overflown. Similarly Tx-only
mode is used to perform the Flash write/erase commands. The driver has to keep up
with pushing data into the Tx FIFO before it gets emptied and CS is de-asserted.
Using these operations is mandatory in case if there is no GPIO-driven CS is
utilized, since native CS is automatically asserted during the whole EEPROM-read
or Tx-only mode executed.
As I also said such operations are very useful, since minimize IO operations
performed over the APB bus. By doing so we can support higher SPI bus
frequencies.
>
> > > > + if (!bs->cfg.cs_gpiod) {
> > > > + bs_push_bytes(bs, cmd, len);
> > > > +
> > > > + if (op->data.dir == SPI_MEM_DATA_IN)
> > > > + ret = bs_pull_bytes(bs, op->data.buf.in,
> > > > + op->data.nbytes);
> > > > + } else {
> > > > + bs_pp_bytes(bs, cmd, NULL, len);
> > > > +
> > > > + if (op->data.dir == SPI_MEM_DATA_IN)
> > > > + bs_pp_bytes(bs, NULL, op->data.buf.in,
> > > > + op->data.nbytes);
> > > > + }
> > >
>
> > > The actual transfers here are done using the same PIO functions as
> > > everything else as far as I can see which makes me wonder what this
> > > spi_mem implementation is adding over the standard SPI flash support.
>
> > No, if no GPIO CS is supplied the memory read operation is performed by means of
> > the EEPROM-read mode of the DW SSI controller (Write command is written to the
> > Tx FIFO and read data length - to the CTRLR1 register). The memory write
>
> So EEPROM read mode is a combined write/read - is that somehow less
> performant or something than separate opeations so there's a reason not
> to use it except in this special circumstance?
Actually It's more performant (less APB-bus MMIO operations required to perform
the transfers) and safer in case of Native CS-driven slave devices. In case of
GPIO-driven CS EEPROM and Tx-only are still more performant modes, but less safe
than normal synchronous SPI Tx/Rx mode.
I'll explain it one more time to logically continue this discussion. In general
the DW APB SSI controller may be utilized on two types of platform setups:
1) A slave device is selected by the DW APB SSI Native CS lane only.
You know, that Dw APB SSI native chip select is automatically asserted by the
SPI controller during a transfer being executed. As soon as there is no data in
the Tx FIFO to transfer (Tx-only or Tx-Rx modes) or there is no data left to
receive (EEPROM-read or Rx-only mode), the native CS will be automatically
de-asserted.
If we decided not to implement the mem-ops in the driver, then we'd have to:
for flash-write operation: analyze the passed message ahead, merge the Tx-only
operations and atomically execute them after activating Tx-only mode;
for flash-read operation: analyze the passed message ahead, merge Tx-only
operations, combine it with Rx-only tail part and atomically execute them all
after activating the EEPROM-read mode. Well, what we've done here is basically
a reverse operation performed by the spi_exec_mem_op(), which just split the
spi_mem_op structure up into a set of spi_transfer's. Why would we need to do
this, while we could just use the already provided perfectly suitable spi_mem_op
data structure for our needs? Especially seeing our controller supports the
operations like Tx-only and EEPROM-read specifically provided for the cases
of flash-device write/read operations. Isn't that a reason of claiming that it
supports mem-ops?
If we decided to implement the mem-ops in the driver (as it's done in this
patch), then the only thing we'd need to do is to enable the corresponding DW APB
SSI controller mode and push or push/pull spi_mem_op data on time. That's it.
No remapping, no data analyzing, no merging. Yes, the hardware doesn't provide
that much acceleration than normal Flash-capable SPI controllers, but still
it's better than handling standard transfers.
You'd say why remapping, analyzing and merging? Just use the normal SPI
synchronous Tx/Rx mode and push dummy zeros or ignore incoming data. The answer
is performance. Well, this might be good solution if the APB bus was fast enough.
If it's not, then we have to minimize the IO operations with Dw APB SSI
registers. This can be only done by using the EEPROM-read and Tx-only mode utilized.
Note, all the operations described above MUST be executed in the atomic context,
so the data push/pull algorithms would keep up with keeping the Tx FIFO
non-empty and preventing the Rx FIFO overflown by automatically incoming data.
If either for a reason of IRQ or another task preemption or due to the slow APB
bus we get the Tx FIFO emptied, then the native CS will be de-asserted. If for
the same reason we get the Rx FIFO overflown, then we'll loose data.
2) A slave is selected by GPIO CS.
Well, TBH in this case it's still more performant to use the Tx-only and
EEPROM-read modes for communications (because we need less APB bus activity),
but these modes mandate the IRQs disabling since data is automatically
received. Since in this case the problem with automatic CS de-assertion doesn't
exist (we can manually set and clear GPIO CS), it is safe to use the normal
synchronous SPI Tx/Rx mode and avoid IRQs disabling. Though in case if better
performance is required then mem-ops should be utilized.
Note using Tx-only and EEPROM-read operations is more performant than
normal synchronous SPI Tx-Rx mode because it causes less APB bus activity.
In addition we need less data analyzing and mapping for spi-mem operations.
In our case both of these factors are very important due to slow APB bus.
(See further comment for details of what I can port from this driver to the
generic DW APB SSI core.)
>
> > operation utilizes the Tx-only mode (just push data to the Tx FIFO, controller
> > discards all incoming data). See bs_set_cfg() for details.
>
> That's not super illuminating on this issue?
>
> > If GPIO CS is utilized then we fallback to the normal push-pull methods because
> > first it's safer this way, second it's still better than handling multiple SPI
> > transfers.
>
> > BTW The EEPROM/Tx-only modes are required to be utilized for the controller on
> > our SoC in order to support the SPI bus operations with highest frequencies.
> > Due to relatively slow APB bus performance we have to minimize MMIO operation
> > per a single byte read/write. This is another reason why we had to create a
> > dedicated driver for this controller.
>
> If the controller has support for TX only mode that seems like a good
> thing to have in the generic driver - for TX only transfers that's less
> bus I/O. The EEPROM mode potentially also, I'm less clear on what
> exactly it is but it sounds potentially useful for common cases with
> register operations. Perhaps other systems might have similarly slow
> buses and get noticable performance benefits from using these modes.
See my comments above. I gave up and will try to merge my driver into the
generic Dw APB SSI framework.
>
> > > > +static void bs_copy_from_map(void *to, void __iomem *from, size_t len)
> > > > +{
> > > > + size_t shift, chunk;
> > > > + u32 data;
>
> > > This feels like something that is likely to be suitable for a generic
> > > implementation? Indeed I'd kind of expect that the architecture
> > > memcpy_to/fromio() would try to copy aligned blocks since it's usually
> > > going to perform better (which I assume is why this function is doing
> > > it).
>
> > MIPS memcpy_to/fromio don't do this. They expect the MMIO space can be read in
> > a same way as normal memory space. It's our controller "feature", that MMIO can
> > be only accessible by lw/sw instructions. So I had no choice but to implement the
> > aligned read/write operations by myself here. AFAICS this won't be suitable for
> > the generic implementation due to the alignment restriction and the controller
> > setups, which are supposed to be performed before accessing the dirmap MMIO.
>
> You should document this in the driver so nobody comes along and does
> the refactoring as a cleanup, it looks like duplicated or redundant code.
Ok.
>
> > > This seems a bit much - we can validate that the message doesn't contain
> > > any delays (which is going to be the overwhelming majority of devices)
> > > or multiple transfers and reject just those transfers we can't support.
> > > Multiple transfers are an issue with this hardware but you could
> > > implement support in the core for coalescing them into single transfers,
> > > this isn't the only hardware with automatic chip select handling that
> > > can't cope with scatter/gather so it would be a useful thing to have.
>
> > As I said in the commit message to the binding this controller is nearly always
> > connected to an external SPI flash (I'd say always, because Baikal-T1 is fully
> > functional only when initially booted from an SPI flash). At least I don't know
> > any hardware using this interface differently (I've worked with all devices with
> > Baikal-T1 SoC on board). In current driver implementation the SPI-mem operations
> > covers the native CS case while the prepare_message()/transfer_one()/unprepare_message()
> > are used when GPIO-driven CS is available (due to the commit 05766050d5bd I had
> > to implement it). So I didn't want to over-complicate the driver just to support
> > some virtual hardware before it's really necessary.
>
> Aside from the issue of tempting fate in board designs this circles back
> to the open coding of the bits of the spi-mem stuff that aren't really
> offloaded by the hardware - the driver would look a lot more standard
> (and be closer to spi-dw I guess) if it only implemented the bits that
> are offloaded and this interface was available. Having the normal
> SPI message interface would not only support non-flash hardware, it'd
> also enable the use of more of the generic SPI flash code like other
> similar controllers.
See my comment above, why it's necessary to have the spi-mem implemented for
the case of native CS. If GPIO-driven CS is utilized, then generic (synchronous
SPI Tx/Rx mode) but poll-based (since there is no IRQ provided for our controller)
algorithm can be utilized. If native CS is only available, then the safest way
is to have the atomic context by disabling the interrupts. This can be easily
done for the spi-mem interface, but nearly impossible for the generic
spi_transfer_one_message()-based IO. The only alternative is to implement the
device-specific transfer_one_message() callback, analyze SPI transfers,
merge them up, execute in the atomic context. Needless to say, that such approach
is only applicable for the IRQless controllers. If IRQ is available for the
controller, then using Native CS is still unsafe.
To sum up what approaches are better in what configurations if IRQ-less DW APB
SSI controller is available:
1) Flash/spi-mem + Native CS => EEPROM-read/Tx-only + atomic context - disable IRQs.
2) Flash/spi-mem + GPIO CS => normal synchronous SPI Tx/Rx mode (currently this
will fallback to 4) because spi_mem_exec_op()
implementation, probably for good).
3) SPI msg + Native CS => reimplement transfer_one_message() + merge transfers
if possible otherwise use normal Tx+Rx mode + atomic
context - disabling IRQs during the whole message.
4) SPI msg + GPIO CS => normal synchronous SPI Tx/Rx mode.
For the Dw APB SSI controller with IRQ the 2) and 4) items are the same. 1) and
3) can't be safely implemented due to possible concurrent IRQs.
Item 4) is already available in the current spi-dw.c driver, although the poll-mode
has been recently removed (I'll have to get it back). From this patch I can port the
items 1) and 2) to the generic version of the DW APB SSI driver. I won't spend
my time for 3) because first I've already spent a lot of it on implementing this
driver, second I don't need such functionality on our platforms. If someone ever
needs it, I'll assist with an advice of how to do this.
So, what do you think?
>
> > > > +static int bs_transfer_one(struct spi_controller *ctrl, struct spi_device *spi,
> > > > + struct spi_transfer *xfer)
> > > > +{
> > > > + struct bt1_spi *bs = spi_controller_get_devdata(ctrl);
> > > > +
> > > > + bs_update_cfg(bs, xfer);
> > > > +
> > > > + if (bs->cfg.dfs <= 8)
> > > > + bs_pp_bytes(bs, xfer->tx_buf, xfer->rx_buf, xfer->len);
> > > > + else
> > > > + bs_pp_words(bs, xfer->tx_buf, xfer->rx_buf, xfer->len / 2);
> > >
> > > This will have issues with transfers with an odd number of bytes won't
> > > it?
>
> > No, it won't. Transfers with bits per word greater than 8 should have even
> > number of bytes seeing the len field is supposed to have the buffers length in
> > bytes:
>
> So dfs is bits per word? This is one of those things where the internal
> APIs make things harder to follow.
>
> > > Perhaps consider regmap_mmio?
>
> > For multiple reasons no. First of all I need a direct access to the DR register
> > and I need to do this as fast as possible due to relatively slow APB
> > bus. The same concern is regarding the controller configs setting. Secondly
> > everywhere in the driver I use the normal read/write methods and there is no
> > need in even a basic regmap-update function. So an additional abstraction like
> > regmap would be unnecessary complication. Thirdly the access to the registers
>
> That comment was more due to writing debug infrastructure than stuff
> like update_bits - the main reason regmap-mmio exists is for the debug
> and cache features. If the performance is too marginal to allow any
> overhead then fine. There's nothing stopping you combining regmap and
> non-regmap on the same device if you exclude the more sensitive
> registers from regmap with the access operations but it's not exactly
> nice.
>
> > > > + if (!ret) {
> > > > + mutex_lock(&bs->ctrl->io_mutex);
>
> > > Holding a mutex over the entire time that a file is open is not good,
> > > it's also not clear to me what this mutex is supposed to be protecting
> > > given that it's only referenced in these debugfs functions.
>
> > Hm, it's io_mutex protecting the SPI IO operation to be thread-safe. See:
> > spi_mem_access_start()/spi_mem_access_end();
> > __spi_pump_messages();
>
> > By locking the mutex here I make sure the DebugFS registers dump operation won't
> > interfere the IO operations like dirmap, which make the registers unavailable
> > for normal MMIO-based access.
>
> Oh, it's the SPI level mutex... that is a bit icky, and it does let
> userspace code block the bus fairly easily which could be problematic
> but I guess it's debugfs so meh.
Ok.
>
> > > > + writel(BC_CSR_SPI_RDA, bs->regs + BC_CSR);
>
> > > Whatever this write is doing we never seem to undo it?
>
> > Here I switch on the DW APB SSI registers to be available for normal
> > readl/writel accesses. It's not a problem to leave the mode on, since
> > bs_set_cfg() will do a proper config anyway.
>
> A comment would help here, the fact that it's not undone looks like a
> bug.
Ok.
-Sergey
^ permalink raw reply
* Re: [PATCH v7 7/7] input: joystick: Add ADC attached joystick driver.
From: kbuild test robot @ 2020-05-17 23:19 UTC (permalink / raw)
To: Artur Rojek, Dmitry Torokhov, Rob Herring, Mark Rutland,
Jonathan Cameron, Paul Cercueil, Andy Shevchenko
Cc: kbuild-all, Heiko Stuebner, Ezequiel Garcia, linux-input,
devicetree, linux-iio, linux-kernel, Artur Rojek
In-Reply-To: <20200517194904.34758-7-contact@artur-rojek.eu>
[-- Attachment #1: Type: text/plain, Size: 3001 bytes --]
Hi Artur,
Thank you for the patch! Perhaps something to improve:
[auto build test WARNING on iio/togreg]
[also build test WARNING on input/next robh/for-next v5.7-rc5 next-20200515]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system. BTW, we also suggest to use '--base' option to specify the
base tree in git format-patch, please see https://stackoverflow.com/a/37406982]
url: https://github.com/0day-ci/linux/commits/Artur-Rojek/dt-bindings-iio-adc-Convert-ingenic-adc-docs-to-YAML/20200518-035120
base: https://git.kernel.org/pub/scm/linux/kernel/git/jic23/iio.git togreg
config: i386-allyesconfig (attached as .config)
reproduce:
# apt-get install sparse
# sparse version: v0.6.1-193-gb8fad4bc-dirty
# save the attached .config to linux build tree
make C=1 ARCH=i386 CF='-fdiagnostic-prefix -D__CHECK_ENDIAN__'
If you fix the issue, kindly add following tag as appropriate
Reported-by: kbuild test robot <lkp@intel.com>
sparse warnings: (new ones prefixed by >>)
>> drivers/input/joystick/adc-joystick.c:49:39: sparse: sparse: cast to restricted __be16
>> drivers/input/joystick/adc-joystick.c:49:39: sparse: sparse: cast to restricted __be16
>> drivers/input/joystick/adc-joystick.c:49:39: sparse: sparse: cast to restricted __be16
>> drivers/input/joystick/adc-joystick.c:49:39: sparse: sparse: cast to restricted __be16
>> drivers/input/joystick/adc-joystick.c:51:39: sparse: sparse: cast to restricted __le16
vim +49 drivers/input/joystick/adc-joystick.c
28
29 static int adc_joystick_handle(const void *data, void *private)
30 {
31 struct adc_joystick *joy = private;
32 enum iio_endian endianness;
33 int bytes, msb, val, i;
34 bool sign;
35
36 bytes = joy->chans[0].channel->scan_type.storagebits >> 3;
37
38 for (i = 0; i < joy->num_chans; ++i) {
39 endianness = joy->chans[i].channel->scan_type.endianness;
40 msb = joy->chans[i].channel->scan_type.realbits - 1;
41 sign = (tolower(joy->chans[i].channel->scan_type.sign) == 's');
42
43 switch (bytes) {
44 case 1:
45 val = ((const u8 *)data)[i];
46 break;
47 case 2:
48 if (endianness == IIO_BE)
> 49 val = be16_to_cpu(((const u16 *)data)[i]);
50 else if (endianness == IIO_LE)
> 51 val = le16_to_cpu(((const u16 *)data)[i]);
52 else /* IIO_CPU */
53 val = ((const u16 *)data)[i];
54 break;
55 default:
56 return -EINVAL;
57 }
58
59 val >>= joy->chans[i].channel->scan_type.shift;
60 if (sign)
61 val = sign_extend32(val, msb);
62 else
63 val &= GENMASK(msb, 0);
64 input_report_abs(joy->input, joy->axes[i].code, val);
65 }
66
67 input_sync(joy->input);
68
69 return 0;
70 }
71
---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-all@lists.01.org
[-- Attachment #2: .config.gz --]
[-- Type: application/gzip, Size: 72481 bytes --]
^ permalink raw reply
* Re: [PATCH v1 8/9] arm64: dts: actions: Add MMC controller support for S700
From: André Przywara @ 2020-05-17 21:30 UTC (permalink / raw)
To: Amit Tomer
Cc: Andreas Färber, Manivannan Sadhasivam, Rob Herring,
cristian.ciocaltea, linux-arm-kernel, linux-actions, devicetree
In-Reply-To: <CABHD4K-OaQ4Vf_+dg9FMR97ocLeUkDswyEnChPV=H=VcbyUhkg@mail.gmail.com>
On 17/05/2020 18:12, Amit Tomer wrote:
>> I don't understand what this has to do with the driver, but I asked
>> above to also change the binding, allowing this compatible string
>> combination.
> if we add these two strings "actions,s700-mmc", "actions,owl-mmc" to dts file
> and leave the driver as it. Wouldn't this be mismatch(as driver only
> has "actions,owl-mmc"
> and DTS has two strings).
>
> Shouldn't that be concerned about ?
I recommend reading the DT spec, chapter 2.3.1 "compatible":
https://github.com/devicetree-org/devicetree-specification/releases/download/v0.3/devicetree-specification-v0.3.pdf
Cheers,
Andre
^ permalink raw reply
* Re: [PATCH 2/2] input: misc: Add support for Azoteq IQS269A
From: Jeff LaBundy @ 2020-05-17 21:21 UTC (permalink / raw)
To: Dmitry Torokhov; +Cc: robh+dt, linux-input, devicetree
In-Reply-To: <20200420170930.GO166864@dtor-ws>
Hi Dmitry,
On Mon, Apr 20, 2020 at 10:09:30AM -0700, Dmitry Torokhov wrote:
> On Sun, Apr 19, 2020 at 06:47:48PM -0500, Jeff LaBundy wrote:
> > This patch adds support for the Azoteq IQS269A capacitive touch
> > controller.
> >
> > Signed-off-by: Jeff LaBundy <jeff@labundy.com>
>
> This looks good, so just need to get Rob's take on the binding...
Thank you for the quick turn-around. Last week Rob reviewed the
binding for v2 [1]; the driver has not changed since your first
review. Would you consider taking v2 for this cycle?
>
> Thanks.
>
> --
> Dmitry
[1] https://patchwork.kernel.org/patch/11522939/
Kind regards,
Jeff LaBundy
^ permalink raw reply
* Re: [PATCH 17/17] ARM: dts: r8a7742: Add RWDT node
From: Wolfram Sang @ 2020-05-17 21:08 UTC (permalink / raw)
To: Lad Prabhakar
Cc: Geert Uytterhoeven, Jens Axboe, Rob Herring, Wolfram Sang,
Ulf Hansson, Sergei Shtylyov, David S. Miller, Wim Van Sebroeck,
Guenter Roeck, linux-ide, devicetree, linux-kernel, linux-i2c,
linux-mmc, netdev, linux-renesas-soc, linux-watchdog, Prabhakar
In-Reply-To: <1589555337-5498-18-git-send-email-prabhakar.mahadev-lad.rj@bp.renesas.com>
[-- Attachment #1: Type: text/plain, Size: 660 bytes --]
On Fri, May 15, 2020 at 04:08:57PM +0100, Lad Prabhakar wrote:
> Add a device node for the Watchdog Timer (RWDT) controller on the Renesas
> RZ/G1H (r8a7742) SoC.
>
> Signed-off-by: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com>
> Reviewed-by: Marian-Cristian Rotariu <marian-cristian.rotariu.rb@bp.renesas.com>
The DTS change looks fine, I checked it against similar SoCs (like the
previous patched). So, for that:
Reviewed-by: Wolfram Sang <wsa+renesas@sang-engineering.com>
However, just to make sure, have you checked the WDT (especially reboot)
with SMP and multiple CPU cores enabled? Some early Gen2 SoCs had issues
there.
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply
* Re: [PATCH 16/17] dt-bindings: watchdog: renesas,wdt: Document r8a7742 support
From: Wolfram Sang @ 2020-05-17 21:03 UTC (permalink / raw)
To: Lad Prabhakar
Cc: Geert Uytterhoeven, Jens Axboe, Rob Herring, Wolfram Sang,
Ulf Hansson, Sergei Shtylyov, David S. Miller, Wim Van Sebroeck,
Guenter Roeck, linux-ide, devicetree, linux-kernel, linux-i2c,
linux-mmc, netdev, linux-renesas-soc, linux-watchdog, Prabhakar
In-Reply-To: <1589555337-5498-17-git-send-email-prabhakar.mahadev-lad.rj@bp.renesas.com>
[-- Attachment #1: Type: text/plain, Size: 408 bytes --]
On Fri, May 15, 2020 at 04:08:56PM +0100, Lad Prabhakar wrote:
> RZ/G1H (R8A7742) watchdog implementation is compatible with R-Car Gen2,
> therefore add relevant documentation.
>
> Signed-off-by: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com>
> Reviewed-by: Marian-Cristian Rotariu <marian-cristian.rotariu.rb@bp.renesas.com>
Reviewed-by: Wolfram Sang <wsa+renesas@sang-engineering.com>
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply
* Re: [PATCH 15/17] ARM: dts: r8a7742: Add APMU nodes
From: Wolfram Sang @ 2020-05-17 21:03 UTC (permalink / raw)
To: Lad Prabhakar
Cc: Geert Uytterhoeven, Jens Axboe, Rob Herring, Wolfram Sang,
Ulf Hansson, Sergei Shtylyov, David S. Miller, Wim Van Sebroeck,
Guenter Roeck, linux-ide, devicetree, linux-kernel, linux-i2c,
linux-mmc, netdev, linux-renesas-soc, linux-watchdog, Prabhakar
In-Reply-To: <1589555337-5498-16-git-send-email-prabhakar.mahadev-lad.rj@bp.renesas.com>
[-- Attachment #1: Type: text/plain, Size: 444 bytes --]
On Fri, May 15, 2020 at 04:08:55PM +0100, Lad Prabhakar wrote:
> Add DT nodes for the Advanced Power Management Units (APMU), and use the
> enable-method to point out that the APMU should be used for SMP support.
>
> Signed-off-by: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com>
> Reviewed-by: Marian-Cristian Rotariu <marian-cristian.rotariu.rb@bp.renesas.com>
Reviewed-by: Wolfram Sang <wsa+renesas@sang-engineering.com>
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply
* Re: [PATCH 14/17] dt-bindings: power: renesas,apmu: Document r8a7742 support
From: Wolfram Sang @ 2020-05-17 21:01 UTC (permalink / raw)
To: Lad Prabhakar
Cc: Geert Uytterhoeven, Jens Axboe, Rob Herring, Wolfram Sang,
Ulf Hansson, Sergei Shtylyov, David S. Miller, Wim Van Sebroeck,
Guenter Roeck, linux-ide, devicetree, linux-kernel, linux-i2c,
linux-mmc, netdev, linux-renesas-soc, linux-watchdog, Prabhakar
In-Reply-To: <1589555337-5498-15-git-send-email-prabhakar.mahadev-lad.rj@bp.renesas.com>
[-- Attachment #1: Type: text/plain, Size: 374 bytes --]
On Fri, May 15, 2020 at 04:08:54PM +0100, Lad Prabhakar wrote:
> Document APMU and SMP enable method for RZ/G1H (also known as r8a7742)
> SoC.
>
> Signed-off-by: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com>
> Reviewed-by: Marian-Cristian Rotariu <marian-cristian.rotariu.rb@bp.renesas.com>
Reviewed-by: Wolfram Sang <wsa+renesas@sang-engineering.com>
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply
* Re: [PATCH 13/17] ARM: dts: r8a7742: Add Ether support
From: Wolfram Sang @ 2020-05-17 21:01 UTC (permalink / raw)
To: Lad Prabhakar
Cc: Geert Uytterhoeven, Jens Axboe, Rob Herring, Wolfram Sang,
Ulf Hansson, Sergei Shtylyov, David S. Miller, Wim Van Sebroeck,
Guenter Roeck, linux-ide, devicetree, linux-kernel, linux-i2c,
linux-mmc, netdev, linux-renesas-soc, linux-watchdog, Prabhakar
In-Reply-To: <1589555337-5498-14-git-send-email-prabhakar.mahadev-lad.rj@bp.renesas.com>
[-- Attachment #1: Type: text/plain, Size: 353 bytes --]
On Fri, May 15, 2020 at 04:08:53PM +0100, Lad Prabhakar wrote:
> Define the generic R8A7742 part of the Ether device node.
>
> Signed-off-by: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com>
> Reviewed-by: Marian-Cristian Rotariu <marian-cristian.rotariu.rb@bp.renesas.com>
Reviewed-by: Wolfram Sang <wsa+renesas@sang-engineering.com>
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply
* Re: [PATCH 12/17] ARM: dts: r8a7742: Add Ethernet AVB support
From: Wolfram Sang @ 2020-05-17 21:00 UTC (permalink / raw)
To: Lad Prabhakar
Cc: Geert Uytterhoeven, Jens Axboe, Rob Herring, Wolfram Sang,
Ulf Hansson, Sergei Shtylyov, David S. Miller, Wim Van Sebroeck,
Guenter Roeck, linux-ide, devicetree, linux-kernel, linux-i2c,
linux-mmc, netdev, linux-renesas-soc, linux-watchdog, Prabhakar
In-Reply-To: <1589555337-5498-13-git-send-email-prabhakar.mahadev-lad.rj@bp.renesas.com>
[-- Attachment #1: Type: text/plain, Size: 337 bytes --]
On Fri, May 15, 2020 at 04:08:52PM +0100, Lad Prabhakar wrote:
> Add Ethernet AVB support for R8A7742 SoC.
>
> Signed-off-by: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com>
> Reviewed-by: Marian-Cristian Rotariu <marian-cristian.rotariu.rb@bp.renesas.com>
Reviewed-by: Wolfram Sang <wsa+renesas@sang-engineering.com>
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply
* Re: [PATCH 11/17] dt-bindings: net: renesas,ether: Document R8A7742 SoC
From: Wolfram Sang @ 2020-05-17 20:59 UTC (permalink / raw)
To: Lad Prabhakar
Cc: Geert Uytterhoeven, Jens Axboe, Rob Herring, Wolfram Sang,
Ulf Hansson, Sergei Shtylyov, David S. Miller, Wim Van Sebroeck,
Guenter Roeck, linux-ide, devicetree, linux-kernel, linux-i2c,
linux-mmc, netdev, linux-renesas-soc, linux-watchdog, Prabhakar
In-Reply-To: <1589555337-5498-12-git-send-email-prabhakar.mahadev-lad.rj@bp.renesas.com>
[-- Attachment #1: Type: text/plain, Size: 335 bytes --]
On Fri, May 15, 2020 at 04:08:51PM +0100, Lad Prabhakar wrote:
> Document RZ/G1H (R8A7742) SoC bindings.
>
> Signed-off-by: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com>
> Reviewed-by: Marian-Cristian Rotariu <marian-cristian.rotariu.rb@bp.renesas.com>
Reviewed-by: Wolfram Sang <wsa+renesas@sang-engineering.com>
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply
* Re: [PATCH 10/17] dt-bindings: net: renesas,ravb: Add support for r8a7742 SoC
From: Wolfram Sang @ 2020-05-17 20:58 UTC (permalink / raw)
To: Lad Prabhakar
Cc: Geert Uytterhoeven, Jens Axboe, Rob Herring, Wolfram Sang,
Ulf Hansson, Sergei Shtylyov, David S. Miller, Wim Van Sebroeck,
Guenter Roeck, linux-ide, devicetree, linux-kernel, linux-i2c,
linux-mmc, netdev, linux-renesas-soc, linux-watchdog, Prabhakar
In-Reply-To: <1589555337-5498-11-git-send-email-prabhakar.mahadev-lad.rj@bp.renesas.com>
[-- Attachment #1: Type: text/plain, Size: 335 bytes --]
On Fri, May 15, 2020 at 04:08:50PM +0100, Lad Prabhakar wrote:
> Document RZ/G1H (R8A7742) SoC bindings.
>
> Signed-off-by: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com>
> Reviewed-by: Marian-Cristian Rotariu <marian-cristian.rotariu.rb@bp.renesas.com>
Reviewed-by: Wolfram Sang <wsa+renesas@sang-engineering.com>
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply
* Re: [PATCH 09/17] ARM: dts: r8a7742: Add sata nodes
From: Wolfram Sang @ 2020-05-17 20:57 UTC (permalink / raw)
To: Lad Prabhakar
Cc: Geert Uytterhoeven, Jens Axboe, Rob Herring, Wolfram Sang,
Ulf Hansson, Sergei Shtylyov, David S. Miller, Wim Van Sebroeck,
Guenter Roeck, linux-ide, devicetree, linux-kernel, linux-i2c,
linux-mmc, netdev, linux-renesas-soc, linux-watchdog, Prabhakar
In-Reply-To: <1589555337-5498-10-git-send-email-prabhakar.mahadev-lad.rj@bp.renesas.com>
[-- Attachment #1: Type: text/plain, Size: 350 bytes --]
On Fri, May 15, 2020 at 04:08:49PM +0100, Lad Prabhakar wrote:
> Add the sata devices nodes to the R8A7742 device tree.
>
> Signed-off-by: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com>
> Reviewed-by: Marian-Cristian Rotariu <marian-cristian.rotariu.rb@bp.renesas.com>
Reviewed-by: Wolfram Sang <wsa+renesas@sang-engineering.com>
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply
* Re: [PATCH 08/17] dt-bindings: ata: renesas,rcar-sata: Add r8a7742 support
From: Wolfram Sang @ 2020-05-17 20:55 UTC (permalink / raw)
To: Lad Prabhakar
Cc: Geert Uytterhoeven, Jens Axboe, Rob Herring, Wolfram Sang,
Ulf Hansson, Sergei Shtylyov, David S. Miller, Wim Van Sebroeck,
Guenter Roeck, linux-ide, devicetree, linux-kernel, linux-i2c,
linux-mmc, netdev, linux-renesas-soc, linux-watchdog, Prabhakar
In-Reply-To: <1589555337-5498-9-git-send-email-prabhakar.mahadev-lad.rj@bp.renesas.com>
[-- Attachment #1: Type: text/plain, Size: 384 bytes --]
On Fri, May 15, 2020 at 04:08:48PM +0100, Lad Prabhakar wrote:
> Document SATA support for the RZ/G1H, which is compatible with
> R-Car Gen2 SoC family.
>
> Signed-off-by: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com>
> Reviewed-by: Marian-Cristian Rotariu <marian-cristian.rotariu.rb@bp.renesas.com>
Reviewed-by: Wolfram Sang <wsa+renesas@sang-engineering.com>
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply
* Re: [PATCH 07/17] ARM: dts: r8a7742: Add MMC0 node
From: Wolfram Sang @ 2020-05-17 20:54 UTC (permalink / raw)
To: Lad Prabhakar
Cc: Geert Uytterhoeven, Jens Axboe, Rob Herring, Wolfram Sang,
Ulf Hansson, Sergei Shtylyov, David S. Miller, Wim Van Sebroeck,
Guenter Roeck, linux-ide, devicetree, linux-kernel, linux-i2c,
linux-mmc, netdev, linux-renesas-soc, linux-watchdog, Prabhakar
In-Reply-To: <1589555337-5498-8-git-send-email-prabhakar.mahadev-lad.rj@bp.renesas.com>
[-- Attachment #1: Type: text/plain, Size: 349 bytes --]
On Fri, May 15, 2020 at 04:08:47PM +0100, Lad Prabhakar wrote:
> Describe MMC0 device node in the R8A7742 device tree.
>
> Signed-off-by: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com>
> Reviewed-by: Marian-Cristian Rotariu <marian-cristian.rotariu.rb@bp.renesas.com>
Reviewed-by: Wolfram Sang <wsa+renesas@sang-engineering.com>
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply
* Re: [PATCH 06/17] ARM: dts: r8a7742: Add SDHI nodes
From: Wolfram Sang @ 2020-05-17 20:53 UTC (permalink / raw)
To: Lad Prabhakar
Cc: Geert Uytterhoeven, Jens Axboe, Rob Herring, Wolfram Sang,
Ulf Hansson, Sergei Shtylyov, David S. Miller, Wim Van Sebroeck,
Guenter Roeck, linux-ide, devicetree, linux-kernel, linux-i2c,
linux-mmc, netdev, linux-renesas-soc, linux-watchdog, Prabhakar
In-Reply-To: <1589555337-5498-7-git-send-email-prabhakar.mahadev-lad.rj@bp.renesas.com>
[-- Attachment #1: Type: text/plain, Size: 350 bytes --]
On Fri, May 15, 2020 at 04:08:46PM +0100, Lad Prabhakar wrote:
> Add the SDHI devices nodes to the R8A7742 device tree.
>
> Signed-off-by: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com>
> Reviewed-by: Marian-Cristian Rotariu <marian-cristian.rotariu.rb@bp.renesas.com>
Reviewed-by: Wolfram Sang <wsa+renesas@sang-engineering.com>
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply
* Re: [PATCH 4/4] sc16is7xx: Use threaded IRQ
From: Daniel Mack @ 2020-05-17 20:44 UTC (permalink / raw)
To: Maarten Brock
Cc: devicetree, linux-serial, gregkh, robh+dt, jslaby, pascal.huerst,
linux-serial-owner
In-Reply-To: <61fdcf12976c924fd86c5203aba673a7@vanmierlo.com>
Hi Maarten,
Thanks for your review!
On 5/9/20 2:55 PM, Maarten Brock wrote:
> On 2020-05-08 16:37, Daniel Mack wrote:
>> Use a threaded IRQ handler to get rid of the irq_work kthread.
>> This also allows for the driver to use interrupts generated by
>> a threaded controller.
>>
>> Signed-off-by: Daniel Mack <daniel@zonque.org>
>> ---
>> drivers/tty/serial/sc16is7xx.c | 18 +++++-------------
>> 1 file changed, 5 insertions(+), 13 deletions(-)
>>
>> diff --git a/drivers/tty/serial/sc16is7xx.c
>> b/drivers/tty/serial/sc16is7xx.c
>> @@ -1317,8 +1308,9 @@ static int sc16is7xx_probe(struct device *dev,
>> }
>>
>> /* Setup interrupt */
>> - ret = devm_request_irq(dev, irq, sc16is7xx_irq,
>> - IRQF_TRIGGER_FALLING, dev_name(dev), s);
>> + ret = devm_request_threaded_irq(dev, irq, NULL, sc16is7xx_irq,
>> + IRQF_TRIGGER_FALLING | IRQF_ONESHOT,
>> + dev_name(dev), s);
>> if (!ret)
>> return 0;
>
> Since UART0 is first handled completely in the for loop before UART1 is
> handled, a new interrupt may arise on UART0 while UART1 is being handled.
The code in the interrupt handling function loops forever until there is
no more interrupt bits pending. So if there is a new IRQ happening for
UART0 while UART1 is being served, it will be handled in the same loop.
And just to be sure I understand correctly: this is unrelated to the
switch to threaded IRQs, right? Falling edge triggers were always used
for pdata probed devices.
> The result is a missed interrupt since the IRQ line might not *FALL* again.
It doesn't have to. We only exit the interrupt handler when there is
nothing left to do, at which point the IRQ line ist back high. So it
will fall again in case of new events.
> Therefor I suggest to change IRQF_TRIGGER_FALLING to IRQF_TRIGGER_LOW. This
> way the thread will be retriggered after IRQ_HANDLED is returned.
This doesn't work in my setup unfortunately, as the interrupt controller
is incapable of handling level IRQs.
Thanks,
Daniel
^ 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