[Openchrome-devel] Early TTM patch

[James Simmons]

> > Okay folks brace yourselves. I managed to hook the current DRM kernel apis 
> > with a TTM/GEM backend. The UMS xorg servers appears to run fine. Now it 
> > is far from perfect. Currently you can't unload the module without a 
> > oops but so far that is the only problem I have seen. But other than that 
> > it runs!!! Since I don't have a freedesktop account yet I posted my patch 
> > at 
> > 
> > http://www.infradead.org/~jsimmons/via-ttm.diff
> > 
> > This patch is against the drm-next branch. Give it a try with the KMS xorg 
> > branch and let me know how it works. While you test that I'm going to put 
> > some gem test together to exercise the driver.
> > 
> Testing on a VX900 laptop with drm-next + your patch + 2 others patches.
> One adds some Chrome9 pciids (patch 2), the other adds a fix from VIA
> for the command verifier that is needed for the hardware mpeg decoder
> from the xvmc-dev branch (patch 1). This should not interfere with your
> TTM work.

I will integrate those patches into my tree. Thanks.
 
> At first, it didn't know about the chipset, and failed to probe the
> VRAM. See attached file oops. It's a bit better with patch 3, but it
> still fails because of lack of AGP support. See attached file oops2.

Looking at both oops I see what the problem is. If it fails to detect the 
VRAM size or no AGP the module just exits and unloads itself. The oops 
happens when you unload the driver due to the unrelease problem. Modern 
motherboards lack a AGP bug so I need to allow that to fail gracefully.
As for VRAM, do any VIA systems exist that lack VRAM? 

> X is still working fine though, and there's nothing unusual in the Xorg log.
> 
> I guess that's all for this laptop and both my VX800 and VX855 will
> suffer from the same issue, so I'll need to try with the CLE266 and
> KM400, but this may take a bit more time.

Very good news :-) I started to test the gem layer that I have written. 
The new GEM layer can allocate and mmap just fine. The problem is the 
eviction of the space once we close the file. Once I wrapped my head 
around TTM it became very clear how it behaves differently from the
current via drm api. The current api reserves specific address spaces 
whereas TTM scans for a free space in some set of pools. In that case you 
don't know what address space you are going to get but the GEM/TTM layer 
handles that for you. This is much more flexiable in that you don't need
to manage pointers on the user side. You grab the GEM handle and then just
mmap it. From looking at the xorg drivers code this doesn't appear to be a 
issue with the AGP space. Now the framebuffer space is another story. I 
need to think about how to cleanly handle both case at the same time to be 
backwards compatable.