On 18/01/2019 21:45, Tony Lindgren wrote:
* Andreas Kemnade <andreas@xxxxxxxxxxxx> [190118 19:39]:
Hi,
On Fri, 18 Jan 2019 10:36:30 -0800
Tony Lindgren <tony@xxxxxxxxxxx> wrote:
[...]
til the next workaround.
That flags also causes the iclk being enabled/disabled
manually.
Yes but SWSUP_IDLE for the interface clock to me currently
just means:
"manually enable and disable ocp interface clock"
well, if we want to manually disable it and not automatically,
we have to disable autoidle or it will be automatically disabled.
Disabling it manually when it is already auto-disabled (by autoidle) is
just practically a no-op towards the clock.
OK I buy that :) It should be probably added to the patch
description to make it clear what it changes.
Tero, any comments on this change?
Well, seeing the flag is pretty much only used for a handful of hwmods
nowadays, it should be fine. OMAP3 PM should be tested with this change
though, as there are couple of hwmods impacted on that platform. I
wonder what happens to cpuidle when display is active...
-Tero
and with your changes it becomes:
"manually enable and disable ocp interface clock and block
autoidle while in use".
So aren't we now changing the way things behave in general
for SWSUP_IDLE?
Yes, we are, so proper testing is needed. But If I read those comments
it was always intended this way but not fully implemented because it
appeared to be more work like needing a usecounter (which my patchset
also adds) for that autoidle flag.
OK yeah the use count seems necessary. I'll test here
with my PM use cases.
Regards,
Tony
--
Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki. Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki
