Simon Burge wrote:
> "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.
>   
Hmm... I might even have some cycles to do this as part of the AR5312
work.  In fact, I think the clock routines should not panic if there is
no attached TODR.  The AR5312 lacks a time-of-day chip, and so I wind up
having to "stub" it out.
>   
>>>> 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...
>   
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.

Frankly, the aurtc code in the Alchemy port is a bit broken (at least on
my boards) and needs repair.

Its on my TODO list. :-)

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