[PATCH] drm: remove procfs code, take 2

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

[Bug 66425] "failed testing IB on ring 5" when suspending to disk

was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20130710/135e8e29/attachment-0001.html>

[Bug 66425] "failed testing IB on ring 5" when suspending to disk

es/dri-devel/attachments/20130710/7d2d22b9/attachment.html>

Questions about TTM buffer object maping

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

[RFC PATCH v1 2/2] dma-buf: add lock callback for fcntl system call.

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 ---

[RFC PATCH v4 1/2] dmabuf-sync: Introduce buffer synchronization framework

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

[RFC PATCH v4 0/2] Introduce buffer synchronization framework

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

[PATCH] drm: don't call ->firstopen for KMS drivers

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

Bug in warning message from MTRR rework in uvesafb

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) > +

[Bug 57381] Radeon HD6950: Resuming from hibernation fails sometimes

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

[PATCH v2 00/14] Platform Framebuffers and SimpleDRM

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

Bug in warning message from MTRR rework in uvesafb

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

[PATCH 33/39] drm: rip out drm_core_has_MTRR checks

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

[PATCH] drm/prime: remove cargo-cult locking from map_sg helper

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

[PATCH 2/2] drm/docs: rip out removed driver flags documentation

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

[PATCH 1/2] drm: rip out drm_core_has_MTRR checks

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

[PATCH 33/39] drm: rip out drm_core_has_MTRR checks

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

[PATCH 2/2] drm: move dev data clearing from drm_setup to lastclose

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

[PATCH 1/2] drm: rip out dev->last_checked

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

[PATCH 33/39] drm: rip out drm_core_has_MTRR checks

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

[PATCH 00/39] clean out drm cruft and hide it better for kms drivers

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". > >

[PATCH] drm: remove FASYNC support

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

[PATCH] drm: remove FASYNC support

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

[PATCH 33/39] drm: rip out drm_core_has_MTRR checks

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

[PATCH] drm/prime: remove cargo-cult locking from map_sg helper

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

[PATCH 08/39] drm: remove redundant clears from drm_setup

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

[PATCH] drm: remove the dma_ioctl special-case

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

[PATCH 01/12] drivers/gpu/drm/tilcdc: don't use devm_pinctrl_get_select_default() in probe

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 --

[PATCH] drm: remove FASYNC support

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

[PATCH] drm/prime: remove cargo-cult locking from map_sg helper

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

[Bug 65723] Xonotic glsl 1.30 broken due to lack of derivatives support in radeonsi

-- 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>

[PATCH] drm/prime: remove cargo-cult locking from map_sg helper

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

[PATCH 34/39] drm: remove the dma_ioctl special-case

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

[PATCH 1/2] drm/rcar-du: Use the GEM PRIME helpers

ication/pgp-signature Size: 836 bytes Desc: Digital signature URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20130710/f571c78a/attachment-0001.pgp>

Exposing GPU information for userspace processes

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

[PATCH 2/2] drm/shmobile: Use the GEM PRIME helpers

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 ---

[PATCH 1/2] drm/rcar-du: Use the GEM PRIME helpers

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 ---

[PATCH 0/2] GEM CMA PRIME fixes for v3.11

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

[PATCH 33/39] drm: rip out drm_core_has_MTRR checks

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 > --- >

[PATCH] drm/prime: remove cargo-cult locking from map_sg helper

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

[PATCH 08/39] drm: remove redundant clears from drm_setup

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

[PATCH] drm/i915: remove unused members from drm_i915_private

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

[Bug 66450] JUNIPER UVD accelerated playback of MPEG 1/2 streams does not work

://lists.freedesktop.org/archives/dri-devel/attachments/20130710/2e000176/attachment.html>

[PATCH] drm/i915: remove unused members from drm_i915_private

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 { }

[Bug 66450] JUNIPER UVD accelerated playback of MPEG 1/2 streams does not work

ail 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>

[PATCH] drm/prime: remove cargo-cult locking from map_sg helper

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

[Bug 66450] JUNIPER UVD accelerated playback of MPEG 1/2 streams does not work

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

[PATCH 39/39] drm: remove procfs code, take 2

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

[PATCH 38/39] drm: fix locking in gem debugfs/procfs file

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

[PATCH 37/39] drm: no-op out GET_STATS ioctl

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

[PATCH 36/39] drm: hollow-out GET_CLIENT ioctl

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

[PATCH 35/39] drm/memory: don't export agp helpers

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

[PATCH 34/39] drm: remove the dma_ioctl special-case

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

[PATCH 33/39] drm: rip out drm_core_has_MTRR checks

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 +--

[PATCH 32/39] drm: remove a bunch of unused #defines from drmP.h

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

[PATCH 31/39] drm: rip out a few unused DRIVER flags

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

[PATCH 30/39] drm: rip out DRIVER_FB_DMA and related code

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

[PATCH 29/39] drm: remove FASYNC support

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

[PATCH 28/39] drm/vmwgfx: remove redundant clearing of driver->dma_quiescent

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 +++

[PATCH 27/39] drm: mark context support as a legacy subsystem

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

[PATCH 26/39] drm: remove drm_order

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 ---

[PATCH 25/39] drm/radeon: s/drm_order/order_base_2/

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

[PATCH 24/39] drm/r128: s/drm_order/order_base_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 ---

