Dynamic clock cause hard lockup on Radeon 7000 + SMP

Alex Deucher alexdeucher at gmail.com
Tue Nov 23 14:31:49 PST 2004


On Tue, 23 Nov 2004 17:25:00 -0500, Kristian Høgsberg <krh at bitplanet.net> wrote:
> 
> 
> Alex Deucher wrote:
> > On Tue, 23 Nov 2004 16:26:14 -0500, Michel Dänzer <michel at daenzer.net> wrote:
> >
> >>On Tue, 2004-11-23 at 15:06 -0500, Alex Deucher wrote:
> >>
> >>>On Tue, 23 Nov 2004 15:01:08 -0500, Alex Deucher <alexdeucher at gmail.com> wrote:
> >>>
> >>>>On Tue, 23 Nov 2004 14:21:18 -0500, Kristian Høgsberg <krh at bitplanet.net> wrote:
> >>>>
> >>>>
> >>>
> >>>-            if ( !info->HasCRTC2 ) {
> >>>+           if ((info->ChipFamily == CHIP_FAMILY_RV100) &&
> >>>!(info->IsMobility)) {
> >>>+               break;
> >>>+           } else if ( !info->HasCRTC2 ) {
> >>
> >>It should probably simply be enabled only on Mobility chips.
> >>
> >
> >
> > right now it's not enabled for _any_ chips by default, however, the
> > not enabled case which sets the clocks explicitly to "on" rather than
> > "dynamic" seems to cause lockups for Kristian.  Kristian, does it lock
> > up when you turn dynamicclocks on (sets clocks for dynamic) on your
> > board?
> 
> Hmm, no, enabling dynamic clocks also makes the crash go away.  I was
> wondering why not enabling dynamic clocks (ie no "DynamicClocks" option)
> also need to change the PLL bits. I was expecting that in that case it
> could just leave it as is (i.e. 6.7.0 behaviour).  Or in code:
> 
>      if (xf86ReturnOptValBool(info->Options, OPTION_DYNAMIC_CLOCKS,
> FALSE)) {
>          RADEONSetDynamicClock(pScrn, 1);
>      }
> 
> instead of
> 
>      if (xf86ReturnOptValBool(info->Options, OPTION_DYNAMIC_CLOCKS,
> FALSE)) {
>          RADEONSetDynamicClock(pScrn, 1);
>      } else {
>          RADEONSetDynamicClock(pScrn, 0);
>      }
> 

the problem was that certain asics apparently need to have their
clocks forced on rather than left in their default configuration.  the
old 6.7 code forced on several clocks in the accel init code in radeon
_accel.c.  that code was removed or commented out in favor of the code
here.

Alex

> cheers,
> Kristian
>



More information about the xorg mailing list