linux-toradex.git/drivers/clk, branch v3.18.13

clk: divider: fix calculation of maximal parent rate for a given divider

2015-04-24T21:14:11+00:00

[ Upstream commit da321133b53caf7889ed3ca1dabe4cc368db2604 ]

The rate provided at the output of a clk-divider is calculated as:

	DIV_ROUND_UP(parent_rate, div)

since commit b11d282dbea2 (clk: divider: fix rate calculation for
fractional rates). So to yield a rate not bigger than r parent_rate
must be <= r * div.

The effect of choosing a parent rate that is too big as was done before
this patch results in wrongly ruling out good dividers.

Note that this is not a complete fix as __clk_round_rate might return a
value >= its 2nd parameter. Also for dividers with
CLK_DIVIDER_ROUND_CLOSEST set the calculation is not accurate. But this
fixes the test case by Sascha Hauer that uses a chain of three dividers
under a fixed clock.

Fixes: b11d282dbea2 (clk: divider: fix rate calculation for fractional rates)
Suggested-by: Sascha Hauer 
Signed-off-by: Uwe Kleine-König 
Acked-by: Sascha Hauer 
Signed-off-by: Michael Turquette 
Signed-off-by: Sasha Levin

clk: divider: fix selection of divider when rounding to closest

2015-04-24T21:14:10+00:00

[ Upstream commit 26bac95aa88c2b1747808c0b885abe7814c0165d ]

It's an invalid approach to assume that among two divider values
the one nearer the exact divider is the better one.

Assume a parent rate of 1000 Hz, a divider with CLK_DIVIDER_POWER_OF_TWO
and a target rate of 89 Hz. The exact divider is ~ 11.236 so 8 and 16
are the candidates to choose from yielding rates 125 Hz and 62.5 Hz
respectivly. While 8 is nearer to 11.236 than 16 is, the latter is still
the better divider as 62.5 is nearer to 89 than 125 is.

Fixes: 774b514390b1 (clk: divider: Add round to closest divider)
Signed-off-by: Uwe Kleine-König 
Acked-by: Sascha Hauer 
Acked-by: Maxime Coquelin 
Signed-off-by: Michael Turquette 
Signed-off-by: Sasha Levin

clk-gate: fix bit # check in clk_register_gate()

2015-03-24T01:02:54+00:00

commit 2e9dcdae4068460c45a308dd891be5248260251c upstream.

In case CLK_GATE_HIWORD_MASK flag is passed to clk_register_gate(), the bit #
should be no higher than 15, however the corresponding check is obviously off-
by-one.

Fixes: 045779942c04 ("clk: gate: add CLK_GATE_HIWORD_MASK")
Signed-off-by: Sergei Shtylyov 
Signed-off-by: Michael Turquette 
Signed-off-by: Greg Kroah-Hartman

sunxi: clk: Set sun6i-pll1 n_start = 1

2015-03-24T01:02:47+00:00

commit 76820fcf7aa5a418b69cb7bed31b62d1feb1d6ad upstream.

For all pll-s on sun6i n == 0 means use a multiplier of 1, rather then 0 as
it means on sun4i / sun5i / sun7i. n_start = 1 is already correctly set
for sun6i pll6, but was missing for pll1, this commit fixes this.

Cc: Chen-Yu Tsai 
Signed-off-by: Hans de Goede 
Signed-off-by: Maxime Ripard 
Signed-off-by: Greg Kroah-Hartman

clk: Fix debugfs clk removal before inited

2015-03-24T01:02:46+00:00

commit 52bba9809a954d72bc77773bd560b9724b495eb7 upstream.

Some of the clks can be registered & unregistered before the clk related debugfs
entries are initialized at late_initcall. In the unregister path checking for only
dentry before clk_debug_init() would lead dangling pointers in the debug clk list,
because the list is already populated in register path and the clk pointer freed in
unregister path.
The side effect of not removing it from the list is either a null pointer
dereference or if lucky to boot the system, the number of clk entries in
debugfs disappear.

