[PATCH 01/12] ARM: OMAP2+: Add hwmod flag for HWMOD_RECONFIG_IO_CHAIN

[PATCH 01/12] ARM: OMAP2+: Add hwmod flag for HWMOD_RECONFIG_IO_CHAIN

[Tony Lindgren]

Commit cc824534d4fe ("ARM: OMAP2+: hwmod: Rearm wake-up interrupts
for DT when MUSB is idled") fixed issues with hung UART wake-up
events by calling _reconfigure_io_chain() when MUSB is connected
or disconnected.

As pointed out by Paul Walmsley, we may need to also call
_reconfigure_io_chain() in other cases, so it should be a separate
flag. Let's add HWMOD_RECONFIG_IO_CHAIN as suggested by Paul.

Cc: Paul Walmsley <paul@pwsan.com>
Signed-off-by: Tony Lindgren <tony@atomide.com>
---
 arch/arm/mach-omap2/omap_hwmod.c           | 4 ++--
 arch/arm/mach-omap2/omap_hwmod.h           | 4 ++++
 arch/arm/mach-omap2/omap_hwmod_3xxx_data.c | 4 ++--
 3 files changed, 8 insertions(+), 4 deletions(-)

diff --git a/arch/arm/mach-omap2/omap_hwmod.c b/arch/arm/mach-omap2/omap_hwmod.c
index 9e91a4e..bd9990e 100644
--- a/arch/arm/mach-omap2/omap_hwmod.c
+++ b/arch/arm/mach-omap2/omap_hwmod.c
@@ -2185,7 +2185,7 @@ static int _enable(struct omap_hwmod *oh)
 			 oh->mux->pads_dynamic))) {
 		omap_hwmod_mux(oh->mux, _HWMOD_STATE_ENABLED);
 		_reconfigure_io_chain();
-	} else if (oh->flags & HWMOD_FORCE_MSTANDBY) {
+	} else if (oh->flags & HWMOD_RECONFIG_IO_CHAIN) {
 		_reconfigure_io_chain();
 	}
 
@@ -2293,7 +2293,7 @@ static int _idle(struct omap_hwmod *oh)
 	if (oh->mux && oh->mux->pads_dynamic) {
 		omap_hwmod_mux(oh->mux, _HWMOD_STATE_IDLE);
 		_reconfigure_io_chain();
-	} else if (oh->flags & HWMOD_FORCE_MSTANDBY) {
+	} else if (oh->flags & HWMOD_RECONFIG_IO_CHAIN) {
 		_reconfigure_io_chain();
 	}
 
