This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

Clock Transition Mode



Hello,
I want to know about the "Clock Transition Mode".
http://www.ti.com/lit/ug/spruh73k/spruh73k.pdf
P1117 "Table 8-9. Clock Transition Mode Settings"

If I set NO_SLEEP, Sleep transition cannot be initiated.
If I set SW_SLEEP, A software-forced sleep transition. The transition is initiated when the associated hardware conditions are satisfied.
If I set SW_WKUP and leave it as SW_WKUP, does the sleep transition happen when the associated hardware conditions are satisfied?
or sleep transition does not happen even the associated hardware conditions are satisfied ?

Regards,
Takeshi Matsuzaki

  • Hi Matsuzaki-san,

    I think SW_SLEEP and SW_WKUP cannot be set at the same time. Value 0x3 is not allowed.

  • Biser-san,

    Thank you for quick reply every time.

    well, I woun't set SW_SLEEP and SW_WKUP at same time.
    My question is that if I set SW_WKUP(0x2) and leave it, does the sleep transition happen or not according to some hardware conditions.

    Do I have to set NO_SLEEP(0x0) or SW_SLEEP(0x1) finaly, not leave as SW_WKUP(0x2), to make the function clear?

    Regards,
    Takeshi Matsuzaki

  • I think that the sequence should be  SW_SLEEP first to put the clock to sleep and then when you want to start it  SW_WKUP.

  • SW_WKUP (2) unconditionally wakes up the clock domain.  The power domain to which the clock domain belongs is automatically powered up if necessary.

    NO_SLEEP (0) wakes up the clock domain if any of its clocks are requested, e.g. when any of its modules or optional clocks are enabled, when a master requests to leave standby-mode, or upon a wakeup request.  Based on a quick test, it does not appear to automatically enable the associated power domain:  If powered off, the clock domain remains in sleep.  Once awakened, behaviour is the same as SW_WKUP:  the clock domain remains active and the power domain enabled.

    SW_SLEEP (1) requests the clock domain to sleep as soon as possible, which is when all modules are disabled (MODULEMODE = 0) and have acknowledged their idlereq (IDLEST=3), all optional clocks are disabled, all masters are in standby (STBYST=1), and no wakeup request is asserted.  Once all clock domains belonging a power domain are sleeping, it will transition to its configured target power state.

  • An additional point worth mentioning:

    Some modules can't be enabled or disabled merely by changing their MODULEMODE:  for example, some reset signal may need to be released before they will acknowledge the request to exit idle state.  The module's behavior in response to a request to enter idle state again can typically be configured inside the module (IDLEMODE).  If a module fails to acknowledge a request to exit or enter idle state, its IDLEST remains "transitioning" (1) and the clock domain won't be able to sleep.

    If a module is also a master, things may be even more complicated.  (For example, on the DM814x processor, if you enable its "Media Controller" subsystem, to disable it again you have to load software onto the two cortex-M3 cores that reside there that puts them into "deep sleep".)

    BTW, I realized my "quick test" of NO_SLEEP behavior may be invalid since I performed it on a DM814x which actually declares that state to be "reserved", so it may not be working as intended there.  (and I don't have an AM335x nearby right now to try it on)

  • Hello Matthijs van Duin,
    Thank you for details.

    I also looking AM35x(not AM335x) TRM.
    http://www.ti.com/lit/ug/sprugr0c/sprugr0c.pdf
    P297 "Table 4-71. Clock State Transition Settings"

    AM35x has "hardware-supervised mode" but AM335x does not.
    So, if I want to change Active to Sleep, woke up by SW_WKUP(2) and woke up by NO_SLEEP(0) is the same. Both of them need to set SW_SLEEP(1) to be Sleep, right ?


    Regards,
    Takeshi Matsuzaki

  • takeshi matsuzaki said:
    I also looking AM35x(not AM335x) TRM.

    While the AM35xx and AM335x part codes look very similar, they are very different chips.

    (Since the same chip can have very different part codes while completely different chips can have very similar part codes, I often prefer to use the chip names (when known) as these are much easier to recognize and distinguish than 4-digit numbers.)

    The AM35xx is an OMAP34xx/35xx-derivative, though with addition of peripherals you won't find on an OMAP and various other changes such as a different memory controller (unlike the AM37xx/DM37xx, which are just rebranded OMAP36xx chips with some features disabled).

    The AM335x ("Subarctic") is most closely related to the "Centaurus" family of chips (DM814x/AM387x and a flurry of other partcodes).  These chips are OMAP4-generation, but they are quite different from the OMAP4 chips.

    In general, the OMAPs tend to have very fancy and fine-grained power management since they are targeted for smartphones.  I'm not deeply familiar with the OMAP3 series but based on a quick look the AM35xx lacks fine-grained voltage control but otherwise appears to inherit OMAP3 power management, including features like sleep/wakeup dependencies.

    Centaurus has OMAP4-derived but greatly simplified power management: other than the automatic clock gating that happens internally in most modules, power management is basically entirely under software control.  Subarctic is similar but adds some low-power modes and has a cortex-M3 intended to manage these.

     

    takeshi matsuzaki said:
    So, if I want to change Active to Sleep, woke up by SW_WKUP(2) and woke up by NO_SLEEP(0) is the same. Both of them need to set SW_SLEEP(1) to be Sleep, right ?

    On centaurus/subarctic only SW_SLEEP(1) requests the clock domain to sleep, yes.  (Though it will still not sleep as long as any of its clock signals are active.)

    I'm not familiar enough with OMAP3/AM35xx power management to make any statement about how things work there.

  • Matthijs van Duin,

    Thank you very much giving me great knowledge.
    I am not familiar with the ancestor of AM35xx and AM335x at all,
    but your post powerfully helps me than reading a TRM.

    Regards,
    Takeshi Matsuzaki