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