RE: [PATCH 28/28] omap2 clock: handle (almost) all clock autoidlingviathe clock framework

Tuukka.Tikkanen
2007-08-27T14:13:55Z

[-- Attachment #1: Type: text/plain, Size: 1837 bytes --]

From: paul@utopia.booyaka.com [mailto:paul@utopia.booyaka.com] On Behalf
Of Paul Walmsley
>
> On Thu, 23 Aug 2007, Tuukka.Tikkanen@elektrobit.com wrote:
>
> > One minor detail to note is that on OMAP2 the sleep code sometimes
has
> > to disable the autoidle feature on certain clocks. Not doing so
would
> > prevent desired functionality. This - at least the action of setting
the
> > autoidle state - of course could be handled via the clock framework.
> > However, it was deemed to be unnecessary extra layer, as the sleep
code
> > already has to be very aware of the hardware its running on and any
> > abstraction is useless. I think at least timers and DMA have some
> > special restrictions in pm.c. Thus the original design of PM code
> > handling the autoidle bits.
>
> Hi Tuukka,
>
> I took a quick look at pm.c, it configures ICLK autoidling for SDMA
and
> GPT*, and sleep.S doesn't look like it touches the autoidle regs.
Could
> you point me at the code you're talking about?

Sorry for the false alarm, guys. The code I was thinking about lives in
OMAP1 tree. The clock framework updates variable called
arm_idlect1_mask. That value is programmed after some masking into
hardware in omap_pm_idle when entering sleep state. Essentially what we
have there is a mask of clocks that may not be autoidled during that
particular idle call.

The OMAP2 tree seems to handle its special cases in another way by
skipping the sleep completely.

Tuukka

----------------------------------------------------------------
Please note: This e-mail may contain confidential information
intended solely for the addressee. If you have received this
e-mail in error, please do not disclose it to anyone, notify
the sender promptly, and delete the message from your system.
Thank you.

[-- Attachment #2: Type: text/plain, Size: 0 bytes --]