On 21-12-13 13:15, Hans de Goede wrote:
Hi,
On 12/20/2013 11:52 PM, Maxime Ripard wrote:
Hi Hans,
On Fri, Dec 20, 2013 at 08:22:56PM +0100, Hans de Goede wrote:
Hi,
On 12/20/2013 09:33 AM, Maxime Ripard wrote:
Hi Hans,
On Fri, Dec 20, 2013 at 08:29:46AM +0100, Hans de Goede wrote:
Hi,
On 12/19/2013 10:49 PM, Юрий Пухальский wrote:
Good UTC night!
Got somewhat further, yet still there are problems.
Is there anything i should change in kernel cmdline maybe?
Is this a sun5i device, iow A10s or A13 SOC based ? If so you
need to build and boot with my sunxi-next u-boot branch:
https://github.com/jwrdegoede/u-boot-sunxi/commits/sunxi-next
The only time I've seen those clock update timeout errors is
on sun5i with an unfixed uboot.
It would be really great if it was to work without any changes in
u-boot.
I agree. For this to work we need to override the initial pll6
frequency we inherit from u-boot, which for sun5i is 2400 MHz,
which PLL6 can be configured to given its factors, but will not
actually work at. I believe this is actually a broken
power-on-reset value in PLL6-cfg, rather then u-boot's fault.
I do hope that even though all the below is valid and true, having
u-boot exit with everything in a sane state is still a patch worth while?
Oliver
The problem is there is no clear / clean way to fix this in
the suni-clk kernel code.
What did you think about/try ?
I looked at the sunxi-clk code, so no obvious way to fix it there,
and decided to fix this in u-boot. IOW I did not try any kernel
changes.
I think that adding a new factors calculation function for sun5i's
PLL6, that would limit the factors returned to whatever frequency is
adequate would work. Emilio?
The problem is that the clk framework will first try to use PLL6
as is, and if that is possible won't call sun4i_get_pll5_factors
at all (I've add a pr_err to sun4i_get_pll5_factors and it never
gets called).
What happens is that clk_factors_recalc_rate returns 2400 for PLL6,
and since 2400 / 48 neatly is 50Mhz and the mmc clk divider can
divide by 48, the clk framework never even tries to reconfigure
PLL6, so sun4i_get_pll5_factors never gets called.
So fixing this in the kernel would require doing something earlier
on, either in sunxi_init_clocks, or add a max valid freq attribute
to clk_factors_config and make clk_factors_recalc_rate check that
and return 0 when the clk has an invalid config, and hope that
the clk framework will then decide to try clk_factors_determine_rate
again with the CLK_SET_RATE_PARENT flag set and then will end up
calling sun4i_get_pll5_factors. Thinking more about this, adding a
max valid freq attribute is a good idea in general, and we should
probably use this in other place too.
I'll happily give a patch for this a try. It is probably best if
Emilio writes it as he knows the code best.
Regards,
Hans
--
You received this message because you are subscribed to the Google Groups
"linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
For more options, visit https://groups.google.com/groups/opt_out.
