In article <20040812.213749.74744454.kiyohara@kk.iij4u.or.jp>
kiyohara@kk.iij4u.or.jp wrote:

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

Hmm, now I notice that GT64111 has a weird register map...
(The timer uses 0x850-0x85c/0x864 but 0x860 is used for DMA Arbiter)

"In the Perfect world," we should prepare two bus space handles
for each region and map both of them (like sys/dev/isa/fdc_isa.c),
but for now the DMA Arbiter register is not used on other place
and -current bus_space_map(9) function for cobalt doesn't manage
mapped regions (actually it just returns an address of KSEG0 or KSEG1),
so maybe it's okay to map whole 0x850-0x864 region in the attachment
of the timer.

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

Well, it's not required so strictly but still recommended because
MI APIs will also help readability and maintainability in the future.
Using "magic" statements like:
>>	/* XXX */
>>	*((volatile u_int32_t *)0xb4000c00) =
>>		(*((volatile u_int32_t *)0xb4000c00) & ~0x6) | 0x2;
in -current gt_attach() looks weird (especially for non-mips guys),
doesn't it? ;-)

> 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

Looks good. Maybe 5. could be done by calling a special
function in gt.c.
---
Izumi Tsutsui
tsutsui@ceres.dti.ne.jp