* [PATCH v7 2/3] ARM: dts: add TOPEET itop elite based board
From: Randy Li @ 2016-09-18 14:01 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1474207279-9662-1-git-send-email-ayaka@soulik.info>
The TOPEET itop exynos 4412 have three versions base board. The
Elite version is the cheap one without too much peripheral devices
on it.
Currently supported are serial console, wired networking(USB),
USB OTG in peripheral mode, USB host, SD storage, GPIO buttons,
PWM beeper, ADC and LEDs. The WM8960 analog audio codec is also
enabled.
The FIMC is not used for camera currently, I enabled it just for a
colorspace convertor.
Signed-off-by: Randy Li <ayaka@soulik.info>
---
.../bindings/arm/samsung/samsung-boards.txt | 3 +
arch/arm/boot/dts/Makefile | 1 +
arch/arm/boot/dts/exynos4412-itop-elite.dts | 240 +++++++++++++++++++++
3 files changed, 244 insertions(+)
create mode 100644 arch/arm/boot/dts/exynos4412-itop-elite.dts
diff --git a/Documentation/devicetree/bindings/arm/samsung/samsung-boards.txt b/Documentation/devicetree/bindings/arm/samsung/samsung-boards.txt
index 0ea7f14..5160fa5 100644
--- a/Documentation/devicetree/bindings/arm/samsung/samsung-boards.txt
+++ b/Documentation/devicetree/bindings/arm/samsung/samsung-boards.txt
@@ -22,6 +22,9 @@ Required root node properties:
* FriendlyARM
- "friendlyarm,tiny4412" - for Exynos4412-based FriendlyARM
TINY4412 board.
+ * TOPEET
+ - "topeet,itop4412-elite" - for Exynos4412-based TOPEET
+ Elite base board.
* Google
- "google,pi" - for Exynos5800-based Google Peach Pi
diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index befcd26..d709f74 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -136,6 +136,7 @@ dtb-$(CONFIG_ARCH_EXYNOS4) += \
exynos4210-smdkv310.dtb \
exynos4210-trats.dtb \
exynos4210-universal_c210.dtb \
+ exynos4412-itop-elite.dtb \
exynos4412-odroidu3.dtb \
exynos4412-odroidx.dtb \
exynos4412-odroidx2.dtb \
diff --git a/arch/arm/boot/dts/exynos4412-itop-elite.dts b/arch/arm/boot/dts/exynos4412-itop-elite.dts
new file mode 100644
index 0000000..b08705e
--- /dev/null
+++ b/arch/arm/boot/dts/exynos4412-itop-elite.dts
@@ -0,0 +1,240 @@
+/*
+ * TOPEET's Exynos4412 based itop board device tree source
+ *
+ * Copyright (c) 2016 SUMOMO Computer Association
+ * https://www.sumomo.mobi
+ * Randy Li <ayaka@soulik.info>
+ *
+ * Device tree source file for TOPEET iTop Exynos 4412 core board
+ * which is based on Samsung's Exynos4412 SoC.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+*/
+
+/dts-v1/;
+#include <dt-bindings/pwm/pwm.h>
+#include <dt-bindings/sound/samsung-i2s.h>
+#include "exynos4412-itop-scp-core.dtsi"
+
+/ {
+ model = "TOPEET iTop 4412 Elite board based on Exynos4412";
+ compatible = "topeet,itop4412-elite", "samsung,exynos4412", "samsung,exynos4";
+
+ chosen {
+ bootargs = "root=/dev/mmcblk0p2 rw rootfstype=ext4 rootdelay=1 rootwait";
+ stdout-path = "serial2:115200n8";
+ };
+
+ leds {
+ compatible = "gpio-leds";
+
+ led2 {
+ label = "red:system";
+ gpios = <&gpx1 0 GPIO_ACTIVE_HIGH>;
+ default-state = "off";
+ linux,default-trigger = "heartbeat";
+ };
+
+ led3 {
+ label = "red:user";
+ gpios = <&gpk1 1 GPIO_ACTIVE_HIGH>;
+ default-state = "off";
+ };
+ };
+
+ gpio-keys {
+ compatible = "gpio-keys";
+
+ home {
+ label = "GPIO Key Home";
+ linux,code = <KEY_HOME>;
+ gpios = <&gpx1 1 GPIO_ACTIVE_LOW>;
+ };
+
+ back {
+ label = "GPIO Key Back";
+ linux,code = <KEY_BACK>;
+ gpios = <&gpx1 2 GPIO_ACTIVE_LOW>;
+ };
+
+ sleep {
+ label = "GPIO Key Sleep";
+ linux,code = <KEY_POWER>;
+ gpios = <&gpx3 3 GPIO_ACTIVE_LOW>;
+ };
+
+ vol-up {
+ label = "GPIO Key Vol+";
+ linux,code = <KEY_UP>;
+ gpios = <&gpx2 1 GPIO_ACTIVE_LOW>;
+ };
+
+ vol-down {
+ label = "GPIO Key Vol-";
+ linux,code = <KEY_DOWN>;
+ gpios = <&gpx2 0 GPIO_ACTIVE_LOW>;
+ };
+ };
+
+ sound {
+ compatible = "simple-audio-card";
+ simple-audio-card,name = "wm-sound";
+
+ assigned-clocks = <&clock_audss EXYNOS_MOUT_AUDSS>,
+ <&clock_audss EXYNOS_MOUT_I2S>,
+ <&clock_audss EXYNOS_DOUT_SRP>,
+ <&clock_audss EXYNOS_DOUT_AUD_BUS>;
+ assigned-clock-parents = <&clock CLK_FOUT_EPLL>,
+ <&clock_audss EXYNOS_MOUT_AUDSS>;
+ assigned-clock-rates = <0>,
+ <0>,
+ <112896000>,
+ <11289600>;
+
+ simple-audio-card,format = "i2s";
+ simple-audio-card,bitclock-master = <&link0_codec>;
+ simple-audio-card,frame-master = <&link0_codec>;
+
+ simple-audio-card,widgets =
+ "Microphone", "Mic Jack",
+ "Line", "Line In",
+ "Line", "Line Out",
+ "Speaker", "Speaker",
+ "Headphone", "Headphone Jack";
+ simple-audio-card,routing =
+ "Headphone Jack", "HP_L",
+ "Headphone Jack", "HP_R",
+ "Speaker", "SPK_LP",
+ "Speaker", "SPK_LN",
+ "Speaker", "SPK_RP",
+ "Speaker", "SPK_RN",
+ "LINPUT1", "Mic Jack",
+ "LINPUT3", "Mic Jack",
+ "RINPUT1", "Mic Jack",
+ "RINPUT2", "Mic Jack";
+
+ simple-audio-card,cpu {
+ sound-dai = <&i2s0 0>;
+ };
+
+ link0_codec: simple-audio-card,codec {
+ sound-dai = <&codec>;
+ clocks = <&i2s0 CLK_I2S_CDCLK>;
+ system-clock-frequency = <11289600>;
+ };
+ };
+
+ beep {
+ compatible = "pwm-beeper";
+ pwms = <&pwm 0 4000000 PWM_POLARITY_INVERTED>;
+ };
+
+ camera: camera {
+ pinctrl-0 = <&cam_port_a_clk_active>;
+ pinctrl-names = "default";
+ status = "okay";
+ assigned-clocks = <&clock CLK_MOUT_CAM0>;
+ assigned-clock-parents = <&clock CLK_XUSBXTI>;
+ };
+};
+
+&adc {
+ vdd-supply = <&ldo3_reg>;
+ status = "okay";
+};
+
+&ehci {
+ status = "okay";
+ /* In order to reset USB ethernet */
+ samsung,vbus-gpio = <&gpc0 1 GPIO_ACTIVE_HIGH>;
+
+ port at 0 {
+ status = "okay";
+ };
+
+ port at 2 {
+ status = "okay";
+ };
+};
+
+&exynos_usbphy {
+ status = "okay";
+};
+
+&fimc_0 {
+ status = "okay";
+ assigned-clocks = <&clock CLK_MOUT_FIMC0>,
+ <&clock CLK_SCLK_FIMC0>;
+ assigned-clock-parents = <&clock CLK_MOUT_MPLL_USER_T>;
+ assigned-clock-rates = <0>, <176000000>;
+};
+
+&hsotg {
+ dr_mode = "peripheral";
+ status = "okay";
+};
+
+&i2c_4 {
+ samsung,i2c-sda-delay = <100>;
+ samsung,i2c-slave-addr = <0x10>;
+ samsung,i2c-max-bus-freq = <100000>;
+ pinctrl-0 = <&i2c4_bus>;
+ pinctrl-names = "default";
+ status = "okay";
+
+ codec: wm8960 at 1a {
+ compatible = "wlf,wm8960";
+ reg = <0x1a>;
+ clocks = <&pmu_system_controller 0>;
+ clock-names = "MCLK1";
+ wlf,shared-lrclk;
+ #sound-dai-cells = <0>;
+ };
+};
+
+&i2s0 {
+ pinctrl-0 = <&i2s0_bus>;
+ pinctrl-names = "default";
+ status = "okay";
+ clocks = <&clock_audss EXYNOS_I2S_BUS>,
+ <&clock_audss EXYNOS_DOUT_AUD_BUS>,
+ <&clock_audss EXYNOS_SCLK_I2S>;
+ clock-names = "iis", "i2s_opclk0", "i2s_opclk1";
+};
+
+&pinctrl_1 {
+ ether-reset {
+ samsung,pins = "gpc0-1";
+ samsung,pin-function = <1>;
+ samsung,pin-pud = <0>;
+ samsung,pin-drv = <0>;
+ };
+};
+
+&pwm {
+ status = "okay";
+ pinctrl-0 = <&pwm0_out>;
+ pinctrl-names = "default";
+ samsung,pwm-outputs = <0>;
+};
+
+&sdhci_2 {
+ bus-width = <4>;
+ pinctrl-0 = <&sd2_clk &sd2_cmd &sd2_bus4>;
+ pinctrl-names = "default";
+ cd-gpio = <&gpx0 7 GPIO_ACTIVE_LOW>;
+ cap-sd-highspeed;
+ vmmc-supply = <&ldo23_reg>;
+ vqmmc-supply = <&ldo17_reg>;
+ status = "okay";
+};
+
+&serial_1 {
+ status = "okay";
+};
+
+&serial_2 {
+ status = "okay";
+};
--
2.7.4
^ permalink raw reply related
* [PATCH v7 1/3] ARM: dts: Add TOPEET itop core board SCP package version
From: Randy Li @ 2016-09-18 14:01 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1474207279-9662-1-git-send-email-ayaka@soulik.info>
The TOPEET itop is a samsung exnynos 4412 core board, which have
two package versions. This patch add the support for SCP version.
Currently supported are USB3503A HSIC, USB OTG, eMMC, rtc and
PMIC. The future features are in the based board. Also MFC and
watchdog have been enabled.
Signed-off-by: Randy Li <ayaka@soulik.info>
---
arch/arm/boot/dts/exynos4412-itop-scp-core.dtsi | 491 ++++++++++++++++++++++++
1 file changed, 491 insertions(+)
create mode 100644 arch/arm/boot/dts/exynos4412-itop-scp-core.dtsi
diff --git a/arch/arm/boot/dts/exynos4412-itop-scp-core.dtsi b/arch/arm/boot/dts/exynos4412-itop-scp-core.dtsi
new file mode 100644
index 0000000..1b780cf
--- /dev/null
+++ b/arch/arm/boot/dts/exynos4412-itop-scp-core.dtsi
@@ -0,0 +1,491 @@
+/*
+ * TOPEET's Exynos4412 based itop board device tree source
+ *
+ * Copyright (c) 2016 SUMOMO Computer Association
+ * https://www.sumomo.mobi
+ * Randy Li <ayaka@soulik.info>
+ *
+ * Device tree source file for TOPEET iTop Exynos 4412 SCP package core
+ * board which is based on Samsung's Exynos4412 SoC.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+*/
+
+#include <dt-bindings/gpio/gpio.h>
+#include <dt-bindings/input/input.h>
+#include <dt-bindings/clock/samsung,s2mps11.h>
+#include "exynos4412.dtsi"
+#include "exynos4412-ppmu-common.dtsi"
+#include "exynos-mfc-reserved-memory.dtsi"
+
+/ {
+ memory at 40000000 {
+ device_type = "memory";
+ reg = <0x40000000 0x40000000>;
+ };
+
+ firmware at 0203F000 {
+ compatible = "samsung,secure-firmware";
+ reg = <0x0203F000 0x1000>;
+ };
+
+ fixed-rate-clocks {
+ xxti {
+ compatible = "samsung,clock-xxti";
+ clock-frequency = <0>;
+ };
+
+ xusbxti {
+ compatible = "samsung,clock-xusbxti";
+ clock-frequency = <24000000>;
+ };
+ };
+
+ thermal-zones {
+ cpu_thermal: cpu-thermal {
+ cooling-maps {
+ map0 {
+ /* Corresponds to 800MHz at freq_table */
+ cooling-device = <&cpu0 7 7>;
+ };
+ map1 {
+ /* Corresponds to 200MHz at freq_table */
+ cooling-device = <&cpu0 13 13>;
+ };
+ };
+ };
+ };
+
+ usb-hub {
+ compatible = "smsc,usb3503a";
+ reset-gpios = <&gpm2 4 GPIO_ACTIVE_LOW>;
+ connect-gpios = <&gpm3 3 GPIO_ACTIVE_HIGH>;
+ intn-gpios = <&gpx2 3 GPIO_ACTIVE_HIGH>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&hsic_reset>;
+ };
+};
+
+&bus_dmc {
+ devfreq-events = <&ppmu_dmc0_3>, <&ppmu_dmc1_3>;
+ vdd-supply = <&buck1_reg>;
+ status = "okay";
+};
+
+&bus_acp {
+ devfreq = <&bus_dmc>;
+ status = "okay";
+};
+
+&bus_c2c {
+ devfreq = <&bus_dmc>;
+ status = "okay";
+};
+
+&bus_leftbus {
+ devfreq-events = <&ppmu_leftbus_3>, <&ppmu_rightbus_3>;
+ vdd-supply = <&buck3_reg>;
+ status = "okay";
+};
+
+&bus_rightbus {
+ devfreq = <&bus_leftbus>;
+ status = "okay";
+};
+
+&bus_fsys {
+ devfreq = <&bus_leftbus>;
+ status = "okay";
+};
+
+&bus_peri {
+ devfreq = <&bus_leftbus>;
+ status = "okay";
+};
+
+&bus_mfc {
+ devfreq = <&bus_leftbus>;
+ status = "okay";
+};
+
+&cpu0 {
+ cpu0-supply = <&buck2_reg>;
+};
+
+&hsotg {
+ vusb_d-supply = <&ldo15_reg>;
+ vusb_a-supply = <&ldo12_reg>;
+};
+
+&i2c_1 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ samsung,i2c-sda-delay = <100>;
+ samsung,i2c-max-bus-freq = <400000>;
+ pinctrl-0 = <&i2c1_bus>;
+ pinctrl-names = "default";
+ status = "okay";
+
+ s5m8767: s5m8767_pmic at 66 {
+ compatible = "samsung,s5m8767-pmic";
+ reg = <0x66>;
+
+ s5m8767,pmic-buck-default-dvs-idx = <3>;
+
+ s5m8767,pmic-buck-dvs-gpios = <&gpb 5 GPIO_ACTIVE_HIGH>,
+ <&gpb 6 GPIO_ACTIVE_HIGH>,
+ <&gpb 7 GPIO_ACTIVE_HIGH>;
+
+ s5m8767,pmic-buck-ds-gpios = <&gpm3 5 GPIO_ACTIVE_HIGH>,
+ <&gpm3 6 GPIO_ACTIVE_HIGH>,
+ <&gpm3 7 GPIO_ACTIVE_HIGH>;
+
+ /* VDD_ARM */
+ s5m8767,pmic-buck2-dvs-voltage = <1356250>, <1300000>,
+ <1243750>, <1118750>,
+ <1068750>, <1012500>,
+ <956250>, <900000>;
+ /* VDD_INT */
+ s5m8767,pmic-buck3-dvs-voltage = <1000000>, <1000000>,
+ <925000>, <925000>,
+ <887500>, <887500>,
+ <850000>, <850000>;
+ /* VDD_G3D */
+ s5m8767,pmic-buck4-dvs-voltage = <1081250>, <1081250>,
+ <1025000>, <950000>,
+ <918750>, <900000>,
+ <875000>, <831250>;
+
+ regulators {
+ ldo1_reg: LDO1 {
+ regulator-name = "VDD_ALIVE";
+ regulator-min-microvolt = <1100000>;
+ regulator-max-microvolt = <1100000>;
+ regulator-always-on;
+ regulator-boot-on;
+ op_mode = <1>; /* Normal Mode */
+ };
+
+ /* SCP uses 1.5v, POP uses 1.2v */
+ ldo2_reg: LDO2 {
+ regulator-name = "VDDQ_M12";
+ regulator-min-microvolt = <1500000>;
+ regulator-max-microvolt = <1500000>;
+ regulator-always-on;
+ regulator-boot-on;
+ op_mode = <1>; /* Normal Mode */
+ };
+
+ ldo3_reg: LDO3 {
+ regulator-name = "VDDIOAP_18";
+ regulator-min-microvolt = <1800000>;
+ regulator-max-microvolt = <1800000>;
+ regulator-always-on;
+ op_mode = <1>; /* Normal Mode */
+ };
+
+ ldo4_reg: LDO4 {
+ regulator-name = "VDDQ_PRE";
+ regulator-min-microvolt = <1800000>;
+ regulator-max-microvolt = <1800000>;
+ regulator-always-on;
+ op_mode = <1>; /* Normal Mode */
+ };
+
+ ldo6_reg: LDO6 {
+ regulator-name = "VDD10_MPLL";
+ regulator-min-microvolt = <1000000>;
+ regulator-max-microvolt = <1000000>;
+ regulator-always-on;
+ op_mode = <1>; /* Normal Mode */
+ };
+
+ ldo7_reg: LDO7 {
+ regulator-name = "VDD10_XPLL";
+ regulator-min-microvolt = <1000000>;
+ regulator-max-microvolt = <1000000>;
+ regulator-always-on;
+ op_mode = <1>; /* Normal Mode */
+ };
+
+ ldo8_reg: LDO8 {
+ regulator-name = "VDD10_MIPI";
+ regulator-min-microvolt = <1000000>;
+ regulator-max-microvolt = <1000000>;
+ op_mode = <1>; /* Normal Mode */
+ };
+
+ ldo9_reg: LDO9 {
+ regulator-name = "VDD33_LCD";
+ regulator-min-microvolt = <3300000>;
+ regulator-max-microvolt = <3300000>;
+ op_mode = <1>; /* Normal Mode */
+ };
+
+ ldo10_reg: LDO10 {
+ regulator-name = "VDD18_MIPI";
+ regulator-min-microvolt = <1800000>;
+ regulator-max-microvolt = <1800000>;
+ op_mode = <1>; /* Normal Mode */
+ };
+
+ ldo11_reg: LDO11 {
+ regulator-name = "VDD18_ABB1";
+ regulator-min-microvolt = <1800000>;
+ regulator-max-microvolt = <1800000>;
+ regulator-always-on;
+ op_mode = <1>; /* Normal Mode */
+ };
+
+ ldo12_reg: LDO12 {
+ regulator-name = "VDD33_UOTG";
+ regulator-min-microvolt = <3300000>;
+ regulator-max-microvolt = <3300000>;
+ regulator-always-on;
+ op_mode = <1>; /* Normal Mode */
+ };
+
+ ldo13_reg: LDO13 {
+ regulator-name = "VDDIOPERI_18";
+ regulator-min-microvolt = <1800000>;
+ regulator-max-microvolt = <1800000>;
+ regulator-always-on;
+ op_mode = <1>; /* Normal Mode */
+ };
+
+ ldo14_reg: LDO14 {
+ regulator-name = "VDD18_ABB02";
+ regulator-min-microvolt = <1800000>;
+ regulator-max-microvolt = <1800000>;
+ regulator-always-on;
+ op_mode = <1>; /* Normal Mode */
+ };
+
+ ldo15_reg: LDO15 {
+ regulator-name = "VDD10_USH";
+ regulator-min-microvolt = <1000000>;
+ regulator-max-microvolt = <1000000>;
+ regulator-always-on;
+ op_mode = <1>; /* Normal Mode */
+ };
+
+ ldo16_reg: LDO16 {
+ regulator-name = "VDD18_HSIC";
+ regulator-min-microvolt = <1800000>;
+ regulator-max-microvolt = <1800000>;
+ regulator-always-on;
+ op_mode = <1>; /* Normal Mode */
+ };
+
+ ldo17_reg: LDO17 {
+ regulator-name = "VDDIOAP_MMC012_28";
+ regulator-min-microvolt = <2800000>;
+ regulator-max-microvolt = <2800000>;
+ op_mode = <1>; /* Normal Mode */
+ };
+
+ /* Used by HSIC */
+ ldo18_reg: LDO18 {
+ regulator-name = "VDDIOPERI_28";
+ regulator-min-microvolt = <3300000>;
+ regulator-max-microvolt = <3300000>;
+ regulator-always-on;
+ op_mode = <1>; /* Normal Mode */
+ };
+
+ ldo20_reg: LDO20 {
+ regulator-name = "VDD28_CAM";
+ regulator-min-microvolt = <1800000>;
+ regulator-max-microvolt = <2800000>;
+ op_mode = <1>; /* Normal Mode */
+ };
+
+ ldo21_reg: LDO21 {
+ regulator-name = "VDD28_AF";
+ regulator-min-microvolt = <1800000>;
+ regulator-max-microvolt = <2800000>;
+ op_mode = <1>; /* Normal Mode */
+ };
+
+ ldo22_reg: LDO22 {
+ regulator-name = "VDDA28_2M";
+ regulator-min-microvolt = <2800000>;
+ regulator-max-microvolt = <2800000>;
+ op_mode = <1>; /* Normal Mode */
+ };
+
+ ldo23_reg: LDO23 {
+ regulator-name = "VDD28_TF";
+ regulator-min-microvolt = <2800000>;
+ regulator-max-microvolt = <2800000>;
+ op_mode = <1>; /* Normal Mode */
+ };
+
+ ldo24_reg: LDO24 {
+ regulator-name = "VDD33_A31";
+ regulator-min-microvolt = <3300000>;
+ regulator-max-microvolt = <3300000>;
+ op_mode = <1>; /* Normal Mode */
+ };
+
+ ldo25_reg: LDO25 {
+ regulator-name = "VDD18_CAM";
+ regulator-min-microvolt = <1800000>;
+ regulator-max-microvolt = <1800000>;
+ op_mode = <1>; /* Normal Mode */
+ };
+
+ ldo26_reg: LDO26 {
+ regulator-name = "VDD18_A31";
+ regulator-min-microvolt = <1800000>;
+ regulator-max-microvolt = <1800000>;
+ op_mode = <1>; /* Normal Mode */
+ };
+
+ ldo27_reg: LDO27 {
+ regulator-name = "GPS_1V8";
+ regulator-min-microvolt = <1800000>;
+ regulator-max-microvolt = <1800000>;
+ op_mode = <1>; /* Normal Mode */
+ };
+
+ ldo28_reg: LDO28 {
+ regulator-name = "DVDD12";
+ regulator-min-microvolt = <1200000>;
+ regulator-max-microvolt = <1200000>;
+ op_mode = <1>; /* Normal Mode */
+ };
+
+ buck1_reg: BUCK1 {
+ regulator-name = "vdd_mif";
+ regulator-min-microvolt = <850000>;
+ regulator-max-microvolt = <1100000>;
+ regulator-always-on;
+ regulator-boot-on;
+ op_mode = <1>; /* Normal Mode */
+ };
+
+ buck2_reg: BUCK2 {
+ regulator-name = "vdd_arm";
+ regulator-min-microvolt = <850000>;
+ regulator-max-microvolt = <1456250>;
+ regulator-always-on;
+ regulator-boot-on;
+ op_mode = <1>; /* Normal Mode */
+ };
+
+ buck3_reg: BUCK3 {
+ regulator-name = "vdd_int";
+ regulator-min-microvolt = <875000>;
+ regulator-max-microvolt = <1200000>;
+ regulator-always-on;
+ regulator-boot-on;
+ op_mode = <1>; /* Normal Mode */
+ };
+
+ buck4_reg: BUCK4 {
+ regulator-name = "vdd_g3d";
+ regulator-min-microvolt = <750000>;
+ regulator-max-microvolt = <1500000>;
+ regulator-always-on;
+ regulator-boot-on;
+ op_mode = <1>; /* Normal Mode */
+ };
+
+ buck5_reg: BUCK5 {
+ regulator-name = "vdd_m12";
+ regulator-min-microvolt = <750000>;
+ regulator-max-microvolt = <1500000>;
+ regulator-always-on;
+ regulator-boot-on;
+ op_mode = <1>; /* Normal Mode */
+ };
+
+ buck6_reg: BUCK6 {
+ regulator-name = "vdd12_5m";
+ regulator-min-microvolt = <750000>;
+ regulator-max-microvolt = <1500000>;
+ regulator-always-on;
+ regulator-boot-on;
+ op_mode = <1>; /* Normal Mode */
+ };
+
+ buck7_reg: BUCK7 {
+ regulator-name = "pvdd_buck7";
+ regulator-min-microvolt = <750000>;
+ regulator-max-microvolt = <2000000>;
+ regulator-boot-on;
+ regulator-always-on;
+ op_mode = <1>; /* Normal Mode */
+ };
+
+ buck8_reg: BUCK8 {
+ regulator-name = "pvdd_buck8";
+ regulator-min-microvolt = <750000>;
+ regulator-max-microvolt = <1500000>;
+ regulator-boot-on;
+ regulator-always-on;
+ op_mode = <1>; /* Normal Mode */
+ };
+
+ buck9_reg: BUCK9 {
+ regulator-name = "vddf28_emmc";
+ regulator-min-microvolt = <750000>;
+ regulator-max-microvolt = <3000000>;
+ op_mode = <1>; /* Normal Mode */
+ };
+ };
+
+ s5m8767_osc: clocks {
+ #clock-cells = <1>;
+ clock-output-names = "s5m8767_ap",
+ "s5m8767_cp", "s5m8767_bt";
+ };
+
+ };
+};
+
+&mfc {
+ status = "okay";
+};
+
+&mshc_0 {
+ pinctrl-0 = <&sd4_clk &sd4_cmd &sd4_bus4 &sd4_bus8>;
+ pinctrl-names = "default";
+ status = "okay";
+ vmmc-supply = <&buck9_reg>;
+ num-slots = <1>;
+ broken-cd;
+ card-detect-delay = <200>;
+ samsung,dw-mshc-ciu-div = <3>;
+ samsung,dw-mshc-sdr-timing = <2 3>;
+ samsung,dw-mshc-ddr-timing = <1 2>;
+ bus-width = <8>;
+ cap-mmc-highspeed;
+};
+
+&pinctrl_1 {
+ hsic_reset: hsic-reset {
+ samsung,pins = "gpm2-4";
+ samsung,pin-function = <1>;
+ samsung,pin-pud = <0>;
+ samsung,pin-drv = <3>;
+ };
+};
+
+&rtc {
+ status = "okay";
+ clocks = <&clock CLK_RTC>, <&s5m8767_osc S2MPS11_CLK_AP>;
+ clock-names = "rtc", "rtc_src";
+};
+
+&tmu {
+ vtmu-supply = <&ldo16_reg>;
+ status = "okay";
+};
+
+&watchdog {
+ status = "okay";
+};
--
2.7.4
^ permalink raw reply related
* [PATCH v7 0/3] Add a new board TOPEET iTOP for Exynos 4412
From: Randy Li @ 2016-09-18 14:01 UTC (permalink / raw)
To: linux-arm-kernel
Changelog:
- v7:
add a missing header file
add a rootdelay to bootargs or it can't mount root filesystem
fix the memory node
- v6:
move pwms pinctrl to pwms node
fix the order of the dtb file in Makefile
- v5:
- correct the mail format
- v4:
- re-order some nodes in alphabetical order
- fix some minor bugs
- add a entry in vendor list
- v3:
- fixing the rtc clock, using clock source from PMIC
- enable the tmu
- enable the fimc for elite board
- suuport the audio codec at elite board
- fixing minor bugs in the last commit
- v2:
- removing rtc node
the clock source driver is not done yet.
- adding exynos-bus
- fixing the MFC
Randy Li (3):
ARM: dts: Add TOPEET itop core board SCP package version
ARM: dts: add TOPEET itop elite based board
devicetree: bindings: Add vendor prefix for Topeet.
.../bindings/arm/samsung/samsung-boards.txt | 3 +
.../devicetree/bindings/vendor-prefixes.txt | 1 +
arch/arm/boot/dts/Makefile | 1 +
arch/arm/boot/dts/exynos4412-itop-elite.dts | 240 ++++++++++
arch/arm/boot/dts/exynos4412-itop-scp-core.dtsi | 491 +++++++++++++++++++++
5 files changed, 736 insertions(+)
create mode 100644 arch/arm/boot/dts/exynos4412-itop-elite.dts
create mode 100644 arch/arm/boot/dts/exynos4412-itop-scp-core.dtsi
--
2.7.4
^ permalink raw reply
* [PATCH] drm/exynos: mark exynos_dp_crtc_clock_enable() static
From: Baoyou Xie @ 2016-09-18 13:58 UTC (permalink / raw)
To: linux-arm-kernel
We get 1 warning when building kernel with W=1:
drivers/gpu/drm/exynos/exynos_dp.c:46:5: warning: no previous prototype for 'exynos_dp_crtc_clock_enable' [-Wmissing-prototypes]
In fact, this function is only used in the file in which it is
declared and don't need a declaration, but can be made static.
So this patch marks it 'static'.
Signed-off-by: Baoyou Xie <baoyou.xie@linaro.org>
---
drivers/gpu/drm/exynos/exynos_dp.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/exynos/exynos_dp.c b/drivers/gpu/drm/exynos/exynos_dp.c
index 4f08505..528229f 100644
--- a/drivers/gpu/drm/exynos/exynos_dp.c
+++ b/drivers/gpu/drm/exynos/exynos_dp.c
@@ -43,7 +43,7 @@ struct exynos_dp_device {
struct analogix_dp_plat_data plat_data;
};
-int exynos_dp_crtc_clock_enable(struct analogix_dp_plat_data *plat_data,
+static int exynos_dp_crtc_clock_enable(struct analogix_dp_plat_data *plat_data,
bool enable)
{
struct exynos_dp_device *dp = to_dp(plat_data);
--
2.7.4
^ permalink raw reply related
* [PATCH] crypto: sun4i-ss: mark sun4i_hash() static
From: Baoyou Xie @ 2016-09-18 12:52 UTC (permalink / raw)
To: linux-arm-kernel
We get 1 warning when building kernel with W=1:
drivers/crypto/sunxi-ss/sun4i-ss-hash.c:168:5: warning: no previous prototype for 'sun4i_hash' [-Wmissing-prototypes]
In fact, this function is only used in the file in which it is
declared and don't need a declaration, but can be made static.
So this patch marks it 'static'.
Signed-off-by: Baoyou Xie <baoyou.xie@linaro.org>
---
drivers/crypto/sunxi-ss/sun4i-ss-hash.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/crypto/sunxi-ss/sun4i-ss-hash.c b/drivers/crypto/sunxi-ss/sun4i-ss-hash.c
index 1afeb8e..0de2f62 100644
--- a/drivers/crypto/sunxi-ss/sun4i-ss-hash.c
+++ b/drivers/crypto/sunxi-ss/sun4i-ss-hash.c
@@ -165,7 +165,7 @@ int sun4i_hash_import_sha1(struct ahash_request *areq, const void *in)
* write remaining data in op->buf
* final state op->len=56
*/
-int sun4i_hash(struct ahash_request *areq)
+static int sun4i_hash(struct ahash_request *areq)
{
u32 v, ivmode = 0;
unsigned int i = 0;
--
2.7.4
^ permalink raw reply related
* [PATCH V5 3/6] ARM: bcm2835: dts: add thermal node to device-tree of bcm283x
From: Stefan Wahren @ 2016-09-18 11:41 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1473759262-27031-4-git-send-email-kernel@martin.sperl.org>
> kernel at martin.sperl.org hat am 13. September 2016 um 11:34 geschrieben:
>
>
> From: Martin Sperl <kernel@martin.sperl.org>
>
> Add the node for the thermal sensor of the bcm2835-soc
> to the device tree.
>
> Signed-off-by: Martin Sperl <kernel@martin.sperl.org>
>
> Changelog:
> V1 -> V5: generic settings is shared in bcm283x.dtsi, but disabled
> moved the compatible string to the SOC specific dtsi
> for arm and arm64
>
> Note: there is no arm/boot/dts/bcm2837.dtsi as of now,
> so there is no support for bcm2837 in 32 bit mode.
> ---
> arch/arm/boot/dts/bcm2835.dtsi | 6 ++++++
> arch/arm/boot/dts/bcm2836.dtsi | 6 ++++++
> arch/arm/boot/dts/bcm283x.dtsi | 7 +++++++
> 3 files changed, 19 insertions(+)
>
> diff --git a/arch/arm/boot/dts/bcm2835.dtsi b/arch/arm/boot/dts/bcm2835.dtsi
> index a78759e..0890d97 100644
> --- a/arch/arm/boot/dts/bcm2835.dtsi
> +++ b/arch/arm/boot/dts/bcm2835.dtsi
> @@ -23,3 +23,9 @@
> };
> };
> };
> +
> +/* enable thermal sensor with the correct compatible property set */
> +&thermal {
> + compatible = "brcm,bcm2835-thermal";
> + status = "okay";
> +};
> diff --git a/arch/arm/boot/dts/bcm2836.dtsi b/arch/arm/boot/dts/bcm2836.dtsi
> index 9d0651d..519a44f 100644
> --- a/arch/arm/boot/dts/bcm2836.dtsi
> +++ b/arch/arm/boot/dts/bcm2836.dtsi
> @@ -76,3 +76,9 @@
> interrupt-parent = <&local_intc>;
> interrupts = <8>;
> };
> +
> +/* enable thermal sensor with the correct compatible property set */
> +&thermal {
> + compatible = "brcm,bcm2836-thermal";
> + status = "okay";
> +};
> diff --git a/arch/arm/boot/dts/bcm283x.dtsi b/arch/arm/boot/dts/bcm283x.dtsi
> index b982522..2cc4847 100644
> --- a/arch/arm/boot/dts/bcm283x.dtsi
> +++ b/arch/arm/boot/dts/bcm283x.dtsi
> @@ -186,6 +186,13 @@
> interrupts = <2 14>; /* pwa1 */
> };
>
> + thermal: thermal at 0x7e212000 {
After removing 0x here like in the binding doc you can add:
Acked-by: Stefan Wahren <stefan.wahren@i2se.com>
> + compatible = "brcm,bcm2835-thermal";
> + reg = <0x7e212000 0x8>;
> + clocks = <&clocks BCM2835_CLOCK_TSENS>;
> + status = "disabled";
> + };
> +
> aux: aux at 0x7e215000 {
> compatible = "brcm,bcm2835-aux";
> #clock-cells = <1>;
> --
> 2.1.4
>
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH 1/2] pinctrl: pm8994: add pad voltage regulator defines
From: Linus Walleij @ 2016-09-18 11:38 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1474047681-6821-2-git-send-email-srinivas.kandagatla@linaro.org>
On Fri, Sep 16, 2016 at 7:41 PM, Srinivas Kandagatla
<srinivas.kandagatla@linaro.org> wrote:
> This patch adds defines for internal voltage regulators used
> to switch voltage levels on gpio/mpp pads.
>
> Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org>
Acked-by: Linus Walleij <linus.walleij@linaro.org>
Andy can merge this with the rest of the stuff to the Qualcomm SoC tree.
Yours,
Linus Walleij
^ permalink raw reply
* [PATCH V5 2/6] thermal: bcm2835: add thermal driver for bcm2835 soc
From: Stefan Wahren @ 2016-09-18 11:31 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1473759262-27031-3-git-send-email-kernel@martin.sperl.org>
Hi Martin,
> kernel at martin.sperl.org hat am 13. September 2016 um 11:34 geschrieben:
>
>
> From: Martin Sperl <kernel@martin.sperl.org>
>
> Add basic thermal driver for bcm2835 SOC.
>
> This driver currently relies on the firmware setting up the
> tsense HW block and does not set it up itself.
>
> Signed-off-by: Martin Sperl <kernel@martin.sperl.org>
>
> ChangeLog:
> V1 -> V2: added specific settings depending on compatiblity
> added trip point based on register
> setting up ctrl-register if HW is not enabled by firmware
> as per recommendation of Eric (untested)
> check that clock frequency is in range
> (1.9 - 5MHz - as per comment in clk-bcm2835.c)
> V2 -> V4: moved back to thermal (not using bcm sub-directory)
> set polling interval to 1second (was 0ms, so interrupt driven)
> ---
> drivers/thermal/Kconfig | 5 +
> drivers/thermal/Makefile | 1 +
> drivers/thermal/bcm2835_thermal.c | 327
> ++++++++++++++++++++++++++++++++++++++
> 3 files changed, 333 insertions(+)
> create mode 100644 drivers/thermal/bcm2835_thermal.c
>
> diff --git a/drivers/thermal/Kconfig b/drivers/thermal/Kconfig
> index 2d702ca..5e3e4e4 100644
> --- a/drivers/thermal/Kconfig
> +++ b/drivers/thermal/Kconfig
> @@ -399,4 +399,9 @@ config GENERIC_ADC_THERMAL
> to this driver. This driver reports the temperature by reading ADC
> channel and converts it to temperature based on lookup table.
>
> +config BCM2835_THERMAL
> + tristate "Thermal sensors on bcm2835 SoC"
i'm not sure if "depends on ARCH_BCM2835 || COMPILE_TEST" is necessary here,
but the following is:
depends on OF
depends on HAS_IOMEM
> + help
> + Support for thermal sensors on Broadcom bcm2835 SoCs.
> +
> endif
> diff --git a/drivers/thermal/Makefile b/drivers/thermal/Makefile
> index 10b07c1..c26343e 100644
> --- a/drivers/thermal/Makefile
> +++ b/drivers/thermal/Makefile
> @@ -51,3 +51,4 @@ obj-$(CONFIG_TEGRA_SOCTHERM) += tegra/
> obj-$(CONFIG_HISI_THERMAL) += hisi_thermal.o
> obj-$(CONFIG_MTK_THERMAL) += mtk_thermal.o
> obj-$(CONFIG_GENERIC_ADC_THERMAL) += thermal-generic-adc.o
> +obj-$(CONFIG_BCM2835_THERMAL) += bcm2835_thermal.o
> ...
> +
> +static int bcm2835_thermal_get_temp(struct thermal_zone_device *tz,
> + int *temp)
> +{
> + struct bcm2835_thermal_data *data = tz->devdata;
> + u32 val = readl(data->regs + BCM2835_TS_TSENSSTAT);
> +
> + if (!(val & BCM2835_TS_TSENSSTAT_VALID))
> + return -EIO;
> +
> + /* mask the relevant bits */
I think this is obvious and could be removed.
> + val &= BCM2835_TS_TSENSSTAT_DATA_MASK;
> +
> + *temp = bcm2835_thermal_adc2temp(data->info, val);
> +
> + return 0;
> +}
> +
> ...
> +static const struct of_device_id bcm2835_thermal_of_match_table[];
> +static int bcm2835_thermal_probe(struct platform_device *pdev)
> +{
> + const struct of_device_id *match;
> + struct thermal_zone_device *tz;
> + struct bcm2835_thermal_data *data;
> + struct resource *res;
> + int err;
> + u32 val;
> + unsigned long rate;
> +
> + data = devm_kzalloc(&pdev->dev, sizeof(*data), GFP_KERNEL);
> + if (!data)
> + return -ENOMEM;
> +
> + match = of_match_device(bcm2835_thermal_of_match_table,
> + &pdev->dev);
> + if (!match)
> + return -EINVAL;
> + data->info = match->data;
> +
> + /* get registers */
ditto
> + res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
> + data->regs = devm_ioremap_resource(&pdev->dev, res);
> + if (IS_ERR(data->regs)) {
> + err = PTR_ERR(data->regs);
> + dev_err(&pdev->dev, "Could not get registers: %d\n", err);
> + return err;
> + }
> +
> + /* get clock */
ditto
> + data->clk = devm_clk_get(&pdev->dev, NULL);
> + if (IS_ERR(data->clk)) {
> + err = PTR_ERR(data->clk);
> + if (err != -EPROBE_DEFER)
> + dev_err(&pdev->dev, "Could not get clk: %d\n", err);
> + return err;
> + }
> +
> + /* set up registers if not already done by the fw */
> + val = readl(data->regs + BCM2835_TS_TSENSCTL);
> + if (!(val & BCM2835_TS_TSENSCTL_RSTB)) {
> + /* the basic required flags */
> + val = (BCM2835_TS_TSENSCTL_CTRL_DEFAULT <<
> + BCM2835_TS_TSENSCTL_CTRL_SHIFT) |
> + BCM2835_TS_TSENSCTL_REGULEN;
The comment above isn't helpful. Could you please write down the intension
behind this bit operation?
> +
> + /* reset delay */
What is the unit of the delay (seconds, 1/10 seconds)?
> + val |= (BCM2835_TS_TSENSCTL_RSTDELAY_DEFAULT <<
Instead of hiding the value behind a define, please use the number directly and
remove this define.
> + BCM2835_TS_TSENSCTL_RSTDELAY_SHIFT);
> +
> + /* trip_adc value from info */
> + val |= bcm2835_thermal_temp2adc(data->info,
> + data->info->trip_temp) <<
> + BCM2835_TS_TSENSCTL_THOLD_SHIFT;
> +
> + /* write the value back to the register as 2 steps */
> + writel(val, data->regs + BCM2835_TS_TSENSCTL);
> + val |= BCM2835_TS_TSENSCTL_RSTB;
> + writel(val, data->regs + BCM2835_TS_TSENSCTL);
> + }
> +
> + /* enable clock and check rate */
> + clk_prepare_enable(data->clk);
This could fail. So please check the result and move this call before the
register set up.
> + rate = clk_get_rate(data->clk);
> + if ((rate < 1920000) || (rate > 5000000)) {
> + dev_warn(&pdev->dev,
> + "Clock %pCn is running at %pCr Hz, which is outside the recommended range
> of 1.9 to 5.0 MHz\n",
> + data->clk, data->clk);
Instead of printing the clock name twice your intension would be to print the
actual clock rate?
Btw the message is very long. Could you please shorten it and make the lower
limit more precise 1.92 MHz?
> + }
> +
> + /* register thermal zone with 1 trip point an 1s polling */
> + tz = thermal_zone_device_register("bcm2835_thermal",
> + 1, 0, data,
> + &bcm2835_thermal_ops,
> + NULL,
> + 0, 1000);
> + if (IS_ERR(tz)) {
> + clk_disable_unprepare(data->clk);
> + err = PTR_ERR(tz);
> + dev_err(&pdev->dev,
> + "Failed to register the thermal device: %d\n",
> + err);
> + return err;
> + }
> +
> + platform_set_drvdata(pdev, tz);
> +
> + bcm2835_thermal_debugfs(pdev);
> +
> + return 0;
> +}
> +
> +static int bcm2835_thermal_remove(struct platform_device *pdev)
> +{
> + struct thermal_zone_device *tz = platform_get_drvdata(pdev);
> + struct bcm2835_thermal_data *data = tz->devdata;
> +
> + debugfs_remove_recursive(data->debugfsdir);
> + thermal_zone_device_unregister(tz);
clk_disable_unprepare(data->clk)
> +
> + return 0;
> +}
> +
> +static const struct of_device_id bcm2835_thermal_of_match_table[] = {
> + {
> + .compatible = "brcm,bcm2835-thermal",
> + .data = &(struct bcm2835_thermal_info) {
> + .offset = 407000,
> + .slope = -538,
> + .trip_temp = 80000
Since the operating temperature of the bcm2835 is only available in the
Foundation FAQ. I would suggest to add the recommenend operating temperature
range ( -40 C to +85 C ) here as a comment.
Thanks
Stefan
^ permalink raw reply
* [PATCH] ARM: tegra: nyan: Mark all USB ports as host
From: Paul Kocialkowski @ 2016-09-18 10:28 UTC (permalink / raw)
To: linux-arm-kernel
Nyan boards only have host USB ports (2 external, 1 internal), there is
no OTG-enabled connector.
Signed-off-by: Paul Kocialkowski <contact@paulk.fr>
---
arch/arm/boot/dts/tegra124-nyan.dtsi | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/tegra124-nyan.dtsi b/arch/arm/boot/dts/tegra124-nyan.dtsi
index 18db797..254b2ee 100644
--- a/arch/arm/boot/dts/tegra124-nyan.dtsi
+++ b/arch/arm/boot/dts/tegra124-nyan.dtsi
@@ -435,7 +435,7 @@
usb2-0 {
vbus-supply = <&vdd_usb1_vbus>;
status = "okay";
- mode = "otg";
+ mode = "host";
};
usb2-1 {
--
2.9.3
^ permalink raw reply related
* [PATCH v3 1/4] drm/bridge: Add RGB to VGA bridge support
From: Laurent Pinchart @ 2016-09-18 10:04 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <2115773.yQojqqIjGI@avalon>
On Sunday 18 Sep 2016 13:01:16 Laurent Pinchart wrote:
> On Thursday 08 Sep 2016 14:17:48 Maxime Ripard wrote:
> > Some boards have an entirely passive RGB to VGA bridge, based on either
> > DACs or resistor ladders.
> >
> > Those might or might not have an i2c bus routed to the VGA connector in
> > order to access the screen EDIDs.
> >
> > Add a bridge that doesn't do anything but expose the modes available on
> > the screen, either based on the EDIDs if available, or based on the XGA
> > standards.
> >
> > Acked-by: Rob Herring <robh@kernel.org>
> > Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com>
> > ---
> >
> > .../bindings/display/bridge/rgb-to-vga-bridge.txt | 52 +++++
> > drivers/gpu/drm/bridge/Kconfig | 6 +
> > drivers/gpu/drm/bridge/Makefile | 1 +
> > drivers/gpu/drm/bridge/rgb-to-vga.c | 232 ++++++++++++++++
> > 4 files changed, 291 insertions(+)
> > create mode 100644
> >
> > Documentation/devicetree/bindings/display/bridge/rgb-to-vga-bridge.txt
> > create mode 100644 drivers/gpu/drm/bridge/rgb-to-vga.c
> >
> > diff --git
> > a/Documentation/devicetree/bindings/display/bridge/rgb-to-vga-bridge.txt
> > b/Documentation/devicetree/bindings/display/bridge/rgb-to-vga-bridge.txt
> > new file mode 100644
> > index 000000000000..83a053fb51a0
> > --- /dev/null
> > +++
> > b/Documentation/devicetree/bindings/display/bridge/rgb-to-vga-bridge.txt
> > @@ -0,0 +1,52 @@
> > +Passive RGB to VGA bridge
> > +-------------------------
> > +
> > +This binding is aimed for entirely passive RGB to VGA bridges that do not
> > +require any configuration.
>
> Couldn't it also support active RGB to VGA bridges that don't require any
> configuration ? It would seem a bit pointless to define a separate DT
> binding for them.
I'm thinking in particular about the ADV7123
(http://www.analog.com/media/en/technical-documentation/data-sheets/ADV7123.pdf) that already has a DT binding. Would it be feasible to
combine the two, and support both devices with a single driver ?
> > +Required properties:
> > +
> > +- compatible: Must be "rgb-to-vga-bridge"
> > +
> > +Required nodes:
> > +
> > +This device has two video ports. Their connections are modeled using the
> > OF +graph bindings specified in
> > Documentation/devicetree/bindings/graph.txt. +
> > +- Video port 0 for RGB input
> > +- Video port 1 for VGA output
> > +
> > +
> > +Example
> > +-------
> > +
> > +bridge {
> > + compatible = "rgb-to-vga-bridge";
> > + #address-cells = <1>;
> > + #size-cells = <0>;
> > +
> > + ports {
> > + #address-cells = <1>;
> > + #size-cells = <0>;
> > +
> > + port at 0 {
> > + #address-cells = <1>;
> > + #size-cells = <0>;
> > + reg = <0>;
> > +
> > + vga_bridge_in: endpoint {
> > + remote-endpoint = <&tcon0_out_vga>;
> > + };
> > + };
> > +
> > + port at 1 {
> > + #address-cells = <1>;
> > + #size-cells = <0>;
> > + reg = <1>;
> > +
> > + vga_bridge_out: endpoint {
> > + remote-endpoint = <&vga_con_in>;
> > + };
> > + };
> > + };
> > +};
--
Regards,
Laurent Pinchart
^ permalink raw reply
* [PATCH v3 1/4] drm/bridge: Add RGB to VGA bridge support
From: Laurent Pinchart @ 2016-09-18 10:01 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20160908121751.16911-2-maxime.ripard@free-electrons.com>
Hi Maxime,
Thank you for the patch.
On Thursday 08 Sep 2016 14:17:48 Maxime Ripard wrote:
> Some boards have an entirely passive RGB to VGA bridge, based on either
> DACs or resistor ladders.
>
> Those might or might not have an i2c bus routed to the VGA connector in
> order to access the screen EDIDs.
>
> Add a bridge that doesn't do anything but expose the modes available on the
> screen, either based on the EDIDs if available, or based on the XGA
> standards.
>
> Acked-by: Rob Herring <robh@kernel.org>
> Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com>
> ---
> .../bindings/display/bridge/rgb-to-vga-bridge.txt | 52 +++++
> drivers/gpu/drm/bridge/Kconfig | 6 +
> drivers/gpu/drm/bridge/Makefile | 1 +
> drivers/gpu/drm/bridge/rgb-to-vga.c | 232 ++++++++++++++++++
> 4 files changed, 291 insertions(+)
> create mode 100644
> Documentation/devicetree/bindings/display/bridge/rgb-to-vga-bridge.txt
> create mode 100644 drivers/gpu/drm/bridge/rgb-to-vga.c
>
> diff --git
> a/Documentation/devicetree/bindings/display/bridge/rgb-to-vga-bridge.txt
> b/Documentation/devicetree/bindings/display/bridge/rgb-to-vga-bridge.txt
> new file mode 100644
> index 000000000000..83a053fb51a0
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/display/bridge/rgb-to-vga-bridge.txt
> @@ -0,0 +1,52 @@
> +Passive RGB to VGA bridge
> +-------------------------
> +
> +This binding is aimed for entirely passive RGB to VGA bridges that do not
> +require any configuration.
Couldn't it also support active RGB to VGA bridges that don't require any
configuration ? It would seem a bit pointless to define a separate DT binding
for them.
> +Required properties:
> +
> +- compatible: Must be "rgb-to-vga-bridge"
> +
> +Required nodes:
> +
> +This device has two video ports. Their connections are modeled using the OF
> +graph bindings specified in Documentation/devicetree/bindings/graph.txt.
> +
> +- Video port 0 for RGB input
> +- Video port 1 for VGA output
> +
> +
> +Example
> +-------
> +
> +bridge {
> + compatible = "rgb-to-vga-bridge";
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + ports {
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + port at 0 {
> + #address-cells = <1>;
> + #size-cells = <0>;
> + reg = <0>;
> +
> + vga_bridge_in: endpoint {
> + remote-endpoint = <&tcon0_out_vga>;
> + };
> + };
> +
> + port at 1 {
> + #address-cells = <1>;
> + #size-cells = <0>;
> + reg = <1>;
> +
> + vga_bridge_out: endpoint {
> + remote-endpoint = <&vga_con_in>;
> + };
> + };
> + };
> +};
> diff --git a/drivers/gpu/drm/bridge/Kconfig b/drivers/gpu/drm/bridge/Kconfig
> index b590e678052d..42b95adf5091 100644
> --- a/drivers/gpu/drm/bridge/Kconfig
> +++ b/drivers/gpu/drm/bridge/Kconfig
> @@ -17,6 +17,12 @@ config DRM_ANALOGIX_ANX78XX
> the HDMI output of an application processor to MyDP
> or DisplayPort.
>
> +config DRM_RGB_TO_VGA
> + tristate "Dumb RGB to VGA Bridge support"
> + select DRM_KMS_HELPER
> + help
> + Support for passive RGB to VGA bridges
> +
> config DRM_DW_HDMI
> tristate
> select DRM_KMS_HELPER
> diff --git a/drivers/gpu/drm/bridge/Makefile
> b/drivers/gpu/drm/bridge/Makefile index efdb07e878f5..3bb8cbe09fe9 100644
> --- a/drivers/gpu/drm/bridge/Makefile
> +++ b/drivers/gpu/drm/bridge/Makefile
> @@ -1,6 +1,7 @@
> ccflags-y := -Iinclude/drm
>
> obj-$(CONFIG_DRM_ANALOGIX_ANX78XX) += analogix-anx78xx.o
> +obj-$(CONFIG_DRM_RGB_TO_VGA) += rgb-to-vga.o
> obj-$(CONFIG_DRM_DW_HDMI) += dw-hdmi.o
> obj-$(CONFIG_DRM_DW_HDMI_AHB_AUDIO) += dw-hdmi-ahb-audio.o
> obj-$(CONFIG_DRM_NXP_PTN3460) += nxp-ptn3460.o
> diff --git a/drivers/gpu/drm/bridge/rgb-to-vga.c
> b/drivers/gpu/drm/bridge/rgb-to-vga.c new file mode 100644
> index 000000000000..84b1b10198a4
> --- /dev/null
> +++ b/drivers/gpu/drm/bridge/rgb-to-vga.c
> @@ -0,0 +1,232 @@
> +
> +#include <linux/module.h>
> +#include <linux/of_graph.h>
> +
> +#include <drm/drmP.h>
> +#include <drm/drm_atomic_helper.h>
> +#include <drm/drm_crtc.h>
> +#include <drm/drm_crtc_helper.h>
> +
> +struct dumb_vga {
> + struct drm_bridge bridge;
> + struct drm_connector connector;
> +
> + struct i2c_adapter *ddc;
> +};
> +
> +static inline struct dumb_vga *
> +drm_bridge_to_dumb_vga(struct drm_bridge *bridge)
> +{
> + return container_of(bridge, struct dumb_vga, bridge);
> +}
> +
> +static inline struct dumb_vga *
> +drm_connector_to_dumb_vga(struct drm_connector *connector)
> +{
> + return container_of(connector, struct dumb_vga, connector);
> +}
> +
> +static int dumb_vga_get_modes(struct drm_connector *connector)
> +{
> + struct dumb_vga *vga = drm_connector_to_dumb_vga(connector);
> + struct edid *edid;
> + int ret;
> +
> + if (IS_ERR(vga->ddc))
> + goto fallback;
> +
> + edid = drm_get_edid(connector, vga->ddc);
> + if (!edid) {
> + DRM_INFO("EDID readout failed, falling back to standard
modes\n");
> + goto fallback;
> + }
> +
> + drm_mode_connector_update_edid_property(connector, edid);
> + return drm_add_edid_modes(connector, edid);
> +
> +fallback:
> + /*
> + * In case we cannot retrieve the EDIDs (broken or missing i2c
> + * bus), fallback on the XGA standards
> + */
> + ret = drm_add_modes_noedid(connector, 1920, 1200);
> +
> + /* And prefer a mode pretty much anyone can handle */
> + drm_set_preferred_mode(connector, 1024, 768);
> +
> + return ret;
> +}
> +
> +static struct drm_encoder *
> +dumb_vga_best_encoder(struct drm_connector *connector)
> +{
> + struct dumb_vga *vga = drm_connector_to_dumb_vga(connector);
> +
> + return vga->bridge.encoder;
> +}
> +
> +static struct drm_connector_helper_funcs dumb_vga_con_helper_funcs = {
> + .get_modes = dumb_vga_get_modes,
> + .best_encoder = dumb_vga_best_encoder,
> +};
> +
> +static enum drm_connector_status
> +dumb_vga_connector_detect(struct drm_connector *connector, bool force)
> +{
> + struct dumb_vga *vga = drm_connector_to_dumb_vga(connector);
> +
> + /*
> + * Even if we have an I2C bus, we can't assume that the cable
> + * is disconnected if drm_probe_ddc. Some cables don't wire
> + * the DDC pins, or the I2C bus might be disfunctional.
> + */
> + if (!IS_ERR(vga->ddc) && drm_probe_ddc(vga->ddc))
> + return connector_status_connected;
> +
> + return connector_status_unknown;
> +}
> +
> +static void
> +dumb_vga_connector_destroy(struct drm_connector *connector)
> +{
> + drm_connector_cleanup(connector);
> +}
> +
> +static struct drm_connector_funcs dumb_vga_con_funcs = {
> + .dpms = drm_atomic_helper_connector_dpms,
> + .detect = dumb_vga_connector_detect,
> + .fill_modes = drm_helper_probe_single_connector_modes,
> + .destroy = dumb_vga_connector_destroy,
> + .reset = drm_atomic_helper_connector_reset,
> + .atomic_duplicate_state = drm_atomic_helper_connector_duplicate_state,
> + .atomic_destroy_state = drm_atomic_helper_connector_destroy_state,
> +};
> +
> +static int dumb_vga_attach(struct drm_bridge *bridge)
> +{
> + struct dumb_vga *vga = drm_bridge_to_dumb_vga(bridge);
> + int ret;
> +
> + if (!bridge->encoder) {
> + DRM_ERROR("Missing encoder\n");
> + return -ENODEV;
> + }
> +
> + drm_connector_helper_add(&vga->connector,
> + &dumb_vga_con_helper_funcs);
> + ret = drm_connector_init(bridge->dev, &vga->connector,
> + &dumb_vga_con_funcs, DRM_MODE_CONNECTOR_VGA);
Bridges should really not create connectors. Fixing this problem is a bit out
of scope for your patch, but I'm concerned that the growing number of bridge
drivers will make it difficult to fix it later.
> + if (ret) {
> + DRM_ERROR("Failed to initialize connector\n");
> + return ret;
> + }
> +
> + drm_mode_connector_attach_encoder(&vga->connector,
> + bridge->encoder);
> +
> + return 0;
> +}
> +
> +static void dumb_vga_nop(struct drm_bridge *bridge) {};
> +
> +static struct drm_bridge_funcs dumb_vga_bridge_funcs = {
> + .attach = dumb_vga_attach,
> + .enable = dumb_vga_nop,
> + .disable = dumb_vga_nop,
> + .pre_enable = dumb_vga_nop,
> + .post_disable = dumb_vga_nop,
Those four operations are optional, you don't need dumb_vga_nop().
> +};
> +
> +static struct i2c_adapter *dumb_vga_retrieve_ddc(struct device *dev)
> +{
> + struct device_node *end_node, *phandle, *remote;
> + struct i2c_adapter *ddc;
> +
> + end_node = of_graph_get_endpoint_by_regs(dev->of_node, 1, -1);
> + if (!end_node) {
> + dev_err(dev, "Missing connector endpoint\n");
> + return ERR_PTR(-ENODEV);
> + }
> +
> + remote = of_graph_get_remote_port_parent(end_node);
> + of_node_put(end_node);
> + if (!remote) {
> + dev_err(dev, "Enable to parse remote node\n");
> + return ERR_PTR(-EINVAL);
> + }
> +
> + phandle = of_parse_phandle(remote, "ddc-i2c-bus", 0);
> + of_node_put(remote);
> + if (!phandle)
> + return ERR_PTR(-ENODEV);
> +
> + ddc = of_get_i2c_adapter_by_node(phandle);
> + of_node_put(phandle);
> + if (!ddc)
> + return ERR_PTR(-EPROBE_DEFER);
> +
> + return ddc;
> +}
> +
> +static int dumb_vga_probe(struct platform_device *pdev)
> +{
> + struct dumb_vga *vga;
> + int ret;
> +
> + vga = devm_kzalloc(&pdev->dev, sizeof(*vga), GFP_KERNEL);
> + if (!vga)
> + return -ENOMEM;
> + platform_set_drvdata(pdev, vga);
> +
> + vga->ddc = dumb_vga_retrieve_ddc(&pdev->dev);
> + if (IS_ERR(vga->ddc)) {
> + if (PTR_ERR(vga->ddc) == -ENODEV) {
> + dev_info(&pdev->dev,
> + "No i2c bus specified... Disabling EDID
readout\n");
> + } else {
> + dev_err(&pdev->dev, "Couldn't retrieve i2c bus\n");
> + return PTR_ERR(vga->ddc);
> + }
> + }
> +
> + vga->bridge.funcs = &dumb_vga_bridge_funcs;
> + vga->bridge.of_node = pdev->dev.of_node;
> +
> + ret = drm_bridge_add(&vga->bridge);
> + if (ret && !IS_ERR(vga->ddc))
> + i2c_put_adapter(vga->ddc);
> +
> + return ret;
> +}
> +
> +static int dumb_vga_remove(struct platform_device *pdev)
> +{
> + struct dumb_vga *vga = platform_get_drvdata(pdev);
> +
> + drm_bridge_remove(&vga->bridge);
> +
> + if (!IS_ERR(vga->ddc))
> + i2c_put_adapter(vga->ddc);
> +
> + return 0;
> +}
> +
> +static const struct of_device_id dumb_vga_match[] = {
> + { .compatible = "rgb-to-vga-bridge" },
> + {},
> +};
> +MODULE_DEVICE_TABLE(of, dumb_vga_match);
> +
> +struct platform_driver dumb_vga_driver = {
> + .probe = dumb_vga_probe,
> + .remove = dumb_vga_remove,
> + .driver = {
> + .name = "rgb-to-vga-bridge",
> + .of_match_table = dumb_vga_match,
> + },
> +};
> +module_platform_driver(dumb_vga_driver);
> +
> +MODULE_AUTHOR("Maxime Ripard <maxime.ripard@free-electrons.com>");
> +MODULE_DESCRIPTION("Dumb RGB to VGA bridge driver");
> +MODULE_LICENSE("GPL");
--
Regards,
Laurent Pinchart
^ permalink raw reply
* [PATCH v6 2/3] ARM: dts: add TOPEET itop elite based board
From: ayaka @ 2016-09-18 9:46 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1e4335db-9004-bb7c-6dc1-e435e66b8126@osg.samsung.com>
On 09/17/2016 02:09 AM, Javier Martinez Canillas wrote:
> Hello Randy,
>
> On 09/16/2016 01:21 PM, Krzysztof Kozlowski wrote:
>
> [snip]
>
>>>>> +
>>>>> + beep {
>>>>> + compatible = "pwm-beeper";
>>>>> + pwms = <&pwm 0 4000000 PWM_POLARITY_INVERTED>;
>>>> I have serious doubts that you run this code... if it does not even
>>>> compile. Sorry, I cannot accept code that does not compile and was not
>>>> tested.
>>>>
>>>> Please, test your DTS on top of current Linux tree, which would be one of:
>>>> 1. Linus' master branch: v4.8-rc6,
>>>> 2. one of my branches (for-next, next/dt etc),
>>> When I sent those patches, I tested in "Add linux-next specific files for
>>> 20160907"
>> OK, good, but please tell me why kbuild reported that build error?
>>
> I agree with Krzysztof, it doesn't seem that you tested the exact version
I am sure I does.
> that was posted. You will need the following change to make the DTS build
> in latest linux-next:
I didn't post the patch is WIP, which would adding the LCD panel support
to this board.
>
> diff --git a/arch/arm/boot/dts/exynos4412-itop-elite.dts b/arch/arm/boot/dts/exynos4412-itop-elite.dts
> index dd83689892ff..8559f891a740 100644
> --- a/arch/arm/boot/dts/exynos4412-itop-elite.dts
> +++ b/arch/arm/boot/dts/exynos4412-itop-elite.dts
> @@ -14,6 +14,7 @@
> */
>
> /dts-v1/;
> +#include <dt-bindings/pwm/pwm.h>
> #include <dt-bindings/sound/samsung-i2s.h>
> #include "exynos4412-itop-scp-core.dtsi"
>
> So please squash that change and resend.
I would, but I meet a problem in memory with the latest next-20160916,
it seems that it can't access the memory while it never happened before.
MMC read: dev # 1, block # 2048, count 14336 ...14336 blocks read:
OK [58/426]
Boot with zImage
Starting kernel ...
Uncompressing Linux... done, booting the kernel.
[ 0.000000] Booting Linux on physical CPU 0xa00
[ 0.000000] Linux version 4.8.0-rc6-next-20160916-00004-gae92137
(ayaka at ritsuko) (gcc version 6.1.0 (Buildroot 2016.05-00006-g0
792d0d-dirty) ) #83 SMP PREEMPT Sun Sep 18 17:29:56 CST 2016
[ 0.000000] CPU: ARMv7 Processor [413fc090] revision 0 (ARMv7),
cr=10c5387d
[ 0.000000] CPU: PIPT / VIPT nonaliasing data cache, VIPT aliasing
instruction cache
[ 0.000000] OF: fdt:Machine model: TOPEET iTop 4412 Elite board based
on Exynos4412
[ 0.000000] bootconsole [earlycon0] enabled
[ 0.000000] OF: reserved mem: failed to allocate memory for node
'region_mfc_right'
[ 0.000000] OF: reserved mem: failed to allocate memory for node
'region_mfc_left'
[ 0.000000] cma: Failed to reserve 32 MiB
[ 0.000000] Memory policy: Data cache writealloc
[ 0.000000] Kernel panic - not syncing: ERROR: Failed to allocate
0x2000 bytes below 0x0.
[ 0.000000]
[ 0.000000] CPU: 0 PID: 0 Comm: swapper Not tainted
4.8.0-rc6-next-20160916-00004-gae92137 #83
[ 0.000000] Hardware name: SAMSUNG EXYNOS (Flattened Device Tree)
[ 0.000000] [<c010e17c>] (unwind_backtrace) from [<c010af78>]
(show_stack+0x10/0x14)
[ 0.000000] [<c010af78>] (show_stack) from [<c03080e4>]
(dump_stack+0x70/0x8c)
[ 0.000000] [<c03080e4>] (dump_stack) from [<c019e580>]
(panic+0xc4/0x244)
[ 0.000000] [<c019e580>] (panic) from [<c0810e3c>]
(memblock_alloc_base+0x2c/0x38)
[ 0.000000] [<c0810e3c>] (memblock_alloc_base) from [<c0806aec>]
(early_alloc_aligned+0xc/0x2c)
[ 0.000000] [<c0806aec>] (early_alloc_aligned) from [<c08074c8>]
(paging_init+0x548/0xa70)
[ 0.000000] [<c08074c8>] (paging_init) from [<c0803dc8>]
(setup_arch+0x50c/0xa28)
[ 0.000000] [<c0803dc8>] (setup_arch) from [<c080091c>]
(start_kernel+0x50/0x384)
[ 0.000000] [<c080091c>] (start_kernel) from [<4000807c>] (0x4000807c)
[ 0.000000] ---[ end Kernel panic - not syncing: ERROR: Failed to
allocate 0x2000 bytes below 0x0.
[ 0.000000
>
> Best regards,
^ permalink raw reply
* [RFC PATCH 00/10] ARM: dts: exynos: Fix invalid GIC interrupt flags
From: Marc Zyngier @ 2016-09-18 9:34 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20160917175553.GA9499@kozik-lap>
On Sat, 17 Sep 2016 19:55:53 +0200
Krzysztof Kozlowski <krzk@kernel.org> wrote:
> On Sat, Sep 17, 2016 at 11:05:39PM +0530, Alim Akhtar wrote:
> > Hi Krzysztof,
> >
> > On Sat, Sep 17, 2016 at 1:12 AM, Krzysztof Kozlowski <krzk@kernel.org> wrote:
> > > Hi,
> > >
> > > Marek (internally), Geert and Alban reported errors like:
> > > genirq: Setting trigger mode 0 for irq 16 failed (gic_set_type+0x0/0x68)
> > > The patchset fixes this issue.
> > >
> > > Tested on:
> > > 1. Exynos4412: Odroid U3,
> > > 2. Exynos5410: Odroid XU,
> > > 3. Exynos5422: Odroid XU3.
> > >
> >
> > Tested on Exynos5800 based peach-pi board, so fpr patch 06/10
> >
> > Tested-by: Alim Akhtar <alim.akhtar@samsung.com>
> >
> >
> > > Other platforms not tested so testing would be highly appreciated.
> > >
> > > Best regards,
> > > Krzysztof
> > >
> > > Krzysztof Kozlowski (10):
> > > ARM: dts: exynos: Fix invalid GIC interrupt flags in exynos4
> > > ARM: dts: exynos: Fix invalid GIC interrupt flags in exynos4210
> > > ARM: dts: exynos: Fix invalid GIC interrupt flags in exynos4x12
> > > ARM: dts: exynos: Fix invalid GIC interrupt flags in exynos4415
> > > ARM: dts: exynos: Fix invalid GIC interrupt flags in exynos3250
> > > ARM: dts: exynos: Fix invalid GIC interrupt flags in exynos5
> > > ARM: dts: exynos: Fix invalid GIC interrupt flags in exynos5250
> > > ARM: dts: exynos: Fix invalid GIC interrupt flags in
> > > exynos5410/exynos542x
> > > ARM: dts: exynos: Fix invalid GIC interrupt flags in exynos5260
> > > ARM: dts: exynos: Fix invalid GIC interrupt flags in exynos5440
> > >
> >
> > In general these patches looks good, feel free to add my review-by tag
> > for this series.
> >
> > Reviewed-by: Alim Akhtar <alim.akhtar@samsung.com>
> >
>
> Thanks, I'll add your reviewed-by to all patches.
There is a couple of things that I don't like about these patches:
- Are you sure that all your interrupts are level? I appreciate that's
a very common setting, but you seem to have simply decided that there
wasn't any edge interrupt. Is that a "Let's see what breaks"
situation? If so, It'd be good to state it.
- You've used the IRQ_TYPE_LEVEL_HIGH macro everywhere, but didn't use
the GIC_SPI macro as the first argument of each interrupt specifier.
I'm by no mean a fan of these macros, but you should at least have
some consistency inside an interrupt specifier.
Thanks,
M.
--
Jazz is not dead. It just smells funny.
^ permalink raw reply
* [PATCH 5/6] arm/arm64: vgic-new: Implement VGICv3 CPU interface access
From: Marc Zyngier @ 2016-09-18 9:27 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CALicx6vp-0igFshdSvdoeSBvVg-+E_WWyYf0z=9A278sAs2sKQ@mail.gmail.com>
On Sun, 18 Sep 2016 12:00:01 +0530
Vijay Kilari <vijay.kilari@gmail.com> wrote:
> Hi Marc,
>
> On Fri, Sep 16, 2016 at 10:37 PM, Marc Zyngier <marc.zyngier@arm.com> wrote:
> > On 16/09/16 17:57, Vijay Kilari wrote:
> >> On Fri, Sep 16, 2016 at 8:06 PM, Marc Zyngier <marc.zyngier@arm.com> wrote:
> >>> On 16/09/16 13:20, vijay.kilari at gmail.com wrote:
> >>>> From: Vijaya Kumar K <Vijaya.Kumar@cavium.com>
> >>>>
> >>>> VGICv3 CPU interface registers are accessed using
> >>>> KVM_DEV_ARM_VGIC_CPU_SYSREGS ioctl. These registers are accessed
> >>>> as 64-bit. The cpu MPIDR value is passed along with register id.
> >>>> is used to identify the cpu for registers access.
> >>>>
> >>>> The version of VGIC v3 specification is define here
> >>>> http://lists.infradead.org/pipermail/linux-arm-kernel/2016-July/445611.html
> >>>>
> >>>> Signed-off-by: Pavel Fedin <p.fedin@samsung.com>
> >>>> Signed-off-by: Vijaya Kumar K <Vijaya.Kumar@cavium.com>
> >>>> ---
> >>>> arch/arm64/include/uapi/asm/kvm.h | 3 +
> >>>> arch/arm64/kvm/Makefile | 1 +
> >>>> include/linux/irqchip/arm-gic-v3.h | 30 ++++
> >>>> virt/kvm/arm/vgic/vgic-kvm-device.c | 27 ++++
> >>>> virt/kvm/arm/vgic/vgic-mmio-v3.c | 18 +++
> >>>> virt/kvm/arm/vgic/vgic-sys-reg-v3.c | 296 ++++++++++++++++++++++++++++++++++++
> >>>> virt/kvm/arm/vgic/vgic.h | 10 ++
> >>>> 7 files changed, 385 insertions(+)
> >
> > [...]
> >
> >>>> diff --git a/virt/kvm/arm/vgic/vgic-sys-reg-v3.c b/virt/kvm/arm/vgic/vgic-sys-reg-v3.c
> >>>> new file mode 100644
> >>>> index 0000000..8e4f403
> >>>> --- /dev/null
> >>>> +++ b/virt/kvm/arm/vgic/vgic-sys-reg-v3.c
> >>>> @@ -0,0 +1,296 @@
> >>>> +#include <linux/irqchip/arm-gic-v3.h>
> >>>> +#include <linux/kvm.h>
> >>>> +#include <linux/kvm_host.h>
> >>>> +#include <kvm/iodev.h>
> >>>> +#include <kvm/arm_vgic.h>
> >>>> +#include <asm/kvm_emulate.h>
> >>>> +#include <asm/kvm_arm.h>
> >>>> +#include <asm/kvm_mmu.h>
> >>>> +
> >>>> +#include "vgic.h"
> >>>> +#include "vgic-mmio.h"
> >>>> +#include "sys_regs.h"
> >>>> +
> >>>> +static bool access_gic_ctlr(struct kvm_vcpu *vcpu, struct sys_reg_params *p,
> >>>> + const struct sys_reg_desc *r)
> >>>> +{
> >>>> + struct vgic_vmcr vmcr;
> >>>> + u64 val;
> >>>> + u32 ich_vtr;
> >>>> +
> >>>> + vgic_get_vmcr(vcpu, &vmcr);
> >>>> + if (p->is_write) {
> >>>> + val = p->regval;
> >>>> + vmcr.ctlr &= ~(ICH_VMCR_CBPR_MASK | ICH_VMCR_EOIM_MASK);
> >>>> + vmcr.ctlr |= ((val & ICC_CTLR_EL1_CBPR_MASK) >>
> >>>> + ICC_CTLR_EL1_CBPR_SHIFT) << ICH_VMCR_CBPR_SHIFT;
> >>>> + vmcr.ctlr |= ((val & ICC_CTLR_EL1_EOImode_MASK) >>
> >>>> + ICC_CTLR_EL1_EOImode_SHIFT) << ICH_VMCR_EOIM_SHIFT;
> >>>> + vgic_set_vmcr(vcpu, &vmcr);
> >>>
> >>> You've ignored my comments again: "What if userspace writes something
> >>> that is incompatible with the current configuration? Wrong number of ID
> >>> bits, or number of priorities?"
> >>
> >> IMO, In case of incompatibility,
> >> If ID bits and PRI bits are less than HW supported, it is ok.
> >
> > Yes. But you also need to track of what the guest has programmed in
> > order to be able to migrate it back to its original configuration.
> >
> >> If ID bits and PRI bits are greater than HW supported, then warn would be good
> >> enough. Please suggest the behaviour that you think it should be.
> >
> > No, it is an error, plain and simple. You cannot run in this condition.
> >
> >>
> >>>
> >>>> + } else {
> >>>> + ich_vtr = kvm_call_hyp(__vgic_v3_get_ich_vtr_el2);
> >>>> +
> >>>> + val = 0;
> >>>> + val |= ((ich_vtr & ICH_VTR_PRI_BITS_MASK) >>
> >>>> + ICH_VTR_PRI_BITS_SHIFT) << ICC_CTLR_EL1_PRI_BITS_SHIFT;
> >>>> + val |= ((ich_vtr & ICH_VTR_ID_BITS_MASK) >>
> >>>> + ICH_VTR_ID_BITS_SHIFT) << ICC_CTLR_EL1_ID_BITS_SHIFT;
> >>>> + val |= ((ich_vtr & ICH_VTR_SEIS_MASK) >> ICH_VTR_SEIS_SHIFT)
> >>>> + << ICC_CTLR_EL1_SEIS_SHIFT;
> >>>> + val |= ((ich_vtr & ICH_VTR_A3V_MASK) >> ICH_VTR_A3V_SHIFT)
> >>>> + << ICC_CTLR_EL1_A3V_SHIFT;
> >>>> + val |= ((vmcr.ctlr & ICH_VMCR_CBPR_MASK) >>
> >>>> + ICH_VMCR_CBPR_SHIFT) << ICC_CTLR_EL1_CBPR_SHIFT;
> >>>> + val |= ((vmcr.ctlr & ICH_VMCR_EOIM_MASK) >>
> >>>> + ICH_VMCR_EOIM_SHIFT) << ICC_CTLR_EL1_EOImode_SHIFT;
> >>>> +
> >>>> + p->regval = val;
> >>>> + }
> >>>> +
> >>>> + return true;
> >>>> +}
> >>>> +
> >>>> +static bool access_gic_pmr(struct kvm_vcpu *vcpu, struct sys_reg_params *p,
> >>>> + const struct sys_reg_desc *r)
> >>>> +{
> >>>> + struct vgic_vmcr vmcr;
> >>>> +
> >>>> + vgic_get_vmcr(vcpu, &vmcr);
> >>>> + if (p->is_write) {
> >>>> + vmcr.pmr = (p->regval & ICC_PMR_EL1_MASK) >> ICC_PMR_EL1_SHIFT;
> >>>> + vgic_set_vmcr(vcpu, &vmcr);
> >>>> + } else {
> >>>> + p->regval = (vmcr.pmr << ICC_PMR_EL1_SHIFT) & ICC_PMR_EL1_MASK;
> >>>> + }
> >>>> +
> >>>> + return true;
> >>>> +}
> >>>> +
> >>>> +static bool access_gic_bpr0(struct kvm_vcpu *vcpu, struct sys_reg_params *p,
> >>>> + const struct sys_reg_desc *r)
> >>>> +{
> >>>> + struct vgic_vmcr vmcr;
> >>>> +
> >>>> + vgic_get_vmcr(vcpu, &vmcr);
> >>>> + if (p->is_write) {
> >>>> + vmcr.bpr = (p->regval & ICC_BPR0_EL1_MASK) >>
> >>>> + ICC_BPR0_EL1_SHIFT;
> >>>> + vgic_set_vmcr(vcpu, &vmcr);
> >>>> + } else {
> >>>> + p->regval = (vmcr.bpr << ICC_BPR0_EL1_SHIFT) &
> >>>> + ICC_BPR0_EL1_MASK;
> >>>> + }
> >>>> +
> >>>> + return true;
> >>>> +}
> >>>> +
> >>>> +static bool access_gic_bpr1(struct kvm_vcpu *vcpu, struct sys_reg_params *p,
> >>>> + const struct sys_reg_desc *r)
> >>>> +{
> >>>> + struct vgic_vmcr vmcr;
> >>>> +
> >>>> + vgic_get_vmcr(vcpu, &vmcr);
> >>>> + if (p->is_write) {
> >>>> + vmcr.abpr = (p->regval & ICC_BPR1_EL1_MASK) >>
> >>>> + ICC_BPR1_EL1_SHIFT;
> >>>> + vgic_set_vmcr(vcpu, &vmcr);
> >>>> + } else {
> >>>> + p->regval = (vmcr.abpr << ICC_BPR1_EL1_SHIFT) &
> >>>> + ICC_BPR1_EL1_MASK;
> >>>> + }
> >>>> +
> >>>> + return true;
> >>>> +}
> >>>> +
> >>>> +static bool access_gic_grpen0(struct kvm_vcpu *vcpu, struct sys_reg_params *p,
> >>>> + const struct sys_reg_desc *r)
> >>>> +{
> >>>> + struct vgic_vmcr vmcr;
> >>>> +
> >>>> + vgic_get_vmcr(vcpu, &vmcr);
> >>>> + if (p->is_write) {
> >>>> + vmcr.grpen0 = (p->regval & ICC_IGRPEN0_EL1_MASK) >>
> >>>> + ICC_IGRPEN0_EL1_SHIFT;
> >>>> + vgic_set_vmcr(vcpu, &vmcr);
> >>>> + } else {
> >>>> + p->regval = (vmcr.grpen0 << ICC_IGRPEN0_EL1_SHIFT) &
> >>>> + ICC_IGRPEN0_EL1_MASK;
> >>>> + }
> >>>> +
> >>>> + return true;
> >>>> +}
> >>>> +
> >>>> +static bool access_gic_grpen1(struct kvm_vcpu *vcpu, struct sys_reg_params *p,
> >>>> + const struct sys_reg_desc *r)
> >>>> +{
> >>>> + struct vgic_vmcr vmcr;
> >>>> +
> >>>> + vgic_get_vmcr(vcpu, &vmcr);
> >>>> + if (p->is_write) {
> >>>> + vmcr.grpen1 = (p->regval & ICC_IGRPEN1_EL1_MASK) >>
> >>>> + ICC_IGRPEN1_EL1_SHIFT;
> >>>> + vgic_set_vmcr(vcpu, &vmcr);
> >>>> + } else {
> >>>> + p->regval = (vmcr.grpen1 << ICC_IGRPEN1_EL1_SHIFT) &
> >>>> + ICC_IGRPEN1_EL1_MASK;
> >>>
> >>> From the previous review comments: "Shouldn't this account for the
> >>> ICC_CTLR_EL1.CBPR setting?"
> >>
> >> Ok. I think this comment is for ICC_BPR1_EL1 access.
> >
> > Yes, sorry about the misplaced comment.
> >
> >> I will make a check on ICC_CTLR.EL1.CBPR for accessing ICC_BPR1_EL1.
> >
> > The reverse is also true: you also need to account the value of
> > ICC_BPR1_EL1 when accessing ICC_CTLR_EL1.
> >
>
> ICC_CTLR_EL1 reg does not hold BPR1 value to account value of ICC_BPR1_EL1.
Oh please. What do you think ICC_CTLR_EL1.CPBR is for? It ties
ICC_BPR1_EL1 to ICC_BPR0_EL1. So if you have the following sequence:
Set ICC_BPR0_EL1 to p0
Set ICC_BPR1_EL1 to p1
Set ICC_CTLR_EL1.CBPR to 1
you must ensure that ICC_BPR1_EL1 is now min(p0 + 1, 7), no matter what
p1 is. ICC_CTLR_EL1 may not hold the BPR1 value, but it directly
controls it.
Effectively, you must always consider BPR0, BPR1 and CBPR together.
Please read the architecture spec, it is one of the few things that are
easy actually to understand.
M.
--
Jazz is not dead. It just smells funny.
^ permalink raw reply
* [RFC PATCH 00/10] ARM: dts: exynos: Fix invalid GIC interrupt flags
From: Geert Uytterhoeven @ 2016-09-18 8:49 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1474054971-16831-1-git-send-email-krzk@kernel.org>
Hi Krzysztof,
On Fri, Sep 16, 2016 at 9:42 PM, Krzysztof Kozlowski <krzk@kernel.org> wrote:
> Marek (internally), Geert and Alban reported errors like:
> genirq: Setting trigger mode 0 for irq 16 failed (gic_set_type+0x0/0x68)
I didn't report these on Exynos, though, so I think you should drop my
Reported-by.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert at linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply
* [PATCH] dmaengine: sun6i: Add support for Allwinner A83T (sun8i) variant
From: Jean-Francois Moine @ 2016-09-18 7:59 UTC (permalink / raw)
To: linux-arm-kernel
The A83T SoC has the same dma engine as the A31 (sun6i), with a reduced
amount of endpoints and physical channels.
Signed-off-by: Jean-Francois Moine <moinejf@free.fr>
---
Documentation/devicetree/bindings/dma/sun6i-dma.txt | 1 +
drivers/dma/sun6i-dma.c | 7 +++++++
2 files changed, 8 insertions(+)
diff --git a/Documentation/devicetree/bindings/dma/sun6i-dma.txt b/Documentation/devicetree/bindings/dma/sun6i-dma.txt
index d13c136..6b26704 100644
--- a/Documentation/devicetree/bindings/dma/sun6i-dma.txt
+++ b/Documentation/devicetree/bindings/dma/sun6i-dma.txt
@@ -7,6 +7,7 @@ Required properties:
- compatible: Must be one of
"allwinner,sun6i-a31-dma"
"allwinner,sun8i-a23-dma"
+ "allwinner,sun8i-a83t-dma"
"allwinner,sun8i-h3-dma"
- reg: Should contain the registers base address and length
- interrupts: Should contain a reference to the interrupt used by this device
diff --git a/drivers/dma/sun6i-dma.c b/drivers/dma/sun6i-dma.c
index 3835fcd..8346199 100644
--- a/drivers/dma/sun6i-dma.c
+++ b/drivers/dma/sun6i-dma.c
@@ -1011,6 +1011,12 @@ static struct sun6i_dma_config sun8i_a23_dma_cfg = {
.nr_max_vchans = 37,
};
+static struct sun6i_dma_config sun8i_a83t_dma_cfg = {
+ .nr_max_channels = 8,
+ .nr_max_requests = 28,
+ .nr_max_vchans = 39,
+};
+
/*
* The H3 has 12 physical channels, a maximum DRQ port id of 27,
* and a total of 34 usable source and destination endpoints.
@@ -1025,6 +1031,7 @@ static struct sun6i_dma_config sun8i_h3_dma_cfg = {
static const struct of_device_id sun6i_dma_match[] = {
{ .compatible = "allwinner,sun6i-a31-dma", .data = &sun6i_a31_dma_cfg },
{ .compatible = "allwinner,sun8i-a23-dma", .data = &sun8i_a23_dma_cfg },
+ { .compatible = "allwinner,sun8i-a83t-dma", .data = &sun8i_a83t_dma_cfg },
{ .compatible = "allwinner,sun8i-h3-dma", .data = &sun8i_h3_dma_cfg },
{ /* sentinel */ }
};
--
2.10.0
^ permalink raw reply related
* [PATCH 5/6] arm/arm64: vgic-new: Implement VGICv3 CPU interface access
From: Vijay Kilari @ 2016-09-18 6:30 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <57DC26C5.2060800@arm.com>
Hi Marc,
On Fri, Sep 16, 2016 at 10:37 PM, Marc Zyngier <marc.zyngier@arm.com> wrote:
> On 16/09/16 17:57, Vijay Kilari wrote:
>> On Fri, Sep 16, 2016 at 8:06 PM, Marc Zyngier <marc.zyngier@arm.com> wrote:
>>> On 16/09/16 13:20, vijay.kilari at gmail.com wrote:
>>>> From: Vijaya Kumar K <Vijaya.Kumar@cavium.com>
>>>>
>>>> VGICv3 CPU interface registers are accessed using
>>>> KVM_DEV_ARM_VGIC_CPU_SYSREGS ioctl. These registers are accessed
>>>> as 64-bit. The cpu MPIDR value is passed along with register id.
>>>> is used to identify the cpu for registers access.
>>>>
>>>> The version of VGIC v3 specification is define here
>>>> http://lists.infradead.org/pipermail/linux-arm-kernel/2016-July/445611.html
>>>>
>>>> Signed-off-by: Pavel Fedin <p.fedin@samsung.com>
>>>> Signed-off-by: Vijaya Kumar K <Vijaya.Kumar@cavium.com>
>>>> ---
>>>> arch/arm64/include/uapi/asm/kvm.h | 3 +
>>>> arch/arm64/kvm/Makefile | 1 +
>>>> include/linux/irqchip/arm-gic-v3.h | 30 ++++
>>>> virt/kvm/arm/vgic/vgic-kvm-device.c | 27 ++++
>>>> virt/kvm/arm/vgic/vgic-mmio-v3.c | 18 +++
>>>> virt/kvm/arm/vgic/vgic-sys-reg-v3.c | 296 ++++++++++++++++++++++++++++++++++++
>>>> virt/kvm/arm/vgic/vgic.h | 10 ++
>>>> 7 files changed, 385 insertions(+)
>
> [...]
>
>>>> diff --git a/virt/kvm/arm/vgic/vgic-sys-reg-v3.c b/virt/kvm/arm/vgic/vgic-sys-reg-v3.c
>>>> new file mode 100644
>>>> index 0000000..8e4f403
>>>> --- /dev/null
>>>> +++ b/virt/kvm/arm/vgic/vgic-sys-reg-v3.c
>>>> @@ -0,0 +1,296 @@
>>>> +#include <linux/irqchip/arm-gic-v3.h>
>>>> +#include <linux/kvm.h>
>>>> +#include <linux/kvm_host.h>
>>>> +#include <kvm/iodev.h>
>>>> +#include <kvm/arm_vgic.h>
>>>> +#include <asm/kvm_emulate.h>
>>>> +#include <asm/kvm_arm.h>
>>>> +#include <asm/kvm_mmu.h>
>>>> +
>>>> +#include "vgic.h"
>>>> +#include "vgic-mmio.h"
>>>> +#include "sys_regs.h"
>>>> +
>>>> +static bool access_gic_ctlr(struct kvm_vcpu *vcpu, struct sys_reg_params *p,
>>>> + const struct sys_reg_desc *r)
>>>> +{
>>>> + struct vgic_vmcr vmcr;
>>>> + u64 val;
>>>> + u32 ich_vtr;
>>>> +
>>>> + vgic_get_vmcr(vcpu, &vmcr);
>>>> + if (p->is_write) {
>>>> + val = p->regval;
>>>> + vmcr.ctlr &= ~(ICH_VMCR_CBPR_MASK | ICH_VMCR_EOIM_MASK);
>>>> + vmcr.ctlr |= ((val & ICC_CTLR_EL1_CBPR_MASK) >>
>>>> + ICC_CTLR_EL1_CBPR_SHIFT) << ICH_VMCR_CBPR_SHIFT;
>>>> + vmcr.ctlr |= ((val & ICC_CTLR_EL1_EOImode_MASK) >>
>>>> + ICC_CTLR_EL1_EOImode_SHIFT) << ICH_VMCR_EOIM_SHIFT;
>>>> + vgic_set_vmcr(vcpu, &vmcr);
>>>
>>> You've ignored my comments again: "What if userspace writes something
>>> that is incompatible with the current configuration? Wrong number of ID
>>> bits, or number of priorities?"
>>
>> IMO, In case of incompatibility,
>> If ID bits and PRI bits are less than HW supported, it is ok.
>
> Yes. But you also need to track of what the guest has programmed in
> order to be able to migrate it back to its original configuration.
>
>> If ID bits and PRI bits are greater than HW supported, then warn would be good
>> enough. Please suggest the behaviour that you think it should be.
>
> No, it is an error, plain and simple. You cannot run in this condition.
>
>>
>>>
>>>> + } else {
>>>> + ich_vtr = kvm_call_hyp(__vgic_v3_get_ich_vtr_el2);
>>>> +
>>>> + val = 0;
>>>> + val |= ((ich_vtr & ICH_VTR_PRI_BITS_MASK) >>
>>>> + ICH_VTR_PRI_BITS_SHIFT) << ICC_CTLR_EL1_PRI_BITS_SHIFT;
>>>> + val |= ((ich_vtr & ICH_VTR_ID_BITS_MASK) >>
>>>> + ICH_VTR_ID_BITS_SHIFT) << ICC_CTLR_EL1_ID_BITS_SHIFT;
>>>> + val |= ((ich_vtr & ICH_VTR_SEIS_MASK) >> ICH_VTR_SEIS_SHIFT)
>>>> + << ICC_CTLR_EL1_SEIS_SHIFT;
>>>> + val |= ((ich_vtr & ICH_VTR_A3V_MASK) >> ICH_VTR_A3V_SHIFT)
>>>> + << ICC_CTLR_EL1_A3V_SHIFT;
>>>> + val |= ((vmcr.ctlr & ICH_VMCR_CBPR_MASK) >>
>>>> + ICH_VMCR_CBPR_SHIFT) << ICC_CTLR_EL1_CBPR_SHIFT;
>>>> + val |= ((vmcr.ctlr & ICH_VMCR_EOIM_MASK) >>
>>>> + ICH_VMCR_EOIM_SHIFT) << ICC_CTLR_EL1_EOImode_SHIFT;
>>>> +
>>>> + p->regval = val;
>>>> + }
>>>> +
>>>> + return true;
>>>> +}
>>>> +
>>>> +static bool access_gic_pmr(struct kvm_vcpu *vcpu, struct sys_reg_params *p,
>>>> + const struct sys_reg_desc *r)
>>>> +{
>>>> + struct vgic_vmcr vmcr;
>>>> +
>>>> + vgic_get_vmcr(vcpu, &vmcr);
>>>> + if (p->is_write) {
>>>> + vmcr.pmr = (p->regval & ICC_PMR_EL1_MASK) >> ICC_PMR_EL1_SHIFT;
>>>> + vgic_set_vmcr(vcpu, &vmcr);
>>>> + } else {
>>>> + p->regval = (vmcr.pmr << ICC_PMR_EL1_SHIFT) & ICC_PMR_EL1_MASK;
>>>> + }
>>>> +
>>>> + return true;
>>>> +}
>>>> +
>>>> +static bool access_gic_bpr0(struct kvm_vcpu *vcpu, struct sys_reg_params *p,
>>>> + const struct sys_reg_desc *r)
>>>> +{
>>>> + struct vgic_vmcr vmcr;
>>>> +
>>>> + vgic_get_vmcr(vcpu, &vmcr);
>>>> + if (p->is_write) {
>>>> + vmcr.bpr = (p->regval & ICC_BPR0_EL1_MASK) >>
>>>> + ICC_BPR0_EL1_SHIFT;
>>>> + vgic_set_vmcr(vcpu, &vmcr);
>>>> + } else {
>>>> + p->regval = (vmcr.bpr << ICC_BPR0_EL1_SHIFT) &
>>>> + ICC_BPR0_EL1_MASK;
>>>> + }
>>>> +
>>>> + return true;
>>>> +}
>>>> +
>>>> +static bool access_gic_bpr1(struct kvm_vcpu *vcpu, struct sys_reg_params *p,
>>>> + const struct sys_reg_desc *r)
>>>> +{
>>>> + struct vgic_vmcr vmcr;
>>>> +
>>>> + vgic_get_vmcr(vcpu, &vmcr);
>>>> + if (p->is_write) {
>>>> + vmcr.abpr = (p->regval & ICC_BPR1_EL1_MASK) >>
>>>> + ICC_BPR1_EL1_SHIFT;
>>>> + vgic_set_vmcr(vcpu, &vmcr);
>>>> + } else {
>>>> + p->regval = (vmcr.abpr << ICC_BPR1_EL1_SHIFT) &
>>>> + ICC_BPR1_EL1_MASK;
>>>> + }
>>>> +
>>>> + return true;
>>>> +}
>>>> +
>>>> +static bool access_gic_grpen0(struct kvm_vcpu *vcpu, struct sys_reg_params *p,
>>>> + const struct sys_reg_desc *r)
>>>> +{
>>>> + struct vgic_vmcr vmcr;
>>>> +
>>>> + vgic_get_vmcr(vcpu, &vmcr);
>>>> + if (p->is_write) {
>>>> + vmcr.grpen0 = (p->regval & ICC_IGRPEN0_EL1_MASK) >>
>>>> + ICC_IGRPEN0_EL1_SHIFT;
>>>> + vgic_set_vmcr(vcpu, &vmcr);
>>>> + } else {
>>>> + p->regval = (vmcr.grpen0 << ICC_IGRPEN0_EL1_SHIFT) &
>>>> + ICC_IGRPEN0_EL1_MASK;
>>>> + }
>>>> +
>>>> + return true;
>>>> +}
>>>> +
>>>> +static bool access_gic_grpen1(struct kvm_vcpu *vcpu, struct sys_reg_params *p,
>>>> + const struct sys_reg_desc *r)
>>>> +{
>>>> + struct vgic_vmcr vmcr;
>>>> +
>>>> + vgic_get_vmcr(vcpu, &vmcr);
>>>> + if (p->is_write) {
>>>> + vmcr.grpen1 = (p->regval & ICC_IGRPEN1_EL1_MASK) >>
>>>> + ICC_IGRPEN1_EL1_SHIFT;
>>>> + vgic_set_vmcr(vcpu, &vmcr);
>>>> + } else {
>>>> + p->regval = (vmcr.grpen1 << ICC_IGRPEN1_EL1_SHIFT) &
>>>> + ICC_IGRPEN1_EL1_MASK;
>>>
>>> From the previous review comments: "Shouldn't this account for the
>>> ICC_CTLR_EL1.CBPR setting?"
>>
>> Ok. I think this comment is for ICC_BPR1_EL1 access.
>
> Yes, sorry about the misplaced comment.
>
>> I will make a check on ICC_CTLR.EL1.CBPR for accessing ICC_BPR1_EL1.
>
> The reverse is also true: you also need to account the value of
> ICC_BPR1_EL1 when accessing ICC_CTLR_EL1.
>
ICC_CTLR_EL1 reg does not hold BPR1 value to account value of ICC_BPR1_EL1.
Regards
Vijay
^ permalink raw reply
* [PATCH 2/8] drm/rockchip: Get rid of some unnecessary code
From: Tomasz Figa @ 2016-09-18 4:01 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <57DDF2EE.5060807@rock-chips.com>
Hi Mark,
On Sun, Sep 18, 2016 at 10:50 AM, Mark yao <mark.yao@rock-chips.com> wrote:
> On 2016?09?14? 20:54, Tomasz Figa wrote:
>>
>> Current code implements prepare_fb and cleanup_fb callbacks only to
>> grab/release fb references, which is already done by atomic framework
>> when creating/destryoing plane state. Let's remove these
>> unused bits.
>>
>> Signed-off-by: Tomasz Figa <tfiga@chromium.org>
>> ---
>> drivers/gpu/drm/rockchip/rockchip_drm_vop.c | 18 ------------------
>> 1 file changed, 18 deletions(-)
>
>
> Hi Tomasz
>
> I think we can't get rid of the prepare_fb and cleanup_fb
I think I have to disagree. Please see below for detailed explanation.
>
> see the reason:
> commit 44d0237a26395ac94160cf23f32769013b365590
> Author: Mark Yao <mark.yao@rock-chips.com>
> Date: Fri Apr 29 11:37:20 2016 +0800
>
> drm/rockchip: vop: fix iommu crash with async atomic
>
> After async atomic_commit callback, drm_atomic_clean_old_fb will
> clean all old fb, but because async, the old fb may be also on
> the vop hardware, dma will access the old fb buffer, clean old
> fb will cause iommu page fault.
I think the above is not quite right. Atomic plane state holds a
reference to its fb and old state is not supposed to be destroyed
until the flip completes.
Indeed current rockchip_atomic_commit implementation has following
order of calls: rockchip_atomic_wait_for_complete(),
drm_atomic_helper_cleanup_planes(), drm_atomic_state_free(). This
means that .cleanup_fb() is called from
drm_atomic_helper_cleanup_planes() just before drm_atomic_state_free()
will release references by destroying old plane states. Note that both
are called already after rockchip_atomic_wait_for_complete(), so it
should be already safe to free the old fbs.
So the above fix doesn't really do anything, possibly just covers the
race condition of the original wait for vblank function by delaying
drm_atomic_state_free() a bit.
Moreover, the whole series has been thoroughly tested in Chrome OS 4.4
kernel, including async commits. (There is still a possibility some
newer upstream changes slightly modified the semantics, but I couldn't
find such difference. Actually one of the advantages of atomic helpers
was to avoid manually refcounting the fbs from the driver.)
Best regards,
Tomasz
^ permalink raw reply
* [PATCH V3 1/4] ARM64 LPC: Indirect ISA port IO introduced
From: zhichang @ 2016-09-18 3:38 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <5264074.nuyDhEuOR4@wuerfel>
Hi, Arnd,
On 2016?09?14? 22:23, Arnd Bergmann wrote:
> On Wednesday, September 14, 2016 10:16:28 PM CEST zhichang.yuan wrote:
>>>
>>> No need to guard includes with an #ifdef.
>> If remove #ifdef here, extio.h should not contain any function external declarations whose definitions are in
>> extio.c compiled only when CONFIG_ARM64_INDIRECT_PIO is yes.
>
> There is no problem with making declarations visible for functions that
> are not part of the kernel, we do that all the time.
>
>>>> +#define BUILDS_RW(bwl, type) \
>>>> +static inline void reads##bwl(const volatile void __iomem *addr, \
>>>> + void *buffer, unsigned int count) \
>>>> +{ \
>>>> + if (count) { \
>>>> + type *buf = buffer; \
>>>> + \
>>>> + do { \
>>>> + type x = __raw_read##bwl(addr); \
>>>> + *buf++ = x; \
>>>> + } while (--count); \
>>>> + } \
>>>> +} \
>>>> + \
>>>> +static inline void writes##bwl(volatile void __iomem *addr, \
>>>> + const void *buffer, unsigned int count) \
>>>> +{ \
>>>> + if (count) { \
>>>> + const type *buf = buffer; \
>>>> + \
>>>> + do { \
>>>> + __raw_write##bwl(*buf++, addr); \
>>>> + } while (--count); \
>>>> + } \
>>>> +}
>>>> +
>>>> +BUILDS_RW(b, u8)
>>>
>>> Why is this in here?
>> the readsb/writesb are defined in asm-generic/io.h which is included later, but the redefined insb/outsb need
>> to call them. Without these readsb/writesb definition before insb/outsb redefined, compile error occur.
>>
>> It seems that copy all the definitions of "asm-generic/io.h" is not a good idea, so I move the definitions of
>> those function needed here....
>>
>> Ok. I think your idea below defining in(s)/out(s) in a c file can solve this issue.
>>
>> #ifdef CONFIG_ARM64_INDIRECT_PIO
>> #define inb inb
>> extern u8 inb(unsigned long addr);
>>
>> #define outb outb
>> extern void outb(u8 value, unsigned long addr);
>>
>> #define insb insb
>> extern void insb(unsigned long addr, void *buffer, unsigned int count);
>>
>> #define outsb outsb
>> extern void outsb(unsigned long addr, const void *buffer, unsigned int count);
>> #endif
>>
>> and definitions of all these functions are in extio.c :
>>
>> u8 inb(unsigned long addr)
>> {
>> if (!arm64_extio_ops || arm64_extio_ops->start > addr ||
>> arm64_extio_ops->end < addr)
>> return readb(PCI_IOBASE + addr);
>> else
>> return arm64_extio_ops->pfin ?
>> arm64_extio_ops->pfin(arm64_extio_ops->devpara,
>> addr + arm64_extio_ops->ptoffset, NULL,
>> sizeof(u8), 1) : -1;
>> }
>> .....
>
> Yes, sounds good.
>
>>>> @@ -149,6 +185,60 @@ static inline u64 __raw_readq(const volatile void __iomem *addr)
>>>> #define IO_SPACE_LIMIT (PCI_IO_SIZE - 1)
>>>> #define PCI_IOBASE ((void __iomem *)PCI_IO_START)
>>>>
>>>> +
>>>> +/*
>>>> + * redefine the in(s)b/out(s)b for indirect-IO.
>>>> + */
>>>> +#define inb inb
>>>> +static inline u8 inb(unsigned long addr)
>>>> +{
>>>> +#ifdef CONFIG_ARM64_INDIRECT_PIO
>>>> + if (arm64_extio_ops && arm64_extio_ops->start <= addr &&
>>>> + addr <= arm64_extio_ops->end)
>>>> + return extio_inb(addr);
>>>> +#endif
>>>> + return readb(PCI_IOBASE + addr);
>>>> +}
>>>> +
>>>
>>> Looks ok, but you only seem to do this for the 8-bit
>>> accessors, when it should be done for 16-bit and 32-bit
>>> ones as well for consistency.
>> Hip06 LPC only support 8-bit I/O operations on the designated port.
>
> That is an interesting limitation. Maybe still call the extio operations
> and have them do WARN_ON_ONCE() instead?
>
> If you get a driver that calls inw/outw on the range that is owned
> by the LPC bus, you otherwise get an unhandled page fault in kernel
> space, which is not as nice.
>
Yes. It probably cause kernel panic.
Will define the extio operations for other IO length and add the corresponding WARNINGS.
Best,
Zhichang
>>>> diff --git a/drivers/bus/extio.c b/drivers/bus/extio.c
>>>> new file mode 100644
>>>> index 0000000..1e7a9c5
>>>> --- /dev/null
>>>> +++ b/drivers/bus/extio.c
>>>> @@ -0,0 +1,66 @@
>>>
>>> This is in a globally visible directory
>>>
>>>> +
>>>> +struct extio_ops *arm64_extio_ops;
>>>
>>> But the identifier uses an architecture specific prefix. Either
>>> move the whole file into arch/arm64, or make the naming so that
>>> it can be used for everything.
>>
>> I perfer to move the whole file into arch/arm64, extio.h will be moved to arch/arm64/include/asm;
>
> Ok, that simplifies it a lot, you can just do everything in asm/io.h then.
>
> Arnd
>
^ permalink raw reply
* [PATCH v5 3/3] pci:aer: add support aer interrupt with none MSI/MSI-X/INTx mode
From: Po Liu @ 2016-09-18 3:37 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20160918005212.GF15478@tiger>
Hi Shawn,
> -----Original Message-----
> From: Shawn Guo [mailto:shawnguo at kernel.org]
> Sent: Sunday, September 18, 2016 8:52 AM
> To: Po Liu
> Cc: linux-pci at vger.kernel.org; linux-arm-kernel at lists.infradead.org;
> linux-kernel at vger.kernel.org; devicetree at vger.kernel.org; Roy Zang; Arnd
> Bergmann; Marc Zyngier; Stuart Yoder; Leo Li; M.H. Lian; Murali
> Karicheri; Bjorn Helgaas; Mingkai Hu
> Subject: Re: [PATCH v5 3/3] pci:aer: add support aer interrupt with none
> MSI/MSI-X/INTx mode
>
> On Tue, Sep 13, 2016 at 12:40:59PM +0800, Po Liu wrote:
> > On some platforms, root port doesn't support MSI/MSI-X/INTx in RC mode.
> > When chip support the aer interrupt with none MSI/MSI-X/INTx mode,
> > maybe there is interrupt line for aer pme etc. Search the interrupt
> > number in the fdt file. Then fixup the dev->irq with it.
> >
> > Signed-off-by: Po Liu <po.liu@nxp.com>
>
> Will the new kernel work with existing/old DTB? I'm trying to
> understand the dependency between driver and DTS changes.
Yes, We've never use name 'intr' before. So we remove it is ok.
'aer' is a dts name for researching it's true interrupt number by kernel. This patch is first time to use name 'aer'. So it must be compatible with existing/old DTB.
>
> Shawn
>
> > ---
> > changes for v5:
> > - Add clear 'aer' interrup-names description
> >
> > .../devicetree/bindings/pci/layerscape-pci.txt | 11 +++++---
> > drivers/pci/pcie/portdrv_core.c | 31
> +++++++++++++++++++---
> > 2 files changed, 35 insertions(+), 7 deletions(-)
> >
> > diff --git a/Documentation/devicetree/bindings/pci/layerscape-pci.txt
> > b/Documentation/devicetree/bindings/pci/layerscape-pci.txt
> > index 41e9f55..101d0a7 100644
> > --- a/Documentation/devicetree/bindings/pci/layerscape-pci.txt
> > +++ b/Documentation/devicetree/bindings/pci/layerscape-pci.txt
> > @@ -18,8 +18,10 @@ Required properties:
> > - reg: base addresses and lengths of the PCIe controller
> > - interrupts: A list of interrupt outputs of the controller. Must
> contain an
> > entry for each entry in the interrupt-names property.
> > -- interrupt-names: Must include the following entries:
> > - "intr": The interrupt that is asserted for controller interrupts
> > +- interrupt-names: It may be include the following entries:
> > + "aer": The interrupt that is asserted for aer interrupt
> > + "pme": The interrupt that is asserted for pme interrupt
> > + ......
> > - fsl,pcie-scfg: Must include two entries.
> > The first entry must be a link to the SCFG device node
> > The second entry must be '0' or '1' based on physical PCIe
> controller index.
> > @@ -35,8 +37,9 @@ Example:
> > reg = <0x00 0x03400000 0x0 0x00010000 /* controller
> registers */
> > 0x40 0x00000000 0x0 0x00002000>; /* configuration
> space */
> > reg-names = "regs", "config";
> > - interrupts = <GIC_SPI 177 IRQ_TYPE_LEVEL_HIGH>; /*
> controller interrupt */
> > - interrupt-names = "intr";
> > + interrupts = <GIC_SPI 176 IRQ_TYPE_LEVEL_HIGH>, /* aer
> interrupt */
> > + <GIC_SPI 177 IRQ_TYPE_LEVEL_HIGH>; /* pme interrupt */
> > + interrupt-names = "aer", "pme";
> > fsl,pcie-scfg = <&scfg 0>;
> > #address-cells = <3>;
> > #size-cells = <2>;
> > diff --git a/drivers/pci/pcie/portdrv_core.c
> > b/drivers/pci/pcie/portdrv_core.c index e9270b4..7c4943d 100644
> > --- a/drivers/pci/pcie/portdrv_core.c
> > +++ b/drivers/pci/pcie/portdrv_core.c
> > @@ -16,6 +16,7 @@
> > #include <linux/slab.h>
> > #include <linux/pcieport_if.h>
> > #include <linux/aer.h>
> > +#include <linux/of_irq.h>
> >
> > #include "../pci.h"
> > #include "portdrv.h"
> > @@ -200,6 +201,28 @@ static int pcie_port_enable_msix(struct pci_dev
> > *dev, int *vectors, int mask) static int init_service_irqs(struct
> > pci_dev *dev, int *irqs, int mask) {
> > int i, irq = -1;
> > + int ret;
> > + struct device_node *np = NULL;
> > +
> > + for (i = 0; i < PCIE_PORT_DEVICE_MAXSERVICES; i++)
> > + irqs[i] = 0;
> > +
> > + if (dev->bus->dev.of_node)
> > + np = dev->bus->dev.of_node;
> > +
> > + /* If root port doesn't support MSI/MSI-X/INTx in RC mode,
> > + * request irq for aer
> > + */
> > + if (IS_ENABLED(CONFIG_OF_IRQ) && np &&
> > + (mask & PCIE_PORT_SERVICE_PME)) {
> > + ret = of_irq_get_byname(np, "aer");
> > + if (ret > 0) {
> > + irqs[PCIE_PORT_SERVICE_AER_SHIFT] = ret;
> > + if (dev->irq)
> > + irq = dev->irq;
> > + goto no_msi;
> > + }
> > + }
> >
> > /*
> > * If MSI cannot be used for PCIe PME or hotplug, we have to use
> @@
> > -225,11 +248,13 @@ static int init_service_irqs(struct pci_dev *dev,
> int *irqs, int mask)
> > irq = dev->irq;
> >
> > no_msi:
> > - for (i = 0; i < PCIE_PORT_DEVICE_MAXSERVICES; i++)
> > - irqs[i] = irq;
> > + for (i = 0; i < PCIE_PORT_DEVICE_MAXSERVICES; i++) {
> > + if (!irqs[i])
> > + irqs[i] = irq;
> > + }
> > irqs[PCIE_PORT_SERVICE_VC_SHIFT] = -1;
> >
> > - if (irq < 0)
> > + if (irq < 0 && irqs[PCIE_PORT_SERVICE_AER_SHIFT] < 0)
> > return -ENODEV;
> > return 0;
> > }
> > --
> > 2.1.0.27.g96db324
> >
> >
> > _______________________________________________
> > linux-arm-kernel mailing list
> > linux-arm-kernel at lists.infradead.org
> > http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [RESEND PATCH v4] thermal: tango: add resume support
From: Zhang Rui @ 2016-09-18 1:58 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <57D96E5E.6070102@sigmadesigns.com>
On ?, 2016-09-14 at 17:35 +0200, Marc Gonzalez wrote:
> On 07/09/2016 10:55, Arnd Bergmann wrote:
>
> >
> > On Wednesday, September 7, 2016 10:30:41 AM CEST Marc Gonzalez
> > wrote:
> >
> > >
> > > When this platform is suspended, firmware powers the entire SoC
> > > down,
> > > except a few hardware blocks waiting for wakeup events. There is
> > > no
> > > context to save for this particular block.
> > >
> > > Therefore, there is nothing useful for the driver to do on
> > > suspend;
> > > so we define a NULL suspend hook. On resume, the driver
> > > initializes
> > > the block exactly as is done in the probe callback.
> > >
> > > Reviewed-by: Kevin Hilman <khilman@baylibre.com>
> > > Signed-off-by: Marc Gonzalez <marc_gonzalez@sigmadesigns.com>
> > Reviewed-by: Arnd Bergmann <arnd@arndb.de>
> Hello Rui, Eduardo,
>
> The present patch has been reviewed by both Kevin Hilman and Arnd
> Bergmann,
> two arm-soc maintainers. Can you pick it up in time for inclusion in
> v4.9?
It has already been in thermal -release branch for a while, and queued
for 4.9.
thanks,
rui
>
> Regards.
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-pm"
> in
> the body of a message to majordomo at vger.kernel.org
> More majordomo info at??http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* [PATCH 2/8] drm/rockchip: Get rid of some unnecessary code
From: Mark yao @ 2016-09-18 1:50 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1473857701-9250-3-git-send-email-tfiga@chromium.org>
On 2016?09?14? 20:54, Tomasz Figa wrote:
> Current code implements prepare_fb and cleanup_fb callbacks only to
> grab/release fb references, which is already done by atomic framework
> when creating/destryoing plane state. Let's remove these
> unused bits.
>
> Signed-off-by: Tomasz Figa <tfiga@chromium.org>
> ---
> drivers/gpu/drm/rockchip/rockchip_drm_vop.c | 18 ------------------
> 1 file changed, 18 deletions(-)
Hi Tomasz
I think we can't get rid of the prepare_fb and cleanup_fb
see the reason:
commit 44d0237a26395ac94160cf23f32769013b365590
Author: Mark Yao <mark.yao@rock-chips.com>
Date: Fri Apr 29 11:37:20 2016 +0800
drm/rockchip: vop: fix iommu crash with async atomic
After async atomic_commit callback, drm_atomic_clean_old_fb will
clean all old fb, but because async, the old fb may be also on
the vop hardware, dma will access the old fb buffer, clean old
fb will cause iommu page fault.
Reference the fb and unreference it when the fb actuall swap out
from vop hardware.
> diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_vop.c b/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
> index 7e811cf..68988c6 100644
> --- a/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
> +++ b/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
> @@ -641,22 +641,6 @@ static void vop_plane_destroy(struct drm_plane *plane)
> drm_plane_cleanup(plane);
> }
>
> -static int vop_plane_prepare_fb(struct drm_plane *plane,
> - struct drm_plane_state *new_state)
> -{
> - if (plane->state->fb)
> - drm_framebuffer_reference(plane->state->fb);
> -
> - return 0;
> -}
> -
> -static void vop_plane_cleanup_fb(struct drm_plane *plane,
> - struct drm_plane_state *old_state)
> -{
> - if (old_state->fb)
> - drm_framebuffer_unreference(old_state->fb);
> -}
> -
> static int vop_plane_atomic_check(struct drm_plane *plane,
> struct drm_plane_state *state)
> {
> @@ -849,8 +833,6 @@ static void vop_plane_atomic_update(struct drm_plane *plane,
> }
>
> static const struct drm_plane_helper_funcs plane_helper_funcs = {
> - .prepare_fb = vop_plane_prepare_fb,
> - .cleanup_fb = vop_plane_cleanup_fb,
> .atomic_check = vop_plane_atomic_check,
> .atomic_update = vop_plane_atomic_update,
> .atomic_disable = vop_plane_atomic_disable,
--
?ark Yao
^ permalink raw reply
* [PATCH v2 3/4] arm64: dts: add Allwinner A64 SoC .dtsi
From: Icenowy Zheng @ 2016-09-18 1:21 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20160917145121.GE17518@lukather>
17.09.2016, 22:56, "Maxime Ripard" <maxime.ripard@free-electrons.com>:
> On Thu, Sep 15, 2016 at 01:08:45AM +0100, Andr? Przywara wrote:
>> ?> --- a/MAINTAINERS
>> ?> +++ b/MAINTAINERS
>> ?> @@ -982,6 +982,7 @@ M: Chen-Yu Tsai <wens@csie.org>
>> ?> L: linux-arm-kernel at lists.infradead.org (moderated for non-subscribers)
>> ?> S: Maintained
>> ?> N: sun[x456789]i
>> ?> +F: arch/arm64/boot/dts/allwinner/
>>
>> ?If you promise to not break it needlessly ;-)
>
> We started doing so since 4.7, and we're already fighting needlessly
> with maintainers because of that.
>
>> ?> + cpus {
>> ?> + #address-cells = <1>;
>> ?> + #size-cells = <0>;
>> ?> +
>> ?> + cpu at 0 {
>>
>> ?This is probably me to blame here since I put you up to it, but you need
>> ?"cpux" names (e.g. "cpu0: cpu at 0 {") to match the ones that the PMU node
>> ?references below. dtc will refuse to compile it otherwise.
>
> Gaah, yes, of course.
>
>> ?> + i2c1_pins: i2c1_pins {
>> ?> + allwinner,pins = "PH2", "PH3";
>> ?> + allwinner,function = "i2c1";
>> ?> + allwinner,drive = <SUN4I_PINCTRL_10_MA>;
>> ?> + allwinner,pull = <SUN4I_PINCTRL_NO_PULL>;
>> ?> + };
>> ?> +
>> ?> + uart0_pins_a: uart0 at 0 {
>> ?> + allwinner,pins = "PB8", "PB9";
>> ?> + allwinner,function = "uart0";
>> ?> + allwinner,drive = <SUN4I_PINCTRL_10_MA>;
>> ?> + allwinner,pull = <SUN4I_PINCTRL_NO_PULL>;
>> ?> + };
>>
>> ?So did I get this right that there is a strict "no user - no pins"
>> ?policy here?
>> ?I don't see a reason why we shouldn't have at least the other UART pins
>> ?described here as well - since they are a pure SoC property. That would
>> ?make it easier for people to enable them (with a simple, scripted fdt
>> ?one-liner command in U-Boot, for instance).
>
> To avoid having huge DT that are longer to load and parse, especially
> since every one wires it in the exact same way all the time. And the
> combination is just too high.
>
> On the A64, the UART0 can be exposed through PB9 and PF4 for TX, and
> PB8 and PF2 for RX. Even though the common usage would be to use PB8
> and PB9, or PF4 and PF6. But absolutely nothing prevents from using
> PB8 and PF4.
>
> You can then add CTS and RTS into the mix, and multiply that by the
> number of devices in the SoC.
>
>> ?I guess there will never be an official DT with more than 2 UARTs
>> ?enabled, although we have actually five UARTs on the headers on the
>> ?Pine64, for instance (and personally I am looking into using one as a
>> ?terminal server).
>
> We relaxed the rule lately however. Boards that have access to those
> UARTs on their headers can put a node in their DT with the right
> muxing filled already. Which brings you the simple, script fdt
> one-liner in U-Boot.
>
>> ?Also UART1 is connected to that WiFi/Bluetooth slot, having it enabled
>> ?should make BT work without further ado (but I haven't tested this).
>
> That's probably not true. You'll most likely need to enable a few
> regulators to have it working.
It seems that Andre has enabled the necessary regulator in the
newest version of his ARM Trusted Firmware...
>
> Maxime
>
> --
> Maxime Ripard, Free Electrons
> Embedded Linux and Kernel engineering
> http://free-electrons.com
> ,
>
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH v5 3/3] pci:aer: add support aer interrupt with none MSI/MSI-X/INTx mode
From: Shawn Guo @ 2016-09-18 0:52 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1473741659-17618-3-git-send-email-po.liu@nxp.com>
On Tue, Sep 13, 2016 at 12:40:59PM +0800, Po Liu wrote:
> On some platforms, root port doesn't support MSI/MSI-X/INTx in RC mode.
> When chip support the aer interrupt with none MSI/MSI-X/INTx mode,
> maybe there is interrupt line for aer pme etc. Search the interrupt
> number in the fdt file. Then fixup the dev->irq with it.
>
> Signed-off-by: Po Liu <po.liu@nxp.com>
Will the new kernel work with existing/old DTB? I'm trying to
understand the dependency between driver and DTS changes.
Shawn
> ---
> changes for v5:
> - Add clear 'aer' interrup-names description
>
> .../devicetree/bindings/pci/layerscape-pci.txt | 11 +++++---
> drivers/pci/pcie/portdrv_core.c | 31 +++++++++++++++++++---
> 2 files changed, 35 insertions(+), 7 deletions(-)
>
> diff --git a/Documentation/devicetree/bindings/pci/layerscape-pci.txt b/Documentation/devicetree/bindings/pci/layerscape-pci.txt
> index 41e9f55..101d0a7 100644
> --- a/Documentation/devicetree/bindings/pci/layerscape-pci.txt
> +++ b/Documentation/devicetree/bindings/pci/layerscape-pci.txt
> @@ -18,8 +18,10 @@ Required properties:
> - reg: base addresses and lengths of the PCIe controller
> - interrupts: A list of interrupt outputs of the controller. Must contain an
> entry for each entry in the interrupt-names property.
> -- interrupt-names: Must include the following entries:
> - "intr": The interrupt that is asserted for controller interrupts
> +- interrupt-names: It may be include the following entries:
> + "aer": The interrupt that is asserted for aer interrupt
> + "pme": The interrupt that is asserted for pme interrupt
> + ......
> - fsl,pcie-scfg: Must include two entries.
> The first entry must be a link to the SCFG device node
> The second entry must be '0' or '1' based on physical PCIe controller index.
> @@ -35,8 +37,9 @@ Example:
> reg = <0x00 0x03400000 0x0 0x00010000 /* controller registers */
> 0x40 0x00000000 0x0 0x00002000>; /* configuration space */
> reg-names = "regs", "config";
> - interrupts = <GIC_SPI 177 IRQ_TYPE_LEVEL_HIGH>; /* controller interrupt */
> - interrupt-names = "intr";
> + interrupts = <GIC_SPI 176 IRQ_TYPE_LEVEL_HIGH>, /* aer interrupt */
> + <GIC_SPI 177 IRQ_TYPE_LEVEL_HIGH>; /* pme interrupt */
> + interrupt-names = "aer", "pme";
> fsl,pcie-scfg = <&scfg 0>;
> #address-cells = <3>;
> #size-cells = <2>;
> diff --git a/drivers/pci/pcie/portdrv_core.c b/drivers/pci/pcie/portdrv_core.c
> index e9270b4..7c4943d 100644
> --- a/drivers/pci/pcie/portdrv_core.c
> +++ b/drivers/pci/pcie/portdrv_core.c
> @@ -16,6 +16,7 @@
> #include <linux/slab.h>
> #include <linux/pcieport_if.h>
> #include <linux/aer.h>
> +#include <linux/of_irq.h>
>
> #include "../pci.h"
> #include "portdrv.h"
> @@ -200,6 +201,28 @@ static int pcie_port_enable_msix(struct pci_dev *dev, int *vectors, int mask)
> static int init_service_irqs(struct pci_dev *dev, int *irqs, int mask)
> {
> int i, irq = -1;
> + int ret;
> + struct device_node *np = NULL;
> +
> + for (i = 0; i < PCIE_PORT_DEVICE_MAXSERVICES; i++)
> + irqs[i] = 0;
> +
> + if (dev->bus->dev.of_node)
> + np = dev->bus->dev.of_node;
> +
> + /* If root port doesn't support MSI/MSI-X/INTx in RC mode,
> + * request irq for aer
> + */
> + if (IS_ENABLED(CONFIG_OF_IRQ) && np &&
> + (mask & PCIE_PORT_SERVICE_PME)) {
> + ret = of_irq_get_byname(np, "aer");
> + if (ret > 0) {
> + irqs[PCIE_PORT_SERVICE_AER_SHIFT] = ret;
> + if (dev->irq)
> + irq = dev->irq;
> + goto no_msi;
> + }
> + }
>
> /*
> * If MSI cannot be used for PCIe PME or hotplug, we have to use
> @@ -225,11 +248,13 @@ static int init_service_irqs(struct pci_dev *dev, int *irqs, int mask)
> irq = dev->irq;
>
> no_msi:
> - for (i = 0; i < PCIE_PORT_DEVICE_MAXSERVICES; i++)
> - irqs[i] = irq;
> + for (i = 0; i < PCIE_PORT_DEVICE_MAXSERVICES; i++) {
> + if (!irqs[i])
> + irqs[i] = irq;
> + }
> irqs[PCIE_PORT_SERVICE_VC_SHIFT] = -1;
>
> - if (irq < 0)
> + if (irq < 0 && irqs[PCIE_PORT_SERVICE_AER_SHIFT] < 0)
> return -ENODEV;
> return 0;
> }
> --
> 2.1.0.27.g96db324
>
>
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH 1/1] ARM: imx5: Add clocks configuration
From: Shawn Guo @ 2016-09-18 0:24 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20160918002159.GD15478@tiger>
On Sun, Sep 18, 2016 at 08:21:59AM +0800, Shawn Guo wrote:
> On Thu, Sep 15, 2016 at 08:42:33PM +0300, Alexander Shiyan wrote:
> > >???????, 15 ???????? 2016, 13:13 +03:00 ?? Fabien Lahoudere <fabien.lahoudere@collabora.co.uk>:
> > >
> > >From: Kalle Kankare < kalle.kankare@vincit.fi >
> > >
> > >Add clocks configuration for CSI, FIRI and IEEE1588.
> > >
> > >Signed-off-by: Fabien Lahoudere < fabien.lahoudere@collabora.co.uk >
> > >---
> > >?drivers/clk/imx/clk-imx51-imx53.c | 20 ++++++++++++++++++++
> > >?include/dt-bindings/clock/imx5-clock.h | 15 ++++++++++++++-
> > >?2 files changed, 34 insertions(+), 1 deletion(-)
> > >
> > >diff --git a/drivers/clk/imx/clk-imx51-imx53.c b/drivers/clk/imx/clk-imx51-imx53.c
> > >index 29d4c44..1e3c9ea 100644
> > >--- a/drivers/clk/imx/clk-imx51-imx53.c
> > >+++ b/drivers/clk/imx/clk-imx51-imx53.c
> > >@@ -126,6 +126,7 @@ static const char *spdif0_com_sel[] = { "spdif0_podf", "ssi1_root_gate", };
> > >?static const char *mx51_spdif1_com_sel[] = { "spdif1_podf", "ssi2_root_gate", };
> > >?static const char *step_sels[] = { "lp_apm", };
> > >?static const char *cpu_podf_sels[] = { "pll1_sw", "step_sel" };
> > >+static const char *ieee1588_sels[] = { "pll3_sw", "pll4_sw", "dummy" /* usbphy2_clk */, "dummy" /* fec_phy_clk */ };
> > >?
> > >?static struct clk *clk[IMX5_CLK_END];
> > >?static struct clk_onecell_data clk_data;
> > >@@ -543,6 +544,25 @@ static void __init mx53_clocks_init(struct device_node *np)
> > ...
> >
> > 2 Shawn Guo: Since the change affects only on i.MX53 architecture,
> > I would ask to change the subject to i.MX53 if it possible.
>
> Yes. Actually, since clock driver is not moved to drivers/clk, we
s/not/now
> shouldn't prefix it with "ARM: " any longer.
Shawn
^ 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