[Bug 50594] VDPAU checks version of wrong DRM driver

2013-10-13 Thread bugzilla-daemon
https://bugs.freedesktop.org/show_bug.cgi?id=50594 Christian König changed: What|Removed |Added Status|REOPENED|RESOLVED Resolution|---

[Bug 50594] VDPAU checks version of wrong DRM driver

2013-10-13 Thread bugzilla-daemon
https://bugs.freedesktop.org/show_bug.cgi?id=50594 --- Comment #8 from Axel --- Sorry to disturb you Christian but in what version was it fixed? And would that also fix bug 60016? -- You are receiving this mail because: You are the assignee for the bug. _

[Bug 50594] VDPAU checks version of wrong DRM driver

2013-10-13 Thread bugzilla-daemon
https://bugs.freedesktop.org/show_bug.cgi?id=50594 --- Comment #9 from Christian König --- (In reply to comment #8) > Sorry to disturb you Christian but in what version was it fixed? > And would that also fix bug 60016? Dave fixed this with commit 19338157c97becac1e61cc51dc0904ddfab8e9da on Jul

[Bug 70199] clang+llvm from svn crashes when generating opencl code for 64 bit types

2013-10-13 Thread bugzilla-daemon
https://bugs.freedesktop.org/show_bug.cgi?id=70199 --- Comment #7 from Peter Wu --- I tried the the patch from comment 5, but the piglit tests have not improved. -- You are receiving this mail because: You are the assignee for the bug. ___ dri-devel m

[Bug 70199] clang+llvm from svn crashes when generating opencl code for 64 bit types

2013-10-13 Thread bugzilla-daemon
https://bugs.freedesktop.org/show_bug.cgi?id=70199 --- Comment #8 from Peter Wu --- Created attachment 87554 --> https://bugs.freedesktop.org/attachment.cgi?id=87554&action=edit piglit test showing importance of parameter order The order of parameters for long seems to matter. Output for the a

Re: [PATCH] drm/radeon: signal all fences after lockup to avoid endless waiting in GEM_WAIT

2013-10-13 Thread Christian König
I've figured out what was wrong with the patch. We need to reset the "needs_reset" flag earlier, otherwise the IB test might think we are in a lockup and aborts the reset after waiting for the minimum timeout period. Please try the attached patch instead. Thanks, Christian. Am 09.10.2013 14:0

Re: i915 driver fails on i686 userspace + x86_64 kernel

2013-10-13 Thread Chris Wilson
On Sun, Oct 13, 2013 at 12:40:10AM -0400, Pavel Roskin wrote: > I won't see that system until Tuesday. I'll give you the > information you ask, I'm just trying to understand the debugging > data I have already. I've just double checked that an i386 Xserver runs with an x86-64 kernel here. I think

[Bug 68451] Texture flicker in native Dota2 in mesa 9.2.0rc1

2013-10-13 Thread bugzilla-daemon
https://bugs.freedesktop.org/show_bug.cgi?id=68451 --- Comment #36 from Alexandre Demers --- (In reply to comment #30) > Is there any performance regression? If there isn't, I'm okay with the > revert. I've run with the original commit 7948ed (+ little workaround) and with it remove (both using

[Bug 69675] audio broken in 24Hz/24p since 3.11 (regression)

2013-10-13 Thread bugzilla-daemon
https://bugs.freedesktop.org/show_bug.cgi?id=69675 --- Comment #22 from Pierre Ossman --- So what's the verdict? Can these patches be applied? It would be nice to be able to go back to a stock kernel. :) -- You are receiving this mail because: You are the assignee for the bug. _

[Bug 69675] audio broken in 24Hz/24p since 3.11 (regression)

2013-10-13 Thread bugzilla-daemon
https://bugs.freedesktop.org/show_bug.cgi?id=69675 --- Comment #23 from Alex Deucher --- Already queued for 3.12 fixes. Should show up in the next RC. -- You are receiving this mail because: You are the assignee for the bug. ___ dri-devel mailing lis

