[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20200226170939.GQ37466@atomide.com>
Date: Wed, 26 Feb 2020 09:09:39 -0800
From: Tony Lindgren <tony@...mide.com>
To: Lokesh Vutla <lokeshvutla@...com>
Cc: Daniel Lezcano <daniel.lezcano@...aro.org>,
Thomas Gleixner <tglx@...utronix.de>,
Linux OMAP Mailing List <linux-omap@...r.kernel.org>,
linux-kernel@...r.kernel.org, narmstrong@...libre.com,
Sekhar Nori <nsekhar@...com>, Tero Kristo <t-kristo@...com>
Subject: Re: [PATCH 1/2] clocksource: timer-ti-dm: Do not restore context on
every timer enable
* Lokesh Vutla <lokeshvutla@...com> [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
Powered by blists - more mailing lists