[PATCH] clocksource: timer-ti-dm: Drop bogus omap_dm_timer_of_set_source()

[PATCH] clocksource: timer-ti-dm: Drop bogus omap_dm_timer_of_set_source()

[Suman Anna]

The function omap_dm_timer_of_set_source() was originally added in
commit 31a7448f4fa8a ("ARM: OMAP: dmtimer: Add clock source from DT"),
and is designed to set a clock source from DT using the clocks property
of a timer node. This design choice is okay for clk provider nodes but
otherwise is a bad design as typically the clocks property is used to
specify the functional clocks for a device, and not its parents.

The timer nodes now all define a timer functional clock after the
conversion to ti-sysc and the new clkctrl layout, and this results
in an attempt to set the same functional clock as its parent when a
consumer driver attempts to acquire any of these timers in the
omap_dm_timer_prepare() function. This was masked and worked around
in commit 983a5a43ec25 ("clocksource: timer-ti-dm: Fix pwm dmtimer
usage of fck reparenting"). Fix all of this by simply dropping the
entire function.

Any DT configuration of clock sources should be achieved using
assigned-clocks and assigned-clock-parents properties provided
by the Common Clock Framework.

Cc: Tony Lindgren <tony@atomide.com>
Cc: Tero Kristo <t-kristo@ti.com>
Cc: Neil Armstrong <narmstrong@baylibre.com>
Cc: H. Nikolaus Schaller <hns@goldelico.com>
Cc: Bartosz Golaszewski <bgolaszewski@baylibre.com>
Cc: Keerthy <j-keerthy@ti.com>
Cc: Ladislav Michl <ladis@linux-mips.org>
Cc: Pavel Machek <pavel@ucw.cz>
Cc: Sebastian Reichel <sre@kernel.org>
Signed-off-by: Suman Anna <s-anna@ti.com>
---
Hi Tony,

Do you have the history of why the 32 KHz source is set as parent during
prepare? One of the current side-affects of this patch is that now instead
of bailing out, the 32 KHz source is set, and consumers will still need
to select their appropriate parent. Dropping that call should actually
allow us to select the parents in the consumer nodes in dts files using
the assigned-clocks and assigned-clock-parents properties. I prefer to
drop it if you do not foresee any issues. For now, I do not anticipate
any issues with omap-pwm-dmtimer with this patch.

regards
Suman

 drivers/clocksource/timer-ti-dm.c | 33 +------------------------------
 1 file changed, 1 insertion(+), 32 deletions(-)

diff --git a/drivers/clocksource/timer-ti-dm.c b/drivers/clocksource/timer-ti-dm.c
index 269a994d6a99..d8637a60a7eb 100644
--- a/drivers/clocksource/timer-ti-dm.c
+++ b/drivers/clocksource/timer-ti-dm.c
@@ -138,35 +138,6 @@ static int omap_dm_timer_reset(struct omap_dm_timer *timer)
 	return 0;
 }
 
-static int omap_dm_timer_of_set_source(struct omap_dm_timer *timer)
-{
-	int ret;
-	struct clk *parent;
-
-	/*
-	 * FIXME: OMAP1 devices do not use the clock framework for dmtimers so
-	 * do not call clk_get() for these devices.
-	 */
-	if (!timer->fclk)
-		return -ENODEV;
-
-	parent = clk_get(&timer->pdev->dev, NULL);
-	if (IS_ERR(parent))
-		return -ENODEV;
-
-	/* Bail out if both clocks point to fck */
-	if (clk_is_match(parent, timer->fclk))
-		return 0;
-
-	ret = clk_set_parent(timer->fclk, parent);
-	if (ret < 0)
-		pr_err("%s: failed to set parent\n", __func__);
-
-	clk_put(parent);
-
-	return ret;
-}
-
 static int omap_dm_timer_set_source(struct omap_dm_timer *timer, int source)
 {
 	int ret;
@@ -276,9 +247,7 @@ static int omap_dm_timer_prepare(struct omap_dm_timer *timer)
 	__omap_dm_timer_enable_posted(timer);
 	omap_dm_timer_disable(timer);
 
-	rc = omap_dm_timer_of_set_source(timer);
-	if (rc == -ENODEV)
-		return omap_dm_timer_set_source(timer, OMAP_TIMER_SRC_32_KHZ);
+	rc = omap_dm_timer_set_source(timer, OMAP_TIMER_SRC_32_KHZ);
 
 	return rc;
 }
