[RFC PATCH] rxerr patch

Andy Green andy at openmoko.com
Wed Feb 11 08:27:44 CET 2009

Hash: SHA1

Somebody in the thread at some point said:

|> Generated when it gets to the top of the receive
|> FIFO without reading out data in it (overrun error).
| So maybe an overrun error means that the fifo is full and not that we
| lost a byte?

Maybe it means that the FIFO operated the handshake action.

The idea might have been that since an RX overrun is "impossible" if you
are using hardware handshake mode, they can overload the meaning of b0
to mean something else when you are using hardware handshaking.

I saw that the only overruns in your last trac entry are on port 1, ie,
GPS UART port.  By the look of it these are probably genuine overruns
caused by the SDI ISR since we don't wire up the handshakes on port 1.

Looking at the interrupt priority arbitration scheme in the s3c2442
datasheet, it seems we could play a trick and elevate arbiter 4 above
arbiter 3 at arbiter 6 (ARB_SEL6 <- 3).  At the moment, we just use
default priority throughout, but that should allow GPS UART to interrupt
this long SDI service action.

It sounds good because USB host and device interrupt is also in arbiter
3 along with GPS UART, these should have higher priority than the fully
synchronous SDI you would think.

- -Andy
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org


More information about the openmoko-kernel mailing list