* Lokesh Vutla <lokeshvutla@xxxxxx> [200224 05:09]:
> omap_dm_timer_enable() restores the entire context(including counter)
> based on 2 conditions:
> - If get_context_loss_count is populated and context is lost.
> - If get_context_loss_count is not populated update unconditionally.
>
> Case2 has a side effect of updating the counter register even though
> context is not lost. When timer is configured in pwm mode, this is
> causing undesired behaviour in the pwm period. So restore context only
> if get_context_loss_count is populated and context is actually lost.
Sounds like this will break things. We have get_context_loss_count()
only on omap4 and later, and even that was only partially implemented
from what I recall.
To mee it seems the right thing to do here is to save and restore
context on CPU_CLUSTER_PM_ENTER and CPU_CLUSTER_PM_EXIT. And I'd
just get rid of the partially implemented custom calls to
get_context_loss_count().
See for example a recent patch on removing the legacy SDMA code
for CPU_CLUSTER_PM_ENTER in commit d2f924879e19 ("thermal:
ti-soc-thermal: Enable addition power management").
Then if we really need to add checks for context lost at some point,
that can be implemented via reset_control_status() returning -ENOLINK
or something similar.
Regards,
Tony
