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.
>   
>> You should probably create a custom evbmips/omsal400 directory and stick
>> your RTC driver there.  You should probably model it after the aurrtc code.
>>     
>
> OMS-AL400 has a RICOH R2025 RTC which is connected SMBus (on PSC0).
> I have already committed this driver to sys/dev/i2c/r2025.c.
>   
Cool.
>   
>> 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.


    - -Garrett



-- 
Garrett D'Amore, Principal Software Engineer
Tadpole Computer / Computing Technologies Division,
General Dynamics C4 Systems
http://www.tadpolecomputer.com/
Phone: 951 325-2134  Fax: 951 325-2191