USB, PCI and registers

USB, PCI and registers

[Benjamin Herrenschmidt]

On Sat, Jul 29, 1939,  <> wrote:

>I'm a bit confused as to why pci.c would have base_address[6] as a 
>member to start with - and just as confused as to why there would
>be a difference between architectures.  
>
>Anyone have any comments that might help clarify this confusion?

Those base addresses correspond to the base-addresses registers of the
board's configuration space. If a given PCI chip uses the 5th register,
then the driver must look for base_addresses[4], that's logical. They are
not assigned in any special order: which register to use depends on the
hw implementation and can make HW that uses the 2nd and 3rd registers and
not the fist, for example.

-- 
           E-Mail: <mailto:bh40@calva.net>
BenH.      Web   : <http://calvaweb.calvacom.fr/bh40/>





[[ This message was sent via the linuxppc-dev mailing list. Replies are ]]
[[ not forced back to the list, so be sure to  Cc linuxppc-dev  if your ]]
[[ reply is of general interest. To unsubscribe from linuxppc-dev, send ]]
[[ the message 'unsubscribe' to linuxppc-dev-request@lists.linuxppc.org ]]

PReP RTC vs Decrementer accuracy...

[Troy Benjegerdes]

I just reset the time on my two prep boxes, which have apparently drifted
about 30-40 minutes fast over two weeks or so.

The PReP code also tries to reset the RTC to match the Kernel's
(decrementer's) version of the time every 11 minutes or so. The question I
have is, isn't the RTC more accurate for long periods of time?

I had this discussion with Cort awhile ago, and he said 'I used the
decrementer because it's part of the main CPU, which isn't a cheap $1
part'. It seemed reasonable enough logic at the time, but I suspect the
RTC may actually be more accurate (since that's what it's designed for,
and at least the one one my MTX can be software calibrated).

Does anyone have any experience with the RTC and decrementer accuracies on
Motorola boards?

--------------------------------------------------------------------------
| Troy Benjegerdes    |    troybenj@iastate.edu    |    hozer@drgw.net   |
|    Unix is user friendly... You just have to be friendly to it first.  |
| This message composed with 100% free software.    http://www.gnu.org   |
--------------------------------------------------------------------------


[[ This message was sent via the linuxppc-dev mailing list. Replies are ]]
[[ not forced back to the list, so be sure to  Cc linuxppc-dev  if your ]]
[[ reply is of general interest. To unsubscribe from linuxppc-dev, send ]]
[[ the message 'unsubscribe' to linuxppc-dev-request@lists.linuxppc.org ]]

Re: PReP RTC vs Decrementer accuracy...

[Cort Dougan]

Right, the rtc is probably more accurate over a long period of time.  The
idea is that the rtc will be sync'd with the decrementer so when we change
time it'll be set in the rtc as well.  The drift should be corrected by
a time daemon.

If my assumption here isn't correct let me know.  I'm not adamant about
this and if I'm wrong about this I'm happy to change it.

}The PReP code also tries to reset the RTC to match the Kernel's
}(decrementer's) version of the time every 11 minutes or so. The question I
}have is, isn't the RTC more accurate for long periods of time?


[[ This message was sent via the linuxppc-dev mailing list. Replies are ]]
[[ not forced back to the list, so be sure to  Cc linuxppc-dev  if your ]]
[[ reply is of general interest. To unsubscribe from linuxppc-dev, send ]]
[[ the message 'unsubscribe' to linuxppc-dev-request@lists.linuxppc.org ]]

Re: PReP RTC vs Decrementer accuracy...

[Dan Malek]

Cort Dougan wrote:

> Right, the rtc is probably more accurate over a long period of time...

Nope, not even close.  If you convert rtc drift specifications and
processor oscillator drift specifications to a common reference (like
PPM) you will see processor oscillators are significantly better
than any rtc.  Of course, running PLLs with high multipliers, like
32kHz up to 50 Mhz will cause wide variations, but over a long
period of time they will they will be more accurate time keepers.


