Re: Using wsdisplay from the Xserver

[Manuel Bouyer <bouyer%antioche.eu.org@localhost>]

On Sat, Jan 24, 2009 at 04:57:19PM -0500, Michael wrote:
> >This has to be very well though to work on hardware like alpha, and  
> >other
> >hardware with non-linear mapping of I/O space (or whatever oddities
> >this hardware could have).
> 
> Well, what /are/ the oddities on alpha? So far nobody bothered to  
> explain it.

I won't claim I completely understand it or know all details about it,
but I'll try to explain it anyway. Someone familiar with the alpha
hardware will have to correct me.

As I get it, all PCI access (I/O or memory mapped) are mapped in
the CPU's memory space.
alpha CPUs before, and including some EV56 don't have instructions to
access memory by 8 or 16 bits; the minimum access is always 32bit,
aligned on 32bit. This of course doens't work well for some devices
which have different, independant registers in the same 32bit word.

To work around this, the PCI bridge (some or all alpha PCI bridges ? I don't
know) offer different view of the I/O and memory spaces. One of this
view, the "dense mapping" works in the normal way: an 32bits access from
the CPU is translated to a 32bit access to the device's registers.
Then there are "sparse mappings" (at last one, maybe 2 for 8 and 16bits
access ? this I don't know), where a 32bits access from the CPU is
translated to a 8 (or eventually 16) bits access to the device (the remaning
bits from the CPU access are ignored).

If a device has e.g. 1024 bytes registers, the corresponding space
in the dense mapping will be 1024 bytes; while the 8bits sparse mapping
will be 4096 bytes wide, and the 16bits sparse mapping would be 2048 byes
wide (assuming one exists). But it seems to be more complicated than
just a *2 or *4 on the offset, the value also has to be translated.
Some constant in this translation sees to be chipset dependant.
These constants and other details about the mapping are exported to userland
though the sysarch() system call (ALPHA_BUS_GET_WINDOW_COUNT and
ALPHA_BUS_GET_WINDOW)

You can get some of these details from
xsrc/external/mit/xorg-server/dist/hw/xfree86/os-support/bsd/
(especially alpha_video.c, bsd_ev56.c) for PCI memory space;
i/o space is acceeded through NetBSD's libalpha (lib/libarch/alpha/)

this all gets complicated by the fast that the recent CPU (starting with
the ev56) have byte and word instructions at the CPU level
(the BWX instructions). Some PCI bridges for ev56 and later still offer
the dense vs sparse mappings; some don't (in this case there's only a single
mapping). There seems to be combinations of CPU/bridges where the BWX
instructions don't work as expected, while others have bugs in the
sparse mappings. There are some details about it in sys/arch/alpha/pci/
(especially cia.c).

From experiment, a PWS500 with a ev56 CPU will use sparse mappins anyway
(and alpha_video.c gets 4 mappings from the kernel, only 2 of them are used);
a XP1000 (ev6 CPU) doens't have sparse mapping (and so has to use BWX
instructions) and alpha_video.c gets a single mapping from the kernel.

These details are hidden from kernel MI drivers by the bus_space(9)
interface. Xorg has a similar interface (the xf86WriteMmio* and xf86ReadMmio*
function pointers) for memory mappings; our libalpha provides one for
I/O mappings (also though function pointers). I don't have ideas to
export details needed by these userland MD interfaces in a MI way.

-- 
Manuel Bouyer <bouyer%antioche.eu.org@localhost>
     NetBSD: 26 ans d'experience feront toujours la difference
--