[PATCH 23/39] drm/bufs: s/drm_order/order_base_2/

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

[PATCH 22/39] drm: move drm_getsarea into drm_bufs.c

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

[PATCH 21/39] drm: disallow legacy dma ioctls for modesetting drivers

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

[PATCH 20/39] drm/nouveau: drop DRIVER_PCI_DMA and DRIVER_SG

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

[PATCH 19/39] drm: mark dma setup/teardown as legacy systems

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 +++-

[PATCH 18/39] drm: disallow legacy sg ioctls for modesetting drivers

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:

[PATCH 17/39] drm: hide legacy sg cleanup better from common code

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 ++-

[PATCH 16/39] drm: fold in drm_sg_alloc into the ioctl

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

[PATCH 15/39] drm/radeon: remove DRIVER_HAS_DMA/SG/PCI_DMA from the kms driver

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

[PATCH 14/39] drm: kill dev->driver->set_version

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

[PATCH 13/39] drm: don't call ->firstopen for KMS drivers

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:

[PATCH 12/39] drm/vmwgfx: remove ->firstopen callback

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

[PATCH 11/39] drm/imx: kill firstopen callback

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

[PATCH 10/39] drm/radeon: kill firstopen callback for kms driver

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

[PATCH 09/39] drm/omap: kill firstopen callback

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

[PATCH 08/39] drm: remove redundant clears from drm_setup

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 ---

[PATCH 07/39] drm: kill dev->buf_readers and dev->buf_writers

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 ---

[PATCH 06/39] drm/radoen: kill radeon_dma_ioctl_kms

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

[PATCH 05/39] drm: kill dev->ctx_start and dev->lck_start

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 ---

[PATCH 04/39] drm: kill dev->interrupt_flag and dev->dma_flag

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 ---

[PATCH 03/39] drm: remove dev->last_switch

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

[PATCH 02/39] drm: kill dev->context_wait

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

[PATCH 01/39] drm: remove drm_modctx ioctl and use drm_noop instead

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

[PATCH 00/39] clean out drm cruft and hide it better for kms drivers

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". Comments, flames and review highly welcome. I'd be especially happy if the

[PATCH] drm/prime: remove cargo-cult locking from map_sg helper

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 and map it with > dma_map_sg (in the helper). > > Only the

[Bug 66767] atombios stuck in loop for more than 5secs aborting after suspend to ram

https://bugs.freedesktop.org/show_bug.cgi?id=66767 --- Comment #2 from Johannes Hirte --- It's a discrete only gpu, no hybrid. full dmesg output: [0.00] Initializing cgroup subsys cpuset [0.00] Initializing cgroup subsys cpu [0.00] Initializing cgroup subsys cpuacct [

[PATCH] drm/prime: remove cargo-cult locking from map_sg helper

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

[Bug 66450] JUNIPER UVD accelerated playback of MPEG 1/2 streams does not work

art -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20130710/26693b43/attachment.html>

[Bug 66450] JUNIPER UVD accelerated playback of MPEG 1/2 streams does not work

: <http://lists.freedesktop.org/archives/dri-devel/attachments/20130710/5ce610db/attachment.html>

[PATCH] drm/rcar-du: Add missing dependency on CMA

API exposed to drivers :-) I've successfully built the driver with CONFIG_CMA disabled. Could you please share the .config that resulted in a link error ? -- Regards, Laurent Pinchart -- next part -- A non-text attachment was scrubbed... Name: signature.asc Type: applicatio

[PATCH 3/3] drm/edid: Make edid_load() return a void *

Always use "void *" for arbitrary memory buffers, as this allows to drop casts in assignments. Signed-off-by: Geert Uytterhoeven --- drivers/gpu/drm/drm_edid_load.c |4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/gpu/drm/drm_edid_load.c

[PATCH 2/3] drm/edid: Fix uninitialized return variable in edid_load()

drivers/gpu/drm/drm_edid_load.c: In function ?edid_load?: drivers/gpu/drm/drm_edid_load.c:141: warning: ?edid? may be used uninitialized in this function In some error cases, edid_load() will return the uninitialized variable. Initialize it to NULL to fix this. Signed-off-by: Geert Uytterhoeven

[PATCH 1/3] drm/edid: Fix constness warning in drm_load_edid_firmware()

drivers/gpu/drm/drm_edid_load.c: In function ?drm_load_edid_firmware?: drivers/gpu/drm/drm_edid_load.c:245: warning: initialization discards qualifiers from pointer target type drm_get_connector_name() returns a "const char *", hence propagate the const where needed. Signed-off-by: Geert

[Bug 66768] UVD decoding of MPEG2 streams doesn't work on CEDAR

ttp://lists.freedesktop.org/archives/dri-devel/attachments/20130710/31a9c885/attachment-0001.html>

[Bug 66450] JUNIPER UVD accelerated playback of MPEG 1/2 streams does not work

: <http://lists.freedesktop.org/archives/dri-devel/attachments/20130710/5ee61832/attachment.html>

[Bug 66767] atombios stuck in loop for more than 5secs aborting after suspend to ram

-- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20130710/3bb9e4fb/attachment.html>

[Bug 66551] System hang on rs780 with latest Linus kernel

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/629eb011/attachment.html>

  1   2   3   >