On Sun, 8 Jul 2012, Alan Cox wrote:
On Sun, 8 Jul 2012 10:39:43 +0200 (CEST)
Julia Lawall wrote:
In the function oaktrail_lvds_mode_set, I don't think that the following
code makes any sense:
/* Find the connector we're trying to set up */
list_for_each_entry(connector, &mo
On Sun, 8 Jul 2012, Paul Menzel wrote:
Dear Julia,
Am Sonntag, den 08.07.2012, 13:37 +0200 schrieb Julia Lawall:
From: Julia Lawall
If list_for_each_entry, etc complete a traversal of the list, the iterator
variable ends up pointing to an address at an offset from the list head,
and not a m
From: Julia Lawall
If list_for_each_entry, etc complete a traversal of the list, the iterator
variable ends up pointing to an address at an offset from the list head,
and not a meaningful structure. Thus this value should not be used after
the end of the iterator.
A break is added after the swi
From: Julia Lawall
If list_for_each_entry, etc complete a traversal of the list, the iterator
variable ends up pointing to an address at an offset from the list head,
and not a meaningful structure. Thus this value should not be used after
the end of the iterator.
A break is added after the swi
From: Julia Lawall
If list_for_each_entry, etc complete a traversal of the list, the iterator
variable ends up pointing to an address at an offset from the list head,
and not a meaningful structure. Thus this value should not be used after
the end of the iterator.
After the iteractor, entry->ba
On Mon, 9 Jul 2012, Patrik Jakobsson wrote:
On Sun, Jul 8, 2012 at 10:16 PM, Alan Cox wrote:
On Sun, 8 Jul 2012 10:39:43 +0200 (CEST)
Julia Lawall wrote:
In the function oaktrail_lvds_mode_set, I don't think that the following
code makes any sense:
/* Find the connector we're tryi
this patch corrects to deallocate the pages allocated by alloc_page()
and fixes exception to page allocation failure.
Thanks.
Inki Dae (2):
drm/exynos: use __free_page() to deallocate memory
drm/exynos: fixed exception to page allocation failure
drivers/gpu/drm/exynos/exynos_drm_gem.c | 1
this patch uses __free_page() to deallocate the pages allocated
by alloc_page() and the pages doesn't need set_parge_dirty()
and mark_page_accessed() because they aren't from page cache so
removes them.
this patch has a pair with previous patch below,
http://www.spinics.net/lists/dri-devel
this patch corrects to deallocate the pages allocated already
at alloc_page failure.
Signed-off-by: Inki Dae
Signed-off-by: Kyungmin Park
---
drivers/gpu/drm/exynos/exynos_drm_gem.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/gpu/drm/exynos/exynos_drm_gem.c
this patch uses __free_page() to deallocate the pages allocated
by alloc_page() and the pages doesn't need set_parge_dirty()
and mark_page_accessed() because they aren't from page cache so
removes them.
this patch has a pair with previous patch below,
http://www.spinics.net/lists/dri-devel
this patch uses __free_page() to deallocate the pages allocated
by alloc_page() and the pages doesn't need set_parge_dirty()
and mark_page_accessed() because they aren't from page cache so
removes them.
this patch has a pair with previous patch below,
http://www.spinics.net/lists/dri-devel
https://bugs.freedesktop.org/show_bug.cgi?id=51870
Michel Dänzer changed:
What|Removed |Added
AssignedTo|xorg-driver-...@lists.x.org |dri-devel@lists.freedesktop
https://bugzilla.kernel.org/show_bug.cgi?id=42984
m.b.lankho...@gmail.com changed:
What|Removed |Added
CC||m.b.lankho...@gmail.com
---
https://bugzilla.kernel.org/show_bug.cgi?id=44341
Christopher Frömmel changed:
What|Removed |Added
Attachment #75081|application/octet-stream|text/plain
mime type|
https://bugzilla.kernel.org/show_bug.cgi?id=44341
Christopher Frömmel changed:
What|Removed |Added
Attachment #75071|application/octet-stream|text/plain
mime type|
https://bugzilla.kernel.org/show_bug.cgi?id=44341
Christopher Frömmel changed:
What|Removed |Added
Attachment #75091|application/octet-stream|text/plain
mime type|
https://bugzilla.kernel.org/show_bug.cgi?id=44341
Christopher Frömmel changed:
What|Removed |Added
Attachment #75121|application/octet-stream|text/plain
mime type|
https://bugzilla.kernel.org/show_bug.cgi?id=44341
Christopher Frömmel changed:
What|Removed |Added
Attachment #75061|application/octet-stream|text/plain
mime type|
On Sun, Jul 08, 2012 at 08:35:55AM +0100, Dave Airlie wrote:
> On Fri, Jul 6, 2012 at 11:58 PM, Greg Kroah-Hartman
> wrote:
> > On Mon, Jul 02, 2012 at 12:05:06PM +0200, Sascha Hauer wrote:
> >> On Thu, Jun 14, 2012 at 03:43:22PM +0200, Sascha Hauer wrote:
> >> > Hi All,
> >> >
> >> > The followin
Waiting for a fence can fail for different reasons,
the most common is a deadlock.
Signed-off-by: Christian König
Reviewed-by: Michel Dänzer
---
drivers/gpu/drm/radeon/radeon_gart.c | 17 ++---
1 file changed, 14 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/radeon/r
Hi,
The following patchset tries to save and restore the not yet processed commands
from the rings in case of a lockup and with that should make a userspace
problem with a single application far less problematic.
The first four patches are just stuff this patchset is based upon, followed by
four
Don't return success if scheduling the IB fails, otherwise
we end up with an oops in ttm_eu_fence_buffer_objects.
Signed-off-by: Christian König
Cc: sta...@vger.kernel.org
---
drivers/gpu/drm/radeon/radeon_cs.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/dr
Instead of returning the error handle it directly
and while at it fix the comments about the ring lock.
Signed-off-by: Christian König
Reviewed-by: Michel Dänzer
---
drivers/gpu/drm/radeon/radeon.h |2 +-
drivers/gpu/drm/radeon/radeon_fence.c | 33 +
We don't need to pad anything if the number of dwords
written to the ring already matches the requirements.
Fixes some "writting more dword to ring than expected"
warnings.
Signed-off-by: Christian König
---
drivers/gpu/drm/radeon/radeon_ring.c |7 +--
1 file changed, 1 insertion(+), 6
It is possible that radeon_fence_process is called
after writeback is disabled for suspend, leading
to an invalid read of register 0x0.
This fixes a problem for me where the fence value
is temporary incremented by 0x1 on
suspend/resume.
Signed-off-by: Christian König
---
drivers/gpu/drm
Start with last signaled fence number instead
of last emitted one.
Signed-off-by: Christian König
---
drivers/gpu/drm/radeon/radeon_fence.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/radeon/radeon_fence.c
b/drivers/gpu/drm/radeon/radeon_fence.c
index
It's not critical, but the current code isn't
100% correct.
Signed-off-by: Christian König
---
drivers/gpu/drm/radeon/ni.c | 133 ++-
1 file changed, 56 insertions(+), 77 deletions(-)
diff --git a/drivers/gpu/drm/radeon/ni.c b/drivers/gpu/drm/radeon/ni.c
For a normal suspend/resume we allready wait for
the rings to be empty, and for a suspend/reasume
in case of a lockup we REALLY don't want to wait
for anything.
Signed-off-by: Christian König
---
drivers/gpu/drm/radeon/evergreen.c |1 -
drivers/gpu/drm/radeon/ni.c|1 -
drivers/gp
The IB pool is in gart memory, so it is completely
superfluous to unpin / repin it on suspend / resume.
Signed-off-by: Christian König
---
drivers/gpu/drm/radeon/evergreen.c | 17 ++---
drivers/gpu/drm/radeon/ni.c | 16 ++--
drivers/gpu/drm/radeon/r100.c
Just reinitialize the shader content on resume instead.
Signed-off-by: Christian König
---
drivers/gpu/drm/radeon/evergreen.c |1 -
drivers/gpu/drm/radeon/evergreen_blit_kms.c | 40 +--
drivers/gpu/drm/radeon/ni.c |1 -
drivers/gpu/drm/r
From: Jerome Glisse
GPU reset need to be exclusive, one happening at a time. For this
add a rw semaphore so that any path that trigger GPU activities
have to take the semaphore as a reader thus allowing concurency.
The GPU reset path take the semaphore as a writer ensuring that
no concurrent res
Making it easier to controlwhen it is executed.
Signed-off-by: Christian König
---
drivers/gpu/drm/radeon/evergreen.c |4
drivers/gpu/drm/radeon/ni.c|4
drivers/gpu/drm/radeon/r100.c |4
drivers/gpu/drm/radeon/r300.c |4
drive
Just restore the page table instead. Addressing three
problem with this change:
1. Calling vm_manager_suspend in the suspend path is
problematic cause it wants to wait for the VM use
to end, which in case of a lockup never happens.
2. In case of a locked up memory controller
unbinding th
Instead of setting it directly from the chipset code.
Signed-off-by: Christian König
---
drivers/gpu/drm/radeon/evergreen.c |3 ++-
drivers/gpu/drm/radeon/ni.c |3 ++-
drivers/gpu/drm/radeon/r100.c|3 +--
drivers/gpu/drm/radeon/r600.c|3 +--
drivers/gpu
Signed-off-by: Christian König
---
drivers/gpu/drm/radeon/radeon.h |3 +++
drivers/gpu/drm/radeon/radeon_ring.c | 39 --
2 files changed, 40 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/radeon/radeon.h b/drivers/gpu/drm/radeon/radeon.h
ind
Try to save whatever is on the rings when
we encounter an lockup.
Signed-off-by: Christian König
---
drivers/gpu/drm/radeon/radeon.h|4 ++
drivers/gpu/drm/radeon/radeon_device.c | 44
drivers/gpu/drm/radeon/radeon_ring.c | 69 +++
https://bugs.freedesktop.org/show_bug.cgi?id=51870
Marek Olšák changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|
https://bugs.freedesktop.org/show_bug.cgi?id=51870
--- Comment #2 from ErikAlesund 2012-07-09 11:13:09
UTC ---
(In reply to comment #1)
> Those environment variables aren't required anymore. GLSL 1.3 and streamout
> are
> enabled by default. The only thing missing is MSAA and there is no way to
https://bugs.freedesktop.org/show_bug.cgi?id=33309
--- Comment #30 from stefan 2012-07-09 11:18:52 PDT ---
Hi Daniel,
(In reply to comment #29)
> (In reply to comment #28)
> > are there any news on this issue?
> > The 3.4 and 3.5-rc series seem stable wrt this issue,
> > but unfortunately somethi
> > > In 3.4, radeon worked with a glitch - window titles were see-throug (not
> > > drawn). In 3.5-rc5, radeon driver seems to be more careful and disables
> > > acceleration on this system at all. Full dmesg below.
> >
> > Does it always do it the same? got the dmesg from 3.4 and/or 2.6.32?
>
>
https://bugs.freedesktop.org/show_bug.cgi?id=33309
Chris Wilson changed:
What|Removed |Added
Status|NEEDINFO|RESOLVED
Resolution|
On Thu, Jul 05, 2012 at 10:34:10AM +0200, Henrik Rydberg wrote:
> On Thu, Jul 05, 2012 at 08:54:46AM +0200, Henrik Rydberg wrote:
> > > Thanks for tracking down the source of this corruption. I don't have
> > > any such hardware, so until someone can figure it out, I think we
> > > should apply th
On Mon, Jul 9, 2012 at 6:41 AM, Christian König wrote:
> It's not critical, but the current code isn't
> 100% correct.
>
> Signed-off-by: Christian König
> ---
> drivers/gpu/drm/radeon/ni.c | 133
> ++-
> 1 file changed, 56 insertions(+), 77 deletions(-)
On Mon, 2012-07-09 at 12:42 +0200, Christian König wrote:
> Try to save whatever is on the rings when
> we encounter an lockup.
>
> Signed-off-by: Christian König
[...]
> @@ -1005,20 +1010,43 @@ int radeon_gpu_reset(struct radeon_device *rdev)
> resched = ttm_bo_lock_delayed_workqueue(&rd
On Mon, 2012-07-09 at 12:42 +0200, Christian König wrote:
> Making it easier to controlwhen it is executed.
>
> Signed-off-by: Christian König
[...]
> diff --git a/drivers/gpu/drm/radeon/radeon_device.c
> b/drivers/gpu/drm/radeon/radeon_device.c
> index 254fdb4..bbd0971 100644
> --- a/drivers/
On 09.07.2012 16:43, Jerome Glisse wrote:
On Mon, Jul 9, 2012 at 6:41 AM, Christian König wrote:
It's not critical, but the current code isn't
100% correct.
Signed-off-by: Christian König
---
drivers/gpu/drm/radeon/ni.c | 133 ++-
1 file changed, 56
On 09.07.2012 17:06, Michel Dänzer wrote:
On Mon, 2012-07-09 at 12:42 +0200, Christian König wrote:
Making it easier to controlwhen it is executed.
Signed-off-by: Christian König
[...]
diff --git a/drivers/gpu/drm/radeon/radeon_device.c
b/drivers/gpu/drm/radeon/radeon_device.c
index 254fdb4
On 09.07.2012 17:06, Michel Dänzer wrote:
On Mon, 2012-07-09 at 12:42 +0200, Christian König wrote:
Try to save whatever is on the rings when
we encounter an lockup.
Signed-off-by: Christian König
[...]
@@ -1005,20 +1010,43 @@ int radeon_gpu_reset(struct radeon_device *rdev)
resched
On Mon, Jul 9, 2012 at 6:42 AM, Christian König wrote:
> Signed-off-by: Christian König
Bit too complex to my taste, what about attached patch, it's lot
simpler. (Haven't tested
the patch but it should work)
Cheers,
Jerome
> ---
> drivers/gpu/drm/radeon/radeon.h |3 +++
> drivers/gpu
On Mon, 2012-07-09 at 17:22 +0200, Christian König wrote:
> On 09.07.2012 17:06, Michel Dänzer wrote:
> > On Mon, 2012-07-09 at 12:42 +0200, Christian König wrote:
> >> Making it easier to controlwhen it is executed.
> >>
> >> Signed-off-by: Christian König
> > [...]
> >> diff --git a/drivers/gpu
On 09.07.2012 17:36, Jerome Glisse wrote:
On Mon, Jul 9, 2012 at 6:42 AM, Christian König wrote:
Signed-off-by: Christian König
Bit too complex to my taste, what about attached patch, it's lot
simpler. (Haven't tested
the patch but it should work)
Cool idea! Depending on the writeback mechani
On Mon, 2012-07-09 at 12:41 +0200, Christian König wrote:
> Hi,
>
> The following patchset tries to save and restore the not yet processed
> commands
> from the rings in case of a lockup and with that should make a userspace
> problem with a single application far less problematic.
>
> The firs
On Mon, Jul 9, 2012 at 11:59 AM, Michel Dänzer wrote:
> On Mon, 2012-07-09 at 12:41 +0200, Christian König wrote:
>> Hi,
>>
>> The following patchset tries to save and restore the not yet processed
>> commands
>> from the rings in case of a lockup and with that should make a userspace
>> problem
On Mon, Jul 9, 2012 at 11:48 AM, Christian König
wrote:
> On 09.07.2012 17:36, Jerome Glisse wrote:
>>
>> On Mon, Jul 9, 2012 at 6:42 AM, Christian König
>> wrote:
>>>
>>> Signed-off-by: Christian König
>>
>> Bit too complex to my taste, what about attached patch, it's lot
>> simpler. (Haven't t
I've done benchmarks and comparison between proprietary drivers and
Mesa, Mesa seems to be up to 200x slower compiling the same shader,
since i understand optimizing such part of code may take months or even
more, i have thought to solve it this way:
Upon calling glLinkProgram , an unoptimized
Tiziano Bacocco writes:
> I've done benchmarks and comparison between proprietary drivers and
> Mesa, Mesa seems to be up to 200x slower compiling the same shader,
> since i understand optimizing such part of code may take months or even
> more, i have thought to solve it this way:
>
> Upon ca
https://bugs.freedesktop.org/show_bug.cgi?id=45018
--- Comment #63 from Alexandre Demers 2012-07-10
00:21:56 PDT ---
Now running latest drm-next just in case. Always the same error, but with a
little something new: with regular kernel, once the GPU crashed, it stays this
way. With the drm-next b
https://bugs.freedesktop.org/show_bug.cgi?id=45018
--- Comment #64 from Alexandre Demers 2012-07-10
00:22:55 PDT ---
Created attachment 64052
--> https://bugs.freedesktop.org/attachment.cgi?id=64052
dmesg drm-next
dmesg with latest drm-next branch
--
Configure bugmail: https://bugs.freedesk
https://bugs.freedesktop.org/show_bug.cgi?id=45018
--- Comment #65 from Alexandre Demers 2012-07-10
00:23:46 PDT ---
Created attachment 64053
--> https://bugs.freedesktop.org/attachment.cgi?id=64053
xsession with drm-next
.xsession with drm-next branch
--
Configure bugmail: https://bugs.fre
Presumably there needs to be a api-level mechanism to wait for the
background optimization to finish, so that piglit etc can validate the
behavior of the optimized shader?
-- Chris
On Tue, Jul 10, 2012 at 5:17 AM, Eric Anholt wrote:
> Tiziano Bacocco writes:
>
>> I've done benchmarks and compar
On Sun, Jul 8, 2012 at 10:16 PM, Alan Cox wrote:
> On Sun, 8 Jul 2012 10:39:43 +0200 (CEST)
> Julia Lawall wrote:
>
>> In the function oaktrail_lvds_mode_set, I don't think that the following
>> code makes any sense:
>>
>> /* Find the connector we're trying to set up */
>> list_
Hi Dave,
Please pull from
git://git.infradead.org/users/kmpark/linux-samsung exynos-drm-fixes
these patch sets below had already been posted several weeks ago for review
and include some fixes and exceptions.
thes patch sets are based on git repository below:
git://people.freedes
with addfb request by user, wrong framebuffer or gem size could be sent
to kernel side so this could induce invalid memory access by dma of a device.
this patch checks if framebuffer and gem size are valid or not to avoid
this issue.
Changelog v2:
use fb->pitches instead of caculating it with fb->
On Mon, 9 Jul 2012, Patrik Jakobsson wrote:
> On Sun, Jul 8, 2012 at 10:16 PM, Alan Cox wrote:
>> On Sun, 8 Jul 2012 10:39:43 +0200 (CEST)
>> Julia Lawall wrote:
>>
>>> In the function oaktrail_lvds_mode_set, I don't think that the following
>>> code makes any sense:
>>>
>>> /* Find the
this patch corrects to deallocate the pages allocated by alloc_page()
and fixes exception to page allocation failure.
Thanks.
Inki Dae (2):
drm/exynos: use __free_page() to deallocate memory
drm/exynos: fixed exception to page allocation failure
drivers/gpu/drm/exynos/exynos_drm_gem.c | 1
this patch uses __free_page() to deallocate the pages allocated
by alloc_page() and the pages doesn't need set_parge_dirty()
and mark_page_accessed() because they aren't from page cache so
removes them.
this patch has a pair with previous patch below,
http://www.spinics.net/lists/dri-devel
this patch corrects to deallocate the pages allocated already
at alloc_page failure.
Signed-off-by: Inki Dae
Signed-off-by: Kyungmin Park
---
drivers/gpu/drm/exynos/exynos_drm_gem.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/gpu/drm/exynos/exynos_drm_gem.c
this patch uses __free_page() to deallocate the pages allocated
by alloc_page() and the pages doesn't need set_parge_dirty()
and mark_page_accessed() because they aren't from page cache so
removes them.
this patch has a pair with previous patch below,
http://www.spinics.net/lists/dri-devel
this patch uses __free_page() to deallocate the pages allocated
by alloc_page() and the pages doesn't need set_parge_dirty()
and mark_page_accessed() because they aren't from page cache so
removes them.
this patch has a pair with previous patch below,
http://www.spinics.net/lists/dri-devel
https://bugs.freedesktop.org/show_bug.cgi?id=51870
Michel D?nzer changed:
What|Removed |Added
AssignedTo|xorg-driver-ati at lists.x.org |dri-devel at
lists.freedesktop
https://bugzilla.kernel.org/show_bug.cgi?id=42984
m.b.lankhorst at gmail.com changed:
What|Removed |Added
CC||m.b.lankhorst at gmail.com
https://bugzilla.kernel.org/show_bug.cgi?id=44341
Christopher Fr?mmel changed:
What|Removed |Added
Attachment #75081|application/octet-stream|text/plain
mime type|
https://bugzilla.kernel.org/show_bug.cgi?id=44341
Christopher Fr?mmel changed:
What|Removed |Added
Attachment #75071|application/octet-stream|text/plain
mime type|
https://bugzilla.kernel.org/show_bug.cgi?id=44341
Christopher Fr?mmel changed:
What|Removed |Added
Attachment #75091|application/octet-stream|text/plain
mime type|
https://bugzilla.kernel.org/show_bug.cgi?id=44341
Christopher Fr?mmel changed:
What|Removed |Added
Attachment #75121|application/octet-stream|text/plain
mime type|
https://bugzilla.kernel.org/show_bug.cgi?id=44341
Christopher Fr?mmel changed:
What|Removed |Added
Attachment #75061|application/octet-stream|text/plain
mime type|
On Sun, Jul 08, 2012 at 08:35:55AM +0100, Dave Airlie wrote:
> On Fri, Jul 6, 2012 at 11:58 PM, Greg Kroah-Hartman
> wrote:
> > On Mon, Jul 02, 2012 at 12:05:06PM +0200, Sascha Hauer wrote:
> >> On Thu, Jun 14, 2012 at 03:43:22PM +0200, Sascha Hauer wrote:
> >> > Hi All,
> >> >
> >> > The followin
Waiting for a fence can fail for different reasons,
the most common is a deadlock.
Signed-off-by: Christian K?nig
Reviewed-by: Michel D?nzer
---
drivers/gpu/drm/radeon/radeon_gart.c | 17 ++---
1 file changed, 14 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/radeon/r
Hi,
The following patchset tries to save and restore the not yet processed commands
from the rings in case of a lockup and with that should make a userspace
problem with a single application far less problematic.
The first four patches are just stuff this patchset is based upon, followed by
four
Don't return success if scheduling the IB fails, otherwise
we end up with an oops in ttm_eu_fence_buffer_objects.
Signed-off-by: Christian K?nig
Cc: stable at vger.kernel.org
---
drivers/gpu/drm/radeon/radeon_cs.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu
Instead of returning the error handle it directly
and while at it fix the comments about the ring lock.
Signed-off-by: Christian K?nig
Reviewed-by: Michel D?nzer
---
drivers/gpu/drm/radeon/radeon.h |2 +-
drivers/gpu/drm/radeon/radeon_fence.c | 33 +
We don't need to pad anything if the number of dwords
written to the ring already matches the requirements.
Fixes some "writting more dword to ring than expected"
warnings.
Signed-off-by: Christian K?nig
---
drivers/gpu/drm/radeon/radeon_ring.c |7 +--
1 file changed, 1 insertion(+), 6
It is possible that radeon_fence_process is called
after writeback is disabled for suspend, leading
to an invalid read of register 0x0.
This fixes a problem for me where the fence value
is temporary incremented by 0x1 on
suspend/resume.
Signed-off-by: Christian K?nig
---
drivers/gpu/drm
Start with last signaled fence number instead
of last emitted one.
Signed-off-by: Christian K?nig
---
drivers/gpu/drm/radeon/radeon_fence.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/radeon/radeon_fence.c
b/drivers/gpu/drm/radeon/radeon_fence.c
index
It's not critical, but the current code isn't
100% correct.
Signed-off-by: Christian K?nig
---
drivers/gpu/drm/radeon/ni.c | 133 ++-
1 file changed, 56 insertions(+), 77 deletions(-)
diff --git a/drivers/gpu/drm/radeon/ni.c b/drivers/gpu/drm/radeon/ni.c
For a normal suspend/resume we allready wait for
the rings to be empty, and for a suspend/reasume
in case of a lockup we REALLY don't want to wait
for anything.
Signed-off-by: Christian K?nig
---
drivers/gpu/drm/radeon/evergreen.c |1 -
drivers/gpu/drm/radeon/ni.c|1 -
drivers/gp
The IB pool is in gart memory, so it is completely
superfluous to unpin / repin it on suspend / resume.
Signed-off-by: Christian K?nig
---
drivers/gpu/drm/radeon/evergreen.c | 17 ++---
drivers/gpu/drm/radeon/ni.c | 16 ++--
drivers/gpu/drm/radeon/r100.c
Just reinitialize the shader content on resume instead.
Signed-off-by: Christian K?nig
---
drivers/gpu/drm/radeon/evergreen.c |1 -
drivers/gpu/drm/radeon/evergreen_blit_kms.c | 40 +--
drivers/gpu/drm/radeon/ni.c |1 -
drivers/gpu/drm/r
From: Jerome Glisse
GPU reset need to be exclusive, one happening at a time. For this
add a rw semaphore so that any path that trigger GPU activities
have to take the semaphore as a reader thus allowing concurency.
The GPU reset path take the semaphore as a writer ensuring that
no concurrent res
Making it easier to controlwhen it is executed.
Signed-off-by: Christian K?nig
---
drivers/gpu/drm/radeon/evergreen.c |4
drivers/gpu/drm/radeon/ni.c|4
drivers/gpu/drm/radeon/r100.c |4
drivers/gpu/drm/radeon/r300.c |4
drive
Just restore the page table instead. Addressing three
problem with this change:
1. Calling vm_manager_suspend in the suspend path is
problematic cause it wants to wait for the VM use
to end, which in case of a lockup never happens.
2. In case of a locked up memory controller
unbinding th
Instead of setting it directly from the chipset code.
Signed-off-by: Christian K?nig
---
drivers/gpu/drm/radeon/evergreen.c |3 ++-
drivers/gpu/drm/radeon/ni.c |3 ++-
drivers/gpu/drm/radeon/r100.c|3 +--
drivers/gpu/drm/radeon/r600.c|3 +--
drivers/gpu
Signed-off-by: Christian K?nig
---
drivers/gpu/drm/radeon/radeon.h |3 +++
drivers/gpu/drm/radeon/radeon_ring.c | 39 --
2 files changed, 40 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/radeon/radeon.h b/drivers/gpu/drm/radeon/radeon.h
ind
Try to save whatever is on the rings when
we encounter an lockup.
Signed-off-by: Christian K?nig
---
drivers/gpu/drm/radeon/radeon.h|4 ++
drivers/gpu/drm/radeon/radeon_device.c | 44
drivers/gpu/drm/radeon/radeon_ring.c | 69 +++
https://bugs.freedesktop.org/show_bug.cgi?id=51870
Marek Ol??k changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|
https://bugs.freedesktop.org/show_bug.cgi?id=51870
--- Comment #2 from ErikAlesund 2012-07-09 11:13:09
UTC ---
(In reply to comment #1)
> Those environment variables aren't required anymore. GLSL 1.3 and streamout
> are
> enabled by default. The only thing missing is MSAA and there is no way to
https://bugs.freedesktop.org/show_bug.cgi?id=33309
--- Comment #30 from stefan 2012-07-09 11:18:52 PDT
---
Hi Daniel,
(In reply to comment #29)
> (In reply to comment #28)
> > are there any news on this issue?
> > The 3.4 and 3.5-rc series seem stable wrt this issue,
> > but unfortunately someth
> > > In 3.4, radeon worked with a glitch - window titles were see-throug (not
> > > drawn). In 3.5-rc5, radeon driver seems to be more careful and disables
> > > acceleration on this system at all. Full dmesg below.
> >
> > Does it always do it the same? got the dmesg from 3.4 and/or 2.6.32?
>
>
https://bugs.freedesktop.org/show_bug.cgi?id=33309
Chris Wilson changed:
What|Removed |Added
Status|NEEDINFO|RESOLVED
Resolution|
On Thu, Jul 05, 2012 at 10:34:10AM +0200, Henrik Rydberg wrote:
> On Thu, Jul 05, 2012 at 08:54:46AM +0200, Henrik Rydberg wrote:
> > > Thanks for tracking down the source of this corruption. I don't have
> > > any such hardware, so until someone can figure it out, I think we
> > > should apply th
1 - 100 of 116 matches
Mail list logo
