linux-toradex.git/drivers/clk/samsung, branch v4.4.156 Linux kernel for Apalis and Colibri modules clk: samsung: exynos3250: Fix PLL rates 2018-05-30T05:49:16+00:00 Andrzej Hajda a.hajda@samsung.com 2018-02-16T14:57:48+00:00 3367b08ebc8e2aa4e170ef7ba4f094875f96e042 [ Upstream commit a8321e7887410a2b2e80ab89d1ef7b30562658ea ] Rates declared in PLL rate tables should match exactly rates calculated from PLL coefficients. If that is not the case, rate of the PLL's child clock might be set not as expected. For instance, if in the PLL rates table we have a 393216000 Hz entry and the real value as returned by the PLL's recalc_rate callback is 393216003, after setting PLL's clk rate to 393216000 clk_get_rate will return 393216003. If we now attempt to set rate of a PLL's child divider clock to 393216000/2 its rate will be 131072001, rather than 196608000. That is, the divider will be set to 3 instead of 2, because 393216003/2 is greater than 196608000. To fix this issue declared rates are changed to exactly match rates generated by the PLL, as calculated from the P, M, S, K coefficients. In this patch an erroneous P value for 74176002 output frequency is also corrected. Signed-off-by: Andrzej Hajda <a.hajda@samsung.com> Acked-by: Chanwoo Choi <cw00.choi@samsung.com> Acked-by: Tomasz Figa <tomasz.figa@gmail.com> Signed-off-by: Sylwester Nawrocki <s.nawrocki@samsung.com> Signed-off-by: Sasha Levin <alexander.levin@microsoft.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 
[ Upstream commit a8321e7887410a2b2e80ab89d1ef7b30562658ea ]

Rates declared in PLL rate tables should match exactly rates calculated
from PLL coefficients. If that is not the case, rate of the PLL's child clock
might be set not as expected. For instance, if in the PLL rates table we have
a 393216000 Hz entry and the real value as returned by the PLL's recalc_rate
callback is 393216003, after setting PLL's clk rate to 393216000 clk_get_rate
will return 393216003. If we now attempt to set rate of a PLL's child divider
clock to 393216000/2 its rate will be 131072001, rather than 196608000.
That is, the divider will be set to 3 instead of 2, because 393216003/2 is
greater than 196608000.

To fix this issue declared rates are changed to exactly match rates generated
by the PLL, as calculated from the P, M, S, K coefficients.

In this patch an erroneous P value for 74176002 output frequency is also
corrected.

Signed-off-by: Andrzej Hajda <a.hajda@samsung.com>
Acked-by: Chanwoo Choi <cw00.choi@samsung.com>
Acked-by: Tomasz Figa <tomasz.figa@gmail.com>
Signed-off-by: Sylwester Nawrocki <s.nawrocki@samsung.com>
Signed-off-by: Sasha Levin <alexander.levin@microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
clk: samsung: exynos5250: Fix PLL rates 2018-05-30T05:49:16+00:00 Andrzej Hajda a.hajda@samsung.com 2018-02-16T14:57:49+00:00 fb3371f30e1ae493565b7620bf7499020249370e [ Upstream commit 2ac051eeabaa411ef89ae7cd5bb8e60cb41ad780 ] Rates declared in PLL rate tables should match exactly rates calculated from PLL coefficients. If that is not the case, rate of the PLL's child clock might be set not as expected. For instance, if in the PLL rates table we have a 393216000 Hz entry and the real value as returned by the PLL's recalc_rate callback is 393216003, after setting PLL's clk rate to 393216000 clk_get_rate will return 393216003. If we now attempt to set rate of a PLL's child divider clock to 393216000/2 its rate will be 131072001, rather than 196608000. That is, the divider will be set to 3 instead of 2, because 393216003/2 is greater than 196608000. To fix this issue declared rates are changed to exactly match rates generated by the PLL, as calculated from the P, M, S, K coefficients. Signed-off-by: Andrzej Hajda <a.hajda@samsung.com> Acked-by: Chanwoo Choi <cw00.choi@samsung.com> Acked-by: Tomasz Figa <tomasz.figa@gmail.com> Signed-off-by: Sylwester Nawrocki <s.nawrocki@samsung.com> Signed-off-by: Sasha Levin <alexander.levin@microsoft.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 
[ Upstream commit 2ac051eeabaa411ef89ae7cd5bb8e60cb41ad780 ]

