> -----Original Message----- > From: linux-omap-owner@xxxxxxxxxxxxxxx > [mailto:linux-omap-owner@xxxxxxxxxxxxxxx] On Behalf Of > Valentin, Eduardo > Sent: Wednesday, April 13, 2011 8:51 PM > To: Paul Walmsley; Kevin Hilman > Cc: Linux-OMAP; Linux-ARM; Valentin, Eduardo > Subject: [PATCH 2/2] OMAP3: PM: Do not rely on ROM code to > restore CM_AUTOIDLE_PLL.AUTO_PERIPH_DPLL > > As per OMAP3 erratum (i671), ROM code adds extra latencies while > restoring CM_AUTOIDLE_PLL register, if AUTO_PERIPH_DPLL is equal to 1. > > This patch stores 0's in scratchpad content area corresponding to > AUTO_PERIPH_DPLL, to prevent ROM code to try to lock per DPLL, since > it won't respect proper programing scheme. > > This register is then stored in prcm context. The saving and restore > is now done by kernel side. > > Here follow the erratum description > > DESCRIPTION > > After OFF mode transition, among many restorations, the ROM > Code restores the > CM_AUTOIDLE_PLL register, and after that, it tries to relock > the PER DPLL. > > In case the restoration data stored in scratchpad memory > contains a field > CM_AUTOIDLE_PLL.AUTO_PERIPH_DPLL = 1, then the way the ROM > Code restores and > locks the PER DPLL does not respect the PER DPLL programming scheme. > > In that case, the DPLL might not lock. Meanwhile, when trying > to lock the PER > DPLL, the ROM Code does not hang. Only extra latencies are > introduced at > wake-up. > [sp] You seem to have missed this patch: http://marc.info/?l=linux-arm-kernel&m=129735383925285&w=2 ~sanjeev -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
