From: Dave Airlie
For some reason on resume, executing the BIOS scripts locks up the whole
chipset, by avoiding the dynclk table the machine resumes properly and seems to
function okay.
Signed-off-by: Dave Airlie
---
drivers/gpu/drm/radeon/radeon_combios.c |8
1 files changed, 8
Signed-off-by: Alex Deucher
---
drivers/gpu/drm/radeon/evergreen.c | 23 +++
drivers/gpu/drm/radeon/evergreend.h |3 +++
2 files changed, 26 insertions(+), 0 deletions(-)
diff --git a/drivers/gpu/drm/radeon/evergreen.c
b/drivers/gpu/drm/radeon/evergreen.c
index 38c500
https://bugs.freedesktop.org/show_bug.cgi?id=28627
--- Comment #16 from Alex Deucher 2010-06-29 16:53:45 PDT ---
You can browse commits in via the git web interface:
http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git
You can also narrow the bisect range by just bisecting drm commits
https://bugs.freedesktop.org/show_bug.cgi?id=28627
--- Comment #16 from Alex Deucher 2010-06-29 16:53:45 PDT
---
You can browse commits in via the git web interface:
http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git
You can also narrow the bisect range by just bisecting drm commit
https://bugs.freedesktop.org/show_bug.cgi?id=28627
--- Comment #15 from Connor Behan 2010-06-29 16:48:19
PDT ---
That's a good idea, if a lengthy one.
Is there a way to see a sequential list of commits in one of the "main"
branches? And is there a way to compile only the radeon module if I'm mo
https://bugs.freedesktop.org/show_bug.cgi?id=28627
--- Comment #15 from Connor Behan 2010-06-29
16:48:19 PDT ---
That's a good idea, if a lengthy one.
Is there a way to see a sequential list of commits in one of the "main"
branches? And is there a way to compile only the radeon module if I'm mo
https://bugs.freedesktop.org/show_bug.cgi?id=28774
--- Comment #12 from Alex Deucher 2010-06-29 15:36:33 PDT ---
Created an attachment (id=36615)
View: https://bugs.freedesktop.org/attachment.cgi?id=36615
Review: https://bugs.freedesktop.org/review?bug=28774&attachment=36615
nb_misc pcie regs
https://bugs.freedesktop.org/show_bug.cgi?id=28774
--- Comment #12 from Alex Deucher 2010-06-29 15:36:33 PDT
---
Created an attachment (id=36615)
View: https://bugs.freedesktop.org/attachment.cgi?id=36615
Review: https://bugs.freedesktop.org/review?bug=28774&attachment=36615
nb_misc pcie regs
https://bugs.freedesktop.org/show_bug.cgi?id=28630
--- Comment #9 from Marek Olšák 2010-06-29 15:27:09 PDT ---
OK so I've committed some fixes because they don't break anything. Please let
me know if they help.
PS: There is a new bug in the GLSL compiler in master. I hope you won't hit
that.
--
https://bugs.freedesktop.org/show_bug.cgi?id=28630
--- Comment #9 from Marek Ol??k 2010-06-29 15:27:09 PDT
---
OK so I've committed some fixes because they don't break anything. Please let
me know if they help.
PS: There is a new bug in the GLSL compiler in master. I hope you won't hit
that.
-
ttm_tt_set_user has "ttm->state = tt_unbound" which will cause the
following ttm_tt_populate return directly because of bellow check:
if (ttm->state != tt_unpopulated)
return 0;
Does it mean we don't need to populate user pages? Here is the patch
if it is not the case
Tha
populuated due to the wrong state
Signed-off-by: Austin Yuan
Signed-off-by: Elaine Wang
---
drivers/gpu/drm/ttm/ttm_tt.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/gpu/drm/ttm/ttm_tt.c b/drivers/gpu/drm/ttm/ttm_tt.c
index a7bab87..4ea44c2 100644
--- a/driv
https://bugs.freedesktop.org/show_bug.cgi?id=28630
--- Comment #8 from Marek Olšák 2010-06-29 14:14:20 PDT ---
I think you are right. That seems to be the only logical explanation. The fix
is not trivial, I'll send you a patch when I have one.
--
Configure bugmail: https://bugs.freedesktop.org/
https://bugs.freedesktop.org/show_bug.cgi?id=28630
--- Comment #8 from Marek Ol??k 2010-06-29 14:14:20 PDT
---
I think you are right. That seems to be the only logical explanation. The fix
is not trivial, I'll send you a patch when I have one.
--
Configure bugmail: https://bugs.freedesktop.org
Signed-off-by: Alex Deucher
---
drivers/gpu/drm/radeon/evergreen.c | 23 +++
drivers/gpu/drm/radeon/evergreend.h |3 +++
2 files changed, 26 insertions(+), 0 deletions(-)
diff --git a/drivers/gpu/drm/radeon/evergreen.c
b/drivers/gpu/drm/radeon/evergreen.c
index 38c500
https://bugs.freedesktop.org/show_bug.cgi?id=28630
--- Comment #7 from Chris Rankin 2010-06-29 13:37:28
PDT ---
(In reply to comment #4)
> I believe the "data" pointer is not valid.
That data pointer looks like it *used* to belong to a r300_context object that
has since been destroyed. Basicall
https://bugs.freedesktop.org/show_bug.cgi?id=28630
--- Comment #7 from Chris Rankin 2010-06-29
13:37:28 PDT ---
(In reply to comment #4)
> I believe the "data" pointer is not valid.
That data pointer looks like it *used* to belong to a r300_context object that
has since been destroyed. Basicall
https://bugs.freedesktop.org/show_bug.cgi?id=28630
--- Comment #6 from Chris Rankin 2010-06-29 12:05:36
PDT ---
(In reply to comment #4)
> I believe the "data" pointer is not valid.
Or possibly the context.flush field has not been assigned? I am having curious
success with this simple patch:
-
https://bugs.freedesktop.org/show_bug.cgi?id=28630
--- Comment #6 from Chris Rankin 2010-06-29
12:05:36 PDT ---
(In reply to comment #4)
> I believe the "data" pointer is not valid.
Or possibly the context.flush field has not been assigned? I am having curious
success with this simple patch:
-
https://bugs.freedesktop.org/show_bug.cgi?id=28630
--- Comment #5 from Chris Rankin 2010-06-29 11:38:15
PDT ---
(In reply to comment #4)
> I have committed some fixes, can you please test latest mesa git?
Backtrace:
=>0 0x (0x0039e9d0)
1 0x7dd5b61d radeon_drm_bufmgr_set_tiling+0xbc()
https://bugs.freedesktop.org/show_bug.cgi?id=28630
--- Comment #5 from Chris Rankin 2010-06-29
11:38:15 PDT ---
(In reply to comment #4)
> I have committed some fixes, can you please test latest mesa git?
Backtrace:
=>0 0x (0x0039e9d0)
1 0x7dd5b61d radeon_drm_bufmgr_set_tiling+0xbc()
21 matches
Mail list logo