Rates declared in PLL rate tables should match exactly rates calculated
from PLL coefficients. If that is not the case, rate of the PLL's child clock
might be set not as expected. For instance, if in the PLL rates table we have
a 393216000 Hz entry and the real value as returned by the PLL's recalc_rate
callback is 393216003, after setting PLL's clk rate to 393216000 clk_get_rate
will return 393216003. If we now attempt to set rate of a PLL's child divider
clock to 393216000/2 its rate will be 131072001, rather than 196608000.
That is, the divider will be set to 3 instead of 2, because 393216003/2 is
greater than 196608000.

To fix this issue declared rates are changed to exactly match rates generated
by the PLL, as calculated from the P, M, S, K coefficients.

Signed-off-by: Andrzej Hajda <a.hajda@samsung.com>
Acked-by: Chanwoo Choi <cw00.choi@samsung.com>
Acked-by: Tomasz Figa <tomasz.figa@gmail.com>
Signed-off-by: Sylwester Nawrocki <s.nawrocki@samsung.com>
Signed-off-by: Sasha Levin <alexander.levin@microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
clk: samsung: exynos5433: Fix PLL rates 2018-05-30T05:49:16+00:00 Andrzej Hajda a.hajda@samsung.com 2018-02-16T14:57:51+00:00 ef4867ac69c6c7f3ce8d1a5ac17c25cf0be832d6 [ Upstream commit ab0447845cffc0fd752df2ccd6b4e34006000ce4 ] Rates declared in PLL rate tables should match exactly rates calculated from the PLL coefficients. If that is not the case, rate of the PLL's child clock might be set not as expected. For instance, if in the PLL rates table we have a 393216000 Hz entry and the real value as returned by the PLL's recalc_rate callback is 393216003, after setting PLL's clk rate to 393216000 clk_get_rate will return 393216003. If we now attempt to set rate of a PLL's child divider clock to 393216000/2 its rate will be 131072001, rather than 196608000. That is, the divider will be set to 3 instead of 2, because 393216003/2 is greater than 196608000. To fix this issue declared rates are changed to exactly match rates generated by the PLL, as calculated from the P, M, S, K coefficients. Signed-off-by: Andrzej Hajda <a.hajda@samsung.com> Acked-by: Tomasz Figa <tomasz.figa@gmail.com> Acked-by: Chanwoo Choi <cw00.choi@samsung.com> Signed-off-by: Sylwester Nawrocki <s.nawrocki@samsung.com> Signed-off-by: Sasha Levin <alexander.levin@microsoft.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 
[ Upstream commit ab0447845cffc0fd752df2ccd6b4e34006000ce4 ]

Rates declared in PLL rate tables should match exactly rates calculated from
the PLL coefficients. If that is not the case, rate of the PLL's child clock
might be set not as expected. For instance, if in the PLL rates table we have
a 393216000 Hz entry and the real value as returned by the PLL's recalc_rate
callback is 393216003, after setting PLL's clk rate to 393216000 clk_get_rate
will return 393216003. If we now attempt to set rate of a PLL's child divider
clock to 393216000/2 its rate will be 131072001, rather than 196608000.
That is, the divider will be set to 3 instead of 2, because 393216003/2 is
greater than 196608000.

To fix this issue declared rates are changed to exactly match rates generated
by the PLL, as calculated from the P, M, S, K coefficients.

Signed-off-by: Andrzej Hajda <a.hajda@samsung.com>
Acked-by: Tomasz Figa <tomasz.figa@gmail.com>
Acked-by: Chanwoo Choi <cw00.choi@samsung.com>
Signed-off-by: Sylwester Nawrocki <s.nawrocki@samsung.com>
Signed-off-by: Sasha Levin <alexander.levin@microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
clk: samsung: exynos5260: Fix PLL rates 2018-05-30T05:49:15+00:00 Andrzej Hajda a.hajda@samsung.com 2018-02-16T14:57:50+00:00 bff5d67e594594d2455ca6cbaebbeb606c414c6c [ Upstream commit cdb68fbd4e7962be742c4f29475220c5bf28d8a5 ] Rates declared in PLL rate tables should match exactly rates calculated from the PLL coefficients. If that is not the case, rate of the PLL's child clock might be set not as expected. For instance, if in the PLL rates table we have a 393216000 Hz entry and the real value as returned by the PLL's recalc_rate callback is 393216003, after setting PLL's clk rate to 393216000 clk_get_rate will return 393216003. If we now attempt to set rate of a PLL's child divider clock to 393216000/2 its rate will be 131072001, rather than 196608000. That is, the divider will be set to 3 instead of 2, because 393216003/2 is greater than 196608000. To fix this issue declared rates are changed to exactly match rates generated by the PLL, as calculated from the P, M, S, K coefficients. Signed-off-by: Andrzej Hajda <a.hajda@samsung.com> Acked-by: Tomasz Figa <tomasz.figa@gmail.com> Acked-by: Chanwoo Choi <cw00.choi@samsung.com> Signed-off-by: Sylwester Nawrocki <s.nawrocki@samsung.com> Signed-off-by: Sasha Levin <alexander.levin@microsoft.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 
[ Upstream commit cdb68fbd4e7962be742c4f29475220c5bf28d8a5 ]

