On Thu, Jul 11, 2013 at 01:45:29AM +0200, David Herrmann wrote:
> DRM core shares a single address_space across all inodes that belong to
> the same DRM device. This allows efficient unmapping of user-space
> mappings during buffer destruction. However, there is no easy way to get a
> shared addres
On Wed, Jul 10, 2013 at 09:00:33PM -0400, Jerome Glisse wrote:
> On Wed, Jul 10, 2013 at 8:27 PM, Jean-Sébastien Pédron
> wrote:
> > Hello,
> >
> > I'm trying to understand how TTM buffer object mapping works on Linux, to
> > make this behave properly on FreeBSD.
> >
> > Here's what I think I unde
https://bugs.freedesktop.org/show_bug.cgi?id=65723
--- Comment #7 from Rafael Castillo ---
tested and working, many thanks for your hard work
--
You are receiving this mail because:
You are the assignee for the bug.
___
dri-devel mailing list
dri-deve
unmapped
Advanced Joystick settings initialized
Redownloading all lightmaps
ALSA lib pcm.c:7339:(snd_pcm_recover) underrun occurred
Uploading dump (out-of-process) [proxy '']
/tmp/dumps/assert_20130711011649_1.dmp
/home/lordh/.local/share/Steam/SteamApps/common/Portal/hl2.sh : ligne 67 :
14112 Abandon (core dumped)${GAME_DEBUGGER}
"${GAMEROOT}"/${GAMEEXE} "$@"
Game removed: AppID 400 "Portal", ProcID 14112
-->8--
--
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130710/37813f27/attachment.html>
So almost two years ago I've tried to nuke the procfs code already
once before:
http://lists.freedesktop.org/archives/dri-devel/2011-October/015707.html
The conclusion was that userspace drivers (specifically libdrm device
node detection) stopped relying on procfs in 2001. But after some
digging
scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130710/135e8e29/attachment-0001.html>
g/archives/dri-devel/attachments/20130710/7d2d22b9/attachment.html>
On Wed, Jul 10, 2013 at 8:27 PM, Jean-S?bastien P?dron
wrote:
> Hello,
>
> I'm trying to understand how TTM buffer object mapping works on Linux, to
> make this behave properly on FreeBSD.
>
> Here's what I think I understand:
>
> When a buffer object is mmap()'d, ttm_bo_vm_open() is called. When
This patch adds lock callback to dma buf file operations,
and this callback will be called by fcntl system call.
With this patch, fcntl system call can be used for buffer
synchronization between CPU and CPU, and CPU and DMA in user mode.
Signed-off-by: Inki Dae
Signed-off-by: Kyungmin Park
---
This patch adds a buffer synchronization framework based on DMA BUF[1]
and reservation[2] to use dma-buf resource, and based on ww-mutexes[3]
for lock mechanism.
The purpose of this framework is to provide not only buffer access control
to CPU and DMA but also easy-to-use interfaces for device dri
Hi all,
This patch set introduces a buffer synchronization framework based
on DMA BUF[1] and reservation[2] to use dma-buf resource, and based
on ww-mutexes[3] for lock mechanism.
The purpose of this framework is to provide not only buffer access
control to CPU and CPU, and CPU and DMA, and DMA a
It has way too much potential for driver writers to do stupid things
like delayed hw setup because the load sequence is somehow racy (e.g.
the imx driver in staging). So don't call it for modesetting drivers,
which reduces the complexity of the drm core -> driver interface a
notch.
v2: Don't forge
On Wed, Jul 10, 2013 at 7:07 PM, Torsten Kaiser
wrote:
> Commit 63e28a7a5ffce59b645ca9cbcc01e1e8be56bd75, "uvesafb: Clean up
> MTRR code" contains the following change:
>
> @@ -1930,6 +1891,9 @@ static int uvesafb_setup(char *options)
> }
> }
>
> +if (mtrr != 3 && mtrr != 1)
> +
https://bugzilla.kernel.org/show_bug.cgi?id=57381
Harald Judt changed:
What|Removed |Added
Kernel Version||3.8.13
--- Comment #21 from Harald Judt --
https://bugs.freedesktop.org/show_bug.cgi?id=66558
Björn Beutel changed:
What|Removed |Added
Assignee|dri-devel@lists.freedesktop |mesa-dev@lists.freedesktop.
Hi
On Tue, Jul 9, 2013 at 11:02 PM, Stephen Warren
wrote:
> On 07/04/2013 06:25 AM, David Herrmann wrote:
>> Hi
>>
>> This series changes the way we handle firmware framebuffers on x86 systems.
>> On
>> other architectures the recently introduced "simple-framebuffer"
>> platform-devices provide
Commit 63e28a7a5ffce59b645ca9cbcc01e1e8be56bd75, "uvesafb: Clean up
MTRR code" contains the following change:
@@ -1930,6 +1891,9 @@ static int uvesafb_setup(char *options)
}
}
+if (mtrr != 3 && mtrr != 1)
+pr_warn("uvesafb: mtrr should be set to 0 or 3; %d is
unsupported
On Wed, Jul 10, 2013 at 6:27 PM, Andy Lutomirski wrote:
> Are all of those codepaths really inaccessible in non-legacy drm
> drivers? I didn't try to fully unravel all the ioctls and such, but
> it seems like userspace could add bufs and map them. Since the mtrr
> code isn't very robust (referen
Op 10-07-13 16:48, Daniel Vetter schreef:
> I've checked both implementations (radeon/nouveau) and they both grab
> the page array from ttm simply by dereferencing it and then wrapping
> it up with drm_prime_pages_to_sg in the callback and map it with
> dma_map_sg (in the helper).
>
> Only the grab
I've forgotten this and shuffling all the little pieces into the
respective patches is rather cumbersome ...
Signed-off-by: Daniel Vetter
---
Documentation/DocBook/drm.tmpl | 29 -
1 file changed, 29 deletions(-)
diff --git a/Documentation/DocBook/drm.tmpl b/Document
The new arch_phys_wc_add/del functions do the right thing both with
and without MTRR support in the kernel. So we can drop these
additional checks.
David Herrmann suggest to also kill the DRIVER_USE_MTRR flag since
it's now unused, which spurred me to do a bit a better audit of the
affected driver
On Wed, Jul 10, 2013 at 8:27 PM, Jean-Sébastien Pédron
wrote:
> Hello,
>
> I'm trying to understand how TTM buffer object mapping works on Linux, to
> make this behave properly on FreeBSD.
>
> Here's what I think I understand:
>
> When a buffer object is mmap()'d, ttm_bo_vm_open() is called. When
On Wed, Jul 10, 2013 at 5:41 PM, David Herrmann
wrote:
> On Wed, Jul 10, 2013 at 5:22 PM, Daniel Vetter
> wrote:
>> On Wed, Jul 10, 2013 at 3:51 PM, David Herrmann
>> wrote:
-#if __OS_HAS_MTRR
-static inline int drm_core_has_MTRR(struct drm_device *dev)
-{
- return d
Hello,
I'm trying to understand how TTM buffer object mapping works on Linux,
to make this behave properly on FreeBSD.
Here's what I think I understand:
When a buffer object is mmap()'d, ttm_bo_vm_open() is called. When
there's a page fault, the page is looked up and inserted in the VMA
usi
We kzalloc this structure, and for real kms devices we should never
loose track of things really.
But ums/legacy drivers rely on the drm core to clean up a bit of cruft
between lastclose and firstopen (i.e. when X is being restarted), so
keep this around. But give it a clear drm_legacy_ prefix and
Only ever re-cleared in drm_setup, otherwise completely unused.
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/drm_fops.c | 1 -
include/drm/drmP.h | 1 -
2 files changed, 2 deletions(-)
diff --git a/drivers/gpu/drm/drm_fops.c b/drivers/gpu/drm/drm_fops.c
index d1b4771..5679971 100644
Hi
On Wed, Jul 10, 2013 at 5:22 PM, Daniel Vetter
wrote:
> On Wed, Jul 10, 2013 at 3:51 PM, David Herrmann
> wrote:
>>> -#if __OS_HAS_MTRR
>>> -static inline int drm_core_has_MTRR(struct drm_device *dev)
>>> -{
>>> - return drm_core_check_feature(dev, DRIVER_USE_MTRR);
>>> -}
>>> -#else
Hi
On Wed, Jul 10, 2013 at 2:11 PM, Daniel Vetter
wrote:
> Hi all,
>
> I've figured that it's again time for a bit of (late) drm spring cleanup. This
> series here consists of a pile of "rip old stuff out" patches interleaved with
> "disable old cruft for kms drivers and hide it better".
>
> Com
Hi Daniel,
Thank you for the patch.
On Wednesday 10 July 2013 17:25:04 Daniel Vetter wrote:
> So I've stumbled over drm_fasync and wondered what it does. Digging
> that up is quite a story.
>
> First I've had to read up on what this does and ended up being rather
> bewildered why peopled loved s
So I've stumbled over drm_fasync and wondered what it does. Digging
that up is quite a story.
First I've had to read up on what this does and ended up being rather
bewildered why peopled loved signals so much back in the days that
they've created SIGIO just for that ...
Then I wondered how this e
So I've stumbled over drm_fasync and wondered what it does. Digging
that up is quite a story.
First I've had to read up on what this does and ended up being rather
bewildered why peopled loved signals so much back in the days that
they've created SIGIO just for that ...
Then I wondered how this e
On Wed, Jul 10, 2013 at 3:51 PM, David Herrmann
wrote:
>> -#if __OS_HAS_MTRR
>> -static inline int drm_core_has_MTRR(struct drm_device *dev)
>> -{
>> - return drm_core_check_feature(dev, DRIVER_USE_MTRR);
>> -}
>> -#else
>> -#define drm_core_has_MTRR(dev) (0)
>> -#endif
>> -
>
> That was th
On Wed, Jul 10, 2013 at 5:18 PM, Konrad Rzeszutek Wilk
wrote:
>> So after a bit of irc chatting with Maarten this seems to be more
>> involved. The above check is to cache the dma mapping, but the
>> implementation is bogus in tons of ways:
>> - If direction changes we don't bother with unmaping a
On Wed, Jul 10, 2013 at 3:28 PM, David Herrmann
wrote:
> drm_setup() is called on every first open. I digged through core DRM
> and noticed that we have a lot of code that cleans up on lastclose and
> reinitializes on firstopen which is skipped for non-UMS drivers to
> preserve KMS state if no us
We might as well have a real ioctl function which checks for the
callbacks. This seems to be a remnant from back in the days when each
drm driver had their own complete ioctl table, with no shared core
drm table at all.
To make really sure no mis-guided user in a kms driver pops up again
explicitl
Since commit ab78029 (drivers/pinctrl: grab default handles from device core),
we can rely on device core for setting the default pins. Compile tested only.
Acked-by: Linus Walleij (personally at LCE13)
Signed-off-by: Wolfram Sang
---
drivers/gpu/drm/tilcdc/tilcdc_panel.c |6 --
driver
So I've stumbled over drm_fasync and wondered what it does. Digging
that up is quite a story.
First I've had to read up on what this does and ended up being rather
bewildered why peopled loved signals so much back in the days that
they've created SIGIO just for that ...
Then I wondered how this e
I've checked both implementations (radeon/nouveau) and they both grab
the page array from ttm simply by dereferencing it and then wrapping
it up with drm_prime_pages_to_sg in the callback and map it with
dma_map_sg (in the helper).
Only the grabbing of the underlying page array is anything we need
Instead of delaying inode initialization until first ->open(), we can use
an anonymous inode. This avoids modifying FS internal inode fields and
provides us a private address_space right during initialization.
Delayed TTM dev_mapping initialization is currently left untouched to keep
this simple.
DRM core shares a single address_space across all inodes that belong to
the same DRM device. This allows efficient unmapping of user-space
mappings during buffer destruction. However, there is no easy way to get a
shared address_space for DRM devices during initialization. Therefore, we
currently d
Hi
This implements anon_inodes_new() to create anonymous inodes. Patch #1
describes the changes to anon_inodes.c and why DRM could make great use of this.
Patch #2 converts DRM core to use anon_inodes_new() instead of delayed
dev_mapping initialization (but kept simple, TTM can be converted later)
--
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130710/9e80dc02/attachment.html>
On Wed, Jul 10, 2013 at 3:46 PM, Laurent Pinchart
wrote:
> On Wednesday 10 July 2013 13:54:33 Daniel Vetter wrote:
>> I've checked both implementations (radeon/nouveau) and they both grab
>> the page array from ttm simply by dereferencing it and then wrapping
>> it up with drm_prime_pages_to_sg in
Hi
On Wed, Jul 10, 2013 at 2:12 PM, Daniel Vetter
wrote:
> We might as well have a real ioctl function which checks for the
> callbacks. This seems to be a remnant from back in the days when each
> drm driver had their own complete ioctl table, with no shared core
> drm table at all.
>
> To make
https://bugs.freedesktop.org/show_bug.cgi?id=66805
Priority: medium
Bug ID: 66805
Assignee: dri-devel@lists.freedesktop.org
Summary: [radeonsi] half life 2 base games are segfaulting
Severity: blocker
Classification: Unclassified
igital signature
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130710/f571c78a/attachment-0001.pgp>
On Wed, Jul 10, 2013 at 7:45 AM, Rhyland Klein wrote:
> We are currently looking into exporting some information from the linux
> kernel to userspace about the GPU. This information is specific per
> board as the data can vary depending on the fuses burnt on the board.
>
> Right now we are leaning
The GEM CMA PRIME import/export helpers have been removed in favor of
generic GEM PRIME helpers with GEM CMA low-level operations. Fix the
driver accordingly.
Reported-by: Mark Brown
Signed-off-by: Laurent Pinchart
---
drivers/gpu/drm/shmobile/shmob_drm_drv.c | 9 +++--
1 file changed, 7 in
The GEM CMA PRIME import/export helpers have been removed in favor of
generic GEM PRIME helpers with GEM CMA low-level operations. Fix the
driver accordingly.
Reported-by: Mark Brown
Signed-off-by: Laurent Pinchart
---
drivers/gpu/drm/rcar-du/rcar_du_drv.c | 9 +++--
1 file changed, 7 inser
Hi Dave,
These two patches fix compilation breakages in drm-next due to the removal of
drm_gem_cma_dmabuf_import() and drm_gem_cma_dmabuf_export() without updating
the existing users (I don't blame anyone here, the patch that removed those
functions and the patches that made use of them were merge
Hi
On Wed, Jul 10, 2013 at 2:12 PM, Daniel Vetter
wrote:
> The new arch_phys_wc_add/del functions do the right thing both with
> and without MTRR support in the kernel. So we can drop these
> additional checks.
>
> Cc: Andy Lutomirski
> Signed-off-by: Daniel Vetter
> ---
> drivers/gpu/drm/drm
Hi Daniel,
On Wednesday 10 July 2013 13:54:33 Daniel Vetter wrote:
> I've checked both implementations (radeon/nouveau) and they both grab
> the page array from ttm simply by dereferencing it and then wrapping
> it up with drm_prime_pages_to_sg in the callback and map it with
> dma_map_sg (in the
https://bugs.freedesktop.org/show_bug.cgi?id=66425
--- Comment #19 from Harald Judt ---
I guess your debugging patch is only for rv770 and not for cayman?, but I
applied it nevertheless and it had no effect. The machine hibernated fine the
first time, but then the error message occurred the secon
https://bugs.freedesktop.org/show_bug.cgi?id=66425
--- Comment #18 from Harald Judt ---
Created attachment 82304
--> https://bugs.freedesktop.org/attachment.cgi?id=82304&action=edit
dmesg-hibernate.out
Ok, this is not a problem with tuxonice. I tried hibernating with current
vanilla git again,
Hi
On Wed, Jul 10, 2013 at 2:11 PM, Daniel Vetter
wrote:
> We kzalloc the driver node at init time, so no need to do this again.
>
> Signed-off-by: Daniel Vetter
> ---
> drivers/gpu/drm/drm_fops.c | 9 -
> 1 file changed, 9 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_fops.c b/dri
On Wed, Jul 10, 2013 at 02:27:31PM +0200, Maarten Lankhorst wrote:
> Signed-off-by: Maarten Lankhorst
Queued for -next, thanks for the patch.
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
;http://lists.freedesktop.org/archives/dri-devel/attachments/20130710/2e000176/attachment.html>
Signed-off-by: Maarten Lankhorst
---
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index a416645..d1b1928 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -1080,8 +1080,6 @@ typedef struct drm_i915_private {
} backlight;
his mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130710/1868b6e0/attachment.html>
On Wed, Jul 10, 2013 at 2:03 PM, Maarten Lankhorst
wrote:
> Op 10-07-13 13:54, Daniel Vetter schreef:
>> I've checked both implementations (radeon/nouveau) and they both grab
>> the page array from ttm simply by dereferencing it and then wrapping
>> it up with drm_prime_pages_to_sg in the callback
curate.
MPlayer interrupted by signal 11 in module: check_framedrop
--
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130710
So almost two years ago I've tried to nuke the procfs code already
once before:
http://lists.freedesktop.org/archives/dri-devel/2011-October/015707.html
The conclusion was that userspace drivers (specifically libdrm device
node detection) stopped relying on procfs in 2011. But after some
digging
The idr is protected with our spinlock, if we don't hold that nothing
prevents the gem objects from disappearing from under us.
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/drm_info.c | 4
1 file changed, 4 insertions(+)
diff --git a/drivers/gpu/drm/drm_info.c b/drivers/gpu/drm/drm_inf
Again only used by a tests in libdrm and by dristat. Nowadays we have
much better tracing tools to get detailed insights into what a drm
driver is doing. And for a simple "does it work" kind of question that
these stats could answer we have plenty of dmesg debug log spew.
So I don't see any use fo
We not only have debugfs files to do pretty much the equivalent of
lsof, we also have an ioctl. Not that compared to lsof this dumps a
wee bit more information, but we can still get at that from debugfs
easily.
I've dug around in mesa, libdrm and ddx histories and the only users
seem to be drm/tes
They're only used by the agpgart support code in drm_agpgart.c,
not by any drivers.
I think long-term we should create a drm_internal.h include file with
all the various functions only used by the drm core and not exported
to drivers, and remove them from drmP.h. Oh, and someone should kill
that u
We might as well have a real ioctl function which checks for the
callbacks. This seems to be a remnant from back in the days when each
drm driver had their own complete ioctl table, with no shared core
drm table at all.
To make really sure no mis-guided user in a kms driver pops up again
explicitl
The new arch_phys_wc_add/del functions do the right thing both with
and without MTRR support in the kernel. So we can drop these
additional checks.
Cc: Andy Lutomirski
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/drm_bufs.c | 13 +
drivers/gpu/drm/drm_pci.c | 11 +--
dr
Signed-off-by: Daniel Vetter
---
include/drm/drmP.h | 9 -
1 file changed, 9 deletions(-)
diff --git a/include/drm/drmP.h b/include/drm/drmP.h
index 2a7001f..62e9e41 100644
--- a/include/drm/drmP.h
+++ b/include/drm/drmP.h
@@ -164,13 +164,7 @@ int drm_err(const char *func, const char *fo
The gma500 driver somehow set the DRIVER_IRQ_VBL flag, but since
there's no code at all to check for this we can kill it. The other two
are completely unused.
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/gma500/psb_drv.c | 2 +-
include/drm/drmP.h | 3 ---
2 files changed, 1 in
No driver ever sets that flag, so good riddance!
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/drm_bufs.c | 161 +
include/drm/drmP.h | 1 -
2 files changed, 2 insertions(+), 160 deletions(-)
diff --git a/drivers/gpu/drm/drm_bufs.c b/driv
So I've stumbled over drm_fasync and wondered what it does. Digging
that up is quite a story.
First I've had to read up on what this does and ended up being rather
bewildered why peopled loved signals so much back in the days that
they've created SIGIO just for that ...
Then I wondered how this e
It's kzalloced ...
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/vmwgfx/vmwgfx_drv.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_drv.c
b/drivers/gpu/drm/vmwgfx/vmwgfx_drv.c
index 3e43578..3e75dfa 100644
--- a/drivers/gpu/drm/vmwgfx/vmwgfx_drv.c
+++ b/driv
So after a lot of digging around in git histories it looks like this
has only ever be used by dri1 render clients. Hence we can fully
disable the entire thing for modesetting drivers and so greatly reduce
the attack surface for potential exploits (or at least tools like
trinity ...).
Also add the
All users of it are now gone!
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/drm_bufs.c | 23 ---
include/drm/drmP.h | 1 -
2 files changed, 24 deletions(-)
diff --git a/drivers/gpu/drm/drm_bufs.c b/drivers/gpu/drm/drm_bufs.c
index 31a971d..25f 100644
--- a/dr
Last driver and pretty obviously a major user of this little function.
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/radeon/cik.c | 14 +++---
drivers/gpu/drm/radeon/evergreen.c | 4 ++--
drivers/gpu/drm/radeon/ni.c| 6 +++---
drivers/gpu/drm/radeon/r100.c | 2 +-
Again just use the version provided by the linux core.
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/r128/r128_cce.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/r128/r128_cce.c b/drivers/gpu/drm/r128/r128_cce.c
index d4660cf..c451257 100644
--- a/driver
The version offered by the core is ridiculously optimized and
does the same thing. So use it.
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/drm_bufs.c | 12 ++--
1 file changed, 6 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/drm_bufs.c b/drivers/gpu/drm/drm_bufs.c
index
It fiddles the sarea out of the maps which are also handled in
drm_bufs.c
With this drm_drv.c is a notch more legacy free.
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/drm_bufs.c | 14 ++
drivers/gpu/drm/drm_drv.c | 15 ---
2 files changed, 14 insertions(+), 15 dele
Now only legacy ums drivers have the DRIVER_HAVE_DMA driver feature
flag set, so strictly speaking the modesetting check is redundant. But
adding it has the upside that it makes it very clear that the dma
support is legacy stuff.
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/drm_bufs.c | 15 +
The former doesn't do anything without DRIVER_HAVE_DMA (which is
force-disabled for kms drivers anyway). The latter isn't used by the
(kms) nouveau ddx.
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/nouveau/nouveau_drm.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/driv
And hide the checks a bit better. This was already disallowed for
modesetting drivers, so no functinal change here.
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/drm_dma.c | 17 +++--
drivers/gpu/drm/drm_drv.c | 4 +---
drivers/gpu/drm/drm_fops.c | 12 +++-
include/drm/
Only the radeon/r128/ati ums drivers use this. Furthermore the cleanup
was already only done for UMS drivers. Also a quick check of the ATI
ddx git history shows that only the UMS code ever used this facility.
So we can safely disallow these pair of ioctls for modesetting
drivers.
Signed-off-by:
I've decided that some clear markers for what's legacy dri1/non-gem
code is useful. I've opted to use the drm_legacy prefix and then hide
all the checks in that function for better readability in the common
code.
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/drm_drv.c | 7 ++-
driver
There's no other caller from driver code, so we can fold this in.
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/drm_drv.c | 2 +-
drivers/gpu/drm/drm_scatter.c | 13 +++--
include/drm/drmP.h| 3 +--
3 files changed, 5 insertions(+), 13 deletions(-)
diff --git a/driv
Really, this is all old-style stuff and just copy-pasta from the
ums driver.
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/radeon/radeon_drv.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/radeon/radeon_drv.c
b/drivers/gpu/drm/radeon/radeon_drv.c
ind
Totally unused, so just rip it out. Anyway, we want drivers to be
fully backwards compatible, allowing them to change behaviour is just
a recipe for them to break badly.
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/drm_ioctl.c | 3 ---
include/drm/drmP.h | 2 --
2 files changed, 5 d
It has way too much potential for driver writers to do stupid things
like delayed hw setup because the load sequence is somehow racy (e.g.
the imx driver in staging). So don't call it for modesetting drivers,
which reduces the complexity of the drm core -> driver interface a
notch.
Signed-off-by:
So if we survey kms drivers there's a bunch of things they commonly do
in ->lastclose
- delayed processing of vga switcheroo requests (i915, nouveau,
radeon)
- force-restoring the fbcon (most)
- resetting a bunch properties to make fbcon work better (omap)
- disabling all outputs (vmwgfx)
In sho
This thing seems to do some kind of delayed setup. Really, real kms
drivers shouldn't do that at all. Either stuff needs to be dynamically
hotplugged or the driver setup sequence needs to be fixed.
This patch here just moves the setup at the very end of the driver
load callback, with the locking a
Again, it does nothing.
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/radeon/radeon_drv.c | 2 --
drivers/gpu/drm/radeon/radeon_kms.c | 13 -
2 files changed, 15 deletions(-)
diff --git a/drivers/gpu/drm/radeon/radeon_drv.c
b/drivers/gpu/drm/radeon/radeon_drv.c
index c07b681..1
KMS drivers really shouldn't need to do anything on firstopen, so kill
empty callbacks.
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/omapdrm/omap_drv.c | 7 ---
1 file changed, 7 deletions(-)
diff --git a/drivers/gpu/drm/omapdrm/omap_drv.c
b/drivers/gpu/drm/omapdrm/omap_drv.c
index 826
We kzalloc the driver node at init time, so no need to do this again.
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/drm_fops.c | 9 -
1 file changed, 9 deletions(-)
diff --git a/drivers/gpu/drm/drm_fops.c b/drivers/gpu/drm/drm_fops.c
index 57e3014..9610997 100644
--- a/drivers/gpu/dr
Again totally unused, so just remove them.
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/drm_fops.c | 2 --
include/drm/drmP.h | 2 --
2 files changed, 4 deletions(-)
diff --git a/drivers/gpu/drm/drm_fops.c b/drivers/gpu/drm/drm_fops.c
index a3714a0..57e3014 100644
--- a/drivers/gpu/
No need to create a dummy ioctl function to return -EINVAL, since
that's what the core already does in the absence of the dma_ioctl
callback. So we can safely remove this.
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/radeon/radeon_drv.c | 3 ---
drivers/gpu/drm/radeon/radeon_kms.c | 10
Again completely unused, so just remove it.
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/drm_fops.c | 3 ---
include/drm/drmP.h | 2 --
2 files changed, 5 deletions(-)
diff --git a/drivers/gpu/drm/drm_fops.c b/drivers/gpu/drm/drm_fops.c
index 386c304..a3714a0 100644
--- a/drivers/gp
Completely unused, so just remove them.
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/drm_fops.c | 2 --
include/drm/drmP.h | 2 --
2 files changed, 4 deletions(-)
diff --git a/drivers/gpu/drm/drm_fops.c b/drivers/gpu/drm/drm_fops.c
index c14fdc1..386c304 100644
--- a/drivers/gpu/drm
Only ever assigned in the context code for real, with no readers
anywhere. Remove it.
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/drm_context.c | 1 -
drivers/gpu/drm/drm_fops.c| 1 -
include/drm/drmP.h| 1 -
3 files changed, 3 deletions(-)
diff --git a/drivers/gpu/drm/drm_
No one ever waits on this waitqueue, so the wake_up call is wasted.
Remove it all.
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/drm_context.c | 1 -
drivers/gpu/drm/drm_fops.c| 1 -
include/drm/drmP.h| 1 -
3 files changed, 3 deletions(-)
diff --git a/drivers/gpu/drm/drm_con
It doesn't do anything, so kill the code.
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/drm_context.c | 6 --
drivers/gpu/drm/drm_drv.c | 2 +-
include/drm/drmP.h| 2 --
3 files changed, 1 insertion(+), 9 deletions(-)
diff --git a/drivers/gpu/drm/drm_context.c b/drivers/g
1 - 100 of 254 matches
Mail list logo
