gt;>>>
>>>>>>>>> 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(>mman.bdev);
>>>>>>>>>>> +
>>>>>>>>>>> + mutex_lock(>ring_lock);
>>>>>>>>>>> + radeon_fence_driver_force_completion(rdev);
>>>>>>>>>>> + mutex_unlock(>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>
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 --
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
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
>
https://bugs.freedesktop.org/show_bug.cgi?id=50594
Christian König deathsim...@vodafone.de changed:
What|Removed |Added
Status|REOPENED|RESOLVED
https://bugs.freedesktop.org/show_bug.cgi?id=50594
--- Comment #8 from Axel agge...@gmail.com ---
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.
https://bugs.freedesktop.org/show_bug.cgi?id=50594
--- Comment #9 from Christian König deathsim...@vodafone.de ---
(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
https://bugs.freedesktop.org/show_bug.cgi?id=70199
--- Comment #7 from Peter Wu lekenst...@gmail.com ---
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.
https://bugs.freedesktop.org/show_bug.cgi?id=70199
--- Comment #8 from Peter Wu lekenst...@gmail.com ---
Created attachment 87554
-- https://bugs.freedesktop.org/attachment.cgi?id=87554action=edit
piglit test showing importance of parameter order
The order of parameters for long seems to
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
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 a
https://bugs.freedesktop.org/show_bug.cgi?id=68451
--- Comment #36 from Alexandre Demers alexandre.f.dem...@gmail.com ---
(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
https://bugs.freedesktop.org/show_bug.cgi?id=69675
--- Comment #22 from Pierre Ossman pierre-bugzi...@ossman.eu ---
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
https://bugs.freedesktop.org/show_bug.cgi?id=69675
--- Comment #23 from Alex Deucher ag...@yahoo.com ---
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.
___
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 +--
https://bugs.freedesktop.org/show_bug.cgi?id=70019
Nikolay Amiantov nikoa...@gmail.com changed:
What|Removed |Added
Status|NEW |RESOLVED
On Sun, Oct 13, 2013 at 12:26 PM, Rafał Miłecki zaj...@gmail.com 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
2013/10/13 Alex Deucher alexdeuc...@gmail.com:
On Sun, Oct 13, 2013 at 12:26 PM, Rafał Miłecki zaj...@gmail.com 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
On Sun, Oct 13, 2013 at 1:06 PM, Rafał Miłecki zaj...@gmail.com wrote:
2013/10/13 Alex Deucher alexdeuc...@gmail.com:
On Sun, Oct 13, 2013 at 12:26 PM, Rafał Miłecki zaj...@gmail.com wrote:
That allow us to use registers defined in evergreend.h.
---
This is another proposal for HDMI code
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
https://bugs.freedesktop.org/show_bug.cgi?id=67187
Harald Judt h.j...@gmx.at changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
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
https://bugs.freedesktop.org/show_bug.cgi?id=70440
--- Comment #1 from Mike Lothian m...@fireburn.co.uk ---
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, bugzilla-dae...@freedesktop.org wrote:
Priority medium
https://bugs.freedesktop.org/show_bug.cgi?id=70440
Erdem U. Altınyurt spamjunkea...@gmail.com changed:
What|Removed |Added
Status|NEW |RESOLVED
https://bugs.freedesktop.org/show_bug.cgi?id=70439
--- Comment #1 from Alex Deucher ag...@yahoo.com ---
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.
https://bugs.freedesktop.org/show_bug.cgi?id=68391
--- Comment #11 from Hohahiu rakothe...@gmail.com ---
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
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
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 compatible
28 matches
Mail list logo
