Message-ID: <5a4e8480-a291-409d-acc3-f053d4e99981@linaro.org>
Date: Wed, 13 Aug 2025 15:00:40 +0200
From: Daniel Lezcano <daniel.lezcano@...aro.org>
To: tglx@...utronix.de
Cc: Jim Cromie <jim.cromie@...il.com>,
 Maxime Coquelin <mcoquelin.stm32@...il.com>,
 Alexandre Torgue <alexandre.torgue@...s.st.com>, Chen-Yu Tsai
 <wens@...e.org>, Jernej Skrabec <jernej.skrabec@...il.com>,
 Samuel Holland <samuel@...lland.org>,
 Thierry Reding <thierry.reding@...il.com>,
 Jonathan Hunter <jonathanh@...dia.com>,
 "Peter Zijlstra (Intel)" <peterz@...radead.org>,
 Marco Elver <elver@...gle.com>, Nam Cao <namcao@...utronix.de>,
 linux-kernel@...r.kernel.org, linux-stm32@...md-mailman.stormreply.com,
 linux-arm-kernel@...ts.infradead.org, linux-sunxi@...ts.linux.dev,
 linux-tegra@...r.kernel.org, John Stulz <jstultz@...gle.com>,
 Will McVicker <willmcvicker@...gle.com>,
 Peter Griffin <peter.griffin@...aro.org>,
 Saravan Kanna <saravanak@...gle.com>
Subject: Re: [PATCH v1 0/7] Setting the scene to convert the timers into
 modules


Hi Thomas,

was this series dropped ?

I'm not able to find it in v6.17-rc1 but it is in the master branch of 
the tip tree (v6.16-rc7)


On 02/06/2025 17:18, Daniel Lezcano wrote:
> The timer drivers are all compiled-in. The initial pre-requisite is to
> have them available as soon as possible in the boot process. While
> this statement made sense a long time ago, the platforms have today
> multiple timers for different purposes along with architected timers
> which are initialized very early. For example, a timer can be used as
> a backup timer when the local timers are belonging to a power domain
> which is shutted down, or used a watchdog timer when the counter are
> shared, or also as a pulse width modulation counter. Another use case
> is the platform user may want to switch to a timer different from the
> architected timers because they have interesting characteristics in
> the context of a dedicated platform (eg. automotive).
> 
> In some existing drivers, there is already the code to load and unload
> a timer driver even if the Kconfig does not allow that. It means, the
> need is there but partially upstream.
> 
> There were multiple attempts to configure the timer drivers into
> modules but it faced the fact that we were unsure if it is correctly
> supported by the time framework.
> 
> After investigating deeper in the core code it appears we have
> everything set for the modularization of the timer drivers.
> 
>   - When a clocksource is registered with a better rating, the current
>     clocksource is swapped with the new one. The userspace allows to
>     change the current clocksource via sysfs
> 
>   - A clocksource can be unregistered
> 
>   - When a clockevent is registered with a better rating, it becomes
>     the active one
> 
>   - A clockevent can not be unregistered
> 
> A timer driver can be loaded later because of all the supported
> above. However unloading is unsupported because a clockevent can not
> be unregistered and that will lead to a crash.
> 
> But if the timer driver has the module owner set, the core framework
> will handle the refcount correctly and will prevent to unload the
> module if a clockevent is registered. All the refcounting is working
> in different use cases.
> 
>   - A clocksource is the current clocksource, the refcount is held
> 
>   - A current clocksource is switched to another one, the refcount is
>     released
> 
>   - A broadcast timer is registered, the refcount is held
> 
>   - A local timer is registered, the refcount is held
> 
> Consequently, it is possible to unload a module which is only used as
> a clocksource. As soon as a clockevent is registered, the refcount is
> held and can not be released thus preventing the module to be
> unloaded.
> 
> That mechanism ensure it is safe to convert the different timer
> drivers into modules.
> 
> This series adds the module owner in the different driver which are
> initialized with the module_platform_driver() function and export the
> symbols for the sched_clock_register() function.
> 
> Cc: Jim Cromie <jim.cromie@...il.com>
> Cc: Daniel Lezcano <daniel.lezcano@...aro.org>
> Cc: Thomas Gleixner <tglx@...utronix.de>
> Cc: Maxime Coquelin <mcoquelin.stm32@...il.com>
> Cc: Alexandre Torgue <alexandre.torgue@...s.st.com>
> Cc: Chen-Yu Tsai <wens@...e.org>
> Cc: Jernej Skrabec <jernej.skrabec@...il.com>
> Cc: Samuel Holland <samuel@...lland.org>
> Cc: Thierry Reding <thierry.reding@...il.com>
> Cc: Jonathan Hunter <jonathanh@...dia.com>
> Cc: "Peter Zijlstra (Intel)" <peterz@...radead.org>
> Cc: Marco Elver <elver@...gle.com>
> Cc: Nam Cao <namcao@...utronix.de>
> Cc: linux-kernel@...r.kernel.org
> Cc: linux-stm32@...md-mailman.stormreply.com
> Cc: linux-arm-kernel@...ts.infradead.org
> Cc: linux-sunxi@...ts.linux.dev
> Cc: linux-tegra@...r.kernel.org
> Cc: John Stulz <jstultz@...gle.com>
> Cc: Will McVicker <willmcvicker@...gle.com>
> Cc: Peter Griffin <peter.griffin@...aro.org>
> Cc: Saravan Kanna <saravanak@...gle.com>
> 
> 
> Daniel Lezcano (7):
>    clocksource/drivers/scx200: Add module owner
>    clocksource/drivers/stm32-lp: Add module owner
>    clocksource/drivers/sun5i: Add module owner
>    clocksource/drivers/tegra186: Add module owner
>    clocksource/drivers/stm: Add module owner
>    clocksource/drivers/cs5535: Add module owner
>    time: Export symbol for sched_clock register function
> 
>   drivers/clocksource/scx200_hrt.c     | 1 +
>   drivers/clocksource/timer-cs5535.c   | 1 +
>   drivers/clocksource/timer-nxp-stm.c  | 2 ++
>   drivers/clocksource/timer-stm32-lp.c | 1 +
>   drivers/clocksource/timer-sun5i.c    | 2 ++
>   drivers/clocksource/timer-tegra186.c | 3 +++
>   kernel/time/sched_clock.c            | 4 ++--
>   7 files changed, 12 insertions(+), 2 deletions(-)
> 


-- 
<http://www.linaro.org/> Linaro.org │ Open source software for ARM SoCs

Follow Linaro:  <http://www.facebook.com/pages/Linaro> Facebook |
<http://twitter.com/#!/linaroorg> Twitter |
<http://www.linaro.org/linaro-blog/> Blog

Powered by blists - more mailing lists