[RFC][PATCH] drm/radeon: put DCE4 audio init/fini in evergreen_hdmi.c

2013-10-13 Thread Rafał Miłecki
That allow us to use registers defined in evergreend.h. --- This is another proposal for HDMI code improvment. I'll start testing my patches soon, so I hope to re-send all of them in the following days. --- drivers/gpu/drm/radeon/evergreen.c |4 +-- drivers/gpu/drm/radeon/evergreen_hdmi.c

[Bug 70019] [RV670] GPU lockup and screen garbage on splash screen and in GNOME

2013-10-13 Thread bugzilla-daemon
https://bugs.freedesktop.org/show_bug.cgi?id=70019 Nikolay Amiantov changed: What|Removed |Added Status|NEW |RESOLVED Resolution|---

Re: [RFC][PATCH] drm/radeon: put DCE4 audio init/fini in evergreen_hdmi.c

2013-10-13 Thread Alex Deucher
On Sun, Oct 13, 2013 at 12:26 PM, Rafał Miłecki wrote: > That allow us to use registers defined in evergreend.h. > --- > This is another proposal for HDMI code improvment. I'll start testing > my patches soon, so I hope to re-send all of them in the following days. Might be worth adding audio_ini

Re: [RFC][PATCH] drm/radeon: put DCE4 audio init/fini in evergreen_hdmi.c

2013-10-13 Thread Rafał Miłecki
2013/10/13 Alex Deucher : > On Sun, Oct 13, 2013 at 12:26 PM, Rafał Miłecki wrote: >> That allow us to use registers defined in evergreend.h. >> --- >> This is another proposal for HDMI code improvment. I'll start testing >> my patches soon, so I hope to re-send all of them in the following days.

Re: [RFC][PATCH] drm/radeon: put DCE4 audio init/fini in evergreen_hdmi.c

2013-10-13 Thread Alex Deucher
On Sun, Oct 13, 2013 at 1:06 PM, Rafał Miłecki wrote: > 2013/10/13 Alex Deucher : >> On Sun, Oct 13, 2013 at 12:26 PM, Rafał Miłecki wrote: >>> That allow us to use registers defined in evergreend.h. >>> --- >>> This is another proposal for HDMI code improvment. I'll start testing >>> my patches

Old: i810 reclaim buffers deadlock

2013-10-13 Thread Paul Rogers
Ancient history, I know, apologies for that, but I can't see my way to a solution and need help. Arguments: i815, kernel 2.6.34.14, XOrg-7.2, driver xf86-video-i810-1.6.5/1.7.4 I'm hitting the old buffer reclaim deadlock problem. Is there a compatible kernel patch for 2.6.34 or a version of the

[Bug 67187] Radeon HD6950: UVD not responding, trying to reset the VCPU

2013-10-13 Thread bugzilla-daemon
https://bugs.freedesktop.org/show_bug.cgi?id=67187 Harald Judt changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|---

[Bug 70439] New: Mobility 4570: System freezes after ~5s of enabling audio via xrandr

2013-10-13 Thread bugzilla-daemon
https://bugs.freedesktop.org/show_bug.cgi?id=70439 Priority: medium Bug ID: 70439 Assignee: dri-devel@lists.freedesktop.org Summary: Mobility 4570: System freezes after ~5s of enabling audio via xrandr Severity: major Cla

[Bug 70440] New: Radeon HDMI Audio issues with Kernel 3.12

2013-10-13 Thread bugzilla-daemon
https://bugs.freedesktop.org/show_bug.cgi?id=70440 Priority: medium Bug ID: 70440 Assignee: dri-devel@lists.freedesktop.org Summary: Radeon HDMI Audio issues with Kernel 3.12 Severity: critical Classification: Unclassified OS

[Bug 70440] Radeon HDMI Audio issues with Kernel 3.12

2013-10-13 Thread bugzilla-daemon
https://bugs.freedesktop.org/show_bug.cgi?id=70440 --- Comment #1 from Mike Lothian --- You need to use xrandr to activate audio now xrandr --output HDMI-0 --set audio auto Should do the trick On 14 Oct 2013 01:48, wrote: > Priority medium Bug ID > 70440