We could add more checks like if (inited && !clk->dentry) but just removing
the check for dentry made more sense as debugfs_remove_recursive() seems to be
safe with null pointers. This will ensure that the unregistering clk would be
removed from the debug list in all the code paths.

Without this patch kernel would crash with log:
Unable to handle kernel NULL pointer dereference at virtual address 00000000
pgd = c0204000
[00000000] *pgd=00000000
Internal error: Oops: 5 [#1] SMP ARM
Modules linked in:
CPU: 1 PID: 1 Comm: swapper/0 Tainted: G    B          3.19.0-rc3-00007-g412f9ba-dirty #840
Hardware name: Qualcomm (Flattened Device Tree)
task: ed948000 ti: ed944000 task.ti: ed944000
PC is at strlen+0xc/0x40
LR is at __create_file+0x64/0x1dc
pc : []    lr : []    psr: 60000013
sp : ed945e40  ip : ed945e50  fp : ed945e4c
r10: 00000000  r9 : c1006094  r8 : 00000000
r7 : 000041ed  r6 : 00000000  r5 : ed4af998  r4 : c11b5e28
r3 : 00000000  r2 : ed945e38  r1 : a0000013  r0 : 00000000
Flags: nZCv  IRQs on  FIQs on  Mode SVC_32  ISA ARM  Segment kernel
Control: 10c5787d  Table: 8020406a  DAC: 00000015
Process swapper/0 (pid: 1, stack limit = 0xed944248)
Stack: (0xed945e40 to 0xed946000)
5e40: ed945e7c ed945e50 c049f1c4 c04ee604 c0fc2fa4 00000000 ecb748c0 c11c2b80
5e60: c0beec04 0000011c c0fc2fa4 00000000 ed945e94 ed945e80 c049f3e0 c049f16c
5e80: 00000000 00000000 ed945eac ed945e98 c08cbc50 c049f3c0 ecb748c0 c11c2b80
5ea0: ed945ed4 ed945eb0 c0fc3080 c08cbc30 c0beec04 c107e1d8 ecdf0600 c107e1d8
5ec0: c107e1d8 ecdf0600 ed945f54 ed945ed8 c0208ed4 c0fc2fb0 c026a784 c04ee628
5ee0: ed945f0c ed945ef0 c0f5d600 c04ee604 c0f5d5ec ef7fcc7d c0b40ecc 0000011c
5f00: ed945f54 ed945f10 c026a994 c0f5d5f8 c04ecc00 00000007 ef7fcc95 00000007
5f20: c0e90744 c0dd0884 ed945f54 c106cde0 00000007 c117f8c0 0000011c c0f5d5ec
5f40: c1006094 c100609c ed945f94 ed945f58 c0f5de34 c0208e50 00000007 00000007
5f60: c0f5d5ec be9b5ae0 00000000 c117f8c0 c0af1680 00000000 00000000 00000000
5f80: 00000000 00000000 ed945fac ed945f98 c0af169c c0f5dd2c ed944000 00000000
5fa0: 00000000 ed945fb0 c020f298 c0af168c 00000000 00000000 00000000 00000000
5fc0: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
5fe0: 00000000 00000000 00000000 00000000 00000013 00000000 ebcc6d33 bfffca73
[] (strlen) from [] (__create_file+0x64/0x1dc)
[] (__create_file) from [] (debugfs_create_dir+0x2c/0x34)
[] (debugfs_create_dir) from [] (clk_debug_create_one+0x2c/0x16c)
[] (clk_debug_create_one) from [] (clk_debug_init+0xdc/0x144)
[] (clk_debug_init) from [] (do_one_initcall+0x90/0x1e0)
[] (do_one_initcall) from [] (kernel_init_freeable+0x114/0x1e0)
[] (kernel_init_freeable) from [] (kernel_init+0x1c/0xfc)
[] (kernel_init) from [] (ret_from_fork+0x14/0x3c)
Code: c0b40ecc e1a0c00d e92dd800 e24cb004 (e5d02000)
---[ end trace b940e45b5e25c1e7 ]---

Fixes: 6314b6796e3c "clk: Don't hold prepare_lock across debugfs creation"
Signed-off-by: Srinivas Kandagatla 
Reviewed-by: Stephen Boyd 
Signed-off-by: Michael Turquette 
Signed-off-by: Greg Kroah-Hartman

clk: zynq: Force CPU_2X clock to be ungated

2015-03-24T01:02:46+00:00

commit 3dccfecdb867fe35b305a4e493ef5652b7d9d4cb upstream.

The CPU_2X clock does not have a classical in-kernel user, but is,
amongst other things, required for OCM and debug access. Make sure this
clock is not mistakenly disabled during boot up by enabling it in the
platform's clock driver.

Fixes: 0ee52b157b8e 'clk: zynq: Add clock controller driver'
Signed-off-by: Soren Brinkmann 
Signed-off-by: Michael Turquette 
Signed-off-by: Greg Kroah-Hartman

clk: at91: keep slow clk enabled to prevent system hang

2015-01-27T16:29:38+00:00

commit dca1a4b5ff6e2c25adeff366eb06270dadeab3db upstream.

All slow clk users are not properly claiming it (get + prepare + enable)
before using it.
If all users properly claiming this clock release it, the clock is
disabled, but faulty users still depends on it, and the system hangs.

This fix prevents the slow clock from being disabled, and should solve the
hanging issue, but offending drivers should be patched to properly claim
this clock.

Signed-off-by: Boris Brezillon 
Reported-by: Bo Shen 
Signed-off-by: Michael Turquette 
Signed-off-by: Greg Kroah-Hartman

clk: berlin: bg2q: remove non-exist "smemc" gate clock

2015-01-27T16:29:38+00:00

commit b71e8ecd57c8aae5b1815782c47b74ffe3efc09a upstream.

The "smemc" clock is removed on BG2Q SoCs. In fact, bit19 of clkenable
register is for nfc. Current code use bit19 for non-exist "smemc"
incorrectly, this prevents eMMC from working due to the sdhci's
"core" clk is still gated.

Signed-off-by: Jisheng Zhang 
Signed-off-by: Michael Turquette 
Signed-off-by: Greg Kroah-Hartman

clk: rockchip: fix rk3066 pll lock bit location

2015-01-27T16:29:38+00:00

commit 12551f0239b50c88352e3292dd7703382addbf5e upstream.

The bit locations indicating the locking status of the plls on rk3066 are
shifted by one to the right when compared to the rk3188, bits [7:4] instead
of [8:5] on the rk3188, thus indicating the locking state of the wrong pll
or a completely different information in case of the gpll.

The recently introduced pll init code exposed that problem on some rk3066
boards when it tried to bring the boot-pll value in line with the value
from the rate table.

Fix this by defining separate pll definitions for rk3066 with the correct
locking indices.

Signed-off-by: Heiko Stuebner 
Fixes: 2c14736c75db ("clk: rockchip: add clock driver for rk3188 and rk3066 clocks")
Tested-by: FUKAUMI Naoki 
Signed-off-by: Greg Kroah-Hartman

clk: rockchip: fix rk3288 cpuclk core dividers

2015-01-27T16:29:38+00:00

commit 9880d4277f6aab6b21404c824f9d9c652ba518ac upstream.

Commit 0e5bdb3f9fa5 (clk: rockchip: switch to using the new cpuclk type
for armclk) didn't take into account that the divider used on rk3288
are of the (n+1) type.

The rk3066 and rk3188 socs use more complex divider types making it
necessary for the list-elements to be the real register-values to write.

Therefore reduce divider values in the table accordingly so that they
really are the values that should be written to the registers and match
the dividers actually specified for the rk3288.

Reported-by: Sonny Rao 
Fixes: 0e5bdb3f9fa5 ("clk: rockchip: switch to using the new cpuclk type for armclk")
Signed-off-by: Heiko Stuebner 
Reviewed-by: Doug Anderson 
Signed-off-by: Greg Kroah-Hartman