On 17.04.2024 12:39, Ulf Hansson wrote:
> On Wed, 17 Apr 2024 at 10:05, claudiu beznea <claudiu.beznea@xxxxxxxxx> wrote:
>>
>> Hi, Ulf,
>>
>> On 16.04.2024 15:07, Ulf Hansson wrote:
>>> On Thu, 7 Mar 2024 at 15:10, Claudiu <claudiu.beznea@xxxxxxxxx> wrote:
>>>>
>>>> From: Claudiu Beznea <claudiu.beznea.uj@xxxxxxxxxxxxxx>
>>>>
>>>> RZ/G3S supports deep sleep states that it can reach with the help of the
>>>> TF-A.
>>>>
>>>> RZ/G3S has a few power domains (e.g. GIC) that need to be always-on while
>>>> Linux is running. These domains are initialized (and powered on) when
>>>> clock driver is probed.
>>>>
>>>> As the TF-A takes control at the very last(suspend)/first(resume)
>>>> phase of configuring the deep sleep state, it can do it's own settings on
>>>> power domains.
>>>
>>> For my understanding, can you please elaborate on this part a bit.
>>> What does the "last suspend/resume phase" mean, more exactly, here?
>>
>> The RZ/G3S SoC support a power saving mode where most of the SoC parts are
>> turned off and the system RAM is switched to retention mode. This is done
>> with the help of TF-A. The handshake b/w Linux and TF-A is done though the
>> drivers/firmware/psci/psci.c driver.
>>
>> After Linux finishes the execution of suspend code the control is taken by
>> TF-A. TF-A does the final settings on the system (e.g. switching the RAM to
>> retention mode) and power off most of the SoC parts.
>>
>> By the last phase of the suspend I'm referring to the TF-A doing the final
>> adjustments for the system to switch to this power saving mode.
>>
>> When resuming, as the TF-A is the 1st one being executed on the system
>> (this is what I called above the 1st phase of the resume), TF-A moves the
>> DDR out of retention mode, reconfigure basic IPs (like in boot case as most
>> of the SoC parts were powered off) and then give the control to Linux which
>> will execute the resume code.
>
> Alright, thanks for clarifying! This makes sense to me now!
>
>>
>>
>>>
>>>>
>>>> Thus, to restore the proper Linux state, add rzg2l_cpg_resume() which
>>>> powers on the always-on domains and rzg2l_cpg_complete() which activates
>>>> the power down mode for the IPs selected through CPG_PWRDN_IP{1, 2}.
>>>>
>>>> Along with it, added the suspend_check member to the RZ/G2L power domain
>>>> data structure whose purpose is to checks if a domain can be powered off
>>>> while the system is going to suspend. This is necessary for the serial
>>>> console domain which needs to be powered on if no_console_suspend is
>>>> available in bootargs.
>>>>
>>>> Signed-off-by: Claudiu Beznea <claudiu.beznea.uj@xxxxxxxxxxxxxx>
>>>> ---
[ ... ]
>>>>
>>>> +static int rzg2l_cpg_resume(struct device *dev)
>>>> +{
>>>> + struct rzg2l_cpg_priv *priv = dev_get_drvdata(dev);
>>>> + const struct rzg2l_cpg_info *info = priv->info;
>>>> +
>>>> + /* Power on always ON domains. */
>>>> + for (unsigned int i = 0; i < info->num_pm_domains; i++) {
>>>> + if (info->pm_domains[i].flags & RZG2L_PD_F_ALWAYS_ON) {
>>>> + int ret = rzg2l_cpg_power_on(priv->domains[i]);
>>>> +
>>>> + if (ret)
>>>> + return ret;
>>>> + }
>>>> + }
>>>
>>> I don't quite understand why this is needed? Is always-on PM domains
>>> being powered-off during system wide suspend, so you need to power
>>> them on again?
>>
>> Yes, as power to most of the system parts is cut off during sytem suspend
>> (and DDR is kept in retention mode) and the resume is almost like a cold
>> boot where the TF-A does basic re-initialization and then pass execution to
>> Linux resume code.
>
> Hmm. If these are really always-on PM domains, why isn't the FW
> powering them on again then before returning to Linux after a system
> resume?
I'll try to explain it better.
The power domain implementation in this series tries to abstract the
control of bus clock (though MSTOP registers) for individual modules
available in RZ/G3S SoC.
>From hardware manual [1]: "The Module Standby Mode is a mode that requests
the clock stop of the module specified by the master. The purpose of this
mode is to reduce power consumption by stopping unnecessary functions."
MSTOP is connected to individual modules as described in this picture:
https://paste.pics/726c963c33a506651a4be5f327e2a46d
There is also the PWRDN functionality for the modules that are part of the
PD_ISOVCC domain. At the time of writing this series there was not much
information in hardware manual about PWRDN functionality. The design team
has been asked but there is no clear answer ATM if the sequence of using
PWRDN in Linux (as proposed in this series) is good or not. I encountered
no issues with it while experimenting thus I have kept it. If you prefer I
can drop it and return with something afterwards, if any.
As I said in the current implementation I also used the PWRDN. The PWRDN is
IP specific but takes effect (as of my experiments) when this is executed:
+ /* Prepare for power down the BUSes in power down mode. */
+ if (info->pm_domain_pwrdn_mstop)
+ writel(CPG_PWRDN_MSTOP_ENABLE, priv->base + CPG_PWRDN_MSTOP);
As of my experiments having CPG_PWRDN_MSTOP.CPG_PWRDN_MSTOP_ENABLE set
applies the PWRDN to all the IPs for which PWRDN bit has been set in
CPG_PWRDN_IP1 and CPG_PWRD_IP2 registers.
This settings are applied in probe after domains are powered (thus PWRDN
bits are properly set up for IP supporting it by calling ->power_on()) and
at the end of resume (after PWRDN bits are properly setup for IPs
supporting it by calling ->power_on())
>From my experiments, when returning from suspend (thus after firmware has
been executed) the CPG_PWRDN_MSTOP_ENABLE bit at register CPG_PWRDN_MSTOP
is zero. We power on the domains in Linux after resuming because of PWRDN
functionality and CPG_PWRDN_MSTOP_ENABLE bit at register CPG_PWRDN_MSTOP.
>
> In a way it sounds to me that they aren't really always-on PM domains,
> as Linux seems to be capable of turning them on/off too, right?
Yes, Linux has the ability of controlling them by setting MSTOP and PWRDN
bits. This is because the IP specific PWRDN functionality takes effect when
CPG_PWRDN_MSTOP_ENABLE bit at register CPG_PWRDN_MSTOP is set (as of my
experiments).
>
> That said, perhaps using GENPD_FLAG_RPM_ALWAYS_ON instead of
> GENPD_FLAG_ALWAYS_ON for some PM domains can be another way forward?
All this is becuase PWRD functionality. Explaining it to you made me
consider that it would be better to just drop the PWRDN functionality at
the moment until it is fully understood. With it I think we should be able
to drop the rzg2l_cpg_power_on() in resume(), at least. What do you think?
> In this way, the ->power_on|off() callbacks can be used to turn on/off
> the PM domains, but only during system suspend/resume. Would that
> work?
I need to check it.
Thank you for you review,
Claudiu Beznea
[1]
https://www.renesas.com/us/en/products/microcontrollers-microprocessors/rz-mpus/rzg3s-general-purpose-microprocessors-single-core-arm-cortex-a55-11-ghz-cpu-and-dual-core-cortex-m33-250
>
> [...]
>
> Kind regards
> Uffe
