* [PATCH 4/4] arm: dts: add support for Laird SOM60 module and DVK boards
From: Ben Whitten @ 2018-06-14 8:51 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1528966340-23216-1-git-send-email-ben.whitten@lairdtech.com>
Signed-off-by: Ben Whitten <ben.whitten@lairdtech.com>
---
arch/arm/boot/dts/Makefile | 3 +-
arch/arm/boot/dts/at91-dvk_som60.dts | 95 +++++++++++
arch/arm/boot/dts/at91-dvk_su60_somc.dtsi | 159 ++++++++++++++++++
arch/arm/boot/dts/at91-dvk_su60_somc_lcm.dtsi | 96 +++++++++++
arch/arm/boot/dts/at91-som60.dtsi | 229 ++++++++++++++++++++++++++
5 files changed, 581 insertions(+), 1 deletion(-)
create mode 100644 arch/arm/boot/dts/at91-dvk_som60.dts
create mode 100644 arch/arm/boot/dts/at91-dvk_su60_somc.dtsi
create mode 100644 arch/arm/boot/dts/at91-dvk_su60_somc_lcm.dtsi
create mode 100644 arch/arm/boot/dts/at91-som60.dtsi
diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index 486ab59..4d3d9ca 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -63,7 +63,8 @@ dtb-$(CONFIG_SOC_SAM_V7) += \
at91-sama5d4ek.dtb \
at91-vinco.dtb \
at91-wb50n.dtb \
- at91-gatwick.dtb
+ at91-gatwick.dtb \
+ at91-dvk_som60.dtb
dtb-$(CONFIG_ARCH_ATLAS6) += \
atlas6-evb.dtb
dtb-$(CONFIG_ARCH_ATLAS7) += \
diff --git a/arch/arm/boot/dts/at91-dvk_som60.dts b/arch/arm/boot/dts/at91-dvk_som60.dts
new file mode 100644
index 0000000..ededd5b
--- /dev/null
+++ b/arch/arm/boot/dts/at91-dvk_som60.dts
@@ -0,0 +1,95 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * at91-dvk_som60.dts - Device Tree file for the DVK SOM60 board
+ *
+ * Copyright (C) 2018 Laird,
+ * 2018 Ben Whitten <ben.whitten@lairdtech.com>
+ *
+ */
+/dts-v1/;
+#include "at91-som60.dtsi"
+#include "at91-dvk_su60_somc.dtsi"
+#include "at91-dvk_su60_somc_lcm.dtsi"
+
+/ {
+ model = "Laird DVK SOM60";
+ compatible = "laird,dvk-som60", "laird,som60", "atmel,sama5d36", "atmel,sama5d3", "atmel,sama5";
+
+ chosen {
+ stdout-path = &dbgu;
+ tick-timer = &pit;
+ };
+};
+
+&mmc0 {
+ status = "okay";
+};
+
+&spi0 {
+ status = "okay";
+};
+
+&ssc0 {
+ status = "okay";
+};
+
+&i2c0 {
+ status = "okay";
+};
+
+&i2c1 {
+ status = "okay";
+};
+
+&usart1 {
+ status = "okay";
+};
+
+&usart2 {
+ status = "okay";
+};
+
+&usart3 {
+ status = "okay";
+};
+
+&uart0 {
+ status = "okay";
+};
+
+&dbgu {
+ status = "okay";
+};
+
+&pit {
+ status = "okay";
+};
+
+&adc0 {
+ status = "okay";
+};
+
+&can1 {
+ status = "okay";
+};
+
+&macb0 {
+ status = "okay";
+};
+
+&macb1 {
+ status = "okay";
+};
+
+&usb0 {
+ status = "okay";
+};
+
+&usb1 {
+ status = "okay";
+};
+
+&usb2 {
+ status = "okay";
+};
+
diff --git a/arch/arm/boot/dts/at91-dvk_su60_somc.dtsi b/arch/arm/boot/dts/at91-dvk_su60_somc.dtsi
new file mode 100644
index 0000000..6031c2f
--- /dev/null
+++ b/arch/arm/boot/dts/at91-dvk_su60_somc.dtsi
@@ -0,0 +1,159 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * at91-dvk_su60_somc.dtsi - Device Tree file for the DVK SOM60 base board
+ *
+ * Copyright (C) 2018 Laird,
+ * 2018 Ben Whitten <ben.whitten@lairdtech.com>
+ *
+ */
+
+/ {
+ sound {
+ compatible = "atmel,asoc-wm8904";
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_pck2_as_audio_mck>;
+
+ atmel,model = "wm8904 @ DVK-SOM60";
+ atmel,audio-routing =
+ "Headphone Jack", "HPOUTL",
+ "Headphone Jack", "HPOUTR",
+ "IN2L", "Line In Jack",
+ "IN2R", "Line In Jack",
+ "Mic", "MICBIAS",
+ "IN1L", "Mic";
+
+ atmel,ssc-controller = <&ssc0>;
+ atmel,audio-codec = <&wm8904>;
+
+ status = "okay";
+ };
+};
+
+&mmc0 {
+ status = "okay";
+
+ pinctrl-0 = <&pinctrl_mmc0_clk_cmd_dat0 &pinctrl_mmc0_dat1_3 &pinctrl_mmc0_cd>;
+ slot at 0 {
+ bus-width = <4>;
+ cd-gpios = <&pioE 31 GPIO_ACTIVE_HIGH>;
+ cd-inverted;
+ };
+};
+
+&spi0 {
+ status = "okay";
+
+ /* spi0.0: 4M Flash Macronix MX25R4035FM1IL0 */
+ spi-flash at 0 {
+ compatible = "mxicy,mx25u4035", "jedec,spi-nor";
+ spi-max-frequency = <33000000>;
+ reg = <0>;
+ };
+};
+
+&ssc0 {
+ atmel,clk-from-rk-pin;
+ status = "okay";
+};
+
+&i2c0 {
+ status = "okay";
+
+ wm8904: wm8904 at 1a {
+ compatible = "wlf,wm8904";
+ reg = <0x1a>;
+ clocks = <&pck2>;
+ clock-names = "mclk";
+ };
+};
+
+&i2c1 {
+ status = "okay";
+
+ eeprom at 87 {
+ compatible = "giantec,24c32";
+ reg = <87>;
+ pagesize = <32>;
+ };
+};
+
+&usart1 {
+ status = "okay";
+};
+
+&usart2 {
+ status = "okay";
+};
+
+&usart3 {
+ status = "okay";
+};
+
+&uart0 {
+ status = "okay";
+};
+
+&dbgu {
+ status = "okay";
+};
+
+&pit {
+ status = "okay";
+};
+
+&adc0 {
+ status = "okay";
+};
+
+&can1 {
+ status = "okay";
+};
+
+&macb0 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ status = "okay";
+
+ ethernet-phy at 7 {
+ reg = <7>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_geth_int>;
+ interrupt-parent = <&pioB>;
+ interrupts = <25 IRQ_TYPE_EDGE_FALLING>;
+ txen-skew-ps = <800>;
+ txc-skew-ps = <3000>;
+ rxdv-skew-ps = <400>;
+ rxc-skew-ps = <3000>;
+ rxd0-skew-ps = <400>;
+ rxd1-skew-ps = <400>;
+ rxd2-skew-ps = <400>;
+ rxd3-skew-ps = <400>;
+ };
+};
+
+&macb1 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ status = "okay";
+
+ ethernet-phy at 1 {
+ reg = <1>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_eth_int>;
+ interrupt-parent = <&pioC>;
+ interrupts = <10 IRQ_TYPE_EDGE_FALLING>;
+ };
+};
+
+&usb0 {
+ status = "okay";
+};
+
+&usb1 {
+ status = "okay";
+};
+
+&usb2 {
+ status = "okay";
+};
+
diff --git a/arch/arm/boot/dts/at91-dvk_su60_somc_lcm.dtsi b/arch/arm/boot/dts/at91-dvk_su60_somc_lcm.dtsi
new file mode 100644
index 0000000..d98c644
--- /dev/null
+++ b/arch/arm/boot/dts/at91-dvk_su60_somc_lcm.dtsi
@@ -0,0 +1,96 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * at91-dvk_su60_somc_lcm.dtsi - Device Tree file for the DVK SOM60 LCD board
+ *
+ * Copyright (C) 2018 Laird,
+ * 2018 Ben Whitten <ben.whitten@lairdtech.com>
+ *
+ */
+
+/ {
+ ahb {
+ apb {
+ pinctrl at fffff200 {
+ board {
+ pinctrl_lcd_ctp_int: lcd_ctp_int {
+ atmel,pins =
+ <AT91_PIOC 28 AT91_PERIPH_GPIO AT91_PINCTRL_PULL_UP_DEGLITCH>;
+ };
+ };
+ };
+ };
+ };
+
+ backlight: backlight {
+ compatible = "pwm-backlight";
+ pwms = <&hlcdc_pwm 0 50000 0>;
+ brightness-levels = <0 4 8 16 32 64 128 255>;
+ default-brightness-level = <6>;
+ status = "okay";
+ };
+
+ panel: panel {
+ /* Actually Winstar WF70GTIAGDNG0 */
+ compatible = "innolux,at070tn92", "simple-panel";
+ backlight = <&backlight>;
+ power-supply = <&vcc_lcd_reg>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ status = "okay";
+
+ port at 0 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <0>;
+
+ panel_input: endpoint at 0 {
+ reg = <0>;
+ remote-endpoint = <&hlcdc_panel_output>;
+ };
+ };
+ };
+
+ vcc_lcd_reg: fixedregulator_lcd {
+ compatible = "regulator-fixed";
+ regulator-name = "VCC LCM";
+ regulator-min-microvolt = <5000000>;
+ regulator-max-microvolt = <5000000>;
+ regulator-boot-on;
+ regulator-always-on;
+ status = "okay";
+ };
+};
+
+&i2c1 {
+ status = "okay";
+
+ ft5426 at 56 {
+ /* Actually FT5426 */
+ compatible = "edt,edt-ft5406";
+ reg = <56>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_lcd_ctp_int>;
+
+ interrupt-parent = <&pioC>;
+ interrupts = <28 IRQ_TYPE_EDGE_FALLING>;
+
+ touchscreen-size-x = <800>;
+ touchscreen-size-y = <480>;
+ };
+};
+
+&hlcdc {
+ status = "okay";
+
+ hlcdc-display-controller {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_lcd_base &pinctrl_lcd_rgb888>;
+
+ port at 0 {
+ hlcdc_panel_output: endpoint at 0 {
+ reg = <0>;
+ remote-endpoint = <&panel_input>;
+ };
+ };
+ };
+};
diff --git a/arch/arm/boot/dts/at91-som60.dtsi b/arch/arm/boot/dts/at91-som60.dtsi
new file mode 100644
index 0000000..1843284
--- /dev/null
+++ b/arch/arm/boot/dts/at91-som60.dtsi
@@ -0,0 +1,229 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * at91-som60.dtsi - Device Tree file for the SOM60 module
+ *
+ * Copyright (C) 2018 Laird,
+ * 2018 Ben Whitten <ben.whitten@lairdtech.com>
+ *
+ */
+#include "sama5d36.dtsi"
+
+/ {
+ model = "Laird SOM60";
+ compatible = "laird,som60", "atmel,sama5d36", "atmel,sama5d3", "atmel,sama5";
+
+ chosen {
+ stdout-path = &dbgu;
+ };
+
+ memory {
+ reg = <0x20000000 0x8000000>;
+ };
+
+ clocks {
+ slow_xtal {
+ clock-frequency = <32768>;
+ };
+
+ main_xtal {
+ clock-frequency = <12000000>;
+ };
+ };
+
+ ahb {
+ apb {
+ pinctrl at fffff200 {
+ board {
+ pinctrl_mmc0_cd: mmc0_cd {
+ atmel,pins =
+ <AT91_PIOE 31 AT91_PERIPH_GPIO AT91_PINCTRL_DEGLITCH>;
+ };
+
+ pinctrl_mmc0_en: mmc0_en {
+ atmel,pins =
+ <AT91_PIOE 30 AT91_PERIPH_GPIO AT91_PINCTRL_NONE>;
+ };
+
+ pinctrl_nand0_wp: nand0_wp {
+ atmel,pins =
+ <AT91_PIOE 14 AT91_PERIPH_GPIO AT91_PINCTRL_PULL_UP>;
+ };
+
+ pinctrl_usb_vbus: usb_vbus {
+ atmel,pins =
+ <AT91_PIOE 20 AT91_PERIPH_GPIO AT91_PINCTRL_NONE>; /* Conflicts with USART2_SCK */
+ };
+
+ pinctrl_usart2_sck: usart2_sck {
+ atmel,pins =
+ <AT91_PIOE 20 AT91_PERIPH_B AT91_PINCTRL_NONE>; /* Conflicts with USB_VBUS */
+ };
+
+ pinctrl_usb_oc: usb_oc {
+ atmel,pins =
+ <AT91_PIOE 15 AT91_PERIPH_GPIO AT91_PINCTRL_DEGLITCH>; /* Conflicts with USART3_SCK */
+ };
+
+ pinctrl_usart3_sck: usart3_sck {
+ atmel,pins =
+ <AT91_PIOE 15 AT91_PERIPH_B AT91_PINCTRL_NONE>; /* Conflicts with USB_OC */
+ };
+
+ pinctrl_usba_vbus: usba_vbus {
+ atmel,pins =
+ <AT91_PIOC 14 AT91_PERIPH_GPIO AT91_PINCTRL_DEGLITCH>;
+ };
+
+ pinctrl_geth_int: geth_int {
+ atmel,pins =
+ <AT91_PIOB 25 AT91_PERIPH_GPIO AT91_PINCTRL_DEGLITCH>; /* Conflicts with USART1_SCK */
+ };
+
+ pinctrl_usart1_sck: usart1_sck {
+ atmel,pins =
+ <AT91_PIOB 25 AT91_PERIPH_A AT91_PINCTRL_NONE>; /* Conflicts with GETH_INT */
+ };
+
+ pinctrl_eth_int: eth_int {
+ atmel,pins =
+ <AT91_PIOC 10 AT91_PERIPH_GPIO AT91_PINCTRL_DEGLITCH>;
+ };
+
+ pinctrl_pck2_as_audio_mck: pck2_as_audio_mck {
+ atmel,pins =
+ <AT91_PIOC 15 AT91_PERIPH_B AT91_PINCTRL_NONE>;
+ };
+ };
+ };
+ };
+ };
+};
+
+&mmc0 {
+ slot at 0 {
+ reg = <0>;
+ bus-width = <8>;
+ };
+};
+
+&mmc1 {
+ status = "okay";
+ slot at 0 {
+ reg = <0>;
+ bus-width = <4>;
+ };
+};
+
+&spi0 {
+ cs-gpios = <&pioD 13 0>, <0>, <0>, <0>;
+};
+
+&usart0 {
+ atmel,use-dma-rx;
+ atmel,use-dma-tx;
+ status = "okay";
+ pinctrl-0 = <&pinctrl_usart0 &pinctrl_usart0_rts_cts>;
+};
+
+&usart1 {
+ pinctrl-0 = <&pinctrl_usart1 &pinctrl_usart1_rts_cts>;
+};
+
+&usart2 {
+ pinctrl-0 = <&pinctrl_usart2 &pinctrl_usart2_rts_cts>;
+};
+
+&usart3 {
+ pinctrl-0 = <&pinctrl_usart3 &pinctrl_usart3_rts_cts>;
+};
+
+&adc0 {
+ pinctrl-0 = <
+ &pinctrl_adc0_adtrg
+ &pinctrl_adc0_ad0
+ &pinctrl_adc0_ad1
+ &pinctrl_adc0_ad2
+ &pinctrl_adc0_ad3
+ &pinctrl_adc0_ad4
+ &pinctrl_adc0_ad5
+ >;
+};
+
+&macb0 {
+ phy-mode = "rgmii";
+};
+
+&macb1 {
+ phy-mode = "rmii";
+};
+
+
+&ebi {
+ pinctrl-0 = <&pinctrl_ebi_nand_addr>;
+ pinctrl-names = "default";
+ status = "okay";
+};
+
+&nand_controller {
+ status = "okay";
+
+ nand: nand at 3 {
+ reg = <0x3 0x0 0x2>;
+ atmel,rb = <0>;
+ nand-bus-width = <8>;
+ nand-ecc-mode = "hw";
+ nand-ecc-strength = <8>;
+ nand-ecc-step-size = <512>;
+ nand-on-flash-bbt;
+ label = "atmel_nand";
+
+ partitions {
+ compatible = "fixed-partitions";
+ #address-cells = <1>;
+ #size-cells = <1>;
+
+ ubootspl at 0 {
+ label = "u-boot-spl";
+ reg = <0x0 0x20000>;
+ };
+
+ uboot at 20000 {
+ label = "u-boot";
+ reg = <0x20000 0x80000>;
+ };
+
+ ubootenv at a0000 {
+ label = "u-boot-env";
+ reg = <0xa0000 0x20000>;
+ };
+
+ ubootenv at c0000 {
+ label = "u-boot-env";
+ reg = <0xc0000 0x20000>;
+ };
+
+ ubi at e0000 {
+ label = "ubi";
+ reg = <0xe0000 0xfe00000>;
+ };
+ };
+ };
+};
+
+&usb0 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_usba_vbus>;
+ atmel,vbus-gpio = <&pioC 14 GPIO_ACTIVE_HIGH>;
+};
+
+&usb1 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_usb_vbus &pinctrl_usb_oc>;
+ num-ports = <3>;
+ atmel,vbus-gpio = <0
+ &pioE 20 GPIO_ACTIVE_HIGH
+ 0>;
+ atmel,oc-gpio = <0
+ &pioE 15 GPIO_ACTIVE_LOW
+ 0>;
+};
--
2.7.4
^ permalink raw reply related
* [PATCH v4 0/7] add virt-dma support for imx-sdma
From: Lucas Stach @ 2018-06-14 8:53 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1528984982-5074-1-git-send-email-yibin.gong@nxp.com>
Hi Robin,
I just gave this series a spin and it seems there is even more locking
fun, see the lockdep output below. After taking a short look it seems
this is caused by using the wrong spinlock variants in
sdma_int_handler(), those should also use the _irqsave ones. When
fixing this you might want to reconsider patch 7/7, as it's probably
not needed at all.
Regards,
Lucas
[ 20.479401] ========================================================
[ 20.485769] WARNING: possible irq lock inversion dependency detected
[ 20.492140] 4.17.0+ #1538 Not tainted
[ 20.495814] --------------------------------------------------------
[ 20.502181] systemd/1 just changed the state of lock:
[ 20.507247] c0abdafc (&(&substream->self_group.lock)->rlock){-...}, at: snd_pcm_stream_lock+0x54/0x60
[ 20.516523] but this lock took another, HARDIRQ-unsafe lock in the past:
[ 20.523234] (fs_reclaim){+.+.}
[ 20.523253]
[ 20.523253]
[ 20.523253] and interrupts could create inverse lock ordering between them.
[ 20.523253]
[ 20.537804]
[ 20.537804] other info that might help us debug this:
[ 20.544344] Possible interrupt unsafe locking scenario:
[ 20.544344]
[ 20.551144] CPU0 CPU1
[ 20.555686] ---- ----
[ 20.560224] lock(fs_reclaim);
[ 20.563386] local_irq_disable();
[ 20.569315] lock(&(&substream->self_group.lock)->rlock);
[ 20.577337] lock(fs_reclaim);
[ 20.583014] <Interrupt>
[ 20.585643] lock(&(&substream->self_group.lock)->rlock);
[ 20.591322]
[ 20.591322] *** DEADLOCK ***
[ 20.591322]
[ 20.597260] 1 lock held by systemd/1:
[ 20.607806] #0: ab23d11c (snd_pcm_link_rwlock){.-..}, at: snd_pcm_stream_lock+0x4c/0x60
[ 20.615951]
[ 20.615951] the shortest dependencies between 2nd lock and 1st lock:
[ 20.623799] -> (fs_reclaim){+.+.} ops: 248474 {
[ 20.628456] HARDIRQ-ON-W at:
[ 20.631716] lock_acquire+0x260/0x29c
[ 20.637223] fs_reclaim_acquire+0x48/0x58
[ 20.643075] kmem_cache_alloc_trace+0x3c/0x364
[ 20.649366] alloc_worker.constprop.15+0x28/0x64
[ 20.655824] init_rescuer.part.5+0x20/0xa4
[ 20.661764] workqueue_init+0x124/0x1f8
[ 20.667446] kernel_init_freeable+0x60/0x550
[ 20.673561] kernel_init+0x18/0x120
[ 20.678890] ret_from_fork+0x14/0x20
[ 20.684299] (null)
[ 20.688408] SOFTIRQ-ON-W at:
[ 20.691659] lock_acquire+0x260/0x29c
[ 20.697158] fs_reclaim_acquire+0x48/0x58
[ 20.703006] kmem_cache_alloc_trace+0x3c/0x364
[ 20.709288] alloc_worker.constprop.15+0x28/0x64
[ 20.709301] init_rescuer.part.5+0x20/0xa4
[ 20.720717] workqueue_init+0x124/0x1f8
[ 20.720729] kernel_init_freeable+0x60/0x550
[ 20.720738] kernel_init+0x18/0x120
[ 20.720746] ret_from_fork+0x14/0x20
[ 20.720751] (null)
[ 20.720756] INITIAL USE at:
[ 20.720770] lock_acquire+0x260/0x29c
[ 20.720782] fs_reclaim_acquire+0x48/0x58
[ 20.774374] kmem_cache_alloc_trace+0x3c/0x364
[ 20.780574] alloc_worker.constprop.15+0x28/0x64
[ 20.786945] init_rescuer.part.5+0x20/0xa4
[ 20.792794] workqueue_init+0x124/0x1f8
[ 20.798384] kernel_init_freeable+0x60/0x550
[ 20.804406] kernel_init+0x18/0x120
[ 20.809648] ret_from_fork+0x14/0x20
[ 20.814971] (null)
[ 20.818992] }
[ 20.820768] ... key at: [<80e22074>] __fs_reclaim_map+0x0/0x10
[ 20.827220] ... acquired at:
[ 20.830289] fs_reclaim_acquire+0x48/0x58
[ 20.834487] kmem_cache_alloc_trace+0x3c/0x364
[ 20.839123] sdma_transfer_init+0x44/0x130
[ 20.843409] sdma_prep_dma_cyclic+0x78/0x21c
[ 20.847869] snd_dmaengine_pcm_trigger+0xdc/0x184
[ 20.852764] soc_pcm_trigger+0x164/0x190
[ 20.856876] snd_pcm_do_start+0x34/0x40
[ 20.860902] snd_pcm_action_single+0x48/0x74
[ 20.865360] snd_pcm_action+0x34/0xfc
[ 20.869213] snd_pcm_ioctl+0x910/0x10ec
[ 20.873241] vfs_ioctl+0x30/0x44
[ 20.876657] do_vfs_ioctl+0xac/0x974
[ 20.880421] ksys_ioctl+0x48/0x64
[ 20.883923] sys_ioctl+0x18/0x1c
[ 20.887340] ret_fast_syscall+0x0/0x28
[ 20.891277] 0x7289bcbc
[ 20.893909]
[ 20.895410] -> (&(&substream->self_group.lock)->rlock){-...} ops: 59 {
[ 20.901977] IN-HARDIRQ-W at:
[ 20.905143] lock_acquire+0x260/0x29c
[ 20.910473] _raw_spin_lock+0x48/0x58
[ 20.915801] snd_pcm_stream_lock+0x54/0x60
[ 20.921561] _snd_pcm_stream_lock_irqsave+0x40/0x48
[ 20.928107] snd_pcm_period_elapsed+0x2c/0xa4
[ 20.934127] dmaengine_pcm_dma_complete+0x54/0x58
[ 20.940498] sdma_int_handler+0x1dc/0x2a8
[ 20.946179] __handle_irq_event_percpu+0x1fc/0x498
[ 20.952635] handle_irq_event_percpu+0x38/0x8c
[ 20.958742] handle_irq_event+0x48/0x6c
[ 20.964242] handle_fasteoi_irq+0xc4/0x138
[ 20.970006] generic_handle_irq+0x28/0x38
[ 20.975681] __handle_domain_irq+0xb0/0xc4
[ 20.981443] gic_handle_irq+0x68/0xa0
[ 20.986769] __irq_svc+0x70/0xb0
[ 20.991662] _raw_spin_unlock_irq+0x38/0x6c
[ 20.997511] task_work_run+0x90/0xb8
[ 21.002751] do_work_pending+0xc8/0xd0
[ 21.008164] slow_work_pending+0xc/0x20
[ 21.013661] 0x76c77e86
[ 21.017768] INITIAL USE at:
[ 21.020844] lock_acquire+0x260/0x29c
[ 21.026086] _raw_spin_lock+0x48/0x58
[ 21.031328] snd_pcm_stream_lock+0x54/0x60
[ 21.037002] snd_pcm_stream_lock_irq+0x38/0x3c
[ 21.043023] snd_pcm_sync_ptr+0x214/0x260
[ 21.048609] snd_pcm_ioctl+0xbe0/0x10ec
[ 21.054027] vfs_ioctl+0x30/0x44
[ 21.058832] do_vfs_ioctl+0xac/0x974
[ 21.063984] ksys_ioctl+0x48/0x64
[ 21.068875] sys_ioctl+0x18/0x1c
[ 21.073679] ret_fast_syscall+0x0/0x28
[ 21.079004] 0x7e9026dc
[ 21.083023] }
[ 21.084710] ... key at: [<8162a6e4>] __key.31798+0x0/0x8
[ 21.090552] ... acquired at:
[ 21.093537] mark_lock+0x3a4/0x69c
[ 21.097128] __lock_acquire+0x420/0x16d4
[ 21.101239] lock_acquire+0x260/0x29c
[ 21.105091] _raw_spin_lock+0x48/0x58
[ 21.108940] snd_pcm_stream_lock+0x54/0x60
[ 21.113226] _snd_pcm_stream_lock_irqsave+0x40/0x48
[ 21.118296] snd_pcm_period_elapsed+0x2c/0xa4
[ 21.122841] dmaengine_pcm_dma_complete+0x54/0x58
[ 21.127735] sdma_int_handler+0x1dc/0x2a8
[ 21.131937] __handle_irq_event_percpu+0x1fc/0x498
[ 21.136915] handle_irq_event_percpu+0x38/0x8c
[ 21.141547] handle_irq_event+0x48/0x6c
[ 21.145570] handle_fasteoi_irq+0xc4/0x138
[ 21.149854] generic_handle_irq+0x28/0x38
[ 21.154052] __handle_domain_irq+0xb0/0xc4
[ 21.158335] gic_handle_irq+0x68/0xa0
[ 21.162184] __irq_svc+0x70/0xb0
[ 21.165601] _raw_spin_unlock_irq+0x38/0x6c
[ 21.169973] task_work_run+0x90/0xb8
[ 21.173735] do_work_pending+0xc8/0xd0
[ 21.177670] slow_work_pending+0xc/0x20
[ 21.181691] 0x76c77e86
[ 21.184320]
[ 21.185821]
[ 21.185821] stack backtrace:
[ 21.190198] CPU: 0 PID: 1 Comm: systemd Not tainted 4.17.0+ #1538
[ 21.196303] Hardware name: Freescale i.MX6 Quad/DualLite (Device Tree)
[ 21.202841] Backtrace:
[ 21.205314] [<8010e318>] (dump_backtrace) from [<8010e604>] (show_stack+0x20/0x24)
[ 21.212900] r7:80e9f3d0 r6:00000000 r5:60070193 r4:80e9f3d0
[ 21.218581] [<8010e5e4>] (show_stack) from [<8099b660>] (dump_stack+0xa4/0xd8)
[ 21.225825] [<8099b5bc>] (dump_stack) from [<8017b52c>] (print_irq_inversion_bug+0x15c/0x1fc)
[ 21.234368] r9:814da818 r8:00000001 r7:ee926c00 r6:00000000 r5:ee915bb0 r4:814da818
[ 21.242133] [<8017b3d0>] (print_irq_inversion_bug) from [<8017b6dc>] (check_usage_forwards+0x110/0x13c)
[ 21.251544] r9:00000002 r8:80bfd3e2 r7:ee926c00 r6:ee927148 r5:80e08488 r4:00000001
[ 21.259306] [<8017b5cc>] (check_usage_forwards) from [<8017c2a4>] (mark_lock+0x3a4/0x69c)
[ 21.267500] r9:ee926c00 r8:80a03cd8 r7:00000101 r6:00000002 r5:00000000 r4:ee927148
[ 21.275263] [<8017bf00>] (mark_lock) from [<8017cf68>] (__lock_acquire+0x420/0x16d4)
[ 21.283023] r10:ee927148 r9:ed4620e4 r8:ee926c00 r7:00000000 r6:00000001 r5:00000001
[ 21.290863] r4:00000490
[ 21.293416] [<8017cb48>] (__lock_acquire) from [<8017ed58>] (lock_acquire+0x260/0x29c)
[ 21.301350] r10:00000001 r9:80e084a4 r8:00000000 r7:00000000 r6:00000000 r5:ed4620e4
[ 21.309189] r4:00000000
[ 21.311746] [<8017eaf8>] (lock_acquire) from [<809b74f0>] (_raw_spin_lock+0x48/0x58)
[ 21.319506] r10:ee0a4714 r9:ed457100 r8:ee0a46c8 r7:ee0a4714 r6:ee0a4010 r5:807847b0
[ 21.327346] r4:ed4620d4
[ 21.329902] [<809b74a8>] (_raw_spin_lock) from [<807847b0>] (snd_pcm_stream_lock+0x54/0x60)
[ 21.338265] r5:ed462000 r4:ed462000
[ 21.341863] [<8078475c>] (snd_pcm_stream_lock) from [<80784838>] (_snd_pcm_stream_lock_irqsave+0x40/0x48)
[ 21.351440] r5:ed462000 r4:60070193
[ 21.355042] [<807847f8>] (_snd_pcm_stream_lock_irqsave) from [<8078b044>] (snd_pcm_period_elapsed+0x2c/0xa4)
[ 21.364881] r5:ee3ef000 r4:ed462000
[ 21.368478] [<8078b018>] (snd_pcm_period_elapsed) from [<8078d7b4>] (dmaengine_pcm_dma_complete+0x54/0x58)
[ 21.378148] r7:ee0a4714 r6:ee0a4010 r5:00000007 r4:ee0a46bc
[ 21.383827] [<8078d760>] (dmaengine_pcm_dma_complete) from [<80504c0c>] (sdma_int_handler+0x1dc/0x2a8)
[ 21.393157] [<80504a30>] (sdma_int_handler) from [<8018cd28>] (__handle_irq_event_percpu+0x1fc/0x498)
[ 21.402393] r10:00000000 r9:eeafd400 r8:80e084a4 r7:00000038 r6:00000038 r5:80ea3c12
[ 21.410233] r4:ee2b5d40
[ 21.412787] [<8018cb2c>] (__handle_irq_event_percpu) from [<8018cffc>] (handle_irq_event_percpu+0x38/0x8c)
[ 21.422457] r10:00000000 r9:ee914000 r8:ee81d400 r7:00000038 r6:eeafd400 r5:eeafd464
[ 21.430296] r4:80e08488
[ 21.432852] [<8018cfc4>] (handle_irq_event_percpu) from [<8018d098>] (handle_irq_event+0x48/0x6c)
[ 21.441736] r6:eeafd464 r5:eeafd464 r4:eeafd400
[ 21.446374] [<8018d050>] (handle_irq_event) from [<8019146c>] (handle_fasteoi_irq+0xc4/0x138)
[ 21.454912] r7:00000038 r6:eeafd464 r5:80e10a60 r4:eeafd400
[ 21.460589] [<801913a8>] (handle_fasteoi_irq) from [<8018bd9c>] (generic_handle_irq+0x28/0x38)
[ 21.469214] r7:00000038 r6:80d92ae4 r5:00000000 r4:00000000
[ 21.474893] [<8018bd74>] (generic_handle_irq) from [<8018c48c>] (__handle_domain_irq+0xb0/0xc4)
[ 21.483611] [<8018c3dc>] (__handle_domain_irq) from [<80102330>] (gic_handle_irq+0x68/0xa0)
[ 21.491978] r9:ee914000 r8:f4001100 r7:80e5c6bc r6:ee915f00 r5:80e08c3c r4:f4000100
[ 21.499738] [<801022c8>] (gic_handle_irq) from [<801019f0>] (__irq_svc+0x70/0xb0)
[ 21.507233] Exception stack(0xee915f00 to 0xee915f48)
[ 21.512303] 5f00: 00000001 00000004 00000000 ee926c00 ee9270a8 ee926c00 ecc45e00 ee9270a8
[ 21.520498] 5f20: 80ec23b0 ee914000 00000000 ee915f64 ee915f20 ee915f50 8017c7c0 809b78ac
[ 21.528687] 5f40: 20070013 ffffffff
[ 21.532193] r9:ee914000 r8:80ec23b0 r7:ee915f34 r6:ffffffff r5:20070013 r4:809b78ac
[ 21.539959] [<809b7874>] (_raw_spin_unlock_irq) from [<8014e98c>] (task_work_run+0x90/0xb8)
[ 21.548321] r5:ee926c00 r4:ecc45e00
[ 21.551913] [<8014e8fc>] (task_work_run) from [<8010da3c>] (do_work_pending+0xc8/0xd0)
[ 21.559848] r9:ee914000 r8:801011c4 r7:ee915fb0 r6:ffffe000 r5:00000004 r4:801011c4
[ 21.567608] [<8010d974>] (do_work_pending) from [<80101034>] (slow_work_pending+0xc/0x20)
[ 21.575797] Exception stack(0xee915fb0 to 0xee915ff8)
[ 21.580864] 5fa0: 00000000 020c34e8 46059f00 00000000
[ 21.589059] 5fc0: 00000002 76f133a4 020df680 00000006 76e6e168 00000035 7ef81778 00000035
[ 21.597253] 5fe0: 00000006 7ef816a0 76c75d67 76c77e86 20070030 00000039
[ 21.603883] r7:00000006 r6:020df680 r5:76f133a4 r4:00000002
Am Donnerstag, den 14.06.2018, 22:02 +0800 schrieb Robin Gong:
> The legacy sdma driver has below limitations or drawbacks:
> ? 1. Hardcode the max BDs number as "PAGE_SIZE / sizeof(*)", and alloc
> ?????one page size for one channel regardless of only few BDs needed
> ?????most time. But in few cases, the max PAGE_SIZE maybe not enough.
> ? 2. One SDMA channel can't stop immediatley once channel disabled which
> ?????means SDMA interrupt may come in after this channel terminated.There
> ?????are some patches for this corner case such as commit "2746e2c389f9",
> ?????but not cover non-cyclic.
>
> The common virt-dma overcomes the above limitations. It can alloc bd
> dynamically and free bd once this tx transfer done. No memory wasted or
> maximum limititation here, only depends on how many memory can be requested
> from kernel. For No.2, such issue can be workaround by checking if there
> is available descript("sdmac->desc") now once the unwanted interrupt
> coming. At last the common virt-dma is easier for sdma driver maintain.
>
> Change from v3:
> ? 1. add two uart patches which impacted by this patchset.
> ? 2. unlock 'vc.lock' before cyclic dma callback and lock again after
> ?????it because some driver such as uart will call dmaengine_tx_status
> ?????which will acquire 'vc.lock' again and dead lock comes out.
> ? 3. remove 'Revert commit' stuff since that patch is not wrong and
> ?????combine two patch into one patch as Sascha's comment.
>
> Change from v2:
> ? 1. include Sascha's patch to make the main patch easier to review.
> ?????Thanks Sacha.
> ? 2. remove useless 'desc'/'chan' in struct sdma_channe.
>
> Change from v1:
> ? 1. split v1 patch into 5 patches.
> ? 2. remove some unnecessary condition check.
> ? 3. remove unnecessary 'pending' list.
>
> Robin Gong (6):
> ? tty: serial: imx: correct dma cookie status
> ? dmaengine: imx-sdma: add virt-dma support
> ? dmaengine: imx-sdma: remove useless 'lock' and 'enabled' in 'struct
> ????sdma_channel'
> ? dmaengine: imx-sdma: remove the maximum limitation for bd numbers
> ? dmaengine: imx-sdma: add sdma_transfer_init to decrease code overlap
> ? tty: serial: imx: split all dma setup operations out of 'port.lock'
> ????protector
>
> Sascha Hauer (1):
> ? dmaengine: imx-sdma: factor out a struct sdma_desc from struct
> ????sdma_channel
>
> ?drivers/dma/Kconfig??????|???1 +
> ?drivers/dma/imx-sdma.c???| 394 +++++++++++++++++++++++++++--------------------
> ?drivers/tty/serial/imx.c |??99 ++++++------
> ?3 files changed, 282 insertions(+), 212 deletions(-)
>
^ permalink raw reply
* [RFC PATCH 6/8] dts: coresight: Clean up the device tree graph bindings
From: Suzuki K Poulose @ 2018-06-14 8:53 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <HE1PR0802MB24121F0EEF8D7D643BC391A1EE7E0@HE1PR0802MB2412.eurprd08.prod.outlook.com>
On 13/06/18 22:07, Matt Sealey wrote:
>
>
>> -----Original Message-----
>> From: Mathieu Poirier <mathieu.poirier@linaro.org>
>>
>>> So, if the suggestion is to use an existing property "unit", I am fine
>>> with it, if people agree to it.
>>
>> If we're going to have something sharply different than ACPI I prefer
>> Rob's idea.
No, the above comment is about using "unit" ( if it is a standard property
for specifying something specific to hardware) instead of "coresight,hwid".
I would prefer to stick to the DT graph bindings, because :
1) The connections are bi-directional => Well, not necessarily bi-directional
in terms of the data flow. But the connection information is critical. i.e,
we need information about both the end-points of a connection, which the DT
graph bindings solves.
All we are missing is a way for specifying the "hardware port" number and the
direction of flow. I don't see why do we need to create something new just for
these two properties for something that exists today and works reasonably well
for the usecase.
>
> What are you trying to say about being sharply different than ACPI?
The proposed Coresight ACPI draft bindings are based on the ACPI Graph bindings
(just like the DT graph bindings and is compatible with it, in terms of the APIs.
i.e, fwnode_graph_* operations work for both ACPI and DT alike).
So, what Mathieu, in turn means is, if we depart from the DT Graph bindings, which
I personally don't see any benefit in.
Suzuki
^ permalink raw reply
* [PATCH] pinctrl: mt7622: fix a kernel panic when pio don't work as EINT controller
From: sean.wang at mediatek.com @ 2018-06-14 8:55 UTC (permalink / raw)
To: linux-arm-kernel
From: Sean Wang <sean.wang@mediatek.com>
The function, external interrupt controller, is made as an optional to
mt7622 pinctrl. But if we don't want pio behaves as an external interrupt
controller, it would lead to hw->eint not be created properly and then
will cause 'kernel NULL pointer' issue when gpiochip try to call .to_irq
or .set_config. To fix it, check hw->eint before accessing the member.
[ 1.339494] Unable to handle kernel NULL pointer dereference at virtual
address 00000010
[ 1.347857] Mem abort info:
[ 1.350742] ESR = 0x96000005
[ 1.353905] Exception class = DABT (current EL), IL = 32 bits
[ 1.360024] SET = 0, FnV = 0
[ 1.363185] EA = 0, S1PTW = 0
[ 1.366431] Data abort info:
[ 1.369405] ISV = 0, ISS = 0x00000005
[ 1.373363] CM = 0, WnR = 0
[ 1.376437] [0000000000000010] user address but active_mm is swapper
[ 1.383005] Internal error: Oops: 96000005 [#1] PREEMPT SMP
[ 1.388748] Modules linked in:
[ 1.391897] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 4.16.0-rc1+ #344
[ 1.398625] Hardware name: MediaTek MT7622 RFB1 board (DT)
[ 1.404279] pstate: 80000005 (Nzcv daif -PAN -UAO)
[ 1.409221] pc : mtk_eint_find_irq+0x8/0x24
[ 1.413532] lr : mtk_gpio_to_irq+0x20/0x28
[ 1.417749] sp : ffffff800801baf0
[ 1.421161] x29: ffffff800801baf0 x28: ffffff8008792f40
[ 1.426637] x27: ffffff800886b000 x26: ffffff8008615620
[ 1.432113] x25: ffffffc00e4dbdc8 x24: ffffff80087b8000
[ 1.437589] x23: ffffffc00325a000 x22: ffffffc00325a010
[ 1.443066] x21: ffffffc0033dec18 x20: 00000000ffffffea
[ 1.448542] x19: ffffffc00e4db800 x18: 0000000000000130
[ 1.454018] x17: 000000000000000e x16: 0000000000000007
[ 1.459494] x15: ffffff80085ee000 x14: 0000000000000001
[ 1.464970] x13: 0000000000000001 x12: 0000000000000010
[ 1.470446] x11: 0101010101010101 x10: 0000000000000880
[ 1.475922] x9 : ffffff800801b990 x8 : ffffffc0030688e0
[ 1.481399] x7 : ffffff80080c0660 x6 : ffffffc00e4dbbb0
[ 1.486875] x5 : 0000000000000000 x4 : 0000000000000000
[ 1.492351] x3 : ffffff80082a92f4 x2 : 00000000fffffffa
[ 1.497826] x1 : 0000000000000051 x0 : 0000000000000000
[ 1.503305] Process swapper/0 (pid: 1, stack limit = 0x0000000054e053bd)
[ 1.510210] Call trace:
[ 1.512727] mtk_eint_find_irq+0x8/0x24
[ 1.516677] mtk_gpio_to_irq+0x20/0x28
[ 1.520539] gpiod_to_irq+0x48/0x60
[ 1.524135] mmc_gpiod_request_cd_irq+0x3c/0xc4
[ 1.528804] mmc_start_host+0x6c/0x8c
[ 1.532575] mmc_add_host+0x58/0x7c
[ 1.536168] msdc_drv_probe+0x4fc/0x67c
[ 1.540121] platform_drv_probe+0x58/0xa4
[ 1.544251] driver_probe_device+0x204/0x44c
[ 1.548649] __driver_attach+0x84/0xf8
[ 1.552512] bus_for_each_dev+0x68/0xa0
[ 1.556461] driver_attach+0x20/0x28
[ 1.560142] bus_add_driver+0xec/0x240
[ 1.564002] driver_register+0x98/0xe4
[ 1.567863] __platform_driver_register+0x48/0x50
[ 1.572711] mt_msdc_driver_init+0x18/0x20
[ 1.576932] do_one_initcall+0x98/0x130
[ 1.580886] kernel_init_freeable+0x13c/0x1d4
[ 1.585375] kernel_init+0x10/0xf8
[ 1.588879] ret_from_fork+0x10/0x18
[ 1.592564] Code: a8c67bfd d65f03c0 a9bf7bfd 910003fd (f9400800)
[ 1.598849] ---[ end trace 4bbcb7bc30e98492 ]---
[ 1.603677] Kernel panic - not syncing: Attempted to kill init!
exitcode=0x0000000b
[ 1.603677]
cc: Kevin Hilman <khilman@baylibre.com>
Cc: stable at vger.kernel.org
Fixes: e6dabd38d8e7 ("pinctrl: mediatek: add EINT support to MT7622 SoC")
Signed-off-by: Sean Wang <sean.wang@mediatek.com>
---
drivers/pinctrl/mediatek/pinctrl-mt7622.c | 6 +++++-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/drivers/pinctrl/mediatek/pinctrl-mt7622.c b/drivers/pinctrl/mediatek/pinctrl-mt7622.c
index ad6da11..e3f1ab2 100644
--- a/drivers/pinctrl/mediatek/pinctrl-mt7622.c
+++ b/drivers/pinctrl/mediatek/pinctrl-mt7622.c
@@ -1459,6 +1459,9 @@ static int mtk_gpio_to_irq(struct gpio_chip *chip, unsigned int offset)
struct mtk_pinctrl *hw = gpiochip_get_data(chip);
unsigned long eint_n;
+ if (!hw->eint)
+ return -ENOTSUPP;
+
eint_n = offset;
return mtk_eint_find_irq(hw->eint, eint_n);
@@ -1471,7 +1474,8 @@ static int mtk_gpio_set_config(struct gpio_chip *chip, unsigned int offset,
unsigned long eint_n;
u32 debounce;
- if (pinconf_to_config_param(config) != PIN_CONFIG_INPUT_DEBOUNCE)
+ if (!hw->eint ||
+ pinconf_to_config_param(config) != PIN_CONFIG_INPUT_DEBOUNCE)
return -ENOTSUPP;
debounce = pinconf_to_config_argument(config);
--
2.7.4
^ permalink raw reply related
* [PATCH v3 2/7] serdev: add dev_pm_domain_attach|detach()
From: Ulf Hansson @ 2018-06-14 8:58 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <e338118bb6b9f560560887eb974eb250a6c89984.1528960095.git.sean.wang@mediatek.com>
On Thu, 14 Jun 2018 at 09:14, <sean.wang@mediatek.com> wrote:
>
> From: Sean Wang <sean.wang@mediatek.com>
>
> In order to open up the required power gate before any operation can be
> effectively performed over the serial bus between CPU and serdev, it's
> clearly essential to add common attach functions for PM domains to serdev
> at the probe phase.
>
> Similarly, the relevant dettach function for the PM domains should be
> properly and reversely added at the remove phase.
>
> Signed-off-by: Sean Wang <sean.wang@mediatek.com>
> Cc: Rob Herring <robh@kernel.org>
> Cc: Ulf Hansson <ulf.hansson@linaro.org>
> Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
> Cc: Jiri Slaby <jslaby@suse.com>
> Cc: linux-serial at vger.kernel.org
> ---
> drivers/tty/serdev/core.c | 14 +++++++++++++-
> 1 file changed, 13 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/tty/serdev/core.c b/drivers/tty/serdev/core.c
> index df93b72..c93d8ee 100644
> --- a/drivers/tty/serdev/core.c
> +++ b/drivers/tty/serdev/core.c
> @@ -13,6 +13,7 @@
> #include <linux/module.h>
> #include <linux/of.h>
> #include <linux/of_device.h>
> +#include <linux/pm_domain.h>
> #include <linux/serdev.h>
> #include <linux/slab.h>
>
> @@ -330,8 +331,16 @@ EXPORT_SYMBOL_GPL(serdev_device_set_tiocm);
> static int serdev_drv_probe(struct device *dev)
> {
> const struct serdev_device_driver *sdrv = to_serdev_device_driver(dev->driver);
> + int ret;
> +
> + ret = dev_pm_domain_attach(dev, true);
> + if (ret != -EPROBE_DEFER) {
>From 4.18 rc1 via commit 919b7308fcc4, dev_pm_domain_attach() will
return better error codes.
I suggest to change the above error path to:
if (ret)
return ret;
Then continue with the probing below.
> + ret = sdrv->probe(to_serdev_device(dev));
> + if (ret)
> + dev_pm_domain_detach(dev, true);
> + }
>
> - return sdrv->probe(to_serdev_device(dev));
> + return ret;
> }
>
> static int serdev_drv_remove(struct device *dev)
> @@ -339,6 +348,9 @@ static int serdev_drv_remove(struct device *dev)
> const struct serdev_device_driver *sdrv = to_serdev_device_driver(dev->driver);
> if (sdrv->remove)
> sdrv->remove(to_serdev_device(dev));
> +
> + dev_pm_domain_detach(dev, true);
> +
> return 0;
> }
>
> --
> 2.7.4
>
Otherwise, this makes sense to me!
Kind regards
Uffe
^ permalink raw reply
* [PATCH 2/4] ARM: dts: Modernize the Vexpress PL111 integration
From: Liviu Dudau @ 2018-06-14 9:03 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <f371ef92-1876-5fa2-a62a-14a7f4e19ded@arm.com>
On Wed, Jun 13, 2018 at 11:57:25AM +0100, Sudeep Holla wrote:
> Hi Linus,
>
> I was planning to apply this and observed few things.
>
> On 28/05/18 13:26, Linus Walleij wrote:
> > The Versatile Express was submitted with the actual display
> > bridges unconnected (but defined in the device tree) and
> > mock "panels" encoded in the device tree node of the PL111
> > controller.
> >
> > This doesn't even remotely describe the actual Versatile
> > Express hardware. Exploit the SiI9022 bridge by connecting
> > the PL111 pads to it, making it use EDID or fallback values
> > to drive the monitor.
> >
> > The also has to use the reserved memory through the
> > CMA pool rather than by open coding a memory region and
> > remapping it explicitly in the driver. To achieve this,
> > a reserved-memory node must exist in the root of the
> > device tree, so we need to pull that out of the
> > motherboard .dtsi include files, and push it into each
> > top-level device tree instead.
> >
> > We do the same manouver for all the Versatile Express
> > boards, taking into account the different location of the
> > video RAM depending on which chip select is used on
> > each platform.
> >
> > This plays nicely with the new PL111 DRM driver and
> > follows the standard ways of assigning bridges and
> > memory pools for graphics.
> >
> > Cc: Sudeep Holla <sudeep.holla@arm.com>
> > Cc: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
> > Cc: Liviu Dudau <liviu.dudau@arm.com>
> > Cc: Mali DP Maintainers <malidp@foss.arm.com>
> > Cc: Robin Murphy <robin.murphy@arm.com>
> > Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
> > ---
> > ChangeLog v1->v2:
> > - Fix up the memory address for the -rs1 tiles to 0x18000000
> > - Drop a bunch of extraneous reg props from the DVI adapter
> > ---
> > arch/arm/boot/dts/vexpress-v2m-rs1.dtsi | 44 ++++++------------
> > arch/arm/boot/dts/vexpress-v2m.dtsi | 45 ++++++-------------
> > arch/arm/boot/dts/vexpress-v2p-ca15-tc1.dts | 14 ++++++
> > arch/arm/boot/dts/vexpress-v2p-ca15_a7.dts | 14 ++++++
> > arch/arm/boot/dts/vexpress-v2p-ca5s.dts | 14 ++++++
> > arch/arm/boot/dts/vexpress-v2p-ca9.dts | 41 +++++++----------
> > arch/arm64/boot/dts/arm/rtsm_ve-aemv8a.dts | 14 ++++++
> > .../boot/dts/arm/rtsm_ve-motherboard.dtsi | 37 +++------------
> > 8 files changed, 105 insertions(+), 118 deletions(-)
> >
> > diff --git a/arch/arm/boot/dts/vexpress-v2m-rs1.dtsi b/arch/arm/boot/dts/vexpress-v2m-rs1.dtsi
> > index 7b8ff5b3b912..69f6a9436325 100644
> > --- a/arch/arm/boot/dts/vexpress-v2m-rs1.dtsi
> > +++ b/arch/arm/boot/dts/vexpress-v2m-rs1.dtsi
> > @@ -43,11 +43,6 @@
> > bank-width = <4>;
> > };
> >
> > - v2m_video_ram: vram at 2,00000000 {
> > - compatible = "arm,vexpress-vram";
> > - reg = <2 0x00000000 0x00800000>;
> > - };
> > -
> > ethernet at 2,02000000 {
> > compatible = "smsc,lan9118", "smsc,lan9115";
> > reg = <2 0x02000000 0x10000>;
> > @@ -224,6 +219,14 @@
> > dvi-transmitter at 39 {
> > compatible = "sil,sii9022-tpi", "sil,sii9022";
> > reg = <0x39>;
> > +
> > + ports {
> > + port at 0 {
>
>
> May need reg=<0> here, otherwise DTC might complain ?
> [...]
>
> > diff --git a/arch/arm/boot/dts/vexpress-v2m.dtsi b/arch/arm/boot/dts/vexpress-v2m.dtsi
> > index 9cd5e146abd5..067d84bc61c0 100644
> > --- a/arch/arm/boot/dts/vexpress-v2m.dtsi
> > +++ b/arch/arm/boot/dts/vexpress-v2m.dtsi
> > @@ -43,11 +43,6 @@
> > bank-width = <4>;
> > };
> >
> > - v2m_video_ram: vram at 3,00000000 {
> > - compatible = "arm,vexpress-vram";
> > - reg = <3 0x00000000 0x00800000>;
> > - };
> > -
> > ethernet at 3,02000000 {
> > compatible = "smsc,lan9118", "smsc,lan9115";
> > reg = <3 0x02000000 0x10000>;
> > @@ -224,6 +219,14 @@
> > dvi-transmitter at 39 {
> > compatible = "sil,sii9022-tpi", "sil,sii9022";
> > reg = <0x39>;
> > +
> > + ports {
> > + port at 0 {
>
> Ditto
>
> > + dvi_bridge_in: endpoint {
> > + remote-endpoint = <&clcd_pads>;
> > + };
> > + };
> > + };
> > };
> >
> > dvi-transmitter at 60 {
>
> [...]
>
> > diff --git a/arch/arm/boot/dts/vexpress-v2p-ca15-tc1.dts b/arch/arm/boot/dts/vexpress-v2p-ca15-tc1.dts
> > index 3971427a105b..0dc4277d5f8b 100644
> > --- a/arch/arm/boot/dts/vexpress-v2p-ca15-tc1.dts
> > +++ b/arch/arm/boot/dts/vexpress-v2p-ca15-tc1.dts
> > @@ -53,6 +53,20 @@
> > reg = <0 0x80000000 0 0x40000000>;
> > };
> >
> > + reserved-memory {
> > + #address-cells = <2>;
> > + #size-cells = <2>;
> > + ranges;
> > +
> > + /* Chipselect 2 is physically at 0x18000000 */
> > + vram: vram at 18000000 {
> > + /* 8 MB of designated video RAM */
> > + compatible = "shared-dma-pool";
> > + reg = <0 0x18000000 0 0x00800000>;
> > + no-map;
> > + };
> > + };
> > +
>
> I need to think hard yet, but was hoping to keep these in the
> motherboard files itself if possible. I don't like the way we need
> to specify the absolute address here.
>
> > hdlcd at 2b000000 {
> > compatible = "arm,hdlcd";
> > reg = <0 0x2b000000 0 0x1000>;
>
>
> [...]
>
> > diff --git a/arch/arm64/boot/dts/arm/rtsm_ve-motherboard.dtsi b/arch/arm64/boot/dts/arm/rtsm_ve-motherboard.dtsi
> > index 1134e5d8df18..737d0a0c0854 100644
> > --- a/arch/arm64/boot/dts/arm/rtsm_ve-motherboard.dtsi
> > +++ b/arch/arm64/boot/dts/arm/rtsm_ve-motherboard.dtsi
> > @@ -23,11 +23,6 @@
> > bank-width = <4>;
> > };
> >
> > - v2m_video_ram: vram at 2,00000000 {
> > - compatible = "arm,vexpress-vram";
> > - reg = <2 0x00000000 0x00800000>;
> > - };
> > -
> > ethernet at 2,02000000 {
> > compatible = "smsc,lan91c111";
> > reg = <2 0x02000000 0x10000>;
> > @@ -186,38 +181,16 @@
> > interrupts = <14>;
> > clocks = <&v2m_oscclk1>, <&v2m_clk24mhz>;
> > clock-names = "clcdclk", "apb_pclk";
> > - arm,pl11x,framebuffer = <0x18000000 0x00180000>;
> > - memory-region = <&v2m_video_ram>;
> > - max-memory-bandwidth = <130000000>; /* 16bpp @ 63.5MHz */
> > + /* 800x600 16bpp @36MHz works fine */
> > + max-memory-bandwidth = <54000000>;
> > + memory-region = <&vram>;
> >
> > port {
> > - v2m_clcd_pads: endpoint {
> > - remote-endpoint = <&v2m_clcd_panel>;
> > + clcd_pads: endpoint {
> > + remote-endpoint = <&dvi_bridge_in>;
>
> I can't find dvi_bridge_in for this RTSM/FVP model, also not sure if I2C
> or DVI transmitter is supported on them.
>
> Liviu, any idea ?
Models don't have any bridges or DVI transmitters, they use the
framebuffer address that gets programmed into the PL111 registers as the
address where they read from in order to render to screen. At least that
is what happens for HDLCD, I'm afraid I have limited knowledge about the
PL111 implementation in the model.
Best regards,
Liviu
>
> Also you my need to fix arm64 express-v2f-1xv7-ca53x2.dts as it includes
> vexpress-v2m-rs1.dtsi
>
> --
> Regards,
> Sudeep
--
====================
| I would like to |
| fix the world, |
| but they're not |
| giving me the |
\ source code! /
---------------
?\_(?)_/?
^ permalink raw reply
* [PATCH] PCI: xilinx-nwl: add missing of_node_put()
From: Nicholas Mc Guire @ 2018-06-14 9:04 UTC (permalink / raw)
To: linux-arm-kernel
The call to of_get_next_child() returns a node pointer with
refcount incremented thus it must be explicitly decremented
here after the last usage.
Signed-off-by: Nicholas Mc Guire <hofrat@osadl.org>
Fixes: commit ab597d35ef11 ("PCI: xilinx-nwl: Add support for Xilinx NWL PCIe Host Controller")
---
Problem found by an experimental cocinelle script
Patch was compile tested with: multi_v7_defconfig + ARCH_ZYNQ=y,
COMPILE_TEST=y, PCIE_XILINX_NWL=y
(one sparse warning though not related to the change proposed though)
Patch is against 4.17.0 (localversion-next is next-20180613)
drivers/pci/controller/pcie-xilinx-nwl.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/pci/controller/pcie-xilinx-nwl.c b/drivers/pci/controller/pcie-xilinx-nwl.c
index 6a4bbb5..fb32840 100644
--- a/drivers/pci/controller/pcie-xilinx-nwl.c
+++ b/drivers/pci/controller/pcie-xilinx-nwl.c
@@ -559,7 +559,7 @@ static int nwl_pcie_init_irq_domain(struct nwl_pcie *pcie)
PCI_NUM_INTX,
&legacy_domain_ops,
pcie);
-
+ of_node_put(legacy_intc_node);
if (!pcie->legacy_irq_domain) {
dev_err(dev, "failed to create IRQ domain\n");
return -ENOMEM;
--
2.1.4
^ permalink raw reply related
* [PATCH 1/4] arm: dts: add support for Laird WB45N cpu module and DVK
From: Alexandre Belloni @ 2018-06-14 9:07 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1528966340-23216-1-git-send-email-ben.whitten@lairdtech.com>
Hi,
On 14/06/2018 09:51:54+0100, Ben Whitten wrote:
This need a proper commit message. Maybe you can also add a link to the
technical brief for the platform?
> Signed-off-by: Ben Whitten <ben.whitten@lairdtech.com>
> ---
> arch/arm/boot/dts/Makefile | 3 +-
> arch/arm/boot/dts/at91-wb45n.dts | 66 +++++++++++++++
> arch/arm/boot/dts/at91-wb45n.dtsi | 169 ++++++++++++++++++++++++++++++++++++++
> 3 files changed, 237 insertions(+), 1 deletion(-)
> create mode 100644 arch/arm/boot/dts/at91-wb45n.dts
> create mode 100644 arch/arm/boot/dts/at91-wb45n.dtsi
>
> diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
> index 7e24249..1ee94ee 100644
> --- a/arch/arm/boot/dts/Makefile
> +++ b/arch/arm/boot/dts/Makefile
> @@ -42,7 +42,8 @@ dtb-$(CONFIG_SOC_AT91SAM9) += \
> at91sam9g25ek.dtb \
> at91sam9g35ek.dtb \
> at91sam9x25ek.dtb \
> - at91sam9x35ek.dtb
> + at91sam9x35ek.dtb \
> + at91-wb45n.dtb
The proper name for the file is <soc>-board.dtb so this should be
at91sam9g25-wb45n.dtb.
--
Alexandre Belloni, Bootlin (formerly Free Electrons)
Embedded Linux and Kernel engineering
https://bootlin.com
^ permalink raw reply
* [PATCH v3 2/3] media: v4l2-ctrl: Add control for VP9 profile
From: Keiichi Watanabe @ 2018-06-14 9:12 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <9cb304df-c600-918a-1c73-8daa9644f9c3@linaro.org>
Hi Stanimir,
On Thu, Jun 14, 2018 at 5:06 PM, Stanimir Varbanov
<stanimir.varbanov@linaro.org> wrote:
> Hi Keiichi,
>
> On 06/14/2018 10:46 AM, Keiichi Watanabe wrote:
>> Add a new control V4L2_CID_MPEG_VIDEO_VP9_PROFILE for VP9
>> profiles. This control allows to select a desired profile for VP9
>> encoder and query for supported profiles by VP9 encoder/decoder.
>>
>> Though this control is similar to V4L2_CID_MPEG_VIDEO_VP8_PROFILE, we need to
>> separate this control from it because supported profiles usually differ between
>> VP8 and VP9.
>>
>> Signed-off-by: Keiichi Watanabe <keiichiw@chromium.org>
>> ---
>> .../media/uapi/v4l/extended-controls.rst | 25 +++++++++++++++++++
>> drivers/media/v4l2-core/v4l2-ctrls.c | 11 ++++++++
>> include/uapi/linux/v4l2-controls.h | 7 ++++++
>> 3 files changed, 43 insertions(+)
>>
>> diff --git a/Documentation/media/uapi/v4l/extended-controls.rst b/Documentation/media/uapi/v4l/extended-controls.rst
>> index de99eafb0872..095b42e9d6fe 100644
>> --- a/Documentation/media/uapi/v4l/extended-controls.rst
>> +++ b/Documentation/media/uapi/v4l/extended-controls.rst
>> @@ -1980,6 +1980,31 @@ enum v4l2_mpeg_video_vp8_profile -
>> * - ``V4L2_MPEG_VIDEO_VP8_PROFILE_3``
>> - Profile 3
>>
>> +.. _v4l2-mpeg-video-vp9-profile:
>> +
>> +``V4L2_CID_MPEG_VIDEO_VP9_PROFILE``
>> + (enum)
>> +
>> +enum v4l2_mpeg_video_vp9_profile -
>
> what about vp9 levels, shouldn't we add them too? Or we will add it when
> there is a user.
>
It sounds good, but I don't think we should include them in this
series of patches now.
As you said, we can add them when someone wants to use them.
Best regards,
Keiichi
>
> --
> regards,
> Stan
^ permalink raw reply
* [PATCH v1] ARM: dts: imx6sx: fix irq for pcie bridge
From: Oleksij Rempel @ 2018-06-14 9:45 UTC (permalink / raw)
To: linux-arm-kernel
Without this patch MSI interrupts are not routed from Intel
i350 PCIe adapter.
Signed-off-by: Oleksij Rempel <o.rempel@pengutronix.de>
---
arch/arm/boot/dts/imx6sx.dtsi | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/imx6sx.dtsi b/arch/arm/boot/dts/imx6sx.dtsi
index 49c7205b8db8..77fdad65e2bb 100644
--- a/arch/arm/boot/dts/imx6sx.dtsi
+++ b/arch/arm/boot/dts/imx6sx.dtsi
@@ -1351,7 +1351,7 @@
ranges = <0x81000000 0 0 0x08f80000 0 0x00010000 /* downstream I/O */
0x82000000 0 0x08000000 0x08000000 0 0x00f00000>; /* non-prefetchable memory */
num-lanes = <1>;
- interrupts = <GIC_SPI 123 IRQ_TYPE_LEVEL_HIGH>;
+ interrupts = <GIC_SPI 120 IRQ_TYPE_LEVEL_HIGH>;
interrupt-names = "msi";
#interrupt-cells = <1>;
interrupt-map-mask = <0 0 0 0x7>;
--
2.17.1
^ permalink raw reply related
* Patch "serial: sh-sci: Stop using printk format %pCr" has been added to the 4.14-stable tree
From: gregkh at linuxfoundation.org @ 2018-06-14 9:49 UTC (permalink / raw)
To: linux-arm-kernel
This is a note to let you know that I've just added the patch titled
serial: sh-sci: Stop using printk format %pCr
to the 4.14-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary
The filename of the patch is:
serial-sh-sci-stop-using-printk-format-pcr.patch
and it can be found in the queue-4.14 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable@vger.kernel.org> know about it.
>From d63c16f8e1ab761775275adcf54f4bef7c330295 Mon Sep 17 00:00:00 2001
From: Geert Uytterhoeven <geert+renesas@glider.be>
Date: Fri, 1 Jun 2018 11:28:21 +0200
Subject: serial: sh-sci: Stop using printk format %pCr
From: Geert Uytterhoeven <geert+renesas@glider.be>
commit d63c16f8e1ab761775275adcf54f4bef7c330295 upstream.
Printk format "%pCr" will be removed soon, as clk_get_rate() must not be
called in atomic context.
Replace it by open-coding the operation. This is safe here, as the code
runs in task context.
Link: http://lkml.kernel.org/r/1527845302-12159-4-git-send-email-geert+renesas at glider.be
To: Jia-Ju Bai <baijiaju1990@gmail.com>
To: Jonathan Corbet <corbet@lwn.net>
To: Michael Turquette <mturquette@baylibre.com>
To: Stephen Boyd <sboyd@kernel.org>
To: Zhang Rui <rui.zhang@intel.com>
To: Eduardo Valentin <edubezval@gmail.com>
To: Eric Anholt <eric@anholt.net>
To: Stefan Wahren <stefan.wahren@i2se.com>
To: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: Sergey Senozhatsky <sergey.senozhatsky.work@gmail.com>
Cc: Petr Mladek <pmladek@suse.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Steven Rostedt <rostedt@goodmis.org>
Cc: linux-doc at vger.kernel.org
Cc: linux-clk at vger.kernel.org
Cc: linux-pm at vger.kernel.org
Cc: linux-serial at vger.kernel.org
Cc: linux-arm-kernel at lists.infradead.org
Cc: linux-renesas-soc at vger.kernel.org
Cc: linux-kernel at vger.kernel.org
Cc: Geert Uytterhoeven <geert+renesas@glider.be>
Cc: stable at vger.kernel.org # 4.5+
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
Signed-off-by: Petr Mladek <pmladek@suse.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/tty/serial/sh-sci.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
--- a/drivers/tty/serial/sh-sci.c
+++ b/drivers/tty/serial/sh-sci.c
@@ -2669,8 +2669,8 @@ found:
dev_dbg(dev, "failed to get %s (%ld)\n", clk_names[i],
PTR_ERR(clk));
else
- dev_dbg(dev, "clk %s is %pC rate %pCr\n", clk_names[i],
- clk, clk);
+ dev_dbg(dev, "clk %s is %pC rate %lu\n", clk_names[i],
+ clk, clk_get_rate(clk));
sci_port->clks[i] = IS_ERR(clk) ? NULL : clk;
}
return 0;
Patches currently in stable-queue which might be from geert+renesas at glider.be are
queue-4.14/serial-sh-sci-stop-using-printk-format-pcr.patch
^ permalink raw reply
* Patch "serial: sh-sci: Stop using printk format %pCr" has been added to the 4.16-stable tree
From: gregkh at linuxfoundation.org @ 2018-06-14 9:49 UTC (permalink / raw)
To: linux-arm-kernel
This is a note to let you know that I've just added the patch titled
serial: sh-sci: Stop using printk format %pCr
to the 4.16-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary
The filename of the patch is:
serial-sh-sci-stop-using-printk-format-pcr.patch
and it can be found in the queue-4.16 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable@vger.kernel.org> know about it.
>From d63c16f8e1ab761775275adcf54f4bef7c330295 Mon Sep 17 00:00:00 2001
From: Geert Uytterhoeven <geert+renesas@glider.be>
Date: Fri, 1 Jun 2018 11:28:21 +0200
Subject: serial: sh-sci: Stop using printk format %pCr
From: Geert Uytterhoeven <geert+renesas@glider.be>
commit d63c16f8e1ab761775275adcf54f4bef7c330295 upstream.
Printk format "%pCr" will be removed soon, as clk_get_rate() must not be
called in atomic context.
Replace it by open-coding the operation. This is safe here, as the code
runs in task context.
Link: http://lkml.kernel.org/r/1527845302-12159-4-git-send-email-geert+renesas at glider.be
To: Jia-Ju Bai <baijiaju1990@gmail.com>
To: Jonathan Corbet <corbet@lwn.net>
To: Michael Turquette <mturquette@baylibre.com>
To: Stephen Boyd <sboyd@kernel.org>
To: Zhang Rui <rui.zhang@intel.com>
To: Eduardo Valentin <edubezval@gmail.com>
To: Eric Anholt <eric@anholt.net>
To: Stefan Wahren <stefan.wahren@i2se.com>
To: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: Sergey Senozhatsky <sergey.senozhatsky.work@gmail.com>
Cc: Petr Mladek <pmladek@suse.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Steven Rostedt <rostedt@goodmis.org>
Cc: linux-doc at vger.kernel.org
Cc: linux-clk at vger.kernel.org
Cc: linux-pm at vger.kernel.org
Cc: linux-serial at vger.kernel.org
Cc: linux-arm-kernel at lists.infradead.org
Cc: linux-renesas-soc at vger.kernel.org
Cc: linux-kernel at vger.kernel.org
Cc: Geert Uytterhoeven <geert+renesas@glider.be>
Cc: stable at vger.kernel.org # 4.5+
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
Signed-off-by: Petr Mladek <pmladek@suse.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/tty/serial/sh-sci.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
--- a/drivers/tty/serial/sh-sci.c
+++ b/drivers/tty/serial/sh-sci.c
@@ -2691,8 +2691,8 @@ found:
dev_dbg(dev, "failed to get %s (%ld)\n", clk_names[i],
PTR_ERR(clk));
else
- dev_dbg(dev, "clk %s is %pC rate %pCr\n", clk_names[i],
- clk, clk);
+ dev_dbg(dev, "clk %s is %pC rate %lu\n", clk_names[i],
+ clk, clk_get_rate(clk));
sci_port->clks[i] = IS_ERR(clk) ? NULL : clk;
}
return 0;
Patches currently in stable-queue which might be from geert+renesas at glider.be are
queue-4.16/serial-sh-sci-stop-using-printk-format-pcr.patch
^ permalink raw reply
* Patch "serial: sh-sci: Stop using printk format %pCr" has been added to the 4.17-stable tree
From: gregkh at linuxfoundation.org @ 2018-06-14 9:50 UTC (permalink / raw)
To: linux-arm-kernel
This is a note to let you know that I've just added the patch titled
serial: sh-sci: Stop using printk format %pCr
to the 4.17-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary
The filename of the patch is:
serial-sh-sci-stop-using-printk-format-pcr.patch
and it can be found in the queue-4.17 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable@vger.kernel.org> know about it.
>From d63c16f8e1ab761775275adcf54f4bef7c330295 Mon Sep 17 00:00:00 2001
From: Geert Uytterhoeven <geert+renesas@glider.be>
Date: Fri, 1 Jun 2018 11:28:21 +0200
Subject: serial: sh-sci: Stop using printk format %pCr
From: Geert Uytterhoeven <geert+renesas@glider.be>
commit d63c16f8e1ab761775275adcf54f4bef7c330295 upstream.
Printk format "%pCr" will be removed soon, as clk_get_rate() must not be
called in atomic context.
Replace it by open-coding the operation. This is safe here, as the code
runs in task context.
Link: http://lkml.kernel.org/r/1527845302-12159-4-git-send-email-geert+renesas at glider.be
To: Jia-Ju Bai <baijiaju1990@gmail.com>
To: Jonathan Corbet <corbet@lwn.net>
To: Michael Turquette <mturquette@baylibre.com>
To: Stephen Boyd <sboyd@kernel.org>
To: Zhang Rui <rui.zhang@intel.com>
To: Eduardo Valentin <edubezval@gmail.com>
To: Eric Anholt <eric@anholt.net>
To: Stefan Wahren <stefan.wahren@i2se.com>
To: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: Sergey Senozhatsky <sergey.senozhatsky.work@gmail.com>
Cc: Petr Mladek <pmladek@suse.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Steven Rostedt <rostedt@goodmis.org>
Cc: linux-doc at vger.kernel.org
Cc: linux-clk at vger.kernel.org
Cc: linux-pm at vger.kernel.org
Cc: linux-serial at vger.kernel.org
Cc: linux-arm-kernel at lists.infradead.org
Cc: linux-renesas-soc at vger.kernel.org
Cc: linux-kernel at vger.kernel.org
Cc: Geert Uytterhoeven <geert+renesas@glider.be>
Cc: stable at vger.kernel.org # 4.5+
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
Signed-off-by: Petr Mladek <pmladek@suse.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/tty/serial/sh-sci.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
--- a/drivers/tty/serial/sh-sci.c
+++ b/drivers/tty/serial/sh-sci.c
@@ -2704,8 +2704,8 @@ found:
dev_dbg(dev, "failed to get %s (%ld)\n", clk_names[i],
PTR_ERR(clk));
else
- dev_dbg(dev, "clk %s is %pC rate %pCr\n", clk_names[i],
- clk, clk);
+ dev_dbg(dev, "clk %s is %pC rate %lu\n", clk_names[i],
+ clk, clk_get_rate(clk));
sci_port->clks[i] = IS_ERR(clk) ? NULL : clk;
}
return 0;
Patches currently in stable-queue which might be from geert+renesas at glider.be are
queue-4.17/serial-sh-sci-stop-using-printk-format-pcr.patch
^ permalink raw reply
* [PATCH 2/4] arm: dts: add support for Laird WB50N cpu module and DVK
From: Alexandre Belloni @ 2018-06-14 9:50 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1528966340-23216-2-git-send-email-ben.whitten@lairdtech.com>
On 14/06/2018 09:51:55+0100, Ben Whitten wrote:
> Signed-off-by: Ben Whitten <ben.whitten@lairdtech.com>
> ---
> arch/arm/boot/dts/Makefile | 3 +-
> arch/arm/boot/dts/at91-wb50n.dts | 116 ++++++++++++++++++++++
> arch/arm/boot/dts/at91-wb50n.dtsi | 202 ++++++++++++++++++++++++++++++++++++++
> 3 files changed, 320 insertions(+), 1 deletion(-)
> create mode 100644 arch/arm/boot/dts/at91-wb50n.dts
> create mode 100644 arch/arm/boot/dts/at91-wb50n.dtsi
>
> diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
> index 1ee94ee..fd5f8a6 100644
> --- a/arch/arm/boot/dts/Makefile
> +++ b/arch/arm/boot/dts/Makefile
> @@ -61,7 +61,8 @@ dtb-$(CONFIG_SOC_SAM_V7) += \
> at91-sama5d4_ma5d4evk.dtb \
> at91-sama5d4_xplained.dtb \
> at91-sama5d4ek.dtb \
> - at91-vinco.dtb
> + at91-vinco.dtb \
> + at91-wb50n.dtb
I know we have been bad at this but this should be
at91-<soc>-<board>.dtb so at91-sama5d31-wb50n.dtb
> dtb-$(CONFIG_ARCH_ATLAS6) += \
> atlas6-evb.dtb
> dtb-$(CONFIG_ARCH_ATLAS7) += \
> diff --git a/arch/arm/boot/dts/at91-wb50n.dts b/arch/arm/boot/dts/at91-wb50n.dts
> new file mode 100644
> index 0000000..ee4f823
> --- /dev/null
> +++ b/arch/arm/boot/dts/at91-wb50n.dts
> @@ -0,0 +1,116 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/*
> + * at91-wb50n.dts - Device Tree file for wb50n evaluation board
> + *
> + * Copyright (C) 2018 Laird
> + *
> + */
> +
> +/dts-v1/;
> +#include "at91-wb50n.dtsi"
> +
> +/ {
> + model = "Laird Workgroup Bridge 50N - Atmel SAMA5D";
> + compatible = "laird,wb50n", "atmel,sama5d31", "atmel,sama5d3", "atmel,sama5";
> +
> + ahb {
> + apb {
> + watchdog at fffffe40 {
I don't mind if you want to have a preparation patch adding the
necessary labels in the soc dtsi so you don't have to reproduce the
ahb/apb hierarchy here.
> + ahb {
> + apb {
> + pinctrl at fffff200 {
Ditto
> + board {
> + pinctrl_mmc0_cd: mmc0_cd {
> + atmel,pins = <AT91_PIOC 26 AT91_PERIPH_GPIO AT91_PINCTRL_PULL_UP_DEGLITCH>; /* PC26 GPIO with pullup deglitch */
> + };
> +
> + pinctrl_usba_vbus: usba_vbus {
> + atmel,pins = <AT91_PIOB 13 AT91_PERIPH_GPIO AT91_PINCTRL_DEGLITCH>; /* PB13 GPIO with deglitch */
> + };
> + };
> + };
> + };
> + };
> +};
> +
> +&slow_osc {
> + atmel,osc-bypass;
> +};
After the clock binding rework, this will have to be moved to the pmc
node (the rework is not posted, this is just to remind me that this will
have to be done).
> +
> +&usart1_clk {
> + atmel,clk-output-range = <0 132000000>;
> +};
The datasheet explicitly states that 66 MHz is the maximum allowed
frequency for the USART. Note that the new binding will not allow you to
do that.
However, I see the table disappeared from the latest datasheet. Maybe
Nicolas can comment on that?
--
Alexandre Belloni, Bootlin (formerly Free Electrons)
Embedded Linux and Kernel engineering
https://bootlin.com
^ permalink raw reply
* Patch "serial: sh-sci: Stop using printk format %pCr" has been added to the 4.9-stable tree
From: gregkh at linuxfoundation.org @ 2018-06-14 9:50 UTC (permalink / raw)
To: linux-arm-kernel
This is a note to let you know that I've just added the patch titled
serial: sh-sci: Stop using printk format %pCr
to the 4.9-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary
The filename of the patch is:
serial-sh-sci-stop-using-printk-format-pcr.patch
and it can be found in the queue-4.9 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable@vger.kernel.org> know about it.
>From d63c16f8e1ab761775275adcf54f4bef7c330295 Mon Sep 17 00:00:00 2001
From: Geert Uytterhoeven <geert+renesas@glider.be>
Date: Fri, 1 Jun 2018 11:28:21 +0200
Subject: serial: sh-sci: Stop using printk format %pCr
From: Geert Uytterhoeven <geert+renesas@glider.be>
commit d63c16f8e1ab761775275adcf54f4bef7c330295 upstream.
Printk format "%pCr" will be removed soon, as clk_get_rate() must not be
called in atomic context.
Replace it by open-coding the operation. This is safe here, as the code
runs in task context.
Link: http://lkml.kernel.org/r/1527845302-12159-4-git-send-email-geert+renesas at glider.be
To: Jia-Ju Bai <baijiaju1990@gmail.com>
To: Jonathan Corbet <corbet@lwn.net>
To: Michael Turquette <mturquette@baylibre.com>
To: Stephen Boyd <sboyd@kernel.org>
To: Zhang Rui <rui.zhang@intel.com>
To: Eduardo Valentin <edubezval@gmail.com>
To: Eric Anholt <eric@anholt.net>
To: Stefan Wahren <stefan.wahren@i2se.com>
To: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: Sergey Senozhatsky <sergey.senozhatsky.work@gmail.com>
Cc: Petr Mladek <pmladek@suse.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Steven Rostedt <rostedt@goodmis.org>
Cc: linux-doc at vger.kernel.org
Cc: linux-clk at vger.kernel.org
Cc: linux-pm at vger.kernel.org
Cc: linux-serial at vger.kernel.org
Cc: linux-arm-kernel at lists.infradead.org
Cc: linux-renesas-soc at vger.kernel.org
Cc: linux-kernel at vger.kernel.org
Cc: Geert Uytterhoeven <geert+renesas@glider.be>
Cc: stable at vger.kernel.org # 4.5+
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
Signed-off-by: Petr Mladek <pmladek@suse.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/tty/serial/sh-sci.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
--- a/drivers/tty/serial/sh-sci.c
+++ b/drivers/tty/serial/sh-sci.c
@@ -2626,8 +2626,8 @@ found:
dev_dbg(dev, "failed to get %s (%ld)\n", clk_names[i],
PTR_ERR(clk));
else
- dev_dbg(dev, "clk %s is %pC rate %pCr\n", clk_names[i],
- clk, clk);
+ dev_dbg(dev, "clk %s is %pC rate %lu\n", clk_names[i],
+ clk, clk_get_rate(clk));
sci_port->clks[i] = IS_ERR(clk) ? NULL : clk;
}
return 0;
Patches currently in stable-queue which might be from geert+renesas at glider.be are
queue-4.9/serial-sh-sci-stop-using-printk-format-pcr.patch
^ permalink raw reply
* [PATCH v4 0/7] add virt-dma support for imx-sdma
From: Robin Gong @ 2018-06-14 10:09 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1528966400.21021.26.camel@pengutronix.de>
Hi Lucas,
Could you double check again? Still can reproduce lockdep
warning on UART if change
spin_lock_lockirqsave/spinlock_unlock_irqrestore to
spin_lock/spin_unlock in sdma_int_handler as you said without patch7/7.
Would you please ask below two more questions?
1. Does your uart case pass now with my v4 patchset?
2. Do you make some code change in your local('I just gave this series
a spin')to reproduce your below issue? If yes, could you post your
change?
On ?, 2018-06-14 at 10:53 +0200, Lucas Stach wrote:
> Hi Robin,
>
> I just gave this series a spin and it seems there is even more
> locking
> fun, see the lockdep output below. After taking a short look it seems
> this is caused by using the wrong spinlock variants in
> sdma_int_handler(), those should also use the _irqsave ones. When
> fixing this you might want to reconsider patch 7/7, as it's probably
> not needed at all.
>
> Regards,
> Lucas
>
> [???20.479401]
> ========================================================
> [???20.485769] WARNING: possible irq lock inversion dependency
> detected
> [???20.492140] 4.17.0+ #1538 Not tainted
> [???20.495814] ------------------------------------------------------
> --
> [???20.502181] systemd/1 just changed the state of lock:
> [???20.507247] c0abdafc (&(&substream->self_group.lock)->rlock){-
> ...}, at: snd_pcm_stream_lock+0x54/0x60
> [???20.516523] but this lock took another, HARDIRQ-unsafe lock in the
> past:
> [???20.523234]??(fs_reclaim){+.+.}
> [???20.523253]?
> [???20.523253]?
> [???20.523253] and interrupts could create inverse lock ordering
> between them.
> [???20.523253]?
> [???20.537804]?
> [???20.537804] other info that might help us debug this:
> [???20.544344]??Possible interrupt unsafe locking scenario:
> [???20.544344]?
> [???20.551144]????????CPU0????????????????????CPU1
> [???20.555686]????????----????????????????????----
> [???20.560224]???lock(fs_reclaim);
> [???20.563386]????????????????????????????????local_irq_disable();
> [???20.569315]????????????????????????????????lock(&(&substream-
> >self_group.lock)->rlock);
> [???20.577337]????????????????????????????????lock(fs_reclaim);
> [???20.583014]???<Interrupt>
> [???20.585643]?????lock(&(&substream->self_group.lock)->rlock);
> [???20.591322]?
> [???20.591322]??*** DEADLOCK ***
> [???20.591322]?
> [???20.597260] 1 lock held by systemd/1:
> [???20.607806]??#0: ab23d11c (snd_pcm_link_rwlock){.-..}, at:
> snd_pcm_stream_lock+0x4c/0x60
> [???20.615951]?
> [???20.615951] the shortest dependencies between 2nd lock and 1st
> lock:
> [???20.623799]??-> (fs_reclaim){+.+.} ops: 248474 {
> [???20.628456]?????HARDIRQ-ON-W at:
> [???20.631716]???????????????????????lock_acquire+0x260/0x29c
> [???20.637223]???????????????????????fs_reclaim_acquire+0x48/0x58
> [???20.643075]???????????????????????kmem_cache_alloc_trace+0x3c/0x36
> 4
> [???20.649366]???????????????????????alloc_worker.constprop.15+0x28/0
> x64
> [???20.655824]???????????????????????init_rescuer.part.5+0x20/0xa4
> [???20.661764]???????????????????????workqueue_init+0x124/0x1f8
> [???20.667446]???????????????????????kernel_init_freeable+0x60/0x550
> [???20.673561]???????????????????????kernel_init+0x18/0x120
> [???20.678890]???????????????????????ret_from_fork+0x14/0x20
> [???20.684299]?????????????????????????(null)
> [???20.688408]?????SOFTIRQ-ON-W at:
> [???20.691659]???????????????????????lock_acquire+0x260/0x29c
> [???20.697158]???????????????????????fs_reclaim_acquire+0x48/0x58
> [???20.703006]???????????????????????kmem_cache_alloc_trace+0x3c/0x36
> 4
> [???20.709288]???????????????????????alloc_worker.constprop.15+0x28/0
> x64
> [???20.709301]???????????????????????init_rescuer.part.5+0x20/0xa4
> [???20.720717]???????????????????????workqueue_init+0x124/0x1f8
> [???20.720729]???????????????????????kernel_init_freeable+0x60/0x550
> [???20.720738]???????????????????????kernel_init+0x18/0x120
> [???20.720746]???????????????????????ret_from_fork+0x14/0x20
> [???20.720751]?????????????????????????(null)
> [???20.720756]?????INITIAL USE at:
> [???20.720770]??????????????????????lock_acquire+0x260/0x29c
> [???20.720782]??????????????????????fs_reclaim_acquire+0x48/0x58
> [???20.774374]??????????????????????kmem_cache_alloc_trace+0x3c/0x364
> [???20.780574]??????????????????????alloc_worker.constprop.15+0x28/0x
> 64
> [???20.786945]??????????????????????init_rescuer.part.5+0x20/0xa4
> [???20.792794]??????????????????????workqueue_init+0x124/0x1f8
> [???20.798384]??????????????????????kernel_init_freeable+0x60/0x550
> [???20.804406]??????????????????????kernel_init+0x18/0x120
> [???20.809648]??????????????????????ret_from_fork+0x14/0x20
> [???20.814971]????????????????????????(null)
> [???20.818992]???}
> [???20.820768]???... key??????at: [<80e22074>]
> __fs_reclaim_map+0x0/0x10
> [???20.827220]???... acquired at:
> [???20.830289]????fs_reclaim_acquire+0x48/0x58
> [???20.834487]????kmem_cache_alloc_trace+0x3c/0x364
> [???20.839123]????sdma_transfer_init+0x44/0x130
> [???20.843409]????sdma_prep_dma_cyclic+0x78/0x21c
> [???20.847869]????snd_dmaengine_pcm_trigger+0xdc/0x184
> [???20.852764]????soc_pcm_trigger+0x164/0x190
> [???20.856876]????snd_pcm_do_start+0x34/0x40
> [???20.860902]????snd_pcm_action_single+0x48/0x74
> [???20.865360]????snd_pcm_action+0x34/0xfc
> [???20.869213]????snd_pcm_ioctl+0x910/0x10ec
> [???20.873241]????vfs_ioctl+0x30/0x44
> [???20.876657]????do_vfs_ioctl+0xac/0x974
> [???20.880421]????ksys_ioctl+0x48/0x64
> [???20.883923]????sys_ioctl+0x18/0x1c
> [???20.887340]????ret_fast_syscall+0x0/0x28
> [???20.891277]????0x7289bcbc
> [???20.893909]?
> [???20.895410] -> (&(&substream->self_group.lock)->rlock){-...} ops:
> 59 {
> [???20.901977]????IN-HARDIRQ-W at:
> [???20.905143]?????????????????????lock_acquire+0x260/0x29c
> [???20.910473]?????????????????????_raw_spin_lock+0x48/0x58
> [???20.915801]?????????????????????snd_pcm_stream_lock+0x54/0x60
> [???20.921561]?????????????????????_snd_pcm_stream_lock_irqsave+0x40/
> 0x48
> [???20.928107]?????????????????????snd_pcm_period_elapsed+0x2c/0xa4
> [???20.934127]?????????????????????dmaengine_pcm_dma_complete+0x54/0x
> 58
> [???20.940498]?????????????????????sdma_int_handler+0x1dc/0x2a8
> [???20.946179]?????????????????????__handle_irq_event_percpu+0x1fc/0x
> 498
> [???20.952635]?????????????????????handle_irq_event_percpu+0x38/0x8c
> [???20.958742]?????????????????????handle_irq_event+0x48/0x6c
> [???20.964242]?????????????????????handle_fasteoi_irq+0xc4/0x138
> [???20.970006]?????????????????????generic_handle_irq+0x28/0x38
> [???20.975681]?????????????????????__handle_domain_irq+0xb0/0xc4
> [???20.981443]?????????????????????gic_handle_irq+0x68/0xa0
> [???20.986769]?????????????????????__irq_svc+0x70/0xb0
> [???20.991662]?????????????????????_raw_spin_unlock_irq+0x38/0x6c
> [???20.997511]?????????????????????task_work_run+0x90/0xb8
> [???21.002751]?????????????????????do_work_pending+0xc8/0xd0
> [???21.008164]?????????????????????slow_work_pending+0xc/0x20
> [???21.013661]?????????????????????0x76c77e86
> [???21.017768]????INITIAL USE at:
> [???21.020844]????????????????????lock_acquire+0x260/0x29c
> [???21.026086]????????????????????_raw_spin_lock+0x48/0x58
> [???21.031328]????????????????????snd_pcm_stream_lock+0x54/0x60
> [???21.037002]????????????????????snd_pcm_stream_lock_irq+0x38/0x3c
> [???21.043023]????????????????????snd_pcm_sync_ptr+0x214/0x260
> [???21.048609]????????????????????snd_pcm_ioctl+0xbe0/0x10ec
> [???21.054027]????????????????????vfs_ioctl+0x30/0x44
> [???21.058832]????????????????????do_vfs_ioctl+0xac/0x974
> [???21.063984]????????????????????ksys_ioctl+0x48/0x64
> [???21.068875]????????????????????sys_ioctl+0x18/0x1c
> [???21.073679]????????????????????ret_fast_syscall+0x0/0x28
> [???21.079004]????????????????????0x7e9026dc
> [???21.083023]??}
> [???21.084710]??... key??????at: [<8162a6e4>] __key.31798+0x0/0x8
> [???21.090552]??... acquired at:
> [???21.093537]????mark_lock+0x3a4/0x69c
> [???21.097128]????__lock_acquire+0x420/0x16d4
> [???21.101239]????lock_acquire+0x260/0x29c
> [???21.105091]????_raw_spin_lock+0x48/0x58
> [???21.108940]????snd_pcm_stream_lock+0x54/0x60
> [???21.113226]????_snd_pcm_stream_lock_irqsave+0x40/0x48
> [???21.118296]????snd_pcm_period_elapsed+0x2c/0xa4
> [???21.122841]????dmaengine_pcm_dma_complete+0x54/0x58
> [???21.127735]????sdma_int_handler+0x1dc/0x2a8
> [???21.131937]????__handle_irq_event_percpu+0x1fc/0x498
> [???21.136915]????handle_irq_event_percpu+0x38/0x8c
> [???21.141547]????handle_irq_event+0x48/0x6c
> [???21.145570]????handle_fasteoi_irq+0xc4/0x138
> [???21.149854]????generic_handle_irq+0x28/0x38
> [???21.154052]????__handle_domain_irq+0xb0/0xc4
> [???21.158335]????gic_handle_irq+0x68/0xa0
> [???21.162184]????__irq_svc+0x70/0xb0
> [???21.165601]????_raw_spin_unlock_irq+0x38/0x6c
> [???21.169973]????task_work_run+0x90/0xb8
> [???21.173735]????do_work_pending+0xc8/0xd0
> [???21.177670]????slow_work_pending+0xc/0x20
> [???21.181691]????0x76c77e86
> [???21.184320]?
> [???21.185821]?
> [???21.185821] stack backtrace:
> [???21.190198] CPU: 0 PID: 1 Comm: systemd Not tainted 4.17.0+ #1538
> [???21.196303] Hardware name: Freescale i.MX6 Quad/DualLite (Device
> Tree)
> [???21.202841] Backtrace:?
> [???21.205314] [<8010e318>] (dump_backtrace) from [<8010e604>]
> (show_stack+0x20/0x24)
> [???21.212900]??r7:80e9f3d0 r6:00000000 r5:60070193 r4:80e9f3d0
> [???21.218581] [<8010e5e4>] (show_stack) from [<8099b660>]
> (dump_stack+0xa4/0xd8)
> [???21.225825] [<8099b5bc>] (dump_stack) from [<8017b52c>]
> (print_irq_inversion_bug+0x15c/0x1fc)
> [???21.234368]??r9:814da818 r8:00000001 r7:ee926c00 r6:00000000
> r5:ee915bb0 r4:814da818
> [???21.242133] [<8017b3d0>] (print_irq_inversion_bug) from
> [<8017b6dc>] (check_usage_forwards+0x110/0x13c)
> [???21.251544]??r9:00000002 r8:80bfd3e2 r7:ee926c00 r6:ee927148
> r5:80e08488 r4:00000001
> [???21.259306] [<8017b5cc>] (check_usage_forwards) from [<8017c2a4>]
> (mark_lock+0x3a4/0x69c)
> [???21.267500]??r9:ee926c00 r8:80a03cd8 r7:00000101 r6:00000002
> r5:00000000 r4:ee927148
> [???21.275263] [<8017bf00>] (mark_lock) from [<8017cf68>]
> (__lock_acquire+0x420/0x16d4)
> [???21.283023]??r10:ee927148 r9:ed4620e4 r8:ee926c00 r7:00000000
> r6:00000001 r5:00000001
> [???21.290863]??r4:00000490
> [???21.293416] [<8017cb48>] (__lock_acquire) from [<8017ed58>]
> (lock_acquire+0x260/0x29c)
> [???21.301350]??r10:00000001 r9:80e084a4 r8:00000000 r7:00000000
> r6:00000000 r5:ed4620e4
> [???21.309189]??r4:00000000
> [???21.311746] [<8017eaf8>] (lock_acquire) from [<809b74f0>]
> (_raw_spin_lock+0x48/0x58)
> [???21.319506]??r10:ee0a4714 r9:ed457100 r8:ee0a46c8 r7:ee0a4714
> r6:ee0a4010 r5:807847b0
> [???21.327346]??r4:ed4620d4
> [???21.329902] [<809b74a8>] (_raw_spin_lock) from [<807847b0>]
> (snd_pcm_stream_lock+0x54/0x60)
> [???21.338265]??r5:ed462000 r4:ed462000
> [???21.341863] [<8078475c>] (snd_pcm_stream_lock) from [<80784838>]
> (_snd_pcm_stream_lock_irqsave+0x40/0x48)
> [???21.351440]??r5:ed462000 r4:60070193
> [???21.355042] [<807847f8>] (_snd_pcm_stream_lock_irqsave) from
> [<8078b044>] (snd_pcm_period_elapsed+0x2c/0xa4)
> [???21.364881]??r5:ee3ef000 r4:ed462000
> [???21.368478] [<8078b018>] (snd_pcm_period_elapsed) from
> [<8078d7b4>] (dmaengine_pcm_dma_complete+0x54/0x58)
> [???21.378148]??r7:ee0a4714 r6:ee0a4010 r5:00000007 r4:ee0a46bc
> [???21.383827] [<8078d760>] (dmaengine_pcm_dma_complete) from
> [<80504c0c>] (sdma_int_handler+0x1dc/0x2a8)
> [???21.393157] [<80504a30>] (sdma_int_handler) from [<8018cd28>]
> (__handle_irq_event_percpu+0x1fc/0x498)
> [???21.402393]??r10:00000000 r9:eeafd400 r8:80e084a4 r7:00000038
> r6:00000038 r5:80ea3c12
> [???21.410233]??r4:ee2b5d40
> [???21.412787] [<8018cb2c>] (__handle_irq_event_percpu) from
> [<8018cffc>] (handle_irq_event_percpu+0x38/0x8c)
> [???21.422457]??r10:00000000 r9:ee914000 r8:ee81d400 r7:00000038
> r6:eeafd400 r5:eeafd464
> [???21.430296]??r4:80e08488
> [???21.432852] [<8018cfc4>] (handle_irq_event_percpu) from
> [<8018d098>] (handle_irq_event+0x48/0x6c)
> [???21.441736]??r6:eeafd464 r5:eeafd464 r4:eeafd400
> [???21.446374] [<8018d050>] (handle_irq_event) from [<8019146c>]
> (handle_fasteoi_irq+0xc4/0x138)
> [???21.454912]??r7:00000038 r6:eeafd464 r5:80e10a60 r4:eeafd400
> [???21.460589] [<801913a8>] (handle_fasteoi_irq) from [<8018bd9c>]
> (generic_handle_irq+0x28/0x38)
> [???21.469214]??r7:00000038 r6:80d92ae4 r5:00000000 r4:00000000
> [???21.474893] [<8018bd74>] (generic_handle_irq) from [<8018c48c>]
> (__handle_domain_irq+0xb0/0xc4)
> [???21.483611] [<8018c3dc>] (__handle_domain_irq) from [<80102330>]
> (gic_handle_irq+0x68/0xa0)
> [???21.491978]??r9:ee914000 r8:f4001100 r7:80e5c6bc r6:ee915f00
> r5:80e08c3c r4:f4000100
> [???21.499738] [<801022c8>] (gic_handle_irq) from [<801019f0>]
> (__irq_svc+0x70/0xb0)
> [???21.507233] Exception stack(0xee915f00 to 0xee915f48)
> [???21.512303] 5f00: 00000001 00000004 00000000 ee926c00 ee9270a8
> ee926c00 ecc45e00 ee9270a8
> [???21.520498] 5f20: 80ec23b0 ee914000 00000000 ee915f64 ee915f20
> ee915f50 8017c7c0 809b78ac
> [???21.528687] 5f40: 20070013 ffffffff
> [???21.532193]??r9:ee914000 r8:80ec23b0 r7:ee915f34 r6:ffffffff
> r5:20070013 r4:809b78ac
> [???21.539959] [<809b7874>] (_raw_spin_unlock_irq) from [<8014e98c>]
> (task_work_run+0x90/0xb8)
> [???21.548321]??r5:ee926c00 r4:ecc45e00
> [???21.551913] [<8014e8fc>] (task_work_run) from [<8010da3c>]
> (do_work_pending+0xc8/0xd0)
> [???21.559848]??r9:ee914000 r8:801011c4 r7:ee915fb0 r6:ffffe000
> r5:00000004 r4:801011c4
> [???21.567608] [<8010d974>] (do_work_pending) from [<80101034>]
> (slow_work_pending+0xc/0x20)
> [???21.575797] Exception stack(0xee915fb0 to 0xee915ff8)
> [???21.580864] 5fa0:?????????????????????????????????????00000000
> 020c34e8 46059f00 00000000
> [???21.589059] 5fc0: 00000002 76f133a4 020df680 00000006 76e6e168
> 00000035 7ef81778 00000035
> [???21.597253] 5fe0: 00000006 7ef816a0 76c75d67 76c77e86 20070030
> 00000039
> [???21.603883]??r7:00000006 r6:020df680 r5:76f133a4 r4:00000002
>
> Am Donnerstag, den 14.06.2018, 22:02 +0800 schrieb Robin Gong:
> >
> > The legacy sdma driver has below limitations or drawbacks:
> > ? 1. Hardcode the max BDs number as "PAGE_SIZE / sizeof(*)", and
> > alloc
> > ?????one page size for one channel regardless of only few BDs
> > needed
> > ?????most time. But in few cases, the max PAGE_SIZE maybe not
> > enough.
> > ? 2. One SDMA channel can't stop immediatley once channel disabled
> > which
> > ?????means SDMA interrupt may come in after this channel
> > terminated.There
> > ?????are some patches for this corner case such as commit
> > "2746e2c389f9",
> > ?????but not cover non-cyclic.
> >
> > The common virt-dma overcomes the above limitations. It can alloc
> > bd
> > dynamically and free bd once this tx transfer done. No memory
> > wasted or
> > maximum limititation here, only depends on how many memory can be
> > requested
> > from kernel. For No.2, such issue can be workaround by checking if
> > there
> > is available descript("sdmac->desc") now once the unwanted
> > interrupt
> > coming. At last the common virt-dma is easier for sdma driver
> > maintain.
> >
> > Change from v3:
> > ? 1. add two uart patches which impacted by this patchset.
> > ? 2. unlock 'vc.lock' before cyclic dma callback and lock again
> > after
> > ?????it because some driver such as uart will call
> > dmaengine_tx_status
> > ?????which will acquire 'vc.lock' again and dead lock comes out.
> > ? 3. remove 'Revert commit' stuff since that patch is not wrong and
> > ?????combine two patch into one patch as Sascha's comment.
> >
> > Change from v2:
> > ? 1. include Sascha's patch to make the main patch easier to
> > review.
> > ?????Thanks Sacha.
> > ? 2. remove useless 'desc'/'chan' in struct sdma_channe.
> >
> > Change from v1:
> > ? 1. split v1 patch into 5 patches.
> > ? 2. remove some unnecessary condition check.
> > ? 3. remove unnecessary 'pending' list.
> >
> > Robin Gong (6):
> > ? tty: serial: imx: correct dma cookie status
> > ? dmaengine: imx-sdma: add virt-dma support
> > ? dmaengine: imx-sdma: remove useless 'lock' and 'enabled' in
> > 'struct
> > ????sdma_channel'
> > ? dmaengine: imx-sdma: remove the maximum limitation for bd numbers
> > ? dmaengine: imx-sdma: add sdma_transfer_init to decrease code
> > overlap
> > ? tty: serial: imx: split all dma setup operations out of
> > 'port.lock'
> > ????protector
> >
> > Sascha Hauer (1):
> > ? dmaengine: imx-sdma: factor out a struct sdma_desc from struct
> > ????sdma_channel
> >
> > ?drivers/dma/Kconfig??????|???1 +
> > ?drivers/dma/imx-sdma.c???| 394 +++++++++++++++++++++++++++------
> > --------------
> > ?drivers/tty/serial/imx.c |??99 ++++++------
> > ?3 files changed, 282 insertions(+), 212 deletions(-)
> >
^ permalink raw reply
* [PATCH 1/2] ARM: dts: imx6qdl-sabreauto: Add sensors
From: Leonard Crestez @ 2018-06-14 10:17 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAOMZO5Czf1bO7vJZ1UG46DyVhzApqS82GFw+NFm_HN5tjD=xoQ@mail.gmail.com>
On Thu, 2018-06-07 at 14:07 -0300, Fabio Estevam wrote:
> Hi Leonard,
>
> On Thu, Jun 7, 2018 at 2:00 PM, Leonard Crestez <leonard.crestez@nxp.com> wrote:
>
> > +
> > + isl29023 at 44 {
>
> According to Devicetree Specification v0.2 document:
>
> "The name of a node should be somewhat generic, reflecting the function
> of the device and not its precise programming model."
>
> So you could write:
>
> light-sensor at 44
Ok, will fix in v2.
Should I also assign a label, like "isl29023: light-sensor at 44"? I
couldn't find any recommendation on this.
There are no immediate uses for a label but this practice is very
common. Having labels allows creating minor board variants with reduced
churn in the base dts so it seems good.
--
Regards,
Leonard
^ permalink raw reply
* [PATCH v4 0/7] add virt-dma support for imx-sdma
From: Lucas Stach @ 2018-06-14 10:22 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1528999731.10947.20.camel@nxp.com>
Am Donnerstag, den 14.06.2018, 10:09 +0000 schrieb Robin Gong:
> Hi Lucas,
> Could you double check again? Still can reproduce lockdep
> warning on UART if change
> spin_lock_lockirqsave/spinlock_unlock_irqrestore to
> spin_lock/spin_unlock in sdma_int_handler as you said without
> patch7/7.
Yes, I can reproduce the lockdep issue with _irqsave variants in the
IRQ handler and 7/7 reverted. It fixes the pcm issue though.
> Would you please ask below two more questions?
> 1. Does your uart case pass now with my v4 patchset?
It seems to work, but the change seems to impact the non-DMA serial
somehow. On several boots the system was unable to present a login
prompt, so patch 7/7 seems to break other stuff and it's a pretty
invasive change to the serial driver, which is known to be non-trivial.
I don't have the bandwidth to dig through this patch currently, but I
wonder if it couldn't be simplified with the spinlock stuff in the sdma
driver fixed.
> 2. Do you make some code change in your local('I just gave this
> series
> a spin')to reproduce your below issue? If yes, could you post your
> change?
The lockdep splat below was without any changes to your series.
Regards,
Lucas
> On ?, 2018-06-14 at 10:53 +0200, Lucas Stach wrote:
> > Hi Robin,
> >
> > I just gave this series a spin and it seems there is even more
> > locking
> > fun, see the lockdep output below. After taking a short look it
> > seems
> > this is caused by using the wrong spinlock variants in
> > sdma_int_handler(), those should also use the _irqsave ones. When
> > fixing this you might want to reconsider patch 7/7, as it's
> > probably
> > not needed at all.
> >
> > Regards,
> > Lucas
> >
> > [???20.479401]
> > ========================================================
> > [???20.485769] WARNING: possible irq lock inversion dependency
> > detected
> > [???20.492140] 4.17.0+ #1538 Not tainted
> > [???20.495814] ----------------------------------------------------
> > --
> > --
> > [???20.502181] systemd/1 just changed the state of lock:
> > [???20.507247] c0abdafc (&(&substream->self_group.lock)->rlock){-
> > ...}, at: snd_pcm_stream_lock+0x54/0x60
> > [???20.516523] but this lock took another, HARDIRQ-unsafe lock in
> > the
> > past:
> > [???20.523234]??(fs_reclaim){+.+.}
> > [???20.523253]?
> > [???20.523253]?
> > [???20.523253] and interrupts could create inverse lock ordering
> > between them.
> > [???20.523253]?
> > [???20.537804]?
> > [???20.537804] other info that might help us debug this:
> > [???20.544344]??Possible interrupt unsafe locking scenario:
> > [???20.544344]?
> > [???20.551144]????????CPU0????????????????????CPU1
> > [???20.555686]????????----????????????????????----
> > [???20.560224]???lock(fs_reclaim);
> > [???20.563386]????????????????????????????????local_irq_disable();
> > [???20.569315]????????????????????????????????lock(&(&substream-
> > > self_group.lock)->rlock);
> >
> > [???20.577337]????????????????????????????????lock(fs_reclaim);
> > [???20.583014]???<Interrupt>
> > [???20.585643]?????lock(&(&substream->self_group.lock)->rlock);
> > [???20.591322]?
> > [???20.591322]??*** DEADLOCK ***
> > [???20.591322]?
> > [???20.597260] 1 lock held by systemd/1:
> > [???20.607806]??#0: ab23d11c (snd_pcm_link_rwlock){.-..}, at:
> > snd_pcm_stream_lock+0x4c/0x60
> > [???20.615951]?
> > [???20.615951] the shortest dependencies between 2nd lock and 1st
> > lock:
> > [???20.623799]??-> (fs_reclaim){+.+.} ops: 248474 {
> > [???20.628456]?????HARDIRQ-ON-W at:
> > [???20.631716]???????????????????????lock_acquire+0x260/0x29c
> > [???20.637223]???????????????????????fs_reclaim_acquire+0x48/0x58
> > [???20.643075]???????????????????????kmem_cache_alloc_trace+0x3c/0x
> > 36
> > 4
> > [???20.649366]???????????????????????alloc_worker.constprop.15+0x28
> > /0
> > x64
> > [???20.655824]???????????????????????init_rescuer.part.5+0x20/0xa4
> > [???20.661764]???????????????????????workqueue_init+0x124/0x1f8
> > [???20.667446]???????????????????????kernel_init_freeable+0x60/0x55
> > 0
> > [???20.673561]???????????????????????kernel_init+0x18/0x120
> > [???20.678890]???????????????????????ret_from_fork+0x14/0x20
> > [???20.684299]?????????????????????????(null)
> > [???20.688408]?????SOFTIRQ-ON-W at:
> > [???20.691659]???????????????????????lock_acquire+0x260/0x29c
> > [???20.697158]???????????????????????fs_reclaim_acquire+0x48/0x58
> > [???20.703006]???????????????????????kmem_cache_alloc_trace+0x3c/0x
> > 36
> > 4
> > [???20.709288]???????????????????????alloc_worker.constprop.15+0x28
> > /0
> > x64
> > [???20.709301]???????????????????????init_rescuer.part.5+0x20/0xa4
> > [???20.720717]???????????????????????workqueue_init+0x124/0x1f8
> > [???20.720729]???????????????????????kernel_init_freeable+0x60/0x55
> > 0
> > [???20.720738]???????????????????????kernel_init+0x18/0x120
> > [???20.720746]???????????????????????ret_from_fork+0x14/0x20
> > [???20.720751]?????????????????????????(null)
> > [???20.720756]?????INITIAL USE at:
> > [???20.720770]??????????????????????lock_acquire+0x260/0x29c
> > [???20.720782]??????????????????????fs_reclaim_acquire+0x48/0x58
> > [???20.774374]??????????????????????kmem_cache_alloc_trace+0x3c/0x3
> > 64
> > [???20.780574]??????????????????????alloc_worker.constprop.15+0x28/
> > 0x
> > 64
> > [???20.786945]??????????????????????init_rescuer.part.5+0x20/0xa4
> > [???20.792794]??????????????????????workqueue_init+0x124/0x1f8
> > [???20.798384]??????????????????????kernel_init_freeable+0x60/0x550
> > [???20.804406]??????????????????????kernel_init+0x18/0x120
> > [???20.809648]??????????????????????ret_from_fork+0x14/0x20
> > [???20.814971]????????????????????????(null)
> > [???20.818992]???}
> > [???20.820768]???... key??????at: [<80e22074>]
> > __fs_reclaim_map+0x0/0x10
> > [???20.827220]???... acquired at:
> > [???20.830289]????fs_reclaim_acquire+0x48/0x58
> > [???20.834487]????kmem_cache_alloc_trace+0x3c/0x364
> > [???20.839123]????sdma_transfer_init+0x44/0x130
> > [???20.843409]????sdma_prep_dma_cyclic+0x78/0x21c
> > [???20.847869]????snd_dmaengine_pcm_trigger+0xdc/0x184
> > [???20.852764]????soc_pcm_trigger+0x164/0x190
> > [???20.856876]????snd_pcm_do_start+0x34/0x40
> > [???20.860902]????snd_pcm_action_single+0x48/0x74
> > [???20.865360]????snd_pcm_action+0x34/0xfc
> > [???20.869213]????snd_pcm_ioctl+0x910/0x10ec
> > [???20.873241]????vfs_ioctl+0x30/0x44
> > [???20.876657]????do_vfs_ioctl+0xac/0x974
> > [???20.880421]????ksys_ioctl+0x48/0x64
> > [???20.883923]????sys_ioctl+0x18/0x1c
> > [???20.887340]????ret_fast_syscall+0x0/0x28
> > [???20.891277]????0x7289bcbc
> > [???20.893909]?
> > [???20.895410] -> (&(&substream->self_group.lock)->rlock){-...}
> > ops:
> > 59 {
> > [???20.901977]????IN-HARDIRQ-W at:
> > [???20.905143]?????????????????????lock_acquire+0x260/0x29c
> > [???20.910473]?????????????????????_raw_spin_lock+0x48/0x58
> > [???20.915801]?????????????????????snd_pcm_stream_lock+0x54/0x60
> > [???20.921561]?????????????????????_snd_pcm_stream_lock_irqsave+0x4
> > 0/
> > 0x48
> > [???20.928107]?????????????????????snd_pcm_period_elapsed+0x2c/0xa4
> > [???20.934127]?????????????????????dmaengine_pcm_dma_complete+0x54/
> > 0x
> > 58
> > [???20.940498]?????????????????????sdma_int_handler+0x1dc/0x2a8
> > [???20.946179]?????????????????????__handle_irq_event_percpu+0x1fc/
> > 0x
> > 498
> > [???20.952635]?????????????????????handle_irq_event_percpu+0x38/0x8
> > c
> > [???20.958742]?????????????????????handle_irq_event+0x48/0x6c
> > [???20.964242]?????????????????????handle_fasteoi_irq+0xc4/0x138
> > [???20.970006]?????????????????????generic_handle_irq+0x28/0x38
> > [???20.975681]?????????????????????__handle_domain_irq+0xb0/0xc4
> > [???20.981443]?????????????????????gic_handle_irq+0x68/0xa0
> > [???20.986769]?????????????????????__irq_svc+0x70/0xb0
> > [???20.991662]?????????????????????_raw_spin_unlock_irq+0x38/0x6c
> > [???20.997511]?????????????????????task_work_run+0x90/0xb8
> > [???21.002751]?????????????????????do_work_pending+0xc8/0xd0
> > [???21.008164]?????????????????????slow_work_pending+0xc/0x20
> > [???21.013661]?????????????????????0x76c77e86
> > [???21.017768]????INITIAL USE at:
> > [???21.020844]????????????????????lock_acquire+0x260/0x29c
> > [???21.026086]????????????????????_raw_spin_lock+0x48/0x58
> > [???21.031328]????????????????????snd_pcm_stream_lock+0x54/0x60
> > [???21.037002]????????????????????snd_pcm_stream_lock_irq+0x38/0x3c
> > [???21.043023]????????????????????snd_pcm_sync_ptr+0x214/0x260
> > [???21.048609]????????????????????snd_pcm_ioctl+0xbe0/0x10ec
> > [???21.054027]????????????????????vfs_ioctl+0x30/0x44
> > [???21.058832]????????????????????do_vfs_ioctl+0xac/0x974
> > [???21.063984]????????????????????ksys_ioctl+0x48/0x64
> > [???21.068875]????????????????????sys_ioctl+0x18/0x1c
> > [???21.073679]????????????????????ret_fast_syscall+0x0/0x28
> > [???21.079004]????????????????????0x7e9026dc
> > [???21.083023]??}
> > [???21.084710]??... key??????at: [<8162a6e4>] __key.31798+0x0/0x8
> > [???21.090552]??... acquired at:
> > [???21.093537]????mark_lock+0x3a4/0x69c
> > [???21.097128]????__lock_acquire+0x420/0x16d4
> > [???21.101239]????lock_acquire+0x260/0x29c
> > [???21.105091]????_raw_spin_lock+0x48/0x58
> > [???21.108940]????snd_pcm_stream_lock+0x54/0x60
> > [???21.113226]????_snd_pcm_stream_lock_irqsave+0x40/0x48
> > [???21.118296]????snd_pcm_period_elapsed+0x2c/0xa4
> > [???21.122841]????dmaengine_pcm_dma_complete+0x54/0x58
> > [???21.127735]????sdma_int_handler+0x1dc/0x2a8
> > [???21.131937]????__handle_irq_event_percpu+0x1fc/0x498
> > [???21.136915]????handle_irq_event_percpu+0x38/0x8c
> > [???21.141547]????handle_irq_event+0x48/0x6c
> > [???21.145570]????handle_fasteoi_irq+0xc4/0x138
> > [???21.149854]????generic_handle_irq+0x28/0x38
> > [???21.154052]????__handle_domain_irq+0xb0/0xc4
> > [???21.158335]????gic_handle_irq+0x68/0xa0
> > [???21.162184]????__irq_svc+0x70/0xb0
> > [???21.165601]????_raw_spin_unlock_irq+0x38/0x6c
> > [???21.169973]????task_work_run+0x90/0xb8
> > [???21.173735]????do_work_pending+0xc8/0xd0
> > [???21.177670]????slow_work_pending+0xc/0x20
> > [???21.181691]????0x76c77e86
> > [???21.184320]?
> > [???21.185821]?
> > [???21.185821] stack backtrace:
> > [???21.190198] CPU: 0 PID: 1 Comm: systemd Not tainted 4.17.0+
> > #1538
> > [???21.196303] Hardware name: Freescale i.MX6 Quad/DualLite (Device
> > Tree)
> > [???21.202841] Backtrace:?
> > [???21.205314] [<8010e318>] (dump_backtrace) from [<8010e604>]
> > (show_stack+0x20/0x24)
> > [???21.212900]??r7:80e9f3d0 r6:00000000 r5:60070193 r4:80e9f3d0
> > [???21.218581] [<8010e5e4>] (show_stack) from [<8099b660>]
> > (dump_stack+0xa4/0xd8)
> > [???21.225825] [<8099b5bc>] (dump_stack) from [<8017b52c>]
> > (print_irq_inversion_bug+0x15c/0x1fc)
> > [???21.234368]??r9:814da818 r8:00000001 r7:ee926c00 r6:00000000
> > r5:ee915bb0 r4:814da818
> > [???21.242133] [<8017b3d0>] (print_irq_inversion_bug) from
> > [<8017b6dc>] (check_usage_forwards+0x110/0x13c)
> > [???21.251544]??r9:00000002 r8:80bfd3e2 r7:ee926c00 r6:ee927148
> > r5:80e08488 r4:00000001
> > [???21.259306] [<8017b5cc>] (check_usage_forwards) from
> > [<8017c2a4>]
> > (mark_lock+0x3a4/0x69c)
> > [???21.267500]??r9:ee926c00 r8:80a03cd8 r7:00000101 r6:00000002
> > r5:00000000 r4:ee927148
> > [???21.275263] [<8017bf00>] (mark_lock) from [<8017cf68>]
> > (__lock_acquire+0x420/0x16d4)
> > [???21.283023]??r10:ee927148 r9:ed4620e4 r8:ee926c00 r7:00000000
> > r6:00000001 r5:00000001
> > [???21.290863]??r4:00000490
> > [???21.293416] [<8017cb48>] (__lock_acquire) from [<8017ed58>]
> > (lock_acquire+0x260/0x29c)
> > [???21.301350]??r10:00000001 r9:80e084a4 r8:00000000 r7:00000000
> > r6:00000000 r5:ed4620e4
> > [???21.309189]??r4:00000000
> > [???21.311746] [<8017eaf8>] (lock_acquire) from [<809b74f0>]
> > (_raw_spin_lock+0x48/0x58)
> > [???21.319506]??r10:ee0a4714 r9:ed457100 r8:ee0a46c8 r7:ee0a4714
> > r6:ee0a4010 r5:807847b0
> > [???21.327346]??r4:ed4620d4
> > [???21.329902] [<809b74a8>] (_raw_spin_lock) from [<807847b0>]
> > (snd_pcm_stream_lock+0x54/0x60)
> > [???21.338265]??r5:ed462000 r4:ed462000
> > [???21.341863] [<8078475c>] (snd_pcm_stream_lock) from [<80784838>]
> > (_snd_pcm_stream_lock_irqsave+0x40/0x48)
> > [???21.351440]??r5:ed462000 r4:60070193
> > [???21.355042] [<807847f8>] (_snd_pcm_stream_lock_irqsave) from
> > [<8078b044>] (snd_pcm_period_elapsed+0x2c/0xa4)
> > [???21.364881]??r5:ee3ef000 r4:ed462000
> > [???21.368478] [<8078b018>] (snd_pcm_period_elapsed) from
> > [<8078d7b4>] (dmaengine_pcm_dma_complete+0x54/0x58)
> > [???21.378148]??r7:ee0a4714 r6:ee0a4010 r5:00000007 r4:ee0a46bc
> > [???21.383827] [<8078d760>] (dmaengine_pcm_dma_complete) from
> > [<80504c0c>] (sdma_int_handler+0x1dc/0x2a8)
> > [???21.393157] [<80504a30>] (sdma_int_handler) from [<8018cd28>]
> > (__handle_irq_event_percpu+0x1fc/0x498)
> > [???21.402393]??r10:00000000 r9:eeafd400 r8:80e084a4 r7:00000038
> > r6:00000038 r5:80ea3c12
> > [???21.410233]??r4:ee2b5d40
> > [???21.412787] [<8018cb2c>] (__handle_irq_event_percpu) from
> > [<8018cffc>] (handle_irq_event_percpu+0x38/0x8c)
> > [???21.422457]??r10:00000000 r9:ee914000 r8:ee81d400 r7:00000038
> > r6:eeafd400 r5:eeafd464
> > [???21.430296]??r4:80e08488
> > [???21.432852] [<8018cfc4>] (handle_irq_event_percpu) from
> > [<8018d098>] (handle_irq_event+0x48/0x6c)
> > [???21.441736]??r6:eeafd464 r5:eeafd464 r4:eeafd400
> > [???21.446374] [<8018d050>] (handle_irq_event) from [<8019146c>]
> > (handle_fasteoi_irq+0xc4/0x138)
> > [???21.454912]??r7:00000038 r6:eeafd464 r5:80e10a60 r4:eeafd400
> > [???21.460589] [<801913a8>] (handle_fasteoi_irq) from [<8018bd9c>]
> > (generic_handle_irq+0x28/0x38)
> > [???21.469214]??r7:00000038 r6:80d92ae4 r5:00000000 r4:00000000
> > [???21.474893] [<8018bd74>] (generic_handle_irq) from [<8018c48c>]
> > (__handle_domain_irq+0xb0/0xc4)
> > [???21.483611] [<8018c3dc>] (__handle_domain_irq) from [<80102330>]
> > (gic_handle_irq+0x68/0xa0)
> > [???21.491978]??r9:ee914000 r8:f4001100 r7:80e5c6bc r6:ee915f00
> > r5:80e08c3c r4:f4000100
> > [???21.499738] [<801022c8>] (gic_handle_irq) from [<801019f0>]
> > (__irq_svc+0x70/0xb0)
> > [???21.507233] Exception stack(0xee915f00 to 0xee915f48)
> > [???21.512303] 5f00: 00000001 00000004 00000000 ee926c00 ee9270a8
> > ee926c00 ecc45e00 ee9270a8
> > [???21.520498] 5f20: 80ec23b0 ee914000 00000000 ee915f64 ee915f20
> > ee915f50 8017c7c0 809b78ac
> > [???21.528687] 5f40: 20070013 ffffffff
> > [???21.532193]??r9:ee914000 r8:80ec23b0 r7:ee915f34 r6:ffffffff
> > r5:20070013 r4:809b78ac
> > [???21.539959] [<809b7874>] (_raw_spin_unlock_irq) from
> > [<8014e98c>]
> > (task_work_run+0x90/0xb8)
> > [???21.548321]??r5:ee926c00 r4:ecc45e00
> > [???21.551913] [<8014e8fc>] (task_work_run) from [<8010da3c>]
> > (do_work_pending+0xc8/0xd0)
> > [???21.559848]??r9:ee914000 r8:801011c4 r7:ee915fb0 r6:ffffe000
> > r5:00000004 r4:801011c4
> > [???21.567608] [<8010d974>] (do_work_pending) from [<80101034>]
> > (slow_work_pending+0xc/0x20)
> > [???21.575797] Exception stack(0xee915fb0 to 0xee915ff8)
> > [???21.580864] 5fa0:?????????????????????????????????????00000000
> > 020c34e8 46059f00 00000000
> > [???21.589059] 5fc0: 00000002 76f133a4 020df680 00000006 76e6e168
> > 00000035 7ef81778 00000035
> > [???21.597253] 5fe0: 00000006 7ef816a0 76c75d67 76c77e86 20070030
> > 00000039
> > [???21.603883]??r7:00000006 r6:020df680 r5:76f133a4 r4:00000002
> >
> > Am Donnerstag, den 14.06.2018, 22:02 +0800 schrieb Robin Gong:
> > >
> > > The legacy sdma driver has below limitations or drawbacks:
> > > ? 1. Hardcode the max BDs number as "PAGE_SIZE / sizeof(*)", and
> > > alloc
> > > ?????one page size for one channel regardless of only few BDs
> > > needed
> > > ?????most time. But in few cases, the max PAGE_SIZE maybe not
> > > enough.
> > > ? 2. One SDMA channel can't stop immediatley once channel
> > > disabled
> > > which
> > > ?????means SDMA interrupt may come in after this channel
> > > terminated.There
> > > ?????are some patches for this corner case such as commit
> > > "2746e2c389f9",
> > > ?????but not cover non-cyclic.
> > >
> > > The common virt-dma overcomes the above limitations. It can alloc
> > > bd
> > > dynamically and free bd once this tx transfer done. No memory
> > > wasted or
> > > maximum limititation here, only depends on how many memory can be
> > > requested
> > > from kernel. For No.2, such issue can be workaround by checking
> > > if
> > > there
> > > is available descript("sdmac->desc") now once the unwanted
> > > interrupt
> > > coming. At last the common virt-dma is easier for sdma driver
> > > maintain.
> > >
> > > Change from v3:
> > > ? 1. add two uart patches which impacted by this patchset.
> > > ? 2. unlock 'vc.lock' before cyclic dma callback and lock again
> > > after
> > > ?????it because some driver such as uart will call
> > > dmaengine_tx_status
> > > ?????which will acquire 'vc.lock' again and dead lock comes out.
> > > ? 3. remove 'Revert commit' stuff since that patch is not wrong
> > > and
> > > ?????combine two patch into one patch as Sascha's comment.
> > >
> > > Change from v2:
> > > ? 1. include Sascha's patch to make the main patch easier to
> > > review.
> > > ?????Thanks Sacha.
> > > ? 2. remove useless 'desc'/'chan' in struct sdma_channe.
> > >
> > > Change from v1:
> > > ? 1. split v1 patch into 5 patches.
> > > ? 2. remove some unnecessary condition check.
> > > ? 3. remove unnecessary 'pending' list.
> > >
> > > Robin Gong (6):
> > > ? tty: serial: imx: correct dma cookie status
> > > ? dmaengine: imx-sdma: add virt-dma support
> > > ? dmaengine: imx-sdma: remove useless 'lock' and 'enabled' in
> > > 'struct
> > > ????sdma_channel'
> > > ? dmaengine: imx-sdma: remove the maximum limitation for bd
> > > numbers
> > > ? dmaengine: imx-sdma: add sdma_transfer_init to decrease code
> > > overlap
> > > ? tty: serial: imx: split all dma setup operations out of
> > > 'port.lock'
> > > ????protector
> > >
> > > Sascha Hauer (1):
> > > ? dmaengine: imx-sdma: factor out a struct sdma_desc from struct
> > > ????sdma_channel
> > >
> > > ?drivers/dma/Kconfig??????|???1 +
> > > ?drivers/dma/imx-sdma.c???| 394 +++++++++++++++++++++++++++------
> > > --------------
> > > ?drivers/tty/serial/imx.c |??99 ++++++------
> > > ?3 files changed, 282 insertions(+), 212 deletions(-)
^ permalink raw reply
* [PATCH v1 4/4] mailbox: Add support for i.MX7D messaging unit
From: Oleksij Rempel @ 2018-06-14 10:24 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAA+hA=RpoRXUK+jB18F4OeYE9PG73SDa_NLYeN5Q2G3B1bC-JA@mail.gmail.com>
On Wed, Jun 13, 2018 at 08:21:10PM +0800, Dong Aisheng wrote:
> Hi Oleksij,
>
> On Fri, Jun 1, 2018 at 2:58 PM, Oleksij Rempel <o.rempel@pengutronix.de> wrote:
> > The Mailbox controller is able to send messages (up to 4 32 bit words)
> > between the endpoints.
>
> Could we really be able to send up to 4 42bit words with this driver?
>
> It looks to me the current Mailbox framework is more designed for share mem
> transfer which does not fit i.MX MU well.
It is possible to set mbox_chan_txdone as soon as one of 4 regs is
written. Even more, it looks like, it should be possible to make a 8
channel mailbox on top of one MU. But i don't have any reason or use
case to implement and test it now.
> >
> > This driver was tested using the mailbox-test driver sending messages
> > between the Cortex-A7 and the Cortex-M4.
>
> Would you please provide a guide on how to test it quickly?
> I may want to give a test.
I use Linux on both side. The linux on M4 is booted over remoteproc.
Currently not all needed parts are upstream. I'll prepare a BSP to build
all components as soon as possible.
>
> >
> > Signed-off-by: Oleksij Rempel <o.rempel@pengutronix.de>
> > ---
> > drivers/mailbox/Kconfig | 6 +
> > drivers/mailbox/Makefile | 2 +
> > drivers/mailbox/imx-mailbox.c | 289 ++++++++++++++++++++++++++++++++++
> > 3 files changed, 297 insertions(+)
> > create mode 100644 drivers/mailbox/imx-mailbox.c
> >
> > diff --git a/drivers/mailbox/Kconfig b/drivers/mailbox/Kconfig
> > index a2bb27446dce..e1d2738a2e4c 100644
> > --- a/drivers/mailbox/Kconfig
> > +++ b/drivers/mailbox/Kconfig
> > @@ -15,6 +15,12 @@ config ARM_MHU
> > The controller has 3 mailbox channels, the last of which can be
> > used in Secure mode only.
> >
> > +config IMX_MBOX
> > + tristate "iMX Mailbox"
> > + depends on SOC_IMX7D || COMPILE_TEST
> > + help
> > + Mailbox implementation for iMX7D Messaging Unit (MU).
> > +
> > config PLATFORM_MHU
> > tristate "Platform MHU Mailbox"
> > depends on OF
> > diff --git a/drivers/mailbox/Makefile b/drivers/mailbox/Makefile
> > index cc23c3a43fcd..ba2fe1b6dd62 100644
> > --- a/drivers/mailbox/Makefile
> > +++ b/drivers/mailbox/Makefile
> > @@ -7,6 +7,8 @@ obj-$(CONFIG_MAILBOX_TEST) += mailbox-test.o
> >
> > obj-$(CONFIG_ARM_MHU) += arm_mhu.o
> >
> > +obj-$(CONFIG_IMX_MBOX) += imx-mailbox.o
> > +
> > obj-$(CONFIG_PLATFORM_MHU) += platform_mhu.o
> >
> > obj-$(CONFIG_PL320_MBOX) += pl320-ipc.o
> > diff --git a/drivers/mailbox/imx-mailbox.c b/drivers/mailbox/imx-mailbox.c
> > new file mode 100644
> > index 000000000000..2bc9f11393b1
> > --- /dev/null
> > +++ b/drivers/mailbox/imx-mailbox.c
> > @@ -0,0 +1,289 @@
> > +// SPDX-License-Identifier: GPL-2.0
> > +/*
> > + * Copyright (c) 2018 Pengutronix, Oleksij Rempel <o.rempel@pengutronix.de>
> > + */
> > +
> > +#include <linux/clk.h>
> > +#include <linux/interrupt.h>
> > +#include <linux/io.h>
> > +#include <linux/kernel.h>
> > +#include <linux/mailbox_controller.h>
> > +#include <linux/module.h>
> > +#include <linux/of_device.h>
> > +
> > +/* Transmit Register */
> > +#define IMX_MU_xTRn(x) (0x00 + 4 * (x))
> > +/* Receive Register */
> > +#define IMX_MU_xRRn(x) (0x10 + 4 * (x))
> > +/* Status Register */
> > +#define IMX_MU_xSR 0x20
> > +#define IMX_MU_xSR_TEn(x) BIT(20 + (x))
> > +#define IMX_MU_xSR_RFn(x) BIT(24 + (x))
> > +#define IMX_MU_xSR_BRDIP BIT(9)
> > +
> > +/* Control Register */
> > +#define IMX_MU_xCR 0x24
> > +/* Transmit Interrupt Enable */
> > +#define IMX_MU_xCR_TIEn(x) BIT(20 + (x))
> > +/* Receive Interrupt Enable */
> > +#define IMX_MU_xCR_RIEn(x) BIT(24 + (x))
> > +
> > +#define IMX_MU_MAX_CHANS 4u
> > +
> > +struct imx_mu_priv;
> > +
> > +struct imx_mu_cfg {
> > + unsigned int chans;
> > + void (*init_hw)(struct imx_mu_priv *priv);
> > +};
> > +
> > +struct imx_mu_con_priv {
> > + int irq;
> > + unsigned int bidx;
> > + unsigned int idx;
> > +};
> > +
> > +struct imx_mu_priv {
> > + struct device *dev;
> > + const struct imx_mu_cfg *dcfg;
> > + void __iomem *base;
> > +
> > + struct mbox_controller mbox;
> > + struct mbox_chan mbox_chans[IMX_MU_MAX_CHANS];
> > +
> > + struct imx_mu_con_priv con_priv[IMX_MU_MAX_CHANS];
> > + struct clk *clk;
> > +};
> > +
> > +static struct imx_mu_priv *to_imx_mu_priv(struct mbox_controller *mbox)
> > +{
> > + return container_of(mbox, struct imx_mu_priv, mbox);
> > +}
> > +
> > +static void imx_mu_write(struct imx_mu_priv *priv, u32 val, u32 offs)
> > +{
> > + iowrite32(val, priv->base + offs);
> > +}
> > +
> > +static u32 imx_mu_read(struct imx_mu_priv *priv, u32 offs)
> > +{
> > + return ioread32(priv->base + offs);
> > +}
> > +
> > +static u32 imx_mu_rmw(struct imx_mu_priv *priv, u32 offs, u32 set, u32 clr)
> > +{
> > + u32 val;
> > +
> > + val = imx_mu_read(priv, offs);
> > + val &= ~clr;
> > + val |= set;
> > + imx_mu_write(priv, val, offs);
> > +
> > + return val;
> > +}
> > +
> > +static irqreturn_t imx_mu_isr(int irq, void *p)
> > +{
> > + struct mbox_chan *chan = p;
> > + struct imx_mu_con_priv *cp = chan->con_priv;
> > + struct imx_mu_priv *priv = to_imx_mu_priv(chan->mbox);
>
> Please do in reversed order from long to short
done
> > +
> > + u32 val, dat;
> > +
> > + val = imx_mu_read(priv, IMX_MU_xSR);
> > + val &= IMX_MU_xSR_TEn(cp->bidx) | IMX_MU_xSR_RFn(cp->bidx);
> > + if (!val)
> > + return IRQ_NONE;
> > +
> > + if (val & IMX_MU_xSR_TEn(cp->bidx)) {
> > + imx_mu_rmw(priv, IMX_MU_xCR, 0, IMX_MU_xCR_TIEn(cp->bidx));
> > + mbox_chan_txdone(chan, 0);
> > + }
> > +
> > + if (val & IMX_MU_xSR_RFn(cp->bidx)) {
> > + dat = imx_mu_read(priv, IMX_MU_xRRn(cp->idx));
> > + mbox_chan_received_data(chan, (void *)&dat);
> > + }
> > +
> > + return IRQ_HANDLED;
> > +}
> > +
> > +static bool imx_mu_last_tx_done(struct mbox_chan *chan)
> > +{
> > + struct imx_mu_priv *priv = to_imx_mu_priv(chan->mbox);
> > + struct imx_mu_con_priv *cp = chan->con_priv;
> > + u32 val;
> > +
> > + val = imx_mu_read(priv, IMX_MU_xSR);
> > + /* test if transmit register is empty */
> > + return (!(val & IMX_MU_xSR_TEn(cp->bidx)));
> > +}
> > +
> > +static int imx_mu_send_data(struct mbox_chan *chan, void *data)
> > +{
> > + struct imx_mu_priv *priv = to_imx_mu_priv(chan->mbox);
> > + struct imx_mu_con_priv *cp = chan->con_priv;
> > + u32 *arg = data;
> > +
> > + if (imx_mu_last_tx_done(chan))
>
> return true for tx_done?
> Or maybe better imx_mu_is_busy?
I'll the name and rework the logic. For polling, if this will be ever
used.
> > + return -EBUSY;
> > +
> > + imx_mu_write(priv, *arg, IMX_MU_xTRn(cp->idx));
> > + imx_mu_rmw(priv, IMX_MU_xCR, IMX_MU_xSR_TEn(cp->bidx), 0);
> > +
> > + return 0;
> > +}
> > +
> > +static int imx_mu_startup(struct mbox_chan *chan)
> > +{
> > + struct imx_mu_priv *priv = to_imx_mu_priv(chan->mbox);
> > + struct imx_mu_con_priv *cp = chan->con_priv;
> > + int ret;
> > +
> > + ret = request_irq(cp->irq, imx_mu_isr,
> > + IRQF_SHARED, "imx_mu_chan", chan);
>
> This looks me to a bit strange as all virtual channels interrupts
> line actually are the same. And we request that same irq line
> repeatedly here with the same irq handler.
Why not? Code is simple and performance should not be noticeable.
> > + if (ret) {
> > + dev_err(chan->mbox->dev,
> > + "Unable to acquire IRQ %d\n", cp->irq);
> > + return ret;
> > + }
> > +
> > + imx_mu_rmw(priv, IMX_MU_xCR, IMX_MU_xCR_RIEn(cp->bidx), 0);
> > +
> > + return 0;
> > +}
> > +
> > +static void imx_mu_shutdown(struct mbox_chan *chan)
> > +{
> > + struct imx_mu_priv *priv = to_imx_mu_priv(chan->mbox);
> > + struct imx_mu_con_priv *cp = chan->con_priv;
> > +
> > + imx_mu_rmw(priv, IMX_MU_xCR, 0,
> > + IMX_MU_xCR_TIEn(cp->bidx) | IMX_MU_xCR_RIEn(cp->bidx));
> > +
> > + free_irq(cp->irq, chan);
> > +}
> > +
> > +static const struct mbox_chan_ops imx_mu_ops = {
> > + .send_data = imx_mu_send_data,
> > + .startup = imx_mu_startup,
> > + .shutdown = imx_mu_shutdown,
> > + .last_tx_done = imx_mu_last_tx_done,
>
> Do we really need this?
> Looking at the code, it seems .last_tx_done() is only called for polling mode.
> But what you set below is:
> priv->mbox.txdone_irq = true;
>
> Or am i missed something?
no. I'll remove it for now.
>
> > +};
> > +
> > +static int imx_mu_probe(struct platform_device *pdev)
> > +{
> > + struct device *dev = &pdev->dev;
> > + struct resource *iomem;
> > + struct imx_mu_priv *priv;
> > + const struct imx_mu_cfg *dcfg;
> > + unsigned int i, chans;
> > + int irq, ret;
> > +
> > + priv = devm_kzalloc(dev, sizeof(*priv), GFP_KERNEL);
> > + if (!priv)
> > + return -ENOMEM;
> > +
> > + dcfg = of_device_get_match_data(dev);
> > + if (!dcfg)
> > + return -EINVAL;
> > +
> > + priv->dcfg = dcfg;
> > + priv->dev = dev;
> > +
> > + iomem = platform_get_resource(pdev, IORESOURCE_MEM, 0);
> > + priv->base = devm_ioremap_resource(&pdev->dev, iomem);
> > + if (IS_ERR(priv->base))
> > + return PTR_ERR(priv->base);
> > +
> > + irq = platform_get_irq(pdev, 0);
> > + if (irq <= 0)
> > + return irq < 0 ? irq : -EINVAL;
>
> Is it possible == 0?
no:
https://elixir.bootlin.com/linux/latest/source/drivers/base/platform.c#L86
or do I miss some thing?
> > +
> > + priv->clk = devm_clk_get(dev, NULL);
> > + if (IS_ERR(priv->clk)) {
> > + if (PTR_ERR(priv->clk) == -ENOENT) {
> > + priv->clk = NULL;
> > + } else {
> > + dev_err(dev, "Failed to get clock\n");
>
> The line looks not be quite meaningful as it may be defer probe.
What is your suggestion?
> > + return PTR_ERR(priv->clk);
> > + }
> > + }
> > +
> > + ret = clk_prepare_enable(priv->clk);
> > + if (ret) {
> > + dev_err(dev, "Failed to enable clock\n");
> > + return ret;
> > + }
> > +
> > + chans = min(dcfg->chans, IMX_MU_MAX_CHANS);
> > + /* Initialize channel identifiers */
> > + for (i = 0; i < chans; i++) {
> > + struct imx_mu_con_priv *cp = &priv->con_priv[i];
> > +
> > + cp->bidx = 3 - i;
> > + cp->idx = i;
> > + cp->irq = irq;
> > + priv->mbox_chans[i].con_priv = cp;
> > + }
> > +
> > + priv->mbox.dev = dev;
> > + priv->mbox.ops = &imx_mu_ops;
> > + priv->mbox.chans = priv->mbox_chans;
> > + priv->mbox.num_chans = chans;
> > + priv->mbox.txdone_irq = true;
> > +
> > + platform_set_drvdata(pdev, priv);
> > +
> > + if (priv->dcfg->init_hw)
> > + priv->dcfg->init_hw(priv);
> > +
> > + return mbox_controller_register(&priv->mbox);
> > +}
> > +
> > +static int imx_mu_remove(struct platform_device *pdev)
> > +{
> > + struct imx_mu_priv *priv = platform_get_drvdata(pdev);
> > +
> > + mbox_controller_unregister(&priv->mbox);
> > + clk_disable_unprepare(priv->clk);
> > +
> > + return 0;
> > +}
> > +
> > +
> > +static void imx_mu_init_imx7d_a(struct imx_mu_priv *priv)
> > +{
> > + /* Set default config */
> > + imx_mu_write(priv, 0, IMX_MU_xCR);
> > +}
> > +
> > +static const struct imx_mu_cfg imx_mu_cfg_imx7d_a = {
> > + .chans = IMX_MU_MAX_CHANS,
> > + .init_hw = imx_mu_init_imx7d_a,
> > +};
> > +
> > +static const struct imx_mu_cfg imx_mu_cfg_imx7d_b = {
> > + .chans = IMX_MU_MAX_CHANS,
> > +};
> > +
> > +static const struct of_device_id imx_mu_dt_ids[] = {
> > + { .compatible = "fsl,imx7s-mu-a", .data = &imx_mu_cfg_imx7d_a },
> > + { .compatible = "fsl,imx7s-mu-b", .data = &imx_mu_cfg_imx7d_b },
> > + { },
> > +};
> > +MODULE_DEVICE_TABLE(of, imx_mu_dt_ids);
> > +
> > +static struct platform_driver imx_mu_driver = {
> > + .probe = imx_mu_probe,
> > + .remove = imx_mu_remove,
> > + .driver = {
> > + .name = "imx_mu",
> > + .of_match_table = imx_mu_dt_ids,
> > + },
> > +};
> > +module_platform_driver(imx_mu_driver);
> > +
> > +MODULE_AUTHOR("Oleksij Rempel <o.rempel@pengutronix.de>");
> > +MODULE_DESCRIPTION("Message Unit driver for i.MX7");
>
> s/i.MX7/i.MX
ok
> Regards
> Dong Aisheng
thank you for review.
--
Pengutronix e.K. | |
Industrial Linux Solutions | http://www.pengutronix.de/ |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0 |
Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 |
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20180614/00022757/attachment.sig>
^ permalink raw reply
* [PATCH v1] ARM: dts: imx6sx: fix irq for pcie bridge
From: Lucas Stach @ 2018-06-14 10:28 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180614094527.25905-1-o.rempel@pengutronix.de>
Am Donnerstag, den 14.06.2018, 11:45 +0200 schrieb Oleksij Rempel:
> Without this patch MSI interrupts are not routed from Intel
> i350 PCIe adapter.
This has nothing to do with the attached endpoint device, so the commit
message should read something like:
Use the correct IRQ line for the MSI controller in the PCIe host
controller. Apparently a different IRQ line is used compared to other
i.MX6 variants. Without this change MSI IRQs aren't properly propagated
to the the upstream interrupt controller.
With this fixed:
Reviewed-by: Lucas Stach <l.stach@pengutronix.de>
> > Signed-off-by: Oleksij Rempel <o.rempel@pengutronix.de>
> ---
> ?arch/arm/boot/dts/imx6sx.dtsi | 2 +-
> ?1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/arch/arm/boot/dts/imx6sx.dtsi b/arch/arm/boot/dts/imx6sx.dtsi
> index 49c7205b8db8..77fdad65e2bb 100644
> --- a/arch/arm/boot/dts/imx6sx.dtsi
> +++ b/arch/arm/boot/dts/imx6sx.dtsi
> @@ -1351,7 +1351,7 @@
> > ? ranges = <0x81000000 0 0??????????0x08f80000 0 0x00010000 /* downstream I/O */
> > ? ??0x82000000 0 0x08000000 0x08000000 0 0x00f00000>; /* non-prefetchable memory */
> > ? num-lanes = <1>;
> > - interrupts = <GIC_SPI 123 IRQ_TYPE_LEVEL_HIGH>;
> > + interrupts = <GIC_SPI 120 IRQ_TYPE_LEVEL_HIGH>;
> > ? interrupt-names = "msi";
> > ? #interrupt-cells = <1>;
> > ? interrupt-map-mask = <0 0 0 0x7>;
^ permalink raw reply
* [PATCH v3 0/6] thermal: tsens: Refactoring for TSENSv2 IP
From: Amit Kucheria @ 2018-06-14 10:43 UTC (permalink / raw)
To: linux-arm-kernel
This series is a mixed bag: Some code moves to deal with v2 of the
TSENS IP into common functions, a new qcom,tsens-v2 DT property to cover
all v2 platforms, new platform support (sdm845), a cleanup
patch and a DT change to have a common way to deal with the SROT and TM
registers despite slightly different features across the IP family and
different register offsets.
Rob, I haven't added your Ack to patch 4 because it changed a bit.
Regards,
Amit
Changes since v2:
- Based on review, moved tsens-8996.c to tsens-v2.c and changed
corresponding function names, struct names to allow for generic tsensv2
platforms
- All v2 platforms will now only need to use the qcom,tsen-v2 property
- Added a DT patch to initialize tsens driver on sdm845, now that 4.18-rc1
will contain an sdm845.dtsi
Changes since v1:
- Move get_temp() from tsens-8996 to tsens-common and rename
- Change 8996 DT entry to allow init_common() to work across sdm845 and
8996 due to different offsets
Amit Kucheria (6):
thermal: tsens: Get rid of unused fields in structure
dt: qcom: 8996: thermal: Move to DT initialisation
thermal: tsens: Rename tsens-8996 to tsens-v2 for reuse
thermal: tsens: Add support for SDM845
thermal: tsens: Check if we have valid data before reading
arm64: dts: sdm845: Add tsens nodes
.../devicetree/bindings/thermal/qcom-tsens.txt | 1 +
arch/arm64/boot/dts/qcom/msm8996.dtsi | 12 ++++++-
arch/arm64/boot/dts/qcom/sdm845.dtsi | 16 +++++++++
drivers/thermal/qcom/Makefile | 2 +-
drivers/thermal/qcom/{tsens-8996.c => tsens-v2.c} | 42 +++++++++++++---------
drivers/thermal/qcom/tsens.c | 3 ++
drivers/thermal/qcom/tsens.h | 7 ++--
7 files changed, 61 insertions(+), 22 deletions(-)
rename drivers/thermal/qcom/{tsens-8996.c => tsens-v2.c} (65%)
--
2.7.4
^ permalink raw reply
* [PATCH v3 2/6] dt: qcom: 8996: thermal: Move to DT initialisation
From: Amit Kucheria @ 2018-06-14 10:43 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <cover.1528972165.git.amit.kucheria@linaro.org>
We also split up the regmap address space into two, one for the TM
registers, the other for the SROT registers. This was required to deal with
different address offsets for the TM and SROT registers across different
SoC families.
Since tsens-common.c/init_common() currently only registers one address
space, the order is important (TM before SROT). This is OK since the code
doesn't really use the SROT functionality yet.
Signed-off-by: Amit Kucheria <amit.kucheria@linaro.org>
---
arch/arm64/boot/dts/qcom/msm8996.dtsi | 12 +++++++++++-
1 file changed, 11 insertions(+), 1 deletion(-)
diff --git a/arch/arm64/boot/dts/qcom/msm8996.dtsi b/arch/arm64/boot/dts/qcom/msm8996.dtsi
index 8c7f9ca..6c8a857 100644
--- a/arch/arm64/boot/dts/qcom/msm8996.dtsi
+++ b/arch/arm64/boot/dts/qcom/msm8996.dtsi
@@ -461,7 +461,17 @@
tsens0: thermal-sensor at 4a8000 {
compatible = "qcom,msm8996-tsens";
- reg = <0x4a8000 0x2000>;
+ reg = <0x4a9000 0x1000>, /* TM */
+ <0x4a8000 0x1000>; /* SROT */
+ #qcom,sensors = <13>;
+ #thermal-sensor-cells = <1>;
+ };
+
+ tsens1: thermal-sensor at 4ac000 {
+ compatible = "qcom,msm8996-tsens";
+ reg = <0x4ad000 0x1000>, /* TM */
+ <0x4ac000 0x1000>; /* SROT */
+ #qcom,sensors = <8>;
#thermal-sensor-cells = <1>;
};
--
2.7.4
^ permalink raw reply related
* [PATCH v3 4/6] thermal: tsens: Add support for SDM845
From: Amit Kucheria @ 2018-06-14 10:43 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <cover.1528972165.git.amit.kucheria@linaro.org>
SDM845 uses the TSENS v2 IP block
Signed-off-by: Amit Kucheria <amit.kucheria@linaro.org>
---
Documentation/devicetree/bindings/thermal/qcom-tsens.txt | 1 +
arch/arm64/boot/dts/qcom/msm8996.dtsi | 2 +-
drivers/thermal/qcom/tsens-v2.c | 9 ++++++++-
drivers/thermal/qcom/tsens.c | 3 +++
drivers/thermal/qcom/tsens.h | 5 ++++-
5 files changed, 17 insertions(+), 3 deletions(-)
diff --git a/Documentation/devicetree/bindings/thermal/qcom-tsens.txt b/Documentation/devicetree/bindings/thermal/qcom-tsens.txt
index 06195e8..84da3db 100644
--- a/Documentation/devicetree/bindings/thermal/qcom-tsens.txt
+++ b/Documentation/devicetree/bindings/thermal/qcom-tsens.txt
@@ -5,6 +5,7 @@ Required properties:
- "qcom,msm8916-tsens" : For 8916 Family of SoCs
- "qcom,msm8974-tsens" : For 8974 Family of SoCs
- "qcom,msm8996-tsens" : For 8996 Family of SoCs
+ - "qcom,tsens-v2" : For any SoC with v2 version of the tsens IP
- reg: Address range of the thermal registers
- #thermal-sensor-cells : Should be 1. See ./thermal.txt for a description.
diff --git a/arch/arm64/boot/dts/qcom/msm8996.dtsi b/arch/arm64/boot/dts/qcom/msm8996.dtsi
index 6c8a857..28d4c08 100644
--- a/arch/arm64/boot/dts/qcom/msm8996.dtsi
+++ b/arch/arm64/boot/dts/qcom/msm8996.dtsi
@@ -460,7 +460,7 @@
};
tsens0: thermal-sensor at 4a8000 {
- compatible = "qcom,msm8996-tsens";
+ compatible = "qcom,msm8996-tsens", "qcom,tsens-v2";
reg = <0x4a9000 0x1000>, /* TM */
<0x4a8000 0x1000>; /* SROT */
#qcom,sensors = <13>;
diff --git a/drivers/thermal/qcom/tsens-v2.c b/drivers/thermal/qcom/tsens-v2.c
index c981a40..abc8f13 100644
--- a/drivers/thermal/qcom/tsens-v2.c
+++ b/drivers/thermal/qcom/tsens-v2.c
@@ -69,8 +69,15 @@ static const struct tsens_ops ops_v2 = {
.get_temp = get_temp_tsens_v2,
};
+const struct tsens_data data_tsens_v2 = {
+ .ops = &ops_v2,
+};
+
+/* Kept around for backward compatibility with old msm8996.dtsi.
+ * New platforms should use data_tsens_v2 if possible and define
+ * the #qcom,sensors property in DT.
+ */
const struct tsens_data data_8996 = {
.num_sensors = 13,
.ops = &ops_v2,
};
-
diff --git a/drivers/thermal/qcom/tsens.c b/drivers/thermal/qcom/tsens.c
index 3440166c..a2c9bfa 100644
--- a/drivers/thermal/qcom/tsens.c
+++ b/drivers/thermal/qcom/tsens.c
@@ -72,6 +72,9 @@ static const struct of_device_id tsens_table[] = {
}, {
.compatible = "qcom,msm8996-tsens",
.data = &data_8996,
+ }, {
+ .compatible = "qcom,tsens-v2",
+ .data = &data_tsens_v2,
},
{}
};
diff --git a/drivers/thermal/qcom/tsens.h b/drivers/thermal/qcom/tsens.h
index dc56e1e..69212cb 100644
--- a/drivers/thermal/qcom/tsens.h
+++ b/drivers/thermal/qcom/tsens.h
@@ -87,6 +87,9 @@ void compute_intercept_slope(struct tsens_device *, u32 *, u32 *, u32);
int init_common(struct tsens_device *);
int get_temp_common(struct tsens_device *, int, int *);
-extern const struct tsens_data data_8916, data_8974, data_8960, data_8996;
+/* TSENS v1 targets */
+extern const struct tsens_data data_8916, data_8974, data_8960;
+/* TSENS v2 targets */
+extern const struct tsens_data data_8996, data_tsens_v2;
#endif /* __QCOM_TSENS_H__ */
--
2.7.4
^ permalink raw reply related
* [PATCH v3 6/6] arm64: dts: sdm845: Add tsens nodes
From: Amit Kucheria @ 2018-06-14 10:43 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <cover.1528972165.git.amit.kucheria@linaro.org>
SDM845 has two tsens blocks, one with 13 sensors and the other with 8
sensors.
Signed-off-by: Amit Kucheria <amit.kucheria@linaro.org>
---
arch/arm64/boot/dts/qcom/sdm845.dtsi | 16 ++++++++++++++++
1 file changed, 16 insertions(+)
diff --git a/arch/arm64/boot/dts/qcom/sdm845.dtsi b/arch/arm64/boot/dts/qcom/sdm845.dtsi
index cdaabeb..7dd59b4 100644
--- a/arch/arm64/boot/dts/qcom/sdm845.dtsi
+++ b/arch/arm64/boot/dts/qcom/sdm845.dtsi
@@ -221,6 +221,22 @@
#interrupt-cells = <2>;
};
+ tsens0: tsens at c222000 {
+ compatible = "qcom,tsens-v2";
+ reg = <0xc263000 0x1ff>, /* TM */
+ <0xc222000 0x1ff>; /* SROT */
+ #qcom,sensors = <13>;
+ #thermal-sensor-cells = <1>;
+ };
+
+ tsens1: tsens at c223000 {
+ compatible = "qcom,tsens-v2";
+ reg = <0xc265000 0x1ff>, /* TM */
+ <0xc223000 0x1ff>; /* SROT */
+ #qcom,sensors = <8>;
+ #thermal-sensor-cells = <1>;
+ };
+
spmi_bus: spmi at c440000 {
compatible = "qcom,spmi-pmic-arb";
reg = <0xc440000 0x1100>,
--
2.7.4
^ permalink raw reply related
* [PATCH v5 0/3] Renesas R9A06G032 SMP enabler
From: Michel Pollet @ 2018-06-14 10:58 UTC (permalink / raw)
To: linux-arm-kernel
*WARNING -- this requires the base R9A06G032 support patches
already posted
This patch series is for enabling the second CA7 of the R9A06G032.
It's based on a spin_table method, and it reuses the same binding
property as that driver.
v5:
+ Fixed a couple of typos
+ Added the Reviewed-by tags where appropriate
+ Rebased on base patch v9
+ Replaced the dts property with a 64 bits one.
+ Changed the driver to support 32 or 64 bits property.
v4:
+ Geert's comments adressed.
+ Renamed symbols to r9a06g032 to match the rest of patchset
+ Rebased on base patch v8
v3:
+ Removed mentions of rz/?n1d?
+ Rebased on base patch v7
v2:
+ Added suggestions from Florian Fainelli
+ Use __pa_symbol()
+ Simplified logic in prepare_cpu()
+ Reordered the patches
+ Rebased on RZN1 Base patch v5
Michel Pollet (3):
dt-bindings: cpu: Add Renesas R9A06G032 SMP enable method.
arm: shmobile: Add the R9A06G032 SMP enabler driver
ARM: dts: Renesas R9A06G032 SMP enable method
Documentation/devicetree/bindings/arm/cpus.txt | 1 +
arch/arm/boot/dts/r9a06g032.dtsi | 2 +
arch/arm/mach-shmobile/Makefile | 1 +
arch/arm/mach-shmobile/smp-r9a06g032.c | 90 ++++++++++++++++++++++++++
4 files changed, 94 insertions(+)
create mode 100644 arch/arm/mach-shmobile/smp-r9a06g032.c
--
2.7.4
^ 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