> .......  The drift should be corrected by
> a time daemon.

Yes, but sometimes they are the cause of the problem, so
check that too.

If the PPC decrementer does not appear to be keeping time correctly,
first ask how often the system is restarted.  Since the time is
initially set from the rtc, if that is out of whack (and many are)
and you reboot frequently, the system time will drift from a
wall clock in a hurry.   The decrementer should keep time
very accurately from system start up to shut down.  If it
isn't we have some fixing to do.  I believe the design to
be correct, but the implementation may be a little flawed.


    -- Dan



[[ This message was sent via the linuxppc-dev mailing list. Replies are ]]
[[ not forced back to the list, so be sure to  Cc linuxppc-dev  if your ]]
[[ reply is of general interest. To unsubscribe from linuxppc-dev, send ]]
[[ the message 'unsubscribe' to linuxppc-dev-request@lists.linuxppc.org ]]

Re: PReP RTC vs Decrementer accuracy...

[Cort Dougan]

The hardware is more stable, of course, but we can miss when handling it.
Take a look at the decrementer code - I think it's possible to miss a decr
when resetting it.  That could explain drift.

}Nope, not even close.  If you convert rtc drift specifications and
}processor oscillator drift specifications to a common reference (like
}PPM) you will see processor oscillators are significantly better


[[ This message was sent via the linuxppc-dev mailing list. Replies are ]]
[[ not forced back to the list, so be sure to  Cc linuxppc-dev  if your ]]
[[ reply is of general interest. To unsubscribe from linuxppc-dev, send ]]
[[ the message 'unsubscribe' to linuxppc-dev-request@lists.linuxppc.org ]]

Re: PReP RTC vs Decrementer accuracy...

[Troy Benjegerdes]

On Tue, 8 Dec 1998, Cort Dougan wrote:

> The hardware is more stable, of course, but we can miss when handling it.
> Take a look at the decrementer code - I think it's possible to miss a decr
> when resetting it.  That could explain drift.

Okay, would this cause the clock to be fast? (mine was about 45 minutes
fast) (And, is it feasable to make it 'impossible' to miss a decr?)

I have also rebooted the machine quite a bit.. This may also be the
reason.

> 
> }Nope, not even close.  If you convert rtc drift specifications and
> }processor oscillator drift specifications to a common reference (like
> }PPM) you will see processor oscillators are significantly better
> 
> 

Basically, I want to know the right way to do this before fixing it.

--------------------------------------------------------------------------
| Troy Benjegerdes    |    troybenj@iastate.edu    |    hozer@drgw.net   |
|    Unix is user friendly... You just have to be friendly to it first.  |
| This message composed with 100% free software.    http://www.gnu.org   |
--------------------------------------------------------------------------


[[ This message was sent via the linuxppc-dev mailing list. Replies are ]]
[[ not forced back to the list, so be sure to  Cc linuxppc-dev  if your ]]
[[ reply is of general interest. To unsubscribe from linuxppc-dev, send ]]
[[ the message 'unsubscribe' to linuxppc-dev-request@lists.linuxppc.org ]]

Re: PReP RTC vs Decrementer accuracy...

[Cort Dougan]

No, this would tend to make it slower if anything.

}Okay, would this cause the clock to be fast? (mine was about 45 minutes
}fast) (And, is it feasable to make it 'impossible' to miss a decr?)

Rebooting a lot would affect it.  Are you running the code that sync's the
rtc with the system clock every 11 minutes?  If so, turning it off and
seeing which clock was accurate after a while would be a useful
experiment.

}I have also rebooted the machine quite a bit.. This may also be the
}reason.


[[ This message was sent via the linuxppc-dev mailing list. Replies are ]]
[[ not forced back to the list, so be sure to  Cc linuxppc-dev  if your ]]
[[ reply is of general interest. To unsubscribe from linuxppc-dev, send ]]
[[ the message 'unsubscribe' to linuxppc-dev-request@lists.linuxppc.org ]]

