[U-Boot] "Reset" values for clksel_con registers in clk_rk3399.c:rkclk_init()

[Kever Yang]

Philipp,


On 01/05/2018 04:23 AM, Dr. Philipp Tomsich wrote:
> Kever,
>
> I came across an odd question in clk_rk3399.c while implementing the reparenting
> (for assigned-clock-parents) that I today discussed with David Wu… looks like the
> following code is supposed to restore the reset values to 3 registers, but both the
> NDA-version of the TRM and the public version of the TRM list different (consistent
> between the two TRM versions) values.
>
> The code in question is:
>          /*
>           * some cru registers changed by bootrom, we'd better reset them to
>           * reset/default values described in TRM to avoid confusion in kernel.
>           * Please consider these three lines as a fix of bootrom bug.
>           */
>          rk_clrsetreg(&cru->clksel_con[12], 0xffff, 0x4101);
>          rk_clrsetreg(&cru->clksel_con[19], 0xffff, 0x033f);
>          rk_clrsetreg(&cru->clksel_con[56], 0x0003, 0x0003);
>
> However, my manual states that the default values are:
> 	CLKSEL_CON12		0x100
> 	CLKSEL_CON19		0x100
> 	CLKSEL_CON56		0x320
>
> This came in with commit 9f636a24 ("rockchip: rk3399: init CPU clock when rkclk_init()”).

The code comes from the first version clock driver and enabled in the 
commit you mentioned,
I port it from coreboot clock driver, however, after I sync internally, 
I didn't find why we
still need this, I think we can remove it if no impact find in system.

Thanks,
- Kever
>
> This popped up on my radar, as I was wondering why GbE had been working so far
> for us, even though we never had any reparenting code for the RK3399.
>
> Do you know why our init code is setting these values and why this doesn’t match
> the comment? I also tried to see if the register-numbers were wrong and the writes
> went to the wrong registers, but I couldn’t find any register in the CLKSEL_CON block
> that had 0x4101 or 0x33f as a default/reset value.
>
> Thanks,
> Philipp.