| commit | 62cb70118c4efabb3c0a6f962168ddcad4344eef | |
| author | Alan Cox <alan@linux.intel.com> | |
| Tue, 7 Jun 2011 13:17:51 +0000 (7 14:17 +0100) | ||
| committer | Dave Airlie <airlied@redhat.com> | |
| Mon, 25 Jul 2011 11:07:15 +0000 (25 12:07 +0100) | ||
| tree | 68c8877c9fd761435082b84ae53c579e2a79fb93 | treesnapshot (tar.gz zip) |
| parent | 04fee895ef98ffbb91a941b53a92d6949bb6d1c4 | commitdiff |
drm/gem: add support for private objects
These small changes should allow GEM to be used with non shmem objects as
well as shmem objects. In the GMA500 case it allows the base framebuffer to
appear as a GEM object and thus acquire a handle and work with KMS.
For i915 it ought to be trivial to get back the wasted memory but putting the
system fb back into stolen RAM and in general I can imagine it allowing the
use of GEM and thus KMS with all the older cards that have their framebuffer
firmly placed in video RAM.
Signed-off-by: Alan Cox <alan@linux.intel.com>
Tested-by: Rob Clark <rob@ti.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
These small changes should allow GEM to be used with non shmem objects as
well as shmem objects. In the GMA500 case it allows the base framebuffer to
appear as a GEM object and thus acquire a handle and work with KMS.
For i915 it ought to be trivial to get back the wasted memory but putting the
system fb back into stolen RAM and in general I can imagine it allowing the
use of GEM and thus KMS with all the older cards that have their framebuffer
firmly placed in video RAM.
Signed-off-by: Alan Cox <alan@linux.intel.com>
Tested-by: Rob Clark <rob@ti.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
| drivers/gpu/drm/drm_gem.c | diffblobblamehistory | |
| include/drm/drmP.h | diffblobblamehistory |