[PATCH 00/30] ARM/omap: omap specific randconfig fixes

[PATCH 00/30] ARM/omap: omap specific randconfig fixes

[Arnd Bergmann]

Hi Tony,

I've mentioned these patches before, and now I've managed to
go through them again and clean them enough for submission.

If nobody has any objections, I would like to send them to
Linus in the coming merge window, otherwise it would be nice
if you could pick the ones that look good to you and send
me a pull request. If any of these look like they should be
backported to stable kernels, please tell me and I'll add
a cc:stable at k.o tag.

The entire set is also available from
 git pull git://git.linaro.org/people/arnd/arm-soc.git randconfig/omap

but I have not yet pulled them into the for-next branch.

	Arnd

Arnd Bergmann (30):
  sound/omap: omap_mcpdm_remove cannot be __devexit
  video/omap: fix dependencies
  video/omap: fix build dependencies
  ARM: omap: add missing __devexit_p() annotations
  ARM: omap: enable building omap2 without omap2420/2430
  ARM: omap: fix build with CONFIG_I2C_OMAP disabled
  ARM: omap: fix visibility of omap2_mbox_iva_priv
  ARM: omap2+: fix building without i2c
  ARM: omap2: export functions used by nand driver
  ARM: omap/iommu: always provide iommu debug code
  ARM: omap2/n8x0: work around modular omap mmc
  ARM: omap4: always build omap_phy_internal
  ARM: omap2+: fix omap_hdq_init compilation
  ARM: omap2: irq.c is always needed
  usb/musb: use a Kconfig choice to pick the right DMA method
  usb/musb: HDRC depends on TWL4030_CORE for OMAP3/4
  usb/musb: allow building USB_MUSB_TUSB6010 as a module
  omap-usb: automatically select MFD_OMAP_USB_HOST
  tty/serial/omap: console can only be built-in
  media/omap_vout: disable driver for now
  sound/soc/omap: limit to omap2plus
  mfd: build twl6030 only on omap2
  ARM: omap2: select twl4030 support on boards that need it
  ARM: omap2+: ensure that one of omap2/3/4 is selected
  ARM: OMAP depends on MMU
  ARM: omap: add board autoselection
  ARM: omap: select L2X0 cache on omap4
  ARM: omap: select CPU_FREQ_TABLE where needed
  ARM: omap: select USB_ARCH_HAS_EHCI only when USB is enabled
  ARM: omap2: select ARM_AMBA for OMAP3_EMU

 arch/arm/Kconfig                           |    1 +
 arch/arm/mach-omap2/Kconfig                |   61 +++++++++++++++++++++++++-
 arch/arm/mach-omap2/Makefile               |   12 ++---
 arch/arm/mach-omap2/board-n8x0.c           |    7 ++-
 arch/arm/mach-omap2/devices.c              |   10 +++--
 arch/arm/mach-omap2/gpmc.c                 |    2 +
 arch/arm/mach-omap2/mailbox.c              |    2 +-
 arch/arm/mach-omap2/omap_hwmod_2420_data.c |    2 +-
 arch/arm/mach-omap2/omap_hwmod_2430_data.c |    2 +-
 arch/arm/mach-omap2/omap_hwmod_3xxx_data.c |    2 +-
 arch/arm/mach-omap2/omap_hwmod_44xx_data.c |    2 +-
 arch/arm/mach-omap2/smartreflex.c          |    2 +-
 arch/arm/plat-omap/Kconfig                 |    5 ++
 arch/arm/plat-omap/dma.c                   |    2 +-
 arch/arm/plat-omap/include/plat/i2c.h      |    6 +-
 arch/arm/plat-omap/include/plat/multi.h    |    5 ++
 arch/arm/plat-omap/iommu.c                 |    2 +-
 drivers/media/video/omap/Kconfig           |    1 +
 drivers/mfd/Kconfig                        |    6 +-
 drivers/tty/serial/Kconfig                 |    2 +-
 drivers/usb/musb/Kconfig                   |   58 +++++++++++++++----------
 drivers/usb/musb/Makefile                  |   26 ++----------
 drivers/usb/musb/musb_core.c               |    3 +-
 drivers/usb/musb/musb_io.h                 |    2 +-
 drivers/usb/musb/tusb6010.c                |    1 +
 drivers/video/omap/Kconfig                 |   41 ++++++++++++++++--
 drivers/video/omap/Makefile                |   64 +++++++++++++---------------
 drivers/video/omap2/displays/Kconfig       |    7 ++-
 sound/soc/omap/Kconfig                     |    2 +-
 sound/soc/omap/mcpdm.c                     |    2 +-
 sound/soc/omap/mcpdm.h                     |    2 +-
 31 files changed, 221 insertions(+), 121 deletions(-)

-- 
1.7.5.4

[PATCH 01/30] sound/omap: omap_mcpdm_remove cannot be __devexit

[Arnd Bergmann]

omap_mcpdm_remove is used from asoc_mcpdm_probe, which is an
initcall, and must not be discarded when HOTPLUG is disabled.

Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Cc: Jarkko Nikula <jarkko.nikula@bitmer.com>
---
 sound/soc/omap/mcpdm.c |    2 +-
 sound/soc/omap/mcpdm.h |    2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/sound/soc/omap/mcpdm.c b/sound/soc/omap/mcpdm.c
index 928f037..50e59194 100644
--- a/sound/soc/omap/mcpdm.c
+++ b/sound/soc/omap/mcpdm.c
@@ -449,7 +449,7 @@ exit:
 	return ret;
 }
 
