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

[bugzilla-daemon at freedesktop.org]

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

--- Comment #14 from Alex Deucher <agd5f at yahoo.com> ---
(In reply to comment #13)
> 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.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20130213/a0fa08f0/attachment.html>