<html> <head> <base href="https://bugs.freedesktop.org/" /> </head> <body> <div> <a class="bz_bug_link bz_status_NEW " title="NEW --- - Radeon: evergreen Atombios in loop during initialization on ppc64" href="https://bugs.freedesktop.org/show_bug.cgi?id=59982#c14">Comment # 14</a> on <a class="bz_bug_link bz_status_NEW " title="NEW --- - Radeon: evergreen Atombios in loop during initialization on ppc64" href="https://bugs.freedesktop.org/show_bug.cgi?id=59982">bug 59982</a> from <a class="email" href="mailto:agd5f@yahoo.com" title="Alex Deucher <agd5f@yahoo.com>"> Alex Deucher</a> <pre>(In reply to <a href="show_bug.cgi?id=59982#c13">comment #13</a>) > 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? No. There's only one register BAR. It's for selecting between the register BAR and pci config registers. See atom_op_setport(). I've never seen a table actually use anything other than the register BAR however. > > > 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? They are passed to the table for execution. See atom_execute_table(). That function takes an atom context, an index (which table to execute), and pointer to the parameter struct. > > > 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? See atombios_lock_crtc(). Use this parameter struct with the UpdateCRTC_DoubleBufferRegisters table: typedef struct _ENABLE_CRTC_PARAMETERS { UCHAR ucCRTC; UCHAR ucEnable; UCHAR ucPadding[2]; }ENABLE_CRTC_PARAMETERS; See atombios.h. The parameter struct is 1 dword. The first byte is ucCRTC and the second byte is ucEnable. > > > 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?)? If the bit is high it means there is an update pending. E.g., some change in the crtc state hasn't gone through yet. I'm not sure why you are seeing it stuck high. > > > 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? Yes. 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? crtc_prepare() and crtc_commit() are called before and after a modeset on the crtc object. See drm_crtc_helper_set_mode() in drm_crtc_helper.c. In atombios_crtc_prepare() we take the crtc hardware lock so that all updates will happen atomically, then we disable the crtc. Then in atombios_crtc_mode_set() we set up the pll, set the crtc timing, graphics plane base address, and scaler. Finally in atombios_crtc_commit() we enable the crtc and drop the crtc hardware lock.</pre> </div> <hr> You are receiving this mail because: <ul> <li>You are the assignee for the bug.</li> </ul> </body> </html>