dri-devel October 2011

dri-devel@lists.freedesktop.org

82 participants
530 discussions

[PATCH] drm: Add KMS debug printk's for encoder and crtc fixup failure
by Adam Jackson 10 Oct '11

10 Oct '11

Signed-off-by: Adam Jackson <ajax(a)redhat.com> --- drivers/gpu/drm/drm_crtc_helper.c | 2 ++ 1 files changed, 2 insertions(+), 0 deletions(-) diff --git a/drivers/gpu/drm/drm_crtc_helper.c b/drivers/gpu/drm/drm_crtc_helper.c index f88a9b2..f236644 100644 --- a/drivers/gpu/drm/drm_crtc_helper.c +++ b/drivers/gpu/drm/drm_crtc_helper.c @@ -372,11 +372,13 @@ bool drm_crtc_helper_set_mode(struct drm_crtc *crtc, encoder_funcs = encoder->helper_private; if (!(ret = encoder_funcs->mode_fixup(encoder, mode, adjusted_mode))) { + DRM_DEBUG_KMS("Encoder fixup failed\n"); goto done; } } if (!(ret = crtc_funcs->mode_fixup(crtc, mode, adjusted_mode))) { + DRM_DEBUG_KMS("CRTC fixup failed\n"); goto done; } DRM_DEBUG_KMS("[CRTC:%d]\n", crtc->base.id); -- 1.7.6.4

1 0

[PATCH] drm/ttm: Pass the buffer object on backend creation
by j.glisse＠gmail.com 10 Oct '11

10 Oct '11

