ARM: OMAP4: PM: fix PM regression introduced by recent clock cleanup
authorPaul Walmsley <paul@pwsan.com>
Tue, 12 Feb 2013 20:28:12 +0000 (20:28 +0000)
committerPaul Walmsley <paul@pwsan.com>
Wed, 13 Mar 2013 10:27:32 +0000 (04:27 -0600)
commit92702df3570e1ccfa050e135e50c450502251b79
tree0d6ddf4be7a773fca09f43feb6691d9735ded1f2
parent092bc089c249de0fa0f0c98b28dea6e5f1367b6e
ARM: OMAP4: PM: fix PM regression introduced by recent clock cleanup

Commit 17b7e7d33530e2bbd3bdc90f4db09b91cfdde2bb ("ARM: OMAP4:
clock/hwmod data: start to remove some IP block control "clocks"")
introduced a regression preventing the L3INIT clockdomain of OMAP4
systems from entering idle.  This in turn prevented these systems from
entering full chip clock-stop.

The regression was caused by the incorrect removal of a so-called
"optional functional clock" from the OMAP4 clock data.  This wasn't
caught for two reasons.  First, I missed the retention entry failure
in the branch test logs:

http://www.pwsan.com/omap/testlogs/cleanup_a_3.9/20130126014242/pm/4460pandaes/4460pandaes_log.txt

Second, the integration data for the OCP2SCP PHY IP block, added by
commit 0c6688753f9912c6a7013549ec31c8844020bbc1 ("ARM: OMAP4: hwmod
data: add remaining USB-related IP blocks"), should have associated this
clock with the IP block, but did not.

Fix by adding back the so-called "optional" functional clock to the
clock data, and by linking that clock to the OCP2SCP PHY IP block
integration hwmod data.

The problem patch was discovered by J, Keerthy <j-keerthy@ti.com>.

Cc: Keerthy <j-keerthy@ti.com>
Cc: BenoƮt Cousson <b-cousson@ti.com>
Signed-off-by: Paul Walmsley <paul@pwsan.com>
arch/arm/mach-omap2/cclock44xx_data.c
arch/arm/mach-omap2/omap_hwmod_44xx_data.c