On 6/18/2024 6:47 PM, Konrad Dybcio wrote:
On 6/10/24 11:42, Taniya Das wrote:
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.
Okay, is there *always* some logic connected to MxC?
From the clock controller PoV PLLs logic (majorly Multimedia clock
controller PLLs) would be connected to MxC.
There can be logics from the other subsystems (other than APSS)
connected to MxC.
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.
I'm still not sure I understand. Is this to prevent MxC being switched off
while Linux is voting for LEVEL_RETENTION, as RPMh sees no other user and
decides it's okay to cut the power?
It is to prevent Linux from voting for LEVEL_RETENTION and then voting
for an OFF state or vice versa. By avoiding this transition we ensure
that the PLL configurations are not lost.
Other users(subsystems) also avoid voting for RETENTION.
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 :).
My point is about the wording.. There is no such thing as "supporting Mx".
Sure, I can update the commit text in the next patch.
Konrad
--
Thanks & Regards,
Taniya Das.
