linux-stable.git/drivers/clk, branch v4.9.3

clk: renesas: mstp: Support 8-bit registers for r7s72100

2017-01-12T10:39:28+00:00

commit e2a33c34ddff22ee208d80abdd12b88a98d6cb60 upstream.

The RZ/A1 is different than the other Renesas SOCs because the MSTP
registers are 8-bit instead of 32-bit and if you try writing values as
32-bit nothing happens...meaning this driver never worked for r7s72100.

Fixes: b6face404f38 ("ARM: shmobile: r7s72100: add essential clock nodes to dtsi")
Signed-off-by: Chris Brandt 
Reviewed-by: Geert Uytterhoeven 
Tested-by: Geert Uytterhoeven 
Acked-by: Kuninori Morimoto 
Signed-off-by: Stephen Boyd 
Signed-off-by: Greg Kroah-Hartman

clk: imx31: fix rewritten input argument of mx31_clocks_init()

2017-01-12T10:39:27+00:00

commit bae203d58b7dce89664071b3fafe20cedaa3e4f6 upstream.

Function mx31_clocks_init() is called during clock intialization on
legacy boards with reference clock frequency passed as its input
argument, this can be verified by examination of the function
declaration found in arch/arm/mach-imx/common.h and actual function
users which include that header file.

Inside CCF driver the function ignores its input argument, by chance
the used value in the function body is the same as input arguments on
side of all callers.

Fixes: d9388c843237 ("clk: imx31: Do not call mxc_timer_init twice when booting with DT")
Signed-off-by: Vladimir Zapolskiy 
Reviewed-by: Uwe Kleine-König 
Acked-by: Stephen Boyd 
Signed-off-by: Shawn Guo 
Signed-off-by: Greg Kroah-Hartman

clk: sunxi-ng: sun8i-h3: Set CLK_SET_RATE_PARENT for audio module clocks

2017-01-12T10:39:27+00:00

commit 0f6f9302b819ca352cfd4f42c18ec08d521f9cae upstream.

The audio module clocks are supposed to be set according to the sample
rate of the audio stream. The audio PLL provides the clock signal for
these module clocks, and only it is freely tunable.

Set CLK_SET_RATE_PARENT for the audio module clocks so their users can
properly tune the clock rate.

Fixes: 0577e4853bfb ("clk: sunxi-ng: Add H3 clocks")
Signed-off-by: Chen-Yu Tsai 
Signed-off-by: Maxime Ripard 
Signed-off-by: Greg Kroah-Hartman

clk: sunxi-ng: sun8i-a23: Set CLK_SET_RATE_PARENT for audio module clocks

2017-01-12T10:39:27+00:00

commit 937ff9ded8b6ebe8963ade55bdd77a61ded88075 upstream.

The audio module clocks are supposed to be set according to the sample
rate of the audio stream. The audio PLL provides the clock signal for
these module clocks, and only it is freely tunable.

Set CLK_SET_RATE_PARENT for the audio module clocks so their users can
properly tune the clock rate.

Fixes: 5690879d93e8 ("clk: sunxi-ng: Add A23 CCU")
Signed-off-by: Chen-Yu Tsai 
Signed-off-by: Maxime Ripard 
Signed-off-by: Greg Kroah-Hartman

clk: ti: dra7: fix "failed to lookup clock node gmac_gmii_ref_clk_div" boot message

2017-01-12T10:39:27+00:00

commit f8d17344a60921c2387759fc0a85aa64299d1ec6 upstream.

Prevent creating clk alias for non existing gmac_gmii_ref_clk_div clock and,
this way, eliminate excessive error message during boot:

 "ti_dt_clocks_register: failed to lookup clock node gmac_gmii_ref_clk_div"

Fixes: c097338ebd3f ("ARM: dts: dra7: cpsw: fix clocks tree")
Signed-off-by: Grygorii Strashko 
Signed-off-by: Stephen Boyd 
Signed-off-by: Greg Kroah-Hartman

