dri-devel March 2011

dri-devel@lists.freedesktop.org

88 participants
477 discussions

[Bug 16140] [RADEON:KMS:RV250:RESUME] suspend to RAM resume broken
by bugzilla-daemon＠bugzilla.kernel.org 22 Mar '11

22 Mar '11

https://bugzilla.kernel.org/show_bug.cgi?id=16140 Robert de Rooy <robert.de.rooy(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |robert.de.rooy(a)gmail.com --- Comment #43 from Robert de Rooy <robert.de.rooy(a)gmail.com> 2011-03-22 08:38:35 --- This same bug is also reported against Fedora; https://bugzilla.redhat.com/show_bug.cgi?id=531825 There it was determined that it is not necessary to completely disable AGP, but that dropping from AGP 4X to AGP 1X is sufficient to let the system resume. In other words, boot with: radeon.agpmode=1 There is though a serious performance penalty with doing so with certain applications (games) that copy around large textures. -- Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are watching the assignee of the bug. ------------------------------------------------------------------------------ Enable your software for Intel(R) Active Management Technology to meet the growing manageability and security demands of your customers. Businesses are taking advantage of Intel(R) vPro (TM) technology - will your software be a part of the solution? Download the Intel(R) Manageability Checker today! http://p.sf.net/sfu/intel-dev2devmar -- _______________________________________________ Dri-devel mailing list Dri-devel(a)lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel

1 0

Re: Linux 2.6.38-rc6
by Linus Torvalds 22 Mar '11

22 Mar '11

On Tue, Feb 22, 2011 at 9:42 PM, Anca Emanuel <anca.emanuel(a)gmail.com> wrote: > General protection fault: > http://i.imgur.com/TBJ6y.jpg > > dmesg: http://pastebin.com/qD8pR8QH > config: http://pastebin.com/XEurtHWi That's drivers/video/fbmem.c: fb_release(), and the "Code:" disassembly shows that it is 1b: e8 f7 c0 29 00 callq xyz 20: 48 8b 93 b8 03 00 00 mov 0x3b8(%rbx),%rdx 27:* 48 8b 42 10 mov 0x10(%rdx),%rax <-- trapping instruction which corresponds to mutex_lock(&info->lock); if (info->fbops->fb_release) info->fbops->fb_release(info,1); so it looks like 'info->fbops' is invalid. It's in %rdx, and is 0x00d000ae00b500c2, which is definitely not a valid pointer. Looks like some bad corruption (looks like a sequence of 16-bit numbers, but it could be anything). Looks like nouveafb took over from vesafb. Did you do anything special to trigger this? Also, you do seem to have some extra patches (yama at the least). Anything else? Linus

6 12

[PATCH] drm/radeon/kms: prefer legacy pll algo for tv-out
by Alex Deucher 22 Mar '11

22 Mar '11

ntsc seems to work fine with either algo, some pal TVs seem pickier. Fixes: https://bugzilla.kernel.org/show_bug.cgi?id=30832 Signed-off-by: Alex Deucher <alexdeucher(a)gmail.com> Cc: stable(a)kernel.org --- drivers/gpu/drm/radeon/atombios_crtc.c | 6 +++++- 1 files changed, 5 insertions(+), 1 deletions(-) diff --git a/drivers/gpu/drm/radeon/atombios_crtc.c b/drivers/gpu/drm/radeon/atombios_crtc.c index 3cd3234..10e41af 100644 --- a/drivers/gpu/drm/radeon/atombios_crtc.c +++ b/drivers/gpu/drm/radeon/atombios_crtc.c @@ -957,7 +957,11 @@ static void atombios_crtc_set_pll(struct drm_crtc *crtc, struct drm_display_mode /* adjust pixel clock as needed */ adjusted_clock = atombios_adjust_pll(crtc, mode, pll, ss_enabled, &ss); - if (ASIC_IS_AVIVO(rdev)) + if (radeon_encoder->active_device & (ATOM_DEVICE_TV_SUPPORT)) + /* TV seems to prefer the legacy algo on some boards */ + radeon_compute_pll_legacy(pll, adjusted_clock, &pll_clock, &fb_div, &frac_fb_div, + &ref_div, &post_div); + else if (ASIC_IS_AVIVO(rdev)) radeon_compute_pll_avivo(pll, adjusted_clock, &pll_clock, &fb_div, &frac_fb_div, &ref_div, &post_div); else -- 1.7.1.1

1 0

[Bug 34088] New: Update autotools configuration
by bugzilla-daemon＠freedesktop.org 21 Mar '11

21 Mar '11

https://bugs.freedesktop.org/show_bug.cgi?id=34088 Summary: Update autotools configuration Product: DRI Version: XOrg CVS Platform: All OS/Version: All Status: NEW Severity: enhancement Priority: medium Component: libdrm AssignedTo: dri-devel(a)lists.freedesktop.org ReportedBy: jjardon(a)gnome.org Created an attachment (id=43160) --> (https://bugs.freedesktop.org/attachment.cgi?id=43160) Update autotools config Replace some deprecated autoconf macros and use the new libtool I also changed the direction to report bugs -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug.

1 2

[PATCH] drm: check for modesetting on modeset ioctls
by Dave Airlie 21 Mar '11

21 Mar '11

From: Dave Airlie <airlied(a)redhat.com> Noticed this while working on some other things, helps if we check for modeset enabled on modesetting ioctls. Cc: stable(a)kernel.org Signed-off-by: Dave Airlie <airlied(a)redhat.com> --- drivers/gpu/drm/drm_crtc.c | 51 ++++++++++++++++++++++++++++++++++++++++++++ 1 files changed, 51 insertions(+), 0 deletions(-) diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c index 4c95b5f..799e149 100644 --- a/drivers/gpu/drm/drm_crtc.c +++ b/drivers/gpu/drm/drm_crtc.c @@ -1073,6 +1073,9 @@ int drm_mode_getresources(struct drm_device *dev, void *data, uint32_t __user *encoder_id; struct drm_mode_group *mode_group; + if (!drm_core_check_feature(dev, DRIVER_MODESET)) + return -EINVAL; + mutex_lock(&dev->mode_config.mutex); /* @@ -1244,6 +1247,9 @@ int drm_mode_getcrtc(struct drm_device *dev, struct drm_mode_object *obj; int ret = 0; + if (!drm_core_check_feature(dev, DRIVER_MODESET)) + return -EINVAL; + mutex_lock(&dev->mode_config.mutex); obj = drm_mode_object_find(dev, crtc_resp->crtc_id, @@ -1312,6 +1318,9 @@ int drm_mode_getconnector(struct drm_device *dev, void *data, uint64_t __user *prop_values; uint32_t __user *encoder_ptr; + if (!drm_core_check_feature(dev, DRIVER_MODESET)) + return -EINVAL; + memset(&u_mode, 0, sizeof(struct drm_mode_modeinfo)); DRM_DEBUG_KMS("[CONNECTOR:%d:?]\n", out_resp->connector_id); @@ -1431,6 +1440,9 @@ int drm_mode_getencoder(struct drm_device *dev, void *data, struct drm_encoder *encoder; int ret = 0; + if (!drm_core_check_feature(dev, DRIVER_MODESET)) + return -EINVAL; + mutex_lock(&dev->mode_config.mutex); obj = drm_mode_object_find(dev, enc_resp->encoder_id, DRM_MODE_OBJECT_ENCODER); @@ -1486,6 +1498,9 @@ int drm_mode_setcrtc(struct drm_device *dev, void *data, int ret = 0; int i; + if (!drm_core_check_feature(dev, DRIVER_MODESET)) + return -EINVAL; + mutex_lock(&dev->mode_config.mutex); obj = drm_mode_object_find(dev, crtc_req->crtc_id, DRM_MODE_OBJECT_CRTC); @@ -1603,6 +1618,9 @@ int drm_mode_cursor_ioctl(struct drm_device *dev, struct drm_crtc *crtc; int ret = 0; + if (!drm_core_check_feature(dev, DRIVER_MODESET)) + return -EINVAL; + if (!req->flags) { DRM_ERROR("no operation set\n"); return -EINVAL; @@ -1667,6 +1685,9 @@ int drm_mode_addfb(struct drm_device *dev, struct drm_framebuffer *fb; int ret = 0; + if (!drm_core_check_feature(dev, DRIVER_MODESET)) + return -EINVAL; + if ((config->min_width > r->width) || (r->width > config->max_width)) { DRM_ERROR("mode new framebuffer width not within limits\n"); return -EINVAL; @@ -1724,6 +1745,9 @@ int drm_mode_rmfb(struct drm_device *dev, int ret = 0; int found = 0; + if (!drm_core_check_feature(dev, DRIVER_MODESET)) + return -EINVAL; + mutex_lock(&dev->mode_config.mutex); obj = drm_mode_object_find(dev, *id, DRM_MODE_OBJECT_FB); /* TODO check that we realy get a framebuffer back. */ @@ -1780,6 +1804,9 @@ int drm_mode_getfb(struct drm_device *dev, struct drm_framebuffer *fb; int ret = 0; + if (!drm_core_check_feature(dev, DRIVER_MODESET)) + return -EINVAL; + mutex_lock(&dev->mode_config.mutex); obj = drm_mode_object_find(dev, r->fb_id, DRM_MODE_OBJECT_FB); if (!obj) { @@ -1813,6 +1840,9 @@ int drm_mode_dirtyfb_ioctl(struct drm_device *dev, int num_clips; int ret = 0; + if (!drm_core_check_feature(dev, DRIVER_MODESET)) + return -EINVAL; + mutex_lock(&dev->mode_config.mutex); obj = drm_mode_object_find(dev, r->fb_id, DRM_MODE_OBJECT_FB); if (!obj) { @@ -1996,6 +2026,9 @@ int drm_mode_attachmode_ioctl(struct drm_device *dev, struct drm_mode_modeinfo *umode = &mode_cmd->mode; int ret = 0; + if (!drm_core_check_feature(dev, DRIVER_MODESET)) + return -EINVAL; + mutex_lock(&dev->mode_config.mutex); obj = drm_mode_object_find(dev, mode_cmd->connector_id, DRM_MODE_OBJECT_CONNECTOR); @@ -2042,6 +2075,9 @@ int drm_mode_detachmode_ioctl(struct drm_device *dev, struct drm_mode_modeinfo *umode = &mode_cmd->mode; int ret = 0; + if (!drm_core_check_feature(dev, DRIVER_MODESET)) + return -EINVAL; + mutex_lock(&dev->mode_config.mutex); obj = drm_mode_object_find(dev, mode_cmd->connector_id, DRM_MODE_OBJECT_CONNECTOR); @@ -2211,6 +2247,9 @@ int drm_mode_getproperty_ioctl(struct drm_device *dev, uint64_t __user *values_ptr; uint32_t __user *blob_length_ptr; + if (!drm_core_check_feature(dev, DRIVER_MODESET)) + return -EINVAL; + mutex_lock(&dev->mode_config.mutex); obj = drm_mode_object_find(dev, out_resp->prop_id, DRM_MODE_OBJECT_PROPERTY); if (!obj) { @@ -2333,6 +2372,9 @@ int drm_mode_getblob_ioctl(struct drm_device *dev, int ret = 0; void *blob_ptr; + if (!drm_core_check_feature(dev, DRIVER_MODESET)) + return -EINVAL; + mutex_lock(&dev->mode_config.mutex); obj = drm_mode_object_find(dev, out_resp->blob_id, DRM_MODE_OBJECT_BLOB); if (!obj) { @@ -2393,6 +2435,9 @@ int drm_mode_connector_property_set_ioctl(struct drm_device *dev, int ret = -EINVAL; int i; + if (!drm_core_check_feature(dev, DRIVER_MODESET)) + return -EINVAL; + mutex_lock(&dev->mode_config.mutex); obj = drm_mode_object_find(dev, out_resp->connector_id, DRM_MODE_OBJECT_CONNECTOR); @@ -2509,6 +2554,9 @@ int drm_mode_gamma_set_ioctl(struct drm_device *dev, int size; int ret = 0; + if (!drm_core_check_feature(dev, DRIVER_MODESET)) + return -EINVAL; + mutex_lock(&dev->mode_config.mutex); obj = drm_mode_object_find(dev, crtc_lut->crtc_id, DRM_MODE_OBJECT_CRTC); if (!obj) { @@ -2560,6 +2608,9 @@ int drm_mode_gamma_get_ioctl(struct drm_device *dev, int size; int ret = 0; + if (!drm_core_check_feature(dev, DRIVER_MODESET)) + return -EINVAL; + mutex_lock(&dev->mode_config.mutex); obj = drm_mode_object_find(dev, crtc_lut->crtc_id, DRM_MODE_OBJECT_CRTC); if (!obj) { -- 1.7.1

2 1

[Bug 27314] displayport link training fails on certain panels (channel equalization fails)
by bugzilla-daemon＠freedesktop.org 21 Mar '11

21 Mar '11

https://bugs.freedesktop.org/show_bug.cgi?id=27314 Alex Deucher <agd5f(a)yahoo.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |ihatewindowsxp(a)gmail.com --- Comment #34 from Alex Deucher <agd5f(a)yahoo.com> 2011-03-20 22:17:23 PDT --- *** Bug 35479 has been marked as a duplicate of this bug. *** -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug.

1 0

[Bug 31412] radeon memory leak
by bugzilla-daemon＠bugzilla.kernel.org 20 Mar '11

20 Mar '11

https://bugzilla.kernel.org/show_bug.cgi?id=31412 --- Comment #12 from Kevin <kjslag(a)gmail.com> 2011-03-20 20:40:48 --- Created an attachment (id=51402) --> (https://bugzilla.kernel.org/attachment.cgi?id=51402) slabinfo after echo 3 > /proc/sys/vm/drop_caches -- Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are watching the assignee of the bug. ------------------------------------------------------------------------------ Colocation vs. Managed Hosting A question and answer guide to determining the best fit for your organization - today and in the future. http://p.sf.net/sfu/internap-sfd2d -- _______________________________________________ Dri-devel mailing list Dri-devel(a)lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel

1 0

[Bug 31412] radeon memory leak
by bugzilla-daemon＠bugzilla.kernel.org 20 Mar '11

20 Mar '11

https://bugzilla.kernel.org/show_bug.cgi?id=31412 --- Comment #11 from Kevin <kjslag(a)gmail.com> 2011-03-20 20:40:18 --- Created an attachment (id=51392) --> (https://bugzilla.kernel.org/attachment.cgi?id=51392) slabinfo before echo 3 > /proc/sys/vm/drop_caches -- Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are watching the assignee of the bug. ------------------------------------------------------------------------------ Colocation vs. Managed Hosting A question and answer guide to determining the best fit for your organization - today and in the future. http://p.sf.net/sfu/internap-sfd2d -- _______________________________________________ Dri-devel mailing list Dri-devel(a)lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel

1 0

[Bug 31412] radeon memory leak
by bugzilla-daemon＠bugzilla.kernel.org 20 Mar '11

20 Mar '11

https://bugzilla.kernel.org/show_bug.cgi?id=31412 --- Comment #10 from Kevin <kjslag(a)gmail.com> 2011-03-20 20:40:04 --- echo 3 > /proc/sys/vm/drop_caches cleared all of the memory. Thank you! See output below (ran after exiting X). I didn't try unloading the gpu stack. I can try it if you like. I also saved /proc/slabinfo before and after I dropped the caches. If I'm interpreting the file correctly, I only notice large drops in ext4 filesystem stuff. Is there a way to tell which slabs are considered buffers or cache? # free -m total used free shared buffers cached Mem: 5920 4318 1602 0 113 2465 -/+ buffers/cache: 1740 4180 Swap: 7998 0 7998 # echo 3 > /proc/sys/vm/drop_caches # free -m total used free shared buffers cached Mem: 5920 225 5695 0 3 12 -/+ buffers/cache: 209 5711 Swap: 7998 0 7998 -- Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are watching the assignee of the bug. ------------------------------------------------------------------------------ Colocation vs. Managed Hosting A question and answer guide to determining the best fit for your organization - today and in the future. http://p.sf.net/sfu/internap-sfd2d -- _______________________________________________ Dri-devel mailing list Dri-devel(a)lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel

1 0

[PATCH] libdrm: vblank wait on crtc > 1
by Ilija Hadzic 20 Mar '11

20 Mar '11

Hi Alex, Below is a patch against the master branch of libdrm that adds support for waits for vblank events on CRTCs that are greater than 1 (and thus cannot be represented using current primary/secondary flags interface). The patch adds a new DRM_CAP so that the application can check whether the new vblank interface is supported and also adds the new DRM_VBLANK mask and shift value so that the application can construct vblank_wait ioctls that refer to crtc > 1 The issue was discussed on the dri-devel list in these two threads http://lists.freedesktop.org/archives/dri-devel/2011-March/009009.html http://lists.freedesktop.org/archives/dri-devel/2011-March/009025.html Regards, Ilija Reviewed-by: Mario Kleiner <mario.kleiner at tuebingen.mpg.de> Acked-by: Mario Kleiner <mario.kleiner at tuebingen.mpg.de> diff --git a/include/drm/drm.h b/include/drm/drm.h index 416673a..10afaf1 100644 --- a/include/drm/drm.h +++ b/include/drm/drm.h @@ -755,6 +755,7 @@ struct drm_event_vblank { }; #define DRM_CAP_DUMB_BUFFER 0x1 +#define DRM_CAP_HIGH_CRTC 0x2 /* typedef area */ typedef struct drm_clip_rect drm_clip_rect_t; diff --git a/xf86drm.h b/xf86drm.h index bf0d5df..e2bea06 100644 --- a/xf86drm.h +++ b/xf86drm.h @@ -302,6 +302,8 @@ typedef enum { DRM_VBLANK_SECONDARY = 0x20000000, /**< Secondary display controller */ DRM_VBLANK_SIGNAL = 0x40000000 /* Send signal instead of blocking */ } drmVBlankSeqType; +#define DRM_VBLANK_HIGH_CRTC_SHIFT 16 +#define DRM_VBLANK_HIGH_CRTC_MASK 0x001F0000 typedef struct _drmVBlankReq { drmVBlankSeqType type;

2 2

← Newer
1
...
26
27
28
29
30
31
32
...
48
Older →

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

dri-devel March 2011