Thomas Petazzoni <[email protected]> writes: > Hello, > > On Mon, 13 Sep 2010 07:56:54 -0700 > Kevin Hilman <[email protected]> wrote: > >> Looks like DSS has not been initialized, so is not hitting RET. >> >> Do you have the DSS driver enabled and built-in? Without this (and >> until we have DSS converted to hwmod) the DSS HW is not in a state that >> can hit the low power mode. If the DSS driver is allowed to initialize, >> even without a panel, it should set the DSS HW in a state that will then >> allow RET. > > Indeed: > > $ grep DSS .config > # CONFIG_OMAP2_DSS is not set > > It's not enabled simply because it isn't enabled by omap3_defconfig. So > maybe it should also be fixed for this ? > > I have zero knowledge of DSS, but shouldn't the kernel be able to > suspend properly even if the DSS driver is disabled ?
Yes, it should, and it's almost there. > But maybe it's too complicated to have the DSS init sequence required > to allow the system to hit RET outside the DSS driver. Thoughts ? One of the multiple motivations for moving to the omap_hwmod model of describing all the HW IP blocks in a central location is so that we have a common init and reset for every on-chip device. Once an omap_hwmod exists for a device, during init, the hwmod core will ensure that that block is properly initialized, reset and in a state that will not prevent the chip from entering low-power sleep. This will happen in the hwmod core, and is independent of the existence of a driver for that device, so will solve problems like this one. Currently, we have a hack here and a hack there for common devices that the bootloader blindy leaves in an state that prevents low-power states, but this is clearly a hack and does not scale. omap_hwmod is the solution to scaling this to every IP block. Kevin -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html