Rates declared in PLL rate tables should match exactly rates calculated from
the PLL coefficients. If that is not the case, rate of the PLL's child clock
might be set not as expected. For instance, if in the PLL rates table we have
a 393216000 Hz entry and the real value as returned by the PLL's recalc_rate
callback is 393216003, after setting PLL's clk rate to 393216000 clk_get_rate
will return 393216003. If we now attempt to set rate of a PLL's child divider
clock to 393216000/2 its rate will be 131072001, rather than 196608000.
That is, the divider will be set to 3 instead of 2, because 393216003/2 is
greater than 196608000.

To fix this issue declared rates are changed to exactly match rates generated
by the PLL, as calculated from the P, M, S, K coefficients.

Signed-off-by: Andrzej Hajda <a.hajda@samsung.com>
Acked-by: Tomasz Figa <tomasz.figa@gmail.com>
Acked-by: Chanwoo Choi <cw00.choi@samsung.com>
Signed-off-by: Sylwester Nawrocki <s.nawrocki@samsung.com>
Signed-off-by: Sasha Levin <alexander.levin@microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
clk: samsung: s3c2410: Fix PLL rates 2018-05-30T05:49:15+00:00 Andrzej Hajda a.hajda@samsung.com 2018-02-16T14:57:53+00:00 72d903272fd9440623d4646bc302618c3098e5b9 [ Upstream commit 179db533c08431f509a3823077549773d519358b ] Rates declared in PLL rate tables should match exactly rates calculated from the PLL coefficients. If that is not the case, rate of the PLL's child clock might be set not as expected. For instance, if in the PLL rates table we have a 393216000 Hz entry and the real value as returned by the PLL's recalc_rate callback is 393216003, after setting PLL's clk rate to 393216000 clk_get_rate will return 393216003. If we now attempt to set rate of a PLL's child divider clock to 393216000/2 its rate will be 131072001, rather than 196608000. That is, the divider will be set to 3 instead of 2, because 393216003/2 is greater than 196608000. To fix this issue declared rates are changed to exactly match rates generated by the PLL, as calculated from the P, M, S, K coefficients. Signed-off-by: Andrzej Hajda <a.hajda@samsung.com> Acked-by: Tomasz Figa <tomasz.figa@gmail.com> Acked-by: Chanwoo Choi <cw00.choi@samsung.com> Signed-off-by: Sylwester Nawrocki <s.nawrocki@samsung.com> Signed-off-by: Sasha Levin <alexander.levin@microsoft.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 
[ Upstream commit 179db533c08431f509a3823077549773d519358b ]

Rates declared in PLL rate tables should match exactly rates calculated from
the PLL coefficients. If that is not the case, rate of the PLL's child clock
might be set not as expected. For instance, if in the PLL rates table we have
a 393216000 Hz entry and the real value as returned by the PLL's recalc_rate
callback is 393216003, after setting PLL's clk rate to 393216000 clk_get_rate
will return 393216003. If we now attempt to set rate of a PLL's child divider
clock to 393216000/2 its rate will be 131072001, rather than 196608000.
That is, the divider will be set to 3 instead of 2, because 393216003/2 is
greater than 196608000.

To fix this issue declared rates are changed to exactly match rates generated
by the PLL, as calculated from the P, M, S, K coefficients.

