Dynamic clock cause hard lockup on Radeon 7000 + SMP
Alex Deucher
alexdeucher at gmail.com
Tue Nov 23 15:27:44 PST 2004
On Tue, 23 Nov 2004 17:46:24 -0500, Kristian Høgsberg <krh at bitplanet.net> wrote:
>
>
> Alex Deucher wrote:
> > 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.
>
> OK, so the right fix would be to port that clock configuration from 6.7
> radeon_accel.c into the 'case 0:' part of RADEONSetDynamicClock()?
>
it seems that way. I'll try and take a loot at it this week at some
point and come up with a better patch unless someone beats me to it.
Alex
> Kristian
>
More information about the xorg
mailing list