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
next prev 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).