-int __devexit omap_mcpdm_remove(struct platform_device *pdev)
+int omap_mcpdm_remove(struct platform_device *pdev)
 {
 	struct omap_mcpdm *mcpdm_ptr = platform_get_drvdata(pdev);
 
diff --git a/sound/soc/omap/mcpdm.h b/sound/soc/omap/mcpdm.h
index df3e16f..20c20a8 100644
--- a/sound/soc/omap/mcpdm.h
+++ b/sound/soc/omap/mcpdm.h
@@ -150,4 +150,4 @@ extern int omap_mcpdm_request(void);
 extern void omap_mcpdm_free(void);
 extern int omap_mcpdm_set_offset(int offset1, int offset2);
 int __devinit omap_mcpdm_probe(struct platform_device *pdev);
-int __devexit omap_mcpdm_remove(struct platform_device *pdev);
+int omap_mcpdm_remove(struct platform_device *pdev);
-- 
1.7.5.4

[PATCH 01/30] sound/omap: omap_mcpdm_remove cannot be __devexit

[Mark Brown]

On Sun, Oct 02, 2011 at 04:45:31PM +0200, Arnd Bergmann wrote:
> omap_mcpdm_remove is used from asoc_mcpdm_probe, which is an
> initcall, and must not be discarded when HOTPLUG is disabled.
> 
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> Cc: Jarkko Nikula <jarkko.nikula@bitmer.com>

I've applied this, thanks.  It'd be helpful if you could say if you're
working on Linus' tree rather than -next, this one doesn't actually
apply against -next as the driver has been totally rewritten.

[PATCH 02/30] video/omap: fix dependencies

[Arnd Bergmann]

The lcd_2430sdp and lcd_ldp drivers depend on TWL4030, which is not
well expressed in the Kconfig. Create new configuration options for
these in order to describe the dependencies correctly.

In some cases, the driver cannot be a loadable module, so better
force it to be built-in.

While we're at it, simplify the Makefile syntax.

Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Cc: Tomi Valkeinen <tomi.valkeinen@ti.com>
---
 drivers/video/omap/Kconfig  |   41 +++++++++++++++++++++++++---
 drivers/video/omap/Makefile |   64 ++++++++++++++++++++-----------------------
 2 files changed, 67 insertions(+), 38 deletions(-)

diff --git a/drivers/video/omap/Kconfig b/drivers/video/omap/Kconfig
index 196fa2e..bd15431 100644
--- a/drivers/video/omap/Kconfig
+++ b/drivers/video/omap/Kconfig
@@ -1,11 +1,11 @@
 config FB_OMAP
-	tristate "OMAP frame buffer support (EXPERIMENTAL)"
-	depends on FB && (OMAP2_DSS = "n")
+	bool "OMAP frame buffer support (EXPERIMENTAL)"
+	# cannot be a module if more than one LCD driver is linked in
+	depends on (FB = "y") && (OMAP2_DSS = "n")
 	depends on ARCH_OMAP1 || ARCH_OMAP2 || ARCH_OMAP3
 	select FB_CFB_FILLRECT
 	select FB_CFB_COPYAREA
 	select FB_CFB_IMAGEBLIT
-	select TWL4030_CORE if MACH_OMAP_2430SDP
 	help
           Frame buffer driver for OMAP based boards.
 
@@ -105,4 +105,37 @@ config FB_OMAP_DMA_TUNE
           answer yes. Answer no if you have a dedicated video
           memory, or don't use any of the accelerated features.
 
-
+config FB_OMAP_SOSSI
+	def_bool y
+	depends on ARCH_OMAP1
+	depends on FB_OMAP_LCDC_EXTERNAL
+
+config FB_OMAP_RFBI
+	def_bool y
+	depends on ARCH_OMAP2 || ARCH_OMAP3
+	depends on FB_OMAP_LCDC_EXTERNAL
+
+config FB_OMAP_INN1610
+	def_bool y
+	depends on ARCH_OMAP16XX
+	depends on MACH_OMAP_INNOVATOR
+
+config FB_OMAP_INN1510
+	def_bool y
+	depends on ARCH_OMAP15XX
+	depends on MACH_OMAP_INNOVATOR
+
+config FB_OMAP_OMAP3EVM
+	def_bool y
+	depends on MACH_OMAP3EVM
+	depends on TWL4030_CORE
+
+config FB_OMAP_X430SDP
+	def_bool y
+	depends on MACH_OMAP_2430SDP || MACH_OMAP_3430SDP
+	depends on TWL4030_CORE
+
+config FB_OMAP_LDP
+	def_bool y
+	depends on MACH_OMAP_LDP
+	depends on TWL4030_CORE
diff --git a/drivers/video/omap/Makefile b/drivers/video/omap/Makefile
index 25db556..8c2cd56 100644
--- a/drivers/video/omap/Makefile
+++ b/drivers/video/omap/Makefile
@@ -4,37 +4,33 @@
 
 obj-$(CONFIG_FB_OMAP) += omapfb.o
 
-objs-yy := omapfb_main.o
-
-objs-y$(CONFIG_ARCH_OMAP1) += lcdc.o
-objs-y$(CONFIG_ARCH_OMAP2) += dispc.o
-objs-y$(CONFIG_ARCH_OMAP3) += dispc.o
-
-objs-$(CONFIG_ARCH_OMAP1)$(CONFIG_FB_OMAP_LCDC_EXTERNAL) += sossi.o
-objs-$(CONFIG_ARCH_OMAP2)$(CONFIG_FB_OMAP_LCDC_EXTERNAL) += rfbi.o
-
-objs-y$(CONFIG_FB_OMAP_LCDC_HWA742) += hwa742.o
-objs-y$(CONFIG_FB_OMAP_LCDC_BLIZZARD) += blizzard.o
-
-objs-y$(CONFIG_MACH_AMS_DELTA) += lcd_ams_delta.o
-objs-y$(CONFIG_MACH_OMAP_H4) += lcd_h4.o
-objs-y$(CONFIG_MACH_OMAP_H3) += lcd_h3.o
-objs-y$(CONFIG_MACH_OMAP_PALMTE) += lcd_palmte.o
-objs-y$(CONFIG_MACH_OMAP_PALMTT) += lcd_palmtt.o
-objs-y$(CONFIG_MACH_OMAP_PALMZ71) += lcd_palmz71.o
-objs-$(CONFIG_ARCH_OMAP16XX)$(CONFIG_MACH_OMAP_INNOVATOR) += lcd_inn1610.o
-objs-$(CONFIG_ARCH_OMAP15XX)$(CONFIG_MACH_OMAP_INNOVATOR) += lcd_inn1510.o
-objs-y$(CONFIG_MACH_OMAP_OSK) += lcd_osk.o
-
-objs-y$(CONFIG_MACH_OMAP_APOLLON) += lcd_apollon.o
-objs-y$(CONFIG_MACH_OMAP_2430SDP) += lcd_2430sdp.o
-objs-y$(CONFIG_MACH_OMAP_3430SDP) += lcd_2430sdp.o
-objs-y$(CONFIG_MACH_OMAP_LDP) += lcd_ldp.o
-objs-y$(CONFIG_MACH_OMAP3EVM) += lcd_omap3evm.o
-objs-y$(CONFIG_MACH_OMAP3_BEAGLE) += lcd_omap3beagle.o
-objs-y$(CONFIG_FB_OMAP_LCD_MIPID) += lcd_mipid.o
-objs-y$(CONFIG_MACH_OVERO) += lcd_overo.o
-objs-y$(CONFIG_MACH_HERALD) += lcd_htcherald.o
-
-omapfb-objs := $(objs-yy)
-
+omapfb-y				+= omapfb_main.o
+
+omapfb-$(CONFIG_ARCH_OMAP1)		+= lcdc.o
+omapfb-$(CONFIG_ARCH_OMAP2)		+= dispc.o
+omapfb-$(CONFIG_ARCH_OMAP3)		+= dispc.o
+
+omapfb-$(CONFIG_FB_OMAP_SOSSI)		+= sossi.o
+omapfb-$(CONFIG_FB_OMAP_RFBI)		+= rfbi.o
+
+omapfb-$(CONFIG_FB_OMAP_LCDC_HWA742)	+= hwa742.o
+omapfb-$(CONFIG_FB_OMAP_LCDC_BLIZZARD)	+= blizzard.o
+
+omapfb-$(CONFIG_MACH_AMS_DELTA)		+= lcd_ams_delta.o
+omapfb-$(CONFIG_MACH_OMAP_H4)		+= lcd_h4.o
+omapfb-$(CONFIG_MACH_OMAP_H3)		+= lcd_h3.o
+omapfb-$(CONFIG_MACH_OMAP_PALMTE)	+= lcd_palmte.o
+omapfb-$(CONFIG_MACH_OMAP_PALMTT)	+= lcd_palmtt.o
+omapfb-$(CONFIG_MACH_OMAP_PALMZ71)	+= lcd_palmz71.o
+omapfb-$(CONFIG_FB_OMAP_INN1610)	+= lcd_inn1610.o
+omapfb-$(CONFIG_FB_OMAP_INN1510)	+= lcd_inn1510.o
+omapfb-$(CONFIG_MACH_OMAP_OSK)		+= lcd_osk.o
+
+omapfb-$(CONFIG_MACH_OMAP_APOLLON)	+= lcd_apollon.o
+omapfb-$(CONFIG_FB_OMAP_X430SDP)	+= lcd_2430sdp.o
+omapfb-$(CONFIG_FB_OMAP_LDP)		+= lcd_ldp.o
+omapfb-$(CONFIG_FB_OMAP_OMAP3EVM)	+= lcd_omap3evm.o
+omapfb-$(CONFIG_MACH_OMAP3_BEAGLE)	+= lcd_omap3beagle.o
+omapfb-$(CONFIG_FB_OMAP_LCD_MIPID)	+= lcd_mipid.o
+omapfb-$(CONFIG_MACH_OVERO)		+= lcd_overo.o
+omapfb-$(CONFIG_MACH_HERALD)		+= lcd_htcherald.o
-- 
1.7.5.4

[PATCH 02/30] video/omap: fix dependencies

[Tomi Valkeinen]

Hi Arnd,

On Sun, 2011-10-02 at 16:45 +0200, Arnd Bergmann wrote:
> The lcd_2430sdp and lcd_ldp drivers depend on TWL4030, which is not
> well expressed in the Kconfig. Create new configuration options for
> these in order to describe the dependencies correctly.
> 
> In some cases, the driver cannot be a loadable module, so better
> force it to be built-in.
> 
> While we're at it, simplify the Makefile syntax.
> 
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> Cc: Tomi Valkeinen <tomi.valkeinen@ti.com>
> ---
>  drivers/video/omap/Kconfig  |   41 +++++++++++++++++++++++++---
>  drivers/video/omap/Makefile |   64 ++++++++++++++++++++-----------------------
>  2 files changed, 67 insertions(+), 38 deletions(-)

I have ported lcd_2430sdp and lcd_ldp drivers (and also other OMAP2/3
panel drivers, except N800) to the newer omapdss driver
(drivers/video/omap2), and the code is in my for-next branch
(git://gitorious.org/linux-omap-dss2/linux.git for-next).

I have also worked on removing OMAP2/3 support from the old omapfb
driver, thus making it OMAP1 fb driver. This code is not yet ready, and
won't make it in the next merge window.

Your patch will conflict with both of those changes. Is it ok for you to
drop this patch, and I'll make a new one on top of my changes to clean
up the Makefile in a similar way than you did? The new patch wouldn't
make it in the next merge window, though, but I don't think this patch
is fixing any bigger bug, so perhaps it's not so urgent.

 Tomi

[PATCH 02/30] video/omap: fix dependencies

[Arnd Bergmann]

On Monday 03 October 2011 09:53:50 Tomi Valkeinen wrote:
> Your patch will conflict with both of those changes. Is it ok for you to
> drop this patch, and I'll make a new one on top of my changes to clean
> up the Makefile in a similar way than you did? The new patch wouldn't
> make it in the next merge window, though, but I don't think this patch
> is fixing any bigger bug, so perhaps it's not so urgent.

Sure, no problem. I'll put it into my "hacks" branch then, so I can
still do randconfig builds and we get back to it later.

	Arnd

[PATCH 03/30] video/omap: fix build dependencies

[Arnd Bergmann]

Four of the LCD panel drivers depend on the backlight class,
so add the dependency in Kconfig.
Selecting the BACKLIGHT_CLASS_DEVICE symbol does not generally
work since it has other dependencies.

Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Cc: Tomi Valkeinen <tomi.valkeinen@ti.com>
---
 drivers/video/omap2/displays/Kconfig |    7 +++++--
 1 files changed, 5 insertions(+), 2 deletions(-)

diff --git a/drivers/video/omap2/displays/Kconfig b/drivers/video/omap2/displays/Kconfig
index 609a280..8e4278c 100644
--- a/drivers/video/omap2/displays/Kconfig
+++ b/drivers/video/omap2/displays/Kconfig
@@ -19,13 +19,15 @@ config PANEL_LGPHILIPS_LB035Q02
 config PANEL_SHARP_LS037V7DW01
         tristate "Sharp LS037V7DW01 LCD Panel"
         depends on OMAP2_DSS_DPI
-        select BACKLIGHT_CLASS_DEVICE
+        depends on BACKLIGHT_CLASS_DEVICE
         help
           LCD Panel used in TI's SDP3430 and EVM boards
 
 config PANEL_NEC_NL8048HL11_01B
 	tristate "NEC NL8048HL11-01B Panel"
 	depends on OMAP2_DSS_DPI
+	depends on SPI
+	depends on BACKLIGHT_CLASS_DEVICE
 	help
 		This NEC NL8048HL11-01B panel is TFT LCD
 		used in the Zoom2/3/3630 sdp boards.
@@ -33,6 +35,7 @@ config PANEL_NEC_NL8048HL11_01B
 config PANEL_TAAL
         tristate "Taal DSI Panel"
         depends on OMAP2_DSS_DSI
+        depends on BACKLIGHT_CLASS_DEVICE
         help
           Taal DSI command mode panel from TPO.
 
@@ -45,7 +48,7 @@ config PANEL_TPO_TD043MTEA1
 config PANEL_ACX565AKM
 	tristate "ACX565AKM Panel"
 	depends on OMAP2_DSS_SDI && SPI
-	select BACKLIGHT_CLASS_DEVICE
+	depends on BACKLIGHT_CLASS_DEVICE
 	help
 	  This is the LCD panel used on Nokia N900
 endmenu
-- 
1.7.5.4

[PATCH 03/30] video/omap: fix build dependencies

[Tomi Valkeinen]

Hi Arnd,

On Sun, 2011-10-02 at 16:45 +0200, Arnd Bergmann wrote:
> Four of the LCD panel drivers depend on the backlight class,
> so add the dependency in Kconfig.
> Selecting the BACKLIGHT_CLASS_DEVICE symbol does not generally
> work since it has other dependencies.
> 
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> Cc: Tomi Valkeinen <tomi.valkeinen@ti.com>

This looks ok to me. If it's fine to you, I'll queue this patch in my
DSS tree to prevent possible conflicts.

 Tomi

[PATCH 03/30] video/omap: fix build dependencies

[Arnd Bergmann]

On Monday 03 October 2011 09:59:35 Tomi Valkeinen wrote:
> On Sun, 2011-10-02 at 16:45 +0200, Arnd Bergmann wrote:
> > Four of the LCD panel drivers depend on the backlight class,
> > so add the dependency in Kconfig.
> > Selecting the BACKLIGHT_CLASS_DEVICE symbol does not generally
> > work since it has other dependencies.
> > 
> > Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> > Cc: Tomi Valkeinen <tomi.valkeinen@ti.com>
> 
> This looks ok to me. If it's fine to you, I'll queue this patch in my
> DSS tree to prevent possible conflicts.

Yes, that's good.

Thanks,

	Arnd

[PATCH 04/30] ARM: omap: add missing __devexit_p() annotations

[Arnd Bergmann]

Drivers that refer to a __devexit function in an operations
structure need to annotate that pointer with __devexit_p so
replace it with a NULL pointer when the section gets discarded.

Signed-off-by: Arnd Bergmann <arnd@arndb.de>
---
 arch/arm/mach-omap2/smartreflex.c |    2 +-
 arch/arm/plat-omap/dma.c          |    2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/arch/arm/mach-omap2/smartreflex.c b/arch/arm/mach-omap2/smartreflex.c
index 34c01a7..67bc6ce 100644
--- a/arch/arm/mach-omap2/smartreflex.c
+++ b/arch/arm/mach-omap2/smartreflex.c
@@ -1002,7 +1002,7 @@ static int __devexit omap_sr_remove(struct platform_device *pdev)
 }
 
 static struct platform_driver smartreflex_driver = {
-	.remove         = omap_sr_remove,
+	.remove         = __devexit_p(omap_sr_remove),
 	.driver		= {
 		.name	= "smartreflex",
 	},
diff --git a/arch/arm/plat-omap/dma.c b/arch/arm/plat-omap/dma.c
index c22217c..f7150ba 100644
--- a/arch/arm/plat-omap/dma.c
+++ b/arch/arm/plat-omap/dma.c
@@ -2105,7 +2105,7 @@ static int __devexit omap_system_dma_remove(struct platform_device *pdev)
 
 static struct platform_driver omap_system_dma_driver = {
 	.probe		= omap_system_dma_probe,
-	.remove		= omap_system_dma_remove,
+	.remove		= __devexit_p(omap_system_dma_remove),
 	.driver		= {
 		.name	= "omap_dma_system"
 	},
-- 
1.7.5.4

[PATCH 04/30] ARM: omap: add missing __devexit_p() annotations

[Bjarne Steinsbo]

Arnd,

Ref http://www.spinics.net/lists/linux-omap/msg57274.html

Don't get me wrong.  This is not about you "stealing" my patch, or
anything like that.  But look also at thread starting at
http://www.spinics.net/lists/linux-omap/msg57667.html Also a patch
that I have posted previously.  Something is not right with the
workflow when bugs are identified, patches are submitted, then
ignored, only for someone else to fix the same bug.  Enough said.

Best regards,

Bjarne Steinsbo

On Sun, Oct 2, 2011 at 4:45 PM, Arnd Bergmann <arnd@arndb.de> wrote:
> Drivers that refer to a __devexit function in an operations
> structure need to annotate that pointer with __devexit_p so
> replace it with a NULL pointer when the section gets discarded.
>
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> ---
> ?arch/arm/mach-omap2/smartreflex.c | ? ?2 +-
> ?arch/arm/plat-omap/dma.c ? ? ? ? ?| ? ?2 +-
> ?2 files changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/arch/arm/mach-omap2/smartreflex.c b/arch/arm/mach-omap2/smartreflex.c
> index 34c01a7..67bc6ce 100644
> --- a/arch/arm/mach-omap2/smartreflex.c
> +++ b/arch/arm/mach-omap2/smartreflex.c
> @@ -1002,7 +1002,7 @@ static int __devexit omap_sr_remove(struct platform_device *pdev)
> ?}
>
> ?static struct platform_driver smartreflex_driver = {
> - ? ? ? .remove ? ? ? ? = omap_sr_remove,
> + ? ? ? .remove ? ? ? ? = __devexit_p(omap_sr_remove),
> ? ? ? ?.driver ? ? ? ? = {
> ? ? ? ? ? ? ? ?.name ? = "smartreflex",
> ? ? ? ?},
> diff --git a/arch/arm/plat-omap/dma.c b/arch/arm/plat-omap/dma.c
> index c22217c..f7150ba 100644
> --- a/arch/arm/plat-omap/dma.c
> +++ b/arch/arm/plat-omap/dma.c
> @@ -2105,7 +2105,7 @@ static int __devexit omap_system_dma_remove(struct platform_device *pdev)
>
> ?static struct platform_driver omap_system_dma_driver = {
> ? ? ? ?.probe ? ? ? ? ?= omap_system_dma_probe,
> - ? ? ? .remove ? ? ? ? = omap_system_dma_remove,
> + ? ? ? .remove ? ? ? ? = __devexit_p(omap_system_dma_remove),
> ? ? ? ?.driver ? ? ? ? = {
> ? ? ? ? ? ? ? ?.name ? = "omap_dma_system"
> ? ? ? ?},
> --
> 1.7.5.4
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-omap" in
> the body of a message to majordomo at vger.kernel.org
> More majordomo info at ?http://vger.kernel.org/majordomo-info.html
>

[PATCH 04/30] ARM: omap: add missing __devexit_p() annotations

[Russell King - ARM Linux]

On Sun, Oct 02, 2011 at 05:56:07PM +0200, Bjarne Steinsbo wrote:
> Arnd,
> 
> Ref http://www.spinics.net/lists/linux-omap/msg57274.html
> 
> Don't get me wrong.  This is not about you "stealing" my patch, or
> anything like that.  But look also at thread starting at
> http://www.spinics.net/lists/linux-omap/msg57667.html Also a patch
> that I have posted previously.  Something is not right with the
> workflow when bugs are identified, patches are submitted, then
> ignored, only for someone else to fix the same bug.  Enough said.

That is where re-sending is important.  Don't throw patches over the wall
and then forget them - that's precisely how this happens.

Consider who has the higher workload, and who ends up dealing with many
many many emails, and realise that the options for those of us who receive
patches are either to drop patches, or have an endlessly growing backlog
of patches when things get busy.

Unless we drop patches, things can get pretty rediculous - consider the
effect of a backlog of one month worth of patches would cause...

[PATCH 04/30] ARM: omap: add missing __devexit_p() annotations

[Tony Lindgren]

* Russell King - ARM Linux <linux@arm.linux.org.uk> [111002 08:35]:
> On Sun, Oct 02, 2011 at 05:56:07PM +0200, Bjarne Steinsbo wrote:
> > Arnd,
> > 
> > Ref http://www.spinics.net/lists/linux-omap/msg57274.html
> > 
> > Don't get me wrong.  This is not about you "stealing" my patch, or
> > anything like that.  But look also at thread starting at
> > http://www.spinics.net/lists/linux-omap/msg57667.html Also a patch
> > that I have posted previously.  Something is not right with the
> > workflow when bugs are identified, patches are submitted, then
> > ignored, only for someone else to fix the same bug.  Enough said.
> 
> That is where re-sending is important.  Don't throw patches over the wall
> and then forget them - that's precisely how this happens.

Bjarne, sorry for accidentally dropping patches, that's not intentional.

Like Russell said, please follow through with your own patches and
repost and complain until the patches do get merged.

> Consider who has the higher workload, and who ends up dealing with many
> many many emails, and realise that the options for those of us who receive
> patches are either to drop patches, or have an endlessly growing backlog
> of patches when things get busy.
> 
> Unless we drop patches, things can get pretty rediculous - consider the
> effect of a backlog of one month worth of patches would cause...

Tools like patchwork.kernel.org help a bit, and especially the email
subject line containing magic the keyword "fix" might help avoiding
the duplicate work.

Regards,

Tony

[PATCH 04/30] ARM: omap: add missing __devexit_p() annotations

[Tony Lindgren]

* Bjarne Steinsbo <bsteinsbo@gmail.com> [111002 08:22]:
> Arnd,
> 
> Ref http://www.spinics.net/lists/linux-omap/msg57274.html
> 
> Don't get me wrong.  This is not about you "stealing" my patch, or
> anything like that.  But look also at thread starting at
> http://www.spinics.net/lists/linux-omap/msg57667.html Also a patch
> that I have posted previously.  Something is not right with the
> workflow when bugs are identified, patches are submitted, then
> ignored, only for someone else to fix the same bug.  Enough said.

Arnd, I suggest using Bjarne's earlier patch here:

Acked-by: Tony Lindgren <tony@atomide.com>
 

> On Sun, Oct 2, 2011 at 4:45 PM, Arnd Bergmann <arnd@arndb.de> wrote:
> > Drivers that refer to a __devexit function in an operations
> > structure need to annotate that pointer with __devexit_p so
> > replace it with a NULL pointer when the section gets discarded.
> >
> > Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> > ---
> > ?arch/arm/mach-omap2/smartreflex.c | ? ?2 +-
> > ?arch/arm/plat-omap/dma.c ? ? ? ? ?| ? ?2 +-
> > ?2 files changed, 2 insertions(+), 2 deletions(-)
> >
> > diff --git a/arch/arm/mach-omap2/smartreflex.c b/arch/arm/mach-omap2/smartreflex.c
> > index 34c01a7..67bc6ce 100644
> > --- a/arch/arm/mach-omap2/smartreflex.c
> > +++ b/arch/arm/mach-omap2/smartreflex.c
> > @@ -1002,7 +1002,7 @@ static int __devexit omap_sr_remove(struct platform_device *pdev)
> > ?}
> >
> > ?static struct platform_driver smartreflex_driver = {
> > - ? ? ? .remove ? ? ? ? = omap_sr_remove,
> > + ? ? ? .remove ? ? ? ? = __devexit_p(omap_sr_remove),
> > ? ? ? ?.driver ? ? ? ? = {
> > ? ? ? ? ? ? ? ?.name ? = "smartreflex",
> > ? ? ? ?},
> > diff --git a/arch/arm/plat-omap/dma.c b/arch/arm/plat-omap/dma.c
> > index c22217c..f7150ba 100644
> > --- a/arch/arm/plat-omap/dma.c
> > +++ b/arch/arm/plat-omap/dma.c
> > @@ -2105,7 +2105,7 @@ static int __devexit omap_system_dma_remove(struct platform_device *pdev)
> >
> > ?static struct platform_driver omap_system_dma_driver = {
> > ? ? ? ?.probe ? ? ? ? ?= omap_system_dma_probe,
> > - ? ? ? .remove ? ? ? ? = omap_system_dma_remove,
> > + ? ? ? .remove ? ? ? ? = __devexit_p(omap_system_dma_remove),
> > ? ? ? ?.driver ? ? ? ? = {
> > ? ? ? ? ? ? ? ?.name ? = "omap_dma_system"
> > ? ? ? ?},
> > --
> > 1.7.5.4
> >
> > --
> > To unsubscribe from this list: send the line "unsubscribe linux-omap" in
> > the body of a message to majordomo at vger.kernel.org
> > More majordomo info at ?http://vger.kernel.org/majordomo-info.html
> >
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo at vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 04/30] ARM: omap: add missing __devexit_p() annotations

[Santosh Shilimkar]

On Sunday 02 October 2011 08:15 PM, Arnd Bergmann wrote:
> Drivers that refer to a __devexit function in an operations
> structure need to annotate that pointer with __devexit_p so
> replace it with a NULL pointer when the section gets discarded.
> 
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> ---
Acked-by: Santosh Shilimkar <santosh.shilimkar@ti.com>

[PATCH 05/30] ARM: omap: enable building omap2 without omap2420/2430

[Arnd Bergmann]

Kconfig allows selecting CONFIG_OMAP2 but no specific SOC, the options
being omap2420 and omap2430, but that leads to a build error when
omap3 or omap4 are also enabled and the MULTI_OMAP2 symbol is
undefined.

This adds another clause to plat/multi.h, mainly to allow all
possible randconfig combinations to build cleanly.

Signed-off-by: Arnd Bergmann <arnd@arndb.de>
---
 arch/arm/plat-omap/include/plat/multi.h |    5 +++++
 1 files changed, 5 insertions(+), 0 deletions(-)

diff --git a/arch/arm/plat-omap/include/plat/multi.h b/arch/arm/plat-omap/include/plat/multi.h
index 999ffba..fb7f196 100644
--- a/arch/arm/plat-omap/include/plat/multi.h
+++ b/arch/arm/plat-omap/include/plat/multi.h
@@ -82,6 +82,11 @@
 #  define OMAP_NAME omap2430
 # endif
 #endif
+#ifdef CONFIG_ARCH_OMAP2
+# ifndef OMAP_NAME
+#  define OMAP_NAME omap2
+# endif
+#endif
 #ifdef CONFIG_ARCH_OMAP3
 # ifdef OMAP_NAME
 #  undef  MULTI_OMAP2
-- 
1.7.5.4

[PATCH 05/30] ARM: omap: enable building omap2 without omap2420/2430

[Santosh Shilimkar]

On Sunday 02 October 2011 08:15 PM, Arnd Bergmann wrote:
> Kconfig allows selecting CONFIG_OMAP2 but no specific SOC, the options
> being omap2420 and omap2430, but that leads to a build error when
> omap3 or omap4 are also enabled and the MULTI_OMAP2 symbol is
> undefined.
> 
> This adds another clause to plat/multi.h, mainly to allow all
> possible randconfig combinations to build cleanly.
> 
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>

Acked-by: Santosh Shilimkar <santosh.shilimkar@ti.com>

[PATCH 05/30] ARM: omap: enable building omap2 without omap2420/2430

[Tony Lindgren]

* Arnd Bergmann <arnd@arndb.de> [111002 07:13]:
> Kconfig allows selecting CONFIG_OMAP2 but no specific SOC, the options
> being omap2420 and omap2430, but that leads to a build error when
> omap3 or omap4 are also enabled and the MULTI_OMAP2 symbol is
> undefined.
> 
> This adds another clause to plat/multi.h, mainly to allow all
> possible randconfig combinations to build cleanly.
> 
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>

Acked-by: Tony Lindgren <tony@atomide.com>

> ---
>  arch/arm/plat-omap/include/plat/multi.h |    5 +++++
>  1 files changed, 5 insertions(+), 0 deletions(-)
> 
> diff --git a/arch/arm/plat-omap/include/plat/multi.h b/arch/arm/plat-omap/include/plat/multi.h
> index 999ffba..fb7f196 100644
> --- a/arch/arm/plat-omap/include/plat/multi.h
> +++ b/arch/arm/plat-omap/include/plat/multi.h
> @@ -82,6 +82,11 @@
>  #  define OMAP_NAME omap2430
>  # endif
>  #endif
> +#ifdef CONFIG_ARCH_OMAP2
> +# ifndef OMAP_NAME
> +#  define OMAP_NAME omap2
> +# endif
> +#endif
>  #ifdef CONFIG_ARCH_OMAP3
>  # ifdef OMAP_NAME
>  #  undef  MULTI_OMAP2
> -- 
> 1.7.5.4
> 

[PATCH 06/30] ARM: omap: fix build with CONFIG_I2C_OMAP disabled

[Arnd Bergmann]

We must not reference omap_i2c_reset if the file defining it
does not get built.

Signed-off-by: Arnd Bergmann <arnd@arndb.de>
---
 arch/arm/plat-omap/include/plat/i2c.h |    6 +++---
 1 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/arch/arm/plat-omap/include/plat/i2c.h b/arch/arm/plat-omap/include/plat/i2c.h
index 7c22b9e..ae72013 100644
--- a/arch/arm/plat-omap/include/plat/i2c.h
+++ b/arch/arm/plat-omap/include/plat/i2c.h
@@ -28,6 +28,8 @@
 extern int omap_register_i2c_bus(int bus_id, u32 clkrate,
 				 struct i2c_board_info const *info,
 				 unsigned len);
+struct omap_hwmod;
+int omap_i2c_reset(struct omap_hwmod *oh);
 #else
 static inline int omap_register_i2c_bus(int bus_id, u32 clkrate,
 				 struct i2c_board_info const *info,
@@ -35,6 +37,7 @@ static inline int omap_register_i2c_bus(int bus_id, u32 clkrate,
 {
 	return 0;
 }
+#define omap_i2c_reset NULL
 #endif
 
 /**
@@ -53,7 +56,4 @@ struct omap_i2c_dev_attr {
 void __init omap1_i2c_mux_pins(int bus_id);
 void __init omap2_i2c_mux_pins(int bus_id);
 
-struct omap_hwmod;
-int omap_i2c_reset(struct omap_hwmod *oh);
-
 #endif /* __ASM__ARCH_OMAP_I2C_H */
-- 
1.7.5.4

[PATCH 06/30] ARM: omap: fix build with CONFIG_I2C_OMAP disabled

[Santosh Shilimkar]

On Sunday 02 October 2011 08:15 PM, Arnd Bergmann wrote:
> We must not reference omap_i2c_reset if the file defining it
> does not get built.
> 
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> ---
Acked-by: Santosh Shilimkar <santosh.shilimkar@ti.com>

[PATCH 07/30] ARM: omap: fix visibility of omap2_mbox_iva_priv

[Arnd Bergmann]

map2_mbox_iva_priv is used on multiple omap2 socs but is hidden
in an outdated #ifdef that is specific to a single soc.

Signed-off-by: Arnd Bergmann <arnd@arndb.de>
---
 arch/arm/mach-omap2/mailbox.c |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/arch/arm/mach-omap2/mailbox.c b/arch/arm/mach-omap2/mailbox.c
index 86d564a..5a2a0e4 100644
--- a/arch/arm/mach-omap2/mailbox.c
+++ b/arch/arm/mach-omap2/mailbox.c
@@ -257,7 +257,7 @@ struct omap_mbox mbox_dsp_info = {
 struct omap_mbox *omap3_mboxes[] = { &mbox_dsp_info, NULL };
 #endif
 
-#if defined(CONFIG_SOC_OMAP2420)
+#if defined(CONFIG_ARCH_OMAP2)
 /* IVA */
 static struct omap_mbox2_priv omap2_mbox_iva_priv = {
 	.tx_fifo = {
-- 
1.7.5.4

[PATCH 07/30] ARM: omap: fix visibility of omap2_mbox_iva_priv

[Santosh Shilimkar]

On Sunday 02 October 2011 08:15 PM, Arnd Bergmann wrote:
> map2_mbox_iva_priv is used on multiple omap2 socs but is hidden
> in an outdated #ifdef that is specific to a single soc.
> 
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> ---
Acked-by: Santosh Shilimkar <santosh.shilimkar@ti.com>

[PATCH 08/30] ARM: omap2+: fix building without i2c

[Arnd Bergmann]

A trivial typo causes build breakage when I2C is disabled
and omap_i2c_reset is set to NULL on OMAP:

omap_hwmod_44xx_data.c:2287:11: error: lvalue required as unary '&' operand

Removing the '&' character solves this.

Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Cc: Avinash.H.M <avinashhm@ti.com>
Cc: Paul Walmsley <paul@pwsan.com>
---
 arch/arm/mach-omap2/omap_hwmod_2420_data.c |    2 +-
 arch/arm/mach-omap2/omap_hwmod_2430_data.c |    2 +-
 arch/arm/mach-omap2/omap_hwmod_3xxx_data.c |    2 +-
 arch/arm/mach-omap2/omap_hwmod_44xx_data.c |    2 +-
 4 files changed, 4 insertions(+), 4 deletions(-)

diff --git a/arch/arm/mach-omap2/omap_hwmod_2420_data.c b/arch/arm/mach-omap2/omap_hwmod_2420_data.c
index a015c69..3aa6c62 100644
--- a/arch/arm/mach-omap2/omap_hwmod_2420_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_2420_data.c
@@ -1030,7 +1030,7 @@ static struct omap_hwmod_class i2c_class = {
 	.name		= "i2c",
 	.sysc		= &i2c_sysc,
 	.rev		= OMAP_I2C_IP_VERSION_1,
-	.reset		= &omap_i2c_reset,
+	.reset		= omap_i2c_reset,
 };
 
 static struct omap_i2c_dev_attr i2c_dev_attr = {
diff --git a/arch/arm/mach-omap2/omap_hwmod_2430_data.c b/arch/arm/mach-omap2/omap_hwmod_2430_data.c
index 16743c7..d9ab245 100644
--- a/arch/arm/mach-omap2/omap_hwmod_2430_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_2430_data.c
@@ -1079,7 +1079,7 @@ static struct omap_hwmod_class i2c_class = {
 	.name		= "i2c",
 	.sysc		= &i2c_sysc,
 	.rev		= OMAP_I2C_IP_VERSION_1,
-	.reset		= &omap_i2c_reset,
+	.reset		= omap_i2c_reset,
 };
 
 static struct omap_i2c_dev_attr i2c_dev_attr = {
diff --git a/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c b/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
index 25bf43b..b0a0113 100644
--- a/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
@@ -1309,7 +1309,7 @@ static struct omap_hwmod_class i2c_class = {
 	.name	= "i2c",
 	.sysc	= &i2c_sysc,
 	.rev	= OMAP_I2C_IP_VERSION_1,
-	.reset	= &omap_i2c_reset,
+	.reset	= omap_i2c_reset,
 };
 
 static struct omap_hwmod_dma_info omap3xxx_dss_sdma_chs[] = {
diff --git a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
index 6201422..a6d42fc 100644
--- a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
@@ -2284,7 +2284,7 @@ static struct omap_hwmod_class omap44xx_i2c_hwmod_class = {
 	.name	= "i2c",
 	.sysc	= &omap44xx_i2c_sysc,
 	.rev	= OMAP_I2C_IP_VERSION_2,
-	.reset	= &omap_i2c_reset,
+	.reset	= omap_i2c_reset,
 };
 
 static struct omap_i2c_dev_attr i2c_dev_attr = {
-- 
1.7.5.4

[PATCH 08/30] ARM: omap2+: fix building without i2c

[Paul Walmsley]

Hello Arnd,

On Sun, 2 Oct 2011, Arnd Bergmann wrote:

> A trivial typo causes build breakage when I2C is disabled
> and omap_i2c_reset is set to NULL on OMAP:
> 
> omap_hwmod_44xx_data.c:2287:11: error: lvalue required as unary '&' operand
> 
> Removing the '&' character solves this.
> 
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> Cc: Avinash.H.M <avinashhm@ti.com>
> Cc: Paul Walmsley <paul@pwsan.com>

Nice catch.  I think the bug is different, though.  omap_i2c_reset should 
never be NULL: that code is intended to execute even when 
CONFIG_I2C_OMAP=n.  The idea is to prevent the IP block from interfering 
with the rest of the kernel even if the driver is not compiled in, no 
matter how the bootloader or previous OS programmed the IP block.

I'd suggest something like the following patch instead.


- Paul

From: Paul Walmsley <paul@pwsan.com>
Date: Sun, 2 Oct 2011 19:15:10 -0600
Subject: [PATCH] ARM: omap2+: fix build breakage when CONFIG_I2C_OMAP=n

arch/arm/mach-omap2/Makefile incorrectly skips compilation of the I2C
IP block reset code when CONFIG_I2C_OMAP=n.  Fix by unconditionally
compiling arch/arm/mach-omap2/i2c.o, which is needed on all OMAP2+ platforms.

Problem noted by Arnd Bergmann <arnd@arndb.de>.

Signed-off-by: Paul Walmsley <paul@pwsan.com>
Cc: Avinash.H.M <avinashhm@ti.com>
Cc: Arnd Bergmann <arnd@arndb.de>
Cc: Tony Lindgren <tony@atomide.com>
---
 arch/arm/mach-omap2/Makefile |    5 +----
 1 files changed, 1 insertions(+), 4 deletions(-)

diff --git a/arch/arm/mach-omap2/Makefile b/arch/arm/mach-omap2/Makefile
index f343365..0951986 100644
--- a/arch/arm/mach-omap2/Makefile
+++ b/arch/arm/mach-omap2/Makefile
@@ -4,7 +4,7 @@
 
 # Common support
 obj-y := id.o io.o control.o mux.o devices.o serial.o gpmc.o timer.o pm.o \
-	 common.o gpio.o dma.o wd_timer.o
+	 common.o gpio.o dma.o wd_timer.o i2c.o
 
 omap-2-3-common				= irq.o sdrc.o
 hwmod-common				= omap_hwmod.o \
@@ -175,9 +175,6 @@ obj-$(CONFIG_OMAP_IOMMU)		+= iommu2.o
 iommu-$(CONFIG_OMAP_IOMMU)		:= omap-iommu.o
 obj-y					+= $(iommu-m) $(iommu-y)
 
-i2c-omap-$(CONFIG_I2C_OMAP)		:= i2c.o
-obj-y					+= $(i2c-omap-m) $(i2c-omap-y)
-
 ifneq ($(CONFIG_TIDSPBRIDGE),)
 obj-y					+= dsp.o
 endif
-- 
1.7.6.3

[PATCH 08/30] ARM: omap2+: fix building without i2c

[Arnd Bergmann]

On Sunday 02 October 2011 19:31:25 Paul Walmsley wrote:

> Nice catch.  I think the bug is different, though.  omap_i2c_reset should 
> never be NULL: that code is intended to execute even when 
> CONFIG_I2C_OMAP=n.  The idea is to prevent the IP block from interfering 
> with the rest of the kernel even if the driver is not compiled in, no 
> matter how the bootloader or previous OS programmed the IP block.
> 
> I'd suggest something like the following patch instead.
> 
> 
> - Paul
> 
> From: Paul Walmsley <paul@pwsan.com>
> Date: Sun, 2 Oct 2011 19:15:10 -0600
> Subject: [PATCH] ARM: omap2+: fix build breakage when CONFIG_I2C_OMAP=n
> 
> arch/arm/mach-omap2/Makefile incorrectly skips compilation of the I2C
> IP block reset code when CONFIG_I2C_OMAP=n.  Fix by unconditionally
> compiling arch/arm/mach-omap2/i2c.o, which is needed on all OMAP2+ platforms.
> 
> Problem noted by Arnd Bergmann <arnd@arndb.de>.

Ok, looks better. You should also drop patch 6 "ARM: omap: fix build with
CONFIG_I2C_OMAP disabled" then.

Acked-by: Arnd Bergmann <arnd@arndb.de>

[PATCH 08/30] ARM: omap2+: fix building without i2c

[Tony Lindgren]

* Arnd Bergmann <arnd@arndb.de> [111003 02:15]:
> On Sunday 02 October 2011 19:31:25 Paul Walmsley wrote:
> 
> > Nice catch.  I think the bug is different, though.  omap_i2c_reset should 
> > never be NULL: that code is intended to execute even when 
> > CONFIG_I2C_OMAP=n.  The idea is to prevent the IP block from interfering 
> > with the rest of the kernel even if the driver is not compiled in, no 
> > matter how the bootloader or previous OS programmed the IP block.
> > 
> > I'd suggest something like the following patch instead.
> > 
> > 
> > - Paul
> > 
> > From: Paul Walmsley <paul@pwsan.com>
> > Date: Sun, 2 Oct 2011 19:15:10 -0600
> > Subject: [PATCH] ARM: omap2+: fix build breakage when CONFIG_I2C_OMAP=n
> > 
> > arch/arm/mach-omap2/Makefile incorrectly skips compilation of the I2C
> > IP block reset code when CONFIG_I2C_OMAP=n.  Fix by unconditionally
> > compiling arch/arm/mach-omap2/i2c.o, which is needed on all OMAP2+ platforms.
> > 
> > Problem noted by Arnd Bergmann <arnd@arndb.de>.
> 
> Ok, looks better. You should also drop patch 6 "ARM: omap: fix build with
> CONFIG_I2C_OMAP disabled" then.
> 
> Acked-by: Arnd Bergmann <arnd@arndb.de>

Arnd I suggest you replace your patch with this in your branch.

Acked-by: Tony Lindgren <tony@atomide.com> 

[PATCH 09/30] ARM: omap2: export functions used by nand driver

[Arnd Bergmann]

The omap nand driver uses the gpmc_enable_hwecc and
gpmc_calculate_ecc functions from the platform code,
but can be built as a module.

This only works if the functions are exported.

Signed-off-by: Arnd Bergmann <arnd@arndb.de>
---
 arch/arm/mach-omap2/gpmc.c |    2 ++
 1 files changed, 2 insertions(+), 0 deletions(-)

diff --git a/arch/arm/mach-omap2/gpmc.c b/arch/arm/mach-omap2/gpmc.c
index 130034b..4ed6880 100644
--- a/arch/arm/mach-omap2/gpmc.c
+++ b/arch/arm/mach-omap2/gpmc.c
@@ -882,6 +882,7 @@ int gpmc_enable_hwecc(int cs, int mode, int dev_width, int ecc_size)
 	gpmc_write_reg(GPMC_ECC_CONFIG, val);
 	return 0;
 }
+EXPORT_SYMBOL_GPL(gpmc_enable_hwecc);
 
 /**
  * gpmc_calculate_ecc - generate non-inverted ecc bytes
@@ -912,3 +913,4 @@ int gpmc_calculate_ecc(int cs, const u_char *dat, u_char *ecc_code)
 	gpmc_ecc_used = -EINVAL;
 	return 0;
 }
+EXPORT_SYMBOL_GPL(gpmc_calculate_ecc);
-- 
1.7.5.4

[PATCH 09/30] ARM: omap2: export functions used by nand driver

[Tony Lindgren]

* Arnd Bergmann <arnd@arndb.de> [111002 07:13]:
> The omap nand driver uses the gpmc_enable_hwecc and
> gpmc_calculate_ecc functions from the platform code,
> but can be built as a module.
> 
> This only works if the functions are exported.
> 
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>

Acked-by: Tony Lindgren <tony@atomide.com>

> ---
>  arch/arm/mach-omap2/gpmc.c |    2 ++
>  1 files changed, 2 insertions(+), 0 deletions(-)
> 
> diff --git a/arch/arm/mach-omap2/gpmc.c b/arch/arm/mach-omap2/gpmc.c
> index 130034b..4ed6880 100644
> --- a/arch/arm/mach-omap2/gpmc.c
> +++ b/arch/arm/mach-omap2/gpmc.c
> @@ -882,6 +882,7 @@ int gpmc_enable_hwecc(int cs, int mode, int dev_width, int ecc_size)
>  	gpmc_write_reg(GPMC_ECC_CONFIG, val);
>  	return 0;
>  }
> +EXPORT_SYMBOL_GPL(gpmc_enable_hwecc);
>  
>  /**
>   * gpmc_calculate_ecc - generate non-inverted ecc bytes
> @@ -912,3 +913,4 @@ int gpmc_calculate_ecc(int cs, const u_char *dat, u_char *ecc_code)
>  	gpmc_ecc_used = -EINVAL;
>  	return 0;
>  }
> +EXPORT_SYMBOL_GPL(gpmc_calculate_ecc);
> -- 
> 1.7.5.4
> 

[PATCH 10/30] ARM: omap/iommu: always provide iommu debug code

[Arnd Bergmann]

The iommu module on omap contains a few functions that are
only used by the debug module. These are however only there
when the debug code is built as a module. Since it is possible
to build the debug code into the kernel, the functions should
also be provided for the built-in case.

Signed-off-by: Arnd Bergmann <arnd@arndb.de>
---
 arch/arm/plat-omap/iommu.c |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/arch/arm/plat-omap/iommu.c b/arch/arm/plat-omap/iommu.c
index 34fc31e..9d43ce1 100644
--- a/arch/arm/plat-omap/iommu.c
+++ b/arch/arm/plat-omap/iommu.c
@@ -391,7 +391,7 @@ void iommu_set_twl(struct iommu *obj, bool on)
 }
 EXPORT_SYMBOL_GPL(iommu_set_twl);
 
-#if defined(CONFIG_OMAP_IOMMU_DEBUG_MODULE)
+#if defined(CONFIG_OMAP_IOMMU_DEBUG) || defined(CONFIG_OMAP_IOMMU_DEBUG_MODULE)
 
 ssize_t iommu_dump_ctx(struct iommu *obj, char *buf, ssize_t bytes)
 {
-- 
1.7.5.4

[PATCH 10/30] ARM: omap/iommu: always provide iommu debug code

[Ohad Ben-Cohen]

On Sun, Oct 2, 2011 at 4:45 PM, Arnd Bergmann <arnd@arndb.de> wrote:
> The iommu module on omap contains a few functions that are
> only used by the debug module. These are however only there
> when the debug code is built as a module. Since it is possible
> to build the debug code into the kernel, the functions should
> also be provided for the built-in case.
>
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> ---
> ?arch/arm/plat-omap/iommu.c | ? ?2 +-

Thanks, Arnd.

The driver has moved to drivers/iommu/ and changed a bit, but this
patch is still relevant.

The merge conflict will be trivial to resolve, but if you prefer, we
can prevent it by taking this patch via the iommu tree.

Thanks,
Ohad.

[PATCH 10/30] ARM: omap/iommu: always provide iommu debug code

[Arnd Bergmann]

On Sunday 02 October 2011 18:34:52 Ohad Ben-Cohen wrote:
> 
> The driver has moved to drivers/iommu/ and changed a bit, but this
> patch is still relevant.
> 
> The merge conflict will be trivial to resolve, but if you prefer, we
> can prevent it by taking this patch via the iommu tree.

Yes, please take it into the iommu tree, so I don't have to track
the conflict.

Thanks,

	Arnd

[PATCH 10/30] ARM: omap/iommu: always provide iommu debug code

[Ohad Ben-Cohen]

On Sun, Oct 2, 2011 at 8:01 PM, Arnd Bergmann <arnd@arndb.de> wrote:
> Yes, please take it into the iommu tree, so I don't have to track
> the conflict.

Sure thing.

Thanks,
Ohad.

[PATCH 10/30] ARM: omap/iommu: always provide iommu debug code

[Tony Lindgren]

* Arnd Bergmann <arnd@arndb.de> [111002 07:13]:
> The iommu module on omap contains a few functions that are
> only used by the debug module. These are however only there
> when the debug code is built as a module. Since it is possible
> to build the debug code into the kernel, the functions should
> also be provided for the built-in case.
> 
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>

Acked-by: Tony Lindgren <tony@atomide.com>

> ---
>  arch/arm/plat-omap/iommu.c |    2 +-
>  1 files changed, 1 insertions(+), 1 deletions(-)
> 
> diff --git a/arch/arm/plat-omap/iommu.c b/arch/arm/plat-omap/iommu.c
> index 34fc31e..9d43ce1 100644
> --- a/arch/arm/plat-omap/iommu.c
> +++ b/arch/arm/plat-omap/iommu.c
> @@ -391,7 +391,7 @@ void iommu_set_twl(struct iommu *obj, bool on)
>  }
>  EXPORT_SYMBOL_GPL(iommu_set_twl);
>  
> -#if defined(CONFIG_OMAP_IOMMU_DEBUG_MODULE)
> +#if defined(CONFIG_OMAP_IOMMU_DEBUG) || defined(CONFIG_OMAP_IOMMU_DEBUG_MODULE)
>  
>  ssize_t iommu_dump_ctx(struct iommu *obj, char *buf, ssize_t bytes)
>  {
> -- 
> 1.7.5.4
> 

[PATCH 11/30] ARM: omap2/n8x0: work around modular omap mmc

[Arnd Bergmann]

When the omap driver is built as a module for n8x0,
n8x0_mmc_set_power_menelaus cannot call into the driver:

arch/arm/mach-omap2/board-n8x0.c:374: undefined reference to `omap_mmc_notify_cover_event'

As a workaround, do not provide that device in this case. This needs
to be fixed properly, e.g. by converting n8x0 to be probed through the
device tree and moving that code into the driver.

Signed-off-by: Arnd Bergmann <arnd@arndb.de>
---
 arch/arm/mach-omap2/board-n8x0.c |    5 +++--
 1 files changed, 3 insertions(+), 2 deletions(-)

diff --git a/arch/arm/mach-omap2/board-n8x0.c b/arch/arm/mach-omap2/board-n8x0.c
index e11f0c5..403325d 100644
--- a/arch/arm/mach-omap2/board-n8x0.c
+++ b/arch/arm/mach-omap2/board-n8x0.c
@@ -193,8 +193,9 @@ static struct omap_onenand_platform_data board_onenand_data[] = {
 };
 #endif
 
-#if defined(CONFIG_MENELAUS) &&						\
-	(defined(CONFIG_MMC_OMAP) || defined(CONFIG_MMC_OMAP_MODULE))
+#if defined(CONFIG_MENELAUS) && defined(CONFIG_MMC_OMAP)
+/* || defined(CONFIG_MMC_OMAP_MODULE)) */
+/* FIXME: cannot call omap_mmc_notify_cover_event for ONFIG_MMC_OMAP_MODULE */
 
 /*
  * On both N800 and N810, only the first of the two MMC controllers is in use.
-- 
1.7.5.4

[PATCH 11/30] ARM: omap2/n8x0: work around modular omap mmc

[Russell King - ARM Linux]

On Sun, Oct 02, 2011 at 04:45:41PM +0200, Arnd Bergmann wrote:
> -#if defined(CONFIG_MENELAUS) &&						\
> -	(defined(CONFIG_MMC_OMAP) || defined(CONFIG_MMC_OMAP_MODULE))
> +#if defined(CONFIG_MENELAUS) && defined(CONFIG_MMC_OMAP)
> +/* || defined(CONFIG_MMC_OMAP_MODULE)) */
> +/* FIXME: cannot call omap_mmc_notify_cover_event for ONFIG_MMC_OMAP_MODULE */

#ifdef CONFIG_MMC_OMAP_MODULE
#warning FIXME: cannot call omap_mmc_notify_cover_event for CONFIG_MMC_OMAP_MODULE
#endif
#if defined(CONFIG_MENELAUS) && defined(CONFIG_MMC_OMAP)

So that it can be seen at build time?

Also note the 'ONFIG' typo...

[PATCH 11/30] ARM: omap2/n8x0: work around modular omap mmc

[Arnd Bergmann]

On Sunday 02 October 2011 16:53:31 Russell King - ARM Linux wrote:
> On Sun, Oct 02, 2011 at 04:45:41PM +0200, Arnd Bergmann wrote:
> > -#if defined(CONFIG_MENELAUS) &&                                              \
> > -     (defined(CONFIG_MMC_OMAP) || defined(CONFIG_MMC_OMAP_MODULE))
> > +#if defined(CONFIG_MENELAUS) && defined(CONFIG_MMC_OMAP)
> > +/* || defined(CONFIG_MMC_OMAP_MODULE)) */
> > +/* FIXME: cannot call omap_mmc_notify_cover_event for ONFIG_MMC_OMAP_MODULE */
> 
> #ifdef CONFIG_MMC_OMAP_MODULE
> #warning FIXME: cannot call omap_mmc_notify_cover_event for CONFIG_MMC_OMAP_MODULE
> #endif
> #if defined(CONFIG_MENELAUS) && defined(CONFIG_MMC_OMAP)
> 
> So that it can be seen at build time?
> 
> Also note the 'ONFIG' typo...

Ok, good idea. I've updated the patch in the git tree accordingly.

Depending on what Tony wants, I might send out the entire series
again once there are no more new comments.

	Arnd

[PATCH 11/30] ARM: omap2/n8x0: work around modular omap mmc

[Tony Lindgren]

* Arnd Bergmann <arnd@arndb.de> [111002 11:22]:
> On Sunday 02 October 2011 16:53:31 Russell King - ARM Linux wrote:
> > On Sun, Oct 02, 2011 at 04:45:41PM +0200, Arnd Bergmann wrote:
> > > -#if defined(CONFIG_MENELAUS) &&                                              \
> > > -     (defined(CONFIG_MMC_OMAP) || defined(CONFIG_MMC_OMAP_MODULE))
> > > +#if defined(CONFIG_MENELAUS) && defined(CONFIG_MMC_OMAP)
> > > +/* || defined(CONFIG_MMC_OMAP_MODULE)) */
> > > +/* FIXME: cannot call omap_mmc_notify_cover_event for ONFIG_MMC_OMAP_MODULE */
> > 
> > #ifdef CONFIG_MMC_OMAP_MODULE
> > #warning FIXME: cannot call omap_mmc_notify_cover_event for CONFIG_MMC_OMAP_MODULE
> > #endif
> > #if defined(CONFIG_MENELAUS) && defined(CONFIG_MMC_OMAP)
> > 
> > So that it can be seen at build time?
> > 
> > Also note the 'ONFIG' typo...
> 
> Ok, good idea. I've updated the patch in the git tree accordingly.

Acked-by: Tony Lindgren <tony@atomide.com>
 
> Depending on what Tony wants, I might send out the entire series
> again once there are no more new comments.

Up to you, I usually prefer to see just updated patches as long
as the mail thread stays readable.

Regards,

Tony

[PATCH 12/30] ARM: omap4: always build omap_phy_internal

[Arnd Bergmann]

The functions defined in omap_phy_internal.c are requrired on
omap4-only configurations, not just for specific boards.

twl-common.c:(.init.text+0x6b40): undefined reference to `omap4430_phy_init'
twl-common.c:(.init.text+0x6c68): undefined reference to `omap4430_phy_init'
mach-omap2/built-in.o:(.data+0x154e0): undefined reference to `omap4430_phy_init'
mach-omap2/built-in.o:(.data+0x154e4): undefined reference to `omap4430_phy_exit'

Signed-off-by: Arnd Bergmann <arnd@arndb.de>
---
 arch/arm/mach-omap2/Makefile |    8 +++-----
 1 files changed, 3 insertions(+), 5 deletions(-)

diff --git a/arch/arm/mach-omap2/Makefile b/arch/arm/mach-omap2/Makefile
index f343365..dc36bd4 100644
--- a/arch/arm/mach-omap2/Makefile
+++ b/arch/arm/mach-omap2/Makefile
@@ -242,12 +242,9 @@ obj-$(CONFIG_MACH_IGEP0020)		+= board-igep0020.o \
 obj-$(CONFIG_MACH_OMAP3_TOUCHBOOK)	+= board-omap3touchbook.o \
 					   hsmmc.o
 obj-$(CONFIG_MACH_OMAP_4430SDP)		+= board-4430sdp.o \
-					   hsmmc.o \
-					   omap_phy_internal.o
+					   hsmmc.o
 obj-$(CONFIG_MACH_OMAP4_PANDA)		+= board-omap4panda.o \
-					   hsmmc.o \
-					   omap_phy_internal.o
-
+					   hsmmc.o
 obj-$(CONFIG_MACH_OMAP3517EVM)		+= board-am3517evm.o \
 					   omap_phy_internal.o \
 
@@ -275,6 +272,7 @@ obj-y					+= $(smc91x-m) $(smc91x-y)
 smsc911x-$(CONFIG_SMSC911X)		:= gpmc-smsc911x.o
 obj-y					+= $(smsc911x-m) $(smsc911x-y)
 obj-$(CONFIG_ARCH_OMAP4)		+= hwspinlock.o
+obj-$(CONFIG_ARCH_OMAP4)		+= omap_phy_internal.o
 
 disp-$(CONFIG_OMAP2_DSS)		:= display.o
 obj-y					+= $(disp-m) $(disp-y)
-- 
1.7.5.4

[PATCH 12/30] ARM: omap4: always build omap_phy_internal

[Tony Lindgren]

* Arnd Bergmann <arnd@arndb.de> [111002 07:13]:
> The functions defined in omap_phy_internal.c are requrired on
> omap4-only configurations, not just for specific boards.
> 
> twl-common.c:(.init.text+0x6b40): undefined reference to `omap4430_phy_init'
> twl-common.c:(.init.text+0x6c68): undefined reference to `omap4430_phy_init'
> mach-omap2/built-in.o:(.data+0x154e0): undefined reference to `omap4430_phy_init'
> mach-omap2/built-in.o:(.data+0x154e4): undefined reference to `omap4430_phy_exit'
> 
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>

This should be OK for now:

Acked-by: Tony Lindgren <tony@atomide.com>

> ---
>  arch/arm/mach-omap2/Makefile |    8 +++-----
>  1 files changed, 3 insertions(+), 5 deletions(-)
> 
> diff --git a/arch/arm/mach-omap2/Makefile b/arch/arm/mach-omap2/Makefile
> index f343365..dc36bd4 100644
> --- a/arch/arm/mach-omap2/Makefile
> +++ b/arch/arm/mach-omap2/Makefile
> @@ -242,12 +242,9 @@ obj-$(CONFIG_MACH_IGEP0020)		+= board-igep0020.o \
>  obj-$(CONFIG_MACH_OMAP3_TOUCHBOOK)	+= board-omap3touchbook.o \
>  					   hsmmc.o
>  obj-$(CONFIG_MACH_OMAP_4430SDP)		+= board-4430sdp.o \
> -					   hsmmc.o \
> -					   omap_phy_internal.o
> +					   hsmmc.o
>  obj-$(CONFIG_MACH_OMAP4_PANDA)		+= board-omap4panda.o \
> -					   hsmmc.o \
> -					   omap_phy_internal.o
> -
> +					   hsmmc.o
>  obj-$(CONFIG_MACH_OMAP3517EVM)		+= board-am3517evm.o \
>  					   omap_phy_internal.o \
>  
> @@ -275,6 +272,7 @@ obj-y					+= $(smc91x-m) $(smc91x-y)
>  smsc911x-$(CONFIG_SMSC911X)		:= gpmc-smsc911x.o
>  obj-y					+= $(smsc911x-m) $(smsc911x-y)
>  obj-$(CONFIG_ARCH_OMAP4)		+= hwspinlock.o
> +obj-$(CONFIG_ARCH_OMAP4)		+= omap_phy_internal.o
>  
>  disp-$(CONFIG_OMAP2_DSS)		:= display.o
>  obj-y					+= $(disp-m) $(disp-y)
> -- 
> 1.7.5.4
> 

[PATCH 13/30] ARM: omap2+: fix omap_hdq_init compilation

[Arnd Bergmann]

The definition of the device must depend on the hardware
we run on, not on the kernel configuration.

arch/arm/mach-omap2/devices.c:624:13: error: 'OMAP_HDQ_BASE' undeclared here (not in a function)

Signed-off-by: Arnd Bergmann <arnd@arndb.de>
---
 arch/arm/mach-omap2/devices.c |   10 ++++++----
 1 files changed, 6 insertions(+), 4 deletions(-)

diff --git a/arch/arm/mach-omap2/devices.c b/arch/arm/mach-omap2/devices.c
index 1077ad6..392f2b0 100644
--- a/arch/arm/mach-omap2/devices.c
+++ b/arch/arm/mach-omap2/devices.c
@@ -29,6 +29,7 @@
 #include <mach/gpio.h>
 #include <plat/mmc.h>
 #include <plat/dma.h>
+#include <plat/cpu.h>
 #include <plat/omap_hwmod.h>
 #include <plat/omap_device.h>
 #include <plat/omap4-keypad.h>
@@ -615,10 +616,8 @@ void __init omap242x_init_mmc(struct omap_mmc_platform_data **mmc_data)
 
 /*-------------------------------------------------------------------------*/
 
-#if defined(CONFIG_HDQ_MASTER_OMAP) || defined(CONFIG_HDQ_MASTER_OMAP_MODULE)
 #if defined(CONFIG_SOC_OMAP2430) || defined(CONFIG_SOC_OMAP3430)
 #define OMAP_HDQ_BASE	0x480B2000
-#endif
 static struct resource omap_hdq_resources[] = {
 	{
 		.start		= OMAP_HDQ_BASE,
@@ -641,10 +640,13 @@ static struct platform_device omap_hdq_dev = {
 };
 static inline void omap_hdq_init(void)
 {
-	(void) platform_device_register(&omap_hdq_dev);
+	if (cpu_is_omap2430() || cpu_is_omap3430())
+		(void) platform_device_register(&omap_hdq_dev);
 }
 #else
-static inline void omap_hdq_init(void) {}
+static inline void omap_hdq_init(void)
+{
+}
 #endif
 
 /*---------------------------------------------------------------------------*/
-- 
1.7.5.4

[PATCH 13/30] ARM: omap2+: fix omap_hdq_init compilation

[Santosh Shilimkar]

On Sunday 02 October 2011 08:15 PM, Arnd Bergmann wrote:
> The definition of the device must depend on the hardware
> we run on, not on the kernel configuration.
> 
> arch/arm/mach-omap2/devices.c:624:13: error: 'OMAP_HDQ_BASE' undeclared here (not in a function)
> 
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> ---
Acked-by: Santosh Shilimkar <santosh.shilimkar@ti.com>

[PATCH 13/30] ARM: omap2+: fix omap_hdq_init compilation

[Tony Lindgren]

* Santosh Shilimkar <santosh.shilimkar@ti.com> [111002 21:37]:
> On Sunday 02 October 2011 08:15 PM, Arnd Bergmann wrote:
> > The definition of the device must depend on the hardware
> > we run on, not on the kernel configuration.
> > 
> > arch/arm/mach-omap2/devices.c:624:13: error: 'OMAP_HDQ_BASE' undeclared here (not in a function)
> > 
> > Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> > ---
> Acked-by: Santosh Shilimkar <santosh.shilimkar@ti.com>

Acked-by: Tony Lindgren <tony@atomide.com>

[PATCH 14/30] ARM: omap2: irq.c is always needed

[Arnd Bergmann]

The Makefile only includes irq.o for omap2 and omap3, but it's in
fact also required to build omap4-only kernels.

Signed-off-by: Arnd Bergmann <arnd@arndb.de>
---
 arch/arm/mach-omap2/Makefile |    4 ++--
 1 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/arch/arm/mach-omap2/Makefile b/arch/arm/mach-omap2/Makefile
index dc36bd4..f14549d 100644
--- a/arch/arm/mach-omap2/Makefile
+++ b/arch/arm/mach-omap2/Makefile
@@ -4,9 +4,9 @@
 
 # Common support
 obj-y := id.o io.o control.o mux.o devices.o serial.o gpmc.o timer.o pm.o \
-	 common.o gpio.o dma.o wd_timer.o
+	 common.o gpio.o dma.o wd_timer.o irq.o
 
-omap-2-3-common				= irq.o sdrc.o
+omap-2-3-common				= sdrc.o
 hwmod-common				= omap_hwmod.o \
 					  omap_hwmod_common_data.o
 clock-common				= clock.o clock_common_data.o \
-- 
1.7.5.4

[PATCH 14/30] ARM: omap2: irq.c is always needed

[Santosh Shilimkar]

On Sunday 02 October 2011 08:15 PM, Arnd Bergmann wrote:
> The Makefile only includes irq.o for omap2 and omap3, but it's in
> fact also required to build omap4-only kernels.
> 
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
That should not be the case. Why do you think it is needed for OMAP4 ?
There is nothing in this file which OMAP4 needs since it makes
use of GIC and wakeupgen for it's interrupt handling.


Regards
Santosh

[PATCH 15/30] usb/musb: use a Kconfig choice to pick the right DMA method

[Arnd Bergmann]

The logic to allow only one DMA driver in MUSB is currently
flawed, because it also allows picking no DMA driver at all
and also not selecting PIO mode.

Using a choice statement makes this foolproof for now and
also simplifies the Makefile.

Unfortunately, we will have to revisit this when we start
supporting multiple ARM platforms in a single kernel binary,
because at that point we will actually need to select
multiple DMA drivers and pick the right one at run-time.

Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Cc: Felipe Balbi <balbi@ti.com>
---
 drivers/usb/musb/Kconfig  |   57 ++++++++++++++++++++++++++------------------
 drivers/usb/musb/Makefile |   26 +++-----------------
 2 files changed, 38 insertions(+), 45 deletions(-)

diff --git a/drivers/usb/musb/Kconfig b/drivers/usb/musb/Kconfig
index fc34b8b..d596fb2 100644
--- a/drivers/usb/musb/Kconfig
+++ b/drivers/usb/musb/Kconfig
@@ -64,46 +64,57 @@ config USB_MUSB_UX500
 
 endchoice
 
-config MUSB_PIO_ONLY
-	bool 'Disable DMA (always use PIO)'
-	depends on USB_MUSB_HDRC
-	default USB_MUSB_TUSB6010 || USB_MUSB_DA8XX || USB_MUSB_AM35X
+choice
+	prompt 'MUSB DMA mode'
+	default USB_UX500_DMA if USB_MUSB_UX500
+	default USB_INVENTRA_DMA if USB_MUSB_OMAP2PLUS || USB_MUSB_BLACKFIN
+	default USB_TI_CPPI_DMA if USB_MUSB_DAVINCI
+	default USB_TUSB_OMAP_DMA if USB_MUSB_TUSB6010
+	default MUSB_PIO_ONLY if USB_MUSB_TUSB6010 || USB_MUSB_DA8XX || USB_MUSB_AM35X
 	help
-	  All data is copied between memory and FIFO by the CPU.
-	  DMA controllers are ignored.
-
-	  Do not select 'n' here unless DMA support for your SOC or board
-	  is unavailable (or unstable).  When DMA is enabled at compile time,
-	  you can still disable it at run time using the "use_dma=n" module
-	  parameter.
+	  Unfortunately, only one option can be enabled here. Ideally one
+	  should be able to build all these drivers into one kernel to
+	  allow using DMA on multiplatform kernels.
 
 config USB_UX500_DMA
-	bool
-	depends on USB_MUSB_HDRC && !MUSB_PIO_ONLY
-	default USB_MUSB_UX500
+	bool 'ST Ericsson U8500 and U5500'
+	depends on USB_MUSB_HDRC
+	depends on USB_MUSB_UX500
 	help
 	  Enable DMA transfers on UX500 platforms.
 
 config USB_INVENTRA_DMA
-	bool
-	depends on USB_MUSB_HDRC && !MUSB_PIO_ONLY
-	default USB_MUSB_OMAP2PLUS || USB_MUSB_BLACKFIN
+	bool 'Inventra'
+	depends on USB_MUSB_HDRC
+	depends on USB_MUSB_OMAP2PLUS || USB_MUSB_BLACKFIN
 	help
 	  Enable DMA transfers using Mentor's engine.
 
 config USB_TI_CPPI_DMA
-	bool
-	depends on USB_MUSB_HDRC && !MUSB_PIO_ONLY
-	default USB_MUSB_DAVINCI
+	bool 'TI CPPI (Davinci)'
+	depends on USB_MUSB_HDRC
+	depends on USB_MUSB_DAVINCI
 	help
 	  Enable DMA transfers when TI CPPI DMA is available.
 
 config USB_TUSB_OMAP_DMA
-	bool
-	depends on USB_MUSB_HDRC && !MUSB_PIO_ONLY
+	bool 'TUSB 6010'
+	depends on USB_MUSB_HDRC
 	depends on USB_MUSB_TUSB6010
 	depends on ARCH_OMAP
-	default y
 	help
 	  Enable DMA transfers on TUSB 6010 when OMAP DMA is available.
 
+config MUSB_PIO_ONLY
+	bool 'Disable DMA (always use PIO)'
+	depends on USB_MUSB_HDRC
+	help
+	  All data is copied between memory and FIFO by the CPU.
+	  DMA controllers are ignored.
+
+	  Do not choose this unless DMA support for your SOC or board
+	  is unavailable (or unstable).  When DMA is enabled at compile time,
+	  you can still disable it at run time using the "use_dma=n" module
+	  parameter.
+
+endchoice
diff --git a/drivers/usb/musb/Makefile b/drivers/usb/musb/Makefile
index d8fd9d0..88bfb9d 100644
--- a/drivers/usb/musb/Makefile
+++ b/drivers/usb/musb/Makefile
@@ -24,25 +24,7 @@ obj-$(CONFIG_USB_MUSB_UX500)			+= ux500.o
 # PIO only, or DMA (several potential schemes).
 # though PIO is always there to back up DMA, and for ep0
 
-ifneq ($(CONFIG_MUSB_PIO_ONLY),y)
-
-  ifeq ($(CONFIG_USB_INVENTRA_DMA),y)
-    musb_hdrc-y			+= musbhsdma.o
-
-  else
-    ifeq ($(CONFIG_USB_TI_CPPI_DMA),y)
-      musb_hdrc-y		+= cppi_dma.o
-
-    else
-      ifeq ($(CONFIG_USB_TUSB_OMAP_DMA),y)
-	musb_hdrc-y		+= tusb6010_omap.o
-
-      else
-        ifeq ($(CONFIG_USB_UX500_DMA),y)
-	  musb_hdrc-y		+= ux500_dma.o
-
-        endif
-      endif
-    endif
-  endif
-endif
+musb_hdrc-$(CONFIG_USB_INVENTRA_DMA)		+= musbhsdma.o
+musb_hdrc-$(CONFIG_USB_TI_CPPI_DMA)		+= cppi_dma.o
+musb_hdrc-$(CONFIG_USB_TUSB_OMAP_DMA)		+= tusb6010_omap.o
+musb_hdrc-$(CONFIG_USB_UX500_DMA)		+= ux500_dma.o
-- 
1.7.5.4

[PATCH 15/30] usb/musb: use a Kconfig choice to pick the right DMA method

[Russell King - ARM Linux]

On Sun, Oct 02, 2011 at 04:45:45PM +0200, Arnd Bergmann wrote:
> The logic to allow only one DMA driver in MUSB is currently
> flawed, because it also allows picking no DMA driver at all
> and also not selecting PIO mode.
> 
> Using a choice statement makes this foolproof for now and
> also simplifies the Makefile.
> 
> Unfortunately, we will have to revisit this when we start
> supporting multiple ARM platforms in a single kernel binary,
> because at that point we will actually need to select
> multiple DMA drivers and pick the right one at run-time.

I thought there was some work going on to convert this to use the
dmaengine stuff?

But in any case, a stop-gap fix is needed for randconfig.

[PATCH 15/30] usb/musb: use a Kconfig choice to pick the right DMA method

[Arnd Bergmann]

On Sunday 02 October 2011 17:14:47 Russell King - ARM Linux wrote:
> On Sun, Oct 02, 2011 at 04:45:45PM +0200, Arnd Bergmann wrote:
> > The logic to allow only one DMA driver in MUSB is currently
> > flawed, because it also allows picking no DMA driver at all
> > and also not selecting PIO mode.
> > 
> > Using a choice statement makes this foolproof for now and
> > also simplifies the Makefile.
> > 
> > Unfortunately, we will have to revisit this when we start
> > supporting multiple ARM platforms in a single kernel binary,
> > because at that point we will actually need to select
> > multiple DMA drivers and pick the right one at run-time.
> 
> I thought there was some work going on to convert this to use the
> dmaengine stuff?

That would certainly be the best solution here, I wasn't aware
that it has already been discussed.

Unfortunately, even with the dma parts out of the way there is
a lot that needs to be done to make musb, ehci or ohci
really cross-platform. Right now, you can only have one
platform driver glue for each of those drivers, and they
should eventually be converted to a large library module for
the core, with independent platform driver front-end, similar
to the recent conversion of the sdhci driver by Shawn Guo,
and the way that a lot of the other common drivers work.

	Arnd

[PATCH 15/30] usb/musb: use a Kconfig choice to pick the right DMA method

[Felipe Balbi]

Hi,

On Sun, Oct 02, 2011 at 08:00:31PM +0200, Arnd Bergmann wrote:
> On Sunday 02 October 2011 17:14:47 Russell King - ARM Linux wrote:
> > On Sun, Oct 02, 2011 at 04:45:45PM +0200, Arnd Bergmann wrote:
> > > The logic to allow only one DMA driver in MUSB is currently
> > > flawed, because it also allows picking no DMA driver at all
> > > and also not selecting PIO mode.
> > > 
> > > Using a choice statement makes this foolproof for now and
> > > also simplifies the Makefile.
> > > 
> > > Unfortunately, we will have to revisit this when we start
> > > supporting multiple ARM platforms in a single kernel binary,
> > > because at that point we will actually need to select
> > > multiple DMA drivers and pick the right one at run-time.
> > 
> > I thought there was some work going on to convert this to use the
> > dmaengine stuff?
> 
> That would certainly be the best solution here, I wasn't aware
> that it has already been discussed.
> 
> Unfortunately, even with the dma parts out of the way there is
> a lot that needs to be done to make musb, ehci or ohci
> really cross-platform. Right now, you can only have one
> platform driver glue for each of those drivers, and they

that's not true for musb. I can already compile am35x and omap2430
together. TUSB is a different story though. With a small effort, we
could also allow DaVinci and the like to compile cleanly and work.

> should eventually be converted to a large library module for
> the core, with independent platform driver front-end, similar

that's how MUSB works now and that's what I have been discussing with
Alan Stern for the past month or so, wrt to *HCI. There are even patches
floating on linux-usb right now trying to hash out the problems.

Maybe you should have consulted the maintainers of those drivers before
making such statements.

MUSB is not the best example because of its history. I understand the
DMA part is still really messy, but we have been working very hard to
hash the problems and still allow new glue layers to be merged.

How about taking a sneak pick at what the code does right now ? As of
today, I can even even have *all* UDC controller drivers into one kernel
and I generally compile x86 with all controllers available. There's some
very small work that has to be done on each of the UDC drivers to remove
any references to <arch/..> <asm/..> and <plat/..> headers but that work
in in progress.

Also, when sending USB patches, be sure to Cc linux-usb at vger where most
of the discussion is happening.

-- 
balbi
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 490 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20111002/f1746536/attachment.sig>

[PATCH 15/30] usb/musb: use a Kconfig choice to pick the right DMA method

[Arnd Bergmann]

On Sunday 02 October 2011 21:56:09 Felipe Balbi wrote:
> 
> > Unfortunately, even with the dma parts out of the way there is
> > a lot that needs to be done to make musb, ehci or ohci
> > really cross-platform. Right now, you can only have one
> > platform driver glue for each of those drivers, and they
> 
> that's not true for musb. I can already compile am35x and omap2430
> together. TUSB is a different story though. With a small effort, we
> could also allow DaVinci and the like to compile cleanly and work.

Ok, good.

> > should eventually be converted to a large library module for
> > the core, with independent platform driver front-end, similar
> 
> that's how MUSB works now and that's what I have been discussing with
> Alan Stern for the past month or so, wrt to *HCI. There are even patches
> floating on linux-usb right now trying to hash out the problems.

Ah, glad to see that is happening. I can probably get rid of a bunch
of randconfig patches I have for those then.

> Maybe you should have consulted the maintainers of those drivers before
> making such statements.
>
> MUSB is not the best example because of its history. I understand the
> DMA part is still really messy, but we have been working very hard to
> hash the problems and still allow new glue layers to be merged.

Sorry if I have made my statement sound like an accusation, it wasn't
meant as one, merely as a sigh at having identified yet another area
that needs to be changed in order to have cross-platform ARM kernels
working in every case.
 
> How about taking a sneak pick at what the code does right now ? As of
> today, I can even even have all UDC controller drivers into one kernel
> and I generally compile x86 with all controllers available. There's some
> very small work that has to be done on each of the UDC drivers to remove
> any references to <arch/..> <asm/..> and <plat/..> headers but that work
> in in progress.

I didn't really see any problems with UDC at all. What I saw were a lot
of build problems with the musb host side, and I rewrote this patch half
a dozen times before I ended up with a version that consistently built
without making the code look worse.

I also agree that the musb implementation is less of a problem than
ohci/ehci in its current form, as it already is layered in the right
way. I did not attempt to turn the Kconfig 'choice' statement there
into a flat list though, so I wouldn't know what problems to expect.

	Arnd

[PATCH 15/30] usb/musb: use a Kconfig choice to pick the right DMA method

[Felipe Balbi]

Hi,

On Sun, Oct 02, 2011 at 09:44:26PM +0200, Arnd Bergmann wrote:
> > that's how MUSB works now and that's what I have been discussing with
> > Alan Stern for the past month or so, wrt to *HCI. There are even patches
> > floating on linux-usb right now trying to hash out the problems.
> 
> Ah, glad to see that is happening. I can probably get rid of a bunch
> of randconfig patches I have for those then.

glad to hear you're sorting out randconfig :-)

> > Maybe you should have consulted the maintainers of those drivers before
> > making such statements.
> >
> > MUSB is not the best example because of its history. I understand the
> > DMA part is still really messy, but we have been working very hard to
> > hash the problems and still allow new glue layers to be merged.
> 
> Sorry if I have made my statement sound like an accusation, it wasn't
> meant as one, merely as a sigh at having identified yet another area
> that needs to be changed in order to have cross-platform ARM kernels
> working in every case.

no big deal ;-)

> > How about taking a sneak pick at what the code does right now ? As of
> > today, I can even even have all UDC controller drivers into one kernel
> > and I generally compile x86 with all controllers available. There's some
> > very small work that has to be done on each of the UDC drivers to remove
> > any references to <arch/..> <asm/..> and <plat/..> headers but that work
> > in in progress.
> 
> I didn't really see any problems with UDC at all. What I saw were a lot
> of build problems with the musb host side, and I rewrote this patch half
> a dozen times before I ended up with a version that consistently built
> without making the code look worse.

I understand.

> I also agree that the musb implementation is less of a problem than
> ohci/ehci in its current form, as it already is layered in the right
> way. I did not attempt to turn the Kconfig 'choice' statement there
> into a flat list though, so I wouldn't know what problems to expect.

Actually, MUSB still has lots of goofage from the original mentor
release but that's another story.

Anyway, I'll take your patches in, but their too late for this merge
window :-( I already sent my last pull to Greg.

-- 
balbi
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 490 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20111003/d84b67a2/attachment.sig>

[PATCH 15/30] usb/musb: use a Kconfig choice to pick the right DMA method

[Arnd Bergmann]

On Monday 03 October 2011 01:10:51 Felipe Balbi wrote:
> Anyway, I'll take your patches in, but their too late for this merge
> window  I already sent my last pull to Greg.

No problem. I need the full set of arm-randconfig patches upstream in order
to make randconfig work in general, and that's not happening for 3.2
anyway. Right now, I'm just trying to as many patches as possible into
maintainer trees.

Is your tree part of linux-next, or will it only show up after the merge
window once Greg has pulled your first set for 3.3?

	Arnd

[PATCH 15/30] usb/musb: use a Kconfig choice to pick the right DMA method

[Felipe Balbi]

Hi,

On Mon, Oct 03, 2011 at 11:40:26AM +0200, Arnd Bergmann wrote:
> On Monday 03 October 2011 01:10:51 Felipe Balbi wrote:
> > Anyway, I'll take your patches in, but their too late for this merge
> > window  I already sent my last pull to Greg.
> 
> No problem. I need the full set of arm-randconfig patches upstream in order
> to make randconfig work in general, and that's not happening for 3.2
> anyway. Right now, I'm just trying to as many patches as possible into
> maintainer trees.
> 
> Is your tree part of linux-next, or will it only show up after the merge
> window once Greg has pulled your first set for 3.3?

My tree isn't in linux-next yet so my patches go to Greg and from there
to -next.

-- 
balbi
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 490 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20111003/fd2867bf/attachment.sig>

[PATCH 15/30] usb/musb: use a Kconfig choice to pick the right DMA method

[Felipe Balbi]

On Sun, Oct 02, 2011 at 04:45:45PM +0200, Arnd Bergmann wrote:
> The logic to allow only one DMA driver in MUSB is currently
> flawed, because it also allows picking no DMA driver at all
> and also not selecting PIO mode.
> 
> Using a choice statement makes this foolproof for now and
> also simplifies the Makefile.
> 
> Unfortunately, we will have to revisit this when we start
> supporting multiple ARM platforms in a single kernel binary,
> because at that point we will actually need to select
> multiple DMA drivers and pick the right one at run-time.
> 
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> Cc: Felipe Balbi <balbi@ti.com>

applied, thanks

-- 
balbi
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 490 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20111010/6dbad263/attachment-0001.sig>

[PATCH 16/30] usb/musb: HDRC depends on TWL4030_CORE for OMAP3/4

[Arnd Bergmann]

The musb_hdrc driver tries to select TWL4030_USB or TWL6030_USB
on some platforms, but those symbols in turn depend on TWL4030_CORE.
Trying not to spread the 'select' further, this makes the driver
depend on the TWL4030_CORE for the platforms that do other selects.

Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Cc: Felipe Balbi <balbi@ti.com>
---
 drivers/usb/musb/Kconfig |    1 +
 1 files changed, 1 insertions(+), 0 deletions(-)

diff --git a/drivers/usb/musb/Kconfig b/drivers/usb/musb/Kconfig
index d596fb2..b6732ee 100644
--- a/drivers/usb/musb/Kconfig
+++ b/drivers/usb/musb/Kconfig
@@ -7,6 +7,7 @@
 config USB_MUSB_HDRC
 	depends on USB && USB_GADGET
 	depends on (ARM || (BF54x && !BF544) || (BF52x && !BF522 && !BF523))
+	depends on TWL4030_CORE || !(MACH_OMAP_3430SDP || MACH_OMAP_4430SDP || MACH_OMAP4_PANDA)
 	select NOP_USB_XCEIV if (ARCH_DAVINCI || MACH_OMAP3EVM || BLACKFIN)
 	select TWL4030_USB if MACH_OMAP_3430SDP
 	select TWL6030_USB if MACH_OMAP_4430SDP || MACH_OMAP4_PANDA
-- 
1.7.5.4

[PATCH 16/30] usb/musb: HDRC depends on TWL4030_CORE for OMAP3/4

[Felipe Balbi]

Hi,

On Sun, Oct 02, 2011 at 04:45:46PM +0200, Arnd Bergmann wrote:
> The musb_hdrc driver tries to select TWL4030_USB or TWL6030_USB
> on some platforms, but those symbols in turn depend on TWL4030_CORE.

the very fact that MUSB tries to select those is wrong. That's also some
buggy legacy crap which is still floating around...

MUSB does not depend on TWL4030. MUSB depends on a PHY being available,
no matter which one.

IMHO, this would be better moved to board definition, ideally with an
option for selecting some symbol as module (as I have suggested before).

Ideally, all those broken dependencies on MUSB would be cut down to
depends on USB && USB_GADGET.

-- 
balbi
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 490 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20111002/2bbe1108/attachment.sig>

[PATCH 17/30] usb/musb: allow building USB_MUSB_TUSB6010 as a module

[Arnd Bergmann]

Commit 1376d92f9 "usb: musb: allow musb and glue layers to be modules"
made the USB_MUSB_TUSB6010 option modular, but actually building
the driver as a module does not work, so various randconfig builds
actually fail. This changes all code that depends on the
option to also check for modular builds, and exports the necessary
symbols.

Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Cc: Felipe Balbi <balbi@ti.com>
---
 arch/arm/mach-omap2/board-n8x0.c |    2 +-
 drivers/usb/musb/musb_core.c     |    3 ++-
 drivers/usb/musb/musb_io.h       |    2 +-
 drivers/usb/musb/tusb6010.c      |    1 +
 4 files changed, 5 insertions(+), 3 deletions(-)

diff --git a/arch/arm/mach-omap2/board-n8x0.c b/arch/arm/mach-omap2/board-n8x0.c
index 403325d..c096dc2 100644
--- a/arch/arm/mach-omap2/board-n8x0.c
+++ b/arch/arm/mach-omap2/board-n8x0.c
@@ -46,7 +46,7 @@ static struct device *mmc_device;
 #define TUSB6010_GPIO_ENABLE	0
 #define TUSB6010_DMACHAN	0x3f
 
-#ifdef CONFIG_USB_MUSB_TUSB6010
+#if defined(CONFIG_USB_MUSB_TUSB6010) || defined(CONFIG_USB_MUSB_TUSB6010_MODULE)
 /*
  * Enable or disable power to TUSB6010. When enabling, turn on 3.3 V and
  * 1.5 V voltage regulators of PM companion chip. Companion chip will then
diff --git a/drivers/usb/musb/musb_core.c b/drivers/usb/musb/musb_core.c
index 20a2873..9fa2596 100644
--- a/drivers/usb/musb/musb_core.c
+++ b/drivers/usb/musb/musb_core.c
@@ -1432,7 +1432,7 @@ static int __init musb_core_init(u16 musb_type, struct musb *musb)
 		struct musb_hw_ep	*hw_ep = musb->endpoints + i;
 
 		hw_ep->fifo = MUSB_FIFO_OFFSET(i) + mbase;
-#ifdef CONFIG_USB_MUSB_TUSB6010
+#if defined(CONFIG_USB_MUSB_TUSB6010) || defined (CONFIG_USB_MUSB_TUSB6010_MODULE)
 		hw_ep->fifo_async = musb->async + 0x400 + MUSB_FIFO_OFFSET(i);
 		hw_ep->fifo_sync = musb->sync + 0x400 + MUSB_FIFO_OFFSET(i);
 		hw_ep->fifo_sync_va =
@@ -1632,6 +1632,7 @@ void musb_dma_completion(struct musb *musb, u8 epnum, u8 transmit)
 		}
 	}
 }
+EXPORT_SYMBOL_GPL(musb_dma_completion);
 
 #else
 #define use_dma			0
diff --git a/drivers/usb/musb/musb_io.h b/drivers/usb/musb/musb_io.h
index 03c6ccd..e61aa95 100644
--- a/drivers/usb/musb/musb_io.h
+++ b/drivers/usb/musb/musb_io.h
@@ -74,7 +74,7 @@ static inline void musb_writel(void __iomem *addr, unsigned offset, u32 data)
 	{ __raw_writel(data, addr + offset); }
 
 
-#ifdef CONFIG_USB_MUSB_TUSB6010
+#if defined(CONFIG_USB_MUSB_TUSB6010) || defined (CONFIG_USB_MUSB_TUSB6010_MODULE)
 
 /*
  * TUSB6010 doesn't allow 8-bit access; 16-bit access is the minimum.
diff --git a/drivers/usb/musb/tusb6010.c b/drivers/usb/musb/tusb6010.c
index ec14801..1f40561 100644
--- a/drivers/usb/musb/tusb6010.c
+++ b/drivers/usb/musb/tusb6010.c
@@ -56,6 +56,7 @@ u8 tusb_get_revision(struct musb *musb)
 
 	return rev;
 }
+EXPORT_SYMBOL_GPL(tusb_get_revision);
 
 static int tusb_print_revision(struct musb *musb)
 {
-- 
1.7.5.4

[PATCH 17/30] usb/musb: allow building USB_MUSB_TUSB6010 as a module

[Tony Lindgren]

* Arnd Bergmann <arnd@arndb.de> [111002 07:13]:
> Commit 1376d92f9 "usb: musb: allow musb and glue layers to be modules"
> made the USB_MUSB_TUSB6010 option modular, but actually building
> the driver as a module does not work, so various randconfig builds
> actually fail. This changes all code that depends on the
> option to also check for modular builds, and exports the necessary
> symbols.
> 
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> Cc: Felipe Balbi <balbi@ti.com>

I guess the tusb_get_revision could also be an inline function
in tusb6010.h if we wanted to avoid that EXPORT_SYMBOL. Anyways:

Acked-by: Tony Lindgren <tony@atomide.com>

> ---
>  arch/arm/mach-omap2/board-n8x0.c |    2 +-
>  drivers/usb/musb/musb_core.c     |    3 ++-
>  drivers/usb/musb/musb_io.h       |    2 +-
>  drivers/usb/musb/tusb6010.c      |    1 +
>  4 files changed, 5 insertions(+), 3 deletions(-)
> 
> diff --git a/arch/arm/mach-omap2/board-n8x0.c b/arch/arm/mach-omap2/board-n8x0.c
> index 403325d..c096dc2 100644
> --- a/arch/arm/mach-omap2/board-n8x0.c
> +++ b/arch/arm/mach-omap2/board-n8x0.c
> @@ -46,7 +46,7 @@ static struct device *mmc_device;
>  #define TUSB6010_GPIO_ENABLE	0
>  #define TUSB6010_DMACHAN	0x3f
>  
> -#ifdef CONFIG_USB_MUSB_TUSB6010
> +#if defined(CONFIG_USB_MUSB_TUSB6010) || defined(CONFIG_USB_MUSB_TUSB6010_MODULE)
>  /*
>   * Enable or disable power to TUSB6010. When enabling, turn on 3.3 V and
>   * 1.5 V voltage regulators of PM companion chip. Companion chip will then
> diff --git a/drivers/usb/musb/musb_core.c b/drivers/usb/musb/musb_core.c
> index 20a2873..9fa2596 100644
> --- a/drivers/usb/musb/musb_core.c
> +++ b/drivers/usb/musb/musb_core.c
> @@ -1432,7 +1432,7 @@ static int __init musb_core_init(u16 musb_type, struct musb *musb)
>  		struct musb_hw_ep	*hw_ep = musb->endpoints + i;
>  
>  		hw_ep->fifo = MUSB_FIFO_OFFSET(i) + mbase;
> -#ifdef CONFIG_USB_MUSB_TUSB6010
> +#if defined(CONFIG_USB_MUSB_TUSB6010) || defined (CONFIG_USB_MUSB_TUSB6010_MODULE)
>  		hw_ep->fifo_async = musb->async + 0x400 + MUSB_FIFO_OFFSET(i);
>  		hw_ep->fifo_sync = musb->sync + 0x400 + MUSB_FIFO_OFFSET(i);
>  		hw_ep->fifo_sync_va =
> @@ -1632,6 +1632,7 @@ void musb_dma_completion(struct musb *musb, u8 epnum, u8 transmit)
>  		}
>  	}
>  }
> +EXPORT_SYMBOL_GPL(musb_dma_completion);
>  
>  #else
>  #define use_dma			0
> diff --git a/drivers/usb/musb/musb_io.h b/drivers/usb/musb/musb_io.h
> index 03c6ccd..e61aa95 100644
> --- a/drivers/usb/musb/musb_io.h
> +++ b/drivers/usb/musb/musb_io.h
> @@ -74,7 +74,7 @@ static inline void musb_writel(void __iomem *addr, unsigned offset, u32 data)
>  	{ __raw_writel(data, addr + offset); }
>  
>  
> -#ifdef CONFIG_USB_MUSB_TUSB6010
> +#if defined(CONFIG_USB_MUSB_TUSB6010) || defined (CONFIG_USB_MUSB_TUSB6010_MODULE)
>  
>  /*
>   * TUSB6010 doesn't allow 8-bit access; 16-bit access is the minimum.
> diff --git a/drivers/usb/musb/tusb6010.c b/drivers/usb/musb/tusb6010.c
> index ec14801..1f40561 100644
> --- a/drivers/usb/musb/tusb6010.c
> +++ b/drivers/usb/musb/tusb6010.c
> @@ -56,6 +56,7 @@ u8 tusb_get_revision(struct musb *musb)
>  
>  	return rev;
>  }
> +EXPORT_SYMBOL_GPL(tusb_get_revision);
>  
>  static int tusb_print_revision(struct musb *musb)
>  {
> -- 
> 1.7.5.4
> 

[PATCH 17/30] usb/musb: allow building USB_MUSB_TUSB6010 as a module

[Felipe Balbi]

On Sun, Oct 02, 2011 at 04:45:47PM +0200, Arnd Bergmann wrote:
> Commit 1376d92f9 "usb: musb: allow musb and glue layers to be modules"
> made the USB_MUSB_TUSB6010 option modular, but actually building
> the driver as a module does not work, so various randconfig builds
> actually fail. This changes all code that depends on the
> option to also check for modular builds, and exports the necessary
> symbols.
> 
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> Cc: Felipe Balbi <balbi@ti.com>

applied, thanks

-- 
balbi
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 490 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20111010/b1e00fb9/attachment.sig>

[PATCH 18/30] omap-usb: automatically select MFD_OMAP_USB_HOST

[Arnd Bergmann]

The ehci-omap and ohci-omap3 drivers both depend on the
omap-usb-host MFD support driver. By default, this is
automatically turned on, but it is possible to disable
the driver, which results in a link error.

This patch makes the option invisible so we always do
the right thing.

Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Cc: Keshava Munegowda <keshava_mgowda@ti.com>
Cc: Samuel Ortiz <sameo@linux.intel.com>
---
 drivers/mfd/Kconfig |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/drivers/mfd/Kconfig b/drivers/mfd/Kconfig
index 21574bd..48cce35 100644
--- a/drivers/mfd/Kconfig
+++ b/drivers/mfd/Kconfig
@@ -721,7 +721,7 @@ config MFD_WL1273_CORE
 	  audio codec.
 
 config MFD_OMAP_USB_HOST
-	bool "Support OMAP USBHS core driver"
+	bool
 	depends on USB_EHCI_HCD_OMAP || USB_OHCI_HCD_OMAP3
 	default y
 	help
-- 
1.7.5.4

[PATCH 18/30] omap-usb: automatically select MFD_OMAP_USB_HOST

[Samuel Ortiz]

Hi Arnd,

On Sun, Oct 02, 2011 at 04:45:48PM +0200, Arnd Bergmann wrote:
> The ehci-omap and ohci-omap3 drivers both depend on the
> omap-usb-host MFD support driver. By default, this is
> automatically turned on, but it is possible to disable
> the driver, which results in a link error.
I don't see the Kconfig entry for e.g. the ohci-omap3 driver, but shouldn't
the dependency be handled there ?
If ohci-omap3 depends on omap-usb-host, then we should not be able to disable
the latter while the former is selected.

Cheers,
Samuel.

-- 
Intel Open Source Technology Centre
http://oss.intel.com/

[PATCH 19/30] tty/serial/omap: console can only be built-in

[Arnd Bergmann]

When the omap serial driver is built as a module, we must
not allow the console driver to be selected, because consoles
can not be loadable modules.

Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Cc: Govindraj.R <govindraj.raja@ti.com>
---
 drivers/tty/serial/Kconfig |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/drivers/tty/serial/Kconfig b/drivers/tty/serial/Kconfig
index 4dcb37bb..eb04b2f 100644
--- a/drivers/tty/serial/Kconfig
+++ b/drivers/tty/serial/Kconfig
@@ -1346,7 +1346,7 @@ config SERIAL_OMAP
 
 config SERIAL_OMAP_CONSOLE
 	bool "Console on OMAP serial port"
-	depends on SERIAL_OMAP
+	depends on SERIAL_OMAP=y
 	select SERIAL_CORE_CONSOLE
 	help
 	  Select this option if you would like to use omap serial port as
-- 
1.7.5.4

[PATCH 19/30] tty/serial/omap: console can only be built-in

[Govindraj]

On Sun, Oct 2, 2011 at 8:15 PM, Arnd Bergmann <arnd@arndb.de> wrote:
> When the omap serial driver is built as a module, we must
> not allow the console driver to be selected, because consoles
> can not be loadable modules.

Agree.

>
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> Cc: Govindraj.R <govindraj.raja@ti.com>

Acked-by: Govindraj.R <govindraj.raja@ti.com>

> ---
> ?drivers/tty/serial/Kconfig | ? ?2 +-
> ?1 files changed, 1 insertions(+), 1 deletions(-)
>
> diff --git a/drivers/tty/serial/Kconfig b/drivers/tty/serial/Kconfig
> index 4dcb37bb..eb04b2f 100644
> --- a/drivers/tty/serial/Kconfig
> +++ b/drivers/tty/serial/Kconfig
> @@ -1346,7 +1346,7 @@ config SERIAL_OMAP
>
> ?config SERIAL_OMAP_CONSOLE
> ? ? ? ?bool "Console on OMAP serial port"
> - ? ? ? depends on SERIAL_OMAP
> + ? ? ? depends on SERIAL_OMAP=y
> ? ? ? ?select SERIAL_CORE_CONSOLE
> ? ? ? ?help
> ? ? ? ? ?Select this option if you would like to use omap serial port as
> --
> 1.7.5.4
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo at vger.kernel.org
> More majordomo info at ?http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at ?http://www.tux.org/lkml/
>

[PATCH 20/30] media/omap_vout: disable driver for now

[Arnd Bergmann]

This driver was broken by 8cff88c5d "OMAP: DSS2: remove update_mode
from omapdss":

/home/arnd/linux-arm/drivers/media/video/omap/omap_vout.c: In function 'omap_vout_probe':
/home/arnd/linux-arm/drivers/media/video/omap/omap_vout.c:2202:15: error: 'struct omap_dss_driver' has no member
named 'set_update_mode'
/home/arnd/linux-arm/drivers/media/video/omap/omap_vout.c:2203:12: error: 'struct omap_dss_driver' has no member
named 'set_update_mode'
/home/arnd/linux-arm/drivers/media/video/omap/omap_vout.c:2204:8: error: 'OMAP_DSS_UPDATE_MANUAL' undeclared (first
use in this function)
/home/arnd/linux-arm/drivers/media/video/omap/omap_vout.c:2204:8: note: each undeclared identifier is reported only
once for each function it appears in
/home/arnd/linux-arm/drivers/media/video/omap/omap_vout.c:2206:15: error: 'struct omap_dss_driver' has no member
named 'set_update_mode'
/home/arnd/linux-arm/drivers/media/video/omap/omap_vout.c:2207:12: error: 'struct omap_dss_driver' has no member
named 'set_update_mode'
/home/arnd/linux-arm/drivers/media/video/omap/omap_vout.c:2208:8: error: 'OMAP_DSS_UPDATE_AUTO' undeclared (first use
in this function)
make[3]: *** [drivers/media/video/omap/omap_vout.o] Error 1
make[2]: *** [drivers/media/video/omap] Error 2
make[1]: *** [drivers/media/video/] Error 2
make: *** [sub-make] Error 2

Let's disable it for now.

Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Cc: Mauro Carvalho Chehab <mchehab@infradead.org>
Cc: Archit Taneja <archit@ti.com>
Cc: Amber Jain <amber@ti.com>
Cc: Vaibhav Hiremath <hvaibhav@ti.com>
---
 drivers/media/video/omap/Kconfig |    1 +
 1 files changed, 1 insertions(+), 0 deletions(-)

diff --git a/drivers/media/video/omap/Kconfig b/drivers/media/video/omap/Kconfig
index 390ab09..ee21f36 100644
--- a/drivers/media/video/omap/Kconfig
+++ b/drivers/media/video/omap/Kconfig
@@ -4,6 +4,7 @@ config VIDEO_OMAP2_VOUT_VRFB
 config VIDEO_OMAP2_VOUT
 	tristate "OMAP2/OMAP3 V4L2-Display driver"
 	depends on ARCH_OMAP2 || ARCH_OMAP3
+	depends on BROKEN # broken by 8cff88c5da "OMAP: DSS2: remove update_mode from omapdss"
 	select VIDEOBUF_GEN
 	select VIDEOBUF_DMA_CONTIG
 	select OMAP2_DSS
-- 
1.7.5.4

[PATCH 20/30] media/omap_vout: disable driver for now

[Archit Taneja]

Hi Arnd,

On Sunday 02 October 2011 08:15 PM, Arnd Bergmann wrote:
> This driver was broken by 8cff88c5d "OMAP: DSS2: remove update_mode
> from omapdss":
>
> /home/arnd/linux-arm/drivers/media/video/omap/omap_vout.c: In function 'omap_vout_probe':
> /home/arnd/linux-arm/drivers/media/video/omap/omap_vout.c:2202:15: error: 'struct omap_dss_driver' has no member
> named 'set_update_mode'
> /home/arnd/linux-arm/drivers/media/video/omap/omap_vout.c:2203:12: error: 'struct omap_dss_driver' has no member
> named 'set_update_mode'
> /home/arnd/linux-arm/drivers/media/video/omap/omap_vout.c:2204:8: error: 'OMAP_DSS_UPDATE_MANUAL' undeclared (first
> use in this function)
> /home/arnd/linux-arm/drivers/media/video/omap/omap_vout.c:2204:8: note: each undeclared identifier is reported only
> once for each function it appears in
> /home/arnd/linux-arm/drivers/media/video/omap/omap_vout.c:2206:15: error: 'struct omap_dss_driver' has no member
> named 'set_update_mode'
> /home/arnd/linux-arm/drivers/media/video/omap/omap_vout.c:2207:12: error: 'struct omap_dss_driver' has no member
> named 'set_update_mode'
> /home/arnd/linux-arm/drivers/media/video/omap/omap_vout.c:2208:8: error: 'OMAP_DSS_UPDATE_AUTO' undeclared (first use
> in this function)
> make[3]: *** [drivers/media/video/omap/omap_vout.o] Error 1
> make[2]: *** [drivers/media/video/omap] Error 2
> make[1]: *** [drivers/media/video/] Error 2
> make: *** [sub-make] Error 2

A fix for this is already in the master branch of Mauro's tree:

git://linuxtv.org/media_tree.git

with the commit id:

5ebbf72dc51bd3b481aa91fea37a7157da5fc548

I am guessing this would during the 3.2 merge window.

Regards,
Archit

>
> Let's disable it for now.
>
> Signed-off-by: Arnd Bergmann<arnd@arndb.de>
> Cc: Mauro Carvalho Chehab<mchehab@infradead.org>
> Cc: Archit Taneja<archit@ti.com>
> Cc: Amber Jain<amber@ti.com>
> Cc: Vaibhav Hiremath<hvaibhav@ti.com>
> ---
>   drivers/media/video/omap/Kconfig |    1 +
>   1 files changed, 1 insertions(+), 0 deletions(-)
>
> diff --git a/drivers/media/video/omap/Kconfig b/drivers/media/video/omap/Kconfig
> index 390ab09..ee21f36 100644
> --- a/drivers/media/video/omap/Kconfig
> +++ b/drivers/media/video/omap/Kconfig
> @@ -4,6 +4,7 @@ config VIDEO_OMAP2_VOUT_VRFB
>   config VIDEO_OMAP2_VOUT
>   	tristate "OMAP2/OMAP3 V4L2-Display driver"
>   	depends on ARCH_OMAP2 || ARCH_OMAP3
> +	depends on BROKEN # broken by 8cff88c5da "OMAP: DSS2: remove update_mode from omapdss"
>   	select VIDEOBUF_GEN
>   	select VIDEOBUF_DMA_CONTIG
>   	select OMAP2_DSS

[PATCH 20/30] media/omap_vout: disable driver for now

[Arnd Bergmann]

On Monday 03 October 2011 11:39:59 Archit Taneja wrote:
> 
> A fix for this is already in the master branch of Mauro's tree:
> 
> git://linuxtv.org/media_tree.git
> 
> with the commit id:
> 
> 5ebbf72dc51bd3b481aa91fea37a7157da5fc548
> 
> I am guessing this would during the 3.2 merge window.

Ok, thanks for the info! We can drop this then.

	Arnd

[PATCH 21/30] sound/soc/omap: limit to omap2plus

[Arnd Bergmann]

These drivers do not build correctly on omap1, so only allow
selecting them on omap2 or higher.

Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Cc: Jarkko Nikula <jarkko.nikula@bitmer.com>
Cc: Liam Girdwood <lrg@ti.com>
---
 sound/soc/omap/Kconfig |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/sound/soc/omap/Kconfig b/sound/soc/omap/Kconfig
index fe83d0d..493733e 100644
--- a/sound/soc/omap/Kconfig
+++ b/sound/soc/omap/Kconfig
@@ -1,6 +1,6 @@
 config SND_OMAP_SOC
 	tristate "SoC Audio for the Texas Instruments OMAP chips"
-	depends on ARCH_OMAP
+	depends on ARCH_OMAP2PLUS
 
 config SND_OMAP_SOC_MCBSP
 	tristate
-- 
1.7.5.4

[PATCH 21/30] sound/soc/omap: limit to omap2plus

[Jarkko Nikula]

On Sun,  2 Oct 2011 16:45:51 +0200
Arnd Bergmann <arnd@arndb.de> wrote:

> These drivers do not build correctly on omap1, so only allow
> selecting them on omap2 or higher.
> 
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> Cc: Jarkko Nikula <jarkko.nikula@bitmer.com>
> Cc: Liam Girdwood <lrg@ti.com>
> ---
Strange. I'm able to build them fine with omap1_defconfig and with two
supported OMAP1 ASoC machine drivers we have:

CONFIG_SND_OMAP_SOC_AMS_DELTA=y
CONFIG_SND_OMAP_SOC_OSK5912=y

What's the error you are seeing? I guess there might be some missing
dependency that doesn't get visible with omap1_defconfig.

I would like to get that fixed instead of disabling OMAP1 ASoC support
as the ams-delta in kernel is alive device thanks to active developer
Janusz Krzysztofik <jkrzyszt@tis.icnet.pl>.

-- 
Jarkko

[PATCH 21/30] sound/soc/omap: limit to omap2plus

[Arnd Bergmann]

On Sunday 02 October 2011 20:40:35 Jarkko Nikula wrote:
> Strange. I'm able to build them fine with omap1_defconfig and with two
> supported OMAP1 ASoC machine drivers we have:
> 
> CONFIG_SND_OMAP_SOC_AMS_DELTA=y
> CONFIG_SND_OMAP_SOC_OSK5912=y
> 
> What's the error you are seeing? I guess there might be some missing
> dependency that doesn't get visible with omap1_defconfig.
> 
> I would like to get that fixed instead of disabling OMAP1 ASoC support
> as the ams-delta in kernel is alive device thanks to active developer
> Janusz Krzysztofik <jkrzyszt@tis.icnet.pl>.

I no longer have the original bug, maybe it was a false positive.
I'll drop this patch and have another look if the problem comes back.

Thanks for taking a closer look!

	Arnd

[PATCH 21/30] sound/soc/omap: limit to omap2plus

[Jarkko Nikula]

On Sun, 02 Oct 2011 20:03:38 +0200
Arnd Bergmann <arnd@arndb.de> wrote:

> On Sunday 02 October 2011 20:40:35 Jarkko Nikula wrote:
> > Strange. I'm able to build them fine with omap1_defconfig and with two
> > supported OMAP1 ASoC machine drivers we have:
> > 
> > CONFIG_SND_OMAP_SOC_AMS_DELTA=y
> > CONFIG_SND_OMAP_SOC_OSK5912=y
> > 
> > What's the error you are seeing? I guess there might be some missing
> > dependency that doesn't get visible with omap1_defconfig.
> > 
> > I would like to get that fixed instead of disabling OMAP1 ASoC support
> > as the ams-delta in kernel is alive device thanks to active developer
> > Janusz Krzysztofik <jkrzyszt@tis.icnet.pl>.
> 
> I no longer have the original bug, maybe it was a false positive.
> I'll drop this patch and have another look if the problem comes back.
> 
> Thanks for taking a closer look!
> 
Now when I remember we had one build error. Hopefully it was the same
than you observed?

commit e574044acbad7421879270a80acd337459c94cc8
Author: Jarkko Nikula <jarkko.nikula@bitmer.com>
Date:   Thu Aug 18 15:02:47 2011 +0300

    ASoC: omap: Fix build errors in ams-delta
    
    Fix "error: too few arguments to function 'ams_delta_set_bias_level'"
    build errors in ams-delta.c that were introduced after commit d4c6005 ("ASoC
    Add context parameter to card DAPM callbacks") by adding dapm context
    to ams_delta_set_bias_level calls.


-- 
Jarkko

[PATCH 21/30] sound/soc/omap: limit to omap2plus

[Arnd Bergmann]

On Sunday 02 October 2011 21:24:26 Jarkko Nikula wrote:
> Now when I remember we had one build error. Hopefully it was the same
> than you observed?

I think it was something different, but it's possible.

	Arnd

[PATCH 21/30] sound/soc/omap: limit to omap2plus

[Mark Brown]

On Sun, Oct 02, 2011 at 04:45:51PM +0200, Arnd Bergmann wrote:
> These drivers do not build correctly on omap1, so only allow
> selecting them on omap2 or higher.

No, OMAP1 is supposed to work and people actively seem to care about it.
If there's some problem with OMAP1 then please report it so that it can
be fixed.

You should also *always* both CC maintainers and relevant mailing lists
on patches so they can see what's going on (I'm being especially grumpy
now because you really should know better), and my previous comments
about subject lines also apply.

[PATCH 22/30] mfd: build twl6030 only on omap2

[Arnd Bergmann]

We can only have one pwm driver built into the kernel, so make sure
that this one is only available on omap2 to avoid conflicts with
pwm drivers of other platforms.

Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Cc: Samuel Ortiz <sameo@linux.intel.com>
Cc: Peter Ujfalusi <peter.ujfalusi@ti.com>
Cc: Balaji T K <balajitk@ti.com>
Cc: Hemanth V <hemanthv@ti.com>
---
 drivers/mfd/Kconfig |    4 ++--
 1 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/mfd/Kconfig b/drivers/mfd/Kconfig
index 48cce35..26bebe8 100644
--- a/drivers/mfd/Kconfig
+++ b/drivers/mfd/Kconfig
@@ -256,8 +256,8 @@ config MFD_TWL4030_AUDIO
 	default n
 
 config TWL6030_PWM
-	tristate "TWL6030 PWM (Pulse Width Modulator) Support"
-	depends on TWL4030_CORE
+	bool "TWL6030 PWM (Pulse Width Modulator) Support"
+	depends on TWL4030_CORE && ARCH_OMAP2
 	select HAVE_PWM
 	default n
 	help
-- 
1.7.5.4

[PATCH 22/30] mfd: build twl6030 only on omap2

[Samuel Ortiz]

Hi Arnd,

On Sun, Oct 02, 2011 at 04:45:52PM +0200, Arnd Bergmann wrote:
> We can only have one pwm driver built into the kernel,
I seem to remember that Bill Gatliff was working on a PWM subsystem that would
get rid of the current pwm.h ugliness. Do we have any updates on this one ?

The patch below looks like a hack to me, trying to work around the current
lack of such subsystem.

Cheers,
Samuel.

> so make sure
> that this one is only available on omap2 to avoid conflicts with
> pwm drivers of other platforms.
> 
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> Cc: Samuel Ortiz <sameo@linux.intel.com>
> Cc: Peter Ujfalusi <peter.ujfalusi@ti.com>
> Cc: Balaji T K <balajitk@ti.com>
> Cc: Hemanth V <hemanthv@ti.com>
> ---
>  drivers/mfd/Kconfig |    4 ++--
>  1 files changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/mfd/Kconfig b/drivers/mfd/Kconfig
> index 48cce35..26bebe8 100644
> --- a/drivers/mfd/Kconfig
> +++ b/drivers/mfd/Kconfig
> @@ -256,8 +256,8 @@ config MFD_TWL4030_AUDIO
>  	default n
>  
>  config TWL6030_PWM
> -	tristate "TWL6030 PWM (Pulse Width Modulator) Support"
> -	depends on TWL4030_CORE
> +	bool "TWL6030 PWM (Pulse Width Modulator) Support"
> +	depends on TWL4030_CORE && ARCH_OMAP2
>  	select HAVE_PWM
>  	default n
>  	help
> -- 
> 1.7.5.4
> 

-- 
Intel Open Source Technology Centre
http://oss.intel.com/

[PATCH 22/30] mfd: build twl6030 only on omap2

[Arnd Bergmann]

On Tuesday 04 October 2011, Samuel Ortiz wrote:
> On Sun, Oct 02, 2011 at 04:45:52PM +0200, Arnd Bergmann wrote:
> > We can only have one pwm driver built into the kernel,
> I seem to remember that Bill Gatliff was working on a PWM subsystem that would
> get rid of the current pwm.h ugliness. Do we have any updates on this one ?

I don't know if the work on the pwm subsystem is progressing right now,
there were at one point two competing patches, but so far neither of them
has made it into linux-next.
 
> The patch below looks like a hack to me, trying to work around the current
> lack of such subsystem.

Absolutely. I'll clarify this in the patch description when I fix the
bug pointed out by Balaji T Krishnamoorthy.

	Arnd

[PATCH 23/30] ARM: omap2: select twl4030 support on boards that need it

[Arnd Bergmann]

These three boards unconditionally use the twl4030 driver
from the board-zoom-display.c file. Make sure that the driver
is always there.
We also need to select the I2C core so we are able to build
that driver.

Signed-off-by: Arnd Bergmann <arnd@arndb.de>
---
 arch/arm/mach-omap2/Kconfig |    6 ++++++
 1 files changed, 6 insertions(+), 0 deletions(-)

diff --git a/arch/arm/mach-omap2/Kconfig b/arch/arm/mach-omap2/Kconfig
index 57b66d5..4deeade 100644
--- a/arch/arm/mach-omap2/Kconfig
+++ b/arch/arm/mach-omap2/Kconfig
@@ -253,6 +253,8 @@ config MACH_OMAP_ZOOM2
 	select SERIAL_CORE_CONSOLE
 	select SERIAL_8250_CONSOLE
 	select REGULATOR_FIXED_VOLTAGE
+	select TWL4030_CORE
+	select I2C
 
 config MACH_OMAP_ZOOM3
 	bool "OMAP3630 Zoom3 board"
@@ -263,6 +265,8 @@ config MACH_OMAP_ZOOM3
 	select SERIAL_CORE_CONSOLE
 	select SERIAL_8250_CONSOLE
 	select REGULATOR_FIXED_VOLTAGE
+	select TWL4030_CORE
+	select I2C
 
 config MACH_CM_T35
 	bool "CompuLab CM-T35/CM-T3730 modules"
@@ -304,6 +308,8 @@ config MACH_OMAP_3630SDP
 	depends on ARCH_OMAP3
 	default y
 	select OMAP_PACKAGE_CBP
+	select TWL4030_CORE
+	select I2C
 
 config MACH_TI8168EVM
 	bool "TI8168 Evaluation Module"
-- 
1.7.5.4

[PATCH 23/30] ARM: omap2: select twl4030 support on boards that need it

[Santosh Shilimkar]

On Sunday 02 October 2011 08:15 PM, Arnd Bergmann wrote:
> These three boards unconditionally use the twl4030 driver
> from the board-zoom-display.c file. Make sure that the driver
> is always there.
> We also need to select the I2C core so we are able to build
> that driver.
> 
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> ---
>  arch/arm/mach-omap2/Kconfig |    6 ++++++
>  1 files changed, 6 insertions(+), 0 deletions(-)
> 
> diff --git a/arch/arm/mach-omap2/Kconfig b/arch/arm/mach-omap2/Kconfig
> index 57b66d5..4deeade 100644
> --- a/arch/arm/mach-omap2/Kconfig
> +++ b/arch/arm/mach-omap2/Kconfig
> @@ -253,6 +253,8 @@ config MACH_OMAP_ZOOM2
>  	select SERIAL_CORE_CONSOLE
>  	select SERIAL_8250_CONSOLE
>  	select REGULATOR_FIXED_VOLTAGE
> +	select TWL4030_CORE
> +	select I2C
>  
Another option to ensure I2C is selected when
TWL* drivers are selected is let it depends
on I2C. That wat we can avoid patching every
machine entry with I2C option.
Not a strong opinion though.

Regards
Santosh

[PATCH 23/30] ARM: omap2: select twl4030 support on boards that need it

[Arnd Bergmann]

On Monday 03 October 2011 10:49:10 Santosh Shilimkar wrote:
> > diff --git a/arch/arm/mach-omap2/Kconfig b/arch/arm/mach-omap2/Kconfig
> > index 57b66d5..4deeade 100644
> > --- a/arch/arm/mach-omap2/Kconfig
> > +++ b/arch/arm/mach-omap2/Kconfig
> > @@ -253,6 +253,8 @@ config MACH_OMAP_ZOOM2
> >       select SERIAL_CORE_CONSOLE
> >       select SERIAL_8250_CONSOLE
> >       select REGULATOR_FIXED_VOLTAGE
> > +     select TWL4030_CORE
> > +     select I2C
> >  
> Another option to ensure I2C is selected when
> TWL* drivers are selected is let it depends
> on I2C. That wat we can avoid patching every
> machine entry with I2C option.
> Not a strong opinion though.

I generally try to avoid having select statements where a
depends on works fine, as in the generic TWL4030_CORE config.

For platforms that require TWL4030, this does not work, although
it would be better not to have this strict dependency and make
the configuration build if the driver is disabled, even if that
is rather pointless.

	Arnd

[PATCH 23/30] ARM: omap2: select twl4030 support on boards that need it

[Tony Lindgren]

* Arnd Bergmann <arnd@arndb.de> [111002 07:13]:
> These three boards unconditionally use the twl4030 driver
> from the board-zoom-display.c file. Make sure that the driver
> is always there.
> We also need to select the I2C core so we are able to build
> that driver.
> 
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>

Acked-by: Tony Lindgren <tony@atomide.com>

> ---
>  arch/arm/mach-omap2/Kconfig |    6 ++++++
>  1 files changed, 6 insertions(+), 0 deletions(-)
> 
> diff --git a/arch/arm/mach-omap2/Kconfig b/arch/arm/mach-omap2/Kconfig
> index 57b66d5..4deeade 100644
> --- a/arch/arm/mach-omap2/Kconfig
> +++ b/arch/arm/mach-omap2/Kconfig
> @@ -253,6 +253,8 @@ config MACH_OMAP_ZOOM2
>  	select SERIAL_CORE_CONSOLE
>  	select SERIAL_8250_CONSOLE
>  	select REGULATOR_FIXED_VOLTAGE
> +	select TWL4030_CORE
> +	select I2C
>  
>  config MACH_OMAP_ZOOM3
>  	bool "OMAP3630 Zoom3 board"
> @@ -263,6 +265,8 @@ config MACH_OMAP_ZOOM3
>  	select SERIAL_CORE_CONSOLE
>  	select SERIAL_8250_CONSOLE
>  	select REGULATOR_FIXED_VOLTAGE
> +	select TWL4030_CORE
> +	select I2C
>  
>  config MACH_CM_T35
>  	bool "CompuLab CM-T35/CM-T3730 modules"
> @@ -304,6 +308,8 @@ config MACH_OMAP_3630SDP
>  	depends on ARCH_OMAP3
>  	default y
>  	select OMAP_PACKAGE_CBP
> +	select TWL4030_CORE
> +	select I2C
>  
>  config MACH_TI8168EVM
>  	bool "TI8168 Evaluation Module"
> -- 
> 1.7.5.4
> 

[PATCH 24/30] ARM: omap2+: ensure that one of omap2/3/4 is selected

[Arnd Bergmann]

Random configurations can fail if none of the omap families
in mach-omap2 is selected. This patch automatically selects
omap2 if the user has not made any other choice.

Signed-off-by: Arnd Bergmann <arnd@arndb.de>
---
 arch/arm/mach-omap2/Kconfig |   10 ++++++++++
 1 files changed, 10 insertions(+), 0 deletions(-)

diff --git a/arch/arm/mach-omap2/Kconfig b/arch/arm/mach-omap2/Kconfig
index 4deeade..3c9fb89 100644
--- a/arch/arm/mach-omap2/Kconfig
+++ b/arch/arm/mach-omap2/Kconfig
@@ -51,6 +51,16 @@ config ARCH_OMAP4
 	select PM_OPP if PM
 	select USB_ARCH_HAS_EHCI
 
+config ARCH_OMAP2_AUTO
+	bool
+	depends on !ARCH_OMAP3 && !ARCH_OMAP4
+	select ARCH_OMAP2
+	default y
+	help
+	  At least one of OMAP2/OMAP3/OMAP4 needs to be enabled, this
+	  selects OMAP2 if nothing else gets selected, to avoid non-building
+	  configurations.
+
 comment "OMAP Core Type"
 	depends on ARCH_OMAP2
 
-- 
1.7.5.4

[PATCH 24/30] ARM: omap2+: ensure that one of omap2/3/4 is selected

[Santosh Shilimkar]

On Sunday 02 October 2011 08:15 PM, Arnd Bergmann wrote:
> Random configurations can fail if none of the omap families
> in mach-omap2 is selected. This patch automatically selects
> omap2 if the user has not made any other choice.
> 
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> ---

OMAP4 would have been a better default but am fine with
OMAP2 too.

Acked-by: Santosh Shilimkar <santosh.shilimkar@ti.com>

[PATCH 24/30] ARM: omap2+: ensure that one of omap2/3/4 is selected

[Tony Lindgren]

* Santosh Shilimkar <santosh.shilimkar@ti.com> [111002 21:46]:
> On Sunday 02 October 2011 08:15 PM, Arnd Bergmann wrote:
> > Random configurations can fail if none of the omap families
> > in mach-omap2 is selected. This patch automatically selects
> > omap2 if the user has not made any other choice.
> > 
> > Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> > ---
> 
> OMAP4 would have been a better default but am fine with
> OMAP2 too.
> 
> Acked-by: Santosh Shilimkar <santosh.shilimkar@ti.com>

Hmm yeah then that would mean constant patching for the
latest omap.. So OMAP2 here makes the fastest build and
avoids having to update it on regular basis.

Acked-by: Tony Lindgren <tony@atomide.com>

[PATCH 25/30] ARM: OMAP depends on MMU

[Arnd Bergmann]

There is no way to build OMAP kernels without an MMU
at this point because of dependencies on MMU-only functions.

As long as nobody is interested in fixing this, let's just disable
this platforms for nommu kernels.

Signed-off-by: Arnd Bergmann <arnd@arndb.de>
---
 arch/arm/Kconfig |    1 +
 1 files changed, 1 insertions(+), 0 deletions(-)

diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index 5ebc5d9..e688ca4 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -875,6 +875,7 @@ config ARCH_DAVINCI
 
 config ARCH_OMAP
 	bool "TI OMAP"
+	depends on MMU
 	select HAVE_CLK
 	select ARCH_REQUIRE_GPIOLIB
 	select ARCH_HAS_CPUFREQ
-- 
1.7.5.4

[PATCH 25/30] ARM: OMAP depends on MMU

[Santosh Shilimkar]

On Sunday 02 October 2011 08:15 PM, Arnd Bergmann wrote:
> There is no way to build OMAP kernels without an MMU
> at this point because of dependencies on MMU-only functions.
> 
> As long as nobody is interested in fixing this, let's just disable
> this platforms for nommu kernels.
> 
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> ---
Acked-by: Santosh Shilimkar <santosh.shilimkar@ti.com>

[PATCH 25/30] ARM: OMAP depends on MMU

[Tony Lindgren]

* Santosh Shilimkar <santosh.shilimkar@ti.com> [111002 21:47]:
> On Sunday 02 October 2011 08:15 PM, Arnd Bergmann wrote:
> > There is no way to build OMAP kernels without an MMU
> > at this point because of dependencies on MMU-only functions.
> > 
> > As long as nobody is interested in fixing this, let's just disable
> > this platforms for nommu kernels.
> > 
> > Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> > ---
> Acked-by: Santosh Shilimkar <santosh.shilimkar@ti.com>

This should be fine for now:

Acked-by: Tony Lindgren <tony@atomide.com>

[PATCH 26/30] ARM: omap: add board autoselection

[Arnd Bergmann]

At least one board file needs to be selected to successfully build
a kernel, so this one adds logic to the omap Kconfig file to
pick one default board file when all others are disabled. Since
the available boards depend on the SoC family (omap2/3/4) being
selected first, this adds one default for each family.

Signed-off-by: Arnd Bergmann <arnd@arndb.de>
---
 arch/arm/mach-omap2/Kconfig |   39 +++++++++++++++++++++++++++++++++++++++
 1 files changed, 39 insertions(+), 0 deletions(-)

diff --git a/arch/arm/mach-omap2/Kconfig b/arch/arm/mach-omap2/Kconfig
index 3c9fb89..fd0ab18 100644
--- a/arch/arm/mach-omap2/Kconfig
+++ b/arch/arm/mach-omap2/Kconfig
@@ -120,6 +120,45 @@ config MACH_OMAP_GENERIC
 	depends on ARCH_OMAP2
 	default y
 
+config MACH_OMAP_AUTO_BOARD
+	def_bool y
+	depends on !MACH_OMAP2_TUSB6010
+	depends on !MACH_OMAP_H4
+	depends on !MACH_OMAP_APOLLON
+	depends on !MACH_OMAP_APOLLON
+	depends on !MACH_OMAP_2430SDP
+	depends on !MACH_OMAP3_BEAGLE
+	depends on !MACH_DEVKIT8000
+	depends on !MACH_OMAP_LDP
+	depends on !MACH_OMAP3530_LV_SOM
+	depends on !MACH_OMAP3_TORPEDO
+	depends on !MACH_OVERO
+	depends on !MACH_OMAP3EVM
+	depends on !MACH_OMAP3517EVM
+	depends on !MACH_CRANEBOARD
+	depends on !MACH_OMAP3_PANDORA
+	depends on !MACH_OMAP3_TOUCHBOOK
+	depends on !MACH_NOKIA_N8X0
+	depends on !MACH_NOKIA_RM680
+	depends on !MACH_NOKIA_RX51
+	depends on !MACH_OMAP_ZOOM2
+	depends on !MACH_OMAP_ZOOM3
+	depends on !MACH_CM_T35
+	depends on !MACH_CM_T3517
+	depends on !MACH_IGEP0020
+	depends on !MACH_IGEP0030
+	depends on !MACH_SBC3530
+	depends on !MACH_OMAP_3630SDP
+	depends on !MACH_TI8168EVM
+	depends on !MACH_OMAP4_PANDA
+	select MACH_OMAP_GENERIC if ARCH_OMAP2
+	select MACH_OMAP_3430SDP if ARCH_OMAP3 && !ARCH_OMAP2
+	select MACH_OMAP_4430SDP if ARCH_OMAP4 && !ARCH_OMAP3 && !ARCH_OMAP2
+	help
+	  The kernel needs to have support for at least one board
+	  in order to build. If none is selected, default to the
+	  generic board.
+
 config MACH_OMAP2_TUSB6010
 	bool
 	depends on ARCH_OMAP2 && SOC_OMAP2420
-- 
1.7.5.4

[PATCH 26/30] ARM: omap: add board autoselection

[Santosh Shilimkar]

On Sunday 02 October 2011 08:15 PM, Arnd Bergmann wrote:
> At least one board file needs to be selected to successfully build
> a kernel, so this one adds logic to the omap Kconfig file to
> pick one default board file when all others are disabled. Since
> the available boards depend on the SoC family (omap2/3/4) being
> selected first, this adds one default for each family.
> 
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> ---
>  arch/arm/mach-omap2/Kconfig |   39 +++++++++++++++++++++++++++++++++++++++
>  1 files changed, 39 insertions(+), 0 deletions(-)
> 
> diff --git a/arch/arm/mach-omap2/Kconfig b/arch/arm/mach-omap2/Kconfig
> index 3c9fb89..fd0ab18 100644
> --- a/arch/arm/mach-omap2/Kconfig
> +++ b/arch/arm/mach-omap2/Kconfig
> @@ -120,6 +120,45 @@ config MACH_OMAP_GENERIC
>  	depends on ARCH_OMAP2
>  	default y
>  
> +config MACH_OMAP_AUTO_BOARD
> +	def_bool y
> +	depends on !MACH_OMAP2_TUSB6010
> +	depends on !MACH_OMAP_H4
> +	depends on !MACH_OMAP_APOLLON
> +	depends on !MACH_OMAP_APOLLON
> +	depends on !MACH_OMAP_2430SDP
> +	depends on !MACH_OMAP3_BEAGLE
> +	depends on !MACH_DEVKIT8000
> +	depends on !MACH_OMAP_LDP
> +	depends on !MACH_OMAP3530_LV_SOM
> +	depends on !MACH_OMAP3_TORPEDO
> +	depends on !MACH_OVERO
> +	depends on !MACH_OMAP3EVM
> +	depends on !MACH_OMAP3517EVM
> +	depends on !MACH_CRANEBOARD
> +	depends on !MACH_OMAP3_PANDORA
> +	depends on !MACH_OMAP3_TOUCHBOOK
> +	depends on !MACH_NOKIA_N8X0
> +	depends on !MACH_NOKIA_RM680
> +	depends on !MACH_NOKIA_RX51
> +	depends on !MACH_OMAP_ZOOM2
> +	depends on !MACH_OMAP_ZOOM3
> +	depends on !MACH_CM_T35
> +	depends on !MACH_CM_T3517
> +	depends on !MACH_IGEP0020
> +	depends on !MACH_IGEP0030
> +	depends on !MACH_SBC3530
> +	depends on !MACH_OMAP_3630SDP
> +	depends on !MACH_TI8168EVM
> +	depends on !MACH_OMAP4_PANDA
Do we need all above 'depends on *' ?
Even if they get selected for one of the below
ARCH along with default machine, build should be happy.
Right ?

> +	select MACH_OMAP_GENERIC if ARCH_OMAP2
> +	select MACH_OMAP_3430SDP if ARCH_OMAP3 && !ARCH_OMAP2
> +	select MACH_OMAP_4430SDP if ARCH_OMAP4 && !ARCH_OMAP3 && !ARCH_OMAP2
This is fine.
Acked-by: Santosh Shilimkar <santosh.shilimkar@ti.com>

[PATCH 26/30] ARM: omap: add board autoselection

[Arnd Bergmann]

On Monday 03 October 2011 10:58:23 Santosh Shilimkar wrote:
> > +config MACH_OMAP_AUTO_BOARD
> > +     def_bool y
> > +     depends on !MACH_OMAP2_TUSB6010
> > +     depends on !MACH_OMAP_H4
> > +     depends on !MACH_OMAP_APOLLON
> > +     depends on !MACH_OMAP_APOLLON
> > +     depends on !MACH_OMAP_2430SDP
> > +     depends on !MACH_OMAP3_BEAGLE
> > +     depends on !MACH_DEVKIT8000
> > +     depends on !MACH_OMAP_LDP
> > +     depends on !MACH_OMAP3530_LV_SOM
> > +     depends on !MACH_OMAP3_TORPEDO
> > +     depends on !MACH_OVERO
> > +     depends on !MACH_OMAP3EVM
> > +     depends on !MACH_OMAP3517EVM
> > +     depends on !MACH_CRANEBOARD
> > +     depends on !MACH_OMAP3_PANDORA
> > +     depends on !MACH_OMAP3_TOUCHBOOK
> > +     depends on !MACH_NOKIA_N8X0
> > +     depends on !MACH_NOKIA_RM680
> > +     depends on !MACH_NOKIA_RX51
> > +     depends on !MACH_OMAP_ZOOM2
> > +     depends on !MACH_OMAP_ZOOM3
> > +     depends on !MACH_CM_T35
> > +     depends on !MACH_CM_T3517
> > +     depends on !MACH_IGEP0020
> > +     depends on !MACH_IGEP0030
> > +     depends on !MACH_SBC3530
> > +     depends on !MACH_OMAP_3630SDP
> > +     depends on !MACH_TI8168EVM
> > +     depends on !MACH_OMAP4_PANDA
> Do we need all above 'depends on *' ?
> Even if they get selected for one of the below
> ARCH along with default machine, build should be happy.
> Right ?

I'm not too happy with having to maintain a list for each subarchitecture,
when each one has the same problem. In general, I would really like to have
the flexibility to disable all but any one board, which requires either
maintaining a list like the above, or expressing the same like

config MACH_OMAP_AUTO_BOARD
	 def_bool y
       depends on !MACH_OMAP_BOARD_SELECTED
       select MACH_OMAP_GENERIC if ARCH_OMAP2
       select MACH_OMAP_3430SDP if ARCH_OMAP3 && !ARCH_OMAP2
       select MACH_OMAP_4430SDP if ARCH_OMAP4 && !ARCH_OMAP3 && !ARCH_OMAP2

and adding a 'select MACH_OMAP_BOARD_SELECTED' for each one. Slightly more
to write but perhaps a little less error-prone.

In the long run, I'd hope we can just get rid of these for subarchitectures
that support device tree probing and make the device tree based machine
description unconditional.

	Arnd

[PATCH 26/30] ARM: omap: add board autoselection

[Santosh Shilimkar]

On Monday 03 October 2011 02:41 PM, Arnd Bergmann wrote:
> On Monday 03 October 2011 10:58:23 Santosh Shilimkar wrote:
>>> +config MACH_OMAP_AUTO_BOARD
>>> +     def_bool y
>>> +     depends on !MACH_OMAP2_TUSB6010
>>> +     depends on !MACH_OMAP_H4
>>> +     depends on !MACH_OMAP_APOLLON
>>> +     depends on !MACH_OMAP_APOLLON
>>> +     depends on !MACH_OMAP_2430SDP
>>> +     depends on !MACH_OMAP3_BEAGLE
>>> +     depends on !MACH_DEVKIT8000
>>> +     depends on !MACH_OMAP_LDP
>>> +     depends on !MACH_OMAP3530_LV_SOM
>>> +     depends on !MACH_OMAP3_TORPEDO
>>> +     depends on !MACH_OVERO
>>> +     depends on !MACH_OMAP3EVM
>>> +     depends on !MACH_OMAP3517EVM
>>> +     depends on !MACH_CRANEBOARD
>>> +     depends on !MACH_OMAP3_PANDORA
>>> +     depends on !MACH_OMAP3_TOUCHBOOK
>>> +     depends on !MACH_NOKIA_N8X0
>>> +     depends on !MACH_NOKIA_RM680
>>> +     depends on !MACH_NOKIA_RX51
>>> +     depends on !MACH_OMAP_ZOOM2
>>> +     depends on !MACH_OMAP_ZOOM3
>>> +     depends on !MACH_CM_T35
>>> +     depends on !MACH_CM_T3517
>>> +     depends on !MACH_IGEP0020
>>> +     depends on !MACH_IGEP0030
>>> +     depends on !MACH_SBC3530
>>> +     depends on !MACH_OMAP_3630SDP
>>> +     depends on !MACH_TI8168EVM
>>> +     depends on !MACH_OMAP4_PANDA
>> Do we need all above 'depends on *' ?
>> Even if they get selected for one of the below
>> ARCH along with default machine, build should be happy.
>> Right ?
> 
> I'm not too happy with having to maintain a list for each subarchitecture,
> when each one has the same problem. In general, I would really like to have
> the flexibility to disable all but any one board, which requires either
> maintaining a list like the above, or expressing the same like
> 
Ok.

> config MACH_OMAP_AUTO_BOARD
> 	 def_bool y
>        depends on !MACH_OMAP_BOARD_SELECTED
>        select MACH_OMAP_GENERIC if ARCH_OMAP2
>        select MACH_OMAP_3430SDP if ARCH_OMAP3 && !ARCH_OMAP2
>        select MACH_OMAP_4430SDP if ARCH_OMAP4 && !ARCH_OMAP3 && !ARCH_OMAP2
> 
> and adding a 'select MACH_OMAP_BOARD_SELECTED' for each one. Slightly more
> to write but perhaps a little less error-prone.
> 
> In the long run, I'd hope we can just get rid of these for subarchitectures
> that support device tree probing and make the device tree based machine
> description unconditional.
> 
I see your point. Sounds a good idea to me.

Regards
Santosh

[PATCH 26/30] ARM: omap: add board autoselection

[Cousson, Benoit]

On 10/3/2011 11:11 AM, Arnd Bergmann wrote:
> On Monday 03 October 2011 10:58:23 Santosh Shilimkar wrote:
>>> +config MACH_OMAP_AUTO_BOARD
>>> +     def_bool y
>>> +     depends on !MACH_OMAP2_TUSB6010
>>> +     depends on !MACH_OMAP_H4
>>> +     depends on !MACH_OMAP_APOLLON
>>> +     depends on !MACH_OMAP_APOLLON
>>> +     depends on !MACH_OMAP_2430SDP
>>> +     depends on !MACH_OMAP3_BEAGLE
>>> +     depends on !MACH_DEVKIT8000
>>> +     depends on !MACH_OMAP_LDP
>>> +     depends on !MACH_OMAP3530_LV_SOM
>>> +     depends on !MACH_OMAP3_TORPEDO
>>> +     depends on !MACH_OVERO
>>> +     depends on !MACH_OMAP3EVM
>>> +     depends on !MACH_OMAP3517EVM
>>> +     depends on !MACH_CRANEBOARD
>>> +     depends on !MACH_OMAP3_PANDORA
>>> +     depends on !MACH_OMAP3_TOUCHBOOK
>>> +     depends on !MACH_NOKIA_N8X0
>>> +     depends on !MACH_NOKIA_RM680
>>> +     depends on !MACH_NOKIA_RX51
>>> +     depends on !MACH_OMAP_ZOOM2
>>> +     depends on !MACH_OMAP_ZOOM3
>>> +     depends on !MACH_CM_T35
>>> +     depends on !MACH_CM_T3517
>>> +     depends on !MACH_IGEP0020
>>> +     depends on !MACH_IGEP0030
>>> +     depends on !MACH_SBC3530
>>> +     depends on !MACH_OMAP_3630SDP
>>> +     depends on !MACH_TI8168EVM
>>> +     depends on !MACH_OMAP4_PANDA
>> Do we need all above 'depends on *' ?
>> Even if they get selected for one of the below
>> ARCH along with default machine, build should be happy.
>> Right ?
>
> I'm not too happy with having to maintain a list for each subarchitecture,
> when each one has the same problem. In general, I would really like to have
> the flexibility to disable all but any one board, which requires either
> maintaining a list like the above, or expressing the same like
>
> config MACH_OMAP_AUTO_BOARD
> 	 def_bool y
>         depends on !MACH_OMAP_BOARD_SELECTED
>         select MACH_OMAP_GENERIC if ARCH_OMAP2
>         select MACH_OMAP_3430SDP if ARCH_OMAP3&&  !ARCH_OMAP2
>         select MACH_OMAP_4430SDP if ARCH_OMAP4&&  !ARCH_OMAP3&&  !ARCH_OMAP2
>
> and adding a 'select MACH_OMAP_BOARD_SELECTED' for each one. Slightly more
> to write but perhaps a little less error-prone.
>
> In the long run, I'd hope we can just get rid of these for subarchitectures
> that support device tree probing and make the device tree based machine
> description unconditional.

This is really our goal, we will have soon the board-generic.c for that, 
someone will *just* have to migrate these ~30 board files to device tree 
DTS files :-)

Regards,
Benoit

[PATCH 26/30] ARM: omap: add board autoselection

[Arnd Bergmann]

On Monday 03 October 2011 11:27:44 Cousson, Benoit wrote:
> >
> > In the long run, I'd hope we can just get rid of these for subarchitectures
> > that support device tree probing and make the device tree based machine
> > description unconditional.
> 
> This is really our goal, we will have soon the board-generic.c for that, 
> someone will just have to migrate these ~30 board files to device tree 
> DTS files 

For the purpose of build-time validation using randconfig, there is no
problem in keeping some board files forever, as long as the generic board
file is always built-in.

	Arnd

[PATCH 26/30] ARM: omap: add board autoselection

[Tony Lindgren]

* Arnd Bergmann <arnd@arndb.de> [111003 02:20]:
> On Monday 03 October 2011 11:27:44 Cousson, Benoit wrote:
> > >
> > > In the long run, I'd hope we can just get rid of these for subarchitectures
> > > that support device tree probing and make the device tree based machine
> > > description unconditional.
> > 
> > This is really our goal, we will have soon the board-generic.c for that, 
> > someone will just have to migrate these ~30 board files to device tree 
> > DTS files 
> 
> For the purpose of build-time validation using randconfig, there is no
> problem in keeping some board files forever, as long as the generic board
> file is always built-in.

Yes please leave out the list so we don't need to constantly update it.
Let's just always build in MACH_OMAP_GENERIC.

Regards,

Tony

[PATCH 26/30] ARM: omap: add board autoselection

[Arnd Bergmann]

On Monday 03 October 2011, Tony Lindgren wrote:
> * Arnd Bergmann <arnd@arndb.de> [111003 02:20]:
> > On Monday 03 October 2011 11:27:44 Cousson, Benoit wrote:
> > > >
> > > > In the long run, I'd hope we can just get rid of these for subarchitectures
> > > > that support device tree probing and make the device tree based machine
> > > > description unconditional.
> > > 
> > > This is really our goal, we will have soon the board-generic.c for that, 
> > > someone will just have to migrate these ~30 board files to device tree 
> > > DTS files 
> > 
> > For the purpose of build-time validation using randconfig, there is no
> > problem in keeping some board files forever, as long as the generic board
> > file is always built-in.
> 
> Yes please leave out the list so we don't need to constantly update it.
> Let's just always build in MACH_OMAP_GENERIC.

That's what I had initially, but now that board file has become
omap2-specific and no longer works on omap3-only or omap4-only
configurations.

	Arnd

[PATCH 26/30] ARM: omap: add board autoselection

[Tony Lindgren]

* Arnd Bergmann <arnd@arndb.de> [111004 00:10]:
> On Monday 03 October 2011, Tony Lindgren wrote:
> > * Arnd Bergmann <arnd@arndb.de> [111003 02:20]:
> > > On Monday 03 October 2011 11:27:44 Cousson, Benoit wrote:
> > > > >
> > > > > In the long run, I'd hope we can just get rid of these for subarchitectures
> > > > > that support device tree probing and make the device tree based machine
> > > > > description unconditional.
> > > > 
> > > > This is really our goal, we will have soon the board-generic.c for that, 
> > > > someone will just have to migrate these ~30 board files to device tree 
> > > > DTS files 
> > > 
> > > For the purpose of build-time validation using randconfig, there is no
> > > problem in keeping some board files forever, as long as the generic board
> > > file is always built-in.
> > 
> > Yes please leave out the list so we don't need to constantly update it.
> > Let's just always build in MACH_OMAP_GENERIC.
> 
> That's what I had initially, but now that board file has become
> omap2-specific and no longer works on omap3-only or omap4-only
> configurations.

Will send a pull request for basic DT bootstrap support from Benoit
that fixes that. So maybe let's sort that out first, then always
select it?

Regards,

Tony

[PATCH 26/30] ARM: omap: add board autoselection

[Arnd Bergmann]

On Tuesday 04 October 2011 08:57:52 Tony Lindgren wrote:
> * Arnd Bergmann <arnd@arndb.de> [111004 00:10]:
> > On Monday 03 October 2011, Tony Lindgren wrote:
> >
> > > Yes please leave out the list so we don't need to constantly update it.
> > > Let's just always build in MACH_OMAP_GENERIC.
> > 
> > That's what I had initially, but now that board file has become
> > omap2-specific and no longer works on omap3-only or omap4-only
> > configurations.
> 
> Will send a pull request for basic DT bootstrap support from Benoit
> that fixes that. So maybe let's sort that out first, then always
> select it?

Yes, sounds good. That is certainly the better solution in the long run.

	Arnd

[GIT PULL] initial omap DT support for v3.2 merge window (Re: [PATCH 26/30] ARM: omap: add board autoselection)

[Tony Lindgren]

* Arnd Bergmann <arnd@arndb.de> [111004 11:55]:
> On Tuesday 04 October 2011 08:57:52 Tony Lindgren wrote:
> > * Arnd Bergmann <arnd@arndb.de> [111004 00:10]:
> > > On Monday 03 October 2011, Tony Lindgren wrote:
> > >
> > > > Yes please leave out the list so we don't need to constantly update it.
> > > > Let's just always build in MACH_OMAP_GENERIC.
> > > 
> > > That's what I had initially, but now that board file has become
> > > omap2-specific and no longer works on omap3-only or omap4-only
> > > configurations.
> > 
> > Will send a pull request for basic DT bootstrap support from Benoit
> > that fixes that. So maybe let's sort that out first, then always
> > select it?
> 
> Yes, sounds good. That is certainly the better solution in the long run.

Here you are. We had to rebase it earlier today because of the
SOB update in fixes branch for the musb related fix that's needed
here to avoid a merge conflict.

This series pretty much depends and conflicts with all the ealier
branches, so I created a new dt-base branch to deal with the merge
conflicts. If you prefer some other base, please let me know.

If you prefer to build some other merge base yourself, see the
attached patch that's needed to avoid two build warnings after
merging the various base branches together.

The dt-base I did is a merge of cleanup-part3, voltage, dmtimer
and l3 into fixes. You may not yet have l3 and fixes pulled in,
I sent pull requests for those yesterday. The others you have
already pulled I believe.

Despite using the merge base this will cause a minor merge conflict
in board-generic.c with Nicolas Pitre's earlier patch titled
"ARM: mach-omap2: convert boot_params to atag_offset". The 
atag_offset can be just left out, as the default will work.

Regards,

Tony


The following changes since commit c541c15fb5ab48c47bc9b90121538fd30d152f23:
  Tony Lindgren (1):
        Merge branches 'cleanup-part3', 'voltage', 'dmtimer' and 'l3' into dt-base

are available in the git repository at:

  git://github.com/tmlind/linux.git dt

Benoit Cousson (18):
      ARM: OMAP3: beagle-board: Use the omap_hwmod_name_get_dev API
      ARM: OMAP2+: pm: Use hwmod name instead of dev pointer
      ARM: OMAP2+: pm: Remove static devices variable for mpu, dsp, iva and l3 PM
      ARM: OMAP: omap_device: Create a default omap_device_pm_latency
      ARM: OMAP2+: devices: Remove all omap_device_pm_latency structures
      of: Add helpers to get one string in multiple strings property
      ARM: OMAP: omap_device: Add omap_device_[alloc|delete] for DT integration
      ARM: OMAP: omap_device: Add a method to build an omap_device from a DT node
      arm/dts: Add initial device tree support for OMAP4 SoC
      arm/dts: Add support for OMAP4 PandaBoard
      arm/dts: Add support for OMAP4 SDP board
      arm/dts: Add initial device tree support for OMAP3 SoC
      arm/dts: Add support for OMAP3 Beagle board
      ARM: OMAP2+: board-generic: Add DT support to generic board
      ARM: OMAP2+: board-generic: Add i2c static init
      ARM: OMAP2+: l3-noc: Add support for device-tree
      arm/dts: OMAP4: Add a main ocp entry bound to l3-noc driver
      arm/dts: OMAP3+: Add mpu, dsp and iva nodes

Nishanth Menon (1):
      ARM: OMAP: omap_device: Add omap_device_get_by_hwmod_name

Tony Lindgren (1):
      Merge branch 'for_3.2/3_omap_devicetree' of git://gitorious.org/omap-pm/linux into dt

 Documentation/devicetree/bindings/arm/omap/dsp.txt |   14 +
 Documentation/devicetree/bindings/arm/omap/iva.txt |   19 ++
 .../devicetree/bindings/arm/omap/l3-noc.txt        |   19 ++
 Documentation/devicetree/bindings/arm/omap/mpu.txt |   27 ++
 .../devicetree/bindings/arm/omap/omap.txt          |   43 +++
 arch/arm/boot/dts/omap3-beagle.dts                 |   29 ++
 arch/arm/boot/dts/omap3.dtsi                       |   63 ++++
 arch/arm/boot/dts/omap4-panda.dts                  |   29 ++
 arch/arm/boot/dts/omap4-sdp.dts                    |   29 ++
 arch/arm/boot/dts/omap4.dtsi                       |  103 +++++++
 arch/arm/mach-omap2/Kconfig                        |    8 +-
 arch/arm/mach-omap2/board-generic.c                |  156 ++++++++---
 arch/arm/mach-omap2/board-omap3beagle.c            |    4 +-
 arch/arm/mach-omap2/devices.c                      |   51 +---
 arch/arm/mach-omap2/display.c                      |   11 +-
 arch/arm/mach-omap2/dma.c                          |   11 +-
 arch/arm/mach-omap2/gpio.c                         |   12 +-
 arch/arm/mach-omap2/hsmmc.c                        |   18 +-
 arch/arm/mach-omap2/hwspinlock.c                   |   12 +-
 arch/arm/mach-omap2/mcbsp.c                        |   11 +-
 arch/arm/mach-omap2/omap_l3_noc.c                  |   25 ++-
 arch/arm/mach-omap2/pm.c                           |   72 ++---
 arch/arm/mach-omap2/serial.c                       |   25 +--
 arch/arm/mach-omap2/sr_device.c                    |   11 +-
 arch/arm/mach-omap2/usb-musb.c                     |   11 +-
 arch/arm/plat-omap/i2c.c                           |   10 +-
 arch/arm/plat-omap/include/plat/omap_device.h      |    1 +
 arch/arm/plat-omap/omap_device.c                   |  313 +++++++++++++++++---
 drivers/of/base.c                                  |   84 ++++++
 include/linux/of.h                                 |   18 ++
 30 files changed, 929 insertions(+), 310 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/arm/omap/dsp.txt
 create mode 100644 Documentation/devicetree/bindings/arm/omap/iva.txt
 create mode 100644 Documentation/devicetree/bindings/arm/omap/l3-noc.txt
 create mode 100644 Documentation/devicetree/bindings/arm/omap/mpu.txt
 create mode 100644 Documentation/devicetree/bindings/arm/omap/omap.txt
 create mode 100644 arch/arm/boot/dts/omap3-beagle.dts
 create mode 100644 arch/arm/boot/dts/omap3.dtsi
 create mode 100644 arch/arm/boot/dts/omap4-panda.dts
 create mode 100644 arch/arm/boot/dts/omap4-sdp.dts
 create mode 100644 arch/arm/boot/dts/omap4.dtsi
-------------- next part --------------
A non-text attachment was scrubbed...
Name: merge.patch
Type: text/x-diff
Size: 2136 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20111004/30d6c319/attachment-0001.bin>

[GIT PULL] initial omap DT support for v3.2 merge window (Re: [PATCH 26/30] ARM: omap: add board autoselection)

[Tony Lindgren]

Arnd,

* Tony Lindgren <tony@atomide.com> [111004 17:32]:
> * Arnd Bergmann <arnd@arndb.de> [111004 11:55]:
> > On Tuesday 04 October 2011 08:57:52 Tony Lindgren wrote:
> > > * Arnd Bergmann <arnd@arndb.de> [111004 00:10]:
> > > > On Monday 03 October 2011, Tony Lindgren wrote:
> > > >
> > > > > Yes please leave out the list so we don't need to constantly update it.
> > > > > Let's just always build in MACH_OMAP_GENERIC.
> > > > 
> > > > That's what I had initially, but now that board file has become
> > > > omap2-specific and no longer works on omap3-only or omap4-only
> > > > configurations.
> > > 
> > > Will send a pull request for basic DT bootstrap support from Benoit
> > > that fixes that. So maybe let's sort that out first, then always
> > > select it?
> > 
> > Yes, sounds good. That is certainly the better solution in the long run.
> 
> Here you are. We had to rebase it earlier today because of the
> SOB update in fixes branch for the musb related fix that's needed
> here to avoid a merge conflict.
> 
> This series pretty much depends and conflicts with all the ealier
> branches, so I created a new dt-base branch to deal with the merge
> conflicts. If you prefer some other base, please let me know.
> 
> If you prefer to build some other merge base yourself, see the
> attached patch that's needed to avoid two build warnings after
> merging the various base branches together.
> 
> The dt-base I did is a merge of cleanup-part3, voltage, dmtimer
> and l3 into fixes. You may not yet have l3 and fixes pulled in,
> I sent pull requests for those yesterday. The others you have
> already pulled I believe.
> 
> Despite using the merge base this will cause a minor merge conflict
> in board-generic.c with Nicolas Pitre's earlier patch titled
> "ARM: mach-omap2: convert boot_params to atag_offset". The 
> atag_offset can be just left out, as the default will work.

Ping, any news on merging these? It would be nice to get these out of
the way so we have something to base other branches on without having
constant merge conflicts.
 
> Regards,
> 
> Tony
> 
> 
> The following changes since commit c541c15fb5ab48c47bc9b90121538fd30d152f23:
>   Tony Lindgren (1):
>         Merge branches 'cleanup-part3', 'voltage', 'dmtimer' and 'l3' into dt-base
> 
> are available in the git repository at:
> 
>   git://github.com/tmlind/linux.git dt
> 
> Benoit Cousson (18):
>       ARM: OMAP3: beagle-board: Use the omap_hwmod_name_get_dev API
>       ARM: OMAP2+: pm: Use hwmod name instead of dev pointer
>       ARM: OMAP2+: pm: Remove static devices variable for mpu, dsp, iva and l3 PM
>       ARM: OMAP: omap_device: Create a default omap_device_pm_latency
>       ARM: OMAP2+: devices: Remove all omap_device_pm_latency structures
>       of: Add helpers to get one string in multiple strings property
>       ARM: OMAP: omap_device: Add omap_device_[alloc|delete] for DT integration
>       ARM: OMAP: omap_device: Add a method to build an omap_device from a DT node
>       arm/dts: Add initial device tree support for OMAP4 SoC
>       arm/dts: Add support for OMAP4 PandaBoard
>       arm/dts: Add support for OMAP4 SDP board
>       arm/dts: Add initial device tree support for OMAP3 SoC
>       arm/dts: Add support for OMAP3 Beagle board
>       ARM: OMAP2+: board-generic: Add DT support to generic board
>       ARM: OMAP2+: board-generic: Add i2c static init
>       ARM: OMAP2+: l3-noc: Add support for device-tree
>       arm/dts: OMAP4: Add a main ocp entry bound to l3-noc driver
>       arm/dts: OMAP3+: Add mpu, dsp and iva nodes
> 
> Nishanth Menon (1):
>       ARM: OMAP: omap_device: Add omap_device_get_by_hwmod_name
> 
> Tony Lindgren (1):
>       Merge branch 'for_3.2/3_omap_devicetree' of git://gitorious.org/omap-pm/linux into dt
> 
>  Documentation/devicetree/bindings/arm/omap/dsp.txt |   14 +
>  Documentation/devicetree/bindings/arm/omap/iva.txt |   19 ++
>  .../devicetree/bindings/arm/omap/l3-noc.txt        |   19 ++
>  Documentation/devicetree/bindings/arm/omap/mpu.txt |   27 ++
>  .../devicetree/bindings/arm/omap/omap.txt          |   43 +++
>  arch/arm/boot/dts/omap3-beagle.dts                 |   29 ++
>  arch/arm/boot/dts/omap3.dtsi                       |   63 ++++
>  arch/arm/boot/dts/omap4-panda.dts                  |   29 ++
>  arch/arm/boot/dts/omap4-sdp.dts                    |   29 ++
>  arch/arm/boot/dts/omap4.dtsi                       |  103 +++++++
>  arch/arm/mach-omap2/Kconfig                        |    8 +-
>  arch/arm/mach-omap2/board-generic.c                |  156 ++++++++---
>  arch/arm/mach-omap2/board-omap3beagle.c            |    4 +-
>  arch/arm/mach-omap2/devices.c                      |   51 +---
>  arch/arm/mach-omap2/display.c                      |   11 +-
>  arch/arm/mach-omap2/dma.c                          |   11 +-
>  arch/arm/mach-omap2/gpio.c                         |   12 +-
>  arch/arm/mach-omap2/hsmmc.c                        |   18 +-
>  arch/arm/mach-omap2/hwspinlock.c                   |   12 +-
>  arch/arm/mach-omap2/mcbsp.c                        |   11 +-
>  arch/arm/mach-omap2/omap_l3_noc.c                  |   25 ++-
>  arch/arm/mach-omap2/pm.c                           |   72 ++---
>  arch/arm/mach-omap2/serial.c                       |   25 +--
>  arch/arm/mach-omap2/sr_device.c                    |   11 +-
>  arch/arm/mach-omap2/usb-musb.c                     |   11 +-
>  arch/arm/plat-omap/i2c.c                           |   10 +-
>  arch/arm/plat-omap/include/plat/omap_device.h      |    1 +
>  arch/arm/plat-omap/omap_device.c                   |  313 +++++++++++++++++---
>  drivers/of/base.c                                  |   84 ++++++
>  include/linux/of.h                                 |   18 ++
>  30 files changed, 929 insertions(+), 310 deletions(-)
>  create mode 100644 Documentation/devicetree/bindings/arm/omap/dsp.txt
>  create mode 100644 Documentation/devicetree/bindings/arm/omap/iva.txt
>  create mode 100644 Documentation/devicetree/bindings/arm/omap/l3-noc.txt
>  create mode 100644 Documentation/devicetree/bindings/arm/omap/mpu.txt
>  create mode 100644 Documentation/devicetree/bindings/arm/omap/omap.txt
>  create mode 100644 arch/arm/boot/dts/omap3-beagle.dts
>  create mode 100644 arch/arm/boot/dts/omap3.dtsi
>  create mode 100644 arch/arm/boot/dts/omap4-panda.dts
>  create mode 100644 arch/arm/boot/dts/omap4-sdp.dts
>  create mode 100644 arch/arm/boot/dts/omap4.dtsi

> --- a/arch/arm/mach-omap2/timer.c
> +++ b/arch/arm/mach-omap2/timer.c
> @@ -434,7 +434,7 @@ static int __init omap_timer_init(struct omap_hwmod *oh, void *unused)
>  	int ret = 0;
>  	char *name = "omap_timer";
>  	struct dmtimer_platform_data *pdata;
> -	struct omap_device *od;
> +	struct platform_device *pdev;
>  	struct omap_timer_capability_dev_attr *timer_dev_attr;
>  	struct powerdomain *pwrdm;
>  
> @@ -476,12 +476,12 @@ static int __init omap_timer_init(struct omap_hwmod *oh, void *unused)
>  #ifdef CONFIG_PM
>  	pdata->get_context_loss_count = omap_pm_get_dev_context_loss_count;
>  #endif
> -	od = omap_device_build(name, id, oh, pdata, sizeof(*pdata),
> +	pdev = omap_device_build(name, id, oh, pdata, sizeof(*pdata),
>  			omap2_dmtimer_latency,
>  			ARRAY_SIZE(omap2_dmtimer_latency),
>  			0);
>  
> -	if (IS_ERR(od)) {
> +	if (IS_ERR(pdev)) {
>  		pr_err("%s: Can't build omap_device for %s: %s.\n",
>  			__func__, name, oh->name);
>  		ret = -EINVAL;
> --- a/arch/arm/mach-omap2/usb-musb.c
> +++ b/arch/arm/mach-omap2/usb-musb.c
> @@ -115,7 +115,6 @@ static struct omap_musb_board_data musb_default_board_data = {
>  void __init usb_musb_init(struct omap_musb_board_data *musb_board_data)
>  {
>  	struct omap_hwmod		*oh;
> -	struct omap_device		*od;
>  	struct platform_device		*pdev;
>  	struct device			*dev;
>  	int				bus_id = -1;
> @@ -145,22 +144,20 @@ void __init usb_musb_init(struct omap_musb_board_data *musb_board_data)
>  		name = "musb-omap2430";
>  	}
>  
> -	oh = omap_hwmod_lookup(oh_name);
> -	if (!oh) {
> -		pr_err("Could not look up %s\n", oh_name);
> -		return;
> -	}
> +        oh = omap_hwmod_lookup(oh_name);
> +        if (WARN(!oh, "%s: could not find omap_hwmod for %s\n",
> +                 __func__, oh_name))
> +                return;
>  
> -	od = omap_device_build(name, bus_id, oh, &musb_plat,
> +	pdev = omap_device_build(name, bus_id, oh, &musb_plat,
>  			       sizeof(musb_plat), omap_musb_latency,
>  			       ARRAY_SIZE(omap_musb_latency), false);
> -	if (IS_ERR(od)) {
> +	if (IS_ERR(pdev)) {
>  		pr_err("Could not build omap_device for %s %s\n",
>  						name, oh_name);
>  		return;
>  	}
>  
> -	pdev = &od->pdev;
>  	dev = &pdev->dev;
>  	get_device(dev);
>  	dev->dma_mask = &musb_dmamask;

[PATCH 27/30] ARM: omap: select L2X0 cache on omap4

[Arnd Bergmann]

The cache controller needs to be enabled for the
cortex-a9 specific errata that are also selected
to work.

Signed-off-by: Arnd Bergmann <arnd@arndb.de>
---
 arch/arm/mach-omap2/Kconfig |    1 +
 1 files changed, 1 insertions(+), 0 deletions(-)

diff --git a/arch/arm/mach-omap2/Kconfig b/arch/arm/mach-omap2/Kconfig
index fd0ab18..3921a95 100644
--- a/arch/arm/mach-omap2/Kconfig
+++ b/arch/arm/mach-omap2/Kconfig
@@ -47,6 +47,7 @@ config ARCH_OMAP4
 	select PL310_ERRATA_588369
 	select PL310_ERRATA_727915
 	select ARM_ERRATA_720789
+	select CACHE_L2X0
 	select ARCH_HAS_OPP
 	select PM_OPP if PM
 	select USB_ARCH_HAS_EHCI
-- 
1.7.5.4

[PATCH 27/30] ARM: omap: select L2X0 cache on omap4

[Santosh Shilimkar]

On Sunday 02 October 2011 08:15 PM, Arnd Bergmann wrote:
> The cache controller needs to be enabled for the
> cortex-a9 specific errata that are also selected
> to work.
> 
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Acked-by: Santosh Shilimkar <santosh.shilimkar@ti.com>	

[PATCH 27/30] ARM: omap: select L2X0 cache on omap4

[Tony Lindgren]

* Santosh Shilimkar <santosh.shilimkar@ti.com> [111002 21:55]:
> On Sunday 02 October 2011 08:15 PM, Arnd Bergmann wrote:
> > The cache controller needs to be enabled for the
> > cortex-a9 specific errata that are also selected
> > to work.
> > 
> > Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> Acked-by: Santosh Shilimkar <santosh.shilimkar@ti.com>	

Acked-by: Tony Lindgren <tony@atomide.com>

[PATCH 28/30] ARM: omap: select CPU_FREQ_TABLE where needed

[Arnd Bergmann]

The omap platform requires CPU_FREQ_TABLE support to be enabled for its
CPU_FREQ implementations, so automatically select that when CPU_FREQ
is enabled.

Signed-off-by: Arnd Bergmann <arnd@arndb.de>
---
 arch/arm/plat-omap/Kconfig |    5 +++++
 1 files changed, 5 insertions(+), 0 deletions(-)

diff --git a/arch/arm/plat-omap/Kconfig b/arch/arm/plat-omap/Kconfig
index bb8f4a6..f7ef9f4 100644
--- a/arch/arm/plat-omap/Kconfig
+++ b/arch/arm/plat-omap/Kconfig
@@ -217,6 +217,11 @@ config OMAP_PM_NOOP
 
 endchoice
 
+config OMAP_CPU_FREQ
+	def_bool "y"
+	depends on CPU_FREQ
+	select CPU_FREQ_TABLE
+
 endmenu
 
 endif
-- 
1.7.5.4

[PATCH 28/30] ARM: omap: select CPU_FREQ_TABLE where needed

[Santosh Shilimkar]

On Sunday 02 October 2011 08:15 PM, Arnd Bergmann wrote:
> The omap platform requires CPU_FREQ_TABLE support to be enabled for its
> CPU_FREQ implementations, so automatically select that when CPU_FREQ
> is enabled.
> 
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> ---
>  arch/arm/plat-omap/Kconfig |    5 +++++
>  1 files changed, 5 insertions(+), 0 deletions(-)
> 
> diff --git a/arch/arm/plat-omap/Kconfig b/arch/arm/plat-omap/Kconfig
> index bb8f4a6..f7ef9f4 100644
> --- a/arch/arm/plat-omap/Kconfig
> +++ b/arch/arm/plat-omap/Kconfig
> @@ -217,6 +217,11 @@ config OMAP_PM_NOOP
>  
>  endchoice
>  
> +config OMAP_CPU_FREQ
> +	def_bool "y"
> +	depends on CPU_FREQ
> +	select CPU_FREQ_TABLE
> +
>  endmenu
With CPUFREQ series from Kevin [1], I don't think we need this any-more.
More so, I didn't find OMAP_CPU_FREQ is being used anywhere on mainline.

Regards
Santosh
[1] http://www.mail-archive.com/linux-omap at vger.kernel.org/msg56288.html

[PATCH 28/30] ARM: omap: select CPU_FREQ_TABLE where needed

[Arnd Bergmann]

On Monday 03 October 2011 11:09:33 Santosh Shilimkar wrote:
> > diff --git a/arch/arm/plat-omap/Kconfig b/arch/arm/plat-omap/Kconfig
> > index bb8f4a6..f7ef9f4 100644
> > --- a/arch/arm/plat-omap/Kconfig
> > +++ b/arch/arm/plat-omap/Kconfig
> > @@ -217,6 +217,11 @@ config OMAP_PM_NOOP
> >  
> >  endchoice
> >  
> > +config OMAP_CPU_FREQ
> > +     def_bool "y"
> > +     depends on CPU_FREQ
> > +     select CPU_FREQ_TABLE
> > +
> >  endmenu
> With CPUFREQ series from Kevin [1], I don't think we need this any-more.

I guess if it's needed, it should at least be moved to the new cpufreq
location.

> More so, I didn't find OMAP_CPU_FREQ is being used anywhere on mainline.

Yes, OMAP_CPU_FREQ is a symbol that is intentionally unused, with the
only purpose of selecting CPU_FREQ_TABLE if any omap platform together
with CPU_FREQ is enabled.

Let's drop this patch for now, if it is still needed as I think, I can
do a patch during the 3.2 cycle for the right location.

	Arnd

[PATCH 28/30] ARM: omap: select CPU_FREQ_TABLE where needed

[Santosh Shilimkar]

On Monday 03 October 2011 02:45 PM, Arnd Bergmann wrote:
> On Monday 03 October 2011 11:09:33 Santosh Shilimkar wrote:
>>> diff --git a/arch/arm/plat-omap/Kconfig b/arch/arm/plat-omap/Kconfig
>>> index bb8f4a6..f7ef9f4 100644
>>> --- a/arch/arm/plat-omap/Kconfig
>>> +++ b/arch/arm/plat-omap/Kconfig
>>> @@ -217,6 +217,11 @@ config OMAP_PM_NOOP
>>>  
>>>  endchoice
>>>  
>>> +config OMAP_CPU_FREQ
>>> +     def_bool "y"
>>> +     depends on CPU_FREQ
>>> +     select CPU_FREQ_TABLE
>>> +
>>>  endmenu
>> With CPUFREQ series from Kevin [1], I don't think we need this any-more.
> 
> I guess if it's needed, it should at least be moved to the new cpufreq
> location.
> 
Probably you are right. CPU_FREQ_TABLE is selected today if
CPU_FREQ_STAT or CPU_FREQ_GOV_ONDEMAND is selected. Without these two
enabled, in won't be selected.

>> More so, I didn't find OMAP_CPU_FREQ is being used anywhere on mainline.
> 
> Yes, OMAP_CPU_FREQ is a symbol that is intentionally unused, with the
> only purpose of selecting CPU_FREQ_TABLE if any omap platform together
> with CPU_FREQ is enabled.
>
I see. This wasn't clear to me.

> Let's drop this patch for now, if it is still needed as I think, I can
> do a patch during the 3.2 cycle for the right location.
> 
Ok.

Regards
Santosh

[PATCH 29/30] ARM: omap: select USB_ARCH_HAS_EHCI only when USB is enabled

[Arnd Bergmann]

This avoids a warning from Kconfig about missing dependencies.

Signed-off-by: Arnd Bergmann <arnd@arndb.de>
---
 arch/arm/mach-omap2/Kconfig |    4 ++--
 1 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/arch/arm/mach-omap2/Kconfig b/arch/arm/mach-omap2/Kconfig
index 3921a95..fdd45dd 100644
--- a/arch/arm/mach-omap2/Kconfig
+++ b/arch/arm/mach-omap2/Kconfig
@@ -32,7 +32,7 @@ config ARCH_OMAP3
 	depends on ARCH_OMAP2PLUS
 	default y
 	select CPU_V7
-	select USB_ARCH_HAS_EHCI
+	select USB_ARCH_HAS_EHCI if USB_SUPPORT
 	select ARM_L1_CACHE_SHIFT_6 if !ARCH_OMAP4
 	select ARCH_HAS_OPP
 	select PM_OPP if PM
@@ -50,7 +50,7 @@ config ARCH_OMAP4
 	select CACHE_L2X0
 	select ARCH_HAS_OPP
 	select PM_OPP if PM
-	select USB_ARCH_HAS_EHCI
+	select USB_ARCH_HAS_EHCI if USB_SUPPORT
 
 config ARCH_OMAP2_AUTO
 	bool
-- 
1.7.5.4

[PATCH 29/30] ARM: omap: select USB_ARCH_HAS_EHCI only when USB is enabled

[Tony Lindgren]

* Arnd Bergmann <arnd@arndb.de> [111002 07:13]:
> This avoids a warning from Kconfig about missing dependencies.
> 
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>

Acked-by: Tony Lindgren <tony@atomide.com>

> ---
>  arch/arm/mach-omap2/Kconfig |    4 ++--
>  1 files changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/arch/arm/mach-omap2/Kconfig b/arch/arm/mach-omap2/Kconfig
> index 3921a95..fdd45dd 100644
> --- a/arch/arm/mach-omap2/Kconfig
> +++ b/arch/arm/mach-omap2/Kconfig
> @@ -32,7 +32,7 @@ config ARCH_OMAP3
>  	depends on ARCH_OMAP2PLUS
>  	default y
>  	select CPU_V7
> -	select USB_ARCH_HAS_EHCI
> +	select USB_ARCH_HAS_EHCI if USB_SUPPORT
>  	select ARM_L1_CACHE_SHIFT_6 if !ARCH_OMAP4
>  	select ARCH_HAS_OPP
>  	select PM_OPP if PM
> @@ -50,7 +50,7 @@ config ARCH_OMAP4
>  	select CACHE_L2X0
>  	select ARCH_HAS_OPP
>  	select PM_OPP if PM
> -	select USB_ARCH_HAS_EHCI
> +	select USB_ARCH_HAS_EHCI if USB_SUPPORT
>  
>  config ARCH_OMAP2_AUTO
>  	bool
> -- 
> 1.7.5.4
> 

[PATCH 30/30] ARM: omap2: select ARM_AMBA for OMAP3_EMU

[Arnd Bergmann]

OMAP3_EMU needs OC_ETM, which needs ARM_AMBA. Since the latter
dependency is getting turned from a 'select' into a 'depends',
omap has to select ARM_AMBA itself in order to have a correct
dependency chain. Alternatively, we could change OMAP3_EMU
to have a 'depends on OC_ETM' instead of selecting it.

Signed-off-by: Arnd Bergmann <arnd@arndb.de>
---
 arch/arm/mach-omap2/Kconfig |    1 +
 1 files changed, 1 insertions(+), 0 deletions(-)

diff --git a/arch/arm/mach-omap2/Kconfig b/arch/arm/mach-omap2/Kconfig
index fdd45dd..12ae86e 100644
--- a/arch/arm/mach-omap2/Kconfig
+++ b/arch/arm/mach-omap2/Kconfig
@@ -386,6 +386,7 @@ config OMAP3_EMU
 	bool "OMAP3 debugging peripherals"
 	depends on ARCH_OMAP3
 	select OC_ETM
+	select ARM_AMBA
 	help
 	  Say Y here to enable debugging hardware of omap3
 
-- 
1.7.5.4

[PATCH 30/30] ARM: omap2: select ARM_AMBA for OMAP3_EMU

[Santosh Shilimkar]

On Sunday 02 October 2011 08:16 PM, Arnd Bergmann wrote:
> OMAP3_EMU needs OC_ETM, which needs ARM_AMBA. Since the latter
> dependency is getting turned from a 'select' into a 'depends',
> omap has to select ARM_AMBA itself in order to have a correct
> dependency chain. Alternatively, we could change OMAP3_EMU
> to have a 'depends on OC_ETM' instead of selecting it.
> 
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Acked-by: Santosh Shilimkar <santosh.shilimkar@ti.com>

[PATCH 30/30] ARM: omap2: select ARM_AMBA for OMAP3_EMU

[Tony Lindgren]

* Santosh Shilimkar <santosh.shilimkar@ti.com> [111002 21:58]:
> On Sunday 02 October 2011 08:16 PM, Arnd Bergmann wrote:
> > OMAP3_EMU needs OC_ETM, which needs ARM_AMBA. Since the latter
> > dependency is getting turned from a 'select' into a 'depends',
> > omap has to select ARM_AMBA itself in order to have a correct
> > dependency chain. Alternatively, we could change OMAP3_EMU
> > to have a 'depends on OC_ETM' instead of selecting it.
> > 
> > Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> Acked-by: Santosh Shilimkar <santosh.shilimkar@ti.com>

Acked-by: Tony Lindgren <tony@atomide.com>

[PATCH 00/30] ARM/omap: omap specific randconfig fixes

[Santosh Shilimkar]

Arnd,

On Sunday 02 October 2011 08:15 PM, Arnd Bergmann wrote:
> Hi Tony,
> 
> I've mentioned these patches before, and now I've managed to
> go through them again and clean them enough for submission.
> 
> If nobody has any objections, I would like to send them to
> Linus in the coming merge window, otherwise it would be nice
> if you could pick the ones that look good to you and send
> me a pull request. If any of these look like they should be
> backported to stable kernels, please tell me and I'll add
> a cc:stable at k.o tag.
> 
> The entire set is also available from
>  git pull git://git.linaro.org/people/arnd/arm-soc.git randconfig/omap
> 
> but I have not yet pulled them into the for-next branch.
> 
Do you have any scripts to create these randconfigs ?
These are useful to run on newer set of patches also to get all
builds right first place.

Regards
Santosh

[PATCH 00/30] ARM/omap: omap specific randconfig fixes

[Arnd Bergmann]

On Monday 03 October 2011 10:35:25 Santosh Shilimkar wrote:

> > The entire set is also available from
> >  git pull git://git.linaro.org/people/arnd/arm-soc.git randconfig/omap
> > 
> > but I have not yet pulled them into the for-next branch.
> > 
> Do you have any scripts to create these randconfigs ?
> These are useful to run on newer set of patches also to get all
> builds right first place.

Yes, see the for-next+randconfig branch of
git://git.linaro.org/people/arnd/arm-soc.git. It has all my patches
and a randconfig.sh script.

Right now, I'm trying to get a baseline upstream, since I have around 150
patches that are needed to always build ten platforms successfully.

The main problem is that you basically need all the patches I did in order
to find regressions, and some of the device driver patches are not currently
in a state where I could submit them. I hope that by the time of the 3.3
merge window, I have enough patches upstream that you no longer need to
pull in an extra tree.

Thanks a lot for your review of the omap set!

	Arnd

[PATCH 00/30] ARM/omap: omap specific randconfig fixes

[Santosh Shilimkar]

On Monday 03 October 2011 02:52 PM, Arnd Bergmann wrote:
> On Monday 03 October 2011 10:35:25 Santosh Shilimkar wrote:
> 
>>> The entire set is also available from
>>>  git pull git://git.linaro.org/people/arnd/arm-soc.git randconfig/omap
>>>
>>> but I have not yet pulled them into the for-next branch.
>>>
>> Do you have any scripts to create these randconfigs ?
>> These are useful to run on newer set of patches also to get all
>> builds right first place.
> 
> Yes, see the for-next+randconfig branch of
> git://git.linaro.org/people/arnd/arm-soc.git. It has all my patches
> and a randconfig.sh script.
> 
> Right now, I'm trying to get a baseline upstream, since I have around 150
> patches that are needed to always build ten platforms successfully.
>
Ok. Will have a look at it.

> The main problem is that you basically need all the patches I did in order
> to find regressions, and some of the device driver patches are not currently
> in a state where I could submit them. I hope that by the time of the 3.3
> merge window, I have enough patches upstream that you no longer need to
> pull in an extra tree.
> 
Sounds like a plan and having these scripts working on mainline kernel
would be really great to test new set dependencies.

Thanks a lot for the patches.

Segards
Santosh

[PATCH 00/30] ARM/omap: omap specific randconfig fixes

[Tony Lindgren]

* Santosh Shilimkar <santosh.shilimkar@ti.com> [111003 02:08]:
> On Monday 03 October 2011 02:52 PM, Arnd Bergmann wrote:
> 
> > The main problem is that you basically need all the patches I did in order
> > to find regressions, and some of the device driver patches are not currently
> > in a state where I could submit them. I hope that by the time of the 3.3
> > merge window, I have enough patches upstream that you no longer need to
> > pull in an extra tree.
> > 
> Sounds like a plan and having these scripts working on mainline kernel
> would be really great to test new set dependencies.
> 
> Thanks a lot for the patches.

Thanks Arnd, this is really nice!

Tony