Re: [linuxsh-dev] Dreamcast RTC

[Rene M. <re...@dr...>]

Philipp Rumpf wrote:
> 
> On Wed, Dec 06, 2000 at 08:44:16PM -0600, M. R. Brown wrote:
> > Hmm, somebody please help me confirm this, but I'm almost certain (based
> > on all of the specs I've seen) that the Dreamcast CPU runs at 200MHz.
> 
> correct
> 
> > Unfortunately I don't have the other specs (bus freq, etc.) in front of
> > me, but they're static as well (they're probably the standard SH4 ratio).
> 
> you can find those out by decoding FQCR.

FQCR ?

> 
> > Personally I'd rather lose the 1.5 seconds :)
> 
> For DC it's probably not that much of an issue - for embedded systems it
> definitely is.


Well yes. But the functions we are talking about are forms of auto
detect. Its my personal view that If you got an embedded system with
time critical applications and you use auto detect then you deserve
every trouble you get.

Well I'll make my proposal a bit more concrete.

1 Add the RTC to the mach_vec functions

mv_rtc_gettime
mv_rtc_settime

Any other part of the kernel is expected to use these functions to get
to the RTC. 

2 Add an constant to the macvector representing the timer_frequency.

mv_time_freq

This variable is either set by a constant or for the generic vector, by
auto detect.
The get_timer_freq functions is modified to fit the new RTC interface.

This way embedded systems can use a predefined value, and hence boot
fast. And lazy people can use the auto detect and pay the 1,5 sec
penalty. As an bonus we get nice modular code and move one step away
from the abyss.

I dont think its a good coding practise to go pass the RTC interface and
go directly at the hardware. I get a feeling that doing things like that
is a good way to introduse hard found bugs.

/Rene