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@xxxxxxxxxxx>
> Cc: Tero Kristo <t-kristo@xxxxxx>
> Cc: Neil Armstrong <narmstrong@xxxxxxxxxxxx>
> Cc: H. Nikolaus Schaller <hns@xxxxxxxxxxxxx>
> Cc: Bartosz Golaszewski <bgolaszewski@xxxxxxxxxxxx>
> Cc: Keerthy <j-keerthy@xxxxxx>
> Cc: Ladislav Michl <ladis@xxxxxxxxxxxxxx>
> Cc: Pavel Machek <pavel@xxxxxx>
> Cc: Sebastian Reichel <sre@xxxxxxxxxx>
> Signed-off-by: Suman Anna <s-anna@xxxxxx>
> ---
> 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@xxxxxx>
Thanks and regards,
Lokesh
