Subject: Re: RTC todr for mips/alchemy
To: None <email@example.com>
From: Izumi Tsutsui <firstname.lastname@example.org>
Date: 03/07/2006 23:15:23
In article <440CB37F.email@example.com>
> >> Possibly (probably!) the other evbmips clock drivers (aurrtc and
> >> mcclock.c) should be converted to use the MI todr logic.
> >> Frankly, I like this idea a lot.
> >> But, the first step is to make evbmips/evmips/clock.c support todr_attach.
> >> That should be the direction you proceed, I think.
It should be trivial. Eventually we should move todr_attach(9),
inittodr(9) and resettodr(9) functions into MI, and it's also
trivial to convert a device from old clockfns style into todr(9) APIs
(unless it also uses timer interrupts in the same RTC device).
Note prep port already has todr(9)'fied mcclock_isa.c with
> > Alchemy is a bit funny here. Almost every other machine has a single
> > physical RTC whereas the Alchemy CPUs have a on-chip one that will
> > always exist and possibly a separate physical RTC. I think at this
> > stage we should special case the aurtc driver somehow rather than making
> > a generic change that affects all evbmips ports. Just how, I'm not sure
> > of right now...
> Why not just handle it in the kernel configs for now? i.e. don't
> include the aurtc in configs for designs that have a better off-chip RTC.
Yes, I also think it's enough, but we can still use device properties
in aurtc_match() function to determine if it should be attached or not.