On 6/4/2024 5:46 PM, Konrad Dybcio wrote:
On 5/31/24 13:41, Taniya Das wrote:
In the cases where the power domain connected to logics is allowed to
transition from a level(L)-->power collapse(0)-->retention(1) or
vice versa retention(1)-->power collapse(0)-->level(L) will cause the
logic to lose the configurations. The ARC does not support retention
to collapse transition on MxC rails.
This is not very legible. Are you saying that:
a) transitioning to/from LEVEL_RETENTION causes the resource to be powered
off internally for some short time and lose state
If there is a logic connected to MxC and the vote on that logic(MXC)
from a subsystem is initially to LEVEL_RETENTION and then to power
collapse [0], then the PLL connected to MxC will loose the contents.
This the transition I am referring here.
or
b) the linux implementation of rpmhpd handling causes that transition to
include a power collapse step that makes it lose the state
No, this is not the case of SW implementation, it is more from the HW
ARC implementation.
?
The targets from SM8450 onwards the PLL logics of clock controllers are
connected to MxC rails and the recommended configurations are carried
out during the clock controller probes. The MxC transition as mentioned
above should be skipped to ensure the PLL settings are intact across
clock controller power on & off.
So is this a workaround for clock controller drivers specifically, or
should
MXC never enter retention, and only poweroff? (the latter sounds like it
makes
more sense given MXC's purpose)
This is avoid MxC to not enter retention to OFF state.
On older generation of targets which supports only Mx the logic is never
collapsed and it is parked always at RETENTION, thus this issue is never
observed on those targets.
"On older targets that do not split MX into MXA and MXC..."
Yes, but that is only Mx :).
Konrad
--
Thanks & Regards,
Taniya Das.