From: Jerome Glisse <jglisse(a)redhat.com> In case of multiple page table for GART, driver want to know which buffer object is being bind/unbind. This allow driver to bind/unbind buffer object from several different GART. Signed-off-by: Jerome Glisse <jglisse(a)redhat.com> --- drivers/gpu/drm/nouveau/nouveau_bo.c | 3 ++- drivers/gpu/drm/radeon/radeon_ttm.c | 11 +++++++---- drivers/gpu/drm/ttm/ttm_bo.c | 4 ++-- drivers/gpu/drm/ttm/ttm_tt.c | 9 ++++++--- drivers/gpu/drm/vmwgfx/vmwgfx_buffer.c | 3 ++- include/drm/ttm/ttm_bo_driver.h | 5 ++++- 6 files changed, 23 insertions(+), 12 deletions(-) diff --git a/drivers/gpu/drm/nouveau/nouveau_bo.c b/drivers/gpu/drm/nouveau/nouveau_bo.c index 890d50e..9f65371 100644 --- a/drivers/gpu/drm/nouveau/nouveau_bo.c +++ b/drivers/gpu/drm/nouveau/nouveau_bo.c @@ -344,7 +344,8 @@ nouveau_bo_wr32(struct nouveau_bo *nvbo, unsigned index, u32 val) } static struct ttm_backend * -nouveau_bo_create_ttm_backend_entry(struct ttm_bo_device *bdev) +nouveau_bo_create_ttm_backend_entry(struct ttm_bo_device *bdev, + struct ttm_buffer_object *bo) { struct drm_nouveau_private *dev_priv = nouveau_bdev(bdev); struct drm_device *dev = dev_priv->dev; diff --git a/drivers/gpu/drm/radeon/radeon_ttm.c b/drivers/gpu/drm/radeon/radeon_ttm.c index 0b5468b..0bad266 100644 --- a/drivers/gpu/drm/radeon/radeon_ttm.c +++ b/drivers/gpu/drm/radeon/radeon_ttm.c @@ -114,10 +114,12 @@ static void radeon_ttm_global_fini(struct radeon_device *rdev) } } -struct ttm_backend *radeon_ttm_backend_create(struct radeon_device *rdev); +struct ttm_backend *radeon_ttm_backend_create(struct radeon_device *rdev, + struct ttm_buffer_object *bo); static struct ttm_backend* -radeon_create_ttm_backend_entry(struct ttm_bo_device *bdev) +radeon_create_ttm_backend_entry(struct ttm_bo_device *bdev, + struct ttm_buffer_object *bo) { struct radeon_device *rdev; @@ -128,7 +130,7 @@ radeon_create_ttm_backend_entry(struct ttm_bo_device *bdev) } else #endif { - return radeon_ttm_backend_create(rdev); + return radeon_ttm_backend_create(rdev, bo); } } @@ -778,7 +780,8 @@ static struct ttm_backend_func radeon_backend_func = { .destroy = &radeon_ttm_backend_destroy, }; -struct ttm_backend *radeon_ttm_backend_create(struct radeon_device *rdev) +struct ttm_backend *radeon_ttm_backend_create(struct radeon_device *rdev, + struct ttm_buffer_object *bo) { struct radeon_ttm_backend *gtt; diff --git a/drivers/gpu/drm/ttm/ttm_bo.c b/drivers/gpu/drm/ttm/ttm_bo.c index ef06194..fe957e7 100644 --- a/drivers/gpu/drm/ttm/ttm_bo.c +++ b/drivers/gpu/drm/ttm/ttm_bo.c @@ -337,13 +337,13 @@ static int ttm_bo_add_ttm(struct ttm_buffer_object *bo, bool zero_alloc) if (zero_alloc) page_flags |= TTM_PAGE_FLAG_ZERO_ALLOC; case ttm_bo_type_kernel: - bo->ttm = ttm_tt_create(bdev, bo->num_pages << PAGE_SHIFT, + bo->ttm = ttm_tt_create(bdev, bo, bo->num_pages << PAGE_SHIFT, page_flags, glob->dummy_read_page); if (unlikely(bo->ttm == NULL)) ret = -ENOMEM; break; case ttm_bo_type_user: - bo->ttm = ttm_tt_create(bdev, bo->num_pages << PAGE_SHIFT, + bo->ttm = ttm_tt_create(bdev, bo, bo->num_pages << PAGE_SHIFT, page_flags | TTM_PAGE_FLAG_USER, glob->dummy_read_page); if (unlikely(bo->ttm == NULL)) { diff --git a/drivers/gpu/drm/ttm/ttm_tt.c b/drivers/gpu/drm/ttm/ttm_tt.c index 58c271e..202e16e 100644 --- a/drivers/gpu/drm/ttm/ttm_tt.c +++ b/drivers/gpu/drm/ttm/ttm_tt.c @@ -379,8 +379,11 @@ int ttm_tt_set_user(struct ttm_tt *ttm, return 0; } -struct ttm_tt *ttm_tt_create(struct ttm_bo_device *bdev, unsigned long size, - uint32_t page_flags, struct page *dummy_read_page) +struct ttm_tt *ttm_tt_create(struct ttm_bo_device *bdev, + struct ttm_buffer_object *bo, + unsigned long size, + uint32_t page_flags, + struct page *dummy_read_page) { struct ttm_bo_driver *bo_driver = bdev->driver; struct ttm_tt *ttm; @@ -407,7 +410,7 @@ struct ttm_tt *ttm_tt_create(struct ttm_bo_device *bdev, unsigned long size, printk(KERN_ERR TTM_PFX "Failed allocating page table\n"); return NULL; } - ttm->be = bo_driver->create_ttm_backend_entry(bdev); + ttm->be = bo_driver->create_ttm_backend_entry(bdev, bo); if (!ttm->be) { ttm_tt_destroy(ttm); printk(KERN_ERR TTM_PFX "Failed creating ttm backend entry\n"); diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_buffer.c b/drivers/gpu/drm/vmwgfx/vmwgfx_buffer.c index 87e43e0..5376285 100644 --- a/drivers/gpu/drm/vmwgfx/vmwgfx_buffer.c +++ b/drivers/gpu/drm/vmwgfx/vmwgfx_buffer.c @@ -159,7 +159,8 @@ static struct ttm_backend_func vmw_ttm_func = { .destroy = vmw_ttm_destroy, }; -struct ttm_backend *vmw_ttm_backend_init(struct ttm_bo_device *bdev) +struct ttm_backend *vmw_ttm_backend_init(struct ttm_bo_device *bdev, + struct ttm_buffer_object *bo) { struct vmw_ttm_backend *vmw_be; diff --git a/include/drm/ttm/ttm_bo_driver.h b/include/drm/ttm/ttm_bo_driver.h index 94eb143..256a8ae 100644 --- a/include/drm/ttm/ttm_bo_driver.h +++ b/include/drm/ttm/ttm_bo_driver.h @@ -354,12 +354,14 @@ struct ttm_bo_driver { * struct ttm_bo_driver member create_ttm_backend_entry * * @bdev: The buffer object device. + * @bo: The buffer object for which this backend is created * * Create a driver specific struct ttm_backend. */ struct ttm_backend *(*create_ttm_backend_entry) - (struct ttm_bo_device *bdev); + (struct ttm_bo_device *bdev, + struct ttm_buffer_object *bo); /** * struct ttm_bo_driver member invalidate_caches @@ -613,6 +615,7 @@ ttm_flag_masked(uint32_t *old, uint32_t new, uint32_t mask) * NULL: Out of memory. */ extern struct ttm_tt *ttm_tt_create(struct ttm_bo_device *bdev, + struct ttm_buffer_object *bo, unsigned long size, uint32_t page_flags, struct page *dummy_read_page); -- 1.7.1

