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 Mon, Jul 09, 2012 at 03:13:25PM +0200, Henrik Rydberg wrote:
> 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 hardwa
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
https://bugs.freedesktop.org/show_bug.cgi?id=33309
Chris Wilson changed:
What|Removed |Added
Status|NEEDINFO|RESOLVED
Resolution|
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
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
https://bugs.freedesktop.org/show_bug.cgi?id=51870
Marek Ol??k changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|
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 writeba
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
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
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
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)
>>
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
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
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
>> ++---
This patch adds a exynos drm specific implementation of fb_mmap
which supports mapping a non-contiguous buffer to user space.
This new function does not assume that the frame buffer is contiguous
and calls dma_mmap_writecombine for mapping the buffer to user space.
dma_mmap_writecombine will be abl
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 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
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
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 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
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
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
> > > 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?
>
>
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->
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
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 +++
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
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
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
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
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
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
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 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
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
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
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
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
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 +
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
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
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
> + commit &= ring->track_mask;
> + }
> + seq_printf(m, "\n");
> i = (i + 1) & ring->ptr_mask;
> }
> return 0;
> --
> 1.7.9.5
>
> ___
> 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: 0001-drm-radeon-record-what-is-next-valid-wptr-for-each-r.patch
Type: application/octet-stream
Size: 7152 bytes
Desc: not available
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20120709/f0d368f6/attachment.obj>
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
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 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
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
ke some work. Sounds like a
fun project for someone.
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: not available
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20120709/0b21e4c7/attachment.pgp>
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
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
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, 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 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
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|
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 #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 #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 #75081|application/octet-stream|text/plain
mime type|
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 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
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
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 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 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 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 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, 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, 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
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
https://bugs.freedesktop.org/show_bug.cgi?id=33309
Chris Wilson changed:
What|Removed |Added
Status|NEEDINFO|RESOLVED
Resolution|
> > > 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
--- 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
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=51870
Marek Olšák changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|
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 +++
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
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
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
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
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
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
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
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
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
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 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
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
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 +
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
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
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
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
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|
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 #75091|application/octet-stream|text/plain
mime type|
1 - 100 of 116 matches
Mail list logo
