Re: [PATCH 3/8] clk: tegra114: add LP1 suspend/resume support

[Stephen Warren <swarren-3lzwWm7+Weoh9ZMKESR00Q@public.gmane.org>]

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".