RK3328: watchdog fails to reset on Radxa Rock Pi E

[Simonas Kazlauskas]

Hello everyone,

I have recently started looking at Rockchip-based devices and recently 
acquired a Rock Pi E to play with. However quite quickly I have found that the 
watchdog isn't able to reset my board – the board hangs instead until the 
physical reset pin is asserted.

I was able to minimize the test down to a simple `mw ff1a0000 1` from the 
U-Boot shell. This command basically just enables the watchdog (which then 
immediatelly attempts to reset the board.) So this isn't strictly a problem 
with Linux and more so with either the board, the chip or the interaction of 
the two.

Through a careful reading of the RK3328 TRM I then found that the following 
hold true:

* Initial state for `CRU_GLB_CNT_TH.wdt_glb_srst_ctrl` is `0`, which selects 
   the second reset mode;
* This reset mode avoids resetting the GRF and GPIO components;
* And it turns out that manually invoking the second reset by writing 
   `0xECA8` into the `CRU_GLB_SRST_SND_VALUE` MMIO register will have the board 
   hang much the same way.

I'm not quite sure what's causing the second reset not to work on my 
chip/board… But as soon as I set `CRU_GLB_CNT_TH.wdt_glb_srst_ctrl = 1` to 
have watchdog timeouts use the first reset mode, the watchdog reset works 
correctly.

While I can see why preserving the GPIO state might be useful on a watchdog 
reset, it seems like a poor default to me (what if the GPIO state caused the 
state which forced WDT to lapse in the first place?)

I would like to propose that on RK* the `CRU_GLB_CNT_TH.wdt_glb_srst_ctrl` is 
set to `1` (possibly providing a kernel argument to override this behaviour?) 
Does that sound reasonable? Is adding this functionality to 
`drivers/clk/rockchip/clk*` the right approach?

Thank you,
S.