On Tue, 2008-11-04 at 12:54 -0800, Eric Anholt wrote:
> When userland detected that this ioctl was supported (by version number
> check),
> it used it in a racy way -- dispatch delayed swap, wait for vblank, continue
> rendering. As there was no mechanism for it to wait for the swap to finish,
> s
http://bugs.freedesktop.org/show_bug.cgi?id=18347
--- Comment #8 from Owen Taylor <[EMAIL PROTECTED]> 2008-11-05 06:39:01 PST ---
I'll try this evening, but my understanding is no. To quote Keith's mail:
i915_gem_object_set_domain is also used from the set_domain ioctl. In
this case, the
Now that the radeon driver has suspend/resume functions, it needs to map its
registers at load time or it will likely crash if a suspend operation occurs
before the driver has been initialized.
This patch moves the register mapping code from firstopen to load and makes
the mapping into a _DRM_DRIV
On Wed, 2008-11-05 at 11:08 -0800, Jesse Barnes wrote:
> Now that the radeon driver has suspend/resume functions, it needs to map its
> registers at load time or it will likely crash if a suspend operation occurs
> before the driver has been initialized.
>
> This patch moves the register mapping c
On Wed, Nov 5, 2008 at 2:08 PM, Jesse Barnes <[EMAIL PROTECTED]> wrote:
> Now that the radeon driver has suspend/resume functions, it needs to map its
> registers at load time or it will likely crash if a suspend operation occurs
> before the driver has been initialized.
>
> This patch moves the re
Here's an updated patch set for core DRM + i915 mode setting. I spent a
good part of the day trying to reduce the size of the patches against
the core, so things should be nearly reviewable now. I'm still tracking
down the unload/load bug (was hoping the diff reduction + audit would
magically fi
Add support for mapping of GEM objects if the underlying driver supports it.
---
drivers/gpu/drm/drm_bufs.c|6 ++
drivers/gpu/drm/drm_drv.c |6 ++
drivers/gpu/drm/drm_fops.c| 12 -
drivers/gpu/drm/drm_gem.c | 109 +
drivers/gpu
Use the new core GEM object mapping code to allow GTT mapping of GEM objects
on i915. The fault handler will make sure a fence register is allocated too,
if the object in question is tiled.
---
Makefile |2 +-
drivers/gpu/drm/i915/i915_dma.c|1 +
driv
http://bugs.freedesktop.org/show_bug.cgi?id=18347
--- Comment #9 from Owen Taylor <[EMAIL PROTECTED]> 2008-11-05 17:53:34 PST ---
Contrary to my expectation, my patch in isolation does fix the problem I was
observing!
--
Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=emai
http://bugs.freedesktop.org/show_bug.cgi?id=18347
Eric Anholt <[EMAIL PROTECTED]> changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolu
On Wed, 2008-11-05 at 16:49 -0800, Jesse Barnes wrote:
> Use the new core GEM object mapping code to allow GTT mapping of GEM objects
> on i915. The fault handler will make sure a fence register is allocated too,
> if the object in question is tiled.
I required the following patch on top of your
This fixes hangs on 855-class hardware by avoiding double attachment of the
driver due to the stub second head device having the same pci id as the real
device.
Other DRM drivers probably want this treatment as well, but I'm applying it
just to this one for safety.
Signed-off-by: Eric Anholt <[EM
12 matches
Mail list logo
