[Openchrome-devel] [PATCH] TTM/GEM patch v2

[James Simmons]

Hi all!

	This weekend I just finished up the second version of the TTM/GEM 
patch for the VIA chipset. Changes from the last patch are:

1) I fixed the module unloading bug and so far I no oops :-) You can 
   also restart your X server with no problems.

2) Moved all resource handling to TTM. This includes the MMIO region used
   internally.

3) GEM creation ioctl was added. I tested with some basic test apps with 
   libkms. Currently the Xorg drivers doesn't use this new api but it 
   would be pretty easy to add.

4) Rework the detection of resources. If no AGP is present or no VRAM 
   allocated the driver should continue to work. Only the MMIO region is
   required.

5) Reworked the VRAM detection code to use the north bridge to detect the 
   amount of RAM as well as the type. We need to know the type when 
   dealing with bandwidth issues for the display.

Please test the patch at 

http://www.infradead.org/~jsimmons/via-ttm.diff

It is against the branch drm-next.

http://git.kernel.org/?p=linux/kernel/git/airlied/drm-2.6.git;a=shortlog;h=drm-next

I especially want to make sure the memory detection code is correct. Thank 
you.

-------------------------------------------------------------------------------------

The TTM/GEM is usable but is missing some features. Here is what is 
left to do on for the TTM/GEM layer:

TODO:

1) Accelerated bmove.

2) Fence object handling. This will be needed for the 3D handling.

3) Add support for VIA PCI DMA Gart

-----------------------------------------------------------------------

Outside of TTM/GEM work we also have KMS support to start and having xorg 
via driver support GEM and KMS. At this point we have 3 options for the
kms_branch for the xorg driver.

1) Merge current code into trunk but kept kms branch for continued work.
   Then add GEM hooks into kms branch. Merge again into trunk once stable.
   Start KMS work kernel side and support on xorg side then merge kms 
   branch into trunk once stable. 

2) Add support for GEM api into kms branch first then merge into trunk.
   Start KMS work kernel side and support on xorg side then merge kms 
   branch into trunk once stable.

3) Start KMS work kernel side and support on xorg side. At the same time 
   add in GEM support for kms branch. Once stable merge back into trunk.
    
Personally I lean toward option 2. The KMS handling will be a bit tricker 
if we want to maitain backwards compatiablity. No easy way to detect if 
modeset is avaliable that I know of on top of my head.