* [PATCH v11 00/14] Add support for FDMA DMA controller and slim core rproc found on STi chipsets
From: Vinod Koul @ 2016-11-14 5:19 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1478542665-17089-1-git-send-email-peter.griffin@linaro.org>
On Mon, Nov 07, 2016 at 06:17:31PM +0000, Peter Griffin wrote:
> Hi Vinod and Bjorn,
>
> This patchset adds support for the Flexible Direct Memory Access (FDMA) core
> found on STi chipsets from STMicroelectronics. The FDMA is a slim core CPU
> with a dedicated firmware. It is a general purpose DMA controller supporting
> 16 independent channels and data can be moved from memory to memory or between
> memory and paced latency critical real time targets.
>
> In reponse to Bjorn latest mail here https://lkml.org/lkml/2016/11/7/425 and
> here https://patchwork.kernel.org/patch/9368157/ I have created a v11
> incorporating the minor API update, and removed the unrelated change.
>
> As tthis series has been in linux-next for a while, some additional fixes
> have been submitted and applied by Vinod. I have included these as part of
> the v11 series as well.
>
> I believe the best route as described here
> https://www.spinics.net/lists/arm-kernel/msg541026.htmlforward is for Vinod
> to apply the whole series on an immutable branch which is then merged into
> both the dma and remoteproc trees.
As I said earlier and just to make it clear, am not taking this one. Please
send updates on top of already applied stuff
--
~Vinod
^ permalink raw reply
* [PATCH v3 1/3] Documentation: DT: add dma compatible for sun50i A64 SOC.
From: Vinod Koul @ 2016-11-14 5:22 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161107181457.GA3619@arx12>
On Tue, Nov 08, 2016 at 02:14:57AM +0800, Hao Zhang wrote:
> This adds documentation of the sun50i a64 dma binding compatible.
Please send a cover letter for patch series, and please post the series as a
thread (hint: git send-email does that quite well).
Lastly where is patch2/3??
--
~Vinod
^ permalink raw reply
* [PATCH V4] ARM: dts: imx6: Add support for Logic PD SOM and Baseboard
From: Shawn Guo @ 2016-11-14 5:27 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1478609017-2415-1-git-send-email-aford173@gmail.com>
On Tue, Nov 08, 2016 at 06:43:37AM -0600, aford173 at gmail.com wrote:
> From: Adam Ford <aford173@gmail.com>
>
> The system on module (SOM) specific portions are in the .dtsi
> while the baseboard specific portions are in the .dts file.
>
> V4: Forgot to fix the Wlcore property list and child node
> V3: Forgot to remove push buttons in V2, and change the
> enable-sdio-wakup to wakeup-source
> V2: Fix small bug and update style for 4.9 Kernel
>
> Signed-off-by: Adam Ford <aford173@gmail.com>
<snip>
> + leds {
> + compatible = "gpio-leds";
> +
> + gen_led0 {
Please use hyphen instead of underscore in node name.
> + label = "cpu0";
> + gpios = <&gpio3 19 GPIO_ACTIVE_HIGH>;
> + linux,default-trigger = "cpu0";
> + };
> +
> + gen_led1 {
> + label = "cpu1";
> + gpios = <&gpio3 20 GPIO_ACTIVE_HIGH>;
> + linux,default-trigger = "cpu1";
> + };
> +
> + gen_led2 {
> + label = "heartbeat";
> + gpios = <&gpio3 21 GPIO_ACTIVE_HIGH>;
> + linux,default-trigger = "heartbeat";
> + };
> +
> + gen_led3 {
> + label = "Always On";
> + gpios = <&gpio3 22 GPIO_ACTIVE_HIGH>;
> + linux,default-trigger = "default-on";
> + };
> + };
<snip>
> + backlight_lcd: backlight-lcd {
> + compatible = "pwm-backlight";
> + pinctrl-names = "default";
> + pinctrl-0 = <&pinctrl_backlight>;
> + enable-gpios = <&gpio2 10 GPIO_ACTIVE_HIGH>;
> + pwms = <&pwm3 0 5000000>;
> + brightness-levels = <0 4 8 16 32 64 128 255>;
> + default-brightness-level = <6>;
> + };
> +
> +
One newline is enough.
> + lcd_display: display at di0 {
> + compatible = "fsl,imx-parallel-display";
> + #address-cells = <1>;
> + #size-cells = <0>;
> + interface-pix-fmt = "rgb565";
> + pinctrl-names = "default";
> + pinctrl-0 = <&pinctrl_lcd>;
> + status = "okay";
> +
> + display-timings {
> + native-mode = <&type15_timing>;
Have a newline between property list and child node.
> + type15_timing: type_15 {
Can we have a better node name for this? Also hyphen should be used in
node name.
> + clock-frequency = <9000000>;
> + hactive = <480>;
> + vactive = <272>;
> + hfront-porch = <3>;
> + hback-porch = <2>;
> + hsync-len = <42>;
> + vback-porch = <3>;
> + vfront-porch = <2>;
> + vsync-len = <11>;
> + hsync-active = <1>;
> + vsync-active = <1>;
> + de-active = <1>;
> + pixelclk-active = <0>;
> + };
> + };
> +
> + port at 0 {
> + reg = <0>;
> + display_in: endpoint {
> + remote-endpoint = <&ipu1_di0_disp0>;
> + };
> + };
> +
> + port at 1 {
> + reg = <1>;
> + display_out: endpoint {
> + remote-endpoint = <&panel_in>;
> + };
> + };
> + };
> +
> + panel: panel {
> + compatible = "innolux,at043tn24", "simple-panel";
> + enable-gpios = <&gpio4 17 GPIO_ACTIVE_HIGH>;
> + backlight = <&backlight_lcd>;
Have a newline between property list and child node.
> + port {
> + panel_in: endpoint {
> + remote-endpoint = <&display_out>;
> + };
> + };
> + };
> +};
> +
> +&ipu1_di0_disp0 {
> + remote-endpoint = <&display_in>;
> +};
> +
> +&pwm3 {
> + pinctrl-names = "default";
> + pinctrl-0 = <&pinctrl_pwm3>;
> + status = "okay";
> +};
> +
> +
Drop one newline.
> +&uart3 {
> + pinctrl-names = "default";
> + pinctrl-0 = <&pinctrl_uart3>;
> + status = "okay";
> +};
> +
> +&usbh1 {
> + pinctrl-names = "default";
> + pinctrl-0 = <&pinctrl_usbh1>;
> + vbus-supply = <®_usb_h1_vbus>;
> + status = "okay";
> +};
> +
> +&usbh2 {
> + pinctrl-names = "default";
> + pinctrl-0 = <&pinctrl_usbh2>;
> + phy_type = "hsic";
> + disable-over-current;
> + status = "okay";
> +};
> +
> +&usbotg {
> + vbus-supply = <®_usb_otg_vbus>;
> + pinctrl-names = "default";
> + pinctrl-0 = <&pinctrl_usbotg>;
> + disable-over-current;
> + status = "okay";
> +};
> +
> +&fec {
Please sort these labeled nodes alphabetically. The iomuxc can be an
exception, and we usually put it at the end of file to make the rest
easy to read.
> + pinctrl-names = "default";
> + pinctrl-0 = <&pinctrl_enet>;
> + phy-mode = "rmii";
> + status = "okay";
> +};
> +
> +&usdhc2 {
> + pinctrl-names = "default";
> + pinctrl-0 = <&pinctrl_usdhc2>;
> + cd-gpios = <&gpio1 4 GPIO_ACTIVE_LOW>;
> + no-1-8-v;
> + keep-power-in-suspend;
> + status = "okay";
> +};
> +
> +&i2c3 {
> + touchscreen: tsc2004 at 48 {
> + compatible = "ti,tsc2004";
> + vio-supply = <®_3v3>;
> + reg = <0x48>;
> + pinctrl-names = "default";
> + pinctrl-0 = <&pinctrl_touchscreen>;
> + reset-gpios = <&gpio4 10 GPIO_ACTIVE_HIGH>;
> + interrupts-extended = <&gpio1 6 IRQ_TYPE_EDGE_RISING>;
> + touchscreen-fuzz-x = <4>;
> + touchscreen-fuzz-y = <7>;
> + touchscreen-fuzz-pressure = <2>;
> + touchscreen-size-x = <4096>;
> + touchscreen-size-y = <4096>;
> + touchscreen-max-pressure = <2048>;
> + ti,x-plate-ohms = <280>;
> + ti,esd-recovery-timeout-ms = <8000>;
> + };
> +};
> +
> +&pcie {
> + pinctrl-names = "default";
> + pinctrl-0 = <&pinctrl_pcie>;
> + reset-gpio = <&gpio1 9 GPIO_ACTIVE_LOW>;
> + status = "okay";
> +};
> +
> +&iomuxc {
> + pinctrl_uart3: uart3grp {
> + fsl,pins = <
> + MX6QDL_PAD_EIM_D23__UART3_CTS_B 0x1b0b1
> + MX6QDL_PAD_EIM_D24__UART3_TX_DATA 0x1b0b1
> + MX6QDL_PAD_EIM_D25__UART3_RX_DATA 0x1b0b1
> + MX6QDL_PAD_EIM_EB3__UART3_RTS_B 0x1b0b1
> + >;
> + };
> +
> + pinctrl_usbotg: usbotggrp {
> + fsl,pins = <
> + MX6QDL_PAD_GPIO_1__USB_OTG_ID 0x17059
> + MX6QDL_PAD_KEY_ROW4__GPIO4_IO15 0x130b0
> + >;
Bad indentation.
> + };
> +
> + pinctrl_usbh1: usbh1grp {
> + fsl,pins = <
> + MX6QDL_PAD_GPIO_0__GPIO1_IO00 0x1b0b0
> + >;
> + };
> +
> + pinctrl_usbh2: usbh2grp {
> + fsl,pins = <
> + MX6QDL_PAD_RGMII_TXC__USB_H2_DATA 0x13030
> + MX6QDL_PAD_RGMII_TX_CTL__USB_H2_STROBE 0x17030
> + >;
> + };
> +
> + 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_enet: enetgrp {
Please sort these pinctrl entries alphabetically.
> + fsl,pins = <
> + MX6QDL_PAD_ENET_MDIO__ENET_MDIO 0x1b0b0
> + MX6QDL_PAD_ENET_MDC__ENET_MDC 0x1b0b0
> + MX6QDL_PAD_ENET_CRS_DV__ENET_RX_EN 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_RX_ER__ENET_RX_ER 0x1b0b0
> + MX6QDL_PAD_ENET_RXD0__ENET_RX_DATA0 0x1b0b0
> + MX6QDL_PAD_ENET_RXD1__ENET_RX_DATA1 0x1b0b0
> + MX6QDL_PAD_GPIO_16__ENET_REF_CLK 0x4001b0a8
> + MX6QDL_PAD_KEY_ROW1__GPIO4_IO09 0x1b0b0
> + >;
> + };
> +
> + pinctrl_gpio_leds: gpioledsgrp {
> + fsl,pins = <
> + MX6QDL_PAD_EIM_D19__GPIO3_IO19 0x130b0
> + MX6QDL_PAD_EIM_D20__GPIO3_IO20 0x130b0
> + MX6QDL_PAD_EIM_D21__GPIO3_IO21 0x130b0
> + MX6QDL_PAD_EIM_D22__GPIO3_IO22 0x130b0
> + >;
> + };
> +
> + pinctrl_gpio_keys: gpio_keysgrp {
> + fsl,pins = <
> + MX6QDL_PAD_EIM_D28__GPIO3_IO28 0x1b0b0
> + MX6QDL_PAD_EIM_D29__GPIO3_IO29 0x1b0b0
> + MX6QDL_PAD_EIM_D30__GPIO3_IO30 0x1b0b0
> + MX6QDL_PAD_EIM_D31__GPIO3_IO31 0x1b0b0
> + >;
> + };
> +
> + pinctrl_touchscreen: touchscreengrp {
> + fsl,pins = <
> + MX6QDL_PAD_KEY_COL2__GPIO4_IO10 0x1b0b0
> + MX6QDL_PAD_GPIO_6__GPIO1_IO06 0x1b0b0
> + >;
> + };
> +
> + pinctrl_pcie_reg: pciereggrp {
> + fsl,pins = <
> + MX6QDL_PAD_GPIO_2__GPIO1_IO02 0x1b0b0
> + >;
> + };
> +
> + pinctrl_pcie: pciegrp {
> + fsl,pins = <
> + MX6QDL_PAD_GPIO_7__GPIO1_IO07 0x1b0b0
> + MX6QDL_PAD_GPIO_8__GPIO1_IO08 0x1b0b0
> + MX6QDL_PAD_GPIO_9__GPIO1_IO09 0x1b0b0
> + >;
> + };
> +
> + pinctrl_lcd: lcdgrp {
> + fsl,pins = <
> + MX6QDL_PAD_DI0_DISP_CLK__IPU1_DI0_DISP_CLK 0x10
> + MX6QDL_PAD_DI0_PIN15__GPIO4_IO17 0x100b0
> + MX6QDL_PAD_DI0_PIN2__IPU1_DI0_PIN02 0x10
> + MX6QDL_PAD_DI0_PIN3__IPU1_DI0_PIN03 0x10
> + MX6QDL_PAD_DI0_PIN4__IPU1_DI0_PIN04 0x10
> + MX6QDL_PAD_DISP0_DAT1__IPU1_DISP0_DATA01 0x10
> + MX6QDL_PAD_DISP0_DAT2__IPU1_DISP0_DATA02 0x10
> + MX6QDL_PAD_DISP0_DAT3__IPU1_DISP0_DATA03 0x10
> + MX6QDL_PAD_DISP0_DAT4__IPU1_DISP0_DATA04 0x10
> + MX6QDL_PAD_DISP0_DAT5__IPU1_DISP0_DATA05 0x10
> + MX6QDL_PAD_DISP0_DAT6__IPU1_DISP0_DATA06 0x10
> + MX6QDL_PAD_DISP0_DAT7__IPU1_DISP0_DATA07 0x10
> + MX6QDL_PAD_DISP0_DAT8__IPU1_DISP0_DATA08 0x10
> + MX6QDL_PAD_DISP0_DAT9__IPU1_DISP0_DATA09 0x10
> + MX6QDL_PAD_DISP0_DAT10__IPU1_DISP0_DATA10 0x10
> + MX6QDL_PAD_DISP0_DAT11__IPU1_DISP0_DATA11 0x10
> + MX6QDL_PAD_DISP0_DAT12__IPU1_DISP0_DATA12 0x10
> + MX6QDL_PAD_DISP0_DAT13__IPU1_DISP0_DATA13 0x10
> + MX6QDL_PAD_DISP0_DAT14__IPU1_DISP0_DATA14 0x10
> + MX6QDL_PAD_DISP0_DAT15__IPU1_DISP0_DATA15 0x10
> + MX6QDL_PAD_DISP0_DAT16__IPU1_DISP0_DATA16 0x10
> + >;
> + };
> +
> + pinctrl_backlight: backlightgrp {
> + fsl,pins = <
> + MX6QDL_PAD_SD4_DAT2__GPIO2_IO10 0x100b0
> + >;
Fix whitespace.
> + };
> +
> + pinctrl_pwm3: pwm3grp {
> + fsl,pins = <
> + MX6QDL_PAD_SD4_DAT1__PWM3_OUT 0x1b0b1
> + >;
> + };
> +};
> +
> +
Drop the end-of-file newlines.
> diff --git a/arch/arm/boot/dts/imx6qdl-logicpd.dtsi b/arch/arm/boot/dts/imx6qdl-logicpd.dtsi
> new file mode 100644
> index 0000000..ca266a3
> --- /dev/null
> +++ b/arch/arm/boot/dts/imx6qdl-logicpd.dtsi
> @@ -0,0 +1,331 @@
> +/*
> + * Copyright 2016 Logic PD
> + * This file is adapted from imx6qdl-sabresd.dtsi.
> + * Copyright 2012 Freescale Semiconductor, Inc.
> + * Copyright 2011 Linaro Ltd.
> + *
> + * The code contained herein is licensed under the GNU General Public
> + * License. You may obtain a copy of the GNU General Public License
> + * Version 2 or later at the following locations:
> + *
> + * http://www.opensource.org/licenses/gpl-license.html
> + * http://www.gnu.org/copyleft/gpl.html
> + */
Please consider to use GPL/X11 dual licence for all new dts files.
> +
> +#include <dt-bindings/gpio/gpio.h>
> +#include <dt-bindings/input/input.h>
> +#include "imx6q.dtsi"
> +
> +/ {
> + chosen {
> + stdout-path = &uart1;
> + };
> +
> + memory {
> + reg = <0x10000000 0x80000000>;
> + };
> +
> +
Unneeded newlines.
> +};
> +
> +/* Reroute power feeding the CPU to come from the external PMIC */
> +&cpu0 {
> + arm-supply = <&sw1a_reg>;
> + soc-supply = <&sw1c_reg>;
> +};
> +
> +®_arm
> +{
®_arm {
> + vin-supply = <&sw1a_reg>;
> +};
> +
> +®_soc
> +{
Ditto
> + vin-supply = <&sw1c_reg>;
> +};
> +
> +&clks {
> + assigned-clocks = <&clks IMX6QDL_CLK_LDB_DI0_SEL>,
> + <&clks IMX6QDL_CLK_LDB_DI1_SEL>;
> + assigned-clock-parents = <&clks IMX6QDL_CLK_PLL3_USB_OTG>,
> + <&clks IMX6QDL_CLK_PLL3_USB_OTG>;
> +};
> +
> +&gpmi {
> + pinctrl-names = "default";
> + pinctrl-0 = <&pinctrl_gpmi_nand>;
> + status = "okay";
> +};
> +
> +&i2c3 {
> + clock-frequency = <100000>;
> + pinctrl-names = "default";
> + pinctrl-0 = <&pinctrl_i2c3>;
> + status = "okay";
> +
> + pmic: pfuze100 at 08 {
> + compatible = "fsl,pfuze100";
> + reg = <0x08>;
> +
> + regulators {
> + sw1a_reg: sw1ab {
> + regulator-min-microvolt = <725000>;
> + regulator-max-microvolt = <1450000>;
> + regulator-name = "vddcore";
> + regulator-boot-on;
> + regulator-always-on;
> + regulator-ramp-delay = <6250>;
> + };
> +
> + sw1c_reg: sw1c {
> + regulator-min-microvolt = <725000>;
> + regulator-max-microvolt = <1450000>;
> + regulator-name = "vddsoc";
> + regulator-boot-on;
> + regulator-always-on;
> + regulator-ramp-delay = <6250>;
> + };
> +
> + sw2_reg: sw2 {
> + regulator-min-microvolt = <3300000>;
> + regulator-max-microvolt = <3300000>;
> + regulator-name = "gen_3v3";
> + regulator-boot-on;
> + regulator-always-on;
> + };
> +
> + sw3a_reg: sw3a {
> + regulator-min-microvolt = <400000>;
> + regulator-max-microvolt = <1975000>;
> + regulator-name = "sw3a_vddr";
> + regulator-boot-on;
> + regulator-always-on;
> + };
> +
> + sw3b_reg: sw3b {
> + regulator-min-microvolt = <400000>;
> + regulator-max-microvolt = <1975000>;
> + regulator-name = "sw3b_vddr";
> + regulator-boot-on;
> + regulator-always-on;
> + };
> +
> + sw4_reg: sw4 {
> + regulator-min-microvolt = <800000>;
> + regulator-max-microvolt = <3300000>;
> + regulator-name = "gen_rgmii";
> + };
> +
> + swbst_reg: swbst {
> + regulator-min-microvolt = <5000000>;
> + regulator-max-microvolt = <5150000>;
> + regulator-name = "gen_5v0";
> + };
> +
> +
Drop one newline.
> + snvs_reg: vsnvs {
> + regulator-min-microvolt = <1000000>;
> + regulator-max-microvolt = <3000000>;
> + regulator-name = "gen_vsns";
> + regulator-boot-on;
> + regulator-always-on;
> + };
> +
> + vref_reg: vrefddr {
> + regulator-boot-on;
> + regulator-always-on;
> + };
> +
> + vgen1_reg: vgen1 {
> + regulator-min-microvolt = <1500000>;
> + regulator-max-microvolt = <1500000>;
> + regulator-name = "gen_1v5";
> + };
> +
> + vgen2_reg: vgen2 {
> + regulator-name = "vgen2";
> + regulator-min-microvolt = <800000>;
> + regulator-max-microvolt = <1550000>;
> + };
> +
> + vgen3_reg: vgen3 {
> + regulator-name = "gen_vadj_0";
> + regulator-min-microvolt = <3000000>;
> + regulator-max-microvolt = <3000000>;
> + };
> +
> + vgen4_reg: vgen4 {
> + regulator-name = "gen_1v8";
> + regulator-min-microvolt = <1800000>;
> + regulator-max-microvolt = <1800000>;
> + regulator-always-on;
> + };
> +
> + vgen5_reg: vgen5 {
> + regulator-name = "gen_adj_1";
> + regulator-min-microvolt = <3300000>;
> + regulator-max-microvolt = <3300000>;
> + regulator-always-on;
> + };
> +
> + vgen6_reg: vgen6 {
> + regulator-name = "gen_2v5";
> + regulator-min-microvolt = <2500000>;
> + regulator-max-microvolt = <2500000>;
> + regulator-always-on;
> + };
> + };
> + };
> +
> + temp_sense1: tmp102 at 49 {
> + compatible = "ti,tmp102";
> + reg = <0x49>;
> + pinctrl-names = "default";
> + pinctrl-0 = <&pinctrl_tempsense>;
> + interrupt-parent = <&gpio6>;
> + interrupts = <15 IRQ_TYPE_LEVEL_LOW>;
> + #thermal-sensor-cells = <1>;
> + };
> +
> + temp_sense0: tmp102 at 4a {
> + compatible = "ti,tmp102";
> + reg = <0x4a>;
> + interrupt-parent = <&gpio6>;
> + interrupts = <15 IRQ_TYPE_LEVEL_LOW>;
> + #thermal-sensor-cells = <1>;
> + };
> +
> + user_eeprom: at24 at 52 {
> + compatible = "atmel,24c64";
> + pagesize = <32>;
> + reg = <0x52>;
> + };
> +
> + mfg_eeprom: at24 at 51 {
> + compatible = "atmel,24c64";
> + pagesize = <32>;
> + read-only;
> + reg = <0x51>;
> + };
> +};
> +
> +&iomuxc {
> + pinctrl_gpmi_nand: gpminandgrp {
> + fsl,pins = <
> + MX6QDL_PAD_NANDF_CLE__NAND_CLE 0x0b0b1
> + MX6QDL_PAD_NANDF_ALE__NAND_ALE 0x0b0b1
> + MX6QDL_PAD_NANDF_WP_B__NAND_WP_B 0x0b0b1
> + MX6QDL_PAD_NANDF_RB0__NAND_READY_B 0x0b000
> + MX6QDL_PAD_NANDF_CS0__NAND_CE0_B 0x0b0b1
> + MX6QDL_PAD_SD4_CMD__NAND_RE_B 0x0b0b1
> + MX6QDL_PAD_SD4_CLK__NAND_WE_B 0x0b0b1
> + MX6QDL_PAD_NANDF_D0__NAND_DATA00 0x0b0b1
> + MX6QDL_PAD_NANDF_D1__NAND_DATA01 0x0b0b1
> + MX6QDL_PAD_NANDF_D2__NAND_DATA02 0x0b0b1
> + MX6QDL_PAD_NANDF_D3__NAND_DATA03 0x0b0b1
> + MX6QDL_PAD_NANDF_D4__NAND_DATA04 0x0b0b1
> + MX6QDL_PAD_NANDF_D5__NAND_DATA05 0x0b0b1
> + MX6QDL_PAD_NANDF_D6__NAND_DATA06 0x0b0b1
> + MX6QDL_PAD_NANDF_D7__NAND_DATA07 0x0b0b1
> + >;
> + };
> +
> + pinctrl_i2c3: i2c3grp {
> + fsl,pins = <
> + MX6QDL_PAD_EIM_D17__I2C3_SCL 0x4001b8b1
> + MX6QDL_PAD_EIM_D18__I2C3_SDA 0x4001b8b1
> + >;
> + };
> +
> + pinctrl_uart1: uart1grp {
> + fsl,pins = <
> + MX6QDL_PAD_SD3_DAT6__UART1_RX_DATA 0x1b0b1
> + MX6QDL_PAD_SD3_DAT7__UART1_TX_DATA 0x1b0b1
> + >;
> + };
> +
> + pinctrl_uart2: uart2grp {
> + fsl,pins = <
> + MX6QDL_PAD_SD4_DAT4__UART2_RX_DATA 0x1b0b1
> + MX6QDL_PAD_SD4_DAT5__UART2_RTS_B 0x1b0b1
> + MX6QDL_PAD_SD4_DAT6__UART2_CTS_B 0x1b0b1
> + MX6QDL_PAD_SD4_DAT7__UART2_TX_DATA 0x1b0b1
> + >;
> + };
> +
> + 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_RST__GPIO7_IO08 0x1f0b0
> + 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__GPIO7_IO01 0x1f0b0
> + MX6QDL_PAD_SD3_DAT5__GPIO7_IO00 0x1f0b0
> + >;
> + };
> +
> + pinctrl_tempsense: tempsensegrp {
> + fsl,pins = <
> + MX6QDL_PAD_NANDF_CS2__GPIO6_IO15 0x1b0b0
> + >;
> + };
> +};
> +
> +&snvs_poweroff {
> + status = "okay";
> +};
> +
> +&uart1 {
> + pinctrl-names = "default";
> + pinctrl-0 = <&pinctrl_uart1>;
> + status = "okay";
> +};
> +
> +&uart2 {
> + pinctrl-names = "default";
> + pinctrl-0 = <&pinctrl_uart2>;
> + status = "okay";
> +};
> +
> +&usdhc1 {
> + pinctrl-names = "default";
> + pinctrl-0 = <&pinctrl_usdhc1>;
> + cd-gpios = <&gpio6 16 GPIO_ACTIVE_HIGH>;
> + keep-power-in-suspend;
> + wakeup-source;
> + status = "okay";
> +};
> +
> +&usdhc3 {
> + pinctrl-names = "default";
> + pinctrl-0 = <&pinctrl_usdhc3>;
> + non-removable;
> + keep-power-in-suspend;
> + wakeup-source;
> + vmmc-supply = <&sw2_reg>;
> + status = "okay";
> + #address-cells = <1>;
> + #size-cells = <0>;
Have a newline between property list and child node.
> + wlcore: wlcore at 0 {
> + compatible = "ti,wl1837";
> + reg = <0>;
> + interrupt-parent = <&gpio7>;
> + interrupts = <1 GPIO_ACTIVE_HIGH>;
> + };
> +};
Shawn
^ permalink raw reply
* [PATCH] input: bma150: Only claim to support the bma180 if the separate iio bma180 driver is not build
From: Dmitry Torokhov @ 2016-11-14 5:35 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161113183407.12848-1-hdegoede@redhat.com>
Hi Hans,
On Sun, Nov 13, 2016 at 07:34:07PM +0100, Hans de Goede wrote:
> commit ef3714fdbc8d ("Input: bma150 - extend chip detection for bma180"),
> adds bma180 chip-ids to the input bma150 driver, assuming that they are
> 100% compatible, but the bma180 is not compatible with the bma150 at all,
> it has 14 bits resolution instead of 10, and it has quite different
> control registers too.
>
> Treating the bma180 as a bma150 wrt its data registers will just result
> in throwing away the lowest 4 bits, which is not too bad. But the ctrl
> registers are a different story. Things happen to just work but supporting
> that certainly does not make treating the bma180 the same as the bma150
> right.
>
> Since some setups depend on the evdev interface the bma150 driver offers
> on top of the bma180, we cannot simply remove the bma180 ids.
>
> So this commit only removes the bma180 id when the bma180 iio driver,
> which does treat the bma180 properly, is enabled.
>
> Cc: Dr. H. Nikolaus Schaller <hns@goldelico.com>
> Signed-off-by: Hans de Goede <hdegoede@redhat.com>
> ---
> drivers/input/misc/bma150.c | 8 +++++++-
> 1 file changed, 7 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/input/misc/bma150.c b/drivers/input/misc/bma150.c
> index b0d4453..9fa1c9a 100644
> --- a/drivers/input/misc/bma150.c
> +++ b/drivers/input/misc/bma150.c
> @@ -539,7 +539,11 @@ static int bma150_probe(struct i2c_client *client,
> }
>
> chip_id = i2c_smbus_read_byte_data(client, BMA150_CHIP_ID_REG);
> - if (chip_id != BMA150_CHIP_ID && chip_id != BMA180_CHIP_ID) {
> + if (chip_id != BMA150_CHIP_ID
> +#ifndef CONFIG_BMA180
> + && chip_id != BMA180_CHIP_ID
> +#endif
Does not this break if bma180 is compiled as module? I'd rather we did
if (chip_id != BMA150_CHIP_ID &&
(IS_ENABLED(CONFIG_BMA180) || chip_id != BMA180_CHIP_ID)) {
...
> + ) {
> dev_err(&client->dev, "BMA150 chip id error: %d\n", chip_id);
> return -EINVAL;
> }
> @@ -643,7 +647,9 @@ static UNIVERSAL_DEV_PM_OPS(bma150_pm, bma150_suspend, bma150_resume, NULL);
>
> static const struct i2c_device_id bma150_id[] = {
> { "bma150", 0 },
> +#ifndef CONFIG_BMA180
#if !IS_ENABLED(CONFIG_BMA180)
> { "bma180", 0 },
> +#endif
> { "smb380", 0 },
> { "bma023", 0 },
> { }
> --
> 2.9.3
>
Thanks.
--
Dmitry
^ permalink raw reply
* [PATCH V3 1/2] ARM: imx: mmdc perf function support i.MX6QP
From: Shawn Guo @ 2016-11-14 5:36 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1478539849-10834-1-git-send-email-Frank.Li@nxp.com>
On Mon, Nov 07, 2016 at 11:30:48AM -0600, Frank Li wrote:
> i.MX6QP added new register bit PROFILE_SEL in MADPCR0.
> need set it at perf start.
>
> Signed-off-by: Frank Li <Frank.Li@nxp.com>
Applied, thanks.
^ permalink raw reply
* [PATCH V3 2/2] ARM: dts: add new compatible stream for i.MX6QP mmdc
From: Shawn Guo @ 2016-11-14 5:37 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1478539849-10834-2-git-send-email-Frank.Li@nxp.com>
On Mon, Nov 07, 2016 at 11:30:49AM -0600, Frank Li wrote:
> MMDC has a slightly different programming model between imx6q and imx6qp
> in terms of perf support, it's exactly same for suspend support, so we
> have fsl,imx6q-mmdc here to save patching suspend driver with the new
> compatible.
>
> Signed-off-by: Frank Li <Frank.Li@nxp.com>
s/stream/string in subject.
I fixed it up and applied the patch.
Shawn
^ permalink raw reply
* [PATCH v2 1/3] ARM: imx6ull: add imx6ull support
From: Shawn Guo @ 2016-11-14 5:48 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1478584614-12054-2-git-send-email-peter.chen@nxp.com>
On Tue, Nov 08, 2016 at 01:56:52PM +0800, Peter Chen wrote:
> It is the 10th processor in the well-known imx6 series, and derived
> from imx6ul but cost optimized. The more information about imx6ull
> can be found at:
>
> http://www.nxp.com/products/microcontrollers-and-processors/
> arm-processors/i.mx-applications-processors/i.mx-6-processors
> /i.mx6qp/i.mx-6ull-single-core-processor-with-arm-cortex-a7-core
> :i.MX6ULL
>
> In this patch, for SoC part, the imx6ull.dtsi includes imx6ul.dtsi;
> for board part (imx6ul/imx6ull 14x14 evk), it has a common board
> file imx6u-14x14-evk.dtsi, and this file is included by both
> imx6ul-14x14-evk.dts and imx6ull-14x14-evk.dts.
>
> Signed-off-by: Peter Chen <peter.chen@nxp.com>
> ---
> arch/arm/boot/dts/Makefile | 3 +-
> arch/arm/boot/dts/imx6u-14x14-evk.dtsi | 487 ++++++++++++++++++++++++++++++++
> arch/arm/boot/dts/imx6ul-14x14-evk.dts | 479 +------------------------------
What's the real change between imx6u-14x14-evk.dtsi and
imx6ul-14x14-evk.dts? Instead of renaming the file, I would like to
have imx6ull-14x14-evk.dts include imx6ul-14x14-evk.dts directly, if we
can work out the difference within imx6ull-14x14-evk.dts.
Shawn
> arch/arm/boot/dts/imx6ull-14x14-evk.dts | 55 ++++
> arch/arm/boot/dts/imx6ull-pinfunc.h | 56 ++++
> arch/arm/boot/dts/imx6ull.dtsi | 43 +++
> 6 files changed, 644 insertions(+), 479 deletions(-)
> create mode 100644 arch/arm/boot/dts/imx6u-14x14-evk.dtsi
> create mode 100644 arch/arm/boot/dts/imx6ull-14x14-evk.dts
> create mode 100644 arch/arm/boot/dts/imx6ull-pinfunc.h
> create mode 100644 arch/arm/boot/dts/imx6ull.dtsi
^ permalink raw reply
* [PATCH v27 1/9] memblock: add memblock_cap_memory_range()
From: AKASHI Takahiro @ 2016-11-14 5:55 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161111031903.GB15997@arm.com>
On Fri, Nov 11, 2016 at 11:19:04AM +0800, Dennis Chen wrote:
> On Fri, Nov 11, 2016 at 11:50:50AM +0900, AKASHI Takahiro wrote:
> > Will,
> > (+ Cc: Dennis)
> >
> > On Thu, Nov 10, 2016 at 05:27:20PM +0000, Will Deacon wrote:
> > > On Wed, Nov 02, 2016 at 01:51:53PM +0900, AKASHI Takahiro wrote:
> > > > Add memblock_cap_memory_range() which will remove all the memblock regions
> > > > except the range specified in the arguments.
> > > >
> > > > This function, like memblock_mem_limit_remove_map(), will not remove
> > > > memblocks with MEMMAP_NOMAP attribute as they may be mapped and accessed
> > > > later as "device memory."
> > > > See the commit a571d4eb55d8 ("mm/memblock.c: add new infrastructure to
> > > > address the mem limit issue").
> > > >
> > > > This function is used, in a succeeding patch in the series of arm64 kdump
> > > > suuport, to limit the range of usable memory, System RAM, on crash dump
> > > > kernel.
> > > > (Please note that "mem=" parameter is of little use for this purpose.)
> > > >
> > > > Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
> > > > Cc: linux-mm at kvack.org
> > > > Cc: Andrew Morton <akpm@linux-foundation.org>
> > > > ---
> > > > include/linux/memblock.h | 1 +
> > > > mm/memblock.c | 28 ++++++++++++++++++++++++++++
> > > > 2 files changed, 29 insertions(+)
> > > >
> > > > diff --git a/include/linux/memblock.h b/include/linux/memblock.h
> > > > index 5b759c9..0e770af 100644
> > > > --- a/include/linux/memblock.h
> > > > +++ b/include/linux/memblock.h
> > > > @@ -334,6 +334,7 @@ phys_addr_t memblock_start_of_DRAM(void);
> > > > phys_addr_t memblock_end_of_DRAM(void);
> > > > void memblock_enforce_memory_limit(phys_addr_t memory_limit);
> > > > void memblock_mem_limit_remove_map(phys_addr_t limit);
> > > > +void memblock_cap_memory_range(phys_addr_t base, phys_addr_t size);
> > > > bool memblock_is_memory(phys_addr_t addr);
> > > > int memblock_is_map_memory(phys_addr_t addr);
> > > > int memblock_is_region_memory(phys_addr_t base, phys_addr_t size);
> > > > diff --git a/mm/memblock.c b/mm/memblock.c
> > > > index 7608bc3..eb53876 100644
> > > > --- a/mm/memblock.c
> > > > +++ b/mm/memblock.c
> > > > @@ -1544,6 +1544,34 @@ void __init memblock_mem_limit_remove_map(phys_addr_t limit)
> > > > (phys_addr_t)ULLONG_MAX);
> > > > }
> > > >
> > > > +void __init memblock_cap_memory_range(phys_addr_t base, phys_addr_t size)
> > > > +{
> > > > + int start_rgn, end_rgn;
> > > > + int i, ret;
> > > > +
> > > > + if (!size)
> > > > + return;
> > > > +
> > > > + ret = memblock_isolate_range(&memblock.memory, base, size,
> > > > + &start_rgn, &end_rgn);
> > > > + if (ret)
> > > > + return;
> > > > +
> > > > + /* remove all the MAP regions */
> > > > + for (i = memblock.memory.cnt - 1; i >= end_rgn; i--)
> > > > + if (!memblock_is_nomap(&memblock.memory.regions[i]))
> > > > + memblock_remove_region(&memblock.memory, i);
> > > > +
> > > > + for (i = start_rgn - 1; i >= 0; i--)
> > > > + if (!memblock_is_nomap(&memblock.memory.regions[i]))
> > > > + memblock_remove_region(&memblock.memory, i);
> > > > +
> > > > + /* truncate the reserved regions */
> > > > + memblock_remove_range(&memblock.reserved, 0, base);
> > > > + memblock_remove_range(&memblock.reserved,
> > > > + base + size, (phys_addr_t)ULLONG_MAX);
> > > > +}
> > >
> > > This duplicates a bunch of the logic in memblock_mem_limit_remove_map. Can
> > > you not implement that in terms of your new, more general, function? e.g.
> > > by passing base == 0, and size == limit?
> >
> > Obviously it's possible.
> > I actually talked to Dennis before about merging them,
> > but he was against my idea.
> >
> Oops! I thought we have reached agreement in the thread:http://lists.infradead.org/pipermail/linux-arm-kernel/2016-July/442817.html
> So feel free to do that as Will'll do
OK, but I found that the two functions have a bit different semantics
in clipping memory range, in particular, when the range [base,base+size)
goes across several regions with a gap.
(This does not happen in my arm64 kdump, though.)
That is, 'limit' in memblock_mem_limit_remove_map() means total size of
available memory, while 'size' in memblock_cap_memory_range() indicates
the size of _continuous_ memory range.
So I added an extra argument, exact, to a common function to specify
distinct behaviors. Confusing? Please see the patch below.
If nobody objects to this merge, I will submit a whole patchset of kdump
again.
Thanks,
-Takahiro AKASHI
===8<===
include/linux/memblock.h | 1 +
mm/memblock.c | 91 +++++++++++++++++++++++++++++++++++-------------
2 files changed, 68 insertions(+), 24 deletions(-)
diff --git a/include/linux/memblock.h b/include/linux/memblock.h
index 5b759c9..0e770af 100644
--- a/include/linux/memblock.h
+++ b/include/linux/memblock.h
@@ -334,6 +334,7 @@ phys_addr_t memblock_start_of_DRAM(void);
phys_addr_t memblock_end_of_DRAM(void);
void memblock_enforce_memory_limit(phys_addr_t memory_limit);
void memblock_mem_limit_remove_map(phys_addr_t limit);
+void memblock_cap_memory_range(phys_addr_t base, phys_addr_t size);
bool memblock_is_memory(phys_addr_t addr);
int memblock_is_map_memory(phys_addr_t addr);
int memblock_is_region_memory(phys_addr_t base, phys_addr_t size);
diff --git a/mm/memblock.c b/mm/memblock.c
index 7608bc3..5f849a9 100644
--- a/mm/memblock.c
+++ b/mm/memblock.c
@@ -1473,9 +1473,10 @@ phys_addr_t __init_memblock memblock_end_of_DRAM(void)
return (memblock.memory.regions[idx].base + memblock.memory.regions[idx].size);
}
-static phys_addr_t __init_memblock __find_max_addr(phys_addr_t limit)
+static phys_addr_t __init_memblock __find_max_addr(phys_addr_t min,
+ phys_addr_t limit)
{
- phys_addr_t max_addr = (phys_addr_t)ULLONG_MAX;
+ phys_addr_t max_addr = (phys_addr_t)ULLONG_MAX, base, size;
struct memblock_region *r;
/*
@@ -1484,11 +1485,22 @@ static phys_addr_t __init_memblock __find_max_addr(phys_addr_t limit)
* of those regions, max_addr will keep original value ULLONG_MAX
*/
for_each_memblock(memory, r) {
- if (limit <= r->size) {
- max_addr = r->base + limit;
+ if (min >= r->base + r->size)
+ continue;
+
+ if (r->base <= min) {
+ base = min;
+ size = r->base + r->size - min;
+ } else {
+ base = r->base;
+ size = r->size;
+ }
+
+ if (limit <= size) {
+ max_addr = base + limit;
break;
}
- limit -= r->size;
+ limit -= size;
}
return max_addr;
@@ -1501,7 +1513,7 @@ void __init memblock_enforce_memory_limit(phys_addr_t limit)
if (!limit)
return;
- max_addr = __find_max_addr(limit);
+ max_addr = __find_max_addr(0, limit);
/* @limit exceeds the total size of the memory, do nothing */
if (max_addr == (phys_addr_t)ULLONG_MAX)
@@ -1514,34 +1526,65 @@ void __init memblock_enforce_memory_limit(phys_addr_t limit)
(phys_addr_t)ULLONG_MAX);
}
-void __init memblock_mem_limit_remove_map(phys_addr_t limit)
+/*
+ * __memblock_cap_memory_range - cap memblock regions
+ * @base: lowest address to clip
+ * @size: size of memory range
+ * @exact: true or false
+ *
+ * If @exact is true, the exact range [@base, @base+ at size) of memory with
+ * kernel direct mapping is clipped from memblock.memory. Otherwise, total
+ * of @size of memory is clipped starting from @base.
+ */
+static void __init __memblock_cap_memory_range(phys_addr_t base,
+ phys_addr_t size, bool exact)
{
- struct memblock_type *type = &memblock.memory;
- phys_addr_t max_addr;
- int i, ret, start_rgn, end_rgn;
+ int start_rgn, end_rgn;
+ int i, ret;
- if (!limit)
+ if (!size)
return;
- max_addr = __find_max_addr(limit);
+ if (!exact) {
+ phys_addr_t max_addr;
- /* @limit exceeds the total size of the memory, do nothing */
- if (max_addr == (phys_addr_t)ULLONG_MAX)
- return;
+ max_addr = __find_max_addr(base, size);
+ /* @size exceeds the total size of the memory, do nothing */
+ if (max_addr == (phys_addr_t)ULLONG_MAX)
+ return;
+
+ /* recalc the size to clip the exact range [@base, max_addr) */
+ size = max_addr - base;
+ }
- ret = memblock_isolate_range(type, max_addr, (phys_addr_t)ULLONG_MAX,
- &start_rgn, &end_rgn);
+ ret = memblock_isolate_range(&memblock.memory, base, size,
+ &start_rgn, &end_rgn);
if (ret)
return;
- /* remove all the MAP regions above the limit */
- for (i = end_rgn - 1; i >= start_rgn; i--) {
- if (!memblock_is_nomap(&type->regions[i]))
- memblock_remove_region(type, i);
- }
+ /* remove all the other MAP regions */
+ for (i = memblock.memory.cnt - 1; i >= end_rgn; i--)
+ if (!memblock_is_nomap(&memblock.memory.regions[i]))
+ memblock_remove_region(&memblock.memory, i);
+
+ for (i = start_rgn - 1; i >= 0; i--)
+ if (!memblock_is_nomap(&memblock.memory.regions[i]))
+ memblock_remove_region(&memblock.memory, i);
+
/* truncate the reserved regions */
- memblock_remove_range(&memblock.reserved, max_addr,
- (phys_addr_t)ULLONG_MAX);
+ memblock_remove_range(&memblock.reserved, 0, base);
+ memblock_remove_range(&memblock.reserved,
+ base + size, (phys_addr_t)ULLONG_MAX);
+}
+
+void __init memblock_mem_limit_remove_map(phys_addr_t limit)
+{
+ __memblock_cap_memory_range(0, limit, false);
+}
+
+void __init memblock_cap_memory_range(phys_addr_t base, phys_addr_t size)
+{
+ __memblock_cap_memory_range(base, size, true);
}
static int __init_memblock memblock_search(struct memblock_type *type, phys_addr_t addr)
--
2.10.0
===>8===
> >
> > Thanks,
> > -Takahiro AKASHI
> >
> > > Will
^ permalink raw reply related
* [PATCH v2 1/2] arm64: dts: Add level for cpu dt node for exynos7
From: Alim Akhtar @ 2016-11-14 5:58 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAJKOXPc5aJi9nVv4rd3pB_dkkoJWUjmkEyXF2Kxtp+6Y7VZdWg@mail.gmail.com>
Hi Krzysztof,
On 11/13/2016 12:43 AM, Krzysztof Kozlowski wrote:
> On Sat, Nov 12, 2016 at 6:00 PM, Alim Akhtar <alim.akhtar@gmail.com> wrote:
>> Hi Javier,
>>
>> On Sat, Nov 12, 2016 at 7:54 PM, Javier Martinez Canillas
>> <javier@osg.samsung.com> wrote:
>>> Hello Alim,
>>>
>>> On 11/12/2016 07:17 AM, Alim Akhtar wrote:
>>>> This patch adds level for cpu dt node, so that these levels can be used
>>>
>>> Do you mean s/level/label here? I'm asking because you are using level
>>> consistently in the subject line and commit message but I'm not sure
>>> what it means in this context.
>>>
>>
>> Ah!! my bad. Its __label__. If required, will respin.
>> Thanks for review.
>
> I think there is no need of respin because this should be squashed
> with previous patch. This is quite small and there are no functional
> changes here (labels are transparent, except of course conflict
> cases). Without the 2/2, this patch does not have much sense yet.
>
The reason why I kept the _label_ changes are separate patch is to keep
git bisect happy. If you think there won't be a case for that, then lets
merge the two in single patch.
Let me know if you want me to respin or you will take care.
> Best regards,
> Krzysztof
>
>
>
^ permalink raw reply
* [PATCH v2 1/3] ARM: imx6ull: add imx6ull support
From: Peter Chen @ 2016-11-14 5:59 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161114054833.GG3310@dragon>
Best regards,
Peter Chen
>-----Original Message-----
>From: Shawn Guo [mailto:shawnguo at kernel.org]
>Sent: Monday, November 14, 2016 1:49 PM
>To: Peter Chen <peter.chen@nxp.com>
>Cc: sboyd at codeaurora.org; mturquette at baylibre.com; linux-arm-
>kernel at lists.infradead.org; kernel at pengutronix.de; devicetree at vger.kernel.org;
>robh+dt at kernel.org; Fabio Estevam <fabio.estevam@nxp.com>;
>mark.rutland at arm.com; linux-clk at vger.kernel.org
>Subject: Re: [PATCH v2 1/3] ARM: imx6ull: add imx6ull support
>
>On Tue, Nov 08, 2016 at 01:56:52PM +0800, Peter Chen wrote:
>> It is the 10th processor in the well-known imx6 series, and derived
>> from imx6ul but cost optimized. The more information about imx6ull can
>> be found at:
>>
>> http://www.nxp.com/products/microcontrollers-and-processors/
>> arm-processors/i.mx-applications-processors/i.mx-6-processors
>> /i.mx6qp/i.mx-6ull-single-core-processor-with-arm-cortex-a7-core
>> :i.MX6ULL
>>
>> In this patch, for SoC part, the imx6ull.dtsi includes imx6ul.dtsi;
>> for board part (imx6ul/imx6ull 14x14 evk), it has a common board file
>> imx6u-14x14-evk.dtsi, and this file is included by both
>> imx6ul-14x14-evk.dts and imx6ull-14x14-evk.dts.
>>
>> Signed-off-by: Peter Chen <peter.chen@nxp.com>
>> ---
>> arch/arm/boot/dts/Makefile | 3 +-
>> arch/arm/boot/dts/imx6u-14x14-evk.dtsi | 487
>> ++++++++++++++++++++++++++++++++
>> arch/arm/boot/dts/imx6ul-14x14-evk.dts | 479
>> +------------------------------
>
>What's the real change between imx6u-14x14-evk.dtsi and imx6ul-14x14-evk.dts?
>Instead of renaming the file, I would like to have imx6ull-14x14-evk.dts include
>imx6ul-14x14-evk.dts directly, if we can work out the difference within imx6ull-
>14x14-evk.dts.
>
The main difference is compatible string, I can't include two compatible strings in one dts file,
the dts build will fail for that.
imx6ull-14x14-evk.dts
/ {
model = "Freescale i.MX6 UlltraLite 14x14 EVK Board";
compatible = "fsl,imx6ull-14x14-evk", "fsl,imx6ull";
};
imx6ul-14x14-evk.dts
/ {
model = "Freescale i.MX6 UltraLite 14x14 EVK Board";
compatible = "fsl,imx6ul-14x14-evk", "fsl,imx6ul";
};
Peter
^ permalink raw reply
* [PATCH 09/16] ARM: BCM: use generic API for enabling SCU
From: Florian Fainelli @ 2016-11-14 6:10 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1479099731-28108-10-git-send-email-pankaj.dubey@samsung.com>
Le 13/11/2016 ? 21:02, Pankaj Dubey a ?crit :
> Now as we have of_scu_enable which takes care of mapping
> scu base from DT, lets use it.
>
> CC: Florian Fainelli <f.fainelli@gmail.com>
> CC: Ray Jui <rjui@broadcom.com>
> CC: Scott Branden <sbranden@broadcom.com>
> CC: bcm-kernel-feedback-list at broadcom.com
> Signed-off-by: Pankaj Dubey <pankaj.dubey@samsung.com>
Reviewed-by: Florian Fainelli <f.fainelli@gmail.com>
Let me know if I need to pick this and submit via ARM SoC pull requests,
thanks!
--
Florian
^ permalink raw reply
* [PATCH 01/16] ARM: scu: Provide support for parsing SCU device node to enable SCU
From: Jisheng Zhang @ 2016-11-14 6:12 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1479099731-28108-2-git-send-email-pankaj.dubey@samsung.com>
Hi Pankaj,
On Mon, 14 Nov 2016 10:31:56 +0530 Pankaj Dubey wrote:
> Many platforms are duplicating code for enabling SCU, lets add
> common code to enable SCU by parsing SCU device node so the duplication
> in each platform can be avoided.
>
> CC: Krzysztof Kozlowski <krzk@kernel.org>
> CC: Jisheng Zhang <jszhang@marvell.com>
> CC: Russell King <linux@armlinux.org.uk>
> CC: Dinh Nguyen <dinguyen@opensource.altera.com>
> CC: Patrice Chotard <patrice.chotard@st.com>
> CC: Linus Walleij <linus.walleij@linaro.org>
> CC: Liviu Dudau <liviu.dudau@arm.com>
> CC: Ray Jui <rjui@broadcom.com>
> CC: Stephen Warren <swarren@wwwdotorg.org>
> CC: Heiko Stuebner <heiko@sntech.de>
> CC: Shawn Guo <shawnguo@kernel.org>
> CC: Michal Simek <michal.simek@xilinx.com>
> CC: Wei Xu <xuwei5@hisilicon.com>
> CC: Andrew Lunn <andrew@lunn.ch>
> CC: Jun Nie <jun.nie@linaro.org>
> Suggested-by: Arnd Bergmann <arnd@arndb.de>
> Signed-off-by: Pankaj Dubey <pankaj.dubey@samsung.com>
> ---
> arch/arm/include/asm/smp_scu.h | 4 +++
> arch/arm/kernel/smp_scu.c | 56 ++++++++++++++++++++++++++++++++++++++++++
> 2 files changed, 60 insertions(+)
>
> diff --git a/arch/arm/include/asm/smp_scu.h b/arch/arm/include/asm/smp_scu.h
> index bfe163c..fdeec07 100644
> --- a/arch/arm/include/asm/smp_scu.h
> +++ b/arch/arm/include/asm/smp_scu.h
> @@ -39,8 +39,12 @@ static inline int scu_power_mode(void __iomem *scu_base, unsigned int mode)
>
> #if defined(CONFIG_SMP) && defined(CONFIG_HAVE_ARM_SCU)
> void scu_enable(void __iomem *scu_base);
> +void __iomem *of_scu_get_base(void);
> +int of_scu_enable(void);
> #else
> static inline void scu_enable(void __iomem *scu_base) {}
> +static inline void __iomem *of_scu_get_base(void) {return NULL; }
> +static inline int of_scu_enable(void) {return 0; }
> #endif
>
> #endif
> diff --git a/arch/arm/kernel/smp_scu.c b/arch/arm/kernel/smp_scu.c
> index 72f9241..d0ac3ed 100644
> --- a/arch/arm/kernel/smp_scu.c
> +++ b/arch/arm/kernel/smp_scu.c
> @@ -10,6 +10,7 @@
> */
> #include <linux/init.h>
> #include <linux/io.h>
> +#include <linux/of_address.h>
>
> #include <asm/smp_plat.h>
> #include <asm/smp_scu.h>
> @@ -70,6 +71,61 @@ void scu_enable(void __iomem *scu_base)
> */
> flush_cache_all();
> }
> +
> +static const struct of_device_id scu_match[] = {
> + { .compatible = "arm,cortex-a9-scu", },
> + { .compatible = "arm,cortex-a5-scu", },
> + { }
> +};
> +
> +/*
> + * Helper API to get SCU base address
> + * In case platform DT do not have SCU node, or iomap fails
> + * this call will fallback and will try to map via call to
> + * scu_a9_get_base.
> + * This will return ownership of scu_base to the caller
> + */
> +void __iomem *of_scu_get_base(void)
> +{
> + unsigned long base = 0;
> + struct device_node *np;
> + void __iomem *scu_base;
> +
> + np = of_find_matching_node(NULL, scu_match);
could we check np before calling of_iomap()?
> + scu_base = of_iomap(np, 0);
> + of_node_put(np);
> + if (!scu_base) {
> + pr_err("%s failed to map scu_base via DT\n", __func__);
For non-ca5, non-ca9 based SoCs, we'll see this error msg. We understand
what does it mean, but it may confuse normal users. In current version,
berlin doesn't complain like this for non-ca9 SoCs
> + if (scu_a9_has_base()) {
> + base = scu_a9_get_base();
> + scu_base = ioremap(base, SZ_4K);
> + }
> + if (!scu_base) {
> + pr_err("%s failed to map scu_base\n", __func__);
ditto
> + return IOMEM_ERR_PTR(-ENOMEM);
> + }
> + }
> + return scu_base;
> +}
> +
> +/*
> + * Enable SCU via mapping scu_base DT
> + * If scu_base mapped successfully scu will be enabled and in case of
> + * failure if will return non-zero error code
> + */
> +int of_scu_enable(void)
> +{
> + void __iomem *scu_base;
> +
> + scu_base = of_scu_get_base();
> + if (!IS_ERR(scu_base)) {
> + scu_enable(scu_base);
> + iounmap(scu_base);
> + return 0;
> + }
> + return PTR_ERR(scu_base);
> +}
> +
> #endif
>
> /*
^ permalink raw reply
* [PATCH v2 1/3] ARM: imx6ull: add imx6ull support
From: Shawn Guo @ 2016-11-14 6:13 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <HE1PR04MB14509BFD0CBA838BC1EA7D598BBC0@HE1PR04MB1450.eurprd04.prod.outlook.com>
On Mon, Nov 14, 2016 at 05:59:01AM +0000, Peter Chen wrote:
> The main difference is compatible string, I can't include two compatible strings in one dts file,
> the dts build will fail for that.
>
> imx6ull-14x14-evk.dts
> / {
> model = "Freescale i.MX6 UlltraLite 14x14 EVK Board";
> compatible = "fsl,imx6ull-14x14-evk", "fsl,imx6ull";
> };
>
> imx6ul-14x14-evk.dts
> / {
> model = "Freescale i.MX6 UltraLite 14x14 EVK Board";
> compatible = "fsl,imx6ul-14x14-evk", "fsl,imx6ul";
> };
I created imx6ull-14x14-evk.dts like below, and DTC seems happy with it.
#include "imx6ul-14x14-evk.dts"
/ {
model = "Freescale i.MX6 UlltraLite 14x14 EVK Board";
compatible = "fsl,imx6ull-14x14-evk", "fsl,imx6ull";
};
Shawn
^ permalink raw reply
* [RESEND][PATCH 6/6] arm64: Add DTS support for FSL's LS2088A SoC
From: Shawn Guo @ 2016-11-14 6:33 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1478597664-14799-7-git-send-email-abhimanyu.saini@nxp.com>
On Tue, Nov 08, 2016 at 03:04:24PM +0530, Abhimanyu Saini wrote:
> This patch adds the device tree support for FSL LS2088A SoC based on
> ARMv8 architecture.
>
> Following levels of DTSI/DTS files have been created for the LS2088A
> SoC family:
>
> - fsl-ls2088a.dtsi:
> DTS-Include file for FSL LS2088A SoC.
>
> - fsl-ls2088a-qds.dts:
> DTS file for FSL LS2088A QDS board.
>
> - fsl-ls2088a-rdb.dts:
> DTS file for FSL LS2088A RDB board.
I compared the following files.
fsl-ls2088a.dtsi vs. fsl-ls2080a.dtsi
fsl-ls2088a-qds.dtsi vs. fsl-ls2080a-qds.dtsi
fsl-ls2088a-rdb.dtsi vs. fsl-ls2080a-rdb.dtsi
They are basically identical except a couple of small changes. Can we
do something to have these SoCs share the dts files at some level to
avoid maintaining duplicated files?
Shawn
> Signed-off-by: Priyanka Jain <priyanka.jain@nxp.com>
> Signed-off-by: Ashish Kumar <ashish.kumar@nxp.com>
> Signed-off-by: Abhimanyu Saini <abhimanyu.saini@nxp.com>
> ---
> arch/arm64/boot/dts/freescale/Makefile | 2 +
> arch/arm64/boot/dts/freescale/fsl-ls2088a-qds.dts | 211 +++++++
> arch/arm64/boot/dts/freescale/fsl-ls2088a-rdb.dts | 166 +++++
> arch/arm64/boot/dts/freescale/fsl-ls2088a.dtsi | 703 ++++++++++++++++++++++
> 4 files changed, 1082 insertions(+)
> create mode 100644 arch/arm64/boot/dts/freescale/fsl-ls2088a-qds.dts
> create mode 100644 arch/arm64/boot/dts/freescale/fsl-ls2088a-rdb.dts
> create mode 100644 arch/arm64/boot/dts/freescale/fsl-ls2088a.dtsi
^ permalink raw reply
* [PATCH v2 1/3] ARM: imx6ull: add imx6ull support
From: Peter Chen @ 2016-11-14 6:35 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161114061311.GA14956@dragon>
>On Mon, Nov 14, 2016 at 05:59:01AM +0000, Peter Chen wrote:
>> The main difference is compatible string, I can't include two
>> compatible strings in one dts file, the dts build will fail for that.
>>
>> imx6ull-14x14-evk.dts
>> / {
>> model = "Freescale i.MX6 UlltraLite 14x14 EVK Board";
>> compatible = "fsl,imx6ull-14x14-evk", "fsl,imx6ull"; };
>>
>> imx6ul-14x14-evk.dts
>> / {
>> model = "Freescale i.MX6 UltraLite 14x14 EVK Board";
>> compatible = "fsl,imx6ul-14x14-evk", "fsl,imx6ul"; };
>
>I created imx6ull-14x14-evk.dts like below, and DTC seems happy with it.
>
>#include "imx6ul-14x14-evk.dts"
>
>/ {
> model = "Freescale i.MX6 UlltraLite 14x14 EVK Board";
> compatible = "fsl,imx6ull-14x14-evk", "fsl,imx6ull"; };
>
Thanks for trying it, the problem why my dtc building fail is I have two
" /dts-v1/;" at dts file (one is from imx6ul-14x14-evk.dts) . I will follow your suggestion.
Peter
^ permalink raw reply
* [PATCH] arm: imx6qp: correct LDB clock inputs
From: Shawn Guo @ 2016-11-14 6:36 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161108165536.19656-1-l.stach@pengutronix.de>
On Tue, Nov 08, 2016 at 05:55:36PM +0100, Lucas Stach wrote:
> On i.MX6QP the LDB clock tree has changed to move the clk gate
> before the divider, to prevent clock glitches propagating downstream.
>
> A consequence of this change is that the clk divider is now the
> parent of the LDB inputs. Reflect this change in the devicetree
> to allow the LDB driver to properly configure the display clocks.
>
> Signed-off-by: Lucas Stach <l.stach@pengutronix.de>
Applied, thanks.
^ permalink raw reply
* [PATCH] ARM: dts: imx7d-pinfunc: fix UART pinmux defines
From: Shawn Guo @ 2016-11-14 6:38 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161109024456.1832-1-stefan@agner.ch>
On Tue, Nov 08, 2016 at 06:44:56PM -0800, Stefan Agner wrote:
> The UART pinmux defines for the pins which are part of the LPSR
> pinmux controller are wrong: Output signals configure the input
> sel value and the pinmux defines allow not to distinguish between
> DCE/DTE mode. Follow the usual pattern using DTE/DCE as part of
> the define to denote the two UART configuration options.
>
> Signed-off-by: Stefan Agner <stefan@agner.ch>
Applied, thanks.
^ permalink raw reply
* [PATCH] i.MX: Kconfig: Drop errata 769419 for Vybrid
From: Shawn Guo @ 2016-11-14 6:44 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1478709850-9361-1-git-send-email-andrew.smirnov@gmail.com>
On Wed, Nov 09, 2016 at 08:44:10AM -0800, Andrey Smirnov wrote:
> According to the datasheet, VF610 uses revision r3p2 of the L2C-310
> block, same as i.MX6Q+, which does not require a software workaround for
> ARM errata 769419.
>
> Signed-off-by: Andrey Smirnov <andrew.smirnov@gmail.com>
I updated subject prefix a bit and applied the patch.
Shawn
^ permalink raw reply
* [PATCH] i.MX: Kconfig: Drop errata 769419 for Vybrid
From: Stefan Agner @ 2016-11-14 6:47 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1478709850-9361-1-git-send-email-andrew.smirnov@gmail.com>
On 2016-11-09 17:44, Andrey Smirnov wrote:
> According to the datasheet, VF610 uses revision r3p2 of the L2C-310
> block, same as i.MX6Q+, which does not require a software workaround for
> ARM errata 769419.
FWIW, r3p2 is also the revision according to the cache registers...
Acked-by: Stefan Agner <stefan@agner.ch>
--
Stefan
>
> Signed-off-by: Andrey Smirnov <andrew.smirnov@gmail.com>
> ---
> arch/arm/mach-imx/Kconfig | 1 -
> 1 file changed, 1 deletion(-)
>
> diff --git a/arch/arm/mach-imx/Kconfig b/arch/arm/mach-imx/Kconfig
> index 9155b63..936c59d 100644
> --- a/arch/arm/mach-imx/Kconfig
> +++ b/arch/arm/mach-imx/Kconfig
> @@ -557,7 +557,6 @@ config SOC_VF610
> bool "Vybrid Family VF610 support"
> select ARM_GIC if ARCH_MULTI_V7
> select PINCTRL_VF610
> - select PL310_ERRATA_769419 if CACHE_L2X0
>
> help
> This enables support for Freescale Vybrid VF610 processor.
^ permalink raw reply
* [PATCH 01/16] ARM: scu: Provide support for parsing SCU device node to enable SCU
From: Jisheng Zhang @ 2016-11-14 6:54 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161114141251.7ea86e7a@xhacker>
On Mon, 14 Nov 2016 14:12:51 +0800 Jisheng Zhang wrote:
> Hi Pankaj,
>
> On Mon, 14 Nov 2016 10:31:56 +0530 Pankaj Dubey wrote:
>
> > Many platforms are duplicating code for enabling SCU, lets add
> > common code to enable SCU by parsing SCU device node so the duplication
> > in each platform can be avoided.
> >
> > CC: Krzysztof Kozlowski <krzk@kernel.org>
> > CC: Jisheng Zhang <jszhang@marvell.com>
> > CC: Russell King <linux@armlinux.org.uk>
> > CC: Dinh Nguyen <dinguyen@opensource.altera.com>
> > CC: Patrice Chotard <patrice.chotard@st.com>
> > CC: Linus Walleij <linus.walleij@linaro.org>
> > CC: Liviu Dudau <liviu.dudau@arm.com>
> > CC: Ray Jui <rjui@broadcom.com>
> > CC: Stephen Warren <swarren@wwwdotorg.org>
> > CC: Heiko Stuebner <heiko@sntech.de>
> > CC: Shawn Guo <shawnguo@kernel.org>
> > CC: Michal Simek <michal.simek@xilinx.com>
> > CC: Wei Xu <xuwei5@hisilicon.com>
> > CC: Andrew Lunn <andrew@lunn.ch>
> > CC: Jun Nie <jun.nie@linaro.org>
> > Suggested-by: Arnd Bergmann <arnd@arndb.de>
> > Signed-off-by: Pankaj Dubey <pankaj.dubey@samsung.com>
> > ---
> > arch/arm/include/asm/smp_scu.h | 4 +++
> > arch/arm/kernel/smp_scu.c | 56 ++++++++++++++++++++++++++++++++++++++++++
> > 2 files changed, 60 insertions(+)
> >
> > diff --git a/arch/arm/include/asm/smp_scu.h b/arch/arm/include/asm/smp_scu.h
> > index bfe163c..fdeec07 100644
> > --- a/arch/arm/include/asm/smp_scu.h
> > +++ b/arch/arm/include/asm/smp_scu.h
> > @@ -39,8 +39,12 @@ static inline int scu_power_mode(void __iomem *scu_base, unsigned int mode)
> >
> > #if defined(CONFIG_SMP) && defined(CONFIG_HAVE_ARM_SCU)
> > void scu_enable(void __iomem *scu_base);
> > +void __iomem *of_scu_get_base(void);
> > +int of_scu_enable(void);
> > #else
> > static inline void scu_enable(void __iomem *scu_base) {}
> > +static inline void __iomem *of_scu_get_base(void) {return NULL; }
> > +static inline int of_scu_enable(void) {return 0; }
> > #endif
> >
> > #endif
> > diff --git a/arch/arm/kernel/smp_scu.c b/arch/arm/kernel/smp_scu.c
> > index 72f9241..d0ac3ed 100644
> > --- a/arch/arm/kernel/smp_scu.c
> > +++ b/arch/arm/kernel/smp_scu.c
> > @@ -10,6 +10,7 @@
> > */
> > #include <linux/init.h>
> > #include <linux/io.h>
> > +#include <linux/of_address.h>
> >
> > #include <asm/smp_plat.h>
> > #include <asm/smp_scu.h>
> > @@ -70,6 +71,61 @@ void scu_enable(void __iomem *scu_base)
> > */
> > flush_cache_all();
> > }
> > +
> > +static const struct of_device_id scu_match[] = {
> > + { .compatible = "arm,cortex-a9-scu", },
> > + { .compatible = "arm,cortex-a5-scu", },
> > + { }
> > +};
> > +
> > +/*
> > + * Helper API to get SCU base address
> > + * In case platform DT do not have SCU node, or iomap fails
> > + * this call will fallback and will try to map via call to
> > + * scu_a9_get_base.
> > + * This will return ownership of scu_base to the caller
> > + */
> > +void __iomem *of_scu_get_base(void)
> > +{
> > + unsigned long base = 0;
> > + struct device_node *np;
> > + void __iomem *scu_base;
> > +
> > + np = of_find_matching_node(NULL, scu_match);
>
> could we check np before calling of_iomap()?
>
> > + scu_base = of_iomap(np, 0);
> > + of_node_put(np);
> > + if (!scu_base) {
> > + pr_err("%s failed to map scu_base via DT\n", __func__);
>
> For non-ca5, non-ca9 based SoCs, we'll see this error msg. We understand
> what does it mean, but it may confuse normal users. In current version,
> berlin doesn't complain like this for non-ca9 SoCs
oops, I just realized that the non-ca9 berlin arm SoC version isn't upstreamed.
Below is the draft version I planed. Basically speaking, the code tries to
find "arm,cortex-a9-scu" node from DT, if can't, we think we don't need to
worry about SCU. Is there any elegant solution for my situation?
Thanks,
Jisheng
------------8<-------------------
--- a/arch/arm/mach-berlin/platsmp.c
+++ b/arch/arm/mach-berlin/platsmp.c
@@ -56,22 +56,25 @@ static void __init berlin_smp_prepare_cpus(unsigned int max_cpus)
void __iomem *vectors_base;
np = of_find_compatible_node(NULL, NULL, "arm,cortex-a9-scu");
- scu_base = of_iomap(np, 0);
- of_node_put(np);
- if (!scu_base)
- return;
+ if (np) {
+ scu_base = of_iomap(np, 0);
+ of_node_put(np);
+ if (!scu_base)
+ return;
+ scu_enable(scu_base);
+ iounmap(scu_base);
+ }
np = of_find_compatible_node(NULL, NULL, "marvell,berlin-cpu-ctrl");
cpu_ctrl = of_iomap(np, 0);
of_node_put(np);
if (!cpu_ctrl)
- goto unmap_scu;
+ return;
vectors_base = ioremap(CONFIG_VECTORS_BASE, SZ_32K);
if (!vectors_base)
- goto unmap_scu;
+ return;
- scu_enable(scu_base);
flush_cache_all();
/*
@@ -87,8 +90,6 @@ static void __init berlin_smp_prepare_cpus(unsigned int max_cpus)
writel(virt_to_phys(secondary_startup), vectors_base + SW_RESET_ADDR);
iounmap(vectors_base);
-unmap_scu:
- iounmap(scu_base);
}
static struct smp_operations berlin_smp_ops __initdata = {
>
> > + if (scu_a9_has_base()) {
> > + base = scu_a9_get_base();
> > + scu_base = ioremap(base, SZ_4K);
> > + }
> > + if (!scu_base) {
> > + pr_err("%s failed to map scu_base\n", __func__);
>
> ditto
>
> > + return IOMEM_ERR_PTR(-ENOMEM);
> > + }
> > + }
> > + return scu_base;
> > +}
> > +
> > +/*
> > + * Enable SCU via mapping scu_base DT
> > + * If scu_base mapped successfully scu will be enabled and in case of
> > + * failure if will return non-zero error code
> > + */
> > +int of_scu_enable(void)
> > +{
> > + void __iomem *scu_base;
> > +
> > + scu_base = of_scu_get_base();
> > + if (!IS_ERR(scu_base)) {
> > + scu_enable(scu_base);
> > + iounmap(scu_base);
> > + return 0;
> > + }
> > + return PTR_ERR(scu_base);
> > +}
> > +
> > #endif
> >
> > /*
>
>
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH v2 0/2] phy: rockchip-inno-usb2: correct 480MHz clk_ops callbacks and stable time
From: William Wu @ 2016-11-14 7:01 UTC (permalink / raw)
To: linux-arm-kernel
This series try to correct the 480MHz output clock of USB2 PHY
clk_ops callback and fix the delay time. It aims to make the
480MHz clock more sensible and stable.
Tested on rk3366/rk3399 EVB board.
William Wu (2):
phy: rockchip-inno-usb2: correct clk_ops callback
phy: rockchip-inno-usb2: correct 480MHz output clock stable time
drivers/phy/phy-rockchip-inno-usb2.c | 14 +++++++-------
1 file changed, 7 insertions(+), 7 deletions(-)
--
2.0.0
^ permalink raw reply
* [PATCH v2 1/2] phy: rockchip-inno-usb2: correct clk_ops callback
From: William Wu @ 2016-11-14 7:01 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1479106911-16049-1-git-send-email-wulf@rock-chips.com>
Since we needs to delay ~1ms to wait for 480MHz output clock
of USB2 PHY to become stable after turn on it, the delay time
is pretty long for something that's supposed to be "atomic"
like a clk_enable(). Consider that clk_enable() will disable
interrupt and that a 1ms interrupt latency is not sensible.
The 480MHz output clock should be handled in prepare callbacks
which support gate a clk if the operation may sleep.
Signed-off-by: William Wu <wulf@rock-chips.com>
---
drivers/phy/phy-rockchip-inno-usb2.c | 12 ++++++------
1 file changed, 6 insertions(+), 6 deletions(-)
diff --git a/drivers/phy/phy-rockchip-inno-usb2.c b/drivers/phy/phy-rockchip-inno-usb2.c
index ac20310..365e077 100644
--- a/drivers/phy/phy-rockchip-inno-usb2.c
+++ b/drivers/phy/phy-rockchip-inno-usb2.c
@@ -153,7 +153,7 @@ static inline bool property_enabled(struct rockchip_usb2phy *rphy,
return tmp == reg->enable;
}
-static int rockchip_usb2phy_clk480m_enable(struct clk_hw *hw)
+static int rockchip_usb2phy_clk480m_prepare(struct clk_hw *hw)
{
struct rockchip_usb2phy *rphy =
container_of(hw, struct rockchip_usb2phy, clk480m_hw);
@@ -172,7 +172,7 @@ static int rockchip_usb2phy_clk480m_enable(struct clk_hw *hw)
return 0;
}
-static void rockchip_usb2phy_clk480m_disable(struct clk_hw *hw)
+static void rockchip_usb2phy_clk480m_unprepare(struct clk_hw *hw)
{
struct rockchip_usb2phy *rphy =
container_of(hw, struct rockchip_usb2phy, clk480m_hw);
@@ -181,7 +181,7 @@ static void rockchip_usb2phy_clk480m_disable(struct clk_hw *hw)
property_enable(rphy, &rphy->phy_cfg->clkout_ctl, false);
}
-static int rockchip_usb2phy_clk480m_enabled(struct clk_hw *hw)
+static int rockchip_usb2phy_clk480m_prepared(struct clk_hw *hw)
{
struct rockchip_usb2phy *rphy =
container_of(hw, struct rockchip_usb2phy, clk480m_hw);
@@ -197,9 +197,9 @@ rockchip_usb2phy_clk480m_recalc_rate(struct clk_hw *hw,
}
static const struct clk_ops rockchip_usb2phy_clkout_ops = {
- .enable = rockchip_usb2phy_clk480m_enable,
- .disable = rockchip_usb2phy_clk480m_disable,
- .is_enabled = rockchip_usb2phy_clk480m_enabled,
+ .prepare = rockchip_usb2phy_clk480m_prepare,
+ .unprepare = rockchip_usb2phy_clk480m_unprepare,
+ .is_prepared = rockchip_usb2phy_clk480m_prepared,
.recalc_rate = rockchip_usb2phy_clk480m_recalc_rate,
};
--
2.0.0
^ permalink raw reply related
* [PATCH v2 2/2] phy: rockchip-inno-usb2: correct 480MHz output clock stable time
From: William Wu @ 2016-11-14 7:01 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1479106911-16049-1-git-send-email-wulf@rock-chips.com>
We found that the system crashed due to 480MHz output clock of
USB2 PHY was unstable after clock had been enabled by gpu module.
Theoretically, 1 millisecond is a critical value for 480MHz
output clock stable time, so we try to change the delay time
to 1.2 millisecond to avoid this issue.
And the commit ed907fb1d7c3 ("phy: rockchip-inno-usb2: correct
clk_ops callback") used prepare callbacks instead of enable
callbacks to support gate a clk if the operation may sleep. So
we can switch from delay to sleep functions.
Signed-off-by: William Wu <wulf@rock-chips.com>
---
Changes in v2:
- use usleep_range() function instead of mdelay()
drivers/phy/phy-rockchip-inno-usb2.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/phy/phy-rockchip-inno-usb2.c b/drivers/phy/phy-rockchip-inno-usb2.c
index 365e077..578290b 100644
--- a/drivers/phy/phy-rockchip-inno-usb2.c
+++ b/drivers/phy/phy-rockchip-inno-usb2.c
@@ -166,7 +166,7 @@ static int rockchip_usb2phy_clk480m_prepare(struct clk_hw *hw)
return ret;
/* waitting for the clk become stable */
- mdelay(1);
+ usleep_range(1200);
}
return 0;
--
2.0.0
^ permalink raw reply related
* [PATCH v3 0/3] imx: add imx6ull support
From: Peter Chen @ 2016-11-14 7:04 UTC (permalink / raw)
To: linux-arm-kernel
Hi Shawn,
In this series, it adds support for imx6ull SoC which is a derived SoC
from imx6ul, and imx6ull is pin-to-pin compatible with imx6ul, the
basic functions are tested at imx6ull 14x14 evk, and imx6ul 14x14 evk
is tested too to avoid regression.
Changes for v3:
- Keep imx6ul-14x14-evk.dts unchanging, and let imx6ull-14x14-evk.dts
include it. [Patch 1/3]
Changes for v2:
- Keep imx6ul.dtsi unchanging, and using GPL/X11 dual license
for new dts file. [Patch 1/3]
- Using IMX6ULL prefix for both imx6ull dedicated pin and clock name.
[Patch 1/3, 3/3]
- Delete useless changes for patch 2/3.
- Delete blank line for patch 3/3.
- Using assigned-clocks for imx6ull 14x14 evk. [Patch 1/3, 3/3]
Bai Ping (1):
clk: imx: clk-imx6ul: add clk support for imx6ull
Peter Chen (2):
ARM: imx6ull: add imx6ull support
ARM: imx: mach-imx6ul: add imx6ull support
arch/arm/boot/dts/Makefile | 3 +-
arch/arm/boot/dts/imx6ull-14x14-evk.dts | 52 +++++++++++++++++++++++
arch/arm/boot/dts/imx6ull-pinfunc.h | 56 +++++++++++++++++++++++++
arch/arm/boot/dts/imx6ull.dtsi | 43 +++++++++++++++++++
arch/arm/mach-imx/mach-imx6ul.c | 1 +
drivers/clk/imx/clk-imx6ul.c | 72 +++++++++++++++++++++++++++-----
include/dt-bindings/clock/imx6ul-clock.h | 15 ++++++-
7 files changed, 229 insertions(+), 13 deletions(-)
create mode 100644 arch/arm/boot/dts/imx6ull-14x14-evk.dts
create mode 100644 arch/arm/boot/dts/imx6ull-pinfunc.h
create mode 100644 arch/arm/boot/dts/imx6ull.dtsi
--
2.7.4
^ permalink raw reply
* [PATCH v3 1/3] ARM: imx6ull: add imx6ull support
From: Peter Chen @ 2016-11-14 7:04 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1479107062-15365-1-git-send-email-peter.chen@nxp.com>
It is the 10th processor in the well-known imx6 series, and derived
from imx6ul but cost optimized. The more information about imx6ull
can be found at:
http://www.nxp.com/products/microcontrollers-and-processors/
arm-processors/i.mx-applications-processors/i.mx-6-processors
/i.mx6qp/i.mx-6ull-single-core-processor-with-arm-cortex-a7-core
:i.MX6ULL
imx6ul.dtsi is the SoC common stuff for both imx6ul and imx6ull;
imx6ul-14x14-evk.dts is the board common stuff for both imx6ul
and imx6ull 14x14 evk. In this patch, for SoC part, the
imx6ull.dtsi includes imx6ul.dtsi; for board part, imx6ull-14x14-evk.dts
includes imx6ul-14x14-evk.dts.
Signed-off-by: Peter Chen <peter.chen@nxp.com>
---
arch/arm/boot/dts/Makefile | 3 +-
arch/arm/boot/dts/imx6ull-14x14-evk.dts | 52 ++++++++++++++++++++++++++++++
arch/arm/boot/dts/imx6ull-pinfunc.h | 56 +++++++++++++++++++++++++++++++++
arch/arm/boot/dts/imx6ull.dtsi | 43 +++++++++++++++++++++++++
4 files changed, 153 insertions(+), 1 deletion(-)
create mode 100644 arch/arm/boot/dts/imx6ull-14x14-evk.dts
create mode 100644 arch/arm/boot/dts/imx6ull-pinfunc.h
create mode 100644 arch/arm/boot/dts/imx6ull.dtsi
diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index befcd26..3d6e199 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -423,7 +423,8 @@ dtb-$(CONFIG_SOC_IMX6UL) += \
imx6ul-pico-hobbit.dtb \
imx6ul-tx6ul-0010.dtb \
imx6ul-tx6ul-0011.dtb \
- imx6ul-tx6ul-mainboard.dtb
+ imx6ul-tx6ul-mainboard.dtb \
+ imx6ull-14x14-evk.dtb
dtb-$(CONFIG_SOC_IMX7D) += \
imx7d-cl-som-imx7.dtb \
imx7d-colibri-eval-v3.dtb \
diff --git a/arch/arm/boot/dts/imx6ull-14x14-evk.dts b/arch/arm/boot/dts/imx6ull-14x14-evk.dts
new file mode 100644
index 0000000..db5bc07
--- /dev/null
+++ b/arch/arm/boot/dts/imx6ull-14x14-evk.dts
@@ -0,0 +1,52 @@
+/*
+ * Copyright (C) 2016 Freescale Semiconductor, Inc.
+ *
+ * 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 "imx6ul-14x14-evk.dts"
+
+/ {
+ model = "Freescale i.MX6 UlltraLite 14x14 EVK Board";
+ compatible = "fsl,imx6ull-14x14-evk", "fsl,imx6ull";
+};
+
+&clks {
+ assigned-clocks = <&clks IMX6UL_CLK_PLL3_PFD2>;
+ assigned-clock-rates = <320000000>;
+};
diff --git a/arch/arm/boot/dts/imx6ull-pinfunc.h b/arch/arm/boot/dts/imx6ull-pinfunc.h
new file mode 100644
index 0000000..580b5c3
--- /dev/null
+++ b/arch/arm/boot/dts/imx6ull-pinfunc.h
@@ -0,0 +1,56 @@
+/*
+ * Copyright (C) 2016 Freescale Semiconductor, Inc.
+ *
+ * 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.
+ */
+
+#ifndef __DTS_IMX6ULL_PINFUNC_H
+#define __DTS_IMX6ULL_PINFUNC_H
+
+#include "imx6ul-pinfunc.h"
+/*
+ * The pin function ID is a tuple of
+ * <mux_reg conf_reg input_reg mux_mode input_val>
+ */
+#define MX6ULL_PAD_ENET2_RX_DATA0__EPDC_SDDO08 0x00E4 0x0370 0x0000 0x9 0x0
+#define MX6ULL_PAD_ENET2_RX_DATA1__EPDC_SDDO09 0x00E8 0x0374 0x0000 0x9 0x0
+#define MX6ULL_PAD_ENET2_RX_EN__EPDC_SDDO10 0x00EC 0x0378 0x0000 0x9 0x0
+#define MX6ULL_PAD_ENET2_TX_DATA0__EPDC_SDDO11 0x00F0 0x037C 0x0000 0x9 0x0
+#define MX6ULL_PAD_ENET2_TX_DATA1__EPDC_SDDO12 0x00F4 0x0380 0x0000 0x9 0x0
+#define MX6ULL_PAD_ENET2_TX_EN__EPDC_SDDO13 0x00F8 0x0384 0x0000 0x9 0x0
+#define MX6ULL_PAD_ENET2_TX_CLK__EPDC_SDDO14 0x00FC 0x0388 0x0000 0x9 0x0
+#define MX6ULL_PAD_ENET2_RX_ER__EPDC_SDDO15 0x0100 0x038C 0x0000 0x9 0x0
+#define MX6ULL_PAD_LCD_CLK__EPDC_SDCLK 0x0104 0x0390 0x0000 0x9 0x0
+#define MX6ULL_PAD_LCD_ENABLE__EPDC_SDLE 0x0108 0x0394 0x0000 0x9 0x0
+#define MX6ULL_PAD_LCD_HSYNC__EPDC_SDOE 0x010C 0x0398 0x0000 0x9 0x0
+#define MX6ULL_PAD_LCD_VSYNC__EPDC_SDCE0 0x0110 0x039C 0x0000 0x9 0x0
+#define MX6ULL_PAD_LCD_RESET__EPDC_GDOE 0x0114 0x03A0 0x0000 0x9 0x0
+#define MX6ULL_PAD_LCD_DATA00__EPDC_SDDO00 0x0118 0x03A4 0x0000 0x9 0x0
+#define MX6ULL_PAD_LCD_DATA01__EPDC_SDDO01 0x011C 0x03A8 0x0000 0x9 0x0
+#define MX6ULL_PAD_LCD_DATA02__EPDC_SDDO02 0x0120 0x03AC 0x0000 0x9 0x0
+#define MX6ULL_PAD_LCD_DATA03__EPDC_SDDO03 0x0124 0x03B0 0x0000 0x9 0x0
+#define MX6ULL_PAD_LCD_DATA04__EPDC_SDDO04 0x0128 0x03B4 0x0000 0x9 0x0
+#define MX6ULL_PAD_LCD_DATA05__EPDC_SDDO05 0x012C 0x03B8 0x0000 0x9 0x0
+#define MX6ULL_PAD_LCD_DATA06__EPDC_SDDO06 0x0130 0x03BC 0x0000 0x9 0x0
+#define MX6ULL_PAD_LCD_DATA07__EPDC_SDDO07 0x0134 0x03C0 0x0000 0x9 0x0
+#define MX6ULL_PAD_LCD_DATA14__EPDC_SDSHR 0x0150 0x03DC 0x0000 0x9 0x0
+#define MX6ULL_PAD_LCD_DATA15__EPDC_GDRL 0x0154 0x03E0 0x0000 0x9 0x0
+#define MX6ULL_PAD_LCD_DATA16__EPDC_GDCLK 0x0158 0x03E4 0x0000 0x9 0x0
+#define MX6ULL_PAD_LCD_DATA17__EPDC_GDSP 0x015C 0x03E8 0x0000 0x9 0x0
+#define MX6ULL_PAD_LCD_DATA21__EPDC_SDCE1 0x016C 0x03F8 0x0000 0x9 0x0
+#define MX6ULL_PAD_CSI_MCLK__ESAI_TX3_RX2 0x01D4 0x0460 0x0000 0x9 0x0
+#define MX6ULL_PAD_CSI_PIXCLK__ESAI_TX2_RX3 0x01D8 0x0464 0x0000 0x9 0x0
+#define MX6ULL_PAD_CSI_VSYNC__ESAI_TX4_RX1 0x01DC 0x0468 0x0000 0x9 0x0
+#define MX6ULL_PAD_CSI_HSYNC__ESAI_TX1 0x01E0 0x046C 0x0000 0x9 0x0
+#define MX6ULL_PAD_CSI_DATA00__ESAI_TX_HF_CLK 0x01E4 0x0470 0x0000 0x9 0x0
+#define MX6ULL_PAD_CSI_DATA01__ESAI_RX_HF_CLK 0x01E8 0x0474 0x0000 0x9 0x0
+#define MX6ULL_PAD_CSI_DATA02__ESAI_RX_FS 0x01EC 0x0478 0x0000 0x9 0x0
+#define MX6ULL_PAD_CSI_DATA03__ESAI_RX_CLK 0x01F0 0x047C 0x0000 0x9 0x0
+#define MX6ULL_PAD_CSI_DATA04__ESAI_TX_FS 0x01F4 0x0480 0x0000 0x9 0x0
+#define MX6ULL_PAD_CSI_DATA05__ESAI_TX_CLK 0x01F8 0x0484 0x0000 0x9 0x0
+#define MX6ULL_PAD_CSI_DATA06__ESAI_TX5_RX0 0x01FC 0x0488 0x0000 0x9 0x0
+#define MX6ULL_PAD_CSI_DATA07__ESAI_T0 0x0200 0x048C 0x0000 0x9 0x0
+
+#endif /* __DTS_IMX6ULL_PINFUNC_H */
diff --git a/arch/arm/boot/dts/imx6ull.dtsi b/arch/arm/boot/dts/imx6ull.dtsi
new file mode 100644
index 0000000..dee8ab8
--- /dev/null
+++ b/arch/arm/boot/dts/imx6ull.dtsi
@@ -0,0 +1,43 @@
+/*
+ * Copyright 2016 Freescale Semiconductor, Inc.
+ *
+ * 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 "imx6ul.dtsi"
+#include "imx6ull-pinfunc.h"
--
2.7.4
^ 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