Anton Vorontsov wrote:
This isn't a timer with usec precision! This is a timer that silently
crops precision as it wants to. Ahh, I see you dropped "u" prefix.
It is a timer with usec precision, unless you ask for a timeout of more
than 65535 usec -- at which point the hardware can't provide usec precision.
And s/as it wants to/as it needs to/.
Well. I'm not going to use it anyway, so just give it some name you
prefer and I'll wrap it into the patch. Preferably, drop a line here with
kerneldoc for it, so I'll not have to document its drawbacks. :-)
/**
* gtm_reset_timer16 - reset 16 bit timer with arbitrary precision
* @tmr: pointer to the gtm_timer structure obtained from gtm_get_timer
* @usec: timer interval in microseconds
* @reload: if set, the timer will reset upon expiry rather than
* continue running free.
*
* This function (re)sets the GTM timer so that it counts up to the
* requested interval value, and fires the interrupt when the value is
* reached. This function will reduce the precision of the timer as
* needed in order for the requested timeout to fit in a 16-bit
* register.
*/
int gtm_reset_timer16(struct gtm_timer *tmr, unsigned long usec,
bool reload)
{
...
}
It could be made faster using cntlzw.
No need to cntlzw, there is fls() already.
fls() uses cntlzw, does it not? I was just too lazy to look up what
Linux calls it. :-)
Though, here you'll need two because of u64.
We can probably get away with 32 bits.
Btw, I hope you aware that single GTM timer running at 166MHz will give you
6 minutes of sleep, maximum.
Yes, but it's all we have on-chip that can do the job.
With cascaded timer you'll get much better
result of 310 days. Is that possible to use cascaded timer as a wakeup
event on 8313?
No, unfortunately. Only timer4 can be a wakeup source, and when
cascaded, timer4 is the input to timer3, rather than the other way around.
-Scott
_______________________________________________
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