Re: PReP RTC vs Decrementer accuracy...

[Corey Minyard]

Cort Dougan <cort@persephone.cs.nmt.edu> writes:

> No, this would tend to make it slower if anything.
> 
> }Okay, would this cause the clock to be fast? (mine was about 45 minutes
> }fast) (And, is it feasable to make it 'impossible' to miss a decr?)
> 
> Rebooting a lot would affect it.  Are you running the code that sync's the
> rtc with the system clock every 11 minutes?  If so, turning it off and
> seeing which clock was accurate after a while would be a useful
> experiment.
> 
> }I have also rebooted the machine quite a bit.. This may also be the
> }reason.
> 

I'm having this same problem on an MVME2700 (233MHZ 750).  With the
default configuration the clock gains about 1.5 seconds every 30
minutes.  LinuxPPC on my PowerMac keeps great time.

I removed the hardcoding of the decrementer setting but the computed
values stayed pretty much the same.  I have modified the hardcoded
frequency value to be 999950000 (after some experimentation with
xntpd) from the old value of 998700000.  This keeps time pretty well
(<16ppm error) and the stability is very good.

Also, I'm not seeing the time being written to the RTC at all.  I just
left my card up all day and it made no difference in the time in the
RTC, it is about 600 seconds off (and that value is growing quite
rapidly, probably 30 seconds a day, which might explain why the
calculated value is so far off).  But why isn't the RTC being written?
Maybe I'll look at this tomorrow.

-- 
Corey Minyard               Internet:  minyard@acm.org
  Work: minyard@nortel.ca       UUCP:  minyard@wf-rch.cirr.com

[[ This message was sent via the linuxppc-dev mailing list. Replies are ]]
[[ not forced back to the list, so be sure to  Cc linuxppc-dev  if your ]]
[[ reply is of general interest. To unsubscribe from linuxppc-dev, send ]]
[[ the message 'unsubscribe' to linuxppc-dev-request@lists.linuxppc.org ]]

Re: PReP RTC vs Decrementer accuracy...

[Corey Minyard]

Corey Minyard <minyard@acm.org> writes:

> Cort Dougan <cort@persephone.cs.nmt.edu> writes:
> 
> > No, this would tend to make it slower if anything.
> > 
> > }Okay, would this cause the clock to be fast? (mine was about 45 minutes
> > }fast) (And, is it feasable to make it 'impossible' to miss a decr?)
> > 
> > Rebooting a lot would affect it.  Are you running the code that sync's the
> > rtc with the system clock every 11 minutes?  If so, turning it off and
> > seeing which clock was accurate after a while would be a useful
> > experiment.
> > 
> > }I have also rebooted the machine quite a bit.. This may also be the
> > }reason.
> > 
> 
> I'm having this same problem on an MVME2700 (233MHZ 750).  With the
> default configuration the clock gains about 1.5 seconds every 30
> minutes.  LinuxPPC on my PowerMac keeps great time.
> 
> I removed the hardcoding of the decrementer setting but the computed
> values stayed pretty much the same.  I have modified the hardcoded
> frequency value to be 999950000 (after some experimentation with
> xntpd) from the old value of 998700000.  This keeps time pretty well
> (<16ppm error) and the stability is very good.
> 
> Also, I'm not seeing the time being written to the RTC at all.  I just
> left my card up all day and it made no difference in the time in the
> RTC, it is about 600 seconds off (and that value is growing quite
> rapidly, probably 30 seconds a day, which might explain why the
> calculated value is so far off).  But why isn't the RTC being written?
> Maybe I'll look at this tomorrow.
> 

I done some more research.  From the looks of things, the MK48T59 is
not register-compatible (even with mapping) with the MC146818.  Most
of the control bits are not in the same place.  I'm going to try to
rewrite this, but...

