Nico Coesel wrote:
Correct - and cevt-r4k won't be usable either. I guess that means you leave the user the choice between either these two or using wait.
Not nice but ...
The Alchemy code doesn't even try to use CP0 counter when CONFIG_PM=y if you look into
arch/mips/au1000/common/time.c... or at
least it didn't before Atsushi removed do_fast_pm_gettimeoffset().
Oh, yes. At that time I tried to implement clocksource drivers for non-standard timers, but it seems I had missied Alchemy PM=y case.
The driver would be something like this? Completely untested ;-)
static cycle_t au1000_hpt_read(void) { return au_readl(SYS_TOYREAD); }
struct clocksource au1000_clocksource = { .name = "au1000-counter", .rating = 200,
Rating should be greater than that of CP0 counter...
.read = au1000_hpt_read, .mask = CLOCKSOURCE_MASK(32), .flags = CLOCK_SOURCE_IS_CONTINUOUS, };
void __init au1000_clocksource_init(unsinged long cpu_speed) { struct clocksource *cs = &au1000_clocksource; clocksource_set_clock(cs, cpu_speed);
Not really, it's clocked by 32768 Hz input, so probably not very good as a clocksource.
Why not? If a 32768Hz watch crystal is connected then you'll have a stable clocksource. IIRC watch crystals are more precise than the crystals used to generate the core frequency.
32 KHz is too low a frequency. The same goes about using TOY as a clockevent -- HRT boasts microsecond resoultion which TOY can't provide.
Nico Coesel
WBR, Sergei
