[PATCH] Add support for RENDER BGRA formats.

Adam Jackson ajax at nwnk.net
Wed Oct 28 07:39:29 PDT 2009

On Tue, 2009-10-27 at 22:54 +0100, Mark Kettenis wrote:

> Hi Adam,
> See the log below.  This is the Xorg version that's currently in the
> OpenBSD tree, with some modifications to the xf86-video-i128 driver
> such that it doesn't blow up.

> (--) PCI: (0:0:3:0) 105d:2339:105d:000b Number 9 Imagine-128 II rev 2,
> Mem @ 0x02000000/8388608, 0x02800000/8388608, 0x03000000/8388608,
> 0x03800000/8388608, 0x00160000/65536, I/O @ 0x00000600/256, BIOS @
> 0x????????/32768

Technically the docs I have are for the two chips after this, but let's
hope it didn't change too much.  Also, very lame that the subvendor and
subdevice IDs are generic Number Nine numbers and not Tech Source.

BARs 0 and 1 are memory windows 0 and 1.  We map MW0 for the
framebuffer, but they're both just views onto the device's VRAM iirc, so
you should be able to map either one.

> (--) I128(0): Memory Windows Registers
> (--) I128(0):   MW0_CTRL 0x00000100
> (--) I128(0):     AMV 0  MP 0  AMD 0  SEN 0  BSY 1  MDM 0  DEN 0  PSZ 0

Hm.  Bits 18 through 16 (mask 0x00070000) define the host data format
for the memory window.  If set, bit 16 swaps bits within each byte
(whatever that means); bit 17 swaps bytes within each word; and bit 18
swaps words within each dword.

> (--) I128(0): M/V/DSE 0/0/0
> (--) I128(0):   MW0_AD    0x02000000  MW0_SZ    0x0000000a  MW0_PGE   0x00000000
> (--) I128(0):   MW0_ORG10 0x00000000  MW0_ORG14 0x00000000  MW0_MSRC  0x00ffff00
> (--) I128(0):   MW0_WKEY  0xffffff00  MW0_KYDAT 0x00000000  MW0_MASK  0xffffffff
> (--) I128(0):   MW1_CTRL 0x00000100
> (--) I128(0):     AMV 0  MP 0  AMD 0  SEN 0  BSY 1  MDM 0  DEN 0  PSZ 0
> (--) I128(0): M/V/DSE 0/0/0
> (--) I128(0):   MW1_AD    0x02800000  MW1_SZ    0x00000000  MW1_PGE   0x000f001b
> (--) I128(0):   MW1_ORG10 0x00fff000  MW1_ORG14 0x00fff000  MW1_MSRC  0x00ffff00
> (--) I128(0):   MW1_WKEY  0xffffff00  MW1_KYDAT 0x00000000  MW1_MASK  0xffffffff

MWn_SZ defines the logical size of the memory window, up to the size
allocated by PCI.  0x0 is 4k, 0x1 is 8k, etc. up to 0xd for 32M.  MWn_AD
is the base address in host memory; MWn_ORG (ORG10 or ORG14, they appear
to be aliased) defines the offset from that to the start of the memory
window.  So you can set up eg a 4k view onto anywhere in VRAM.

MWn_PGE is mentioned as "Memory Window 1 Page", and (to the extent it's
documented) seems to be added to MWn_ORG to determine the offset within
device memory.

The rest is all to do with write masking, not terribly interesting.

So, first thing to try would be to bang the swap bits in MW0_AD and see
if you at least get different colors.

> (--) I128(0):   CMD       0x00010c00
> (--) I128(0):     OPC 0x00  ROP 0x0c  STYLE 0x01  CLP 0x0  PATRN 0x0  HDF 0
> (--) I128(0):   CMD_SHADE 0x00
> (--) I128(0):   CMD_OPC   0x00
> (--) I128(0):   CMD_ROP   0x0c
> (--) I128(0):   CMD_STYLE 0x01
> (--) I128(0):   CMD_PATRN 0x00
> (--) I128(0):   CMD_CLP   0x00
> (--) I128(0):   CMD_HDF   0x00

HDF here is the same as the host data format bits in MWn_CTRL; lowest
bit is bit swap, etc.  Presumably only applies to data send through the
command stream.

- ajax
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part
Url : http://lists.x.org/archives/xorg-devel/attachments/20091028/51fa580b/attachment.pgp 

More information about the xorg-devel mailing list