Subject: Re: hardclock(9) for cobalt
To: None <tsutsui@ceres.dti.ne.jp>
From: KIYOHARA Takashi <kiyohara@kk.iij4u.or.jp>
List: port-cobalt
Date: 08/12/2004 21:37:50
From: Izumi Tsutsui <tsutsui@ceres.dti.ne.jp>
Date: Thu, 12 Aug 2004 04:00:52 +0900

> In article <20040811.023752.74752917.kiyohara@kk.iij4u.or.jp>
> kiyohara@kk.iij4u.or.jp wrote:
> 
> > > Maybe we should attach the timer as usual device and initialize
> > > it in the attachment, and functions which enable the timer that
> > > will be called from cpu_initclocks(9) should also be registered
> > > in the attachment (like mvme68k or news68k ;-).
> > 
> > How is it now?
> > 
> >   gttmr0 at mainbus0: 32bit-Wide Timer/Counter on GT-64111
> 
> With a quick glance, I still have some requests for completeness.
> (yes, maybe I'm a paranoid ;-)

OK! ;-)


> - gttmr should be attached at gt0 rather than mainbus0.
> - gttmr.c should use bus_space(9) functions rather than
>   MIPS_PHYS_TO_KSEG1(). I guess some GT64xxx devices are
>   also used by some evbppc.
>   (In this case, INTR_CAUSE register can't be mapped here,
>    so we have to have a function to access it in gt.c??)

I also thought so. However, since it was the fragmentized small space,
bus_space(9) was not used. # 0x10byte + 4bytes.
# Also deer There is a crevice between 4 bytes.

However, other port If it uses also bus_space(9) It is required.

Is it good in the following proccess ?

  1. attach gt
  2.   attach gttmr
  3.   disable timer0
  4.   set func pointers
  5. clear INTR_CAUSE register


> - Register definitions (like TIMER_COUNT_0 etc.) should be in
>   some header file.
>   (cobalt/dev/gt64111reg.h, or sys/dev/ic/gt64111reg.h eventually?).
> - I think cpu_initclocks() should call timer_enable() via some
>   function pointer which is initialized in gttmr_attach().
>   (maybe we should have some MI API for the timer, like todr(9))
> 
> > microtime(9) uses timer0.
> > Probably, it will be better to add microtime(9) here, if possible.
> 
> IMO, it's better to use function pointer to read counter, like pmax.
> Cobalt port doesn't have/require "struct platform", so maybe
> it's enough to prepare one global pointer for it.

all OK!
I try next week. ;-)
--
kiyohara