Re: [linuxsh-dev] Dreamcast RTC

[M. R. B. <ma...@uw...>]

On Sat, 9 Dec 2000, Rene Malmgren wrote:

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

The meaning and specs of the FRQCR hardware register are taken right from
the SH7750 hardware manual.  Basically it tells you how fast the cpu clock
(ifc), bus clock (bfc), and peripheral/module clock (pfc) are running in
relation to the master clock (or, the crystal on the mainboard).  The HW
Manual also has the table (or check time.c).  The clever (it is clever,
even though it doesn't work for the DC :) get_timer_frequency code checks
the value of 1/128 of a second (using the interval timer R64CNT, also
broken on the DC) while counting down from TMU0.  This gives an accurate
value of the peripheral clock (pfc), which can be used to calculate the
master clock, bus clock, and cpu clock.  If we can find another way to
activate an interval timer on the DC (currently I'm suspicious of the
AICA, I think there's one in there somewhere), then we can use the same
code, just with our interval timer, but that could potentially get messy
(i.e. another call _within_ get_timer_frequency!).

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

The fact that the interval timer is on the builtin RTC has nothing to do
with using an interval timer, per se, it's just that the RTC is completely
disabled on the DC so we _need_ another interval timer for this to work.
But we seem to be going in circles here...?

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

I'm not sure what you mean by extended clock.  I know the 386 Linux
target has "Enhanced RTC support" which allows you to play with interval
timers, is this what you're talking about?

Can we come to an agreement about cleaning this up?  Is it, "put RTC stuff
into the machvec so that machines can use it generically or custom"; and
"find an autocalibration routine for the DC" - or is it something else?

M. R.