[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <26208b83-32fa-a855-ddbb-715cd7bf8dde@ti.com>
Date: Mon, 24 Feb 2020 10:31:39 +0530
From: Lokesh Vutla <lokeshvutla@...com>
To: Suman Anna <s-anna@...com>, Tony Lindgren <tony@...mide.com>,
Daniel Lezcano <daniel.lezcano@...aro.org>,
Thomas Gleixner <tglx@...utronix.de>
CC: <linux-omap@...r.kernel.org>, <linux-kernel@...r.kernel.org>,
Tero Kristo <t-kristo@...com>,
Neil Armstrong <narmstrong@...libre.com>,
"H . Nikolaus Schaller" <hns@...delico.com>,
Bartosz Golaszewski <bgolaszewski@...libre.com>,
Keerthy <j-keerthy@...com>,
Ladislav Michl <ladis@...ux-mips.org>,
Pavel Machek <pavel@....cz>, Sebastian Reichel <sre@...nel.org>
Subject: Re: [PATCH] clocksource: timer-ti-dm: Drop bogus
omap_dm_timer_of_set_source()
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@...mide.com>
> Cc: Tero Kristo <t-kristo@...com>
> Cc: Neil Armstrong <narmstrong@...libre.com>
> Cc: H. Nikolaus Schaller <hns@...delico.com>
> Cc: Bartosz Golaszewski <bgolaszewski@...libre.com>
> Cc: Keerthy <j-keerthy@...com>
> Cc: Ladislav Michl <ladis@...ux-mips.org>
> Cc: Pavel Machek <pavel@....cz>
> Cc: Sebastian Reichel <sre@...nel.org>
> Signed-off-by: Suman Anna <s-anna@...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@...com>
Thanks and regards,
Lokesh
Powered by blists - more mailing lists