Subject: port-sparc/23399: [dM]
To: None <email@example.com>
From: der Mouse <mouse@Rodents.Montreal.QC.CA>
Date: 11/09/2003 13:48:42
>Synopsis: sys/dev/sbus/zx* is unnecessarily sketchy
>Arrival-Date: Sun Nov 09 18:49:00 UTC 2003
>Originator: der Mouse
>Release: -current as of 2003-11-09
Any SPARC with a zx ("SUNW,leo")
sys/dev/sbus/zx* has a number of unknown things (search zxreg.h
for UNK) and magic numbers (look at zx_reset's calls to
zx_cross_loadwid, for example). These need not be unknown; I
have documentation on the leo that's detailed enough to explain
Look at the code.
I have documentation enough to fix these. Unfortunately it's
in the form of HTML files; I have distilled them down into a
text file, but the text file is intended for my own reference
rather than as full documentation.
The whole thing is up for anonymous ftp from
notes/mouse-notes.txt is the aforementioned text file, with
index.html being the root of the HTML docs.
I spent a little while looking for where I got these HTML files
from, but I found nothing answering that question. (Googling
for quotes finds no hits, for example.)
#define ZX_OFF_UNK2 0x00000000
This is boot PROM space.
#define ZX_OFF_UNK 0x00602000
This is the video frame counter register.
#define ZX_CROSS_TYPE_UNK 0x00001006
This is an interrupt enable mask.
#define ZX_CROSS_CSR_UNK 0x00000002
#define ZX_CROSS_CSR_UNK2 0x00000001
These are the WID LUT Transfer Command (UNK) and WID LUT
Transfer Direction (UNK2) bits.
zx_cross_wait is rather misnamed; it is wait-for-completion
only for LUT transfers.
The magic numbers in the cursor code are explained. I also
suspect there's a bug; I think 0x20<<j in zx_cursor_set should
be 0x20*j, according to the doc.
zx_cursor_color needs to do something analogous to
Most of the pad areas in the structs have things in them, but
it would be way too lengthy to fill them all in here.
LUT transfers do not use the recommended procedure of
withdrawing a previous transfer request if present. This
mostly matters in that it may mean delaying some transfers by
more vertical blanking intervals than necessary. Since the
delay is done by busy-waiting in the kernel, this is not good.
/~\ The ASCII der Mouse
\ / Ribbon Campaign
X Against HTML firstname.lastname@example.org
/ \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B