Re: [linuxsh-dev] Dreamcast RTC

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

Philipp Rumpf wrote:
> 
> 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.

Mening?

Could you please explai the theory behind the initialisation of the bus
freq. And how the values are calculated.
I am personaly having trouble with hanings if I use a value above 20.000
and as I understand it the value for the DC should be 200.000.000 (200
Mhz)

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

Ok. 

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

Ok.

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

Ok you arn't using the RTC as an RTC but you are using it as a CLOCK.
Whitch dosn't work on all platforms, well atleast not on the DC. But you
are right we could hardcode in the value for the DC. And make the
problem go awy. Or we could extend the RTC interface to  make i that of
a general clock. With diferent resulution for different RTC:s 

in other words adding the folowing
unsigned int rtc_clockticks; 			// The number of ticks the RTC makes in
an second
						// Thats 128 for a std SH RTC and 1 for a DC.
void 	rtc_sleep(unsigned int count);		// functions that sleeps for cont
ticks

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

Sure you are right the time_freq don't belong in the machvec. But
neither does the get_time_freq functions. I'll vote for the extended
clock. Because either way we have to find a way for other parts of the
kernel to understand the behavior of the clock.

/Rene