Re: [Nouveau] Nouveau DRM kernel tree

2009-06-07 Thread Maarten Maathuis
Any plans on merging the wfb patch or will i get that honor when i get
home (in 6 weeks)?

Maarten.
___
Nouveau mailing list
Nouveau@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/nouveau


[Nouveau] Nouveau DRM kernel tree

2009-06-03 Thread Ben Skeggs
Just a heads up that there's a Linux kernel tree up at
git://anongit.freedesktop.org/git/nouveau/linux-2.6 which (after
discussion in #nouveau) is where development of the Nouveau drm will
continue.  In the newttm-devel branch is the latest work towards using
the re-worked TTM memory manager that will likely appear in a future
upstream kernel.

The major differences between the drm in the newttm-devel branch, and
that up at drm.git are:

- TTM is the sole memory manager, the previous interfaces no longer
  exist.  For compatibility with the 0.0.13 kernel in drm.git the
  interface exposed is identical, however, the MM_ENABLED getparam will
  *always* return 1.  Calling the older ioctls will return an error.

- Kernel modesetting for all supported chipsets.
  - The code for G80 onwards should be fairly OK, it's mostly the same
as what's in Fedora 11, which appears to work well.  There are some
changes from F11 though, see below.
  - For earlier chipsets, fbcon comes up fine, and X will start on all
the cards I have available, but it hasn't been overly tested and
likely has some rough edges still.  The code is more-or-less in sync
with the latest DDX git.

- NV50 modesetting:
  - Uses the display push buffer (yes, this is necessary, I didn't do
it purely for the fun of it).  From some error messages seen
while confusing the binary driver, NVIDIA call the display engine
EVO, so, I stole that name too.  Any guesses what it stands for? :P
  - CRTCs can be configured to scan out non-linear buffers, except on
the most hateful of all G80 chipsets (that'd be the original 8800).
I'll look into that more at some stage.  Work is needed elsewhere
before this will be useful anyway.

The most straight-forward way to try this out is to build the kernel
(2.6.30-rc7) with CONFIG_DRM_TTM and CONFIG_DRM_NOUVEAU enabled.  There
are ways to build against your current kernel, but I'll leave that as an
exercise to the reader.

Anyway, there are still some rough patches, but people have been asking
about this for a while now.  If testing, please report any
bugs/regressions noticed.

Ben.

___
Nouveau mailing list
Nouveau@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/nouveau


Re: [Nouveau] Nouveau DRM kernel tree

2009-06-03 Thread Maarten Maathuis
If you had to estimate, how long did it take you to figure out evo?

Anyway, it looks nice, i will certainly try when i'm home again.

Maarten.
___
Nouveau mailing list
Nouveau@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/nouveau


Re: [Nouveau] Nouveau DRM kernel tree

2009-06-03 Thread Ben Skeggs
On Wed, 2009-06-03 at 15:49 +0200, Maarten Maathuis wrote:
 If you had to estimate, how long did it take you to figure out evo?
It's hard to say.  It works pretty much exactly how I said I thought it
would ages back.  The missing piece (as expected) was using the push
buffer rather than poking stuff into 0x610300 directly.  That, I
stumbled on the idea of how to track down accidentally while looking at
another bug a couple of weeks back.

The missing bits (the meaning of 0x86c in non-linear mode, and that the
CRTCs want buffers with 0x7a00 in the page flags) for non-linear
scanout, I sat down and worked out yesterday.

 
 Anyway, it looks nice, i will certainly try when i'm home again.
Good luck!

Ben.
 
 Maarten.

___
Nouveau mailing list
Nouveau@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/nouveau