dri-devel May 2012

dri-devel@lists.freedesktop.org

115 participants
737 discussions

[Bug 43215] New: Nouveau: Resume from s2disk fails.
by bugzilla-daemon＠bugzilla.kernel.org 08 May '12

08 May '12

https://bugzilla.kernel.org/show_bug.cgi?id=43215 Summary: Nouveau: Resume from s2disk fails. Product: Drivers Version: 2.5 Kernel Version: 3.3.5, 3.4-rc4+, 3.4-rc6+ Platform: All OS/Version: Linux Tree: Mainline Status: NEW Severity: normal Priority: P1 Component: Video(DRI - non Intel) AssignedTo: drivers_video-dri(a)kernel-bugs.osdl.org ReportedBy: harn-solo(a)gmx.de Regression: No Created an attachment (id=73220) --> (https://bugzilla.kernel.org/attachment.cgi?id=73220) dmesg output of a cold boot -> suspend to disk > resume cycle When sending the PC into suspend to disk mode via echo disk > /sys/power/state or using pm-suspend the resume process fails with the following messages: [ 61.782648] [drm] nouveau 0000:01:00.0: timeout: URSOR_CTRL2_STATUS_ACTIVE(0) [ 61.782709] [drm] nouveau 0000:01:00.0: CURSOR_CTRL2(0) = 0x00000000 This bug is reproducible on several 3.3.x and 3.4-rc kernels. I did not test it on prior kernels. Suspend to RAM works fine. The card used here is a nvce, Gainward 560 Ti, 2G video ram. -- Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are watching the assignee of the bug.

1 0

[Bug 42490] NUTMEG DP to VGA bridge not working
by bugzilla-daemon＠freedesktop.org 08 May '12

08 May '12

https://bugs.freedesktop.org/show_bug.cgi?id=42490 --- Comment #29 from diego.abelenda(a)gmail.com 2012-05-07 23:54:17 PDT --- Well considering the commit pointed is exactly the patch proposed in comment 14 ( https://bugs.freedesktop.org/attachment.cgi?id=60707 ) it is pretty clear that it doesn't do anything for me. That's why I didn't react at all when the inclusion was advertised. -- 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 1/3] acpi_video: fix leaking PCI references
by Alan Cox 08 May '12

08 May '12

