* Tero Kristo <t-kristo@xxxxxx> [130327 02:15]: > On Tue, 2013-03-26 at 18:43 +0000, Paul Walmsley wrote: > > > > So what I'd like you to do is: > > > > 1. Determine what devices are remaining to be reset and idled on OMAP4 > > with the bootloader that I use. As far as I know, there are only four > > that block full-chip idle: M3, DSP, SL2IF, FSUSB > > > > 2. Determine what's needed to reset and idle them. For the M3 and DSP, > > I'd assume this involves pointing the reset vector for those > > processors at a few lines of code that basically enter WFI or the C64x > > equivalent. > > This is the nasty part. We need firmware support for the blocks to do > this, and this is imo a complete overkill for the task at hand, as it > will duplicate the DSP + M3 firmware and drivers at least partially. On > OMAP3, it was easy as you could just setup the boot mode for IVA and get > over with it. We don't have similar luxury on OMAP4. > > If there was a simple way to do this, don't you think this would have > been done already a year back when we started to discuss this first > time? And, a year old bootloader is ancient seeing we didn't have any > kind of support for OMAP4 core idle in mainline back then and this > feature was essentially completely untested.... nobody cared about the > upstream u-boot PM compatibility before that. You may be able to have an inline function in the DSP and M3 headers that idles those modules that can also be called from the reset and idle function in the hwmod code. That way the driver related code stays in the driver, but can be called from hwmod reset if the driver is not compiled in. Of course if the reset and idle of DSP and M3 gets more complex than just a few lines of code, then we should just determine that the PM is broken without those drivers and print out a warning. Regards, Tony -- 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
