Re: [linuxsh-dev] Dreamcast RTC

[Philipp R. <pr...@pa...>]

On Thu, Dec 07, 2000 at 04:29:38PM +0100, Rene Malmgren wrote:
> Philipp Rumpf wrote:
> > > 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 ?

FRQCR, sorry.

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

there's no way to find out whether your fixed value is correct unless you
calibrated it (other than comparing with an external time source).  As on
most SH systems the calibration takes less than 20 ms I don't think it's
a good idea to ever use a constant timer value for those - for the DC it's
a different issue.

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

or specifid on the command line (since 2 seconds of delay during boot just
because you don't know your CPU speed just aren't acceptable) ?

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

We don't rely on the hardware we access being an RTC at all - all we need
is to know the rate of change of the hardware register we read (the
equivalent code on x86 uses the PIT).  Using the RTC interface if you're
not using RTC functionality doesn't sound like a good idea.

> I get a feeling that doing things like that
> is a good way to introduse hard found bugs.

And not doing things this way introduces limitations that I think would be
unacceptable to many people;  it would also, IMHO needlessly, move things
out of the cpu data structures into the machvec.

	Philipp Rumpf