Signed-off-by: Andrzej Hajda <a.hajda@samsung.com>
Acked-by: Tomasz Figa <tomasz.figa@gmail.com>
Acked-by: Chanwoo Choi <cw00.choi@samsung.com>
Signed-off-by: Sylwester Nawrocki <s.nawrocki@samsung.com>
Signed-off-by: Sasha Levin <alexander.levin@microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
clk: exynos: use irqsave version of spin_lock to avoid deadlock with irqs 2016-03-03T23:07:17+00:00 Marek Szyprowski m.szyprowski@samsung.com 2015-12-11T14:38:40+00:00 7ca59689c947bda700e07fdea4d9e4f582601c68 commit 6b4feaea251a97bf08c7d41eabdec07f63a11073 upstream. It is allowed to enable/disable clocks from interrupts, so common Exynos ARM clock management code for CPUfreq should use 'irqsave' version of spin_lock calls to avoid potential deadlock caused by spin_lock recursion. The same spin_lock is used by gate/mux clocks during enable/disable calls. This deadlock, can be reproduced by enabling CPUfreq (ondemand or userspace) and decoding video with s5p-mfc driver. Relevant stack trace: [ 5928.061534] BUG: spinlock recursion on CPU#0, bash/1252 [ 5928.061609] lock: 0xee80454c, .magic: dead4ead, .owner: bash/1252, .owner_cpu: 0 [ 5928.068586] CPU: 0 PID: 1252 Comm: bash Tainted: G W 4.4.0-rc4-00001-g447a7fd #678 [ 5928.077260] Hardware name: SAMSUNG EXYNOS (Flattened Device Tree) [ 5928.083359] [<c00153dc>] (unwind_backtrace) from [<c00121b4>] (show_stack+0x10/0x14) [ 5928.091072] [<c00121b4>] (show_stack) from [<c0213e28>] (dump_stack+0x68/0xb8) [ 5928.098275] [<c0213e28>] (dump_stack) from [<c005c1ec>] (do_raw_spin_lock+0x184/0x1ac) [ 5928.106177] [<c005c1ec>] (do_raw_spin_lock) from [<c05cfa98>] (_raw_spin_lock_irqsave+0x20/0x28) [ 5928.114943] [<c05cfa98>] (_raw_spin_lock_irqsave) from [<c0468698>] (clk_gate_endisable+0x24/0x98) [ 5928.123882] [<c0468698>] (clk_gate_endisable) from [<c0464d40>] (clk_core_disable+0x60/0x84) [ 5928.132299] [<c0464d40>] (clk_core_disable) from [<c0465e00>] (clk_disable+0x24/0x30) [ 5928.140117] [<c0465e00>] (clk_disable) from [<c03f3b80>] (s5p_mfc_handle_frame+0x254/0x860) [ 5928.148445] [<c03f3b80>] (s5p_mfc_handle_frame) from [<c03f4b34>] (s5p_mfc_irq+0x890/0xa24) [ 5928.156778] [<c03f4b34>] (s5p_mfc_irq) from [<c00627bc>] (handle_irq_event_percpu+0x50/0x14c) [ 5928.165283] [<c00627bc>] (handle_irq_event_percpu) from [<c00628f0>] (handle_irq_event+0x38/0x5c) [ 5928.174143] [<c00628f0>] (handle_irq_event) from [<c0065864>] (handle_fasteoi_irq+0xdc/0x1a4) [ 5928.182645] [<c0065864>] (handle_fasteoi_irq) from [<c0062090>] (generic_handle_irq+0x18/0x28) [ 5928.191236] [<c0062090>] (generic_handle_irq) from [<c00621a4>] (__handle_domain_irq+0x6c/0xdc) [ 5928.199917] [<c00621a4>] (__handle_domain_irq) from [<c0009470>] (gic_handle_irq+0x4c/0x98) [ 5928.208249] [<c0009470>] (gic_handle_irq) from [<c0012c54>] (__irq_svc+0x54/0x90) [ 5928.215709] Exception stack(0xeddb5cb8 to 0xeddb5d00) [ 5928.220745] 5ca0: ee80454c faddfadc [ 5928.228906] 5cc0: 00000000 01000001 ee831ce0 f8114200 ee807c00 01130520 00000403 eddb5d84 [ 5928.237063] 5ce0: ee807c48 2faf0800 ee807c0c eddb5d08 c046b618 c046b634 20000053 ffffffff [ 5928.245225] [<c0012c54>] (__irq_svc) from [<c046b634>] (exynos_cpuclk_notifier_cb+0x170/0x270) [ 5928.253823] [<c046b634>] (exynos_cpuclk_notifier_cb) from [<c003cb58>] (notifier_call_chain+0x44/0x84) [ 5928.263106] [<c003cb58>] (notifier_call_chain) from [<c003ccd4>] (__srcu_notifier_call_chain+0x6c/0x9c) [ 5928.272480] [<c003ccd4>] (__srcu_notifier_call_chain) from [<c003cd1c>] (srcu_notifier_call_chain+0x18/0x20) [ 5928.282288] [<c003cd1c>] (srcu_notifier_call_chain) from [<c0464ed0>] (__clk_notify+0x6c/0x74) [ 5928.290881] [<c0464ed0>] (__clk_notify) from [<c0465388>] (clk_propagate_rate_change+0xa0/0xac) [ 5928.299561] [<c0465388>] (clk_propagate_rate_change) from [<c0465378>] (clk_propagate_rate_change+0x90/0xac) [ 5928.309370] [<c0465378>] (clk_propagate_rate_change) from [<c04666fc>] (clk_core_set_rate_nolock+0x64/0xa8) [ 5928.319091] [<c04666fc>] (clk_core_set_rate_nolock) from [<c0466760>] (clk_set_rate+0x20/0x30) [ 5928.327686] [<c0466760>] (clk_set_rate) from [<c0428c70>] (set_target+0xe8/0x23c) [ 5928.335152] [<c0428c70>] (set_target) from [<c04244d0>] (__cpufreq_driver_target+0x184/0x29c) [ 5928.343655] [<c04244d0>] (__cpufreq_driver_target) from [<c0427128>] (cpufreq_set+0x44/0x64) [ 5928.352074] [<c0427128>] (cpufreq_set) from [<c0423948>] (store_scaling_setspeed+0x5c/0x74) [ 5928.360407] [<c0423948>] (store_scaling_setspeed) from [<c04238d0>] (store+0x7c/0x98) [ 5928.368221] [<c04238d0>] (store) from [<c0132540>] (sysfs_kf_write+0x44/0x48) [ 5928.375338] [<c0132540>] (sysfs_kf_write) from [<c0131b9c>] (kernfs_fop_write+0xb8/0x1bc) [ 5928.383496] [<c0131b9c>] (kernfs_fop_write) from [<c00d71f8>] (__vfs_write+0x2c/0xd4) [ 5928.391308] [<c00d71f8>] (__vfs_write) from [<c00d7de8>] (vfs_write+0xa0/0x144) [ 5928.398598] [<c00d7de8>] (vfs_write) from [<c00d8048>] (SyS_write+0x44/0x84) [ 5928.405631] [<c00d8048>] (SyS_write) from [<c000f540>] (ret_fast_syscall+0x0/0x3c) Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com> Signed-off-by: Sylwester Nawrocki <s.nawrocki@samsung.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 
commit 6b4feaea251a97bf08c7d41eabdec07f63a11073 upstream.

