Hi Peter, Peter Barada <peter.barada@xxxxxxxxx> writes: [...] > Thanks for helping me to understand things. > > The kernel I'm using is TI's OMAPPSP_03.00.01.06 2.6.32 kernel [1] > with their u-boot [2] and x-loader[3], modified to run on Logic's > DM3730 board(s) (as we use the Micron mt29c4g48mazapakq-5 POP). I'm afraid somone who supports that older TI kernel will have to help you out. If you can reproduce on a current kernel, I'd be glad to help but I'm currently not able (well, not willing is more accurate) to try and figure out what's going on based on an older kernel with who knows how many out-of-tree patches/hacks piled on. What I can say based on the register dump you shared is that there is no obvious driver issue going on where a clock was left on by a driver. More than likely what is going on is that the booloader is using a device (e.g. USB, MMC) but is leaving it in a state such that that IP block cannot idle, so the CORE powerdomain then does not fully idle. In older kernels like this one, the linux drivers did not fully reset the hardware so bootloaders could cause problems like this (the u-boot on beagle has had several problems like this.) As a first whack at things, I would focus on USB OTG and MMC, as I've seen problem with both on other platforms, like Beagle. You need to ensure that both the these modules are fully reset either by the bootloader when it's done using them, or by the kernel in the early boot process. Current kernels now do the latter. Sorry I can't be of more help, Kevin -- 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
