https://bugs.freedesktop.org/show_bug.cgi?id=59982 --- Comment #13 from Lucas Kannebley Tavares --- Thanks for clarifying those things! Well, I ran into a brand new set of questions while pursuing this. > 0006: 370000 SET_ATI_PORT 0000 (INDIRECT_IO_MM) > Select the mmio register aperture. This sounds like selecting BARs, but from what I see, Region 0 would be the framebuffer (256M) and Region 2 would be the MMIO registers. Or how are those addresses mapped from within the adapter? Or does that mean that there are multiple register banks and you're picking one? > 0009: 5214 CALL_TABLE 14 >(ASIC_StaticPwrMgtStatusChange/SetUniphyInstance) >SetUniphyInstance updates the offset for the selected crtc based on args.ucCRTC >parameter. How are parameters passed here? Does it get the same parameters that the first call received? I take it, the reference for param[00] there means ucCRTC, then. Is that it? > 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) Ok, so, why is now param[00] referencing ucEnable? What is the reference to ucCRTC here? > 0034: 492f00 JUMP_NotEqual 002f > If the bit is high, we jump back to 0x002f. If the bit is low, we're done. So, the bit being low here means we don't have an update pending. Does it being high mean that the lock is still in effect (i.e. the CLEAR commands didn't take the disables down?)? > 0044: 3a0000 SET_REG_BLOCK 0000 > 0047: 5b EOT This seems to me like stack cleanup and return (I'm guessing EOT is End Of Table). Is that correct? On the kernel driver side, I couldn't find who is calling, or what's the purpose of the crtc_prepare and crtc_commit functions, which are the only ones apparently using this call (atombios_lock_crtc). What are they meant to do? Thanks -- You are receiving this mail because: You are the assignee for the bug.