RE: [RFC/PATCH] OMAP3: run the ASM sleep code from DDR

[Santosh Shilimkar <santosh.shilimkar@ti.com>]

> -----Original Message-----
> From: Jean Pihet [mailto:jean.pihet@newoldbits.com]
> Sent: Tuesday, February 01, 2011 4:53 PM
> To: Santosh Shilimkar
> Cc: linux-omap@vger.kernel.org; Jean Pihet-XID
> Subject: Re: [RFC/PATCH] OMAP3: run the ASM sleep code from DDR
>

[...]
> >> Does that makes sense?
> >>
> > Actually not. Rather I will separate only the scenario's
> > where CORE low power targets are attempted and only have
> > that code run from SRAM.
> >
> > There are scenario's where CORE can be active because MODEM,
> > DSP and MPU can still hit RET, OFF. And here, the errata
> > isn't applicable.
> >
> > Unless I missed something here, I think in the code we check
> > the the CORE attempted state and based on that we can do a
> > normal WFI from DDR (no self rfersh) or WFI from
> > SRAM with self refresh enabled.
> No. Only the MPU attempted state is checked (this actually is the
> 'save_state' parameter passed to omap_cpu_suspend).
> So it makes sense to check the CORE attempted state in order to
> decide
> to run the WFI from internal SRAM or DDR.
>
> The MPU attempted state is used to decide whether to save the
> MPU/L1/L2 context.
>
Looks like you miss-understood my point. As I understand from
errata, as long as core clock domain can idle with core
dpll divider auto idle enabled, the errata is applicable.

So the only check needed is to see if the core clockdomain
hw_auto or sw sleep is enabled.

If it is suppose to be not idle(we force few C-states
where CORE inactive is avoided for faster response),
we can execute WFI from DDR with not enabling
self refresh.

Rest of the scenario can follow the SRAM path.

Hope this is clear to you.

Regards,
Santosh