[Bug 71067] [drm:r600] UVD not responding OR failed testing IB on GFX ring

URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20131103/d2c9d428/attachment.html>

[Bug 71194] Null Pointer dereference in drm_send_blank_event

art -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20131103/21f82d14/attachment.html>

[Bug 71194] Null Pointer dereference in drm_send_blank_event

. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20131103/f99b7459/attachment-0001.html>

[Bug 71194] Null Pointer dereference in drm_send_blank_event

|| -- 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/20131103/3cb70165/attachment.html>

[Bug 71194] Null Pointer dereference in drm_send_blank_event

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

[Bug 71194] Null Pointer dereference in drm_send_blank_event

-- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20131103/304d592a/attachment.html>

[PATCH] drm: restrict the device list for shadow attached drivers

There's really no need for the drm core to keep a list of all devices of a given driver - the linux device model keeps perfect track of this already for us. The exception is old legacy ums drivers using pci shadow attaching. So rename the lists to make the use case clearer and rip out everything

[Bug 71194] New: Null Pointer dereference in drm_send_blank_event

art -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20131103/5d37e05c/attachment.html>

[PATCH] drm: kill the ->agp_destroy callback

Call drm_pci_agp_destroy directly, there's no point in the indirection. Long term we want to shuffle this into each driver's unload logic, but that needs cleared-up drm lifetime rules first. v2: Add a dummy function for !CONFIG_PCI, spotted my David Herrmann. v3: Fixup for the coding style

[PATCH] drm: remove agp_init() bus callback

The PCI bus helper is the only user of it. Call it directly before device-registration to get rid of the callback. Note that all drm_agp_*() calls are locked with the drm-global-mutex so we need to explicitly lock it during initialization. It's not really clear why it's needed, but lets be safe.

[PATCH 17/19] drm: inline drm_agp_destroy

On Sun, Nov 03, 2013 at 02:43:44PM +0100, David Herrmann wrote: > Hi > > On Sun, Nov 3, 2013 at 2:31 PM, Daniel Vetter > wrote: > > Wrapping a kfree is pointless. > > > > Signed-off-by: Daniel Vetter > > --- > > I added that one dutifully to document the API in: > > commit

[PATCH] drm: kill the ->agp_destroy callback

Hey Daniel On Sun, Nov 3, 2013 at 3:24 PM, Daniel Vetter wrote: > Call drm_pci_agp_destroy directly, there's no point in the > indirection. Long term we want to shuffle this into each driver's > unload logic, but that needs cleared-up drm lifetime rules first. > > v2: Add a dummy function for

[PATCH] drm: kill the ->agp_destroy callback

Call drm_pci_agp_destroy directly, there's no point in the indirection. Long term we want to shuffle this into each driver's unload logic, but that needs cleared-up drm lifetime rules first. v2: Add a dummy function for !CONFIG_PCI, spotted my David Herrmann. Reviewed-by: David Herrmann Cc:

[PATCH 16/19] drm: remove agp_init() bus callback

On Sun, Nov 3, 2013 at 3:14 PM, David Herrmann wrote: >> diff --git a/drivers/gpu/drm/drm_pci.c b/drivers/gpu/drm/drm_pci.c >> index 4ec43b8d42f5..54eae6d83e5d 100644 >> --- a/drivers/gpu/drm/drm_pci.c >> +++ b/drivers/gpu/drm/drm_pci.c >> @@ -292,8 +292,6 @@ static struct drm_bus drm_pci_bus = {

[PATCH 16/19] drm: remove agp_init() bus callback

Hi Daniel On Sun, Nov 3, 2013 at 2:31 PM, Daniel Vetter wrote: > From: David Herrmann > > The PCI bus helper is the only user of it. Call it directly before > device-registration to get rid of the callback. > > Note that all drm_agp_*() calls are locked with the drm-global-mutex so we > need to

[PATCH 11/19] drm: restrict the device list for shadow attached drivers

On Sun, Nov 3, 2013 at 3:05 PM, David Herrmann wrote: > On Sun, Nov 3, 2013 at 2:31 PM, Daniel Vetter > wrote: >> There's really no need for the drm core to keep a list of all >> devices of a given driver - the linux device model keeps perfect >> track of this already for us. >> >> The

[PATCH 14/19] drm: ->agp_init can't fail

Hi Daniel On Sun, Nov 3, 2013 at 2:31 PM, Daniel Vetter wrote: > Thanks to the removal of REQUIRE_AGP we can use a void return value > and shed a bit of complexity. > > Signed-off-by: Daniel Vetter > --- > drivers/gpu/drm/drm_pci.c | 3 +-- > drivers/gpu/drm/drm_stub.c | 7 ++- >

[PATCH 12/19] drm/bufs: remove handling of _DRM_GEM mappings

Hi Daniel On Sun, Nov 3, 2013 at 2:31 PM, Daniel Vetter wrote: > Gone with the new gem vma offset manager from David. > > We can also ditch the uapi header definition from the enum since > userspace never used this. It ended up in there purely for historical > reasons (for reusing the old drm

[PATCH 11/19] drm: restrict the device list for shadow attached drivers

Hi Daniel On Sun, Nov 3, 2013 at 2:31 PM, Daniel Vetter wrote: > There's really no need for the drm core to keep a list of all > devices of a given driver - the linux device model keeps perfect > track of this already for us. > > The exception is old legacy ums drivers using pci shadow

[PATCH 18/19] drm: kill the ->agp_destroy callback

Hi Daniel On Sun, Nov 3, 2013 at 2:31 PM, Daniel Vetter wrote: > Call drm_pci_agp_destroy directly, there's no point in the > indirection. Long term we want to shuffle this into each driver's > unload logic, but that needs cleared-up drm lifetime rules first. > > Signed-off-by: Daniel Vetter >

[PATCH 01/19] drm/rcar: call drm_put_dev directly in the ->remove hook

Hi Daniel, Thank you for the patch. On Sunday 03 November 2013 14:31:07 Daniel Vetter wrote: > The magic dance drm_platform_exit does is actually a remnant of the > old legacy shadow attach support for platform devices. Modern modesetting > drm drivers shouldn't do this any more (and usb/pci

[PATCH 17/19] drm: inline drm_agp_destroy

Hi On Sun, Nov 3, 2013 at 2:31 PM, Daniel Vetter wrote: > Wrapping a kfree is pointless. > > Signed-off-by: Daniel Vetter > --- I added that one dutifully to document the API in: commit 28ec711cd427f8b61f73712a43b8100ba8ca933b Author: David Herrmann Date: Sat Jul 27 16:37:00 2013 +0200

[PATCH 5/6] dri3: Add DRI3 support to GLX, DRI common and Intel driver

I that can support all of the window systems sure seems like a better long-term plan... -- keith.packard at intel.com -- next part -- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 827 bytes Desc: not available URL: <http:

[PATCH 19/19] drm: remove global_mutex locking around agp_init

David Herrmann dutifully moved this locking along when moving the agp_init call out of the generic drm_dev_register into the pci specific load helpers. But afaict there's no need and the reason for that locking has been purely a historical accident - we need the lock around the driver dev node

[PATCH 18/19] drm: kill the ->agp_destroy callback

Call drm_pci_agp_destroy directly, there's no point in the indirection. Long term we want to shuffle this into each driver's unload logic, but that needs cleared-up drm lifetime rules first. Signed-off-by: Daniel Vetter --- drivers/gpu/drm/drm_pci.c | 3 +-- drivers/gpu/drm/drm_stub.c | 4 ++--

[PATCH 17/19] drm: inline drm_agp_destroy

Wrapping a kfree is pointless. Signed-off-by: Daniel Vetter --- drivers/gpu/drm/drm_agpsupport.c | 15 --- drivers/gpu/drm/drm_pci.c| 2 +- include/drm/drm_agpsupport.h | 5 - 3 files changed, 1 insertion(+), 21 deletions(-) diff --git

[PATCH 16/19] drm: remove agp_init() bus callback

From: David Herrmann The PCI bus helper is the only user of it. Call it directly before device-registration to get rid of the callback. Note that all drm_agp_*() calls are locked with the drm-global-mutex so we need to explicitly lock it during initialization. It's not

[PATCH 15/19] drm: rip out drm_core_has_AGP

Most place actually want to just check for dev->agp (most do, but a few don't so this fixes a few potential NULL derefs). The only exception is the agp init code which should check for the AGP driver feature flag. Signed-off-by: Daniel Vetter --- drivers/gpu/drm/drm_agpsupport.c| 2 +-

[PATCH 14/19] drm: ->agp_init can't fail

Thanks to the removal of REQUIRE_AGP we can use a void return value and shed a bit of complexity. Signed-off-by: Daniel Vetter --- drivers/gpu/drm/drm_pci.c | 3 +-- drivers/gpu/drm/drm_stub.c | 7 ++- include/drm/drmP.h | 2 +- 3 files changed, 4 insertions(+), 8 deletions(-)

[PATCH 13/19] drm: kill DRIVER_REQUIRE_AGP

Only the two intel drivers need this and they can easily check for working agp support in their driver ->load callbacks. This is the only reason why agp initialization could fail, so allows us to rip out a bit of error handling code in the next patch. Signed-off-by: Daniel Vetter ---

[PATCH 12/19] drm/bufs: remove handling of _DRM_GEM mappings

Gone with the new gem vma offset manager from David. We can also ditch the uapi header definition from the enum since userspace never used this. It ended up in there purely for historical reasons (for reusing the old drm mmap code essentially), not because userspace ever needed it. Cc: David

[PATCH 11/19] drm: restrict the device list for shadow attached drivers

There's really no need for the drm core to keep a list of all devices of a given driver - the linux device model keeps perfect track of this already for us. The exception is old legacy ums drivers using pci shadow attaching. So rename the lists to make the use case clearer and rip out everything

[PATCH 10/19] drm: rip out drm_platform_exit

This very much looks like a remnant of the old legady ums shadow attach days. Now with the last users gone we can rip it out since we won't ever support an ums drm driver again. Signed-off-by: Daniel Vetter --- drivers/gpu/drm/drm_platform.c | 11 --- include/drm/drmP.h | 1

[PATCH 09/19] drm/msm: call drm_put_dev directly in ->remove

The drvdata pointer is already assigned to something useful. Cc: Rob Clark Signed-off-by: Daniel Vetter --- drivers/gpu/drm/msm/msm_drv.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/msm/msm_drv.c b/drivers/gpu/drm/msm/msm_drv.c index

[PATCH 08/19] drm/armada: directly call drm_put_dev in ->remove

Again no apparent user of the driver data field. Cc: Russell King Signed-off-by: Daniel Vetter --- drivers/gpu/drm/armada/armada_drv.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/drivers/gpu/drm/armada/armada_drv.c

[PATCH 07/19] drm/host1x: Call drm_put_dev directly instead of drm_platform_exit

I'm a bit confused about how this all works wrt host1x clients, but this patch looks like the right thing to me. Cc: Thierry Reding Signed-off-by: Daniel Vetter --- drivers/gpu/host1x/drm/drm.c | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/drivers/gpu/host1x/drm/drm.c

[PATCH 06/19] drm/shmob: call drm_put_dev directly from ->remove hook

We need to chase one pointer here. Cc: Laurent Pinchart Signed-off-by: Daniel Vetter --- drivers/gpu/drm/shmobile/shmob_drm_drv.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/drivers/gpu/drm/shmobile/shmob_drm_drv.c

[PATCH 05/19] drm/omap: call drm_put_dev directly in ->remove

Again omap already sets the driver data pointer to the drm_device. Also drop the driver unregister call, that should be (and already is) done in the module unload hook. Cc: Rob Clark Signed-off-by: Daniel Vetter --- drivers/gpu/drm/omapdrm/omap_drv.c | 4 ++-- 1 file changed, 2 insertions(+),

[PATCH 04/19] drm/tilcdc: call drm_put_dev directly from ->remove

tilcdc already stores the drm_device in the driver data pointer. So use that. Cc: Rob Clark Signed-off-by: Daniel Vetter --- drivers/gpu/drm/tilcdc/tilcdc_drv.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/tilcdc/tilcdc_drv.c

[PATCH 03/19] drm/imx: directly call drm_put_dev in ->remove

Again no apparent user of the driver data field. Cc: Sascha Hauer Cc: Greg Kroah-Hartman Signed-off-by: Daniel Vetter --- drivers/staging/imx-drm/imx-drm-core.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/drivers/staging/imx-drm/imx-drm-core.c

[PATCH 02/19] drm/exynos: call drm_put_dev directly from ->remove

I didn't find any user of the driver data yet, so store the drm_device pointer in there. Cc: Inki Dae Signed-off-by: Daniel Vetter --- drivers/gpu/drm/exynos/exynos_drm_drv.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/drivers/gpu/drm/exynos/exynos_drm_drv.c

[PATCH 01/19] drm/rcar: call drm_put_dev directly in the ->remove hook

The magic dance drm_platform_exit does is actually a remnant of the old legacy shadow attach support for platform devices. Modern modesetting drm drivers shouldn't do this any more (and usb/pci devices actually don't do this). Cc: Laurent Pinchart

[PATCH 00/19] drm de-midlayer, part 1: device list and agp bus stuff

Hi all, So at ks there was a lot of talk about fixing up the drm device model to stop insanity like imx. And I kinda promised Dave to resurrect my latest branch at drm demidlayering - motivation kinda dissipated when I've started this a few moons back. So this is the first part. Patches 1-11

[PATCH 1/2] drm: remove agp_init() bus callback

On Sun, Nov 3, 2013 at 12:43 PM, David Herrmann wrote: >> Wrt patch 2 I don't see the point - better to just outright kill this >> callback and inline it like the agp_init one. > > 2/2 just does a rename. Where do you want to inline it? In > drm_pci_exit()? It calls drm_put_dev() which already

[PATCH 1/5] drm/radeon: rework and fix reset detection v2

2013/10/29 Christian K?nig : > From: Christian K?nig > > Stop fiddling with jiffies, always wait for RADEON_FENCE_JIFFIES_TIMEOUT. > Consolidate the two wait sequence implementations into just one function. > Activate all waiters and remember if the reset was already done instead of > trying to

[pull] radeon drm-next-3.13

2013/11/1 Alex Deucher : > > Christian K?nig (7): > drm/radeon: rework and fix reset detection v2 Please note this pull request (above patch) break suspending on my: 01:00.0 VGA compatible controller [0300]: Advanced Micro Devices [AMD] nee ATI Blackcomb [Radeon HD 6900M series] [1002:6720]

[Bug 64810] EGL/Gles/Weston give segfault on RADEONSI with egl_gallium.so

You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20131103/388f2836/attachment.html>

[PATCH 1/2] drm: remove agp_init() bus callback

Hi Daniel On Sun, Nov 3, 2013 at 12:36 PM, Daniel Vetter wrote: > On Sun, Nov 03, 2013 at 12:06:05PM +0100, David Herrmann wrote: >> Hi Dave >> >> This one can also go into 3.13. This and 2/2 provide the agp_init() >> cleanup that Daniel suggested for the drm_dev_*() patches. 2/2 is not >>

[PATCH 1/2] drm: remove agp_init() bus callback

On Sun, Nov 03, 2013 at 12:06:05PM +0100, David Herrmann wrote: > Hi Dave > > This one can also go into 3.13. This and 2/2 provide the agp_init() > cleanup that Daniel suggested for the drm_dev_*() patches. 2/2 is not > required, but I thought it was a nice addition. I have a few more patches to

[Bug 69372] Render issues in some GTK widgets with Mesa 9+ RadeonSI drivers

|| -- 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/20131103/1f3a9ba7/attachment.html>

[Bug 69372] Render issues in some GTK widgets with Mesa 9+ RadeonSI drivers

|| -- 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/20131103/767b772a/attachment.html>

[PATCH 1/2] drm: remove agp_init() bus callback

Hi Dave This one can also go into 3.13. This and 2/2 provide the agp_init() cleanup that Daniel suggested for the drm_dev_*() patches. 2/2 is not required, but I thought it was a nice addition. Thanks David On Sat, Oct 19, 2013 at 1:58 PM, David Herrmann wrote: > The PCI bus helper is the

[PATCH] drm: allow DRM_IOCTL_VERSION on render-nodes

Hi Dave That one should go into 3.13. I'd like to keep drm.rnodes=0 for one more release. OpenCL is reported to be working with this (thanks to Tom), OpenGL isn't working, yet as it relies on flink names. Patches are available to make OpenGL work on rnodes with mesa. Cheers David On Mon, Oct

[Bug 60929] [r600-llvm] mono games with opengl are blocking on start

Git:master/ba209eeef2 DDX: Git:master/f1dc677e79 -- 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/20131103/ae795087/attachment.html>

[Bug 69372] Render issues in some GTK widgets with Mesa 9+ RadeonSI drivers

-- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20131103/717a22a1/attachment.html>

[Bug 41079] xorg-r600: display (sometimes) doesn't get updated or only partially

t part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20131103/8c5e59d1/attachment.html>

[Bug 40986] xorg-r600: graphical glitches on cursor display

t part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20131103/57bc57c0/attachment.html>

[Linaro-mm-sig] thoughts of looking at android fences

op 02-11-13 22:36, Colin Cross schreef: > On Wed, Oct 30, 2013 at 5:17 AM, Maarten Lankhorst > wrote: >> op 24-10-13 14:13, Maarten Lankhorst schreef: >>> So I actually tried to implement it now. I killed all the deprecated >>> members and assumed a linear timeline. >>> This means that

[PATCH 2/2] drm/radeon/kms: add crtc_disable function for legacy crtc

To plug the VRAM memory leak (see previous patch for details) we must unpin the frame buffer when disabling the CRTC. This warrants the addition of disable function for legacy CRTC, which puts the CRTC in DPMS-OFF state and unpins the frame buffer if there is one associated with the CRTC.

[PATCH 1/2] drm/radeon/kms: unpin fb in atombios crtc disable

When drm_helper_disable_unused_functions calls disable function of the CRTC, it also sets the crtc->fb pointer to NULL. This can later (when the mode on that CRTC is setup again from user space) cause ***_do_set_base functions to "think" that there is no old buffer and skip the unpinning code.

plug the VRAM leak in radeon driver

The following patches will plug the VRAM leak that can be provoked in the radeon driver by changing the mode. The mechanism that causes the leak is described in the commit message associated with the first patch. The way I have caused it (and tested the fix) was temporarily hack up debug counters