In article <440CB37F.2000805@tadpole.com>
garrett_damore@tadpole.com wrote:

> >> 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
MI dev/ic/mc146818.c.

> > 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.
---
Izumi Tsutsui