diff --git a/arch/arm/mach-omap2/omap_hwmod.h b/arch/arm/mach-omap2/omap_hwmod.h
index 0f97d63..512f809 100644
--- a/arch/arm/mach-omap2/omap_hwmod.h
+++ b/arch/arm/mach-omap2/omap_hwmod.h
@@ -514,6 +514,9 @@ struct omap_hwmod_omap4_prcm {
  * HWMOD_SWSUP_SIDLE_ACT: omap_hwmod code should manually bring the module
  *     out of idle, but rely on smart-idle to the put it back in idle,
  *     so the wakeups are still functional (Only known case for now is UART)
+ * HWMOD_RECONFIG_IO_CHAIN: omap_hwmod code needs to reconfigure wake-up 
+ *     events by calling _reconfigure_io_chain() when a device is enabled
+ *     or idled.
  */
 #define HWMOD_SWSUP_SIDLE			(1 << 0)
 #define HWMOD_SWSUP_MSTANDBY			(1 << 1)
@@ -528,6 +531,7 @@ struct omap_hwmod_omap4_prcm {
 #define HWMOD_BLOCK_WFI				(1 << 10)
 #define HWMOD_FORCE_MSTANDBY			(1 << 11)
 #define HWMOD_SWSUP_SIDLE_ACT			(1 << 12)
+#define HWMOD_RECONFIG_IO_CHAIN			(1 << 13)
 
 /*
  * omap_hwmod._int_flags definitions
diff --git a/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c b/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
index e9516b4..61cd49d 100644
--- a/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
@@ -1730,8 +1730,8 @@ static struct omap_hwmod omap3xxx_usbhsotg_hwmod = {
 	 * Note that musb has OTG_FORCESTDBY register that controls MSTANDBY
 	 * signal when MIDLEMODE is set to force-idle.
 	 */
-	.flags		= HWMOD_NO_OCP_AUTOIDLE | HWMOD_SWSUP_SIDLE
-				| HWMOD_FORCE_MSTANDBY,
+	.flags		= HWMOD_NO_OCP_AUTOIDLE | HWMOD_SWSUP_SIDLE |
+			  HWMOD_FORCE_MSTANDBY | HWMOD_RECONFIG_IO_CHAIN,
 };
 
 /* usb_otg_hs */
-- 
2.1.0

[PATCH 02/12] ARM: OMAP3: Use force-idle for UARTs because of DMA errata

[Tony Lindgren]

In sprz318f.pdf "Usage Note 2.7" says that UARTs cannot acknowledge
idle requests in smartidle mode when configured for DMA operations.
This prevents L4 from going idle. So let's use force-idle mode
instead and also force reconfiguring of the IO chain wake-up events.

Otherwise systems using Sebastian's 8250 patches with DMA will
never enter deeper idle states because of the errata above.

Cc: Paul Walmsley <paul@pwsan.com>
Cc: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
Signed-off-by: Tony Lindgren <tony@atomide.com>
---
 arch/arm/mach-omap2/omap_hwmod_3xxx_data.c | 15 +++++++++++----
 1 file changed, 11 insertions(+), 4 deletions(-)

diff --git a/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c b/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
index 61cd49d..55f088c 100644
--- a/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
@@ -490,7 +490,9 @@ static struct omap_hwmod omap3xxx_uart1_hwmod = {
 	.mpu_irqs	= omap2_uart1_mpu_irqs,
 	.sdma_reqs	= omap2_uart1_sdma_reqs,
 	.main_clk	= "uart1_fck",
-	.flags		= DEBUG_TI81XXUART1_FLAGS | HWMOD_SWSUP_SIDLE_ACT,
+	.flags		= DEBUG_TI81XXUART1_FLAGS |
+				HWMOD_NO_OCP_AUTOIDLE | HWMOD_SWSUP_SIDLE |
+				HWMOD_FORCE_MSTANDBY | HWMOD_RECONFIG_IO_CHAIN,
 	.prcm		= {
 		.omap2 = {
 			.module_offs = CORE_MOD,
@@ -509,7 +511,9 @@ static struct omap_hwmod omap3xxx_uart2_hwmod = {
 	.mpu_irqs	= omap2_uart2_mpu_irqs,
 	.sdma_reqs	= omap2_uart2_sdma_reqs,
 	.main_clk	= "uart2_fck",
-	.flags		= DEBUG_TI81XXUART2_FLAGS | HWMOD_SWSUP_SIDLE_ACT,
+	.flags		= DEBUG_TI81XXUART2_FLAGS |
+				HWMOD_NO_OCP_AUTOIDLE | HWMOD_SWSUP_SIDLE |
+				HWMOD_FORCE_MSTANDBY | HWMOD_RECONFIG_IO_CHAIN,
 	.prcm		= {
 		.omap2 = {
 			.module_offs = CORE_MOD,
@@ -529,7 +533,8 @@ static struct omap_hwmod omap3xxx_uart3_hwmod = {
 	.sdma_reqs	= omap2_uart3_sdma_reqs,
 	.main_clk	= "uart3_fck",
 	.flags		= DEBUG_OMAP3UART3_FLAGS | DEBUG_TI81XXUART3_FLAGS |
-				HWMOD_SWSUP_SIDLE_ACT,
+				HWMOD_NO_OCP_AUTOIDLE | HWMOD_SWSUP_SIDLE |
+				HWMOD_FORCE_MSTANDBY | HWMOD_RECONFIG_IO_CHAIN,
 	.prcm		= {
 		.omap2 = {
 			.module_offs = OMAP3430_PER_MOD,
@@ -559,7 +564,9 @@ static struct omap_hwmod omap36xx_uart4_hwmod = {
 	.mpu_irqs	= uart4_mpu_irqs,
 	.sdma_reqs	= uart4_sdma_reqs,
 	.main_clk	= "uart4_fck",
-	.flags		= DEBUG_OMAP3UART4_FLAGS | HWMOD_SWSUP_SIDLE_ACT,
+	.flags		= DEBUG_OMAP3UART4_FLAGS |
+				HWMOD_NO_OCP_AUTOIDLE | HWMOD_SWSUP_SIDLE |
+				HWMOD_FORCE_MSTANDBY | HWMOD_RECONFIG_IO_CHAIN,
 	.prcm		= {
 		.omap2 = {
 			.module_offs = OMAP3430_PER_MOD,
-- 
2.1.0

[PATCH 03/12] ARM: dts: omap3-overo: Fix UART wake-up events

[Tony Lindgren]

Compared to legacy booting, we don't have wake-up events enabled
for device tree based booting. This means that if deeper idle
states are enabled, the device won't wake up to UART events and
seems like it has hung.

Let's fix that by adding the wake-up interrupt. Note that we
don't need to set the PIN_OFF_WAKEUPENABLE any longer, that's
handled by the wake-up interrupt when the serial driver does
request_irq on it.

Tested with the following on omap3-overo-summit that has the
ES2.1 omap:

#!/bin/bash

uarts=$(find /sys/class/tty/ttyO*/device/power/ -type d)
for uart in $uarts; do
        echo 3000 > $uart/autosuspend_delay_ms
done

uarts=$(find /sys/class/tty/ttyO*/power/ -type d)
for uart in $uarts; do
        echo enabled > $uart/wakeup
        echo auto > $uart/control
done

echo 1 > /sys/kernel/debug/pm_debug/enable_off_mode

# grep -i uart /proc/interrupts
 90:       1085      INTC  74  OMAP UART2
338:          5   pinctrl 366  OMAP UART2

# grep ^core_pwrdm /sys/kernel/debug/pm_debug/count
core_pwrdm (ON),OFF:1654,RET:131,INA:39,ON:1825...

Signed-off-by: Tony Lindgren <tony@atomide.com>
---
 arch/arm/boot/dts/omap3-overo-common-peripherals.dtsi | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/arch/arm/boot/dts/omap3-overo-common-peripherals.dtsi b/arch/arm/boot/dts/omap3-overo-common-peripherals.dtsi
index 5831bcc..520453d 100644
--- a/arch/arm/boot/dts/omap3-overo-common-peripherals.dtsi
+++ b/arch/arm/boot/dts/omap3-overo-common-peripherals.dtsi
@@ -36,8 +36,8 @@
 
 	uart3_pins: pinmux_uart3_pins {
 		pinctrl-single,pins = <
-			OMAP3_CORE1_IOPAD(0x219e, PIN_INPUT | PIN_OFF_WAKEUPENABLE | MUX_MODE0)	/* uart3_rx_irrx.uart3_rx_irrx */
-			OMAP3_CORE1_IOPAD(0x21a0, PIN_OUTPUT | MUX_MODE0)		/* uart3_tx_irtx.uart3_tx_irtx */
+			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 */
 		>;
 	};
 };
@@ -88,6 +88,7 @@
 };
 
 &uart3 {
+	interrupts-extended = <&intc 74 &omap3_pmx_core OMAP3_UART3_RX>;
 	pinctrl-names = "default";
 	pinctrl-0 = <&uart3_pins>;
 };
-- 
2.1.0

[PATCH 04/12] ARM: dts: omap: Remove WAKEUPENABLE mux options for UARTs

[Tony Lindgren]

This is no longer needed as the device specific wake-up event
can now be specified with interrupts-extended property where
the second interrupt is the pinctrl-single register, such as
the UART3 RX pin.

Note that twl4030_omap3.dtsi needs to set WAKEUPENABLE for
off-idle to properly trigger the PMIC scripts. And GPIO pins
still need to set WAKEUPENABLE for wake-up events.

Signed-off-by: Tony Lindgren <tony@atomide.com>
---
 arch/arm/boot/dts/omap3-beagle-xm.dts | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/arch/arm/boot/dts/omap3-beagle-xm.dts b/arch/arm/boot/dts/omap3-beagle-xm.dts
index 1becefc..06a8aec 100644
--- a/arch/arm/boot/dts/omap3-beagle-xm.dts
+++ b/arch/arm/boot/dts/omap3-beagle-xm.dts
@@ -174,8 +174,8 @@
 
 	uart3_pins: pinmux_uart3_pins {
 		pinctrl-single,pins = <
-			0x16e (PIN_INPUT | PIN_OFF_WAKEUPENABLE | MUX_MODE0) /* uart3_rx_irrx.uart3_rx_irrx */
-			0x170 (PIN_OUTPUT | MUX_MODE0) /* uart3_tx_irtx.uart3_tx_irtx OUTPUT | MODE0 */
+			0x16e (PIN_INPUT | MUX_MODE0)	/* uart3_rx_irrx.uart3_rx_irrx */
+			0x170 (PIN_OUTPUT | MUX_MODE0)	/* uart3_tx_irtx.uart3_tx_irtx OUTPUT | MODE0 */
 		>;
 	};
 
-- 
2.1.0

[PATCH 05/12] ARM: dts: Do not set pulls for I2C lines

[Tony Lindgren]

There are external pulls on these lines and enabling the
internal pulls can cause issue. This is because the internal
pulls are parallel with the external pulls. So let's clear
the internal I2C pulls.

Signed-off-by: Tony Lindgren <tony@atomide.com>
---
 arch/arm/boot/dts/omap3-n900.dts | 12 ++++++------
 1 file changed, 6 insertions(+), 6 deletions(-)

diff --git a/arch/arm/boot/dts/omap3-n900.dts b/arch/arm/boot/dts/omap3-n900.dts
index 1fe45d1..f0d8236 100644
--- a/arch/arm/boot/dts/omap3-n900.dts
+++ b/arch/arm/boot/dts/omap3-n900.dts
@@ -136,22 +136,22 @@
 
 	i2c1_pins: pinmux_i2c1_pins {
 		pinctrl-single,pins = <
-			0x18a (PIN_INPUT_PULLUP | MUX_MODE0)	/* i2c1_scl */
-			0x18c (PIN_INPUT_PULLUP | MUX_MODE0)	/* i2c1_sda */
+			0x18a (PIN_INPUT | MUX_MODE0)		/* i2c1_scl */
+			0x18c (PIN_INPUT | MUX_MODE0)		/* i2c1_sda */
 		>;
 	};
 
 	i2c2_pins: pinmux_i2c2_pins {
 		pinctrl-single,pins = <
-			0x18e (PIN_INPUT_PULLUP | MUX_MODE0)	/* i2c2_scl */
-			0x190 (PIN_INPUT_PULLUP | MUX_MODE0)	/* i2c2_sda */
+			0x18e (PIN_INPUT | MUX_MODE0)		/* i2c2_scl */
+			0x190 (PIN_INPUT | MUX_MODE0)		/* i2c2_sda */
 		>;
 	};
 
 	i2c3_pins: pinmux_i2c3_pins {
 		pinctrl-single,pins = <
-			0x192 (PIN_INPUT_PULLUP | MUX_MODE0)	/* i2c3_scl */
-			0x194 (PIN_INPUT_PULLUP | MUX_MODE0)	/* i2c3_sda */
+			0x192 (PIN_INPUT | MUX_MODE0)		/* i2c3_scl */
+			0x194 (PIN_INPUT | MUX_MODE0)		/* i2c3_sda */
 		>;
 	};
 
-- 
2.1.0

[PATCH 06/12] ARM: dts: Add support for Ethernet on some N900 macro boards

[Tony Lindgren]

As we have support for this in board-rx51-peripherals.c, let's
add it to the .dts files too.

Note that the reset GPIO will eventually go to the driver.
For now let's just pull it down and skip any further reset
in case the bootloader has configured the MAC address so
NFSroot works.

Also note that after 3430-sdp are using proper GPMC timings
we can remove the tests for smsc,lan91c94 in gpmc.c.

Signed-off-by: Tony Lindgren <tony@atomide.com>
---
 arch/arm/boot/dts/omap3-n900.dts   | 42 ++++++++++++++++++++++++++++++++++++++
 arch/arm/mach-omap2/pdata-quirks.c |  3 +++
 2 files changed, 45 insertions(+)

diff --git a/arch/arm/boot/dts/omap3-n900.dts b/arch/arm/boot/dts/omap3-n900.dts
index f0d8236..19a5857 100644
--- a/arch/arm/boot/dts/omap3-n900.dts
+++ b/arch/arm/boot/dts/omap3-n900.dts
@@ -134,6 +134,14 @@
 		>;
 	};
 
+	ethernet_pins: pinmux_ethernet_pins {
+		pinctrl-single,pins = <
+			OMAP3_CORE1_IOPAD(0x20b4, PIN_INPUT_PULLDOWN | MUX_MODE4)	/* gpmc_ncs3.gpio_54 */
+			OMAP3_CORE1_IOPAD(0x20fc, PIN_OUTPUT | MUX_MODE4)		/* dss_data16.gpio_86 */
+			OMAP3_CORE1_IOPAD(0x219c, PIN_OUTPUT | MUX_MODE4)		/* uart3_rts_sd.gpio_164 */
+		>;
+	};
+
 	i2c1_pins: pinmux_i2c1_pins {
 		pinctrl-single,pins = <
 			0x18a (PIN_INPUT | MUX_MODE0)		/* i2c1_scl */
@@ -578,6 +586,8 @@
 
 &gpmc {
 	ranges = <0 0 0x04000000 0x10000000>; /* 256MB */
+	ranges = <0 0 0x01000000 0x01000000>,	/* 16 MB for OneNAND */
+		 <1 0 0x02000000 0x01000000>;	/* 16 MB for smc91c96 */
 
 	/* gpio-irq for dma: 65 */
 
@@ -646,6 +656,38 @@
 			reg = <0x004c0000 0x0fb40000>;
 		};
 	};
+
+	ethernet at gpmc {
+		compatible = "smsc,lan91c94";
+		interrupt-parent = <&gpio2>;
+		interrupts = <22 IRQ_TYPE_LEVEL_HIGH>;	/* gpio54 */
+		reg = <1 0x300 0xf>;		/* 16 byte IO range at offset 0x300 */
+		bank-width = <2>;
+		pinctrl-names = "default";
+		pinctrl-0 = <&ethernet_pins>;
+		gpmc,device-width = <2>;
+		gpmc,sync-clk-ps = <0>;
+		gpmc,cs-on-ns = <0>;
+		gpmc,cs-rd-off-ns = <48>;
+		gpmc,cs-wr-off-ns = <24>;
+		gpmc,adv-on-ns = <0>;
+		gpmc,adv-rd-off-ns = <0>;
+		gpmc,adv-wr-off-ns = <0>;
+		gpmc,we-on-ns = <12>;
+		gpmc,we-off-ns = <18>;
+		gpmc,oe-on-ns = <12>;
+		gpmc,oe-off-ns = <48>;
+		gpmc,page-burst-access-ns = <0>;
+		gpmc,access-ns = <42>;
+		gpmc,rd-cycle-ns = <180>;
+		gpmc,wr-cycle-ns = <180>;
+		gpmc,bus-turnaround-ns = <0>;
+		gpmc,cycle2cycle-delay-ns = <0>;
+		gpmc,wait-monitoring-ns = <0>;
+		gpmc,clk-activation-ns = <0>;
+		gpmc,wr-access-ns = <0>;
+		gpmc,wr-data-mux-bus-ns = <12>;
+	};
 };
 
 &mcspi1 {
diff --git a/arch/arm/mach-omap2/pdata-quirks.c b/arch/arm/mach-omap2/pdata-quirks.c
index ead7736..540f3f8 100644
--- a/arch/arm/mach-omap2/pdata-quirks.c
+++ b/arch/arm/mach-omap2/pdata-quirks.c
@@ -252,6 +252,9 @@ static void __init nokia_n900_legacy_init(void)
 		platform_device_register(&omap3_rom_rng_device);
 
 	}
+
+	/* Only on some development boards */
+	gpio_request_one(164, GPIOF_OUT_INIT_LOW, "smc91x reset");
 }
 
 static void __init omap3_tao3530_legacy_init(void)
-- 
2.1.0

[PATCH 07/12] ARM: dts: Enable PMIC idle configuration for LDP

[Tony Lindgren]

With the IO chain reconfigure fixed, we can now enable the PMIC
scripts for LDP.

Note that at least on my es3.0 based LDP, the UART seems to be
flakey after wake-up events from off-idle and hangs but eventually
continues.

Signed-off-by: Tony Lindgren <tony@atomide.com>
---
 arch/arm/boot/dts/omap3-ldp.dts | 5 +++++
 1 file changed, 5 insertions(+)

diff --git a/arch/arm/boot/dts/omap3-ldp.dts b/arch/arm/boot/dts/omap3-ldp.dts
index af272c1..72dca0b 100644
--- a/arch/arm/boot/dts/omap3-ldp.dts
+++ b/arch/arm/boot/dts/omap3-ldp.dts
@@ -159,6 +159,11 @@
 		reg = <0x48>;
 		interrupts = <7>; /* SYS_NIRQ cascaded to intc */
 		interrupt-parent = <&intc>;
+
+		twl_power: power {
+			compatible = "ti,twl4030-power-idle";
+			ti,use_poweroff;
+		};
 	};
 };
 
-- 
2.1.0

[PATCH 08/12] ARM: omap2plus_defconfig: Shrink with savedefconfig

[Tony Lindgren]

This saves few lines and makes it easier to make patches
against omap2plus_defconfig.

Signed-off-by: Tony Lindgren <tony@atomide.com>
---
 arch/arm/configs/omap2plus_defconfig | 19 +++----------------
 1 file changed, 3 insertions(+), 16 deletions(-)

diff --git a/arch/arm/configs/omap2plus_defconfig b/arch/arm/configs/omap2plus_defconfig
index f650f00..fc63855 100644
--- a/arch/arm/configs/omap2plus_defconfig
+++ b/arch/arm/configs/omap2plus_defconfig
@@ -32,7 +32,6 @@ CONFIG_SOC_OMAP5=y
 CONFIG_SOC_AM33XX=y
 CONFIG_SOC_AM43XX=y
 CONFIG_SOC_DRA7XX=y
-CONFIG_CACHE_L2X0=y
 CONFIG_ARM_THUMBEE=y
 CONFIG_ARM_ERRATA_411920=y
 CONFIG_SMP=y
@@ -44,7 +43,6 @@ CONFIG_ARM_APPENDED_DTB=y
 CONFIG_ARM_ATAG_DTB_COMPAT=y
 CONFIG_CMDLINE="root=/dev/mmcblk0p2 rootwait console=ttyO2,115200"
 CONFIG_KEXEC=y
-CONFIG_FPE_NWFPE=y
 CONFIG_CPU_IDLE=y
 CONFIG_BINFMT_MISC=y
 CONFIG_PM_DEBUG=y
@@ -75,8 +73,6 @@ CONFIG_BT_HCIBCM203X=m
 CONFIG_BT_HCIBPA10X=m
 CONFIG_CFG80211=m
 CONFIG_MAC80211=m
-CONFIG_MAC80211_RC_PID=y
-CONFIG_MAC80211_RC_DEFAULT_PID=y
 CONFIG_UEVENT_HELPER_PATH="/sbin/hotplug"
 CONFIG_DEVTMPFS=y
 CONFIG_DEVTMPFS_MOUNT=y
@@ -103,7 +99,6 @@ CONFIG_BMP085_I2C=m
 CONFIG_SENSORS_LIS3_I2C=m
 CONFIG_SCSI=y
 CONFIG_BLK_DEV_SD=y
-CONFIG_SCSI_MULTI_LUN=y
 CONFIG_SCSI_SCAN_ASYNC=y
 CONFIG_MD=y
 CONFIG_NETDEVICES=y
@@ -162,15 +157,12 @@ CONFIG_DEBUG_GPIO=y
 CONFIG_GPIO_SYSFS=y
 CONFIG_GPIO_TWL4030=y
 CONFIG_W1=y
-CONFIG_POWER_SUPPLY=y
 CONFIG_POWER_AVS=y
 CONFIG_SENSORS_LM75=m
 CONFIG_THERMAL=y
 CONFIG_THERMAL_GOV_FAIR_SHARE=y
 CONFIG_THERMAL_GOV_USER_SPACE=y
-CONFIG_CPU_THERMAL=y
 CONFIG_TI_SOC_THERMAL=y
-CONFIG_TI_THERMAL=y
 CONFIG_OMAP4_THERMAL=y
 CONFIG_OMAP5_THERMAL=y
 CONFIG_DRA752_THERMAL=y
@@ -183,8 +175,8 @@ CONFIG_MFD_TPS65217=y
 CONFIG_MFD_TPS65218=y
 CONFIG_MFD_TPS65910=y
 CONFIG_TWL6040_CORE=y
-CONFIG_REGULATOR_FIXED_VOLTAGE=y
 CONFIG_REGULATOR_PALMAS=y
+CONFIG_REGULATOR_PBIAS=y
 CONFIG_REGULATOR_TI_ABB=y
 CONFIG_REGULATOR_TPS65023=y
 CONFIG_REGULATOR_TPS6507X=y
@@ -192,7 +184,6 @@ CONFIG_REGULATOR_TPS65217=y
 CONFIG_REGULATOR_TPS65218=y
 CONFIG_REGULATOR_TPS65910=y
 CONFIG_REGULATOR_TWL4030=y
-CONFIG_REGULATOR_PBIAS=y
 CONFIG_FB=y
 CONFIG_FIRMWARE_EDID=y
 CONFIG_FB_MODE_HELPERS=y
@@ -221,8 +212,6 @@ CONFIG_SND_DEBUG=y
 CONFIG_SND_USB_AUDIO=m
 CONFIG_SND_SOC=m
 CONFIG_SND_OMAP_SOC=m
-CONFIG_SND_AM33XX_SOC_EVM=m
-CONFIG_SND_DAVINCI_SOC=m
 CONFIG_SND_OMAP_SOC_OMAP_TWL4030=m
 CONFIG_SND_OMAP_SOC_OMAP_ABE_TWL6040=m
 CONFIG_SND_OMAP_SOC_OMAP3_PANDORA=m
@@ -233,9 +222,6 @@ CONFIG_USB_WDM=y
 CONFIG_USB_STORAGE=y
 CONFIG_USB_DWC3=m
 CONFIG_USB_TEST=y
-CONFIG_NOP_USB_XCEIV=y
-CONFIG_OMAP_USB2=y
-CONFIG_TI_PIPE3=y
 CONFIG_AM335X_PHY_USB=y
 CONFIG_USB_GADGET=y
 CONFIG_USB_GADGET_DEBUG=y
@@ -243,7 +229,6 @@ CONFIG_USB_GADGET_DEBUG_FILES=y
 CONFIG_USB_GADGET_DEBUG_FS=y
 CONFIG_USB_ZERO=m
 CONFIG_MMC=y
-CONFIG_MMC_UNSAFE_RESUME=y
 CONFIG_SDIO_UART=y
 CONFIG_MMC_OMAP=y
 CONFIG_MMC_OMAP_HS=y
@@ -267,6 +252,8 @@ CONFIG_TI_EDMA=y
 CONFIG_DMA_OMAP=y
 CONFIG_EXTCON=y
 CONFIG_EXTCON_PALMAS=y
+CONFIG_OMAP_USB2=y
+CONFIG_TI_PIPE3=y
 CONFIG_EXT2_FS=y
 CONFIG_EXT3_FS=y
 # CONFIG_EXT3_FS_XATTR is not set
-- 
2.1.0

[PATCH 09/12] ARM: omap2plus_defconfig: Add cpufreq to defconfig

[Tony Lindgren]

Note that we can now use the CONFIG_GENERIC_CPUFREQ_CPU0,
so let's only enable that.

Signed-off-by: Tony Lindgren <tony@atomide.com>
---
 arch/arm/configs/omap2plus_defconfig | 7 +++++++
 1 file changed, 7 insertions(+)

diff --git a/arch/arm/configs/omap2plus_defconfig b/arch/arm/configs/omap2plus_defconfig
index fc63855..9d232a5 100644
--- a/arch/arm/configs/omap2plus_defconfig
+++ b/arch/arm/configs/omap2plus_defconfig
@@ -43,6 +43,13 @@ CONFIG_ARM_APPENDED_DTB=y
 CONFIG_ARM_ATAG_DTB_COMPAT=y
 CONFIG_CMDLINE="root=/dev/mmcblk0p2 rootwait console=ttyO2,115200"
 CONFIG_KEXEC=y
+CONFIG_CPU_FREQ=y
+CONFIG_CPU_FREQ_GOV_POWERSAVE=y
+CONFIG_CPU_FREQ_GOV_USERSPACE=y
+CONFIG_CPU_FREQ_GOV_ONDEMAND=y
+CONFIG_CPU_FREQ_GOV_CONSERVATIVE=y
+CONFIG_GENERIC_CPUFREQ_CPU0=y
+# CONFIG_ARM_OMAP2PLUS_CPUFREQ is not set
 CONFIG_CPU_IDLE=y
 CONFIG_BINFMT_MISC=y
 CONFIG_PM_DEBUG=y
-- 
2.1.0

[PATCH 10/12] ARM: omap2plus_defconfig: Add support for distros with systemd

[Tony Lindgren]

Some distros are now using systemd, so let's enable most of
what's recommended at:

http://cgit.freedesktop.org/systemd/systemd/tree/README

Signed-off-by: Tony Lindgren <tony@atomide.com>
---
 arch/arm/configs/omap2plus_defconfig | 24 ++++++++++++++++++++++--
 1 file changed, 22 insertions(+), 2 deletions(-)

diff --git a/arch/arm/configs/omap2plus_defconfig b/arch/arm/configs/omap2plus_defconfig
index 9d232a5..8e6c363 100644
--- a/arch/arm/configs/omap2plus_defconfig
+++ b/arch/arm/configs/omap2plus_defconfig
@@ -1,11 +1,28 @@
 CONFIG_SYSVIPC=y
 CONFIG_POSIX_MQUEUE=y
+CONFIG_FHANDLE=y
+CONFIG_AUDIT=y
 CONFIG_NO_HZ=y
 CONFIG_HIGH_RES_TIMERS=y
 CONFIG_BSD_PROCESS_ACCT=y
 CONFIG_IKCONFIG=y
 CONFIG_IKCONFIG_PROC=y
 CONFIG_LOG_BUF_SHIFT=16
+CONFIG_CGROUPS=y
+CONFIG_CGROUP_FREEZER=y
+CONFIG_CGROUP_DEVICE=y
+CONFIG_CPUSETS=y
+CONFIG_CGROUP_CPUACCT=y
+CONFIG_RESOURCE_COUNTERS=y
+CONFIG_MEMCG=y
+CONFIG_MEMCG_SWAP=y
+CONFIG_MEMCG_KMEM=y
+CONFIG_CGROUP_PERF=y
+CONFIG_CGROUP_SCHED=y
+CONFIG_CFS_BANDWIDTH=y
+CONFIG_RT_GROUP_SCHED=y
+CONFIG_BLK_CGROUP=y
+CONFIG_NAMESPACES=y
 CONFIG_BLK_DEV_INITRD=y
 CONFIG_EXPERT=y
 CONFIG_SLAB=y
@@ -37,6 +54,7 @@ CONFIG_ARM_ERRATA_411920=y
 CONFIG_SMP=y
 CONFIG_NR_CPUS=2
 CONFIG_CMA=y
+CONFIG_SECCOMP=y
 CONFIG_ZBOOT_ROM_TEXT=0x0
 CONFIG_ZBOOT_ROM_BSS=0x0
 CONFIG_ARM_APPENDED_DTB=y
@@ -66,7 +84,7 @@ CONFIG_IP_PNP_DHCP=y
 CONFIG_IP_PNP_BOOTP=y
 CONFIG_IP_PNP_RARP=y
 # CONFIG_INET_LRO is not set
-# CONFIG_IPV6 is not set
+CONFIG_IPV6=y
 CONFIG_NETFILTER=y
 CONFIG_CAN=m
 CONFIG_CAN_C_CAN=m
@@ -80,7 +98,6 @@ CONFIG_BT_HCIBCM203X=m
 CONFIG_BT_HCIBPA10X=m
 CONFIG_CFG80211=m
 CONFIG_MAC80211=m
-CONFIG_UEVENT_HELPER_PATH="/sbin/hotplug"
 CONFIG_DEVTMPFS=y
 CONFIG_DEVTMPFS_MOUNT=y
 CONFIG_DMA_CMA=y
@@ -265,11 +282,14 @@ CONFIG_EXT2_FS=y
 CONFIG_EXT3_FS=y
 # CONFIG_EXT3_FS_XATTR is not set
 CONFIG_EXT4_FS=y
+CONFIG_FANOTIFY=y
 CONFIG_QUOTA=y
 CONFIG_QFMT_V2=y
+CONFIG_AUTOFS4_FS=y
 CONFIG_MSDOS_FS=y
 CONFIG_VFAT_FS=y
 CONFIG_TMPFS=y
+CONFIG_TMPFS_POSIX_ACL=y
 CONFIG_JFFS2_FS=y
 CONFIG_JFFS2_SUMMARY=y
 CONFIG_JFFS2_FS_XATTR=y
-- 
2.1.0

[PATCH 11/12] ARM: omap2plus_defconfig: Enable battery and reset drivers

[Tony Lindgren]

Since many omaps run on battery, we should have the battery
drivers enabled. Let's also enable the reset driver.

Signed-off-by: Tony Lindgren <tony@atomide.com>
---
 arch/arm/configs/omap2plus_defconfig | 7 +++++++
 1 file changed, 7 insertions(+)

diff --git a/arch/arm/configs/omap2plus_defconfig b/arch/arm/configs/omap2plus_defconfig
index 8e6c363..113f104 100644
--- a/arch/arm/configs/omap2plus_defconfig
+++ b/arch/arm/configs/omap2plus_defconfig
@@ -181,6 +181,13 @@ CONFIG_DEBUG_GPIO=y
 CONFIG_GPIO_SYSFS=y
 CONFIG_GPIO_TWL4030=y
 CONFIG_W1=y
+CONFIG_BATTERY_BQ27x00=m
+CONFIG_CHARGER_ISP1704=m
+CONFIG_CHARGER_TWL4030=m
+CONFIG_CHARGER_BQ2415X=m
+CONFIG_CHARGER_BQ24190=m
+CONFIG_CHARGER_BQ24735=m
+CONFIG_POWER_RESET=y
 CONFIG_POWER_AVS=y
 CONFIG_SENSORS_LM75=m
 CONFIG_THERMAL=y
-- 
2.1.0

[PATCH 12/12] ARM: omap2plus_defconfig: Enable some display features

[Tony Lindgren]

Now that we have panel support for DT based booting,
let's make it usable and enable most things as modules.

Note that omap3 boards need also the ads7847 module for
the panel that we're now changing to a loadable module.
And n900 seems to require setting the brightness via
sysfs for acx565akm/brightness after modprobe of
panel_sony_acx565akm and omapfb.

Signed-off-by: Tony Lindgren <tony@atomide.com>
---
 arch/arm/configs/omap2plus_defconfig | 22 +++++++++++++++++++++-
 1 file changed, 21 insertions(+), 1 deletion(-)

diff --git a/arch/arm/configs/omap2plus_defconfig b/arch/arm/configs/omap2plus_defconfig
index 113f104..c029e5e 100644
--- a/arch/arm/configs/omap2plus_defconfig
+++ b/arch/arm/configs/omap2plus_defconfig
@@ -157,7 +157,9 @@ CONFIG_KEYBOARD_GPIO=y
 CONFIG_KEYBOARD_MATRIX=m
 CONFIG_KEYBOARD_TWL4030=y
 CONFIG_INPUT_TOUCHSCREEN=y
-CONFIG_TOUCHSCREEN_ADS7846=y
+CONFIG_TOUCHSCREEN_ADS7846=m
+CONFIG_TOUCHSCREEN_TSC2005=m
+CONFIG_TOUCHSCREEN_TSC2007=m
 CONFIG_INPUT_MISC=y
 CONFIG_INPUT_TWL4030_PWRBUTTON=y
 # CONFIG_LEGACY_PTYS is not set
@@ -220,6 +222,7 @@ CONFIG_FIRMWARE_EDID=y
 CONFIG_FB_MODE_HELPERS=y
 CONFIG_FB_TILEBLITTING=y
 CONFIG_OMAP2_DSS=m
+CONFIG_OMAP5_DSS_HDMI=y
 CONFIG_OMAP2_DSS_SDI=y
 CONFIG_OMAP2_DSS_DSI=y
 CONFIG_FB_OMAP2=m
@@ -227,11 +230,25 @@ CONFIG_DISPLAY_ENCODER_TFP410=m
 CONFIG_DISPLAY_ENCODER_TPD12S015=m
 CONFIG_DISPLAY_CONNECTOR_DVI=m
 CONFIG_DISPLAY_CONNECTOR_HDMI=m
+CONFIG_DISPLAY_CONNECTOR_ANALOG_TV=m
 CONFIG_DISPLAY_PANEL_DPI=m
+CONFIG_DISPLAY_PANEL_DSI_CM=m
+CONFIG_DISPLAY_PANEL_SONY_ACX565AKM=m
+CONFIG_DISPLAY_PANEL_LGPHILIPS_LB035Q02=m
+CONFIG_DISPLAY_PANEL_SHARP_LS037V7DW01=m
+CONFIG_DISPLAY_PANEL_TPO_TD028TTEC1=m
+CONFIG_DISPLAY_PANEL_TPO_TD043MTEA1=m
+CONFIG_DISPLAY_PANEL_NEC_NL8048HL11=m
 CONFIG_BACKLIGHT_LCD_SUPPORT=y
 CONFIG_LCD_CLASS_DEVICE=y
 CONFIG_LCD_PLATFORM=y
+CONFIG_BACKLIGHT_CLASS_DEVICE=y
+CONFIG_BACKLIGHT_GENERIC=m
+CONFIG_BACKLIGHT_PWM=m
+CONFIG_BACKLIGHT_PANDORA=m
+CONFIG_BACKLIGHT_GPIO=m
 CONFIG_FRAMEBUFFER_CONSOLE=y
+CONFIG_FRAMEBUFFER_CONSOLE_DETECT_PRIMARY=y
 CONFIG_FRAMEBUFFER_CONSOLE_ROTATION=y
 CONFIG_LOGO=y
 CONFIG_SOUND=m
@@ -283,6 +300,9 @@ CONFIG_TI_EDMA=y
 CONFIG_DMA_OMAP=y
 CONFIG_EXTCON=y
 CONFIG_EXTCON_PALMAS=y
+CONFIG_PWM=y
+CONFIG_PWM_TWL=y
+CONFIG_PWM_TWL_LED=y
 CONFIG_OMAP_USB2=y
 CONFIG_TI_PIPE3=y
 CONFIG_EXT2_FS=y
-- 
2.1.0

[PATCH 08/12] ARM: omap2plus_defconfig: Shrink with savedefconfig

[Felipe Balbi]

Hi,

On Mon, Sep 15, 2014 at 08:12:02PM -0700, Tony Lindgren wrote:
> This saves few lines and makes it easier to make patches
> against omap2plus_defconfig.
> 
> Signed-off-by: Tony Lindgren <tony@atomide.com>

while at that, can you enable voluntary preemption ?

-- 
balbi
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20140915/8da29687/attachment.sig>

[PATCH 01/12] ARM: OMAP2+: Add hwmod flag for HWMOD_RECONFIG_IO_CHAIN

[Paul Walmsley]

On Mon, 15 Sep 2014, Tony Lindgren wrote:

> Commit cc824534d4fe ("ARM: OMAP2+: hwmod: Rearm wake-up interrupts
> for DT when MUSB is idled") fixed issues with hung UART wake-up
> events by calling _reconfigure_io_chain() when MUSB is connected
> or disconnected.
> 
> As pointed out by Paul Walmsley, we may need to also call
> _reconfigure_io_chain() in other cases, so it should be a separate
> flag. Let's add HWMOD_RECONFIG_IO_CHAIN as suggested by Paul.
> 
> Cc: Paul Walmsley <paul@pwsan.com>
> Signed-off-by: Tony Lindgren <tony@atomide.com>

Reviewed-by: Paul Walmsley <paul@pwsan.com>

Thanks for taking care of this.


- Paul

[PATCH 02/12] ARM: OMAP3: Use force-idle for UARTs because of DMA errata

[Paul Walmsley]

Hi

A few comments

On Mon, 15 Sep 2014, Tony Lindgren wrote:

> In sprz318f.pdf "Usage Note 2.7" says that UARTs cannot acknowledge
> idle requests in smartidle mode when configured for DMA operations.

I don't have Rev. F here.  But reading between the typos in Rev. E, all it 
says that the UART should be placed into force-idle mode when there are no 
DMA transfers scheduled, otherwise CORE won't go idle.  However, this 
patch does a lot more than that...

> This prevents L4 from going idle. So let's use force-idle mode
> instead and also force reconfiguring of the IO chain wake-up events.
> 
> Otherwise systems using Sebastian's 8250 patches with DMA will
> never enter deeper idle states because of the errata above.
> 
> Cc: Paul Walmsley <paul@pwsan.com>
> Cc: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
> Signed-off-by: Tony Lindgren <tony@atomide.com>
> ---
>  arch/arm/mach-omap2/omap_hwmod_3xxx_data.c | 15 +++++++++++----
>  1 file changed, 11 insertions(+), 4 deletions(-)
> 
> diff --git a/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c b/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
> index 61cd49d..55f088c 100644
> --- a/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
> +++ b/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
> @@ -490,7 +490,9 @@ static struct omap_hwmod omap3xxx_uart1_hwmod = {
>  	.mpu_irqs	= omap2_uart1_mpu_irqs,
>  	.sdma_reqs	= omap2_uart1_sdma_reqs,
>  	.main_clk	= "uart1_fck",
> -	.flags		= DEBUG_TI81XXUART1_FLAGS | HWMOD_SWSUP_SIDLE_ACT,
> +	.flags		= DEBUG_TI81XXUART1_FLAGS |
> +				HWMOD_NO_OCP_AUTOIDLE | HWMOD_SWSUP_SIDLE |
> +				HWMOD_FORCE_MSTANDBY | HWMOD_RECONFIG_IO_CHAIN,

... this patch makes four significant changes to the hwmod flags:

1. It changes HWMOD_SWSUP_SIDLE_ACT to HWMOD_SWSUP_SIDLE

2. It adds HWMOD_NO_OCP_AUTOIDLE

3. It adds HWMOD_FORCE_MSTANDBY

4. It adds HWMOD_RECONFIG_IO_CHAIN 

As far as I can tell, the only change that actually matches the erratum 
usage note is #1.  And even that should only be activated when the UART is 
in DMA mode.. PIO mode shouldn't need it.  (We used to have a DMA-specific 
workaround in the driver code for this years ago, which was only enabled 
when DMA was used, but it got ripped out in the rush to get rid of the 
platform_data function pointers.)

So that leaves the other three flag changes.  Of those three, adding 
HWMOD_FORCE_MSTANDBY is definitely not correct according to the 34xx 
public TRM Rev. ZV, since the UART IP blocks:

a) have no master port, 

b) do not contain DMA controllers (they rely on the SDMA), and 

c) according to the SYSC_REG register documentation in Table 17-112 of the 
above TRM, have no MIDLEMODE bit field.

So adding HWMOD_FORCE_MSTANDBY should have zero effect and it most likely 
should be dropped.

Regarding the rest: 

I'd be pretty surprised if HWMOD_RECONFIG_IO_CHAIN is needed.  If that was 
needed, I'd think we would have seen wakeup failures in this path a long 
time ago, since the console serial port is the primary debug tool we used
for waking the chip up from deep idle states on demand.

As far as HWMOD_NO_OCP_AUTOIDLE goes: does adding this flag have an effect 
when HWMOD_SWSUP_SIDLE is used?  If so then this should probably go in as 
a separate patch, because it's probably a separate bug than the one 
described in the commit message.

...

So I'd suggest restricting this patch to simply change 
HWMOD_SWSUP_SIDLE_ACT to HWMOD_SWSUP_SIDLE.  Then if the other flags are 
needed, would suggest adding them in separate patches, describing what 
problems are fixed by adding them.


- Paul

[PATCH 02/12] ARM: OMAP3: Use force-idle for UARTs because of DMA errata

[Tony Lindgren]

* Paul Walmsley <paul@pwsan.com> [140916 10:01]:
> On Mon, 15 Sep 2014, Tony Lindgren wrote:
> 
> > In sprz318f.pdf "Usage Note 2.7" says that UARTs cannot acknowledge
> > idle requests in smartidle mode when configured for DMA operations.
> 
> I don't have Rev. F here.  But reading between the typos in Rev. E, all it 
> says that the UART should be placed into force-idle mode when there are no 
> DMA transfers scheduled, otherwise CORE won't go idle.  However, this 
> patch does a lot more than that...

OK. The errata above seems to have a bit more info on that.

> > @@ -490,7 +490,9 @@ static struct omap_hwmod omap3xxx_uart1_hwmod = {
> >  	.mpu_irqs	= omap2_uart1_mpu_irqs,
> >  	.sdma_reqs	= omap2_uart1_sdma_reqs,
> >  	.main_clk	= "uart1_fck",
> > -	.flags		= DEBUG_TI81XXUART1_FLAGS | HWMOD_SWSUP_SIDLE_ACT,
> > +	.flags		= DEBUG_TI81XXUART1_FLAGS |
> > +				HWMOD_NO_OCP_AUTOIDLE | HWMOD_SWSUP_SIDLE |
> > +				HWMOD_FORCE_MSTANDBY | HWMOD_RECONFIG_IO_CHAIN,
> 
> ... this patch makes four significant changes to the hwmod flags:
> 
> 1. It changes HWMOD_SWSUP_SIDLE_ACT to HWMOD_SWSUP_SIDLE
> 
> 2. It adds HWMOD_NO_OCP_AUTOIDLE
> 
> 3. It adds HWMOD_FORCE_MSTANDBY
> 
> 4. It adds HWMOD_RECONFIG_IO_CHAIN 
> 
> As far as I can tell, the only change that actually matches the erratum 
> usage note is #1.  And even that should only be activated when the UART is 
> in DMA mode.. PIO mode shouldn't need it.  (We used to have a DMA-specific 
> workaround in the driver code for this years ago, which was only enabled 
> when DMA was used, but it got ripped out in the rush to get rid of the 
> platform_data function pointers.)

Indeed that's the case. Only #1 above is needed.

It seems I intially just blindly copied the MUSB related changes for
UART to get Sebastian's series going with DMA, then just rebased those
changes blindly on the HWMOD_RECONFIG_IO_CHAIN patch.

For toggling the DMA vs PIO mode, that should be done with some Linux
generic API from the driver. But since we don't have that, I don't think
there's much overhead for always configuring for DMA mode. Or do you
see some issues with that?
 
> So that leaves the other three flag changes.  Of those three, adding 
> HWMOD_FORCE_MSTANDBY is definitely not correct according to the 34xx 
> public TRM Rev. ZV, since the UART IP blocks:
> 
> a) have no master port, 
> 
> b) do not contain DMA controllers (they rely on the SDMA), and 
> 
> c) according to the SYSC_REG register documentation in Table 17-112 of the 
> above TRM, have no MIDLEMODE bit field.
> 
> So adding HWMOD_FORCE_MSTANDBY should have zero effect and it most likely 
> should be dropped.

OK. That's left over from blind copy-paste from MUSB related changes and
not needed.
 
> Regarding the rest: 
> 
> I'd be pretty surprised if HWMOD_RECONFIG_IO_CHAIN is needed.  If that was 
> needed, I'd think we would have seen wakeup failures in this path a long 
> time ago, since the console serial port is the primary debug tool we used
> for waking the chip up from deep idle states on demand.

OK. Does not seem to be needed.
 
> As far as HWMOD_NO_OCP_AUTOIDLE goes: does adding this flag have an effect 
> when HWMOD_SWSUP_SIDLE is used?  If so then this should probably go in as 
> a separate patch, because it's probably a separate bug than the one 
> described in the commit message.

That does not seem to be needed either. 
 
> So I'd suggest restricting this patch to simply change 
> HWMOD_SWSUP_SIDLE_ACT to HWMOD_SWSUP_SIDLE.  Then if the other flags are 
> needed, would suggest adding them in separate patches, describing what 
> problems are fixed by adding them.

Yes great. I've verified that's enough to make it work properly with off-idle
and dma when tested against Sebastian's uart_v10_pre1 branch.

Updated patch below, thanks for catching the bogus configuration.

Regards,

Tony

8< --------------
From: Tony Lindgren <tony@atomide.com>
Date: Wed, 10 Sep 2014 16:22:31 -0700
Subject: [PATCH] ARM: OMAP3: Use manual idle for UARTs because of DMA errata

In sprz318f.pdf "Usage Note 2.7" says that UARTs cannot acknowledge
idle requests in smartidle mode when configured for DMA operations.
This prevents L4 from going idle. So let's use manual idle mode
instead.

Otherwise systems using Sebastian's 8250 patches with DMA will
never enter deeper idle states because of the errata above.

Cc: Paul Walmsley <paul@pwsan.com>
Cc: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
Signed-off-by: Tony Lindgren <tony@atomide.com>

--- a/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
@@ -490,7 +490,7 @@ static struct omap_hwmod omap3xxx_uart1_hwmod = {
 	.mpu_irqs	= omap2_uart1_mpu_irqs,
 	.sdma_reqs	= omap2_uart1_sdma_reqs,
 	.main_clk	= "uart1_fck",
-	.flags		= DEBUG_TI81XXUART1_FLAGS | HWMOD_SWSUP_SIDLE_ACT,
+	.flags		= DEBUG_TI81XXUART1_FLAGS | HWMOD_SWSUP_SIDLE,
 	.prcm		= {
 		.omap2 = {
 			.module_offs = CORE_MOD,
@@ -509,7 +509,7 @@ static struct omap_hwmod omap3xxx_uart2_hwmod = {
 	.mpu_irqs	= omap2_uart2_mpu_irqs,
 	.sdma_reqs	= omap2_uart2_sdma_reqs,
 	.main_clk	= "uart2_fck",
-	.flags		= DEBUG_TI81XXUART2_FLAGS | HWMOD_SWSUP_SIDLE_ACT,
+	.flags		= DEBUG_TI81XXUART2_FLAGS | HWMOD_SWSUP_SIDLE,
 	.prcm		= {
 		.omap2 = {
 			.module_offs = CORE_MOD,
@@ -529,7 +529,7 @@ static struct omap_hwmod omap3xxx_uart3_hwmod = {
 	.sdma_reqs	= omap2_uart3_sdma_reqs,
 	.main_clk	= "uart3_fck",
 	.flags		= DEBUG_OMAP3UART3_FLAGS | DEBUG_TI81XXUART3_FLAGS |
-				HWMOD_SWSUP_SIDLE_ACT,
+				HWMOD_SWSUP_SIDLE,
 	.prcm		= {
 		.omap2 = {
 			.module_offs = OMAP3430_PER_MOD,
@@ -559,7 +559,7 @@ static struct omap_hwmod omap36xx_uart4_hwmod = {
 	.mpu_irqs	= uart4_mpu_irqs,
 	.sdma_reqs	= uart4_sdma_reqs,
 	.main_clk	= "uart4_fck",
-	.flags		= DEBUG_OMAP3UART4_FLAGS | HWMOD_SWSUP_SIDLE_ACT,
+	.flags		= DEBUG_OMAP3UART4_FLAGS | HWMOD_SWSUP_SIDLE,
 	.prcm		= {
 		.omap2 = {
 			.module_offs = OMAP3430_PER_MOD,

[PATCH 02/12] ARM: OMAP3: Use force-idle for UARTs because of DMA errata

[Paul Walmsley]

On Tue, 16 Sep 2014, Tony Lindgren wrote:

> For toggling the DMA vs PIO mode, that should be done with some Linux
> generic API from the driver. But since we don't have that, I don't think
> there's much overhead for always configuring for DMA mode. Or do you
> see some issues with that?

I think it should be OK.  Probably it would not be a case of additional 
overhead.  The impact would be on UART wakeup handling.  We'll just want 
to keep an eye on wakeups from characters received on the UART, and if 
those start flaking out occasionally, we might take a closer look at this 
patch.  

The race window, if it even exists, would be pretty narrow.  And the 
erratum usage note doesn't mention any impact on wakeups...  

> Yes great. I've verified that's enough to make it work properly with off-idle
> and dma when tested against Sebastian's uart_v10_pre1 branch.
> 
> Updated patch below, thanks for catching the bogus configuration.

Cool, thanks for looking into those flags.

Reviewed-by: Paul Walmsley <paul@pwsan.com>


- Paul

[PATCH 10/12] ARM: omap2plus_defconfig: Add support for distros with systemd

[Javier Martinez Canillas]

Hello Tony,

On Tue, Sep 16, 2014 at 5:12 AM, Tony Lindgren <tony@atomide.com> wrote:
> Some distros are now using systemd, so let's enable most of
> what's recommended at:
>
> http://cgit.freedesktop.org/systemd/systemd/tree/README
>
> Signed-off-by: Tony Lindgren <tony@atomide.com>
> ---
>  arch/arm/configs/omap2plus_defconfig | 24 ++++++++++++++++++++++--
>  1 file changed, 22 insertions(+), 2 deletions(-)
>
> diff --git a/arch/arm/configs/omap2plus_defconfig b/arch/arm/configs/omap2plus_defconfig
> index 9d232a5..8e6c363 100644
> --- a/arch/arm/configs/omap2plus_defconfig
> +++ b/arch/arm/configs/omap2plus_defconfig
> @@ -1,11 +1,28 @@
>  CONFIG_SYSVIPC=y
>  CONFIG_POSIX_MQUEUE=y
> +CONFIG_FHANDLE=y
> +CONFIG_AUDIT=y
>  CONFIG_NO_HZ=y
>  CONFIG_HIGH_RES_TIMERS=y
>  CONFIG_BSD_PROCESS_ACCT=y
>  CONFIG_IKCONFIG=y
>  CONFIG_IKCONFIG_PROC=y
>  CONFIG_LOG_BUF_SHIFT=16
> +CONFIG_CGROUPS=y
> +CONFIG_CGROUP_FREEZER=y
> +CONFIG_CGROUP_DEVICE=y
> +CONFIG_CPUSETS=y
> +CONFIG_CGROUP_CPUACCT=y
> +CONFIG_RESOURCE_COUNTERS=y
> +CONFIG_MEMCG=y
> +CONFIG_MEMCG_SWAP=y
> +CONFIG_MEMCG_KMEM=y
> +CONFIG_CGROUP_PERF=y
> +CONFIG_CGROUP_SCHED=y
> +CONFIG_CFS_BANDWIDTH=y
> +CONFIG_RT_GROUP_SCHED=y
> +CONFIG_BLK_CGROUP=y
> +CONFIG_NAMESPACES=y
>  CONFIG_BLK_DEV_INITRD=y
>  CONFIG_EXPERT=y
>  CONFIG_SLAB=y
> @@ -37,6 +54,7 @@ CONFIG_ARM_ERRATA_411920=y
>  CONFIG_SMP=y
>  CONFIG_NR_CPUS=2
>  CONFIG_CMA=y
> +CONFIG_SECCOMP=y
>  CONFIG_ZBOOT_ROM_TEXT=0x0
>  CONFIG_ZBOOT_ROM_BSS=0x0
>  CONFIG_ARM_APPENDED_DTB=y
> @@ -66,7 +84,7 @@ CONFIG_IP_PNP_DHCP=y
>  CONFIG_IP_PNP_BOOTP=y
>  CONFIG_IP_PNP_RARP=y
>  # CONFIG_INET_LRO is not set
> -# CONFIG_IPV6 is not set
> +CONFIG_IPV6=y
>  CONFIG_NETFILTER=y
>  CONFIG_CAN=m
>  CONFIG_CAN_C_CAN=m
> @@ -80,7 +98,6 @@ CONFIG_BT_HCIBCM203X=m
>  CONFIG_BT_HCIBPA10X=m
>  CONFIG_CFG80211=m
>  CONFIG_MAC80211=m
> -CONFIG_UEVENT_HELPER_PATH="/sbin/hotplug"
>  CONFIG_DEVTMPFS=y
>  CONFIG_DEVTMPFS_MOUNT=y
>  CONFIG_DMA_CMA=y
> @@ -265,11 +282,14 @@ CONFIG_EXT2_FS=y
>  CONFIG_EXT3_FS=y
>  # CONFIG_EXT3_FS_XATTR is not set
>  CONFIG_EXT4_FS=y
> +CONFIG_FANOTIFY=y
>  CONFIG_QUOTA=y
>  CONFIG_QFMT_V2=y
> +CONFIG_AUTOFS4_FS=y
>  CONFIG_MSDOS_FS=y
>  CONFIG_VFAT_FS=y
>  CONFIG_TMPFS=y
> +CONFIG_TMPFS_POSIX_ACL=y
>  CONFIG_JFFS2_FS=y
>  CONFIG_JFFS2_SUMMARY=y
>  CONFIG_JFFS2_FS_XATTR=y
> --

Looks good to me, so:

Reviewed-by: Javier Martinez Canillas <javier.martinez@collabora.co.uk>

I think that the same options should be enabled in multi_v7_defconfig BTW.

Best regards,
Javier

[PATCH 08/12] ARM: omap2plus_defconfig: Shrink with savedefconfig

[Tony Lindgren]

* Felipe Balbi <balbi@ti.com> [140915 21:57]:
> Hi,
> 
> On Mon, Sep 15, 2014 at 08:12:02PM -0700, Tony Lindgren wrote:
> > This saves few lines and makes it easier to make patches
> > against omap2plus_defconfig.
> > 
> > Signed-off-by: Tony Lindgren <tony@atomide.com>
> 
> while at that, can you enable voluntary preemption ?

OK, can you do a separate patch for that with a brief description
why it should be enabled?

Regards,

Tony

[PATCH 08/12] ARM: omap2plus_defconfig: Shrink with savedefconfig

[Felipe Balbi]

Hi,

On Thu, Sep 18, 2014 at 08:57:32AM -0700, Tony Lindgren wrote:
> * Felipe Balbi <balbi@ti.com> [140915 21:57]:
> > Hi,
> > 
> > On Mon, Sep 15, 2014 at 08:12:02PM -0700, Tony Lindgren wrote:
> > > This saves few lines and makes it easier to make patches
> > > against omap2plus_defconfig.
> > > 
> > > Signed-off-by: Tony Lindgren <tony@atomide.com>
> > 
> > while at that, can you enable voluntary preemption ?
> 
> OK, can you do a separate patch for that with a brief description
> why it should be enabled?

sure, gimme a day or two (busy with other patches).

-- 
balbi
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20140918/1a220e10/attachment.sig>

[PATCH 09/12] ARM: omap2plus_defconfig: Add cpufreq to defconfig

[Nishanth Menon]

On 20:12-20140915, Tony Lindgren wrote:
> Note that we can now use the CONFIG_GENERIC_CPUFREQ_CPU0,
> so let's only enable that.
> 
> Signed-off-by: Tony Lindgren <tony@atomide.com>
> ---
>  arch/arm/configs/omap2plus_defconfig | 7 +++++++
>  1 file changed, 7 insertions(+)
> 
> diff --git a/arch/arm/configs/omap2plus_defconfig b/arch/arm/configs/omap2plus_defconfig
> index fc63855..9d232a5 100644
> --- a/arch/arm/configs/omap2plus_defconfig
> +++ b/arch/arm/configs/omap2plus_defconfig
> @@ -43,6 +43,13 @@ CONFIG_ARM_APPENDED_DTB=y
>  CONFIG_ARM_ATAG_DTB_COMPAT=y
>  CONFIG_CMDLINE="root=/dev/mmcblk0p2 rootwait console=ttyO2,115200"
>  CONFIG_KEXEC=y
> +CONFIG_CPU_FREQ=y
> +CONFIG_CPU_FREQ_GOV_POWERSAVE=y
> +CONFIG_CPU_FREQ_GOV_USERSPACE=y
> +CONFIG_CPU_FREQ_GOV_ONDEMAND=y
> +CONFIG_CPU_FREQ_GOV_CONSERVATIVE=y
> +CONFIG_GENERIC_CPUFREQ_CPU0=y
> +# CONFIG_ARM_OMAP2PLUS_CPUFREQ is not set

With this
we get performace as the default governor.

could we use CONFIG_CPU_FREQ_DEFAULT_GOV_ONDEMAND as the default
instead? on Many TI SoCs using Highest frequency is not really too nice
of an idea for long periods of time. And not everything is upstream to
support things optimially - example avs class 0, 1.5 ABB consolidation
with cpufreq etc.. We definitely need thermal enabled as well for device
safety needs.

I propose the following instead:
@@ -43,6 +43,14 @@ CONFIG_ARM_APPENDED_DTB=y
 CONFIG_ARM_ATAG_DTB_COMPAT=y
 CONFIG_CMDLINE="root=/dev/mmcblk0p2 rootwait console=ttyO2,115200"
 CONFIG_KEXEC=y
+CONFIG_CPU_FREQ=y
+CONFIG_CPU_FREQ_STAT_DETAILS=y
+CONFIG_CPU_FREQ_DEFAULT_GOV_ONDEMAND=y
+CONFIG_CPU_FREQ_GOV_POWERSAVE=y
+CONFIG_CPU_FREQ_GOV_USERSPACE=y
+CONFIG_CPU_FREQ_GOV_CONSERVATIVE=y
+CONFIG_GENERIC_CPUFREQ_CPU0=y
+# CONFIG_ARM_OMAP2PLUS_CPUFREQ is not set
 CONFIG_CPU_IDLE=y
 CONFIG_BINFMT_MISC=y
 CONFIG_PM_DEBUG=y
@@ -162,7 +170,9 @@ CONFIG_SENSORS_LM75=m
 CONFIG_THERMAL=y
 CONFIG_THERMAL_GOV_FAIR_SHARE=y
 CONFIG_THERMAL_GOV_USER_SPACE=y
+CONFIG_CPU_THERMAL=y
 CONFIG_TI_SOC_THERMAL=y
+CONFIG_TI_THERMAL=y
 CONFIG_OMAP4_THERMAL=y
 CONFIG_OMAP5_THERMAL=y
 CONFIG_DRA752_THERMAL=y

-- 
Regards,
Nishanth Menon

[PATCH 09/12] ARM: omap2plus_defconfig: Add cpufreq to defconfig

[Tony Lindgren]

* Nishanth Menon <nm@ti.com> [140918 09:12]:
> On 20:12-20140915, Tony Lindgren wrote:
> > Note that we can now use the CONFIG_GENERIC_CPUFREQ_CPU0,
> > so let's only enable that.
> > 
> > Signed-off-by: Tony Lindgren <tony@atomide.com>
> > ---
> >  arch/arm/configs/omap2plus_defconfig | 7 +++++++
> >  1 file changed, 7 insertions(+)
> > 
> > diff --git a/arch/arm/configs/omap2plus_defconfig b/arch/arm/configs/omap2plus_defconfig
> > index fc63855..9d232a5 100644
> > --- a/arch/arm/configs/omap2plus_defconfig
> > +++ b/arch/arm/configs/omap2plus_defconfig
> > @@ -43,6 +43,13 @@ CONFIG_ARM_APPENDED_DTB=y
> >  CONFIG_ARM_ATAG_DTB_COMPAT=y
> >  CONFIG_CMDLINE="root=/dev/mmcblk0p2 rootwait console=ttyO2,115200"
> >  CONFIG_KEXEC=y
> > +CONFIG_CPU_FREQ=y
> > +CONFIG_CPU_FREQ_GOV_POWERSAVE=y
> > +CONFIG_CPU_FREQ_GOV_USERSPACE=y
> > +CONFIG_CPU_FREQ_GOV_ONDEMAND=y
> > +CONFIG_CPU_FREQ_GOV_CONSERVATIVE=y
> > +CONFIG_GENERIC_CPUFREQ_CPU0=y
> > +# CONFIG_ARM_OMAP2PLUS_CPUFREQ is not set
> 
> With this
> we get performace as the default governor.
> 
> could we use CONFIG_CPU_FREQ_DEFAULT_GOV_ONDEMAND as the default
> instead? on Many TI SoCs using Highest frequency is not really too nice
> of an idea for long periods of time. And not everything is upstream to
> support things optimially - example avs class 0, 1.5 ABB consolidation
> with cpufreq etc.. We definitely need thermal enabled as well for device
> safety needs.

OK, sure. I've applied the following version with your changes folded
in.

Regards,

Tony

8< ---------------
From: Tony Lindgren <tony@atomide.com>
Date: Thu, 18 Sep 2014 09:01:07 -0700
Subject: [PATCH] ARM: omap2plus_defconfig: Add cpufreq to defconfig

Note that we can now use the CONFIG_GENERIC_CPUFREQ_CPU0,
so let's only enable that. Let's use CONFIG_CPU_FREQ_DEFAULT_GOV_ONDEMAND
as suggested by Nishant.

And also let's enable thermal as explained by Nishant Menon:

Many TI SoCs using Highest frequency is not really too nice of an idea for
long periods of time. And not everything is upstream to support things
optimially - example avs class 0, 1.5 ABB consolidation with cpufreq etc..
We definitely need thermal enabled as well for device safety needs.

Cc: Nishanth Menon <nm@ti.com>
[tony at atomide.com: updated per Nishant's suggestions]
Signed-off-by: Tony Lindgren <tony@atomide.com>

--- a/arch/arm/configs/omap2plus_defconfig
+++ b/arch/arm/configs/omap2plus_defconfig
@@ -43,6 +43,14 @@ CONFIG_ARM_APPENDED_DTB=y
 CONFIG_ARM_ATAG_DTB_COMPAT=y
 CONFIG_CMDLINE="root=/dev/mmcblk0p2 rootwait console=ttyO2,115200"
 CONFIG_KEXEC=y
+CONFIG_CPU_FREQ=y
+CONFIG_CPU_FREQ_STAT_DETAILS=y
+CONFIG_CPU_FREQ_DEFAULT_GOV_ONDEMAND=y
+CONFIG_CPU_FREQ_GOV_POWERSAVE=y
+CONFIG_CPU_FREQ_GOV_USERSPACE=y
+CONFIG_CPU_FREQ_GOV_CONSERVATIVE=y
+CONFIG_GENERIC_CPUFREQ_CPU0=y
+# CONFIG_ARM_OMAP2PLUS_CPUFREQ is not set
 CONFIG_CPU_IDLE=y
 CONFIG_BINFMT_MISC=y
 CONFIG_PM_DEBUG=y
@@ -162,7 +170,9 @@ CONFIG_SENSORS_LM75=m
 CONFIG_THERMAL=y
 CONFIG_THERMAL_GOV_FAIR_SHARE=y
 CONFIG_THERMAL_GOV_USER_SPACE=y
+CONFIG_CPU_THERMAL=y
 CONFIG_TI_SOC_THERMAL=y
+CONFIG_TI_THERMAL=y
 CONFIG_OMAP4_THERMAL=y
 CONFIG_OMAP5_THERMAL=y
 CONFIG_DRA752_THERMAL=y

[PATCH 09/12] ARM: omap2plus_defconfig: Add cpufreq to defconfig

[Nishanth Menon]

On 09:20-20140918, Tony Lindgren wrote:
> * Nishanth Menon <nm@ti.com> [140918 09:12]:
> > On 20:12-20140915, Tony Lindgren wrote:
> > > Note that we can now use the CONFIG_GENERIC_CPUFREQ_CPU0,
> > > so let's only enable that.
> > > 
> > > Signed-off-by: Tony Lindgren <tony@atomide.com>
> > > ---
> > >  arch/arm/configs/omap2plus_defconfig | 7 +++++++
> > >  1 file changed, 7 insertions(+)
> > > 
> > > diff --git a/arch/arm/configs/omap2plus_defconfig b/arch/arm/configs/omap2plus_defconfig
> > > index fc63855..9d232a5 100644
> > > --- a/arch/arm/configs/omap2plus_defconfig
> > > +++ b/arch/arm/configs/omap2plus_defconfig
> > > @@ -43,6 +43,13 @@ CONFIG_ARM_APPENDED_DTB=y
> > >  CONFIG_ARM_ATAG_DTB_COMPAT=y
> > >  CONFIG_CMDLINE="root=/dev/mmcblk0p2 rootwait console=ttyO2,115200"
> > >  CONFIG_KEXEC=y
> > > +CONFIG_CPU_FREQ=y
> > > +CONFIG_CPU_FREQ_GOV_POWERSAVE=y
> > > +CONFIG_CPU_FREQ_GOV_USERSPACE=y
> > > +CONFIG_CPU_FREQ_GOV_ONDEMAND=y
> > > +CONFIG_CPU_FREQ_GOV_CONSERVATIVE=y
> > > +CONFIG_GENERIC_CPUFREQ_CPU0=y
> > > +# CONFIG_ARM_OMAP2PLUS_CPUFREQ is not set
> > 
> > With this
> > we get performace as the default governor.
> > 
> > could we use CONFIG_CPU_FREQ_DEFAULT_GOV_ONDEMAND as the default
> > instead? on Many TI SoCs using Highest frequency is not really too nice
> > of an idea for long periods of time. And not everything is upstream to
> > support things optimially - example avs class 0, 1.5 ABB consolidation
> > with cpufreq etc.. We definitely need thermal enabled as well for device
> > safety needs.
> 
> OK, sure. I've applied the following version with your changes folded
> in.
> 
> Regards,
> 
> Tony
> 
> 8< ---------------
> From: Tony Lindgren <tony@atomide.com>
> Date: Thu, 18 Sep 2014 09:01:07 -0700
> Subject: [PATCH] ARM: omap2plus_defconfig: Add cpufreq to defconfig
> 
> Note that we can now use the CONFIG_GENERIC_CPUFREQ_CPU0,
> so let's only enable that. Let's use CONFIG_CPU_FREQ_DEFAULT_GOV_ONDEMAND
> as suggested by Nishant.
> 
> And also let's enable thermal as explained by Nishant Menon:
> 
> Many TI SoCs using Highest frequency is not really too nice of an idea for
> long periods of time. And not everything is upstream to support things
> optimially - example avs class 0, 1.5 ABB consolidation with cpufreq etc..
> We definitely need thermal enabled as well for device safety needs.
> 
> Cc: Nishanth Menon <nm@ti.com>
> [tony at atomide.com: updated per Nishant's suggestions]
> Signed-off-by: Tony Lindgren <tony@atomide.com>
> 
> --- a/arch/arm/configs/omap2plus_defconfig
> +++ b/arch/arm/configs/omap2plus_defconfig
> @@ -43,6 +43,14 @@ CONFIG_ARM_APPENDED_DTB=y
>  CONFIG_ARM_ATAG_DTB_COMPAT=y
>  CONFIG_CMDLINE="root=/dev/mmcblk0p2 rootwait console=ttyO2,115200"
>  CONFIG_KEXEC=y
> +CONFIG_CPU_FREQ=y
> +CONFIG_CPU_FREQ_STAT_DETAILS=y
> +CONFIG_CPU_FREQ_DEFAULT_GOV_ONDEMAND=y
> +CONFIG_CPU_FREQ_GOV_POWERSAVE=y
> +CONFIG_CPU_FREQ_GOV_USERSPACE=y
> +CONFIG_CPU_FREQ_GOV_CONSERVATIVE=y
> +CONFIG_GENERIC_CPUFREQ_CPU0=y
> +# CONFIG_ARM_OMAP2PLUS_CPUFREQ is not set
>  CONFIG_CPU_IDLE=y
>  CONFIG_BINFMT_MISC=y
>  CONFIG_PM_DEBUG=y
> @@ -162,7 +170,9 @@ CONFIG_SENSORS_LM75=m
>  CONFIG_THERMAL=y
>  CONFIG_THERMAL_GOV_FAIR_SHARE=y
>  CONFIG_THERMAL_GOV_USER_SPACE=y
> +CONFIG_CPU_THERMAL=y
>  CONFIG_TI_SOC_THERMAL=y
> +CONFIG_TI_THERMAL=y
>  CONFIG_OMAP4_THERMAL=y
>  CONFIG_OMAP5_THERMAL=y
>  CONFIG_DRA752_THERMAL=y

Acked-by: Nishanth Menon <nm@ti.com>
-- 
Regards,
Nishanth Menon