It is allowed to enable/disable clocks from interrupts, so common Exynos
ARM clock management code for CPUfreq should use 'irqsave' version of
spin_lock calls to avoid potential deadlock caused by spin_lock recursion.
The same spin_lock is used by gate/mux clocks during enable/disable calls.

This deadlock, can be reproduced by enabling CPUfreq (ondemand or
userspace) and decoding video with s5p-mfc driver.

Relevant stack trace:
[ 5928.061534] BUG: spinlock recursion on CPU#0, bash/1252
[ 5928.061609]  lock: 0xee80454c, .magic: dead4ead, .owner: bash/1252, .owner_cpu: 0
[ 5928.068586] CPU: 0 PID: 1252 Comm: bash Tainted: G        W       4.4.0-rc4-00001-g447a7fd #678
[ 5928.077260] Hardware name: SAMSUNG EXYNOS (Flattened Device Tree)
[ 5928.083359] [<c00153dc>] (unwind_backtrace) from [<c00121b4>] (show_stack+0x10/0x14)
[ 5928.091072] [<c00121b4>] (show_stack) from [<c0213e28>] (dump_stack+0x68/0xb8)
[ 5928.098275] [<c0213e28>] (dump_stack) from [<c005c1ec>] (do_raw_spin_lock+0x184/0x1ac)
[ 5928.106177] [<c005c1ec>] (do_raw_spin_lock) from [<c05cfa98>] (_raw_spin_lock_irqsave+0x20/0x28)
[ 5928.114943] [<c05cfa98>] (_raw_spin_lock_irqsave) from [<c0468698>] (clk_gate_endisable+0x24/0x98)
[ 5928.123882] [<c0468698>] (clk_gate_endisable) from [<c0464d40>] (clk_core_disable+0x60/0x84)
[ 5928.132299] [<c0464d40>] (clk_core_disable) from [<c0465e00>] (clk_disable+0x24/0x30)
[ 5928.140117] [<c0465e00>] (clk_disable) from [<c03f3b80>] (s5p_mfc_handle_frame+0x254/0x860)
[ 5928.148445] [<c03f3b80>] (s5p_mfc_handle_frame) from [<c03f4b34>] (s5p_mfc_irq+0x890/0xa24)
[ 5928.156778] [<c03f4b34>] (s5p_mfc_irq) from [<c00627bc>] (handle_irq_event_percpu+0x50/0x14c)
[ 5928.165283] [<c00627bc>] (handle_irq_event_percpu) from [<c00628f0>] (handle_irq_event+0x38/0x5c)
[ 5928.174143] [<c00628f0>] (handle_irq_event) from [<c0065864>] (handle_fasteoi_irq+0xdc/0x1a4)
[ 5928.182645] [<c0065864>] (handle_fasteoi_irq) from [<c0062090>] (generic_handle_irq+0x18/0x28)
[ 5928.191236] [<c0062090>] (generic_handle_irq) from [<c00621a4>] (__handle_domain_irq+0x6c/0xdc)
[ 5928.199917] [<c00621a4>] (__handle_domain_irq) from [<c0009470>] (gic_handle_irq+0x4c/0x98)
[ 5928.208249] [<c0009470>] (gic_handle_irq) from [<c0012c54>] (__irq_svc+0x54/0x90)
[ 5928.215709] Exception stack(0xeddb5cb8 to 0xeddb5d00)
[ 5928.220745] 5ca0:                                                       ee80454c faddfadc
[ 5928.228906] 5cc0: 00000000 01000001 ee831ce0 f8114200 ee807c00 01130520 00000403 eddb5d84
[ 5928.237063] 5ce0: ee807c48 2faf0800 ee807c0c eddb5d08 c046b618 c046b634 20000053 ffffffff
[ 5928.245225] [<c0012c54>] (__irq_svc) from [<c046b634>] (exynos_cpuclk_notifier_cb+0x170/0x270)
[ 5928.253823] [<c046b634>] (exynos_cpuclk_notifier_cb) from [<c003cb58>] (notifier_call_chain+0x44/0x84)
[ 5928.263106] [<c003cb58>] (notifier_call_chain) from [<c003ccd4>] (__srcu_notifier_call_chain+0x6c/0x9c)
[ 5928.272480] [<c003ccd4>] (__srcu_notifier_call_chain) from [<c003cd1c>] (srcu_notifier_call_chain+0x18/0x20)
[ 5928.282288] [<c003cd1c>] (srcu_notifier_call_chain) from [<c0464ed0>] (__clk_notify+0x6c/0x74)
[ 5928.290881] [<c0464ed0>] (__clk_notify) from [<c0465388>] (clk_propagate_rate_change+0xa0/0xac)
[ 5928.299561] [<c0465388>] (clk_propagate_rate_change) from [<c0465378>] (clk_propagate_rate_change+0x90/0xac)
[ 5928.309370] [<c0465378>] (clk_propagate_rate_change) from [<c04666fc>] (clk_core_set_rate_nolock+0x64/0xa8)
[ 5928.319091] [<c04666fc>] (clk_core_set_rate_nolock) from [<c0466760>] (clk_set_rate+0x20/0x30)
[ 5928.327686] [<c0466760>] (clk_set_rate) from [<c0428c70>] (set_target+0xe8/0x23c)
[ 5928.335152] [<c0428c70>] (set_target) from [<c04244d0>] (__cpufreq_driver_target+0x184/0x29c)
[ 5928.343655] [<c04244d0>] (__cpufreq_driver_target) from [<c0427128>] (cpufreq_set+0x44/0x64)
[ 5928.352074] [<c0427128>] (cpufreq_set) from [<c0423948>] (store_scaling_setspeed+0x5c/0x74)
[ 5928.360407] [<c0423948>] (store_scaling_setspeed) from [<c04238d0>] (store+0x7c/0x98)
[ 5928.368221] [<c04238d0>] (store) from [<c0132540>] (sysfs_kf_write+0x44/0x48)
[ 5928.375338] [<c0132540>] (sysfs_kf_write) from [<c0131b9c>] (kernfs_fop_write+0xb8/0x1bc)
[ 5928.383496] [<c0131b9c>] (kernfs_fop_write) from [<c00d71f8>] (__vfs_write+0x2c/0xd4)
[ 5928.391308] [<c00d71f8>] (__vfs_write) from [<c00d7de8>] (vfs_write+0xa0/0x144)
[ 5928.398598] [<c00d7de8>] (vfs_write) from [<c00d8048>] (SyS_write+0x44/0x84)
[ 5928.405631] [<c00d8048>] (SyS_write) from [<c000f540>] (ret_fast_syscall+0x0/0x3c)

Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com>
Signed-off-by: Sylwester Nawrocki <s.nawrocki@samsung.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Merge tag 'armsoc-dt' of git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc 2015-11-10T23:06:26+00:00 Linus Torvalds torvalds@linux-foundation.org 2015-11-10T23:06:26+00:00 c0d6fe2f01c475cc137d90607a07578586883df8 Pull ARM DT updates from Olof Johansson: "As usual, this is the massive branch we have for each release. Lots of various updates and additions of hardware descriptions on existing hardware, as well as the usual additions of new boards and SoCs. This is also the first release where we've started mixing 64- and 32-bit DT updates in one branch. (Specific details on what's actually here and new is pretty easy to tell from the diffstat, so there's little point in duplicating listing it here)" * tag 'armsoc-dt' of git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc: (499 commits) ARM: dts: uniphier: add system-bus-controller nodes ARM64: juno: disable NOR flash node by default ARM: dts: uniphier: add outer cache controller nodes arm64: defconfig: Enable PCI generic host bridge by default arm64: Juno: Add support for the PCIe host bridge on Juno R1 Documentation: of: Document the bindings used by Juno R1 PCIe host bridge ARM: dts: uniphier: add I2C aliases for ProXstream2 boards dts/Makefile: Add build support for LS2080a QDS & RDB board DTS dts/ls2080a: Add DTS support for LS2080a QDS & RDB boards dts/ls2080a: Update Simulator DTS to add support of various peripherals dts/ls2080a: Remove text about writing to Free Software Foundation dts/ls2080a: Update DTSI to add support of various peripherals doc: DTS: Update DWC3 binding to provide reference to generic bindings doc/bindings: Update GPIO devicetree binding documentation for LS2080A Documentation/dts: Move FSL board-specific bindings out of /powerpc Documentation: DT: Add entry for FSL LS2080A QDS and RDB boards arm64: Rename FSL LS2085A SoC support code to LS2080A arm64: Use generic Layerscape SoC family naming ARM: dts: uniphier: add ProXstream2 Vodka board support ARM: dts: uniphier: add ProXstream2 Gentil board support ... 
Pull ARM DT updates from Olof Johansson:
 "As usual, this is the massive branch we have for each release.  Lots
  of various updates and additions of hardware descriptions on existing
  hardware, as well as the usual additions of new boards and SoCs.

  This is also the first release where we've started mixing 64- and
  32-bit DT updates in one branch.

  (Specific details on what's actually here and new is pretty easy to
  tell from the diffstat, so there's little point in duplicating listing
  it here)"