[Bug 70440] Radeon HDMI Audio issues with Kernel 3.12

2013-10-13 Thread bugzilla-daemon
https://bugs.freedesktop.org/show_bug.cgi?id=70440 Erdem U. Altınyurt changed: What|Removed |Added Status|NEW |RESOLVED Resolution|---

[Bug 70439] Mobility 4570: System freezes after ~5s of enabling audio via xrandr

2013-10-13 Thread bugzilla-daemon
https://bugs.freedesktop.org/show_bug.cgi?id=70439 --- Comment #1 from Alex Deucher --- Please attach your xorg log and dmesg output. If this is a regression can you use git to bisect? -- You are receiving this mail because: You are the assignee for the bug. ___

[Bug 68391] [radeonsi] Crash unigine-sanctuary

2013-10-13 Thread bugzilla-daemon
https://bugs.freedesktop.org/show_bug.cgi?id=68391 --- Comment #11 from Hohahiu --- It seems that the commit 6e51c2a941955fd2a34d62437fc149e633e79ec7 "radeonsi: Allow Sinking pass to move preloaded const/res/sampl" by Vincent Lejeune has fixed this problem with Unigine Sanctuary and Unigine Heave

Re: [PATCH v2 15/27] gpu: host1x: Add support for Tegra114

2013-10-13 Thread Terje Bergström
On 12.10.2013 14:24, Thierry Reding wrote: > Yeah, I don't like very much how this is currently done. I mean about > half of this is actually duplicate code because of the static inline > functions used for register defines. As discussed elsewhere this was > originally meant to be used for coverage

Re: [PATCH v2 27/27] drm/tegra: Add Tegra114 gr2d support

2013-10-13 Thread Terje Bergström
On 12.10.2013 01:43, Stephen Warren wrote: > On 10/07/2013 02:34 AM, Thierry Reding wrote: >> The gr2d hardware in Tegra114 is compatible with that of Tegra20 and >> Tegra30. No functionaly changes are required. > Similarly here, if the HW is 100% backwards-compatible, there's no need > to add comp

[Bug 70327] Casting floating point variable to integer not working properly while constant gets converted properly

2013-10-13 Thread bugzilla-daemon
https://bugs.freedesktop.org/show_bug.cgi?id=70327 Fabio Pedretti changed: What|Removed |Added Status|NEW |RESOLVED Resolution|---

[PULL] drm-intel-next

2013-10-13 Thread Daniel Vetter
Hi Dave, New feature pile for 3.12! Highlights: - Stereo/3d support for hdmi from Damien, both the drm core bits and the i915 integration. - Manual boost/deboost logic for gpu turbo (Chris) - Fixed up clock readout support for vlv (Chris). - Tons of little fixes and improvements for vlv in gener

[PATCH] drm/radeon: signal all fences after lockup to avoid endless waiting in GEM_WAIT