From: Alan Cox <alan(a)linux.intel.com> Signed-off-by: Alan Cox <alan(a)linux.intel.com> --- drivers/acpi/video.c | 5 +++-- 1 files changed, 3 insertions(+), 2 deletions(-) diff --git a/drivers/acpi/video.c b/drivers/acpi/video.c index 9577b6f..66e8f73 100644 --- a/drivers/acpi/video.c +++ b/drivers/acpi/video.c @@ -1745,6 +1745,7 @@ static int acpi_video_bus_remove(struct acpi_device *device, int type) static int __init intel_opregion_present(void) { + int i915 = 0; #if defined(CONFIG_DRM_I915) || defined(CONFIG_DRM_I915_MODULE) struct pci_dev *dev = NULL; u32 address; @@ -1757,10 +1758,10 @@ static int __init intel_opregion_present(void) pci_read_config_dword(dev, 0xfc, &address); if (!address) continue; - return 1; + i915 = 1; } #endif - return 0; + return i915; } int acpi_video_register(void)

3 4

[Bug 42490] NUTMEG DP to VGA bridge not working
by bugzilla-daemon＠freedesktop.org 07 May '12

07 May '12

https://bugs.freedesktop.org/show_bug.cgi?id=42490 --- Comment #28 from Jerome Glisse <glisse(a)freedesktop.org> 2012-05-07 12:57:34 PDT --- Does people here have better luck with the patch mentioned previously: drm/radeon/kms: need to set up ss on DP bridges as well -- 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

[RFC][PATCH] drm/radeon/hdmi: define struct for AVI infoframe
by Rafał Miłecki 07 May '12

07 May '12

--- drivers/gpu/drm/radeon/r600_hdmi.c | 81 ++++++----------------------------- drivers/gpu/drm/radeon/radeon.h | 41 ++++++++++++++++++ 2 files changed, 55 insertions(+), 67 deletions(-) diff --git a/drivers/gpu/drm/radeon/r600_hdmi.c b/drivers/gpu/drm/radeon/r600_hdmi.c index c308432..b14c90a 100644 --- a/drivers/gpu/drm/radeon/r600_hdmi.c +++ b/drivers/gpu/drm/radeon/r600_hdmi.c @@ -134,78 +134,22 @@ static void r600_hdmi_infoframe_checksum(uint8_t packetType, } /* - * build a HDMI Video Info Frame + * Upload a HDMI AVI Infoframe */ -static void r600_hdmi_videoinfoframe( - struct drm_encoder *encoder, - enum r600_hdmi_color_format color_format, - int active_information_present, - uint8_t active_format_aspect_ratio, - uint8_t scan_information, - uint8_t colorimetry, - uint8_t ex_colorimetry, - uint8_t quantization, - int ITC, - uint8_t picture_aspect_ratio, - uint8_t video_format_identification, - uint8_t pixel_repetition, - uint8_t non_uniform_picture_scaling, - uint8_t bar_info_data_valid, - uint16_t top_bar, - uint16_t bottom_bar, - uint16_t left_bar, - uint16_t right_bar -) +static void r600_hdmi_avi_infoframe(struct drm_encoder *encoder, + struct radeon_avi_infoframe infoframe) { struct drm_device *dev = encoder->dev; struct radeon_device *rdev = dev->dev_private; uint32_t offset = to_radeon_encoder(encoder)->hdmi_offset; - uint8_t frame[14]; - - frame[0x0] = 0; - frame[0x1] = - (scan_information & 0x3) | - ((bar_info_data_valid & 0x3) << 2) | - ((active_information_present & 0x1) << 4) | - ((color_format & 0x3) << 5); - frame[0x2] = - (active_format_aspect_ratio & 0xF) | - ((picture_aspect_ratio & 0x3) << 4) | - ((colorimetry & 0x3) << 6); - frame[0x3] = - (non_uniform_picture_scaling & 0x3) | - ((quantization & 0x3) << 2) | - ((ex_colorimetry & 0x7) << 4) | - ((ITC & 0x1) << 7); - frame[0x4] = (video_format_identification & 0x7F); - frame[0x5] = (pixel_repetition & 0xF); - frame[0x6] = (top_bar & 0xFF); - frame[0x7] = (top_bar >> 8); - frame[0x8] = (bottom_bar & 0xFF); - frame[0x9] = (bottom_bar >> 8); - frame[0xA] = (left_bar & 0xFF); - frame[0xB] = (left_bar >> 8); - frame[0xC] = (right_bar & 0xFF); - frame[0xD] = (right_bar >> 8); + /* Standard says about 0x82 0x02 but radeon uses 0x81 0x01...? */ + r600_hdmi_infoframe_checksum(0x81, 0x01, 13, (u8 *)&infoframe); - r600_hdmi_infoframe_checksum(0x82, 0x02, 0x0D, frame); - /* Our header values (type, version, length) should be alright, Intel - * is using the same. Checksum function also seems to be OK, it works - * fine for audio infoframe. However calculated value is always lower - * by 2 in comparison to fglrx. It breaks displaying anything in case - * of TVs that strictly check the checksum. Hack it manually here to - * workaround this issue. */ - frame[0x0] += 2; - - WREG32(HDMI0_AVI_INFO0 + offset, - frame[0x0] | (frame[0x1] << 8) | (frame[0x2] << 16) | (frame[0x3] << 24)); - WREG32(HDMI0_AVI_INFO1 + offset, - frame[0x4] | (frame[0x5] << 8) | (frame[0x6] << 16) | (frame[0x7] << 24)); - WREG32(HDMI0_AVI_INFO2 + offset, - frame[0x8] | (frame[0x9] << 8) | (frame[0xA] << 16) | (frame[0xB] << 24)); - WREG32(HDMI0_AVI_INFO3 + offset, - frame[0xC] | (frame[0xD] << 8)); + WREG32(HDMI0_AVI_INFO0 + offset, ((u32 *)&infoframe)[0]); + WREG32(HDMI0_AVI_INFO1 + offset, ((u32 *)&infoframe)[1]); + WREG32(HDMI0_AVI_INFO2 + offset, ((u32 *)&infoframe)[2]); + WREG32(HDMI0_AVI_INFO3 + offset, ((u32 *)&infoframe)[3]); } /* @@ -316,6 +260,10 @@ void r600_hdmi_setmode(struct drm_encoder *encoder, struct drm_display_mode *mod struct radeon_device *rdev = dev->dev_private; uint32_t offset = to_radeon_encoder(encoder)->hdmi_offset; + /* TODO: fill in more avi info */ + struct radeon_avi_infoframe infoframe = { }; + infoframe.color_format = 0; + if (ASIC_IS_DCE5(rdev)) return; @@ -367,8 +315,7 @@ void r600_hdmi_setmode(struct drm_encoder *encoder, struct drm_display_mode *mod WREG32(HDMI0_GC + offset, 0); /* unset HDMI0_GC_AVMUTE */ - r600_hdmi_videoinfoframe(encoder, RGB, 0, 0, 0, 0, - 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0); + r600_hdmi_avi_infoframe(encoder, infoframe); r600_hdmi_update_ACR(encoder, mode->clock); diff --git a/drivers/gpu/drm/radeon/radeon.h b/drivers/gpu/drm/radeon/radeon.h index a7ae4ca..5a5c76f 100644 --- a/drivers/gpu/drm/radeon/radeon.h +++ b/drivers/gpu/drm/radeon/radeon.h @@ -1874,6 +1874,47 @@ struct radeon_hdmi_acr { }; +struct radeon_avi_infoframe { + unsigned checksum: 8; + + unsigned scan_information: 2; + unsigned bar_info_data_valid: 2; + unsigned active_information_present: 1; + unsigned color_format: 2; + unsigned :1; + + unsigned active_format_aspect_ratio:4; + unsigned picture_aspect_ratio:2; + unsigned colorimetry:2; + + unsigned non_uniform_picture_scaling:2; + unsigned quantization:2; + unsigned ex_colorimetry:3; + unsigned ITC:1; + + unsigned video_format_identification: 7; + unsigned :1; + + unsigned pixel_repetition: 4; + unsigned :4; + + unsigned top_bar_lo: 8; + + unsigned top_bar_hi: 8; + + unsigned bottom_bar_lo: 8; + + unsigned bottom_bar_hi: 8; + + unsigned left_bar_lo: 8; + + unsigned left_bar_hi: 8; + + unsigned right_bar_lo: 8; + + unsigned right_bar_hi: 8; +} __packed; + extern struct radeon_hdmi_acr r600_hdmi_acr(uint32_t clock); extern void r600_hdmi_enable(struct drm_encoder *encoder); -- 1.7.7

5 7

[Bug 49484] New: invalid enum 0x500, invalid value 0x501
by bugzilla-daemon＠freedesktop.org 07 May '12

07 May '12

https://bugs.freedesktop.org/show_bug.cgi?id=49484 Bug #: 49484 Summary: invalid enum 0x500, invalid value 0x501 Classification: Unclassified Product: Mesa Version: 8.0 Platform: x86-64 (AMD64) OS/Version: Linux (All) Status: NEW Severity: enhancement Priority: medium Component: Drivers/DRI/R600 AssignedTo: dri-devel(a)lists.freedesktop.org ReportedBy: hramrach(a)gmail.com running D3D application in wine I get lots of err:d3d_surface:surface_allocate_surface >>>>>>>>>>>>>>>>> GL_INVALID_VALUE (0x501) from glTexImage2D @ surface.c / 2566 err:d3d_surface:surface_upload_data >>>>>>>>>>>>>>>>> GL_INVALID_ENUM (0x500) from glTexSubImage2D @ surface.c / 2349 Needless to say I get pretty much nothing visible. OpenGL renderer string: Gallium 0.4 on AMD REDWOOD OpenGL version string: 2.1 Mesa 8.0.2 Maybe wine is using a format/feature without checking it is available here. However, r600 could implement it I guess. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug.

1 7

SA and other Patches.
by Christian König 07 May '12

07 May '12

Hi Jerome & everybody on the list, this gathers together every patch we developed over the last week or so and which is not already in drm-next. I've run quite some tests with them yesterday and today and as far as I can see hammered out every known bug. For the SA allocator I reverted to tracking the hole pointer instead of just the last allocation, cause otherwise we will never release the first allocation on the list. Glxgears now even keeps happily running if I deadlock on the not GFX rings on purpose. Please take a second look at them and if nobody objects any more we should commit them to drm-next. Cheers, Christian.

2 27

[PULL] drm-intel-next manual merge
by Daniel Vetter 07 May '12

07 May '12

Hi Dave, As discussed on irc&mail, here's the pull request for the manual merge to unconfuse git about the changes in intel_display.c. Note that I've manually frobbed the shortlog to exclude all the changes merge through Linus' tree. Yours, Daniel The following changes since commit 5bc69bf9aeb73547cad8e1ce683a103fe9728282: Merge tag 'drm-intel-next-2012-04-23' of git://people.freedesktop.org/~danvet/drm-intel into drm-core-next (2012-05-02 09:22:29 +0100) are available in the git repository at: git://people.freedesktop.org/~danvet/drm-intel for-airlied for you to fetch changes up to dc257cf154be708ecc47b8b89c12ad8cd2cc35e4: Merge tag 'v3.4-rc6' into drm-intel-next (2012-05-07 14:02:14 +0200) ---------------------------------------------------------------- Daniel Vetter (1): Merge tag 'v3.4-rc6' into drm-intel-next -- Daniel Vetter Mail: daniel(a)ffwll.ch Mobile: +41 (0)79 365 57 48

1 0

[git pull] drm fixes
by Dave Airlie 07 May '12

07 May '12

Two fixes from Intel, one a regression, one because I merged an early version of a fix. Also the nouveau revert of the i2c code that was tested on the list. Dave. The following changes since commit febb72a6e4cc6c8cffcc1ea649a3fb364f1ea432: IA32 emulation: Fix build problem for modular ia32 a.out support (2012-05-06 18:26:20 -0700) are available in the git repository at: git://people.freedesktop.org/~airlied/linux drm-fixes Ben Skeggs (1): drm/nouveau/i2c: resume use of i2c-algo-bit, rather than custom stack Daniel Vetter (2): drm/i915: disable sdvo hotplug on i945g/gm drm/i915: Do no set Stencil Cache eviction LRA w/a on gen7+ Dave Airlie (1): Merge branch 'drm-intel-fixes' of git://people.freedesktop.org/~danvet/drm-intel into drm-fixes drivers/gpu/drm/i915/intel_ringbuffer.c | 9 +- drivers/gpu/drm/i915/intel_sdvo.c | 6 + drivers/gpu/drm/nouveau/nouveau_i2c.c | 199 ++++--------------------------- drivers/gpu/drm/nouveau/nouveau_i2c.h | 1 + 4 files changed, 34 insertions(+), 181 deletions(-)

1 0

[PULL] drm-intel-fixes
by Daniel Vetter 07 May '12

07 May '12

Hi Dave, 2 little patches: - One regression fix to disable sdvo hotplug on broken hw. - One patch to upconvert the snb hang workaround from patch v1 to patch v2. Yours, Daniel The following changes since commit d48b97b403d23f6df0b990cee652bdf9a52337a3: Linux 3.4-rc6 (2012-05-06 15:07:32 -0700) are available in the git repository at: git://people.freedesktop.org/~danvet/drm-intel drm-intel-fixes for you to fetch changes up to 2e7a44814d802c8ba479164b8924070cd908d6b5: drm/i915: Do no set Stencil Cache eviction LRA w/a on gen7+ (2012-05-07 10:37:56 +0200) ---------------------------------------------------------------- Daniel Vetter (2): drm/i915: disable sdvo hotplug on i945g/gm drm/i915: Do no set Stencil Cache eviction LRA w/a on gen7+ drivers/gpu/drm/i915/intel_ringbuffer.c | 9 ++++++--- drivers/gpu/drm/i915/intel_sdvo.c | 6 ++++++ 2 files changed, 12 insertions(+), 3 deletions(-) -- Daniel Vetter Mail: daniel(a)ffwll.ch Mobile: +41 (0)79 365 57 48

1 0

← Newer
1
...
66
67
68
69
70
71
72
73
74
Older →

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

dri-devel May 2012