From mboxrd@z Thu Jan 1 00:00:00 1970
From: bugzilla-daemon@freedesktop.org
Subject: [Bug 59982] Radeon: evergreen Atombios in loop during initialization
on ppc64
Date: Sat, 09 Feb 2013 14:40:59 +0000
Message-ID:
References:
Mime-Version: 1.0
Content-Type: multipart/mixed; boundary="===============0102242467=="
Return-path:
Received: from culpepper.freedesktop.org (unknown [131.252.210.165])
by gabe.freedesktop.org (Postfix) with ESMTP id 62122E5C8C
for ;
Sat, 9 Feb 2013 06:40:59 -0800 (PST)
In-Reply-To:
List-Unsubscribe: ,
List-Archive:
List-Post:
List-Help:
List-Subscribe: ,
Sender: dri-devel-bounces+sf-dri-devel=m.gmane.org@lists.freedesktop.org
Errors-To: dri-devel-bounces+sf-dri-devel=m.gmane.org@lists.freedesktop.org
To: dri-devel@lists.freedesktop.org
List-Id: dri-devel@lists.freedesktop.org
--===============0102242467==
Content-Type: multipart/alternative; boundary="1360420859.c56B31.16851"; charset="us-ascii"
--1360420859.c56B31.16851
Date: Sat, 9 Feb 2013 14:40:59 +0000
MIME-Version: 1.0
Content-Type: text/plain; charset="UTF-8"
https://bugs.freedesktop.org/show_bug.cgi?id=59982
--- Comment #12 from Alex Deucher ---
UpdateCRTC_DoubleBufferRegisters takes the crtc hardware lock so that updates
happen atomically rather than double buffered updates during the vupdate
period.
You pass parameters to the atom table via a struct, in this case,
ENABLE_CRTC_PS_ALLOCATION.
args.ucCRTC = radeon_crtc->crtc_id;
args.ucEnable = lock;
0006: 370000 SET_ATI_PORT 0000 (INDIRECT_IO_MM)
Select the mmio register aperture.
0009: 5214 CALL_TABLE 14
(ASIC_StaticPwrMgtStatusChange/SetUniphyInstance)
SetUniphyInstance updates the offset for the selected crtc based on args.ucCRTC
parameter.
000b: 0765b61bfe AND reg[1bb6] [..X.] <- fe
This enables enables double buffering.
0010: 3d650001 COMP param[00] [..X.] <- 01
This checks the params to see is we are enabling the lock (args.ucEnable =
ATOM_ENABLE) or disabling the lock (args.ucEnable = ATOM_DISABLE).
0014: 443b00 JUMP_Equal 003b
If args.ucEnable == ATOM_ENABLE, jump to table offset 0x003b.
Drop the lock (args.ucEnable = ATOM_DISABLE).
0017: 5430761a CLEAR reg[1a76] [.X..]
001b: 54306e1a CLEAR reg[1a6e] [.X..]
001f: 5430271a CLEAR reg[1a27] [.X..]
0023: 5430111a CLEAR reg[1a11] [.X..]
0027: 5420b51b CLEAR reg[1bb5] [...X]
002b: 5420bd1b CLEAR reg[1bbd] [...X]
002f: 4a25b61b01 TEST reg[1bb6] [...X] <- 01
This tests the CRTC_DOUBLE_BUFFER_CONTROL.CRTC_UPDATE_PENDING bit.
0034: 492f00 JUMP_NotEqual 002f
If the bit is high, we jump back to 0x002f. If the bit is low, we're done.
0037: 3a0000 SET_REG_BLOCK 0000
003a: 5b EOT
Take the lock (args.ucEnable = ATOM_ENABLE).
003b: 0d25bd1b01 OR reg[1bbd] [...X] <- 01
0040: 54009e1b CLEAR reg[1b9e] [XXXX]
0044: 3a0000 SET_REG_BLOCK 0000
0047: 5b EOT
Just like in the other table, for some reason, the bit never goes low.
--
You are receiving this mail because:
You are the assignee for the bug.
--1360420859.c56B31.16851
Date: Sat, 9 Feb 2013 14:40:59 +0000
MIME-Version: 1.0
Content-Type: text/html; charset="UTF-8"
Comment # 12
on bug 59982
from Alex Deucher
UpdateCRTC_DoubleBufferRegisters takes the crtc hardware lock so that updates
happen atomically rather than double buffered updates during the vupdate
period.
You pass parameters to the atom table via a struct, in this case,
ENABLE_CRTC_PS_ALLOCATION.
args.ucCRTC = radeon_crtc->crtc_id;
args.ucEnable = lock;
0006: 370000 SET_ATI_PORT 0000 (INDIRECT_IO_MM)
Select the mmio register aperture.
0009: 5214 CALL_TABLE 14
(ASIC_StaticPwrMgtStatusChange/SetUniphyInstance)
SetUniphyInstance updates the offset for the selected crtc based on args.ucCRTC
parameter.
000b: 0765b61bfe AND reg[1bb6] [..X.] <- fe
This enables enables double buffering.
0010: 3d650001 COMP param[00] [..X.] <- 01
This checks the params to see is we are enabling the lock (args.ucEnable =
ATOM_ENABLE) or disabling the lock (args.ucEnable = ATOM_DISABLE).
0014: 443b00 JUMP_Equal 003b
If args.ucEnable == ATOM_ENABLE, jump to table offset 0x003b.
Drop the lock (args.ucEnable = ATOM_DISABLE).
0017: 5430761a CLEAR reg[1a76] [.X..]
001b: 54306e1a CLEAR reg[1a6e] [.X..]
001f: 5430271a CLEAR reg[1a27] [.X..]
0023: 5430111a CLEAR reg[1a11] [.X..]
0027: 5420b51b CLEAR reg[1bb5] [...X]
002b: 5420bd1b CLEAR reg[1bbd] [...X]
002f: 4a25b61b01 TEST reg[1bb6] [...X] <- 01
This tests the CRTC_DOUBLE_BUFFER_CONTROL.CRTC_UPDATE_PENDING bit.
0034: 492f00 JUMP_NotEqual 002f
If the bit is high, we jump back to 0x002f. If the bit is low, we're done.
0037: 3a0000 SET_REG_BLOCK 0000
003a: 5b EOT
Take the lock (args.ucEnable = ATOM_ENABLE).
003b: 0d25bd1b01 OR reg[1bbd] [...X] <- 01
0040: 54009e1b CLEAR reg[1b9e] [XXXX]
0044: 3a0000 SET_REG_BLOCK 0000
0047: 5b EOT
Just like in the other table, for some reason, the bit never goes low.
You are receiving this mail because:
- You are the assignee for the bug.
--1360420859.c56B31.16851--
--===============0102242467==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
--===============0102242467==--