* tag 'armsoc-dt' of git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc: (499 commits)
  ARM: dts: uniphier: add system-bus-controller nodes
  ARM64: juno: disable NOR flash node by default
  ARM: dts: uniphier: add outer cache controller nodes
  arm64: defconfig: Enable PCI generic host bridge by default
  arm64: Juno: Add support for the PCIe host bridge on Juno R1
  Documentation: of: Document the bindings used by Juno R1 PCIe host bridge
  ARM: dts: uniphier: add I2C aliases for ProXstream2 boards
  dts/Makefile: Add build support for LS2080a QDS & RDB board DTS
  dts/ls2080a: Add DTS support for LS2080a QDS & RDB boards
  dts/ls2080a: Update Simulator DTS to add support of various peripherals
  dts/ls2080a: Remove text about writing to Free Software Foundation
  dts/ls2080a: Update DTSI to add support of various peripherals
  doc: DTS: Update DWC3 binding to provide reference to generic bindings
  doc/bindings: Update GPIO devicetree binding documentation for LS2080A
  Documentation/dts: Move FSL board-specific bindings out of /powerpc
  Documentation: DT: Add entry for FSL LS2080A QDS and RDB boards
  arm64: Rename FSL LS2085A SoC support code to LS2080A
  arm64: Use generic Layerscape SoC family naming
  ARM: dts: uniphier: add ProXstream2 Vodka board support
  ARM: dts: uniphier: add ProXstream2 Gentil board support
  ...
