[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