clk: clk-wm831x: fix a logic error

2017-01-12T10:39:27+00:00

commit 20979202ee6e4c68dab7bcf408787225a656d18e upstream.

Fix bug https://bugzilla.kernel.org/show_bug.cgi?id=188561. Function
wm831x_clkout_is_prepared() returns "true" when it fails to read
CLOCK_CONTROL_1. "true" means the device is already prepared. So
return "true" on the read failure seems improper.

Signed-off-by: Pan Bian 
Acked-by: Charles Keepax 
Fixes: f05259a6ffa4 ("clk: wm831x: Add initial WM831x clock driver")
Signed-off-by: Stephen Boyd 
Signed-off-by: Greg Kroah-Hartman

clk: qcom: ipq806x: Fix board clk rates

2017-01-12T10:39:26+00:00

commit cbf2e548ca8ad4bb274d014e9a70bd841d29948e upstream.

The clocks on these boards run at 25 MHz, not 19.2 and 27 like
other platforms. Unfortunately I copy/pasted from other similar
SoCs but forgot this one is different. Fix it.

Fixes: a085f877a882 ("clk: qcom: Move cxo/pxo/xo into dt files")
Signed-off-by: Stephen Boyd 
Signed-off-by: Greg Kroah-Hartman

clk: renesas: cpg-mssr: Fix inverted debug check

2017-01-12T10:39:24+00:00

commit bc4725d9029e2c8205fbaf1105e193d1c4e463bb upstream.

The intention was to enable the checks if debugging is enabled, not
disabled.

Fixes: f793d1e51705b276 ("clk: shmobile: Add new CPG/MSSR driver core")
Signed-off-by: Geert Uytterhoeven 
Signed-off-by: Greg Kroah-Hartman

clk: bcm2835: Avoid overwriting the div info when disabling a pll_div clk

2017-01-09T07:32:18+00:00

commit 68af4fa8f39b542a6cde7ac19518d88e9b3099dc upstream.

bcm2835_pll_divider_off() is resetting the divider field in the A2W reg
to zero when disabling the clock.

Make sure we preserve this value by reading the previous a2w_reg value
first and ORing the result with A2W_PLL_CHANNEL_DISABLE.

Signed-off-by: Boris Brezillon 
Fixes: 41691b8862e2 ("clk: bcm2835: Add support for programming the audio domain clocks")
Reviewed-by: Eric Anholt 
Signed-off-by: Stephen Boyd 
Signed-off-by: Greg Kroah-Hartman

clk: ti: omap36xx: Work around sprz319 advisory 2.1

2017-01-06T09:40:12+00:00

commit 035cd485a47dda64f25ccf8a90b11a07d0b7aa7a upstream.

The OMAP36xx DPLL5, driving EHCI USB, can be subject to a long-term
frequency drift. The frequency drift magnitude depends on the VCO update
rate, which is inversely proportional to the PLL divider. The kernel
DPLL configuration code results in a high value for the divider, leading
to a long term drift high enough to cause USB transmission errors. In
the worst case the USB PHY's ULPI interface can stop responding,
breaking USB operation completely. This manifests itself on the
Beagleboard xM by the LAN9514 reporting 'Cannot enable port 2. Maybe the
cable is bad?' in the kernel log.

Errata sprz319 advisory 2.1 documents PLL values that minimize the
drift. Use them automatically when DPLL5 is used for USB operation,
which we detect based on the requested clock rate. The clock framework
will still compute the PLL parameters and resulting rate as usual, but
the PLL M and N values will then be overridden. This can result in the
effective clock rate being slightly different than the rate cached by
the clock framework, but won't cause any adverse effect to USB
operation.

Signed-off-by: Richard Watts 
[Upported from v3.2 to v4.9]
Signed-off-by: Laurent Pinchart 
Tested-by: Ladislav Michl 
Signed-off-by: Stephen Boyd 
Cc: Adam Ford 
Signed-off-by: Greg Kroah-Hartman