Clock provider drivers generally shouldn't include clk.h because
it's the consumer API. Only include clk.h in files that are
using it. The clkdev.h header isn't always used either, so remove
it and add in slab.h where files were relying on it to include
slab for them.
Cc: Chanwoo Choi <cw00.choi@samsung.com>
Cc: Sylwester Nawrocki <s.nawrocki@samsung.com>
Cc: Krzysztof Kozlowski <k.kozlowski@samsung.com>
Cc: Kukjin Kim <kgene.kim@samsung.com>
Signed-off-by: Stephen Boyd <sboyd@codeaurora.org>
Ensure the clock provider is not registered until after all its related
clocks were created and are ready to use. Currently there are races
possible and any (of_)clk_get() call right after a clock provider's
clk_init_cb callback call may fail.
Signed-off-by: Sylwester Nawrocki <s.nawrocki@samsung.com>
Signed-off-by: Tomasz Figa <t.figa@samsung.com>
There's a several typos in a driver: 2410 instead of S3C2410
and wrong argument to ARRAY_SIZE(). They prevent s3c2410
from properly booting.
Signed-off-by: Vasily Khoruzhick <anarsoul@gmail.com>
Reviewed-by: Heiko Stuebner <heiko@sntech.de>
Signed-off-by: Tomasz Figa <t.figa@samsung.com>
Samsung CCF helper functions do not provide support to
register multiple Clock Providers for a given SoC. Due to
this limitation, SoC platforms are not able to use these
helpers for registering multiple clock providers and are
forced to bypass this layer.
This layer is modified accordingly to enable the support
for multiple clock providers.
Clock file for exynos4, exynos5250, exynos5420, exynos5440,
S3c64xx, S3c24xx are also modified as per changed helper functions.
Signed-off-by: Rahul Sharma <rahul.sharma@samsung.com>
[t.figa: Modified s3c2410 clock driver as well]
Signed-off-by: Tomasz Figa <t.figa@samsung.com>
This driver can handle the clock controllers of the socs mentioned above,
as they share a common clock tree with only small differences.
The clock structure is built according to the manuals of the included
SoCs and might include changes in comparison to the previous clock
structure.
As pll-rate-tables only the 12mhz variants are currently included.
The original code was wrongly checking for 169mhz xti values [a 0 to much
at the end], so the original 16mhz pll table would have never been
included and its values are so obscure that I have no possibility to
at least check their sane-ness. When using the formula from the manual
the resulting frequency is near the table value but still slightly off.
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
Acked-by: Mike Turquette <mturquette@linaro.org>
Signed-off-by: Kukjin Kim <kgene.kim@samsung.com>