Re: RTC todr for mips/alchemy

Simon Burge <[email protected]>
Newsgroups gmane.os.netbsd.ports.evbmips
Organization Wasabi Systems, Inc.
Message-ID <[email protected]>
"Garrett D'Amore" wrote:

> Shigeyuki Fukushima wrote:
> > Garrett D'Amore wrote:
> >   
> >> Take a look at sys/arch/evbmips/clock.c
> >>     
> >
> > There is no todr_attach() function in it.
> > I want to add todr_attach() to it.
> > Because this function is defined at sys/dev/clock_subr.h.
> > This is a device-general function.
> >
> > Would you like to look at sys/dev/clock_subr.{c,h}?
> >   
> Okay, so the problem, as I see it, is that clock.c in
> evbmips/evbmips/clock.c doesn't follow the clock_subr.h stuff.
> 
> So, what I think we need to do is implement todr_attach in
> evbmips/evbmips/clock.c, so that it can make use of your rtc driver.
> 
> What we do *not* need is a seperate and new RTC driver.
> 
> 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.

I think the todr_attach() stuff was relatively new when I first did
evbmips, and it's been something that I keep meaning to convert evbmips
over too.  As Garrett said, this should be the first step.

> >> In your kernel config, you must *only* have one of aurrtc or your rtc. 
> >> multiple devices trying to clockattach() will panic.
> >>     
> This is also something you could look at possibly changing when you are
> doing your work.  Although as a first coarse pass you could probably
> just continue to panic in this case.

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

Simon.
--
Simon Burge                            <[email protected]>
NetBSD Support and Service:         http://www.wasabisystems.com/
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.