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". -- To unsubscribe from this list: send the line "unsubscribe linux-tegra" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
