ARM: OMAP4: hwmod data: do not enable or reset the McPDM during kernel init
authorPaul Walmsley <paul@pwsan.com>
Tue, 30 Oct 2012 04:02:14 +0000 (22:02 -0600)
committerPaul Walmsley <paul@pwsan.com>
Wed, 31 Oct 2012 11:02:31 +0000 (05:02 -0600)
commitbc05244e65f26b7b6f87e0964bfe277803914ed9
tree580cf45916980fa725cfd3e346ab69ae4f0587fb
parent5fb3d522efca4b3a369040d37d1380103411db74
ARM: OMAP4: hwmod data: do not enable or reset the McPDM during kernel init

Resolve this kernel boot message:

omap_hwmod: mcpdm: cannot be enabled for reset (3)

The McPDM on OMAP4 can only receive its functional clock from an
off-chip source.  This source is not guaranteed to be present on the
board, and when present, it is controlled by I2C.  This would
introduce a board dependency to the early hwmod code which it was not
designed to handle.  Also, neither the driver for this off-chip clock
provider nor the I2C code is available early in boot when the hwmod
code is attempting to enable and reset IP blocks.  This effectively
makes it impossible to enable and reset this device during hwmod init.

At its core, this patch is a workaround for an OMAP hardware problem.
It should be possible to configure the OMAP to provide any IP block's
functional clock from an on-chip source.  (This is true for almost
every IP block on the chip.  As far as I know, McPDM is the only
exception.)  If the kernel cannot reset and configure IP blocks, it
cannot guarantee a sane SoC state.  Relying on an optional off-chip
clock also creates a board dependency which is beyond the scope of the
early hwmod code.

This patch works around the issue by marking the McPDM hwmod record
with the HWMOD_EXT_OPT_MAIN_CLK flag.  This prevents the hwmod
code from touching the device early during boot.

Signed-off-by: Paul Walmsley <paul@pwsan.com>
Cc: Péter Ujfalusi <peter.ujfalusi@ti.com>
Cc: Benoît Cousson <b-cousson@ti.com>
Acked-by: Peter Ujfalusi <peter.ujfalusi@ti.com>
arch/arm/mach-omap2/omap_hwmod_44xx_data.c