-- 
2.23.0

Re: [PATCH] clocksource: timer-ti-dm: Drop bogus omap_dm_timer_of_set_source()

[Lokesh Vutla]

On 13/02/20 11:05 AM, Suman Anna wrote:
> The function omap_dm_timer_of_set_source() was originally added in
> commit 31a7448f4fa8a ("ARM: OMAP: dmtimer: Add clock source from DT"),
> and is designed to set a clock source from DT using the clocks property
> of a timer node. This design choice is okay for clk provider nodes but
> otherwise is a bad design as typically the clocks property is used to
> specify the functional clocks for a device, and not its parents.
> 
> The timer nodes now all define a timer functional clock after the
> conversion to ti-sysc and the new clkctrl layout, and this results
> in an attempt to set the same functional clock as its parent when a
> consumer driver attempts to acquire any of these timers in the
> omap_dm_timer_prepare() function. This was masked and worked around
> in commit 983a5a43ec25 ("clocksource: timer-ti-dm: Fix pwm dmtimer
> usage of fck reparenting"). Fix all of this by simply dropping the
> entire function.
> 
> Any DT configuration of clock sources should be achieved using
> assigned-clocks and assigned-clock-parents properties provided
> by the Common Clock Framework.
> 
> Cc: Tony Lindgren <tony@atomide.com>
> Cc: Tero Kristo <t-kristo@ti.com>
> Cc: Neil Armstrong <narmstrong@baylibre.com>
> Cc: H. Nikolaus Schaller <hns@goldelico.com>
> Cc: Bartosz Golaszewski <bgolaszewski@baylibre.com>
> Cc: Keerthy <j-keerthy@ti.com>
> Cc: Ladislav Michl <ladis@linux-mips.org>
> Cc: Pavel Machek <pavel@ucw.cz>
> Cc: Sebastian Reichel <sre@kernel.org>
> Signed-off-by: Suman Anna <s-anna@ti.com>
> ---
> Hi Tony,
> 
> Do you have the history of why the 32 KHz source is set as parent during
> prepare? One of the current side-affects of this patch is that now instead
> of bailing out, the 32 KHz source is set, and consumers will still need
> to select their appropriate parent. Dropping that call should actually
> allow us to select the parents in the consumer nodes in dts files using
> the assigned-clocks and assigned-clock-parents properties. I prefer to
> drop it if you do not foresee any issues. For now, I do not anticipate
> any issues with omap-pwm-dmtimer with this patch.

Without this patch, pwm is not being generated at all on my BBB. After applying
this patch I am able to see pwm being generated on the scope.

FWIW:
Tested-by: Lokesh Vutla <lokeshvutla@ti.com>

Thanks and regards,
Lokesh

Re: [PATCH] clocksource: timer-ti-dm: Drop bogus omap_dm_timer_of_set_source()

[Tony Lindgren]

* Suman Anna <s-anna@ti.com> [200212 21:36]:
> Hi Tony,
> 
> Do you have the history of why the 32 KHz source is set as parent during
> prepare? One of the current side-affects of this patch is that now instead
> of bailing out, the 32 KHz source is set, and consumers will still need
> to select their appropriate parent. Dropping that call should actually
> allow us to select the parents in the consumer nodes in dts files using
> the assigned-clocks and assigned-clock-parents properties. I prefer to
> drop it if you do not foresee any issues. For now, I do not anticipate
> any issues with omap-pwm-dmtimer with this patch.

Using the 32 KiHz source works better for PM. But yeah the
machine specific source clock should be configured with
assigned-clocks and assigned-clock-parents properites.

Things seem to behave just fine for me with this patch for both
pwm-leds and PM. Good to see this function gone:

Tested-by: Tony Lindgren <tony@atomide.com>

Re: [PATCH] clocksource: timer-ti-dm: Drop bogus omap_dm_timer_of_set_source()

[Daniel Lezcano]

On 26/02/2020 17:16, Tony Lindgren wrote:
> * Suman Anna <s-anna@ti.com> [200212 21:36]:
>> Hi Tony,
>>
>> Do you have the history of why the 32 KHz source is set as parent during
>> prepare? One of the current side-affects of this patch is that now instead
>> of bailing out, the 32 KHz source is set, and consumers will still need
>> to select their appropriate parent. Dropping that call should actually
>> allow us to select the parents in the consumer nodes in dts files using
>> the assigned-clocks and assigned-clock-parents properties. I prefer to
>> drop it if you do not foresee any issues. For now, I do not anticipate
>> any issues with omap-pwm-dmtimer with this patch.
> 
> Using the 32 KiHz source works better for PM. But yeah the
> machine specific source clock should be configured with
> assigned-clocks and assigned-clock-parents properites.
> 
> Things seem to behave just fine for me with this patch for both
> pwm-leds and PM. Good to see this function gone:
> 
> Tested-by: Tony Lindgren <tony@atomide.com>

Thanks for testing


-- 
 <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

Re: [PATCH] clocksource: timer-ti-dm: Drop bogus omap_dm_timer_of_set_source()

[Daniel Lezcano]

Hi,

On 13/02/2020 06:35, Suman Anna wrote:
> The function omap_dm_timer_of_set_source() was originally added in
> commit 31a7448f4fa8a ("ARM: OMAP: dmtimer: Add clock source from DT"),
> and is designed to set a clock source from DT using the clocks property
> of a timer node. This design choice is okay for clk provider nodes but
> otherwise is a bad design as typically the clocks property is used to
> specify the functional clocks for a device, and not its parents.
> 
> The timer nodes now all define a timer functional clock after the
> conversion to ti-sysc and the new clkctrl layout, and this results
> in an attempt to set the same functional clock as its parent when a
> consumer driver attempts to acquire any of these timers in the
> omap_dm_timer_prepare() function. This was masked and worked around
> in commit 983a5a43ec25 ("clocksource: timer-ti-dm: Fix pwm dmtimer
> usage of fck reparenting"). Fix all of this by simply dropping the
> entire function.
> 
> Any DT configuration of clock sources should be achieved using
> assigned-clocks and assigned-clock-parents properties provided
> by the Common Clock Framework.

Applied. Thanks

-- 
 <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

Re: [PATCH] clocksource: timer-ti-dm: Drop bogus omap_dm_timer_of_set_source()

[Lokesh Vutla]

Hi Tony, Suman,

On 13/02/20 11:05 AM, Suman Anna wrote:
> The function omap_dm_timer_of_set_source() was originally added in
> commit 31a7448f4fa8a ("ARM: OMAP: dmtimer: Add clock source from DT"),
> and is designed to set a clock source from DT using the clocks property
> of a timer node. This design choice is okay for clk provider nodes but
> otherwise is a bad design as typically the clocks property is used to
> specify the functional clocks for a device, and not its parents.
> 
> The timer nodes now all define a timer functional clock after the
> conversion to ti-sysc and the new clkctrl layout, and this results
> in an attempt to set the same functional clock as its parent when a
> consumer driver attempts to acquire any of these timers in the
> omap_dm_timer_prepare() function. This was masked and worked around
> in commit 983a5a43ec25 ("clocksource: timer-ti-dm: Fix pwm dmtimer
> usage of fck reparenting"). Fix all of this by simply dropping the
> entire function.
> 
> Any DT configuration of clock sources should be achieved using
> assigned-clocks and assigned-clock-parents properties provided
> by the Common Clock Framework.
> 
> Cc: Tony Lindgren <tony@atomide.com>
> Cc: Tero Kristo <t-kristo@ti.com>
> Cc: Neil Armstrong <narmstrong@baylibre.com>
> Cc: H. Nikolaus Schaller <hns@goldelico.com>
> Cc: Bartosz Golaszewski <bgolaszewski@baylibre.com>
> Cc: Keerthy <j-keerthy@ti.com>
> Cc: Ladislav Michl <ladis@linux-mips.org>
> Cc: Pavel Machek <pavel@ucw.cz>
> Cc: Sebastian Reichel <sre@kernel.org>
> Signed-off-by: Suman Anna <s-anna@ti.com>
> ---
> Hi Tony,
> 
> Do you have the history of why the 32 KHz source is set as parent during
> prepare? One of the current side-affects of this patch is that now instead
> of bailing out, the 32 KHz source is set, and consumers will still need
> to select their appropriate parent. Dropping that call should actually
> allow us to select the parents in the consumer nodes in dts files using
> the assigned-clocks and assigned-clock-parents properties. I prefer to
> drop it if you do not foresee any issues. For now, I do not anticipate
> any issues with omap-pwm-dmtimer with this patch.
> 

Sorry to bring up an old thread. But ping on this question by Suman. prepare()
is over writing any parent set by DT to 32KHz. Is it possible to know why
prepare is doing it? If there is no proper reason can we drop this setting all
together?

Thanks and regards,
Lokesh

Re: [PATCH] clocksource: timer-ti-dm: Drop bogus omap_dm_timer_of_set_source()

[Tony Lindgren]

* Lokesh Vutla <lokeshvutla@ti.com> [200425 09:15]:
> Hi Tony, Suman,
> 
> On 13/02/20 11:05 AM, Suman Anna wrote:
> > The function omap_dm_timer_of_set_source() was originally added in
> > commit 31a7448f4fa8a ("ARM: OMAP: dmtimer: Add clock source from DT"),
> > and is designed to set a clock source from DT using the clocks property
> > of a timer node. This design choice is okay for clk provider nodes but
> > otherwise is a bad design as typically the clocks property is used to
> > specify the functional clocks for a device, and not its parents.
> > 
> > The timer nodes now all define a timer functional clock after the
> > conversion to ti-sysc and the new clkctrl layout, and this results
> > in an attempt to set the same functional clock as its parent when a
> > consumer driver attempts to acquire any of these timers in the
> > omap_dm_timer_prepare() function. This was masked and worked around
> > in commit 983a5a43ec25 ("clocksource: timer-ti-dm: Fix pwm dmtimer
> > usage of fck reparenting"). Fix all of this by simply dropping the
> > entire function.
> > 
> > Any DT configuration of clock sources should be achieved using
> > assigned-clocks and assigned-clock-parents properties provided
> > by the Common Clock Framework.
> > 
> > Cc: Tony Lindgren <tony@atomide.com>
> > Cc: Tero Kristo <t-kristo@ti.com>
> > Cc: Neil Armstrong <narmstrong@baylibre.com>
> > Cc: H. Nikolaus Schaller <hns@goldelico.com>
> > Cc: Bartosz Golaszewski <bgolaszewski@baylibre.com>
> > Cc: Keerthy <j-keerthy@ti.com>
> > Cc: Ladislav Michl <ladis@linux-mips.org>
> > Cc: Pavel Machek <pavel@ucw.cz>
> > Cc: Sebastian Reichel <sre@kernel.org>
> > Signed-off-by: Suman Anna <s-anna@ti.com>
> > ---
> > Hi Tony,
> > 
> > Do you have the history of why the 32 KHz source is set as parent during
> > prepare? One of the current side-affects of this patch is that now instead
> > of bailing out, the 32 KHz source is set, and consumers will still need
> > to select their appropriate parent. Dropping that call should actually
> > allow us to select the parents in the consumer nodes in dts files using
> > the assigned-clocks and assigned-clock-parents properties. I prefer to
> > drop it if you do not foresee any issues. For now, I do not anticipate
> > any issues with omap-pwm-dmtimer with this patch.
> > 
> 
> Sorry to bring up an old thread. But ping on this question by Suman. prepare()
> is over writing any parent set by DT to 32KHz. Is it possible to know why
> prepare is doing it? If there is no proper reason can we drop this setting all
> together?

For devicetree configured machines we should just configure the source
clock with assigned-clock-parents as there may be device specific need
for a specific source. So yeah, I'm all for dropping that code for device
tree booting machines. For the old omap1 devices, the clock code still
needs to configure it probably.

The reason why the 32k source is the default is that it's always on and
works for power management unlike the system clock which may be shut off
during idle.

Regards,

Tony