2013-10-13 Thread Marek Olšák
;>> I'm afraid signalling the fences with an IB test is not reliable. >>>>>>>>> >>>>>>>>> Marek >>>>>>>>> >>>>>>>>> On Wed, Oct 2, 2013 at 3:52 PM, Christian K?nig >>>>>>>>> wrote: >>>>>>>>>> >>>>>>>>>> NAK, after recovering from a lockup the first thing we do is >>>>>>>>>> signalling all remaining fences with an IB test. >>>>>>>>>> >>>>>>>>>> If we don't recover we indeed signal all fences manually. >>>>>>>>>> >>>>>>>>>> Signalling all fences regardless of the outcome of the reset >>>>>>>>>> creates >>>>>>>>>> problems with both types of partial resets. >>>>>>>>>> >>>>>>>>>> Christian. >>>>>>>>>> >>>>>>>>>> Marek Ol??k schrieb: >>>>>>>>>> >>>>>>>>>>> From: Marek Ol??k >>>>>>>>>>> >>>>>>>>>>> After a lockup, fences are not signalled sometimes, causing >>>>>>>>>>> the GEM_WAIT_IDLE ioctl to never return, which sometimes results >>>>>>>>>>> in an X server freeze. >>>>>>>>>>> >>>>>>>>>>> This fixes only one of many deadlocks which can occur during a >>>>>>>>>>> lockup. >>>>>>>>>>> >>>>>>>>>>> Signed-off-by: Marek Ol??k >>>>>>>>>>> --- >>>>>>>>>>> drivers/gpu/drm/radeon/radeon_device.c | 5 + >>>>>>>>>>> 1 file changed, 5 insertions(+) >>>>>>>>>>> >>>>>>>>>>> diff --git a/drivers/gpu/drm/radeon/radeon_device.c >>>>>>>>>>> b/drivers/gpu/drm/radeon/radeon_device.c >>>>>>>>>>> index 841d0e0..7b97baa 100644 >>>>>>>>>>> --- a/drivers/gpu/drm/radeon/radeon_device.c >>>>>>>>>>> +++ b/drivers/gpu/drm/radeon/radeon_device.c >>>>>>>>>>> @@ -1552,6 +1552,11 @@ int radeon_gpu_reset(struct radeon_device >>>>>>>>>>> *rdev) >>>>>>>>>>> radeon_save_bios_scratch_regs(rdev); >>>>>>>>>>> /* block TTM */ >>>>>>>>>>> resched = >>>>>>>>>>> ttm_bo_lock_delayed_workqueue(&rdev->mman.bdev); >>>>>>>>>>> + >>>>>>>>>>> + mutex_lock(&rdev->ring_lock); >>>>>>>>>>> + radeon_fence_driver_force_completion(rdev); >>>>>>>>>>> + mutex_unlock(&rdev->ring_lock); >>>>>>>>>>> + >>>>>>>>>>> radeon_pm_suspend(rdev); >>>>>>>>>>> radeon_suspend(rdev); >>>>>>>>>>> >>>>>>>>>>> -- >>>>>>>>>>> 1.8.1.2 >>>>>>>>>>> >>>>>>>>>>> ___ >>>>>>>>>>> dri-devel mailing list >>>>>>>>>>> dri-devel at lists.freedesktop.org >>>>>>>>>>> http://lists.freedesktop.org/mailman/listinfo/dri-devel >>>>>> >>>>>> >>>>>> ___ >>>>>> dri-devel mailing list >>>>>> dri-devel at lists.freedesktop.org >>>>>> http://lists.freedesktop.org/mailman/listinfo/dri-devel >>>>> >>>>> > -- next part -- A non-text attachment was scrubbed... Name: dmesg Type: application/octet-stream Size: 88645 bytes Desc: not available URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20131013/3c73e0e0/attachment-0001.obj>

i915 driver fails on i686 userspace + x86_64 kernel

2013-10-13 Thread Pavel Roskin
Quoting Chris Wilson : >> I believe the error is on the kernel side. The kernel should >> convert the pointer. compat_ptr() doesn't convert the value, only >> the type. The comment in arch/x86/include/asm/compat.h says: > > That seems odd as the kernel expects a 32-bit address for the user > pr

[PATCH 0/4] remove devm_pinctrl_get_select_default from drivers

2013-10-13 Thread Wolfram Sang
The core does this automatically, no need to do this explicitly in drivers. Those patchces should go via the respective subtrees. Thanks! Wolfram Sang (4): drivers/gpu/drm/tilcdc: don't use devm_pinctrl_get_select_default() in probe drivers/mmc/host: don't use devm_pinctrl_get_select_defa

[PATCH 1/4] drivers/gpu/drm/tilcdc: don't use devm_pinctrl_get_select_default() in probe

2013-10-13 Thread Wolfram Sang
Since commit ab78029 (drivers/pinctrl: grab default handles from device core), we can rely on device core for setting the default pins. Compile tested only. Acked-by: Linus Walleij (personally at LCE13) Signed-off-by: Wolfram Sang --- drivers/gpu/drm/tilcdc/tilcdc_panel.c | 6 -- drivers/g