- 30 Sep, 2014 10 commits
-
-
Mike Turquette authored
-
Robert Jarzmik authored
Transition the PXA27x CPUs to the clock framework. This transition still enables legacy platforms to run without device tree as before, ie relying on platform data encoded in board specific files. Signed-off-by: Robert Jarzmik <robert.jarzmik@free.fr> Signed-off-by: Mike Turquette <mturquette@linaro.org>
-
Robert Jarzmik authored
Add the clock tree description for the PXA27x based boards. Signed-off-by: Robert Jarzmik <robert.jarzmik@free.fr> Signed-off-by: Mike Turquette <mturquette@linaro.org>
-
Robert Jarzmik authored
Move pxa27x clock drivers from arch/arm/mach-pxa to driver/clk. In the move : - convert to new clock framework legacy clocks - provide clocks as before for platform data based boards - provide clocks through devicetree Signed-off-by: Robert Jarzmik <robert.jarzmik@free.fr> Signed-off-by: Mike Turquette <mturquette@linaro.org>
-
Robert Jarzmik authored
Add missing bits for CCCR and CCSR : - CPLL and PPLL selection, either full speed or 13MHz - CPSR masks Signed-off-by: Robert Jarzmik <robert.jarzmik@free.fr> Signed-off-by: Mike Turquette <mturquette@linaro.org>
-
Robert Jarzmik authored
Document the device-tree binding of Marvell PXA based SoCs. PXA clocks are mostly fixed rate and fixed ratio clocks derived from an external oscillator, and gated by a register set (CKEN or CKEN*). Signed-off-by: Robert Jarzmik <robert.jarzmik@free.fr> Signed-off-by: Mike Turquette <mturquette@linaro.org>
-
Robert Jarzmik authored
Add a the common code used by all PXA variants. This is the first step in the transition from architecture defined clocks (in arch/arm/mach-pxa) towards clock framework. The goal is to have the same features (and not all the features) of the existing clocks, and enable the transition of PXA to device-tree. All PXA rely on a "CKEN" type clock, which : - has a gate (bit in CKEN register) - is generated from a PLL, generally divided - has an alternate low power clock Each variant will specialize the CKEN clock : - pxa25x have no low power clock - pxa27x in low power use always the 13 MHz ring oscillator - pxa3xx in low power have specific dividers for each clock The device-tree provides a list of CLK_* (ex: CLK_USB or CLK_I2C) to get a handle on the clock. While pxa-clock.h will describe all the clocks of all the variants, each variant will only use a subset of it. Signed-off-by: Robert Jarzmik <robert.jarzmik@free.fr> Signed-off-by: Mike Turquette <mturquette@linaro.org>
-
Mark Brown authored
The gpio-gate clock uses the gpiod_ APIs but does not directly include the header for them causing build failures in some configurations including ARM allnoconfig. Include the header directly. Signed-off-by: Mark Brown <broonie@kernel.org> Acked-by: Jyri Sarha <jsarha@ti.com> Signed-off-by: Mike Turquette <mturquette@linaro.org>
-
Mike Turquette authored
Merge tag 'for_3.18/samsung-clk' of git://git.kernel.org/pub/scm/linux/kernel/git/tfiga/samsung-clk into clk-next Samsung clock patches for v3.18 1) non-critical fixes (without the need to push to stable) fa0111be clk: samsung: exynos4: remove duplicate div_core2 divider clock instantiation b511593d clk: samsung: exynos4: fix g3d clocks c1425430 clk: samsung: exynos4: add missing smmu_g2d clock and update comments 22842d24 clk: samsung: exynos5260: fix typo in clock name e82ba578 clk: samsung: exynos3250: fix width field of mout_mmc0/1 59037b92 clk: samsung: exynos3250: fix width and shift of div_spi0_isp clock 5ce37f26 clk: samsung: exynos3250: fix mout_cam_blk parent list 2) Clock driver extensions 07ccf02b dt-bindings: clk: samsung: Document the DMC domain of Exynos3250 CMU d0e73eaf ARM: dts: exynos3250: Add CMU node for DMC domain clocks e3c3f19b clk: samsung: exynos3250: Register DMC clk provider 4676f0aa clk: samsung: exynos4: add support for MOUT_HDMI and MOUT_MIXER clocks
-
Mike Turquette authored
-
- 29 Sep, 2014 5 commits
-
-
Peter Ujfalusi authored
It is safe to call the pm sync calls in interrupt context in this driver. Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com> Signed-off-by: Tero Kristo <t-kristo@ti.com>
-
Behan Webster authored
As written, the __init for ti_clk_get_div_table is in the middle of the return type. The gcc documentation indicates that section attributes should be added to the end of the function declaration: extern void foobar (void) __attribute__ ((section ("bar"))); However gcc seems to be very permissive with where attributes can be placed. clang on the other hand isn't so permissive, and fails if you put the section definition in the middle of the return type: drivers/clk/ti/divider.c:298:28: error: expected ';' after struct static struct clk_div_table ^ ; drivers/clk/ti/divider.c:298:1: warning: 'static' ignored on this declaration [-Wmissing-declarations] static struct clk_div_table ^ drivers/clk/ti/divider.c:299:9: error: type specifier missing, defaults to 'int' [-Werror,-Wimplicit-int] __init *ti_clk_get_div_table(struct device_node *node) ~~~~~~ ^ drivers/clk/ti/divider.c:345:9: warning: incompatible pointer types returning 'struct clk_div_table *' from a function with result type 'int *' [-Wincompatible-pointer-types] return table; ^~~~~ drivers/clk/ti/divider.c:419:9: warning: incompatible pointer types assigning to 'const struct clk_div_table *' from 'int *' [-Wincompatible-pointer-types] *table = ti_clk_get_div_table(node); ^ ~~~~~~~~~~~~~~~~~~~~~~~~~~ 3 warnings and 2 errors generated. By convention, most of the kernel code puts section attributes between the return type and function name. In the case where the return type is a pointer, it's important to place the '*' on left of the __init. This updated code works for both gcc and clang. Signed-off-by: Behan Webster <behanw@converseincode.com> Reviewed-by: Mark Charlebois <charlebm@gmail.com> Reviewed-by: Felipe Balbi <balbi@ti.com> Signed-off-by: Tero Kristo <t-kristo@ti.com>
-
Sebastian Andrzej Siewior authored
I "forgot" to update the dtb and the kernel crashed: |Unable to handle kernel NULL pointer dereference at virtual address 0000002e |PC is at __clk_get_flags+0x4/0xc |LR is at ti_dt_clockdomains_setup+0x70/0xe8 because I did not have the clock nodes. of_clk_get() returns an error pointer which is not checked here. Acked-by: Nishanth Menon <nm@ti.com> Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de> Signed-off-by: Tero Kristo <t-kristo@ti.com>
-
Tero Kristo authored
of_clk_add_provider makes an internal copy of the parent_names property while its called, thus it is no longer needed after this call and can be freed. Signed-off-by: Tero Kristo <t-kristo@ti.com> Cc: Mike Turquette <mturquette@linaro.org> Cc: Peter Ujfalusi <peter.ujfalusi@ti.com> Acked-by: Peter Ujfalusi <peter.ujfalusi@ti.com>
-
Tero Kristo authored
Previously, the TI clock driver initialized all the clocks hierarchically under each separate clock provider node. Now, each clock that requires IO access will instead check their parent node to find out which IO range to use. This patch allows the TI clock driver to use a few new features provided by the generic of_clk_init, and also allows registration of clock nodes outside the clock hierarchy (for example, any external clocks.) Signed-off-by: Tero Kristo <t-kristo@ti.com> Cc: Mike Turquette <mturquette@linaro.org> Cc: Paul Walmsley <paul@pwsan.com> Cc: Tony Lindgren <tony@atomide.com> Cc: Mark Rutland <mark.rutland@arm.com> Cc: Peter Ujfalusi <peter.ujfalusi@ti.com> Cc: Jyri Sarha <jsarha@ti.com> Cc: Stefan Assmann <sassmann@kpanic.de> Acked-by: Tony Lindgren <tony@atomide.com>
-
- 28 Sep, 2014 5 commits
-
-
git://github.com/hisilicon/linux-hisiMike Turquette authored
Hisilicon HiX5HD2 clock updates for 3.18-v2 - Add I2C clocks - Add watchdog clocks - Add sd clocks - Add complex clock implementation to support sata, usb and ethernet
-
Wei Yan authored
hix5hd2 add I2C clocks (I2C0~i2C5) Signed-off-by: Wei Yan <sledge.yanwei@huawei.com> Signed-off-by: Zhangfei Gao <zhangfei.gao@linaro.org> Signed-off-by: Wei Xu <xuwei5@hisilicon.com>
-
Guoxiong Yan authored
hix5hd2 add watchdog0 clocks Signed-off-by: Guoxiong Yan <yanguoxiong@huawei.com> Signed-off-by: Zhangfei Gao <zhangfei.gao@linaro.org> Signed-off-by: Wei Xu <xuwei5@hisilicon.com>
-
Jiancheng Xue authored
Signed-off-by: Jiancheng Xue <xuejiancheng@huawei.com> Signed-off-by: Zhangfei Gao <zhangfei.gao@linaro.org> Signed-off-by: Wei Xu <xuwei5@hisilicon.com>
-
Zhangfei Gao authored
Support clk of sata, usb and ethernet Signed-off-by: Jiancheng Xue <xuejiancheng@huawei.com> Signed-off-by: Zhangfei Gao <zhangfei.gao@linaro.org> Signed-off-by: Wei Xu <xuwei5@hisilicon.com>
-
- 27 Sep, 2014 20 commits
-
-
Xiubo Li authored
Setting 'flags' to zero will be certainly a misleading way to avoid warning of 'flags' may be used uninitialized. uninitialized_var is a correct way because the warning is a false possitive. Signed-off-by: Xiubo Li <Li.Xiubo@freescale.com> Signed-off-by: Mike Turquette <mturquette@linaro.org>
-
Mike Turquette authored
Merge tag 'sunxi-clocks-for-3.18' of git://git.kernel.org/pub/scm/linux/kernel/git/mripard/linux into clk-next Allwinner Clocks Additions for 3.18 The most important part of this serie is the addition of the phase API to handle the MMC clocks in the Allwinner SoCs. Apart from that, the A23 gained a new mbus driver, and there's a fix for a incorrect divider table on the APB0 clock.
-
Mike Turquette authored
Merge tag 'v3.18-rockchip-cpuclk' of git://git.kernel.org/pub/scm/linux/kernel/git/mmind/linux-rockchip into clk-next CPU clock handling for Rockchip SoCs
-
Heiko Stuebner authored
This adds the necessary soc-specific divider values and switches the armclk to use the newly introduced cpuclk type. Signed-off-by: Heiko Stuebner <heiko@sntech.de> Reviewed-by: Doug Anderson <dianders@chromium.org> Tested-by: Doug Anderson <dianders@chromium.org>
-
Heiko Stuebner authored
When changing the armclk on Rockchip SoCs it is supposed to be reparented to an alternate parent before changing the underlying pll and back after the change. Additionally there exist clocks that are very tightly bound to the armclk whose divider values are set according to the armclk rate. Add a special clock-type to handle all that. The rate table and divider values will be supplied from the soc-specific clock controllers. Signed-off-by: Heiko Stuebner <heiko@sntech.de> Reviewed-by: Doug Anderson <dianders@chromium.org> On a rk3288-board: Tested-by: Doug Anderson <dianders@chromium.org>
-
Heiko Stuebner authored
Rockchip SoCs contain clocks tightly bound to the armclk, where the best rate / divider is supplied by the vendor after careful measuring. Often this ideal rate may be greater than the current rate. Therefore prevent the ccf from trying to set these dividers itself by setting them to read-only. In the case of the rk3066, this also includes the aclk_cpu, which makes it necessary to also split its direct child-clocks (pclk_cpu, hclk_cpu, ...) into individual definitions for rk3066 and rk3188. Signed-off-by: Heiko Stuebner <heiko@sntech.de> Reviewed-by: Doug Anderson <dianders@chromium.org> Tested-by: Doug Anderson <dianders@chromium.org>
-
Heiko Stuebner authored
aclk_cpu_pre on the rk3188 can either be sourced from the armclk or the gpll. To reduce complexity on apll changes caused by cpufreq, reparent it always to the gpll source. If really necessary it could be reparented back on a per board level using the assigned-clocks mechanism. Signed-off-by: Heiko Stuebner <heiko@sntech.de>
-
Jianqun authored
In RK3288, APLL lock status bit is in GRF_SOC_STATUS1, but in RK3188, is GRFSOC_STATUS0. Signed-off-by: Jianqun <jay.xu@rock-chips.com> Also name the constant accordingly as GRF_SOC_STATUS1 to prevent confusion. Signed-off-by: Heiko Stuebner <heiko@sntech.de> Reviewed-by: Doug Anderson <dianders@chromium.org> Tested-by: Doug Anderson <dianders@chromium.org>
-
Heiko Stuebner authored
The register providing the pll lock status is at a different address on the rk3066. The error became apparent while working on cpufreq support for the rockchip SoCs. Signed-off-by: Heiko Stuebner <heiko@sntech.de>
-
Doug Anderson authored
The Rockchip PLL code switches into slow mode (AKA bypass more AKA 24MHz mode) before actually changing the PLL. This keeps anyone from using the PLL while it's changing. However, in all known Rockchip SoCs nobody should ever see the 24MHz when changing the PLL supplying the armclk because we should reparent children to an alternate (faster than 24MHz) PLL. One problem is that the code to switch to an alternate parent was running in PRE_RATE_CHANGE. ...and the code to switch to slow mode was _also_ running in PRE_RATE_CHANGE. That meant there was no real guarantee that we would switch to an alternate parent before switching to 24MHz mode. Let's move the switch to "slow mode" straight into rockchip_rk3066_pll_set_rate(). That means we're guaranteed that the 24MHz is really a last-resort. Note that without this change on real systems we were the code to switch to an alternate parent at 24MHz. In some older versions of that code we'd appy a (temporary) / 5 to the 24MHz causing us to run at 4.8MHz. That wasn't enough to service USB interrupts in some cases and could lead to a system hang. Signed-off-by: Doug Anderson <dianders@chromium.org> Signed-off-by: Heiko Stuebner <heiko@sntech.de>
-
Heiko Stuebner authored
-
Heiko Stuebner authored
Signed-off-by: Heiko Stuebner <heiko@sntech.de> Reviewed-by: Doug Anderson <dianders@chromium.org>
-
Chen-Yu Tsai authored
The MBUS clock on sun8i is slightly different from the old mod0 clocks. The divider is 3 bits wider, while also needing a divider table for the higher 4 values, which all set the same divider. Signed-off-by: Chen-Yu Tsai <wens@csie.org> Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com>
-
Maxime Ripard authored
The MMC clock we thought we had until now are actually not one but three different clocks. The main one is unchanged, and will have three outputs: - The clock fed into the MMC - a sample and output clocks, to deal with when should we output/sample data to/from the MMC bus The phase control we had are actually controlling the two latter clocks, but the main MMC one is unchanged. We can adjust the phase with a 3 bits value, from 0 to 7, 0 meaning a 180 phase shift, and the other values being the number of periods from the MMC parent clock to outphase the clock of. Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com> Acked-by: Hans de Goede <hdegoede@redhat.com>
-
Maxime Ripard authored
Move the MBUS clock to the module clocks file. It's pretty trivial, but still requires to enable the clocks to make sure it won't get disabled. Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com> Acked-by: Hans de Goede <hdegoede@redhat.com>
-
Maxime Ripard authored
Since we know have the ability to declare factors clock outside of clk-sunxi, create a new mod0 driver to deal with the mod0 clocks. Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com> Acked-by: Hans de Goede <hdegoede@redhat.com>
-
Maxime Ripard authored
Now that we have a compatible of its own for the mbus clock, switch to it. Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com> Acked-by: Hans de Goede <hdegoede@redhat.com>
-
Maxime Ripard authored
Even though the mbus clock is a regular module clock, given its nature, it needs to be enabled all the time. Introduce a new compatible, to differentiate it from the other module clocks. Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com> Acked-by: Hans de Goede <hdegoede@redhat.com>
-
Maxime Ripard authored
Until now, the factors clock probing was done directly by sunxi_init_clocks, with the factors registration being called directly with the clocks data passed as an argument. This approch has shown its limits when we added more clocks, since we couldn't really split code with such a logic in smaller files, and led to a huge file having all the clocks. Introduce an intermediate probing function, so that factor clocks will be able to directly be called by CLK_OF_DECLARE, which will in turn ease the split into several files. Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com> Acked-by: Hans de Goede <hdegoede@redhat.com>
-
Maxime Ripard authored
The current phase API doesn't look into the actual hardware to get the phase value, but will rather get it from a variable only set by the set_phase function. This will cause issue when the client driver will never call the set_phase function, where we can end up having a reported phase that will not match what the hardware has been programmed to by the bootloader or what phase is programmed out of reset. Add a new get_phase function for the drivers to implement so that we can get this value. Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com> Reviewed-by: Heiko Stuebner <heiko@sntech.de> Acked-by: Hans de Goede <hdegoede@redhat.com>
-