* [PATCH] DTS: MCCMON6: IMX: Provide support for iMX6Q based Liebherr mccmon6 board
From: Lukasz Majewski @ 2017-01-02 14:44 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <610d3784-ee2e-c213-2a8c-6db6d7af578b@mentor.com>
Hi Vladimir,
Thank you for review. Comments without my remarks have been applied
already.
> Hello Lukasz,
>
> On 12/27/2016 01:19 AM, Lukasz Majewski wrote:
> > Signed-off-by: Lukasz Majewski <l.majewski@majess.pl>
>
> please add a commit message with a short description of the change.
>
> Also change subject line to "ARM: dts: imx6q: Add mccmon6 board
> support".
>
> > ---
> > MCCMON6 board support depends on following patches:
> >
> > 1. "video: backlight: pwm_bl: Initialize fb_bl_on[x] and use_count
> > during pwm_backlight_probe()"
> > http://patchwork.ozlabs.org/patch/708844/
> >
> > 2. "pwm: imx: Provide atomic operation for IMX PWM driver"
> > http://patchwork.ozlabs.org/patch/708847/ -
> > http://patchwork.ozlabs.org/patch/708843/
> >
> >
> > ---
> > arch/arm/boot/dts/Makefile | 1 +
> > arch/arm/boot/dts/imx6q-mccmon6.dts | 469
> > ++++++++++++++++++++++++++++++++++++ 2 files changed, 470
> > insertions(+) create mode 100644 arch/arm/boot/dts/imx6q-mccmon6.dts
> >
> > diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
> > index c558ba7..7ce1080 100644
> > --- a/arch/arm/boot/dts/Makefile
> > +++ b/arch/arm/boot/dts/Makefile
> > @@ -382,6 +382,7 @@ dtb-$(CONFIG_SOC_IMX6Q) += \
> > imx6q-h100.dtb \
> > imx6q-hummingboard.dtb \
> > imx6q-icore-rqs.dtb \
> > + imx6q-mccmon6.dtb \
> > imx6q-marsboard.dtb \
>
> Please add a new line preserving alphabetical order.
>
> > imx6q-nitrogen6x.dtb \
> > imx6q-nitrogen6_max.dtb \
> > diff --git a/arch/arm/boot/dts/imx6q-mccmon6.dts
> > b/arch/arm/boot/dts/imx6q-mccmon6.dts new file mode 100644
> > index 0000000..7445d01
> > --- /dev/null
> > +++ b/arch/arm/boot/dts/imx6q-mccmon6.dts
> > @@ -0,0 +1,469 @@
> > +/*
> > + * Copyright 2016
>
> Copyright holder is missing.
>
> > + *
> > + * Author: Lukasz Majewski <l.majewski@majess.pl>
> > + *
> > + * This program is free software; you can redistribute it and/or
> > modify
> > + * it under the terms of the GNU General Public License version 2
> > as
> > + * published by the Free Software Foundation.
> > + *
> > + */
>
> Please add an empty line here to improve readability.
>
> > +/dts-v1/;
>
> Please add an empty line here to improve readability.
>
> > +#include "imx6q.dtsi"
> > +
> > +#include <dt-bindings/gpio/gpio.h>
> > +#include <dt-bindings/pwm/pwm.h>
> > +
> > +/ {
> > + model = "Monitor6 i.MX6 Quad Board";
>
> Missing hardware vendor name.
>
> > + compatible = "mccmon6", "fsl,imx6q";
>
> Missing hardware vendor prefix before "mccmon6".
"lwn,mccmon6" ?
>
> > +
> > + memory {
> > + reg = <0x10000000 0x80000000>;
> > + };
> > +
> > + ethernet0 {
> > + status = "okay";
> > + };
>
> It looks like a useless device node, you have a description of &fec
> already.
>
> > +
> > + backlight_lvds: backlight {
> > + compatible = "pwm-backlight";
> > + pinctrl-names = "default";
> > + pinctrl-0 = <&pinctrl_display>;
>
> I would recommend to rename "pinctrl_display" to "pinctrl_backlight".
>
> > + pwms = <&pwm2 0 5000000 PWM_POLARITY_INVERTED>;
>
> This should work when extension to the i.MX PWM driver is merged.
Yes. The PWM -> apply is an ongoing work. But without the PMW patch the
board is also fully operational (with reversed PWM :-) )
>
> > + brightness-levels = < 0 1 2 3 4 5 6
> > 7 8 9
> > + 10 11 12 13 14 15 16
> > 17 18 19
> > + 20 21 22 23 24 25 26
> > 27 28 29
> > + 30 31 32 33 34 35 36
> > 37 38 39
> > + 40 41 42 43 44 45 46
> > 47 48 49
> > + 50 51 52 53 54 55 56
> > 57 58 59
> > + 60 61 62 63 64 65 66
> > 67 68 69
> > + 70 71 72 73 74 75 76
> > 77 78 79
> > + 80 81 82 83 84 85 86
> > 87 88 89
> > + 90 91 92 93 94 95 96
> > 97 98 99
> > + 100 101 102 103 104 105 106
> > 107 108 109
> > + 110 111 112 113 114 115 116
> > 117 118 119
> > + 120 121 122 123 124 125 126
> > 127 128 129
> > + 130 131 132 133 134 135 136
> > 137 138 139
> > + 140 141 142 143 144 145 146
> > 147 148 149
> > + 150 151 152 153 154 155 156
> > 157 158 159
> > + 160 161 162 163 164 165 166
> > 167 168 169
> > + 170 171 172 173 174 175 176
> > 177 178 179
> > + 180 181 182 183 184 185 186
> > 187 188 189
> > + 190 191 192 193 194 195 196
> > 197 198 199
> > + 200 201 202 203 204 205 206
> > 207 208 209
> > + 210 211 212 213 214 215 216
> > 217 218 219
> > + 220 221 222 223 224 225 226
> > 227 228 229
> > + 230 231 232 233 234 235 236
> > 237 238 239
> > + 240 241 242 243 244 245 246
> > 247 248 249
> > + 250 251 252 253 254 255>;
>
> I'm not sure that actually need such a long list of brightness levels.
Such brightness-level property is so verbose on purpose - in this board
we need fine brightness adjustment (harsh environment operation).
>
> > + default-brightness-level = <50>;
> > + enable-gpios = <&gpio1 2 GPIO_ACTIVE_LOW>;
> > + };
> > +
> > + reg_lvds: regulator-lvds {
> > + compatible = "regulator-fixed";
> > + regulator-name = "lvds_ppen";
> > + regulator-min-microvolt = <3300000>;
> > + regulator-max-microvolt = <3300000>;
> > + regulator-boot-on;
> > + gpio = <&gpio1 19 GPIO_ACTIVE_HIGH>;
> > + enable-active-high;
> > + };
> > +
> > + panel-lvds0 {
> > + compatible = "innolux,g121x1-l03";
> > + backlight = <&backlight_lvds>;
> > + power-supply = <®_lvds>;
> > +
> > + port {
> > + panel_in_lvds0: endpoint {
> > + remote-endpoint = <&lvds0_out>;
> > + };
> > + };
> > + };
> > +};
> > +
> > +&i2c1 {
> > + clock-frequency = <100000>;
> > + pinctrl-names = "default";
> > + pinctrl-0 = <&pinctrl_i2c1>;
> > + status = "okay";
> > +};
> > +
> > +&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>;
> > + };
> > +
> > + sw2_reg: sw2 {
> > + regulator-min-microvolt = <800000>;
> > + regulator-max-microvolt =
> > <3950000>;
> > + regulator-boot-on;
> > + regulator-always-on;
> > + };
> > +
> > + sw3a_reg: sw3a {
> > + regulator-min-microvolt = <400000>;
> > + regulator-max-microvolt =
> > <1975000>;
> > + regulator-boot-on;
> > + regulator-always-on;
> > + };
> > +
> > + sw3b_reg: sw3b {
> > + regulator-min-microvolt = <400000>;
> > + regulator-max-microvolt =
> > <1975000>;
> > + regulator-boot-on;
> > + regulator-always-on;
> > + };
> > +
> > + sw4_reg: sw4 {
> > + regulator-min-microvolt = <800000>;
> > + regulator-max-microvolt =
> > <3300000>;
> > + };
> > +
> > + swbst_reg: swbst {
> > + regulator-min-microvolt =
> > <5000000>;
> > + regulator-max-microvolt =
> > <5150000>;
> > + };
> > +
> > + 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_reg: vgen1 {
> > + regulator-min-microvolt = <800000>;
> > + regulator-max-microvolt =
> > <1550000>;
> > + };
> > +
> > + vgen2_reg: vgen2 {
> > + regulator-min-microvolt = <800000>;
> > + regulator-max-microvolt =
> > <1550000>;
> > + };
> > +
> > + vgen3_reg: vgen3 {
> > + regulator-min-microvolt =
> > <1800000>;
> > + regulator-max-microvolt =
> > <3300000>;
> > + };
> > +
> > + vgen4_reg: vgen4 {
> > + regulator-min-microvolt =
> > <1800000>;
> > + regulator-max-microvolt =
> > <3300000>;
> > + regulator-always-on;
> > + };
> > +
> > + vgen5_reg: vgen5 {
> > + regulator-min-microvolt =
> > <1800000>;
> > + regulator-max-microvolt =
> > <3300000>;
> > + regulator-always-on;
> > + };
> > +
> > + vgen6_reg: vgen6 {
> > + regulator-min-microvolt =
> > <1800000>;
> > + regulator-max-microvolt =
> > <3300000>;
> > + regulator-always-on;
> > + };
> > + };
> > + };
> > +};
> > +
> > +&iomuxc {
> > + pinctrl-names = "default";
> > +
> > + imx6q-mccmon6 {
> > +
>
> Please drop the empty line above.
>
> > + pinctrl_enet: enetgrp {
> > + fsl,pins = <
> > +
> > MX6QDL_PAD_ENET_MDIO__ENET_MDIO 0x1b0b0
> > +
> > MX6QDL_PAD_ENET_MDC__ENET_MDC 0x1b0b0
> > +
> > MX6QDL_PAD_RGMII_TXC__RGMII_TXC 0x1b0b0
> > +
> > MX6QDL_PAD_RGMII_TD0__RGMII_TD0 0x1b0b0
> > +
> > MX6QDL_PAD_RGMII_TD1__RGMII_TD1 0x1b0b0
> > +
> > MX6QDL_PAD_RGMII_TD2__RGMII_TD2 0x1b0b0
> > +
> > MX6QDL_PAD_RGMII_TD3__RGMII_TD3 0x1b0b0
> > +
> > MX6QDL_PAD_RGMII_TX_CTL__RGMII_TX_CTL 0x1b0b0
> > +
> > MX6QDL_PAD_ENET_REF_CLK__ENET_TX_CLK 0x1b0b0
> > +
> > MX6QDL_PAD_RGMII_RXC__RGMII_RXC 0x1b0b0
> > +
> > MX6QDL_PAD_RGMII_RD0__RGMII_RD0 0x1b0b0
> > +
> > MX6QDL_PAD_RGMII_RD1__RGMII_RD1 0x1b0b0
> > +
> > MX6QDL_PAD_RGMII_RD2__RGMII_RD2 0x1b0b0
> > +
> > MX6QDL_PAD_RGMII_RD3__RGMII_RD3 0x1b0b0
> > +
> > MX6QDL_PAD_RGMII_RX_CTL__RGMII_RX_CTL 0x1b0b0
> > + MX6QDL_PAD_GPIO_16__ENET_REF_CLK
> > 0x4001b0a8
> > +
> > MX6QDL_PAD_GPIO_6__ENET_IRQ 0x000b1
> > + >;
> > + };
> > +
> > + pinctrl_i2c1: i2c1grp {
> > + fsl,pins = <
> > +
> > MX6QDL_PAD_CSI0_DAT9__I2C1_SCL 0x4001b8b1
> > +
> > MX6QDL_PAD_CSI0_DAT8__I2C1_SDA 0x4001b8b1
> > + >;
> > + };
> > +
> > + pinctrl_i2c2: i2c2grp {
> > + fsl,pins = <
> > +
> > MX6QDL_PAD_KEY_COL3__I2C2_SCL 0x4001b8b1
> > +
> > MX6QDL_PAD_KEY_ROW3__I2C2_SDA 0x4001b8b1
> > + >;
> > + };
> > +
> > + pinctrl_uart1: uart1grp {
> > + fsl,pins = <
> > +
> > MX6QDL_PAD_CSI0_DAT10__UART1_TX_DATA 0x1b0b1
> > +
> > MX6QDL_PAD_CSI0_DAT11__UART1_RX_DATA 0x1b0b1
> > + >;
> > + };
> > +
> > + pinctrl_usdhc2: usdhc2grp {
> > + fsl,pins = <
> > +
> > MX6QDL_PAD_SD2_CMD__SD2_CMD 0x17059
> > +
> > MX6QDL_PAD_SD2_CLK__SD2_CLK 0x10059
> > +
> > MX6QDL_PAD_SD2_DAT0__SD2_DATA0 0x17059
> > +
> > MX6QDL_PAD_SD2_DAT1__SD2_DATA1 0x17059
> > +
> > MX6QDL_PAD_SD2_DAT2__SD2_DATA2 0x17059
> > +
> > MX6QDL_PAD_SD2_DAT3__SD2_DATA3 0x17059
> > + >;
> > + };
> > +
> > + 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
> > +
> > MX6QDL_PAD_SD3_RST__SD3_RESET 0x17059
> > + >;
> > + };
> > +
> > + pinctrl_weim_cs0: weimcs0grp {
> > + fsl,pins = <
> > +
> > MX6QDL_PAD_EIM_CS0__EIM_CS0_B 0xb0b1
> > + >;
> > + };
> > +
> > + pinctrl_weim_nor: weimnorgrp {
> > + fsl,pins = <
> > +
> > MX6QDL_PAD_EIM_OE__EIM_OE_B 0xb0b1
> > +
> > MX6QDL_PAD_EIM_RW__EIM_RW 0xb0b1
> > +
> > MX6QDL_PAD_EIM_WAIT__EIM_WAIT_B 0xb060
> > +
> > MX6QDL_PAD_EIM_D16__EIM_DATA16 0x1b0b0
> > +
> > MX6QDL_PAD_EIM_D17__EIM_DATA17 0x1b0b0
> > +
> > MX6QDL_PAD_EIM_D18__EIM_DATA18 0x1b0b0
> > +
> > MX6QDL_PAD_EIM_D19__EIM_DATA19 0x1b0b0
> > +
> > MX6QDL_PAD_EIM_D20__EIM_DATA20 0x1b0b0
> > +
> > MX6QDL_PAD_EIM_D21__EIM_DATA21 0x1b0b0
> > +
> > MX6QDL_PAD_EIM_D22__EIM_DATA22 0x1b0b0
> > +
> > MX6QDL_PAD_EIM_D23__EIM_DATA23 0x1b0b0
> > +
> > MX6QDL_PAD_EIM_D24__EIM_DATA24 0x1b0b0
> > +
> > MX6QDL_PAD_EIM_D25__EIM_DATA25 0x1b0b0
> > +
> > MX6QDL_PAD_EIM_D26__EIM_DATA26 0x1b0b0
> > +
> > MX6QDL_PAD_EIM_D27__EIM_DATA27 0x1b0b0
> > +
> > MX6QDL_PAD_EIM_D28__EIM_DATA28 0x1b0b0
> > +
> > MX6QDL_PAD_EIM_D29__EIM_DATA29 0x1b0b0
> > +
> > MX6QDL_PAD_EIM_D30__EIM_DATA30 0x1b0b0
> > +
> > MX6QDL_PAD_EIM_D31__EIM_DATA31 0x1b0b0
> > +
> > MX6QDL_PAD_EIM_A23__EIM_ADDR23 0xb0b1
> > +
> > MX6QDL_PAD_EIM_A22__EIM_ADDR22 0xb0b1
> > +
> > MX6QDL_PAD_EIM_A21__EIM_ADDR21 0xb0b1
> > +v4.9-release-devel-fast
> > MX6QDL_PAD_EIM_A20__EIM_ADDR20 0xb0b1
> > +
> > MX6QDL_PAD_EIM_A19__EIM_ADDR19 0xb0b1
> > +
> > MX6QDL_PAD_EIM_A18__EIM_ADDR18 0xb0b1
> > +
> > MX6QDL_PAD_EIM_A17__EIM_ADDR17 0xb0b1
> > +
> > MX6QDL_PAD_EIM_A16__EIM_ADDR16 0xb0b1
> > +
> > 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_ecspi3: ecspi3grp {
> > + fsl,pins = <
> > +
> > MX6QDL_PAD_DISP0_DAT2__ECSPI3_MISO 0x100b1
> > +
> > MX6QDL_PAD_DISP0_DAT1__ECSPI3_MOSI 0x100b1
> > +
> > MX6QDL_PAD_DISP0_DAT0__ECSPI3_SCLK 0x100b1
> > + >;
> > + };
> > +
> > + pinctrl_ecspi3_cs: ecspi3cs {
> > + fsl,pins = <
> > + MX6QDL_PAD_DISP0_DAT3__GPIO4_IO24
> > 0x80000000
> > + >;
> > + };
> > + pinctrl_ecspi3_flwp: ecspi3flwp {
> > + fsl,pins = <
> > + MX6QDL_PAD_DISP0_DAT6__GPIO4_IO27
> > 0x80000000
> > + >;
> > + };
> > +
> > + pinctrl_uart4: uart4grp {
> > + fsl,pins = <
> > +
> > MX6QDL_PAD_KEY_COL0__UART4_TX_DATA 0x1b0b1
> > +
> > MX6QDL_PAD_KEY_ROW0__UART4_RX_DATA 0x1b0b1
> > +
> > MX6QDL_PAD_CSI0_DAT16__UART4_RTS_B 0x1b0b1
> > +
> > MX6QDL_PAD_CSI0_DAT17__UART4_CTS_B 0x1b0b1
> > + >;
> > + };
> > +
> > + pinctrl_display: dispgrp {
> > + fsl,pins = <
> > + /* BLEN_OUT */
> > + MX6QDL_PAD_GPIO_2__GPIO1_IO02
> > 0x1b0b0
> > + /* LVDS_PPEN_OUT */
> > + MX6QDL_PAD_SD1_DAT2__GPIO1_IO19
> > 0x1b0b0
>
> This GPIO should be moved to a pinctrl group of regulator-lvds device
> node.
You mean to provide separate:
pinctrl_reg_lvds: req_lvds_grp {
fsl,pins = <
/* LVDS_PPEN_OUT */
MX6QDL_PAD_SD1_DAT2__GPIO1_IO19
>;
and then
reg_lvds: regulator-lvds {
compatible = "regulator-fixed";
regulator-name = "lvds_ppen";
regulator-min-microvolt = <3300000>;
regulator-max-microvolt = <3300000>;
regulator-boot-on;
pinctrl-names = "default";
pinctrl-0 = <&pinctrl_reg_lvds>;
gpio = <&gpio1 19 GPIO_ACTIVE_HIGH>;
enable-active-high;
};
>
> > + >;
> > + };
> > +
> > + pinctrl_pwm2: pwm2grp {
> > + fsl,pins = <
> > +
> > MX6QDL_PAD_GPIO_1__PWM2_OUT 0x1b0b1
> > + >;
> > + };
>
> Please sort out all pinctrl_* nodes alphabetically.
>
> > + };
> > +};
> > +
> > +&fec {
> > + pinctrl-names = "default";
> > + pinctrl-0 = <&pinctrl_enet>;
> > + phy-mode = "rgmii";
> > + phy-reset-gpios = <&gpio1 27 0>;
>
> GPIO1_27 has no pad configuration in pinctrl_enet.
>
> > + interrupts-extended = <&gpio1 6 IRQ_TYPE_LEVEL_HIGH>,
> > + <&intc 0 119 IRQ_TYPE_LEVEL_HIGH>;
> > + status = "okay";
> > +};
> > +
> > +&uart1 {
> > + pinctrl-names = "default";
> > + pinctrl-0 = <&pinctrl_uart1>;
>
> Should you add "uart-has-rtscts" property?
This is a simple "console" uart without rts/cts, so this property is
not needed.
>
> > + status = "okay";
> > +};
> > +
> > +&usdhc2 {
> > + pinctrl-names = "default";
> > + pinctrl-0 = <&pinctrl_usdhc2>;
> > + cd-gpios = <&gpio1 4 GPIO_ACTIVE_LOW>;
>
> bus-width = <4>;
>
> You should consider to add the GPIO1_4 into pinctrl_usdhc2 group.
Added.
>
> > + status = "okay";
> > +};
> > +
> > +&usdhc3 {
> > + pinctrl-names = "default";
> > + pinctrl-0 = <&pinctrl_usdhc3>;
> > + bus-width = <8>;
> > + status = "okay";
>
> No "cd-gpios" property, should you add "non-removable" property then?
Yes, this is the eMMC memory.
>
> > +};
> > +
> > +&weim {
> > + pinctrl-names = "default";
> > + pinctrl-0 = <&pinctrl_weim_nor &pinctrl_weim_cs0>;
> > + #address-cells = <2>;
> > + #size-cells = <1>;
> > + ranges = <0 0 0x08000000 0x08000000>;
> > + status = "okay";
> > +
> > + nor at 0,0 {
> > + compatible = "cfi-flash";
> > + reg = <0 0 0x02000000>;
> > + #address-cells = <1>;
> > + #size-cells = <1>;
> > + bank-width = <2>;
> > + use-advanced-sector-protection;
> > + fsl,weim-cs-timing = <0x00620081 0x00000001
> > 0x1c022000
> > + 0x0000c000 0x1404a38e 0x00000000>;
> > + };
> > +};
> > +
> > +&ecspi3 {
> > + fsl,spi-num-chipselects = <1>;
>
> This property is obsoleted, please remove it.
>
> > + cs-gpios = <&gpio4 24 0>;
> > + pinctrl-names = "default";
> > + pinctrl-0 = <&pinctrl_ecspi3 &pinctrl_ecspi3_cs
> > &pinctrl_ecspi3_flwp>;
> > + status = "okay";
> > +
> > + flash: s25sl032p at 0 {
> > + #address-cells = <1>;
> > + #size-cells = <1>;
> > + compatible = "spansion,s25sl032p", "jedec,spi-nor";
> > + spi-max-frequency = <40000000>;
> > + reg = <0>;
> > + };
> > +};
> > +
> > +&uart4 {
> > + pinctrl-names = "default";
> > + pinctrl-0 = <&pinctrl_uart4>;
> > + status = "okay";
>
> Should you add "uart-has-rtscts" property?
Yes, this uart supports rts/cts flow controll
>
> > +};
> > +
> > +&ldb {
> > + status = "okay";
> > +
> > + lvds0: lvds-channel at 0 {
> > + fsl,data-mapping = "spwg";
> > + fsl,data-width = <24>;
> > + status = "okay";
> > +
> > + port at 4 {
> > + reg = <4>;
> > +
> > + lvds0_out: endpoint {
> > + remote-endpoint =
> > <&panel_in_lvds0>;
> > + };
> > + };
> > + };
> > +};
> > +
> > +&pwm2 {
> > + #pwm-cells = <3>;
> > + pinctrl-names = "default";
> > + pinctrl-0 = <&pinctrl_pwm2>;
> > + status = "okay";
> > +};
> >
>
> Please sort out all device nodes but &iomuxc alphabetically:
>
> * iomuxc
> * ecspi3
> * fec
> * i2c1
> * i2c2
> * ldb
> * pwm2
> * uart1
> * uart4
> * usdhc2
> * usdhc3
> * weim
Ok.
>
> --
> With best wishes,
> Vladimir
Best regards,
?ukasz Majewski
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 181 bytes
Desc: OpenPGP digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20170102/096b34d3/attachment-0001.sig>
^ permalink raw reply
* [PATCH 15/20] ARM/hw_breakpoint: Convert to hotplug state machine
From: Linus Walleij @ 2017-01-02 14:34 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CACRpkdZE+h0+3EizLCMUr-e-4pv4w9iAatSqL8k0Ovd2iUaS8Q@mail.gmail.com>
On Mon, Jan 2, 2017 at 3:15 PM, Linus Walleij <linus.walleij@linaro.org> wrote:
> Something hits a brick wall when initializing the hardware breakpoints.
Should be noted that since I'm not using the breakpoints, the dirtyfix is to put
return 0;
in the first line of arch_hw_breakpoint_init() in
arch/arm/kernel/hw_breakpoint.c
I suspect that is not an accepable solution ...
It hangs at PC is at write_wb_reg+0x20c/0x330
Which is c03101dc, and looks like this in objdump -d:
c031020c: ee001eba mcr 14, 0, r1, cr0, cr10, {5}
c0310210: eaffffb3 b c03100e4 <write_wb_reg+0x114>
c0310214: ee001eb9 mcr 14, 0, r1, cr0, cr9, {5}
c0310218: eaffffb1 b c03100e4 <write_wb_reg+0x114>
c031021c: ee001eb8 mcr 14, 0, r1, cr0, cr8, {5}
c0310220: eaffffaf b c03100e4 <write_wb_reg+0x114>
c0310224: ee001eb7 mcr 14, 0, r1, cr0, cr7, {5}
c0310228: eaffffad b c03100e4 <write_wb_reg+0x114>
c031022c: ee001eb6 mcr 14, 0, r1, cr0, cr6, {5}
c0310230: eaffffab b c03100e4 <write_wb_reg+0x114>
c0310234: ee001eb5 mcr 14, 0, r1, cr0, cr5, {5}
c0310238: eaffffa9 b c03100e4 <write_wb_reg+0x114>
No idea if this helps.
Yours,
Linus Walleij
^ permalink raw reply
* [PATCH 0/4] video: ARM CLCD: add support of an optional GPIO to enable panel
From: Russell King - ARM Linux @ 2017-01-02 14:22 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CACRpkdZE6VgJA27+Wh=Gxd7yOXpLMyT7yCB2PYA36y0gvosHFQ@mail.gmail.com>
On Fri, Dec 30, 2016 at 09:23:59AM +0100, Linus Walleij wrote:
> On Wed, Dec 21, 2016 at 4:27 AM, Vladimir Zapolskiy <vz@mleia.com> wrote:
>
> > The changeset contains a number of cleanups, changed semantics of
> > init_panel() callback, which allows to simplify getting of panel
> > properties from panel device tree node, and a handling of optional
> > "enable-gpios" panel property, the latter is described in
> > display/panel/panel-dpi.txt device tree binding documentation, but
> > it has been unsupported by the ARM CLCD driver.
> >
> > Vladimir Zapolskiy (4):
> > video: ARM CLCD: sort included headers out alphabetically
> > video: ARM CLCD: use panel device node for panel initialization
> > video: ARM CLCD: use panel device node for getting backlight and mode
> > video: ARM CLCD: add support of an optional GPIO to enable panel
>
> As you may have seen Tomi has stepped down as FBDEV maintainer and
> this subsystem is now orphaned.
>
> I guess Andrew Morton merges patches for it in this case, he usually does.
>
> But what we should actually do is create a new DRM driver for CLCD
> in drivers/gpu/drm/arm/clcd*
>
> It's maybe not a small undertaking :(
>
> But in case you're interested in the job, I will pitch in and test the result
> on all ARM reference designs plus Nomadik.
A DRM driver for it would probably be a good idea, but dealing with all
the weird and wonderful connection arrangements may not be that easy...
--
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.
^ permalink raw reply
* [PATCH] tty/serial: atmel_serial: BUG: stop DMA from transmitting in stop_tx
From: Richard Genoud @ 2017-01-02 14:16 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <059a5366-c0d4-ab89-d64a-dcf007bc9e91@atmel.com>
2017-01-02 12:13 GMT+01:00 Nicolas Ferre <nicolas.ferre@atmel.com>:
> Le 13/12/2016 ? 17:27, Richard Genoud a ?crit :
>> If we don't disable the transmitter in atmel_stop_tx, the DMA buffer
>> continues to send data until it is emptied.
>> This cause problems with the flow control (CTS is asserted and data are
>> still sent).
>>
>> So, disabling the transmitter in atmel_stop_tx is a sane thing to do.
>>
>> Tested on at91sam9g35-cm(DMA)
>> Tested for regressions on sama5d2-xplained(Fifo) and at91sam9g20ek(PDC)
>>
>> Cc: <stable@vger.kernel.org> (beware, this won't apply before 4.3)
>> Signed-off-by: Richard Genoud <richard.genoud@gmail.com>
>
> Acked-by: Nicolas Ferre <nicolas.ferre@atmel.com>
>
>> ---
>> drivers/tty/serial/atmel_serial.c | 11 +++++++++++
>> 1 file changed, 11 insertions(+)
>>
>> NB: this is not for the 4.10 merge window, I'm just sending it now to
>> have some comments if someone is againts it.
>>
>> diff --git a/drivers/tty/serial/atmel_serial.c b/drivers/tty/serial/atmel_serial.c
>> index 168b10cad47b..f9d42de5ab2d 100644
>> --- a/drivers/tty/serial/atmel_serial.c
>> +++ b/drivers/tty/serial/atmel_serial.c
>> @@ -481,6 +481,14 @@ static void atmel_stop_tx(struct uart_port *port)
>> /* disable PDC transmit */
>> atmel_uart_writel(port, ATMEL_PDC_PTCR, ATMEL_PDC_TXTDIS);
>> }
>> +
>> + /*
>> + * Disable the transmitter.
>> + * This is mandatory when DMA is used, otherwise the DMA buffer
>> + * is fully transmitted.
>> + */
>> + atmel_uart_writel(port, ATMEL_US_CR, ATMEL_US_TXDIS);
>> +
>> /* Disable interrupts */
>> atmel_uart_writel(port, ATMEL_US_IDR, atmel_port->tx_done_mask);
>>
>> @@ -513,6 +521,9 @@ static void atmel_start_tx(struct uart_port *port)
>>
>> /* Enable interrupts */
>> atmel_uart_writel(port, ATMEL_US_IER, atmel_port->tx_done_mask);
>> +
>> + /* re-enable the transmitter */
>> + atmel_uart_writel(port, ATMEL_US_CR, ATMEL_US_TXEN);
>> }
>>
>> /*
>>
>
>
> --
> Nicolas Ferre
Greg, could you also take this patch in your tree ?
Thanks !
Richard.
^ permalink raw reply
* [PATCH 15/20] ARM/hw_breakpoint: Convert to hotplug state machine
From: Linus Walleij @ 2017-01-02 14:15 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161117183541.8588-16-bigeasy@linutronix.de>
On Thu, Nov 17, 2016 at 7:35 PM, Sebastian Andrzej Siewior
<bigeasy@linutronix.de> wrote:
> Install the callbacks via the state machine and let the core invoke
> the callbacks on the already online CPUs.
>
> smp_call_function_single() has been removed because the function is already
> invoked on the target CPU.
>
> Cc: Will Deacon <will.deacon@arm.com>
> Cc: Mark Rutland <mark.rutland@arm.com>
> Cc: Russell King <linux@armlinux.org.uk>
> Cc: linux-arm-kernel at lists.infradead.org
> Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
> Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
This patch causes a regression on my Qualcomm APQ8060 DragonBoard.
[ 0.000000] CPU: ARMv7 Processor [510f02d2] revision 2 (ARMv7), cr=10c5787d
[ 0.000000] CPU: PIPT / VIPT nonaliasing data cache, VIVT ASID
tagged instruction cache
[ 0.000000] OF: fdt:Machine model: Qualcomm APQ8060 Dragonboard
The board hangs in very early boot. Reverting the commit does not work
because of dependencies, but I bisected down to this commit.
With earlypints the crash looks like this:
NET: Registered protocol family 16
DMA: preallocated 256 KiB pool for atomic coherent allocations
cpuidle: using governor menu
hw-breakpoint: found 3 (+1 reserved) breakpoint and 1 watchpoint registers.
Internal error: Oops - undefined instruction: 0 [#1] PREEMPT SMP ARM
Modules linked in: c
CPU: 0 PID: 1 Comm: swapper/0 Not tainted 4.10.0-rc2-00001-g100b2fb6bf9c #19
Hardware name: Generic DT based system
task: c02a0000 task.stack: c029a000
PC is at write_wb_reg+0x20c/0x330
LR is at arch_hw_breakpoint_init+0x1dc/0x27c
pc : [<c03101dc>] lr : [<c0c0551c>] psr: 80000013
sp : c029bef0 ip : 00000000 fp : dfffcd80
r10: c0c4f83c r9 : 00000004 r8 : 000000af
r7 : c0c4f828 r6 : c10a631c r5 : c10a631c r4 : 00001fe0
r3 : 00000020 r2 : 00001fe0 r1 : 00000000 r0 : 00000060
Flags: Nzcv IRQs on FIQs on Mode SVC_32 ISA ARM Segment none
Control: 10c5787d Table: 4020406a DAC: 00000051
Process swapper/0 (pid: 1, stack limit = 0xc029a210)
Stack: (0xc029bef0 to 0xc029c000)
bee0: 00000000 00000000 dfffcd80 07f80000
bf00: ffffe000 c0c05340 00000000 c030185c c0b7b7d4 dfffcded c0931100 c033b75c
bf20: 60000013 00000003 00000001 c0ab8424 c0b7aa28 00000000 c1099a20 00000003
bf40: 00000003 c0ac1440 c100c588 c10a6000 c10a6000 00000003 c10a6000 c10a6000
bf60: c0c5a30c 000000af 00000004 c0c00e04 00000003 00000003 00000000 c0c005c4
bf80: c08d66c0 00000000 c08d66c0 00000000 00000000 00000000 00000000 00000000
bfa0: 00000000 c08d66c8 00000000 c0308518 00000000 00000000 00000000 00000000
bfc0: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
bfe0: 00000000 00000000 00000000 00000000 00000013 00000000 00000000 00000000
[<c03101dc>] (write_wb_reg) from [<00000000>] ( (null))
Code: ee001ed2 eaffffc3 ee001ed1 eaffffc1 (ee001ed0)
---[ end trace da08286cccfd900e ]---
Kernel panic - not syncing: Attempted to kill init! exitcode=0x0000000b
CPU1: stopping
CPU: 1 PID: 0 Comm: swapper/1 Tainted: G D
4.10.0-rc2-00001-g100b2fb6bf9c #19
Hardware name: Generic DT based system
[<c030f914>] (unwind_backtrace) from [<c030c7b0>] (show_stack+0x10/0x14)
[<c030c7b0>] (show_stack) from [<c05eb2a0>] (dump_stack+0x78/0x8c)
[<c05eb2a0>] (dump_stack) from [<c030ea14>] (handle_IPI+0x358/0x368)
[<c030ea14>] (handle_IPI) from [<c03014a4>] (gic_handle_irq+0x88/0x8c)
[<c03014a4>] (gic_handle_irq) from [<c08dce8c>] (__irq_svc+0x6c/0xa8)
Exception stack(0xc02c5f70 to 0xc02c5fb8)
5f60: 00000001 00000000 00000000 c0318580
5f80: c02c4000 c1003c78 c1003c2c c0fa1f20 c0afea4c c02c5fc8 00000000 00000000
5fa0: 00000008 c02c5fc0 c0308f98 c0308f9c 60000013 ffffffff
[<c08dce8c>] (__irq_svc) from [<c0308f9c>] (arch_cpu_idle+0x38/0x3c)
[<c0308f9c>] (arch_cpu_idle) from [<c035d24c>] (do_idle+0x170/0x204)
[<c035d24c>] (do_idle) from [<c035d598>] (cpu_startup_entry+0x18/0x1c)
[<c035d598>] (cpu_startup_entry) from [<4030154c>] (0x4030154c)
---[ end Kernel panic - not syncing: Attempted to kill init! exitcode=0x0000000b
Something hits a brick wall when initializing the hardware breakpoints.
This is pretty tricksy for me to debug, hints welcome...
Yours,
Linus Walleij
^ permalink raw reply
* [PATCH v4 0/4] ARM: Add support for CONFIG_DEBUG_VIRTUAL
From: Russell King - ARM Linux @ 2017-01-02 14:10 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161226203842.19457-1-f.fainelli@gmail.com>
On Mon, Dec 26, 2016 at 12:38:38PM -0800, Florian Fainelli wrote:
> Hi all,
>
> This patch series builds on top of Laura's [PATCHv5 00/10] CONFIG_DEBUG_VIRTUAL
> for arm64 to add support for CONFIG_DEBUG_VIRTUAL for ARM.
>
> This was tested on a Brahma B15 platform (ARMv7 + HIGHMEM + LPAE).
>
> Note that the treewide changes would involve a huge CC list, which
> is why it has been purposely trimmed to just focusing on the DEBUG_VIRTUAL
> aspect.
Nothing stands out from a quick read-through of these patches, so for the
core ARM and SA11x0 bits:
Acked-by: Russell King <rmk+kernel@armlinux.org.uk>
Thanks.
--
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.
^ permalink raw reply
* [PATCH] rtc: armada38x: add __ro_after_init to armada38x_rtc_ops
From: Russell King - ARM Linux @ 2017-01-02 14:06 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1482751862-18699-1-git-send-email-bhumirks@gmail.com>
On Mon, Dec 26, 2016 at 05:01:02PM +0530, Bhumika Goyal wrote:
> The object armada38x_rtc_ops of type rtc_class_ops structure is not
> modified after getting initialized by armada38x_rtc_probe. Apart from
> getting referenced in init it is also passed as an argument to the function
> devm_rtc_device_register but this argument is of type const struct
> rtc_class_ops *. Therefore add __ro_after_init to its declaration.
What I'd prefer here is for the structure to be duplicated, with one
copy having the alarm methods and one which does not. Both can then
be made "const" (so placed into the read-only section at link time)
and the probe function select between the two.
I think that's a cleaner and better solution, even though it's
slightly larger.
I'm not a fan of __ro_after_init being used where other solutions are
possible.
--
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.
^ permalink raw reply
* [PATCH] arm: dt: Initialize boot_command_line from CONFIG_CMDLINE in case DT does not provide /chosen/bootargs
From: Russell King - ARM Linux @ 2017-01-02 13:54 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <201612252308.15324@pali>
On Sun, Dec 25, 2016 at 11:08:15PM +0100, Pali Roh?r wrote:
> On Friday 16 December 2016 12:42:34 Pali Roh?r wrote:
> > On Thursday 15 December 2016 11:09:32 Russell King - ARM Linux wrote:
> > > > What is reason that CONFIG_CMDLINE is not supported for DT?
> > >
> > > Sorry, that's my mistake - as you've pointed out above, it is
> > > supported but via generic code. I was only looking at arch code
> > > when I made the statement.
> > >
> > > This patch (untested) should solve it:
> > > drivers/of/fdt.c | 40 ++++++++++++++++++++--------------------
> > > 1 file changed, 20 insertions(+), 20 deletions(-)
> > >
> > > diff --git a/drivers/of/fdt.c b/drivers/of/fdt.c
> > > index c89d5d231a0e..fb89157332c6 100644
> > > --- a/drivers/of/fdt.c
> > > +++ b/drivers/of/fdt.c
> > > @@ -1073,26 +1073,6 @@ int __init
> > > early_init_dt_scan_chosen(unsigned long node, const char *uname,
> > > if (p != NULL && l > 0)
> > >
> > > strlcpy(data, p, min((int)l, COMMAND_LINE_SIZE));
> > >
> > > - /*
> > > - * CONFIG_CMDLINE is meant to be a default in case nothing else
> > > - * managed to set the command line, unless CONFIG_CMDLINE_FORCE
> > > - * is set in which case we override whatever was found earlier.
> > > - */
> > > -#ifdef CONFIG_CMDLINE
> > > -#if defined(CONFIG_CMDLINE_EXTEND)
> > > - strlcat(data, " ", COMMAND_LINE_SIZE);
> > > - strlcat(data, CONFIG_CMDLINE, COMMAND_LINE_SIZE);
> > > -#elif defined(CONFIG_CMDLINE_FORCE)
> > > - strlcpy(data, CONFIG_CMDLINE, COMMAND_LINE_SIZE);
> > > -#else
> > > - /* No arguments from boot loader, use kernel's cmdl*/
> > > - if (!((char *)data)[0])
> > > - strlcpy(data, CONFIG_CMDLINE, COMMAND_LINE_SIZE);
> > > -#endif
> > > -#endif /* CONFIG_CMDLINE */
> > > -
> > > - pr_debug("Command line is: %s\n", (char*)data);
> > > -
> > >
> > > /* break now */
> > > return 1;
> > >
> > > }
> > >
> > > @@ -1205,6 +1185,26 @@ void __init early_init_dt_scan_nodes(void)
> > >
> > > /* Retrieve various information from the /chosen node */
> > > of_scan_flat_dt(early_init_dt_scan_chosen, boot_command_line);
> > >
> > > + /*
> > > + * CONFIG_CMDLINE is meant to be a default in case nothing else
> > > + * managed to set the command line, unless CONFIG_CMDLINE_FORCE
> > > + * is set in which case we override whatever was found earlier.
> > > + */
> > > +#ifdef CONFIG_CMDLINE
> > > +#if defined(CONFIG_CMDLINE_EXTEND)
> > > + strlcat(boot_command_line, " ", COMMAND_LINE_SIZE);
> > > + strlcat(boot_command_line, CONFIG_CMDLINE, COMMAND_LINE_SIZE);
> > > +#elif defined(CONFIG_CMDLINE_FORCE)
> > > + strlcpy(boot_command_line, CONFIG_CMDLINE, COMMAND_LINE_SIZE);
> > > +#else
> > > + /* No arguments from boot loader, use kernel's cmdline */
> > > + if (!boot_command_line[0])
> > > + strlcpy(boot_command_line, CONFIG_CMDLINE, COMMAND_LINE_SIZE);
> > > +#endif
> > > +#endif /* CONFIG_CMDLINE */
> > > +
> > > + pr_debug("Command line is: %s\n", boot_command_line);
> > > +
> > >
> > > /* Initialize {size,address}-cells info */
> > > of_scan_flat_dt(early_init_dt_scan_root, NULL);
> >
> > Patch is working fine and fixes my problem. You can add my Tested-by.
>
> Russell, are you going to use your patch? Or original my? Or any other?
> If you need more testing or other data, let me know.
>
> I would like to see this problem (non working CONFIG_CMDLINE) fixed...
If the DT people would like to comment on it and give me an ack or take
the patch... I guess that's not going to happen as they're not on the
Cc... I'll resend later today.
--
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.
^ permalink raw reply
* [PATCH v2 3/3] ARM: dts: imx6ul: Add Engicam Is.IoT MX6UL initial support
From: Jagan Teki @ 2017-01-02 13:40 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1483364420-10012-1-git-send-email-jagan@openedev.com>
From: Jagan Teki <jagan@amarulasolutions.com>
Is.IoT MX6UL modules are system on module solutions manufactured by
Engicam for IOT connectivity applications with following characteristics:
CPU NXP i.MX6UL (G2) Cortex-A7 at 528 MHz
RAM Up to 512 MB LvDDR3 at 800MT/s
NAND 256MB (option)
eMMC 4GB (option)
LCD 18 bit parallel
BT 2.1+EDR,Bluetooth 3.0, Bluetooth 4.1 (Bluetooth low energy)
WLAN IEEE 802.11 b/g/n (single stream n)
Cc: Shawn Guo <shawnguo@kernel.org>
Cc: Matteo Lisi <matteo.lisi@engicam.com>
Cc: Michael Trimarchi <michael@amarulasolutions.com>
Signed-off-by: Jagan Teki <jagan@amarulasolutions.com>
---
Changes for v2:
- Newly added patch
arch/arm/boot/dts/Makefile | 1 +
arch/arm/boot/dts/imx6ul-isiot.dts | 119 +++++++++++++++++++++++++++++++++++++
2 files changed, 120 insertions(+)
create mode 100644 arch/arm/boot/dts/imx6ul-isiot.dts
diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index 51f8dae..bb1a172 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -435,6 +435,7 @@ dtb-$(CONFIG_SOC_IMX6SX) += \
dtb-$(CONFIG_SOC_IMX6UL) += \
imx6ul-14x14-evk.dtb \
imx6ul-geam-kit.dtb \
+ imx6ul-isiot.dtb \
imx6ul-liteboard.dtb \
imx6ul-pico-hobbit.dtb \
imx6ul-tx6ul-0010.dtb \
diff --git a/arch/arm/boot/dts/imx6ul-isiot.dts b/arch/arm/boot/dts/imx6ul-isiot.dts
new file mode 100644
index 0000000..b37db73
--- /dev/null
+++ b/arch/arm/boot/dts/imx6ul-isiot.dts
@@ -0,0 +1,119 @@
+/*
+ * Copyright (C) 2016 Amarula Solutions B.V.
+ * Copyright (C) 2016 Engicam S.r.l.
+ *
+ * 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 "AS IS", 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/gpio/gpio.h>
+#include <dt-bindings/input/input.h>
+#include "imx6ul.dtsi"
+
+/ {
+ model = "Engicam Is.IoT MX6UL Starter kit";
+ compatible = "engicam,imx6ul-isiot", "fsl,imx6ul";
+
+ memory {
+ reg = <0x80000000 0x20000000>;
+ };
+
+ chosen {
+ stdout-path = &uart1;
+ };
+};
+
+&uart1 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_uart1>;
+ status = "okay";
+};
+
+&usdhc1 {
+ pinctrl-names = "default", "state_100mhz", "state_200mhz";
+ pinctrl-0 = <&pinctrl_usdhc1>;
+ pinctrl-1 = <&pinctrl_usdhc1_100mhz>;
+ pinctrl-2 = <&pinctrl_usdhc1_200mhz>;
+ cd-gpios = <&gpio1 19 GPIO_ACTIVE_LOW>;
+ bus-width = <4>;
+ no-1-8-v;
+ status = "okay";
+};
+
+&iomuxc {
+ pinctrl_uart1: uart1grp {
+ fsl,pins = <
+ MX6UL_PAD_UART1_TX_DATA__UART1_DCE_TX 0x1b0b1
+ MX6UL_PAD_UART1_RX_DATA__UART1_DCE_RX 0x1b0b1
+ >;
+ };
+
+ pinctrl_usdhc1: usdhc1grp {
+ fsl,pins = <
+ MX6UL_PAD_SD1_CMD__USDHC1_CMD 0x17059
+ MX6UL_PAD_SD1_CLK__USDHC1_CLK 0x10059
+ MX6UL_PAD_SD1_DATA0__USDHC1_DATA0 0x17059
+ MX6UL_PAD_SD1_DATA1__USDHC1_DATA1 0x17059
+ MX6UL_PAD_SD1_DATA2__USDHC1_DATA2 0x17059
+ MX6UL_PAD_SD1_DATA3__USDHC1_DATA3 0x17059
+ >;
+ };
+
+ pinctrl_usdhc1_100mhz: usdhc1grp100mhz {
+ fsl,pins = <
+ MX6UL_PAD_SD1_CMD__USDHC1_CMD 0x170b9
+ MX6UL_PAD_SD1_CLK__USDHC1_CLK 0x100b9
+ MX6UL_PAD_SD1_DATA0__USDHC1_DATA0 0x170b9
+ MX6UL_PAD_SD1_DATA1__USDHC1_DATA1 0x170b9
+ MX6UL_PAD_SD1_DATA2__USDHC1_DATA2 0x170b9
+ MX6UL_PAD_SD1_DATA3__USDHC1_DATA3 0x170b9
+ >;
+ };
+
+ pinctrl_usdhc1_200mhz: usdhc1grp200mhz {
+ fsl,pins = <
+ MX6UL_PAD_SD1_CMD__USDHC1_CMD 0x170f9
+ MX6UL_PAD_SD1_CLK__USDHC1_CLK 0x100f9
+ MX6UL_PAD_SD1_DATA0__USDHC1_DATA0 0x170f9
+ MX6UL_PAD_SD1_DATA1__USDHC1_DATA1 0x170f9
+ MX6UL_PAD_SD1_DATA2__USDHC1_DATA2 0x170f9
+ MX6UL_PAD_SD1_DATA3__USDHC1_DATA3 0x170f9
+ >;
+ };
+};
--
1.9.1
^ permalink raw reply related
* [PATCH v2 2/3] ARM: dts: imx6q-icore-rqs: Update model to support Dual SOM
From: Jagan Teki @ 2017-01-02 13:40 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1483364420-10012-1-git-send-email-jagan@openedev.com>
From: Jagan Teki <jagan@amarulasolutions.com>
Engicam i.CoreM6 Dual and Quad SOM's use same dts file, hence
update model name to add Dual and also added full mode decsription.
Cc: Shawn Guo <shawnguo@kernel.org>
Cc: Matteo Lisi <matteo.lisi@engicam.com>
Cc: Michael Trimarchi <michael@amarulasolutions.com>
Signed-off-by: Jagan Teki <jagan@amarulasolutions.com>
---
Changes for v2:
- none
arch/arm/boot/dts/imx6q-icore-rqs.dts | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/imx6q-icore-rqs.dts b/arch/arm/boot/dts/imx6q-icore-rqs.dts
index 0053188..76757f8 100644
--- a/arch/arm/boot/dts/imx6q-icore-rqs.dts
+++ b/arch/arm/boot/dts/imx6q-icore-rqs.dts
@@ -45,7 +45,7 @@
#include "imx6qdl-icore-rqs.dtsi"
/ {
- model = "Engicam i.CoreM6 Quad SOM";
+ model = "Engicam i.CoreM6 Quad/Dual RQS Starter Kit";
compatible = "engicam,imx6-icore-rqs", "fsl,imx6q";
sound {
--
1.9.1
^ permalink raw reply related
* [PATCH v2 1/3] ARM: dts: imx6dl: Add Engicam i.CoreM6 DualLite/Solo RQS initial support
From: Jagan Teki @ 2017-01-02 13:40 UTC (permalink / raw)
To: linux-arm-kernel
From: Jagan Teki <jagan@amarulasolutions.com>
i.CoreM6 DualLite/Solo modules are system on module solutions manufactured
by Engicam with following characteristics:
CPU NXP i.MX6 DL, 800MHz
RAM 1GB, 32, 64 bit, DDR3-800/1066
NAND SLC,512MB
Power supply Single 5V
MAX LCD RES FULLHD
and more info at
http://www.engicam.com/en/products/embedded/som/standard/i-core-rqs-m6s-dl-d-q
Cc: Shawn Guo <shawnguo@kernel.org>
Cc: Matteo Lisi <matteo.lisi@engicam.com>
Cc: Michael Trimarchi <michael@amarulasolutions.com>
Signed-off-by: Jagan Teki <jagan@amarulasolutions.com>
---
Changes for v2:
- Update correct licenece notes
arch/arm/boot/dts/Makefile | 1 +
arch/arm/boot/dts/imx6dl-icore-rqs.dts | 51 ++++++++++++++++++++++++++++++++++
2 files changed, 52 insertions(+)
create mode 100644 arch/arm/boot/dts/imx6dl-icore-rqs.dts
diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index cccdbcb..51f8dae 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -349,6 +349,7 @@ dtb-$(CONFIG_SOC_IMX6Q) += \
imx6dl-gw553x.dtb \
imx6dl-hummingboard.dtb \
imx6dl-icore.dtb \
+ imx6dl-icore-rqs.dtb \
imx6dl-nit6xlite.dtb \
imx6dl-nitrogen6x.dtb \
imx6dl-phytec-pbab01.dtb \
diff --git a/arch/arm/boot/dts/imx6dl-icore-rqs.dts b/arch/arm/boot/dts/imx6dl-icore-rqs.dts
new file mode 100644
index 0000000..cf42c2f
--- /dev/null
+++ b/arch/arm/boot/dts/imx6dl-icore-rqs.dts
@@ -0,0 +1,51 @@
+/*
+ * Copyright (C) 2016 Amarula Solutions B.V.
+ * Copyright (C) 2016 Engicam S.r.l.
+ *
+ * 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 "AS IS", 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 "imx6q.dtsi"
+#include "imx6qdl-icore-rqs.dtsi"
+
+/ {
+ model = "Engicam i.CoreM6 DualLite/Solo RQS Starter Kit";
+ compatible = "engicam,imx6-icore-rqs", "fsl,imx6dl";
+};
--
1.9.1
^ permalink raw reply related
* [PATCH v2] ARM64: zynqmp: Fix i2c node's compatible string
From: Michal Simek @ 2017-01-02 13:35 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161222172740.7eieploc3kp5lunx@xsjsorenbubuntu.xilinx.com>
On 22.12.2016 18:27, S?ren Brinkmann wrote:
> On Thu, 2016-12-22 at 09:19:25 -0800, mdf at kernel.org wrote:
>> From: Moritz Fischer <mdf@kernel.org>
>>
>> The Zynq Ultrascale MP uses version 1.4 of the Cadence IP core
>> which fixes some silicon bugs that needed software workarounds
>> in Version 1.0 that was used on Zynq systems.
>>
>> Signed-off-by: Moritz Fischer <mdf@kernel.org>
>> Cc: Michal Simek <michal.simek@xilinx.com>
>> Cc: S?ren Brinkmann <soren.brinkmann@xilinx.com>
>> Cc: Rob Herring <robh+dt@kernel.org>
> Acked-by: S?ren Brinkmann <soren.brinkmann@xilinx.com>
>
> S?ren
>
Applied and send as the part of PR to arm-soc guys.
Thanks,
Michal
^ permalink raw reply
* [GIT PULL] ARM: Xilinx ZynqMP DT fixes for v4.10
From: Michal Simek @ 2017-01-02 13:35 UTC (permalink / raw)
To: linux-arm-kernel
Hi,
please pull these two fixes to your tree. Will be good to get them to
v4.10. If not possible, please queue them for 4.11.
Thanks,
Michal
The following changes since commit 7ce7d89f48834cefece7804d38fc5d85382edf77:
Linux 4.10-rc1 (2016-12-25 16:13:08 -0800)
are available in the git repository at:
https://github.com/Xilinx/linux-xlnx.git tags/zynmp-dt-fixes-for-4.10
for you to fetch changes up to c415f9e8304a1d235ef118d912f374ee2e46c45d:
ARM64: zynqmp: Fix i2c node's compatible string (2017-01-02 14:14:36
+0100)
----------------------------------------------------------------
arm: Xilinx ZynqMP DT fixes for v4.10
- Fix dtc warnings
- Fix i2c compatible string
----------------------------------------------------------------
Michal Simek (1):
ARM64: zynqmp: Fix W=1 dtc 1.4 warnings
Moritz Fischer (1):
ARM64: zynqmp: Fix i2c node's compatible string
arch/arm64/boot/dts/xilinx/zynqmp-ep108.dts | 2 +-
arch/arm64/boot/dts/xilinx/zynqmp.dtsi | 6 +++---
2 files changed, 4 insertions(+), 4 deletions(-)
--
Michal Simek, Ing. (M.Eng), OpenPGP -> KeyID: FE3D1F91
w: www.monstr.eu p: +42-0-721842854
Maintainer of Linux kernel - Xilinx Microblaze
Maintainer of Linux kernel - Xilinx Zynq ARM and ZynqMP ARM64 SoCs
U-Boot custodian - Xilinx Microblaze/Zynq/ZynqMP SoCs
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: OpenPGP digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20170102/10564cf4/attachment.sig>
^ permalink raw reply
* [PATCH v2 2/3] dmaeninge: xilinx_dma: Fix bug in multiple frame stores scenario in vdma
From: Jose Abreu @ 2017-01-02 13:34 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <C246CAC1457055469EF09E3A7AC4E11A4A65FFE9@XAP-PVEXMBX01.xlnx.xilinx.com>
Hi Kedar,
On 02-01-2017 11:46, Appana Durga Kedareswara Rao wrote:
> Hi Jose Miguel Abreu,
>
> Thanks for the review....
> Sorry for the delay in the reply please see comments inline...
>
>>
[snip]
>> What if we reach here and j < num_frms? It can happen because if
>> the pending list is empty the loop breaks. Then VDMA will start
>> with framebuffers having address 0x0. You should only program
>> vsize when j > num_frms or when we have already previously set
>> the framebuffers (i.e. when submitcount has already been
>> incremented num_frms at least once).
> In case of j < num_frms VDMA won't start the frame buffer having address 0
> As we are programming the VDMA buffer address based on the desc_submitcount value only i.e. i.
>
> Code snippet in the driver doing this:
> list_for_each_entry(segment, &desc->segments, node) {
> if (chan->ext_addr)
> vdma_desc_write_64(chan,
> XILINX_VDMA_REG_START_ADDRESS_64(i++),
> segment->hw.buf_addr,
> segment->hw.buf_addr_msb);
> else
> vdma_desc_write(chan,
> XILINX_VDMA_REG_START_ADDRESS(i++),
> segment->hw.buf_addr);
>
> last = segment;
> }
>
> Initially desc_submitcount will be zero.
> Let's assume h/w is configured for 10 frames and user submitted only 5 frames.
> And triggered the VDMA h/w using issue_pending in this case desc_submitcount will be 5.
> desc_submitcount will become zero again only when
> User submits more frames than h/w capable or user submit frames up to h/w capable.
>
> If my understanding is wrong could you please elaborate the race condition that you are talking above?
I just noticed there is a write to XILINX_DMA_REG_FRMSTORE which,
by the description in the VDMA databook, allows to modify the
total number of framebuffers.
Does it correct this situation: Lets assume VDMA has 10
framebuffers in HW and user only submits 5 descriptors. Then
vsize will be programmed and VDMA will start. The VDMA will start
in fb 1, then 2, ... until 5 its all ok. But then after the fb 5
the VDMA will jump to fb 6, this fb will have no address because
the user only submitted 5 addresses so VDMA will try to write to
location 0x0 of system mem (if using S2MM channel). ?
If so then there is no race condition, but the HW image that I
have does not have this register enabled so I was getting this
result (memory corruption because not all framebuffers had
addresses set).
Best regards,
Jose Miguel Abreu
>
> Regards,
> Kedar.
>
>> Best regards,
>> Jose Miguel Abreu
>>
^ permalink raw reply
* [PATCH v6 14/14] irqchip: mbigen: Add ACPI support
From: Hanjun Guo @ 2017-01-02 13:31 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1483363905-2806-1-git-send-email-hanjun.guo@linaro.org>
With the preparation of platform msi support and interrupt producer
in DSDT, we can add mbigen ACPI support now.
We are using _PRS methd to indicate number of irq pins instead
of num_pins in DT to avoid _DSD usage in this case.
For mbi-gen,
Device(MBI0) {
Name(_HID, "HISI0152")
Name(_UID, Zero)
Name(_CRS, ResourceTemplate() {
Memory32Fixed(ReadWrite, 0xa0080000, 0x10000)
})
Name (_PRS, ResourceTemplate() {
Interrupt(ResourceProducer,...) {12,14,....}
})
}
For devices,
Device(COM0) {
Name(_HID, "ACPIIDxx")
Name(_UID, Zero)
Name(_CRS, ResourceTemplate() {
Memory32Fixed(ReadWrite, 0xb0030000, 0x10000)
Interrupt(ResourceConsumer,..., "\_SB.MBI0") {12}
})
}
With the helpe of platform msi and interrupt producer, then devices
will get the virq from mbi-gen's irqdomain.
Signed-off-by: Hanjun Guo <hanjun.guo@linaro.org>
Reviewed-by: Majun <majun258@huawei.com>
Tested-by: Majun <majun258@huawei.com>
Tested-by: Xinwei Kong <kong.kongxinwei@hisilicon.com>
Cc: Marc Zyngier <marc.zyngier@arm.com>
Cc: Thomas Gleixner <tglx@linutronix.de>
---
drivers/irqchip/irq-mbigen.c | 70 ++++++++++++++++++++++++++++++++++++++++++--
1 file changed, 67 insertions(+), 3 deletions(-)
diff --git a/drivers/irqchip/irq-mbigen.c b/drivers/irqchip/irq-mbigen.c
index 4e11da5..17d35fa 100644
--- a/drivers/irqchip/irq-mbigen.c
+++ b/drivers/irqchip/irq-mbigen.c
@@ -16,6 +16,7 @@
* along with this program. If not, see <http://www.gnu.org/licenses/>.
*/
+#include <linux/acpi.h>
#include <linux/interrupt.h>
#include <linux/irqchip.h>
#include <linux/module.h>
@@ -180,7 +181,7 @@ static int mbigen_domain_translate(struct irq_domain *d,
unsigned long *hwirq,
unsigned int *type)
{
- if (is_of_node(fwspec->fwnode)) {
+ if (is_of_node(fwspec->fwnode) || is_acpi_device_node(fwspec->fwnode)) {
if (fwspec->param_count != 2)
return -EINVAL;
@@ -271,6 +272,54 @@ static int mbigen_of_create_domain(struct platform_device *pdev,
return 0;
}
+#ifdef CONFIG_ACPI
+static acpi_status mbigen_acpi_process_resource(struct acpi_resource *ares,
+ void *context)
+{
+ struct acpi_resource_extended_irq *ext_irq;
+ u32 *num_irqs = context;
+
+ switch (ares->type) {
+ case ACPI_RESOURCE_TYPE_EXTENDED_IRQ:
+ ext_irq = &ares->data.extended_irq;
+ *num_irqs += ext_irq->interrupt_count;
+ break;
+ default:
+ break;
+ }
+
+ return AE_OK;
+}
+
+static int mbigen_acpi_create_domain(struct platform_device *pdev,
+ struct mbigen_device *mgn_chip)
+{
+ struct irq_domain *domain;
+ u32 num_msis = 0;
+ acpi_status status;
+
+ status = acpi_walk_resources(ACPI_HANDLE(&pdev->dev), METHOD_NAME__PRS,
+ mbigen_acpi_process_resource, &num_msis);
+ if (ACPI_FAILURE(status) || num_msis == 0)
+ return -EINVAL;
+
+ domain = platform_msi_create_device_domain(&pdev->dev, num_msis,
+ mbigen_write_msg,
+ &mbigen_domain_ops,
+ mgn_chip);
+ if (!domain)
+ return -ENOMEM;
+
+ return 0;
+}
+#else
+static int mbigen_acpi_create_domain(struct platform_device *pdev,
+ struct mbigen_device *mgn_chip)
+{
+ return -ENODEV;
+}
+#endif
+
static int mbigen_device_probe(struct platform_device *pdev)
{
struct mbigen_device *mgn_chip;
@@ -288,9 +337,17 @@ static int mbigen_device_probe(struct platform_device *pdev)
if (IS_ERR(mgn_chip->base))
return PTR_ERR(mgn_chip->base);
- err = mbigen_of_create_domain(pdev, mgn_chip);
- if (err)
+ if (IS_ENABLED(CONFIG_OF) && pdev->dev.of_node)
+ err = mbigen_of_create_domain(pdev, mgn_chip);
+ else if (ACPI_COMPANION(&pdev->dev))
+ err = mbigen_acpi_create_domain(pdev, mgn_chip);
+ else
+ err = -EINVAL;
+
+ if (err) {
+ dev_err(&pdev->dev, "Failed to create mbi-gen@%p irqdomain", mgn_chip->base);
return err;
+ }
platform_set_drvdata(pdev, mgn_chip);
return 0;
@@ -302,10 +359,17 @@ static int mbigen_device_probe(struct platform_device *pdev)
};
MODULE_DEVICE_TABLE(of, mbigen_of_match);
+static const struct acpi_device_id mbigen_acpi_match[] = {
+ { "HISI0152", 0 },
+ {}
+};
+MODULE_DEVICE_TABLE(acpi, mbigen_acpi_match);
+
static struct platform_driver mbigen_platform_driver = {
.driver = {
.name = "Hisilicon MBIGEN-V2",
.of_match_table = mbigen_of_match,
+ .acpi_match_table = ACPI_PTR(mbigen_acpi_match),
},
.probe = mbigen_device_probe,
};
--
1.9.1
^ permalink raw reply related
* [PATCH v6 13/14] irqchip: mbigen: introduce mbigen_of_create_domain()
From: Hanjun Guo @ 2017-01-02 13:31 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1483363905-2806-1-git-send-email-hanjun.guo@linaro.org>
From: Kefeng Wang <wangkefeng.wang@huawei.com>
Introduce mbigen_of_create_domain() to consolidate OF related
code and prepare for ACPI later, no funtional change.
Signed-off-by: Kefeng Wang <wangkefeng.wang@huawei.com>
Signed-off-by: Hanjun Guo <hanjun.guo@linaro.org>
Reviewed-by: Majun <majun258@huawei.com>
Tested-by: Majun <majun258@huawei.com>
Tested-by: Xinwei Kong <kong.kongxinwei@hisilicon.com>
Cc: Marc Zyngier <marc.zyngier@arm.com>
Cc: Thomas Gleixner <tglx@linutronix.de>
---
drivers/irqchip/irq-mbigen.c | 42 +++++++++++++++++++++++++++---------------
1 file changed, 27 insertions(+), 15 deletions(-)
diff --git a/drivers/irqchip/irq-mbigen.c b/drivers/irqchip/irq-mbigen.c
index c01ab41..4e11da5 100644
--- a/drivers/irqchip/irq-mbigen.c
+++ b/drivers/irqchip/irq-mbigen.c
@@ -236,27 +236,15 @@ static int mbigen_irq_domain_alloc(struct irq_domain *domain,
.free = irq_domain_free_irqs_common,
};
-static int mbigen_device_probe(struct platform_device *pdev)
+static int mbigen_of_create_domain(struct platform_device *pdev,
+ struct mbigen_device *mgn_chip)
{
- struct mbigen_device *mgn_chip;
+ struct device *parent;
struct platform_device *child;
struct irq_domain *domain;
struct device_node *np;
- struct device *parent;
- struct resource *res;
u32 num_pins;
- mgn_chip = devm_kzalloc(&pdev->dev, sizeof(*mgn_chip), GFP_KERNEL);
- if (!mgn_chip)
- return -ENOMEM;
-
- mgn_chip->pdev = pdev;
-
- res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
- mgn_chip->base = devm_ioremap_resource(&pdev->dev, res);
- if (IS_ERR(mgn_chip->base))
- return PTR_ERR(mgn_chip->base);
-
for_each_child_of_node(pdev->dev.of_node, np) {
if (!of_property_read_bool(np, "interrupt-controller"))
continue;
@@ -280,6 +268,30 @@ static int mbigen_device_probe(struct platform_device *pdev)
return -ENOMEM;
}
+ return 0;
+}
+
+static int mbigen_device_probe(struct platform_device *pdev)
+{
+ struct mbigen_device *mgn_chip;
+ struct resource *res;
+ int err;
+
+ mgn_chip = devm_kzalloc(&pdev->dev, sizeof(*mgn_chip), GFP_KERNEL);
+ if (!mgn_chip)
+ return -ENOMEM;
+
+ mgn_chip->pdev = pdev;
+
+ res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
+ mgn_chip->base = devm_ioremap(&pdev->dev, res->start, resource_size(res));
+ if (IS_ERR(mgn_chip->base))
+ return PTR_ERR(mgn_chip->base);
+
+ err = mbigen_of_create_domain(pdev, mgn_chip);
+ if (err)
+ return err;
+
platform_set_drvdata(pdev, mgn_chip);
return 0;
}
--
1.9.1
^ permalink raw reply related
* [PATCH v6 12/14] irqchip: mbigen: drop module owner
From: Hanjun Guo @ 2017-01-02 13:31 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1483363905-2806-1-git-send-email-hanjun.guo@linaro.org>
From: Kefeng Wang <wangkefeng.wang@huawei.com>
Module owner will be set by driver core, so drop it.
Signed-off-by: Kefeng Wang <wangkefeng.wang@huawei.com>
Signed-off-by: Hanjun Guo <hanjun.guo@linaro.org>
Reviewed-by: Majun <majun258@huawei.com>
Tested-by: Majun <majun258@huawei.com>
Tested-by: Xinwei Kong <kong.kongxinwei@hisilicon.com>
Cc: Marc Zyngier <marc.zyngier@arm.com>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Ma Jun <majun258@huawei.com>
---
drivers/irqchip/irq-mbigen.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/irqchip/irq-mbigen.c b/drivers/irqchip/irq-mbigen.c
index 03b79b0..c01ab41 100644
--- a/drivers/irqchip/irq-mbigen.c
+++ b/drivers/irqchip/irq-mbigen.c
@@ -293,7 +293,6 @@ static int mbigen_device_probe(struct platform_device *pdev)
static struct platform_driver mbigen_platform_driver = {
.driver = {
.name = "Hisilicon MBIGEN-V2",
- .owner = THIS_MODULE,
.of_match_table = mbigen_of_match,
},
.probe = mbigen_device_probe,
--
1.9.1
^ permalink raw reply related
* [PATCH v6 11/14] msi: platform: make platform_msi_create_device_domain() ACPI aware
From: Hanjun Guo @ 2017-01-02 13:31 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1483363905-2806-1-git-send-email-hanjun.guo@linaro.org>
With the platform msi domain created for ITS, irqchip such as
mbi-gen connecting ITS, which needs ctreate its own irqdomain.
Fortunately with the platform msi support upstreamed by Marc,
we just need to add minor code to make it run properly.
platform_msi_create_device_domain() is almost ready for ACPI use
except of_node_to_fwnode() is for dt only, make it ACPI aware then
things will work in both DTS and ACPI.
Signed-off-by: Hanjun Guo <hanjun.guo@linaro.org>
Tested-by: Majun <majun258@huawei.com>
Tested-by: Xinwei Kong <kong.kongxinwei@hisilicon.com>
Cc: Marc Zyngier <marc.zyngier@arm.com>
Cc: Greg KH <gregkh@linuxfoundation.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
---
drivers/base/platform-msi.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/base/platform-msi.c b/drivers/base/platform-msi.c
index be6a599..035ca3b 100644
--- a/drivers/base/platform-msi.c
+++ b/drivers/base/platform-msi.c
@@ -345,8 +345,7 @@ struct irq_domain *
data->host_data = host_data;
domain = irq_domain_create_hierarchy(dev->msi_domain, 0, nvec,
- of_node_to_fwnode(dev->of_node),
- ops, data);
+ dev->fwnode, ops, data);
if (!domain)
goto free_priv;
--
1.9.1
^ permalink raw reply related
* [PATCH v6 10/14] ACPI: ARM64: IORT: rework iort_node_get_id() for NC->SMMU->ITS case
From: Hanjun Guo @ 2017-01-02 13:31 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1483363905-2806-1-git-send-email-hanjun.guo@linaro.org>
iort_node_get_id() for now only support NC(named componant)->SMMU
or NC->ITS cases, we also have other device topology such NC->
SMMU->ITS, so rework iort_node_get_id() for those cases.
Signed-off-by: Hanjun Guo <hanjun.guo@linaro.org>
Tested-by: Majun <majun258@huawei.com>
Tested-by: Xinwei Kong <kong.kongxinwei@hisilicon.com>
Cc: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
---
drivers/acpi/arm64/iort.c | 61 ++++++++++++++++++++++++++---------------------
1 file changed, 34 insertions(+), 27 deletions(-)
diff --git a/drivers/acpi/arm64/iort.c b/drivers/acpi/arm64/iort.c
index 6b72fcb..99f079b 100644
--- a/drivers/acpi/arm64/iort.c
+++ b/drivers/acpi/arm64/iort.c
@@ -292,22 +292,28 @@ static acpi_status iort_match_node_callback(struct acpi_iort_node *node,
return status;
}
-static int iort_id_map(struct acpi_iort_id_mapping *map, u8 type, u32 rid_in,
- u32 *rid_out)
+static int iort_id_single_map(struct acpi_iort_id_mapping *map, u8 type,
+ u32 *rid_out)
{
/* Single mapping does not care for input id */
if (map->flags & ACPI_IORT_ID_SINGLE_MAPPING) {
if (type == ACPI_IORT_NODE_NAMED_COMPONENT ||
type == ACPI_IORT_NODE_PCI_ROOT_COMPLEX) {
- *rid_out = map->output_base;
+ if (rid_out)
+ *rid_out = map->output_base;
return 0;
}
pr_warn(FW_BUG "[map %p] SINGLE MAPPING flag not allowed for node type %d, skipping ID map\n",
map, type);
- return -ENXIO;
}
+ return -ENXIO;
+}
+
+static int iort_id_map(struct acpi_iort_id_mapping *map, u32 rid_in,
+ u32 *rid_out)
+{
if (rid_in < map->input_base ||
(rid_in >= map->input_base + map->id_count))
return -ENXIO;
@@ -324,33 +330,34 @@ struct acpi_iort_node *iort_node_get_id(struct acpi_iort_node *node,
struct acpi_iort_node *parent;
struct acpi_iort_id_mapping *map;
- if (!node->mapping_offset || !node->mapping_count ||
- index >= node->mapping_count)
- return NULL;
-
- map = ACPI_ADD_PTR(struct acpi_iort_id_mapping, node,
- node->mapping_offset);
+ while (node) {
+ if (!node->mapping_offset || !node->mapping_count ||
+ index >= node->mapping_count)
+ return NULL;
- /* Firmware bug! */
- if (!map->output_reference) {
- pr_err(FW_BUG "[node %p type %d] ID map has NULL parent reference\n",
- node, node->type);
- return NULL;
- }
+ map = ACPI_ADD_PTR(struct acpi_iort_id_mapping, node,
+ node->mapping_offset);
- parent = ACPI_ADD_PTR(struct acpi_iort_node, iort_table,
- map->output_reference);
+ /* Firmware bug! */
+ if (!map->output_reference) {
+ pr_err(FW_BUG "[node %p type %d] ID map has NULL parent reference\n",
+ node, node->type);
+ return NULL;
+ }
- if (!(IORT_TYPE_MASK(parent->type) & type_mask))
- return NULL;
+ parent = ACPI_ADD_PTR(struct acpi_iort_node, iort_table,
+ map->output_reference);
- if (map[index].flags & ACPI_IORT_ID_SINGLE_MAPPING) {
- if (node->type == ACPI_IORT_NODE_NAMED_COMPONENT ||
- node->type == ACPI_IORT_NODE_PCI_ROOT_COMPLEX) {
- if (id_out)
- *id_out = map[index].output_base;
- return parent;
+ /* go upstream to find its parent */
+ if (!(IORT_TYPE_MASK(parent->type) & type_mask)) {
+ node = parent;
+ continue;
}
+
+ if (iort_id_single_map(&map[index], node->type, id_out))
+ break;
+
+ return parent;
}
return NULL;
@@ -388,7 +395,7 @@ static struct acpi_iort_node *iort_node_map_rid(struct acpi_iort_node *node,
/* Do the RID translation */
for (i = 0; i < node->mapping_count; i++, map++) {
- if (!iort_id_map(map, node->type, rid, &rid))
+ if (!iort_id_map(map, rid, &rid))
break;
}
--
1.9.1
^ permalink raw reply related
* [PATCH v6 09/14] ACPI: platform: setup MSI domain for ACPI based platform device
From: Hanjun Guo @ 2017-01-02 13:31 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1483363905-2806-1-git-send-email-hanjun.guo@linaro.org>
With the platform msi domain created, we can set up the msi domain
for a platform device when it's probed.
In order to do that, we need to get the domain that the platform
device connecting to, so the iort_get_platform_device_domain() is
introduced to retrieve the domain from iort.
After the domain is retrieved, we need a proper way to set the
domain to paltform device, as some platform devices such as an
irqchip needs the msi irqdomain to be the interrupt parent domain,
we need to get irqdomain before platform device is probed but after
the platform device is allocated (the time slot of setting the
msi domain also works for other cases). So simply call
acpi_configure_pmsi_domain() in acpi_platform_notify() for
platform devices will work.
Signed-off-by: Hanjun Guo <hanjun.guo@linaro.org>
Cc: Rafael J. Wysocki <rjw@rjwysocki.net>
Cc: Marc Zyngier <marc.zyngier@arm.com>
Cc: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
---
drivers/acpi/arm64/iort.c | 43 +++++++++++++++++++++++++++++++++++++++++++
drivers/acpi/glue.c | 6 ++++++
include/linux/acpi_iort.h | 3 +++
3 files changed, 52 insertions(+)
diff --git a/drivers/acpi/arm64/iort.c b/drivers/acpi/arm64/iort.c
index bc68d93..6b72fcb 100644
--- a/drivers/acpi/arm64/iort.c
+++ b/drivers/acpi/arm64/iort.c
@@ -527,6 +527,49 @@ struct irq_domain *iort_get_device_domain(struct device *dev, u32 req_id)
return irq_find_matching_fwnode(handle, DOMAIN_BUS_PCI_MSI);
}
+/**
+ * iort_get_platform_device_domain() - Find MSI domain related to a
+ * platform device
+ * @dev: the dev pointer associated with the platform device
+ *
+ * Returns: the MSI domain for this device, NULL otherwise
+ */
+static struct irq_domain *iort_get_platform_device_domain(struct device *dev)
+{
+ struct acpi_iort_node *node, *msi_parent;
+ struct fwnode_handle *iort_fwnode;
+ struct acpi_iort_its_group *its;
+
+ /* find its associated iort node */
+ node = iort_scan_node(ACPI_IORT_NODE_NAMED_COMPONENT,
+ iort_match_node_callback, dev);
+ if (!node)
+ return NULL;
+
+ /* then find its msi parent node */
+ msi_parent = iort_node_get_id(node, NULL, IORT_MSI_TYPE, 0);
+ if (!msi_parent)
+ return NULL;
+
+ /* Move to ITS specific data */
+ its = (struct acpi_iort_its_group *)msi_parent->node_data;
+
+ iort_fwnode = iort_find_domain_token(its->identifiers[0]);
+ if (!iort_fwnode)
+ return NULL;
+
+ return irq_find_matching_fwnode(iort_fwnode, DOMAIN_BUS_PLATFORM_MSI);
+}
+
+void acpi_configure_pmsi_domain(struct device *dev)
+{
+ struct irq_domain *msi_domain;
+
+ msi_domain = iort_get_platform_device_domain(dev);
+ if (msi_domain)
+ dev_set_msi_domain(dev, msi_domain);
+}
+
static int __get_pci_rid(struct pci_dev *pdev, u16 alias, void *data)
{
u32 *rid = data;
diff --git a/drivers/acpi/glue.c b/drivers/acpi/glue.c
index f8d6564..4a73f27 100644
--- a/drivers/acpi/glue.c
+++ b/drivers/acpi/glue.c
@@ -6,6 +6,8 @@
*
* This file is released under the GPLv2.
*/
+
+#include <linux/acpi_iort.h>
#include <linux/export.h>
#include <linux/init.h>
#include <linux/list.h>
@@ -14,6 +16,7 @@
#include <linux/rwsem.h>
#include <linux/acpi.h>
#include <linux/dma-mapping.h>
+#include <linux/platform_device.h>
#include "internal.h"
@@ -315,6 +318,9 @@ static int acpi_platform_notify(struct device *dev)
if (!adev)
goto out;
+ if (dev->bus == &platform_bus_type)
+ acpi_configure_pmsi_domain(dev);
+
if (type && type->setup)
type->setup(dev);
else if (adev->handler && adev->handler->bind)
diff --git a/include/linux/acpi_iort.h b/include/linux/acpi_iort.h
index ef99fd52..33f5ac3 100644
--- a/include/linux/acpi_iort.h
+++ b/include/linux/acpi_iort.h
@@ -38,6 +38,7 @@
/* IOMMU interface */
void iort_set_dma_mask(struct device *dev);
const struct iommu_ops *iort_iommu_configure(struct device *dev);
+void acpi_configure_pmsi_domain(struct device *dev);
#else
static inline void acpi_iort_init(void) { }
static inline bool iort_node_match(u8 type) { return false; }
@@ -58,6 +59,8 @@ static inline void iort_set_dma_mask(struct device *dev) { }
static inline
const struct iommu_ops *iort_iommu_configure(struct device *dev)
{ return NULL; }
+
+static inline void acpi_configure_pmsi_domain(struct device *dev) { }
#endif
#define IORT_ACPI_DECLARE(name, table_id, fn) \
--
1.9.1
^ permalink raw reply related
* [PATCH v6 08/14] ACPI: ARM64: IORT: rework iort_node_get_id()
From: Hanjun Guo @ 2017-01-02 13:31 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1483363905-2806-1-git-send-email-hanjun.guo@linaro.org>
iort_node_get_id() has two output, one is the mapped ids,
the other is the referenced parent node which is returned
from the function.
For now we need a API just return its parent node for
single mapping, so just update this function slightly then
reuse it later.
Signed-off-by: Hanjun Guo <hanjun.guo@linaro.org>
Tested-by: Majun <majun258@huawei.com>
Tested-by: Xinwei Kong <kong.kongxinwei@hisilicon.com>
Cc: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
Cc: Marc Zyngier <marc.zyngier@arm.com>
---
drivers/acpi/arm64/iort.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/acpi/arm64/iort.c b/drivers/acpi/arm64/iort.c
index ab7bae7..bc68d93 100644
--- a/drivers/acpi/arm64/iort.c
+++ b/drivers/acpi/arm64/iort.c
@@ -347,7 +347,8 @@ struct acpi_iort_node *iort_node_get_id(struct acpi_iort_node *node,
if (map[index].flags & ACPI_IORT_ID_SINGLE_MAPPING) {
if (node->type == ACPI_IORT_NODE_NAMED_COMPONENT ||
node->type == ACPI_IORT_NODE_PCI_ROOT_COMPLEX) {
- *id_out = map[index].output_base;
+ if (id_out)
+ *id_out = map[index].output_base;
return parent;
}
}
--
1.9.1
^ permalink raw reply related
* [PATCH v6 07/14] irqchip: gicv3-its: platform-msi: scan MADT to create platform msi domain
From: Hanjun Guo @ 2017-01-02 13:31 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1483363905-2806-1-git-send-email-hanjun.guo@linaro.org>
With the introduction of its_pmsi_init_one(), we can add some code
on top for ACPI support of platform MSI.
We are scanning the MADT table to get the ITS entry(ies), then use
the information to create the platform msi domain for devices connect
to it, just like the PCI MSI for ITS did.
Signed-off-by: Hanjun Guo <hanjun.guo@linaro.org>
Tested-by: Sinan Kaya <okaya@codeaurora.org>
Tested-by: Majun <majun258@huawei.com>
Tested-by: Xinwei Kong <kong.kongxinwei@hisilicon.com>
Cc: Marc Zyngier <marc.zyngier@arm.com>
Cc: Tomasz Nowicki <tn@semihalf.com>
Cc: Thomas Gleixner <tglx@linutronix.de>
---
drivers/irqchip/irq-gic-v3-its-platform-msi.c | 36 +++++++++++++++++++++++++++
1 file changed, 36 insertions(+)
diff --git a/drivers/irqchip/irq-gic-v3-its-platform-msi.c b/drivers/irqchip/irq-gic-v3-its-platform-msi.c
index ff72704..0be0437 100644
--- a/drivers/irqchip/irq-gic-v3-its-platform-msi.c
+++ b/drivers/irqchip/irq-gic-v3-its-platform-msi.c
@@ -105,6 +105,41 @@ static int __init its_pmsi_init_one(struct fwnode_handle *fwnode,
return 0;
}
+#ifdef CONFIG_ACPI
+static int __init
+its_pmsi_parse_madt(struct acpi_subtable_header *header,
+ const unsigned long end)
+{
+ struct acpi_madt_generic_translator *its_entry;
+ struct fwnode_handle *domain_handle;
+ const char *node_name;
+ int err = -ENXIO;
+
+ its_entry = (struct acpi_madt_generic_translator *)header;
+ node_name = kasprintf(GFP_KERNEL, "ITS at 0x%lx",
+ (long)its_entry->base_address);
+ domain_handle = iort_find_domain_token(its_entry->translation_id);
+ if (!domain_handle) {
+ pr_err("%s: Unable to locate ITS domain handle\n", node_name);
+ goto out;
+ }
+
+ err = its_pmsi_init_one(domain_handle, node_name);
+
+out:
+ kfree(node_name);
+ return err;
+}
+
+static void __init its_acpi_pmsi_init(void)
+{
+ acpi_table_parse_madt(ACPI_MADT_TYPE_GENERIC_TRANSLATOR,
+ its_pmsi_parse_madt, 0);
+}
+#else
+static inline void its_acpi_pmsi_init(void) { }
+#endif
+
static void __init its_pmsi_of_init(void)
{
struct device_node *np;
@@ -121,6 +156,7 @@ static void __init its_pmsi_of_init(void)
static int __init its_pmsi_init(void)
{
its_pmsi_of_init();
+ its_acpi_pmsi_init();
return 0;
}
early_initcall(its_pmsi_init);
--
1.9.1
^ permalink raw reply related
* [PATCH v6 06/14] irqchip: gicv3-its: platform-msi: refactor its_pmsi_init() to prepare for ACPI
From: Hanjun Guo @ 2017-01-02 13:31 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1483363905-2806-1-git-send-email-hanjun.guo@linaro.org>
Introduce its_pmsi_init_one() to refactor the code to isolate
ACPI&DT common code to prepare for ACPI later.
Signed-off-by: Hanjun Guo <hanjun.guo@linaro.org>
Tested-by: Sinan Kaya <okaya@codeaurora.org>
Tested-by: Majun <majun258@huawei.com>
Tested-by: Xinwei Kong <kong.kongxinwei@hisilicon.com>
Cc: Marc Zyngier <marc.zyngier@arm.com>
Cc: Tomasz Nowicki <tn@semihalf.com>
Cc: Thomas Gleixner <tglx@linutronix.de>
---
drivers/irqchip/irq-gic-v3-its-platform-msi.c | 45 ++++++++++++++++-----------
1 file changed, 27 insertions(+), 18 deletions(-)
diff --git a/drivers/irqchip/irq-gic-v3-its-platform-msi.c b/drivers/irqchip/irq-gic-v3-its-platform-msi.c
index 16587a9..ff72704 100644
--- a/drivers/irqchip/irq-gic-v3-its-platform-msi.c
+++ b/drivers/irqchip/irq-gic-v3-its-platform-msi.c
@@ -84,34 +84,43 @@ static int its_pmsi_prepare(struct irq_domain *domain, struct device *dev,
{},
};
-static int __init its_pmsi_init(void)
+static int __init its_pmsi_init_one(struct fwnode_handle *fwnode,
+ const char *name)
{
- struct device_node *np;
struct irq_domain *parent;
+ parent = irq_find_matching_fwnode(fwnode, DOMAIN_BUS_NEXUS);
+ if (!parent || !msi_get_domain_info(parent)) {
+ pr_err("%s: unable to locate ITS domain\n", name);
+ return -ENXIO;
+ }
+
+ if (!platform_msi_create_irq_domain(fwnode, &its_pmsi_domain_info,
+ parent)) {
+ pr_err("%s: unable to create platform domain\n", name);
+ return -ENXIO;
+ }
+
+ pr_info("Platform MSI: %s domain created\n", name);
+ return 0;
+}
+
+static void __init its_pmsi_of_init(void)
+{
+ struct device_node *np;
+
for (np = of_find_matching_node(NULL, its_device_id); np;
np = of_find_matching_node(np, its_device_id)) {
if (!of_property_read_bool(np, "msi-controller"))
continue;
- parent = irq_find_matching_host(np, DOMAIN_BUS_NEXUS);
- if (!parent || !msi_get_domain_info(parent)) {
- pr_err("%s: unable to locate ITS domain\n",
- np->full_name);
- continue;
- }
-
- if (!platform_msi_create_irq_domain(of_node_to_fwnode(np),
- &its_pmsi_domain_info,
- parent)) {
- pr_err("%s: unable to create platform domain\n",
- np->full_name);
- continue;
- }
-
- pr_info("Platform MSI: %s domain created\n", np->full_name);
+ its_pmsi_init_one(of_node_to_fwnode(np), np->full_name);
}
+}
+static int __init its_pmsi_init(void)
+{
+ its_pmsi_of_init();
return 0;
}
early_initcall(its_pmsi_init);
--
1.9.1
^ permalink raw reply related
* [PATCH v6 05/14] ACPI: platform-msi: retrieve dev id from IORT
From: Hanjun Guo @ 2017-01-02 13:31 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1483363905-2806-1-git-send-email-hanjun.guo@linaro.org>
For devices connecting to ITS, it needs dev id to identify
itself, and this dev id is represented in the IORT table in
named componant node [1] for platform devices, so in this
patch we will scan the IORT to retrieve device's dev id.
Introduce iort_pmsi_get_dev_id() with pointer dev passed
in for that purpose.
[1]: https://static.docs.arm.com/den0049/b/DEN0049B_IO_Remapping_Table.pdf
Signed-off-by: Hanjun Guo <hanjun.guo@linaro.org>
Tested-by: Sinan Kaya <okaya@codeaurora.org>
Tested-by: Majun <majun258@huawei.com>
Tested-by: Xinwei Kong <kong.kongxinwei@hisilicon.com>
Cc: Marc Zyngier <marc.zyngier@arm.com>
Cc: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
Cc: Tomasz Nowicki <tn@semihalf.com>
Cc: Thomas Gleixner <tglx@linutronix.de>
---
drivers/acpi/arm64/iort.c | 26 ++++++++++++++++++++++++++
drivers/irqchip/irq-gic-v3-its-platform-msi.c | 4 +++-
include/linux/acpi_iort.h | 8 ++++++++
3 files changed, 37 insertions(+), 1 deletion(-)
diff --git a/drivers/acpi/arm64/iort.c b/drivers/acpi/arm64/iort.c
index 174e983..ab7bae7 100644
--- a/drivers/acpi/arm64/iort.c
+++ b/drivers/acpi/arm64/iort.c
@@ -444,6 +444,32 @@ u32 iort_msi_map_rid(struct device *dev, u32 req_id)
}
/**
+ * iort_pmsi_get_dev_id() - Get the device id for a device
+ * @dev: The device for which the mapping is to be done.
+ * @dev_id: The device ID found.
+ *
+ * Returns: 0 for successful find a dev id, errors otherwise
+ */
+int iort_pmsi_get_dev_id(struct device *dev, u32 *dev_id)
+{
+ struct acpi_iort_node *node;
+
+ if (!iort_table)
+ return -ENODEV;
+
+ node = iort_find_dev_node(dev);
+ if (!node) {
+ dev_err(dev, "can't find related IORT node\n");
+ return -ENODEV;
+ }
+
+ if(!iort_node_get_id(node, dev_id, IORT_MSI_TYPE, 0))
+ return -ENODEV;
+
+ return 0;
+}
+
+/**
* iort_dev_find_its_id() - Find the ITS identifier for a device
* @dev: The device.
* @req_id: Device's Requster ID
diff --git a/drivers/irqchip/irq-gic-v3-its-platform-msi.c b/drivers/irqchip/irq-gic-v3-its-platform-msi.c
index 3c94278..16587a9 100644
--- a/drivers/irqchip/irq-gic-v3-its-platform-msi.c
+++ b/drivers/irqchip/irq-gic-v3-its-platform-msi.c
@@ -15,6 +15,7 @@
* along with this program. If not, see <http://www.gnu.org/licenses/>.
*/
+#include <linux/acpi_iort.h>
#include <linux/device.h>
#include <linux/msi.h>
#include <linux/of.h>
@@ -56,7 +57,8 @@ static int its_pmsi_prepare(struct irq_domain *domain, struct device *dev,
msi_info = msi_get_domain_info(domain->parent);
- ret = of_pmsi_get_dev_id(domain, dev, &dev_id);
+ ret = dev->of_node ? of_pmsi_get_dev_id(domain, dev, &dev_id) :
+ iort_pmsi_get_dev_id(dev, &dev_id);
if (ret)
return ret;
diff --git a/include/linux/acpi_iort.h b/include/linux/acpi_iort.h
index 77e0809..ef99fd52 100644
--- a/include/linux/acpi_iort.h
+++ b/include/linux/acpi_iort.h
@@ -33,6 +33,7 @@
void acpi_iort_init(void);
bool iort_node_match(u8 type);
u32 iort_msi_map_rid(struct device *dev, u32 req_id);
+int iort_pmsi_get_dev_id(struct device *dev, u32 *dev_id);
struct irq_domain *iort_get_device_domain(struct device *dev, u32 req_id);
/* IOMMU interface */
void iort_set_dma_mask(struct device *dev);
@@ -42,9 +43,16 @@ static inline void acpi_iort_init(void) { }
static inline bool iort_node_match(u8 type) { return false; }
static inline u32 iort_msi_map_rid(struct device *dev, u32 req_id)
{ return req_id; }
+
static inline struct irq_domain *iort_get_device_domain(struct device *dev,
u32 req_id)
{ return NULL; }
+
+static inline int iort_pmsi_get_dev_id(struct device *dev, u32 *dev_id)
+{
+ return -ENODEV;
+}
+
/* IOMMU interface */
static inline void iort_set_dma_mask(struct device *dev) { }
static inline
--
1.9.1
^ permalink raw reply related
* [PATCH v6 04/14] irqchip: gicv3-its: platform-msi: refactor its_pmsi_prepare()
From: Hanjun Guo @ 2017-01-02 13:31 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1483363905-2806-1-git-send-email-hanjun.guo@linaro.org>
Adding ACPI support for platform MSI, we need to retrieve the
dev id in ACPI way instead of device tree, we already have
a well formed function its_pmsi_prepare() to get the dev id
but it's OF dependent, so collect OF related code and put them
into a single function to make its_pmsi_prepare() more friendly
to ACPI later.
Signed-off-by: Hanjun Guo <hanjun.guo@linaro.org>
Tested-by: Sinan Kaya <okaya@codeaurora.org>
Tested-by: Majun <majun258@huawei.com>
Tested-by: Xinwei Kong <kong.kongxinwei@hisilicon.com>
Cc: Marc Zyngier <marc.zyngier@arm.com>
Cc: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
Cc: Tomasz Nowicki <tn@semihalf.com>
Cc: Thomas Gleixner <tglx@linutronix.de>
---
drivers/irqchip/irq-gic-v3-its-platform-msi.c | 23 ++++++++++++++++-------
1 file changed, 16 insertions(+), 7 deletions(-)
diff --git a/drivers/irqchip/irq-gic-v3-its-platform-msi.c b/drivers/irqchip/irq-gic-v3-its-platform-msi.c
index 470b4aa..3c94278 100644
--- a/drivers/irqchip/irq-gic-v3-its-platform-msi.c
+++ b/drivers/irqchip/irq-gic-v3-its-platform-msi.c
@@ -24,15 +24,11 @@
.name = "ITS-pMSI",
};
-static int its_pmsi_prepare(struct irq_domain *domain, struct device *dev,
- int nvec, msi_alloc_info_t *info)
+static int of_pmsi_get_dev_id(struct irq_domain *domain, struct device *dev,
+ u32 *dev_id)
{
- struct msi_domain_info *msi_info;
- u32 dev_id;
int ret, index = 0;
- msi_info = msi_get_domain_info(domain->parent);
-
/* Suck the DeviceID out of the msi-parent property */
do {
struct of_phandle_args args;
@@ -43,11 +39,24 @@ static int its_pmsi_prepare(struct irq_domain *domain, struct device *dev,
if (args.np == irq_domain_get_of_node(domain)) {
if (WARN_ON(args.args_count != 1))
return -EINVAL;
- dev_id = args.args[0];
+ *dev_id = args.args[0];
break;
}
} while (!ret);
+ return ret;
+}
+
+static int its_pmsi_prepare(struct irq_domain *domain, struct device *dev,
+ int nvec, msi_alloc_info_t *info)
+{
+ struct msi_domain_info *msi_info;
+ u32 dev_id;
+ int ret;
+
+ msi_info = msi_get_domain_info(domain->parent);
+
+ ret = of_pmsi_get_dev_id(domain, dev, &dev_id);
if (ret)
return ret;
--
1.9.1
^ permalink raw reply related
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