linux-omap.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Kevin Hilman <khilman@deeprootsystems.com>
To: Russ Dill <russ.dill@gmail.com>
Cc: "Premi, Sanjeev" <premi@ti.com>,
	Peter Barada <peterb@logicpd.com>,
	"linux-omap@vger.kernel.org" <linux-omap@vger.kernel.org>
Subject: Re: PM branch rebased to 2.6.29
Date: Tue, 31 Mar 2009 11:25:43 -0700	[thread overview]
Message-ID: <87myb1wnvc.fsf@deeprootsystems.com> (raw)
In-Reply-To: <f9d2a5e10903301601q5fcd331bs44c81d854ad0082f@mail.gmail.com> (Russ Dill's message of "Mon\, 30 Mar 2009 16\:01\:24 -0700")

Russ Dill <russ.dill@gmail.com> writes:

> On Mon, Mar 30, 2009 at 11:43 AM, Kevin Hilman
> <khilman@deeprootsystems.com> wrote:
>> Russ Dill <russ.dill@gmail.com> writes:
>>
>>> On Mon, Mar 30, 2009 at 3:08 AM, Premi, Sanjeev <premi@ti.com> wrote:
>> [...]
>>>>
>>>> I had found that two drivers that could prevent clocks_off are
>>>> USB and DSS because of the way they use clk_enable().
>>>>
>>>> Can you try building without theses drivers just for verification?
>>>>
>>>
>>> Building without dss makes things worse:
>>>
>>> Powerdomain (dss_pwrdm) didn't enter target state 0
>>>
>>> Maybe by looking at what the dss driver is doing I can get core and
>>> per to turn off.
>>
>> Russ,
>>
>> Can you try with the latest HEAD of PM branch.  After suspend/resume,
>> do
>>
>> # cat /debug/pm_debug/registers/1
>>
>> and post results to list.  We can then see the exact state of PM
>> registers before going into WFI.

Russ,

With the dump below, what was the output after you resumed?  Which
powerdomains did not hit their target state?  It looks like PER and
CORE did not hit target state.

Also, you didn't mention what hardware you're using or your .config or
your bootloader etc.  All of these play an important role.

> root@beagleboard:/sys# cat /debug/pm_debug/registers/1
> MOD: CM_IVA2 (48014000)
>   04 => 00000037  20 => 00000001  34 => 00000001  40 => 0009680c
>   44 => 00000001  48 => 00000003
> MOD: CM_OCP (48004800)
>   00 => 00000010  10 => 00000001
> MOD: CM_MPU (48004900)
>   04 => 00000037  24 => 00000001  34 => 00000001  40 => 0011f40c
>   44 => 00000001  48 => 00000003  4c => 00000001
> MOD: CM_CORE (48004a00)
>   10 => 00000042  20 => ffffffbd  24 => 0000001f  28 => 0000000d
>   30 => fffffed9  34 => 0000001f  38 => 0000000c  40 => 0000030a
>   48 => 0000003f  4c => 00000003
> MOD: CM_SGX (48004b00)
>   20 => 00000001  48 => 00000003
> MOD: CM_WKUP (48004c00)
>   10 => 0000000e  20 => 000002f1  30 => 0000003f  40 => 00000015

Here is at least one problem.

Offset 0x40 is CM_CLKSEL_WKUP, and bit 0 shows which clock is the
source clock for GPTIMER1.  Here, bit 0 is 1 which means SYS_CLK
is used as the timer source.  

Based on this, you must have:

   System Type --> TI OMAP Implementations --> System Timer

set to 'MPU timer'.  Please change to 32k timer.  Using MPU timer will
keep timers not in WKUP powerdomain (which is all of them except GPT1)
running across suspend, preventing PER from hitting RET.

Using the 32k timer only uses GPT1 and sources it from the 32k clock, both
of which are in the WKUP powerdomain.

> MOD: CM_CCR (48004d00)
>   00 => f8311037  04 => 00000017  20 => 00000201  30 => 00000009
>   34 => 00000001  40 => 094c0c00  44 => 0001b00c  48 => 00000009
>   50 => 00000001  70 => 00000003
> MOD: CM_DSS (48004e00)
>   20 => 00000003  30 => 00000001  40 => 00001006  48 => 00000003
> MOD: CM_CAM (48004f00)
>   20 => 00000001  30 => 00000001  40 => 00000004  48 => 00000003
> MOD: CM_PER (48005000)
>   10 => 0003e000  20 => 00001fff  30 => 0003ffff  40 => 000000ff
>   44 => 00000006  48 => 00000003  4c => 00000001
> MOD: CM_EMU (48005100)
>   40 => 03020a50  48 => 00000002  4c => 00000001
> MOD: CM_NEON (48005300)
>   48 => 00000003
> MOD: CM_USB (48005400)
>   20 => 00000003  30 => 00000001  48 => 00000003
> MOD: PRM_IVA2 (48316000)
>   50 => 00000007  e0 => 00ff0f04  f8 => 00000007
> MOD: PRM_OCP (48306800)
>   04 => 00000010  14 => 00000001  1c => 00000201
> MOD: PRM_MPU (48306900)
>   58 => 00000005  d4 => 00000012  e0 => 00030104  e4 => 000000c7
>   e8 => 000000c7
> MOD: PRM_CORE (48306a00)
>   58 => 00000301  a0 => c33ffe18  a4 => c33ffe18  a8 => c33ffe18
>   e0 => 000f0304  e4 => 000000f7  e8 => 000000f7  f0 => 00000004
>   f4 => 00000004  f8 => 00000004
> MOD: PRM_SGX (48306b00)
>   e0 => 00030104
> MOD: PRM_WKUP (48306c00)
>   a0 => 0000010b  a4 => 0000010b
> MOD: PRM_CCR (48306d00)
>   40 => 00000003
> MOD: PRM_DSS (48306e00)
>   58 => 00000005  a0 => 00000001  e0 => 00030104
> MOD: PRM_CAM (48306f00)
>   58 => 00000001  e0 => 00030104
> MOD: PRM_PER (48307000)
>   58 => 00000001  a0 => 0003efff  a4 => 0003efff  a8 => 0003efff
>   c8 => 00000007  e0 => 00030104  e4 => 00000007  e8 => 00000007
> MOD: PRM_EMU (48307100)
>   58 => 00000005  e4 => 00000103
> MOD: PRM_GLBL (48307200)
>   20 => 00120012  24 => 00010000  2c => 301e1e30  30 => 2c1e1e2c
>   34 => 00120000  38 => 00000018  54 => 00001006  58 => 00000001
>   60 => 0000000e  64 => 00000050  70 => 00000088  90 => 0fff0fff
>   94 => 000000ff  98 => 000000ff  9c => 00000002  a0 => 000000ff
>   c4 => 00000001  e4 => 00000001
> MOD: PRM_NEON (48307300)
>   58 => 00000005  c8 => 00000002  e0 => 00000004  e4 => 00000003
>   e8 => 00000003
> MOD: PRM_USB (48307400)
>   58 => 00000001  a0 => 00000001  a4 => 00000001  a8 => 00000001
>   e0 => 00030104
>
>
>> Also, post dump of
>>
>
> root@beagleboard:/sys# cat /debug/pm_debug/count
> usbhost_pwrdm (OFF),OFF:1,RET:1,INA:0,ON:1
> sgx_pwrdm (OFF),OFF:1,RET:0,INA:0,ON:1
> per_pwrdm (ON),OFF:0,RET:0,INA:0,ON:1
> dss_pwrdm (ON),OFF:2,RET:0,INA:0,ON:3
> cam_pwrdm (OFF),OFF:1,RET:1,INA:0,ON:1
> core_pwrdm (ON),OFF:0,RET:0,INA:0,ON:1
> neon_pwrdm (ON),OFF:2,RET:0,INA:14100,ON:14103
> mpu_pwrdm (ON),OFF:2,RET:0,INA:14100,ON:14103
> iva2_pwrdm (OFF),OFF:1,RET:1,INA:0,ON:1
> per_clkdm->per_pwrdm (9)
> usbhost_clkdm->usbhost_pwrdm (0)
> cam_clkdm->cam_pwrdm (0)
> dss_clkdm->dss_pwrdm (2)
> core_l4_clkdm->core_pwrdm (8)
> core_l3_clkdm->core_pwrdm (4)
> d2d_clkdm->core_pwrdm (0)
> sgx_clkdm->sgx_pwrdm (0)
> iva2_clkdm->iva2_pwrdm (0)
> neon_clkdm->neon_pwrdm (0)
> mpu_clkdm->mpu_pwrdm (0)
> virt_opp_clkdm->wkup_pwrdm (0)
> prm_clkdm->wkup_pwrdm (10)
> cm_clkdm->core_pwrdm (3)

Based on this, I see that you're DSS is not the problem anymore as it
is hitting off, but neither PER nor CORE have made any transistions.
PER is most likely because of the timer issue above.  Not sure yet
about CORE.

In addtion to more details on your hardware and .config, Can you send
me the console log of a full boot followed by trying just retention in
suspend by doing the following right after boot:

# cat /debug/pm_debug/count
# echo 1 > /sys/power/clocks_off_while_idle
# echo mem > /sys/power/state

<after wakeup>

# cat /debug/pm_debug/count
# cat /debug/pm_debug/registers/1

Kevin
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

  parent reply	other threads:[~2009-03-31 18:25 UTC|newest]

Thread overview: 31+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-03-18  5:21 PM branch rebased to 2.6.29 Kevin Hilman
2009-03-18  7:41 ` Artem Bityutskiy
2009-03-18 15:51   ` Kevin Hilman
2009-03-19 22:20 ` David Brownell
2009-03-20 18:59   ` Tony Lindgren
2009-03-20 19:46     ` David Brownell
2009-03-20 19:57       ` Tony Lindgren
2009-03-20 21:27         ` Tony Lindgren
2009-03-20 22:36       ` David Brownell
2009-03-24 17:10 ` Peter Barada
2009-03-24 18:08   ` Kevin Hilman
2009-03-24 20:11     ` Peter Barada
2009-03-24 20:21       ` Kevin Hilman
2009-03-24 20:37         ` Peter Barada
2009-03-27 20:50         ` Russ Dill
2009-03-30 10:08           ` Premi, Sanjeev
2009-03-30 10:42             ` Koen Kooi
2009-03-30 13:22               ` Premi, Sanjeev
2009-03-30 17:44             ` Russ Dill
2009-03-30 17:57               ` Kevin Hilman
2009-03-30 18:18                 ` Peter Barada
2009-03-30 18:43               ` Kevin Hilman
2009-03-30 23:01                 ` Russ Dill
2009-03-31  7:01                   ` Russ Dill
2009-03-31 18:25                   ` Kevin Hilman [this message]
2009-03-31 21:31                     ` Russ Dill
2009-03-31 23:33                       ` Kevin Hilman
2009-04-01  1:30                         ` Russ Dill
2009-04-01  4:11                           ` Kevin Hilman
2009-03-26 16:54 ` Jean Pihet
2009-03-26 17:01   ` Kevin Hilman

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=87myb1wnvc.fsf@deeprootsystems.com \
    --to=khilman@deeprootsystems.com \
    --cc=linux-omap@vger.kernel.org \
    --cc=peterb@logicpd.com \
    --cc=premi@ti.com \
    --cc=russ.dill@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).