I would like to make things in the arch/ppc/kernel directory more
"polymorphic", meaning I'd like to have a table of function pointers
that point to the various procedures to handle things, much like a
device driver or filesystem entry.  The detection code would fill in
all the proper functions, and there would be no more checks all over
the place for various architectures.  I think it would make the code
much cleaner and make it much easier to add new boards.

Cort, who would I contact for more info on this?

-- 
Corey Minyard               Internet:  minyard@acm.org
  Work: minyard@nortel.ca       UUCP:  minyard@wf-rch.cirr.com

[[ This message was sent via the linuxppc-dev mailing list. Replies are ]]
[[ not forced back to the list, so be sure to  Cc linuxppc-dev  if your ]]
[[ reply is of general interest. To unsubscribe from linuxppc-dev, send ]]
[[ the message 'unsubscribe' to linuxppc-dev-request@lists.linuxppc.org ]]

Re: PReP RTC vs Decrementer accuracy...

[Cort Dougan]

Great!  That's exactly what we need.

}I would like to make things in the arch/ppc/kernel directory more
}"polymorphic", meaning I'd like to have a table of function pointers
}that point to the various procedures to handle things, much like a

Probably me.

}Cort, who would I contact for more info on this?


[[ This message was sent via the linuxppc-dev mailing list. Replies are ]]
[[ not forced back to the list, so be sure to  Cc linuxppc-dev  if your ]]
[[ reply is of general interest. To unsubscribe from linuxppc-dev, send ]]
[[ the message 'unsubscribe' to linuxppc-dev-request@lists.linuxppc.org ]]

Re: PReP RTC vs Decrementer accuracy...

[Geert Uytterhoeven]

On Wed, 9 Dec 1998, Cort Dougan wrote:
> Great!  That's exactly what we need.
> 
> }I would like to make things in the arch/ppc/kernel directory more
> }"polymorphic", meaning I'd like to have a table of function pointers
> }that point to the various procedures to handle things, much like a

And that's what we've been doing on m68k for years
(include/asm-m68k/machdep.h).

Greetings,

						Geert

--
Geert Uytterhoeven                     Geert.Uytterhoeven@cs.kuleuven.ac.be
Wavelets, Linux/{m68k~Amiga,PPC~CHRP}  http://www.cs.kuleuven.ac.be/~geert/
Department of Computer Science -- Katholieke Universiteit Leuven -- Belgium


[[ This message was sent via the linuxppc-dev mailing list. Replies are ]]
[[ not forced back to the list, so be sure to  Cc linuxppc-dev  if your ]]
[[ reply is of general interest. To unsubscribe from linuxppc-dev, send ]]
[[ the message 'unsubscribe' to linuxppc-dev-request@lists.linuxppc.org ]]

Re: PReP RTC vs Decrementer accuracy...

[Corey Minyard]

Cort Dougan <cort@persephone.cs.nmt.edu> writes:

> Great!  That's exactly what we need.
> 
> }I would like to make things in the arch/ppc/kernel directory more
> }"polymorphic", meaning I'd like to have a table of function pointers
> }that point to the various procedures to handle things, much like a
> 
> Probably me.
> 
> }Cort, who would I contact for more info on this?
> 

Ok.  I'm going to start doing this work.  I'll reference the m68k code
to see how that works, and I'm going to spend a few days working on it
at work.  Keep in mind that this is going to touch pretty much
everything, if you have patches they will need to be redone.  I assume
if the quality is good this will go into the standard release?

-- 
Corey Minyard               Internet:  minyard@acm.org
  Work: minyard@nortel.ca       UUCP:  minyard@wf-rch.cirr.com

[[ This message was sent via the linuxppc-dev mailing list. Replies are ]]
[[ not forced back to the list, so be sure to  Cc linuxppc-dev  if your ]]
[[ reply is of general interest. To unsubscribe from linuxppc-dev, send ]]
[[ the message 'unsubscribe' to linuxppc-dev-request@lists.linuxppc.org ]]

Re: PReP RTC vs Decrementer accuracy...

[Dan Malek]

Cort Dougan wrote:

