Comment # 13 on bug 59982 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