History log of /drivers/gpu/drm/nouveau/nv40_grctx.c
Revision Date Author Comments (<<< Hide modified files) (Show modified files >>>)
c693931d93facab671bafdcebf515520663c22fc 11-Jan-2011 Ben Skeggs <bskeggs@redhat.com> drm/nv40: make detection of 0x4097-ful chipsets available everywhere

Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
/drivers/gpu/drm/nouveau/nv40_grctx.c
b3beb167af0de6d7cb03aed0687eca645cfd06a6 01-Sep-2010 Ben Skeggs <bskeggs@redhat.com> drm/nouveau: modify object accessors, offset in bytes rather than dwords

Reviewed-by: Francisco Jerez <currojerez@riseup.net>
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
/drivers/gpu/drm/nouveau/nv40_grctx.c
de1f46a4b97ad93870a06065cc2ef72e2c89fe35 12-Apr-2010 Ben Skeggs <bskeggs@redhat.com> drm/nv40: remove some completed ctxprog TODOs

I actually thought these were gone already when the initial commit was
done.. I guess not!

Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
/drivers/gpu/drm/nouveau/nv40_grctx.c
054b93e444550a72aef17115363cdef253b9ee7c 15-Dec-2009 Ben Skeggs <bskeggs@redhat.com> drm/nv40: implement ctxprog/state generation

The context programs are *very* simple compared to the ones used by
the binary driver. There's notes in nv40_grctx.c explaining most of
the things we don't implement. If we discover if/why any of it is
required further down the track, we'll handle it then.

The PGRAPH state generated for each chipset should match what NVIDIA
do almost exactly (there's a couple of exceptions). If someone has
a lot of time on their hands, they could figure out the mapping of
object/method to PGRAPH register and demagic the initial state a little,
it's not terribly important however.

At time of commit, confirmed to be working at least well enough for
accelerated X (and where tested, for 3D apps) on NV40, NV43, NV44, NV46,
NV49, NV4A, NV4B and NV4E.

A module option has been added to force the use of external firmware
blobs if it becomes required.

Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
/drivers/gpu/drm/nouveau/nv40_grctx.c