ARM: OMAP2+: hwmod code/data: fix 32K sync timer

Kevin discovered that commit c8d82ff68fb6873691536cf33021977efbf5593c
("ARM: OMAP2/3: hwmod data: Add 32k-sync timer data to hwmod
database") broke CORE idle on OMAP3, which prevents device low power
states.  The root cause is that the 32K sync timer IP block does not
support smart-idle mode[1], and so the hwmod code keeps the IP block
in no-idle mode while it is active.  The IP block must stay
perpetually active since it is used as an MMIO clocksource, so there
is no opportunity to implement PM runtime-based IP block control
without implementing a custom clocksource.  The pm34xx.c code could
have forced the IP block idle before entering WFI, but did not -- but
this would not have been an acceptable approach since we are trying to
remove this type of centralized IP block idle control.

All this prevents the WKUP clockdomain from transitioning to idle.
Furthermore, since there is a hardcoded sleep dependency that prevents
the CORE_L3 and CORE_CM clockdomains from transitioning to idle when
the WKUP clockdomain is active[2], this keeps the CORE active.  This
in turn blocks chip low-power modes.

Fix by defining a new hwmod flag, HWMOD_ALWAYS_FORCE_SIDLE, that
places the IP block into target force-idle mode even when enabled.
This works for the 32k sync timer since the PRCM only asserts the
SIdleReq line to the 32k sync timer when the WKUP clockdomain is able
to enter idle, and this can only happen when the CORE clockdomains can
enter idle.  This can only happen when the kernel is not running.

This patch is effectively a workaround for a hardware oversight.  A
better approach in the hardware would have been to implement a
smart-idle target idle mode for this IP block.  The smart-idle mode in
this case would behave identically to the force-idle mode.  This would
have removed the need for this software workaround since the
force-idle and no-idle target idle mode settings were intended for
debugging and hardware bug workarounds only.

Another strategy that was considered would have been to implement PM
runtime-based control around 32k sync timer accesses, and to implement
a custom clocksource for this IP block.  While theoretically correct,
due to the simplicity of this IP block, the result would have been the
addition of useless lines of code with no practical benefit, and a
needless expenditure of CPU cycles and power.

This patch is a collaboration between Kevin Hilman <khilman@ti.com>
and Paul Walmsley <paul@pwsan.com>.

Footnotes:

1. Table 16-96 "REG_32KSYNCNT_SYSCONFIG" of the OMAP34xx TRM Rev. ZU
   (SWPU223U), available from:
   http://www.ti.com/pdfs/wtbu/OMAP34x_ES3.1.x_PUBLIC_TRM_vzU.zip

2. Table 4-72 "Sleep Dependencies" of the OMAP34xx TRM Rev. ZU
   (SWPU223U)

Cc: Tony Lindgren <tony@atomide.com>
Cc: Vaibhav Hiremath <hvaibhav@ti.com>

XXX Update autogen scripts
mmc: host: enable OMAP DMA engine support for omap hosts by default

The OMAP MMC and OMAP High Speed MMC hosts now use entirely the DMA
engine API instead of the previous private DMA API implementation.

So, if the kernel is built with support for any of these hosts but it
doesn't support DMA devices nor OMAP DMA support, it fails when trying
to obtain a DMA channel which leads to the following error on an OMAP3
IGEPv2 Rev.C board (and probably on most OMAP boards with MMC support):

[    2.199981] omap_hsmmc omap_hsmmc.1: unable to obtain RX DMA engine channel 48
[    2.215087] omap_hsmmc omap_hsmmc.0: unable to obtain RX DMA engine channel 62

selecting automatically CONFIG_DMADEVICES and CONFIG_DMA_OMAP solves it.

While being there, also update drivers/spi/spi-omap2-mcspi which has been
ported to DMA engine API too.

Signed-off-by: Javier Martinez Canillas <javier@dowhile0.org>
Acked-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
bbxm: Save default config for posterity
musb: Introduce mailbox helper

When MUSB_OMAP2 is compiled as a module while the musb mailbox callers are
not build fails. Introduce a helper to get around the problem.

Conflicts:
	drivers/usb/musb/omap2430.c
musb: Kill __init from function that are called at other times as well.

Marking functions as __init or __devinit and calling them at other times
leads to predictable crashes (if you're lucky).

Remove them for now.

Conflicts:
	drivers/usb/musb/musb_core.c
	drivers/usb/musb/musb_dma.h
	drivers/usb/musb/musbhsdma.c