We've been seeing some crashes at reboot test on rk3288-based systems,
which boards have not reset pin connected to NPOR, they reboot by
setting 0xfdb9 to RK3288_GLB_SRST_FST register. If the APLL works in
a high frequency mode, some IPs might hang during soft reset.
It appears that we can fix the
Hi Chris,
Am Dienstag, 10. November 2015, 17:35:31 schrieb Chris Zhong:
> We've been seeing some crashes at reboot test on rk3288-based systems,
> which boards have not reset pin connected to NPOR, they reboot by
> setting 0xfdb9 to RK3288_GLB_SRST_FST register. If the APLL works in
> a high
We've been seeing some crashes at reboot test on rk3288-based systems,
which boards have not reset pin connected to NPOR, they reboot by
setting 0xfdb9 to RK3288_GLB_SRST_FST register. If the APLL works in
a high frequency mode, some IPs might hang during soft reset.
It appears that we can fix the
Hi Chris,
one nit below, otherwise
Reviewed-by: Heiko Stuebner
Am Mittwoch, 11. November 2015, 13:48:11 schrieb Chris Zhong:
> We've been seeing some crashes at reboot test on rk3288-based systems,
> which boards have not reset pin connected to NPOR, they reboot by
> setting
Hi.
I am implementing clk and reset drivers for my SoCs.
(drivers/clk/uniphier/* and drivers/reset/uniphier/*)
In my SoCs, one hardware block contains various
registers for both clock and reset controlling.
(so, it is like a MFD system controller device).
I think it is a common case.
I am