> Take a look at the decrementer code - I think it's possible to miss a decr
> when resetting it.  That could explain drift.

I finally had a look (after I saw my original message _finally_
got sent to the list :-).

We are either going to get it right, or miss a bunch.  If the
instructions fit in a cache line, I think we are OK because
nothing should affect the stream between the get_dec()
and set_dec().  If we have to do a cache line fill between
these, I think we are hosed........

This is why I used the PIT in my original port of the 8xx
stuff.  Since the hardware did the reload, there was no
timer drift that could be the result of the software (unless
you missed one of the imterrupts, which better not
happen :-).  I went back to the decrementer for the 8xx
because it presented an integration hassle....I may
now reconsider.....


    -- Dan




[[ This message was sent via the linuxppc-dev mailing list. Replies are ]]
[[ not forced back to the list, so be sure to  Cc linuxppc-dev  if your ]]
[[ reply is of general interest. To unsubscribe from linuxppc-dev, send ]]
[[ the message 'unsubscribe' to linuxppc-dev-request@lists.linuxppc.org ]]

Re: PReP RTC vs Decrementer accuracy...

[Guy G. Sotomayor, Jr.]

Dan Malek wrote:
> 
> Cort Dougan wrote:
> 
> > Take a look at the decrementer code - I think it's possible to miss a decr
> > when resetting it.  That could explain drift.
> 
> I finally had a look (after I saw my original message _finally_
> got sent to the list :-).
> 
> We are either going to get it right, or miss a bunch.  If the
> instructions fit in a cache line, I think we are OK because
> nothing should affect the stream between the get_dec()
> and set_dec().  If we have to do a cache line fill between
> these, I think we are hosed........
> 
> This is why I used the PIT in my original port of the 8xx
> stuff.  Since the hardware did the reload, there was no
> timer drift that could be the result of the software (unless
> you missed one of the imterrupts, which better not
> happen :-).  I went back to the decrementer for the 8xx
> because it presented an integration hassle....I may
> now reconsider.....
> 
Umm, but why are you keeping track of time with the decrementer?  Why
don't you use the timebase to keep track of time and the decrementer
to deliver periodic interrupts?  The two do not necessarily need to be
linked and solve the drift problem.

TTFN - Guy

[[ This message was sent via the linuxppc-dev mailing list. Replies are ]]
[[ not forced back to the list, so be sure to  Cc linuxppc-dev  if your ]]
[[ reply is of general interest. To unsubscribe from linuxppc-dev, send ]]
[[ the message 'unsubscribe' to linuxppc-dev-request@lists.linuxppc.org ]]

Re: PReP RTC vs Decrementer accuracy...

[Dan Malek]

Guy G. Sotomayor, Jr. wrote:

> Umm, but why are you keeping track of time with the decrementer?

Because that is the way it was done when I first looked at the kernel
a long time ago :-).


> .....use the timebase to keep track of time and the decrementer
> to deliver periodic interrupts?

Excellent idea.  I have started to implement this on an MPC8xx board,
so I will let everyone know the results pretty quickly.

It appears the TB is part of every PPC core.  If anyone knows different
please let me know.

    -- Dan



[[ This message was sent via the linuxppc-dev mailing list. Replies are ]]
[[ not forced back to the list, so be sure to  Cc linuxppc-dev  if your ]]
[[ reply is of general interest. To unsubscribe from linuxppc-dev, send ]]
[[ the message 'unsubscribe' to linuxppc-dev-request@lists.linuxppc.org ]]

Re: PReP RTC vs Decrementer accuracy...

[Guy G. Sotomayor, Jr.]

