Re: Suspend to RAM broken on BeagleBoard ?

[Kevin Hilman <khilman@deeprootsystems.com>]

Thomas Petazzoni <thomas.petazzoni@free-electrons.com> writes:

> Hello,
>
> On Mon, 13 Sep 2010 07:56:54 -0700
> Kevin Hilman <khilman@deeprootsystems.com> 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