Re: [linuxsh-dev] Dreamcast RTC

[Rene M. <d9...@ef...>]

----- Original Message -----
From: "Philipp Rumpf" <pr...@pa...>
To: "M. R. Brown" <ma...@uw...>
Cc: "Rene Malmgren" <re...@dr...>
Sent: Tuesday, December 05, 2000 10:58 PM
Subject: Re: [linuxsh-dev] Dreamcast RTC


> On Tue, Dec 05, 2000 at 02:36:11PM -0600, M. R. Brown wrote:
> > Either something happened to my mail or my filters are broken, but I
> > seemed to miss most of this thread, any chance I can get a recap of what
> > was discussed?
>
> > >From the latest e-mail, I can see that you were debating on where the
RTC
> > code should go.  I agree with Rene that the code in time.c is
bastardized,
> > and not necessarily portable across SH's (well just the DC that I know
>
> It makes use of hardware not available on all CPUs - I was working under
the
> (incorrect) premise that since the RTC hardware exists on all SH-4 chips,
it
> would be functional on all of them as well.
>
> So here's my first proposal of how to fix it:
>
> add a mv_get_timer_freq function, which is one of three things:
> 1. a function returning a constant, for machines on which you know the
exact
> frequencies used.
> 2. my 1/128 s - 1/64 s RTC calibration function
> 3. machine-dependent code that calibrates the TMU freq using whatever
known
> clock is available
>
> add machvec functions for gettimeofday/settimeofday
>
> The default implementations of 2., gettimeofday, and settimeofday could be
> in arch/sh/kernel/rtc.c, nicely isolated from the TMU code.
>
> Any obvious breakage (otherwise I'll do a patch tomorrow) ?

Let me give you an alternative solution witch might be better att hand.

I thnik we should adress the problem directly. Not try to patch our way
arouind it.

So our problem is that different SH arch have different ways to talk to the
RTC.
So I prupose that we introduse an abstraction. Simply the get/set timeofday
funktions.
These funktions can be switched in att compile time or dynamicly at runtime.
Then we simply write an rtc_gen.c and a rtc_dc.c, or perhaps even an
rtc_sh3_gen.c, rtc_sh4_gen.c and an rtc_sh4_dc.c. Then we make all the other
functions that use ther RTC access it through these two funktions. The
get_timer_freq for instance. No modification has to be made to the generic
code at all. You just simply chose the type of timer you want. We should
consider doing the same thing to the timers aswell.

>
> > of), but then there's a point where you can't say what's standard on the
> > SH (which is why the rest of time.c doesn't work on the DC, which is why
I
> > think adding timer/RTC/irq items to the generic machvec would make the
> > most sense.
>
> You lost me at "the rest of time.c".  Surely the TMU timers work ?

Yes the TMU works on the DC. But I dont know if its the same way.

Could you pleas describe the init_timer function breafly an what it does
just around the get_timer_freq.

As I see it it sets some busfreq and som other stuff. But I have no idee
what the DC values are supose to be.

>
> > Since I somehow missed the thread, I added some comments to your
responses
>
> Some of the messages were (accidentally ?) sent privately.  If Rene
doesn't
> mind, I'll forward my responses to you.

No mind.

>
> > On Tue, 5 Dec 2000, Rene Malmgren wrote:
> > The DC has _all_ the traits of an SH4 processor with the notable
exception
> > of a disabled RTC.  It doesn't make sense to conditionalize or exclude
it
>
> where "disabled RTC" means there is no crystal connected to the RTC pins ?

Most likely yes. It's standing still.