|
From: Paul M. <pm...@mv...> - 2001-12-02 19:38:23
|
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.
|