Re: [linuxdc-dev]Dreamcast sound and kernel memory

[Paul M. <pm...@mv...>]

On Sun, Dec 02, 2001 at 01:05:23PM -0600, M. R. Brown wrote:
> Damn, I need time :P.  Check out the latest KOS which (apparently) has AI=
CA
> DMA working.  You want to use DMA.  You have to use DMA.  It's DMA or die
> ... ok maybe that's too much.  But that's the only way you'll effectively
> get anything to AICA RAM without choking on the FIFO.
>=20
Er, side stepping the FIFO through DMA doesn't sound like that good of a
solution either. DMA is definately the optimal way to go for AICA access, b=
ut
it might still prove to be useful to have a non-DMA fallback that waits on =
the
FIFO for its reads (especially for debugging when things go horribly wrong).

If the FIFO is slow in dealing with, there's likely a good reason for it..
doing DMA directly without any kind of flow control might also cause you to
kill the AICA.

[snip]
> void aica_rtc_gettimeofday(struct timeval *tv) {
> 	unsigned long val1, val2;
>=20
> 	do {
> 		val1 =3D ((ctrl_inl(AICA_RTC_SECS_H) & 0xffff) << 16) |
> 			(ctrl_inl(AICA_RTC_SECS_L) & 0xffff);
> 		val2 =3D ((ctrl_inl(AICA_RTC_SECS_H) & 0xffff) << 16) |
> 			(ctrl_inl(AICA_RTC_SECS_L) & 0xffff);
> 	} while (val1 !=3D val2);
[snip]
> }
>=20
The other thing to consider (as I've told you on IRC), the AICA is likely n=
ot
too responsive.. and expecting it to be will likely end up shooting you in =
the
foot. Perhaps something more along the lines of waiting for a brief duration
of time after a read (mdelay(5) perhaps?), and doing the reads with interru=
pts
disabled might prove to yield more consistent data without the need to do a
nasty read-twice and compare hack.

Regards,

--=20
Paul Mundt <pm...@mv...>
MontaVista Software, Inc.