* [PATCH v4 1/4] ARM: dts: omap3: Add support for INCOstartec a83x module
From: Christoph Fritz @ 2014-02-14 14:20 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1392387656-15186-1-git-send-email-chf.fritz@googlemail.com>
INCOstartec LILLY-A83X module is a TI DM3730xx100 (OMAP3) SoC
computer-on-module.
This patch adds device tree support for most of its features.
Signed-off-by: Christoph Fritz <chf.fritz@googlemail.com>
---
arch/arm/boot/dts/omap3-lilly-a83x.dtsi | 459 +++++++++++++++++++++++++++++++
1 file changed, 459 insertions(+)
create mode 100644 arch/arm/boot/dts/omap3-lilly-a83x.dtsi
diff --git a/arch/arm/boot/dts/omap3-lilly-a83x.dtsi b/arch/arm/boot/dts/omap3-lilly-a83x.dtsi
new file mode 100644
index 0000000..6369d9f
--- /dev/null
+++ b/arch/arm/boot/dts/omap3-lilly-a83x.dtsi
@@ -0,0 +1,459 @@
+/*
+ * Copyright (C) 2014 Christoph Fritz <chf.fritzc@googlemail.com>
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ */
+
+#include "omap36xx.dtsi"
+
+/ {
+ model = "INCOstartec LILLY-A83X module (DM3730)";
+ compatible = "incostartec,omap3-lilly-a83x", "ti,omap36xx", "ti,omap3";
+
+ chosen {
+ bootargs = "console=ttyO0,115200n8 vt.global_cursor_default=0 consoleblank=0";
+ };
+
+ memory {
+ device_type = "memory";
+ reg = <0x80000000 0x8000000>; /* 128 MB */
+ };
+
+ leds {
+ compatible = "gpio-leds";
+
+ led1 {
+ label = "lilly-a83x::led1";
+ gpios = <&gpio1 29 GPIO_ACTIVE_LOW>;
+ linux,default-trigger = "default-on";
+ };
+
+ };
+
+ sound {
+ compatible = "ti,omap-twl4030";
+ ti,model = "lilly-a83x";
+
+ ti,mcbsp = <&mcbsp2>;
+ ti,codec = <&twl_audio>;
+ };
+
+ reg_vcc3: vcc3 {
+ compatible = "regulator-fixed";
+ regulator-name = "VCC3";
+ regulator-min-microvolt = <3300000>;
+ regulator-max-microvolt = <3300000>;
+ regulator-always-on;
+ };
+
+ hsusb1_phy: hsusb1_phy {
+ compatible = "usb-nop-xceiv";
+ vcc-supply = <®_vcc3>;
+ };
+};
+
+&omap3_pmx_wkup {
+ pinctrl-names = "default";
+
+ lan9221_pins: pinmux_lan9221_pins {
+ pinctrl-single,pins = <
+ OMAP3_WKUP_IOPAD(0x2a5a, PIN_INPUT | MUX_MODE4) /* reserved.gpio_129 */
+ >;
+ };
+
+ tsc2048_pins: pinmux_tsc2048_pins {
+ pinctrl-single,pins = <
+ OMAP3_WKUP_IOPAD(0x2a16, PIN_INPUT_PULLUP | MUX_MODE4) /* sys_boot6.gpio_8 */
+ >;
+ };
+
+ mmc1cd_pins: pinmux_mmc1cd_pins {
+ pinctrl-single,pins = <
+ OMAP3_WKUP_IOPAD(0x2a56, PIN_INPUT | MUX_MODE4) /* reserved.gpio_126 */
+ >;
+ };
+};
+
+&omap3_pmx_core {
+ pinctrl-names = "default";
+
+ uart1_pins: pinmux_uart1_pins {
+ pinctrl-single,pins = <
+ OMAP3_CORE1_IOPAD(0x217c, PIN_OUTPUT | MUX_MODE0) /* uart1_tx.uart1_tx */
+ OMAP3_CORE1_IOPAD(0x217e, PIN_OUTPUT | MUX_MODE0) /* uart1_rts.uart1_rts */
+ OMAP3_CORE1_IOPAD(0x2180, PIN_INPUT | MUX_MODE0) /* uart1_cts.uart1_cts */
+ OMAP3_CORE1_IOPAD(0x2182, PIN_INPUT | MUX_MODE0) /* uart1_rx.uart1_rx */
+ >;
+ };
+
+ uart2_pins: pinmux_uart2_pins {
+ pinctrl-single,pins = <
+ OMAP3_CORE1_IOPAD(0x2170, PIN_OUTPUT | MUX_MODE1) /* mcbsp3_clkx.uart2_tx */
+ OMAP3_CORE1_IOPAD(0x2172, PIN_INPUT | MUX_MODE1) /* mcbsp3_fsx.uart2_rx */
+ >;
+ };
+
+ uart3_pins: pinmux_uart3_pins {
+ pinctrl-single,pins = <
+ OMAP3_CORE1_IOPAD(0x219e, PIN_INPUT | MUX_MODE0) /* uart3_rx_irrx.uart3_rx_irrx */
+ OMAP3_CORE1_IOPAD(0x21a0, PIN_OUTPUT | MUX_MODE0) /* uart3_tx_irtx.uart3_tx_irtx */
+ >;
+ };
+
+ i2c1_pins: pinmux_i2c1_pins {
+ pinctrl-single,pins = <
+ OMAP3_CORE1_IOPAD(0x21ba ,PIN_INPUT_PULLUP | MUX_MODE0) /* i2c1_scl.i2c1_scl */
+ OMAP3_CORE1_IOPAD(0x21bc ,PIN_INPUT_PULLUP | MUX_MODE0) /* i2c1_sda.i2c1_sda */
+ >;
+ };
+
+ i2c2_pins: pinmux_i2c2_pins {
+ pinctrl-single,pins = <
+ OMAP3_CORE1_IOPAD(0x21be, PIN_INPUT | MUX_MODE0) /* i2c2_scl.i2c2_scl */
+ OMAP3_CORE1_IOPAD(0x21c0, PIN_INPUT | MUX_MODE0) /* i2c2_sda.i2c2_sda */
+ >;
+ };
+
+ i2c3_pins: pinmux_i2c3_pins {
+ pinctrl-single,pins = <
+ OMAP3_CORE1_IOPAD(0x21c2, PIN_INPUT | MUX_MODE0) /* i2c3_scl.i2c3_scl */
+ OMAP3_CORE1_IOPAD(0x21c4, PIN_INPUT | MUX_MODE0) /* i2c3_sda.i2c3_sda */
+ >;
+ };
+
+ hsusb1_pins: pinmux_hsusb1_pins {
+ pinctrl-single,pins = <
+
+ /* GPIO 182 controls USB-Hub reset. But USB-Phy its
+ * reset can't be controlled. So we clamp this GPIO to
+ * high (PIN_OFF_OUTPUT_HIGH) to always enable USB-Hub.
+ */
+
+ OMAP3_CORE1_IOPAD(0x21de, PIN_OUTPUT_PULLUP | PIN_OFF_OUTPUT_HIGH | MUX_MODE4) /* mcspi2_cs1.gpio_182 */
+ >;
+ };
+
+ hsusb_otg_pins: pinmux_hsusb_otg_pins {
+ pinctrl-single,pins = <
+ OMAP3_CORE1_IOPAD(0x21a2, PIN_INPUT | MUX_MODE0) /* hsusb0_clk.hsusb0_clk */
+ OMAP3_CORE1_IOPAD(0x21a4, PIN_OUTPUT | MUX_MODE0) /* hsusb0_stp.hsusb0_stp */
+ OMAP3_CORE1_IOPAD(0x21a6, PIN_INPUT | MUX_MODE0) /* hsusb0_dir.hsusb0_dir */
+ OMAP3_CORE1_IOPAD(0x21a8, PIN_INPUT | MUX_MODE0) /* hsusb0_nxt.hsusb0_nxt */
+ OMAP3_CORE1_IOPAD(0x21aa, PIN_INPUT | MUX_MODE0) /* hsusb0_data0.hsusb0_data0 */
+ OMAP3_CORE1_IOPAD(0x21ac, PIN_INPUT | MUX_MODE0) /* hsusb0_data1.hsusb0_data1 */
+ OMAP3_CORE1_IOPAD(0x21ae, PIN_INPUT | MUX_MODE0) /* hsusb0_data2.hsusb0_data2 */
+ OMAP3_CORE1_IOPAD(0x21b0, PIN_INPUT | MUX_MODE0) /* hsusb0_data3.hsusb0_data3 */
+ OMAP3_CORE1_IOPAD(0x21b2, PIN_INPUT | MUX_MODE0) /* hsusb0_data4.hsusb0_data4 */
+ OMAP3_CORE1_IOPAD(0x21b4, PIN_INPUT | MUX_MODE0) /* hsusb0_data5.hsusb0_data5 */
+ OMAP3_CORE1_IOPAD(0x21b6, PIN_INPUT | MUX_MODE0) /* hsusb0_data6.hsusb0_data6 */
+ OMAP3_CORE1_IOPAD(0x21b8, PIN_INPUT | MUX_MODE0) /* hsusb0_data7.hsusb0_data7 */
+ >;
+ };
+
+ mmc1_pins: pinmux_mmc1_pins {
+ pinctrl-single,pins = <
+ OMAP3_CORE1_IOPAD(0x2144, PIN_INPUT_PULLUP | MUX_MODE0) /* sdmmc1_clk.sdmmc1_clk */
+ OMAP3_CORE1_IOPAD(0x2146, PIN_INPUT_PULLUP | MUX_MODE0) /* sdmmc1_cmd.sdmmc1_cmd */
+ OMAP3_CORE1_IOPAD(0x2148, PIN_INPUT_PULLUP | MUX_MODE0) /* sdmmc1_dat0.sdmmc1_dat0 */
+ OMAP3_CORE1_IOPAD(0x214a, PIN_INPUT_PULLUP | MUX_MODE0) /* sdmmc1_dat1.sdmmc1_dat1 */
+ OMAP3_CORE1_IOPAD(0x214c, PIN_INPUT_PULLUP | MUX_MODE0) /* sdmmc1_dat2.sdmmc1_dat2 */
+ OMAP3_CORE1_IOPAD(0x214e, PIN_INPUT_PULLUP | MUX_MODE0) /* sdmmc1_dat3.sdmmc1_dat3 */
+ >;
+ };
+
+ spi2_pins: pinmux_spi2_pins {
+ pinctrl-single,pins = <
+ OMAP3_CORE1_IOPAD(0x21d6, PIN_INPUT_PULLDOWN | MUX_MODE0) /* mcspi2_clk.mcspi2_clk */
+ OMAP3_CORE1_IOPAD(0x21d8, PIN_INPUT_PULLDOWN | MUX_MODE0) /* mcspi2_simo.mcspi2_simo */
+ OMAP3_CORE1_IOPAD(0x21da, PIN_INPUT_PULLDOWN | MUX_MODE0) /* mcspi2_somi.mcspi2_somi */
+ OMAP3_CORE1_IOPAD(0x21dc, PIN_OUTPUT | MUX_MODE0) /* mcspi2_cs0.mcspi2_cs0 */
+ >;
+ };
+};
+
+&omap3_pmx_core2 {
+ pinctrl-names = "default";
+ pinctrl-0 = <
+ &hsusb1_2_pins
+ >;
+
+ hsusb1_2_pins: pinmux_hsusb1_2_pins {
+ pinctrl-single,pins = <
+ OMAP3630_CORE2_IOPAD(0x25d8, PIN_OUTPUT | MUX_MODE3) /* etk_clk.hsusb1_stp */
+ OMAP3630_CORE2_IOPAD(0x25da, PIN_INPUT | MUX_MODE3) /* etk_ctl.hsusb1_clk */
+ OMAP3630_CORE2_IOPAD(0x25dc, PIN_INPUT | MUX_MODE3) /* etk_d0.hsusb1_data0 */
+ OMAP3630_CORE2_IOPAD(0x25de, PIN_INPUT | MUX_MODE3) /* etk_d1.hsusb1_data1 */
+ OMAP3630_CORE2_IOPAD(0x25e0, PIN_INPUT | MUX_MODE3) /* etk_d2.hsusb1_data2 */
+ OMAP3630_CORE2_IOPAD(0x25e2, PIN_INPUT | MUX_MODE3) /* etk_d3.hsusb1_data7 */
+ OMAP3630_CORE2_IOPAD(0x25e4, PIN_INPUT | MUX_MODE3) /* etk_d4.hsusb1_data4 */
+ OMAP3630_CORE2_IOPAD(0x25e6, PIN_INPUT | MUX_MODE3) /* etk_d5.hsusb1_data5 */
+ OMAP3630_CORE2_IOPAD(0x25e8, PIN_INPUT | MUX_MODE3) /* etk_d6.hsusb1_data6 */
+ OMAP3630_CORE2_IOPAD(0x25ea, PIN_INPUT | MUX_MODE3) /* etk_d7.hsusb1_data3 */
+ OMAP3630_CORE2_IOPAD(0x25ec, PIN_INPUT | MUX_MODE3) /* etk_d8.hsusb1_dir */
+ OMAP3630_CORE2_IOPAD(0x25ee, PIN_INPUT | MUX_MODE3) /* etk_d9.hsusb1_nxt */
+ >;
+ };
+
+ gpio1_pins: pinmux_gpio1_pins {
+ pinctrl-single,pins = <
+ OMAP3630_CORE2_IOPAD(0x25fa, PIN_OUTPUT_PULLDOWN | MUX_MODE4) /* etk_d15.gpio_29 */
+ >;
+ };
+
+};
+
+&gpio1 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&gpio1_pins>;
+};
+
+&gpio6 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&hsusb1_pins>;
+};
+
+&i2c1 {
+ clock-frequency = <2600000>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&i2c1_pins>;
+
+ twl: twl at 48 {
+ reg = <0x48>;
+ interrupts = <7>; /* SYS_NIRQ cascaded to intc */
+ interrupt-parent = <&intc>;
+
+ twl_audio: audio {
+ compatible = "ti,twl4030-audio";
+ codec {
+ };
+ };
+ };
+};
+
+#include "twl4030.dtsi"
+#include "twl4030_omap3.dtsi"
+
+&twl {
+ vmmc1: regulator-vmmc1 {
+ regulator-always-on;
+ };
+
+ vdd1: regulator-vdd1 {
+ regulator-always-on;
+ };
+
+ vdd2: regulator-vdd2 {
+ regulator-always-on;
+ };
+};
+
+&i2c2 {
+ clock-frequency = <2600000>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&i2c2_pins>;
+};
+
+&i2c3 {
+ clock-frequency = <2600000>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&i2c3_pins>;
+ gpiom1: gpio at 20 {
+ compatible = "mcp,mcp23017";
+ gpio-controller;
+ #gpio-cells = <2>;
+ reg = <0x20>;
+ };
+};
+
+&uart1 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&uart1_pins>;
+};
+
+&uart2 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&uart2_pins>;
+};
+
+&uart3 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&uart3_pins>;
+};
+
+&uart4 {
+ status = "disabled";
+};
+
+&mmc1 {
+ cd-gpios = <&gpio4 30 IRQ_TYPE_LEVEL_LOW>;
+ cd-inverted;
+ vmmc-supply = <&vmmc1>;
+ bus-width = <4>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&mmc1_pins &mmc1cd_pins>;
+ cap-sdio-irq;
+ cap-sd-highspeed;
+ cap-mmc-highspeed;
+};
+
+&mmc2 {
+ status = "disabled";
+};
+
+&mmc3 {
+ status = "disabled";
+};
+
+&mcspi2 {
+ status = "okay";
+ pinctrl-names = "default";
+ pinctrl-0 = <&spi2_pins>;
+
+ tsc2046 at 0 {
+ reg = <0>; /* CS0 */
+ compatible = "ti,tsc2046";
+ interrupt-parent = <&gpio1>;
+ interrupts = <8 0>; /* boot6 / gpio_8 */
+ spi-max-frequency = <1000000>;
+ pendown-gpio = <&gpio1 8 0>;
+ vcc-supply = <®_vcc3>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&tsc2048_pins>;
+
+ ti,x-min = <300>;
+ ti,x-max = <3000>;
+ ti,y-min = <600>;
+ ti,y-max = <3600>;
+ ti,x-plate-ohms = <80>;
+ ti,pressure-max = <255>;
+ ti,swap-xy;
+
+ linux,wakeup;
+ };
+};
+
+&usbhsehci {
+ phys = <&hsusb1_phy>;
+};
+
+&usbhshost {
+ pinctrl-names = "default";
+ pinctrl-0 = <&hsusb1_2_pins>;
+ num-ports = <2>;
+ port1-mode = "ehci-phy";
+};
+
+&usb_otg_hs {
+ pinctrl-names = "default";
+ pinctrl-0 = <&hsusb_otg_pins>;
+ interface-type = <0>;
+ usb-phy = <&usb2_phy>;
+ phys = <&usb2_phy>;
+ phy-names = "usb2-phy";
+ mode = <3>;
+ power = <50>;
+};
+
+&gpmc {
+ ranges = <0 0 0x30000000 0x1000000>,
+ <7 0 0x15000000 0x01000000>;
+
+ nand at 0,0 {
+ reg = <0 0 0x1000000>;
+ nand-bus-width = <16>;
+ ti,nand-ecc-opt = "bch8";
+ /* no elm on omap3 */
+
+ gpmc,mux-add-data = <0>;
+ gpmc,device-nand;
+ gpmc,device-width = <2>;
+ gpmc,wait-pin = <0>;
+ gpmc,wait-monitoring-ns = <0>;
+ gpmc,burst-length= <4>;
+ gpmc,cs-on-ns = <0>;
+ gpmc,cs-rd-off-ns = <100>;
+ gpmc,cs-wr-off-ns = <100>;
+ gpmc,adv-on-ns = <0>;
+ gpmc,adv-rd-off-ns = <100>;
+ gpmc,adv-wr-off-ns = <100>;
+ gpmc,oe-on-ns = <5>;
+ gpmc,oe-off-ns = <75>;
+ gpmc,we-on-ns = <5>;
+ gpmc,we-off-ns = <75>;
+ gpmc,rd-cycle-ns = <100>;
+ gpmc,wr-cycle-ns = <100>;
+ gpmc,access-ns = <60>;
+ gpmc,page-burst-access-ns = <5>;
+ gpmc,bus-turnaround-ns = <0>;
+ gpmc,cycle2cycle-samecsen;
+ gpmc,cycle2cycle-delay-ns = <50>;
+ gpmc,wr-data-mux-bus-ns = <75>;
+ gpmc,wr-access-ns = <155>;
+
+ #address-cells = <1>;
+ #size-cells = <1>;
+
+ partition at 0 {
+ label = "MLO";
+ reg = <0 0x80000>;
+ };
+
+ partition at 0x80000 {
+ label = "u-boot";
+ reg = <0x80000 0x1e0000>;
+ };
+
+ partition at 0x260000 {
+ label = "u-boot-environment";
+ reg = <0x260000 0x20000>;
+ };
+
+ partition at 0x280000 {
+ label = "kernel";
+ reg = <0x280000 0x500000>;
+ };
+
+ partition at 0x780000 {
+ label = "filesystem";
+ reg = <0x780000 0xf880000>;
+ };
+ };
+
+ ethernet at 7,0 {
+ compatible = "smsc,lan9221", "smsc,lan9115";
+ bank-width = <2>;
+ gpmc,mux-add-data = <2>;
+ gpmc,cs-on-ns = <10>;
+ gpmc,cs-rd-off-ns = <60>;
+ gpmc,cs-wr-off-ns = <60>;
+ gpmc,adv-on-ns = <0>;
+ gpmc,adv-rd-off-ns = <10>;
+ gpmc,adv-wr-off-ns = <10>;
+ gpmc,oe-on-ns = <10>;
+ gpmc,oe-off-ns = <60>;
+ gpmc,we-on-ns = <10>;
+ gpmc,we-off-ns = <60>;
+ gpmc,rd-cycle-ns = <100>;
+ gpmc,wr-cycle-ns = <100>;
+ gpmc,access-ns = <50>;
+ gpmc,page-burst-access-ns = <5>;
+ gpmc,bus-turnaround-ns = <0>;
+ gpmc,cycle2cycle-delay-ns = <75>;
+ gpmc,wr-data-mux-bus-ns = <15>;
+ gpmc,wr-access-ns = <75>;
+ gpmc,cycle2cycle-samecsen;
+ gpmc,cycle2cycle-diffcsen;
+ vddvario-supply = <®_vcc3>;
+ vdd33a-supply = <®_vcc3>;
+ reg-io-width = <4>;
+ interrupt-parent = <&gpio5>;
+ interrupts = <1 0x2>;
+ reg = <7 0 0xff>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&lan9221_pins>;
+ phy-mode = "mii";
+ };
+};
--
1.7.10.4
^ permalink raw reply related
* [PATCH v4 2/4] ARM: dts: omap3: Add support for INCOstartec DBB056 baseboard
From: Christoph Fritz @ 2014-02-14 14:20 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1392387656-15186-1-git-send-email-chf.fritz@googlemail.com>
INCOstartec LILLY-DBB056 is a carrier board (baseboard) for
computer-on-module LILLY-A83X.
This patch adds device-tree support for most of its features.
Signed-off-by: Christoph Fritz <chf.fritz@googlemail.com>
---
arch/arm/boot/dts/Makefile | 1 +
arch/arm/boot/dts/omap3-lilly-dbb056.dts | 170 ++++++++++++++++++++++++++++++
2 files changed, 171 insertions(+)
create mode 100644 arch/arm/boot/dts/omap3-lilly-dbb056.dts
diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index b9d6a8b..cee7564 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -212,6 +212,7 @@ dtb-$(CONFIG_ARCH_OMAP2PLUS) += omap2420-h4.dtb \
omap3-gta04.dtb \
omap3-igep0020.dtb \
omap3-igep0030.dtb \
+ omap3-lilly-dbb056.dtb \
omap3-zoom3.dtb \
omap4-panda.dtb \
omap4-panda-a4.dtb \
diff --git a/arch/arm/boot/dts/omap3-lilly-dbb056.dts b/arch/arm/boot/dts/omap3-lilly-dbb056.dts
new file mode 100644
index 0000000..834f7c6
--- /dev/null
+++ b/arch/arm/boot/dts/omap3-lilly-dbb056.dts
@@ -0,0 +1,170 @@
+/*
+ * Copyright (C) 2014 Christoph Fritz <chf.fritzc@googlemail.com>
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ */
+/dts-v1/;
+
+#include "omap3-lilly-a83x.dtsi"
+
+/ {
+ model = "INCOstartec LILLY-DBB056 (DM3730)";
+ compatible = "incostartec,omap3-lilly-dbb056", "incostartec,omap3-lilly-a83x", "ti,omap36xx", "ti,omap3";
+};
+
+&twl {
+ vaux2: regulator-vaux2 {
+ compatible = "ti,twl4030-vaux2";
+ regulator-min-microvolt = <2800000>;
+ regulator-max-microvolt = <2800000>;
+ regulator-always-on;
+ };
+};
+
+&omap3_pmx_core {
+ pinctrl-names = "default";
+ pinctrl-0 = <&lcd_pins>;
+
+ lan9117_pins: pinmux_lan9117_pins {
+ pinctrl-single,pins = <
+ OMAP3_CORE1_IOPAD(0x2114, PIN_INPUT | MUX_MODE4) /* cam_fld.gpio_98 */
+ >;
+ };
+
+ gpio4_pins: pinmux_gpio4_pins {
+ pinctrl-single,pins = <
+ OMAP3_CORE1_IOPAD(0x212e, PIN_INPUT | MUX_MODE4) /* cam_xclkb.gpio_111 -> sja1000 IRQ */
+ >;
+ };
+
+ gpio5_pins: pinmux_gpio5_pins {
+ pinctrl-single,pins = <
+ OMAP3_CORE1_IOPAD(0x218c, PIN_OUTPUT | PIN_OFF_OUTPUT_HIGH | MUX_MODE4) /* mcbsp1_clk.gpio_156 -> enable DSS */
+ >;
+ };
+
+ lcd_pins: pinmux_lcd_pins {
+ pinctrl-single,pins = <
+ OMAP3_CORE1_IOPAD(0x20d4, PIN_OUTPUT | MUX_MODE0) /* dss_pclk.dss_pclk */
+ OMAP3_CORE1_IOPAD(0x20d6, PIN_OUTPUT | MUX_MODE0) /* dss_hsync.dss_hsync */
+ OMAP3_CORE1_IOPAD(0x20d8, PIN_OUTPUT | MUX_MODE0) /* dss_vsync.dss_vsync */
+ OMAP3_CORE1_IOPAD(0x20da, PIN_OUTPUT | MUX_MODE0) /* dss_acbias.dss_acbias */
+ OMAP3_CORE1_IOPAD(0x20dc, PIN_OUTPUT | MUX_MODE0) /* dss_data0.dss_data0 */
+ OMAP3_CORE1_IOPAD(0x20de, PIN_OUTPUT | MUX_MODE0) /* dss_data1.dss_data1 */
+ OMAP3_CORE1_IOPAD(0x20e0, PIN_OUTPUT | MUX_MODE0) /* dss_data2.dss_data2 */
+ OMAP3_CORE1_IOPAD(0x20e2, PIN_OUTPUT | MUX_MODE0) /* dss_data3.dss_data3 */
+ OMAP3_CORE1_IOPAD(0x20e4, PIN_OUTPUT | MUX_MODE0) /* dss_data4.dss_data4 */
+ OMAP3_CORE1_IOPAD(0x20e6, PIN_OUTPUT | MUX_MODE0) /* dss_data5.dss_data5 */
+ OMAP3_CORE1_IOPAD(0x20e8, PIN_OUTPUT | MUX_MODE0) /* dss_data6.dss_data6 */
+ OMAP3_CORE1_IOPAD(0x20ea, PIN_OUTPUT | MUX_MODE0) /* dss_data7.dss_data7 */
+ OMAP3_CORE1_IOPAD(0x20ec, PIN_OUTPUT | MUX_MODE0) /* dss_data8.dss_data8 */
+ OMAP3_CORE1_IOPAD(0x20ee, PIN_OUTPUT | MUX_MODE0) /* dss_data9.dss_data9 */
+ OMAP3_CORE1_IOPAD(0x20f0, PIN_OUTPUT | MUX_MODE0) /* dss_data10.dss_data10 */
+ OMAP3_CORE1_IOPAD(0x20f2, PIN_OUTPUT | MUX_MODE0) /* dss_data11.dss_data11 */
+ OMAP3_CORE1_IOPAD(0x20f4, PIN_OUTPUT | MUX_MODE0) /* dss_data12.dss_data12 */
+ OMAP3_CORE1_IOPAD(0x20f6, PIN_OUTPUT | MUX_MODE0) /* dss_data13.dss_data13 */
+ OMAP3_CORE1_IOPAD(0x20f8, PIN_OUTPUT | MUX_MODE0) /* dss_data14.dss_data14 */
+ OMAP3_CORE1_IOPAD(0x20fa, PIN_OUTPUT | MUX_MODE0) /* dss_data15.dss_data15 */
+ OMAP3_CORE1_IOPAD(0x20fc, PIN_OUTPUT | MUX_MODE0) /* dss_data16.dss_data16 */
+ OMAP3_CORE1_IOPAD(0x20fe, PIN_OUTPUT | MUX_MODE0) /* dss_data17.dss_data17 */
+ >;
+ };
+
+ mmc2_pins: pinmux_mmc2_pins {
+ pinctrl-single,pins = <
+ OMAP3_CORE1_IOPAD(0x2158, PIN_INPUT_PULLUP | MUX_MODE0) /* sdmmc2_clk.sdmmc2_clk */
+ OMAP3_CORE1_IOPAD(0x215a, PIN_INPUT_PULLUP | MUX_MODE0) /* sdmmc2_cmd.sdmmc2_cmd */
+ OMAP3_CORE1_IOPAD(0x215c, PIN_INPUT_PULLUP | MUX_MODE0) /* sdmmc2_dat0.sdmmc2_dat0 */
+ OMAP3_CORE1_IOPAD(0x215e, PIN_INPUT_PULLUP | MUX_MODE0) /* sdmmc2_dat1.sdmmc2_dat1 */
+ OMAP3_CORE1_IOPAD(0x2160, PIN_INPUT_PULLUP | MUX_MODE0) /* sdmmc2_dat2.sdmmc2_dat2 */
+ OMAP3_CORE1_IOPAD(0x2162, PIN_INPUT_PULLUP | MUX_MODE0) /* sdmmc2_dat3.sdmmc2_dat3 */
+ OMAP3_CORE1_IOPAD(0x2164, PIN_OUTPUT | MUX_MODE1) /* sdmmc2_dat4.sdmmc2_dir_dat0 */
+ OMAP3_CORE1_IOPAD(0x2166, PIN_OUTPUT | MUX_MODE1) /* sdmmc2_dat5.sdmmc2_dir_dat1 */
+ OMAP3_CORE1_IOPAD(0x2168, PIN_OUTPUT | MUX_MODE1) /* sdmmc2_dat6.sdmmc2_dir_cmd */
+ OMAP3_CORE1_IOPAD(0x216a, PIN_INPUT | MUX_MODE1) /* sdmmc2_dat7.sdmmc2_clkin */
+ OMAP3_CORE1_IOPAD(0x219a, PIN_INPUT_PULLUP | MUX_MODE4) /* uart3_cts_rctx.gpio_163 -> wp */
+ OMAP3_CORE1_IOPAD(0x219c, PIN_INPUT_PULLUP | MUX_MODE4) /* uart3_rts_sd.gpio_164 -> cd */
+ >;
+ };
+
+ spi1_pins: pinmux_spi1_pins {
+ pinctrl-single,pins = <
+ OMAP3_CORE1_IOPAD(0x21c8, PIN_INPUT | MUX_MODE0) /* mcspi1_clk.mcspi1_clk */
+ OMAP3_CORE1_IOPAD(0x21ca, PIN_INPUT | MUX_MODE0) /* mcspi1_simo.mcspi1_simo */
+ OMAP3_CORE1_IOPAD(0x21cc, PIN_INPUT | MUX_MODE0) /* mcspi1_somi.mcspi1_somi */
+ OMAP3_CORE1_IOPAD(0x21ce, PIN_INPUT_PULLDOWN | MUX_MODE0) /* mcspi1_cs0.mcspi1_cs0 */
+ >;
+ };
+};
+
+&gpio4 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&gpio4_pins>;
+};
+
+&gpio5 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&gpio5_pins>;
+};
+
+&mmc2 {
+ status = "okay";
+ bus-width = <4>;
+ vmmc-supply = <&vmmc1>;
+ cd-gpios = <&gpio6 4 0>; /* gpio_164 */
+ wp-gpios = <&gpio6 3 0>; /* gpio_163 */
+ pinctrl-names = "default";
+ pinctrl-0 = <&mmc2_pins>;
+ ti,dual-volt;
+};
+
+&mcspi1 {
+ status = "okay";
+ pinctrl-names = "default";
+ pinctrl-0 = <&spi1_pins>;
+};
+
+&gpmc {
+ ranges = <0 0 0x30000000 0x1000000>, /* nand assigned by COM a83x */
+ <4 0 0x20000000 0x01000000>,
+ <7 0 0x15000000 0x01000000>; /* eth assigend by COM a83x */
+
+ ethernet at 4,0 {
+ compatible = "smsc,lan9117", "smsc,lan9115";
+ bank-width = <2>;
+ gpmc,mux-add-data = <2>;
+ gpmc,cs-on-ns = <10>;
+ gpmc,cs-rd-off-ns = <65>;
+ gpmc,cs-wr-off-ns = <65>;
+ gpmc,adv-on-ns = <0>;
+ gpmc,adv-rd-off-ns = <10>;
+ gpmc,adv-wr-off-ns = <10>;
+ gpmc,oe-on-ns = <10>;
+ gpmc,oe-off-ns = <65>;
+ gpmc,we-on-ns = <10>;
+ gpmc,we-off-ns = <65>;
+ gpmc,rd-cycle-ns = <100>;
+ gpmc,wr-cycle-ns = <100>;
+ gpmc,access-ns = <60>;
+ gpmc,page-burst-access-ns = <5>;
+ gpmc,bus-turnaround-ns = <0>;
+ gpmc,cycle2cycle-delay-ns = <75>;
+ gpmc,wr-data-mux-bus-ns = <15>;
+ gpmc,wr-access-ns = <75>;
+ gpmc,cycle2cycle-samecsen;
+ gpmc,cycle2cycle-diffcsen;
+ vddvario-supply = <®_vcc3>;
+ vdd33a-supply = <®_vcc3>;
+ reg-io-width = <4>;
+ interrupt-parent = <&gpio4>;
+ interrupts = <2 0x2>;
+ reg = <4 0 0xff>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&lan9117_pins>;
+ phy-mode = "mii";
+ smsc,force-internal-phy;
+ };
+};
--
1.7.10.4
^ permalink raw reply related
* [PATCH v4 3/4] ARM: OMAP2+: add legacy display for omap3 DBB056
From: Christoph Fritz @ 2014-02-14 14:20 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1392387656-15186-1-git-send-email-chf.fritz@googlemail.com>
Full device tree support for omapdss is not yet accomplished. Until
then, init display by legacy platform code.
Signed-off-by: Christoph Fritz <chf.fritz@googlemail.com>
---
arch/arm/mach-omap2/dss-common.c | 49 ++++++++++++++++++++++++++++++++++++
arch/arm/mach-omap2/dss-common.h | 1 +
arch/arm/mach-omap2/pdata-quirks.c | 8 +++++-
3 files changed, 57 insertions(+), 1 deletion(-)
diff --git a/arch/arm/mach-omap2/dss-common.c b/arch/arm/mach-omap2/dss-common.c
index dadccc9..b8b4e39 100644
--- a/arch/arm/mach-omap2/dss-common.c
+++ b/arch/arm/mach-omap2/dss-common.c
@@ -257,3 +257,52 @@ void __init omap3_igep2_display_init_of(void)
platform_device_register(&omap3_igep2_tfp410_device);
platform_device_register(&omap3_igep2_dvi_connector_device);
}
+
+/* OMAP3 dbb056 data */
+
+#define DBB056_DISPLAY_ENABLE_GPIO 156
+
+static const struct display_timing dbb056_lcd_videomode = {
+ .pixelclock = { 0, 19200000, 0 },
+
+ .hactive = { 0, 640, 0 },
+ .hfront_porch = { 0, 104, 0 },
+ .hback_porch = { 0, 8, 0 },
+ .hsync_len = { 0, 8, 0 },
+
+ .vactive = { 0, 480, 0 },
+ .vfront_porch = { 0, 104, 0 },
+ .vback_porch = { 0, 8, 0 },
+ .vsync_len = { 0, 8, 0 },
+
+ .flags = DISPLAY_FLAGS_HSYNC_LOW | DISPLAY_FLAGS_VSYNC_LOW |
+ DISPLAY_FLAGS_DE_HIGH | DISPLAY_FLAGS_PIXDATA_NEGEDGE,
+};
+
+static struct panel_dpi_platform_data dbb056_lcd_pdata = {
+ .name = "lcd",
+ .source = "dpi.0",
+
+ .data_lines = 18,
+
+ .display_timing = &dbb056_lcd_videomode,
+
+ .enable_gpio = DBB056_DISPLAY_ENABLE_GPIO,
+ .backlight_gpio = -1,
+};
+
+static struct platform_device dbb056_lcd_device = {
+ .name = "panel-dpi",
+ .id = 0,
+ .dev.platform_data = &dbb056_lcd_pdata,
+};
+
+static struct omap_dss_board_info omap_dbb056_dss_data = {
+ .default_display_name = "lcd",
+};
+
+void __init omap3_dbb056_display_init_of(void)
+{
+ platform_device_register(&dbb056_lcd_device);
+ omap_display_init(&omap_dbb056_dss_data);
+}
diff --git a/arch/arm/mach-omap2/dss-common.h b/arch/arm/mach-omap2/dss-common.h
index a9becf0..a125b55 100644
--- a/arch/arm/mach-omap2/dss-common.h
+++ b/arch/arm/mach-omap2/dss-common.h
@@ -9,5 +9,6 @@
void __init omap4_panda_display_init_of(void);
void __init omap_4430sdp_display_init_of(void);
void __init omap3_igep2_display_init_of(void);
+void __init omap3_dbb056_display_init_of(void);
#endif
diff --git a/arch/arm/mach-omap2/pdata-quirks.c b/arch/arm/mach-omap2/pdata-quirks.c
index 3d5b24d..435a823 100644
--- a/arch/arm/mach-omap2/pdata-quirks.c
+++ b/arch/arm/mach-omap2/pdata-quirks.c
@@ -169,6 +169,11 @@ static void __init am3517_evm_legacy_init(void)
omap_ctrl_writel(v, AM35XX_CONTROL_IP_SW_RESET);
omap_ctrl_readl(AM35XX_CONTROL_IP_SW_RESET); /* OCP barrier */
}
+
+static void __init omap3_dbb056_legacy_init(void)
+{
+ omap3_dbb056_display_init_of();
+}
#endif /* CONFIG_ARCH_OMAP3 */
#ifdef CONFIG_ARCH_OMAP4
@@ -259,10 +264,11 @@ struct of_dev_auxdata omap_auxdata_lookup[] __initdata = {
static struct pdata_init pdata_quirks[] __initdata = {
#ifdef CONFIG_ARCH_OMAP3
{ "compulab,omap3-sbc-t3730", omap3_sbc_t3730_legacy_init, },
+ { "incostartec,omap3-lilly-dbb056", omap3_dbb056_legacy_init, },
+ { "isee,omap3-igep0020", omap3_igep0020_legacy_init, },
{ "nokia,omap3-n900", hsmmc2_internal_input_clk, },
{ "nokia,omap3-n9", hsmmc2_internal_input_clk, },
{ "nokia,omap3-n950", hsmmc2_internal_input_clk, },
- { "isee,omap3-igep0020", omap3_igep0020_legacy_init, },
{ "ti,omap3-evm-37xx", omap3_evm_legacy_init, },
{ "ti,omap3-zoom3", omap3_zoom_legacy_init, },
{ "ti,am3517-evm", am3517_evm_legacy_init, },
--
1.7.10.4
^ permalink raw reply related
* [PATCH v4 4/4] ARM: OMAP2+: Add pdata quirk for sys_clkout2 for omap3 DBB056
From: Christoph Fritz @ 2014-02-14 14:20 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1392387656-15186-1-git-send-email-chf.fritz@googlemail.com>
Full device tree support for clock control, especially to set frequencies,
is not yet accomplished. Until then, configure the 24Mhz of sys_clkout2 to
feed an USB-Hub here.
Signed-off-by: Christoph Fritz <chf.fritz@googlemail.com>
---
arch/arm/mach-omap2/pdata-quirks.c | 37 ++++++++++++++++++++++++++++++++++++
1 file changed, 37 insertions(+)
diff --git a/arch/arm/mach-omap2/pdata-quirks.c b/arch/arm/mach-omap2/pdata-quirks.c
index 435a823..e36ac3f 100644
--- a/arch/arm/mach-omap2/pdata-quirks.c
+++ b/arch/arm/mach-omap2/pdata-quirks.c
@@ -172,6 +172,43 @@ static void __init am3517_evm_legacy_init(void)
static void __init omap3_dbb056_legacy_init(void)
{
+ struct clk *clkout2;
+ struct clk *cm96fck;
+
+ /* Reparent clkout2 to 96M_FCK */
+ pr_info("%s: Late Reparent clkout2 to 96M_FCK\n", __func__);
+ clkout2 = clk_get(NULL, "clkout2_src_ck");
+ if (clkout2 < 0) {
+ pr_err("a83x-quirk: couldn't get clkout2_src_ck\n");
+ return;
+ }
+ cm96fck = clk_get(NULL, "cm_96m_fck");
+ if (cm96fck < 0) {
+ pr_err("a83x-quirk: couldn't get cm_96m_fck\n");
+ return;
+ }
+ if (clk_set_parent(clkout2, cm96fck) < 0) {
+ pr_err("a83x-quirk: couldn't reparent clkout2_src_ck\n");
+ return;
+ }
+
+ /* Set clkout2 to 24MHz for internal usb hub*/
+ pr_info("%s: Set clkout2 to 24MHz for internal usb hub\n", __func__);
+ clkout2 = clk_get(NULL, "sys_clkout2");
+ if (clkout2 < 0) {
+ pr_err("%s: couldn't get sys_clkout2\n", __func__);
+ return;
+ }
+ if (clk_set_rate(clkout2, 24000000) < 0) {
+ pr_err("%s: couldn't set sys_clkout2 rate\n", __func__);
+ return;
+ }
+ if (clk_prepare_enable(clkout2) < 0) {
+ pr_err("%s: couldn't enable sys_clkout2\n", __func__);
+ return;
+ }
+
+ /* Initialize display */
omap3_dbb056_display_init_of();
}
#endif /* CONFIG_ARCH_OMAP3 */
--
1.7.10.4
^ permalink raw reply related
* [PATCH 26/27] ARM: shmobile: lager-reference: Enable CMT0 in device tree
From: Laurent Pinchart @ 2014-02-14 14:22 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <52FE2498.8040609@cogentembedded.com>
Hi Sergei,
On Friday 14 February 2014 18:13:44 Sergei Shtylyov wrote:
> On 14-02-2014 17:48, Laurent Pinchart wrote:
> >>> Enable the CMT0 device and configure channel 0 as a clock event
> >>> provider.
> >>>
> >>> Signed-off-by: Laurent Pinchart
> >>> <laurent.pinchart+renesas@ideasonboard.com>
> >>>
> >>> diff --git a/arch/arm/mach-shmobile/include/mach/r8a7790.h
> >>> b/arch/arm/mach-shmobile/include/mach/r8a7790.h index 0b95bab..62b31f3
> >>> 100644 --- a/arch/arm/mach-shmobile/include/mach/r8a7790.h
> >>> +++ b/arch/arm/mach-shmobile/include/mach/r8a7790.h
> >>> @@ -29,7 +29,6 @@ enum {
> >>> };
> >>>
> >>> void r8a7790_add_standard_devices(void);
> >>> -void r8a7790_add_dt_devices(void);
> >>> void r8a7790_clock_init(void);
> >>> void r8a7790_pinmux_init(void);
> >>> void r8a7790_pm_init(void);
> >>> diff --git a/arch/arm/mach-shmobile/setup-r8a7790.c
> >>> b/arch/arm/mach-shmobile/setup-r8a7790.c index 3e5813f..462c81f 100644
> >>> --- a/arch/arm/mach-shmobile/setup-r8a7790.c
> >>> +++ b/arch/arm/mach-shmobile/setup-r8a7790.c
> >>> @@ -294,11 +294,6 @@ static struct resource cmt0_resources[] = {
> >>> &cmt##idx##_platform_data, \
> >>> sizeof(struct sh_timer_config))
> >>>
> >>> -void __init r8a7790_add_dt_devices(void)
> >>> -{
> >>> - r8a7790_register_cmt(0);
> >>> -}
> >>> -
> >>> void __init r8a7790_add_standard_devices(void)
> >>> {
> >>> r8a7790_register_scif(0);
> >>> @@ -311,7 +306,7 @@ void __init r8a7790_add_standard_devices(void)
> >>> r8a7790_register_scif(7);
> >>> r8a7790_register_scif(8);
> >>> r8a7790_register_scif(9);
> >>> - r8a7790_add_dt_devices();
> >>> + r8a7790_register_cmt(0);
> >>> r8a7790_register_irqc(0);
> >>> r8a7790_register_thermal();
> >>> }
> >>>
> >> IMHO, these 2 files should be split into a separate patch.
> >
> > That could easily be done, but why ?
>
> It does not seem necessary to combine these changes in one patch. Remember,
> Simon has separate branches for boards and SoCs. So finally it's up to him
> to decide on this...
Right, but in this case I need to remove the CMT platform device registration
from r8a7790_add_dt_devices() at the same time as I enable it in DT, otherwise
we'll have two instances of the same device.
--
Regards,
Laurent Pinchart
^ permalink raw reply
* [PATCH] KVM: ARM: vgic: plug irq injection race
From: Marc Zyngier @ 2014-02-14 14:28 UTC (permalink / raw)
To: linux-arm-kernel
As it stands, nothing prevents userspace from injecting an interrupt
before the guest's GIC is actually initialized.
This goes unnoticed so far (as everything is pretty much statically
allocated), but ends up exploding in a spectacular way once we switch
to a more dynamic allocation (the GIC data structure isn't there yet).
The fix is to test for the "ready" flag in the VGIC distributor before
trying to inject the interrupt. Note that in order to avoid breaking
userspace, we have to ignore what is essentially an error.
Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
---
virt/kvm/arm/vgic.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/virt/kvm/arm/vgic.c b/virt/kvm/arm/vgic.c
index be456ce..d40fe61 100644
--- a/virt/kvm/arm/vgic.c
+++ b/virt/kvm/arm/vgic.c
@@ -1386,7 +1386,8 @@ out:
int kvm_vgic_inject_irq(struct kvm *kvm, int cpuid, unsigned int irq_num,
bool level)
{
- if (vgic_update_irq_state(kvm, cpuid, irq_num, level))
+ if (likely(vgic_initialized(kvm)) &&
+ vgic_update_irq_state(kvm, cpuid, irq_num, level))
vgic_kick_vcpus(kvm);
return 0;
--
1.8.3.4
^ permalink raw reply related
* [PATCH RESEND] ARM: mcpm: Make all mcpm functions notrace
From: Sudeep Holla @ 2014-02-14 14:33 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1392279975.3469.4.camel@linaro1.home>
Hi Tixy,
On 13/02/14 08:26, Jon Medhurst (Tixy) wrote:
> From: Dave Martin <dave.martin@linaro.org>
>
> The functions in mcpm_entry.c are mostly intended for use during
> scary cache and coherency disabling sequences, or do other things
> which confuse trace ... like powering a CPU down and not
> returning. Similarly for the backend code.
>
> For simplicity, this patch just makes whole files notrace.
> There should be more than enough traceable points on the paths to
> these functions, but we can be more fine-grained later if there is
> a need for it.
>
> Signed-off-by: Dave Martin <dave.martin@linaro.org>
>
> Also added spc.o to the list of files as it contains functions used by
> MCPM code which have comments comments like: "might be used in code
> paths where normal cacheable locks are not working"
>
Just realised that spc.c now has OPP functionality too. As the comment above
says this can be fine grained later, but just wanted to mention here. IMO we can
restrict notrace to just below functions in spc.c
ve_spc_cpu_in_wfi
ve_spc_cpu_wakeup_irq
ve_spc_global_wakeup_irq
ve_spc_powerdown
ve_spc_set_resume_addr
Regards,
Sudeep
^ permalink raw reply
* [PATCH v4 3/4] ARM: OMAP2+: add legacy display for omap3 DBB056
From: Tomi Valkeinen @ 2014-02-14 14:35 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1392387656-15186-4-git-send-email-chf.fritz@googlemail.com>
Hi,
On 14/02/14 16:20, Christoph Fritz wrote:
> Full device tree support for omapdss is not yet accomplished. Until
> then, init display by legacy platform code.
>
> Signed-off-by: Christoph Fritz <chf.fritz@googlemail.com>
> ---
> arch/arm/mach-omap2/dss-common.c | 49 ++++++++++++++++++++++++++++++++++++
> arch/arm/mach-omap2/dss-common.h | 1 +
> arch/arm/mach-omap2/pdata-quirks.c | 8 +++++-
> 3 files changed, 57 insertions(+), 1 deletion(-)
I'm not nack'ing this, but I'm again hoping to get DSS DT support for
3.15. I haven't done any bigger changes to my branch for some time now,
and I'm just waiting to get some comments/acks for the bindings.
So I suggest to also try out DSS DT for your board, based on the latest
DSS DT branch:
git://git.kernel.org/pub/scm/linux/kernel/git/tomba/linux.git work/dss-dt
That way you have it ready and tested if DSS DT goes forward.
Tomi
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 901 bytes
Desc: OpenPGP digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20140214/8cbe0eaa/attachment-0001.sig>
^ permalink raw reply
* [PATCH 23/27] clocksource: sh_cmt: Add DT support
From: Laurent Pinchart @ 2014-02-14 14:35 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAMuHMdUPJ_Wz85AJeYF8vnkOfjd8A7fHb45bL5-B0bAPqNHnhw@mail.gmail.com>
Hi Geert,
Thank you for the review.
On Friday 14 February 2014 10:18:58 Geert Uytterhoeven wrote:
> On Fri, Feb 14, 2014 at 2:00 AM, Laurent Pinchart wrote:
> > +++ b/Documentation/devicetree/bindings/timer/renesas,cmt.txt
> > @@ -0,0 +1,75 @@
> > +* Renesas R-Car Compare Match Timer (CMT)
> > +
> > +The CMT is a multi-channel 16/32/48-bit timer/counter with configurable
> > clock
> 16-bit is mentioned here ...
>
> > +inputs and programmable compare match.
> > +
> > +Channels share hadware resources but their counter and compare match
> > value are
>
> hardware
>
> > +independent. A particular CMT instance can implement only a subset of the
> > +channels supported by the CMT model. Channels indices start from 0 and
> > are
>
> Channel indices
>
> > +consecutive.
> > +
> > +Required Properties:
> > +
> > + - compatible: must contain one of the following.
>
> ... why not add "renesas,cmt-16" here (and one extra line in the actual
> driver), while you're at it?
Because the 16-bit variant is only used on SuperH SoCs, so there's not much
point in adding DT bindings for it.
> > + - "renesas,cmt-32" for the 32-bit CMT
> > + (CMT0 on sh7372, sh73a0 and r8a7740)
> > + - "renesas,cmt-32-fast" for the 32-bit CMT with fast clock support
> > + (CMT[234] on sh7372, sh73a0 and r8a7740)
> > + - "renasas,cmt-48" for the 48-bit CMT
> > + (CMT1 on sh7372, sh73a0 and r8a7740)
> > + - "renesas,cmt-48-gen2" for the second generation 48-bit CMT
> > + (CMT[01] on r8a73a4, r8a7790 and r8a7791)
--
Regards,
Laurent Pinchart
^ permalink raw reply
* [PATCH 26/27] ARM: shmobile: lager-reference: Enable CMT0 in device tree
From: Sergei Shtylyov @ 2014-02-14 14:36 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <2354725.yUCM3gQqXi@avalon>
Hello.
On 14-02-2014 18:22, Laurent Pinchart wrote:
>>>>> Enable the CMT0 device and configure channel 0 as a clock event
>>>>> provider.
>>>>> Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
>>>>> diff --git a/arch/arm/mach-shmobile/include/mach/r8a7790.h
>>>>> b/arch/arm/mach-shmobile/include/mach/r8a7790.h index 0b95bab..62b31f3
>>>>> 100644 --- a/arch/arm/mach-shmobile/include/mach/r8a7790.h
>>>>> +++ b/arch/arm/mach-shmobile/include/mach/r8a7790.h
>>>>> @@ -29,7 +29,6 @@ enum {
>>>>> };
>>>>>
>>>>> void r8a7790_add_standard_devices(void);
>>>>> -void r8a7790_add_dt_devices(void);
>>>>> void r8a7790_clock_init(void);
>>>>> void r8a7790_pinmux_init(void);
>>>>> void r8a7790_pm_init(void);
>>>>> diff --git a/arch/arm/mach-shmobile/setup-r8a7790.c
>>>>> b/arch/arm/mach-shmobile/setup-r8a7790.c index 3e5813f..462c81f 100644
>>>>> --- a/arch/arm/mach-shmobile/setup-r8a7790.c
>>>>> +++ b/arch/arm/mach-shmobile/setup-r8a7790.c
>>>>> @@ -294,11 +294,6 @@ static struct resource cmt0_resources[] = {
>>>>> &cmt##idx##_platform_data, \
>>>>> sizeof(struct sh_timer_config))
>>>>>
>>>>> -void __init r8a7790_add_dt_devices(void)
>>>>> -{
>>>>> - r8a7790_register_cmt(0);
>>>>> -}
>>>>> -
>>>>> void __init r8a7790_add_standard_devices(void)
>>>>> {
>>>>> r8a7790_register_scif(0);
>>>>> @@ -311,7 +306,7 @@ void __init r8a7790_add_standard_devices(void)
>>>>> r8a7790_register_scif(7);
>>>>> r8a7790_register_scif(8);
>>>>> r8a7790_register_scif(9);
>>>>> - r8a7790_add_dt_devices();
>>>>> + r8a7790_register_cmt(0);
>>>>> r8a7790_register_irqc(0);
>>>>> r8a7790_register_thermal();
>>>>> }
>>>>>
>>>> IMHO, these 2 files should be split into a separate patch.
>>>
>>> That could easily be done, but why ?
>>
>> It does not seem necessary to combine these changes in one patch. Remember,
>> Simon has separate branches for boards and SoCs. So finally it's up to him
>> to decide on this...
> Right, but in this case I need to remove the CMT platform device registration
> from r8a7790_add_dt_devices()
You're not removing anything in these 2 files, you're just replacing
"indirect" call to r8a7790_register_cmt(0) with direct.
WBR, Sergei
^ permalink raw reply
* [PATCH 1/2] mfd: twl4030-madc: Add devicetree support.
From: Belisko Marek @ 2014-02-14 14:53 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20140214134815.GD13293@lee--X1>
On Fri, Feb 14, 2014 at 2:48 PM, Lee Jones <lee.jones@linaro.org> wrote:
>> Signed-off-by: Marek Belisko <marek@goldelico.com>
>> ---
>> .../devicetree/bindings/mfd/twl4030-madc.txt | 18 +++++++++++++
>> drivers/mfd/twl4030-madc.c | 31
>> ++++++++++++++++++++--
>
> Please separate these into different patches.
OK.
>
>> 2 files changed, 47 insertions(+), 2 deletions(-)
>> create mode 100644 Documentation/devicetree/bindings/mfd/twl4030-madc.txt
>
> <snip>
>
>> +++ b/drivers/mfd/twl4030-madc.c
>> @@ -695,6 +695,29 @@ static int twl4030_madc_set_power(struct twl4030_madc_data *madc, int on)
>> return 0;
>> }
>>
>> +#ifdef CONFIG_OF
>
> I believe we're heading for a more:
>
> if (IS_ENABLED(CONFIG_OF))
>
> ... approach. I won't enforce it, but please consider using it.
OK I'll use it in next version.
>
>> +static struct twl4030_madc_platform_data *
>> + twl4030_madc_of_parse(struct platform_device *pdev)
>> +{
>> + struct twl4030_madc_platform_data *pdata;
>> +
>> + pdata = devm_kzalloc(&pdev->dev,
>> + sizeof(struct twl4030_madc_platform_data), GFP_KERNEL);
>
> s/struct twl4030_madc_platform_data/*pdata/
Right typo.
>
>> + if (!pdata)
>> + return ERR_PTR(-ENOMEM);
>> +
>> + pdata->irq_line = platform_get_irq(pdev, 0);
>
> Why weren't 'resources' used in the original implementation?
Not sure I'm not an author :). It's passed in platform data.
>
>> + return pdata;
>> +}
>> +
>> +static const struct of_device_id twl4030_madc_dt_match_table[] = {
>> + { .compatible = "ti,twl4030-madc" },
>> + {},
>> +};
>> +
>> +#endif
>> +
>> /*
>> * Initialize MADC and request for threaded irq
>> */
>> @@ -706,8 +729,11 @@ static int twl4030_madc_probe(struct platform_device *pdev)
>> u8 regval;
>>
>> if (!pdata) {
>> - dev_err(&pdev->dev, "platform_data not available\n");
>> - return -EINVAL;
>> + pdata = twl4030_madc_of_parse(pdev);
>> + if (!pdata) {
>
> And if you received -ENOMEM?
Hmm right. I'll fix that.
>
>> + dev_err(&pdev->dev, "platform_data not available\n");
>> + return -EINVAL;
>> + }
>> }
>> madc = kzalloc(sizeof(*madc), GFP_KERNEL);
>> if (!madc)
>> @@ -807,6 +833,7 @@ static struct platform_driver twl4030_madc_driver = {
>> .driver = {
>> .name = "twl4030_madc",
>> .owner = THIS_MODULE,
>> + .of_match_table = of_match_ptr(twl4030_madc_dt_match_table),
>> },
>> };
>>
>
> --
> Lee Jones
> Linaro STMicroelectronics Landing Team Lead
> Linaro.org ? Open source software for ARM SoCs
> Follow Linaro: Facebook | Twitter | Blog
BR,
marek
--
as simple and primitive as possible
-------------------------------------------------
Marek Belisko - OPEN-NANDRA
Freelance Developer
Ruska Nova Ves 219 | Presov, 08005 Slovak Republic
Tel: +421 915 052 184
skype: marekwhite
twitter: #opennandra
web: http://open-nandra.com
^ permalink raw reply
* [PATCH v10 0/4] ata: Add APM X-Gene SoC SATA host controller support
From: Tejun Heo @ 2014-02-14 15:03 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAPw-ZTn5c=v+7pbetEjXWpw9i=cG+zdeHPxO1QD0e42uFrKnCg@mail.gmail.com>
Hello, Loc.
On Thu, Feb 13, 2014 at 03:28:01PM -0800, Loc Ho wrote:
> 1. There are a number of errata that require workaround. Some can be
> fixed by adding broken flags while others are better to just wrap
> around the existent libahci library routines and not overly polluting
> the libahci routines.
> 2. There are additional controller programming sequences to configure.
> 2a. By default, RAM are powered down and require brought out of shutdown.
> 2b. The controller has an additional corresponding PHY part that needs
> to be programmed after PHY configuration.
Have you looked at the latest patchset Hans posted? He added multiple
PHY support and split up init to three steps so that each platform
driver can mix and match as they see fit. Looking at xgene driver,
sure there are things specific to the driver but there also are
non-insignificant amount of boilerplate code and that's what I'm
primarily concerned about. It may be okay when you have two or three
drivers duplicating some code but it looks like we could have many
more and I *really* want to avoid the situation where the same piece
of code is copied over N times. In addition, frankly, not many people
except yourself would care about these drivers once they're merged and
many of these are gonna be painful to test making later refactoring a
lot harder.
> 2c. The controller requires extra programming sequence for the
> hardreset due to errata.
> 2d. For the IO flush, it requires additional memory resources.
Sure, you'll need to override good parts of the driver. What I'm
saying is please try to reuse whatever you can. If that takes
refactoring and librarize ahci_platform, please do so and I do see
healthy chunk of duplicated code in the init path. Please take a look
at Hans' patches and if necessary work with him so that your driver
can be part of the refactoring.
Thanks.
--
tejun
^ permalink raw reply
* [PATCH] MAINTAINERS: add additional ARM BCM281xx/BCM11xxx maintainer
From: Matt Porter @ 2014-02-14 15:03 UTC (permalink / raw)
To: linux-arm-kernel
Add myself as an additional maintainer for the Broadcom mobile
SoCs.
---
MAINTAINERS | 1 +
1 file changed, 1 insertion(+)
diff --git a/MAINTAINERS b/MAINTAINERS
index b2cf5cf..9d6fbfd 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -1860,6 +1860,7 @@ F: drivers/net/ethernet/broadcom/bnx2x/
BROADCOM BCM281XX/BCM11XXX ARM ARCHITECTURE
M: Christian Daudt <bcm@fixthebug.org>
+M: Matt Porter <mporter@linaro.org>
L: bcm-kernel-feedback-list at broadcom.com
T: git git://git.github.com/broadcom/bcm11351
S: Maintained
--
1.8.4
^ permalink raw reply related
* [PATCH v2] MAINTAINERS: add additional ARM BCM281xx/BCM11xxx maintainer
From: Matt Porter @ 2014-02-14 15:15 UTC (permalink / raw)
To: linux-arm-kernel
Add myself as an additional maintainer for the Broadcom mobile
SoCs.
Signed-off-by: Matt Porter <mporter@linaro.org>
---
Since v1: put back my missing SOB
MAINTAINERS | 1 +
1 file changed, 1 insertion(+)
diff --git a/MAINTAINERS b/MAINTAINERS
index b2cf5cf..9d6fbfd 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -1860,6 +1860,7 @@ F: drivers/net/ethernet/broadcom/bnx2x/
BROADCOM BCM281XX/BCM11XXX ARM ARCHITECTURE
M: Christian Daudt <bcm@fixthebug.org>
+M: Matt Porter <mporter@linaro.org>
L: bcm-kernel-feedback-list at broadcom.com
T: git git://git.github.com/broadcom/bcm11351
S: Maintained
--
1.8.4
^ permalink raw reply related
* [PATCH 1/2] mfd: twl4030-madc: Add devicetree support.
From: Lee Jones @ 2014-02-14 15:28 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAAfyv36FH364OPnktx_Qh6sUfwYe7hynqrc3Xs_tY4gPXqQWvA@mail.gmail.com>
> >> Signed-off-by: Marek Belisko <marek@goldelico.com>
> >> ---
> >> .../devicetree/bindings/mfd/twl4030-madc.txt | 18 +++++++++++++
> >> drivers/mfd/twl4030-madc.c | 31
> >> ++++++++++++++++++++--
> >
<snip>
> >> +static struct twl4030_madc_platform_data *
> >> + twl4030_madc_of_parse(struct platform_device *pdev)
> >> +{
> >> + struct twl4030_madc_platform_data *pdata;
> >> +
> >> + pdata = devm_kzalloc(&pdev->dev,
> >> + sizeof(struct twl4030_madc_platform_data), GFP_KERNEL);
> >
> > s/struct twl4030_madc_platform_data/*pdata/
> Right typo.
Sorry, my comment of ambiguous.
I mean do this:
sizeof(*pdata)
... instead of this:
sizeof(struct twl4030_madc_platform_data)
> >> + if (!pdata)
> >> + return ERR_PTR(-ENOMEM);
> >> +
> >> + pdata->irq_line = platform_get_irq(pdev, 0);
> >
> > Why weren't 'resources' used in the original implementation?
> Not sure I'm not an author :). It's passed in platform data.
Yes, I saw that. It should be changed.
--
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org ? Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
^ permalink raw reply
* [PATCH] ARM: shmobile: lager: Add internal USB PCI support
From: Magnus Damm @ 2014-02-14 15:30 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <52FE2026.8040801@cogentembedded.com>
Hi Sergei,
On Fri, Feb 14, 2014 at 10:54 PM, Sergei Shtylyov
<sergei.shtylyov@cogentembedded.com> wrote:
> Hello.
>
>
> On 14-02-2014 7:29, Magnus Damm wrote:
>
>> From: Valentine Barshak <valentine.barshak@cogentembedded.com>
>
>
>> This adds internal PCI USB host devices to R-Car H2 Lager board.
>
>
>> Signed-off-by: Valentine Barshak <valentine.barshak@cogentembedded.com>
>> [damm at opensource.se: Rebased and reworked to only include USB1 and USB2]
>> Signed-off-by: Magnus Damm <damm@opensource.se>
>> ---
>
>
>> Written against renesas-devel-v3.14-rc2-20140213
>
>
>> arch/arm/mach-shmobile/board-lager.c | 50
>> ++++++++++++++++++++++++++++++++++
>> 1 file changed, 50 insertions(+)
>
>
>> --- 0001/arch/arm/mach-shmobile/board-lager.c
>> +++ work/arch/arm/mach-shmobile/board-lager.c 2014-02-14
>> 12:16:26.000000000 +0900
>> @@ -638,6 +638,48 @@ static struct resource sdhi2_resources[]
>> DEFINE_RES_IRQ(gic_spi(167)),
>> };
>>
>> +/* Internal PCI1 */
>> +static const struct resource pci1_resources[] __initconst = {
>> + DEFINE_RES_MEM(0xee0b0000, 0x10000), /* CFG */
>> + DEFINE_RES_MEM(0xee0a0000, 0x10000), /* MEM */
>> + DEFINE_RES_IRQ(gic_spi(112)),
>> +};
>> +
>> +static const struct platform_device_info pci1_info __initconst = {
>> + .parent = &platform_bus,
>> + .name = "pci-rcar-gen2",
>> + .id = 1,
>> + .res = pci1_resources,
>> + .num_res = ARRAY_SIZE(pci1_resources),
>> + .dma_mask = DMA_BIT_MASK(32),
>> +};
>> +
>> +static void __init lager_add_usb1_device(void)
>
>
> Actually, this adds PCI device, not USB, so the name is strange.
> Also, I doubt that such functions are really necessary.
Well there are only USB devices hanging off the PCI devices on the
actual silicon, so this naming discussion seems like splitting hairs?
>> +{
>> + platform_device_register_full(&pci1_info);
>> +}
>> +
>> +/* Internal PCI2 */
>> +static const struct resource pci2_resources[] __initconst = {
>> + DEFINE_RES_MEM(0xee0d0000, 0x10000), /* CFG */
>> + DEFINE_RES_MEM(0xee0c0000, 0x10000), /* MEM */
>> + DEFINE_RES_IRQ(gic_spi(113)),
>> +};
>> +
>> +static const struct platform_device_info pci2_info __initconst = {
>> + .parent = &platform_bus,
>> + .name = "pci-rcar-gen2",
>> + .id = 2,
>> + .res = pci2_resources,
>> + .num_res = ARRAY_SIZE(pci2_resources),
>> + .dma_mask = DMA_BIT_MASK(32),
>> +};
>> +
>
>
> I suspect the PCI resources and info could be wrapped by macros and then
> instantiated by using only 2 lines.
I suspect anything can be done. =) As you may know, I'm not the
original author of this patch. At this point in time I'm mainly
focusing on getting device support merged, so please feel free to send
either incremental patches or pick up this one and fix it yourself.
I'm beyond caring.
Thanks,
/ magnus
^ permalink raw reply
* [PATCH 23/27] clocksource: sh_cmt: Add DT support
From: Laurent Pinchart @ 2014-02-14 15:53 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20140214105822.GE9907@e106331-lin.cambridge.arm.com>
Hi Mark,
Thank you for the review.
On Friday 14 February 2014 10:58:22 Mark Rutland wrote:
> On Fri, Feb 14, 2014 at 01:00:01AM +0000, Laurent Pinchart wrote:
> > Cc: devicetree at vger.kernel.org
> > Signed-off-by: Laurent Pinchart
> > <laurent.pinchart+renesas@ideasonboard.com>
> > ---
> >
> > .../devicetree/bindings/timer/renesas,cmt.txt | 75 +++++++++++++++
> > drivers/clocksource/sh_cmt.c | 104 +++++++++++++---
> > 2 files changed, 160 insertions(+), 19 deletions(-)
> > create mode 100644
> > Documentation/devicetree/bindings/timer/renesas,cmt.txt
> >
> > diff --git a/Documentation/devicetree/bindings/timer/renesas,cmt.txt
> > b/Documentation/devicetree/bindings/timer/renesas,cmt.txt new file mode
> > 100644
> > index 0000000..28d4ab5
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/timer/renesas,cmt.txt
> > @@ -0,0 +1,75 @@
> > +* Renesas R-Car Compare Match Timer (CMT)
> > +
> > +The CMT is a multi-channel 16/32/48-bit timer/counter with configurable
> > clock
> > +inputs and programmable compare match.
> > +
> > +Channels share hadware resources but their counter and compare match
> > value are
> > +independent. A particular CMT instance can implement only a subset of the
> > +channels supported by the CMT model. Channels indices start from 0 and
> > are
> > +consecutive.
> > +
> > +Required Properties:
> > +
> > + - compatible: must contain one of the following.
> > + - "renesas,cmt-32" for the 32-bit CMT
> > + (CMT0 on sh7372, sh73a0 and r8a7740)
> > + - "renesas,cmt-32-fast" for the 32-bit CMT with fast clock support
> > + (CMT[234] on sh7372, sh73a0 and r8a7740)
> > + - "renasas,cmt-48" for the 48-bit CMT
> > + (CMT1 on sh7372, sh73a0 and r8a7740)
> > + - "renesas,cmt-48-gen2" for the second generation 48-bit CMT
> > + (CMT[01] on r8a73a4, r8a7790 and r8a7791)
> > +
> > + - reg: base address and length of the registers block for the timer
> > module.
> > + - interrupt-parent, interrupts: interrupt-specifier for the timer, one
> > per
> > + channel.
>
> It might make more sense to describe the interrupt on the channel
> subnode. It makes it far clearer which channel has which interrupt.
That's a good point. I'm relying on platform_get_irq() which won't support
that usage, but I can switch to of_irq_to_resource() instead.
> > + - clocks: phandle and clock-specifier pair for the functional clock.
> > + - clock-names: must be "fck".
>
> It would be nice to define the list once:
>
> - clocks: A list of phandle + clock-specifier pairs, one for each entry
> in clock-names.
> - clock-names: Should contain "fck" for the functional clock.
OK.
> > +
> > + - #address-cells: must be 1
> > + - #size-cells: must be 0
> > +
> > + - renesas,channels-mask: integer bitmask of the channels implemented by
> > the
> > + timer instance.
>
> This is implied by the presence of a subnode. Either remove this or the
> subnodes.
>
> > +
> > +
> > +Each channel is described by a sub-node named "channel@<idx>", where
> > <idx> is +the channel index.
> > +
> > +Channels Required Properties:
> > +
> > + - reg: the channel index.
> > +
> > +Channels Optional Properties:
> > +
> > + - clock-source-rating: rating of the timer as a clock source device.
> > + - clock-event-rating: rating of the timer as a clock event device.
>
> This feels like a leak of Linux internals. Why do you need this?
You're right, it is. The clock source and clock event ratings are currently
configured through platform data, I'll need to find a way to compute them in
the driver instead.
There's still one piece of Linux-specific data I need though, as I need to
specify for each channel whether to use it as a clock source device, a clock
event device, both of them or none. That's configuration information that
needs to be provided somehow.
> > +
> > +
> > +Example: R8A7790 (R-Car H2) CMT0 node
> > +
> > + CMT0 on R8A7790 implements hardware channels 5 and 6 only and names
> > + them channels 0 and 1 in the documentation.
> > +
> > + cmt0: timer at ffca0000 {
> > + compatible = "renesas,cmt-48-gen2";
> > + reg = <0 0xffca0000 0 0x1004>;
> > + interrupt-parent = <&gic>;
> > + interrupts = <0 142 IRQ_TYPE_LEVEL_HIGH>,
> > + <0 142 IRQ_TYPE_LEVEL_HIGH>;
> > + clocks = <&mstp1_clks R8A7790_CLK_CMT0>;
> > +
> > + #address-cells = <1>;
> > + #size-cells = <0>;
> > +
> > + renesas,channels-mask = <0x60>;
> > +
> > + channel at 0 {
> > + reg = <0>;
> > + clock-event-rating = <80>;
> > + };
> > + channel at 0 {
> > + reg = <0>;
> > + clock-source-rating = <80>;
> > + };
>
> Aaargh. Use the _real_ channel IDs for the reg proeprties and get rid of
> the mask. It's pointlessly confusing.
There's two real channel IDs. One of them is the value used in the hardware
implementation (5 and 6 in this case, used to compute the channel registers
block address) and the other one is the value used throughout the datasheet, 0
and 1 in this case.
The later is used by the driver to reference the correct interrupt, which
won't be needed anymore when referencing interrupts in the channel subnodes
directly. It's also used to print messages to the kernel log and match the
channel numbers specified in the datasheets. I could use the hardware channel
number instead, but that might become confusing.
--
Regards,
Laurent Pinchart
^ permalink raw reply
* [PATCH 23/27] clocksource: sh_cmt: Add DT support
From: Josh Cartwright @ 2014-02-14 15:59 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <107109887.afEv2P92gg@avalon>
On Fri, Feb 14, 2014 at 04:53:08PM +0100, Laurent Pinchart wrote:
> On Friday 14 February 2014 10:58:22 Mark Rutland wrote:
> > On Fri, Feb 14, 2014 at 01:00:01AM +0000, Laurent Pinchart wrote:
> > > +Channels Optional Properties:
> > > +
> > > + - clock-source-rating: rating of the timer as a clock source device.
> > > + - clock-event-rating: rating of the timer as a clock event device.
> >
> > This feels like a leak of Linux internals. Why do you need this?
>
> You're right, it is. The clock source and clock event ratings are currently
> configured through platform data, I'll need to find a way to compute them in
> the driver instead.
>
> There's still one piece of Linux-specific data I need though, as I need to
> specify for each channel whether to use it as a clock source device, a clock
> event device, both of them or none. That's configuration information that
> needs to be provided somehow.
Are all the channels equally capable? We had this problem for the
cadence_ttc timer used on Zynq, and decided to just statically allocate
the first timer to be the clocksource, and the second to be the
clockevent.
Also, should the rating really be user configurable?
--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
hosted by The Linux Foundation
^ permalink raw reply
* [PATCH 23/27] clocksource: sh_cmt: Add DT support
From: Magnus Damm @ 2014-02-14 16:01 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <107109887.afEv2P92gg@avalon>
On Sat, Feb 15, 2014 at 12:53 AM, Laurent Pinchart
<laurent.pinchart@ideasonboard.com> wrote:
> On Friday 14 February 2014 10:58:22 Mark Rutland wrote:
>> On Fri, Feb 14, 2014 at 01:00:01AM +0000, Laurent Pinchart wrote:
>> > +Channels Optional Properties:
>> > +
>> > + - clock-source-rating: rating of the timer as a clock source device.
>> > + - clock-event-rating: rating of the timer as a clock event device.
>>
>> This feels like a leak of Linux internals. Why do you need this?
>
> You're right, it is. The clock source and clock event ratings are currently
> configured through platform data, I'll need to find a way to compute them in
> the driver instead.
That would be very good!
> There's still one piece of Linux-specific data I need though, as I need to
> specify for each channel whether to use it as a clock source device, a clock
> event device, both of them or none. That's configuration information that
> needs to be provided somehow.
I think you can decide clock source or clock event assignment based on
number of channels available. If you have only a single channel then
both clock event and clock source need to be supported. Otherwise use
one channel for clock source and the rest for clock events.
This is probably out of scope for this DT conversion, but it would be
neat if you somehow could specify the CPU affinity for a channel to
tie a clock event to an individual CPU core. This would make a a
per-cpu timer unless I'm mistaken. But that's more of a software
policy than anything else.
Thanks,
/ magnus
^ permalink raw reply
* [PATCH v4 01/13] ARM: PJ4B: Add cpu_suspend/cpu_resume hooks for PJ4B
From: Lorenzo Pieralisi @ 2014-02-14 16:06 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1392312816-17657-2-git-send-email-gregory.clement@free-electrons.com>
Hi Gregory,
On Thu, Feb 13, 2014 at 05:33:24PM +0000, Gregory CLEMENT wrote:
> PJ4B needs extra instructions for suspend and resume, so instead of
> using the armv7 version, this commit introduces specific versions for
> PJ4B.
>
> Cc: Russell King <linux@arm.linux.org.uk>
> Signed-off-by: Gregory CLEMENT <gregory.clement@free-electrons.com>
> ---
> arch/arm/mm/proc-v7.S | 64 ++++++++++++++++++++++++++++++++++++++++++++++++---
> 1 file changed, 61 insertions(+), 3 deletions(-)
>
> diff --git a/arch/arm/mm/proc-v7.S b/arch/arm/mm/proc-v7.S
> index bd1781979a39..11117423a9b4 100644
> --- a/arch/arm/mm/proc-v7.S
> +++ b/arch/arm/mm/proc-v7.S
> @@ -169,9 +169,67 @@ ENDPROC(cpu_pj4b_do_idle)
> globl_equ cpu_pj4b_do_idle, cpu_v7_do_idle
> #endif
> globl_equ cpu_pj4b_dcache_clean_area, cpu_v7_dcache_clean_area
> - globl_equ cpu_pj4b_do_suspend, cpu_v7_do_suspend
> - globl_equ cpu_pj4b_do_resume, cpu_v7_do_resume
> - globl_equ cpu_pj4b_suspend_size, cpu_v7_suspend_size
> +#ifdef CONFIG_ARM_CPU_SUSPEND
> +ENTRY(cpu_pj4b_do_suspend)
> + stmfd sp!, {r4 - r10, lr}
> + mrc p15, 0, r4, c13, c0, 0 @ FCSE/PID
> + mrc p15, 0, r5, c13, c0, 3 @ User r/o thread ID
> + stmia r0!, {r4 - r5}
> + mrc p15, 1, r6, c15, c1, 0 @ save CP15 - extra features
> + mrc p15, 1, r7, c15, c2, 0 @ save CP15 - Aux Func Modes Ctrl 0
> + mrc p15, 1, r8, c15, c1, 2 @ save CP15 - Aux Debug Modes Ctrl 2
> + mrc p15, 1, r9, c15, c1, 1 @ save CP15 - Aux Debug Modes Ctrl 1
> + mrc p15, 0, r10, c9, c14, 0 @ save CP15 - PMC
> + stmia r0!, {r6 - r10}
> + mrc p15, 0, r6, c3, c0, 0 @ Domain ID
> + mrc p15, 0, r7, c2, c0, 1 @ TTB 1
> + mrc p15, 0, r11, c2, c0, 2 @ TTB control register
> + mrc p15, 0, r8, c1, c0, 0 @ Control register
> + mrc p15, 0, r9, c1, c0, 1 @ Auxiliary control register
> + mrc p15, 0, r10, c1, c0, 2 @ Co-processor access control
> + stmia r0, {r6 - r11}
> + ldmfd sp!, {r4 - r10, pc}
> +ENDPROC(cpu_pj4b_do_suspend)
> +
> +ENTRY(cpu_pj4b_do_resume)
> + mov ip, #0
> + mcr p15, 0, ip, c7, c5, 0 @ invalidate I cache
> + mcr p15, 0, ip, c13, c0, 1 @ set reserved context ID
> + ldmia r0!, {r4 - r5}
> + mcr p15, 0, r4, c13, c0, 0 @ FCSE/PID
> + mcr p15, 0, r5, c13, c0, 3 @ User r/o thread ID
> + ldmia r0!, {r6 - r10}
> + mcr p15, 1, r6, c15, c1, 0 @ save CP15 - extra features
> + mcr p15, 1, r7, c15, c2, 0 @ save CP15 - Aux Func Modes Ctrl 0
> + mcr p15, 1, r8, c15, c1, 2 @ save CP15 - Aux Debug Modes Ctrl 2
> + mcr p15, 1, r9, c15, c1, 1 @ save CP15 - Aux Debug Modes Ctrl 1
> + mcr p15, 0, r10, c9, c14, 0 @ save CP15 - PMC
> + ldmia r0, {r6 - r11}
> + mcr p15, 0, ip, c8, c7, 0 @ invalidate TLBs
> + mcr p15, 0, r6, c3, c0, 0 @ Domain ID
> +#ifndef CONFIG_ARM_LPAE
> + ALT_SMP(orr r1, r1, #TTB_FLAGS_SMP)
> + ALT_UP(orr r1, r1, #TTB_FLAGS_UP)
> +#endif
> + mcr p15, 0, r1, c2, c0, 0 @ TTB 0
> + mcr p15, 0, r7, c2, c0, 1 @ TTB 1
> + mcr p15, 0, r11, c2, c0, 2 @ TTB control register
> + ldr r4, =PRRR @ PRRR
> + ldr r5, =NMRR @ NMRR
> + mcr p15, 0, r4, c10, c2, 0 @ write PRRR
> + mcr p15, 0, r5, c10, c2, 1 @ write NMRR
> + mrc p15, 0, r4, c1, c0, 1 @ Read Auxiliary control register
> + teq r4, r9 @ Is it already set?
> + mcrne p15, 0, r9, c1, c0, 1 @ No, so write it
> + mcr p15, 0, r10, c1, c0, 2 @ Co-processor access control
> + isb
> + dsb
> + mov r0, r8 @ control register
> + b cpu_resume_mmu
> +ENDPROC(cpu_pj4b_do_resume)
> +#endif
> +.globl cpu_pj4b_suspend_size
> +.equ cpu_pj4b_suspend_size, 4 * 13
>
> #endif
A couple of questions:
1) Do the extra registers ever change after coldboot ?
2) Do you need to restore them before turning the MMU and caches on ?
3) Most of the code is copy'n'paste from v7, is not it possible to reuse
that code by doing processor specific save/restore and then jump to
the v7 functions ?
Thanks,
Lorenzo
^ permalink raw reply
* [PATCH 23/27] clocksource: sh_cmt: Add DT support
From: Laurent Pinchart @ 2014-02-14 16:12 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CANqRtoS-d-CW3XX3_E2dgJ83btRZYWiMCYmWUJAPqh9EeBhLEQ@mail.gmail.com>
Hi Magnus,
On Saturday 15 February 2014 01:01:30 Magnus Damm wrote:
> On Sat, Feb 15, 2014 at 12:53 AM, Laurent Pinchart wrote:
> > On Friday 14 February 2014 10:58:22 Mark Rutland wrote:
> >> On Fri, Feb 14, 2014 at 01:00:01AM +0000, Laurent Pinchart wrote:
> >> > +Channels Optional Properties:
> >> > +
> >> > + - clock-source-rating: rating of the timer as a clock source device.
> >> > + - clock-event-rating: rating of the timer as a clock event device.
> >>
> >> This feels like a leak of Linux internals. Why do you need this?
> >
> > You're right, it is. The clock source and clock event ratings are
> > currently configured through platform data, I'll need to find a way to
> > compute them in the driver instead.
>
> That would be very good!
Any pointer would be appreciated :-) How did you compute the various ratings
used in platform data all over the place ?
> > There's still one piece of Linux-specific data I need though, as I need to
> > specify for each channel whether to use it as a clock source device, a
> > clock event device, both of them or none. That's configuration
> > information that needs to be provided somehow.
>
> I think you can decide clock source or clock event assignment based on
> number of channels available. If you have only a single channel then both
> clock event and clock source need to be supported. Otherwise use one channel
> for clock source and the rest for clock events.
That won't match the current situation. Look at CMT0 in r8a7790 for instance.
There's two hardware channels available, and we only use the first one, for
clock events only.
> This is probably out of scope for this DT conversion, but it would be neat
> if you somehow could specify the CPU affinity for a channel to tie a clock
> event to an individual CPU core. This would make a a per-cpu timer unless
> I'm mistaken. But that's more of a software policy than anything else.
Yes, that's a configuration that needs to be specified somewhere. I don't know
where though.
--
Regards,
Laurent Pinchart
^ permalink raw reply
* [BISECTED] ssh - Received disconnect from x.x.x.x: 2: Bad packet length 3149594624
From: Ivaylo Dimitrov @ 2014-02-14 16:12 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20140213192909.GO13576@mudshark.cambridge.arm.com>
On 13.02.2014 21:29, Will Deacon wrote:
>
> Can you try hacking crypto/memneq.c so that it doesn't use
> CONFIG_HAVE_EFFICIENT_UNALIGNED_ACCESS please? That would at least point the
> finger at net/mac80211/rx.c or similar.
>
> Cheers,
>
> Will
>
Well, I am lazy so I hacked net/mac80211/rx.c first:
index c24ca0d..6839c77 100644
--- a/net/mac80211/rx.c
+++ b/net/mac80211/rx.c
@@ -1963,7 +1963,7 @@ ieee80211_deliver_skb(struct ieee80211_rx_data *rx)
}
}
-#ifndef CONFIG_HAVE_EFFICIENT_UNALIGNED_ACCESS
+//#ifndef CONFIG_HAVE_EFFICIENT_UNALIGNED_ACCESS
if (skb) {
/* 'align' will only take the values 0 or 2 here since all
* frames are required to be aligned to 2-byte boundaries
@@ -1987,7 +1987,7 @@ ieee80211_deliver_skb(struct ieee80211_rx_data *rx)
}
}
}
-#endif
+//#endif
if (skb) {
/* deliver to local stack */
and that seems to fix the problem.
I am not sure whom I should forward the problem.
Thanks,
Ivo
^ permalink raw reply related
* [PATCH 23/27] clocksource: sh_cmt: Add DT support
From: Laurent Pinchart @ 2014-02-14 16:15 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20140214155951.GA22449@joshc.qualcomm.com>
Hi Josh,
On Friday 14 February 2014 09:59:51 Josh Cartwright wrote:
> On Fri, Feb 14, 2014 at 04:53:08PM +0100, Laurent Pinchart wrote:
> > On Friday 14 February 2014 10:58:22 Mark Rutland wrote:
> > > On Fri, Feb 14, 2014 at 01:00:01AM +0000, Laurent Pinchart wrote:
> > > > +Channels Optional Properties:
> > > > +
> > > > + - clock-source-rating: rating of the timer as a clock source
> > > > device.
> > > > + - clock-event-rating: rating of the timer as a clock event device.
> > >
> > > This feels like a leak of Linux internals. Why do you need this?
> >
> > You're right, it is. The clock source and clock event ratings are
> > currently configured through platform data, I'll need to find a way to
> > compute them in the driver instead.
> >
> > There's still one piece of Linux-specific data I need though, as I need to
> > specify for each channel whether to use it as a clock source device, a
> > clock event device, both of them or none. That's configuration
> > information that needs to be provided somehow.
>
> Are all the channels equally capable? We had this problem for the
> cadence_ttc timer used on Zynq, and decided to just statically allocate
> the first timer to be the clocksource, and the second to be the
> clockevent.
No, they're not. The channels can be implemented with different counter
widths, different available prescalers and source clocks and different power
management features (not all of them are capable to run in all sleep states).
> Also, should the rating really be user configurable?
Probably not. I suppose the rating should be computed by the driver based on
the source clock frequency, prescaler and counter width. Any help there would
be very appreciated, I'm pretty new to clock source and clock event devices.
--
Regards,
Laurent Pinchart
^ permalink raw reply
* [PATCH] arm: dtsi: am335x-bone-common, usb0 is peripheral only
From: Tony Lindgren @ 2014-02-14 16:20 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20140214100248.GO31787@pengutronix.de>
* Markus Pargmann <mpa@pengutronix.de> [140214 02:05]:
> Hi,
>
> On Thu, Feb 13, 2014 at 03:25:52PM -0800, Tony Lindgren wrote:
> > * Markus Pargmann <mpa@pengutronix.de> [140213 15:16]:
> > > Hi,
> > >
> > > On Thu, Feb 13, 2014 at 02:54:38PM -0800, Tony Lindgren wrote:
> > > > * Markus Pargmann <mpa@pengutronix.de> [140111 06:03]:
> > > > > The PMIC is using usb0 vbus line as power source. It is also connected
> > > > > to the am335x processor as vbus sense. But there is no possibility to
> > > > > pullup usb0 vbus to operate as host. This patch fixes the dr_mode of usb0.
> > > >
> > > > That's the MUSB? AFAIK it's not possible to operate MUSB in peripheral
> > > > only mode because the hardware does what it wants based on the ID
> > > > pin state.
> > >
> > > Yes that's MUSB. The am335x reference manual describes that it is
> > > possible to force peripheral/host mode by setting bit 7 (IDDIG_MUX) in
> > > register USBnMODE to 1. Then it uses the bit written in bit 8 (IDDIG) of
> > > register USBnMODE to set host/peripheral mode.
> >
> > OK
> >
> > > I am not sure if the driver supports it yet but I think the DTS should
> > > contain the correct mode nevertheless, especially to avoid starting the
> > > otg loops in the musb driver.
> >
> > Well there's one more thing to consider.. I think in the OTG role change
> > case the VBUS is still driven externally from the original host, so the
> > lack of VBUS does not always mean that host mode should be disabled.
>
> I thought more about the hardware description than the possible role
> changes through software protocols. In a hardware perspective, this USB
> port is only in peripheral mode, as it can't drive VBUS. However is
> there any support for role change protocols in the kernel yet?
There's some to trigger it, if you grep -ri hnp drivers/usb/
you'll see some references to it.
> Perhaps we have to add a seperate DT binding for usb role changes when
> they are supported. This would help to describe the hardware
> capabilities (host, peripheral or OTG) and the role change protocols
> supported.
Yeah it might be worth discussing on the USB list what's the best way
to deal with all that.
Regards,
Tony
^ permalink raw reply
* [PATCH 2/2] ARM: mm: keep rodata non-executable
From: Dave Martin @ 2014-02-14 16:22 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1392339850-18686-3-git-send-email-keescook@chromium.org>
On Thu, Feb 13, 2014 at 05:04:10PM -0800, Kees Cook wrote:
> Introduce "CONFIG_DEBUG_RODATA" to mostly match the x86 config, though
> the behavior is different: it depends on STRICT_KERNMEM_PERMS, which
> sets rodata read-only (but executable), where as this option additionally
> splits rodata from the kernel text (resulting in potentially more memory
> lost to padding) and sets it non-executable as well. The end result is
> that on builds with CONFIG_DEBUG_RODATA=y (like x86) the rodata with be
> marked purely read-only.
This triggers an Oops in kexec, because we have a block of code in .text
which is a template for generating baremetal code to relocate the new
kernel, and some literal words are written into it before copying.
Possibly this should be in .rodata, not .text.
There may be a few other instances of this kind of thing.
Are you aware of similar situations on other arches?
Cheers
---Dave
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox