dri-devel May 2012

dri-devel@lists.freedesktop.org

115 participants
737 discussions

Include request for reset-rework branch v2
by j.glisse＠gmail.com 02 May '12

02 May '12

So it's pretty much the same patchset except for patch 7 (use mutex instead of spinlock) and 9 & 10 which correspond to previous patch 9 split in two and the sa allocation being simplified. The patchset can be found at : http://people.freedesktop.org/~glisse/reset/ Cheers, Jerome Glisse

3 29

[PATCH] cdv: Fix typos in initialization of mdfld_chip_ops
by Patrik Jakobsson 01 May '12

01 May '12

Signed-off-by: Patrik Jakobsson <patrik.r.jakobsson(a)gmail.com> --- drivers/gpu/drm/gma500/mdfld_device.c | 4 ++-- 1 files changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/gpu/drm/gma500/mdfld_device.c b/drivers/gpu/drm/gma500/mdfld_device.c index a0bd48c..717f4db 100644 --- a/drivers/gpu/drm/gma500/mdfld_device.c +++ b/drivers/gpu/drm/gma500/mdfld_device.c @@ -672,8 +672,8 @@ const struct psb_ops mdfld_chip_ops = { .accel_2d = 0, .pipes = 3, .crtcs = 3, - .lvds_mask = (1 << 1); - .hdmi_mask = (1 << 1); + .lvds_mask = (1 << 1), + .hdmi_mask = (1 << 1), .sgx_offset = MRST_SGX_OFFSET, .chip_setup = mid_chip_setup, -- 1.7.5.4

2 1

[Bug 26891] Radeon KMS on Macs with EFI boot
by bugzilla-daemon＠freedesktop.org 01 May '12

01 May '12

https://bugs.freedesktop.org/show_bug.cgi?id=26891 --- Comment #21 from headwall <hedvall(a)gmail.com> 2012-05-01 10:24:20 PDT --- I'm on a Mac Pro 1,1 with the original ATI X1900XT card, and had similar problems booting via EFI. After the modesetting was initialized the screen went blank, but the computer completed booting. Therefore, I applied the patch, which made the kernel boot absolutely fine. When I want to start X however, the picture gets distorted. No errors or warnings are shown in the Xorg log file. Starting X with BIOS boot works absolutely fine with the same install. One thing I've no noticed is that the kernel doesn't reserve the memory space for the video ROM (0x000c0000-0x000cffff) in EFI boot as it does in BIOS mode. I've tried to write a DSDT patch for this to reserve the area, without success. I suspect that the ATI drivers (xf86-video-ati) tries to read the video ROM both from the kernel, that was placed there through the patch, and from the memory range, which is not there in EFI boot. I run a Gentoo install with Grub2 boot, 3.3 vanilla kernel, Xorg-server 1.12 and xf86-video-ati compiled from GIT. -- 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

[PATCH] drm/kms: reduce some messages to debug level
by Dave Airlie 01 May '12

01 May '12

From: Dave Airlie <airlied(a)redhat.com> These can all be trigged from userspace if you pass the right values. Signed-off-by: Dave Airlie <airlied(a)redhat.com> --- drivers/gpu/drm/drm_crtc.c | 10 +++++----- 1 files changed, 5 insertions(+), 5 deletions(-) diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c index 5e818a8..597d309 100644 --- a/drivers/gpu/drm/drm_crtc.c +++ b/drivers/gpu/drm/drm_crtc.c @@ -2062,7 +2062,7 @@ int drm_mode_addfb(struct drm_device *dev, fb = dev->mode_config.funcs->fb_create(dev, file_priv, &r); if (IS_ERR(fb)) { - DRM_ERROR("could not create framebuffer\n"); + DRM_DEBUG_KMS("could not create framebuffer\n"); ret = PTR_ERR(fb); goto out; } @@ -2174,19 +2174,19 @@ int drm_mode_addfb2(struct drm_device *dev, return -EINVAL; if ((config->min_width > r->width) || (r->width > config->max_width)) { - DRM_ERROR("bad framebuffer width %d, should be >= %d && <= %d\n", + DRM_DEBUG_KMS("bad framebuffer width %d, should be >= %d && <= %d\n", r->width, config->min_width, config->max_width); return -EINVAL; } if ((config->min_height > r->height) || (r->height > config->max_height)) { - DRM_ERROR("bad framebuffer height %d, should be >= %d && <= %d\n", + DRM_DEBUG_KMS("bad framebuffer height %d, should be >= %d && <= %d\n", r->height, config->min_height, config->max_height); return -EINVAL; } ret = format_check(r); if (ret) { - DRM_ERROR("bad framebuffer format 0x%08x\n", r->pixel_format); + DRM_DEBUG_KMS("bad framebuffer format 0x%08x\n", r->pixel_format); return ret; } @@ -2194,7 +2194,7 @@ int drm_mode_addfb2(struct drm_device *dev, fb = dev->mode_config.funcs->fb_create(dev, file_priv, r); if (IS_ERR(fb)) { - DRM_ERROR("could not create framebuffer\n"); + DRM_DEBUG_KMS("could not create framebuffer\n"); ret = PTR_ERR(fb); goto out; } -- 1.7.7.6

2 1

[PATCH] drm: pass dev to drm_vm_{open,close}_locked()
by Rob Clark 01 May '12

01 May '12

From: Rob Clark <rob(a)ti.com> Previously these functions would assume that vma->vm_file was the drm_file. Although if in some cases if the drm driver needs to use something else for the backing file (such as the tmpfs filp) then this assumption is no longer true. But vma->vm_private_data is still the GEM object. With this change, now the drm_device comes from the GEM object rather than the drm_file so the driver is more free to play with vma->vm_file. The scenario where this comes up is for mmap'ing of cached dmabuf's for non-coherent systems, where the driver needs to use fault handling and PTE shootdown to simulate coherency. We can't use the vma->vm_file of the dmabuf, which is using anon_inode's address_space. The most straightforward thing to do is to use the GEM object's obj->filp for vma->vm_file in all cases, for which we need this patch. Signed-off-by: Rob Clark <rob(a)ti.com> --- drivers/gpu/drm/drm_gem.c | 6 +++--- drivers/gpu/drm/drm_vm.c | 18 ++++++++---------- include/drm/drmP.h | 4 ++-- 3 files changed, 13 insertions(+), 15 deletions(-) diff --git a/drivers/gpu/drm/drm_gem.c b/drivers/gpu/drm/drm_gem.c index 83114b5..475b300 100644 --- a/drivers/gpu/drm/drm_gem.c +++ b/drivers/gpu/drm/drm_gem.c @@ -628,7 +628,7 @@ void drm_gem_vm_open(struct vm_area_struct *vma) drm_gem_object_reference(obj); mutex_lock(&obj->dev->struct_mutex); - drm_vm_open_locked(vma); + drm_vm_open_locked(obj->dev, vma); mutex_unlock(&obj->dev->struct_mutex); } EXPORT_SYMBOL(drm_gem_vm_open); @@ -639,7 +639,7 @@ void drm_gem_vm_close(struct vm_area_struct *vma) struct drm_device *dev = obj->dev; mutex_lock(&dev->struct_mutex); - drm_vm_close_locked(vma); + drm_vm_close_locked(obj->dev, vma); drm_gem_object_unreference(obj); mutex_unlock(&dev->struct_mutex); } @@ -712,7 +712,7 @@ int drm_gem_mmap(struct file *filp, struct vm_area_struct *vma) */ drm_gem_object_reference(obj); - drm_vm_open_locked(vma); + drm_vm_open_locked(dev, vma); out_unlock: mutex_unlock(&dev->struct_mutex); diff --git a/drivers/gpu/drm/drm_vm.c b/drivers/gpu/drm/drm_vm.c index 1495618..961ee08 100644 --- a/drivers/gpu/drm/drm_vm.c +++ b/drivers/gpu/drm/drm_vm.c @@ -406,10 +406,9 @@ static const struct vm_operations_struct drm_vm_sg_ops = { * Create a new drm_vma_entry structure as the \p vma private data entry and * add it to drm_device::vmalist. */ -void drm_vm_open_locked(struct vm_area_struct *vma) +void drm_vm_open_locked(struct drm_device *dev, + struct vm_area_struct *vma) { - struct drm_file *priv = vma->vm_file->private_data; - struct drm_device *dev = priv->minor->dev; struct drm_vma_entry *vma_entry; DRM_DEBUG("0x%08lx,0x%08lx\n", @@ -430,14 +429,13 @@ static void drm_vm_open(struct vm_area_struct *vma) struct drm_device *dev = priv->minor->dev; mutex_lock(&dev->struct_mutex); - drm_vm_open_locked(vma); + drm_vm_open_locked(dev, vma); mutex_unlock(&dev->struct_mutex); } -void drm_vm_close_locked(struct vm_area_struct *vma) +void drm_vm_close_locked(struct drm_device *dev, + struct vm_area_struct *vma) { - struct drm_file *priv = vma->vm_file->private_data; - struct drm_device *dev = priv->minor->dev; struct drm_vma_entry *pt, *temp; DRM_DEBUG("0x%08lx,0x%08lx\n", @@ -467,7 +465,7 @@ static void drm_vm_close(struct vm_area_struct *vma) struct drm_device *dev = priv->minor->dev; mutex_lock(&dev->struct_mutex); - drm_vm_close_locked(vma); + drm_vm_close_locked(dev, vma); mutex_unlock(&dev->struct_mutex); } @@ -519,7 +517,7 @@ static int drm_mmap_dma(struct file *filp, struct vm_area_struct *vma) vma->vm_flags |= VM_RESERVED; /* Don't swap */ vma->vm_flags |= VM_DONTEXPAND; - drm_vm_open_locked(vma); + drm_vm_open_locked(dev, vma); return 0; } @@ -670,7 +668,7 @@ int drm_mmap_locked(struct file *filp, struct vm_area_struct *vma) vma->vm_flags |= VM_RESERVED; /* Don't swap */ vma->vm_flags |= VM_DONTEXPAND; - drm_vm_open_locked(vma); + drm_vm_open_locked(dev, vma); return 0; } diff --git a/include/drm/drmP.h b/include/drm/drmP.h index dd73104..213a85a 100644 --- a/include/drm/drmP.h +++ b/include/drm/drmP.h @@ -1309,8 +1309,8 @@ extern int drm_release(struct inode *inode, struct file *filp); /* Mapping support (drm_vm.h) */ extern int drm_mmap(struct file *filp, struct vm_area_struct *vma); extern int drm_mmap_locked(struct file *filp, struct vm_area_struct *vma); -extern void drm_vm_open_locked(struct vm_area_struct *vma); -extern void drm_vm_close_locked(struct vm_area_struct *vma); +extern void drm_vm_open_locked(struct drm_device *dev, struct vm_area_struct *vma); +extern void drm_vm_close_locked(struct drm_device *dev, struct vm_area_struct *vma); extern unsigned int drm_poll(struct file *filp, struct poll_table_struct *wait); /* Memory management support (drm_memory.h) */ -- 1.7.9.5

1 0

Include request for reset-rework branch.
by Christian König 01 May '12

01 May '12

Hi Dave, if nobody has a last moment concern please include the following patches in drm-next. Except for some minor fixes they have already been on the list for quite some time, but I intentional left out the debugfs related patches cause we haven't finished the discussion about them yet. If you prefer to merge them directly, I also made them available as reset-rework branch here: git://people.freedesktop.org/~deathsimple/linux Cheers, Christian.

3 37

[next][PATCH 0/3] radeon HDMI: next minor improvements
by Rafał Miłecki 01 May '12

01 May '12

This is one more patchset bringing minor improvements to the current HDMI implementation. I think after this step I'll start working on moving Evergreen HDMI code to the separated file. Some cleanups and making ACR re-usable were needed before that. Patches depend on the earlier 5-patches-set I sent yesterday. Again, tested on RV620 and HD6320. Unfortunately I don't have DCE32 card or sth to test code in r600_hdmi_enable/r600_hdmi_disable (pre DCE3). P.S. I'm leaving civilization for the rest of this week. Rafał Miłecki (3): drm/radeon/kms/hdmi: enable audio packets at one place drm/radeon/kms/hdmi: clean&improve handling HDMI mode drm/radeon/kms/hdmi: helper getting ready ACR entry drivers/gpu/drm/radeon/r600_hdmi.c | 129 +++++++++++++++++++---------------- drivers/gpu/drm/radeon/radeon.h | 14 ++++ 2 files changed, 84 insertions(+), 59 deletions(-) -- 1.7.7

2 4

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

dri-devel May 2012