Merge branch 'next/arm64' into next/dt 2015-11-10T00:35:19+00:00 Olof Johansson olof@lixom.net 2015-11-10T00:35:19+00:00 3e4dda70cc989a4f8079541972942609229e9f55 Merging in the few patches I had kept separate from main next/dt, since others got merged here directly. * next/arm64: arm64: defconfig: Enable PCI generic host bridge by default arm64: Juno: Add support for the PCIe host bridge on Juno R1 Documentation: of: Document the bindings used by Juno R1 PCIe host bridge arm64: dts: mt8173: Add clocks for SCPSYS unit arm64: dts: mt8173: Add subsystem clock controller device nodes + Linux 4.3-rc5 
Merging in the few patches I had kept separate from main next/dt, since others
got merged here directly.

* next/arm64:
  arm64: defconfig: Enable PCI generic host bridge by default
  arm64: Juno: Add support for the PCIe host bridge on Juno R1
  Documentation: of: Document the bindings used by Juno R1 PCIe host bridge
  arm64: dts: mt8173: Add clocks for SCPSYS unit
  arm64: dts: mt8173: Add subsystem clock controller device nodes
  + Linux 4.3-rc5
clk: samsung: exynos5250: Add DISP1 clocks 2015-10-23T19:31:18+00:00 Tomeu Vizoso tomeu.vizoso@collabora.com 2015-10-15T10:31:23+00:00 b4dc272b60fd7b43ff5b9ef89714d38c65db2cdb When the DISP1 power domain is powered off, there's two clocks that need to be temporarily reparented to OSC, and back to their original parents when the domain is powered on again. We expose these two clocks in the DT bindings so that the DT node of the power domain can reference them. Signed-off-by: Tomeu Vizoso <tomeu.vizoso@collabora.com> Acked-by: Stephen Boyd <sboyd@codeaurora.org> Signed-off-by: Krzysztof Kozlowski <k.kozlowski@samsung.com> Signed-off-by: Kukjin Kim <kgene@kernel.org> 
When the DISP1 power domain is powered off, there's two clocks that need
to be temporarily reparented to OSC, and back to their original parents
when the domain is powered on again.

