Re: RTC todr for mips/alchemy

Izumi Tsutsui <[email protected]>
Newsgroups gmane.os.netbsd.ports.evbmips
Message-ID <[email protected]>
In article <[email protected]>
[email protected] 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
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.