[Bug 59982] Radeon: evergreen Atombios in loop during initialization on ppc64

[bugzilla-daemon@freedesktop.org]

[-- Attachment #1.1: Type: text/plain, Size: 1558 bytes --]

https://bugs.freedesktop.org/show_bug.cgi?id=59982

--- Comment #17 from Lucas Kannebley Tavares <lucaskt@linux.vnet.ibm.com> ---
Created attachment 75176
  --> https://bugs.freedesktop.org/attachment.cgi?id=75176&action=edit
Dumping registers to investigate values change

Ok, so now I've tried dumping the register we're waiting for using this patch,
and the output looks like this:

   OR_REG @ 0xD8EA
EVERGREEN_CRTC_BLANK_CONTROL: 0001
0x6ED8: 10000
      dst: 
REG[0x19A4].[7:0] -> 0x04
      src: 
PS[0x00,0x0000].[7:0] -> 0x00
      dst: 
REG[0x19A4].[7:0] <- 0x04
   EOT @ 0xD8EF
EVERGREEN_CRTC_BLANK_CONTROL: 0001
0x6ED8: 10000
<<
>> execute E82E (len 91, WS 0, PS 0)
   MOVE_PS @ 0xE834
EVERGREEN_CRTC_BLANK_CONTROL: ffffffff
0x6ED8: ffffffff

I'm dumping 0x6ED8 as it is the register whose bit never goes down. Following
this, all references to either register are All F's. I'm wondering if this
could be my testing interfering with the adapter operation, or if this is
really what's going on, as it could indicate other problems.

Can I be dumping these registers there? Does that interfere with tests?
Should I dump another register for testing? Which one would be best?

>From the 0xD8EA address, I can conclude it was executing the DAC1OutputControl
function from the atombios that exited sucessfully. I'm investigating what
happens afterwards that trigger this. Is it interrupt activation? Right now
we're having to use LSIs, so it might be a problem there.

Thanks

-- 
You are receiving this mail because:
You are the assignee for the bug.

[-- Attachment #1.2: Type: text/html, Size: 2710 bytes --]

[-- Attachment #2: Type: text/plain, Size: 159 bytes --]

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