summaryrefslogtreecommitdiff
path: root/arch/arm64
diff options
context:
space:
mode:
authorPaul Walmsley <paul@pwsan.com>2013-02-12 20:28:12 (GMT)
committerPaul Walmsley <paul@pwsan.com>2013-03-13 10:27:32 (GMT)
commit92702df3570e1ccfa050e135e50c450502251b79 (patch)
tree0d6ddf4be7a773fca09f43feb6691d9735ded1f2 /arch/arm64
parent092bc089c249de0fa0f0c98b28dea6e5f1367b6e (diff)
downloadlinux-fsl-qoriq-92702df3570e1ccfa050e135e50c450502251b79.tar.xz
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>
Diffstat (limited to 'arch/arm64')
0 files changed, 0 insertions, 0 deletions