1 0

[PATCH] drm: fix messages about failed procfs/debugfs file registration
by Marcin Slusarz 10 Oct '11

10 Oct '11

It printed garbage from stack: [drm:drm_debugfs_create_files] *ERROR* Cannot create /sys/kernel/debug/dri/!.wy/2 Reported-by: Daniel Yek <danieyek(a)alumni.washington.edu> Signed-off-by: Marcin Slusarz <marcin.slusarz(a)gmail.com> Cc: stable(a)kernel.org --- drivers/gpu/drm/drm_debugfs.c | 3 +-- drivers/gpu/drm/drm_proc.c | 3 +-- 2 files changed, 2 insertions(+), 4 deletions(-) diff --git a/drivers/gpu/drm/drm_debugfs.c b/drivers/gpu/drm/drm_debugfs.c index 9d8c892..b9dc262 100644 --- a/drivers/gpu/drm/drm_debugfs.c +++ b/drivers/gpu/drm/drm_debugfs.c @@ -90,7 +90,6 @@ int drm_debugfs_create_files(struct drm_info_list *files, int count, struct drm_device *dev = minor->dev; struct dentry *ent; struct drm_info_node *tmp; - char name[64]; int i, ret; for (i = 0; i < count; i++) { @@ -109,7 +108,7 @@ int drm_debugfs_create_files(struct drm_info_list *files, int count, root, tmp, &drm_debugfs_fops); if (!ent) { DRM_ERROR("Cannot create /sys/kernel/debug/dri/%s/%s\n", - name, files[i].name); + root->d_name.name, files[i].name); kfree(tmp); ret = -1; goto fail; diff --git a/drivers/gpu/drm/drm_proc.c b/drivers/gpu/drm/drm_proc.c index 9e5b07e..0f3c4e3 100644 --- a/drivers/gpu/drm/drm_proc.c +++ b/drivers/gpu/drm/drm_proc.c @@ -95,7 +95,6 @@ int drm_proc_create_files(struct drm_info_list *files, int count, struct drm_device *dev = minor->dev; struct proc_dir_entry *ent; struct drm_info_node *tmp; - char name[64]; int i, ret; for (i = 0; i < count; i++) { @@ -118,7 +117,7 @@ int drm_proc_create_files(struct drm_info_list *files, int count, &drm_proc_fops, tmp); if (!ent) { DRM_ERROR("Cannot create /proc/dri/%s/%s\n", - name, files[i].name); + root->name, files[i].name); list_del(&tmp->list); kfree(tmp); ret = -1; -- 1.7.6.1

3 4

[PATCH 0/2] RFC: Potential improvements in edid detection timings (v2)
by Eugeni Dodonov 10 Oct '11

10 Oct '11

(Resending with small improvements - also sending to dri-devel for feedback). This is the the forth iteration of potential fixes for slow edid detection issues over non-existent outputs (https://bugs.freedesktop.org/show_bug.cgi?id=41059) - the previous versions were posted to the bug and were used mostly for debugging the problem. The problem I attempted to fix here is that some systems would take a very long time trying to locate all the possible video outputs - in in cases where such outputs were bogus, this lead to timing out after all the possible delays were done. After investigation, I came to think on two different ways to fix the issue: - The first patch does a one-line fix in drm_edid.c. I added a check for the return value of i2c_transfer - and, if it is -ENXIO, we give up on further attempts as the bus is not there. A drawback to this approach is that it affects all the devices out there which use drm_get_edid. From my testing, the -ENXIO gave no false positives, but I haven't tested it on non-Intel cards. So I'd like to hear what other drm developers think about that. - The second patch does a similar procedure within the i915 driver, in case the proposed change to drm_edid.c won't be adequate for other drivers. It adds a new function - intel_drm_get_valid_edid - which attempts to do a simple i2c transfer over the bus prior to calling drm_get_edid. In case such transfer fails with -ENXIO, it is a signal that the bus is not there, so we shouldn't waste any time trying to communicate with it further. Note that those patches provide lots of dmesg pollution - for the final version those printk'ss should probably be removed, but I left them intentionally with KERN_DEBUG in order to see when the adapters come and go during the debugging and testing. According to testing performed at https://bugs.freedesktop.org/show_bug.cgi?id=41059, the following results were obtained with those patches: System1: (testing all possible outputs) ubuntu 3.0.0-12.19: 840ms 3.0.0-12.19 + drm patch: 290ms 3.0.0-12.19 + i915 patch: 290ms (manually ignoring phantom outputs) ubuntu 3.0.0-12.19: 690ms 3.0.0-12.19 + drm patch: 140ms 3.0.0-12.19 + i915 patch: 140ms System2: (testing all possible outputs) ubuntu 3.0.0-12.19: 315ms 3.0.0-12.19 + drm patch: 280ms 3.0.0-12.19 + i915 patch: 280ms (manually ignoring phantom outputs) ubuntu 3.0.0-12.19: 175ms 3.0.0-12.19 + drm patch: 140ms 3.0.0-12.19 + i915 patch: 140ms Eugeni Dodonov (2): Give up on edid retries when i2c tells us that bus is not there Check if the bus is valid prior to discovering edid. drivers/gpu/drm/drm_edid.c | 5 +++++ drivers/gpu/drm/i915/intel_dp.c | 4 ++-- drivers/gpu/drm/i915/intel_drv.h | 2 ++ drivers/gpu/drm/i915/intel_hdmi.c | 4 ++-- drivers/gpu/drm/i915/intel_i2c.c | 33 +++++++++++++++++++++++++++++++++ drivers/gpu/drm/i915/intel_lvds.c | 2 +- drivers/gpu/drm/i915/intel_modes.c | 2 +- drivers/gpu/drm/i915/intel_sdvo.c | 4 ++-- 8 files changed, 48 insertions(+), 8 deletions(-) -- 1.7.6.3

3 4

[PATCH 0/4] vmwgfx: Fence events
by Thomas Hellstrom 10 Oct '11

10 Oct '11

A small patch series that makes it possible to attach drm events for delivery when fence objects signal. This will hopefully be the last changes before the driver is taken out of staging.

1 4

[PATCH 1/2] drm/radeon/kms: bail early in dvi_detect for digital only connectors
by alexdeucher＠gmail.com 10 Oct '11

10 Oct '11

From: Alex Deucher <alexander.deucher(a)amd.com> DVI-D and HDMI-A are digital only, so there's no need to attempt analog load detect. Also, skip bail before the !force check, or we fail to get a disconnect events. The next patches in the series attempt to fix disconnect events for connectors with analog support (DVI-I, HDMI-B, DVI-A). Fixes: https://bugs.freedesktop.org/show_bug.cgi?id=41561 Signed-off-by: Alex Deucher <alexander.deucher(a)amd.com> Cc: stable(a)kernel.org --- drivers/gpu/drm/radeon/radeon_connectors.c | 5 +++++ 1 files changed, 5 insertions(+), 0 deletions(-) diff --git a/drivers/gpu/drm/radeon/radeon_connectors.c b/drivers/gpu/drm/radeon/radeon_connectors.c index 449c3d8..103eb1b 100644 --- a/drivers/gpu/drm/radeon/radeon_connectors.c +++ b/drivers/gpu/drm/radeon/radeon_connectors.c @@ -959,6 +959,11 @@ radeon_dvi_detect(struct drm_connector *connector, bool force) if ((ret == connector_status_connected) && (radeon_connector->use_digital == true)) goto out; + /* DVI-D and HDMI-A are digital only */ + if ((connector->connector_type == DRM_MODE_CONNECTOR_DVID) || + (connector->connector_type == DRM_MODE_CONNECTOR_HDMIA)) + goto out; + if (!force) { ret = connector->status; goto out; -- 1.7.1.1

2 2

[PATCH] vgaarb: a NULL bridge is acceptable for root devices.
by Dave Airlie 10 Oct '11

10 Oct '11

From: Dave Airlie <airlied(a)redhat.com> I assumed all PCI buses had a bridge, but playing with qemu recently, I discovered vgaarb bug where it wasn't detecting both devices shared a bridge at the root level. Don't check for NULL, if two buses have a NULL bridge, assume the share the root bus. Signed-off-by: Dave Airlie <airlied(a)redhat.com> --- drivers/gpu/vga/vgaarb.c | 44 +++++++++++++++++++++----------------------- 1 files changed, 21 insertions(+), 23 deletions(-) diff --git a/drivers/gpu/vga/vgaarb.c b/drivers/gpu/vga/vgaarb.c index c72f1c0..bdde899 100644 --- a/drivers/gpu/vga/vgaarb.c +++ b/drivers/gpu/vga/vgaarb.c @@ -465,31 +465,29 @@ static void vga_arbiter_check_bridge_sharing(struct vga_device *vgadev) while (new_bus) { new_bridge = new_bus->self; - if (new_bridge) { - /* go through list of devices already registered */ - list_for_each_entry(same_bridge_vgadev, &vga_list, list) { - bus = same_bridge_vgadev->pdev->bus; - bridge = bus->self; - - /* see if the share a bridge with this device */ - if (new_bridge == bridge) { - /* if their direct parent bridge is the same - as any bridge of this device then it can't be used - for that device */ - same_bridge_vgadev->bridge_has_one_vga = false; - } + /* go through list of devices already registered */ + list_for_each_entry(same_bridge_vgadev, &vga_list, list) { + bus = same_bridge_vgadev->pdev->bus; + bridge = bus->self; + + /* see if the share a bridge with this device */ + if (new_bridge == bridge) { + /* if their direct parent bridge is the same + as any bridge of this device then it can't be used + for that device */ + same_bridge_vgadev->bridge_has_one_vga = false; + } - /* now iterate the previous devices bridge hierarchy */ - /* if the new devices parent bridge is in the other devices - hierarchy then we can't use it to control this device */ - while (bus) { - bridge = bus->self; - if (bridge) { - if (bridge == vgadev->pdev->bus->self) - vgadev->bridge_has_one_vga = false; - } - bus = bus->parent; + /* now iterate the previous devices bridge hierarchy */ + /* if the new devices parent bridge is in the other devices + hierarchy then we can't use it to control this device */ + while (bus) { + bridge = bus->self; + if (bridge) { + if (bridge == vgadev->pdev->bus->self) + vgadev->bridge_has_one_vga = false; } + bus = bus->parent; } } new_bus = new_bus->parent; -- 1.7.6

1 0

[Bug 41613] New: [r300g] Latest Mesa breaks Wine - "Bad vertex format"
by bugzilla-daemon＠freedesktop.org 09 Oct '11

09 Oct '11

https://bugs.freedesktop.org/show_bug.cgi?id=41613 Summary: [r300g] Latest Mesa breaks Wine - "Bad vertex format" Product: Mesa Version: git Platform: x86 (IA32) OS/Version: Linux (All) Status: NEW Severity: major Priority: medium Component: Drivers/Gallium/r300 AssignedTo: dri-devel(a)lists.freedesktop.org ReportedBy: rankincj(a)googlemail.com Trying to run Wine against the latest Mesa causes this error message: r300: Bad vertex format r32g32b32a32_sint. err:module:attach_process_dlls "opengl32.dll" failed to initialize, aborting err:module:LdrInitializeThunk Main exe initialization for L"H:\\World of Warcraft\\Wow.exe" failed, status 80000101 The following commit seems to be responsible: commit 4e28e6f6c777841b9ffe7a7ad1e865e2595f70f9 Author: Dave Airlie <airlied(a)redhat.com> Date: Mon Sep 26 19:05:18 2011 +0100 u_blitter: add integer clear support We need add a new set of fragment shader variants, along with new vertex elements for signed and unsigned clears. The new fragment shader variants are due to the integers values requiring CONSTANT interpolation. The new vertex element descriptions are for passing the clear color as an unsigned or signed integer value. Signed-off-by: Dave Airlie <airlied(a)redhat.com> -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug.

1 4

[git pull] drm fixes
by Dave Airlie 08 Oct '11

08 Oct '11

Hi Linus, just some more fixes from Alex for various displayport and llano output setup on radeon. Dave. The following changes since commit 976d167615b64e14bc1491ca51d424e2ba9a5e84: Linux 3.1-rc9 (2011-10-04 18:11:50 -0700) are available in the git repository at: git://people.freedesktop.org/~airlied/linux.git drm-fixes Alex Deucher (3): drm/radeon/kms: retry aux transactions if there are status flags drm/radeon/kms: fix dp_detect handling for DP bridge chips drm/radeon/kms: use hardcoded dig encoder to transmitter mapping for DCE4.1 drivers/gpu/drm/radeon/atombios_dp.c | 12 +++++++++--- drivers/gpu/drm/radeon/radeon_connectors.c | 21 ++++++--------------- drivers/gpu/drm/radeon/radeon_encoders.c | 9 ++++++--- 3 files changed, 21 insertions(+), 21 deletions(-)

1 0

[Bug 40252] New: No udev event for disconnecting VGA/HDMI cable
by bugzilla-daemon＠freedesktop.org 07 Oct '11

07 Oct '11

https://bugs.freedesktop.org/show_bug.cgi?id=40252 Summary: No udev event for disconnecting VGA/HDMI cable Product: DRI Version: XOrg CVS Platform: x86-64 (AMD64) OS/Version: Linux (All) Status: NEW Severity: normal Priority: medium Component: DRM/Radeon AssignedTo: dri-devel(a)lists.freedesktop.org ReportedBy: qjn(a)gmx.de Created an attachment (id=50402) --> (https://bugs.freedesktop.org/attachment.cgi?id=50402) Xorg.0.log Hi, I have an AMD Radeon HD 6310 with free radeon drivers running. Xorg version is 7.6, xserver is 1.10.3. I tried to define a udev rule to change my monitor settings automatically when I connect a VGA or an HDMI cable. Connecting works fine but disconnecting is not recognized. udevadm monitor shows: udevadm monitor monitor will print the received events for: UDEV - the event which udev sends out after rule processing KERNEL - the kernel uevent KERNEL[100.176249] change /devices/pci0000:00/0000:00:01.0/drm/card0 (drm) UDEV [100.869104] change /devices/pci0000:00/0000:00:01.0/drm/card0 (drm) for connecting. For disconnecting nothing happens. I hope this is the right place to file this as a bug. Every help is appreciated! Regards Dirk -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug.

1 6

← Newer
1
...
45
46
47
48
49
50
51
52
53
Older →

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

dri-devel October 2011