From: swarren@wwwdotorg•org (Stephen Warren)
To: linux-arm-kernel@lists•infradead.org
Subject: [PATCH 3/8] clk: tegra114: add LP1 suspend/resume support
Date: Thu, 08 Aug 2013 13:54:14 -0600 [thread overview]
Message-ID: <5203F766.9050100@wwwdotorg.org> (raw)
In-Reply-To: <1375928591.1758.66.camel@jlo-ubuntu-64.nvidia.com>
On 08/07/2013 08:23 PM, Joseph Lo wrote:
> On Thu, 2013-08-08 at 00:46 +0800, Stephen Warren wrote:
..
>> I still have absolutely no idea why Tegra30 and Tegra114 are different.
>>
>> You mentioned something about this low-level code only manipulating the
>> IDLE state, and the clock driver needing to restore the other 4 states.
>> This raises yet more questions:
>>
>> 1) Do we not need to restore the other 4 states on Tegra30? If not, why
>> not? If we do, presumably Tegra30 (and Tegra20?) need to the syscore_op
>> this patch series adds to Tegra114 only? If we don't, then why does
>> Tegra114 have to restore them?
>
> We need to restore all of them for all Tegra chips. For Tegra20/30, we
> had done it in the tegra_cpu_car_ops.suspend/resume. For Tegra114, the
> patch was here.
>
> The other reason is:
> 1) The PLLX is the main CPU clock source in Tegra20/30. We can restore
> it ASAP to get a better performance.
> 2) For Tegra114, the PLLX is the CPU clock source when CPU runs at low
> rates. When CPU in high rate, it uses DFLL as clock source. So it
> depends on what the clock source of the CPU when it goes into suspend.
> And the DFLL has its own resume code, it needs to be restored before the
> CPU uses it as clock source again. It makes the CPU clock restore
> sequence like this.
So, we don't yet support the DFLL upstream. Presumably, the CPU is
always running off PLLX on Tegra114 upstream right now. As such, we can
hard-code that into the resume path just like we do on earlier chips,
i.e. using tegra_cpu_car_ops.resume().
Once we do get DFLL support, presumably the DFLL resume path can switch
the register from PLLX to DFLL, and we still won't need a custom
syscore_ops.
Will that work?
>> 2) What triggers the HW to switch from IDLE to RUN state?
>
> I also want to know more detail about it. The TRM only said it decided
> by HW and gave an example about when switching to IRQ or FIQ state.
>
>> In other
>> words, I think you're saying that the existing Tegra30 code:
>>
>> mov32 r4, ((1 << 28) | (0x8)) @ burst policy is PLLX
>> str r4, [r0, #CLK_RESET_CCLK_BURST]
>>
>> doesn't change the clock rate right away. When does it change?
>
> The code before this is the PLLX re-enable code. Then it switches to
> PLLX. The rate is still kept the same when it suspended. The next rate
> change after resume would be happened in the CPUfreq driver.
Sorry, when I wrote "doesn't change the clock rate right away", I really
meant "doesn't change the clock *source* right away".
next prev parent reply other threads:[~2013-08-08 19:54 UTC|newest]
Thread overview: 44+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-07-26 9:15 [PATCH 0/8] ARM: tegra: support LP1 suspend mode Joseph Lo
2013-07-26 9:15 ` [PATCH 1/8] ARM: tegra: add common resume handling code for LP1 resuming Joseph Lo
2013-07-29 22:38 ` Stephen Warren
2013-07-26 9:15 ` [PATCH 2/8] ARM: tegra: config the polarity of the request of sys clock Joseph Lo
2013-07-29 22:47 ` Stephen Warren
2013-08-02 7:48 ` Joseph Lo
2013-08-02 20:24 ` Stephen Warren
2013-08-05 8:42 ` Joseph Lo
2013-07-26 9:15 ` [PATCH 3/8] clk: tegra114: add LP1 suspend/resume support Joseph Lo
2013-07-29 22:51 ` Stephen Warren
2013-08-02 8:09 ` Joseph Lo
2013-08-02 20:32 ` Stephen Warren
2013-08-05 8:02 ` Joseph Lo
2013-08-05 17:00 ` Stephen Warren
2013-08-05 17:39 ` Stephen Warren
2013-08-06 9:10 ` Joseph Lo
2013-08-06 18:37 ` Stephen Warren
2013-08-07 9:12 ` Joseph Lo
2013-08-07 16:46 ` Stephen Warren
2013-08-08 2:23 ` Joseph Lo
2013-08-08 19:54 ` Stephen Warren [this message]
2013-08-09 9:23 ` Joseph Lo
2013-08-06 9:19 ` Joseph Lo
2013-07-26 9:15 ` [PATCH 4/8] ARM: tegra: add common LP1 suspend support Joseph Lo
2013-07-29 23:13 ` Stephen Warren
2013-08-02 9:27 ` Joseph Lo
2013-08-02 20:40 ` Stephen Warren
2013-08-05 8:07 ` Joseph Lo
2013-07-26 9:15 ` [PATCH 5/8] ARM: tegra30: add " Joseph Lo
2013-07-29 23:45 ` Stephen Warren
2013-08-05 6:46 ` Joseph Lo
2013-07-26 9:15 ` [PATCH 6/8] ARM: tegra20: " Joseph Lo
2013-07-26 9:15 ` [PATCH 7/8] ARM: tegra114: " Joseph Lo
2013-07-29 23:53 ` Stephen Warren
2013-08-05 6:51 ` Joseph Lo
2013-07-26 9:15 ` [PATCH 8/8] ARM: dts: tegra: enable LP1 suspend mode Joseph Lo
2013-07-27 16:12 ` [PATCH 0/8] ARM: tegra: support " Marc Dietrich
2013-07-27 16:20 ` Dmitry Osipenko
2013-07-27 18:09 ` Marc Dietrich
2013-07-27 18:26 ` Dmitry Osipenko
2013-07-27 18:29 ` Dmitry Osipenko
2013-07-27 19:03 ` Marc Dietrich
2013-07-27 19:11 ` Dmitry Osipenko
2013-07-30 9:49 ` Joseph Lo
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=5203F766.9050100@wwwdotorg.org \
--to=swarren@wwwdotorg$(echo .)org \
--cc=linux-arm-kernel@lists$(echo .)infradead.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
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