[Bug 56139] [bisected] kernel 3.7.0-rc1 breaks 6950 (CAYMAN)

2013-04-17 Thread Huacai Chen 
We have a similar problem: A HD6570(TURKS) card with RS780E chipset. When
booting, DVI output is good, but VGA output is black screen; after X
started, DVI is still good and VGA blinks forever. We have tried
3.4~3.9-rc7 kernel, all kernels after the commit "drm/radeon: properly
handle mc_stop/mc_resume on evergreen+" has the same issue.


On Mon, Nov 12, 2012 at 2:55 AM,  wrote:

>  Florian Mickler  changed bug 
> 56139
>  What Removed Added  CC   florian at mickler.org
>
>  *Comment # 25 on bug
> 56139  from Florian
> Mickler  *
>
> A patch referencing this bug report has been merged in Linux v3.7-rc5:
>
> commit 695ddeb457584a602f2ba117d08ce37cf6ec1589
> Author: Alex Deucher 
> Date:   Mon Nov 5 16:34:58 2012 +
>
> drm/radeon: fix typo in evergreen_mc_resume()
>
>  --
> You are receiving this mail because:
>
>- You are the assignee for the bug.
>
>
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel
>
>
-- next part --
An HTML attachment was scrubbed...
URL:

Re: [Bug 56139] [bisected] kernel 3.7.0-rc1 breaks 6950 (CAYMAN)

2013-04-17 Thread Huacai Chen 
We have a similar problem: A HD6570(TURKS) card with RS780E chipset. When
booting, DVI output is good, but VGA output is black screen; after X
started, DVI is still good and VGA blinks forever. We have tried
3.4~3.9-rc7 kernel, all kernels after the commit drm/radeon: properly
handle mc_stop/mc_resume on evergreen+ has the same issue.


On Mon, Nov 12, 2012 at 2:55 AM, bugzilla-dae...@freedesktop.org wrote:

  Florian Mickler flor...@mickler.org changed bug 
 56139https://bugs.freedesktop.org/show_bug.cgi?id=56139
  What Removed Added  CC   flor...@mickler.org

  *Comment # 25 https://bugs.freedesktop.org/show_bug.cgi?id=56139#c25on bug
 56139 https://bugs.freedesktop.org/show_bug.cgi?id=56139 from Florian
 Mickler flor...@mickler.org *

 A patch referencing this bug report has been merged in Linux v3.7-rc5:

 commit 695ddeb457584a602f2ba117d08ce37cf6ec1589
 Author: Alex Deucher alexander.deuc...@amd.com
 Date:   Mon Nov 5 16:34:58 2012 +

 drm/radeon: fix typo in evergreen_mc_resume()

  --
 You are receiving this mail because:

- You are the assignee for the bug.


 ___
 dri-devel mailing list
 dri-devel@lists.freedesktop.org
 http://lists.freedesktop.org/mailman/listinfo/dri-devel


___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 56139] [bisected] kernel 3.7.0-rc1 breaks 6950 (CAYMAN)

2012-11-11 Thread bugzilla-dae...@freedesktop.org 
https://bugs.freedesktop.org/show_bug.cgi?id=56139

Florian Mickler  changed:

   What|Removed |Added

 CC||florian at mickler.org

--- Comment #25 from Florian Mickler  ---
A patch referencing this bug report has been merged in Linux v3.7-rc5:

commit 695ddeb457584a602f2ba117d08ce37cf6ec1589
Author: Alex Deucher 
Date:   Mon Nov 5 16:34:58 2012 +

drm/radeon: fix typo in evergreen_mc_resume()

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:

[Bug 56139] [bisected] kernel 3.7.0-rc1 breaks 6950 (CAYMAN)

2012-11-11 Thread bugzilla-daemon 
https://bugs.freedesktop.org/show_bug.cgi?id=56139

Florian Mickler flor...@mickler.org changed:

   What|Removed |Added

 CC||flor...@mickler.org

--- Comment #25 from Florian Mickler flor...@mickler.org ---
A patch referencing this bug report has been merged in Linux v3.7-rc5:

commit 695ddeb457584a602f2ba117d08ce37cf6ec1589
Author: Alex Deucher alexander.deuc...@amd.com
Date:   Mon Nov 5 16:34:58 2012 +

drm/radeon: fix typo in evergreen_mc_resume()

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 56139] [bisected] kernel 3.7.0-rc1 breaks 6950 (CAYMAN)

2012-11-06 Thread bugzilla-dae...@freedesktop.org 
https://bugs.freedesktop.org/show_bug.cgi?id=56139

--- Comment #24 from Alexandre Demers  ---
I'll retest it with the latest two patches, but I think setting gfxpayload=text
prevents the bug. I know for sure that with the index patch, suspend/resume
cycle is fixed. Also, if I remove gfxpayload=keep completely, my monitor works
fine.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:

[Bug 56139] [bisected] kernel 3.7.0-rc1 breaks 6950 (CAYMAN)

2012-11-06 Thread bugzilla-dae...@freedesktop.org 
https://bugs.freedesktop.org/show_bug.cgi?id=56139