We expose these two clocks in the DT bindings so that the DT node of the
power domain can reference them.

Signed-off-by: Tomeu Vizoso <tomeu.vizoso@collabora.com>
Acked-by: Stephen Boyd <sboyd@codeaurora.org>
Signed-off-by: Krzysztof Kozlowski <k.kozlowski@samsung.com>
Signed-off-by: Kukjin Kim <kgene@kernel.org>
clk: samsung: exynos7: Staticize file scope symbols 2015-10-02T18:35:32+00:00 Stephen Boyd sboyd@codeaurora.org 2015-10-02T18:34:34+00:00 12b5aa61ee1d9425c82e35290ec76db1bc0a0614 drivers/clk/samsung/clk-exynos7.c:896:33: warning: symbol 'fixed_rate_clks_fsys0' was not declared. Should it be static? drivers/clk/samsung/clk-exynos7.c:1010:33: warning: symbol 'fixed_rate_clks_fsys1' was not declared. Should it be static? Cc: Sylwester Nawrocki <s.nawrocki@samsung.com> Signed-off-by: Stephen Boyd <sboyd@codeaurora.org> 
drivers/clk/samsung/clk-exynos7.c:896:33:
warning: symbol 'fixed_rate_clks_fsys0' was not declared. Should
it be static?
drivers/clk/samsung/clk-exynos7.c:1010:33:
warning: symbol 'fixed_rate_clks_fsys1' was not declared. Should
it be static?

Cc: Sylwester Nawrocki <s.nawrocki@samsung.com>
Signed-off-by: Stephen Boyd <sboyd@codeaurora.org>