AT91 slow clock mode regression/fixes, improvement proposal

Sylvain Rochet sylvain.rochet at finsecur.com
Fri Dec 19 07:26:25 PST 2014


Hello Wenyou,


On Fri, Dec 19, 2014 at 02:50:04AM +0000, Yang, Wenyou wrote:
> > 
> > Is actually jumping to wait_pllblock before enabling PLLB instead of skipping UTMI
> > PLL. Unfortunately the compiler does not warn about that.
> 
> Thanks. I will check it

Fixed in proposed patch (UPLL code removed).


> > Furthermore, it looks like MCKRDY_TIMEOUT set to 1000 is not enough, my board
> > crashes in about 1 wake up to 10 with this value and works perfectly
> > fine with 4000.
> 
> I also encountered this issue.

Fixed in proposed patch, since we don't timeout anymore.


> Moreover the Main Crystal Oscillator Startup Time seems not enough 
> too, not sure, I am confirming it.

This is OK for me, CKGR_MOR.MOSCXTST is set to 8:  (1/32768)*8*8 = 1.95 ms

I checked with a scope on XTAL of the AT91SAM9G35-CM module, 2 ms is 
about twice enough waiting time.


> > Therefore I am also proposing to remove all the timeout.
> 
> Good idea, but I still worry the deadlock without timeout. Maybe 
> increasing timeout is better.

This is just a test request patch, I am first trying without timeout to 
get some feedback. It works well for me, at least, but this isn't 
convicing myself enough :-)


> > By the way, I don't know for other AT91 boards (or without DT, or
> > something else), but the UTMI PLL suspend/resume seem unnecessary for
> > me, the USB driver is already disabling the USB PLL when suspending,
> > could you confirm ?
> Yes, I agree.

Removed.


> Remove disabling the PLLB code as well.  

Done, but my SoC don't have a PLLB, so I can't check myself, could you 
check if "AT91: PM - Suspend-to-RAM with PLL B running" does not fire on 
PLL B enabled board ?


Regards,
Sylvain



More information about the linux-arm-kernel mailing list