--- Comment #23 from Alex Deucher  ---
(In reply to comment #19)
> Should I try to combine patch 69113
> and patch 69370 with the others?

Worth a shot.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:

[Bug 56139] [bisected] kernel 3.7.0-rc1 breaks 6950 (CAYMAN)

2012-11-06 Thread bugzilla-dae...@freedesktop.org 
https://bugs.freedesktop.org/show_bug.cgi?id=56139

--- Comment #22 from Alexandre Demers  ---
(In reply to comment #21)
> (In reply to comment #19)
> > If I followed you correctly, setting bit 24 to "1" disables memory but keeps
> > the CRTC state as it is (hopefully in sync with the monitor). However, what
> > I see when grub2 kicks in with the "gfxpayload=keep" is an unsynced monitor.
> > Sometimes the display will be black, other times it will only appear in the
> > first couple of vertical lines, in others it will be vertically synced but
> > shifted to the right at half or at two third of the screen. In other words,
> > this really seems to be a sync problem. Should I try to combine patch 69113
> > and patch 69370 with the others?
> 
> Are you saying the monitor gets messed up when grub kicks in?  I.e., before
> the OS loads?  If so, that sounds like a grub issue.

I'll take some pictures or record a small video of what's going on. That will
be easier to understand. But yes, I'm beginning to think Grub2 is playing a bad
trick somewhere in there and is not playing nicely when handling the
framebuffer.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:

[Bug 56139] [bisected] kernel 3.7.0-rc1 breaks 6950 (CAYMAN)

2012-11-06 Thread bugzilla-dae...@freedesktop.org 
https://bugs.freedesktop.org/show_bug.cgi?id=56139

--- Comment #21 from Alex Deucher  ---
(In reply to comment #19)
> If I followed you correctly, setting bit 24 to "1" disables memory but keeps
> the CRTC state as it is (hopefully in sync with the monitor). However, what
> I see when grub2 kicks in with the "gfxpayload=keep" is an unsynced monitor.
> Sometimes the display will be black, other times it will only appear in the
> first couple of vertical lines, in others it will be vertically synced but
> shifted to the right at half or at two third of the screen. In other words,
> this really seems to be a sync problem. Should I try to combine patch 69113
> and patch 69370 with the others?

Are you saying the monitor gets messed up when grub kicks in?  I.e., before the
OS loads?  If so, that sounds like a grub issue.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:

[Bug 56139] [bisected] kernel 3.7.0-rc1 breaks 6950 (CAYMAN)

2012-11-06 Thread bugzilla-dae...@freedesktop.org 
https://bugs.freedesktop.org/show_bug.cgi?id=56139

--- Comment #20 from Alexandre Demers  ---
Should I have a look at how grub2 handles and talks to the kernel when using
gfxpayload=keep? A quick search shows this issue has been lurking for some time
(2010) with various radeon card
(https://bugs.launchpad.net/ubuntu/+source/grub2/+bug/605614,
http://frugalware.org/pipermail/frugalware-devel/2012-February/011500.html,
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=567245,
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=567393).

Could something be wrong when handling the framebuffer?

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:

[Bug 56139] [bisected] kernel 3.7.0-rc1 breaks 6950 (CAYMAN)

2012-11-06 Thread bugzilla-dae...@freedesktop.org 
https://bugs.freedesktop.org/show_bug.cgi?id=56139

--- Comment #19 from Alexandre Demers  ---
(In reply to comment #15)
> (In reply to comment #14)
> > (In reply to comment #12)
> > > (In reply to comment #11)
> > > > Found what is wrong with the help of a few printk and by comparing to 
> > > > the
> > > > code being replaced. All the logic is good (going through crtc, 
> > > > disabling
> > > > them, waiting for vblank) BUT setting "tmp |=
> > > > EVERGREEN_CRTC_DISP_READ_REQUEST_DISABLE;" is wrong.
> > > > 
> > > > If I do as in the previous code by setting tmp = 0 and then continuing 
> > > > with:
> > > > radeon_wait_for_vblank(rdev, i);
> > > > WREG32(EVERGREEN_CRTC_CONTROL + crtc_offsets[i], tmp);
> > > > everything works fine as before.
> > > > 
> > > > What is expected from "tmp |= 
> > > > EVERGREEN_CRTC_DISP_READ_REQUEST_DISABLE;"?
> > > > From what I read with printk, it is far from a 0 or a 1. Is this normal?
> > > 
> > > That's the most important bit in the entire sequence.  It's a bit field 
> > > in a
> > > register (bit 24 to be exact).  That bit is the bit that actually disables
> > > the requests from the display controller in the memory controller.  The
> > > whole point of this code is to disable all clients of the memory 
> > > controller
> > > (mc_stop()) so that we can change the location of vram within the GPU's
> > > address space.  Once we've moved vram, we can re-enable the clients
> > > (mc_resume()) so that they point to the new vram location.
> > 
> > Thank you, you confirmed what I had assumed. I had already understood that
> > it was the most important part in the sequence since it is associated to a
> > "write" instruction. I don't have the (decimal/binary) values with me right
> > now, but I'll be able to give you what was read from the register and from
> > the result returned from the bitwise OR assignment we are pushing in the
> > register. I'll confirm which bit(s) are changing. I'm sure the assignment
> > was setting one (or more) bit in the register to "1". Is bit 24 the only one
> > expected to change in the register? Should it be put to "1" or "0"?
> > 
> 
> Setting bit 24 to 1 disables memory requests from the display controller. 
> Setting bit 24 to 0, enables memory requests from the display controller.
> 
> > Another question: why were we setting "0" in the register before? By doing
> > so, we were setting the whole register to "0" (the whole 32 bits), right? If
> > I remember correctly, from what I saw yesterday with the help of printk, it
> > seems we are setting at least one bit to "1" in this register, which would
> > be the opposite of what was being done before and therefore of what was
> > working correctly with my video card. I'm just trying to understand why we
> > were doing something in the first place that was working correctly and that
> > was introduce to fix this problem in the first place, both at boot time for
> > grub (set gfxpayload=keep) and when suspending/resuming, and we are now
> > doing the opposite, thus breaking the code for some setups. Is it possible
> > that the bit/register logic is not the same for all Radeon GPUs? After all,
> > we already introduced a different path for DCE6.
> 
> Bit 0 for CRTC_CONTROL turns on/off the entire crtc.  If bit 0 is 0 the crtc
> is disabled.  If bit 0 is 1, the crtc is enabled.  If the crtc is disabled
> (bit 0 = 0) bit 24 is irrelevant.  There are separate bits to enable the
> crtc and disable memory requests since there are cases (like this one) where
> we want to keep the crtc timing running so that the monitor stays synced,
> but disable reads from memory so we can reconfigure the memory controller. 
> If we disable the crtc entirely, the monitor would lose sync and you would
> get additional flicker during boot up.  Ideally, eventually we'd like to
> just hand over control from the firmware without touching the display
> hardware so the user gets a flicker free boot experience.
> 
> DCE4 and 5 have the same logic and bit layout for these registers.  The
> logic is different on DCE6 chips.  On DCE6, the the memory controller
> request bit is now tied in with the crtc blanking bit.  When the crtc is
> blanked, memory requests are also disabled.

If I followed you correctly, setting bit 24 to "1" disables memory but keeps
the CRTC state as it is (hopefully in sync with the monitor). However, what I
see when grub2 kicks in with the "gfxpayload=keep" is an unsynced monitor.
Sometimes the display will be black, other times it will only appear in the
first couple of vertical lines, in others it will be vertically synced but
shifted to the right at half or at two third of the screen. In other words,
this really seems to be a sync problem. Should I try to combine patch 69113 and
patch 69370 with the others?

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:

[Bug 56139] [bisected] kernel 3.7.0-rc1 breaks 6950 (CAYMAN)

2012-11-06 Thread bugzilla-dae...@freedesktop.org 
https://bugs.freedesktop.org/show_bug.cgi?id=56139

--- Comment #18 from Alexandre Demers  ---
(In reply to comment #16)
> Created attachment 69573 [details] [review]
> possible fix
> 
> Actually, I think I found the problem.  Missing index in mc_resume().

This seems to fix my resume problem I was experiencing where the display would
come up, but then it would crash. However, it doesn't solve the boot/grub2 bug.

So, this patch should be kept (but not for the current bug).

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:

[Bug 56139] [bisected] kernel 3.7.0-rc1 breaks 6950 (CAYMAN)

2012-11-06 Thread bugzilla-daemon 
https://bugs.freedesktop.org/show_bug.cgi?id=56139

--- Comment #20 from Alexandre Demers alexandre.f.dem...@gmail.com ---
Should I have a look at how grub2 handles and talks to the kernel when using
gfxpayload=keep? A quick search shows this issue has been lurking for some time
(2010) with various radeon card
(https://bugs.launchpad.net/ubuntu/+source/grub2/+bug/605614,
http://frugalware.org/pipermail/frugalware-devel/2012-February/011500.html,
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=567245,
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=567393).

Could something be wrong when handling the framebuffer?

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 56139] [bisected] kernel 3.7.0-rc1 breaks 6950 (CAYMAN)

2012-11-06 Thread bugzilla-daemon 
https://bugs.freedesktop.org/show_bug.cgi?id=56139

--- Comment #21 from Alex Deucher ag...@yahoo.com ---
(In reply to comment #19)
 If I followed you correctly, setting bit 24 to 1 disables memory but keeps
 the CRTC state as it is (hopefully in sync with the monitor). However, what
 I see when grub2 kicks in with the gfxpayload=keep is an unsynced monitor.
 Sometimes the display will be black, other times it will only appear in the
 first couple of vertical lines, in others it will be vertically synced but
 shifted to the right at half or at two third of the screen. In other words,
 this really seems to be a sync problem. Should I try to combine patch 69113
 and patch 69370 with the others?

Are you saying the monitor gets messed up when grub kicks in?  I.e., before the
OS loads?  If so, that sounds like a grub issue.

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 56139] [bisected] kernel 3.7.0-rc1 breaks 6950 (CAYMAN)

2012-11-06 Thread bugzilla-daemon 
https://bugs.freedesktop.org/show_bug.cgi?id=56139

--- Comment #22 from Alexandre Demers alexandre.f.dem...@gmail.com ---
(In reply to comment #21)
 (In reply to comment #19)
  If I followed you correctly, setting bit 24 to 1 disables memory but keeps
  the CRTC state as it is (hopefully in sync with the monitor). However, what
  I see when grub2 kicks in with the gfxpayload=keep is an unsynced monitor.
  Sometimes the display will be black, other times it will only appear in the
  first couple of vertical lines, in others it will be vertically synced but
  shifted to the right at half or at two third of the screen. In other words,
  this really seems to be a sync problem. Should I try to combine patch 69113
  and patch 69370 with the others?
 
 Are you saying the monitor gets messed up when grub kicks in?  I.e., before
 the OS loads?  If so, that sounds like a grub issue.

I'll take some pictures or record a small video of what's going on. That will
be easier to understand. But yes, I'm beginning to think Grub2 is playing a bad
trick somewhere in there and is not playing nicely when handling the
framebuffer.

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 56139] [bisected] kernel 3.7.0-rc1 breaks 6950 (CAYMAN)

2012-11-06 Thread bugzilla-daemon 
https://bugs.freedesktop.org/show_bug.cgi?id=56139

--- Comment #23 from Alex Deucher ag...@yahoo.com ---
(In reply to comment #19)
 Should I try to combine patch 69113
 and patch 69370 with the others?

Worth a shot.

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 56139] [bisected] kernel 3.7.0-rc1 breaks 6950 (CAYMAN)

2012-11-06 Thread bugzilla-daemon 
https://bugs.freedesktop.org/show_bug.cgi?id=56139

--- Comment #24 from Alexandre Demers alexandre.f.dem...@gmail.com ---
I'll retest it with the latest two patches, but I think setting gfxpayload=text
prevents the bug. I know for sure that with the index patch, suspend/resume
cycle is fixed. Also, if I remove gfxpayload=keep completely, my monitor works
fine.

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 56139] [bisected] kernel 3.7.0-rc1 breaks 6950 (CAYMAN)

2012-11-05 Thread bugzilla-dae...@freedesktop.org 
https://bugs.freedesktop.org/show_bug.cgi?id=56139

--- Comment #17 from Alexandre Demers  ---
I'm about to test patches. But before, as promised, here are the values
retrieved read and written to the registers. By the way, I have only a single
monitor.
tmp = RREG32(EVERGREEN_CRTC_CONTROL + crtc_offsets[i]); -> 272696081 (0001 
0100 0001  0011 0001 0001)
tmp |= EVERGREEN_CRTC_DISP_READ_REQUEST_DISABLE; -> 289473297 (0001 0001 0100
0001  0011 0001 0001)

So, it is set as you explained me earlier. I'll be back soon with some news
from the patches.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:

[Bug 56139] [bisected] kernel 3.7.0-rc1 breaks 6950 (CAYMAN)

2012-11-05 Thread bugzilla-dae...@freedesktop.org 
https://bugs.freedesktop.org/show_bug.cgi?id=56139

--- Comment #16 from Alex Deucher  ---
Created attachment 69573
  --> https://bugs.freedesktop.org/attachment.cgi?id=69573=edit
possible fix

Actually, I think I found the problem.  Missing index in mc_resume().

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:

[Bug 56139] [bisected] kernel 3.7.0-rc1 breaks 6950 (CAYMAN)

2012-11-05 Thread bugzilla-dae...@freedesktop.org 
https://bugs.freedesktop.org/show_bug.cgi?id=56139

--- Comment #15 from Alex Deucher  ---
(In reply to comment #14)
> (In reply to comment #12)
> > (In reply to comment #11)
> > > Found what is wrong with the help of a few printk and by comparing to the
> > > code being replaced. All the logic is good (going through crtc, disabling
> > > them, waiting for vblank) BUT setting "tmp |=
> > > EVERGREEN_CRTC_DISP_READ_REQUEST_DISABLE;" is wrong.
> > > 
> > > If I do as in the previous code by setting tmp = 0 and then continuing 
> > > with:
> > > radeon_wait_for_vblank(rdev, i);
> > > WREG32(EVERGREEN_CRTC_CONTROL + crtc_offsets[i], tmp);
> > > everything works fine as before.
> > > 
> > > What is expected from "tmp |= EVERGREEN_CRTC_DISP_READ_REQUEST_DISABLE;"?
> > > From what I read with printk, it is far from a 0 or a 1. Is this normal?
> > 
> > That's the most important bit in the entire sequence.  It's a bit field in a
> > register (bit 24 to be exact).  That bit is the bit that actually disables
> > the requests from the display controller in the memory controller.  The
> > whole point of this code is to disable all clients of the memory controller
> > (mc_stop()) so that we can change the location of vram within the GPU's
> > address space.  Once we've moved vram, we can re-enable the clients
> > (mc_resume()) so that they point to the new vram location.
> 
> Thank you, you confirmed what I had assumed. I had already understood that
> it was the most important part in the sequence since it is associated to a
> "write" instruction. I don't have the (decimal/binary) values with me right
> now, but I'll be able to give you what was read from the register and from
> the result returned from the bitwise OR assignment we are pushing in the
> register. I'll confirm which bit(s) are changing. I'm sure the assignment
> was setting one (or more) bit in the register to "1". Is bit 24 the only one
> expected to change in the register? Should it be put to "1" or "0"?
> 

Setting bit 24 to 1 disables memory requests from the display controller. 
Setting bit 24 to 0, enables memory requests from the display controller.

> Another question: why were we setting "0" in the register before? By doing
> so, we were setting the whole register to "0" (the whole 32 bits), right? If
> I remember correctly, from what I saw yesterday with the help of printk, it
> seems we are setting at least one bit to "1" in this register, which would
> be the opposite of what was being done before and therefore of what was
> working correctly with my video card. I'm just trying to understand why we
> were doing something in the first place that was working correctly and that
> was introduce to fix this problem in the first place, both at boot time for
> grub (set gfxpayload=keep) and when suspending/resuming, and we are now
> doing the opposite, thus breaking the code for some setups. Is it possible
> that the bit/register logic is not the same for all Radeon GPUs? After all,
> we already introduced a different path for DCE6.

Bit 0 for CRTC_CONTROL turns on/off the entire crtc.  If bit 0 is 0 the crtc is
disabled.  If bit 0 is 1, the crtc is enabled.  If the crtc is disabled (bit 0
= 0) bit 24 is irrelevant.  There are separate bits to enable the crtc and
disable memory requests since there are cases (like this one) where we want to
keep the crtc timing running so that the monitor stays synced, but disable
reads from memory so we can reconfigure the memory controller.  If we disable
the crtc entirely, the monitor would lose sync and you would get additional
flicker during boot up.  Ideally, eventually we'd like to just hand over
control from the firmware without touching the display hardware so the user
gets a flicker free boot experience.

DCE4 and 5 have the same logic and bit layout for these registers.  The logic
is different on DCE6 chips.  On DCE6, the the memory controller request bit is
now tied in with the crtc blanking bit.  When the crtc is blanked, memory
requests are also disabled.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:

[Bug 56139] [bisected] kernel 3.7.0-rc1 breaks 6950 (CAYMAN)

2012-11-05 Thread bugzilla-dae...@freedesktop.org 
https://bugs.freedesktop.org/show_bug.cgi?id=56139

--- Comment #14 from Alexandre Demers  ---
(In reply to comment #12)
> (In reply to comment #11)
> > Found what is wrong with the help of a few printk and by comparing to the
> > code being replaced. All the logic is good (going through crtc, disabling
> > them, waiting for vblank) BUT setting "tmp |=
> > EVERGREEN_CRTC_DISP_READ_REQUEST_DISABLE;" is wrong.
> > 
> > If I do as in the previous code by setting tmp = 0 and then continuing with:
> > radeon_wait_for_vblank(rdev, i);
> > WREG32(EVERGREEN_CRTC_CONTROL + crtc_offsets[i], tmp);
> > everything works fine as before.
> > 
> > What is expected from "tmp |= EVERGREEN_CRTC_DISP_READ_REQUEST_DISABLE;"?
> > From what I read with printk, it is far from a 0 or a 1. Is this normal?
> 
> That's the most important bit in the entire sequence.  It's a bit field in a
> register (bit 24 to be exact).  That bit is the bit that actually disables
> the requests from the display controller in the memory controller.  The
> whole point of this code is to disable all clients of the memory controller
> (mc_stop()) so that we can change the location of vram within the GPU's
> address space.  Once we've moved vram, we can re-enable the clients
> (mc_resume()) so that they point to the new vram location.

Thank you, you confirmed what I had assumed. I had already understood that it
was the most important part in the sequence since it is associated to a "write"
instruction. I don't have the (decimal/binary) values with me right now, but
I'll be able to give you what was read from the register and from the result
returned from the bitwise OR assignment we are pushing in the register. I'll
confirm which bit(s) are changing. I'm sure the assignment was setting one (or
more) bit in the register to "1". Is bit 24 the only one expected to change in
the register? Should it be put to "1" or "0"?

Another question: why were we setting "0" in the register before? By doing so,
we were setting the whole register to "0" (the whole 32 bits), right? If I
remember correctly, from what I saw yesterday with the help of printk, it seems
we are setting at least one bit to "1" in this register, which would be the
opposite of what was being done before and therefore of what was working
correctly with my video card. I'm just trying to understand why we were doing
something in the first place that was working correctly and that was introduce
to fix this problem in the first place, both at boot time for grub (set
gfxpayload=keep) and when suspending/resuming, and we are now doing the
opposite, thus breaking the code for some setups. Is it possible that the
bit/register logic is not the same for all Radeon GPUs? After all, we already
introduced a different path for DCE6.

I'll also try your patch when I'll get home tonight.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:

[Bug 56139] [bisected] kernel 3.7.0-rc1 breaks 6950 (CAYMAN)

2012-11-05 Thread bugzilla-dae...@freedesktop.org 
https://bugs.freedesktop.org/show_bug.cgi?id=56139

--- Comment #13 from Alex Deucher  ---
Created attachment 69564
  --> https://bugs.freedesktop.org/attachment.cgi?id=69564=edit
possible fix

Slightly adjusted wait for vblank function.  Maybe this will help?

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:

[Bug 56139] [bisected] kernel 3.7.0-rc1 breaks 6950 (CAYMAN)

2012-11-05 Thread bugzilla-dae...@freedesktop.org 
https://bugs.freedesktop.org/show_bug.cgi?id=56139

--- Comment #12 from Alex Deucher  ---
(In reply to comment #11)
> Found what is wrong with the help of a few printk and by comparing to the
> code being replaced. All the logic is good (going through crtc, disabling
> them, waiting for vblank) BUT setting "tmp |=
> EVERGREEN_CRTC_DISP_READ_REQUEST_DISABLE;" is wrong.
> 
> If I do as in the previous code by setting tmp = 0 and then continuing with:
> radeon_wait_for_vblank(rdev, i);
> WREG32(EVERGREEN_CRTC_CONTROL + crtc_offsets[i], tmp);
> everything works fine as before.
> 
> What is expected from "tmp |= EVERGREEN_CRTC_DISP_READ_REQUEST_DISABLE;"?
> From what I read with printk, it is far from a 0 or a 1. Is this normal?

That's the most important bit in the entire sequence.  It's a bit field in a
register (bit 24 to be exact).  That bit is the bit that actually disables the
requests from the display controller in the memory controller.  The whole point
of this code is to disable all clients of the memory controller (mc_stop()) so
that we can change the location of vram within the GPU's address space.  Once
we've moved vram, we can re-enable the clients (mc_resume()) so that they point
to the new vram location.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:

[Bug 56139] [bisected] kernel 3.7.0-rc1 breaks 6950 (CAYMAN)

2012-11-05 Thread bugzilla-dae...@freedesktop.org 
https://bugs.freedesktop.org/show_bug.cgi?id=56139

--- Comment #11 from Alexandre Demers  ---
Found what is wrong with the help of a few printk and by comparing to the code
being replaced. All the logic is good (going through crtc, disabling them,
waiting for vblank) BUT setting "tmp |=
EVERGREEN_CRTC_DISP_READ_REQUEST_DISABLE;" is wrong.

If I do as in the previous code by setting tmp = 0 and then continuing with:
radeon_wait_for_vblank(rdev, i);
WREG32(EVERGREEN_CRTC_CONTROL + crtc_offsets[i], tmp);
everything works fine as before.

What is expected from "tmp |= EVERGREEN_CRTC_DISP_READ_REQUEST_DISABLE;"? From
what I read with printk, it is far from a 0 or a 1. Is this normal?

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:

[Bug 56139] [bisected] kernel 3.7.0-rc1 breaks 6950 (CAYMAN)

2012-11-05 Thread bugzilla-daemon 
https://bugs.freedesktop.org/show_bug.cgi?id=56139

--- Comment #12 from Alex Deucher ag...@yahoo.com ---
(In reply to comment #11)
 Found what is wrong with the help of a few printk and by comparing to the
 code being replaced. All the logic is good (going through crtc, disabling
 them, waiting for vblank) BUT setting tmp |=
 EVERGREEN_CRTC_DISP_READ_REQUEST_DISABLE; is wrong.
 
 If I do as in the previous code by setting tmp = 0 and then continuing with:
 radeon_wait_for_vblank(rdev, i);
 WREG32(EVERGREEN_CRTC_CONTROL + crtc_offsets[i], tmp);
 everything works fine as before.
 
 What is expected from tmp |= EVERGREEN_CRTC_DISP_READ_REQUEST_DISABLE;?
 From what I read with printk, it is far from a 0 or a 1. Is this normal?

That's the most important bit in the entire sequence.  It's a bit field in a
register (bit 24 to be exact).  That bit is the bit that actually disables the
requests from the display controller in the memory controller.  The whole point
of this code is to disable all clients of the memory controller (mc_stop()) so
that we can change the location of vram within the GPU's address space.  Once
we've moved vram, we can re-enable the clients (mc_resume()) so that they point
to the new vram location.

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 56139] [bisected] kernel 3.7.0-rc1 breaks 6950 (CAYMAN)

2012-11-05 Thread bugzilla-daemon 
https://bugs.freedesktop.org/show_bug.cgi?id=56139

--- Comment #13 from Alex Deucher ag...@yahoo.com ---
Created attachment 69564
  -- https://bugs.freedesktop.org/attachment.cgi?id=69564action=edit
possible fix

Slightly adjusted wait for vblank function.  Maybe this will help?

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 56139] [bisected] kernel 3.7.0-rc1 breaks 6950 (CAYMAN)

2012-11-05 Thread bugzilla-daemon 
https://bugs.freedesktop.org/show_bug.cgi?id=56139

--- Comment #14 from Alexandre Demers alexandre.f.dem...@gmail.com ---
(In reply to comment #12)
 (In reply to comment #11)
  Found what is wrong with the help of a few printk and by comparing to the
  code being replaced. All the logic is good (going through crtc, disabling
  them, waiting for vblank) BUT setting tmp |=
  EVERGREEN_CRTC_DISP_READ_REQUEST_DISABLE; is wrong.
  
  If I do as in the previous code by setting tmp = 0 and then continuing with:
  radeon_wait_for_vblank(rdev, i);
  WREG32(EVERGREEN_CRTC_CONTROL + crtc_offsets[i], tmp);
  everything works fine as before.
  
  What is expected from tmp |= EVERGREEN_CRTC_DISP_READ_REQUEST_DISABLE;?
  From what I read with printk, it is far from a 0 or a 1. Is this normal?
 
 That's the most important bit in the entire sequence.  It's a bit field in a
 register (bit 24 to be exact).  That bit is the bit that actually disables
 the requests from the display controller in the memory controller.  The
 whole point of this code is to disable all clients of the memory controller
 (mc_stop()) so that we can change the location of vram within the GPU's
 address space.  Once we've moved vram, we can re-enable the clients
 (mc_resume()) so that they point to the new vram location.

Thank you, you confirmed what I had assumed. I had already understood that it
was the most important part in the sequence since it is associated to a write
instruction. I don't have the (decimal/binary) values with me right now, but
I'll be able to give you what was read from the register and from the result
returned from the bitwise OR assignment we are pushing in the register. I'll
confirm which bit(s) are changing. I'm sure the assignment was setting one (or
more) bit in the register to 1. Is bit 24 the only one expected to change in
the register? Should it be put to 1 or 0?

Another question: why were we setting 0 in the register before? By doing so,
we were setting the whole register to 0 (the whole 32 bits), right? If I
remember correctly, from what I saw yesterday with the help of printk, it seems
we are setting at least one bit to 1 in this register, which would be the
opposite of what was being done before and therefore of what was working
correctly with my video card. I'm just trying to understand why we were doing
something in the first place that was working correctly and that was introduce
to fix this problem in the first place, both at boot time for grub (set
gfxpayload=keep) and when suspending/resuming, and we are now doing the
opposite, thus breaking the code for some setups. Is it possible that the
bit/register logic is not the same for all Radeon GPUs? After all, we already
introduced a different path for DCE6.

I'll also try your patch when I'll get home tonight.

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 56139] [bisected] kernel 3.7.0-rc1 breaks 6950 (CAYMAN)

2012-11-05 Thread bugzilla-daemon 
https://bugs.freedesktop.org/show_bug.cgi?id=56139

--- Comment #15 from Alex Deucher ag...@yahoo.com ---
(In reply to comment #14)
 (In reply to comment #12)
  (In reply to comment #11)
   Found what is wrong with the help of a few printk and by comparing to the
   code being replaced. All the logic is good (going through crtc, disabling
   them, waiting for vblank) BUT setting tmp |=
   EVERGREEN_CRTC_DISP_READ_REQUEST_DISABLE; is wrong.
   
   If I do as in the previous code by setting tmp = 0 and then continuing 
   with:
   radeon_wait_for_vblank(rdev, i);
   WREG32(EVERGREEN_CRTC_CONTROL + crtc_offsets[i], tmp);
   everything works fine as before.
   
   What is expected from tmp |= EVERGREEN_CRTC_DISP_READ_REQUEST_DISABLE;?
   From what I read with printk, it is far from a 0 or a 1. Is this normal?
  
  That's the most important bit in the entire sequence.  It's a bit field in a
  register (bit 24 to be exact).  That bit is the bit that actually disables
  the requests from the display controller in the memory controller.  The
  whole point of this code is to disable all clients of the memory controller
  (mc_stop()) so that we can change the location of vram within the GPU's
  address space.  Once we've moved vram, we can re-enable the clients
  (mc_resume()) so that they point to the new vram location.
 
 Thank you, you confirmed what I had assumed. I had already understood that
 it was the most important part in the sequence since it is associated to a
 write instruction. I don't have the (decimal/binary) values with me right
 now, but I'll be able to give you what was read from the register and from
 the result returned from the bitwise OR assignment we are pushing in the
 register. I'll confirm which bit(s) are changing. I'm sure the assignment
 was setting one (or more) bit in the register to 1. Is bit 24 the only one
 expected to change in the register? Should it be put to 1 or 0?
 

Setting bit 24 to 1 disables memory requests from the display controller. 
Setting bit 24 to 0, enables memory requests from the display controller.

 Another question: why were we setting 0 in the register before? By doing
 so, we were setting the whole register to 0 (the whole 32 bits), right? If
 I remember correctly, from what I saw yesterday with the help of printk, it
 seems we are setting at least one bit to 1 in this register, which would
 be the opposite of what was being done before and therefore of what was
 working correctly with my video card. I'm just trying to understand why we
 were doing something in the first place that was working correctly and that
 was introduce to fix this problem in the first place, both at boot time for
 grub (set gfxpayload=keep) and when suspending/resuming, and we are now
 doing the opposite, thus breaking the code for some setups. Is it possible
 that the bit/register logic is not the same for all Radeon GPUs? After all,
 we already introduced a different path for DCE6.

Bit 0 for CRTC_CONTROL turns on/off the entire crtc.  If bit 0 is 0 the crtc is
disabled.  If bit 0 is 1, the crtc is enabled.  If the crtc is disabled (bit 0
= 0) bit 24 is irrelevant.  There are separate bits to enable the crtc and
disable memory requests since there are cases (like this one) where we want to
keep the crtc timing running so that the monitor stays synced, but disable
reads from memory so we can reconfigure the memory controller.  If we disable
the crtc entirely, the monitor would lose sync and you would get additional
flicker during boot up.  Ideally, eventually we'd like to just hand over
control from the firmware without touching the display hardware so the user
gets a flicker free boot experience.

DCE4 and 5 have the same logic and bit layout for these registers.  The logic
is different on DCE6 chips.  On DCE6, the the memory controller request bit is
now tied in with the crtc blanking bit.  When the crtc is blanked, memory
requests are also disabled.

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 56139] [bisected] kernel 3.7.0-rc1 breaks 6950 (CAYMAN)

2012-11-05 Thread bugzilla-daemon 
https://bugs.freedesktop.org/show_bug.cgi?id=56139

--- Comment #16 from Alex Deucher ag...@yahoo.com ---
Created attachment 69573
  -- https://bugs.freedesktop.org/attachment.cgi?id=69573action=edit
possible fix

Actually, I think I found the problem.  Missing index in mc_resume().

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 56139] [bisected] kernel 3.7.0-rc1 breaks 6950 (CAYMAN)

2012-11-05 Thread bugzilla-daemon 
https://bugs.freedesktop.org/show_bug.cgi?id=56139

--- Comment #17 from Alexandre Demers alexandre.f.dem...@gmail.com ---
I'm about to test patches. But before, as promised, here are the values
retrieved read and written to the registers. By the way, I have only a single
monitor.
tmp = RREG32(EVERGREEN_CRTC_CONTROL + crtc_offsets[i]); - 272696081 (0001 
0100 0001  0011 0001 0001)
tmp |= EVERGREEN_CRTC_DISP_READ_REQUEST_DISABLE; - 289473297 (0001 0001 0100
0001  0011 0001 0001)

So, it is set as you explained me earlier. I'll be back soon with some news
from the patches.

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 56139] [bisected] kernel 3.7.0-rc1 breaks 6950 (CAYMAN)

2012-11-05 Thread bugzilla-daemon 
https://bugs.freedesktop.org/show_bug.cgi?id=56139

--- Comment #18 from Alexandre Demers alexandre.f.dem...@gmail.com ---
(In reply to comment #16)
 Created attachment 69573 [details] [review]
 possible fix
 
 Actually, I think I found the problem.  Missing index in mc_resume().

This seems to fix my resume problem I was experiencing where the display would
come up, but then it would crash. However, it doesn't solve the boot/grub2 bug.

So, this patch should be kept (but not for the current bug).

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 56139] [bisected] kernel 3.7.0-rc1 breaks 6950 (CAYMAN)

2012-11-05 Thread bugzilla-daemon 
https://bugs.freedesktop.org/show_bug.cgi?id=56139

--- Comment #19 from Alexandre Demers alexandre.f.dem...@gmail.com ---
(In reply to comment #15)
 (In reply to comment #14)
  (In reply to comment #12)
   (In reply to comment #11)
Found what is wrong with the help of a few printk and by comparing to 
the
code being replaced. All the logic is good (going through crtc, 
disabling
them, waiting for vblank) BUT setting tmp |=
EVERGREEN_CRTC_DISP_READ_REQUEST_DISABLE; is wrong.

If I do as in the previous code by setting tmp = 0 and then continuing 
with:
radeon_wait_for_vblank(rdev, i);
WREG32(EVERGREEN_CRTC_CONTROL + crtc_offsets[i], tmp);
everything works fine as before.

What is expected from tmp |= 
EVERGREEN_CRTC_DISP_READ_REQUEST_DISABLE;?
From what I read with printk, it is far from a 0 or a 1. Is this normal?
   
   That's the most important bit in the entire sequence.  It's a bit field 
   in a
   register (bit 24 to be exact).  That bit is the bit that actually disables
   the requests from the display controller in the memory controller.  The
   whole point of this code is to disable all clients of the memory 
   controller
   (mc_stop()) so that we can change the location of vram within the GPU's
   address space.  Once we've moved vram, we can re-enable the clients
   (mc_resume()) so that they point to the new vram location.
  
  Thank you, you confirmed what I had assumed. I had already understood that
  it was the most important part in the sequence since it is associated to a
  write instruction. I don't have the (decimal/binary) values with me right
  now, but I'll be able to give you what was read from the register and from
  the result returned from the bitwise OR assignment we are pushing in the
  register. I'll confirm which bit(s) are changing. I'm sure the assignment
  was setting one (or more) bit in the register to 1. Is bit 24 the only one
  expected to change in the register? Should it be put to 1 or 0?
  
 
 Setting bit 24 to 1 disables memory requests from the display controller. 
 Setting bit 24 to 0, enables memory requests from the display controller.
 
  Another question: why were we setting 0 in the register before? By doing
  so, we were setting the whole register to 0 (the whole 32 bits), right? If
  I remember correctly, from what I saw yesterday with the help of printk, it
  seems we are setting at least one bit to 1 in this register, which would
  be the opposite of what was being done before and therefore of what was
  working correctly with my video card. I'm just trying to understand why we
  were doing something in the first place that was working correctly and that
  was introduce to fix this problem in the first place, both at boot time for
  grub (set gfxpayload=keep) and when suspending/resuming, and we are now
  doing the opposite, thus breaking the code for some setups. Is it possible
  that the bit/register logic is not the same for all Radeon GPUs? After all,
  we already introduced a different path for DCE6.
 
 Bit 0 for CRTC_CONTROL turns on/off the entire crtc.  If bit 0 is 0 the crtc
 is disabled.  If bit 0 is 1, the crtc is enabled.  If the crtc is disabled
 (bit 0 = 0) bit 24 is irrelevant.  There are separate bits to enable the
 crtc and disable memory requests since there are cases (like this one) where
 we want to keep the crtc timing running so that the monitor stays synced,
 but disable reads from memory so we can reconfigure the memory controller. 
 If we disable the crtc entirely, the monitor would lose sync and you would
 get additional flicker during boot up.  Ideally, eventually we'd like to
 just hand over control from the firmware without touching the display
 hardware so the user gets a flicker free boot experience.
 
 DCE4 and 5 have the same logic and bit layout for these registers.  The
 logic is different on DCE6 chips.  On DCE6, the the memory controller
 request bit is now tied in with the crtc blanking bit.  When the crtc is
 blanked, memory requests are also disabled.

If I followed you correctly, setting bit 24 to 1 disables memory but keeps
the CRTC state as it is (hopefully in sync with the monitor). However, what I
see when grub2 kicks in with the gfxpayload=keep is an unsynced monitor.
Sometimes the display will be black, other times it will only appear in the
first couple of vertical lines, in others it will be vertically synced but
shifted to the right at half or at two third of the screen. In other words,
this really seems to be a sync problem. Should I try to combine patch 69113 and
patch 69370 with the others?

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 56139] [bisected] kernel 3.7.0-rc1 breaks 6950 (CAYMAN)

2012-11-04 Thread bugzilla-daemon 
https://bugs.freedesktop.org/show_bug.cgi?id=56139

--- Comment #11 from Alexandre Demers alexandre.f.dem...@gmail.com ---
Found what is wrong with the help of a few printk and by comparing to the code
being replaced. All the logic is good (going through crtc, disabling them,
waiting for vblank) BUT setting tmp |=
EVERGREEN_CRTC_DISP_READ_REQUEST_DISABLE; is wrong.

If I do as in the previous code by setting tmp = 0 and then continuing with:
radeon_wait_for_vblank(rdev, i);
WREG32(EVERGREEN_CRTC_CONTROL + crtc_offsets[i], tmp);
everything works fine as before.

What is expected from tmp |= EVERGREEN_CRTC_DISP_READ_REQUEST_DISABLE;? From
what I read with printk, it is far from a 0 or a 1. Is this normal?

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 56139] [bisected] kernel 3.7.0-rc1 breaks 6950 (CAYMAN)

2012-11-01 Thread bugzilla-dae...@freedesktop.org 
https://bugs.freedesktop.org/show_bug.cgi?id=56139

--- Comment #10 from Alexandre Demers  ---
The good news is: the code under resume() is not to be blamed for the lock
after coming back from suspend.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:

[Bug 56139] [bisected] kernel 3.7.0-rc1 breaks 6950 (CAYMAN)

2012-11-01 Thread bugzilla-dae...@freedesktop.org 
https://bugs.freedesktop.org/show_bug.cgi?id=56139

--- Comment #9 from Alexandre Demers  ---
(In reply to comment #8)
> Created attachment 69370 [details] [review]
> possible fix
> 
> (In reply to comment #7)
> > Alex, would it be possible to print what is going on or if an error occurred
> > in evergreen_mc_stop()?
> > 
> > I see four things that could be going on:
> > 1- we are not using the right path for CAYMAN -> (ASIC_IS_DCE6(rdev));
> 
> cayman is DCE5.  It is using the correct code path.
> 
> > 2- lock mechanism synced with vblank is not working properly;
> 
> Locking makes updates atomic rather than double buffered.
> 
> > 3- all the registers should be locked at the same time, then all modified
> > and finally unlocked together, which is not done with the for loop where we
> > move through each at a time;
> 
> doesn't matter.
> 
> > 4- we are not setting the right registers.
> 
> The existing sequence should be correct.  It's the same sequence our hw team
> recommends.  I can't reproduce this on my cayman boards unfortunately and
> this patch fixes the exact same problem you are having for a number of other
> people :/
> 
> Maybe an issue with the icon or cursor, but I think those should be disabled
> when we disable mem requests in the crtc.  Does this patch help?

Not working either. Also, with 3.7.0-rc3 + this patch, the computer freezes
when coming back from suspend. I see Gnome-Shell for a couple of seconds, then
some garbage and it stops. Kernel 3.6 works fine on that matter. I'll test with
my split patches to see if it is caused by the same commit.

So, pretty much back to square 1, wherever that is.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:

[Bug 56139] [bisected] kernel 3.7.0-rc1 breaks 6950 (CAYMAN)

2012-11-01 Thread bugzilla-daemon 
https://bugs.freedesktop.org/show_bug.cgi?id=56139

--- Comment #10 from Alexandre Demers alexandre.f.dem...@gmail.com ---
The good news is: the code under resume() is not to be blamed for the lock
after coming back from suspend.

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 56139] [bisected] kernel 3.7.0-rc1 breaks 6950 (CAYMAN)

2012-10-31 Thread bugzilla-dae...@freedesktop.org 
https://bugs.freedesktop.org/show_bug.cgi?id=56139

--- Comment #8 from Alex Deucher  ---
Created attachment 69370
  --> https://bugs.freedesktop.org/attachment.cgi?id=69370=edit
possible fix

(In reply to comment #7)
> Alex, would it be possible to print what is going on or if an error occurred
> in evergreen_mc_stop()?
> 
> I see four things that could be going on:
> 1- we are not using the right path for CAYMAN -> (ASIC_IS_DCE6(rdev));

cayman is DCE5.  It is using the correct code path.

> 2- lock mechanism synced with vblank is not working properly;

Locking makes updates atomic rather than double buffered.

> 3- all the registers should be locked at the same time, then all modified
> and finally unlocked together, which is not done with the for loop where we
> move through each at a time;

doesn't matter.

> 4- we are not setting the right registers.

The existing sequence should be correct.  It's the same sequence our hw team
recommends.  I can't reproduce this on my cayman boards unfortunately and this
patch fixes the exact same problem you are having for a number of other people
:/

Maybe an issue with the icon or cursor, but I think those should be disabled
when we disable mem requests in the crtc.  Does this patch help?

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:

[Bug 56139] [bisected] kernel 3.7.0-rc1 breaks 6950 (CAYMAN)

2012-10-31 Thread bugzilla-dae...@freedesktop.org 
https://bugs.freedesktop.org/show_bug.cgi?id=56139

--- Comment #7 from Alexandre Demers  ---
Alex, would it be possible to print what is going on or if an error occurred in
evergreen_mc_stop()?

I see four things that could be going on:
1- we are not using the right path for CAYMAN -> (ASIC_IS_DCE6(rdev));
2- lock mechanism synced with vblank is not working properly;
3- all the registers should be locked at the same time, then all modified and
finally unlocked together, which is not done with the for loop where we move
through each at a time;
4- we are not setting the right registers.

What do you think?

I can test and investigate 1, 3 and 4. But what about 2?

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:

[Bug 56139] [bisected] kernel 3.7.0-rc1 breaks 6950 (CAYMAN)

2012-10-31 Thread bugzilla-daemon 
https://bugs.freedesktop.org/show_bug.cgi?id=56139

--- Comment #7 from Alexandre Demers alexandre.f.dem...@gmail.com ---
Alex, would it be possible to print what is going on or if an error occurred in
evergreen_mc_stop()?

I see four things that could be going on:
1- we are not using the right path for CAYMAN - (ASIC_IS_DCE6(rdev));
2- lock mechanism synced with vblank is not working properly;
3- all the registers should be locked at the same time, then all modified and
finally unlocked together, which is not done with the for loop where we move
through each at a time;
4- we are not setting the right registers.

What do you think?

I can test and investigate 1, 3 and 4. But what about 2?

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 56139] [bisected] kernel 3.7.0-rc1 breaks 6950 (CAYMAN)

2012-10-31 Thread bugzilla-daemon 
https://bugs.freedesktop.org/show_bug.cgi?id=56139

--- Comment #8 from Alex Deucher ag...@yahoo.com ---
Created attachment 69370
  -- https://bugs.freedesktop.org/attachment.cgi?id=69370action=edit
possible fix

(In reply to comment #7)
 Alex, would it be possible to print what is going on or if an error occurred
 in evergreen_mc_stop()?
 
 I see four things that could be going on:
 1- we are not using the right path for CAYMAN - (ASIC_IS_DCE6(rdev));

cayman is DCE5.  It is using the correct code path.

 2- lock mechanism synced with vblank is not working properly;

Locking makes updates atomic rather than double buffered.

 3- all the registers should be locked at the same time, then all modified
 and finally unlocked together, which is not done with the for loop where we
 move through each at a time;

doesn't matter.

 4- we are not setting the right registers.

The existing sequence should be correct.  It's the same sequence our hw team
recommends.  I can't reproduce this on my cayman boards unfortunately and this
patch fixes the exact same problem you are having for a number of other people
:/

Maybe an issue with the icon or cursor, but I think those should be disabled
when we disable mem requests in the crtc.  Does this patch help?

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 56139] [bisected] kernel 3.7.0-rc1 breaks 6950 (CAYMAN)

2012-10-31 Thread bugzilla-daemon 
https://bugs.freedesktop.org/show_bug.cgi?id=56139

--- Comment #9 from Alexandre Demers alexandre.f.dem...@gmail.com ---
(In reply to comment #8)
 Created attachment 69370 [details] [review]
 possible fix
 
 (In reply to comment #7)
  Alex, would it be possible to print what is going on or if an error occurred
  in evergreen_mc_stop()?
  
  I see four things that could be going on:
  1- we are not using the right path for CAYMAN - (ASIC_IS_DCE6(rdev));
 
 cayman is DCE5.  It is using the correct code path.
 
  2- lock mechanism synced with vblank is not working properly;
 
 Locking makes updates atomic rather than double buffered.
 
  3- all the registers should be locked at the same time, then all modified
  and finally unlocked together, which is not done with the for loop where we
  move through each at a time;
 
 doesn't matter.
 
  4- we are not setting the right registers.
 
 The existing sequence should be correct.  It's the same sequence our hw team
 recommends.  I can't reproduce this on my cayman boards unfortunately and
 this patch fixes the exact same problem you are having for a number of other
 people :/
 
 Maybe an issue with the icon or cursor, but I think those should be disabled
 when we disable mem requests in the crtc.  Does this patch help?

Not working either. Also, with 3.7.0-rc3 + this patch, the computer freezes
when coming back from suspend. I see Gnome-Shell for a couple of seconds, then
some garbage and it stops. Kernel 3.6 works fine on that matter. I'll test with
my split patches to see if it is caused by the same commit.

So, pretty much back to square 1, wherever that is.

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 56139] [bisected] kernel 3.7.0-rc1 breaks 6950 (CAYMAN)

2012-10-27 Thread bugzilla-dae...@freedesktop.org 
https://bugs.freedesktop.org/show_bug.cgi?id=56139

--- Comment #6 from Alexandre Demers  ---
(In reply to comment #5)
> Created attachment 69113 [details] [review]
> possible fix
> 
> (In reply to comment #4)
> > the bug appeared. So it seems blanking the display controllers with for(i =
> > 0; i < rdev->num_crtc; i++) is not equivalent to the code that it replaces.
> > The original code first wrote in the EVERGREEN_CRTC_UPDATE_LOCK registers,
> > before setting EVERGREEN_CRTC_CONTROL registers and writing again in the
> > EVERGREEN_CRTC_UPDATE_LOCK registers. On the other hand, the new code
> > doesn't write in the EVERGREEN_CRTC_UPDATE_LOCK neither before nor after
> > setting EVERGREEN_CRTC_CONTROL.
> 
> It should be equivalent.  CRTC_UPDATE_LOCK turns off double buffering in the
> crtc which makes register updates atomic.  The new code waits for the frame
> count to increase (the double buffered updates happen at vblank) so it
> should be equivalent.  That said, it shouldn't hurt to take the lock.  Does
> this patch help?

Sadly, it didn't help.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:

[Bug 56139] [bisected] kernel 3.7.0-rc1 breaks 6950 (CAYMAN)

2012-10-26 Thread bugzilla-dae...@freedesktop.org 
https://bugs.freedesktop.org/show_bug.cgi?id=56139

Alex Deucher  changed:

   What|Removed |Added

  Attachment #68760|0   |1
is obsolete||

--- Comment #5 from Alex Deucher  ---
Created attachment 69113
  --> https://bugs.freedesktop.org/attachment.cgi?id=69113=edit
possible fix

(In reply to comment #4)
> the bug appeared. So it seems blanking the display controllers with for(i =
> 0; i < rdev->num_crtc; i++) is not equivalent to the code that it replaces.
> The original code first wrote in the EVERGREEN_CRTC_UPDATE_LOCK registers,
> before setting EVERGREEN_CRTC_CONTROL registers and writing again in the
> EVERGREEN_CRTC_UPDATE_LOCK registers. On the other hand, the new code
> doesn't write in the EVERGREEN_CRTC_UPDATE_LOCK neither before nor after
> setting EVERGREEN_CRTC_CONTROL.

It should be equivalent.  CRTC_UPDATE_LOCK turns off double buffering in the
crtc which makes register updates atomic.  The new code waits for the frame
count to increase (the double buffered updates happen at vblank) so it should
be equivalent.  That said, it shouldn't hurt to take the lock.  Does this patch
help?

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:

[Bug 56139] [bisected] kernel 3.7.0-rc1 breaks 6950 (CAYMAN)

2012-10-26 Thread bugzilla-dae...@freedesktop.org 
https://bugs.freedesktop.org/show_bug.cgi?id=56139

--- Comment #4 from Alexandre Demers  ---
First, I made a mistake last time I wrote: the evergreen_mc_resume() function
patch was fine. The bad code was in the evergreen_mc_stop() function. Sorry for
the wrong lead, I realized it today when I continued my tests.

Now, I split the evergreen_mc_stop() code in two parts. The following ran fine:
-WREG32(D1VGA_CONTROL, 0);
-WREG32(D2VGA_CONTROL, 0);
-if (rdev->num_crtc >= 4) {
-WREG32(EVERGREEN_D3VGA_CONTROL, 0);
-WREG32(EVERGREEN_D4VGA_CONTROL, 0);
-}
-if (rdev->num_crtc >= 6) {
-WREG32(EVERGREEN_D5VGA_CONTROL, 0);
-WREG32(EVERGREEN_D6VGA_CONTROL, 0);
+radeon_mc_wait_for_idle(rdev);
+
+blackout = RREG32(MC_SHARED_BLACKOUT_CNTL);
+if ((blackout & BLACKOUT_MODE_MASK) != 1) {
+/* Block CPU access */
+WREG32(BIF_FB_EN, 0);
+/* blackout the MC */
+blackout &= ~BLACKOUT_MODE_MASK;
+WREG32(MC_SHARED_BLACKOUT_CNTL, blackout | 1);

and I was able to boot, stop, restart and suspend correctly.

However, when I applied:
void evergreen_mc_stop(struct radeon_device *rdev, struct evergreen_mc_save
*save)
 {
-u32 blackout;
+u32 crtc_enabled, tmp, frame_count, blackout;
+int i, j;

 save->vga_render_control = RREG32(VGA_RENDER_CONTROL);
 save->vga_hdp_control = RREG32(VGA_HDP_CONTROL);

-/* Stop all video */
+/* disable VGA render */
 WREG32(VGA_RENDER_CONTROL, 0);
-WREG32(EVERGREEN_CRTC_UPDATE_LOCK + EVERGREEN_CRTC0_REGISTER_OFFSET, 1);
-WREG32(EVERGREEN_CRTC_UPDATE_LOCK + EVERGREEN_CRTC1_REGISTER_OFFSET, 1);
-if (rdev->num_crtc >= 4) {
-WREG32(EVERGREEN_CRTC_UPDATE_LOCK + EVERGREEN_CRTC2_REGISTER_OFFSET,
1);
-WREG32(EVERGREEN_CRTC_UPDATE_LOCK + EVERGREEN_CRTC3_REGISTER_OFFSET,
1);
-}
-if (rdev->num_crtc >= 6) {
-WREG32(EVERGREEN_CRTC_UPDATE_LOCK + EVERGREEN_CRTC4_REGISTER_OFFSET,
1);
-WREG32(EVERGREEN_CRTC_UPDATE_LOCK + EVERGREEN_CRTC5_REGISTER_OFFSET,
1);
-}
-WREG32(EVERGREEN_CRTC_CONTROL + EVERGREEN_CRTC0_REGISTER_OFFSET, 0);
-WREG32(EVERGREEN_CRTC_CONTROL + EVERGREEN_CRTC1_REGISTER_OFFSET, 0);
-if (rdev->num_crtc >= 4) {
-WREG32(EVERGREEN_CRTC_CONTROL + EVERGREEN_CRTC2_REGISTER_OFFSET, 0);
-WREG32(EVERGREEN_CRTC_CONTROL + EVERGREEN_CRTC3_REGISTER_OFFSET, 0);
-}
-if (rdev->num_crtc >= 6) {
-WREG32(EVERGREEN_CRTC_CONTROL + EVERGREEN_CRTC4_REGISTER_OFFSET, 0);
-WREG32(EVERGREEN_CRTC_CONTROL + EVERGREEN_CRTC5_REGISTER_OFFSET, 0);
-}
-WREG32(EVERGREEN_CRTC_UPDATE_LOCK + EVERGREEN_CRTC0_REGISTER_OFFSET, 0);
-WREG32(EVERGREEN_CRTC_UPDATE_LOCK + EVERGREEN_CRTC1_REGISTER_OFFSET, 0);
-if (rdev->num_crtc >= 4) {
-WREG32(EVERGREEN_CRTC_UPDATE_LOCK + EVERGREEN_CRTC2_REGISTER_OFFSET,
0);
-WREG32(EVERGREEN_CRTC_UPDATE_LOCK + EVERGREEN_CRTC3_REGISTER_OFFSET,
0);
-}
-if (rdev->num_crtc >= 6) {
-WREG32(EVERGREEN_CRTC_UPDATE_LOCK + EVERGREEN_CRTC4_REGISTER_OFFSET,
0);
-WREG32(EVERGREEN_CRTC_UPDATE_LOCK + EVERGREEN_CRTC5_REGISTER_OFFSET,
0);
+/* blank the display controllers */
+for (i = 0; i < rdev->num_crtc; i++) {
+crtc_enabled = RREG32(EVERGREEN_CRTC_CONTROL + crtc_offsets[i]) &
EVERGREEN_CRTC_MASTER_EN;
+if (crtc_enabled) {
+save->crtc_enabled[i] = true;
+if (ASIC_IS_DCE6(rdev)) {
+tmp = RREG32(EVERGREEN_CRTC_BLANK_CONTROL + crtc_offsets[i]);
+if (!(tmp & EVERGREEN_CRTC_BLANK_DATA_EN)) {
+radeon_wait_for_vblank(rdev, i);
+tmp |= EVERGREEN_CRTC_BLANK_DATA_EN;
+WREG32(EVERGREEN_CRTC_BLANK_CONTROL + crtc_offsets[i],
tmp);
+}
+} else {
+tmp = RREG32(EVERGREEN_CRTC_CONTROL + crtc_offsets[i]);
+if (!(tmp & EVERGREEN_CRTC_DISP_READ_REQUEST_DISABLE)) {
+radeon_wait_for_vblank(rdev, i);
+tmp |= EVERGREEN_CRTC_DISP_READ_REQUEST_DISABLE;
+WREG32(EVERGREEN_CRTC_CONTROL + crtc_offsets[i], tmp);
+}
+}
+/* wait for the next frame */
+frame_count = radeon_get_vblank_counter(rdev, i);
+for (j = 0; j < rdev->usec_timeout; j++) {
+if (radeon_get_vblank_counter(rdev, i) != frame_count)
+break;
+udelay(1);
+}
+}
 }

the bug appeared. So it seems blanking the display controllers with for(i = 0;
i < rdev->num_crtc; i++) is not equivalent to the code that it replaces. The
original code first wrote in the EVERGREEN_CRTC_UPDATE_LOCK registers, before
setting EVERGREEN_CRTC_CONTROL registers and writing again in the
EVERGREEN_CRTC_UPDATE_LOCK registers. On the other hand, the new code doesn't
write in the EVERGREEN_CRTC_UPDATE_LOCK neither before nor after setting

[Bug 56139] [bisected] kernel 3.7.0-rc1 breaks 6950 (CAYMAN)

2012-10-26 Thread bugzilla-daemon 
https://bugs.freedesktop.org/show_bug.cgi?id=56139

--- Comment #6 from Alexandre Demers alexandre.f.dem...@gmail.com ---
(In reply to comment #5)
 Created attachment 69113 [details] [review]
 possible fix
 
 (In reply to comment #4)
  the bug appeared. So it seems blanking the display controllers with for(i =
  0; i  rdev-num_crtc; i++) is not equivalent to the code that it replaces.
  The original code first wrote in the EVERGREEN_CRTC_UPDATE_LOCK registers,
  before setting EVERGREEN_CRTC_CONTROL registers and writing again in the
  EVERGREEN_CRTC_UPDATE_LOCK registers. On the other hand, the new code
  doesn't write in the EVERGREEN_CRTC_UPDATE_LOCK neither before nor after
  setting EVERGREEN_CRTC_CONTROL.
 
 It should be equivalent.  CRTC_UPDATE_LOCK turns off double buffering in the
 crtc which makes register updates atomic.  The new code waits for the frame
 count to increase (the double buffered updates happen at vblank) so it
 should be equivalent.  That said, it shouldn't hurt to take the lock.  Does
 this patch help?

Sadly, it didn't help.

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 56139] [bisected] kernel 3.7.0-rc1 breaks 6950 (CAYMAN)

2012-10-25 Thread bugzilla-daemon 
https://bugs.freedesktop.org/show_bug.cgi?id=56139

--- Comment #4 from Alexandre Demers alexandre.f.dem...@gmail.com ---
First, I made a mistake last time I wrote: the evergreen_mc_resume() function
patch was fine. The bad code was in the evergreen_mc_stop() function. Sorry for
the wrong lead, I realized it today when I continued my tests.

Now, I split the evergreen_mc_stop() code in two parts. The following ran fine:
-WREG32(D1VGA_CONTROL, 0);
-WREG32(D2VGA_CONTROL, 0);
-if (rdev-num_crtc = 4) {
-WREG32(EVERGREEN_D3VGA_CONTROL, 0);
-WREG32(EVERGREEN_D4VGA_CONTROL, 0);
-}
-if (rdev-num_crtc = 6) {
-WREG32(EVERGREEN_D5VGA_CONTROL, 0);
-WREG32(EVERGREEN_D6VGA_CONTROL, 0);
+radeon_mc_wait_for_idle(rdev);
+
+blackout = RREG32(MC_SHARED_BLACKOUT_CNTL);
+if ((blackout  BLACKOUT_MODE_MASK) != 1) {
+/* Block CPU access */
+WREG32(BIF_FB_EN, 0);
+/* blackout the MC */
+blackout = ~BLACKOUT_MODE_MASK;
+WREG32(MC_SHARED_BLACKOUT_CNTL, blackout | 1);

and I was able to boot, stop, restart and suspend correctly.

However, when I applied:
void evergreen_mc_stop(struct radeon_device *rdev, struct evergreen_mc_save
*save)
 {
-u32 blackout;
+u32 crtc_enabled, tmp, frame_count, blackout;
+int i, j;

 save-vga_render_control = RREG32(VGA_RENDER_CONTROL);
 save-vga_hdp_control = RREG32(VGA_HDP_CONTROL);

-/* Stop all video */
+/* disable VGA render */
 WREG32(VGA_RENDER_CONTROL, 0);
-WREG32(EVERGREEN_CRTC_UPDATE_LOCK + EVERGREEN_CRTC0_REGISTER_OFFSET, 1);
-WREG32(EVERGREEN_CRTC_UPDATE_LOCK + EVERGREEN_CRTC1_REGISTER_OFFSET, 1);
-if (rdev-num_crtc = 4) {
-WREG32(EVERGREEN_CRTC_UPDATE_LOCK + EVERGREEN_CRTC2_REGISTER_OFFSET,
1);
-WREG32(EVERGREEN_CRTC_UPDATE_LOCK + EVERGREEN_CRTC3_REGISTER_OFFSET,
1);
-}
-if (rdev-num_crtc = 6) {
-WREG32(EVERGREEN_CRTC_UPDATE_LOCK + EVERGREEN_CRTC4_REGISTER_OFFSET,
1);
-WREG32(EVERGREEN_CRTC_UPDATE_LOCK + EVERGREEN_CRTC5_REGISTER_OFFSET,
1);
-}
-WREG32(EVERGREEN_CRTC_CONTROL + EVERGREEN_CRTC0_REGISTER_OFFSET, 0);
-WREG32(EVERGREEN_CRTC_CONTROL + EVERGREEN_CRTC1_REGISTER_OFFSET, 0);
-if (rdev-num_crtc = 4) {
-WREG32(EVERGREEN_CRTC_CONTROL + EVERGREEN_CRTC2_REGISTER_OFFSET, 0);
-WREG32(EVERGREEN_CRTC_CONTROL + EVERGREEN_CRTC3_REGISTER_OFFSET, 0);
-}
-if (rdev-num_crtc = 6) {
-WREG32(EVERGREEN_CRTC_CONTROL + EVERGREEN_CRTC4_REGISTER_OFFSET, 0);
-WREG32(EVERGREEN_CRTC_CONTROL + EVERGREEN_CRTC5_REGISTER_OFFSET, 0);
-}
-WREG32(EVERGREEN_CRTC_UPDATE_LOCK + EVERGREEN_CRTC0_REGISTER_OFFSET, 0);
-WREG32(EVERGREEN_CRTC_UPDATE_LOCK + EVERGREEN_CRTC1_REGISTER_OFFSET, 0);
-if (rdev-num_crtc = 4) {
-WREG32(EVERGREEN_CRTC_UPDATE_LOCK + EVERGREEN_CRTC2_REGISTER_OFFSET,
0);
-WREG32(EVERGREEN_CRTC_UPDATE_LOCK + EVERGREEN_CRTC3_REGISTER_OFFSET,
0);
-}
-if (rdev-num_crtc = 6) {
-WREG32(EVERGREEN_CRTC_UPDATE_LOCK + EVERGREEN_CRTC4_REGISTER_OFFSET,
0);
-WREG32(EVERGREEN_CRTC_UPDATE_LOCK + EVERGREEN_CRTC5_REGISTER_OFFSET,
0);
+/* blank the display controllers */
+for (i = 0; i  rdev-num_crtc; i++) {
+crtc_enabled = RREG32(EVERGREEN_CRTC_CONTROL + crtc_offsets[i]) 
EVERGREEN_CRTC_MASTER_EN;
+if (crtc_enabled) {
+save-crtc_enabled[i] = true;
+if (ASIC_IS_DCE6(rdev)) {
+tmp = RREG32(EVERGREEN_CRTC_BLANK_CONTROL + crtc_offsets[i]);
+if (!(tmp  EVERGREEN_CRTC_BLANK_DATA_EN)) {
+radeon_wait_for_vblank(rdev, i);
+tmp |= EVERGREEN_CRTC_BLANK_DATA_EN;
+WREG32(EVERGREEN_CRTC_BLANK_CONTROL + crtc_offsets[i],
tmp);
+}
+} else {
+tmp = RREG32(EVERGREEN_CRTC_CONTROL + crtc_offsets[i]);
+if (!(tmp  EVERGREEN_CRTC_DISP_READ_REQUEST_DISABLE)) {
+radeon_wait_for_vblank(rdev, i);
+tmp |= EVERGREEN_CRTC_DISP_READ_REQUEST_DISABLE;
+WREG32(EVERGREEN_CRTC_CONTROL + crtc_offsets[i], tmp);
+}
+}
+/* wait for the next frame */
+frame_count = radeon_get_vblank_counter(rdev, i);
+for (j = 0; j  rdev-usec_timeout; j++) {
+if (radeon_get_vblank_counter(rdev, i) != frame_count)
+break;
+udelay(1);
+}
+}
 }

the bug appeared. So it seems blanking the display controllers with for(i = 0;
i  rdev-num_crtc; i++) is not equivalent to the code that it replaces. The
original code first wrote in the EVERGREEN_CRTC_UPDATE_LOCK registers, before
setting EVERGREEN_CRTC_CONTROL registers and writing again in the
EVERGREEN_CRTC_UPDATE_LOCK registers. On the other hand, the new code doesn't
write in the EVERGREEN_CRTC_UPDATE_LOCK neither before nor after setting

[Bug 56139] [bisected] kernel 3.7.0-rc1 breaks 6950 (CAYMAN)

2012-10-22 Thread bugzilla-dae...@freedesktop.org 
https://bugs.freedesktop.org/show_bug.cgi?id=56139

--- Comment #3 from Alexandre Demers  ---
So, I went further and I split commit 62444b in 3 patches. On for the register
values, one for the stop function and one for the resume function. I applied
the first and the second patches for now and it seems to work well. I suspended
my computer, resumed and everything is going normal (for now at least). I'll
test it a bit more, but the problem seems to be somewhere in the resume
function.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:

[Bug 56139] [bisected] kernel 3.7.0-rc1 breaks 6950 (CAYMAN)

2012-10-21 Thread bugzilla-daemon 
https://bugs.freedesktop.org/show_bug.cgi?id=56139

--- Comment #3 from Alexandre Demers alexandre.f.dem...@gmail.com ---
So, I went further and I split commit 62444b in 3 patches. On for the register
values, one for the stop function and one for the resume function. I applied
the first and the second patches for now and it seems to work well. I suspended
my computer, resumed and everything is going normal (for now at least). I'll
test it a bit more, but the problem seems to be somewhere in the resume
function.

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 56139] [bisected] kernel 3.7.0-rc1 breaks 6950 (CAYMAN)

2012-10-19 Thread bugzilla-dae...@freedesktop.org 
https://bugs.freedesktop.org/show_bug.cgi?id=56139

--- Comment #2 from Alexandre Demers  ---
(In reply to comment #1)
> Created attachment 68760 [details] [review]
> possible fix
> 
> Does this patch help?

Applied suggested patch on top of 62444b7462a2b98bc78d68736c03a7c4e66ba7e2 and
it doesn't fix it.

By the way, I confirmed it is exactly as bug 43655 (same symptoms, same
workaround).

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:

[Bug 56139] [bisected] kernel 3.7.0-rc1 breaks 6950 (CAYMAN)

2012-10-18 Thread bugzilla-dae...@freedesktop.org 
https://bugs.freedesktop.org/show_bug.cgi?id=56139

--- Comment #1 from Alex Deucher  ---
Created attachment 68760
  --> https://bugs.freedesktop.org/attachment.cgi?id=68760=edit
possible fix

Does this patch help?

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:

[Bug 56139] [bisected] kernel 3.7.0-rc1 breaks 6950 (CAYMAN)

2012-10-18 Thread bugzilla-dae...@freedesktop.org 
https://bugs.freedesktop.org/show_bug.cgi?id=56139

Alexandre Demers  changed:

   What|Removed |Added

   See Also||https://bugs.freedesktop.or
   ||g/show_bug.cgi?id=43655,
   ||https://bugs.freedesktop.or
   ||g/show_bug.cgi?id=42373

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:

[Bug 56139] [bisected] kernel 3.7.0-rc1 breaks 6950 (CAYMAN)

2012-10-18 Thread bugzilla-daemon 
https://bugs.freedesktop.org/show_bug.cgi?id=56139

Alexandre Demers alexandre.f.dem...@gmail.com changed:

   What|Removed |Added

   See Also||https://bugs.freedesktop.or
   ||g/show_bug.cgi?id=43655,
   ||https://bugs.freedesktop.or
   ||g/show_bug.cgi?id=42373

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 56139] [bisected] kernel 3.7.0-rc1 breaks 6950 (CAYMAN)

2012-10-18 Thread bugzilla-daemon 
https://bugs.freedesktop.org/show_bug.cgi?id=56139

--- Comment #1 from Alex Deucher ag...@yahoo.com ---
Created attachment 68760
  -- https://bugs.freedesktop.org/attachment.cgi?id=68760action=edit
possible fix

Does this patch help?

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 56139] [bisected] kernel 3.7.0-rc1 breaks 6950 (CAYMAN)

2012-10-18 Thread bugzilla-daemon 
https://bugs.freedesktop.org/show_bug.cgi?id=56139

--- Comment #2 from Alexandre Demers alexandre.f.dem...@gmail.com ---
(In reply to comment #1)
 Created attachment 68760 [details] [review]
 possible fix
 
 Does this patch help?

Applied suggested patch on top of 62444b7462a2b98bc78d68736c03a7c4e66ba7e2 and
it doesn't fix it.

By the way, I confirmed it is exactly as bug 43655 (same symptoms, same
workaround).

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel