* [PATCH v2 2/9] dmaengine: edma: Use enum for eDMA binding type (legacy vs TPCC)
From: Peter Ujfalusi @ 2016-09-21 11:07 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <7753810.Z3F41qkFaI@wuerfel>
On 09/21/16 13:31, Arnd Bergmann wrote:
> On Wednesday, September 21, 2016 1:26:30 PM CEST Peter Ujfalusi wrote:
>> diff --git a/drivers/dma/edma.c b/drivers/dma/edma.c
>> index c2098a4b4dcf..4c8818278fcc 100644
>> --- a/drivers/dma/edma.c
>> +++ b/drivers/dma/edma.c
>> @@ -261,8 +261,11 @@ static const struct edmacc_param dummy_paramset = {
>> .ccnt = 1,
>> };
>>
>> -#define EDMA_BINDING_LEGACY 0
>> -#define EDMA_BINDING_TPCC 1
>> +enum edma_binding_type {
>> + EDMA_BINDING_LEGACY = 0,
>> + EDMA_BINDING_TPCC,
>> +};
>> +
>> static const struct of_device_id edma_of_ids[] = {
>> {
>> .compatible = "ti,edma3",
>> @@ -2184,7 +2187,8 @@ static int edma_probe(struct platform_device *pdev)
>> const struct of_device_id *match;
>>
>> match = of_match_node(edma_of_ids, node);
>> - if (match && (u32)match->data == EDMA_BINDING_TPCC)
>> + if (match &&
>> + (enum edma_binding_type)match->data == EDMA_BINDING_TPCC)
>> legacy_mode = false;
>>
>> info = edma_setup_info_from_dt(dev, legacy_mode);
>> --
>> 2.10.0
>>
>
> Are you sure this works on all architectures? IIRC the size of an enum
> is implementation defined, so this could still fail sometimes.
True, some arch have HW type for enum or something similar.
>
> I tend to use 'uintptr_t' for the cast instead.
What about keeping the defines and:
diff --git a/drivers/dma/edma.c b/drivers/dma/edma.c
index 3e9606b08340..493fdf30e8b8 100644
--- a/drivers/dma/edma.c
+++ b/drivers/dma/edma.c
@@ -263,14 +263,19 @@ static const struct edmacc_param dummy_paramset = {
#define EDMA_BINDING_LEGACY 0
#define EDMA_BINDING_TPCC 1
+static const u32 edma_binding_type[] = {
+ [EDMA_BINDING_LEGACY] = EDMA_BINDING_LEGACY,
+ [EDMA_BINDING_TPCC] = EDMA_BINDING_TPCC,
+};
+
static const struct of_device_id edma_of_ids[] = {
{
.compatible = "ti,edma3",
- .data = (void *)EDMA_BINDING_LEGACY,
+ .data = (void *)&edma_binding_type[EDMA_BINDING_LEGACY],
},
{
.compatible = "ti,edma3-tpcc",
- .data = (void *)EDMA_BINDING_TPCC,
+ .data = (void *)&edma_binding_type[EDMA_BINDING_TPCC],
},
{}
};
@@ -2183,7 +2188,7 @@ static int edma_probe(struct platform_device *pdev)
const struct of_device_id *match;
match = of_match_node(edma_of_ids, node);
- if (match && (u32)match->data == EDMA_BINDING_TPCC)
+ if (match && (*(u32*)match->data) == EDMA_BINDING_TPCC)
legacy_mode = false;
info = edma_setup_info_from_dt(dev, legacy_mode);
same for the ti-dma-crossbar.
--
P?ter
^ permalink raw reply related
* [PATCH] ARM: dts: imx6: Add support for Toradex Colibri iMX6 module
From: Sanchayan Maity @ 2016-09-21 11:24 UTC (permalink / raw)
To: linux-arm-kernel
Add support for Toradex Colibri iMX6 module.
Signed-off-by: Sanchayan Maity <maitysanchayan@gmail.com>
---
arch/arm/boot/dts/Makefile | 1 +
arch/arm/boot/dts/imx6dl-colibri-eval-v3.dts | 253 ++++++++
arch/arm/boot/dts/imx6qdl-colibri.dtsi | 890 +++++++++++++++++++++++++++
3 files changed, 1144 insertions(+)
create mode 100644 arch/arm/boot/dts/imx6dl-colibri-eval-v3.dts
create mode 100644 arch/arm/boot/dts/imx6qdl-colibri.dtsi
diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index f79cac2..44ff380 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -323,6 +323,7 @@ dtb-$(CONFIG_SOC_IMX6Q) += \
imx6dl-aristainetos_7.dtb \
imx6dl-aristainetos2_4.dtb \
imx6dl-aristainetos2_7.dtb \
+ imx6dl-colibri-eval-v3.dtb \
imx6dl-cubox-i.dtb \
imx6dl-dfi-fs700-m60.dtb \
imx6dl-gw51xx.dtb \
diff --git a/arch/arm/boot/dts/imx6dl-colibri-eval-v3.dts b/arch/arm/boot/dts/imx6dl-colibri-eval-v3.dts
new file mode 100644
index 0000000..e0c2172
--- /dev/null
+++ b/arch/arm/boot/dts/imx6dl-colibri-eval-v3.dts
@@ -0,0 +1,253 @@
+/*
+ * Copyright 2014-2016 Toradex AG
+ * Copyright 2012 Freescale Semiconductor, Inc.
+ * Copyright 2011 Linaro Ltd.
+ *
+ * This file is dual-licensed: you can use it either under the terms
+ * of the GPL or the X11 license, at your option. Note that this dual
+ * licensing only applies to this file, and not this project as a
+ * whole.
+ *
+ * a) This file is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License
+ * version 2 as published by the Free Software Foundation.
+ *
+ * This file is distributed in the hope that it will be useful
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * Or, alternatively
+ *
+ * b) Permission is hereby granted, free of charge, to any person
+ * obtaining a copy of this software and associated documentation
+ * files (the "Software"), to deal in the Software without
+ * restriction, including without limitation the rights to use
+ * copy, modify, merge, publish, distribute, sublicense, and/or
+ * sell copies of the Software, and to permit persons to whom the
+ * Software is furnished to do so, subject to the following
+ * conditions:
+ *
+ * The above copyright notice and this permission notice shall be
+ * included in all copies or substantial portions of the Software.
+ *
+ * THE SOFTWARE IS PROVIDED , WITHOUT WARRANTY OF ANY KIND
+ * EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES
+ * OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
+ * NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT
+ * HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY
+ * WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
+ * OTHER DEALINGS IN THE SOFTWARE.
+ */
+
+/dts-v1/;
+
+#include <dt-bindings/input/input.h>
+#include <dt-bindings/interrupt-controller/irq.h>
+#include "imx6dl.dtsi"
+#include "imx6qdl-colibri.dtsi"
+
+/ {
+ model = "Toradex Colibri iMX6DL/S on Colibri Evaluation Board V3";
+ compatible = "toradex,colibri_imx6dl-eval-v3", "toradex,colibri_imx6dl",
+ "fsl,imx6dl";
+
+ aliases {
+ i2c0 = &i2c2;
+ i2c1 = &i2c3;
+ };
+
+ aliases {
+ rtc0 = &rtc_i2c;
+ rtc1 = &snvs_rtc;
+ };
+
+ clocks {
+ /* Fixed crystal dedicated to mcp251x */
+ clk16m: clk at 1 {
+ compatible = "fixed-clock";
+ reg = <1>;
+ #clock-cells = <0>;
+ clock-frequency = <16000000>;
+ clock-output-names = "clk16m";
+ };
+ };
+
+ gpio-keys {
+ compatible = "gpio-keys";
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_gpio_keys>;
+
+ wakeup {
+ label = "Wake-Up";
+ gpios = <&gpio2 22 GPIO_ACTIVE_HIGH>; /* SODIMM 45 */
+ linux,code = <KEY_WAKEUP>;
+ debounce-interval = <10>;
+ wakeup-source;
+ };
+ };
+
+ lcd_display: display at di0 {
+ compatible = "fsl,imx-parallel-display";
+ #address-cells = <1>;
+ #size-cells = <0>;
+ interface-pix-fmt = "bgr666";
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_ipu1_lcdif>;
+ status = "okay";
+
+ port at 0 {
+ reg = <0>;
+
+ lcd_display_in: endpoint {
+ remote-endpoint = <&ipu1_di0_disp0>;
+ };
+ };
+
+ port at 1 {
+ reg = <1>;
+
+ lcd_display_out: endpoint {
+ remote-endpoint = <&lcd_panel_in>;
+ };
+ };
+ };
+
+ panel: panel {
+ /*
+ * edt,et057090dhu: EDT 5.7" LCD TFT
+ * edt,et070080dh6: EDT 7.0" LCD TFT
+ */
+ compatible = "edt,et057090dhu";
+ backlight = <&backlight>;
+
+ port {
+ lcd_panel_in: endpoint {
+ remote-endpoint = <&lcd_display_out>;
+ };
+ };
+ };
+};
+
+&backlight {
+ brightness-levels = <0 127 191 223 239 247 251 255>;
+ default-brightness-level = <1>;
+ status = "okay";
+};
+
+/* Colibri SSP */
+&ecspi4 {
+ status = "okay";
+
+ mcp251x0: mcp251x at 1 {
+ compatible = "microchip,mcp2515";
+ reg = <0>;
+ clocks = <&clk16m>;
+ interrupt-parent = <&gpio3>;
+ interrupts = <27 0x2>;
+ spi-max-frequency = <10000000>;
+ status = "okay";
+ };
+};
+
+&hdmi {
+ status = "okay";
+};
+
+/*
+ * Colibri I2C: I2C3_SDA/SCL on SODIMM 194/196 (e.g. RTC on carrier board)
+ */
+&i2c3 {
+ status = "okay";
+
+ /* M41T0M6 real time clock on carrier board */
+ rtc_i2c: rtc at 68 {
+ compatible = "st,m41t00";
+ reg = <0x68>;
+ };
+};
+
+&ipu1_di0_disp0 {
+ remote-endpoint = <&lcd_display_in>;
+};
+
+&pwm1 {
+ status = "okay";
+};
+
+&pwm2 {
+ status = "okay";
+};
+
+&pwm3 {
+ status = "okay";
+};
+
+&pwm4 {
+ status = "okay";
+};
+
+®_usb_host_vbus {
+ status = "okay";
+};
+
+&uart1 {
+ status = "okay";
+};
+
+&uart2 {
+ status = "okay";
+};
+
+&uart3 {
+ status = "okay";
+};
+
+&usbh1 {
+ vbus-supply = <®_usb_host_vbus>;
+ status = "okay";
+};
+
+&usbotg {
+ status = "okay";
+};
+
+/* Colibri MMC */
+&usdhc1 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_mmc_cd>;
+ cd-gpios = <&gpio2 5 GPIO_ACTIVE_LOW>; /* MMCD */
+ status = "okay";
+};
+
+&weim {
+ status = "okay";
+
+ /* weim memory map: 32MB on CS0, 32MB on CS1, 32MB on CS2 */
+ ranges = <0 0 0x08000000 0x02000000
+ 1 0 0x0a000000 0x02000000
+ 2 0 0x0c000000 0x02000000>;
+
+ /* SRAM on Colibri nEXT_CS0 */
+ sram at 0,0 {
+ compatible = "cypress,cy7c1019dv33-10zsxi, mtd-ram";
+ reg = <0 0 0x00010000>;
+ #address-cells = <1>;
+ #size-cells = <1>;
+ bank-width = <2>;
+ fsl,weim-cs-timing = <0x00010081 0x00000000 0x04000000
+ 0x00000000 0x04000040 0x00000000>;
+ };
+
+ /* SRAM on Colibri nEXT_CS1 */
+ sram at 1,0 {
+ compatible = "cypress,cy7c1019dv33-10zsxi, mtd-ram";
+ reg = <1 0 0x00010000>;
+ #address-cells = <1>;
+ #size-cells = <1>;
+ bank-width = <2>;
+ fsl,weim-cs-timing = <0x00010081 0x00000000 0x04000000
+ 0x00000000 0x04000040 0x00000000>;
+ };
+};
diff --git a/arch/arm/boot/dts/imx6qdl-colibri.dtsi b/arch/arm/boot/dts/imx6qdl-colibri.dtsi
new file mode 100644
index 0000000..e6faa65
--- /dev/null
+++ b/arch/arm/boot/dts/imx6qdl-colibri.dtsi
@@ -0,0 +1,890 @@
+/*
+ * Copyright 2014-2016 Toradex AG
+ * Copyright 2012 Freescale Semiconductor, Inc.
+ * Copyright 2011 Linaro Ltd.
+ *
+ * This file is dual-licensed: you can use it either under the terms
+ * of the GPL or the X11 license, at your option. Note that this dual
+ * licensing only applies to this file, and not this project as a
+ * whole.
+ *
+ * a) This file is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License
+ * version 2 as published by the Free Software Foundation.
+ *
+ * This file is distributed in the hope that it will be useful
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * Or, alternatively
+ *
+ * b) Permission is hereby granted, free of charge, to any person
+ * obtaining a copy of this software and associated documentation
+ * files (the "Software"), to deal in the Software without
+ * restriction, including without limitation the rights to use
+ * copy, modify, merge, publish, distribute, sublicense, and/or
+ * sell copies of the Software, and to permit persons to whom the
+ * Software is furnished to do so, subject to the following
+ * conditions:
+ *
+ * The above copyright notice and this permission notice shall be
+ * included in all copies or substantial portions of the Software.
+ *
+ * THE SOFTWARE IS PROVIDED , WITHOUT WARRANTY OF ANY KIND
+ * EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES
+ * OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
+ * NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT
+ * HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY
+ * WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
+ * OTHER DEALINGS IN THE SOFTWARE.
+ */
+
+#include <dt-bindings/gpio/gpio.h>
+
+/ {
+ model = "Toradex Colibri iMX6DL/S Module";
+ compatible = "toradex,colibri_imx6dl", "fsl,imx6dl";
+
+ backlight: backlight {
+ compatible = "pwm-backlight";
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_gpio_bl_on>;
+ pwms = <&pwm3 0 5000000>;
+ enable-gpios = <&gpio3 26 GPIO_ACTIVE_HIGH>; /* Colibri BL_ON */
+ status = "disabled";
+ };
+
+ reg_1p8v: regulator-1p8v {
+ compatible = "regulator-fixed";
+ regulator-name = "1P8V";
+ regulator-min-microvolt = <1800000>;
+ regulator-max-microvolt = <1800000>;
+ regulator-always-on;
+ };
+
+ reg_2p5v: regulator-2p5v {
+ compatible = "regulator-fixed";
+ regulator-name = "2P5V";
+ regulator-min-microvolt = <2500000>;
+ regulator-max-microvolt = <2500000>;
+ regulator-always-on;
+ };
+
+ reg_3p3v: regulator-3p3v {
+ compatible = "regulator-fixed";
+ regulator-name = "3P3V";
+ regulator-min-microvolt = <3300000>;
+ regulator-max-microvolt = <3300000>;
+ regulator-always-on;
+ };
+
+ reg_usb_host_vbus: regulator-usb-host-vbus {
+ compatible = "regulator-fixed";
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_regulator_usbh_pwr>;
+ regulator-name = "usb_host_vbus";
+ regulator-min-microvolt = <5000000>;
+ regulator-max-microvolt = <5000000>;
+ gpio = <&gpio3 31 GPIO_ACTIVE_HIGH>; /* USBH_PEN */
+ status = "disabled";
+ };
+
+ sound {
+ compatible = "fsl,imx-audio-sgtl5000";
+ model = "imx6dl-colibri-sgtl5000";
+ ssi-controller = <&ssi1>;
+ audio-codec = <&codec>;
+ audio-routing =
+ "Headphone Jack", "HP_OUT",
+ "LINE_IN", "Line In Jack",
+ "MIC_IN", "Mic Jack",
+ "Mic Jack", "Mic Bias";
+ mux-int-port = <1>;
+ mux-ext-port = <5>;
+ };
+
+ /* Optional S/PDIF in on SODIMM 88 and out on SODIMM 90, 137 or 168 */
+ sound_spdif: sound-spdif {
+ compatible = "fsl,imx-audio-spdif";
+ model = "imx-spdif";
+ spdif-controller = <&spdif>;
+ spdif-in;
+ spdif-out;
+ status = "disabled";
+ };
+};
+
+&audmux {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_audmux &pinctrl_mic_gnd>;
+ status = "okay";
+};
+
+/* Optional on SODIMM 55/63 */
+&can1 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_flexcan1>;
+ status = "disabled";
+};
+
+/* Optional on SODIMM 178/188 */
+&can2 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_flexcan2>;
+ status = "disabled";
+};
+
+/* Colibri SSP */
+&ecspi4 {
+ fsl,spi-num-chipselects = <1>;
+ cs-gpios = <&gpio5 2 GPIO_ACTIVE_HIGH>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_ecspi4>;
+ status = "disabled";
+};
+
+&fec {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_enet>;
+ phy-mode = "rmii";
+ status = "okay";
+};
+
+&hdmi {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_hdmi_ddc>;
+ status = "disabled";
+};
+
+/*
+ * PWR_I2C: power I2C to audio codec, PMIC, temperature sensor and
+ * touch screen controller
+ */
+&i2c2 {
+ clock-frequency = <100000>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_i2c2>;
+ status = "okay";
+
+ pmic: pfuze100 at 08 {
+ compatible = "fsl,pfuze100";
+ reg = <0x08>;
+
+ regulators {
+ sw1a_reg: sw1ab {
+ regulator-min-microvolt = <300000>;
+ regulator-max-microvolt = <1875000>;
+ regulator-boot-on;
+ regulator-always-on;
+ regulator-ramp-delay = <6250>;
+ };
+
+ sw1c_reg: sw1c {
+ regulator-min-microvolt = <300000>;
+ regulator-max-microvolt = <1875000>;
+ regulator-boot-on;
+ regulator-always-on;
+ regulator-ramp-delay = <6250>;
+ };
+
+ sw3a_reg: sw3a {
+ regulator-min-microvolt = <400000>;
+ regulator-max-microvolt = <1975000>;
+ regulator-boot-on;
+ regulator-always-on;
+ };
+
+ swbst_reg: swbst {
+ regulator-min-microvolt = <5000000>;
+ regulator-max-microvolt = <5150000>;
+ regulator-boot-on;
+ regulator-always-on;
+ };
+
+ snvs_reg: vsnvs {
+ regulator-min-microvolt = <1000000>;
+ regulator-max-microvolt = <3000000>;
+ regulator-boot-on;
+ regulator-always-on;
+ };
+
+ vref_reg: vrefddr {
+ regulator-boot-on;
+ regulator-always-on;
+ };
+
+ /* vgen1: unused */
+
+ vgen2_reg: vgen2 {
+ regulator-min-microvolt = <800000>;
+ regulator-max-microvolt = <1550000>;
+ regulator-boot-on;
+ regulator-always-on;
+ };
+
+ /* vgen3: unused */
+
+ vgen4_reg: vgen4 {
+ regulator-min-microvolt = <1800000>;
+ regulator-max-microvolt = <3300000>;
+ regulator-boot-on;
+ regulator-always-on;
+ };
+
+ vgen5_reg: vgen5 {
+ regulator-min-microvolt = <1800000>;
+ regulator-max-microvolt = <3300000>;
+ regulator-boot-on;
+ regulator-always-on;
+ };
+
+ vgen6_reg: vgen6 {
+ regulator-min-microvolt = <1800000>;
+ regulator-max-microvolt = <3300000>;
+ regulator-boot-on;
+ regulator-always-on;
+ };
+ };
+ };
+
+ codec: sgtl5000 at 0a {
+ compatible = "fsl,sgtl5000";
+ reg = <0x0a>;
+ clocks = <&clks IMX6QDL_CLK_CKO>;
+ VDDA-supply = <®_2p5v>;
+ VDDIO-supply = <®_3p3v>;
+ };
+
+ /* STMPE811 touch screen controller */
+ stmpe811 at 41 {
+ compatible = "st,stmpe811";
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_touch_int>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <0x41>;
+ interrupts = <20 IRQ_TYPE_LEVEL_LOW>;
+ interrupt-parent = <&gpio6>;
+ interrupt-controller;
+ id = <0>;
+ blocks = <0x5>;
+ irq-trigger = <0x1>;
+
+ stmpe_touchscreen {
+ compatible = "st,stmpe-ts";
+ reg = <0>;
+ /* 3.25 MHz ADC clock speed */
+ st,adc-freq = <1>;
+ /* 8 sample average control */
+ st,ave-ctrl = <3>;
+ /* 7 length fractional part in z */
+ st,fraction-z = <7>;
+ /*
+ * 50 mA typical 80 mA max touchscreen drivers
+ * current limit value
+ */
+ st,i-drive = <1>;
+ /* 12-bit ADC */
+ st,mod-12b = <1>;
+ /* internal ADC reference */
+ st,ref-sel = <0>;
+ /* ADC converstion time: 80 clocks */
+ st,sample-time = <4>;
+ /* 1 ms panel driver settling time */
+ st,settling = <3>;
+ /* 5 ms touch detect interrupt delay */
+ st,touch-det-delay = <5>;
+ };
+ };
+};
+
+/*
+ * I2C3_SDA/SCL on SODIMM 194/196 (e.g. RTC on carrier board)
+ */
+&i2c3 {
+ clock-frequency = <100000>;
+ pinctrl-names = "default", "recovery";
+ pinctrl-0 = <&pinctrl_i2c3>;
+ pinctrl-1 = <&pinctrl_i2c3_recovery>;
+ scl-gpios = <&gpio1 3 GPIO_ACTIVE_HIGH>;
+ sda-gpios = <&gpio1 6 GPIO_ACTIVE_HIGH>;
+ status = "disabled";
+};
+
+/* Colibri PWM<B> */
+&pwm1 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_pwm1>;
+ status = "disabled";
+};
+
+/* Colibri PWM<D> */
+&pwm2 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_pwm2>;
+ status = "disabled";
+};
+
+/* Colibri PWM<A> */
+&pwm3 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_pwm3>;
+ status = "disabled";
+};
+
+/* Colibri PWM<C> */
+&pwm4 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_pwm4>;
+ status = "disabled";
+};
+
+/* Optional S/PDIF out on SODIMM 137 */
+&spdif {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_spdif>;
+ status = "disabled";
+};
+
+&ssi1 {
+ status = "okay";
+};
+
+/* Colibri UART_A */
+&uart1 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_uart1_dte &pinctrl_uart1_ctrl>;
+ fsl,dte-mode;
+ uart-has-rtscts;
+ status = "disabled";
+};
+
+/* Colibri UART_B */
+&uart2 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_uart2_dte>;
+ fsl,dte-mode;
+ uart-has-rtscts;
+ status = "disabled";
+};
+
+/* Colibri UART_C */
+&uart3 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_uart3_dte>;
+ fsl,dte-mode;
+ status = "disabled";
+};
+
+&usbotg {
+ pinctrl-names = "default";
+ disable-over-current;
+ dr_mode = "peripheral";
+ status = "disabled";
+};
+
+/* Colibri MMC */
+&usdhc1 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_usdhc1>;
+ vqmmc-supply = <®_3p3v>;
+ bus-width = <4>;
+ voltage-ranges = <3300 3300>;
+ status = "disabled";
+};
+
+/* eMMC */
+&usdhc3 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_usdhc3>;
+ vqmmc-supply = <®_3p3v>;
+ bus-width = <8>;
+ voltage-ranges = <3300 3300>;
+ non-removable;
+ status = "okay";
+};
+
+&weim {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_weim_sram &pinctrl_weim_cs0
+ &pinctrl_weim_cs1 &pinctrl_weim_cs2
+ &pinctrl_weim_rdnwr &pinctrl_weim_npwe>;
+ #address-cells = <2>;
+ #size-cells = <1>;
+ status = "disabled";
+};
+
+&iomuxc {
+ pinctrl_audmux: audmuxgrp {
+ fsl,pins = <
+ MX6QDL_PAD_KEY_COL0__AUD5_TXC 0x130b0
+ MX6QDL_PAD_KEY_ROW0__AUD5_TXD 0x130b0
+ MX6QDL_PAD_KEY_COL1__AUD5_TXFS 0x130b0
+ MX6QDL_PAD_KEY_ROW1__AUD5_RXD 0x130b0
+ /* SGTL5000 sys_mclk */
+ MX6QDL_PAD_GPIO_0__CCM_CLKO1 0x000b0
+ >;
+ };
+
+ pinctrl_cam_mclk: cammclkgrp {
+ fsl,pins = <
+ /* Parallel Camera CAM sys_mclk */
+ MX6QDL_PAD_NANDF_CS2__CCM_CLKO2 0x00b0
+ >;
+ };
+
+ pinctrl_ecspi4: ecspi4grp {
+ fsl,pins = <
+ MX6QDL_PAD_EIM_D22__ECSPI4_MISO 0x100b1
+ MX6QDL_PAD_EIM_D28__ECSPI4_MOSI 0x100b1
+ MX6QDL_PAD_EIM_D21__ECSPI4_SCLK 0x100b1
+ /* SPI CS */
+ MX6QDL_PAD_EIM_A25__GPIO5_IO02 0x000b1
+ >;
+ };
+
+ pinctrl_enet: enetgrp {
+ fsl,pins = <
+ MX6QDL_PAD_ENET_MDC__ENET_MDC 0x1b0b0
+ MX6QDL_PAD_ENET_MDIO__ENET_MDIO 0x1b0b0
+ MX6QDL_PAD_ENET_RXD0__ENET_RX_DATA0 0x1b0b0
+ MX6QDL_PAD_ENET_RXD1__ENET_RX_DATA1 0x1b0b0
+ MX6QDL_PAD_ENET_RX_ER__ENET_RX_ER 0x1b0b0
+ MX6QDL_PAD_ENET_TX_EN__ENET_TX_EN 0x1b0b0
+ MX6QDL_PAD_ENET_TXD0__ENET_TX_DATA0 0x1b0b0
+ MX6QDL_PAD_ENET_TXD1__ENET_TX_DATA1 0x1b0b0
+ MX6QDL_PAD_ENET_CRS_DV__ENET_RX_EN 0x1b0b0
+ MX6QDL_PAD_GPIO_16__ENET_REF_CLK ((1<<30) | 0x1b0b0)
+ >;
+ };
+
+ pinctrl_flexcan1: flexcan1grp {
+ fsl,pins = <
+ MX6QDL_PAD_GPIO_7__FLEXCAN1_TX 0x1b0b0
+ MX6QDL_PAD_GPIO_8__FLEXCAN1_RX 0x1b0b0
+ >;
+ };
+
+ pinctrl_flexcan2: flexcan2grp {
+ fsl,pins = <
+ MX6QDL_PAD_KEY_COL4__FLEXCAN2_TX 0x1b0b0
+ MX6QDL_PAD_KEY_ROW4__FLEXCAN2_RX 0x1b0b0
+ >;
+ };
+
+ pinctrl_gpio_bl_on: gpioblon {
+ fsl,pins = <
+ MX6QDL_PAD_EIM_D26__GPIO3_IO26 0x1b0b0
+ >;
+ };
+
+ pinctrl_gpio_keys: gpiokeys {
+ fsl,pins = <
+ /* Power button */
+ MX6QDL_PAD_EIM_A16__GPIO2_IO22 0x1b0b0
+ >;
+ };
+
+ pinctrl_hdmi_ddc: hdmiddcgrp {
+ fsl,pins = <
+ MX6QDL_PAD_KEY_COL3__HDMI_TX_DDC_SCL 0x4001b8b1
+ MX6QDL_PAD_KEY_ROW3__HDMI_TX_DDC_SDA 0x4001b8b1
+ >;
+ };
+
+ pinctrl_i2c2: i2c2grp {
+ fsl,pins = <
+ MX6QDL_PAD_EIM_EB2__I2C2_SCL 0x4001b8b1
+ MX6QDL_PAD_EIM_D16__I2C2_SDA 0x4001b8b1
+ >;
+ };
+
+ pinctrl_i2c3: i2c3grp {
+ fsl,pins = <
+ MX6QDL_PAD_GPIO_3__I2C3_SCL 0x4001b8b1
+ MX6QDL_PAD_GPIO_6__I2C3_SDA 0x4001b8b1
+ >;
+ };
+
+ pinctrl_i2c3_recovery: i2c3recoverygrp {
+ fsl,pins = <
+ MX6QDL_PAD_GPIO_3__GPIO1_IO03 0x4001b8b1
+ MX6QDL_PAD_GPIO_6__GPIO1_IO06 0x4001b8b1
+ >;
+ };
+
+ pinctrl_ipu1_csi0: ipu1csi0grp { /* Parallel Camera */
+ fsl,pins = <
+ MX6QDL_PAD_EIM_A17__IPU1_CSI1_DATA12 0xb0b1
+ MX6QDL_PAD_EIM_A18__IPU1_CSI1_DATA13 0xb0b1
+ MX6QDL_PAD_EIM_A19__IPU1_CSI1_DATA14 0xb0b1
+ MX6QDL_PAD_EIM_A20__IPU1_CSI1_DATA15 0xb0b1
+ MX6QDL_PAD_EIM_A21__IPU1_CSI1_DATA16 0xb0b1
+ MX6QDL_PAD_EIM_A22__IPU1_CSI1_DATA17 0xb0b1
+ MX6QDL_PAD_EIM_A23__IPU1_CSI1_DATA18 0xb0b1
+ MX6QDL_PAD_EIM_A24__IPU1_CSI1_DATA19 0xb0b1
+ MX6QDL_PAD_EIM_D17__IPU1_CSI1_PIXCLK 0xb0b1
+ MX6QDL_PAD_EIM_EB3__IPU1_CSI1_HSYNC 0xb0b1
+ MX6QDL_PAD_EIM_D29__IPU1_CSI1_VSYNC 0xb0b1
+ /* Disable PWM pins on camera interface */
+ MX6QDL_PAD_SD4_DAT1__GPIO2_IO09 0x40
+ MX6QDL_PAD_GPIO_1__GPIO1_IO01 0x40
+ >;
+ };
+
+ pinctrl_ipu1_lcdif: ipu1lcdifgrp {
+ fsl,pins = <
+ MX6QDL_PAD_DI0_DISP_CLK__IPU1_DI0_DISP_CLK 0xa1
+ MX6QDL_PAD_DI0_PIN15__IPU1_DI0_PIN15 0xa1
+ MX6QDL_PAD_DI0_PIN2__IPU1_DI0_PIN02 0xa1
+ MX6QDL_PAD_DI0_PIN3__IPU1_DI0_PIN03 0xa1
+ MX6QDL_PAD_DISP0_DAT0__IPU1_DISP0_DATA00 0xa1
+ MX6QDL_PAD_DISP0_DAT1__IPU1_DISP0_DATA01 0xa1
+ MX6QDL_PAD_DISP0_DAT2__IPU1_DISP0_DATA02 0xa1
+ MX6QDL_PAD_DISP0_DAT3__IPU1_DISP0_DATA03 0xa1
+ MX6QDL_PAD_DISP0_DAT4__IPU1_DISP0_DATA04 0xa1
+ MX6QDL_PAD_DISP0_DAT5__IPU1_DISP0_DATA05 0xa1
+ MX6QDL_PAD_DISP0_DAT6__IPU1_DISP0_DATA06 0xa1
+ MX6QDL_PAD_DISP0_DAT7__IPU1_DISP0_DATA07 0xa1
+ MX6QDL_PAD_DISP0_DAT8__IPU1_DISP0_DATA08 0xa1
+ MX6QDL_PAD_DISP0_DAT9__IPU1_DISP0_DATA09 0xa1
+ MX6QDL_PAD_DISP0_DAT10__IPU1_DISP0_DATA10 0xa1
+ MX6QDL_PAD_DISP0_DAT11__IPU1_DISP0_DATA11 0xa1
+ MX6QDL_PAD_DISP0_DAT12__IPU1_DISP0_DATA12 0xa1
+ MX6QDL_PAD_DISP0_DAT13__IPU1_DISP0_DATA13 0xa1
+ MX6QDL_PAD_DISP0_DAT14__IPU1_DISP0_DATA14 0xa1
+ MX6QDL_PAD_DISP0_DAT15__IPU1_DISP0_DATA15 0xa1
+ MX6QDL_PAD_DISP0_DAT16__IPU1_DISP0_DATA16 0xa1
+ MX6QDL_PAD_DISP0_DAT17__IPU1_DISP0_DATA17 0xa1
+ >;
+ };
+
+ pinctrl_mic_gnd: gpiomicgnd {
+ fsl,pins = <
+ /* Controls Mic GND, PU or '1' pull Mic GND to GND */
+ MX6QDL_PAD_RGMII_TD1__GPIO6_IO21 0x1b0b0
+ >;
+ };
+
+ pinctrl_mmc_cd: gpiommccd {
+ fsl,pins = <
+ MX6QDL_PAD_NANDF_D5__GPIO2_IO05 0x80000000
+ >;
+ };
+
+ pinctrl_pwm1: pwm1grp {
+ fsl,pins = <
+ MX6QDL_PAD_GPIO_9__PWM1_OUT 0x1b0b1
+ >;
+ };
+
+ pinctrl_pwm2: pwm2grp {
+ fsl,pins = <
+ MX6QDL_PAD_GPIO_1__PWM2_OUT 0x1b0b1
+ MX6QDL_PAD_EIM_A21__GPIO2_IO17 0x00040
+ >;
+ };
+
+ pinctrl_pwm3: pwm3grp {
+ fsl,pins = <
+ MX6QDL_PAD_SD4_DAT1__PWM3_OUT 0x1b0b1
+ MX6QDL_PAD_EIM_A22__GPIO2_IO16 0x00040
+ >;
+ };
+
+ pinctrl_pwm4: pwm4grp {
+ fsl,pins = <
+ MX6QDL_PAD_SD4_DAT2__PWM4_OUT 0x1b0b1
+ >;
+ };
+
+ pinctrl_regulator_usbh_pwr: gpioregusbhpwrgrp {
+ fsl,pins = <
+ /* USBH_EN */
+ MX6QDL_PAD_EIM_D31__GPIO3_IO31 0x0f058
+ >;
+ };
+
+ pinctrl_spdif: spdifgrp {
+ fsl,pins = <
+ MX6QDL_PAD_GPIO_17__SPDIF_OUT 0x1b0b0
+ >;
+ };
+
+ pinctrl_touch_int: gpiotouchintgrp {
+ fsl,pins = <
+ /* STMPE811 interrupt */
+ MX6QDL_PAD_RGMII_TD0__GPIO6_IO20 0x1b0b0
+ >;
+ };
+
+ pinctrl_uart1_dce: uart1dcegrp {
+ fsl,pins = <
+ MX6QDL_PAD_CSI0_DAT10__UART1_TX_DATA 0x1b0b1
+ MX6QDL_PAD_CSI0_DAT11__UART1_RX_DATA 0x1b0b1
+ >;
+ };
+
+ /* DTE mode */
+ pinctrl_uart1_dte: uart1dtegrp {
+ fsl,pins = <
+ MX6QDL_PAD_CSI0_DAT10__UART1_RX_DATA 0x1b0b1
+ MX6QDL_PAD_CSI0_DAT11__UART1_TX_DATA 0x1b0b1
+ MX6QDL_PAD_EIM_D19__UART1_RTS_B 0x1b0b1
+ MX6QDL_PAD_EIM_D20__UART1_CTS_B 0x1b0b1
+ >;
+ };
+
+ /* Additional DTR, DSR, DCD */
+ pinctrl_uart1_ctrl: uart1ctrlgrp {
+ fsl,pins = <
+ MX6QDL_PAD_EIM_D23__UART1_DCD_B 0x1b0b0
+ MX6QDL_PAD_EIM_D24__UART1_DTR_B 0x1b0b0
+ MX6QDL_PAD_EIM_D25__UART1_DSR_B 0x1b0b0
+ >;
+ };
+
+ pinctrl_uart2_dte: uart2dtegrp {
+ fsl,pins = <
+ MX6QDL_PAD_SD4_DAT4__UART2_TX_DATA 0x1b0b1
+ MX6QDL_PAD_SD4_DAT7__UART2_RX_DATA 0x1b0b1
+ MX6QDL_PAD_SD4_DAT6__UART2_RTS_B 0x1b0b1
+ MX6QDL_PAD_SD4_DAT5__UART2_CTS_B 0x1b0b1
+ >;
+ };
+
+ pinctrl_uart3_dte: uart3dtegrp {
+ fsl,pins = <
+ MX6QDL_PAD_SD4_CLK__UART3_TX_DATA 0x1b0b1
+ MX6QDL_PAD_SD4_CMD__UART3_RX_DATA 0x1b0b1
+ >;
+ };
+
+ pinctrl_usbc_det: usbcdetgrp {
+ fsl,pins = <
+ /* USBC_DET */
+ MX6QDL_PAD_GPIO_17__GPIO7_IO12 0x1b0b0
+ /* USBC_DET_EN */
+ MX6QDL_PAD_RGMII_TX_CTL__GPIO6_IO26 0x0f058
+ /* USBC_DET_OVERWRITE */
+ MX6QDL_PAD_RGMII_RXC__GPIO6_IO30 0x0f058
+ >;
+ };
+
+ pinctrl_usdhc1: usdhc1grp {
+ fsl,pins = <
+ MX6QDL_PAD_SD1_CMD__SD1_CMD 0x17071
+ MX6QDL_PAD_SD1_CLK__SD1_CLK 0x10071
+ MX6QDL_PAD_SD1_DAT0__SD1_DATA0 0x17071
+ MX6QDL_PAD_SD1_DAT1__SD1_DATA1 0x17071
+ MX6QDL_PAD_SD1_DAT2__SD1_DATA2 0x17071
+ MX6QDL_PAD_SD1_DAT3__SD1_DATA3 0x17071
+ >;
+ };
+
+ pinctrl_usdhc3: usdhc3grp {
+ fsl,pins = <
+ MX6QDL_PAD_SD3_CMD__SD3_CMD 0x17059
+ MX6QDL_PAD_SD3_CLK__SD3_CLK 0x10059
+ MX6QDL_PAD_SD3_DAT0__SD3_DATA0 0x17059
+ MX6QDL_PAD_SD3_DAT1__SD3_DATA1 0x17059
+ MX6QDL_PAD_SD3_DAT2__SD3_DATA2 0x17059
+ MX6QDL_PAD_SD3_DAT3__SD3_DATA3 0x17059
+ MX6QDL_PAD_SD3_DAT4__SD3_DATA4 0x17059
+ MX6QDL_PAD_SD3_DAT5__SD3_DATA5 0x17059
+ MX6QDL_PAD_SD3_DAT6__SD3_DATA6 0x17059
+ MX6QDL_PAD_SD3_DAT7__SD3_DATA7 0x17059
+ /* eMMC reset */
+ MX6QDL_PAD_SD3_RST__SD3_RESET 0x17059
+ >;
+ };
+
+ pinctrl_usdhc3_100mhz: usdhc3100mhzgrp {
+ fsl,pins = <
+ MX6QDL_PAD_SD3_CMD__SD3_CMD 0x170b9
+ MX6QDL_PAD_SD3_CLK__SD3_CLK 0x100b9
+ MX6QDL_PAD_SD3_DAT0__SD3_DATA0 0x170b9
+ MX6QDL_PAD_SD3_DAT1__SD3_DATA1 0x170b9
+ MX6QDL_PAD_SD3_DAT2__SD3_DATA2 0x170b9
+ MX6QDL_PAD_SD3_DAT3__SD3_DATA3 0x170b9
+ MX6QDL_PAD_SD3_DAT4__SD3_DATA4 0x170b9
+ MX6QDL_PAD_SD3_DAT5__SD3_DATA5 0x170b9
+ MX6QDL_PAD_SD3_DAT6__SD3_DATA6 0x170b9
+ MX6QDL_PAD_SD3_DAT7__SD3_DATA7 0x170b9
+ /* eMMC reset */
+ MX6QDL_PAD_SD3_RST__SD3_RESET 0x170b9
+ >;
+ };
+
+ pinctrl_usdhc3_200mhz: usdhc3200mhzgrp {
+ fsl,pins = <
+ MX6QDL_PAD_SD3_CMD__SD3_CMD 0x170f9
+ MX6QDL_PAD_SD3_CLK__SD3_CLK 0x100f9
+ MX6QDL_PAD_SD3_DAT0__SD3_DATA0 0x170f9
+ MX6QDL_PAD_SD3_DAT1__SD3_DATA1 0x170f9
+ MX6QDL_PAD_SD3_DAT2__SD3_DATA2 0x170f9
+ MX6QDL_PAD_SD3_DAT3__SD3_DATA3 0x170f9
+ MX6QDL_PAD_SD3_DAT4__SD3_DATA4 0x170f9
+ MX6QDL_PAD_SD3_DAT5__SD3_DATA5 0x170f9
+ MX6QDL_PAD_SD3_DAT6__SD3_DATA6 0x170f9
+ MX6QDL_PAD_SD3_DAT7__SD3_DATA7 0x170f9
+ /* eMMC reset */
+ MX6QDL_PAD_SD3_RST__SD3_RESET 0x170f9
+ >;
+ };
+
+ pinctrl_weim_cs0: weimcs0grp {
+ fsl,pins = <
+ /* nEXT_CS0 */
+ MX6QDL_PAD_EIM_CS0__EIM_CS0_B 0xb0b1
+ >;
+ };
+
+ pinctrl_weim_cs1: weimcs1grp {
+ fsl,pins = <
+ /* nEXT_CS1 */
+ MX6QDL_PAD_EIM_CS1__EIM_CS1_B 0xb0b1
+ >;
+ };
+
+ pinctrl_weim_cs2: weimcs2grp {
+ fsl,pins = <
+ /* nEXT_CS2 */
+ MX6QDL_PAD_SD2_DAT1__EIM_CS2_B 0xb0b1
+ >;
+ };
+
+ pinctrl_weim_sram: weimsramgrp {
+ fsl,pins = <
+ MX6QDL_PAD_EIM_OE__EIM_OE_B 0xb0b1
+ MX6QDL_PAD_EIM_RW__EIM_RW 0xb0b1
+ /* Data */
+ MX6QDL_PAD_CSI0_DATA_EN__EIM_DATA00 0x1b0b0
+ MX6QDL_PAD_CSI0_VSYNC__EIM_DATA01 0x1b0b0
+ MX6QDL_PAD_CSI0_DAT4__EIM_DATA02 0x1b0b0
+ MX6QDL_PAD_CSI0_DAT5__EIM_DATA03 0x1b0b0
+ MX6QDL_PAD_CSI0_DAT6__EIM_DATA04 0x1b0b0
+ MX6QDL_PAD_CSI0_DAT7__EIM_DATA05 0x1b0b0
+ MX6QDL_PAD_CSI0_DAT8__EIM_DATA06 0x1b0b0
+ MX6QDL_PAD_CSI0_DAT9__EIM_DATA07 0x1b0b0
+ MX6QDL_PAD_CSI0_DAT12__EIM_DATA08 0x1b0b0
+ MX6QDL_PAD_CSI0_DAT13__EIM_DATA09 0x1b0b0
+ MX6QDL_PAD_CSI0_DAT14__EIM_DATA10 0x1b0b0
+ MX6QDL_PAD_CSI0_DAT15__EIM_DATA11 0x1b0b0
+ MX6QDL_PAD_CSI0_DAT16__EIM_DATA12 0x1b0b0
+ MX6QDL_PAD_CSI0_DAT17__EIM_DATA13 0x1b0b0
+ MX6QDL_PAD_CSI0_DAT18__EIM_DATA14 0x1b0b0
+ MX6QDL_PAD_CSI0_DAT19__EIM_DATA15 0x1b0b0
+ /* Address */
+ MX6QDL_PAD_EIM_DA15__EIM_AD15 0xb0b1
+ MX6QDL_PAD_EIM_DA14__EIM_AD14 0xb0b1
+ MX6QDL_PAD_EIM_DA13__EIM_AD13 0xb0b1
+ MX6QDL_PAD_EIM_DA12__EIM_AD12 0xb0b1
+ MX6QDL_PAD_EIM_DA11__EIM_AD11 0xb0b1
+ MX6QDL_PAD_EIM_DA10__EIM_AD10 0xb0b1
+ MX6QDL_PAD_EIM_DA9__EIM_AD09 0xb0b1
+ MX6QDL_PAD_EIM_DA8__EIM_AD08 0xb0b1
+ MX6QDL_PAD_EIM_DA7__EIM_AD07 0xb0b1
+ MX6QDL_PAD_EIM_DA6__EIM_AD06 0xb0b1
+ MX6QDL_PAD_EIM_DA5__EIM_AD05 0xb0b1
+ MX6QDL_PAD_EIM_DA4__EIM_AD04 0xb0b1
+ MX6QDL_PAD_EIM_DA3__EIM_AD03 0xb0b1
+ MX6QDL_PAD_EIM_DA2__EIM_AD02 0xb0b1
+ MX6QDL_PAD_EIM_DA1__EIM_AD01 0xb0b1
+ MX6QDL_PAD_EIM_DA0__EIM_AD00 0xb0b1
+ >;
+ };
+
+ pinctrl_weim_rdnwr: weimrdnwr {
+ fsl,pins = <
+ MX6QDL_PAD_SD2_CLK__GPIO1_IO10 0x0040
+ MX6QDL_PAD_RGMII_TD3__GPIO6_IO23 0x130b0
+ >;
+ };
+
+ pinctrl_weim_npwe: weimnpwe {
+ fsl,pins = <
+ MX6QDL_PAD_SD2_DAT3__GPIO1_IO12 0x0040
+ MX6QDL_PAD_RGMII_TD2__GPIO6_IO22 0x130b0
+ >;
+ };
+
+ /* ADDRESS[16:18] [25] used as GPIO */
+ pinctrl_weim_gpio_1: weimgpio-1 {
+ fsl,pins = <
+ MX6QDL_PAD_KEY_ROW4__GPIO4_IO15 0x1b0b0
+ MX6QDL_PAD_KEY_ROW2__GPIO4_IO11 0x1b0b0
+ MX6QDL_PAD_KEY_COL2__GPIO4_IO10 0x1b0b0
+ MX6QDL_PAD_DISP0_DAT23__GPIO5_IO17 0x1b0b0
+ MX6QDL_PAD_DISP0_DAT22__GPIO5_IO16 0x1b0b0
+ MX6QDL_PAD_DISP0_DAT21__GPIO5_IO15 0x1b0b0
+ MX6QDL_PAD_DISP0_DAT20__GPIO5_IO14 0x1b0b0
+ MX6QDL_PAD_DISP0_DAT19__GPIO5_IO13 0x1b0b0
+ MX6QDL_PAD_DISP0_DAT18__GPIO5_IO12 0x1b0b0
+ MX6QDL_PAD_NANDF_D1__GPIO2_IO01 0x1b0b0
+ >;
+ };
+
+ /* ADDRESS[19:24] used as GPIO */
+ pinctrl_weim_gpio_2: weimgpio-2 {
+ fsl,pins = <
+ MX6QDL_PAD_KEY_ROW2__GPIO4_IO11 0x1b0b0
+ MX6QDL_PAD_KEY_COL2__GPIO4_IO10 0x1b0b0
+ MX6QDL_PAD_DISP0_DAT23__GPIO5_IO17 0x1b0b0
+ MX6QDL_PAD_DISP0_DAT22__GPIO5_IO16 0x1b0b0
+ MX6QDL_PAD_DISP0_DAT21__GPIO5_IO15 0x1b0b0
+ MX6QDL_PAD_DISP0_DAT20__GPIO5_IO14 0x1b0b0
+ MX6QDL_PAD_DISP0_DAT19__GPIO5_IO13 0x1b0b0
+ MX6QDL_PAD_DISP0_DAT18__GPIO5_IO12 0x1b0b0
+ MX6QDL_PAD_NANDF_D1__GPIO2_IO01 0x1b0b0
+ >;
+ };
+
+ /* DATA[16:31] used as GPIO */
+ pinctrl_weim_gpio_3: weimgpio-3 {
+ fsl,pins = <
+ MX6QDL_PAD_EIM_LBA__GPIO2_IO27 0x1b0b0
+ MX6QDL_PAD_EIM_BCLK__GPIO6_IO31 0x1b0b0
+ MX6QDL_PAD_NANDF_CS3__GPIO6_IO16 0x1b0b0
+ MX6QDL_PAD_NANDF_CS1__GPIO6_IO14 0x1b0b0
+ MX6QDL_PAD_NANDF_RB0__GPIO6_IO10 0x1b0b0
+ MX6QDL_PAD_NANDF_ALE__GPIO6_IO08 0x1b0b0
+ MX6QDL_PAD_NANDF_WP_B__GPIO6_IO09 0x1b0b0
+ MX6QDL_PAD_NANDF_CS0__GPIO6_IO11 0x1b0b0
+ MX6QDL_PAD_NANDF_CLE__GPIO6_IO07 0x1b0b0
+ MX6QDL_PAD_GPIO_19__GPIO4_IO05 0x1b0b0
+ MX6QDL_PAD_CSI0_MCLK__GPIO5_IO19 0x1b0b0
+ MX6QDL_PAD_CSI0_PIXCLK__GPIO5_IO18 0x1b0b0
+ MX6QDL_PAD_GPIO_4__GPIO1_IO04 0x1b0b0
+ MX6QDL_PAD_GPIO_5__GPIO1_IO05 0x1b0b0
+ MX6QDL_PAD_GPIO_2__GPIO1_IO02 0x1b0b0
+ >;
+ };
+
+ /* DQM[0:3] used as GPIO */
+ pinctrl_weim_gpio_4: weimgpio-4 {
+ fsl,pins = <
+ MX6QDL_PAD_EIM_EB0__GPIO2_IO28 0x1b0b0
+ MX6QDL_PAD_EIM_EB1__GPIO2_IO29 0x1b0b0
+ MX6QDL_PAD_SD2_DAT2__GPIO1_IO13 0x1b0b0
+ MX6QDL_PAD_NANDF_D0__GPIO2_IO00 0x1b0b0
+ >;
+ };
+
+ /* RDY used as GPIO */
+ pinctrl_weim_gpio_5: weimgpio-5 {
+ fsl,pins = <
+ MX6QDL_PAD_EIM_WAIT__GPIO5_IO00 0x1b0b0
+ >;
+ };
+
+ /* ADDRESS[16] DATA[30] used as GPIO */
+ pinctrl_weim_gpio_6: weimgpio-6 {
+ fsl,pins = <
+ MX6QDL_PAD_KEY_ROW4__GPIO4_IO15 0x1b0b0
+ MX6QDL_PAD_KEY_COL4__GPIO4_IO14 0x1b0b0
+ >;
+ };
+};
--
2.10.0
^ permalink raw reply related
* [PATCH] usb: dwc3: host: inherit dma configuration from parent dev
From: Arnd Bergmann @ 2016-09-21 11:31 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <DB5PR0401MB19259C5DBD40BEEC70F0B7CEF5F60@DB5PR0401MB1925.eurprd04.prod.outlook.com>
On Wednesday, September 21, 2016 11:06:47 AM CEST Sriram Dash wrote:
>
> Hello Arnd,
>
> We tried this patch on NXP platforms (ls2085 and ls1043) which use dwc3
> controller without any glue layer. On first go, this did not work. But after
> minimal reworks mention snippet below, we are able to verify that the USB
> was working OK.
>
> drivers/usb/host/xhci-mem.c | 12 ++++++------
> drivers/usb/host/xhci.c | 20 ++++++++++----------
>
> - struct device *dev = xhci_to_hcd(xhci)->self.controller;
> + struct device *dev = xhci_to_hcd(xhci)->self.sysdev;
>
> We believe the patch needs little modification to work or there might be chances
> we may have missed something. Any idea?
I had not tried the patch, it was just sent for clarification what I
meant, so I'm glad you got it working with just minimal changes.
Unfortunately, I can't tell from your lines above what exactly you
changed, can you send that again as a proper patch?
I think I also had some minimal changes that I did myself in order
to fix a build regression I introduced.
Arnd
^ permalink raw reply
* [PATCH v2 2/9] dmaengine: edma: Use enum for eDMA binding type (legacy vs TPCC)
From: Arnd Bergmann @ 2016-09-21 11:38 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <bbd248d1-223c-00a9-3d2a-33df085c4f68@ti.com>
On Wednesday, September 21, 2016 2:07:22 PM CEST Peter Ujfalusi wrote:
> >
> > I tend to use 'uintptr_t' for the cast instead.
>
> What about keeping the defines and:
>
> diff --git a/drivers/dma/edma.c b/drivers/dma/edma.c
> index 3e9606b08340..493fdf30e8b8 100644
> --- a/drivers/dma/edma.c
> +++ b/drivers/dma/edma.c
> @@ -263,14 +263,19 @@ static const struct edmacc_param dummy_paramset = {
>
> #define EDMA_BINDING_LEGACY 0
> #define EDMA_BINDING_TPCC 1
> +static const u32 edma_binding_type[] = {
> + [EDMA_BINDING_LEGACY] = EDMA_BINDING_LEGACY,
> + [EDMA_BINDING_TPCC] = EDMA_BINDING_TPCC,
> +};
> +
> static const struct of_device_id edma_of_ids[] = {
> {
> .compatible = "ti,edma3",
> - .data = (void *)EDMA_BINDING_LEGACY,
> + .data = (void *)&edma_binding_type[EDMA_BINDING_LEGACY],
> },
> {
> .compatible = "ti,edma3-tpcc",
> - .data = (void *)EDMA_BINDING_TPCC,
> + .data = (void *)&edma_binding_type[EDMA_BINDING_TPCC],
> },
> {}
You can drop the cast to (void *) here, otherwise looks good.
Arnd
^ permalink raw reply
* [PATCH] usb: dwc3: host: inherit dma configuration from parent dev
From: Sriram Dash @ 2016-09-21 11:43 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <3596831.dckG5peiyF@wuerfel>
>From: Arnd Bergmann [mailto:arnd at arndb.de]
>On Wednesday, September 21, 2016 11:06:47 AM CEST Sriram Dash wrote:
>>
>> Hello Arnd,
>>
>> We tried this patch on NXP platforms (ls2085 and ls1043) which use
>> dwc3 controller without any glue layer. On first go, this did not
>> work. But after minimal reworks mention snippet below, we are able to
>> verify that the USB was working OK.
>>
>> drivers/usb/host/xhci-mem.c | 12 ++++++------
>> drivers/usb/host/xhci.c | 20 ++++++++++----------
>>
>> - struct device *dev = xhci_to_hcd(xhci)->self.controller;
>> + struct device *dev = xhci_to_hcd(xhci)->self.sysdev;
>>
>> We believe the patch needs little modification to work or there might
>> be chances we may have missed something. Any idea?
>
>
>I had not tried the patch, it was just sent for clarification what I meant, so I'm glad
>you got it working with just minimal changes.
>
>Unfortunately, I can't tell from your lines above what exactly you changed, can you
>send that again as a proper patch?
>
Sure.
==============================================================
>From 8b0dea1513e9e73a11dcfa802ddc71cca11d66f8 Mon Sep 17 00:00:00 2001
From: Sriram Dash <sriram.dash@nxp.com>
Date: Wed, 21 Sep 2016 11:39:30 +0530
Subject: [PATCH] usb: xhci: Fix the patch inherit dma configuration from
parent dev
Fixes the patch https://patchwork.kernel.org/patch/9319527/
("usb: dwc3: host: inherit dma configuration from parent dev").
Signed-off-by: Sriram Dash <sriram.dash@nxp.com>
---
drivers/usb/host/xhci-mem.c | 12 ++++++------
drivers/usb/host/xhci.c | 20 ++++++++++----------
2 files changed, 16 insertions(+), 16 deletions(-)
diff --git a/drivers/usb/host/xhci-mem.c b/drivers/usb/host/xhci-mem.c
index 6afe323..79608df 100644
--- a/drivers/usb/host/xhci-mem.c
+++ b/drivers/usb/host/xhci-mem.c
@@ -586,7 +586,7 @@ static void xhci_free_stream_ctx(struct xhci_hcd *xhci,
unsigned int num_stream_ctxs,
struct xhci_stream_ctx *stream_ctx, dma_addr_t dma)
{
- struct device *dev = xhci_to_hcd(xhci)->self.controller;
+ struct device *dev = xhci_to_hcd(xhci)->self.sysdev;
size_t size = sizeof(struct xhci_stream_ctx) * num_stream_ctxs;
if (size > MEDIUM_STREAM_ARRAY_SIZE)
@@ -614,7 +614,7 @@ static struct xhci_stream_ctx *xhci_alloc_stream_ctx(struct xhci_hcd *xhci,
unsigned int num_stream_ctxs, dma_addr_t *dma,
gfp_t mem_flags)
{
- struct device *dev = xhci_to_hcd(xhci)->self.controller;
+ struct device *dev = xhci_to_hcd(xhci)->self.sysdev;
size_t size = sizeof(struct xhci_stream_ctx) * num_stream_ctxs;
if (size > MEDIUM_STREAM_ARRAY_SIZE)
@@ -1644,7 +1644,7 @@ void xhci_slot_copy(struct xhci_hcd *xhci,
static int scratchpad_alloc(struct xhci_hcd *xhci, gfp_t flags)
{
int i;
- struct device *dev = xhci_to_hcd(xhci)->self.controller;
+ struct device *dev = xhci_to_hcd(xhci)->self.sysdev;
int num_sp = HCS_MAX_SCRATCHPAD(xhci->hcs_params2);
xhci_dbg_trace(xhci, trace_xhci_dbg_init,
@@ -1716,7 +1716,7 @@ static void scratchpad_free(struct xhci_hcd *xhci)
{
int num_sp;
int i;
- struct device *dev = xhci_to_hcd(xhci)->self.controller;
+ struct device *dev = xhci_to_hcd(xhci)->self.sysdev;
if (!xhci->scratchpad)
return;
@@ -1792,7 +1792,7 @@ void xhci_free_command(struct xhci_hcd *xhci,
void xhci_mem_cleanup(struct xhci_hcd *xhci)
{
- struct device *dev = xhci_to_hcd(xhci)->self.controller;
+ struct device *dev = xhci_to_hcd(xhci)->self.sysdev;
int size;
int i, j, num_ports;
@@ -2334,7 +2334,7 @@ static int xhci_setup_port_arrays(struct xhci_hcd *xhci, gfp_t flags)
int xhci_mem_init(struct xhci_hcd *xhci, gfp_t flags)
{
dma_addr_t dma;
- struct device *dev = xhci_to_hcd(xhci)->self.controller;
+ struct device *dev = xhci_to_hcd(xhci)->self.sysdev;
unsigned int val, val2;
u64 val_64;
struct xhci_segment *seg;
diff --git a/drivers/usb/host/xhci.c b/drivers/usb/host/xhci.c
index 01d96c9..9a1ff09 100644
--- a/drivers/usb/host/xhci.c
+++ b/drivers/usb/host/xhci.c
@@ -231,7 +231,7 @@ static int xhci_free_msi(struct xhci_hcd *xhci)
static int xhci_setup_msi(struct xhci_hcd *xhci)
{
int ret;
- struct pci_dev *pdev = to_pci_dev(xhci_to_hcd(xhci)->self.controller);
+ struct pci_dev *pdev = to_pci_dev(xhci_to_hcd(xhci)->self.sysdev);
ret = pci_enable_msi(pdev);
if (ret) {
@@ -257,7 +257,7 @@ static int xhci_setup_msi(struct xhci_hcd *xhci)
*/
static void xhci_free_irq(struct xhci_hcd *xhci)
{
- struct pci_dev *pdev = to_pci_dev(xhci_to_hcd(xhci)->self.controller);
+ struct pci_dev *pdev = to_pci_dev(xhci_to_hcd(xhci)->self.sysdev);
int ret;
/* return if using legacy interrupt */
@@ -280,7 +280,7 @@ static int xhci_setup_msix(struct xhci_hcd *xhci)
{
int i, ret = 0;
struct usb_hcd *hcd = xhci_to_hcd(xhci);
- struct pci_dev *pdev = to_pci_dev(hcd->self.controller);
+ struct pci_dev *pdev = to_pci_dev(hcd->self.sysdev);
/*
* calculate number of msi-x vectors supported.
@@ -337,7 +337,7 @@ free_entries:
static void xhci_cleanup_msix(struct xhci_hcd *xhci)
{
struct usb_hcd *hcd = xhci_to_hcd(xhci);
- struct pci_dev *pdev = to_pci_dev(hcd->self.controller);
+ struct pci_dev *pdev = to_pci_dev(hcd->self.sysdev);
if (xhci->quirks & XHCI_PLAT)
return;
@@ -376,7 +376,7 @@ static int xhci_try_enable_msi(struct usb_hcd *hcd)
if (xhci->quirks & XHCI_PLAT)
return 0;
- pdev = to_pci_dev(xhci_to_hcd(xhci)->self.controller);
+ pdev = to_pci_dev(xhci_to_hcd(xhci)->self.sysdev);
/*
* Some Fresco Logic host controllers advertise MSI, but fail to
* generate interrupts. Don't even try to enable MSI.
@@ -745,7 +745,7 @@ void xhci_shutdown(struct usb_hcd *hcd)
struct xhci_hcd *xhci = hcd_to_xhci(hcd);
if (xhci->quirks & XHCI_SPURIOUS_REBOOT)
- usb_disable_xhci_ports(to_pci_dev(hcd->self.controller));
+ usb_disable_xhci_ports(to_pci_dev(hcd->self.sysdev));
spin_lock_irq(&xhci->lock);
xhci_halt(xhci);
@@ -762,7 +762,7 @@ void xhci_shutdown(struct usb_hcd *hcd)
/* Yet another workaround for spurious wakeups at shutdown with HSW */
if (xhci->quirks & XHCI_SPURIOUS_WAKEUP)
- pci_set_power_state(to_pci_dev(hcd->self.controller), PCI_D3hot);
+ pci_set_power_state(to_pci_dev(hcd->self.sysdev), PCI_D3hot);
}
#ifdef CONFIG_PM
@@ -3605,7 +3605,7 @@ void xhci_free_dev(struct usb_hcd *hcd, struct usb_device *udev)
* if no devices remain.
*/
if (xhci->quirks & XHCI_RESET_ON_RESUME)
- pm_runtime_put_noidle(hcd->self.controller);
+ pm_runtime_put_noidle(hcd->self.sysdev);
#endif
ret = xhci_check_args(hcd, udev, NULL, 0, true, __func__);
@@ -3745,7 +3745,7 @@ int xhci_alloc_dev(struct usb_hcd *hcd, struct usb_device *udev)
* suspend if there is a device attached.
*/
if (xhci->quirks & XHCI_RESET_ON_RESUME)
- pm_runtime_get_noresume(hcd->self.controller);
+ pm_runtime_get_noresume(hcd->self.sysdev);
#endif
@@ -4834,7 +4834,7 @@ int xhci_get_frame(struct usb_hcd *hcd)
int xhci_gen_setup(struct usb_hcd *hcd, xhci_get_quirks_t get_quirks)
{
struct xhci_hcd *xhci;
- struct device *dev = hcd->self.controller;
+ struct device *dev = hcd->self.sysdev;
int retval;
/* Accept arbitrarily long scatter-gather lists */
--
2.1.0
==============================================================
>I think I also had some minimal changes that I did myself in order to fix a build
>regression I introduced.
>
> Arnd
^ permalink raw reply related
* [PATCH v9 17/19] drm/virtio: kconfig: Fix recursive dependency issue.
From: Emil Velikov @ 2016-09-21 12:09 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20160920083251.GB26093@griffinp-ThinkPad-X1-Carbon-2nd>
On 20 September 2016 at 09:32, Peter Griffin <peter.griffin@linaro.org> wrote:
> Hi Emil,
>
> On Tue, 20 Sep 2016, Emil Velikov wrote:
>
>> On 5 September 2016 at 14:16, Peter Griffin <peter.griffin@linaro.org> wrote:
>> > ST_SLIM_REMOTEPROC must select REMOTEPROC, which exposes the following
>> > recursive dependency.
>
>
>> >
>> From a humble skim through remoteproc, drm and a few other subsystems
>> I think the above is wrong. All the drivers (outside of remoteproc),
>> that I've seen, depend on the core component, they don't select it.
>
> I will let Bjorn comment on the remoteproc subsystem Kconfig design, and
> why it is like it is.
>
> For this particular SLIM_RPROC I have added it to Kconfig in keeping with all
> the other drivers in the remoteproc subsystem which has exposed this recursive
> dependency issue.
>
> For this particular kconfig symbol a quick grep reveals more drivers in
> the kernel using 'select', than 'depend on'
>
> git grep "select VIRTIO" | wc -l
> 14
>
> git grep "depends on VIRTIO" | wc -l
> 10
>
Might be worth taking a closer look into these at some point.
>
>> Furthermore most places explicitly hide the drivers from the menu if
>> the core component isn't enabled.
>
> Remoteproc subsystem takes a different approach, the core code is only enabled
> if a driver which relies on it is enabled. This IMHO makes sense, as
> remoteproc is not widely used (only a few particular ARM SoC's).
>
> It is true that for subsystems which rely on the core component being
> explicitly enabled, they often tend to hide drivers which depend on it
> from the menu unless it is. This also makes sense.
>
>>
>> Is there something that requires such a different/unusual behaviour in
>> remoteproc ?
>>
>
> I'm not sure it is that unusual...looking at config USB, it selects USB_COMMON in
> mfd subsystem, client drivers select MFD_CORE.
>
On the USB case I'm not sure what the reasoning behind the USB vs
USB_COMMON split. In seems that one could just fold them, but that's
another topic. On the MFD side... it follows the select {,mis,ab}use.
With one (the only one?) MFD driver not using/selecting MFD_CORE doing
it's own version of mfd_add_devices... which could be reworked,
possibly.
> I've added Arnd to this thread, as I've seen lots of Kconfig patches from him
> recently, maybe he has some thoughts on whether this is the correct fix or not?
>
Ack. Fwiw, I believe that the reasoning put by Jani is perfeclty
reasonable, but it'll be great to hear others as well.
Thanks
Emil
^ permalink raw reply
* [PATCH v3 0/9] dmaengine: ti drivers: enable COMPILE_TESTing
From: Peter Ujfalusi @ 2016-09-21 12:41 UTC (permalink / raw)
To: linux-arm-kernel
Hi,
Changes since v2:
- Instead of converting to use enum for the of_device_id data parameter the two
patch for edma and ti-dma-crossbar is using pointers to u32 variables to make
sure that the code compile (and in theory work) on all architectures.
- fixed issue in the ti-dma-crossbar driver I have made with the enum change to
not handle the DMA offset parameters correctly.
Changes since v1:
- added the compiler warning message to ti-dma-crossbar enum type patch
- moved the Kconfig patches at the end of the seris
The following series will enable unconditional COMPILE_TEST coverage for the
following drivers: omap-dma, edma and ti-dma-crossbar
The series includes fixes noticed when compiling the drivers for x86_64 and
aarch64.
Replaces the patch Vinod sent to enable partial compile testing for omap-dma:
http://www.spinics.net/lists/dmaengine/msg11025.html
Regards,
Peter
---
Peter Ujfalusi (9):
dmaengine: edma: Add missing MODULE_DEVICE_TABLE() for of_device_id
structs
dmaengine: edma: Fix of_device_id data parameter usage (legacy vs
TPCC)
dmaengine: edma: Use correct type for of_find_property() third
parameter
dmaengine/ARM: omap-dma: Fix the DMAengine compile test on non OMAP
configs
dmaengine: ti-dma-crossbar: Correct type for of_find_property() third
parameter
dmaengine: ti-dma-crossbar: Fix of_device_id data parameter usage
dmaengine: edma: enable COMPILE_TEST
dmaengine: omap-dma: enable COMPILE_TEST
dmaengine: ti-dma-crossbar: enable COMPILE_TEST
drivers/dma/Kconfig | 8 ++++----
drivers/dma/edma.c | 16 +++++++++++-----
drivers/dma/ti-dma-crossbar.c | 30 +++++++++++++++++++-----------
include/linux/omap-dma.h | 19 +++++++++++++++++++
4 files changed, 53 insertions(+), 20 deletions(-)
--
2.10.0
^ permalink raw reply
* [PATCH v3 1/9] dmaengine: edma: Add missing MODULE_DEVICE_TABLE() for of_device_id structs
From: Peter Ujfalusi @ 2016-09-21 12:41 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20160921124135.11849-1-peter.ujfalusi@ti.com>
The MODULE_DEVICE_TABLE() were missing from the driver for the of_device_id
structures.
Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com>
---
drivers/dma/edma.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/dma/edma.c b/drivers/dma/edma.c
index 3d277fa76c1a..c2098a4b4dcf 100644
--- a/drivers/dma/edma.c
+++ b/drivers/dma/edma.c
@@ -274,11 +274,13 @@ static const struct of_device_id edma_of_ids[] = {
},
{}
};
+MODULE_DEVICE_TABLE(of, edma_of_ids);
static const struct of_device_id edma_tptc_of_ids[] = {
{ .compatible = "ti,edma3-tptc", },
{}
};
+MODULE_DEVICE_TABLE(of, edma_tptc_of_ids);
static inline unsigned int edma_read(struct edma_cc *ecc, int offset)
{
--
2.10.0
^ permalink raw reply related
* [PATCH v3 2/9] dmaengine: edma: Fix of_device_id data parameter usage (legacy vs TPCC)
From: Peter Ujfalusi @ 2016-09-21 12:41 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20160921124135.11849-1-peter.ujfalusi@ti.com>
Use pointers to static constant variables for eDMA binding
type (legacy vs TPCC).
Fixes the following warning when compiling the driver for 64bit
architectures (x86_64 for example):
drivers/dma/edma.c:2185:16: warning: cast from pointer to integer of different size [-Wpointer-to-int-cast]
if (match && (u32)match->data == EDMA_BINDING_TPCC)
^
Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com>
---
drivers/dma/edma.c | 11 ++++++++---
1 file changed, 8 insertions(+), 3 deletions(-)
diff --git a/drivers/dma/edma.c b/drivers/dma/edma.c
index c2098a4b4dcf..87c58710ae31 100644
--- a/drivers/dma/edma.c
+++ b/drivers/dma/edma.c
@@ -263,14 +263,19 @@ static const struct edmacc_param dummy_paramset = {
#define EDMA_BINDING_LEGACY 0
#define EDMA_BINDING_TPCC 1
+static const u32 edma_binding_type[] = {
+ [EDMA_BINDING_LEGACY] = EDMA_BINDING_LEGACY,
+ [EDMA_BINDING_TPCC] = EDMA_BINDING_TPCC,
+};
+
static const struct of_device_id edma_of_ids[] = {
{
.compatible = "ti,edma3",
- .data = (void *)EDMA_BINDING_LEGACY,
+ .data = &edma_binding_type[EDMA_BINDING_LEGACY],
},
{
.compatible = "ti,edma3-tpcc",
- .data = (void *)EDMA_BINDING_TPCC,
+ .data = &edma_binding_type[EDMA_BINDING_TPCC],
},
{}
};
@@ -2184,7 +2189,7 @@ static int edma_probe(struct platform_device *pdev)
const struct of_device_id *match;
match = of_match_node(edma_of_ids, node);
- if (match && (u32)match->data == EDMA_BINDING_TPCC)
+ if (match && (*(u32*)match->data) == EDMA_BINDING_TPCC)
legacy_mode = false;
info = edma_setup_info_from_dt(dev, legacy_mode);
--
2.10.0
^ permalink raw reply related
* [PATCH v3 3/9] dmaengine: edma: Use correct type for of_find_property() third parameter
From: Peter Ujfalusi @ 2016-09-21 12:41 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20160921124135.11849-1-peter.ujfalusi@ti.com>
The correct type is int and not for the third parameter of
of_find_property().
Fixes compilation for 64bit architectures (x86_64, aarch64).
Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com>
---
drivers/dma/edma.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/dma/edma.c b/drivers/dma/edma.c
index 87c58710ae31..0241f39ba64c 100644
--- a/drivers/dma/edma.c
+++ b/drivers/dma/edma.c
@@ -2026,8 +2026,7 @@ static struct edma_soc_info *edma_setup_info_from_dt(struct device *dev,
{
struct edma_soc_info *info;
struct property *prop;
- size_t sz;
- int ret;
+ int sz, ret;
info = devm_kzalloc(dev, sizeof(struct edma_soc_info), GFP_KERNEL);
if (!info)
--
2.10.0
^ permalink raw reply related
* [PATCH v3 4/9] dmaengine/ARM: omap-dma: Fix the DMAengine compile test on non OMAP configs
From: Peter Ujfalusi @ 2016-09-21 12:41 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20160921124135.11849-1-peter.ujfalusi@ti.com>
The DMAengine driver for omap-dma use three function calls from the
plat-omap legacy driver. When the DMAengine driver is built when ARCH_OMAP
is not set, the compilation will fail due to missing symbols.
Add empty inline functions to allow the DMAengine driver to be compiled
with COMPILE_TEST.
Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com>
---
include/linux/omap-dma.h | 19 +++++++++++++++++++
1 file changed, 19 insertions(+)
diff --git a/include/linux/omap-dma.h b/include/linux/omap-dma.h
index 1d99b61adc65..290081620b3e 100644
--- a/include/linux/omap-dma.h
+++ b/include/linux/omap-dma.h
@@ -297,6 +297,7 @@ struct omap_system_dma_plat_info {
#define dma_omap15xx() __dma_omap15xx(d)
#define dma_omap16xx() __dma_omap16xx(d)
+#if defined(CONFIG_ARCH_OMAP)
extern struct omap_system_dma_plat_info *omap_get_plat_info(void);
extern void omap_set_dma_priority(int lch, int dst_port, int priority);
@@ -355,4 +356,22 @@ static inline int omap_lcd_dma_running(void)
}
#endif
+#else /* CONFIG_ARCH_OMAP */
+
+static inline struct omap_system_dma_plat_info *omap_get_plat_info(void)
+{
+ return NULL;
+}
+
+static inline int omap_request_dma(int dev_id, const char *dev_name,
+ void (*callback)(int lch, u16 ch_status, void *data),
+ void *data, int *dma_ch)
+{
+ return -ENODEV;
+}
+
+static inline void omap_free_dma(int ch) { }
+
+#endif /* CONFIG_ARCH_OMAP */
+
#endif /* __LINUX_OMAP_DMA_H */
--
2.10.0
^ permalink raw reply related
* [PATCH v3 5/9] dmaengine: ti-dma-crossbar: Correct type for of_find_property() third parameter
From: Peter Ujfalusi @ 2016-09-21 12:41 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20160921124135.11849-1-peter.ujfalusi@ti.com>
The correct type is int and not for the third parameter of
of_find_property().
Fixes compilation for 64bit architectures (x86_64, aarch64).
Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com>
---
drivers/dma/ti-dma-crossbar.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/dma/ti-dma-crossbar.c b/drivers/dma/ti-dma-crossbar.c
index 5ae294b256a7..e4f3bd1ae264 100644
--- a/drivers/dma/ti-dma-crossbar.c
+++ b/drivers/dma/ti-dma-crossbar.c
@@ -311,7 +311,7 @@ static int ti_dra7_xbar_probe(struct platform_device *pdev)
struct property *prop;
struct resource *res;
u32 safe_val;
- size_t sz;
+ int sz;
void __iomem *iomem;
int i, ret;
--
2.10.0
^ permalink raw reply related
* [PATCH v3 6/9] dmaengine: ti-dma-crossbar: Fix of_device_id data parameter usage
From: Peter Ujfalusi @ 2016-09-21 12:41 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20160921124135.11849-1-peter.ujfalusi@ti.com>
Use pointers to static constant variables for crossbar type and for DMA
offset configuration.
Fixes compiler warnings on 64bit architectures:
drivers/dma/ti-dma-crossbar.c: In function ?ti_dra7_xbar_probe?:
drivers/dma/ti-dma-crossbar.c:398:21: warning: cast from pointer to integer of different size [-Wpointer-to-int-cast]
xbar->dma_offset = (u32)match->data;
^
drivers/dma/ti-dma-crossbar.c: In function ?ti_dma_xbar_probe?:
drivers/dma/ti-dma-crossbar.c:431:10: warning: cast from pointer to integer of different size [-Wpointer-to-int-cast]
switch ((u32)match->data) {
^
Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com>
---
drivers/dma/ti-dma-crossbar.c | 28 ++++++++++++++++++----------
1 file changed, 18 insertions(+), 10 deletions(-)
diff --git a/drivers/dma/ti-dma-crossbar.c b/drivers/dma/ti-dma-crossbar.c
index e4f3bd1ae264..9103b1260797 100644
--- a/drivers/dma/ti-dma-crossbar.c
+++ b/drivers/dma/ti-dma-crossbar.c
@@ -18,15 +18,19 @@
#define TI_XBAR_DRA7 0
#define TI_XBAR_AM335X 1
+static const u32 ti_xbar_type[] = {
+ [TI_XBAR_DRA7] = TI_XBAR_DRA7,
+ [TI_XBAR_AM335X] = TI_XBAR_AM335X,
+};
static const struct of_device_id ti_dma_xbar_match[] = {
{
.compatible = "ti,dra7-dma-crossbar",
- .data = (void *)TI_XBAR_DRA7,
+ .data = &ti_xbar_type[TI_XBAR_DRA7],
},
{
.compatible = "ti,am335x-edma-crossbar",
- .data = (void *)TI_XBAR_AM335X,
+ .data = &ti_xbar_type[TI_XBAR_AM335X],
},
{},
};
@@ -190,9 +194,6 @@ static int ti_am335x_xbar_probe(struct platform_device *pdev)
#define TI_DRA7_XBAR_OUTPUTS 127
#define TI_DRA7_XBAR_INPUTS 256
-#define TI_XBAR_EDMA_OFFSET 0
-#define TI_XBAR_SDMA_OFFSET 1
-
struct ti_dra7_xbar_data {
void __iomem *iomem;
@@ -280,18 +281,25 @@ static void *ti_dra7_xbar_route_allocate(struct of_phandle_args *dma_spec,
return map;
}
+#define TI_XBAR_EDMA_OFFSET 0
+#define TI_XBAR_SDMA_OFFSET 1
+static const u32 ti_dma_offset[] = {
+ [TI_XBAR_EDMA_OFFSET] = 0,
+ [TI_XBAR_SDMA_OFFSET] = 1,
+};
+
static const struct of_device_id ti_dra7_master_match[] = {
{
.compatible = "ti,omap4430-sdma",
- .data = (void *)TI_XBAR_SDMA_OFFSET,
+ .data = &ti_dma_offset[TI_XBAR_SDMA_OFFSET],
},
{
.compatible = "ti,edma3",
- .data = (void *)TI_XBAR_EDMA_OFFSET,
+ .data = &ti_dma_offset[TI_XBAR_EDMA_OFFSET],
},
{
.compatible = "ti,edma3-tpcc",
- .data = (void *)TI_XBAR_EDMA_OFFSET,
+ .data = &ti_dma_offset[TI_XBAR_EDMA_OFFSET],
},
{},
};
@@ -395,7 +403,7 @@ static int ti_dra7_xbar_probe(struct platform_device *pdev)
xbar->dmarouter.dev = &pdev->dev;
xbar->dmarouter.route_free = ti_dra7_xbar_free;
- xbar->dma_offset = (u32)match->data;
+ xbar->dma_offset = *(u32*)match->data;
mutex_init(&xbar->mutex);
platform_set_drvdata(pdev, xbar);
@@ -428,7 +436,7 @@ static int ti_dma_xbar_probe(struct platform_device *pdev)
if (unlikely(!match))
return -EINVAL;
- switch ((u32)match->data) {
+ switch (*(u32*)match->data) {
case TI_XBAR_DRA7:
ret = ti_dra7_xbar_probe(pdev);
break;
--
2.10.0
^ permalink raw reply related
* [PATCH v3 7/9] dmaengine: edma: enable COMPILE_TEST
From: Peter Ujfalusi @ 2016-09-21 12:41 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20160921124135.11849-1-peter.ujfalusi@ti.com>
To get more coverage, enable COMPILE_TEST for this driver.
Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com>
---
drivers/dma/Kconfig | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/dma/Kconfig b/drivers/dma/Kconfig
index fe2dbb811e19..4348249b943a 100644
--- a/drivers/dma/Kconfig
+++ b/drivers/dma/Kconfig
@@ -515,7 +515,7 @@ config TI_DMA_CROSSBAR
config TI_EDMA
bool "TI EDMA support"
- depends on ARCH_DAVINCI || ARCH_OMAP || ARCH_KEYSTONE
+ depends on ARCH_DAVINCI || ARCH_OMAP || ARCH_KEYSTONE || COMPILE_TEST
select DMA_ENGINE
select DMA_VIRTUAL_CHANNELS
select TI_DMA_CROSSBAR if ARCH_OMAP
--
2.10.0
^ permalink raw reply related
* [PATCH v3 8/9] dmaengine: omap-dma: enable COMPILE_TEST
From: Peter Ujfalusi @ 2016-09-21 12:41 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20160921124135.11849-1-peter.ujfalusi@ti.com>
To get more coverage, enable COMPILE_TEST for this driver.
Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com>
---
drivers/dma/Kconfig | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/dma/Kconfig b/drivers/dma/Kconfig
index 4348249b943a..84647d6cb2f4 100644
--- a/drivers/dma/Kconfig
+++ b/drivers/dma/Kconfig
@@ -130,7 +130,7 @@ config DMA_JZ4780
config DMA_OMAP
tristate "OMAP DMA support"
- depends on ARCH_OMAP
+ depends on ARCH_OMAP || COMPILE_TEST
select DMA_ENGINE
select DMA_VIRTUAL_CHANNELS
select TI_DMA_CROSSBAR if SOC_DRA7XX
--
2.10.0
^ permalink raw reply related
* [PATCH v3 9/9] dmaengine: ti-dma-crossbar: enable COMPILE_TEST
From: Peter Ujfalusi @ 2016-09-21 12:41 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20160921124135.11849-1-peter.ujfalusi@ti.com>
To get more coverage, enable COMPILE_TEST for this driver.
When compile testing eDMA or omap-dma, select also the ti-dma-crossbar so
it is also covered by the compile testing.
Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com>
---
drivers/dma/Kconfig | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/dma/Kconfig b/drivers/dma/Kconfig
index 84647d6cb2f4..1c11628062ad 100644
--- a/drivers/dma/Kconfig
+++ b/drivers/dma/Kconfig
@@ -133,7 +133,7 @@ config DMA_OMAP
depends on ARCH_OMAP || COMPILE_TEST
select DMA_ENGINE
select DMA_VIRTUAL_CHANNELS
- select TI_DMA_CROSSBAR if SOC_DRA7XX
+ select TI_DMA_CROSSBAR if (SOC_DRA7XX || COMPILE_TEST)
config DMA_SA11X0
tristate "SA-11x0 DMA support"
@@ -518,7 +518,7 @@ config TI_EDMA
depends on ARCH_DAVINCI || ARCH_OMAP || ARCH_KEYSTONE || COMPILE_TEST
select DMA_ENGINE
select DMA_VIRTUAL_CHANNELS
- select TI_DMA_CROSSBAR if ARCH_OMAP
+ select TI_DMA_CROSSBAR if (ARCH_OMAP || COMPILE_TEST)
default n
help
Enable support for the TI EDMA controller. This DMA
--
2.10.0
^ permalink raw reply related
* [PATCH] usb: dwc3: host: inherit dma configuration from parent dev
From: Arnd Bergmann @ 2016-09-21 12:48 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <DB5PR0401MB1925CDF6CBD45ACBEE95D152F5F60@DB5PR0401MB1925.eurprd04.prod.outlook.com>
On Wednesday, September 21, 2016 11:43:59 AM CEST Sriram Dash wrote:
> >From: Arnd Bergmann [mailto:arnd at arndb.de]
> >On Wednesday, September 21, 2016 11:06:47 AM CEST Sriram Dash wrote:
>
> ==============================================================
> From 8b0dea1513e9e73a11dcfa802ddc71cca11d66f8 Mon Sep 17 00:00:00 2001
> From: Sriram Dash <sriram.dash@nxp.com>
> Date: Wed, 21 Sep 2016 11:39:30 +0530
> Subject: [PATCH] usb: xhci: Fix the patch inherit dma configuration from
> parent dev
>
> Fixes the patch https://patchwork.kernel.org/patch/9319527/
> ("usb: dwc3: host: inherit dma configuration from parent dev").
>
> Signed-off-by: Sriram Dash <sriram.dash@nxp.com>
> ---
> drivers/usb/host/xhci-mem.c | 12 ++++++------
> drivers/usb/host/xhci.c | 20 ++++++++++----------
> 2 files changed, 16 insertions(+), 16 deletions(-)
>
> diff --git a/drivers/usb/host/xhci-mem.c b/drivers/usb/host/xhci-mem.c
> index 6afe323..79608df 100644
> --- a/drivers/usb/host/xhci-mem.c
> +++ b/drivers/usb/host/xhci-mem.c
All the changes you did to this file seem fine, I completely missed that part.
> diff --git a/drivers/usb/host/xhci.c b/drivers/usb/host/xhci.c
> index 01d96c9..9a1ff09 100644
> --- a/drivers/usb/host/xhci.c
> +++ b/drivers/usb/host/xhci.c
> @@ -231,7 +231,7 @@ static int xhci_free_msi(struct xhci_hcd *xhci)
> static int xhci_setup_msi(struct xhci_hcd *xhci)
> {
> int ret;
> - struct pci_dev *pdev = to_pci_dev(xhci_to_hcd(xhci)->self.controller);
> + struct pci_dev *pdev = to_pci_dev(xhci_to_hcd(xhci)->self.sysdev);
>
> ret = pci_enable_msi(pdev);
> if (ret) {
This one is interesting as I stumbled over some code comment mentioning
that for dwc3-pci, we don't support MSI. I think with this change,
we /can/ actually support MSI, but this could be a separate patch
and we'd have to test it on dwc3-pci hardware. Same for most of
this file.
> @@ -745,7 +745,7 @@ void xhci_shutdown(struct usb_hcd *hcd)
> struct xhci_hcd *xhci = hcd_to_xhci(hcd);
>
> if (xhci->quirks & XHCI_SPURIOUS_REBOOT)
> - usb_disable_xhci_ports(to_pci_dev(hcd->self.controller));
> + usb_disable_xhci_ports(to_pci_dev(hcd->self.sysdev));
>
> spin_lock_irq(&xhci->lock);
> xhci_halt(xhci);
This seems obviously correct, but I don't yet see why it currently
works. We probably don't call this function on dwc3.
> #ifdef CONFIG_PM
> @@ -3605,7 +3605,7 @@ void xhci_free_dev(struct usb_hcd *hcd, struct usb_device *udev)
> * if no devices remain.
> */
> if (xhci->quirks & XHCI_RESET_ON_RESUME)
> - pm_runtime_put_noidle(hcd->self.controller);
> + pm_runtime_put_noidle(hcd->self.sysdev);
> #endif
>
> ret = xhci_check_args(hcd, udev, NULL, 0, true, __func__);
I suspect this one is wrong, based on what Felipe explained earlier:
the power management should propagate down from the child to the
parent device.
Someone who understands this better than I do should look at it.
> @@ -3745,7 +3745,7 @@ int xhci_alloc_dev(struct usb_hcd *hcd, struct usb_device *udev)
> * suspend if there is a device attached.
> */
> if (xhci->quirks & XHCI_RESET_ON_RESUME)
> - pm_runtime_get_noresume(hcd->self.controller);
> + pm_runtime_get_noresume(hcd->self.sysdev);
> #endif
>
>
Same here.
> @@ -4834,7 +4834,7 @@ int xhci_get_frame(struct usb_hcd *hcd)
> int xhci_gen_setup(struct usb_hcd *hcd, xhci_get_quirks_t get_quirks)
> {
> struct xhci_hcd *xhci;
> - struct device *dev = hcd->self.controller;
> + struct device *dev = hcd->self.sysdev;
> int retval;
This one calls
get_quirks(dev, xhci);
not sure whether this should be called with self.controller or
self.sysdev, we should audit every one of the callers here to
be sure:
drivers/usb/host/xhci-mtk.c: return xhci_gen_setup(hcd, xhci_mtk_quirks);
drivers/usb/host/xhci-pci.c: retval = xhci_gen_setup(hcd, xhci_pci_quirks);
drivers/usb/host/xhci-plat.c: return xhci_gen_setup(hcd, xhci_plat_quirks);
drivers/usb/host/xhci-rcar.c: * xhci_gen_setup().
drivers/usb/host/xhci-tegra.c: return xhci_gen_setup(hcd, tegra_xhci_quirks);
Arnd
^ permalink raw reply
* [PATCH] drm/sun4i: rgb: Enable panel after controller
From: Jonathan Liu @ 2016-09-21 13:03 UTC (permalink / raw)
To: linux-arm-kernel
The panel should be enabled after the controller so that the panel
prepare/enable delays are properly taken into account. Similarly, the
panel should be disabled before the controller so that the panel
unprepare/disable delays are properly taken into account.
This is useful for avoiding visual glitches.
Signed-off-by: Jonathan Liu <net147@gmail.com>
---
drivers/gpu/drm/sun4i/sun4i_rgb.c | 14 ++++++++------
1 file changed, 8 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/sun4i/sun4i_rgb.c b/drivers/gpu/drm/sun4i/sun4i_rgb.c
index c3ff10f..4e4bea6 100644
--- a/drivers/gpu/drm/sun4i/sun4i_rgb.c
+++ b/drivers/gpu/drm/sun4i/sun4i_rgb.c
@@ -152,15 +152,16 @@ static void sun4i_rgb_encoder_enable(struct drm_encoder *encoder)
DRM_DEBUG_DRIVER("Enabling RGB output\n");
- if (!IS_ERR(tcon->panel)) {
+ if (!IS_ERR(tcon->panel))
drm_panel_prepare(tcon->panel);
- drm_panel_enable(tcon->panel);
- }
/* encoder->bridge can be NULL; drm_bridge_enable checks for it */
drm_bridge_enable(encoder->bridge);
sun4i_tcon_channel_enable(tcon, 0);
+
+ if (!IS_ERR(tcon->panel))
+ drm_panel_enable(tcon->panel);
}
static void sun4i_rgb_encoder_disable(struct drm_encoder *encoder)
@@ -171,15 +172,16 @@ static void sun4i_rgb_encoder_disable(struct drm_encoder *encoder)
DRM_DEBUG_DRIVER("Disabling RGB output\n");
+ if (!IS_ERR(tcon->panel))
+ drm_panel_disable(tcon->panel);
+
sun4i_tcon_channel_disable(tcon, 0);
/* encoder->bridge can be NULL; drm_bridge_disable checks for it */
drm_bridge_disable(encoder->bridge);
- if (!IS_ERR(tcon->panel)) {
- drm_panel_disable(tcon->panel);
+ if (!IS_ERR(tcon->panel))
drm_panel_unprepare(tcon->panel);
- }
}
static void sun4i_rgb_encoder_mode_set(struct drm_encoder *encoder,
--
2.10.0
^ permalink raw reply related
* [PATCH V6 0/5] ECAM quirks handling for ARM64 platforms
From: Bjorn Helgaas @ 2016-09-21 13:11 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <0429663d51ed8e93fb0c96261dd2ecc7@codeaurora.org>
On Tue, Sep 20, 2016 at 09:15:14PM -0400, cov at codeaurora.org wrote:
> Hi Bjorn, Thomasz,
>
> On 2016-09-20 15:26, Bjorn Helgaas wrote:
> >On Fri, Sep 09, 2016 at 09:24:02PM +0200, Tomasz Nowicki wrote:
> >>Quirk handling relies on an idea of simple static array which contains
> >>quirk enties. Each entry consists of identification information
> >>(IDs from
> >>standard header of MCFG table) along with custom pci_ecam_ops
> >>structure and
> >>configuration space resource structure. This way it is possible find
> >>corresponding quirk entries and override pci_ecam_ops and PCI
> >>configuration
> >>space regions.
> >>
> >>As an example, the last 3 patches present quirk handling
> >>mechanism usage for
> >>ThunderX.
> >>
> >>v5 -> v6
> >>- rebase against v4.8-rc5
> >>- drop patch 1 form previous series
> >>- keep pci_acpi_setup_ecam_mapping() in ARM64 arch directory
> >>- move quirk code to pci_mcfg.c
> >>- restrict quirk to override pci_ecam_ops and CFG resource structure
> >> only, no init call any more
> >>- split ThunderX quirks into the smaller chunks
> >>- add ThunderX pass1.x silicon revision support
> >>
> >>v4 -> v5
> >>- rebase against v4.8-rc1
> >>- rework to exact MCFG OEM ID, TABLE ID, rev match
> >> - use memcmp instead of strncmp
> >> - no substring match
> >>- fix typos and dmesg message
> >>
> >>Tomasz Nowicki (5):
> >> PCI/ACPI: Extend pci_mcfg_lookup() responsibilities
> >> PCI/ACPI: Check platform specific ECAM quirks
> >> PCI: thunder-pem: Allow to probe PEM-specific register range
> >>for ACPI
> >> case
> >> PCI: thunder: Enable ACPI PCI controller for ThunderX pass2.x
> >>silicon
> >> version
> >> PCI: thunder: Enable ACPI PCI controller for ThunderX pass1.x
> >>silicon
> >> version
> >>
> >> arch/arm64/kernel/pci.c | 17 ++--
> >> drivers/acpi/pci_mcfg.c | 168
> >>+++++++++++++++++++++++++++++++++++-
> >> drivers/pci/host/pci-thunder-ecam.c | 2 +-
> >> drivers/pci/host/pci-thunder-pem.c | 63 +++++++++++---
> >> include/linux/pci-acpi.h | 4 +-
> >> include/linux/pci-ecam.h | 7 ++
> >> 6 files changed, 230 insertions(+), 31 deletions(-)
> >
> >I'm not quite ready to merge these because we haven't resolved the
> >question of how to expose the resources used by the memory-mapped
> >config space. I'm fine with the first two patches (I did make a
> >couple trivial changes, see below), but there's no point in merging
> >them until we merge a user for them.
> >
> >I pushed the series to pci/ecam-v6 for build testing and discussion.
> >The diff (the changes I made locally) from v6 as posted by Tomasz is
> >below.
>
> Rebasing the following simple quirks framework user onto this branch,
> I have some questions.
>
> https://source.codeaurora.org/quic/server/kernel/commit/?h=cov/4.8-rc2-testing&id=83b766cafef11c107b10177d0626db311f382299
>
> >diff --git a/drivers/acpi/pci_mcfg.c b/drivers/acpi/pci_mcfg.c
> >index eb14f74..bb3b8ad 100644
> >--- a/drivers/acpi/pci_mcfg.c
> >+++ b/drivers/acpi/pci_mcfg.c
> >@@ -42,86 +42,59 @@ struct mcfg_fixup {
> > struct resource cfgres;
> > };
> >
> >-#define MCFG_DOM_ANY (-1)
>
> Did you delete this because there were no current users, because you'd
> prefer users just use "-1", or for some other reason?
I removed it because there were no users of it and, more importantly,
the code doesn't implement support for it.
> > #define MCFG_BUS_RANGE(start, end) DEFINE_RES_NAMED((start), \
> > ((end) - (start) + 1), \
> > NULL, IORESOURCE_BUS)
> >-#define MCFG_BUS_ANY MCFG_BUS_RANGE(0x0, 0xff)
> >-#define MCFG_RES_EMPTY DEFINE_RES_NAMED(0, 0, NULL, 0)
> >+#define MCFG_BUS_ANY MCFG_BUS_RANGE(0x0, 0xff)
> >
> > static struct mcfg_fixup mcfg_quirks[] = {
> >-/* { OEM_ID, OEM_TABLE_ID, REV, DOMAIN, BUS_RANGE, cfgres, ops }, */
> >+/* { OEM_ID, OEM_TABLE_ID, REV, SEGMENT, BUS_RANGE, cfgres, ops }, */
>
> This comment appears to have the order of cfgres and ops reversed.
Fixed, thanks!
> Am I correct in reading that if a user of the framework does not wish to
> override cfgres they must place a struct resource with .start = 0 at the
> end of their mcfg_quirks entry? If so, I guess I have the same questions
> about removing MCFG_RES_EMPTY as I do about removing MCFG_DOM_ANY.
You're right that we only override cfgres if the quirk supplies a
struct resource with non-zero .start. I removed MCFG_RES_EMPTY
because mcfg_quirks[] is a static array and is initialized with all
members being zero anyway. If a quirk doesn't need to override
cfgres, I think it's more readable if the quirk just doesn't mention
the resource at all.
Bjorn
^ permalink raw reply
* [PATCH v2] clkdev: Detect errors in clk_hw_register_clkdev() for mass registration
From: Geert Uytterhoeven @ 2016-09-21 13:12 UTC (permalink / raw)
To: linux-arm-kernel
Unlike clk_register_clkdev(), clk_hw_register_clkdev() doesn't check for
passed error objects from a previous registration call. Hence the caller
of clk_hw_register_*() had to check for errors before calling
clk_hw_register_clkdev*().
Make clk_hw_register_clkdev() more similar to clk_register_clkdev() by
adding this error check, removing the burden from callers that do mass
registration.
Fixes: e4f1b49bda6d6aa2 ("clkdev: Add clk_hw based registration APIs")
Fixes: 944b9a41e004534f ("clk: ls1x: Migrate to clk_hw based OF and registration APIs")
Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org>
---
v2:
- Correct wrong function references
s/clkdev_{,hw_}create/clk_{,hw_}register_clkdev/
Note that in the mean time more clk_hw conversions not checking for
errors have been posted, leading to crashes in error paths, so it would
be good to have this check in the core.
---
drivers/clk/clkdev.c | 8 ++++++++
1 file changed, 8 insertions(+)
diff --git a/drivers/clk/clkdev.c b/drivers/clk/clkdev.c
index 97ae60fa15849954..bb8a77a5985f8627 100644
--- a/drivers/clk/clkdev.c
+++ b/drivers/clk/clkdev.c
@@ -448,12 +448,20 @@ EXPORT_SYMBOL(clk_register_clkdev);
*
* con_id or dev_id may be NULL as a wildcard, just as in the rest of
* clkdev.
+ *
+ * To make things easier for mass registration, we detect error clk_hws
+ * from a previous clk_hw_register_*() call, and return the error code for
+ * those. This is to permit this function to be called immediately
+ * after clk_hw_register_*().
*/
int clk_hw_register_clkdev(struct clk_hw *hw, const char *con_id,
const char *dev_id)
{
struct clk_lookup *cl;
+ if (IS_ERR(hw))
+ return PTR_ERR(hw);
+
/*
* Since dev_id can be NULL, and NULL is handled specially, we must
* pass it as either a NULL format string, or with "%s".
--
1.9.1
^ permalink raw reply related
* ftrace function_graph causes system crash
From: Steven Rostedt @ 2016-09-21 13:45 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <0e38f79fdc1f4671943da74764c15050@SIWEX5A.sing.micron.com>
On Wed, 21 Sep 2016 07:50:58 +0000
"Bean Huo (beanhuo)" <beanhuo@micron.com> wrote:
>
> Hi, Steve
> Thanks very much! This is a very useful trace tool, I now know the problem function,
> It is gt_counter_read, if not trace this function, ftrace function_graph work well.
> Do you know now how to deeply debug and trace which line is wrong through Ftrace?
Hmm, maybe I should add this into the scripts directory. Yeah, I should
do that.
-- Steve
^ permalink raw reply
* [PATCH 2/3] i2c: bcm2835: Add support for combined write-read transfer
From: Noralf Trønnes @ 2016-09-21 13:45 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <DF457EB8-D1B8-4BA4-B79C-AF01AF7CAA3B@martin.sperl.org>
Den 20.09.2016 13:29, skrev kernel at martin.sperl.org:
>> On 20.09.2016, at 12:56, Noralf Tr?nnes <noralf@tronnes.org> wrote:
>>
>>
>> Den 20.09.2016 12:15, skrev Martin Sperl:
>>>
>>> On 20.09.2016 10:41, Noralf Tr?nnes wrote:
>>>> Den 20.09.2016 09:19, skrev Martin Sperl:
>>>>> Hi Noralf!
>>>>>
>>>>> On 19.09.2016 17:26, Noralf Tr?nnes wrote:
>>>>>> Some SMBus protocols use Repeated Start Condition to switch from write
>>>>>> mode to read mode. Devices like MMA8451 won't work without it.
>>>>>>
>>>>>> When downstream implemented support for this in i2c-bcm2708, it broke
>>>>>> support for some devices, so a module parameter was added and combined
>>>>>> transfer was disabled by default.
>>>>>> See https://github.com/raspberrypi/linux/issues/599
>>>>>> It doesn't seem to have been any investigation into what the problem
>>>>>> really was. Later there was added a timeout on the polling loop.
>>>>>>
>>>>>> One of the devices mentioned to partially stop working was DS1307.
>>>>>>
>>>>>> I have run thousands of transfers to a DS1307 (rtc), MMA8451 (accel)
>>>>>> and AT24C32 (eeprom) in parallel without problems.
>>>>>>
>>>>>> Signed-off-by: Noralf Tr?nnes <noralf@tronnes.org>
>>>>>> ---
>>>>>> drivers/i2c/busses/i2c-bcm2835.c | 107
>>>>>> +++++++++++++++++++++++++++++++++++----
>>>>>> 1 file changed, 98 insertions(+), 9 deletions(-)
>>>>> ...
>>>>>> @@ -209,8 +289,17 @@ static int bcm2835_i2c_xfer(struct i2c_adapter
>>>>>> *adap, struct i2c_msg msgs[],
>>>>>> int i;
>>>>>> int ret = 0;
>>>>>> + /* Combined write-read to the same address (smbus) */
>>>>>> + if (num == 2 && (msgs[0].addr == msgs[1].addr) &&
>>>>>> + !(msgs[0].flags & I2C_M_RD) && (msgs[1].flags & I2C_M_RD) &&
>>>>>> + (msgs[0].len <= 16)) {
>>>>>> + ret = bcm2835_i2c_xfer_msg(i2c_dev, &msgs[0], &msgs[1]);
>>>>>> +
>>>>>> + return ret ? ret : 2;
>>>>>> + }
>>>>>> +
>>>>>> for (i = 0; i < num; i++) {
>>>>>> - ret = bcm2835_i2c_xfer_msg(i2c_dev, &msgs[i]);
>>>>>> + ret = bcm2835_i2c_xfer_msg(i2c_dev, &msgs[i], NULL);
>>>>>> if (ret)
>>>>>> break;
>>>>>> }
>>>>> This does not seem to implement the i2c_msg api correctly.
>>>>>
>>>>> As per comments in include/uapi/linux/i2c.h on line 58 only the last
>>>>> message
>>>>> in a group should - by default - send a STOP.
>>>>>
>>>> Apparently it's a known problem that the i2c controller doesn't support
>>>> Repeated Start. It will always issue a Stop when it has transferred DLEN
>>>> bytes.
>>>> Refs:
>>>> http://www.circuitwizard.de/raspi-i2c-fix/raspi-i2c-fix.html
>>>> http://raspberrypi.stackexchange.com/questions/31728/has-anyone-successfully-used-i2c-repeated-starts-on-the-pi2-my-scope-says-they
>>>>
>>>>
>>>> UNLESS: a Start Transfer (ST) is issued after Transfer Active (TA) is set
>>>> and before DONE is set (or the last byte is shifted, I don't know excatly).
>>>> Refs:
>>>> https://github.com/raspberrypi/linux/issues/254#issuecomment-15254134
>>>> https://www.raspberrypi.org/forums/viewtopic.php?p=807834&sid=2b612c7209f2175bf1a266359c72ae6c#p807834
>>>>
>>>>
>>>> I found this answer/report by joan that the downstream combined support
>>>> isn't reliable:
>>>> http://raspberrypi.stackexchange.com/questions/31728/has-anyone-successfully-used-i2c-repeated-starts-on-the-pi2-my-scope-says-they
>>>>
>>>>
>>>> My implementation differs from downstream in that I use local_irq_save()
>>>> to protect the polling loop. But that only protects from missing the TA
>>>> (downstream can miss the TA and issue a Stop).
>>>>
>>>> So currently in mainline we have a driver that says it support the standard
>>>> (I2C_FUNC_I2C), but it really only supports one message transfers since it
>>>> can't do ReStart.
>>>>
>>>> What I have done in this patch is to support ReStart for transfers with
>>>> 2 messages: first write, then read. But maybe a better solution is to just
>>>> leave this alone if it is flaky and use bitbanging instead. I don't know.
>>> I have not said that the approach you have taken is wrong or bad.
>>>
>> I didn't take it as such, I'm just not sure what's the best approach here,
>> so I added and looked up some more information
>>
>>> I was only telling you that the portion inside the bcm2835_i2c_xfer:
>>> + /* Combined write-read to the same address (smbus) */
>>> + if (num == 2 && (msgs[0].addr == msgs[1].addr) &&
>>> + !(msgs[0].flags & I2C_M_RD) && (msgs[1].flags & I2C_M_RD) &&
>>> + (msgs[0].len <= 16)) {
>>> + ret = bcm2835_i2c_xfer_msg(i2c_dev, &msgs[0], &msgs[1]);
>>> +
>>> + return ret ? ret : 2;
>>> + }
>>> is very specific and maybe could be done in a "generic" manner
>>> supporting more cases.
>>>
>> It has to be specific when it comes to number of messages. We can only
>> support ReStart after the first message unless we use polling for the
>> whole transfer. And in that case we can't disable interrupts for such
>> a long period and we will end up sometimes loosing Transfer Active,
>> resulting in Stop Condition between the messages.
>> So we can only do transfers with 2 messages if we want Restart.
>>
>> It is possible to support more than 16 bytes for the first message,
>> filling the FIFO after polling TA, but I'm not sure that is common.
>> Mostly it's 1 or 2 bytes to set a register.
>> The write-read restriction isn't absolutely necessary either, but it's the
>> most common case I think. So it was about reusing bcm2835_i2c_xfer_msg().
>> A less restrictive approach would require a dedicated function I think.
>>
>>> At least add a dev_warn_once for all num > 1 cases not handled by the
>>> code above.
>>>
>>> This gives people an opportunity to detect such a situation if they
>>> find something is not working as expected.
>>>
>> I agree.
>>
>> After reading joan's report I wonder if it would be best to add a module
>> parameter like downstream has, so it can be disabled. What do you think?
>>
> I guess let us start simple:
> * get warning in place about always issuing a stop for num > 1
> - instead we may just want to set max_num_msgs = 1 in quirks.
> * apply your patch for the write (<=16) then read case.
> - maybe by setting quirks I2C_AQ_COMB_WRITE_THEN_READ
> plus max_comb_1st_msg_len = 16 and max_num_msgs = 2
>
> If this becomes too restrictive for some specific HW, then someone
> may want to add the missing features.
>
> As for the module parameters: no idea if this is acceptable
> or sensible.
>
> But that?s just my 2c...
It suddenly struct me that I had seen the TA bit set when I debugged the
interrupt function. And it turns out that if I don't prefill the FIFO,
then I can use the TXW interrupt to know when the transfer is active,
no need for polling. It looks promising so far, need to run my testcases
to be sure.
Thanks,
Noralf.
^ permalink raw reply
* [PATCH V6 3/5] PCI: thunder-pem: Allow to probe PEM-specific register range for ACPI case
From: Lorenzo Pieralisi @ 2016-09-21 14:05 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20160920191744.GA4941@localhost>
On Tue, Sep 20, 2016 at 02:17:44PM -0500, Bjorn Helgaas wrote:
> On Tue, Sep 20, 2016 at 04:09:25PM +0100, Ard Biesheuvel wrote:
[...]
> > None of these platforms can be fixed entirely in software, and given
> > that we will not be adding quirks for new broken hardware, we should
> > ask ourselves whether having two versions of a quirk, i.e., one for
> > broken hardware + currently shipping firmware, and one for the same
> > broken hardware with fixed firmware is really an improvement over what
> > has been proposed here.
>
> We're talking about two completely different types of quirks:
>
> 1) MCFG quirks to use memory-mapped config space that doesn't quite
> conform to the ECAM model in the PCIe spec, and
>
> 2) Some yet-to-be-determined method to describe address space
> consumed by a bridge.
>
> The first two patches of this series are a nice implementation for 1).
> The third patch (ThunderX-specific) is one possibility for 2), but I
> don't like it because there's no way for generic software like the
> ACPI core to discover these resources.
Ok, so basically this means that to implement (2) we need to assign
some sort of _HID to these quirky PCI bridges (so that we know what
device they represent and we can retrieve their _CRS). I take from
this discussion that the goal is to make sure that all non-config
resources have to be declared through _CRS device objects, which is
fine but that requires a FW update (unless we can fabricate ACPI
devices and corresponding _CRS in the kernel whenever we match a
given MCFG table signature).
We discussed this already and I think we should make a decision:
http://lists.infradead.org/pipermail/linux-arm-kernel/2016-March/414722.html
> > > I'd like to step back and come up with some understanding of how
> > > non-broken firmware *should* deal with this issue. Then, if we *do*
> > > work around this particular broken firmware in the kernel, it would be
> > > nice to do it in a way that fits in with that understanding.
> > >
> > > For example, if a companion ACPI device is the preferred solution, an
> > > ACPI quirk could fabricate a device with the required resources. That
> > > would address the problem closer to the source and make it more likely
> > > that the rest of the system will work correctly: /proc/iomem could
> > > make sense, things that look at _CRS generically would work (e.g,
> > > /sys/, an admittedly hypothetical "lsacpi", etc.)
> > >
> > > Hard-coding stuff in drivers is a point solution that doesn't provide
> > > any guidance for future platforms and makes it likely that the hack
> > > will get copied into even more drivers.
> > >
> >
> > OK, I see. But the guidance for future platforms should be 'do not
> > rely on quirks', and what I am arguing here is that the more we polish
> > up this code and make it clean and reusable, the more likely it is
> > that will end up getting abused by new broken hardware that we set out
> > to reject entirely in the first place.
> >
> > So of course, if the quirk involves claiming resources, let's make
> > sure that this occurs in the cleanest and most compliant way possible.
> > But any factoring/reuse concerns other than for the current crop of
> > broken hardware should be avoided imo.
>
> If future hardware is completely ECAM-compliant and we don't need any
> more MCFG quirks, that would be great.
Yes.
> But we'll still need to describe that memory-mapped config space
> somewhere. If that's done with PNP0C02 or similar devices (as is done
> on my x86 laptop), we'd be all set.
I am not sure I understand what you mean here. Are you referring
to MCFG regions reported as PNP0c02 resources through its _CRS ?
IIUC PNP0C02 is a reservation mechanism, but it does not help us
associate its _CRS to a specific PCI host bridge instance, right ?
> If we need to work around firmware in the field that doesn't do that,
> one possibility is a PNP quirk along the lines of
> quirk_amd_mmconfig_area().
You mean matching PNP0C01/PNP0c02 and create a resource (that has to
hardcoded in a static array in the kernel anyway, there is no way to
retrieve it otherwise) in the corresponding PNP quirk handler ?
And it is not a given we can match against PNP0c01/PNP0c02.
So it looks like the only solution is allocating an _HID for each
host bridge that is not ECAM compliant to add resources to its _CRS
(unless the MCFG quirk does not need any additional data/resource,
eg "use different set of PCI accessorsi 32-bit vs byte-access").
For FW that is immutable I really do not see what we can do apart
from hardcoding the non-config resources (consumed by a bridge),
somehow.
Thanks,
Lorenzo
^ permalink raw reply
* [PATCH V6 0/5] ECAM quirks handling for ARM64 platforms
From: Sinan Kaya @ 2016-09-21 14:07 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20160921131107.GB10804@localhost>
On 9/21/2016 9:11 AM, Bjorn Helgaas wrote:
> On Tue, Sep 20, 2016 at 09:15:14PM -0400, cov at codeaurora.org wrote:
>> Hi Bjorn, Thomasz,
>>
>>
>> Did you delete this because there were no current users, because you'd
>> prefer users just use "-1", or for some other reason?
>
> I removed it because there were no users of it and, more importantly,
> the code doesn't implement support for it.
Is it possible to queue up Cov's patch as part of this effort once he
rebases and sends an updated version? Cov will have to implement something
else now.
--
Sinan Kaya
Qualcomm Datacenter Technologies, Inc. as an affiliate of Qualcomm Technologies, Inc.
Qualcomm Technologies, Inc. is a member of the Code Aurora Forum, a Linux Foundation Collaborative Project.
^ permalink raw reply
* [PATCH V6 3/5] PCI: thunder-pem: Allow to probe PEM-specific register range for ACPI case
From: Gabriele Paoloni @ 2016-09-21 14:10 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20160920191744.GA4941@localhost>
Hi Bjorn
[...]
>
> If future hardware is completely ECAM-compliant and we don't need any
> more MCFG quirks, that would be great.
>
> But we'll still need to describe that memory-mapped config space
> somewhere. If that's done with PNP0C02 or similar devices (as is done
> on my x86 laptop), we'd be all set.
>
> If we need to work around firmware in the field that doesn't do that,
> one possibility is a PNP quirk along the lines of
> quirk_amd_mmconfig_area().
So, if my understanding is correct, for platforms that have not been
shipped yet you propose to use PNP0C02 in the ACPI table in order to
declare a motherboard reserved resource whereas for shipped platforms
you propose to have a quirk along pnp_fixups in order to track the
resource usage even if values are hardcoded...correct?
Before Tomasz came up with this patchset we had a call between the vendors
involved in this PCI quirks saga and other guys from Linaro and ARM.
Lorenzo summarized the outcome as in the following link
http://lkml.iu.edu/hypermail/linux/kernel/1606.2/03344.html
Since this quirks mechanism has been discussed for quite a long time now
IMHO it would be good to have a last call including also you (Bjorn) so
that we can all agree on what to do and we avoid changing our drivers again
and again...
What do you think?
Thanks
Gab
>
> Bjorn
^ 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