Comment # 17
on bug 59982
from Lucas Kannebley Tavares
Created attachment 75176 [details] [review] 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.
_______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/dri-devel