Dan Malek wrote:
> 
> Guy G. Sotomayor, Jr. wrote:
> 
> > Umm, but why are you keeping track of time with the decrementer?
> 
> Because that is the way it was done when I first looked at the kernel
> a long time ago :-).
> 
> > .....use the timebase to keep track of time and the decrementer
> > to deliver periodic interrupts?
> 
> Excellent idea.  I have started to implement this on an MPC8xx board,
> so I will let everyone know the results pretty quickly.
> 
> It appears the TB is part of every PPC core.  If anyone knows different
> please let me know.
> 
I haven't looked into how the various Linux ports deal with time, but back
when I was doing microkernel work (for a large computer company with a 3
letter name) this is how we kept time since all of the processors we were
dealing with had a time base or its moral equivalent.  This was necessary
since we didn't use the decrementer to deliver fixed period interrupts and
trying keep time from drifting would have been hard.

TTFN - Guy

[[ This message was sent via the linuxppc-dev mailing list. Replies are ]]
[[ not forced back to the list, so be sure to  Cc linuxppc-dev  if your ]]
[[ reply is of general interest. To unsubscribe from linuxppc-dev, send ]]
[[ the message 'unsubscribe' to linuxppc-dev-request@lists.linuxppc.org ]]

Re: PReP RTC vs Decrementer accuracy...

[Dan Malek]

Guy G. Sotomayor, Jr. wrote:

> Dan Malek wrote:
> > Excellent idea.  I have started to implement this on an MPC8xx board,
> > so I will let everyone know the results pretty quickly.

> .....this is how we kept time since all of the processors we were
> dealing with had a time base or its moral equivalent.....

I have it running on an MPC8xx board right now, we'll
see how it keeps time overnight with some other programs
running.   I couldn't point to any problems with the decrementer,
but I think my implementation of the TB prevents missing
any counts.  One nice thing I discovered is the decrementer
is an exception rather than an interrupt, so you are unlikely
to mask it like you do with the TB interrupt.

I am working on a version right now that I will run on
my PowerBook G3 to see if I can actually make it  run
on a 750 platform.


    -- Dan



[[ This message was sent via the linuxppc-dev mailing list. Replies are ]]
[[ not forced back to the list, so be sure to  Cc linuxppc-dev  if your ]]
[[ reply is of general interest. To unsubscribe from linuxppc-dev, send ]]
[[ the message 'unsubscribe' to linuxppc-dev-request@lists.linuxppc.org ]]

Re: PReP RTC vs Decrementer accuracy...

[Gabriel Paubert]

On Thu, 10 Dec 1998, Dan Malek wrote:

> 
> Guy G. Sotomayor, Jr. wrote:
> 
> > Umm, but why are you keeping track of time with the decrementer?
> 
> Because that is the way it was done when I first looked at the kernel
> a long time ago :-).
> 
> 
> > .....use the timebase to keep track of time and the decrementer
> > to deliver periodic interrupts?
> 
> Excellent idea.  I have started to implement this on an MPC8xx board,
> so I will let everyone know the results pretty quickly.
> 
> It appears the TB is part of every PPC core.  If anyone knows different
> please let me know.

Yes, the problem is the good old 601. The TB uses different register
numbers (it's called the RTC, split into RTCU and RTCL like TBU and TBL).
Register numbers are 20(RTCU)/21(RTCL), they can also be read from user
mode as registers 4 and 5. 

However, the most troublesome characteritice of the 601 timebase is that
the RTCL overflows at 1 billion exactly (it virtually counts in
nanoseconds), in such a way that the RTCU is incremented by 1 every
second. This is not a straight binary 64 bit counter. It can be
transformed into one, however:

1:	mfrtcu	r3
	mfrtcl	r4
	mfrtcu	r5
	cmpw	r3,r5
	bne	1b
	lis	r5,(1000000000/64)>>16
	addi	r5,r5,(1000000000/64)&0xffff
	mullw   r6,r3,r5
	mulhwu  r3,r3,r5
	srwi    r4,r4,6
	addc    r4,r4,r6
	addze   r3,r3

returns the equivalent of a 64 bit (not exactly, since the 8 MSB will
always be zero) timebase with 64nsec resolution, almost equivalent to
what most processors give with 66MHz buses (60nS resolution).
If you only need the 32 LSB, you can even simplify it, replace the last
five instructions with:

	mullw   r3,r3,r5
	srwi	r4,r4,6
	add	r3,r3,r4


According to my 601 doc, the RTC input is a 7.8125 MHz clock, which
increases by one count every 128 nS, the 7 LSB are always zero and you
can't lose any precision by shifting right the RTCL value by 6 as I
suggest. High 601 speed grades might have a clock at a higher rate (15.625
or 31.25 MHz), I don't know but it would be required to fulfill the
following condition "enough bits are implemented to provide a resolution
that is finer than the time required to execute 10 Add Immediate (addi)
instructions".

	Gabriel.


[[ This message was sent via the linuxppc-dev mailing list. Replies are ]]
[[ not forced back to the list, so be sure to  Cc linuxppc-dev  if your ]]
[[ reply is of general interest. To unsubscribe from linuxppc-dev, send ]]
[[ the message 'unsubscribe' to linuxppc-dev-request@lists.linuxppc.org ]]

Re: PReP RTC vs Decrementer accuracy...

[Dan Malek]

Gabriel Paubert wrote:

> Yes, the problem is the good old 601. The TB uses different register
> numbers (it's called the RTC, split into RTCU and RTCL like TBU and TBL).

I'll take a look at this.  I don't think it is a problem.  I only use the
lower part to count 10 millisecond timer interrupts, and as long
as I know where it wraps around, it should be fine.  As long as
there are timebase compare registers that interrupt when a match
occurs on either upper or lower, we are all set.  Different register
numbers are OK because all get/set operations are implementation
defined functions.


    -- Dan



[[ This message was sent via the linuxppc-dev mailing list. Replies are ]]
[[ not forced back to the list, so be sure to  Cc linuxppc-dev  if your ]]
[[ reply is of general interest. To unsubscribe from linuxppc-dev, send ]]
[[ the message 'unsubscribe' to linuxppc-dev-request@lists.linuxppc.org ]]

Re: PReP RTC vs Decrementer accuracy...

[Dan Malek]

This timebase thing isn't working out so well.  I hope
I am just not being stupid, but I need some conversation
about this.

It appears all processors have the timebase register,
or at least something similar as on the 601.  However,
only the embedded processors have a timebase _compare_
register set.  What I implemented was a simulated interval
timer using the TB and the TB compare registers.  Can't
do that on other processors.

>From the various processor manuals, it appears the
timebase registers were intented to be used as the
time of day keeper.  It would be set by the OS once
(or whenever time changed) and then used to determine
time of day and date.  It has a high enough frequency to
give sub-second resolution, can easily be read by user
applications for the time/date purpose or even time stamping.
Other than the embedded processors, it doesn't appear
there is any generic capability to interrupt the processor
when the timebase attains one particular value.

Hence, the decrementer.  It generates an interrupt (exception
actually) when it counts to zero and rolls over.  It is
likely this could be used as a periodic interrrupt, but
not guaranteed since there is no atomic update capability.

IMHO, I think the decrementer serves our needs well
enough.  It may require a little more tuning to be more
accurate, but if you are running in a network of servers
you should be running a time daemon anyway to keep
everyone in sync.  If you are not, just set the date
once in a while when it starts to drift too far away
from your wrist watch.

In the embedded world where timing is sometimes
more critical, I have now implemented three different
choices....the decrementer, the timebase compare, and
the programmable interval timer.  There are even more
to choose from :-).

The generic solution would be an implementation as
many of the processor documents suggest.  Use the
decrementer to give you a "close enough" scheduling
interrupt, and the timebase registers to keep an accurate
time of day and date reference.


    -- Dan



[[ This message was sent via the linuxppc-dev mailing list. Replies are ]]
[[ not forced back to the list, so be sure to  Cc linuxppc-dev  if your ]]
[[ reply is of general interest. To unsubscribe from linuxppc-dev, send ]]
[[ the message 'unsubscribe' to linuxppc-dev-request@lists.linuxppc.org ]]