Age | Commit message (Collapse) | Author |
|
Nouveau headers are installed in I${includedir}/libdrm.
|
|
As we clear the relocs from the bo, we also need to clear the
contribution of the reloc_target_bo from the fence count. Otherwise they
are leaked and prevent any further relocations being added to the bo.
|
|
I must have botched something in the push of the xml switchover, since I
now get errors when building the pages and aliases. Just disable for
now.
|
|
This adds an overview page that describes Dumb-Buffers, TTM and GEM. It
does not describe chipset-specific features. You should do that in the
driver-manpages.
Signed-off-by: David Herrmann <dh.herrmann@googlemail.com>
Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org>
|
|
This is an overview page for KMS. It is again targeted at novice users
that need redirection to the correct function man-pages.
Signed-off-by: David Herrmann <dh.herrmann@googlemail.com>
Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org>
|
|
The drm.xml file compiles to drm.7 and is meant as a global overview page
for libdrm. It is targeted to new users of libdrm and redirects to all
other main man-pages.
Signed-off-by: David Herrmann <dh.herrmann@googlemail.com>
Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org>
|
|
If we want to use the manpages in external documentation other than normal
manpages, we should rather use XML. Furthermore, almost no-one knows troff
today, anyway, and XML allows others to easily add more pages without
having to learn troff.
Signed-off-by: David Herrmann <dh.herrmann@googlemail.com>
|
|
Under certain circumstances it's possible for libdrm to decide to move
a GART|VRAM pushbuf to be VRAM-only. This causes the kernel to reject
the command submission on GF8 and up, due to a stricter policy where
buffers are only allowed to move to memory types that were specified
at creation time.
The simplest fix for this is to force the creation-time memory type for
the lifetime of the push buffer.
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
|
|
On error fstat return -1, instead return -EINVAL to caller
Signed-off-by: Maxime Villard <rustyBSD@gmx.fr>
Signed-off-by: Jerome Glisse <jglisse@redhat.com>
|
|
Signed-off-by: Maxime Villard <rustyBSD@gmx.fr>
Signed-off-by: Jerome Glisse <jglisse@redhat.com>
|
|
To avoid kernel rejecting cs if we return different global name
for same bo keep track of global name and always return the same.
Seems to fix issue with suspend/resume failing and repeatly printing
following message :
[drm:radeon_cs_ioctl] *ERROR* Failed to parse relocation -35!
There might still be way for a rogue program to trigger this issue.
Signed-off-by: Jerome Glisse <jglisse@redhat.com>
|
|
Signed-off-by: Alex Deucher <alexdeucher@gmail.com>
|
|
Originally posted to Free Desktop bug #52549 by David Shao.
Resolves Gentoo Bug #433403.
Commit message by Richard Yao.
Reviewed-by: Richard Yao <ryao@gentoo.org>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
References: https://bugs.freedesktop.org/show_bug.cgi?id=52549
Signed-off-by: Ben Widawsky <ben@bwidawsk.net>
|
|
|
|
typo,
Reported-by: mareko on irc
Signed-off-by: Dave Airlie <airlied@redhat.com>
|
|
The calculation led to the number 8192, which is too high.
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
|
|
radeon_cs_gem.c:333:13: warning: 'cs_gem_dump_bof' defined but
not used [-Wunused-function]
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
|
|
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
|
|
If we have valid timings, we can at least set width/height to
*something*, which is I think at least less confusing than always
seeing width/height of zero. At least modeprint and modetest
seem to expect width/height to mean something.
Signed-off-by: Rob Clark <rob@ti.com>
|
|
Signed-off-by: Rob Clark <rob@ti.com>
|
|
Signed-off-by: Rob Clark <rob@ti.com>
|
|
We don't want to build libdrm tests with Cairo support under Poky, since
they're never used and also cause a build loop from libdrm -> cairo ->
mesa-dri -> libdrm.
To avoid variance in build results, introduce a --disable-cairo-tests
switch.
Signed-off-by: Daniel Stone <daniel@fooishbar.org>
Signed-off-by: Dave Airlie <airlied@redhat.com>
|
|
intel_bufmgr_gem.c: In function 'drm_intel_bo_gem_export_to_prime':
intel_bufmgr_gem.c:2477:6: warning: unused variable 'ret' [-Wunused-variable]
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
|
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
|
commit 92fd0ce4f659d7b0680543e9e5b96a3c7737a5f3
Author: Daniel Vetter <daniel.vetter@ffwll.ch>
Date: Fri Aug 31 11:16:53 2012 +0200
intel: properly test for HAS_LLC
missed slightly and in effect had no effect on the outcome of checking
whether the kernel/chipset supported LLC.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
|
This allows texturing with depth-stencil buffers directly without the copy
to CB. The separate miptree description for stencil is added, because
the stencil mipmap offsets are not really depth offsets/4 (at least
for the texture units).
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
|
|
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
|
|
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
|
|
|
|
It's the same situation as flink and we need take the same precautions.
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Kristian Høgsberg <krh@bitplanet.net>
|
|
Just some PCI ID stuff to enable the right features.
|
|
Signed-off-by: Marcin Slusarz <marcin.slusarz@gmail.com>
|
|
Another corner case that isn't well-explained yet.
Signed-off-by: Michel Dänzer <michel.daenzer@amd.com>
Reviewed-by: Christian König <christian.koenig@amd.com>
|
|
Signed-off-by: Michel Dänzer <michel.daenzer@amd.com>
Reviewed-by: Christian König <christian.koenig@amd.com>
|
|
Signed-off-by: Michel Dänzer <michel.daenzer@amd.com>
Reviewed-by: Christian König <christian.koenig@amd.com>
|
|
If the kernel supports the test, we need to check the param.
Copy&pasta from the above checks that only look at the return value.
Interesting how much one can get such a simple interface wrong.
Issue created in
commit 151cdcfe685ee280a4344dfc40e6087d74a5590f
Author: Eugeni Dodonov <eugeni.dodonov@intel.com>
Date: Tue Jan 17 15:20:19 2012 -0200
intel: query for LLC support
Patch even claims to have fixed this in v2, but is actually unchanged
from v1.
Reported-by: Xiang, Haihao <haihao.xiang@intel.com>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
|
And hasn't been in a long while.
Reviewed-by: Zack Rusin <zackr@vmware.com>
Signed-off-by: Jakob Bornecrantz <jakob@vmware.com>
|
|
|
|
I am not sure whether this is needed, but better be safe than sorry.
|
|
Reviewed-by: Jerome Glisse <jglisse@redhat.com>
|
|
omap_drm.h uses data type defined in stdint.h, but that header was
not included.
omap_drm.h includes drm.h as a local file when it is part of the
compiler c flags.
This two issues are fixed. New code can include omap_drm.h alone.
Signed-off-by: Víctor Manuel Jáquez Leal <vjaquez@igalia.com>
Signed-off-by: Rob Clark <rob@ti.com>
|
|
this adds radeon version of the prime import/export support.
Signed-off-by: Dave Airlie <airlied@redhat.com>
|
|
Otherwise pad appears uninitialized and valgrind grumbles.
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Eric Anholt <eric@anholt.net>
|
|
Signed-off-by: Marek Olšák <maraeo@gmail.com>
|
|
|
|
|
|
Reviewed-by: Ben Widawsky <ben@bwidawsk.net>
|
|
Reviewed-by: Ben Widawsky <ben@bwidawsk.net>
|
|
It warns about totally sensible things done in intel_decode.c. I've
never seen this warn do anything useful, and apparently I was the one
to introduce it when I added the giant pile of warning flags back in
2008.
Reviewed-by: Ben Widawsky <ben@bwidawsk.net>
|
|
Reviewed-by: Jerome Glisse <jglisse@redhat.com>
|